# Claude для бизнес-кейсов, расчета ROI и прогноза инвестиций

> Полная операционная система для обоснования инвестиций в ИИ: 10 этапов (S0–S9), 8 контрольных ворот (G0–G7), математический мост захвата ценности, анализ чувствительности и защита бизнес-кейса перед CFO.

Бизнес-кейс становится по-настоящему полезным тогда, когда он превращает неизвестность в структурированную, проверяемую неопределенность. Эта операционная система помогает лидеру инициативы или владельцу продукта организовать фактические доказательства, рабочие допущения, финансовую экономику, риски и персональную ответственность за реализацию выгод.

Она не является волшебной таблеткой и не гарантирует автоматического одобрения бюджета, но создает прозрачный язык диалога между продуктовой командой, техническими лидерами и финансовым департаментом (CFO/Finance).

---

## 1. Как работает система и границы применения

Система разработана как сквозной алгоритм подготовки и сопровождения инвестиционных решений в сфере цифровых технологий.

### 1.1. Назначение бизнес-кейса и управление неопределенностью

Главная проблема большинства бизнес-кейсов для ИИ — завышенные ожидания без четкого механизма монетизации сэкономленного времени. Система устраняет разрыв между теоретической производительностью и реальным денежным потоком (Cash Flow). Она заставляет отделять гипотезы от доказательств и рассчитывать точку безубыточности для каждого проекта.

### 1.2. Сфера применения, ограничения и роли

Система оптимизирована для решений по:
- Инвестициям в генеративный ИИ и агентные системы (LLM / Agentic Workflows);
- Автоматизации бизнес-процессов и внедрению RPA;
- Закупке корпоративных SaaS-платформ и выбору вендоров;
- Внутренним проектам цифровой трансформации.

> [!NOTE]
> **Границы применения:** Это руководство регулирует внутренние управленческие решения. Оно не является юридической, аудиторской, налоговой консультацией или оценкой для сделок слияния и поглощения (M&A). Решения всегда принимаются уполномоченными должностными лицами компании.

**Ключевые роли кейса:**
1. **Оператор кейса:** ведет расчеты, заполняет реестры допущений и координирует промпты.
2. **Спонсор инициативы:** бизнес-лидер, заинтересованный в решении проблемы.
3. **Рецензент от Финансов:** проверяет целостность модели, формулы и дисконтирование.
4. **Владелец решения (Decision Maker):** руководитель или комитет с правом подписи бюджета.

---

## 2. Обзор процесса: этапы и контрольные точки

Весь цикл разделен на 10 последовательных этапов (**S0–S9**), каждый из которых завершается обязательной человеческой контрольной точкой — воротами качества (**G0–G7**).

### 2.1. Десятиэтапный цикл (S0–S9) и контрольные ворота (G0–G7)

| Ворота (Gate) | Этап (Stage) | Содержание работы | Итоговый артефакт |
| :--- | :--- | :--- | :--- |
| **G0 — Вход** | S0 — Старт и первичный триаж | Оценка соответствия инициативы критериям системы | Профильная запись кейса |
| **G1 — Рамка готова** | S1 — Рамка решения | Формулирование вопроса, альтернатив и контрфактического сценария | Согласованное намерение (Charter) |
| **G2 — Доказательства готовы** | S2–S3 — Доказательства и драйверы ценности | Сбор фактов, интервью и построение дерева драйверов | Реестры доказательств и карта драйверов |
| **G3 — Целостность модели** | S4–S5 — Модель и неопределенность | Построение расчетной книги и сценариев | Проверенная финансовая модель |
| **G4 — Финансовая проверка** | S6 — Стресс-тест и проверка на прочность | Тестирование граничных значений и поиск уязвимостей | Журнал замечаний Финансов |
| **G5 — Сверка пакета** | S7 — Подготовка меморандума | Формирование финального пакета для руководства | Сверенный Executive Summary пакет |
| **G6 — Решение** | S8 — Инвестиционное решение | Заседание комитета, голосование и фиксация условий | Подписанный протокол решения |
| **G7 — Проверка выгод** | S9 — Реализация и трекинг | Сравнение факта с планом, анализ отклонений | Отчет реализации и пересчет прогноза |

### 2.2. Принцип безусловного человеческого контроля

Каждая контрольная точка — это барьер, где решение принимает исключительно человек, а не алгоритм Claude или автоматизированный скрипт. Ни одна модель не имеет права автоматически переводить кейс на следующий этап без подтверждения ответственного владельца.

---

## 3. С чего начать: сбор кейса до принятия решения

Создание бизнес-кейса начинается задолго до открытия таблиц Excel и запуска финансовых расчетов.

### 3.1. Первичный триаж инициативы и распределение ролей

На этапе **S0** оператор проводит экспресс-фильтрацию инициативы по трем критериям:
1. **Масштаб:** превышает ли потенциальный эффект или затраты минимальный инвестиционный порог компании?
2. **Наличие альтернатив:** рассматривается ли вариант «ничего не менять» (Do Nothing) или покупка готового решения вместо собственной разработки?
3. **Наличие спонсора:** есть ли конкретный руководитель, готовый защищать проект перед правлением?

