Advanced planning and scheduling: waaraan een planning moet voldoen

Het uitgangspunt is dat je je eigen proces kent en nog nooit planningssoftware hebt gekocht.

Restricties waaraan een echte lijn moet voldoen

Begin bij de restricties, want de software is alleen interessant voor zover zij die kan weergeven. Een machine draait één werkorder tegelijk, en de tijd om van de lopende order naar de volgende te komen hangt meestal af van wélke twee orders dat zijn. Van een lichte kleur naar een donkere is even uitvegen; van donker naar licht is spoelen en reinigen. Dat is volgordeafhankelijke omsteltijd: de omsteltijd is geen eigenschap van een bewerking maar van een paar bewerkingen op een bepaalde resource, want dezelfde kleurwissel kost op een grote pers iets anders dan op een kleine, en op sommige lijnen hangt het ook nog af van de machinetoestand. Het is de restrictie die het vaakst ontbreekt in het bronsysteem, en daarom ziet een planning uit ERP er zo vaak uit als een gesorteerde lijst in plaats van als een volgorde.

Dan de restricties die niet aan één machine hangen, en die op veel lijnen harder knellen dan de omstelmatrix. Een matrijs, een stempel of een testopstelling kan maar op één plek tegelijk zijn, dus twee cellen die de order elk zouden kunnen draaien, kunnen dat niet allebei tegelijk. Een gekwalificeerde operator is net zo'n schaars object: drie mensen in de ploeg en één gecertificeerd voor de lasklasse betekent dat die klasse een capaciteit van één heeft. Perslucht, een oven of een kraan knelt over een heel gebied, dus twee orders die afzonderlijk passen, passen samen misschien niet.

Materiaalbeschikbaarheid is een harde randvoorwaarde en een zachte invoer. De order kan niet starten voordat het onderdeel binnen is, maar de leverdatum is een belofte van een leverancier met een eigen betrouwbaarheid. De planning moet daarom laten zien welke orders afhangen van een levering die nog niet binnen is, zodat dat risico zichtbaar is op het planbord in plaats van uitgemiddeld in een levertijd en ontdekt op de ochtend dat het materiaal niet arriveert.

Kalenders dragen meer dan mensen verwachten. Ploegenpatronen verschillen per afdeling en niet per fabriek: warmtebehandeling draait door de nacht heen en assemblage niet, en een omstelling op vrijdag die niet voor het einde van de ploeg af is, wordt twee keer gedaan. Onderhoudsvensters, feestdagen en de jaarlijkse stop zijn periodes waarin een resource wel op de assetlijst staat en niet beschikbaar is voor productie.

En er zijn procesregels die niets met capaciteit te maken hebben. Uitharden, drogen, afkoelen en quarantaine leggen minimale wachttijden tussen bewerkingen op, en vaak ook maximale: minstens vier uur uitharden, binnen vierentwintig uur coaten, de aangemaakte lijm binnen zijn potlife verwerken, het deel wassen voordat vliegroest ontstaat. Een planningssysteem dat minimale wachttijden begrijpt maar maximale niet, produceert stilletjes planningen die materiaal afkeuren. Sommige paren bewerkingen moeten aaneengesloten zijn omdat het deel niet halfafgewerkt mag blijven liggen; sommige batches moeten op een tankinhoud worden gemaakt en niet op een vraaghoeveelheid.

Waarom de MRP-run datums oplevert die niemand haalt

MRP doet iets dat echt nuttig is, en dat is geen planning in de fijne zin. Het explodeert de vraag door de stuklijsten, verrekent met voorraad en openstaande orders, schuift per artikel een vaste doorlooptijd terug, en vertelt je wat je moet maken of kopen en ongeveer wanneer je moet starten. Om dat over duizenden artikelen te kunnen doen, gaat het ervan uit dat capaciteit beschikbaar is zodra de rekensom erom vraagt.

Die aanname faalt geruisloos. Twee orders willen allebei om tien uur op de pers en MRP zet ze er allebei neer. De doorlooptijd is een getal dat ooit één keer is ingesteld, een gemiddelde van wacht-, bewerkings- en transporttijd onder omstandigheden die niet meer gelden, en omstellingen ontbreken ofwel, ofwel zitten erin verstopt als een vaste opslag die niet van de volgorde afhangt. Het resultaat is rekenkundig consistent en fysiek onhaalbaar, en dat is erger dan fout, omdat het er in het systeem correct uitziet.

