E-kereskedelem és logisztika integrálása

Egy rendelés beérkezik a webshopba, majd valaki e-mailben vagy Excelben továbbítja a raktárnak. A kolléga ellenőrzi a készletet, kézzel rögzíti az adatokat a futárrendszerben, később pedig egy másik rendszerben módosítja a rendelés állapotát. Amíg napi néhány tucat csomagról van szó, ez még kezelhetőnek tűnhet. Növekedéskor azonban gyorsan kiderül, miért kulcskérdés, hogyan integráljuk az e-kereskedelem és logisztika rendszereit: nem az adatok mozgatása a valódi munka, mégis erre megy el az idő és itt keletkezik a legtöbb hiba.

Az integráció célja nem pusztán az, hogy két szoftver adatot cseréljen. A cél egy olyan működés kialakítása, amelyben mindenki ugyanabból az állapotból dolgozik, egyértelmű, ki miért felel, és a rendszer a gépies adminisztrációt elvégzi az emberek helyett. Ehhez először az üzleti folyamatot kell rendbe tenni. Egy rosszul megtervezett folyamat gyors összekötése csak gyorsabban termeli ki ugyanazokat a hibákat.

Miért szakad szét a webshop és a logisztika?

A legtöbb problémát nem egyetlen hibás rendszer okozza. A webshop, az ERP, a készletnyilvántartás, a WMS, a számlázó, a futárszolgálati felület és az ügyfélszolgálat eszközei külön-külön akár megfelelőek is lehetnek. A nehézség ott kezdődik, amikor nem világos, melyik rendszer mondja meg az igazat egy termékről, egy készletről vagy egy rendelés állapotáról.

Tipikus helyzet, hogy a webshop olyan készletet ígér eladásra, amelyet a raktár már lefoglalt egy másik csatornához. Máskor a raktár fizikailag összekészítette a csomagot, de a webshopban még mindig „feldolgozás alatt” állapot látszik. Az ügyfélszolgálat ilyenkor telefonálgat, a raktár megszakítja a munkát válaszadás miatt, a vezető pedig később több, egymásnak ellentmondó riportból próbálja megérteni, mi történt.

Ezek nem egyszerűen informatikai kellemetlenségek. Közvetlenül érintik a kiszállítási ígéretet, a készletfinanszírozást, a visszáru kezelését és a munkatársak terhelését. Ha egy tapasztalt kolléga fejében van meg, hogy melyik táblázatot kell még frissíteni, akkor a folyamat nem ellenőrzött, csak megszokott.

Hogyan integráljuk az e-kereskedelem és logisztika rendszereit?

A helyes első kérdés nem az, hogy van-e API a két rendszer között. A kérdés az, hogyan halad át egy rendelés a vállalaton a fizetéstől a kézbesítésig, és hol kell valóban döntést hoznia embernek.

Érdemes egy konkrét rendelést végigkövetni. Mikor jön létre? Mikor ellenőrződik a fizetés? Mikor foglalódik a készlet? Ki kezeli a hiányt, a részszállítást vagy a címhibát? Melyik pillanatban készül a számla? Mikor és milyen feltétellel kap az ügyfél értesítést? A folyamat feltérképezése során gyakran kiderül, hogy egy kézi lépés valójában már nem üzleti kontrollt ad, csak egy korábbi rendszerhiányt kompenzál.

Az integráció tervezésénél négy alapelv ad stabil kiindulópontot:

• minden lényeges adatnak legyen kijelölt gazdarendszere;
• az átadott adatokhoz legyen egyértelmű üzleti esemény és állapot;
• a kivételek kezelését ne rejtsük el a normál folyamatban;
• a hibáknak láthatónak, visszakereshetőnek és javíthatónak kell lenniük.

A gazdarendszer kijelölése különösen fontos. A termék kereskedelmi leírását és árát jellemzően a webshop vagy a termékinformációs rendszer kezeli. A fizikailag elérhető, foglalható készletet sok esetben a raktári rendszer vagy az ERP tartja nyilván. A szállítási cím és a vásárlói kommunikáció forrása lehet a webshop, míg a fuvarcímke és a kézbesítési esemény a fuvarozói kapcsolatból érkezik. Nem minden esetben ugyanaz a jó felosztás, de ugyanarra az adatra nem lehet tartósan több, egymástól független „végleges” forrás.

Ne adatmezőket, üzleti eseményeket kapcsoljunk össze

Gyenge megoldás, amikor egy időzített folyamat félóránként átmásolja a rendelési adatokat egyik adatbázisból a másikba. Bizonyos környezetben ez elfogadható kompromisszum lehet, például régi rendszer vagy alacsony rendelésvolumen mellett. De a késleltetés, az ismételt küldések és a félbeszakadt feldolgozás kezelését ilyenkor is meg kell tervezni.

Jobb kiindulópont az üzleti események meghatározása. Például: rendelés jóváhagyva, készlet lefoglalva, komissiózásra kiadva, csomag feladva, kézbesítés sikertelen, visszáru beérkezett. Minden eseményhez tartozik egy felelős rendszer, egy értelmezhető állapot és szükség esetén egy emberi teendő.

