Почему среднее время процесса врёт: четыре проверки перед тем, как верить метрике

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

Это первая статья серии о статистике для процессных аналитиков. В основе — NIST/SEMATECH e-Handbook of Statistical Methods, справочник, по которому десятилетиями учат инженеров работать с данными измерений. Почти всё, что там написано про производственные процессы, дословно переносится на согласования, заявки и обращения. Начнём с самого основания: когда одному числу вообще можно верить.

Четыре набора данных с одинаковым средним

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

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

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

Когда среднему всё-таки можно верить: четыре допущения

NIST формулирует это строго. Одно число (среднее плюс разброс) корректно описывает процесс, только если данные проходят четыре проверки:

1. Случайность. Соседние значения не связаны друг с другом. В процессах это ломается чаще всего: заявки приходят пачками, исполнитель разгребает завал сериями, и время обработки соседних заявок коррелирует.
2. Одно распределение. Все значения приходят из одной «генеральной совокупности». Если в метрику согласования свалены и типовые договоры по шаблону, и нестандартные с тремя кругами правок — это смесь двух разных процессов, и её среднее не описывает ни один из них.
3. Постоянный центр. Типичное значение не уплывает во времени. После найма двух человек, смены регламента или сезонного пика «средним за квартал» описывать процесс нельзя: внутри квартала это был другой процесс.
4. Постоянный разброс. Ширина коридора не меняется. Бывает, что среднее стоит на месте, а разброс растёт — процесс становится непредсказуемым, и клиенты чувствуют именно это, хотя дашборд со средним зелёный.

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

Четыре картинки, которые заменяют интуицию

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

1. Значения по порядку поступления (run chart). Время цикла каждой заявки в хронологии. Виден тренд («после релиза всё поехало»), ступеньки («в марте наняли человека») и рост разброса.
2. Лаг-график: время заявки против времени предыдущей заявки. Если точки собираются в облако без структуры — случайность есть. Если вытягиваются в линию — значения зависят друг от друга, и все классические формулы «погрешности среднего» врут в оптимистичную сторону.
3. Гистограмма. Форма распределения. Два горба — в метрике смешаны два разных типа заявок, разделяйте и считайте отдельно. Длинный правый хвост — норма для времён обработки, но именно он делает среднее бесполезным.
4. Сравнение с ожидаемой формой (вероятностный график). Насколько данные похожи на предполагаемое распределение — и стоит ли пользоваться методами, которые его требуют.

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

Что требовать вместо среднего: перцентили

Если распределение скошено — а времена обработки скошены почти всегда, — честный язык разговора о сроках это перцентили:

• P50 (медиана) — половина заявок быстрее этого времени. «Типичный случай».
• P90 — девять из десяти заявок укладываются. Это уже язык обещаний клиенту.
• P95 и P99 — хвост. Именно тут живут заявки, о которых пишут жалобы и эскалации.

Разница между этими числами — сама по себе диагноз. Если P50 — один день, а P95 — девять, у вас не «процесс со средним 2,2 дня», у вас процесс с нормальным ходом и отдельной больной веткой, которую надо найти и лечить. SLA, сформулированный как «P95 ≤ 5 дней», защищает клиента. SLA «в среднем 3 дня» не защищает никого: он выполняется, даже когда каждая двадцатая заявка висит месяц.

Как это выглядит в симуляции процесса

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

В модуле имитационного моделирования Stormbpmn отчёт по прогону показывает динамику метрик во времени, разброс по сценариям прохождения и долю заявок, укладывающихся в SLA, — а не только «среднее время цикла». Сравнивая два сценария («нанять человека» против «убрать этап»), сравнивайте именно хвосты: сценарий с чуть худшим средним и вдвое короче хвостом почти всегда лучше для клиентов. Почему очередь реагирует на нагрузку нелинейно и что это делает с хвостами — разбор в статье про теорию очередей.

Чек-лист на эту неделю

1. Выгрузите времена цикла одного процесса за квартал — не отчёт, а сырые строки по заявкам.
2. Постройте четыре графика: хронологию, лаг, гистограмму, и посчитайте P50/P90/P95.
3. Найдите в гистограмме второй горб. Если есть — разделите метрику на два типа заявок и считайте отдельно.
4. Перепишите один SLA с языка «в среднем» на язык «P95 ≤ …».
5. Спросите у любого отчёта со средним: выполняются ли четыре допущения? Если никто не проверял — цифра пока ничего не значит.

Серия основана на NIST/SEMATECH e-Handbook of Statistical Methods — открытом справочнике Национального института стандартов США. В следующей статье — можно ли верить самим замерам: чему процессная аналитика может научиться у метрологов.