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