Uitleggen wat 'serviceniveau' betekent in uw voorraadoptimalisatiesoftware

Klanten vragen ons vaak waarom een kousaanbeveling "zo hoog" is. Hier is een vraag die we onlangs ontvingen:

Tijdens onze laatste teamvergadering hebben we enkele items gevonden met abnormale hiaten tussen onze huidige ROP en de door Smart voorgestelde ROP op een 99%-serviceniveau. De zorg is dat het systeem aangeeft dat het bestelpunt fors omhoog zal moeten om een 99%-serviceniveau te halen. Kunt u ons helpen de berekening te begrijpen?

Toen we de gegevens bekeken, was het voor de klant duidelijk dat de door Smart berekende ROP inderdaad klopte. We concludeerden (1) wat ze echt wilden was een veel lager doel voor het serviceniveau en (2) we hadden niet goed uitgelegd wat er werkelijk werd bedoeld met 'serviceniveau'. 

Dus, wat betekent een "99%-serviceniveau" eigenlijk? 

Als het gaat om het doel dat u invoert in uw voorraadoptimalisatiesoftware, betekent dit dat het voorraadniveau voor het artikel in kwestie een kans van 99% heeft om te kunnen vullen wat de klant nodig heeft meteen.  Als u bijvoorbeeld 50 stuks op voorraad heeft, is de kans 99% dat de volgende vraag ergens in het bereik van 0 tot 50 stuks zal vallen.

Wat onze klant bedoelde was dat 99% van de keren dat een klant een bestelling plaatste, dat ook zo was volledig geleverd binnen de door de klant opgegeven levertijd. Met andere woorden, niet per se meteen maar wanneer beloofd.  

Het is duidelijk dat hoe meer tijd u uzelf geeft om aan een klant te leveren, hoe hoger uw serviceniveau zal zijn. Maar dat onderscheid wordt vaak niet expliciet begrepen wanneer nieuwe gebruikers van voorraadoptimalisatiesoftware wat-als-scenario's uitvoeren op verschillende serviceniveaus. En dat kan tot grote verwarring leiden. Het berekenen van serviceniveaus op basis van onmiddellijke voorraadbeschikbaarheid is een hogere norm: moeilijker te halen maar veel competitiever.

Onze productieklanten geven vaak serviceniveaus aan op basis van doorlooptijden aan hun klanten, dus het is niet essentieel voor hen om direct uit het schap te leveren. Onze klanten in de distributie, Maintenance Repair and Operations (MRO) en ruimtes voor reserveonderdelen moeten daarentegen normaal gesproken dezelfde dag of binnen 24 uur verzenden. Voor hen is het een competitieve noodzaak om meteen te verzenden en dit volledig te doen.

Houd bij het invoeren van beoogde serviceniveaus met uw voorraadoptimalisatiesoftware rekening met dit onderscheid. Kies het serviceniveau op basis van het percentage van de tijd dat u de volledige voorraad direct vanaf de plank wilt verzenden.  

Geef tekorten niet de schuld aan problematische doorlooptijden.

Vertragingen in de doorlooptijd en variabiliteit in de levering zijn dagelijkse realiteit in de toeleveringsketen, maar organisaties die voorraad hebben, worden vaak verrast wanneer een leverancier te laat is. Een effectief voorraadplanningsproces omarmt dit feit en ontwikkelt beleid dat effectief rekening houdt met deze onzekerheid. Natuurlijk zullen er momenten zijn dat vertragingen in de doorlooptijd uit het niets opduiken en een tekort veroorzaken. Maar meestal zijn de tekorten het gevolg van:

  1. Het voorraadbeleid (bijv. bestelpunten, veiligheidsvoorraden en min/max-niveaus) niet vaak genoeg berekenen om veranderingen in de doorlooptijd op te vangen. 
  2. Slechte schattingen van de werkelijke doorlooptijd gebruiken, zoals alleen gemiddelden van historische ontvangsten gebruiken of vertrouwen op een offerte van een leverancier.

Kalibreer in plaats daarvan het beleid voor elk afzonderlijk onderdeel tijdens elke planningscyclus om veranderingen in de vraag en doorlooptijden op te vangen. In plaats van alleen uit te gaan van een gemiddelde doorlooptijd, simuleer je de doorlooptijden met behulp van scenario's. Op deze manier houdt het aanbevolen voorraadbeleid rekening met de waarschijnlijkheid dat doorlooptijden hoog zijn en wordt het dienovereenkomstig aangepast. Wanneer u dit doet, identificeert u de benodigde voorraadverhogingen voordat het te laat is. U genereert meer omzet en zorgt voor aanzienlijke verbeteringen in de klanttevredenheid.

Hoe gaat uw ERP-systeem om met veiligheidsvoorraad?

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.

 

How does your ERP system treat safety stock 1

 

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.

 

How does your ERP system treat safety stock 2

 

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.

 

How does your ERP system treat safety stock 3

 

Top 4 bewegingen wanneer u vermoedt dat software de voorraad opdrijft

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.

Iedereen maakt prognoses om de voorraadplanning te stimuleren. Het is alleen de vraag hoe.

Ontdek hoe prognoses worden gebruikt met deze 4 vragen.

Vaak zullen bedrijven volhouden dat ze "geen prognoses gebruiken" om voorraad te plannen. Ze gebruiken vaak methodes voor bestelpunten en worstelen met het verbeteren van tijdige levering, voorraadrotaties en andere KPI's. Hoewel ze niet denken dat wat ze doen expliciet voorspellen, gebruiken ze zeker schattingen van de toekomstige vraag om bestelpunten zoals min/max te ontwikkelen.

Ongeacht hoe het wordt genoemd, iedereen probeert de toekomstige vraag op de een of andere manier in te schatten en gebruikt deze schatting om voorraadbeleid te bepalen en bestellingen te stimuleren. Om de voorraadplanning te verbeteren en ervoor te zorgen dat u niet te veel of te weinig bestelt en grote voorraden en een opgeblazen gevoel creëert, is het belangrijk om precies te begrijpen hoe uw organisatie prognoses gebruikt. Als dit eenmaal is begrepen, kunt u beoordelen of de kwaliteit van de prognoses kan worden verbeterd.

Probeer antwoorden te krijgen op de volgende vragen. Het zal onthullen hoe prognoses in uw bedrijf worden gebruikt, zelfs als u denkt dat u geen prognoses gebruikt.

1. Is uw prognose een periode-voor-periode schatting in de loop van de tijd die wordt gebruikt om te voorspellen welke voorraad er in de toekomst zal zijn en die bestelsuggesties in uw ERP-systeem activeert?

2. Of wordt uw prognose gebruikt om een bestelpunt af te leiden, maar niet expliciet gebruikt als drijfveer per periode om bestellingen te activeren? Hier kan ik voorspellen dat we er 10 per week zullen verkopen op basis van de geschiedenis, maar we laden niet 10, 10, 10, 10, etc. in het ERP. In plaats daarvan leid ik een bestelpunt of min af dat de doorlooptijd van twee perioden dekt + een hoeveelheid buffer om te helpen beschermen tegen voorraaduitval. In dit geval bestel ik meer wanneer de voorraad op 25 komt.

3. Wordt uw prognose gebruikt als leidraad voor de planner om subjectief te helpen bepalen wanneer ze meer moeten bestellen? Hier voorspel ik er 10 per week, en ik beoordeel de voorhanden inventaris periodiek, bekijk de verwachte doorlooptijd en besluit, gezien de 40 eenheden die ik vandaag bij de hand heb, dat ik "genoeg" heb. Dus ik doe nu niets, maar kom over een week weer terug.

4. Wordt het gebruikt om raamcontracten met leveranciers op te stellen? Hier voorspel ik 10 per week en ga akkoord met een algemene inkooporder met de leverancier van 520 per jaar. De bestellingen worden vervolgens van tevoren geplaatst om eenmaal per week in hoeveelheden van 10 te arriveren totdat de algemene bestelling is verbruikt.

Zodra u de antwoorden heeft, kunt u vragen hoe de schattingen van de vraag tot stand komen. Is het een gemiddelde? Leidt het de vraag over de doorlooptijd af uit een verkoopprognose? Wordt er ergens een statistische prognose gegenereerd? Welke methodes worden overwogen? Het zal ook belangrijk zijn om te beoordelen hoe veiligheidsvoorraden worden gebruikt om te beschermen tegen variabiliteit in vraag en aanbod. Meer over dit alles in een toekomstig artikel.

 

Wat Silicon Valley Bank kan leren van Supply Chain Planning

Als je de laatste tijd je hoofd omhoog hebt gehouden, heb je misschien wat extra waanzin opgemerkt op het basketbalveld: het falen van Silicon Valley Bank. Degenen onder ons in de supply chain-wereld hebben het bankfalen misschien afgedaan als het probleem van iemand anders, maar die spijtige episode bevat ook een grote les voor ons: het belang van stresstesten die goed worden uitgevoerd.

De Washington Post onlangs verscheen een opiniestuk van Natasha Sarin met de titel “Regulators misten de problemen van Silicon Valley Bank maandenlang. Dit is waarom." Sarin schetste de tekortkomingen in het stresstestregime dat de Federal Reserve aan de bank heeft opgelegd. Een probleem is dat de stresstesten te statisch zijn. De stressfactor van de Fed voor de nominale bbp-groei was één enkel scenario met de veronderstelde waarden voor de komende 13 kwartalen (zie figuur 1). Die 13 driemaandelijkse projecties zijn misschien iemands consensus over hoe een bad hair day eruit zou zien, maar dat is niet de enige manier waarop dingen zouden kunnen verlopen. Als samenleving wordt ons geleerd een betere manier te waarderen om onvoorziene omstandigheden weer te geven telkens wanneer de National Weather Service ons geprojecteerde orkaansporen laat zien (zie figuur 2). Elk scenario, weergegeven door een lijn met een andere kleur, toont een mogelijk stormpad, waarbij de geconcentreerde lijnen het meest waarschijnlijke pad vertegenwoordigen. Door de lagere waarschijnlijkheidspaden bloot te leggen, wordt de risicoplanning verbeterd.

Bij het stresstesten van de toeleveringsketen hebben we realistische scenario's nodig van mogelijke toekomstige eisen die zich kunnen voordoen, zelfs extreme eisen. Smart voorziet hierin in onze software (met aanzienlijke verbeteringen in onze Gen2 methodes). De software genereert een groot aantal geloofwaardige vraagscenario's, genoeg om de volledige omvang van de risico's bloot te leggen (zie figuur 3). Stresstesten hebben alles te maken met het genereren van enorme aantallen planningsscenario's, en de probabilistische methoden van Smart wijken radicaal af van eerdere deterministische S&OP-toepassingen, omdat ze volledig op scenario's zijn gebaseerd.

De andere fout in de stresstests van de Fed was dat ze maanden van tevoren waren ontworpen, maar nooit werden bijgewerkt voor veranderende omstandigheden. Vraagplanners en voorraadbeheerders begrijpen intuïtief dat sleutelvariabelen zoals de vraag naar artikelen en de doorlooptijd van leveranciers niet alleen zeer willekeurig zijn, zelfs wanneer de zaken stabiel zijn, maar ook onderhevig zijn aan abrupte verschuivingen die een snelle herschrijving van planningsscenario's vereisen (zie afbeelding 4, waar de gemiddelde vraag springt dramatisch omhoog tussen waarnemingen 19 en 20). Smart's Gen2-producten bevatten nieuwe technologie voor het detecteren van dergelijke "regime verandert' en dienovereenkomstig automatisch veranderende scenario's.

Banken worden gedwongen om stresstests te ondergaan, hoe gebrekkig ze ook mogen zijn, om hun spaarders te beschermen. Supply chain-professionals hebben nu een manier om hun supply chains te beschermen door moderne software te gebruiken om hun vraagplannen en voorraadbeheerbeslissingen aan een stresstest te onderwerpen.

1 Scenarios used the Fed to stress test banks Software

Figuur 1: Scenario's die de Fed gebruikte om banken te stresstesten.

 

2 Scenarios used by the National Weather Service to predict hurricane tracks

Figuur 2: Scenario's die door de National Weather Service worden gebruikt om orkaansporen te voorspellen

 

3 Demand scenarios of the type generated by Smart Demand Planner

Afbeelding 3: Vraagscenario's van het type gegenereerd door Smart Demand Planner

 

4 Example of regime change in product demand after observation #19

Figuur 4: Voorbeeld van regimeverandering in productvraag na observatie #19