Эффект нужно с чем-то сравнить, иначе это мнение

Контрольная группа — это часть процесса, которая продолжает работать по-старому, пока остальные используют новое решение. Без неё любые измерения упираются в вопрос «а что было бы без системы». В бизнесе одновременно меняется слишком многое: объём заявок колеблется по сезонам, меняется состав команды, приходят новые клиенты, обновляются регламенты. Сравнение «до и после» смешивает эффект системы со всеми этими изменениями.

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

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

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

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

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

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

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

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