Simulatiesoftware voor productie: zo evalueer en kies je

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

Simulatiesoftware voor productie kies je makkelijker aan de hand van een scorecard dan aan de hand van een ranglijst. Criteria, testvragen en een eerlijke vergelijkingsmethode voor fabrieksmanagers.

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

Simulatiesoftware voor productie is de tool achter fabrieksimulatie: je bouwt een computermodel van een lijn of fabriek en test beslissingen voordat er echt geld wordt uitgegeven. Het kiezen van de juiste tool gaat minder over een lijst met functies en meer over drie zaken: de vraag die beantwoord moet worden, de data die je kunt aanleveren en de mensen die de modellen bouwen en lezen. Deze gids is bedoeld voor fabrieksmanagers die een softwareselectie moeten uitvoeren en een scorecard willen die ze kunnen verdedigen.

Belangrijkste punten

• Kies simulatiesoftware voor productie op basis van je vraag, je data en de mensen die de modellen bouwen en lezen, niet op basis van een populariteitslijst.
• Een studie van de Winter Simulation Conference uit 2016 rangschikte tools op populariteit en stelt zelf dat populariteit geen garantie voor kwaliteit is; de meeste tools hebben vergelijkbare functielijsten.
• Discrete-event- en agent-gebaseerde benaderingen passen beide bij procesontwikkeling, dus de keuze hangt vaak af van de software en van wie het model bouwt.
• Controleer of de tool herhaalde runs ondersteunt met betrouwbaarheidsintervallen en warm-up-afhandeling, want één run is slechts één steekproef.
• Vergelijk finalisten met dezelfde casus, met je eigen data, vooraf vastgestelde wegingen en een overzicht van de modelleeruren die elke tool nodig had.

Welke soorten simulatiesoftware voor productie bestaan er?

Twee indelingen helpen je de markt te ordenen. De eerste is de modelleringsaanpak, de tweede is hoe het model wordt opgebouwd.

Een studie over Lean Six Sigma vergeleek drie aanpakken aan de hand van een fabriekscasus: discrete-event, agent-gebaseerd en systeemdynamica. De auteurs concludeerden dat discrete-event- en agent-gebaseerde simulatie ongeveer even geschikt zijn voor het ontwikkelen van productieprocessen, en dat de keuze mogelijk afhangt van de beschikbare software of de voorkeur van de modelleur. Ook vonden ze hybride modellen zeer veelbelovend. Kortom: het paradigma is minder belangrijk dan veel mensen denken. Belangrijk is of de tool je stroom, je regels en je variabiliteit kan weergeven.

In de praktijk vallen de vragen in een paar groepen, en tools neigen meestal naar één van die groepen:

• Stroommodellen volgen producten langs stations, buffers en wachtrijen. Ze beantwoorden vragen over doorvoer, doorlooptijd en werk in uitvoering.
• Modellen met individuele actoren, zoals planners, orders of transporteurs die hun eigen regels volgen. Ze zijn nuttig wanneer gedrag en beslissingen net zo belangrijk zijn als de stroom.
• Modellen op hoog niveau van hoeveelheden over langere periodes, gebruikt voor strategische vragen.
• Fysieke of 3D-modellen van machines en robots. Ze beantwoorden een andere vraag, namelijk of een beweging of indeling in de ruimte werkt.

De manier waarop het model wordt opgebouwd is de tweede indeling. Sommige tools zijn visueel en werken met slepen en neerzetten. Andere werken met tabellen en spreadsheets. Weer andere zijn codebibliotheken die je team programmeert. Hoe meer vrijheid een tool biedt, hoe meer vaardigheden er nodig zijn.

Als je ook een digital twin overweegt, let dan op dat die een ander probleem oplost: die blijft verbonden met live fabrieksdata, terwijl een simulatie op verzoek wordt uitgevoerd om keuzes te testen. Beantwoord die vraag eerst.

Waarom helpt een ranglijst niet?

Lijstjes met de beste tools staan overal, en ze zijn verleidelijk. Ga er voorzichtig mee om.

Het paper Discrete Simulation Software Ranking van de Winter Simulation Conference uit 2016 rangschikte tools op populariteit, op basis van webzoekopdrachten, publicaties, reviews en sociale netwerken. De auteurs stellen dat meer populariteit niet automatisch meer kwaliteit betekent. Volgens hen mag populariteit niet het enige selectiecriterium zijn; ze raden aan het te combineren met een vergelijking van functionaliteiten en met experimenteren. Ook merken ze op dat de meeste tools vergelijkbare functielijsten hebben, waardoor een pure functievergelijking lastig tot een conclusie leidt.

