Postępowania przetargowe, zwłaszcza te wielomilionowe, zawsze będą budziły zainteresowanie otoczenia, mediów zaś w szczególności, które będą oczywiście szukać sensacyjnych wątków. I nie należy się temu specjalne dziwić jako, że sensacja zawsze sprzedaje się lepiej niż naga prawda. Trzeba być na to przygotowanym i podchodzić do tych spraw bez emocji, tym bardziej, że czeka nas realizacja projektów informatycznych w ochronie zdrowia za prawie 1 mld zł. Do informatyzacji szykują się zarówno podmioty centralne (NFZ, CSIOZ, NRL itp.) jak i zakłady opieki zdrowotnej. Wykorzystanie środków unijnych na te przedsięwzięcia jest teraz sprawą interesu narodowego. I nie ma w tym zdaniu przesady. Kryzys finansowy jest faktem i to właśnie środki unijne mogą nie tylko być może uratować naszą gospodarkę, zwiększyć PKB ale – i to jest pewnie najważniejsze – jest to w perspektywie najbliższych 10 lat ( a może nawet 20) jedyna możliwość zinformatyzowania polskiej służby zdrowia. Wszyscy zdajemy sobie sprawę, że jeżeli prognozujemy spadki PKB to po prostu za 3 lata nie będzie pieniędzy na uruchomienie tych projektów w budżecie państwa.

Warto w tym miejscu zastanowić się jak szybko i sprawnie przeprowadzić projekty informatyczne w jednostkach publicznych zwłaszcza w jego pierwszej fazie tj. projektowania i przeprowadzenia zamówienia publicznego. Bardzo dużym ograniczeniem jest bowiem dla tych podmiotów szczupłość kadr informatycznych oraz brak osób ze znajomością inżynierii prowadzenia projektu, wielkość budżetu, który można przeznaczyć na realizację projektu oraz duże wymagania i oczekiwania postawione przez nadzorujących podmioty publiczne. Nie należy zapominać również, że podmiot publiczny działa w reżimie prawa zamówień publicznych oraz ustawy o finansach publicznych, która narzuca bardzo ostry reżim zarządzania budżetem jednostki. Doświadczenie niektórych projektów pokazuje, ze nawet w tak trudnej sytuacji można efektywnie zaprojektować i sprawnie przeprowadzić projekt informatyczny. Zanim zaproponujemy tą metodę warto zapoznać się jak wygląda najczęstsza praktyka realizacji projektów przez instytucje publiczne.

