Chmurowa transformacja kompetencji

Cykl transformacji chmurowej kompetencji to 3 lata. Po tym czasie firma nabiera dojrzałości pozwalającej świadomie wybierać i zmieniać środowisko chmurowe dla swojego biznesu. Wraz z migracją do chmury obliczeniowej części – albo większości rozwiązań IT – następuje potrzeba dostosowania do pracy z nowym środowiskiem IT. Dla pracowników IT jest to z reguły początek dużej przygody zawodowej, znacznego przyśpieszenia rozwoju. W jaki sposób zaprogramować chmurową transformację kompetencji?

Posiadanie już na początku transformacji kompetencji chmurowych jest bardzo ważne. Większość działań, które podejmuje się wówczas ma znaczenie i wpływ na dalszą możliwość rozwoju systemów, usług, konfiguracje. Robienie tego po omacku, bez wiedzy, może powodować przyszłe problemy dla wszystkich, w tym użytkowników. Nigdy nie rozpocząłbym transformacji chmurowej po omacku na żywym produkcyjnym środowisku biznesowym. Chyba, że testujemy, próbujemy jakieś środowisko bez konsekwencji. Ale to rzadki przypadek, ponieważ najczęściej jest to pilna potrzeba biznesowa, która nie może czekać.

Zacznijmy od architektury

Czego zatem potrzeba w firmie, aby pierwsze kroki w chmurze nie były stawiane po omacku? Jak pozyskać owe kompetencje “na start”? Jakie ta faza ma znaczenie dla przebiegu całej transformacji chmurowej? Minimum niezbędne na start, to kompetencje architekta usług chmurowych. Powinna być to osoba z szeroką wiedzą informatyczną. Tylko wówczas będzie w stanie rozmawiać z biznesem, aby zorientować się w ich potrzebach, aby ocenić możliwości np. z dostawcami, aby ostatecznie podjąć decyzję o kierunku działania. Zdecydowanie odradzam, aby na początku posiłkować się kimś o bardzo specjalizowanym, wycinkowym obrazie sytuacji, np. o profilu eksperta od zagadnień DevOps w Azure. Na start potrzebny jest szeroki wachlarz wiedzy – abstrahując od wybranego dostawcy.

Oczywiście na rynku trudno o taką osobę. Dlatego niekiedy taki architekt chmurowy musi być wynajętym specjalistą, kontraktorem spoza firmy. Uważam, że nie jest to zagrożeniem, IT nie różni się w firmach co do zasady. Skoro więc trudno pozyskać osobę o szerokich horyzontach na stałe, można pokusić się o pozyskanie „najemnika” do współpracy w fazie wstępnej. Lepiej jest szybciej wystartować niż strawić zbyt wiele czasu na poszukiwaniach. Jednocześnie, równolegle trzeba znaleźć pracownika wewnątrz firmy, który stojąc u boku wynajętego architekta, nauczy się od niego właściwego spojrzenia, podejścia i po okresie kontraktu będzie mógł przejąć jego rolę. To niezbędne.

Transformacja chmurowa to nie projekt na kwartał czy pół roku, tylko wejście w proces nieustannego przekształcania i przystosowywania firmy, nieustannej zmiany dla firmy.  Dlatego musi być w niej obecny architekt, który będzie miał wiedzę, jakie poczyniono na początku założenia, jakie wykonano ustawienia, czym podyktowane są owe wybory, nawet jeśli dokonał ich ktoś, kogo już nie ma w firmie. Ta wiedza musi być w firmie. Wiedza ta jest niezbędna do utrzymywania rozwiązań chmurowych.

Kryterium otwartości na zmianę

