Fejlhåndtering


En af de klareste erfaringer jeg har gjort mig rollen som RPA-udvikler er at tænke fejlhåndtering ind i et RPA-projekt fra analyse til implementering og drift.

RPA-udviklere der kommer fra softwareudvikling over til RPA-udvikling, har indbygget i DNA’et at tænke fremad og forudse de fejl der opstår ved konkrete typer af softwareløsninger. Men for en person der, som jeg selv, er skolet i forretnings-IT, har det været en vigtig erfaring at lære hvordan typer af RPA-løsninger agerer når de kommer i drift.



Generelle overvejelser i forhold til fejlhåndtering
Der er en generelle række ting, der får kompleksiteten og derved chancen for at fejl til at stige i RPA-projekter. Man kan med fordel, i de indledende udviklingsstadier, overveje:
– Er der mange forskellige udfald i automatiseringen
– Er der mange variable og datatyper
– Hvordan fungerer stabiliteten af de anvendte systemer

For at imødekomme et projekt med potentiel kompleks fejlhåndtering, anvender vi i RPA House fire følgende actions.

Tænk dataformat
En af de primære ting er data input. Alle processeringsrobotter anvender en form for datainput og formatet hertil, samt omskifteligheden i den enkelte variabel er med til at afgøre hvor mange forretningsfejl man skal kunne håndtere i en løsning.
Et eksempel er data fra blanketter, som ikke er standardiseret til et fast dataformat. Det kunne være en kunde, der udfylder en dato i en blanket på en hjemmeside, som sidenhen, skal anvendes som input til automatiseringen. Hvis feltet godtager fritekst, vil kunder antageligvis ikke indtaste datoer i samme format hver gang. Lad os sige den relevante dato er 01/12/2021. Nogle vil kunder måske skrive ’1. december 2021’, mens andre skriver ’1/12/2021’, eller ’1-12-2021’.
Normalt vil man forsøge at fixe udfordringen ved kilden, altså låse feltet, ved hjælp af en datepicker, så kunden ikke selv vælger datoformat. Alternativt kan man låse feltet, altså så feltet kun godtager dd-MM-yyy eksempelvis.
En anden udfordring ved data input er tilfælde hvor der ikke eksisterer data i et felt, som skal anvendes. Her skal der vurderes om data inputtet er altafgørende, altså kan processen fortsætte uden den relevante data eller ikke. Skal processen stoppe, er det måske passende at en procesekspert orienteres om sagen.
 

General sikring

Hos RPA House anvender automatiseringsframeworks med indbygget håndtering af systemfejl og forretningsfejl(kendte fejl der skal håndteres, eksempelvis en bestemt type sag, der ikke skal behandles, men sendes til en process ekspert). Der skal altid bygges logik til håndtering af system- og forretningsfejl, specifikt til den enkelte proces. Dette imødekommes gennem REFramework, fra UiPath, der sørger for at robotten ikke skal genstartes, hvis der sker en forretningsfejl i forbindelse med en bestemt ’sag’. Derimod vil løsninger i dette framework, fortsætte til næste ’sag’. I tilfælde af systemfejl, kan det være nødvendigt at starte på ny, altså starte relevante programmer forfra, indlæse filer, indstillinger osv. Med REFramework kan vi løbe ind adskillige typer af fejl, men automatiseringen går aldrig i stå på baggrund af fejl. Systemfejlshåndtering er general, i den forstand, at der som regel sker det samme uanset, hvilken ukendt fejl robotten løber ind i. I forbindelse med forretningsfejl, kan der dog udvikles specifikke workflows til den type fejl. Det kan eksempelvis være der skal sendes en mail til en procesekspert, som kan tage stilling til sagen.


Kommunikér
Forsøg at komme i tanke om alle de særtilfælde, der kan opstå. Spørg proceseksperten ind til formatet på data input, kan det variere i specielle omstændigheder?. Udover dette, skal der bygges specifik logik til specielle omstændigheder?. Det forekommer ofte at der lavet dokumentation på en proces, men når man så kører testdata igennem med automatiseringen, opdager man at nogle udfald ikke er inkluderet i dokumentationen. Det skal man holde in mente, og give rum til at nogle delløsninger udvikles i kraft af kommunikation med en procesekspert. Men hvis man ikke spørger proceseksperten, når der forekommer usikkerheder i automatiseringens logik, løber man ind fejl i implementering/drift, der kunne være undgået, ved tættere kommunikation.

Hold fokus på produktion
Sidste punkt er et godt råd til udvikleren undervejs i udvikling, et råd der kan spare udvikleren for mange fejl i implementeringen af en løsning.

Fokusér hele tiden at løsningen skal i produktion. En ting man kan gøre, er at tidligt kigge på produktionssystemet og se om data er ens med testsystemet. Desuden er det en god idé, uden at køre løsningen, at gå ind og se i produktionssystemet, om automatiseringen kan interagere med elementerne på samme måde, både i testsystemet og produktionssystemet. På denne bliver implementeringen af en løsning mere fri for småfejl. Kig også gerne på hvordan load times og popups fungerer i produktionssystemet i forhold til testsystemet. Det kan være, at man bygger noget logik der venter på testsystemet eller klikker en popup mens man er i test. Hvis systemerne agerer ens, ved man som udvikler at man skal bruge noget tid på at sikre driftstabiliteten af denne logik.

Opsummering
Man lærer det henad vejen, men jeg håber for nogle at de kan bruge disse overvejelser i deres arbejde. Det er en fin kunstart at udvikle stabile løsninger, lave veludført dokumentation, samt kommunikere klart hele vejen.
Hvis man dog tænker over hvad man gør og hvorfor og kommunikere dette med sine tekniske kolleger, samt procesekspert, så skal det nok gå!

Skriv et svar