Роботизація бізнес-процесів: розповсюджені помилки початкового етапу проектів (Частина 6)
При старті проекту з роботизації бізнес-процесів, як і в будь-яких інших проектах з автоматизації бізнесу, є своє підводне каміння, що неочевидне для замовника, який вперше почав тестувати цю технологією. Сьогоднішній матеріал як раз й буде присвячений найбільш розповсюдженим помилкам, які допускають проектні команди разом із їх спонсорами на початкових етапах RPA (Robotic Process Automation) проектів. Описані нижче помилки, звичайно ж, не є вичерпним переліком, так само як не всі помилки можуть бути релевантними для кожного замовника.
Помилка 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 - провайдер технології Robotic Process Automation (RPA), який надає повний спектр RPA рішень. Ми - перший український провайдер послуг у сфері роботизації бізнес-процесів (Robotic Process Automation, RPA) та побудови систем управління програмними роботами. DMS Solutions працює на ринках Європи, Північної Америки та Азії і має офіси в Гонконзі та Україні. Дивіться наше відео про те, як програмні роботи виконують функції бек-офісу!