Vad leverantörsstyrd lagerhållning kräver att båda parter delar
Det kommersiella avtalet sätter målen. Datautbytet avgör om de kan nås.
- Aktuellt lagersaldo: vad köparens affärssystem eller lagersystem innehåller just nu, per plats, och den siffra som påfyllningsbeslutet vilar på
- Förbrukning eller försäljning: hur snabbt lagret förbrukas, vilket är det som förvandlar en nivå till en prognos
- Överenskomna minimi- och maximinivåer: intervallet som leverantören fyller på till, vilket kan variera beroende på artikel, plats och säsong
- Inkommande och under transport: vad leverantören redan har skickat, så att samma brist inte täcks två gånger
- Avvikelser och justeringar: skador, avskrivningar och lagerflyttar som förändrar läget utan att en försäljning har skett
De två första punkterna är de som inköpare tvekar inför, eftersom att dela dem innebär att visa leverantören hur mycket de har i lager och hur snabbt de säljer det. Det är ett kommersiellt avslöjande lika mycket som ett tekniskt, och det är värt att ta ett medvetet beslut snarare än att låta det ske av gammal vana.
Varför slutar det med att VMI körs via kalkylblad?
En fil är det snabbaste att komma överens om. Ingen av parterna vill att pilotprojektet ska vänta på ett integrationsprojekt, så det första utbytet blir en veckovis lagerrapport via e-post. Upplägget fungerar sedan tillräckligt bra för att ingen ska se anledning att se över metoden.
Det är den veckovisa takten som brister. En leverantör som planerar påfyllning utifrån en sju dagar gammal lagersiffra gissar sig till den senaste veckan, vilket är precis den period som avgör om köparen får slut på varor. Leverantören kompenserar detta genom att hålla ett säkerhetslager, vilket återinför de lagerkostnader som leverantörsstyrd lagerhållning var tänkt att eliminera.
Skalbarhet gör det snarare värre än mer rutinmässigt. En leverantör som hanterar upplägget för tjugo kunder måste stämma av tjugo olika kalkylbladsformat, tjugo definitioner av vad som räknas som tillgängligt och tjugo avsändare som ibland glömmer bort sig. Att lägga till den tjugoförsta kunden är aldrig enklare än den första, vilket är samma matematik som gör leverantörsonboarding dyr.
Inget av detta märks genom stora haverier. Det visar sig som kostnader för båda parter i samarbetet.
Vad svagt datautbyte kostar ett program för leverantörsstyrd lagerhållning
En inaktuell lagerstatus kostar båda parter, vilket är anledningen till att dessa samarbeten ofta tyst återgår till konventionell beställning.
- Säkerhetslager som motverkar syftet: leverantören håller extra lager för att täcka datadröjsmål, och någon betalar för det lagret
- Lagerbrist som köparen inte förutsåg: köparen slutade planera påfyllning och leverantören arbetade utifrån inaktuella siffror
- Dubbla leveranser: en brist som täckts två gånger eftersom varor under transport inte var synliga i den lagerstatus leverantören såg
- Tvister om vad som faktiskt fanns i lager: där konsignationsvillkor gäller avgör lagerstatusen när äganderätt och betalning överförs
Den sista punkten är den mest kritiska, eftersom den förvandlar ett dataproblem till ett faktureringsproblem. Innan något av detta kan åtgärdas finns det dock en fråga som köparen måste reda ut först.
Leverantörsstyrd lagerhållning är en förtroendefråga med ett tekniskt svar
Köpare tvekar att dela förbrukningsdata av skäl som är kommersiellt rationella. En leverantör som kan se exakt hur snabbt en produkt säljer vet mer om köparens verksamhet än vad köparen kanske vill. Den kunskapen är också användbar i nästa prisförhandling.
Den vanliga lösningen är omfattning. En leverantör behöver lager- och förbrukningsdata för de artiklar de levererar, på de platser de fyller på, och inget utöver det. Det är ett betydligt mer begränsat utlämnande än systemåtkomst, och det är tillräckligt för att kunna planera utifrån.
Det förvandlar en styrningsfråga till ett konfigurationsbeslut. En köpare som kan exponera exakt de artiklar, platser och fält som avtalats kan tacka ja till upplägget utan att exponera något annat. En köpare vars enda alternativ är ett fullständigt lagerutdrag tvingas välja mellan upplägget och utlämnandet, och väljer då oftast kalkylarket.
Det finns tre sätt som utbytet vanligtvis sker på, och inget av dem är neutralt. EDI och API:er stöder lager- och förbrukningsmeddelanden på rätt sätt och passar partners som redan använder dem, vilket exkluderar många medelstora leverantörer. Leverantörsportaler låter en säljare logga in och titta, vilket fungerar fram till dess att de behöver siffrorna i sitt eget planeringssystem. Schemalagt filutbyte är standard, och det sätter taket för hur aktuellt ett påfyllningsbeslut kan vara.
Hur stöder en integrationsplattform leverantörsstyrt lager?
En aktuell lagerstatus måste nå leverantören begränsad till de artiklar och platser som omfattas av avtalet, och i ett format som deras planeringssystem kan läsa. Att uppfylla alla tre kraven samtidigt kräver ett lager mellan de två företagen snarare än en anslutning direkt in i köparens eget affärssystem. Det lagret är en integrationsplattform som tjänst (iPaaS).
Att dela lager- och förbrukningsdata över en företagsgräns är ett annat krav än att dela dem internt. Endast vissa fält får lämna företaget. Leverantören kan inte förväntas acceptera köparens interna datamodell, och båda parter kan senare behöva bevisa vad som skickats. Att upprätthålla en omfattning, anpassa efter partner och logga utbytet är tre krav som en filöverföring inte uppfyller.
Alumio är en integrationsplattform utformad för utbyten som korsar företagsgränser, där omfattning är lika viktigt som hastighet. Fyra funktioner inom Alumio-plattformen möjliggör detta.
- Status delas i takt med att den ändras: en händelsestyrd dataväg inom Alumio skickar lager- och förbrukningsdata till leverantören i takt med att rörelser sker, så att påfyllning planeras utifrån dagsläget snarare än förra måndagen
- Begränsat till det som avtalats: åtkomstkontroll och konfiguration per partner exponerar endast de artiklar, platser och fält som ingår i avtalet, så att den kommersiella gränsen upprätthålls snarare än att man förlitar sig på tillit
- Varje partners format hanteras: en datatransformator konverterar en intern lagermodell till EDI-, API- eller filformat per leverantör, så att partnerns förmåga inte dikterar den interna designen
- Ett register som båda parter kan kontrollera: detaljerade loggar fångar vad som skickades och när, vilket är det som löser en tvist om leverans eller underskott utan behov av tidskrävande rekonstruktioner
Konfiguration hanterar omfattnings- och mappningsregler, och Alumio iPaaS tillhandahåller en kodtransformator för de fall där det är mer effektivt att skriva kod än att konfigurera. Att utöka upplägget till en tredje och fjärde leverantör kostar en bråkdel av den första, vilket är det som gör att det kan spridas över hela leverantörsbasen.
Leverantörsstyrt lager som båda parter kan lita på
Leverantörsstyrt lager motiveras vanligtvis utifrån köparens rörelsekapital och leverantörens prognossynlighet, och båda fördelarna är helt beroende av kvaliteten på den delade informationen.
Tre roller är inblandade, varav två arbetar för olika företag. Köparens inköps- eller logistikchef har släppt kontrollen över påfyllningsbesluten och förlitar sig nu på att någon annan fattar dem. Leverantörens kundansvariga eller planerare måste uppnå en viss servicenivå med hjälp av data de inte själva kontrollerar. Ekonomiavdelningen på båda sidor ansvarar för konsignationslagret, där lagersaldot avgör när äganderätt och betalningsansvar övergår.
En veckovis fil gör att alla tre kan arbeta, om än ineffektivt. En aktuell lagerstatus gör att leverantören kan hålla en mindre buffert och samtidigt undvika lagerbrist – vilket är det resultat avtalet utlovade, men som kalkylark sällan levererar. Att köra utbytet via en integrationsplattform är det som gör det ekonomiskt försvarbart att hålla informationen uppdaterad. Det är också skillnaden mellan ett upplägg som kan skalas upp till hela leverantörsbasen och ett som i tysthet återgår till vanliga inköpsordrar.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
