Аудит бизнес-процесса перед внедрением ИИ: что проверить

Сотрудник говорит: «Эту работу можно автоматизировать». Руководитель открывает список сервисов. Подрядчик предлагает ИИ-агента. Все уже обсуждают технологию, хотя никто ещё не восстановил сам процесс.

Где он начинается? Чем заканчивается? Какие данные нужны? Что происходит в нестандартном случае? Сколько времени занимает нормальный результат, а не первый черновик?

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

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

Коротко: что должно появиться после аудита

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

Чем аудит отличается от чек-листа готовности

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

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

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

Сначала ограничьте один процесс

«Внедрить ИИ в продажи» - не процесс. «Автоматизировать маркетинг» - тоже. Это названия областей, внутри которых десятки разных работ.

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

Пять вопросов о границе

1. Какое событие запускает процесс?
2. Что считается принятым результатом?
3. Кто владелец результата, а кто только участвует?
4. Какие соседние процессы не входят в аудит?
5. На какой единице считаем объём: заявка, документ, диалог, заказ или задача?

Без этой рамки аудит расползается по всей компании. Смета тоже расползается. В итоге никто не понимает, что именно должен улучшить ИИ.

Шаг 1. Зафиксируйте бизнес-результат и базовую линию

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

Плохая цель: «ускорить работу отдела». Хорошая цель: «сократить полный цикл обработки одного обращения при сохранении согласованного качества и безопасной передаче сложных случаев человеку».

Что измерить до разработки

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

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

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

Шаг 2. Нарисуйте фактическую карту AS-IS

AS-IS - это процесс «как есть». Не регламент из папки. Не идеальная схема руководителя. Не версия самого опытного сотрудника. Нужен маршрут, по которому действительно проходит работа.

Как собирать карту

Возьмите несколько реальных единиц работы и восстановите их путь. Для каждой отметьте:

1. вход и источник;
2. действие человека или системы;
3. принятое решение;
4. использованный документ или данные;
5. передачу следующему участнику;
6. ожидание и возврат;
7. результат или причина остановки.

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

Что искать на карте

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

Это не означает, что всё нужно отдать ИИ. Иногда лучший результат аудита - убрать лишний шаг или настроить обычное правило.

Проверьте карту с теми, кто делает работу

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

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

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

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

Не путайте частоту с важностью

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

Это помогает не перегружать первую версию. Частую безопасную работу можно автоматизировать раньше. Редкую дорогую ветку - оставить человеку, добавить предупреждение и собрать наблюдения.

Шаг 3. Соберите входы, выходы и источники данных

Фраза «агент возьмёт данные из CRM» ничего не говорит о готовности. В CRM могут быть пустые поля, дубли, старые статусы и свободный текст, который сотрудники заполняют по-разному.

Реестр данных процесса

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

Шаг 4. Разберите исключения и ручные решения

Прямой маршрут обычно помещается на одной схеме. Цена проекта прячется в исключениях.

Спросите сотрудников не только «что вы делаете», но и:

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

Карточка исключения

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

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

Шаг 5. Проверьте системы, интеграции и права

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

Карта технического контура

Для каждой системы нужны ответы:

1. Какие данные читаем?
2. Какие действия выполняем?
3. Можно ли ограничить права?
4. Есть ли тестовая среда?
5. Как обнаружить повторное действие?
6. Как отменить или исправить результат?
7. Где сохраняется журнал?
8. Кто отвечает при сбое?

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

Шаг 6. Решите, нужен ли вообще ИИ-агент

После карты процесса технологический выбор становится проще. Иногда агент избыточен.

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

Шаг 7. Сравните кандидатов по одной матрице

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

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

Влияние на бизнес

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

Техническая реализуемость

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

Готовность пользователей

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

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

Шаг 8. Подготовьте тестовый набор и критерии приёмки

До разработки соберите реальные примеры. Не только простые.

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

Для каждого примера запишите ожидаемый исход:

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

Этот набор позже становится основой пилота и приёмки. Сам маршрут внедрения разобран в статье как внедрить ИИ в бизнес от аудита до запуска.

Три решения по итогам аудита

1. Пилотировать

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

2. Сначала исправить процесс

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

3. Остановить гипотезу

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

NIST рекомендует после описания контекста, целей, ограничений, человеческого контроля и рисков принимать начальное решение go/no-go. Смысл аудита именно в этом: не доказать необходимость ИИ, а подготовить решение на фактах.

Что входит в паспорт пилота

После этого можно готовить ТЗ на ИИ-агента. До аудита ТЗ часто описывает желаемые функции. После аудита оно описывает конкретный процесс и проверяемый результат.

Признаки слабого аудита

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

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

Кому аудит пока не поможет

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

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

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

Частые вопросы

Сколько длится аудит бизнес-процесса перед внедрением ИИ?

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

Нужно ли описывать процесс в BPMN?

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

Можно ли провести аудит самостоятельно?

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

Что подготовить к первой диагностике?

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

Аудит гарантирует окупаемость внедрения?

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

Чем аудит заканчивается для подрядчика?

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

Вывод

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

Когда процесс описан фактами, разговор меняется. Вместо «какую модель поставить» команда обсуждает, что именно улучшить, как проверить результат и где оставить решение человеку.