`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Виталий Береза

Robotic Process Automation. Часть 6: Распространённые ошибки начального этапа проектов

+11
голос

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

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

Ошибка 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. Часть 1. О технологии

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+11
голос

Напечатать Отправить другу

Читайте также

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT