4 évad / 18. epizód – A leállás ára

Blogposzt megnyitasa · Epizod a YouTube-on


- Üdvözlök mindenkit, ez itt a Digit Podcast.

- Személyi László vagyok, a Future-NOW vezető partnere és társam a krimiben Szekér Zoltán, az OD&IT és a Sailing HAngar alapító ügyvezetője. Sziasztok, jó napot kívánok!

- A Digit Podcast célja, hogy akit nem elégítenek ki a felszínes cikkek és a hangzatos jelszavak, az közelebb kerülhessen a digitalizáció és az informatika mai meghatározó trendjeihez. Mi itt a mélyére fogunk ásni a dolgoknak. Egy súlyosabb IT idsidens ma már nem csak átmeneti fennakadást jelent, hanem akár egy egész cég fennmaradását is veszélybe sodorhatja.

- Kinek mi a feladata a megelőzésben, az azonnali intézkedésekben vagy akár a dokumentációban. Milyen felkészülési állapotban vannak azok, akikre vonatkozik a DORA vagy a Nis2, és azok, akikre nem vonatkozik, lehet-e pusztán pénzügyi alapon dönteni a megelőzés és/vagy a kármentés között. Hát van, aki vállalta, aki eljött és hágogathatjuk ebben a témában, és nemcsak egy konferenciakönyöklőnél, hanem itt mikrofonoknál is. Mórocz Máté a Neuronszoftver kommunikációs vezetője. Köszöntünk a Digit Podcast stúdiójában.

- Köszönöm, hogy itt lehetek.

- Köszi, hogy eljöttél.

- Hallgatsz-e podcastokat, Máté?

- Hallgatok.

- Hallgatok, köztük titeket. Segít abszolút például a Digit Podcast, nekem segít abban, hogy amúgy sok szolgáltató van nálatok, jelenik meg, és tök jó követni azt, hogy ki mivel foglalkozik, miben mélyült el, milyen trendekre ül föl, akár szolgáltatóként legyen az versenytársunk, vagy pedig egy teljesen más területet képviselő cég, úgyhogy titeket, illetve szerintem a politikai és a közéleti zajban most elég nehéz függetlenedni, mármint hogy egy kicsit kicsekkolni ebből a világból, de nekem erre az egyik bevált podcastem a Bánhalmy Kata Itt vagyok csatornája, nagyon-nagyon jó vendégeket hív meg, és inkább az életmód oldalról közelítenek meg nagyon sok témát, és szerintem egy ilyen üde színfolt a mostani nagy zajban.

- Köszönjük a tippet. Nem is olyan régen Marsi Tomit faggattuk, hát ez ilyen királyi többes, mert abban én kevésbé vettem részt. Különböző felmérések vannak. Van például a Checkpoint Cyber Security riport, és ha ezt nézzük, akkor azt látjuk, hogy csaknem 20 százalékkal több kibertámadás volt, oké, 20 százalék, de hogy ezen belül például a Hansonwerk kategóriában másfélszer annyi támadás volt, mint korábban. És hát azt tudjuk, hogy mondjuk a jéghegy csúcsa, amit úgy látunk is, ott akár egy-két napra is le tud állni egy szervezet. Nyilván nem ez a csúcstartó, tehát hogy több hónap a csúcstartó, vagy az örök élet is állítólag volt ilyen, aki már nem tudott fölállni, de hogyha viszont egy ár akár csak maradjunk az egy napnál. Egy napra leáll, és utána mondjuk még egy nap, mire újraindul, az azért tetemes költség, és akár az egész éves nyereséget el tudja vinni állítólag, de hogy ma azzal indítanék, hogy vajon ez csak riogatás, hogy valóban ekkora a veszély szerintetek?

- Sokkal nagyobb.

- Kövessetek minket a közösségi média csatornáinkon is.

- Három napig konferenciáztunk Mátéval, ahol meghívást kaptam az ő kerekasztalába, ahol gyakorlatilag ez volt a fő kérdés, amit körbejártunk.

- Igen, ez a három napra összezárva Mátéval, de jól sikerült szerintem.

- Itt csak egy óra.

- Igen, igen, igen. Nyilván Zoli szerintem sokkal mélyebben tudna a kiberszekurity oldalról nyilatkozni, és nagy nyitott szemekkel hallgatnám végig ezt, ahogy elmeséli, ugye cyberszekeret kockázat oldalról. Én amire sokkal jobban rálátok, és talán kevésbé is mondjuk gyártó cégek oldaláról, mi azért elsődlegesen inkább a banktól a kommunikációs szektorban vagyunk erősek, de van és volt is gyártó céges ügyfelünk, és én ugye nem is a támadás oldal, hanem az, amikor egyszerűen csak hagyják erodálódni azt az adott rendszert, ami amúgy lehet, hogy egy tök picike kis szoftver, fogalmazzunk így, tehát nem egy ilyen csillagromboló cserébe, hogyha ez sincs karbantartva, adott esetben elmegy a fejlesztő, ez lehet házon belül is, vagy egyszerűen valami nem várt olyan szervezeti változás következik be, nem tudnak megállapodni a beszállítóval és társai, akkor ez a rendszer egyik napról a másikra egy teljes kitettség. Tehát egyszerűen ez lehet támadási kockázat, lehet az is, hogy oké, valami elcsattan a kódban, és nincs, aki hozzányúl. És akkor ez a rendszer viszont megáll, és akkor megáll a termelés, vagy megáll a folyamat.

- Zoli sokszor műsorvezető nálunk, de ma kiaknáznám, hogy valahogy te is mondtad ennek a szakterületnek, hát régóta ismerője és művelője. Tehát azért ennek a leállásnak van ára. Ezt hogyan tudnád kézzelfoghatóvá tenni? Ugye mondtad, hogy sokkal nagyobb.

- Attól függ, hogy mit gyártunk. Ez nagyon fontos mondat. Hogyha azt mondjuk, hogy nem tudom én, Ford Focust gyártunk és egy órára kiesik ez a Ford Focus gyártás, az most akkor veszteség vagy nem? Kicsivel később kapják meg. De mit jelent akkor, hogyha mondjuk, nem tudom, csavarokat gyártunk, vagy mit jelent, ha tűket gyártunk. Tehát nem feltétlenül megfogható ez a gyártáskiesés, ezért azok a gyártási rendszerek OT oldalon, ezt ugye úgy hívják, hogy a Cyber Security részén az OT főleg a nagy kitettség, nehezen megfoghatók. De mégis kéne egy számot mellé tennem. És akkor mondok egy számot, és akkor nem gyártás lesz, jó? Tehát mi van akkor, hogyha egy élelmiszerbolt egy órára kiesik? 17 millió forint. Egyből érezhető ez a dolog, hogy akkor 17 millió egy kiesés miért esett ki? Hát mert nem volt aggregátor. De miért nem volt aggregátor? Most akkor az az IT-hoz tartozik, vagy az üzemeltetéshez tartozik. És itt kezd kicsit bonyolultabbá válni, főleg az igazgatói üléseken is ez a kérdés. Mi történik az IT-val? Milyen szervezeti egységhez van rendelve, hogyan alakult ki egy gyártásnak az informatikai vezénylése. Ugye a Mátéék, és még egyszer, tehát nagyon fontos, hogy mi azért sokat dolgozunk együtt, és ebben vannak a Legaszi rendszerek névre hallgató csodák.

- Örökzöldek.

- Az örökzöldek, amik valamikor meg lettek írva, valahogy működnek, jobb esetben még él a fejlesztője. Jobb esetben. És ugye többnyire a probléma az akkor keletkezik, amikor már nem. Merthogy hirtelen van egy olyan jellegű kitettség, amit vagy új rendszer bevezetésével lehetne megvalósítani, vagy pedig igazából nem is tudjuk a következményeit. És itt a következmények, az 1 óra 17 millió, ugyanígy lehet forintosítani azt az egy órás leállást a gyárban. Csak nem tudjuk, hogy mi az, ami a kieséskor nemcsak a gyártósor leállását hozza magával, hanem a beszállítói lánc leállását is magával fogja hozni, ami sokkal nagyobb összveszteséget fog előidézni.

- Én azt gondolom, hogy ennél a pontnál egy pici aláhúzást érdemes tenni. Merthogy még nem hangzott el az a szó, hogy kockázat, de már erről beszélgetünk a kibervédelmi részen is, mint sok más üzleti folyamatban nekünk meg kéne tudni mondani, hogy mekkora kockázatot futunk, és azzal arányosan kéne védekezni. Ezt már több adásban érintettük, és van több ezer szervezet Magyarországon, aki ezt nem hobbiból vagy szakmai elhivatottságból, hanem törvényi kötelezettségből kell megtegye. Tehát van mire figyelni. Na most ennél a kockázatnál gyakorlatilag fölértékelődik az a szakmai tudás, aki ezt így végig bírja gondolni, hogy oké, leáll a pénztárgép mögötti alkalmazásszerver. Most mondtam valamit. És akkor jó, akkor ha ez a dolognak a kockázata 10 százalék, oké, de mi a hatás? Na most ennek a hatásnak az elemzését el lehet intézni azzal, hogy jó, hát újraindítjuk. És akkor lehet. Jó, hát akkor körülbelül az történik, hogy jó, akkor a pénztárgép helyett biztos kell majd valami papírt intézni, és akkor valaki hátat fordít a problémának anélkül, hogy mondjuk megkérdezné a pénztárost, vagy a gazdasági igazgatót, ne adj isten megfelelési tanácsadót, tehá, hogy ez egy aláhúzás, hogy ez nem egy könnyű szakma, ez egy nagyon komoly szaktudás szerintem. A másik, amit így rákötnék, hogy tegyük fel, hogy ezt viszonylag jó szakemberrel tudjuk megcsinálni, és egy jó kockázathatás elemzésünk van. És akkor ott jön az igazi üzleti döntési szituáció, mert addig szerintem nincs is valódi döntés. Ott jön, hogy akkor most bevállaljuk és inkább a nagyon nehezen végezhető kármentéssel fogunk foglalkozni, ha lesz kár, vagy nem vállaljuk a kockázatot és a kitettségünket csökkentjük. Na most ide beszúrnék egy ilyen kérdést, hogy azért szerintetek a megfelelő helyen beszélünk-e erről? Nagyon sokszor azt hallom, hogy IT szakemberek, IT biztonsági szakemberek beszélgetnek erről, és kényelmes üzleti döntéshozók meg nem beszélgetnek róla. Ti mit láttok?

