Modulaire productieplanningssoftware: welke modules je als eerste toevoegt

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

Modulaire productieplanningssoftware laat een groeiende fabriek stap voor stap extra planningslagen toevoegen. Ontdek welke modules er bestaan, wat ze gemeen hebben en welke je als eerste toevoegt.

Automatically translated with AI from the original post. Read the English original

Modulaire productieplanningssoftware splitst de planning op in afzonderlijke modules, zoals masterplanning, materiaalplanning, finite scheduling, feedback van de productievloer en rapportage. Zo kun je beginnen met de module die je grootste probleem oplost en de rest toevoegen naarmate de fabriek groeit. Het addertje is dat modules alleen helpen als ze dezelfde gegevens delen en het eens zijn over hetzelfde plan. Dit artikel is bedoeld voor productieplanners in productiefabrieken die een eerste module moeten kiezen en een lappendeken willen voorkomen.

Belangrijkste punten

• Modulaire productieplanningssoftware verdeelt de planning in lagen, zoals hoofdplanning, materiaalplanning, finite scheduling, feedback over de uitvoering en kpi's.
• Modules werken alleen samen als ze één set gedeelde gegevens gebruiken voor artikelen, stuklijsten, routings, resources en kalenders.
• Voeg eerst de module toe die je duurste symptoom verhelpt: tekorten, onuitvoerbare planningen, plannen die niemand volgt of een gebrek aan zicht.
• Vraag elke leverancier of modulair betekent: één suite met gedeelde gegevens, of afzonderlijke producten die via koppelingen zijn verbonden. Het antwoord bepaalt hoeveel integratiewerk je krijgt.
• Test één productfamilie van begin tot eind over twee modules voordat je de rest koopt.

Wat betekent "modulair" in planningssoftware?

Leveranciers gebruiken het woord op twee manieren, en je moet vragen welke je hoort.

De eerste is een suite met modules die één database delen. De beschrijving van manufacturing resource planning op Wikipedia geeft dit idee goed weer. MRP II bestaat uit modules zoals de hoofdproductieplanning, het artikel- en stuklijstbeheer, productiemiddelengegevens, materiaalbehoefteplanning, productiebesturing en capaciteitsplanning. Die modules delen gemeenschappelijke gegevens, zodat ze vrij informatie kunnen uitwisselen. Per definitie zijn ze volledig geïntegreerd, of op zijn minst volledig gekoppeld.

De tweede is een set afzonderlijke producten, elk sterk in één laag, die via koppelingen zijn verbonden. Dat geeft je de vrijheid om later één onderdeel te vervangen, maar het koppelen van gegevens en het testen tussen de onderdelen ligt bij jou.

Geen van beide is fout. Ze verschillen in waar het werk terechtkomt. Bij een suite zit het werk in de configuratie. Bij afzonderlijke producten zit het in de integratie. Weet welke van de twee je koopt voordat je prijzen vergelijkt.

Welke planningslagen kunnen modules worden?

De dag van een planner doorloopt een paar lagen, en elk daarvan kan een module zijn. De namen verschillen per product, maar de logica blijft gelijk.

• Hoofdplanning. De hoofdproductieplanning legt vast welke producten in elke periode worden geproduceerd. Volgens Wikipedia omvatten de invoergegevens onder meer de verwachte vraag, verkooporders, voorraadniveaus, aanvoer, partijgrootte, doorlooptijd en capaciteit. Ze stuurt een materiaalbehoefteplan aan.
• Materiaalplanning. Deze laag verrekent de vraag met voorraad en openstaande aanvoer en stelt orders voor. Dynamics 365 noemt dit master planning. In de documentatie van Microsoft wordt het omschreven als het combineren van beschikbare materialen en capaciteit met wat nodig is, het berekenen van de behoefte en het genereren van geplande orders die planners kunnen wijzigen. Het maakt een onderscheid tussen een netto behoefteplan voor het dagelijks bijvullen en een prognoseplanning voor langetermijnbehoeften.
• Eindige planning. Deze laag plaatst orders in de tijd op resources, met echte beperkingen. Advanced planning and scheduling wordt op Wikipedia beschreven als een aanpak die materialen en capaciteit samen plant en rekening houdt met beperkingen. Traditionele MRP-achtige systemen plannen die daarentegen apart en kunnen plannen opleveren die niet uitvoerbaar zijn.
• Uitvoering en terugkoppeling. Deze laag geeft leidinggevenden hun taken en meldt terug wat er daadwerkelijk is gebeurd.
• KPI's en evaluatie. Doorlooptijd, bezettingsgraad en levering op tijd, vergeleken met het plan.

