CRM для производства: что должна уметь система, когда сделка — это заказ в цех

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

Ниже разобрано, где обычная CRM ломается на производстве и в B2B-продажах. Чем производственная сделка отличается от торговой и что происходит с ней после оплаты. Как считать цену и срок в КП, не дёргая технолога, и как менеджеру видеть статус заказа в цеху. Как связать CRM с 1С и ERP и какая система какими данными владеет. Как вести долгий цикл повторных заказов с одним контрагентом и по каким признакам видно, что система не справляется. В конце — что нужно подготовить до старта и почему коробка закрывает здесь только часть задачи. Выбор CRM в целом и устройство производственного контура разобраны отдельно, в статьях как выбрать CRM и ERP для производства; здесь речь про стык продаж и цеха.

Чем CRM для производства отличается от обычной?

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

Типовая воронка выглядит так: заявка, квалификация, коммерческое предложение, счёт, оплата. Для торговли этого хватает: товар лежит на складе, цена стоит в прайсе, срок равен доставке. На производстве на каждом шаге вопрос уходит за пределы отдела продаж. Что именно заказывает клиент, определяет спецификация, иногда новая под этот заказ. Цена зависит от материалов и операций, срок — от того, чем сейчас занят цех.

После оплаты начинается самая долгая часть: запуск, закупка материалов, изготовление, контроль качества, отгрузка, документы. Клиент всё это время звонит менеджеру, потому что договаривался с ним. Если CRM на оплате заканчивается, менеджер отвечает клиенту со слов начальника цеха.

Разрыв между продажами и производством виден и в государственной статистике. По сборнику «Индикаторы цифровой экономики: 2025» ИСИЭЗ НИУ ВШЭ, Минцифры и Росстата (таблица 12.6, данные за 2023 год) по строке «Обрабатывающая промышленность» ERP-системы используют 38,2% организаций, CRM-системы — 27,2%. В оптовой и розничной торговле картина другая: CRM у 37,8% организаций, ERP у 37,6%. Программы для управления продажами товаров, работ и услуг на предприятиях обработки есть у 39,7% организаций, больше, чем CRM. Судя по разнице цифр, часть заводов ведёт продажи в отдельных программах, а не в CRM.

На заводе учёт и производство автоматизируют раньше продаж, и CRM, если она есть, часто живёт отдельно от учётного контура. Производственные компании при этом заметная часть пользователей CRM. В опросе J'son & Partners Consulting, проведённом вместе с Битрикс24 и опубликованном в журнале вендора 19 августа 2026 года (1000 компаний, ноябрь 2025 — январь 2026), производство составило 13% выборки, второй сегмент после торговли с 26%.

Что происходит со сделкой после оплаты?

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

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

Больше всего проблем приносит версия спецификации. Изменение, пришедшее до запуска, стоит переписки. Изменение посреди изготовления стоит материала, переналадки и сдвига срока, и клиенту об этом надо сказать до отгрузки. Поэтому CRM на производстве делает следующее:

• Хранит согласованную версию спецификации с датой, автором и способом согласования. Спор «мы же договорились по-другому» решается по карточке заказа.
• Передаёт заказ в учёт одной операцией. Позиции берутся из справочника 1С или ERP, и заказ уходит в производство без перебивки руками.
• Принимает изменения как новую версию. Видно, на каком этапе изготовления пришло изменение, кто его одобрил и как изменились цена и срок.
• Делит заказ на отгрузки и оплаты. Предоплата, оплата по готовности, частичная отгрузка и постоплата привязаны к этапам заказа.
• Хранит закрывающие документы. Акты, накладные, сертификаты и паспорта изделий лежат при заказе, и их не ищут по почте через год.

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

Как считать цену и срок в КП, не дёргая технолога?

Коротко: цену собирают из норм расхода и операций, которые уже лежат в 1С или ERP, а срок — из наличия материалов и загрузки участков. Технолог нужен там, где изделие новое.