Zwykle realizacja projektu informatycznego przez jednostkę publiczną wygląda jak wyścig z czasem. Po oficjalnym przyznaniu budżetu inwestycyjnego (mniej więcej w połowie roku) rozpoczyna się faza projektowania założeń. Ze względu na brak czasu, wspomnianą wyżej szczupłość kadr informatycznych i projektowych zaproponowane założenia są zbyt ogólne (w skutek czego oddawany system najczęściej nie spełnia wszystkich wymagań zamawiającego). Zamawiający stoi przed dylematem, czy projektować system własnymi siłami, czy starać się szukać doradcy zewnętrznego. Wybór drugiej opcji to oczywiście dodatkowe koszty i czas i pierwsze podejrzenia otoczenia, że system będzie zaprojektowany „pod kogoś”. Zamawiający decyduje się więc najczęściej na wybór pierwszej opcji. Następnie na początku czwartego kwartału ogłaszane jest postępowanie przetargowe. Najczęściej jest to przetarg nieograniczony poniżej wartości progowej 133 tys euro netto (około 600 tys brutto), która umożliwia zminimalizowanie czasu na składanie ofert ( 7 dni) a do niedawna umożliwiała również Zamawiającemu skuteczne odrzucanie ewentualnych protestów (obecna ustawa umożliwia wykonawcom oddanie pod arbitraż UZP postępowań o małych wartościach). Zdając sobie sprawę z dość ogólnego opisu przedmiotu zamówienia Zamawiający stara się ograniczyć ryzyko otrzymania przedmiotu zamówienia nie spełniającego wymagań poprzez wprowadzenie bardziej restrykcyjnych warunków udziału w postępowaniu, ograniczając udział w postępowaniu firmom o małym doświadczeniu (zgodnie z ustawą prawo zamówień publicznych zamawiający ma w tym względzie stosunkowo dużą swobodę) Z jednej strony mamy więc wysokie oczekiwania Zamawiającego co do doświadczenia Wykonawcy (spełniają je zwykle firmy duże), a z drugiej ograniczony budżet (zdolność wykonawczą mają zwykle firmy mniejsze). Do postępowania przystępują więc najczęściej firmy z dużym doświadczeniem, które są skłonne wykonać oprogramowanie po kosztach lub nawet poniżej byle tylko dostać się na rynek licząc na ewentualne zyski w przyszłości. W konsekwencji zainteresowanie postępowaniem ze strony Wykonawców znacząco spada. W efekcie podczas postępowania przetargowego składane są często jest jedna lub dwie oferty. Postępowanie przetargowe i podpisanie umowy z Wykonawcą zwykle kończy się w okolicach listopada. Wykonawca ma więc około miesiąca czasu na wykonanie systemu. System wytworzony w tak krótkim czasie można potraktować wyłącznie jak jego niedoskonałą lub niedojrzałą wersję. Konieczne są bowiem wykonanie szczegółowej analizy, przygotowanie projektu koncepcyjnego i przede wszystkim konsultacje z użytkownikami a na to zwykle już brak czasu. Ostatecznie w grudniu następuje formalny odbiór systemu i dokonanie zapłaty. Budżet zostaje wykonany. Problem z systemem jednak pozostaje. Trzeba go jeszcze dopracować i rzecz najważniejsza wdrożyć, co w projekcie informatycznym jest kwestią najważniejszą. Doświadczeni zamawiający stosują zwykle w takich sytuacjach zabieg w postaci wprowadzenia w umowie klauzuli gwarantującej wprowadzanie nieodpłatnych poprawek w systemie zgłaszanych przez użytkowników. Doświadczeni wykonawcy natomiast pragną za wszelką cenę tego uniknąć, gdyż zdają sobie sprawę że często prowadzi to do konieczności całkowitego przebudowania systemu. Następuje pierwsze zwarcie interesów zamawiającego i wykonawcy. Zwykle proces konsultacji i dopracowywania systemu odbywa się w pierwszej połowie następnego roku. Nierzadko system spotyka się z gwałtowną krytyką użytkowników, którzy pierwszy raz mają możliwość z nim się zaznajomić. Zgłaszane poprawki i postulaty zaczynają przekraczać ustalony w umowie zakres zmian. Jeśli Zamawiający nie był na tyle zapobiegliwy i nie zawarł w umowie wyżej wymienionej klauzuli, ma jeszcze większy problem. Najczęściej w połowie następnego roku (po oficjalnym przyznaniu budżetu) ogłaszane jest kolejne postępowanie przetargowe na wprowadzenie zmian do już wytworzonego systemu (oczywiście jest to przetarg nieograniczony). Zakres zmian jest bardzo często na tyle duży, że często prowadzi do gruntownej przebudowy systemu a nierzadko do jego budowy od podstaw. Jak można się spodziewać w takim postępowaniu przetargowym zostanie złożona tylko jedna oferta - tj. firmy, która zrealizowała pierwsze zamówienie. Wykonanie zamówienia przez innego wykonawcę praktycznie jest niewykonalne ze względów technologicznych. Należy również pamiętać o istnieniu niepisanej reguły na rynku informatycznym, która mówi o wzajemnym „nie wtrącaniu się” firm w realizowane przez nie projekty informatyczne. Zdarzają się często przypadki, składania ofert przez konkurencyjne firmy, ale głównie po to aby móc skontrolować ofertę faworyta pod kątem posiadanych referencji w planowanych innych postępowaniach przetargowych. Oferty takie są najczęściej wybrakowane aby przypadkiem nie doszło do jej wyboru. Przetarg kończy się wyborem oferty faworyta. Wszystko odbywa się zgodnie z ustawą o zamówieniach publicznych a przetargi przechodzą kontrolę przez instytucje nadzorujące. Zwykle pod koniec roku wprowadzane są zmiany w systemie postulowane przez użytkowników i ostateczna wersja systemu jest oddawana do użytku. Cały cykl życia projektu od powstania założeń do oddania ostatecznej wersji systemu trwa więc około półtora roku.

