Nagy Géza: – Szeretettel köszöntök mindenkit, én Nagy Géza vagyok, a Protechtor-események egyik főszervezője, és a Stylers munkatársa. A mai alkalommal Fodor Szabolcs, a United Consult Data-csapatának vezetője, és Masa Attila, az Indeveyes vezetője fognak beszélgetni a Data Science ipari alkalmazásáról, elképzelésekről és realitásokról, valamint számos gyakorlati szempontról, ami felmerülhet a kérdéskör kapcsán. Köszönöm szépen, hogy itt vagytok velünk, és elfogadtátok a meghívásunkat!

Fodor Szabolcs: – Sziasztok, köszönjük szépen!

Masa Attila: – Sziasztok, mi is köszönjük szépen a lehetőséget, Géza bevezetője után vágjunk is bele. A mai napon, illetve a mai webináron alapvetően Szabolccsal fogok beszélgetni, én leszek a téma-, illetve kérdésindikátor, és Szabolcs pedig igyekszik nekünk az eddigi tapasztalatai alapján ezekre a kérdésekre, felvetésekre releváns válaszokat adni. Azt előirányozhatjuk – talán Szabolcs, megengeded, hogy ezt így mondjam –, hogy két, az iparágban dolgozó egyéniség találkozott a személyünkben, úgyhogy tényleg igyekszünk majd a lila ködöt olyan tekintetben eloszlatni, hogy érdemi értékekről, illetve érdemi eredményekről beszéljünk, és ne mindig csak azt hangoztassuk, ami már alig fér bele az Ipar 4.0 katalógusokba. Úgyhogy ennek első csapásaként én azt gondolom, hogy némi fogalom-, illetve definíció-karbantartást tegyünk meg, és tisztázzuk azt, hogy tényleg ebben a nagy lila ködben a trendi szavak mögött valójában mi rejlik, és melyiket hogyan kell értelmezni. Egészen konkrétan itt arra szeretnék rákérdezni, vagy szeretném, ha tisztáznánk, hogy a data science, a machine learning, illetve az artifical intelligence milyen viszonyban van egymással, milyen hierarchiában vannak egymással, egyáltalán mit jelent az egyik, mit jelent a másik. Mert szerintem ezek nagyon-nagyon könnyen és gyorsan összemosódnak a laikusok, de talán még a kevésbé laikusok fejében is.

Fodor Szabolcs: – Igen, hát ez egy nagyon jó kérdés. Gyakorlatilag mindent használunk ma már, marketing anyagokban előszeretettel használjuk a mesterséges intelligenciát, mert most talán az a legszexibb fogalom így az adatos világban. Nagyon szoros kapcsolatban állnak egymással, én azért óvakodva használom bármelyiket is, igazából azért, mert talán sokszor túlzó az a fogalmi magyarázat, ami ezek mögött van. Az artifical intelligence-re azt gondolom, hogy tekinthetünk úgy, mint – a nevében is benne van: mesterséges intelligencia – valahol az emberi intelligenciának a leképezése valamilyen gépi rendszerre, ezt szeretnék ezzel elérni, és tényleg nagyon sok terjedelem belefér ebbe a fogalomba. Valójában a machine learning is ennek a része, tehát gyakorlatilag a machine learning, a gépi tanulási algoritmusok, az egyik olyan megoldási módszer, amivel ezt az úgymond mesterséges intelligenciát el tudjuk készíteni. Nyilván a gépi tanulásnak is nagyon sokféle alfaja, alcsoportja van, mondjuk úgy, hogy a munkánk során egyébként 80 %-ban az egyszerűbb gépi tanulási algoritmusokkal találkozunk, tehát a regressziós klaszterezési eljárások tekinthetők ennek. Nyilván, amikor azt mondjuk, hogy a mesterséges intelligenciát szeretnénk valamilyen géptanuló algoritmussal előállítani, akkor már inkább a mélytanuló algoritmusokra, a reinforcement learning algoritmusokra tudunk gondolni. Ha veszünk egy példát, hogy képes egy gép megtanulni sakkot játszani, hogy hogyan tudja ezt megtanulni, hát nem egy egyszerű regressziós vagy egy diszkrét változós eseményekre tanított modellel, hanem gyakorlatilag peremfeltételek mentén képes öntanulásra egy ilyen modell, és gyakorlatilag megtanulja, hogy bizonyos állások esetén hogyan kell majd a következő lépést megtenni. Ezek az algoritmusok tekinthetők olyan gépi tanulási módszereknek, amelyek valamilyen szinten az emberi intelligenciát, gondolkodásmódot próbálják leképezni. És hogyan kapcsolódik ide a data science, a data scientist? Ez alapvetően egy ilyen szakmai gyűjtőfogalom, ezt én nagyon nem szeretem használni, bár most szintén egy elég szexi téma, ugye a data scientist-ek azok, akik képesek gépi tanuló algoritmusokat fejleszteni. Én úgy tekintek erre a data science-re, mint gyűjtőfogalom, mert a saját csapatunkban is azt látjuk, hogy azt a szerepkört, amit meg kellene testesítenie egyben egy data scientist-nek, azt azért nagyon nehéz egy emberként teljesíteni. Gondolhatunk itt arra, hogy kell valamilyen technológiai tudással rendelkeznie, adatbázisokat tudnia kell kezelni, ismernie kell a tanuló algoritmusok fejlesztési módszerét, de egyébként nem árt, hogyha tud adatot vizualizálni, prezentálni, egyébként üzleti megrendelőkkel is egyeztetni, hogy megértsék, hogy az üzleti igények és az adatok között milyen kapcsolat van. Szóval, hogyha ezt így felírjuk egy lapra, és elkezdünk azon gondolkozni, hogy ezt melyik kollegánk tudja teljesíteni, akkor azért nagyon nehéz azt mondani, hogy van olyan kollega, aki mindenben kitűnően működik, persze ez nem is baj. Tehát mi tényleg úgy tekintünk erre a fogalomra, mint egy jó gyűjtőfogalomra, és ezen fogalom alatt különböző szerepkörökkel töltjük fel ezt a skill-készletet. Remélem ezzel tudtam segíteni egy kicsit így a fogalmak tisztázásában.

Masa Attila: – Abszolút. Mindenképpen tisztábban látom. Annyi reflexió, hogy ugye említetted, hogy a data science mint gyűjtőfogalom, illetve mint gyűjtő tudáscsomag, rendkívül szerteágazó kompetenciacsomagot igényel. Ez kicsit hasonló, mint amikor egy szoftverfejlesztő céghez full stack fejlesztőt keresnek, és mire felsorolják, hogy mit szeretnének, kiderül, hogy kell egy komplett IT department. Egyébként az Ipar 4.0-ban általánosságban, mint ilyen fejlesztésekben, újra és újra előjön, hogy itt nagyon széles az a tudáskészlet, amire szükség van egy ilyen feladat megoldásához. Erre majd még később visszatérünk. Ha már így a fogalmakat tisztáztuk, ragadjuk ki őket egyesével vagy akár összességében is. Azt szerintem már az utcán járó hétköznapi ember is tapasztalta, hogy a mindennapi életünkben a commerce alkalmazásokban – legyen ez közösségi média vagy bármilyen más mindenki által használt alkalmazás –, ha nem is tudjuk, hogy valójában dolgozik mögötte valamilyen tanuló algoritmus, vagy mesterséges intelligencia, de mint eszközkészlet jelen van. Azért ez tudvalevő, hogy a motorháztető alatt például azzal, hogy célzott hirdetéseket kapunk egy közösségi média felületen, már ez dolgozik a mindennapi alkalmazásokban. Mi a helyzet az iparban? Mennyire ígérik még ezt egyelőre a katalógusok, vagy mennyire alkalmazzák ténylegesen már ipari környezetben ezeket az eszközöket?

Fodor Szabolcs: – Oszlassunk el lila ködöt már az elején, igazából én személy szerint reprezentatív mintával azért nem tudok szolgálni, de szerencsére vannak olyanok, akik dolgoztak azért, hogy az Európai Unióban legyen egy ilyen mintánk. Ezt a linket majd szívesen megosztom az előadás vége felé chatben. 2020-ban az EU készített egy ilyen AI adaption felmérést, ami gyakorlatilag az Európai Unión belül működő kis-, közép- és nagyvállalkozásokat kérdezte meg arról, hogy az adott szektorban működő vállalat milyen AI-megoldásokat alkalmaz, és akkor itt most alapvetően igen, a gépi tanulási algoritmusokról, vagy azokról a megoldásokról beszélünk, amik adatalapon valamilyen formában hozzájárulnak a vállalat működéséhez, termékeihez. Ez egy nagyon átfogó és részletes tanulmány, gyakorlatilag a tanulmány végén országszinten le van bontva, hogy az adott országban mi az átlagos visszajelzés erről, milyen nehézségekkel küzd az adott ország. Tényleg érdemes átfutni, akit így érdekel valamilyen szinten a téma. Hogy konkrét választ adjak, ebben a tanulmányban az a megállapítás született, hogy a megkérdezett vállalatok 42%-a alkalmaz valamilyen adatalapú megoldást a működésében, és ha ezt konkrét iparágra nézzük meg, akkor az ipari szektorban gyakorlatilag ez 38%, tehát közel van az átlaghoz. Sajnos ez nincs lebontva Magyarországra, de azt gondolom, hogy nagyjából hasonló. Talán a magyarországi átlag alacsonyabb, mint az európai, és azt gondolom, hogy az ipari szektorban is hasonló különbség található az átlaghoz képest. Tehát mondjuk azt, hogy 10-ből 3 vállalat valamilyen szinten alkalmaz ilyen megoldást. Én azt gondolom, hogy jelenleg sokkal nagyobb a hype ekörül, és inkább az a helyzet, hogy nagyon sokan beszélnek róla, szeretnék ezt alkalmazni, van nyitottság ebbe az irányba, de a valóság egy kicsit árnyaltabb. Azért, mert a konkrét terepről jövő tapasztalatok azt mutatják, hogy pontosan ez a helyzet, hogy igény van rá, hogy elindult ebbe az irányba mozgolódás itt a piacon, de nagyon sok nehézség akadályozza azt, hogy ezek az alkalmazások úgymond egyik hónapról a másikra alkalmazásba vehetők legyenek egy ilyen nagyvállalatnál.