- Én most lehet, hogy egyre visszább lépek, mert szerintem tök jó, hogy behoztad ezt a kockázat gondolatmenetet, de ugye az volt az előző kérdés, hogy mi az ára.

- Ugye mi itt beszéltünk pénzügyi kérdésről, és akkor igen, hogyha egy nap a kereskedésben 17,5 millió forintnyi kiesés, vagy egy óra, oké, akkor az így egy szám. De ezt megint nehéz, ahogy Zoli is mondta, berakni a periódusos rendszerbe, hogy oké, de most akkor ez egy tiszta veszteség, ez egy nem megtermelt bevétel, vagy ez most hogy néz ki, a dolgozókat arra az egy órára kifizették, elküldték, mi történt vagy egy nap. Szóval ez szerintem egy ilyen bonyolult számítás, de én inkább beletennék sokkal kézzelfoghatóbb dolgokat is, amiről megfeledkezünk, mégpedig az ügyfelek. Lehet, hogy aznap volt valami kiesés, de mi van azokkal az ügyfelekkel, akiket aznap nem tudtunk kiszolgálni, és ők már nem lesznek tovább az ügyfeleink. Ez lehet egy gyártónál, például nem tudjuk teljesíteni a szerződéseket, egy gyártó cégnek beszállítói láncba ez nem fér bele. Tehát ez nem fér bele, hogy valaki egy ekkora kiesést, és ki tudja, hogy ennek a kiesésnek a leszállításbeli határidőkre mekkora hatása van, tehát itt az, hogy én nem tudom kiszolgálni az ügyfeleimet egy rendszer leállása miatt, vagy rendszerek leállása miatt, és mindegy, hogy ez most egy infrastrukturális kérdés volt, vagy egy szoftveres, tehát hogy egy alkalmazásbeli kérdés. Nem tudom ezt kiszolgálni, akkor ügyfélveszteség lesz, vagy ügyfél-élményveszteség. Őket kárpótolni. Azt mindannyian tudjuk, hiszen a piacról élünk, hogy egy új ügyfél megszerzése az sokszoros energia, idő és pénz befektetése ahhoz képest, mint amennyit mondjuk egy ügyfél megtartása igényel, vagy akár egy ügyfélnek való további értékesítés.

- És akkor, ha innen nézzük meg, hogy milyen lesz a reputációnk, hány ügyfelet veszítünk el állásaink vagy állásunk végett, és akiket nem veszítettünk el, ők mondjuk hogyan értékelnek innentől kezdve minket?

- Technikailag itt nagyon sokszor beszélek arról, hogy egy visszaállítási idő az mit jelent, és hogy mennyire összefügg. Ha egy KKV-t nem tudok visszaállítani mondjuk öt nap alatt. Akkor öt nap múlva az a KKV jelentős reputációs veszteséget szenved el, de a tanulmányok azt mutatják, hogy egy év múlva bezár. Ugyanezt egy gyár, ugyanezt egy bank, ugyanezt egy telekommunikáció, hát most gondoljuk végig, hogy telekommunikációs résznél nem tudtok telefonálni egy napig. El tudjátok képzelni, hogy mit jelent az a kiesés, annak a rendszernek a kiesése, ami az ügyfelekhez tartozó kimenő hívás számlázását méri. Most ez egy egyszerű rendszer, nem? Tehát végül is fölemelem a telefont, megnyomom a hívásgombot, fölveszi a másik, és elkezd ketyegni a másodperc. És mondjuk az a rendszer esik ki, ami ezt méri.

- Tudok hozni neked ezzel, és akkor mind a két szektort érintjük jó, amilyen példát.

- Mi csináltunk, direkt nem mondom a céget, és akkor így nem lehet megnézni, nem lehet támadási pontja, de hogy mi például egy olyan háttéralkalmazást fejlesztettünk az egyik cégnek, és a mai napig támogatjuk, ez most már nem is tudom, tizenvalahányadik éve működik, ami ugye pont egy olyan összekötő a bank és a telekommunikációs szolgáltató rendszerei között azért, hogy amikor te be akarsz lépni a netbankba, megkapd az SMS-t. És ugye itt a szolgáltató is, tehát a telekommunikációs szolgáltató is érintett, és a bank is érintett.

- Ugye kettős hitelesítés, tehát hogy biztonsági funkciója van.

- Hát hogy innentől most már belegondoltok, hogy mindegy, hogy a bank vagy a telkónak a rendszere durrant el most ilyen értelemben, te nem tudsz belépni a netbankodba, és akkor oké, hogy meg tudod mutatni azt, hogy hát bocsánat, de a szolgáltató partnerrendszere nem működött, ez ott már senkit nem érdekel. Szóval itt is ez a láncolat bent van, és azért tudom ezt mondani, mert hogy szerintem ennél a rendszernél volt egy olyan, hogy is mondjam, egy olyan pont a neuron életében is, amikor rájöttünk, hogy ki kell tudnunk azt, most értsétek jól, követelnünk, el kell tudnunk érni, ez sokkal jobb megfogalmazás az ügyfélnél, hogy értse meg, hogy miért kell folyamatosan nem túl nagy összegeket költeni arra, hogy ez a háttérben futó alkalmazás, ami 724-es, tehát ennek mindig mennie kell, ez ne épüljön le, ne avuljon el, mert amikor hozzá kell nyúlni úgy, hogy hagytuk elavulni, ezt szerintem mondjuk egy autótulajdonos pontosan tudja, ha nem viszi szervizbe az autót, és utána kijön már egyre több hiba, akkor egyben az gigaköltség tud lenni, meg iszonytató nagy szívás, mire elérjük a kívánt eredményt.

- És mivel áll az autó.

- Így van, így van.

- Ugyanezt mondjuk egy logisztikai cégnél képzeld el autóra. Tehát, hogy a legnagyobb költsége az állási idő, és akkor ehhez képest a szervizben áll is az autó, nem is tud mozogni, a sofőrje is idézőjelben kényszerszabadságon van, nem tudja teljesíteni a fuvarokat, tehát hogy bármelyik aspektusára ki tudjuk terjeszteni magának az üzletnek ezt, hogy mit jelent maga az állás, mint fogalom, mennyibe kerül?

- Nagyon köszönöm ezeket a példákat, mert ezek megmagyarázzák még több aspektusból, hogy miért olyan különleges szakmai tudás az, és miért olyan fontos szakember az, aki meg tudja mondani, hogy mi a hatása, hogy mi az ára a leállásnak, ha nem is mindent forintban, de a reputációt is lehet forintosítani, de egy ponton már nem kell, mert mindenki az asztal körül tudja, hogy miről van szó.

- Ez a Kibersecurityből fog jönni először, és úgy hívják ezt a három betűs, hogy Bia. Tehát a business impact analysis, ez az üzleti hatáselemzés, ami egy elképesztően fontos dolog, hogy az üzletmenet-folytonossághoz skálázom be azokat a kockázatokat, amikkel együtt tudok élni és vagy nem, meg azokat az árakat, meg költségeket, amik ezeknél, mint incidens megjelennek.

- De szerintetek a KKV is érti, hogy ez biznisz impect, tehát üzleti hatáselemzés? Mert a pénzügyi szektorban leégett.

- Ezt akartam mondani, most lehet, hogy itt Zolival megnyitjuk a népszerűségi versenynek a teljes.

- A legjobb spirálja.

- Abszolút, de nem. Vannak nagyon durva szélső értékek még ebben a nagyon kontrollált mezőnyben is, hogy fogalmazzak így. Ahhoz tudok jönni kapcsolódni, amit Zoli mondott, hogy a nagyvállalatban sem biztos, tehát ezt nem evidens, hogy tudják azért, mert az eszközrendszer, hogy hogyan kell ilyen különböző hatástanulmányt, elemzéseket elkészíteni, meg végrehajtani a rendszereik kapcsán, az az eszköz nem evidens, hogy ki is van használva minden rendszer kapcsán. Én most ide egy ilyen nagyon pici zárójelet megnyitok, mi most pont a múlt héten is Zolival azért. Zoli abban segített nekünk, hogy egy kutatás-fejlesztési projekt keretében egy olyan indexet tudjunk létrehozni, amivel pont hogy tömegesen világíthatók át a rendszerek, és indikátora legyen annak, hogy adott esetben mi annak a rendszernek az élettartama, ha minden így megy tovább, ahogy most.

- Ezt magyarul minden dominóról meg tudjátok mondani a sorban, hogy mennyire inog.

- Így van, így van, mert itt igazándiból azért azt semmilyen vezető nem szereti látni, hogy mondjuk az ő rendszerparkja az pirosban világít és egy csomó. És ez amúgy nem azt jelenti, hogy mindegyik kritikus és bármikor megállhat, hanem az, hogy ezzel igenis foglalkozni kell. Éppen ezért nekünk sem az a célunk, hogy azt mondjuk mindenkinek, hogy hoppá, gyerekek, hát nálatok itt 100-ból 98 az rossz helyzetben van, tehát nem ilyen a cél szolgáltatói oldalról sem, tehát mi sem vagyunk ebben érdekeltek, hanem inkább az, hogy oké, azt lássák, hogy mik azok a rendszerek, amikhez viszont tudjanak belül priorizálni.

- Tehát magyarul egy innovációt hajtotok végre, mert itt azért elhangzott, hogy kutatás-fejlesztés zajlik. Ezt azért örömmel nyugtázzuk, hogy vannak ilyen cégek, mint a neuronszoftver, és akkor ez egy olyan innováció lesz, ami az üzleti hatáselemzést tudja tömegesen sok-sok szoftvernél egyszerre megcsinálni?

