Спецификация из конфигуратора: состав изделия и заказ

Спецификация из конфигуратора — это документ, который система собирает автоматически из выбранных опций: позиции, артикулы, количество, комплектующие, вес и габариты. Она снимает ручной перенос конфигурации в таблицу и делает так, чтобы заказ в производство и закупку уходил ровно в той комплектации, которую согласовал клиент.

Дальше — что именно в неё попадает, как из конфигурации собирается состав изделия, куда спецификация уходит и где конфигуратор ловит ошибки до того, как они станут переделками в цехе.

Что такое спецификация из конфигуратора и чем она не является?

Спецификация описывает состав: что именно нужно изготовить, собрать, укомплектовать и отгрузить. Конфигуратор уже знает, из каких опций собран продукт, поэтому спецификация — это следствие конфигурации, а не отдельная работа менеджера после закрытия сделки.

Спецификацию регулярно путают с расчётом и коммерческим предложением. Расчёт отвечает на вопрос «сколько это стоит», КП — «на каких условиях клиент это покупает», а спецификация — «из чего изделие состоит и что заказывать в цех и снабжение».

Отличие спецификации от КП и от расчёта цены

КП уходит клиенту и показывает цену, скидку, сроки и условия поставки. Спецификация чаще всего становится приложением к договору и внутренним документом, по которому работают производство, снабжение и логистика. Цена в ней может быть, а может и не быть — а вот состав обязан быть точным.

Если инструмент умеет только считать цену — например, калькулятор для сайта, — состав изделия всё равно собирают руками. Именно на этом шаге появляются расхождения между тем, что согласовал клиент, и тем, что уехало на завод. Как из первичного запроса собирается предложение клиенту, разобрано отдельно — в материале про Web-RFQ по опросному листу.

Почему без конфигуратора спецификацию собирают вручную

Когда конфигурация живёт в переписке и в голове менеджера, её кто-то переводит в таблицу. Обычно это инженер или снабженец, который не участвовал в переговорах и восстанавливает состав по обрывкам описаний. Каждый такой перевод — точка потери данных.

Почему ручная спецификация ломает производство?

Пока конфигураций в месяц десять и они типовые, ручная работа терпима. Как только продукт собирается из базы и десятков опций, ошибка становится вопросом времени, а не вероятности. Разберём, где именно происходит сбой.

• Пропущенная позиция. Менеджер собирает спецификацию по памяти или по прошлому заказу и забывает то, что в прошлый раз обсуждали отдельно. В цехе это выясняется на сборке, когда изделие уже начали делать.
• Не тот артикул. Прайс содержит десятки похожих исполнений, отличающихся одним индексом: сторона подключения, мощность, материал, тип крепления. Ошибка на один символ даёт неверную деталь в заказе на закупку.
• Количество и комплектность. Расходники, крепёж и метизы считаются «на глаз» или по нормативу из старого документа. Недосчитали — срочная дозакупка по невыгодной цене, пересчитали — замороженные деньги на складе.
• Вес и габариты. Если спецификация не несёт транспортных характеристик, логистика считает доставку вслепую. В итоге доставку либо оплачивает производитель, либо клиент получает счёт, которого не ожидал.
• Версии. Клиент по ходу согласования меняет опцию, спецификация остаётся в прежней редакции, и кто-то из сторон работает по устаревшему документу. Без фиксации версии доказать, что именно согласовали, невозможно.
• Сроки. Пока спецификация уточняется по почте, снабжение ждёт, а производство не может поставить заказ в план. Дни, потраченные на сверку состава, сдвигают всю цепочку.

Что должно попадать в спецификацию из конфигуратора?

Спецификация нужна четырём потребителям сразу: продажам, производству, снабжению и логистике. Каждому нужен свой срез данных, поэтому документ собирается из одного источника, а показывается по-разному. Если конфигуратора у вас пока нет, общий контур описан в разделе решений для конфигураторов.

Вот минимальный состав, без которого спецификация не работает:

