We werken samen met veel klanten in veel sectoren om onze geavanceerde software voor analyse, prognoses en voorraadplanning te verbinden met hun ERP-systemen. Ondanks de verscheidenheid aan situaties die we tegenkomen, hebben sommige gegevensgerelateerde problemen de neiging om keer op keer de kop op te steken. In deze blog staan tien tips die je kunnen helpen om deze veelvoorkomende problemen te voorkomen.

Zodra een klant klaar is om software voor vraagplanning en/of voorraadoptimalisatie te implementeren, moet hij de analysesoftware aansluiten op zijn bedrijfsgegevensstroom. In ons geval verwerken we transactiegegevens rechtstreeks in de analytische software. Dit geeft onder meer informatie over de vraag naar artikelen en de doorlooptijden van leveranciers. We halen de rest van de gegevens uit het ERP-systeem zelf, dat metagegevens levert zoals de locatie van elk artikel, de kostprijs per eenheid en de productgroep.

Deze tips zijn belangrijk omdat het niet ongebruikelijk is dat implementatieprojecten met veel enthousiasme beginnen, maar al snel vastlopen door problemen met de gegevens die de analyse voeden. Deze vertragingen kunnen het teamenthousiasme verminderen, projectleiders in verlegenheid brengen en de ROI-uitbetaling vertragen (en daardoor verminderen) die uiteindelijk het implementatieproject rechtvaardigde.

Het belang van het verbinden van de analysesoftware met de bedrijfsgegevensstroom

Hier is de lijst met tips, gegroepeerd op basis van de algemene thema's veilig omgaan met bestanden, waarborgen van gegevensintegriteit en omgaan met uitzonderingen.

Veilig omgaan met bestanden

1. Zorg voor een testomgeving die u als 'sandbox' kunt gebruiken. Kopieer uw huidige gegevens naar een testomgeving waar u veilig kunt experimenteren met de software zonder de huidige bewerkingen te riskeren. Naast het helpen van gebruikers om de ins en outs van de nieuwe software te leren, stelt het hebben van de nieuwste gegevens in de software eindgebruikers in staat eventuele problemen met de gegevens te ontdekken.

2. Bescherm uw regels voor gegevensextractie. Als u geen gebruik maakt van een kant-en-klare connector voor uw ERP-systeem dan moet u ervoor zorgen dat u bewaarbare uittrekregels kunt maken om gegevens van uw ERP naar een bestand te verplaatsen. Kolomvolgorde, gegevenstypen, datumnotaties, enz. mogen niet elke keer dat hetzelfde extract opnieuw wordt uitgevoerd, variëren. Anders loopt het project vast in handmatige fouten of verwarring bij het opnieuw uitpakken na fixes van de gegevens of wanneer nieuwe gegevens binnenkomen. Alle regels voor gegevensextractie moeten worden opgeslagen en beschikbaar zijn voor IT - we zijn situaties tegengekomen waarin bestanden werden geëxtraheerd. op ad hoc wijze resulterend in een iets ander formaat bij elk nieuw uittreksel. We hebben ook gezien dat klanten hard werkten aan het ontwikkelen van een complexe en nauwkeurige routine voor het extraheren van gegevens, waarna ze ontdekten dat al hun werk verloren was gegaan toen het niet goed was gearchiveerd. Beide situaties leidden tot verwarring en projectvertragingen.

3. Gebruik geen native bestandsindelingen van Excel voor gegevensoverdracht. Als uw planningsoplossing geen directe integratie met uw ERP-systeem heeft, exporteer dan ERP-gegevens naar een platte bestandsindeling, zoals door komma's gescheiden bestanden (.csv) of door tabs gescheiden tekstbestanden. Gebruik geen MS Excel-indelingen zoals .xls of .xlsx als het exportbestandstype omdat Excel automatisch veldwaarden op onverwachte manieren opnieuw opmaakt. Veel gebruikers gaan ervan uit dat ze .xlsx-bestanden moeten gebruiken als ze ze handmatig willen bekijken, zich niet realiserend dat .csv- of .txt-bestanden net zo gemakkelijk kunnen worden geopend en niet het risico met zich meebrengen dat ze automatisch opnieuw worden geformatteerd.

Gegevensintegriteit verzekeren

Gegevensproblemen en oplossingen bij software-implementatie. Hier is de lijst met tips, gegroepeerd op basis van de algemene thema's veilig omgaan met bestanden, waarborgen van gegevensintegriteit en omgaan met uitzonderingen.