Czy można zastosować inną mniej „stresującą” dla Zamawiającego metodę prowadzenia projektu. Okazuje się, że tak. Metoda ta jest kombinacją trzech postępowań przetargowych występujących jedne po drugim, które w sumie mogą przyczynić się do skrócenia realizacji projektu mniej więcej o pół roku. Daje ona zamawiającemu możliwość kontrolowania projektu na każdym etapie jego realizacji. Biorąc pod uwagę, szczupłość zasobów kadrowych zamawiającego oraz konieczność zaangażowania użytkowników już na wstępnym etapie projektowania systemu informatycznego na początku projektu najlepiej jest przeprowadzić konkurs „na opracowanie założeń do systemu informatycznego” w trybie ustawy prawo zamówień publicznych. Metoda ta przed długie lata niedoceniania, jest w ostatnim okresie czasu coraz częściej stosowana przez podmioty publiczne. Postępowanie konkursowe zwykle trwa około 1,5 miesiąca, które zakończy się przyznaniem nagród dla autora najlepszej pracy konkursowej. W konkursie nie występuje komisja przetargowa a sąd konkursowy, do którego warto zaprosić przedstawicieli użytkowników przyszłego systemu. Sąd podejmuje decyzje o wyborze najlepszej pracy konkursowej poprzez przyznanie określonej ilości punktów w ramach określonych wcześniej kryteriów oceniania. Oceniane mogą być np. metody utrzymania bezpieczeństwa systemu, sposób prowadzenia nadzoru autorskiego, propozycje z zakresu interfejsu użytkownika, architektura informatyczna, metody przygotowywania analiz i raportów itp. Konkurs ustanawia więc zamawiającego w roli arbitra, który może kierować się dużą swobodą w swoich wyborach. Warunki udziału w postępowaniu powinny umożliwiać zamawiającemu otrzymanie „rozsądnej” ilości prac konkursowych, gdyż każda z nich musi zostać przeanalizowana i oceniona w założonym wcześniej czasie przez członków sądu konkursowego. Doświadczenie wskazuje, że ilość prac konkursowych powinna wahać się między 3 a 6. Konkurs kończy się otrzymaniem przez zamawiającego kompletu założeń do systemu, które można wykorzystać na dalszych etapach projektu tj. jako podstawa do opracowania specyfikacji istotnych warunków zamówienia. Nagrodą w konkursie może być również zaproszenie zwycięscy konkursu do negocjacji, w trybie zamówienia „z wolnej ręki” na opracowanie docelowego projektu koncepcyjnego systemu informatycznego oraz jego prototypu. Zamawiający przystępując do negocjacji nie jest związany z tak mocno istotnymi postanowieniami umowy jak w przypadku przetargu nieograniczonego. Może negocjować zarówno cenę jak i zakres przedmiotowy np. poprzez konieczność uwzględnienia przez wykonawcę projektu koncepcyjnego wybranych części prac konkursowych, które zajęły drugie i trzecie miejsce w konkursie. W umowie ze zwycięzcą konkursu warto zawrzeć klauzulę o „nieodpłatnym” wprowadzaniu zmian zgłaszanych przez użytkowników podczas konsultacji prototypu. W związku z tym, że nie mamy do czynienia jeszcze z gotową wersją systemu przyjęcie takiego zobowiązania przez wykonawcę nie powinno stanowić większego problemu. W wyniku realizacji tego etapu zamawiający otrzymuje więc (mniej więcej po pół roku od rozpoczęcia realizacji całego projektu) szczegółowy projekt koncepcyjny wraz z prototypem w wersji elektronicznej. Istotne znaczenie dla jednostki publicznej ma fakt, że zapłata za projekt koncepcyjny i prototyp można zrealizować zarówno ze środków bieżących jak inwestycyjnych. Mamy bowiem do czynienia z produktem informatycznym będącym równocześnie opracowaniem koncepcyjnym. Tak więc zamawiający nie musi czekać na oficjalne przyznanie budżetu inwestycyjnego aby rozpocząć procedurę konkursową. Dysponując szczegółowym projektem koncepcyjnym i jego wersją elektroniczną w postaci prototypu zamawiający może ogłosić postępowanie w trybie przetargu nieograniczonego. Projekt koncepcyjny i prototyp elektroniczny stają się załącznikami do specyfikacji istotnych warunków zamówienia i stanowią opis przedmiotu zamówienia. W takim postępowaniu zamawiający może zdecydować się na  „poluzowanie” warunków udziału w postępowaniu, gdyż ryzyko otrzymania produktu nie spełniającego wymagań jest zdecydowanie mniejsze niż w przypadku opisanym w pierwszej części artykułu. Oczywiście tak jak w pierwszym przypadku nie należy oczekiwać jakiegoś dużego wysypu ofert. Zainteresowanie postępowaniem ograniczy się zapewne do wykonawców mających doświadczenie w danym obszarze rynku a na pewno będzie w nim startował wykonawca prototypu, który wykonywał go jako podwykonawca na zlecenie zwycięscy konkursu. Pod koniec roku możemy oczekiwać gotowego systemu, który zostanie dobrze przyjęty przez użytkowników. Wartość całego projektu tj. prototypu, projektu koncepcyjnego oraz docelowego systemu nie powinna łącznie przekroczyć sumy środków, które zostały wydane w pierwszym przypadku tj. dwukrotnego ogłaszania przetargów nieograniczonych.

 

