Vannak olyan blogbejegyzéseim illetve témáim amelyeknél azt érzem, hogy a Reflexió nevű blogomon is elférne, ez is ilyen lesz. Kezdjük a problémával amire a címbéli eszköz lesz a részmegoldás. Ha ez a része a témának nem érdekel (~ Business Analysis), akkor ugorj egy nagyot és kezd az eszközzel.
A komissió az a tevékenység amikor raktári dolgozók összekészítenek egy rendelést. Ahhoz, hogy ez a lehető legkevesebb hibával történjen bemutatom, hogyan alakítottam ki a rendszerünket.
Alapfogalmakkal kell kezdenem, mert feltételezem a kedves olvasó nem logisztikus, ha pedig netán igen, akkor neki elnézését kérem.
Egy raklapállvány az a méret amelyen 3 raklap szélességben közel tetszőleges magasságban vannak a raklapok. Egy ilyenre a mi cégkultúránkban gondolaként hivatkozunk. Ezekből az egységekből képzünk sorokat, amelyet mi utcáknak hívunk. Amikor rendszert tervezünk, akkor mindig építünk a felhasználók meglévő tudásra, most is így tettünk. Egy-egy ilyen utcát az ABC betűivel inkrementális módszerrel nevezünk el. A gondolák pedig olyanok, mint a házak az utcában, vagyis van páros és páratlan oldal. Egy gondolán belül pedig vannak szintek 0..n és raklaphelyek 1..3. Az első utca, első gondola, földszinten lévő raklap első helyének kódja így alakul: A0101 rendre: A:utca 01:gondola 0:földszint 1:első raklap balról.
Mi ebben a nagyszerű?
Először is könnyen sorba rendezhető, így akár raktárbejárási útvonal is tervezhető, hogy az adott munkatárs a feladatot a legrövidebb útvonalon végezhesse el. Az a rendszer önmagában még nem egy nagy varázslat, kell hozzá a termékek elhelyezése is. Ennél nálunk két szabály van, hogy összegyűjtésnél a lehető legkevesebb hiba, kognitív valamint fizikai terhelés legyen. Ehhez az kell, hogy lehetőleg hasonló, könnyen összetéveszthető termékek egymás közelében ne legyenek, valamint a nagyobb forgási sebességű termékek elérhetőbb helyen legyenek. Ez a két feltétel sajnos nem minden iparágban megvalósítható, így a hibák számát ezen helyeken a vonalkódolvasó használatával lehet csökkenteni. Mi szerencsések vagyunk, de még így is kb van 0,4% hiba az összeszedésben. Ez sokaknak elenyésző lehet, de nem nekem. Abból indulok ki, hogy az az ügyfél, akinél mondjuk két tranzakcióra jutott 1 hiba az mit gondolhat rólunk? Neki sovány vigasz, hogy mi 0,4%-os hibával dolgozunk, amikor ez nála két nagyságrenddel nagyobb. Mivel a partnereink kereskedők, így az ő életüket minden ilyen hiba nagymértékben érint. Mi kockáztatjuk az ő reputációjukat, ami idővel visszahat ránk. Azt gondolom ami ügyfél részéről a normális elvárás, az a háttérben a hibátlan kiválóság lenne. Ennek elérése közel lehetetlen, de törekedni mindig érdemes rá.
Eddig is használtunk egy általam készített komissiózó szoftvert, ami a tételek összeszedésben és útvonal készítésben segített, de a felhasználó ennél rafináltabb. Megfigyeltem, hogy időnként az áru össze volt szedve, de a komissiózó alkalmazásban meg sem volt nyitva az adott logisztikai tétel. Az történt, hogy a kolléga ránézett a nyomtatványra, majd fejből összerakta a rendelést. Miután végzett kiütött mindent, mintha az alkalmazással szedte volna össze. Na ilyenkor van az, hogy minden szoftverfejlesztő, cégvezető tépi a haját. A tapasztalatomnál fogva ma már tudom: nincs rossz ember, csak rossz rendszer. Ha pedig valami oknál fogva ragaszkodunk ahhoz, márpedig ez az ember rossz, akkor vigasztaljuk magunkat azzal, hogy rosszat mindig találunk, legyen a rendszer jó, hogy a rossz ember is jó munkát végezhessen.
Mit kellene tennem, hogy ezt megelőzzem az ilyen felhasználói hacket?
Az első amit be kell vezetni, hogy olvassa le a termék vonalkódját a komissiózó személy. Ehhez neki a termék mellett kell lennie. Oké, de ez sem oldja meg azt, hogy összepakolás után csinálja meg és nem pedig szedés közben. Erre a jelenlegi legjobb ötletem a késleltetés. Mit értek ezt alatt? Egymás után két termék kiütéséhez legyen n másodperc a szükséges minimális idő. Még nem mértem ki mennyi lenne az ideális, de annyinak mindenképpen kell lennie, ha utólag üti ki az agyára menjen, és kifejezetten kényelmetlenné váljon a feladat.
Itt jön képbe a Zebra!
Amikor az eszközt kiválasztottam két utat jártam be. Az egyik ez a megvásárolt adatgyűjtő, a másik pedig venni egy tabletet és egy nagyon jó minőségű vonalkódolvasót mellé. A vicc az, hogy a Zebranak ez a modellje (T22B6CBC2-A6) olyan lézerrel rendelkezik, mint az árban hasonló illetve drágább olvasók. Innentől kezdve nem volt kérdés, hogy ezt veszem, mert egyben azért csak jobb ez az egész.
Zebra TC22 eszközről
Állítva az eszköz felső részen a scanner mellett van a felélesztő és power gomb egyben. Más gombbal nem lehet aktiválni az eszközt és ez nagyon jól van így, mert nem fog lemerülni a felhasználó zsebében. Miért ezt választottam a megannyi adatgyűjtő közül? A brand már megdolgozott a reputációjáért, a lézer nagy hatótávú, az ár a többihez képest kedvező és a 6″, amit amúgy én speciel keveslek (ez max a termékkategóriában). Egyre több a 40+-os munkavállaló nem sasszemmel, szóval kedves gyártok tessék növelni a képernyő méretét.
A készülék kedvez a jobb és balkezeseknek, mert a scanner olvasó gombja egy vonalban, mindkét oldalon elérhető. Ezenkívül rendelkezik programozható gombokkal. A nálam lévő készüléken a lézert vezérlő olvasó gomb sárga színű, de a tokon sajnos nincs beszínezve ugyanez.
Az akkumulátora kivehető, ehhez lehet kapni dokkolót amiben tölthető, ha te egy nagyobb szervezethez akarnád bevezetni. Szerencsére a TC22 és az újabb TC27 tokja, akkuja, kijelzője és annak fóliája megegyezik (cikkszámban is). Bevallom oda nem merném adni tok nélkül senkinek, hiszen felszerelve (tok, fólia) közel 400.000 ft bruttó egy ilyen készülék. Az eszközhöz lehet vásárolni pisztolyt (grip gun):
Ha a képeket jól értelmezem, akkor ennek illesztéséhez is kell a telefontok. Ha valaki igazi harcosokat akar csinálni a munkavállalóiból, akkor ehhez vehet még pisztolytáskát is:
Én nem vettem. Szerintem kényelmesebb a kertésznadrág felső zsebében tárolni a készüléket.
Érdemes tudni, hogy a Zebra úgy teszteli a készülékeit, hogy 1 méterről leejti, sokszor. Ha a dolgozó ennek ellenére összetöri, akkor talán nem alaptalanul élhetünk a gyanúval, hogy ez szándékos volt a részéről. Ha már itt járunk megjegyzem IP68 minősítésű a készülék, ami teljes por (6) és tartós vízállóságot (8) jelent, ez 1.5 méter mély vízben 30 perc.
Minek vonalkód olvasáshoz egy ilyen? Miért nem jó egy profi telefon?
Ez a kérdés sokakban felmerül, ahogyan bennem is felmerült. Sajnos a legjobb telefonok kamerája (pl.: S25 Ultra), jó fényviszonyok mellett kb 10 cm-ről sem képes arra, mint a legolcsóbb lézeres szkenner 50 cm-ről. Próbáltam, fejlesztettem, játszottam vele, de esélytelen vállalati környezetben, mert megbízhatatlan és időrabló megoldás lenne és emellett egyáltalán nem olcsóbb.
Jöhet a szoftveres rész!
Az alkalmazásom böngészőben fut. Amikor megvettem a készüléket arra gondoltam, hogy vagy az alkalmazásból fogom vezérelni a lézert, vagy a lézer elsütőjét elkapom és fogja vezérelni az appot. Na ezekről le kell mondanom. A használat az lesz, hogy a felhasználó kiválasztja, hogy melyik terméket szedi és majd elsüti a lézert. Igazából ezt akartam valamilyen logika szerint egyszerűsíteni. pl elsütőbillentyűzetet elkapva a következő soros terméket olvasná le. Miért nem tudom ezt megtenni? Amikor elsütőm a lézer gombot, akkor fókuszt veszít a böngésző és nem kapja meg a keycode-ot. Oké, gondoltam akkor csináljuk fordítva, vagyis süssük el mi a billentyűzetet ezzel aktiválva a lézert. Na ezt nem lehet a mai böngészőkben, mert nem nyúlhat ki a böngészőből a HW felé az app. Ezt a Zebra viszont megkerülte, készített egy hekkelt böngészőt, ami semmibe veszi ezt a biztonsági intézkedést és ezt a megoldását tdadam-kapaszkodás Enterprise Browser-nak hívja. 🙂 Tudom csalódás ez minden szoftvermérnöknek, és amikor ilyen történik mindig meghal egy etikus hackernek készülő kiscica a világban. Talán az Enterprise jelző már csak azért is szükséges egy böngészőnek, mert nem ingyenes ez a termék. Amiket találtam publikus árakat $30-$90 között volt, nekem is valami huszonezer forint rémlik onnan, amikor erről beszéltem az ügyfélszolgálattal.
Saját megoldásom
GDPR és biztonsági okból nem tudok videót megosztani, pedig azzal lehetne jól bemutatni az alkalmazást. Megpróbálom leírni. A termékek egymás alatt vannak minden termékhez van egy beviteli mező, aminek a placeholder-jében van amit be kellene olvasnia, és mellette egy button ami a beolvasás kiválasztásáért felel, lényegében átadja az inputnak a fókuszt és ott tartja addig, amíg vagy meg nem találja a helyes kódot (terméket) a felhasználó, vagy hibás termék esetén ez a button átvált feloldó gombra és azzal tovább tud lépni, ha valami oknál fogva nem találja a terméket. Ha a fellelt termék helyes, akkor egy mély férfi hang ebben megerősíti, míg ha helytelen egy magas női hang figyelmezteti a felhasználót. Ebből kérem ne csináljunk gender kérdést, pénzfeldobással választottam. A lényeg az volt UX szempontból, hogy ne csak az számítson mit mondott, hanem hogy ki mondta. Emellett arra is figyeltem, hogy az elhangzó kifejezések ne hasonlítsanak, magyarul ne ugyanaz a mondat/kifejezés legyen tagadva. Így az alábbiak hangoznak el: „Ez nem az a termék!” (női hang) és „Jó választás!” (férfi hang) mint látható még részleteimben sem hasonlít a két kifejezés egymásra. A hangokat a Speech Note-tal generáltam. Magáról pedig a hanglejátszásról annyit kell tudni, hogy böngészőben kizárólag felhasználói interakcióra történhet ilyen cselekmény, vagyis valamilyen felhasználói eseményre. Ez lehet akár egy scrool is. Nem próbáltam, de úgy értelmeztem egy leírást, hogy ez alól talán a ServiceWorker kivétel (fixme). Vannak akik ezt a korlátozást azzal kerülik meg, hogy videóba ágyazzák a hangot és alapból megy a lejátszás végtelenítve mute, majd a scriptjük csak a mute-ot kapcsolja ki. Szerintem felhasználói interakció nélkül váratlanul megszólaltatni egy hangot a felhasználó eszközén modortalanságra vall és ellenszenvet vált ki. Magát a technológiát, hogy a szoftverek hangos utasítással kommunikálnak a felhasználóval én speciel imádom. Lásd, automata kasszák és benzinkutak.
Tökéletes lesz így a komissiózás?
Nem. Jóból is lehet még rossz mennyiséget adni, továbbá különböző raktározási módszerek betartását ez nem védi ki, mint FIFO, LIFO. A menyiségre megoldás lehet a súlyalapú ellenőrzés, az össz darabszám ellenőrzése. A súly alapú ellenőrzés első lépcsője az lenne, hogy az üres raklapot megméri és rögzíti a felhasználó. Ha szükséges, akkor nagy valószínűséggel ez lesz a következő lépés amit bevezetek a jövőben.
Összefoglalás
Na ilyen most nem lesz. Ugyanis a mai napon osztom ki az eszközöket, majd rövid tapasztalat után, ha szükséges módosítom az alkalmazásomat. Ha ilyen lesz, majd írok róla, mert ugye elméletileg az elmélet és a gyakorlat ugyanaz, de gyakorlatilag nem. 🙂