Ez azért lényeges, mert a rendelés nem egyetlen rekord, hanem állapotok sorozata. Ha a futár címkét generált, de a raktárban a csomag még nem került a raklapra, nem szabad automatikusan úgy kommunikálni az ügyfélnek, mintha a küldemény már úton lenne. Az ilyen apró különbségek döntik el, hogy a riportok és az ügyféltájékoztatás hitelesek maradnak-e.

A kivételek döntik el, használható-e a megoldás

A normál rendelési útvonal általában gyorsan automatizálható. A nehezebb kérdések a kivételeknél jelennek meg: nincs elegendő készlet, a vásárló módosítaná a rendelést, több raktárból kell teljesíteni, a cím érvénytelen, sérült áru érkezik vissza, vagy a fuvarozó sikertelen kézbesítést jelez.

Ezekre nem mindig érdemes teljesen automatikus választ adni. Egy értékhatár feletti rendelés, egy egyedi B2B szállítás vagy egy visszatérő címprobléma esetén az emberi ellenőrzés üzletileg indokolt lehet. A rendszer feladata ilyenkor az, hogy a megfelelő kollégának mutassa meg a problémát, minden szükséges háttéradattal együtt. Nem az, hogy e-mailes köröket és külön listákat hozzon létre.

A kivételkezeléshez felelősségi határok is kellenek. A raktár dönt-e helyettesítő termékről? Az ügyfélszolgálat módosíthat-e címet a komissiózás után? Ki oldja fel a fizetési vagy készletfoglalási anomáliát? Ha ezek a döntések csak szóban léteznek, az integráció nem fogja megszüntetni a bizonytalanságot.

Technikai kialakítás: egyszerű, de ellenőrizhető

Nem minden vállalatnak van szüksége külön integrációs platformra vagy nagy átalakításra. Előfordulhat, hogy egy szabványos webshop-ERP kapcsolat megfelelő, ha az adatmodell, a készletlogika és a kivételkezelés is illeszkedik a működéshez. Más környezetben egy köztes integrációs réteg indokolt, különösen akkor, ha több értékesítési csatorna, több raktár, saját fejlesztésű rendszer vagy eltérő adatstruktúrák kapcsolódnak össze.

A technikai megoldástól függetlenül szükség van azonosítókra, naplózásra és újrafeldolgozási lehetőségre. Egy rendelésnek, küldeménynek és terméknek következetesen azonosíthatónak kell lennie minden érintett rendszerben. Ha egy kapcsolat átmenetileg nem elérhető, a rendszernek nem szabad csendben elveszítenie az eseményt. Legyen látható, mely átadások várakoznak, melyek hibásak, és ki tudja azokat üzleti döntés nélkül vagy üzleti jóváhagyással újraindítani.

A jogosultságok és az adatvédelem is része a tervezésnek. Nem minden rendszernek és nem minden felhasználónak kell teljes ügyfél- vagy rendelési adatkörhöz hozzáférnie. Az integrációban csak az a személyes és üzleti adat mozogjon, amely a feladat elvégzéséhez szükséges. Ez egyszerre csökkenti a kockázatot és teszi átláthatóbbá a működést.

Bevezetéskor ne a teljes működést cseréljük le egyszerre

A nagy, egyszeri átállás első látásra hatékonynak tűnhet, de a rendelésfeldolgozás nem olyan terület, ahol könnyű hosszabb hibázási időszakot vállalni. Célszerűbb olyan szakaszt kiválasztani, ahol egyértelmű a fájdalom és mérhető a változás. Ilyen lehet a rendelésátadás automatizálása, a készletszinkronizáció rendbetétele vagy a fuvarcímke-generálás kiváltása.

Mielőtt élesedik az új kapcsolat, valós esetekkel kell tesztelni. Nem csak egy szabályos, előre kifizetett rendelést, hanem törlést, részszállítást, készlethiányt, visszárut, címjavítást és ismételt eseményküldést is. Az elfogadási feltételeknek üzleti nyelven kell megfogalmazódniuk: mit lát a raktár, mit lát az ügyfélszolgálat, milyen státuszt kap a vásárló, és mi jelenik meg a vezetői riportban.

A bevezetés után is figyelni kell a folyamatot. Nem elegendő azt ellenőrizni, hogy fut-e az interfész. Azt kell látni, hány rendelés várakozik indokolatlanul, hány eset igényel kézi beavatkozást, hol tér el a rendszerkészlet a fizikai készlettől, és mennyi idő telik el az egyes állapotok között. Ezek az adatok nemcsak az IT működését, hanem a teljesítési folyamat minőségét is megmutatják.

A CGAT szemléletében az integráció ezért nem önálló fejlesztési feladatként indul, hanem a rendelési és raktári működés közös vizsgálatával. A jó eredmény gyakran nem attól születik, hogy több technológiát vezetnek be, hanem attól, hogy néhány bizonytalan átadás, párhuzamos adatforrás vagy felesleges jóváhagyás megszűnik.

A következő vezetői megbeszélésen érdemes nem azt kérdezni, melyik rendszert kellene még összekötni. Inkább válasszanak ki egy tegnapi, problémás rendelést, és kövessék végig rendszerből rendszerbe. Ahol az információ megáll, megismétlődik vagy csak egy ember fejében folytatódik, ott kezdődik az a munka, amely valóban javíthatja az e-kereskedelem és a logisztika együttműködését.