A TC2 jövőképe az IT beruházások kapcsán

Ü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 Solutions é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. A Először is minden kedves hallgatónknak szeretnék köszönetet mondani, merthogy így szeptemberre csak a Spotify-on elértük a háromezredik végighallgatást, ami az átlag egyórás időtartammal értendő, és egyébként közel 200 ezer perc, amit már a hallgatásunkkal töltöttek.

A további számok terén a Youtube-on, ahol a feliratok miatt már 30 országból néznek minket, ami egy váratlan meglepetés volt nekem legalábbis. Hát az epizódjaink úgy együttesen a 40 ezredik végighallgatásnál járnak, úgyhogy hála és köszönet. Mai napra milyen a sikeres IT beruházás, ha egyáltalán lehet ilyenről beszélgetni. Hogyan számolunk megtérülést, milyen időtávra szól egy beruházási döntésünk, nő vagy csökken a piac itthon, és mekkora a verseny, hogy hozunk szinkronba cégvezetést IT beruházási célokkal, illetve hát unalom ellen mi is jó orvosság vagyunk, azt hiszem. Vendégünk ma Révész Róbert, a TC2 alapító ügyvezetője és Sepsy Károly, a TC2 technológiai igazgatója, amit a tengerentúl CTO-ként is lehet hívni, de itt a stúdióban nem.

Köszöntünk benneteket a Digit Podcastban.

Sziasztok! Köszönjük szépen, hogy itt lehetünk.

Köszönöm szépen.

Akkor mi kettővel hozzájárultunk ehhez a 40 ezres hallgatottsághoz.

Köszöntöm a hallgatókat, a hallgatóságot. Szerintem ez egy egyébként egy remek fölvezetés volt, és azért is gondolom remeknek, mert egy rakat kérdés rögtön eszembe jutott ezzel kapcsolatban, amit most nem megválaszolni szeretnék, de nem is költői kérdésnek szánnám, inkább csak azt mutatnám, hogy hányféleképpen lehet erre a témára rácsatlakozni. Itt most beruházásról beszélünk, vagy felhőinformatikáról, hogy ezek ellentmondanak egymásnak, vagy egymást támogatók. Olyan kérdések jutottak eszembe az elmúlt közel tíz év tapasztalata alapján, hogy tudják-e a vállalatok megfelelő tempóban lekövetni a piaci változásokat. Vagy hogy egyébként mi számít megfelelő jó sebességű és minőségű termék és szolgáltatás fejlesztésnek majd vállalati működésben.

Vagy hogy egyébként az informatikai tudás, az informatikai folyamataink ezeket jól tudják támogatni? És akkor eljutottunk megint odáig, amit időszakonként szerintem elővesz a szakma meg a piac, hogy lehet az IT vezető egy innovátor a vállalat működésében? Hogy lehet az IT vezető egy innovátor a vállalat működésében? És aztán hogyha az egészet úgy keretbe foglalnám, akkor mi most itt a felhőinformatikát, az Amazon Web Services-t képviseljük ebben a beszélgetésben, hogy hogy van az, amikor egy kicsit úgy ebben az újragondolásban kilépünk a korábbi áramból, és nem mindent magunk akarunk megvenni, integrálni, felépíteni, működtetni, fejleszteni, hanem mi van akkor, hogyha ebben az újragondolásban eljutunk odáig, hogy vannak nekünk üzleti igényeink, hogy lehet ehhez a megfelelő jó szolgáltatást hozzá vásárolni.

Tehát ez a szokásos, ez a Bild or by Karcsi szokta ezeket szakmai szempontból rendszeresen megvilágítani.

Én ezzel kezdeném, hogy még egyszer köszönöm a lehetőséget, hogy itt lehetünk, és rengeteg kérdés jutott el eszembe, ezért külön hálás vagyok.

De nem nekünk kell megválaszolnunk, ugye?

Persze, hát ezekről fogunk beszélgetni.

Nagyon jó ez a kérdésfelvetés. Tudniillik ugye mindannyiunk gyakorló szakember is a saját szakmájában, és pont így kiegészítjük egymást. Ráadásul nagyon sok olyan konferencián vagyunk jelen, ahol egymás után jövünk a sorban és szólalunk meg hasonló témákban is. Mit gondoltok, hogy a cégvezetők mennyire vannak edukálva ebben a kérdésben, hogy felhőinformatika, meg költségvetés tervezés.

Mit tapasztaltok a saját praxisotokon belül?

Azt hiszem, van az az örök klasszikus, mindig mi is idézzük, mások is Henry Fordnak ez a szokásos mondata, hogyha megkérdeztem volna a vevőimet, akkor ők valójában egy gyorsabb lovat szerettek volna inkább kapni. Hosszú utat jártunk be ebben az elmúlt közel tíz évben, és nagyon sok csalódás volt ennek az utazásnak az elején, leginkább azért, mert hogy ez jó vagy rossz naivitás-e vagy sem, de hogy hittünk az elemzői vélekedéseknek, hogy egyébként, ami nagyon fontos, hogy nem 30-35 év a tudástranszfer, és akkor egyébként a felhőinformatika megérkezett a régióba, Magyarországra is, úgyhogy hát akkor ezt jobbító szándékkal el kellene kezdeni a vállalatok javára hasznosítani, és akkor kiderült, hogy tulajdonképpen nincsen semmifajta tudás.

Nemcsak szállítói tudás hiányzott, hanem sokkal nagyobb kockázattal a vevői, tehát az ügyféloldali, a megrendelői tudás is hiányzott, és akkor kiderült, hogy amikor elkezdünk beszélgetni, hogy mi a felhő, meg mi nem a felhő, és akkor jönnek a kérdések, amiket te igyekszel szakmai alapon, ha már ez egy szakmai beszélgetés megválaszolni, akkor előjön a következő probléma, amiből kisejlik, hogy voltaképp ez is ugyanaz, mint bármi más. Az újdonságtól való félelem, hogy eddig tudtam, mit csinálok, és akkor most csinálok valami újat, amihez tanulnom kellene, ez egy szintugrás megint, és mi lesz, hogyha elbukom. Szóval, hogy visszahelyezve a kérdésednek az első felére, hogy hogy állnak ehhez hozzá a cégvezetők.

Nagyon sokat fektettünk a piaci edukációba, tehát nagyon sokat fektettünk már nagyképűség nélkül. Nagyon sokat fektetünk abba, hogy próbáljuk azt értelmezni az ügyfeleinkkel közösen, hogy mik azok a use case-ek, mik azok a referenciamunkák, egyáltalán mik azok az irányok, amik alkalmasak arra, hogy elinduljanak a felhőben, és akkor ennek többfajta megközelítése van. Szerintem ezt annak idején még csak nem is üvegplafonnak hívnám, hanem inkább egy sziklának, vagy egy sziklamennyezetes barlangnak. Ezt sikerült átütnünk közösen az ügyfeleinkkel, és akkor az a rövid válaszom, bocsánat, hogy ilyen hosszú a kérdésed, hogy amikor a nagyon tradicionális iparágak, és mint a bank, te, aki mondjuk egy két-három évvel ezelőtt elindul, és azt mondja, hogy az innovációnak a felhőinformatika a platformja, akkor szerintem megértették a vállalati vezetők, hogy enélkül nem tudnak ma transzformációt, digitális transzformációt véghezvinni.

Igen, egyébként én is azt látom és gondolom, hogy úgy a vízió, tehát hogy ez jó lesz, ez ugye nagyon sok csapból folyik, hogy ez meg fogja érni, és ott vannak a tanulmányok is, hogy nem tudom, Észak-Amerikában így meg úgy meg amúgy, meg ennyit nyernek rajta, de a hogyan, tehát pontosan a use készek, amit Robi te is mondasz, tehát hogy ez hogy fog végbemenni, és hogy lesz nekünk ez jó, és hogy ne a fejjel a falnak szaladjunk, hanem hatékonyan és kicsiből építkezve aztán valami robosztus és jól működő dolog szülessen a felhőben, és nem ilyen big bang jelleggel, hogy akkor most hirtelen már ott vagyunk, vagy még nem vagyunk ott. Ez ugye egy evolúció, tehát ezen dolgozni kell folyamatosan, bármennyire is esetleg rosszul hangzik, de hogy minden máson is, tehát bármi a világon, amivel nem foglalkozunk, az eltörik előbb-utóbb.

Tehát ez is egy Journey, ugye ezt szokták mondani, ez kicsit olyan marketingszagú, de tényleg igaz, tehát hogy foglalkozunk vele is, és egyre több jön ki belőle, és aztán egyre inkább akarja az ügyfél is.

Ugye a mai adásnak van egy háttérsztorija, ezt most megosztom a hallgatókkal, hogy Károllyal egy konferencián találkoztunk, ahogy Zoli is mondta, ez valóban előfordul, hogy egymás után vagyunk színpadon más szakemberekkel. És hát ezen az Alcity Global eseményen annyira megtetszett a Károlynak az előadása, hogy én fölvetettem, hogy mi lenne, hogyha ezt itt folytatnánk, és a mélyére ásnánk a dolgoknak. És külön köszönöm Róbertnek, hogy ez megvalósulhatott a mai nap. Na most, hogyha kinyitjuk az online portálokat, meg hát ugye ezeket az elemzéseket, akkor hát csak az a különbség, hogy 10, 20, vagy 50, vagy 100 IT trendet, de hogy rengeteg trendet tudnak fölsorolni nekünk. És való igaz, hogy azért ezek egy jelentős részével kicsit ilyen erőltetett, mondjuk, hogy marketingszagú, de legalábbis erőltetett, hogy kell húsz trend, akkor nézzük, mi az a húsz.

De hogy most abban a szerencsés helyzetben ülünk, hogy gyakorló szakemberként, és nem ilyen keretek között, hogy muszáj húszat mondani, tudunk beszélgetni, szóval mik azok a trendek, amiket ti láttok a magyar piacon, ami létező átvitt trend, amivel valóban, ha nem is mindenki, de nagyon sokan foglalkoznak, és ami ezáltal mindenféle szolgáltatói erőforrást is igényel.

Először is köszönöm a kedves szavakat az év eleji ICT is előadásomra, ott ugye mesterséges intelligenciáról adtam elő, és volt egy olyan slide, ami szerintem jól rezonált a közönséggel, hogy mik a várható előnyök, ráfordítás és hosszú távú hatása, ugye menedzselt szolgáltatások a kivitelezett AI megoldásoknál, és hogyha Open Stones-ból összeragasztgatjuk, és akkor szerintem ez ott jól feküdt, és ez kapcsolódik egyébként abszolút a mai témához is, tehát nyilván itt a felhő körül keringve. Amit mi látunk, először is a felhőt is sokan trendnek hívják, mi erre inkább szeretünk úgy tekinteni, mint hogy a felhő az egy eszköz, az nem egy ilyen megfoghatatlan ilyen valami, hanem az nagyon is konkrét szolgáltatások összessége, amit rettentő profi módon tud az adott provider, a mi esetünkben AWS kiajánlani az ügyfeleknek.

És ilyen szempontból ez egy eszköz arra is, hogy a divatos trendeket mi kiértékeljük üzletileg. Ugye nagyon sok trend kering, és keringett eddig is, tehát hogy nem is tudom, digitalizáció, meg devops, tehát az automatizáció, a fejlesztési és operatív feladatok körül, és egyáltalán a kultúrának a megreformálása, akkor a konténerizáció, tehát hogy úgy tudjunk szállítani alkalmazásokat, hogy az skálázható legyen, és kis egységekre bontva tudjuk ezeket kezelni. Most van a Machine Learning, meg az Artificial Intelligence, annak itt a legújabb debütálás, a Generative AI, tehát az megint egy újfajta hype, úgymond. Erre mind-mind nagyon hatékonyan a felhőt ki tudjuk használni, hogy rövid idő alatt ezeket a különböző trendeket, vagy hype-okat, vagy technológiai megoldásokat megfogjuk úgy, hogy számunkra mi az, ami fontos üzletileg, tehát hogy üzleti KPI-okat állítsunk emellé, és akkor egy strukturált módon kicsiben ki tudjuk próbálni, tehát erre lehet prof of concepteket, meg pilot projekteket definiálni, meg tudjuk nézni, hogy ez hasznos-e nekünk.