Masa Attila: – Köszi. Az említett nehézségekre még azért visszatérünk, és ezt mindenképp boncolgatjuk, mert abszolút hasznos lenne mindenki számára, hogy lássák, mik azok az akadályok, amiket le kell gyűrni egy ilyen projekt bevezetése előtt vagy bevezetése közben ahhoz, hogy eredményre jussunk, és üzleti értéket tudjunk teremteni a vállalatunk részére. Kicsit beszéljünk arról, hogy kik azok a vállalatok, mik azok az ipari szegmensek, területek, ahol egyfelől már nyomokban megtalálható az adatvezérelt működés, másfelől egyáltalán szóba kerülhet, vagy érdemes arról beszélni, hogy adatok elemzésével teremtsünk valamilyen számukra fontos értéket. Persze lehetne evidens a válasz, hogy ez mindenki számára fontos, és ugye az ipar 4.0, és az IoT világába az egy kulcsfontosságú tényező, hogy rendelkezzünk digitális adatmennyiséggel, illetve rendelkezzünk olyan adatbázisokkal, amik a cég működésével kapcsolatban – és ez legyen akár termelési oldal, vagy legyen akár az office-szint – utána tudunk különböző riportok, következtetések mentén megfelelő intézkedéseket, akciókat eszkalálni. Mégis mik lennének azok az ipari alkalmazási területek, amik szóba jöhetnek? Itt beszéltünk iparágról, mint például az autógyártás vagy a biotechnológia, vagy konkrét use case-ket is felsorolhatnánk esetleg, gondolok itt mondjuk a predictive maintenance-re, vagy a gyártási hatékonyság növelésére,  amik egy-egy ilyen alkalmazásnál a fókuszba kerülhetnek. Mik ezek szerinted?

Fodor Szabolcs: – Gyakorlatilag a data  science eszközrendszer, vagy szoktam használni ezt a kifejezést, hogy nekünk van egy ilyen kis ládácskánk, amivel megyünk szerelni, tehát hogy van egy eszközkészletünk, ami igazából fel tudunk használni különböző problémák megoldására, és nem akarom a lila ködöt építeni, de gyakorlatilag a végtelen lehetőségek halmaza, hogy mire lehet használni. Nyilván mindig az a kérdés, hogy érdemes-e, tehát van-e akkora hozzáadott értéke egy adott alkalmazásnak. Ha nagyon azt keressük, hogy mik azok a legtrendibb alkalmazások, amik egyébként úgy látjuk, hogy hozzáadott értékkel bírnak, és ezt tanulmány is alátámasztotta, elsősorban a folyamatoptimalizálás, folyamatautomatizálás volt az a terület, amiben ezek az ipari területen működő vállalatok valamilyen mesterségesintelligencia-megoldást alkalmaztak. Tehát hogyha ezt vizsgáljuk, akkor elsősorban a gyártáshatékonyság-növelés, ami a kulcs. Nyilván itt iparágon belüli működéstől függ, hogy ez most mit takar abban az esetben, ha ez egy konkrét termék előállítása. Akkor a selejtarány-javítás, ami hatékonyságot növelhet úgymond a gyártás során, vagy a konkrét gyártott mennyiség egységnyi időn belül legyártott mennyiségnek a javítása. Hogyha abból indulunk ki, hogy van egy alapanyaghalmazunk, amiből egy bizonyos mennyiséget szeretnénk legyártani, és ez a mennyiség ingadozik valamilyen véletlenszerű vagy nem véletlenszerű események hatására, akkor például megpróbáljuk megérteni, hogy milyen hatások okozzák azt, hogy az elvárt mennyiségből kevesebbet tudunk egy bizonyos egységnyi alapanyagból legyártani. Szóval, ha ezeket a kvázi ilyen nagyon standardizált eseteket vesszük, akkor ez egy tipikus olyan megoldási iránya vagy olyan alkalmazási iránya a mesterséges intelligenciának, a gépi tanulásnak, amivel például ipari területen lehet hozzáadott értéket eredményezni. Ugye a másik, ez alapvetően termelésoldali, tehát amikor arra vagyunk kíváncsiak, hogy az egységnyi idő alatt egységnyi mennyiségből mennyi értéket tudunk aztán eladni, kvázi a bevételnövelés az optimalizálásnak a célszáma – mondjuk így. Van egy másik megközelítés, ez a predictive maintenance témaköre, amikor az adott üzemet üzemeltető területnek van egy fontos KPI-a, hogy nyilván egyrészt konstans rendelkezésre álljon az a gyártási terület vagy eszköz, és ugye mi jöhet itt szóba, vagy mi akadályozhatja ezt meg. Nyilván ha kell valamit cserélni a gépen, fel kell újítani, vagy egyszerűen csak a karbantartás is bizonyos gépeknél egy több hetes folyamatot jelenthet. Az, hogy ezeket minél hatékonyabban tudjuk ütemezni, illetve ennek a karbantartásnak, gépcserének a költségét minimalizálni tudjuk, ilyen esetekben mondjuk azt, hogy predictive maintenance, tehát hogy például előre tudjuk jelezni azt, hogy valamilyen gép el fog majd romlani. Vagy akkor végezzük a karbantartást, amikor annak valódi igénye van, és ne mondjuk, csak azt tegyük, hogy félévente, évente ütemezett karbantartásokat végzünk, aminek vagy az lesz a következménye, hogy túl gyakran végezzük és költséges, vagy túl ritkán és azért hamarabb tönkremegy egy gép. Ebben a predictive maintenance, mint egy ilyen általános megközelítés vagy alkalmazási mód egy kifejezetten gyakran használt gépi tanulási alkalmazás. És akkor itt most még nagyon a gyártásra fókuszáltunk, de nyilván ezeket a termékeket értékesíteni kell a piacon. Hogyha egy kicsit eltávolodunk a konkrét gyártási területről, akkor egy ilyen nagyvállalatnál ugyanúgy szóba jöhet a kereskedelmi oldalon például a termékárazás, a sortiment-alakítás, vagy éppen a kiszállítás, a logisztikai témákkal kapcsolatos problémák. Ami már tényleg nem konkrétan a gyártási alkalmazása egy ilyen algoritmusnak, mégis ugyanebben az intézményben, ugyanebben a vállalatban ezeket az eszközöket más-más szempont szerint is lehet használni és hasznosítani, és ezzel értéket teremteni.

Masa Attila: – Egy kicsit még menjünk vissza az origóra, illetve a nulladik lépésig: elkezdtünk egy-két tézist itt felvázolni az adatelemzés kapcsán, de hogyha tényleg visszamegyünk a kezdőpontra, akkor egyáltalán nagyon fontos, hogy legyenek adataink, legyenek megfelelő mennyiségben, és főleg megfelelő minőségben olyan adatok, amin utána bármilyen tetszőleges elemzést tudunk futtatni, és következtetésekre jutni. Mik a tapasztalatok az adatok rendelkezésre állása terén? Az a kérdés, hogy azok a cégek, akik titeket megkeresnek, és adott esetben már lehet, hogy így keresnek meg, hogy akkor majd szeretnénk venni egy AI-t, jelentsen ez bármit is. Tisztában vannak-e azzal, hogy nekik az adatok olyan formában és mennyiségben rendelkezésre állnak-e ahhoz, hogy azzal érdemben lehessen elemzéseket futtatni? Vagy adott esetben egy ilyen igény drive-olja-e azt, hogy ezeket az adatokat előteremtsék akár a gépről, akár máshonnan? Illetve, hogy egy projekt indulásánál mennyire tudjátok ezt ügyféllel vagy ügyfél nélkül felmérni, hogy a rendelkezése álló adatmennyiség alkalmas ezeknek a céloknak a kiszolgálására?