De werkvloer vangt het verschil op. Iemand herplant met de hand, meestal goed, met kennis die in één of twee hoofden zit, en de planning wordt een suggestie. Alles wat ervan is afgeleid erft de fout: toegezegde leverdata, inkoopmomenten, bezetting, het capaciteitsgetal dat verkoop noemt. Als een planner daarop reageert door doorlooptijden op te rekken, is de bescherming echt en de prijs ook, want een opgerekte doorlooptijd betekent werk dat te vroeg wordt vrijgegeven, en dat wordt onderhanden werk dat tussen de werkplekken blijft staan.

Het spreadsheet dat die datums vervangt is een echte verbetering met een plafond. Het werkt omdat de planner de omstelmatrix en de gereedschapsconflicten in zijn hoofd heeft, en het faalt op schaal, tijdens zijn vakantie, en op de vraag wat er stukgaat als deze order wordt aangenomen.

Wat planning met eindige capaciteit verandert

Planning met eindige capaciteit draait de vraag om. In plaats van te vragen wanneer een bewerking zou moeten starten als niets in de weg ligt, plaatst zij bewerkingen op resources waar al werk op staat, rekening houdend met omstellingen, kalenders, gereedschap en volgorderelaties, en rapporteert zij de datums die daaruit volgen. De datums worden een uitkomst in plaats van een invoer.

De gevolgen zijn praktisch. De volgorde op elke resource is expliciet, dus de omstelmatrix kan worden benut: waar omstellen een wezenlijk deel van de beschikbare capaciteit kost, levert het groeperen van verwante producten omsteluren op zonder investering. Of dat jouw situatie is, is één getal dat je deze week kunt meten, en dat je eerst zou moeten meten, want op een lijn met omstellingen van vijf minuten en een materiaalprobleem levert de volgordebepaling vrijwel niets op. Knelpunten worden zichtbaar als belasting in plaats van als meningen. Omdat de planning begrensd is, laat het toevoegen van een order zien wat die verdringt, en dat is wat een geloofwaardige leverbelofte mogelijk maakt.

Het verandert ook de vrijgave. Een planning met oneindige capaciteit geeft werk zo vroeg vrij als de doorlooptijden toestaan; een eindige planning geeft vrij wanneer het knelpunt het aankan, wat het onderhanden werk omlaag brengt en de afstand verkort tussen het maken van een fout en het vinden ervan. Niets daarvan is gratis: het model moet worden onderhouden, en is niet eerlijker dan de tijden die erin staan.

Planning, fijnplanning en werkverdeling zijn drie verschillende taken

Het door elkaar halen hiervan is de meest voorkomende reden dat een planningsproject iets oplevert dat niemand gebruikt. Planning werkt in weken en maanden. Zij beantwoordt of de vraag in totaliteit haalbaar is, of er in maart een tweede ploeg nodig is, wat je aan leveranciers toezegt. De eenheid is een productfamilie en een week; meer precisie zou vals zijn, want de vraag is ook niet precies.

Fijnplanning werkt in uren en dagen. Zij beantwoordt de volgorde op elke resource voor de komende ploegen, met de omstellingen die die volgorde impliceert, en dat is waar APS in de engste zin op doelt.

Werkverdeling werkt in minuten. Zij beantwoordt waar de operator aan deze cel als volgende aan begint, gegeven de storing, het afgekeurde eerste product, het materiaal dat niet kwam. Zij hoort thuis in datgene waar de operator werkelijk naar kijkt — een MES-terminal, een werklijst, een volgorde die op de machine is geplakt — en wat telt is dat zij dicht bij het werk zit en mag afwijken van de planning, want de werkelijkheid heeft ook een stem.

De faalwijze is één gereedschap op de verkeerde hoogte gebruiken: drie weken vooruit tot op de minuut plannen, of capaciteit plannen vanuit een werklijst. De andere is afwijken op het niveau van de werkverdeling verbieden, waardoor het systeem een obstakel wordt en er gegarandeerd omheen wordt gewerkt.

Welke data een APS nodig heeft: routings, cyclustijden, omsteltijden

Een planningsengine is een rekensom over je stamgegevens. Zijn die decoratief, dan is de uitkomst decoratief en zelfverzekerd.

Routings moeten weergeven hoe het deel echt wordt gemaakt, inclusief alternatieven. Als een werkorder op drie machines kan draaien maar de routing er één noemt, zet het planningssysteem het werk daar in de rij en meldt het een knelpunt dat je niet hebt. Laat een routing een bewerking weg die altijd gebeurt — ontbramen, een controle, wachten op afkoelen — dan is elke datum precies zoveel te krap.

Cyclustijden moeten gemeten zijn en niet geërfd. Standaardtijden in de meeste ERP-systemen zijn bij de livegang ingevoerd en weerspiegelen een gereedschap en een operator die er misschien niet meer zijn. Je hebt geen perfecte tijden nodig, alleen tijden waarvan de fout klein is en niet systematisch één kant op wijst: een route waarin elke bewerking met dezelfde marge te optimistisch is, stapelt op tot een planning die er aan het eind van de week een hele ploeg naast zit.