Talán még a Quantum Computingot nem mondtam, ami ugye szintén egy ilyen hot topik, tehá, hogy egy újfajta számítási módot használjunk bizonyos feladatoknak a hatékonyabb elvégzésére. Nyilván körbe tudunk nézni, hogy más versenyzők, vagy akár más potenciális partnerek mikkel készülnek, és akkor ezt a felhő platformon ezt nagyon hatékonyan és kis kockázattal ki tudjuk próbálni. Ami ma nagyon divatos, és látjuk az ügyfeleknél is, és egyébként mi is használjuk, az a Generative AI, tehát ezzel nem lehet nem foglalkozni egy mai IT cégnek, főleg ilyen felhős környezetben. Úgyhogy azt azért jó látni, hogy vannak bizonyos use case-ek, amik jól mennek, és ezeket az ügyfelek is szívesen kipróbálják, és érnek el benne sikereket.

És egyébként mi is a saját belsős dolgainkra használjuk a generatív AI-t, úgyhogy gyorsítsuk a munkafolyamatokat, ami esetleg ilyen nagyon sziszifuszt, ilyen össze kell állítani, tehát ilyen tartalomgenerálás jellegű azokra is, de akár technikai vonalon is nagyon sok mindenre jó, meg jellemzően a tudástárban az intelligens keresésre szokták használni, és akkor az ilyen chatbot alapú megoldásokkal. Úgyhogy összességében én azt látom, hogyha valaki eldönti, hogy ez érdekli, akkor a felhőben nagyon gyorsan ennek a végére járhat, és hogyha ez sikeres, akkor utána a következő lépésben fel is tudja skálázni produktív mértékűre.

De azt hiszem, hogy az volt a kulcs ebben, amit mondtál, nem, hogy ez a fajta ilyen tudatosság, mert hogy most érted, kétévente átneveznek egy terméket, négyévente lecserélik a terméket, és akkor jönnek ezek a trendek, rohadt nagy a zaj.

Ebben ember legyen a talpán, aki azt tudja, hogy nekem ez kell, amaz meg egyébként teljesen haszontalan. Ez a méret egyébként nekem megfelel, az meg egyébként teljesen más üzemméretben hasznosítható. És akkor hogy lehet egyébként a piacodat edukálni? Saját magaddal kezdve fegyelmezetten, tudatos mérce alapján vagy lépéssor alapján azt mondani, hogy ez egyébként egy kipróbálható, amaz meg még nem időszerű. Hát most mekkora boom volt, van a Generative I környékén. Ez számszerűsítő, hogy a kockázati tőkéből az elmúlt két évben milliárd dollárok mentek be azokba a startupokba, amiből mindenki a csodát és a megváltást várta. És nekem, amit te mondtál, abból az volt megfogható, hogy nem megúszható az, hogy egyébként tudd, hogy egyébként te milyen piacon, milyen ügyfelekkel, milyen iparágban dolgozol, milyen tudásra építve akarsz egyébként értéket szállítani az ügyfeleidnek, és hogy nem megúszható, hogy legyen egy úszkézed.

Csinálj rá egy tervet, definiálj ilyen viccet.

Persze.

Tegyél hozzá KP-ket, mérd meg, hogy sikeres volt, és ha nem, akkor alakíts rajta, de nem kötelező neked mindent használni. Bocsánat, egyszóval, hogy ez kb. olyan ez a trend cunami, ami nem tudom, nektek mekkora gyerekeitek vannak, ez a fomo érzés. Tehát ez a fear of missing, ahol én nem fogom kipróbálni, akkor ki fogok maradni, megijedek, félek tőle. És ezt nagyon nehéz ezt a fajta emberi tényezőt átugrani, hogy nem kell mindenbe beleütni az orrodat, azzal foglalkozz, ami egyébként a te iparágadat a leginkább fejleszt.

Nézzétek, négy generáció van jelen a piacon. Ugye, hogyha azt mondom a 70 éves tulajdonosnak, hogy te most holnaptól mesterséges intelligenciával kell, hogy foglalkozzál, akkor azt fogja nekem mondani, hogy Zoltán, menjen ki az irodámból.

Ó, ennél sokkal durvábbakat fogunk.

Ugye?

De hogyha a csúnya szavakat kihagyom, akkor csak köszön, de ezt így szoktam poénból mondani. És itt a konferencia élményeknek a felsorolásában szoktam azt mondani, hogy mi megyünk mi. Olyan konferenciákon megyünk, ahol IT-sok ülnek. És az IT-soknak próbáljuk meg elmondani, hogy hogy működik az üzlet. És amikor elmegyek egy üzleti konferenciára, ahol az IT nem meri elmondani, hogy egyébként mire van szükség az üzlettől. És az látszik, és ez a kedvenc negatív példám az elmúlt három hónapból. Ott ülünk ezen a konferencián, üzleti döntéshozók izgatottan várják, hogy végre egy IT is megszólaljon. És az első három perc után csalódással az arcukon kimennek. Mert továbbra sem értik, hogy mit akar tőlük az az ember, aki ott áll a színpadon.

És én azt gondolom, hogy ebben nekünk borzasztó nagy szerepünk van, hogy üzleti terv. Mert amit elmondtatok, itt most kiegészítem az előző gondolatodat, az üzleti tervnek hívják azt, amit meg kéne tanítanunk, egy, kettő. Ha azt mondom most egy név nélkül bármelyik nagy építőipari cégnél dolgozó kedves szakembernek, hogy KPI, hát akkor lehet, hogy ő sem fogja érteni. Márpedig ő fogja az én büdzsémet eldönteni abban a pillanatban, ahogy az informatikáról beszélek. Még egyszer név nélkül, legyen ez egy ilyen virtuális beszélgetés, de nézzük már meg, hogy az informatikának hol van a helye. És addig, ameddig az informatikában az informatika nem ért üzletül, az üzlet minden egyes projektjét pedig IT-nak kezeli, addig nem lehet konszenzust az én véleményem szerint, és akkor itt most visszadobom nektek a labdát, hogy jól látom?

Szerintem teljesen. Én azt hiszem, hogy akkor most előjön, amikor azt mondtam, hogy jó volt a kérdés feltevés az elején, vagy a beszélgetés indító, hogy akkor számtalan kérdés fogalmazódott meg, az informatika vezető szerepe, hogy akkor most ő csak egy büdzsé rabló, büdzséfoglaló, erőforrást terhelő szerepkör, aki mindig el tudja mondani, hogy mit miért nem lehet megcsinálni, vagy ezeknek az eszközöknek az átgondolt felhasználójaként egy transzformatív erő, aki azt tudja mondani, hogy értem az üzletemnek a működését, átlátom, legalábbis egy bizonyos mélységig, hogy egyébként milyen eszközök állnak a rendelkezésre, és azt mondom az üzleti vezetőnek, nekem az lenne az ötletem, így haladhatnánk gyorsabban, szebben, jobban, hatékonyabban.

Szerintem ez egy nagyon nehéz, ez egy nagyon nehéz pálya. Mi pontosan ezt tapasztaljuk az elmúlt közel tíz évben, hogy megpróbáljuk üzleti nyelven lefordítani azt, amit egyébként mi végül pure technológiában tervezünk, szállítunk, meg üzemeltetést támogatunk. Ez nem egyszerű, és akkor egyébként ebben nem csak az van, hogy van egy ilyen klasszikus ellentmondás az üzleti igény, meg az informatikai képességek között, hanem az is, hogy még az informatikai szervezeten belül is klasszikus silók voltak, tehát volt egy fejlesztő, egy üzemeltető, egy szervező, és akkor nem kellett egymásra hangolni. Tehát az, hogy most úgy hívjuk, hogy devops, amögött azért van egy ilyen átkötés, hogy nem lenne baj, hogyha a fejlesztő úgy fejlesztene, amit egyébként lehet üzemeltetni.

Nem lenne baj, hogyha egyébként a fejlesztő értené, hogy mi az üzleti igény, és annak mentén fejlesztene olyat, amit egyébként lehetne üzemeltetni. Nem lenne baj, hogyha kápék mentén felelősséget lehetne vállalnunk a munkánkért, ami egyébként mérhető lenne, amitől nem ijednénk meg, hogy akkor majd egyébként fejbe lőnek bennünket, hanem annak örülnénk, hogy akkor van egy változtatási, fejlesztési lehetőség, hogyha valami nem úgy sikerült, ahogy szerettük volna. Ez egy tök más, egyébként szerintem a felhőinformatikának ez az egyik leginkább edukatív szerepe, ez a fajta transzformáció, hogy menj, próbáld ki, olcsó, gyorsan megvan, értékeld ki, elbuktál, gondold át ismét, és addig gyakorold, ameddig egyébként ki nem jön az a biznisz, ki az, amit te vártál.

Igen, ez a vállalati kultúrában ez az elbuktál mondat, ez egy nagyon érdekes, mert hogy igazából milyen területen lakunk, élünk, dolgozunk és működünk, egy olyan területen, ahol ezt az elbuktál szót, ezt a halálnak halálával halt, hogy egy kicsit idézzek régebbi iratokból, de ezt mindenféleképpen meg kell tudni valahol értetni, én azt látom, ez az én tapasztalatom, amikor ilyen vezetőképzésben megpróbálok vezetőket edukálni abba az irányba, hogy figyeljetek, nem baj, ha kipróbálunk valamit, és nem működik. Meg kell próbálni. Azért van, azért van a felhő, oda el tudod vinni, ki tudod próbálni, demó környezet, megcsináltad, működik, nem működik, megnézem. De ebből a szempontból valahogy a felhő, az nem tudom, hogy hogy látjátok.

Mi az első lépés? Inkább most így fogom föltenni a kérdést, hogy megjelennek, és azt mondják, hogy felhő. És én azt látom az arcukon, hogy ilyen kicsit viszolygás, hogy hú, ki kell próbálnom valamit, amihez nem értek. Nálatok hogy kezdődik az első lépése ennek a projektnek?

Jellemzően egy beszélgetés az ügyféllel, tehát mindig a business case körül keringünk, tehát hogy mi a use case, hogy lehet ez hasznos. Tehát egy olyan, hogyha megáll a use case a beszélgetés szintjén, akkor elsőként mindig azzal szoktuk kezdeni, hogy csinálunk egy felmérést, egy business case-t, és a business case-nek része, hogy csinálunk egy helikopter nézetű felmérést minden rendszerről, ami csak szóba jöhet, ami jelenleg ott van az ügyfélnél. Hát a helikopter nézet az mondjuk olyan szempontból nem helikopter nézet, hogy vannak erre discovery toolok, és az begyűjtött terheltségi adatokat, alkalmazásról, licencről, és mindenről, amit ugye enged az ügyfél, hogy megnézzünk.

Ez egy saját fejlesztés, bocsánat, hogy közbeszóltam?

Nem, ez fontos, hogy ez egy AWS által nyújtott szolgáltatás, illetve szolgáltatáshalmaz, tehát ez sem már csak egy. Ugye a 200 szolgáltatásból ez mondjuk 5-8, és nagyon jól körbe lehet rakni, hogy aztán hogyan tovább. Vannak különböző migrációs stratégiák. A migráció nem csak azt jelenti, hogy megfogunk valamit, és úgy, ahogy van, átrakjuk, hanem a legtöbb esetben modernizáljuk, tehát hogy optimálisan fusson, natívan, az is lehet, hogy eldobjuk és újat készítünk, csak maga a funkció marad meg. És hogyha erre van egy rálátásunk, hogy nagyjából mivel érdemes foglalkozni és mivel nem, és emellé tudunk rakni effort és impakt párosítást, tehát hogy mennyire fog fájni, mennyi munka, és mi lesz az előnye ennek, mivel ugye mindennek ára van, tehát a felhőben is nagyon jól be van árazva minden egyes faktor, de hogy annak is ára van, hogy meddig tart, amíg mondjuk piacra lépünk egy termékkel, tehát hogy ilyen szempontból szerintem nagyon összetett, és nagyon is kellenek ezek a sikerkritériumok, vagy hogy definiálhatjuk a sikert egy-egy, tehát ahogy mondtad is, attól, hogy valamit befejeztünk egy rövid időtávon, az lehet siker is, hiszen mondjuk bebizonyítottuk, hogy nem az a jó irány, és akkor fölösleges bele többet invesztálni.

Tehát, hogy ez szerintem is nagyon sokrétű. Emellett ennek a business case teremtésnek van egy másik lába is, hogy a szervezetet felmérjük, hogy mennyire áll készen a felhős működése, tehát hogy mennyire vannak meg a folyamatok, mennyire vannak meg a biztonsági alapjai, hogy mondjuk felhős elosztott rendszereken, vagy egy hibrid környezetben például jól működjön, mennyire van meg a stáb. Ebből is konkrét tennivalók kiesnek, hogyha az ügyfél szeretne folytatni ezen az úton, és akkor kvázi ez egy olyan stratégiának az alapja is lehet, hogyha az ügyfél szeretne a felhőbe menni a következő években, és valószínűleg szeretne, még hogyha elsőre el is kerüli, de igazából középtávon elkerülhetetlennek tűnik, pont azért, mert annyiféle innovatív technológiával állt rendelkezésre, hogy saját erőből nagyon nehéz megépíteni mindet, vagy akkor a Fear of Missing Out-ot, hogy akkor meg kihagyják ezeket a jobbító és a versenyképességet ösztönző újításokat.

