Как убрать ручные переносы между замером, договором и цехом, но не превратить CRM в второй учёт производства.
Заявка на кухню приходит в мессенджер. Менеджер договорился о замере, замерщик уточнил материал и размеры, конструктор подготовил проект. В этот момент у клиента уже есть ожидание по сроку. Но у производства свой чат, у менеджера своя таблица, а заказ в 1С появляется позже. Если срок сдвинулся, клиент часто узнаёт об этом последним.
В такой ситуации обычно пытаются "внедрить CRM в производство". Формулировка опасная. Мебельное производство не становится управляемым от того, что все сотрудники получили ещё по одной карточке для заполнения. Сначала нужно договориться, какая запись является заказом, где меняется его статус и кто отвечает за следующий шаг.
Спешите? В FAQ есть прямые ответы: нужна ли отдельная карточка заказа и что оставлять в 1С.
Связывать стоит путь заказа, а не все действия цеха
Прямой ответ на главный вопрос: в CRM имеет смысл связать входящую заявку, расчёт и договорённость с клиентом, заказ на изготовление, его контрольные статусы и передачу результата клиенту. Посменные задания, нормы расхода, складские операции и бухгалтерские документы не нужно переносить в CRM только ради единого окна.
Для клиента весь путь выглядит одной историей. Для компании это несколько разных объектов с разной ответственностью. Заявкой занимается менеджер, замером - замерщик, конструкцией и запуском - производство. Если вести их одной сделкой до монтажа, карточка быстро обрастает полями, которые никто не может корректно поддерживать. Если развести всё по несвязанным таблицам, руководитель перестаёт видеть, что происходит с обещанным заказом.
Рабочая граница обычно такая:
| Участок | Что фиксировать | Кто поддерживает запись |
|---|---|---|
| Обращение и продажа | источник заявки, клиент, потребность, дата замера, расчёт, договорённости | менеджер |
| Заказ на изготовление | состав заказа, версия проекта, плановые даты, текущий контрольный этап, причина остановки | ответственный за заказ или диспетчер производства |
| Производственный учёт | спецификации, материалы, остатки, документы, фактические операции | система учёта и производство |
| Монтаж и закрытие | согласованная дата, задача монтажной бригаде, итог для клиента | менеджер или координатор |
Это не готовая схема для любой фабрики. У компании с серийной продукцией и у производства мебели на заказ будут разные точки передачи. Но принцип один: для каждого изменения заранее названо место, где его вносят один раз.
В Битрикс24 для таких промежуточных сущностей предусмотрены смарт-процессы: у них можно задать собственные поля, воронки, стадии, права доступа и связи с другими элементами. Официальная справка описывает именно этот сценарий. Это техническая возможность, а не ответ на вопрос, какие этапы нужны конкретному цеху.
Сделка и заказ на производство - разные записи
Сделка отвечает на вопрос коммерческого отдела: купит ли клиент, на каких условиях и что ему обещано. Заказ на производство отвечает на другой вопрос: можно ли изготовить согласованный состав в нужный срок и что мешает его передаче дальше.
Пока клиент выбирает фасад, меняет размеры или не внёс предоплату, одной сделки достаточно. Отдельный заказ возникает в момент, который компания сама считает обязательством перед производством. Например, после подписания спецификации и подтверждения оплаты. Главное, чтобы точка появления заказа была однозначной. Нельзя сегодня создавать его после замера, завтра после договора, а послезавтра после сообщения в рабочем чате.
Связь между сделкой и заказом нужна в обе стороны. Менеджер должен открыть карточку клиента и увидеть, что заказ остановлен на уточнении проекта. Производство должно видеть согласованные с клиентом условия, не переписывая их вручную. Но возможность видеть данные не означает право менять их: дату монтажа, согласованную менеджером, не стоит разрешать тихо корректировать в карточке производства без уведомления ответственного.
В CRM-карточке Битрикс24 хранятся поля и история изменений, комментариев, документов и стадий. Карточки можно настраивать и для элементов смарт-процессов, что позволяет собрать историю конкретного заказа рядом с нужными полями. Это подтверждает документация по карточке CRM. Какие поля выводить, решает не интерфейс, а маршрут заказа.
Что должна содержать карточка заказа: условный пример
Ниже не кейс и не шаблон для копирования. Это условная модель заказа корпусной мебели на заказ. Её полезно разобрать на встрече с менеджером, замерщиком и руководителем производства, а затем вычеркнуть поля, которыми никто не пользуется.
Связи: сделка, клиент, контактное лицо, замер, задача конструктору, документы или ссылка на папку проекта.
Данные для работы: номер заказа, тип изделия, адрес монтажа, согласованная версия проекта, плановая дата готовности, плановая дата монтажа, ответственный, причина блокировки.
Контрольные этапы: данные переданы в производство, проверка комплекта, подготовка к запуску, изготовление, готово к монтажу, монтаж назначен, заказ закрыт. На этапе "блокировка" важнее не цвет статуса, а обязательное поле с причиной: ждём клиента, уточняем проект, нет материала, нужна корректировка срока или другая причина, которую компания готова анализировать.
Не превращайте карточку в электронный техпаспорт изделия. Если конструктор обязан внести в CRM полный состав каждой детали, а затем повторить его в учётной системе, он закономерно выберет одну из систем и перестанет обновлять другую. В карточке остаются данные для передачи ответственности и общения с клиентом. Детальная спецификация живёт там, где её действительно считают и используют.
Роли и статусы важнее автоматического перемещения
Статус "в производстве" почти ничего не говорит руководителю. Один заказ ждёт утверждения чертежа, второй уже в раскрое, третий задержан поставщиком. Система не угадает разницу, если сотрудникам разрешено называть эти ситуации одним и тем же словом.
До настройки стадий разберите с командой четыре вопроса:
- Какое событие переводит заказ на следующий этап: утверждение клиента, выпуск задания, поступление материала, фактическая готовность или что-то ещё?
- Кто меняет этап и в какой срок после события?
- Какие данные должны быть заполнены до передачи заказа следующей роли?
- Кто получает сигнал, если заказ остановился или плановая дата меняется?
После этого можно настраивать автоматизацию. Например, при создании заказа из сделки система создаёт задачу замерщику; при заполнении даты готовности уведомляет менеджера; при переводе в блокировку просит указать причину. Автоматизация полезна, когда она закрепляет уже согласованное правило. Она не заменяет правило.
Отдельно договоритесь о том, как сообщать клиенту о переносе срока. Производство может менять внутренний план несколько раз за день. Менеджеру не нужен поток технических уведомлений. Ему нужен сигнал в тот момент, когда изменение уже влияет на обещание клиенту и требует разговора. Это разные события, и в CRM их лучше не смешивать.
Граница с 1С: у каждой системы должна быть своя правда
Связка CRM и 1С становится проблемой не из-за обмена как такового, а из-за двух владельцев одних данных. Если цена редактируется и в сделке, и в 1С, если заказ можно отменить в любой системе, а статусы называются по-разному, расхождения появятся даже при исправной интеграции.
Перед постановкой задачи на обмен зафиксируйте простую матрицу.
| Данные | Основная система | Что получает другая система |
|---|---|---|
| Клиент, обращение, коммуникации, согласованная дата | CRM | ссылка или нужный набор реквизитов в 1С |
| Спецификация, учётные документы, остатки и движение материалов | 1С | статус, номер документа и данные, нужные менеджеру |
| Контрольный статус заказа для клиента | правило компании | обновление в CRM только по согласованным событиям |
Официальный коннектор Битрикс24 с 1С позволяет синхронизировать данные и настраивать автоматизацию, но его состав и границы зависят от выбранного сценария и конфигурации 1С. В справке по началу работы с коннектором приведён пример создания документа в 1С при смене стадии сделки. До разработки обмена проверьте на тестовых заказах, какие поля передаются, кто имеет право их менять и что произойдёт при повторной отправке.
Не обещайте команде "синхронизацию всего". Для мебельного производства обычно достаточно передавать ровно те события, по которым менеджер должен действовать: заказ создан, требуется уточнение, дата изменилась, заказ готов к монтажу. Остальная детализация остаётся в производственном контуре.
Когда CRM лучше не расширять до производства
Иногда отдельный смарт-процесс будет лишним. Если владелец лично ведёт несколько заказов, один сотрудник одновременно продаёт и передаёт их в цех, а у производства нет отдельных ролей и контрольных дат, сначала может хватить сделки с несколькими обязательными полями и общей таблицы планирования. Настройка двух сущностей добавит работу, но не даст нового управленческого решения.
Пауза нужна и в другом случае: команда не может назвать единый момент передачи заказа в производство. Тогда спор о стадиях внутри CRM только зафиксирует текущую путаницу. Сначала проведите разбор одного реального заказа, найдите все передачи в чатах и таблицах, определите владельцев действий. Возвращаться к автоматизации имеет смысл после этого.
Зато отдельная карточка заказа становится оправданной, когда к одной сделке подключаются несколько ролей, срок зависит от производственного этапа, а менеджер регулярно выясняет статус в чате. Здесь CRM не заменяет учёт. Она делает видимым маршрут, который раньше существовал только в головах сотрудников.
Чек-лист: что собрать до настройки CRM для мебельного производства
Пройдите этот список на одном заказе, а не на идеальной схеме на доске. Если на любой пункт нет точного ответа, он станет источником ручных уточнений и после запуска.
- Перечислены все источники заявок и указан ответственный за первичный ответ.
- Названо событие, после которого сделка становится заказом на производство.
- Для каждого этапа заказа есть владелец, допустимый срок и условие передачи дальше.
- Отдельно определено, что считается внутренним изменением плана, а что требует связи с клиентом.
- Есть единая версия проекта или понятная ссылка на место её хранения.
- Для каждого поля обмена с 1С определена основная система и правило изменения.
- Руководитель знает, на какой вопрос должен отвечать отчёт: где заказы остановились, какие сроки изменились или кто ждёт действие.
После такой проверки можно собрать прототип: одну сделку, один заказ, несколько реальных этапов и минимальный обмен с учётной системой. Только затем расширять схему. Это скучнее, чем сразу рисовать большую воронку, зато команда быстрее замечает дублирование и спорные статусы.
Короткие ответы на частые вопросы
01Можно вести заказ на производство прямо в сделке?
Можно, если путь заказа короткий и его не ведут разные роли. Когда в сделке появляются замер, проект, производство и монтаж с отдельными ответственными, она перестаёт показывать коммерческую ситуацию. Тогда связанный заказ помогает разделить работу без потери истории клиента.
02Нужно ли переносить в CRM спецификацию и учёт материалов?
Нет, если эти данные уже корректно ведутся в 1С или другой производственной системе. В CRM оставьте ссылку на актуальный документ, контрольные даты и данные, которые нужны для обещаний клиенту. Дублировать полный состав изделия имеет смысл только при понятной причине и назначенном владельце обеих записей.
03Кто должен менять статусы производства?
Тот, кто видит факт наступления этапа и может отвечать за точность записи. Иногда это мастер участка, иногда диспетчер. Менеджер не должен угадывать готовность заказа по сообщениям коллег и обновлять карточку задним числом.
04Можно ли начать без интеграции с 1С?
Можно, если сначала нужно наладить маршрут заявки и передачу заказа между людьми. В этом случае зафиксируйте ручное правило: где сотрудник проверяет данные 1С и в какой момент обновляет контрольный статус в CRM. Интеграцию добавляйте после того, как станет понятно, какие конкретно данные должны передаваться автоматически.
05Как понять, что процесс настроен правильно?
Проведите через него несколько настоящих заказов и сравните карточку с тем, что происходит в работе. Руководитель должен без звонков в цех увидеть ответственного, текущую остановку и дату, на которую можно ориентировать клиента. Если для ответа всё ещё нужен чат, схема не дошла до нужного места.
CRM для мебельного производства нужна не для того, чтобы загрузить цех ещё одной программой. Её задача проще: связать обещание клиенту с моментом, когда заказ передаётся между людьми, и показать руководителю причину остановки до того, как она превратится в конфликт по сроку.
Неясно, где у вас рвётся путь заказа? На разборе процесса можно пройти один заказ от первого обращения до монтажа, отметить ручные переносы между таблицами, чатами и 1С, а затем определить минимальную схему CRM без дублирования производственного учёта.
