Что подготовить перед внедрением ИИ: пошаговая подготовка компании

Большинство неудачных проектов с искусственным интеллектом проваливаются не на этапе обучения модели, а задолго до него. Компания покупает доступ к языковой модели, поручает пилот энтузиасту из отдела маркетинга, через два месяца получает набор любопытных демонстраций и ни одного изменённого бизнес-показателя. Причина почти всегда одна и та же, и она не техническая. Ниже разобрано, что именно нужно привести в порядок до первой строки кода и до первого платежа за токены.

Когда компания готова к ИИ, а когда рано

Готовность к внедрению определяется не размером бюджета и не наличием ИТ-отдела. Она определяется тем, насколько процессы компании описаны, повторяемы и измеримы. Искусственный интеллект усиливает то, что уже работает, и обнажает то, что держится на личных договорённостях между людьми. Если согласование договора занимает от трёх часов до трёх недель в зависимости от того, кто его ведёт, автоматизация этого участка даст непредсказуемый результат.

Есть минимальный набор условий, при которых проект имеет смысл начинать.

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

Последний пункт недооценивают чаще остальных. Внедрение почти всегда меняет распределение работы между людьми, а значит затрагивает чью-то зону влияния и чьи-то премии. Технически проект может быть безупречен и при этом тихо умереть, потому что отдел, чью отчётность он автоматизировал, перестал передавать исходные данные.

Признаки преждевременного внедрения

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

• Задача сформулирована как желание внедрить искусственный интеллект, а не как проблема конкретного отдела.
• Никто не может назвать текущие значения показателей, которые планируется улучшить.
• Данные для задачи придётся собирать вручную из нескольких таблиц перед каждым запуском.
• В компании нет человека, который отвечает за результат проекта своим рабочим временем, а не на словах.
• Бюджет выделен на пилот, но не предусмотрен на поддержку и доработку после него.
• Решение выбрано раньше, чем описана задача.

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

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

Цель и выбор задачи для первого проекта

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

Хороший первый кандидат обладает набором довольно скучных свойств.

1. Объём работы большой и однообразный, то есть эффект виден сразу.
2. Цена ошибки умеренная, и ошибку можно заметить до того, как она дойдёт до клиента.
3. Результат легко проверить человеку за минуту, а не за полдня.
4. Исходные данные уже лежат в одном месте в более или менее пригодном виде.
5. Процесс не требует согласования с пятью подразделениями при каждом изменении.

На российском рынке типичные первые задачи выглядят довольно приземлённо. Обработка входящих обращений с распределением по категориям и ответственным. Подготовка черновиков товарных описаний для каталога на основе характеристик из учётной системы. Расшифровка и структурирование записей переговоров с выделением договорённостей. Извлечение сведений из счетов, актов и заявок в формате сканов. Первичная проверка комплектности документов перед отправкой на согласование. Все эти задачи объединяет то, что человек остаётся в контуре принятия решения и видит результат до его публикации.

Критерии задачи с быстрой отдачей

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

• Частота выполнения за месяц и суммарные трудозатраты в часах.
• Доля операций, которые сводятся к работе с текстом, документами или классификацией.
• Доступность данных без ручной выгрузки и без запроса к сторонним компаниям.
• Скорость проверки результата силами сотрудника, который уже делает эту работу.
• Устойчивость правил, то есть как часто меняются требования к результату.
• Готовность владельца процесса участвовать в проекте и давать обратную связь.

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

Задачи, которые не стоит отдавать ИИ на старте

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

• Окончательные решения по людям, включая подбор, оценку и увольнение.
• Юридически значимые выводы и формулировки, уходящие внешнему адресату без проверки.
• Расчёты, где требуется арифметическая точность и воспроизводимость до копейки.
• Работа с данными, которые компания не имеет права передавать во внешний сервис.
• Процессы, правила которых меняются каждую неделю под давлением рынка.
• Участки, где нет ни одного эксперта, способного отличить правильный ответ от убедительно выглядящего.

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

Аудит процессов и точек интеграции

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

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

1. Кто выполняет действие и в какой системе.
2. Что поступает на вход и откуда именно, с указанием формата.
3. Какое решение принимается и по каким правилам, включая негласные.
4. Что считается результатом и кто его принимает.

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

Как зафиксировать исходные показатели до внедрения

Без базовых замеров любой результат проекта будет предметом спора. Замеры нужно сделать заранее, минимум за две недели типичной работы, и сохранить методику, чтобы потом считать тем же способом.

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

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

Стоимость проекта определяется не моделью, а состоянием данных и количеством согласований, которые придётся пройти, чтобы до этих данных добраться.

Подготовка данных

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

Инвентаризация источников и доступов

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

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

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

Качество, полнота и разметка

