Jak budować własne kadry chmurowe?

Przeczytasz w 10 min

Czy programy transformacji chmurowej a wraz z nimi transformacja cyfrowa są zagrożone przez deficyt kompetencji? W jaki sposób niedostatek specjalistów chmurowych wpływa na jakość i organizację tych programów?

Krzysztof Stumpf, FOTO: archiwum redakcji

Problem deficytu kompetencji chmurowych pragnę omówić to na przykładzie kompetencji odpowiednich dla dużych przedsiębiorstw. Taki chmurowy poziom enterprise bardzo wyraźnie różni się np. od zestawu kompetencji dla małych firm, gdzie polega na umiejętności zbudowania środowiska chmurowego dla aplikacji. Dla nas to poziom junior/mid, przedsionek właściwego rozwoju. Swoje obserwacje odnoszę też przede wszystkim do sektora finansowego a opieram się na wieloletnim doświadczeniu budowy zespołów DevOps i chmurowych w Raiffeisen Solutions czy obecnie w MIT Group Delivery Center Poland dla Raiffeisen Bank International.

Pęd migracji do rozwiązań chmury obliczeniowej oraz testowania jej możliwości jest obecnie rzeczywiście bardzo duży. Niekoniecznie dotyczy to systemów największych, krytycznych, zdecydowanie najczęściej chodzi o uruchamianie w chmurze pewnych środowisk. Przy tym masowym przyswajaniu modelu chmurowego niedostatek kompetencji chmurowych zaczyna być wyraźnie dostrzegalny. Dodatkowo wzmaga go obecnie kilka zjawisk.

Chmurowe plemiona

Jednym z nich jest obecne wyrównanie sił czołowych dostawców chmury publicznej. Wcześniej mieliśmy do czynienia z sytuacją, kiedy niektórzy dostawcy chmury mocno się specjalizowali w Open Source. Z perspektywy instytucji finansowych, których doświadczenia są mi najbliższe, było to zdecydowanym atutem. Open Source oznacza bowiem brak ryzyka vendor lock – kluczowego parametru przy wyborach architektonicznych w sektorze finansowym. Dlatego dostawca, który wchodził mocno w Open Source, w środowisku finansowym był zdecydowanie faworyzowany. Takim przykładem historycznym jest Amazon. AWS dostarczał najwięcej obudowanych rozwiązań Open Source. Pamiętam, że alternatywa – samodzielne dostarczenie wysokiej dostępności  np. dla postgresowych baz danych – była dużym wyzwaniem. Kiedy Amazon zaczął to robić, sytuacja zmieniła się diametralnie.

Innym założeniem dotyczącym technologii w finansach jest unikanie konieczności samodzielnego developmentu. Wiele europejskich instytucji finansowych, w szczególności z rynków niemieckojęzycznych, postawiło w efekcie na zestaw AWS plus Open Source. W oparciu o niego zaczęło też budować odpowiednie kompetencje. Popyt na chmurowe kompetencje w naszej branży dotyczył więc przede wszystkim jednego z ekosystemów chmurowych. Obecnie jednak pozostałe czołowe chmurowe ekosystemy publiczne także poszły tą drogą. Mamy więc trzech głównych konkurentów i sytuację, kiedy programiści zaczynają dokonywać wyborów i specjalizować się. Nie dość zatem, że mamy deficyt kompetencji, to jeszcze trzy drogi rozwoju i specjalizacji. Wraz z doświadczeniem, wraz z indywidualizacją rozwiązań w poszczególnych ekosystemach, wraz z rosnącym popytem i stawkami rodzi to coraz trudniejszą sytuację.

Skłonność do chmurowych konwersji

Już dzisiaj, kiedy poszukujemy np. specjalisty w Azure, chętnie przyjmiemy osobę, która „przekonwertuje się” np. z ekosystemu AWS. Jest to możliwe i nawet całkiem popularne, ale na poziomie junior, ewentualnie mid. Specjaliści z wyższym doświadczeniem nie są tym zainteresowani. Łatwo ich zrozumieć: za dużo zainwestowali w swoją pozycję, chcą więc rozwijać się w tej części rynku, w której dużo znaczą i mogą swoje umiejętności dobrze sprzedać.

