Меняли по одному фактору — и не нашли: как планировать эксперименты над процессом

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

О том, как ставить эксперименты, чтобы не попадать в эту ловушку, написана глава хендбука NIST о планировании экспериментов (Design of Experiments, DOE). Дисциплине сто лет, её создали для дорогих промышленных экспериментов — и именно поэтому она идеально ложится на симуляцию процессов, где эксперименты наконец стали бесплатными. Это пятая статья серии по статистике для процессов.

Почему «по одному фактору» — ловушка

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

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

Факторный план: все комбинации вместо одной цепочки

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

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

Лестница вместо одного большого эксперимента

Второй принцип хендбука: не складывайте все яйца в один большой эксперимент. Правильная стратегия — лестница:

1. Отсеивание. Есть десять идей — дешёвыми грубыми прогонами отделите две-три влияющие от семи бесполезных. Большинство идей умирает здесь, и это дешёвая смерть.
2. Уточнение. Для выживших факторов — полный факторный план с взаимодействиями и подбор уровней: не «нанять ли людей», а «сколько именно».
3. Подтверждение. Лучшую найденную комбинацию — в пилот на реальном процессе. NIST требует подтверждающие прогоны даже после самого красивого анализа — и для симуляции это тоже верно: модель предлагает, пилот подтверждает.

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

Два правила честного эксперимента — и в жизни, и в симуляторе

Смело, но не безрассудно выбирайте диапазоны. Если проверять «нанять одного человека или двух», разница утонет в шуме. Проверьте контрастные варианты — текущий штат против штата +50%, — чтобы понять форму зависимости, а потом ищите оптимум внутри. В симуляторе контрастные сценарии бесплатны — пользуйтесь.

Не сводите результат к одной цифре. NIST предостерегает от склеенных метрик: смотрите на составляющие, а не только на итог. Сценарий может улучшать среднее время цикла, одновременно раздувая хвост P95 и перегружая одну группу людей до 95% — про то, почему среднее прячет такие вещи, была первая статья серии.

Чек-лист

1. Спишите все идеи улучшения процесса в список факторов. Обычно их 5-10.
2. Отсейте грубыми прогонами в симуляторе: какие факторы вообще двигают метрику.
3. Для 2-3 выживших прогоните все комбинации — ищите взаимодействия.
4. Лучшую комбинацию проверьте пилотом на реальном процессе, с замером «до».
5. Никогда не делайте вывод «фактор не работает», пока не проверили его в комбинации с другими.

Серия основана на NIST/SEMATECH e-Handbook of Statistical Methods. Следующая статья — контрольные карты: как отличить «процесс сломался» от обычного шума и не дёргать команду по ложным тревогам.