Какая задача подходит для первого пилота?
Начните со списка повторяющихся задач и для каждой запишите, с чего она начинается, какие данные поступают на вход, что должно получиться в итоге и кто за неё отвечает. Такой простой перечень быстро показывает, какие задачи хорошо описаны, а какие держатся на личном опыте сотрудников, который никто никогда не записывал. С такого же перечня начинается автоматизация малого бизнеса, где один человек часто совмещает несколько ролей.
Для первого пилота лучше подходит задача, по которой легко собрать примеры и где команда может чётко сказать, как выглядит правильно сделанная работа. Обратите внимание, как часто встречаются исключения: задачу, в которой большинство случаев похожи друг на друга, проверить проще, чем ту, где каждый случай особенный. И уточните, можно ли проверить результат до того, как он дойдёт до клиента или изменит данные в рабочей системе. Если ошибку можно поймать на этом этапе, пилот пройдёт безопасно, пока команда набирается опыта. Так мы выбираем первую задачу в проектах ИИ-автоматизации процессов.
Ограниченная задача заодно помогает трезво оценить демонстрации поставщиков, и с неё же удобно начинать консультации по ИИ. Программа, которая эффектно выглядит на общих примерах, мало что говорит о вашем случае. Та же программа, выполнившая ограниченный кусок вашей работы — с вашими документами, вашими форматами и вашими трудными случаями, — показывает, стоит ли двигаться дальше. Попросите поставщика показать работу на ваших примерах ещё до того, как что-либо подписывать: это быстро отсеивает неподходящие решения. С каких задач обычно начинают внедрение ИИ в бизнес, мы собрали на отдельной странице.
Как сравнить процесс до и после?
Измеряйте процесс целиком: подготовку, обработку, проверку, исправления и передачу результата. Автоматизация часто сокращает один ручной шаг, но добавляет проверку или исправления в другом месте, и если замерять только автоматизированный шаг, результат будет выглядеть лучше, чем на самом деле. Поэтому замер должен начинаться с момента, когда задача поступила, и заканчиваться тогда, когда результат принят и передан дальше.
Поэтому держите отдельно две цифры: насколько сократился отдельный ручной шаг и сколько усилий в сумме требует весь процесс. Для решения важна именно вторая. Добавьте к ней расходы, которые приносит пилот, — программы, работу по интеграции и дальнейшую поддержку, — чтобы сравнение показывало то, что бизнес действительно возьмёт на себя.
По своим замерам постройте расчётный сценарий, а после запуска пилота сравнивайте с ним фактические результаты, используя те же определения. Если определения между расчётом и замером изменятся, сравнение потеряет смысл. И, как в любом расчёте по автоматизации, отделяйте освобождённое рабочее время от денежной экономии: освободившиеся часы ценны, но деньгами они становятся только тогда, когда кто-то решает, на что пойдёт это время или какие расходы сократятся.
На чём основывать решение по пилоту?
До начала пилота подберите тестовые примеры, в которых есть и обычная работа, и те трудные случаи, о которых команда уже знает: нестандартные форматы, неполные данные, запросы, которые всегда вызывают вопросы. Пилот, проверенный только на аккуратных примерах, разочарует сразу, как только столкнётся с повседневной работой. Попросите сотрудников, которые делают эту работу каждый день, подсказать такие примеры: они знают их лучше всех.
Заранее решите, какие ошибки настолько серьёзны, что блокируют запуск, кто проверяет результаты, в которых система не уверена, и как исправляется неудачный запуск. Назначьте человека, отвечающего за повседневную работу процесса, до того как пилот будет расширен; иначе после ухода проектной команды процесс постепенно начинает работать как придётся. У этого человека должно быть время на процесс и право остановить его, если что-то пошло не так.
Итоговый разбор должен ответить на три вопроса: что нужно доработать, стоит ли двигаться дальше и какие зависимости ещё не закрыты — например, доступы к системам, подготовка данных или обучение сотрудников. Помните и о границах собранных доказательств. Успешная проверка на небольшом наборе примеров обнадёживает, но говорит только об этих примерах и ничего не гарантирует для всех будущих случаев, поэтому запланируйте наблюдение за процессом в первое время после расширения.
Чек-лист: как выбрать пилот
- Опишите, с чего начинается задача, какие данные поступают на вход, какой нужен результат и кто за неё отвечает.
- Измеряйте проверку и исправления как полноценную часть процесса.
- Проверяйте пилот на типичных примерах и на трудных случаях, которые команда уже знает.
- Заранее определите критерии приёмки, порядок восстановления после сбоя и того, кто ведёт процесс каждый день.
Пример: данные из писем поставщиков
ИИ читает письма поставщиков и заполняет нужные поля, сотрудник их проверяет, а утверждённые записи попадают в промежуточную очередь, а не сразу в основную систему. В ходе теста команда сравнивает полное время обработки и точность каждого поля с прежним ручным процессом. По той же схеме работает ИИ-обработка документов со счетами и другими вложениями.
Прямое обновление данных без участия человека рассматривают только позже — когда у команды есть результаты реальных запусков и она определилась с системой контроля: какие проверки выполняются автоматически, какие случаи по-прежнему уходят к сотруднику и как исправляются ошибки. Такой порядок позволяет набраться опыта, не рискуя данными в основной системе. Только после этого имеет смысл переходить к разработке ИИ-агентов, которые действуют сами в заданных границах.
Читать дальше
- Карта процесса до автоматизации: шаблон на одну страницу
- ROI автоматизации: как посчитать время, качество и расходы
- Калькулятор потенциала автоматизации
