18. november 2022
Av Stephen Elliott, MBA, JD, CISSP, CSM, SVP, IT-innovasjon og beslutningsoptimalisering
Den største styrken bak robotisk prosessautomatisering (RPA) er tilgjengeligheten og brukervennligheten.
Dessverre kan disse faktorene også bidra til at den mislykkes i store, skalerbare implementeringer. RPA åpner døren for teknologi uten at det kreves en grad eller mange års erfaring – å legge koding i hendene på sluttbrukere. Imidlertid forventer de fleste ledere i dag mye større suksesser (og dermed kostnadsbesparelser) fra RPA. I disse tilfellene trenger en organisasjon mer enn bare en sluttbruker som registrerer automatiseringer på skrivebordet sitt. Hele løsningen inkluderer programvare som kjører på servere, roboter som kjører på skrivebord, sikkerhetslegitimasjon, nettverkstilkobling, metoder for å skrive, teste og distribuere programmene, og et team av mennesker som støtter prosessen. Alle disse komponentene er avgjørende for suksess, men de blir ofte ignorert under det første kjøpet og implementeringen av RPA-løsninger.
RPA bør ikke sees på som en grov gjengivelse av trinnene til en sluttbruker. Det bør sees på som en nøyaktig gjengivelse av trinnene en sluttbruker ville tatt. Dette presisjonsnivået krever at RPA-implementeringer – for å lykkes i stor skala – tar i bruk livssyklusen til programvareutvikling, inkludert hovedkomponenter som krav, testing og den underliggende infrastrukturen robotene kjører på.
Krav
I likhet med tradisjonell utvikling innebærer dette å tydelig forstå og dokumentere alle inndataene (dataene en bruker kan motta eller se) og alle trinnene de kan ta for å utføre oppgavene sine i systemet(ene) de bruker. Kravinnsamlingsprosessen kan være like detaljert og like vanskelig som de som brukes i enhver annen tradisjonell IT-øvelse. RPA som unngår dette prosessnivået som er iboende i mange IT-organisasjoner, risikerer å bare automatisere det som er kjent som «den lykkelige veien», noe som fører til de ofte fryktede «tapte krav»-konsekvensene som plager mislykkede initiativer.
Testing
Testing av RPA -automatiseringer lider av den samme utfordringen som IT-utvikling har møtt i flere tiår: evnen til å (a) kjenne til alle mulige prosessbaner og datatyper, og deretter (b) faktisk teste dem for å se hva som skjer. For å gjøre dette effektivt for store, komplekse automatiseringer, må RPA-teamet:
- Ha en dyp forståelse av applikasjonen(e) som brukes i automatiseringen. Dette inkluderer hvordan applikasjonene fungerer, hva skjermflytene er, og hvilke meldinger som kan og vises med forskjellige (potensielt feilaktige) input. Dette er uvurderlig å vite når du begynner å registrere robothandlinger gjennom flere scenarier.
- Ansett et bredt team på flere personer til testing. Å ha teammedlemmer som er forskjellige fra utviklerne som utfører testingen av automatiseringene vil bidra til å identifisere og avdekke scenarier og problemer i god tid før man snubler over dem i produksjonen. Dette nivået av disiplin fører til resultater av høyere kvalitet og unngår potensielt tap av tillit som kan oppstå hvis det ses for mange unntak etter utrulling.
Infrastruktur
Et punkt som nesten aldri diskuteres før implementering av robotisert prosessautomatisering, og som også er årsaken til betydelige utfordringer, er den underliggende infrastrukturen som robotene kjører på. Bedriftsnettverk og systemoppsett kan lett være flere tiår gamle og, enda viktigere, tatt for gitt. Å ikke invitere teamene som forstår disse til bordet for RPA-diskusjoner fører ofte til problemer senere med de underliggende serverne, nettverkene og applikasjonene som RPA bruker. For å lykkes må bedrifter tenke på følgende:
- Skal RPA-roboten din kjøre på en fysisk datamaskin som står på et skrivebord eller på en virtuell datamaskin i skyen? Uansett hvor den kjører, hvem vedlikeholder den teknisk sett? Hvem laster ned oppdateringer og holder den i gang? Hvem setter opp brukerkontoen for roboten og tilbakestiller passordene om nødvendig? Hvis den kjører et annet sted enn vanlige ansattes skrivebord (for eksempel en virtuell maskin i skyen), kan den i det hele tatt koble seg sikkert til alle applikasjonene som brukerne vanligvis har tilgang til? På grunn av variasjonen i jobbene sine, trenger en robot ofte tilgang til flere bedriftsapplikasjoner enn noen annen enkeltbruker måtte trenge.
- Er nettverks- og infrastrukturteamene dine forberedt på å sette opp og vedlikeholde VM-serverfarmer for robotene? Hvem håndterer et driftsavbrudd? Hva om driftsavbruddet er unikt for robotene? Hvem vedlikeholder RPA-serverne? Hvem analyserer nettverkskommunikasjonen for å sikre at den fungerer som den skal?
- Hvem setter opp, eier og vedlikeholder sikkerhetstilgangen og påloggingsinformasjonen for robotene til alle bedriftsapplikasjonene de har tilgang til? Hvem sørger for at robotene bare har minimalt nødvendig tilgang, ettersom det å gi full tilgang er enkelt ... men usikkert?
En av RPAs største styrker er den lave inngangsbarrieren. Det kan være lett å forstå, slik at sluttbrukere kan opprette en innledende automatisering relativt enkelt. Men uttrykket «djevelen ligger i detaljene» er sant. Hvis organisasjonen din ønsker effektive, skalerbare og vedlikeholdbare automatiseringer, må du ikke gå glipp av behovet for å opprette støttestrukturer og team rundt RPA. Det er ofte mer arbeid enn først antatt, men hvis det gjøres riktig, kan det føre til store besparelser på automatisering. Klikk her for mer informasjon om robotisert prosessautomatisering.
Australia
Canada
Danmark
Frankrike
Tyskland
Hellas
Irland
Nederland
New Zealand
Norge
Spania og Portugal
Storbritannia
USA