Úgyhogy Summa summarum ennek az a vége, hogy van egy ilyen tervünk, hogy mely alkalmazásokat javasoljuk elsőnek, milyen sorrendben, miket kéne szervezetileg még megtenni, ennek van ára, ennek van megtérülése, tehát hogy ők mit nyernek ezzel, ahhoz képest, hogyha hagyományos környezetben maradnak, és akkor ennek utána vannak következő lépései. Tehát, hogyha azt mondja az ügyfél, hogy igen, én ezt meg akarom próbálni, akkor vannak pilot alkalmazások, ahol kicsiben kipróbáljuk, kicsiben megnézzük, hogy az operating modell, tehát hogy a működési modell.

Működési modell.

A működési modell, köszönöm, hogy működne, ugye félig felhő, félig on-premise, tehát nyilván ez mindig ez van.

És akkor eljutunk oda, hogyha itt komfortos az ügyfél, akkor a további fázisokban elindulhat a Mass Migration, tehát sok alkalmazásnak a tömeges felvétele, mert egyszerűen megéri.

Én azt gondolom, hogy ezen a ponton egyértelmű lesz a hallgatóknak most már, hogy mennyire fontos egy szakértő szerep ebben a folyamatban. Tehát akár az Amazon, akár a Microsoft, bármelyik nagy felhőszolgáltató esetén kimeríthetetlenül sok leírás van arról, hogy mit tud az a rendszer, milyen szolgáltatásai vannak, mind a 200-ról nagyon alaposan lehet tájékozódni, de hát valakinek meg kéne azt mondania, hogy az hol lesz jó. Meg hogy mit mire tudok én használni az én cégemben.

Mi volt a legrövidebb, meg a leghosszabb idő, hogyha lehet egy ilyen köztes kérdést föltenni?

Tehát aki fel volt készülve ügyfél versus, nem volt felkészülve, föl kellett készíteni, el kellett indítani egy projektet. Tehát most valahogy megpróbálom a hallgatóknak ezt az időtávot így belőni, hogy abban, amit elmondtatok, rengeteg információ volt. Ha ismeri a folyamatait, ha megvannak a felkészültsége az IT üzemeltetésre, de biztos van egy ilyen minimum maximum.

Válaszolhatok egy picit?

Nagyon.

Rácsatlakozhatok még mielőtt válaszolnék.

Mindenhol.

Erre a kérdésedre, hogy olyan furi ez a mi szakmánk, ez a felhőinformatika, csak látszólagos lesz a furcsasága, hogy itt nem elég kellően jó szakembernek lenni, hanem ez egyfajta ilyen pszichológusi pálya is, hiszen nem árt empatizálni az ügyféllel. Tehát, hogy nem árt azt átérezni, hogy ha te azzal nyitsz, hogy itt mindent is meg tudsz oldani, és ettől kellemetlen érzi magát, ebből kettőtök között nem lesz egy ilyen kapcsolódási pont. Amikor 2023-ban az év elején az AWS úgy működik, hogy csak partnereken keresztül szállít. Tehát igazándiból szerintem nem a nagy vendoroknak a technológiai felkészültsége tesz elsősorban különbséget, hanem az, hogy az integrátor milyen felkészültségben, partner milyen felkészültségben, az ügyfél megértésében.

És amikor '23-ban Magyarországon is elsőként, és a régióban is csak nagyon kevesen vagyunk, akik megkapták az úgynevezett Certified Migration Competency partneri rangot. Ez egy nagyon komoly audit eredményeképp egy szakmai elismerés, a Karcsi erről beszélt most egy pár szóban, az pontosan arról szólt, hogy érted az ügyfelednek az iparágát, érted az ő szerepét, érted azokat a drivereket, amik egyébként mögötte és a versenytársak között húzódnak. Tudod, hogy milyen eszközeid vannak egyébként arra, hogy újragondold, vagy segítsd az újragondolását az üzleti működésének, és akkor egyébként ezeket hogyan magyarázod el, hogy ez mi az, ami hasznos ebből neki. És szerintem az a legfontosabb, hogy strukturált, lépéssoros protokollt követünk.

Mi tulajdonképpen egy migrációs gyár vagyunk. Ez azt jelenti, hogy van egy ebből a minősítésünkből adódóan egy keretrendszer, egy eszközrendszer, egy dokumentációs rend, egy auditálandó követelményrendszer, ami alapján kell nekünk azt bizonyítanunk az ügyfélnek, hogy az AWS legmagasabb szintű best practice alapján szállítjuk ezeket a migrációs feladatokat, és akkor ott annak megint csak több lépése van. Nem lehet ilyen, gyere buci, hamm, bekaplak alapján menni. Nem csak azért, mert az ügyfél nem készült föl rá. És akkor egy picit visszakötve a kérdésedre, hogy szerintem nem az a kérdés, hogy ki az, aki felkészült, ki az, aki nem, senki sem ebben a régióban, inkább az a kérdés, hogy ki az, aki lát abban üzletileg potenciális előnyt, hogyha ő ezt a folyamatot, ezt a fejlődési útvonalat a Karcsi ezt Győrnek hívta, az előbb elindítja.

Ugye ennek rengeteg vonatkozó aspektusa van, például a szponzorsíp. Tehát a stakeholder eldönti-e, az üzleti informatika összebeszél neki, hogy egyébként nekik ez miért fontos, hogyan mérnék, milyen szervezetet, milyen folyamatot, milyen lépések mentén kezdenek csinálni. Maga az a tevékenység, amivel mi foglalkozunk, hogy jobbá tesszük az ügyfeleink vállalati működését, az tulajdonképpen informatikailag egy felhő informatikában leírható. Figyelembe kell venni, hogy ő hol van most. Ahhoz, hogy a felhőbe mehessen, annak van egyébként egy. Szerintem említetted is Karcsi ezt a felmérést, hogy annak van egy strukturált kérdőívezése, az tulajdonképpen olyan, mint amikor, hogyha magatok mellett kapnátok a Mckinsey-t, és akkor a Mckinsey-nek a sorvezető mentén kellene az egyes üzleti technikai doméneket lekérdezni.

Ott fölmérjük, hogyha te a felhőbe akarsz menni, amúgy egy másik operatív modellen mi volt a magyar megfelelő?

Operációs modell.

Egyébként a felhő informatikai működési modellbe akarsz áttérni, akkor egyébként nagyon pontos domainnak mentél, te hol állsz, mik az erősséged, és egyébként mik azok a területek, amiket fejleszteni kell, és akkor hogyha ez megvan, akkor van egy világos képed arról, hogy ebben az útvonalban milyen teendőid vannak. Aztán van egy másik ága, hogy azt is fölmérjük, hogy ahogy te ma működsz, ahhoz képest ez mennyivel lenne olcsóbb, lényegesen olcsóbb a felhőben. És akkor utána jönnek azok az üzleti döntések, amik egyébként szakaszoltan visznek előre, nincsen big bang, nem kell mindent átvinni, sőt, mi mindig azt mondjuk, hogy ne válasszunk ki valamit. Legyen egy quiquin, legyen egyfajta szocializáció, szakemberek, Bálint, tehát legyen egy elköteleződés, hogy igen, már nem félek, ki mertem próbálni.

Működik a partner, el tudja magyarázni, hogy hogyan működik. Segít abban, hogy képződjünk, akkor kis projekteken keresztül eljuthatunk odáig, hogy az egész vállalatot egy-két-három év alatt felhőben lehet transzformálni. Szóval szerintem, hogy az a kérdése, hogy ki volt készen vagy ki nem, szerintem inkább az a kérdés, hogy mi az elköteleződés, hogy egyébként hogy látják a saját piacukat, mi az, ami egyébként ebben az élbolyban maradok, vagy a lemaradók közé kerülök be, ebben hogyan alkalmazzák a digitális transzformációt és a fejlődő információt.

Az a fontos, hogy ezt ti mondjátok ki. Tehát, hogy én azt látom, hogy nagyon-nagyon fontos kérdések azok, hogy ezeknek a típusú büdzséknek a kialakításakor mit szánok én a piacvezetői státuszomra, ami az informatikához tartozik. Ugyanis, ha piacvezető vagyok, növekszik az adatmennyiségem, és az adatmennyiséggel növekednie kell a tárhelynek, és növekednie kell azoknak a felhasználóknak is, akik igénybe veszik azt a tárhelyet, amit eddig skáláztam. Ha nincsenek mérőszámaim, akkor nem tudom ezt megmondani. Akkor csak azt látom, hogy elfogyott.

Elfogyott.

Elfogyott, meg hogy kidobtam az informatikára pénzt.

Volt egy vendégünk, akinek a mondása azóta is a fülembe cseng, hogy tegyük rendbe az informatikát, az it.hu-nak az alapítója volt egyébként, és hogy egyre inkább azt látom, hogy tényleg erről kéne beszélni, vagy ez a jó megközelítés, hogy persze sokszor kipróbálunk dolgokat, meg sokszor gyorsan kell valami megoldás, és nincs idő átgondolni, de hogy egy idő után azért át kéne. Tehát, hogy így-úgy-gyorsan megvettünk ezt-azt, vagy túléltünk egy-két évet, de hogy egy ponton azért ezt végig kéne gondolni, és hogy racionalizálni is kéne, meg adott esetben költségoptimalizálni is kéne, adott esetben egy fejlődési, egy növekedési pályát kéne alkotni, aminek van informatikai lába. Mit gondoltok erről, illetve, hogy ide kapcsolódik, nagyon jó, hogy említetted ezt az Amazon kiemelt szerepet, ha jól tudom, ez így évről évre lépegettek előre az Amazonnak a ranglétráján, ami most már tényleg egy regionális tényezővé teszi a TC2-t, és ehhez külön gratulálok, hogy nektek a filozófiátok is ez?

Mert kicsit az az érzésem, hogy azért is tudtok ennyire magas szintű partnerek lenni egy globális szolgáltatónál, mert hogy nem megúszni, vagy gyorsan túllenni akartok egy-egy projekten.

Más a filozófiátok, nem?

Most ezzel a szóval rendrakás? Azt mondtad?

Tegyük rendbe az informatikát, ez volt az idézet.

Tegyük rendbe. Megmondja, mi az a híres mondat, amit a legjobban gyűlölök, amikor azt mondják egy problémafelvetés, hogy így szoktuk csinálni.

Szerintem ez nagyjából szerintem egy cégnek a működésében a halál felé vezető út a székházépítésnél, és az így szoktuk csinálni mondatoknál kezdődik el kulturálisan. Szerintem az fontos, hogy tegyünk rendet, én ezt kiegészíteném azzal, amit az előbb is említettem, hogy gondoljuk újra. Merthogy az előbb említettetek példát, hogy elfogy a tárhely. Ugye a felhőinformatika Karcsi említette, rengeteg szolgáltatásnak, szoftvernek, tehát ugye ez messze nem a hardver, hanem ez a szolgáltatásoknak, a szoftvereknek egy integrált, tehát maga az innovációnak a platformja, hogy azt hogy lehet mérni egyébként, hogy akkor hárommal több feature tudtam ugyanannyi időt lefejleszteni, vagy két nappal korábban mentem ki a piacra.

Vagy az a termék, amit kifejlesztettem, az egyébként öttel kevesebbe került. Vagy az egyébként tízezer darab virtuális gépet akkor nem száz, hanem ötven darab rendszergazdával tudtuk működtetni, és a másik ötvenet nem elbocsátom, hanem munkahatékonyságra, jobb minőségű munkákra alkalmazom. Hogy inkább mi ezt úgy gondoljuk, hogy nagyon fontos azt megérteni, hogy te ma hol vagy, de hogy egyébként ez az újragondolás, nekünk a felhőinformatika sokkal inkább az újragondolásnak az időszaka, amiben az is van, hogy hogyan lehetne ezt jobban csinálni, és én személy szerint ezt szeretem benne a legjobban, hogy azon túl, hogy ez egy tök konkrét terület, tehát itt is meg kell tervezni, le kell szállítani, mérőszámok vannak hozzá.