Eén echt voordeel van een populaire tool is dat je mensen vindt die ermee kunnen werken. Dat telt wanneer je iemand aanneemt of wanneer je consultant vertrekt. Weeg het mee, maar laat het niet de doorslag geven.

Welke criteria zijn het belangrijkst?

Gebruik deze als rijen in je scorecard. Bij elk criterium is de vraag aan de rechterkant wat je tijdens een demo zou vragen.

1. Past bij je vraagstelling. Kan de tool je processtroom, je batchregels, je shiftkalenders en je omstelmomenten weergeven zonder omwegen? Vraag de leverancier om live één lastig onderdeel van jouw productielijn te modelleren.
2. Data-import. Kan de tool routings, resources en orders inlezen uit je ERP-exports, Excel-bestanden of een database, en kun je het model verversen zonder het opnieuw op te bouwen? Een model dat gevoed wordt met overgetypte getallen veroudert snel.
3. Afhandeling van experimenten. Kan de tool veel scenario's draaien en elk scenario automatisch herhalen? Zie de volgende sectie.
4. Ondersteuning bij validatie. Kun je de output van het model vergelijken met eerdere resultaten, één enkel product door het model volgen en nagaan waarom iets gebeurde?
5. Resultaten en rapportage. Kan de tool de KPI's opleveren die jij volgt, en resultaten exporteren naar de tools die je managers gebruiken, zoals Excel of Power BI? Animatie helpt mensen een model te geloven, maar cijfers beslissen.
6. Benodigde vaardigheden. Wie in je fabriek kan een model bouwen en onderhouden, en hoe lang duurt de opleiding? Een tool die maar één expert begrijpt, overleeft zelden het vertrek van die expert.
7. Doorlooptijd en schaal. Hoe lang duurt een realistisch model om te draaien, en wat gebeurt er bij tien keer zoveel orders?
8. Automatisering en integratie. Is er een interface om modellen vanuit scripts of andere systemen te starten?
9. Kosten over drie jaar. Licenties, opleiding, uren van de modelleur, datavoorbereiding en support. Reken ook de kosten van het volgende model mee, niet alleen die van het eerste.
10. Exit. Kun je de modelstructuur en de data exporteren als je van tool wisselt?

Waarom verdient de afhandeling van experimenten een eigen controlepunt?

Simulatiemodellen met willekeurige invoer geven bij elke run een ander antwoord, dus één run is slechts één steekproef. Een MIT-college over experimentontwerp (gehost op een spiegelserver van MIT OpenCourseWare) formuleert de kernvraag als: hoeveel onafhankelijke replicaties heb je nodig voor een bepaalde nauwkeurigheid? Het beschrijft ook een stopregel op basis van de breedte van een betrouwbaarheidsinterval. Voor modellen die continu draaien, behandelt het ook de inloopperiode: je negeert de eerste waarnemingen van elke replicatie en middelt de rest. De methode van Welch helpt je bepalen waar die inloopperiode eindigt.

Die berekeningen hoef je zelf niet te maken, maar de software moet ze wel kunnen. Vraag of de tool replicaties automatisch kan draaien, betrouwbaarheidsintervallen kan rapporteren, kan helpen een inloopperiode vast te stellen en scenario's in één overzicht kan vergelijken. Als de tool alleen één geanimeerde run kan tonen, beslis je uiteindelijk op basis van een muntworp.

Wat is er mis met het draaien van veel scenario's?

Wanneer je tientallen scenario's test met elk veel replicaties, wordt de doorlooptijd al snel een echte kostenpost. Replicaties zijn onafhankelijk van elkaar, dus ze kunnen tegelijk draaien. Microsoft beschrijft Azure Batch als een service voor grootschalige parallelle taken die niet met elkaar hoeven te communiceren, en noemt Monte Carlo-simulatie als voorbeeld. Je brengt je eigen applicatie mee en Batch rolt die uit naar een pool van virtuele machines. Dat helpt alleen als je simulatietool zonder scherm vanaf de opdrachtregel kan draaien en de licentie dat toestaat, dus zet beide op je vragenlijst. Azure-capaciteit bespreek je pas met IT als een pilot laat zien dat je die nodig hebt.

