Waarom mislukken RPA-projecten?

RPA-projecten mislukken meestal niet door de software zelf, maar door keuzes vooraf en door beheer achteraf. Het verkeerde proces wordt gekozen, afwijkingen zijn niet uitgewerkt, niemand houdt de robot in de gaten of is eigenaar, en de besparing is bruto berekend. Zulke oorzaken zijn meestal vóór de start te herkennen. Veel ervan zijn met eenvoudige afspraken te voorkomen.

Wat "mislukken" betekent

Een software-robot (RPA, robotic process automation) is software die schermhandelingen van een medewerker overneemt: inloggen, gegevens opzoeken, velden invullen. Hij is geen industriële robot en stuurt geen machines of PLC's (machinebesturingen) aan. Een robotproject kan op vier manieren mislukken:

• De robot gaat nooit live, omdat het proces moeilijker blijkt dan gedacht.
• De robot draait, maar valt zo vaak stil dat medewerkers het werk weer zelf doen.
• De robot draait betrouwbaar, maar levert veel minder op dan beloofd.
• De robot wordt na een jaar uitgezet, omdat niemand hem onderhoudt.

Hoe vaak gaat het mis?

Het veelgenoemde cijfer is dat 30 tot 50 procent van de eerste RPA-projecten mislukt. Het komt uit een paper van adviesbureau EY uit 2016. Het is een waarneming uit de eigen adviespraktijk van EY, vooral in de financiële sector, geen onderzoek met een beschreven steekproef of methode. EY schrijft ook dat het vaak wordt ingeschakeld als een eerste poging is mislukt, en het verkoopt zelf RPA-advies. Volgens EY zegt het cijfer niets over de techniek zelf.

Een wetenschappelijk artikel uit 2024 noemt hetzelfde cijfer alleen "volgens sommige bronnen". Het concludeert wel dat niet-technische factoren bij RPA-projecten zwaarder wegen dan technische. Gebruik het getal dus als signaal, niet als meting. De oorzaken zijn nuttiger dan het percentage.

Het voorbeeld: twee versies van hetzelfde project

De tien oorzaken in één overzicht

1. Het verkeerde proces

Een robot past bij werk dat vaak voorkomt, vaste regels volgt en digitaal binnenkomt. Hij past slecht bij werk dat weinig voorkomt, vaak verandert of bij elke beurt een oordeel vraagt. Toch kiezen bedrijven het eerste proces soms omdat iemand er last van heeft, niet omdat het geschikt is. EY noemt het kiezen van de verkeerde processen als een van de veelgemaakte fouten.

Voorkomen: meet voordat u kiest. Tel een paar weken hoe vaak het werk voorkomt, hoeveel gevallen afwijken en hoe vaak de regels of schermen de afgelopen tijd veranderden. Een proces met een laag volume, of met veel uitzonderingen die per geval interpretatie vragen, is meestal geen goede kandidaat. Veel uitzonderingen met een vaste regel zijn geen bezwaar. Meer signalen staan in wanneer u een proces beter niet automatiseert.

2. Een slecht proces automatiseren

Een robot doet precies wat het proces voorschrijft, ook de onnodige stappen. Wordt een order nu geprint, afgetekend en weer ingescand, dan bouwt u die omweg in software na. Een dubbele controle die ooit is ingevoerd na één incident, wordt ineens een vaste stap in de robot.

Voorkomen: teken het proces eerst uit, stap voor stap, met de mensen die het werk doen. Vraag bij elke stap waarom hij bestaat. Schrap wat niets toevoegt en maak de rest eenduidig. Soms is het proces daarna zo eenvoudig dat een standaardfunctie van het ERP volstaat.

3. Afwijkingen onderschat

De gewone order is snel gebouwd. Het werk zit in de uitzonderingen: een klant die zijn eigen artikelnummers gebruikt, een order verdeeld over twee mails, een correctie op een eerdere order, een order op een tekeningrevisie die niet meer geldt, een prijs die net anders is. Wie alleen de gewone order ontwerpt, krijgt een robot die in de praktijk steeds vastloopt.

