Спешите? Экспресс-диагностика за 45 минут → для первого анализа без глубокого погружения.

От диагностики процесса до запуска и мониторинга. Методология помогает руководителям решить, какие задачи отдать ИИ, как проверять результат и не потерять при этом контроль.

Зачем эта методология?

59% организаций накладывают ИИ на старые процессы, не переосмысливая, как люди и ИИ взаимодействуют (Deloitte AI Institute, 2026). Результат: получают ожидаемый возврат инвестиций в 2 раза реже, а 95% пилотов по внедрению ИИ не выходят из экспериментальной фазы (Svitla Systems, 2026) — нет структуры для повторения результата.

Методология решает четыре проблемы:

1
Проблема делегирования
Что отдать ИИ, а что пока не стоит. Граница подвижная: зависит от задачи, модели и контекста.
2
Разрыв ответственности
ИИ не несёт ответственности. Если результат попал в работу без владельца — виноватого не найти.
3
Парадокс проверки
ИИ быстро генерирует, но проверка требует тех же экспертов, которых хотели разгрузить. Часто, чем дешевле генерация, тем дороже валидация.
4
Ловушка зависимости
Через месяцы делегирования навыки деградируют. Способность ловить ошибки ИИ падает именно тогда, когда она нужнее всего.

Каждый этап методологии адресует одну или несколько из этих проблем. Подход работает на любом масштабе — от пилота на одной-двух задачах до масштабной AI-трансформации. Инструмент одинаковый, растёт глубина применения. Начать можно с одного процесса: первый этап — Диагностика, 15–20 минут.

Три кейса провала

Klarna заменила 700 сотрудников поддержки ИИ-агентом. Удовлетворённость клиентов упала — людей вернули (DigitalApplied, 2024). Технология работала. Не было критериев качества и мониторинга.

Air Canada позволила чатботу консультировать клиентов по тарифам. Чатбот ошибся — суд обязал компанию возместить ущерб и установил прецедент: компания отвечает за ошибки своего ИИ (McCarthy Tétrault, 2024). Не было владельца результата и проверки перед ответом клиенту.

Mata v. Avianca (2023): юристы сдали в суд документ с прецедентами, сгенерированными ChatGPT. Прецеденты оказались несуществующими — штраф $5 000 (U.S. District Court, SDNY). Не было критериев проверки и ответственного за результат.

Во всех трёх случаях технология отработала корректно. Провалилась организационная сторона внедрения.

Почему пилоты не выходят на масштаб

89% провалов при масштабировании ИИ объясняются семью причинами (DigitalApplied, март 2026, опрос 650 руководителей; KPMG, 2025; McKinsey, 2026):

Причина провала Доля компаний Что делает методология
Нет владельца результата 67% Внедрение: именованный владелец каждого результата ИИ
Нет мониторинга качества 61% Мониторинг: протокол проверки + стоп-факторы
Качество падает при масштабе 54% Проектирование: критерии проверки формулируются до задачи
Интеграция с существующими системами 48% Диагностика выявляет этот блокер до запуска пилота
Недостаток данных для обучения 39% Декомпозиция разделяет задачи с готовой моделью и задачи, требующие дообучения
«Теневой» ИИ: сотрудники используют без политики компании 50% Диагностика: уровень зрелости + проверка готовности задают минимальные условия контроля
Управление автономными агентами не выстроено ~33% Внедрение: уровни автономности 1–4 задают рамку контроля

«Наложить ИИ» или перестроить процесс?

McKinsey разделяет два подхода. Первый — добавить ИИ (ChatGPT, Claude, Qwen, GigaChat, YandexGPT и другие) в существующий процесс, ничего не меняя. Работает для простых задач. Не масштабируется. Второй — перепроектировать рабочий поток с учётом того, что часть работы выполняет ИИ: изменить структуру, роли, точки контроля. Компании-лидеры выбирают второй путь в 55% случаев.

Методология делегирования задач ИИ — инструмент для второго подхода: этапы Декомпозиция → Проектирование → Обоснование дают структуру для перепроектирования, а не просто добавления ИИ поверх существующего процесса.

