Первый шаг стратегического анализа — ответить, зачем организации нужны перемены. Без ясной бизнес-потребности (business need) команда рискует проектировать решение, которое не принесёт ценности. Задача аналитика на этом этапе — перейти от жалоб и «хотелок» к измеримой формулировке проблемы или возможности и связать её со стратегией, не подменяя анализ готовым решением.

Business need на этом шаге — ещё не бизнес-требования: это обоснованная потребность в изменении, которую позже декомпозируют в требования к решению — см. 02.03.01 Классификация требований (БТ, ФТ, НФТ).

1. Суть темы

В BABOK Strategy Analysis этап включает задачи Analyze Current State, Define Future State и Assess Risks — без описания конкретного продукта или системы. «Боль» описывается в терминах бизнеса; «будущее» — как измеримое улучшение состояния, а не как «внедрить CRM».

As-Is собирают из метрик, процессов и документов: интервью и наблюдение — 02.02.01 Интервьюирование и анкетирование, 02.02.03 Наблюдение и анализ документов; моделирование процессов — 03.04.01 BPMN 2.0 - введение и основы. Отдельные артефакты As-Is/To-Be не обязательны: достаточно встроить измеримое текущее и желаемое состояние в Problem Statement или фрагмент Vision and Scope.

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

Уровень анализа влияет на формулировку одной и той же ситуации:

УровеньПример формулировки
Портфель (enterprise)«Доля рынка в сегменте SMB падает третий год подряд»
Программа«Три продуктовые линейки дублируют функции онбординга клиента»
Проект«Цикл согласования договора в отделе продаж — 7 дней при целевых 2»

Два входа в анализ:

  • От проблемы — есть измеримое нежелательное явление; артефакт — Problem Statement; при значимых инвестициях — Business Case.
  • От возможности — окно для роста без явной «боли»; выше неопределённость, нужна гипотеза ценности (opportunity hypothesis) и ранняя проверка (Lean Canvas, discovery). Риск одобрения выше, чем у «тушения пожара».

На уровне проекта возможность часто оформляют как product discovery; на уровне портфеля/программы — как strategic fit с корпоративными целями. Граница с product management: здесь фиксируют зачем организации меняться, а не backlog фич продукта.

Problem Statement и Business Case — разные артефакты. PS отвечает «что не так и почему это важно»; Business Case — «стоит ли инвестировать»: ожидаемые выгоды, варианты (включая «не делать»), риски, рекомендация. Business Case обязателен при запросе бюджета у портфельного комитета или спонсора; для небольшой инициативы с явным ROI достаточно PS с последствиями бездействия. Детальные финансовые KPI и ROI — в 02.01.02 Цели, KPI и критерии успеха (SMART, GQM); структура документов — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).

flowchart TD
    A[Сигнал: жалоба, метрика, идея] --> B{Проблема или возможность?}
    B -->|Измеримый вред| C[Черновик PS + As-Is]
    B -->|Гипотеза роста| D[Opportunity hypothesis + быстрая проверка]
    C --> E{Несколько проблем?}
    D --> E
    E -->|Да| F[Problem-Goal Matrix: ранжирование]
    E -->|Нет| G[Problem-Goal Matrix: проверка strategic fit]
    F --> H[1–2 приоритетные → углубление: To-Be, RCA]
    G --> H
    H --> I{Стоит инвестировать?}
    I -->|Да| J[Business Case при необходимости → цели и KPI]
    I -->|Нет| K[Отказ или отложить — решение спонсора]

Решение «инвестировать / отказать / отложить» принимает спонсор (или портфельный комитет); аналитик готовит обоснование, PM может дать оценку сроков и ресурсов. Отказ фиксируют явно — иначе инициатива вернётся через полгода с тем же симптомом.

2. Ключевые понятия

Симптом, проблема, решение

СущностьОпределениеПример
Симптом (жалоба)Внешнее проявление«У нас долго согласовываются договоры»
Бизнес-проблемаИзмеримое нежелательное явление с последствиями и владельцем«Средний цикл согласования договора — 7 дней; 15% клиентов уходят на этапе подписания. Владелец — коммерческий директор»
РешениеГипотеза об устранении проблемы«Внедрить ЭДО с маршрутизацией»

