Stel je voor dat een klant volgende maand 100 fietsen wil. De frames komen te laat aan. De wielen liggen in een ander magazijn. En je as een blaasjelijn zit al voor de komende twee weken volgeboekt. Dus, wat koop je in? Wat ga je bouwen? Wat moet je verplaatsen? En wanneer heb je elk onderdeel nodig? Yum, Milko Petas van M365FM. Dit kennisfragment gaat over Dynamics 365 Master Planning O. Het onderdeel van supply chain management dat achter de schermen al die vragen beantwoordt. Zie je bedrijf als een kantoorpand met een magazijn eraan vast. Bestellingen komen via één deur binnen. Voorraad ligt op schappen. Leveranciers brengen goederen naar het laadperron. Productie verandert onderdelen in eindproducten. Master Planning kijkt door het hele pand heen. In plaats van elk team met een eigen losse lijst te laten werken. Vandaag volgen we bij Gert Mann één fietsbestelling. Vanaf de klantvraag tot aan de bevoorradingsacties.

Dynamics 365 laat zien waarom bedrijven een plan nodig hebben. Geen spreadsheet. Voordat er verbonden planningstools bestonden, werkte bedrijven met losse informatiebronnen. Verkoop had klantbestellingen op één plek. Magazijn teams controleerden de voorraad in een ander systeem. Inkoop hield leveranciersdata bij in e-mails of spreadsheets. En productie hield eigen notices bij over wat de fabriek die week kon bouwen. Elke lijst leek op zichzelf correct. De problemen begonnen pas toen iemand probeerde één klant vraagt te beantwoorden. Oh, kunnen we honderd fietsen leveren op de datum die we beloofd hebben? Iola Tafts. Stel je voor dat er vandaag 30 afgewerkte fietsen in het magazijn staan. Dat klinkt als een goed begin, maar de bestelling heeft nog steeds 70 extra fietsen nodig. En voor die 70 fietsen heb je frames, wielen, kettingen, zadels, bouten, verpakkingsmateriaal, mensen om ze in elkaar te zetten en tijd op de juiste machines nodig.

Een simpele voorraadtelling vertelt je alleen wat er nu op de plank ligt. Het vertelt je niet of 70 extra frames kunnen arriveren voordat de productie ze nodig heeft. Het vertelt je niet of een open inkooporder de wielen al dekt. En het vertelt je niet of de fabriek genoeg tijd heeft om alles in elkaar te zetten voor de leverdatum. Dit is precies het punt waar planning meer wordt dan alleen tellen. Wanneer een klant honderd fietsen bestelt, kijkt het systeem naar de vraag van honderd. Het trekt de 30 fietsen af die al beschikbaar zijn. Dan brengt het in kaart wat er moet gebeuren voor de resterende 70. Het controleert de onderdelen onder de afgewerkte fiets. Het controleert de voorraad die al onderweg is. En het controleert de data die verbonden zijn aan elk werkstuk. Een ontbrekend onderdeel kan het hele antwoord veranderen. Je hebt misschien genoeg wielen en genoeg zadels. Maar als de frames twee weken levertijd hebben, helpt het niet om ze de dag voor de assemblage te kopen.

De order lijkt haalbaar op een spreadsheet totdat je elk onderdeel op een kalender plaatst. En die kalender verandert voortdurend. Een leverancier kan de leverdatum naar voren halen. Een andere verkooporder kan voorraad claimen waarvan je dacht dat deze vrij was. Een productieopdracht kan vertraging oplopen. Wanneer die details op verschillende plekken staan, zijn mensen constant aan het bellen, mailen, controleren en hun eigen versie van het plan aan het bijwerken. Dynamics 365 Masterplanning brengt de huidige vraag en het huidige aanbod samen in één planningsoverzicht. Het leest klantorders, voorhanden voorraad, inkomende leveringen en productieinformatie samen. Vervolgens berekent het waar het aanbod de vraag dekt en waar een tekort blijft. In plaats van elk team handmatig de puntjes te laten verbinden, creëert het systeem voorgestelde acties op basis van de beschikbare informatie. Dit betekent niet dat het systeem het bedrijf zelfstandig runt.

