Привет! Меня зовут Адель Давлетшин, я занимаюсь роботизацией процессов в компании «Лента». Сегодня я хочу поделиться историей о том, как наше чрезмерное увлечение RPA привело к остановкам и сбоям в критическом процессе, и как этот случай побудил нас перейти от вопроса «Можно ли это сделать с помощью RPA?» к более важному вопросу: «А почему это стоит делать именно с помощью RPA?»

Предыстория

К необходимости роботизации процессов «Лента» пришла в 2018 году. Внедрение RPA в компании и возможности этой технологии вызвали резкий рост числа задач, которые стремились автоматизировать из-за быстрой, простой и дешевой реализации. Роботизируя те или иные задачи, мы никак не влияли на существующий IT-ландшафт. Зачастую взаимодействие с пользователями строилось следующим образом: к нам приходили с проблемой, мы «записывали» действия пользователей, а затем повторяли все шаги роботом. Пара недель, и сотрудники избавлены от рутины.

Тот самый процесс

Со временем о наших успехах в роботизации узнало всё больше людей. К нам обратились коллеги из бухгалтерии с просьбой автоматизировать процесс начисления НДС по дегустациям.

Нужно было:

1.      получить данные из SAP;

2.      сформировать бухгалтерские справки;

3.      провести проводки в этой же системе в установленные сроки.

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

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

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

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

Работа над ошибками

Правильно ли мы использовали роботов для уже имеющихся задач? Что вообще стоит понимать под правильной роботизацией?

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

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

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

По результатам встреч мы определили основные причины, по которым заказчик для автоматизации процессов обращался к RPA:

1. ограниченные возможности интеграции;

2. необходимость быстрого внедрения автоматизации;

3. краткосрочные проекты или временные задачи;

4. отсутствие возможности изменения целевых систем;

5. высокие затраты на доработку систем;

6. ограниченность ресурсов у других команд;

7. дополнительный источник контроля для снижения количества ошибок;

8. необходимость обработки данных из различных источников.

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

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

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

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

Далее мы решили зафиксировать случаи, когда для автоматизации нам стоит рассматривать применение RPA, а когда использование RPA может быть нецелесообразным и даже вредным.

Когда следует рассматривать применение RPA:

1. Повторяющиеся и рутинные задачи. RPA отлично подходит для автоматизации повторяющихся и рутинных задач, которые требуют выполнения одинаковых шагов.

2. Высокий объем транзакций. RPA может значительно ускорить выполнение задач и уменьшить вероятность ошибок, если бизнес-процессы включают обработку большого объема транзакций.

3. Четкие правила. Процессы с четко определенными правилами и последовательность действий являются идеальными кандидатами для автоматизации с помощью RPA.

4. Стабильные и неизменные процессы. Процессы, которые не подвержены частым изменениям, хорошо подходят для роботизации, так как требуют минимальных доработок после внедрения.

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

6. Интеграция с существующими системами. RPA может быть полезен для интеграции различных систем, которые не имеют программного интерфейса для взаимодействия. Роботы могут работать на уровне пользовательского интерфейса, обеспечивая взаимодействие между системами.

Когда НЕ следует применять RPA:

1. Высокая изменчивость процессов. Если процессы подвержены частым изменениям, использование RPA может стать сложным и дорогостоящим из-за необходимости постоянной адаптации роботов.

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

3. Неструктурированные данные. Если данные, с которыми нужно работать, не структурированы или имеют множество различных форматов, использование RPA может быть неэффективным.

4. Высокий уровень исключений. Процессы, в которых часто возникают исключительные ситуации или нестандартные случаи, могут быть не подходящими для автоматизации с помощью RPA.

5. Низкий объем транзакций. Если объем транзакций или задач недостаточно велик, чтобы оправдать затраты на разработку и поддержку роботов, использование RPA может быть нецелесообразным.

6. Отсутствие четко определенных правил. Процессы, не имеющие четко определенных правил и последовательности действий, сложно автоматизировать с помощью RPA.

7. Высокие требования к безопасности. Если процесс включает обработку чувствительных данных с высокими требованиями к безопасности, использование RPA может быть рискованным.

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

«Одним из примеров такой аварийной ситуации, как выяснилось, может быть уход платформы с рынка и риск остановки процессов из-за проблем с лицензированием. Отсутствие компетенций у бизнес-пользователей по тем или иным процессам повлек бы за собой риски для всей компании. Для нашей компании период миграции на отечественное ПО прошел без необходимости остановки процессов, но важно иметь в виду даже такие случаи» - комментирует Роман Клюкин, Руководитель команды WEB и RPA

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

RPA как постоянное решение

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

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

Последним шагом стоит убедиться, что решение будет экономически целесообразным.

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

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

• взаимодействие с интерфейсом браузеров/приложений для получения/внесения данных;

• обработка почты;

• обработка и формирование документов;

• интеграция информационных систем (Включая разовые задачи по миграции данных);

• работа с файлами и папками;

• контроль и выявление ошибок.

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

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

 RPA как временное решение

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

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

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

Ситуации, где можно использовать RPA как временное решение:

• быстрый запуск MVP (актуально для пилотных проектов или проверки гипотез);

• необходимость быстро адаптироваться к изменениям (законодательные дедлайны и т.д.); 

• промежуточное решение при разработке/доработке целевых систем.

Хорошим примером временной роботизации был робот для кадровой дирекции по интеграции внешнего портала для обучения сотрудников с внутренней HR ERP системой. Целевым решением было собственное мобильное приложение, в котором сотрудники могли проходить и отслеживать назначенные обучения, но оно находилось на этапе разработки.

Делать интеграцию внешнего портала с внутренней HR ERP системой было нецелесообразно, так как через определенное время данный функционал был бы неактуален. Для автоматизации рутины в качестве временного решения стали использовать RPA. Робот «забирал» из внутренней HR системы список сотрудников, которым было добавлено обучение, затем переходил на внешний портал, активировал учетные записи и назначал необходимые курсы. Последним этапом робот получал по почте файл с результатами сотрудников и заносил информацию во внутреннюю систему.

«В отличие от целевого решения данные о прохождении обучения сотрудником обновлялись не сразу, а спустя определенное время, так как роботу нужно было получить, обработать и внести информацию в нашу HR систему. По завершении работ над мобильным приложением от RPA в данном процессе мы отказались» - комментирует Фадин Егор, разработчик RPA

RPA не является решением

Если в ходе анализа мы понимаем, что процесс подпадает под один из случаев «когда НЕ следует применять RPA», в роботизацию не идем. Если задача может быть решена более эффективно с помощью другой технологии или за счет доработки существующих систем (за исключением случаев временного применения роботов), RPA также не является правильным выбором.

Эти простые правила позволяют избежать множества проблем в будущем и направить ресурсы на действительно стоящие задачи.

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

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

Интересно узнать, сталкивались ли вы с неудачным опытом при роботизации процессов? Какими принципами руководствуетесь, применяя RPA? Буду рад вашей обратной связи и дискуссии в комментариях.