К содержимому журнала

CRM системы

Заказ в производство из Битрикс24: как передать спецификацию и изменения

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

Терракотовая деталь проходит через керамическую арку между ступенями: передача утверждённого задания в производство.
Содержание

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

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

Что передавать вместе с заказом #

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

ДанныеКто подтверждаетЧто проверяет принимающая сторона
Состав и количествоМенеджер и заказчикОднозначность позиций и единиц
Чертёж или макетТехнолог по согласованной процедуреВерсию, комплектность, применимость
СрокПроизводственный ответственныйВозможность выполнения, зависимости
Требования к качествуНазначенный специалистМетод контроля и документы приёмки
Адрес и состав отгрузкиЛогистикаГотовность партии и ограничения доставки

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

Между продажей и запуском нужен этап приёмки #

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

В карточках CRM можно настраивать обязательность полей по стадиям ; доступность зависит от тарифа. Это помогает не пропустить пустое поле, но не проверяет инженерный смысл вложения. Обязательная ссылка на чертёж не доказывает, что технолог принял именно эту ревизию. Для этого нужно отдельное подтверждение.

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

Как жить с изменениями после запуска #

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

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

example.jsonJSON
{
  "production_order": "work-order-731",
  "approved_revision": "rev-03",
  "change_request": {
    "requested_revision": "rev-04",
    "reason": "material_replacement",
    "decision": "awaiting_technologist"
  }
}

Пример показывает внутреннюю модель решения, а не готовый REST-запрос. Важно не имя поля, а запрет незаметной подмены принятого задания. Отклонённое изменение сохраняют в истории; подтверждённое связывают с новой версией, оценкой срока и затронутой партией.

Где заканчивается CRM и начинается учёт производства #

Битрикс24 удобен для взаимодействия с клиентом, согласования готовности и контроля ответственности. Детальное планирование операций, материалов и себестоимости может оставаться в 1С:ERP или другой производственной системе. Наличие канбана не превращает CRM в систему расчёта загрузки оборудования.

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

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

Что нужно проверить перед запуском схемы #

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

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

Нужно отдельное направление сделок «Производство»? #

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

Можно разрешить менеджеру менять чертёж в работающем заказе? #

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

Поможем настроить передачу заказов #

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

Был ли материал полезен?

0 полезных · 0 неполезных · 0 оценок

Голосование временно недоступно: подключаем безопасную идентификацию читателя.