Een planner controleert nog steeds de suggesties, stelt vragen en beslist wat er moet gebeuren. Maar de planner begint met een verbonden beeld in plaats van een stapel losse lijsten. Zie een spreadsheet als een foto. Het legt de voorraad vast op één moment en dat kan nuttig zijn. Masterplanning lijkt meer op een vooruitziende planning omdat het hoeveelheden koppelt aan data, inkomend aanbod en toekomstige vraag. De volgende stap is het scheiden van de verschillende soorten vraag die het planningsproces kan lezen. Er is niet slechts één manier om te plannen. De planningsmodus die je gebruikt hangt af van de vraag die je bedrijf beantwoord moet hebben. Een bedrijf dat deze week klantorders afhandelt, heeft een heel ander overzicht nodig dan een bedrijf dat materialen voorbereidt voor het volgende seizoen. De eerste modus is masterplanning. Dit is je dagelijkse planning en het berekent een nettobehoefte.

Dit betekent simpelweg dat het systeem kijkt naar wat je nodig hebt en het aanbod aftrekt dat je al hebt of verwacht te ontvangen. Het leest echte bedrijfsactiviteiten zoals klantorders, inkooporders naar leveranciers, productieorders in de fabriek en voorraad in het magazijn. Stel je een klantorder voor van 100 eenheden van een product. Je magazijn bevat 30 eenheden die de planning voor die order kan gebruiken. Het systeem stelt niet voor om alle 100 opnieuw te kopen of te bouwen, omdat het die 30 als aanbod ziet. Dus berekent het een resterende behoefte van 70 eenheden. Die resterende 70 is de nettobehoefte. Een echtplan kan meer omvatten dan alleen voorraad op een plank. Misschien worden er nog 20 eenheden verwacht van een leverancier voor de door de klant gevraagde datum. In dat geval houdt het systeem ook rekening met die 20 stuks, waardoor het gat nog kleiner wordt. Maar data bepalen het antwoord.

Als die 20 eenheden arriveren na de verwachte leverdatum van de klant, helpen ze uiteindelijk niet veel. Je ontvangt ze fysiek wel, maar ze komen te laat voor deze specifieke behoefte. Masterplanning kijkt naar hoeveelheid en timing in samenhang. Oh, een simpel totaalcijfer voor de voorraad kan je het verkeerde antwoord geven. Voor veel bedrijven is dit het plan dat ze het vaakst uitvoeren. Microsoft noemt masterplanning een korte termijnproces, meestal variërend van één week tot zes maanden. Het exacte bereik hangt af van de levertijd van voorraad of de duur van het productieproces. Een bedrijf dat eenvoudige lokale artikelen inkoopt, plant misschien maar enkele weken vooruit. Maar een fabrikant met onderdelen die maanden duren, moet verder vooruitkijken, vaak tot de langste totale doorlooptijd van zijn producten. Anders ontdekt de planning een tekort wanneer het te laat is om dit nog te voorkomen.

De tweede modus is prognoseplanning. In plaats van te beginnen met bevestigde verkooporders, begint prognoseplanning met de verwachte vraag. Misschien verwacht het verkoopteam hogere fietsverkopen in de zomer, of verwacht een retailer een grote promotie die later in het jaarvraag creëert. Dit zijn prognoses gebaseerd op wat het team verwacht, niet op bevestigde orders. Ze zijn nuttig omdat wachten op elke klantorder te weinig tijd kan overlaten voor inkoop van grondstoffen, planning van fabriekswerk of voorbereiding van voldoende capaciteit. Items met een lange levertijd vereisen eerder beslissingen, zelfs als de definitieve klantorder nog niet is binnengekomen. Prognoseplanning berekent de bruto behoefte. Dat betekent dat het begint bij het verwachte vragenvolume. Als een prognose 500 fietsen in juli verwacht, ziet de planning eerst de volledige behoefte van 500 eenheden en werkt vanuit die verwachte noodzaak.

