Minden ERP rendszer a valóság valamilyen pontosságú modellezése. A beruházás során választott modell pedig erőteljesen befolyásolja az elérhető hatékonyságot, így nagyon nem mindegy, hogy a választott rendszer a mi működésünket modellezi vagy másokét. Ezért első lépésben magunkat kell megismerni. A csere előtt értékelni kell, hogy a meglévő ERP rendszer mely területeken működött megfelelően, melyek a nem tartható gyengeségei és fontos megvizsgálni, hogy van-e lehetőség a rendszer élettartalmának a meghosszabbítására (miután ez a leggazdaságosabb megoldás). Ezt követheti a raktár és a gyártás újraszervezése, amely során még az új rendszer választása és bevezetése előtt meg kell szabadulni a hibás szokásoktól, ki kell alakítani az új ERP képes környezetet és ERP független módon ki kell alakítani a szükséges adatbázisokat. A rossz és hiányos adatok ugyanakkora kockázatot jelentenek, mint a hibás termelési környezet és a hibás választás.
Az alábbiakban egy szokatlanul pontos modellt mutatok be, melyet az alap ERP rendszerek általában meg sem közelítik. Nem is biztos, hogy erre szükség van, az egyszerűbb (így alacsonyabb árfekvésű) modelleknek is megvan a helye.
Ez a leírás egy konkrét ERP részfeladat megismerésében segít és lehetőséget ad arra, hogy a beruházó betekinthessen a feladat(ok) összetettségébe és ne csak azt tudja megfogalmazni, hogy mire van szüksége, hanem azt is, hogy mire nincs. Az ERP rendszerek – a piaci szegmens növelése érdekében – rengeteg olyan dolgot tudnak, amelyre a beruházónak nincs szüksége. Legalább azokat kell levagdalni, amelyek többlet terhelést vagy kárt okoznak.
A leírás lényegében egy funkcionális rendszertervnek tekinthető, amihez egy üzemképes, könnyen módosítható tanulmányrendszer is tartozik. A tanulmányrendszert a termelés újraszervezéseknél kell/lehet használni, mert a munkatársaknak minden változás elfogadása kifejezetten nehézséget okoz, ezért még a megvalósítás előtt, az újraszervezési fázisban szemléltetni, majd gyakoroltatni kell az új folyamatokat. Csak ezt követően történik az ERP rendszer igényjegyzékének az összeállítása, de ez a rendszer szolgál arra is, hogy a nyilvánvalóan hiányzó adatokat a belső szakemberek még időben ERP független formában alakítsák ki.
Ha ezt a feladatot egy piaci ERP rendszerre bízzuk, akkor esély sincs arra, hogy mást (esetleg alkalmasabbat) válasszunk.
Az ERP csere feladatkörből most egy olyan feladatot választottam, amely a raktár és a gyártás között van: a gyártáshoz szükséges anyagok kivételezését.
Az IPAR 4.0
A KKV szektorban az IPAR 4.0 követelményeitől olyan messze vagyunk, mint Makó Jeruzsálemtől. És sajnos pillanatnyilag még távolodunk is. Az is nyilvánvaló, hogy csak a – számunkra megoldhatatlan – teljes gépcsere jelenthetne megoldást, de sem a hálózatba kapcsolt megmunkálógépekre, sem a robotizálásra, sem az új szemlélet és ipari kultúra bevezetésére nincs mérhető esély. Ennél sokkal nagyobb probléma, hogy az igény is kicsi.
E helyett azonban az ERP rendszerek működési körében mód lenne az automatizálások bevezetésére és a magasabb színvonalú munkaszervezésre csak arra kéne törekednünk, hogy mindent, ami szoftvereszközökkel megoldható a szoftverek oldják is meg és ahol csak lehet száműzzük az élőmunkát és az emberi döntési helyzeteket. Az új szemlélettel jó lenne elveszejteni a ma még uralkodó „ezt nem kérjük, majd a munkatársak megoldják” választásokat.
Három területen kellene előre lépni:
Az első lépés ehhez is a folyamatok újraszervezése.
Termelés újraszervezés
Az ERP csere feladatkörből most egy olyan funkciót választottam, amely a raktár és a gyártás között van: a gyártáshoz szükséges anyagok kivételezését. Ennek a funkciónak speciális helyzete van, mert vitatható, hogy a gyártáshoz tartozik-e vagy a raktározáshoz. Az anyagok és alkatrészek kivételezését majd minden rendszer egy egyszerű raktározási funkciónak tekinti. Ez azt eredményezi, hogy a jól rendezett raktárból – ahol nem kell ismerni a cikkeket a kivételezéshez – kiveszik a cikkeket, valamilyen kocsira helyezik, ahol összekeverednek és elvesztik egyedi azonosítójukat. A kocsit elviszik egy gyűjtő/osztályozó pontra, ahol nagy szaktudást, cikk és termékismeretet igénylő drága művelettel ismét szétválogatják és csoportosítják, majd továbbítják az operatív munkahelyekre.
Ha a gyártáselőkészítő funkciót áthelyeznénk a raktárba, akkor annak terhelése csak ~10%-kal nőne, mert még a rendezett és jól azonosított állapottal lehet dolgozni, a gyártáselőkészítő munkakör viszont akár 80%-al is csökkenhet és a gyártás terhelése is csökkenhet.
Az, hogy a valóságban milyen értékek jönnek majd ki, azt a termelés újraszervezésének kell meghatározni. Mindössze annyit csináltunk, hogy a gyártáselőkészítési feladatok egy részét átszerveztünk a raktárba, de körültekintően kell eljárni mert ezzel az ERP rendszer hagyományos szerkezetét felrúgtuk.
A továbbiakban azt vizsgáljuk, hogy mit várhatunk egy ilyen fejlesztéstől és milyen eszközök állnak rendelkezésre.
A raktárnak a szerepe az, hogy tárolja az értékesítéshez, a gyártáshoz és a működéshez szükséges anyagokat és pufferként működve biztosítsa az anyagok folyamatos rendelkezésre állását. A gyártás feladata, hogy félkész vagy készterméket gazdaságosan állítson elő.
DE!
Sem a raktározásnak, sem az értékesítésnek vagy a gyártásnak nem feladata a könyvelés. A munkatársai nem értenek a könyveléshez és borzasztóan nem érdekli őket. Ezeket a területeket a könyvelés semmilyen formájával nem szabad terhelni, és sehol sem jelenhetnek meg könyvelési adatok vagy folyamatok. Az elő és utókalkulációhoz szükséges adatok kialakítása, rögzítése és karbantartása a könyvelés és/vagy a kontrolling feladata.
A gyártásban (és a raktárban) működő minőségbiztosítási rendszer feladata, hogy a gyár azonos minőségben gyártson le minden terméket.
Nem jó minőségben, hanem azonos minőségben!
Ezért a gyártás nem tudhatja, hogy a termék kinek készül, a rendszer ilyen adatok nem tartalmazhat. A gyártás munkatársai semmilyen körülmények között sem vehetik fel a kapcsolatot a megrendelővel, erre az esélyt sem szabad megadni.
Kiszedésnek fogjuk nevezni azt a folyamatot, amikor a raktárban található cikkeket – esetleg valamilyen adatgyűjtő segítségével – az elosztóponthoz vagy felhasználáshoz szállító logisztikai eszközre helyezzük. Ez a folyamat alapjaiban függ attól, hogyan működik a raktár, mit várunk el a kiszedőeszköztől és a további lépésekben hogyan lesznek feldolgozva a cikkek. Ennek megfelelően a kiszedési eljárás működését a raktári oldal, a kiszedőeszköz és az értékesítés, ill. gyártásvezérlés logikája határozza meg ezért első lépésben rendszerezni kell azokat az igényeket, amik meghatározzák, hogy a kiszedéshez milyen eljárást kell választani.
Tehát azok a tipikus megoldások, amelyekben a kiszedés egy egyszerű raktári művelet biztosan egy gyenge modellt jelentenek. Ezeknél a rendszereknél a szoftver tervezési, fejlesztési és üzemeltetési érdeke felülírja a gyártás érdekét.
Egy általánosnak nevezhető sémában van több raktárunk, a raktárakban van egy gyűjtőpont, vannak üzemcsarnokaink, amelyekben elosztási pontok vannak. Az elosztási pontokról kerül az anyag és alkatrész a megmunkálópontokra. Ezek azonban nem minden esetben léteznek vagy nem elegendően nagyok az optimális megoldáshoz és az sem mindegy, hogy a raktár mennyire van távol a gyártócsarnoktól, esetleg összeépültek-e.
A gyártási szemléletű ERP rendszerben a kiszedés közvetlenül kiszolgálja a gyártást, ezért azt, hogy egy konkrét esetben milyen kiszedési megoldás az optimális csak helyszín felmérésével és teszteléssel lehet megállapítani.
A feladat mélységébe betekintve az is látszik, hogy a megbízónak közvetlenül részt kell venni a felmérésben és a rendszerterv kialakításában és nem bízhatja azt a beszállítóra.
Már ha valóban jó ERP rendszert akar.
A közös munka nélkülözhetetlen.
Az a megoldás, hogy a beszállító végez egy felmérést, a végén átad egy rendszertervet majd ez alapján végrehajtja a módosításokat súlyos félreértésekre ad lehetőségeket.
A kiszedési folyamat logikája
Vannak bizonylat alapú ERP rendszerek és vannak feladat alapú rendszerek.
A bizonylat alapú raktári rendszerek központi eleme egy minden tranzakciót tartalmazó bizonylattömb. Ezt lehet szűrni, bővíteni különböző kiadási és bevételi bizonylatokkal. Ezek a bizonylatok az ügylet minden adatát (vevő-beszállító és könyvelési adatokat is) tartalmazzák.
A feladat alapú folyamatoknál teljesen mindegy, hogy ki szállította be vagy ki a cikkeket, milyen bizonylatokon szerepel, és hogy van-e rajta foglalás és kinek a részére.
A raktárban csak adott paraméterű cikkek szerepelnek, adott helyen és adott mennyiségben. A raktárosokat semmi más nem érdekli, sőt a többlet információ kifejezetten akadályozza a munkát.
Az anyagáramlás szempontjából a raktári kiszedés többféle lehet:
Az első három megléte esetén az ERP rendszer valószínűleg fejlett webáruházzal rendelkezi és alapjában értékesítési rendszer. A negyediknél magas-raktár van.
Önálló anyagmozgást jelent a termelési igények kiszolgálása.
A továbbiakban csak a termeléshez tartozó megoldásokat vizsgáljuk.
A raktári oldalról a kiszedési eljárást befolyásoló tényezők
Technikai adagkezelés.
Az egyik meghatározó elem az adagkezelés. Lehetséges megoldás, hogy nincs adagkezelés, de a raktár kezelhet BATCH-et, LOT-ot, SARZS-okat is, amik eltérő technológiákhoz (iparágakhoz) tartozó adagkezelési eljárások. Az adagkezelés végső soron azt határozza meg, hogy egy cikket melyik tárhelyről kell kiszedni. Ekkor a cikkszám mellett megjelenik az adagszám, amit a bevételezésnél rögzíteni kell. Ez a két azonosító együtt határozza meg, hogy honnan kell kivételezni a cikket.
Az adag típusán túl a tényleges eljárást meghatározza, hogy milyen célt szolgál az adagkezelés. Ez lehet visszahívás, valamilyen lejárati paraméter meghatározás és lehet konstrukciós előírás. Ilyen konstrukciós előírás pl. az, hogy egy szék támláját és ülését, avagy egy öltöny zakóját és nadrágját ugyanazon LOT azonosítójú anyagból (végből) kell készíteni. Ilyenkor előfordulhat, hogy a raktár tele van, mégsem tudjuk a rendelést teljesíteni. Egy raktáron belül elvileg több eltérő adagfajta is lehet, de erre nem szokás készülni, mert csak olyankor fordul elő, ha a gyártási portfólió lényegesen eltérő gyártástechnológiákat igényel, ami általában külön divízióban van, önálló raktárral. A technikai adagkezelést meghatározó paraméter azt írja elő, hogy azoknál a cikkeknél, ahol meg van adva az adag, használni kell az adagkezelést. Maga az adagkezelés csak a kiszedési jegyzékben jelenik meg, oly módon, hogy az azonos cikkszámú (de eltérő adagszámú) cikkeket tartalmazó tárhelyek közül melyik kell választani.
A termelésirányítás szempontjából nagyon fontos, hogy csak olyan adagkezelést engedjünk meg, amely valóban nélkülözhetetlen. Tudnunk kell, hogy a FIFO, LIFO eljárásokhoz nem kell adagkezelés.
Az összes bemutatott eljárás változtatás nélkül használható, mert az adagkezelés csak a kiszedési listát módosítja
Beszállítási adagkezelés.
Kezelhetünk beérkezési adagokat is, amikor beszállítónkként külön tárhelyen tartjuk a cikkeket és lejáratos adagokat is (amikor a cikk felhasználására időbeli korlát van). Ilyenkor nem elég a beszállítási időpontot nyilvántartani, mert azt is ismerni kell, hogy a beérkezéskor milyen idős volt a cikk.
A beszállítási adagkezelés – a lejárati időn túl – akkor használatos, ha egy kiszállítást csak egy beszállító termékeiből akarjuk teljesíteni. Ez abban különbözik a technikaitól, hogy bevételezésnél nem tartozik hozzá adagszám rögzítés.
Az összes bemutatott eljárás változtatás nélkül használható, mert az adagkezelés csak a kiszedési listát módosítja
Az adagkezelés módja.
Az adagkezelés lehet homogén, amikor egy batch csak egyféle adagot használhat és lehet inhomogén, amikor a batch többféle adagot is felhasználhat. Az inhomogén adagkezelés nagyon megnehezíti a kimenő-adagszámos termékek gyártását.
Az adagkezelésből mindössze annyi látszik, hogy a kiszedési lista látszólag nem optimálisan választja ki a bejárási útvonalat, esetleg nem engedélyezi a kiszedést annak ellenére, hogy látszólag van a kért cikk raktáron és a darabszáma is elegendő.
Adagkezelés nagyon megnehezíti a raktár működtetését, ezért csak akkor szabad bevezetni, ha törvény írja elő használatát. Az összes bemutatott eljárás változtatás nélkül használható, mert az adagkezelés csak a kiszedési listát módosítja
Gyári-szám kezelés.
Ha vannak gyári-számos alkatrészek (késztermékek), akkor a kivételnél minden cikk esetén, egyenként ki kell választani a gyári-számot. Ha kézzel adjuk meg, akkor a rendszer ellenőrzi, hogy van-e olyan gyári-szám. Ha a gyári-szám vonalkódon van, akkor csak be kell olvasni.A gyári-szám beviteli mezője csak akkor jelenik meg, ha az aktuális cikkhez tartozik gyári-szám.
Csak nagyon speciális termékeknél fordul elő, hogy egy gyári-számos fő-alkatrész kerül beépítésre.
Garanciajegy.
Csak az értékesítési üzletágban van szerepe a garancia (jótállás) kezelésének. A gyártás esetén a jótállást szerződéses szinte szokás kezelni.
Nyilvántartási mód.
Tipikusnak mondható, hogy a raktárban vonalkóddal azonosított tárhelyek vannak kialakítva, de van olyan raktár is, ahol nincsenek vonalkódok. Sőt olyan is, ahol még klasszikus tárhelyek sincsenek. Ezért többféle azonosításra kell készülni, de van két kitüntetett mód: a vonalkód és a tárhelyazonosító szám alapú azonosításra. A vonalkód többféle lehet, ezért itt is a névben pontosítani kell, hogy milyen megoldásra készüljön a raktári kiszedő modul (pl: AEN13, a tárhelyeken 2D-s bárkódokat nem használunk, ha mégis, akkor az 1D/2D jel is szükséges, pl. AEN13D2).
Bejárási útvonal.
A bejárási útvonal lehet eseti, rendezett és optimalizált. Az eseti bejárásnál a raktári munkatársakra bízzuk az útvonal megválasztását. (Ne becsüljük le ennek a hatékonyságát.) Tipikus megoldás a Rendezett (indexszelt) bejárás, amikor a tárhely kialakításnál a tárhelyekhez egy sorszámot rendelünk és erre rendezve adjuk meg a bejárási útvonalat. Ez nem valódi optimalizált útvonalat ad, de olcsó és elegendően hatékony lehet. A jól optimalizált bejáráshoz rögzíteni kell a raktár topológiáját (hol vannak átjárok, vak-járatok stb.) és azokat a kihelyezési szabályokat, amelyek alapján a tárhelyek kiosztása automatizálva van (pl. káosz-raktárak esetén). Az optimalizálás célfüggvénye lehet az, hogy egy tárhelyet csak egyszer érintsünk, lehet a minimális bejárási hossz. Lehetnek összetettebb célok is, pl. a nehéz cikkeket ne utaztassuk, vagy bizonyos anyagok nem lehetnek együtt egy kocsin (tűz és robbanásveszélyes anyagok). Az optimalizált bejárásnál érdekes kérdés az útvonal megjelenítése. A döntésnél figyelembe kell venni, hogy egy gyakorlott raktárosnak semmi szüksége nincs az optimalizált útvonal megjelenítésére, elegendő ha a cikkek az optimalizált sorrendben vannak a kiszedési listában.
Tárolási mód.
A raktárban „L1”-es tárolási móddal jelöljük azokat a cikkeket (tárhelyeket), amelyeket szigorú elszámolással vételezünk be és adunk ki. Ezek a hagyományos értelembe vett tárhelyek. A cikkek egy részét azonban – rendszeres használatuk miatt – kihelyezzük a gyártóegységek mellé. Ezeket egy szigorú elszámolású tranzakcióval töltjük fel a raktárból, de a művelet vételezi ki őket. Bizonylat ilyenkor is keletkezik, de ez nem szigorú elszámolású. Ez a tárolási mód szinte minden gyártásnál előfordul. Ezeket az anyagokat általában rezsianyagnak tekintjük és L2 szintű tárolási móddal jelöljük. Természetesen ezek az anyagok is megtalálhatóak a raktárakban és ott L1-es szinten szerepelnek. Az L2 szintű tárolók minimum készlet és feltöltési szint alapján készletfeltöltési tranzakcióval töltődnek fel. Van olyan tárhely is, amelybe valamilyen művelet outputjaként kerül egy alkatrész vagy részegység, és amelyet egy másik művelet vételez ki. Ezek a klasszikus gyártásközi raktárak, amelyeknek egyik oldala sem szigorú elszámolású. Őket L3-as szinttel jelölöm. Az L2 és L3-as cikkeket a kiszedés során nem kell kiszedni, mert a felhasználás céljára a gyártóhelyeken vannak készletezve, de a technológiában (valamilyen módon) szerepelniük kell. A „tárolóhely típusa” adatot az egyszerűbb rendszerek cikkadatként tartalmazzák és csak a kiszedés működését befolyásolják. Valójában a tárolási mód egy tárhelyadat, amelyik az állványadatokban jelenik meg. Vannak további speciális tárhelyek is: hordók, silók, tartályok, szabad területek stb. Ezeknek saját kiszedési mechanizmusuk van.
Kiszedési mód.
Ha bármiből nagyobb tétet kell megszámolni, akkor ezt kétféleképpen szokás megtenni. Vagy egyvégtében leszámoljuk az elsőtől az utolsóig vagy csoportokra osztjuk és úgy számoljuk meg (négy vonal, az ötödikkel áthúzzuk). Hogy melyik jobb módszer az adottság kérdése. Jelen esetben a csoportot egy batch jelenti. Tehát számolhatjuk a cikkeket Batchenként és számolhatjuk Összesítve.
Elsősorban a színvezérlésnél van jelentősége, mert ott batchenként is ki lehet helyezni a színeket.
A kézi adatgyűjtő azonosítása.
Maga a kiszedés valamilyen adatgyűjtő segítségével kézzel történik. Az eltérő gyártmányú adatgyűjtőkhöz azonban eltérő operációs rendszer és alkalmazási szoftverek tartozik. De a betanulási vagy raktár újraszervezési fázisban az adatgyűjtő lehet egy lista is, hogy a betanulás ne terjedjen ki egy időben a raktári folyamatok és adatgyűjtő használatának a megtanulására. A tablet egy Bluetooth-os adatgyűjtővel elsősorban targoncán vagy a kiszedőkocsin használható. Ezek a modulok jelennek meg a raktári terminálokon is. Az adatgyűjtőn be kell állítani az alkalmazott karakterkészletet, de ez csak akkor kritikus, ha a vonalkód betűket is tartalmaz. Be kell állítani továbbá az automatikus CR módot. Az ERP rendszer fejlesztői szeretnek egy adott típussal dolgozni és jó ezt a megrendeléskor elfogadni, bár az eszközök minősége és ára között hatalmas különbségek vannak. A nagy-képernyős, nyomógombos, pisztolyfogantyús, ejtésbiztos ipari készülékek a legjobban. És a legdrágábbak.
Kiszedőeszköz (kiszedőkocsi) azonosítása.
A kiszedőeszköz sokféle lehet, illeszkedve a cikk / termék tulajdonságához. Lehet kocsi, tálca, rakonca, láda, konténer, raklap, krumplis-láda stb. A kiszedőeszközt gyakran nevezem kiszedőkocsinak mert az ipari környezetben ez a leggyakoribb megoldás.
Az azonosítás módja.
A kiszedőkocsit nem feltétlenül kell azonosítani, de nagyon ajánlott. Az azonosítás lehet egy sorszám, egy RFID bélyeg, egy vonalkód, egy írásjel, egy szín stb. A választás a gyártás eljárása alapján történik és szó sincs arról, hogy mindig a vonalkód a jó megoldás. A vonalkód lehet többféle is ezért a vonalkód esetén annak típusát is meg kell adni, pl. „EAN13 vonalkód” vagy „EAN128 vonalkód stb.”. A kiszedőeszközön (kocsin) lehet többféle azonosítás is, pl. egy kód azonosíthatja magát az eszközt, további kódok pedig az eszközön lévő konténereket. Az eszközazonosításnál csak azt adjuk meg, hogy milyen típusú azonosítás történik, de azt nem, hogy az azonosító mit takar. Ilyen azonosító lehet pl az „EAN13 vonalkód”, amikor a rendszernek arra kell készülni, hogy egy vonalkódot be kell majd olvasni. Lehet pl. „EAN13 vonalkód + RFID”, amikor (egy RFID kártyára ragasztunk egy vonalkódot). Ilyenkor a kiszedéshez használt adatgyűjtővel a cikk is azonosítható a tárolóhelyen és a kiszedőkocsi is, de lehetőség van arra, hogy a továbbiakban a gyártásokhoz sokkal jobban illeszkedő RFID azonosítót használjunk.
A kiszedőeszközöket több rendszer is tárhelyként kezeli. Ez nem helyes megoldás, de általában használható. A kiszedőeszköz az egy „Eszköz” entitás, amelynek van tárolási tulajdonsági is, de egy sor olyan tulajdonsága is lehet, ami nem értelmezhető a ráktári tárhelyek esetében (pl. leltári szám, önjáró eszközök műszaki adata).
Az azonosító típusa.
Az eszköznek lehet fix azonosítója (amely soha nem válik el az eszköztől), és lehet dinamikusan változó azonosítója. Fix azonosító pl, az eszköz valamely részére felragasztott vonalkód, dinamikus azonosításról beszélünk, amikor az eszközön lévő tárolóelembe belehelyezünk egy azonosító kártyát (pl. egy papírkártyát vagy RFID kártyát). A Fix azonosító és az RFID kártya esetén az azonosítónak szerepelnie kell az „Eszközök” törzsadatban, a dinamikus esetében pedig bármilyen azonosítót akár eseti jelleggel is létrehozhatunk. Azaz a Fix azonosító az eszközt jelöli, a dinamikus az eszköz tartalmát is.
A kiszedésnél használandó programot befolyásolja a gyártás vezérlése.
Azonosítási szint.
A gyártást általában finomprogramokba (gyártási ütemekbe) szervezzük. A kevésbé igényes kiszedésvezérlések esetén a kiszedés azonosítási egysége maga a finomprogram, azaz a kiszedett cikkek tömegéhez csak azt tudjuk megmondani, hogy melyik program anyagai. Ez sokszor elégséges megoldás, de mindig költséges. Érdekes módon ez gyakoribb megoldás, mint az ember gondolná. A módszer nagy hibája, hogy míg a raktárban pontosan azonosítva vannak a cikkek – ezért nem kell ismerni őket, addig a kiszedőkocsin már összekeverednek, ezért ahhoz, hogy kihelyezzük egy munkahelyhez pontosan ismerni kell őket. Ez nagyon erőforrás pazarló eljárás, ráadásul ez a munkakör (gyártás logisztikus), a hosszú betanulási idő miatt nehezen helyettesíthető munkatársat igényel. Szervezhetjük úgy a kiszedést, hogy a cikkek a finomprogramon belül batchenként (késztermékenként) legyenek kigyűjtve. Ilyenkor a kocsin egy-egy késztermék anyaga található. Megtehetjük azt is, hogy egy kocsi egy késztermék egy munkahelyéhez tartozik, de azt is, hogy a munkahely tevékenységéhez szükséges összes anyagot tesszük egy kocsira. Ennek megfelelően a finomprogramon belül azonosítunk egy munkahelyet, vagy egy „batchet” vagy „munkahelyet”.
Miután minden megoldáshoz más-más gépelrendezés, más munkaszervezés, erőforrás kiosztás és operatív program tartozik ezért nagyon lényeges, pont olyan kiszedési eljárást alkalmazzunk, ami optimálisan illeszkedik a termékünkhöz és a technológiánkhoz.
Kitt kezelés.
Az anyagokat és alkatrészeket olyan mennyiségben kell a gépekhez kihelyezni, mint a megmunkálandó munkadarab mennyisége megkíván. Azaz van ahol a munkadarab gyártási egységének megfelelő alkatrészcsomagokat, kitteket kell képezni. Ez történhet a raktárban, ekkor eleve olyan csoportosításban szedjük ki az anyagokat, mint a gyártási egység. Történhet egy elosztási ponton, amikor a gyártáslogisztikusnak kell a kittet képezni. Történhet a gépek mellett, amikor az oda halmozott anyagokat és alkatrészeket a műveletet végző munkatárs készíti ki. A kiszedési szinten azonban a raktárban vagy „Van kittképzés”, vagy „Nincs kittképzés”.
Kittképzés esetén az anyagokat, alkatrészeket konténerekbe kell helyezni és a konténereket azonosítóval lehet ellátni. Miután minden konténer tartalma ugyanaz, az elegendő csak a finomprogramot és a batch-et azonosítani. Ha a konténerek RFID bélyeget kapnak, akkor az elszámolás sokkal egyszerűbb és pontosabb lesz.
Kittképzésről beszélünk akkor is ha egy vagy adott fajtájú cikkeket összecsomagolunk és a csomag önálló cikkszámot kap. Ezt is végezheti a raktár, de ez valójában egy (vagy több) művelet, amihez további anyagok (csomagoló anyagok, címkék stb.) tartoznak.
Hibakezelés.
A működés alapértelmezése az, hogy mindig pontosan annyi cikket szedünk ki amennyi elő van írva. Ha a munkatárs nyilvántartási hibára fut, akkor alapértelmezésben raktári mozgásokkal kell rendbe kell hozni a nyilvántartást és csak ezt követően folyhat a kiszedés. Ha a nyilvántartás nem hozható rendbe, mert fizikailag nincs annyi termék és nem csak a tárhelyek közötti elosztása a hibás, akkor lehetőség van a batch tiltására és a következő batchhel való folytatás. Ekkorra a termelésvezető üzenetet kap, mert a hibát neki kell elhárítani. Bizonyos esetben meg kell engedni a folytatás a hibás termelési feltételek mellett is. Ha a Hibakezelés paraméter értéke „Tovább mehet”, akkor a kiszedés folytatható, de a termelésvezető kap egy képernyő értesítést, egy mailt és egy SMS-t. Ha az értéke „Várakozik”, akkor a hiba kijavításáig nem mehet tovább.
Üzemmód
A Tanulmányrendszerben van oktatási, normál és professzionális üzemmód. Ezt az ERP rendszerek nem ismerik. Miután a Tanulmányrendszer lényegéhez tartozik a gyors módosítás és az oktatás, ezért itt kitüntetett szerepe van a tesztelésnek és betanulást megkönnyítő megoldásoknak.
Oktatási üzemmód.
Az oktatási üzemmódban jelennek meg azok az adatok, amelyek a gyakorlatlan munkatársakat segítik a betanulási fázisban. Megjelennek tájékoztató adatok, részletesebb üzenetek és kisegítő információk. Ebben az üzemmódban lehet helyettestő eszközöket használni (pl. listákat eszközök helyett, kézzel megadni eszközök által beolvasandó adatokat és tesztkörnyezetet beolvasni). Bizonyos esetekben kifejezetten nehézkes egy új rendszer gyakorlása és tesztelése. Ennek az-az oka, hogy sok folyamat egy sor más tevékenység után következik. A teszteléshez és gyakorláshoz ezek mindig végre kell hajtani (pl. a kiszedés gyakorlásához minden alkalommal össze kell állítani egy durvaprogramot, egy finomprogramot és egy kiszedési jegyzéket. Ezután következhet a tesztelés. Az oktatási verzió képes visszaállítani azt a pontot, ahonnan rögtön a tesztelés kezdődhet. Egy folyamat tesztelése után visszatöltjük a kiszedés előtti hibátlan állapotot és más kiszedési helyzeteket vizsgálhatunk. Ez nagyon hiányzik az ERP rendszerekből ezért a betanulás a kelleténél sokkal jobban terheli a felhasználót. Ebben az üzemmódban megjelennek olyan tájékoztató adatok is, amelyek a működés megértését szolgálják.
Normál üzemmód.
Semmilyen nélkülözhető adat nem jeleni meg.
Professzionális üzemmód.
Még az adatok neve sem jelenik meg csak maga az adat. Olyankor használható, ha már jól ismerik a képernyőket a munkatársak.
Kiszedési megoldások.
A különböző kiszedési lehetőségekhez más-más felépítésű és feladatú kiszedési modul tartozhat. Gyakorlatilag elképzelhetetlen, hogy egyetlen kiszedőmodullal több gyártási eljárás is magas-szinten megoldható legyen. A megfelelő modul kiválasztás a raktárat és a gyártást leíró rendszerparaméterekkel történik. A finomprogramhoz szükséges cikkek (anyagok, alapanyagok, alkatrészek, fő-alkatrészek, részegységek, félkésztermékek stb.) kiszedése több raktárt is érinthet ezért a kiszedési lista raktáranként keletkezik, így a kiszedés során első lépésben azt kell meghatározni, hogy melyik raktárban történik a kiszedés. Nagy raktárak esetén akár szekciónként is folyhat párhuzamos kiszedés. Miután egyidejűleg több finomprogram is létezhet, ezért a kiszedés megkezdése előtt a finomprogramot is meg kell nevezni, de elvárható, hogy a rendszer automatikusan felkínálja a legrégebbi finomprogramot. A kiszedési képernyő csak azokat az adatokat tartalmazhatja, ami egy tétel kiszedéséhez feltétlen szükséges. Miután a kiszedés közben a raktárosnak nincs döntési feladata, ezért semmilyen tájékoztató adat nem jelenik meg. A kiszedés során sem a cikkszám, sem a tárhely, sem a mennyiség a kiszedő szintjén nem módosítható. Ahol ez nem tartható ott még súlyos raktárszervezési és vezetési hibák vannak, ezeket még a bevezetés előtt javítani kell. A bemutatott megoldások sokkal pontosabbak a szokásos megvalósításoknál. Tipikus megoldás, hogy a kézi adatgyűjtőn megjelenik a kiszedendő mennyiség és munkatárs beírja, hogy ennyit sikerült kiszedni. Ez a megoldás automatikusan elfogadja a rossz raktárvezetést, de az összes problémát ezzel a gyártásra terheli egy gyárthatatlan helyzet létrehozásával. Tény, hogy ezeket könnyebb bevezetni, mert a bevezetési szakaszban sem a raktárban, sem a gyártásban még nem derül ki a megoldás hibája. Az általam javasolt raktár működési rend lényegesen szigorúbb a szokásosnál. Ezért mindig azt tanácsolom, hogy az ERP bevezetés előtt újra kell szervezni a raktár működését. Ha egy cég nem képes egy fegyelmezett raktár működtetésére, akkor még nincs ott az ideje egy korszerű ERP rendszer bevezetésének. A legnagyobb hiba, amit el lehet követni, hogy költségmegfontolásból, jóhiszeműségből, időszűkéből vagy bármilyen más okból elfogadjuk az ERP rendszer gyártásunkhoz nem jól illeszkedő megoldását.
Kiszedés általános folyamata.
Az alábbiakban egy Tanulmányrendszer megoldásai kerülnek bemutatásra. A tanulmányrendszert csak az újra-szervezésnél használjuk ezért lényegesen eltérhet a bevezetésre kiválasztott ERP megoldásától. Az egyszerűség kedvéért a „Kiszedőeszköz” megnevezés helyett a kiszedőkocsi kifejezést használom. Az eszköz sokféle lehet keret, kocsi, bevásárlókocsi, rakonca, krumplisláda, tálca, raklap stb. Elsősorban a gyártási ütemhez szükséges anyag mennyisége, jellege és súlya határozza meg a típusát. Bár fizikai megjelenése jelentősen eltérhet, logikai szinten ezek azonosak. A gyártáslogisztikus dönti el, hogy mikor állítja össze a kiszedési listát és az ő döntése az is, hogy hány kiszedési listát állít össze. Hogy több kiszedés esetén ne legyen keveredés, ezért a raktárban a kiszedéseket egymástól elhatárolva kell tárolni. A raktárvezető felelőssége, hogy a keveredést egy megfelelő eljárással megakadályozza. A kiszedés összeállítása a finomprogramban egy gombnyomással történik (a „Kiszedési jegyzék összeállítása” nevű gomb). A gyártandó termékeket egyértelműen meghatározza a finomprogram, a szükséges anyagokat pedig meghatározza a technológia. Ezektől sem a gyártáslogisztikus sem a raktáros nem térhet el, mert nem ezen a kompetencia szinten vannak. A bonyolult, sok adatot megjelenítő, ad hoc döntésre lehetőséget adó kiszedési megoldások hibásak, feleslegesen terhelik a munkatársakat és rontják a gyártás biztonságát. A gyártáslogisztikus beleszólhat abba, hogy mikor kezdődjék a cikkek kiszedése, a „Kiszedéskérés” gombban a megadott azonosítójú programhoz tartozó kiszedés beszállítását kérheti. Miután Ő látja a gyártás előrehaladását meg tudja mondani mikor kéne elkezdeni a kiszedést. A logisztikus dönti el azt is, hogy az összeállított kiszedést mikor kell beszállítani az elosztási pontokra. Miután a raktáros vagy észreveszi a beérkezett kérést vagy nem, ezért a kérés egy SMS üzenet is küld megjelölve, hogy melyik kiszedést kell teljesíteni és megjelenik a telefonszám is, amelyen a kapcsolat felvehető. Ez akkor lényeges, ha több gyártáslogisztikus is van. (Ezen az ábrám a „Kiszedés” gomb csak bemutatási/oktatási célból szerepel, az éles megoldáson nincs itt helye.)
Döntési helyzet nincs, a raktári munkatárs sem a kiszedés sorrendjén, sem a kiszedett mennyiségen nem változtathat, tehát nincs helye semmilyen beavatkozási lehetőség megadásának, de kezelni kell a felmerülő hibákat.
Kiszedésnél előforduló hibák:
Az elképzelhető legrosszabb gyártási szokás az, amikor hiányzó alkatrészek mellett kezdődik el a gyártás. Ettől mindenképpen meg kell szabadulni és meg kell keresni a valódi hibát. aminek legtöbbször – valamilyen nehezen bevallható oka van. Hiba esetén a „Batch kiszedés leállítása” gombot kell megnyomni. Ettől kezdve a kiszedés a következő batchtől folytatható. A hibás batch csak a hiba elhárítása után szedhető ki. Ez meglehetősen sürgős ezért a művezető kap egy SMS-t, amelyben látható a tárhelyazonosító és az üzenet küldőjének a telefonszáma.
A jól vezetett raktárak esetén is lehet cikkhiány, mert a selejt javítási művelet lefoglalt cikket is kiszedhet. A termelés napi több finomprogramot igényelhet, ilyenkor – ha más munkavezetői utasítás nincs érvényben – a legkisebb sorszámú finomprogram anyagát kell kiszedni. A kiszedés a raktárvezető hatáskörében van, de ha egy kiszedéskérés utasítás érkezik, azt nem késleltetheti, és nem írhatja felül.
Általános használata.
Bár a kiszedési modul nagyon sokféle lehet, de meg tudunk fogalmazni általános elvárásokat. Az első lépésben meg kell adni, hogy melyik finomprogram anyagait kell kiszedni. Egyidejűleg sok finomprogram lehet jelen ezért elvárjuk, hogy a rendszer mindig automatikusan ajánlja fel a legrégebbit teljesítetlen vagy részteljesített programot.
Ezt követő lépés a raktár kiválasztása. Nagyon fontos, hogy minden munkatárs csak annak a raktárnak az anyagait lássa, ahová vezényelték. A raktárban lehetnek szekciók és a kiszedés meggyorsítása érdekében a szekciókhoz is vezényelhetünk munkatársakat. (A tanulmányrendszer mintáiban most nem kezelünk szekciókat.) Szép (elvárható) megoldás, ha a raktárat nem csak egy legördülőmenüből (vagy beírva) lehet kiválasztani, hanem egy tetszőleges tárhelyazonostóra pittyentve megállapítja, hogy melyik raktárban vagyunk.
A kiszedési lista meghatározza, hogy melyik tárhelyről kell kiszedni cikket, így az alkatrészek ismerete nem feltétele a helyes kiszedésnek. Ehhez azonban az kell, hogy minden cikk önálló tárhelyen legyen. Miután a raktárak kitöltöttsége általában nagyon alacsony (a raktárakban leginkább levegőt tárolunk) ez az elvárás szinte mindig teljesíthető. Ha egy raktárban egy tárolóhelyen több cikk is található az raktárvezetői hiba.
A kiszedési lista felsorolásában csak az L1 szintű anyagok szerepelnek. Az L2 és L3 szintű anyagokat és alkatrészeket mindig a munkahelyeken raktározzák, így a központi raktárakból nem kell kivételezni őket.
A kezelőszervek használatának bemutatására vegyünk egy fejlett megoldást (6.2 – a kocsi és konténer is vonalkóddal van ellátva). A bemutatott eszköz mindenhol a tablet. A tipikus kiszedőeszköz egy digitális adatgyűjtő, amelynek ugyanezeket az adatokat kell tartalmazni.
A rendszer pontosan tudja, hogy egy cikk melyik tárolóhelyeket foglalja el. Ha a kiszedendő mennyiség több mint amit a legközelebbi tárolóhely tartalmaz, akkor eleve több téteben kerül kiírásra a kiszedés. Azaz nem fordul elő, hogy a raktári munkatársnak kell dönteni, hol szedi ki a cikkeket. Ha egy cikket több tárhelyről kell kiszedni, akkor előfordulhat, hogy az első tétel kiszedése után a „Következő” gomb lenyomására nem feltételen a következő ugyanilyen cikk kerül kiszedésre (pl. a káoszraktárak esetén), hanem a bejárási eljárás szerinti következő cikkre lép. Ha ismét elérkeztünk ugyanahhoz a cikkhez, akkor folytathatjuk a konténer töltését, de ismét pittyenteni kell a vonalkódra. Tehetjük új konténerbe is, majd rápittyentünk a vonalkódjára. Ha más cikk van benne alapértelmezésben hibát üzen a rendszer. Rendszerparaméterrel beállítható, hogy a cikk betehető legyen más cikket tartalmazó konténerbe is, de csak akkor, ha az ugyanazon finomprogramhoz (batchez és munkahelyhez) tartozik. A következő gomb csak akkor válik aktívvá, ha a megadott tárhely (és a többi vonalkód) ellenőrzése sikeres volt és van még kiszedendő cikk. Rendszerparaméterrel beállítható, hogy a kocsi és konténer vonalkód beolvasása ne legyen kötelező. Tárhelyként csak olyan vonalkódot szabad elfogadni, amely szerepel az adott raktár tárhely vonalkódjai között (a tárhely vonalkódokat az állványzatot leíró törzs tartalmazza).
A kiszedőeszköz nem tárhely, csak van tárhely tulajdonsága is. Eszköznek olyan vonalkódot szabad elfogadni, amely benne van az eszköz adatbázisban valamelyik kiszedőeszköznél. Ugyancsak itt szerepelnek a konténerek is.
Mind az eszköznek mind a konténernek van egy számmal megadott azonosítója is. A kiszedőmodul ezeket az azonosítókat is kezeli, nem kell feltétlen vonalkód olvasó a kezeléshez. Az azonosítónak az a jelentősége, hogy ha nem olvasható a vonalkód, akkor nem 13 jegyet kell beírni hanem csak 2-4-et. Ez biztosítja azt is, hogy a raktár akkor is működik, ha a olvasó meghibásodott és akkor, ha nincs. Az azonosító a vonalkód matricán is szerepel a számjeggyel kiírt vonalkódok mellett.
A program összeállításánál mindig megtörténik a készletellenőrzés és a foglalás, így elvileg nem hiányozhat cikk. Van azonban egy olyan művelet, amely a foglalt cikket is ki tudja vételezni, és ez a selejt javítás. Ha a tárhelyen nincs elegendő cikk, akkor vagy selejt javításon van, vagy egy téves kivételezés volt, amit nem vettek még észre. Ilyenkor a művezetőnek (vagy a termeléslogisztikusnak) kell intézkedni. Leggyakrabban nyilvántartási hiba miatt nem szedhető ki egy cikk, azaz fizikailag nincs meg a szükséges mennyiség a megadott tárolóhelyeken (máshol még lehet). Ennek kezelésére szolgál a „Módosítás” eljárás. Ha nem tudtuk az előírt mennyiséget kiszedni, akkor a módosítás ágban megadható, hogy ténylegesen mennyit szedtünk ki. Ez a „Következő” tétel kérésére könyvelésre is kerül és megjeleníti ugyanaz a cikket a maradék mennyiséggel. Itt ki lehet lépni a rendszerből és meg kell vizsgálni a nyilvántartási hibát. Erre a célra a rendszerek tartalmaznak egy „Rovancs” funkciót. Raktári mozgásokkal meg kell szüntetni a nyilvántartási hibát és javítani kell. Ezt követően belépve ismét a kivételezésbe onnan folytatódik a munka ahol abbahagytuk, tehát a korábban hiányzott cikkeket is kivesszük. Van, amikor fizikailag hiányzik a cikk. Ekkor két lehetőségünk van. A „Batch kiszedés leállítása” funkcióval befejezzük a kiszedést a hiba kijavításáig. Ez nagyon fontos a magas színvonalú működés eléréséhez, de eleinte elegendő időt kell hagyni az esetleges hibák kijavításához. A másik lehetőség, hogy a kiszedett mennyiség helyére nullát írunk. Ekkor a rendszer hibásként rögzíti a tételt és nyilvántartja hány cikket nem sikerült kivételezni. Ilyenkor folytatni lehet a munkát, de a termelésvezető kap egy hibaüzenetet (képernyőn, levélben és SMS-ben). Ez letiltható funkció, a termelésvezető akkor engedélyezi, ha a hiány oka a selejt javítás és a selejt valóban kijavítható.
A következő tétel kérése után a kiszedendő mennyiség mező ki van töltve. Az esetek legnagyobb részében ugyanannyi cikket kell kiszedni, mint amit előírt a rendszer. Ki van töltve a tárhely vonalkódja és az azonosítója is. A rendszer pontosan tudja, hogy melyik tárhelyről kell kiszedni a cikket. Nem is enged meg más tárhelyről kiszedést, még akkor sem, ha abban is ugyanaz a cikk van. A gyors fegyelmezett működés szempontjából ez nagyon fontos. A munkatársnak az a feladata, hogy végrehajtsa az utasítást, a munkakör ebben a kérdésben nem tartalmaz döntési feladatot. Előfordulhat az is, hogy kiszedés közben megtelik a kocsi vagy a konténer. Ha egy cikk kiszedése nem volt teljes, akkor a „Módosítás” gomb megnyomása után a „Kiszedendő” (mennyiség) mezőbe be kell írni a kiszedett mennyiséget és úgy kell kérni a következő tételt. Ekkor az újabb konténer (vagy kocsi) töltését ezzel a tétellel kezdi a rendszer. A tétel kiszedését a „Következő” nevű gomb megnyomásával kell nyugtázni. Ha a következő helyett a „Kilépés” gombot választjuk, akkor könyvelés nélkül kilép a programból. Ismételten belépve ott lehet folytatni, ahol abbahagytuk. Az utolsó tételnél egy figyelmeztető üzenetet is kapunk.
A képernyőn egy bár mutatja a kiszedési folyamat előrehaladását. Segítségével a raktári munkatárs ütemezheti a munkáját. Különösen hasznos a sürgős feladatoknál.
A „?” billentyű lista formában jeleníti meg a kiszedési feladatot, feltüntetve az összesített adatokat is, pl.: a cikkek számát, a cikkfajták számát. A cikkekhez hozzá van rendelve az alapértelmezett kiszedési egység (pl. konténer) így megjeleníthető, hogy a tétel kiszedés hány konténert fog igényelni.
Az oktatási módban megjelennek szimulációs gombok, amelyekkel a vonalkódolvasó helyettesítő, ill. a hibás leolvasás gyakorolható. Segítségével elválasztható a kiszedő program és az olvasó használatának gyakorlása. Azokon a helyeken, ahol elvárt válasz van (tárhely vonalkód) az elvárt válasz érkezik, azokon a helyeken, ahol választás van, ott véletlenszerű választás történik.
Ahhoz, hogy tesztelni lehessen egy kiszedést szükség van egy rendelésállományra, egy durva program összeállítására és egy finomprogram összeállítására, azaz a tesztelés nagyon nehézkes (lehetetlen) , ezért van egy „Tesztadatok visszatöltése” gomb, amely automatikusan visszatölti a kiindulási adatokat.
A rendszertől elvárjuk, hogy
Ezeket az alapvető ergonómiai követelményeket a felhő alapú rendszerek általában hiányosan tudják csak teljesíteni.
Készülni kell az alábbi, üzemszerűen is előforduló esetekre:
Ezeket kezelnie kell a kiszedőprogramnak, de csak azokban az esetekben amikor a vevő igényli vagy a működés ezt megköveteli.
A módszer lényegéhez tartozik a fegyelmezett működés és a megfelelő raktári rend. Ha ez nem áll rendelkezésre, akkor az ERP bevezetését meg kell hogy előzze a raktári rend kialakítása.
Az alábbi példákban a kiszedőeszköz a „Tablet”, amelyhez egyszerű és olcsó vonalkódolvasó csatlakoztatható. A vonalkód olvasón működnie kell az autoCR funkciónak.
A kiszedés akár lista alapján is történhet, de ilyenkor nincs valódi raktárkönyvelés. Ez jó gyakorló megoldás azokon a helyeken, ahol nincs korszerű raktározási gyakorlat.
A raktárhoz és a gyártáshoz jól illeszkedő kiszedőprogramoknak több ezer variációja lehet viszont a hazai ERP rendszereket általában csak néhány tucat felhasználó használja. A kiszedő modulokat így általában testre kell szabni.
Ehhez áll rendelkezésre, néhány tipus-megoldás.
Két stratéga tipikus.
A tanulmányrendszerben ki van dolgozva ~10 típus megoldás, amelyeknek a megszemélyesítésével kaphatunk újabb, a többitől független modulokat.
Alább külön tárgyaljuk a tárhely és vonalkód alapú eljárásokat és a színkód vezérlést.
Az egyszerűség kedvéért sehol sem kezelünk adagokat, gyári-számos és garanciajegyes cikkeket. Az utóbbiak leginkább az értékesítő cégek sajátja, a gyártásnál ritkán fordul elő. Nem kezelünk raktári szekciókat és fiókokat sem.
Nem vagyok híve a dinamikus tárhelyeknek sem (amikor egy raktári oszlopban a bevételezéstől függően lehet másfeles, dupla vagy tripla tárhely). A modell ezt sem kezeli.
Mindenhol engedélyezve van az L2-es tárhely használata.
Tárhelykód és vonalkód alapú megoldások.
1. megoldás
A raktárban tárhelyazonosítót használnak a kiszedőkocsi (és a konténer, ha van) nincs azonosítva ezért azonosítási szint nincs értelmezve.
Ezen a megoldáson mutatom be a három üzemmódot.
A tesztüzemmód megjeleníti a norma szerinti kiszedendő mennyiséget és az eddig kiszedett mennyiséget is. Ez akkor előnyös, ha nem sikerült a kiszedés vagy betelt a kocsi. Továbbá lehetőséget teremt a tesztadatok visszatöltésére. Ez nagyon fontos a teszt és betanulási időszakban. Az, mélységében megismerjék a munkatársak a program működését kellő gondossággal kell végig járni a lehetőségeket, ami nagyon nehéz, ugyanis minden teszt menet után meg kellene ismételni a bevételezés, a durva és a finomprogram összeállítását és a kiszedési lista generálását. A rendszer úgy működik, hogy létrehozunk egy adott raktári feltöltést és egy finomprogramot, valamint a hozzá tartozó kiszedési listát. Ezt követően konzekvensen kipróbálhatjuk a kiszedési folyamatokat. Ennek végeztével visszatöltjük a kiszedés előtti hibátlan állapotot és máris vizsgálhatjuk a következő kiszedési helyzetet.
Ez nagyon hiányzik az ERP rendszerekből ezért a betanulás a kelleténél sokkal jobban terheli a felhasználót.
A normál üzemmódban az adatok részletesen megjelennek, de csak azok, amelyek tényleg szükséges a munkához.
Ebben az üzemmódban semmilyen felesleges adat nem szerepel a képernyőn, mert a gyakorlott munkatárs a tárhelykódból már pontosan tudja, hogy hol keresse a cikket. Ha mégis elbizonytalanodik, akkor a „?” pontosan megmondja, hogy hol van a tárhely.
A nagy betűkkel való kiírás azért fontos, mert egy raktár általában alul-megvilágított hely, ahol rendszerint az idősebb, gyengébb szemű munkatársak dolgoznak (vagy azok lesznek). Ezzel a megoldással elkerülhető, hogy a munkatársak nagyítóval nézzék a kisebb képernyőjű adatgyűjtőket.
Ez egy gyakori kiszedési megoldás a digitálisan kevéssé fejlett cégeknél, ill. a kis cégek (100-200 mFt árbevétel) esetén, ahol egy komplexebb termelésirányítás nem finanszírozható meg.
Érdekes módon ugyan ezt találhatjuk a nagy szolgáltató láncoknál is (pl.: kávézók), ahol összesen néhány tucat anyag mozog. Általában a finomprogramok kicsik és kevés (vagy csak egy) termék előállítására szorítkoznak. Az is lehet, hogy nincs is finomprogram. A termékek egyszerűek, a műveletek száma kevés, esetleg nem is tartozik hozzá technológia csak anyagjegyzék. Az operatív munkahelyen általában elegendő egy lista a gyártandó termékekről és a termékek anyagjegyzékének megjelenítése (vagy még – az egyszerűség miatt – az sem kell). A raktárban nagy mennyiségek vannak cikkek és a termék előállítása L2 szintű tárolókból történik. A gyártási kivétel általában az L2 feltöltésére szorítkozik. A termékismeret mindig alapos.
Ezeken a helyeken teljesen felesleges egy vonalkódos rendszer bevezetése.
A raktárban sokszor nem, hogy vonalkód, de még sorszámozás és tárhely kiosztás sincs. A tárhelyeket azonban egy raktár újra-szervezési menetben mindenképpen ki kell alakítani és meg kell számozni.
A modellt nagy raktáraknál a bevezetés megkönnyítésére lehet használni, ha első lépésben túl sok változást a cég nem tűr el.
Hagyományos gyártásnál ne alkalmazzuk ezt az eljárást.
2. megoldás
A raktárban EAN13-as vonalkódos tárhely-azonosítót használnak; a kiszedőkocsi nincs azonosítva.
A következő fejlődési lépésben be kell vezetni a tárhelyet azonosító vonalkódot. A megoldás megegyezik az 1. megoldással, de itt a munkatárs a tárhely felkeresését követően rápittyent a tárhely vonalkódjára, az beíródik a mezőbe mire megtörténik az ellenőrzés.
Az oktató verzióban a vonalkód melletti jelekre kattintva megjelenik a cikk vonalkódja, így a kiszedés a vonalkód olvasó nélkül is gyakorolható. A másik gomb egy hibás kódot küld be.
A módszer nagy gyengesége, hogy míg a tárolókban jól rendezett módon vannak a cikkek, így ismerni sem kell őket, addig a kocsin összekeverednek és elvesztik a cikkszám információt. A kiszedett cikkek a továbbiakban egy osztályozópontra kerülnek, ahol egy „drága”, nehezen cserélhető munkatárs pontosan ismeri a cikkeket és cikkszám szerint ismét átrendezi őket a felhasználásnak megfelelően. A megoldás költséghatékonysága ezért alacsony.
Ez az alapértelmezés a legtöbb ERP rendszerben.
A raktári kivételezés ilyenkor egy egyszerű raktári alapfunkció.
3. megoldás
A raktárban és a kiszedőkocsin Fixen rögzített EAN13-as vonalkódokat használnak. A kiszedésazonosítás finomprogram és eszközszintű.
Ez egy fejlettebb szint, ill. ez lehet a következő fejlődési lépés. Ez abban különbözik az előző megoldástól, hogy a tárhelyre pittyentés után a kiszedőkocsi fixen rögzített vonalkódjára is pittyenteni kell. A leolvasások sorrendje felcserélhető, a program kitalálja, hogy milyen kódot olvastak be. A kocsi azonosításával nem csak ahhoz az információhoz jutunk, hogy mi van a kocsin, hanem ahhoz is, hogy melyik finomprogramhoz tartozik. Az azonosítás tehát finomprogram és eszköz szintű.
A megoldás sikeressége annak köszönhető, hogy többféleképpen is használható. A termék és a gyártási mennyiségtől függően egy kocsin lehet sokféle alkatrész, tartalmazhat egyféle alkatrészt (ilyenkor azonosítja a cikket a kocsi vonalkódja és megoldható az is, hogy a kiszedőkocsira konténereket teszünk és minden cikket másik konténerbe teszünk.
A felhasználás módját csak egy vezetői utasítás szabályozza.
Ha a kocsi megtelt, de a futó cikkszámból van még kiszedendő (10 van kiírva, de csak 8 fér el a kocsin), akkor a „Módosítás” gombot kell megnyomni, meg kell adni, hogy mennyi cikket sikerült kiszedni, majd a „Következő” gomb megnyomása után be kell olvasni az új kocsi vonalkódját.
Ebben a megoldásban a kiszedés egy egyszerű kétoldalas raktári áttárolás, ahol a kiszedőeszközt egy közönséges raktári tárolóhelynek tekintik. A modell működőképes, bár valójában a kiszedőkocsi nem egy tárhely, hanem egy logisztikai eszköz, amelynek van tárhely tulajdonsága is.
4. megoldás
A raktárban és a kiszedőkocsin Fixen rögzített vonalkódokat használnak. A kiszedésazonosítás finomprogram, eszköz és munkahely szintű.
Ez egy legfejlettebb megoldás. Az eszköz képernyőjén megjelenik az is, hogy a kiszedett cikk melyik munkahelyhez tartozik. A kiszedőkocsi úgy járja végig a raktárat, hogy csak egy munkahely anyagait tartalmazza. Minden kocsin van egy tároló elem, ahova be lehet tenni a munkahely azonosítóját, ami egy táblácska. Ha a kocsin van munkahely azonosító, akkor a kocsi elosztási pont nélkül azonnal kikerülhet a munkahelyek gyártási sorába. Az azonosító tábla akár el is hagyható, mert a programnak van egy olyan szolgáltatása, hogy ha a kocsi kiszedése lezárult, akkor a vonalkódra kattintva leolvasható, hogy melyik munkahelyhez tartozik.
Amikor befejeződik egy munkahely anyagainak kiszedése, akkor egy figyelmeztető üzenet jelenik meg, amelyre új kocsit kell bevonni a következő munkahely anyagjaihoz.
Ha a kocsira konténereket helyezünk, akkor nem keverednek össze az alkatrészek. Az alkatrészeket csak a munkahelyeken kell ismerni.
A megoldáshoz konkrét gépelrendezés és gyártási rend tartozik.
Bár első pillanatban bonyolultnak tűnik a kiszedés, de mindössze arról van szó, hogy a gyűjtőponton folyó munkát áthelyeztük a raktárba. Tehát többletmunkát nem jelent csak a feladat elosztása változott. Annyiban mégis változik a kiszedési rendszer, hogy munkahelyenként kell végig járni a raktárat, de ez sem okoz többletmunkát, ha jól vannak a szabályok és a szekciók kialakítva.
Az elosztópont munkája azonban lényegesen egyszerűbb (gyakorlatilag megszűnt), ugyanis a kocsit egyszerűen csak át kell tolni a megadott munkahelyhez. Ilyenkor a munkahelyen dolgozó feladata a cikkek felismerése, mert a program összes batch-ének az anyagát tartalmazza az anyagkocsi. Ha a munkatársak felkészültsége alacsony, akkor szükség lehet arra, hogy az elosztási ponton a munkahely anyagát batchekre bontsák. Ez egy módosított verziót eredményez.
A megoldás akkor használható jól, ha a raktár a csarnokon belül van és a raktár előtt kialakítható egy tárolási pont. A raktáros egyszerűen elhelyezi a kocsikat a tárolási ponton és az operatív munkát végző munkatárs egy mozgó, közös vonalkódolvasó vagy a munkahely tábla segítségével kiválasztja, majd a munkahelyhez viszi a szükséges anyagokat és alkatrészeket.
A megoldás gyengesége, hogy ilyenkor munkatársak bóklásznak a csarnokba, ami fegyelmezetlenséget szül.
5. megoldás
A raktárban és a kiszedőkocsin Fixen rögzített EAN13-as vonalkódokat használnak. A kiszedésazonosítás finomprogram, eszköz és batch szintű.
Megegyezik a 4-es megoldással, de a képernyőn a Batch azonosító az elsődleges, azaz a batch szerint rendezve történik a kiszedés és az optimális bejárás csak a batcheken belül érvényesül.
Ez lehetővé teszi, hogy a batch váltásnál kiszedőeszközt is válthassunk, így minden termék összes anyaga önálló kiszedőeszközbe kerül. A batch váltásra figyelmeztetést küld a program.
Ebben a megoldásban egy kocsin egy termék anyagai vannak, de nem feltétlen mindig legyártható állapotban. Ez azt jelenti, hogy ha egy cikk már nem fér rá a kocsira, akkor a további cikkek már a következő kocsin találhatók. Tehát előfordulhat, hogy a gyárthatósághoz több kocsi is kell. Megtehetjük azt, hogy a kiszedőkocsira konténereket teszünk és minden cikket más konténerbe helyezünk. Ez viszont csak akkor működik jól, ha termék kevés alkatrészt tartalmaz.
Ez a megoldás használandó akkor is, ha a kittképzést az elosztási ponton végezzük.
Ha egy munkahelyen sok műveletet végeznek (pl.: óraszerelés, műszer szerelés), akkor kitteket kell képezni, Egy kitt a termék összes alkatrészét tartalmazza. Ha több munkahely van, akkor a kitetteket munkahelyenként kell összeállítani. A kitteken az alkatrészeket a felhasználás sorrendjében kell elhelyezni és célszerű a tárolóeszközön (amely ilyenkor általában egy tálca vagy speciális konténer.
6. megoldás
A raktárban a tárhelyazonosítás EAN13-as vonalkóddal és tárhelyazonosítóval történik; A konténereken EAN13 vonalkód és konténerazonosító van; A kocsin EAN-13-as vonalkód és kocsiazonosító van; A kiszedés munkahelyenként történik; A kiszedésazonosítás finomprogram, eszköz és munkahely szintű.
Ez az egyik legfejlettebb megoldás. Ha a kocsin van munkahely azonosító, akkor a kocsi elosztási pont nélkül azonnal kikerülhet a munkahelyek gyártási sorába. Az alkatrészeket egyáltalán nem kell ismerni, mert minden konténer azonosítva van és minden konténerben csak ugyanolyan alkatrész van. Ha egy már feltöltött konténerbe egy másik cikket akarunk betenni, akkor a rendszer hibát üzen. (Egy rendszerparaméter azt is lehetővé teszi, hogy egy konténer többféle alkatrészt is tartalmazzon)
A megoldáshoz konkrét gépelrendezés és gyártási rend tartozik.
Ebben a valós és tipikus elrendezésben a csarnokokban van műveleti-kocsi és anyagkocsi. Általában ezeket használjuk kiszedőkocsiként is, amit a gyűjtőpontba szállítanak át. A műveleti-kocsi szállítja a munkadarabokat a munkahelyek között, az anyagkocsi meg a munkahely anyag és alkatrészszükségletét biztosítja. A termelésvezérlés feladata, hogy a műveleti-kocsi és az anyagkocsi a megfelelő helyen és megfelelő időben találkozzanak. A nagy vagy nehéz termékek esetén (pl. kazánok, kandallók) a műveleti-kocsit targoncával mozgatott raklapok helyettesítik, de egy szalag, a konvejor is lényegében egy speciális műveleti-kocsi. Logikailag nincs is különbség köztük.
Jelen esetben a kiszedőkocsik egyben anyagkocsik is, ugyanis nincs szükség a kiszedett cikkek áthelyezésére az anyagkocsikra.
A kiszedőkocsi (anyagkocsi) fixen elhelyezett vonalkód azonosítással rendelkezik. Azonosítja magát az eszközt, továbbá a programot és a munkahelyet. A kocsi azonosítás azért fontos, mert ha nagyon sok anyagkocsi van a gyártótérben, akkor először a kocsit kell megkeresni, aztán azon belül a konténert.
A kocsin elhelyezhető egy fix sorszám is, amelyet szintén az eszközadatok között tárolunk. Ez azért jó, mert használatával elkerülhető a vonalkódolvasó beruházása a munkahelyeken. A kocsi azonosítása történhet a vonalkódra pittyentve, a vonalkód be is írható és ki is választható. Ekkor automatikusan megjelenik a kocsiazonosító szám is. A kocsi azonosítható a szám beírásával vagy kiválasztásával. Ekkor a vonalkód lesz felülírva. A kocsi vonalkódjának és a kocsiazonosítónak léteznie kel az Eszközadatok között.
A kocsikra konténereket helyeznek. A konténereken található egy Fixen felhelyezett vonalkód és egy (konténerazonosító) sorszám. A két azonosító egyenértékű. A vonalkódokat és a sorszámokat az Eszköz adatbázis tartalmazza. Kezelésük egyezik a kocsiazonosítóéval.
Ha a cikk adatbázisban megtalálható a cikkhez tartozó alapértelmezett kiszedő konténer típusa és az az információ, hogy a cikkből mennyi fér el a konténeren, akkor a kiszedés indításakor már tudjuk, hogy hány és milyen konténert kell a kocsira helyezni. Ez a „Konténer szükséglet” parancsgombbal kérhető ki.
Érdekes módon – bár sok rendszer tartalmaz hasonló megoldást – ezek az adatok általában nincsenek feltöltve. Valamilyen ellenérdekeltség gyanítható e mögött, a munkatársak nem érdekeltek a hatékonyság növelésében.
Megadva a finomprogramot és a raktárat megjelenik a kiszedőlista első tétele. Mind a megadott raktárnak, mind a megadott finomprogramnak léteznie kell. Különben hibaüzenetet kapunk.
Induláskor fogunk egy kiszedőkocsit és rápittyentünk a fix vonalkódjára, ezzel jelezzük, hogy a következő tételeket ebbe a kocsiba tesszük. A pittyentés helyett kiválaszthatjuk és be is írhatjuk a vonalkódot vagy a kocsiazonosítót. Mindegyikhez cselekvés azaz felelősségvállalás tartozik.
Ha munkahely jelet is használni akarunk, akkor a kialakított hordozóra feltesszük a munkahelyjel táblát. A szükséges tábla jele leolvasható a képernyőről.
Felkeressük a listán megjelent első cikket. Az állványzaton rákattintunk a cikk vonalkódjára, majd arra konténerre, amibe helyezni fogjuk. A konténer típusa a képernyőn látszik. Ha a megadott vonalkódon nem a technológiában megadott termék található, akkor hibaüzenetet kapunk és nem lehet továbbmenni. Akkor is hibaüzenetet kapunk, ha a cikk egyezik ugyan, de nem arról a tárhelyről vette ki a munkatárs, ami elő van írva.
Ezzel azonosítottuk, hogy melyik munkahely cikkei, melyik kocsin, melyik konténerekben találhatók. Azonosítja továbbá a programot és a terméket (batchet) is.
Ha egy konténer megtelt de van még kiszedendő cikk, akkor a Módosítás ágban megadjuk hány cikket tudtunk elhelyezni, majd vesszük a következő tételt (ekkor megjelenik a hiányzó mennyiség tétele amire a következő üres konténerre pittyentünk és oda tesszük a további cikkeket. Ez tetszőleges sokszor ismételhető, mindaddig míg ki nem szedtük az utolsó tételt is. Ha nincs több cikk a munkahelyhez, akkor veszünk egy új kocsit lepittyentjük a kocsiazonosítót, kitesszük a munkahely jelet és folytatjuk a kiszedést. Ha minden konténerben van már valami, akkor veszünk egy új kocsit, lepittyentjük a kocsiazonosítót, kitesszük a munkahely jelet és folytatjuk a kiszedést.
Kiszedést követően a kocsik egy raktári gyűjtési pontban várakoznak a termelésvezető vagy a gyártási logisztikus beszállítási hívásra. A gyűjtési pontban azonban több program anyaga is várakozhat. Ha megtörtént a kiszedés és ismételten kiválasztjuk ugyanazt a raktárat és finomprogramot, akkor egy üres képernyő jeleni meg, hiszen nincs mit kiszedni. Azonban, ha a kocsi vonalkódot kiválasztjuk a legördülő listából (vagy pittyentünk egy kocsi vonalkódjára), az adatok akkor is megjelennek, így itt is elkerülhető a vonalkód használata. Természetesen az adatok nem módosíthatók.
Az operatív munkahely elszámolóterminálján megadva a műveleti kocsi számát a megjelenő BOM lista elején látjuk, hogy a szükséges alkatrészek milyen számú konténerben találhatók. Tehát itt sem kell vonalkódolvasó.
A megoldást „Vonalkód alapúnak” mondjuk annak ellenére, hogy ténylegesen csak a raktárban kell vonalkódolvasó, aminek az-az oka, hogy valójában hatékonyabban és biztonságosabban működik vonalkód olvasóval.
A kevésbé korszerű gyártásoknál mindig felmerül az a kérdés, hogy érdemes-e beruházni egy ilyen bonyolult rendszerbe. Természetesen, addig amíg a piac mindent felvesz és igénytelen és mindig van olcsó munkaerő, addig nem.
Ha ezek bármelyike megváltozik, akkor ez a beruházás nagyon gyorsan térül meg. Ekkor kell újraszervezni a gyártást és a Tanulmányrendszer segítségével megmutatni, hogy ezek a megoldások valójában sokkal egyszerűbbek, sokkal gyorsabbak és hatékonyabbak, mint a jelenlegi megoldás csak fel kell oldani a változás okozta stresszet. Sőt, még arra is érdemes költséget és időt fordítani, hogy a buzerálás helyett professzionális, a gyártáshoz és a termékhez pontosan illeszkedő speciális kocsikat gyártassunk le, amely megkíméli a munkatársakat az emeléstől és a kocsik, konténerek mozgatástól.
A gépek mindig olcsóbbak, mint az ember.
7. megoldás
A gyártás csomagokban folyik; A raktárban a tárhelyazonosítás EAN13-as vonalkóddal és tárhelyazonosítóval történik. A kocsin és a konténereken EAN13 vonalkód és numerikus azonosítókkal van ellátva. Adagkezelés nincs; A kiszedés munkahelyenként történik; A kiszedésazonosítás finomprogram, eszköz és munkahely szintű.
Az előző megoldásokban az anyagkocsiban a batch összes anyaga került elhelyezésre. A gyártás azonban sokszor szakaszokra van bontva, azaz nem a teljes batchet gyártják le egy fogásban, hanem kisebb csomagokban folyik a gyártás. Ha egy műveleti kocsin pl. 8 termék fél el, és kocsiban elférnek az alkatrészek is, akkor egy 40 darabos gyártási megrendelés esetén öt műveleti kocsi lesz megtöltve. Ha a kiszedőkocsit (ami egyben a műveleti kocsi is) ténylegesen megtölti a 8 termék anyaga, akkor így is – úgy is ötször kell végig járni a szedési útvonalat, tehát semmilyen többletmunkát nem jelent a megoldás.
Amikor egy finomprogramban található batch nem folyamatosan termékenként, hanem gyártási csomagokban gyártható, akkor jobb megoldás eleve a gyártási csomagnak megfelelő egységben kiszedni a cikkeket, mint osztályozni. Ha a gyűjtőponton töltjük fel a műveleti kocsikat, akkor ismerni kell a cikkeket, ismételten kézbe kell venni minden darabot, ami csökkenti a hatékonyságot és növeli a tévedés valószínűségét, ha ugyanezt a raktárban csináljuk, akkor cégszinten semmilyen többletmunkával nem jár a kiszedés.
A megoldáshoz szükséges csomagnagyság egy termékadat, amely a technológia fejadatai között található.
A 6. megoldáshoz képest eltérés csak a kiszedési jegyzékben van.
A megoldáshoz több konkrét gépelrendezés és gyártási rend is tartozik.
Ezek mind ugyanannak rendszernek a módosulatai.
Kittképzés
Kittképzésről akkor beszélünk, ha adott anyagokat és alkatrészeket egy csomagba gyűjtünk össze. Ez történhet a raktárban, egy elosztási ponton vagy egy gyártóhelyen. A kittképzés egy speciális kiszedés-komissiózás-bevétel típusú háromlépéses kiszedés ami lényegében egy raktárba kihelyezett művelet, amelyhez tartozik műveleti idő, anyagok, segédanyagok és önálló szoftver funkció kezeli.
A kittek rendelkezhetnek cikkszámmal és az alkatrészraktárban készletre kell venni.
Kittek keletkezhetnek gyártási szálként is, ekkor indításuk a a többi szál indításával egyszerre történik és L3-as tárhelyen tároljuk.
999. megoldás
Számos egyéb kiszedési eljárásra is szükség lehet, ami igényelheti a rendszerparaméterek módosítását is. Ezek mindig önálló eljárásként jelennek meg, így más cégek speciális eljárásait nem érintik.
A legtöbb speciális eset a fentiek módosított megvalósításai.
Mindig a rendszerparaméterek határozzák meg, hogy melyik kiszedési megoldás töltődik be.
Az ilyen stratégiájú rendszerek eleve a nagymértékű testreszabásra készül.
Szín-vezérelt kiszedés
A 6-os és 7-es megoldás hatékonysága tovább növelhető, ha jobban összehangoljuk és egyszerűbbé tesszük a műveleti-kocsik és az anyagok találkozását.
Ezekben a megoldásokban a műveleti-kocsi és a konténerek is vonalkóddal és numerikus azonosítóval vannak ellátva. Így a vonalkód infrastruktúra nem nélkülözhető, bár lehet a numerikus kódokat is használni, de ez szintén munkatársi aktivitást igényel és a hibalehetőség is benne van a folyamatban.
Az a cél, hogy olyan eljárás működjék, amely nem igényli sem a vonalkód olvasók használatát (sem az azonosító kódok begépelését), így is gyorsabb és mégis biztonságosabb.
Erre való a szín-vezérelt gyártás.
Ekkor a műveleti-kocsit az első munkahelynél ellátjuk egy rendszer által meghatározott színjelzéssel és a raktárban is minden konténer kap egy színjelzést. A munkahelyeken csak annyi a feladat, hogy megnézik a kocsi színjelzését és beépítik azokat az alkatrészeket, amelyiknek a konténerén találunk ugyanolyan színjelzést.
Valójában tetszőlegesen sok szín használható, miután a színeket (az árnyalatok használata helyett) egy sorszámmal is el lehet látni. Akkor megfelelő a színek száma, ha a csarnokban egy időben, egy szín csak egyszer fordul elő.
A szín-vezérelt gyártás különösen hatékony, ha egy vezértermék variációjának a száma nagy, mert ilyenkor sok egymáshoz nagyon hasomló alkatész van egyidejűleg jelen gyártótérben. Tipikusan ilyen a konstrukciós gyártás, ahol a vevő kattogja ki a késztermék paramétereit.
A feladatra két alapmegoldás van.
1. A konténereket csak színnel azonosítjuk.
(A raktárban a tárhelyazonosítás EAN13-as vonalkóddal és tárhelyazonosítóval történik; A kiszedésazonosítás finomprogram és munkahely szintű; A konténereket csak színnel azonosítjuk; Összesített kiszedés folyik.)
Ez az egyszerűbb megoldás. Ilyenkor a kiszedőkocsit ( ami egyben műveleti-kocsit és anyagkocsi is) és a konténert is csak színnel azonosítjuk.
A kiszedés megkezdése előtt az „Konténer szükséglet” parancsgombbal kikérhetünk egy listát, amely megmutatja, hogy milyen színjelzésű konténereket kell összeállítani és a kiszedőkocsira tenni. A lista előírja a kiszedés sorrendjét is, azaz a kiszedés abban a sorrendben történik, amely a listán szerepel, azaz a megfelelő konténer sorrendet is kialakíthatjuk. A jelzések kihelyezését megteheti a raktáros az induláskor, de a konkrét cikknél is elvégezhető. Egyénfüggő.
Ha a technikai cikkadatoknál meg van adva az alapértelmezett kiszedő konténer és a cikk tárolási térfogata, akkor a rendszer meghatározza, hogy hány, milyen fajta és milyen színjelzésű konténerre lesz szükség.
Fél és harmad konténer is elegendő lehet
Lista formában megkaphatjuk azt is, hogy a program kiszedése milyen színjelzésből mennyit igényel. Ezeket a munkatárs viszi magával, ha ezt a módszert választotta.
Raktárankénti színjelző szükséglet
A program a kiszedést alapértelmezésben úgy irányítja, hogy minden munkahely anyaga önálló kocsiba kerüljön és minden alkatrész önálló konténerben legyen. Ez felülbírálható, de csak akkor lehet több cikket egy konténerbe tenni, ha ugyanazon a programhoz, batch-hez és munkahelyhez tartoznak. Egyébként hibát üzen.
Célszerű a munkahely jelét elhelyezni a kocsin lévő tárolóelembe, ugyanis így ránézésre is meghatározó melyik munkahely gyártási sorába kell a kocsit kihelyezni. Ha nem tesszük ki a munkahely jelet, akkor ismerni kell a cikkeket, különben a színkombinációból kellene megállapítani a munkahelyet.
Abban az esetben, ha a cikket jól kezelhető dobozba szállították, akkor a dobozra felesleges színjelzést tenni (bár lehet), hanem a képernyőn található színkombinációt kell felírni. A színezés és a színkombináció egyenértékű azonosító. A munkahely elszámolóterminálján a cikkek mellett a színkombináció is látható.
Alapértelmezésben ez a megoldás minden cikket automatikusan külön konténerbe irányít, így semmilyen cikkismeret nem szükséges a gyártásnál, viszont a szükséges konténerek száma nagy lehet.
A program és a raktár megadása után megjelenik az első kiszedendő termék kiszedési adatai. Megjelenik az is, hogy összesen hányat igényel ebből a program. Ezt betesszük a megadott típusú konténerbe (már ha fel van töltve a cikk technikai adatbázisa) és megjelenik, hogy milyen színkódot kell kitenni a konténerre. A színek vesszővel elválasztva vannak felsorolva.
Ha a konténer megtelik, akkor belépve a Módosítás ágba meg kell adni, hogy hány cikket sikerült kiszedni és a maradékot egy másik konténerbe kell tenni. Az újonnan bevont konténerekre is ki kell tenni az előírt színjelzést.
A „Következő” parancsgomb hatására megjelenik egy másik cikk, ehhez ismét meg kell adni majd a konténert, de a kocsit csak akkor ha megtelt.
Ha a munkahely összes alkatrészét kiszedtük, akkor egy új kocsit kell bevonni és folytatni kell a kiszedést a következő munkahellyel.
A kiszedés végeztével minden konténeren legalább egy színjelzés található és minden kiszedőkocsin található egy munkahely jelzés is.
A megoldás kismértékben növeli a raktári feladatokat viszont megszünteti a gyártáslogisztikai munkaköröket és a hibákat valamint jelentősen növelheti a hatékonyságot.
A megoldás könnyen módosítható a csoportos gyártás igényei szerint és választható a batch szerinti kiszedés is. Ezek új módosított verziók lesznek.
2. A konténereket színnel és vonalkóddal is azonosítjuk.
(A raktárban a tárhelyazonosítás, a kocsiazonosítás és a konténerazonosítás EAN13-as vonalkóddal és skalárazonosítókkal történik; A kiszedésazonosítási program, kocsi, konténer szintű; Batchenkénti kiszedés folyik.)
A megoldás szemben az előzővel teljes-körű nyilvántartást biztosít. Sok kiszedőkocsi esetén azonosítja, hogy a kocsi melyik finomprogramhoz, batch-hez és munkahelyhez tartozik, ami akkor előnyös, ha túl sok kocsi van az elosztási ponton mert pl. helyhiány miatt nincs mód az anyagok, alkatrészek kihelyezésére. A konténer azonosítása teljes, pontosan megadja, hogy a konténer milyen cikkeket tartalmaz.
A pontosság több esetben is számít:
– műveleti-kocsinként meg lehet mondani, hogy melyik műveletet ki végezte,
– az alkatrészek neve is beazonosítható,
– meg lehet mondani, hogy a félreállított kocsi milyen állapotban van,
– bármikor vissza lehet térni a 6.2-es modulra.
Az azonosításkor használható a kocsi és konténerazonosító, így nincs feltétlen szükség a vonalkód infrastruktúrára.
Használni ugyanúgy kell ahogyan az előzőt: ha egy konténeren ugyanaz a szín is van, mint a műveleti-kocsin, akkor az az alkatrész a műveleti-kocsihoz tartozik.
A kocsi és/vagy konténer vonalkód a gyártás adottságainak függvényében el is hagyható. A rendszer akkor is működik, ha csak a színjelzést használják és akkor is működik, ha nem használjuk a színjelzést. A vonalkód helyett használható a numerikus azonosító is.
A folyamat úgy indul, hogy le kell/lehet olvasni a kiszedőkocsi vonalkódját. A vonalkód használata nem kötelező, de ha megadják, akkor ellenőrzi, hogy tényleg kiszedőkocsit azonosít-e. Ezt követően felkeresve az első cikket pittyentünk a tárhely vonalkódjára, kiszedjük a cikket, pittyentünk arra a konténerre, amelybe betettük és kihelyezzük azt a színt, amelyet előír a rendszer. A megoldás batchenkénti kiszedést tartalmaz, ezért nem kell a kiszedés előtt kihelyezni a színeket. Új cikk tehető már feltöltött konténerbe, ha a program, a munkahely és a batch egyezik és a rendszerparaméter ezt engedélyezi. Ha a művelet sikeres volt, akkor – a beállított útvonaltípusnak megfelelően – lépünk következő tárhelyre. Ez lehet ugyanolyan cikk, de lehet más cikk is. Előfordulhat, hogy ugyanaz a cikk a raktár más helyén található (káosz raktár). Ekkor a cikket tehetjük a már részben feltöltött konténerbe, de nyithatunk új konténert is. Ilyenkor ismét ki kell tenni a színjelzést. Ha a konténer megtelt akkor belépünk a módosítás ágba, megadjuk mennyit sikerült elhelyezni a konténerben és fogunk egy új konténert, leolvassuk a kódját és elhelyezzük a színeket.
Ha tárhelyen nem volt elegendő cikk, akkor belépünk a módosítás ágba, megadjuk, hogy mennyit sikerült kiszedni majd rendbe hozzuk a nyilvántartást. Ezt követően kiszedhető a maradék cikk is. A rendbehozatal nélkül a rendszer nem engedi a kiszedés folytatását. Ha nincs triviális megoldás, akkor fel kell függeszteni az adott batch kiszedését, legyárthatatlan összeállítás nem hagyhatja el a raktárat. A termelésvezető saját hatáskörében oldja meg a problémát (engedélyezheti a tovább haladást, intézkedik a selejt javításról, törli a batchet stb.)
Egy új tétel esetén a kocsi azonosító változatlan, mindaddig, míg nem vonnak be egy új kocsit és nem olvassák le annak a vonalkódját. A konténerazonosító mező minden váltás után üres.
A termelésvezető engedélyezi a több cikk egy konténer módot.
A Batchenként kiszedés azt jelenti, hogy a kiszedik a batch által előírt cikkmennyiséget, majd kiteszi a konténerre a batch színét, ami szintén a képernyő található. Ezt követően a „Következő” parancsra megjelenik egy másik batch igénye ugyanarra a cikkre. Ki kell szedni és kihelyezni a batch színét. Ezt addig kel folytatni, míg elfogynak az igények. A konténeren sok szín lehet, de ezeket most nem egyszerre, hanem batchenként helyeztük ki.
Sem a kocsira sem a konténere nem kell pittyenteni, mert az a képernyőn már ki van töltve, csak a cikk váltásnál kell megadni új konténerazonosítót.. Persze ha másik konténerbe akarjuk tenni, akkor az is megtehető. Ekkor a kocsin kevesebb konténer lesz.
Ebben a megoldásban a képernyőn mindig csak egy szín látható, így kisebb a hibalehetőség.
A szín-vezérlés jellege miatt a gyűjtőponton nem kell osztályozni és rendezni a kocsikat, hanem rögtön kihelyezhetők a konténerek a gyártóponthoz.
Mindig vannak olyan doboz kiszerelésű elemek, melyeket célszerű a gyári csomagolásukban kiszedni. Ezeket nem célszerű színekkel és vonalkódokkal ellátni, egyszerűen rá kell írni a dobozra a színkombináció kódját.
A színeket egy erre a célra kialakított tárolóban kell tartani.
A megoldás a sok adat miatt csak a nagy-képernyős adatgyűjtőkön valósítható meg.
___________________________________________________________________________________________
@Kupán Károly (2022) v.1.3 Kupán Károly