Voorkomen: verzamel vóór het bouwen een flinke set echte voorbeelden, bijvoorbeeld een maand aan orders. Noteer elke afwijking en de reden. Besluit per soort afwijking: verwerkt de robot hem zelf, gaat hij naar een medewerker, of wordt hij geweigerd? Een afwijking die naar een medewerker gaat, komt in een werkbak met de reden erbij. In UiPath kan dat bijvoorbeeld een taak in Action Center (het onderdeel van UiPath waar een medewerker taken afhandelt) zijn: de robot wacht tot een mens de taak heeft afgehandeld en gaat dan verder.

4. Kwetsbare schermautomatisering

Een robot die schermen bedient, is afhankelijk van die schermen. Een update van het ERP verplaatst een veld, een nieuwe melding verschijnt, het portaal van een klant krijgt een nieuwe opmaak. Een medewerker past zich direct aan. Een robot stopt, of klikt op de verkeerde plek. Let extra op als de robot een toepassing alleen als beeld ziet, bijvoorbeeld via een extern bureaublad. Dan kan hij velden niet aan hun technische kenmerken herkennen.

Voorkomen:

• Gebruik een koppeling (API) of importfunctie als het systeem die biedt. Een koppeling is een vaste ingang voor software en verandert minder vaak dan een scherm. De afweging staat in RPA of API-koppeling: wat is de beste keuze?
• Laat de robot controleren of het juiste scherm er is voordat hij iets doet. In UiPath herhaalt de activiteit Retry Scope een reeks stappen tot een voorwaarde klopt, bijvoorbeeld tot een veld zichtbaar is.
• Spreek met IT of de leverancier af dat u vooraf hoort wanneer er een update komt. Test de robot na elke grote update, voordat hij weer met echte gegevens werkt.

5. Geen foutafhandeling of monitoring

Een robot zonder monitoring (iemand of iets dat de uitvoering in de gaten houdt en meldt) valt vaak stil zonder dat iemand het merkt. U merkt het pas als een klant belt over een order die nooit is aangemaakt. Een tweede valkuil is een robot die elke fout op dezelfde manier behandelt.

UiPath maakt een nuttig onderscheid tussen twee soorten fouten. Een technische fout ontstaat doordat een toepassing niet reageert of een veld niet te vinden is. Opnieuw proberen kan dan helpen. Een inhoudelijke fout ontstaat doordat gegevens onvolledig of onjuist zijn, zoals een telefoonnummer dat een cijfer mist. Opnieuw proberen heeft dan volgens UiPath geen zin. Orchestrator, het beheerplatform van UiPath, probeert zulke fouten standaard niet opnieuw. Hier moet een mens iets doen.

Voorkomen:

• Probeer technische fouten een beperkt aantal keren opnieuw. Stuur inhoudelijke fouten direct naar de werkbak.
• Stel meldingen in. In Orchestrator kunt u zich bijvoorbeeld abonneren op meldingen als een taak mislukt, of als een werkitem (één geval in de werkbak) mislukt door een technische of inhoudelijke fout.
• Controleer ook items die blijven hangen. Een werkitem dat ongeveer 24 uur "in behandeling" staat zonder klaar te komen, krijgt in Orchestrator de status Abandoned (verlaten).
• Gebruik een vangnet voor onverwachte fouten, zoals de Global Exception Handler in UiPath. Die bepaalt wat de robot dan doet: opnieuw proberen, de fout negeren of stoppen. Een vangnet vervangt geen doordachte afhandeling per stap.
• Maak een dagoverzicht: hoeveel gevallen verwerkt, hoeveel in de werkbak, hoeveel mislukt.

6. Geen eigenaar in de organisatie

Een robot wordt vaak gezien als iets van IT. Maar IT weet niet welke prijsafwijking acceptabel is of wanneer een order eerst langs engineering moet, en IT leegt de werkbak niet. Zonder eigenaar in de organisatie blijven beslissingen liggen. EY noemt RPA zien als een IT-project, in plaats van een initiatief van de organisatie zelf, als een veelgemaakte fout. Een nieuwe klant met een eigen orderformaat komt niet vanzelf in de regels terecht, en tijdens de vakantie van de enige medewerker die de werkbak kent, loopt die vol.