4. Bevestig de juistheid van uw catalogusgegevens. Exporteer uw catalogusgegevens (dwz lijst met producten, lijst met klanten, lijst met leveranciers) en al hun relevante attributen. Controleer op verkeerde of verdachte waarden in de attributen (vooral doorlooptijden en kosten van artikelen). Problematische waarden zijn spaties, nullen als u geen nul als gegevenswaarde verwacht, en tekenreeksen als u numerieke waarden verwacht (of vice versa). Het kan helpen om elk extractbestand in Excel te openen en op elk attribuutveld te filteren, kijkend naar de unieke waarden om te zien wat eruit springt als niet zoals de andere (bijv. "1", "2", "&&", "3" …).

5. Bevestig de juistheid van uw groeperingsgegevens. Een andere nuttige activiteit die kan worden uitgevoerd tijdens het bekijken van de productcatalogusgegevens in Excel, is het controleren van belangrijke groeperings-/filtervelden zoals productfamilie, categorie of klasse om er zeker van te zijn dat er geen producten zijn toegewezen aan de verkeerde categorie, klasse of familie. Controleer ook alle velden voor productstatus/productlevenscyclus, zorg er bijvoorbeeld voor dat u alle stopgezette producten correct hebt geïdentificeerd.

6. Controleer op valse controletekens in tekstvelden. Controleer of er geen ongebruikelijke tekens in uw productbeschrijvingen zijn geëxtraheerd, zoals regelterugloop of tabs in de beschrijvingswaarde zelf. Als dat het geval is, zorg er dan voor dat u die gegevens kunt extraheren door tussenvoegsels met dubbele aanhalingstekens rond de beschrijving te gebruiken, of herstel fouten bij het invoeren van gegevens rechtstreeks in het ERP-systeem.

7. Controleer of de gegevens een standaardlay-out hebben. Controleer of uw uittreksels van transactiegegevens (bijv. klantorders, klantverzendingen, inkooporders, leveranciersbonnen) geen dubbele rijen bevatten. Als dat het geval is, identificeert u welke velden moeten worden toegevoegd om de rijen onderscheidend te maken of, als het echte duplicaten zijn, verwijdert u de extra exemplaren in de ERP-database.

Omgaan met uitzonderingen

8. Detecteer en reageer op uitzonderingen. Identificeer alle kenmerken van transactiegegevens die zouden betekenen dat ze niet zouden moeten worden gebruikt, zoals geannuleerde bestellingen. Begrijp het proces rond verkeerd ingevoerde bestellingen of geannuleerde bestellingen om ervoor te zorgen dat dit soort transacties niet worden geteld of dubbel geteld. Let op andere gegevensattributen die zouden impliceren dat dat attribuut niet mag worden gebruikt, zoals dropshipping rechtstreeks van een leverancier naar de klant in plaats van het vanuit uw eigen bedrijf te verzenden. 

9. Codificeer de afhandeling van uitzonderlijke interne overboekingen. Definieer het geïdealiseerde record van interne voorraadoverdrachten in noodgevallen en geef vervolgens regels voor het bewerken van transacties die op noodbasis zijn uitgevoerd en die afwijken van het ideale patroon. Als bijvoorbeeld product P1 zou moeten worden verzonden vanuit locatie A, maar er was een noodverzending vanuit locatie B, wordt de vraaggeschiedenis voor P1 op locatie A gekaapt en minder dan het had moeten zijn. Geef indien mogelijk een regel op voor de gewenste verzendlocatie voor elk product, zodat de geschiedenis kan worden gecorrigeerd door de voorraadoptimalisatiesoftware voor prognosedoeleinden.

10. Bedenk een procedure om vervanging af te handelen. Vervangingen doen zich bijvoorbeeld voor bij het adopteren van een nieuw ERP-systeem dat de producten opnieuw indexeert, of een oud product wordt vervangen door een bijgewerkte versie, of een geheel nieuw product veroudert en het oude. Als product-ID's om welke reden dan ook in de afgelopen paar jaar zijn gewijzigd, identificeer dan een mapping van de oude product-ID naar de nieuwe. Deze regels moeten beschikbaar zijn voor het vraagplannings- en prognosesysteem en kunnen worden bewerkt binnen de applicatie.

Het niet anticiperen op dataproblemen vormt een grote belemmering voor een soepele implementatie van nieuwe analytische software. Geen enkele lijst kan alle vreemde dingen opsommen die fout kunnen gaan bij het verzamelen van gegevens, maar deze lijst belicht veelvoorkomende problemen en verstandige antwoorden.

Opmerking: voor meer informatie over hoe gegevensproblemen de toepassing van geavanceerde analytische software kunnen belemmeren, zie de uitstekende blog van Sean Snapp over hoe dit probleem de toepassing van kunstmatige intelligentie en machine learning belemmert.  https://www.brightworkresearch.com/demandplanning/2019/05/how-many-ai-projects-will-fail-due-to-a-lack-of-data/

