Laczkó Gábor: – Üdvözlök mindenkit, a mai videónkban azt fogjuk megvizsgálni, hogy ipari IT fejlesztési  projektek kapcsán milyen inputokkal érdemes dolgoznunk. Gyártási ipari folyamatok digitalizálása kapcsán kiemelten fontos és hatalmas felelősséggel jár, hogy olyan szoftvert fejlesszünk, ami aztán ipari körülmények között is megfelelően működik. Itt együttműködik a mérnök, az IT fejlesztő, és az ő kommunikációjuk egy kulcsmomentum a teljes folyamat során. A mostani beszélgetésben több oldalról fogjuk megközelíteni, hogy egy ilyen IT fejlesztési projekt kapcsán milyen nehézségek, milyen tanulságok merülnek fel, és mire érdemes külön figyelmet fordítani, például a mérnök és az IT fejlesztő kapcsolatában. Mai vendégeim Masa Attila az Indeveyestól, Medve Ádám a BorsodChemtől, és Szűcs Dániel az MST Engineeringtől. Én pedig Laczkó Gábor vagyok a Stylers, Braining Hub és a Protechtornak az egyik alapítója. Arra kérlek titeket, hogy nagyon röviden mutatkozzatok be, és meséljetek arról, hogy ti most mivel foglalkoztok. Attila, ha megkérlek és elkezded, megköszönöm.

Masa Attila: – Köszi, sziasztok, Masa Attila vagyok az Indeveyes Technologies ügyvezetője. Gyakorlatilag mi azzal foglalkozunk, illetve olyan projekteket valósítunk meg, amiről ma beszélni fogunk. A mi cégünk, a mi csapatunk gyártásdigitalizációval, illetve gyártásfelügyeleti rendszereknek a fejlesztésével foglalkozik. Mi kifejezetten a gyártószinten érezzük jól magunkat, és gépekhez kapcsolható monitoring rendszereket fejlesztünk. Ez az amiben otthonosan mozgunk, remélem tudok majd hasznos gondolatokat elszórni ezekben a témákban.

Laczkó Gábor: – Köszi szépen. Ádám?

Medve Ádám: – Sziasztok, Medve Ádám vagyok, én a BorsodChem Zrt-nél dolgozom mint IT menedzser, ezen belül is leginkább termelésinformatikai vezető. Mi felelünk, illetve az én csapatom a termelésinformatikai rendszerekért. Ez egy viszonylag kicsi csapat, 7 fős, fejlesztői csapat, fejlesztőkből áll, illetve nemcsak fejlesztünk, üzemeltetünk, hanem kicsit projektmenedzserkedünk is. A BorsodChemről annyit röviden, hogy ez egy vegyipari vállalat, a nevéből adódóan Borsod megyében található. Mi a Wanhua Industrial Groupnak vagyunk a tagjai 2011 óta. Jellemzően műanyag alapanyag és vegyianyag gyártók vagyunk. Beszállítunk autóipari cégeknek, bútoripari cégeknek, ruházati termékek gyártása területén is jelen vagyunk, illetve természetesen építőanyagiparnál is.

Laczkó Gábor: – Köszi szépen. Dániel?

Szűcs Dániel: – Sziasztok, Szűcs Dániel vagyok, az MST Engineering Kft. Debrecen képviseletében. Mi egy gyártócég vagyunk, elsősorban nyugat-magyarországi vevőkörrel. Egyedi gyártásban tevékenykedünk, igazából bérgyártást végzünk, ami azt jelenti, hogy vevői igényeket szolgálunk ki mindenféle tekintetben. Forgácsolás, lakatosipari munkák, szereldei és felületkezelési tevékenység amit végzünk. Összetett és mindig változatos, úgyhogy sok érdekességgel találkoztunk már, bízom benne, hogy érdekes dolgokat fogok tudni mondani én is.

Laczkó Gábor: – Szuper, nagyon szépen köszönöm. Ha már így felütöttük a témát, és megkezdtük azzal, hogy beszéltünk IT szakemberekről, mérnökökről, ti mit tapasztaltok, mik azok a jellemző különbségek, amik tipikusan egy ipari területen dolgozó mérnök, és egy IT szakember között jelentkezik? Miből fakadhat az, hogy az ő nyelvüket, az ő közös kommunikációjukat folyamatosan fejleszteni kell? És akkor bedobom, nyugodtan bárki kezdje meg, amit szeretne mondani.

Szűcs Dániel: – Kezdem én akkor, a sor végéről újra előre. Amit én tapasztaltam, gyakorlatilag ténylegesen egy teljesen külön nyelv, teljesen más nyelvet beszélnek, teljesen másképpen gondolkodnak, mind az informatikus, mind a programozó, mind a mérnök. Bármelyik kabátot veszi fel az ember, szerintem mindig egy külön szerep, egy teljesen külön világ, teljesen más dimenzió. A multiverzumok világát éljük, úgyhogy ez teljes mértékben visszaközön itt is. Egy olyan köztes szerep, ami szükséges, hogy legyen köztük. A programozó, a termelés, az üzemvezetés, a cégvezetés, mindenki között, aki beszéli az informatika nyelvét is, beszéli a programozó nyelvét is. Ez egy olyan nélkülözhetetlen szerep, amit vagy a fejlesztő cég nyújt, és ő tölti be, és nála van egy olyan ember, aki ezt a kulcspozíciót be tudja tölteni, vagy pedig a cégen belül van egy rendszergazda, aki a rendszerfejlesztésért felelős szakember vagy bárki más. Az alapja pedig az, hogy teljesen más oldalról néznek a világra. Egyik az a fizikai probléma és a napi feladatokkal, elvégzendő dolgokkal találkozik, a másik előtt pedig az 1-esek és a 0-ák sorakoznak fel. Egyik a lehetőségekben gondolkodik, a másik az ő lehetőségeiben gondolkodik. Nagyon-nagyon más látásmód.

Medve Ádám: – Igen, én abszolút egyet tudok érteni minden mondatával Daninak, mert ugyanezeket a problémákat tapasztaltuk mi is. A szemlélet, a látásmód, az, hogy különböző területekről jönnek a kollégák, hiába mérnök, mérnök, de az IT-s inkább – ha lehet így fogalmazni – egy külön faj, nekik inkább speciális a tudásuk, viszont üzleti oldalról akár a mi esetünkben a termelésről, kevés az információ. Amikor odakerülünk, hogy van egy megoldandó probléma, valamilyen új rendszer bevezetésében, vagy egy változás, az üzleti oldal a mi esetünkben nem elegendő információt ad át az IT-k felé, tehát hiába írják le, hiába írják körbe a problémát, egyszerűen az IT-s nem fogja valószínűleg megérteni elsőre, hiszen nincs tapasztalata ebben. Mit lehet ezzel kezdeni? Mi mindig azt mondjuk, hogy jó folyamatábra az már fél siker. Hogyha fel tudják rajzolni a folyamatokat, az már nekünk egy nagy segítség. Ha van egy olyan köztes személy, aki az üzleti oldalra is rálát, az IT oldalra is rálát, akkor az nagyon előre tudja mozdítani a projektet. De nálunk ez a személy nincs jelen.

Laczkó Gábor: – Azt mondjátok mind a ketten, hogy kell ez a köztes személy mindenképpen. Ez ennyire nélkülözhetetlen úgy érzitek? Muszáj bevonnunk egy harmadik személyt?

Medve Ádám: – Nem nélkülözhetetlen, viszont egyre inkább nélkülözhetetlen lesz. Mert egyre inkább olyan projektek lesznek, amiből az IT-t nem lehet kihagyni. Ez nagyon jelentkezik nálunk is. Egyre több projekt van, mindenbe be kell vonni gyakorlatilag az IT-t. Egyébként ez egy jó kérdés, én is fel akartam tenni, hogy mit lehet ezzel kezdeni. Más szemszögből megvizsgálni? Mivel nem lehet minden IT-sból üzleti szakembert képezni vagy fordítva. Lehet a tudásukat javítani üzleti oldalon is, IT oldalon is, lehet bejárásokkal, gyárlátogatásokkal, rotációs programokkal ezeket egyébként javítani, de soha nem lesz valószínűleg egy olyan tudása, mint a köztes személynek, akinek dedikáltan, célzottan ez a feladata. Az IT szakembereknek, az üzleti oldali szakembereknek ugyanúgy üzemeltetni kell, saját területükkel foglalkozni kell.

