Аномалии детектед. Как они влияют на бизнес-процессы

Сроки сдвигаются, система ломается, предсказуемость стремится к нулю — так влияют аномалии на бизнес-процессы. Как обнаружить аномалии и какие контрмеры помогут их устранить? Разбираем на реальных примерах.

Мы с вами уже многому научились: умеем разделять задачи по типам, быстро и обоснованно прогнозировать сроки выполнения задач с вероятностью до 80, 90 и даже 100%, знаем, чем чреваты перегрузки в рабочих процессах и как их эффективно устранить. Здорово, правда?

Но сразу возникает вопрос: а как всё будет в реальной жизни? Ну конечно, гораздо сложнее. Настало время настоящих хардкорных примеров, которые с высокой долей вероятности вы встретите в своих командах. Спойлер: мы справимся и с ними!

Итак, давайте представим, что вы измерили время выполнения задач в 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 событий: заболел заказчик, из команды ушел ведущий разработчик и в довершение всего сломался сервер.

Возможные системные контрмеры:

Все перечисленные выше контрмеры — это системные вещи, которые могли не волновать нас раньше, но они очень сильно мешали нам работать и делали нашу систему непредсказуемой. Обратите внимание, как выглядело распределение до внедрения контрмер.

Разброс значений довольно большой: от минимально возможного до аномального, которое сложно прогнозировать и которым сложно управлять в системе. Введение контрмер позволит серьезно снизить разброс значений, устранить причины, которые приводят к появлению аномалии, и сделать систему более стабильной, а наши прогнозы достоверными.

Давайте посмотрим, что еще можно увидеть на этой диаграмме.

Треугольник

На этом графике мы видим некий треугольник, а именно — восходящий тренд. Для нас это сигнал, что Lead Time со временем становится хуже, задачи выполняются дольше. А значит, самое время бить в колокола: использовать WIP-лимиты и стабилизировать систему.

Пустоты

На этом графике мы явным образом видим пробелы, отсутствие значений, это ситуации, когда никакие задачи не закрывались. Что это значит? Возможно, были какие-то длинные выходные или произошла авария. Однозначно стоит обратить на это внимание, вспомнить, проанализировать и принять решение, нужно ли что-то с этим делать.

Сильное рассеяние

На этом графике мы видим типичный пример сильного рассеяния — точки беспорядочно разбросаны по всему графику. К сожалению, это говорит о том, что система совершенно непредсказуема, не подчиняется никаким закономерностям и придется предпринять много усилий, чтобы получить какую-то закономерность, повторяемый результат.

Выброс

Давайте посмотрим еще один пример. У нас есть некий набор значений, и вдруг мы замечаем некий выброс, всплеск, положение которого сильно отличается от остальных показателей. Что это значит? Возможно, это задача, которую положили в бэклог, но затем забыли про нее, а потом и «забили», то есть по каким-то причинам решили не делать совсем. В любом случае это повод поговорить и разобраться, что в данном конкретном случае произошло и что нужно предпринять, чтобы избежать подобных аномалий в будущем.

Таким образом, диаграмма рассеяния Lead Time в деталях покажет вам, где находятся аномалии, после чего вы сможете начать с ними системную работу. Устраняя аномалии, вы делаете систему стабильной и предсказуемой.

Есть еще один график, который позволяет понять, насколько стабильна наша система. Это кумулятивная диаграмма потока (Cumulative Flow Diagram).

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

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

В итоге у нас получается нарастающий итог. По вертикали отмечаем количество задач в колонках, по горизонтали — даты. Полученная диаграмма показывает работу нашей системы в динамике, мы видим, что происходило в течение определенного периода времени на этапе анализа, тестирования, приемки и так далее.

Кроме того, на диаграмме мы явно видим Lead Time — это горизонтальное расстояние от момента, когда начали делать задачу (колонка «Идеи»), до даты, когда мы завершили работу с ней и переместили ее в столбец «Готово».

Важный момент: очевидно, что на графике за разные периоды времени мы получаем разный Lead Time. И это однозначно говорит о том, что система нестабильна. Скорее всего, мы получим усредненный Lead Time, потому что на него влияет множество разных факторов, тем не менее даже это среднее значение позволит нам понять, что происходит с системой.

На любом отрезке времени Lead Time должен быть одинаковым. Этого трудно добиться, и конечно, на графике мы видим идеальную картинку, но это состояние, к которому нужно стремиться. Если мы работаем в стабильной системе, мы уверены в наших прогнозах, потому что есть повторяемость результатов, понятный и прозрачный процесс, нам хорошо известны правила и возможные ограничения. И теперь наш замечательный менеджер, который всегда хочет знать точные сроки, сможет выдохнуть и с уверенностью сказать: «Да, я уверен в сроках, которые называю заказчикам».

В следующей статье поговорим о том, что такое Cost of Delay и как с его помощью определять приоритетность задачи.

Если хотите поделиться своим кейсом или у вас остались вопросы к статье — оставляйте их в комментариях и подписывайтесь на наш ТГ-канал, чтобы не пропустить интересные материалы из мира современного менеджмента.

Автор: Василий Савунов, Agile-коуч и эксперт ScrumTrek