Als je bedrijven zoals UiPath, Another Monday en Blueprism af en toe hoort praten, dan lijkt het net alsof RPA de oplossing is voor alles. Dat zal men ook bij die bedrijven zelf zeker niet zo zien overigens, maar dat is wel de indruk die af en toe wordt gewekt. Om meer inzicht te krijgen op waar de grenzen van RPA liggen op dit moment, hebben we met Blaise Jamroz van Pegasystems gesproken. Dat bedrijf heeft namelijk een uitgesproken visie over wat de rol van RPA moet zijn in het geheel.

Vrij jonge discipline, ook voor Pegasystems

Jamroz begint ons gesprek met de uitspraak dat RPA nog een vrij jonge discipline is en dat we eigenlijk nog aan het uitvinden zijn wat er allemaal mee mogelijk is. Dat de nadruk op dit moment nog steeds behoorlijk ligt op het automatiseren van desktop-processen is ook niet zo gek, omdat de beginselen van RPA liggen in screen scraping, dat vervolgens resulteerde in Robotic Desktop Automation, waarna het pas Robotic Process Automation werd. “Pas een jaar of acht geleden zijn we het gaan hebben over RPA. Daarvoor was het RDA, dat een stuk beperkter is dan RPA, maar er nog altijd onderdeel van uitmaakt.”

Pegasystems is zelf ook nog niet zo heel lang bezig met RPA overigens. In 2016 werd OpenSpan overgenomen, waarmee het aan het portfolio van het bedrijf toegevoegd werd. Dit alles om weer een stap verder te komen in datgene waar Pegasystems zich vooral mee bezighoudt: Customer Engagement, Business Process Management en/of Digital Process Automation.

Blaise Jamroz, Principal Solution Consultant bij Pegasystems

Radertje in het grote geheel

Bij Pegasystems verkoopt men dus geen RPA zoals je dat wel ziet bij ‘pure’ RPA-aanbieders. Het wordt alleen aangeboden als onderdeel van een groter automatiseringsproces. Daarmee wil Jamroz het belang van RPA en daarmee softwarematige robots zeker niet bagatelliseren overigens. “Robots zijn erg goed in zeer specifieke taken, waarbij ze minder fouten maken dan mensen en ze veel meer in een kortere tijd kunnen doen. Ze zijn erg goed in high volume en low complexity.”

Dat laatste moet dan ook altijd de focus hebben bij het inzetten van RPA. Gebruik ze alleen voor microprocessen en ga niet proberen om boven de kleinere processen een robot te bouwen die ‘hoger in rang’ is en meerdere andere robots aanstuurt. Laat dat laatste over aan een daadwerkelijk slim overkoepelend platform, dat ook nog wat extra intelligentie heeft in de vorm van AI om zaken op te pakken.

Rol van het overkoepelende platform

Om dat laatste te illustreren, geeft Jamroz het voorbeeld van een robot die ergens in wil loggen, terwijl de inlogprocedure is veranderd sinds de laatste keer. “Een robot zal blijven proberen om in te loggen, maar niet succesvol zijn. De intelligentie in het platform dat de robot aanstuurt pikt de herhaalde mislukte inlogpogingen echter op en onderneemt hier actie op.” In een geval zoals dit zal het oplossen van het probleem hoogstwaarschijnlijk alsnog bij een mens op zijn of haar bordje terechtkomen. Die moet aanpassen hoe er wel ingelogd moet worden. Hier zie je uiteindelijk ook dat de mens een rol zal blijven spelen in automatisering overigens, maar dat terzijde.

Een ander voorbeeld van de rol van het overkoepelende platform dat Jamroz aanhaalt is de mogelijkheid om robots net een tikkeltje slimmer te maken. Als een robot voor het eerst een bepaald microproces moet uitvoeren en hij heeft die specifieke taak niet in zijn arsenaal, dan zal hij dat binnen de omgeving van Pegasystems laten weten aan het platform. Dat geeft hem dan vervolgens de opdracht om ergens iets te downloaden waarmee hij de taak wel uit kan voeren. Daarna is een dergelijke interactie overigens niet meer nodig, behalve als er iets verandert aan de taak die uitgevoerd moet worden uiteraard.

RPA vs. API

We hebben het met Jamroz ook over de meerwaarde van RPA als het gaat om het integreren van meerdere onderdelen van een digitale omgeving. API’s mogen dan voor alle moderne applicaties en omgevingen de standaard zijn om te integreren met elkaar, dat geldt niet voor veel oudere applicaties bijvoorbeeld.

Jamroz noemt hier specifiek oude applicaties bij banken, die niet zomaar vervangen kunnen of mogen worden. Vandaar dat je bij banken nog regelmatig medewerkers informatie over ziet tikken bij de fulfilment van een aanvraag voor een lening bijvoorbeeld. Hij of zij tikt het dan van het ene scherm over op het andere scherm, terwijl het op de achtergrond wel gewoon in dezelfde omgeving draait. Dat moet je tegenwoordig niet meer handmatig willen doen.

Het probleem bij dit soort gevallen is dan echter vaak dat de applicaties dermate oud zijn dat API’s geen oplossing bieden. In zulke gevallen biedt RPA uitkomst. Een robot op de achtergrond kan ervoor zorgen dat de informatie van de ene applicatie in de juiste velden van de andere terechtkomt. Althans, als de applicatie goed kan ‘praten’ met robots. Dat is volgens Jamroz ook niet altijd zo. “Not all applications are very chatty with robots”, zoals hij het zelf stelt.

In dat laatste geval zal er een andere oplossing bedacht moeten worden om de zaken te automatiseren. Het vernieuwen van de gebruikte software zou dan weleens de enige optie kunnen zijn. Of je moet het prima vinden om nog een tijd aan te modderen in de oude situatie uiteraard.

Functie op twee niveaus

Samenvattend heeft RPA volgens Pegasystems dus een functie op twee niveaus binnen digitale omgevingen. Allereerst is er het niveau van de microprocessen, waarbij de robot een zeer specifieke taak uitvoert als onderdeel van een veel groter geheel, dat dan wordt aangestuurd door een overkoepelend platform. Het tweede niveau is dat van het koppelen van applicaties/componenten op een API-niveau, als API’s niet volstaan of mogelijk zijn. Pegasystems zelf zal dan ook nooit specifiek robots verkopen volgens Jamroz, maar een platform waarmee automatiseringsuitdagingen van klanten te lijf worden gegaan.