Wprowadzenie homologacji systemów informatycznych do praktyki administracji publicznej, tak jak postulują Ministerstwo Gospodarki i Pracy oraz Ministerstwo Polityki Społecznej, oznacza rewolucję na rynku.

Standardowym sposobem pozyskiwania oprogramowania dedykowanego przez administrację publiczną jest jego zamówienie w ramach projektu outsourcingowego. Polega to na tym, że jednostka administracji publicznej definiuje swoje potrzeby w odniesieniu do oprogramowania, a następnie w ramach standardowej, dopuszczalnej prawem procedury przetargowej, wyłania zewnętrznego w stosunku do siebie producenta, którego zadaniem jest realizacja czynności programistycznych i wdrożeniowych.

Układ taki, kiedy to produkcją aplikacji zajmuje się profesjonalna firma programistyczna, jest oczywiście jak najbardziej właściwy, jednak implementacja tego układu poprzez projekt outsourcingowy niesie wiele problemów. Co stanowi największe wyzwanie? Otóż to, że jednostka administracji publicznej dokonując wyboru "najlepszego" spośród producentów, czyni z niego tym aktem monopolistę, na którego musi być zdana - a zatem dyktatora.

Wiele już było, i zapewne wiele jeszcze będzie, pomysłów na zwiększenie efektywności realizacji projektów informatycznych lub też chociażby na zwiększenie szans ich powodzenia. Zbiory takich pomysłów ogłaszane są światu w postaci wytycznych w odniesieniu do procesów wytwórczych oprogramowania, propozycji samych procesów lub ich szablonów (frameworks). Mamy więc Project Management Body of Knowledge (PMBOK), ISO 9000:2000, ISO 12207, Software Engineering Body of Knowledge (SWEBOK), Software Capability Maturity Model (SW-CMM), Capability Maturity Model Integration (CMMI), Prince 2, IBM Rational Unified Process, SELECT Perspective, Dynamic System Development Method (DSDM), Feature Driven Development, Crystal Family of Methodologies, Extreme Programming i wiele, wiele innych.

Rzeczą niezmiernie istotną jest, aby wybrać najwłaściwszą metodykę dla projektu, który ma się przeprowadzić, ponieważ wbrew temu co się powszechnie głosi nie ma w produkcji oprogramowania środków uniwersalnych. Tylko czy to wszystko musi interesować administrację publiczną? Kiedy myśli się o przedsięwzięciu, odpowiedź musi być niestety twierdząca. Ale czy administracja publiczna musi rzeczywiście myśleć o przedsięwzięciach? Otóż nie zawsze. Administracji publicznej potrzebne są narzędzia informatyczne wspierające jej własne procesy, ale nie projekty, w ramach których te narzędzia powstają!

W związku z tym, że administracja ma specyficzne potrzeby, które w dodatku często się zmieniają, niezbędne jej programy nie są dostępne z półki, tak jak edytory tekstów czy arkusze kalkulacyjne, lub choćby nawet na wpół z półki, np. systemy CRM lub ERP. Systemy dla administracji publicznej muszą być tworzone na jej zamówienie. Zobaczmy najpierw jak to się robi dziś, w ramach projektów outsourcingowych, a następnie jak można to, w niektórych przypadkach, poprawić.

Dyktatura

Jednostka administracji publicznej uruchamiająca przedsięwzięcie, w ramach którego ma powstać oprogramowanie, nie może pozostawać obojętna na ryzyko, jakie jest związane z tego typu działaniem. Oczywistą jest też rzeczą, że wszyscy odpowiedzialni za sukces projektu starają się to ryzyko minimalizować. A co można robić, mając do czynienia z przedsięwzięciami organizowanymi na zasadach outsourcingowych? Otóż po pierwsze, można zabezpieczać się na okoliczność dokonania złego wyboru producenta. Specyfikacje Istotnych Warunków Zamówienia zawierają mnóstwo zapisów podporządkowanych temu celowi.

Żąda się więc od oferentów:

1. Życiorysów wiodących uczestników projektu, z poświadczonym wykształceniem i doświadczeniem, wraz z ich oświadczeniami, że nie opuszczą przedsięwzięcia, aż do ostatniego jego dnia, jak również, że nie będą w czasie trwania projektu brać udziału w żadnym innym przedsięwzięciu.
2. Wykazu dotychczasowych sukcesów oferenta w podobnych projektach, biorąc pod uwagę zakres, czas trwania, branżę, liczbę użytkowników itp.
3. Opisu metodyki, jaką oferent zastosuje w przedsięwzięciu, jeśli dana mu będzie szansa jego podjęcia, oraz planu zapewnienia jakości w projekcie.
4. Oświadczenia o posiadaniu odpowiedniego potencjału technicznego i ekonomicznego, informacji z banku potwierdzającej wielkość posiadanych środków finansowych oraz zdolność kredytową, zaświadczeń o niezaleganiu z podatkami i płatnościami na rzecz ZUS.

Czy spełnienie tych warunków przez oferenta gwarantuje, że projekt odniesie sukces?

Konieczność sprostania wymaganiom, które poza zaświadczeniami z banków i urzędów są tylko oświadczeniami i deklaracjami, stawia przed oferentami najróżniejsze pokusy. To, czy tym pokusom ulegają, to już sprawa indywidualna każdego oferenta. Kiedy się jednak raz przegra, a potem może jeszcze raz, i gdy później uzyska się informację, że ten, który wygrał, nie zrobił tego w pełni uczciwie, albo chociażby, że nie dał rady sprostać zadaniu, które wydawało się takie błahe, pokusy, wciąż te same, stają się o wiele silniejsze. A ludzie są w końcu tylko ludźmi.

A ileż wysiłku od zamawiającego wymaga weryfikacja, jakże trudnych do pomierzenia, odpowiedzi oferentów. A niby jak zamawiający ma stwierdzić, że metodyka zaproponowana przez jednego oferenta okaże się skuteczniejsza od metodyki zaproponowanej przez innego? Chyba nie poprzez podliczenie stron, które zostały poświęcone temu zagadnieniu przez kontrkandydatów. Czy czytelność opisu, np. poprawność formułowania zdań w języku polskim, jest jakimś gwarantem? A może zdecydują sławne nazwiska stojące za podejściami, którymi oferenci starają się podpierać? Ale jak zamawiający ma dokonać porównania tego, co mówi Grady Booch z tym, co propaguje Kent Beck, tego, o co postuluje Mark Paulk, z tym, co zaleca Eric Raymond? A w końcu jak zamawiający może ocenić, czy oferent sam rozumie co napisał i czy jest w stanie zastosować to w praktyce?

Załóżmy jednak, że zamawiający po dokonaniu wyboru jest przeświadczony, że wygrał rzeczywiście najlepszy spośród kandydatów, ponieważ zrobił wszystko co było w jego mocy, aby to przeświadczenie uzyskać. Rozpoczyna się projekt... I co można powiedzieć w danej chwili o tym projekcie? Czy skończy się w pożądanym czasie? Czy w jego wyniku powstanie rzeczywiście to, co jest potrzebne? Czy projekt nie pochłonie więcej środków niż się zakłada? Na żadne z tych pytań nie da się odpowiedzieć z pewnością. Z pewnością jednak zamawiający ma podstawy do zadowolenia z posiadanego alibi: "Jeśli z tym wygranym się nie uda, to z przegranymi też nie da się odnieść sukcesu". To alibi jest pozorne, ale nie da się go obalić w prosty sposób.