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

Принцип одного изделия в потоке (one piece flow) проявился в том, что команда DevOps в процессе реализации проекта «Феникс» настолько овладела подходом, что в конце игры уже не использовала второй ряд столов. Это означает, что задачи проходили через весь процесс без скопления промежуточных запасов, каждая следующая задача могла начаться сразу после завершения предыдущей, что исключило простои и сократило время цикла выполнения задачи. Такой уровень отлаженности процесса позволяет максимально уменьшить время ожидания, избегать параллельного выполнения множества задач, что обычно приводит к снижению производительности из-за многозадачности и переключений контекста.

ITIL 4 упрощает формулирование ключевых показателей эффективности (KPI) благодаря подробному описанию каждого фактора успеха практики (PSF) и предоставлению сопровождающих примеров метрик, которые можно использовать в качестве KPI. Описания практик в ITIL 4 стали более практико-ориентированными, что позволяет легче определить, какие показатели следует измерять для оценки эффективности конкретных практик в контексте их вклада в потоки создания ценности. В ITILv3 подход был более процесс-ориентированным, и, хотя концепция CSF также позволяла формулировать KPI, в ITIL 4 это становится проще благодаря более структурированному и конкретному описанию факторов успеха.

В Lean-подходе Lead Time — это время от момента поступления запроса до его выполнения, то есть общий период, который заказчик ожидает результата. Process Time (также называемое Touch Time или Task Time) — это время, когда непосредственно осуществляется работа над запросом, без учета времени ожидания в очередях. Основная разница в том, что Lead Time учитывает все задержки и время ожидания, тогда как Process Time фокусируется только на активной работе. Поскольку именно Lead Time определяет восприятие скорости выполнения работы заказчиком, оптимизация обычно направлена на сокращение именно этого показателя, а не Process Time. Однако отношение Process Time к Lead Time служит важным индикатором общей эффективности потока.

Work in progress (WIP) лимит - это ограничение на количество элементов (историй, задач), которые команда может одновременно обрабатывать на первом этапе конвейера разработки. WIP лимит влияет на скорость работы команды следующим образом: уменьшение количества элементов, допущенных в обработку одновременно, уменьшает переключение контекстов, увеличивает фокусировку на текущих задачах и позволяет элементам быстрее проходить через весь конвейер разработки. Это явление иногда называют "меньше впустим - быстрее пролетит". WIP лимиты помогают выявить узкие места в процессе, улучшают поток работы и увеличивают общую производительность команды, предотвращая перегрузку.

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

Одним из ключевых факторов, которые могут помешать успешному внедрению методологий вроде Scrum или Kanban, является отсутствие мотивации сотрудников. Когда сотрудники не заинтересованы в выполнении новых задач, даже после завершения предыдущих, вся структура, построенная на основе таких методик, перестаёт функционировать. Например, если аналитики не считают нужным брать в работу новые задачи, это приводит к отсутствию входящего потока задач, что является фундаментальным условием для работы системы Kanban. Другие факторы, влияющие на внедрение методологий, могут включать недостаток компетенций сотрудников, непонимание целей методологии, а также отсутствие поддержки со стороны руководства. Таким образом, успешное внедрение любой методологии требует предварительного решения основных вопросов мотивации и подготовки персонала.

ITIL 4 определяет четыре аспекта управления ИТ-услугами, которые необходимо учитывать для целостного подхода: 1. Организации и люди - включают организационные структуры, операционные и ролевые модели, коммуникации, развитие сотрудников, культуру. 2. Информация и технологии - касаются инструментов предоставления услуг, систем хранения и обработки информации, технологических достижений включая ИИ и машинное обучение. 3. Поставщики и партнеры - охватывают отношения с внешними организациями, уровень интеграции и формальности взаимодействия, стратегию вовлечения поставщиков. 4. Потоки создания ценности и процессы - включают все виды деятельности, рабочие процессы, средства управления для достижения целей, комбинацию практик в цепочке создания ценности. Эти аспекты должны рассматриваться совместно и сбалансировано, так как они взаимосвязаны и перекрываются друг с другом.

Incident Rate — это метрика, показывающая количество пользовательских инцидентов в месяц на одного пользователя ИТ-системы. Для расчёта в числитель ставится количество обращений пользователей категории инцидент за месяц (рекомендуется брать годовую выборку с разбивкой по месяцам для исключения сезонности), а в знаменатель — количество активных пользователей ИТ (исключая уволенных сотрудников и технические учётные записи). Метрика измеряет поток пользовательских обращений, не учитываются инфраструктурные инциденты, инициированные ИТ-службой.

Ограничение работ в процессе (WIP) в системе Kanban — это установленный верхний предел количества задач, которые могут одновременно находиться на определённом этапе процесса. Это ограничение необходимо для предотвращения перегрузки рабочих этапов, снижения времени ожидания и повышения скорости прохождения задач через весь процесс. В DevOps-практиках WIP также позволяет зарезервировать ресурсы для неплановых задач, таких как решение инцидентов. В канбане можно устанавливать как общие ограничения для всего процесса, так и отдельные ограничения для разных категорий задач, что делает систему более гибкой и устойчивой к возникающим проблемам.