W jaki sposób pozyskiwać dla transformacji i zmiany kompetencji pracowników IT: co jest dla nich wartością, co nie, co odbierają jako zagrożenie, co jako szansę. Czy system liderów zmiany się sprawdza? Kiedy mamy już kompetencyjny fundament osobowy zmiany – CIO i architekta chmurowego – trzeba do niej pozyskiwać pozostałych pracowników IT. Pierwsza dwójka musi przewodzić zmianie, ale jeśli chodzi o rozwój chmury dokona się on rękoma zespołu, który musi być otwarty na tę zmianę. Transformacja chmurowa się uda, jeśli pracownicy są w pewnym sensie „zafiksowani” na tę zmianę, czują ją. Nie wyobrażam sobie, że w takim przedsięwzięciu będzie ktoś, kto będzie ją negował.

Osoba, która zaakceptuje podejście stałej zmiany, przechodzi w pewien specjalny stan nieustannej chmurowej czujności. Wachlarz rozwiązań jest bogaty, a zarazem nawzajem się przenikający. Pracownicy IT uczestniczący w budowaniu systemu firmowej chmury, muszą rozumieć zależności – ich stałą zmienność i być gotowym do uwzględnienia tych zmian. Muszą stale próbować je zgłębiać, poszukiwać udoskonaleń, zagrożeń. Nieustannie zżywać się z tym środowiskiem. Bez otwartego umysłu i chęci zdobycia wiedzy, kompetencji, nie ma szansy, aby to się udało.

Już na wstępnym etapie kluczowe jest dla mnie czy osoba z zespołu jest otwarta na zmianę. Nastawienie jest kluczem – bo deficyt wiedzy i doświadczenia można wówczas po prostu uzupełnić, nadrobić. Każdy, kto wchodzi do transformacyjnego zespołu chmurowego, musi być przekonany, że chce się uczyć, mieć świadomość, że wchodzi na szybszy pas ruchu i widzieć w tym dla siebie wartość. Mam wiele przykładów pracowników IT, którzy w ogóle nie mieli doświadczenia chmurowego – i obawiali się, bo to zrozumiałe – ale wówczas moją rolą jako CIO jest pokazać im marszrutę oraz korzyści płynące również dla nich z wprowadzania tej zmiany.

Sprzężenie zwrotne w trybie chmurowym

Oferując perspektywę i udostępniając narzędzia powoduję, że tym chętniej wchodzą w zmianę. To potwierdza moje doświadczenie z dwóch transformacji w różnych organizacjach. Następuje sprzężenie zwrotne: umówiliśmy się na zmianę, na nowości, i ja im to zapewniam. Tym chętniej członkowie zespołu zagłębiają się wówczas w tę zmianę. Umawiamy się też, że „sprawdzam” z ich strony pada bardzo szybko. Nie chcę im dać czekać ani chwili na próbowanie nowego podejścia. W pierwszej fazie wszystko dzieje się może nawet szybciej, zastrzyk nowych doświadczeń jest naprawdę duży. Jako CIO nie mówię też, że to jest nagroda. Daję im zadania lub problemy do rozwiązania na tydzień – miesiąc, i zaraz podsuwam kolejne, z innego obszaru. Pracownicy są w ciągłym ruchu.

To jest – moim zdaniem kluczowe – w toku transformacji chmurowej, w ogóle w firmie wykorzystującej chmurę, nie ma stagnacji typowej, codziennej pracy IT. „Młynek” pracy operacyjnej nadal jest, ale schodzi na plan dalszy. Życie zawodowe zaczyna się teraz kręcić wokół zmienności, nauki, nowych zadań. Operacje nie mogą przesłonić rzeczywistości, która nakręca do działania. To dlatego bez przesady mówię zawsze, że transformacja chmurowa jest dla pracowników początkiem wielkiej zawodowej przygody.

Mam sytuacje, że nie wszyscy się odnajdują w takim rytmie. Musimy – w obrębie zaangażowanych w zmianę chmurową – zgodzić się, że rozwój to wartość. Nie mogę dawać pracownikowi po prostu narzędzia x, y, z – tylko możliwość samodzielnego poszukiwania rozwiązania problemu. Rozwiązania cloud computing są bardzo wdzięczne do takiego trybu działania.

Codzienność w chmurze – jak stale ostrzyć kompetencje