- Mondhatni igen, az, hogy most ez pontosan egy ilyen hatáselemzés lesz, vagy pontosan miket fog figyelembe venni, mérni, értékelni és ezek alapján kalkulálni, hogy a vezető tiszta döntési szituációban üljön a helyén. Tehát, hogy ne arra legyen utalva mindegy, hogy ez középnagy, bármilyen vállalati vezető, ne az határozza meg az ő büdzsétervezését, döntését, hogy akkor ebben az idei évben a negyedévben melyik szoftver modernizációja, kiváltása, támogatása lesz a prioritás, ne az határozza meg, hogy őneki Béla, Balázs, bárkicsoda kolléga mit mondott, hogy hogy is állunk ezzel a rendszerrel, mondjuk technológiailag.

- A nagy cégeknél is azért, hogy mondjam, ilyen típusú gondolat, mondjuk ilyen építőiparra gondolok, ott nem nagyon tud jól hatáselemeződni, hogy ilyen csúnyán mondjam ki, merthogy technikailag nem biztos, hogy ezt akarják hallani. Valahogy úgy beszélgettünk erről, hogy van egy autóm, ami mondjuk fölvillan egy sárga csekken ginlámpa. És akkor most mi a teendő egy sárga csekken ginlámpánál? Hárman ülünk itt, és mindenki máshogy cselekedne. Csak azzal, hogy kimondtam, hogy sárga és csekken ginlámpa. De hogyha hozzáteszem és elkezdem ezt mélyíteni, hogy jó, de ez egy 1999-es autó. Egyébként van benne egy szenzorhiba, amiről tudunk, nagyon nem kell vele foglalkozni, mert a szerviz sem tud vele mit csinálni, merthogy egyébként a szenzor rossz, tehát gyári hibás, nem tudnak újat csinálni, hiszen már nem gyártanak, akkor ugye van egy ilyen vállalható kockázat, itt lehet inkább megérteni ezt a vállalható kockázatot, hogy meddig tudok én ezzel az autóval úgy elmenni, hogy elkezdek más szenzorokról információkat gyűjtve menni az úton. Hol van az a kritikus pont, amikor figyelnem kell, hogy az Álmoskönyv szerint három lámpa kigyulladása esetén már ne menjek tovább. Tehát, hogy ugye ezt egy informatikai rendszeren belül nincsenek ilyen jelzőlámpák, többnyire azt mondjuk, hogy az informatikus próbálja meg a legjobb tudása szerint akár pénz nélkül is rendben tartani a rendszert. De az informatikusnak hol van az az utolsó lehetősége, ameddig be tud avatkozni? Hol van az a pont, amikor már nincs több ember, akihez ő fordulni tud? És itt jön be ez a típusú gondolat, hogy ennek a megelőzésére van ez az innováció Mátééknál, amivel oda tudnak menni, és azt tudják mondani, hogy figyelj, ebben a rendszerkörnyezetben ilyen típusú hatáselemzések mellett fogtok tudni hatékonyan működni, de el kéne kezdeni a következő stratégiát, víziót és missziót kialakítani, amihez maga a működési környezet átalakítása 2026-ban meg kell, hogy történjen. Miért kell megtörténni a működési környezet átalakításánál? Nagyon egyszerű. Az 1962-es vágógép egyszer csak meg fog halni, mert nem lesz hozzá fizikailag több számítógép a bontóban. És ez a nehéz ebben az informatikában, hogy hogy tudom én azt vizualizálni egy boardnak, akit nem érdekel ez, merthogy hát figyeljetek, akkor majd egy 65 ezer soros Excelben levezetjük a gyártást. Egyébként a minőségbiztosító az majd szépen kimegy, és ugyanúgy meg fogja húzni ezeket a kis jelöléseit, és majd nem tudom én, cetlizünk, nem kell ezt informatikai rendszerbe tenni. Tehát visszaállunk egy régebbi, egy korábbi, egyébként nem mondom, hogy hatékony vagy nem hatékony verzióra, de ez egy bekap mód. Meddig lehet ezt fenntartani?

- Hát meg hogy van-e backup mód. Tehát volt-e olyan mentés, vagy volt-e olyan korábbi verzió, ami tényleg az, mint amit hisznek, hogy kábé most fut.

- Látjuk meg, hogy a cetlizéssel az azóta aláírt szerződésekben lévő szállítási határidők is tarthatók-e, vagy csak a tíz évvel ezelőtti szállítási határidő.

- Nagyon élesen a határ aközött, hogy meddig tudok fenntartani egy gyárat működőképesen, és hol van az, amikor a tulajdonosok azt mondják, hogy jó, de hát nem éri meg fenntartani, és inkább elköltöztetem egy másik országba.

- És azt gondolom, hogy ezt egy nagyon fontos valahol folyamatosan vizsgálni, hogy igaz-e, hogyha digitalizálok, akkor ettől hatékony leszek, és hogyha hatékony vagyok, akkor a digitalizáció az valójában működteti-e a gyárat, vagy kell bármilyen beavatkozás vagy háttérsegítség, ami egyébként jöhet a szoftveroldalon.

- Szerintem ez az adás ma attól is nagyon izgalmas, hogy folyamatosan fogunk pulzálni a gyártás, az építőipar, meg a bankok világa között. Én most egy picit visszakanyarodnék a banki pénzügyi világra. Az előbb szerintem elég jól megvilágítottuk, hogy nem minden kockázat forintosítható, de majdnem minden, és van egy nagy mértékű kockázat abban, hogyha egész egyszerűen hiteltelenné válok, ha elvesztem a bizalmat, még akkor is, ha egyébként rögtön nem látszik a számokban, mert másnap vagy harmadnap már úgy termelek, mint tegnap, de néhány hónap vagy egy éven belül már meglátszik a reputációs veszteségnek a pénzügyi hatása is. Na most ugye van a pénzügyi szektorban Dora, egyébként meg sok más helyen ugyanis kettős szabályok, amiben önmagában rengeteg kockázatminimalizáló előírás van, és egy kicsit volt bennem egy ilyen érzés mostanában, hogy nagyon sokat beszélünk ezekről a jogszabályokról, és nagyon sokat beszélünk ezekről az elég technikai előírásokról, és kezdek látni inkább azt mondom egy ilyen veszélyt, hogy az üzleti döntéshozók, akár egy bankban például, annyira lefoglalja őket ez a mennyiségű technikai előírás és száraz kockázat, hogy az ügyfélélményre, a reputációra és társaira esetleg már nem marad idejük, és elfelejtik, hogy azzal is kéne foglalkozni, és ott vannak, hogy jaj, de jó, végre most eljutottunk oda, hogy compliant vagyok, vagy bocsánat, megfelelek a Nis 2 vagy a Dorea elővárásainak, hátradőlök, és elfelejtem ezeket. Ti éreztek ebben egy ilyen veszélyt?

- Veszély az lehet, van. Szerintem az egy nagyon érdekes kérdés nyit ki, hogy itt valóban ezek a megfelelések elindítanak-e olyan rendszerfenntarthatósági biztonsági folyamatokat, legyen szó ez nagyon elavult rendszerek technológiai modernizációjáról, vagy tényleg nagyon-nagyon kockázatos elemek teljes kiváltásáról bocsánat, ezek valóban elindulnak, vagy pedig, és itt jövök szerintem Zoli kedvenc témájára, vagy pedig ki lett pipálva. De az egy fontos dolog, hogyha a szabályozás túlnyomja, amit te is mondtál, Laci, túlnyomja a rendszert, túl sok mindennek kell egy időben holnapra megfelelnie, akkor viszont belátható, hogy akkor ennek valami a kárát fogja látni, hogy ez éppen az ügyfél élménye lesz, a szolgáltatás gyorsasága, minősége, mert valahonnan az erőforrásokat adja.

- Az új funkciói?

- Vagy az új funkciók. Én most, hogyha ebben kéne valamit mondani, én most azt gondolom, hogy azért elég turbulens volt az elmúlt jó néhány évben ez a jogszabályváltozások és egyebeknek való megfelelés itt Magyarországon, ezért azért nagyon sok nagyvállalat, hiába zárnak akár bankok is rekord bevételű nyereségű éveket, az újba, az innovációba, az új fejlesztésekbe azért nagyon óvatosan tolják bele az erőforrásokat, valahol persze érthető okokból, mert ha holnap jön egy olyan szabály, ami pont elcsuklóztatja ezt az innovációs kísérletünket, akkor az egy kidobott pénz volt. Szóval érthető szerintem a vállalatoknak az ilyen innovációs és új fejlesztési nyitottsága vagy ilyen fékezett habzású hozzáállása, de az is látszik, hogy nem lehet túl hosszan megállni és nem előre menni, mert akkor viszont regionálisan lesz versenyképességi hátrány. Szóval emiatt én tudom, hogy most nagyon elkanyarodtam ettől a megfelelési témától, de sajnos a megfelelési kérdésben.

- Ez egy ilyen kérdés volt.

- Szerintem mi nagyon nem ott tartunk, hogy bármit is lehetne ezzel kezdenünk, hanem sajnos ezek a játékszabályok. Szerintem szolgáltatóként nekünk abban kell segíteni a vállalatokat, hogy ne felejtsék el, hogy azért a cél az ne a megfelelés legyen, hanem a fejlődés megfelel a szabályoknak.

- Igen, igen, igen.

- Nagyon nehéz kérdés ez, és egyetértek Mátéval.

- Az egyik oldalon az történik, hogyha van egy túlszabályozott bármilyen policy, én nem akarok kimondani három betűs szavakat kettővel végződve.

- Tegyük fel, hogy van.

