| name | future_state |
| description | Скилл BABOK 6.2 — Определение будущего состояния (to-be). Используй этот скилл когда BA хочет описать целевое состояние бизнеса, поставить SMART-цели с KPI, провести gap-анализ или зафиксировать ограничения и потенциальную ценность изменения. Триггеры: «будущее состояние», «future state», «to-be», «цели», «gap-анализ», «ограничения», «потенциальная ценность», «SMART-цели», «define future state».
|
| project | AI-powered Platform AInalyst (AI Платформа AIналитик) |
| copyright | Copyright (c) 2026 Anatoly Chaussky. Licensed under AGPL v3. Commercial licensing: chaussky@gmail.com |
SKILL: Define Future State (BABOK 6.2)
Когда читать этот скилл
Читай этот файл когда:
- BA говорит «нужно описать целевое состояние», «как должно быть», «будущее состояние»
- BA хочет поставить бизнес-цели с KPI
- BA проводит gap-анализ или описывает разрыв между as-is и to-be
- Запрос содержит: «будущее состояние», «future state», «to-be», «цели», «gap-анализ»,
«ограничения», «потенциальная ценность», «SMART-цели»
Что это за задача
BABOK 6.2 — Define Future State — описывает куда движется организация.
Два ключевых выхода:
- Описание будущего состояния — 8 элементов «как должно быть» + SMART-цели с KPI
- Gap-анализ — структурированное сравнение текущего и будущего состояний (вход для 6.4)
Почему это важно:
- Без будущего состояния нет основания оценивать дизайн-опции в 7.5
- SMART-цели с KPI дают baseline для измерения успеха в Главе 8
- Gap-анализ — прямой вход для 6.4: стратегия изменений строится на явном разрыве
- Потенциальная ценность в 6.2 — контекст для детального расчёта в 7.6
MCP-инструменты (7 шт.)
| Инструмент | Когда вызывать |
|---|
scope_future_state | Первый шаг — контракт анализа, что описываем |
capture_future_state_element | Для каждого элемента из скоупа (итеративно) |
define_goals_and_objectives | Для каждой бизнес-цели с KPI (SMART-валидация) |
capture_constraints | Для каждого ограничения по категории |
run_gap_analysis | После заполнения всех элементов — явный артефакт |
assess_potential_value | Структурированная оценка выгод (входные данные для 7.6) |
check_future_state_completeness | Перед финализацией — coverage check |
save_future_state | Финальный шаг — Markdown-отчёт + проброс в 7.3 |
Примечание: save_future_state — 8-й вызов в pipeline, но в списке инструментов
платформы считается как часть 7 основных инструментов задачи.
Алгоритм работы
Шаг 1 — Скоуп (обязательно первым)
Вызов scope_future_state. Явный контракт: что анализируем, какая глубина.
Вопросы BA:
- Те же элементы что в 6.1 или расширяем? → elements_in_scope
- Уровень детализации: стратегический срез или глубокая проработка? → analysis_depth
- Есть ли уже известные цели от спонсора? → known_goals
При наличии 6.1 — система автоматически читает скоуп текущего состояния как контекст.
Это рекомендованная отправная точка: те же элементы, но смотрим на «как должно быть».
Шаг 2 — Сбор данных по элементам (итеративно)
Вызов capture_future_state_element для каждого элемента.
Порядок работы:
- Начинай с
business_needs — какие потребности будут удовлетворены
- Потом
capabilities — новые / улучшенные процессы
- Потом
technology — целевой технологический стек
- По необходимости:
org_structure, policies, architecture, assets, external
UX-паттерн «прошлое рядом с будущим»:
Если есть данные 6.1, инструмент автоматически покажет текущее состояние элемента рядом.
Используй это: BA описывает не «что добавить», а «как должно быть в итоге».
Признак качественного описания:
- Ориентировано на результат, не на процесс внедрения
- Есть целевые метрики (
target_metrics)
- Трассировано к BN из 6.1 (
linked_business_needs)
- Не дублирует текущее состояние
Признак плохого описания:
- «Будет CRM-система» — это решение, не будущее состояние
- «Всё будет лучше» — нет конкретики
- Описывает процесс внедрения, а не целевое состояние
Подробнее о 8 элементах: читай references/future_state_guide.md
Шаг 3 — Бизнес-цели и KPI
Вызов define_goals_and_objectives для каждой бизнес-цели.
SMART-валидация (подробнее: references/future_state_guide.md):
- Инструмент проверяет критерии и предлагает улучшения
- Каждая цель привязана к BN из 6.1 → трассировка
BN → BG → FR
- Цель регистрируется как узел
business_goal в репозитории 5.1 (ADR-062)
Структура objectives_json:
[
{
"title": "Сократить время обработки заявок",
"metric": "Время обработки (часы)",
"baseline": "8 часов",
"target": "2 часа",
"deadline": "2025-12-31"
}
]
Цель без измеримого KPI — не цель. Помоги BA найти метрику.
Шаг 4 — Ограничения
Вызов capture_constraints для каждого ограничения.
Типы: budget | time | technology | policy | resources | compliance | other
Зачем фиксировать явно:
- В 7.5 дизайн-опции разрабатываются в рамках ограничений
- Предполагаемые ограничения (
assumed) нужно валидировать — могут оказаться мифами
- Неизвестные ограничения = риски проекта
Шаг 5 — Gap-анализ (отдельный явный инструмент)
Вызов run_gap_analysis.
Важно: gap-анализ — инструмент мышления, не технический шаг.
BA должен запустить его осознанно после заполнения всех элементов.
Без данных 6.1: current_description = null — gap формулируется только по future.
С данными 6.1: автоматически сравнивается текущее и будущее состояние по элементам.
Результат ({project}_gap_analysis.json) — обязательный вход для 6.4.
Типы изменений: new | improve | eliminate | replace
Оценка сложности: low | medium | high
Подробнее: references/future_state_guide.md → раздел «Gap-анализ»
Шаг 6 — Потенциальная ценность
Вызов assess_potential_value.
Качественная оценка, без формулы. Структурированный список выгод.
Это контекст для 7.6, не замена ему.
Параметры:
benefits_json — JSON-список выгод (тип + magnitude + confidence + привязка)investment_level — качественная оценка уровня вложенийvalue_summary — суммарный тезис для коммуникации со спонсором
Подробнее о типах выгод, magnitude, confidence: читай references/value_guide.md
Шаг 7 — Проверка полноты
Вызов check_future_state_completeness перед финализацией.
Что проверяет:
- Все ли скоупированные элементы заполнены?
- Есть ли хотя бы одна цель с KPI?
- Привязаны ли BN к целям (если 6.1 есть)?
- Есть ли хотя бы одно ограничение?
- Запущен ли gap-анализ?
- Есть ли оценка потенциальной ценности?
Это предупреждения, не блокировки. Аналитик принимает решение идти дальше.
Шаг 8 — Финализация
Вызов save_future_state.
Параметр push_to_business_context:
false (по умолчанию) — только сохраняет отчёт 6.2true — готовит данные для передачи в 7.3. BA затем вызывает:
set_business_context(from_strategy_project_id="project_id", ...)
и данные из целей 6.2 предзаполнят бизнес-контекст для валидации требований (ADR-065)
Интеграция с другими задачами
Вход: 6.1 → 6.2 (опционально, ADR-060)
6.1 не является обязательным для работы 6.2 — graceful degradation.
При наличии 6.1 — автоматически читается:
{project}_current_state_scope.json → контекст для скоупа 6.2{project}_business_needs.json → BN для трассировки целей{project}_current_state.json → текущее состояние для gap-анализа
Выход: 6.2 → 5.1 (трассировка целей)
BG-xxx узлы регистрируются в репозитории 5.1 с типом business_goal (ADR-062).
Сквозная цепочка: BN-001 → derives → BG-001 → satisfies → FR-001 → verifies → TC-001
Выход: 6.2 → 6.4 (стратегия изменений)
{project}_gap_analysis.json — обязательный вход для 6.4.
Стратегия изменений строится на явном перечне gaps и их типов.
Выход: 6.2 → 7.3 (бизнес-контекст)
set_business_context в 7.3 принимает from_strategy_project_id (ADR-065).
При передаче — предзаполняет бизнес-цели и future_state из данных 6.1 + 6.2.
Старый параметр from_current_state_project_id deprecated, но работает.
Выход: 6.2 → 7.6 (потенциальная ценность)
add_value_assessment в 7.6 при наличии 6.2 читает benefits как pre-fill контекст.
BA уточняет качественные оценки количественно — не начинает с нуля.
Артефакты 6.2
| Файл | Назначение |
|---|
{project}_future_state_scope.json | Контракт: что анализируем |
{project}_future_state.json | Элементы, цели, ограничения, ценность, статус |
{project}_future_state_goals.json | Цели и KPI (+ регистрация в 5.1) |
{project}_gap_analysis.json | Gap-анализ — вход для 6.4 |
6_2_future_state_{project}.md | Читаемый отчёт (REPORTS_DIR) |
Reference-файлы
Читай когда нужны детали:
-
references/future_state_guide.md — подробное описание 8 элементов, SMART-критерии,
типы изменений gap-анализа, типы и статусы ограничений, UX-паттерны
-
references/value_guide.md — типы выгод, magnitude/confidence, investment_level,
структура benefits_json, типичные ошибки BA при оценке ценности
