7 ошибок внедрения RPA, из-за которых робот встаёт

Роботы останавливаются не потому, что кто-то плохо написал сценарий. В шести случаях из семи причина организационная: процесс не был описан, у робота не оказалось владельца, он работал под учётной записью сотрудника, который уволился, или никто не спроектировал, куда девать те 15 % документов, которые роботу не по силам.

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

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

Роботов останавливает организация, а не техника

Технические поломки у RPA тоже есть, и их доля известна: 38 % остановок дают обновления автоматизируемой системы, 22 % — данные, которых не было в тестовой выборке. Эта часть разобрана в материале про хрупкость роботов и стоимость поддержки. Но поломка — это то, что чинится за часы. Ошибки из таблицы ниже чинятся месяцами или не чинятся вовсе, потому что требуют менять не сценарий, а работу компании.

Ошибка 1. Роботизировать процесс как есть

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

Порядок правильный и скучный: сначала процесс описывают на одну страницу, потом убирают из него всё, что делается «на всякий случай», и только потом отдают в разработку. На практике описание съедает 20 часов, то есть 60 000 ₽ по рыночной ставке инженера — и обычно возвращает эти деньги сразу, потому что после упрощения сценарий становится короче на треть.

Ошибки 2 и 3: чужой логин и никем не замеченный простой

Робот, работающий под учётной записью живого сотрудника, ломается по расписанию: политика безопасности требует сменить пароль раз в 90 дней, и в этот день робот останавливается без всякой ошибки в логах — он просто видит форму входа вместо привычного экрана. Дальше хуже: под чужим логином невозможно разобрать, кто провёл документ — человек или робот, а увольнение владельца записи выключает робота окончательно. Служебная учётная запись с отдельным именем, своим паролем и своей лицензией рабочего места стоит 18 000 ₽ разово и снимает весь этот класс проблем. Принципы разграничения прав мы описали на странице безопасности.

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

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

Ошибки 4 и 5: исключения и отладка на боевой базе

На вопрос «а что робот будет делать с непонятными документами» почти всегда отвечают «их почти не бывает». В реальности роботу не по силам 10–20 % случаев: нестандартная форма, пустое поле, поставщик, который прислал файл в другой раскладке. На потоке в 3 000 документов это 300–600 штук в месяц, и с ними надо что-то делать явно.

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

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

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

Ошибки 6 и 7: забытый робот и не тот процесс

Шестая ошибка — смета без второго года. Робот сдан, акт подписан, подрядчик ушёл, бюджета на сопровождение нет. Дальше происходит предсказуемое: через три-четыре месяца автоматизируемую систему обновляют, сценарий встаёт, чинить его некому и не на что. Процесс возвращается в руки, лицензия продолжает списываться до конца оплаченного года. Минимальный годовой бюджет живого робота — 90 000 ₽ на три переделки плюс сопровождение; без этой строки проект правильнее не начинать, чем начать и бросить.

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

1. 1А точно ли у системы нет программного обмена? Вопрос вендору письмом, поиск в партнёрской документации, проверка штатной выгрузки в файл, конструктора отчётов и обмена через ЭДО. Примерно у половины систем, которые в компании называют закрытыми, хотя бы один канал рабочий: порядок проверки мы описали в разборе систем без API. Три дня инженера здесь экономят двухлетнее владение роботом.
2. 2А хватает ли объёма? Порог считается в часах, а не в документах: ниже 16 часов ручной работы в месяц робот не окупается ни при какой ставке, а на обычной ставке рядового сотрудника порог — 56 часов. Как считается этот порог и почему, разобрано в статье про окупаемость робота.

Проверка готовности за час: девять вопросов

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

1. 1
   1. Процесс описан на одной странице

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

2. 2
   2. Объём замерен, а не оценён по памяти

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

3. 3
   3. У процесса есть владелец с фамилией

   Конкретный человек, готовый выделять 3–4 часа в неделю, принимать решения по исключениям и получать уведомления о сбоях. Не «отдел», не «мы все».

4. 4
   4. Известно, куда денутся освободившиеся часы

   Ответ «займутся другими задачами» не годится: он означает коэффициент утилизации ниже 0,5 и вдвое худшую окупаемость, чем в презентации подрядчика.

5. 5
   5. Понятна доля исключений и есть кому их разбирать

   10–20 % случаев роботу не по силам. Нужен человек, очередь и норматив: разобрать в течение рабочего дня.

6. 6
   6. Есть тестовый контур или готовность его развернуть

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

7. 7
   7. Робот получит служебную учётную запись

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

8. 8
   8. В бюджете есть второй год

   Переделки после чужих обновлений, сопровождение, лицензия. Робот без строки на второй год — это разовая демонстрация, а не автоматизация.

9. 9
   9. Задан вопрос про программный обмен

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

Когда лучше не начинать вовсе

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

• Процесс переписывали дважды за последние полгода. Сценарий робота придётся переписывать вместе с ним, и каждая переделка — это 20 000–50 000 ₽. Сначала регламент устаканивается, потом автоматизируется.
• Идёт смена или обновление автоматизируемой системы. Робот, написанный под интерфейс, который заменят через квартал, — это выброшенные 120 000–400 000 ₽ разработки. Дождаться переезда дешевле, чем сделать работу дважды.
• Автоматизируется задача, за которую отвечают перед регулятором. Робот ошибается систематически: если сценарий берёт не то поле, ошибку получат все документы разом, а отвечать за них будет компания, а не подрядчик. Здесь нужен сплошной контроль результата, и его стоимость надо считать до старта, а не после первого штрафа.

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

Робот не наводит порядок в процессе. Он делает беспорядок воспроизводимым.