StoneX Group – firma z listy Frotune 100, sieć usług finansowych klasy instytucjonalnej, globalna organizacja fintech i właściciel Forex.com – w 2019 roku stanął przed koniecznością usprawnienia działalności w zakresie zarządzania zmianą (Change Management). Wbrew popularnym trendom w branży, kluczem do rozwiązania problemu nie okazały się kosztowne projekty związane z nowymi technologiami, lecz proces – prawdopodobnie najmniej lubiane dziecko IT.
Nowy proces spowodował zmianę kulturową w organizacji i pozwolił na znaczącą poprawę sytuacji pomimo stosowania wciąż tych samych technologii. Nowe podejście do zmian pozwoliło zwiększyć autonomię managerów i ich zespołów, a następnie w pełni wykorzystać potencjał nowych narzędzi i transformacji technologicznej. Jako Architekt Serwisów byłam motorem tej zmiany i dziś z prawdziwą satysfakcją przedstawiam nasz przykład jako dowód na ogromny – i wydaje się wciąż niedoceniony – potencjał procesu jako narzędzia w transformacji IT.
Houston, mamy… incydent
Fintech, to specyficzna branża, w której przedmiotem szczególnej troski jest balans między szybkością wprowadzania zmian, podążaniem za potrzebami rynku i regulacjami prawnymi, a stabilnością i dostępnością usług. Z jednej strony są niezbędne dla biznesu innowacje, nowe rozwiązania i ekspansja na rynkach, a z drugiej oczywiste ryzyko incydentów generowanych przez zmiany.
2019 roku StoneX znalazł się w miejscu, w którym liczba i dotkliwość incydentów przekroczyła poziom ryzyka akceptowanego przez biznes. Zdecydowano o pilnej konieczności poprawy sytuacji w obszarze zarządzania wdrożeniami, które były głównym generatorem incydentów. Szukając przyczyn niekorzystnego stanu zidentyfikowano problemy z obszaru technologii, zarządzania, zasobów, umiejętności, ale także procesów związanych z zarządzaniem zmianami. Stąd zadanie poprawy sytuacji zostało powierzone Architektowi Serwisów – nowej, nieoperacyjnej roli stworzonej w firmie.
W 2019 roku StoneX znalazł się w miejscu, w którym liczba i dotkliwość incydentów przekroczyła poziom ryzyka akceptowanego przez biznes. Zdecydowano o pilnej konieczności poprawy sytuacji w obszarze zarządzania wdrożeniami, które były głównym generatorem incydentów. Szukając przyczyn niekorzystnego stanu zidentyfikowano problemy z obszaru technologii, zarządzania, zasobów, umiejętności, ale także procesów związanych z zarządzaniem zmianami. Stąd zadanie poprawy sytuacji zostało powierzone Architektowi Serwisów – nowej, nieoperacyjnej roli stworzonej w firmie.
Myśl mojej zasady „process first, then tool” podjęłam się takiej zmiany procesu, która w relatywnie krótkim czasie pozwoli zrealizować strategiczne cele top managementu – znacząco obniży ich zaangażowanie w zarządzanie wdrożeniami, a jednocześnie zmniejszy liczbę incydentów i ułatwi oraz przyspieszy wdrożenia zmian na produkcję. Moja rola polegać miała na przeprowadzeniu konsultacji wstępnych, zebraniu wymagań, zaprojektowaniu, skonsultowaniu, przygotowaniu narzędzi, materiałów szkoleniowych, globalnym wdrożeniu procesu i jego dalszych udoskonaleń.
Dokładna analiza sytuacji wskazała kilka obszarów wymagających poprawy
Przede wszystkim proces w nadmierny sposób angażował najwyższy szczebel managerski – ze względu na rosnącą ilość incydentów i obawy przed kolejnymi. Każda zmiana wymagała wielopoziomowej akceptacji, włączając zgodę na poziomie C-1. Wraz ze wzrostem liczny incydentów rosła liczba wymaganych zgód. Rozmywało to odpowiedzialność za wdrożenia, liczba incydentów wciąż była zbyt wysoka. Istniejący proces nie był wystarczająco dobrze udokumentowany, nie było matrycy odpowiedzialności, występowała pewna dowolność w podejściu do wdrażania zmian na produkcji, brakowało również minimalnych wymagań jakościowych. W efekcie niemal wszystkie zmiany były duże, skomplikowane, wymagały zgody najwyższej kadry zarządzającej i były wdrażane w weekendy. Miało to niekorzystny wpływ na morale zespołów pracujących w weekendy mierzących się jednocześnie z falą wdrożeń jak i z rosnącą liczbą incydentów.
Krótkie konsultacje pozwoliły na zidentyfikowanie wspomnianych obszarów i wyznaczenie najważniejszych wymagań dla nowego procesu tak, aby wspierał on osiągnięcie strategicznych celów biznesu, jak i kierownictwa pionu IT. Ze względu na konieczność szybkiej poprawy sytuacji musiałam się skupić na stworzeniu procesu nieidealnego, lecz osiągalnego, takiego, którego wdrożenie będzie możliwe w naszej organizacji, dostosowanego do jej specyfiki i bazującego na istniejących rozwiązaniach technicznych.
Dotychczasowy proces w nadmierny sposób angażował najwyższy szczebel managerski – ze względu na rosnącą ilość incydentów i obawy przed kolejnymi. Każda zmiana wymagała wielopoziomowej akceptacji, włączając zgodę na poziomie C-1. Wraz ze wzrostem liczny incydentów rosła liczba wymaganych zgód. Rozmywało to odpowiedzialność za wdrożenia, liczba incydentów wciąż była zbyt wysoka. Istniejący proces nie był wystarczająco dobrze udokumentowany, nie było matrycy odpowiedzialności, występowała pewna dowolność w podejściu do wdrażania zmian na produkcji, brakowało również minimalnych wymagań jakościowych.
Dla każdego ze zidentyfikowanych problemów zdefiniowałam konkretny element procesu, który go rozwiązuje. Konsultacje pozwoliły stworzyć jasne zasady klasyfikacji zmian wg ryzyka, zależnie od którego musiały one spełniać określone wymagania jakościowe. Prawdziwą rewolucją było zdefiniowanie wdrożeń niskiego ryzyka, dla których – wbrew dotychczasowemu trendowi dokładania kolejnych szczebli aprobaty – postanowiłam zmniejszyć ilość wymaganych do wdrożenia zgód. Dzięki temu do wdrożenia zmiany niskiego ryzyka wystarczyła tylko zgoda managera serwisu, który potwierdzał spełnienie wymagań jakościowych. Była to prawdziwa rewolucja, ponieważ takie zmiany nie wymagały ani dodatkowych dyskusji ani zgody CABa.
Dodatkowo dla tych zmian otworzyłam możliwość wdrażania na produkcję w tygodniu roboczym, w określonych oknach technicznych. Nowy proces w znaczący sposób zwiększał więc autonomię managerów, ale jednocześnie jasno definiował ich odpowiedzialność. Możliwość błyskawicznego wdrażania niewielkich zmian niskiego ryzyka w tygodniu zachęciła zespoły do dzielenia pracy na mniejsze części, co znacząco skróciło czas potrzebny do wdrożenia zmian na produkcję. Te rozwiązania wprost realizowały strategiczny cel tego projektu – pozwalały przestać angażować najwyższy szczebel zarządzający w zgody na zmiany i oddawało autonomię managerom odpowiedzialnym za serwis, co wprost skracało czas potrzebny do wdrożenia zmiany.
Zmiana procesu zmiany
Szczegółowe rozwiązania wprowadzone w nowym procesie nie nakładały na zespoły sztywnych ram, ale były zbiorem możliwości i wymagań nienarzucających sposobu ich realizacji. Pozwoliło to zespołom korzystać z możliwości, w których widzieli wartość (jak np. specjalna kategoria rutynowych, standardowych zmian z szybką ścieżką do wdrożenia) ale nie narzucało konkretnego sposobu pracy. Proces wskazywał zatem ramy, zasady i wymagania, ale dawał jednocześnie wolność i odpowiedzialność, co do sposobu ich realizacji.
Dla każdego ze zidentyfikowanych problemów zdefiniowałam konkretny element procesu, który go rozwiązuje. Konsultacje pozwoliły stworzyć jasne zasady klasyfikacji zmian wg ryzyka, zależnie od którego musiały one spełniać określone wymagania jakościowe. Prawdziwą rewolucją było zdefiniowanie wdrożeń niskiego ryzyka, dla których – wbrew dotychczasowemu trendowi dokładania kolejnych szczebli aprobaty – postanowiłam zmniejszyć ilość wymaganych do wdrożenia zgód. Dzięki temu do wdrożenia zmiany niskiego ryzyka wystarczyła tylko zgoda managera serwisu, który potwierdzał spełnienie wymagań jakościowych. Była to prawdziwa rewolucja.
Samo wdrożenie nowego procesu nie wymagało żadnych nowych rozwiązań technicznych. Bazowało na drobnych zmianach konfiguracyjnych do istniejących w firmie narzędzi. Proces został natomiast skrojony na miarę i wykorzystywał istniejące w organizacji zespoły i ich kompetencje, a jego wdrożenie, mimo że działo się w czasie sprzed pandemii Covid, ze względu na globalne rozproszenie zespołów, odbywało się w pełni online przy pomocy wideokonferencji.
Jakie były efekty i jak je zmierzyć?
Wraz ze zdefiniowaniem, udokumentowaniem i dostarczeniem materiałów szkoleniowych oraz wsparcia merytorycznego znacząco zwiększyła się świadomość zespołów o procesie, a otrzymana autonomia decyzji wniosła niespotykane wcześniej poczucie odpowiedzialności. Dokonała się zmiana kulturowa w podejściu do CABa. Zmiany okazały się być lepiej przygotowane Szybko zmienił się także rozkład procentowy zmian, z których większość stała się wdrożeniami niskiego ryzyka wykonywanymi w tygodniu. Jednocześnie – mimo skrócenia łańcucha aprobaty – zmniejszyła się liczba incydentów. Skrócił się także czas (Time-to-Market) potrzebny na wdrożenie zmian.
Różnica w rozkładzie ilości wdrożeń w tygodniu przed i po wdrożeniu nowego procesu.
Uporządkowanie i poprawienie procesu otworzyło drogę do wprowadzania dalszych usprawnień, automatyzacji wdrożeń i pełną automatyzację zmian niskiego ryzyka. Dzięki spójnym zasadom, przejrzystości, automatyzacji manualnych zadań i zmniejszenia ilości incydentów tylko w zespole wdrożeniowym zostały zaoszczędzone 2 FTE (Full-Time Equivalent) wykorzystywane dotychczas na obsługę wdrożeń. Czas ten mógł być zainwestowany w innowacje, wdrożenie i lepsze wykorzystanie potencjału nowo nabytych rozwiązań technologicznych.
Zmiana procesu to tak naprawdę zmiana sposobu, w jaki pracują ludzie i zespoły, przez co dostosowanie do nowych reguł zawsze wymaga wysiłku. Rodzi to niestety opór wśród pracowników, dlatego kluczowe jest to, żeby zmiana przynosiła wartość zarówno dla biznesu, managerów IT, jak i pracowników. Wspieranie realizacji celów strategicznych zapewnia niezbędne dla każdej transformacji wsparcie managementu. Natomiast proces sam w sobie nie może być przeszkodą w realizacji zadań, ale wsparciem i dobrze znaną drogą do celu. Proces mimo istniejących w branży negatywnych stereotypów nie musi być smutnym dokumentem nakładającym kajdany na pracowników i zespoły, ale może być zbiorem jasnych zasad i wymagań, które dzięki powszechnej znajomości i zrozumieniu wspierają zespoły w dostarczaniu wartości dla biznesu. Odpowiednio zbudowany proces, może zwiększać autonomię i być dowodem na ogromne zaufanie jakim darzymy naszych pracowników, a nie na jego brak.
Proces jako potężne, ale wciąż niewystarczająco docenione narzędzie transformacji
Mimo rosnącej popularności związanych z procesami szkoleń i certyfikacji, jak i rosnącej ilości ekspertów z tego obszaru, często procesy traktowane są jako coś zabijającego autonomię, tzw. kulturę startupu i wciąż wiedza i zadania związane z ich wdrażaniem są niejako dodatkowymi wobec operacji. Tymczasem to procesy leżą u podstaw działania organizacji i dobry proces, na dopasowanym do potrzeb organizacji poziomie dojrzałości, jest kluczem do efektywnego działania. Inaczej ryzykujemy jeszcze szybsze generowanie incydentów przez technologiczne „usprawnienie chaosu”.
Decyzje kadry zarządzającej w StoneX, stworzenie w organizacji roli skoncentrowanej na procesach i inwestycja w ten obszar pozwoliło prawidłowo wykorzystać potencjał procesu jako aktywatora, który odpowiednio użyty może zwiększać zaufanie i autonomię managerów, otworzyć nowe drogi do innowacji i pomaga w pełni wykorzystać potencjał nowych rozwiązań technologicznych.
Dominika Pacyna, Service Architect, StoneX Group
