Как выбрать бизнес-процесс для автоматизации с помощью ИИ

Фраза «нужно внедрить ИИ» не описывает бизнес-задачу. Она сразу направляет обсуждение к моделям и сервисам, хотя компания ещё не определила, какое решение хочет улучшить. В результате команда ищет применение купленному инструменту или автоматизирует удобный, но несущественный участок.

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

До автоматизации ответьте на четыре вопроса:

1. кто сейчас выполняет работу и для кого;

2. что поступает на вход и что должно получиться;

3. по каким правилам принимается результат;

4. какое бизнес-решение изменится после улучшения.

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

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

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

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

Перед выбором сравните варианты решения:

• убрать лишний шаг;

• изменить форму или регламент;

• добавить обязательное поле;

• связать системы обычной интеграцией;

• использовать правила и шаблоны;

• применить ИИ к части задачи;

• оставить решение человеку, улучшив доступ к информации.

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

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

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

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

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

Для каждого этапа соберите исходные показатели:

• число операций за выбранный период;

• время активной работы и ожидания;

• долю возвратов на исправление;

• типы ошибок и их последствия;

• стоимость используемых систем и труда;

• требования к сроку ответа;

• долю случаев, которые уже обрабатываются без человека.

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

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

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

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

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

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

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

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

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

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

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

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

Признаки подходящего процесса

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

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

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

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

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

Когда процесс лучше не брать первым

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подход к рискам стоит сверять с AI Risk Management Framework NIST, профилем NIST для генеративного ИИ и актуальными рекомендациями OWASP GenAI Security. Это не заменяет юридическую и отраслевую проверку конкретного проекта.

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

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

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

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

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

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

Общий подход к подготовке компании разобран в статье «Внедрение ИИ в маркетинг». Для сценариев общения с клиентами отдельно полезен материал о чат-ботах для бизнеса.