Varför POS-integration måste fungera i båda riktningarna
Ett kassasystem specificeras vanligtvis som ett försäljningssystem men fungerar som ett lagersystem. Utbytet sker åt båda hållen.
- Försäljning ut: varje transaktion minskar butikslagret, och hur snabbt den informationen sprids avgör hur inaktuell siffran på nätet är
- Lager in: leveranser, överföringar mellan butiker och returer till lager, vilket ändrar tillgängligheten utan att en försäljning sker
- Priser och kampanjer ner: kassan behöver aktuella priser, inklusive kampanjer som kan skilja sig åt mellan butik eller kanal
- Onlinebeställningar in: click-and-collect-reservationer och ship-from-store-plock, som minskar det säljbara lagret innan en kund i butik köper samma vara
Den fjärde punkten är där de flesta implementationer kämpar, eftersom den kräver att onlinekanalen kan reservera lager som en kund står precis bredvid.
Varför avviker butikslagret från systemet?
Den mekaniska orsaken är batch-överföring. När kassor skickar försäljningsdata till huvudkontoret under natten är varje butiks lagersaldo en dag gammalt under större delen av handelsdagen. Det är precis då onlinekunder väljer var de ska hämta sina varor.
Den fysiska verkligheten är den andra orsaken, och den svårare. Varor flyttas, skadas, lämnas i ett provrum eller säljs i ett paket som registrerats mot en annan kod. Inget av detta är ett systemfel, men allt gör att den registrerade siffran avviker från vad som faktiskt finns på hyllan.
Reservationer är den tredje orsaken, och den förvandlar en korrekt siffra till ett brutet löfte. En vara som reserverats för en onlinebeställning ligger kvar på hyllan, och om inte kassan vet att den är reserverad kommer en kund i butiken att köpa den.
En lagersiffra i butiken kan alltså vara helt korrekt och ändå vara osäker att sälja mot. Det är ett annat problem än när två system inte är överens om vem som äger siffran, vilket är vad WMS ERP-integration löser.
Vad en svag POS-integration kostar en återförsäljare
Förlusterna hamnar i de kanaler som är beroende av butikslager, inte i själva butiken.
- Misslyckade upphämtningar: en kund reser till en butik för en vara som systemet angav fanns i lager, vilket är värre än att aldrig erbjuda upphämtning
- Avbokningar vid leverans från butik: en order som skickats till en butik som inte kan expediera den, och som måste omfördelas trots att löftet redan getts
- Säkerhetsmarginaler för butikslager: återförsäljare döljer butikslager för onlinekanaler för att undvika de två första problemen, vilket innebär att säljbara varor hålls tillbaka
- Personal som kringgår systemet: butikspersonal som ringer till andra butiker istället för att lita på skärmen, ett tydligt tecken på att siffran inte anses tillförlitlig
Var och en av dessa landar i en kanal som butiken ursprungligen aldrig var byggd för att betjäna.
Varför POS-integration avgör vad en butik kan expediera
Återförsäljare lade till klicka-och-hämta samt leverans från butik för att använda lager som redan är betalt och finns nära kunden. Antagandet bakom detta är att butikslagret är tillräckligt korrekt för att sälja mot, och de flesta kassasystem är äldre än det antagandet.
Vissa återförsäljare kör den extrema versionen. Van Tilburg, en nederländsk klädkedja, förvarar sina varor för onlineförsäljning direkt i butikerna istället för på ett separat lager. Ett onlineköp måste därför plockas snabbt från butiken, annars riskerar samma vara att säljas två gånger.
Övergången till specialiserade system (best-of-breed) hade resulterat i applikationer som lagrade produkt-, lager- och orderdata i sina egna strukturer. I samarbete med sin digitala byrå Happy Horizon implementerade de integrationsplattformen Alumio för att standardisera data mellan systemen. Lageruppdateringar från egna och externa lager dirigeras nu via Microsoft Dynamics 365 Business Central till deras Scayle-butik, medan produktdata och prissättning hanteras via separata dataflöden. För en återförsäljare i den situationen är kopplingen mellan butik och online en förutsättning för att överhuvudtaget kunna sälja, snarare än bara en effektiviseringsåtgärd.
Begränsningen för omnikanal-logistik ligger därför sällan i lagret, transportören eller butiksfronten. Det handlar om hur snabbt ett köp i en kassa blir ett faktum som resten av verksamheten kan agera utifrån. Det är det som avgör varifrån en order skickas.
Återförsäljare löser detta på ett av tre sätt. En butikssvit som täcker kassasystem (POS), lager och e-handel tar bort gränserna men begränsar valmöjligheterna för andra specialsystem. Inbyggda POS-kopplingar till en e-handelsplattform hanterar lager och försäljning för vanliga kombinationer, men stannar oftast innan de når affärssystemet (ERP) och lagret. Många butikskedjor använder fortfarande nattliga filöverföringar, vilket gör att butikslagret alltid är ett dygn gammalt.
Hur ansluter en integrationsplattform till kassasystemet?
En integrationsplattform som tjänst (iPaaS) kopplar samman system via en central hubb istället för att skapa länkar mellan varje enskilt par. Varje system ansluter till integrationsplattformen en gång. Plattformen flyttar sedan data mellan dem och omformar den under processens gång, så att varje mottagare får den struktur de förväntar sig, antingen i realtid eller enligt ett schema.
När detta tillämpas på en butikskedja förändras innebörden av ett köp. En transaktion i kassan blir en händelse som affärssystemet, butiksfronten och lagret tar emot i sitt eget format. Det är inte längre bara en rad i en nattlig fil som huvudkontoret måste omfördela.
För att detta ska fungera krävs två saker, och hastighet är bara en av dem. Det första är timing: lagertillgängligheten måste uppdateras under öppettiderna, inte efter stängning. Det andra är identitet. Produktkoden som skannas i butiken är ofta inte densamma som affärssystemet eller butiksfronten använder, så samma artikel måste kunna identifieras i alla tre system. En nattlig fil kan lösa det första problemet, men aldrig det andra.
Alumio är en integrationsplattform byggd för just denna typ av verksamhet, där samma flöden måste fungera identiskt i varje butik. Inom Alumios integrationsplattform sker detta arbete på fyra sätt.
- Försäljning som registreras i realtid: ett händelsestyrt dataflöde inom Alumio skickar varje transaktion till affärssystemet och onlinekanalen omedelbart, så att lagertillgängligheten speglar läget i morse snarare än i natt.
- Reservationer som respekteras i kassan: en realtids-proxy kontrollerar om en vara är reserverad för en upphämtning eller onlineorder innan kassasystemet tillåter att den säljs.
- Enhetlig definition av produkt och pris: en datatransformator omformar butikens produktkoder, streckkoder och kampanjpriser till det format som affärssystemet och butiksfronten förväntar sig, så att samma artikel betyder samma sak överallt.
- Synlighet på butiksnivå: detaljerade loggar visar vilken butik som skickade vad och när, så att avvikelser kan spåras till en specifik plats och tidpunkt istället för att upptäckas först vid nästa inventering.
Att lägga till en butik eller ett varumärke innebär att man återanvänder de flöden som redan körs, vilket är avgörande när verksamheten omfattar hundratals enheter.
Vad POS-integration ger en återförsäljare
POS-integration specificeras vanligtvis som ett krav på rapportering. Det sätter ribban vid att siffrorna ska vara korrekta nästa morgon, vilket är tillräckligt för bokföring men otillräckligt för försäljning.
Tre roller upplever klyftan på olika sätt. Butikschefen hanterar onlinebeställningar utifrån en siffra som den egna personalen inte litar på. E-handelschefen ansvarar för ett löfte om upphämtning som baseras på någon annans data. Operativ chefen för detaljhandeln fastställer säkerhetsmarginalen, en direkt avvägning mellan misslyckade upphämtningar och osålda varor.
Att betrakta kassasystemet som ett lagersystem snarare än ett rapporteringssystem förändrar vad en butik kan användas till. En butik vars siffror verksamheten litar på kan ta emot beställningar för upphämtning, möta efterfrågan online i sin region och låta sitt lager räknas som säljbart istället för dolt. En integrationsplattform är det som gör siffrorna tillräckligt aktuella för att kunna förlita sig på dem, och vad man vinner är att lager som redan är betalt kan arbeta över alla kanaler.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
