Robot.

Hoe richt je de ideale robot workforce in

Zes tips voor Robotic Process Automation.

Robot. © Flickr/Creative Commons Chris Isherwood
26 september 2017

Zes tips voor Robotic Process Automation.

Robotic Process Automation, de inzet van software die 'toetsenbordtaken' van mensen overneemt, is sterk in opmars. Vooral in backoffices, en als het daar bevalt, al gauw ook in datacenters. Alleen zijn de best practices nog niet uitgekristalliseerd.

Dom herhalend toetsenbord- en beeldschermwerk komt nog altijd heel veel voor. Virtuele robots kunnen kantoorwerkers het 'domme' werk uit handen nemen. Robotic Process Automation, of kortweg RPA, heet dat.

Heel erg hightech is RPA niet eens. Anders dan bij robotics in het frontoffice komt aan process robotics in backoffices nauwelijks machine learning of cognitive computing te pas. Veeleer gaat het om veredelde scripting in combinatie met een krachtige trucendoos om lees- en schrijftoegang te krijgen tot data en applicaties, die nooit werden ontworpen om door iets anders dan mensen te worden gebruikt.

Niet alleen zijn de virtuele procesrobots sneller, goedkoper en trefzekerder dan menselijke werknemers, vaak zijn ze ook dé manier om in een vloek en een zucht procesveranderingen door te voeren die normaliter kostbaar en tijdrovend functioneel applicatieonderhoud zouden vergen. Businesscases voor procesrobotica zijn doorgaans snel gemaakt. Maar dat betekent allerminst dat RPA vanuit IT-perspectief probleemloos is. Wat rondvragen bij kenners leverde een zestal potentiële valkuilen op.

1. RPA als alternatief voor functioneel applicatieonderhoud

Process robots worden ingezet om te doen wat bedrijfsapplicaties eigenlijk zouden moeten kunnen doen. We zijn gewend dat de eindgebruikers dat dan maar moeten oplossen. Het is natuurlijk beter en voordeliger om dat ondankbare werk te laten klaren door robots. Maar het is en blijft natuurlijk een plan-B. Idealiter doen je bedrijfsapplicaties alles waar geen mens aan te pas hoef te komen. Elke andere oplossing is feitelijk een bestendiging van een functioneel gebrek, oftewel application backlog.

Vaak wordt voor robotics geopteerd met het argument dat het aanpassen van de bedrijfsapplicaties duur en tijdrovend is. Chris Vinke (Capgemini) plaatst vraagtekens bij die redenatie: "Aanpassen van applicaties vergt inderdaad maanden en soms zelfs jaren, terwijl de meeste RPA-oplossingen in 8 tot 12 weken zijn te realiseren. Maar je moet oppassen dat RPA geen trucje wordt om je legacy-uitdaging uit de weg te gaan. Voor je het weet groeit je RPA-gebruik zodanig dat je RPA je nieuwe legacy wordt. Bovenop die niet te onderhouden applicaties."

Vinkes concullega Wobke Hählen (Deloitte) ziet zo nu en dan zelfs RPA-plannen voor procesproblemen die ook met standaardsoftware op te lossen zouden zijn: "Zeker in tax and finance doen zich allerlei kleine handmatige processen voor, waarvoor inmiddels vaak standaard software-oplossingen beschikbaar zijn, meestal als 'bolt-ons' op SAP, HFM of een andere financiële omgeving. Als je dat niet weet dan ben je wellicht geneigd zoiets met robotica aan te pakken. Wij adviseren in die gevallen de bolt-on, omdat daar al standaard tax-datamodellen en -knowledge in zit en die ook (door de leverancier) up-to-date wordt gehouden."

2. Suboptimale processen robotiseren

Het gevaar bestaat dat je problemen in processen begraaft onder een nieuwe legacy van RPA-scripts, in plaats van ze op te lossen. Eén van de stappen die maar al te makkelijk wordt overgeslagen is het kritisch onderzoeken van de bedrijfsprocessen, die veelal niet bepaald zijn vormgegeven met wendbaarheid als eerste doel.

