Как перестроить бизнес-процессы вокруг ИИ и создать некопируемое конкурентное преимущество: конспект методики Oper8

Доклад посвящен переходу от точечного внедрения ИИ-инструментов (уровень Deploy) к системной перестройке сквозных бизнес-процессов (уровень Reshape) на основе методологии Oper8. Спикеры подробно объясняют, почему простые ИИ-решения вроде чат-ботов не приносят реальной прибыли в P&L и легко копируются конкурентами. Главная идея доклада — создание самообучающегося маховика, в котором каждое действие ИИ фиксируется в логе решений (Decision Log) и обогащает живую базу знаний компании. Этот конспект будет полезен всем, кто стремится внедрять искусственный интеллект не ради хайпа, а для радикального и долгосрочного повышения операционной эффективности бизнеса.

Кому будет полезно

• Роли: Продакт-менеджеры, ИТ-директора (CIO), бизнес-аналитики, фаундеры, руководители операционных департаментов и AI-специалисты.
• Уровень: Middle / Senior / Executive.
• Условия: Если вы уже внедрили базовые ИИ-фичи (суммаризацию, чат-ботов), но не видите измеримого финансового эффекта; если вы поддерживаете нагруженные операционные процессы и ищете стратегическую защиту от конкурентов.

Краткий контекст

Спикеры доклада — Асхат Уразбаев и Сергей Липчанский, эксперты по управлению и авторы книги «Oper8: AI-процессы, которые учатся с каждым клиентом». В своем выступлении они представляют авторскую методологию создания самообучающихся систем на базе больших лингвистических моделей (LLM). Теоретическая часть доклада подкрепляется демонстрацией интерактивной технической карты Oper8 и разбором реального практического кейса внедрения ИИ в медицине.

Ключевые идеи

1. Три уровня зрелости ИИ: от косметической автоматизации к изменению бизнес-модели

• Что сказали: Внедрение ИИ в компаниях делится на три типа: Deploy (добавление ИИ к отдельному шагу существующего процесса), Reshape (перестройка сквозного процесса вокруг ИИ) и Invent (создание принципиально новой бизнес-модели) [00:03:05]. Почти весь рынок сейчас застревает на уровне Deploy, внедряя изолированные инструменты вроде чат-ботов или генераторов писем без сквозных метрик.
• Почему это важно: На уровне Deploy реальный бизнес-эффект в P&L незаметен: автоматизация мелкого шага не позволяет оптимизировать штат, а фичи быстро догоняются конкурентами. Настоящий прорыв происходит на уровне Reshape (эффективность 50%+ по данным BCG), когда процесс проектируется как AI First, меняя роли людей и создавая защищенный сервис.
• Как применить на практике:
  1. Провести аудит текущих ИИ-активностей в компании и классифицировать их по уровням зрелости.
  2. Отказаться от внедрения ИИ-инструментов "в вакууме" без привязки к сквозному бизнес-процессу и измеримым метрикам.

2. Смерть уникальности ИТ-продукта и переход к ИИ-сервису

• Что сказали: Благодаря современному ИИ-кодингу любые продуктовые фичи, логика работы ПО и удобный интерфейс (UX) теперь копируются конкурентами за считанные дни [00:09:18]. Единственным долгосрочным и устойчивым преимуществом бизнеса становится сервис — то, насколько глубоко и мгновенно система способна закрывать нужды конкретного клиента [00:09:42].
• Почему это важно: Традиционные SaaS-продукты теряют ценность, так как клиенты могут собирать локальные фичи сами. Защитить бизнес от копирования может только уникальный накопленный контекст общения и живая база знаний. ИИ позволяет работать с каждым клиентом как с отдельной личностью (например, адаптируя тон общения от формального до зумерского), а не как с широким сегментом рынка [00:10:13].
• Как применить на практике:
  1. Начать собирать и структурировать полную историю и контекст коммуникаций с клиентами в единой системе.
  2. Переориентировать метрики успеха ИТ-решений с "количества выпущенных фич" на "глубину удержания и персонализацию клиентского опыта".

3. Эволюция автономности агентов и изменение роли человека

