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

Аналитик построил в 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. Проверка чувствительности. Пошевелите входные параметры в пределах их погрешности. Если вывод переворачивается от десятипроцентного сдвига одного параметра - вы опираетесь на точность, которой у вас нет.

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

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

Чек-лист

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

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