omnichannel-eisberg

De omnichannel-ijsberg: enorme backend-processen zijn verborgen

Omnichannel-handel is eenvoudig - alleen niet voor de retailer

E-commerce is eenvoudig. In ieder geval voor de eindklant: hij bestelt, betaalt en laat de goederen, liefst nog dezelfde dag, bij hem thuis bezorgen. En als er iets niet past, stuurt hij het product terug, ofwel naar het dichtstbijzijnde filiaal of hij stuurt het terug als pakket. De vangst aan de kant van de retailer: om deze zogenaamd eenvoudige processen echt soepel te laten verlopen, moeten organisaties enorme uitdagingen aangaan. Hieronder laat ik u zien welke dit zijn en welke oplossingen er zijn.

De waargenomen 1:1 relatie van de eindklant is een complexe multi-to-multi relatie

Als je een moderne klantreis onder de loep neemt, zie je al snel dat de functies gericht op de klant enerzijds en de backend-processen anderzijds een complexe, multidimensionale relatie vormen. Dit betekent dat er achter de hierboven beschreven winkelervaring een verscheidenheid aan omnichannel-processen schuilgaat die flexibel moeten worden ingezet, omdat de klant bepaalt hoe hij koopt en altijd een hoge kwaliteit van dienstverlening verwacht. Dus uiteindelijk hoeft het niet uit te maken:
• Hoe en waar de eindklant bestelt (eShops, marktplaatsen, filialen, app, voice, social ...),
• Hoe en waar de eindklant betaalt (contant, creditcard, huurkoop, voucher, gesplitste betaling),
• Hoe en waar vandaan het pakket de eindklant bereikt (eigen magazijn, FBA, externe logistiek medewerker, externe leverancier, vestigingen, fabrikant of verzending via meerdere magazijnen),
• Hoe en waar de klant indien nodig terugkeert (in het filiaal, pakketbezorging),
• Op welk toestel de klant inlogt: hij wil graag zijn volledige bestelgeschiedenis zien en alle serviceopties gebruiken (bv. in de backend van de eShop, in de in-store app, in een mobiele app...).
Ook tijdens de customer journey is het belangrijk dat het bedrijf altijd uniform overkomt en de merkbeleving consistent is. Kortom: wat het bestelproces ook is, de klant eist altijd dat hij zijn pakket zo snel en soepel mogelijk ontvangt, dat hij het net zo gemakkelijk kan retourneren en dat hij te allen tijde optimaal geïnformeerd is. Storingen, bijvoorbeeld het annuleren van een artikel vanwege een gebrek aan voorraad, zijn tegenwoordig een grote ergernis voor klanten en leiden vaak tot slechte beoordelingen die zowel online als offline gevolgen hebben voor de retailer. En: de wegen naar Amazon of andere marktplaatsen, die klanten aantrekken met een hoge kwaliteit van dienstverlening en een bijna eindeloos aanbod van producten, zijn kort.

Omnichannel-backend: welkom onder het wateroppervlak

Het grootste deel van een ijsberg bevindt zich onder het wateroppervlak. Het is vergelijkbaar in omnichannel-commerce: er is het zichtbare oppervlak, d.w.z. de contactpunten waarmee de eindklant met het bedrijf communiceert, en er zijn de back-endprocessen die voor de klant verborgen blijven.
Dit omvat bijvoorbeeld de volgende taken:
• Verbind snel verschillende touchpoints,
• Artikelstamgegevens specifiek voor elk contactpunt voorbereiden,
• Houd de voorraden van meerdere magazijnen up-to-date op verschillende contactpunten om oververkoop te voorkomen,
• Ontvang en verwerk bestellingen in een breed scala aan formaten en alle relevante formulieren zoals: B. Aanmaken leveringsbon, factuur en creditnota,
• Routeer bestellingen naar het magazijn dat het meest geschikt is voor verzending (bijv. hoofdmagazijn, filiaal, externe leverancier, externe logistiek medewerker of fabrikant),
• Verdeel de bestelling eventueel over meerdere magazijnen die verschillend van aard zijn,
• Zorg voor een optimale en uniforme klantcommunicatie voor elk triggerpoint (bijvoorbeeld bij het verzenden van de goederen, het ontvangen van de retour, het uitbetalen van een tegoed, het annuleren, enz.),
• Optimale integratie in de bestaande IT-infrastructuur om geen e-commerce silo op te bouwen.

Er ontstaan problemen met schalen

In de regel zal een 1:1 relatie (een eShop en een verzendmagazijn) in de loop van de tijd veranderen in een complexere multi-to-multi relatie. Dat betekent dat het aantal contactpunten en verzendmagazijnopties groeit. Om aanpassingsprogrammering in de eShop en/of in het ERP-systeem te voorkomen, hebben organisaties een sterke oplossing nodig die de backend-processen in kaart brengt en die speciaal is ontworpen voor dergelijke schaalscenario's.

Gegevens en bedrijfslogica op meerdere plaatsen

Als een IT-infrastructuur groeit, worden vaak meerdere systemen gebruikt: een eShop, het ERP-systeem, een systeem van het externe logistieke bedrijf, een systeem voor aansluiting op marktplaatsen en een kassasysteem. Elk systeem bevat klant- en transactiegegevens - en zijn eigen bedrijfslogica. Dat maakt het niet alleen operationeel lastig. Laten we bijvoorbeeld eens kijken naar ondersteuning: ze moeten vaak inloggen op meerdere systemen en met elk ervan vertrouwd zijn. Het combineren van de data uit deze verschillende potten om een uniform klantenbestand inclusief historie te genereren is bijna onmogelijk. Het resultaat: personalisatie, uitgebreide rapportage, goede service en omnichannel zijn nog ver weg.