Podczas jednego z wiosennych spotkań CXO HUB Krzysztof Wykręt, CIO w Gulermak, mówił, że dąży do tego, aby specjaliści chmurowi w jego dziale IT byli „wieloplatformowi” i unikali specjalizacji. Mówił o mechanizmie dojrzewania takich specjalistów, w którym wykształca się poczucie wartości w oparciu o uniwersalność kompetencji i doświadczenia. I o tym, że później nie chcą oni już wracać na ścieżkę specjalizacji. Uważam, że to ciekawe, duże osiągnięcie, ale zarazem z mojego doświadczenia wygląda to inaczej. Obserwuję, że bardziej od nastawienia do bycia „człowiekiem od chmury” dominuje dążenie do bycia np. „specjalistą Azure’owym”.

Na wspomnianym spotkaniu miała też miejsce dyskusja o modelu migracji chmurowej w kontekście kompetencji. A w zasadzie – o tym, jak model kompetencji chmurowych zależny jest od modelu migracji. Spójrzmy na to przez pryzmat deficytu kompetencji chmurowych. Przypomnę jeszcze, że Krzysztof Wykręt mówił o modelu (a potem także opisał to w artykule), w którym firma buduje zestaw kompetencji zaczynając od architektów wyższego poziomu. Oni będą mieć strategiczną i ogólną znajomość rynku chmurowego oraz poszczególnych rozwiązań. W oparciu o tę wiedzę i znajomość kontekstu firmy dokonują wyborów a następnie będą kontraktować do szczegółowych zagadnień specjalistów chmurowych.

Praktycy i entuzjaści

My podeszliśmy do budowy modelu kompetencji chmurowych inaczej. Decydując się na migrację postanowiliśmy raczej pozyskać ludzi, którzy są bardziej specjalizowani i doświadczeni w praktycznych migracjach, i to nie do jednej, ale najlepiej różnych chmur, w różnych projektach.

Dlaczego? Ponieważ jedna chmura zaczyna być ograniczeniem. To podobna przesłanka, jaką kieruje się w swoim podejściu do zrealizowanych migracji chmurowych Krzysztof Wykręt, ale prowadzi nas do innego wniosku. Poszukaliśmy takich specjalistów, którzy różnice pomiędzy ekosystemami chmurowymi znają dzięki projektom migracyjnym, przeszli to. Tymczasem duża część specjalistów na rynku, to w rzeczywistości dobrze wyedukowani entuzjaści, którzy jednak nigdy nie byli w projekcie. Mogą wspierać wybór, bo na wyrywki znają dostępne w danej chmurze opcje, ale dla nas to za mało.

W naszych rekrutacjach poszukujemy kandydatów, którzy mieliby w doświadczeniu migrację do jednej albo dwóch chmur. Takich osób jest oczywiście na rynku niewiele i w większości są świetnie opłacane w firmach konsultingowych. Tam pracują przede wszystkim w projektach dla zagranicznych klientów. To swoisty drenaż mózgów i zarazem zaklęty krąg. Ponieważ nie ma doświadczonych specjalistów, na polskim rynku nie widzimy zaawansowanych migracji do chmur. Nie przybędzie ich, bo najlepsi będą wspierać transformacje np. na rynku skandynawskim, to obecnie gorący kierunek. Nie mamy więc nadal przykładu projektu, aby ktoś przeniósł do chmury poważny system z bankowości albo bankowość elektroniczną. Do chmury przenosi się office, stronę internetową – to projekty, które można nazwać bezpiecznymi. Brakuje mocnych wdrożeń, przynajmniej w naszej rekrutacji takie osoby się nie pojawiają.

Kompozycja kompetencyjna

Na czym więc opieramy nadzieje na powodzenie naszej strategii w zakresie budowy kompetencji?

W ciągu dwóch ostatnich lat budowaliśmy kompetencje posługując się kilkoma metodami. Po pierwsze – jak w rasowym klubie piłkarskim, stawiamy na wychowanków. Na początek były to dwie osoby z Raiffeisen Solutions, osoby przyzwyczajone do DevOps, ale nie znające chmury obliczeniowej. Dla nich start był trudny, ale zapewniliśmy im wsparcie osoby z firmy zewnętrznej. Przy niej nauczyli się na tyle, że mogli przejąć obowiązki, działać na wysokim poziomie a jednocześnie wspierać rozwój kolejnych osób. Osoby z doświadczeniem DevOps są dobrym „narybkiem” do chmurowej akademii.