Szűcs Dániel: – Én ezt annyival egészíteném ki, picikét máshogy látom, teljesen egyetértek azontúl, viszont a köztes szerep nem megoldható. Tehát olyan nincs, hogy valaki nem is informatikus, nem is mérnök, nem is termelési ember, de egyébként megérti mind a két nyelvet. Az ember vagy ez, vagy az, és egyébként van mellette egy nagyon nagy affinitás a másik téma felé. Igazából pont azt látom, hogy igenis az az informatikus, aki kellő mennyiségű információval van bővítve képzettségileg, tapasztalatilag vagy bármilyen úton-módon. Vagy ugyanez fordítva. Egy olyan gyártási szakember, egy olyan mérnök, aki megfelelő információkkal és affinitással bír az informatika világáról. Egyre jobban azt látom, hogyha valaki csak köztes szereplő, nagyon erős szerep és kitölt egy embernyi funkciót. Tehát nem azt mondom, hogy ez csak egy mellékszál és valaki programozzon, de amikor kell, akkor meg ugorjon be egy olyan kalapba, hogy én most megértem mit kell csinálni. Hanem inkább pont az, hogy igenis ez a szerep egy olyan szerep, amiben egy alapszakmára, bőséges alapismeretre rá kell építeni a másikat is. Ez képzésekkel, coacholásokkal, gyárlátogatásokkal, nagyon-nagyon sok mindennel lehet felvenni, és az biztos, hogy olyan szintre tenni főleg egy ilyen köztes szereplőt, hogy akár a termelést vinni, vagy akár tudja a programot is vinni, abszolút megoldható. Láttam olyan céget, ahol a szoftvernek a fejlesztője egy sajnálatos emberi, személyügyi változás után gyakorlatilag a gyár üzemeltetését átvette. Cégvezetői pozícióból előrelépett egy informatikai vezetői pozícióba, mert ő tudta, hogy egy vállalatirányítási rendszer, termelésprogramozó, termelésirányítási rendszer a cégnek a fő folyamatait tartalmazza. Ha ezt valaki kisujjból tudja, akkor ő tudja, hogy hogyan működik a cég. Ismerheti egyébként sokkal-sokkal jobban, mint az, aki ténylegesen az egyik területen „szakértőként”, szakterületének egyik ékes elemeként nagyon-nagyon jól végzi az ő munkáját. Láttam olyan céget másfél-kétmilliárdos árbevétellel, ahol az IT vezető 3 évig vitte a céget. Kell mind a kettő, mindkettőben lehet kemény tudás, mert kemény alapok kellenek. Az biztos, hogy nem fél év alatt vesz fel egy informatikus ilyen műszaki tudást, vagy ugyanez fordítva, egy műszaki vagy egy gyártási alapokkal, mérnöki alapokkal bíró ember, akinek az informatika még közelről sem fogja meg, olyan emberből nehéz egy ilyen embert csinálni. Azon túl én a gondolkodásmódot emelném ki. Ott egy ilyen pozícióban nem elég az, ha valaki ismeri az SQR-nek a csínját-bínját, meg a HANA-nak a dolgait, vagy beszéljünk bármelyik szoftverről. Hanem ott inkább ténylegesen arról szól az igazi kérdés, hogy rendszerben mennyire tud gondolkodni, mennyire tud abban gondolkodni, ha én itt jobb oldalon felül szeretnék egy zöld pöttyöt, az mivel jár a rendszerben az a fajta rendszerelvűség, az a fajta következetesség, az a fajta sokrétűségben gondolkodás, és ugye ebben benne van a másiknak a területe is, effektíve a gyártás, a termelés, bármelyik más része. Van erre egy nagyon jó elszólás, talán A mag című filmben volt, amikor az informatikai fejlesztő srácot kérdezik, hogy ő kicsoda, merthogy komolytalannak tűnik. Kérdezte, hogy ön hány nyelvet beszél? – Hetet. – Nagyszerű. Én egyet, de azzal elveszem az életét, megoldom a problémáit. Tehát azzal az egy nyelvvel sok mindent meg lehet oldani, de ez nem elég, hanem a gondolkodásmód az a fajta következetesség, az a fajta sokrétűbben gondolkodás, hogy egy dolgot nézek, egyetlen zöld gombot nézek, az másik 35 aspektusban mit fog eredményezni, mit fog csinálni, ki fogja használni, miért fogja használni? Kicsit rendszerben való gondolkodás ez, a multiverzumos verzió ténylegesen, sokrétűen gondolkodva. Ennek a fajta kommunikációnak az alapja, hogy amikor azt mondják neki, hogy zöld gomb, akkor ő látja mögötte picit a 0-kat, meg az 1-eseket. Picikét látja, hogy azt ki fogja használni, milyen módon, ki fogja megnyomni azt a gombot. Ez informatikai oldalról és szoftveroldalról is egy optimalizált programmá fog válni, és a felhasználói oldalról is egy felhasználóbarát programmá fog válni. Szerintem nagyjából ez lenne az az alap, ami kelleni fog az ide én kérek egy zöld pöttyöt című kérdésre.

Laczkó Gábor: – Attila?

Masa Attila: – Nagyon sok mindent elmondtatok, amihez nehéz már most hozzátenni. Egyik, ami a legfontosabb, hogy talán mi pont ezt a szerepet igyekszünk betölteni, ha nem is egyszemélyben, hanem egy külső konzulens személyében. Nagyon-nagyon régen voltak termékvízióink, hogy Ipar 4.0, meg gyártásdigitalizációs szoftvert leveszünk a polcról és eladunk, de nagyon gyorsan kiderült, hogy nem így működik. Azt tapasztaljuk, hogy nemcsak attól fontos a szerepünk, hogy a projekt végén valamilyen értéket teremtő szoftvert az ügyfélnek leszállítsunk, hanem hogy azon az úton közösen hogyan jutunk el, nyilván ezt így belsőleg ti is ugyanígy tapasztaljátok. Kicsit visszatérve arra, hogy az IT-s és a mérnök miben gondolkozik másképp, talán azt tudnám mondani, hogy ami a mérnökségnek a problémája, az az IT-nak a baja lesz egy idő után. Ha szoftverről beszélünk, mindig az IT jön elő, hogy így az IT, úgy az IT, de nagyon kevés helyen látjuk azt, hogy ezt az IT akarná igazán. Ők inkább úgy élik meg, hogy lesz egy újabb rendszer, amit nekik üzemeltetni kell még a meglévő 12 mellé. A mérnökségen viszont ott van a nyomás, hogy ők valamiképpen optimalizáljanak a gyártáson, és hatékonyabban tudjon a gyártás működni. Tehát alapból itt ők már érdekellentétben vannak. Ami nyilván így humán oldalról nem segíti a közös kommunikációt, hogy megértsék egymást. Ez a menedzsment feladata, hogy tudja a szervezetet evangelizálni, meg úgy irányítani, hogy megtalálják a közös nevezőt, belássák, hogy ez mind a két területnek az előnyét szolgálja. Viszont az tény, hogy eddig ők nagyon távol voltak egymástól, tehát klasszikusan egy mérnöknek az volt a feladata, hogy a gyártási folyamatokért, a berendezésekért feleljen, az IT-nak pedig, hogy a hálózati infrastruktúra, szerverkörnyezetek stb. kifogástalanul operáljanak. Az e-mesh SCADA és hasonló rendszerek évtizedek óta vannak, még ha eddig inkább a nagyobb cégeknek volt a kiváltsága, hogy ilyen szoftveres eszközöket használjanak, de ezek léteznek. Ilyen szempontból a termelésinformatika mint olyan, már szintén jelen van régebb óta, de most van egy nagyobb hype ezek körül. A technológia már nagyon sokat segít abban, hogy egy rendszernek a bevezetése könnyebb és egyszerűbb legyen. De tény, hogy a két részleg között kell fordítani. Szerintem ami kihívás itt, bármilyen IT projektről beszélünk egyébként, az a termék, az a megoldás akkor lesz eladható, akkor lesz piacképes, ha az ténylegesen megold valamilyen üzleti problémát, és nem egy nagyon fancy architektúrát szeretne az ügyfél venni amiben nagyon szexi technológiák vannak, mert azzal nem lesz előrébb. Értelemszerűen egy bármilyen IT projektnél meg kell tudni fogalmazni, hogy mi az üzleti igény, vagy mi az a szűk keresztmetszet, amit szeretnénk feloldani. Mondjuk B2C világban csinálunk egy commercial alkalmazást, úgy gondolom egy átlagember is könnyen meg tudja fogalmazni, hogy mi az elvárása szoftverrel szemben. Ha bemegyünk egy gyárba, ott komplexebb folyamtok vannak, komplexebbek a problémák, oda már kell az a mérnöki domain tudás, kell egy mérnök, aki ezt a problémát meg tudja fogalmazni, hogy mire szeretne a szoftver által megoldást kapni. Ezért vékonyabb itt a jég, vagy nehezebb a két területet egyeztetni, mert tényleg kell az a mérnöki szaktudás, hogy el tudja mondani, hogy neki mire van szüksége. Az IT-snak pedig muszáj ezeket az igényeket megértenie és lefordítania a technológiára, és kitalálni, hogy mi lesz az a felépítés, az a szoftverfelépítés, az a feature set, ami ezt a végén eredményezi. Ilyen szempontból mi azt látjuk, hogy nem a technológiák a fő akadályozói vagy nehezítői ennek a projektnek, hanem egyszerűen az emberek, és ezt nem pejoratív értelemben, hanem amiatt, hogy nem erre vagyunk jelenleg berendezkedve, nem ebbe szocializálódtunk. Ezt egészen odáig vissza lehetne gyűrűztetni, hogy kérdés, hogy az oktatás majd ezt időben vajon hogyan tudja lereagálni. Eddig nagyon szigorúan mérnököket képeztünk, nagyon szigorúan IT-sokat, de a jövőben ezeknek a hibridjére lesz szükség. Nem is azért, hogy ezeket a projekteket egyszemélyben megoldja, hanem, hogy tényleg értsék egymás problémáját. Hogy a mérnök azt el tudja fogadni, ha az IT-s azt mondja, hogy márpedig az adatok nem fognak kimenni a gyárból, mert nekünk az rengeteg kibervédelmi problémát ad. Az IT-s pedig értse meg azt, hogy miért fontos azokat a gépeket bekötni a hálózatba, amivel ugyan neki lesz plusz feladata, de a gyártás hatékonyabb lesz, a gyár költséghatékonyabban működik, és lehet, hogy az majd egyszer az ő fizetésében is meglátszik. Szóval nagyon összetett ez a kérdéses problémakör, de van azért fény az alagút végén.

