Zastanówmy się teraz co się dzieje w przedsięwzięciu, które nie idzie tak jakby zamawiający sobie tego życzył. Weźmy jeden, prosty, lecz jakże częsty przykład, kiedy to wykonawca żąda od zamawiającego zatwierdzenia szczegółowej specyfikacji wymagań całego systemu, grożąc z jednej strony, że jeśli nie zrobi się tego już teraz, to trzeba się będzie liczyć z opóźnieniem, a z drugiej mówiąc, że każda zmiana wprowadzona do już zatwierdzonych wymagań będzie oznaczała zmianę zakresu projektu, a tym samym podstawę do renegocjacji terminów i budżetu(1).

Może dorzućmy do tego jeszcze trochę pikanterii. Niech to będzie projekt finansowany ze środków PHARE. Jeśli się nie skończy w terminie, PHARE cofnie dotację. Jeśli zamawiający zdecyduje się na wystąpienie o wydłużenie czasu trwania projektu, co wcale nie jest takie łatwe, będzie musiał przyznać się do złego skalkulowania przedsięwzięcia. A to też takie proste nie jest.

Wyzwań tego typu w każdym projekcie można znaleźć wiele, a ich rozwiązywanie to dodatkowy, ukryty koszt przedsięwzięcia. Dlaczego pracownicy zamawiającego, którzy powinni zajmować się czymś, co przynosi wartość, muszą skupiać się na zagadnieniach, które nie powinny ich w ogóle interesować? Dlaczego zamawiający musi stawać przed tak złożonymi dylematami? Dlaczego musi zastanawiać się, jak nie ulegać szantażowi producenta? Dlaczego musi godzić się na kompromisy? Przyczyn tych wszystkich problemów upatruję w monopolu, jaki zamawiający sam funduje dostawcy, dokonując jego namaszczenia podczas obrad komisji przetargowej. Ale do diabła, wina nie musi leżeć ani po stronie producenta, ani po stronie zamawiającego.

Na początku projektu każda ze stron kontraktu stoi przed taką samą niewiadomą i każda ma swoje cele do osiągnięcia. Część z tych celów niestety jest sprzeczna, więc każdy ciągnie w swoją stronę. Im więcej czasu upłynie w projekcie i im więcej środków zostanie przekazanych producentowi, tym silniejsza staje się jego pozycja. Bo czyż łatwo jest zerwać kontrakt, nawet taki, który wydaje się najgorszym koszmarem? A czy z kolejnym wygranym poszłoby lepiej? Fundusze już zainwestowane może i dałoby się w jakiejś części odzyskać, chociaż i w to wątpię, ale co z czasem, który już minął bezpowrotnie?

Wróćmy więc do tezy podstawowej. Administracji publicznej potrzebne są nie projekty, ale produkty!

Rewolucja

Administracja publiczna nie zawsze musi angażować się w produkcję oprogramowania, którego potrzebuje, zaś którego nie wymyślił dotychczas marketing żadnej z firm programistycznych. Tam, gdzie odbiorców aplikacji jest odpowiednio dużo (np. na poziomie samorządów gminnych lub powiatowych), można kreować konkurencyjne rynki zbytu dla produktów informatycznych. Aby jednak nie dopuścić do wypaczenia procesów realizowanych przez jednostki, do których oprogramowanie się adresuje, i by zapewnić odpowiednią przydatność aplikacji, należy zachować pewną kontrolę nad tymi rynkami zbytu. Kontrolę tę można sprawować przez homologację systemów informatycznych.

