Korupcja to potajemne wręczanie korzyści majątkowych aby wywrzeć wpływ na decyzję urzędnika. W przypadku projektów informatycznych korupcja związana z wyborem dostawcy nie jest głównym źródłem problemów. Wybór potajemnie faworyzowanego, choć gorszego dostawcy tylko w niewielkim stopniu wpływa na niską jakość dostarczonego systemu.
W projektach informatycznych największym zagrożeniem jest korupcja związana z odbiorem systemu. To od odbiorcy zależy jakość systemu, jego funkcje i niezawodność. Odbiorca akceptuje system na podstawie specyfikacji funkcjonalnej zdefiniowanej w umowie. Problem w tym, że w Polsce specyfikacje systemów zamawianych przez urzędników są nieprecyzyjne i niespójne. Umowa na system KSI ZUS była podpisana z Prokomem przez p. Bańkowską jeszcze przed uchwaleniem ustawy o ubezpieczeniach czyli w momencie, kiedy nie było wiadomo co taki system miałby robić.
Specyfikacja funkcjonalna systemu jest jego definicją, czyli jedynym punktem odniesienia w przypadku sporów dotyczących ostatecznego kształtu systemu.
Odbiór systemów informatycznych w praktyce
Jeżeli zamawiany jest system jedyny w swoim rodzaju (CEPIK, POLTAX etc.), to w pewnym momencie trzeba go przetestować i formalnie odebrać. Ale jak określić zakres testów, jeżeli umowa zawiera tylko szczątkowy opis funkcjonalności systemu.
Czy dana funkcja użytkowa w dostarczonym systemie odpowiada oczekiwaniom odbiorcy? A jeśli nie jest zaprojektowana po myśli odbiorcy, to co wtedy? Kto powinien ponieść koszty jej modyfikacji? Jak głębokich modyfikacji może domagać się odbiorca systemu na podstawie podpisanej umowy? Takie pytania można mnożyć w nieskończoność, jeśli nie mamy szczegółowej i jednoznacznej specyfikacji systemu.
Załóżmy, że zawarto umowę na dostawę dużego systemu informatycznego i w jego specyfikacji funkcjonalnej nie określono wielu istotnych szczegółów. Dostawca buduje system. W trakcie odbioru okazuje się, że funkcjonalność systemu daleko odbiega od oczekiwań odbiorcy. Co ma zrobić dostawca systemu?
Dostawca wykonał system zgodnie z umową a to, że jego interpretacja ogólnikowych zapisów w umowie nie pokrywa się z oczekiwaniami odbiorcy nie jest jego winą. Odbiorca przed podpisaniem umowy nie przemyślał dostatecznie szczegółowo funkcji użytkowych, które powinny być realizowane przez system (jest to typowa sytuacja w administracji państwowej) a teraz grozi, że nie podpisze faktury. Najprostszym i najtańszym wyjściem z sytuacji jest dotarcie do osoby wysoko umocowanej w hierarchii urzędu, która nieformalnie „przekona” urzędnika odpowiedzialnego za odbiór systemu, że po niewielkich korektach system będzie już miał „właściwą” postać. Korupcja następuje w fazie odbioru.
Jeżeli po podpisaniu umowy nie porzucono budowy systemu a tak też bywało (np. systemy dla GUC), to powyżej mamy opis typowego scenariusza odbioru dużych systemów informatycznych w sektorze publicznym po 89r.
W przypadku nieprecyzyjnych specyfikacji funkcjonalnych instytucje kontrolne nie mają wiele do zrobienia. Jeśli kontrolerzy NIK chcieliby dokonać oceny jakości systemu i zasadności poniesionych kosztów, to nie mają na czym się oprzeć. Mogą tylko sprawdzić kwestie formalno-prawne, czy wszystko odbyło się zgodnie z prawem, czy osoby podejmujące decyzje były do nich uprawnione itp. Korupcja związana z odbiorem systemu przynosi więcej szkód niż korupcja dotycząca wyboru dostawcy i wiąże się ze znacznie mniejszym ryzykiem.
