AI koppelen aan verouderd ERP: integreren, niet vervangen

Ja — AI werkt met verouderde ERP-software. U hoeft uw vijftien jaar oude ERP-, WMS- of planningspakket niet te vervangen om AI te gebruiken. Een dunne integratielaag leest data via de API’s, databasekoppelingen of zelfs de exports die uw systeem al heeft, laat AI buiten het oude systeem het denkwerk doen, en schrijft resultaten terug als gewone transacties. Vervangen is een vijfjarenproject; integreren is er een van zestig tot negentig dagen.

Waarom “onze software is te oud voor AI” meestal niet klopt

De angst is begrijpelijk: de leverancier is weg of traag, de code is fragiel, en de ene consultant die het maatwerk snapt, nadert zijn pensioen. Maar AI-integratie wijzigt het legacy-systeem helemaal niet — dat is juist de truc. Ook oudere SAP-, Oracle-, Exact- of Unit4-installaties ontsluiten data via API’s of ODBC/JDBC-databasekoppelingen, en de grofste terugvaloptie — een nachtelijke CSV-export — is nog altijd een bruikbare datastroom. De AI-laag staat naast het ERP, niet erin.

Wat een systeem écht diskwalificeert komt zelden voor: geen enkele manier om data eruit te krijgen (geen API, geen databasetoegang, geen exports), of data die zo onbetrouwbaar is dat geen automatisering erop mag vertrouwen. Het eerste is uitzonderlijk; het tweede is een datakwaliteitsproject, geen reden om een nieuw ERP te kopen.

De drie integratiepatronen, van veilig naar diep

1. Alleen-lezen (spiegel): de middleware leest alleen — orders, voorraadmutaties, facturen, uren — en de AI levert advies: uitzonderingslijsten, prognoses, afwijkingssignalen. Er wordt niets teruggeschreven, dus er kan niets kapot. Hier hoort elke legacy-integratie te beginnen, met een schaduwperiode van enkele weken die de nauwkeurigheid bewijst vóór iemand ernaar handelt.
2. Terugschrijven via de voordeur: de AI maakt concepttransacties — een inkoopvoorstel, een factuurcodering, een planningssuggestie — via dezelfde interfaces die een menselijke gebruiker zou gebruiken, en een mens keurt ze goed in de vertrouwde ERP-schermen. Het ERP blijft het systeem van waarheid; de AI is een erg snelle junior-collega.
3. Wrap-and-extend: voor workflows die het oude systeem simpelweg niet kan (documentbegrip, e-mailtriage, klantcontact), legt de middleware een uniforme API over de legacy-kern en worden nieuwe toepassingen dáártegen gebouwd — met het ERP onaangeroerd eronder.

Wat het kost en oplevert — de eerlijke versie

Integratieprojecten van deze vorm duren weken tot maanden, geen jaren. Vakliteratuur noemt 60–90 dagen tot eerste productiegebruik via middleware, en dat komt overeen met wat wij in de Nederlandse mkb-praktijk zien: de eerste alleen-lezen toepassing (meestal factuuruitzonderingen, voorraadafwijkingen of planningssignalen) draait binnen twee maanden. De terugverdienlogica is simpel: kies één workflow waar mensen nu overtypen, afstemmen of data najagen tussen ERP en werkelijkheid, en beprijs de uren. Besteedt een planner 6 uur per week aan dezelfde Excel uit ERP-exports, dan is die ene workflow ~280 uur per jaar — nog vóór de fouten meetellen.

Kosten schalen met ambitie, niet met de leeftijd van uw ERP: een alleen-lezen uitzonderingsfeed is een klein project; terugschrijf-automatisering voegt goedkeuringsontwerp en testen toe; wrap-and-extend is echt softwareontwikkeling. De dure fout is direct naar patroon drie springen omdat een leveranciersdemo er goed uitzag.

De vijf vragen die uw integratieroute bepalen

• Kan data eruit? API, databasekoppeling of geplande export — in die volgorde van voorkeur. Uw IT-partner beantwoordt dit binnen een dag.
• Is de data betrouwbaar? Als voorraadstanden fictie zijn: eerst tellen fiksen, dan pas voorspellen.
• Waar is de pijn repetitief? AI op legacy-systemen verdient geld in werk met hoog volume en lage variatie: coderen, matchen, controleren, concepten maken.
• Wie keurt goed? Elke terugschrijfactie heeft een benoemde menselijke eigenaar nodig, ín de bestaande ERP-schermen — nieuwe interfaces doden adoptie.
• Wat is de exit? Houd de middleware leveranciersneutraal, zodat wanneer u het ERP in 2030 wél vervangt, de AI-laag en zijn historie meeverhuizen in plaats van te sterven met het oude systeem.

