W poprzednim wpisie opisałem mniej znaną formę korupcji dotyczącą odbioru systemów informatycznych w sektorze publicznym. Korupcja w fazie wyboru dostawcy powoduje mniejsze szkody niż korupcja w fazie odbioru systemu. Skala działań korupcyjnych zależy od jakości opisu specyfikacji funkcjonalnej systemu. Im gorsza specyfikacja tym większa przestrzeń do korupcji i niższa jakość gotowego systemu.
W drugiej części przedstawiam propozycję rozwiązania systemowego, które ograniczyłoby opisane patologie. Najpierw krótkie wprowadzenie do metodyki projektowej.
Jak ocenić jakość wdrożenia systemu informatycznego?
Duże systemy informatyczne wdrażane są według metodyki zarządzania projektami (project management). Cel projektu określa się za pomocą trzech elementów:
- opisu funkcjonalności gotowego systemu (tj. specyfikacji funkcjonalnej)
- czasu budowy systemu i jego wdrożenia (tj. harmonogramu)
- kosztów budowy systemu
Sposób wdrożenia systemu nie ma większego znaczenia dla odbiorcy. Jeśli system zostanie zbudowany zgodnie ze specyfikacją w przewidzianym czasie i w ramach założonych kosztów, to taki projekt jest sukcesem a odbiorca nie ma podstawy do wnoszenia zastrzeżeń.
Często zdarza się, że harmonogram lub koszty projektu zostają przekroczone, co może utrudnić osiągnięcie założonych celów biznesowych w planowanym czasie.
Zmiana specyfikacji jest poważnym problemem wewnątrzprojektowym. We wszystkich metodykach zarządzania projektami zmiana specyfikacji musi być wykonana poprzez formalny proces zarządzania zmianami z udziałem dostawcy i odbiorcy. Procedura wprowadzenia zmiany jest zwykle zawarta w umowie. Do zmienionej specyfikacji dostosowuje się harmonogram i koszty.
Pierwotna specyfikacja systemu i aneksy z uzgodnionymi zmianami stanowią jedyny punkt odniesienia, na który może się powołać dostawca lub odbiorca w przypadku wystąpienia nieporozumień dotyczących ostatecznej funkcjonalności systemu.
Dwa niezależne projekty
Jeżeli zgodzimy się z diagnozą, że słaba specyfikacja jest głównym powodem korupcji w fazie odbioru oraz istotną przyczyną niepowodzeń w realizacji projektów informatycznych, to można oczekiwać, że mechanizmy wymuszające tworzenie dobrych specyfikacji zmniejszą te patologie.
Potrzebne jest prawo, które w sektorze publicznym wymusi rozbicie wszystkich dużych projektów informatycznych na dwa niezależne projekty. Celem pierwszego projektu byłoby przygotowanie specyfikacji funkcjonalnej systemu a celem drugiego zbudowanie systemu zgodnie z tą specyfikacją.
Projekt przygotowania specyfikacji
Urząd planujący komputeryzację ogłasza przetarg na utworzenie specyfikacji funkcjonalnej systemu informatycznego. Przetarg powinien wyłonić co najmniej dwóch dostawców.
Komputeryzacja to kulturowa i organizacyjna rewolucja z wieloma nieprzewidywalnymi skutkami ubocznymi. Cel biznesowy można osiągać różnymi sposobami. Wiele specyfikacji to wiele oryginalnych rozwiązań prowadzących do tego samego celu. Każda złotówka zainwestowana w specyfikację zwróci się wielokrotnie, stąd warto zamówić specyfikacje od kilku firm. Co więcej, koszty wdrożenia i utrzymania systemów zbudowanych według różnych specyfikacji ale realizujących te same cele biznesowe mogą się różnić wielokrotnie!
Po zakończeniu projektu specyfikacji osoba odpowiedzialna za zakup systemu powinna pisemnie uzasadnić, dlaczego wybiera tą a nie inną specyfikację i podpisać oświadczenie, że według jej oceny specyfikacja jednoznacznie opisuje funkcjonalność przyszłego systemu. Przygotowanie specyfikacji poprzez odrębny projekt zapewnia wiele korzyści:
- zmusza zamawiającego do gruntownego przemyślenia swoich potrzeb i spodziewanych korzyści z informatyzacji (zamawiający będzie musiał odpowiedzieć na wiele inspirujących pytań zadawanych przez konsultantów przygotowujących specyfikacje)
- uzyskujemy szczegółową i precyzyjną specyfikacje systemu
- umożliwia zewnętrzną kontrolę procesu informatyzacji na poziomie projektu i nadaje jej czytelną racjonalność. Dobra specyfikacja i podpisane oświadczenie o jakości specyfikacji są doskonałym punktem wyjścia dla pracy instytucji kontrolnych.
Jeśli specyfikację będą tworzyć renomowane firmy konsultingowe, to urzędy państwowe uzyskają również dostęp do sprawdzonych rozwiązań z innych krajów. Jest to najtańszy sposób transferu nowoczesnych rozwiązań informatycznych do polskiego sektora publicznego.
Budowa systemu na podstawie gotowej specyfikacji
Profesjonalna specyfikacja zawęża pole do działań pozaprawnych, ułatwia ułożenie realistycznego harmonogramu i umożliwia precyzyjne określenie kosztów.
Przetarg na budowę i wdrożenie systemu byłby niezależny od przetargu na utworzenie specyfikacji. Jeśli mamy gotową specyfikację systemu, to wybór dostawcy systemu powinien się opierać tylko na dwóch kryteriach: ceny i czasu realizacji. Jest to najbardziej racjonalne podejście, bo do zdefiniowania celu projektu potrzebujemy tylko specyfikacji, harmonogramu i kosztów. Przy takich kryteriach wyboru oferty nie ma miejsca na korupcję.
Zaproponowane rozwiązanie ukróciłoby także powszechną w Polsce praktykę wygrywania przetargów najniższą ceną, która poprzez aneksy w trakcie wdrożenia jest podwyższana do wielkości przekraczającej najdroższą ofertę. Aneksy nie wzbogacają funkcjonalności systemu, ale ją... uszczegóławiają. Tak było z CEPiKiem. Wygrał Softbank z najniższą ceną a po różnych aneksach koszt systemu przerósł cenę najdroższej oferty.