A Karcsiék minden projektet úgy csinálnak, hogy egyébként van egy ilyen basedine, hogy ma ez így működött. És akkor, amikor átmentünk, akkor egyébként még mielőtt átmegyünk, akkor egyébként az hogy működik jobban, mert ha nem működik jobban, akkor miért mennénk át, hogy ez egy ilyen újragondolás, sokkal inkább újragondolás, mint pusztán csak annyi, hogy tegyünk rendet. Nekem a te rendrakásom mindig az jut eszembe, amikor a gyerekeim visszatoloncolják a székeket az asztal alá, de hát ott nincsen morzsa, vagy pontosabban morzsa van, meg le kéne portörölgetni, meg utána lehetne föltolni, és akkor utána vissza lehetne. Hogyan lehetne az egészet úgy átgondolni, hogy ez egy fenntartható fejlődés legyen, ne csak egy pillanatnyi rendrakás.

Az AWS-nek van ez a mondása, vagy alapelve, hogy customer obsession, tehát hogy megszállottan ki akarják elégíteni az ügyfeleket, és ezt egyébként átragasztják a partnerekre is, tehát hogy értsük úgy, hogy mindig minél optimálisabban, minél olcsóbban és minél többet kapjanak az ügyfelek, és ebben egyébként nagyon igazuk van. Nyilván gondolhatnám bárki, hogy miért is. Tehát, hogy az a jó az AWS-nek, hogy valaki ott

nem tudom - kétszer akkorára véretezi a valamilyen rendszert, és akkor ott fut, és akkor több pénz lesz belőle, de aztán az ügyfelek meg fogják magukat, és leköltöznek a felhőből, hogyha ez nem jól működik, és ez nem egy jól működő modell. És ugye a partnereket is nagyon-nagyon méri ezen az AWS, és ösztönzi, hogy folyamatosan optimalizáljunk, tehát átnézzük, lehet-e optimalizálni költségre, biztonságilag van-e mit tenni, esetleg vannak-e újabb szolgáltatások, amik jobban működnének, úgyhogy ez a rendrakás, vagy újragondolás ilyen szinten is folyamatosan a hétköznapjainkban benne vannak. Az a nehéz ebben, hogy akkor, amikor arról beszélünk, hogy üzleti terv, ami szerintem minden egyes egyetemi oktatás legelső évfolyamának legelső napjától elkezdődik.

Ugyanannak a könyvnek igazából már a háromnegyedénél van benne egy olyan szavacska, hogy TQM, meg van benne egy olyan, hogy PDCA. És ugye ezek a típusú modellek mutatják meg azt is, hogy hogy lehet ezt a menedzsmentet, ezt a Quality, tehát minőségmenedzsmentet, amit most elmondtál, én ezt így tudom lefordítani, és kérdezek vissza is, hogy jól fordítom-e le, hogy ez egy minőségbiztosítása annak, amit csináltok, és egyébként pedig ez a PDCA modell, ez egy ciklus, ami körkörös, és folyamatosan arról szól, hogy hogyan tudod megjavítani ezt a típusú működést, és nem a rendrakást, hanem hogy van-e benne jobb. Tudsz-e alkalmazni jobbat, tudsz-e csökkenteni költséget, tudsz-e hozzáadott értéket, hozzáadott értékteremtést.

Ha a gazdasági oldalról nézem, akkor mit nem tudunk kimutatni mérőszámok nélkül az elmaradó üzleti hasznot. És ugye az elmaradó üzleti haszonhoz tartozó mérőszámok megjelenésével fogok tudni sajnos kimutatni elmaradó üzleti hasznot, merthogy ott megjelenik.

Jól értettem ezt, amit mondtatok?

Nagyon jól, igen. Korábban is elhangzott, hogy folyamatosan törődni kell ezekkel a fejlődési rendszerekkel, és valójában ezt értettem nagyrészt ezalatt, és a hagyományos projekteknél, tehát hagyományos rendszereknél azt mondják, hogy akkor megcsináljuk, és akkor öt évre ez az összes költsége, totál cost of warnership, lerakjuk a sarokba, és akkor ennyi. De valójában az sem annyi, tehát rengeteg indirekt költség van, és hát öt évre előre megjellemzően nem szoktak látni az emberek, csak van egy terv. Tehát itt benne van az is, hogy tudunk adaptálódni a változó kihívásokra, akár változtatni kell funkcionálisan, akár csak leskálázni, vagy felskálázni, és igen, tehát hogy van, erre is van egy frameworkje az AWS-nak, ezt úgy hívják, hogy Bell Architected Framework, ez nekünk ott a szakiknak a bibliája kvázi, tehát abban mindenféle szempontból bármilyen megoldásokra ott vannak az alapelvek, nyilván ezek általános, még csak nem is AWS specifikus, hanem felhős alapelvek, amiktől jól fog működni egy ilyen rendszer, és ahogy át kell nézni, és rendszeresen ezt alkalmazzuk, hogy ez rend legyen.

Hozzátok odamegy valaki, és azt mondja, hogy figyelj, ennyien vagyunk, ezt szeretnénk.

Most csak egy picit ezt a use case-t szeretném megfogni, mert most ez letölthető a weboldalról, elolvasom, és ez a use case, vagy pedig leültetitek, kikérdezitek, megbeszélitek, és egyébként pedig vannak különböző, ez a baseline, amit mondtál, és akkor az alapján mentek rajta végig. Tehát, hogy ezt hogy lehet megfogni jól?

Ez a kettőnek a kombinációja. Tehát van egy sorvezető, ahogy kéne, hogy kinézzen, meg van minden ügyfél egyedi, viszont ebbe a struktúrába mindenki beleillik, és a kérdések sorozatával mi a mai fájdalompont, és ahogy tervezik a felskálázódást az ügyfelek, jellemzően fel szeretnének skálázódni üzletileg, akkor mi lesz? Hol lesznek ezek a buttonleckek, amitől már nem fog működni az, ami eddig működött, vagy esetleg most se működik, és erre szoktunk javaslatot adni, hogy ezt így tudjuk felskálázni, és így fog kicsiben is működni, és kicsiben kipróbálható kis kockázattal kis költségen, és aztán ez működni fog nagyban is. Tehát ez a szuper benne, hogy amit megépítünk ilyen kis, hát nem deszkamodellnek mondanám, mert pont, hogy nem kell eldobni, mert az szuperül fog működni, hogyha ráeresztünk, nem tudom, ezerszer annyit is másnap forgalomban, vagy adatmennyiségben, vagy bármiben, és ezt végig szoktuk vezetni üzleti szempontból is, tehát ilyen konzulens business analyst szemüveggel, tehát hogy nem csak nyilván virtuális gépekről, meg szolgáltatásokról beszélünk, hanem ez nagyon is kell, hogy üzletileg is alá legyen támasztva, és legyen egy szponzora, lássa, hogy mi a sikerkritérium, és akkor ez a végén ki is legyen mondva.

Olyan jó, hogy ezt nem nekünk kell mondani.

Karcsi, nem az is fontos ehhez, hogy ez nekünk azért nagyon szerencsés, nemcsak intellektuálisan is roppant vonzó egyébként jókat mondani és jókat csinálni az ügyfeleknek, mert ha már szerintem csinálsz valamit, akkor csináld jól.

Igen.

Hanem, hogy gondoljátok el, hogy csak az AWS-nek minden hónapban van 20-on számú új bejelentése. Ez lehet egy új AI funkció, ez lehet egy nagyobb gép olcsóbban, ez lehet egy újabb szerver lesz fejlesztésnek az iránya. Tehát a legegyszerűbbtől a legösszetettebbig. Most akkor ezt le kéne követni. És akkor ugye úgy van ezzel az egész felhővel, hogyha azt mondjuk, hogy ez nem más, ha leegyszerűsítem, akkor a felhő maga az innováció, hogy az kevés, önmagában nem elegendő, inkább úgy mondom, hogy te leültél, kikérdezted, és ugyan best practice alapján egy frameworkben, de egyedi módon, rászabottan végigviszed egy útvonalon, nem hagyod ott. Ami nekünk különösen vonzó ebben a bizniszben, ebben a felhő informatikai bizniszben, az az, hogy úgy maradunk együtt az ügyfelekkel ebben az ilyen megbízható, tanácsadó szerepkörben, hogy mi meghatározott menetrend szerint fölülvizsgáljuk az ő működését.

Naponta, hetente, havonta, negyedévente, félévente, meg évente. Erre van nekünk egy menetrendünk, hogy hogy kell egyébként jól üzemeltetni. És a jól üzemeltetés az azt jelenti, hogy hogy lesz optimális. Az optimális nem azt jelenti, hogy hárommal több vagy kettővel kevesebb, hanem az ő üzleti igényének és az innovációnak, ami egyébként jön a felhőből, ha te egyébként ahhoz föl tudsz zárkózni, és érted, hogy mi történik a felhőben, érted, hogy mire van szüksége az ügyfeleknek, akkor azt mondhatod, hogy ma ezt lehetne gyorsabban, holnap meg lehetne olcsóbban. Ezzel a külön funkcióval lehetne másképp. Tehát, hogy hogyan lehet minden nap egyébként ezért a bizalomért megküzdeni. Hogyan lehet minden nap egyébként megmutatni az üzemeltetést?

Ez már nem egy klasszikus üzemeltetés támogatás. Ez a legkevésbé a hibajavításról szól, mert azok az automatizmusok, amiket mi megfelelő tervezéssel beépítünk a rendszerek működésébe, köszönjük szépen, azok többségében kiválóan szelfiri módon, előrejelezve a hibát, beavatkozva, hanem az, hogy egyébként amik jönnek ma, meg amik lesznek, tehát amikor a felhőprojektet ma átadod, az ma optimálisnak tekinthető. A Karcsi a Bell Architected Framework-öt mondja. Amikor mi a vállalati területek alapján tervezünk, meg üzemeltetés támogatást nyújtunk, akkor pontosan ez a feladatunk, hogy ez ma optimális, holnap már biztos nem.

Mit kell ahhoz tenni?

Egy pillanat Zoli, de ennyi szakmaiság után muszáj egy szünetet tartani. Ez kijár a hallgatóinknak.

Úgyhogy itt az idő, hogy feltegyek egy személyes kérdést magunknak. Minden műsorunkban van egy személyes szál, ami egyáltalán nem a témához kapcsolódik, és van, amikor én sem tudom.

Hát látod, hogy nem olvasod el a forgatókönyvet.

Tekintve, hogy szeptember van, legyen most az iskolával kapcsolatos a témánk. Kinek melyik iskola számít igazán az ő álma materének? Választanád-e a gyermekednek azt az iskolát, ahova te is jártál. Vagy éppen mennyire hisztek a divatos új magánsuli koncepciókban így általában.

Én nekem kisebb itt a tapasztalat. Nekem a nagyobbik fiam most fogja kezdeni az általános iskolát, egyébként a közeli iskolában itt az agglomerációban. Én Debrecenben tanultam egyébként, én az általános iskolát egy református általános iskolába jártam végig, ami szerintem remek dolog az ilyen alapértékek, hogy meglegyenek az emberben. Nyilván nem ez az egyetlen útja, és hát egy gyakorló gimnáziumban, tehát a Kossuth Lajos, az egyetemnek a gyakorló gimnáziumában tanultam gimnáziumban, ott pedig közben cserediák voltam, elmentem Japánba egy évre, én azért tartom nagyon hasznosnak, hogy minimum a nyelveket tanuljanak korán a gyerekek, mert ez szerintem a kulcs, hogy tényleg egyébként nincsenek határok, tehát hogyha így a munkaerőpiacot nézzük, bárhova dolgozhatunk, nagyon sok ember saját magát korlátozza be, hogy nem tud.

Valami nyelven.

Igen, vagy nem elég magabiztos. És hát nyilván más kultúrákat is megismerni, tehát az nagyon sokat ad szerintem a nyitottsághoz, az elfogadáshoz, úgyhogy igen, aztán később is dolgoztam sokat külföldön. Szerintem ez nagyon fontos, és egyfajta jó légkört is megteremt aztán a későbbiekben, ahol az ember dolgozik, hogyha ez az alapértékek és a nyitottság megvan.

Te ilyen klasszikus céhlegény vagy, nem? Hogy a céhlegény úgy értem, hogy amikor elvégezted, akkor elmentél világot látni, tapasztalatot gyűjtött, és akkor ezeket hazahoztad, és akkor itt a TC2-ben az ügyfeleink örömére.

