Smart IP&O biedt geautomatiseerde statistische prognoses die de juiste prognosemethode selecteren die de gegevens het beste voorspelt. Het doet dit voor elke tijdreeks in de dataset. Deze blog zal leken helpen begrijpen hoe de voorspellingsmethoden automatisch worden gekozen.

Smart stelt vele methoden beschikbaar, waaronder enkele en dubbele exponentiële afvlakking, lineair en eenvoudig voortschrijdend gemiddelde, en Winters-modellen. Elk model is ontworpen om een ander soort patroon vast te leggen. De criteria om automatisch één statistische methode uit een reeks keuzes te kiezen, zijn gebaseerd op welke methode het dichtst bij het correct voorspellen van de achtergehouden geschiedenis kwam.

Eerdere vraaggeschiedenis wordt aan elke methode doorgegeven en het resultaat wordt vergeleken met de werkelijke waarden om de methode te vinden die er in het algemeen het dichtst bij kwam. Die "winnende" automatisch gekozen methode krijgt dan alle geschiedenis voor dat item om de prognose te produceren.

De algehele aard van het vraagpatroon voor het item wordt vastgelegd door verschillende delen van de geschiedenis vast te houden, zodat een incidentele uitbijter de keuze van de methode niet onnodig beïnvloedt. U kunt het visualiseren met behulp van het onderstaande diagram, waarin elke rij een 3-periodevoorspelling in de uitgehouden geschiedenis vertegenwoordigt, gebaseerd op verschillende hoeveelheden van de rode eerdere geschiedenis. De varianties van elke pass worden samen gemiddeld om de algemene rangschikking van de methode ten opzichte van alle andere methoden te bepalen.

Voor de meeste tijdreeksen kan dit proces nauwkeurig trends, seizoensinvloeden en gemiddeld volume vastleggen. Maar soms komt een gekozen methode wiskundig het dichtst in de buurt van het voorspellen van de achtergehouden geschiedenis, maar projecteert deze niet op een logische manier.

Gebruikers kunnen dit corrigeren door de uitzonderingsrapporten en filterfuncties van het systeem te gebruiken om items te identificeren die een beoordeling verdienen. Vervolgens kunnen ze de automatische prognosemethoden configureren waarmee ze voor dat item in aanmerking willen komen.

Hoe lang moet het duren voordat een vraagprognose wordt berekend met behulp van statistische methoden? Deze vraag wordt vaak gesteld door klanten en prospects. Het antwoord hangt er echt van af. Voorspellingsresultaten voor een enkel item kunnen in een oogwenk worden berekend, in slechts enkele honderdsten van een seconde, maar soms kan het zelfs vijf seconden duren. Om de verschillen te begrijpen, is het belangrijk om te begrijpen dat er meer bij komt kijken dan alleen de rekenkundige berekeningen zelf door te spitten. Hier zijn zes factoren die de snelheid van uw prognose-engine beïnvloeden.

1) Prognosemethode.  Traditionele tijdreeks-extrapolatieve technieken (zoals exponentiële afvlakking en voortschrijdend-gemiddeldemethoden) zijn, mits slim gecodeerd, razendsnel. De automatische prognose-engine Smart Forecast, die gebruikmaakt van deze technieken en onze software voor vraagplanning en voorraadoptimalisatie aandrijft, kan bijvoorbeeld in 1 seconde statistische prognoses voor 1000 artikelen genereren! Extrapolatieve methoden produceren een verwachte voorspelling en een samenvattende maatstaf voor de voorspellingsonzekerheid. Complexere modellen in ons platform die probabilistische vraagscenario's genereren, duren echter veel langer bij dezelfde computerbronnen. Dit komt deels omdat ze een veel groter outputvolume creëren, meestal duizenden plausibele toekomstige vraagreeksen. Meer tijd, ja, maar geen tijdverspilling, aangezien deze resultaten veel vollediger zijn en de basis vormen voor downstream-optimalisatie van voorraadbeheerparameters.

