Z Borysem Stokalskim, prezesem firmy InfoVIDE, rozmawia Dorota Konowrocka.

W swoich artykułach wielokrotnie poruszał Pan temat analizy opłacalności przedsięwzięć informatycznych. Czy jesteśmy choć o krok bliżej możliwości przedstawienia w liczbach korzyści wynikających z wdrożenia systemu informatycznego?

Ogólne techniki analizy zwrotu z inwestycji są od dawna dobrze znane. Szczególnym przypadkiem analizy zwrotu w inwestycje w technologie informatyczne zajmuje się m.in. Paul Strassmann. Uzasadniając swoje zainteresowanie tym tematem Strassmann opowiada od lat tą samą historyjkę. W latach 70-tych był szefem informatyki w Xeroxie. Firma przeżywała wówczas pewne kłopoty i starała się ograniczać koszty, a on na posiedzenie zarządu przyszedł z pomysłem zwiększenia nakładów na informatykę. Wtedy zrozumiał, że istnieje ogromna bariera między ludźmi, którzy fascynują się technologią dla samej technologii, a ludźmi, którzy zmuszani są do jej finansowania. Dzięki temu doświadczeniu Strassmann zaczął bardziej konserwatywnie myśleć o inwestycjach w informatykę. Jego wydana w 1990 roku Business Value of Computers jest nadal bardzo aktualną i wartą lektury pozycją.

Wydaje się jednak, że potrzeba głębszej analizy tematu pojawiła się tak naprawdę dopiero teraz. Wiele organizacji nasyconych jest już informatyką, wydatki na nią w ubiegłych latach cały czas rosły. W erze nowej gospodarki wydaje się, że nie inwestowanie w informatykę oznacza utratę konkurencyjności, ale przedsiębiorstwa po prostu przestają mieć na to pieniądze i poszukują narzędzi racjonalizacji swoich inwestycji w IT.

Podstawowym narzędziem racjonalizacji jest spojrzenie na proces informatyzacji rzeczywiście jak na inwestycję, czyli poniesienie pewnych nakładów finansowych i organizacyjnych w celu osiągnięcia w przyszłości przewyższających je zysków.

Dlatego można powiedzieć, że rzeczywiście jesteśmy o krok bliżej możliwości przedstawienia korzyści z informatyki w wartościach liczbowych, ponieważ temat stał się naprawdę interesujący dla użytkowników informatyki. Dziś zaczynają się prawdziwe poszukiwania nowych narzędzi analizy tego rodzaju inwestycji.

Czy więc analiza inwestycji w informatykę wymaga podejścia innego niż analiza inwestycji w nieruchomości?

Pewnego rodzaju inwestycje informatyczne nie wymagają innego podejścia, zwłaszcza te, których przedmiotem jest realizacja systemu, który będzie funkcjonował latami, spełniając cały czas podobne funkcje w podobny sposób. Przykładem takich systemów mogą być systemy finansowo-księgowe czy wiele systemów w administracji państwowej. Wydaje się, że do takiej inwestycji można podchodzić jak do budowy domu czy mostu.

Informatyka ma jednak to do siebie, że raz wytworzony produkt często podlega zmianom, szczególnie w obszarach, gdzie taka zmienność wymuszona jest przez rynek. Dobrym przykładem takiego obszaru jest bankowość internetowa. W tej chwili w Polsce funkcjonuje kilka takich banków, konkurujących ze sobą przede wszystkim ofertą dla klienta, a więc produktem informatycznym. W ich przypadku w pewnym stopniu produkt oferowany klientowi można utożsamić z kryjącym się za nim systemem informatycznym. Jednocześnie system ten nie jest źródłem przewagi konkurencyjnej, ponieważ prawdopodobnie w ciągu 6 miesięcy konkurencja może każdy z tych systemów skopiować i udoskonalić, drastycznie skracając cykl inwestycji informatycznej jego posiadacza. Informatyzacja tych obszarów wymusza więc hiperkonkurencyjność i konieczność dalszego inwestowania.

Ale czy to oznacza, że nadal stoimy w punkcie wyjścia? Nie próbujmy mierzyć inwestycji w informatykę, bo i tak nie jesteśmy w stanie z nich zrezygnować ze względu na konieczność konkurowania na rynkach nasyconych technologiami informatycznymi?