Kijk naar de kloof tussen de tweede en derde laag, want die verklaart veel te late orders. De documentatie van Microsoft vermeldt dat een geplande productieorder een statische doorlooptijd uit het productrecord gebruikt, terwijl planning op basis van routes met resourcebeperkingen pas gebeurt wanneer de order wordt vastgelegd. De doorlooptijd kan dus veranderen tussen het plan en de vastgelegde order. Dat is geen fout. Het is wat er gebeurt wanneer planninglagen met verschillende informatie werken, en het is de reden waarom een module voor eindige planning het overwegen waard is.

Welke module moet je als eerste toevoegen?

Begin bij het probleem dat je het meeste kost, niet bij de functielijst.

1. Je komt materiaal tekort, of je hebt te veel op voorraad. Begin met materiaalplanning en zorg eerst dat voorraad- en doorlooptijdgegevens kloppen.
2. Het materiaal is er, maar orders worden toch te laat geleverd. Het plan houdt geen rekening met capaciteit. Kijk naar eindige planning.
3. Het schema ziet er op het scherm goed uit en niemand volgt het. Je hebt terugkoppeling uit de uitvoering nodig, zodat planners dezelfde dag al weten van vertragingen.
4. Iedereen discussieert over de cijfers. Voeg een KPI-laag met afgesproken definities toe, voordat je nieuwe planningslogica invoert.
5. Je kunt niet zien of een wijziging zal helpen. Een what-if-mogelijkheid, zoals de simulatie die al in beschrijvingen van MRP II voorkomt, kan later komen.

Een enkele productfamilie is een betere eerste scope dan een enkele afdeling. Zo zie je het effect van één module op de werkelijke leverprestaties.

Wat moeten de modules delen?

Welke architectuur je ook kiest, de modules moeten het eens zijn over een kleine set stamgegevens:

• artikelmaster en stuklijst,
• routings en bewerkingstijden,
• resources, werkplekken en hun agenda's,
• shiftmodellen en beschikbare vaardigheden,
• orderstatussen en hun betekenis.

Als twee modules van een van deze een eigen kopie bijhouden, lopen ze binnen enkele maanden uiteen. Bepaal welke module de master is voor elk object en wie het corrigeert wanneer de productievloer het er niet mee eens is.

Test dit in de demo. Vraag de leverancier om een routingtijd in één module te wijzigen en laat zien waar de wijziging in de andere modules verschijnt en hoelang dat duurt. Als het antwoord "na een export" is, heb je de werkelijke integratie-inspanning ontdekt.

Voorbeeld: één routing, twee antwoorden

Dit is een verzonnen voorbeeld, geen gemeten resultaat. Een fabriek voegt een module voor eindige planning toe naast de bestaande materiaalplanning. De ERP-routing voor een beugel zegt dat de freesbewerking 15 minuten duurt. De planningsmodule is opgezet vanuit een spreadsheet die 22 minuten noemt, omdat dat is wat de operators in de praktijk zien na het instellen en ontbramen.

Het materiaalplan belooft de beugel op donderdag. Het schema zegt maandag. Beide modules werken correct op hun eigen gegevens, en de planner besteedt elke week een uur aan uitleg waarom. De oplossing is geen beter algoritme. Het is één afgesproken tijd, beheerd door één persoon en opgeslagen op één plek die beide modules lezen.

Hoe groei je zonder alles opnieuw te doen?

Groei betekent meestal meer producten, meer shifts, een tweede lijn of een andere vestiging. Plan hiervoor op vier manieren.