«Быстрый обзор» в следующем разделе покажет всю структуру за две минуты — прежде чем переходить к Диагностике.

Когда методология не подходит

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

  1. Процесс не описан. Если никто не может объяснить, как процесс работает сейчас — из каких шагов состоит, кто что делает, — декомпозиция невозможна. Сначала опиши процесс, потом анализируй.
  2. Одноразовая задача. Методология окупается на повторяемых процессах. Для разовой задачи (написать одно письмо, сделать один отчёт) — просто попробуй ИИ напрямую, без анализа.
  3. Нет владельца процесса. Если некому принять решение о делегировании и отвечать за результат, методология не заработает. Это управленческий подход, а не инструмент самообслуживания.
  4. Нет критериев качества. Если невозможно описать, что значит «хороший результат» для этого процесса, — нечем проверять работу ИИ, а без проверки нет контроля. Это часто бывает с полностью творческими или стратегическими процессами, где границы размыты и результат субъективен.

Если процесс не подходит сейчас — это не приговор. Опиши его, назначь владельца, сформулируй критерии — и вернись к методологии.

Быстрый обзор

Фаза 1 — Анализ: «Стоит ли делегировать?»

Диагностика Зачем анализируем + как работает процесс сейчас + кто делает + готова ли команда (Проверка готовности: 4 вопроса ДА/НЕТ)
Декомпозиция Разбить процесс на блоки + оценить каждый по EPOCH (нужен ли человек?) + проверить риски → Экспресс-оценка (10 мин)
Проектирование Для каждого блока: сначала описать критерии проверки, потом задачу (нельзя делегировать то, что не можешь проверить) + Карточка
Обоснование Предварительный ROI перед пилотом → после пилота: фактический ROI + решение

Фаза 2 — Внедрение: «Как и с каким результатом?»

Только при положительном решении на этапе Обоснование

Внедрение Назначить владельца + выбрать уровень контроля + запустить пилот
Мониторинг Факт vs прогноз → корректируй или масштабируй (Управленческий цикл)

Как этапы связаны (Управленческий цикл)

Методология работает по принципу петли обратной связи — аналог цикла PDCA (Планируй → Делай → Проверяй → Корректируй). Один виток: Анализ (Plan) → Внедрение (Do) → Мониторинг (Check + Act). После мониторинга возможны три пути:

  • Следующий цикл того же процесса — основной путь. Продолжаем работать, корректируем уровни автономности.
  • Возврат к Диагностике того же процесса — если результаты сильно расходятся с прогнозом.
  • Диагностика нового процесса — когда текущий процесс стабилизировался и готов к масштабированию.

Обоснование проходится дважды

  • Первый проход (оценка) — предварительный расчёт ROI и транзакционных издержек перед пилотом
  • Второй проход (факт) — фактический расчёт после пилота, сравнение с прогнозом

Четыре обратные петли (это нормально!)

  1. Проектирование → Декомпозиция: не можешь описать проверку → блок слишком большой → декомпозируй
  2. Обоснование (оценка) → Диагностика: ОСТАНОВИТЬ → выбери другой процесс или пересмотри охват
  3. Обоснование (факт) → Проектирование: факт сильно расходится с прогнозом → скорректируй Карточку делегирования
  4. Мониторинг → Диагностика: результаты расходятся → переанализируй

Ключевые понятия

Три уровня декомпозиции

Уровень Что это Пример
Процесс Целостная деятельность с началом и концом «Планирование спринта», «Анализ рынка»
Этап Крупный шаг внутри процесса (3–7 на процесс) «Сбор информации», «Распределение задач»
Блок Минимальная единица работы с чётким входом, выходом и проверкой «Выгрузить задачи из трекера»

Четыре зоны делегирования

Определяются на этапе Декомпозиция:

🟢
Автоматизация

ИИ делает, человек проверяет

🟡
Усиление

ИИ — черновик, человек дорабатывает

🟠
Коллаборация

Человек — автор, ИИ помогает

🔴
Человек

Человек делает сам

Зоны — результат EPOCH-скоринга (этап Декомпозиция): определяют, кто автор результата. Уровни автономности — настраиваются на этапе Внедрение: определяют, как контролировать выполнение.

