Het meten van de nauwkeurigheid van prognoses is een onmiskenbaar belangrijk onderdeel van het vraagplanningsproces. Deze voorspellingsscorekaart zou kunnen worden opgebouwd op basis van een van de twee contrasterende gezichtspunten voor het berekenen van metrieken. Vanuit het foutperspectief wordt de vraag gesteld: “Hoe ver lag de voorspelling van de werkelijkheid?” Vanuit het nauwkeurigheidsperspectief wordt de vraag gesteld: “Hoe dicht lag de voorspelling bij de werkelijkheid?” Beide zijn geldig, maar foutstatistieken bieden meer informatie.

Nauwkeurigheid wordt weergegeven als een percentage tussen nul en 100, terwijl foutpercentages bij nul beginnen maar geen bovengrens hebben. Rapporten van MAPE (gemiddelde absolute procentuele fout) of andere foutstatistieken kunnen de titel 'voorspellingsnauwkeurigheid'-rapporten krijgen, waardoor het onderscheid vervaagt. Het kan dus zijn dat u wilt weten hoe u vanuit het foutenperspectief kunt overstappen naar het nauwkeurigheidsperspectief dat uw bedrijf omarmt. In deze blog wordt aan de hand van enkele voorbeelden beschreven hoe.

Nauwkeurigheidsgegevens worden zo berekend dat wanneer de werkelijke waarde gelijk is aan de voorspelling, de nauwkeurigheid 100% is en wanneer de voorspelling het dubbele of de helft is van de werkelijke, de nauwkeurigheid 0% is. Rapporten waarin de voorspelling met de werkelijkheid wordt vergeleken, bevatten vaak het volgende:

• De daadwerkelijke
• De prognose
• Eenheidsfout = Prognose – Werkelijk
• Absolute fout = Absolute waarde van eenheidsfout
• Absolute %-fout = Abs-fout / Werkelijk, als een %
• Nauwkeurigheid % = 100% – Absolute %-fout

Bekijk een paar voorbeelden die het verschil in aanpak illustreren. Stel dat de Werkelijke = 8 en de voorspelling is 10.

Eenheidsfout is 10 – 8 = 2

Absolute %-fout = 2/8, als % = 0,25 * 100 = 25%

Nauwkeurigheid = 100% – 25% = 75%.

Laten we nu zeggen dat de werkelijke waarde 8 is en de voorspelling 24.

Eenheidsfout is 24– 8 = 16

Absolute %-fout = 16/8 als % = 2 * 100 = 200%

Nauwkeurigheid = 100% – 200% = negatief is ingesteld op 0%.

In het eerste voorbeeld leveren nauwkeurigheidsmetingen dezelfde informatie op als foutmetingen, aangezien de voorspelling en de werkelijke situatie al relatief dicht bij elkaar liggen. Maar als de fout meer dan het dubbele is van de werkelijke, komen de nauwkeurigheidsmetingen uit op nul. Het geeft wel correct aan dat de voorspelling helemaal niet accuraat was. Maar het tweede voorbeeld is nauwkeuriger dan een derde, waarbij de werkelijke waarde 8 is en de voorspelling 200. Dat is een onderscheid dat een nauwkeurigheidsbereik van 0 tot 100% niet registreert. In dit laatste voorbeeld:

Eenheidsfout is 200 – 8 = 192

Absolute %-fout = 192/8, als % = 24 * 100 = 2,400%

Nauwkeurigheid = 100% – 2.400% = negatief is ingesteld op 0%.

Foutstatistieken blijven informatie verschaffen over hoe ver de voorspelling afwijkt van de werkelijke en geven aantoonbaar een betere weergave van de nauwkeurigheid van de voorspelling.

Wij moedigen aan om het foutperspectief te hanteren. U hoopt eenvoudigweg op een klein foutpercentage dat aangeeft dat de voorspelling niet ver van de werkelijkheid ligt, in plaats van te hopen op een groot nauwkeurigheidspercentage dat aangeeft dat de voorspelling dicht bij de werkelijkheid ligt. Deze mentaliteitsverandering biedt dezelfde inzichten en elimineert vervormingen.

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.

Smart IP&O wordt mogelijk gemaakt door de SmartForecasts®-prognose-engine die automatisch de meest geschikte methode voor elk item selecteert. Smart Forecast-methoden worden hieronder vermeld:

