Simulatiemodel-data: waar het vandaan komt en hoe goed het moet zijn

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

Data voor een simulatiemodel komt uit systemen, metingen en experts. Bekijk de bronnen, de gebruikelijke kwaliteitsgaten en hoe goed de invoerdata van een simulatie moet zijn.

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

De data voor het bouwen van een simulatiemodel komt uit drie plekken: bedrijfs- en werkvloersystemen, directe meting en de mensen die de lijn kennen. Hoe goed die data moet zijn, hangt af van de vraag, niet van een algemene norm. Deze gids is bedoeld voor continuous improvement managers die gevraagd worden de data aan te leveren voor een fabrieckssimulatie. Je leert wat het model nodig heeft, waar elk onderdeel vandaan komt, wat meestal misgaat, een uitgewerkt voorbeeld met cijfers en een plan in zes stappen om data te krijgen die goed genoeg is.

Belangrijkste punten

• Een simulatiemodel heeft producten en routings, procestijden, middelen, stilstanden, orders en bezettingsregels nodig; elk onderdeel komt uit een systeem, een meting of een expert.
• Data komt uit primaire bronnen, zoals tijdstudies met een stopwatch en observatie, en uit secundaire bronnen, zoals ERP-, MES- en CAD-systemen en prognoses.
• Typische gaten zijn vooraf ingestelde ERP-tijden die afwijken van de werkelijke tijden, dubbele records, data die achterloopt op de werkelijkheid en ontbrekende variatie.
• Invoer moet goed genoeg zijn voor de vraag: controleer welke invoer het resultaat het meest verandert en steek je inspanning daar in.
• Gebruik verdelingen en werkelijke registraties, niet alleen gemiddelden, want variatie zorgt voor de wachttijd die je wilt testen.

Data voor het bouwen van een simulatiemodel: wat het model nodig heeft

Een stroommodel van een lijn heeft zes soorten invoer nodig. Deze lijst is onze eigen samenvatting van gangbare praktijk, geen norm.

• Producten en routings. Welk product welk station bezoekt, en in welke volgorde.
• Tijden. Procestijd per product en station, omsteltijden, en de variatie in beide.
• Middelen. Machines, gereedschap en mensen, hun capaciteit en hun beschikbaarheid, inclusief storingen en geplande stilstanden.
• Orders en vraag. Ordergroottes, productmix en aankomstpatroon, uit het orderboek of uit een prognose.
• Regels. Shiftmodel, pauzetijden, volgordebepaling en batchregels, en hoe operators zich tussen stations verplaatsen.
• Kwaliteit. Percentages afkeur en herwerk, en waar defecten worden ontdekt.

Het model heeft niet elk getal uit de fabriek nodig. Het heeft de getallen nodig waar de vraag van afhangt, en het heeft de variatie nodig, want variatie zorgt voor de wachttijd die je wilt simuleren en testen. Een model kan alleen voorspellen wat zijn data toelaat.

Waar invoerdata voor een simulatie vandaan komt: dataverzameling in de praktijk

Een artikel van Maja Bärring en collega's op de Winter Simulation Conference 2018 beschrijft de bronnen in twee groepen, voortbouwend op eerder werk van Anders Skoogh en collega's.

• Primaire data wordt verzameld voor de studie: metingen, tijdstudies met een stopwatch en observatie op de lijn.
• Secundaire data bestaat al. Dit omvat externe referenties zoals industriële normen en domeinexperts, bedrijfssystemen zoals ERP, MES, PDM en CAD, en projectspecifieke data zoals prognoses van productievolumes.

Voor een continuous improvement-manager ziet het verzamelen van data er in de praktijk zo uit. Het manufacturing execution system bevat de werkelijke cyclustijden, stilstanden en aantallen per station. Het ERP-systeem bevat orders, routings en geplande tijden. Het CAD- of PDM-systeem bevat de productstructuur. Shiftplannen liggen bij planning of HR. Omsteltijden en de manier waarop operators echt werken, vind je vaak alleen door te observeren en de shiftleiders te vragen.

Waarom de data vaak niet goed genoeg is

