Wat is browser-automatisering (RPA) en wanneer gebruik je het?

In het kort

Browser-automatisering, vaak RPA genoemd (robotic process automation), is software die een website of portaal bedient zoals een mens dat doet: inloggen, klikken, velden invullen, gegevens aflezen en downloaden. Je gebruikt het als een systeem geen API heeft en je toch wilt dat herhaald werk automatisch gebeurt. Het werkt goed voor stabiele portalen met voorspelbare handelingen, en het vraagt om logging en bewaking omdat een portaal zonder aankondiging kan veranderen.

Wat browser-automatisering precies is

Stel je een medewerker voor die elke ochtend inlogt op het portaal van een verzekeraar, een lijst met nieuwe dossiers opent, per dossier de status en de bijlagen ophaalt en die overzet naar het eigen systeem. Een uur werk, elke dag, zonder dat er één beslissing bij komt kijken. Browser-automatisering doet exact dat: een programma opent een browser, gaat naar dezelfde pagina's, doet dezelfde klikken en leest dezelfde velden af.

Het verschil met een API-koppeling zit in de ingang. Bij een API praat je rechtstreeks met het systeem via een afspraak die de leverancier heeft bedoeld voor software. Bij browser-automatisering gebruik je de ingang die bedoeld is voor mensen: het scherm. Dat maakt het universeel inzetbaar, want elk portaal heeft een scherm. Het maakt het ook kwetsbaarder, want dat scherm is niet gebouwd om stabiel te blijven voor software.

De term RPA komt uit de wereld van grote organisaties, waar platforms zoals UiPath en Power Automate worden ingezet om medewerkers van administratieve taken te ontlasten. Voor het MKB en dienstverleners is de kern hetzelfde, maar de schaal kleiner: meestal gaat het om één of enkele portalen die veel tijd kosten.

Hoe het onder de motorkap werkt

Zonder al te technisch te worden: een script bestuurt een browser die, meestal onzichtbaar, op een server draait. Het script bestaat uit stappen die de bouwer vastlegt.

1. Navigeren en inloggen. Naar het adres van het portaal gaan, de inloggegevens invullen, wachten tot de pagina geladen is.
2. Elementen vinden. Het script herkent knoppen en velden aan hun kenmerken in de pagina, bijvoorbeeld een naam of een positie in de structuur. Dit is het kwetsbare deel: verandert het portaal die kenmerken, dan vindt het script het veld niet meer.
3. Handelingen uitvoeren. Klikken, typen, een bestand uploaden of downloaden, een pagina verder bladeren.
4. Gegevens aflezen. De tekst uit een tabel of veld halen en omzetten naar gestructureerde gegevens die je eigen software begrijpt.
5. Wegschrijven en afronden. De gegevens opslaan in je eigen systeem, uitloggen, en vastleggen wat er is gebeurd.

Het script draait op een vast moment (elke nacht, elk uur) of op een signaal (er is een nieuw dossier). Belangrijk: het draait op een server die jij beheert, niet op de laptop van een medewerker. Anders stopt het proces zodra die laptop dichtgaat.

Wanneer je het gebruikt, en wanneer niet

Een eenvoudige vuistregel: is er een API, gebruik die. Is er geen API, of is de API te beperkt voor wat je nodig hebt, dan is browser-automatisering de volgende optie.

Goede toepassingen

• Portalen van overheden, verzekeraars, banken of leveranciers zonder koppeling, waar je dagelijks statussen of documenten ophaalt.
• Oude interne systemen die niemand meer durft aan te passen, maar die nog jaren mee moeten.
• Het periodiek downloaden van overzichten of facturen uit een leveranciersomgeving.
• Gegevens uit je eigen systeem invoeren in een extern portaal dat alleen handmatige invoer kent.

Geen goed idee als

• er wél een API is; dan bouw je bewust op een wankeler fundament dan nodig. Lees als voorbeeld hoe een API-koppeling met je boekhouding werkt;
• het portaal bij elke inlog een code op een telefoon vereist en de leverancier geen alternatief biedt;
• de gebruiksvoorwaarden geautomatiseerd gebruik verbieden;
• het om zeer grote volumes gaat waarbij snelheid bepalend is;
• het portaal vaak verandert, zoals een omgeving die duidelijk nog volop in ontwikkeling is.