Правило: в формулировке проблемы не должно быть предписанного решения. Стейкхолдеры часто приходят с готовым решением — это solution bias; подробнее см. 01.07 Когнитивные искажения и критическое мышление.

Шаблон формулировки проблемы

Хорошая формулировка отвечает на четыре вопроса:

  1. В чём суть? Что идёт не так в бизнес-терминах?
  2. Масштаб и влияние? Кого затрагивает, как часто, какие потери?
  3. Последствия бездействия? Что будет через год без изменений?
  4. Направление желаемого изменения? Как должно выглядеть улучшенное состояние — без указания средства.

Пункт 4 — черновик To-Be, не SMART-цель. Конкретные метрики успеха («сократить на 80%») фиксируйте на этапе целей.

Пример:

  • Плохо: «Плохая отчётность».
  • Хорошо: «Финансовый отдел тратит 40 человеко-часов в месяц на ручное сведение данных из нескольких учётных систем; ошибки приводят к переплате налогов ~300 тыс. руб. в квартал. При росте объёма сделок нагрузка удвоится. Желаемое состояние: единый управляемый источник консолидированной отчётности без ручного сведения в Excel».

Корневая причина и сопутствующие факторы

Не каждое улучшение требует поиска «единственного корня». Различайте:

  • Корневая причина (root cause) — устранение которой снимает проблему системно.
  • Сопутствующие факторы (contributing factors) — усиливают симптом, но их правка даёт локальный эффект.

Выбор глубины RCA зависит от стоимости изменения и риска. Методы и типовые ошибки — 01.03 Техники анализа проблем; для связанных нежелательных явлений — CRT и «Грозовая туча» в 01.05 Теория ограничений и бережливое мышление.

При «5 Почему» различайте найденную корневую причину и зону влияния инициативы: ответ «регулятор запретил» может быть корнем, но лежать вне scope проекта — тогда фиксируйте ограничение (constraint) в Context, а не «закрывайте» RCA формально. Регуляторные ограничения в РФ — 08.06 Юридические и регуляторные требования РФ (PCI-DSS).

Бизнес-возможность

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

Минимальная оценка: потенциальная ценность, осуществимость (технология, бюджет, компетенции), соответствие стратегии. Риски — 08.05 Управление рисками на этапе анализа.

В условиях неопределённости оформляйте гипотезу: problem hypothesis для проблем, opportunity hypothesis для возможностей — проверяемое предположение до полного анализа. В Agile discovery это часть параллельного трека — 05.02 Scrum и Kanban (аналитик в Agile).

Problem-Goal Matrix

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

  1. Несколько проблем или возможностей — ранжирование до глубокого RCA по каждой: сопоставление со стратегическими целями, влияние, стоимость бездействия. В первый цикл анализа берут 1–2 приоритетные; остальные — в backlog инициатив.
  2. Одна проблема — проверка strategic fit: привязана ли к цели или это частная боль, не требующая инвестиций.

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

Когда одна программа закрывает портфель проблем, связывайте их через theme/epic на уровне инициативы и приоритизируйте внутри программы — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано), границы — 02.01.04 Определение границ решения (Scope Modelling).

BACCM на этом этапе

КонцепцияВопрос
NeedКакая проблема или возможность стоит за инициативой?
ChangeКакое преобразование As-Is → To-Be требуется?
StakeholderКто страдает, кто выиграет, кто должен согласовать?
ContextОграничения: бюджет, регуляторика, legacy, сроки — 02.01.04 Определение границ решения (Scope Modelling)

Каноническое описание BACCM и Strategy Analysis — 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).

3. Как применяется в работе аналитика

Стратегические инструменты (роль на этапе)

ИнструментЗачем здесьДетали
Problem-Goal MatrixФильтр и ранжирование до углубленияРаздел 2
Бенчмаркинг, SWOTОтставание и окна дифференциацииКратко на воркшопе, без углубления
Value ChainУзкие звенья в создании ценности03.04.04 Цепочка создания ценности (VAD) и EPC
Исикава, 5 Whys, CRTОт симптома к причинам01.03 Техники анализа проблем, 01.05 Теория ограничений и бережливое мышление