Voorkomen: benoem een proceseigenaar, iemand uit de afdeling die het werk doet. Die beslist over de regels, keurt wijzigingen goed en test ze. Benoem daarnaast een technisch beheerder. Leg vast wie hen vervangt bij ziekte en vakantie.

7. Inloggegevens en beveiliging

Een robot heeft toegang nodig tot systemen, soms tot veel systemen. Gebruikt hij het account van een medewerker, dan is achteraf niet te zien wie wat heeft gedaan. Wijzigt die medewerker zijn wachtwoord, dan stopt de robot. Staat het wachtwoord in de code of in een Excel-bestand, dan kan iedereen met toegang tot dat bestand het lezen.

Voorkomen:

• Geef elke robot een eigen account met alleen de rechten die hij nodig heeft. Een robot die orders invoert, hoeft geen stuklijsten te wijzigen of klanten te verwijderen.
• Bewaar wachtwoorden in een kluis, niet in de code. In UiPath Orchestrator staan inloggegevens als zogenoemde credential assets. De robot haalt ze pas tijdens het werk op met de activiteit Get Credential, die een gebruikersnaam en een beveiligd wachtwoord teruggeeft. Orchestrator kan ook externe kluizen gebruiken, zoals Azure Key Vault of HashiCorp Vault. Volgens UiPath kan dat alleen met een Enterprise-licentieplan.
• Vervang wachtwoorden op een vast moment, en leg vast wie wanneer welk wachtwoord heeft opgevraagd. Dat adviseert ook OWASP, een non-profitorganisatie voor softwarebeveiliging.
• Houd wachtwoorden en gevoelige gegevens uit de logboeken. Op het uitgebreidste logniveau (Verbose) legt UiPath ook de waarden van variabelen en argumenten vast. Gebruik dat niveau dus niet standaard in productie.

8. Geen testomgeving

Zonder testomgeving test u in het echte systeem. Dan maakt een fout in de robot echte orders aan, die misschien al in de planning van de werkvloer komen, of stuurt het ERP een bevestiging naar een echte klant. Uit angst daarvoor wordt er vaak te weinig getest, en komen de problemen pas na de livegang aan het licht.

Voorkomen: vraag uw ERP-leverancier naar een testomgeving en gebruik een aparte test-mailbox. Test met een representatieve set echte gevallen, inclusief de lastige. Ook testgegevens met namen en mailadressen vallen onder de privacywet (AVG), dus gebruik niet meer dan nodig. Is een testomgeving echt niet mogelijk, bouw dan een proefmodus in: de robot doet alles behalve het opslaan en schrijft op wat hij zou hebben gedaan. Een medewerker vergelijkt dat een paar dagen met haar eigen werk. Laat de proceseigenaar de test goedkeuren, niet alleen de bouwer.

9. Geen onderhoudsbudget

Een robot is geen eenmalige aankoop. Systemen krijgen updates, klanten veranderen hun formulieren, regels veranderen, licenties lopen door en iemand moet de meldingen opvolgen. Staat daar geen budget voor, dan wordt de eerste grote storing ook de laatste. Ook EY noemt het onderschatten van wat er na de livegang nodig is als veelgemaakte fout.

Voorkomen: begroot beheer per jaar, vanaf het begin. Zorg voor documentatie, zodat ook iemand anders de robot kan aanpassen. Wat onderhoud inhoudt en waar de kosten zitten, leest u in wat het onderhoud van een software-robot kost.

10. Bruto gerekende besparing

Veel businesscases tellen alle uren die het werk nu kost als besparing. Dat klopt niet. Afwijkingen blijven handwerk, en iemand moet de robot elke dag controleren. Daarnaast zijn ontwikkeling, licenties en onderhoud kosten, geen tijdwinst.

Aannames: 80 orders per werkdag, 4 minuten per order, 15 procent afwijkingen, 15 minuten controle per dag en 230 werkdagen per jaar.

