Advanced Planning and Scheduling Software: hoe je APS beoordeelt

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

Advanced planning and scheduling software maakt planningen die rekening houden met echte beperkingen. Lees hoe je je behoefte bepaalt, APS-tools vergelijkt en er één test op je eigen data.

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

Advanced planning and scheduling software, meestal APS genoemd, berekent een productieplanning die past binnen echte beperkingen: machine-uren, shifts, vaardigheden, gereedschap en materiaal. Het is de stap voorbij een plan dat alleen aangeeft wat er gemaakt moet worden en wanneer materiaal nodig is. Deze gids is bedoeld voor productieplanners en operationeel leidinggevenden die moeten beslissen of ze APS nodig hebben en hoe ze de opties beoordelen, zonder dat een leverancier de criteria voor hen bepaalt.

Belangrijkste punten

• Advanced planning and scheduling software voegt op capaciteit gebaseerde planning en volgordebepaling toe aan wat MRP doet, zodat concurrerende orders en beperkte resources deel uitmaken van het plan.
• Bepaal je probleem voordat je naar producten kijkt: hoeveel orders strijden om dezelfde capaciteit, hoe vaak het plan faalt en wat de echte beperking is.
• Controleer wat je ERP-systeem al doet met eindige capaciteit voordat je iets koopt. Een deel daarvan is beperkt tot resources waarvoor je het moet inschakelen.
• Beoordeel tools op modellering van beperkingen, transparantie, handmatige aanpassingen door planners, stabiliteit bij herplannen en de inspanning om stamdata schoon te houden.
• Test op je eigen data: speel een week uit het verleden opnieuw af en vergelijk de planning van de tool met wat er werkelijk is gebeurd.

Wat is advanced planning and scheduling software?

Het APICS-woordenboek, geciteerd door ASCM, beschrijft een APS-systeem als een computerprogramma dat geavanceerde wiskundige algoritmen of logica gebruikt om planning- en schedulingfuncties te optimaliseren. Dat is breed. Een praktischer definitie komt van Fraunhofer IPA (een Duitstalig document, mijn vertaling). Die plaatst APS naast twee andere softwareklassen: supply chain management op netwerkniveau en manufacturing execution op productieniveau, met ERP op bedrijfsniveau. Daarnaast beschrijft het drie stappen in de planlogica.

MRP in zijn eerste vorm berekent alleen de materiaalbehoefte. De volgende stap voegt belastingsgebaseerde capaciteitsbehoeften toe, maar houdt nog steeds geen rekening met orders die om dezelfde resource concurreren. APS voegt capaciteitsplanning en volgordebepaling toe, zodat concurrerende orders en beschikbaarheid van materiaal deel uitmaken van het resultaat. Dat is het hele punt. Je krijgt een planning die je daadwerkelijk kunt uitvoeren, en niet alleen een lijst met behoeften.

Dit artikel kijkt vanuit het perspectief van de koper: wat je eerst moet beslissen, welke criteria ertoe doen en hoe je test. Voor een korte definitie van de term zelf, zie het lemma advanced planning and scheduling op deze site.

Waar zit APS tussen ERP en de productievloer?

ISA beschrijft ISA-95 als een internationale set standaarden voor de integratie van logistieke systemen met besturingssystemen in de productie. In het model staan bedrijfsplanning en logistiek, waar het ERP-systeem thuishoort, op niveau 4. Productiebeheer, inclusief MES, staat op niveau 3. APS werkt meestal in het gebied daartussen: het neemt orders en stamgegevens van bovenaf over, bouwt de planning en geeft die door aan de productievloer.

Fraunhofer IPA merkt op dat ERP meestal de bron is voor planningsgegevens, zoals artikelstambestanden, stuklijsten en routings. Dat laat zien waar je datawerk zich gaat afspelen. Als die gegevens in het ERP fout zijn, plant elke APS heel efficiënt het verkeerde.

Hetzelfde artikel wijst erop dat de markten voor APS en MES sterk overlappen. Vraag vroeg wie de dispatching op de vloer beheert. Een manufacturing execution system registreert wat er echt is gebeurd. APS bepaalt wat er hierna moet gebeuren. Als beide systemen de takenlijst claimen, werken planners en voormannen met twee lijsten.

Welk probleem moet het oplossen?

Fraunhofer IPA adviseert eerst je toepassingsfocus en eisen te definiëren, meestal via een as-is-analyse en een globaal concept, voordat je software evalueert. Doe dat aan de hand van deze vragen:

