RPA

Voor RPA geldt gedeeltelijk hetzelfde. Het bestaat eigenlijk ook al jaren. Je zou kunnen stellen dat batchfiles in de tijd van MS-DOS (ik leerde het meer dan 25 jaar geleden al kennen) een soort hetzelfde zijn.

Menig systeembeheerder heeft zijn werk al die jaren veel gemakkelijker gemaakt door het maken van een batchfiles, kleine bestandjes waarin één of meerdere opdrachten achter elkaar werden gezet.

Zo was het bijvoorbeeld mogelijk om met één commando:

• een bestandje op te halen van een andere computer; 
• deze aan het einde van een ander bestand te plakken;
• dit nieuwe bestand vervolgens een andere naam te geven; en
• deze in een bepaalde directory te zetten.

Normaal zou een systeembeheerder hiervoor meerdere opdrachten in moeten voeren (verbinding starten, inloggen met een gebruikersnaam en wachtwoord, bestandsnamen invoeren, kopieeropdrachten uitvoeren, etc.) maar dit alles kon nu met slechts één commando worden gestart.

Fijn hieraan was dat dit kon zonder dat je echt een computerprogramma hoefde te maken. Je maakte gewoon een tekst-bestandje met daarin de commando’s achter elkaar. Het was zelfs mogelijk om hierin voorwaardelijk acties te laten kiezen op basis van waardes. De zogenaamde ‘ALS-DAN’ routines (voorbeeld: IF %day%==Zondag THEN backup).

Hebben we systeembeheerders dan al jaren te veel betaald? Persoonlijk vind ik natuurlijk van niet ;-). Een systeembeheerder is geen systeembeheerder omdat hij een muisklik kan zetten, maar vooral omdat hij weet wáár hij op welk moment moet klikken. Bij Batchfiles is het vooral de truc om precies te weten welk commando je op welke manier kunt gebruiken en in welke volgorde je deze ‘gereedschappen’ gebruikt. Batchfiles bestaan overigens nog steeds en worden nog veel (door ICT-ers) gebruikt.

Hoe is RPA dan anders dan wat ICT-ers kunnen en doen?

Er zijn een aantal ontwikkelingen die ervoor zorgen dat ‘slim automatiseren’ voor steeds meer mensen beschikbaar komt.

Voorheen moest je alle nodige commando’s met hun mogelijkheden goed kennen om koppelingen te kunnen maken. Ook was het voor ingewikkeldere koppelingen nodig om een programmeertaal te kennen waarmee je vaak veel dieper (en op de achtergrond) in de gegevens van een programma kunt wroeten. Wanneer je bijvoorbeeld in een uren-pakket uren in wilt voeren, dan ga je binnen het programma naar het scherm om uren in te voeren, en daar klik je op de juiste vakjes en vul je de uren in. Vanuit een programmeertaal kun je de onderliggende database openen en opdrachten geven om direct gegevens op te zoeken of aan te passen. Een programmeertaal is dus in feite een gereedschap om een computer dingen te laten doen. Programmeertalen bestaan al sinds het ontstaan van computers. Die moesten immers geprogrammeerd worden. Het goed leren kennen van zo’n programmeertaal kost alleen maanden, zo niet jaren.

Gereedschap is handzamer

Een belangrijke ontwikkeling is dat het programmeren van een computer tegenwoordig niet meer altijd vereist dat je een complexe set met commando’s uit je hoofd moet leren. De ‘gereedschapsset’ om dit aan te sturen is uitgebreid met manieren om bijvoorbeeld gewoon op het scherm aan te wijzen welke informatie je wilt gebruiken.