De risico's eerlijk benoemd

Het portaal verandert

Dit is het grootste risico. Een leverancier verplaatst een knop of hernoemt een veld, en het script loopt vast. Dat is geen kwestie van of, maar van wanneer. Je kunt het niet voorkomen, wel opvangen: met bewaking die meteen meldt dat er iets misgaat en een bouwer die het snel herstelt.

Inloggen en tweestapsverificatie

Steeds meer portalen vragen om een tweede factor. Soms is dat oplosbaar, bijvoorbeeld met een aparte account voor de automatisering of een methode die de leverancier voor software bedoeld heeft. Soms niet. Bespreek dit voordat je begint, niet erna.

Gebruiksvoorwaarden

Niet elk portaal staat geautomatiseerd gebruik toe. Lees de voorwaarden of vraag het de leverancier. Voor je eigen gegevens in een portaal van een partij waar je klant bent, is er zelden een probleem, maar controleer het. Bij twijfel is een jurist de aangewezen persoon, niet de bouwer.

Wachtwoorden en toegang

Het script moet inloggen, dus ergens staan inloggegevens. Die horen in een beveiligde kluis op de server, nooit in de code of in een gedeeld document. En de account die het script gebruikt, mag alleen zien wat het nodig heeft.

Zo maak je het betrouwbaar

Browser-automatisering heeft een slechte naam bij wie het ooit als los script op een bureaulaptop heeft gehad. Goed gebouwd is het een stabiel onderdeel van je proces. Het verschil zit in deze maatregelen:

• Logboek per run. Elke uitvoering legt vast wat er is gedaan, welke dossiers zijn verwerkt en waar het stopte. Je kunt altijd terugkijken.
• Schermafbeelding bij fouten. Loopt het script vast, dan bewaart het een afbeelding van de pagina op dat moment. Zo zie je in één oogopslag wat er is veranderd.
• Melding bij afwijking. Geen dossiers gevonden waar er normaal tientallen zijn? Inloggen mislukt? Dan gaat er meteen een bericht naar een mens, niet pas als iemand het toevallig merkt.
• Herhaalpogingen met verstand. Een pagina die traag laadt is geen fout. Het script wacht en probeert opnieuw, maar niet eindeloos.
• Controle op de uitkomst. Voordat gegevens worden weggeschreven, controleert het script of ze eruitzien zoals verwacht: een datum is een datum, een bedrag is een bedrag.
• Mens in de lus voor onomkeerbare stappen. Iets versturen, indienen of bevestigen in een portaal? Laat het script het klaarzetten en een mens de laatste knop drukken, in elk geval totdat het vertrouwen er is.
• Kleine, losse stappen. Ophalen, verwerken en wegschrijven als aparte onderdelen. Gaat één deel stuk, dan blijft de rest werken.

Met deze maatregelen is de vraag niet meer of het script ooit vastloopt, maar hoe snel je dat weet en hoe snel het weer draait. Dat is dezelfde logica als bij elke andere vorm van procesautomatisering: niet perfect willen zijn, maar controleerbaar.

Zo begin je

1. Kies het portaal dat het meeste tijd kost en beschrijf de handelingen stap voor stap, alsof je het aan een nieuwe collega uitlegt.
2. Controleer of er toch een API of exportmogelijkheid is. Vraag het de leverancier; soms bestaat die wel, maar staat het niet op de website.
3. Lees de gebruiksvoorwaarden en regel een aparte account voor de automatisering.
4. Laat een eerste versie bouwen die alleen leest en niets indient. Dat is veilig om te testen en levert meteen tijdwinst op.
5. Draai een paar weken mee naast het handmatige proces en vergelijk de uitkomsten.
6. Breid pas uit naar schrijvende handelingen als het lezen betrouwbaar is.

Op de pagina over browser-automatisering zonder API lees je hoe wij dit aanpakken. In procesautomatisering: voorbeelden vind je welke andere processen zich lenen voor automatisering. Blijkt er toch een koppeling mogelijk, kijk dan bij koppelingen en API's.