Wat is het verschil tussen RPA en document-AI?
RPA, robotic process automation, voert stappen uit die een mens ook in een systeem zou doen: klik hier, kopieer daar, plak het in veld X. De robot volgt een script. Dat werkt uitstekend voor vaste, herhalende handelingen waarbij de invoer altijd dezelfde structuur heeft. Document-AI doet iets anders: het leest een document, begrijpt de context en haalt de juiste velden eruit, ook als het format wisselt. Een factuur van leverancier A ziet er anders uit dan die van leverancier B, maar document-AI trekt er allebei het factuurnummer, bedrag en betalingstermijn uit. RPA zou voor elke lay-out een apart script nodig hebben.
Wanneer werkt RPA goed voor documentverwerking?
RPA is op zijn sterkst als het document eigenlijk geen document is: een gestructureerde export uit een systeem, een EDI-bericht in vast formaat of een spreadsheet die altijd dezelfde kolommen heeft. Je bouwt het script eenmalig, het draait onbeheerd en het is snel klaar. Ook als aanvulling op andere tooling is RPA nuttig: je gebruikt document-AI om de data uit een PDF te halen, en RPA om die data vervolgens in het juiste scherm van je ERP te zetten. Die combinatie komt in de praktijk geregeld voor. Het probleem begint zodra het bronbestand varieert. Een leverancier past zijn factuurlayout aan, een nieuwe shipper stuurt CMR's in een ander formaat, een klant mailt orders in een iets andere tabel. Het RPA-script faalt, niemand merkt het meteen, en ergens in de keten klopt de data niet meer.
Waarom breekt RPA op ongestructureerde documenten?
RPA werkt op positie of patroon: het zoekt een waarde op een vaste plek of via een vaste reguliere expressie. Zodra de opmaak verandert, vindt het script de waarde niet meer. Dat is geen bug, het is een ontwerpkeuze: RPA is gemaakt voor stabiliteit, niet voor variatie. Documenten zoals inkomende orders, CMR-vrachtbrieven, pakbonnen of inspectiefoto's zijn van nature variabel. Ze komen van tientallen of honderden verschillende afzenders, elk met hun eigen lay-out, afkortingen en veldenindeling. Elk nieuw format betekent in een RPA-aanpak: een nieuwe regel schrijven, testen en beheren. Bij een handvol vaste leveranciers is dat te doen. Bij een operatie met brede leveranciersbasis wordt het al snel een voltijdse beheerstaak.
Wat zijn de concrete trade-offs van document-AI ten opzichte van RPA?
Document-AI lost het variatie-probleem op maar brengt eigen afwegingen mee. Ten eerste: implementatietijd. Een RPA-script voor een enkel stabiel proces is snel gebouwd, soms in dagen. Document-AI heeft een initiële inrichting nodig: welke velden wil je extraheren, welke regels gelden voor matching, hoe ziet de uitvoer eruit. Bij dottle is dat in twee weken live, maar je moet die tijd wel inplannen. Ten tweede: transparantie. Goed gebouwde document-AI markeert wat het niet zeker weet en legt de beslissing dan bij een mens. RPA doet dat niet van zichzelf: het slaagt of faalt, en bij falen weet je het soms pas als de schade al gedaan is. Ten derde: beheerslast op termijn. Bij document-AI voeg je een nieuw format toe als een nieuwe regel of extractieset, gecontroleerd. Bij RPA pas je het script aan en hoop je dat het geen andere stroom raakt. Naarmate het aantal documentbronnen groeit, kantelt de balans duidelijk in het voordeel van document-AI.
Wanneer is een combinatie van RPA en document-AI zinvol?
De twee sluiten elkaar niet uit. De meest voorkomende combinatie: document-AI leest het inkomende document uit en levert gestructureerde data, RPA of een directe API-koppeling zet die data in het doelsysteem. Je speelt dan op de sterkte van beide: document-AI op de ongestructureerde input, RPA of koppeling op de stabiele systeemhandeling. Dat is ook precies hoe dottle werkt: de uitvoer gaat via een koppeling naar ERP, TMS, WMS of boekhoudpakket, zodat het overtikwerk verdwijnt zonder dat je een fragiel end-to-end RPA-script bouwt dat door het hele document heen moet lezen. Een combinatie is minder zinvol als het document al volledig gestructureerd binnenkomt. Dan is document-AI overkill en volstaat een directe koppeling of eenvoudig RPA-script.
Wanneer past document-AI juist niet?
Eerlijk zijn betekent ook dit zeggen: document-AI is niet altijd de juiste keuze. Als je één vaste leverancier hebt die altijd hetzelfde gestructureerde formaat aanlevert, is het bouwen van een lichtgewicht koppeling of een eenvoudig script sneller en goedkoper. Als het documentvolume laag is, minder dan een paar honderd documenten per maand, is de terugverdientijd lang. En als het onderliggende proces nog niet vaststaat, wat er precies in welk veld moet komen, dan los je met automatisering niets op: dan leg je de chaos alleen sneller vast. Automatiseren heeft pas zin als je weet wat je wilt automatiseren.