Z czasem, nawet w transformacji chmurowej, tego „ruchu” jest siłą rzeczy mniej. Rozwiązania chmurowe kompletnie zmieniły już wówczas sytuację firmy. W architekturze on-premise praca kreatywna dokonywała się zrywami, przedzielona okresami odcinania kuponów od wykonanej pracy. W chmurze jest przeciwnie. Sama chmura się ciągle zmienia. Ciągłe update’y sprawiają, że nie możemy się nudzić. Możemy się zgadzać z tym lub nie, ale zmiana jest ciągła, to założenie, które nie podlega ocenie: dobrze czy źle. Dla całego zespołu IT dokonywanie zmian jest codziennością. Nie ma dnia, żeby nie trzeba by było wprowadzić jakiejś zmiany, mniejszej – większej…

W środowisku on-premise zmiany wprowadzane były co kwartał, co pół roku. Trudno o lepsze zobrazowanie zmiany sytuacji pracownika i mojej, jako CIO. Widać, jak kluczowe było dobranie pracowników otwartych na zmianę. Dziś – poszukujących nowych rozwiązań dla biznesu, bo o ile wczoraj jakieś zadanie można było zrobić w dany sposób, to dziś właśnie pojawiła się możliwość innego rozwiązania problemu. W tym momencie pracownicy, którzy są „młynkowymi” odpadają na starcie. Takie ułożenie środowiska gwarantuje stały rozwój pracowników. Oni się codziennie uczą. Szukają, pytają, „ostrzą” swoje chmurowe kompetencje.

Długofalowa ścieżka kompetencji

Im bardziej firma jest w ekosystemie chmury publicznej i różnorodnym środowisku chmurowym, być może także hybrydowym, tym bardziej właściwe zbilansowanie kompetencji wydaje się konieczne. Jakie ścieżki i role warto zaplanować, jak współpracować przy tym z HR? Profil pracownika IT w toku transformacji chmurowej zmienia się. Powinno to znajdować odzwierciedlenie w działaniach HR wspierających rekrutację i rozwój. Oczywiście zależy mi, aby szukali odpowiednich osób, stosownych szkoleń, wiedzieli, jak funkcjonuje zespół jako całość, co jest dla ludzi o takim profilu ważne. A tym samym, stopniowo, nieuchronnie zarażali się i nabywali tej świadomości, że staliśmy się firmą działającą w trybie chmurowym.

To wszystko zależy jednak od poziomu dojrzałości zespołu HR. Mam natomiast wrażenie, że ta dojrzałość nie nadąża za tempem zmiany chmurowej. Przy rekrutacji i utrzymaniu, rozwoju pracownika, jest szereg elementów kompetencji miękkich i wiedzę o tym jestem w stanie przekazać HR. Ale w aspektach kompetencji technicznych – zdecydowanie muszę rekrutację brać na siebie. Wręcz nawet nie chcę się z tym dzielić. HR-y nie pomogą, nie znają naszego specyficznego „języka”. Dlatego, kiedy dyskutuję z HR, to bardziej koncentruję się na rzeczach miękkich: współpracy z użytkownikiem, pracy w zespole, umiejętności negocjacji. To jest wystarczające novum, widzę, jak koledzy i koleżanki z HR otwierają niekiedy szerzej oczy, bo nie z takimi cechami dotychczas kojarzyło się im IT.

Zmiana, ciągła zmiana wymaga umiejętności tłumaczenia. Pracownik IT musi umieć pójść do biznesu i powiedzieć, że wprowadzona została zmiana, w wyniku której dana funkcja czy produkt będą działały w nowy sposób. Tu mówimy już o stricte miękkich kompetencjach IT. I jest to przełom. Myślę, że transformacja chmurowa kompletnie zmienia zespół IT. Dotąd byliśmy w kokonie. Zmiany, które wprowadzamy mają taki wpływ na biznes, że musimy trzymać rękę na pulsie, stale być gotowym tłumaczyć. To nowa, bardzo ważna kompetencja.

