Gdzieś w połowie lat 90. audytorzy finansowi zaczęli mieć problem. Systemy informatyczne w dużych korporacjach rozrosły się do tego stopnia, że nikt nie potrafił powiedzieć, kto właściwie odpowiada za konkretną decyzję technologiczną, kto zatwierdził wydatek na nową infrastrukturę i dlaczego projekt za 3 miliony dolarów właśnie wyszedł poza budżet bez żadnej eskalacji do zarządu. ISACA, stowarzyszenie audytorów systemów informatycznych, opublikowała w 1996 roku pierwszą wersję COBIT – framework zbudowany pierwotnie nie dla CIO, lecz właśnie dla tych audytorów, którzy musieli jakoś ogarnąć bałagan decyzyjny w IT.
To chyba najuczciwsza odpowiedź na pytanie, czym jest IT governance: próbą odpowiedzi na pytanie, kto tu właściwie rządzi. Nie w sensie hierarchicznym, lecz w sensie decyzyjnym. Peter Weill i Jeanne Ross z MIT Sloan Center for Information Systems Research opisali to w 2004 roku jako „przypisanie praw decyzyjnych i ram odpowiedzialności, które mają zachęcać do pożądanych zachowań w użyciu IT”. Brzmi sucho, ale w praktyce oznacza jedno: w firmie bez IT governance każdy decyduje o wszystkim albo nikt nie decyduje o niczym, i obie te sytuacje kończą się tak samo.
Rok 2002 i nagłe zainteresowanie tematem
Przed upadkiem Enronu i uchwaleniem Sarbanes-Oxley Act w 2002 roku IT governance było tematem raczej akademickim, interesującym głównie konsultantów i naukowców z MIT. Po SOX przestało być opcjonalne przynajmniej dla spółek notowanych na giełdach amerykańskich, bo nowe prawo wymagało udokumentowania kontroli wewnętrznych nad raportowaniem finansowym – a te kontrole w zdecydowanej większości przypadków zależały od systemów IT. Nagle okazało się, że brak jasnych zasad zarządzania technologią to nie tylko problem operacyjny, ale potencjalna odpowiedzialność karna dla zarządu. COBIT 3 z 2000 roku stał się niemal obowiązkową lekturą dla działów compliance w całych Stanach, a kolejna edycja – COBIT 4 z 2005 roku – była już pisana z myślą o tym nowym świecie.
W Europie podobną rolę odegrały regulacje sektorowe: w bankowości Bazylea II, w ochronie zdrowia kolejne dyrektywy unijne, w energetyce wymogi operatorów sieci. Za każdym razem mechanizm był ten sam: regulator wymaga dokumentacji, dokumentacja wymaga procesów, procesy wymagają kogoś, kto za nie odpowiada. I tak IT governance wchodziło tylnymi drzwiami do firm, które nigdy by same z siebie po nie nie sięgnęły.
Co to naprawdę oznacza dla organizacji
Wyobraźmy sobie firmę produkcyjną zatrudniającą 400 osób, która po kilku latach organicznego wzrostu ma cztery oddziały, trzy różne systemy ERP i dwa zewnętrzne dostawców chmury – każdy dobrany przez innego dyrektora w innym roku. Dział IT obsługuje to wszystko siedmioma osobami. Decyzja o wymianie jednego z systemów ERP leży gdzieś pomiędzy CFO, który płaci faktury, COO, który używa danych do planowania produkcji, i CTO, który musi to zintegrować z resztą. Nikt nie ma formalnej władzy, żeby powiedzieć: „decydujemy tak”. Projekt rusza albo nie rusza zależnie od tego, kto akurat ma więcej energii na walki wewnętrzne. To jest właśnie brak IT governance, i nie ma w tym nic wyjątkowego – to raczej norma niż wyjątek w firmach poniżej pewnej skali.
IT governance nie jest jednym narzędziem ani jednym dokumentem. To raczej zestaw mechanizmów, który obejmuje przynajmniej trzy poziomy: kto podejmuje decyzje (struktury), jak te decyzje są podejmowane (procesy) i jak się sprawdza, czy były dobre (metryki i audyty). COBIT w swojej obecnej wersji organizuje to wokół pięciu obszarów: oceny, kierowania i monitorowania po stronie governance oraz budowania i dostarczania po stronie zarządzania. ITIL skupia się bardziej na zarządzaniu usługami i ich jakości, a więc operuje raczej na poziomie zarządzania niż governance w ścisłym sensie – choć granica między nimi bywa w praktyce rozmyta i warto ją rozumieć, zanim sięgnie się po którykolwiek z frameworków.
Pułapka dokumentu, który nikt nie otwiera
Największy błąd, jaki obserwuję w organizacjach próbujących wdrożyć IT governance, to pomylenie mapy z terenem. Firma zamawia konsultanta, konsultant dostarcza po trzech miesiącach policy document liczący 80 stron, zarząd zatwierdza w pięć minut na posiedzeniu i odkłada na dysk sieciowy. Sześć miesięcy później nikt tego dokumentu nie pamięta, a decyzje technologiczne zapadają tak samo jak przed wdrożeniem, czyli jakoś między stanowiskiem pracy a korytarzem przy ekspresie do kawy.
Problem z IT governance jest taki, że jego wartość jest prawie niewidoczna, gdy działa, i bardzo widoczna, gdy nie działa. Projekt, który trafił do eskalacji za późno, bo nie było jasne, do kogo eskalować – to koszt IT governance, którego nie było. Audyt, który ujawnił trzy niezatwierdzone licencje na oprogramowanie za łącznie 200 tysięcy złotych rocznie, bo nikt nie prowadził rejestru umów – to kolejny. Standish Group od lat monitoruje kondycję projektów IT w swoim CHAOS Report i obraz jest raczej niewesoły: znaczna część projektów przekracza budżet, harmonogram albo nie dostarcza zakładanej funkcjonalności. Brak jasnych struktur decyzyjnych pojawia się w tej literaturze jako jeden z powtarzających się czynników.
Dlatego firmy rzadko sięgają po doradztwo IT governance z własnej inicjatywy – najczęściej coś musiało się najpierw posypać. Audyt powdrożeniowy, który ujawnił że nikt nie wiedział o projekcie za pół miliona, albo retrospekcja po fakapie z dostawcą, który zmienił warunki umowy i nagle okazało się, że umowę podpisał ktoś bez odpowiednich uprawnień. Te sytuacje mobilizują znacznie skuteczniej niż jakikolwiek raport Gartnera.
Skala ma znaczenie
IT governance w firmie zatrudniającej 30 osób i IT governance w organizacji z 3000 pracownikami to raczej dwa różne zjawiska, które tylko używają tej samej nazwy. W małej firmie wystarczy czasem jedno spotkanie co dwa tygodnie, na którym CTO, CFO i CEO uzgadniają priorytety technologiczne i zapisują to w jakimś sensownym miejscu – i to już jest governance, nawet jeśli nikt tak tego nie nazwie. Przy 3000 osób potrzebne są formalne komitety, matryca RACI, zdefiniowane progi eskalacji i cykliczne przeglądy portfela projektów, bo bez tego backlog projektów IT staje się listą życzeń bez żadnego związku z rzeczywistością organizacyjną.
COBIT, ITIL, ISO 38500 – wszystkie te standardy mają tę samą odpowiedź na pytanie o skalę: zacznij od tego, co boli najbardziej. Nie od dokumentu. Nie od certyfikatu. Od pytania, kto w twojej firmie ma ostatnie słowo w decyzjach technologicznych i czy wszyscy to wiedzą.
Źródła
- Weill P., Ross J.W., „IT Governance: How Top Performers Manage IT Decision Rights for Superior Results”, Harvard Business School Press, 2004.
- ISACA, „COBIT 2019 Framework: Introduction and Methodology”, ISACA, 2018.
- Standish Group, „CHAOS Report” – cykliczny raport o kondycji projektów IT, standishgroup.com.
- ISO/IEC 38500, „Information technology – Governance of IT for the organization”, ISO.
Zdjęcie: Praveen Thirumurugan / Unsplash