2) Computerbronnen.  Hoe meer bronnen u naar de berekening gooit, hoe sneller het zal zijn. Middelen kosten echter geld en het is misschien niet economisch om in deze middelen te investeren. Om bijvoorbeeld bepaalde soorten op machine learning gebaseerde prognoses te laten werken, moet het systeem multithread-berekeningen over meerdere servers uitvoeren om snel resultaten te leveren. Zorg er dus voor dat u de veronderstelde rekenresources en bijbehorende kosten begrijpt. Onze berekeningen vinden plaats in de Amazon Web Services-cloud, dus het is mogelijk om desgewenst voor een groot deel van de parallelle berekeningen te betalen.

3) Aantal tijdreeksen.  Moet u slechts een paar honderd artikelen op één locatie of vele duizenden artikelen op tientallen locaties voorspellen? Hoe groter het aantal combinaties van SKU x Locatie, hoe langer de benodigde tijd. Het is echter mogelijk om de tijd om vraagprognoses te krijgen te verkorten door een betere vraagclassificatie. Het is bijvoorbeeld niet belangrijk om elke combinatie van SKU x Locatie te voorspellen. Moderne software voor vraagplanning kan de gegevens eerst subsetten op basis van volume-/frequentieclassificaties voordat de prognose-engine wordt uitgevoerd. We hebben situaties waargenomen waarin meer dan een miljoen combinaties van SKU x Locatie bestonden, maar waar slechts tien procent vraag naar had in de voorgaande twaalf maanden.

4) Historisch emmeren. Maakt u prognoses met behulp van dagelijkse, wekelijkse of maandelijkse tijdsintervallen? Hoe gedetailleerder de bucketing, hoe meer tijd het kost om statistische prognoses te berekenen. Veel bedrijven zullen zich afvragen: "Waarom zou iemand dagelijks prognoses willen maken?" State-of-the-art software voor vraagvoorspelling kan echter gebruikmaken van dagelijkse gegevens om gelijktijdige dag-van-week- en week-van-maandpatronen te detecteren die anders zouden worden verdoezeld met traditionele maandelijkse vraagbuckets. En de snelheid van zaken blijft toenemen, wat de concurrentiekracht van het traditionele maandelijkse planningstempo bedreigt.

5) Hoeveelheid geschiedenis. Beperkt u het model door alleen de meest recente vraaghistorie in te voeren, of voert u alle beschikbare historie in de vraagvoorspellingssoftware? Hoe meer historie u het model voedt, hoe meer gegevens er moeten worden geanalyseerd en hoe langer het gaat duren.

6) Aanvullende analytische verwerking.  Tot nu toe hebben we ons voorgesteld om de vraaggeschiedenis van items in te voeren en prognoses te krijgen. Maar het proces kan ook aanvullende analytische stappen omvatten die de resultaten kunnen verbeteren. Voorbeelden zijn onder meer:

a) Uitbijterdetectie en -verwijdering om de vervorming te minimaliseren die wordt veroorzaakt door eenmalige gebeurtenissen zoals stormschade.

b) Machine learning dat beslist hoeveel geschiedenis moet worden gebruikt voor elk item door verandering van regime te detecteren.

c) Causale modellering die identificeert hoe veranderingen in vraagbepalende factoren (zoals prijs, rentevoet, klantensentiment, enz.) de toekomstige vraag beïnvloeden.

d) Melding van uitzonderingen die data-analyse gebruikt om ongebruikelijke situaties te identificeren die nadere beoordeling door het management verdienen.

De rest van het verhaal. Het is ook van cruciaal belang om te begrijpen dat de tijd om een antwoord te krijgen meer inhoudt dan de snelheid van het voorspellen van berekeningen per se. Gegevens moeten in het geheugen worden geladen voordat de berekening kan beginnen. Zodra de prognoses zijn berekend, moet uw browser de resultaten laden zodat ze op het scherm kunnen worden weergegeven zodat u ermee kunt werken. Als u een product opnieuw voorspelt, kunt u ervoor kiezen om de resultaten op te slaan. Als u werkt met producthiërarchieën (het samenvoegen van artikelprognoses tot productfamilies, families tot productlijnen, enz.), zal de nieuwe prognose de hiërarchie beïnvloeden en moet alles op elkaar worden afgestemd. Dit kost allemaal tijd.