Duża zmienność, takie dzienne „taktowanie” zmiany powinno też wpisywać się w pewną długofalową wizję rozwoju kompetencji. Z mojej perspektywy cały zespół ma jasno nakreślone perspektywy rozwoju własnego i technologii w horyzoncie 2-3 letnim. Wiedzą, co ich czeka. Czasem nie do końca jest to sprecyzowane, a niektóre kwestie są dla nich niejasne i po prostu nieznane, ale z czasem te cele się klarują. Oczekuję od zespołu, że będą to mieli z tyłu głowy i zawczasu będą to uwzględniać w toku swojej codziennej pracy w chmurze. To dotyczy wszystkich elementów dalekosiężnych, strategicznych.

Pracownicy IT nieustannie zastanawiają się nad swoją przyszłością. Jakie konsekwencje dla mnie niesie ewolucja DevOps – noOps? Podejście kontenerowe a serverless… Co zmienia automatyzacja? Ta dłuższa perspektywa daje im odpowiedzi na pytania, które sobie na pewno stawiają.

Jest w tym też taki zamysł, aby zespół prowadzący transformację chmurową nie myślał tylko o codziennych sprawach, ale także o przyszłości. To rola CIO, aby tę przestrzeń im wykreować. Jak również, aby w tej przestrzeni, przyszłości, stopniowo mógł odnajdywać obszar, w którym będzie próbował się rozwijać mocniej. Zdecydowanie unikam i odradzam w tym wypadku słowa „specjalizować”. Powody są proste: mała – średnia firma nie może sobie pozwolić na osobny zespół od Microsoft Azure, Google Cloud, AWS. Dlatego to musi być rozwój wielokierunkowy, aby osoby mocniej rozwijające się w poszczególnych obszarach nadal miały wspólną chmurową perspektywę i potrafiły ze sobą rozmawiać, poszukiwać rozwiązań, robić burze mózgów. Inaczej – popadniemy w silosy, choćby były one w chmurze. Pod względem kompetencji zespół musi być złożony z komplementarnych jednostek, wręcz redundantnych.

Utrzymanie szerokiego spojrzenia na chmurę, z jakimś akcentem głębszego poznania danego obszaru w bardzo długofalowej perspektywie, zabezpiecza przyszłość zawodową osób z mojego zespołu, „ubiera” ich w doświadczenie, mądrość. Ogromnie lubię pracować z ludźmi, dlatego chcę mieć przekonanie, że kiedy odchodzą, to zabierają cenne doświadczenia, które zebrali w moim zespole. Bardziej dbam o to, aby mieli szerokie horyzonty niż wąską specjalizację. Kiedyś w IT wąska specjalizacja była gwarancją sukcesu – dziś są to szerokie horyzonty – i indywidualnie, i zespołu, i całej firmy.

Chmurowa edukacja biznesu

A na jakim etapie i w jakim zakresie zadbać o “chmurowe” kompetencje biznesu? Transformacja chmurowa jest tego typu zmianą technologiczną, o której biznes powinien wiedzieć. Jakimi sposobami dostarczać im tej wiedzy? Według mnie, najlepsze jest podejście, w którym to uświadamianie dzieli się na dwa etapy. Samo wprowadzenie podstawy transformacji chmurowej musi być dokonane twardo, nawet bez specjalnego wyjaśniania. Dlaczego? Dlatego że dopiero wprowadzenie podstawowych narzędzi pracy – takich jak poczta, komunikatory, wspólna przestrzeń – to dopiero otwiera oczy biznesowi. To nie są też rzeczy do negocjowania.

Dopiero po tym mocnym wejściu, uruchamiamy proces edukacji. Wcześniej byłaby to nauka pływania na sucho. Jest w tym pewna analogia do wdrożenia zespołu IT w transformację chmurową. Oni także od razu dostają zadania i zestaw narzędzi, a nie wprowadzające warsztaty. Sprawdza się to również w biznesie: jeśli użytkownik po warsztacie, szkoleniu będzie mógł sobie zastosować funkcję albo skorzystać z rozwiązania, to wówczas nauczy się tego w zupełnie nowy sposób.

