AI Native
Раздел исследования

Как выбирать и запускать ИИ-инициативы

Как связать инициативу со стратегической целью, зрелостью процесса и измеримым эффектом.

Заголовок источника

Как выбирать и запускать ИИ-инициативы

О статусе материала

Подготовлено к рассмотрению.

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

Автоматизировать отчётность. Создать агента продаж. Обработать клиентские обращения.

Собрать базу знаний. Проверять документы. Прогнозировать спрос. Готовить контент.

Анализировать рынок. Контролировать сотрудников.

Большинство идей выглядят полезными. Но одновременный запуск превращает внедрение ИИ в набор слабо связанных экспериментов.

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

Поэтому управление ИИ начинается не с генерации максимального количества сценариев, а с выбора правильного места приложения усилий.

Предлагаемая логика такова: стратегическая цель → дерево метрик → ограничение → процесс → функция → тип задачи → зрелость процесса → механизм → контроль → эффект.

Каждый следующий шаг сужает пространство решения. Только после прохождения всей цепочки появляется основание проектировать конкретный ИИ-контур.

8.1. Начинать со стратегии, а не с технологии

Первый вопрос:

Какой результат компании должен измениться?

Это может быть:

  • рост прибыли;
  • увеличение пропускной способности;
  • сокращение оборотного капитала;
  • снижение дефектов;
  • ускорение вывода продукта;
  • повышение конверсии;
  • сокращение оттока;
  • снижение риска;
  • уменьшение зависимости от дефицитной экспертизы.

Если инициатива не связана ни с одним значимым результатом, её ценность необходимо поставить под сомнение.

Это не означает, что каждый эксперимент обязан сразу давать прямой финансовый эффект.

Исследовательские проекты могут создавать знания, инфраструктуру или новые способности.

Но и в этом случае нужно понимать, какую неопределённость они уменьшают и какое последующее решение делают возможным.

Формулировки вроде «повысить уровень использования ИИ» или «не отстать от рынка» недостаточны. Они описывают намерение, но не результат.

8.2. От стратегической цели к дереву метрик

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

Нельзя обоснованно утверждать, что автоматическая подготовка отчёта увеличит прибыль, если между этими объектами не построена причинная связь.

Поэтому цель необходимо декомпозировать.

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

Или: прибыль → операционные затраты → стоимость обработки рекламации → количество ручных операций → время классификации обращения.

Дерево метрик позволяет определить, на какой показатель непосредственно влияет ИИ-контур.

При этом важно различать:

  • итоговый результат;
  • промежуточную метрику;
  • показатель процесса;
  • технический показатель системы.

Например:

  • прибыль — итоговый результат;
  • конверсия сделки — промежуточная метрика;
  • время подготовки предложения — показатель процесса;
  • доля успешно обработанных транскриптов — технический показатель.

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

8.3. Найти ограничение

ИИ следует применять не там, где он вообще способен что-то делать, а там, где изменение работы повлияет на ограничение системы.

Ограничением может быть:

  • дефицит экспертного времени;
  • низкая пропускная способность;
  • несогласованность функций;
  • длительное принятие решения;
  • недостаток данных;
  • высокое количество переделок;
  • нестабильное качество;
  • потеря знаний;
  • слабая скорость обучения;
  • невозможность обслуживать растущий объём.

Если отдел не служит ограничением, его локальная автоматизация может не дать заметного результата компании.

Более того, ускорение одного участка способно ухудшить систему.

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

Поэтому перед запуском необходимо ответить:

  • что сейчас ограничивает результат;
  • как проявляется потеря;
  • что произойдёт, если функция станет работать быстрее;
  • не переместится ли ограничение;
  • сможет ли следующий участок принять дополнительный поток.

8.4. Выбрать процесс и функцию

Даже правильно найденное ограничение обычно слишком широко для одного ИИ-проекта.

Например, ограничение «низкая скорость вывода новых продуктов» может включать:

  • сбор рыночных сигналов;
  • оценку привлекательности идеи;
  • разработку концепции;
  • финансовую модель;
  • техническое проектирование;
  • тестирование;
  • согласования;
  • подготовку производства;
  • коммерческий запуск.

