Zarządzanie talentami w hybrydowym IT: Jak połączyć świat mainframe i cloud, by wygrać transformację?

W krajobrazie współczesnych korporacji technologicznych rozgrywa się dramat, który rzadko trafia na slajdy prezentacji dla zarządu. To cichy kryzys tożsamości, technologiczny odpowiednik zespołu rozdwojenia jaźni. Z jednej strony, firma inwestuje miliony w elastyczną, innowacyjną i skalowalną chmurę, kreując wizerunek cyfrowego lidera. Z drugiej, jej fundamentalne procesy biznesowe – te, które generują 99% przychodów i gwarantują ciągłość działania – wciąż opierają się na pancernych, niezawodnych, ale postrzeganych jako „przestarzałe” systemach mainframe. Te dwie osobowości technologiczne nie tylko ze sobą nie współpracują; one aktywnie ze sobą walczą o budżet, talenty i strategiczną przyszłość firmy.

Symptomy tego schorzenia są powszechnie znane każdemu menedżerowi IT. To niekończące się bitwy budżetowe, gdzie innowacyjne projekty chmurowe są przeciwstawiane „kosztom utrzymania” systemów core. To sprzeczne wskaźniki KPI, gdzie jeden zespół jest nagradzany za szybkość wdrożeń, a drugi za zerową liczbę incydentów produkcyjnych. To kultura wzajemnego obwiniania się, gdy ambitny projekt cyfrowy upada, bo utknął na etapie integracji z systemami, których nikt z „nowego” zespołu nie rozumie. To zjawisko tworzy nie tylko dług technologiczny, ale również znacznie groźniejszy dług kulturowy – rosnącą przepaść w komunikacji, zaufaniu i wspólnych celach. Celem tego artykułu jest postawienie diagnozy i zaproponowanie konkretnej, długofalowej terapii, która pozwoli wyleczyć organizację z tej kosztownej dolegliwości.

Dlaczego pogoń za talentem 'cloud-native’ może okazać się strategiczną pułapką?

W obliczu presji na innowacje, najprostszą i najbardziej kuszącą odpowiedzią wydaje się być agresywna rekrutacja. Liderzy IT, zachęcani przez zarządy, uruchamiają programy mające na celu pozyskanie „najlepszych talentów cloud-native” na rynku. W teorii ma to przyspieszyć transformację. W praktyce, jeśli jest to jedyna strategia, prowadzi firmę prosto w pułapkę, której zatrzaśnięcie staje się bolesne i kosztowne po około 18-24 miesiącach.

Jaki jest ukryty koszt ignorowania wiedzy domenowej?

Wiedza domenowa to ciche, niewidoczne aktywo, którego wartość objawia się dopiero w momencie jego utraty. To głębokie zrozumienie, „dlaczego” system działa w określony sposób. To świadomość, że konkretna, pozornie nielogiczna linijka kodu w module COBOL-owym sprzed 25 lat jest w rzeczywistości zabezpieczeniem wynikającym z historycznej ugody z regulatorem rynku. Nowo zatrudniony, genialny inżynier „cloud-native” może zoptymalizować ten kod, nieświadomie narażając firmę na wielomilionowe kary.

Ten ukryty koszt materializuje się w postaci:

• Wzrostu ryzyka operacyjnego: Zmiany wprowadzane bez pełnego zrozumienia kontekstu biznesowego prowadzą do subtelnych, trudnych do wykrycia błędów w kluczowych procesach, takich jak naliczanie odsetek, fakturowanie czy zarządzanie polisami.
• Wydłużenia czasu rozwiązywania problemów: Gdy pojawia się incydent na styku nowego i starego systemu, zespoły chmurowe nie mają narzędzi ani wiedzy, by zdiagnozować problem po stronie mainframe, a kurczące się zespoły mainframe są zarzucane zgłoszeniami, których nie rozumieją.
• Utraty zdolności do innowacji w rdzeniu biznesu: Z czasem firma boi się dotykać swoich systemów centralnych, ponieważ nikt już w pełni nie rozumie ich działania. Prowadzi to do paradoksu, w którym firma potrafi wdrożyć chatbota AI, ale nie jest w stanie zmodyfikować sposobu naliczania opłat za podstawowy produkt.

