Het bijhouden van KPI's voor productiesimulatie: scenario's eerlijk vergelijken

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

Het bijhouden van KPI's voor productiesimulatie begint met een paar KPI's die gedefinieerd zijn zoals jouw fabriek ze definieert. Lees hoe je scenario's uitvoert, resultaten interpreteert en ze rapporteert.

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

Het bijhouden van KPI's voor productiesimulatie betekent dat je vóór het bouwen van het model een kleine set prestatie-indicatoren kiest, ze in het model berekent precies zoals jouw fabriek dat doet, en scenario's vergelijkt op basis van die cijfers. Als de definities in model en fabriek verschillen, zijn de resultaten niet betrouwbaar, hoe goed het dashboard er ook uitziet. Dit artikel is bedoeld voor productiemanagers en procesingenieurs die simulatiestudies uitvoeren, of die de resultaten moeten lezen en er een beslissing op moeten baseren.

Belangrijkste punten

• Het bijhouden van simulatie-KPI's betekent dat je vóór het bouwen van het model een paar KPI's kiest en ze precies berekent zoals de fabriek dat doet.
• ISO 22400-2 laat de werkwijze zien: elke KPI wordt beschreven met zijn formule, zijn elementen, zijn tijdsgedrag en zijn eenheid.
• Eén simulatierun is één steekproef, dus gebruik meerdere replicaties en rapporteer een gemiddelde met een betrouwbaarheidsinterval.
• Verander per scenario maar één ding, vergelijk scenario's op basis van dezelfde KPI-definities en controleer eerst de nulmeting tegen een echte, eerdere periode.
• Simulatieresultaten zijn niet live, dus een dashboard dat erop gebaseerd is, moet na elke reeks runs worden vernieuwd en per scenario worden gelabeld.

Wat is het bijhouden van KPI's voor productiesimulatie?

Een simulatiemodel levert veel ruwe output op: elk onderdeel, elke wachttijd, elke machinestatus gedurende de gesimuleerde tijd. KPI-tracking zet die output om in een handvol getallen die mensen kunnen vergelijken. Waar fabriekssimulatie antwoord geeft op de vraag "wat gebeurt er als we dit veranderen?", vertellen de KPI's hoeveel, in termen die de fabriek al gebruikt.

Er zijn twee manieren waarop dit misgaat. Bij de eerste meet het team wat makkelijk uit de modelsoftware te halen is, en eindigt het met cijfers die niemand in de fabriek herkent. Bij de tweede kopieert het team een lange KPI-lijst uit een dashboardsjabloon, en verdrinkt de studie in getallen die niets met de beslissing te maken hebben.

De oplossing is in beide gevallen dezelfde. Begin bij de beslissing, bijvoorbeeld "voegen we een tweede ploeg toe aan de assemblagelijn of kopen we een tweede machine?", en vraag welke getallen je doen kiezen voor de ene optie boven de andere. Dat zijn je KPI's.

Welke KPI's horen bij een simulatiestudie?

Houd de lijst kort. Vijf tot zeven is ruim voldoende. Dit zijn gangbare keuzes, en welke ertoe doen hangt af van je vraag:

1. Doorvoer. Goede eenheden per uur, ploeg of week.
2. Doorlooptijd. Hoe lang een order of onderdeel nodig heeft van vrijgave tot afronding.
3. Werk in proces (WIP). Hoeveel er op een bepaald moment in het systeem zit. Dit beweegt vaak mee met de doorlooptijd.
4. Bezettingsgraad van resources. Hoeveel van de beschikbare tijd machines en mensen bezet zijn. Kijk naar het knelpunt en naar de resource ernaast.
5. Wachttijd en wachtrijlengte vóór het knelpunt.
6. Levering op tijd, als het model leverdatums bevat.
7. OEE, als verliezen van apparatuur de beperkende factor zijn.

Wees specifiek over OEE. Het Lean Enterprise Institute beschrijft overall equipment effectiveness als een metriek uit total productive maintenance die beschikbaarheid, prestatie en kwaliteit met elkaar vermenigvuldigt. Volgens het instituut richt de metriek zich meestal op de zes grote verliezen: storingen, afstellingen, korte stilstanden, verlaagde snelheden, afval en herbewerking. OEE heeft alleen zin in een simulatie als het model die verliezen bevat, zoals storingsgedrag, omstelling en afvalpercentages. Als dat niet zo is, is een OEE-cijfer uit het model een gok met een decimaal erachter. Op een productielijn met meerdere producten en een lange omstelling kan OEE bovendien verbergen wat kosten en levertijd echt bepaalt. Combineer het daarom met doorlooptijd of levering op tijd.

Verzet je tegen KPI's die het model niet kan beïnvloeden. Als je scenario's de shiftplanning veranderen, hoort een klanttevredenheidsscore niet in het onderzoek thuis.