Zo is het bijvoorbeeld van belang er bij stil te staan dat optimaal voor robots best weleens anders kan zijn dan optimaal voor menselijke gebruikers. "Veel processen bevatten stappen waarvoor judgement nodig is. Bij menselijke procesuitvoering mogen zulke stappen gewoon zitten waar ze zich aandienen. Maar als een robot zo'n proces moet uitvoeren, dan heb je stappen die menselijk tussenkomst vergen liefst helemaal vooraan of achteraan in het proces”, geeft Hählen als voorbeeld, “en als het even kan ook bij elkaar gegroepeerd, zodat die menselijk tussenkomst eenmalig is en het proces niet verder ophoudt."

Ook het scheiden van processtromen voor makkelijke en ingewikkelde cases kan door inzet van RPA onnodig worden; want met robots wordt opeens alles snel en makkelijk. Dit inzicht is met name van belang omdat RPA in beginsel alleen seriële processen automatiseert. "Waar afstemming tussen parallelle processen wordt gewenst, is een orchestration tool de geëigende oplossing. In de praktijk gaan orchestration en RPA vaak samen, vandaar dat de meeste RPA-leveranciers ook wel oplossingen voor orchestration in hun programma voeren. Maar die zijn als regel functioneel minder rijk dan de orchestration tools van gespecialiseerde leveranciers, zoals Cortex (voorheen Innovise)", merkt Vinke op.

3. Wildgroei van robotica

Een robotrisico waar Alex Van den Bergh (Quint Wellington Redwood) voor waarschuwt, is verrommeling van de inzet van robots. "Ze inzetten als een snelle oplossing voor de laatste losse eindjes van procesautomatisering ontaardt al gauw in een soort legacy 2.0: ongedocumenteerd en ondoorgrondelijk."

Van de Bergh pleit er daarom voor RPA niet anders te behandelen dan applicatieontwikkeling en -onderhoud:

    1. Behandel de robot als software en volg ook de daarbij behorende test- en acceptatieprocessen. Zo zal je ook niet-functionele checks doen om te zien of de robot het IT-landschap niet bovenmatig vervuilt.
    2. Implementeer een strategie die een bewuste afweging tussen de inzet van een robot of verdere automatisering van de bestaande systemen afdwingt. Soms is het interessanter de automatisering van taken niet in de robot maar in de gewone IT-applicaties in te bouwen.
    3. Neem robots op in de architectuur van je IT-landschap; zo onderken je eerder of de inzet van robots uit de hand loopt.

Hählen is het daarmee niet oneens, maar plaatst wel een kanttekening. "Je kiest voor RPA omdat het flexibel is; dan moet je de governance niet te rigide inkleden. Zoek een evenwicht tussen agility en governance."

 

4. Service-provider lock-in

Enigszins aanpalend aan het gevaar van verrommeling is er nog robotbeheerprobleem: de applicaties waar de robots gebruik van maken zijn meestal geen statisch gegeven. Er komen zo nu en dan nieuwe versies uit. Robots kunnen daar helemaal door van slag van raken. Er is dus ook op de robot-scrips functioneel en technisch onderhoud, changemanagement en testen nodig. Voor de activiteiten zullen de 'werkgevers' van de robots al gauw afhankelijk blijken van hun robot-implementatiepartner. Vooral als er sprake is van agile of DevOps applicatieonderhoud, of als de robots meerdere applicaties gebruiken die niet steeds in sync worden geüpdatet, kan dat leiden tot een gestaag voortgaande stroom aan facturen van de betreffende robotica-dienstverlener.

