Модель процесса без проверки — просто мнение с формулами

Аналитик построил в Excel зависимость: число заявок → время обработки. Прямая легла красиво, R² = 0,92. По прямой посчитали: при росте потока вдвое время вырастет на 40%. Наняли людей под этот прогноз. Поток вырос — и время обработки взлетело не на 40%, а втрое. Модель была красивая. Она просто была неправильная.

Глава о моделировании хендбука NIST — про то, как не попадать в эту историю. Её уроки относятся ко всем моделям процесса сразу: и к линейным прикидкам в Excel, и к имитационным моделям в симуляторе. Это четвёртая статья серии по статистике для процессов.

Модель — это функция плюс шум. Шум — тоже часть модели

NIST записывает любую модель одной формулой: наблюдаемое = детерминированная часть + случайная часть. И настаивает: модель — это не только формула, но и допущения о том, как устроен шум. Забыть про вторую половину — типовая ошибка. Для процессов это звучит так: сказать «проверка занимает 30 минут» — это полмодели. Вторая половина: а какой у этих 30 минут разброс и форма? От ответа зависит поведение очередей: при одном и том же среднем процесс с большим разбросом даёт в разы больше ожидания, чем процесс стабильный. Именно поэтому в симуляторе длительности задаются распределениями, а не одним числом.

Остатки: главный детектор вранья

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

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

Про R² хендбук говорит прямо: высокий R² не гарантирует, что модель хороша, и валидация, сведённая к цитированию R², — один из самых распространённых провалов анализа. Наша прямая с R² = 0,92 — ровно этот случай.

Экстраполяция: где умирают красивые модели

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

Важное преимущество имитационной модели перед прямой в Excel именно здесь: она воспроизводит механизм — очереди, ресурсы, календари, маршруты, — а не сглаженную картинку прошлого. Механизм продолжает работать и в режимах, которых в истории не было. Но и он — модель, и его тоже надо проверять.

Как валидировать имитационную модель процесса

Правило то же, что у NIST: модель должна воспроизвести вчера, прежде чем ей доверят завтра. Практических проверок три:

1. Сравнение с фактом. Прогоните модель на текущих параметрах и сравните с реальностью: пропускная способность, загрузка людей, время цикла. Расхождение в разы — ошибка в параметрах или в схеме. Расхождение в процентах — рабочий уровень.
2. Внутренняя согласованность. В теории очередей есть закон Литтла: число заявок в системе = интенсивность потока × время в системе. Он выполняется для любого стабильного процесса, и если в результатах модели он нарушен — модель внутренне противоречива. В отчёте симулятора Stormbpmn эта проверка встроена: блок валидации сверяет результаты прогона с законом Литтла и показывает, вышла ли модель на устойчивый режим или вся статистика собрана на разогреве.
3. Проверка чувствительности. Пошевелите входные параметры в пределах их погрешности. Если вывод переворачивается от десятипроцентного сдвига одного параметра — вы опираетесь на точность, которой у вас нет.

Сначала простая модель, потом сложная — и только если остатки потребуют

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

Чек-лист

1. У любой модели процесса спрашивайте две вещи: что в ней детерминированная часть и как описан шум.
2. Не принимайте R² и красивый график как доказательство. Смотрите на остатки: есть структура — модель недоговаривает.
3. Не экстраполируйте линейные модели за пределы наблюдавшейся нагрузки — очереди нелинейны.
4. Имитационную модель валидируйте на текущем режиме: пусть сначала воспроизведёт сегодняшнюю реальность, потом спрашивайте про завтрашнюю.
5. Стройте простую модель, усложняйте по фактам расхождения, а не по желанию учесть всё.

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