Необходимо найти конкретную функцию, в которой возникает потеря.

Хорошая единица внедрения имеет:

  • заданный вход;
  • повторяемое действие;
  • наблюдаемый выход;
  • владельца;
  • известную частоту;
  • измеримую стоимость или длительность;
  • возможность проверить качество;
  • ограниченную область риска.

Например:

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

Такая постановка позволяет выбрать архитектуру и измерить результат.

8.5. Определить природу задачи

Следующий шаг — классификация, рассмотренная в разделе 3.

Необходимо понять:

  • известен ли алгоритм;
  • существует ли единственный ответ;
  • требуется ли экспертное суждение;
  • меняется ли среда в ответ на действие;
  • можно ли безопасно экспериментировать;
  • кризисная ли ситуация.

От этого зависит механизм.

Воспроизводимая операция

Подходят:

  • навык;
  • агент;
  • автоматическая проверка;
  • рабочий процесс;
  • микросервис.

Экспертный анализ

Подходят:

  • расчётная модель;
  • несколько сценариев;
  • scaffold;
  • человеческий шлюз;
  • фиксация допущений.

Сложная ситуация

Подходят:

  • исследовательский контур;
  • сбор слабых сигналов;
  • портфель экспериментов;
  • наблюдение за паттернами;
  • человеческое осмысление.

Классификация должна проводиться на уровне функции. В одном процессе могут сочетаться все три режима.

Один шаг зрелости

Один шаг зрелостиОдин шаг зрелости: 01 Хаотический; 02 Замысленный; 03 Описанный; 04 Исполнимый; 05 Измеримый; 06 Оптимизируемый.
Шесть состояний конкретного процесса. Это не шкала отношения людей к ИИ, не шкала автономности и не семь уровней машиночитаемости. Природа задачи и зрелость процесса — разные признаки.
Текстовое описание схемы
  1. 01 Хаотический
  2. 02 Замысленный
  3. 03 Описанный
  4. 04 Исполнимый
  5. 05 Измеримый
  6. 06 Оптимизируемый

8.6. Оценить зрелость процесса

Природа задачи и зрелость процесса — разные параметры.

Задача может быть в принципе алгоритмизируемой, но компания ещё не выработала устойчивый способ её выполнения. И наоборот, процесс может быть хорошо описан, но содержать решения, которые нельзя свести к одному алгоритму.

Для оценки готовности к ИИ полезна лестница зрелости.

Уровень 1. Хаотический

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

Задача ИИ на этом уровне — помочь собрать фактическую практику:

  • восстановить реальные действия;
  • найти повторяющиеся элементы;
  • зафиксировать различия;
  • обнаружить разрывы;
  • подготовить материал для проектирования метода.

Полная автоматизация преждевременна.

Уровень 2. Замысленный

Компания понимает, как процесс должен работать, но целевая логика ещё не подтверждена практикой.

Существуют:

  • концепция;
  • роли;
  • предполагаемые этапы;
  • ожидаемый результат.

ИИ может помочь смоделировать процесс, проверить непротиворечивость и подготовить пилот.

Уровень 3. Описанный

Процесс зафиксирован в документах, но его исполнение остаётся нестабильным.

На этом уровне полезны:

  • scaffolds;
  • подсказки;
  • контроль обязательных этапов;
  • проверка артефактов;
  • регистрация отклонений.

Задача — сделать процесс исполнимым на практике.

Уровень 4. Исполнимый

Процесс устойчиво воспроизводится людьми. Известны входы, выходы, роли, правила и основные исключения.

Теперь отдельные функции можно передавать навыкам, агентам и микросервисам.

Уровень 5. Измеримый

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

  • времени;
  • качества;
  • стоимости;
  • пропускной способности;
  • количества ошибок;
  • результата процесса.

На этом уровне можно доказательно сравнивать ручной и ИИ-контур.

Уровень 6. Оптимизируемый

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

ИИ используется не только для исполнения, но и для постоянного совершенствования.