Zamówienia publiczne a jakość systemów informatycznych

Zgodnie z zapisami rozporządzenia Prezesa Rady Ministrów z dnia 19 maja 2006 r. w sprawie rodzajów dokumentów, jakich może żądać zamawiający od wykonawcy, oraz form, w jakich te dokumenty mogą być składane, Zamawiający ma prawo wymagać od wykonawcy dokumentów potwierdzających spełnianie przez niego norm jakościowych. Standardem stało się już wymaganie dotyczące norm ISO 9001:2000, w zakresie wytwarzania i wdrażania oprogramowania oraz potwierdzenia stosowania metodyki zarządzania projektami PRINCE 2. Powoli takim standardem stają się również normy dotyczące zarządzania bezpieczeństwem informacji (BS-7799-2, PN-I-07799-2:2005, lub ISO 27001:2005). Wymaganie posiadania przez wykonawcę dokumentu potwierdzającego spełnianie tej normy ma głębokie uzasadnienie zwłaszcza w systemie ochrony zdrowia gdzie przetwarzane są dane medyczne. W przypadku gdy zamawiany system informatyczny będzie utrzymywany przez wykonawcę w outsourcingu wymaganie takie staje się wręcz koniecznością. Należy przy tym pamiętać o zapisach Rozporządzenia Rady Ministrów z dnia 11 października 2005 w sprawie minimalnych wymagań dla systemów teleinformatycznych (Dz.U. Nr 212, poz. 1766), które mówi m.in., że „przy opracowaniu polityki bezpieczeństwa, podmiot publiczny powinien uwzględniać postanowienia Polskich Norm z zakresu bezpieczeństwa informacji” oraz wymaga od podmiotów publicznych aby „systemy teleinformatyczne używane do realizacji zadań publicznych spełniały właściwości i cechy w zakresie funkcjonalności, niezawodności, używalności, wydajności, przenoszalności i pielęgnowalności określone w normach ISO zatwierdzonych przez krajową jednostkę normalizacyjną, na etapie projektowania, wdrażania i modyfikowania tych systemów”.

  

Tekst ukazał się w styczniowym numerze "Służby Zdrowia" nr 1-4/2009