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

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

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

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

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

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

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

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

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

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

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

🧮 Посчитайте свой процесс, а не спорьте о нём. Имитационное моделирование в Storm: очереди, загрузка ролей, SLA и себестоимость заявки — до внедрения, по обычной BPMN-схеме. Как это работает · 42 посчитанных кейса.

Четыре картинки вместо формул

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

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

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

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

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

Для скошенных времён обработки - а они скошены почти всегда - о сроках честнее говорить перцентилями:

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

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

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

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

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

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

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

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