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

1. Работа которую возможно надо делать, но по ней мы не дали обещания, что ее сделаем (еще ее называют Backlog)
2. Запланированная работа, которую мы уже пообещали сделать, но ее не приступили к ней (To do)
3. Работа над которой работаем (in Progress)
4. Сделанная работа, по которой наши обещания исполнилось (Done)

Обратите внимание на первый пункт: это список работ, где есть элементы работы, которые не надо делать никогда. И здесь нужно учитывать контекст, где ваш поток находится. Если это ресторан, то людей, которые находятся в очереди на входе в ресторан вы не обязаны обслужить всех и более того, можете выбирать кого обслужить, а кого нет. Например, соответствует вашему дресс-коду или нет. (вспоминаем про  конкурс красоты ) Если вы техническая поддержка или служба оперативного реагирования, то вам нужно обслужить все запросы и как можно скорее. В этом случае, у вас нет пункта backlog и вся работа сразу попадает в To Do, а это значит, что вы по ней уже дали обещание (SLA договоренность об уровне сервиса) и время для клиента начинает тикать моментально.

Давайте подумаем, а как мы вообще начали думать об эффективности потока?

Бизнес всегда думает об эффективности, и первая эффективность которой легче всего управлять — это эффективность использования ресурсов. Т. е. мы должны следить, чтобы у всех людей обе руки были заняты и чтобы все станки в цеху, столики в ресторане, операторы в колл-центре и т. д. были в работе 100% (или близко к этому) времени, в реальности получается 75-80%, остальное уходит на перерывы, покурить, ненужные встречи и т. д.

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

Обычно, следующий шаг — это увеличить количество людей (аналитиков, поваров, кассиров, программистов и т. д.), так как кажется что именно в этом вся проблема. СТОП. Если вы пришли к этой точке, то это тот самый момент, когда пора подумать, а что же у нас с эффективностью потока?

Формула подсчета Эффективности потока

Подсчет эффективности потока делается следующим образом:
Эффективность потока (в %) = Время работы / (Время работы + Время ожидания)
Где,
Время работы = Времени, когда карточка находилась в колонках вида “В работе” (т. е. когда создавала ценность) минус время, когда в них карточка была заблокирована
Время ожидания = Время блокировки плюс Время, когда карточка находилась в колонках вида “Готово”, “Закончено”, “Сделано” плюс Время в бэклоге (если наши обязательства распространяются на колонку Бэклог)

Обычная эффективность около 15%, т. е. 85% времени с элементом работы никто не занимался.

Чтобы подсчет эффективности потока стал возможен нам потребуется визуализация, как минимум в виде канбан-доски и сбор статистики по выполненным элементам работы.

Эффективность ресурсов и эффективность потока — это две стороны одной медали. Мы привыкли фокусироваться на активную составляющую нашей работы: написание автотестов, обучение сотрудников, выстраивание devops трубы, качество приготовляемой еды на кухне, скорость работы кассира и т. д. Это все правильно, но работа только на этим может быстро перестать давать положительный эффект и каждым новым уровнем улучшения стоит дороже, но и есть темная сторона: это время, когда мы просто ждем и природа этого времени может быть разной: зависимости, смена приоритетов, ожидание следующего этапа, блокировки и т. д.

То, что задача находится в работе и то, что над ней кто-то работает не одно и тоже, и Эффективность потока показывает как часто это бывает правдой.

Очевидно, что нужно сбалансировать эффективность потока и эффективность ресурсов

Для начала посмотрим о чем нам говорит закон Литтла:

Т. е. при сохранении скорости потока (сколько элементов работы выходят из нашей системы в единицу времени), мы можем сократить среднее время выполнения за счёт того, что сократим количество одновременно выполняемой работы. К чему это приведет: заказчики встанут в очередь и кому-то из них нужно говорить “нет” или “подожди”, а некоторые сотрудники будут простаивать, ведь при меньшем количестве работы ее может на всех не хватить и это хорошо.

Дальше, мы должны убедиться, что мы рассматриваем единую систему создания ценности (в начале, в конце или с обоих концов должен быть внешний клиент) — это поможет нам избежать ловушки локальной оптимизации. И вот только теперь мы начинаем смотреть на корневые причины возникновения этапов “Ожидания”, делаем эксперименты по уменьшению времени ожидания и подбор лимитов незавершенной работы (об этом можно почитать:
WIP лимиты — часть 1
WIP лимиты — часть 2 ) .

Еще видео о ловушке утилизации ресурсов