Als RPA bots wachtwoorden van bot collega’s veranderen…

…Robotic Process Automation houdt ook rekening met compliance-eisen die oorspronkelijk voor mensen waren opgesteld. Zelfs mailverzoeken aan menselijke collega’s van andere afdelingen of een “onderbuikgevoel” nagebootst door een set regels is niet langer een zeldzaamheid.

De start-up meta:proc is op de markt met de “e:Agent”, een zelfontwikkeld platform voor het programmeren van “RPA bots”. Onder de verzamelnaam RPA (Robotic Process Automation) veroveren virtuele robots die louter op softwareniveau bestaan, op vele plaatsen het dagelijkse kantoorleven. De “softwarebots” nemen gewoonlijk repetitieve, op regels gebaseerde taken op zich in de zin van functie- en toepassingsoverschrijdende macro’s. Zij verhelpen bijvoorbeeld mediadiscontinuïteiten bij het opstellen van aanbiedingen door kerngegevens in uniforme overzichten over te brengen, controleren automatisch de geldigheid van BTW-nummers of nemen het grootste deel van de werkzaamheden in verband met de verificatie van facturen over, van de inkomende post tot de goedkeuring door een mens. De technologie van meta:proc verschilt niet fundamenteel van die van de concurrentie, maar een sterk punt van de meta:proc-aanpak is “om ook niet-regelgebaseerde processen in regels te definiëren, zodat RPA-bots regelmatig voorkomend, soms hersenloos werk kunnen overnemen”, zegt Alexander Steiner, Chief Solution Architect bij meta:proc. “Als bijvoorbeeld kortingen aan bepaalde klanten worden gegeven op basis van het onderbuikgevoel van een verkoopmedewerker, vinden wij een manier om daar regels voor op te stellen”, zegt Steiner.

De e:Agent van meta:proc

De e:Agent is uiteindelijk een toolbox die de basis vormt voor het maken van softwarebots met behulp van onder andere Java-technologieën. “In vergelijking met onze concurrenten hanteren wij een aanpak die meer is toegesneden op de complexiteit van afdelingsoverkoepelend gebruik. Zo is ook de bedrijfsnaam ontstaan: meta:proc staat voor metaprocessen die continu zijn en gevonden moeten worden,” legt de RPA-professional uit en illustreert het afdelingsoverstijgende aspect met een voorbeeld uit de IT-industrie: “Controlling in een softwarebedrijf heeft regelmatig behoefte aan een overzicht van de kostensituatie voor een bepaald project. Met behulp van een afdelingsoverkoepelende oplossing op basis van RPA kon het projectbeheer worden geautomatiseerd, kon op vooraf vastgestelde tijdstippen per mail contact worden opgenomen en konden ook de daaruit voortvloeiende follow-up-taken door robots worden uitgevoerd of vereenvoudigd.”

Mail van bot-collega

In de regel worden softwarebots als zodanig herkend in interne mailquery’s, maar men kan ook met fictieve personen werken, wat bijvoorbeeld voor marketing- of verkoopcampagnes een goed idee is. Aangezien bots over het algemeen beter overweg kunnen met gestructureerde dan met ongestructureerde gegevens, is een bijgevoegd Excel-document of formulier een goed idee: Daarin verzamelt de robot de resterende uitgaven die voor het jaar moeten worden afgebakend, alsmede de berekende veiligheidsbuffers in het projectbeheer. In controlling kan deze informatie dan automatisch worden verwerkt in de vorm van voorzieningen.

Toegangswachtwoorden voor RPA-bots

Compliance-richtlijnen in bedrijven spelen hier soms een rol, bijvoorbeeld als een database-medewerker – om veiligheidsredenen – geen toegang heeft tot het applicatieniveau en het netwerkniveau. “In de regel wordt met dergelijke structuren ook rekening gehouden wanneer RPA-bots het werk van de betrokken werknemers ondersteunen”, meldt Steiner vanuit de projectpraktijk. Er zijn zelfs robots die – om compliance-redenen – noodzakelijk worden door het gebruik van andere robots: “Als de IT bijvoorbeeld voorschrijft dat de toegangswachtwoorden van de bots voor bepaalde toepassingen regelmatig moeten worden gewijzigd, zijn andere robots nodig om deze wachtwoorden voor hun ‘bot-collega’s’ te wijzigen met het oog op automatisering en vanuit compliance-oogpunt.”

Kennis opbouwen

Een tweeweekse cursus van meta:proc, en met basiskennis van programmeren met Java, stelt ervaring in staat om RPA-bots te maken voor een zogenaamd “happy path”-proces en deze te automatiseren. In de dagelijkse praktijk doen zich buiten deze “laboratoriumoplossing” uitdagingen voor die moeten worden beheerst – namelijk wanneer van de robot wordt verwacht dat hij een zekere dynamiek aan de dag legt en tolerantie vertoont voor afwijkingen van dit gelukkige pad. Op dit punt zijn er parallellen met menselijke gebruikers van software die geïrriteerd raken wanneer de gebruikersinterface wordt gewijzigd.

Steiner legt het probleem uit: “Als de softwarebots bijvoorbeeld met cloud-applicaties werken, waarvan de fabrikant de gebruikersinterface van de ene op de andere dag verandert, staat de te bedienen knop of het invoerveld opeens ergens anders. Wat is de beste manier om ermee om te gaan wanneer er sporadisch een pop-up verschijnt over de knop die de bot eigenlijk met een klik wilde bedienen? Of hoe moet het verder als de responstijden bergafwaarts gaan als er veel bots worden gebruikt?” Voor dergelijke praktische problemen is – afhankelijk van de voorkennis – zes maanden tot driekwart jaar oefenen nodig om het geheel in een project te kunnen implementeren, schat Steiner in en noemt het probleem: “De technologie is zo jong dat er geen RPA-programmeurs zijn met tien jaar beroepservaring. Daarom halen we onze ontbrekende specialisten rechtstreeks van de universiteit door te proberen mensen daar van onze technologie te overtuigen”

Indirecte verkoop

De kanaalbusiness van meta:proc voorziet in drie vormen van samenwerking: Via verkooppartnerschappen kunnen partners zakelijke kansen genereren en projecten naar het bedrijf doorverwijzen. Daarnaast zijn er analyse- en uitvoeringspartnerschappen met RPA-dienstverleners die min of meer zelfstandig projecten uitvoeren. En ecosysteem- en technologiepartners bieden complementaire oplossingen, bijvoorbeeld chatbots of AI-oplossingen.