Как измерить эффект автоматизации, если процесс не сводится к экономии времени?

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

Когда проект заканчивается, команда часто показывает красивую цифру: раньше сотрудник тратил двадцать минут, теперь — пять. Это хороший сигнал, но не ответ на главный вопрос. Исчезла ли причина, из-за которой работа тормозила? Стало ли понятнее, кто должен действовать? Уменьшилось ли число исправлений и уточнений?

Сначала назовите решение, которое должно измениться

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

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

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

Четыре вещи, которые стоит наблюдать

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

Доля возвратов. Сколько раз операцию исправляют, пересоздают или отправляют заново. Небольшое ускорение не радует, если после него растёт очередь на исправления.

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

Понятность владельца. Можно ли по конкретному случаю за минуту понять, кто следующий и почему? Если ответ требует созвона с тремя отделами, автоматизация только быстрее передаёт неопределённость.

Не берите метрику из воздуха

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

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

Пример без выдуманной экономики

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

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

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

Частые ошибки

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

Короткий порядок действий

1. Назовите решение, ради которого меняется процесс.
2. Зафиксируйте несколько обычных случаев до изменения.
3. Выберите две-три метрики, которые команда может объяснить и проверить.
4. Отдельно опишите, как выглядит исключение и кто за него отвечает.
5. После запуска разберите не только цифры, но и конкретные случаи, где система помогла или подвела.

Связанные вопросы

Как понять, что процесс уже можно автоматизировать? Почему отчёт не всегда помогает принять решение? Что делать, если новая система увеличила число исключений? Как сравнить результат до и после без сложной аналитики?

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