Fodor Szabolcs: – Hát, ha a valósággal szembesülni szeretnénk és álomgyilkost keresünk, akkor talán ez az a pont, amit így muszáj kiemelni. S talán a legfontosabb, már csak azért is, mert él az a közhely, hogy az ilyen algoritmusoknak a hozzáadott értéke vagy a pontossága, jósága az 80%-ban az adatoktól, az adatminőségtől függ és 20%-ban attól, hogy milyen modellt alkalmazunk. Ez egyébként nemcsak hogy közhely, ezt így a működésünk során is gyakran tapasztaltuk, hogy nem azon múlik, hogy mekkora a hozzáadott érték, vagy mennyire lesz pontos a végeredmény, mennyire használható, vagy az algoritmust mennyire tudjuk jól optimalizálni, sokkal inkább attól függ, hogy milyen adatok állnak rendelkezésre, mennyire tiszták ezek az adatok, mennyire fedik le jól azt a problémát. És hát sajnos ebben az a tapasztalat, hogy van hova fejlődni, ami nem baj. Nyilván a motiváció megvan, de nagyon sokszor találkozunk azzal, illetve még a kisebbik probléma az, hogy a vállalaton belül adatsilók vannak, tehát különböző területek, tekintsük ezt a gyártásra, minőségbiztosításra, kereskedelmi oldalra, ezek a területek saját adatsilókat alakítanak ki. Nyilván ők nagyon jól ismerik a saját adatközpontjukat, vagy alközpontjukat, ismerik a domaint, ismerik az amögött lévő adathalmazt, annak hiányosságait, anomáliáit, összefüggéseit, és ezekkel jól elvannak. De amikor az a kérdés merül föl, hogy a gyártást és minőséget, a gyártáshatékonyságot a minőségi kritériumokkal együtt szeretném vizsgálni, és ezeket az információkat össze kell vetnem, akkor jön az első probléma, hogy egyáltalán mennyire tudom megfeleltetni egymásnak a két adatbázist. Vajon ha elém öntenek egy ilyen silóban elhelyezkedő adattáblát, akkor ismerni fogom-e egyáltalán, hogy ott milyen adatok vannak, vagy az elemző kollega ismerni fogja-e, hogy az az adott mező mit tartalmaz, és azt hogyan kell értelmezni. Tehát van-e konkrét data glossary, data governance feladatokat ellátnak-e. Itt megintcsak egy olyan problémahalmazt említettem, ami méginkább a jobb helyzetet takarja. Legtöbbször az a nehézség, hogy egyszerűen ezek az információk, ezek az adatok a gyártógépeknél maradnak. Tehát nincsenek – még csak adatbázis szintig sem – például egy gyártósornál a különböző gépekről gyűjtött információk összerendelve, historikusan eltárolva, hanem a gépeken áll rendelkezésre bizonyos ideig, és azzal szembesülünk, hogy ahhoz hogy egyáltalán elemezhessünk, ezeket az adatokat valamilyen formában ki kell nyerni. Erre hadd mondjak egy nagyon rossz példát: egy autóipari alkatrészeket gyártó cégnél láttunk egy ilyet, hogy egy gép alatt lévő asztali számítógépből egy pendrive-val szépen lementették a gépen lévő adatokat, vagy az adott rendszert irányító szoftveren lévő adatokat, és aztán átsétáltak vele egy másik géphez, oda bedugták és akkor onnantól kezdve lehetett elemezni. Szóval nyilván ilyennel is találkozunk sajnos, és nem mondom, hogy itt lehetetlen adatalapon valamilyen hozzáadott értéket biztosítani, de képzeljük el, hogyha például heti rendszerességgel kell predikció, vagy akár napi rendszerességgel akarunk valamilyen modell alapján, vagy az adatokból nem is modellel, hanem valamilyen egyszerű szakértői döntési fával információkat szolgáltatni, akkor valakinek mindig sétálgatnia kell egy pendrive-val, ami lássuk be, egy kicsit megnehezíti ezt a működési folyamatot. Én azt gondolom, hogy amikor egy ilyen projektigény felmerül, akkor elengedhetetlen, hogy már az igényt megfogalmazó vállalati terület vagy szakterület, vagy éppen aki ezt menedzseli, egy ilyen igény összegyűjtését, már házon belül készítse elő azt, vagy gyűjtse össze, hogy milyen információk állnak rendelkezésre. Egyébként a projektjeim során nemcsak adatelemzéssel vagy modellfejlesztéssel foglalkoztunk, sőt, elsősorban inkább az adatoknak egy központi data lake-be való integrációjával foglalkoztunk a legtöbbet. Hogyha valakinek van ilyen törekvése, hogy ezek az adatok integrálva elérhetők legyenek, akkor ez mindig felmerül, hogy oké, de ez miért jó, miért fektessünk abba erőforrást, hogy ezeket az adatokat valamilyen központi data lake-ben összerendezve tároljuk. Hát igen, ilyenkor jönnek az üzleti use case-ek, hogy azért van erre szükség, mert egyébként, ha ezeket az információkat ismerem, akkor tudok hatni a gyártáshatékonyságra, és akkor ilyen site projecteken keresztül gyakorlatilag meg lehet ezeknek az engineering munkáknak az értékét támogatni egy kicsit, üzleti haszonnal. Így nagyobb a motiváció arra, hogy ezek az adatintegrációk elinduljanak. Nem tudom mennyire sikerült megválaszolni a kérdést, illetve hogy milyen tapasztalattal bírsz mondjuk te ezen a területen, mert ha jól sejtem az előzetes beszélgetésből kiindulva itt azért én azt éreztem, hogy mi inkább az adatok feldolgozásáért, elemzéséért vagyunk felelősek. Attila, nektek ez a gépekhez közeli adatgyűjtés-integráció volt a szakterületetek, vagy ez a szakterületetek, ebben azért bőven rendelkezel te is tapasztalattal. Nem tudom, hogy hasonlót láttál-e?

Masa Attila: – Igen, abszolút. Gyakorlatilag nekünk pont ez az a fókuszterület, ahol otthonosan mozgunk, és pont emiatt van még bőven potenciál az ügyfelekben, illetve a mi szolgáltatásunkban. Ugyanis nagyon sokan szeretnének digitális eszközökkel gyártáshatékonyságot fejleszteni, de ezt a nulladik lépést segítünk nekik megtenni, hogy egyáltalán az adatokhoz hozzájussanak, amiből utána már lehet különböző következtetéseket levonni. Úgyhogy mindenképpen meg kell tenni ezt a lépést ahhoz, hogy utána bármi más szóba jöhessen. Illetve a másik, ahogy mesélted egyébként, hogy mekkora hozzáadott értéke van egy tanuló algoritmusnak a végén úgy arányosan ahhoz képest, hogy a jó minőségű adatokat elő kell állítani, rendelkezésre kell bocsátani, majd egy adattudósnak ezt kell tudnia értelmezni. felcímkézni. Ebből is látszik, hogy milyen széles kompetenciacsomag kell tényleg ahhoz, hogy egy ilyen feladatot kompletten meg lehessen oldani. És maga az algoritmusfejlesztés nem feltétlen mindig az oroszlánrésze ennek. Kicsit beszélgessünk még erről, hogy főleg inkább ügyfél-, vagy vállalati oldalról mennyire van meg jelenleg az a szakértői brigád, aki egy ilyen projekt előkészítéséhez, bevezetéséhez, és későbbi koordinálásához szükséges. Szintén személyes tapasztalatból mi azt látjuk, eleve az OT és az IT között, hogy elég széles szakadék tátong. Ugye az OT az Operation Technology az lent szorgoskodik a gyártósoron, az IT pedig valahol általában az irodai szinteken mozog, és a gyártósoron inkább a klasszikus mérnökség van – most egyszerűsítsük le a megfogalmazásokat –, az IT-nál pedig ott vannak az informatikusok. Igazából az elmúlt, vagy mondjuk úgy, hogy a napjainkat megelőző munkahelyi szocializációs rendszerben egészen más területeken dolgoztak ezek a szakemberek, valószínűleg néha beszélgettek, amikor egy mérnöknek például Windows telepítési problémái voltak, de alapvetően azért nem igazán volt uniója az ő tevékenységüknek. Viszont ezek a témák, amikről most beszélünk, adatgyűjtés, adatoknak a feldolgozása, ez gyakorlatilag már mind a két csoportot érint. Mi sokszor azt tapasztaljuk, hogy azért ebben van bőven kihívás, hogy ők egymást házon belül megértsék, és közösen próbálják azt megérteni, vagy hát próbáljuk velük megértetni, hogy valójában nekik milyen lépéseken kellene átvinni a szervezetüket ahhoz, hogy egy-egy ilyen projekt bevezetésre kerülhessen, és a végén tényleg azokat az eredményeket szállítsa, amikre nekik szükségük van. Hogy látjátok, mennyire vannak erre a cégek felkészülve, mennyire kell őket edukálni, evangelizálni, és mennyire befogadó egyáltalán egy szervezet minderre?

