De aanname klinkt verstandig: kies één groot ERP-systeem voor alles, dan heb je één waarheid, één leverancier en één plek waar alles samenkomt. Veel directies zien dat als de veilige keuze. Wie alles in één pakket stopt, hoeft geen koppelingen te beheren en geen discussies te voeren over welk systeem gelijk heeft.
Het cijfer vertelt een ander verhaal. Gartner voorspelt dat tegen 2027 meer dan 70% van de recent geïmplementeerde ERP-initiatieven er niet in slaagt om de oorspronkelijke businessdoelen volledig te halen. Als verklaring noemt Gartner onder meer dat veel ERP-trajecten werden opgezet als monolithische systemen op basis van IT-gedreven aannames, zonder voldoende betrokkenheid van de business.
Meer dan zeven op tien. Dat is geen randfenomeen van slecht geleide projecten, dat is het dominante patroon. En het opvallende is dat het niet aan de software ligt. De grote pakketten zijn volwassen. Wat misloopt, is de aanname dat één systeem alle beslissingen van een organisatie kan vastleggen in één datamodel, één procesflow en één releasekalender.
Niet het aantal systemen bepaalt je risico, maar hoe snel je een beslissing kunt veranderen zonder dat de rest meebeweegt.
Waarom de monoliet faalt
Een monolithisch ERP koppelt alles aan alles. Dat is precies het verkoopargument, en precies het probleem. Wil je je orderproces aanpassen omdat de markt verandert? Dan raak je Finance, voorraad en rapportering tegelijk. Elke wijziging wordt een project met een stuurgroep, omdat elke wijziging overal doorwerkt.
Het tweede probleem is de releasekalender. In een monoliet bepaalt de leverancier wanneer nieuwe functionaliteit beschikbaar komt, en in welke volgorde. Jouw prioriteit staat in de wachtrij achter die van duizenden andere klanten. Organisaties die snel willen schakelen, bouwen daarom maatwerk bovenop het pakket. Dat maatwerk maakt de volgende upgrade duurder, waardoor upgrades worden uitgesteld, waardoor het maatwerk verder groeit. Zo ontstaat het systeem dat niemand nog durft aan te raken.
Het derde probleem is organisatorisch. Een groep met meerdere entiteiten, elk met eigen processen, wordt in een monoliet gedwongen tot één werkwijze. Dat kan een goede keuze zijn als die werkwijze bewust is gekozen. Meestal is ze het gevolg van wat het pakket standaard doet. De business krijgt dan een systeem dat klopt volgens de leverancier en niet volgens de manier waarop het bedrijf zijn geld verdient.
Dat is wat Gartner bedoelt met IT-gedreven aannames. De technische beslissing over het platform loopt vooruit op de zakelijke beslissing over hoe je wilt werken.
Beter alternatief
Composable architecture draait de volgorde om. Je start niet bij het pakket, maar bij de bouwstenen van je organisatie:
- Welke processen zijn onderscheidend?
- Welke zijn generiek?
- En welke veranderen het vaakst?
Voor de generieke processen, denk aan grootboek of loonadministratie, kies je een stabiele kern die je zo weinig mogelijk aanpast. Voor de processen waarmee je het verschil maakt, kies je componenten die je apart kunt vervangen, uitbreiden of stopzetten.
Dat vraagt dingen die in een monoliet vaak ontbreken.
- Een gedeelde datalaag met duidelijke definities: Wat is een klant? Wat is een order? Wie is eigenaar?
- Een integratielaag die bewust wordt beheerd, niet als bijzaak van elk project.
- Een architectuurrol met mandaat, die beslist welke component waar thuishoort en die 'nee' mag zeggen tegen een nieuwe tool die het landschap verder versnippert.
Composable betekent dus niet 'meer systemen'. Het betekent dat elk systeem een afgebakende verantwoordelijkheid heeft en dat je die verantwoordelijkheid kunt verplaatsen zonder alles om te gooien. De discipline verschuift van het beheren van één pakket naar het bewaken van de grenzen ertussen.
De rol van onafhankelijk advies zit in die grenzen. Een leverancier van een monolithisch ERP heeft er belang bij dat zoveel mogelijk in zijn pakket landt. Een integrator heeft er belang bij dat er veel te koppelen valt. Wie geen eigen software verkoopt, kan de vraag stellen die er echt toe doet: welke beslissing moet dit systeem ondersteunen, en hoe vaak gaat die beslissing veranderen?
En hoe zit dat in de praktijk?
Een patroon dat we vaak tegenkomen bij groepen met meerdere entiteiten: het hoofdkantoor kiest één ERP voor de hele groep, met als doel uniforme rapportering. Twee jaar later draait de kern, maar elke entiteit heeft eigen Excel-lagen, eigen tussenoplossingen en eigen definities opgebouwd rond wat het pakket niet kon. De rapportering is uniform op papier en handwerk in de praktijk.
De uitweg zit zelden in een nieuwe migratie. Ze zit in het benoemen van wat de kern echt moet doen, het loskoppelen van de processen die per entiteit verschillen, en het vastleggen van de definities waarop de groep wil sturen. Pas dan wordt duidelijk welke component vervangen moet worden en welke gewoon kan blijven draaien.
Het grootste risico van een monolithisch ERP is niet dat het kapotgaat. Het is dat het blijft werken terwijl je organisatie erom heen moet werken. Niet één systeem dat alles doet, maar een architectuur die je beslissingen volgt: dat is wat een transformatie in 2026 nodig heeft.
Sta jij voor een ERP-keuze of zit je vast in een pakket dat niet meer meebeweegt? Spar met ideeds over jouw transformatie-aanpak.