In versie A van het voorbeeld rekent het bedrijf met 1.227 uur. Dat is ongeveer 242 uur per jaar meer dan er werkelijk vrijkomt, nog vóór de kosten. Na een jaar lijkt het project tegen te vallen, terwijl de robot doet wat hij moet doen. De belofte was te groot. Vrijgemaakte tijd levert bovendien alleen iets op als u bepaalt waaraan die tijd besteed wordt. Hoe u de terugverdientijd eerlijk berekent, leest u in wanneer automatisering rendabel is voor een klein bedrijf.

Hoe u een robotproject opzet

De aanpak bij de start bepaalt veel van het risico. Vier gangbare aanpakken naast elkaar:

Voor een klein of middelgroot bedrijf is één proces als proefproject meestal de verstandigste start. Kies dan wel een proces met echte afwijkingen, zodat het proefproject ook de lastige kant laat zien. Hoe u zo'n eerste proces invoert, staat in de gids bedrijfsprocessen automatiseren.

Besliskader: vragen vóór de start

Bespreek deze vragen intern voordat u een robot laat bouwen. Kunt u er een niet beantwoorden, dan weet u waar het risico zit.

1. Hoe vaak komt het werk voor, en hoeveel gevallen wijken af? Is dat gemeten of geschat?
2. Kan iemand de regels uitleggen, inclusief de uitzonderingen?
3. Verandert het proces of het systeem binnen een jaar?
4. Biedt het systeem een koppeling of import, of alleen schermen?
5. Wie is proceseigenaar, en wie vervangt die persoon?
6. Waar komen afwijkingen terecht, en wie handelt ze af?
7. Wie krijgt een melding als de robot stopt, en hoe snel moet die reageren?
8. Met welk account werkt de robot, en waar staan de wachtwoorden?
9. Waar wordt getest?
10. Rekent de businesscase met de werkelijk vrijgemaakte tijd, en is onderhoud begroot?

De zwaarste factoren zijn de proceskeuze, de afhandeling van afwijkingen en het eigenaarschap. Techniek is bijna altijd op te lossen. Een proces zonder eigenaar niet.

Externe hulp is zinvol als u nog geen ervaring hebt met robots, als de antwoorden op vraag 1 tot 4 onzeker zijn, of als u een onafhankelijke blik op de businesscase wilt. Een procesanalyse vooraf maakt de risico's zichtbaar. Voor robots die al draaien, gaat het vooral om beheer en ondersteuning.

Grenzen van deze aanpak

• Ook een goed opgezette robot blijft afhankelijk van andere systemen. Een storing bij de leverancier van een portaal kunt u niet voorkomen, alleen snel opmerken.
• Al deze maatregelen kosten tijd vóór de start. Voor een heel klein proces kan dat meer zijn dan het oplevert. Dat is dan een reden om niet te automatiseren.
• Stoppen na een proefproject is geen mislukking. Een proefproject dat laat zien dat het proces ongeschikt is, heeft zijn werk gedaan.

Conclusie

Een mislukt robotproject is zelden een verrassing achteraf. De signalen zijn er vooraf: een proces dat niemand kan uitleggen, afwijkingen die niemand heeft geteld, een robot zonder eigenaar en een besparing die te mooi is. Wie die tien vragen vóór de start eerlijk beantwoordt, voorkomt de meeste problemen, of besluit op tijd om niet te beginnen.

Bronnen

• UiPath Documentation: Business Exception vs Application Exception
• UiPath Documentation: Queue Item Statuses
• UiPath Documentation: Notifications (Orchestrator)
• UiPath Documentation: Logging Levels
• UiPath Documentation: Get Credential / Get Orchestrator Credential
• UiPath Documentation: Managing credential stores
• UiPath Documentation: Action types (Action Center)
• UiPath Documentation: Retry Scope
• UiPath Documentation: Global Exception Handler
• OWASP Cheat Sheet Series: Secrets Management
• EY (2016): Get ready for robots (pdf)
• Schlegel e.a. (2024): How to conduct successful business process automation projects? Business Process Management Journal