### 3.2. Критерии готовности кейса к инвестиционному комитету

Кейс считается готовым к рассмотрению только тогда, когда:
- Определен контрфактический сценарий (что произойдет с бизнесом через 3 года, если проект не реализовать);
- Все допущения имеют назначенного владельца и уровень достоверности (High / Medium / Low);
- Зафиксированы пороговые значения, при которых проект будет немедленно остановлен (Kill Criteria).

---

## 4. Архитектура решения и управляемый рабочий процесс

Система функционирует как сквозной механизм, где каждый текстовый вывод привязан к числовым ячейкам рабочей книги.

### 4.1. Четыре ключевых блока прослеживаемого кейса

```mermaid
flowchart TD
    A["1. Рамка решения (S1)<br/>• Вопрос и альтернативы<br/>• Полномочия и пороги<br/>• Контрфактический сценарий"] --> B["2. Управляемые входные данные (S2–S3)<br/>• Реестр доказательств<br/>• Диапазоны допущений<br/>• Карта драйверов ценности"]
    B --> C["3. Финансовая модель (S4–S6)<br/>• Модель денежных потоков<br/>• Анализ чувствительности<br/>• Стресс-тестирование Финансов"]
    C --> D["4. Executive-пакет (S7–S8)<br/>• Меморандум решения<br/>• Условия и риски<br/>• Подписанный протокол G6"]
    
    E["Контрольный слой: Процесс S0–S9 | Ворота G0–G7 | Аудит версий"] -.-> A
    E -.-> B
    E -.-> C
    E -.-> D
```

### 4.2. Рабочая книга как единый числовой источник истины

> [!IMPORTANT]
> Любые цифры, приведенные в тексте меморандума, презентации или ответах Claude, должны иметь прямую ссылку на соответствующую ячейку финансовой рабочей книги. Текстовые утверждения без формульного следа считаются недействительными.

---

## 5. Полный цикл S0–S9: правила переходов и дисциплина артефактов

Дисциплина переходов между этапами гарантирует, что кейс не развалится во время финансового аудита.

### 5.1. Последовательность этапов и логика сигналов STOP / RETURN

При прохождении контрольных точек возможны четыре вердикта:
- **PROCEED (Вперед):** переход к следующему этапу без оговорок.
- **PROCEED WITH CONDITIONS (Вперед с оговорками):** движение продолжается, но накладывается обязательство устранить указанные пробелы до следующих ворот.
- **RETURN (Возврат):** возврат на конкретный предыдущий этап (например, с G4 на S2 для сбора фактов).
- **STOP (Остановка):** закрытие проекта из-за экономической нецелесообразности, отсутствия полномочий или неприемлемых рисков.

### 5.2. Управление версиями и универсальный блок контроля P00

> [!WARNING]
> Любое существенное изменение входных данных после прохождения ворот **G3 (Целостность модели)** автоматически аннулирует результаты ворот G4 и G5. Модель и меморандум должны быть пересчитаны и согласованы заново.

Для работы с Claude используется контрольный префикс **P00**, который добавляется к каждому запросу. Он обязывает модель указывать текущий этап, идентификаторы использованных доказательств и перечень открытых ограничений.

---

## 6. Оцифровка затрат, выгод и мост захвата ценности

Самая частая ошибка в расчетах искусственного интеллекта — приравнивание сэкономленного времени сотрудников к прямой финансовой экономии компании.

### 6.1. Единовременные (CapEx) и регулярные (OpEx) затраты на ИИ

Структура затрат проекта должна полностью учитывать скрытые статьи:

| Категория | Единовременные затраты (One-off / CapEx) | Регулярные годовые затраты (Recurring / OpEx) |
| :--- | :--- | :--- |
| **Технологии** | Интеграция API, настройка векторных баз данных | Подписка на платформу, токены моделей (LLM API) |
| **Данные и инфраструктура** | Очистка и разметка исторических данных | Облачные вычислительные мощности, хранилища |
| **Люди и процессы** | Обучение сотрудников, консалтинг по промптингу | Зарплата инженера поддержки, сопровождение процессов |
| **Безопасность и комплаенс** | Аудит безопасности, оценка рисков AI Act | Мониторинг галлюцинаций, юридическое сопровождение |

### 6.2. Пять стадий от операционного изменения к захваченной ценности

Ценность в бизнесе проходит длинный путь от технического улучшения до банковского счета компании:

```mermaid
flowchart LR
    A["1. Операционное изменение<br/>Быстрая генерация отчетов"] --> B["2. Сгенерированная ценность<br/>Освобождено 20 часов/неделю"]
    B --> C["3. Действие захвата<br/>Сокращение подрядчиков / доп. продажи"]
    C --> D["4. Захваченная ценность<br/>Увеличение денежного потока ($)"]
    D --> E["5. Реализация (S9)<br/>Факт в отчете CFO и трекинг"]
```

### 6.3. Формула расчета выгоды и защита от двойного учета

Математический расчет захваченной выгоды осуществляется по формуле:

$$\text{Захваченная выгода} = \text{Базовая линия} \times \text{Применимый объем} \times \text{Уровень внедрения} \times \text{Атрибуция} \times \text{Коэффициент захвата}$$

- **Базовая линия:** текущая стоимость процесса или время выполнения до оптимизации.
- **Уровень внедрения (Adoption Rate):** процент команды, который реально использует новый инструмент ежедневно.
- **Атрибуция:** доля эффекта, вызванная именно этим инструментом, а не другими рыночными факторами.
- **Коэффициент захвата (Capture Rate):** какая часть освобожденного ресурса превращена в деньги или дополнительные сделки.

> [!IMPORTANT]
> Если сотрудник сберег 2 часа в день, но компания не сократила внешние расходы и не привлекла дополнительных клиентов, коэффициент захвата равен **0**. Освобожденная мощность — это лишь потенциал, а не реализованный денежный поток.

---

## 7. Сценарии, анализ чувствительности и пороги решений

Отдельный точечный прогноз всегда оказывается ошибочным. Надежное решение требует анализа диапазонов.

### 7.1. Моделирование базового, оптимистичного и пессимистичного сценариев

:::tabs
=== Базовый сценарий (Base Case)
Консервативные ожидания: уровень внедрения 60%, коэффициент захвата 40%, плановые расходы на токены без перерасхода. Проект генерирует положительный ROI в течение 18 месяцев.
=== Пессимистичный сценарий (Downside)
Сложное внедрение: саботаж персонала (внедрение 30%), задержка интеграции на 4 месяца, рост затрат на API на 25%. Моделируется убыток и критические условия выхода из проекта.
=== Оптимистичный сценарий (Upside)
Быстрая адаптация: уровень внедрения 85%, высвобожденные мощности полностью направлены на новое направление продаж. Финансы проверяют, чтобы оптимизм не строился на фантазиях.
:::

### 7.2. Однофакторный анализ чувствительности и точка безубыточности

Анализ чувствительности определяет наиболее уязвимые места бизнес-модели:
- При каком минимальном уровне внедрения проект остается безубыточным?
- Какой максимальный рост цен вендора на токены выдержит юнит-экономика?
- Сколько месяцев задержки интеграции превращают NPV в отрицательное значение?

> [!TIP]
> Если для достижения безубыточности требуется уровень внедрения свыше 80%, проект несет чрезвычайно высокий риск провала. Снижайте начальные затраты или пересматривайте архитектуру решения.

---

## 8. Реализация выгод: трекинг, отклонения и пересчет прогноза

Подписание бюджета на заседании комитета — это не финал, а начало фазы захвата ценности.

### 8.1. Четырехшаговый цикл контроля и контрольная точка G7

На этапе **S9** проект переходит в постоянный цикл мониторинга:
1. **Измерение факта:** регулярное снятие фактических операционных данных из CRM/ERP систем.
2. **Объяснение отклонений:** разложение разницы между планом и фактом на факторы (тайминг, объем, внедрение, стоимость токенов).
3. **Корректирующие действия:** назначение ответственных за устранение отставания с четкими сроками.
4. **Пересчет прогноза (Re-forecasting):** обновление ожиданий без переписывания истории утвержденного исходного плана.

### 8.2. Процедура объяснения отклонений и актуализация прогнозов

Контрольная точка **G7** проверяет реальный факт. Утвержденный бизнес-кейс версионируется: первоначальная версия (Baseline v1.0) навсегда остается неизменной, а все изменения отражаются в версиях пересчета (Forecast Q1, Forecast Q2). Это обеспечивает полную прозрачность перед аудитом.

---

## 9. Навык управления кейсом и автоматизация в Claude

Для ускорения работы разработчики могут использовать специализированные скилы и промпты в Claude.

### 9.1. Роль и ограничения кастомного Markdown-скила

Специализированный скил Claude действует как строгий рецензент:
- Он следит за соблюдением протокола S0–S9;
- Требует указывать источники для каждого допущения;
- Блокирует попытки перейти к финансовой модели без сформированной рамки решения (Gate G1).

Он категорически **не имеет права**: самостоятельно выдумывать цифры базовой линии, утверждать пороги или подписывать переход между контрольными точками.

### 9.2. Тестирование, безопасность данных и резервные протоколы

:::tabs
=== Claude Skill (Автоматизированный)
Использование загруженного ZIP-скила или системной инструкции в Claude Projects. Обеспечивает быструю структуризацию мыслей, интервью по выявлению допущений и генерацию драфтов меморандумов.
=== Ручной режим (Промпты P00–P13)
Резервный протокол: пошаговое выполнение через стандартные промпты без сторонних модулей. Гарантирует работоспособность системы при любых обновлениях или ограничениях интерфейса.
=== Рабочая книга Excel/Sheets
Числовой базис: все расчеты ведутся исключительно в формульных таблицах. Claude используется только для аудита формул, поиска логических коллизий и подготовки текстовых пояснений.
:::

> [!WARNING]
> Никогда не загружайте чувствительные финансовые данные клиентов, персональные данные сотрудников или коммерческую тайну в публичные инстансы моделей. Используйте анонимизированные или индексированные показатели.