hirdetés
hirdetés

Gyártásvégrehajtás

A MES bevezetésének kérdései (2. rész)

Aki már vezett be MES-rendszert, nem is egyet, az tudja, hogy összességében mennyire lesz sikeres a bevezetés. Sós András, a Com-Forth fejlesztőmérnöke tudja és meg is írta tapasztalatait. Az első részben az alapdilemmákról esett szó, most a bevezetés lépéseiről és a költségigényekről számolunk be. 

hirdetés

A cikk első részében Sós András helyre tette, hogy mikortól beszélhetünk MES-rendszerről (Manufacturing Execution System – gyártásvégrehajtás-rendszer), a globálisan bevezetett, vagy a telephelyenként eltérő megoldás a jobb, illetve hogy dobozos vagy inkább saját megoldást érdemes választani. Az alábbiakban a bevezetés klasszikus buktatóiról, a megvalósítás optimális üteméről és a költségigényekről lesz szó. 

Bevezetés egyszerre vagy apránként 

Régebben megszokott volt, hogy a szoftvereket az épületekhez hasonlóan egyszerre tervezték meg, és egyhuzamban építették fel. A mérnökök már csak ilyenek, alaposan terveznek és pontosan kiviteleznek. Van azonban egy óriási különbség: épületeket tízezer éve építünk és használunk, szoftverekkel viszont csak pár tíz éve dolgozunk. Az épületeknél előre meg tudjuk adni, hogy mire és hogyan akarjuk használni, és azt is meg tudjuk jósolni, hogy milyen jövőbeni változtatásokra lehet szükség. A tervező, aki több ezer év tapasztalatát hordozza magában, ennek megfelelően tud is olyan épületet tervezni, amely a célnak megfelel. 

A szoftvereknél ez a tapasztalat meggyőződésem szerint nem áll rendelkezésre. A megrendelő nem tudja összeszedni az összes aktuális igényét, és csak halvány, többnyire téves sejtése van arról, hogy mit hozhat a jövő. A fejlesztő jobb helyzetben van, hiszen több rendszert leszállított már, ezért fel tudja hívni a megrendelő figyelmét néhány téves elképzelésre, de az összesre nem. Az olyan szoftverek, amelyeket ilyen monolitnak terveznek és a hagyományos vízesés modell szerint fejlesztenek, általában rövidesen a süllyesztőbe kerülnek, ha egyáltalán megérik az átadás napját.

A fentiek miatt ma már szinte mindenki az agilis módszertan szerint fejleszt szoftvert. Ez azt jelenti, hogy egy alapos felmérés után meghozunk egy döntést az architektúráról. Ami utána következik, az a legkisebb, önmagában is hasznos rész (kb. MVP – Minimal Viable Product) kiválasztása. A részletes tervezés már csak erre az MVP-re fog vonatkozni, és az átadás azonnal megtörténik, amint működőképes. Az MVP használatának a tapasztalatai alapján fogjuk a vevővel közösen eldönteni, hogy mi kerüljön a második ütembe. Ezt részletesen megtervezzük, kivitelezzük és átadjuk. És így tovább. Minden új fejlesztés és változtatás ilyen tyúklépésekben történik. Lényegi különbség, hogy az architektúrát, a rendszer felépítését már eleve úgy tervezzük meg, hogy az agilis fejlesztést lehetővé tegye, magyarul: könnyű legyen változtatni rajta.

Az agilis módszertant követők jellemzően rövid sprintekben gondolkoznak. Egy sprint tipikusan 2 hét. Egyszerre csak annyi feladattal foglalkoznak, ami 2 hét alatt megvalósítható. A mi gyakorlatunkban még rövidebb egység is lehet egy sprint, és mindig a feladathoz igazítjuk
Az agilis módszertant követők jellemzően rövid sprintekben gondolkoznak. Egy sprint tipikusan 2 hét. Egyszerre csak annyi feladattal foglalkoznak, ami 2 hét alatt megvalósítható. A mi gyakorlatunkban még rövidebb egység is lehet egy sprint, és mindig a feladathoz igazítjuk

