Отчёты в Битрикс24 для производства: что видно сразу, а что придётся собирать

О чём на самом деле спрашивают

Вопросы у производственников повторяются от компании к компании.

• На каком этапе конкретный заказ прямо сейчас и кто за него отвечает.
• Успеваем ли к обещанной дате и по каким заказам уже опаздываем.
• Сколько заказов в работе одновременно и не перегружен ли участок.
• Что сдвинулось с прошлой недели и по чьей вине — снабжение, цех, согласование с клиентом.

Ни на один из этих вопросов воронка продаж не отвечает. Она заканчивается там, где производство начинается: сделка закрыта, оплата получена, а самое интересное для директора только стартует.

Почему стандартные отчёты не помогают

Отчёты в портале построены вокруг сделки: сумма, стадия, ответственный, срок закрытия. Производственный заказ по этой модели описывается плохо сразу по трём причинам.

Во-первых, одна сделка часто порождает несколько заказов с разными сроками. В модели «одна сделка — одна дата закрытия» они схлопываются в одну строку.

Во-вторых, у заказа своя логика движения: он может вернуться на предыдущий этап после брака, встать из-за отсутствия материала, разделиться на партии. Воронка продаж такие движения не предполагает.

В-третьих, сделка закрывается в момент оплаты и выпадает из активных отчётов, хотя работа по ней идёт ещё месяц.

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

Что помогает

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

Ключевое условие — связь со сделкой обязательна. Без неё вы получаете вторую параллельную базу вместо единой картины.

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

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

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

Когда портала не хватает

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

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

С чего начать, если портал уже есть

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

Разбор портала целиком делаю отдельной работой: /uslugi/audit-bitrix24/. Отчётность и дашборды поверх CRM — /uslugi/razrabotka-dashbordov/.