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 также улучшает культуру команды, а продуктивные и увлечённые команды — это ещё и удовольствие от работы.