Idee

Standardowym sposobem pozyskiwania oprogramowania dedykowanego przez administrację publiczną jest powodowanie jego wytworzenia 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 wytwórstwem aplikacji komputerowych zajmuje się profesjonalna firma programistyczna^[1], jest oczywiście jak najbardziej właściwy, jednak implementacja tego układu poprzez projekt outsourcingowy niesie ze sobą 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 oprogramowana, propozycji samych procesów lub ich szablonów (ang. 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, a nie projekty, w ramach których te narzędzia powstają!

W związku z tym, że administracja ma bardzo specyficzne potrzeby, które w dodatku bardzo często się zmieniają, niezbędne jej programy nie są dostępne z półki, tak jak np. edytory tekstów czy arkusze kalkulacyjne, lub choćby nawet na wpół z półki, jak 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ć.

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^[2]. Oczywistą rzeczą jest też to, ż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:

• Ż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,

• Wykazu dotychczasowych sukcesów oferenta w podobnych projektach, biorąc pod uwagę zakres, czas trwania, branżę, liczbę użytkowników, itp.,

• 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,

• 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 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 z oferentów. Kiedy się jednak raz przegra, a potem może jeszcze raz i gdy później uzyska się informację^[3], ż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.

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 strony 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^[4]. 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 On 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. Cześć 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, a produkty!

Administracja publiczna nie zawsze musi angażować się w produkcję oprogramowania, którego potrzebuje, a 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 aby 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ą pt. „Informatyka w Polityce Społecznej”^[5], w której znalazły się trzy artykuły poświęcone zagadnieniu homologacji systemów informatycznych. Dwa spośród nich, pani Krystyny Mierzwińskiej i pana 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 i jest wynikiem ponad dwuletniej, niezależnej obserwacji czynionej przez firmę METODA sp. z o.o. 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 piszę dokładniej dlaczego 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ą pani Mierzwińska i pan 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^[6]. 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.

O homologacji systemów informatycznych opowiadał podczas konferencji „Państwo w mikro- i makroskali” Dyrektor Departamentu Informatyki MGiP, pan Zbigniew Olejniczak. 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 wypowiedziała. Każda rewolucja występuje przeciwko pewnemu status quo ante, a więc niewątpliwie przeciwko przeciwko temu, co przez niektórych jest postrzegane jako korzystne^[7].

Rewolucja budzi strach.