Productiesimulatie voor verstoringen en wijzigingen in productmix

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

Productiesimulatie voor verstoringen: test storingen, afwezigheid, late materialen en wijzigingen in de productmix in een model voordat ze je lijn raken. Een praktische gids.

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

Met een productiesimulatie speel je een verstoring in een model af: een storing bij je bottleneck, een ontbrekende operator, een late levering of een verschuiving in de productmix. Je ziet dan wat er met output en doorlooptijd gebeurt, zonder aan de echte lijn te komen. Dit artikel is bedoeld voor productieplanners die willen weten welke verstoringen ze moeten simuleren, welke data ze nodig hebben en hoe ze de resultaten lezen.

Belangrijkste punten

• Met een productiesimulatie speel je een verstoring af, zoals een storing of een verschuiving in de productmix, in een model. Zo zie je het effect op output en doorlooptijd voordat het zich voordoet.
• Kies verstoringen op basis van waarschijnlijkheid en impact, gebaseerd op je eigen registraties. Elke denkbare gebeurtenis modelleren maakt het model alleen trager en minder betrouwbaar.
• Een wijziging in de productmix kan de bottleneck verplaatsen, ook als het totale volume gelijk blijft, omdat varianten de gedeelde machines voor verschillende tijden gebruiken.
• Omdat storingen willekeurig optreden, draai je elk scenario meerdere keren en vergelijk je bandbreedtes in plaats van één resultaat.
• Controleer het model eerst tegen een afgelopen periode en houd een korte lijst met verstoringsscenario’s bij die je opnieuw draait wanneer het proces verandert.

Wat kan een simulatie je laten zien over een verstoring?

Een verstoring is alles wat het plan onjuist maakt: minder capaciteit dan gepland, materiaal dat er niet is, of een vraag die er anders uitziet dan de forecast. Een plan beantwoordt de vraag "wat moet er gebeuren". Een fabriekssimulatie beantwoordt de vraag "wat gebeurt er als dit misgaat".

NIST beschrijft discrete-eventsimulatie als een manier om een productiesysteem te analyseren onder verschillende scenario’s en omstandigheden, en om doorvoer, capaciteit en bottlenecks te meten. Dezelfde NIST-pagina noemt het belangrijkste obstakel: het is lastig om tijdig en nauwkeurige data over apparatuur en processen te krijgen. Houd dat in gedachten, want het bepaalt hoeveel vertrouwen je in een resultaat kunt hebben.

Het nuttigste wat een simulatie laat zien, is waar de pijn terechtkomt. Een stilstand bij één machine raakt zelden alleen die machine. Er ontstaat werk voor die machine, de stations erachter krijgen geen input en orders die die machine nooit hebben aangeraakt, lopen vertraging op. Een model maakt die keten in minuten zichtbaar, in plaats van weken brandjes blussen.

Het helpt ook om te zien dat de bottleneck kan verschuiven. De inleiding van het Lean Enterprise Institute over de theory of constraints stelt dat je na het ingrijpen op de beperking moet nagaan of die zich naar een ander deel van het systeem heeft verplaatst. Een verstoring doet hetzelfde, zonder dat je erom vraagt. Speel dat eerst in het model af.

Welke verstoringen zijn het simuleren waard?

Niet alle. Begin met een korte lijst en kies op basis van twee vragen: hoe vaak komt het voor, en hoeveel kost het als het gebeurt?

Typische kandidaten:

• Machinestilstanden. Modelleer hoe vaak een machine stilvalt en hoe lang reparaties duren. Gemiddelden verbergen de lange reparaties, en juist die doen de meeste pijn. Als je onderhoudslog echte stilstandduren bevat, gebruik dan de spreiding en niet alleen het gemiddelde.
• Personeel. Afwezigheden, een ontbrekende vaardigheid op één ploeg, limieten voor overwerk.
• Materiaal. Een late levering, een te korte levering, een kwaliteitsblokkade op een inkomende partij.
• Kwaliteitsverlies. Afval of herwerk dat onderdelen terugstuurt naar een station.
• Spoedorders. Een urgente order die de wachtrij voorbijsteekt en extra omstellingen afdwingt.
• Vraagverschuivingen. Een andere verdeling over varianten, of een plotselinge volumestijging.

Gebruik je eigen gegevens om ze te rangschikken. Kijk naar het stilstandlogboek van vorig jaar, de ploegrapporten en de lijst met te late orders. Als een verstoring er elke maand in voorkomt, simuleer haar. Als ze in vijf jaar één keer is voorgekomen, noteer haar dan en laat haar voorlopig buiten beschouwing.

Hoe simuleer je een wijziging in de productmix?