Én inkább úgy gondolkodom erről, hogy nekem például a gimnázium, hogyha itt az alma materről beszélünk, egy fontos pontja az életemnek, kevésbé az egyetem inkább a gimnázium, ez a Szent László Gimnázium Budapesten, és ha visszatekintek rá, akkor ez a fajta kulturális sokszínűség a nyelvválasztásnak, a nyelvtudásnak a lehetőségeként tekintek pozitív példaként vissza a gimnáziumra, és akkor az a kérdés, hogy vinném-e ma ide a gyerekemet, nekem ennél egy kicsivel nagyobbak a gyerekeim, szóval ez a kérdés már eldőlt. Azért mentünk másik irányba, mert én meg azt látom, hogy az egyénnel szemben a közösség ereje elképesztően nagy. Tehát a közösségben rejlő bölcsességnek az ereje elképesztően nagy. És amikor mi a gyerekeinknek iskolát választottunk, akkor hogyha ez divatos, vagy nem divatos, akkor abba az irányba mentünk el, ahol ez a fajta egymásra utaltság érvényesül, ahol egyébként oda kell figyelni a másikra, ahol egyébként egy közösségi értéket be kell tartani, ha már ezeket megfogalmaztátok magatoknak, ahol projektszemlélettel működnek a gyerekek.

Sose fogom elfelejteni, amikor a nagyobbik gyerekem volt negyedikes általános iskolás, és akkor bementünk egy ilyen nyitott napra, és akkor azt mondták a gyerekeknek, hogy akkor itt ez a lista, így lesznek csoportokban, ott az a tíz darab. Itt egy feladat, bontsátok le taskokra, beszéljétek meg, hogy kinek mi a dolga, aztán utána szállítsátok le, gyertek vissza és számoljatok. Ez olyan triviálisnak tűnik, de hogy mitől lenne az még a felnőttek és a munkakörülmények között sem magától értetődő, hogy nem összeveszünk, hanem a kölcsönös egymást erősítve, az erősségek mentén kezdünk el összedolgozni. Nekem ez a legfontosabb, és ez azért is jó, mert a cégemben sem kell másképp gondolkodjak, mint ahogy egyébként a magánéletemben gondolkodom, abban hiszek, hogy három ember együtt hatot ér legalább, de ötöt biztosan, főleg akkor, hogyha egyébként megvannak azok a közös értékek, és megvannak azok az erősségi szinergia pontok, amik alapján többet lehet vinni.

Nekem ez a legfontosabb az iskola szempontjából.

Nekem is az a véleményem, hogy a közösségteremtő erő az nagyon fontos egy iskolában. Nekem szerencsére egy hagyományos iskolarendszerben is megvan ez, vagy megvan ez az élmény, megtörtént annak idején. A Fóti Ökomenikus Általános Iskolát szeretném kiemelni. Amint megalakult '91-ben, én a harmadik osztályt már ott kezdtem. Nyilván ez még inkább édesanyám döntése volt, mint az enyém, de nagyon jó döntés volt. A hat év alatt rengeteget kaptam barátságban, tiszteletben, projekt meg csoportmunkában, meg szakkörökben, meg értékekben. Ugyanakkor azt szeretném elmondani, hogy nyilván most elköltöztünk, nem oda járnak a gyerekek, meg ott változott sok minden, hiszen ma nagyon gyorsan változnak a dolgok, még egy iskolarendszerben is sajnos, de hogy én abban is egy nagyon nagy értéket látok, amit ma egyre kevésbé mernek fölvállalni a pedagógusok, hogy van egy központi tekintély, hívjuk mondjuk tanárnak, aki többet tud a világról, meg a feladatok megoldásáról, mint a diák, főleg még alsóban, és ő irányítja azt a munkát.

Meg ő irányítja a figyelmet, hogy na most arra is kéne figyelj, azt is meg kéne tanuld, hogy lehet azon vitatkozni, hogy nyolc egység vagy tizenkét egység információt kéne beletáplálni a gyerekekbe, lehet, hogy néha tényleg sok, de én hiszek abban, hogy megtanulni információkat raktározni, meg sokféle információt begyűjteni a fiatal éveid során, az utána később sokkal nyitottabbá tud tenni. Mert nehéz azt mondani ma, hogy te elindulsz egy pályán, és akkor mondjuk 40 év az minimum, ami úgy kijár a nyugdíj előtt, vagy egyáltalán ezt nyugdíj, addig azt a pályát azt úgy lehet vinni. Hozzáteszem, hogy egyébként informatikában is ez igaz, a nagyobbik fiam ő informatikusnak tanul a BME-n. Neki is mindig azt mondom, hogy akkor lesz jó informatikus, ha még legalább egy szakmát meg fog érteni, ahogy te is mondod, neki értenie kell azt, hogy mire fogják használni azt, amit ő csinál, és hogyan lesz jó?

Zoli.

Hú, de nehéz. Mindegyikőtökkel egyetértek.

Passzol?

Nem, nem szeretnék passzolni, csak mindegyikőtökkel egyetértek. Én azt látom.

Ugye én büszke apa vagyok, és nem posztolom öt percenként, hogy mi történik a gyerekkel, de a gyereket fölvették a sok díjra. Elképesztő dolog tőle. Amire én próbálom meg őt így tanítani, és nem látom ugyanezt az oktatásban, hogy merjen dönteni. Próbálja ki a döntését, és egyébként, hogyha van benne olyan, ami esetleg máshogy sikerül, akkor tanuljon már belőle. Ugye ebben ők egyáltalán nem támogatják. És akkor itt most térjek vissza a sajátomra. A kedvenc példám az, amikor engem ugye gimnáziumban példa statuálási célból, egy nap hat tantárgyból húztak meg, ami mind érettségi tantárgy volt. Mindezt azért, mert egyébként vitorlázásban jobb voltam, mint az átlag. És ők meg akarták mutatni, hogy márpedig így nem lehet.

Tehát a kreativitást azt azonnal el kell vetni, és van egy matektanár, aki ebben élen járt. És képzeljétek el, idén én lettem a főnöke. És csak annyit mondtam neki, hogy köszönöm azt az összes genyaságot, amit akkor genyaságnak éltem meg, mert most tudom, hogy ez adta meg azt a kitartást, ami azzá tett, ami vagyok. De nem tudtunk sokáig együtt dolgozni, mert ugyanazt kapta tőlem vissza, amit ő belém nevelt, csak ő már nem tudta ezt teljesíteni. Én ebben látok különbséget. Hogy ha egy iskolának van felelőssége, akkor abban is van felelőssége, hogy ha megtanít valamit, majd utána szembesül vele, akkor ismerje el, hogy Á, tanulhatott volna belőle B, lehet, hogy vannak különböző helyzetek és irányok, amiket meg észre kell venni és be kell építeni.

Ez egy ilyen többszörösen összetett mondat egyik része.

Igen, itt vigyázat, mert összetett mondataink vannak, és nem kerüljük meg a valóságot.

Mondhatok még erre valamit?

Természetesen.

Továbbmegyünk, hogy mi most negyvenvalahányan vagyunk, és borzasztóan büszkék mi is hasonlóan te a gyereked, minekünk is ez a gyerekünk is, másrészt ez a vállalkozás, hogy idén júniusban kötöttünk egy olyan globális stratégiai szerződést, csak látszólag félreviszem, de majd visszakerülök oda, hogy egyébként hogy csatlakozom az előzőekre. Kötöttünk az AWS-sel egy olyan globális stratégiai szerződést, amit itt a régión még soha senkivel nem kötöttek. Ennek számunkra nagyon világos a munkánkkal, a munkánk minőségével, a vállalásainkkal és azoknak a teljesítésével kapcsolatos tulajdonképpen értékelése történt ezzel. Abban a méretben, amiben mi utazunk, még mindig nagyon jól ismerjük az összes munkatársunkat, még mindig tudjuk, hogy kit miért szeretünk egyébként, hogy kinek mi az erőssége.

És akkor, amikor ezt most már tizedik éve csináljuk, és az első perctől kezdve azt gondoltuk, hogy nekünk valójában vállalati kultúrát kell építenünk, ami más, mint amiben mi szocializáltunk a közoktatásban, az arról kellett, hogy szóljon, hogy ha nem próbálod ki, nem fog kiderülni. Ja, hogy egyébként megtettél-e mindent annak érdekében, hogy egyébként az, amit te megpróbálsz, az jól sikerülhessen. De olyan van, hogy megtettél mindent, felkészült vagy kellő alázattal álltál a feladathoz, de a kellő alázatnak az is a része, hogy elismerd, hogy te abban elbuktál, és akkor ez nem egy szégyen, hanem az egy megosztandó feladat, hogyha egyébként te már egyszer kipróbáltad, vetted magadnak a fáradságot és a bátorságot, akkor oszd meg a hibát, ha többet kell javítsuk, és többet ne forduljon elő.

Én szerintem az egész felhő informatika erről szól, hogy olyan nagy a mozgástér, olyan sok az innováció benne, hogy azt nem vállalod föl, hogy tenned kell valóban azért, hogy eredményt érj el, és aztán döntést kell hoznod, ki kell értékelned, akkor ez nem egy ilyen tovagördülő, önmagát napról napra fejlesztendő lehetőség.

Igen, ez egy nagy különbség a mi gyerekkorunk, meg a gyerekeink gyerekkora között, hogy akkoriban sokkal kiszámíthatóbb volt egy csomó minden a világban, sokkal lassabban változott egy csomó minden.

Most sokkal dinamikusabb az élet, ez másféle hozzáállást is követel, és az alázat egy olyan érték, ami ilyenkor nagyon jól jön szerintem. De ha már itt a világról beszélgetünk, most mondanék számokat. Néha olyat is szoktam. Ugye fel szokott merülni a kérdés IT beruházásoknál, hogy akkor ez most hardver beruházás vagy szoftver beruházás, szerintem ezt egyébként meghaladtuk, de azt azért elmondanám, hogy a hardverre is van magyar szó, a Bak Józsi baráto, az IDC-nél egyébként szintén IDC a vas szót preferálja, és én ezt osztom. Na most a felhőszolgáltatásokra nézve az EU statisztikák szerint Magyarországon a vállalatok ötöde, tehát minden ötödik használ felhőszolgáltatásokat. Ezzel az ötödik leggyengébb adatot hozzuk.

Az EU átlaga 34 százalék, és egyébként a legjobb helyeken, tehát tipikusan tudjátok, a skandináv országokban háromszor ennyien használnak, mint nálunk, ott 60 százalék feletti az arány. Az egyik megjegyzésem rögtön, hogy én sem hiszem el teljesen a statisztikákat, hiába szoktam őket idézni. Azért azt tudni kell, hogy nem feltétlenül tudja a felhőszolgáltatásokat pontosan azonosítani az, aki válaszol ezekre a kérdésekre, tehát lehet, hogy ő is használ olyan felhőszolgáltatást, amit ő nem annak gondol. Mi lehet a saját ügyfélkörötökben a tapasztalatok szerint? Valóban, mondjuk így, hatalmas növekedés előtt áll a magyar felhőszolgáltatási tanácsadási piac, mondjuk így a ti piacotok, illetve, hogy lehet, hogy ennyi elég is.

Tehát, hogy még jó, hogy nem kétszer ennyien használnak, mert akkor végképp bedöglene az élet, merthogy nincs ennyi szakember.

Én inkább a pozitív ágát emelném ennek ki.

Ugye amikor azt mondtam az elején, hogy ez kiderült, hogy semmi nem úgy van, tehát hogy nincs felkészültség, nincs érettség, nincs szabályozás, nincsenek készen arra, hogy ezt a fajta transzformációt az ügyfeleink megtegyék, akkor egy dolog mégis biztató volt, és szerintem ez az egy, ami a legerősebb horderejű, hogy nem 30 év a technológiai transzfer. Tehát most mi lemaradók vagyunk-e, vagy lemaradottabbak vagyunk-e, jobbak-e nálunk a nyugat-európaiak, vagy a skandinávok. Biztos sok mindenben van mit tanulnunk, rengeteget van mit tanulnunk. Kiváló felkészültségű szakemberek vannak egyébként, ezt látjuk Magyarországon is. Én azt emelném ki, hogy az esély és a lehetőség, hogy egyébként mi ebbe a nagykabátba belenőjünk, ez itt van.

Tehát a saját mintánkba és a saját példánkból látjuk, hogy a tizedik évet kezdjük jövőre, tehát kilenc éve végezzük ezt a felhőinformatikai bizniszét Magyarországon, hogy végül az elmúlt három évben, vagy három évvel ezelőtt, azt nagyon sok invesztíció, edukációt követően sikerült áttörni a konvenciókat. Tehát, hogy ott tartunk, hogy ma nincsen anélkül döntés a legnagyobb banknál vagy a legnagyobb telkónál, vagy a legkisebb textilvállalatnál sem szerencsére, hogy ha valamit akarok, akkor azt megvizsgáljam, legalább eljussak odáig, hogy megvizsgáljam, hogy a felhőben meg lehet-e csinálni.