Laczkó Gábor: – Most amit eddig felsoroltatok, körülbelül öt beszélgetésnek a témája lehetne pluszban, iszonyatosan nagy a pool. Van egy ilyen ökölszabály, amit szoftverfejlesztési szempontból szoktunk emlegetni, hogy egy-egy fejlesztési folyamat során 60 %-ban az input minősége határozza meg majd a szoftvernek a sikerességét. Attila te is mondtad, hogy például egy műszaki probléma, amit megfogalmaz egy mérnök, hogy ugratok neki egy IT fejlesztési projektnek? Mik a legelső lépések, ti hogy csináljátok? Best practices mindenkitől jöhet, hogy ki mit szokott.

Masa Attila: – Két szélsőséges példát elmondanék gyorsan. Van az a verzió, amikor már nagyon magas az érettségi szint, és itt direkt nem azt mondom, hogy ez mekkora cég, létszámot, volument vagy telephelyeket tekintve, mert nagyon diverz a piac ilyen szempontból. Nem fogok végképp neveket említeni, találkoztunk nagyon nagy enterprise környezetben is azzal az esettel, hogy nem igazán tudták mit szeretnének, meg találkoztunk azzal is, hogy egy kkv tudott adni egy elég részletes specifikációt arról, hogy mit szeretne. De lényegében ezzel a két véglettel és az átmenetekkel lehet találkozni. Egyrészt vannak, akik hallottak arról, hogy létezik manapság gyártásdigitalizáció, és bizonyos szoftvertechnológiák által a gyártási adatok gyűjtésének köszönhetően lehet hatékonyságot fokozni. De lehet, hogy csak egy konferencián hallották az Ipar 4.0 kifejezést, és akkor a menedzsmentnek ez megtetszett, kitalálták, hogy ők ebbe akár invesztálnának is, mert tudják, hogy ez mi fán terem. Nyilván ilyenkor a mi szerepünk még fontosabb és erősebb, hogy egy felmérés és konzultáció során igyekezzünk azt felmérni, hogy jelenleg milyen érettségi szinttel rendelkeznek, milyen ponton lépnek be, mennyire gépiesített a gyártás, mennyire van az informatikai infrastruktúrájuk erre felkészítve ők maguk, illetve a szervezet, milyen problémákat szeretnének megoldani. Nagyon fontos azt az elején azonosítani, akár közösen, akár általuk, hogy mi lesz az elvárás a fejlesztés eredményeképpen, mert ha ez nincs meg, akkor nem tudjuk, hogy hova tartunk. Van az a megközelítés, hogy gyűjtsünk adatot gépektől, aztán majd lesz vele valami. Az a tapasztalat, hogy ez nem feltétlen hoz sikerélményt rövidtávon. Hosszútávon lehet. Persze maradhat ez a megközelítés, csak akkor azt a kockázatot vállalni kell, hogy nem biztos, hogy belátható időn belül eredményre jutunk. Az a tapasztalat, hogy sokkal eredményesebb lehet egy projekt, ha tudjuk mit szeretnénk elérni, ez nyilván evidens is. A pénzügyi részlegnek valamiképpen alá kell támasztani, hogy miért kér a mérnökség erre a fejlesztésre pénzt. Ilyenkor erősebb a külső szolgáltató vagy a konzulens cégnek a szerepe, hogy ezeket az igényeket technológiai megoldássá tudja lefordítani. A másik véglet, ahogy említettem, amikor küld az ügyfél egy 80 oldalas specifikációt, hogy ezt szeretné. Gyakorlatilag nekünk ezen nem kell túl sokat gondolkozni. Ilyenkor megvan az a hátrány, viszonylag kötött a kezünk, tehát tényleg azt kell pontosan leszállítani, amit kér. Ilyen szempontból a mi kockázatunkat viszont csökkenti, hogy amikor az átvétel megtörténik, akkor ki hogyan értette annak a zöld gombnak a működését, amit Dániel is említett, hogy az mitől lesz zöld. Úgyhogy ez egy tipikus eset, amikor első projekt van egy ügyfélnél, hogy „hát én csak azt szeretném, hogy legyen zöld az a gomb, mi kell ahhoz”? És amikor elmondjuk, hogy két hónap fejlesztés, akkor nehéz ezeket megértetni, hogy egy ilyen egyszerűbb feature az miért eredményez ennyi ráfordítást. Nagyon fontos az input. Két lehetőség van, vagy az ügyfél már meg tudja mondani, mert van olyan érettségi szinten, akkor azt elfogadjuk, nyilván próbálunk tanácsokat adni, hogy hol van észrevételünk. Ha nincs még azon az érettségi szinten, akkor nekünk kell megcsinálni, ez közös érdek, mert másképp nem fog révbe érni.

Laczkó Gábor: – Ádám, nálatok hogy működik?

Medve Ádám: – Én ezt az input témát kettészedném, aztán majd vitatkoztok vele. Van egy kezdeti input szerintem, az lehet egy 60-70 % ökölszabály szerint, viszont utána, ha megvan ez a kezdeti input és elkezd dolgozni a fejlesztő és az üzleti oldal is ezen, onnantól kezdve jönnek még elő dolgok. Az igénylő nagy valószínűséggel – evés közben jön meg az étvágy – nagyjából tudja, hogy mit szeretne, de aztán lesznek ötletei, vagy átgondolja újra azt a folyamatot. Valószínűleg a kezdeti input kevés. Én legalábbis így gondolom és ezt tapasztaltam. Utána, ha most belemegyünk abba, hogy milyen módszertanokkal lehet fejlesztéseket végezni, agilis módszertanoknál fontos a kommunikáció. Az, hogy ő az elején letett egy inputot, és nem kommunikálok vele vagy nem olyan minőségben a projekt során, akkor nagy valószínűséggel nem az lesz belőle, amit ő elképzelt az elején. Fontos közben is kommunikálni, tehát iteratív módon kell ezt csinálni. Minél mélyebben meg kell ismerni a problémát, nálunk egy folyamatábra mindenféleképpen szükséges, egy business case, ha tudunk pilotot csinálni, akkor mindenképpen, vagy egy POC, tehát hogy lássuk, hogy valóban mit szeretne a felhasználó. Kimenni hozzájuk, megnézni a területen, hogy hogyan működnek a dolgok, mert sok esetben, ha elmondja az igénylő, az nem biztos hogy úgy néz ki a valóságban is. Én sem akarom itt pejoratív értelemben feltüntetni a felhasználókat, egyszerűen más a két terület, más valószínűleg régiónként az érettségi szint is, meg vállalatonként is az érettségi szint ebben a tekintetben. Ezeket jelenleg el kell fogadni. Egyébként jöhetnek képbe különböző toolok, különböző eszközök, amik ezt elősegíthetik. Mi nem foglalkoztunk eddig felhasználói felület designerrel. Ez egy eszköz, amivel meg tudod tervezni a felületet, ezt meg tudod mutatni a felhasználónak, ő akkor már gyakorlatilag a valóságban látja, hogy hogy nézhet ki ez a felület, és mögé tudsz tenni eseménykezeléseket, illetve interakciókat. Konkrétan látod, hogyha ide kattintasz, akkor mi fog történni. Vagy ha ezt a listát lenyitod, akkor mi jelenjen meg benne. És hogyha már ő ezt látja, jobban el tudja képzelni, azt mondja neked, hogy igen, ő ezt szerette volna, akkor az szerintem egy óriási segítség, és rengeteg időt meg lehet ezzel spórolni.

Laczkó Gábor: – Dániel?

Szűcs Dániel: – Teljesen igaz, én is ezt az összetettebb verziót gondolom. Igazából az elhangzottakban az a szép, minden oldalról akárhogy is nézzük. Ami az igény az egyik oldalon, abból lesz a probléma a másik oldalon. Ugyanez fordítva. Ami a megoldás az egyik oldalon, abból lesz a probléma, merthogy azt használni kell, csinálni kell, üzemeltetni kell. Ami még ezen túlmegy nekem, hogy akkor amikor a kollégák egy igényt mondanak, sok esetben azt látom, hogy azon túl sokszor megvan az, hogy nincsen rá szükség. Tehát gyakorlatilag nem az a tényleges igény. Ádám, nálatok egy nagyon nagy rendszerből egy komplett csapat dolgozik ezen. Ott nálatok házon belül kell, hogy meglegyen ez a tudás. Az hogy pontosan rajzoljuk fel a térképet, pontosan tudjuk mi az igény, pontosan oldjuk meg a problémát. Ti ezt házon belül oldjátok meg. Attila, amit mondtál a két véglet, ott ugye az egyik oldalon a vevőnél van meg, a partnernél van meg a házon belüliség, és ezt neveztük érettségnek, ez nagyon jó szó rá. A másik meg az, amikor nem tudja, hogy mit akar, ő azt akarja, hogy ez a gomb változzon zöldre vagy legyen zöld és akkor oldjátok meg. Ilyenkor van az, hogy oké, miért ezt akarod, ez a gomb kell-e hozzá, ez a legjobb formája-e ennek, ténylegesen mit akarsz egyébként elérni a háttérben. Mert lehet, hogy ez a zöld gomb csak tünet. Lehet, hogy neki három lépéssel hátrébb van amire tényleg szüksége van, vagy három lépéssel előrébb, amit ő tényleg akar ebből a zöld gombból. Sok esetben ennek a kommunikátornak, ennek a projektgazdának vagy az, aki a térképet felrajzolja, nevezzük bárhogy is, ez a feladat akkor olyan felelősséggel bír, hogyha egy aspektusát kihagyja ennek a tervezési folyamatnak, ennek a projektfolyamatnak, akkor elkészül valami, ami nem a leghatékonyabb, nem a legcélszerűbb, nem a legeredményrevezetőbb megoldás lesz. Azt viszont szidni fogják mind a két oldalon. Kicsit felesleges, kicsit foglalkozni is kell vele, üzemeltetni is kell, sokba is kerül lefejleszteni, lehet hogy pont felesleges, és ezekből lesznek az olyan oszlopok, meg olyan tartalmak, meg olyan programelemek, amiket csinálunk-csinálunk, és a végén meg ott van, nem kér enni, de nagyon sok pénzbe került. Utána meg csak kerülgetni kell. Ilyen szempontból is nagyon fontos ez, meg azon túl, hogy ténylegesen hogyan fordítja le az ember ezt egy jó megoldásra, és azt hogyan adja át. Ahhoz olyan csapatmunka kell, itt jön be a képbe, hogy van egy előzetes információ, hogy ő mit akar. Utána annak van egy visszakérdezgetése, egy rendes kérdőív gyakorlatilag, hogy ő mit is szeretne pontosan, mit szeretne elérni, mi a célja, ki csinálja, mit csinál, hol akarja ezt használni, mi lesz ebből a végcél, milyen adatokkal akar dolgozni, milyen adatok azok, amik neki megbízhatóak, fixek, tud rájuk támaszkodni, és abból akar, abból tud, vagy abból képes dolgozni. A végkifejletet pont ugyanúgy meg kell vizsgálni. A másik oldala az pedig az, hogy egy ilyen programnak azon túl, hogy az input mondjuk 60 %, mivel ennyire összetett, valahol itt lehet a százalék. Több mint 50 % azon múlik, hogy pontosan értsük meg azt, hogy mit akarunk. Az, hogy ez az input melyik része, hogy ez alapinput, vagy a már kidolgozott input, és az elkészült szoftver az csak a „maradék” 40 %, ez már szerintem apróság. A különbözet a kettő között, hogy ide értjük vagy oda értjük ezt a nem kevés mennyiségű munkát. A szoftvert utána jól megcsinálni, az egy másfajta tudást igényel. Megálmodni azt, hogy pontosan mit akarok, akár egy folytonos jobbítás, akár egy célzott költségcsökkentés érdekében, ez megint egy másfajta tudást igényel. Az, hogy ezek között egy jó megoldást és egy jó közbenső folyamatot tudjunk kialakítani, ahhoz sok esetben tényleg egy team kell. Meg kell kérdezni az eredeti ötletgazdát szerintem, vagy a másik az az, hogy ténylegesen van ott egy ember, aki azt mondja, oké, elmondtad, hogy te egy zöld gombot akarsz, mehetsz a dolgodra, majd szólok, ha készen van az, amit akartál. Emögött van nem kevés agymunka, amire ez fejben összeáll. Ennek az embernek, ennek a pozíciónak, ennek a cégnek a tudása az, ami idős korra meglesz. Tipikus példa, amikor kijön a villanyszerelő, kijön a gázszerelő, meghúz két csapot és azt mondja, hogy 30.000 forint lesz. Nem a 3 percet fizetjük ki, hanem a mögötte lévő 30 évet, hogy tudta, hogy azt a 3 csavart kell meghúzni. Egy ilyen jellegű projektnek az összerakásánál az az idő, amit eltöltünk a projektnek a jó megvalósításával, az lehet akár évek, mert ötször csináljuk meg, háromszor fejlesztjük le, 30 ember dolgozik rajta, 4 x 4 program készül el ötfajta változatban, és teszteli 30 másik ember. Vagy pedig van egy ember, aki két hét alatt összerakja úgy, hogy működik, használjuk, készen van, jöhet a számla. A kettő között hatalmas különbség van.

Laczkó Gábor: – Többször említettétek – és ez megütötte a fülemet – a specifikációt, meg agilitás is szóba jött. Valamelyikőtök mondta, Attila azt hiszem te, hogy megvan a két véglet, hogy írnak egy specet, az részletes, Ádám, te mondtad, hogy egyébként iteratív módon sokszor utólag jönnek az igények. Nyilván ez így van, hogy jönnek az igények utólagosan. Mennyire tud ilyen szempontból az agilitás – Ádám te azt mondtad, hogy nálatok ez elég hétköznapos – belefolyni egy ilyen típusú szoftvertervezésbe? Az én gondolatomban az van, hogy rengeteg berendezés, gép van, folyamat van, aminek meg kell felelni, protokollok vannak, ahogy ezek működnek. Nem az van, hogy ennek nagyon streaknek kell lennie? Vagy lehet mégis egy picit agilis?

Medve Ádám: – Nálunk az, hogy egy olyan módszertanban dolgozzunk, hogy megkapom előre az inputot, és majd a végén találkozom újra az ügyféllel vagy a felhasználóval, az biztos, hogy nem fog működni. Itt még sok mindent hozzá tudok tenni az elmondottakhoz. Az igényekről is lehetne beszélni, hogy milyen igények vannak. Egyrészt, ki az igénylő? Mert lehet igénylő az üzleti oldal, de lehet az IT is. Nagyon nem mindegy. Sőt, van egy harmadik is, akit nem vennék sehova, az pedig a felső vezetés. Amikor azt mondja a felső vezetés, hogy márpedig ezt nektek meg kell csinálni, márpedig ezt nektek be kell vezetni, akkor lehet, hogy sem az IT, sem az üzleti oldal nem úgy fog hozzáállni a projekthez, hogy gyerünk, csináljuk, és megvan a munkakedv, vágjunk bele a projektbe. Hanem mindenki kicsit szívja a fogát, hogy ez nem biztos, hogy jó, nem érti, ezt miért kell csinálni, aztán nagyjából olyan is lesz a minősége a projektnek a végén, amikor ilyen igényt kapunk. Úgyhogy ezt is fel lehetne boncolni, illetve mint mondtam, nálunk van egy 7 fős fejlesztői csapat, illetve dolgozunk külsősökkel is, hiszen attól függetlenül, hogy van még más IT csapat is rajtunk kívül, elég nagy a terület, nagy a létszám. Hiába vannak hasonló technológiák mindenhol, az üzemek azért különböznek, és a területek is különböznek, elég nagy területeket kell lefedni. Limitáltak az erőforrások. Egyre több igény van, egyre több igényt kell kielégíteni. Amellett, hogy mi fejlesztünk, üzemeltetünk is, supportot is adunk, kicsit projektmenedzserkedünk is. Nálunk például a scrum módszertan nagyon nehezen tudna működni. Próbálkozunk egyébként, de ezeket a fix idejű sprinteket nehezen tudnánk tartani. Nem feltétlen tudom minden fejlesztőnek megengedni, hogy akkor te két hétig csak ezzel az egyetlen dologgal foglalkozol. Valahogy kicsit hibrid módon működünk, de agilis módon, mert folyamatos a kommunikáció, különben nem az lesz a projektből, amit megálmodott a felhasználó.

Masa Attila: – Igen, itt említettem, hogy kétféle specifikáció létezik, bár azt nem mondtam, hogy a specifikáció az szentírás, az egy irányelv. Sok mindent elmondtatok, ami emellett felróható, az egyik az, hogy nagyon fontosak a pilot projectek, ezeket mi is mindig „erőltetjük” az ügyfélnek, hogy mindenképpen csináljunk egy pilotot. Egyrészt amiatt, hogy amit magasabb kockázatúnak érzünk és ugyan kihívás, de jobb, ha az elején letudjuk, azokat a feature-öket, igényeket soroljuk előre. De mindenképpen legyen a feature setben olyan tartalom is, aminek köszönhetően belátható időn belül lesz közös sikerélményünk. Ez nagyon fontos, hogy közös sikerélmény legyen, ez megalapozza a hosszútávú közös munkát. Ez tényleg iterációs folyamat. Vannak dobozos gyártásdigitalizációs termékek a piacon, de azt is az integrátoroknak mindig testre kell szabni. De nem lehet egy ilyen megoldást úgy megvenni, mint egy Windowst vagy egy Office-t, amit feltelepítünk, és akkor működik. Ezt muszáj elfogadni az ügyfeleknek, hogy ezen közösen kell dolgozni hónapokon vagy akár éveken át. Mi nem láttunk eddig más utat vagy tapasztalatot. Ahol ezt elfogadják, és erre fel vannak készülve, ott lehet egyébként jól együtt dolgozni, és akkor azt mondanám, hogy ez a kezdeti specifikáció, ez egy irányelv, ez egy kiindulási pont és utána folyamatosan iterálunk rajta. Az agilitás az nagyon jól tudna találkozni ilyen projektekkel, csak mi külsősként, de ezek szerint ti belsőleg is küzdetek ezzel a problémával. Nagyon örülnénk neki, ha valaki tud erre tippet mondani, szívesen látom a csapatban. Az iparban az agilitást nem lehet eladni. Úgy működik a szervezet, hogy a beszerzés azt mondja, hogy erre a projektre van ennyi idő, a menedzsment pedig megkérdezi mikor lesz kész, a, mérnökség pedig meghatározza, hogy mi legyen a tartalom. Gyakorlatilag ez a három fő paraméter leír egy projektet, mi lesz benne, mennyibe fog kerülni, mikor lesz kész. Az iparba nem lehet, mi nem tudtuk eddig átnyomni, hogy jó, majd csinálunk valamit, majd fog valamennyibe kerülni, és majd egyszer lesz valami eredménye. Nem így működik a gyártás. Valahol a kettő között „fű alatt” át lehet vinni, és ebből szokott az lenni, hogy elindul a fejlesztés, elindul a közös munka az ügyféllel. Menet közben ismertetjük vele azokat a problémákat, amik szembejöttek, amiket vagy véltünk már az elején vagy nem véltünk, és azt mondjuk, hogy most eddig eljutottunk, de nem biztos, hogy innen arra kéne továbbmenni, amit eredetileg terveztünk, hanem menjünk tovább egy másik irányba. Vagy azt mondjuk, hogy azért fog a projekt később elkészülni, mint azt terveztük, mert ezzel meg ezzel az akadállyal küzdünk jelenleg, hogyan tudnánk ezt közösen megoldani. Illetve nagyon fontos, talán Dániel említette, hogy nem ritka eset, hogy menet közben kiderül, hogy az a feature, amin mi már két hete izzadunk, és az ügyfélnek feltárjuk, hogy ezen már két hete ezen a problémán izzadunk, azt mondja, hogy végülis ez nem is olyan fontos, arra nem igazán van szükségem, úgyhogy ki tudjuk hagyni. A gyakorlatban talán valahogy úgy működik, hogy egy ilyen „kamuagilitást” csinálunk, elindul a projekt, elkezdünk együtt dolgozni és aztán a három paraméter valamelyikéből engedünk közösen. Vagy a scope-ot kicsit megváltoztatjuk, vagy az ügyfél belátja, hogy ez a probléma összetettebb, adok még neketek egy kis időt, meg egy kis pénzt. De valahol ebben az iterációs folyamatban mindig igyekszünk konszenzusra jutni.

Medve Ádám: – Ez a scope, nagyon jó, hogy említetted, mert a hatókörökkel is mindig probléma van. Az, hogy meghatározzuk az elején a scope-ot, hogy ebbe bele kell férni, ez azért szokott változni, így ahogy mondod, ez sem ritka. Ilyenkor jön az, hogy változott a scope, semmi gond, de ehhez most akkor több idő kell vagy több erőforrás. De egyik sincs, szóval akkor ezt így oldd meg. Mondtad, hogy nem nagyon tudtátok átnyomni ezt az agilis módszertant a termelői vagy gyártó vállalatoknál. Van ahol egyébként igen? Van olyan terület, ahol igen?

Masa Attila: – Bankszektorban már volt akinek sikerült.

Medve Ádám: – Lehet, hogy a bankszektor, a pénzügyi szektor merőben más, mint a termelő, gyártó terület, de talán ezeknél a folyamatoknál kicsit komfortosabb a működés. Ha most minket nézünk, mint termelő vállalatot, és valószínűleg a gyártóknál ugyanez jelen van. Ha vannak leállások, vagy van egy havária helyzet, olyankor mindenki eldob mindent. A bankszektorban talán nem annyira gyakori, hogy bedőlnek a bankok is, mondjuk, hogy mindenkinek szabadjára engedik a pénzét, ami a számláján van. Én előzetesen beszélgettem, egyeztettem mérnök kollégákkal itt házon belül, ők ezt megfogalmazták, hogy az IT-soknak nincs rálátásuk az üzemeltetésre. Tehát nem látják, hogy napi szinten, napi menedzsmentben ők mit csinálnak. Nyilván vannak olyan folyamataik, amit nem tudnak elhagyni, nem tudnak eltenni máshova, más időpontba, nekik ezt meg kell csinálni. Ezért az elején még az agilitás megvan, amikor elindul a projekt, akkor mindenki odakoncentrál. Majd utána, ahogy ez az egész elindul a maga útján, akkor lehet, hogy már kevésbé lesz agilis. Ezt viszont meg kell értetni a másik oldallal, hogy ebből máshogy nem lesz egy sikeres, minőségi projekt, hogyha ők sem teszik bele az időt. Például ezt mi is tapasztaljuk, hogy lefektetjük a projekt elején, hogy mondjuk hány emberre, hány munkaórára lenne szükség ehhez. Itt még egyébként visszacsatolnék az előző mondandómhoz, ahol kifelejtettem egy fontos dolgot, ezt a megtérülést. Persze van olyan projekt, ami nem térül meg, lehet sok mindent forintosítani is, de fel kell tudni mérni, hogy megéri-e ezzel a projekttel foglalkozni, mert vannak olyan esetek, amikor nagyon nem, és mégis rengeteg időt tölt el vele a fejlesztő, vagy a fejlesztő cég. Abszolút átérzem és alá tudom támasztani, hogy az agilitás az nagyon nehezen működik. Ez még messzebb vezet, ez globális probléma is, legalábbis itt a régióban, vagy az országon belül mindenképpen, hogy a piacról rengeteg szakember hiányzik. Nálunk is nagyon kevés szerintem a mérnöki állomány ahhoz képest, hogy mekkora cég vagyunk. Nehéz rátenni egy tapasztalt mérnököt – és ez megint egy probléma – egy projektre, úgy, hogy nem dolgozik a cégnél jópár éve, nem látja át a működést, nincs megfelelő rendszerszemlélet, vagy IT oldalról rálátás a dolgokra. Ez mind olyan probléma, amikkel nem nagyon tudsz mit kezdeni. Edukációval lehet, edukálni kell az embereket, illetve reméljük, hogy ez majd egy öngerjesztő folyamat lesz, jönnek a fiatalok, ők ebbe szocializálódnak bele, valószínű, hogy ők már máshogy fognak viszonyulni ezekhez a dolgokhoz. Nyitottabbak az automatizáltságra, arra, hogy digitalizáljunk mindent. Az idősebb kollégák ezektől ódzkodnak.

Szűcs Dániel: – Ez az agilitás, ez szépen és jól hangzik, de ti is megfogalmaztátok, hogy van az, amikor újra van gondolva a program informatikai szempontból. Mikor már valaki megért az elhangzott igényekből valamit, összeáll egy olyan szoftvercsomag, ami azt meg is tudja valósítani, de valahol mindig picit elferdül a folyamat. Vagy a hátterében, vagy a frontback, tehát vagy az előtér, vagy a háttér mindig változni fog. Én így értem azt, hogy – nevezzük agilitásnak – az a fajta rugalmasság, az a fajta alkalmazkodóképesség az igazából mindig benne van, mert minden nem lehet fix. Ha azt mondja a felső vezetés, hogy ennyi pénz van rá, ekkorra legyen kész, és ez csinálja, az szerintem nagyon ritka, hogy mind a három megvalósul csorba nélkül. Természetesen van az az eset, meg minél jobb szakember valaki, annál jobban tudja ezeket a csorbákat kiküszöbölni, és annál kisebb csorbákat szenved ez a három pont. De mindig benne van, hogy van egyfokú tervezettség mögötte. Ha megvan az, hogy mennyi idő és mennyi pénz fog kerülni az adott probléma megoldására, én azt mondom, hogy van egy előzetes igény, ami kvázi olyan, mint egy előzetes projektterv, hogyha az reálisan van leírva egy papírra, egy Excelbe, egy kimutatásba, egy rendszerbe, akkor azt reálisan véghez lehet vinni. Hogyha az tartalmazza a megfelelő időt és megfelelő pénzt a program megoldására, akkor reálisan volt a cél meghatározva. Tehát itt az agilitásnak kevesebb szerepe van. Akkor, amikor valaki fehér asztal mellől eldönti, hogy gyerekek, nekem egy ilyen dolog fog kelleni, ennyi pénzt költenék rá, legyen meg jövő keddre. Tehát itt az agilitásnak elég nagy szerepe lesz, vagy az lesz a végeredmény, hogy három dologból három tényezőből valamelyik nagyon csúnyán fog sérülni, ha nem mindegyik. Nem azt fogja tudni, nem is annyiba fog kerülni, nem annyi idő alatt fog elkészülni. Az agilitás szerintem itt gyakorlatilag egy olyan hibamegoldó mechanizmusként folyamatosan jelen van, hogy valamelyik oldal, valamilyen információval, valamilyen jelleggel mindenféleképpen alkalmazkodni fog. Itt gyakorlatilag az agilitást nevezhetjük akárhogy, ha most azt mondom, hogy jövő hét keddig készüljön el, vagy ez év decemberéig készüljön el, és abban lesz ezer órányi túlóra, akkor az agilitás fellépett, mert én 8 órával és 200 nappal számoltam, de kijött belőle 250 napnyi munka azért, mert túlóráztunk hétvégén. Tehát az agilitás valahol mindig fellép. Ugyanez az, hogy nagyon sok esetben az igények is valamilyen szempontból változnak. Teljesen más szempont egy felső vezetés kérése, teljesen más, amit egy kolléga kér, ott is az agilitás nem mindegy, hogy melyik oldalon jelenik meg. Valamikor az egyik oldalnak kell alkalmazkodni, valamikor a másiknak, valamikor mindkettőnek picikét, valamikor meg egyik sem fog alkalmazkodni, mert megmondták, hogy ezt már tényleg meg kell csinálni és ennyi idő alatt, ennyi pénzből, hogy ott nincsen helye az agilitásnak. Ilyen szempontból azért jó, hogy négyen vagyunk a beszélgetésben, mert ti szoftver és szolgáltató oldalról ti alvállalkozókkal találkoztok, megrendelőkkel találkoztok, cégekkel találkoztok, akik valamilyen szintű fejlettségen vannak. Ádámmal mi gyakorlatilag az üzemi oldalról találkozunk, a kollégáknak az igényeivel, így picikét másabb az „erőviszony”, a kapcsolat, a kommunikációs felület pedig nagyon-nagyon más. Kettőnk között van egy óriási lépcső, mert azért a BorsodChem nem egy kis kkv. Más az igény, más a határozottsága, más a komolysága egy kérésnek, más a szó, amit tud mondani egy alvállalkozó a megrendelőnek, más az, amit ténylegesen egy 100-120 fős cégnél lehet mondani a kollégáknak IT vezetőként, hogy ez pedig így meg így lesz. Más a harmadik verzió, amikor egy akkora szervezet, akkora felső vezető mondja, hogy meg kell csinálni, gyerekek, 5-en, 7-en vagyunk, neki kell esnünk, keddre készen kell lennie. Nagyon sok aspektusból lehet nézni, nagyon sokfajta igény van, sokfajta igénynek megfelelően különféle csapatok különféle erőforrásokat tudnak megmozgatni. Van, amikor semmi nem változik. Szerencsés, ha jól lett megtervezve, mert ha már a tervfázisban be van vonva egy szereplő, aki legalább az egyik oldalt a két oldalból – a mérnöki vagy az informatikai oldal – legalább valamilyen szinten reálisan látja, és abból próbálunk meghatározni egy projektet, annak valószínűleg több realitása lesz. Ha valaki elkezd tervezni reális terv nélkül, akkor annak nem fogja senki megköszönni a végeredményét, mert a végén az lesz, hogy 200.000-t szántunk rá és azt terveztük, hogy hónap végén készen lesz. Nagyságrendi eltérések lesznek, mert 70.000.000 lesz közben a vége, és másik három csapatnak kell csinálnia 3 évig. Ezt emelném ki, hogy a terveknél próbáljunk meg minél több ilyen jellegű szakembert bevonni, mert az segíti a végkifejletet, reálisabb elvárásokkal indítja el a projektet.

Medve Ádám: – Én már csak egyetlen egy mondatot tennék hozzá, hogy egyébként az agilis módszertan tud veszélyes is lenni, főleg akkor, ha jól csinálják. Sajnos így van. Ha nincsenek jól meghatározva a hatókörök, és folyamatosan mennek a sprintek, és mindig kommunikáció van és finomítunk a dolgokon, akkor nincs vége a projektnek, nincs lezárva a projekt. Muszáj lezárni a projektet, kell hatókör, aztán lehetnek utána optimalizációs fejlesztések. De olyan nincs, hogy egy projektnek nincs vége. Van eleje és van vége. Ezt sok esetben nem értik meg a felhasználók, mert ők úgy vannak vele, jó hát most már ezt is tegyük bele, ha már beszélünk erről, meg még azt is, de ennek akkor soha nem lesz vége.

Laczkó Gábor: – Nagyon sok olyan terület kezdtetek el feszegetni, ami tipikusan nemcsak ebben az ipari területben, hanem a szoftverfejlesztés minden területén igaz szokott lenni. Egyébként valaki valahol mindig picit sérül. Nagyon sok ilyen vasháromszöget rajzol fel az ember, nekünk is például házon belül van egy ilyen vasháromszögünk. Három nagyon fontos dolog van, amire mi odafigyelünk. A megrendelőnek az elégedettsége, a belső csapatunknak a jóléte, illetve nyilván, hogy gazdaságos legyen, amit csinálunk. De ez bármilyen szereplőnél igaz tud lenni. Nagyon fontos tényezővé kezd feljönni, hogy a megrendelés, az ügyfélelégedettség az egy kardinális dolog. Ha körbenézünk manapság, hogy a piac milyen nehéz, és az embereket mennyire nehéz megtartani, fejlesztési szempontból igenis egy rettentő fontos dolog, hogy a saját csapatunk úgy dolgozzon, olyan körülmények között dolgozzon, hogy szeressen ott dolgozni, és ott akarjon dolgozni. Amellett pedig pénzügyileg egy olyan terméket tegyünk le, ami a vállalatnak megéri, és megéri azért dolgozni, hogy azt megtermelje. Tehát e három közötti finomhangolás nagyon fontos dolog tud lenni, hogy a fájdalmakat enyhíti, hogy nemcsak egyik oldalnak fáj, hanem lehet jó talán picit mindenkinek, és kis feladásokkal mindenki tud élni talán.

Medve Ádám: – Szerintem van még egy nagyon fontos dolog amiről nem beszéltünk, Attiláéknak valószínűleg nehezebb a helyzete, mint nekünk belsősöknek. Ez szerintem még egy jódarabig így is lesz. Ez a trend is nagyon érdekes, hogy én úgy látom, az, hogy most valaki külsőst vagy belsőst alkalmaz, vagy belsőleg épít ki egy szoftverfejlesztői csapatot, ez is változik. Én nem látom azt, hogy most éppen valamelyik oldalra eldőlne. Voltak olyan időszakok, amikor folyamatosan ment az outsourcing, most például látom azt, tapasztalom azt, hogy amilyen cégekkel kapcsolatban vagyunk, egyre inkább kezdik a belső fejlesztői vagy komolyabb üzemeltetői csapatokat újra kialakítani, ez a trend is érdekes illetve a bizalom. A belsős fejlesztőkkel szembeni bizalom mindig is nagyobb lesz, mint egy külsőssel. Jobban ismerik a területet, jobban megbíznak bennük, napi kapcsolatban vannak. A külsősökkel idő, míg kiépül a bizalom, ott egy kis problémát, egy kis hibát sokkal jobban a szívükre vesznek a felhasználók. Ez is szerintem egy kulcsparaméter.

