6 põhjust, miks robotiseeritud protsesside automatiseerimise (RPA) projektid ebaõnnestuvad, ja kuidas neid vältida

Foto autor chuttersnap saidil Unsplash

Robotprotsesside automatiseerimine (RPA) on kuum teema automatiseerimise ja AI valdkonnas. Põhimõtteliselt on RPA tarkvaravahend, mis saavutab automatiseerimise, matkides reeglitepõhiseid ja korduvaid inimtegevusi. RPA kasutab protsesside automatiseerimiseks robotit või robotit. Tänapäeval on tööstuses palju RPA müüjaid, peamisteks tegijateks on Automation Anywhere (AA), Blue Prism ja UiPath. Kui olete väikeettevõte või õpilane, kes uurib RPA välja, pakuvad enamik müüjaid ka oma tööriistade kogukondlikku versiooni, mida saab tasuta kasutada.

RPA rakendamine järgib süsteemi arendamise elutsüklit (SDLC). Selles artiklis kirjeldatakse RPA projekti võimalikke tõrkeid, mis võivad juhtuda SDLC etappides, ja kuidas neid vältida.

RPA projekti SDLC faasid
1. Planeerimine: automatiseerimiseks sobiva protsessi valimine 2. Analüüs: nõuete lahing 3. Kujundus: kuidas vältida halva lahenduse kujundamist 4. Arendus: eesseisvate keskkonnaerinevuste äratundmine 5. Testimine: RPA-s sageli kasutamata jäänud stsenaariumid projektid 6. Hüperhooldus: mis juhtub, kui robot töötab sageli liiga sageli?

1. Planeerimine: automatiseerimiseks õige protsessi valimine

RPA projekti esimene samm on valida õige protsess automatiseerimiseks. Valiku ja hindamise teostaja peaks olema kursis protsessikandidaatide ja RPA tööriistaga. RPA jaoks on protsessi teostatavuse hindamiseks kaks lähenemisviisi, mis on ülalt alla ja alt üles meetod.

Ülalt-alla meetod: protsessi valimine, määrates kindlaks ettevõtlusega seotud eelised
Alt-üles meetod: protsessi valimine, hinnates tehnilise teostatavuse taset

Ülalt-alla meetodit teeb tavaliselt juhtkond, kes on teadlik ja tunneb protsessi konteksti, näiteks protsessis osalevate töötajate arvu, kehtivat teenustaseme lepingut ja RPA mõju teisele protsessid ja äriüksused. Seda meetodit kasutatakse tavaliselt väga kõrgel tasemel, kus inimesed vaatavad korraga mitut protsessivõimalust.

Teisalt teeb alt-üles lähenemisviisi RPA lahenduste arhitekt või arendaja, kes mõistab RPA väljatöötamise metoodikat ja funktsioone. Alt-üles lähenemisviis hõlmab vajaliku keskkonna kättesaadavuse, turvalisuse ja roboti kättesaadavuse tuvastamist. See lähenemisviis võib juhtuda ka ainult analüüsi faasis, kui arendaja kogub nõudeid.

Mõlemal viisil lähenemine protsessile tagab RPA teostatavuse ja hoiab ära ressursside raiskamist eelseisvates tegevustes.

2. Analüüs: nõuete lahing

Kui RPA jaoks on valitud protsess, saame hakata nõudmisi koguma. Kui RPA on organisatsiooni esimene automaatikaprojekt, siis tõenäoliselt ei tunne enamik sidusrühmi / kasutajaid seda tehnoloogiat. Seega peab RPA ärianalüütik tutvustama RPA-d asjaomastele sidusrühmadele. Ärianalüütikul oleks lihtsam koguda kasutajatelt nõudeid, kui nad on teadlikud RPA toimimisest ja selle eelistest. Sageli võib ärianalüütik leida, et kasutajad jätavad nõuete aruteludes teatavad sammud ja väljundi vajaka, kuna nad ei pruugi automatiseerimisega kursis olla ja mil määral RPA robot saab või ei saa.