Zie het als vooruitkijken naar de werklast die op het bedrijf afkomt. Je kunt dan materialen en capaciteit plannen rond dat verwachte volume. Misschien moet je vroegtijdig met leveranciers praten, magazijnruimte voorbereiden of controleren of de productie de verwachte werklast aan kan. Prognoses zijn geen garanties, ze kunnen veranderen en de werkelijke verkoop komt mogelijk niet overeen. Toch geven ze je een langere horizon dan een plan dat alleen is gebaseerd op reeds geplaatste orders. Dan is er nog de intercompany masterplanning. Dit komt aan bod wanneer de ene juridische entiteit voorraad nodig heeft van de andere. Bijvoorbeeld, één bedrijf in je groep produceert een item, terwijl een ander bedrijf het verkoopt aan klanten in een ander land. Het verkopende bedrijf ziet de klantvraag. Het producerende bedrijf moet de aanbodbehoeften zien die door die vraag ontstaat. Intercompany masterplanning verbindt die behoeften over bedrijfsgrenzen heen, inclusief geplande vraag en aanbod die nog geen definitieve orders zijn geworden.

Bedrijven plannen dus niet alsof ze er alleen voor staan. Het verkoopbedrijf kan de bevoorrading vanuit het productiebedrijf plannen, terwijl het productiebedrijf kan zien welke materialen en capaciteit nodig zijn om aan die vraag te voldoen. De koppeling brengt het planningssignaal over van de ene rechtspersoon naar de andere. Elke modus begint met de vraag, maar vraag is slechts het eerste signaal, want één eindproduct kan een keten van behoefte voor vele onderliggende onderdelen creëren. Van één order naar een toeleveringsketen laten we bij de fiets blijven, want hier begint de hoofdplanning aan zijn eigenlijke werk. Stel je voor dat een klant een order plaatst voor 70 fietsen en vraagt om levering op een specifieke datum. Die datum is niet zomaar een notitie voor het verkoopteam. Het wordt het uitgangspunt voor de planning, waarbij wordt teruggewerkt vanuit de vraag wat er moet gebeuren voordat die fietsen het magazijn kunnen verlaten.

De voltooide fiets is slechts de eerste laag. Dynamics 365 controleert de stuklijst, vaak de bom, genoemd. Zie de stuklijst als het recept voor één fiets. Het vermeldt het frame, de wielen, de ketting, het zadel, het stuur, de remmen, bouten en elk ander onderdeel dat nodig is om hen te bouwen. Als de order om 70 fietsen vraagt, breidt de planning die order uit naar de onderdelen die nodig zijn voor alle 70 fietsen. Dat kan al snel een lange lijst worden. Je hebt wellicht 70 frames, 140 wielen, 70 kettingen, 70 zadels en honderden kleine boutjes nodig. Een planner hoeft niet elk onderdeel met de hand te tellen. De stuklijst geeft Dynamics 365 de structuur zodat het systeem de vraag kan herleiden van de voltooide fiets tot elk afzonderlijk onderdeel. Maar met alleen onderdelen kun je nog geen fietsen produceren. Voor productie is ook een route nodig. Een route beschrijft de werkstappen die nodig zijn om het item te bouwen, zoals het assembleren van het frame, het monteren van de wielen, het controleren van de remmen en het verpakken van de voltooide fiets.