Snel genoeg voor jou? Wanneer u software evalueert om te zien of aan uw behoefte aan snelheid zal worden voldaan, kan dit allemaal worden getest als onderdeel van een proof of concept of proef aangeboden door leveranciers van software voor vraagplanning. Test het uit, en zorg ervoor dat de berekenen, laden en opslaan tijden zijn acceptabel gezien de hoeveelheid gegevens en prognosemethoden die u wilt gebruiken om uw proces te ondersteunen.

 Wat is het wiggle-effect? 

Het is wanneer uw statistische prognose de ups en downs die in uw vraaggeschiedenis zijn waargenomen, onjuist voorspelt terwijl er echt geen patroon is. Het is belangrijk om ervoor te zorgen dat uw prognoses niet schommelen, tenzij er een echt patroon is.

Hier is een transcriptie van een recente klant waar dit probleem werd besproken:

Klant: “De prognose volgt niet de patronen die ik in de historie zie. Waarom niet?" 

Smart: “Als je goed kijkt, zijn de ups en downs die je ziet geen patronen. Het is echt lawaai.”  

Klant: "Maar als we de hoogtepunten niet voorspellen, slaan we de voorraad op."

Smart: “Als de voorspelling zou 'wiebelen', zou die veel minder nauwkeurig zijn. Het systeem voorspelt welk patroon dan ook, in dit geval een zeer lichte opwaartse trend. We bufferen het lawaai met veiligheidsvoorraden. De wiggles worden gebruikt om de veiligheidsvoorraden in te stellen.”

Klant: “Oké. Logisch nu.” 

De wiggle ziet er geruststellend uit, maar in dit geval resulteert het in een onjuiste vraagprognose. De ups en downs vinden niet echt elke maand op hetzelfde tijdstip plaats. Een betere statistische voorspelling wordt weergegeven in lichtgroen.

Microsoft Dynamics 365 F&SC en AX kunnen aanvulling beheren door te suggereren wat te bestellen en wanneer via op bestelpunten gebaseerd voorraadbeleid. Een uitdaging waarmee klanten worden geconfronteerd, is dat inspanningen om deze niveaus te handhaven zeer gedetailleerd zijn georiënteerd en dat het ERP-systeem vereist dat de gebruiker deze bestelpunten en/of prognoses handmatig specificeert. Als alternatief genereren veel organisaties handmatig voorraadbeleid met behulp van Excel-spreadsheets of andere ad-hocbenaderingen.

Deze methoden zijn tijdrovend en beide resulteren waarschijnlijk in een zekere mate van onnauwkeurigheid. Als gevolg hiervan zal de organisatie eindigen met overtollige voorraad, onnodige tekorten en een algemeen wantrouwen in hun softwaresystemen. In dit artikel zullen we de functionaliteit voor het bestellen van voorraad in AX / D365 F&SC bekijken, de beperkingen ervan uitleggen en samenvatten hoe slimme voorraadplanning en -optimalisatie kan helpen de kaspositie van een bedrijf te verbeteren. Dit wordt bereikt door verminderde voorraad, geminimaliseerde en gecontroleerde stockouts. Gebruik van Smart Software levert voorspellende functionaliteit die ontbreekt in Dynamics 365.

Microsoft Dynamics 365 F&SC en AX-aanvullingsbeleid

In de voorraadbeheermodule van AX en F&SC kunnen gebruikers voor elk voorraadartikel handmatig planningsparameters invoeren. Deze parameters omvatten bestelpunten, doorlooptijden veiligheidsvoorraad, hoeveelheden veiligheidsvoorraad, bestelcycli en bestelmodificatoren zoals door de leverancier opgelegde minimale en maximale bestelhoeveelheden en veelvouden van bestellingen. Eenmaal ingevoerd, zal het ERP-systeem de inkomende voorraad, de actuele voorraad, de uitgaande vraag en de door de gebruiker gedefinieerde prognoses en voorraadbeleid afstemmen om het leveringsplan of orderschema (dwz wat te bestellen en wanneer) te berekenen.

Er zijn 4 keuzes voor het aanvullingsbeleid in F&SC en AX: vaste bestelhoeveelheid, maximale hoeveelheid, lot-voor-lot en klantordergestuurd.