Szűcs Dániel: – Abszolút. Ami ennek az elmúlt 20 percnek gyakorlatilag a megoldása, az az, hogy azon túl, hogy ezt valaki kollégákkal, megrendelővel, alvállalkozóval bármilyen módon csinálja, ott lennie kell egy projektmenedzsment jellegű megközelítésnek, hogy ott legyen vége a projektnek, valaki vezényelje a feleket. Ha van egy olyan fél, aki mindenkinél erősebb, esetleg egy felső vezető, saját főnökének nehezen mondja az ember, hogy ez eddig van, majd a következő hónapban beszéljünk egy másik projektről, mert ezt most így befejeztük. Tehát ha az erőviszonyok ténylegesen vannak megálmodva, és ott egy alvállalkozóval, egy társosztállyal, egy fejlesztővel úgy van megbeszélve, hogy ezt tartalmazza, és elkészült, és boldog mindenki, és majd beszélünk új projektről, akkor kevésbé lesznek sérülések. Az lehet, hogy szó szerint továbbra is nyújtják-nyújtják, mert eszembe jutott, hogy még ezt is, meg ezt is csináljuk meg. Ott vagy pótmunkát számlázunk egy idő után, vagy jönnek a többletköltségek, vagy új projekteket szül a történet. Ha van egy rendes menedzselés, akkor az elhangzott problémáknak a 70-80 %-a az nincs, hanem azt megfelelő helyén kell kezelni, és akkor azok nem problémák, hanem új lehetőség arra, hogy javuljunk, fejlődjünk, és mégsem érzi azt senki, hogy sérült. Hanem azt érzi, a fejlesztői oldalon, hogy van munka amivel foglalkozni kell, a megrendelői vagy műszaki oldalon meg azt érzik, hogy csináltunk egy ilyet rendszerben, ami segít nekem, hogy ilyet meg ilyet is meg tudjak csinálni. Ez egy nagyon optimista hozzáállás, egy nagyon optimista látásmód. Minden esetben sérül valaki, csak más szavakkal. Ha nagyon-nagyon lokálisan, körülhatároltan nézem az adott projektet, akkor igen, sérülnek benne a felek. Ha kicsit távolabbról nézem, cég szintjén, üzleti kapcsolat szintjén nézem, akkor pedig van hova tovább.

Masa Attila: – Igen, én nem véletlenül mondtam, amikor mondtam, hogy miért fontos szerintem egy pilot, és nem véletlen mondtam, hogy ez egy közös sikerélmény legyen. Ezzel is találkoztunk, ezt is látjuk, Gábor, amit említettél, hogy nyilván a fejlesztő csapat jóléte abból a szempontból kulcsfontosságú, hogy kvázi ők hozzák létre azt az értéket, amit el tudsz adni, és aminek örül az ügyfél. Ebből a háromszögből nem lehet egyik lábát sem kirúgni. A pilotnak tényleg ez is a célja, hogy ne csak az ügyfél lássa, és örüljön, hogy amit beígértünk a projekt elején, azt tudjuk teljesíteni, hanem mi is azt érezzük, hogy valamit letettünk az asztalra, az ügyfél örül neki, és valahova eljutottunk, van eredményterméke annak, amit csináltunk. Ez a projektnek az eleje. A másik, amit Ádám mondott, nagyon fontos gondolat, ez inkább már belső ember- illetve projektmenedzsment kérdés vagy feladat, hogy hol van egy projektnek vége. Mi is találkoztunk ezzel, fejlesztünk amit szeretnének, ők a tökéletes kódot, tökéletes szoftvert szeretnék elkészíteni. Nagyon sokszor a tökéletes előtti tizedik iterációban már az az üzleti eredmény létrejött, amitől az ügyfél boldog és neki nincs szüksége a maradék kilencre, amit olyan edge case-ekre optimalizálunk, amik lehet, hogy egy nagyon távoli jövőben következnének be. Nyilván ezzel nem akarom a kód minőségét elbagatellizálni, illetve, hogy nem fontos az, hogy jó minőségű szoftvert készítsünk, de ez egy nagyon nehéz feladat, hogy tényleg nem csak funkcionálisan húzzuk meg a határt az ügyfélnek, hogy az a zöld gomb nem fog ebbe a projektbe bekerülni, hanem egy következőbe, hogyha kifizeted. De hogy a csapatnak is hogy sikerül ezt lefordítani, illetve elmondani azt, hogy mi az a feltétlenül szükséges iterációs mennyiség, amivel mi már le tudjuk azt szállítani az ügyfélnek, ami neki értéket teremt, és amiért ő fizet. Nyilván ezt láttatni kell a fejlesztő csapattal, akár külső szolgáltató, akár belső. Ha ez egy cégen belül van, akkor is az ő eredményességüket legalább egyszer egy évben megvizsgálják, hogy érdemes-e ezt a részleget abban az adott cégben fenntartani. Ezeket tudni kell menedzselni, hogy egy projektnek hol van a vége, és mikor értük el azt az eredményt, ami elégséges. A harmadik dolog, ami eszembe jutott, ránézésre talán ti lehettek azok, mi ezt úgy szoktuk mondani, hogy minden gyárban kell egy helyi hős. A helyi hősök azok a szereplők, akik kellően érdekeltek ezekben a projektekben, változó, hogy milyen szerepet töltenek be. Volt már, hogy IT-st kaptunk, többnyire inkább a mérnökségből vagy a termelésvezetésből kapunk egy szereplőt. Általában ők belső projektmenedzserek, nagyon fontos, hogy őket kell igazán megnyerni, az a személy kell, aki tényleg elhivatott ebben a projektben, érti a belső üzleti problémát, nagyságrendileg, némileg konyít a technológiához, de nem probléma ha nem, azért vagyunk mi, hogy neki segítsünk. Az a tapasztalat, hogy 10 projektből 9 akkor volt sikeres, ha volt helyi hősünk, aki ezt tényleg akarta, értette, és házon belül átvitte, faltörő kosként mindent megtett azért, hogy a projekt érvényesülni tudjon. Sokkal jobb minőségű végeredményt tud garantálni, mint az a felállás, amikor a menedzsment ráerőlteti egy részlegre vagy személyre, hogy márpedig ezt meg kell csinálni. Ilyen szempontból a kapocs, illetve a kulcs az a személy általában, aki tudja képviselni mind a két oldalt, és fordítani egyik nyelvről a másikra szükség esetén.

Medve Ádám: – Nálunk a projektcsapat összetételét tekintve, a projektszervezet összetételét tekintve megvan a klasszikus értelemben vett projektmenedzser, megvan a felső vezetésből az a pár személy, akinek nyomást kell gyakorolni az adott szituációban, tehát hogy menjen, haladjon az a projekt. Van egy üzleti oldali felelős is, vagy üzleti oldali projektmenedzser, aki gyakorlatilag a projektnek a projektmenedzsere alá van besorolva, nálunk ő a helyi hős. Ő az, aki az üzleti oldalon, ha kell, szállítja az adatokat, szállítja az információkat. Kellenek, abszolút egyet értek veled. Ha odatesznek egy junior kollégát egy ilyen pozícióba, mi sem vagyunk vele előrébb. Ez egy olyan személy, aki átlátja a dolgokat, tapasztalt, tudja, hogy kihez és hogyan kell szólni. Kicsit ez egy people management is egyébként. Ezek nélkül nem lesz sikeres a projekt.

Szűcs Dániel: – Megfelelő alázattal kell hozzáállni a projekthez minden oldalról, így van.

Laczkó Gábor: – Az a helyzet, hogy nagyon sok témát megbeszéltünk, hogy miről fogunk beszélni, csak aztán az élet úgy hozta most, hogy eléggé belementünk egy-egy részterületbe. Lehet, hogy arra foglak kérni titeket, hogy egy következő beszélgetésben legyen egy második része ennek. Lassan a végéhez érünk most, azt mondjátok el nekem, mik most a best practice-ek, milyen rendszerek azok, amiket ti láttok magatok körül? Milyen olyan terültek vannak, amikre keresik most az ipari szereplők a megoldásokat? Vannak-e kitüntetett fókuszterületek, akár egységekben? Egy kis látképet kapjunk arról, hogy milyen digitalizációs folyamatok, fejlesztési folyamatok zajlanak akár nálatok?

Masa Attila: – Két fő fókuszterületet látunk, nyilván a gyártásdigitalizációnak általában az a fő célja, hogy valahol vagy költségmegtakarítást tudjunk elérni vagy bevételnövekedést. Nyilván kiadás és a bevétel közötti különbség a lehető legnagyobb legyen. Gazdálkodó szervezetnek ez a célja. Az a tapasztalat, hogy vannak piaci változások, aminek eredményeképpen lehet vagy kell bizonyos termékeket drágábban eladni. Sajnos ezt manapság megéljük, elég nehezen éljük meg, mert az infláció és egyéb hatások miatt minden drágul. De általában nem ez a megközelítés, hogy nézzük meg, hogy mitől lesz a termék drágább, hanem nézzük meg azt, hogy hogyan lehet a gyártási költségeket csökkenteni, nyilván, ami a kiadásainkat tudja redukálni. Ahol mi mozgunk, a gyártósor és a gépek közelében most abszolút keresett portéka a gépeknek a hatékonyságmérése. Nem egy teljesen újkeletű fogalom, ez a bázisa annak a feltérképezésnek, aminek az eredményeképpen szeretnék majd megtudni a gyárak. Ez még nem az a lépés amikor a költségeket csökkentjük, ez az a lépés, amikor szeretnénk megtudni, hogy egyébként most mennyire gyártunk hatékonyan, és azt szeretnénk objektíven mérni. Azt láttuk, hogy erre nagyon sok cégnek volt már valamilyen Excel táblája, ami tudott nekik OI-t számolni, és a menedzsment főleg ha cégcsoportról van szó akkor a hó végén kiküldött egy Excelt, amiben az új értékek voltak, amit a felső vezetés örömmel fogadott. Aztán vagy úgy van a valóságban vagy nem. Egyre több helyen szeretnének erre egy objektív mérőrendszert, beépítve a gyártást, ami megmondja, hogy most milyen hatékonysággal megy a gép. Amikor meg nem megy olyan hatékonysággal ahogy terveznénk, vagy szerettük volna, akkor pedig miért? Ott jön az, hogy feltárjuk, hogy milyen gépállapotok idéződtek elő azon a berendezésen, milyen hibák keletkeztek, azok a hibák mennyi megállást okoztak, adott esetben milyen egyéb anomáliák, külső behatások okozták azt, hogy nem volt a gép annyira termelékeny. Ezek közül is, ha még egyet ki lehet emelni, és erre vannak statisztikák is, akkor ténylegesen a nem tervezett gépmegállások azok, amik világszinten a legnagyobb veszteséget okozzák az összes gyár számára. Ha nagyon erősen kell fókuszálni, akkor a nem tervezett gépmegállások redukálása az, amiben most mindenki szeretne előrelépést elérni. Vagy a hatékonyságot mérjük, és annak az argumentumait próbáljuk feltárni. Volt olyan ügyfelünk is, ez nyilván gyártási környezet függő, ahol kifejezetten robotokhoz készítettünk diagnosztikai rendszert, amivel azt lehetett vizsgálni, hogy ezeknek a meghibásodása be fog-e esetleg következni egy nem várt időpillanatban. Ez az, ami mindenkit leginkább érdekel. És az, hogy a papírokat és az Excel táblákat el tudjuk hagyni, és legyen egy egységesített platform, vagy felület, ahol ezek a gyártási adatok elérhetőek, riportálhatóak. Értesítést tud küldeni, ha bármilyen olyan esemény bekövetkezik, amiről szeretnénk tudni azonnal. Mi ezekkel találkozunk, és nyilván itt a pontos feature-nek a meghatározása, illetve az, hogy ezt 1 gépre csináljuk vagy 500-ra, ez gyáranként változó. A végcél azt lehet mondani, hogy mindenhol ugyanez. De mindjárt a többiek megcáfolnak, ha nekik nem ezek a céljaik.

Medve Ádám: – Én nagyon nagy bajban lennék, ha most egy-két fókuszpontot kellene mondanom, mert egyébként rengeteg terület van, ahol lehetne fejlődni és előrelépni. A karbantartás az egyik ilyen, amit Attila is említett, tehát nálunk ugye TMK, tehát tervszerű megelőző karbantartás, ami nagyon fontos, hiszen ezzel rengeteg kisleállást, üzemleállást meg lehet előzni. Nálunk egy-egy üzemleállás rengeteg profitkiesést jelent. Az viszont töredéke, ha megfelelő időben karbantartjuk a berendezést, nem várjuk meg, hogy tönkremenjen. Erre ráépülve nálunk folyamatban van egyfajta prediktív karbantartás is. Próbálunk forcastokat csinálni, nálunk a vállalatirányítási rendszer egy verzióváltáson megy keresztül, az új rendszerben lesznek RPA funkciók, tehát ilyen robotizált folyamatautomatizálás. Az automatizálás, a folyamatos digitalizáció, amikor kiejtik az emberek az Ipar 4.0-t, az IoT-t vagy olyan buzzwordöt, ami megijeszti az embert, hogy ebbe sok mindent belegondolnak. Egyébként nagyon apró dolgokkal el lehet érni rengeteg mindent. Az állványmenedzsment rendszerünket hoznám példaként, amit digitalizáltunk, reformáltuk meg és optimalizáltuk is a folyamatot. Nem kell nagy dolgokra gondolni, nem volt benne semmi különös. Növeltük a transzparenciát, a folyamatot optimalizáltuk, és óriási megtakarításokat lehetett elérni. Nem kell mindig nagyot ugrani. Nálunk ez is probléma szokott lenni, hogy nincsenek meg a lépcsőfokok, nagyon nagyot akarunk ugrani és ott sem mindig lesz sikeres a projekt. Nekünk van egy termelésirányítási rendszerünk, nagyon meg vagyunk elégedve, adatgyűjtés szempontjából. Sok adatot gyűjtünk, generálunk, ez nem elég, ezzel valamit kezdeni is kell. Ezeket vizualizálni kell. A transzparencia nagyon fontos. Amit ugye mondott Attila, hogy lássuk, hogy adott technológiai területtel vagy egy berendezéssel van a gond, tehát hogy lássuk, hogy hol van a probléma, az legyen vizualizálva, legyen valamilyen analitika. A mi érettségi szintünk nem tart ott, hogy mesterséges intelligenciát alkalmazzunk még erre, de nyilván ezek a rövidtávú terveink, hogy előbb-utóbb ezt is bevezessük, hiszen ezekkel is óriási megtakarításokat lehet elérni. Ugyan ez a megoldás nem olcsó, de valószínű hosszú távon jóval inkább megtérülő, főleg egy ekkora termelő gyár esetében. Nálunk például a selejtet nehéz értelmezni, ugyanis mi termelők vagyunk. Ez is egy nagyon fontos eleme az optimalizálásnak meg a hatékonyságnövelésnek, a költségmegtakarításnak, a profitnövelésnek, ezekkel csak egyetérteni tudok. Nekünk vannak még fókuszban – mivel azért veszélyes üzem vagyunk – balesetmegelőző intézkedések, illetve olyan projektek, amik segítenek ebben. Olyan kamerákat szeretnénk a jelenlegi stratégiai partnerünkkel alkalmazni, amik már fel vannak vértezve mesterséges intelligenciával. Le tudják követni, hogy egy adott munkavállalón ott van-e a védőfelszerelés, megfelelő védőfelszerelést használ-e vagy adott területen nincs-e esetleg túl sok munkavállaló, túl sok dolgozó, vagy mondjuk csöpögések, kifújások felderítése, füst, páralecsapódás, tehát ezeket mind jelezni időben előre, és beavatkozni. Mert veszélyes üzem vagyunk, nekünk egy ilyen baleset óriási kockázat.

Szűcs Dániel: – Nálunk, ami van, relatíve általános igények. Gyakorlatilag költségcsökkentések, állásidők csökkentése, szűrése, mihamarabbi megoldása, a rendszerből történő adatok helyességének a biztosítása a rendszerbe és azoknak a visszatöltése. Viszonylag általános projektkörnél tartunk, ennek az általános fejlesztése. Nálunk viszonylag rövid a lista. Összes többi terület természetesen mindig megvan, mert a biztonság is fontos, a fejlődés is fontos, a pénzügy is fontos, a controlling is fontos, ez mindegyik megvan nálunk is.

Laczkó Gábor: – Nagyon szépen köszönöm nektek ezt a beszélgetést. Rengeteg téma merült fel még az utolsó mondataitok kapcsán is, akár a későbbi blockchain alapú adathitelesítés vagy emlegettétek a mesterséges intelligenciát, hogy ezeknek milyen szerepe lesz. Ez vélhetően egy következő beszélgetésnek lesz a témája. Nagyon szépen köszönöm nektek, nagyon sok sikert kívánok a mostani projektekhez, és a munkátokhoz. Remélem, hamarosan tudjuk ezt a beszélgetést is folytatni.

Szűcs Dániel: – Köszönjük szépen mi is.

Masa Attila: – Mi is köszönjük.

Medve Ádám: – Köszönjük.

Laczkó Gábor: – Köszönöm, sziasztok!

Masa Attila: – Sziasztok!

Medve Ádám: – Sziasztok!

Szűcs Dániel: – Sziasztok!