Podejście takie jest stosowane obecnie przez dwa ministerstwa: Ministerstwo Polityki Społecznej oraz Ministerstwo Gospodarki i Pracy, które jeszcze do niedawna stanowiły jeden organizm. Idea i doświadczenia mają więc jedno źródło, a historia kilku lat zmagań z homologacją pokazuje, że jest to nie najgorsza alternatywa dla tradycyjnych projektów outsourcingowych. W końcu zeszłego roku Polskie Towarzystwo Informatyczne wydało kolejną już pracę zbiorową "Informatyka w polityce społecznej"(2), w której znalazły się trzy artykuły poświęcone zagadnieniu homologacji systemów informatycznych. Dwa spośród nich, Krystyny Mierzwińskiej i Tomasza Jeruzalskiego, opisują historię i dzień dzisiejszy homologacji w konkretnych przypadkach i są doskonałym źródłem informacji o tym, jak to się robi w praktyce. Trzeci artykuł, który wyszedł spod mojego pióra, stanowi próbę uogólnienia zjawiska.

Nie sposób streścić w kilku słowach całości ww. materiałów, tak że wszystkich zainteresowanych pozwolę sobie odesłać do źródła. W artykule mojego autorstwa przedstawiam dokładniej, dlaczego dla administracji publicznej lepiej jest kupować systemy IT niż je budować, dokonuję analizy porównawczej pięciu różnych, możliwych, metod nabywania oprogramowania przez jednostki administracji publicznej i dokonuję rozbioru SWOT samej homologacji.

Z technicznego punktu widzenia, o jakim piszą Krystyna Mierzwińska i Tomasz Jeruzalski, homologacja jest procesem weryfikacji oprogramowania na okoliczność zgodności z konkretną wersją wymagań homologacyjnych, którą to zgodność potwierdza się świadectwem homologacji dla konkretnej wersji produktu. Jest to prawda, która została zdefiniowana również w sposób formalny, w drodze rozporządzenia(3). Z mojego punktu widzenia jest to jednak coś o wiele bardziej doniosłego: homologacja systemów informatycznych jest sposobem nabywania oprogramowania dedykowanego na zasadach rynkowych. I to jest rewolucja.

Postscriptum

O homologacji systemów informatycznych opowiadał podczas konferencji Computerworld "Państwo w mikro- i makroskali" Zbigniew Olejniczak, dyrektor Departamentu Informatyki MGiP. Po jego wystąpieniu podniósł się z sali jeden głos, osoby, której bardzo zależało na tym, aby wszyscy dobrze słyszeli co ma do powiedzenia, mimo że prowadzący nie zdążył podać jeszcze mikrofonu, a może nawet w związku z lekkim opóźnieniem, nie chciał już dopuścić do rozwinięcia dyskusji. Osoba ta powiedziała coś, co mniej więcej zabrzmiało tak: "Mam tylko jedno zastrzeżenie - to jest niezgodne z prawem!". Nie zdążyłem odnotować, z czyich ust padła ta opinia, jednak zaryzykuję stwierdzenie, że wiem dlaczego w ogóle została wypowiedziana. Każda rewolucja występuje przeciwko pewnemu status quo ante, a więc niewątpliwie przeciwko temu, co przez niektórych jest postrzegane jako korzystne. Rewolucja budzi strach.

Robert Ganowski jest analitykiem systemowym w firmie Metoda sp. z o.o.

(1) Tu akurat błąd popełniają sami zamawiający już na etapie formułowania SIWZ, narzucając wykonawcom wodospadowy sposób realizacji projektu. To jest korzystne dla producenta, ponieważ podejście wodospadowe jest pojęciowo o wiele prostsze niż podejście iteracyjne. Dodatkowo też, tym razem on, producent, zyskuje alibi: "nie udało się, bo zamawiający narzucił taki tryb pracy".

(2) "Informatyka w polityce społecznej", red. Zbigniew Olejniczak i Jerzy S. Nowak, PTI, Warszawa 2004, ISBN 83-920406-2-7.

(3) Rozporządzenie Ministra Gospodarki i Pracy z dnia 30 sierpnia 2004 r. w sprawie homologacji systemów informatycznych stosowanych w urzędach pracy; DzU nr 204, poz. 2085 (§3).