CRM для производства и завода: порядок в заказах

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

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

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

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

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

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

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

На производстве CRM почти никогда не работает в одиночку: рядом стоит учётная система, чаще всего 1С, а иногда ещё и складская или цеховая программа. Вопрос не в том, интегрировать или нет, а в том, какие данные и в какую сторону ходят. Мы всегда начинаем с этой схемы, потому что именно в ней прячется основная трудоёмкость проекта, а вовсе не в настройке воронки.

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

Отдельно про честность в оценке. Объём интеграции зависит не от нашего желания, а от того, какие интерфейсы обмена есть у ваших систем: у типовой конфигурации 1С один разговор, у самописной доработанной за десять лет — совсем другой. Поэтому обмен мы всегда смотрим первым делом на аудите. Там же решаем, что делать с данными, которые не переносятся автоматически. Технически такие связки — это заказная разработка поверх CRM: обмен между системами по API, чтобы данные не переносили руками, и отдельные рабочие интерфейсы там, где стандартных экранов не хватает.

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

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

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

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

Когда признаки совпадают, проект перестаёт быть настройкой и становится разработкой со всеми её атрибутами: разбор процессов, техническое задание, этапы, тестирование, обучение. Похожий путь мы проходим в собственном продукте — МИС, медицинской информационной системе, которую строим с нуля, а не по заказу клиента: цель была не подгонять готовую коробку, а получить собственный продукт на управляемом стеке. Перед проектированием разобрали систему-аналог — 1613 таблиц базы данных и 1029 роботов, — собрали техническое задание на 1619 требований и вышли на MVP с рабочими местами под роли, мультиарендностью через механизм разделения данных RLS в PostgreSQL и контуром под 152-ФЗ. Честно про статус: это MVP, а не многолетний прод, и мы предпочитаем называть вещи своими именами. Отрасль другая, но механика та же — так же проектируется отраслевая система под производство, где несколько площадок работают в одном контуре с разделением данных.

Есть и промежуточный путь, который на практике выбирают чаще всего: ядро остаётся на готовой CRM, а сверху достраивается то, чего в ней нет. Кабинет дилера или заказчика со статусом заказа и документами, терминал мастера на участке, обмен с 1С, расчётный модуль под ваше изделие. Такая надстройка работает на тех же данных, поэтому статус в кабинете и статус в CRM — одна и та же запись, а не две базы, которые надо синхронизировать по ночам.

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

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

И про честные границы нашего опыта. Ближайший к теме публичный проект у нас — миграция CRM мебельного производства, которое делает кухни, с Bitrix24 на self-hosted EspoCRM. Мы провели аудит REST исходной системы и спроектировали структуру: 10 объединённых стадий двух воронок, 22 источника и 66 кастомных полей. Затем перенесли со сверкой 1:1 45 компаний, 2217 контактов, 1541 лид и 668 сделок, а историю общения свели в 2584 записи таймлайна. WhatsApp подключили прямо в CRM через технического пользователя-мост, чтобы переписка с заказчиками оставалась в системе. Честно про статус: перенос файлов и настройка автоматизации ещё в работе, они упираются в ограничения выгрузки из Bitrix24, — проект в фазе внедрения, а не финального релиза.

Знакомство устроено просто: полчаса бесплатного экспресс-аудита без презентаций. За это время проходим по четырём точкам — где сейчас живёт спецификация, кто и как отмечает готовность на участках, откуда берётся дата отгрузки, которую называют клиенту, и что происходит при изменении заказа. На выходе вы получаете вывод, а не коммерческое предложение. Иногда вывод звучит так: вам хватит навести порядок в спецификациях и стадиях на текущей системе, полноценное внедрение пока не нужно. Стоимость работ называем после разбора, когда виден объём процессов, интеграций и доработок. Лицензии платформы считайте отдельной строкой: у Битрикс24 прайс открытый — при оплате за год «Базовый» на 5 пользователей стоит 1 743 ₽/мес, «Стандартный» на 50 — 4 893 ₽/мес, «Профессиональный» на 100 — 9 793 ₽/мес, «Энтерпрайз» от 250 пользователей — от 23 793 ₽/мес, есть и бесплатный тариф без ограничения по числу сотрудников. На эти цифры мы не влияем, и в стоимость работ по внедрению они не входят.