W 2009 roku udzielając wywiadu Gazecie zwróciłem uwagę na fakt, że:

– Patologiczne są przetargi, w których wykonawca systemu sam sobie robi analizę wymagań. Z całym szacunkiem, nie widziałem jeszcze wykonawcy, który by w takiej analizie napisał: “niniejszym stwierdzam, że moje rozwiązanie się tu nie nadaje”. Słyszałem za to: “ukręcimy łeb każdemu przetargowi, który ma oddzieloną specyfikację wymagań od wykonania na dwa przetargi” (na szczęście coraz rzadziej się to udaje). Powód był prosty – firmy się obawiały, że mniej zarobią. (Wymiećmy spod kołdry brudy informatyzacji).

Świeży przykład. W pewnym przetargu wymagania opisane całkiem przyzwoicie w Załączniku nr 3 (znowu jednak nie znamy autora tej dokumentacji, Przetarg na utworzenie Systemu Konsultacji On-Line prowadzone w trybie przetargu nieograniczonego). Jednak znowu mamy przetarg, w którym dostawca oprogramowania ma w zakresie także:

Wykonanie pełnej specyfikacji funkcjonalnej Systemu wraz z całościowym projektem graficznym oraz Harmonogramem realizacji projektu zawierającym przewidywane zaangażowanie osób.

Zamawiający narzuca w przetargu rozwiązanie oparte o [[CMS Drupal]], moja wątpliwość brzmi: a skąd wiadomo, że Drupal skoro nie ma jeszcze analizy wymagań? Te wątpliwość zgłosił także jeden z oferentów:

“Pytanie 5 Pkt 2.2 ? Z jakich względów rozwiązanie ma być oparte na systemie Drupal? Czy może być zastosowane rozwiązanie równoważne (np. Joomla)?

Odpowiedź Zamawiającego Portal WWW powinien być dostępny w systemie Drupal, ze względu na to że Ministerstwo Gospodarki korzysta z tego rozwiązania portalowego na swojej stronie internetowej. www.mg.gov.pl. W związku z tym są już przeszkoleni odpowiednio pracownicy do zarządzania i wprowadzania modyfikacji używając tego narzędzia portalowego. Tylko w momencie udowodnienia ograniczeń programistycznych systemu Drupal uniemożliwiających wykonanie pełnej funkcjonalności portalu WWW Zamawiający dopuszcza utworzenie silnika portalu w oparciu o inne rozwiązanie opensourcowe z zastrzeżeniem że musi również powstać wtyczka do portalu Drupal oparta na utworzonym API która by umożliwiła korzystanie z funkcjonalności systemu.” (http://bip.mg.gov.pl/files/Odpowiedz_0.pdf)

Czyli znowu, jak się okaże w toku projektu, że Drupal nie, to projekt czeka zmiana zakresu (podniesienie kosztu), ciekawe tylko na czyj koszt odbędzie się ta zmiana … popatrzymy… dlaczego najkosztowniejsza metoda odkrywania wymagań: rozpoznanie bojem, jest tak popularna w administracji (zresztą nie tylko) i preferowana przez wielu dostawców ? Bo kosztowna?

Mamy 12.04.2012, ukazuje się w Gazecie Prawnej badanie:

Naukowcy z Instytutu Informatyki Politechniki Wrocławskiej przyjrzeli się bliżej 80 inwestycjom, które uruchomiono w połowie 2010 roku. I porównali ze sobą ich wyniki. Okazało się, że są ogromne dysproporcje między urzędami a firmami. Dysproporcje niestety na niekorzyść projektów publicznych, które kończą się sukcesem dwukrotnie rzadziej niż analogiczne z sektora prywatnego. A do tego niestety ponad połowa z nich kończy się klapą. […] mamy niestety wysyp projektów spektakularnych, o ogromnych budżetach i zapowiadanych jako rewolucyjne, ale o znikomej funkcjonalności. Wystarczy wymienić ePUAP, CEPiK, systemy do obsługi elektronicznego obiegu dokumentów w urzędach. Albo wdrażany przez kilkanaście lat system do rozliczania podatków Poltax, który choć ostatecznie zakończony zgodnie ze specyfikacją, okazał się całkowicie nieprzydatny. (Informatyzacja administracji totalną klęską – Biznes i prawo gospodarcze – Gazeta Prawna – Partner pracodawcy, narzędzie specjalisty).

Cóż, dziwnym trafem projekty o porównywalnej funkcjonalności są niejednokrotnie w administracji znacznie kosztowniejsze niż w sektorze prywatny. Kilka lat temu gdy jeszcze miałem ambicje “startować”  w przetargach dowiadywałem się, że moja “oferta rażąco niska w stosunku do pozostałych”. Zawsze wydawało mi się, że dość wysokie stawki a tu proszę. Ale chyba jest wyjasnienie:

Przetarg na platformę medyczną P1 trzeba unieważnić ? twierdzą eksperci. Zarzuty o zmowę cenową przy przetargu na informatyzację służby zdrowia są bardzo poważne. (za  Fatalny błąd przy informatyzacji słuzby zdrowia: przetargi do kasacji).

O zmowach cenowych (zawyżanie cen) “tylko słyszałem”…  ale chyba i to, jak widać, jest nie tylko plotką. Jakimś cudem jak tylko coś jest za “państwowe pieniądze” natychmiast staje się “bardzo kosztowne”…

Kolejny przykład:

Agenci katowickiego CBA zatrzymali dwoje pracowników PKP, którzy mieli brać łapówki podczas informatyzacji kolei na Śląsku. Razem z nimi zatrzymano prezesa jednej z globalnych firm informatycznych, który miał im wręczać pieniądze. (Akcja CBA na kolei. Trzy osoby zatrzymane).

Zaczynam się zastanawiać czy którykolwiek z “wielkich projektów informatycznych dla administracji państwowej” został zrealizowany “uczciwie”…

Ciekawy jestem, kiedy i czy w ogóle nowy minister od informatyzacji zareaguje, jak na razie robotę ma CBA… Ciekawsze moim zdaniem jest co innego: już następuje na rynku podział na firmy permanentnie startujące w przetargach, dla których administracja to główne źródło przychodu oraz pozostałe.  Te dwa rynki coraz bardziej stają się “odrębnymi rynkami”. Nie raz słyszę: “nie starujemy w przetargach bo są poustawiane” mamy klientów i bez tego. Na tle tego z jakichś powodów te pierwsze firmy – specjalizujące się w administracji państwowej – mają bardzo mało klientów poza nią…

“Przypadków” nie ma końca:

ceny zamawianych systemów informatycznych były wielokrotnie zawyżane w stosunku do ich rzeczywistej wartości. Specyfikacje warunków zamówienia były tak formułowane, że ich wymagania mogło spełnić zaledwie kilka firm. Najczęściej chodziło o wymóg posiadania określonych certyfikatów wystawianych przez globalne koncerny informatyczne. Innym sposobem było wpisanie do warunków zamówienia wymogu posiadania doświadczenia w realizacji wielkich systemów informatycznych. Ponadto umowy były tak konstruowane, by uzależnić odbiorców tak, aby nie mogli zamawiać w przyszłości sprzętu i oprogramowania u innych dostawców. Firmy nie przekazywały bowiem tzw. kluczy oraz praw autorskich do oprogramowania. (za  Miliardy utopione w infoaferze | rp.pl).

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.