Raktári hibacsökkentés valós példája egy cégnél

Reggel nyolckor a raktár már dolgozik, de az első reklamáció is megérkezik: a vevő két darabot rendelt, csak egyet kapott. Közben az értékesítés azt látja, hogy a rendszer szerint van készlet, a raktár szerint viszont az adott termék már elfogyott. A nap végén valaki újra átnézi a kiszedési listákat, javítja a számlát, és próbálja kideríteni, hol csúszott el a folyamat. A raktári hibacsökkentés valós példája nem feltétlenül egy új rendszer bevezetésével kezdődik. Gyakran azzal, hogy végre pontosan megnézik, mi történik egy rendelés útján.

Egy növekvő kereskedelmi vállalkozásnál ez a helyzet már nem egyszeri kellemetlenség volt. A webshopos, B2B és telefonon felvett rendelések ugyanabba a raktárba érkeztek, de nem azonos módon. A komissiózók nyomtatott listából dolgoztak, a készletmozgásokat részben egy vállalatirányítási rendszerben, részben táblázatban vezették, a sürgős rendeléseket pedig üzenetben jelezték egymásnak.

A hibák aránya még nem tűnt katasztrofálisnak. Havonta azonban több tucat helyesbítő szállítás, jóváírás és vevői egyeztetés gyűlt össze. Ennél nagyobb gond volt, hogy senki sem tudta biztosan megmondani: a hibák melyik ponton keletkeznek, és melyik változtatás hozna tényleges eredményt.

Mit jelentett valójában a raktári hiba?

A „raktári hiba” túl tág kifejezés. Ha minden eltérést egyetlen kategóriába tesznek, a javítás is találgatássá válik. Ebben az esetben a vezetés kezdetben főként rossz termékkiküldésre gyanakodott. A részletes vizsgálat viszont több, egymástól eltérő problémát mutatott ki.

Előfordult, hogy a komissiózó rossz polcról vett le terméket. Máskor a helyes termék került a dobozba, csak hibás darabszámban. Volt olyan eset is, amikor a rendszerkészlet már a kiszedés előtt pontatlan volt, ezért a rendelés csak helyettesítéssel vagy késéssel volt teljesíthető. A reklamáció szempontjából ezek mind hibák, de az okuk és a kezelésük nem ugyanaz.

A vállalat ezért négy héten át minden eltérést azonos szempontok szerint rögzített: rendeléstípus, termékcsoport, raktári zóna, műszak, hiba típusa, felfedezés helye és szükséges utómunka. Ez nem azért kellett, hogy az egyes munkatársakat minősítsék. A cél az volt, hogy a folyamat láthatóvá váljon.

Már az első hét után feltűnt egy fontos minta. A hibák jelentős része nem a kiszedésnél indult, hanem korábban: akkor, amikor a rendelési információ több csatornából, eltérő formában került a raktári listára.

Raktári hibacsökkentés valós példája: a folyamat feltárása

Az elemzés során nem azt kérdezték, ki hibázott, hanem azt, hogy egy rendelésnél hányszor kell ugyanazt az információt átadni, értelmezni vagy újra rögzíteni. Ez a különbség döntő.

A webshopos rendelések automatikusan bekerültek az adminisztrációs rendszerbe, de a raktár számára készült kiszedési lista csak egy reggeli exportból állt elő. A délelőtt beérkező rendelésekhez ezért külön lista készült. A kiemelten sürgős rendeléseket gyakran chatüzenetben jelezték, majd valaki kézzel írta hozzá a nyomtatott dokumentumhoz.

A B2B rendelések egy részét az értékesítők vitték fel manuálisan. Ha a vevő saját cikkszámot használt, a termékazonosítást sokszor tapasztalat alapján végezték. Egy hasonló elnevezésű, közeli tárolóhelyen lévő termék esetén már egy apró félreértés is elegendő volt a hibás kiszedéshez.

A készletpontatlanságok mögött szintén nem egyetlen ok állt. Bizonyos termékekből bontott csomagokat kezeltek, de az egységváltás nem minden rendszerben történt meg ugyanúgy. Egy karton például a beszerzésben kartonként, a webshopban darabként, a raktári nyilvántartásban pedig időnként mindkét egységben megjelent. Az eltérés nem a leltár napján keletkezett, hanem folyamatosan épült fel.

Ekkor vált világossá, hogy a gyorsabb munkára ösztönzés nem fogja megoldani a problémát. A kollégák már így is sok kivételt kezeltek fejben. A folyamat tette őket az információk közötti kapcsolattá, miközben nekik a fizikai áru pontos mozgatására kellett volna figyelniük.

Nem minden javítás technológiai projekt

A feltárt problémákból több változtatás következett, de ezek nem egyszerre és nem kizárólag rendszerfejlesztésként valósultak meg. Először egységesítették, hogy mi számít sürgős rendelésnek, ki jogosult ezt kérni, és hogyan kerül a kérés a raktárhoz. A chatüzenet megszűnt hivatalos rendelési csatorna lenni.