Moet je een tool kopen, een specialist inhuren of zelf iets bouwen?

Wees eerlijk over hoe vaak je het gaat gebruiken.

• Huur een specialist in als je er één of twee grote vragen per jaar hebt, zoals een nieuwe lijn of een grote investering. Je betaalt voor de studie en slaat de training over.
• Koop een tool als planners regelmatig opties willen testen, bijvoorbeeld shiftmodellen, productmix en buffergroottes. Reserveer tijd voor training en voor het actueel houden van het model.
• Bouw zelf met een programmeerbibliotheek alleen als je mensen hebt die de code kunnen schrijven en onderhouden. De flexibiliteit is hoog, maar ook de afhankelijkheid van die mensen.

Veel fabrieken beginnen met een studie door een specialist, leren welke vragen ze echt hebben en kiezen daarna pas een tool.

Hoe voer je een eerlijke vergelijking uit?

Een eerlijke test duurt enkele weken, niet maanden.

1. Formuleer de vraag. Één beslissing, één datum, één eigenaar.
2. Stel één datapakket samen voor één lijn of cel: routings, tijden, resources, kalenders, vraag en een maand aan werkelijke resultaten.
3. Bepaal eerst de weging. Leg vast hoe zwaar dataimport, het omgaan met experimenten, vaardigheden en kosten meewegen voordat je een demo ziet.
4. Geef elke finalist dezelfde case en dezelfde deadline.
5. Laat je eigen mensen ermee werken. Let op waar ze vastlopen.
6. Valideer tegen de historie. Reproduceert het model vorige maand binnen een marge die jullie hebben afgesproken?
7. Registreer de inspanning. Uren van de modelbouwer, uren voor het opschonen van data, vragen aan support.
8. Score samen. Productie, planning, IT en finance scoren elk hun eigen rijen.

Als een leverancier je data niet in een pilot wil draaien, is dat ook een antwoord.

Veelgemaakte fouten

• Kiezen op basis van een ranglijst. Die laat zien wat populair is, niet wat past.
• Kopen op basis van de demo. Een strakke animatie zegt niets over het verwerken van data of het ondersteunen van experimenten.
• Negeren wie de modellen bouwt. De beste tool voor een expert kan de verkeerde zijn voor jouw team.
• Validatie overslaan. Een model dat het verleden niet kan reproduceren, verdient geen vertrouwen voor de toekomst.
• Het datawerk onderschatten. Het verzamelen en opschonen van invoerdata kan net zo lang duren als het bouwen van het model.
• Beslissen op basis van één run. Zonder replicaties kun je een echte verbetering niet onderscheiden van ruis.

Waar Polaris bij past

Als je een simulatie wilt die start vanuit je ERP-data, is iFAKT Polaris een kandidaat. iFAKT omschrijft Polaris als AI plus een digitale tweeling voor productie. De module Polaris Designer bouwt uit ERP-data, stuklijsten en procestijden een kennisgraaf van product, proces en resource. De module Polaris Simulator gebruikt die graaf om capaciteit, bezetting en buffer-scenario's virtueel te testen en knelpunten en onevenwichtigheden in bezetting zichtbaar te maken. Laat hem door dezelfde scorecard en dezelfde pilotcase gaan als elke andere kandidaat.

Gerelateerde onderwerpen om te verkennen

• Invoerdata voor simulatie. Welke tijden en regels je eerst verzamelt, en hoe je die controleert met de mensen op de vloer.
• Een model valideren. Hoe je de output vergelijkt met een eerdere periode en de afwijkingen documenteert.
• Simulatie en live data. Wat er verandert wanneer een model is gekoppeld aan de productievloer.
• Simulatieresultaten rapporteren. Welke weinige KPI's managers nodig hebben en hoe je scenario's naast elkaar toont.
• Het personeel voor een simulatiecapaciteit inzetten. Wie bouwt de modellen, wie is eigenaar en wie controleert ze.

Volgende stap

Het kiezen van software voor productiesimulatie wordt eenvoudiger zodra je een scorecard hebt met vooraf afgesproken wegingen. Kies één echte beslissing in je fabriek, stel het datapakket daarvoor samen en geef dezelfde case aan twee of drie kandidaten.