Een uitgewerkt voorbeeld: factuuruitzonderingen op een ouder ERP

Het patroon dat wij het vaakst als eerste project aanraden, omdat elk bedrijf het heeft: inkoopfacturen die niet matchen met hun order of ontvangst. In de klassieke opzet opent iemand elke mismatch, graaft door het ERP, mailt een collega en parkeert de factuur twee weken. Met een alleen-lezen integratie haalt de middleware ’s nachts facturen, orders en ontvangsten op; een taalmodel classificeert elke mismatch (prijsverschil, aantalverschil, ontbrekende ontvangst, onbekende leveranciersreferentie) en zet de uitleg plus de e-mail aan de juiste inkoper klaar. Mensen stoppen met uitzoeken en beginnen met beslissen.

De cijfers erachter, met zichtbare aannames: een bedrijf dat 12.000 inkoopfacturen per jaar verwerkt met 6% uitzonderingen, behandelt er 720. À 20 minuten per stuk is dat 240 uur gekwalificeerde financetijd. Classificatie plus concepten brengt de behandeltijd doorgaans naar 5–7 minuten — grofweg 160 uur bespaard, elk jaar, uit één alleen-lezen feed die niets in het ERP aanraakt. Dat is de orde van grootte voor patroon één: geen transformatie, wel een solide terugkerend dividend — en een bewijs dat vertrouwen koopt voor patroon twee.

Security, en het gesprek met uw IT-partner

Legacy-integraties stranden vaker op politiek dan op techniek, en de poortwachter is meestal uw IT-partner. Drie afspraken maken dat gesprek werkbaar. Eén: toegang — een alleen-lezen databaseaccount of afgebakende API-gebruiker, zodat de AI-laag nooit buiten haar strook kan schrijven. Twee: datagrenzen — welke tabellen het pand verlaten, waar ze verwerkt worden (EU-datacenters onder een verwerkersovereenkomst) en wat er gelogd wordt. Drie: verantwoordelijkheid — de IT-partner houdt het ERP; de AI-laag is een apart systeem met een eigen eigenaar. Zet die drie op één A4 en de meeste IT-partners worden bondgenoten — zij hebben genoeg mislukte rip-and-replace-projecten gezien om een aanpak te waarderen die hun systeem met rust laat.

Middleware bouwen of kopen?

Voor standaardkoppelingen: kopen. Integratieplatformen en de connector-ecosystemen rond n8n, Make en de iPaaS-leveranciers dekken gangbare ERP’s goed af. Bouw alleen het dunne maatwerkdeel waar uw onderscheidende proces zit — de extractielogica, de bedrijfsregels, de AI-prompts en de evaluatie. Die verdeling houdt u leveranciersneutraal (de exitvraag hierboven) en bespaart maanden loodgieterswerk dat kant-en-klare connectors al hebben opgelost. Wat u níét moet kopen: een black box die uw ERP-data in andermans cloud opsluit zonder exportpad — dan bouwt u het legacy-probleem één laag hoger opnieuw.

En AI-agents die rechtstreeks met het ERP praten?

De agent-golf van 2026 (MCP-connectors, computer-use agents die door schermen klikken) maakt het verleidelijk om de middleware over te slaan en een agent het ERP als mens te laten bedienen. Voor verkenning werkt dat; voor productie is het fragiel — schermgestuurde agents breken op elke UI-eigenaardigheid, en ongemedieerde schrijftoegang is precies wat de patronen hierboven moeten voorkomen. Agents horen bóven de integratielaag, waar hun acties getypeerd, gelogd en goedkeurbaar zijn — niet ín een twintig jaar oude interface om twee uur ’s nachts.

Waar begint u?

Breng één workflow van begin tot eind in kaart, bevestig het datapad uit uw ERP, en draai patroon één een maand in schaduwmodus. Dat levert een businesscase op met uw eigen cijfers in plaats van een leveranciersbrochure. Onze aanpak voor AI-implementatie en data-engineeringpraktijk zijn precies rond deze route gebouwd — en wilt u eerst een second opinion, dan is dit het gesprek dat een AI-consultant voor het mkb in één middag met uw IT-partner moet kunnen voeren.

Veelgestelde vragen