In een zeer configureerbare productieomgeving kan het voorspellen van eindproducten een complexe en lastige taak worden. Het aantal mogelijke eindproducten zal enorm stijgen als veel componenten uitwisselbaar zijn. Een traditionele MRP zou ons dwingen om elk afzonderlijk eindproduct te voorspellen, wat onrealistisch of zelfs onmogelijk kan zijn. Verschillende toonaangevende ERP-oplossingen introduceren het concept van de “Planning BOM”, waarmee prognoses op een hoger niveau in het productieproces kunnen worden gebruikt. In dit artikel bespreken we deze functionaliteit in ERP, en hoe u hiervan kunt profiteren met Smart Inventory Planning en Optimization (Smart IP&O) om in het licht van deze complexiteit uw vraag voor te blijven.

Waarom heb ik een planningsstuklijst nodig?

Traditioneel zou elk eindproduct of elke SKU een strak gedefinieerde stuklijst hebben. Als we dat product op voorraad hebben en rond de voorspelde vraag willen plannen, voorspellen we de vraag naar die producten en voeren we vervolgens MRP in om deze voorspelde vraag via de stuklijst van het niveau van het eindproduct naar de componenten te blazen.

Veel bedrijven bieden echter zeer configureerbare producten aan waarbij klanten opties kunnen selecteren voor het product dat ze kopen. Denk bijvoorbeeld eens aan de laatste keer dat u een personal computer kocht. U koos een merk en model, maar van daaruit kreeg u waarschijnlijk opties te zien: welke CPU-snelheid wilt u? Hoeveel RAM wil je? Wat voor harde schijf en hoeveel ruimte? Als dat bedrijf deze computers binnen een redelijke termijn klaar en beschikbaar wil hebben om naar u te verzenden, anticiperen ze plotseling niet langer alleen maar op de vraag naar dat model; ze moeten dat model voorspellen voor elk type CPU, voor alle hoeveelheden RAM, voor alle soorten harde schijven, en ook alle mogelijke combinaties daarvan! Voor sommige fabrikanten kunnen deze configuraties honderden of duizenden mogelijke voltooide goede permutaties opleveren.

Er kunnen zoveel aanpassingen mogelijk zijn dat de vraag op het niveau van het eindproduct in traditionele zin volkomen onvoorspelbaar is. Duizenden van deze computers kunnen elk jaar worden verkocht, maar voor elke mogelijke configuratie kan de vraag extreem laag en sporadisch zijn – misschien worden bepaalde combinaties één keer verkocht en nooit meer.

Dit dwingt deze bedrijven vaak om bestelpunten en veiligheidsvoorraadniveaus vooral op componentniveau te plannen, terwijl ze grotendeels reageren op de sterke vraag op het niveau van eindproducten via MRP. Hoewel dit een geldige aanpak is, ontbreekt het aan een systematische manier om voorspellingen te doen die rekening kunnen houden met verwachte toekomstige activiteiten, zoals promoties, aanstaande projecten of verkoopkansen. Voorspellen op het 'geconfigureerde' niveau is feitelijk onmogelijk, en het is ook niet haalbaar om deze prognoseaannames op componentniveau te verweven.

Planning BOM uitgelegd

Dit is waar Planning BOM's van pas komen. Misschien werkt het verkoopteam aan een grote b2b-opportuniteit voor dat model, of is er een geplande promotie voor Cyber Monday. Hoewel het niet realistisch is om met deze aannames voor elke mogelijke configuratie te werken, is het op modelniveau wel heel goed te doen – en enorm waardevol.

De Planningstuklijst kan een prognose op een hoger niveau gebruiken en vervolgens de vraag naar beneden blazen op basis van vooraf gedefinieerde verhoudingen mogelijk componenten. De computerfabrikant weet bijvoorbeeld misschien dat de meeste mensen kiezen voor 16 GB RAM, en veel minder mensen kiezen voor de upgrades naar 32 of 64. Met de planningsstuklijst kan de organisatie (bijvoorbeeld) 60% van de vraag terugblazen naar de 16 GB-optie , 30% naar de 32GB-optie en 10% naar de 64GB-optie. Ze zouden hetzelfde kunnen doen voor CPU's, harde schijven of andere beschikbare aanpassingen.  