• позиции и опции с артикулами и наименованиями по номенклатуре учётной системы;
• количество и единицы измерения — в тех же единицах, что в прайсе и на складе;
• комплектующие, крепёж, расходники и нормы их расхода на изделие;
• вес, габариты и тип упаковки для расчёта перевозки;
• технические параметры, материал и покрытие — то, что критично для цеха;
• принадлежность к заказу, версия конфигурации и дата фиксации;
• при необходимости — аналоги и допустимые замены.

Такой набор данных появляется не сам. Он опирается на параметрический каталог, где у каждой позиции описаны характеристики и правила применения — о том, как собрать каталог продукции из прайса, мы разбирали отдельно. Если каталог нужно построить из действующего прайса, это отдельное направление — каталоги продукции.

Уровни спецификации: изделие, узел, деталь

Если конфигуратор описывает только верхний уровень, нижние снова расписывают вручную.

Что из этого нужно снабжению и логистике

Снабжению нужны артикулы, количество и сроки по каждой закупаемой позиции. Логистике — вес, объём, габариты и число мест. Оба среза строятся из одной спецификации, если в ней с самого начала заложены эти атрибуты.

Как из конфигурации собирается состав изделия (BOM)?

BOM, или состав изделия, — это перечень компонентов, из которых состоит продукт, с количеством и связями между уровнями. Для конфигуратора это не отдельная сущность, а результат: клиент выбрал опции, система развернула их в дерево компонентов по правилам входимости.

Для этого у каждой опции должно быть описано, из чего она состоит и как влияет на состав. Например, выбор «левое исполнение» меняет не только артикул корпуса, но и сторону вывода, набор крепежа и схему упаковки.

Правила входимости и нормы расхода

Входимость — это правило «если выбрана опция X, в состав входит деталь Y в количестве Z». У сложных изделий таких правил сотни, и держать их в Excel-таблице рядом с прайсом почти невозможно: связи рвутся при первом же обновлении.

Аналоги и допустимые замены

Замена — тоже правило. Если деталь недоступна или идёт с длинным сроком, система должна предложить допустимый аналог с сохранением технических характеристик, а не оставить снабжение в тупике. Без этого каждая замена согласуется через инженера, и сроки снова растут.

Куда уходит спецификация: от кабинета дилера до 1С и ERP

Спецификация полезна ровно настолько, насколько быстро попадает туда, где по ней начинают работать. Если она остаётся PDF-файлом в почте, ручной ввод никуда не исчезает — просто переносится на следующий шаг.

Слева — то, что делает конфигуратор, справа — адресаты, которые получают результат. Разница между «файлом в почте» и рабочей спецификацией ровно в этом звене: документ не перепечатывают, а передают.

Передача в 1С и ERP

Самое ценное — прямая передача спецификации в учётную систему. Заказ создаётся без повторного ввода, позиции встают в закупку, а резерв на складе проверяется на актуальных данных. Меньше ручных операций — меньше расхождений между тем, что продали, и тем, что закупили и отгрузили.

Спецификация как приложение к договору

Клиенту обычно нужен документ, где состав зафиксирован и подписан. Если он генерируется из той же конфигурации, что и внутренний заказ, спора «мы согласовывали другое» просто не возникает. Версия и дата в документе закрывают вопрос задним числом.

Спецификация для дилера и партнёра

Когда продают дилеры, спецификацию логично собирать в дилерском кабинете: партнёр конфигурирует по вашим правилам, а вы получаете заказ уже с готовым составом. Это снимает поток уточнений в переписке и делает цены сопоставимыми между каналами. Что внутри такого кабинета и с чего начинать его внедрение, разобрано в материале про дилерский кабинет.

Как конфигуратор ловит ошибки в спецификации?

Конфигуратор ценен не тем, что собирает документ, а тем, что не даёт собрать неправильный. Правила проверяются в момент конфигурирования, когда исправление стоит ноль, а не на сборке, где оно стоит денег и сроков. Проверок четыре:

1. Совместимость. Система не даст поставить опцию, которая физически не сочетается с уже выбранной. Это ядро любого конфигуратора продукта: без правил совместимости он превращается в красивый, но бесполезный конструктор.
2. Полнота комплекта. Конфигурация, из которой невозможно собрать рабочее изделие, не должна уходить дальше. Проверка обязательных групп компонентов ловит именно тот случай, когда клиент не выбрал нужное, а менеджер не заметил.
3. Технические ограничения. Мощность, размеры, вес, допустимая нагрузка, требования к помещению: то, что нельзя проверить «на глаз», но можно описать правилом. Здесь же живут ограничения по транспортировке и монтажу.
4. Склад и сроки. Если позиции нет, а замена недопустима, лучше узнать об этом на этапе конфигурации, а не после подписания. Это прямо влияет на срок поставки, который вы называете клиенту.

Кто отвечает за правила и справочники?

Правила, артикулы и нормы расхода живут дольше любого интерфейса и меняются быстрее, чем кажется. Значит, у них должен быть владелец и регламент обновления, иначе через полгода конфигуратор начнёт считать по устаревшим данным.

Один источник данных — обязательное условие. Если цены и номенклатура лежат одновременно в 1С и в отдельной таблице для конфигуратора, они разойдутся в первый же месяц обновления прайса. Владелец процесса должен быть один, и это не разработчик.

Обновление при смене прайса и ассортимента

Появление новой линейки, снятие позиции с производства, изменение комплектации базового изделия — всё это изменения в правилах, а не только в ценах. Хорошо, если каждое из них проходит по понятному маршруту: заявка, правка справочника, проверка на тестовой конфигурации, публикация. Иначе обновление превращается в аварийный ремонт.

Что это даёт производителю?

Эффект от спецификации из конфигуратора считается не в абстрактной «автоматизации», а в конкретных потерях, которые уходят:

Когда конфигуратора и спецификации уже не хватает — например, нужны сложные скидочные правила и согласования по уровням, — обычно речь идёт о CPQ-системе, которая берёт на себя всю цепочку от конфигурации до предложения.

Как внедрить спецификацию из конфигуратора: с чего начать?

1. Собрать справочник. Начинать стоит не с документа, а с правил и справочника. Пока не описаны опции, комплектующие и нормы расхода, любая форма спецификации будет пустой оболочкой. Собрать вводные помогают документы для старта проекта — брифы на конфигуратор и шаблоны ТЗ.
2. Взять пилот. Одна линейка продуктов или один канал продаж. На ограниченном объёме видно, где правила описаны неполно, а где данные в учётной системе не совпадают с реальностью цеха.
3. Сверить с фактической сборкой. Расхождения первых заказов правят в правилах, а не в документе, — иначе ошибка вернётся в следующем заказе.

Ориентиры по срокам и стоимости зависят от числа правил, глубины интеграции и качества данных; смотреть их удобнее на странице цен. Общий подход к встраиванию инструмента в сайт и процессы описан в материале про конфигуратор на сайте производителя, а собрать задачу под вашу номенклатуру можно на стартовой странице.

Нужна спецификация, которая собирается сама? Если у вас сложный прайс и изделие собирается из опций, пришлите номенклатуру — разберём состав, правила входимости и покажем, как это работает на ваших данных. Заполните бриф за 5 минут — получите оценку по срокам и бюджету на странице старта проекта.

Читайте также

Серия о цифровых инструментах для B2B — от данных производителя к рабочему продукту:

• Конфигуратор продукта — что должно быть внутри, чтобы выбор клиента превращался в правильную конфигурацию.
• Каталог продукции из прайса — на чём строится состав изделия: характеристики, артикулы и правила применения.
• CPQ-система — следующий шаг, когда нужны скидочные правила, согласования и предложения клиенту.

Что уже сделано на подобных проектах — системы подбора, расчёта и подготовки КП — собрано в разделе кейсов.

Частые вопросы