Bärring en collega’s onderzochten twee casusbedrijven met vijf geïnterviewden, dus de bevindingen zijn indicatief en niet algemeen geldig. In de casus waarin data handmatig uit het ERP-systeem en uit spreadsheets werd verzameld, beschrijven ze problemen die veel fabrieken herkennen:

• Vooraf ingestelde ERP-waarden werden gebruikt in plaats van werkelijke tijden, waardoor onduidelijk was welke tijden je moest gebruiken.
• Hetzelfde item stond zowel in het ERP-systeem als in spreadsheets.
• Labels waren niet consistent en afdelingen hanteerden verschillende labels.
• De werkelijkheid veranderde, maar het systeem niet.

De auteurs wijzen er ook op dat ERP-systemen deterministische waarden benadrukken boven stochastische, waardoor de variatie die een simulatie nodig heeft vaak ontbreekt. In de tweede casus voorkwam automatische dataverzameling vijf van de acht uitdagingen die ze noemen. Het artikel adviseert onder meer om de eigenaarschap van de data toe te wijzen aan functies binnen het bedrijf. Een enquête van Skoogh, Perera en Johansson in Simulation Modelling Practice and Theory wees uit dat ongeveer 80 procent van de gebruikers van simulatie nog steeds sterk handmatige werkwijzen gebruikt voor invoerdata.

Routing en stuklijst in een simulatie

Twee soorten stamdata veroorzaken vaak problemen. De routing geeft aan welke bewerkingen een product nodig heeft, in welke volgorde, op welke resource en met welke tijd. De stuklijst geeft aan welke onderdelen in het product gaan. Voor een stroommodel is de routing meestal de ruggengraat, en de stuklijst is belangrijk wanneer onderdelen kunnen ontbreken of wanneer een station wacht op een subassemblage.

Routings in het ERP-systeem zijn vaak planningswaarden die één keer zijn ingesteld en zelden worden bijgewerkt. Dat is het probleem dat Bärring en collega’s beschrijven. Voordat je een routing in een model laadt, vergelijk je de tijden met de werkelijke tijden uit het MES voor hetzelfde product en station. Controleer ook of de volgorde van de bewerkingen nog overeenkomt met de werkvloer, en of de stuklijst de varianten laat zien die je daadwerkelijk bouwt. Vul een gat niet op met gesimuleerde data, ook wel synthetische data genoemd, en vergeet niet om dat te labelen.

Hoe goed moet de datakwaliteit van een simulatie zijn?

Het antwoord is: goed genoeg voor de beslissing. Averill Law vraagt in zijn artikel over valkuilen bij simulatiemodellering om registratie van de invoerverdelingen en om validatie. Hij raadt aan om waar mogelijk data te verzamelen over alle mogelijke bronnen van willekeurigheid in het systeem. Hij waarschuwt voor twee fouten: een willekeurige invoer vervangen door het gemiddelde, wat in zijn voorbeeld de wachtrij volledig wegneemt, en uit gewoonte een normale verdeling kiezen, wat in een van zijn voorbeelden leidde tot een uitvoerfout van 39 procent.

Een praktische manier om te bepalen hoeveel moeite je erin steekt, is de invoer te rangschikken op basis van het effect en de onzekerheid van elke parameter. Law adviseert ook een gevoeligheidsanalyse om te zien welke factoren de prestatie-indicatoren het sterkst beïnvloeden. Deze indeling is onze eigen planningshulp, geen standaard:

1. Klasse A: gemeten en gecontroleerd. Gebruik deze klasse voor invoer die het resultaat het sterkst beïnvloedt, zoals de cyclustijd van de bottleneck en het stilstandpatroon ervoor.
2. Klasse B: afkomstig uit een systeem en gecontroleerd op een steekproef. Gebruik deze klasse voor invoer met een gemiddeld effect.
3. Klasse C: deskundigenoordeel. Gebruik deze klasse voor invoer met weinig effect, en leg de aanname vast.

Controleer ten slotte de hele set via validatie: reproduceert het model de output van de echte lijn? Zo niet, kijk dan eerst naar de invoer van klasse A.

Voorbeeld: routingtijd tegenover werkelijke tijd