Fodor Szabolcs: – Nagyon jó ez a témafelvetés. Szerintem azzal, hogy elindult egy igény arra, hogy egy központi adattár épüljön fel a silóból, egyszerűen elengedhetetlen, hogy ezek a területek elkezdjenek egymással beszélni, és hatékonyan tudjanak együttműködni. Sok esetben az OT a saját területén kialakította az adatsilókat, abban tényleg nagyon jól tud mozogni, nagyon jól ismeri azt a területet, és az IT-nak meg nem nagyon kellett ehhez hozzáadott erőforrást adnia, merthogy az OT el tudta üzemeltetni ezeket a rendszereket. Az egyes kis silókban azokat az adattárakat vagy azokat a kis adatgyűjtő rendszereket, illetve gyártáskiszolgáló rendszereket jól tudja üzemeltetni. Abban az esetben, ha ezeket már integrálni kell, és valamilyen központi tárban kell elhelyezni, nyilván a megfelelő jogosultságrendszerekkel, a megfelelő hálózati elemekkel, erőforrásokkal, a data governance igényekkel kiegészítve, azt gondoljuk, hogy ez már az Operation Technology-ért felelős csapatok kompetenciáját meghaladhatja, vagy legalábbis nem érdemes, nekik nem is ez a fő fókuszuk a működés során, ezért nyilván az IT területen kell ezeket az igényeket felszedni. Azt gondolom, hogy ma már kiváló szakemberek érhetők el a legtöbb ilyen vállalatnál, akár a data engineering vonalon, akár a data science, vagy adatelemző vonalon. Amit mi tapasztalunk, hogy a nehézségeket inkább az adja, hogy ezt a kommunikációt, a közös platformot, az igények összerendelését, ezt az információáramlást hogyan tudjuk segíteni annak érdekében, hogy ezek a csapatok hatékonyan tudjanak együtt dolgozni, és sikeres projekteket hajtsanak végre. Ebben viszont úgy látjuk, hogy kevés a tapasztalat. Illetve azért azt is fontos tudni, hogy akár az OT, akár az IT területén az érintett feladatok sokszor nagyon komplex, vagy nagyon speciális tudást igényelnek, és ezzel nem biztos, hogy rendelkezik egy ilyen vállalat, és nem is biztos, hogy kell, hogy rendelkezzen folyamatosan. Például, hogy egy PLC-rendszerből hogyan szedjük ki az információkat, adatokat, nem biztos, hogy mindent ismerni kell egy OT területen dolgozó szakértőnek. De hogyha egy konkrét rendszert, egy új rendszert, vagy egy már meglévő rendszert, amivel eddig adatgyűjtés szempontjából nem foglalkoztak, de be kell integrálni egy ilyen data lake irányába, akkor nem biztos, hogy nekik ki kell képezni erre egy szakértőt, hanem lehet, hogy a piacról érdemes tanácsadón keresztül erre a feladatra bevonni az adott időszakra. Ha például ez egy két-három hónapos projekt, akkor arra az időszakra érdemes inkább bevonni szakértőt, vagy érdemes bevonni terméket. Ugyanígy igaz az IT területén, hogy ha data engineering feladatokra integrálni kell, vagy ha ki kell alakítani egy adatarchitektúrát, akkor nem biztos, hogy erre folyamatosan érdemes fenntartani egy ilyen területnek szakembereket, vagy bővíteni a csapatot, hanem bizonyos esetekben, amikor projektek futnak, vagy olyan igény van, akkor érdemes külső szakértőt bevonni. Ilyenkor mindig azt szoktuk mondani, hogy valahol a szakértő bevonásával nemcsak erőforrást, hanem tudásimportot is végez egy ilyen vállalat, mert be tudnak hozni olyan szemléletet, olyan, a vállalaton kívülről érkező friss tudást, ami gyakorlatilag a projekt során felelőssége is egy ilyen projektcsapatnak, hogy átvegye ezt a tudást, és felmérje. És nyilván a beszállító pedig ezt az információt, ezt a tudáshalmazt azért valamilyen szinten a megrendelőnek átadja. Itt emeljük ki az edukációt meg az evangelizációt, aminek szerintem abban van óriási szerepe, és az ilyen projekteknek az egyik nagy buktatója, hogy sokszor a szervezetekben ülő személyek nincsenek felkészülve arra, hogy ilyen változásokon menjenek keresztül. Leegyszerűsítve próbálok elmondani egy példát, hogyha van egy gépeken gyűjtött adathalmazom, mondjuk szenzoradat, van egy rendszerem, amihez én férek hozzá, én fejlesztem, az OT területén belül vagyok, gyakorlatilag kvázi szabad kezem van azzal kapcsolatban, hogy hogyan fejlesztem ezt az adattöltést, adatgyűjtést, a rendszert, ami ezeket az adatokat feldolgozza. Majd egyszer csak jön egy projekt, ami azt mondja, hogy nekem szükségem van ezekre az adatokra, én ezt integrálni szeretném. Akkor nyilván felmerül a kérdés, hogy ki fogja ezt látni, kinek akarom én ezt átadni. Hát alapvetően nem biztos, hogy mindenkinek szeretném átadni, vagy hát tartok tőle, hogy nem biztos, hogy jó szándékkal fogja egy terület felhasználni ezeket az adatokat, és akkor most csak egy ilyen kicsi vállalatokon belüli nehézségeket hoztam be. Aztán nyilván, ha felmerül a kérdés, hogy oké, hogyha ezekkel az adatokkal production-t, valamilyen funkciót ezekkel ki akarnak szolgálni, és én azon szeretnék módosítani, mert lehet, hogy én leszek a terméknek a tulajdonosa úgymond, amit egy központi adatsilón vagy adatintegráción keresztül átvezet, mondjuk, ha egy gépi tanulási algoritmuson átvezetve kapok egy ilyen terméket. De mi van akkor, ha én ezen változtatni szeretnék, vagy az adattöltési eljáráson módosítani szeretnék? Akkor már egyből jönnek a függőségek, hogyha ezt én már nem tehetem meg, mert mondjuk ez egy más területen integrált rendszer egy production-ba állított rendszer, amibe azért én személyesen nem nyúlkálhatok bele. Ezért valakit majd meg kell kérnem, hogy ez tudjon működni, akinek meg más prioritásai is lesznek, így nem biztos, hogy én leszek a legfontosabb számára, nem biztos, hogy úgy fog megvalósulni ez a feladat, vagy úgy lesz elvégezve a feladat, ahogy én szeretném. Szóval minden egyes ilyen esetben felmerülnek ezek a kérdések, és kvázi ilyen nehézséget okoznak, és azt az érzést keltik, hogy felesleges is ezt csinálni, miért nem egyszerűbb, hogyha én saját adataimmal rendelkezem, azon dolgozom, és nem kell itt mást bevonnom. Nyilván mindig az innováció ellen hatnak ezek a gondolatok, amik alapvetően lehetnek teljesen jogos gondolatok, és egy-egy ilyen projektben nem elég csak a technológiai problémákat kezelni, hanem igenis nagyon fókuszálni kell arra, hogy a szervezet mennyire képes megküzdeni ezekkel a változásokkal. Csak egy példát még kiemelnék, hogy egy hatékonyságnöveléssel kapcsolatos projekten van egy gyártási üzemeltetési terület, ami felelős a gyártásért. Majd elindul egy projekt, ahová a gyártásról információkat, adatokat szolgáltatnak, és a projektnek az a célja, hogy azt a gyártási folyamatot valamivel hatékonyabbá tegyék az adatok elemzésén keresztül. Kiderülnek az adatokból, hogy bizonyos beállításokkal egyébként sokkal jobban lehetne működtetni ezt a gyártást, és mondjuk 10-15%-kal javul a gyártott mennyiség. Amikor ez a stakeholder kikerül a prezentációra, akkor azért gondoljunk bele, hogy a gyártásért felelős vezető meglátja ezt a számot – hát nyilván, ha én lennék az, nem örülnék neki, hogy valaki bevési egy prezentációra –, ebben az fog szerepelni, hogy én eddig nem biztos, hogy jól végeztem a munkám. Mert egyébként 10%-kal hatékonyabban is lehetett volna végezni ezt, és akár megkérdezhetik tőlem, hogy miért nem így tettem, és ilyenkor beindul természetszerűleg egy védekezési mechanizmus, és azt mondom, hogy rosszak az adatok, az biztos nem is úgy van, szóval egyből elkezdem vitatni ezt az eredményt. Óhatatlan, hogy ez nézetkülönbségeket okozhat, és lehet igaza bármelyik félnek, nyilván itt az a feladat, hogy ezt a gátat leépítsük és egy kicsit ezt a bizalmat a csapaton belül felépítsük, hogy igen, azok az adatok egyébként jók, az adatelemzési módszer jó, a machine learning algoritmus értéket teremtett, és ezt érdemes elfogadni. És ez nem azt jelenti, hogy probléma volt eddig a működéssel, hanem egy olyan aspektusból sikerült megvizsgálni az adott gyártási folyamatot, amit eddig még nem tudott senki megtenni, és most a képességek és az adatok alkalmasak voltak arra, hogy erre rájöjjünk, és érdemes ezt használni. Szóval nyilván ezek olyan tényezők, amikre sokszor nem is gondolunk egy projekt esetén, hanem azt gondoljuk, hogy a technológiai problémákkal kell csak megküzdenünk, de fontos erre is fókuszálni.

Masa Attila: – Igen, ezt saját tapasztalatból megerősíthetem. Itt beszéltünk az elején, hogy milyen stakeholderekre, milyen szereplőkre van szükség egy-egy ilyen projektben. Azt is fontos tudni, hogy egy ilyen rendszernek a bevezetése mindig közös munka az ügyféllel, tehát azt a domain-tudást, azt a gyártási tapasztalatot, amik az ő gyártási sajátosságait jellemzik, azt mi nyilván nem tudjuk egy-két találkozás alapján felismerni vagy teljes részletességgel megismerni, ami a projekt sikerét szolgálja. Másrészt pedig – mi azt szoktuk mondani – mindig szükség van egy helyi hősre, aki ezt a projektet igazán akarja, hisz benne és drive-olja, gyakorlatilag nemcsak minket, mint beszállítót, hanem egyaránt a céget is, és próbálja házon belül azokat az értékeket kihangsúlyozni vagy interpretálni, amiket igazán ők értenek, és tudják, hogy miért lesz ez fontos a számukra. Érdekes volt, amikor beszéltünk arról, hogy az adatok milyen minőségben állnak rendelkezésre. A kérdés az, hogy a tyúk vagy a tojás volt hamarabb. Arra gondolok itt, hogy amikor egy-egy projekttel megkeresnek titeket, akkor mi az, ami ezt indikálja egyfelől. Szól-e arról a megkeresés, hogy van már egy meglévő óriási adathalmaz, amiben valamit keresünk, még mi sem tudjuk igazából pontosan, hogy mit keresünk, csak tudjuk, hogy van rengeteg adatunk, és azt gondoljuk, hogy ebből valamilyen algoritmussal valamilyen következtetést le tudnánk vonni, nagy valószínűséggel, ami a mi előnyünket szolgálja. Vagy inkább a másik oldalról érkezik a megközelítés, hogy van valamilyen üzleti probléma, hallottunk ilyen szexi kifejezéseket, hogy machine learning és AI, és hogy valami ilyesmivel oldjátok már meg a problémákat. Nyilván akkor meg kell vizsgálni, hogy ehhez a szükséges adatok rendelkezésre állnak-e, erről már ugye beszéltünk. Illetve még a kérdésnek a másik fele, hogy amikor ilyen nagy adattömeget vizsgáltok, illetve hogy osztályozzátok vagy validáljátok az egyes adatpontokat, mondjuk annak a projektnek vagy üzleti célnak mennyire felelnek meg, akkor mi alapján tudtok arról dönteni? Mondok egy példát, van egy szenzor, van egy hőmérsékletérték, amit szolgáltat egy gép. Lehet, hogy önmagában az a hőmérsékletérték igazából nem releváns, vagy nincs túl sok információértéke, viszont ha korrelációba kapcsoljuk két-három másik szenzorértékkel, akkor rögtön akár előrejelezhetnek valamilyen meghibásodást. Milyen mechanizmus mentén tudtok így az adatok osztályozása közben dönteni arról, hogy egy adat szükséges, nem szükséges, vagy megfelelő-e?

