6 прычын, па якіх праекты Robotic Process Automation (RPA) церпяць няўдачу, і як іх пазбегнуць

Фота Chuttersnap на Unsplash

Аўтаматызацыя робататэхнічных працэсаў (RPA) - актуальная тэма ў галіне аўтаматызацыі і AI. Па сутнасці, RPA - гэта праграмнае забеспячэнне, якое дасягае аўтаматызацыі, імітуючы чалавечыя дзеянні, заснаваныя на правілах і паўтараюцца. RPA выкарыстоўвае робата ці бота для аўтаматызацыі працэсаў. На сённяшні дзень у гэтай галіне ёсць шмат пастаўшчыкоў RPA, асноўнымі гульцамі якіх з'яўляюцца "Аўтаматызацыя дзе-небудзь" (AA), "Сіняя прызма" і UiPath. Калі вы маленькі бізнес або студэнт, які вывучае поле RPA, большасць пастаўшчыкоў таксама прадастаўляюць супольнай версіі сваіх інструментаў, якую можна бясплатна выкарыстоўваць.

Укараненне RPA варта за жыццёвым цыклам развіцця сістэмы (SDLC). У гэтым артыкуле апісаны магчымыя збоі ў праекце RPA, якія могуць здарыцца на этапах SDLC, і спосабы іх пазбегнуць.

Фазы праекта RPA SDLC
1. Планаванне: Выбар правільнага працэсу для аўтаматызацыі 2. Аналіз: Бітва з патрабаваннямі 3. Дызайн: Як пазбегнуць стварэння дрэннай канструкцыі рашэння 4. Развіццё: Распазнаванне адрозненняў навакольнага асяроддзя наперад 5. Тэставанне: Тэставыя сцэнарыі, якія часта не трацяць у RPA праекты 6. Гіпер-сыход: што рабіць, калі робат занадта часта працуе?

1. Планаванне: выбар правільнага працэсу для аўтаматызацыі

Першым крокам у праекце RPA з'яўляецца падбор правільнага працэсу для аўтаматызацыі. Людзі, якія праводзяць адбор і ацэнку, павінны быць знаёмыя з кандыдатамі ў працэсе і інструментам RPA. Ёсць два падыходы, каб ацаніць, ці магчыма рэалізаваць працэс RPA, і гэта метады зверху ўніз і знізу ўверх.

Метад зверху ўніз: выбар працэсу шляхам вызначэння пераваг, звязаных з бізнесам
Метад "знізу ўверх": выбар працэсу шляхам ацэнкі тэхнічнай мэтазгоднасці

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

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

Даступ да працэсу з абодвума падыходамі забяспечвае мэтазгоднасць RPA і пазбягае марнавання рэсурсаў на будучыя мерапрыемствы.

2. Аналіз: Бітва з патрабаваннямі

Калі працэс будзе абраны для RPA, мы можам пачаць збіраць патрабаванні. Калі RPA з'яўляецца першым праектам па аўтаматызацыі арганізацыі, верагодна, што большасць зацікаўленых бакоў / карыстальнікаў не знаёмыя з гэтай тэхналогіяй. Такім чынам, бізнес-аналітык RPA павінен азнаёміць RPA з адпаведнымі зацікаўленымі бакамі. Бізнэс-аналітыку было б прасцей сабраць патрабаванні ад карыстальнікаў, калі яны ўсведамляюць, як працуе RPA і якія яго перавагі. Часта бізнес-аналітык можа выявіць, што карыстальнікі прапускаюць пэўныя крокі і высновы, неабходныя пры абмеркаванні патрабаванняў, паколькі яны могуць не знаёміцца ​​з аўтаматызацыяй і ў якой ступені робат RPA можа або не можа зрабіць.

Фота Джэймса Пондса на Unsplash

Іншы сцэнар, з якім можа сутыкнуцца бізнес-аналітык, - гэта дадатковыя патрабаванні карыстальнікаў. Правіла, калі дадатковыя патрабаванні павінны быць дададзены ў аб'ём, спачатку разумее, колькі часу штодня траціцца карыстальнікам на дадатковы аб'ём; і колькасць карыстальнікаў, якія выкарыстоўваюць функцыі з новай вобласці. Бізнес-аналітыку таксама можа спатрэбіцца выдаткаваць шмат часу на аналіз дадатковых патрабаванняў. Дадатковая сфера можа лёгка скласці намаганні / час, неабходныя для распрацоўкі і тэставання.

Такім чынам, разумна мець зносіны з карыстальнікамі пра маштабы і пра тое, як дадатковая сфера можа перашкодзіць тэрмінам распрацоўкі.

3. Дызайн: Як пазбегнуць стварэння дрэннага дызайну рашэння

Разумеючы патрабаванні, прыйшоў час стварыць план для нашага робата! Робаты RPA - гэта тэхналогіі аўтаматызацыі, накіраваныя на памяншэнне залішніх працоўных задач для чалавека і, такім чынам, выдатна спраўляюцца з паўтаральнымі і малакаштоўнымі задачамі.

Большасць робатаў RPA мае чатыры тыповыя этапы аўтаматызацыі працэсу, уключаючы выманне і праверку ўваходных дадзеных, аўтаматызацыю асноўнага працэсу (напрыклад, увод дадзеных, вылічэнні), а таксама генерацыю высноваў і вынікаў дадзеных.

Больш падрабязна пра чатыры асноўныя этапы можна прачытаць тут. Паколькі робаты робяць паўтараюцца задачы, за пляцоўкай адбываецца шмат цыклаў, а таксама лагічнасць if / else. На этапе праектавання важна правільна выправіць логіку кадавання, каб пазбегнуць праблем у дызайне ў будучыні. Наступныя прыклады - некаторыя з меркаванняў, якія архітэктар павінен прыняць да ведама пры стварэнні дызайну рашэння ў праекце RPA:

Саветы па дызайне рашэння RPA: 1. Асноўная логіка цыкла для апрацоўкі ўсіх запісаў (увод дадзеных) павінна быць на месцы для кожнага працэсу
2. Робат павінен ствараць вынікі для кожнай запісу (увод дадзеных), такіх як "ОК", "Памылка" і заўвагі пры неабходнасці 
3. Робат павінен апавясціць карыстальніка, калі ён скончыў працэс, пры дапамозе ўсплываючых вокнаў, электроннай пошты і г.д.
4. Планаванне адкатаў: калі здараецца памылка, вярніцеся да кроку X, каб працягнуць апрацоўку наступнай запісу
5. Планаванне адкатаў: калі адбудзецца збой сістэмы, спыніце працэс і зачыніце прыкладанне да выхаду робата
6. Пераканайцеся, што ўсе выкарыстаныя прыкладанні закрытыя перад выхадам робата

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

4. Развіццё: наперад усведамленне адрозненняў навакольнага асяроддзя

Робаты RPA спадзяюцца на карыстацкі інтэрфейс (UI), каб ведаць, як і калі ён павінен уводзіць клавішу хуткага доступу, націскаць або выконваць функцыю. Ідэнтычныя экраны прыкладанняў у любых асяроддзях (распрацоўка, тэставанне прыёму карыстальнікаў (UAT) і вытворчае асяроддзе спецыяльна) дапамогуць зрабіць працэс распрацоўкі больш кіраваным. Аднак паводзіны прыкладанняў часта некалькі адрозніваюцца ў кожнай асяроддзі і пры выкарыстанні розных тыпаў карыстальнікаў. Такім чынам, пры выяўленні такога неадпаведнасці распрацоўшчык павінен планаваць планы "на выпадак".

Фота Кевіна Ку на Unsplash

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

Іншае вялікае правіла пры распрацоўцы RPA - гэта напісанне модуляваных кодаў і паўторнае выкарыстанне модуляў столькі разоў, колькі неабходна. Распрацоўшчыкі RPA часта могуць сутыкнуцца з сітуацыяй, калі неабходна змяніць паток працэсу з-за грэбавання або дадатковых патрабаванняў. Такім чынам, модуляваны код дазволіў зэканоміць час, бо распрацоўшчыку трэба толькі ўнесці змены ў пэўныя радкі кода, каб адлюстраваць неабходныя змены.

5. Тэставанне: тэставыя сцэнарыі, якія часта не трацяцца ў праектах RPA

На робатах RPA можна выпрабаваць дзве асноўныя вобласці: звязаныя з RPA і звязаныя з патрабаваннямі бізнесу. Праводзячы тэставанне, нельга прапусціць функцыянальныя характарыстыкі, звязаныя з тэхналогіяй RPA, паколькі яны не могуць быць дакладна прапісаны ў праектных дакументах. Вось некалькі тэставых сцэнарыяў для абедзвюх абласцей:

Сцэнарыі, звязаныя з RPA - Вокны, сцэнары не знойдзены аб'ектамі - Некалькі робатаў, якія працуюць у той жа працэс адначасова - Усе праграмы закрытыя перад выхадам робата - Файл часопіса захоўваецца і чытаецца для кожнага запуску працэсу
Сцэнарыі, звязаныя з бізнесам - сцэнар уводу дадзеных не прадугледжаны - паспяхова ўвесці імя, узрост і захаваць профіль кліента - вынік разліку правільны - вынік памылкі друку, калі імя не пазначана, і працягнуць - колькасць захоўваемых працэсаў FTE (макра КПІ)

Сцэнарыі тэсціравання прымяняюцца да любых умоў і павінны ўключаць у сябе тэставанне як мага больш негатыўных сцэнарыяў. На этапе UAT карыстальнікі змогуць убачыць "фізічны" выхад з робата, і часта яны могуць запытаць касметычныя змены ў плане прадстаўлення вынікаў. Такім чынам, распрацоўшчыкі павінны пастаянна звяртацца да карыстальнікаў, калі яны задаволены вынікамі тэставання.

6. Гіпер-сыход: што рабіць, калі робат працуе няправільна?

Віншуем! Ваш робат RPA зараз разгорнуты! Зараз справа толькі ў маніторынгу робатаў, каб пераканацца, што яны выконваюць працэс як справакаваны.

Мы можам вызначыць сцэнар як «няправільны робат RPA», калі выкананы працэс не дасягнуў чаканага выніку / асноўных паказчыкаў эфектыўнасці (KPI), як правіла, указаных у статуце праекта.

Некаторыя ўзоры КПК RPA ўключаюць у сябе: 
- Колькасць захаваных FTE (макра КПІ) -% часу / запуск, які патрабуе ўмяшання чалавека - Колькасць запісаў для апрацоўкі за гадзіну / дзень - Колькасць запісаў, якія паспяхова апрацоўваюцца робатам

Акрамя назірання за паводзінамі робатаў і вывучэння выключэнняў, людзі часта прапускаюць запіс і вымярэнне эфектыўнасці робатаў. Такім чынам, каманда RPA павінна падрыхтаваць спіс KPI для вымярэння і выдзеленых рэсурсаў, каб зразумець і прааналізаваць, калі рэалізацыя RPA паспяховая.

З іншага боку, удасканалення патрэбныя, калі робаты працуюць не так, як чакалася, альбо кідаюць на карыстальнік занадта шмат выключэнняў. Звычайна размясціць працэс у 2-3 разы ў вытворчым асяроддзі, калі гэта ваш першы праект RPA.

Фота Філіпа Глікмана на Unsplash

Шчаслівая аўтаматызацыя!