• Что сказали: Существует 5 уровней автономности ИИ-агентов [00:12:57]. Процесс идет пошагово: от простого ассистента-подсказчика (уровень 1) до полной автономии (уровень 5). При этом для 80% бизнес-кейсов уровень 3 (ИИ выполняет стандартные задачи, а человек проверяет результаты пакетно) является идеальным и достаточным [00:14:35].
• Почему это важно: Стремление сразу достичь полной автономии ИИ экономически неоправданно и сопряжено с огромными рисками. Четкое понимание уровней позволяет правильно распределить роли. Начиная с уровня 4 человек фундаментально меняет свою роль: он перестает быть оператором конкретных кейсов и становится Владельцем процесса, управляющим метриками через общение с ИИ-дэшбордами [00:14:14].
• Как применить на практике:
  1. Для выбранного процесса жестко определить текущий и целевой уровень автономности ИИ-агента.
  2. Не пытаться сразу полностью исключить человека из процесса, а спроектировать интерфейсы для удобной пакетной проверки решений ИИ.

4. Decision Log (Лог решений) как главное топливо для маховика обучения

• Что сказали: Ключевым артефактом и ядром AI First системы является Decision Log — детальный реестр абсолютно всех решений, принятых ИИ-агентами, содержащий полный контекст входящих данных, выданный ответ и итоговый долгосрочный бизнес-результат [00:15:18].
• Почему это важно: Логировать только ошибки системы — критический антипаттерн. Для полноценного обучения маховика необходимо отслеживать и успешные цепочки действий. Decision Log является сырьем, из которого человек (или специализированный ИИ-агент) извлекает новые правила для базы знаний, обеспечивая непрерывное самообучение системы.
• Как применить на практике:
  1. Технически реализовать логирование входящего контекста, промптов, ответов ИИ и последующих действий пользователя в едином структурированном виде (например, JSON).
  2. Настроить отложенное связывание: автоматически добавлять в лог решений бизнес-результат, зафиксированный через несколько дней (факт заказа, возврат клиента).

5. Двухпетлевой маховик и структура живой базы знаний

• Что сказали: Архитектура Oper8 строится на взаимодействии двух контуров: внешнего (общение с клиентом и сбор обучающих сигналов) и внутреннего (анализ лога решений, тестирование и обновление знаний) [00:10:52]. Сама база знаний концептуально разделяется на три слоя: факты (статика), правила (динамика) и примеры [00:19:42].
• Почему это важно: Подход "нанять вендора, чтобы он за три месяца построил идеальную базу знаний" полностью недееспособен [00:19:00]. База знаний должна быть живым регламентом, который постоянно эволюционирует. При этом слой примеров должен расти автоматически за счет действий сотрудников.
• Как применить на практике:
  1. Начинать внедрение с простейшей базы знаний (например, базового каталога) и сразу замыкать внешнюю петлю сбора фидбека от пользователей.
  2. Внедрить в интерфейсы сотрудников кнопку (лайк/тег) для автоматической отправки удачных реальных диалогов в слой примеров базы знаний [00:20:53].

6. Автоматическое тестирование ИИ (Evals) против отложенных метрик

• Что сказали: Для ИИ-систем необходима автоматическая система тестов (Evals), которая запускается до релиза и включает три уровня: Safety (блокировка деструктивных действий), Regression (проверка точности на эталонных диалогах) и EQ (оценка тональности и качества силами другой, более мощной LLM) [00:21:57].
• Почему это важно: Бизнес-метрики (выручка, отток) всегда отложены во времени — вы узнаете о сбое ИИ слишком поздно. Автоматические Evals позволяют ловить деградацию моделей на ранних этапах. Ошибка в ИИ-обслуживании без должных проверок может мгновенно разрушить лояльность прибыльных клиентов, как это случилось в известном кейсе Klarna [00:27:17].
• Как применить на практике:
  1. Внедрить базовый набор Safety-тестов, которые намертво блокируют выкатку промптов или моделей при критических нарушениях (например, если ИИ самовольно обещает клиенту возврат денег).
  2. Использовать подход TDD (Test-Driven Development): при обнаружении сбоя сначала фиксировать проблемный кейс в виде теста, и только потом править промпт или базу знаний [00:25:23].

Примеры и кейсы