Foto James Pond saidil Unsplash

Teine stsenaarium, millega ärianalüütik võib kokku puutuda, on kasutajate lisanõuded. Rusikareegel, kui reguleerimisalasse tuleks lisada täiendavaid nõudeid, on kõigepealt mõistmine, kui palju aega kasutaja lisaruumile igapäevaselt kulutab; ja kasutajate arv, kes kasutavad funktsioone uuest ulatusest. Ärianalüütik võib vajada täiendavate nõuete analüüsimiseks ka palju aega. Täiendav ulatus võib hõlpsalt lisada pingutusi / aega, mis on vajalik arendamiseks ja testimiseks.

Seega on mõistlik kasutajatega suhelda ulatuse ja selle kohta, kuidas täiendav ulatus võib arenduse ajakava takistada.

3. Kujundus: kuidas vältida halva lahenduse kujunduse loomist

Pärast nõuete mõistmist on aeg luua meie roboti jaoks plaan! RPA-robotid on automatiseerimistehnoloogiad, mis on kavandatud inimeste koondatud tööülesannete vähendamiseks ja on seetõttu suurepärased korduvate ja väheväärtuslike tööde tegemisel.

Enamikul RPA robotitest on protsessi automatiseerimiseks neli tüüpilist sammu, sealhulgas andmete sisendite ekstraheerimine ja kinnitamine, põhiprotsessi automatiseerimine (nt andmesisestus, arvutused) ning andmete väljundite ja tulemuste genereerimine.

Nelja olulise sammu kohta saate lugeda siit. Kuna robotid teevad korduvaid töid, toimub sündmuskoha taga palju loopimist ja kui / muidu loogikat. Projekteerimisetapis on oluline, et kodeerimisloogika oleks korrektne, et tulevikus vältida kujundusprobleeme. Järgnevad näited on mõned kaalutlustest, mida lahendusearhitekt peaks RPA projektis lahenduse kujunduse loomisel arvestama:

RPA lahenduse kujundamise näpunäited: 1. Peamine silmusloogika kõigi kirjete töötlemiseks (andmesisestus) peaks olema paigas igas protsessis.
2. Robot peaks genereerima tulemused iga kirje (andmesisestuse) jaoks, näiteks "OK", "ebaõnnestunud" ja vajadusel märkused 
3. Robot peaks kasutajat teatama, kui ta on protsessi lõpule viinud akna hüpikakna, meilisõnumi jms kaudu.
4. Tagasipööramise kavandamine: kui ilmneb tõrge, jätkake järgmise sammu töötlemise jätkamiseks sammiga X
5. Tagasipööramise kavandamine: kui süsteemirike juhtub, peatage protsess ja sulgege rakendus enne roboti väljumist
6. Enne roboti väljumist veenduge, et kõik kasutatud rakendused on suletud

Piisava aja kulutamine projekteerimisfaasis on RPA sujuva väljatöötamise elutsükli tagamiseks ülioluline. Lahenduse kujundamise dokumendis tuleks loetleda ka kõik võimalikud erandid, mis juhtuksid, ja selgitada, kuidas robotid peaksid eranditega hakkama saama.

4. Areng: eesseisvate keskkonnaerinevuste äratundmine

RPA-robotid toetuvad kasutajaliidesele (UI), et teada saada, kuidas ja millal peaks kiirklahv sisestama, nuppu klõpsama või funktsiooni täitma. Identsed rakendusekraanid kõigis keskkondades (arendus, kasutajate aktsepteerimistestid (UAT) ja konkreetselt tootmiskeskkonnad) aitaksid arendusprotsessi paremini hallatavaks muuta. Kuid rakenduste käitumine on igas keskkonnas ja erinevat tüüpi kasutajatel sageli pisut erinev. Seega peaks arendaja kavandama situatsiooniplaanide kasutamist, kui selline lahknevus on tuvastatud.

Foto autor Kevin Ku saidil Unsplash

