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

Q: Нужно ли начинать с самого дорогого процесса?

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

Q: Можно ли выбрать процесс без точной статистики?

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

Q: Что делать, если процесс меняется каждый месяц?

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

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

Кому актуален такой выбор

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

В каждом случае задача одна: отделить дорогую повторяемую операцию от общего недовольства процессом. Формулировка «менеджеры слишком долго работают» непригодна для пилота. Формулировка «на классификацию входящего письма, извлечение реквизитов и постановку задачи уходит в среднем N минут» уже задаёт объект измерения. Значение N нужно получить из наблюдений, а не придумать на встрече.

Признаки сильного первого процесса

У подходящего кандидата обычно есть семь признаков.

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

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

Как посчитать экономику

Начните не с стоимости модели или лицензии, а со стоимости текущего процесса. Простая месячная оценка:

Текущая стоимость = объём операций × среднее время × стоимость часа + стоимость исправлений + потери от задержки.

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

| Показатель | Модельное значение | Как получить свой показатель | |---|---:|---| | Операций в месяц | 800 | выгрузка CRM или журнал задач | | Время на операцию | 12 минут | замер выборки в течение 1–2 недель | | Полная стоимость часа | 1 200 ₽ | данные финансовой службы | | Текущая стоимость труда | 192 000 ₽ | 800 × 0,2 часа × 1 200 ₽ | | Доля операций с помощью системы | 60% | фактический результат теста | | Экономия времени на такой операции | 7 минут | сравнение до и после | | Модельный высвобожденный ресурс | 67 200 ₽ | 800 × 60% × 7/60 × 1 200 ₽ |

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

Матрица выбора

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

| Критерий | Рекомендуемый вес | Вопрос для оценки | |---|---:|---| | Экономический потенциал | 25% | сколько стоит потеря сегодня? | | Повторяемость | 15% | достаточно ли случаев для проверки? | | Готовность данных | 20% | доступны ли входы и эталонные результаты? | | Измеримость | 15% | можно ли сравнить «до» и «после»? | | Интеграционная сложность | 10% | сколько систем нужно затронуть? | | Риск ошибки | 10% | можно ли безопасно оставить подтверждение человеку? | | Готовность команды | 5% | есть ли владелец и тестовая группа? |

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

Текстовая схема выбора:

Список потерь
    ↓
5–7 повторяемых процессов
    ↓
Экономика + данные + риск + владелец
    ↓
Стоп-факторы исключены?
    ├── нет → подготовка процесса или другой кандидат
    └── да  → базовая линия → пилот → решение по KPI

Готовый сервис или разработка

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

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

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

План пилота

Пилот — это проверка гипотезы, а не уменьшенная копия всей будущей платформы.

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

Шаг 2. Собрать базовую линию. Замерить объём, время, очередь, возвраты и долю исключений. Договориться, какие события считаются началом и завершением операции.

Шаг 3. Подготовить выборку. Включить обычные случаи, сложные документы, ошибки формата и исключения. Удалить лишние персональные данные и назначить права доступа.

Шаг 4. Задать приёмку. Зафиксировать KPI, минимальный объём теста, допустимые ошибки, правила ручной проверки и способ регистрации результата.

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

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

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

Ошибки при выборе

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

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

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

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

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

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

Чек-лист решения

[ ] Процесс описан одним предложением с входом, действием и выходом.
[ ] Известен месячный объём операций.
[ ] Замерено текущее время полного цикла.
[ ] Определены стоимость труда и другие потери.
[ ] Доступна репрезентативная выборка данных.
[ ] Описаны обычные случаи и исключения.
[ ] Назначен бизнес-владелец.
[ ] Определён человек, подтверждающий результат пилота.
[ ] Выбраны два–четыре KPI и источники данных.
[ ] Зафиксированы стоп-факторы по безопасности и риску.
[ ] Понятно, где результат появится в рабочей системе.
[ ] Есть дата решения: масштабировать, изменить или остановить.

Связанные материалы

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

FAQ

Нужно ли начинать с самого дорогого процесса?

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

Можно ли выбрать процесс без точной статистики?

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

Что делать, если процесс меняется каждый месяц?

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

Достаточно ли высокой точности модели?

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

Следующий шаг

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