- De tegyük fel, hogy van. Abban azért ugyanúgy, mint ahogy a megboldogult GDPR, amit újra visszahozunk, meg néha elfelejtünk, erodálódik a hatásfoka annak a szabálynak, amiért létrejött. Pedig jó, hogy létrejött, de a differenciálás az nincs meg. Nem tudok differenciálni Nis 2-ben egy valóban ötfős KKV és vs. a nem ötfős KKV között, ami rossz. Ettől nyilvánvalóan mindenki meg akar felelni, és nyilvánvalóan mindenki megpróbál valamilyen módon megfelelni. És itt valamilyen módon van a probléma akkor, amikor történik egy incidens. És az egyik az valamilyen módon felelt meg, a másik meg valóban megfelelt, és jobb esetben, mivel valóban megfelelt, fönnakad az incidens, fönnakad legalább a jól megfeleltnek a rostáján, miközben az, akinek csak papírja van, ő nem is tud róla, hogy ez megtörtént. Ez a probléma. A másik probléma, hogy egy bizonyos szervezeti kultúrában nincs helye annak, hogy ellentmondjunk. Ellent lehet, csak a munkahelyünk megőrzése érdekében nem javasolt. Ha ebben a szervezeti kultúrában jelzem, hogy probléma van, akkor nem a problémára lesznek szenzitívek, hanem rám, mint a probléma forrására. Ergo megint abban a helyzetben találom magam, hogy a rossz hír hozójaként rövid időn belül el fogok halálozni ebben a szervezeti kultúrában. Ezt az egyensúlyt szerettem volna elmondani, hogy az egyensúly az azon múlik, hogy fékek és ilyen együtthatásoknak az összessége. Ha túl sok a fék, akkor azért vágjuk el, mert nem haladunk. Ha nincsenek fékek, meg nem tudunk megállni. Tehát, hogy valahol a kettő között van az igazság. Ha használok egy 1990-es rendszert, akkor el kéne tudnom fogadni, hogy nem biztos, hogy még öt évig fogom tudni használni. De valahol el kéne kezdenem számolni a leváltásával. Ugye a konferencián az is szóba került, hogy a jelenlegi AI projektek körülbelül 95 százaléka sikertelen. Azért sikertelen, és ezt úgy mutattam be valahogy a Mátéék kerekasztalában, hogy van egy ilyen projektpurgatórium, ahova bekerülnek ezek, én PET-projekteknek hívom őket, hogy mindenki ki akar próbálni, hogy a pipa meglegyen, hogy igen, én már megpróbáltam az AI-t, és két dolog. Az egyik, hogy nagyon hasznos, én vagyok a császár, és tudok tovább golfozni. A másik, hogy hát ez mekkora egy hülyeség, hát nehogy megvedd! Ugye ez a kettő van. De technikailag azért nagyon kevés az a vállalatvezető, aki azt tudja nekem visszacsatolni, hogy figyelj, két új mérőszámom van, és amellett azt tudom mondani, hogy a használhatóságom ennek a mérőszámnak a hatására azt mondja, hogy ez a szoftver, mert nevezzük ezt szoftvernek, három lépésen belül megtérülést fog hozni. És ugye ez a kérdés.

- Ez most az öt százalék.

- Ez az 5 százalék, igen. Tehát az az 5 százalék az valójában azért tud sikeres lenni, mert technikailag új mérőszámokat hozott a rendszerbe, és az üzleti innováció menedzsmenthez tartozó üzletfolytonossági menedzsmentet is kiegészítette azokkal az információhalmazokkal, amik eddig nem léteztek.

- Meg erről is beszélgettünk már talán, meg nagyon sok podcast szól arról, hogy éjjel csodafegyver és csapból is folyik.

- Nekem az alapkérdésem is ez volt a konferencián is, hogy oké, de most eszköz vagy megoldás? És ebben viszont a mi eredményeink jelenleg azok, hogy elképesztően jól használható az AI arra, hogy jól meghatározott módszertani keretek között nagyon konzisztens kódot fordítson le egy nagyon régi, akár általunk sem ismert technológiából egy olyanba, amihez viszont már értünk. És itt ez például nálunk egy hatalmas áttörés, és ez ugye lehetne, mondhatnánk, hogy a fejlesztésben, akár a dokumentációk elkészítésében ez elképesztően nagy segítő eszköz tud lenni, rengeteg embernapot, rengeteg átfutási időt lehet ezzel megtakarítani, szóval egy kiváló eszköz, de pusztán azért, de egyszerűen még nem egy megoldás. Tehát kell oda az a szenior ember, kell oda az az architek, kell utána oda az a tesztelő vagy tesztmenedzser, aki utána meg is nézi, hogy ez a rendszer, amit ez így átforgatott, az úgy működik-e? Tényleg az? Tényleg tudja? Vagy baromi jól néz ki, mert most már nem egy ilyen dosszos ablakba ülnek majd a kezelők, a rendszer felhasználói, hanem egy nagyon szép, új, modern dizájn valamiben, és amikor rákattint a másik gombra, akkor pont nem az történik, mint aminek történnie kell. Szóval nem akarom nagyon messzire vinni ezt a témát, de hogy igen, szerintem fontos lenne belátni a vezetőknek, hogy brutál jó eszköz, csak találjuk ki, hogy mire kell nekünk eszköz, mi az a folyamatunk, amiben ez brutál mód felskáláz, és ne a cél legyen az AI, hanem egy eszköz legyen a cél elérésében. Én inkább így lőnék ezzel, de igen, az tény, hogy a csapból is ez folyik.

- Elérkeztünk az adás feléhez, ideje megpihennünk, és a személyes szálat én beleszőném. Kávé. Mindannyian tudunk hozzászólni. Szerintem az az én néhány kérdésem, hogy mikor kezdtetek el kávézni egyáltalán, emlékeztek-e az első kávéra? Én már most mondom, hogy nem, nagyon régen. Hogy változott az ízlésetek, esetleg a gombnyomás, ez az őrlés között van valami különbség, vagy nektek preferencia van-e meg úgy mire figyeltek így kávék kapcsán?

- Kotyogós az volt a kezdet, mint mindenkinek, hiszen közel az 50-hez szerintem ott még nem voltak ilyen automata gépek. Maga a kávézáshoz tartozó illatélmény az a régi ABC-kben található darálókból érkezik. Ugye ott nem feltétlenül volt ilyen mostani vákuumfóliázott verzió, hanem ilyen nagy kiszerelésű szemes kávé volt, amit hogyha haza akartál vinni, akkor rádaráltad otthon, aztán jött ennek is a gépesített verziója, de tömegével az ABC-kben voltak fölszerelve ilyen óriási színes gépek, amivel brutális hangerővel, de lehetett kávét darálni, és akkor ez továbbfejlődött. Hosszú időn keresztül a szarvasi kávéfőző volt a best off a kávéfőzésben, az az egy darab gomb, amit az Ikarusban is használtak, és a Szarvasi Café főzött is, az mindent vitt. Hát most meg már nem tudom, a múltkor voltunk valahol a feleségemmel kávézni, és igazából az ütötte meg a fülemet, hogy nem az volt a kérdés, hogy kávé, hanem hogy hány bárral főz a kávéfőző kávét, és hogyha nem annyival főzi, akkor már hogy az, akinek a hangját így hallottam a háttérben, érdeklődött a pincértől, hogy hány báros a kávéfőző, és hogy akkor ő nem hajlandó kávét inni, inkább kiment erről a szórakozóhelyről, vagy étteremből, vagy tök mindegy, hogy mi volt. Nekem nincsenek ilyenek. Én szeretem a kávét. Szeretek sok kávét meginni, és Giuseppe barátom óta risrettó az a kávé minden nélkül.

- Én arra jutottam, hogy szerintem a kávé az kb. majdnem minden embernél meglehet egy ilyen íve, hogy mikor miért. Szerintem, ahogy te is a kotyogóstól indultál, tehát van az az időszak, amikor mindegy, ami van.

- Tehát, hogy amilyen kávé éppen, hogy ez most porból jött, darálóból, kotyogóból, elkészítve szinte mindegy. Tehát ez, ami van, azt a következő, az a praktikum, minél gyorsabban egy gombnyomásra legyen, és akkor nem tudom, ilyenkor bejönnek a kapszulások például, és utána szerintem aki rajta marad ezen a kávét rekken, akkor utána elindul ez a megérése, és akkor lesz gourmet, és akkor fontossá válik, hogy milyen pörkölésű, hány barral és társai. Én nem tudom, hogy ezen az úton most hol vagyok, de én most amúgy tök kevés kávét iszom az elmúlt jó néhány évben. Régen volt ez az igyunk egy kávét, ez volt a meeting apropó, hogy fogalmazzunk így, és akkor ittam tonnaszámra kávét, de szeretem, de hogy nem a hatásáért, semmiért, hanem mert ez volt az apropó. Most pedig, ami nekem az örök klasszikus, igen, az a ristrettó minden nélkül, de nekem a nagy kedvencem főleg nyáron, ez a Presso Tonik.

- Tényleg, és én úgyszintén, tehát egy két éve, három éve kezdtem el ezt, hogy melegben szívesen presszót vonnék, és még mai napig kapok kérdést, hogy az mi, tehát hogy amikor mesélek róla, nyilván nem a pincérek azért, bár egy helyen még a pincértől is megkaptam nemrég. A másik meg, hogy én nem emlékszem, mikor kezdtem el. Nekem a kotyogós az nagymamám kicsi gyerekként, tehát hogy így fölfelé nézve van meg az emlék, hogy kotyog a kávé, de soha nem ittam otthon. Valahol munka közben kezdtem el az első munkahelyek egyikén, de így nem tudnám megmondani. Ami most nagy találmány, idézőjelben, hogy rátaláltam, ez a helyes kifejezés. Ezek a filteres kávék. Én először azt hittem, hogy az ilyen bénázás, meg nem tudom milyen francia flancolás. De amikor voltam egyszer egy ázsiai ilyen kávézóban, ahol ugye óceán és tenger és kereskedő nem, és olyan szintű aromák jöttek ki abból a fél literből, ami teljesen más, majdnem mint a tea, csak kávéból. Na, ez nekem nagyon tetszik, hogy aroma és ízvilág, és nem tudom. Visszatérek Mához. Tegyük fel, hogy vezetőként mondjuk fejlődni akarok, mert nem akarom már homokba dugni a fejem, van jó hatáselemző kollégám, aki meg tudja mutatni nekem, hogy meg tudjuk előzni a bajt, érdemes megelőzni a bajt. Na most hogyan lehet jól betervezni ezt. Tehát már odáig eljutottam, hogy kockázatarányosan akarok bizonyos dolgokat kivédeni előre, megelőzni. Inkább mondjuk beruházásnehéz dolog ez, inkább működés nehéz ez az IT biztonság, milyen időtávokban lehet itt büdzsét tervezni? Vannak-e mondjuk benchmarkok? Ez egy külön érdekes kérdés nekem, hogy tudom-e viszonyítani, hogy amit én most beterveztem, az hozzám, az én iparágamhoz, cégméretemhez, bármihez képest jó, vagy nem jó, vagy. Na, értitek.