Omsteltijden zijn de gegevens die het vaakst helemaal ontbreken, en de waardevolste. Een volledige matrix van elk productpaar is zelden te onderhouden. Wat wel werkt, is producten in families groeperen op wat de omstelling werkelijk bepaalt — kleur, materiaal, gereedschap, temperatuur, breedte — en tijden tussen families vastleggen, met uitzonderingen alleen waar die ertoe doen. Ga ervan uit dat je die familie-naar-familiematrix per resourcegroep bijhoudt en niet één keer voor de hele fabriek, want dezelfde overgang kost zelden hetzelfde op twee verschillende machines.

Het actuele onderhanden werk is het deel dat mensen vergeten. Een planning voor morgen begint bij de toestand van de werkvloer vanavond: wat halfafgewerkt is, waar het ligt, wat er op elke machine staat ingesteld. Wordt die toestand aan het eind van de ploeg vanaf een papieren lijst ingetypt, dan optimaliseert het planningssysteem een fabriek die uren geleden bestond.

Slechte data kondigt zichzelf aan. Eén resource zit altijd vol en de rest staat stil, wat meestal betekent dat routings er kunstmatig naartoe trechteren. Planners overrulen elke dag dezelfde orders, wat betekent dat er een restrictie in het model ontbreekt. Werkorders worden in batches op dezelfde minuut teruggemeld, wat betekent dat de terugmeldingen later worden overgetypt en de starttijden fictie zijn. De reflex is de engine bijstellen; de oorzaak zit vrijwel altijd in de stamgegevens.

Hoe je een planning beoordeelt

Leverbetrouwbaarheid is de uitkomst die telt, gemeten tegen de datum die de klant is gegeven en niet tegen de laatst herziene interne datum, anders verbetert het getal terwijl de ervaring van de klant hetzelfde blijft.

Totale omsteluren per week is de zuiverste maat voor de vraag of de volgordebepaling werk verzet, en is rechtstreeks om te rekenen naar capaciteit.

Onderhanden werk en doorlooptijd zeggen of de planning verstandig vrijgeeft. Een planning die de leverbetrouwbaarheid verbetert door de werkvloer te overspoelen met vroege vrijgaven, heeft het probleem naar de gangpaden verplaatst.

Planvastheid — hoeveel van wat voor een ploeg gepland stond er werkelijk is gedraaid, in de geplande volgorde — is de eerlijke maat voor de vraag of de planning geloofwaardig is. Een planning met uitstekende theoretische cijfers die de werkvloer al voor de lunch losliet, is een document.

Bezettingsgraad is de valkuil. Elke machine bezig houden op een niet-knelpunt levert voorraad op en geen output, en een lijn die overal tegen zijn plafond is belast, heeft niets meer over om variatie op te vangen, waardoor rijen niet-lineair groeien en doorlooptijden slechter worden naarmate het bezettingsgetal beter oogt. Bekijk het bij het knelpunt en negeer het verder grotendeels.

Herplanbeleid en planningsnervositeit

Een engine die in seconden kan herplannen, nodigt uit tot voortdurend herplannen. Doe het niet. Als de volgorde verandert zodra er iets beweegt, leert de werkvloer dat de planning van acht uur niet de planning van tien uur is, en valt zij terug op draaien wat verstandig lijkt. Die instabiliteit heet nervositeit, en zij vernietigt vertrouwen sneller dan een middelmatige planning.

Het bruikbare patroon is een bevroren horizon plus een beleid. Binnen dat venster verandert de volgorde niet, behalve bij echte blokkades, zodat al begonnen omstellingen niet worden weggegooid; daarbuiten mag opnieuw worden geoptimaliseerd. De vuistregel is: herplan niet vaker dan het bevroren venster lang is, en bepaal dat venster uit twee dingen die je in de afdeling kunt waarnemen: hoe lang een omstelling duurt, en hoe vaak er een echte blokkade opduikt. Een verspanende werkplaats met orders van een uur en bijna dagelijks een gereedschapsconflict bevriest een paar uur en herplant elke ploeg; een procesfabriek die campagnes van een week draait, bevriest dagen. Hoe dan ook worden de geplande herplanruns aangevuld met event-gestuurde runs bij een machinestoring, een uitblijvende levering of een spoedorder.

Twee dingen maken het beleid werkbaar. De uitzonderingenlijst moet expliciet zijn: wat geldt als reden om de bevriezing te doorbreken, en wie dat mag autoriseren. En als de planning wél verandert, moet de teamleider kunnen zien waarom, want een onverklaarde wijziging leest als onbetrouwbare software.