Nie, to oznacza, że trzeba mieć świadomość, że w przypadku wielu inwestycji informatycznych cykl życia produktu, a więc również okres zwrotu, jest bardzo krótki. Z drugiej strony warto pamiętać, że wdrażany system informatyczny zawiera nie tylko elementy, które jesteśmy w stanie zaoferować czy wykorzystać od razu, ale również pewne opcje. Jak należy rozumieć pojęcie opcji? Gdy mBank przyciągnie 150 tys. klientów, może próbować wykorzystać ten potencjał, wychodząc poza wcześniej oferowane produkty czy usługi. Powstaje pytanie, czy umiemy zmierzyć to, czego jeszcze nie ma, ale co może powstać? Dysponujemy dziś takimi mechanizmami, określanymi jako Real Options Valuation, bazującymi na tych samych technikach wyceny, które stosowane są do wyceny walorów spółek giełdowych. Dążymy do określenia całkowitej, obecnej i przyszłej wartości inwestycji informatycznej, określenia opcji, jakie w sobie kryje. Budując system z wykorzystaniem korporacyjnej architektury aplikacji będziemy ponosić niższe koszty tworzenia nowych elektronicznych kanałów dystrybucji. Każdy kanał to potencjalny przychód i określone ryzyko. Nie decydując się na korporacyjną architekturę aplikacji uzyskamy dziś wyższy zwrot z inwestycji, poniesiemy niższe jej koszty, ale jednocześnie nasze opcje będą miały niższą wartość. Real Options Valuation jest próbą zastosowania mierzalnym kryteriów oceny w miejsce machania rękami. Próbujemy zdefiniować, co w zdaniu "ten system jest drogi, ale w przyszłości będziemy mogli coś z nim zrobić" oznaczają słowa "przyszłość" i "coś".

Czy mają sens próby określenia ogólnych zasad dotyczących rozsądnego poziomu inwestycji w informatykę? Budując na przykład analogię do teorii, że wydatki marketingowe przedsiębiorstwa powinny stanowić określony procent jego przychodów?

W tak prosty sposób z pewnością nie da się tego policzyć. Co więcej, myślenie w ten sposób o marketingu również jest fikcją. Firma zajmująca się wprowadzaniem na rynek regularnych innowacji musi mieć zupełnie inne koszty marketingowe niż firma, która wyłącznie wykorzystuje potencjał schodzących rynków, których kreowaniem zajmuje się kto inny.

Paul Strassmann przez wiele lat zajmował się badaniem w przedsiębiorstwach stosunku nakładów na informatykę na głowę pracownika do wyników ekonomicznych firmy, poszukując zależności między intensywnością inwestowania w informatykę i zyskownością. Z jego badań wynika, że taka korelacja nie istnieje. Strassmann stwierdził więc, że w gruncie rzeczy informatyka warta jest dziś tyle, na ile wspiera kierownictwo firmy.

Rozpoczęciu projektu informatycznego wielokrotnie nie towarzyszy zdefiniowanie żadnych mierzalnych kryteriów jego sukcesu lub klęski. Jakie są najlepsze praktyki określania tego rodzaju wskaźników?

Instrumentarium finansowe jest tu proste i dobrze znane, mamy narzędzia takie jak NPV (Net Present Value) i ROV (Real Options Valuation). Można również mówić o całej sferze kosztowej, a więc w jaki sposób wdrożenie nowego systemu zmienia strukturę kosztów utrzymania całości systemów informatycznych i czy zyski z tego tytułu przewyższają koszty wdrożenia, z czym wiążę się pojęcie TCO (Total Cost of Ownership - całkowity koszt posiadania). Metody te są podstawą usług świadczonych przez Infovide w ramach programu ValueIT.

Istnieje również szerszy kontekst. Wiele projektów przyzwyczailiśmy się traktować jako udane, gdy zmieściły się w założonym harmonogramie, założonych kosztach i założonym zakresie. Jeśli popatrzymy na branżę IT z tego punktu widzenia, okaże się, że jest ona w kiepskim stanie i trudno zauważyć w ostatnich latach jakąkolwiek poprawę. Zaledwie kilkanaście procent realizowanych projektów mieści w założonych ramach czasowych i kosztowych, a cała reszta to albo kompletne niepowodzenia, albo projekty, które na przykład drastycznie przekroczyły budżet. Wszystkie dane benchmarkingowe, czyli dotyczące dobrych praktyk, odnoszą się do tego właśnie modelu sukcesu projektu. Przeciwnicy tego rodzaju podejścia argumentują, że można wskazać wiele projektów zrealizowanych zgodnie z ustalonym harmonogramem, budżetem i zakresem, które były kompletnym nonsensem ekonomicznym. Można również wskazać wiele projektów, które przekroczyły harmonogram i budżet, ale jednocześnie były bardzo udanymi przedsięwzięciami z punktu widzenia organizacji i fantastyczną przygodą dla ludzi, którzy je realizowali. Jestem w tej branży już kilka lat i, prawdę mówiąc, trudno mi się z takim podejściem nie zgodzić. Branie pod uwagę tylko tych trzech aspektów projektów informatycznych prowadzi do trzymania się za wszelką cenę pierwotnego planu, który z biegiem czasu stracił już sens. Z drugiej strony zespół realizujący projekt może być związany umową czy warunkami zamówienia publicznego.

