Írta: Sós András
2019. szeptember 27. 17:19:45 CEST
Abban a kivételes helyzetben vagyunk, hogy mi már vezettünk be MES rendszert, méghozzá nem egyet, nem kettőt. Így, amikor megkeresést kapunk, általában már előre tudjuk, hogy mennyi ideig fog tartani, mennyire tudjuk tartani a költségvetést és összességében mennyire lesz sikeres a projekt. Mivel a piac soha nem látott MES bevezetési lázban ég, úgy gondoltuk, sokaknak hasznos lehet, ha írunk egy összefoglalót a tapasztalatainkról.
A fenti cikket több mint 15 éve publikáltuk. Érdekes, hogy a termék nevén és a külcsínen kívül alig változott valami. Azóta is ipari szabványokat követve, dobozos, konfigurálható szoftverek segítségével, saját program részletekkel építjük a rendszereinket. A sláger ma is az állásidő és a folyamat képesség, de azóta bővültek az igények a raktár készlet követéstől, a termelés ütemezésen át, az automatikus ERP lekérdezésig és feljelentésig minden irányban.
Mi a MES?
A vállalatirányítási rendszerben létrehozott megrendelés és a számlázás között van egy fontos feladat: a gyártás. Ezt a gyártás végrehajtói végzik el: a mérnökség megtervezi a gyártást, a művezető ütemezi, kiosztja és ellenőrzi a feladatokat, az operátorok pedig elvégeztetik a munkát a gépekkel vagy elvégzik ők maguk. Végül lejelentik darabszámokat a művezetőnek, aki tovább jelenti a vállalatirányítási rendszer felé.
Valódi MES-ről akkor beszélünk, amikor az előbbi feladatokat legalább részben átveszi az informatika, hiszen a MES jelentése Manufacturing Execution System, gyártás végrehajtási rendszer.
Nem vagyunk persze szőrös szívűek, nálunk az is MES, ha a végrehajtás az emberek kezében van, de digitálisan lekövetik a folyamatnak legalább egy részét.
Sőt, szoktunk egy kompetencia mátrixot vagy akár egy hatékonyság monitorozó alkalmazást is MES-nek hívni, hiszen sokszor egy-egy ilyen projektből növi ki magát az idő során valódi MES. És hát érdemes is ezeket a szoftvereket úgy megtervezni, hogy ne álljon a fejlődés útjába.
Az általunk készített MES rendszer sematikus ábráját láthatod felül. Kapcsolódunk a gépekhez (bal alul), az ERP-hez (felül), és természetesen kommunikálunk az operátorokkal (jobb alul). Minden adat a központi MES motorba kerül. A MES motornak a különböző moduljai mind egy közös forrásból kapják az adatokat, és minden valós időben történik, tehát nincsenek sorba állított feladatok. Van olyan rendszer is, ahol a különböző modulok valójában külön adatbázist használnak, így az adatokat folyamatosan szinkronban kell tartani. Ez később problémákhoz, ütközéshez vezethet. Másik probléma forrása lehet, ha nem valós idejű a motor, hanem várólistát alkalmaz. Ebben az esetben percek is eltelhetnek, amíg egy művelet elvégzésre kerül, ami egyben azt is jelenti, hogy a következő, ettől függő művelettel várni kell. Az ilyen apróságnak tűnő részletek is megbuktathatnak egy projektet.
Miért létszükséglet a MES bevezetése?
Különböző aspektusait különféle neveken illetik, hívhatják ipar 4.0-nak, IIoT-nak, vagy digitális ikernek, valójában mind arról szól, hogy a digitalizáció soha nem látott mértékben fogja megreformálni minden iparág életét. Jellegében olyan váltás előtt állunk, mint amikor a lovaskocsiról áttértünk a gépesített teherszállításra: a vasútra és a teherautókra. Akkor is, most is alapjaiban gondoljuk át a folyamatainkat. A lovaskocsik korában egy tervezőnek eszébe sem juthatott 40 tonnás elemekben gondolkozni, amikor hidat tervezett, hiszen ekkora tömeget a korábbi technológiával nem lehetett odaszállítani az építkezés helyszínére. (Még a mindössze 2 tonnás elemekből készített piramisok építését is rejtély övezi.)
Ma már érződik, hogy a 100 éve fix üzleti modellek alapján működő iparágakat kell alapjaiban átgondolni. Egyre kevesebben akarnak például saját autót használni, inkább megoldják hosszabb-rövidebb távú kölcsönzéssel, ráadásul nem mindig autót, néha robogót, biciklit, rollert kölcsönöznek, mikor melyik az ésszerűbb. Több autógyár már kísérletezik ezért azzal, hogy a hagyományos eladás és szervizelés helyett a bérbeadásból szerezze meg a kieső jövedelmét. Erre még rátesz egy lapáttal, hogy sokan már úgy várják (várjuk) az önvezető autókat, mint a messiást, hiszen akkor a bérlés már úgy fog kinézni, hogy el sem kell sétálni a legközelebbi bérautóig, hanem házhozjön, mint K.I.T.T.
Mind a rövid távú bérlést, mind az önvezető autókat az informatika fejlődése és elterjedtsége teszi lehetővé. Hasonló történik a gyártó iparban is, persze kevésbé nyilvánvaló módon. Mégis, az, aki teljes transzparenciát és teljes kontrollt tud gyakorolni a termelése fölött, annak olyan eszközkészlet kerül a kezébe, mint aki a fahíd helyett acélban kezdett gondolkozni. Aki viszont nem vált, az kulloghat lovaskocsin, vagy nosztalgiázhat egy kocsmában, elfelejtett lódoktorként.
Az átalakulás 3 hullámáról és annak elkerülhetetlenségéről itt tekinthetitek meg Orbán Krisztián kiváló előadását, nála jobban én sem tudnám elmondani.
Íme a tipikus dilemmák, és a lehetséges kiutak:
Erre a kérdésre viszonylag egyszerű a válasz.
Nemzetközi cég nem létezhet globálisan egységes vállalatirányítási rendszer nélkül. Ennek analógiájára sokan gondolják, hogy a MES-nek is mindenhol egységesnek kell lennie. Ezen a hiten túl a globális rendszernek több látszólagos előnye van.
Egyik, hogy a HQ nagyobb szakmaisággal tud dönteni. Abból indulnak ki, hogy felkészült, kompetens csapatot állítanak össze, akik együtt, minden szempontot figyelembe véve tudnak dönteni arról, melyik a nyerő szoftver. Ez persze csak a HQ-ban dolgozóknak tűnik előnynek, a telephelyi vezetők és mérnökök számára nem feltétlenül. A HQ-ban ugyanis a gyártás és a helyi kultúra részleteivel általában nincsenek tisztában (miért is lennének), ezért a döntésükben ezeket nem is vehetik figyelembe. Pedig, mint látni fogjuk, ezek kritikus jelentőségűek. Számtalan példát ismerünk erre az esetre, és mindig izzadtságos volt a bevezetés. Sokszor csak úgy tudtunk működőképes rendszert szállítani, ha a megvásárolt szoftver több elemét gyakorlatilag kihagytuk a megoldásból, és helyette újat írtunk. Mellesleg ez örömteli megoldás is volt egyben, hiszen a telephely kapott egy működőképes rendszert, a központ pedig megkapta azt az örömöt, hogy sikeresnek könyvelhették el a MES bevezetést :)
Másik előnye a központilag meghatározott rendszernek, hogy a központból minden telephelyet egységesen láthatnak, ezért a teljesítményüket könnyű összehasonlítani. Ez rendkívül fontos szempont. Sajnos azonban ez alapján dönteni a globálisan egységesen bevezetett rendszer mellett mégiscsak hibás. Miért? Akkor is lehet egységes képet kapni a telephelyekről, ha ott teljesen különböző MES motor fut. Ennek az az oka, hogy minden szóba jöhető MES rendszernek rendelkeznie kell API-val, tehát egységesen elérhető interfésszel. Ennek a segítségével azután egy központi szoftver egységes formában tudja összehasonlítani a telephelyek teljesítményét. Ez talán bonyolultnak hangzik, mégis sokkal egyszerűbb, mint egy gyártásra ráhúzni egy nem ráillő MES-t, és a dolgozókra erőltetni egy nekik nem tetsző munka stílust.
Azt már csak félve jegyzem meg, hogy néha igazságtalan a telephelyek összehasonlítása, hiszen ha még ugyanazt a terméket is gyártják Kelet-Európában, mint az angol telephelyen, Angliában a legújabb gyártósorok és teljes gyártói támogatás áll rendelkezésre, míg hozzánk az Angliában szanált 30 éves sorok kerültek, és nincs olyan mérnök, aki ismerné ezeket a 30 éves PLC-ket.
Ugyancsak előny, hogy a központilag beszerzett szoftver licencére nagy kedvezményt és komolyabb támogatást lehet kapni a szoftver szállítójától. Ez pedig megdobja a ROI-t, amely nagy súllyal szerepel a döntéshozatalban.
A probléma és az ördög viszont a részletekben rejlik, azokban a részletekben, amelyekkel nem tudnak számolni: a gyártás részleteivel és a helyi kultúrával. És bekövetkezik az elmaradhatatlan: nem tudják a helyi hardvereket és szoftvereket integrálni a MES-be, és a dolgozók torkán nem tudják lenyomni az új munkafolyamatokat. A pénz pedig csak ömlik és ömlik a bevezetésbe, telik az idő, és nincs eredmény.
Mi történik viszont, ha elengedjük a globálisan egységes MES rendszert, és rábízzuk a telephelyekre, hogy döntsék el, mit akarnak bevezetni? Mivel a döntést helyileg hozzák meg, azonnal involválódnak, sajátjuknak érzik. Olyan rendszert vásárolnak, amely a saját hardvereikkel és szoftvereikkel integrálható, és amelyhez kapnak az anyanyelvükön hozzáértő rendszerintegrátort és műszaki támogatást.
Bár előfordulhat, hogy a licenc többe kerül, mintha központilag szerezték volna meg, ez többszörösen visszajön azzal, hogy kevesebb saját erőforrást kell bevonni, kevesebb pótmunkát kell rendelni a beszállítóktól, és hamarabb vége a projektnek, ezért hamarabb elkezd pénzt termelni. Nem mellesleg mindez a dolgozók kisebb ellenállásával történik.
Nem szabad megfeledkezni azonban arról a szempontról, hogy a telephelyek teljesítményének összehasonlíthatónak kell lennie. Ezért aztán nem szabad bedobni a gyeplőt a lovak közé, meg kell követelni a telephelyektől, hogy az adatokat egységes formában, egységes tartalommal, egy egységes interfészen keresztül elérhetővé tegyék egymás és a központ felé.
Dobozos kontra egyedi megoldás
Erre a kérdésre már nem lehet egy általánosan érvényes választ adni. A feladattól függ, melyik út a nyerő.
Minden dobozos szoftvernek van egy specialitása, egy funkció, amelyre eredetileg kifejlesztették. Az egyik abban erős, hogy gépekből tud változatos módszerekkel automatikusan adatokat kinyerni, a másiknak az erőssége pont az, hogy a kézzel bevitt adatokhoz ad ergonómikus felületeket, a harmadikat nagyon gyorsan lehet letelepíteni, bár a funkcionalitása erősen korlátozott, a negyedik mindenre képes, de nagyon bonyolult és hosszadalmas a konfigurációja, az ötödik szintén teljeskörű, és a telepítése is gyors, viszont a PLC programokat kell hozzá igazítani. Mindemellett elérhetőek iparágra, például a gyógyszeriparra vagy a vegyiparra specializálódott megoldások is.
Mindegyiknek lehet létjogosultsága. Ha pl új gyárat építünk, akkor nem biztos, hogy nagy gond, hogy a PLC programokat a MES-hez kell igazítani. Ismerni kell tehát az elérhető szoftvereket és a feladatot, mert még az sem biztos, hogy az a megfelelő választás, ami elsőre úgy tűnik, tökéletesen passzol. Végigkísértük például -szerencsére csak távolról- egy gyógyszergyárban, ahogy évekig szenvednek egy kifejezetten gyógyszergyárakra szabott dobozos MES bevezetést… pár év után feladták.
A dobozos programoknak van egy óriási előnyük: a megrendelés pillanatában készen vannak (ha az eladó nem füllentett, bár sajnos erre is hallottunk már példát nem kisebb márkáról, mint a … na ezt inkább hagyjuk!)
Az egyedi rendszereknek feltétlen előnye, hogy pontosan azt fogja tudni, amire szükség van. Hátránya viszont, hogy nincs készen a megrendelés pillanatában. Igaz ugyan, hogy aki régóta van a pályán, annak rengeteg modul készen áll, még így is sokkal több idő, míg a teljes MES elkészül. Amint azonban látni fogjuk, ez a hátrány sokszor pont, hogy előnnyé válik.
Össze lehet rakni egy teljes rendszert is csak dobozos, konfigurálható szoftverek segítségével is. A fenti ábrán a GE automatizálás termékcsaládja látható. Moduljai lefedik a valós idejű adatgyűjtéstől (SCADA) a termék követésen keresztül (Plant Apps) a riportozásig (Portal RTIP) az összes szükséges területet.
A dobozos szoftverekkel kész jelentéseket is kapunk.
Az agilis módszertan
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. (Még a legjobban megtervezett építési projektek végén sem kerülhető el a pótmunka. Ne felejtsük viszont, hogy ezek általában hibák következményei, melyeket kifelejtettek, vagy roszul kiviteleztek, és nem abból adódnak, hogy nem is tudhatta senki, hogy arra az elemre szükség lett volna)
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.
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 ez 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.
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.
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űszak jelenté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 halálcsillagot építünk, akkor évekig fog tartani, mire beleszoknak, és addig folyamatosan mindent el fognak követni, hogy megbuktassák a rendszert.
Ha már itt tartunk...
Kiszemezgettünk néhányat a klasszikus buktatók közül, álljanak itt intésül.
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? Azzal teszünk jót, ha a legmenőbb szoftvert vásároljuk meg, amire a konkurens cégek dolgozói elismerően bólintanak, vagy ha egy olyan fejlesztő céggel csináltatjuk meg, akinek a fejlesztői napról napra ott vannak a gyárban, és haverkodnak a dolgozókkal?
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.
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.
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. A milliónyi közül egy példa, amikor elfelejtődik, hogy egy bizonyos terméket csomagolás után még néha elvisznek tesztelésre, majd visszacsomagolják, pontosabban visszacsomagolnák, ha a rendszer nem utasítaná vissza, hogy már el lett csomagolva. Az állomáson dolgozóknak természetes, de ha kimarad a specifikációból, akkor már vakarhatja a fejét a MES gazda, hogy hogyan teszi bele a MES-be ezt a szabályt.
Ilyen apróságnak tűnő feladatok előzetes ismerete már a megfelelő szoftver kiválasztásakor is létfontosságú lenne, hiszen lehet, hogy van olyan szoftver, ami az adott problémára egyáltalán nem nyújt megoldást.
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 fenti képen egy csomagolás regisztrációs folyamat 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.
Minden folyamat változik. Új termék típusok, új gépek, folyamat optimalizá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.
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.
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.
Egyetértesz a leírtakkal? Esetleg más a tapasztalatod? Szívesen várjuk a hozzászólásodat!
-----
A Com-Forth Kft. egy magyar tulajdonú ipari informatikai vállalat, mely 30 éve szállít adatgyűjtő rendszereket és 17 éve MES-t. Adtunk át különféle dobozos szoftverekkel készült megoldásokat valamint saját fejlesztésű rendszereket is.
A cikk megjelent a GyártásTrend oldalán.