Miarą sukcesu takiego podejścia jest to, że po pewnym czasie – nieokreślonym – biznes wraca i pyta o możliwość wykonania w chmurze jakiejś zamyślonej zmiany w procesie czy produkcie. Jestem wówczas przekonany, że całość zmierza w dobrym kierunku – pokazywanie ustawicznie plusów i minusów rozwiązania, pełnego spektrum, co się zmienia, jak się zmienia, powoduje, że biznes przychodzi i zaczyna pytać, przynosić pomysły na zmianę, poprawę funkcjonowania procesów biznesowych z wykorzystaniem środowiska chmurowego.

Ważne, aby wówczas IT wchodziło w taki dialog, współpracę. Skoro wprowadziliśmy elastyczne środowisko – wykorzystajmy to. Pokazujemy więc im dostępne rozwiązania, otwieramy oczy. Wówczas biznes sam zdecyduje o rozwiązaniach, wyselekcjonowanych przez nas z bardzo dużego wachlarza możliwości. Jesteśmy w dobrej sytuacji, bo jako IT wiemy najwięcej o funkcjonowaniu firmy, o jej procesach, o samym biznesie.  To zawsze była norma w przypadku dobrze prowadzonego IT, niezależnie od architektury. Kiedy mamy połączenie wiedzy z doświadczeniem, możemy dopasować rozwiązania chmurowe do procesów, w taki sposób, aby zmiana u nas nie pociągała rewolucji po stronie klienta, bo nie chodzi o wywoływanie turbulencji w codziennym prowadzeniu biznesu.

Chmura jest więc też czymś w rodzaju wprowadzenia komunikacji w naturalnym języku. Tyle, że nie użytkownika z maszyną, ale na linii IT-biznes. Mniej jest „przekładni”, które mają przetłumaczyć potrzebę na narzędzie. Z kompetencją rozumienia chmury nie potrzeba specjalnego nasycania komunikacji wiedzą i językiem chmurowym. Od podanego kryterium, np. „time to market”, dla chmurowego IT jest już tylko jeden krok do usługi lub kategorii usług, którymi się tę potrzebę obsłuży. Funkcja warstwy pośredniczącej – zanika. To ewolucja, nie rewolucja. Bez tego tracilibyśmy potencjał jaki daje fakt, że to biznes odkrywa pewne rzeczy. Dlatego wolę, żeby to oni przychodzili do IT i komunikowali potrzeby niż podsuwać im gotowe rozwiązanie. Pomagam im wchodzić w taki nowy tryb współpracy, oswajać technologię. To pożądana ścieżka, aby nie wylać dziecka z kąpielą.

Cloud computing as usual

Dochodzimy to pytania kluczowego: w jakim tempie organizacja dojrzewa pod względem kompetencji chmurowych? Jak szybko przejmuje np. od zewnętrznego dostawcy lub doradcy i integratora pełnię odpowiedzialności i decyzyjności? Kiedy jest wytrawna, dojrzała? W pierwszy etapie kompetencje chmurowe pojawiają się i przyrastają bardzo szybko. Z czasem następuje faza budowania komplementarności, uczynienia z trybu chmurowego – naturalnego trybu działania organizacji. Z mojego doświadczenia i obserwacji wynika, że potrzeba trzech pełnych lat, aby powiedzieć, że mamy zespół, który poradzi sobie z każdym wyzwaniem czy problemem chmurowym.

To jest tempo osiągania poziomu dojrzałości, który stwarza całkowicie nowe szanse dla firmy i działu IT. W jednym z moich zawodowych wcieleń, w takim właśnie czasie zbudowaliśmy organizację IT od zerowego poziomu wiedzy o chmurze, do statusu centrum kompetencji chmurowych międzynarodowej grupy. Dojrzewa IT, ale i dojrzewa organizacja. CIO powinien kontrolować przebieg tej zmiany – na różnych etapach mocniej lub dyskretniej zaznaczając swoją obecność. To jest nasza jako CIO, rola w biznesie.