Abszolút alá tudom támasztani, tehát hogy a gyakorlati tapasztalat, mi a kiberbiztonság részét csináljuk most már húsz éve. Az látszik, hogy még ezelőtt, mit tudom én, 2014 környékén szóba se jöhetett. Minden on-preme, építsünk szervertermet, nem tudom én micsoda. Még 2018 környékén is volt olyan IT főnök, aki. Mit képzel maga Zoltán? Kezdte a beszélgetést. Most már ő nincs ott, de felhőbe költöztek az adatok, de amit még mindig problémának látok, hogy az IT-hoz tartozó üzleti Chatgpt modell, tehát amivel le tudom fordítani az üzletet, és megértem, és vissza. Most kitalált az üzlet, ilyen Cisho, Misho, Bisho, Lisho, az összes négybetűs, akivel megpróbáljuk egy ilyen közbülső tolmács robot szerepet betöltetni, miközben ők is szakemberek.

Nekik sem ez lenne a feladatuk, hanem az lenne a feladatuk, hogy a logokból megtalálható információkat a biztonságra, az IT üzemeltetés felé, és egyébként a vezetőség felé el tudják transzformálni, hogy úgy mondjam. Mindig elmondjuk, hogy szép a felhő, de azért egy nagyon fontos dolgot meg kell állapítanunk, hogy vannak olyan kritikus helyzetek, amikor nem lehet felhővel megoldani, mert vagy fizikailag az összekötő kapocs hiányzik, ami viszonylag gyakran előfordul, hogy az összekötő kapocs, ami elviszi a felhőig, nem akarom a telkókat nagyon ekézni, de azért van fejlődési lehetőség ebben, de amit szerettem volna kérdezni, és ez még mielőtt a személyes szálra tértünk is kérdés volt. Ugye azt mondjátok, hogy van egy csomó ajánlás, amiben végig lehet menni.

Az IT-s környezetben, amikor régen azt mondtam, hogy itil, az számotokra mond-e valamit, és használjátok-e?

Igen.

Igenis, igen.

Tehát alapvetően ez Ethel köré van építve. Nyilván az AWS is nem úgy dolgozik, hogy akkor ő elmegy, és akkor valami teljesen, nem tudom, ilyen marsról kapott ötleteket így összepattint, tehát hogy a sztenderdek köré van építve minden. Tehát, hogy itt azért ilyen szempontból nincs új a nap alatt sem a technológiák, sem a szolgáltatások, sem ajánlások, sem másban. Tehát ez mindenhol, mindenkinek ismerős lehet. Aki ilyen szempontból képzett, az egy pillanat alatt azt mondja, hogy aha, és akkor ennek felel meg, az annak, és egyszerűen folyamatilag is, és minden szempontból ez összeáll.

És ugye erre kiválóan egyébként ez egy szuper kérdés, mert akkor erre kiválhatunk úgy válaszolni, hogy ezt mi képzeli a legjobban, ugye nekünk ez a most elért legnagyobb szakmai dicsőségünk az utóbbi időszakban, hogy mennyi Service Provider lett a TC2. Megint csak a Magyarországon az egyedüliként, és most úgy néz ki, hogy a szír régióban, tehát Kelet-közép-európában is az egyedüliként, ez ma a legmagasabb szakmai rang. A Karcsi csinálta ennek a nagyon fájdalmas auditját a csapatával végig, úgyhogy azért beszélhetnél erről egy pár szót, ha már a Zoltántól az Itt él, fölmerült kérdésként.

Igen, ez fontos.

Tehát, hogy azt látom, hogy a büszkeségnek az, hogy ti ezt meg tudtátok csinálni, itt az ordas munkájáról egy picit, hogyha ki tudnád emelni a csapatodnak a teljesítményét, ez az óriási elképesztő teljesítményt csináltatok.

Igen, ugye mi az ügyfelek AWS workloadjait már nagyon-nagyon sok éve üzemeltetést támogatjuk, tehát egyrészt bármi gond felmerül, akkor van rá helpdesk, beadják a ticketet, ez nyilván a kisebbik része, tehát ez az ethok. Ott van a másik fele, az optimalizáció, amiről korábban beszéltünk, tehát hogy folyamatosan egyre jobban működjön biztonsági szolgáltatások, költség, operational, reliability és a többi.

Igen, és ezt mondani könnyebb, mint megcsinálni.

Hát igen, igen. És akkor nyilván, hogy ez flottul menjen, tehát nemcsak, amikor éppen eszébe jut annak, hogy emögé processzeink legyenek. És hát akkor ez a Meryl Service Provider program, ez arról is szól ezentúl, hogy az egész Journey-t olyan AWS által lepecsételt módon felkaroljuk, hogy az üzletileg hogy néz ki, mik a fontos kémiájuk, hogy hogy tud ez sikeres lenni, az alá hogy néz ki a technikai megvalósítás, folyamatok szintjén, emberek szervezetileg, és ez az egész összeáll egy termékké, amit mi hatékonyan tudunk támogatni, és ez egyfajta partnerség az ügyfeleink és az AWS és mi közöttünk, tehát egy ilyen hármas házasság, és végül is erről kaptunk, tehát két napig forgattak minket, tehát kétszer nyolc órában, hogy milyen folyamataink vannak, mutasd be a dokumentációt, és ez hogy történt, és hogyha ez történik, akkor mi történik?

Igen, ez egy elég végeláthatatlan beszélgetés volt. Nyilván, ha nem is voltunk tökéletesek, de abszolút igen, simán átmentünk, úgyhogy.

Szabad egy kicsit dicsekedni szerinted, hogy ez egy próbaprogram volt egyébként tavaly az AWS-től, és mi nagyon korán úgy gondoltuk, '17-18 környékén, hogy nagyon pici volt a cég, rengeteg kölcsönünk volt, zéró bevételünk, klasszikus eset volt, nagyon fájt, időben, energiában, pénzben, és ez egy tudatos döntés volt, ezzel együtt nagyon fájt. És akkor azt gondoltuk, hogy az elfogadottsághoz sztenderdek kellenek. Például kellenek az izomminősítések. Nagyon fontos, hogy legyen egy 9001-ünk, de még talán sokkal fontosabb, hogy 27001-es megfelelőséget lehessen lerakni, és azt lehessen mutatni a piacnak, hogy áttekinthető módon, szabványok és standard folyamatok mentén tesszük a dolgunkat, számol át bennünket ebben kérni.

Azzal jött elő tavaly az AWS, hogy az ügyfél és a partner közötti stratégiai együttműködésnek ez az MSP a legjobb hordozó közege. Több ilyen partner, nagyon kevés ilyen partner van a világban ma még egyébként, és akkor nyolc darab partnert válogattak be, tulajdonképpen egy ilyen trágyába, vagy egy ilyen próbajátékba. Hét észak-amerikait és a TC2-t. Itt a lottószámokat is kihúzhattuk volna. Most ebben nyilván volt nagyon komoly szakmai előéletünk, amit ígértünk, azt teljesítettük, tehát kiszámítható módon, mi mindig kiszámítható módon működünk szerintem. És akkor az egy héten keresztül ment napi, nem tudom, 5-8 órában egy felmérés, hogy az Itil V4, és egyébként az AWS-nek a Next Generation MSP, bocsánat, ezt nem lehet, vagy én nem tudom ennek a magyarul mondani, ennek a kettőnek van egy nagyon konkrétan megfogalmazott elváráshalmaza az AWS-től egy partner felé, hogy te MSP-re es.

És akkor tulajdonképpen arról szólt az egész hét, hogy hol vagy te ehhez képest. És akkor a végén ennek lett egy gepanalízis, meg egy ilyen feladat javaslata. És akkor ott az volt, hogy ránk bízták, hogy ennek mikor fogunk tudni megfelelni, és akkor végül ezt úgy zártuk, hogy ahhoz, hogy eljuthass odáig, hogy több napon keresztül nagyon durva, külsős partner által auditálva vagy, el kellett végezni a házi feladatot, mindent be kellett adni, és amikor minden pipa a beadandók mellett ott volt, mint az egyetemen, akkor azt mondták, hogy formailag rendben vagytok, akkor nézzük meg, hogy egyébként egy szörpparti, aki sosem az AWS, hogy ne legyen valamifajta ellentmondás vagy összeférhetetlenség, akkor ő auditálni fog benneteket, és akkor ennek az auditnak lett az eredménye az, hogy akkor nekünk van egy ilyen elismertségünk, egy szakmai rangunk, hogy MSP partnerekké váltunk.

Ez egy nagyon ritka itt a környéken.

Az a helyzet, hogy ez egy lépcső ahhoz, hogy a NATO minősítést is megkapjátok, tehá, hogy nagyjából ennyire, tehát valahogy ezt próbálom a hallgatóknak elmagyarázni, hogy az ISO 27 ezer az IT-lel kombinálva, plusz az, amit most megkaptatok, minősítés, azért az sokkal magasabb rangot is képes egyben befogadni, aminek nincs feltétlenül megfelelő pecsétje, csak ennek a súlyát szeretném valahogy mondani, hogy na ez az.

És még durvább a helyzet ennél, mert vannak bizonyos plecsnik, amiket az AWS minden évben auditál, hogy ez tök jó, hogy ezt megcsináltad, de hogy egy évvel később, ez még mindig így van, ezt fönntarthatóan tudod csinálni, vagy akkor szerencséd volt, vagy betettetek, és aztán utána hajnalodik. Szóval nem nagyon van lehetőség elaludni. Ez nyilván folyamatos tudásfejlesztést igényel, szervezetfejlesztést igényel, kultúrát igényel, ismételten fenntartható módon kell ennek megfelelni, ami szerintem azért nagyon jó, és akkor ígérem, most fogok utoljára dicsekedni, de ha csak hogy kontextus legyen, hogy amikor mi ezt a stratégiai szerződést megkötöttük az AWS-sel júniusban, vagy júliusban, már nem emlékszem ennek a.

Akkor ezt olyan cégek kötötték még meg áprilisban az AWS-sel, mint a Bigfordból az egyik, a másik, meg a harmadik, de Észak-amerikában. Tehát nem abban a méretben, amiben mi, de ugyanaz volt pontosan az elvárás. Tehát, hogy szerintem az az ügyfeleinknek, a piacainknak egy nagyon fontos üzenet, hogy lehetsz negyvenezren, meg lehettek negyvenkettőn ma, de hogy ahhoz, hogy ezt a rangot megkapd, pontosan ugyanaz a transzparens feladatlista elvárásrendszer van, mint ami mindenkivel szemben van. Hiszen az AWS-nek az az immanens érdeke, hiszen partnereken keresztül szállít, hogy az ügyfél a piac úgy értékelje, hogy ez a technológia megfelelően jól lett alkalmazva.

Én azt gondolom, hogy ez egy nagyon jó inspiráció lehet a kkv-s hallgatóinknak, hogy a maguk területén ilyen minőséget nem kell meghagyni a Bigfordnak, meg a nagy tanácsadó cégeknek, erre lehet aspirálni. És ha már büszkeség, én meg akkor hadd legyek arra büszke, hogy ezt először a Digit Podcast csatornáján veséztétek ki velünk.

Ez most a lehetőséget.

Hát azért még ennyire könnyen nem ússzátok meg a lehetőséget szívesen, de akkor élnénk is vele, és még egy-két kérdést föltennénk. Ugye a beruházások iránya vagy hardver, vagy szoftver, na de az egy még érdekesebb kérdés, és szerintem a hallgatók már így látják, hogy ez nálatok is a legelején fölmerül, hogy jó, de akkor ti milyen, mármint az adott ügyfél milyen területen fogja ezt használni, és azért azt jó, ha tudatosítjuk, hogy a felhőszolgáltatások tényleg az összes iparágban tudnak előnyöket teremteni, és mondjuk itt is idéznék egy kutatást az egyik Bigford Tech Riport szerint. A következő, hát egy-két-három-négy-öt-hat célra költenek azok, akik felhőszolgáltatásra költenek. Ugye az egyik a legújabb technológiák működtetése, akár az IL-t és a Quantumot is ideértve, ez kb. a fele a válaszadóknak.