Fodor Szabolcs: – Összetett kérdés, de igyekszem minden pontjára válaszolni. Az egyikre fel is kaptam a fejem, és ezzel szoktunk rendszeresen találkozni. Most már külön módszert építettünk ki magunknak, leírtuk, hogy hogyan ne csináljuk így. Ez a tipikus igény, amivel gyakran találkozunk, és nem jól megfogalmazott igény, hogy van egy csomó adatunk, ti vagytok az adatos emberek, gyertek ide, nézzétek meg, és mondjátok meg, hogy mit kezdjünk vele. Ezekkel a kérdésekkel nekem az a bajom, és sajnos egyébként tapasztalat, hogy volt olyan projekt, amit így elindítottunk, elfogadtuk a megkeresést, és aztán ezzel mentünk neki. Sajnos a vége az lett, hogy rossz szájízzel zártuk. Miért rossz ez a problémafelvetés? Azt mondja egy vállalat, hogy van egy adattárházam, abban van egy csomó információ, egyébként én ezzel foglalkozom, itt vannak az adatok, mondd meg, hogy mit kezdjek vele. Akkor általában az történik, hogy átadnak egy connection string-et amivel hozzáférünk az adattárházhoz, vagy átadnak valami mintaadatokat. Akkor mi nekiülünk, és elkezdünk gondolkozni, hogy oké, mi lehet itt az üzleti motiváció, milyen adatok vannak mögötte, elkezdjük nézegetni, elemezgetni, aztán hátha találunk benne érdekességeket. És aztán eltelik pár hét a projektből, jönnek eredmények, érdekességek, bemutatjuk, hú ez nagyon jó, érdekes, aztán megint eltelik pár hét, és akkor azt mondjuk, hogy oké, ezeket találtuk, leszállítottuk az eredményeket. Ilyenkor szokott felmerülni projektzáráskor, hogy rendben, de mit kezdjünk ezekkel? Szóval, hogy tyúk vagy a tojás, én azt gondolom, hogy az a jó megközelítés, és ebben egy beszállítónak is óriási felelőssége van, hogy feltegye a kérdést, hogy igen, vannak adataid, de mi az igazi problémád, mi az az üzleti probléma vagy az a gyártási, működési, operation vagy bármi ilyen probléma, amire választ keresel. Mert szerintem sokkal fontosabb megérteni azt, hogy mi az, amivel közvetlenül hozzá lehet járulni egy vállalat működéséhez. Akár költségoptimalizálás, akár folyamatoptimalizálás, vagy bevételnövekedésen keresztül, ami mérhető, ami kézzelfogható, amit hogyha készítünk egy terméket adatalapon, vagy egy egyszerű elemzést, akkor azt tudom mondani, ha elkezdtük ezt működtetni, akkor egy hét, egy hónap múlva ennek te vissza tudod mérni az eredményét, és valamilyen KPI-on keresztül számszerűsíteni tudod. És ha erre tudunk jó választ adni, hogy például én azt szeretném, hogy a selejtarányom ennél a termék gyártásánál csökkenjen, akkor igazából nem egy adatalapú problémát vetettél föl, hanem egy működésbeli problémát, amire azt mondhatjuk, hogy oké, értjük. Vannak-e adataid, mennyi a termelt mennyiség mellett a selejt, mi befolyásolja ezt, és ezekről tudsz-e adatot szolgáltatni, tudsz-e mondjuk a gyártási lépésekről szenzoradatokat szolgáltatni? És ha azt mondják, hogy igen, akkor nyilván az a következő kérdésünk, hogy hogyan függhet ez össze, és hogyha ezekre tudunk választ adni, akkor azt mondjuk, hogy ez egy értékes projekt lett. Természetesen itt sincs garancia arra, hogy ezekből az adatokból kijön valami hasznos eredmény, de már van egy kerek sztorink, ami mögött azt feltételezzük, hogy vannak jó adatok és ezzel tudunk értéket teremteni. Azért is jó ez a megközelítés, mert ilyenkor eléggé bekorlátozzuk azoknak az adatoknak a halmazát, amikkel érdemes foglalkozni. Én nem vagyok az agilitásnak a prédikátora, viszont az elveknek az értékét vallom. Mi is megfogalmaztuk saját csapaton belül, hogy van egy ilyen tipikus modellfejlesztési megközelítés, ez a CRISP-DM modell, hogy hogyan megyünk végig egy modellfejlesztési folyamaton, hogy nyilván begyűjtjük az üzleti információkat, begyűjtjük a rendelkezésre álló adatokat, elkezdjük értelmezni, egyeztetünk, aztán amikor már eljutottunk olyan fázisba, akkor erre modellt fejlesztünk, és akkor ezt visszamérjük, visszacsatoljuk az ügyfélnek. Ez egy nagyon jó általános módszertan arra, hogy hogyan menjünk végig egy ilyen feladaton, de képzeljük el, mi van akkor, ha 100-200 mezőből álló adathalmazunk van, és akkor azt mondják, hogy én gyorsan szeretnék eredményt ebből. Akkor vajon végigmegyünk-e az összes adaton, elkezdjük-e mindegyiket elemezgetni, hogy majd ez mire lesz jó? Mi erre azt mondjuk, hogy nem biztos, hogy ez jó megközelítés, fordítsuk meg. Kérdezzük ki az ügyfelet, gondoljuk végig a problémakört, és próbáljuk meghatározni azt az 5-6-10 ismérvet, ami ténylegesen befolyásolni fogja. És ezt az 5-6-10 ismérvet kezdjük el mélyére hatóan vizsgálni, és nézzük meg, hogy ebből tudunk-e értéket teremteni, és ha sikerült, akkor rövid időn belül tudunk eredményt produkálni. Ha esetleg ezekből nem sikerült, akkor visszamehetünk az első ponthoz és újra elkezdhetünk beszélgetni az üzleti stakeholderekkel, hogy oké, ti azt gondoltátok, hogy ezek a fontos ismérvek, de az adatokból az jött ki, hogy nem. Akkor keressünk tovább, és nyilván így el tudunk jutni odáig, hogy egy értéket teremtsünk. Ugye még arra kérdeztél, hogy az adatokból hogyan tudjuk kihámozni, hogyan tudjuk így ezeket összeszedni, hogy mik fontosak, hogyan lehet ezt előzetesen felmérni? Ez is egy izgalmas kérdés, ez a scoping kérdése, szeretjük ezt is feszegetni. Nyilván amikor a nagyvállalati beszerzési terület azt mondja, hogy márpedig erre ekkora büdzsé van, és ezt a terméket várjuk ebből a büdzséből, akkor nehéz helyzetben vagyunk, mert ilyen esetben elindul az ajánlkozási folyamatnál egy ilyen mindenre kiterjedő előzetes felmérés. Milyen adatok vannak, azok pontosan mit jelentenek, milyen minőségben, milyen rendszerességgel töltődnek, hogyan lehet ezt felhasználni, mit szeretnél, mi a termék, mondd meg pontosan, hogy azt hogy akarod, mert csak erre tudok konkrét ajánlatot adni. És aztán nyilván ilyenkor jön az, ha ez egy több hónapos projekt, hogy a projekt közepén kiderül, hogy ez nem is az az adat, meg nem is úgy gondoltuk azt a terméket, hanem most már ismerjük, és az eddigi tapasztalatokból már egy kicsit lehet, hogy mást kellene csinálni. Akkor jönnek ezek a klasszikus projektmenedzseres nehézségek, hogy dehát ezt pluszban kell fizetni, ez nem volt benne az eredeti ajánlatban. Szóval nehézségek vannak, és sajnos ilyenből is van negatív tapasztalatunk, hogy hiába volt alapos a felmérés, az adatokból kiderült, hogy nem lehet terméket fejleszteni. És mit csinálsz a projekt közepén, amikor leszerződtél egy termékre és kiderül az adatokból, hogy nem lesz meg az a termék? Hát ilyenkor nehéz helyzetben vagy. Egy kicsit ezért is gondolom az agilitásnak az értékét, mert mondhatjuk azt, és nyilván megrendelői oldalról ez óriási nyitottság és határozottság kell, de hogy agilisan közelítjük meg. Addig fejlesztünk egy terméket, addig dolgozunk rajta, amíg értéket teremt. És ha azt mondjuk, hogy a második héten kiderül, hogy egyébként nem is jók az adatok, vagy egyszerűen nincs olyan adatminőség, meg mennyiség, amiből lehet értéket teremteni, akkor lehet, hogy két hét után azt mondjuk, hogy sorry, de ne folytassuk ezt a projektet, inkább indítsunk egy olyan projektet, ami az adatgyűjtésre koncentrál, vagy az adatminőség javításra. Nyilván ha siker van, jók az adatok és el tudunk indulni, akkor is iteratíve tudjuk addig csinálni a projektet, amíg abban van érték. Úgyhogy ez megközelítés kérdése, meg ez az agilitás is. Egy másik ilyen gyönyörű nagy csomag, amivel mostanában ugyanígy találkozunk, az agilis transzformáció – mint buzzword-del, mondjuk így –, szóval most az AI adaptáció mellett ezen is dolgoznak a nagyvállalatok, nincsenek könnyű helyzetben. Én hiszek ezekben, hogy tudnak úgy értéket teremteni, hogy ha nem sikerülne, akkor is minimális veszteséggel lehet egy ilyen helyzetből kilavírozni.

Masa Attila: – Igen, ezt mi is, vagy én magam is meg tudom erősíteni, hogy elég nehéz emiatt egyébként ebben a szektorban, szegmensben projektet vállalni, egyrészt, mert evés közben jön meg az étvágy. Nagyon jó ez a feature set, amivel leszállítottuk a rendszert, de még lehetne egy kicsit ilyen, egy kicsit olyan, és hát persze a beszállító, illetve mi szolgáltatói oldalon próbáljuk az ügyfélt maximálisan kielégíteni, de a végtelenségig nem lehet projektet nyújtani. Erre az agilitás lenne jó megoldás, de egy klasszikus ipari vállalatnál a beszerzés nem igazán erre méretezett egy büdzsének az elengedésekor, amikor jóváhagy egy-egy ilyen projektet, szeretnék tudni, hogy ennek pontosan hol lesz az eleje és hol lesz a vége mind pénzben, mind pedig időben. Ezt a témát még egy kicsit vesézhetnénk, és itt arra lennék kíváncsi, hogy egy-egy ilyen projektnek a megtérülését hogy lehet, vagy lehet-e egyáltalán számolni? Az teljesen egyértelmű, hogy minden vállalat profitorientált, és bármilyen innovációba, fejlesztésbe belevág, hogyha valamilyen távon, rövid-, közép- vagy hosszútávon annak a megtérülését vagy az eredményét látja, de jelen esetben hogy lehet ezt alátámasztani, kiszámítani, megindokolni, amikor sokszor a cél sem pontosan ismert, az odavezető út meg pláne. Azt se tudjuk, hogy pontosan milyen kihívásokkal találkozunk, illetve milyen hosszú lesz ez az út, meg egyáltalán itt milyen időben, és milyen projektméretekben lehet vagy kell gondolkozni. Azért azt mi is tapasztaltuk, amikor együttműködtünk, vagy hát volt olyan projektünk, ahol tanuló algoritmusokat alkalmaztunk valamilyen gépi anomália predikcióra, hogy az algoritmusoknak tanulniuk kell, és a tanuláshoz idő szükséges, tehát hogy rendelkezésre áll egy megfelelő adathalmaz, rá készültek az algoritmusok, és akkor utána gyakorlatilag még akár hónapokba is telhet, mire azokat a következtetéseket megkapjuk, amiket a nap végén majd eredménnyé formálhatunk. Úgyhogy mik azok a sarokszámok, vagy hogyan lehet belevágni egy ilyen fejlesztésbe?