• Медицинский кейс (Автоматизация заполнения карт приема врача): [00:29:20]
  • Было → стало: Процесс опроса пациента и фиксации данных занимал 25% времени всего приема, так как врач был вынужден вручную вбивать информацию в интерфейс 1С [00:31:39]. После внедрения ИИ-ассистента система слушает живой диалог на приеме, осуществляет транскрибацию и диаризацию речи, после чего автоматически заполняет до 80% из ~40 полей медицинской карты стандартными фразами из справочника [00:34:01]. Врач больше не сидит уткнувшись в экран, а общается с пациентом глаза в глаза, в конце приема лишь быстро валидируя предзаполненную форму [00:39:51].
  • Технические решения: Легковесный агент на Python (Pydantic), open-source модель распознавания речи от Сбера (показавшая себя на русском языке лучше Whisper), интеграция RAG по справочнику клинических рекомендаций и МКБ (14 000 диагнозов) на базе Postgres с расширением PG Vector [00:35:38].
  • Главный вывод кейса: Ключевая метрика эффективности проекта — это не мифическая "инновационность", а измеримое сокращение времени процесса (время приема) и планомерное снижение процента вмешательства человека (корневая метрика для любого AI-процесса) [00:52:16].

Ошибки и грабли

• Коробочное мышление заказчиков: Менеджеры часто воспринимают ИИ как стандартный статичный софт: «назовите стоимость лицензии, внедрите продукт и не трогайте наших пользователей и процессы» [00:01:02]. Внедрение ИИ как "подорожника" (например, простое складывание транскриптов рядом с процессом без замыкания петли обучения) ведет к полной потере эффективности [00:32:41].
• Эффект привыкания операторов ("Ok-Ok-Ok"): Через 2-3 месяца работы с ИИ-подсказчиком 3-го уровня у людей замыливается глаз. Возникает сильное желание бездумно соглашаться со всеми вариантами ИИ, не вчитываясь в текст [00:41:15]. Для защиты от этого необходимо отдельно измерять и контролировать качество проверки со стороны человека.
• Ограничения технологий: Инструмент PG Vector отлично работает в пределах до 5 миллионов записей логов [00:50:25]. Если масштаб компании предполагает миллионы действий клиентов в день, стандартные простые базы данных начнут буксовать — потребуются специализированные enterprise-технологии векторного поиска.
• Когда подход НЕ подойдет: Метод Oper8 бесполезен без активного участия человека-эксперта (Владельца процесса) [00:17:15]. Полная автономия (уровень 5) практически нигде в реальном бизнесе не нужна и экономически неоправданна.

Что можно сделать уже сегодня

• [ ] Провести ревизию: Классифицировать текущие ИИ-активности в компании (определить, где у вас точечный Deploy, а где потенциальный Reshape).
• [ ] Спроектировать артефакт: Описать структуру простейшего Decision Log для одного критичного операционного процесса (какие данные на входе, какое решение ИИ, какой отложенный бизнес-результат).
• [ ] Назначить ответственного: Выделить внутри команды роль "Владельца процесса" (Domain Expert), который будет отвечать за актуализацию правил в базе знаний на основе логов.
• [ ] Развернуть сбор примеров: Добавить в интерфейс ваших операторов или CRM простую кнопку лайка успешных ответов для автоматического наполнения базы знаний живыми примерами.
• [ ] Написать Safety-правила: Сформулировать первые 3-5 жестких ограничений (чего ИИ ни в коем случае не должен обещать или говорить клиенту) для будущих автоматических тестов (Evals).
• [ ] Проверить петлю данных: Убедиться, что логи решений в ваших текущих пилотах технически доезжают до центральной базы данных, а не оседают в изолированных папках.

Цитаты

"Продукт сам по себе не является конкурентным преимуществом. Его можно повторить. Что является конкурентным преимуществом — это сервис." [00:09:42] "Сначала тесты, потом проверка, потом запуск — тесты вперед! В разработке у нас был Test-Driven Development. Здесь то же самое." [00:45:14] "Процент вмешательства человека — это единственная метрика, которая переходит из проекта в проект. Она должна снижаться." [00:53:03]

Итоговый вывод

Основная мысль доклада заключается в том, что эпоха точечного внедрения ИИ-инструментов (Deploy) прошла: они легко копируются и не приносят долгосрочной прибыли в P&L. Для получения устойчивого конкурентного преимущества компаниям необходимо перестраивать сквозные процессы (Reshape) вокруг ИИ, создавая самообучающиеся системы с двойным контуром обратной связи. Спикеры доносят до зрителя, что главная ценность бизнеса теперь лежит не в кодовой базе продукта, а в накопленной памяти уникальных решений (Decision Log). Самый разумный первый шаг после прочтения саммари — выбрать один конкретный процесс, спроектировать для него структуру лога решений и начать собирать реальные данные для будущего маховика обучения.