Определение Потоков Ценности и Поездов в SAFe

Как организоваться вокруг ценности?

«Устраняйте барьеры между подразделениями.»

Уильям Эдвардс Деминг

Потоки создания ценности и Релизные Поезда (Agile Release Train, ART) являются основополагающими элементами в Scaled Agile Framework. Поэтому для успеха SAFe трансформации так важно определить потоки ценности в организации и сформировать поезда для них.

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

Процесс «Организоваться вокруг ценности» включает в себя следующие шаги:

1. Определить Операционные Потоки Ценности
2. Определить Решения, которые Операционные Потоки Ценности используют или предоставляют клиентам
3. Определить людей, которые разрабатывают и поддерживают решения
4. Определить Разработческие Потоки Ценности, которые разрабатывают решения
5. Добавить людей, которые необходимы для создания всего бизнес-решения
6. Сформировать Релизные Поезда (Agile Release Train, ART) для реализации Разработческих Потоков Ценности

Далее в статье мы подробнее рассмотрим каждый из этих шагов.

Что такое Поток Ценности?

Поток создания ценности – это основной элемент в SAFe для понимания ценности, организации вокруг неё и собственно доставки ценности клиентам. Как показано на рисунке 1, каждый поток ценности представляет собой долгосрочную последовательность шагов, используемых для создания ценности — от создания концепции до доставки конкретных результатов клиенту. Поток создания ценности определяет следующую хронологию действий, их содержание и участников:

Рисунок 1. Анатомия потока создания ценности

• Триггер – Какое-то важное событие запускает поток ценности. Например, заказ клиента или запрос на новую фичу. Поток ценности завершается, когда какая-то ценность — отправка продукта, совершение покупки клиентом или ввод решения в эксплуатацию— доставлена.
• Шаги – Процесс между триггером и получением клиентом ценности — это шаги, которые предприятие предпринимает для получения результата [1].
• Ценность – Клиент получает ценность, когда поток ценности выполняет свои шаги.
• Люди и системы – Поток создания ценности также содержит людей, которые выполняют работу, системы, которыми эти люди управляют, а также поток информации и материалов.
• Время выполнения (Lead time) – Время, проходящее с момента возникновения триггера до доставки ценности — это общее время выполнения (или Время Потока). Уменьшение времени выполнения сокращает время выхода на рынок (time-to-market). Самый простой способ сократить время выполнения — выявить и свести к минимуму (или устранить) виды деятельности, которые не приносят ценности, и приводят к значительным задержкам. Это основной фокус Бережливого Мышления.

Типы потоков создания ценности

Обратите внимание, что существует два типа потоков создания ценности [1], как показано на рисунке 2.

Рисунок 2. Операционные и разработческие потоки создания ценности

• Операционные потоки ценности (Operational Value Streams, OVS) – состоят из шагов и людей, которые доставляют ценность для конечного пользователя с помощью бизнес-решений, созданных разработческими потоками создания ценности.
• Разработческие потоки ценности (Development Value Streams, DVS) – cоcтоят из шагов и людей, которые разрабатывают бизнес-решения, используемые операционными потоками создания ценности.

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

1. Определенить операционных потоков ценности

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

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

• Кто ваши пользователи и клиенты? Являются ли они внутренними, внешними или и тем, и другим для вашей организации?
• Какие продукты и сервисы вы выводите на рынок, продаете и поддерживаете?
• Какие решения вы предоставляете для внутренних пользователей?
• Что запускает поток ценности? Что является триггером для потока ценности?
• Как клиенты сами описывают ценность, которую они получают от вас?

Как правило, операционные потоки ценности подразделяются на один из четырех типов, показанных на рисунке 3:

• Потоки ценности «Исполнение» представляют собой шаги, необходимые для обработки запроса клиента, доставки продукта или услуги с использованием цифровых технологий и получения вознаграждения. Примеры: предоставление потребителю страхового продукта или выполнение заказа клиента Интернет-магазина.
• Потоки ценности «Производство» преобразуют сырьё, материалы и полуфабрикаты в продукты, которые покупают клиенты. Примеры: потребительские товары, медицинские устройства и сложные киберфизические системы.
• Потоки ценности «Программные продукты» предлагают и поддерживают программные продукты. Примеры: ERP системы, SaaS, а также настольные и мобильные приложения.
• Потоки ценности «Поддержка» включают в себя сквозные рабочие процессы для различных вспомогательных видов деятельности. Примеры: найм и удержание сотрудников, заключение контрактов с поставщиками, выполнение годового бюджета и завершение всего цикла корпоративных продаж.

Рисунок 3. Примеры четырех типов операционных потоков создания ценности

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

Само собой разумеется, что крупные предприятия обычно предлагают своим клиентам широкий спектр товаров и услуг. Это один из способов их роста. Таким образом, внутри этих предприятий существуют большие и комплексные потоки ценности. На рисунке 4 показано, что в крупном коммерческом банке поток ценности «Потребительские кредиты» является лишь одним из его предложений и операционных потоков ценности [2].