Ezután rendbe tették a terméktörzs azon adatait, amelyek a raktári munkához szükségesek voltak: egyértelmű megnevezések, vonalkódok, tárolóhelyek, kiszerelési egységek és helyettesítési szabályok. Ez kevésbé látványos feladat, mint egy új alkalmazás bevezetése, de közvetlenül csökkenti azt a helyzetet, amikor egy dolgozónak találgatnia kell.

A tárolási logikát is felülvizsgálták. A gyakran együtt rendelt, hasonló csomagolású termékek túl közel voltak egymáshoz. Néhány polchely átrendezése, jól olvasható helyazonosítók és elkülönített visszáru-zóna már önmagában csökkentette az összecserélés esélyét.

Csak ezután került napirendre a rendszerkapcsolat javítása. A cél nem egy „automatizált raktár” volt, hanem az, hogy a rendelés státusza, a készletmozgás és a komissiózási feladat ugyanarra az aktuális információra épüljön. A raktárnak ne kelljen reggeli exportokból és napközben kézzel toldott listákból dolgoznia.

A kontrollpontoknak ott kell lenniük, ahol még olcsó a hiba

A vállalat bevezetett egy egyszerű, de következetes ellenőrzési elvet. A rendszer a kiszedéskor termékazonosítást kért, a csomagolás előtt pedig a magasabb értékű vagy gyakran tévesztett termékcsoportoknál második ellenőrzési pontot alkalmaztak.

Nem volt célszerű minden rendelést kétszer teljes körűen átvizsgálni. Az jelentős kapacitást kötött volna le, és a nagyobb forgalom mellett új szűk keresztmetszetet hoz létre. Ehelyett az ellenőrzést a kockázat alapján alakították ki: az értékesebb termékek, a több hasonló változatban létező cikkek, valamint az új vagy ideiglenes tárolóhelyről kiszedett rendelések nagyobb figyelmet kaptak.

Ez a megközelítés fontos vezetői tanulságot is ad. A hibacsökkentés nem azt jelenti, hogy minden folyamatot maximális kontroll alá kell helyezni. A cél az, hogy a megfelelő kontroll a megfelelő ponton működjön, és ne lassítsa szükségtelenül az egész működést.

Mit változtattak a számok?

A kiinduló állapotban a vállalat a kiküldött rendelések körülbelül 3,6 százalékánál rögzített valamilyen eltérést. Ebbe a hibás termék, hibás mennyiség, készlethiány miatti utólagos módosítás és dokumentációs hiba is beletartozott. Három hónappal a folyamatváltoztatások után ez az arány 1,4 százalékra csökkent.

A szám önmagában kedvező, de nem ez volt az egyetlen eredmény. Jelentősen rövidült a reklamációk kivizsgálására fordított idő, mert a rendelés, a kiszedés és a csomagolás állapota visszakövethetőbbé vált. Kevesebb volt a napi megszakítás is: a raktári vezetőnek ritkábban kellett azonnal megoldania egy hiányzó vagy félreérthető információból eredő helyzetet.

A legnagyobb változást a munkatársak érezték. Nem a teljesítménykényszer nőtt, hanem csökkent azoknak a döntéseknek a száma, amelyeket hiányos adatokból, rutinból vagy egyéni emlékezetből kellett meghozniuk. Ez a kiszámíthatóság a betanításnál is értékes: egy új kolléga nem kizárólag attól válik hatékonnyá, hogy megtanulja, kit kell megkérdezni.

Mire figyeljen, mielőtt megoldást választ?

Ha egy raktárban rendszeresen előfordulnak eltérések, érdemes először a hibák költségét és útját megérteni. Nemcsak a visszaküldés vagy a jóváírás számít, hanem az ügyfélszolgálati idő, az újraszállítás, a készlettervezési torzulás, a vezetői megszakítás és a vevői bizalom is.

Érdemes azt is megvizsgálni, hogy a raktár mennyi információt kap más rendszerekből, és abból mennyit kell kézzel átírni vagy értelmezni. Ahol ugyanaz a cikkszám, mennyiség vagy státusz több helyen jelenik meg, ott előbb-utóbb eltérés keletkezik. Nem biztos, hogy azonnal új rendszerre van szükség. Lehet, hogy egy adatgazda kijelölése, egyértelműbb rendelési szabály vagy egy jól meghatározott rendszerkapcsolat oldja meg a problémát.

A tartós javulás akkor kezdődik, amikor a raktári hiba nem emberi figyelmetlenségként, hanem üzemi folyamatjelzésként jelenik meg. Minden ismétlődő eltérés megmutat valamit arról, hogyan áramlik az információ és hol kér túl sokat a rendszer az emberektől. Ezt érdemes előbb megérteni, mint gyorsan új technológiát választani.