Fodor Szabolcs: – Említettük a beszerzést, meg az üzleti megrendelőt, üzleti stakeholdert, nyilván azt a kérdést fogja először feltenni, hogy oké, mennyibe kerül ez a projekt. És általában ezek a projektek azért nem egy marginális költséget jelentenek, mert technológia és szakember szempontjából is számolni kell – erre majd visszatérek –, de nem is baj, ha van ennek látszata. Nem ilyen vonal alatti költséget jelent. Szóval, hogyha egy ilyen döntés előtt áll egy üzleti döntéshozó vagy egy vezető, nyilván felteszi a kérdést, hogy ez most nekünk meg fogja érni, mi lesz ebből nekünk a haszon? És akkor innen eljutunk nagyon rövid időn belül a ROI-ra, a megtérülésre. Nagyon nehéz – amit említettél is –, rengeteg kockázat övez egy ilyen kvázi beruházást, vagy egy ilyen projektet. Lehet megközelítő számításokat végezni, anélkül, hogy valamilyen elvárásaink lennének. Mondjuk egy ilyen eszköz vagy projekt bevezetésével vagy végrehajtásával nem érdemes elindulni, tehát azért valamilyen célszámokat ki kell tűzni. De amikor ez egy kvázi zöldmezős beruházás, és például egy autó gyártósornál akarunk valamin változtatni s még életünkben nem vizsgáltuk ezeket az adatokat, akkor csak feltételezhetjük, hogy ez sikeres lesz. Azt gondolom, hogy ilyenkor az a jó megközelítés, hogyha megpróbálunk rövid időn belül valamilyen mérföldkövet, valami kisebb mérföldkövet megcélozni, és azt mondani, hogy akár csak ilyen POC (Proof of concept) jelleggel egyáltalán vizsgáljuk meg, mérjük fel, hogy ebben van-e akkora üzleti potenciál. Lehet, hogy nem kell az első lépésnél még machine learning modellt fejleszteni, hogyha mondjuk csak erre szorítkozunk, hanem egyszerűen csak azt vizsgáljuk meg, hogy van-e adatunk. Ha erre az adathalmazra egyébként valamilyen machine learning megoldást illesztenénk, akkor ezt be tudjuk-e az operatív folyamatainkba illeszteni, tehát hogy működőképes lesz-e, hogyan tud ez működőképes lenni. Hogyha nem csinálunk még modellt, de az adatokból csak megvizsgálom a legfontosabb kulcsadatokat, tényezőket, és abból egy egyszerű szakértői logikával csinálok egy szakértői modellt, és azt elkezdem mérni egy-két hónapig, akkor ebből már rövid időn belül el tudom dönteni, hogy vajon ennek van-e hozzáadott értéke. Találkoztunk már nem egyszer olyan tenderrel vagy megrendelési igénnyel, ahol azt szoktuk mondani, hogy a csillagrombolót szeretnénk így azonnal felépíttetni, és sokszor azzal szembesülünk, hogy egyébként a valóság a projekt közben kiderül, hogy azért nagyon messze van attól, ami igényként megfogalmazódott, és ez persze nem baj, csak tudatosan kell ezt a folyamatot építeni. Érdemes már az első lépésnél azt mondani, hogy csak egy egyszerű dolgot akarjunk, tehát hogy tudjuk, hogy egyébként ebben a megoldási irányban egy machine learning modellel majd nagyon komoly értékeket lehet elérni, óriási feltételezés, de vizsgáljuk meg valami sokkal kisebb egységben és kevesebb ráfordítással. Hogyha ott tudtunk eredményt produkálni, akkor lépjünk még egyet. És nem biztos, hogy egyből a csúcsra kell lépni, hanem még egy szintet lépünk. Ezért is mondtam, hogy egyébként a hozzáadott értéknek a 80%-át az adatok adják, tehát nem biztos, hogy azonnal a machine learning modell fejlesztésére kell fókuszálni egy ilyen projektnél, hanem arra, hogy azokból az adatokból kinyerem-e azt az információt, amit tudok hasznosítani. És hogyha igen, sikerült, akkor majd egy következő lépésben ennek az információnak a hasznosságát majd egy machine learning modellel tudom növelni abban az esetben, ha ebben tényleg látunk értéket. És olyan azért nyilván előfordulhat, hogy hibázunk, hogy egyébként egy komplex modellel lett volna érték, de az adatokból az első lépésnél nem sikerült értéket teremteni. Azt gondolom, fókuszáltan azokra az adatokra kell koncentrálnunk, amiknél adott szakterület úgy véli, hogy fontosak az ő működésükben, a selejtarányban, kereskedelemben, az ipartól eltekintve bárhol, bármilyen területen. Szóval, hogyha ezekből – mondjuk ez legyen egy öt ismérv – nem találunk valamilyen olyan összefüggést, ami hasznos lehet, akkor elég nagy a valószínűsége, hogy később akár száz modellel sem fogunk találni. Azt gondolom, hogy ez a megközelítés biztosíték lehet arra, hogy a kockázatok minimalizálása mellett olyan projekteket válasszunk ki, amik értékesek legyenek. Mondok egy példát. Nem az ipari szektorban találkoztunk ilyennel, hanem a kereskedelmi szektorban. Azt mondták, hogy elkészült egy adattárház verzió, és a digital csapat, aki drive-olta ezt a fejlesztést, azt mondta, hogy őneki rengeteg ötlete van ezekből az adatokból, és ő nem szeretné egyből a termékeket megvalósítani, csak a termékeket szeretné validálni. Ezeket a validációs projekteket egymás mellett párhuzamosan futtatta. Mondjunk egy számot, legyen tíz. Tíz ilyen validációs projektet lefuttatott másfél hónap alatt, és kijött, hogy ebből a tíz ötletből háromban van üzleti potenciál, és azt mondta, hogy rendben, én a következő egy évben ezzel a hárommal akarok csak foglalkozni. És arra már nyilván nagyobb fejlesztési erőforrást allokál. Ezzel gyakorlatilag megszűrte az ötleteket, és azokra fókuszált első körben, amiben nagyobb potenciált lehetett kimutatni. Ha ezt sikerül realizálni, akkor nyilván egyrészt nagyobb büdzsé van arra, hogy komplexebb vagy nehezebb problémába is fogjanak, illetve van már egy magabiztosság, hogy ezekben az adatokban van érték. Forduljunk rá még arra a maradék hétre, és nézzük meg, hogy egyébként abban találunk-e még lehetőséget. Szóval szerintem ez, ha nagyon leegyszerűsítem, vagy elvonatkoztatok így a projekttől, az agilisabb alapelveket érdemes követni, hogy rövid időn belül értéket teremtő megoldásokat próbáljunk leszállítani, és ezeket iteráljuk folyamatosan, amíg van benne érték.

Masa Attila: – Egyébként ezt abszolút osztom, és ez nálunk is egy bevett szokás, hogy gyakorlatilag ügyfeleknél, vagy új ügyfeleknél nagyon nagy százalékban úgynevezett pilot projekttel vagy POC-vel indulunk. Kis anyagi kockázattal valamilyen szűkebb scope-ot kijelölünk, és gyakorlatilag ott validáljuk egyrészt a mi megoldásunkat az ügyfél számára, másrészt pedig azt, hogy számukra ténylegesen azt az értéket meg tudjuk-e teremteni ami fontos. Szerencsére ezen a lépcsőn túl szoktunk tudni jutni az ügyfeleknél pont emiatt, hogy az elején van közös sikerélmény. Itt fontos ezt a scope-ot is – és valószínűleg ez a ti területetekre is igaz – definiálni, hogy amit kockázatosnak érzünk, azt próbáljuk meg már az elején feltárni. Mindamellett fontos, hogy meglegyen a kölcsönös sikerélmény, hogy ne törje derékba már a csírájánál ezt a bevezetést vagy ezt a projektet. Másfelől említetted ezt a csillagrombolót, ez is simán jó megfogalmazás, sok kontextusban mi is alkalmazzuk, és találkozunk vele. Nyilvánvalóan az ügyfél nagyon szeretné, ha a beszállítónak, aki hozzá megérkezik, ott lenne az autójában egy csillagromboló, ami minden problémájára megoldást tud nyújtani. Mi is nagyon szeretnénk, hogyha rendelkeznénk ezzel a csillagrombolóval, de hát azért ennek a kifejlesztése egyrészt óriási erőforrásokat igényelne, másrészt pedig nekünk az a tapasztalatunk, hogy bár helikopterből nézve a gyárak lehetnek egyformák vagy nagyon hasonlóak, de valójában mindenhol nagyon eltérőek a gyártási folyamatok, és nagyon nehéz erre univerzális megoldást úgymond a fiókban tartani, szükség esetén elővenni, és tényleg csak bekapcsolni vagy installálni, és működésre bírni. Ezzel kapcsolatban nektek milyen tapasztalataitok vannak? Mennyire tudtok egy-egy ilyen megoldást betenni a fiókba, és a következő ügyfélnél elővenni? Gyakorlatilag annyira eltérőek a környezetek, illetve a feltételek egy-egy gyárnál, hogy ez minden esetben egy teljesen eltérő szemléletet és projektkivitelezést igényel.

