Een traditionele ERP is gebouwd voor een persoon achter een scherm. De functies, integraties en het audittrail gaan ervan uit dat werk binnenkomt via formulieren die een mens invult. Een AI-native ERP is gebouwd voor een agent als de primaire gebruiker: elke actie die het systeem kan ondernemen, wordt blootgesteld als een getypte tool die een agent kan aanroepen via een open protocol, en elke oproep wordt gecontroleerd op basis van de rechten van de persoon die de agent vertegenwoordigt. Mensen gebruiken nog steeds schermen om te kijken en beslissen; ze zijn niet langer de enige manier waarop werk wordt gedaan.
Dat is een architectonisch verschil in plaats van een verschil in functies. Een traditionele ERP met een toegevoegde assistent leidt het werk nog steeds via de persoon. Een AI-native ERP leidt het werk via de agent en houdt het record als bijproduct. De rest van dit stuk toont waar de twee paden splitsen en wat daaruit voortvloeit.
Volg één inkooporder door beide systemen
Begin met iets gewoons. Een leverancier genaamd Northwind heeft een offerte voor voorraad gegeven, de offerte is acceptabel, en het bedrijf heeft een inkooporder nodig die moet worden aangemaakt, verzonden en gematcht wanneer de goederen en de factuur aankomen. Volg dat verzoek door elke architectuur en het verschil is zichtbaar voordat er een functieslijst wordt geopend.
In het traditionele systeem is het pad het pad van een persoon. Iemand opent de inkoopmodule, vindt of creëert de leverancier, voert de regels van de offerte in, controleert het kostenplaats, slaat op, exporteert het document, voegt het toe aan een e-mail en keert later terug om de goederen te ontvangen en de factuur te matchen. Als het systeem een assistent heeft, kan deze de regels van de offerte vooraf invullen of de e-mail opstellen. De persoon blijft degene die van scherm naar scherm beweegt, en de assistent bereikt alleen de schermen waarmee de leverancier heeft gekozen om verbinding te maken.
In het AI-native systeem is het pad het pad van een agent. De persoon vertelt hun agent wat ze willen. De agent vraagt de werkruimte welke tools hij mag gebruiken, en de werkruimte antwoordt met een gefilterde lijst: leverancier opzoeken, inkooporder aanmaken, document verzenden, goederen ontvangen, factuur matchen, en niets dat de rol van die persoon niet toestaat. De agent roept die tools in volgorde aan, de werkruimte controleert elke oproep opnieuw terwijl deze draait, en de inkooporder, het verzonden document en de latere match bestaan in het systeem precies zoals als een persoon ze had ingevoerd. De persoon ziet het resultaat en het logboek, niet de formulieren.
In een AI-native systeem gaat de aanvraag van de persoon naar hun agent, vervolgens door een toestemmingslaag, voordat er een module wordt aangeraakt. Dezelfde laag die de toegang van een persoon regelt, regelt ook die van de agent.
De primaire gebruiker is het verschil
Alles wat volgt in de vergelijking tussen AI-native ERP en traditionele ERP komt voort uit één ontwerpbepaling: wie de software verwacht te bedienen. Traditionele ERP beantwoordt die vraag met een persoon, en veertig jaar goed werk is gestoken in het gemakkelijker maken van de taak van de persoon. Schermen werden sneller, workflows werden configureerbaar, mobiele apps kwamen, en uiteindelijk verscheen er een assistent naast het formulier. Niets daarvan veranderde wie de controle had.
AI-native ERP beantwoordt dezelfde vraag met een agent die namens een persoon handelt. Zodra dat het antwoord is, moet het product anders worden gebouwd dan de eerste regel. Elke functionaliteit heeft een tooldefinitie nodig met een naam, getypte invoer en een resultaat, niet alleen een scherm. Het toestemmingsmodel moet per oproep werken, niet per sessie, omdat een enkele aanvraag kan uitmonden in een dozijn oproepen over modules. Het protocol moet open zijn, omdat de agent die de oproep doet, mogelijk tot de klant behoort en niet tot de leverancier. En het auditlogboek moet registreren wat de agent deed met dezelfde nauwkeurigheid als wat een persoon deed, omdat dat logboek nu de primaire manier is waarop een manager het werk beoordeelt.
Wat daaruit volgt: zes gevolgen
De onderstaande tabel is de praktische vergelijking. Elke rij is een gevolg van de beslissing over de primaire gebruiker in plaats van een functie die de ene leverancier heeft gekozen en de andere niet.
| Traditionele ERP | AI-native ERP | |
|---|---|---|
| Primaire gebruiker | Een persoon achter een scherm | Een agent die namens een persoon handelt |
| Hoe werk binnenkomt | Formulieren, imports, integraties gebouwd voor elke koppeling | Tooloproepen via een open protocol; schermen blijven voor beoordeling |
| Bereik van de AI | De functies waarmee de leverancier de assistent heeft verbonden | Elke actie die het systeem heeft, omdat elke actie een hulpmiddel is. |
| Welke agent | De leverancier, binnen het product, indien van toepassing. | Elke compatibele cliënt, inclusief degene die de klant al gebruikt. |
| Machtigingen | Per gebruiker, per sessie. | Per gebruiker, gecontroleerd wanneer hulpmiddelen worden aangeboden en opnieuw bij elke oproep. |
| Audit. | Wie welke record heeft gewijzigd. | Wie vroeg, welke agent handelde, welke hulpmiddelen werden uitgevoerd met welke invoer en resultaten. |
Rijen zijn architectonische gevolgen, geen scores. Een traditioneel ERP kan uitstekend zijn in waar het voor is gebouwd.
De rij die kopers het meest verrast is bereik. Een assistent toegevoegd aan een traditioneel systeem voelt breed aan in een demo omdat de demo is gescript rond de functies die het aanraakt. In dagelijks gebruik stopt het aan de rand van die functies, en de persoon neemt het over. In een agent-native systeem is de grens de permissies van de persoon, wat een andere en nuttigere grens is.
Wat niet verandert
Het is belangrijk om precies te zijn over wat hetzelfde blijft, omdat leveranciers aan beide zijden dit vervagen. Het datamodel verandert niet. Dubbel boekhouden is dubbel boekhouden, of een agent of een persoon het journaal boekt. Belastingregels, multi-valuta verwerking, voorraadwaardering, periode afsluiting en documentnummering zijn dezelfde problemen met dezelfde antwoorden. Een AI-native systeem dat deze verkeerd krijgt, is een slecht ERP met een goede interface voor agents, wat geen ruil is die de moeite waard is.
Permissies veranderen in principe ook niet; ze veranderen in waar ze worden afgedwongen. Een traditioneel systeem controleert wat een gebruiker mag zien wanneer een scherm laadt. Een AI-native systeem moet controleren wat een gebruiker mag doen elke keer dat een hulpmiddel wordt aangeroepen, omdat er geen schermlading is om de controle aan te hangen. De regel is hetzelfde. Het handhavingspunt verschuift.
De behoefte aan oordeel verandert niet. Een agent zal de inkooporder aanmaken en de factuur matchen; hij zal ook stoppen wanneer twee leveranciersrecords op hetzelfde bedrijf lijken, wanneer een match buiten de toleranties valt, of wanneer een goedkeuring boven de autoriteit van de gebruiker ligt. Die pauzes zijn het systeem dat werkt zoals bedoeld, en de eerste weken met een agent lijken veel op de eerste weken met een capabele nieuwe collega.
Waar traditionele ERP nog steeds het juiste antwoord is
Een eerlijke vergelijking moet zeggen wanneer de oudere architectuur wint. Als het bedrijf diepgaand is, gevalideerde productie of gereguleerde processen heeft met tientallen jaren aan maatwerk binnen een gevestigde suite, is de kosten van verhuizen reëel en de assistent die die suite nu levert, kan voldoende zijn voor wat het team daadwerkelijk van AI nodig heeft, wat vaak samenvatten, opstellen en vragen over de gegevens beantwoorden is. Als de operatie uit een handvol mensen bestaat met een boekhoudpakket en een spreadsheet, is beide architecturen meer dan ze gebruiken.
De zaak voor AI-native is het sterkst in het midden: een bedrijf met voldoende routine, cross-module werk dat het invoeren een baan op zich is geworden, en een team dat al een agent voor andere dingen gebruikt en het liever op het bedrijf richt dan een andere chatvenster van een leverancier te leren. Daar is het doorsturen van werk via de agent snel rendabel, en waar het kunnen meenemen van je eigen agent stopt met een slogan en begint met een regel op de kostenlijst, aangezien een werkruimte geen AI voor je uitvoert wanneer je eigen agent de redenering doet.
Hoe te herkennen welke architectuur je wordt getoond
Demo's zijn ontworpen om de twee op elkaar te laten lijken. De volgende volgorde scheidt ze in minder dan een uur en heeft geen technische persoon nodig om het uit te voeren.
- Breng uw eigen agent meeVerbind de agent die je al gebruikt (Claude, ChatGPT of een andere MCP-client) van buiten het product van de leverancier. Als dat niet mogelijk is, heb je je antwoord op de protocolvraag.
- Vraag om de lijst met toolsLaat de agent opsommen wat hij mag doen. Controleer of de lijst lang is, de modules de aandacht heeft die je belangrijk vindt, en verandert wanneer je inlogt als een meer beperkte gebruiker.
- Voltooi één resultaatVraag de agent om de follow-up voor één inkooporder aan te maken, te verzenden en in te plannen zonder dat iemand het scherm aanraakt. Kijk of het afgemaakt wordt of halverwege teruggegeven wordt aan een persoon.
- Lees het logboekVind het record van wat de agent deed: wie vroeg, welke tools draaiden, met welke invoer. Als dat logboek dunner is dan het logboek voor een persoon, is de agent een gast in het systeem in plaats van een gebruiker ervan.
Sois is één implementatie van de AI-native architectuur, en het is de enige die we precies kunnen beschrijven. Een werkruimte is een MCP-server. Elke compatibele client verbindt door het adres van de werkruimte toe te voegen en eenmaal in te loggen via OAuth, zonder token om in te voeren. De aangeboden tools worden gefilterd op basis van de rol van de gebruiker voordat de agent ze ziet en opnieuw gecontroleerd wanneer elke tool draait; toegang faalt gesloten. Uitgaven kunnen per integratie worden beperkt en elke actie wordt gelogd. De modules eronder zijn de modules die je zou verwachten van een ERP: contacten en CRM, inbox, documenten, agenda, taken, boekhouding met facturering, rekeningen, inkoopfacturen en multi-valuta, deals, magazijn en voorraad, en een marktplaats van apps.
Of je het nu kiest of niet, voer de bovenstaande volgorde uit op wat je ook maar wordt getoond. De vraag die je moet blijven stellen is niet welk product AI heeft, aangezien ze allemaal zeggen dat ze dat hebben, maar door wie het product is gebouwd om bediend te worden.
Vragen die mensen stellen
Is AI-native ERP hetzelfde als agentic ERP?
In de praktijk, ja. AI-native en agent-native beschrijven hoe het systeem is gebouwd; agentic beschrijft wat erin gebeurt. Alle drie de zinnen wijzen op systemen waar een agent de software kan bedienen onder de permissies van een persoon, in tegenstelling tot systemen die een assistent aan schermen hebben toegevoegd die voor mensen zijn gebouwd.
Heeft een AI-native ERP nog steeds schermen?
Ja. Mensen gebruiken schermen om te kijken, te beoordelen en te beslissen, en om direct te werken wanneer ze dat willen. Het verschil is dat schermen niet langer de enige manier zijn waarop werk het systeem kan binnenkomen.
Kan een traditionele ERP AI-native worden door een assistent toe te voegen?
Niet alleen daarmee. Een assistent helpt een persoon om de bestaande schermen te bedienen en bereikt alleen de functies die de leverancier heeft verbonden. AI-native worden betekent dat elke actie wordt blootgesteld als een geautoriseerd hulpmiddel via een open protocol, wat een herbouw van de interface-laag is in plaats van een toevoeging.
Is het veilig om een agent transacties te laten plaatsen?
Het is net zo veilig als de handhaving eronder. Zoek naar permissies die bij elke oproep worden gecontroleerd, een bestedingslimiet en een logboek dat de acties van de agent met dezelfde details als die van een persoon vastlegt. De agent moet handelen met de autoriteit van de persoon die hij vertegenwoordigt en nooit meer.
- Model Context Protocol specificatie: tools hoe hulpmiddelen worden gedefinieerd, vermeld en genoemd, en de vereiste dat servers toegangscontroles implementeren
- Sois documentatie: de werkruimte MCP-server het eindpunt, OAuth-inloggen, rol-gefilterde hulplijst en fail-closed gedrag zoals hierboven beschreven
- Sois: beveiliging en de machtigingslaag permissies die worden afgedwongen wanneer hulpmiddelen worden aangeboden en wanneer ze draaien; bestedingslimieten; logging
Dit artikel wordt herzien wanneer de producten die het beschrijft veranderen. Volgende geplande herziening: 4 december 2026.