In een andere blog we stelden de vraag: hoe weet je zeker dat je echt een beleid hebt voor voorraadplanning en vraagprognoses? We legden uit hoe het gebrek aan begrip van een organisatie over de basisprincipes (hoe een prognose tot stand komt, hoe veiligheidsvoorraadbuffers worden bepaald en hoe/waarom deze waarden worden aangepast) bijdraagt aan slechte prognosenauwkeurigheid, verkeerd toegewezen voorraad en gebrek aan vertrouwen in het geheel Verwerken.

In deze blog bekijken we 10 specifieke vragen die u kunt stellen om erachter te komen wat er echt speelt in uw bedrijf. We beschrijven de typische antwoorden die worden gegeven wanneer er niet echt een beleid voor prognoses/voorraadplanning bestaat, leggen uit hoe deze antwoorden moeten worden geïnterpreteerd en geven duidelijk advies over wat u eraan kunt doen.

Begin altijd met een simpele hypothetisch voorbeeld. Als u zich concentreert op een specifiek probleem dat u zojuist hebt ervaren, zal dit ongetwijfeld defensieve antwoorden uitlokken die het volledige verhaal verbergen. Het doel is om de daadwerkelijke benadering te ontdekken die wordt gebruikt om inventaris en prognoses te plannen die in de mentale wiskunde of spreadsheets is ingebakken. Hier is een voorbeeld:

Stel dat u 100 eenheden bij de hand heeft, de doorlooptijd om aan te vullen 3 maanden is en de gemiddelde maandelijkse vraag 20 eenheden is? Wanneer bestel je meer? Hoeveel zou jij bestellen? Hoe zal uw antwoord veranderen als de verwachte ontvangsten van 10 per maand zouden aankomen? Hoe verandert uw antwoord als het artikel een A-, B- of C-artikel is, de prijs van het artikel hoog of laag is, de doorlooptijd van het artikel lang of kort is? Simpel gezegd, wanneer u een productietaak plant of een nieuwe bestelling plaatst bij een leverancier, waarom deed u dat dan? Wat was de aanleiding voor de beslissing om meer te krijgen? Welke planningsinputs werden overwogen?

Wanneer u antwoorden op de bovenstaande vraag krijgt, concentreer u dan op het vinden van antwoorden op de volgende vragen:

1. Wat is de onderliggende aanvullingsbenadering? Dit is meestal een van Min/Max, prognose/veiligheidsvoorraad, bestelpunt/bestelhoeveelheid, periodieke beoordeling/bestelling tot of zelfs een vreemde combinatie

2. Hoe worden de planningsparameters, zoals vraagprognoses, bestelpunten of Min/Max, daadwerkelijk berekend? Het is niet voldoende om te weten dat u Min/Max gebruikt. U moet precies weten hoe deze waarden worden berekend. Antwoorden als “We gebruiken geschiedenis” of “We gebruiken een gemiddelde” zijn niet specifiek genoeg. U hebt antwoorden nodig die duidelijk aangeven hoe geschiedenis wordt gebruikt. Bijvoorbeeld, “We nemen een gemiddelde van de afgelopen 6 maanden, delen dat door 30 om een daggemiddelde te krijgen en vermenigvuldigen dat met de doorlooptijd in dagen. Voor 'A'-artikelen vermenigvuldigen we vervolgens de gemiddelde doorlooptijd met 2 en voor 'B'-artikelen gebruiken we een vermenigvuldiger van 1,5.” (Hoewel dat geen bijzonder goede technische benadering is, heeft het tenminste een duidelijke logica.)

Zodra u een goed gedefinieerd beleid heeft, kunt u de zwakke punten identificeren om het te verbeteren. Maar als het gegeven antwoord niet veel verder komt dan “We gebruiken geschiedenis”, dan heb je geen beleid om mee te beginnen. Uit antwoorden blijkt vaak dat verschillende planners geschiedenis op verschillende manieren gebruiken. Sommigen houden alleen rekening met de meest recente vraag, anderen slaan misschien in op basis van het gemiddelde van de perioden met de hoogste vraag, enz. Met andere woorden, het kan zijn dat u in feite meerdere ondoordachte "polissen" heeft.

3. Worden prognoses gebruikt om de bevoorradingsplanning aan te sturen en, zo ja, hoe? Veel bedrijven zullen zeggen dat ze voorspellen, maar hun prognoses worden op een andere manier berekend en gebruikt. Wordt de prognose gebruikt om te voorspellen welke voorraad er in de toekomst zal zijn, waardoor een order wordt geactiveerd? Of wordt het gebruikt om een bestelpunt af te leiden, maar niet om te voorspellen wanneer ik moet bestellen (dat wil zeggen, ik voorspel dat we er 10 per week zullen verkopen, dus om te helpen voorkomen dat de voorraad op is, zal ik meer bestellen als de voorraad op 15 komt)? Wordt het gebruikt als een leidraad voor de planner om subjectief te helpen bepalen wanneer ze meer moeten bestellen? Wordt het gebruikt om raamcontracten met leveranciers op te stellen? Sommigen gebruiken het om MRP aan te drijven. U moet deze details kennen. Een grondig antwoord op deze vraag zou er als volgt uit kunnen zien: “Mijn voorspelling is 10 per week en mijn doorlooptijd is 3 weken, dus ik maak mijn bestelpunt een veelvoud van die voorspelling, meestal 2 x de doorlooptijdvraag of 60 eenheden voor belangrijke artikelen en ik gebruik een kleiner veelvoud voor minder belangrijke artikelen. (Nogmaals, geen geweldige technische benadering, maar duidelijk.)