Het bedrijf kan zijn prognose nu op dit modelniveau richten, waarbij de planningsstuklijst de componentenmix moet uitzoeken. Het is duidelijk dat het definiëren van deze verhoudingen enige denkkracht vereist, maar het plannen van stuklijsten stelt bedrijven in staat te voorspellen wat anders onvoorspelbaar zou zijn.

Het belang van een goede voorspelling

Natuurlijk nog steeds hebben een goede prognose nodig om in een ERP-systeem te laden. Zoals hierin uitgelegd artikelHoewel ERP een prognose kan importeren, kan het er vaak geen genereren en als dat wel het geval is, zijn er vaak veel moeilijk te gebruiken configuraties nodig die niet vaak opnieuw worden bekeken, wat resulteert in onnauwkeurige prognoses. Het is daarom aan het bedrijf om met eigen prognoses te komen, vaak handmatig geproduceerd in Excel. Handmatige prognoses brengen over het algemeen een aantal uitdagingen met zich mee, waaronder maar niet beperkt tot:

• Het onvermogen om vraagpatronen zoals seizoensinvloeden of trends te identificeren
• Overmatig vertrouwen op klant- of verkoopprognoses
• Gebrek aan nauwkeurigheid of prestatieregistratie

Hoe goed de MRP ook is geconfigureerd met uw zorgvuldig overwogen planningsstuklijsten, een slechte prognose betekent een slechte MRP-output en wantrouwen in het systeem: garbage in, garbage out. Als we verdergaan met het voorbeeld van het ‘computerbedrijf’, zonder een systematische manier om belangrijke vraagpatronen en/of domeinkennis in de prognose vast te leggen, kan MRP dit nooit zien.

Breid ERP uit met Smart IP&O

Smart IP&O is ontworpen om uw ERP-systeem uit te breiden met een aantal geïntegreerde oplossingen voor vraagplanning en voorraadoptimalisatie. Het kan bijvoorbeeld automatisch statistische prognoses genereren voor grote aantallen artikelen, maakt intuïtieve prognoseaanpassingen mogelijk, houdt de nauwkeurigheid van prognoses bij en stelt u uiteindelijk in staat echte op consensus gebaseerde prognoses te genereren om beter te kunnen anticiperen op de behoeften van uw klanten.

Dankzij de zeer flexibele producthiërarchieën is Smart IP&O perfect geschikt voor prognoses op het niveau van de Planning BOM, zodat u belangrijke patronen kunt vastleggen en bedrijfskennis kunt integreren op de niveaus die er het meest toe doen. Bovendien kunt u op elk niveau van uw stuklijst optimale veiligheidsvoorraden analyseren en inzetten.

Wordt veiligheidsvoorraad beschouwd als noodreserve of als dagelijkse buffer tegen pieken in de vraag? Het verschil kennen en uw ERP correct configureren, zal een groot verschil maken voor uw bedrijfsresultaten.

De Safety Stock veld in je ERP systeem kan heel verschillende dingen betekenen, afhankelijk van de configuratie. Het niet begrijpen van deze verschillen en hoe ze uw winst beïnvloeden, is een veelvoorkomend probleem dat we hebben gezien bij implementaties van onze software.

Het implementeren van software voor voorraadoptimalisatie begint met nieuwe klanten die de technische implementatie voltooien om de gegevensstroom op gang te brengen. Vervolgens krijgen ze gebruikerstraining en besteden ze weken aan het zorgvuldig configureren van hun initiële veiligheidsvoorraden, bestelniveaus en consensusvraagprognoses met Smart IP&O. Het team raakt vertrouwd met Smart's Key Performance Forecasts (KPP's) voor serviceniveaus, bestelkosten en beschikbare voorraad, die allemaal worden voorspeld met behulp van het nieuwe voorraadbeleid.

Maar wanneer ze het beleid en de prognoses opslaan in hun ERP-testsysteem, zijn de voorgestelde bestellingen soms veel groter en komen ze vaker voor dan ze hadden verwacht, wat de verwachte voorraadkosten opdrijft.

Wanneer dit gebeurt, is de primaire boosdoener de manier waarop het ERP is geconfigureerd om veiligheidsvoorraad te behandelen. Door op de hoogte te zijn van deze configuratie-instellingen kunnen planningsteams de verwachtingen beter stellen en de verwachte resultaten bereiken met minder inspanning (en reden tot ongerustheid!).

Dit zijn de drie veelvoorkomende voorbeelden van configuraties van ERP-veiligheidsvoorraden:

Configuratie 1. Veiligheidsvoorraad wordt behandeld als noodvoorraad dat kan niet geconsumeerd worden. Als een inbreuk op de veiligheidsvoorraad wordt voorspeld, dwingt het ERP-systeem een spoedprocedure af, ongeacht de kosten, zodat de aanwezige voorraad nooit onder de veiligheidsvoorraad komt, zelfs als een geplande ontvangst al in bestelling is en binnenkort zal aankomen.

Configuratie 2. Veiligheidsvoorraad wordt behandeld als Buffervoorraad die is ontworpen om te worden geconsumeerd. Het ERP-systeem zal een bestelling plaatsen wanneer een inbreuk op de veiligheidsvoorraad wordt voorspeld, maar de voorhanden voorraad mag onder de veiligheidsvoorraad dalen. De buffervoorraad beschermt tegen stockout tijdens de bevoorradingsperiode (dwz de doorlooptijd).

Configuratie 3. Veiligheidsvoorraad wordt door het systeem genegeerd en behandeld als een visuele weergave planningshulp of vuistregel. Het wordt genegeerd door de berekeningen van de leveringsplanning, maar wordt door de planner gebruikt om handmatige beoordelingen te maken van wanneer er besteld moet worden.

Opmerking: we raden nooit aan om het veiligheidsvoorraadveld te gebruiken zoals beschreven in Configuratie 3. In de meeste gevallen waren deze configuraties niet bedoeld, maar het resultaat van jarenlange improvisatie die ertoe hebben geleid dat het ERP op een niet-standaard manier werd gebruikt. Over het algemeen zijn deze velden ontworpen om de aanvullingsberekeningen programmatisch te beïnvloeden. De focus van ons gesprek zal dus liggen op configuraties 1 en 2. 

Systemen voor prognoses en inventarisoptimalisatie zijn ontworpen om prognoses te berekenen die anticiperen op voorraadafname en vervolgens veiligheidsvoorraden te berekenen die voldoende zijn om bescherming te bieden tegen variabiliteit in vraag en aanbod. Dit betekent dat de veiligheidsvoorraad bedoeld is om te worden gebruikt als een beschermende buffer (configuratie 2) en niet als noodsituatie schaars (configuratie 3). Het is ook belangrijk om te begrijpen dat, door het ontwerp, de veiligheidsvoorraad zal worden geconsumeerd ongeveer 50% van die tijd.

Waarom 50%? Omdat werkelijke bestellingen de helft van de tijd een onbevooroordeelde prognose zullen overschrijden. Zie onderstaande afbeelding om dit te illustreren. Een "goede" prognose zou de waarde moeten opleveren die het dichtst bij de werkelijke vraag komt, zodat de werkelijke vraag hoger of lager zal zijn zonder vooringenomenheid in beide richtingen.

Als u uw ERP-systeem zo heeft geconfigureerd dat het verbruik van veiligheidsvoorraad correct is toegestaan, dan kan de voorhanden voorraad er uitzien zoals in de onderstaande grafiek. Houd er rekening mee dat een deel van de veiligheidsvoorraad is verbruikt, maar een stockout is vermeden. Het serviceniveau dat u nastreeft bij het berekenen van de veiligheidsvoorraad, bepaalt hoe vaak u uw voorraad moet aanvullen voordat de aanvullingsorder arriveert. De gemiddelde voorraad is in dit scenario ongeveer 60 eenheden over de tijdshorizon.

Als uw ERP-systeem is geconfigureerd om niet het verbruik van de veiligheidsvoorraad toestaat en de ingevoerde hoeveelheid in het veld voor de veiligheidsvoorraad meer behandelt als noodreserves, dan heb je een enorme overvoorraad! Uw beschikbare voorraad ziet er uit als in de onderstaande grafiek, waarbij bestellingen worden versneld zodra een inbreuk op de veiligheidsvoorraad wordt verwacht. De gemiddelde voorraad is ongeveer 90 eenheden, een toename van 50% in vergelijking met toen u toestond dat veiligheidsvoorraad werd verbruikt.