Lepiej też widzę przyszłość współpracy z wewnętrznie wyszkolonymi specjalistami chmurowymi, ponieważ w mniejszym stopniu będą dążyć do zmiennych wyzwań, coraz to nowych projektów. Tak jest z reguły w przypadku z osób przychodzących z firm konsultingowych albo innych branży. Oczywiście uzyskanie chmurowych szlifów dodaje każdemu skrzydeł, sytuacja na rynku pracy takiej osoby jest znakomita. Ale „wychowankowie” doceniają pracę w sektorze finansowym. Takie też osoby docelowo będą obsługiwać nowe środowisko post-transformacyjne.

O ile do migracji kompetencje pozyskujemy z zewnątrz, to liczymy się z tym, że po projekcie takie osoby zmieniają miejsce pracy. Do funkcjonowania w nowym ekosystemie i obejmowania tam ról w większym stopniu predestynowani są więc wychowankowie. Ich podejście zmienia się oczywiście i nie chcemy walczyć z tym, że chcą w oparciu o swoje kompetencje mieć wpływ, budować. To łączy zresztą specjalistów od chmury, której wdrożenie stwarza im możliwości rozwinięcia skrzydeł. Patrzymy na to z nadzieją a nie obawą, bo także wierzymy w potencjał chmury w kontekście efektywności IT, możliwości biznesowych. Ich pełnia ujawni się po migracji.

Między doświadczeniem a zapałem

W chwili obecnej udało nam się uzyskać kompozycję zespołu chmurowego oscylującą pomiędzy 30-50% ludzi z mocnymi, posiadanymi już kompetencjami chmurowymi, którzy przeszli projekty chmurowe i 30-50% tych, którzy się na te kompetencje przestawiają właśnie. Optimum to stabilne 50-50, z tendencją wzrostową w grupie ludzi z doświadczeniem chmurowym. W dzisiejszych realiach bardzo trudno osiągalny, o ile w ogóle model. Na rynku dominuje raczej układ 70 i więcej do 30 i mniej, ze wskazaniem na młodszych specjalistów bez większego doświadczenia i entuzjastów.

Taki model, dążący do szybkiej maksymalizacji udziału doświadczonych specjalistów pozwala płynnie, skutecznie absorbować szybko rozwijające się chmury z ich funkcjonalnościami typu serverless, gotowe mechanizmy do security check, gotowe komponenty, które wręcz można nazwać aplikacjami. Krzywa uczenia jest bardzo stroma a samo poznawanie chmury przychodzi łatwiej tym, którzy opanowali wcześniej podstawy, znają mechanizmy. Przenosząc to na skalę firmy oznacza zarazem zdolność do tego, aby samodzielnie wieść prym w rozwiązaniach a nie zrzekać się kompetencji na rzecz usługodawcy. To jest cel naszego podejścia do budowy modelu kompetencji.

Alternatywa jest ryzykowna

Alternatywna – z perspektywy kompetencyjnej – wizja migracji a następnie funkcjonowania w paradygmacie chmurowym polega na oparciu się na kompetencjach zewnętrznych. Duże firmy konsultingowe mocno wchodzą w budowę kompetencji chmurowych, ponieważ stoją za tym duże pieniądze. Usługi chmurowe są drogie i pożądane. To jednak ryzykowna usługa z punkt widzenia organizacji. Sam w sobie projekt jest ryzykowny, kiedy np. migrujemy bankowość elektroniczną do chmury, to bardzo ryzykowne. Korzyści są oczywiste, ale odpowiedzialność olbrzymia. To także popycha firmy do poszukiwania wsparcia zewnętrznego. Firmy pytają same siebie, czy będą w stanie, nawet posiadając własnych architektów to ryzyko, odpowiedzialność udźwignąć. Kalkulacje często prowadzą je do wniosków, że jak w przypadku innych technologicznych przełomów w IT wymagających dużych decyzji – lepiej wziąć dużą firmę, która bierze na siebie zasadniczą część odpowiedzialności.

To jednak tylko chwilowa ulga. Pozostaje bowiem otwarta kwestia wykonawców, którzy zrealizują wizję nakreśloną dzięki usłudze konsultingowej.

Walka o ludzi

I wtedy wracamy ponownie do zagadnienia zasobów. Nieuchronnie będą one rozdzierane przez obie strony. Konsekwentne oparcie wykonawstwa i utrzymania na zewnętrznym dostawcy byłoby bardzo drogie. Czy tak drogie, że pochłonęłoby korzyści finansowe? Być może. Takie jest przynajmniej poczucie i dlatego firmy starają się te kompetencje, aby zespoły budować także wewnątrz. W praktyce, wykonaniem i późniejszym utrzymaniem zajmować będą się zespoły mieszane.

