Waarom capaciteitsplanning in maakbedrijven structureel achter de feiten aanloopt
De meeste productiebedrijven plannen capaciteit op basis van een model: hoeveel uur heeft een bewerking gemiddeld nodig, hoeveel mensen staan er ingeroosterd, hoeveel machine-uren zijn beschikbaar. Dat model klopt op papier. Het probleem is dat de werkelijkheid op de vloer voortdurend afwijkt van dat model, en dat de planning dat pas merkt als iemand aan de bel trekt. Een monteur meldt zich ziek, een machine valt uit, een order blijkt lastiger dan geraamd. Al die afwijkingen stapelen zich op, maar de planning past zich niet automatisch aan. De planner corrigeert handmatig, als hij het al weet. Tegen die tijd is de verstoring al verder doorgestroomd.
Knelpunt 1: realtime bezettingsdata zit niet in het planningssysteem
In de meeste maakbedrijven leeft bezettingsinformatie op drie plekken tegelijk: in het hoofd van de werkvoorbereider, in een urenschrijfsysteem dat pas de volgende ochtend gesynchroniseerd wordt, en in een Excel-sheet die de planner zelf bijhoudt. Het ERP of het planningspakket ziet geen van die drie bronnen direct. Wat het systeem toont is een capaciteitsbeeld dat gebaseerd is op de situatie van gisteravond, of erger: van het moment dat de maakorder aangemaakt werd. Bijsturen op basis van die data is bijsturen op basis van verleden tijd. Pas als de werkplek fysiek stilstaat of de order te laat dreigt te worden, wordt de afwijking zichtbaar. Op dat moment zijn de opties beperkt.
Knelpunt 2: verzuim en uitval worden niet direct doorvertaald naar capaciteit
Een ziekmelding om half acht 's ochtends verdwijnt in het HR-systeem. De planning weet het niet, of weet het via een appje van de teamleider. Een machinestoring gaat naar de onderhoudsdienst. De planning hoort het als de storing al een uur oud is. Het gevolg is dat de capaciteitsplanning voor die dag nog steeds uitgaat van de oorspronkelijke bezetting, terwijl de vloer al tekortkomt. Orders worden niet herverdeeld, prioriteiten worden niet aangepast, en de klant merkt het pas aan het einde van de dag of de week. Dit is geen organisatieprobleem dat je oplost met betere communicatie. Het is een architectuurprobleem: het planningssysteem ontvangt geen signalen uit de systemen waar de uitval geregistreerd wordt.
Knelpunt 3: de koppeling met inkoop en levertijden ontbreekt
Capaciteitsplanning gaat niet alleen over mensen en machines. Het gaat ook over materiaal. Als een component twee weken later binnenkomt dan verwacht, heeft dat direct gevolgen voor de volgorde van orders en daarmee voor de bezetting van werkplekken. Maar in de meeste bedrijven staat die informatie in het inkoopsysteem of bij de inkoper zelf. De planning haalt die informatie pas op als iemand er actief naar vraagt. Knelpunten in de toeleveringsketen worden zichtbaar op het moment dat de productielijn stilstaat bij gebrek aan materiaal, niet een week eerder toen bijsturen nog mogelijk was. De drie problemen hangen samen: geen realtime bezettingsdata, geen automatische vertaling van uitval naar capaciteit, geen koppeling met inkoop. Ze versterken elkaar en maken dat de planning altijd een reactieve bezigheid blijft.
Wanneer verandert software voor capaciteitsplanning hier iets aan?
Software helpt pas als de databronnen gekoppeld zijn. Dat klinkt voor de hand liggend, maar is in de praktijk het moeilijkste deel. Een nieuw planningspakket bovenop een bestaand ERP en een los urenschrijfsysteem lost niets op als de drie systemen elkaar niet in realtime voeden. Wat wel werkt: een AI-worker die signalen uit HR, onderhoud en inkoop ophaalt en de planning automatisch doorrekent op gewijzigde capaciteit, of een maatwerk planningssysteem dat vanaf de kern gebouwd is op de databronnen die in jouw bedrijf bestaan. Bonsai bouwt beide, afhankelijk van wat de situatie vraagt. Als het bestaande ERP goed genoeg is maar de koppelingen ontbreken, bouwen we een AI-laag eromheen die de signalen verbindt en de planner op tijd waarschuwt. Als het kernsysteem zelf de bottleneck is, bouwen we dat opnieuw, AI-native, zodat bezettingsdata, uitval en inkoopstatus altijd in hetzelfde model leven. Wanneer helpt het niet? Als de onderliggende data niet betrouwbaar is. Software die slechte of onvolledige invoer beter presenteert, maakt het probleem eerder groter dan kleiner. Eerst de databasis op orde, dan automatisering.