We hebben onlangs een ontmoeting gehad met het IT-team bij een van onze klanten om de gegevensvereisten en de installatie van onze API-gebaseerde integratie te bespreken die gegevens zou halen uit hun lokale installatie van hun ERP-systeem. De IT-manager en de analist uitten allebei hun grote bezorgdheid over het verstrekken van deze gegevens en vroegen zich serieus af waarom ze überhaupt moesten worden verstrekt. Ze uitten zelfs hun bezorgdheid dat hun gegevens zouden kunnen worden doorverkocht aan hun concurrentie. Hun reactie was een grote verrassing voor ons. We hebben deze blog geschreven met hen in gedachten en om het voor anderen gemakkelijker te maken om te communiceren waarom bepaalde gegevens nodig zijn om een effectief vraagplanningsproces te ondersteunen. 

Houd er rekening mee dat als u een prognoseanalist, vraagplanner of supply chain-professional bent, het meeste van wat u hieronder zult lezen voor de hand ligt. Maar wat deze bijeenkomst me heeft geleerd, is dat wat voor de ene groep specialisten vanzelfsprekend is, dat niet zal zijn voor een andere groep specialisten op een heel ander gebied. 

De vier belangrijkste soorten gegevens die nodig zijn, zijn:  

1. Historische transacties, zoals verkooporders en verzendingen.
2. Taakgebruik transacties, zoals welke componenten nodig zijn om eindproducten te produceren
3. Voorraadoverdrachttransacties, zoals welke inventaris van de ene locatie naar de andere is verzonden.
4. Prijzen, kosten en attributen, zoals de eenheidskosten betaald aan de leverancier, de eenheidsprijs betaald door de klant en verschillende metagegevens zoals productfamilie, klasse, enz.  

Hieronder volgt een korte uitleg waarom deze gegevens nodig zijn om de implementatie van software voor vraagplanning door een bedrijf te ondersteunen.

Transactiegegevens van historische verkopen en verzendingen per klant
Denk aan wat uit de inventaris werd gehaald als de "grondstof" die nodig is voor software voor vraagplanning. Dit kan zijn wat aan wie en wanneer is verkocht of wat u aan wie en wanneer hebt verzonden. Of welke grondstoffen of halffabrikaten zijn verbruikt in werkorders en wanneer. Of wat er wanneer vanuit een distributiecentrum aan een satellietmagazijn wordt geleverd.

De geschiedenis van deze transacties wordt door de software geanalyseerd en gebruikt om statistische prognoses te produceren die waargenomen patronen extrapoleren. De gegevens worden geëvalueerd om patronen zoals trend, seizoensinvloeden, cyclische patronen bloot te leggen en om potentiële uitschieters te identificeren die zakelijke aandacht vereisen. Als deze gegevens niet algemeen toegankelijk zijn of onregelmatig worden bijgewerkt, is het bijna onmogelijk om een goede voorspelling van de toekomstige vraag te maken. Ja, je zou zakelijke kennis of onderbuikgevoel kunnen gebruiken, maar dat schaalt niet en introduceert bijna altijd vertekening in de prognose (dwz consequent te hoog of te laag voorspellen). 

Er zijn gegevens nodig op transactieniveau om nauwkeurigere prognoses op wekelijks of zelfs dagelijks niveau te ondersteunen. Als een bedrijf bijvoorbeeld het drukke seizoen ingaat, wil het misschien beginnen met wekelijkse prognoses om de productie beter af te stemmen op de vraag. Dat lukt niet zonder de transactiegegevens in een goed gestructureerd datawarehouse te hebben. 

Het kan ook zo zijn dat bepaalde soorten transacties niet in de vraaggegevens moeten worden opgenomen. Dit kan gebeuren wanneer de vraag het gevolg is van een forse korting of een andere omstandigheid waarvan het supply chain-team weet dat deze de resultaten zal vertekenen. Als de gegevens geaggregeerd worden verstrekt, is het veel moeilijker om deze uitzonderingen te scheiden. Bij Smart Software noemen we het proces om uit te zoeken welke transacties (en bijbehorende transactiekenmerken) in het vraagsignaal moeten worden meegeteld "vraagsignaalsamenstelling". Door toegang te hebben tot alle transacties kan een bedrijf zijn vraagsignaal in de loop van de tijd naar behoefte aanpassen binnen de software. Slechts het verstrekken van een deel van de gegevens resulteert in een veel rigidere vraagsamenstelling die alleen kan worden verholpen met extra implementatiewerk.

