Double Diamond для AI-трансформации: от хаоса к AI Native процессам

Большинство AI-трансформаций проваливаются не из-за плохих моделей. Они проваливаются из-за того, что команда начинает с решения, не разобравшись в проблеме. «Давайте внедрим GPT в клиентскую поддержку» — звучит конкретно, но это не стратегия. Это гадание.

Фреймворк Double Diamond, пришедший из дизайн-мышления, даёт структуру, которая защищает от этой ловушки. Два ромба — два цикла расширения и сужения фокуса, — которые помогают сначала понять проблему, а потом уже проектировать решение.

Я адаптировал Double Diamond для задач AI-трансформации и за последний год применял его в нескольких проектах. В этой статье расскажу, как это работает на практике — с конкретными инструментами, примерами и типичными ошибками.

Double Diamond: быстрое напоминание

graph LR
    subgraph diamond1 ["Ромб 1: Проблема"]
        D1["Discover
Расширяем"] --> D2["Define
Сужаем"]
    end
    subgraph diamond2 ["Ромб 2: Решение"]
        D3["Develop
Расширяем"] --> D4["Deliver
Сужаем"]
    end
    D2 -->|"Трансформационный
бриф"| D3

    style D1 fill:#2a2a2a,stroke:#FFB870,color:#FFB870
    style D2 fill:#1a1a1a,stroke:#FFB870,stroke-width:2px,color:#FFB870
    style D3 fill:#2a2a2a,stroke:#FF8A50,color:#FF8A50
    style D4 fill:#1a1a1a,stroke:#FF8A50,stroke-width:2px,color:#FF8A50

Фреймворк был предложен британским Design Council и состоит из четырёх фаз:

1. Discover (Исследование) — расширяем понимание: собираем данные, разговариваем с людьми, изучаем контекст
2. Define (Определение) — сужаем фокус: формулируем конкретную проблему, которую будем решать
3. Develop (Разработка) — снова расширяем: генерируем варианты решений, прототипируем, экспериментируем
4. Deliver (Внедрение) — сужаем до финального решения: тестируем, доводим до продакшена, масштабируем

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

Ромб 1: Понимание проблемного пространства

Фаза Discover: копаем вширь

На этом этапе цель — собрать максимум информации о текущем состоянии процессов. Не фильтруя, не оценивая, не делая выводов. Просто данные.

graph TD
    PM["Process Mining
Данные из ERP/CRM"] --> MAP["Карта реальных
процессов"]
    SI["Stakeholder
Interviews"] --> PP["Pain Points"]
    OBS["Наблюдение
за работой"] --> PP
    MAP --> THICK["«Толстая папка»
Данные + гипотезы"]
    PP --> THICK

    style PM fill:#2a2a2a,stroke:#FFB870,color:#FFB870
    style SI fill:#2a2a2a,stroke:#FFB870,color:#FFB870
    style OBS fill:#2a2a2a,stroke:#FFB870,color:#FFB870
    style THICK fill:#1a1a1a,stroke:#FF8A50,stroke-width:2px,color:#FF8A50

Инструменты, которые работают:

Process Mining. Если у вас есть системы с логами (ERP, CRM, тикет-системы), process mining покажет, как процессы работают на самом деле, а не как описано в регламентах. Celonis, Disco, ProM — инструменты разные, принцип один: восстановить реальный flow из данных.

Что process mining даёт для AI-трансформации:

• Карту реальных процессов с частотами и длительностями
• Бутылочные горлышки — где процесс тормозит
• Отклонения от нормы — где люди «обходят» систему
• Данные для приоритизации: какие процессы отнимают больше всего времени

Stakeholder Interviews. Разговоры с людьми, которые делают работу. Не с руководителями, которые думают, что знают, как работа делается, а с исполнителями. Операторами колл-центра, менеджерами по логистике, HR-специалистами — теми, кто каждый день проживает процесс на себе.

Ключевые вопросы:

• Что в вашей работе отнимает больше всего времени?
• Какие решения вы принимаете чаще всего? По каким критериям?
• Где вы чувствуете, что делаете «обезьянью работу»?
• Что вы бы автоматизировали в первую очередь?
• Что точно нельзя автоматизировать и почему?

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

Pain Point Mapping. Визуальная карта болевых точек, наложенная на карту процессов. Для каждой точки фиксируем: частоту, критичность, текущий workaround, потенциал для AI.

На выходе из фазы Discover у вас должна быть «толстая папка» — много данных, много наблюдений, много гипотез. Это нормально. Следующая фаза их отсортирует.

Фаза Define: формулируем трансформационный бриф

Здесь мы сужаем. Из всего массива данных нужно выделить конкретный фокус трансформации.

Критерии приоритизации:

• Impact (влияние): Сколько времени/денег/ошибок экономим?
• Feasibility (реализуемость): Есть ли данные? Есть ли процесс, который можно оцифровать? Готовы ли люди?
• Risk (риск): Что случится, если AI ошибётся? Цена ошибки в финансовом расчёте — это одно. Цена ошибки в медицинской рекомендации — совершенно другое.
• Strategic Alignment (стратегическое соответствие): Соответствует ли это приоритетам бизнеса?

Результат фазы Define — трансформационный бриф: документ на 2-3 страницы, который чётко формулирует, какой процесс мы трансформируем, почему именно его, какие метрики улучшаем и каких ограничений придерживаемся.

Бриф — это точка перегиба между двумя ромбами. Если он сформулирован плохо — всё, что дальше, будет шатким. Я рекомендую утверждать бриф со стейкхолдерами: и с бизнесом, и с IT, и с командой, которая живёт в этом процессе. Без консенсуса на этом этапе дальше будет больно.

Пример: HR-процесс найма

Фаза Discover: process mining по ATS-системе показывает, что средний цикл найма — 47 дней. Интервью с рекрутерами выявляют, что 60% времени уходит на скрининг резюме и первичную коммуникацию с кандидатами. Pain point mapping показывает: рекрутеры жалуются на рутину переписки и шаблонные отказы, а нанимающие менеджеры — на качество отобранных кандидатов.

Фаза Define: бриф фокусируется на этапе «первичный скрининг + коммуникация». Метрика успеха: сокращение цикла найма на 30% без снижения quality of hire. Ограничение: финальное решение о приглашении на интервью остаётся за человеком.

Ромб 2: Проектирование и внедрение AI Native процессов

Здесь начинается самое интересное — и самое сложное. Второй ромб — это про решение, но не любое, а AI Native.

Что значит AI Native

graph LR
    subgraph old ["AI-дополнение"]
        H1["Человек делает"] --> AI1["AI помогает"]
    end
    subgraph new ["AI Native"]
        AI2["AI делает"] --> H2["Человек
контролирует"]
    end
    old -->|"Трансформация"| new

    style H1 fill:#2a2a2a,stroke:#888888,color:#888888
    style AI1 fill:#2a2a2a,stroke:#888888,color:#888888
    style AI2 fill:#1a1a1a,stroke:#FF8A50,stroke-width:2px,color:#FF8A50
    style H2 fill:#1a1a1a,stroke:#FFB870,stroke-width:2px,color:#FFB870

AI Native процесс — это процесс, спроектированный с нуля с учётом возможностей AI. Это не «берём старый процесс и прикручиваем чат-бота». Это фундаментальное переосмысление: а как бы мы делали это, если бы AI был с первого дня?

Разница принципиальная:

В AI Native подходе человек переходит из роли исполнителя в роль супервайзера и обработчика исключений. Это меняет и процесс, и требования к людям, и метрики.

Фаза Develop: генерируем варианты

На этом этапе мы проектируем целевой AI Native процесс. Важно: не один вариант, а несколько. Double Diamond настаивает на расширении перед сужением.

Что помогает:

To-Be Process Design. Рисуем целевой процесс, где AI — полноценный участник. Для каждого шага определяем:

• Кто его выполняет: AI, человек, или AI с human-in-the-loop
• Какие данные нужны на входе
• Какой результат на выходе
• Какие условия для эскалации на человека

Proof of Concept (PoC). Быстрые эксперименты — за дни, не за месяцы. Берём реальные данные (прошлые резюме, исторические тикеты, логи маршрутов), прогоняем через AI-решение и сравниваем с результатами людей.

PoC должен ответить на три вопроса:

1. Способен ли AI выполнять эту задачу на приемлемом уровне?
2. Какой процент случаев потребует вмешательства человека?
3. Какие типы ошибок допускает AI и насколько они критичны?

Shadow Mode. Прежде чем передавать AI реальную работу, запускаем его «в тени» — AI делает свою работу параллельно с человеком, но результат AI не идёт клиенту. Сравниваем выходы. Это бесценно для калибровки и выявления edge cases.

Фаза Deliver: внедряем и масштабируем

Из нескольких вариантов выбираем один и доводим до продакшена.

graph LR
    P["Пилот
1 команда"] --> M["Замер
метрик"]
    M --> K["Корректировка"]
    K --> S["Масштабирование"]
    S --> M2["Замер"]
    M2 --> K2["Корректировка"]
    K2 --> FULL["Full Rollout"]

    style P fill:#2a2a2a,stroke:#FFB870,color:#FFB870
    style M fill:#1a1a1a,stroke:#FF8A50,color:#FF8A50
    style K fill:#2a2a2a,stroke:#FFB870,color:#FFB870
    style S fill:#1a1a1a,stroke:#FF8A50,stroke-width:2px,color:#FF8A50
    style FULL fill:#1a1a1a,stroke:#4CAF50,stroke-width:2px,color:#4CAF50

Этапы внедрения:

1. Пилот на ограниченном скоупе. Одна команда, один продукт, один регион. Не пытайтесь раскатать на всю компанию сразу.

2. Обучение команды. Люди должны понимать, как работает новый процесс, какова их новая роль, как эскалировать проблемы. Это change management, и его нельзя пропускать.

3. Мониторинг и петля обратной связи. Первые недели — ежедневный разбор результатов. Какие кейсы AI обработал хорошо? Какие провалил? Почему? Корректируем промпты, правила эскалации, пороги уверенности.

4. Масштабирование. После стабилизации метрик — расширяем на другие команды, продукты, регионы. Постепенно.

Практические примеры

Логистика: маршрутизация доставки

graph TD
    subgraph r1 ["Ромб 1"]
        A1["23% доставок
вне SLA"] --> A2["3ч ручного
планирования"]
        A2 --> BRIEF["Бриф: SLA до 10%
Время -80%"]
    end
    subgraph r2 ["Ромб 2"]
        BRIEF --> AI["AI-маршрутизация
в реальном времени"]
        AI --> LOG["Логист =
исключения"]
        LOG --> RES["SLA 8%
Планирование: 20 мин"]
    end

    style A1 fill:#2a2a2a,stroke:#FF8A50,color:#FF8A50
    style BRIEF fill:#1a1a1a,stroke:#FFB870,stroke-width:2px,color:#FFB870
    style AI fill:#1a1a1a,stroke:#FF8A50,stroke-width:2px,color:#FF8A50
    style RES fill:#2a2a2a,stroke:#4CAF50,color:#4CAF50

Ромб 1. Process mining показал: 23% доставок выходят за рамки обещанного окна. Интервью с логистами: они тратят 3 часа утром на ручное составление маршрутов, но к обеду половина маршрутов ломается из-за пробок и отмен.

Бриф: переработать процесс маршрутизации, чтобы сократить нарушения SLA до 10% и уменьшить время планирования на 80%.

Ромб 2. AI Native процесс: AI-система формирует маршруты автоматически с учётом данных о трафике в реальном времени, пересчитывает при изменениях. Логист работает с исключениями: нестандартный груз, VIP-клиенты, форс-мажоры.

Результат пилота: нарушения SLA сократились до 8%, время планирования — с 3 часов до 20 минут ежедневного контроля.

Банкинг: обработка заявок на кредит

Ромб 1. Средний срок рассмотрения заявки — 5 рабочих дней. 70% времени уходит на сбор и верификацию документов. Клиенты жалуются на долгое ожидание и непрозрачность статуса.

Бриф: сократить время от заявки до решения до 1 рабочего дня для стандартных кейсов.

Ромб 2. AI Native процесс: AI-агент принимает заявку, автоматически запрашивает недостающие документы у клиента через мессенджер, верифицирует данные через API (бюро кредитных историй, налоговая), формирует предварительное решение. Кредитный аналитик верифицирует решение AI для заявок выше порога суммы или при обнаружении аномалий.

Типичные ошибки

За время работы с Double Diamond в контексте AI-трансформации я собрал коллекцию повторяющихся ошибок.

Ошибка 1: Пропуск первого ромба

Самая частая. «Мы и так знаем наши проблемы, давайте сразу к решению.» Нет, не знаете. Process mining почти всегда показывает картину, отличающуюся от того, что думает руководство. А интервью с исполнителями выявляют боли, которые наверх не доходят.

Ошибка 2: AI-обёртка вместо AI Native

Компания берёт старый процесс из 15 шагов с 7 ручными хендоффами и добавляет AI-ассистента на два шага. Процент улучшения — 5-10%. Разочарование. А нужно было перепроектировать процесс с нуля — тогда улучшение было бы 50-70%.

Ошибка 3: Нет метрик до начала

Если вы не измерили текущее состояние, вы не докажете улучшение. Фиксируйте базовые метрики до начала трансформации: время выполнения, процент ошибок, стоимость, удовлетворённость клиентов.

Ошибка 4: Забыли про людей

AI Native процесс меняет роли. Рекрутер, который 80% времени скринил резюме, теперь должен быть экспертом по оценке качества работы AI и обработке сложных кейсов. Это другой набор навыков. Без обучения и change management трансформация забуксует — не из-за технологий, а из-за сопротивления.

Ошибка 5: Большой взрыв вместо итераций

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

Метрики трансформации

Как понять, что трансформация работает? Несколько категорий метрик.

Операционные:

• Время выполнения процесса (cycle time)
• Процент автоматически обработанных кейсов (automation rate)
• Процент ошибок AI vs. человека
• Время на обработку исключений

Бизнесовые:

• ROI трансформации
• Стоимость обработки одного кейса
• Удовлетворённость клиентов (NPS, CSAT)
• Скорость масштабирования (время от пилота до full rollout)

Человеческие:

• Удовлетворённость сотрудников новым процессом
• Время адаптации к новой роли
• Процент эскалаций от AI к человеку (должен снижаться со временем)

Хорошая трансформация улучшает метрики во всех трёх категориях. Если операционные метрики растут, а человеческие падают — вы автоматизируете людей вместо процессов. Это тупиковый путь.

Итог

Double Diamond — не магическая формула. Это дисциплина мышления: не прыгать к решению, пока не поняли проблему. Не останавливаться на первом варианте, пока не исследовали альтернативы. Не раскатывать на всех, пока не проверили на немногих.

Для AI-трансформации эта дисциплина критически важна. Потому что соблазн «воткнуть ChatGPT и посмотреть, что получится» слишком велик, а цена хаотичной трансформации — потерянные месяцы и разочарование, после которого слово «AI» в компании становится токсичным.

Два ромба. Проблема, потом решение. Широко, потом узко. Просто — но удивительно эффективно.