Jeśli chcemy nie być zależni w 100% od firmy zewnętrznej, to zaczyna się walka o ludzi. Dziś ona już na rynku trwa. Kiedy przekazaliśmy jednemu z headhunterów profil poszukiwanego pracownika, okazało się, że dokładnie takiego samego poszukuje firma, który nas w pewnym obszarze obsługuje. Konkurujemy więc o tych samych ludzi. Albo kupimy usługi albo zatrudnimy ludzi. Jeśli uda nam się zatrudnić, to nadal pozostaje ryzyko, czy ich utrzymamy. Tym niemniej warto o to walczyć i takie jest w mojej ocenie powszechne podejścia na rynku. Świat chmurowy to inny świat niż wtedy, kiedy firmy IT skupiały kompetencje a firmy finansowe czy innej branży po prostu kupowały te zasoby.

W chmurowym świecie przyszłości

W kontekście kompetencji należy też pytać, czego po migracji chmurowej trzeba wymagać od organizacji. Jakie powinna mieć zasoby do codziennego funkcjonowania w nowy paradygmacie chmurowym. Czy jego elementem będzie permanentny deficyt i rotacje ludzi kompetentnych w obszarach chmurowych? Jak w takich warunkach realizować korzyści ze zmiany chmurowej?

Uważam, że za 3-4 lata pod względem dostępu do kompetencji na rynku powinno być łatwiej. Doświadczenie, choć dzisiaj, jak uważam w Polsce znaczących projektów chmurowych nie przybywa, musi w końcu się zbudować. W Polsce i w regionie chmurowe migracje będą łatwiejsze, bo przybędzie kompetencji. Dzisiaj jest etap pionierski rynku i wszyscy aktywni w tych zagadnieniach mają trudniej. Brakuje choćby nauki na cudzych błędach. Ale też pierwsi zbierają profity.

Pionierstwo jest też zachętą, najsilniejszą na rynku pracy dla osób będących pomiędzy poziomem mid a junior. Do nowego modelu przyciągają w moim przekonaniu poczucie władności, sprawczości, jakie zyskuje specjalista w organizacji właściwie wykorzystującej chmurę. Oby tylko uwiedzeni wizją chmury jej adepci nie zapominali, że rewers tej monety to ogromna odpowiedzialność.

Co jest za tym wzgórzem?

W tym momencie przełomowym, definiowania na przyszłość rzeczy, jeśli ustali się opisywane powyżej optimum zestawu kompetencji, da się więcej uzyskać z chmury. Taka przyszłość niesie szereg potencjalnych korzyści przekształcenia modelu procesowego, biznesowego. Brzmi to może nadmiernie optymistycznie w sytuacji, gdy opisane powyżej zjawiska rynku prac przywodzą na myśl raczej walkę o przetrwanie po wstawieniu stopy w drzwi. Prawdziwe korzyści czekają nas jednak wtedy, gdy ta migracja już się dokończy. Najciekawsze przed nami.

Sięgając wzrokiem w przyszłość, warto zastanowić się także nad ewolucją ról w ekosystemie chmurowym (de facto oczywiście hybrydowym, ale generalnie zdefiniowanym przez opcję chmurową, jako opcję pierwszego wyboru, punkt odniesienia). Jakie nowe kompetencje będą potrzebne? Im wcześniej zaczniemy je projektować, formować, budować – tym szybciej pojawią się korzyści.

My zaczynaliśmy gromadzenie kompetencji od DevOps’ów i developerów, którzy nie byli cloud native.  Nastąpił potem opisany wyżej, trwający do dziś proces formowania zespołu, dokształcania wychowanków i łączenia z doświadczonymi osobami z zewnątrz. W tym czasie, ze względu na wymogi korporacyjnego bezpieczeństwa, potrzebna była nam osoba do promocji tego typu bezpieczeństwa w warunkach chmurowych. To była zmiana, ponieważ z reguły bezpieczeństwo nastawia się raczej na audytowanie rozwiązań. A tu, w sytuacji, gdy adaptujemy się do zmiennego, elastycznego środowiska potrzebowaliśmy znaleźć osobę do roli architekta bezpieczeństwa.  Po uruchomieniu rozwiązań i systemów w chmurze, jasno widzę, że chmura wymaga monitorowania kosztów.