Производственные запросы обычно делятся на три типа, и расчёт для них устроен по-разному:

1. Серийное изделие из каталога. Цена считается по нормативной себестоимости плюс наценка, срок — по стандартному циклу и текущей очереди. Расчёт делает система, менеджер проверяет и отправляет.
2. Исполнение на базе типового. Другой размер, материал, покрытие, комплектация. Параметры вносятся в конфигуратор, и правила собирают из них спецификацию и маршрут, а цена пересчитывается сама. Правила один раз описывает технолог, дальше он в каждом КП не участвует.
3. Новое изделие. Запрос уходит конструктору или технологу задачей внутри CRM со сроком ответа. Менеджер и клиент видят, что КП ждёт расчёта и до какого числа.

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

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

В КП фиксируются дата расчёта и версия норм и цен, по которым оно посчитано. Цены на металл и покупные изделия меняются, и при повторном запросе через полгода видно, что именно подорожало. Само КП собирается из данных системы по шаблону, без ручного копирования таблиц в документ; так же устроено решение «Авто-документы» из каталога.

Как менеджеру видеть статус заказа в цеху?

Коротко: статус приходит из той системы, где производство отмечает выполнение — ERP, MES или простого терминала мастера, — и CRM показывает его менеджеру и клиенту без звонка в цех.

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

Источник статуса зависит от того, что есть на заводе. Если производственные заказы ведутся в ERP, CRM читает из неё этапы: запущен, материалы выданы, операция выполнена, контроль пройден, принято на склад. Если есть MES, статус приходит почти в реальном времени. Если нет ни того ни другого, этапы отмечает мастер кнопкой в боте или на планшете у участка. Как устроены такие боты для сотрудников вне офиса, разобрано в статье «Чат-боты для бизнеса».

Третий вариант встречается чаще, чем кажется по презентациям. Совет по развитию цифровых технологий для промышленности АПКИТ при содействии Минпромторга опросил с ноября 2025 по февраль 2026 года 39 предприятий станкостроения и инструментального производства. По результатам, опубликованным 4 мая 2026 года, решения для управления основным производством в реальном времени используют 10% опрошенных предприятий, а 41% опираются преимущественно на ручной труд с минимальной автоматизацией. Выборка небольшая и отраслевая, на всю промышленность её не перенести. Более широкий срез даёт та же таблица 12.6 сборника ВШЭ: программы для управления автоматизированным производством и технологическими процессами есть у 28,9% организаций обработки. Где нет ни такой программы, ни производственных заказов в ERP, статус начинается с отметки человека, и делать её надо так, чтобы она занимала секунды.

Менеджеру и клиенту не нужны все операции маршрута. Хватает пяти-шести понятных статусов: принят в работу, материалы обеспечены, в изготовлении, готов, отгружен. Важнее статусов отклонения. Если материал не пришёл к дате запуска или операция отстаёт от плана, менеджер получает сигнал и звонит клиенту первым, до того как клиент позвонит сам. В проекте для оптово-производственной компании клиенты видят цены своего договора, статусы заказов и документы в личном кабинете.

Как связать CRM с 1С и ERP?

Коротко: у каждого вида данных одна система-владелец, остальные его читают. Номенклатура, нормы, цены материалов, остатки, производственные заказы и деньги живут в 1С или ERP; клиенты, контакты, сделки и переписка — в CRM.

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

Технически у 1С для обмена есть штатные механизмы: платформа «1С:Предприятие» автоматически формирует REST-интерфейс по протоколу OData для всего прикладного решения, а для нестандартных сценариев есть HTTP-сервисы. Сам канал обмена — меньшая часть работы. Больше времени уходит на правила: что делать, если позиция в CRM уже есть, а в 1С её удалили; как обработать заказ, если учётная система недоступна; кто разбирает конфликт, когда реквизиты в двух системах разошлись. Подробно способы связать системы разобраны в материале про интеграцию систем.