Ez a dilemma visszavezethető a vízesés kontra agilis módszertan kérdésére (lásd a keretes írást). Érthető hát, hogy ritka kivétel, hogy javasoljuk az egyszerre történő bevezetést.

Mégis mik lehetnek a kivételek? Elsősorban a pályázatok. Aki pályázati pénzt akar költeni, annak akkor és azt kell vásárolnia, amikor és amire pénz van. Másik eset az új gyár építése, és az is csak akkor, ha van ráhatásunk az érkező gépek működésére, és a munkautasítások (SOP) kialakítására. Ekkor érdemes lehet az egész gyárat úgy indítani, hogy már eleve működik a MES.

Minden más esetben az agilis módszertant, és a kis lépésenkénti bevezetést ajánljuk. A MES bevezetése ugyanis egy tanulási folyamat, úgy a megrendelőnek, mint a szállítónak. Ahhoz, hogy a rendszerintegrátor megismerje a megrendelőt, a gyártástechnolóiát és magát a feladatot, és ahhoz, hogy a vevő saját maga megértse, mely információ releváns a MES specifikációjához, és megtanuljanak egy nyelvet beszélni, időre van szükség. Akár dobozos szoftvert kell felkonfigurálni, akár egyedi fejlesztésben gondolkodunk, sokkal jobb és végső soron gyorsabb eredményre jutunk, ha hagyunk időt magunknak és egymásnak erre a tanulási folyamatra.

Az agilis módszertan akkor válik különösen nélkülözhetetlenné, amikor átalakul a gyártási folyamat, és ezért hozzá kell igazítani a MES-t. Monolit szoftvernél számtalan helyzetben elhangozhat, hogy “ezt vagy azt nem lehet megcsinálni, mert nem tudja, és nem is fogja tudni a MES”. Erre az a megoldás szokott születni, hogy amit nem tud, azt MES-en kívül vezetik (Excelben, SAP-ban), a MES-ben pedig megpróbálják lekövetni valahogy. Az agilis módszertan szerint jól átgondolt és felépített rendszerben legfeljebb az hangzik el, hogy “jelen formájában nem tudja a MES, ezért át kell alakítani”, ami persze jelenthet több vagy kevesebb munkát, de szinte soha sem megoldhatatlan.

Az ipar 3.0 csinosítása

Amikor azt mondjuk, hogy apró lépésenként kell bevezetni egy ilyen mérvű módosítást, arra is gondolunk, hogy a dolgozókat egy időben minél kevesebb változásnak kell kitenni, hiszen mindenki utálja a változást. Ez érthető is. A változás kényelmetlenséget és eleinte még extra munkát is jelent.

Műszaknapló
Műszaknapló

A fenti műszaknapló tipikus példája volt az apró, fájdalommentes lépésekben történő bevezetésnek. Az első lépésben a meglévő Excelt kellett kiváltani, és kitölteni azokkal az adatokkal, amelyeket a gépekről gyűjtünk: melyik gépen, melyik dolgozó, melyik termékből, mennyit gyártott és abból hány volt a selejt. A művezető eleinte még átnézte az adatokat, majd kattintott egyet a jóváhagyás gombra. Ma már tudja, hogy a MES sokkal pontosabb adatokat szolgáltat, mint amit ő valaha, ezért a MES automatikusan menti a műszaknaplót. Ez a felület helyett inkább csak a műszakjelentéseket nézegetik.

Ha lehetséges, minél több olyan átmeneti lépést kell beiktatni, ami csak apró változtatást jelent a dolgozók munkájában. Például, ha eddig papíron vagy Word-ben kellett kitölteni a műszak átadás naplót, akkor lehet az első lépés, hogy a megszokott kinézettel, de már webes felületen lehessen megadni az adatokat, és csak a második az, hogy írisz azonosítással egybekötött gondolat vezérléssel kelljen kitölteni az adatbázis hiányzó rekordjait. Az első lépés után a művezetők már maguktól fogják kérni az újabb fejlesztést. Ha viszont rögtön minden egyszerre szeretnénk, akkor évekig fog tartani, mire beleszoknak a munkatársak és addig mindent el fognak követni, hogy megbuktassák a rendszert. 