• Eenvoudig voortschrijdend gemiddelde en enkele exponentiële afvlakking voor platte, ruisige gegevens
• Lineair voortschrijdend gemiddelde en dubbele exponentiële afvlakking voor trendgegevens
• Winters Additief en Winters Multiplicatief voor seizoens- en seizoens- en trendgegevens.

Deze blog legt uit hoe elk model werkt met behulp van tijdgrafieken van historische en voorspelde gegevens. Het schetst hoe te kiezen welk model te gebruiken. De onderstaande voorbeelden tonen dezelfde geschiedenis, in rood, voorspeld met elke methode, in donkergroen, vergeleken met de Slim gekozen winnende methode, in lichtgroen.

Seizoensgebondenheid
Als u seizoensinvloeden wilt forceren (of voorkomen) in de prognose, kies dan voor Winters-modellen. Beide methoden vereisen 2 volle jaren geschiedenis.

'Winter is multiplicatief zal de grootte van de pieken of dalen van seizoenseffecten bepalen op basis van een procentueel verschil met een trending gemiddeld volume. Het past niet goed bij items met een zeer laag volume vanwege deling door nul bij het bepalen van dat percentage. Merk in de onderstaande afbeelding op dat de grote procentuele daling van de seizoensgebonden vraag in de geschiedenis naar verwachting zal voortduren gedurende de prognosehorizon, waardoor het lijkt alsof er geen seizoensgebonden vraag is, ondanks het gebruik van een seizoensmethode.

Statistische voorspelling gemaakt met de multiplicatieve methode van Winter. 

Toevoeging voor de winter zal de grootte van de pieken of dalen van seizoenseffecten bepalen op basis van een eenheidsverschil met het gemiddelde volume. Het past niet goed als er een significante trend in de gegevens is. Let op in de afbeelding hieronder dat seasonaliteit wordt nu voorspeld op basis van de gemiddelde eenheidsverandering in seizoensgebondenheid. De voorspelling geeft dus nog steeds duidelijk het seizoenspatroon weer ondanks de neerwaartse trend in zowel het niveau als de seizoenspieken/dalen.

Statistische voorspelling gemaakt met de additieve methode van Winter.

Trend

Als u trend omhoog of omlaag wilt forceren (of voorkomen) om in de prognose te tonen, beperk dan de gekozen methoden tot (of verwijder de methoden van) Lineair voortschrijdend gemiddelde en Double Exponential Smoothing.

 Dubbele exponentiële afvlakking zal een langetermijntrend oppikken. Het past niet goed als er weinig historische datapunten zijn.

Statistische voorspelling geproduceerd met Double Exponential Smoothing

Lineair voortschrijdend gemiddelde zal trends op kortere termijn oppikken. Het is niet geschikt voor zeer volatiele gegevens

Niet-trending en niet-seizoensgebonden gegevens
Als u wilt forceren (of voorkomen) dat een gemiddelde wordt weergegeven in de prognose, beperk dan de gekozen methoden tot (of verwijder de methoden van) Eenvoudig voortschrijdend gemiddelde en Enkelvoudig exponentieel effenen.

Enkele exponentiële afvlakking zal de meest recente gegevens zwaarder wegen en een vlakke lijnprognose produceren. Het is niet geschikt voor trending- of seizoensgegevens.

Statistische voorspelling met Single Exponential Smoothing

Eenvoudig voortschrijdend gemiddelde zal voor elke periode een gemiddelde vinden, dat soms lijkt te wiebelen, en beter voor middelingen op langere termijn. Het is niet geschikt voor trending- of seizoensgegevens.

Statistische voorspelling met behulp van eenvoudig voortschrijdend gemiddelde

Soms slaat een statistische prognose gewoon nergens op. Elke voorspeller is er geweest. Ze kunnen dubbel controleren of de gegevens correct zijn ingevoerd of de modelinstellingen bekijken, maar ze blijven zich afvragen waarom de voorspelling er zo anders uitziet dan de vraaggeschiedenis. Wanneer de incidentele voorspelling nergens op slaat, kan dit het vertrouwen in het hele statistische prognoseproces aantasten.

