Mythe 3: Voortdurende wijzigingen aan de user-interface leiden tot hoge maintenance kosten voor RPA-scripts

RPA maintenance kosten

De vorige bijdrage (mythe 2) toont aan dat het lanceren van een Robotic Process Automation (RPA) traject alvast geen fortuinen hoeft te kosten aan software en infrastructuur.  In deze post gaan we één van de hardnekkigste mythes te lijf, namelijk dat RPA-scripts enorm kwetsbaar zouden zijn.  Met name wijzigingen aan de user interface van toepassingen waarmee de bots werken, zouden leiden tot massaal falende scripts en een hoop re-work.

Waar komt deze stelling vandaan?

Zodra je op zoek gaat naar de zwakke punten van RPA, duikt deze boodschap steeds weer op, in nauwelijks gewijzigde vorm en zonder bijkomende verduidelijking of voorbeeld.  Vaak ook uit een niet-onbevooroordeelde hoek.  Reden genoeg dus om deze stelling even grondig te evalueren.

Voortdurende wijzigingen aan de user-interface?

Eerst misschien even kijken naar de “voortdurende wijzigingen aan de user-interface”.  In de praktijk blijkt dit nogal mee te vallen.  Wijzigingen die enkel de user-interface betreffen, komen in onze ervaring niet zo frequent voor.  De businesscase om enkel aan de user-interface te sleutelen is immers heel beperkt.  Het verhaal verandert natuurlijk als ook de functionaliteiten een stevige make-over krijgen, maar dan moet het ganse omliggende IT-landschap grondig nagekeken worden, niet enkel de RPA scripts.  Om van opleiding voor de menselijke gebruikers nog maar te zwijgen.  We kunnen zelfs nog een stap verder gaan.  Als het in belangrijke mate bots zijn die met de oude, bestaande applicaties aan de slag zijn, waarom dan sowieso de user-interface nog aanpassen?  De bots hebben geen last van oude, weinig gebruiksvriendelijke interfaces…

Welke oplossingen biedt de RPA-software zelf?

We willen er ons echter niet zo makkelijk vanaf maken.  Wijzigingen aan de user-interface komen voor, zeker in toepassingen waartoe ook de eindklant toegang heeft, en waar marketing en branding dus een belangrijke rol spelen.  Wel, het goede nieuws is dat bots prima overweg kunnen met veranderingen van plaats, kleur, label, … bijvoorbeeld voor toepassingen die via een browser benaderd worden.  Professioneel gebouwde bots “kijken” immers niet enkel naar het scherm, maar “lezen” ook de achterliggende code, en gaan zo op zoek naar de informatie die nodig is om hun taak uit te voeren.  De evolutie naar SAAS- en Cloud-toepassingen maakt dat dit voor steeds meer applicaties mogelijk is.

Er is echter meer dat de robuustheid ten goede komt.  Voor een belangrijk aantal toepassingen, hebben de meest voorkomende RPA-paketten connectoren voorhanden.  Die bevinden zich in de standaard activiteiten (bijvoorbeeld voor de Office producten), of als extra in de zogenaamde bot-stores (bijvoorbeeld voor Salesforce).  Deze connectoren werken niet op het niveau van de user-interface, maar interageren op een dieperliggend niveau.

Uiteraard blijven er toepassingen waarvoor de bot enkel afhankelijk is van scherm-informatie.  Neem bijvoorbeeld de oude mainframes die, zeker in grotere organisaties, nog frequent opduiken.  Zodra daar wijzigingen op schermniveau gebeuren, zal een aanpassing van het bot-script zich inderdaad opdringen.  Echter, hiermee kom ik terug tot het eerste punt: hoe vaak worden deze toepassingen nog gewijzigd?

Wat is de impact van de mogelijke aanpassingen?

En nog willen we er ons niet te makkelijk vanaf maken.  Wijzigingen komen voor, de robuustheid van zelfs de meest professioneel gebouwde bots lost niet alles op, en een falende bot betekent falende processen, misnoegde klanten en gestresseerde medewerkers.  Wel, nu komen we dus bij de zogenaamd hoge maintenance kosten.  Twee elementen zijn van belang: het tijdstip van de interventie en de kost of duurtijd van de interventie zelf.

Wat betreft de timing van de interventie, kan heel wat onheil voorkomen worden door een goed release-management, zoals dat ook voor andere applicaties geldt.  Het is zaak om bij elke upgrade van het IT-landschap het bot-script ook in de testomgeving te laten draaien, voordat de nieuwe release in productie komt.  De bot scripts zouden met andere woorden integraal deel moeten uitmaken van de regressie-testen.  Zo vermijd je problemen in de productieomgeving.  Mogelijke ergernissen van klanten en medewerkers zijn daarmee alvast van de baan.

Een tweede belangrijk element zijn natuurlijk de kosten van de wijziging zelf.  Wel, weet dat het bouwen van een script zo’n 3 à 5 weken in beslag neemt (voor meer details over de kostprijs van een script kan je gebruik maken van onze kostencalculator).  Aanpassingen naderhand duren uiteraard slechts een fractie van de tijd.  Op één werkdag kunnen er al enorm veel aanpassingen gebeuren.  De stelling dat de maintenance kosten voor RPA hoger zouden liggen dat voor klassieke ontwikkelingen, is moeilijk hard te maken.

Conclusie

Met die hoge maintenance kosten valt het dus wel mee.  Het tempo van de wijzigingen aan onderliggende systemen licht vaak minder hoog dan gedacht.  Goed gebouwde bots zijn ook robuust, en kunnen dus wel wat wijzigingen aan.  Tenslotte is het bouwen van scripts al bij al geen dure aangelegenheid, het aanbrengen van wijzigingen dus al helemaal niet.