Dit is een illustratief voorbeeld met aangenomen getallen, geen gemeten case. Een lijn maakt één product. De routingtijd in het ERP-systeem is 42 seconden per onderdeel op het bottleneckstation. Het MES laat over vier weken een mediane werkelijke cyclustijd van 47 seconden zien.

• Output per uur met de routingtijd: 3.600 ÷ 42 = 85,7 onderdelen.
• Output per uur met de werkelijke tijd: 3.600 ÷ 47 = 76,6 onderdelen.
• De routing overschat de snelheid met 85,7 ÷ 76,6 = ongeveer 12 procent. Over een shift van 8 uur is dat ongeveer 686 tegen 613 onderdelen, een verschil van 73 onderdelen.

Een model dat met de routing wordt gevoed, maakt een voorspelling die de lijn nooit heeft gehaald. Elke verbetering die je daarmee meet, lijkt slechter dan ze in werkelijkheid is.

Dezelfde logica geldt voor stops. Stel dat het MES zeven stops registreert met duren van 2, 3, 3, 4, 5, 6 en 40 minuten. De som is 63 minuten, dus het gemiddelde is 9 minuten, terwijl de mediaan 4 minuten is. Een model met een constante stop van 9 minuten laat de stop van 40 minuten die de buffer leegloopt nooit zien, en het toont meer middellange stops dan de lijn werkelijk heeft. Breng de geregistreerde duren in een grafiek, bereken de spreiding en gebruik ze direct, of gebruik een statistische verdeling die je erop hebt gefit. Schat de parameters ervan op basis van de registraties.

Data goed gebruiken: een plan in zes stappen

1. Stel de vragen op een rij. De vraag bepaalt welke invoer je nodig hebt.
2. Zet de items op een rij in de zes groepen hierboven, en markeer welke het sterkst van de vraag afhangen.
3. Benoem bron en eigenaar per item, bijvoorbeeld het MES voor stops, het ERP voor orders, en een observator voor omsteltijden.
4. Vergelijk de bronnen. Controleer de routingtijden tegen het MES, en controleer of identificaties en eenheden tussen systemen overeenkomen.
5. Meet de hiaten met de methode van kwaliteitsniveau A voor de invoer die ertoe doet, en leg de aannames voor de rest vast.
6. Valideer en onderhoud de data. Vergelijk het model met de echte lijn, sla de dataset op met een datum, en wijs een eigenaar aan die hem bijwerkt.

Veelgemaakte fouten

• De ERP-routing laden zonder controle. Geplande waarden zijn geen werkelijke waarden.
• Alleen met gemiddelden werken. Elke invoer is een variabele met een spreiding, geen enkel getal. Variatie veroorzaakt de wachttijd, en het gemiddelde haalt die weg.
• Alles verzamelen. Inspanning zonder vraag verspilt tijd die het project niet heeft, en de enorme hoeveelheid verbergt wat er echt toe doet.
• Definities door elkaar halen. Een stop, een omsteltijd of een cyclus kan in verschillende systemen iets anders betekenen.
• Geen eigenaar. Cijfers die niemand bijhoudt, zijn verouderd bij de volgende wijziging.
• Validatie overslaan. Zonder vergelijking met de echte lijn weet je niet of de invoer goed genoeg is.

Hoe software kan helpen

Een kennisgraaf die producten, processtappen en resources met elkaar verbindt, kan dubbele en tegenstrijdige data verminderen, omdat elk feit maar één keer wordt opgeslagen. iFAKT's Polaris Designer is een module van iFAKT Polaris die een product-proces-resource (PPR)-kennisgraaf bouwt als enige bron van waarheid voor producten, processtappen en resources. Het vervangt de controle op werkelijke tijden, de eigenaren of de validatie van het model niet. Vraag bij elk hulpmiddel hoe het gegevens uit je ERP en MES importeert, en hoe wijzigingen worden bijgehouden.

Volgende stap

Neem het knelpuntstation van één lijn en vergelijk de routingtijd in het ERP met de werkelijke cyclustijd in het MES over de afgelopen vier weken. Als die verschillen, heb je de eerste hiaat in de data voor het bouwen van het simulatiemodel gevonden, en weet je waar je moet beginnen.