Czy jesteś gotów na 'ścianę integracyjną’ za 18 miesięcy?

Początkowa faza projektu opartego na zespole „cloud-only” jest zazwyczaj pełna sukcesów. Powstaje elegancki interfejs użytkownika, aplikacja działa błyskawicznie, a pierwsze wersje demonstracyjne robią wrażenie na zarządzie. Jednak każdy projekt cyfrowy w dojrzałej organizacji w pewnym momencie musi uderzyć w „ścianę integracyjną” – moment, w którym musi zacząć komunikować się z systemami transakcyjnymi i bazami danych na mainframe.

Bez odpowiednich talentów na pokładzie, to zderzenie jest katastrofalne. Zespoły chmurowe, przyzwyczajone do elastycznych API i rozproszonych baz danych, projektują integracje w sposób naiwny, generując tysiące nieefektywnych zapytań, które degradują wydajność systemu centralnego lub, co gorsza, prowadzą do jego niestabilności. Koszty naprawy takiej źle zaprojektowanej integracji, często wymagającej fundamentalnych zmian architektonicznych po obu stronach, mogą wielokrotnie przewyższyć początkowy budżet projektu.

---

Kim jest 'hybrydowy profesjonalista’ i dlaczego jest wart więcej niż jego certyfikaty?

Skoro ani ortodoksyjne trzymanie się starych kadr, ani rewolucja w stylu „cloud-only” nie działają, gdzie leży rozwiązanie? W świadomym tworzeniu i pielęgnowaniu nowego gatunku specjalisty IT: hybrydowego profesjonalisty. To nie jest mityczna postać, która w równym stopniu koduje w COBOL-u i projektuje klastry Kubernetes. To raczej dyplomata, tłumacz i inżynier mostów w jednej osobie. Jego kluczową kompetencją nie jest dogłębna znajomość każdej technologii, ale umiejętność płynnego poruszania się między nimi i rozumienia ich wzajemnych zależności.

Wartość takiego specjalisty daleko wykracza poza listę posiadanych certyfikatów AWS czy IBM. Certyfikat potwierdza znajomość narzędzia. Hybrydowy profesjonalista posiada mądrość – zdolność do wyboru odpowiedniego narzędzia do danego problemu biznesowego, niezależnie od tego, na której platformie ono rezyduje. Jest on bezcennym akceleratorem, który potrafi w 15 minut na spotkaniu rozwiązać problem, nad którym dwa odizolowane zespoły dyskutowałyby przez trzy tygodnie, wysyłając sobie formalne zgłoszenia.

Anatomia hybrydowego profesjonalisty