- Én nagyon gyorsan elkezdem, és szerintem Zoli erre rá fog ülni erre a gondolatmenetre. Szerintem rendszerek, legyen az biztonságára, fenntarthatóságára, működésére, ha iparági benchmarkból indul ki valaki, akkor olyan, mintha elfelejtené, hogy őneki mi a biznisze és mitől sikeres. Tehát hogy a sales marketing büdzsét se iparági benchmark alapján húzunk be, hanem hogy mi kell ahhoz a célhoz, amit el szeretnénk érni, ha ahhoz nagyobb költés kell, mint az iparág, vagy mint a benchmark, vagy mint a tavalyi év, akkor többet kell betervezni rá, mert fontos, hogy a cél határozza meg, hogy milyen költést húzunk hozzá, és a cél az meg lehetővé tesz, hogy költsünk is rá annyit, praktikusan én úgy gondolom. Tehát én az üzletből indulnék ki, és nem abból, hogy hát ennyit szoktunk. Ugye ez azért nagyon jellemző, hogy oké, tavaly ennyi volt, most akkor legyen plusz két-öt valahány százalék, és azt így költsük el. Ahelyett, hogy azt néznénk meg, akár tényleg itt elemzések, bármi, vagy az üzleti működésből kiindulva, igazából mire van szükségünk?

- És ahhoz húzzuk be, hogy akkor milyen költések kellenek, hogy elérjük azokat a célokat, amiket mi tervezünk a rendszereink kapcsán, vagy a megfelelés, vagy a bármi tekintetében?

- Kettős a válasz. Az egyik, hogy ha rendszert tervezünk, akkor hibázunk, mert stratégiát kell tervezni. És a stratégiában van egy olyan rendszer, amit fejleszthetünk. Az a modell, amit fejlesztünk, az egyik fele az Mátééknál van, ami kifejezetten azt a benchmarkot méri, állítja föl, megcsinálja a nullás pontot, hogy honnan és hová kéne ezt a szoftvert, ami jelenleg is fut, átvizsgálni, fejleszten, kicserélni. Ugye az, amit szándékosan úgy fogalmazom, hogy nálam van, az pedig a vezetői oldal, és a vezetői oldalnak az általam kifejlesztett mérőszáma az az, hogy egyáltalán kész van-e a szervezet arra, hogy bevezessen bármit. Ez nem csak szoftver, ez nem csak hardver. Ez arról szól, hogy az a hat vezető egyáltalán hogy látja a céget. Erre van egy mérőszám, egy mutatószám, egymásra tudok rakni pókháló diagramokat, amiben meg tudom mondani, hogy ez a projekt, amit ő kitaláltak, ez nem indítható el. Ez egy jelentős mondat, mert nagyon máshogy nem csinálják, és ez egy gyors teszt, egy lakmuszpapír, ez nem hónapokat fog igénybe venni, hanem fejenként hat percet, és utána kap egy kézzelfogható eredményt, ami ahhoz kell, hogy erről a stratégiáról tudjunk beszélgetni.

- Kövessetek minket a közösségi média csatornáinkon is.

- A probléma az azzal van, hogy egy cég nem játék. A cégen belül, ha bevezetsz egy darab szoftvert, azért már felelősséget kell vállalnod. Mindegy, hogy kifizeted-e a bevezetésnek az árát vagy nem, mert azt valamilyen módon így is, úgy is meg fogod fizetni. Az a szoftver ott marad. Azt vagy lekapcsolod, vagy leamortizálod, vagy kivezeted, vagy bármit csinálhatsz vele, de technikailag te lőttél valamit, ezt hívom én a projektpurgatóriumnak, amikor bevezetsz valamit, és ott van. A másik oldalon az üzleti. Mit értünk szoftverhatékonyság alatt? Szoftverhatékonyság alatt értjük-e, hogy a bevezetés után a fluktuáció megnő vagy nem. Ugye értitek? Ezt nagyon kevesen mérik. Egy jól bevezetett szoftver után vonzóvá válik a munkahely. Egy rosszul bevezetett szoftver után nem válik vonzóvá a munkahely, de nem is találsz új munkaerőt a hiány pótlására. A harmadik, az egy, ugye vannak kvalitatív, meg kvantitatív mérőszámaink. Használod-e? Technikailag neked hány szoftvert kell használnod. Bemész a céghez, van egy felületed, amin mindent el tudsz intézni, vagy három másodpercenként ki kell belőle lépned, mindegyikhez egy új jelszó van, mert ez meg a mentális egészséget befolyásolja, bár azért 2026-ban illik már beszélni arról, hogy a generációk közötti különbséghez tartozó mentális egészségprogramok mit jelentenek egy szoftver bevezetés esetén?

- Nem beszélve arról, hogy találkoztam én is tényleg nem egy munkahelyen olyannal, hogy a kolléga duplázódik, merthogy a szoftverben, amiről beszélünk most éppen, csak az egyikük igazodik el, annyira bonyolult, és részben egyébként biztonsági funkciók miatt, ezért a másik, ha meg kell oldjon valamit abban a szoftverben, akkor mindig odahívja. Most akkor a munkahatékonyság, még ha a fluktuációt nem is nézzük, akkor a fele, abban az időben konkrétan a fele. Visszatérnék egy picit a tervezéshez, hogy milyen időtávon, illetve beruházásként vagy működési költségként nézzük mi ezeket üzleti vezetőknek. Hogyan lehet ezt elmondani, vagy akár gazdasági vezetőknek, ami ugye egy külön nehéz pálya szerintem.

- Szerintem ez egy nagyon érdekes kérdés, én találkoztam a legfurább gondolkodásmódokkal ezen a területen.

- Nézzük.

- Tehát, hogy nagy multinacionális vállalati szinten, például érdekes, hogy ahol van egy nagyon céleredmény-orientált IT-hoz kapcsolódó vezető, akkor őt például ez határozottan nem érdekli, mert azért van a pénzügyi-gazdasági osztály, hogy találja ki. Őneki megvan, hogy mire van szüksége, és hogy ennek a technikai elszámolás az hogy fog megtörténni, hogy ez majd egy beruházás, amit aktivál, az őt például nem érdekli. Szerintem mindenki csinálja azt, amihez ért. Az üzleti döntéshozók alkotnak egy stratégiát, egy üzleti stratégiát. Az ehhez kapcsolódó kiszolgáló rendszerek, ami lehet nemcsak informatikai rendszer, hanem bármely más rendszer, illetve maga a szervezet, az pedig kapcsolódjon ennek a célnak az eléréséhez. És az, hogy ezt milyen finanszírozásból tudják megoldani, arra meg különálló szervezeti egység van jellemzően azért azoknál a cégeknél, akiknél mi ott vagyunk, tehát hogy nem is biztos, hogy jó az, hogyha az IT vezető próbálja meg kitalálni, hogy ez most hogy lesz financiálisan a leghatékonyabb. Erre tudok hozni nagyon jó példákat akár egy ügyféloldalról, amikor az előbb elhangzottakat képviselte a vezető, és ő képes volt átütni azt, hogy oké, találják meg ehhez a forrást. Nem volt benne a Budgetben. És akkor találtak egy olyan zsebet, akkor megértettük az üzleti célt, megértettük az üzleti eredményt, és gyakorlatilag újrakódoltak teljesen újraértek egy szoftvert, mert a vezető látta, hogy amilyen hatékonyság kell, amilyen terhelést ki kell tudnia majd szolgálni egy év múlva, látva a számaikat, hogy ez a rendszer mekkora igénybevételnek van kitéve, előre menekült. De hát nyilvánvalóan ezt nem lehet csak úgy megoldani, hogy kezdjük el újra, ezt senki nem hagyja jóvá, de kért extra forrásokat annak érdekében, és akkor az ő kreativitása volt, hogy hogyan, miért, mire, de gyakorlatilag egy éves munka, ami a normál támogatás, normál fejlesztés mellett zajlott, ugye ebben mi egy hibrid együttműködésben vettünk részt, és egy év múlva mit lehet az üzlet? Az üzlet nem vesz észre semmit. Hiszen nem állt le, számukra nem lett gyorsabb, de ha megmutatja majd nekik a vezető a számokat, hogy tavaly ilyenkor mennyi tranzakció ment végbe, milyen futási sebességgel, mennyi hibával és a többi, ahhoz képest, na ott megjönnek majd mögé a számok, és akkor az idő beigazolta ezt a vezetőt, aki előre tervezett, előre nézett, és nem pedig büdzséből indult ki. Tehát, hogy őt nem korlátozta a büdzsé.

- Zoli kiegészítené bármivel?

- Hát kiegészíteném, mert igazából nagyon sok helyen kezelik magát a szoftvert érzelmi kérdésként. Ez nem érzelmi kérdés, ez egy tök egyszerű dolog. Hát merre halad az üzlet?

