Заказное производство: что ИИ-продавец фиксирует до расчёта

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

До расчёта ИИ-продавец фиксирует исходные данные заказа: параметры изделия, источники, версии чертежа и открытые вопросы. Он не подтверждает допуски, материал и не замораживает редакцию. Готовность к оценке наступает, когда спецификация имеет применимую версию, а все открытые параметры закрыты ответственными сотрудниками.

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

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

Спецификация как версия, а не как файл в переписке

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

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

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

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

Три редакции одного чертежа и что с ними делать

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

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

Здесь появляется неприятный, но честный вопрос: кто имеет право объявить редакцию замороженной. Это не менеджер, который хочет быстрее отправить цену, и не ИИ, который «уверен». Это ответственный сотрудник, чья роль описана в процессе. ИИ-продавец может собрать редакции, подсветить расхождения между ними и задать вопрос, но заморозка — действие человека с полномочиями.

Открытые параметры: материал, допуски, образец

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

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

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

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

Согласование картинки не равно разрешению производства

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

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

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

Форма рабочего объекта: что должно читаться без переслушивания звонка

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

Форма не обязана быть красивой. Она обязана быть однозначной: два сотрудника, открыв объект, должны прийти к одному выводу о готовности. Если для этого нужно переслушать звонок, объект не работает.

Где ИИ-продавец помогает, а где останавливается

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

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

Изменение после запуска: самый дорогой сценарий

Условный эпизод. Спецификация заморожена, заказ запущен, клиент звонит и просит изменить толщину. Если процесс не различает «изменение до заморозки» и «изменение после запуска», менеджер просто правит поле. В производстве при этом уже есть заготовки под прежний размер.

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

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

Интерфейс для сотрудника: что видно на одном экране

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

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

Неизвестный материал, чужой эскиз и изменение размеров

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

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

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

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

Проверка перед запуском: тесты процесса, а не демонстрация

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

Тест считается пройденным не тогда, когда система показала красивый статус, а когда два разных сотрудника независимо пришли к одному выводу о готовности заявки.

Практикум: разбор заявки на кронштейн

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

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

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

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

Что закрепить в процессе, прежде чем включать ИИ

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

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

Соседний вопрос разобран отдельно: Несколько вариантов КП в одной сделке: что должен помнить ИИ. Здесь основной предмет — готовность индивидуальной спецификации к оценке и заморозка редакции; не стандартный товар и не варианты КП.