Ook hoef je niet meer een complete programmeertaal te installeren, maar is het soms voldoende om een browser-plugin te installeren (zie bijvoorbeeld https://ui.vision).

Integratie is verbeterd

Wanneer je gegevens uit een applicatie wilt lezen, was je voorheen vaak beperkt om deze informatie rechtstreeks uit de database te moeten halen, wanneer dat überhaupt mogelijk was. Doordat technieken als Optical Character Recognition (OCR, tekstherkenning) verbeteren kun je soms ook gewoon toe met het uitlezen vanaf een scherm. De applicatie hoeft dan niet aangepast te worden, maar een bestaande applicatie kun je ‘uitlezen’ vanaf het scherm.

Deze twee ontwikkelingen maken RPA bereikbaar voor een veel grotere groep dan alleen ICT-ers. In feite kan iedereen (in theorie) betrekkelijk snel en eenvoudig processen automatiseren (of robotiseren zoals dat nu heet).

Voorbeelden van gebruik

Allereerst is het belangrijk om te zeggen dat het aantal mogelijkheden gigantisch is. In dit blog staan vast net niet die voorbeelden die op jou van toepassing zijn. Wellicht geeft het wel een beetje een beeld wat zou kunnen en triggert het om zelf na te denken over RPA.

Weersvoorspelling overnemen
Misschien begint voor jou als medewerker van een ijsfabriek de dag wel met het invoeren van de weersvoorspelling van de komende 5 dagen. Je gaat naar de website van buienradar, bladert naar de 5-daagse voorspelling en klopt de cijfers vanaf deze pagina over in een Excel-document (of in een ERP- of productieplannings-pakket). Dit zou RPA heel makkelijk voor jou over kunnen nemen.

Aanmaken van klanten of leveranciers in ERP pakket
Wanneer je gebruik maakt van bijvoorbeeld een workflow met een formulier voor nieuwe klanten, maar dit niet in jouw ERP-pakket zit, zul je de gegevens hierop wellicht moeten overtypen. Dit overtypen en aanmaken van een klant in het ERP-pakket zou typisch een taak kunnen zijn die RPA van jou overneemt.

Automatisch periodiek factureren
Wanneer jouw ERP-pakket geen automatische facturen ondersteunt, zou je RPA kunnen inzetten om periodiek geautomatiseerd facturen te laten versturen en deze ook direct in de boekhouding te plaatsen.

Kanttekeningen RPA

De ontwikkelingen gaan snel, maar dat betekent niet dat iedereen nu simpel en snel alle herhaalde werkzaamheden kan robotiseren/automatiseren en dat dit ook de beste oplossing is.

Ten eerste is het belangrijk om te beseffen dat RPA een prima manier is om tekortkomingen aan de huidige ICT-omgeving aan te pakken. Men kan zonder grote investeringen winst behalen door buiten de bestaande software om zaken te automatiseren. Dit is de kracht, maar ook gelijk de valkuil.

Wanneer je buiten de bestaande software om verbeteringen aanbrengt, wordt de omgeving meer ‘houtje-touwtje’ en worden verdere ontwikkelingen of verbeteringen wellicht minder snel gemaakt. Sterker nog, soms kunnen updates van software of internetpagina’s ervoor zorgen dat het gemaakte RPA-script niet meer goed werkt. Wanneer de RPA-robot (zo heet zo’n script) gegevens op een bepaalde plaats binnen de pagina of het programma verwacht, en dit is na de update verandert, dan werkt het script niet meer. Dit geldt ook voor lay-outs van facturen, etc. Je kunt dus RPA goed inzetten als overbrugging, maar kijk altijd of er mogelijkheden zijn om de systemen in basis te verbeteren.

Een andere kanttekening is dat procesoptimalisatie mogelijk geremd wordt. Een voorbeeld is de vraag die ik enige tijd geleden kreeg: “Kun je zorgen dat in een PDF die digitaal getekend wordt, automatisch op alle pagina’s een paraaf wordt gezet?”

Deze vraag was in het ‘papieren’ tijdperk een zinvolle omdat de paraaf daar op alle pagina’s waarde heeft. Zo is aan te tonen dat de desbetreffende pagina onderdeel was van de overeenkomst die getekend is. Bij digitaal tekenen wordt een PDF als geheel getekend, en is het uithalen of wijzigen van tussenliggende pagina’s niet mogelijk zonder de digitale handtekening ongeldig te maken. Denk dus bij het in kaart brengen van het proces om te verbeteren na, of het proces zelf nog wel optimaal is.

Robots zijn erg zwart-wit. RPA is dus als systeem geschikt wanneer eventuele keuzes of beslissingen zwart-wit zijn. Wanneer er uitzonderingssituaties zijn en zeker wanneer hierbij zaken ‘op gevoel’ spelen, dan kun je deze (vrijwel) niet automatiseren.
Neem een voorbeeld van een klant die te laat betaalt, en waarbij je ‘geautomatiseerd’ een herinnering stuurt. RPA zal geen rekening houden met die bijzondere privésituatie waar de klant in zit en klakkeloos een herinnering sturen.

Zoals met alle automatiseringsslagen kan RPA bepaalde werkzaamheden overbodig maken waardoor functies veranderen of zelfs vervallen. Door het vervallen van eenvoudigere en herhaalde werkzaamheden kunnen medewerkers (die daartoe in staat zijn) wel meer tijd besteden aan complexere en afwisselendere werkzaamheden.

RPA vereist daarnaast dat er personeel is om de ‘robots’ in te richten, te beheren en waar nodig aan te passen. RPA is voor de niet-ICT-er een vrij nieuwe ontwikkeling, dus het is lastig om mensen te vinden die hier jaren ervaring mee hebben. Het is dus al snel nodig om externen in te huren om de eerste resultaten te bereiken en medewerkers op te leiden of om te scholen.

Wanneer een medewerker iets fout doet, dan ziet men dat (als het meezit;-)), stopt men en bedenkt men een andere manier om verder te gaan. Een RPA-script (of robot) zal 24×7 exact zijn fout blijven herhalen. Wanneer je een uitzondering niet goed in kaart hebt, dan loop je dus het risico dat fouten in basis ongezien blijven.

Als laatste gaat het bij implementatie van RPA om veranderingen binnen een organisatie. Dit soort wijzigingen hebben de neiging om niet succesvol te zijn wanneer de medewerkers die erdoor geraakt worden niet volledig achter de wijzigingen staan. Het is dus belangrijk dat deze medewerkers betrokken zijn bij het proces en beseffen dat de veranderingen het doel hebben om hen te helpen.

Al met al best wat kanttekeningen, maar laat dit vooral geen belemmering zijn om te kijken of RPA kan helpen jouw organisatie te verbeteren.

Wil je eenvoudig RPA aan het werk zien?

Wanneer je in 10 minuten wilt zien hoe RPA er ‘in het echt’ uitziet, kun je het volgende filmpje kijken; https://youtu.be/gTwQ1GGw1sc. Hierin is te zien hoe eenvoudig het kan zijn om de eerste stappen te zetten. Er wordt een extensie voor een browser geïnstalleerd (ui.vision) en geautomatiseerd gegevens van een internetpagina gelezen.

Publicatiedatum: 20-05-2021