Voor elke stap kan een hulbron nodig zijn. Die hulbron kan een assemblage lijn, een werkbank, een spuitcabine, een machine of een groep mensen met de juiste vaardigheden zijn. De planning gebruikt deze informatie om werk op het juiste moment in te plannen. In plaats van productie als iets te zien dat onmiddellijk gebeurt, beginnen data hier terug in de tijd te lopen. Als de klant de fietsen op vrijdag nodig heeft, moet de productieorder wellicht op donderdag klaar zijn, zodat het magazijn ze kan inpakken en verzenden. De assemblage moet misschien al op dinsdag beginnen. De frames en wielen moeten dan mogelijk op maandag arriveren. Als een leverancier 10 dagen nodig heeft om wielen te leveren, moet de inkooporder jouw bedrijf nog eerder verlaten. De datum van de klant creëert een keten van data. Dynamics 365 werkt achterwaarts door die keten, rekening houdend met doorlooptijden. Een doorlooptijd is simpelweg de tijd die iets nodig heeft, of het nu gaat om een leverancier die een onderdeel levert, een magazijn dat goederen verplaatst of een fabriek die een taak afrondt.

Een te laat onderdeel kan alles vertragen. Stel dat het systeem 70 frames op voorraad vindt. Het ziet ook een openstaande inkooporder voor 140 wielen met een levering geplant voor aanvang van de assemblage. Dat aanbod dekt de behoefte aan wielen, terwijl de frames al voor hun deel zorgen. Daarna controleert het de kettingen. Misschien zijn er slechts 40 kettingen voor handen en zorgt geen enkele inkooporder voor de resterende 30. De planning ziet een tekort en doet een voorstel om dit op te vangen. Dezelfde controle wordt uitgevoerd voor de voltooide fietsen, de onderdelen daaronder en al het werk daartussenin. Er bestaat al enig aanbod. Beschikbare voorraad kan in een behoefte voorzien. Een openstaande inkooporder kan hierin voorzien als de goederen op tijd arriveren. Een openstaande productieorder kan hierin voorzien als de fabriek op tijd klaar is. Wanneer geen van deze bronnen aan de vraag voldoet, maakt het plan een geplande order aan.

Een geplande inkooporder stelt voor om iets bij een leverancier te kopen. Een geplande productieorder stelt voor om iets binnen uw bedrijf te bouwen. Een geplande transferorder stelt voor om voorraad van de ene locatie of het ene magazijn naar het andere te verplaatsen. Dit zijn suggesties, geen verplichtingen. Dynamics 365 stuurt niet zomaar in stilte een order naar een leverancier of start het werk op de werkvloer. Het geeft de planner een voorgestelde hoeveelheid en datum op basis van de beschikbare gegevens. Een persoon controleert nog steeds of de leverancier correct is, of de datum haalbaar is en of het bedrijf de actie moet goedkeuren. Stel u een klein probleem voor met onze fietsorder. Alles lijkt klaar, behalve één wiel. De geplande aanvoer dekt frames, kettingen, zadels en bijna elk wiel. Maar één wiel arriveert een dag nadat de assemblage het nodig heeft. Zonder dat wiel kan één fiets niet worden voltooid.

Hoewel het magazijn vol onderdelen lijkt te liggen, herleidt de hoofdplanning het tekort naar de bron. De planner kan zien dat het tekort niet voortkomt uit de klantenorder zelf. O, het komt door de datum van de leverancier op de inkooporder voor de wielen. Dat geeft de planner iets specifieks om op te acteren. Vraag om een eerdere levering, zoek een andere bron of wijzig de productiedatum. Het plan kan aanbod voorstellen. Maar de volgende vraag is net zo nuttig. Waarom heeft Dynamics 365 dit aanbod aan die vraag gekoppeld? Het lezen van netto behoeften, het planningsgesprek. Planners gebruiken daarom de pagina met netto behoeften om die verbinding te onderzoeken. Deze pagina brengt het volledige planningsgesprek voor één artikel op één plek samen. Het toont elke behoefte aan het artikel en elke leveringsbron die dit kan dekken, met datums direct naast elke regel. Neem het fietswiel als voorbeeld.

