Как провести диагностику бизнес-процессов перед внедрением ИИ

2026-07-16 · Слаживание

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

Если коротко, перед внедрением ИИ я делаю 4 шага:

• фиксирую границы процесса: что его запускает, кто отвечает, какой нужен результат;
• рисую карту “как есть”: шаги, системы, передачи, обходные пути;
• снимаю базовые цифры: цикл, чел.-ч, возвраты, ожидание, потери в деньгах;
• проверяю данные и интеграции: CRM, 1С, почта, телефония, СЭД, доступы, ФЗ-152;
• отбираю один пилот: только типовой, частый и цифровой процесс.

Вот главная мысль статьи в одном списке:

• ИИ даёт эффект не “в компании вообще”, а в _одной задаче внутри одного процесса_.
• Если сначала не убрать лишние шаги, ИИ может не сократить срок, а растянуть его.
• Для пилота лучше брать процесс с понятным входом, понятным выходом и повторяемыми действиями.
• Считать надо не только активную работу, но и время ожидания. Часто именно там сидит _основная потеря_.
• Если данные грязные, в PDF-сканах без OCR, с дублями или без доступа, пилот лучше отложить.
• Если процесс редкий, бумажный или весь состоит из исключений, он не подходит для первого запуска.

Ниже я свёл материал к простой логике: _сначала диагностика, потом пилот, потом замер эффекта, и только после этого - масштабирование_.

С чего начать внедрение ИИ в бизнес: шаги, мифы и кейсы

Шаг 1: Определите границы процесса и составьте карту «как есть»

Сначала разберите один сквозной процесс - от триггера до результата.

Зафиксируйте границы, владельца, триггер и результат

Для ИИ лучше брать процессы, где есть большой объём, типовые сценарии и понятный итог [3][6].

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

Когда границы зафиксированы, можно переходить к карте фактического маршрута.

Составьте карту процесса «как есть» с системами и передачами

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

Зафиксируйте каждый шаг:

• кто его выполняет;
• в какой системе он работает - CRM, 1С, почта, телефония, файловое хранилище;
• что именно он передаёт следующему участнику.

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

Карта должна показывать не только формальный маршрут, но и обходные шаги, если они есть. Если сотрудник в жизни идёт не по регламенту, это тоже надо записать. Иначе автоматизация может не ускорить процесс, а, наоборот, притормозить его: то, что раньше решалось за 2–3 дня, начнёт тянуться 2 недели из-за жёсткой привязки к формальному маршруту [3].

Снимите базовые метрики до любых изменений

Базовые метрики нужны для простой вещи: сравнить процесс до и после и показать эффект цифрами.

Зафиксируйте как минимум:

• длительность цикла;
• трудозатраты;
• объём;
• долю возвратов;
• частоту исключений;
• стоимость задержки [3].

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

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

Шаг 2: Найдите узкие места, ручные операции и потери времени

Определите повторяющиеся операции, двойной ввод данных и циклы согласований

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

Обычно проблемные места видны довольно быстро. Вот типичные сигналы:

• копирование данных из CRM в 1С или Excel, двойной ввод, ручное заполнение однотипных документов и писем;
• поиск нужного файла или прошлой версии документа;
• ручное назначение задач между отделами;
• циклы согласований: если ошибка находится слишком поздно, процесс возвращается к инициатору и согласование начинается заново [4].

Именно такие объёмные, типовые и дорогие по времени операции чаще всего и становятся главными кандидатами для ИИ. Отдельно помечайте рутинные отчёты, которые забирают время у сильного специалиста и уводят его от основной работы [5].

Измерьте стоимость потерь в часах, задержках и деньгах

Считайте просто: объём задач × среднее время на одну задачу = трудозатраты. Но на этом не останавливайтесь. К этой цифре нужно добавить ещё и _время ожидания_ - сколько документ или задача просто лежит в очереди без движения.

Вот почему это важно. В одном процессе согласования договоров после перевода в жёсткий цифровой маршрут без учёта отсутствий срок вырос с 2–3 дней до 2 недель. После оптимизации - до 5–6 рабочих дней [3].

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

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

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

Шаг 3: Проверьте готовность данных, интеграций и соответствие процесса ИИ

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

Оцените качество входных данных

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

Удобнее всего зафиксировать это в таблице - по одной строке на каждый ключевой тип данных внутри процесса:

Смысл простой: данные должны быть достаточно надёжными, чтобы на их основе можно было принимать решения. Иначе ИИ будет ошибаться не потому, что модель «плохая», а потому что на вход ей подали сырой материал.

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

Проверьте интеграционные пути

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

• есть ли API или прямой доступ к базе данных
• совместима ли версия системы
• поддерживается ли электронная подпись в СЭД
• можно ли безопасно настроить чтение и запись внутри контура компании
• получится ли перенести исторические записи без потери данных [1][2][4]

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

Определите уровень применения ИИ

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

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

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

Шаг 4: Расставьте приоритеты и выберите первый пилот

Если процессы уже прошли проверку по данным и интеграциям, их пора сравнить между собой по эффекту и сложности. Смотрите только на жизнеспособные варианты: те, у которых уже есть карта «как есть», базовые метрики и пройдена проверка данных [8][7].

Ранжируйте процессы по матрице «эффект - сложность»

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

Для пилота обычно берут верхние строки таблицы. Нижние лучше отложить на потом.

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

Выберите пилот: один процесс, один владелец, чёткий базис

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

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

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

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

Заключение: что компания должна знать до старта

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

Порядок действий такой: диагностика → пилот → замер эффекта → масштабирование.

Пилот выбирают только после диагностики процесса, данных, интеграций и владельца.

FAQs