4. Welke techniek wordt eigenlijk gebruikt om de prognose te genereren? Is het een gemiddelde, een trending model zoals dubbele exponentiële afvlakking, een seizoensmodel? Hangt de keuze van de techniekverandering af van het type vraaggegevens of wanneer er nieuwe vraaggegevens beschikbaar zijn? (Reserveonderdelen en artikelen met een hoog volume hebben zeer verschillende vraagpatronen.) Hoe kiest u het prognosemodel? Is dit proces geautomatiseerd? Hoe vaak wordt de modelkeuze heroverwogen? Hoe vaak worden de modelparameters opnieuw berekend? Wat is het proces dat wordt gebruikt om uw aanpak te heroverwegen? Het antwoord documenteert hier hoe de basisprognoses tot stand komen. Eenmaal bepaald, kunt u een analyse uitvoeren om te bepalen of andere prognosemethoden zouden verbeteren nauwkeurigheid van de voorspelling. Als u de nauwkeurigheid van de prognoses niet documenteert en geen analyse van de toegevoegde waarde van de prognose uitvoert, bent u niet in staat om goed te beoordelen of de geproduceerde prognoses de beste zijn die ze kunnen zijn. U loopt kansen mis om het proces te verbeteren, de nauwkeurigheid van prognoses te vergroten en het bedrijf te informeren over welk type prognosefout normaal is en moet worden verwacht.

5. Hoe gebruik je veiligheidsvoorraad? Merk op dat de vraag niet was: "Gebruikt u veiligheidsvoorraad?" In deze context, en om het simpel te houden, betekent de term "veiligheidsvoorraad" voorraad die wordt gebruikt om voorraad te bufferen tegen variabiliteit van vraag en aanbod. Alle bedrijven gebruiken op de een of andere manier buffermethoden. Er zijn echter enkele uitzonderingen. Misschien bent u een werkplaatsfabrikant die alle onderdelen op bestelling aanschaft en vinden uw klanten het helemaal prima om weken of maanden op u te wachten om materiaal te vinden, te produceren, QA te leveren en te verzenden. Of misschien bent u een grote fabrikant met tonnen koopkracht, zodat uw leveranciers lokale magazijnen opzetten die volledig gevuld zijn en klaar om u vrijwel onmiddellijk van voorraad te voorzien. Als deze beschrijvingen uw bedrijf niet beschrijven, heeft u zeker een soort buffer om u te beschermen tegen variabiliteit in vraag en aanbod. U gebruikt het veld "veiligheidsvoorraad" misschien niet in uw ERP, maar u bent zeker aan het bufferen.

Er kunnen antwoorden worden gegeven zoals "We gebruiken geen veiligheidsvoorraad omdat we prognoses maken." Helaas, een goede voorspelling zal een 50/50 kans hebben om boven/onder de daadwerkelijke vraag te zijn. Dit betekent dat u 50% van de tijd een voorraad krijgt zonder dat er een veiligheidsvoorraadbuffer aan de prognose is toegevoegd. Voorspellingen zijn alleen perfect als er geen willekeur is. Aangezien er altijd willekeur is, moet u bufferen als u geen bodemloze serviceniveaus wilt hebben.

Als het antwoord niet wordt onthuld, kunt u wat meer onderzoeken hoe de verschillende aanvullingshendels worden gebruikt om mogelijke buffers toe te voegen, wat leidt tot vragen 6 en 7.

6. Verlengt u wel eens de doorlooptijd of bestelt u wel eens eerder dan nodig is?
In ons hypothetische voorbeeld heeft uw leverancier doorgaans 4 weken nodig om te leveren en is redelijk consistent. Maar om u te beschermen tegen stockouts, bestelt uw koper routinematig 6 weken uit in plaats van 4 weken. Het veiligheidsvoorraadveld in uw ERP-systeem staat misschien op nul omdat "we geen veiligheidsvoorraad gebruiken", maar in werkelijkheid heeft de bestelbenadering van de koper zojuist 2 weken buffervoorraad toegevoegd.