Bovenaan kiest u de locatie of het magazijn waarvoor dat wiel relevant is. Daaronder toont Dynamics 365 alle gerelateerde transacties, zoals verkopen, inkopen, voorraad en productie, allemaal in één lijst. De vraag wordt weergegeven als een negatief getal ten opzichte van uw beschikbare voorraad. Die vraag kan uit vele hoeken komen. Een verkooporder heeft wielen nodig omdat een klant fietsen heeft besteld. Een prognose creëert een verwachte toekomstige vraag. Een productieorder heeft wielen nodig voor het productieplan. En een overboekingsorder creëert vraag wanneer een ander magazijn om voorraad vraagt. Elke regel beantwoordt een eenvoudige vraag. Wie heeft dit artikel nodig? Hoeveel hebben ze er nodig? En op welke datum? Dat klinkt simpel, maar het voorkomt een veelgemaakte fout. Mensen zien vaak een totaalhoeveelheid en gaan ervan uit dat deze bij één klant of taak hoort, terwijl hetzelfde artikel meerdere orders op verschillende data kan ondersteunen.

Aan de aanbodzijde heeft u de voorhanden voorraad, of wat er al op voorraad is. Daarnaast inkooporders van leveranciers, productieorders die uw bedrijf plant, transfers tussen magazijnen en geplande orders die het systeem voorstelt maar die nog niet zijn aangemaakt. De pagina sorteert alles op datum. Terwijl u door de lijst bladert, ziet u de beschikbare hoeveelheid veranderen. De voorraad kan er begin van de maand goed uitzien, dan dalen wanneer een productieorder onderdelen gebruikt, en weer stijgen als een leverancier levert. Timing verandert het resultaat. Stel dat er op maandag 100 wielen in een magazijn liggen, maar een productieorder op dinsdag 80 wielen nodig heeft en er op woensdag een klantbehoefte van 30 bij komt. De totale vraag overstijgt de voorraad, ook al komt er op vrijdag een inkooporder van 50 wielen binnen. De levering van vrijdag lost het tekort van woensdag niet op.

Dat dag-voor-dag-overzicht verklaart waarom het systeem zijn suggesties doet. Dynamics 365 vraagt niet zomaar willekeurig om meer wielen. Het ziet precies wanneer het beschikbare aanbod onder de te dekken vraag zakt. Nu stelt u wellicht een specifiekere vraag. Welke leveringsregel dekt welke vraagsregel? Die verbinding wordt pegging genoemd. Pegging is de eigen planningskoppeling van Dynamics 365 tussen vraag en aanbod. Het verbindt een behoefte, zoals een productieorder voor fietsen, met de bron die dit moet dekken, zoals een inkooporder voor wielen of een geplande inkooporder. Het systeem bouwt deze koppeling tijdens de planningsberekening op. Als de vraag verandert, kan de planning de verbinding opnieuw berekenen. Misschien verplaatst een klant zijn leverdatum of verschuift een inkooporder. Pegging kan dan naar een andere leveringsbron wijzen of een nieuwe geplande order aanmaken waar het tekort ontstaat.

Het helpt je de gehele keten te traceren. Begin bij een verkooporder, bekijk de gekoppelde productieorder, volg deze naar de benodigde onderdelen en vind de inkooporder die ze dekt. Soms heb je meer controle nodig. Dat is waar markeren van pas komt. Markeren is een handmatige verbinding tussen een aanboventransactie en een vraagtransactie. Het vertelt het systeem dat dit aanbod aan die vraag moet voldoen, in plaats van de planning het ergens anders vrij te laten matchen. Zie het als het plaatsen van een label op twee gerelateerde records. Je kunt een specifieke inkomende inkooporder voor wielen markeren voor een bepaalde productieorder omdat die wielen voor dat werk zijn gekocht. De planning respecteert die relatie steviger dan de normale pegging-koppeling. Toch is gemarkeerd aanbod niet de sterkste verbinding die beschikbaar is. Reservering is sterker. Wanneer je voorraad of inkomend aanbod reserveert voor een specifieke vraag, creëer je een harde link.

