RPA-implementering
RPA-implementering
Implementering
Implementering
Et succesfuldt RPA-projekt kan levere en win-win-win: Kunderne får nye produkter hurtigere, organisationen får effektiviseret sine processer så den kan reagere hurtigere i forhold til markedet, og medarbejderne kan slippe for det kedelige, rutinearbejde og koncentrere sig om de opgaver, der gør deres arbejde interessant.
Den vigtigste faldgrube at undgå er, at et RPA-projekt ikke må behandles som et IT-projekt. Softwarerobotterne arbejder for forretningen. De repræsenterer en enterprise capability og skal behandles som en sådan – ikke som et lokalt desktopautomatiseringsværktøj.
Proof of Concept (PoC) handler om så tidligt som muligt, og så billigt som muligt, at kunne fremvise noget, der virker og kan bevise sin holdbarhed. Et RPA Proof of Concept er et mindre projekt med det formål, at bevise RPA-værktøjernes praktiske anvendelighed i organisationen. Dette sker ved, at et stykke RPA-software benyttes til at automatisere en del af en proces. Løsningen udvikles ikke til at være operationel.
Tendensen inden for RPA-implementeringer er, at organisationerne starter blødt op med et mindre projekt i form af enten en Proof of Concept (PoC) eller et pilotprojekt. Disse udvides løbende i takt med, at der opnås gode resultater samt accept af at teknologien bliver mere udbredt i organisationerne. Nogle vælger at starte stille op med en PoC og videreudvikler derefter løsningen i en pilot, hvor andre kaster sig direkte ud i et pilotprojekt.
En pilot er meget lig en Proof of concept (PoC), men vil have et større scope. Derudover vil en pilot-løsning være operationel, og den kan sættes i drift for at teste den egentlige indflydelse på organisationen, hvilket ikke gør sig gældende for en PoC.
Formålet med et pilotprojekt er at give organisationen nogle vigtige erfaringer med, hvor og hvordan RPA giver mest mening at implementere, inden det eventuelt bliver foldet ud i en større skala. Via pilotprojektet får organisationen bedre indsigt i RPA potentialet og muligheder.
For at kunne vælge det bedste grundlag for de rette automatiseringsinitiativer, så skal organisationen først kunne svare på følgende spørgsmål:
Hvordan ser vores tværgående arbejdsgange ud?
Hvilken rolle udfører opgaverne i hver proces?
Hvordan udføres hver opgave trin for trin?
Hvilke systemer bruges? (systemlandskab og samspil mellem de forskellige systemer)
Har vi fjernet unødige trin og opgaver fra hver aktivitet og proces?
Hvordan vil vi overvåge og optimere processen, efter den er blevet automatiseret?
Når der er svaret på de seks spørgsmål, så har organisationen et klart defineret grundlag til at finde egnede arbejdsgange, der kan automatiseres.
Overordnet set, så er en proces egnet til RPA, hvis følgende forhold er til stede:
Hele eller dele af processen er meget manuel og gentagende.
Tidsbelastningen – Processer medarbejderen bruger meget tid på.
Regel baseret proces (Hvis A, så B, eller C)
Lav grad af undtagelser.
Høj volumen af gentagelser – Dagligt, ugentligt eller månedligt.
Data flyttes i eller på tværs af programmer.
Men der er også andre faktorer, der spiller ind fx datatyper, systemer, IT-opgraderingsplaner, besparelse af ressourcer.
Ved at identificere områder, som kræver menneskelig handling kan afgøres, hvor automatisering kan bidrage til at strømline workflows og øge produktiviteten.
Eksempler:
Manuel indtastning af data i systemer, hvor der kan opstå menneskelige fejl.
Indsamling af data til fremstilling af rapporter.
Områder som underperformer fx indenfor kundeservice eller andre områder i organisationens værdikæde.
Områder hvor 'stive systemer' skaber flaskehalse. Det kan fx være et kombination af gamle og nye systemer, overlappende eller dublette systemer (ERP, CRM og andre systemer).
Forretningsprocesser som ikke kan udbygges uden, at der skal ansætte flere medarbejdere.
Manuelle processer med lave kvalifikationskrav som fjerner fokus fra strategisk vigtige opgaver med store faglige krav til de ansatte.
Områder som organisationen overvejer at outsource, men ønsker at beholde in-house.
På baggrund af foranalysen foretages følgende handlinger og udvælgelse:
Er denne proces klar til RPA eller skal der først ske en optimering?
Er der en forventning om 100% automatisering af processen?
Hvor kritisk er processen ift. implementering her og nu eller kan den vente til senere?
Der udvælges 2 eller 3 simple processer til piloten. Anbefalingen er, at der skal startes med processer uden for mange undtagelser og komplekse regler.
Udvælgelse og prioriteringen kan foretages ud fra flere kriterier:
Værdien? – Effekt potentiale (antal transaktioner, samlet tidsbesparelse)
Er processen egnet? – Struktureret og regelbaseret.
Strategisk? – Hvor vigtigt er det at processens kvalitet sikres.
Ud fra disse kriterier vælges der, hvilke processer som skal detailbeskrives.
Efter udvælgelsen af processer skal der ske en kortlægning af den nuværende proces samt udformningen af den automatiserede proces. Dette skal ske ved inddragelse af nøglepersoner for at sikre medindflydelse og højere kvalitet.
Udarbejdelse af detailbeskrivelse af den nuværende proces
Overordnet beskrivelse.
Proces diagram.
Evt. video dokumentation.
Hvem ejer processen?
Hvad udfører den fra start til slut?
Er den dokumenteret?
Er processen opdateret?
Udformningen af den automatiserede proces
Er der mulighed for en forbedring af processen?
Er der mulighed for en udvidelse af processen?
På baggrund af forløbet af pilotprojektet skal der foretages en evaluering.
Blev målsætningerne indfriet? (frigivelse af tid, forbedret kvalitet etc.)
Blev der opnået en tilfredsstillende automatiseringsgrad?
Levede RPA-softwaren op til forventningerne?
Efter de indhøstede erfaringer fra PoC/Pilotprojekt er organisationen nu i stand til at udarbejde en plan for den videre implementering og skalering af RPA på tværs af organisationen. Transformations-processen skal håndteres korrekt ved at have fokus på forandringsledelse og de berørte ansatte.
Det er meget vigtigt at have en end-to-end tilgang til processerne på tværs af organisationen, og samtidig sørge for, at processerne er standardiserede og optimeret til RPA. Det er nødvendigt at få etableret RPA som en naturlig del af organisationens driftsmodel ved at etablere en governance-struktur, der passer til organisationens behov.
Hvad er målsætningerne for RPA-initiativet ift. skalering?
Eksempler på RPA-målsætninger:
Antal automatiserede processer.
Gevinster.
Kvalitet.
m.fl.
På baggrund af målsætningerne udarbejdes et roadmap..
Normen er, at der oprettes et RPA Centre of Excellence (CoE) i forbindelse med skaleringen af et RPA-initiativ. I generelle termer er et CoE en enhed, der bl.a. tilbyder best practice, ledelse, support og træning inden for et bestemt område.
Et CoE kan være ansvarlig for:
At styre drift og lede RPA-initiativet.
RPA-initiativet bliver ledet fra CoE, og det er her, det besluttes, hvordan RPA skal driftes. Der vil også være RPA-medarbejdere lokaliseret i CoE, som driver udrulningen og implementeringen af RPA, såsom projektledere, forretningsanalytikere samt RPA-proceskonsulenter og -udviklere.
At sikre kvalitet.
Gennem veldefinerede standarder, procedurer og retningslinjer, ejet og udviklet af CoE, sikrer organisationen sig en høj kvalitet af RPA-løsninger.
At prioritere
CoE hjælper organisationen med at prioritere processer med automatiseringspotentiale. Nogle organisationer kan benytte sig af en gatekeeperfunktion i CoE, som godkender alle automatiseringer, før de sættes i produktion. Dette gør det også muligt for CoE at vurdere, hvorvidt RPA er det rette værktøj at bruge til optimering af processen, eller om andre it-løsninger vil være mere brugbare.
At udvikle talent.
CoE styrer træning og oplæring af medarbejdere i RPA.
At kommunikere med interessenter.
En koordineret kommunikationsindsats bliver ofte drevet af CoE.
At sikre compliance.
CoE sikrer, at alle robotter og processer overholder alle retningslinjer, udstedt af compliance og sikkerhed.
Til CoE er der behov for RPA-proceskonsulenter og RPA-udviklere.
RPA-proceskonsulenten skal identificere og optimere processer og sikre fremdrift i RPA projektet. Det er typisk nøglepersoner med procesforståelse, projektledelse og interne konsulenter.
RPA-udvikleren skal udvikle og drifte softwarerobotter i organisationen og har typisk en god logisk og teknisk forståelse.
At indføre RPA åbner generelt op for en snak omkring etablering af en governance struktur, som passer til organisationens behov. Der skal være fokus på en agil tilgang, så skiftende behov i egen organisation, kunder, leverandører m.m. hurtigt kan tilpasses robotterne.
Typisk starter et RPA-initiativ lokalt, hvor værktøjet installeres på en medarbejders pc og begynder at automatisere sine egne opgaver. Her er det brugerens eksisterende rettigheder, der styrer adgange til eksisterende systemer (AD-adgange).
Næste trin er, at den samme person bygger robotter til kolleger fra andre afdelinger i organisationen, når de får kendskab til muligheden for at automatisere manuelle arbejdsopgaver. Det er en helt naturlig udvikling, at flere medarbejdere får adgang til at bygge robotter. Det giver mulighed for, at der er flere som er i stand til at redigere og udvikle robotter på tværs af organisationen.
Jo mere udbredt RPA bliver, jo større incitament er der til at overveje governance vedrørende RPA. Der skal være styr på og enighed om:
Hvad de kan.
Hvad de skal.
Hvad de må.
Hvem der laver hvad.
Hvem der har adgange.
Hvem der bruger kapaciteten.
Hvornår der køres automatiseringer.