„Co mam zrobić z całym tym bałaganem?”

Data: 2014-07-14
Autor: Sebastian Konkol
„Co mam zrobić z całym tym bałaganem?”

Wiele organizacji IT jest głęboko uwikłanych w projekty rozwojowe, zapewniające wsparcie dla zmieniającego się biznesu firm. W związku z pędem ich realizacji, na dalszy plan schodzą potrzeby dbałości o obsługę długu technologicznego. Każda technologia, prędzej czy później, staje się przestarzała, a w przypadku technologii IT cykle życia skracają się tak, że lokuje to je bliżej końca skali oznaczonego jako „prędzej”. Coraz mniejszy odsetek organizacji IT w ogóle zajmuje się zagadnieniami długu technologicznego – część z nich z powodu braku czasu na refleksję, a część z powodu braku zrozumienia tego zagadnienia i jego konsekwencji w dłuższym horyzoncie czasu.

O tym zagadnieniu wolę myśleć w kategoriach ryzyka (zarządzanie), nie długu (spojrzenie finansowe). Upraszczając sprawę, im starsza technologia tym większe prawdopodobieństwo problemów w jej użytkowaniu, a im dłużej jest wykorzystywana, tym mocniej staje się ona wbudowana w całość środowiska IT firmy. Mówiąc o problemie w użytkowaniu mam na myśli nie tylko awarie techniczne, ale dostępność aktualizacji poprawiających bezpieczeństwo, kompetencji jej utrzymania i zarządzania nią, czy dostępności sił zdolnych do rozwoju systemów na niej bazujących. W sytuacji skrajnej, kiedy cała firma opiera się w sferze informatyki o dokładnie jedną technologię, cała wartość biznesu jest niedostępna, jeśli nawet mała jej część zawiedzie. W sytuacji typowej starsza technologia po prostu kosztuje wielokrotnie więcej, niż nowsza.

Celem jest ustanowienie zdolności organizacji IT do radzenia sobie z problemami ryzyka technologicznego (istotnej składowej długu technologicznego). W mojej praktyce, dla zobrazowania zagadnienia i wprowadzenia zdolności zarządzania nim, posługuję się trzema koncepcjami:

  • cykl życia technologii – zrozumienie, że (choć nie w czasie liniowym) każda technologia staje się przestarzałą i po pewnym czasie wymagać będzie wyłączenia;
  • planowanie migracji – przygotowanie do wprowadzenia do środowiska informatycznego zmian, które nie budują dodatkowej wartości biznesowej, ale pełnią rolę kuracji anti-aging dla IT;
  • zarządzanie ryzykiem technologicznym – identyfikacja komponentów technologii IT reprezentujących zagrożenie dla biznesu, wyrażania ich w kategoriach mierzalnych (prawdopodobieństwa i skutku) i objęcia mechanizmami zarządczymi znanymi dla sfery ryzyka (monitorowanie, zapobieganie, leczenie).

Podejście, jakie stosuję, opiera się na ocenie każdego z komponentów architektury (aplikacji, danych, infrastruktury) z perspektywy ryzyka technologicznego w odniesieniu do ciągłości działania, utrzymania i rozwoju danego komponentu, zarówno przez pryzmat własnych sił jak i dostępnego na rynku wsparcia. Kluczową dla skuteczności komunikacyjnej tego podejścia jest zdolność do wyrażenia wartości monetarnej poszczególnych czynników ryzyka. Nie jest to ani proste, ani łatwe do obrony przed zarządami firm, ale każdy kto kiedykolwiek próbował przekonać CFO do wydania sporej kwoty na podmianę technologii wie, że mówienie o zaletach technologii jest stratą czasu i powietrza. Trzeba mówić o pieniądzach.

Każdy komponent, którego ryzyko (a dokładniej wartość monetarna) przekracza pewien krytyczny poziom, powinien zostać zmieniony tak, aby zmniejszać prawdopodobieństwo wystąpienia ryzyka (np. podmiana komponentu na nowszy) lub redukować wpływ ryzyka (np. podzielenie komponentu na mniejsze). Zbiór takich zmian stanowi zakres projektu migracji, który powinien być zaplanowany.

Prawdziwym wyzwaniem nie jest jednak przeprowadzenie takich analiz na poszczególnych komponentach, lecz na całej architekturze IT w firmie. Daje się to jednak przeprowadzić, jeśli istnieje (lub zostanie zbudowany) odpowiedniej jakości opis architektury korporacyjnej, gdyż bazując na tych modelach można zastosować nieco bardziej zaawansowane narzędzia probabilistyki i analiz statystycznych, które w poprawny sposób agregują dane ryzyka. Bardzo ciekawymi pytaniami, na jakie analizy takie dają odpowiedzi są na przykład: jakim ryzykiem technicznym obciążone są w obecnej architekturze procesy obsługi klienta lub finansowe. Wyraz twarzy członków zarządów po takich prezentacjach – bezcenne.

Architektura korporacyjna (EA, Enterprise Architecture) jest najwłaściwszą kanwą dla snucia takich opowieści. Choć zwykle ograniczana do „projektowania systemów”, pozwala na przedstawianie aktywów IT z wielu punktów widzenia, także z perspektyw wartości biznesowej i związanego z nią nierozerwalnie ryzyka technologicznego. Co kluczowe, pozwala na przedstawianie zagadnień ryzyka bez konieczności „nurkowania” w szczegóły techniczne wyrażalne jedynie w hermetycznym języku, którego żaden członek zarządu nie chce „musieć rozumieć”.

Dla wyjaśnienia, jestem fanem pragmatyzmu i zagorzałym przeciwnikiem „marketingowego wyścigu zbrojeń” na technologie IT. Na szczęście między „COBOLem na terminalu tekstowym” a najnowszymi hasłami marketingowymi firm sprzedających technologię istnieje całkiem spora przestrzeń, którą można i należy odkrywać. Optymalne radzenie sobie z zagadnieniami ryzyka technologicznego stanowi ogromny, choć mocno niedoceniany wkład w wartość biznesową firmy.

Każda sfera działalności ludzkiej ma oczekiwane korzyści i ryzyko. Praktyka budowania uzasadnień biznesowych dla projektów IT wymagająca oparcia „przychodów” wyłącznie w korzyściach to taka bajka o istnieniu w przyrodzie korzyści bez ryzyka – samooszukiwanie się. Redukcja ekspozycji ryzyka, jest tak samo istotnym składnikiem budżetów firm, jak zdolność zwiększania przychodów, czy zmniejszania kosztów.

Pozostaw komentarz