1. Hoeveel orders concurreren om dezelfde paar resources? Bij weinig orders kan een spreadsheet nog voldoende zijn.
2. Hoe vaak breekt de planning tijdens een shift, en waarom? Machinestilstand, ontbrekend materiaal, spoedorders?
3. Wat is de echte beperking: een machine, een vaardig medewerker, een gereedschap, een oven, een testopstelling?
4. Hangen de omsteltijden af van de volgorde van de taken? Als dat zo is, heeft sequencing echte waarde.
5. Wie maakt nu de planning, hoe lang duurt dat, en hoe vaak wordt die opnieuw gemaakt?
6. Welke beslissingen wil je dat de tool neemt, en welke blijven bij de planner?

Kijk daarna wat je ERP al kan. Microsoft documenteert bijvoorbeeld finite capacity planning and scheduling in Dynamics 365 Supply Chain Management. Daarmee wordt een geplande order die niet past binnen de beschikbare capaciteit verschoven naar een datum waarop er wel capaciteit is. Maar het werkt alleen voor resources waarvoor je het inschakelt, het gebruikt een time fence die bepaalt hoeveel dagen als finite worden behandeld, en Microsoft waarschuwt dat een time fence van één dag waarschijnlijk te kort is voor de meeste producenten. Ook staat er dat finite capacity niet gebruikt moet worden als de capaciteit verandert met de vraag, zoals capaciteit op basis van shifts. Als je beperking zo lijkt, heb je al iets geleerd voordat je met een leverancier praat. Je eigen ERP kan anders werken, dus zoek in de documentatie naar dezelfde soorten beperkingen. Het verwante idee van finite capacity scheduling is de basis van dit alles.

Welke criteria onderscheiden de ene APS van de andere?

Featurelijsten lijken op elkaar. Deze criteria maken in de praktijk het verschil.

• Modellering van beperkingen: kan het je echte grenzen weergeven? Machines, medewerkers met bepaalde vaardigheden, gereedschap, shiftkalenders, omsteltijden die afhangen van de volgorde, en vrijgave van materiaal.
• Transparantie: kan een planner zien waarom een taak op een bepaalde plek staat? Een planning die je niet kunt uitleggen, overleeft de eerste discussie op de vloer niet.
• Prioriteitsregels: kun je regels aanpassen (uiterste leverdatum, klant, omsteltijdbesparing) zonder hulp van de leverancier?
• Handmatige ingrepen: kan de planner een taak zelf verplaatsen, logt het systeem dat, en controleert het de rest van de planning opnieuw? Vraag wat er met de rest van de planning gebeurt na een handmatige verplaatsing.
• Gedrag bij herplannen: een herplanning na een verstoring moet alleen aanpassen wat echt moet veranderen. Een planning die bij elke wijziging alles opnieuw door elkaar gooit, is op de vloer niet bruikbaar. Fraunhofer IPA wijst er ook op dat plannen nooit exact uitgevoerd kunnen worden, dus je hebt een tolerantie nodig voor afwijkingen tussen werkelijkheid en planning.
• Data-interfaces: hoe krijgt het orders, routings en voortgang binnen, en wie onderhoudt die interfaces?
• Rekentijd: hoe lang duurt een volledige planning bij jouw datavolume? Fraunhofer IPA noemt dat rekentijden in de orde van minuten het plannen alleen 's nachts twijfelachtig maken, maar test met je eigen volume.
• Wat-als: kun je een scenario testen zonder het actuele schema aan te raken?
• Inspanning van de planner: hoeveel tijd kost het om de stamgegevens en regels actueel te houden?
• Kosten over meerdere jaren: licentie, koppelingen, onderhoud van stamgegevens, training, upgrades.

Wat moet je een leverancier vragen?

Neem deze punten mee naar het eerste gesprek. Goede antwoorden zijn specifiek, en vage antwoorden zeggen ook iets.

• Laat me een schema zien dat is opgebouwd uit onze data, niet uit jullie voorbeeldfabriek.
• Wat gebeurt er als een machine om 10.00 uur stilvalt? Wat verandert er, en wat niet?
• Hoe worden volgafhankelijke omsteltijden verwerkt?
• Welke van onze regels kan een planner zelfstandig wijzigen?
• Hoe worden handmatige aanpassingen vastgelegd en beoordeeld?
• Welke datakwaliteit hebben jullie van ons nodig, en wat doen jullie als die ontbreekt?
• Wie is eigenaar van de koppeling met ons ERP en met het systeem op de werkvloer?
• Waar lopen klanten met een vergelijkbaar proces (jobshop, repeterend, batch) meestal tegenaan?
• Kunnen we ons model, onze regels en onze data exporteren als we stoppen?

Hoe test je een APS voordat je hem koopt?

Gebruik een replay. Het is de goedkoopste manier om marketing van geschiktheid te scheiden.