Aanpassingsprogrammering verhindert updatemogelijkheid

Sommige retailers zonder backend-oplossing proberen aan de schaalvereisten te voldoen met dure en langdurige aanpassingsprogramma's voor eShop- en ERP-systemen. Daarnaast worden er extra interfaces gecreëerd, waardoor het systeemlandschap nog wankeler wordt. Dergelijke aanpassingen zijn z. Een releasewijziging naar een nieuwe versie van het eShop-systeem of de toevoeging van nieuwe touchpoints of verzendmagazijnen worden bijvoorbeeld steeds complexer en duurder. Na verloop van tijd blijft de ijsberg onder het wateroppervlak groeien en oncontroleerbare vormen aannemen. De integratie van een nieuwe backend-oplossing in de bestaande IT-infrastructuur en in de operationele processen is noodzakelijk om deze groei te voorkomen, namelijk het creëren van een extra e-commerce silo. Een dergelijke oplossing synchroniseert alle klantgegevens inclusief alle relevante transactiegegevens en verbindt ERP-, CRM-, logistieke of financiële boekhoudsystemen. Ook speciale systemen van derden, bijvoorbeeld voor personalisatie, automatische tekstgeneratie, PIM of logistieke systemen, kunnen eenvoudig worden geïntegreerd. Dit is een uitstekende manier om de best-of-breed benadering na te streven.

De oplossing: een headless systeem

Als je het bestaande systeemlandschap, oftewel de onderkant van de ijsberg, analyseert, wordt al snel duidelijk dat veel systemen op allerlei manieren met elkaar verbonden zijn. Dit zijn meestal systemen die niet zijn ontworpen voor e-commercetransacties en hun sterk geautomatiseerde processen. Als je nog meer e-commercesystemen aan dit systeemlandschap zou toevoegen, zou het al snel eindigen in een chaos van interfaces die vroeg of laat niet meer verhandelbaar zouden zijn. Hierdoor gaat de nodige snelheid in e-commerce verloren; in het ergste geval dreigt een 'dead lock-scenario'. Want: De systemen kunnen door te veel aanpassingen niet meer geüpdatet worden en verdere aanpassingen zijn door bijwerkingen niet meer mogelijk. Dit kan worden verholpen door een headless systeem dat ook een geavanceerde e-commerce bedrijfslogica bevat. Hierdoor worden gegevens uit omliggende systemen geïmporteerd en na verwerking doorgegeven aan andere systemen. Op deze manier worden bestaande systemen "losgekoppeld" van de online wereld. Men spreekt van het principe van "IT op twee snelheden". Op deze manier wordt de complexiteit in e-commerce drastisch verminderd: de bestaande systemen vertragen de e-commerce business niet, de business wordt schaalbaar en dezelfde opties zijn open als een online pure player.

Open voor alle toekomstige touchpoints

Een backend-systeem dat "headless" werkt, kan een breed scala aan formaten van verschillende touchpoints verwerken en order- en klantgegevens harmoniseren. Ook het koppelen van nieuwe touchpoints gaat snel en eenvoudig. Misschien wel het grootste pluspunt is dat de complete bedrijfslogica centraal in zo'n systeem in kaart kan worden gebracht.

API: data en functies centraal beschikbaar stellen

Voorwaarde voor een uniforme klantbeleving is dat er een centrale dataweergave is en dat functies centraal via een API voor alle devices kunnen worden aangeboden. Dit maakt het bijvoorbeeld mogelijk om via alle kanalen dezelfde functie te bieden voor een retour, of het nu gaat om online shop, app, PWA (Progressive Web App), de kassa of mobiele verkoopondersteuning. Dit heeft als voordeel dat functies niet voor elk apparaat opnieuw hoeven te worden ontwikkeld of aangepast. En dat leidt weer tot een snellere time-to-market. Daarnaast heeft elk touchpoint centraal toegang tot klantgegevens en transactiegegevens zoals aankoophistorie en retourgedrag.
Een sterke partner voor logistiek Logistiek staat centraal bij e-commerce. Hoewel klassieke logistieke systemen niet zijn ontworpen voor omnichannel-logistiek, biedt een speciale backend-oplossing een enorm potentieel op dit gebied. Een bestelalgoritme kan worden gebruikt om voor elke afzonderlijke zending het "juiste" magazijn te vinden, bijvoorbeeld op voorraad, nabijheid van de eindklant (geo-routing) of de goedkoopste verzendoptie. Een verzendorder kan ook worden opgesplitst in verschillende orders, waarvoor meerdere magazijnen kunnen worden gebruikt. Omdat het bestelalgoritme direct in de backend plaatsvindt en centraal draait, betekent dit een aanzienlijk snelheidsvoordeel, waardoor de oververkoop enorm kan worden verminderd.

onderneem zorgeloos met retailtrust shop-it

Dat is slim ondernemen.

Onze website maakt gebruik van cookies. Cookies zijn kleine stukjes informatie die je internetbrowser opslaat op jouw computer. Wij gebruiken cookies enkel om onze service te verbeteren en om statistieken bij te houden.