Аномалии в бизнес-процессах: как найти и исключить
Сроки сдвигаются, система ломается, предсказуемость стремится к нулю — так влияют аномалии на бизнес-процессы. Как обнаружить аномалии и какие контрмеры помогут их устранить? Разберем на реальных примерах, а также обсудим, что такое и для чего нужны диаграмма рассеяния Lead Time и Накопительная диаграмма потока (CFD)
Мы с вами уже многому научились: умеем разделять задачи по типам, быстро и обоснованно прогнозировать сроки выполнения задач с вероятностью до 80, 90 и даже 100%, знаем, чем чреваты перегрузки в рабочих процессах и как их эффективно устранить. Здорово, правда?
Но сразу возникает вопрос: а как всё будет в реальной жизни? Ну конечно, гораздо сложнее.
Настало время настоящих хардкорных примеров, которые с высокой долей вероятности вы встретите в своих командах. Спойлер: мы справимся и с ними!
Такой разный Lead Time
Итак, давайте представим, что вы измерили время выполнения задач в I квартале, построили диаграмму распределения времени выполнения (Lead Time Distribution) и получили следующий результат — наиболее вероятный Lead Time равен 16 дням. Отлично!
Продолжаем измерять показатели в следующем квартале.
И вот незадача: Lead Time составляет уже 29 дней. В предыдущем квартале было 16, сейчас — 29. Смотрим дальше.
Третий квартал, новая диаграмма и Lead Time вдруг становится равен 20 дням.
В итоге у нас есть 3 измерения по трем разным кварталам, и каждый квартал показывает разное вероятное время выполнения задач. Что на самом деле происходит?
Колебания Lead Time говорят о том, что ваша рабочая система на данный момент нестабильна и непредсказуема. Мы постоянно наблюдаем какие-то всплески активности или наоборот простои, рабочая нагрузка распределена неравномерно и может серьезно отличаться на разных этапах.
Вы можете сказать: «Спасибо, кэп, а что делать-то?». Давайте разбираться вместе.
Что указывает на нестабильность системы? Анализируем метрики
Если мы ведем метрики, как нам диктует Канбан-метод, то сразу обратим внимание на некоторые аномалии в графиках. Давайте вернемся к кейсу компании Sokolov из предыдущей статьи и посмотрим на график, который мы получили в их случае в ходе анализа задач за квартал. Мы четко видим, что 3 значения находятся в стороне от основного массива данных. Анализируя эти аномалии, удалось обнаружить 3 группы причин:
- В одном случае причиной аномалии стали сразу несколько обстоятельств, произошедших одновременно. Всё, что могло пойти не так, пошло не так: заказчик заболел, уволился ведущий разработчик и упал сервер.
- Во втором случае столкнулись неопытный исполнитель и шесть заказчиков, которые никак не могли между собой договориться.
- И наконец, последний кейс — период отпусков, когда практически всё в один момент свалилось на одного человека, поэтому выполнение некоторых задач было отложено.
Важный момент, что Lead Time на графике выше — это идеальная картинка, потому что мы четко видим отдельно стоящие аномальные значения, но так бывает далеко не всегда.
Как еще можно обнаружить аномалии
Давайте рассмотрим еще ряд графиков и метрик, позволяющих явным образом обнаружить эти аномалии и понять, что с ними делать. И первая диаграмма, которая нам в этом поможет — диаграмма рассеяния Lead Time (Lead Time Scatter Plot).
По вертикали (ось Y) отмечаем время производства (Lead Time), а по горизонтали — даты. И каждый раз, когда в какую-то дату закрывается задача, мы ставим отметку на графике, она будет соответствовать времени выполнения этой задачи. Например, у нас закрылась задача за 5 дней 5 мая, соответственно мы ставим отметку на высоте 5.
Таким образом, у нас получается некое распределение, рассеяние, у которого мы уже можем заметить некий тренд. Тренд может расти вверх, и это означает, что Lead Time растет и мы ухудшаемся как система, или падать вниз, а значит, мы наоборот ускоряемся. Но самое интересное здесь — это то, что точно так же, как на диаграмме распределения Lead Time (подробнее об этом я рассказывал в этой статье), мы можем сделать отсечки с вероятностью в 15%, 50%, 85% или 95%.
И глядя на это распределение, мы снова замечаем значение, которое сильно отличается от остальных. То есть мы снова столкнулись с аномалией, какой-то проблемой в нашей системе.
Аномалии детектед. Что делать дальше?
- Проанализировать, что произошло и послужило причиной возникновения аномалии.
- Найти корневую причину. Если что-то случилось, важно докопаться до сути: что именно в нашей работе, системе или регламентах провоцирует такого рода аномалию. Важно, что само по себе событие может не быть разрушительным, но в нашей системе последствия от его наступления оказались тяжелыми.
- Продумать контрмеры и изменить рабочий процесс таким образом, чтобы случайности в будущем не порождали эти аномалии, не ломали статистику и давали возможность прогнозировать сроки выполнения задач достаточно достоверно.
Какие это могут быть контрмеры? Давайте снова вернемся к кейсу Sokolov. Напомню, что причиной одной из аномалий стало фатальное совпадение сразу 3 событий: заболел заказчик, из команды ушел ведущий разработчик и в довершение всего сломался сервер.
Возможные системные контрмеры:
- У каждого заказчика должен быть заместитель. Если по причине отсутствия заказчика у нас останавливается проект, логично договориться, чтобы у каждого заказчика был помощник или заместитель, который в случае его болезни или отпуска просто берет эту ответственность на себя, и тогда работа продолжается. Это системное решение, которое должно быть принято как правило.
- Кросс-опыление разработчиков + документация. Почему увольнение одного человека стало общей проблемой? Вполне возможно, что другие разработчики ничего не знали о том, что делает их коллега, или у нас нет документации? Похоже, настало время, чтобы этим заняться.
- Система мониторинга и резервирования. На случай проблем с сервером у каждого системного администратора должны быть бэкапы, резервная система, на которую буквально за 1 клик переносятся все данные, и мы можем продолжать работу. И если в данном случае это не так, это сигнал, что пора вплотную заняться этим вопросом.
Все перечисленные выше контрмеры — это системные вещи, которые могли не волновать нас раньше, но они очень сильно мешали нам работать и делали нашу систему непредсказуемой. Обратите внимание, как выглядело распределение до внедрения контрмер.
Разброс значений довольно большой: от минимально возможного до аномального, которое сложно прогнозировать и которым сложно управлять в системе. Введение контрмер позволит серьезно снизить разброс значений, устранить причины, которые приводят к появлению аномалии, и сделать систему более стабильной, а наши прогнозы достоверными.
Продолжаем анализ
Давайте посмотрим, что еще можно увидеть на этой диаграмме.
Треугольник
На этом графике мы видим некий треугольник, а именно — восходящий тренд. Для нас это сигнал, что Lead Time со временем становится хуже, задачи выполняются дольше. А значит, самое время бить в колокола: использовать WIP-лимиты и стабилизировать систему.
Пустоты
На этом графике мы явным образом видим пробелы, отсутствие значений, это ситуации, когда никакие задачи не закрывались. Что это значит? Возможно, были какие-то длинные выходные или произошла авария. Однозначно стоит обратить на это внимание, вспомнить, проанализировать и принять решение, нужно ли что-то с этим делать.
Сильное рассеяние
На этом графике мы видим типичный пример сильного рассеяния — точки беспорядочно разбросаны по всему графику. К сожалению, это говорит о том, что система совершенно непредсказуема, не подчиняется никаким закономерностям и придется предпринять много усилий, чтобы получить какую-то закономерность, повторяемый результат.
Выброс
Давайте посмотрим еще один пример. У нас есть некий набор значений, и вдруг мы замечаем некий выброс, всплеск, положение которого сильно отличается от остальных показателей. Что это значит? Возможно, это задача, которую положили в бэклог, но затем забыли про нее, а потом и «забили», то есть по каким-то причинам решили не делать совсем. В любом случае это повод поговорить и разобраться, что в данном конкретном случае произошло и что нужно предпринять, чтобы избежать подобных аномалий в будущем.
Таким образом, диаграмма рассеяния Lead Time в деталях покажет вам, где находятся аномалии, после чего вы сможете начать с ними системную работу. Устраняя аномалии, вы делаете систему стабильной и предсказуемой.
Кумулятивная диаграмма потока (Cumulative Flow Diagram)
Есть еще один график, который позволяет понять, насколько стабильна наша система. Это кумулятивная диаграмма потока (Cumulative Flow Diagram).
Для начала разберем, как ее построить. Вспомним, что у нас есть рабочая доска, на которой отражены разные этапы выполнения работы. Ежедневно на каждом этапе есть какое-то количество задач, для построения диаграммы мы должны завести отдельную таблицу и каждый день фиксировать ту же информацию о статусах и количестве задач в ней.
Полученные результаты обозначают разным цветом и откладывают на диаграмме кумулятивно, то есть суммируя значение предыдущего дня с текущим, далее со значением следующего дня и так далее.
В итоге у нас получается нарастающий итог. По вертикали отмечаем количество задач в колонках, по горизонтали — даты. Полученная диаграмма показывает работу нашей системы в динамике, мы видим, что происходило в течение определенного периода времени на этапе анализа, тестирования, приемки и так далее.
Кроме того, на диаграмме мы явно видим Lead Time — это горизонтальное расстояние от момента, когда начали делать задачу (колонка «Идеи»), до даты, когда мы завершили работу с ней и переместили ее в столбец «Готово».
Важный момент: очевидно, что на графике за разные периоды времени мы получаем разный Lead Time. И это однозначно говорит о том, что система нестабильна. Скорее всего, мы получим усредненный Lead Time, потому что на него влияет множество разных факторов, тем не менее даже это среднее значение позволит нам понять, что происходит с системой.
Как выглядит стабильная система?
На любом отрезке времени Lead Time должен быть одинаковым. Этого трудно добиться, и конечно, на графике мы видим идеальную картинку, но это состояние, к которому нужно стремиться. Если мы работаем в стабильной системе, мы уверены в наших прогнозах, потому что есть повторяемость результатов, понятный и прозрачный процесс, нам хорошо известны правила и возможные ограничения. И теперь наш замечательный менеджер, который всегда хочет знать точные сроки, сможет выдохнуть и с уверенностью сказать: «Да, я уверен в сроках, которые называю заказчикам».
Остались вопросы? Буду рад ответить в комментариях после статьи или в моем Телеграм-канале «Данные в дейSTвии».
В следующей статье поговорим о том, что такое Cost of Delay и как с его помощью определять приоритетность задачи.
Чем Канбан отличается от Scrum? Для чего нужна Канбан-доска? Каким командам подойдет Канбан-метод и с чего начать? Я подготовил развернутый гайд, где постарался ответить на самые популярные вопросы, которые встречались в моей практике, максимально простым языком. В статье рассмотрим, что такое Канбан-метод, обсудим его преимущества, узнаем, в каких сферах используется Канбан и как эффективно внедрить его в своей команде.
«Эта задача очень срочная, и не забывайте про вчерашние запросы — они мне нужны в первую очередь». Как часто вы слышали такое от заказчика? К сожалению, в условиях отсутствия WIP-лимитов подобные ситуации не редкость. И спустя какое-то время рабочая система будет просто переполнена различными запросами. Ведь мы не можем делать всё и сразу. В итоге — сроки не будут соблюдаться, задачи выполняться, а система работать всё медленнее и медленнее. Можно ли это исправить? В статье обсудим, почему не работают приоритеты и как использовать Cost of Delay, чтобы определить очередность задач
В новом материале цикла статей «Канбан просто» я расскажу, почему «сгорают» незавершенные задачи, как визуализировать ограничения, чтобы наладить диалог с бизнесом и повысить предсказуемость процесса и, конечно, как в этом нам помогут Канбан-доска и WIP-лимит.