Рисунок 4. Операционные потоки ценности в коммерческом банке

Шаблон для определения потока создания ценности

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

Рисунок 5. Шаблон для определения потока ценности на примере операционного потока ценности

2. Определить решения, которые Операционные потоки ценности используют или предоставляют клиентам

После того, как определены шаги Операционного потока ценности, необходимо определить решения, которые требуются для его поддержки. Важно составить карту связей между решениями и различными шагами потока ценности и определить людей, которые работают с этими решениями. Карта позволяет глубже понять, как это всё работает, как показано на примере потребительного кредита на рисунке 6.

Рисунок 6. Определение систем, которые поддерживают шаги потока ценности

3. Определить людей, которые разрабатывают и поддерживают решения

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

Рисунок 7. Определение людей, которые разрабатывают системы

4. Определить Разработческие потоки ценности, которые создают решения

Следующим шагом является определение Разработческих потоков ценности, которые отражают последовательность шагов, необходимых для разработки решений, и людей, которые их создают. Эти решения поддерживают и повышают эффективность Операционных потоков ценности. Таким образом, ценность заключается в создании нового функционала или изменении существующего функционала (фич) решений. Триггерами для Разработческих потоков ценности являются потребности и идеи, которые развивают этот функционал.

Рисунок 8. Определение разработческих потоков создания ценности

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

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

Несмотря на то, что нет никаких ограничений относительно того, как предприятие может сконфигурировать разработческие потоки ценности, на практике сформировались определенные шаблоны (паттерны) формирования потоков ценности. Они описываются в статье «Разработческие потоки ценности». Перейти на статью на сайте Scaled Agile, Inc.: https://scaledagileframework.com/development-value-streams/

5. Добавить людей, которые необходимы для независимого от остальной организации создания бизнес-решения

Разработческие потоки ценности доставляют инновационные бизнес-решения, поэтому для реализации этой задачи недостаточно только вклада Agile-команд. Все, кто участвует в разработке бизнес-решений, включая представителей таких подразделения, как: операционная деятельность, юридическая служба, маркетинг, финансы, поддержка, соответствие требованиям (комплаэнс), безопасность и других, — считаются частью разработческого потока ценности. Учитывая это, следующим шагом является определение дополнительных людей и команд, которые являются частью разработческих потоков ценности, определенных на предыдущем шаге.

Рисунок 9. Добавьте людей, которые необходимы для создания бизнес-решения целиком

В примере на рисунке 9 первый разработческий поток ценности, ориентированный на процесс рассмотрения заявок на кредиты, включает представителей маркетинга для разработки рекламных материалов и кампаний по привлечению клиентов. В этот поток ценности также входят сотрудники юридической службы для определения соответствующих условий предлагаемых кредитов. Второй разработческий поток ценности, который развивает Автоматизированную Банковскую Систему (АБС), также управляет погашением кредитов. Поэтому он включает представителей маркетинга для управления регулярными коммуникациями с существующей базой клиентов. Оба потока ценности включают в себя команды поддержки для реагирования на любые проблемы, которые могут возникнуть у клиентов, и командами эксплуатации, которые управляют стабильностью этих систем в рабочей среде.

Границы Разработческих Потоков Ценности не соответствуют иерархии и географии

После того, как разработческие потоки ценности определены, следующим шагом является формирование Agile Release Trains (ART) для их реализации. Поезда содержат всех людей и другие активы, необходимые для улучшения потока ценности. Первый шаг — понять, где в организации создается ценность, потому что именно там находятся люди, процессы и системы. На этом этапе, как правило, становится очевидным, что в процессе создания ценности разработческие потоки ценности пересекают множество организационных границ. Текущая структура предприятия появилась в существующем виде в следствии различных причин: историческое развитие, функциональное удобство, эффективность централизации, купля-продажа, географическое расположение и многое другое. В результате, никто не может понять всю последовательность действий, необходимых для разработки и совершенствования систем, которые помогают непрерывно доставлять ценность. Кроме того, меры по корректировки часто сосредоточены на функциональных, локальных улучшениях, которые могут привести к оптимизации одной функции или одного шага, но не могут оптимизировать сквозной поток.

Долгосрочное существование потоков ценности в Lean-Agile организации порождает иное мышление. Как правило, крупные предприятия организованы вокруг функций. Кроме того, люди в них часто распределены географически. Но ценность перемещается за эти границы, как показано на рисунке 10.

Рисунок 10. Потоки ценности проходят через функциональные, организационные и географические границы

6. Сформировать Релизные Поезда для реализации Разработческих Потоков Ценности

Последний шаг состоит в том, чтобы определить Релизные Поезда, которые реализуют ценность. Как правило, наиболее эффективные ART обладают следующими свойствами:

