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

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

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

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

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

Вернёмся к команде из начала статьи (кейс собирательный, но механика типовая). Узких мест в процессе было два: и маршрутизация, и проверка сидели на загрузке под 95%. Добавочный человек на проверке не помог: заявки по-прежнему часами ждали распределения. Автоматическая маршрутизация сама по себе тоже не помогла: она быстрее подводила заявки к проверке - и очередь просто переехала туда. Расшивка одного узкого места передавала ограничение другому. Эффект даёт только комбинация: быстрая маршрутизация плюс расширенная проверка - обе загрузки падают, и ожидание сжимается сразу на обоих узлах. При переборе по одному эту комбинацию не увидеть - именно во взаимодействиях, по хендбуку, может прятаться улучшение почти без затрат.

Как это выглядит в числах - четыре комбинации на имитационной модели, по десять прогонов на каждую (числа модельные):

По отдельности каждое изменение даёт десятые доли дня, вместе - минус три дня. Это и есть взаимодействие.

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

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

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

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

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

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

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

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

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

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

Чек-лист

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

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