Vijf veelgemaakte fouten in simulatieprojecten en hoe je ze voorkomt

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-11

Fouten in simulatieprojecten kosten tijd en vertrouwen. Leer vijf veelvoorkomende fouten kennen, van vage vragen tot overgeslagen validatie, met een uitgewerkt voorbeeld en een checklist.

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

Fouten in simulatieprojecten zijn grotendeels te voorkomen, en de meeste worden gemaakt voordat het eerste model is gebouwd. Deze gids is bedoeld voor fabrieksmanagers die een simulatieproject in de productie sponsoren, en voor de engineers die het model bouwen, wanneer zij willen dat het werk uitmondt in een besluit. Je leert vijf veelgemaakte fouten, ontleend aan twee artikelen van simulatie-expert Averill Law en aan de praktijk, een uitgewerkt voorbeeld met cijfers dat laat zien waarom één run niet genoeg is, en een checklist voor je volgende project met factory simulation.

Belangrijkste punten

• Vijf fouten komen steeds terug in simulatieprojecten: geen duidelijke vraag, het verkeerde detailniveau, zwakke data, geen validatie en vertrouwen op één enkele run.
• Een model zonder duidelijke vraag en zonder regelmatig contact met de besluitnemer lost het verkeerde probleem op, hoe goed het ook is.
• Begin eenvoudig en voeg alleen detail toe wanneer de vraag dat nodig heeft; onnodig detail kost tijd en verbergt de factoren die ertoe doen.
• Valideer het model tegen het bestaande systeem voordat je het voor prognoses gebruikt, en bewaar de geschreven aannames voor beoordeling.
• Willekeurige gebeurtenissen vragen om veel replicaties: één run kan twee opties in de verkeerde volgorde zetten.

Fouten in simulatieprojecten: waar ze vandaan komen

Een simulatieproject is geen programmeeroefening. Averill Law beschrijft in zijn artikel over hoe je een succesvolle simulatiestudie uitvoert op de Winter Simulation Conference van 2003 zeventien valkuilen in vier groepen: modellering en validatie, software, willekeur en het ontwerp van experimenten. In 2024 breidde hij de lijst uit tot 23 valkuilen in een artikel voor dezelfde conferentie. Hij merkt op dat programmeren in een degelijke studie slechts 25 tot 50 procent van het werk is.

Law werkt bij zijn eigen adviesbureau voor simulatie, Averill M. Law & Associates, dus zijn lijsten weerspiegelen één expertmening. Ze komen overeen met een praktisch artikel van J. Michael Knoll en Joseph Heim van Genie Industries over de invoering van discrete-event-simulatie in een productieomgeving. Dat artikel is gebaseerd op één middelgrote producent en rapporteert geen becijferde besparingen.

Op basis van deze bronnen en de dagelijkse praktijk kiezen we vijf fouten die voor een fabriek het zwaarst wegen. Deze selectie is van ons, geen rangschikking uit de artikelen.

Fout 1: geen duidelijke vraag en geen contact met de besluitnemer

De eerste fout is beginnen met de tool in plaats van met de vraag. Law noemt onduidelijke doelstellingen en weinig regelmatig contact met de besluitnemer als valkuilen. Hij haalt een waarschuwing aan dat het beste model voor het verkeerde probleem de besluitnemer nauwelijks iets oplevert. In een van zijn voorbeelden werkte een analist maandenlang zonder de opdrachtgevende generaal te raadplegen. Die verliet de eindbespreking na vijf minuten met de opmerking dat dit niet het probleem was waarin hij geïnteresseerd was.

Knoll en Heim geven een praktische vuistregel: een model waarvan de output niet gebruikt wordt, moet je niet bouwen.

Hoe je het voorkomt. Formuleer de vraag als een beslissing. "Welke van twee indelingen levert 3.000 eenheden per dienst op?" is een vraag. "Laten we de fabriek simuleren" is dat niet. Organiseer een kick-offvergadering met iedereen die erbij betrokken is, leg vast wie beslist en wanneer, en spreek regelmatige evaluatievergaderingen af tijdens het project.

Fout 2: Het verkeerde detailniveau

