--- 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 — точка отсчёта для всего проекта изменений. **Два ключевых выхода:** 1. **Описание текущего состояния** — структурированный анализ 8 элементов (что есть сейчас) 2. **Бизнес-потребности (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, policies - `new_system` → business_needs, capabilities, technology, architecture - `regulatory` → business_needs, policies, technology, external - `cost_reduction` → business_needs, capabilities, assets, external - `market_opportunity` → все 8 элементов (deep) Подробнее о 8 элементах: читай `references/current_state_guide.md` --- ### Шаг 2 — Сбор данных по элементам (итеративно) Вызов `capture_current_state_element` для каждого элемента из скоупа. **Порядок работы:** 1. Начинай с `business_needs` — это фундамент 2. Потом `capabilities` и `technology` — где происходит проблема 3. Потом `policies` — что мешает или что требуется 4. По необходимости: `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.1 - `true` — готовит данные для передачи в 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_needs` - `confirmed_constraints` → элемент `policies`, частично `technology` - `raw_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)