• Vaste bestelhoeveelheid en Max zijn op bestelpunten gebaseerde aanvullingsmethoden. Beide suggereren bestellingen wanneer de beschikbare voorraad het bestelpunt bereikt. Bij een vaste ROQ is de ordergrootte gespecificeerd en zal deze niet variëren totdat deze wordt gewijzigd. Bij Max variëren de bestelgroottes op basis van de voorraadpositie op het moment van bestelling, waarbij bestellingen tot aan de Max worden geplaatst.
• Lot-voor-lot is een op prognoses gebaseerde aanvullingsmethode die de totale voorspelde vraag bundelt over een door de gebruiker gedefinieerd tijdsbestek (de "lotaccumulatieperiode") en een bestelsuggestie genereert voor de totale voorspelde hoeveelheid. Dus als uw totale voorspelde vraag 100 eenheden per maand is en de accumulatieperiode van de partij 3 maanden is, dan is uw bestelsuggestie gelijk aan 300 eenheden.
• Orde gedreven is een op bestelling gebaseerde aanvullingsmethode. Het maakt geen gebruik van bestelpunten of prognoses. Zie het als een "sell one, buy one"-logica die alleen bestellingen plaatst nadat de vraag is ingevoerd.

Beperkingen

Alle F&SC / AX-aanvulinstellingen moeten handmatig worden ingevoerd of geïmporteerd via aangepaste uploads die door klanten zijn gemaakt. Er is gewoon geen manier voor gebruikers om native invoer te genereren (vooral niet optimale). Het gebrek aan geloofwaardige functionaliteit voor prognoses op eenheidsniveau en voorraadoptimalisatie binnen het ERP-systeem is de reden waarom zoveel AX- en F&SC-gebruikers gedwongen zijn te vertrouwen op spreadsheets voor planning en vervolgens handmatig de parameters in te stellen die het ERP nodig heeft. In werkelijkheid stellen de meeste planners handmatig vraagprognoses in en herbestellen.

En wanneer ze spreadsheets kunnen gebruiken, vertrouwen ze vaak op brede vuistregelmethoden die resulteren in het gebruik van vereenvoudigde statistische modellen. Eenmaal berekend in de spreadsheet moeten deze in F&SC/AX worden geladen. Ze worden vaak geladen via omslachtige bestandsimporten of handmatig ingevoerd. Vanwege de tijd en moeite die het kost om deze op te bouwen, werken bedrijven deze cijfers niet vaak bij.

Als deze eenmaal zijn ingevoerd, hebben organisaties de neiging om een reactieve benadering van veranderingen te gebruiken. De enige keer dat een koper/planner het voorraadbeleid beoordeelt, is jaarlijks of op het moment van aankopen of productie. Sommige bedrijven zullen ook reageren nadat ze problemen hebben ondervonden met te lage (of te hoge) voorraden. Om dit in AX en F&AS te beheren, is handmatige ondervraging vereist om de geschiedenis te bekijken, prognoses te berekenen, bufferposities te beoordelen en opnieuw te kalibreren.

Microsoft erkent deze beperkingen in hun kern-ERP's en begrijpt de aanzienlijke uitdagingen voor klanten. Als reactie hierop heeft Microsoft prognoses gepositioneerd onder hun AI Azure-stack. Deze methode valt buiten de kern-ERP's. Het wordt aangeboden als een toolset voor datawetenschappers om te gebruiken bij het definiëren van aangepaste complexe statistieken en berekeningen zoals een bedrijf wenst. Dit komt bovenop enkele eenvoudige basisberekeningen, aangezien het uitgangspunt zich momenteel in de opstartfase van ontwikkeling bevindt. Hoewel dit op de lange termijn winst kan opleveren, betekent deze methode momenteel dat klanten helemaal opnieuw beginnen en definiëren wat Microsoft momenteel 'experimenten' noemt om de vraagplanning te meten.

Het komt erop neer dat klanten voor grote uitdagingen staan om de Dynamics-stack zelf te krijgen om deze problemen op te lossen. Het resultaat is dat CFO's minder geld beschikbaar hebben voor wat ze nodig hebben en dat Sales Execs verkoopkansen onvervuld hebben en mogelijk omzet mislopen omdat het bedrijf de goederen die de klant wil niet kan verzenden.

