É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é. Körülbelül így szokták megfogalmazni:

„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, ha kommunikálna egymással az összes rendszer. Csakhogy eddigre már több tíz különböző rendszer van, a legtöbbnek a fejlesztője nem ér rá, vagy elment a cégtől, vagy a beszállítóval elmérgesedett a kapcsolat. 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ő 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ő. Mindenki boldog. Mégis mi ezzel a probléma?

Ma már nincsenek önmagukban álló programok, ezért programozni sem szabad rendszertervezés nélkül. Ma 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, tervezés szükséges. 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 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 pedig mégse 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, és a sebláztól 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, hogy kell őket megtervezni. De vannak, akik nem mentek be ebbe az utcába!

Kik ők, és mit csináltak másképp?

Jellemzően azok a multinacionális vállalatok, ahol 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 lett az a következménye, hogy á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.

Belső kompetencia

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 átlátják a teljes termelési folyamatot, megfelelő kapcsolatrendszerrel rendelkeznek gyáron belül, és van hatáskörük, hogy az ellenérdekelt dolgozókra is rákényszerítsék a meghozott döntéseket. 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.

A beszállító

A második rész, a 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.

A specifikáció

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.

TCO

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!

(Nyitókép: Illusztráció, Adobe Stock)