Praktijkanalyse · Automation
Variant: deze RPA-case gaat eigenlijk over het slim verbinden van systemen
De publieke Variant-case beschrijft medewerkers die gegevens tussen sterk verschillende applicaties moesten overnemen. De relevante les is niet “zet overal een bot tussen”, maar kies per systeem de beste beschikbare interface en automatiseer de keten beheersbaar.
Variant was automation-ready doordat het probleem concreet, terugkerend en digitaal was én omdat meerdere systemen al databases, webservices of API’s aanboden. RPA was onderdeel van een bredere integratie-aanpak, niet het doel op zichzelf.
Wat de openbare case feitelijk vermeldt
- Variant werkte volgens de publieke case met meerdere verschillende applicaties die niet eenvoudig op elkaar aansloten, waaronder Firebase, Exact OnPremise/MSSQL, webservices en een mobiele/webapp met REST API’s.
- Medewerkers moesten gegevens uit het ene systeem afdrukken of overnemen en in een ander systeem invoeren.
- De case rapporteert 100% minder handmatige fouten en 75% minder planningsfouten.
- Automate werd volgens de bron gebruikt in planning, finance, ICT, HR en customer support en maakte gebruik van onder meer databases, webservices/OData, REST/JSON, CSV en XML/XSLT.
Het probleem was vooral systeemfrictie, niet “te weinig robots”
Variant is interessant omdat het klassieke beeld van RPA als klikrobot hier tekortschiet. De oorspronkelijke pijn was informatie die handmatig tussen verschillende systemen moest worden verplaatst. Dat maakt de case vooral een integratie- en orkestratievraagstuk.
- Meerdere applicaties moesten gegevens van elkaar gebruiken.
- Er waren zowel databases als webservices en REST API’s beschikbaar.
- Handmatig overtypen veroorzaakte tijdverlies en fouten.
- De behoefte bestond in meerdere afdelingen, waardoor hergebruik relevant werd.
Waarom een hybride automationlaag logisch was
| Beschikbare interface | Logische eerste route |
|---|---|
| MSSQL/database | Directe databaseconnector of gecontroleerde datalaag. |
| REST API / JSON | API-integratie wanneer de interface stabiel en ondersteund is. |
| Webservices / OData | Systeemintegratie via bestaande services. |
| CSV/XML | Gecontroleerde file/data-processing workflow. |
| Ontbrekende interface | RPA/UI-automatisering als bridge waar nodig. |
De case ondersteunt daarmee een belangrijke Boermans-regel: RPA is niet automatisch de eerste keuze. Gebruik de beste beschikbare interface per stap en orkestreer de keten als geheel.
Waarom dit soort handwerk vaak een goede eerste kandidaat is
- De handeling komt terug en is digitaal.
- Bron en bestemming zijn identificeerbaar.
- Het foutmechanisme — handmatig overnemen — is concreet.
- De bestaande systemen hoeven niet meteen vervangen te worden.
- De waarde is meetbaar via fouten, doorlooptijd en handmatige behandeltijd.
Wat je niet mag generaliseren
- Dat iedere handmatige fout volledig kan worden geëlimineerd.
- Dat de gerapporteerde 100% en 75% reducties overdraagbaar zijn naar een andere organisatie.
- Dat één technologie alle interfaces in jouw landschap het beste kan bedienen.
- Dat het ontbreken van een native koppeling automatisch betekent dat RPA nodig is.
- Wat implementatiekosten, payback of beheerinspanning in deze case waren.
Bronnen en bewijskracht
De feiten hieronder komen uit de genoemde openbare bron. De analyse eromheen is van Boermans Digital.
Afbakening: De resultaten zijn gepubliceerd in een Korper/Fortra klantcase. Boermans Digital claimt Variant niet als eigen klant en gebruikt de bron uitsluitend om proces- en architectuurkeuzes te analyseren.