What-If Scenarioanalyse in productieplanning: een methode
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 ·
What-if scenarioanalyse in productieplanning betekent het plan kopiëren, één aanname veranderen en de resultaten vergelijken. Leer de stappen, gegevens, tools en controles.
Automatically translated with AI from the original post. Read the English original
What-if scenarioanalyse in productieplanning betekent dat je een basisplan aanhoudt, één aanname verandert en het resultaat vergelijkt voordat er echt iets gebeurt. De aanname kan zijn dat een machine twee shifts stilstaat, een spoedorder, een ontbrekend materiaal of een nieuw shiftmodel. De vergelijking laat zien wat elke keuze doet met leverdatums, belasting en overwerk. Dit artikel is bedoeld voor productieplanners die een herhaalbare methode willen, geen eenmalig spreadsheet, en die willen weten welke gegevens, tools en controles de antwoorden betrouwbaar maken.
Belangrijkste punten
- Een what-if-scenario neemt je basisplan, verandert één aanname, zoals een machinestoring of een spoedorder, en vergelijkt het resultaat met de basis voordat er echt iets gebeurt.
- Begin met de beslissing en kies daarna twee of drie hefbomen en twee of drie KPI's. Een scenario zonder beslissing erachter is namelijk alleen een oefening.
- Verander eerst één hefboom tegelijk en combineer hefbomen pas nadat je het effect van elk afzonderlijk begrijpt.
- Test het model eerst op een voorbije periode voordat je het voor een toekomstige periode vertrouwt. De waarde van een model hangt ervan af of de uitkomst nauwkeurig genoeg is voor het doel.
- Microsoft-tools dekken delen van het werk: Dynamics 365-hoofdplannen kunnen alternatieve planningsstrategieën bevatten, en what-if-parameters in Power BI zijn geschikt voor eenvoudige berekeningen, niet voor het bepalen van de volgorde van een planning.
Wat is een what-if-scenario, en wat is het niet?
Een scenario is een samenhangende set aannames over de toekomst, doorgerekend in hetzelfde model als je basisplan. Het basisplan is je beste huidige plan. Al het andere is een variant daarop.
Het is de moeite waard om drie begrippen die mensen vaak door elkaar halen, uit elkaar te houden.
- Een voorspelling zegt wat je verwacht dat er gebeurt. Een scenario zegt wat er gebeurt als iets specifieks gebeurt.
- Een what-if-vraag is de vraag die je stelt. Fabrieksimulatie is één manier om die te beantwoorden, door een model van de fabriek te draaien met gekozen invoer. Een spreadsheet of een planningsrun in je ERP-systeem is een andere manier.
- Een gevoeligheidscontrole varieert één invoer over een bereik om te zien hoeveel het resultaat verschuift. Zo zie je welke aannames je aandacht verdienen.
Het doel van alle drie is hetzelfde: de gevolgen van een beslissing leren kennen terwijl het nog goedkoop is om van gedachten te veranderen.
Welke beslissingen zijn een scenario waard?
Doe een scenario wanneer een beslissing duur is om terug te draaien, wanneer meerdere beperkingen elkaar beïnvloeden, of wanneer het antwoord uit ervaring niet vanzelf duidelijk is. Typische aanleidingen in productieplanning:
- Een knelpuntmachine gaat voor onderhoud uit de running, en je moet kiezen welke orders uitlopen.
- Een klant vraagt om een eerdere datum. Wat schuift daardoor door, en wie betaalt de prijs?
- Verlof of ziekte verlaagt de bezetting voor een week.
- Een leverancier meldt vertraging op een belangrijk materiaal.
- De productmix verandert binnenkort, en je wilt weten of de huidige capaciteit nog voldoende is.
- Je overweegt een tweede shift, een nieuwe buffer of extra gereedschap.
Sla scenario's over voor beslissingen die goedkoop en snel terug te draaien zijn, en voor vragen waarbij het plan al haalbaar is met ruime speling. Een scenario kost tijd van een planner, en het moet een betere beslissing opleveren.
Hoe voer je een what-if-scenarioanalyse uit in de productie?
Hier is een werkwijze die werkt in een spreadsheet en in gespecialiseerde software.
- Leg de beslissing vast. Eén zin: "We moeten vóór vrijdag beslissen over X." Lukt dat niet, dan heb je nog geen scenario nodig.
- Bevries de baseline. Sla het huidige plan op met de aannames: agenda's, doorlooptijden, orderlijst, beschikbaarheid van materiaal. Elk scenario wordt vergeleken met deze versie, dus die mag niet onder je veranderen.
- Kies de hefbomen. Hefbomen zijn de zaken die je kunt veranderen of die kunnen veranderen: capaciteit, bezetting, orderprioriteiten, leverdatums, aankomst van materiaal. Kies er twee of drie die voor deze beslissing ertoe doen.
- Stel realistische bandbreedtes vast. Vraag het aan de mensen die het weten. Hoe lang duurt een gewone reparatie? Hoe vaak leveren leveranciers te laat, en hoeveel? Verzin geen getallen; gebruik je eigen historie en markeer elke schatting als schatting.
- Kies de meetwaarden. Twee of drie KPI's zijn voldoende: levering op tijd, doorlooptijd, bezetting van het knelpunt, overuren en werk in uitvoering. Leg ze vast voordat je iets draait, zodat niemand achteraf de gunstigste kiest.
- Wijzig één hefboom tegelijk. Draai elk scenario tegen de baseline. Combineer hefbomen pas nadat je het effect van elk afzonderlijk begrijpt.
- Vergelijk en beslis. Zet de baseline en de scenario's naast elkaar. Bespreek wat je in elk geval zou doen, en leg de beslissing en de reden vast.
- Bewaar het logboek. Sla de aannames en het resultaat op bij de beslissing. Je hebt ze nodig wanneer je terugkijkt op wat er echt gebeurd is.
Hier is een hypothetisch voorbeeld, alleen verzonnen om de logica te tonen. Een cel heeft één knelpunt-pers die 300 eenheden per shift maakt. De fabriek draait tien shifts per week, dus de capaciteit is 3.000 eenheden. De orders van deze week tellen op tot 2.700 eenheden, dat is 90% van de capaciteit. De baseline is haalbaar, met één shift speling.
- Scenario A: De pers valt twee shifts uit. De capaciteit daalt naar acht shifts, of 2.400 eenheden. Dat laat 300 eenheden onbedekt, dus sommige orders halen hun datum niet.
- Scenario B: Zelfde uitval, plus een shift op zaterdag. De capaciteit is weer 2.700 eenheden, maar de belasting is nu 100%. Elke verdere verstoring betekent een gemiste datum.
- Scenario C: Zelfde uitval, en de planner verschuift 300 eenheden aan orders met lage prioriteit naar volgende week. De belangrijke orders worden op tijd verzonden, en één klant krijgt vandaag een telefoontje in plaats van een verrassing op vrijdag.
Hiervoor is geen geavanceerd hulpmiddel nodig. Je hebt een baseline nodig, één hefboom en een eerlijke vergelijking. De waarde zit in het inzien dat B eruitziet als oplossing, maar geen reserve heeft.
Welke gegevens en hulpmiddelen heb je nodig?
Begin met wat je hebt. Een scenario heeft dezelfde invoer nodig als het plan zelf: orders en leverdatums, routings en doorlooptijden, resources en agenda's, beschikbaarheid van materiaal. Als deze gegevens onbetrouwbaar zijn, neemt elk scenario de fout over. Repareer eerst de stamgegevens, anders discussieer je over het model in plaats van over de beslissing.
Kies daarna het hulpmiddel op basis van de complexiteit van de vraag.
- Een spreadsheet is prima wanneer één of twee resources en een handvol orders het antwoord bepalen, zoals in het voorbeeld hierboven.
- Je ERP-planningsrun kan materiaalgedreven vragen aan. In Dynamics 365 Supply Chain Management laten hoofdplannen je verschillende planningsstrategieën simuleren, en volgens de documentatie van Microsoft kun je zoveel plannen opzetten als je wilt en sommige bewaren voor verschillende prognoses of simulaties. Controleer bij je implementatiepartner hoe dit past bij jouw versie en je planningsengine, want de pagina beschrijft de afhandeling van scenario's niet in detail. Hoofdplanning werkt op materialen en capaciteit op grof niveau en is geen gedetailleerd hulpmiddel voor volgordebepaling.
- Een eindige-capaciteitsplanner of een simulatiemodel is de juiste keuze wanneer gedeelde machines, volgordeafhankelijke omstellingen, shifts en vaardigheden elkaar beïnvloeden. In dat geval kan een eenvoudige berekening er goed uitzien terwijl het dagelijkse schema niet haalbaar is.
- Power BI is een goede plek om scenarioresultaten aan managers te laten zien. Met de what-if-parameters kunnen gebruikers een schuifregelaar verplaatsen en zien hoe een meting verandert. Volgens Microsoft zijn ze bedoeld voor gebruik in metingen binnen visuals, en een parameter kan maximaal 1.000 unieke waarden hebben. Dat maakt ze bruikbaar voor eenvoudige vragen als "wat doet 5% meer uitval met de output?" Ze plannen geen volgorde van een planning. Gebruik ze als voorkant voor resultaten, niet als motor.
Welk hulpmiddel je ook kiest, bewaar twee dingen buiten dat hulpmiddel: de schriftelijke aannames en het beslisregister. Hulpmiddelen veranderen, documenten blijven.
Hoe weet je dat de antwoorden betrouwbaar zijn?
Een scenario is alleen zo goed als het model erachter. Drie controles helpen.
Test het met historische data (backtesten). Draai het model over een periode in het verleden waarvan je weet wat er gebeurd is. Vergelijk de uitkomst met de echte resultaten. In de simulatieliteratuur heet dit operationele validiteit: of het gedrag van de uitvoer van een model nauwkeurig genoeg is voor het beoogde doel, binnen het bereik van omstandigheden waarvoor het gebruikt wordt. Een paper van Sargent en collega's van de Winter Simulation Conference beschrijft het zo en wijst erop dat het risico van de gebruiker, namelijk een verkeerd model accepteren, klein gehouden moet worden. Simpel gezegd: als het model vorige maand niet kan reproduceren, gebruik het dan niet om volgende maand te beslissen.
Ken je drijvers. Varieer elke aanname binnen zijn bereik en kijk welke het resultaat echt verschuiven. Vaak domineren twee ervan. Die verdienen betere data. De rest mag ruw blijven.
Toon de bandbreedte, niet één getal. Een uitspraak als "we leveren donderdag" suggereert een precisie die je niet hebt. "Tussen woensdag en vrijdag, afhankelijk van de reparatietijd" is eerlijker en nuttiger. Besluitvormers kunnen met onzekerheid overweg als ze die kunnen zien.
Hoe maak je er een gewoonte van in plaats van een project?
Scenariowerk loopt vast als het afhangt van het spreadsheet van één persoon. Een paar werkwijzen houden het levend.
- Wijs een eigenaar aan voor de uitgangssituatie en de modelgegevens. Zonder eigenaar loopt het model weg van de werkelijkheid op de fabrieksvloer.
- Plan wekelijks een korte vergadering waarin de planner, de productieleider en, waar nodig, inkoop en verkoop de openstaande vragen bespreken. Neem twee of drie scenario's mee, niet twintig.
- Evalueer achteraf. Vergelijk na afloop van de week wat er gebeurd is met wat het scenario voorspelde. Waar zat het ernaast, en waarom? Werk het model of de bandbreedtes bij.
- Deel de logica, niet alleen de uitkomst. Als de productieleider de aannames begrijpt, zullen ze die vroeg uitdagen, en dat is precies het doel van de oefening.
- Houd financiën betrokken. Kostenvragen, zoals overwerk tegenover een late levering, vragen om dezelfde scenario's met kostencijfers erbij. Spreek de kosteninvoer één keer af, zodat de cijfers niet tussen vergaderingen veranderen.
Live data helpt zodra de basis werkt. Als de werkelijke voortgang terugvloeit in het plan, starten scenario's vanuit de werkelijke situatie op de fabrieksvloer in plaats van vanuit het plan van gisteren. Zorg eerst dat de logica en de stamgegevens kloppen. Een live feed bovenop een zwak model levert alleen sneller foute antwoorden op.
Veelgemaakte fouten
- Scenario's draaien zonder beslissing waar ze op aansluiten.
- Meerdere knoppen tegelijk veranderen, zodat niemand weet wat het effect veroorzaakte.
- Scenario's vergelijken met een uitgangssituatie die in de tussentijd is veranderd.
- Best-case cijfers gebruiken voor cyclustijden en reparatietijden.
- Het backtesten overslaan omdat het model "goed lijkt".
- Eén getal rapporteren in plaats van een bandbreedte.
- Scenario's bouwen voor alles en op geen enkele ervan handelen.
- Vergeten de beslissing vast te leggen, zodat de evaluatie niets heeft om mee te vergelijken.
Waar Polaris past
Als je what-if-vragen gaat over gedeelde machines, ploegendiensten en wisselende productmixen, beantwoordt een simulatie van het productiesysteem ze sneller dan een spreadsheet. iFAKT beschrijft Polaris als AI plus een digitale tweeling voor productie, die werkt met ERP-data. De module Polaris Simulator test het productiesysteem virtueel voordat je echte beslissingen neemt, inclusief scenario's voor capaciteit, bezetting en buffers, en laat knelpunten en onevenwichtigheden in bezettingsgraad zien. De module Polaris Optimizer maakt binnen de gestelde randvoorwaarden een geoptimaliseerd plan en analyseert de impact van verstoringen. Probeer het eerst op één echte beslissing en controleer de resultaten tegen een spreadsheetberekening die je vertrouwt.
Gerelateerde onderwerpen om verder te verkennen
- Verstoringsplanning: hoe je standaardreacties voorbereidt op machinestoringen, te late materialen en afwezigheid.
- Capaciteit versus eindige planning: waarom een wekelijks belastingoverzicht er goed uit kan zien terwijl de dagplanning faalt.
- Wijzigingen in de productmix: testen hoe een verschuiving naar complexe varianten het knelpunt verplaatst.
- Modelvalidatie in de praktijk: gesimuleerde en werkelijke doorlooptijden voor een afgelopen periode met elkaar vergelijken.
- Scenariorapportage: basis en scenario's naast elkaar tonen in Power BI, zodat managers de logica kunnen volgen.
Volgende stap
Neem de volgende beslissing die op je bureau ligt en formuleer die in één zin. Sla daarna je huidige plan op als basisscenario en draai er drie scenario's op, waarbij je telkens één hefboom aanpast. Deze kleine ronde what-if-scenarioanalyse in productieplanning laat zien of de methode een vaste plek verdient in je wekelijkse vergadering.