Czy w ten sposób nie dojdziemy do usprawiedliwiania rozmywających się z czasem założeń projektu i nieudolności realizatorów "zdobywaniem doświadczenia"?

Dojdziemy, jeśli nie będziemy mieli nic w zamian. Całkowite odrzucanie tradycyjnych zasad realizacji projektów informatycznych jest nierozsądne, bo rzeczywiście nadal istnieje sporo projektów, które po prostu trzeba dobrze zaplanować, a później zrealizować. Wydaje się jednak, że pojawia się dziś kilka propozycji alternatywnych, zgrupowanych po hasłami Agile Manifesto. Jest to strona internetowa będąca manifestem twórców tzw. lekkich metodologii, alternatywnych podejść do realizacji systemów informatycznych. Wszystkie one ukierunkowane są na proces tworzenia systemów, w którym zmiana jest normą, pożądaną cechą projektu. Zgodnie z tymi metodologiami dobrze prowadzony projekt powinien umożliwiać absorbowanie zmian. W tym nurcie mieści się propozycja Jima Highsmitha - Adaptive Software Development, mająca zastosowanie w przypadku dużych projektów, w tym nurcie mieści się również Extreme Programming, metodologia popularyzowana przez Jakuba Chabika. Sądzę, że ten ruch alternatywny wniesie istotne zmiany do tego, jak buduje się systemy informatyczne. Dlatego zresztą współpracujemy z Jimem Highsmithem, który niedawno uczył kierowników projektów Infovide zarządzania adaptacyjnego.

Czy w tym momencie nie należałoby więc porzucić pojęcia projektu informatycznego na rzecz nieograniczonego czasowo, podlegającego stałym zmianom procesu informatyzacji?

Nie, zadanie polega na tym, by realizując projekty informatyczne cały czas przyjmować punkt widzenia inwestora i użytkownika. Przyjrzyjmy się temu, jak rozwijają się portale. od początku mają pewną podstawową infrastrukturę informatyczną, związaną z podstawowym zakresem usług - pocztą elektroniczną, chatami, katalogiem. Za nimi następują pewne struktury wertykalne - Moje Finanse, Moje Wiadomości, Mój Małysz czy cokolwiek innego. Mój Małysz to produkt na jeden sezon. W ciągu tego sezonu trzeba wykorzystać cały jego potencjał, przyciągając na strony internetowe portalu miliony internautów. I właśnie na Mojego Małysza trzeba spojrzeć jak na krótkoterminową inwestycję, projekt w ramach szerzej zakrojonej wizji portalu. Tworzący Mojego Małysza zespół programistów musi być bardzo szybki i elastyczny, a jednocześnie inwestorzy muszą być świadomi, że w pewnym momencie utracą cały przychód z tego tytułu, bo sezon się skończy. Odpowiedzią jest więc stosowanie znanych metodologii czasu, budżetu i zakresu, ale w ramach krótkich inwestycji o dobrze zdefiniowanych ramach czasowych. Nowe, lekkie metodologie zakładają również, że co dwa tygodnie klient dostaje nowy fragment funkcjonalności swojego systemu, który naprawdę działa i naprawdę można go używać. Tego wielu dostawców systemów informatycznych nie jest w stanie dziś zapewnić swoim klientom ani nawet nie wie, jak to zrobić. W tej chwili pierwsze efekty pracy programistów dostępne są dla klienta w czasie, który z jego punktu widzenia jest wiecznością. Jak stwierdził ktoś żartobliwie, Extreme Programming jest metodologią, która pozwala osiągnąć nirwanę w zakresie tworzenia aplikacji - co dwa tygodnie zespół projektowy jest trochę przemęczony, a klient trochę niezadowolony.

Czy biorąc pod uwagę powyższe rozważania, można określić przyczyny mniejszych i większych niepowodzeń projektów realizowanych w sektorze publicznym?

Jedna z przyczyn jest znana od dawna. Większość systemów powstających w administracji powstaje na gruncie niestabilnego prawa. Zespoły realizujące te projekty zawsze maja do czynienia z dwiema warstwami: czysto techniczną, związana z bieżącym zarządzaniem zespołem, modelowaniem, konstruowaniem, testowaniem aplikacji; oraz warstwą polityczną, gdzie wchodzą w grę decyzje polityczne w dobrym i złym tego słowa znaczeniu. To sprawia, że fundament tych projektów jest dość niestabilny.

