Менеджер собирает оборудование из нескольких прайсов, уточняет совместимость у инженера и вручную переносит результат в коммерческое предложение. Клиент меняет одну опцию — расчёт повторяется. Ошибка может остаться незаметной: сумма выглядит верно, но в комплекте нет обязательного компонента.
Конфигуратор помогает выбрать допустимый состав по установленным правилам и связать его с расчётом. Это больше, чем калькулятор суммы. Для разработки нужно описать варианты оборудования, ограничения, источники цен и условия передачи результата клиенту.
Отделите конфигурацию от расчёта цены
Конфигурация отвечает на вопрос, может ли выбранный комплект выполнять согласованную задачу. Расчёт определяет стоимость допустимого состава по выбранным условиям.
Цена не должна исправлять техническую ошибку. Если два компонента несовместимы, добавление скидки не делает комплект пригодным. И наоборот, технически допустимый состав может требовать отдельного коммерческого согласования.
Промежуточный результат полезно разделить на состав, проверку правил, расчёт и статус предложения. Тогда понятно, на каком шаге возникло ограничение и кто должен принять решение.
Не переносите в конфигуратор инженерные расчёты без подтверждённой модели и проверки профильным специалистом. Программа применяет утверждённые правила, но сама по себе не доказывает правильность этих правил.
Начните с одной группы оборудования
Выберите семейство с повторяющимися опциями и понятным владельцем правил. Для каждого изделия соберите обязательные компоненты, варианты исполнения, ограничения сочетаний и типовые дополнительные услуги.
Особенно полезны ранее согласованные примеры: простой комплект, комплект с дополнениями и вариант, который инженер отклонил. Они позволяют проверить, одинаково ли команда понимает правила.
Не начинайте с обещания охватить весь ассортимент. У разных товарных групп могут быть разные способы подбора, а единый список флажков только скроет различия.
Назначьте владельца изменений. Если ассортимент обновляется, кто подтверждает новое правило и с какой даты оно применяется? Без этого даже правильно разработанный сервис быстро начинает выдавать устаревший состав.
Условный пример: измерительный шкаф
Рассмотрим вымышленное семейство измерительных шкафов. Это упрощённый учебный пример, не инструкция по проектированию реального оборудования и не кейс ExtentLab.
Корпус имеет восемь условных мест. Базовый блок занимает два, каждый измерительный модуль — одно, модуль связи — одно. Клиент выбирает четыре измерительных модуля и связь: всего занято семь мест.
Пятый измерительный модуль занимает последнее место. Шестой уже не помещается: два плюс шесть плюс один дают девять. Конфигуратор должен объяснить ограничение и предложить только предусмотренные правилами варианты, например другой корпус.
Допустим также, что для выбранного исполнения предусмотрен обязательный дополнительный элемент. Он должен входить в состав автоматически либо требовать явного подтверждения. Его нельзя забыть только потому, что клиент не поставил отдельный флажок.
Цены в этом примере не задаются: корректность состава проверяется независимо от стоимости.
Запишите правила в понятной форме
Правило должно содержать условие, действие и объяснение. «Если выбрано исполнение для определённого режима, добавить предусмотренный компонент» понятнее разрозненного комментария в прайсе.
Разделите виды правил:
- обязательность компонента;
- несовместимость двух вариантов;
- ограничение общего ресурса;
- зависимость количества;
- доступность опции для конкретной модели;
- необходимость рассмотрения специалистом.
Не все исключения нужно автоматизировать сразу. Для редкого сложного варианта можно предусмотреть статус «требуется инженерная проверка». Но это должно быть отдельное состояние, а не молчаливо сформированное окончательное предложение.
Пользователь должен понимать, какое поле исправить и почему. Сообщение «ошибка конфигурации» без указания причины возвращает его к звонку инженеру.
Свяжите цены с версиями и условиями
У расчёта должны быть известны источник цен, дата действия и применённые условия. Если прайс обновился после подготовки предложения, старый документ не должен незаметно пересчитаться.
Разделите стоимость компонентов, дополнительных работ и других согласованных составляющих. Не прячьте обязательные расходы в свободном комментарии, который легко потерять при копировании.
Скидки и индивидуальные условия требуют полномочий. Например, менеджер может подготовить предварительный расчёт, а отклонение от стандартного правила направляется руководителю. Конкретные пределы определяет компания; универсальные проценты здесь не нужны.
Если цена компонента отсутствует, ноль не является безопасной заменой. Предложение должно получить понятное ограничение до подтверждения цены.
Сохраните согласованный состав
Коммерческое предложение должно ссылаться на конкретную версию конфигурации. Иначе клиент и инженер могут обсуждать документы с одинаковым номером, но разными опциями.
При изменении состава после согласования зафиксируйте, что изменилось и какие решения нужно повторить. Смена декоративного обозначения и замена функционального компонента могут требовать разной проверки.
Для передачи в исполнение определите, какие сведения обязательны: идентификаторы компонентов, количества, вариант исполнения, версия правил и принятые исключения. Красивый файл без структурированного состава может оставить ручной ввод на следующем этапе.
Сценарии первой версии и исключения
Первая версия должна провести пользователя от параметров до проверяемого предложения хотя бы для одной группы. Подготовьте следующие испытания:
- допустимый типовой комплект;
- запрещённое сочетание опций;
- заполнение ресурса ровно до границы;
- превышение границы;
- обязательное дополнение;
- отсутствующая цена;
- устаревший прайс;
- изменение уже согласованного комплекта.
Ожидаемый состав каждого примера утверждает владелец правил. Нельзя проверять конфигуратор только сравнением с результатом, который он сам вычислил.
Добавьте повторное открытие сохранённого предложения. Пользователь должен увидеть его прежние условия либо явное предложение пересчёта, а не незаметно изменившийся результат.
Когда достаточно готового решения
Готовый конфигуратор может подойти, если поддерживает нужные ограничения, версии и передачу состава. Проверьте его на самых важных исключениях, а не только на сборке красивой демонстрационной модели.
Если вариантов мало и расчёты стабильны, может хватить управляемого шаблона с проверками. Собственная разработка становится обоснованной, когда сложность правил, связи с другими системами или рабочий маршрут не укладываются в готовые возможности.
Не нужно разрабатывать универсальный движок правил ради одного семейства. Для начала важнее доказать, что выбранная модель описывает реальные комплекты и остаётся понятной сотрудникам, которые будут её поддерживать.
Проверьте изменение правил после запуска
Конфигуратор живёт вместе с ассортиментом. Для новой опции нужно определить автора изменения, проверяющего и дату применения. Полезно сохранить набор эталонных комплектов и повторять его после обновления правил.
Если новая версия запрещает сочетание, которое раньше продавалось, это не повод незаметно изменить старое предложение. Определите, относится ли ограничение только к новым расчётам или требует отдельного разбора действующих заказов.
Проверьте объяснение изменений для менеджера. Он должен понимать, почему привычный вариант больше не доступен и к кому обратиться по исключению. Иначе сотрудники начнут собирать предложения вне сервиса.
Отдельно контролируйте доступность комплектующих и техническую допустимость. Компонент может подходить по правилам, но отсутствовать в нужный срок. Если сроки не входят в первую версию, обозначьте границу явно, чтобы корректная конфигурация не воспринималась как подтверждённое обещание поставки.
Чеклист перед оценкой разработки
- Определена первая товарная группа и владелец правил.
- Есть примеры допустимых и недопустимых комплектов.
- Совместимость отделена от коммерческого расчёта.
- Обязательные компоненты включены явно.
- Неизвестная цена не заменяется нулём.
- Согласованы версии состава и прайса.
- Для исключений назначен проверяющий.
- Понятен состав передачи в исполнение.
- Проверено подходящее готовое решение.
В ExtentLab можно прийти с одним изделием, несколькими вариантами комплектации и текущим расчётом. По ним предметно обсуждают логику конфигуратора и объём первой версии, не обещая универсальную систему до изучения правил.