Nem sokkal ettől elmaradva a különböző adatforrások összekapcsolása azért, hogy lehessen elemezni. Ez a van adatunk, de hol van, és ki fogja azt összerakni. Utána jön kicsit kevesebb 41 százalékkal, hogy a lehető legtöbb alkalmazást helyezzük ki a felhőbe. Én itt az üzletmenet folytonosságot érzem emögött. Még ilyen célok is szerepelnek, hogy a biztonság, meg a törvényi megfelelés, az új termék és szolgáltatások fejlesztése, az ugye akkor nincs az élen, de itt megjelenik, illetve van még ilyen, hogy költségoptimalizálás, vagy akár az üzleti modellnek az átalakítása. Tehát azért tényleg nem azért megyünk a felhőbe, mert egy dolgot lehet vele elérni, hanem lehet, hogy neked ez, neked az, lehet, hogy neked előbb ez, aztán jövőre az.

De ha már itt tartunk, nézzük meg ezt egy kicsit a pénzügyek szempontjából is. Itt ugye, ha már Zoli a műsorvezetőtársam, aki gazdasági informatikát tanít, akkor kicsit így az ő nevében is feltéve a kérdést. Már feltettük egyébként egy gyártó cégnek is, de most akkor feltennénk egy integrátornak, ha szabad titeket integrátornak hívni. Milyen forrásból finanszíroznak ma titeket? Milyen pénzügyi forrásból mennek ma ezek a projektek, hogy például pályázati forrásból, vagy olyan nagyberuházások, amelynek része ez a felhős projekt, vagy alprojekt, vagy akár csak tárhelyfejlesztés címén, de akkor már ezt meg azt megnézzük. Vagy olyan, hát éppen maradt egy kicsi a nyereségből, vagy muszáj, és akkor nem tudom, kikanyarítunk valamit költségátcsoportosítással, mert muszáj.

Én itt a felsorolt motivációt épp azon bólogattam magamban, hogy igen, tehát mindegyik igen, hogy én szinte fejben kötöttem össze a pontokat, hogy ez nem az, hogy melyik, hanem hogy milyen sorrendben. Jellemzően úgy kezdődnek ezek a legtöbb projektünk úgy kezdődik, nyilván vannak kivételek, hogy mi a belépési pont, de hogy van valamilyen hagyományosnak mondható rendszer, egy nem tudom, egy SAP, vagy valamilyen portál, vagy bármi, és akkor megkérdeznek minket, hogy hogy lenne ez a felhőben.

Miért mondjuk kivezetik az On Premise-t?

Csak így mondjuk.

SAP-ban kevésbé járatosak.

Igen, tehát nem biztos, hogy, tehát nem csak ez a mozgatórugó, és akkor ott van egy olyan bizniszkész, hogy már a jelenlegi megoldás is olcsóbb, és biztos, hogy van a jövőben kitekintése a cégnek, tehát stratégiai célok vagy vízió, tehát hogy ezeket az új technológiákat, innovációkat használja a felhőben, és ezzel elindulnak. És nagyon sokszor egyébként ez alá van támasztva, még esetleg ilyen regulációs igényekkel, tehát sokkal-sokkal könnyebb, mondjuk egy felhős környezetben, ahol az egyes platformerek le vannak már pecsételve mindenféle ilyen complianc, meg regulation framework-ökre, hogy ott összerakjunk egy olyan alkalmazást, aminek ennek megfelel, és hogy az Audit az ne legyen véresen komoly, nem tudom, minden x évben.

Mondom a hallgatóknak, hogy nincs kettő. Tehát bármelyik időpillanatban lehetnek nincs kettő kötelezettek, és akkor valamilyen döntést meg kell hozni. Tehát most azt gondolják sokan.

Bocsánat, de szerintem ide tartozik.

Abszolút.

Költségtervezés. Az elmúlt szintén fél évnek az egyik ilyen gondolkodása, hogy a Checkbox Compliance. Ó, megleszünk, meg kivesszük az izét, a teaorszámokat, meg mit tudom én, tegnapelőtt, azt hiszem, az hétfő. Csörgött a telefon, hogy hát baj van.

Tényleg?

Tehát sikerült meghaladni, és annak ellenére, hogy kivették a távorszámot, ismét kötelesek. Na most mit csináljunk? Hát mondom, most már nehezebb lesz, mert sokkal rövidebb idő alatt kell nagyobb produktumot előállítani, amihez eddig ugye arról beszéltünk, hogy dehogy lesz ezzel nekünk dolgunk ebben az évben. És én erre szeretném gyorsan itt a költségeknél mondani, hogy akkor, amikor rugalmas megoldások, és én visszaadom, csakhogy a rugalmas megoldások ennél a mondatnál érkeznek be, és ezért érdekes az, hogy például egy kisvállalati megoldásnál, hogyha most megvan minden egyes itiner, végig tudtok rajta menni, akkor mi az a legrövidebb belépési idő? Most még egyszer ez fontos, tehát szabályszerűen szeretnénk végigmenni, de hogy van egy minimum pont, ami az n-edik lépéstől az auditig tart, és az n-edik lépéstől az auditig, mi az, amivel minimum számolni kell, hogyha a legrugalmasabb megoldásban is száz százalékig fel vannak készülve, és gyakorlatilag megvan hozzá minden egyes szabályzatuk, ami nincs.

Tehát, hogy most tegyük fel egy nagyon optimális, ezért fontos számomra ez a kérdés, és ezért, hogyha megengeditek, akkor visszatérek rá, és megkérdezem ennél a pontnál.

Tényleg ez elsikkadt az előbb. Tehát, hogy mi ez a legrövidebb idő. Hát igen, én nagyon utálom azt mondani, hogy attól függ, mert ez egy nagyon csapnivaló válasz, de mondjuk tegyük fel, hogy nagyobb szervezeti méretről beszélünk, tehát mondjuk tegyük fel, hogy egy bank. Tehát az, hogy egy ilyen sztereotípia.

Ráadásul Dóra vonatkozik, de hogyha mondjuk nézzük meg egy olyan kkv-t nézzük meg, ahol mondjuk 150-en vannak.

Aha.

150-en, igen, mert mindig oda fut ki, hogy nekünk van egy sztenderd ajánlásunk, amit aztán rá tudunk szabni az ügyfél szervezetére. Hogyha ez a sztenderd ajánlás nagyjából jó, és nem tudom, kettőt kell tekerni rajta, ugye mi mindent automatikus módon, infrastructure-es kóddal implementálunk. Tehát nekünk van rengeteg ilyen kész modulunk, hogy azokat a megoldásokat, amiket mi azt mondjuk, hogy tudjuk, azt mi úgy tudjuk, hogy azt nagyon hatékonyan ki tudjuk futtatni, hogy a Security by design, minden be van állítva bele, tehát ez a része, nem is tudom. Tehát maga a kifuttatás, az nyilván órákban mérhető, a konzultáció, satöbbi, az mondjuk nagyon ideális esetben hetek, de mondjuk két-három hónap, az szerintem megállja a helyét.

Tehát azért legyen ez egy félév.

De mondjuk legyen egy félév. Versus, tehát ugye az szokott lenni a probléma, hogyha mi így szoktuk, de nem lehetne, és ez jellemzően egyébként a tájékozatlanságból fakad, tehát, hogy valaki nem érti a felelős modellt, mert aztán eltöltünk három-négy hónapot, van ilyen upskilling, ilyen oktatás és minden, és akkor a homlokukra csapnak, hogy ja, hát ez nekünk akkor jó lesz így, meg hogyha jó másnak, tehát hogy nyilván egyébként ilyen szinten, ami nem üzleti, hanem operatív, meg IT funkciók, azok jellemzően egyébként nincsenek nagy különbségek.

Megengedtek ilyen provokatív kérdést, hogy vannak ilyen belépési összeküszöbök?

Tehát, hogyha most mit tudom én, a másik gyártó infrastruktúra felhős megoldását nézem, akkor ott van mondjuk egy ilyen ötvenmilliós minimum. Ehhez képest följebb-lejjebb hogy kell ezt elképzelni. Tehát azért mondom, hogy itt azért nagyon fontos, hogy a számoknak a bűvöletében most tudjuk, hogy azért minimum öt hónapot rá kell erre szánni minimum, és ez egy optimális eset, tehát hogy még egyszer a mérnököktől azt a választ, én nagyon köszönöm, hogy ebben partner voltál és mondtál egy számot, mert ez nagyon ritka. De most ugyanerre gondolnék az összeggel is, hogy hol van az az 50 millió fölött vagy alatt. És akkor ez így szerintem egy ilyen.

Sajnos, szerencsére alatt, bőven alatt. Mondjuk, hogy két példa jut eszembe, név nélkül, iparág nélkül azt mondani, hogy vegyünk egy olyan ügyfelet, aki egyébként már van valamilyen mértékben a felhőben, meg vegyünk egy olyan ügyfelet, akinek egyébként vannak már elvárásai a felhőben, de nagyon az útnak az elején elmondjuk, hogy nem tett még nagyjából semmit, akkor az az ügyfél, aki már fönt van, az egy idő után rájön, hogy nem tudom másképp mondani, hogy elfogyott. Szakértelemben nem tudja azt a tempót, azt a lépéssort tartani, amit egyébként az AWS diktál hónapról hónapra, akkor ott például úgy érkezünk meg, hogy azt mondjuk, hogy akkor nekünk van egy, a Wella Rectedre épülő, van egy partneri kompetenciánk, egy minősítésünk, egy badge-ünk, meg van egy szaktudásunk, akkor a következő, és akkor ez nem hat hónap, a következő, mondjuk kettő, négy hét, legyen három, a következő három hétben egy túllal és a szaktudásunkkal átvizsgálunk, hogy egyébként Securityban, performanciában, kosztban, integrációban hol térsz el a legjobb gyakorlatra, és akkor a harmadik hétnek a végén leteszünk egy elemzést, hogy itt vannak ezek a brio1-esek, amit azonnal meg kell csinálni, és ott vannak azok a feladatok,

amiket egyébként a következő roadmap-re föl lehet tenni. És akkor ezek három héttől mondjuk eltelhetnek hat hétig. Ez nagyjából az ingyen kategóriába tartozik, mert akkor mi azt gondoljuk, hogy van is hozzá tartozó program, egyébként egy AWS program, hogy egy hitelt érdemlő szaktudást tudtunk bíztatni. Egy bizalmat tudtunk építeni, mert azt tudtuk mondani, hogy megnéztük, ezt sokkal jobban is lehetne csinálni. Itt értetek el ezen a mi javaslatunk. Megcsináltathatjátok velünk, megcsinálhatjátok ti magatok is. A másik, amikor azt mondja, hogy még nagyon az elején vagyok, még nem léptem, de már szeretnék, mert vannak nekem dolgaim, amik miatt ezeket ott mondjuk azt mondom, hogy mentés archiválás, csak hogy egy ilyen nagyon egyszerű példát mondjak, akkor az egy pár millió forintos tétel, és a pár millió forintos tétel itt egy nagyvállalatról beszélek, tehát nem egy ötfős kkv-ról beszélek, hanem akkor egy nagyvállalatról beszélek, hogy akkor egyébként hogy megy a mentési policy, milyen RTO RP adatokkal operálsz, milyen veszteséget, időablakot tudsz egyébként elviselni.

Egyébként milyen eszközöket használsz, milyen szakértelmet, licenceid vannak, akkor ezeket átvizsgáljuk. Ez egyfajta átvizsgálás, konzultáció és egy sztenderdek mentén kialakított teeringet, hogy hogy kell ezt magyarul mondani, amikor különböző osztályokba rakod föl ezeket a minősített adatokat különböző mértékben.

Ez most megint fontos, hogy a Nis2-nél 1-2-3-as osztályokba kell besorolni, csak megint próbálok visszacsatolni, hogy a NIS2 hol köszön be.

Na jó, hát ez meg egy, ez meg egy, mondjuk akkor egy két hónapig vagy három hónapig tartó, picinek tekinthető, de rendkívül értékes projekt, most nemcsak azért, mert jöhetett egy ransomware, vagy jöhetett bármi más, hanem azért is, mert mondjuk van szabályozói kötelessége, hogy a földön kívül még mondjuk attól független mentési rendszer, vagy mentési pozíció kell, hogy legyen. És akkor elmentünk odáig, hogy egyébként öt éve fejlesztjük a nagyvállalatot, aki egyébként '18-ban kezdett el velünk dolgozni, és akkor ez ilyen szempontból egy állandó innováció.

Bocsánat, én még visszakanyarodhatok.

