Александр Бочкин

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

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

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

Данные о процессе — фундамент автоматизации

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

Проблемы возникают уже при постановке задачи. Трудности начинаются еще до внедрения ИИ. В опросе Strategy Partners 55% представителей ИТ-компаний назвали такую проблему: клиентам сложно объяснить, как устроена работа, которую они хотят передать ИИ-агенту, и определить, что именно он должен делать. Это дополнительный аргумент, чтобы начинать автоматизацию с исследования фактической работы.

Аналитика бизнес-процессов (Process Mining) позволяет сделать это по событиям в информационных системах, а аналитика бизнес-операций (Task Mining) помогает подробнее изучить действия сотрудников, в том числе при переходе между приложениями.

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

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

От найденной проблемы — к исполняемой логике

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

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

ИИ помогает создать код, обращения к API и механизмы обработки данных на основе этих требований. Однако скорость не отменяет проверки: по данным опроса Stack Overflow, 66% респондентов сталкивались с «почти правильными» решениями ИИ. Поэтому сгенерированный код нужно проверять: соответствует ли он бизнес-правилам и корректно ли обрабатывает исключения.

Роль ИИ зависит от задачи

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

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

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

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

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

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

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

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

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

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

Результат возвращается в аналитику

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

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

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

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

Источник: