Павел Харитонов

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

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

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

И уже после этого становится понятно, что автоматизировать, а что лучше оставить как есть.

Спасибо за статью. Мне близка сама идея, что автоматизация без фундамента часто только ускоряет хаос.

Но я бы добавил обратную сторону: формализация ради самой формализации тоже может разрушить то, что уже работает.

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

Поэтому для меня первый вопрос не «какой у нас уровень зрелости?», а «что сейчас реально не работает и какой результат мы хотим изменить?»
А уже потом — процессы, данные, метрики, автоматизация.

Иначе можно получить систему, которую сотрудники отлично обслуживают, но бизнесу от этого лучше не становится.

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

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

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

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

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

Спасибо за тему. Особенно откликнулась мысль, что при делегировании важно определить результат, а не просто передать человеку набор действий.

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

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

Получается, работу он делегировал, а контроль — нет. И из операционки в итоге вышел только наполовину.

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

Спасибо за здравый взгляд на цифровизацию — особенно за то, что начинать предлагаете не с выбора ПО, а с аудита процессов. На практике этот этап действительно часто пытаются перескочить.

Я бы только между аудитом и выбором ПО добавил ещё один шаг — спроектировать, как процесс вообще должен работать после внедрения.

«У нас теряются документы» ещё не значит, что надо просто внедрить документооборот. Кто создаёт документ, кто согласует, что считается завершением, где руководитель видит просрочку, что происходит дальше?
В проектах регулярно сталкиваюсь с тем, что запрос начинается с «нам нужна CRM / отчёт / согласование». Начинаешь разбирать — и оказывается, что сначала надо договориться, как должен выглядеть сам результат работы.
А уже потом выбирать инструмент. Иначе можно довольно успешно автоматизировать плохо спроектированный процесс.

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

То есть цена пропущенного звонка действительно не исчезает, а переезжает в другой канал и увеличивает стоимость дальнейшей обработки.

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

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

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