"Het probleem is dat de robots vaak geen expliciet onderdeel van de outsourcingcontracten zijn”, zegt Van de Bergh. “Ze zijn vaak een onbenoemd gevolg van eisen die de klant stelt; eisen zoals een verplichte jaarlijkse verbetering van de efficiëntie. En als er niets is afgesproken, dan is dus er ook niets geregeld over overdracht van technologie en documentatie bij beëindiging van een outsourcingrelatie." Van de Bergh adviseert om het gevaar van de robotic vendor lock-in te mitigeren door:

    1. Maak afspraken over het gebruik van robots na aflopen van het overkoepelende outsourcing-contract. Spreek expliciet af dat de robots ook door een concurrent van de leverancier mogen worden aangepast.
    2. Zorg net als bij software dat de functionele eigenschappen van de robot goed zijn gedocumenteerd en spreek een exit-plan af met de leverancier, waarin deze zich onder meer verplicht tot het overdragen van de kennis die nodig is om eventueel een vervangende robot (of andere oplossing) te ontwikkelen. Stopt de relatie, dan is de leverancier verplicht enige tijd mee te werken aan het implementeren van een alternatief.
    3. De leverancier moet opdrachtgever op de hoogte brengen van de te robotiseren aspecten van het werk. In veel gevallen kan het voor de opdrachtgever interessanter zijn de taak-automatisering niet in een robot maar in de reguliere IT-applicaties in te bouwen.

5. Technology lock-in

Nee, de valkuil hier lijkt niet de lock-in zelf, maar het je er op blindstaren. RPA is een jong domein, waar dus veel aanbieders in de markt actief zijn en een verkeerde keuze snel gemaakt is. Vaak is het ook niet goed voorspelbaar welke leverancier de meest vruchtbare aanpak volgt in het licht van toekomstige innovaties, zoals toevoeging van cognitieve functionaliteit.

Achteraf minder gelukkige keuzes resulteren bij grootschalige bedrijfsimplementaties vaak nog decennialang als een blok aan het been. Maar bij RPA zou je je daar wat minder zorgen over moeten maken, vindt Hählen. "De terugverdientijd op RPA is doorgaans zo kort dat het ook wel acceptabel is dat je het ook relatief snel moet vervangen door iets wat je dan weer nog meer voordeel oplevert. Ik zie de licentietarieven voor deze technologie de laatste jaren snel dalen. En ook de kosten voor het inrichten vallen als regel enorm mee, mede doordat de ontwikkelomgevingen en de beheertooling steeds beter worden."

6 - Weerstand

Het zijn niet alleen de vakbonden en de politiek die zich zorgen maken over gevolgen die RPA kan hebben voor de werkgelegenheid. Oprichter Erik van der Leest van RPA-specialist Bluepond worstelt er al jaren mee dat ook het middelmanagement in organisaties vaak zeer terughoudend reageert. "Directies vinden het meestal supergaaf als je uitlegt wat er met onze robots allemaal mogelijk is en welke productiviteitseffecten ze mogen verwachten. Maar als je dan een follow-up krijgt, om samen met het operationeel management te onderzoeken waar inzet van RPA binnen hun afdelingen interessant zou kunnen zijn, dan is er opeens vooral aandacht voor de eventuele beperkingen. Vaak luidt de reactie in eerste instantie iets in de trant van 'interessant, we komen erop terug'. Maar in de praktijk komt dat laatste er meestal niet van.” In antwoord op de vraag hoe met deze weerstand om te gaan, windt Van der Leest er geen doekjes om: "Terug naar de directie."

Voor dit artikel werd gesproken met:
  • Erik van der Leest, ceo-oprichter Bluepond
  • Chris Vinke, business analyst bij Capgemini
  • Wobke Hählen, Tax lead Robotics Process Automation bij Deloitte
  • Kees-Wim van den Herik, Operational Excellence Director bij Deloitte
  • Derk Jan Brand, managing director Benelux&Nordics voor Pegasystems
  • Alex van den Bergh, managing partner bij Quint Wellington Redwood
Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.