Deze blog zal een leek helpen begrijpen wat de slimme statistische modellen zijn en hoe ze automatisch worden gekozen. Er wordt ingegaan op hoe die keuze soms mislukt, hoe u kunt weten of dat zo is en wat u kunt doen om ervoor te zorgen dat de prognoses altijd gerechtvaardigd kunnen worden. Het is belangrijk om te weten wat u kunt verwachten en hoe u de uitzonderingen kunt opvangen, zodat u kunt vertrouwen op uw prognosesysteem.

Hoe methoden automatisch worden gekozen

De criteria om automatisch één statistische methode uit een set te kiezen, zijn gebaseerd op welke methode het dichtst bij het correct voorspellen van de achtergehouden geschiedenis kwam. De eerdere geschiedenis wordt aan elke methode doorgegeven en het resultaat wordt vergeleken met de werkelijke waarden om de methode te vinden die er het dichtst bij in de buurt kwam. Die automatisch gekozen methode krijgt dan alle geschiedenis om de voorspelling te produceren. Bekijk deze blog voor meer informatie over de modelselectie https://smartcorp.com/uncategorized/statistical-forecasting-how-automatic-method-selection-works/

Voor de meeste tijdreeksen kan dit proces trends, seizoensgebondenheid en gemiddeld volume nauwkeurig vastleggen. Maar soms komt een gekozen methode wiskundig het dichtst in de buurt van het voorspellen van de achtergehouden geschiedenis, maar projecteert deze niet op een logische manier. Dat betekent dat de door het systeem geselecteerde methode niet de beste is en voor sommigen "moeilijk te voorspellen"

Moeilijk te voorspellen items

Moeilijk te voorspellen items kunnen grote, onvoorspelbare pieken in de vraag hebben, of meestal geen vraag maar willekeurige onregelmatige pieken, of ongebruikelijke recente activiteit. Ruis in de gegevens dwaalt soms willekeurig omhoog of omlaag, en de geautomatiseerde best-pick-methode kan een op hol geslagen trend of een nulpunt voorspellen. Het zal het slechter doen dan gezond verstand en in een klein percentage van een redelijk gevarieerde groep items. U moet deze gevallen dus identificeren en reageren door de prognose te negeren of de invoer van de prognose te wijzigen.

Hoe de uitzonderingen te vinden

De beste werkwijze is om de voorspelde items te filteren of te sorteren om de items te identificeren waarvan de som van de prognose voor het volgende jaar aanzienlijk afwijkt van de overeenkomstige geschiedenis van vorig jaar. De prognosesom kan veel lager zijn dan de historie of andersom. Gebruik de meegeleverde statistieken om deze items te identificeren; vervolgens kunt u ervoor kiezen om overschrijvingen toe te passen op de prognose of de prognose-instellingen te wijzigen.

Hoe de uitzonderingen op te lossen

Wanneer de voorspelling vreemd lijkt, zal een middelingsmethode, zoals Single Exponential Smoothing of zelfs een eenvoudig gemiddelde met behulp van Freestyle, vaak een redelijkere voorspelling opleveren. Als de trend mogelijk geldig is, kunt u alleen seizoensmethoden verwijderen om een onjuist seizoensresultaat te voorkomen. Of doe het tegenovergestelde en gebruik alleen seizoensmethoden als seizoensgebondenheid wordt verwacht maar niet was geprojecteerd in de standaardprognose. U kunt de wat-als-functies gebruiken om een onbeperkt aantal prognoses te maken, te evalueren en te vergelijken en de instellingen verder te verfijnen totdat u vertrouwd bent met de prognose.

Het opschonen van de geschiedenis, met of zonder wijziging van de automatische methodeselectie, is ook effectief bij het produceren van redelijke voorspellingen. U kunt prognoseparameters insluiten om de hoeveelheid geschiedenis die wordt gebruikt om die items te voorspellen of het aantal perioden dat aan het algoritme is doorgegeven, te verminderen, zodat eerdere, verouderde geschiedenis niet langer in aanmerking wordt genomen. U kunt pieken of dalen in de vraaggeschiedenis bewerken die bekende afwijkingen zijn, zodat ze de uitkomst niet beïnvloeden. U kunt ook samenwerken met het Smart-team om automatische detectie en verwijdering van uitschieters te implementeren, zodat gegevens voordat ze worden voorspeld al zijn opgeschoond van deze afwijkingen.