1. Kies een echte week uit het verleden met een normale hoeveelheid problemen.
2. Laad de orders, routings, kalenders en resources zoals ze waren aan het begin van die week.
3. Laat de tool een schema maken.
4. Vergelijk dat met wat er werkelijk gebeurde en met het schema van de planner: te late orders, aantal omsteltijden, overwerk, wachttijd bij de bottleneck.
5. Introduceer een verstoring, zoals een stilstand van twee uur bij de bottleneck, en controleer wat de herplanning verandert.
6. Laat een planner de tool een dag gebruiken en noteer elk moment waarop die er niet op vertrouwde of het niet begreep.

Spreek succescriteria af voordat je begint. Anders wordt er achteraf over de resultaten gediscussieerd.

Voorbeeld: een replay met verzonnen cijfers

Dit voorbeeld is verzonnen om te laten zien hoe je een replay leest. Het is geen gemeten resultaat.

De werkelijke week van de planner had 120 orders, waarvan er 14 te laat waren. Het schema van de tool laat 9 te late orders zien. Een leverancier zou daar stoppen en het een overwinning noemen. Een zorgvuldig team kijkt naar de vijf orders die de tool "heeft gered". Twee daarvan waren afhankelijk van een machine die in werkelijkheid het grootste deel van die week stilstond, en de tool wist dat niet, omdat stilstanden niet in de invoer zaten. Een ander was afhankelijk van een routingtijd die te optimistisch was. Slechts twee waren echte verbeteringen. Het eerlijke resultaat is: "de tool is waarschijnlijk beter, en onze data heeft een gat dat we moeten dichten." Dat is in beide gevallen een nuttige conclusie.

Wat heeft een uitrol nodig?

Vooral data en eigenaarschap, niet software.

• Schone routings, procestijden, omsteltijden en kalenders. Plan eerst het opschonen van de data, en stel de projectplanning op basis van die inspanning, niet op basis van een dia van de leverancier.
• Een benoemde eigenaar voor de stamgegevens en voor de planningsregels.
• Begin met één gebied, vaak het gebied rond de bottleneck. Breid uit zodra de planners de output vertrouwen.
• Terugkoppeling vanaf de werkvloer: gestarte, afgeronde en uitgeschoten aantallen, en stilstanden. Zonder die gegevens loopt het schema binnen enkele dagen los van de werkelijkheid.
• Een wekelijkse review van de schema-naleving in de eerste maanden. Power BI of een andere rapportagetool kan gepland tegenover werkelijk laten zien.

Veelgemaakte fouten

• Kopen op functies, niet op geschiktheid. Een lange lijst met modules helpt niet als jouw probleem één bottleneck is.
• De ERP-check overslaan. Jouw ERP dekt misschien al een deel van de behoefte.
• Vertrouwen op demodata. Een demo op een voorbeeldfabriek laat zien hoe de tool zich gedraagt in een goed geval.
• Stamgegevens negeren. Verkeerde routingtijden leveren netjes ogende, maar foutieve schema's op.
• De planner buiten de lus houden. De planner moet kunnen ingrijpen en moet zien waarom.
• Onduidelijk eigenaarschap tussen APS en MES. Twee orderlijsten leiden tot twee waarheden.
• Een perfect plan verwachten. Plannen wijken altijd af. Bouw een tolerantie en een routine voor herplanning in.

Waar Polaris past

Als je behoefte een haalbaar plan met randvoorwaarden is, dan is iFAKT Polaris een optie om naar te kijken. iFAKT beschrijft Polaris als AI plus een digitale tweeling voor productie. De module Polaris Optimizer zet een kennisgraaf van product, proces en middelen om in een uitvoerbaar, geoptimaliseerd productieplan. Dat plan is gebaseerd op realtime ERP-data, beschikbaarheid van middelen en randvoorwaarden zoals shifts, zones, vaardigheden en capaciteiten. Het detecteert knelpunten, prioriteert orders, analyseert de impact van verstoringen en optimaliseert opnieuw. Of het past, hangt af van je proces en je data. Gebruik daarom eerst de replay-test hierboven op een afgebakend deel van je productie.

Gerelateerde onderwerpen om te verkennen

• Planning over meerdere locaties. Als fabrieken middelen of orders delen, bepaal dan of één team of elke locatie zijn eigen planning beheert.
• Veel varianten en productie op bestelling. Unieke routings en engineering-doorlooptijden bepalen wat een planningstool moet kunnen verwerken.
• Vraagsignalen. Hoe snel klantorders en wijzigingen de planning bereiken, bepaalt hoe vaak je opnieuw moet plannen.
• Planning en energie. Sommige fabrieken willen energiekosten als invoer voor de planning. Vraag of een tool dat ondersteunt voordat het ertoe doet.

Volgende stap

Het evalueren van geavanceerde planning- en schedulingsoftware wordt eenvoudiger zodra je een schriftelijke probleemomschrijving en een afgelopen week hebt om opnieuw af te spelen. Haal de order-, routing- en agendagegevens van één recente week op en gebruik die als testcase in je volgende gesprek met de leverancier.