Kompetencja	Dlaczego jest kluczowa w środowisku hybrydowym?	Jak ją rozwijać w zespole?
Myślenie API-First	Umożliwia traktowanie logiki biznesowej mainframe nie jako monolitu, ale jako zbioru usług możliwych do wykorzystania przez aplikacje chmurowe. To fundament integracji.	Organizacja warsztatów z projektowania REST API dla zespołów mainframe. Wprowadzenie narzędzi (np. Zowe) ułatwiających tworzenie i zarządzanie usługami.
Głęboka Wiedza Domenowa	Zapewnia, że nowe rozwiązania chmurowe nie naruszają kluczowych reguł biznesowych i regulacyjnych, zaszytych głęboko w systemach core.	Aktywne włączanie weteranów mainframe w fazę projektowania nowych produktów. Stworzenie programów mentorskich, gdzie dzielą się wiedzą z młodszymi pracownikami.
Pragmatyzm Architektoniczny	Pozwala na podejmowanie decyzji opartych na faktach (gdzie dane mają być przetwarzane), a nie na technologicznej modzie. Zapobiega „przerzucaniu” wszystkiego do chmury bez uzasadnienia.	Tworzenie mieszanych komitetów architektonicznych (Architecture Review Boards). Promowanie kultury „Request for Comments” (RFC) dla kluczowych decyzji projektowych.
Kompetencje „Tłumacza”	Umiejętność wyjaśnienia ograniczeń transakcyjnych CICS programistom front-endowym i odwrotnie. Redukuje frustrację i błędy wynikające z braku zrozumienia.	Rotacja członków zespołu między projektami. Organizacja wspólnych sesji „show & tell”, gdzie zespoły prezentują sobie nawzajem swoje wyzwania i sukcesy.
Automatyzacja End-to-End	Zdolność do patrzenia na procesy CI/CD holistycznie, od kodu w repozytorium Git, przez pipeline Jenkinsa, aż po wdrożenie na środowisku mainframe i w chmurze.	Inwestycja w narzędzia do automatyzacji, które wspierają obie platformy (np. Ansible, Broadcom Endevor Bridge for Git). Budowanie tzw. „Value Stream Map” dla całego procesu.
Świadomość Kosztów (FinOps)	Rozumienie fundamentalnych różnic między modelem CapEx (mainframe) a OpEx (chmura). Pozwala projektować rozwiązania, które są optymalne nie tylko technicznie, ale i finansowo.	Włączenie analityków finansowych do zespołów projektowych. Szkolenia dla architektów z zasad FinOps i TCO (Total Cost of Ownership) dla różnych platform.

Jaką ścieżkę kariery zaproponować, aby wyhodować takie talenty wewnętrznie?

Hybrydowi profesjonaliści rzadko pojawiają się na rynku pracy jako gotowy produkt. Najskuteczniejszą strategią jest ich „wyhodowanie” wewnątrz organizacji. Wymaga to stworzenia świadomych ścieżek rozwoju, które promują wszechstronność:

• Programy Rotacyjne: Celowe przenoszenie utalentowanych inżynierów między zespołami mainframe i chmurowymi na okres 6-12 miesięcy.
• Stworzenie Roli „Architekta Integracji”: Formalne stanowisko, którego jedynym zadaniem jest projektowanie i nadzorowanie spójnych, wydajnych i bezpiecznych połączeń między platformami.
• System Premiowy: Wynagradzanie pracowników nie tylko za sukcesy w ich macierzystej dziedzinie, ale również za wkład w projekty międzysystemowe i zaangażowanie w transfer wiedzy.

---

Czy 'zespoły fuzyjne’ to tylko modne hasło, czy realna recepta na organizacyjne silosy?

Samo posiadanie utalentowanych jednostek to za mało, jeśli struktura organizacyjna zmusza je do pracy w izolacji. Odpowiedzią na ten problem jest model, który zyskuje coraz większą popularność w dojrzałych organizacjach IT: „zespoły fuzyjne” (fusion teams). To coś więcej niż modne hasło – to fundamentalna zmiana w sposobie organizacji pracy, polegająca na tworzeniu zespołów wokół produktu lub strumienia wartości biznesowej, a nie wokół technologii.

Jak w praktyce zbudować i uruchomić skuteczny zespół fuzyjny?

Stworzenie takiego zespołu to proces, który wymaga starannego przygotowania:

1. Wybór Pilotażu: Zacznij od jednego, strategicznie ważnego, ale niezbyt skomplikowanego projektu, np. „stworzenie nowej aplikacji mobilnej do obsługi roszczeń”.
2. Zdefiniowanie Celu Biznesowego: Cel musi być jasny i mierzalny dla wszystkich, np. „skrócenie czasu obsługi roszczenia z 5 dni do 24 godzin”.
3. Dobór Składu: Zespół musi od pierwszego dnia zawierać wszystkich niezbędnych specjalistów: dewelopera mainframe znającego system polis, inżyniera chmury, który zbuduje front-end, eksperta ds. bezpieczeństwa, analityka danych i, co kluczowe, w pełni umocowanego Product Ownera z linii biznesowej.
4. Ustanowienie Wspólnych Rytuałów: Zespół musi pracować razem w ramach jednego sprintu, mieć wspólne planowanie, codzienne spotkania (stand-upy) i retrospektywy. To buduje poczucie jedności i wspólnej odpowiedzialności.

