Vad en punchout-katalog faktiskt gör
En punchout-session sker i fyra steg. Varje steg korsar gränsen mellan två företags system.
- Köparen gör en punchout: deras inköpssystem skickar en förfrågan som identifierar köparen och deras organisation, så att leverantörens webbplats öppnas med vetskap om vem som handlar
- Prissättningen anpassas per konto: butiken visar köparens avtalspriser och aktuellt lagersaldo, inte en publik katalog
- Varukorgen returneras som en inköpsrekvisition: köparen för över varukorgen till sitt eget inköpssystem istället för att gå till kassan på leverantörens webbplats
- Godkännande och beställning sker hos köparen: rekvisitionen följer köparens interna godkännandeprocess och anländer sedan som en inköpsorder
Ordern läggs aldrig i leverantörens webbshop. Det är den del som leverantörer ofta tycker verkar ologisk, men det är precis därför köparens inköpsteam kräver det.
Varför kräver stora företag punchout?
Inköpssystem finns till för att efterleva policys. Inköp kategoriseras mot budgetar, godkännanden styrs av belopp och varje åtagande hamnar på en granskningsbar plats. En köpare som lämnar systemet för att beställa på en leverantörs webbplats kringgår hela denna process.
Stora organisationer svarar med att kräva att alla inköp sker inuti inköpssystemet. Att handla någon annanstans klassas som "maverick spend", vilket inköpsteam mäts på att minska. I det läget konkurrerar inte leverantörens webbshop med andra webbshoppar. Den konkurrerar med köparens egen policy, och den förlorar.
Punchout löser konflikten istället för att motarbeta den. Leverantören behåller katalogen, prislogiken och produktupplevelsen. Köparen behåller godkännandekedjan och revisionsspåret. Ingen av parterna behöver ge upp det som är affärskritiskt för dem.
Vad förlorar leverantörer utan en punchout-katalog?
En leverantör utan punchout får inte bara en långsammare kanal. De blir uteslutna från konton som annars skulle ha handlat. Förlusten visar sig på ett tydligt sätt:
- Borttagen från listan över godkända leverantörer: inköpsteam väljer ut leverantörer som deras system kan nå, och en leverantör som inte kan nås via punchout filtreras bort innan några affärssamtal ens har påbörjats
- Beställningar som innebär merarbete: utan punchout skickar stora konton inköpsordrar via e-post eller EDI, och någon måste manuellt knappa in dem i affärssystemet
- Pristvister vid fakturering: när köparen beställer från ett kalkylblad eller en PDF-katalog skiljer sig det förväntade priset från det fakturerade, och ekonomiavdelningen får ta smällen
- Ingen insyn i kontot: beställningar kommer in utan den information om surfbeteende, offerthistorik eller produktintresse som en integrerad butik skulle ha fångat upp
Vad punchout kräver av dina system
Punchout ser ut som en e-handelsfunktion men fungerar som ett integrationskrav. Fyra saker måste stämma i det ögonblick köparen surfar.
- Kontospecifik prissättning på begäran: det avtalade priset för den specifika köparen, hämtat i realtid från affärssystemet istället för från en synkroniserad tabell som snabbt blir inaktuell
- Reell lagersaldo: lagersaldo som tar hänsyn till allokeringar och inleveranser, eftersom en punchout-varukorg som inte kan levereras skadar kundrelationen mer än en långsam webbplats skulle göra
- Korrekt hantering av identitet: punchout-förfrågan innehåller inloggningsuppgifter som varje gång måste kopplas till rätt konto och avtal i dina system
- Rätt dokumentformat: de flesta inköpsplattformar talar cXML, vissa talar OCI, och rekvisitionen och ordern måste vara läsbara för båda parter
Endast den fjärde handlar egentligen om punchout som standard, och den ligger vid sidan av EDI-integration som de flesta leverantörer redan kör för sina största konton. De tre första är vanliga integrationsproblem som punchout synliggör. En inköpare i sitt eget inköpssystem har inget tålamod med en sida som tar sex sekunder att prissätta.
Hur en integrationsplattform hanterar en punchout-katalog
Leverantörer når punchout på tre sätt. Ett inköpsnätverk eller en leverantörsportal kan vara värd för katalogen åt dig, vilket fungerar och debiteras per transaktion samtidigt som kundrelationen hålls på ett stegs avstånd. Vissa e-handelsplattformar erbjuder punchout-moduler som hanterar protokollet, men som fortfarande behöver kopplas till det affärssystem (ERP) där avtalspriserna finns. Att bygga det direkt mot varje inköpares inköpssystem är möjligt, men det multipliceras med varje nytt storkonto.
En integrationsplattform som tjänst (iPaaS) kopplar samman butiken med de system som sitter på svaren. På Alumio iPaaS tar det arbetet fyra former:
- Prissatt medan inköparen väntar: en realtidsproxy kontrollerar avtalspriser och lager i affärssystemet medan inköparen surfar, så att siffran på skärmen är samma siffra som finns i affärssystemet
- Format översatta åt båda hållen: en datatransformator konverterar cXML- eller OCI-dokument till vad affärssystemet förväntar sig och tillbaka igen, så att inköpsstandarder inte dikterar utformningen av din backoffice
- Hålls kvar när ett system är långsamt: en inbyggd lagring håller referensdata redo och köar inkommande order, så att ett affärssystem under hög belastning inte avbryter en pågående köpsession
- Spårbart per session: detaljerade loggar registrerar vilken inköpare som såg vilket pris och när, vilket är det som löser en fakturatvist utan behov av utredning
Dessa flöden konfigureras snarare än att byggas för hand per köpare, med en kodtransformator tillgänglig där konfiguration inte kan uttrycka en regel och där kodning föredras. Leeuwerik Plaat, en nederländsk B2B-leverantör av skivmaterial, säljer till kundspecifika avtalspriser. Alumio flyttar deras produkter, lager och priser per kund i realtid mellan affärssystemet Kerridge och Adobe Commerce. Inköpare beställer dygnet runt till det pris som deras avtal anger.
Vad en punchout-katalog är värd för en leverantör
Punchout finansieras sällan utifrån sina egna meriter. Det finansieras när en stor kund efterfrågar det, och svaret avgör om kunden stannar eller inte.
De leverantörer som behandlar det som infrastruktur snarare än ett engångsbygge hamnar i ett bättre läge. Genom att köra via en integrationsplattform ansluts varje ny företagskund till ett mönster som redan finns. Inköpsteam slutar gå runt dem, och priset som når köparen är det pris som ekonomiavdelningen förväntar sig att fakturera.
Vad verksamheten får tillbaka är tillgång till konton som tidigare var oåtkomliga, order som anländer strukturerade istället för som e-postbilagor, och en kanal som skalar med säljteamet snarare än med integrationskön.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