Als de vraag echt intermitterend is, wordt het bijna onmogelijk om "nauwkeurig" per periode te voorspellen. Als een level-loading-gemiddelde niet acceptabel is, kan het effectief zijn om het artikel af te handelen door een voorraadbeleid in te stellen met een doorlooptijdprognose. U kunt er ook voor kiezen om 'hetzelfde als vorig jaar'-modellen te gebruiken die, hoewel ze niet gevoelig zijn voor nauwkeurigheid, algemeen worden geaccepteerd door het bedrijf gezien de alternatieve prognoses.

Ten slotte, als het item zo recent is geïntroduceerd dat de algoritmen niet genoeg input hebben om nauwkeurig te voorspellen, is een eenvoudige gemiddelde of handmatige voorspelling wellicht het beste. U kunt nieuwe items identificeren door te filteren op het aantal historische perioden.

Handmatige selectie van methoden

Zodra u rijen hebt geïdentificeerd waar de prognose niet logisch is voor het menselijk oog, kunt u een kleinere subset van alle methoden kiezen om de prognoserun toe te laten en te vergelijken met de geschiedenis. Met Smart kunt u een beperkte set methoden gebruiken voor slechts één prognoserun of de beperkte set insluiten om te gebruiken voor alle prognoseruns in de toekomst. Verschillende methoden zullen de geschiedenis op verschillende manieren in de toekomst projecteren. Als u een idee heeft van hoe elk werkt, kunt u kiezen welke u wilt toestaan.

Vertrouw op uw prognosetool

Hoe meer u Slimme periode-over-periode gebruikt om uw beslissingen over hoe te voorspellen en welke historische gegevens u in overweging moet nemen, vast te leggen, hoe minder vaak u uitzonderingen zult tegenkomen, zoals beschreven in deze blog. Het invoeren van prognoseparameters is een beheersbare taak wanneer u begint met kritieke items of items met een hoge impact. Zelfs als u geen handmatige beslissingen over prognosemethoden insluit, wordt de prognose elke periode opnieuw uitgevoerd met nieuwe gegevens. Dus een item met een oneven resultaat vandaag kan in de loop van de tijd gemakkelijk voorspelbaar worden.

Gegevensverificatie en -validatie zijn essentieel voor het succes van de implementatie van software die statistische analyse van gegevens uitvoert, zoals Smart IP&O. Dit artikel beschrijft het probleem en dient als een praktische gids om het werk goed te doen, vooral voor de gebruiker van de nieuwe applicatie.

Hoe minder ervaring uw organisatie heeft met het valideren van historische transacties of artikelstamkenmerken, hoe waarschijnlijker het is dat er problemen of fouten zijn opgetreden bij het invoeren van gegevens in het ERP die tot nu toe onopgemerkt zijn gebleven. De 'garbage in, garbage out'-regel betekent dat u prioriteit moet geven aan deze stap van het software-onboardingproces, anders loopt u het risico vertraging op te lopen en mogelijk geen ROI te genereren.

De beste persoon om te bevestigen dat gegevens in uw ERP correct zijn ingevoerd, is uiteindelijk de persoon die de business kent en bijvoorbeeld kan beweren “dit onderdeel behoort niet tot die productgroep”. Dat is meestal dezelfde persoon die Smart opent en gebruikt. Maar ook een databasebeheerder of IT-support kan een sleutelrol spelen door te kunnen zeggen: “Dit onderdeel is afgelopen december door Jane Smith aan die productgroep toegewezen.” Ervoor zorgen dat gegevens correct zijn, is misschien geen vast onderdeel van uw dagelijkse werk, maar kan worden opgesplitst in beheersbare kleine taken waarvoor een goede projectmanager tijd en middelen zal uittrekken.

De softwareleverancier voor vraagplanning die de gegevens ontvangt, speelt ook een rol. Ze zullen bevestigen dat de onbewerkte gegevens zonder problemen zijn opgenomen. De leverancier kan ook afwijkingen in de onbewerkte gegevensbestanden identificeren die wijzen op de noodzaak van validatie. Maar vertrouwen op de softwareleverancier om u gerust te stellen dat de gegevens er goed uitzien, is niet genoeg. U wilt na de livegang niet ontdekken dat u de output niet kunt vertrouwen omdat sommige gegevens "niet kloppen".

Elke stap in de gegevensstroom heeft verificatie en validatie nodig.  Verificatie betekent dat de gegevens in de ene stap nog steeds hetzelfde zijn nadat ze naar de volgende stap zijn gegaan. Validatie betekent dat de gegevens correct en bruikbaar zijn voor analyse. 

