Value Stream Mapping (VSM) — это техника анализа и управления потоками материалов и информации, необходимых для создания продукта или услуги. Инструмент пришёл из бережливого производства, где его также называют «картированием потоков создания ценности» (KПСЦ). Суть метода в том, чтобы визуализировать все этапы работы с помощью системы специальных символов и оценить, какие из них действительно важны для клиента, а какие — нет. Главная цель VSM — найти и устранить операции, которые не добавляют ценности, и тем самым оптимизировать процесс.

Метод отлично подходит для любых процессов с повторяющимися шагами, особенно там, где много передач (handoffs). На производстве эти передачи видны невооружённым глазом, а в интеллектуальном труде потери часто скрыты в ожиданиях между этапами. Именно VSM помогает сделать эти неэффективные передачи заметными и, как следствие, улучшить коммуникацию в команде и общую продуктивность.

История возникновения метода

Истоки VSM часто связывают с Toyota, хотя это не совсем однозначный вопрос. Предшественники подобных диаграмм встречались ещё в литературе начала XX века. Внутри Toyota метод был известен как «картирование материальных и информационных потоков» и применялся почти как дополнительный инструмент. Всемирную известность VSM получил в 1990-е годы, когда успех Toyota и её бережливых методов сделал картирование потоков создания ценности современным стандартом для команд, стремящихся к максимальной эффективности.

О чём говорит карта потока создания ценности

Создание карты VSM помогает не просто сократить потери, но и увидеть их первопричину. Анализ обычно начинают с одного из трёх уровней.

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

Основные плюсы и минусы VSM

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

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

Семь видов потерь на производстве

Классификация потерь в VSM начинается с семи типов отходов, описанных ещё в бережливом производстве.

  • Перепроизводство. Создание продукта в объёме, большем, чем нужно клиенту. Оно тянет за собой дополнительные расходы на хранение, сырьё и замораживание капитала.
  • Запасы. Издержки на содержание и сохранность излишков: плата за складские площади, аренду, транспортировку, а также потери от порчи продукции.
  • Лишние перемещения (Motion). Любые движения людей или машин, которые можно минимизировать. Например, перемещение материалов вилочным погрузчиком через весь склад.
  • Брак (Дефекты). Исправление или полная потеря бракованной продукции. Сюда же относятся затраты на замену, утилизацию и повторное производство.
  • Излишняя обработка (Over-processing). Выполнение ненужных операций: добавление функций, которые клиент не заказывал, или шлифовка деталей, которые пользователь всё равно не увидит.
  • Ожидание (Waiting). Простои, вызванные медленными этапами обработки. Они порождают расходы на освещение, отопление, охлаждение и риск истечения сроков материалов или контрактов.
  • Транспортировка (Transport). Похожа на движения, но касается внешних перемещений между локациями или с участием сторонних партнёров.

Семь видов потерь в разработке ПО

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

  • Частично выполненная работа. Выпуск кода в неполном или недокументированном состоянии. Это порождает каскад дополнительной работы по доделке.
  • Лишние функции (Feature creep). Реализация того, о чём пользователи не просили. Даже если они сделаны из благих побуждений, такие фичи — всегда отрыв от реальных потребностей клиента.
  • Повторное обучение. Потери времени на решение уже решённых проблем из-за отсутствия документации. Или переучивание команды на очередной модный фреймворк, тогда как задачу уже умели решать на старом.
  • Передачи между людьми. Смена владельца задачи, потеря контекста, особенно при увольнении ключевых сотрудников. В худшем случае — неэффективная передача продукта из разработки в эксплуатацию.
  • Задержки. Остановка работы на каком-либо этапе из-за зависимости от другого отдела или человека. Особенно опасны в быстрых итеративных процессах.
  • Переключение задач. В отличие от передачи задачи другому человеку, это переключение одного специалиста между множеством дел. Постоянные прерывания, совещания и письма мешают разработчику войти в состояние потока.
  • Дефекты (Баги). Ошибки в коде, которые могут быть обнаружены пользователями уже после выпуска, что вызывает задержки и дополнительную поддержку.

Как построить карту потока создания ценности: пошаговая инструкция

Создание VSM разбивается на несколько последовательных шагов.

  • Шаг 1. Определите решаемую задачу с точки зрения клиента. Сформулируйте проблему и убедитесь, что все её понимают одинаково. Например, «клиентам кажется, что новые функции выходят слишком долго».
  • Шаг 2. Соберите правильную команду. Это должна быть зрелая и опытная группа, способная решать задачи. Руководство должно выделить на это необходимый бюджет.
  • Шаг 3. Ограничьте процесс рамками. Исходя из проблемы, сузьте область VSM. Не нужно картографировать релизный процесс целиком, если проблема кроется только на одном участке.
  • Шаг 4. Нарисуйте текущую карту (как есть). Важно пройти процесс лично, а не полагаться на чужие (возможно, неполные или смещённые) описания. Лучше повторить анализ несколько раз: часто при втором проходе находятся упущенные детали.
  • Шаг 5. Соберите данные процесса. Вносите в схему факты: количество задействованных людей, среднее количество рабочих часов, время цикла, время ожидания, время безотказной работы и простои.
  • Шаг 6. Постройте временную ось. Отобразите время выполнения операций и общее время выполнения заказа.
  • Шаг 7. Проанализируйте карту. Задайте важные вопросы: много ли у команд взаимозависимостей? Почему общее время большое? Возможно, тесты не могут работать параллельно? Есть ли стабильные окружения? Некоторые шаги могут казаться ценными для команды, но ничего не значить для клиента.
  • Шаг 8. Спроектируйте будущую карту (как должно быть). Не стремитесь к окончательной версии сразу. Убедитесь, что карта соответствует видению компании, и помните, что она может меняться вместе с потребностями клиентов.
  • Шаг 9. Внедрите будущую карту. Следуйте новой схеме, регулярно отслеживайте ключевые показатели и проверяйте, решает ли она исходную проблему. Убедитесь, что вся команда гребёт в сторону клиента.

Как VSM помогает в непрерывной доставке

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

Зачем внедрять VSM в вашей команде?

Value Stream Mapping применим в любой отрасли, где нужно улучшать процессы. Визуализация передач помогает оптимизировать поток и генерировать реальную экономию. Без неё вы рискуете увязнуть в долгих встречах и не достичь желаемых бизнес-целей. В мире разработки ПО непрерывное улучшение лежит в самом сердце непрерывной доставки, где главное — выпускать продукты часто, предсказуемо и стабильно. VSM также улучшает культуру команды, а продуктивные и увлечённые команды — это ещё и удовольствие от работы.