Leermoment 1: de orderstroom en de planningsmodule praten niet real-time met elkaar
Het patroon dat we keer op keer tegenkomen: orders leven in het ERP of het CRM, capaciteitsplanning zit in een apart systeem of in een spreadsheet ernaast. De koppeling tussen beide is een export, een nachtelijke batch, of een handmatige kopieeractie door de planner. Dat betekent dat de planning op het moment dat een nieuwe order binnenkomt al verouderd is. Planners werken met een foto van gisteren terwijl de werkelijkheid van vandaag al verder is gegaan. Ze proberen bij te blijven via telefoon, e-mail en geheugen. Het werkt, totdat een grote order aankomt, een klant een spoedwijziging doorgeeft of een leverancier laat weten dat materiaal vertraagd is. Dan valt de façade weg en wordt zichtbaar dat de planning nooit de echte toestand weerspiegelde. Wat dit vraagt is een datamodel waarin de orderstroom en de beschikbare capaciteit één bron delen, zodat een nieuwe order of een statuswijziging direct zichtbaar is in de planningslaag, zonder tussenkomst van een mens.
Leermoment 2: capaciteitsgroepen zijn te grof om pieken op tijd te zien
Als capaciteitsplanning en orderstroom al gekoppeld zijn, stuit je op een volgend probleem: de manier waarop capaciteit is ingedeeld. Veel bedrijven werken met brede capaciteitsgroepen, zoals 'verspaning', 'assemblage' of 'oppervlaktebehandeling'. Op papier is er dan ruimte. In werkelijkheid zit één specifieke CNC-machine of één bepaalde operator die een certificering heeft voor dat stuk werk, volledig vol. Die piek is pas zichtbaar als de orderbevestiging al de deur uit is en de leverbelofte al staat. Verfijnde capaciteitsgroepen kost tijd om op te zetten en te onderhouden, maar de prijs van te grove groepen is hoger: te late leveringen, intern brandjes blussen en klanten die bellen. De oplossing is niet een nieuw planningspakket installeren. De oplossing begint bij het datamodel: welke resources zijn echt beperkend, op welk niveau wil je dat bijhouden, en is dat niveau ook gevoed door actuele bezettingsdata vanuit de werkvloer?
Leermoment 3: uitzonderingen gaan buiten het systeem om
Spoedorders, uitval van een machine, een medewerker die ziek uitvalt, een klant die halverwege de week de prioriteit omgooit. Allemaal uitzonderingen die in de praktijk worden opgelost via WhatsApp-groepen, telefoon of mondeling overleg op de werkvloer. Het systeem wordt daarna niet bijgewerkt, of pas aan het einde van de dag als de planner er even aan toekomt. Het gevolg is dat de planning in het systeem en de werkelijke situatie op de vloer steeds verder uit elkaar lopen. Dat ondermijnt het vertrouwen in het systeem: als iedereen weet dat het systeem de werkelijkheid niet weergeeft, stopt iedereen ermee het bij te houden. Zo ontstaat een neerwaartse spiraal waarbij de uitzondering de norm wordt en het systeem decoratie is. Dit los je niet op met een regel die zegt 'je moet het altijd invullen'. Je lost het op door de drempel om een uitzondering te registreren lager te maken dan de drempel om de telefoon te pakken, en door het systeem zo te bouwen dat het actief om bevestiging vraagt als afwijkingen gesignaleerd worden.
Wat vraagt dit structureel van je datamodel en systeemarchitectuur?
De drie leermomenten wijzen naar hetzelfde onderliggende probleem: capaciteitsplanning koppelen aan de orderstroom lukt niet als het datamodel niet klopt. Niet als er geen gedeeld model is voor orders, resources en bezetting. Niet als uitzonderingen een uitweg buiten het systeem hebben. Wat je nodig hebt is een architectuur waarin order-events direct de planningslaag raken, zonder batch en zonder handmatige kopieerstap. Capaciteitsgroepen die gedefinieerd zijn op het niveau waarop de bottleneck echt zit, gevoed door actuele data van de vloer. En een registratiemechanisme voor uitzonderingen dat eenvoudiger is dan een WhatsApp-bericht sturen. Dat vraagt soms om het ERP of het MES opnieuw te bekijken, soms om een AI-laag die ordermutaties herkent en de planning proactief bijwerkt. Maar altijd begint het bij de vraag: wie is eigenaar van welk gegeven, en op welk moment is dat gegeven beschikbaar voor de planning? Zolang die vraag niet scherp beantwoord is, lost een nieuw pakket niets op.