Обзор конфигурации продукта
Потребность в конфигурировании продуктов в соответствии с особыми требованиями становится скорее правилом, чем исключением, как в B2B-, так и в B2C-отношениях.
Изготовитель, который поддерживает сценарии конфигурирования под заказ, имеет возможность более гибко реагировать на потребности клиентов. Кроме того, путем создания запасов полуфабрикатов в виде универсальных компонентов, а не готовой продукции, производитель может уменьшить капитал, замороженный в запасах.
Успешный переход от схемы производства в запас к схеме конфигурирования под заказ требует тщательного анализа структур продуктов, выявления семейств продуктов и компонентизации. Чтобы уменьшить количество деталей и свести к минимуму количество незавершенных товаров, очень важно понимать интерфейсы продуктов и проектировать продукты в расчете на повторное применение.
Существует несколько принципов моделирования конфигурации продукта, например основанное на правилах, основанное на аналитиках и основанное на ограничениях моделирование. Исследования показывают, что основанная на ограничениях методология может уменьшить количество строк кода в моделях примерно на 50 процентов по сравнению с другими принципами моделирования. Следовательно, эта методология может уменьшить общую стоимость владения (TCO). В случае перехода от модели на основе правил, основанной на коде X++, к модели на основе ограничений, вам больше будет не нужна лицензия разработчика для ведения моделей продуктов.
Конфигурация продукта
Период индустриализации привел к огромным достижениям в производстве высококачественных, функциональных изделий по доступным ценам. Эффект масштаба позволил большинству людей в промышленно развитых странах приобрести автомобили, телевизоры, бытовую технику и другие товары, которые большинство из нас считают необходимой составляющей повседневной жизни.
Поскольку многие изделия стали массовыми, возникла потребность в их дифференциации. Первой реакцией производителей было создание вариантов каждого изделия, чтобы у покупателей было больше альтернатив. Эта стратегия привела к проблемам с прогнозированием, а также к повышению стоимости запасов и появлению непроданных изделий, которые становились устаревшими.
Принимая на вооружение философию конфигурирования на заказ, производители имеют возможность удовлетворить потребительский спрос на уникальные изделия и сократить количество устаревших номенклатур запасах либо ликвидировать их вовсе. По перехода от философии производства в запасы к философии конфигурирования на заказ сразу же возникает одна проблема: необходимость обеспечить короткие сроки выполнения заказов при низких уровнях запасов.
Ключом к успеху здесь является тщательный анализ портфеля продукции и поиск паттернов как в характеристиках продуктов, так и в технологических процессах. Задача состоит в том, чтобы выявить универсальные компоненты, которые могут быть изготовлены на одном и том же оборудовании и использоваться во всех вариантах.
Набор функций "Конфигурация продукта" включает в себя пользовательский интерфейс, который обеспечивает визуальный обзор структуры модели конфигурации продукта, а также декларативный синтаксис ограничений, который не требует компиляции. Следовательно, компаниям, которые хотят перейти к практике конфигурирования, будет легче приступить к работе. Как будет пояснено в следующих разделах, проектировщику продукта больше не требуется помощь разработчика для построения модели конфигурации продукта, ее тестирования и передачи торговой организации.
Построение модели конфигурации продукта
Существует несколько подходов к построению модели конфигурации продукта, которыми может воспользоваться пользователь. Один из вариантов — двигаться последовательно, т. е. сначала создать все ссылочные данные, такие как шаблоны продукта, уникально идентифицируемые продукты и операционные ресурсы, а затем включать их в качестве компонентов, строк спецификаций, операций маршрута и других элементов модели конфигурации продукта. Другой вариант — двигаться итеративно, т. е сначала создать модель, а затем по мере необходимости добавлять ссылочные данные.
Компоненты
Модель конфигурации продукта состоит из одного или нескольких компонентов, увязанных воедино посредством подкомпонентных отношений. Компоненты определяются один раз, а затем могут использоваться многократно в одной или нескольких моделях конфигурации продуктов. Компоненты — это главные "кирпичики" модели конфигурации продукта, и практически вся информация о модели связана именно с ними.
Атрибуты
У каждого компонента есть один или несколько атрибутов для определения его свойств. Атрибуты — это то, что пользователи будут выбирать в процессе конфигурирования. Атрибуты управляют отношениями и между компонентами, и внутри компонентами путем их включения в ограничения или вычисления. Посредством условий, применяемых к строкам спецификации, атрибуты можно использовать для определения того, из каких физических деталей будет состоять сконфигурированный продукт. Кроме того, атрибут может управлять свойством строки спецификации посредством механизма сопоставления. Подобная функциональность существует и для операций маршрута (и включение, и задание свойств).
Примечание
При создании типов атрибутов избегайте создания большого количества значений для домена типа атрибута. Это может привести к снижению производительности конфигуратора продуктов.
Ограничение выражений
Использование основанной на ограничениях модели конфигурации продукта подразумевает, что при выборе пользователем значений для различных атрибутов существуют некоторые ограничения. Такие ограничения могут быть реализованы как выражения с использованием языка оптимизации моделирования (Optimization Modeling Language, OML). Другой вариант — реализовать ограничение в виде табличного ограничения.
Ограничения таблицы
Ограничения таблицы могут быть определены пользователем или системой.
Определенное пользователем табличное ограничение создается пользователем. Пользователь выбирает сочетание типов атрибутов, представляющее столбцы таблицы, а затем вводить значения из доменов, соответствующих выбранным типам атрибутов, чтобы образовать строки в табличном ограничении.
Определенное системой табличное ограничение определяется путем выбора таблицы, используемой в качестве ссылки, и выбора полей из этой таблицы для образования столбцов в ограничении. Строки табличного ограничения — это строки таблицы Supply Chain Management, присутствующие во время конфигурации.
Табличное ограничение включается в модель конфигурации продукта путем ссылки на определение табличного ограничения и сопоставления соответствующих атрибутов в модели со столбцами в табличном ограничении.
Вычисления
Вычисления представляют собой механизм для выполнения арифметических операций в модели конфигурации. Например, вычисление может определять длину конкретной заготовки или длительность операции полировки. Вычисления являются императивными и задают значение целевого атрибута после того, как станут доступны все значения атрибутов, входящих в выражение вычисления.
Подкомпоненты
Подкомпоненты представляют собой узлы в структуре модели конфигурации продукта. Для каждого отношения подкомпонентов должна быть указана ссылка на шаблон продукта, у которого в качестве метода конфигурации вариантов установлена конфигурация на основе ограничений.
Потребности пользователя
Требование пользователя содержит все те же составные части, что и подкомпонент. Единственное различие состоит в том, что требование пользователя не связано с шаблоном продукта. На практике это различие проявляется в том, что все строки спецификации или операции маршрута, определяемые в контексте требования пользователя, сворачиваются в структуру спецификации или маршрут родительского компонента. Это поведение похоже на поведение виртуальной спецификации.
Строки спецификации
Строки спецификации включаются для определения производственной спецификации для каждого компонента. Строка спецификации должна ссылаться на номенклатуру, и все свойства номенклатуры могут быть установлены равными фиксированному значению или сопоставлены атрибутам.
Операции маршрута
Операции маршрута включаются для определения маршрута производства. Операция маршрута должна ссылаться на определенную операцию, и все свойства могут быть установлены равными фиксированному значению. Все свойства, за исключением потребностей в ресурсах, можно составить атрибуту вместо задания значения.
Валидация и тестирование модели конфигурации продукта
Валидация модели конфигурации продукта может происходить на нескольких уровнях в модели и, следовательно, охватывать различные области. Самый низкий уровень — валидация одного ограничения-выражению. В этом случае валидация обычно выполняется конструктором продукта и предполагает проверку правильности синтаксиса выражения.
Аналогичным образом можно изолированно валидировать условие для строки спецификации или операции маршрута.
Валидировать также можно определенное пользователем определение табличного ограничения. В этом случае пользователь может проверить, что значения, введенные для каждого поля, находятся внутри домена соответствующих типов атрибутов.
И наконец, валидировать можно всю модель конфигурации продукта, чтобы убедиться в правильности всего синтаксиса, а также в том, что все соглашения по именованию и моделированию соблюдены.
Тестирование
Тестирование модели сходно с проведением фактической сессии конфигурирования. Пользователь может пройти по страницам конфигурации и убедиться, что структура модели поддерживает процесс конфигурирования. Потребитель может проверить что значения атрибутов верны, и что описания к атрибутам позволяют пользователю выбрать правильные значения. В конце концов, после того как тестовая сессия завершена, система пытается создать спецификацию и маршрут, соответствующие выбранным значениям атрибутов, и выводит сообщение об ошибке, есть что-то пошло не так.
Страница конфигурации
Для перехода между компонентами нажимайте Далее или выберите компонент в дереве модели конфигурации продукта, чтобы установить на него фокус.
Окончательное оформление модели для конфигурирования
Когда модель конфигурации продукта готова к использованию в сценариях конфигурирования под заказ, необходимо создать ее версию. Однако есть ряд вариантов, которые могут сделать моделирование более комфортным.
Пользовательский интерфейс
Можно видоизменить пользовательский интерфейс конфигурирвоания путем использования групп атрибутов в одном или нескольких компонентах. Такое группирование может подчеркнуть отношения между определенными атрибутами и помочь пользователю конфигурирования определить область продукта, над которой в данный момент идет работа.
Шаблоны
Для ускорения процесса конфигурирования можно создать один или несколько процессов конфигурирования. Другой вариант — создать шаблоны для продвижения определенных сочетаний атрибутов, например при проведении рекламной акции, сосредоточенной на конкретном наборе характеристик продукта.
Переводы
Если продукт будет продаваться в различных странах/регионах, можно создать переводы для всего текста, присутствующего в пользовательском интерфейсе конфигурирования. Этот текст включает не только поля имен и описаний, но и текстовые значения атрибутов.
Версии
Последний и самый важный шаг в процессе окончательного оформления — это создание версии для модели конфигурации продукта. Версия представляет собой отношение между шаблоном продукта, который может быть выбран для конфигурации в строке заказа или предложения, и моделью конфигурации продукта. Прежде чем версию можно будет использовать в сессиях конфигурирования, ее необходимо утвердить и активировать.
Расширение модели конфигурации продукта посредством API
Реализован специальный интерфейс прикладного программирования (API), чтобы партнеры и другие пользователи, у которых есть лицензия разработчика, могли расширять возможности модели конфигурации продукта. Главной целью было создать механизм, который позволил бы партнерам и клиентам, пользующимся Конфигуратором продукции, проводить миграцию внедренного в модели Конфигуратора продукции кода на этот API. Таким образом они смогут перенести свои модели из Конфигуратора продукции в конфигурацию продукта. Тем не менее, новые партнеры и клиенты также могут извлечь пользу из API — использовать его для расширения новых моделей конфигурации продуктов.
API реализован путем использования набора классов PCAdaptor, которые предоставляют структуру данных моделей конфигурации продуктов. Экземпляр класса PCAdaptor должен быть создан для каждой модели, которая расширяется. После завершения сеанса конфигурации система проверяет наличие экземпляра этого класса и запускает его, если он найден.
На следующей блок-схеме API показаны основные этапы процесса.
Настройка продуктов
Настройка одного или нескольких продуктов
Можно настроить продукты из следующих мест:
- Строка заказа на продажу
- Строка предложения по продаже
- Строка заказа на покупку
- Строка производственного заказа
- Строка потребности в номенклатуре (проект)
Цель конфигурирования — создать особый вариант продукта, соответствующий требованиям клиента. Для каждой новой конфигурации создается уникальный код конфигурации. Этот код обеспечивает возможность ее отслеживания в запасах.
Многоузловые и внутрихолдинговые сценарии
Если конфигурирование будет производиться в узле или даже в компании, отличных от узла или компании, где будет происходить производство, будут созданы спецификация и маршрут для узла поставщика в поставляющей компании и помещены в этот узел. Вариант продукта будет выпущен во всех компаниях, которые участвуют в цепочке поставок.