Наш перший RPA-проект на UiPath: продакшен, тестування й робота з людськими страхами
На початку 2018 року EPAM одержав перший проект robotic process automation (RPA), що базується на технології UiPath. Протягом року команда зі Львова, яка працює з клієнтом, запустила в роботу 7 ботів, покрила 5 бізнес-напрямів, а реальний ROI проекту перевищив очікування на 20%. Однак шлях побудови «експертизи» з нуля був тернистим. Як це вдалося нашій команді, читайте в цій статті. На проекті я від самого початку і як Delivery Manager знаю всі нюанси, з якими нам довелося зіткнутися.
Про клієнта
Спочатку розповім про нашого клієнта. Це компанія зі США, основною діяльністю якої є надавання посередницьких послуг між страховими компаніями й постачальниками медичних товарів і послуг. Вона створює та надає комплексні вирішення у сфері охорони здоров’я як для постачальників, так і для пацієнтів, яких обслуговує. Бізнес-напрями включають:
- стоматологію;
- діагностику;
- обладнання та прилади;
- комплексний догляд;
- фізіотерапію;
- транспорт і переклад.
Команда EPAM працює із цим клієнтом уже понад десять років, а я на акаунті вже п’ятий рік. Починала як ВА інфраструктурного проекту. Оскільки ми розумілися на багатьох аспектах діяльности замовника й володіли доменними знаннями, у нас виникла ідея роботизації певних бізнес-процесів. Разом з девелоперами ми розробили PoC і наочно продемонстрували можливості RPA. Потенційна користь від роботизації стала очевидною клієнтові, що вилилося для нас в окремий проект.
Невдала історія з індійськими ботами
Та перш ніж усе вийшло в продакшен та інвестиції клієнта почали повертатися, нашій команді довелося добре попрацювати й розрулити не один десяток викликів. Передусім переконати клієнта, що його бізнес потребує автоматизації бізнес-процесів. Ситуацію обтяжував ще той факт, що клієнт уже три роки поспіль працював у цьому напрямі з індійською компанією. Вони вже навіть створили якихось ботів і 17 серверів, на яких ці боти мали розгортатися. Але ніхто так і не побачив їхньої реальної цінности. Ба більше, ніхто не бачив самих ботів у продакшені.
Однак наш багаторічний позитивний досвід роботи із цим клієнтом і правильно написана й представлена PoC усе ж дали нам можливість почати автоматизацію частини бізнес-процесів. Спочатку було неймовірно складно. Співробітники нашого клієнта боялися звільнення й, відповідно, не бажали ділитися інформацією. Не розуміючи, як насправді працюють боти, працівники (та й менеджмент) боялися, що систему зламають.
За два з половиною місяці нам удалося запустити в продакшен першого бота. Спочатку клієнт перевіряв його на кожному кроці. Але коли бот уже здобув певну довіру, на нас посипалося багато change requests. Воно й не дивно. Бо через страх, що бот може завалити бізнес, клієнт видавав процеси маленькими шматочками. Та потім замовник почав додавати один за одним нові бізнес-процеси. Як наслідок, у нас половина часу йшла на новий девелопмент, а інша половина — на закриття change requests.
Технічний бік проекту
Основною платформою проекту обрали UiPath. Для багатьох клієнтів вона є оптимальною (що функціонально, що вартісно), як порівняти з аналогами. Велика перевага RPA-проектів у тому, що розробники можуть відчути користь від своєї роботи відразу після їхнього релізу. Від моменту збирання вимог до моменту розгортання проекту в продакшені проходить у середньому два-три місяці. Такий короткий цикл дає змогу побачити кінцевий результат у стислі строки й продовжити співпрацю з клієнтом в інших напрямах.
Технологічний стек має такий вигляд:
- RPA platform: UiPath.
- Infrastructure platform: MS Azure.
- Backend database: Azure SQL.
- Log storage and analytics: ELK Stack.
- CI/CD/CM toolset: MS PowerShell DSC, Terraform and BuildMaster.
- Languages: VB .NET, C# .NET, JavaScript, PowerShell, VBA, etc.
- Integrations: MS Exchange, Azure Service Bus, Web App, desktop thin clients.
Проект можна вважати викликом, оскільки компанія не мала досвіду розробляння на UiPath-технології на продакшені. Наша команда сама досліджувала цей напрям і будувала обізнаність з нуля. Тому що в девелопменті, що в тестингу на нас чекало багато несподіванок і набитих ґуль.
Нашим клієнтом, як я вже згадувала, була страхова компанія, до складу якої входила енна кількість невеличких стартапів, які вона купувала в процесі свого росту. Відповідно, кожен стартап приходив у компанію зі своїми інфраструктурою й системами. У більшості випадків це legacy, про які навіть немає в кого дізнатися. Це й стало нашою першою набитою ґулею. Зворотний бік усіх цих підсистем — одержання нашим ботом прав на роботу з ними й доступів до них: різні акаунти, облікові записи й домени.
Першу архітектуру проекту ми зробили в міру нашого розуміння процесу, і це була ще одна набита ґуля. Адже за три місяці роботи бота в продакшені нам довелося трохи змінити архітектуру, зробивши її гнучкішою й адаптивнішою. Поступово почали з’являтися внутрішні процеси й code review, установлювалися правила та створювалися домовленості щодо назв (naming convention). Звичайно, стартуй ми зараз такий проект, усе було б куди простіше й зрозуміліше, адже вже є вироблена система. Мене тішить той факт, що за всіма оцінками (estimates), які наша команда склала ще на початку проекту, ми й досі в графіку.
До речі, ось як можна зреалізувати процес у такому проекті:
Development
Для кожного в команді це був перший досвід роботи з UiPath. Development Technical Lead прийшов у RPA-технологію з .NET-бекграундом. Його досвід і «сеньйорність» уможливили досить безболісно задаптуватися й навчитися дописувати на JavaScript, PowerShell, VB.net тощо. Адже його логіка роботи й кроки в більшості випадків доволі прості. Це алгоритмічна мова й тут усе, як у звичайному програмуванні. Різниця лише в тому, що робот — це завжди скінченний процес. Він зайде в одну систему, другу, витягне з них дані, проклікає, опрацює їх, видасть результат і відзвітує. Це не застосунок чи бухгалтерська програма, коли одна платформа включає всі модулі. Тут є скінченна кількість кроків, які не потрібно постійно розширювати, а лише вдосконалювати. Для нового функціонала робиш новий процес. Тому його легше почати, закінчити та, звичайно ж, підтримувати.
Тестування
Загалом у RPA-тестуванні ми використовували такі самі техніки й методи, що й у звичних проектах. Істотна відмінність полягає в тому, що тут ти не клікаєш сам, а пишеш сценарій і дивишся, як робот у тому чи тому місці працюватиме відповідно до попередньо заданих вхідних параметрів. Це була чергова набита ґуля. Для того щоб написати сценарій, потрібно дослідити нюанси роботи тої чи тої системи замовника, з якими працюватиме робот. Як і відшукати максимум ситуацій, з якими зустрічається реальний працівник під час роботи із системою, і що потенційно можуть загнати бота в глухий кут чи спричинити його невідповідну поведінку.
У результаті роботи QA-команди майже всі дефекти, які мають місце на різних етапах наших процесів, виявляють до моменту виходу ботів у продакшен. Це означає, що після релізу ми відразу можемо перейти до розробляння й тестування нового процесу або до розширювання вже наявних згідно з побажаннями замовника. Але щоб досягти такого стану речей, ми, знову ж таки, пройшли тернистий шлях з помилок і спроб. Адже профільних тестувальників у нашій компанії не було, і ті, хто взявся за ці процеси, будували обізнаність майже з нуля.
Найбільше команда втішилася, коли наш перший бот вийшов у продакшен, і ми побачили, що він коректно працює й не завалюється на дрібницях. Однак частину нашої роботи таки довелося доробляти. Тому що в продакшені система реагує на бота інакше, і на це ніяк не вплинеш. Адже наш клієнт знає, як користуватися своїми системами, але не знає всіх можливих сценаріїв роботи, бо документації до систем немає. На продакшені ми стикалися з недоробленими інструментами, де реально навіть немає коректних назв, а лише button 1, button 2, form 1, form 2.
Що ж ми завтоматизували?
На початку збирання інформації по кейсах для автоматизації ми з клієнтом розібрали 20 бізнес-процесів. Спершу в автоматизацію пішло два. Інші процеси, перш ніж автоматизувати, треба було змінювати й стандартизувати всередині компанії. Звичайно, що на це я й звернула увагу клієнта. До речі, важливою перевагою для бізнес-аналітика на RPA-проектах є можливість проявити себе в ролі консультанта.
Кейси для ботів
Пацієнт, страхова компанія, вендор — усі спілкуються з ботом
Коли пацієнт звертається до страхової компанії, на нього створюють окрему теку з усіма даними й закріплюють за ним медсестру. У разі, коли пацієнтові треба згідно з призначенням лікаря одержати милиці, створюється запит, який уже авторизує та відстежує наш бот. Він формує лист, надсилає його на погодження страховій і вендорові й порівнює ціни різних пропозицій. Якщо бот дістає всі погодження, справу закривають, пацієнт одержує свої милиці, страхова — різницю в ціні, а вендор — гроші за оплату послуг.
Якщо ж із якихось причин страхова компанія не погоджується на оплату, бот закриває цей кейс. Є ще третій варіант розвитку подій, коли бот не розуміє, що написано в листі. Це може бути через незрозумілі скорочення, нові слова тощо. Такі листи бот перенаправляє людині. Частка таких листів становить не більш як 10 відсотків. Відповідно, робот замикає на собі весь бізнес-процес потоку спілкування «пацієнт — страхова компанія — вендор». Ця діяльність проходить без участі людини.
Не оплачено заявку. Чому? Бот відповість
Ще один наш бот інтегрується з медичним порталами й шукає інформацію про неоплачені заявки та причини такої ситуації. Якщо заявка кілька днів залишається в статусі «не оплачено», вона автоматично потрапляє до колекторів. Загалом є сотні тисяч операцій з оплатами в системі замовника, тому людям складно відстежити всі транзакції. У кожного постачальника є свій портал, де можна перевірити, чи взагалі той запит є на опрацьовуванні, чи його поставили в чергу на оплату, і з’ясувати причину затримки. Наш бот бере цей запит від колекторів, заходить на портал вендора, збирає потрібну інформацію та передає її в систему. А відтак записує, чому запит перебуває в статусі «не оплачено», розподіляючи інформацію за напрямами:
- Не оплачено, бо це дубльована заявка.
- Не оплачено, бо неправильно виставлено суму.
- Потрібно додатково перевірити дані.
- Запит завис із інших причин.
Усю важливу інформацію бот реєструє та передає на опрацьовування людям. На сьогодні наша команда розробила інтеграцію з одним порталом вендора, а попереду ще 17.
Proof of Concept
На регулярній основі команда EPAM розробляє для цього клієнта Proofs of Concept. Однією з таких був процес розпізнавання недоброчесних пацієнтів.
Наприклад, нам потрібно визначити, чи добре пацієнти лікуються, чи є в них якісь проблеми психологічного чи ментального характеру, чи не форсують вони лікування й чи не занадто часто звертаються по медичну допомогу. Тобто зідентифікувати недоброчесних пацієнтів. Ми маємо записи медсестри з коментарями про пацієнта (на що він скаржився, який стан його здоров’я та інші показники). Це все сканують і прикріплюють до справи цього хворого. Потім наш бот бере цей документ, аналізує дані пацієнта й на основі алгоритмів видає можливі варіанти рішень.
Кожен штат і кожна лікарня мають свій тип медичних записів, тому нашого бота потрібно щоразу дотреновувати. Він перевіряє, чи є відповідні слова-маркери або вислови, які підпадають під визначення шахрайства, неадекватности або маніпуляції з боку пацієнта, чому його лікування є нестандартним і забирає більше грошей у страхової компанії, чи дотримується він рекомендацій, чи, може, просто симулює симптоми. На першому етапі PoC ми показали, що можемо розпізнавати всі ці речі, робити аналіз і певні прогнози, щоб звернути увагу персоналу компанії на такі випадки для подальшого їх опрацювання.
Психологічний складник у RPA-бізнесі
Була додаткова складність у роботі з працівниками клієнта. Люди боялися втратити свої робочі місця через роботів. Тому нашій команді довелося попрацювати й у цьому напрямі: пояснювати та показувати потенційні вигоди як для бізнесу, так і для самих працівників замовника. За деякий час люди відчули, що їхня робота стала легшою, і в них з’являються набагато цікавіші завдання. Ба більше, їх ніхто не збирається звільняти. Емоційний інтелект, міркування, судження, взаємодія з клієнтами — це для людини. А рутину віддали роботам, які дають нам змогу легко масштабувати їхню роботу й за певних умов досконало її виконувати.
Що вже зроблено й наступні кроки
За півтора року роботи команда вже завтоматизувала частину бізнесу клієнта:
- Вивела в продакшен 7 ботів.
- Покрила 5 бізнес-напрямів клієнта.
- Розробила 5 Proofs of Concept.
- Продемонструвала ROI, що перевищив очікування замовника на 20%.
Попри всі ці гарні цифри, перед нами ще багато викликів. Адже зараз триває стандартизування бізнес-процесів клієнта і їх адаптування. Фактично щомісяця приходять завдання на автоматизування нових процесів. Звичайно, що частину з них ми опрацьовуємо. Проте іншу частину відхиляємо й пропонуємо змінити підходи всередині компанії, щоб поліпшити цей бізнес-процес. Адже є випадки, коли бот не буде корисним. Наприклад, коли процес використовує мало людей або виконує маленькі транзакції. Звичайно, для них теж можна запропонувати бота, тоді ROI такого процесу буде мінімальним.
Зараз ми збираємо дані про коректність виконання нашими ботами своїх кроків. Як я вже згадувала, вони інтегруються з legacy-системами й будь-якої миті щось може піти не так. Адже бізнес-процес було прописано під ідеальне середовище й ідеальні дані. Ідеальне середовище можуть похитнути legacy-системи, які першої-ліпшої миті можуть просто зависнути. А ідеальні дані можуть некоректно внести люди. Тому консистентність і правильність даних, уведених у систему, є запорукою успішної роботи наших ботів. А на другому місці — безперебійна робота legacy-систем.
Автоматизація бізнес-процесів уможливлює зреалізувати дієву систему звітности. Щодня клієнт одержує звіт з винятками, які не зміг опрацювати робот. Як правило, це збої в системах, з якими зінтегровано роботів. Також формуються аналітичні звіти за певний період (щодня, щотижня й щомісяця). Це, з одного боку, допомагає показати клієнтові їхню ефективність, а з іншого — допомагає девелоперам поліпшувати процес і його ефективність. А ефективність наших ботів підтверджують прості цифри: наша команда зросла із 4 до 9. Це сталося за 8 місяців проекту. І зараз у львівський офіс заходить другий проект з UiPath RPA.
Тим, хто лише придивляється до технології чи вже почав знайомитися з UiPath, вартує мати базові знання .NET, розуміння, що таке RPA та UiPath-архітектура й інфраструктура. Багато важитимуть знання алгоритмів, робота з вебсервісами, API, Windows-застосунками тощо, як і вміння мислити креативно й знаходити нестандартні підходи до розв’язання завдань. Ну й, звісно ж, англійська мова, бо на RPA-проектах девелоперам часто доводиться спілкуватися з командою замовника.
