Почему расчёт заказа застревает между менеджером и инженером

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

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

Где теряется время

Если разложить один запрос по шагам, обычно выходит пять передач:

1. Менеджер получает запрос и видит, что данных для подбора не хватает.
2. Инженер задаёт уточняющие вопросы, менеджер пересылает их клиенту и ждёт ответа.
3. Инженер подбирает состав и проверяет совместимость узлов.
4. Менеджер переносит состав в КП, считает цену и согласует скидку.
5. Клиент просит изменить параметр, и проверка совместимости начинается заново.

На каждой передаче запрос стоит в чужой очереди. Инженер занят текущим проектом, руководитель согласует скидку к вечеру, клиент отвечает на следующий день. Даже если подбор занимает час, путь до КП растягивается на дни.

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

Почему правила живут в головах

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

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

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

Что меняется, когда ограничения записаны

Когда правила совместимости вынесены из опыта инженера в систему, работа делится иначе:

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

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

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

Проверка: где застревает ваш расчёт

Возьмите последние десять КП и ответьте на вопросы. Ответы покажут, есть ли смысл записывать правила.

1. Сколько составов инженер подбирал заново, хотя похожий уже был?
2. Сколько раз клиент менял параметры после первого КП и сколько дней занял каждый повтор?
3. Может ли менеджер без инженера сказать, допустимо ли сочетание двух опций?
4. Есть ли записанный список запрещённых сочетаний, или он существует только в опыте сотрудников?
5. Совпадут ли КП двух менеджеров по одинаковому запросу?
6. Где фиксируется, почему инженер разрешил нестандартный вариант?

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

С чего начать

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

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

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

Посмотреть сценарий

Продолжение темы: От требований клиента до спецификации и КП: как работает конфигуратор оборудования.

Источники и границы примера

• Конфигурация по ограничениям
• Управление производством

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