Parimal juhul peaks lahendusearhitekt olema projekteerimisetapis probleemide tuvastamiseks ja käsitlemiseks. Seega on võimalik, et lahknevusi leitakse ainult arengus. Kui selline olukord juhtub, peaks arendaja arutama lahendusearhitektiga, et kontrollida, kas on vaja uut lahenduse kavandamist, ja tegema mõjuanalüüsi muudele protsessi etappidele.

Veel üks rusikareegel RPA väljatöötamisel on modulaarsete koodide kirjutamine ja moodulite uuesti kasutamine nii sageli, kui vaja. RPA arendajad võivad sageli kokku puutuda olukordadega, kus tähelepanuta jäetud või lisanõuete tõttu tuli protsessi voogu muuta. Seega säästaks modulaarne kood aega, kuna vajalike muudatuste kajastamiseks peab arendaja tegema muudatusi ainult teatud koodiridades.

5. Testimine: testi stsenaariumid, mis RPA projektides sageli vahele jäävad

RPA robotitel on kaks peamist valdkonda, mida testida: RPA-ga seotud ja ärinõuetega seotud. Testimisel on lihtne RPA tehnoloogiaga seotud funktsionaalsetest spetsifikatsioonidest ilma jääda, kuna see ei pruugi olla projekteerimisdokumentides selgesõnaliselt loetletud. Siin on mõned mõlema valdkonna testistsenaariumid:

RPA-ga seotud stsenaariumid - aken, objekti ei leita stsenaariume - mitu robotit töötab samal protsessil korraga - kõik rakendused suletakse enne roboti väljumist - logifail salvestatakse ja loetakse iga protsessi jaoks
Ettevõtlusega seotud stsenaariumid - Andmesisestuse stsenaarium puudub - Nimi, vanus ja kliendi profiili salvestamine õnnestus - Arvestuse tulemus on õige - Prindi tõrketulemus, kui nime ei antud, ja jätka - Salvestatud täistööajale taandatud töötajate arv (makro KPI)

Testimisstsenaariumid kehtivad kõigi keskkondade kohta ja peaksid võimalusel sisaldama võimalikult paljude negatiivsete stsenaariumide testimist. UAT-etapis näeksid kasutajad roboti füüsilist väljundit ja sageli võivad nad taotleda kosmeetilisi muudatusi väljundi esitusviisi osas. Seega peaksid arendajad alati kasutajatega ühendust võtma, kui nad on testimistulemustega rahul.

6. Hüperhooldus: mis juhtub, kui robot töötab sageli liiga sageli?

Palju õnne! Teie RPA robot on nüüd kasutusele võetud! Nüüd on vaja ainult jälgida roboteid, veendumaks, et nad täidavad protsessi käivitatud viisil.

Me võime stsenaariumi määratleda kui 'RPA robot töötab valesti', kui protsessi käitamine ei saavutanud oodatavat tulemuse / peamiste tulemusnäitajate (KPI) eesmärki, mis on tavaliselt projekti hartas täpsustatud.

Mõni RPA KPI näidis sisaldab: 
- Salvestatud täistööajale taandatud töötajate arv (makro KPI) -% ajast / jooksust, mis vajab inimese sekkumist - Töödeldud kirjete arv tunnis / päevas - Roboti poolt edukalt töödeldud kirjete arv

Lisaks robotite käitumise jälgimisele ja erandite uurimisele jäävad inimesed sageli robotite tõhususe registreerimise ja mõõtmise vahele. Seega peaks RPA meeskond koostama KPI loendi, mida mõõta ja ressursse, et mõista ja analüüsida, kas RPA rakendamine on edukas.

Kõrvaliste märkmetena on vaja täiustusi, kui robotid ei tööta ootuspäraselt või kui kasutaja viskab liiga palju erandeid. Kui see on teie esimene RPA-projekt, on tüüpiline, kui protsessi rakendatakse tootmiskeskkonnas 2–3 korda.

Foto autor Phillip Glickman saidil Unsplash

Head automatiseerimist!