Leverancier A is op basis van OTIF net zo slecht als leverancier B en C, terwijl hier toch wel degelijk verschil in zit. Ik zou veel liever met leverancier C van doen hebben dan met B. Door tijdigheid en aantallen apart te meten, kun je onderscheid maken tussen leveranciers die steeds maar een dag te laat zijn of steeds 20 dagen. Of leveranciers die 99 stuks leveren en de volgende dag de ontbrekende 1, en leveranciers die 25 stuks leveren en de resterende 75 stuks pas na 3 weken.
Ik schreef eerder dat er 4 beoordelingscriteria zijn die je beter kunt vermijden, en die hebben allemaal betrekking op OTIF. Je kun OTIF namelijk berekenen voor orders en orderregels, en je kunt OTIF-exact berekenen (er moet precies op tijd geleverd worden) of OTIF-early berekenen (te vroeg leveren is ook op tijd). Door deze met elkaar te combineren krijg je 4 OTIF mogelijkheden. Maar ik maak eigenlijk te veel woorden vuil aan iets wat je juist niet moet toepassen.
Basis+1: de bevestigde datum
Indien het lukt om ook de door de leverancier bevestigde datum uit het IT-systeem te halen, dan ontstaan er nog 4 andere beoordelingsmogelijkheden.
Wordt er bevestigd (ja/nee)? (D1)
In organisaties waar leveranciers niet allemaal met elektronische berichten (zoals EDI) werken, komen orderbevestigingen nog vaak per mail binnen. Deze moeten
vervolgens in het systeem gezet worden. Orderbevestigingen zijn van belang, om zeker te weten dat de inkooporders goed ontvangen zijn, goed overgenomen zijn en dat de goederen op tijd gaan komen. Meten of de leverancier de order bevestigt, is daarom geen overbodige luxe. Je voorkomt daarmee verrassingen en krijgt betere controle over je bestelproces. Men moet er echter wel op kunnen vertrouwen dat de orderbevestigingen ook daadwerkelijk in het systeem gezet worden. Heeft men daar twijfels over, meet het dan wel, maar reken dit de leverancier dan ook niet aan (weging 0).
Betrouwbaarheid bevestiging (D2)
Daarnaast kun je kijken of de orderbevestiging overeenkomt met de werkelijkheid: ze zeiden dat er op de 10e geleverd zou worden, maar klopte dat ook? Hoeveel dagen zitten er tussen de beloofde en werkelijke leverdatum?
Aantal bevestigingen (D3)
Indien het IT-systeem dit registreert, kun je ook kijken naar het aantal bevestigingen per order. Een leverancier die elke dag een nieuwe leverdatum bevestigt, tja, daar heb je precies niets aan. Ook als het IT systeem dit niet apart opslaat (de nieuwe bevestigde datum overschrijft de vorige datum), dan kan een goed leveranciersbeoordelingssysteem alle wijzigingen registreren.
Flexibiliteit (E)
Je kunt ook een indruk krijgen in hoeverre de leverancier in staat is zich aan te passen aan het grillige bestelpatroon van de klant. Gedragen ze zich als het Congolees ministerie van Lastige Zaken of proberen ze het de klant echt zo veel mogelijk naar de zin te maken? Je kunt namelijk meten hoeveel dagen er zitten tussen de datum die op de (spoed)order gevraagd wordt en de datum die door de leverancier bevestigd wordt.
Basis+2: standaard levertijd
Echt interessant wordt het indien ook de standaard levertijd beschikbaar is. Bij goed artikelbeheer wordt ook de standaard levertijd van de leverancier in het IT-systeem geregistreerd. “Als je iets bij ons bestelt moet je rekening houden met een standaard
levertijd van 3 weken, behalve voor ons assortiment “gekke kleurtjes”, daar hebben we 5 weken voor nodig”. Betrek je dit gegeven in je beoordeling, dan wordt het ineens mogelijk niet alleen de leverancier beter te beoordelen, maar vooral ook je eigen bestelgedrag.
Klopt de standaard levertijd? (F)
Door te kijken naar het aantal dagen verschil tussen standaard leverdatum en de werkelijk leverdatum krijg je een indruk of de standaard levertijd juist in het systeem staat. Hier zitten echter twee kanten aan:
- òf de eigen organisatie zit zelf te slapen, omdat ze de standaard levertijd slecht onderhouden. Ofwel de updates van de leverancier worden niet overgenomen, of er wordt niet geregeld, actief aan de leveranciers gevraagd wat de huidige standaard levertijden zijn.
- òf het kan zijn dat de leverancier gewoon verkeerde informatie afgeeft die in werkelijkheid niet blijkt te kloppen.
Je zit dus met het dilemma of je de leverancier nu wel of niet kunt afrekenen voor foute standaard levertijden in het systeem. Indien je van mening bent dat het IT-systeem doorgaans de actuele standaardlevertijden bevat, dan kun je de score op dit punt gerust laten meewegen in je beoordeling van de leverancier.
Houden we ons aan de standaard levertijd? (G)
Zoals eerder gezegd, leveranciers krijgen vaak ten onrechte een slechte beoordeling omdat de klant te weinig rekening houdt met de afgesproken standaard levertijd. Er zijn orders die direct de volgende dag al geleverd moeten worden, terwijl 3 weken standaard is afgesproken. Ik zie het als essentieel dat bij de interpretatie van de leveranciersprestaties, ook het eigen gedrag onder de loep genomen wordt. Dit is uitgebreid aan de orde gekomen in mijn eerste blog (wat is je eigen rol in de prestaties van de leverancier).
Dit criterium is gemakkelijk te meten door te kijken naar het aantal dagen verschil tussen de gevraagde datum en de afgesproken standaard leverdatum. Omdat dit een interne meting is, dient hier een gewicht van 0 aan gekoppeld te worden (je kunt er de leverancier niet op afrekenen).
Lengte standaard levertijd (H)
Het is niet alleen mogelijk een leverancier af te rekenen op de lengte van zijn werkelijke levertijd, maar je kunt ook de standaard levertijd beoordelen. Immers, hoe langer de standaard levertijd, hoe meer voorraad er doorgaans aangehouden moet worden.
Werkdagen/kalenderdagen
Bij alle criteria die hierboven besproken zijn, wordt gekeken naar het verschil in dagen tussen moment A en moment B. Het is daarbij beter om te rekenen in werkdagen dan in kalenderdagen. Een levering die voor vrijdag gevraagd was, maar pas op maandag geleverd wordt, is dan slechts 1 dag te laat en niet 3. Een goed leveranciersbeoordelingssysteem kan niet alleen rekening houden met de weekenden (als optie), maar moet ook de mogelijkheid bieden om een lijst van feestdagen op te geven, zodat deze niet als werkdagen worden gezien.
In mijn verhaal geef ik overigens veel voorbeelden op basis van dagen. Er zijn echter branches die de leveranciersbetrouwbaarheid meten in uren. Dat maakt voor de discussie niet uit. Dergelijke lezers kunnen eenvoudig weg het woord dagen vervangen door uren.
Kwaliteit van data
Vaak wordt aangevoerd dat leveranciersbeoordeling in een organisatie niet gaat werken omdat de kwaliteit van de data onvoldoende is. In 9 van de 10 gevallen is het meer een excuus om niet aan de slag te gaan. Ik verwijs naar deel 1 voor de uitgebreidere uitleg, maar gebrekkige data hoeft absoluut geen spelbreker te zijn:
- Een goed leveranciersbeoordelingssysteem kan de fouten corrigeren of eruit filteren en zodoende de datakwaliteit continu verhogen.
- Goed, we weten dat de data niet perfect is en dat er fouten in zitten. Maar deze fouten passen we wel consequent toe. Het gaat uiteindelijk niet zo zeer om het absolute cijfer (u scoort een 5), maar veel meer om de beweging (u bent gestegen van een 5 naar een 6, en dat is een verbetering van 20%. Overigens, uw grootste concurrent scoort een 8).
- Je kunt er voor kiezen zaken wel te meten, maar er een gewicht van 0 aan te hangen, zodat de leverancier er niet op afgerekend wordt. Het verschaft dan wel heel veel inzicht. En als de kwaliteit zich na enige tijd wel verbetert, kan er wel een gewicht aan gehangen worden. Zonder leveranciersbeoordeling zou dit inzicht en de verbetering waarschijnlijk niet tot stand gebracht zijn.
Meer dan levertijd alleen
IT-data kan niet alleen gebruikt worden om zaken omtrent levertijd en compleetheid te beoordelen. Er is vaak nog veel meer data beschikbaar die gebruikt kan worden om de leverancier automatisch op te beoordelen, zodat de beoordeling nog breder wordt. Een paar voorbeelden:
- Dit kan in geld (de afwijking gerelateerd aan de ingekochte omzet bij de desbetreffende leverancier) en/of in aantallen (aantal facturen met een verschil t.o.v. alle facturen in die periode van de desbetreffende leverancier).
Crediteringen. Indien het mogelijk is om de crediteringen te scheiden van eventuele bonus- of kickbackbetalingen, dan is dat een prima beoordelingscriterium. Ook hier kan men dat in geld en/of in aantallen doen. Een creditering is 9 van de 10 keer een indicatie dat de leverancier een fout heeft gemaakt. Ja, het kan zijn dat de klant zelf een fout heeft gemaakt, en dan is het niet juist de leverancier af te rekenen voor zijn flexibiliteit. Maar als deze ‘fout’ er consequent in zit, is het nog steeds interessant de scores te
- vergelijken met andere leveranciers en om de ontwikkeling van de score in de gaten te houden.
- Standaard onderdeel van elke leveranciersovereenkomst zouden de betalingscondities moeten zijn. Sommige organisaties krijgen het voor elkaar om alle leveranciers aan de dezelfde conditie te laten voldoen. In de meeste gevallen echter zijn de betalingscondities onderdeel van het onderhandelingspalet. In Nederland variëren ze grofweg van 90 dagen tot 8 dagen 4% en alles wat daar tussenin zit. Een goed leveranciersbeoordelingssysteem is in staat om zowel dagen als de betalingskorting om te zetten in één rapportcijfer, gebruikmakend van een interne rekenrente.
- Zoals ook in deel 1 besproken, sommige bedrijven registreren niet alleen het moment dat een zending geleverd wordt, maar ook het moment dat deze aan de voorraad wordt toegevoegd. Het komt geregeld voor dat goederen door drukte/onderbezetting langere tijd bij goederenontvangst blijven staan. Het kan vervolgens gebeuren dat een leverancier aangesproken wordt op zijn latere leveringen, maar in werkelijkheid blijkt het probleem bij goederenontvangst te liggen. Door het verschil in dagen tussen aankomst en opboeken te meten, krijgt men een beter beeld van de eigen prestaties en kan men genuanceerder naar de prestaties van de leverancier kijken.
- Sommige retailers en groothandelaren hebben bij veel merkproducten nog maar weinig invloed op de marge die ze kunnen maken. De fabrikant zorgt met al zijn marketing voor een goede vraag uit de markt, en de distributeurs concurreren elkaar vervolgens dood. Zwart/wit gezegd, de verkoopprijs wordt door de markt bepaald, de inkoopprijs door de fabrikant, en de handelaar zit er tussenin. Het is in dat geval slim om de hoogte van de marge die de handelaar kan maken de fabrikant aan te rekenen, en dus onderdeel te laten zijn van de leveranciersbeoordeling.
- Iets dergelijks kan ook gezegd worden over de omloopsnelheid van de voorraad van een assortiment (omzet gedeeld door de waarde gemiddelde voorraad). Een hoge omloopsnelheid duidt op veel vraag uit de markt in combinatie met een kleine voorraad., waarvoor de leverancier in de beoordeling beloond kan worden. Dit is een criterium wat wederom vooral relevant is voor retailers en groothandelaren.
- Omloopsnelheid x Marge. Als je het echt perfect wilt doen, combineer je de twee bovenstaande criteria. ‘Het geeft niet dat we niet zoveel aan het product verdienen, want we verkopen er een miljoen per dag van’. Of ‘we verkopen er niet zo veel van, maar als we wat verkopen, dan maken we een wereldmarge’. In beide voorbeelden levert dit een hoge multi op en dus een hoge score in de leveranciersbeoordeling.
Smal of breed?
Beoordelen op basis van IT-data is geen rocket science en er zijn applicaties die dat perfect voor je kunnen doen. Wil je echter een eerlijkere, brede beoordeling van je leveranciers, waarin ook allerlei andere zaken worden meegenomen, zoals logistiek, financiën, MVO en/of commercie, dan raad ik aan deze beoordelingen met vaste regelmaat op te halen bij de eigen medewerkers. Een goed leveranciersbeoordelingssysteem kan dit geautomatiseerd doen door middel van online enquêtes.
Dit was deel 4 van een serie van 5 over leveranciersbeoordeling:
- Je eigen rol in de prestaties van je leveranciers
- Waar kan ik leveranciersbeoordeling voor inzetten?
- Welk systeem kan ik gebruiken voor leveranciersbeoordeling?
- Welke data kan ik gebruiken bij leveranciersbeoordeling?
- Inkoopprestatiemeting op basis van leveranciersbeoordeling
Mail voor vragen of het business case rekenmodel naar: jp.plieger@wtpbn.com