Hoe definieer je KPI's zodat het model en de fabriek hetzelfde bedoelen?

Schrijf vóór de eerste run een KPI-blad van één pagina. Beschrijf per KPI:

• de naam en de vraag die de KPI beantwoordt,
• de formule en de onderdelen ervan,
• de tijdsbasis, bijvoorbeeld per shift, per kalenderweek of per geplande productie-uur,
• de eenheid,
• waar de werkelijke waarde in de fabriek vandaan komt,
• wie eigenaar is van de definitie.

Dit is de discipline die normen op dit gebied volgen. De ISO-pagina voor ISO 22400-2, die kerngetallen voor de aansturing van productieprocessen definieert, stelt dat elke KPI wordt beschreven met zijn formule en onderdelen, zijn tijdsgedrag, zijn eenheid of dimensie, zijn gebruikersgroep en de productiemethodiek waartoe hij behoort. De pagina die ik las beschrijft het concept van de tweede editie, die de versie uit 2014 gaat vervangen. Controleer dus de huidige editie als je de norm wilt citeren. Je hoeft de norm niet volledig over te nemen om er voordeel uit te halen: één precieze definitie per KPI.

De meeste discussies gaan over tijd. "Beschikbaarheid" verandert met het antwoord op de vraag "beschikbaar van hoeveel?". De beschrijving van OEE door het LEI meet stilstand door storingen en omstelling ten opzichte van de geplande tijd. Die geplande tijd moet dus duidelijk in je blad staan. Telt gepland onderhoud mee? Pauzes? Een shift die in de agenda als vrije dag staat? Leg dit vast voordat het model wordt gebouwd, want het beïnvloedt elk resultaat.

Doe daarna de controle die het blad waardevol maakt: bereken dezelfde KPI's over een echte periode in het verleden met fabrieksdata, en vergelijk ze met wat het model oplevert wanneer je die periode erin stopt.

Hoe draai je scenario's en lees je de resultaten?

Een simulatierun is een willekeurige steekproef. Storingen, aankomsttijden en verwerkingstijden variëren, dus twee runs van hetzelfde scenario geven twee verschillende antwoorden. Behandel één run als een anekdote.

1. Valideer de baseline. Draai het model voor een periode die je kent en vergelijk de KPI's met de werkelijkheid. Als het model het verleden niet binnen een bandbreedte kan reproduceren die je accepteert, verbeter dan eerst het model voordat je een wijziging test.
2. Gebruik replicaties. Draai elk scenario meerdere keren met onafhankelijke random streams. Een MIT-college over proefopzet voor simulaties beschrijft het bepalen van het aantal replicaties aan de hand van een precisiedoel: je gaat door totdat het betrouwbaarheidsinterval smal genoeg is ten opzichte van de schatting. Het college vermeldt ook dat je bij minder dan 30 replicaties de Student-t-verdeling gebruikt voor het interval.
3. Behandel de opwarmfase. Voor een fabriek die continu draait, start het model leeg en heeft het tijd nodig om een normale werking te bereiken. Hetzelfde college beschrijft het weggooien van het begin van elke replicatie en noemt de methode van Welch om te bepalen hoeveel je weggooit. Als je vraag gaat over een afgebakende periode, zoals één orderbatch, start het model dan in de toestand waarin de fabriek op dat moment verkeert.
4. Wijzig één ding per scenario. Als scenario B een machine toevoegt en tegelijk de shiftplanning en de batchgrootte wijzigt, weet je niet welke wijziging wat heeft veroorzaakt.
5. Rapporteer bandbreedtes. "De doorvoer stijgt met 4% tot 9%" is eerlijker dan "stijgt met 6,5%". Als de intervallen van twee scenario's sterk overlappen, zeg dan dat de data ze niet van elkaar kan onderscheiden.
6. Kijk naar de hele stroom. Een winst op één machine kan het knelpunt ergens anders naartoe verplaatsen. Controleer de bezetting en de wachtrijen langs de hele stroom, niet alleen op het station dat je hebt aangepast.

Houd een scenarioregister bij: een lijst met de scenarionaam, wat er is veranderd, de aannames, het aantal replicaties en de datum. Zonder die lijst weet over zes maanden niemand meer waarom scenario 7 is gekozen.

Hoe toon je simulatie-KPI's aan managers?

Managers hebben behoefte aan de vergelijking, niet aan de ruwe output. Een eenvoudige pagina werkt goed: de uitgangssituatie en elk scenario naast elkaar, voor dezelfde paar KPI's, met de bandbreedte en een toelichting op wat elk scenario verandert.