Ha már itt tartunk...

Klasszikus buktatók

Kiszemezgettünk néhányat a klasszikus buktatók közül, álljanak itt intésül.

A vállalati kultúra

Minden cégnél egyedi kultúra alakult ki. Ha valaki nem a bevezetés módszerét alakítja a vállalati kultúrához, hanem a kultúrát próbálja megváltoztatni, az kudarcra van ítélve.

A probléma csak az, hogy a vállalati kultúrák homlok egyenest különböznek egymástól, ezért azt messziről nem lehet megmondani, hogy az a jó megoldás, ha bevonjuk a dolgozókat a tervezésbe, vagy ha kihagyjuk őket belőle. Az a nyerő, ha egy-két főkolompossal próbáltatjuk ki előre a rendszert, aki majd pletykaként szivárogtatja tovább az infókat, és győzi meg előre a kollégáit, hogy remek változások jönnek, vagy ezzel csak féltékenykedést érnénk el? Azzal érünk célt, ha a kinyert adatokat publikussá és akár a jutalmazási rendszer részévé tesszük, vagy azzal, ha az egész gyárat egy csapatként kezeljük? 

A lista a végtelenségig sorolható, és a megfelelő szoftver kiválasztásától a bevezetés ütemén és stílusán keresztül minden apró részletre hatással van. 

Érdekek és hatáskörök szétválása

Minden munka konfliktusokkal és kudarcokkal teli, ha valakinek nincs elég hatásköre arra, hogy végrehajtsa a feladatait. A MES bevezetésére ez halmozottan igaz, mivel rendkívül komplex, sok területet érintő rendszerről beszélünk, amely csak akkor áldás, ha minden részegységét gördülékenyen működtetik. Hiába van egy rendszerünk, ami megmondja, hogy az öregítőben melyik készülék mióta tesztelődik, ha a végszerelésen nem regisztrálják a munka elvégzését, ezért az öregítőben nem tudják a teszt indítást bevinni, mert a rendszer visszadobja, mint félkész terméket.

Az ehhez hasonló problémák általában abból erednek, hogy akinek érdeke lenne, hogy a terméket be lehessen olvasni az öregítőben, annak nincsen hatásköre, hogy ezt be is hajtsa az előző állomáson.

Ez a konfliktus pedig nem csak a MES működtetését, hanem már a bevezetését is el tudja lehetetleníteni. Számtalan olyan esettel találkoztunk, amikor a mérnök, akinek felelőssége volt pl. a selejt arányt csökkenteni, hiába erősködött, hogy a MES rendszer nyújt erre megoldást, és az árát is egy éven belül visszahozná. Miért volt hiába a kalimpálás? Azért mert a mérnökségnek nincs hatásköre arra, hogy a termelésre erőszakoljon egy rendszert. Még az is számtalanszor megesett, hogy a mérnökség saját költségvetésből megrendelt egy MES-alaprendszert, de sehogy nem tudták rávenni a termelést, hogy a rendszert használja is. Egy esetben rengeteg sikertelen kísérlet után a mérnökség vezetőjét a teljes üzem vezetőjévé léptették elő. Másnaptól mindenki használta a MES-t, mint a kisangyal.

Ez a probléma persze sokkal kisebb léptékben, minden részlet kidolgozásánál és bevezetésénél jelentkezik.

A saját folyamatok ismerete

Azt gondolnánk, egyértelmű, hogy olyanra kell bízni a MES kiválasztását és bevezetését, aki jól ismeri a folyamatokat, amiket digitalizálni, esetleg automatizálni akarunk. Mégis sokszor találkozunk azzal, hogy kritikus részletek hiányoznak a specifikációból. Ez sokszor már csak akkor derül ki, amikor bevezettük a rendszert.