Fodor Szabolcs: – Ez egy érdekes kérdés. Nyilván – mondjuk így – a termékesítésnek, és az, hogy valamilyen tudást újra tudjunk hasznosítani, abban nyilván – ha már csak azt az egyszerű tényt vesszük alapul – tudunk nagyon hatékonyak lenni, hogyha valamit másodjára csinálunk végig, mert akkor már van egy jó tapasztalatunk. És hogyha harmadjára, negyedjére, akkor még több tapasztalattal bírunk. Mi azt vettük észre – és én megerősítem ezt az állítást –, hogy igen, minden egyes szituáció, minden egyes üzleti probléma bármennyire is nagyon hasonló területről beszéltünk, más és más. Én erre azt mondom, hogy amennyiben a saját csapatunkban próbálunk előre menni, hogy módszertant fejlesztünk, építünk és standardizálunk. Tehát az, amit itt az előbb mondtam, hogy agilisan próbálunk hozzáállni egy projekthez, hogy feltesszük az elején a kérdést, hogy nem az adatokat akarjuk nézegetni, hanem megtudni, hogy mi az üzleti probléma, és hogyan tudjuk azt az adatok nyelvére lefordítani. Akkor kezdünk el projektet indítani, amikor ezekre már megvannak a kész válaszok, és értjük a problémát. A legelején említettem, hogy igen, van egy szerszámosládánk, amiben rengeteg eszköz van, és ezt az eszközkészletet szeretnénk minél frissebben, minél aktuálisabban tartani, és ebben komfortos lenni. Azt gondolom, hogy ezekkel felvértezve meg lehet válaszolni a legtöbb problémát, sőt a mai piaci helyzetben inkább azt gondolom, hogy nem is biztos, hogy a ládából a legspeciálisabb szerszámmal kell nekiállnunk a probléma megoldásának, hanem az egyszerű dolgokat kell elővenni, mert még inkább erre van most igény. Ebből lehet ma még – ha nem azt mondom, hogy szerencsénk van, de hogyha jó témát sikerül fogni, és jó minőségű adatok állnak rendelkezésre – komoly értéket teremteni. Úgyhogy én azt látom, bár a magyarországi piac erre szűk is, de sok év tapasztalata, meg sok év projektmunkája után előfordulhat, hogy lesznek olyan részfeladatok, amire azt tudjuk mondani, hogy lehet standard módszereket készíteni, ami bizonyos customizáció után használható egy nagyon hasonló ügyfélnél. Bár jelenleg inkább azt tapasztaljuk, hogy a felmerülő problémák hasonlóak, de egyszerűen nagyon nehéz hasonló módszertant látni. A megoldásra nagyon hasonló módszerekkel tudunk válaszolni, például elkészítünk egy kész modellt ami a fiókban van, kivesszük, és csak bekötünk hozzá más adatokat, és aztán működik. Egyébként ez pont egy ügyféllel való scope tárgyalás során merült föl, hogy dehát már megcsináltunk egy ilyen modellt, nem lehet csak kicserélni alatta az adatokat a másikra, és akkor ugyanúgy fog működni? És mondtuk, hogy hát nyilván ugye rosszul jön ki, erre ő azt mondta, hogy abban vagyunk érdekeltek, hogy fejlesszünk egy újat. Hozzá kellett tennem, hogy meg persze abban is, hogy neki sikerélménye legyen és eredményt termeljen. Ezért azt mondtam, hogy szakmailag nem jársz ezzel jól, de hogyha te úgy gondolod, hogy neked az így jobban megéri, próbáld meg, de valószínűleg nem fog működni. Szóval igen, azt látjuk, hogy még a custom megoldások azok, amikkel tudunk operálni, és amik így a közeljövőben is inkább felmerülnek.

Masa Attila: – Kicsit összefoglalva a lassan elmúlt egy órát, ha most lenne egy ügyes tanuló algoritmusunk, akkor ezt megtenné helyettünk. Mert morzsákba szerintem már ezt szétszórtuk, de hogyan lehetne egy ilyen projektnek a roadmap-jét definiálni? Kezdve azzal, hogy egyáltalán mi az a belépési pont – ha belépési pont, mint olyan most itt értelmezhető vagy megfogható –, ahol ebbe egy vállalat beléphet, és mik azok a lépések mondjuk néhány, nagyjából négy-öt pontban összefoglalva, amin végig kell menni ahhoz, hogy egy ilyen projekt eredményre jusson?

Fodor Szabolcs: – Hát az igényfelmerülés a legfontosabb, és itt azt mondom, hogy nem kell feltétlenül egy vállalaton belül teljesen a problémát felvetni, és hogyha vannak adatok, fel kell tenni a kérdést, hogy vajon azokból lehet-e válaszolni. És aztán nyilván ez a függvény, vagy ez a megoldáshoz vezető út első lépése, hogy megvizsgáljuk, hogy egyáltalán rendelkezésre állnak-e információk. És ezt persze lehet belső hatáskörben erőforrásokkal vagy külső szakértők bevonásával is megtenni. Szerintem a legeslegfontosabb az, hogy tegyük fel a kérdést, és tudjunk arra értelmes választ adni, hogy mit szeretnénk az adatokkal kezdeni, vagy pontosabban mik azok a problémák, amikre azt gondoljuk, hogy az adatokon keresztül választ adhatunk. Nem feltétlenül kell itt most egyből az AI-t – megint a buzzwordöket használom –, a machine learning algoritmusokat a megoldáshoz behúzni, lehet egyszerűbben is gondolkodni. Szerintem a kérdésfeltevés a legfontosabb, s aztán amikor világossá válik, hogy ez tiszta, akkor az első lépés – ezzel abszolút egyetértek –, hogy érdemes egy pilot-ot, egy POC projektet indítani arra, hogy felmérjük, hogy ebben van-e potenciál. Ez a POC projekt válaszolhat arra, hogy egyáltalán ebben a problémakörben, a problémakör mögött rendelkezésre álló adatok elegendőek-e, az adatminőség megfelelő-e, és hogyha ezen végigrágtuk magunkat, akkor van-e ebből érték. És hogyha itt idáig eljutottunk, akkor már egy óriási lépést tettünk meg a siker érdekében, mert meg tudjuk ezeket a kérdéseket válaszolni, és ha meg tudtuk válaszolni, akkor érdemes elindítani az üzletiérték-realizációs projektet, amit nevezhetünk MDP-nek, mert még így sem feltétlenül kell a legtökéletesebb megoldást leszállítani. Milyen kompetenciák, milyen feladatok merülnek fel egy ilyen projekt esetén? Egyrészt előfordulhat, hogy adatokat kell integrálni, töltési gyakoriságot például. Ilyennel már találkoztunk, hogy volt bár gyártóterületen, kereskedelmi oldalon egy konkrét üzleti igény, volt nagyon sok külső adatforrás, tehát ilyen publikusan elérhető adatforrás, mind árazási problémához használható volt, de nem birtokolta úgymond adatbázis szinten egy cég. Ilyen esetben ezt például egy data engineering miniprojektté kell alakítani, ahol ezeket az információkat összegyűjtöm, és aztán utána tudom majd elemezni. Felmerülhet viszont, hogy akkor kell valamilyen data engineering, illetve architect szempontból erőforrás, hogy egyáltalán azokat a környezeteket létrehozzák, amin az adattöltések, az adatelemzési munka zajlik. Hogyha van itt egy konkrét produktum a végén, ami mondjuk egy prediktív algoritmus vagy csak egy szakértői döntési logika, akkor azt végig tudjuk rendszeresen futtatni, és akkor van valami kimenete, akár egy adatbázis, akár egy frontend vagy egy dashboard. Ezeknek az architekturális kialakítására is kell erőforrást fókuszálni, hogy milyen elemek lehetnek még. Alapvetően ha túl vagyunk az adatgyűjtésen, akkor az elemzési lépéseket kell elvégezni, ehhez kell valamilyen erőforrással, illetve dedikált fókusszal foglalkoznunk. Szerintem a kulcs itt igazából mindig a projekt végtermék szempontjából, ha egy ilyen döntési helyzetbe kerülünk, hogy találkoztunk olyan projekttel, ahol egy ilyen hatékonyságjavításnál nem az volt a mondás, hogy ennek az algoritmusnak vagy ennek az adattöltési eljárásnak folyamatosan kell futnia. Ez egy egyszeri elemzés volt, abból kiderült, hogy a gyártási lépésekben mit kell javítani, és igazából időközönként visszamérték. Viszont ennek az előrejelző algoritmusnak nem kellett a háttérben folyamatosan futnia, ez kvázi leegyszerűsítette a problémát, tehát nem kellett élesbe állítani egy teljes rendszert, hanem csak egy elemzésről szólt. De felmerülhet a kérdés, hogy van-e hozzáadott értéke annak, hogy ez mondjuk egy éves üzemben működő termék, és akkor ilyenkor például az élesítés folyamatát, vagy az élesítés lépéseit már a projekt végén el kell végezni ahhoz, hogy folyamatosan információt szolgáltasson. Itt most nagyjából a feladatok, szerepkörök szintén egy jó példa, pont ennél a projektnél volt, ahol egy ilyen belső cross-funkcionális csapatban dolgoztunk, tehát elengedhetetlen, hogy egy ilyen projektnél nyilván egy product owner vezesse az egészet, tehát ő mondja meg, hogy ő mit szeretne. Be kell vonni természetesen a szakterület szakértőjét, ebben az esetben például egy mérnököt, aki érti a gyártási folyamatot. Egy adattudós érti az adatokat, de nem biztos, hogy az adatokból érti azt, hogy mi az a gyártási folyamat, és igazából sokkal fontosabb érteni a folyamatot, mint az adatokat nézegetni, és abból majd valamilyen következtetést levonni. Mert levonhatunk triviális következtetést anélkül, hogy tudnánk hogy egyébként ez tényleg triviális. Vagyis a megfelelő szakembereket be kell vonni, és akkor itt a mérnöki oldalról az engineering, vagy IT oldalról, az adattudós oldalról valakinek, mondjuk egy projektmenedzsernek vagy egy scrum master-nek ezt az egészet egyben kell tartania, és valahogy menedzselnie, hogy ez időről időre értéket tudjon szállítani. Szóval szerepkörök szempontjából én azt gondolom, hogy minimum ezek a szerepkörök megjelennek egy ilyen projektnél.

Masa Attila: – Milyen gyakorlati példákat tudnál még említeni? Ugye itt azért sok minden felsejlett már a monológjaid közben, amikor meséltél egy-egy esetről, vagy egy-egy kérdésre reagáltál, hogy mivel találkoztatok. De ha tudnál mondani néhány olyat – nyilván cégnév, és bármiféle olyan titok kiadása nélkül, ami ne lehetne publikus –, hogy mi volt a probléma amivel megkerestek, és erre ti milyen megoldást szállítottatok, és a végén mi volt az az eredmény, ami értéket teremtett az ügyfélnek?