Артефакты этапа

На выходе обычно нужны: Problem Statement (с As-Is/To-Be внутри или рядом), Business Case — при значимых инвестициях, фрагмент Vision and Scope. Структура документов — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD). Для быстрой проверки гипотез — Lean Canvas / Value Proposition Canvas (leanstack.com, strategyzer.com).

Консенсус стейкхолдеров

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

На этапе problem definition обычно достаточно 2–4 интервью с владельцем и затронутыми ролями плюс один воркшоп на согласование формулировки. Карта стейкхолдеров и техники сбора — 02.01.03 Анализ заинтересованных сторон (Stakeholder Map), 02.02.01 Интервьюирование и анкетирование, 02.02.02 Воркшопы, фасилитация и совместные сессии.

Правило: если через две недели после согласования спонсор и пользователи спорят «в чём реальная проблема» — анализ не завершён.

Чек-лист перед следующим этапом

Пункты про As-Is/To-Be — про содержание в PS или Vision, не про обязательные отдельные документы.

  • Проблема в терминах бизнеса, не технологий.
  • As-Is описан измеримыми показателями текущего состояния.
  • To-Be сформулирован как желаемое состояние, без предписанного решения.
  • Определён владелец проблемы.
  • Проблема привязана к стратегической цели (или зафиксировано, что цели уточняются).
  • Симптомы отделены от корневых/сопутствующих причин (при необходимости — RCA).
  • Последствия бездействия понятны спонсору.
  • Ограничения (Context) зафиксированы.
  • Есть консенсус ключевых стейкхолдеров.

Пример: «5 Почему» для бизнес-проблемы

graph TD
    Q1["1. Почему теряем клиентов на подписании?"] --> A1["Цикл согласования — 7 дней"]
    Q2["2. Почему 7 дней?"] --> A2["Три согласующих последовательно, каждый 1–2 дня"]
    Q3["3. Почему последовательно?"] --> A3["Нет единого регламента; каждый добавляет правки"]
    Q4["4. Почему нет регламента?"] --> A4["Процесс не пересматривали с момента роста штата в 3 раза"]
    Q5["5. Почему не пересматривали?"] --> A5["Корень в зоне влияния: нет владельца процесса согласования"]

4. Типовые ошибки и ограничения

ОшибкаКак избежать
Путать симптом, проблему и решениеТаблица в разделе 2; не принимать «нужна кнопка X» за проблему
Вшить KPI успеха в Problem StatementПроблема + черновик To-Be здесь; SMART-цели — на следующем этапе
Solution bias стейкхолдеров01.07 Когнитивные искажения и критическое мышление
«Закрыть» 5 Whys на неконтролируемом фактореОтделить корень от зоны влияния; зафиксировать constraint
Глубокий RCA по всем проблемам сразуСначала Problem-Goal Matrix; 1–2 в первый цикл
Начать scope без консенсусаПравило двух недель; 02.01.03 Анализ заинтересованных сторон (Stakeholder Map)
Смешать business need и бизнес-требованияNeed здесь; декомпозиция в требования — 02.03.01 Классификация требований (БТ, ФТ, НФТ)
Дублировать форматы документовСтруктура PS, Business Case, Vision — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

  • IIBA (2015). BABOK® Guide v3. Глава 5 «Strategy Analysis»: Analyze Current State, Define Future State, Assess Risks; BACCM. Актуальное издание: https://www.iiba.org/standards-and-resources/babok/
  • Wiegers, K., Beatty, J. (2013). Разработка требований к программному обеспечению. Гл. 2 «Требования с точки зрения бизнеса».
  • Goldratt, E. (2014). Цель. Симптомы vs корневые проблемы, логика ограничений.
  • Олсен, Д. (2020). The Lean Product Playbook. Гипотезы проблемы и ранняя проверка.

Статьи и онлайн-ресурсы