De meest voorkomende gegevensstroom ziet er als volgt uit:

Minder vaak wordt de eerste stap tussen ERP-stamgegevens en de gekoppelde bestanden soms overgeslagen, waarbij bestanden niet als interface worden gebruikt. In plaats daarvan is een API die is gebouwd door IT of de leverancier van software voor inventarisoptimalisatie verantwoordelijk voor het rechtstreeks schrijven van gegevens vanuit de ERP naar de gespiegelde database in de cloud. De leverancier zou samenwerken met IT om te bevestigen dat de API werkt zoals verwacht. Maar zelfs in dat geval kan de eerste validatiestap nog steeds worden uitgevoerd. Na opname van de gegevens kan de leverancier de gespiegelde gegevens beschikbaar maken in bestanden voor de DBA/IT-verificatie en bedrijfsvalidatie.

De bevestiging dat de gespiegelde data in de cloud de stroom naar de applicatie voltooit, is de verantwoordelijkheid van de leverancier van software-as-a-service. SaaS-leveranciers testen voortdurend of de software correct werkt tussen de front-end-applicatie die hun abonnees zien en de back-end-gegevens in de clouddatabase. Als de abonnees nog steeds denken dat de gegevens niet kloppen in de applicatie, zelfs nadat ze de interfacing-bestanden hebben gevalideerd voordat ze live gaan, is dat een probleem dat ze moeten bespreken met de klantenondersteuning van de leverancier.

Hoe de interfacing-bestanden ook worden verkregen, het grootste deel van de verificatie en validatie komt toe aan de projectmanager en zijn team. Ze moeten een test van de interfacing-bestanden uitvoeren om te bevestigen:

1. Ze matchen de gegevens in het ERP. En dat alle en alleen de ERP-gegevens die nodig waren om te extraheren voor gebruik in de applicatie, werden geëxtraheerd.
2. Niets "springt eruit" voor het bedrijf als onjuist voor elk van de soorten informatie in de gegevens
3. Ze zijn geformatteerd zoals verwacht.

DBA/IT Verificatie Taken

1. Test het uittreksel:

IT's verificatiestap kan worden gedaan met verschillende tools, waarbij bestanden worden vergeleken of bestanden worden terug geïmporteerd naar de database als tijdelijke tabellen en ze worden samengevoegd met de originele gegevens om een match te bevestigen. IT kan afhankelijk zijn van een query om de gevraagde gegevens naar een bestand te halen, maar dat bestand kan niet overeenkomen. Het bestaan van scheidingstekens of regelretouren binnen de gegevenswaarden kan ertoe leiden dat een bestand afwijkt van de oorspronkelijke databasetabel. Het is omdat het bestand sterk afhankelijk is van scheidingstekens en regelterugloop om velden en records te identificeren, terwijl de tabel niet afhankelijk is van die tekens om de structuur te definiëren.

2. Geen slechte karakters:

Vrije gegevensinvoervelden in het ERP, zoals productbeschrijvingen, kunnen soms zelf regeleinden, tabs, komma's en/of dubbele aanhalingstekens bevatten die de structuur van het uitvoerbestand kunnen beïnvloeden. Regelretouren mogen niet worden toegestaan in waarden die naar een bestand worden geëxtraheerd. Tekens die gelijk zijn aan het scheidingsteken moeten tijdens het extraheren worden verwijderd of er moet een ander scheidingsteken worden gebruikt.

Tip: als komma's het bestandsscheidingsteken zijn, kunnen getallen groter dan 999 niet worden geëxtraheerd met een komma. Gebruik "1000" in plaats van "1000".

3. Bevestig de filters:

De andere manier waarop query-extracten onverwachte resultaten kunnen opleveren, is als voorwaarden voor de query onjuist zijn ingevoerd. De eenvoudigste manier om verkeerde "where-clausules" te voorkomen, is door ze niet te gebruiken. Extraheer alle gegevens en laat de leverancier enkele records eruit filteren volgens de regels die door het bedrijf zijn verstrekt. Als dit leidt tot uittrekbestanden die zo groot zijn dat er te veel rekentijd wordt besteed aan de gegevensuitwisseling, moet het DBA/IT-team met het bedrijf overleggen om precies te bevestigen welke filters op de gegevens kunnen worden toegepast om te voorkomen dat records worden uitgewisseld die geen betekenis hebben voor de gegevensuitwisseling. sollicitatie.

