Роботизация бизнес-процессов: типовые ошибки в RPA проектах (Часть 6)

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

Ошибка 1. Переоценка возможностей технологии Robotic Process Automation

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

Не следует любой ценой заменять сотрудника роботом от начала и до конца бизнес-процесса. Такой подход может значительно увеличить сложность проекта по роботизации и снизить показатели RoI (Return on Investment, возврат вложенных инвестиций). Правильным подходом является автоматизация наиболее простых и рутинных частей процесса, с сохранением участия человека (сотрудника) в нетривиальных ситуациях. В таком случае, проект пройдет быстро, будет экономически оправданным, и в то же время даст ощутимый эффект. В то время, когда, компания выйдет на определенный уровень зрелости в области роботизации, передать роботам оставшиеся участки работ в бизнес-процессе будет значительно проще, а вероятность «провала» проекта будет минимальна.

Ошибка 2. Переоценка результатов Proof of Concept

Перед принятием решения о старте проекта по роботизации бизнес-процессов, заказчик обычно проводит тестирование самой концепции, то есть подтверждение работоспособности технологии (Proof of Concept, PoC). На этом этапе часто возникает ситуация, когда в РоС отдается самый простой процесс. Такой выбор может быть обусловлен многими объективными факторами. Вот некоторые из них:

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

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

  • Proof of Concept на небольшом бизнес-процессе с получением понимания как работает данная технология в конкретной среде.
  • Пилот по роботизации одного-двух полноценных бизнес-процессов, максимально затрагивающих все технологические аспекты роботизации. Если заказчик собирается роботизировать процессы, затрагивающие SAP, приложения с WEB интерфейсом, MS Windows приложения, OCR (optical character recognition) технологии – все это желательно протестировать еще в пилоте, чтобы не наткнуться на ограничения платформы уже после покупки большого количества лицензий.
  • Масштабирование проекта на весь пул планируемых к роботизации процессов.

Следует заметить, что наличие всех трех этапов не является обязательным требованием. Если заказчику необходимо автоматизировать много однотипных процессов, то правильно подобранный для PoC бизнес-процесс может дать ему ответы на все вопросы. Может быть и другая ситуация, когда работоспособность самой технологии не вызывает сомнений (например, в банковской и страховой сферах), и можно начинать проект с этапа пилотирования.

Ошибка 3. Неправильный состав рабочей группы проекта

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

  • ИТ безопасность. Роботу понадобятся аккаунты для работы в ИТ системах компании, а значит ему необходимо назначить права доступа. Какие это будут права: единая модель доступа для всех роботов или каждый робот получит свой собственный набор доступов? Открытым остается вопрос выдачи роботу ЭЦП. Для подписи в пределах компании — это можно решить внутренним распоряжением. Для подписи за пределами компании  - этот вопрос должен быть урегулирован отраслевым или государственным законодательством. И тут следует отметить, что в Украине этот вопрос пока даже не стоит на повестке дня регуляторов, да и в мире в целом, ситуация ненамного лучше.
  • Контролирующие структурные подразделения. Роботизируемые бизнес-процессы часто затрагивают области, подлежащие проверке на соответствие отраслевым стандартам. И хотя передача определенных задач от человека роботу только снижает риски несоответствия, контролирующие структурные подразделения должны с самого начала проекта активно привлекаться для оценки на соответствие отраслевым стандартам и выдачи соответствующих рекомендаций.
  • HR. Применение роботов высвобождает человеческие ресурсы компании, а значит необходимо привлечение HR департамента, который должен учитывать какие сотрудники будут высвобождаться, планировать их переобучение (если это необходимо) и перераспределение на задачи с большей добавочной стоимостью.

Ошибка 4. Роботизация бизнес-процессов без оптимизации

Хотя роботизация зачастую просто ускоряет действия пользователя и повышает производительность, было бы ошибкой передать роботу бизнес-процесс (даже на стадии PoC или пилота), предварительно не пересмотрев его.
Проектная команда должна понимать, что правило GIGO (Garbage In, Garbage Out, «Мусор на входе — мусор на выходе») на 100% применимо и к роботизации бизнес-процессов.

Ошибка 5. Недооценка требований к квалификации кадров

Если в компании было принято решение развивать собственный центр компетенции, то было бы большой ошибкой полагать, что можно быстро переориентировать специалистов другого профиля на внедрение RPA. Ускоренные онлайн-тренинги возможно и смогут обучить специалистов выполнить небольшой Proof of Concept. Однако, для масштабного внедрения собственными силами нужно обучить специалистов на продвинутых тренингах, затем дать им возможность поработать в реальных проектах по роботизации бизнес-процессов в течении 3-6 месяцев под управлением опытных специалистов, и только после такой подготовки таких специалистов можно допускать к промышленному проекту по роботизации.

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

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

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

Перечисленные проблемные вопросы при внедрении Robotic Process Automation, конечно же, не являются исчерпывающем перечнем. Тем не менее это наиболее часто встречаемые и очевидные ошибки, которые легко нивелировать грамотным планированием проекта и выбором квалифицированного партнера, способного помочь заказчику «не наступить на известные грабли».

Желаете узнать больше о Robotic Process Automation (RPA), пожалуйста обращайтесь в наши украинский и гонконгский офисы!

О Компании «DMS Solutions»:
«DMS Solutions» - является украинским разработчиком системы электронного документооборота elDoc . Мы - первый украинский провайдер услуг в сфере роботизации бизнес-процессов (Robotic Process Automation, RPA) и построении систем управления программными роботами. «DMS Solutions» работает на рынках Европы, Северной Америки и Азии и имеет офисы в Гонконге и Украине.

Смотрите наше видео о том, как программные роботы выполняют функции бек-офиса!