С чего начать автоматизацию бизнеса: как выбрать первый процесс для AI и не слить на нём пилот

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

Около 80% компаний, начавших внедрять AI, застревают на одном-двух пилотах и не доходят до промышленного использования. Технологии тут почти ни при чем – модели давно рабочие. Разваливается все обычно задолго до внедрения, на этапе выбора процесса, который будет автоматизироваться.

Логика ^[1] ошибки ^[2] почти всегда одинаковая. Руководитель рассуждает так: «Раз уж внедрять AI, давайте бить по самому больному – по самому сложному и важному процессу, где мы теряем больше всего сил, времени, денег». Звучит разумно, а на деле это самый быстрый способ похоронить всю затею. Самый сложный процесс обычно не просто так самый сложный:) В нем множество исключений, доработко, устных договоренностей и многого другого. Пилот вязнет, сроки плывут, результат спорный, и в компании делают вывод «AI у нас не работает». Хотя не работал не AI, а неудачно выбранная первая задача.

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

Шесть признаков хорошего кандидата на автоматизацию

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

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

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

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

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

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

6. Боль ^[5] реальна, и люди ее признают. Процесс должен по-настоящему раздражать команду и сжирать ресурс – тогда у людей будет мотивация ^[6] пользоваться новым инструментом, а не саботировать его. Автоматизация задачи, которая никого не бесит, останется красивым демо, которым никто не пользуется.

Как свести это в решение

Не полагайтесь на ощущение «вот это подойдет». Выпишите 4–5 процессов-кандидатов и оцените каждый по шести критериям — хотя бы по простой шкале от 1 до 3. Получится примерно так:

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

Что почти всегда оказывается хорошим первым процессом

На практике в топ по этим критериям регулярно выходят четыре типа задач:

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

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

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

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

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

Чего не делать первым

Три анти-паттерна, которые чаще всего топят пилот:

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

• Процесс без данных. «Хотим AI, который будет делать X» – а материалов, на которых его настроить, нет. Сначала данные, потом автоматизация.

• «Модная» задача вместо болезненной. Автоматизируют то, что звучит красиво на презентации, а не то, что реально мешает работать. Итог – демо, которым никто не пользуется.

Как проверить выбор, не вкладываясь целиком

Даже аккуратно посчитанный по фреймворку выбор стоит проверить на практике, прежде чем разворачивать в масштабе. Рабочая схема — собрать прототип на одном выбранном процессе за 2–3 недели, на ваших реальных данных, и сравнить «до и после» по той метрике, которую вы заранее определили. Не демо на слайдах, а один живой сценарий, который можно потрогать.

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