Chmura jako koszt, chmura jako przychód

W najbliższym więc czasie pojawi się rola cloud cost menedżera. Kiedy chmura zaczyna funkcjonować, zaczyna się też od razu zmieniać. Ma to swój wymiar finansowy, nad którym trzeba czuwać i który trzeba modelować na bieżąco. Celem jest stała optymalizacja kosztów w kontekście zmieniającego się sposobu wykorzystania chmury. Mają do tego oczywiście narzędzia dostawcy chmury, ale potrzebna jest osoba do wirtuozowskiego posługiwania się nimi, która w oparciu o nie potrafi ze środowiska wyciągnąć maksimum. Znaczenie takiej roli stanie się w pewnym momencie kluczowe, po swoistym okresie ochronnym dla chmury.

Oczywiście już na etapie migracji do chmury warto wiedzieć, co i ile kosztuje, mieć świadomość, że jakaś przyjazna usługa, łudząco podobna do znajomej usługi realizowanej na własnej infrastrukturze może w modelu chmurowym być bardzo droga. Choćby logowanie i monitoring w aplikacji. W środowisku on premise to tylko jakieś dodatkowe pliki czy zapisy w bazie danych. W chmurze to po prostu koszt, który się skaluje. Trzeba jednak uważać, bo bez kontroli może urosnąć niebotycznie. Może też trzeba wówczas pomyśleć, czym tę drogą usługę chmurową zastąpić, być może zbudować coś samodzielnie i posadzić w chmurze. Powinien to rekomendować architekt z kompetencjami cost advisora. To tym bardziej ważne, że motyw porównywania kosztu chmury i własnej infrastruktury będzie stałym obszarem dyskusji w firmie. Na razie uważam, że przyszłość architektury jest hybrydowa, pewne środowiska pozostaną nieuchronnie w starym modelu.

Krok dalej może iść koncepcja roli kogoś, kto oceniałby chmurę jak revenue oficer. Może być to ciekawa koncepcja budowania pozytywnego przekazu na temat bilansu transformacji chmurowej. Ale także ten wkład analityczny mógłby stanowić element np. decyzji o zmianie dostawcy chmurowego, środowiska czy modelu.

Jak liczyć to revenue? Dzisiaj już dość często produktem biznesowym jest np. API, użycie go  generuje  przychód, który nie jest już jednoznacznie przypisany tylko do biznesu. Chmura, która skaluje się i gwarantuje SLA bez względu na ilość wywołań API – także byłaby kreatorem przychodu a nie tylko kosztu

Kierunki przepływu kompetencji w przyszłości

Jeszcze jeden wymiar przyszłości w świecie chmurowym nawiązuje do podziałów i specjalizacji. Zarysowałem kilka wymiarów, osi, które dzielą klasy i kategorie kompetencji. Jednym z kluczowych problemów jest możliwość przepływu kompetencji pomiędzy tymi wymiarami, kategoriami. Jestem szczególnie ciekaw rozwoju sytuacji na linii enterprise – firmy Digital (branży, która jest digital native, model chmurowy, nie tylko od strony technologicznej, ma niejako we krwi). Na początku zastrzegłem, że na obecny moment trzeba mocno odróżnić sytuację i oczekiwania wobec specjalisty chmurowego enterprise od pozostałych.

W przypadku tych dwóch sektorów, w przyszłości powinno dojść jednak do pewnej konwergencji. Budujące swój cyfrowy biznes firmy digitalowe adaptują, w dużej mierze dobrowolnie, szereg standardów, rekomendacji czy regulacji, którym podlegają branże bardziej tradycyjne, jak finanse. W konsekwencji, zmienia się ich doświadczenie chmurowe. Tacy specjaliści lepiej będą mogli zrozumieć ramy, w jakich musi funkcjonować chmura w takich instytucjach jak nasza. A zarazem atrakcyjna może stać się wizja pracy w najstabilniejszym z perspektywy pracowniczej otoczeniu.

Na koniec – znowu proponuję spojrzeć bardziej z przyszłej perspektywy hybrydowej, niż dzisiejszego etapu pionierskiego podbijania chmury. Ponownie odwołam się do jednego z ostatnich spotkań CXO HUB, gdzie rzuciłem tezę, że specjaliści od infrastruktury powinni się starać przekwalifikować na chmurę. Ale może było to krótkowzroczne. W dłuższej perspektywie, być może będą takie miejsca, fragmenty rynku, gdzie środowisko infrastrukturalne będzie mocno się trzymać. I specjalista od serwera czy starodawnej macierzy będzie niszowym, ale i dobrze opłacanym specjalistą.

