Сделайте стратегический ландшафт обсуждаемым: расположите цепочку ценности относительно потребности пользователя и одновременно покажите эволюцию компонентов. Карта — проверяемая модель ситуации, а не география и не прогноз.
За одну минуту
Карта Wardley объединяет:
- якорь — потребность пользователя или стейкхолдера;
- цепочку ценности — компоненты и их зависимости;
- видимость — близость компонента к потребности;
- эволюцию — от Genesis через Custom Built и Product/Rental к Commodity/Utility;
- движение и контекст — давления, инерцию, доктрину и варианты как гипотезы.
Позиции относительны и спорны. Разные команды могут обоснованно разместить компонент по-разному из-за контекста, уровня детализации или качества данных.
Лучше всего: для решений build/buy, стандартизации, дифференциации и последовательности изменений.
Не подходит: если нужен таймлайн процесса, ось эволюции принимают за календарь или от карты ждут автоматического решения.
Какую проблему решает
Стратегические обсуждения часто смешивают пользовательскую ценность, архитектуру, зрелость рынка и предпочтения организации. Wardley Mapping разделяет эти измерения, показывает зависимости и заставляет проверить, что действительно ново, что сделано на заказ, а что стало продуктом или utility.
Карта не вычисляет правильную стратегию. Она делает убеждения видимыми и помогает спроектировать проверки до крупных обязательств.
Когда применять
Применяйте Wardley Mapping, когда:
- продукт зависит от меняющегося технологического ландшафта;
- спор build-versus-buy идёт без общей цепочки ценности;
- дифференциация опирается на быстро стандартизирующиеся компоненты;
- нужно упорядочить платформенные, sourcing- или modernisation-решения;
- сценарий требует конкретного представления возможностей и зависимостей;
- стратегическим допущениям нужны владельцы и сигналы пересмотра.
Когда не применять
Не используйте метод:
- вместо исследования пользователей и архитектурных данных;
- для единой перегруженной карты всех вопросов;
- как карту времени процесса — для этого есть Value Stream Mapping;
- чтобы считать эволюцию неизбежной;
- чтобы скрыть регулирование, власть или экологические ограничения;
- копируя чужую карту без восстановления своего якоря и данных.
Необходимые входные данные
- ограниченный стратегический вопрос и горизонт;
- конкретная потребность пользователя;
- компоненты и подтверждённые зависимости;
- данные о доступности, распространённости и определённости;
- ограничения, инерция, власть и регулирование;
- конкурирующие гипотезы и права решения.
Пошаговый процесс
1. Ограничьте решение
Определите выбор, границы, горизонт и исключения. Формулировка «решить, чем владеть в платформе AI-помощника в ближайшие 18 месяцев» пригоднее, чем «нарисовать архитектуру».
2. Поставьте якорь на потребность
Назовите пользователя и наблюдаемую потребность. Внутренний проект редко является конечным бенефициаром.
3. Постройте цепочку ценности
Спросите, от чего зависит потребность, затем от чего зависит каждый компонент. Выберите уровень, на котором возможен стратегический выбор.
4. Разместите по видимости
Якорь находится выше, менее видимые зависимости — ниже. Низкая видимость не означает низкую важность.
5. Разместите по эволюции
По данным расположите компоненты от Genesis до Commodity/Utility. Сохраняйте разногласия и уверенность.
6. Добавьте движение и ограничения
Отметьте вероятную эволюцию, инерцию, стандарты, регулирование и концентрацию поставщиков. Стрелки остаются гипотезами.
7. Проверьте доктрину
Оцените, достаточно ли сильны пользовательский фокус, ситуационная осведомлённость, обучение, снижение смещений и уместное применение стандартов.
8. Сформируйте варианты
Рассмотрите выделение платформы, покупку зрелого компонента, защиту действительно нового, open source или последовательность вокруг ограничения.
9. Назначьте проверки и пересмотр
Для каждого варианта запишите допущение, обратимую проверку, guardrail, владельца и триггер обновления карты. Храните версии.
Линза AI-автоматизации
AI может группировать разрешённые данные о компонентах, сравнивать заявления поставщиков, находить противоречивые позиции и вести реестр допущений.
AI не должен:
- собирать конфиденциальные данные без полномочий;
- определять эволюцию только по популярности;
- выдавать сгенерированную карту за объективную истину рынка;
- скрывать неопределённость источников;
- принимать sourcing-, кадровые или экосистемные решения без ответственного человека.
Визуальная модель
Интерактивный пример
Региональный банк проектирует AI-сервис финансовых рекомендаций. Понятные объяснения незрелы и дифференцируют сервис; orchestration становится продуктом; identity, storage и messaging доступны как utility.
Рабочий ответ: поставьте в якорь потребность клиента в понятном безопасном совете; объяснения проверяйте близко к пользователю; для orchestration сравните продуктовые варианты; utilities снабдите resilience- и exit-контролями; права на данные и regulatory assurance покажите как зависимости.
Заметки фасилитатору
- Сначала собирайте независимые позиции участников.
- Запрашивайте данные и уверенность, а не только интуицию.
- Разделяйте компоненты со смешанной зрелостью.
- Привлекайте продукт, операции, архитектуру, закупки, риск и пользователей.
- Не смешивайте «где находится» и «что хотим сделать».
Ожидаемый результат
- ограниченная цепочка ценности с пользовательским якорем;
- позиции эволюции с данными и уверенностью;
- видимые ограничения, инерция и гипотезы движения;
- минимум два стратегических варианта;
- проверки, guardrails, владельцы и сигналы обновления;
- версия карты и реестр допущений.
Типичные ошибки
- Эволюция принимается за календарное время.
- Видимость принимается за ценность.
- Гипотеза карты выдаётся за факт.
- Архитектурный список не связан с пользовательской потребностью.
- Стрелка движения считается доказательством.
- Игнорируются власть, regulation и lock-in.
Чек-лист качества
- Решение, пользователь и потребность определены.
- Каждый компонент имеет путь зависимости к якорю.
- Видимость и эволюция не смешаны.
- Позиции содержат данные, уверенность и разногласия.
- Ограничения, инерция, власть и regulation видимы.
- Есть минимум два варианта и опровергающая проверка.
- Sourcing- и кадровые последствия проверяет ответственный человек.
- Назначены триггер обновления и владелец.
Шаблон
| Компонент | Зависит от | Видимость | Эволюция | Данные / уверенность | Движение / инерция | Вариант | Проверка / владелец |
|---|---|---|---|---|---|---|---|
| Способность | Потребность или компонент | Высокая / средняя / низкая | Genesis / Custom / Product / Commodity | Источник и пробел | Направление и ограничение | Build / buy / share / retire / protect | Сигнал и дата |
Проверка знаний
Вопрос: компонент расположен далеко справа. Что можно заключить?
Ответ: он считается относительно стандартным и распространённым в данном контексте. Это не означает, что он неважен, должен быть отдан на аутсорсинг или появится поздно.
Связанные методы
Источники
- Simon Wardley. Wardley Maps. Официальный обзор (откроется в новой вкладке). Доступ 22 сентября 2026.
- Simon Wardley. “To Thine Own Self Be True.” Открытая книга (откроется в новой вкладке).
- Tomasz Górski. “Wardley Maps in Enterprise Architecture”, 2025. Статья (откроется в новой вкладке). Независимое применение не доказывает универсальную причинную эффективность.
Профиль метода
- Главный результат: пользовательская цепочка, квалифицированные позиции и портфель вариантов.
- Уровень решения: продукт, платформа, организация или экосистема.
- Сила данных: влиятельный practitioner-метод с растущим числом применений; независимая сравнительная валидация ограничена.
- Триггер пересмотра: изменение потребности, зрелости поставщика, стандарта, regulation, зависимости или обязательства.