De tweede fout is te veel of te weinig modelleren. Law noemt een onjuist detailniveau een van de meest voorkomende fouten, vooral bij nieuwe analisten. Zijn advies is om alleen zoveel detail op te nemen als nodig is om de relevante vragen te beantwoorden, en klein te beginnen en pas detail toe te voegen wanneer dat nodig is. Knoll en Heim zijn het daarmee eens: houd de scope strak en breid een model niet uit alleen omdat het kan.

Te veel detail vertraagt het project en verbergt de factoren die ertoe doen tussen een grote hoeveelheid parameters. Te weinig detail laat een effect weg dat je wilde testen, zoals een omstelling of een buffer.

Hoe je het voorkomt. Vraag bij elk element en elke invoerparameter van het model of het het antwoord op de vraag verandert. Zo niet, laat het dan weg of gebruik een eenvoudige regel. Leg de aannames vast in een kort conceptueel model, wat Law een absoluut kritieke activiteit noemt die vaak wordt overgeslagen, en loop het door met de mensen die de lijn kennen.

Fout 3: Zwakke verzameling van simulatiedata

De derde fout betreft data. Law noemt slechte verzameling van systeemdata als een valkuil, en hij waarschuwt ook voor twee typische fouten bij het modelleren van invoer. De eerste is een willekeurige invoer vervangen door het gemiddelde. In zijn wachtrijvoorbeeld verwijdert het gebruik van constante tijden gelijk aan de gemiddelden de wachtrij volledig, waardoor het model geen wachttijd toont waar het echte systeem die wel heeft. De tweede is uit gewoonte een verdeling kiezen, zoals de normaalverdeling. In een van zijn voorbeelden leverde een normaalverdeling voor doorlooptijden een uitvoerfout van 39 procent op in vergelijking met een beter passende verdeling.

De fabrieksdata zelf vraagt om zorg. Komt de stopreden in het manufacturing execution system overeen met het onderhoudsrecord? Als er een digital twin beschikbaar is, een onderhouden digitale representatie van een fysieke resource die op basis van observaties actueel wordt gehouden, kan die actuele data leveren. Zo niet, plan dan tijd in voor meting.

Hoe je het voorkomt. Maak een lijst van de data die de vraag nodig heeft, zoek de bron en de eigenaar van elk onderdeel, en verzamel de variatie, niet alleen het gemiddelde. Raadpleeg minstens twee experts voor belangrijke onderdelen van het proces, want een deel van wat mensen zeggen klopt niet.

Fout 4: Modelvalidatie overslaan

De vierde fout is een model vertrouwen dat nooit is vergeleken met de werkelijkheid. Law noemt het vergelijken van modeluitvoer met het bestaande systeem de belangrijkste validatietechniek, en hij zegt dat het ook de geloofwaardigheid ondersteunt. In zijn paper uit 2024 geeft hij een voorbeeld uit de papierpulpindustrie, waarin de doorvoer van model en systeem slechts 0,4 en 1,1 procent verschilden. Hij raadt ook een gestructureerde doorloop van de aannames met alle belanghebbenden aan, omdat modelfouten en weglatingen dan worden gevonden.

Hoe je het voorkomt. Bouw eerst de referentiesituatie en controleer die tegen de uitvoer, stops en doorlooptijd van de echte lijn. Laat experts de simulatieresultaten op redelijkheid beoordelen en test welke invoerparameter de resultaten het meest verschuift. Gebruik het model pas daarna voor opties. Als de lijn nog niet bestaat, vergelijk het model dan met een vergelijkbare lijn of met berekeningen, en benoem dat open.

Fout 5: Eén run zien als de waarheid

De vijfde fout is statistisch. Een simulatie met willekeurige gebeurtenissen geeft bij elke run een ander resultaat. Law waarschuwt ertegen de uitkomst van één run te behandelen als de werkelijke prestatie van het model. In zijn voorbeeld van een kantoor van de wegenverkeersdienst varieerde de gemiddelde vertraging tussen replicaties van 1,83 tot 10,37 minuten. Hij noemt ook het weglaten van een opwarmperiode, wanneer de startsituatie leeg en niet representatief is, en het vergelijken van opties zonder betrouwbaarheidsintervallen.