Prijzen en kosten
De prijs waarvoor u uw producten heeft verkocht en de kosten die u hebt betaald om ze (of grondstoffen) te kopen, zijn van cruciaal belang om inkomsten of kosten te kunnen voorspellen. Een belangrijk onderdeel van het vraagplanningsproces is het verkrijgen van zakelijke kennis van klanten en verkoopteams. Verkoopteams denken vaak aan de vraag per klant of productcategorie en spreken in de taal van dollars. Het is dus belangrijk om een prognose in dollars uit te drukken. Het vraagplanningssysteem kan dat niet als de prognose alleen in eenheden wordt weergegeven. 

Vaak wordt de vraagprognose gebruikt om een groter planning- en budgetteringsproces aan te sturen of op zijn minst te beïnvloeden, en de belangrijkste input voor een budget is een omzetprognose. Wanneer vraagprognoses worden gebruikt om het S&OP-proces te ondersteunen, moet de software voor vraagplanning de gemiddelde prijs over alle transacties berekenen of "tijdgefaseerde" conversies toepassen die rekening houden met de op dat moment verkochte prijs. Zonder de onbewerkte gegevens over prijsstelling en kosten kan het vraagplanningsproces nog steeds functioneren, maar zal het ernstig worden belemmerd. 

Productkenmerken, klantgegevens en locaties
Productattributen zijn nodig zodat voorspellers prognoses kunnen verzamelen voor verschillende productfamilies, groepen, goederencodes, enz. Het is handig om te weten hoeveel eenheden en de totale geprojecteerde gedollariseerde vraag voor verschillende categorieën. Zakelijke kennis over wat de vraag in de toekomst zou kunnen zijn, is vaak niet bekend op productniveau, maar wel op productfamilieniveau, klantniveau of regionaal niveau. Met de toevoeging van productkenmerken aan uw datafeed voor vraagplanning, kunt u eenvoudig prognoses "oprollen" van artikelniveau naar familieniveau. U kunt prognoses op deze niveaus omzetten in dollars en beter samenwerken aan hoe de prognose moet worden aangepast.  

Zodra de kennis is toegepast in de vorm van een prognose-override, zal de software de wijziging automatisch afstemmen op alle individuele items waaruit de groep bestaat. Zo hoeft een forecast analist niet elk onderdeel apart aan te passen. Ze kunnen op geaggregeerd niveau een wijziging aanbrengen en de software voor vraagplanning de afstemming voor hen laten doen. 

Groepering voor gemakkelijke analyse is ook van toepassing op klantkenmerken, zoals een toegewezen verkoper of de voorkeurslocatie van een klant voor verzending. En locatieattributen kunnen handig zijn, zoals toegewezen regio. Soms hebben attributen betrekking op een product- en locatiecombinatie, zoals voorkeursleverancier of toegewezen planner, die voor hetzelfde product kan verschillen, afhankelijk van het magazijn.

Een laatste opmerking over vertrouwelijkheid

Bedenk dat onze klant bezorgd was dat we hun gegevens aan een concurrent zouden verkopen. Dat zouden we nooit doen. Al tientallen jaren gebruiken we klantgegevens voor trainingsdoeleinden en om onze producten te verbeteren. We zijn nauwgezet in het beschermen van klantgegevens en het anonimiseren van alles wat bijvoorbeeld kan worden gebruikt om een punt in een blogpost te illustreren.

'Ondanks wat je in je tekenfilms op zaterdagochtend hebt gezien, kunnen olifanten niet springen, en daar is een simpele reden voor: dat hoeft niet. De meeste springerige dieren – je kangoeroes, apen en kikkers – doen het voornamelijk om weg te komen van roofdieren.” — Patrick Monahan, Science.org, 27 januari 2016.

Nu weet u waarom de grootste ERP-bedrijven geen best-of-breed-achtige oplossingen van hoge kwaliteit kunnen ontwikkelen. Dat hebben ze nooit hoeven doen, dus ze zijn nooit geëvolueerd om te innoveren buiten hun kernfocus. 

Naarmate ERP-systemen echter gemeengoed zijn geworden, werden hiaten in hun functionaliteit onmogelijk te negeren. De grotere spelers probeerden hun deel van de portemonnee van de klant te beschermen door te beloven innovatieve add-on-applicaties te ontwikkelen om alle witte ruimtes te vullen. Maar zonder die 'innovatiekracht' mislukten veel projecten en stapelden zich bergen technische schulden op.

Best-of-breed bedrijven zijn geëvolueerd om te innoveren en hebben een diepgaande functionele expertise in specifieke branches. Het resultaat is dat de beste ERP-add-ons eenvoudiger te gebruiken zijn, meer functies hebben en meer waarde bieden dan de native ERP-modules die ze vervangen. 