7. Vult u de vraagprognose in?
In ons voorbeeld verwacht de planner 10 eenheden per maand te verbruiken, maar "voor het geval dat" een prognose van 20 per maand invoert. Het veiligheidsvoorraadveld in het MRP-systeem is blanco gelaten, maar de nu vermomde buffervoorraad is de vraagprognose binnengesmokkeld. Dit is een fout die 'voorspellingsbias' introduceert. Niet alleen zullen uw prognoses minder nauwkeurig zijn, maar als er geen rekening wordt gehouden met de vertekening en de veiligheidsvoorraad wordt toegevoegd door andere afdelingen, zult u te veel bevoorraden.

Het ad-hockarakter van de bovenstaande benaderingen verergert de problemen door geen rekening te houden met de daadwerkelijke vraag of het aanbod variabiliteit van het artikel. De planner kan bijvoorbeeld gewoon een vuistregel maken die de doorlooptijdprognose voor belangrijke artikelen verdubbelt. Eén maat past niet allemaal als het gaat om voorraadbeheer. Deze benadering zal de voorspelbare artikelen substantieel overbevoorraden, terwijl de periodiek gevraagde artikelen substantieel onderbezet zijn. Jij kunt lezen "Pas op voor eenvoudige vuistregels voor voorraadbeheer” om meer te weten te komen over waarom dit soort aanpak zo kostbaar is.

De ad-hoc aard van de benaderingen negeert ook wat er gebeurt als het bedrijf wordt geconfronteerd met een enorme overstock of stock out. Bij het proberen te begrijpen wat er is gebeurd, zal het vermelde beleid worden onderzocht. In het geval van een overstock zal het systeem een veiligheidsvoorraad nul tonen. De bedrijfsleiders zullen aannemen dat ze geen veiligheidsvoorraad bij zich hebben, hun hoofd krabben en uiteindelijk de voorspelling de schuld geven, verklaren "Ons bedrijf kan niet worden voorspeld" en strompelen verder. Ze kunnen de leverancier zelfs de schuld geven voor het te vroeg verzenden en ervoor zorgen dat ze meer vasthouden dan nodig is. In het geval dat de voorraad op is, denken ze dat ze niet genoeg op voorraad hebben en voegen ze willekeurig meer voorraad toe aan veel items, zonder zich te realiseren dat er in feite veel extra veiligheidsvoorraad in het proces is ingebakken. Dit maakt het waarschijnlijker dat voorraden in de toekomst moeten worden afgeschreven.

8. Wat is de exacte inventaristerminologie die wordt gebruikt? Definieer wat u bedoelt met veiligheidsvoorraad, Min, bestelpunt, EOQ, enz. Hoewel er standaard technische definities het is mogelijk dat er iets anders is, en miscommunicatie zal hier problematisch zijn. Sommige bedrijven verwijzen bijvoorbeeld naar Min als de hoeveelheid voorraad die nodig is om aan de doorlooptijdvraag te voldoen, terwijl sommigen Min definiëren als inclusief zowel doorlooptijdvraag als veiligheidsvoorraad om te bufferen tegen vraagvariabiliteit. Anderen kunnen de minimale bestelhoeveelheid betekenen.

