что такое value stream

Безжалостное непрерывное улучшение оргструктуры по SAFe

Инструменты SAFe для проектирования на старте Agile-трансформации и постоянного совершенствования оргструктуры.

Нужна быстрая поставка ценности клиенту?
Ломайте преграды между департаментами!
(c) Эдвардс Деминг

Потоки создания ценности (Value Stream) и поезда (Agile Release Trains, ARTs) являются самой важной частью фреймворка SAFe (Scaled Agile Framework). Без правильного организационного дизайна вы столкнетесь с множеством зависимостей и замедлением скорости поставки.

5 шагов дизайна

Нужно пройти 5 шагов для идентификации поездов:

Value Stream

Value Stream — это последовательность действий по созданию ценности от первичного запроса до поставки итогового результата клиенту.

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

Понятие Value Stream также включает:

Типы Value Stream

Выделяют два типа Value Stream:

Для того, чтобы наиболее оптимальным способом спроектировать разработческие Value Stream, необходимо сначала построить карту операционных Value Stream.

Шаг 1. Определите операционные Value Stream

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

Для определения начните с вопросов из таблицы:

Шаблон описания Value Stream

Этот шаблон описывает общие характеристики, которые полезно определить до анализа Value Stream.

Пример операционного Value Stream предоставления кредитов физическим лицам

Рассмотрим пример из банковской сферы по получению кредита:

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

Эта карта похожа на Customer Journey Map (CJM, карта путешествия потребителя) за исключением того, что цель применения этого инструмента иная. CJM выявляет проблемные области и подсказывает, как увеличить продажи и повысить лояльность клиентов. Операционный Value Stream в SAFe визуализируется для оптимизации организационной структуры.

Шаг 2. Определите системы, которые поддерживают операционный Value Stream

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

Шаг 3. Определите людей, участвующих в разработке

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

Шаг 4. Определите разработческий Value Stream

На следующем шаге мы переходим к определению разработческого Value Stream.

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

Анализ входящих требований позволяет понять, сколько будет разработческих Value Stream. К примеру, если бОльшая часть требований требует изменения всех систем, вероятно, будет один разработческий Value Stream. А если системы не сильно связаны, то можно разбить Value Stream на несколько (при необходимости).

Как бы вы их не спроектировали, разработческие Value Stream должны быть по максимуму независимы между собой.

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

Разработческие Value Stream являются сквозными к организационной структуре

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

Бережливые (Lean) организации нацелены на улучшение всего потока целиком. Это требует понимания, как лучше всего организовать взаимную работу разных частей организации.

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

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

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

Шаг 5. Определение ART

Заключительный шаг — это определение ART, которые реализуют добавленную ценность.

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

Практический опыт показывает, что поезда наиболее эффективны когда:

Возможны три конфигурации дизайна поезда.

1) Один поезд реализует несколько Value Stream:

2) Один поезд реализует один Value Stream:

3) Для крупного решения необходимо несколько поездов:

Разделение Value Stream на несколько ART

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

Зависимости могут быть продуктовые, а могут быть компонентными, поэтому группировка может быть двух типов:

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

Также можно закрепить за поездом нескольких шагов (сегментов/сервисов) Value Stream. В этом случае поезд не является полностью сквозным и для каждого сегмента необходимо определить входные параметры и ожидаемую конечную ценность, провести границу между сегментами.

Рассмотрим примеры дизайнов поездов из опыта различных компаний.

У каждого канала свой поезд + есть платформенный поезд:

У каждого продукта свой поезд (внутри поезда охвачены все каналы) + есть платформенный поезд:

По шагам Value Stream без платформенного поезда:

В этом случае каждый поезд отвечает за часть шагов Value Stream, а в развитие платформы вкладываются все 3 поезда.

Выбор оптимального варианта дизайна поездов

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

Воркшоп по дизайну поездов

Набор инструментов предлагает проверенный, системный подход для оптимизации дизайна с учетом зависимостей, координации и ограничений компании.

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

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

Видео доклада Сергея Рогачева на конференции Enterprise Agile Russia 2019 «Безжалостное непрерывное улучшение оргструктуры по SAFe»

Источник

Составление карт потоков создания ценности (VSM)

Узнайте, как оптимизировать конвейер CD с помощью этого метода анализа.

Что такое составление карт потоков создания ценности?

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

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

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

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

