Учёт заказов на производстве: граница между CRM и 1С и где на ней теряются деньги

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

Деньги теряются на стыке, а не в отсутствии системы

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

Цена вопроса считается. Возьму иллюстративный расчёт: 300 заявок в месяц, потеря 12% — это 36 обращений, средний чек 80 000 ₽, конверсия 30%. На таких вводных производство недополучает около 864 000 ₽ выручки в месяц (расчёт по открытой методике вендора, привожу как иллюстрацию механики, не как клиентский кейс). Это не абстрактная «неэффективность» — это конкретные обращения, которые не дошли до менеджера, и деньги, которые не вошли в цех.

Что ведёт CRM, что остаётся в 1С

Границу я провожу по денежным задачам, которые каждая система закрывает.

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

В учётной системе (1С) остаются план цеха и загрузка оборудования, учёт сырья и материалов, склад, себестоимость и регламентированная отчётность. Это ответ на вопрос «сможем ли выполнить точно, прибыльно и в срок».

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

Точка передачи: где сделка уходит в цех

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

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

Что ломается при ручном переносе

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

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

Почему прогноз выручки без связки врёт

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

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

Где граница размыта: позаказное производство

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

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

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