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.

Er wordt ons vaak gevraagd: "Waarom drijft de software de voorraad op?" Het antwoord is dat Smart het in geen van beide richtingen stuurt - de inputs sturen het aan en die inputs worden beheerd door de gebruikers (of beheerders). Hier zijn vier dingen die u kunt doen om de resultaten te krijgen die u verwacht.

1. Bevestig dat uw serviceniveaudoelen in overeenstemming zijn met wat u wilt voor dat artikel of die groep artikelen. Het instellen van zeer hoge doelen (95% of meer) zal waarschijnlijk de inventaris verhogen als je op een lager niveau hebt rondgereden en het goed vindt om daar te zijn. Het is mogelijk dat u het nieuwe, hogere serviceniveau nog nooit heeft bereikt, maar klanten hebben niet geklaagd. Zoek uit welk serviceniveau heeft gewerkt door historische prestatierapporten te evalueren en stel uw doelen dienovereenkomstig vast. Houd er echter rekening mee dat concurrenten u kunnen verslaan op het gebied van artikelbeschikbaarheid als u de serviceniveaudoelstellingen van uw vader blijft gebruiken.

2. Zorg ervoor dat uw begrip van "serviceniveau" overeenkomt met de definitie van het softwaresysteem. Mogelijk meet u de prestaties op basis van hoe vaak u verzendt binnen een week na ontvangst van de bestelling van de klant, terwijl de software zich richt op bestelpunten op basis van uw vermogen om meteen te verzenden, niet binnen een week. Het is duidelijk dat de laatste meer inventaris nodig heeft om hetzelfde "serviceniveau" te bereiken. Een 75%-serviceniveau voor dezelfde dag kan bijvoorbeeld overeenkomen met een 90%-serviceniveau voor dezelfde week. In dit geval ben je echt appels met peren aan het vergelijken. Als dit de reden is voor de overtollige voorraad, bepaal dan welk serviceniveau "dezelfde dag" nodig is om u op het door u gewenste serviceniveau "dezelfde week" te krijgen en voer dat in de software in. Het gebruik van het minder strikte doel voor dezelfde dag zal de inventaris doen dalen, soms zeer aanzienlijk.

3. Evalueer de invoer van de doorlooptijd. We hebben gevallen gezien waarin doorlooptijden waren opgeblazen om oude software te misleiden om de gewenste resultaten te produceren. Moderne software houdt de prestaties van leveranciers bij door hun werkelijke doorlooptijden over meerdere bestellingen vast te leggen, en houdt vervolgens rekening met de doorlooptijdvariabiliteit in simulaties van dagelijkse activiteiten. Pas op als uw doorlooptijden zijn vastgesteld op een waarde die in het verre verleden is bepaald en niet actueel is.

4. Controleer uw vraagsignaal. U heeft veel historische transacties in uw ERP-systeem die op veel manieren kunnen worden gebruikt om de vraaghistorie te bepalen. Als u signalen gebruikt zoals overboekingen, of als u retouren niet uitsluit, overdrijft u mogelijk de vraag. Besteed wat tijd aan het definiëren van "vraag" op de manier die het meest logisch is voor uw situatie.

Buiten het werk heb je misschien de beroemde uitspraak 'Correlatie is geen oorzakelijk verband' gehoord. Het klinkt misschien als een stuk theoretische onzin die, hoewel betrokken bij een recente Nobelprijs voor economie, niet relevant is voor uw werk als vraagplanner. Is dat zo, dan heb je misschien maar gedeeltelijk gelijk.

Extrapolatieve versus causale modellen

De meeste vraagvoorspellingen maken gebruik van extrapolatieve modellen. Deze modellen, ook wel tijdreeksmodellen genoemd, voorspellen de vraag op basis van alleen de waarden uit het verleden van de vraag naar een artikel. Plots van waarden uit het verleden onthullen trend en seizoensgebondenheid en volatiliteit, dus er is veel waar ze goed voor zijn. Maar er is nog een ander type model – causale modellen – dat de nauwkeurigheid van prognoses mogelijk kan verbeteren, verder dan wat u kunt krijgen van extrapolatieve modellen.

Causale modellen voegen meer invoergegevens toe aan de prognosetaak: informatie over veronderstelde prognose "stuurprogramma's" buiten de vraaggeschiedenis van een artikel. Voorbeelden van potentieel bruikbare oorzakelijke factoren zijn onder meer macro-economische variabelen zoals het inflatiepercentage, het groeipercentage van het bbp en grondstofprijzen. Voorbeelden die niet gebonden zijn aan de nationale economie zijn onder meer branchespecifieke groeipercentages en uw eigen advertentie-uitgaven en die van uw concurrenten. Deze variabelen worden meestal gebruikt als invoer voor regressiemodellen, dit zijn vergelijkingen met vraag als uitvoer en causale variabelen als invoer.

Voorspellingen met behulp van causale modellen

Veel bedrijven hebben een S&OP-proces waarbij maandelijks statistische (extrapolatieve) prognoses worden beoordeeld, waarbij het management de prognoses aanpast op basis van hun oordeel. Vaak is dit een indirecte en subjectieve manier om causale modellen in het proces te verwerken zonder de regressiemodellering uit te voeren.

Om daadwerkelijk een causaal regressiemodel te maken, moet u eerst een lijst van potentieel bruikbare causale voorspellende variabelen nomineren. Deze kunnen voortkomen uit uw inhoudelijke expertise. Stel, u vervaardigt vensterglas. Veel van uw glas kan terechtkomen in nieuwe woningen en nieuwe kantoorgebouwen. Het aantal nieuw gebouwde woningen en kantoren zijn dus plausibele voorspellende variabelen in een regressievergelijking.

Er is hier een complicatie: als je de vergelijking gebruikt om iets te voorspellen, moet je eerst de voorspellers voorspellen. Zo kan de verkoop van glas komend kwartaal sterk gerelateerd zijn aan aantallen nieuwe woningen en nieuwe kantoorpanden komend kwartaal. Maar hoeveel nieuwe woningen komen er komend kwartaal? Dat is zijn eigen prognoseprobleem. Je hebt dus een potentieel krachtig prognosemodel, maar je hebt extra werk te doen om het bruikbaar te maken.

Er is één manier om dingen te vereenvoudigen: als de voorspellende variabelen "vertraagde" versies van zichzelf zijn. Zo kan het aantal nieuw afgegeven bouwvergunningen een half jaar geleden een goede voorspeller zijn van de glasverkoop volgende maand. U hoeft de bouwvergunninggegevens niet te voorspellen, u hoeft ze alleen maar op te zoeken.

Is het een causaal verband of slechts een onechte correlatie?

Causale modellen zijn de real deal: er is een feitelijk mechanisme dat de voorspellende variabele relateert aan de voorspelde variabele. Het voorbeeld van het voorspellen van de verkoop van glas uit bouwvergunningen is een voorbeeld.

Een correlatierelatie is twijfelachtiger. Er is een statistische associatie die al dan niet een solide basis vormt voor prognoses. Stel, u verkoopt een product dat Nederlanders het meest aanspreekt, maar u heeft dit niet door. Nederlanders zijn gemiddeld de langste mensen van Europa. Als uw verkopen stijgen en de gemiddelde lengte van Europeanen toeneemt, kunt u die relatie goed gebruiken. Maar als het aandeel Nederlanders in de eurozone afneemt terwijl de gemiddelde lengte toeneemt omdat de mix van mannen versus vrouwen naar mannen verschuift, wat kan er dan misgaan? U verwacht dat de verkoop zal toenemen omdat de gemiddelde lengte toeneemt. Maar uw verkopen zijn eigenlijk vooral aan Nederlanders, en hun relatieve aandeel in de bevolking wordt kleiner, dus uw verkopen zullen in plaats daarvan echt afnemen. In dit geval is de associatie tussen verkoop en klantlengte een onechte correlatie.

Hoe kun je het verschil zien tussen echte en valse relaties? De gouden standaard is om een rigoureus wetenschappelijk experiment te doen. Maar u bent waarschijnlijk niet in de positie om dat te doen. In plaats daarvan moet u vertrouwen op uw persoonlijke 'mentale model' van hoe uw markt werkt. Als uw vermoedens juist zijn, zullen uw potentiële causale modellen correleren met de vraag en zal causale modellering voor u lonend zijn, hetzij als aanvulling op extrapolatieve modellen, hetzij ter vervanging ervan.

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.