Tip: Houd er rekening mee dat actief/inactief of informatie over de levenscyclus van items niet mag worden gebruikt om records uit te filteren. Deze informatie moet naar de applicatie worden gestuurd, zodat deze weet wanneer een item inactief wordt.

4. Wees consistent:

Het extractieproces moet elke keer dat het wordt uitgevoerd, bestanden met een consistent formaat produceren. Bestandsnamen, veldnamen en positie, scheidingsteken en Excel-bladnaam als Excel wordt gebruikt, numerieke formaten en datumnotaties, en het gebruik van aanhalingstekens rond waarden mogen nooit verschillen van de ene uitvoering van het extract van dag tot dag. Voor elke uitvoering van het uittreksel moet een hands-off rapport of opgeslagen procedure worden opgesteld en gebruikt.

Zakelijke validatie achtergrond

Hieronder vindt u een uitsplitsing van elke validatiestap in overwegingen, met name in het geval dat de leverancier een sjabloonformaat heeft verstrekt voor de gekoppelde bestanden, waarbij elk type informatie in een eigen bestand wordt verstrekt. Bestanden die vanuit uw ERP naar Smart worden verzonden, zijn geformatteerd zodat ze eenvoudig vanuit het ERP kunnen worden geëxporteerd. Dat soort formaat maakt de vergelijking terug naar het ERP een relatief eenvoudige taak voor IT, maar het kan moeilijker zijn voor het bedrijf om te interpreteren. De beste praktijk is om de ERP-gegevens te manipuleren, hetzij door draaitabellen of iets dergelijks in een spreadsheet te gebruiken. IT kan helpen door geherformatteerde gegevensbestanden aan te bieden voor beoordeling door het bedrijf.

Als u zich wilt verdiepen in de interfacing-bestanden, moet u ze begrijpen. De leverancier zal een nauwkeurig sjabloon leveren, maar over het algemeen bestaan de interfacebestanden uit drie typen: catalogusgegevens, artikelkenmerken en transactiegegevens.

• Catalogusgegevens bevatten identifiers en hun attributen. Identificaties zijn typisch voor producten, locaties (dit kunnen fabrieken of magazijnen zijn), uw klanten en uw leveranciers.
• Artikelkenmerken bevatten informatie over producten op locaties die nodig zijn voor analyse van de product- en locatiecombinatie. Zoals:
  • Huidig bevoorradingsbeleid in de vorm van een Min en Max, Bestelpunt, of Herzieningsperiode en Bestelling tot waarde, of Veiligheidsvoorraad
  • Toewijzing primaire leverancier en nominale doorlooptijd en kosten per eenheid van die leverancier
  • Vereisten voor de bestelhoeveelheid, zoals de minimale bestelhoeveelheid, de grootte van de productieserie of veelvouden van bestellingen
  • Actieve/inactieve status van de combinatie product/locatie of vlaggen die de status ervan in de levenscyclus aangeven, zoals pre-obsolete
  • Attributen voor groepering of filtering, zoals toegewezen inkoper/planner of productcategorie
  • Actuele voorraadinformatie zoals bij de hand, op bestelling en in transithoeveelheden.
• Transactiegegevens bevatten verwijzingen naar identifiers samen met datums en hoeveelheden. Zoals de verkochte hoeveelheid in een verkooporder van een product, op een locatie, voor een klant, op een datum. Of hoeveelheid geplaatst op inkooporder van een product, naar een locatie, van een leverancier, op een datum. Of hoeveelheid gebruikt in een werkorder van een componentproduct op een locatie op een datum.

Catalogusgegevens valideren

Als u eerst de catalogusgegevens bekijkt, hebt u mogelijk catalogusbestanden die lijken op deze voorbeelden:

1: Controleer op een redelijk aantal catalogusrecords

Open elk bestand met catalogusgegevens in een spreadsheetprogramma zoals Google Spreadsheets of MS Excel. Beantwoord deze vragen:

1. Is het recordaantal in de marge? Als u ongeveer 50.000 producten heeft, zouden er niet slechts 10.000 rijen in het bestand moeten staan.
2. Als het een kort bestand is, bijvoorbeeld het locatiebestand, kunt u precies bevestigen dat alle verwachte identifiers erin staan.
3. Filter op elke attribuutwaarde en bevestig nogmaals dat het aantal records met die attribuutwaarde zinvol is.