De productmix is het aandeel van elke variant in je orderstroom. Dat is belangrijk omdat varianten zelden even lang gebruikmaken van gedeelde machines. Verandert de mix, dan verandert de belasting van elke resource, ook als het totale aantal stuks gelijk blijft.

Een paper van de Winter Simulation Conference over interactieve productiesimulatie laat dit effect zien in een batchoven-afdeling. Producten kunnen alleen onder specifieke combinatieregels samen in een batch, dus de volgorde van producten beïnvloedt het ovengebruik, en de bottleneck verschuift naarmate de mix verandert. Dat is een oud paper en een bijzonder geval, maar de les geldt voor de meeste gedeelde resources.

Zo kun je er stap voor stap mee aan de slag:

1. Leg een uitgangspunt vast. Gebruik de huidige mix en zorg dat het model de recente output en doorlooptijden reproduceert.
2. Definieer de nieuwe mix. Schrijf die uit als aandelen van het volume, bijvoorbeeld "variant B groeit van een minderheid naar de helft van de orders". Bepaal of het totale volume gelijk blijft of groeit.
3. Controleer de gegevens per variant. Elke variant heeft zijn eigen routing, procestijden en omsteltijden nodig. Omstellingen tussen varianten zijn vaak belangrijker dan de looptijden.
4. Draai de nieuwe mix. Vergelijk de bezetting per resource, de wachtrijlengtes en de doorlooptijd per variant.
5. Verschuif de mix in stappen. Test niet alleen de eindsituatie. Verschuif de mix in een paar stappen om het punt te vinden waarop de bottleneck naar een andere resource verschuift of waarop de doorlooptijd snel begint te stijgen.
6. Schrijf op wat je zou veranderen. Een tweede ploeg, een buffer, een andere volgorderegel, een extra gereedschap op een tweede machine. Test die wijzigingen daarna in hetzelfde model.

Voorbeeld: een globale controle op de achtergrond (hypothetische getallen)

Dit voorbeeld is verzonnen om de logica te tonen. Het is geen gemeten resultaat.

Een cel heeft één freesmachine. Variant A duurt daar 6 minuten en variant B 10 minuten. Vandaag is 70% van de orders A en 30% B. De gemiddelde tijd per stuk is 0,7 × 6 + 0,3 × 10 = 7,2 minuten. In een shift van 450 minuten kan de freesmachine ongeveer 62 stuks maken.

Nu verschuift de mix naar 50% A en 50% B. Het gemiddelde wordt 8 minuten, en diezelfde shift levert ongeveer 56 stuks op. Dat is ruwweg 10% minder output, alleen door de mix, zonder enige storing.

Voeg een stilstand van 45 minuten toe. De freesmachine heeft nu 405 minuten, en de shift levert ongeveer 50 stuks op. Twee schijnbaar onschuldige wijzigingen kostten samen ruim een vijfde van de output.

Deze rekensom is een goede eerste controle, en je moet hem doen voordat je een model bouwt. Wat ze niet kan laten zien, zijn wachtrijen, omstellingen, batchregels, willekeurige stilstanden en het effect op het volgende station. Dat voegt de simulatie toe.

Welke gegevens hebben de scenario's nodig?

Verstoringsscenario's hebben een paar dingen nodig die het normale model misschien niet heeft. Controleer deze lijst voordat je resultaten belooft.

• Stilstandhistorie per machine: hoe vaak er stilstand is en hoe lang elke stilstand duurt, afkomstig uit het onderhouds- of stilstandlogboek.
• Werkkalenders en vaardigheden: wie welk station kan bedienen, en wat er gebeurt bij een korte ploeg.
• Omsteltijden en wisseltijden tussen varianten, niet alleen de looptijden.
• Order- en leverdatagegevens, zodat je ziet welke orders vertraging oplopen en niet alleen dát er iets vertraagt.
• De regels die de lijn vandaag echt volgt: volgordeaspecten, limieten voor overwerk, wanneer een job naar een andere machine gaat.

Als een rij ontbreekt, zeg dat dan in de scenariobeschrijving. Een resultaat dat gebaseerd is op een geschatte stilstandduur is een gok met een mooie grafiek eromheen. Laat het lijnteam de cijfers controleren. Die vertellen je vaak binnen twee minuten welk getal fout is.

Hoe voer je een verstoringsstudie uit?

De stappen zijn dezelfde als bij elk simulatieproject, met een paar punten die voor verstoringen zwaarder wegen.