- Hogyan akarom kiszolgálni magát az ügyfelet. Most az ügyfél ebből a szempontból, ha hatékonyságot szeretnék nézni, és nagyon közgazdasági alapon, akkor termelési görbében megnézem, hogy egy-egy új embert veszek föl, vagy szoftvert vezetek be pont. Ez a kérdés. Ebben nincs érzelem, ebben az az érzelem, hogy azokat a munkatársakat meg tudom-e tartani, de most már 2026-ban nem ez a kérdés, hanem hogy föl tudok-e venni. És ez óriási probléma. Tehát, hogy nem biztos, hogy be fogok tudni tanítani olyan kollégát, akit eddig betudtam. Nem biztos, hogy meg fogom tudni hosszabbítani a terhelhetőségét, hiszen nem biztos, hogy fiatalodik. Ugye? Ezek mind-mind kérdések, de ez nem érzelmi, ez racionális, előkészítő, üzleti döntés. Az üzlet rábízza az IT-ra ezeket a döntéseket. Miért? Hát az IT-tól, ha megkérdezem, hogy melyik a legjobb, nem tudom én, szerver, akkor mond egyfajta verziót, de nem tudja, hogy mire méretezze a terhelést. Hát akkor most kinek a feladata az üzletnek, vagy az IT-nak? Ebben van egy eltolódás. Az üzleti vezetőnek igenis egy picit szenzitívebbeknek kéne lennie arra, hogy milyen mérőszámokban akarja az IT teljesítményét mérni. Egy egyszerű példát szeretnék mondani. Az IT azt mondja, hogy vezess be új tűzfalat. Mennyibe kerül? X millió forint. Hát ez drága. Na de miért kell bevezetnem egy új tűzfalat? Hát az IT sem azért teszi a javaslatot, mert feltétlenül jókedvében be akar vezetni egy új tűzfalat, hanem azért, mert az a terhelés, amit a jelenlegi bír, arra nincs mérőszámom, de túlterhelhetem a rendszert. Oké, bevezettem az új tűzfalat, és azt mondom, hogy figyelj, Áti, azt szeretném mondani, hogy nekem ez akkor hatékony, hogyha - nem tudom én - 96 százalékkal csökken a támadások száma, ami bentre átjön. Ugye értitek? Akkor ez egy mérhető valami. Ugyanígy el tudom mondani, hogy annak idején ez nem volt olyan régen, 2020, ugye mindenki tudja, mi ez a dátum. Azon vitatkoztam egy IT főnökkel, meg az üzlettel, hogy a négyezer ember bentről kifelé dolgozik, vagy a négyezer ember bentről, vagy kintről befelé kezd dolgozni. Hát ez nem ugyanaz a paraméter, nem ugyanaz a tűzfal, nem ugyanaz a szolgáltatási szint, és nem ugyanaz az elérési szint. Az egyiknél egy jelentős beruházást kellett végrehajtani, ellenben 2020-ban ők voltak az egyetlen cég, akik azt tudták csinálni, hogy mind a négyezer ember hazament dolgozni. Minden további nélkül. És hogy mi a várható bekövetkezési esélye ennek a dolognak? Tehát azért ez egy nagyon fontos mondat, hogy amikor az üzlet velem kezd el beszélgetni, azon kívül, hogy megkapja a pókháló diagramokat, hogy egyáltalán készen áll rá, ahogy beszélgessünk. A másik, hogy fölteszem a kérdést, hogy mi a várható bekövetkezése annak az eseménynek, amire ők így ennyire készülnek, mert van, amikor egy százalék, akkor hát jó, én értem, de az ő pénze.

- Ez egy nagyon jó példa, mert beszéltünk már gyárról, beszéltünk már boltról, beszéltünk már bankról, nem beszéltünk munkavégzésről. Az is egy leállás ára, hogy én most be tudok-e léptetni négyezer embert, mondjuk az ügyfélélmény.

- Ez ügyfélélmény.

- Ezt mondtad, hogy ügyfélélmény.

- Az a belső ügyfélélmény, de az rögtön külső is, tehát a négyezer ember jelentős részének a munkájának a meg nem történtével az ügyfél is fog találkozni. Jó, szerintem ezt körbejártuk. Még visszatérhetünk rá, de nekem van még kérdésem. Méghozzá a felelősség kérdését én elővenném. Mert általában az előadásokban ezt úgy finoman szokták kezelni. De ez a Digit Podcast, mi itt a mélyére tudunk ásni a dolgoknak. Kinek mi a feladata? Megelőzés, azonnali intézkedések, illetve dokumentálás, bármelyikről tudunk beszélgetni, de hogy ugye vannak ilyen határok, és tulajdonképpen a jó folyamatmenedzsment is, meg a jó kockázatkezelés is, az pont a határokat teszi átjárhatóvá, vagy legalábbis kapcsolja össze a határ két oldalán élőket, tehát mondjuk a fejlesztőket az üzemeltetőkkel, a külső beszállítókat a belső IT-val, a megfelelősi tanácsadót az üzlettel és így tovább. Tehát, hogy kinek mi a feladata, de másképp is föl tudom tenni ezt a kérdést. Tehát, hogy azért nagyon gyakran a technológiai hibák mögött húzódik egy rossz döntés, ami a megelőzést elmulasztó döntés. És hogy vajon hol van a gyenge láncszem egy szervezetben szerintetek? Lehet-e ilyet mondani, mert az nyilván nem szép dolog, de ha igaz, akkor mondjuk ki. Hol szokott egy szervezetben a leggyakrabban ez a határ, ez megállítani döntési folyamatokat, vagy felkészülést, vagy megelőzést. Ez ugyanaz a kérdés, még egyszer mondom.

- Fú, sok minden tetted föl egybe, de én lehet, hogy hozok egy sztorit, ami lehet elsőre olyan lesz, mintha nem is idejönne, de mégis csak az állatorvosi lovak.

- Hiszen ez a felelősség kérdését szerintem erősen jól meg tudja világítani. Visszamegyek a bankhoz. Banknál új fejlesztés, legyen ez mobil applikáció, direkt nem akarok ennél pontosabbat. Legyen ez egy új fejlesztés a mobil applikációban. Benne egy új termékkel, jó? Tehát, hogy ebben van már üzleti termékfejlesztés, hiszen ez egy banki termék, van benne egy informatikai fejlesztés, ami leköveti, hogy ez a termék elérhető legyen az ügyfeleknek, és ezután jól fusson végig.

- Így van, mondjuk mobilbankban. És ugye bekapcsolódik a marketing. Hát na most kell megbombázni, hogy az ügyfelek számára frissen elérhetővé tett üzleti és informatikai termék, na vegyétek, vigyétek. És itt jön elő, hogy végigfut ez az egész processz marketing, izomból elkezdi küldeni, rácuppannak a netbankba vagy a mobilbankba az ügyfelek erre az új termékre.

- Fölszólal ez egy siker.

- És összeomlik a rendszer.

- Eddig a pontig. És megáll. Az egész mobilbank mondjuk éppen ledobja a láncot, merthogy akkora terhelést kapott egy olyan nem kitesztelt, nem biztos, hogy jól felskálázott funkcionalitás, ami akár az egészet fogja és akkor kikapcsolja. És akkor itt oké, ki a hibás? A marketing? Hogy miért adott el ennyit, vagy miért promózta be ennyire? Vagy az üzlet, hogy rossz döntést hozott, vagy az IT, hogy nem mérte föl, hogy erre mennyien fognak rácuppanni? Szóval, hogy itt most három különböző területnek a felelősségét próbálnánk megkeresni egy ilyenben, és azért szerintem a közelmúltban is, de akár évekkel ezelőtt is banki, de valószínűleg más szolgáltatónál is. Lehet tehát ilyenekkel találkozni. És akkor nagy kérdés, hogy kié volt a felelősség. Én azt szoktam mondani, hogy bármilyen leállás, bármilyen incidens, az nem biztos, hogy egy felelőse van, az biztos, hogy rosszul meghozott, vagy nem időben meghozott döntések sorozatának a végeredménye. Úgyhogy és innentől, hogy ebben a több döntésben vagy egy döntési láncban amúgy milyen területeid vettek részt, és akkor itt mehetünk az informatikától a Cison át, és akkor mondhatunk még elég sok néhány betűszavas pozíciót, vagy konkrét területet. Szerintem az valahol egy picit mindegy is, merthogy itt sokan vesznek részt egy döntésben, és ezek vagy nem vettek részt, vagy nem hozták meg, és ezért.

- Nagyon nehéz, de egyetértek. És most kiegészítem. Általában ezek a típusú projektek presztízs projektek is.

- Presztízs projekt miatt kialakul egy ilyen belső vakság, amikor nem akarunk hallani különböző dolgokról. És igen, a projektvezető az van prés alatt, hogy most akkor ő ennek feleljen meg, vagy egyébként a kritikus gondolkodást próbálja meg erőltetni. Nemrég írtam erről egy cikket, hogy technikailag a projektvezetőnek nincs köze ahhoz, hogy a talpfa mi van ráírva, milyen a sín, de elkezdik neki mutogatni a TGV-t. És hogyha nem teszi föl azt a kérdést, hogy te ezen szeretnél-e járni, akkor szerintem hibázik a projektvezető is. Merthogy technikailag a TGV 400-zal fog menni azon a talpán és azon a sínen, ami egyébként 140-re van hitelesítve. Egy bizonyos pontnál, amikor értsétek jól, életveszély kerül előtérbe, és életek kerülhetnek ilyen szempontból veszélybe. Igen, ilyen kritikus ez a terület. A másik oldalon pedig egy ilyen reputációs veszteség. Hogyha a marketing nem tudja nekem megmondani, hogy az adott időszakban mekkora volt a csúcsterhelésem, mondjuk legyen egy weboldal, ne applikációról beszéljünk, most legyen egy weboldal. Tehát hogyha nekem nem tudja megmondani, hogy egy weboldalnak mekkora volt a maximális terhelése, akkor az IT-nak honnan kéne tudnia kinek a felelősséget? Ott ülnek egy boltban. Valaki meghoz egy döntést valamiért, hogy le kell cserélni. Nyilván ebben nem a vezető a felelős, merthogy ő azt mondja, hogy hozzál ide egy olyan technológiát, ami ezt ki fogja szolgálni. Az IT a felelős, hogy nem kérte be az összes információt? Hát lehet, hogy az IT a felelős, de hogy kitől kellene elkérni? Tehát definiált az az üzleti ember, akinek rendelkezésre áll? Ugye a gazdasági igazgató alá szokta besorolva lenni a legtöbb IT. Ez ténykérdés. Abban az esetben, hogyha az IT nem tud teljesen önálló egységként működni, és nem is vesszük számításba, mert a gazdasági vezér vagy a gazdasági vezérhelyettes képviseli az érdekeit, akkor az is kérdés, hogy a gazdasági vezér nem annak a számoknak szeretne-e megfelelni, ami számára kedvező ebben a projektben. Ezt el tudom neked mondani ugyanígy, hogy azt a típusú weboldal load balancer, ugye ez a terheléselosztásos dolgot. Ez egy nagyon kemény hely volt, és a nagyon kemény Ciso sem szúrta ki, hogy a loot balancert nem cserélték. Technikailag enélkül a projekt abszolút halott volt. És mindez azért, mert a második körös árajánlatból húzták le. Tehát az első körös csillagrombolónak minősítették, a második köröst pedig már alulbecsülve adták be és fogadtatták el. De olyan vészmegoldások hiányoztak belőle, amik az árazásban értsétek jól, az összbüdzséhez képest tényleg pár százalékot jelentettek.