• Houd de planningshorizonten duidelijk. Microsoft geeft aan dat masterplanning doorgaans een periode van één week tot zes maanden beslaat en in de meeste bedrijven doorloopt tot de langste cumulatieve doorlooptijd van de betrokken producten. Weet welke module welke horizon beheert, zodat een kortetermijnplanning niet wordt aangezien voor het langetermijnplan.
• Plan de tweede vestiging eerst op papier. In de documentatie van Microsoft staat intercompany-planning vermeld als een apart proces dat vraag en aanbod over juridische entiteiten heen met elkaar verbindt. Verwacht je een tweede fabriek, vraag dan hoe je kandidaat dat aanpakt.
• Kies voor configuratie in plaats van maatwerkcode. Elke aangepaste regel moet je bij elke upgrade opnieuw testen.
• Controleer hoe de planning zich gedraagt bij meer data. Volgens Microsoft zijn plannen die met Planning Optimization worden gemaakt regeneratief, wat betekent dat ze alle behoeften bijwerken en niet alleen de gewijzigde. Vraag elke leverancier hoe lang een volledige planningsrun duurt bij twee keer je huidige volume.

Hoe kies en test je een leverancier?

Vragen die voor elke module werken:

1. Welke data leest en schrijft deze module, en uit welk systeem?
2. Wat gebeurt er met de planning wanneer een spoedorder, een machinestoring of een ontbrekende medewerker binnenkomt? Kan een planner opnieuw plannen zonder specialist?
3. Kan een planner zien waarom de module een order op een bepaald moment heeft ingepland? Planningen die als een black box werken, zijn lastig te verdedigen in een overleg op de werkvloer.
4. Hoe worden upgrades afgehandeld, en wie test de koppelingen daarna?
5. Wat kost het om de volgende module aan te sluiten, en niet alleen wat de licentie kost?
6. Kun je het plan en de masterdata exporteren in een bruikbaar formaat?

Draai daarna een pilot. Neem één productfamilie en twee weken echte orders. Plan ze in de kandidaatmodule, plan ze op de manier waarop je dat nu doet en vergelijk de resultaten met wat er werkelijk is gebeurd. Registreer ook de inspanning: hoeveel handmatige correcties en hoeveel uren voorbereiding.

Veelgemaakte fouten

• Alle modules tegelijk aanschaffen. Je kunt dan niet zien welke module heeft geholpen, en het datawerk komt in één grote klap op je af.
• Beginnen met een module die niet bij het symptoom past. Een finite scheduler op slechte stuklijsten levert precieze onzin op.
• Twee kopieën van masterdata. De modules lopen uiteen en niemand vertrouwt er nog één.
• De mensenlaag negeren. Planners moeten kunnen zien waarom een planning er zo uitziet, anders gaan ze hem overschrijven.
• Geen eigenaar voor de koppelingen. Wanneer een upgrade er één breekt, is niemand verantwoordelijk.
• Plannen op het volume van vandaag. Vraag naar de volgende productfamilie of het volgende ploegenmodel voordat je tekent.

Waar Polaris past

Wil je een planningsstack die is opgebouwd uit modules, dan is iFAKT Polaris de moeite van het bekijken waard. iFAKT presenteert Polaris als productiesoftware die ERP-data combineert met een digitale tweeling van de productie, georganiseerd in zeven modules. De Polaris Designer bouwt een kennisgraaf van product, proces en middelen als gedeelde bron van waarheid. De Polaris Optimizer genereert productieplannen binnen beperkingen zoals middelen, ploegen, zones, kwalificaties en capaciteiten. Test het op één productfamilie, met je eigen data, zoals je dat bij elke andere kandidaat zou doen.

Gerelateerde onderwerpen om verder te verkennen

• Kwaliteit van masterdata. Wie is eigenaar van routings en stuklijsten, en hoe worden fouten gecorrigeerd?
• Finite versus infinite capaciteitsplanning. Wanneer een materiaalplan voldoende is en wanneer niet.
• Planningshorizonten en bevroren zones. Hoe ver vooruit elke laag plant, en wanneer de planning ophoudt te veranderen.
• Scenarioplanning. Hoe je twee plannen met elkaar vergelijkt voordat je je vastlegt.
• Planning over meerdere locaties. Wat verandert er wanneer vraag en aanbod worden gedeeld tussen fabrieken.

Volgende stap

Modulaire productieplanningssoftware loont wanneer je de module kiest op basis van het symptoom. Schrijf het grootste planningsprobleem in je fabriek op, bepaal tot welke laag het behoort en vraag twee leveranciers om te laten zien hoe die module werkt op een van je eigen productfamilies.