2: Controleer de juistheid van waarden in elk attribuutveld

Iemand die weet wat de producten zijn en wat de groepen betekenen, moet de tijd nemen om te bevestigen dat het echt goed is, voor alle attributen van alle catalogusgegevens.

Dus als uw productbestand de attributen bevat zoals in het bovenstaande voorbeeld, zou u filteren op Status van Actief en controleren of alle resulterende producten daadwerkelijk actief zijn. Filter vervolgens op Status van Inactief en controleer of alle resulterende producten daadwerkelijk inactief zijn. Filter vervolgens op de eerste groepswaarde en bevestig dat alle resulterende producten in die groep zitten. Herhaal dit voor Groep2 en Groep3, enz. Herhaal dit voor elk attribuut in elk bestand.

Het kan helpen om deze validatie uit te voeren met een vergelijking met een reeds bestaand en vertrouwd rapport. Als u om welke reden dan ook een andere spreadsheet heeft die producten per groep weergeeft, kunt u de interfacing-bestanden daarmee vergelijken. Mogelijk moet u vertrouwd raken met de functie VERT.ZOEKEN die helpt bij het vergelijken van spreadsheets.

Artikelkenmerkgegevens valideren

1: Controleer op een redelijk aantal itemrecords

De bevestiging van de itemattribuutgegevens is vergelijkbaar met de catalogusgegevens. Bevestig dat het aantal product/locatie-combinaties logisch is in totaal en voor elk van de unieke itemkenmerken, één voor één. Dit is een voorbeeldbestand met artikelgegevens:

2: Zoek en verklaar rare getallen in het itembestand

Er zijn meestal veel numerieke waarden in de itemattributen, dus "rare" cijfers verdienen een beoordeling. Om gegevens voor een numeriek attribuut in een willekeurig bestand te valideren, zoekt u waar het nummer is:

• Ontbreekt volledig
• Gelijk aan nul
• Minder dan nul
• Meer dan de meeste anderen, of minder dan de meeste anderen (sorteer op die kolom)
• Helemaal geen nummer, terwijl het zou moeten zijn

Een speciale overweging van bestanden die geen catalogusbestanden zijn, is dat ze mogelijk niet de beschrijvingen van de producten en locaties tonen, alleen hun identifiers, die voor u betekenisloos kunnen zijn. U kunt kolommen invoegen voor de product- en locatiebeschrijvingen die u gewend bent te zien en deze in de spreadsheet invullen om u te helpen bij uw werk. De VLOOKUP-functie werkt hier ook voor. Of u nu wel of niet een ander rapport hebt om het Items-bestand mee te vergelijken, u hebt de catalogusbestanden voor Producten en Locatie met zowel de identifier als de beschrijving voor elke rij.

3: Controle ter plaatse

Als u gefrustreerd bent dat er te veel attribuutwaarden zijn om binnen een redelijke tijd handmatig te controleren, is steekproefsgewijze controle een oplossing. Het kan worden gedaan op een manier die waarschijnlijk problemen oppikt. Haal voor elk attribuut een lijst op met de unieke waarden in elke kolom. U kunt een kolom naar een nieuw blad kopiëren en vervolgens de functie Duplicaten verwijderen gebruiken om de lijst met mogelijke waarden te bekijken. Met het:

1. Bevestig dat er geen attribuutwaarden aanwezig zijn die dat niet zouden moeten zijn.
2. Het kan moeilijker zijn om te onthouden welke attribuutwaarden ontbreken die er zouden moeten zijn, dus het kan helpen om naar een andere bron te kijken om u eraan te herinneren. Als bijvoorbeeld Groep1 tot en met Groep12 aanwezig zijn, kunt u een andere bron controleren om te onthouden of dit alle mogelijke groepen zijn. Zelfs als het niet vereist is voor de interfacing-bestanden voor de applicatie, kan het voor IT gemakkelijk zijn om een lijst te extraheren van alle mogelijke groepen die in uw ERP staan, die u kunt gebruiken voor de validatie. Als u extra of ontbrekende waarden vindt die u niet verwacht, breng dan een voorbeeld van elk naar IT om te onderzoeken.
3. Sorteer alfabetisch en scan naar beneden om te zien of twee waarden vergelijkbaar zijn, maar enigszins verschillen, misschien alleen in interpunctie, wat zou kunnen betekenen dat in één record de attribuutgegevens onjuist zijn ingevoerd.

