Полгода назад согласование занимало в среднем 6,1 дня. Внедрили новый регламент — стало 5,4. На слайде для руководства: «ускорили процесс на 11%». Вопрос, который никто не задал: а насколько эти 6,1 и 5,4 вообще различимы на фоне шума? Если месяц к месяцу среднее и так гуляет от 5 до 7 дней — вы отчитались об улучшении, которого, возможно, не было.
Глава о сравнениях хендбука NIST — ровно про этот вопрос во всех его формах: отличается ли то, что я вижу, от того, что было, или мне кажется. Это седьмая статья серии по статистике для процессов.
Главная привычка, которую стоит забрать из этой главы: любая оценка по данным — это не точка, а интервал. «Среднее 5,4 дня» по ста заявкам означает что-то вроде «истинное типичное время где-то между 4,9 и 5,9». И тогда главный вопрос сравнения формулируется просто: накрывает ли интервал разницы «до минус после» скучное значение — ноль. Если ноль внутри интервала — данные совместимы с тем, что улучшения нет вообще. Если снаружи — эффект, скорее всего, настоящий, и интервал заодно показывает его правдоподобный размер — что для решений важнее любого «значимо/незначимо».
Считать такие интервалы умеет любой статпакет и даже Excel. Важнее формул — сама привычка требовать вилку рядом с каждой цифрой эффекта на слайде.
Вторая ошибка тоньше. Допустим, интервал накрыл ноль, и аналитик пишет: «различий нет, регламент не сработал». Хендбук прямо называет это неверным выводом: отсутствие доказательства разницы — не доказательство отсутствия. Возможно, эффект есть, но выборка мала, чтобы его разглядеть на фоне шума. При большом разбросе времён цикла (а у процессов он всегда большой) месяца данных может банально не хватить, чтобы увидеть даже честные минус десять процентов. Перед тем как хоронить изменение, посчитайте, какой размер эффекта ваша выборка вообще способна обнаружить.
Третья ошибка — массовая. Команда проверила десять идей оптимизации, девять не дали эффекта, одна показала улучшение «со статистической значимостью». Победа? Не факт. Если каждая проверка ошибается в 5% случаев, то среди десяти проверок шанс хотя бы одной ложной «победы» — уже около 40%. Хендбук посвящает этой проблеме целый раздел про множественные сравнения: чем больше гипотез вы проверяете на одних данных, тем жёстче должен быть порог для каждой. Самое простое бытовое правило: одиночный красивый результат среди многих проверок — это гипотеза для повторной проверки на свежих данных, а не готовый вывод.
Есть приём, который резко повышает чувствительность сравнения, — сравнивать парами, а не толпами. Не «весь март против всего мая», где на разницу наложились сезонность, состав заявок и отпуска, а по возможности одинаковые условия: те же типы договоров, те же недели месяца, те же люди. Каждая пара — свой маленький эксперимент, и общий шум вычитается.
И здесь симулятор даёт то, чего в живом процессе не бывает никогда: идеально парный эксперимент. В симуляторе Stormbpmn два сценария можно прогнать на одном и том же потоке виртуальных заявок: одинаковые моменты прихода, одинаковые доли сложных случаев — меняется только само проверяемое изменение (для воспроизводимости достаточно зафиксировать одинаковый seed прогона). Вся разница в результатах — эффект изменения, а не разница в удачливости месяцев. В живом эксперименте такое невозможно в принципе: март никогда не повторится для контрольной группы.
После такого сравнения остаётся последний шаг — проверить победивший сценарий пилотом в реальности, с честным замером «до» и заранее зафиксированным критерием успеха. Про то, почему без этого любой исход объявляют успехом — был разбор в статье про три способа соврать себе про оптимизацию.
Серия основана на NIST/SEMATECH e-Handbook of Statistical Methods. Финальная статья серии — про надёжность: почему год без сбоев ничего не говорит о надёжности процесса.
Новые статьи в вашем электрическом ящике
Обзоры конференций, лучшие практики процессного подхода и учебные статьи в вашей почте. Не чаще 1 раза в неделю.
Без спама, только то, что вы запросили.
