Írta: Sós András
2022. szeptember 8. 16:21:30 CEST
Abban a szerencsés helyzetben vagyunk, hogy az elmúlt több mint 30 évben a legkülönbözőbb gyárak termelési folyamataiba nyertünk betekintést. Megszámlálhatatlan adatgyűjtési és termelésirányító szoftvert vezettünk be és fejlesztettünk tovább.
Érdekes, hogy ezeknek a rendszereknek az egyedfejlődése olyan, mintha mind ugyanazt a forgatókönyvet követte volna. Eltekintve néhány kivételtől. Lássuk hát, hogy mi a forgatókönyv, és kik voltak a kivételek! Barátságok és ismeretségek, csalódások és sikerélmények, illetve az adott időpillanatban rendelkezésre álló kompetenciák alakították a belső szoftverek hálózatát nagyon hasonló alakú – ahogy egy kedves partnerünk megfogalmazta – torzszülötté. Gyakran hallhatjuk az alábbiakat:
„Egy korábbi vezető beleszeretett az előző munkahelyén kialakított adatgyűjtő rendszerbe, ezért kiadta, hogy a gépeinkről gyűjtsünk adatokat. A mérnökség pendrive-okon gyűjtötte be a csv fájlokat, és heti Power Point prezentációkat készített az eredményekből. Volt egy ügyes kolléga, aki parádésan kezelte az Excelt. Írt egy makrót, ami távolról kiolvasta a gépekről a csv-ket, és eltárolta egy Access adatbázisba. Az új vezető kedvenc projektje a gyártmányt kísérő papírcetlik kiváltása volt, mert egy dolgozó napi 8 órában csak a cetlik adatait vitte be Excelbe (rengeteg hibával persze). Hozta is az előző munkahelyéről egy RFID-s termékkövető rendszerhez a beszállítót.”
És a többi, és a többi... A legtöbb cég, ahogy hánykolódik a digitalizáció óceánján, újabb és újabb szoftvereket és hardvereket szerez be vagy ír meg maga. A meglévő rendszereket pedig bővíti, ahogy tudja, amíg tudja. Előbb vagy utóbb mindenki eljut oda, hogy ezeknek a rendszereknek a funkcionalitása összeér. Fontos lenne, hogy az összes kommunikáljon egymással. Csakhogy eddigre már több tíz különböző rendszer van használatban, a legtöbbnek a fejlesztője nem ér rá, vagy már nem dolgozik a cégnél, vagy elmérgesedett a kapcsolata beszállítóval. Egy szó, mint száz, nem megoldható.
Hogyan lehet elszakadni ettől a hagyatéktól, és hogyan lehet olyan irányt venni, amely évtizedekig tartható?
Lássuk először is az okokat, amelyek a torzszülötteket eredményezik! Saját, belső informatikai fejlesztésnél rendszeresen visszatérő probléma, hogy kellő körültekintés nélkül kezdenek egy feladat megoldásához: van egy kolléga, aki azt mondja, meg tudja oldani az egyik égető problémát, mert ügyes Excelben és Accessben. A vezetőség szívesen tesz egy próbát, hiszen gyors és olcsó megoldás ígérkezik, ráadásul nagyon motiváló a dolgozónak. A kísérlet sikerül, hurrá! Az evés meghozza az étvágyat, egyre több fejlesztést kérnek bele; a rendszer nőttön-nő.
Mégis mi ezzel a probléma? Ma már nincsenek önmagukban álló programok, ezért programozni sem szabad rendszertervezés nélkül. Egy-egy szoftverre úgy kell gondolni, mint egy állandóan változó, növekvő, számos más rendszerrel szimbiózisban élő lényre. Ahhoz, hogy tényleg ilyen lehessen, - ahogy erről korábban írtunk is - tervezni kell! Már a szoftverembrió elkészítéséhez is a kész, kifejlett példányt kell megtervezni. Aki így tervez, biztos, hogy nem fog egy többfelhasználós, sok adatot tartalmazó rendszert Excelre vagy Accessre bízni.
A GE Plant Applications dobozos MES rendszer dashboardja
A másik visszatérő probléma a szoftverlény etetése. A gondozója az egyetlen, akitől elfogadja az ételt, ő viszont már egész nap csak eteti. A lény mégsem lakik jól. Nemcsak a lényt kell megtervezni, hanem a hozzá tartozó logisztikát, erőforrásokat és munkafolyamatokat is. Mi történik, ha a gondozó elmegy szabadságra, vagy az éjszakai műszakban kéne lenyugtatni a dühöngő fenevadat? Mit teszünk, amikor kijön az Access új verziója, és ha azon futtatják, a szoftverlény lába megsérül, a sebláztól pedig elkezd összevissza beszélni? Mikor éri el azt a méretet, amikor, ha megterhelik, nem lesz elég ereje teljesíteni?
Szinte mindenhol előfordul, hogy a fejlesztéseket barátoknak, ismerősöknek szervezik ki. Ha ez az ismerős egy egyszemélyes cég, akkor sajnos a tervezés sokszor ugyanúgy elmarad. Szerencsés és ritka kivétel, ha az ismerős éppenséggel jól ismeri a gyártási rendszereket, és tudja, hogyan kell őket megtervezni. De vannak, akik nem mentek be ebbe az utcába!
Jellemzően azok a multinacionális vállalatok tervezik meg és fejlesztik tudatosan gyártási rendszereiket (pl. MES), akik számára a központ bőven bocsátott rendelkezésre forrást már a kezdet kezdetén egy robusztus rendszer kiépítéséhez. Egyrészt megfelelő kompetenciával rendelkező mérnököket vettek fel, másrészt a rendszer bevezetésekor nem az árat vették figyelembe, hanem a TCO-t, a teljes élettartam alatti bekerülési költséget. Ennek köszönhetően átgondolt követelményrendszert állítottak fel, valamint olyan beszállítót választottak, amely évtizedekig ellátja a támogatást és a továbbfejlesztést.
Kritikus, hogy meglegyen a belső kompetencia a rendszer lespecifikálásához és a beszállító kiválasztásához. Túl sokszor találkozunk azzal, hogy az IT-részleget vagy egy éppen ráérő mérnököt választanak ki a projekt felelősének. Sajnos ez ritkán hoz eredményt. Olyan személy(ek)re van szükség, akik:
Bár apróságnak tűnhetnek, mindegyik kritérium kritikus, ugyanis a sikertelen vagy félig sikerült bevezetéseknek tipikusan ezek valamelyike az oka.
Egy saját fejlesztéssel megvalósított Andon rendszer
A megfelelő beszállító kiválasztása viszonylag egyszerű feladat: pénzügyileg stabil, kis dolgozói fluktuációval jellemezhető, referenciákkal rendelkező céget kell keresni.
Az átgondolt követelményrendszerre már nem lehet egymondatos tanácsot adni. Először is le kell fektetni az alapelveket! Nem kell minden apróságra kiterjedő, ezer oldalas specifikációra gondolni. Ehelyett a teljes termelést, a termelés összes informatikai igényét figyelembe vevő sorvezetőket érdemes megfogalmazni.
Íme néhány példa, amit az átgondolt stratégia mentén fejlesztő partnereinktől szoktunk hallani:
– „Sikerült végre egy stabil, megbízható hardverbeszállítót találnunk. A dolgozók megtanulták az eszközök használatát, és tudják, kit hívjanak fel, ha elakadtak. A rendszert ezért MOXA hardverekkel kell kiépíteni.” (Máshol Siemensszel, Omronnal stb.)
– „Túl sokszor égettük meg magunkat. Nem akarunk egyetlen szoftveres beszállítótól függni. Ennek az a módja, hogy a felhasznált szoftver csak nyílt forráskódú vagy saját fejlesztésű lehet, és meg kell osztani a forráskódot.”
Más cégeknél pedig éppen fordítva: „Törekedni kell az olyan dobozos szoftverek alkalmazására, amelyek elterjedtek Magyarországon, ezért sokan értenek hozzá.”
– „Nagyon nagy rendszert építünk. Fontos, hogy a mérnökök azonnal átlássák, hogy melyik eleme milyen feladatot lát el, melyik másikkal van kapcsolatban, és milyen interfészen kommunikálnak. A rendszert ISA 95 szabvány szerint kell kiépíteni.”
A sorvezetőn túl pedig szükség van természetesen minimum egy funkciólistára. Milyen feladatot kell ellátnia az elkészült programnak? Egy funkciólista alapján már egy tapasztalt beszállító fel tud tenni kérdéseket, ami alapján össze tudja állítani a specifikációt.
A kompetens munkatárs és a jó szoftver drága. Hosszú távon mégis jobban megéri, akár azért, mert az elkészült szoftvert nem kell javítgatni, akár azért, mert kevesebb emberrel, kevesebb hibával lehet gyártani. Néha a több kevesebb.
Ezekkel a tanácsokkal kívánok jó rendszerbevezetést!
-----
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.