Waar APS staat naast ERP en MES, en wie waarover beslist

ERP is eigenaar van de commerciële en materiële wereld en is de bron van wat er gemaakt moet worden en wanneer. APS is eigenaar van de volgorde, en haalt vraag en materiaal uit ERP, restricties uit zijn eigen model en de toestand van de werkvloer uit de uitvoering. MES is eigenaar van de uitvoering en van de registratie daarvan, en is tegelijk de sensor voor APS, zonder welke het planningssysteem blind is voor het heden.

De lus sluit alleen als hij beide kanten op loopt: van APS naar MES gaat de planning, van MES naar APS gaat wat er werkelijk is gebeurd. Een dagelijks bestand met terugmeldingen is genoeg om morgen te plannen en niet genoeg om vanmiddag te herplannen.

Eigenaarschap moet vóór de livegang worden vastgelegd, want de discussies zijn voorspelbaar. Wie een leverdatum mag wijzigen. Wie de omstelmatrix en de cyclustijden onderhoudt, en op welke herzieningscyclus. Wie de volgorde aan de cel mag overrulen, en of die afwijking wordt vastgelegd. Welk systeem leidend is als ERP en de planner het oneens zijn over wat er op voorraad ligt. Dit impliciet laten is de gebruikelijke reden dat een technisch gezonde implementatie vastloopt.

Een evaluatie uitvoeren die je iets vertelt

Een leveranciersdemo op leveranciersdata bewijst alleen dat de software draait. Beoordeel haar in plaats daarvan op je eigen fabriek; de oefening is goedkoop als je haar afbakent.

Kies één afdeling met echte restricties — forse omstellingen, gedeeld gereedschap, concurrerende orders — in plaats van de hele fabriek, en neem een periode uit het verleden van vier tot acht weken waarvan je weet wat er is gedraaid en wat te laat was. Geef de kandidaat de stamgegevens die je vandaag hebt, en geen versie die voor de test is opgeschoond, want de staat van je data is een van de dingen die je meet.

Vraag vervolgens om een planning voor die periode te reproduceren en vergelijk. Geeft het model jouw restricties weer, of moeten de lastige worden wegvereenvoudigd? Kan het maximale wachttijden net zo goed aan als minimale, als je proces een houdbaarheid of een potlife kent? Hoeveel omsteltijd gebruikt zijn volgorde tegenover wat je werkelijk kwijt was, en wat zegt het over de orders die je te laat hebt geleverd? Draai dan de scenario's die ertoe doen: het knelpunt twee dagen uit bedrijf, een spoedorder midden in de week, een levering een week te laat.

Zet daarna een planner er een middag voor. De vraag is niet of de engine slim is, maar of een mens kan zien waarom hij een beslissing nam en die kan bijstellen zonder met het gereedschap te vechten; een planningssysteem waarmee niemand in discussie kan gaan, is een systeem dat niemand zal gebruiken. Vraag wat het onderhoud van het model kost als een product, een machine of een omsteltijd verandert, en op hoeveel plekken. De meeste planningen verslechteren niet omdat de engine fout zat, maar omdat niemand het model bezat nadat het project was afgelopen.

Waar Meta Smart Factory past

De APS- en MRP-modules van Meta Smart Factory doen het eindige-capaciteitsdeel hiervan, tegen een restrictiemodel dat volgordeafhankelijke omsteltijden, gedeeld gereedschap, operatorkwalificatie en ploegenkalenders per afdeling omvat, met scenarioruns voor de verstoringen hierboven. Omdat ze in hetzelfde platform zitten als de MES-module, is er geen nachtelijke bestandsoverdracht tussen uitvoering en planner, zodat de toestand van de werkvloer zo actueel is als jouw terugmeldpunten en de meldingsdiscipline van je operators haar maken. Dat is een voorwaarde en geen detail: als de helft van de terugmeldingen in de pauze wordt ingevoerd en de handmatige assemblagestap geen scanpunt heeft, redt de architectuur je niet. Bepalen waar die punten zitten is implementatiewerk, geen bijproduct daarvan. De koppeling met ERP voor orders, stuklijsten en terugmeldingen hoort bij hetzelfde werk.

De onderdelen die bepalen of het geheel werkt, zijn niet aan ons om te leveren: gemeten cyclustijden, een omstelmatrix waar iemand eigenaar van is, routings die kloppen met hoe het deel echt wordt gemaakt, en een vastgelegd herplanbeleid. Zit je hier nog vroeg in, dan is de nuttige eerste stap geen demo maar de historische vergelijking die hierboven is beschreven, op één afdeling met restricties, met je data zoals die nu is.