Póki co łatwiej do tego środowiska pozyskać specjalistę niż do chmurowego. Być może za 5 lat ta sytuacja na rynku ulegnie zmianie, odwróceniu. Byłoby to prawdziwe zwieńczenie dzisiejszej epoki gwałtownej migracji rynku do chmury, epoki deficytu kompetencji chmurowych i pewnego rodzaju walki firm o podmiotowość w nowym świecie definiowanym przez paradygmat chmury obliczeniowej.

 

Krzysztof Stumpf
Współpraca: Szymon Augustyniak

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Przeczytaj też:

Przeczytasz w 7 min
0

Credit-Agricole Bank Polska: przyspieszyliśmy digitalizację i projekty omnichannel

Przeczytasz w 7 min Z Dorotą Poniatowską Mańczak, CIO banku Credit-Agricole Bank Polska rozmawiamy o sposobach na przejście przez pandemię; przygotowaniu się na nową normalność; ciągłym wzbogacaniu oferty; innowacjach potrzebnych do budowy nowej, lepiej przystosowanej oferty; pracy zdalnej; zadbaniu o miejsca pracy, zdrowie i motywacje pracowników; odpowiedzialności społecznej w kontekście tarczy antykryzysowej; a także historii banku, który bardzo szeroko analizuje dzisiejszą, nietypową, trudną sytuację i wielu obszarach szuka sposobów na sprostanie obecnym wyzwaniom.

Przeczytasz w 5 min
0

Nasz sukces w realizacji procesu transformacji cyfrowej!

Przeczytasz w 5 min Transformacja cyfrowa podstawą optymalizacji procesów biznesowych. To fakt, który dociera do każdej gałęzi gospodarki, choć z różną szybkością. Na pewno nie jest kojarzony z deweloperami. Niedawno do takiego procesu zabrało się Echo Investment. Pierwsze owoce przyszły już po kilku miesiącach.

Przeczytasz w 7 min
0

PKO BP: staniemy się bankiem funkcjonującym w chmurze hybrydowej

Przeczytasz w 7 min Z Adamem Marciniakiem, wiceprezesem zarządu PKO BP nadzorującym Obszar Informatyki rozmawiamy o planach banku dotyczących migracji do usług cloud computing; trzyletniej strategii Road to cloud – RC2; harmonogramie migracji poszczególnych systemów IT; założeniach, które stały za decyzjami o ich przeniesieniu poszczególnych rozwiązań na platformy cloud computing; a także początkowych kosztach, które PKO BP musi ponieść w związku z planami migracji oraz roli narzędzi chmurowych w realizacji strategii biznesowej.

Dziś tam gdzie jest cyfrowe terra incognita są członkowie CXOHUB, którzy są pionierami cyfryzacji, transformacji do nowej gospodarki (new normal).

Zapraszam do udziału,
Szymon Augustyniak

Misja, wizja i wartości CXO HUB

  • CXO HUB powstało, aby zgromadzić najlepszych menedżerów i ekspertów w zakresie szeroko pojętej cyfrowej zmiany.
  • Misją społeczności CXO HUB jest promowanie wiedzy oraz sylwetek jej członków na arenie polskiej oraz międzynarodowej.
  • Społeczność CXO HUB stanie się widoczną, słyszalną siłą w dyskursie o przyszłości i standardach w zakresie zastosowań nowych technologii.

Zdobywaj kontakty, buduj relacje

CXO HUB:

  • wspiera budowę wizerunku merytorycznej i doświadczonej firmy
  • zapewnia oryginalne, inteligentne formaty budowania relacji
  • tworzy zaangażowaną i aktywną społeczność
  • buduje i dystrybuuje unikalny content dla publiczności
  • zapewnia przestrzeń do budowy kontaktu, relacji i wpływu

Dołącz do nas!

Formuła CXO HUB jest etyczna w wymiarze moralnym, obiektywna w wymiarze poznawczym oraz neutralna w wymiarze relacji z rynkiem.

Dołącz do naszej społeczności w serwisie LinkedIn

 

Dla kogo jest CXO HUB:

  • CIO polskich przedsiębiorstw
  • szefowie IT
  • liderzy największych firm w Polsce
  • decydenci zakupu rozwiązań informatycznych