- Ide hadd ugorjak még be egy fejessel melléd, mert ez egyből fölvet egy olyan piaci kérdést, ami az árazás, a tendereztetés, mert ugye nagyvállalati szinten gyakorlatilag teljesen mindegy, hogy miről van szó, ott kell a három versenyző és tender, amivel alapvetően szerintem nincs baj, hiszen a verseny az előre visz.

- De nem tudom, hogy ti mennyire találkoztok ezzel. Mi azért a versenypiacon látunk olyan meghökkentő ajánlatokat bizonyos kiírásra, amit hogyha felelősségteljesen szeretne megvalósítani egy szolgáltató, és nem arról van szó, hogy a százszoros extraprofit tartalommal, hanem tényleg szeretné valaki jól megcsinálni, és beírsz egy számot, és utána látod, hogy milyen végszámmal vagy megtudod, milyen végszámmal vitték el ezt a projektet. És akkor így végiggondoljuk mondjuk szakmai csapattal, hogy ez hogyan? Tehát mi ennyire elmentünk mellé a dolognak? Merthogy nagyon nagy nagyságrendi különbségek, mit tudom én, a mi árunknak a nem tudom, akár a 40 százalékát. Tehát ez annyira pici, és bocs, többen is adnak, most akkor a normál árhoz képest brutál kedvezőt, és akkor utána jön az, hogy hát nem készült el a végére, meg nem is fog. És hát vagy elfog, de hogy mi történik ilyenkor? Megrendelő, benne van már azért pénze, plusz csomó ideje. Onnan van kitáncolás, valódi kitáncolási lehetőség? Tudjuk, hogy van, mert azt lehet mondani, bumm, köd, bér, helló, új beszállító. De hogy a presztízsprojektnél? Megvan előttetek, amikor azt mondják, hogy oké, kuka. Tehát nem nagyon. Viszont ezek meg olyan dolgot eredményeznek, hogy lesznek ilyen félig kész rendszerek, amiket utána toldozni-foltozni kell, mert amúgy meg a büdzsé arra lett betervezve, amilyen ajánlatot ők kaptak, és akkor a szolgáltató lehet, hogy vagy elér egy ilyen vendorlock szituációt, amiben egy olyan függőség alakul ki, hogy hát kedves Megrendelés, azt szeretnéd, hogy ez be legyen fejezve, akkor még itt ilyen díjak vannak, és így megyünk majd tovább. Tehát megfordul a ló, ez nem egy jó együttműködés felé mutat.

- Nem, és azt nagyon köszönöm, hogy ezt a példát behoztad, mert jó lenne arról is két szót hallani a hallgatóságnak, hogy szerintem ez nem alapvetően a szállító hibája csak, hogy akkor van ilyen gonosz csúcsszállító, aki ilyen marketing stratégiát alkalmaz, hogy jól alámegyek, árnok oszt majd jól meg kötbérezted, ha akar, de egyébként meg itt van nem tudom, jó pár érvem arra, hogy ebből majd hogy lesznek pótmunkák. Az építőiparban is a beruházások nagy része a pótmunkákból térül meg sajnos, de hogy én azt gondolom, hogy a felelősség legalább annyira ott van a megrendelői oldalon is, hogy hogy működtethetek egy olyan rendszert, hogy akár sorozatba belefutok egy ilyen szituációba, amibe ha csak így az asztalnál minden más nélkül megkérdeznek, hogy bele akarsz futni ebbe, akkor 89 százalék, hogy azt mondom, hogy nem, nem akarok belefutni, azt mégis belefutok háromszor, akkor ez csak a szállítók problémája? Nem, ez az én problémám is. És ugye visszakanyarodva, összefoglalva, amit nagyon jól összeszedtetek szerintem mind a ketten. Nekem az jön át, ami az én zsigeri érzésem is, hogy nincs egy felelőse annak, hogyha az IT biztonsági kockázatokat nem látjuk, vagy nem jól lőjük be. Ennek mindenki a felelőse, végeredményben az ügyvezető vagy a vezérigazgató a felelőse, ami bizonyos szabályozásokban egyébként meg kifejezetten ki is van mondva. Egyszerűen azért, mert ezeket a határokat átlépni, ő tudja úgy működtetni a szervezetet, hogy beszéljenek egymással, és ha nem értettek szót, akkor másnap még egyszer beszéljenek egymással, de ne menjen el mindenki duzzogni a saját sarkába és haladjon tovább látszólag a projekt, miközben valójában ott van egy nagy piros keretű fehér folt a projektben, amit mind a két vagy három fél tud, csak éppen mehet tovább az élet, mert valaki ezt hagyja odafönt.

- Jó, szerintem erre lehet, hogy nem tudunk sokkal több határozottsággal reagálni, de ennyivel tudtunk.

- Ugye abszolút tudunk erre mondani, mert pont ez a terület az, amikor a projektköltségbe nem fér bele ez az előkészítés. Tehát 14 dimenzióban tudom megmondani öt különböző területről, hogy milyen típusú hibák várhatók, mert ez egy kicsivel komplexebb elemzés, ahol tényleg, miután egyszer így a szoftver bevezetés nem volt sikeres, két év alatt majdnem becsődölt a cég a szoftver bevezetésétől, csináltunk egy utólagos elemzést, mert akkor már tényleg a lét volt a tét, és nem számított az összeg. Megcsináltuk az elemzést, és egy adott pillanatban lehetett látni, hogy a projekt, akinek a felelőssége volt, nem volt biztos, hogy a projekt sikeres lesz. Így álltak neki. A vezetőség nem volt elkötelezett a projekt mellett, és minden végrehajtó terület azt mondta, hogy ez neki nem jó és nem használható. Olyan költségről beszélünk, ami mondjuk egy vezérigazgató nyaralásának az ára. Jó, tehát hogy nem arról beszélünk, hogy ebből új, nem tudom én, villát kell venni, és azt kell megtartani, hanem egy olyan költségről beszélünk, ami abszolút megér annyit, hogy az elköltött pénzhez képest 2 százalék? Hogyha ezt nem tervezzük be, mint egy háznál, hogy egy háznál, ha fölújítok egy házat, nem tervezek be plusz költséget. Nem tervezek oda egy ilyet, hogy mi van, ha nem tudom én, még egy gerendát be kell raknom. Ez a teljesen normális egy szoftver bevezetése előtt pedig nem csinálom meg, a mérnöktől nem kérdezem meg, hogy egyébként képes-e az alap elbírni ezt a házat, amit szeretnék bővíteni. És ez a szemlélet, ezt gondolom egy picit ilyen fejlesztendőnek talán.

- Csak hogy legyenek számok is ebben az adásban, csak a top 500 magyar vállalatnál, ott ilyen átlagban 250-es darabszámban vannak rendszerek.

- Most tudunk olyan magyar bankot, ahol ez a szám ezer fölötti. Most nyilván ebben benne vannak a nem egyedi és ilyen, tehát tényleg nem csak az egyedi szoftverek, meg ebben persze benne vannak olyanok, ami nem tudom, összesen kettő funkciója van. Tehát hogy nyilvánvalóan azért itt a komplexitás, a bonyolultság az nagyon vegyes. Amikor ekkora a rendszerszám, és át kell látni. Sok esetben az sem biztosan megmondható, hogy az a szállítóval még van-e szerződés. Attól még tud működni az a rendszer, tehát azért mondom, amikor kétbites valami, akkor az lehet, hogy senkinek föl nem tűnik, vagy hogy az a kolléga, aki 15 évvel ezelőtt a saját munkájának a megtámogatására összeprogramozott valamit, ami után tök jól sikerült. Tehát, hogy jól sikerült ez a cucc, és egyre többen elkezdték használni. De hát az nyilván nem arra lett kitalálva, és itt jön elő, amit a Zoli mondott, hogy ez architekturális kérdéseket vet föl. Tehát tök jó, hogy van egy karácsonyfánk, amire most már tényleg ráakasztottunk annyi díszt, mint az állat, mert baromi jó. Tök jó. De egy fa ekkora volt, és nem 456 millió díszre kitalálva. És akkor utána nem kell csodálkozni, hogyha ez nem is összedől, de hogy így meglehetősen. És éppen emiatt szerintem egy kulcsdolog, és ebben nagyon örülök, hogy a Zolival mindig tudunk együtt menni. Gondolkozzunk már előre, és az egy egységnyi ma elköltött forint az 90 százalékos biztossággal megelőz egy holnap, egy hét múlva, egy év múlva, két év múlva bekövetkező 250 vagy még több egységnyi költést. És szerintem a mi felelősségünk most például ebben a beszélgetésben az az, hogy arra hívjuk fel a figyelmet, hogy a prevenció az sokkal jobb, mint reakció, amikor már valami gáz van.

