​ACHTERGROND

De meeste blogs, webinars en whitepapers van Smart Software beschrijven het gebruik van onze software bij ‘normale werkzaamheden’. Deze gaat over ‘onregelmatige operaties’. Smart Software is bezig met het aanpassen van onze producten om u te helpen omgaan met uw eigen onregelmatige werkzaamheden. Dit is een voorproefje.

Ik hoorde de term ‘irreguliere operaties’ voor het eerst toen ik een sabbatical-tournee maakte bij de Amerikaanse Federal Aviation Administration in Washington, DC. De FAA verkort de term tot “IROPS” en gebruikt deze om situaties te beschrijven waarin weersomstandigheden, mechanische problemen of andere problemen de normale vliegtuigstroom verstoren.

Smart Inventory Optimization® (“SIO”) werkt momenteel aan het bieden van een zogenaamd “steady state”-beleid voor het beheren van voorraadartikelen. Dat betekent bijvoorbeeld dat SIO automatisch waarden berekent voor bestelpunten (ROP's) en bestelhoeveelheden (OQ's) die bedoeld zijn om in de nabije toekomst mee te gaan. Het berekent deze waarden op basis van simulaties van dagelijkse activiteiten die jaren in de toekomst reiken. Als en wanneer het onvoorzienbare gebeurt, zullen onze verandering van regime De detectiemethode reageert door verouderde gegevens te verwijderen en herberekening van de ROP's en OQ's mogelijk te maken.