Зачем три уровня

Процесс слишком крупный для оценки — внутри него всегда смешаны рутина и творческая работа. Пример: в «Планировании спринта» блок «Выгрузить задачи из трекера задач» — рутина (🟢 Автоматизация), а «Приоритизировать список задач с учётом бизнес-целей» — суждение руководителя (🟠 Коллаборация). Без декомпозиции до блоков оценишь процесс целиком, получишь «среднюю» зону — и упустишь автоматизируемые блоки.

Почему «блок», а не «задача»

Руководители привыкли к слову «задача» — его используют при делегировании сотруднику. В методологии мы вводим термин «блок» (делегируемый блок), потому что:

  1. Блок имеет жёсткую структуру: вход → выход → критерии проверки
  2. Для блока описаны критерии проверки: нельзя рассчитывать на здравый смысл исполнителя — каждое действие описывается явно. Подробнее — этап Проектирование.
  3. Термин «блок» сигнализирует о готовности: у него определены вход, выход и критерии проверки — задача готова к передаче.

Примеры отличий задачи сотруднику и блока делегирования

Аспект Задача (сотруднику) Блок делегирования (в методологии)
Формулировка «Собери причины срыва сроков» «Сопоставить даты план/факт из трекера, выделить отклонения > 2 дней, для каждого найти комментарий»
Проверка Сотрудник сам знает «достаточно» Критерии «принято»/«отклонено» заданы заранее
Контекст Сотрудник использует здравый смысл Контекст передаётся явно через параметр «Входные данные» в Карточке делегирования

Правило

  • В таблицах, карточках, результатах этапов — «блок»
  • В пояснительном тексте — «задача» допустима как разговорный синоним

Короткая формула: процесс — это ЧТО ты анализируешь, этап — КАК ты структурируешь, блок — ЧТО ты оцениваешь и делегируешь.

Пример: процесс «Планирование спринта» → этап «Анализ и приоритизация» → блоки «Сравнить план с фактом» (🟢 Автоматизация), «Собрать причины отклонений» (🟡 Усиление), «Приоритизировать список задач» (🟠 Коллаборация). Один этап — три зоны. Без декомпозиции до блоков этого не видно.

Пилот

Пилот — 2–4 недели реального использования на 1–2 блоках при уровне контроля 2: ИИ выполняет, человек проверяет каждый результат до использования. Цель — собрать фактические данные для Обоснования: время, ошибки, экономия.

Пилот завершён, когда накоплено 4+ проверенных цикла и заполнены три метрики: время до/после, частота ошибок, фактическая экономия или дополнительный эффект.

6 этапов

Навыки команды

Не все задачи уйдут ИИ полностью. Задачи из зон Усиление и Коллаборация останутся в связке человек + ИИ. Для них сотрудникам нужны навыки: поставить задачу, проверить результат, скорректировать. Курс «После промптов» учит этому за шесть писем.

Подробнее о курсе →

Часто задают вопросы

Чем методология отличается от курса по промптам?

Методология — для руководителя, который решает, какие задачи отдать ИИ и как контролировать результат. Курс «После промптов» — для сотрудников, которые работают с ИИ ежедневно. Это два уровня одной задачи.

Для компании какого размера подходит?

Подход работает на любом масштабе — от пилота на одной-двух задачах до AI-трансформации компании на 300+ человек. Инструмент один, растёт глубина применения.

Нужна ли IT-команда для работы с методологией?

Нет. Методология — управленческий подход. Она отвечает на вопросы, что отдать ИИ и как организовать контроль. Технические детали — выбор инструментов, настройка агентов, инфраструктура — за рамками методологии.

Методология бесплатная?

Да. Методология открытая — лицензия CC BY-SA 4.0. Используйте в работе, адаптируйте под свою компанию, делитесь с командой. Единственное условие — указать авторство.

Начните с одного процесса

Не нужно перестраивать всю команду. Возьмите один процесс, пройдите Экспресс-диагностику за 45 минут — и поймёте, есть ли смысл идти дальше.