> For the complete documentation index, see [llms.txt](https://scrumtrek.gitbook.io/iishki-1/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://scrumtrek.gitbook.io/iishki-1/transformation/ai-process-redesign.md).

# Перестройка бизнес-процессов с AI

## Что это

Полная переработка одного-трёх ключевых бизнес-процессов вокруг AI — от глубокого понимания текущего состояния до работающей системы в production, с метриками и governance. 12 недель, 4 контрольные точки (Gate), каждый проект выходит с кейсом с цифрами.

Это не «добавляем LLM к существующему процессу». Это «строим процесс заново с AI в ядре, вводим kill switch для безопасности, мониторим каждое решение, передаём команде с Runbook и Свод правил (Rulebook)».

> **Кратко:** Полная переработка 1-3 бизнес-процессов вокруг AI — от аудита до production с метриками. **Для кого:** VP Operations, CDO, владелец процесса — готовы инвестировать 12 недель в трансформацию. **Результат:** Процесс в production, ROI по 3 осям, Runbook и Свод правил, кейс с вашими цифрами. **Сроки:** 12 недель, 4 контрольные точки (Gate).

## Для кого

* **VP Operations** или **VP Transformation** — отвечает за операционную эффективность
* **Chief Digital Officer** — координирует AI-инициативы
* **Владелец процесса** — тот, кто в повседневной работе управляет процессом и видит его боли
* **Спонсор проекта** — обычно руководитель выше, утверждает бюджет

Ключевой критерий: вы владеете процессом и бюджетом на его трансформацию. Не консультируете, а собственно трансформируете.

## Участие клиента

Мы не делаем это в бункере. Трансформация процесса — это **совместная работа**.

| Роль                             | Участие                             | Что делает                                                                                                                                                |
| -------------------------------- | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Владелец процесса**            | 50% времени (12 недель = 240 часов) | Интервью, shadow observation, валидирует целевой дизайн, участвует в прототипировании, принимает решения на Gates, участвует в Shadow Mode и Parallel Run |
| **Спонсор (руководитель)**       | 2 часа в неделю                     | Встречи статуса, одобрение на Gates, снятие блокировок в организации, alignment с требованиями compliance                                                 |
| **3-5 операционных сотрудников** | 4 часа в неделю                     | Shadow observation, feedback на прототип, пилот в Shadow Mode, feedback в Parallel Run, обучение на Runbook/Свод правил                                   |

## Команда Кактуса

* **Process Lead** (мой руководитель проекта, 60% FTE) — дизайн, координация Gates, мониторинг ROI
* **AI Engineer** (разработка, 80% FTE) — прототипирование, integration, production deployment, мониторинг
* Опционально **Data Analyst** (20-40% FTE) — сбор метрик, анализ, dashboard

Обычно 2-3 человека. Для сложных проектов — 4.

## Как работает — 3 фазы

### Фаза 1: Понять и спроектировать (недели 1-4)

#### Неделя 1: Аудит процесса в деталях

**Что делаем**:

* Глубинные интервью: 5-10 участников процесса (сотрудники, менеджеры, stakeholders)
* Shadow observation: 20-30 часов наблюдения за процессом в реальности
* Сбор метрик: текущее время цикла, объём, ошибки, переработка, handoffs, bottlenecks
* Анализ систем: какие системы используются, как они интегрированы, где ручной ввод

**Что получаете**:

* Карта текущего процесса (визуальная карта процесса)
* Baseline-метрики: время цикла, стоимость, качество, handoff count, переработка
* Краткий отчёт о состоянии

**Контрольная точка**: Process Lead показывает вам findings. Вы подтверждаете, что мы поняли правильно.

***

#### Неделя 2: Value Stream Mapping и оценка трансформируемости

**Что делаем**:

* Value Stream Mapping: каждый шаг оцениваем по матрице (время, ценность для клиента, сложность, вариативность)
* A1-A5 scoring: каждый шаг оцениваем по целевому уровню автономии AI:
  * **A1** — AI подсказывает, человек решает (ассистент)
  * **A5** — AI действует полностью автономно, человек проектирует правила и границы
* Scoring 3-Gate: для каждого шага выбираем кандидатов на трансформацию на основе impact (снижение цикла, стоимости, ошибок) × effort трансформирования

**Что получаете**:

* Value Stream Map с отметкой узких мест
* A1-A5 карта каждого шага
* Выбранные шаги для трансформации (обычно 3-7 шагов из 15-20)

**Gate 1: Go / Conditional Go / No-Go**

* Есть ли что трансформировать? Есть ли потенциал ROI?
* Если потенциал низкий — мы говорим честно и экономим вам деньги. Может быть, этот процесс не готов, или нужен другой подход.
* Если Go → переходим в неделю 3.

***

#### Неделя 3: Выбор паттерна и проектирование целевого процесса

**Что делаем**:

* Из 8 агентных паттернов (Decision Agent, Agentic Loop, Intent Recognition, Workflow Router, Escalation Chain, Hybrid Human-AI, Batch Processor, Real-time Monitor) выбираем подходящие для ваших шагов
* Пример: для шага «Классификация заявок» подходит Decision Agent (чёткие классы, структурированный вход), для «Генерация ответа клиенту» подходит Agentic Loop (может потребоваться несколько итераций)
* Проектируем целевой процесс: какие шаги делает AI, какие люди, где handoffs, где kill switch, какие правила эскалации
* Выбираем метрики: как мы будем мерить успех. Обычно 3 оси: эффективность (время, стоимость), качество (ошибки, удовлетворённость), скорость (цикл, пропускная способность)

**Что получаете**:

* Целевой процесс (визуальная карта с обозначением шагов AI и человека)
* Выбранный паттерн/паттерны с обоснованием
* Метрики и целевые значения (обычно 20-40% улучшение по эффективности, 10-20% по качеству)

**Контрольная точка**: Смотрим на целевой процесс вместе. Вы говорите: это реалистично? Это решает нашу боль?

***

#### Неделя 4: Спринт прототипирования

**Что делаем**:

* AI Engineer пишет MVP агента на выбранном паттерне
* Интегрируем с вашими системами (если есть API, берём оттуда данные; если нет, используем manual input для MVP)
* Пишем протокол логирования решений — логирование каждого решения AI (что на input, какой выбор, confidence score, результат). Это нужно для аудита и governance.
* Готовим протокол двойного запуска: как будет проходить Shadow Mode и Parallel Run, кто отвечает за валидацию, как быстро мы сможем откатиться (kill switch)

**Что получаете**:

* Работающий MVP агента (на ваших данных или на тестовых)
* Протокол логирования решений (логирование каждого решения в структурированный формат)
* План двойного запуска: дни, ответственные, метрики валидирования, kill switch механизм

**Gate 2: Prototype Review**

* Показываем MVP на ваших реальных данных (10-20 примеров)
* Точность по целевой метрике?
* Скорость приемлемая?
* Edge cases понимаем?
* Если точность < 85% для типовых случаев — анализируем причины (другой паттерн, больше обучающих данных, изменение правил эскалации). Обычно 1-2 дня анализа.
* Если точность OK → переходим в Фазу 2.

***

### Фаза 2: Внедрить и валидировать (недели 5-9)

#### Недели 5-6: Shadow Mode

**Что делаем**:

* AI работает в production (или pre-production), но не принимает решений
* Для каждого case: AI даёт рекомендацию, человек принимает решение
* Сравниваем: что бы выбрал AI vs что выбрал человек. Совпадает? На сколько процентов?
* Логируем ошибки, edge cases, когда AI ошибался или был неуверен

**Что получаете**:

* Лог 500-2000 случаев (зависит от volume вашего процесса)
* Dashboard точности: по каким категориям AI ошибается, где confidence низкая
* Список edge cases для корректировки rules

**Контрольная точка**: обычно после недели 5. Смотрим accuracy. Если <80%, можем добавить неделю Shadow Mode для доработки.

***

#### Недели 7-8: Parallel Run (КЛЮЧЕВОЙ ЭТАП)

**Что делаем**:

* AI и человек работают параллельно на одних и тех же cases
* AI принимает решение, человек принимает решение, результаты сравниваются в real-time
* Ловим случаи, когда AI ошибался, но человек тоже ошибался (не видимый конфликт)
* Собираем feedback: кому из команды комфортно полагаться на AI? У кого опасения?
* Настраиваем пороги эскалации: если confidence < 70% → эскалируем человеку, если < 50% → берёт human

**Что получаете**:

* Сравнительный отчёт: AI точность vs Human точность на одних данных
* Эскалационная матрица: при каких условиях AI передаёт решение человеку
* Психологическая готовность команды (обычно к концу недели 8 люди уже немного верят AI)

**Gate 3: Cutover Decision**

* Точность AI >= точность человека? (или достаточно близко)
* Скорость улучшилась?
* Команда готова доверить AI эти решения?
* Kill switch настроен и человек может в любой момент отключить?
* Если все Yes → переходим в Cutover. Если нет → ещё 2 недели Parallel Run или stop.

***

#### Неделя 9: Cutover (Переход в production)

**Что делаем**:

* AI начинает принимать реальные решения (целевые шаги из VSM)
* Kill switch в руках менеджера процесса: если что-то пошло не так, можно в 10 минут отключить AI и вернуться к человеку
* Качественный контроль запускается: каждый день идёт логирование метрик (accuracy, speed, ошибки), dashboard обновляется

**Что получаете**:

* Процесс в production с AI
* Kill switch, проверен и работает
* Daily dashboard с метриками

***

### Фаза 3: Закрепить и передать (недели 10-12)

#### Неделя 10: Мониторинг production и первая волна улучшений

**Что делаем**:

* Ежедневный мониторинг метрик (accuracy, speed, escalation rate, cost)
* Анализ ошибок, собранных в production: какие edge cases не покрыли, какие rules нужны
* Первая волна улучшений: добавляем правила для edge cases, настраиваем пороги эскалации на основе реальных данных

**Что получаете**:

* Production dashboard: real-time view на метрики
* Отчёт по ошибкам и планы их исправления

***

#### Неделя 11: Документирование и обучение

**Что делаем**:

* **Runbook** (оперативное): как запустить, как мониторить, как отключить, как добавить новое правило, как эскалировать, как отчитываться
* **Свод правил** (governance): какие решения может принимать AI, какие ограждения, когда требуется approval человека, как логируются решения для аудита (152-ФЗ compliance)
* Обучение команды: каждый участник процесса понимает как работает AI, что он может, что не может, когда ему доверять
* Передача ownership: менеджер процесса становится владельцем, Кактус уходит на advisory

**Что получаете**:

* Runbook (20-30 страниц)
* Свод правил (10-15 страниц)
* Обученная команда (видео + live workshop)
* Ясная структура ownership

***

#### Неделя 12: QBR и масштабирование

**Что делаем**:

* Финальный отчёт: ROI по 3 осям
  * **Efficiency**: сколько сэкономили time per case, annual savings, стоимость результата
  * **Quality**: снижение ошибок, улучшение customer satisfaction (если есть), compliance incidents
  * **Speed**: улучшение цикла, throughput, SLA attainment
* Кейс: ваш процесс, цифры, что работало, что не работало, lessons learned
* Рекомендации по масштабированию: какие другие процессы готовы к трансформации, какой паттерн подходит

**Gate 4: Scale Decision**

* Продолжаем ли мы улучшать этот процесс?
* Какой следующий процесс берём?
* Нужно ли наращивать to [Центра компетенций](/iishki-1/transformation/ai-coe.md) или [AI-директора](/iishki-1/transformation/fractional-cdo.md)?

***

## Ключевые инструменты и гарантии

### 8 агентных паттернов

1. **Decision Agent** — классификация, routing на основе правил
2. **Agentic Loop** — итеративное уточнение (например, генерация + review + редактура)
3. **Intent Recognition** — понимание намерения и выбор тактики
4. **Workflow Router** — маршрутизация в разные процессы на основе характеристик
5. **Escalation Chain** — если AI не уверен → escalate человеку, с градиентом доверия
6. **Hybrid Human-AI** — человек + AI на одном шаге (напр. человек пишет черновик, AI редактирует)
7. **Batch Processor** — async обработка больших объёмов (напр. обработка 1000 заявок за ночь)
8. **Real-time Monitor** — AI следит за метриками и alerting (напр. детектирует аномалии в operational data)

Для каждого выбираем подходящие.

### Двойной прогон (Dual Run) протокол

* **Shadow Mode**: AI не решает, только даёт рекомендацию
* **Parallel Run**: AI решает параллельно с человеком, результаты сравниваются
* **Kill switch**: менеджер процесса может в любой момент отключить AI и вернуться к ручному режиму
* **Escalation rules**: если confidence < threshold → автоматически идёт человеку

Это даёт психологическую безопасность и реальную безопасность.

### Фиксация решений (Decision Capture)

Каждое решение AI логируется:

```
{
  "case_id": "12345",
  "timestamp": "2026-04-12T10:30:00Z",
  "input": {"supplier_name": "...", "invoice_amount": "..."},
  "decision": "approve",
  "confidence": 0.92,
  "reasoning": "Invoice <$10k AND supplier on approved list",
  "human_review": null,
  "escalated": false,
  "outcome": "approved",
  "feedback": null
}
```

Это нужно для:

* Аудита (для compliance и регулятора)
* Feedback loop (AI учится на своих ошибках)
* Trust building (люди видят логику AI)

### Качественный контроль (Quality Gate)

Каждый день автоматически:

* Сравниваем accuracy по типам cases
* Выявляем degradation (если accuracy падает — alert)
* Ловим новые edge cases
* Dashboard обновляется в real-time

***

## Что получаете итого

1. **Перестроенный процесс** в production (шаги выбраны на основе A1-A5 scoring, паттерн подходит к задаче)
2. **Метрики по 3 осям**:
   * Efficiency: annual savings (время + стоимость), стоимость результата (cost-per-outcome)
   * Quality: error rate reduction, compliance score, customer satisfaction delta
   * Speed: cycle time reduction, throughput increase, SLA attainment
3. **Runbook + Свод правил**:
   * Runbook: как оперировать, как добавлять правила, как мониторить, как откатываться
   * Свод правил (Rulebook): какие решения AI может принимать, какие ограничения, compliance requirements
4. **Case Study** с вашими цифрами (не обезличенный пример, а ваш реальный проект)
5. **Governance framework** (Фиксация решений, Качественный контроль, escalation rules, owner и escalation contact)
6. **Рекомендации по масштабированию** (какие процессы дальше, какой паттерн, когда нужен [AI CoE](/iishki-1/transformation/ai-coe.md))

***

## Формат и сроки

* **Продолжительность**: 12 недель
* **Команда Кактуса**: 2-3 человека (Process Lead, AI Engineer, опционально Data Analyst)
* **Вашего времени**: 50% владельца процесса + 2ч/нед спонсора + 4ч/нед операционных сотрудников
* **Параллельные потоки**: можно делать 2-3 процесса параллельно (если разные команды)
* **Интеграция**: работаем с вашими системами (API, databases, инструменты)

***

## Кейсы (примеры)

### Кейс 1: Банк — обработка заявок на кредит

* **Процесс**: classification → risk scoring → decision → communication
* **Паттерн**: Decision Agent
* **Результат**: время цикла 2 дня → 2 часа (12x), cost per decision $50 → $5, accuracy 98% (vs 95% human)
* **Масштабирование**: 5000 заявок/месяц → 10000, экономия $225k/год (стоимость результата упала с $50 на $5)

### Кейс 2: Логистика — маршрутизация заказов

* **Процесс**: order intake → routing to warehouse → packaging → shipping
* **Паттерн**: Workflow Router + Batch Processor
* **Результат**: цикл 4 часа → 1 час, ошибки маршрутизации 2% → 0.3%, cost per shipment $8 → $6

### Кейс 3: HR — обработка резюме

* **Процесс**: screening → initial ranking → scheduling
* **Паттерн**: Decision Agent + Escalation Chain
* **Результат**: время скрининга 30 минут → 3 минуты, качество (кандидаты, которые пришли на собеседование, приняты) 40% → 65%

***

## Часто задаваемые вопросы

**Q: Может ли проект провалиться?** A: Да. На Gate 1 (после недели 2) мы честно говорим, есть ли потенциал. На Gate 2 (после прототипа) проверяем точность. Если потенциал низкий — лучше остановиться, чем тратить 12 недель впустую.

**Q: А если AI ошибётся в production?** A: Kill switch. Менеджер отключает в 10 минут. Плюс escalation rules: если confidence низкая, сам AI отправляет человеку. Плюс Decision Capture Pipeline: каждая ошибка логируется и мы её анализируем.

**Q: Насколько я должен быть вовлечён?** A: 50% времени владельца процесса. Это инвестиция. Результат зависит от качества вашего вклада.

**Q: Что если мой процесс очень специфичный?** A: 8 паттернов покрывают 80% случаев. Для специфичных — адаптируем. Плюс Shadow Mode даёт время на доработку.

**Q: Какова гарантия ROI?** A: Мы не гарантируем. Мы гарантируем процесс (аудит → дизайн → прототип → dual run → production). ROI зависит от вашего процесса и среды. На Gate 1 мы оцениваем потенциал честно.

***

**Дальше**: [AI-директор по подписке](/iishki-1/transformation/fractional-cdo.md) или [Центр компетенций](/iishki-1/transformation/ai-coe.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://scrumtrek.gitbook.io/iishki-1/transformation/ai-process-redesign.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