- Ezekre a rendszerekre tényleg rá kell tenni a fókuszt, ha kell, akkor tömegessé válik. És elég egy lépés is. Nem muszáj mindent egyben kezelve azonnal megoldani, vagy gigaberuházásokat kiírni erre.

- Logikáját nézzük végig. Szerintem ez elképesztően fontos, hogy van, amikor a karácsonyfa. Az egyik programozó kitalált egy dolgot. Most maradjunk a banki vonalon. Kitalálta, hogy akkor a fiókok között legyen hírküldés. Volt tíz fiók, most van 140. Tök máshogy működik a hírküldés, de akkor jó, akkor a hírküldést kössük össze a valamivel. Erre ki lett találva még egy program. Erre kitaláltak még egy programot, meg még egyet, meg még egyet, az evolúció ahogy fejlődött. Meg mondjuk megvettek még egy bankot, azt beolvasztották, abban is tetszett valami, annak a felülete tetszett. De technikailag mi maradt? Az a folyamat, ahogy elküldöm a híreket. Most akkor nézzük már végig, hogy a funkcióhoz akarjuk ezt az egészet csinálni, hogy a hírlevélhez keresünk egy folyamatot, a folyamat alapján megnézzük, hogy kiket érint, milyen döntési lánc van benne. Igen, ez lassabb, valóban, igen, vagy ott van a másik, amikor azt mondjuk a programozóknak, hogy na, akkor csináljatok rendet. És hogy ez kicsit olyan, mint amikor a Star Warsban a nemezeket, a droidokat keresik.

- Tehát, hogy hogy lehet rendet csinálni ebben, de komolyan. Tehát, hogy nem ismersz egy kódsort, de egyébként majd te át fogod tudni vizsgálni. Igen, a Mátét át fogják tudni vizsgálni, AI-jal még gyorsabban át tudják vizsgálni, és hogy ebben azért 2026 egy olyan fogyasztói társadalom, hogy három másodpercenként új tartalomnak kell kijönnie.

- Minek akarunk megfelelni? Ez a kérdés. Minek akarunk megfelelni?

- Nekem egyébként az ilyen banki meg nagyvállalati programozói körből sokkal inkább az az idézet jut eszembe a költészetből, hogy szabadság teszi nekem rendet. Ez a leggyakoribb, hogy én márpedig azt szeretném fejleszteni, ami nekem kedves, vagy úgy szeretném olyan platformon, ami a nekem kedves, az upgritek nekem ne jöjjön azzal, hogy az itt ilyen, meg ilyen sztenderdekbe ütközik. A másik, ami eszembe jutott, nagyon jó a karácsonyfás hasonlat, hogy lehetőleg olyan fát kezdjünk el további díszekkel megbombázni, aminek van gyökere. Tehát nem egy ilyen kis vacak három lábon áll, és nem tud növekedni, hanem egy növekedésképes és meggyökerezett fára próbáljunk újabb és újabb díszeket. A végére még hagytam egy ilyen kérdést, hogy ilyen kicsit keretes szerkezete legyen a mai adásnak, mert hogy egyébként el tudnánk kalandozni még az architektúra felé, lehet, hogy egy egész adást meg tudnánk erre tölteni, mert az, hogy hány rendszer van, az egy dolog. Az, hogy annak hány interfésze van, az egy másik dolog, mert az általában többször annyi, nem beszélve arról, hogy milyen interfész típusok vannak, és így tovább. Na de beszéltünk az elején arról, hogy Nis 2 meg Dora megfelelés, és kíváncsi vagyok most így aktuálisan arra, hogy mit láttok a piacon, hogy milyen állapotban vannak azok a cégek, akikre ez vonatkozik, bennük megindult-e a tökéletesedés, meg a másik, hogy esetleg van-e ilyen, ahogy az angol mondja, spinlover hatás, vagy ilyen átgyűrűzés, hogy mivel nagy visszhangja van ennek, mivel sok partnert beszállítót, megrendelőt, nem tudom kit érint, ezért olyan cégek is, akik egyébként nem kellene, hogy megfeleljenek ezeknek a szabályoknak. Egyes más dolgokban elkezdtek-e fejlődni.

- Kövessetek minket a közösségi média csatornáinkon is.

- Különböztessük már meg ezt a Nis 2-t, meg a Dorát.

- Pénzügyi intézeteknél Dora van. Ezt az MNB felügyeli. Ott előírják, hogy milyen szabályozatoknak, milyen szabályozóknak, milyen paramétereknek kell megfelelni, és ha nem tetszik, akkor viszontlátásra. Tehát ott, ha nem akarsz részt venni a pénzügyi tevékenységben, persze nem kell megfelelned, ha meg részt szeretnél venni, akkor pedig meg kell felelned. Ezért az IT biztonsági felelős, mint szerepkör, a Ciso, mint szerepkör, ugye nem kérdés. Az, hogy a Compliance oldalon hogy kapcsolódnak be, milyen riasztási láncok vannak, milyen incidenskezelési kötelezettségek vannak, az sem kérdés. És van a Nis 2. Ugye a Nis 2 alapjában véve egy ilyen amerikai nagyvállalatból érkező szabályozás kicsit hasonlít az ISO minősítéshez, ezt implementálta az Európai Unió, de mi ez a tagállami hatáskörbe helyezte, mi bevezettük, de nincs különválasztva, hogy mit értünk ugyanaz alatt a vállalat alatt. Tehát ugyanannak kell megfelelnie egy négyfős vállalatnak is, akire vonatkozik a táorszám, a bevétel és a létszám, meg ugyanannak kell megfelelnie egy egyébként ugyanezeknek a paraméterek mellett megfelelő nagyvállalatnak. És nyilván akkor, amikor egy rendszerbesorolást kell megcsinálnod például a Nis 2 esetében ahhoz, hogy a kritikus rendszereid egy-kettő vagy egyes, kettes vagy hármas besorolásba tartoznak, akkor nyilvánvalóan egy hármas besorolású rendszer fenntartása az már jelentős költséget fog adni. Ugyanez a kérdés a szoftvernél. Tehát, ha és amennyiben te Nis 2 köteles leszel, be is vezetik, és nem checkboscom pliennszel szeretnél megfelelni, akkor logikailag neked a szoftvertermékeidre vonatkozó kritikus infrastruktúra átvizsgálásra is szükséged van. Ez a gap elemzés, ami a Nis 2 felmérés első lépése. Ebben nem árt tudni, hogy hány darab szoftvered van. Na most nézhetjük ezt most szigorúan kiberszekurity szemmel megnézhetjük, mennyiből tudom fizetni az alkalmazottaimat szemmel. De a végeredmény, hogy ha nem gondolkozunk ebben kiberszekurity nézőponttal, akkor problémáink vannak, függetlenül attól, hogy Nis 2-nek, Dorának vagy Izzónak hívom ezt?

- Összefoglalom, amit megértettem. A Dorában jól állnak a cégek, mert különben már nem lennének. A Nis 2-ben kevésbé, és az átgyűrűzési hatásról most ne beszéljünk.

- Nagyjából így.

- Máté, kiegészítenéd szoftveroldalról valamivel?

- Én egyszer már beemeltem ezt, hogy tök jó lenne, hogyha nem elsődlegesen pénzben néznék meg a rendszerek leállását vagy folyamatok leállásának az árát, hanem tényleg közelítsük meg, hogy miből van a pénz, az ügyfelekből.

- És nekem ez egy ilyen örök vesszőparipám, de tudom, hogy Zolinak is ez az ügyfélélmény. Nálunk a Neuron Best például egy ilyen top keepje, hogy milyen az ügyfélélmény, mert az ügyfélélmény határozza meg azt, hogy a mi ügyfeleink például mennyire ajánlanak minket akár házon belül. Azért ugye mi nagy szervezetekkel dolgozunk, tehát azt tökr, tehát nem triviális az, hogy azért, mert én az adott céggel dolgozom, ott mindenhol, a több ezer fős szervezeti egységeken belül mindenhol ismernek engem, vagy elismernek. Szóval nagyon-nagyon fontos ez a reputáció házon belül is, tehát mármint az ügyfeleink házán belül, hogy ez rendben legyen, mert én azt gondolom, hogy az elmúlt időszak gazdasági környezete szerintem baromira megtanította mind a szolgáltató cégeket, mind a nagyon nagy ügyfélszámmal dolgozó, és kvázi nekünk, ugye célcsoportunknak, hogy ahonnan a bevételed származik, hozzá kell a legkedvesebbnek lenni, és én nagyon-nagyon örülnék annak, hogyha a teljes magyar gazdaság sokkal inkább egy ilyen, hogy is mondjam, az ügyfeleire támaszkodó lenne, és kevésbé mondjuk támogatásokra, és elképesztően olcsó hitelekre, ami gyakorlatilag mondhatnánk azt, hogy részben ingyen pénz. Szóval én nagyon versenypárti vagyok, szerintem az elmúlt időszak nagyon rá is mutatott arra, hogy padlógázon kell nyomni a versenyt, különben nagyon gyorsan elhullanak, akár egészen nagyvállalatok is ebben a futásban, és nagyon fontos, hogy ebben az óriási számú rendszerben, amiben működnek a cégek, és itt volt szó róla, hogy prevencióval gondolkozzanak és ne reakcióba, hogy a hídon akkor megyünk át, amikor odaértünk, ezt a gondolkodásmódot érdemes oda, hogy nézzük át, legyen átnézve, legyen karbantartva, mi ugye alapvetően ezzel foglalkozunk, hogyan modernizáljunk úgy, és tegyünk fenntarthatóvá szoftvereket, hogy az ne egy egyszerű nagy kiadás legyen, és ne egy ilyen sokkterápia, amiről itt többször beszéltünk. Úgyhogy szerintem, ha van fő üzenetem, akkor én ezzel engednék el mindenkit majd ennek a podcastnek a meghallgatását követően.

- Az ügyfélélmény jó végszó. Ez van srácok, ennyi fért a mai adásba.

- Köszönöm, hogy itt lehettem.

- Köszönjük, hogy itt voltál a Digit Vodka stúdiójában.

- Köszi!