8.7. Принцип одного шага зрелости

Не следует пытаться одним проектом перевести хаотическую деятельность в полностью автономный режим.

Более надёжная цель — поднять процесс на один уровень.

  • Хаотический → восстановить и формализовать фактическую практику.

  • Замысленный → проверить модель на пилоте.

  • Описанный → обеспечить соблюдение.

  • Исполнимый → автоматизировать устойчивые функции.

  • Измеримый → оптимизировать.

  • Оптимизируемый → создать контур постоянного обучения.

Такой подход уменьшает риск и создаёт понятный результат каждого этапа.

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

8.8. Проверить пригодность функции

Перед запуском полезно оценить функцию по нескольким критериям.

Стратегическая значимость

Влияет ли функция на цель или ограничение?

Частота

Насколько регулярно она выполняется?

Объём

Сколько объектов проходит через неё?

Стандартизируемость

Существует ли воспроизводимый метод?

Качество входов

Доступны ли необходимые данные?

Проверяемость выхода

Можно ли установить, что результат корректен?

Цена ошибки

Каковы возможные последствия?

Обратимость

Можно ли отменить действие?

Дефицитность

Использует ли функция ограниченный человеческий ресурс?

Переносимость

Можно ли применить решение в других процессах?

Принятие

Будут ли реальные пользователи применять новый способ?

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

8.9. Выбрать наименьший достаточный механизм

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

Возможная последовательность:

  1. Подсказка или шаблон.
  2. Scaffold.
  3. Проверка.
  4. Навык.
  5. Агент с ограниченными действиями.
  6. Связка агентов.
  7. Микросервис.
  8. Интеграция с основной системой.
  9. Автоматическое исполнение с контролем исключений.

Часто полезный результат достигается на ранних уровнях.

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

Архитектурная зрелость — не в количестве технологий, а в соответствии механизма задаче.

8.10. Зафиксировать исходное состояние

Без исходных данных невозможно доказать эффект.

До запуска необходимо измерить:

  • время выполнения;
  • стоимость;
  • количество участников;
  • количество итераций;
  • долю ошибок;
  • время ожидания;
  • пропускную способность;
  • качество результата;
  • удовлетворённость пользователя;
  • экономический результат процесса.

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

При этом нельзя заменять процессную метрику субъективным ощущением «стало быстрее». И нельзя автоматически превращать сэкономленные часы в деньги.

Если сотрудник выполнил работу на два часа быстрее, экономический эффект возникает только тогда, когда освободившееся время было направлено на полезную деятельность или позволило избежать дополнительных затрат.

Четыре уровня эффекта

Четыре уровня эффектаЧетыре уровня эффекта: 01 Технический результат; 02 Процессный эффект; 03 Принятие; 04 Экономическая конверсия.
Четыре уровня эффекта. Знак ≠ означает, что переход к следующему уровню не происходит автоматически. Экономический эффект сам по себе не равен прибыли.
Текстовое описание схемы
  1. 01 Технический результат
  2. 02 Процессный эффект
  3. 03 Принятие
  4. 04 Экономическая конверсия

8.11. Четыре уровня эффекта

Для оценки ИИ-инициатив необходимо различать четыре уровня.

1. Технический результат

Система выполнила требуемую операцию.

Примеры:

  • обработала документ;
  • извлекла поля;
  • построила расчёт;
  • подготовила черновик;
  • обнаружила отклонение.

Это подтверждает техническую работоспособность, но не бизнес-ценность.

2. Процессный эффект

Изменились характеристики работы:

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

3. Принятие

Люди действительно используют решение.

Необходимо оценивать:

  • долю целевых случаев;
  • повторное использование;
  • отказ от старого способа;
  • количество обходов;
  • потребность в поддержке;
  • доверие к результату.

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

4. Экономический эффект

Процессное улучшение повлияло на финансовый или стратегический результат:

  • выросла выручка;
  • сократились затраты;
  • снизился оборотный капитал;
  • уменьшился риск;
  • удалось избежать найма;
  • вырос объём работы без расширения команды;
  • сократились потери;
  • ускорился выход продукта.

