← Статьи
Конфигураторы

Конфигуратор для нескольких линеек: как один движок обслуживает весь каталог

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

Конфигуратор для нескольких продуктовых линеек: как один движок обслуживает весь каталог

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

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

Почему отдельный конфигуратор под каждую линейку — тупик?

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

Цифры показывают масштаб. Если у трёх линеек 40 общих правил, при копировании получается 120 записей вместо 40. При 12 изменениях каталога в год это 36 правок вместо 12 — и каждая правка в трёх местах это ещё и три способа ошибиться.

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

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

Что в конфигураторе должно быть общим, а что — своим?

Работает простое разделение: общее поднимается наверх, особенное остаётся внизу. Ниже три уровня, и каждый отвечает на свой вопрос — что продаём, чем линейка отличается, что нестандартного у конкретной модели.

Каталожный уровень: библиотека опций и атрибутов

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

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

Уровень линейки: модели, коэффициенты, условия продаж

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

Именно здесь удобно хранить и политику: например, по бюджетной серии скидка дилера 12%, по промышленной — 18%, потому что объём закупки другой. Если эти условия живут в копиях конфигуратора, они разъезжаются при первом же пересмотре прайса.

Уровень модели: точечные исключения

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

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

Как устроить библиотеку атрибутов, чтобы не плодить справочники?

Атрибут описывает характеристику изделия, опция — то, что клиент покупает. Смешивать их нельзя: «мощность привода» — атрибут с числом и единицей, «привод 5,5 кВт» — значение, «привод повышенной мощности» — опция, которая это значение выставляет.

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

Отдельно стоит договориться о формате значений до наполнения каталога. «5.5 кВт», «5,5 кВт» и «5,5кВт» — три разные строки для системы, даже если человек читает их одинаково. На каталоге в 600 позиций такая мелочь превращается в неработающий фильтр и неверную совместимость.

Как считать цену, если одна и та же опция стоит по-разному в линейках?

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

Покажем на двух линейках. Базовая комплектация первой стоит 480 000 ₽, набор из четырёх опций — 96 000 ₽, итого 576 000 ₽; себестоимость 373 000 ₽, маржа 203 000 ₽, то есть 35,2%. Вторая линейка: база 690 000 ₽, тот же набор опций уже 118 000 ₽ из-за другого крепежа и фильтров, итого 808 000 ₽; себестоимость 529 000 ₽, маржа 279 000 ₽ — 34,5%.

Разница в наборе — 22 000 ₽, и она почти целиком приходится на систему аспирации: 46 500 ₽ в первой линейке против 68 500 ₽ во второй. Если бы цена бралась из общего справочника по первой линейке, каждый второй-третий заказ промышленной серии уходил бы с заниженной на 22 000 ₽ позицией. При 120 заказах в год и доле заказов с аспирацией 55% это 66 сделок и 1 452 000 ₽ недополученной выручки, а при той же себестоимости — и маржи.

Почему цена не должна подставляться молча

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

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

Как наследуются правила совместимости и где их переопределять?

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

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

Полезно вести журнал переопределений: какие правила изменены на уровне линейки или модели, кем и когда. Технолог, который разбирает рекламацию, должен видеть не только «комбинация была разрешена», но и на каком основании.

Как вывести новую линейку, не переписывая конфигуратор?

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

Аудит начинается с вопроса «сколько опций реально общие». Обычно у линеек одного производителя совпадает 55–70% номенклатуры, и именно эта часть даёт основную экономию: заводится один раз и переиспользуется.

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

Сверка идёт на 30–50 реальных заказах: цена в конфигураторе должна совпасть с той, что выставляли вручную, а состав — с фактически отгруженным. Расхождение до 1–2% обычно объясняется округлением, расхождение в 10% означает потерянную скидку или опцию.

По опыту проектов вывод новой линейки на готовом движке занимает 2–4 недели против 6–10 недель при сборке отдельного конфигуратора — оценка зависит от объёма номенклатуры и качества исходных прайсов. Если первая линейка уже описана в конфигураторе на сайте производителя, вторая проходится по той же схеме заметно быстрее.

Как мультилинейный конфигуратор выглядит для дилера?

Для дилера важна не архитектура, а один вход. Он выбирает линейку на первом экране, собирает позиции в общую корзину и отправляет одно КП — даже если в заказе оборудование из двух серий. Второй интерфейс и второй набор условий продажи он воспринимает как проблему производителя.

Скидки при этом остаются разными: матрица по линейкам задаёт базовый уровень, а дилерский уровень добавляет надбавку или скидку поверх. Если условия смешивать в одном поле, при первом пересмотре прайса появляется «средняя» скидка, которая невыгодна либо производителю, либо партнёру.

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

Какие ошибки чаще всего ломают мультилинейный конфигуратор?

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

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

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

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

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

Шестая — отсутствие владельца каталога. Библиотека атрибутов и правила живут дольше любого проекта внедрения; если у них нет ответственного, через полгода каталог снова обрастает дублями.

Как проверить, что движок действительно выдержит каталог?

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

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

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

После запуска стоит смотреть на три метрики: время вывода новой серии, доля КП с ручными правками цены и число обращений «почему здесь такая цена». Первая показывает гибкость движка, вторая — доверие продавцов к расчёту, третья — качество наполнения каталога.

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

Сколько линеек выдерживает один конфигуратор?

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

Нужен ли отдельный конфигуратор для нестандартных изделий?

Обычно нет. Нестандарт описывается теми же атрибутами с расширенными диапазонами и отдельным сценарием «собрать под задачу». Отдельное решение оправдано, если расчёт строится принципиально иначе — например, по метражу и раскрою, а не по составу.

Что делать, если линейки отличаются технологией, а не опциями?

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

Можно ли свести существующие конфигураторы в один?

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

Как быть с разными единицами измерения?

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

Кто должен владеть библиотекой атрибутов?

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

Больше разборов по конфигураторам, калькуляторам и дилерским кабинетам — в блоге WOID. Посмотреть, как устроен конфигуратор с несколькими линейками, можно на странице демо, обсудить свой каталог — на старте проекта, а состав работ и сроки — на странице решений для конфигураторов и в разделе цен.


← К списку статей