Контрольные карты для бизнес-процессов: как отличить поломку от шума

В понедельник среднее время обработки было 3,1 дня, во вторник - 4,2. Руководитель увидел рост на треть, собрал летучку, команда полдня искала причину. Причины не было: в среду метрика сама вернулась к 3,3. Это был обычный шум процесса - такой же, как был всегда. А через месяц процесс начал медленно деградировать - по чуть-чуть каждую неделю, - и этого не заметил никто, потому что каждый отдельный день выглядел нормально.

Обе ошибки - ложная тревога и пропущенная деградация - лечатся одним инструментом, которому уже сто лет. Контрольные карты придумал Уолтер Шухарт, инженер Western Electric: хендбук NIST датирует его первый меморандум - служебную записку с эскизом первой карты - 16 мая 1924 года. С тех пор на них стоит промышленное качество, а в главе о мониторинге процессов собраны готовые формулы границ для карт всех типов. Это шестая статья нашей серии по статистике для процессов.

Идея карты: сравнивай сегодня с собственным вчера

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

В нашем примере соседние дни отличаются в среднем на полдня - значит, границы лягут примерно на 1,9 и 4,5. Карта сразу показала бы: вторничные 4,2 дня - внутри, летучка не нужна. А медленная деградация дала бы серию точек по одну сторону центра - сигнал раньше, чем проблему заметят на глаз. Для совсем медленных дрейфов у статистиков есть карты с памятью (EWMA, CUSUM): они копят слабые отклонения и ловят сдвиг, который простая карта увидит намного позже.

Границы процесса - не SLA. Это главная путаница

Хендбук настойчиво разделяет две пары границ, которые постоянно путают.

Контрольные границы - голос процесса: что он фактически умеет, исходя из своего устройства. SLA - голос клиента: что от процесса требуется. Между ними нет никакой математической связи, и возможны все четыре комбинации: стабилен и держит, нестабилен, но держит, нестабилен и не держит. Самая коварная - четвёртая: процесс стабилен и при этом стабильно нарушает SLA. Он честно и предсказуемо делает то, на что способна его конструкция, - просто конструкция не тянет требование. В этой ситуации бесполезно усиливать контроль и мотивировать людей - нужно менять сам процесс. Что именно менять, подсказывают индексы способности из инженерии качества: Cp сравнивает требование SLA с разбросом процесса, Cpk - ещё и с тем, насколько процесс прижат к границе. Просел сам Cp - разброс шире требования, нарушения будут случаться регулярно и предсказуемо, сколько ни дави: меняйте конструкцию, штат, маршруты, автоматизацию. Cp в порядке, а просел только Cpk - процесс просто сдвинут к границе, и его достаточно перецентрировать, не перестраивая.

Цена чувствительности: ложные тревоги

Почему границы ставят именно на три сигмы - те самые три стандартных отклонения, - а не на две? Это осознанный компромисс. Хендбук приводит цифры: у классической трёхсигмовой карты ложная тревога случается в среднем раз в 370 точек. Добавьте популярные дополнительные правила чувствительности - правила Western Electric, названные по той самой компании, где работал Шухарт, - и интервал падает до раза в 92 точки: напрасные тревоги учащаются вчетверо. Взамен вы получаете не «больше пойманных поломок», а более раннее обнаружение, и заметен выигрыш в основном на небольших медленных сдвигах: крупную поломку простая карта и так видит с первых точек. В календаре руководителя это так: при ежедневном замере - одна напрасная летучка примерно в год без правил и раз в квартал с ними. Бесплатной чувствительности не бывает. Это тот же выбор, что у алертов мониторинга ИТ-систем: слишком чуткие алерты команда начинает игнорировать, и тогда пропускается настоящий.

Ещё одно правило гигиены: не пересчитывайте границы без причины. Границы - это память о нормальном поведении процесса; если пересчитывать их каждый месяц, медленная деградация просто впитается в новые границы и станет «новой нормой». Пересчёт законен после осознанного изменения процесса - с датой и причиной, записанными рядом с картой.

Контрольные карты в симуляторе: проверить SLA до внедрения

Обычно контрольные карты строят постфактум - когда процесс уже работает и уже болит. Но главный вопрос - вытянет ли конструкция обещание - можно задать и до внедрения. В отчёте симулятора Stormbpmn по результатам прогона считаются индексы Cp/Cpk относительно вашего SLA и строится контрольная карта с проверкой правил Western Electric: ещё до внедрения видно, держит ли новая версия процесса заявленный SLA и с каким запасом. Одна оговорка: карта по прогону наследует допущения модели - она честна ровно настолько, насколько честны входные данные, поэтому сначала проверьте саму модель. Как мы делали такой расчёт для реального клиента - в разборе готовых симуляций.

Чек-лист

1. Для главной метрики процесса постройте контрольную карту: центр и границы из истории за период без известных сбоев и изменений. Если распределение сильно скошено - стройте карту по медианам.
2. Договоритесь с командой: реагируем на сигналы карты, а не на любое колебание метрики.
3. Разведите в отчётности голос процесса (контрольные границы) и голос клиента (SLA). Это разные линии на разных графиках.
4. Если процесс стабилен, но не держит SLA - прекратите давить на людей: смотрите Cp и Cpk и либо перецентрируйте процесс, либо меняйте конструкцию. Варианты конструкции прогоняйте в симуляторе.
5. Пересчитывайте границы только после документированного изменения процесса.

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