Между уровнями нет автоматического перехода.

Технический результат ≠ процессный эффект ≠ принятие ≠ экономический эффект.

Эта формула необходима для честной оценки.

8.12. Проектирование пилота

Хороший пилот должен проверять конкретную гипотезу.

Например:

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

В гипотезе определены:

  • функция;
  • механизм;
  • исходное состояние;
  • целевой результат;
  • ограничение качества.

Пилот должен включать:

  1. Базовую выборку.
  2. Ограниченную группу пользователей.
  3. Набор типовых и сложных случаев.
  4. Параллельную проверку человеком.
  5. Регистрацию всех вмешательств.
  6. Заранее определённые критерии успеха.
  7. Условия остановки.
  8. Решение о следующем этапе.

8.13. Критерии перехода к промышленной эксплуатации

Пилот не должен масштабироваться только потому, что система несколько раз показала впечатляющий результат.

Необходимо проверить:

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

До промышленной эксплуатации должны быть определены:

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

8.14. Управление портфелем ИИ-инициатив

Отдельные проекты должны рассматриваться как портфель.

Полезно разделить инициативы на несколько групп.

Быстрые улучшения

Узкие, проверяемые функции с низким риском.

Их задача — создать опыт и первые доказательства эффекта.

Инфраструктурные инициативы

  • машиночитаемость;
  • правила;
  • подключение данных;
  • реестр навыков;
  • контроль доступа;
  • журналирование.

Они не всегда дают немедленный экономический эффект, но создают основу для последующих решений.

Стратегические контуры

Проекты, влияющие на ключевое ограничение, конкурентное преимущество или масштабирование организации.

Они требуют участия руководителей и более строгой оценки.

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

Исследовательские инициативы

Эксперименты в областях высокой неопределённости.

Их результатом может быть не внедрение, а снижение неопределённости и отказ от слабой гипотезы.

Портфель необходимо регулярно пересматривать:

  • какие инициативы дают эффект;
  • какие не перешли из пилота;
  • где дублируется работа;
  • какие компоненты можно использовать повторно;
  • какие проекты следует остановить;
  • какое новое ограничение возникло после улучшения.

8.15. Принятие и изменение способа работы

ИИ-проект меняет не только технологию, но и распределение труда.

Сотрудники могут воспринимать систему как:

  • угрозу занятости;
  • внешний контроль;
  • обесценивание экспертизы;
  • дополнительную обязанность;
  • непрозрачного конкурента;
  • источник риска.

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

Поэтому внедрение должно включать:

  • объяснение проблемы;
  • участие носителей метода;
  • совместное тестирование;
  • прозрачные границы автономности;
  • понятный порядок исправления;
  • обучение;
  • фиксацию вклада сотрудников;
  • пересмотр ролей и показателей.

Особенно важно не наказывать людей за дефекты пилотной системы. Иначе они перестанут сообщать об ошибках и контур потеряет возможность обучаться.

8.16. Когда проект следует остановить

Остановка — нормальный результат управляемого эксперимента.

Основаниями могут быть:

  • задача неправильно классифицирована;
  • процесс недостаточно зрел;
  • данные непригодны;
  • цена контроля превышает эффект;
  • пользователи не принимают решение;
  • рынок предлагает более сильный готовый продукт;
  • функция не влияет на ограничение;
  • риск невозможно удержать;
  • качество нестабильно;
  • экономический эффект отсутствует.

Продолжение слабого проекта только потому, что в него уже вложены ресурсы, увеличивает стоимость ошибки.

Вывод

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

При этом необходимо провести две независимые проверки.

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

Вторая определяет зрелость процесса: существует ли устойчивый метод, исполняется ли он и можно ли измерить результат.

Хороший первый проект:

  • связан со значимым ограничением;
  • ограничен одной функцией;
  • использует доступные данные;
  • имеет владельца;
  • допускает проверку;
  • сохраняет человеческую ответственность;
  • создаёт измеримый процессный эффект;
  • способен стать основанием для следующей способности.

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