• В Поезд входит 50 – 125 человек
• Поезд сфокусирован на создании целостного решения или связанных с ним продуктов или сервисов
• Поезд состоит из долгоживущих, стабильных команд, которые непрерывно доставляют ценность
• Поезд имеет минимальное количество зависимостей с другими Поездами (ART)
• Поезд может выпускать решение или его элементы независимо от других Поездов

В зависимости от того, сколько людей выполняют работу, существует три возможных сценария дизайна ART, как показано на рисунке 11.

Рисунок 11. Три возможных сценария дизайна ART

• Несколько небольших разработческих потоков ценности могут быть реализованы с помощью одного ART – Когда несколько связанных продуктов или решений могут быть созданы относительно небольшим количеством людей, то один Поезд может обеспечить реализацию нескольких потоков ценности.
• Один разработческий поток ценности может быть реализован в рамках одного ART – Чаще всего поток создания ценности может быть реализован с помощью 100 или менее участников. Большое количество существующих групп разработки имеют приблизительно такой размер. В связи с чем 2-й сценарий достаточно распространен на практике. В этом случае ART соответствует потоку ценности.
• Несколько Поездов необходимы для реализации крупных разработческих потоков ценности – Когда в процесс вовлечено много людей, разработческий поток ценности должен быть разделен на несколько Релизных Поездов (ART), которые вместе формируют Поезд Решения. Этот сценарий мы рассмотрим далее в статье.

Разделение крупных Потоков Ценности на несколько Релизных Поездов

Большие разработческие потоки ценности широко распространены на крупных предприятиях. И этот сценарий требует дополнительного анализа. Поезда должны быть сосредоточены на одном основном решении или наборе тесно связанных продуктов или сервисов. В небольших потоках ценности применяется относительно простая конструкция — один ART доставляет четко определенный набор решений.

Однако, когда для создания одного решения требуется много людей, то для его разработки необходимо сформировать несколько ART, которые взаимодействуют друг с другом внутри Поезда Решения. Для достижения общей цели непрерывной доставки ценности каждый ART в рамках Solution Train должен быть спроектирован таким образом, чтобы максимизировать поток Поезда Решения.

Для формирования Agile команд и Поездов SAFe рекомендует применять топологии команд [4]:

• Команда, организованная вокруг потока (Stream-aligned team) – команда организована вокруг потока работы и способна доставлять ценность непосредственно клиенту или конечному пользователю
• Команда сложной подсистемы (Complicated subsystem team) – команда организована вокруг конкретных подсистем, требующих глубоких профессиональных навыков и знаний
• Команда платформы (Platform team) – команда организована вокруг разработки и поддержки платформ, предоставляющих услуги другим командам
• Помогающая команда (Enabling team) – команда организована для того, чтобы помочь другим командам приобрести недостающие компетенции и помочь им овладеть новыми технологиями

Эти топологии могут помочь организациям определить оптимальные дизайны Релизных Поездов внутри Поезда Решения (рис. 12).

Рисунок 12. Применение топологии к формированию Поездов внутри Поезда Решения

Примечание: «Помогающий Поезд» может быть исключением при применении топологий к Поездам. Несмотря на то, что обычно две или три Помогающие команды функционируют внутри портфеля и они со-направлены относительно единой цели, маловероятно, что такие команды смогут сформировать целый Помогающий ART в Поезде Решения.

Далее в статье мы рассмотрим подробнее масштабирование этих топологий для организации Релизных Поездов (Agile Release Train, ART).

Поезда, организованные вокруг потока (Stream-aligned ARTs)

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

Зоны ответственности поездов этого типа в целом схожи с зонами ответственности команд, организованных вокруг потока.

Поезда сложной подсистемы (Complicated subsystem ARTs)

Большинство крупных систем также включают в себя масштабные подсистемы. Это означает, что при создании крупномасштабных систем ожидается, что будут созданы Поезда сложной подсистемы, которые помогут снизить когнитивную нагрузку на потоковые ART. Например, для создания системы управления автономным транспортным средством вполне может потребоваться отдельный Релизный Поезд сложной подсистемы.

Платформенные поезда (Platform ARTs)

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

Помогающие поезда (Enabling ARTs)

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

И, конечно же, в крупных потоках ценности часто встречается комбинация всех четырех типов поездов, как показано в нашем последнем примере на рисунке 13.

Рисунок 13. Комбинация топологий Поездов на примере потока ценности «Потребительский Кредит» банка

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

Узнать больше:
[1] Ward, Allen. Lean Product and Process Development (video). Lean Enterprise Institute, 2004.
[2] Contributed by Wilmshurst, Darren, Murray Ford, Per-Magnus Skoogh, Phillip Manketo, Sam Bunting, and Virpi Rowe.
[3] Knaster, Richard, and Dean Leffingwell. SAFe 5.0 Distilled, Achieving Business Agility with the Scaled Agile Framework. Addison-Wesley, 2020.
[4] Skelton, Matthew, and Manuel Pais. Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press, 2019.

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом статьи «Organize around value».