Als uw ERP-leverancier al een samenwerking heeft aangegaan met een innovatieve, toonaangevende add-onprovider*, bent u helemaal klaar! Maar als u alleen de basis uit uw ERP kunt halen, kies dan voor een best-of-breed add-on die op maat is geïntegreerd met het ERP. 

Een goede plek om te beginnen met zoeken is om te zoeken naar add-ons voor ERP-vraagplanning die hersens toevoegen aan de kracht van het ERP, dat wil zeggen add-ons die voorraadoptimalisatie en vraagvoorspelling ondersteunen. Maak gebruik van aanvullende tools zoals Smart's apps voor statistische prognoses, vraagplanning en voorraadoptimalisatie om prognoses en voorraadbeleid te ontwikkelen die worden teruggekoppeld naar het ERP-systeem om dagelijkse bestellingen te stimuleren. 

*App-stores zijn een licentie voor de beste in hun soort om te verkopen aan de ERP-bedrijvenbasis - zijnde beursgenoteerde partnerschappen.

Er is één ding waar ik bijna elke dag aan herinnerd wordt bij Smart Software dat me een raadsel stelt: de meeste bedrijven begrijpen niet hoe prognoses worden gemaakt en hoe voorraadbeleid wordt bepaald. Het is een organisatorische zwarte doos. Hier is een voorbeeld van een recent verkoopgesprek:

Hoe voorspel je?
Wij gebruiken geschiedenis.

Hoe gebruik je geschiedenis?
Wat bedoel je?

Welnu, u kunt een gemiddelde nemen van het afgelopen jaar, de afgelopen twee jaar, het gemiddelde nemen van de meest recente perioden, of een ander type formule gebruiken om de prognose te genereren.
Ik ben er vrij zeker van dat we een gemiddelde van de laatste 12 maanden gebruiken.

Waarom 12 maanden in plaats van een andere hoeveelheid geschiedenis?
12 maanden is een goede hoeveelheid tijd om te gebruiken omdat het niet vertekend wordt door oudere gegevens, maar het is recent genoeg

Hoe weet je dat het nauwkeuriger is dan 18 maanden of een andere lengte van de geschiedenis te gebruiken?
We weten het niet. Wel passen we de prognoses aan op basis van feedback van sales.  

Weet u of de aanpassingen de zaken nauwkeuriger of minder nauwkeurig maken dan wanneer u alleen het gemiddelde zou gebruiken?
We weten het niet, maar zijn ervan overtuigd dat de prognoses te hoog zijn

Wat doen de voorraadkopers dan als ze denken dat de cijfers te hoog zijn?
Ze hebben veel zakelijke kennis en passen hun aankopen hierop aan

Dus, is het eerlijk om te zeggen dat ze de voorspellingen in ieder geval een deel van de tijd zouden negeren?
Ja, soms.

Hoe beslissen de kopers wanneer ze meer bestellen? Heeft u een bestelpunt of veiligheidsvoorraad gespecificeerd in uw ERP-systeem die u helpt bij het nemen van deze beslissingen?
Ja, we gebruiken een veiligheidsvoorraadveld.

Hoe wordt de veiligheidsvoorraad berekend?
Kopers bepalen dit op basis van het belang van het artikel, doorlooptijden en andere overwegingen, zoals hoeveel klanten het artikel kopen, de snelheid van het artikel en de kosten. Afhankelijk hiervan zullen ze verschillende hoeveelheden veiligheidsvoorraad bij zich hebben.

De discussie ging door. De belangrijkste afhaalmogelijkheid hier is dat wanneer je net onder het oppervlak krabt, er veel meer vragen worden onthuld dan antwoorden. Dit betekent vaak dat het voorraadplanning- en vraagprognoseproces zeer subjectief is, van planner tot planner varieert, niet goed wordt begrepen door de rest van de organisatie en waarschijnlijk reactief is. Zoals Tom Willemain heeft beschreven, is het "chaos gemaskeerd door improvisatie". Het "as-is"-proces moet volledig worden geïdentificeerd en gedocumenteerd. Alleen dan kunnen hiaten worden blootgelegd en kunnen verbeteringen worden aangebracht.   Hier is een lijst met 10 vragen die u kunt stellen dat zal het werkelijke proces van prognoses, vraagplanning en voorraadplanning van uw organisatie onthullen.