Z drugiej strony dostawca systemów informatycznych dla administracji państwowej działa zawsze w ramach nienaruszalnej umowy i wszyscy oczekują, że będzie ona dokładnie tak realizowana, jak została podpisana. Dla obu stron projektu - dostawcy i klienta - jest to dramat. Dostawca czuje, że robi coś, co w obecnych warunkach może nie mieć już sensu, ale nie może podjąć decyzji o wprowadzeniu zmian. Po drugiej stronie siedzi urzędnik, który być może również ma świadomość konieczności wprowadzenia zmian w projekcie, ale wie, że każda zmiana w umowie wykraczająca poza ustawę o zamówieniach publicznych jest jego osobistym ryzykiem. Wszystkie inwestycje informatyczne na wielką skalę będą wyzwaniem dla wszystkich stron projektu tak długo, jak długo nie będzie dobrych mechanizmów zarządzania zmianą w tych projektach, i jak długo po stronie zamawiającego nie będzie odpowiednich struktur, które są w stanie zarządzać tymi projektami w zakresie definiowania wymagań. W interesujący sposób problem ten usiłuje rozwiązać GUC, który w swojej strategii informatyzacji przewiduje fundusz na ryzyko, związane z płynnością zakresu wymagań i koniecznością wprowadzania zmian. Staje jednak w obliczu problemów natury formalnej, ponieważ budżet państwa nie przewiduje ryzyka. Projekt informatyczny zawsze jednak wiąże się z jakimś ryzykiem, a ignorowanie tego faktu jest ignorowaniem prawa grawitacji. Remedium na problemy informatyzacji administracji publicznej może być przegląd ustawy o zamówieniach publicznych pod kątem mechanizmów umożliwiających zarządzanie zmianami.

Uważa Pan również, że poprawa jakości realizacji projektów informatycznych w sektorze publicznym mogłaby być efektem powstania tzw. Białej Księgi Rejestrów Państwowych. Czy mógłby Pan wyjaśnić jej ideę?

Andrzej Florczyk, szef zespołu informatyki wyborczej, pokazał mi kiedyś dokument przygotowany przez amerykański Departament Stanu dla tamtejszego biura wyborczego, i udostępniony publicznie. Była to dokumentacja amerykańskiego systemu wyborczego w postaci diagramów, modeli i opisów, dokładnie przedstawiających schemat działania systemu. Taki dokument nie został stworzony dla żadnego systemu funkcjonującego w polskiej administracji publicznej. Istnieje wiele dużych projektów informatycznych wymagających użycia danych pochodzących z rejestrów takich jak PESEL czy KEP. Kiedy próbuje się je wykorzystać, okazuje się, że są niespójne, część informacji ma fatalną jakość i nie ma możliwości ich wykorzystania zgodnie z zamierzeniami projektanta systemu. Nigdzie nie znajdziemy informacji na temat jakości tych danych, ich struktury, cyklu, w którym dane te ulegają zmianom. Dostępność takiego rodzaju informacji jest kluczowa dla oferentów startujących w przetargach na takie systemy jak KSI ZUS, a potem również dla architektów, którzy systemy te projektują. Warto więc byłoby udokumentować zawartość informacyjną podstawowych rejestrów mających największe znaczenie w gospodarce: PESEL, Krajowej Ewidencji Podatników, REGON, Krajowych Rejestrów Sądowych i Krajowego Rejestru Wyborców.

W 1998 roku departament łączności MSWiA, wystąpił z propozycją, by MSWiA opiniowała każdą inwestycję informatyczną realizowaną w administracji państwowej. Propozycja padła ze strony osób, których dobrych intencje, kwalifikacje merytoryczne i etyka zawodowa są dla mnie niewątpliwe. Gdyby jednak taka biurokratyczna procedura trafiła kiedyś w ręce ludzi nieodpowiedzialnych, mogłaby się stać korupcjogenna, i jednocześnie spowolniłaby realizację inwestycji informatycznych w administracji publicznej. Koncepcja Białej Księgi jest inna: ujawnijmy, jak wyglądają rejestry. W ten sposób każda firma, która ma zamiar prowadzić projekty w administracji publicznej, będzie miał punkt odniesienia. Biała Księga byłaby dostępna dla wszystkich, może na przykład poprzez jej publikację w Internecie. Kto jednak miałby się zająć realizacją takiego projektu "inwentaryzacyjnego"? Administracja zapewne nie ma dziś budżetu na zatrudnienie zewnętrznej firmy konsultingowej, może jednak zrobić to siłami pracowników własnych zespołów informatycznych, pracujących pod kierownictwem kilku doświadczonych konsultantów firmy zewnętrznej.

Być może powstaje tu jednak problem wykraczający poza kwestie finansowe. Rejestry państwowe należą dziś do poszczególnych resortów, które "sprawują nad nimi władzę". Próba uczynienia tych rejestrów własnością wspólną wymaga na pewno dobrowolnej zgody tych resortów na oddanie tej władzy. Ale jeśli mówimy dziś o e-Polsce, o jakichkolwiek strategiach informatyzacji państwa polskiego, nie można uciekać od takich tematów.