Связка с 1С для российского рынка CRM — основной сценарий. В том же опросе J'son & Partners каждая пятая компания, 20%, ведёт продажи в 1С:CRM, то есть на той же платформе, что и учёт. Битрикс24 в нём используют 49% компаний, amoCRM — 9%; поправка на источник обязательна: опрос проводили вместе с Битрикс24, и цифры показывают распространённость среди опрошенных, а не долю рынка. CRM на платформе 1С снимает часть обмена, потому что справочники у неё общие с учётом. Правила расчёта КП, статусы производства и исключения конкретного завода всё равно настраиваются отдельно.

Учётный контур на многих заводах сейчас и сам перестраивается. По сообщению Интерфакса от 28 февраля 2026 года, правительство обновило стратегическое направление цифровой трансформации промышленности (распоряжение от 26 февраля 2026 года № 378-р). К 2030 году не менее 80% предприятий обработки должны перейти на отечественный софт в системах для основных производственных и управленческих процессов. Если завод меняет учётную систему, интеграцию CRM разумно проектировать под новый контур сразу, чтобы не переделывать её через год. О том, как не потерять при этом клиентскую базу и не наплодить дублей, написано в статье «Клиентская база в CRM».

Как вести повторные заказы и долгий цикл с одним клиентом?

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

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

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

• Договор и цены договора. КП по повторному заказу считается по ним без поиска в почте.
• История заказов со спецификациями. Новый заказ создаётся копией прошлого и пересчитывается по текущим нормам и ценам, а разница с прошлой ценой видна сразу.
• Рекламации и их причины. Привязаны к заказу и партии, поэтому при следующем запуске технолог видит, что уже шло не так.
• Ритм заказов. Если клиент заказывает раз в квартал и пропустил срок, менеджер получает задачу связаться. Это дешевле, чем узнать через полгода, что клиент ушёл к конкуренту.

Для рамочных договоров CRM ведёт лимиты и заявки внутри них: сколько выбрано, сколько осталось, какие отгрузки запланированы. Собственнику по такой базе видно, какие контрагенты держат загрузку завода и у кого падает частота заказов. Как вывести эти цифры на один экран, разобрано в статье «Дашборд собственника».

Как проверить, что CRM справляется с производственной сделкой?

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

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

С чего начать?

Коротко: с описания одного типового заказа от запроса до отгрузки. По нему становится видно, какие данные CRM должна получать из учёта и производства, и большая часть подготовки делается силами самого завода.

1. Описанный путь заказа. Этапы от запроса до закрывающих документов, кто отвечает на каждом, где принимаются решения о цене, сроке и изменениях. Описывают реальный путь, со всеми обходами через почту и мессенджеры.
2. Справочник номенклатуры в порядке. Одна позиция — одна карточка, спецификации с версиями. Если справочник в учёте грязный, CRM, подключённая к нему, унаследует дубли. Почему производственные проекты чаще всего спотыкаются именно здесь, разобрано в статье про ERP для производства.
3. Правила расчёта цены. Какие нормы считаются действующими, откуда берутся цены материалов и ставки участков, какая минимальная маржа, кто согласует скидку выше порога. Решение принимает бизнес, а разработчик переносит его в систему.
4. Доступ к учётной системе. Технический пользователь в 1С или ERP, права на чтение и запись, тестовая база для проверки обмена. Без тестовой базы первая же ошибка обмена попадает в боевой учёт.
5. Источник статусов. Где производство отмечает выполнение: в производственных заказах ERP, в MES или пока нигде. В последнем случае до старта решают, кто и чем будет отмечать этапы.
6. Матрица прав. Кто видит себестоимость, кто маржу, кто цены договоров чужих клиентов, что видит клиент в личном кабинете. Список ролей проще составить до разработки, чем исправлять после.
7. Владелец после запуска и сопровождение. Сотрудник, который отвечает за справочники и правила расчёта, и договорённость о поддержке системы. Нормы, цены материалов и состав изделий меняются, и без владельца расчёт КП через полгода начнёт врать.

