future-state

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: [e-mail]

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 — описывает куда движется организация.

Два ключевых выхода:

1. Описание будущего состояния — 8 элементов «как должно быть» + SMART-цели с KPI
2. 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 для каждого элемента.

Порядок работы:

1. Начинай с business_needs — какие потребности будут удовлетворены
2. Потом capabilities — новые / улучшенные процессы
3. Потом technology — целевой технологический стек
4. По необходимости: 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.2
• true — готовит данные для передачи в 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 при оценке ценности