Welke gegevens zijn nodig ter ondersteuning van software-implementaties voor Demand planning?

Onlangs spraken we met het IT-team van een van onze klanten over de gegevensvereisten en de installatie van onze API-gebaseerde integratie die gegevens uit hun on-premises installatie van hun ERP-systeem zou halen. De IT-manager en analist toonden zich beiden zeer bezorgd over het verstrekken van deze gegevens en vroegen zich serieus af waarom deze gegevens überhaupt verstrekt moesten worden. 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 uit te leggen waarom bepaalde gegevens nodig zijn om een effectief vraagplanningsproces te ondersteunen.

Als je een prognoseanalist, vraagplanner of supply chain-professional bent, zal het meeste van wat je hieronder leest voor de hand liggen. Maar wat deze bijeenkomst mij heeft geleerd, is dat wat voor de ene groep specialisten vanzelfsprekend is, niet vanzelfsprekend is voor een andere groep specialisten in een heel ander vakgebied.

De vier belangrijkste soorten gegevens die nodig zijn, zijn:

1. Historische transacties, zoals verkooporders en verzendingen.
2. Taakgebruiktransacties, zoals welke onderdelen nodig zijn om eindproducten te produceren.
3. Transacties voor voorraadoverdracht, zoals welke voorraad is verzonden van de ene locatie naar de andere.
4. Prijzen, kosten en attributen, zoals de eenheidsprijs betaald aan de leverancier, de eenheidsprijs betaald door de klant en verschillende metagegevens zoals productfamilie, klasse, enz.

Hieronder wordt kort uitgelegd waarom deze gegevens nodig zijn om de implementatie van vraagplanningsoftware door een bedrijf te ondersteunen.

Transactiegegevens van historische verkopen en verzendingen per klant
Beschouw wat uit de voorraad werd gehaald als de “grondstof” die de vraagplanningssoftware nodig heeft. Dit kan zijn wat er is verkocht aan wie en wanneer of wat je hebt verzonden naar wie en wanneer. Of welke grondstoffen of subassemblages werden verbruikt in werkorders en wanneer. Of wat er geleverd is aan een satellietmagazijn vanuit een distributiecentrum en wanneer.

De geschiedenis van deze transacties wordt door de software geanalyseerd en gebruikt om statistische voorspellingen te maken die waargenomen patronen extrapoleren. De gegevens worden geëvalueerd om patronen te ontdekken, zoals trends, seizoensgebondenheid, cyclische patronen en om potentiële uitschieters te identificeren die bedrijfsaandacht vereisen. Als deze gegevens niet algemeen toegankelijk zijn of met onregelmatige tussenpozen worden bijgewerkt, dan is het bijna onmogelijk om een goede voorspelling te maken van de toekomstige vraag. Ja, je zou bedrijfskennis of onderbuikgevoel kunnen gebruiken, maar dat is niet schaalbaar en introduceert bijna altijd vooringenomenheid in de voorspelling (d.w.z. consequent te hoog of te laag voorspellen).

Er zijn gegevens nodig op transactieniveau om fijnmazige prognoses op wekelijks of zelfs dagelijks niveau te ondersteunen. Als een bedrijf bijvoorbeeld het drukke seizoen ingaat, kan het beginnen met wekelijkse prognoses om de productie beter af te stemmen op de vraag. Dat is niet eenvoudig zonder de transactionele gegevens in een goed gestructureerd datawarehouse.

Het kan ook zo zijn dat bepaalde soorten transacties niet in de vraaggegevens moeten worden opgenomen. Dit kan gebeuren als de vraag het gevolg is van een fikse korting of een andere omstandigheid waarvan het supply chain-team weet dat deze de resultaten zal vertekenen. Als de gegevens als geheel worden aangeleverd, is het veel moeilijker om deze uitzonderingen te onderscheiden. Bij Smart Software noemen we het proces om uit te zoeken welke transacties (en bijbehorende transactieattributen) moeten worden meegeteld in het vraagsignaal “samenstelling van het vraagsignaal”. Als een bedrijf toegang heeft tot alle transacties, kan het zijn vraagsignaal in de loop der tijd binnen de software naar behoefte aanpassen. Als slechts een deel van de gegevens beschikbaar is, resulteert dit in een veel rigide samenstelling van het vraagsignaal die alleen kan worden verholpen met extra implementatiewerk.

Prijzen en kosten
De prijs waarvoor je je producten hebt verkocht en de kosten die je hebt betaald om ze aan te schaffen (of grondstoffen) zijn cruciaal voor het kunnen voorspellen van inkomsten of kosten. Een belangrijk onderdeel van het vraagplanningsproces is het verkrijgen van bedrijfskennis van klanten en verkoopteams. Verkoopteams hebben de neiging om de vraag per klant of productcategorie te bekijken 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 voorspelling alleen in eenheden wordt weergegeven.

Vaak wordt de vraagprognose gebruikt om een groter plannings- en budgetteringsproces aan te sturen of op zijn minst te beïnvloeden en de belangrijkste input voor een budget is een prognose van de inkomsten. Wanneer vraagprognoses worden gebruikt om het S&OP-proces te ondersteunen, moet de vraagplanningssoftware ofwel een gemiddelde nemen van de prijzen voor alle transacties of “tijdfasige” conversies toepassen die rekening houden met de prijs die op dat moment wordt verkocht. Zonder de ruwe gegevens over prijzen en kosten kan het vraagplanningsproces nog steeds functioneren, maar het zal ernstig worden belemmerd.

Productkenmerken, klantgegevens en locaties
Productattributen zijn nodig zodat forecasters prognoses kunnen aggregeren over verschillende productfamilies, groepen, goederencodes, enz. Het is handig om te weten hoeveel eenheden en de totale verwachte vraag in dollars voor verschillende categorieën. Vaak is bedrijfskennis over wat de vraag in de toekomst zou kunnen zijn niet bekend op productniveau, maar wel op productfamilieniveau, klantniveau of regionaal niveau. Door productattributen toe te voegen aan uw demand planning datafeed, kunt u eenvoudig prognoses “oprollen” van artikelniveau naar familieniveau. U kunt prognoses op deze niveaus omzetten naar dollars en beter samenwerken over hoe de prognose moet worden aangepast.

Zodra de kennis wordt toegepast in de vorm van een forecast override, zal de software de wijziging automatisch doorvoeren in alle individuele items waaruit de groep bestaat. Op deze manier hoeft een forecast analist niet elk onderdeel afzonderlijk aan te passen. Ze kunnen een wijziging doorvoeren op geaggregeerd niveau en de demand planning software de reconciliatie voor hen laten doen.

Groeperen voor gemakkelijke analyse is ook van toepassing op klantattributen, zoals de toegewezen verkoper of de voorkeursleverlocatie van de klant. En locatieattributen kunnen nuttig zijn, zoals toegewezen regio. Soms hebben attributen betrekking op een combinatie van product en locatie, zoals voorkeursleverancier of toegewezen planner, die per magazijn kunnen verschillen voor hetzelfde product.