WEBVTT 00:00:00.000 --> 00:00:02.260 Stel je voor dat een klant volgende maand 100 fietsen wil. 00:00:02.420 --> 00:00:03.640 De frames komen te laat aan. 00:00:03.820 --> 00:00:05.260 De wielen liggen in een ander magazijn. 00:00:05.420 --> 00:00:07.700 En je as een blaasjelijn zit al voor de komende twee weken volgeboekt. 00:00:07.860 --> 00:00:08.740 Dus, wat koop je in? 00:00:08.860 --> 00:00:09.620 Wat ga je bouwen? 00:00:09.780 --> 00:00:10.680 Wat moet je verplaatsen? 00:00:10.780 --> 00:00:12.300 En wanneer heb je elk onderdeel nodig? 00:00:12.500 --> 00:00:15.540 Yum, Milko Petas van M365FM. 00:00:15.720 --> 00:00:19.500 Dit kennisfragment gaat over Dynamics 365 Master Planning O. 00:00:19.660 --> 00:00:23.900 Het onderdeel van supply chain management dat achter de schermen al die vragen beantwoordt. 00:00:24.040 --> 00:00:26.860 Zie je bedrijf als een kantoorpand met een magazijn eraan vast. 00:00:27.200 --> 00:00:28.740 Bestellingen komen via één deur binnen. 00:00:28.740 --> 00:00:30.100 Voorraad ligt op schappen. 00:00:30.440 --> 00:00:32.300 Leveranciers brengen goederen naar het laadperron. 00:00:32.480 --> 00:00:34.740 Productie verandert onderdelen in eindproducten. 00:00:35.080 --> 00:00:36.980 Master Planning kijkt door het hele pand heen. 00:00:37.120 --> 00:00:40.020 In plaats van elk team met een eigen losse lijst te laten werken. 00:00:40.460 --> 00:00:42.940 Vandaag volgen we bij Gert Mann één fietsbestelling. 00:00:43.240 --> 00:00:45.900 Vanaf de klantvraag tot aan de bevoorradingsacties. 00:00:46.180 --> 00:00:50.160 Dynamics 365 laat zien waarom bedrijven een plan nodig hebben. 00:00:50.340 --> 00:00:51.000 Geen spreadsheet. 00:00:51.380 --> 00:00:55.520 Voordat er verbonden planningstools bestonden, werkte bedrijven met losse informatiebronnen. 00:00:55.760 --> 00:00:57.740 Verkoop had klantbestellingen op één plek. 00:00:57.740 --> 00:01:00.380 Magazijn teams controleerden de voorraad in een ander systeem. 00:01:00.500 --> 00:01:02.980 Inkoop hield leveranciersdata bij in e-mails of spreadsheets. 00:01:03.140 --> 00:01:06.080 En productie hield eigen notices bij over wat de fabriek die week kon bouwen. 00:01:06.220 --> 00:01:07.860 Elke lijst leek op zichzelf correct. 00:01:08.060 --> 00:01:11.000 De problemen begonnen pas toen iemand probeerde één klant vraagt te beantwoorden. 00:01:11.140 --> 00:01:13.720 Oh, kunnen we honderd fietsen leveren op de datum die we beloofd hebben? 00:01:13.720 --> 00:01:14.720 Iola Tafts. 00:01:14.920 --> 00:01:17.740 Stel je voor dat er vandaag 30 afgewerkte fietsen in het magazijn staan. 00:01:17.980 --> 00:01:21.500 Dat klinkt als een goed begin, maar de bestelling heeft nog steeds 70 extra fietsen nodig. 00:01:21.700 --> 00:01:26.400 En voor die 70 fietsen heb je frames, wielen, kettingen, zadels, bouten, verpakkingsmateriaal, 00:01:26.600 --> 00:01:29.200 mensen om ze in elkaar te zetten en tijd op de juiste machines nodig. 00:01:29.400 --> 00:01:32.540 Een simpele voorraadtelling vertelt je alleen wat er nu op de plank ligt. 00:01:32.800 --> 00:01:37.220 Het vertelt je niet of 70 extra frames kunnen arriveren voordat de productie ze nodig heeft. 00:01:37.440 --> 00:01:40.480 Het vertelt je niet of een open inkooporder de wielen al dekt. 00:01:40.480 --> 00:01:45.320 En het vertelt je niet of de fabriek genoeg tijd heeft om alles in elkaar te zetten voor de leverdatum. 00:01:46.560 --> 00:01:49.500 Dit is precies het punt waar planning meer wordt dan alleen tellen. 00:01:50.300 --> 00:01:54.060 Wanneer een klant honderd fietsen bestelt, kijkt het systeem naar de vraag van honderd. 00:01:54.200 --> 00:01:56.500 Het trekt de 30 fietsen af die al beschikbaar zijn. 00:01:56.720 --> 00:01:59.300 Dan brengt het in kaart wat er moet gebeuren voor de resterende 70. 00:01:59.540 --> 00:02:01.820 Het controleert de onderdelen onder de afgewerkte fiets. 00:02:02.000 --> 00:02:03.880 Het controleert de voorraad die al onderweg is. 00:02:04.040 --> 00:02:06.440 En het controleert de data die verbonden zijn aan elk werkstuk. 00:02:06.580 --> 00:02:08.820 Een ontbrekend onderdeel kan het hele antwoord veranderen. 00:02:08.820 --> 00:02:10.940 Je hebt misschien genoeg wielen en genoeg zadels. 00:02:11.160 --> 00:02:15.800 Maar als de frames twee weken levertijd hebben, helpt het niet om ze de dag voor de assemblage te kopen. 00:02:16.020 --> 00:02:20.100 De order lijkt haalbaar op een spreadsheet totdat je elk onderdeel op een kalender plaatst. 00:02:20.240 --> 00:02:21.940 En die kalender verandert voortdurend. 00:02:22.100 --> 00:02:24.280 Een leverancier kan de leverdatum naar voren halen. 00:02:24.420 --> 00:02:27.180 Een andere verkooporder kan voorraad claimen waarvan je dacht dat deze vrij was. 00:02:27.340 --> 00:02:29.220 Een productieopdracht kan vertraging oplopen. 00:02:29.220 --> 00:02:35.640 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. 00:02:35.860 --> 00:02:41.640 Dynamics 365 Masterplanning brengt de huidige vraag en het huidige aanbod samen in één planningsoverzicht. 00:02:41.820 --> 00:02:46.240 Het leest klantorders, voorhanden voorraad, inkomende leveringen en productieinformatie samen. 00:02:46.440 --> 00:02:49.620 Vervolgens berekent het waar het aanbod de vraag dekt en waar een tekort blijft. 00:02:49.760 --> 00:02:55.700 In plaats van elk team handmatig de puntjes te laten verbinden, creëert het systeem voorgestelde acties op basis van de beschikbare informatie. 00:02:55.700 --> 00:02:58.780 Dit betekent niet dat het systeem het bedrijf zelfstandig runt. 00:02:58.960 --> 00:03:03.300 Een planner controleert nog steeds de suggesties, stelt vragen en beslist wat er moet gebeuren. 00:03:03.480 --> 00:03:07.060 Maar de planner begint met een verbonden beeld in plaats van een stapel losse lijsten. 00:03:07.320 --> 00:03:12.140 Zie een spreadsheet als een foto. Het legt de voorraad vast op één moment en dat kan nuttig zijn. 00:03:12.560 --> 00:03:18.560 Masterplanning lijkt meer op een vooruitziende planning omdat het hoeveelheden koppelt aan data, inkomend aanbod en toekomstige vraag. 00:03:18.740 --> 00:03:23.300 De volgende stap is het scheiden van de verschillende soorten vraag die het planningsproces kan lezen. 00:03:23.300 --> 00:03:31.680 Er is niet slechts één manier om te plannen. 00:03:31.860 --> 00:03:35.740 De planningsmodus die je gebruikt hangt af van de vraag die je bedrijf beantwoord moet hebben. 00:03:35.940 --> 00:03:42.780 Een bedrijf dat deze week klantorders afhandelt, heeft een heel ander overzicht nodig dan een bedrijf dat materialen voorbereidt voor het volgende seizoen. 00:03:42.960 --> 00:03:44.800 De eerste modus is masterplanning. 00:03:44.800 --> 00:03:47.980 Dit is je dagelijkse planning en het berekent een nettobehoefte. 00:03:48.120 --> 00:03:53.780 Dit betekent simpelweg dat het systeem kijkt naar wat je nodig hebt en het aanbod aftrekt dat je al hebt of verwacht te ontvangen. 00:03:53.980 --> 00:04:01.920 Het leest echte bedrijfsactiviteiten zoals klantorders, inkooporders naar leveranciers, productieorders in de fabriek en voorraad in het magazijn. 00:04:02.260 --> 00:04:05.060 Stel je een klantorder voor van 100 eenheden van een product. 00:04:05.280 --> 00:04:08.580 Je magazijn bevat 30 eenheden die de planning voor die order kan gebruiken. 00:04:08.580 --> 00:04:13.240 Het systeem stelt niet voor om alle 100 opnieuw te kopen of te bouwen, omdat het die 30 als aanbod ziet. 00:04:13.440 --> 00:04:16.000 Dus berekent het een resterende behoefte van 70 eenheden. 00:04:16.180 --> 00:04:18.300 Die resterende 70 is de nettobehoefte. 00:04:18.440 --> 00:04:21.060 Een echtplan kan meer omvatten dan alleen voorraad op een plank. 00:04:21.320 --> 00:04:26.180 Misschien worden er nog 20 eenheden verwacht van een leverancier voor de door de klant gevraagde datum. 00:04:27.160 --> 00:04:31.680 In dat geval houdt het systeem ook rekening met die 20 stuks, waardoor het gat nog kleiner wordt. 00:04:31.860 --> 00:04:33.360 Maar data bepalen het antwoord. 00:04:33.540 --> 00:04:37.920 Als die 20 eenheden arriveren na de verwachte leverdatum van de klant, helpen ze uiteindelijk niet veel. 00:04:37.920 --> 00:04:41.400 Je ontvangt ze fysiek wel, maar ze komen te laat voor deze specifieke behoefte. 00:04:41.760 --> 00:04:44.180 Masterplanning kijkt naar hoeveelheid en timing in samenhang. 00:04:44.380 --> 00:04:47.800 Oh, een simpel totaalcijfer voor de voorraad kan je het verkeerde antwoord geven. 00:04:48.020 --> 00:04:50.580 Voor veel bedrijven is dit het plan dat ze het vaakst uitvoeren. 00:04:50.880 --> 00:04:55.400 Microsoft noemt masterplanning een korte termijnproces, meestal variërend van één week tot zes maanden. 00:04:55.620 --> 00:04:59.780 Het exacte bereik hangt af van de levertijd van voorraad of de duur van het productieproces. 00:04:59.960 --> 00:05:04.160 Een bedrijf dat eenvoudige lokale artikelen inkoopt, plant misschien maar enkele weken vooruit. 00:05:04.160 --> 00:05:10.940 Maar een fabrikant met onderdelen die maanden duren, moet verder vooruitkijken, vaak tot de langste totale doorlooptijd van zijn producten. 00:05:11.120 --> 00:05:14.800 Anders ontdekt de planning een tekort wanneer het te laat is om dit nog te voorkomen. 00:05:15.040 --> 00:05:17.100 De tweede modus is prognoseplanning. 00:05:17.300 --> 00:05:21.900 In plaats van te beginnen met bevestigde verkooporders, begint prognoseplanning met de verwachte vraag. 00:05:22.140 --> 00:05:28.820 Misschien verwacht het verkoopteam hogere fietsverkopen in de zomer, of verwacht een retailer een grote promotie die later in het jaarvraag creëert. 00:05:29.040 --> 00:05:32.580 Dit zijn prognoses gebaseerd op wat het team verwacht, niet op bevestigde orders. 00:05:32.580 --> 00:05:39.980 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. 00:05:40.180 --> 00:05:45.100 Items met een lange levertijd vereisen eerder beslissingen, zelfs als de definitieve klantorder nog niet is binnengekomen. 00:05:45.660 --> 00:05:47.540 Prognoseplanning berekent de bruto behoefte. 00:05:47.740 --> 00:05:50.520 Dat betekent dat het begint bij het verwachte vragenvolume. 00:05:50.760 --> 00:05:58.360 Als een prognose 500 fietsen in juli verwacht, ziet de planning eerst de volledige behoefte van 500 eenheden en werkt vanuit die verwachte noodzaak. 00:05:58.480 --> 00:06:01.440 Zie het als vooruitkijken naar de werklast die op het bedrijf afkomt. 00:06:01.440 --> 00:06:04.560 Je kunt dan materialen en capaciteit plannen rond dat verwachte volume. 00:06:04.800 --> 00:06:10.540 Misschien moet je vroegtijdig met leveranciers praten, magazijnruimte voorbereiden of controleren of de productie de verwachte werklast aan kan. 00:06:10.820 --> 00:06:15.160 Prognoses zijn geen garanties, ze kunnen veranderen en de werkelijke verkoop komt mogelijk niet overeen. 00:06:15.280 --> 00:06:19.300 Toch geven ze je een langere horizon dan een plan dat alleen is gebaseerd op reeds geplaatste orders. 00:06:19.580 --> 00:06:21.560 Dan is er nog de intercompany masterplanning. 00:06:21.780 --> 00:06:25.280 Dit komt aan bod wanneer de ene juridische entiteit voorraad nodig heeft van de andere. 00:06:25.560 --> 00:06:30.900 Bijvoorbeeld, één bedrijf in je groep produceert een item, terwijl een ander bedrijf het verkoopt aan klanten in een ander land. 00:06:30.900 --> 00:06:33.220 Het verkopende bedrijf ziet de klantvraag. 00:06:33.340 --> 00:06:37.180 Het producerende bedrijf moet de aanbodbehoeften zien die door die vraag ontstaat. 00:06:37.540 --> 00:06:40.900 Intercompany masterplanning verbindt die behoeften over bedrijfsgrenzen heen, 00:06:41.100 --> 00:06:44.720 inclusief geplande vraag en aanbod die nog geen definitieve orders zijn geworden. 00:06:45.060 --> 00:06:47.620 Bedrijven plannen dus niet alsof ze er alleen voor staan. 00:06:47.880 --> 00:06:51.060 Het verkoopbedrijf kan de bevoorrading vanuit het productiebedrijf plannen, 00:06:51.340 --> 00:06:55.920 terwijl het productiebedrijf kan zien welke materialen en capaciteit nodig zijn om aan die vraag te voldoen. 00:06:56.080 --> 00:06:59.480 De koppeling brengt het planningssignaal over van de ene rechtspersoon naar de andere. 00:06:59.480 --> 00:07:03.360 Elke modus begint met de vraag, maar vraag is slechts het eerste signaal, 00:07:03.500 --> 00:07:07.560 want één eindproduct kan een keten van behoefte voor vele onderliggende onderdelen creëren. 00:07:07.900 --> 00:07:11.300 Van één order naar een toeleveringsketen laten we bij de fiets blijven, 00:07:11.560 --> 00:07:13.920 want hier begint de hoofdplanning aan zijn eigenlijke werk. 00:07:14.120 --> 00:07:19.140 Stel je voor dat een klant een order plaatst voor 70 fietsen en vraagt om levering op een specifieke datum. 00:07:19.360 --> 00:07:21.480 Die datum is niet zomaar een notitie voor het verkoopteam. 00:07:22.200 --> 00:07:23.880 Het wordt het uitgangspunt voor de planning, 00:07:23.880 --> 00:07:28.800 waarbij wordt teruggewerkt vanuit de vraag wat er moet gebeuren voordat die fietsen het magazijn kunnen verlaten. 00:07:29.020 --> 00:07:31.100 De voltooide fiets is slechts de eerste laag. 00:07:31.320 --> 00:07:35.120 Dynamics 365 controleert de stuklijst, vaak de bom, genoemd. 00:07:35.280 --> 00:07:37.280 Zie de stuklijst als het recept voor één fiets. 00:07:37.500 --> 00:07:41.140 Het vermeldt het frame, de wielen, de ketting, het zadel, het stuur, de remmen, 00:07:41.320 --> 00:07:43.460 bouten en elk ander onderdeel dat nodig is om hen te bouwen. 00:07:43.600 --> 00:07:48.620 Als de order om 70 fietsen vraagt, breidt de planning die order uit naar de onderdelen die nodig zijn voor alle 70 fietsen. 00:07:48.620 --> 00:07:55.520 Dat kan al snel een lange lijst worden. Je hebt wellicht 70 frames, 140 wielen, 70 kettingen, 70 zadels en honderden kleine boutjes nodig. 00:07:55.700 --> 00:07:58.100 Een planner hoeft niet elk onderdeel met de hand te tellen. 00:07:58.260 --> 00:08:04.780 De stuklijst geeft Dynamics 365 de structuur zodat het systeem de vraag kan herleiden van de voltooide fiets tot elk afzonderlijk onderdeel. 00:08:04.940 --> 00:08:07.440 Maar met alleen onderdelen kun je nog geen fietsen produceren. 00:08:07.600 --> 00:08:09.200 Voor productie is ook een route nodig. 00:08:09.400 --> 00:08:11.960 Een route beschrijft de werkstappen die nodig zijn om het item te bouwen, 00:08:12.140 --> 00:08:16.800 zoals het assembleren van het frame, het monteren van de wielen, het controleren van de remmen en het verpakken van de voltooide fiets. 00:08:16.800 --> 00:08:18.860 Voor elke stap kan een hulbron nodig zijn. 00:08:19.060 --> 00:08:24.800 Die hulbron kan een assemblage lijn, een werkbank, een spuitcabine, een machine of een groep mensen met de juiste vaardigheden zijn. 00:08:24.980 --> 00:08:28.080 De planning gebruikt deze informatie om werk op het juiste moment in te plannen. 00:08:28.280 --> 00:08:32.620 In plaats van productie als iets te zien dat onmiddellijk gebeurt, beginnen data hier terug in de tijd te lopen. 00:08:32.820 --> 00:08:36.900 Als de klant de fietsen op vrijdag nodig heeft, moet de productieorder wellicht op donderdag klaar zijn, 00:08:37.100 --> 00:08:39.040 zodat het magazijn ze kan inpakken en verzenden. 00:08:39.240 --> 00:08:41.260 De assemblage moet misschien al op dinsdag beginnen. 00:08:41.500 --> 00:08:43.840 De frames en wielen moeten dan mogelijk op maandag arriveren. 00:08:43.840 --> 00:08:48.600 Als een leverancier 10 dagen nodig heeft om wielen te leveren, moet de inkooporder jouw bedrijf nog eerder verlaten. 00:08:48.760 --> 00:08:51.000 De datum van de klant creëert een keten van data. 00:08:51.320 --> 00:08:56.020 Dynamics 365 werkt achterwaarts door die keten, rekening houdend met doorlooptijden. 00:08:56.160 --> 00:09:01.080 Een doorlooptijd is simpelweg de tijd die iets nodig heeft, of het nu gaat om een leverancier die een onderdeel levert, 00:09:01.200 --> 00:09:04.260 een magazijn dat goederen verplaatst of een fabriek die een taak afrondt. 00:09:04.320 --> 00:09:06.220 Een te laat onderdeel kan alles vertragen. 00:09:06.520 --> 00:09:09.160 Stel dat het systeem 70 frames op voorraad vindt. 00:09:09.160 --> 00:09:14.480 Het ziet ook een openstaande inkooporder voor 140 wielen met een levering geplant voor aanvang van de assemblage. 00:09:14.740 --> 00:09:18.280 Dat aanbod dekt de behoefte aan wielen, terwijl de frames al voor hun deel zorgen. 00:09:18.480 --> 00:09:19.900 Daarna controleert het de kettingen. 00:09:20.060 --> 00:09:23.800 Misschien zijn er slechts 40 kettingen voor handen en zorgt geen enkele inkooporder voor de resterende 30. 00:09:23.960 --> 00:09:26.360 De planning ziet een tekort en doet een voorstel om dit op te vangen. 00:09:26.580 --> 00:09:30.780 Dezelfde controle wordt uitgevoerd voor de voltooide fietsen, de onderdelen daaronder en al het werk daartussenin. 00:09:30.900 --> 00:09:32.180 Er bestaat al enig aanbod. 00:09:32.520 --> 00:09:34.220 Beschikbare voorraad kan in een behoefte voorzien. 00:09:34.360 --> 00:09:37.260 Een openstaande inkooporder kan hierin voorzien als de goederen op tijd arriveren. 00:09:37.260 --> 00:09:40.580 Een openstaande productieorder kan hierin voorzien als de fabriek op tijd klaar is. 00:09:40.760 --> 00:09:44.400 Wanneer geen van deze bronnen aan de vraag voldoet, maakt het plan een geplande order aan. 00:09:44.540 --> 00:09:47.500 Een geplande inkooporder stelt voor om iets bij een leverancier te kopen. 00:09:47.660 --> 00:09:50.700 Een geplande productieorder stelt voor om iets binnen uw bedrijf te bouwen. 00:09:50.840 --> 00:09:55.380 Een geplande transferorder stelt voor om voorraad van de ene locatie of het ene magazijn naar het andere te verplaatsen. 00:09:55.520 --> 00:09:57.380 Dit zijn suggesties, geen verplichtingen. 00:09:57.720 --> 00:10:03.160 Dynamics 365 stuurt niet zomaar in stilte een order naar een leverancier of start het werk op de werkvloer. 00:10:03.160 --> 00:10:07.380 Het geeft de planner een voorgestelde hoeveelheid en datum op basis van de beschikbare gegevens. 00:10:07.560 --> 00:10:13.100 Een persoon controleert nog steeds of de leverancier correct is, of de datum haalbaar is en of het bedrijf de actie moet goedkeuren. 00:10:13.300 --> 00:10:15.420 Stel u een klein probleem voor met onze fietsorder. 00:10:15.620 --> 00:10:17.340 Alles lijkt klaar, behalve één wiel. 00:10:17.540 --> 00:10:21.000 De geplande aanvoer dekt frames, kettingen, zadels en bijna elk wiel. 00:10:21.180 --> 00:10:24.060 Maar één wiel arriveert een dag nadat de assemblage het nodig heeft. 00:10:24.320 --> 00:10:26.520 Zonder dat wiel kan één fiets niet worden voltooid. 00:10:26.700 --> 00:10:31.060 Hoewel het magazijn vol onderdelen lijkt te liggen, herleidt de hoofdplanning het tekort naar de bron. 00:10:31.060 --> 00:10:34.720 De planner kan zien dat het tekort niet voortkomt uit de klantenorder zelf. 00:10:34.900 --> 00:10:38.100 O, het komt door de datum van de leverancier op de inkooporder voor de wielen. 00:10:38.320 --> 00:10:40.480 Dat geeft de planner iets specifieks om op te acteren. 00:10:40.700 --> 00:10:43.980 Vraag om een eerdere levering, zoek een andere bron of wijzig de productiedatum. 00:10:44.140 --> 00:10:45.640 Het plan kan aanbod voorstellen. 00:10:45.880 --> 00:10:47.660 Maar de volgende vraag is net zo nuttig. 00:10:47.840 --> 00:10:51.160 Waarom heeft Dynamics 365 dit aanbod aan die vraag gekoppeld? 00:10:51.320 --> 00:10:54.000 Het lezen van netto behoeften, het planningsgesprek. 00:10:54.140 --> 00:10:57.620 Planners gebruiken daarom de pagina met netto behoeften om die verbinding te onderzoeken. 00:10:57.620 --> 00:11:01.740 Deze pagina brengt het volledige planningsgesprek voor één artikel op één plek samen. 00:11:01.900 --> 00:11:07.180 Het toont elke behoefte aan het artikel en elke leveringsbron die dit kan dekken, met datums direct naast elke regel. 00:11:07.480 --> 00:11:08.940 Neem het fietswiel als voorbeeld. 00:11:09.260 --> 00:11:12.560 Bovenaan kiest u de locatie of het magazijn waarvoor dat wiel relevant is. 00:11:12.780 --> 00:11:19.200 Daaronder toont Dynamics 365 alle gerelateerde transacties, zoals verkopen, inkopen, voorraad en productie, allemaal in één lijst. 00:11:19.340 --> 00:11:22.900 De vraag wordt weergegeven als een negatief getal ten opzichte van uw beschikbare voorraad. 00:11:22.900 --> 00:11:27.720 Die vraag kan uit vele hoeken komen. Een verkooporder heeft wielen nodig omdat een klant fietsen heeft besteld. 00:11:27.900 --> 00:11:32.720 Een prognose creëert een verwachte toekomstige vraag. Een productieorder heeft wielen nodig voor het productieplan. 00:11:32.920 --> 00:11:35.900 En een overboekingsorder creëert vraag wanneer een ander magazijn om voorraad vraagt. 00:11:36.080 --> 00:11:40.200 Elke regel beantwoordt een eenvoudige vraag. Wie heeft dit artikel nodig? Hoeveel hebben ze er nodig? 00:11:40.400 --> 00:11:43.780 En op welke datum? Dat klinkt simpel, maar het voorkomt een veelgemaakte fout. 00:11:44.020 --> 00:11:47.800 Mensen zien vaak een totaalhoeveelheid en gaan ervan uit dat deze bij één klant of taak hoort, 00:11:48.000 --> 00:11:51.340 terwijl hetzelfde artikel meerdere orders op verschillende data kan ondersteunen. 00:11:51.340 --> 00:11:55.320 Aan de aanbodzijde heeft u de voorhanden voorraad, of wat er al op voorraad is. 00:11:55.560 --> 00:11:59.260 Daarnaast inkooporders van leveranciers, productieorders die uw bedrijf plant, 00:11:59.460 --> 00:12:03.800 transfers tussen magazijnen en geplande orders die het systeem voorstelt maar die nog niet zijn aangemaakt. 00:12:03.960 --> 00:12:09.500 De pagina sorteert alles op datum. Terwijl u door de lijst bladert, ziet u de beschikbare hoeveelheid veranderen. 00:12:09.640 --> 00:12:14.100 De voorraad kan er begin van de maand goed uitzien, dan dalen wanneer een productieorder onderdelen gebruikt, 00:12:14.260 --> 00:12:15.980 en weer stijgen als een leverancier levert. 00:12:16.160 --> 00:12:17.760 Timing verandert het resultaat. 00:12:17.760 --> 00:12:23.040 Stel dat er op maandag 100 wielen in een magazijn liggen, maar een productieorder op dinsdag 80 wielen nodig heeft 00:12:23.040 --> 00:12:25.240 en er op woensdag een klantbehoefte van 30 bij komt. 00:12:25.400 --> 00:12:30.220 De totale vraag overstijgt de voorraad, ook al komt er op vrijdag een inkooporder van 50 wielen binnen. 00:12:30.440 --> 00:12:33.000 De levering van vrijdag lost het tekort van woensdag niet op. 00:12:33.220 --> 00:12:36.080 Dat dag-voor-dag-overzicht verklaart waarom het systeem zijn suggesties doet. 00:12:36.300 --> 00:12:39.580 Dynamics 365 vraagt niet zomaar willekeurig om meer wielen. 00:12:39.760 --> 00:12:43.220 Het ziet precies wanneer het beschikbare aanbod onder de te dekken vraag zakt. 00:12:43.220 --> 00:12:47.620 Nu stelt u wellicht een specifiekere vraag. Welke leveringsregel dekt welke vraagsregel? 00:12:47.740 --> 00:12:49.200 Die verbinding wordt pegging genoemd. 00:12:49.280 --> 00:12:52.980 Pegging is de eigen planningskoppeling van Dynamics 365 tussen vraag en aanbod. 00:12:53.160 --> 00:12:56.800 Het verbindt een behoefte, zoals een productieorder voor fietsen, met de bron die dit moet dekken, 00:12:57.000 --> 00:12:59.380 zoals een inkooporder voor wielen of een geplande inkooporder. 00:12:59.600 --> 00:13:02.620 Het systeem bouwt deze koppeling tijdens de planningsberekening op. 00:13:02.780 --> 00:13:05.980 Als de vraag verandert, kan de planning de verbinding opnieuw berekenen. 00:13:06.200 --> 00:13:09.660 Misschien verplaatst een klant zijn leverdatum of verschuift een inkooporder. 00:13:09.660 --> 00:13:14.920 Pegging kan dan naar een andere leveringsbron wijzen of een nieuwe geplande order aanmaken waar het tekort ontstaat. 00:13:15.040 --> 00:13:16.860 Het helpt je de gehele keten te traceren. 00:13:17.120 --> 00:13:19.740 Begin bij een verkooporder, bekijk de gekoppelde productieorder, 00:13:19.980 --> 00:13:22.740 volg deze naar de benodigde onderdelen en vind de inkooporder die ze dekt. 00:13:22.960 --> 00:13:24.400 Soms heb je meer controle nodig. 00:13:24.660 --> 00:13:26.060 Dat is waar markeren van pas komt. 00:13:26.300 --> 00:13:29.920 Markeren is een handmatige verbinding tussen een aanboventransactie en een vraagtransactie. 00:13:30.060 --> 00:13:32.620 Het vertelt het systeem dat dit aanbod aan die vraag moet voldoen, 00:13:32.800 --> 00:13:35.240 in plaats van de planning het ergens anders vrij te laten matchen. 00:13:35.240 --> 00:13:38.360 Zie het als het plaatsen van een label op twee gerelateerde records. 00:13:38.360 --> 00:13:43.160 Je kunt een specifieke inkomende inkooporder voor wielen markeren voor een bepaalde productieorder 00:13:43.160 --> 00:13:45.180 omdat die wielen voor dat werk zijn gekocht. 00:13:45.340 --> 00:13:48.860 De planning respecteert die relatie steviger dan de normale pegging-koppeling. 00:13:49.100 --> 00:13:52.040 Toch is gemarkeerd aanbod niet de sterkste verbinding die beschikbaar is. 00:13:52.460 --> 00:13:53.500 Reservering is sterker. 00:13:53.760 --> 00:13:58.040 Wanneer je voorraad of inkomend aanbod reserveert voor een specifieke vraag, creëer je een harde link. 00:13:58.240 --> 00:14:02.160 Die hoeveelheid wordt apart gezet voor de gekozen verkooporder, productieorder of andere vraag. 00:14:02.160 --> 00:14:06.800 En de hoofdplanning behandelt de reservering als prioriteit boven normale, pegging en markering. 00:14:06.800 --> 00:14:11.200 Stel je tien wielen op voorraad voor, maar die wielen zijn gereserveerd voor een dringende reparatieorder. 00:14:11.400 --> 00:14:17.180 Een latere klantenorder heeft wellicht ook wielen nodig, maar de planning kan die tien gereserveerde wielen niet als vrij beschikbaar beschouwen. 00:14:17.340 --> 00:14:21.620 Het moet ander aanbod vinden of meer aanbod voorstellen, omdat de reservering ze al elders toewijst. 00:14:21.780 --> 00:14:24.640 Dus, pegging, markeren en reserveren bieden je drie niveaus van verbinding. 00:14:24.840 --> 00:14:26.780 Pegging is de automatische match van het systeem. 00:14:26.980 --> 00:14:29.000 Markeren is een handmatige, meer vaste koppeling. 00:14:29.000 --> 00:14:31.620 Reserveren vergrendeld aanbod aan een specifieke behoefte. 00:14:31.740 --> 00:14:32.760 De sterkste van de drie. 00:14:32.980 --> 00:14:37.480 Zodra je die koppelingen kunt lezen, lijken geplande orders niet langer op onverklaarbare instructies. 00:14:37.660 --> 00:14:43.000 De volgende vraag is hoe vaak dit planningsoverzicht verandert en hoe snel Dynamics 365 dit kan berekenen. 00:14:43.220 --> 00:14:45.560 Statisch, dynamisch en planningsoptimalisatie. 00:14:45.780 --> 00:14:49.900 De pagina nettobehoefte toont een planningsresultaat, maar niet elk plan werkt op dezelfde manier bij. 00:14:50.060 --> 00:14:53.140 Een statisch plan verandert alleen wanneer iemand de hoofdplanning uitvoert. 00:14:53.140 --> 00:14:58.820 Dat geeft planners een stabiel beeld dat ze gedurende de dag kunnen bekijken zonder dat elke nieuwe transactie de cijfers eronder verandert. 00:14:59.000 --> 00:15:02.000 Stel je voor dat er ochtends om 11 uur een grote verkooporder binnenkomt. 00:15:02.140 --> 00:15:06.940 Als het statische plan s'nachts is gedraaid, verschijnt die nieuwe order pas in de suggesties bij de volgende planningsrun. 00:15:07.120 --> 00:15:12.580 Het plan toont nog steeds het laatst berekende resultaat, wat nuttig kan zijn wanneer een team 1 afgesproken beeld voor de dag nodig heeft. 00:15:12.760 --> 00:15:14.320 Maar die stabiliteit heeft een prijs. 00:15:14.540 --> 00:15:19.900 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. 00:15:19.900 --> 00:15:24.960 Een planner weet wellicht dat er een klantenorder bestaat, maar het statische plan heeft de aanbodreactie nog niet herberekend. 00:15:25.140 --> 00:15:26.620 Dat is waar een dynamisch plan helpt. 00:15:26.620 --> 00:15:29.320 Een dynamisch plan toont de huidige vraag zoals die zich voordoet. 00:15:29.440 --> 00:15:34.100 Planners kunnen het effect van nieuwe verkooporders en andere vragen zien zonder te wachten op de volgende volledige hoofdplanning. 00:15:34.240 --> 00:15:35.840 Het is een blik op de kortere termijn. 00:15:36.080 --> 00:15:39.300 Dynamische plannen slaan prognoses over en focussen op wat er nu gebeurt. 00:15:39.560 --> 00:15:43.180 Stel dat een klant vanmiddag onverwacht een order plaatst voor 200 fietsen. 00:15:43.380 --> 00:15:47.620 Voordat iemand een leverdatum belooft, kan de planner het dynamische plan openen en het effect controleren. 00:15:47.620 --> 00:15:50.040 Veroorzaakt de nieuwe order een tekort? 00:15:50.220 --> 00:15:52.580 Schuift het een bestaande behoefte door naar een latere datum? 00:15:52.780 --> 00:15:55.620 Activeert het een nieuwe voorgestelde inkoop- of productieactie? 00:15:55.820 --> 00:15:58.340 Dit geeft het team een praktisch, wat als overzicht. 00:15:58.520 --> 00:16:01.920 Je wijzigt het statische plan niet zomaar om één nieuwe order te onderzoeken. 00:16:02.100 --> 00:16:08.000 Je controleert eerst de waarschijnlijke impact en beslist dan of de order nu aandacht nodig heeft of kan wachten op de volgende geplande run. 00:16:08.260 --> 00:16:11.620 Statische en dynamische plannen beantwoorden gerelateerde maar verschillende vragen. 00:16:11.620 --> 00:16:16.100 Het statische plan vraagt, wat zei onze laatste officiële planningsberekening dat we moesten doen. 00:16:16.280 --> 00:16:19.800 Het dynamische plan vraagt hoe de huidige vraag er op dit moment uitziet. 00:16:20.000 --> 00:16:24.860 Achter beide plannen zit de plannings engine voor Dynamics 365 cloudomgevingen. 00:16:25.000 --> 00:16:28.620 Planning optimalisatie is de moderne engine die Microsoft gebruikt voor hoofdplanning. 00:16:29.440 --> 00:16:35.220 Deze berekent de verrijste buiten de hoofdbedrijfstoepassing, wat de belasting op het systeem voor dagelijks werk vermindert. 00:16:35.420 --> 00:16:37.260 Oudere plannings runs konden lang duren. 00:16:37.260 --> 00:16:43.000 Rapporten van klanten en partners beschrijven planningswerk dat voorheen uren duurde en nu in minuten wordt voltooid met planning optimalisatie. 00:16:43.260 --> 00:16:48.760 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. 00:16:48.880 --> 00:16:50.900 Maar een sneller antwoord kan nog steeds een verkeerd antwoord zijn. 00:16:51.060 --> 00:16:54.780 Planning optimalisatie kan snel een enorme hoeveelheid gekoppelde gegevens berekenen. 00:16:54.920 --> 00:16:57.660 Toch werkt het alleen op basis van de gegevens die jouw bedrijf invoert. 00:16:57.860 --> 00:17:01.360 Als de levertijd van een leverancier fout is, kan de voorgestelde orderdatum ook fout zijn. 00:17:01.360 --> 00:17:06.640 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. 00:17:06.780 --> 00:17:11.340 En als een onderdeel ontbreekt in de stuklijst, kan de planning geen vraag creëren voor dat ontbrekende onderdeel. 00:17:11.480 --> 00:17:15.760 De berekening is misschien in minuten klaar, maar de fabriek staat nog steeds stil als dat onderdeel er niet is. 00:17:15.920 --> 00:17:18.180 Er is ook een verandering in hoe planningen worden uitgevoerd. 00:17:18.400 --> 00:17:20.800 Met planning optimalisatie zijn plannen regeneratief. 00:17:20.980 --> 00:17:28.220 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. 00:17:28.220 --> 00:17:31.420 Zie het als het telkens opnieuw berekenen van het volledige planningsbeeld. 00:17:31.660 --> 00:17:39.100 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. 00:17:39.340 --> 00:17:42.860 Snelheid helpt, maar schone data bepaalt of het plan vertrouwen verdient. 00:17:43.120 --> 00:17:47.940 Zodra het plan suggesties genereert, is de volgende stap bepalen welke actie prioriteit heeft. 00:17:48.180 --> 00:17:50.320 Maar wat masterplanning doet en wat het nu doet. 00:17:50.320 --> 00:17:52.460 Dus hier is de eenvoudigste definitie. 00:17:52.800 --> 00:17:59.980 Masterplanning gebruikt alle data in Dynamics 365 en suggereert wat te kopen, produceren of verplaatsen, inclusief datums en hoeveelheden. 00:18:00.140 --> 00:18:03.080 Een planner beoordeelt die geplande orders voordat er actie wordt ondernomen. 00:18:03.300 --> 00:18:07.600 Ze controleren de leverancier, de leverdatum, de hoeveelheid en of de fabriek het werk aan kan. 00:18:07.820 --> 00:18:12.520 Na bevestiging wordt die suggestie omgezet in een echte inkooporder, productieorder of transferorder. 00:18:12.740 --> 00:18:14.840 Maar masterplanning kan de toekomst niet voorspellen. 00:18:15.000 --> 00:18:18.920 Prognoses zijn slecht schattingen en echte klantorders kunnen van de ene op de andere dag veranderen. 00:18:19.020 --> 00:18:21.000 En het vervangt absoluut geen menselijke planners. 00:18:21.320 --> 00:18:25.020 Mensen beheren nog steeds het leveranciersrisico, klantafspraken en uitzonderingen. 00:18:25.140 --> 00:18:26.980 Het systeem kan simpelweg niet oordelen. 00:18:27.220 --> 00:18:28.660 Alleen voorraad is ook niet genoeg. 00:18:28.840 --> 00:18:33.100 Die voorraad kan te laat komen, in het verkeerde magazijn liggen of al gereserveerd zijn voor een andere order. 00:18:33.320 --> 00:18:41.560 Voor goede resultaten begint u met schone data, correcte artikelgegevens, nauwkeurige levertijden, juiste stuklijsten, actuele voorraad en realistische vraag. 00:18:41.560 --> 00:18:44.900 Voor onze fietsorder dekt de huidige voorraad een deel van de behoefte. 00:18:45.060 --> 00:18:48.240 De planning suggereert aanvoer voor de rest en de planner bevestigt de actie. 00:18:48.440 --> 00:18:51.340 Dat brengt ons terug bij de vraag waar elk team antwoord op moet hebben. 00:18:51.560 --> 00:18:52.620 Wat moet er nu gebeuren? 00:18:53.760 --> 00:18:55.280 Conclusie 1 verbonden plan. 00:18:55.680 --> 00:19:01.780 Masterplanning combineert vraag, voorraadniveaus, leverdata van leveranciers, productieschema's en capaciteit... 00:19:01.780 --> 00:19:03.940 ...en zet dit om in acties die uw team kan beoordelen. 00:19:04.140 --> 00:19:06.720 Geplande orders starten nu het menselijke besluitvormingsproces. 00:19:06.940 --> 00:19:07.920 Ze voltooien het niet. 00:19:08.160 --> 00:19:09.680 Daarom blijven planners essentieel. 00:19:09.680 --> 00:19:15.500 Abonneer u op uw favoriete podcastplatform en deel dit kennisfragment met iemand die Dynamics 365 Supply Chain Management leert.