Было 6 дней, стало 5: как понять, что вы действительно ускорили процесс

Полгода назад согласование занимало в среднем 6,1 дня. Внедрили новый регламент - стало 5,4. На слайде для руководства: «ускорили процесс на 11%». Вопрос, который никто не задал: а насколько эти 6,1 и 5,4 вообще различимы на фоне шума? Если месяц к месяцу среднее и так гуляет на полдня вверх-вниз - вы отчитались об улучшении, которого, возможно, не было.

Глава о сравнениях хендбука NIST - ровно про этот вопрос во всех его формах: отличается ли то, что я вижу, от того, что было, или мне кажется. Это седьмая статья серии по статистике для процессов.

Интервал вместо точки

Главная привычка, которую стоит забрать из этой главы: любая оценка по данным - это не точка, а интервал. «Среднее 5,4 дня» по ста заявкам за месяц означает что-то вроде «истинное среднее где-то между 4,9 и 5,9». И тогда главный вопрос сравнения формулируется просто: накрывает ли вилка разницы «до минус после» скучное значение - ноль. Если ноль внутри - данные совместимы с тем, что улучшения нет вообще. Если снаружи - эффект, скорее всего, настоящий (если только это не лучший из десятка результатов - об этой ловушке ниже), и вилка заодно показывает его правдоподобный размер - что для решений важнее любого вердикта о «значимости».

Механика простая и есть даже в Excel: стандартное отклонение, делённое на корень из числа заявок, даёт точность среднего; отложите две таких точности в обе стороны - получите вилку (по-взрослому - доверительный интервал). В нашем кейсе разница 0,7 дня, а её вилка - от нуля до 1,4: ноль на самом краю. Улучшение, скорее всего, есть, но объявлять «минус 11%» с трибуны рано. И одна проверка до всякого сравнения: убедитесь, что процесс стабилен, - средние нестабильного процесса сравнивать бессмысленно, об этом была статья про контрольные карты.

«Не доказали разницу» - не значит «разницы нет»

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

🧮 Посчитайте свой процесс, а не спорьте о нём. Имитационное моделирование в Storm: очереди, загрузка ролей, SLA и себестоимость заявки — до внедрения, по обычной BPMN-схеме. Как это работает · 42 посчитанных кейса.

Ловушка десяти гипотез

Третья ошибка - массовая. Команда проверила десять идей оптимизации, девять не дали эффекта, одна показала улучшение «со статистической значимостью». Победа? Не факт. Привычный порог «значимости» 5% означает: там, где эффекта на самом деле нет, проверка поднимет ложную тревогу с шансом один к двадцати. При десяти независимых проверках идей, из которых не работает ни одна, шанс хотя бы одной ложной «победы» - уже около 40%. Хендбук посвящает этой проблеме целый раздел про множественные сравнения: чем больше гипотез вы проверяете на одних данных, тем жёстче должен быть порог для каждой. Самое простое бытовое правило: одиночный красивый результат среди многих проверок перепроверяют на свежих данных, прежде чем что-то менять.

Парное сравнение: убрать чужой шум

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

И здесь симулятор даёт то, чего в живом процессе не бывает: по-настоящему парный эксперимент. В симуляторе Stormbpmn два сценария можно прогнать на одном и том же потоке виртуальных заявок - те же моменты прихода, та же доля сложных случаев, различается только то, что вы проверяете. Разница считается внутри пары, и «удачливость месяцев» из результата уходит. Собственный шум у симуляции тоже есть, поэтому прогоны повторяют несколько раз и смотрят на вилку средней разницы - но набрать двадцать таких пар здесь стоит вечер, а не полгода накопления живых данных. В живом эксперименте парность недостижима в принципе: март никогда не повторится для контрольной группы.

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

Чек-лист

1. К каждой цифре эффекта на слайде требуйте вилку: «быстрее на 0,7 дня, вилка от нуля до 1,4» честнее, чем «минус 11%».
2. Если ноль внутри вилки - не объявляйте победу. Если выборка мала - не объявляйте и поражение.
3. Сравнивайте сопоставимое с сопоставимым: одинаковые типы заявок и периоды, без смешанных одновременных изменений.
4. При десяти проверенных гипотезах одиночную «значимую» перепроверьте на свежих данных.
5. Сценарии сравнивайте в симуляторе на одинаковом потоке заявок - это парный эксперимент, недоступный в живой эксплуатации.

Серия основана на NIST/SEMATECH e-Handbook of Statistical Methods. О природе шума, на фоне которого идёт любое сравнение, - в статье про то, откуда в процессе разброс. Финальная статья серии - про надёжность: почему год без сбоев почти ничего не говорит о надёжности процесса.