Ugye ott kanyarodtunk el, hogy elkezdik a cégek egy-egy migrációs projektet állítani, mert kijön ugye a TCO-ban, tehát költségekben, és a reguláció volt itt a bűvös szó. És akkor mondjuk felmegy az első alkalmazás, és a működési modellt akkor elkezdjük ráfaragni, automatizálunk, és nem csak az alkalmazás szinten, hanem működési modell szinten is elkezd egyre optimálisabban működni az egész ilyen hibrid felhős működése a cégeknek, és akkor mi elkezdjük hozni az ilyen kisebb ilyen adatos megoldásokat. Tehát, hogy nem tudom, a költségekre vannak ilyen nagyon szép kis színes szagos kimutatásaink. Tehát, hogy ez is egyébként big data, tehát ez nem Excel, hanem már ez is data lake-ben feldolgozzuk, vannak ráadásboardok, akkor például, hogyha a migráció előtt vagyunk, ott is lehet, hogy több ezer szervert kell prezentálni, és akkor abból kihozni, hogy melyek hogy kapcsolódnak egymáshoz, hogy érdemes vágni, hogyha itt vannak ilyen migrációs hullámok, ilyen csoportok, hogy mit vigyünk fel.

Ugyanez igaz a Security-re is, és akkor az ügyfél elkezd kedvet kapni, hogy na, hát ez ilyen jól működik, meg így plug and play. Elkezdenek ők is játszani az adattúlokkal, tehát itt van az adatkapcsolódás, vagy nem is tudom, hogy valami hasonló volt a megfogalmazás. És egyébként nagyon jó látni, hogy az ügyfelek elkezdik megérteni, hogy mi van ott a platformon, és elkezdik használni, és akkor amint ez látszik, hogy ez jól működik, és van már egy olyan stratégia, hogy milyen új alkalmazások menjenek a felhőbe, vagy miket migráljunk át, utána elkezdődik a sok alkalmazás migrációja, tehát látszik, már megvan a bizalom, és megvan a business case-nek az alátámasztása a gyakorlatban is. És hát akkor jönnek ezek az AI-os történetek ezután, bár egyébként valaki ezzel kezd, de előbb-utóbb mindenki eljut oda, hogy ki kellene próbálni ezeket a service-eket, és akkor rákattint, és beírja a pontba, és visszaadja minden, ugye nagyon szépen ilyen regulát, meg szekül módon körbe van támasztva logolással, hozzáférés menedzsmenttel, stb. stb., és a legtöbb ügyféllel ilyen hosszú távú együttműködési kapcsolatban vagyunk, úgyhogy ki hol tart, meg milyen sebességgel, de azért látjuk, hogy bejönnek ezek a hívószavak.

És akkor visszakanyarodva erre a kérdésre, hogy miből finanszírozzák a cégek mindezt, amiről ti itt beszéltek.

Karcsi mesélt már arról, hogy nagyon furcsa

ez is egy szörnyeteg végül is, ez az AWS, hatalmas monstrum.

Nagyon furcsa módon működik, tök másképp, mint a százéves múlttal rendelkező informatikai multinacionális nagyvállalatok. 2006-ban kezdte a működését, tök más a háttere, ugye ez mégiscsak egy webshop volt. Rájöttek, hogy egyébként ez egy borzasztó hatékony, elosztott kapacitású rendszer, miért ne lehetne ezt annál tovább vinni? Miért ne lehetne ebből egy üzleti modellt? Szóval az, amiről Karcsi az előbb beszélt, hogy casting robsession, tehát ez a fajta elköteleződés, hogy ügyfélérték, vagy amiről az előbb arról beszélt, hogy nem abban vagyunk érdekeltek, mint partner, bármilyen meglepő is, hogy egyre több és többet költsön az ügyfél, hanem abban vagyunk érdekeltek, hogy optimálisan, hogy őszerinte, az üzletének megfelelően optimálisan legyen tartva a költése.

Ez azt jelenti, hogy hosszú távon gondolkodunk, abban gondolkodunk, hogy minél tovább együtt tudunk maradni, minél jobban egyébként azt az értéket szállítjuk, amit egyébként az üzleti érték kapni szeretne, annál stabilabb az együttműködésünk. Programok vannak arra. Program van arra, hogy - és ez ebben motivált a TC2 is, hogy vizsgált fölül háromhavonta egyébként a költségstruktúráját, egyébként, amit az AWS elköt. Nézd meg, hogy annak milyen funkciói, milyen elemei vannak, amiket lehetne ma nagyobbat, olcsóbbat, szebbet, jobbat csinálni. Mutasd ki, hogy egyébként ugyanazon szolgáltatási halmaznál ma már le lehetne vinni mondjuk a felére a költségét. Ez egy program, rengeteg program van. Ami ilyen szempontból a legjobban használt és szerintem a legjobban működő programja az AWS-nek, ez a partnerségünkhöz, ez a Migration-höz kapcsolódik.

Van egy úgynevezett Migration Acceleration program, a map-nak hívjuk, map a leánykori neve. Ez a map arról szól, hogy amikor az ügyfél fölmegy a felhőbe, fölkísérjük a felhőbe, akkor annak egyébként kell egy ilyen pénzügyi fedezete is. Mert lehet olyan helyzet, amikor liften, shift alapon, azaz mindenfajta változtatás nélkül fölviszed azt az alkalmazást, vagy annak egy részét a felhőbe, ott igenis előfordulhat, hogy maga az infrastruktúra lehet drágább annál, mint ami korábban volt. Jó, lehet, hogy jobb lesz a latency, jó, lehet, hogy automatizált lesz a mentés, jó, lehet, hogy egyébként a DRB BCP-ben kikényszeríthetőek lesznek egyébként a haváriáknak évenként a 18-szori lepróbálása, tehát hogy egy csomó olyan kontrollpontot építesz be a működésbe, amitől egyébként ott biztonságosabb, megfelelőbb lesz, komplikáltabb lesz a működése, kevesebb emberrel hatékonyabban tud működni, de akkor is van az infrastruktúránk, vagy lehet az infrastruktúra olyan szintje, amitől egyébként meg magasabb a költség.

És akkor azt mondja az AWS, hogy akkor ezt csináljuk úgy, hogy akkor ebben a MAP programban kísérjetek át az ügyfelet, válassz ki egy réteget, és azon játsszuk végig ezt a teljes migrációs folyamatot az elejétől, tehát a tervezéstől, az implementálástól az operatív modell kialakításáig, ami látszólag egyszerű, de abban valójában akkor szervezet épül, folyamat épül, elköteleződés épül. És akkor azt mondja, hogy ehhez kereskedelemtámogató eszközöket adok. Tehát adok visszatérítést. Adok a partnernek projekttámogató forrást. A projekt támogató forrás azt jelenti, hogy meghatározott metrikák szerint a partner a TC2 az ügyfél felé jelentős mértékben le tudja csökkenteni a projekt bekerülési értékét.

Ha ez mind megtörtént, és ennek a szakasznak a végén úgy értékeli az ügyfél, hogy valóban KP-ket definiáltunk, ezeknek megfeleltünk, láthatóan kicsiben már működik, és ugyanezt a gyakorlatot kéne gyászszerűen, sztenderd módon ismételni, replikálni, akkor átmehetünk abba a fázisba, meg arról szól, hogy modernizáció, tömeges migráció, és ott meg azt mondja az AWS, hogy jó, hát ennek az egész újragondolásnak, ennek a Journe-nek azért van egy útja, meg van egy ideje. Mondjuk, hogy ez három év. Akkor három éves szerződést kötök vele, és azt mondom, hogy ebben a három éves szerződésben, amikor mész fölfelé az alkalmazásaiddal a felhőbe, akkor én minden negyedévről negyedévre a növekményre a 25-től 75 százalékáig a költésednek visszaadom.

Szerintem ez egy elképesztően motiváló üzleti modell vagy pénzügyi modell, ami ennek a hátterében van. Tulajdonképpen azt szokta mondani, hogy ez az egész egy nagyon agilis világ, de valójában egy vízesés modellben fölvázolunk az elejétől egy végéig tartó projektet. De annak mondjuk a hét szakaszát agilis módon közöljük. Azt mondjuk, hogy leszállítottunk egyet, ezt definiáltuk előre, megnézzük, hogy még mindig ott tartunk-e a priókban. Még mindig ott tartunk a szervezeti fejlesztésben. Az, amit mi csinálunk, az nem csak arról szól, hogy megértjük, megtervezzük, együttműködve leszállítjuk, és aztán optimalizálunk az üzemeltetés támogatásban, hanem fejlesztjük az ügyféltudást. Tehát ez az abskillingnek csúfolt valami.

Hogy ez nagyon fontos, hogy az ügyféloldalon felképzett szakemberek dolgoznak veled. Ez megint egy látszólagos elem, hogy mennyivel jobb lenne, ha egyirányú lenne az utca, mindenki a TC2-höz kellene, hogy kösse az életét, de nekünk ez nem sikeres. Nekünk az a sikeres, hogyha a túloldalon lévő szakemberrel ugyanazokon a szavakon ugyanazokat a fogalmakat értjük, könnyebben tudunk sikert mérni például. Szóval, hogy akkor lépésekre bontjuk, és azt mondjuk a lépésnél, hogy akkor menjünk-e tovább. Tovább megyünk mindig egyébként, de hogy akkor ennek van egy ilyen kiszámíthatósága, lehet kockázatot csökkenteni, azt lehet mondani, hogy eddig nem mentünk tovább, mert közben történt valami piaci változás.

Lépésekre vagy lépésekre. Van egy nagy tervünk, amit elfogadhatunk, azokat lépésekre bontjuk, és minden lépésnél megnézzük, hogy még mindig ezt látjuk-e a privónak, még mindig ezt látjuk-e a feladatnak, és menjünk-e tovább a másodikra. Úgy menjünk-e tovább, hogy egyébként annak idején ezt elterveztük.

Hát ez is egyfajta ügyféligény-megszállottság, azt gondolom. Itt most azért elég sok ilyen.

Jó, mondom, mítoszt lebontottunk remélhetőleg.

Igen, hogy is mondtad, hogy agilis és vízesés, igen.

Ezen biztos sok ember mosolyog, de tehát hogy teljesen agilisan sem jó az egészet beereszteni, mert akkor meg annyiféle impulzussal találkozik az ügyfél, hogy nagyon ilyen cikkcakkba megyünk, tehát valameddig el kell jutni, és azt viszont körül lehet nézni, és az irányt esetleg finomítani, kicsit módosítani, így van.

Igen, és rengeteg ötlet be szokott jönni, és csináljuk ezt még, csináljuk azt, vegyük hozzá, nézzük meg, amint megérzik ennek az ízét az ügyfelek, onnantól kezdve meg nagyon szeretik, hogy ez jól működik, és tényleg ez nem csak ilyen dokumentáció szintjén működik, hanem valójában, és ezért kellenek ezek a milestone-ok, ez tényleg ez az ügyfélnek se kockázat, nekünk se.

Mindenki szereti ezt, úgyhogy igen.

Hát így ebédidőben akkor lehet mindenféle szólásokkal dobálózni, hogy a puding próbája az evés, meg hogy a közben jön meg az étvágy. Még egy apró adat, hogy a már említett KPMG felmérésben a vezető kétharmada azt mondta, hogy az elmúlt két évben így a digitális transzformációs erőfeszítések hatására igenis nőtt a cég teljesítménye, meg a profitabilitása. Tehát többségében ez jó döntésnek bizonyult. Én azt remélem, hogy a hallgatók is kaptak ma impulzust arra vonatkozólag, hogy ez nem egy hype, meg nem egy lenyúlás, hanem ez egy igenis valós alternatíva az informatikában. Most itt abba kell hagyjuk, mert végképp kimerítjük a hallgatók türelmét. Károly és Péter, köszönjük, hogy vállaltátok ezt a megmérettetést, és segítettetek a beruházási, meg a felhős logikák mélyére ásni.

Köszönjük a lehetőséget.

Köszönjük a lehetőséget, és annyit a magam részéről, legalábbis zárszóként, hogy mi most ebben a stratégiai együttműködésben meghaladjuk a magyarországi kereteinket, és az a megállapodásunk az AWS az Amazon Web Servicesszel, hogy a balkáni régióra kezdünk el egy fejlesztő tevékenységet, ezt el is kezdtük egyébként ez év januárjában. Úgyhogy bizonyos idővel később vissza is jöhetünk hozzátok, és be is számoltunk arra, hogy amit mi Magyarországon megtanultunk, azt egy következő piacon, ahol egyébként még mindig mínuszban vannak hozzánk képest, ott ezeket a jobban értett dolgokat hogyan lehet könnyebben implementálni.

Ez is egy nagyon jó téma lenne, és egyébként felirattal a balkáni hallgatóknak is ajánlhatjuk Fradi podcast adásait.

Köszönjük a lehetőséget. Köszönjük, hogy itt voltatok.

A