Hoe je het voorkomt. Voer veel onafhankelijke replicaties uit, negeer de opwarmperiode, plan de analyses vóór de runs, en vergelijk opties met bandbreedtes of betrouwbaarheidsintervallen, niet met losse getallen.

Voorbeeld: één run tegenover vijf replicaties

Dit is een illustratief voorbeeld met aangenomen getallen, geen gemeten casus. Een productiebedrijf vergelijkt twee bufferontwerpen, A en B, in een model van een verpakkingslijn. De output per shift van elk ontwerp in het model is:

• Ontwerp A, vijf replicaties: 412, 389, 401, 395 en 393 eenheden. Het gemiddelde is 1.990 ÷ 5 = 398 eenheden.
• Ontwerp B, vijf replicaties: 405, 399, 408, 402 en 406 eenheden. Het gemiddelde is 2.020 ÷ 5 = 404 eenheden.

Als het team alleen de eerste replicatie van elk had gedraaid, had A 412 gescoord en B 405, en zou A er 7 eenheden beter uitzien. Met vijf replicaties is B gemiddeld 6 eenheden beter, en zijn bereik van 399 tot 408 is smaller dan dat van A, dat loopt van 389 tot 412. De eerste run rangschikte de ontwerpen dus precies andersom.

Vijf replicaties is voor een illustratie het minimum. Een echt project draait er meer en berekent betrouwbaarheidsintervallen. De validatiestap werkt met hetzelfde idee: als het basismodel een gemiddelde van 391 eenheden geeft en de echte lijn over 20 shifts gemiddeld 380 eenheden per shift haalde, dan ligt het model 11 eenheden, of ongeveer 3 procent, hoger. Het team beslist of dat dicht genoeg bij de vraag ligt, en legt die beslissing vast.

Hoe vermijd je de vijf fouten: een checklist

1. Formuleer de vraag als een beslissing, met de beslisser en de datum.
2. Start met een kick-off met alle belanghebbenden en spreek vergaderingen voor evaluatiemomenten af. Behandel het werk als een iteratie met toetsmomenten, niet als een eenrichtingsproces.
3. Begin eenvoudig. Schrijf een kort conceptueel model met de aannames op en loop het door met experts voordat je gaat programmeren.
4. Plan de data. Benoem de bron en eigenaar van elk datapunt en verzamel de variatie.
5. Valideer het basismodel tegen de echte lijn voordat je opties test.
6. Repliceer. Draai voldoende replicaties, laat de opwarmperiode weg en rapporteer bereiken.

Veelgemaakte fouten

• Het project behandelen als programmeerwerk. Volgens Law is programmeren maar een deel van het werk.
• De animatie laten beslissen. Een korte blik op de animatie is geen experiment.
• Simulatietools alleen op prijs kiezen. Kies de tool die past bij het probleem en bij de vaardigheden van je team, en gebruik simulatiesoftware niet als black box.
• Geen documentatie. Een model zonder schriftelijke aannames kan niet worden beoordeeld of hergebruikt.
• Geen eigenaar na afloop van het project. Een model dat niemand bijwerkt, is na de eerste wijziging verouderd.

Hoe software kan helpen

iFAKT's Polaris Simulator is een module van iFAKT Polaris die het productiesysteem virtueel test, bijvoorbeeld voor capaciteits-, personeels- en bufferscenario's, en knelpunten zichtbaar maakt voordat er wijzigingen worden doorgevoerd. Welke tool je ook kiest, en voordat je simulatie voor een beslissing gebruikt, controleer hoe die omgaat met replicaties en opwarmperiode, hoe je echte data importeert, en hoe je aannames kunt documenteren en laten beoordelen. Software kan de vraag of de validatie niet vervangen.

Volgende stap

Neem je volgende simulatieproject voor productie, of een project dat nu loopt, en toets het aan de checklist hierboven. Waar een antwoord ontbreekt, heb je een waarschijnlijke oorzaak van fouten in simulatieprojecten gevonden, en kun je die oplossen voordat het model wordt gebouwd.