1. Schrijf de vraag op. Bijvoorbeeld: "Als de molen een volledige shift stilligt, welke orders halen dan hun datum niet, en wat is de goedkoopste reactie?"
2. Valideer de uitgangssituatie. Vergelijk de modeluitkomst met een eerdere periode. Is het verschil groot, dan corrigeer je eerst de data voordat je ook maar één verstoring toevoegt.
3. Definieer een kleine set scenario's. Drie tot vijf is ruim voldoende. Geef elk scenario een naam en leg vast wat er verandert en hoe lang.
4. Draai elk scenario meerdere keren. Storingen zijn willekeurig, dus één run kan beter of slechter uitvallen dan normaal. Vergelijk de spreiding van de resultaten, niet één getal.
5. Test de reacties. Overwerk, werk verschuiven naar een andere machine, de volgorde aanpassen, voorraad inzetten. Een verstoringsstudie zonder reactieopties vertelt je alleen dat er dingen misgaan.
6. Spreek de beslisregel af. Bepaal vóór de run welk resultaat je tot actie zou aanzetten. Anders wordt er alleen over de cijfers gediscussieerd.

Houd de scenario's in een korte lijst die je opnieuw kunt draaien wanneer het proces verandert. Een scenariobibliotheek is waardevoller dan elke afzonderlijke studie.

Waar passen Microsoft-tools?

Je ERP-systeem is meestal de plek waar routings, stuklijsten en werkagenda's staan. Dat maakt het de natuurlijke bron voor de basisdata van het model. Het model zelf is meestal aparte software.

Om resultaten te tonen werkt Power BI goed om scenario's naast elkaar te vergelijken. Microsoft Learn documenteert daarnaast what-if-parameters: een instelbare variabele die rapportlezers met een slicer wijzigen, waarna het rapport opnieuw berekent. Dat is handig voor eenvoudige rekenvoorbeelden zoals het voorbeeld hierboven, bijvoorbeeld het aanpassen van het mixaandeel en zien hoe een capaciteitscijfer meebeweegt. Microsoft stelt dat deze parameters bedoeld zijn voor measures in visuals. Ze simuleren geen wachtrijen, dus haal een what-if-schuifregelaar niet door elkaar met een simulatie.

Veelgemaakte fouten

• Alles willen simuleren. Te veel scenario's maken het model traag en de resultaten lastig uit te leggen.
• Alleen gemiddelde reparatietijden gebruiken. De lange stilstanden veroorzaken de meeste schade.
• Alleen de eindsituatie van een mixwijziging testen. De bottleneck verschuift onderweg vaak.
• De controle van de uitgangssituatie overslaan. Als het model vorige maand niet kan reproduceren, zijn de resultaten van de verstoringen giswerk.
• Vertrouwen op één run. Bij willekeurige gebeurtenissen kan één run je misleiden.
• De mensen vergeten. Afwezigheid, vaardigheden en overwerklimieten horen in het model wanneer de verstoring met personeelsbezetting te maken heeft.
• Een eenmalig model bouwen. Een model dat niemand bijwerkt na de volgende procesverandering, is binnen een paar maanden verouderd.

Waar Polaris past

Als je vragen gaan over capaciteit, personeelsbezetting, buffers of productmix, is iFAKT Polaris een optie om te bekijken. iFAKT beschrijft Polaris als AI plus een digitale tweeling voor productie, die ERP-data combineert met een digitale tweeling van de productie. De module Polaris Simulator test het productiesysteem virtueel, inclusief scenario's voor capaciteit, personeelsbezetting en buffers en dynamische productmixen op gedeelde resources. De module Polaris Optimizer signaleert bottlenecks en analyseert bij verstoringen de impact en optimaliseert het plan opnieuw. Of het past, hangt af van je data en je vraag, dus probeer het eerst op één smal geval.

Verwante onderwerpen om te verkennen

• Het model voeden met live data. Een digitale tweeling houdt het model verbonden met de fabriek. Bepaal eerst of je beslissing een live feed nodig heeft of alleen een goed model.
• De menselijke reactie modelleren. Vertraagde reacties en shiftwisselingen veranderen hoe lang een verstoring duurt, dus voeg ze toe wanneer personeelsbezetting onderdeel van de vraag is.
• Herstel en herstart. Nadat de verstoring voorbij is, komt de achterstand op de lijn terecht. Simuleer de herstart, inclusief de overwerklimieten.
• De lus sluiten met planning. Zodra een verstoring werkelijkheid is, moet de planning veranderen. Denk na over hoe het resultaat van een simulatie in de herplanning terechtkomt.

Volgende stap

Productieverstoringen simuleren is het makkelijkst als je vertrekt van je eigen stilstandregistratie. Kies de verstoring die vorig jaar de meeste kosten heeft veroorzaakt, beschrijf die in één zin met duur en getroffen resource, en test die in een model, ook al is het een ruw model, vóór de volgende planningsvergadering.