In een Microsoft-omgeving is een veelgebruikte route een resultatentabel die je laadt in Power BI. Elke rij bevat het scenario, de replicatie, de KPI-naam en de waarde. Zo kun je de vergelijking bouwen en filteren op scenario. In de documentatie van Microsoft over gegevensvernieuwing staat dat geïmporteerde gegevens in een semantisch model een momentopname zijn, dus je moet ze vernieuwen om nieuwe gegevens te zien. Voor simulatieresultaten past dat goed: je vernieuwt na een reeks runs, en niet ervoor.

Daaruit volgen twee praktische punten:

• Markeer elke visual als scenarioresultaat, met de datum van de laatste run. Prognosecijfers naast live productiecijfers nodigen uit tot verkeerde interpretatie.
• Vergelijk later de geplande en de werkelijke situatie, wanneer de wijziging is doorgevoerd, met dezelfde KPI-definities. Daar betaalt het KPI-overzicht zich terug.

Als je naast het model een live beeld van de productie wilt, is dat een apart project met een eigen datafeed. Beschouw dat als de volgende fase, zodra de simulatie-KPI's vertrouwd worden.

Hoe houd je het model na verloop van tijd betrouwbaar?

Een model dat in maart klopt, kan in september fout zijn, omdat het proces is veranderd.

• Kalibreer opnieuw. Vergelijk elk kwartaal, of na elke grote wijziging, de KPI's van het model met de werkelijke KPI's, en pas de invoer aan als ze uit elkaar lopen.
• Zorg voor eigenaarschap van de invoer. Cyclustijden, insteltijden, storingsgedrag en shiftkalenders hebben een benoemde eigenaar nodig die ze bijwerkt. Behandel de simulatiedata als een product dat een beheerder heeft.
• Neem mensen mee waar het ertoe doet. Operators beïnvloeden de resultaten via afwezigheid, vaardigheden en variatie in werktempo. Je hoeft vermoeidheid niet te modelleren om dit te zien: met realistische variatie in cyclustijden en de echte bezetting per shift kom je al een heel eind. Vraag de shiftleiders of de aannames van het model kloppen.
• Kijk de doelen opnieuw na. Neem geen benchmark van een andere fabriek over in je model zonder te controleren of die past bij jouw productmix. Gebruik eerst je eigen uitgangssituatie.

Veelgemaakte fouten

• Begin met het dashboard. Bepaal eerst de KPI's en de vraag.
• Te veel KPI's. Een pagina met twintig getallen wordt niet gelezen.
• Verschillende definities in model en fabriek. Dan is geen vergelijking mogelijk.
• Eén run per scenario. Toeval bepaalt dan je conclusie.
• De basislijncontrole overslaan. Als het model het verleden niet kan reproduceren, hebben de prognoses geen basis.
• Meerdere zaken per scenario wijzigen. Dan leer je niets over de oorzaak.
• Prognoses tonen als live data. Label scenarioresultaten duidelijk.
• Geen eigenaar voor de invoer van het model. Verouderde invoer levert zelfverzekerde, foute antwoorden op.

Waar Polaris past

Voor dit soort studies zijn er twee modules van iFAKT Polaris die je kunt bekijken. iFAKT beschrijft de Polaris Simulator als een tool die het productiesysteem virtueel test voordat er echte beslissingen worden genomen, met capaciteits-, bezettings- en buffer­scenario's, en die knelpunten en ongelijke bezetting in de tijd laat zien. De Polaris Analyzer biedt KPI-dashboards over de modules heen en vergelijkt geplande en werkelijke waarden. Zoals bij elke tool geldt: controleer of de KPI-definities erin overeenkomen met de jouwe, en probeer het eerst op één productielijn.

Gerelateerde onderwerpen om te verkennen

• Hiërarchieën van KPI's. Hoe waarden per lijn, shift, afdeling en fabriek worden opgeteld zonder op elk niveau opnieuw te berekenen.
• Databronnen voor het model. Welke ERP-, machine- en handmatige gegevens voeden het model, en hoe controleer je de kwaliteit ervan.
• Normaliseren over fabrieken heen. Hoe je locaties met verschillende automatiseringsniveaus vergelijkt zonder fabrieken met veel productvarianten te benadelen.
• Variatie in personeel in modellen. Welke effecten van operators en shifts de moeite waard zijn om te modelleren, en welke complexiteit toevoegen zonder er iets mee op te leveren.
• Van plan naar werkelijkheid. Hoe je het gekozen scenario vergelijkt met echte KPI's nadat de wijziging live is gegaan.

Volgende stap

KPI-tracking voor productiesimulaties loont wanneer het model en de fabriek dezelfde cijfers spreken. Neem je volgende simulatievraag, schrijf het KPI-overzicht op één pagina met formule, tijdsbasis en eenheid, en controleer dat tegen een echte eerdere periode voordat je het eerste scenario draait.