Controleer voor elk type item, misschien één van elke productgroep en/of locatie, of alle attributen in elk bestand correct zijn of op zijn minst een sanity check doorstaan. Hoe meer u een breed scala aan items kunt controleren, hoe kleiner de kans dat u problemen zult hebben nadat ze live zijn gegaan.

Transactiegegevens valideren

Transactiebestanden kunnen allemaal een vergelijkbare indeling hebben:

1: Vind rare getallen in elk transactiebestand en leg ze uit

Deze moeten worden gecontroleerd op "rare" getallen in het veld Hoeveelheid. Dan kunt u doorgaan naar:

1. Filter op datums buiten het verwachte bereik of ontbrekende verwachte datums.
2. Zoek waar transactie-ID's en regelnummers ontbreken. Dat zouden ze niet moeten zijn.
3. Als er meer dan één record is voor een bepaalde combinatie van transactie-ID en transactieregelnummer, is dat dan een vergissing? Anders gezegd, moeten dubbele records hun hoeveelheden bij elkaar optellen of is dat dubbeltelling?

2: Sanity check opgetelde hoeveelheden

Voer een gezond verstand uit door te filteren op een bepaald product waarmee u bekend bent, en filter op een herkenbare periode zoals vorige maand of vorig jaar, en som de hoeveelheden op. Is dat totale bedrag wat u voor dat product in dat tijdsbestek verwachtte? Als u informatie heeft over het totale gebruik buiten een locatie, kunt u de gegevens op die manier splitsen om de hoeveelheden op te tellen en te vergelijken met wat u verwacht. Draaitabellen zijn handig voor verificatie van transactiegegevens. Met hen kunt u de gegevens bekijken zoals:

Het jaarlijkse totaal van de producten kan eenvoudig te controleren zijn als u de producten goed kent. Of u kunt VERT.ZOEKEN gebruiken om attributen toe te voegen, zoals een productgroep, en daarop draaien om een hoger niveau te zien dat vertrouwder is:

3: Sanity check telling van records

Het kan helpen om een aantal transacties weer te geven in plaats van een som van de hoeveelheden, vooral voor inkoopordergegevens. Zoals:

En/of dezelfde samenvatting op een hoger niveau, zoals:

4: Controle ter plaatse

Steekproefsgewijs controleren van de juistheid van een enkele transactie, voor elk type artikel en elk type transactie, voltooit de due diligence. Besteed speciale aandacht aan welke datum aan de transactie is gekoppeld en of deze geschikt is voor de analyse. Datums kunnen een aanmaakdatum zijn, zoals de datum waarop een klant een bestelling bij u heeft geplaatst, of een beloftedatum, zoals de datum waarop u verwachtte te leveren op de bestelling van de klant op het moment dat u deze aanmaakte, of een uitvoeringsdatum, wanneer u daadwerkelijk heeft geleverd op de bestelling. Soms wordt een beloftedatum gewijzigd dagen nadat de bestelling is gemaakt als deze niet kan worden gehaald. Zorg ervoor dat de gebruiksdatum de werkelijke vraag van de klant naar het product zo goed mogelijk weergeeft.

Wat te doen met slechte gegevens 

Als er weinig of eenmalig foutieve invoer is, kunt u de ERP-records met de hand bewerken zodra ze worden gevonden, waardoor uw cataloguskenmerken worden opgeschoond, zelfs nadat de applicatie live is gegaan. Maar als grote hoeveelheden attributen of transactiehoeveelheden niet kloppen, kan dit een intern project ertoe aanzetten om gegevens opnieuw correct in te voeren en mogelijk om het proces te wijzigen of te documenteren dat moet worden gevolgd wanneer nieuwe records in uw ERP worden ingevoerd.

Er moet voor worden gezorgd dat de implementatie van de SaaS-applicatie niet te lang op zich laat wachten tijdens het wachten op schone attributen. Verdeel het werk in brokken en gebruik de applicatie om eerst de opgeschoonde gegevens te analyseren, zodat het gegevensopschoningsproject parallel loopt met het halen van waarde uit de nieuwe applicatie.