We merken vaak de toenemende snelheid van zakendoen, waardoor de duur van de “afzienbare toekomst” wordt verkort. Sommige van onze klanten hanteren nu een kortere planningshorizon, zoals de overstap van kwartaal- naar maandplannen. Eén neveneffect van deze verandering is dat IROPS meer consequenties heeft. Als een plan gebaseerd is op drie gesimuleerde jaren van dagelijkse vraag, doet één vreemde gebeurtenis, zoals een grote verrassingsbestelling, er in het grote geheel niet zoveel toe. Maar als de planningshorizon erg kort is, kan één grote verrassingsvraag een groot effect hebben op de belangrijkste prestatie-indicatoren (KPI's) die over een korter interval worden berekend – er is geen tijd voor 'uitmiddelen'. De planner kan zich genoodzaakt zien een noodbestelling te plaatsen om de verstoring op te vangen. Wanneer moet de bestelling worden geplaatst om het meeste goed te doen? Hoe groot moet het zijn?

SCENARIO: NORMALE OPS

Om dit concreet te maken, beschouwen we het volgende scenario. Tom's Spares, Inc. levert kritische serviceonderdelen aan zijn klanten, waaronder SKU723, een vervangende printplaat die wordt verkocht onder de handelsnaam WIDGET. De vraag naar WIDGET is wisselend, er wordt minder dan één eenheid per dag gevraagd. Tom's Spares bestelt WIDGET's bij Acme Products, waardoor het 7 of 10 dagen duurt om de aanvullingsbestellingen uit te voeren.

Tom's Spares werkt met een korte voorraadplanningshorizon van 28 dagen. Het bedrijf opereert in een competitieve omgeving met ongeduldige klanten die alleen met tegenzin nabestellingen accepteren. Het beleid van Tom is om ROP's en OQ's zo in te stellen dat de voorraad beperkt blijft en tegelijkertijd een opvullingspercentage van minimaal 90% wordt gehandhaafd. Het management monitort maandelijks de KPI's. In het geval van WIDGETS worden deze KPI-doelen momenteel gehaald met een ROP=3 en een OQ=4, wat resulteert in een gemiddelde voorraad van ongeveer 4 eenheden en een gemiddeld opvullingspercentage van 96%. Tom's Spares heeft iets goeds op het gebied van WIDGETS.

Figuur 1 toont twee maanden WIDGET-informatie. Het paneel linksboven toont de dagelijkse vraag naar eenheden. Rechtsboven ziet u de beschikbare dagelijkse eenheden. Het paneel linksonder toont de timing en de omvang van de aanvullingsorders naar Acme Products. Rechtsonder ziet u eenheden die zijn nabesteld vanwege voorraadtekorten. In deze simulatie was de dagelijkse vraag 0 of 1, met één vraag van 2 eenheden. Voorhanden eenheden begonnen de maand op 7 en daalden nooit onder de 1, hoewel er de volgende maand een voorraadtekort was, wat resulteerde in een enkele eenheid in nabestelling. Gedurende de twee maanden werden er vier aanvullingsorders van elk vier eenheden naar Acme gestuurd, die allemaal binnenkwamen tijdens de simulatieperiode van twee maanden.

GOEDE PROBLEMEN VERSTOREN NORMALE OPS

Nu voegen we wat ‘goede problemen’ toe aan het scenario: halverwege de planningsperiode ontstaat er een ongewoon grote order. Het is “goed” omdat meer vraag meer inkomsten impliceert. Maar het is een “probleem” omdat de normale parameters voor voorraadbeheer van de operatie (ROP=3, OQ=4) niet zijn gekozen om met deze situatie om te gaan. De piek in de vraag kan zo groot zijn, en zo ongunstig getimed, dat het voorraadsysteem overweldigd wordt, waardoor voorraadtekorten en de daarmee gepaard gaande nabestellingen ontstaan. Het KPI-rapport aan het management voor zo'n maand zou niet mooi zijn.

Figuur 2 toont een scenario waarin een vraagpiek van 10 eenheden optreedt op de derde dag van de planningsperiode. In dit geval zet de piek de voorraad voor de rest van de maand onder water en creëert een cascade van nabestellingen die zich uitstrekt tot de volgende maand. Met een gemiddelde van meer dan 1.000 simulaties tonen de KPI's van maand 1 een gemiddelde van 0,6 eenheden en een miserabel opvullingspercentage van 44%.

TERUGVECHTEN MET ONREGELMATIGE OPERATIES

Tom's Spares kan op een onregelmatige situatie reageren met een onregelmatige verplaatsing door een noodaanvulorder aan te maken. Om het goed te doen, moeten ze nadenken over (a) wanneer ze de bestelling moeten plaatsen, (b) hoe groot de bestelling moet zijn en (c) of ze de bestelling moeten bespoedigen.

De vraag over de timing lijkt voor de hand te liggen: reageer zodra de order toekomt. Als de klant echter vroegtijdig zou waarschuwen, zou Tom's Spares vroegtijdig kunnen bestellen en in een betere positie zijn om de verstoring als gevolg van de piek te beperken. Als de communicatie tussen Tom's en de klant die de grote bestelling plaatst echter gebrekkig is, kan het zijn dat de klant Tom's later of helemaal niet op de hoogte stelt.

Ook de omvang van de speciale bestelling lijkt voor de hand liggend: bestel het benodigde aantal eenheden vooraf. Maar dat werkt het beste als Tom's Spares weet wanneer de vraagpiek zal aanbreken. Zo niet, dan is het misschien een goed idee om extra te bestellen om de duur van eventuele nabestellingen te beperken. Over het algemeen geldt dat hoe minder vroegtijdige waarschuwing wordt gegeven, hoe groter de bestelling die Tom's moet plaatsen. Deze relatie kan uiteraard worden onderzocht met simulatie.

De aankomst van de aanvulopdracht kon worden overgelaten aan de gebruikelijke bedrijfsvoering van Acme Products. In de bovenstaande simulaties was de kans even groot dat Acme binnen zeven of veertien dagen zou reageren. Voor een planningshorizon van 28 dagen kan het risico nemen om binnen 14 dagen een antwoord te krijgen vragen om problemen zijn, dus het kan voor Tom's vooral de moeite waard zijn om Acme te betalen voor versnelde verzending. Misschien van de ene op de andere dag, maar mogelijk iets goedkoper maar toch relatief snel.

We hebben nog een paar scenario's onderzocht met behulp van simulatie. Tabel 1 toont de resultaten. Scenario's 1-4 gaan ervan uit dat er op dag 3 een verrassende extra vraag van 10 eenheden arriveert, wat aanleiding geeft tot een onmiddellijke bestelling voor extra aanvulling. De omvang en doorlooptijd van de aanvulorder varieert.

Scenario 0 laat zien dat niets doen als reactie op de verrassende vraag leidt tot een verschrikkelijk 41%-opvullingspercentage voor die maand; niet getoond is dat dit resultaat de volgende maand een aanhoudend slechte prestatie inhoudt. Reguliere operaties zullen niet goed werken. De planner moet iets doen om op de afwijkende vraag te reageren.

Als u hier iets aan wilt doen, betekent dit dat u een eenmalige noodaanvullingsbestelling moet doen. De planner moet de omvang en het tijdstip van die bestelling kiezen. Scenario's 1 en 3 tonen aanvullingen van "halve grootte". Scenario's 1 en 2 geven nachtelijke aanvullingen weer, terwijl scenario's 3 en 4 een gegarandeerde respons binnen één week weergeven.

De resultaten maken duidelijk dat onmiddellijke reactie belangrijker is dan de omvang van de aanvulorder om de opvullingsgraad te herstellen. Nachtelijke aanvulling levert opvullingspercentages op in het 70%-bereik, terwijl een aanvultijd van een week het opvullingspercentage verlaagt naar het midden-50% tot midden-60%-bereik.

AFHAALMAAL

Voorraadbeheersoftware breidt zich uit van de traditionele focus op normale operaties naar een extra focus op onregelmatige operaties (IROPS). Deze evolutie is mogelijk gemaakt door de ontwikkeling van nieuwe statistische methoden voor het genereren van vraagscenario's op dagelijks niveau.

We hebben één IROPS-situatie overwogen: de verrassende komst van een abnormaal grote vraag. Dagelijkse simulaties gaven inzicht in de timing en de omvang van een noodaanvullingsorder. De resultaten van een dergelijke analyse bieden inventarisplanners een kritische back-up door de resultaten van alternatieve interventies te schatten die hun ervaring hen suggereert.

We komen vaak op Excel gebaseerde methoden voor het plannen van bestelpunten tegen. In dit bericht hebben we een benadering beschreven die een klant gebruikte voordat hij verder ging met Smart. We beschrijven hoe hun spreadsheet werkte, de statistische benaderingen waarop het zich baseerde, de stappen die planners doorliepen bij elke planningscyclus en hun aangegeven motivaties om deze intern ontwikkelde spreadsheet te gebruiken (en echt leuk te vinden).

Hun maandelijkse proces bestond uit het bijwerken van een nieuwe maand met actuals naar het 'puntenoverzicht voor opnieuw bestellen'. Een ingebedde formule herberekende het Reorder Point (ROP) en order-up-to (Max) niveau. Het werkte als volgt:

• ROP = LT Vraag + Veiligheidsvoorraad
• LT-vraag = gemiddelde dagelijkse vraag x doorlooptijddagen (constant verondersteld om het simpel te houden)
• Veiligheidsvoorraad voor onderdelen met een lange doorlooptijd = Standaardafwijking x 2,0
• Veiligheidsvoorraad voor onderdelen met een korte doorlooptijd = Standaardafwijking x 1,2
• Max = ROP + door de leverancier voorgeschreven minimale bestelhoeveelheid

Historische gemiddelden en standaarddeviaties gebruikten 52 weken voortschrijdende geschiedenis (dwz de nieuwste week verving de oudste week in elke periode). De standaarddeviatie van de vraag werd berekend met behulp van de functie "stdevp" in Excel.

Elke maand werd een nieuwe ROP opnieuw berekend. Zowel de gemiddelde vraag als de standaarddeviatie werden gewijzigd door de vraag van de nieuwe week, die op zijn beurt de ROP bijwerkte.

De standaard ROP is altijd gebaseerd op de bovenstaande logica. Planners zouden echter onder bepaalde voorwaarden wijzigingen aanbrengen:

1. Planners zouden de minimumprijs voor goedkope onderdelen verhogen om het risico op een on-time delivery hit (OTD) op een goedkoop onderdeel te verkleinen.

2. Het Excel-blad identificeerde elk onderdeel met een nieuw berekende ROP die ± 20% verschilde van de huidige ROP.

3. Planners beoordeelden onderdelen die de uitzonderingsdrempel overschreden, stelden wijzigingen voor en lieten een manager goedkeuren.

4. Planners beoordeelden items met OTD-hits en verhoogden de ROP op basis van hun intuïtie. Planners bleven die onderdelen gedurende verschillende perioden monitoren en verlaagden de ROP wanneer ze dachten dat het veilig was.

5. Nadat de ROP en de maximale hoeveelheid waren bepaald, werd het bestand met herziene resultaten naar IT gestuurd, die het in hun ERP uploadde.

6. Het ERP-systeem beheerde vervolgens de dagelijkse bevoorrading en het orderbeheer.

Objectief gezien was dit misschien een bovengemiddelde benadering van voorraadbeheer. Sommige bedrijven zijn zich bijvoorbeeld niet bewust van het verband tussen vraagvariabiliteit en veiligheidsvoorraadvereisten en vertrouwen uitsluitend op methodes of intuïtie. Er zijn echter problemen met hun aanpak:

1. Handmatige gegevensupdates
De spreadsheets moesten handmatig worden bijgewerkt. Om opnieuw te berekenen waren meerdere stappen nodig, elk met hun eigen afhankelijkheid. Eerst moest er een datadump worden uitgevoerd vanuit het ERP-systeem. Ten tweede zou een planner de spreadsheet moeten openen en bekijken om er zeker van te zijn dat de gegevens correct zijn geïmporteerd. Ten derde moesten ze de uitvoer beoordelen om er zeker van te zijn dat deze berekend was zoals verwacht. Ten vierde waren er handmatige stappen nodig om de resultaten terug te sturen naar het ERP-systeem.

2. Eén maat voor alle veiligheidsvoorraad
Of in dit geval "one of two sizes fit all". De keuze om 2x en 1,2x standaarddeviatie te gebruiken voor respectievelijk artikelen met een lange en korte doorlooptijd komt overeen met serviceniveaus van 97.7% en 88.4%. Dit is een groot probleem, aangezien het logisch is dat niet elk onderdeel in elke groep hetzelfde serviceniveau vereist. Sommige onderdelen hebben meer voorraadpijn dan andere en vice versa. Serviceniveaus moeten daarom dienovereenkomstig worden gespecificeerd en in overeenstemming zijn met het belang van het item. We ontdekten dat ze OTD-hits ondervonden op ongeveer 20% van hun kritieke reserveonderdelen, waardoor handmatige aanpassingen van de ROP nodig waren. De hoofdoorzaak was dat ze voor alle items met een korte doorlooptijd een serviceniveau van 88,4% hadden gepland. Dus het beste wat ze hadden kunnen krijgen, was om 12% van die tijd in voorraad te hebben, zelfs als ze 'volgens plan' waren. Het zou beter zijn geweest om serviceniveaudoelen te plannen op basis van het belang van het onderdeel.

3. Veiligheidsvoorraad is onnauwkeurig.  De artikelen die voor dit bedrijf worden gepland, zijn reserveonderdelen ter ondersteuning van diagnostische apparatuur. De vraag naar de meeste van deze onderdelen is zeer intermitterend en sporadisch. De keuze om een gemiddelde te gebruiken om de vraag naar doorlooptijd te berekenen, was dus niet onredelijk als je de noodzaak accepteert om variabiliteit in doorlooptijden te negeren. Echter, het beroep op a Normale verdeling het bepalen van de veiligheidsvoorraad was een grote fout die resulteerde in onnauwkeurige veiligheidsvoorraden. Het bedrijf verklaarde dat het serviceniveau voor artikelen met een lange doorlooptijd in het 90%-bereik lag in vergelijking met hun doel van 97,7%, en dat ze het verschil goedmaakten met spoed. De bereikte serviceniveaus voor items met een kortere doorlooptijd bedroegen ongeveer 80%, ondanks het feit dat er werd gestreefd naar 88,4%. Ze berekenden de veiligheidsvoorraad verkeerd omdat hun vraag niet "klokvormig" is, maar ze kozen de veiligheidsvoorraad in de veronderstelling dat dit wel het geval was. Deze vereenvoudiging resulteert in het missen van serviceniveaudoelen, waardoor de handmatige beoordeling van veel items wordt gedwongen die vervolgens handmatig "gedurende meerdere perioden" moeten worden gecontroleerd door een planner. Zou het niet beter zijn om ervoor te zorgen dat het bestelpunt vanaf het begin precies het gewenste serviceniveau had? Dit zou ervoor zorgen dat u uw serviceniveau bereikt en onnodige handmatige tussenkomst minimaliseert.

Er is een vierde probleem dat de lijst niet heeft gehaald, maar het vermelden waard is. De spreadsheet kon geen trend- of seizoenspatronen volgen. Historische gemiddelden negeren trend en seizoensgebondenheid, dus de cumulatieve vraag over de doorlooptijd die in de ROP wordt gebruikt, zal aanzienlijk minder nauwkeurig zijn voor trending of seizoensgebonden onderdelen. Het planningsteam erkende dit, maar vond het geen legitiem probleem, redenerend dat het grootste deel van de vraag onregelmatig was en niet seizoensgebonden. Het is belangrijk voor het model om trend en seizoensinvloeden op te pikken op intermitterende gegevens als die bestaan, maar we hebben niet gevonden dat hun gegevens deze patronen vertoonden. Dus we waren het erover eens dat dit geen probleem was voor hen. Maar naarmate het planningstempo toeneemt tot het punt dat de vraag in een emmer terechtkomt dagelijks, zelfs intermitterende vraag blijkt heel vaak seizoensgebonden te zijn per dag van de week en soms per week. Als je nu niet met een hogere frequentie rent, houd er dan rekening mee dat je misschien binnenkort gedwongen zult worden om de meer behendige concurrentie bij te houden. Op dat moment zal de verwerking op basis van spreadsheets het gewoon niet bij kunnen houden.

Tot slot: gebruik geen spreadsheets. Ze zijn niet bevorderlijk voor zinvolle wat-als-analyses, ze zijn te arbeidsintensief en de onderliggende logica moet worden afgezwakt om snel genoeg te kunnen worden verwerkt om bruikbaar te zijn. Kortom, ga voor doelgerichte oplossingen. En zorg ervoor dat ze in de cloud draaien.