Вопрос «где заказ №347» звучит в операционном блоке чаще любого другого. Ответ обычно занимает от двадцати минут до половины дня: кто-то пишет в чат, кто-то звонит на склад, кто-то ищет письмо в почте. К моменту, когда картина собрана, клиент уже написал сам. Операционный директор при этом формально контролирует сроки, а фактически восстанавливает хронологию задним числом. Между этими двумя занятиями лежит вся разница в управляемости сроков, и закрывается она не усилием воли, а тем, как устроен учёт заказов.
Сроки срываются не там, где их ищут
Когда заказ уходит за плановую дату, первым делом ищут виноватого исполнителя. В большинстве компаний это не туда. Задержка почти всегда набирается не внутри этапа, а на стыках между ними: производство закончило, но никто не сказал логистике; логистика готова, но документы ещё у бухгалтерии; бухгалтерия ждёт правку от менеджера, который в отпуске.
Каждый такой стык стоит от нескольких часов до нескольких дней, и в отчётах он не виден вообще. В отчёте видно только суммарное отклонение по заказу, а внутри него ровно один вопрос без ответа: где именно осело время. Пока этот вопрос закрывается устно, любые меры по ускорению бьют наугад. Обычно наугад бьют по продажам, потому что их проще всего измерить, хотя продажи к задержке отношения не имеют.
Второй источник срывов чуть менее очевиден. Плановая дата в большинстве компаний живёт не в системе, а в голове менеджера и в письме клиенту. Она нигде не зафиксирована как поле, по которому можно построить фильтр. Соответственно, вопрос «сколько заказов сейчас просрочено» технически не имеет ответа: цифру приходится собирать вручную, и каждый раз она получается разной.
Три цифры, которых обычно не хватает
Операционному директору для ежедневного контроля нужно немного. Практически весь управленческий разговор строится вокруг трёх чисел.
Сколько заказов сейчас в работе и на каком этапе. Не список, а распределение: столько на производстве, столько на отгрузке, столько ждут документов. Скопление на одном этапе означает узкое место, и видно его до того, как посыпались сроки, а не после.
Сколько заказов вышли за плановый срок и на сколько дней. Ключевое слово здесь «на сколько». Двадцать заказов с отставанием в день и два заказа с отставанием в три недели дают одинаковый процент просрочки и совершенно разные последствия для репутации.
Сколько заказов подойдут к сроку на этой неделе. Это единственная из трёх цифр, которая позволяет действовать заранее. Первые две говорят о прошлом, третья о ближайших пяти днях.
Ни одна из этих цифр не требует внедрения сложного продукта. Все три получаются из CRM при условии, что этап и плановая дата зафиксированы как данные, а не как договорённость.
Где в системе живёт срок
Самая частая методическая ошибка, это попытка контролировать исполнение заказа в той же воронке, где идёт продажа. Логика вроде бы понятна: сделка одна, зачем плодить сущности. На практике это ломает и продажи, и производство.
Воронка продаж отвечает на вопрос «купят или нет» и заканчивается решением клиента. Исполнение заказа отвечает на вопрос «сделали или нет» и начинается там, где продажа закончилась. У них разные владельцы, разные этапы, разная скорость и разные метрики. Смешанные в одну воронку, они дают отчёт, в котором коммерческий директор не может посмотреть конверсию, а операционный не может посмотреть сроки.
Рабочая схема простая: отдельная воронка исполнения, куда заказ попадает после выигрыша сделки в коммерческой воронке. У неё свои стадии, отражающие реальный маршрут заказа по компании, и свой ответственный на каждой стадии. Для более сложных случаев в Битрикс24 есть смарт-процессы, отдельная сущность под собственный объект учёта вроде заказа, отгрузки или рекламации. Учтите, что смарт-процессы и автоматизация задач доступны не на всех планах облака, так что перед проектированием стоит свериться с матрицей тарифов.
Отдельно про поле срока. Плановая дата исполнения должна быть обязательным полем, заполняемым в момент перехода заказа в исполнение. Пока это поле необязательное, оно будет пустым в трети карточек, и любая отчётность по срокам превращается в оценку.
Кто отвечает за срок
Пока ответственность за срок размазана по всей цепочке, её нет ни у кого. Формула «за заказ отвечает менеджер» перестаёт работать в тот момент, когда заказ уходит в производство: менеджер не управляет ни загрузкой цеха, ни очередью на отгрузку, а спрашивают с него.
Рабочая модель делит ответственность на два уровня. У каждой стадии есть свой владелец, тот, кто отвечает за прохождение заказа через этот участок и за сроки внутри него. И у заказа целиком есть один держатель, обычно это менеджер или руководитель проекта, который отвечает за коммуникацию с клиентом и за эскалацию, когда участок встал. Технически это выражается просто: ответственный на стадии меняется вместе со стадией, а поле держателя заказа остаётся неизменным до закрытия.
Такое разделение снимает самый утомительный тип совещаний, где полтора часа выясняют, чья это была зона. Ответ виден в карточке: заказ стоял на стадии комплектации шесть дней, владелец стадии известен, вопрос адресный. Заодно исчезает практика, при которой ответственным по умолчанию назначают того, кто громче всех отвечает в чате.
Отдельно стоит договориться про эскалацию. У каждой стадии должен быть порог в днях, после которого держатель заказа обязан поднять вопрос выше, а не ждать. Без такого порога эскалация происходит в момент, когда клиент уже позвонил директору, то есть слишком поздно, чтобы что-то исправить.
Что уже есть в системе для контроля
Многие компании покупают отдельные инструменты под контроль исполнения, не разобравшись с тем, что уже оплачено. Ниже то, на чём операционный контроль строится в Битрикс24 штатно.
CRM-аналитика. Отдельный раздел в левом меню, где отчёты разделены на анализ лидов и анализ продаж. Для операционного блока полезнее всего сам принцип фильтрации: результаты фильтруются по любым полям, включая пользовательские. Это и означает, что заведённое вами поле плановой даты сразу становится измеримым, без разработки.
Раздел «Руковожу» в задачах. Находится по пути «Задачи и проекты», далее «Ещё», далее «Руковожу». Показывает поручения подчинённых и позволяет оценить их загрузку, не собирая отчёты вручную с каждого руководителя отдела.
Показатель «Эффективность». Живёт в «Задачи и проекты», раздел «Эффективность». Считается по формуле: эффективность равна 100 минус отношение замечаний к задачам к общему числу задач в работе за период, умноженное на 100. По умолчанию показатель равен 100 процентам. Замечание, это отметка о нарушении крайнего срока по задаче; если задача просрочена дважды, замечаний будет два, и они переносятся в следующий период, пока не будут исправлены завершением задачи или продлением срока. Период задаётся фильтром.
Контроль после завершения. Опция «Проконтролировать задачу после завершения» переводит выполненную работу в статус «Ждёт контроля»: постановщик принимает результат или возвращает на доработку. Для операционного блока это способ отделить «сотрудник нажал кнопку» от «работа действительно сделана».
Счётчики. Цветные индикаторы показывают состояние: красный означает просрочку, зелёный новые сообщения, серый изменения при отключенных уведомлениях. Простая вещь, но именно она превращает просрочку из строки в отчёте в то, что человек видит каждый день.
Статусы задач. «Ждёт выполнения», «Выполняется», «Отложена», «На проверке», «Завершена». Колонку «Статус» включают в настройках представления списка.
Автоматизация вместо ручных напоминаний
Контроль, который держится на памяти руководителя, не масштабируется. При тридцати активных заказах операционный директор ещё помнит критичные, при ста уже нет. Дальше начинается выборочный контроль, а выборочный контроль означает, что срываются именно те заказы, которые в выборку не попали.
В CRM Битрикс24 эту часть закрывают роботы и триггеры. Робот срабатывает, когда элемент попадает на стадию, и выполняет действие: ставит задачу, отправляет уведомление, меняет поле. Триггер работает в обратную сторону, отслеживает событие и сам двигает элемент на другую стадию. Практически это значит, что передача заказа между отделами перестаёт зависеть от того, написал ли кто-то в чат.
Для операционного контроля полезны три сценария. Первый: при переходе заказа на стадию автоматически ставится задача ответственному следующего этапа, со сроком и понятным описанием. Второй: за сутки до плановой даты ответственный получает напоминание, а руководитель уведомление, если заказ всё ещё не на финальной стадии. Третий: заказ, вышедший за плановую дату, помечается или переносится в отдельное представление, где его видно без фильтров.
Важная оговорка про тарифы. Роботы и триггеры в CRM доступны на большинстве коммерческих планов облака, а вот автоматизация внутри задач, регулярные задачи и смарт-процессы относятся к старшим планам. Если проект строится вокруг исполнительской дисциплины, тариф стоит проверять до проектирования процесса, а не после. Мы обычно сверяем это на старте, когда обсуждаем внедрение Битрикс24 для вашего бизнеса, чтобы не проектировать схему, которую потом не на чем запустить.
Четыре метрики операционного контроля
Когда данные начинают собираться, появляется соблазн построить двадцать отчётов. Не надо. Для управления сроками исполнения заказов хватает четырёх показателей, и все четыре считаются автоматически, если этапы и плановая дата зафиксированы.
Доля заказов, выполненных в срок. Базовая цифра, которую можно показать собственнику и клиенту. Смотреть её нужно в динамике по месяцам, а не разово: разовое значение ничего не говорит, тренд говорит всё.
Среднее время исполнения от передачи в работу до закрытия. Отвечает на вопрос, стала ли компания быстрее. Полезно считать отдельно по типам заказов, иначе крупный нетиповой проект перекашивает среднее.
Среднее время на каждом этапе. Самая недооценённая метрика и единственная, которая показывает узкое место. Если из двенадцати рабочих дней цикла пять уходит на согласование документов, то ускорять производство бессмысленно.
Количество возвратов на предыдущий этап. Показатель качества, а не скорости. Заказ, вернувшийся с отгрузки обратно на комплектацию, означает ошибку, которую выгоднее найти на входе. Отдельные возвраты нормальны, устойчивый процент возвратов на одном и том же переходе означает дыру в процессе.
Ни одна из четырёх метрик не требует ручного ввода. Все они выводятся из того, как и когда двигались карточки, при условии, что сотрудники двигают их вовремя. Что подводит к самой болезненной части.
Почему система показывает неправду и что с этим делать
Отчётность в CRM ровно настолько честна, насколько дисциплинированно люди отмечают этапы. Здесь операционный директор сталкивается не с технической, а с управленческой задачей, и решается она не настройками.
Первое, что убивает достоверность, это двойной учёт. Если сотрудник ведёт заказ в системе и параллельно в своей таблице, актуальной будет таблица, а система превратится в отчётный ритуал. Пока хотя бы один участок процесса живёт в чужом файле, данные будут расходиться. Убирать надо не таблицу, а причину, по которой она удобнее.
Второе, это отметки задним числом. Заказ переводят на следующую стадию не тогда, когда работа сделана, а вечером перед планёркой, все разом. Формально дисциплина есть, фактически метрика времени на этапе мертва. Лечится тем, что перевод стадии привязывают к действию, которое сотруднику всё равно нужно сделать: приложить документ, отметить отгрузку, зафиксировать приёмку.
Третье, и самое частое: система построена под отчётность руководителя, а не под работу исполнителя. Если сотруднику ведение карточки не даёт ничего, кроме дополнительных кликов, он будет заполнять её по остаточному принципу. Если карточка даёт ему готовые данные для следующего шага, документы под рукой и понятный список того, что от него ждут сегодня, заполняемость держится сама.
Практический критерий готовности такой. Спросите у линейного сотрудника, куда он смотрит утром, чтобы понять свою работу на день. Если он называет CRM, данные достоверны. Если он называет чат, таблицу или устные указания руководителя, отчёты по срокам можно не открывать.
Что делать с заказом, который уже просрочен
Отдельная процедура нужна не только для профилактики, но и для тех заказов, где срок уже упущен. В большинстве компаний такой процедуры нет, и просроченный заказ ведёт себя как обычный, только с нервной перепиской вокруг.
Минимальный набор правил выглядит так. Просроченный заказ получает видимую метку и попадает в отдельное представление, куда операционный директор смотрит ежедневно. У него появляется новая плановая дата, согласованная с клиентом, при этом исходная дата сохраняется отдельным полем: иначе через месяц окажется, что все заказы выполнены в срок, потому что срок переносили. И у него назначается конкретное действие с ответственным, а не общее указание ускориться.
Сохранение первоначальной даты, это принципиальный момент для честности отчётности. Компании, где плановую дату просто перезаписывают, теряют возможность считать долю выполненных в срок вообще: цифра всегда будет близка к ста процентам, и ей никто не поверит, включая самого директора. Два поля вместо одного стоят пяти минут настройки и возвращают показателю смысл.
С чего начинать, если сейчас ничего не измеряется
Полный переход операционного блока в систему занимает месяцы и почти всегда буксует, если пытаться сделать всё сразу. Разумный порядок другой.
Начните с одного типа заказов, самого массового. Опишите его маршрут по компании так, как он идёт на самом деле, а не как записано в регламенте, и оформите этот маршрут стадиями. Введите обязательную плановую дату. Дайте процессу поработать месяц без всякой автоматизации, только на ручных переводах стадий. Через месяц у вас появятся первые честные цифры по времени на этапах, и именно они покажут, куда ставить роботов.
Автоматизацию добавляйте после, начиная со стыков с наибольшей задержкой. Это ровно те места, где заказ ждёт, пока кто-то кому-то скажет. Тут автоматическая передача даёт эффект сразу и не требует убеждать команду.
И последнее. Контроль сроков исполнения заказов даёт результат не в момент запуска отчёта, а в момент, когда обсуждение просрочек на планёрке перестаёт быть спором о том, кто что помнит. Когда цифры на экране одни и те же для всех участников, разговор занимает пятнадцать минут вместо часа и заканчивается решением, а не взаимными претензиями. Ради этого операционному директору и стоит доводить учёт до состояния, в котором ему можно верить.
Частые вопросы
Нужна ли отдельная воронка под исполнение или хватит стадий в коммерческой?
Отдельная воронка почти всегда лучше. У продажи и у исполнения разные владельцы, разные метрики и разная длительность. В общей воронке отчёт становится нечитаемым для обоих блоков, а конверсия продаж искажается стадиями, к продаже не относящимися.
Как посчитать процент заказов, выполненных в срок, если плановая дата нигде не хранится?
Никак, пока не появится поле. Плановую дату нужно завести как обязательное поле, заполняемое при передаче заказа в исполнение. Отчёты CRM-аналитики фильтруются по любым полям, включая пользовательские, поэтому после появления поля цифра считается без доработок.
Что делать, если сотрудники двигают карточки задним числом?
Привязать перевод стадии к действию, которое всё равно требуется: приложенный документ, отметка отгрузки, подтверждение приёмки. Пока перевод стадии остаётся отдельным лишним действием ради отчётности, он будет делаться пачками перед планёркой.
Можно ли видеть эффективность конкретного сотрудника, а не только общую картину?
Да, для этого есть раздел «Эффективность» в «Задачах и проектах» и раздел «Руковожу» для просмотра поручений подчинённых. Эффективность считается от числа замечаний, то есть нарушений крайнего срока, за выбранный в фильтре период.
С какого объёма заказов это перестаёт быть избыточным?
Ориентир простой: когда руководитель перестаёт держать все активные заказы в голове. Обычно это несколько десятков одновременных заказов или две и более передачи между отделами внутри одного заказа. До этого порога хватает и таблицы, после него ручной контроль начинает давать сбои чаще, чем экономит время.