Die hoeveelheid wordt apart gezet voor de gekozen verkooporder, productieorder of andere vraag. En de hoofdplanning behandelt de reservering als prioriteit boven normale, pegging en markering. Stel je tien wielen op voorraad voor, maar die wielen zijn gereserveerd voor een dringende reparatieorder. Een latere klantenorder heeft wellicht ook wielen nodig, maar de planning kan die tien gereserveerde wielen niet als vrij beschikbaar beschouwen. Het moet ander aanbod vinden of meer aanbod voorstellen, omdat de reservering ze al elders toewijst. Dus, pegging, markeren en reserveren bieden je drie niveaus van verbinding. Pegging is de automatische match van het systeem. Markeren is een handmatige, meer vaste koppeling. Reserveren vergrendeld aanbod aan een specifieke behoefte. De sterkste van de drie. Zodra je die koppelingen kunt lezen, lijken geplande orders niet langer op onverklaarbare instructies.

De volgende vraag is hoe vaak dit planningsoverzicht verandert en hoe snel Dynamics 365 dit kan berekenen. Statisch, dynamisch en planningsoptimalisatie. De pagina nettobehoefte toont een planningsresultaat, maar niet elk plan werkt op dezelfde manier bij. Een statisch plan verandert alleen wanneer iemand de hoofdplanning uitvoert. Dat geeft planners een stabiel beeld dat ze gedurende de dag kunnen bekijken zonder dat elke nieuwe transactie de cijfers eronder verandert. Stel je voor dat er ochtends om 11 uur een grote verkooporder binnenkomt. Als het statische plan s'nachts is gedraaid, verschijnt die nieuwe order pas in de suggesties bij de volgende planningsrun. Het plan toont nog steeds het laatst berekende resultaat, wat nuttig kan zijn wanneer een team 1 afgesproken beeld voor de dag nodig heeft. Maar die stabiliteit heeft een prijs. Nieuwe vraag kan een tijdje buiten het statische plan vallen, zeker als je bedrijf de planning slechts één keer per nacht of per week draait.

Een planner weet wellicht dat er een klantenorder bestaat, maar het statische plan heeft de aanbodreactie nog niet herberekend. Dat is waar een dynamisch plan helpt. Een dynamisch plan toont de huidige vraag zoals die zich voordoet. Planners kunnen het effect van nieuwe verkooporders en andere vragen zien zonder te wachten op de volgende volledige hoofdplanning. Het is een blik op de kortere termijn. Dynamische plannen slaan prognoses over en focussen op wat er nu gebeurt. Stel dat een klant vanmiddag onverwacht een order plaatst voor 200 fietsen. Voordat iemand een leverdatum belooft, kan de planner het dynamische plan openen en het effect controleren. Veroorzaakt de nieuwe order een tekort? Schuift het een bestaande behoefte door naar een latere datum? Activeert het een nieuwe voorgestelde inkoop- of productieactie? Dit geeft het team een praktisch, wat als overzicht. Je wijzigt het statische plan niet zomaar om één nieuwe order te onderzoeken.

Je controleert eerst de waarschijnlijke impact en beslist dan of de order nu aandacht nodig heeft of kan wachten op de volgende geplande run. Statische en dynamische plannen beantwoorden gerelateerde maar verschillende vragen. Het statische plan vraagt, wat zei onze laatste officiële planningsberekening dat we moesten doen. Het dynamische plan vraagt hoe de huidige vraag er op dit moment uitziet. Achter beide plannen zit de plannings engine voor Dynamics 365 cloudomgevingen. Planning optimalisatie is de moderne engine die Microsoft gebruikt voor hoofdplanning. Deze berekent de verrijste buiten de hoofdbedrijfstoepassing, wat de belasting op het systeem voor dagelijks werk vermindert. Oudere plannings runs konden lang duren. Rapporten van klanten en partners beschrijven planningswerk dat voorheen uren duurde en nu in minuten wordt voltooid met planning optimalisatie. Snellere runs betekenen dat teams het plan vaker kunnen verversen in plaats van te wachten tot het eind van de dag om te zien of de vraag is veranderd.