Jakie są najczęstsze pułapki i jak ich unikać?

Implementacja zespołów fuzyjnych napotyka na typowe przeszkody. Świadomość ich istnienia pozwala ich uniknąć:

• Problem „Mini-Wodospadu”: Zespół formalnie jest jeden, ale w praktyce praca jest nadal sekwencyjna – zespół mainframe najpierw coś przygotowuje, a dopiero potem przekazuje do zespołu chmurowego. Rozwiązanie: Planowanie pracy w oparciu o „pionowe plastry” funkcjonalności, które od razu wymagają pracy na obu platformach.
• Brak Umocowania Product Ownera: Przedstawiciel biznesu jest tylko nominalnym członkiem zespołu i każdą decyzję musi konsultować z hierarchiczną strukturą. Rozwiązanie: Zapewnienie, że Product Owner ma realną władzę decyzyjną w zakresie priorytetów i funkcjonalności produktu.
• Opór Średniego Szczebla Menedżerskiego: Menedżerowie tradycyjnych silosów mogą postrzegać zespoły fuzyjne jako zagrożenie dla ich autorytetu. Rozwiązanie: Włączenie tych menedżerów w proces jako mentorów i coachów, odpowiedzialnych za rozwój kompetencji swoich ludzi, a nie za codzienne zarządzanie zadaniami.

---

Co zrobić, gdy bezcenna wiedza o systemach core przygotowuje się do odejścia na emeryturę?

Problem demograficzny w zespołach mainframe jest faktem. Wielu kluczowych ekspertów, którzy budowali i rozwijali systemy centralne przez ostatnie 30-40 lat, zbliża się do wieku emerytalnego. Podejście „jakoś to będzie” lub wiara, że wszystko da się zapisać w dokumentacji, to prosta droga do katastrofy operacyjnej.

Dlaczego tradycyjna dokumentacja to strategia skazana na porażkę?

Wielu liderów wierzy, że rozwiązaniem jest zmuszenie odchodzących ekspertów do „spisania wszystkiego, co wiedzą”. To iluzja. Po pierwsze, ogromna część wiedzy eksperckiej to tzw. wiedza ukryta (tacit knowledge) – intuicja, doświadczenie i kontekst, których nie da się w pełni zwerbalizować. Po drugie, w dynamicznym środowisku IT dokumentacja staje się nieaktualna w momencie jej zapisania. Nikt nie ma czasu na jej ciągłą aktualizację, a nowi pracownicy szybko uczą się ją ignorować, bo jest niewiarygodna.

Jakie nowoczesne metody transferu wiedzy działają w praktyce?

Efektywny transfer wiedzy musi być procesem aktywnym, społecznym i wbudowanym w codzienną pracę. Zamiast tworzyć cmentarzyska dokumentów, należy inwestować w:

• Pair Programming i Shadowing: Młodszy inżynier przez kilka tygodni pracuje „ramię w ramię” z weteranem nad realnymi zadaniami, obserwując nie tylko „co” robi, ale „jak” myśli i podchodzi do rozwiązywania problemów.
• Mentoring Odwrócony: To dwukierunkowa ulica. Młodszy pracownik uczy doświadczonego kolegę nowych narzędzi (np. jak efektywnie używać VS Code do pracy z COBOL-em), a w zamian zyskuje bezcenną wiedzę o logice biznesowej i architekturze systemu.
• Projekty Modernizacyjne jako Kuźnie Talentów: Najlepszym sposobem na naukę jest praktyka. Zamiast abstrakcyjnych szkoleń, należy tworzyć mieszane zespoły, których celem jest np. refaktoryzacja starego modułu lub wystawienie jego funkcjonalności jako nowoczesnego API. To najbardziej efektywna forma transferu wiedzy.