Fodor Szabolcs: – Hát akkor mondom ezt, amit most így éppen említettem. Ez egyébként megint egy több szakaszból álló féléves projekt volt, ahol egy tihanyi belső csapatba allokáltunk erőforrást, tehát nem mi vittük az egészet végig, hanem egy közös projektcsapat vitte végig. Gyakorlatilag a gyártáshatékonyság javítása volt a cél, de egyébként nagyon érdekes volt, hogy nemcsak hogy eredményes volt, de hogy milyen problémákkal szembesültünk, főleg a projekt elején, például a bizonyos gyártási adatok papíralapon voltak meg. Tehát hogy a digitalizáció nem jár túl magas szinten, konkrétan volt olyan feladat, ahol Excelbe kellett bizonyos információkat összegyűjteni. Szerencsére azért a kulcsadatok egy elég nagy része az adatbázis-oldalon elérhető volt, de például ezt is egy elemzői erőforrás alá kellett rakni. Na most ez a projekt alapvetően arról szólt, hogy a folyamatot adatalapon értsük meg, és a mérnöki oldalt meg az adatokat jól tudjuk összekötni. Volt a végén egy konkrét modell, de nem ez adta a hozzáadott értéket, az eredmény az viszont óriási, mert forintban és százalékban is konkrétan jól mérhető érték lett az egész projektnek az eredménye, és ezzel gyakorlatilag sikerült a működés hatékonyságán javítani. Volt egy másik érdekes kérdéskör, ahol egy folyamatosan működő ipari gyártási környezetben működő gépnek a degradációja volt egy ilyen előrejelzési feladat. Az volt a kérdés, hogy a környezetben folyadékáramlás hatására bizonyos kopás merül fel, és igazából az volt a kérdés, hogy várhatóan mi az élettartama ennek a gépnek, meddig érdemes karbantartani, és mikor érdemes lecserélni. Erre voltak előzetes feltételezések, vagy egy ilyen ajánlás, hogy ezt nagyjából mikor kell megtenni. Nyilván az nem a konkrét gyártási környezetet feltételezte, hanem valamilyen általános környezetet feltételezett. Mivel ennek a gépnek a cseréje elég költséges dolog volt, ezért fontos volt, hogy minél pontosabban előre lehessen jelezni a várható elavulási időpontot, vagy azt, hogy egyáltalán meddig érdemes így karbantartásra fordítani költséget, és mikor érdemes cserélni a teljes gépet. Ez egy teljesen más, ez egy tipikusan predictive maintenance feladatkör volt, ahol a rezgés meg folyadékáramlás adatokból kellett eredményt összerakni. A gyártásterületen egyébként a kereskedelmi oldalon voltunk, ugye erről is meséltem, hogy például leárazás, hossztermék árazáshoz kapcsolódó információkat kellett összegyűjteni, és ehhez támogatni egy elemzőcsapatot, ahol ezeket az eredményeket felhasználva az árazási metóduson lehetett érdemben javítani. Úgyhogy ezek, amikkel így találkoztunk, tipikus gyártásspecifikus problémakörök.

Masa Attila: – Közben érkezett egy-két kérdésünk is Dórától. Azt gondolom – de majd kérek visszajelzést –, hogy az első hosszabb kérdést itt szerintem, már ha darabokban is, de megválaszoltuk. Viszont érkezett egy másik érdekes kérdés, ami szerintem is érdekes, hogy az adattudós és a mérnök szót tudnak-e érteni, át tud-e menni az adattudóshoz a domain tudás? Most ezt még annyival egészíteném ki – ez személyes tapasztalat –, hogy mennyire tudunk ezzel együtt élni, vagy érteni. Régebben dolgoztam robot- meg PLC-programozóként is, és hogyha valaki erről kérdez, hogy nehéz-e robotot, egy ipari robotot programozni, akkor mindig azt mondom, hogy maga a programozás nem nehéz. Viszont ahhoz, hogy valaki tudjon egy működő alkalmazást készíteni, ahhoz neki igazából az alkalmazott gyártástechnológiát nagyon mélyen, vagy legalább közepes szinten meg kell tudnia ismernie. Most itt arra gondolok, hogy ha éppen egy robottal egy alkatrészt festeni kell, akkor a programozónak meg kell tanulnia egy kicsit festeni, hogyha éppen egy robottal hegeszteni kell, akkor bizony meg kell tanulni egy kicsit hegeszteni. Mi a helyzet ebben az esetben mondjuk az adattudományok terén, hogy azt a domain tudást fel tudják-e, vagy hogyan tudják felszedni a kollegák, ami tényleg elengedhetetlen ahhoz, hogy az üzleti problémát megértsék?

Fodor Szabolcs: – Az biztos, hogy ahhoz, hogy sikeresen tudjunk végigvinni egy projektet, ahhoz elengedhetetlen, hogy a domain tudást valamilyen szinten megértsük. Azt hogy ezt egy adattudós önmagától megtegye, arra vajmi kicsi a lehetőség, vagy a valószínűség főleg egy ipari vagy gyártási területen. Egy kereskedelmi területen azért azt gondoljuk, hogy a tranzakciók, az eladások a hétköznapi ember számára kézzelfogható dolgok. Egy gyártásnál, ha emögött kémiai folyamatok zajlanak le, vagy amit te is említettél, hogy valami olyan folyamat, hogy azért nem biztos, hogy könnyű egy mindennapi tudással megérteni, vagy nem specializált tudással nehéz megérteni, ilyen esetben elengedhetetlen, hogy valaki a domain ismeretével támogasson egy-egy ilyen projektet. Ha indulunk egy ilyen projekttel, vagy bárki becsatlakozik egy ilyen projektbe adattudósként, akkor azt követelnie kell, hogy a domaint jól ismerő szakember legyen benn. És itt a következő pont, hogy tudjanak is szót érteni egymással, mert sokszor nagyon nehéz megérteni azt, ami valakinek teljesen természetes. Nekem teljesen természetes az, hogy hogyan fejlesszek egy modellt, de ezt nem biztos, hogy el tudom jól mondani egy mérnöknek, akivel együtt kell, hogy dolgozzak, hogy nekem milyen szempontokat kell vizsgálni. És ugyanez fordítva is, tehát hogyha egy mérnök elmondja, hogy ez a gyártási folyamat így működik, lehet, hogy átsiklik néhány apró dolgon, ami egyébként fontos lenne, mert őneki ez teljesen triviális, de mondjuk ezt az adattudós nem tudja. Szóval én azt gondolom, hogy ilyen speciális projekteknél elengedhetetlen, hogy képviseltesse a projekt az adott domainnek a szakértőjét, és hogy folyamatosan együtt dolgozzanak. Nyilván át lehet valamilyen szinten venni az adattudósnak ezt a domain tudást. Minden projektnél mi is úgy jöttünk el, hogy tanultunk nagyon sok mindent. Gyógyszeriparban csináltuk ezeket a projekteket, nagyon sokat tanultam a gyógyszergyártásról, de nem tudnék holnap gyógyszert gyártani, tehát hogy ettől függetlenül valószínűleg soha nem fogok olyan tudással rendelkezni, mint az adott domainnek az ismerője. Abban viszont nagyon sokat segít, hogyha következő alkalommal hasonló projekten dolgoznánk, akkor már azért eggyel mélyebb tudással, vagy eggyel alaposabb tudással tudnék elkezdeni projektet, és nem biztos, hogy mindent újra fel kellene venni. Nyilván minden egyes beszállítói oldalon nekünk a hatékonyságunkat két dolog határozza meg. Az, hogy mennyire tudunk gyorsan végigmenni az adathalmazon, megismerni, és gyorsan értéket teremteni, ez az egyik kulcs a hatékonysághoz. A másik az, hogy mennyire tudjuk gyorsan megérteni a domaint. Tehát fel tudjuk-e tenni a megfelelő kérdéseket, tudjuk-e irányítani az ügyfelet a megfelelő információátadásban, és egyáltalán képesek vagyunk-e felfogni – és hogyha nem tudjuk felfogni, akkor gyakorlatilag biztos, hogy nem lesz jó a projekt. Ez a kettő olyan kulcs, ami így beszállítóként nagyon fontos, de egyébként elengedhetetlen egy nagyvállalati csapatban dolgozó adattudósnál is, hogy az adott domaint amennyire lehet, az ő szintjén ismerje meg.

Masa Attila: – Abszolút, tényleg ez kiterjed azért sok minden más tevékenységre is. Közben úgy látom, hogy további kérdésünk már nem érkezett, úgyhogy én nagyon élveztem, nagyon hasznosnak találtam ezt a beszélgetést az elmúlt közel másfél órában. Szerintem sikerült jól körbejárnunk ezt a témát mindamellett, hogy próbáltunk racionálisak lenni, és a jelenlegi helyzetet feltárni. Mindenkit arra buzdítunk, hogy bátran vágjon bele ebbe, nyilván fontos, hogy legyen egy olyan konzulens a túloldalon, egy olyan beszállító, aki ezen az úton tudja fogni a kezét, és megfelelő irányba, főleg megfelelő pillanatban orientálni. Nagyon fontos, hogy megfelelő énképpel, illetve megfelelő elvárásokkal vágjunk ennek neki, és akkor a sikerélmény is sokkal közelebb tud kerülni mint ellenkező esetben. Úgyhogy köszönjük szépen, illetve köszönöm szépen.

Fodor Szabolcs: – Én is köszönöm szépen!

Nagy Géza: – Én is, és még nagyon sokszor megköszönni szeretném azt, hogy itt voltatok velünk. Rettentő tanulságos volt ezt beszélgetést végighallgatni. Nekem, mint akinek viszonylag kevés közöm van hozzá, még akkor is, hogyha szintén az IT-ban, habár nem IT területen, de közel hozzájuk dolgozom, rengeteg sok új információra tudtam szert tenni. És valóban a legfontosabb tanulság szerintem is az volt, hogy érdemes ebbe belevágni, csak meg kell gondolni, mert egyáltalán nem olyan rózsaszín ez a világ, mint ahogy az ember elképzeli magától. A nézőknek is köszönjük, hogy itt voltatok velünk. Zárjuk is le ezt a mai beszélgetést, további szép napot kívánok mindenkinek, és örülök, hogy itt voltatok.

Masa Attila: – Sziasztok!

Fodor Szabolcs: – Köszönjük a lehetőséget, sziasztok!