Maar een sneller antwoord kan nog steeds een verkeerd antwoord zijn. Planning optimalisatie kan snel een enorme hoeveelheid gekoppelde gegevens berekenen. Toch werkt het alleen op basis van de gegevens die jouw bedrijf invoert. Als de levertijd van een leverancier fout is, kan de voorgestelde orderdatum ook fout zijn. Als het systeem denkt dat er 500 wielen op voorraad zijn terwijl dat niet zo is, kan het een inkoopvoorstel overslaan dat je eigenlijk nodig hebt. En als een onderdeel ontbreekt in de stuklijst, kan de planning geen vraag creëren voor dat ontbrekende onderdeel. De berekening is misschien in minuten klaar, maar de fabriek staat nog steeds stil als dat onderdeel er niet is. Er is ook een verandering in hoe planningen worden uitgevoerd. Met planning optimalisatie zijn plannen regeneratief. Dat betekent dat elke run alle verrijsten opnieuw bekijkt, in plaats van de oudere, netto wijziging, methode die alleen items met nieuwe verrijsten sinds de laatste run bijwerkte.

Zie het als het telkens opnieuw berekenen van het volledige planningsbeeld. Dat neemt de onzekerheid weg of een eerdere wijziging aan de berekening is ontsnapt, terwijl de snellere engine een volledige herberekening praktischer maakt voor veel bedrijven. Snelheid helpt, maar schone data bepaalt of het plan vertrouwen verdient. Zodra het plan suggesties genereert, is de volgende stap bepalen welke actie prioriteit heeft. Maar wat masterplanning doet en wat het nu doet. Dus hier is de eenvoudigste definitie. Masterplanning gebruikt alle data in Dynamics 365 en suggereert wat te kopen, produceren of verplaatsen, inclusief datums en hoeveelheden. Een planner beoordeelt die geplande orders voordat er actie wordt ondernomen. Ze controleren de leverancier, de leverdatum, de hoeveelheid en of de fabriek het werk aan kan. Na bevestiging wordt die suggestie omgezet in een echte inkooporder, productieorder of transferorder.

Maar masterplanning kan de toekomst niet voorspellen. Prognoses zijn slecht schattingen en echte klantorders kunnen van de ene op de andere dag veranderen. En het vervangt absoluut geen menselijke planners. Mensen beheren nog steeds het leveranciersrisico, klantafspraken en uitzonderingen. Het systeem kan simpelweg niet oordelen. Alleen voorraad is ook niet genoeg. Die voorraad kan te laat komen, in het verkeerde magazijn liggen of al gereserveerd zijn voor een andere order. Voor goede resultaten begint u met schone data, correcte artikelgegevens, nauwkeurige levertijden, juiste stuklijsten, actuele voorraad en realistische vraag. Voor onze fietsorder dekt de huidige voorraad een deel van de behoefte. De planning suggereert aanvoer voor de rest en de planner bevestigt de actie. Dat brengt ons terug bij de vraag waar elk team antwoord op moet hebben. Wat moet er nu gebeuren? Conclusie 1 verbonden plan.

Masterplanning combineert vraag, voorraadniveaus, leverdata van leveranciers, productieschema's en capaciteit... ...en zet dit om in acties die uw team kan beoordelen. Geplande orders starten nu het menselijke besluitvormingsproces. Ze voltooien het niet. Daarom blijven planners essentieel. Abonneer u op uw favoriete podcastplatform en deel dit kennisfragment met iemand die Dynamics 365 Supply Chain Management leert.