Качество данных проверяется не на глаз, а по нескольким конкретным параметрам, которые стоит посчитать до начала работ.

1. Полнота заполнения ключевых полей в процентах от общего числа записей.
2. Наличие дублей и правило, по которому дубль определяется.
3. Единообразие справочников, когда одно и то же понятие названо одинаково во всех системах.
4. Актуальность, то есть доля записей, которые описывают уже не существующие условия работы.
5. Согласованность между системами по пересекающимся сведениям.
6. Наличие примеров правильного результата, пригодных для проверки работы модели.

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

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

Персональные данные и коммерческая тайна

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

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

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

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

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

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

Выбор инструмента и инфраструктуры

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

Основные ограничения, из которых складывается решение, обычно выглядят так.

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

Готовый сервис, API или своя модель

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

Вариант	Когда подходит	Что требует от компании	Основной риск
Готовый прикладной сервис с нужной функцией	Задача типовая, данные не чувствительные, нужен быстрый старт	Настройка, обучение сотрудников, подписка	Невозможность подстроить логику под свои правила
Обращение к модели через программный интерфейс	Нужна своя логика, интеграция с системами, контроль над сценарием	Разработка, сопровождение, расходы по объёму обращений	Зависимость от поставщика и изменений в его моделях
Открытая модель в своём контуре	Данные нельзя выпускать наружу, объёмы большие и стабильные	Оборудование, инженеры, постоянное сопровождение	Высокая стоимость входа и дефицит специалистов

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

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

Облако или локальное развёртывание

Выбор места обработки влияет не только на безопасность, но и на экономику проекта. Облачный вариант переносит расходы в операционные и позволяет начать без закупок, локальный требует вложений заранее и оправдывается на объёме.

Сравнивать стоит по полному набору факторов, а не только по цене лицензии.

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

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

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

Команда, роли и зоны ответственности

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

• Заказчик со стороны бизнеса, который формулирует задачу и принимает результат. У него должно быть право менять процесс.
• Владелец процесса, который знает текущую работу в деталях и отвечает за её перестройку.
• Технический исполнитель, который реализует решение и интеграции, собственный или внешний.
• Эксперт предметной области, который готовит эталонные примеры и оценивает качество ответов.
• Ответственный за данные, который обеспечивает доступы, выгрузки и качество источников.
• Специалист по безопасности и юрист, подключённые на согласовании режима обработки данных.
• Спонсор проекта на уровне руководства, который снимает блокировки между подразделениями.

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

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

Когда привлекать внешнего подрядчика

Собственная команда даёт контроль и накопление опыта, внешняя скорость и готовую практику. Разумный ориентир выглядит так.

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

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

Обучение сотрудников и работа с сопротивлением

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

Содержательный разговор с командой стоит провести до запуска и ответить в нём на конкретные вещи.

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

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

Люди не саботируют инструменты, которые делают их работу заметнее и легче. Они саботируют инструменты, которые делают их работу прозрачнее, не делая её легче.

Как построить обучение

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

1. Короткое занятие на разборе реальных случаев из их практики, а не из презентации поставщика.
2. Набор готовых формулировок запросов под типовые ситуации, который можно просто взять и использовать.
3. Явное описание границ применимости с перечнем случаев, где инструмент использовать нельзя.
4. Примеры неверных ответов с объяснением, по каким признакам ошибка распознаётся.
5. Назначенный внутренний наставник, к которому можно обратиться с вопросом без формальной заявки.
6. Повторная встреча через две или три недели работы для разбора накопленных затруднений.

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

Регламент использования ИИ

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

Что прописать в политике

Документ должен быть коротким и однозначным. Хватает нескольких страниц, которые человек прочитает один раз и запомнит.

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

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

Проверка результата и ответственность за ошибки

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

Глубина проверки при этом должна зависеть от последствий, иначе контроль съест всю полученную экономию.

Тип результата	Порядок проверки	Кто подтверждает
Внутренний черновик, конспект, заметка	Проверка автором при использовании	Сам сотрудник
Материал для клиента или внешней публикации	Полная проверка фактов и формулировок	Руководитель или редактор направления
Юридически значимый документ	Обязательная проверка профильным специалистом	Юрист
Расчёт, влияющий на деньги	Пересчёт независимым способом	Финансовое подразделение
Автоматическое действие без участия человека	Выборочный контроль и разбор отклонений	Владелец процесса

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

Бюджет, сроки и расчёт окупаемости

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

Полная смета первого года включает несколько групп расходов.

• Разовые работы по подготовке данных, настройке и интеграции с внутренними системами.
• Оплата доступа к модели или сервису по фактическому объёму обращений.
• Инфраструктура, если решение разворачивается в своём контуре или на арендованных мощностях.
• Время собственных сотрудников, включая эксперта на разметку и разбор ошибок.
• Юридическое сопровождение и работы по информационной безопасности.
• Обучение команды и подготовка материалов для пользователей.
• Сопровождение после запуска, доработки и реакция на изменение правил процесса.

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