Если вы знакомы с концепцией непрерывной поставки, то наверняка представляете, как можно применить систематизацию потока ценности в этом процессе и получить пользу. Но прежде чем перейти к этому вопросу, рассмотрим некоторые преимущества и недостатки метода.

Систематизация потока ценности: история метода

Предполагается, что идея систематизации потока ценности впервые появилась в корпорации Toyota Motor. Однако это спорный вопрос. Возможно, Toyota позаимствовала этот метод из других источников или он возник естественным образом в ходе обмена идеями между членами сообщества бережливого производства. Ранние версии диаграмм, представляющих потоки материалов и информации, можно найти уже в книге Чарльза Э. Кнеппеля «Внедрение методов повышения эффективности», которая была опубликована в 1918 году.

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

Преимущества систематизации потока ценности

Систематизация потока ценности крайне важна для устойчивого развития бизнеса. И вот почему.

Проблемы систематизации потока ценности

Если не проявлять должной осторожности, систематизация потока ценности может оказаться затратным мероприятием сама по себе. Вот как можно избежать распространенных ошибок:

Короче говоря, систематизировать поток ценности полезно, но если перестараться, это может стать причиной новых проблем.

Примеры использования систематизации потока ценности

Вкратце рассмотрим преимущества систематизации потока ценности для различных отраслей. Сфера применения определяет набор элементов на карте потока ценности.

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

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

Как систематизация потока ценности позволяет выявить и сократить потери

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

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

В бережливом производстве выделяют семь видов потерь.

Перепроизводство

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

Запасы

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

Перемещение

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

Дефекты

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

Излишняя обработка

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

Ожидание

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

Транспортировка

Потери от транспортировки очень похожи на потери от перемещения. Потери от транспортировки возникают при внешних перевозках между несколькими пунктами или при внутренних перемещениях в пределах одного пункта у сторонних партнеров.

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

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

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

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

Недоработка

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

Избыточные возможности

Избыточные возможности, или «неконтролируемое расширение возможностей», вызывают потери из-за ненужного расширения объема работы. Избыточные возможности — это возможности, созданные компанией наугад без запроса пользователей. Избыточные возможности создаются с благими намерениями, но часто в отрыве от реальных потребностей клиентов.

Переподготовка

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

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

Передача работы

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

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

Задержки

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

Переключение между задачами

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

Дефекты

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

Символы на картах потока ценности

Существуют стандартные символы для схематичного представления потока ценности.

Пошаговая инструкция по систематизации потока ценности

1. Определите проблему, которую вы решаете

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

2. Доверьте задачу подходящей команде

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

3. Задайте границы процесса

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

4. Составьте карту выбранного процесса

Обязательно проверьте выбранный процесс. Это может поменять картину, так как непосредственный опыт нельзя заменить описанием (оно может быть предвзятым) и документацией, написанной другими сотрудниками (она может быть неполной и неточной).

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

5. Соберите данные о процессе

Систематизируя поток ценности, заносите данные о процессе в поля данных на карте. Данные о процессе включают в себя (помимо прочего) количество вовлеченных людей, среднее количество рабочих часов, время цикла, время ожидания, время бесперебойной работы, время простоя и так далее.

6. Создайте график

Создайте карту затрат времени на процессы и выполнение.

7. Оцените текущую карту

Задавайте вопросы. Много ли зависимостей связывает команды? Не слишком ли велико время выполнения? Если да, не связано ли это с тем, что наборы тестов не выполняются (или не могут выполняться) параллельно? Все ли среды стабильны? Не наблюдаются ли при тестировании периодические сбои, которые команды не в состоянии воспроизвести?

Или, может быть, в вашем процессе есть этапы, которые вы считаете ценными, но которые ничего не значат для клиента? Анализируя информационный поток, ищите в нем застойные и узкие участки. Обращайте внимание на тип операций (отправка или получение).

8. Спроектируйте будущую карту

Возможно, вам не удастся создать полную и окончательную версию, но это нормально. Убедитесь, что ваша новая карта соответствует видению компании.

Помните: ничто не постоянно. Исходя из потребностей клиентов, вносите постоянные корректировки.

9. Реализуйте будущую карту

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

Если вам интересно посмотреть, как выглядит конечный продукт, вот пример карты потока ценности.

Систематизация потока ценности для непрерывной поставки

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

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

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

Зачем внедрять карты потоков создания ценности в своей команде?

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

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

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

Источник