| name | current_state |
| description | Скилл BABOK 6.1 — Анализ текущего состояния (as-is). Используй этот скилл когда BA хочет понять текущее состояние бизнеса, сформулировать бизнес-потребности, провести RCA (Root Cause Analysis) или описать проблемы организации. Триггеры: «текущее состояние», «as-is», «проблема», «бизнес-потребность», «корневая причина», «current state», «analyze current state», «почему так происходит».
|
| project | AI-powered Platform AInalyst (AI Платформа AIналитик) |
| copyright | Copyright (c) 2026 Anatoly Chaussky. Licensed under AGPL v3. Commercial licensing: chaussky@gmail.com |
SKILL: Analyze Current State (BABOK 6.1)
Когда читать этот скилл
Читай этот файл когда:
- BA говорит «нужно понять текущее состояние», «провести анализ as-is», «описать проблему»
- BA хочет сформулировать бизнес-потребности
- BA проводит RCA (Root Cause Analysis)
- Запрос содержит: «текущее состояние», «as-is», «проблема», «бизнес-потребность»,
«корневая причина», «анализ», «current state»
Что это за задача
BABOK 6.1 — Analyze Current State — точка отсчёта для всего проекта изменений.
Два ключевых выхода:
- Описание текущего состояния — структурированный анализ 8 элементов (что есть сейчас)
- Бизнес-потребности (BN-xxx) — формализованные причины изменений (input для 6.2)
Почему это важно:
- Без анализа текущего состояния — нет понимания, что именно меняем и почему
- Бизнес-потребности — upstream-вершины всей трассировки (BN → BR → FR → TC)
- RCA отличает симптомы от причин: решение точное, не «лечим симптомы»
MCP-инструменты (6 шт.)
| Инструмент | Когда вызывать |
|---|
scope_current_state | Первый шаг — скоуп и контракт анализа |
capture_current_state_element | Для каждого элемента из скоупа (итеративно) |
run_root_cause_analysis | После сбора данных, перед формулировкой BN |
define_business_needs | После RCA — формулировать и регистрировать BN |
check_current_state_completeness | Перед финализацией — coverage check |
save_current_state | Финальный шаг — Markdown-отчёт + проброс в 7.3 |
Алгоритм работы
Шаг 1 — Скоуп (обязательно первым)
Вызов scope_current_state. Фиксирует явный контракт анализа.
Вопросы BA:
- Что инициировало этот проект? (process_improvement / new_system / regulatory / cost_reduction / market_opportunity)
- Сколько времени есть на анализ? → выбор глубины (light / standard / deep)
- Есть ли готовые результаты выявления из 4.3? → session_ids
Рекомендации по elements_in_scope по умолчанию:
process_improvement → business_needs, capabilities, technology, policiesnew_system → business_needs, capabilities, technology, architectureregulatory → business_needs, policies, technology, externalcost_reduction → business_needs, capabilities, assets, externalmarket_opportunity → все 8 элементов (deep)
Подробнее о 8 элементах: читай references/current_state_guide.md
Шаг 2 — Сбор данных по элементам (итеративно)
Вызов capture_current_state_element для каждого элемента из скоупа.
Порядок работы:
- Начинай с
business_needs — это фундамент
- Потом
capabilities и technology — где происходит проблема
- Потом
policies — что мешает или что требуется
- По необходимости:
org_structure, architecture, assets, external
Как помогать BA заполнять элементы:
Для каждого элемента задай вопросы (из references/current_state_guide.md),
помоги структурировать ответы. Результат — конкретные, измеримые описания.
Признак качественного описания:
- Есть цифры (метрики): время, деньги, частота, процент ошибок
- Есть pain_points — симптомы, жалобы, наблюдения
- Понятен источник информации (sources)
Признак плохого описания:
- «Процесс неэффективный» — слишком общо
- «Нет автоматизации» — симптом, не описание состояния
- Нет метрик и нет источников
Шаг 3 — Root Cause Analysis
Вызов run_root_cause_analysis для каждой ключевой проблемы.
Выбор техники (подробнее: references/rca_guide.md):
five_whys — одна проблема, линейная цепочка, быстроfishbone — несколько категорий причин (Люди / Процессы / Технологии / Данные)problem_tree — стратегический анализ с последствиями
Ключевые принципы:
problem_statement — измеримо: «Время выросло с 2 до 8 часов» а не «процесс медленный»root_cause — одна главная причина (не симптом, не следствие)contributing_factors — факторы, усиливающие корневую причинуevidence — данные, подтверждающие цепочку причинaffected_elements — какие из 8 элементов затронуты (связь с шагом 2)
Нормализованный выход (ADR-056): независимо от техники — единый формат.
Техника — инструмент мышления. MCP сохраняет нормализованный результат.
Шаг 4 — Формулировка бизнес-потребностей
Вызов define_business_needs для каждой бизнес-потребности.
Отличие бизнес-потребности от требования:
- Бизнес-потребность: ЧТО нужно изменить и ПОЧЕМУ
- Требование: КАК именно это сделать
Структура хорошей бизнес-потребности:
need_title — краткий, понятный заголовокdescription — конкретная, измеримая формулировка проблемы/возможностиcost_of_inaction — что будет если не менять (убедительный аргумент)expected_benefits — ожидаемые выгоды от измененийroot_cause_ids — связь с RCA (обязательно!)
Регистрация в трассировке (ADR-054):
register_in_traceability: true (по умолчанию) — BN-xxx появится в репозитории 5.1- Это upstream-вершина: BN → BR → FR → TC — полная сквозная трассировка
- Если репозиторий 5.1 ещё не создан — создать через
init_traceability_repo (5.1)
Шаг 5 — Проверка полноты
Вызов check_current_state_completeness перед финализацией.
Что проверяет:
- Все ли скоупированные элементы заполнены?
- Есть ли хотя бы один RCA?
- Есть ли бизнес-потребности?
- Связаны ли BN с RCA?
Это предупреждения, не блокировки. Аналитик принимает решение идти дальше.
Шаг 6 — Финализация
Вызов save_current_state.
Параметр push_to_business_context:
false (по умолчанию) — только сохраняет отчёт 6.1true — готовит данные для передачи в 7.3. BA затем вызывает:
set_business_context(from_current_state_project_id="project_id", ...)
и данные из BN предзаполнят бизнес-цели автоматически (ADR-055)
Интеграция с другими задачами
Вход: 4.3 → 6.1 (импорт из выявления)
Если BA уже проводил выявление и есть подтверждённые результаты (4.3),
их можно импортировать при скоупировании через session_ids.
Маппинг данных 4.3 → 8 элементов 6.1:
confirmed_needs → элемент business_needsconfirmed_constraints → элемент policies, частично technologyraw_notes и контекст интервью → capabilities, org_structure, technology- Упоминания внешних факторов →
external
Импортированные данные помечаются как черновик — BA уточняет через
capture_current_state_element.
Выход: 6.1 → 5.1 (трассировка)
BN-xxx узлы регистрируются в репозитории 5.1 с типом business_need.
Полная цепочка: BN-001 → BR-001 → FR-001 → TC-001
run_impact_analysis (5.4) видит бизнес-потребности как upstream-вершины.
Выход: 6.1 → 7.3 (бизнес-контекст)
set_business_context в 7.3 принимает параметр from_current_state_project_id.
При передаче — предзаполняет бизнес-цели из бизнес-потребностей 6.1.
Без параметра — работает как раньше (backward compatible, ADR-055).
Выход: 6.1 → 6.2 (Future State)
Задача 6.2 строится на root_cause из RCA:
«Что именно меняем» = «устраняем корневую причину из RCA-001»
Частые ошибки BA — как помогать
«Описывает симптомы вместо причин»
- Помоги задать вопрос «Почему?» три-пять раз
- Напомни: жалоба клиента — симптом, причина — в процессе/технологии/политике
«Хочет проанализировать всё»
- Напомни про скоуп — scope_current_state определяет что анализируем
- Лучше глубоко 4 элемента, чем поверхностно все 8
«Бизнес-потребность сформулирована как решение»
- «Нам нужна CRM-система» — это решение, не потребность
- Потребность: «Мы теряем 30% клиентов из-за медленной обработки обращений»
«Нет цифр и метрик»
- Без цифр невозможно оценить ценность решения в 7.6
- Помоги BA найти или оценить метрики: время, деньги, частота ошибок
Артефакты 6.1
| Файл | Назначение |
|---|
{project}_current_state_scope.json | Контракт: что анализируем |
{project}_current_state.json | Данные по 8 элементам + RCA |
{project}_business_needs.json | Реестр бизнес-потребностей |
6_1_current_state_{project}.md | Читаемый отчёт (REPORTS_DIR) |
Reference-файлы
Читай когда нужны детали:
-
references/current_state_guide.md — подробное описание каждого из 8 элементов:
что анализировать, вопросы для BA, примеры хорошего/плохого описания
-
references/rca_guide.md — три техники RCA с пошаговыми инструкциями
и маппингом в нормализованный формат (ADR-056)