Word slimmer

Zou het niet beter zijn om gewoon een best-of-breed add-on te gebruiken voor vraagplanning; en een best-of-breed oplossing voor voorraadoptimalisatie om kosten en uitvoeringsniveaus te beheren en in evenwicht te houden? Zou het niet beter zijn om dit dagelijks of wekelijks te kunnen doen om uw beslissingen zo dicht mogelijk bij de behoefte te kunnen nemen, geld te besparen en tegelijkertijd aan de verkoopvraag te voldoen?

Stel je voor dat je een bidirectionele integratie hebt met AX en F&AS, zodat dit allemaal gemakkelijk en snel werkt. Een waar:

• u kunt beleid automatisch opnieuw kalibreren in frequente planningscycli met behulp van in de praktijk bewezen, geavanceerde statistische modellen,
• u zou vraagprognoses kunnen berekenen die rekening houden met seizoens-, trend- en cyclische patronen,
• U zou automatisch optimalisatiemethoden gebruiken die het meest winstgevende voorraadbeleid en serviceniveaus voorschrijven die rekening houden met de werkelijke kosten van voorraadbeheer en voorraadonderbrekingen, waardoor u een volledig economisch beeld krijgt,
• U kunt contant geld vrijmaken voor gebruik binnen het bedrijf en uw voorraadniveaus beheren om de orderafhandeling te verbeteren terwijl u dit geld vrijmaakt.
• u zou veiligheidsvoorraden en voorraadniveaus hebben die rekening houden met de variabiliteit van vraag en aanbod, zakelijke omstandigheden en prioriteiten,
• u zou specifieke serviceniveaus kunnen targeten op productgroepen, klanten, magazijnen of een andere dimensie die u hebt geselecteerd,
• u verhoogt de algehele bedrijfswinst en balansgezondheid.

Breid Microsoft 365 F&SC en AX uit met Smart IP&O

Registreer u hier om een opname te zien van het Microsoft Dynamics Communities-webinar over Smart IP&O:

https://smartcorp.com/inventory-planning-with-microsoft-365-fsc-and-ax/

Een statistische voorspelling van nul kan voor veel verwarring zorgen bij voorspellers, vooral wanneer de historische vraag niet nul is. Natuurlijk, het is duidelijk dat de vraag naar beneden neigt, maar moet deze naar nul evolueren? Wanneer de oudere vraag veel groter is dan de meer recente vraag en de meer recente vraag een zeer laag volume is (dwz 1,2,3 gevraagde eenheden), is het antwoord, statistisch gezien, ja. Dit komt echter mogelijk niet overeen met de zakelijke kennis van de planner en het verwachte minimale vraagniveau. Dus, wat moet een voorspeller doen om dit te corrigeren? Hier zijn drie suggesties:

1. Beperk de historische gegevens die aan het model worden ingevoerd. In een neerwaartse trendsituatie zijn de oudere gegevens dat vaak veel groter dan de recente gegevens. Wanneer de oudere, veel hogere volumevraag wordt genegeerd, zal de neerwaartse trend lang niet zo significant zijn. U voorspelt nog steeds een neerwaartse trend, maar de resultaten zullen eerder in lijn zijn met de zakelijke verwachtingen.

2. Probeer trenddemping. Smart Demand Planner heeft een functie genaamd "trendhedging" waarmee gebruikers kunnen definiëren hoe een trend in de loop van de tijd moet verdwijnen. Hoe hoger het percentage trendhedge (0-100%), hoe sterker de trenddemping. Dit betekent dat een voorspelde trend zich niet gedurende de hele prognosehorizon zal voortzetten. Dit betekent dat de vraagprognose begint af te vlakken voordat deze nul bereikt bij een neerwaartse trend.

3. Wijzig het prognosemodel. Schakel over van een trendingmethode zoals Double Exponential Smoothing of Linear Moving Average naar een niet-trendingmethode zoals Single Exponential Smoothing of Simple Moving Average. U voorspelt geen neerwaartse trend, maar uw voorspelling zal in ieder geval niet nul zijn en dus waarschijnlijker door het bedrijf worden geaccepteerd.