Túlságosan megengedő rendszer

Az átlag dolgozó mindig a legegyszerűbb utat választja. Ha valamit nem kötelező bevinni, nem fogja. Ha egy selejtet nem kötelező lejelenteni, hanem egyszerűen visszarakhatja a gépbe, hátha másodszorra már átmegy, akkor lejelentés nélkül vissza fogja tenni, mi pedig azt fogjuk hinni, hogy kitűnő a FPY (First Pass Yield) mutatónk.

Sokszor kaptunk felkérést meglévő rendszer cseréjére. Ennek sokszor egyszerűen az volt az oka, hogy a vezetőség nem hitt az adatoknak, amit a MES-ből kinyert.

A MES-t ezért olyanra kell tervezni, hogy mindent kötelezővé tegyen, ami fontos. Apróságnak tűnik, de sok fejfájástól kímélhetjük meg magunkat, ha ezzel számolunk.

A csomagolás regisztrációs folyamata
A csomagolás regisztrációs folyamata

A fenti képen egy csomagolás regisztrációs folyamata látható. A PLC adja fel, hogy melyik sorozatszámú terméket kell lecsomagolni. Az operátor beolvassa a megfelelő sorozatszámot, és még egy beépülő alkatrész sorozatszámát. Ez után elvégez egy mérést, melynek az eredményét a program értékeli ki. Amíg az összes beolvasás és mérés nem stimmel, nem regisztrálható a csomagolás, csak selejtezni enged a rendszer. Ha a termék előéletével volt a baj, akkor a rendszer automatikusan selejtezi. Ha selejtet regisztrál, az állomás zárolódik, amíg az elkülönítőben (Q-Pont) az operátor be nem regisztrálja. Ezzel tudja bizonyítani, hogy a selejtes darab nem került lecsomagolásra. A rendszer nem megkerülhető, nem átverhető, és rengeteg olyan hibát fogott már meg, ami korábban DOA (Dead On Arrival – Kicsomagoláskor már hibás) terméket eredményezett volna.

A folyamatos karbantartás

Minden folyamat változik. Új terméktípusok, új gépek, folyamatoptimalizálások, költöztetés, audit miatti igények, és így tovább.

A költségvetés tervezésekor már azt is bele kell tervezni, hogy legyen pénz a bevezetett rendszer folyamatos igazítgatására / finomhangolására. Azoknál a gyártóknál, ahol a folyamatos karbantartás elmarad, rendszerint a MES egyre több funkcionalitása lesz használhatatlan, míg végül annyira elavulttá válik, hogy egyszerűbb és olcsóbb egy újat venni, mint találni valakit, aki a meglévő, 5-10 éves rendszert korszerűsíti. Még sokkal olcsóbb lett volna karbantartási szerződéssel folyamatosan kivitelezni a módosításokat. 

Belsőerőforrás-igény

Sokszor már az ajánlatadásig sem jutunk el, mert az is évekig tart, hogy az igényeket megkapjuk. Mi ilyen esetben sokszor inkább visszavonulót fújunk. Egy jó MES bevezetése nagyon időigényes a megrendelő részéről is. Erre erőforrást kell allokálni. Anélkül sajnos nem megy.

Ha egy szolgáltató azt ígéri, hogy a megrendelőnek semmi dolga nincs, csak kicsengeti a pénzt és élvezi a MES hasznát, azzal jobb, ha óvatosan bánunk.

Konklúzió

A MES-rendszer kiválasztása, megtervezése és bevezetése komplex, nehéz feladat. Ráadásul még a legkörültekintőbbek sem lehetnek száz százalékban biztosak benne, hogy az optimális megoldást választották. Mégis sokat tehetünk azért, hogy sikerre vigyük a projektet. Remélem, sikerült ehhez hozzájárulnom.

Sós András, Com-Forth
a szerző cikkei

hirdetés
Ha hozzá kíván szólni, jelentkezzen be!
 
hirdetés
hirdetés
hirdetés

Kiadónk társoldalai

hirdetés