---

Czy GenAI to gwóźdź do trumny dla ekspertów mainframe, czy potężny sojusznik?

Pojawienie się zaawansowanych modeli językowych, zdolnych do analizy i tłumaczenia kodu w językach takich jak COBOL, wywołało falę spekulacji. Czy to oznacza, że rola ludzkich ekspertów dobiega końca? Nasze doświadczenie i analiza rynku wskazują na coś wręcz przeciwnego. GenAI nie jest zagrożeniem dla ekspertów, ale staje się ich najpotężniejszym sojusznikiem, zwielokrotniającym ich produktywność i wartość dla organizacji.

Jakie szanse GenAI stwarza dla modernizacji i onboardingu?

Narzędzia takie jak IBM watsonx Code Assistant for Z działają jak potężny akcelerator, demokratyzując dostęp do wiedzy o systemach core:

• Dla Modernizacji: AI może w kilka minut przeanalizować miliony linii kodu, zidentyfikować zależności, zaproponować podział na mikroserwisy czy automatycznie przetłumaczyć fragmenty kodu na Javę. To zadania, które człowiekowi zajęłyby miesiące.
• Dla Onboardingu: Nowy pracownik, zamiast spędzać pół roku na próbach zrozumienia skomplikowanej logiki, może zadać AI pytanie w naturalnym języku: „Wyjaśnij mi krok po kroku, jak działa proces naliczania tej opłaty” i otrzymać natychmiastową, zrozumiałą odpowiedź.
• Dla Testowania: GenAI może automatycznie generować dane testowe, a nawet całe scenariusze testowe na podstawie analizy kodu, co radykalnie skraca czas i podnosi jakość procesu zapewnienia jakości.

Jakie ryzyka należy kontrolować przy wdrażaniu AI w środowiskach krytycznych?

Wykorzystanie AI w kontekście systemów centralnych wymaga jednak dużej rozwagi. Należy zarządzać kluczowymi ryzykami, takimi jak:

• Poufność Danych i Kodu: Czy nasz kod źródłowy, będący własnością intelektualną firmy, nie jest wysyłany do zewnętrznych modeli AI w sposób niekontrolowany?
• Dokładność i „Halucynacje”: Modele AI mogą się mylić. Każda propozycja zmiany kodu czy wyjaśnienie logiki wygenerowane przez AI musi być zweryfikowane przez ludzkiego eksperta („expert-in-the-loop”).
• Nadmierne Zaufanie: Istnieje ryzyko, że zespoły zaczną bezkrytycznie ufać sugestiom AI, co może prowadzić do wprowadzania subtelnych, ale groźnych błędów.

---

Czy jesteś gotów budować mosty, a nie mury, w swoim dziale IT?

Podsumowując, największym wyzwaniem transformacji cyfrowej nie jest technologia. Jest nim przezwyciężenie wewnętrznych podziałów, silosów kompetencyjnych i kulturowych wojen, które paraliżują potencjał organizacji. Sukces w erze hybrydowej nie polega na wyborze między mainframe a chmurą, ale na mistrzowskim połączeniu stabilności i niezawodności jednego świata z dynamiką i innowacyjnością drugiego. Kluczem do tego połączenia są ludzie – świadomie kształtowani hybrydowi profesjonaliści, pracujący w zintegrowanych zespołach fuzyjnych.

W ARDURA Consulting specjalizujemy się w diagnozowaniu i leczeniu „technologicznego rozdwojenia jaźni”. Rozumiemy, że budowanie mostów między platformami musi zacząć się od budowania mostów między ludźmi. Nasze usługi, od strategicznego doradztwa w zakresie transformacji organizacyjnej, przez elastyczny Staff Augmentation dostarczający brakujące hybrydowe kompetencje, aż po wdrażanie kompletnych, gotowych do działania zespołów fuzyjnych, są zaprojektowane, aby pomóc Twojej firmie przekształcić wewnętrzne tarcia w siłę napędową realnej innowacji.