Первые три пункта не требуют бюджета на разработку и сами по себе дают заметную часть результата. Они же объясняют, почему стоимость CRM для производства нельзя назвать по телефону: её определяют число интеграций, глубина расчёта КП и количество исключений в вашем процессе. Если CRM уже куплена и не прижилась, причины чаще лежат в процессе, чем в программе; они разобраны в статье «Почему CRM не приживается».

Коробка или система под свой процесс?

Коротко: готовая CRM закрывает воронку и коммуникации. Расчёт КП по нормам, передачу заказа в учёт и статусы из цеха приходится собирать под справочники, права и исключения конкретного завода.

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

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

Рабочим вариантом часто оказывается гибрид. Учёт остаётся в 1С, а участок, который определяет деньги и сроки, строится отдельно и связывается с учётом обменом данных. В проекте для оптово-производственной компании так и сделано. Заказы из почты, мессенджеров и личного кабинета сводятся в одну очередь, резервы ставятся по реальным остаткам, а дефицит по заказам превращается в заявки на закупку и производство. Номенклатура, остатки, отгрузки и оплаты синхронизируются с 1С в обе стороны. Обработка заказа сократилась с часов до минут.

Мы в INCUBE AI делаем и то, и другое. Типовые задачи закрывают готовые решения из каталога, каждое адаптируется под процесс заказчика. Когда нужна связка продаж с производством, собираем её как заказную разработку: расчёт КП по вашим нормам, передача заказа в учёт, статусы из цеха, личный кабинет клиента и обмен с 1С или ERP. Работаем по договору, данные остаются в РФ, после сдачи сопровождаем систему. Если менеджеры до сих пор узнают цену и срок у технолога, расскажите о задаче: разберём один ваш заказ от запроса до отгрузки и оценим по нему объём работ.

Источники и ссылки

• ИСИЭЗ НИУ ВШЭ, Минцифры России, Росстат. «Индикаторы цифровой экономики: 2025», статистический сборник — таблица 12.6 «Использование специальных программных средств в бизнес-процессах организаций по видам экономической деятельности: 2023», в процентах от общего числа организаций. Строка «Обрабатывающая промышленность»: ERP-системы 38,2%, CRM-системы 27,2%, программы для управления продажами товаров, работ, услуг 39,7%, программы для управления автоматизированным производством и технологическими процессами 28,9%. Строка «Оптовая и розничная торговля»: CRM 37,8%, ERP 37,6%
• J'son & Partners Consulting: как компании выбирают CRM в 2026 году, журнал Битрикс24, 19 августа 2026 года — опрос 1000 компаний, проведён вместе с Битрикс24, ноябрь 2025 — январь 2026: производство 13% выборки, торговля 26%; распространённость среди опрошенных: Битрикс24 49%, 1С:CRM 20%, amoCRM 9%
• АПКИТ, 4 мая 2026 года. Исследование ИТ в станкостроении и инструментальном производстве — опрос 39 предприятий с ноября 2025 по февраль 2026 года при содействии Минпромторга: решения для управления основным производством в реальном времени у 10%, преимущественно ручной труд у 41%
• Интерфакс, 28 февраля 2026 года — обновление стратегического направления цифровой трансформации промышленности: к 2030 году не менее 80% предприятий обработки переходят на отечественный софт в системах для основных производственных и управленческих процессов, 95% в компаниях с госучастием больше 50%
• Распоряжение Правительства РФ от 26 февраля 2026 года № 378-р, «Гарант» — изменения в распоряжения правительства № 1512-р (2020 год) и № 3113-р (2023 год)
• REST-интерфейс и HTTP-сервисы, сайт платформы «1С:Предприятие 8» — штатные механизмы обмена с внешними системами, автоматический REST-интерфейс по протоколу OData