Po kilku dekadach intensywnej informatyzacji przedsiębiorstw i instytucji realną barierą rozwoju ich biznesu staje się – w wielu przypadkach – zarządzanie tzw. długiem technologicznym, czyli nadmiernymi kosztami utrzymania i rozwoju wykorzystywanych rozwiązań informatycznych.
Twórcą pojęcia „dług technologiczny” jest Ward Cunningham, znany amerykański programista, „ojciec” otwartej internetowej platformy zarządzania informacją znanej jako „wiki” (wykorzystywanej choćby przez Wikipedię). Według niego, dług technologiczny powstaje wtedy, gdy zamiast poświęcić czas na zbudowanie dobrze zaprojektowanego, elastycznego rozwiązania, tworzymy je pospiesznie – byle taniej i szybciej.
Architektura rozwiązania źródłem długu technologicznego
Doraźnie czasem uzyskujemy korzyści, jednak stosunkowo szybko okazuje się, że koszty i czas modyfikacji niechlujnie lub bez niezbędnej jakości technologicznej zaprojektowanych rozwiązań szybko rosną. Ten zmarnowany czas i pieniądze, to właśnie „odsetki”, jakie organizacja płaci od zaciągniętego długu technologicznego. Źródłem tak rozumianego długu jest architektura rozwiązań, a sam dług pojawia się przede wszystkim w obszarze nadmiernych kosztów rozwoju i niskiej efektywności inwestycji.
Podobny efekt – wysokie koszty zmian i rozwoju – może powodować uzależnienie od dostawcy monopolizującego krytyczne dla organizacji rozwiązania. Niezależnie od jakości tych rozwiązań, taki monopol może prowadzić do nierynkowych wycen wynikających z „przewagi wiedzy” i „powiązań” dominującego wykonawcy. Każdy alternatywny dostawca musi bowiem wliczyć w rachunek istotne ryzyko – koszt zbudowania lub pozyskania „know how”. w celu osiągnięcia potencjału niezbędnego do skutecznego zastąpienia monopolisty.
Dług pierworodny spowodowany błędnym oszacowaniem kosztów
Kolejnym objawem długu są wysokie koszty utrzymania rozwiązań pogarszające efektywność procesów, które mają wspierać. Przyczyną fundamentalną są w tym przypadku błędy w formułowaniu zakresu i oszacowaniu kosztów posiadania wdrażanych rozwiązań (opłaty licencyjne, wsparcie użytkowników, szkolenia, usługi utrzymania, koszty zarządzania), a także błędy w administrowaniu inwestycją – szczególnie zarządzaniu wartością biznesową (business case) i zakresem przedsięwzięcia.
Dług technologiczny powstaje wtedy, gdy zamiast poświęcić czas na zbudowanie dobrze zaprojektowanego, elastycznego rozwiązania, tworzymy je pospiesznie – byle taniej i szybciej. Doraźnie czasem uzyskujemy korzyści, jednak stosunkowo szybko okazuje się, że koszty i czas modyfikacji niechlujnie lub bez niezbędnej jakości technologicznej zaprojektowanych rozwiązań szybko rosną. Ten zmarnowany czas i pieniądze, to właśnie „odsetki”, jakie organizacja płaci od zaciągniętego długu technologicznego.
W efekcie takich błędów pojawiają się różnorodne czynniki generujące dług technologiczny. Często pojawiające się przykłady to: automatyzacja procesów bez ich racjonalizacji lub w najlepszym przypadku optymalizacji, czy funkcje wspierające automatyzację/obsługę scenariuszy biznesowych o marginalnym znaczeniu, podwyższające istotnie całkowity koszt posiadania rozwiązania, a nie przyczyniające się do polepszenia procesów o najważniejszym znaczeniu. Innym przykładem może być brak elementów ładu niezbędnych do efektywnego wykorzystania rozwiązań, np. brak procesów zarządzania jakością informacji wspierających kluczowe systemy ewidencyjne (rejestry).
Tam gdzie jest dług, pojawiają się w naturalny sposób ci, którzy „żyją z odsetek”. W świecie finansów, dopóki odsetki są rynkowe, a umowy nie mają dziwnych klauzul utrudniających skorzystanie z lepszej oferty (np. poprzez konsolidację), tylko rozsądek klienta w sięganiu po kredyt decyduje o tym, jaki jest efekt jego działań. Podobnie, tam gdzie organizacja prowadzi rozsądną politykę w zakresie doboru dostawców technologii, usług i rozwiązań, poprzez korzystanie z mechanizmów rynkowych (tj. konkurencji dostawców, rozwiązań substytuty równoważne itp.), będzie ona zdolna do skutecznego kontrolowania „odsetek” – czyli kosztów utrzymania technologii i systematycznej modernizacji rozwiązań.
Rosnący technologiczny dług publiczny
Zagadnienie zarządzania długiem technologicznym ma obecnie szczególny wymiar w sektorze publicznym, z racji potężnego napływu środków unijnych konsumowanych w ramach rozlicznych programów, takich jak POIG (Program Operacyjny Innowacyjna Gospodarka) czy aktualnie planowany POPC (Program Operacyjny Polska Cyfrowa).
Retoryka stojąca u podstaw koncepcji „zintegrowanej informatyzacji” wydawała się świadczyć o tym, że jej twórcy są do pewnego stopnia świadomi zagrożeń rozwojowych, które – przy obfitości środków inwestycyjnych – wynikają ze skali i liczby równolegle prowadzonych projektów. W praktyce jednak próba realizacji tych idei nie doprowadziła do jasnej koncepcji modernizacji państwa, nadającej kształt programom operacyjnym, i nie stworzyła też procesu pozwalającego zarządzać bilansem kosztów utrzymania informatycznych systemów publicznych w relacji do korzyści dostarczanych dzięki ich wieloletniej eksploatacji. Tymczasem problem jest bardzo poważny.
Gdyby roczne koszty posiadania „infostruktury” powstałej za unijne miliardy szacować ostrożnie na 15% wartości inwestycji (co w zasadzie nie uwzględnia budżetu na istotny rozwój ich funkcjonalności), uzyskujemy kwotę astronomiczną w realiach polskiego budżetu. Tylko dla POIG tak oszacowany koszt może wynosić ponad 1 mld euro rocznie – bez uwzględnienia kosztów amortyzacji komputerów, licencji i innych środków trwałych. Oczywiście jest nadzieja, że zrealizowane inwestycje przyniosą rocznie korzyści, których wartość przewyższy ich koszty utrzymania i amortyzacji. Jeżeli nie, to środki na utrzymanie tych inwestycji – przynajmniej w okresie trwałości wymaganym przez UE – obciążą budżet.
Tam gdzie organizacja prowadzi rozsądną politykę w zakresie doboru dostawców technologii, usług i rozwiązań – poprzez korzystanie z mechanizmów rynkowych (tj. konkurencji dostawców, rozwiązań substytuty równoważne itp.) – będzie ona zdolna do skutecznego kontrolowania „odsetek” długu technologicznego – czyli kosztów utrzymania technologii i systematycznej modernizacji rozwiązań.
Naturalnie są w tym obszarze instytucje działające bardzo świadomie, realizujące długofalową politykę biorącą pod uwagę efektywność i efekt biznesowy. Jako przykłady zasługujące na osobne studium przypadku można wskazać choćby program transformacji Zakładu Ubezpieczeń Społecznych, działania Ministerstwa Gospodarki, których wynikiem są usługi CEIDG, czy program informatyzacji realizowany przez Główny Urząd Geodezji i Kartografii.
Powracająca Zosia Samosia
Z tego punktu warto ocenić powracające co jakiś czas pomysły na realizację projektów przez administrację. Pojawia się również narracja, która problemy informatyzacji wiąże z faktem zaangażowania w projekty dostawców komercyjnych, a poprawę skuteczności i efektywności procesu informatyzacji państwa widzi w odwróceniu się od przemysłu IT i zastąpieniu go resortowymi i międzyresortowymi ośrodkami informatyzacji. Takie myślenie znajdziemy w opiniach części polityków, a nawet w materiałach dyskutowanych na konferencjach programowych czołowych ugrupowań.
Warto przypomnieć, że pomysły te – po trwającym dłużej lub krócej „okresie miodowym”, kiedy hołubione są przez swoich politycznych promotorów, nieuchronnie kończą się tak samo. Przy braku standardów w zakresie zarządzania efektywnością usług i projektów, przy specyfice systemów motywacyjnych i decyzyjnych w administracji, rezygnacja z rynkowych mechanizmów realizacji inwestycji przynosi decydentom wcześniej czy później problemy. „Ośrodki informatyzacji” stają się kolejnymi monopolistami, sterowanymi mechanizmami polityki i biurokracji. Prowadzą czasem wieloletnie „życie po życiu”, konsumując środki publiczne, podczas gdy próbuje się je konsolidować, restrukturyzować, a nawet prywatyzować. Koniec końców stanowią jednak zwykle specyficzny – strukturalny – składnik długu technologicznego.
Insourcing – w skali jakiej wymagają programy, takie jak POIG czy POPC – realizowany przez jednostki administracji publicznej – nie rozwiązuje żadnego z problemów związanych z długiem technologicznym. Przy brakach w procesach zarządzania/ładu to przede wszystkim rezygnacja z rynkowych narzędzi pozwalających uniknąć źródła długu, jakim jest monopol dostawcy. Głównym wyzwaniem i obszarem koniecznej budowy kompetencji dla programów modernizacji państwa z wykorzystaniem informatyki jest bowiem tworzenie racjonalnych koncepcji modernizacji oraz proces zarządzania korzyściami i ryzykiem. W tym także zarządzanie długiem, który może te korzyści niweczyć.
Odpowiedzią na te wyzwania z pewnością nie jest zastępowanie przemysłu IT w obszarze, w którym – jak pokazują doświadczenia z wielu sektorów gospodarki – radzi sobie skutecznie i efektywnie.
Borys Stokalski jest prezesem Infovide-Matrix SA.
Przykłady czynników generujących dług technologiczny:- · automatyzacja procesów bez ich racjonalizacji lub w najlepszym przypadku optymalizacji,
- · funkcje wspierające automatyzację/obsługę scenariuszy biznesowych o marginalnym znaczeniu, podwyższające istotnie całkowity koszt posiadania rozwiązania, a nie przyczyniające się do polepszenia procesów o najważniejszym znaczeniu,
- · brak elementów ładu niezbędnych do efektywnego wykorzystania rozwiązań, np. brak procesów zarządzania jakością informacji wspierających kluczowe systemy ewidencyjne (rejestry).