Как считать окупаемость без самообмана

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

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

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

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

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

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

Пилот: гипотеза, метрики, критерии успеха

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

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

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

Что измеряем	Как считаем	Зачем нужно
Качество результата	Доля ответов, принятых экспертом без правок, на проверочном наборе	Показывает пригодность решения к работе
Трудозатраты на операцию	Среднее время от поступления задачи до принятого результата	Основа расчёта выгоды
Охват случаев	Доля обращений, обработанных без перехода на ручной сценарий	Отражает реальную применимость
Критические ошибки	Количество случаев с недопустимыми последствиями за период	Определяет возможность расширения
Фактическое использование	Доля сотрудников и операций, где инструмент применялся	Показывает принятие командой
Стоимость обработки	Расходы на обращения и инфраструктуру, делённые на число операций	Позволяет оценить экономику при росте объёма

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

Как организовать сам прогон

Техническая сторона пилота несложная, но порядок действий влияет на достоверность выводов.

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

Теневой режим недооценивают, хотя он даёт самую честную картину. Решение работает на реальном потоке, его ответы сравниваются с решениями людей, при этом ошибки никому не вредят. Две или три недели в таком режиме обычно выявляют все существенные расхождения между описанным процессом и фактическим.

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

Переход от пилота к масштабированию

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

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

1. Решение выдерживает ожидаемый объём, включая пиковые дни, а не только средний поток.
2. Есть мониторинг качества, который работает сам и подаёт сигнал при отклонениях.
3. Есть сопровождение с названным ответственным и понятным порядком обращения за помощью.
4. Логика и настройки описаны в документе, а не хранятся в памяти разработчика.
5. Есть процедура обновления, если поставщик изменил модель или изменились правила процесса.
6. Регламент работы включён в рабочие инструкции сотрудников, а не существует отдельно.
7. Экономика подтверждена на реальном объёме, а не рассчитана по данным небольшого пилота.

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

В каком порядке расширять

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

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

Чек-лист готовности перед запуском

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

• Задача сформулирована и измерима. Есть описание процесса по шагам, названы показатели, зафиксированы их текущие значения и указано ожидаемое изменение.
• Данные собраны, очищены, доступы выданы. Источники описаны, качество проверено по полноте и дублям, подготовлен проверочный набор с эталонными ответами, режим обработки персональных данных согласован.
• Выбран инструмент и формат развёртывания. Решение соответствует юридическим ограничениям, рассчитана стоимость на ожидаемом объёме, спроектирован резервный сценарий при недоступности.
• Назначены владелец проекта и исполнители. Есть заказчик с правом менять процесс, эксперт с выделенным временем, технический исполнитель и человек, принимающий результат.
• Утверждены регламент и правила контроля. Описаны разрешённые инструменты, запрещённые к передаче категории сведений, глубина проверки по типам результата и канал для сообщений об ошибках.
• Зафиксированы бюджет, сроки и метрики пилота. Разделены расходы на запуск и эксплуатацию, определены критерии успеха и критерии остановки, назначена дата принятия решения.

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

Ошибки подготовки, которые срывают внедрение

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

• Выбор технологии до постановки задачи, когда инструмент ищет применение вместо решения существующей проблемы.
• Отсутствие исходных замеров, из-за чего результат невозможно подтвердить и приходится спорить о впечатлениях.
• Расчёт выгоды без учёта времени на проверку ответов человеком.
• Проект без владельца со стороны бизнеса, который держится на энтузиазме технического специалиста.
• Эксперт, привлечённый без выделения рабочего времени, из-за чего обратная связь приходит с задержкой в недели.
• Подключение юриста и специалиста по безопасности на финальном согласовании, когда решение уже построено.
• Проверочный набор из удобных типовых примеров без сложных и спорных случаев.
• Смета без расходов на сопровождение после запуска.
• Отсутствие резервного сценария на случай сбоя или недоступности сервиса.
• Молчание о том, что произойдёт с нормами, оплатой и обязанностями сотрудников после внедрения.
• Попытка автоматизировать процесс, который не описан и выполняется по-разному разными людьми.
• Расширение на всю компанию сразу после первых удачных демонстраций, без проверки на реальном объёме.

Как проверить себя за полчаса

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

1. Какой показатель изменится, каково его значение сейчас и каким оно должно стать.
2. Кто из сотрудников потеряет часть привычной работы и что получит взамен.
3. Где лежат данные и сколько времени займёт получение доступа к ним.
4. Кто скажет, что ответ неверный, и сколько времени у него на это выделено.
5. При каких результатах через два месяца вы закроете проект.

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

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

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