W czasie pandemii COVID-19, to naturalne tempo zostało zaburzone – dla niektórych organizacji konieczne było przeprowadzenie transformacji w tempie turbo. Takie rewolucje chmurowe zdarzały się także wcześniej, bez pandemii, kiedy transformacja dokonywała się pod wpływem jakiejś presji. Tempo może być szybsze, ale ryzyko jest oczywiście większe. A rewolucja z reguły pożera swoje dzieci. Bez odpowiednich kompetencji, analizy, pewności – trzeba być gotowym na komplikacje, niepokoje w firmie itd.

W normalnych warunkach transformacja chmurowa kompetencji, to proces ciągły który powinien trwać, jak wspomniałem, około trzech lat. Po tym okresie organizacja działa w trybie „cloud as usual”. Kompetencje będą na tyle duże, że proces negocjowania nowych usług, wypracowywania ich, będzie elastyczny, płynniejszy. Wówczas nawet pojawia się odrobina rutyny.

Chmurowa dojrzałość to stan umysłu, a nie certyfikaty

Dojrzała chmurowo organizacja ma też pewną bardzo wyraźną cezurę czasową. Dla mnie – wyznacza ją osiągnięcie poczucia niezależności od chmury – posiadania kompetencji i środków do opuszczenia danego środowiska na rzecz innego. Swobodnego przemieszczania się w architekturze multicloud, hybrydowej.

Dojrzałość kompetencyjna przejawia się też innym funkcjonowaniem – CIO może właśnie wówczas ukierunkowywać niektórych pracowników na zajmowanie się szczególnie jakimiś obszarami. Dlatego, że pracownik jest już na tyle chmurowo dojrzałą osobą, że nie zamknie się tylko do tego pola. To jest świadectwo dojrzałości – nabyta niechęć do zamykania się w swoim silosie. Jest to u dojrzałych chmurowo osób na tyle mocne, że swobodnie mogą np. czasowo skupić się na jakimś węższym obszarze lub wręcz całkowicie odpowiadać za wdrożenie jakiegoś nowego narzędzia w oparciu o chmurowe możliwości

Zdecydowanie i z premedytacją nie definiuję natomiast owej dojrzałości jakimiś stosami technologicznymi. Dojrzałość – to wolność. Można wybrać kierunek, w którym idziemy. Jest to jeden z celów przewodnich CIO, stale w tyle głowy – nie zapętlić się np. u jednego dostawcy. To zatem moment, kiedy możemy bardzo świadomie wybrać rozwiązania technologiczne z zupełnie innego stosu technologicznego niż ten, którym się posługujemy. Spośród miliona elementów wybieramy świadomie konkretnie jeden i wiemy, dlaczego. W naszym otwarciu na zmianę docieramy do punktu, w którym nie ogranicza nas nawet środowisko i rozmiar ewentualnej migracji chmurowej. Biznes będzie się toczył „as usual”. Ale technologia, od której jest uzależniony może – a nawet powinna się zmieniać. Bo to jest paradygmat technologii i architektury chmurowej.

Ostatni ciekawy aspekt chmurowej zmiany kompetencyjnej dotyczy uzależnienia biznesu od technologii. Nigdy dotąd nie było tak silne, jak w modelu chmurowym. Mamy wręcz wewnętrzny vendor-lock. Nigdy nie byłem za wprowadzaniem technologii, po to, aby odtwarzała jakąś wcześniej zdefiniowaną akcję – teraz przetwarzanie jest dobrą, wymaganą praktyką przy przenoszeniu procesu do chmury. Dzięki IT zmianą technologiczną obejmowany jest on całościowo – nie ma więc przeniesienia wąskich gardeł w inne miejsca. Transformacja chmurowa kończy w zasadzie dyskusję o tym, czy IT jest w firmie potrzebne. W modelu chmurowym, jest niezbędnym partnerem, współwłaścicielem procesów, bez którego nie mogą dokonać się w nich zmiany.

Krzysztof Wykręt pełni funkcję Global IT Directora w Gulermak, jest członkiem  Rady Programowej CXO HUB.