9. Is de aanwezige voorraad in overeenstemming met het beleid? Wanneer uw detectivewerk is voltooid en alles is gedocumenteerd, opent u uw spreadsheet of ERP-systeem en bekijkt u de beschikbare hoeveelheid. Het zou min of meer in overeenstemming moeten zijn met uw planningsparameters (dwz als Min/Max 20/40 is en de typische doorlooptijdvraag 10 is, dan zou u op elk moment ongeveer 10 tot 40 eenheden bij de hand moeten hebben. Verrassend genoeg, voor veel bedrijven is er vaak een enorme inconsistentie. We hebben situaties waargenomen waarin de min/max-instelling 20/40 is, maar de voorhanden voorraad 300+ is. Dit geeft aan dat het beleid dat is voorgeschreven gewoon niet wordt gevolgd. Dat is een groter probleem.

10. Wat ga je nu doen?

Vraagprognoses en voorraadopslagbeleid moeten goed gedefinieerde processen zijn die door alle betrokkenen worden begrepen en geaccepteerd.  Er zou nul mysterie moeten zijn.

Om dit goed te doen, moeten de vraag- en aanbodvariabiliteit worden geanalyseerd en gebruikt om de juiste niveaus van veiligheidsvoorraad te berekenen. Buffers toevoegen zonder een impliciet begrip van wat elke extra eenheid buffervoorraad u oplevert in termen van service, is als willekeurig een handvol ingrediënten in een cakerecept gooien. Een kleine verandering in ingrediënten kan een enorme impact hebben op wat er uit de oven komt: de ene hap is te zoet, de volgende te zuur. Zo is het ook met voorraadbeheer. Een beetje extra hier, een beetje minder daar, en al snel zit je met kostbare overtollige voorraad in sommige gebieden, pijnlijke tekorten in andere, geen idee hoe je daar bent gekomen, en met weinig begeleiding om dingen beter te maken.

Modern Inventory optimization en software voor vraagplanning met zijn geavanceerde analyses en sterke basis in prognoseanalyse kan veel helpen bij dit probleem. Maar zelfs de beste software helpt niet als deze inconsistent wordt gebruikt.

Het testen van softwareoplossingen via een reeks empirische competities kan een aanzienlijke optie zijn. Voor prognoses/vraagplanning is dit een traditionele “hold out”-test waarbij gegevens voor 2014-2018 worden verstrekt aan softwareleveranciers en 2019 wordt aangehouden voor latere vergelijking met prognoses van concurrerende leveranciers. Het bedrijf meet vervolgens prognosefouten en vooringenomenheid. Deze benadering wordt bijna universeel aanbevolen voor het beoordelen van de nauwkeurigheid van prognoses. Het is een goede manier om de nauwkeurigheid van maandelijkse of wekelijkse prognoses te beoordelen, maar het is minimaal nuttig als u een ander doel heeft: voorraad optimaliseren.

In onze vorige blog hebben we het erover gehad hoe u een gericht serviceniveau kiest. We hebben aangegeven dat het feit dat je een doel stelt (of een systeem een doel aanbeveelt) niet betekent dat je het doel ook daadwerkelijk zult bereiken. De juiste manier om nauwkeurigheid te meten als u geïnteresseerd bent in het optimaliseren van voorraadniveaus, is door u te concentreren op de nauwkeurigheid van de projectie van het serviceniveau. Dit houdt rekening met zowel de doorlooptijdvraag als de veiligheidsvoorraad.

Een instellen beoogde serviceniveau is een strategische beslissing over voorraadrisicobeheer. Voorraadsoftware doet het tactische werk door herordeningspunten (ook wel minuten genoemd) te berekenen die bedoeld zijn om een door de gebruiker gedefinieerd doel te bereiken of om een door het systeem berekend optimaal doel te bereiken. Maar als de software het verkeerde vraagmodel gebruikt, kan de bereikte servicegraad zal het doel missen, soms aanzienlijk. Het resultaat van deze fout is ofwel een tekort ofwel een opgeblazen voorraad, afhankelijk van de richting van de misser.

Prognoses zijn een middel om een doel te bereiken. Het doel is om voorraadniveaus te optimaliseren. Omdat de vraag onzeker is, moeten bedrijven die zelfs maar een matig serviceniveau moeten bieden, meer voorraad hebben dan de prognose, vaak veel meer. Maar betekent een lage voorspellingsfout niet een lagere veiligheidsvoorraad? Hoe beter mijn prognoses, hoe lager mijn voorraad? Ja waar. Maar waar het bij het bepalen van de benodigde voorraad om gaat, zijn zowel nauwkeurige prognoses van de meest waarschijnlijke vraag als nauwkeurige schattingen van de variabiliteit rond de meest waarschijnlijke vraag.

Vooral met een langdurige, intermitterende vraag, missen traditionele prognosenauwkeurigheidsbeoordelingen over een conventionele prognosehorizon van 12 maanden het punt op drie manieren.

– Ten eerste is de relevante tijdschaal voor voorraadoptimalisatie de doorlooptijd voor aanvulling, die meestal veel korter is dan 12 maanden. Vraag tijdens doorlooptijden gemeten in dagen of weken heeft een volatiliteit die wordt gemiddeld over lange prognosehorizons. Dit is slecht omdat rekening houden met het effect van volatiliteit essentieel is voor de berekening van optimale bestelpunten.

– Ten tweede richt de prognosenauwkeurigheid die wordt beoordeeld over een prognosehorizon van meerdere maanden zich op de typische fout in een typische maand binnen de horizon. Voorraadoptimalisatie vereist daarentegen een focus op de cumulatieve vraag, niet op de vraag per periode.

– Ten derde, en het belangrijkste, is dat prognosefoutstatistieken gericht zijn op het midden van de vraagverdeling, met als doel de meest waarschijnlijke vraag in te schatten. Maar het instellen van bestelpunten omvat het schatten van hoge percentielen van de cumulatieve vraagverdeling over een doorlooptijd. Het midden iets beter inschatten, maar geen idee hebben van bijvoorbeeld het 95e percentiel, helpt niet.

Beschouw dit hypothetische voorbeeld. Als leverancier A 20 eenheden voorspelt met een 110%-fout en leverancier B voorspelt 22 eenheden met een 105%-fout, dan heeft leverancier B een voordeel in het voorspellingsspel. Maar als u een hoog serviceniveau wilt en de vraag wisselvallig is, moet u veel meer dan 20 of 22 eenheden op voorraad hebben. Laten we aannemen dat u de technologie van leverancier B selecteert om voorraadniveaus te plannen. Je merkt dan dat bij het plannen van bestelpunten om een 95%-serviceniveau te bereiken, je vaak tekortschiet - veel vaker dan de verwachte 5% van die tijd. U komt tot het besef dat de benadering van leverancier B de veiligheidsvoorraad die nodig is om het beoogde servicedoel te bereiken, volledig onderschat. Focussen op de voorspellingsfout van leveranciers zal niet helpen. U zult gaan wensen dat u de leveranciers A en B had geverifieerd nauwkeurigheid op serviceniveau. Nu zit u vast aan het willekeurig aanpassen van de serviceniveaudoelstellingen van leverancier B om het tekort te compenseren.

Wat dus nodig is bij leverancierscompetities, is een beoordeling van het vermogen van hun systemen om nauwkeurig de voorraad te voorspellen die nodig is om te voldoen aan een bepaald serviceniveau gedurende de doorlooptijd van een artikel. Een beperkte focus op het meten van prognosefouten is niet gepast als de missie inventarisbeheer is. Dit geldt met name voor longtail-artikelen met intermitterende vraag of artikelen met een gemiddeld tot hoog volume maar zonder een vraagverdeling die lijkt op de klassieke "klokvormige curve" (normale verdeling).

In de rest van deze blog wordt uitgelegd hoe u de nauwkeurigheid van de serviceniveauberekeningen van software kunt testen, zodat u het risico kunt bewaken dat u uw serviceniveaudoelen niet haalt. We raden deze nauwkeurigheidstest aan in plaats van traditionele "prognose versus werkelijke" tests, omdat deze veel meer inzicht geeft in hoe aanbevelingen voor bestelpunten voorraadniveaus en klantenservice zullen beïnvloeden.

Kantoorpersoneel analyseert The Right Forecast Accuracy Metric voor voorraadplanning

Serviceniveau gedefinieerd

Overweeg een enkel inventarisitem. Wanneer de voorraad daalt tot of onder het bestelpunt, wordt een aanvullingsorder gegenereerd. Hiermee begint een risicoperiode die net zo lang duurt als de doorlooptijd van de aanvulling. Tijdens de risicoperiode kunnen er voldoende aanvragen binnenkomen om naleveringen of verloren verkopen te creëren. Het serviceniveau is de waarschijnlijkheid dat er geen backorders of stockouts zijn tijdens de doorlooptijd van de aanvulling. Kritieke items kunnen zeer hoge doelserviceniveaus krijgen, bijvoorbeeld 99%, terwijl andere items mogelijk meer ontspannen doelen hebben, zoals 75%. Wat het beoogde serviceniveau ook is, het is het beste om dat doel te halen.

Serviceniveau berekenen

Het serviceniveau voor een individueel artikel kan alleen worden geschat door de waargenomen doorlooptijdvraag herhaaldelijk te vergelijken met het berekende bestelpunt. Deze schattingen kosten veel tijd: zeker tientallen doorlooptijden. Maar het serviceniveau van het wagenpark kan worden geschat met behulp van gegevens die over een enkele doorlooptijd zijn verzameld.

Laten we een voorbeeld doen. Stel dat u een vraaggeschiedenis heeft voor 1.000 artikelen gedurende 365 dagen en dat (voor de eenvoud) alle artikelen een doorlooptijd van 45 dagen hebben. Volg voor elk artikel de volgende stappen om het voor het wagenpark bereikte serviceniveau te schatten:

Stap 1: Zet de meest recente 45 dagen aan vraag opzij ('houd uit') (of het aantal dagen dat het dichtst bij uw typische doorlooptijden ligt). Bereken hun som, wat de meest recente waarde is van de werkelijke doorlooptijdvraag. Dit is de grondwaarheid die wordt gebruikt om het bereikte serviceniveau in te schatten.

Stap 2: Gebruik de voorafgaande 320 dagen aan vraaggeschiedenis om te voorspellen hoeveel voorraad nodig is om een reeks serviceniveaudoelen te bereiken, bijvoorbeeld 90%, 95%, 97% en 99%.

Stap 3: Controleer of de waargenomen doorlooptijdvraag kleiner is dan of gelijk is aan het bestelpunt. Als dat zo is, tel dit dan als een overwinning; reken het anders als een verlies. Als het bestelpunt bijvoorbeeld 15 eenheden is, maar de meest recente doorlooptijdvraag 10 eenheden is, dan is dit een overwinning, aangezien het bestelpunt hoog genoeg is om een doorlooptijdvraag van 10 te dekken zonder enig tekort. Als de meest recente doorlooptijdvraag echter 18 eenheden is, zou er sprake zijn van een voorraaduitval en zouden 3 eenheden worden nabesteld of als verloren verkoop worden geteld.

Stap 4: Tel voor alle items en alle serviceniveaudoelen het percentage tests voor elk serviceniveaudoel dat tot een overwinning heeft geleid. Dit is het behaalde serviceniveau. Als het doel 90% was en 853 van de 1.000 eenheden winnen, dan is het bereikte serviceniveau 85.3%.

Voorbeeld

Overweeg een voorbeeld uit de echte wereld. De gegevens zijn dagelijkse vraaggeschiedenissen van 590 medische artikelen die worden gebruikt in een internationaal bekende kliniek. Voor de eenvoud gaan we ervan uit dat elk artikel een levertijd heeft van 45 dagen. We evalueren beoogde serviceniveaus van 70%, 90%, 95% en 99%.
We vergelijken twee vraagmodellen. Het "Normale" model gaat ervan uit dat de dagelijkse vraag een normale ("klokvormige") verdeling heeft. Dit is de klassieke aanname die wordt gebruikt in de meeste inleidende leerboeken over voorraadbeheer en in veel softwareproducten. Hoe klassiek het ook mag zijn, het is vaak een ongepast model van de vraag naar reserveonderdelen of voorraden. Het “Probability Forecast”-model houdt expliciet rekening met de intermitterende aard van de vraag.

Bijlage 1 toont de resultaten. Kolom J toont de werkelijke vraag over de laatste 45 waarnemingen. De berekende bestelpunten voor het geavanceerde model worden weergegeven in kolommen LO. De berekende bestelpunten voor het model Normaal worden niet weergegeven. De kolommen QT en VY bevatten de resultaten van de tests om na te gaan of de bestelpunten hoog genoeg waren om de doorlooptijdvereisten in kolom J aan te kunnen.

De uiteindelijke resultaten (gele cellen) laten een duidelijk verschil zien tussen de vraagmodellen Normal en Probability (Advanced). Beiden hebben het 70%-serviceniveaudoel goed bereikt, maar het schatten van hogere serviceniveaus is een meer delicate berekening en het waarschijnlijkheidsmodel doet het veel beter. Het veronderstelde 99%-serviceniveau van het Normal-model bleek bijvoorbeeld slechts 94.4% te zijn, terwijl het Probability-model het doel bereikte met een 98.5% bereikt serviceniveau.

Implicaties

Met de meer nauwkeurige methode werd het beoogde serviceniveau bereikt, terwijl dat met de minder nauwkeurige methode niet het geval was. Als de minder nauwkeurige methode wordt gebruikt, zullen echte en kostbare zakelijke beslissingen worden genomen in de valse veronderstelling dat een hoger serviceniveau zal worden bereikt. Als er bijvoorbeeld een Service Level Agreement (SLA) is gebaseerd op deze resultaten en een 99%-serviceniveau is vastgelegd, is de kans dat de leverancier een voorraad oploopt vijf keer groter dan gepland (beloofd serviceniveau = 99%- of 1%-voorraadrisico vs. serviceniveau bereikt = 94.5% of 5.5% stock out risico)! Dit betekent dat boetes vijf keer vaker worden opgelegd dan verwacht.

Stel dat planners wisten dat het beoogde serviceniveau niet zou worden gehaald, maar vast kwamen te zitten met een onnauwkeurig model. Ze zouden nog steeds een manier nodig hebben om de voorraad te vergroten en het gewenste serviceniveau te bereiken. Wat zouden ze kunnen kiezen om te doen? We hebben situaties waargenomen waarin de planner een hoger doel voor het serviceniveau invoert dan nodig is om het systeem te "misleiden" om het vereiste serviceniveau te leveren. In het bovenstaande voorbeeld moest het Normal-model een 99.99%-serviceniveau hebben ingevoerd voordat het een doelserviceniveau van 99% kon bereiken. Deze wijziging resulteerde in het bereiken van een 99%-service, maar meer dan een verdubbeling van de voorraadinvestering in vergelijking met het geavanceerde model.

Het implementeren van een nauwkeurigheidstest op serviceniveau

Bij Smart Software hebben we veel van onze klanten aangemoedigd om de test van de nauwkeurigheid van het serviceniveau uit te voeren als een manier voor hen om onze claims en die van andere leveranciers te beoordelen tijdens het softwareselectieproces. Het niet halen van de service level target heeft uiterst kostbare implicaties, resulterend in substantiële over- of ondervoorraden. Test dus de nauwkeurigheid van het serviceniveau voordat u een oplossing implementeert om situaties te identificeren waarin de modellering mislukt. Ga er niet vanuit dat u het serviceniveau bereikt dat u besluit te targeten (of dat het systeem aanbeveelt). Als u een Excel-spreadsheet wilt aanvragen die dient als sjabloon voor een nauwkeurigheidstest op serviceniveau, e-mailt u uw contactgegevens naar info@smartcorp.com en voert u "Nauwkeurigheidssjabloon" in de onderwerpregel in.