Source: http://docplayer.pl/1502989-Udzielanie-zamowien-publicznych-na-systemy-informatyczne-oraz-dostawe-zestawow-komputerowych.html
Timestamp: 2018-06-20 18:18:46+00:00
Document Index: 114601030

Matched Legal Cases: ['art. 10', 'art. 7', 'art. 31', 'art. 67', 'art. 67', 'art. 36', 'art. 23', 'art. 23']

Udzielanie zamówień publicznych na systemy informatyczne oraz dostawę zestawów komputerowych - PDF
Download "Udzielanie zamówień publicznych na systemy informatyczne oraz dostawę zestawów komputerowych"
1 2011 Udzielanie zamówień publicznych na systemy informatyczne oraz dostawę zestawów komputerowych REKOMENDACJE Prezesa UZP
2 Udzielanie zamówień publicznych na systemy informatyczne oraz dostawę zestawów komputerowych REKOMENDACJE Prezesa UZP Warszawa 2011
3 Udzielanie zamówień publicznych na systemy informatyczne oraz dostawę zestawów komputerowych. Rekomendacje Prezesa UZP. Opracowanie: Urząd Zamówień Publicznych ul. Postępu 17a Warszawa Wydawca: Polska Agencja Rozwoju Przedsiębiorczości ul. Pańska 81/ Warszawa Copyright by Urząd Zamówień Publicznych, Warszawa 2011 Copyright by Polska Agencja Rozwoju Przedsiębiorczości, Warszawa 2011 Publikacja współfinansowana przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Publikacja bezpłatna ISBN: Wydanie I Nakład: egz. Przygotowanie do druku, druk i oprawa: Agencja Reklamowo-Wydawnicza A. Grzegorczyk
4 Słowo wstępne Prezentujemy Państwu publikację Udzielanie zamówień publicznych na systemy informatyczne oraz dostawę zestawów komputerowych. Rekomendacje zostały przygotowane przez Prezesa Urzędu Zamówień Publicznych i udostępnione w 2010 r. na stronie internetowej UZP. Publikacja jest swego rodzaju przewodnikiem dotyczącym udzielania zamówień publicznych na powszechnie stosowane systemy informatyczne oraz dostawę zestawów komputerowych. Omawiane są w niej przepisy ustawy Prawo zamówień publicznych, których nie zastosowanie lub błędna interpretacja skutkuje nieprawidłowościami w postępowaniach, charakteryzujących się wysokim stopniem złożoności oraz wysoką wartością przedmiotu zamówienia. Wskazane są również rozwiązania, które pozwalają tych nieprawidłowości uniknąć. W rekomendacjach zwraca się uwagę na narzędzia, które są przewidziane w ustawie oraz dyrektywach Unii Europejskiej, dzięki którym, przy zachowaniu należytej staranności podczas przygotowania i prowadzenia postępowania o udzielenie zamówienia publicznego na systemy informatyczne, można dokonywać zarówno korzystnych ekonomicznie jak i funkcjonalnych, innowacyjnych zakupów. Opracowanie jest publikowane w ramach projektu systemowego Polskiej Agencji Rozwoju Przedsiębiorczości pn. Nowe podejście do zamówień publicznych szkolenia i doradztwo. Projekt jest współfinansowany ze środków Europejskiego Funduszu Społecznego w ramach Programu Operacyjnego Kapitał Ludzki, Działanie 2.1 Rozwój kadr nowoczesnej gospodarki", Poddziałanie Wsparcie systemowe na rzecz zwiększania zdolności adaptacyjnych pracowników i przedsiębiorstw. W projekcie przewidziane są kompleksowe działania, prowadzone w skali ogólnopolskiej, mające na celu wzrost wiedzy o możliwościach, jakie stwarza ustawa Prawo zamówień publicznych w zakresie nowego podejścia oraz sposobach wdrożenia tych rozwiązań w praktyce udzielania zamówień publicznych. W rekomendacjach prezentowane są rozwiązania stosowane przy opisie przedmiotu zamówienia, będące elementami nowego podejścia do zamówień publicznych, takie jak zróżnicowanie kryteriów oceny ofert, formułowanie wymagań jakościowych, korzystne nie tylko dla zamawiającego ale również wykonawców, których stosowanie musi iść w parze z prawidłowym, zgodnym z obowiązującymi regulacjami, prowadzeniem postępowań. Wyrażamy nadzieję, że publikacja będzie przydatnym źródłem wiedzy dla osób uczestniczących w procesie udzielania zamówień publicznych. Jacek Sadowy Prezes Urzędu Zamówień Publicznych Bożena Lublińska-Kasprzak Prezes Polskiej Agencji Rozwoju Przedsiębiorczości 3
6 Spis treści: UDZIELANIE ZAMÓWIEŃ PUBLICZNYCH NA SYSTEMY INFORMATYCZNE REKOMENDACJE Wstęp Słownik pojęć Struktura rekomendacji Rekomendacje Rekomendacja 1: planowanie rozwoju systemów informatycznych w organizacji Zamawiającego Wprowadzenie problemowe Treść rekomendacji Rekomendacja 2: zarządzanie informatyką w organizacji zgodnie z najlepszymi praktykami i standardami Wprowadzenie problemowe Typowe błędy popełniane przez Zamawiających Treść rekomendacji Rekomendacja nr 3: Konstruowanie zamówienia z uwzględnieniem cyklu życia systemu Wprowadzenie problemowe Typowe błędy popełniane przez Zamawiających Treść rekomendacji Rekomendacja 4: formułowanie wymagań jakościowych, pomiar jakości i stosowanie mechanizmów zapewniania jakości w toku realizacji zamówienia Wprowadzenie problemowe Treść rekomendacji Rekomendacja 5: pro-konkurencyjne kształtowanie architektury systemów Wprowadzenie problemowe Typowe błędy popełniane przez Zamawiających Treść rekomendacji Rekomendacja 6: gromadzenie i transfer wiedzy o konstrukcji systemu informatycznego Wprowadzenie problemowe Typowe błędy popełniane przez Zamawiających Treść rekomendacji Rekomendacja 7: pro-konkurencyjna konstrukcja SIWZ oraz umów Wprowadzenie problemowe Typowe błędy popełniane przez Zamawiających Treść rekomendacji UDZIELANIE ZAMÓWIEŃ PUBLICZNYCH NA DOSTAWĘ ZESTAWÓW KOMPUTEROWYCH REKOMENDACJE REKOMENDACJE Cel rekomendacji Zasady ogólne wynikające z przepisów prawa Zasady konstruowania SIWZ w sposób nieograniczający konkurencji Definicje
7 Zasada ogólna opisu przedmiotu zamówienia na dostawę zestawów komputerowych Podstawowe zasady opisu przedmiotu zamówienia Wymagania dotyczące stosowanych testów Zakup zestawów komputerowych a zakup licencji na oprogramowanie użytkowane na nabywanych zestawach Zapisy niedopuszczalne Dyskryminujący zbieg wymagań Odstępstwa od rekomendacji Uzasadnienie zasad konstruowania SIWZ (p. 3) Wyjaśnienia do zapisów szczegółowych Obszar zastosowań Procesor Wydajność zestawu Pamięć operacyjna Karta graficzna Płyta główna Dysk twardy Monitor i inne urządzenia peryferyjne Dyskryminujący zbieg wymagań Przykładowy opis wymagań dla zestawu komputerowego Zastrzeżenia... 48
8 Udzielanie zamówień publicznych na systemy informatyczne rekomendacje 1. Wstęp W praktyce kontrolnej Urzędu Zamówień Publicznych, w szczególności w ramach analizy przesyłanych Prezesowi Urzędu obligatoryjnych zawiadomień o wszczęciu postępowania o zamówienie publiczne daje się zaobserwować niepokojące zjawisko dużej skali udzielania zamówień w trybie z wolnej ręki związanych z systemami informatycznymi. Zamówienia takie skutkują wydatkowaniem wielomilionowych kwot rocznie, osiągając w skrajnych przypadkach poziom około 100 mln złotych rocznie wydatkowanych przez jednego zamawiającego. Analizowane przez UZP przypadki dotyczą udzielania kolejnych zamówień w trybie z wolnej ręki często wielokrotnie przekraczających swą wartością zamówienie podstawowe udzielone w trybie konkurencyjnym. W przeważającej większości takich zamówień ich przedmiotem są prace nad rozbudową i modyfikacją systemów informatycznych, czy też zamawiania usług, oprogramowania lub sprzętu niezbędnego do utrzymywania infrastruktury lub oprogramowania gotowego zlecane dotychczasowemu wykonawcy. Przyczyną opisanego tu zjawiska jest powstanie uzależnienia zamawiającego od pierwotnego wykonawcy systemu lub producenta sprzętu lub oprogramowania gotowego uniemożliwiające nabycie niezbędnych usług lub dostaw w trybach konkurencyjnych. Uzależnienie to jest w dużej mierze konsekwencją niewłaściwego przygotowania postępowania i udzielenia zamówienia publicznego. Tymczasem źle przeprowadzony proces udzielania zamówienia podstawowego skutkujący koniecznością udzielenia zamówienia w trybie z wolnej ręki nie jest wystarczającą podstawą do stosowania trybu zamówienia z wolnej ręki. Tryb ten bowiem nie gwarantuje przejrzystości, a praktyka taka jest nie do zaakceptowania w świetle podstawowych zasad ustawy Prawo zamówień publicznych (dalej: Pzp). Zgodnie z art. 10 ustawy Pzp podstawowymi trybami udzielenia zamówienia są przetarg nieograniczony oraz przetarg ograniczony. Przepis ten służy realizacji podstawowych zasad wynikających z Traktatu Ustanawiającego Wspólnotę Europejską oraz wyrażonych w art. 7 ust. 1 ustawy Pzp tj. zasady przejrzystości, uczciwej konkurencji, niedyskryminacji i równego traktowania. Zastosowanie innego trybu niż przetarg nieograniczony lub ograniczony wymaga spełnienia przesłanek określonych w ustawie, które jako uzasadniające odstępstwo od podstawowej reguły należy interpretować ściśle. Do takich odstępstw należy zaliczyć zawieranie umów w wyniku przeprowadzenia postępowania w trybie z wolnej ręki. We wszystkich takich przypadkach do zamawiającego należy obowiązek wykazania podstawy dla zastosowania odstępstwa od zasady stosowania trybów podstawowych. W przypadku zamówień informatycznych zamawiający często korzystają z tego trybu powołując się bądź na przyczyny techniczne, bądź na przyczyny związane z ochroną praw wyłącznych. Zarówno dyrektywa 2004/18/WE (art. 31) jak i wdrażająca ją ustawa Pzp (art. 67 ust. 1 pkt 1 lit. a) i b) zamówienie z wolnej 7
9 ręki), wymieniają te przesłanki wśród przyczyn uzasadniających zastosowanie trybu niekonkurencyjnego, jednakże nie można z nich korzystać w całkowitym oderwaniu od podstawowych zasad traktatowych. Zgodnie z ww. regulacjami zamawiający może udzielić zamówienia z wolnej ręki m.in. w przypadku, gdy dostawy, usługi lub roboty budowlane mogą być świadczone tylko przez jednego wykonawcę: $ z przyczyn technicznych o obiektywnym charakterze, $ z przyczyn związanych z ochroną praw wyłącznych, wynikających z odrębnych przepisów. Wykładnia dyrektywy, którą implementuje przepis art. 67 ust. 1 pkt 1 lit. a) ustawy Pzp, przyjęta przez Europejski Trybunał Sprawiedliwości (dalej: ETS) wskazuje, że stosowanie trybu zamówienia z wolnej ręki jest uzależnione od kumulatywnego spełnienia dwóch przesłanek, a mianowicie: istnienia szczególnych przyczyn technicznych związanych z dostawami, usługami czy robotami będącymi przedmiotem zamówienia oraz tego, aby te szczególne przyczyny techniczne czyniły udzielenie zamówienia określonemu przedsiębiorcy bezwzględnie koniecznym 1. Podstawą zastosowania tej przesłanki jest zatem szczególny charakter danego zamówienia powodujący, że może ono być zrealizowane tylko przez jednego wykonawcę, przy czym nie jest wystarczające, że dany wykonawca jest w stanie zrealizować zamówienie najlepiej bądź w najszerszym zakresie. Musi on być jedynym wykonawcą, który ze względu np. na specyficzne cechy techniczne zamówienia jest zdolny do realizacji zamówienia. Trzeba przy tym pamiętać, że w tym wypadku należy brać pod uwagę nie tylko wykonawców prowadzących działalność na terenie Polski, ale również wykonawców pochodzących z innych państw członkowskich UE. Ponadto, do wykazania, że zamówienie może być wykonane tylko przez jednego wykonawcę nie wystarczy sam fakt, że zamówienie ma charakter złożony tym bardziej, jeśli jego realizacja została przewidziana w dłuższym okresie 2, czy też specyficzne cechy dostarczanych urządzeń i sposób ich montażu 3. Nie stanowi przesłanki pozwalającej na skorzystanie z trybu z wolej ręki przekonanie zamawiającego, że proponowany przez niego wykonawca jest jedynym, który ze względu na szczególne zaufanie, doświadczenie i możliwości organizacyjne, jest w stanie wykonać zamówienie. 4 Zamówienia w trybie z wolnej ręki można udzielić również wykonawcy, ze względu na posiadanie przez niego praw wyłącznych m.in. wynikających z prawa autorskiego. W tym przypadku zamawiający jest zobowiązany wykazać dodatkowo, iż na rynku nie istnieją rozwiązania równoważne, które odpowiadałyby potrzebom zamawiającego. W przeciwnym wypadku niemożliwe jest skorzystanie z trybu zamówienia z wolnej ręki, ponieważ prowadziłoby to do nierównego traktowania wykonawców i preferencji na rzecz rozwiązań objętych prawami wyłącznymi. Warto podkreślić, że skorzystanie z trybu zamówienia z wolnej ręki możliwe jest tylko w sytuacjach szczególnych, a szczególny charakter tych sytuacji zależny jest od czynników zewnętrznych niezależnych od zamawiającego. Mimo że ani ustawa, ani dyrektywa, wymieniając przyczyny techniczne bądź też związane z prawami wyłącznymi, nie formułuje wprost warunku, zgodnie z którym przyczyny te nie mogą wynikać z działania zamawiającego, to tego rodzaju warunek wynika z zasad traktatowych. Natomiast z dotychczasowej praktyki UZP wynika, iż wskazywanie przez zamawiających na konieczność udzielania zamówień publicznych w trybie z wolnej ręki konkretnemu wykonawcy w obszarze zamówień informatycznych w znacznej ich części jest wynikiem braku dochowania przez zamawiającego należytej staranności w zakresie opisu przedmiotu zamówienia, czy też przy sporządzaniu projektu umowy o zamówienie publiczne. 8 1 sprawy połączone C-20/01 i C-28/01 Komisja przeciwko Niemcom, pkt 59; sprawa C-57/94 Komisja przeciwko Republice Włoch, pkt 24; sprawa C-385/02 Komisja przeciwko Republice Włoch, pkt 18, 20 i 21 2 sprawa C-385/02 Komisja przeciwko Republice Włoch 3 C-394/02 Komisja przeciwko Grecji 4 wyrok NSA z dnia 11 września 2000 r. sygn. akt II SA 2074/00, wyrok SN z dnia 6 lipca 2001 sygn. akt III EN 16/01
10 Obowiązek zamawiającego przygotowania i przeprowadzenia postępowania z należytą starannością, oznacza w praktyce, że powinien on przede wszystkim precyzyjnie określić co będzie przedmiotem zamówienia. Ponadto, przedmiot zamówienia powinien być opisany w sposób, który umożliwia wykonawcom jednakowy dostęp do zamówienia i nie powoduje tworzenia nieuzasadnionych przeszkód w otwarciu zamówienia na konkurencję 5. Naruszeniem konkurencji oraz zasady przejrzystości byłoby w tym wypadku na przykład takie sformułowanie opisu przedmiotu zamówienia i/lub postanowień w umowie o zamówienie publiczne, którego konsekwencją będzie konieczność udzielenia kolejnego zamówienia na przykład na rozbudowę sytemu lub jego utrzymanie tylko temu wykonawcy, któremu udzielono zamówienia na budowę danego systemu informatycznego. Działanie takie ogranicza bowiem dostęp do zamówienia tym wykonawcom, którzy mogliby ubiegać się o nie, gdyby opis przedmiotu zamówienia na budowę systemu został przygotowany w sposób prawidłowy. Należy zauważyć, że zarówno ustawa PZP jak i dyrektywy dają zamawiającemu szereg narzędzi, dzięki którym, przy zachowaniu należytej staranności podczas przygotowania i prowadzenia postępowania, nie wystąpi konieczność udzielenia kolejnego zamówienia temu samemu wykonawcy. Do tego rodzaju narzędzi należy zaliczyć przepisy odnoszące się do specyfikacji technicznych (opisu przedmiotu zamówienia), które umożliwiają zamawiającemu określenie przedmiotu zamówienia nie tylko za pomocą norm, ale również za pomocą wymagań funkcjonalnych 6. Daje to m.in. możliwość sformułowania wymogu, aby zaproponowane przez wykonawcę rozwiązanie bądź też system był kompatybilny z innymi dostępnymi na rynku rozwiązaniami technicznymi, tak aby konieczność rozbudowy takiego systemu nie powodowała automatycznie konieczności korzystania z rozwiązań technicznych oferowanych tylko przez wykonawcę systemu. Zamawiający może również już w zamówieniu na budowę systemu przewidzieć możliwość jego dostosowania bądź rozbudowy w trakcie jego funkcjonowania. Tym samym, już w zamówieniu podstawowym, przeprowadzonym w procedurze konkurencyjnej możliwe byłoby wyłonienie wykonawcy, który odpowiadałby zarówno za budowę, wdrożenie, jak i ewentualną rozbudowę czy modyfikację systemu. Istotne z punktu widzenia zasad konkurencji, równego traktowania i zasady przejrzystości jest, aby wszelkie informacje dotyczące przedmiotu zamówienia oraz zakresu przewidywanych zmian zawarte zostały w dokumentacji postępowania i były dostępne wszystkim zainteresowanym wykonawcom. Tym samym, zamawiający przewidując, konieczność prawidłowej eksploatacji i utrzymania oraz możliwość rozbudowy, czy też modyfikacji, dedykowanego dla niego systemu informatycznego powinien objąć zamówieniem podstawowym możliwie najszerszy zakres realizacji, włącznie z utrzymaniem, eksploatacją i ewentualnymi modyfikacjami, bądź też zapewnić sobie taki zakres uprawnień do niego i wiedzy o nim, który będzie mu pozwalał na udzielenie takiego zamówienia bez zgody pierwotnego wykonawcy systemu, a więc w jednym z trybów konkurencyjnych. Specyfikacja techniczna przedmiotu zamówienia jest jednak tylko częścią dokumentacji zamówienia, na co wskazuje w szczególności art. 36 ust. 1 pkt 16 ustawy Pzp. Integralną częścią specyfikacji istotnych warunków zamówienia są też istotne dla stron postanowienia umowy. W przypadku zamówień dotyczących systemów informatycznych, w których może zdarzyć się sytuacja, kiedy niektórych zmian w istniejącym systemie nie da się przewidzieć, właściwie określone postanowienia umowy pozwalają zabezpieczyć interesy zamawiającego. Z tego względu zamawiający powinien w umowie na budowę systemu zagwarantować sobie przeniesienie majątkowych praw autorskich do danego systemu, w takim zakresie, aby bez przeszkód ewentualne zamówienie na poprawki bądź rozbudowę systemu mógł powierzyć również innemu wykonawcy, wybranemu w procedurze konkurencyjnej. 5 Dyrektywa 2004/18/WE, art. 23 ust. 2 6 art. 23 ust 3 Dyrektywy 2004/18/WE 9
11 Zamawiający chcąc uzyskać prawo do swobodnej rozbudowy i modyfikacji systemu informatycznego powinien przede wszystkim w umowie o zamówienie publiczne zawrzeć postanowienia dotyczące: $ przeniesienia autorskich praw majątkowych do zakupywanego systemu, łącznie z prawem na udzielania zezwoleń na wykonywania zależnego prawa autorskiego; zamawiający w zależności od swoich potrzeb powinien szczegółowo i jednoznacznie określić pola eksploatacji obejmujące autorskie prawa majątkowe (np. uprawniające zamawiającego do modyfikacji oprogramowania, jego kodów źródłowych itp.); $ przeniesienie praw powinno dotyczyć również kodów źródłowych w stosunku do nowoutworzonego systemu, ich swobodnej modyfikacji; jednocześnie, zamawiający powinien zobowiązać wykonawcę w umowie do wydania kodów źródłowych oraz pełnej dokumentacji technicznej systemu; $ warunki gwarancji jakości powinny być tak zapisywane, by nie ograniczyć lub wyłączyć uprawnień zamawiającego z posiadania autorskich praw majątkowych, zatem modyfikacja oprogramowania, jego kodów źródłowych prowadzona niezależnie od pierwotnego wykonawcy nie powinna mieć wpływu na uprawnienia zamawiającego wynikłe z gwarancji udzielonej przez wykonawcę; $ w zawieranej umowie powinna być jednocześnie uregulowana kwestia ewentualnego przeniesienia na zamawiającego praw do licencji lub sublicencji oprogramowania niezbędnych do prawidłowego funkcjonowania zamawianego systemu; postanowienia przyszłej umowy powinny zawierać takie zapisy, aby warunki udzielanych przez wykonawcę licencji nie stanowiły bariery do dokonania modyfikacji lub rozbudowy oprogramowania. Należy jednocześnie mieć na uwadze i zapewnić, aby ewentualne przeniesienie autorskich praw majątkowych do oprogramowania, kodów źródłowych, przekazanych przez wykonawcę licencji i sublicencji zostało dokonane w ramach wynagrodzenia za system informatyczny. Zamawiający powinien mieć też na względzie: $ ewentualną konieczność rozbudowy, czy modyfikacji zamawianego oprogramowania, wątpliwości bowiem rodzi sytuacja, gdy konieczność rozbudowy systemu następuje niezwłocznie po zawarciu umowy podstawowej, czyli z reguły przed przeniesieniem autorskich praw majątkowych do zamawianego systemu; $ połączenie w jednym postępowaniu zakupu oprogramowania (licencji) oraz jego aktualizacji w przypadku, gdy do właściwego korzystania z zamawianego oprogramowania konieczna jest jego aktualizacja. Należy jednocześnie podkreślić, że wszystkie najistotniejsze informacje powinny być dostępne dla wszystkich zainteresowanych wykonawców od początku postępowania o udzielenie zamówienia publicznego. Jest to istotne ze względu na wspólnotowe zasady niedyskryminacji i przejrzystości, których efektem jest też zakaz wprowadzania zmian w zawartych umowach o zamówienie publiczne. Powyższe znajduje potwierdzenie w orzecznictwie ETS, zgodnie z którym zmiana istotnego warunku umowy w czasie trwania zamówienia, w braku wyraźnego upoważnienia w tym zakresie w ramach postanowień pierwotnego zamówienia, stanowi zagrożenie powstania naruszenia zasad przejrzystości i równego traktowania oferentów 7. Wszelkie istotne zmiany powinny zatem być traktowane jako konieczność udzielenia nowego zamówienia. Według ETS zmiana zamówienia publicznego w czasie jego trwania może być uznana za istotną m.in. w sytuacji, kiedy: $ wprowadza warunki, które gdyby zostały ujęte w ramach pierwotnej procedury udzielania zamówienia, umożliwiłyby dopuszczenie innych oferentów niż ci, którzy zostali pierwotnie dopuszczeni lub umożliwiłyby dopuszczenie innej oferty niż ta, która została pierwotnie dopuszczona, 10 7 Sprawa C-454/06, pkt. 60
12 $ w sposób znaczący poszerza zamówienie o usługi, które pierwotnie nie były w nim przewidziane, $ modyfikuje równowagę ekonomiczną umowy na korzyść usługodawcy w sposób, który nie był przewidziany w postanowieniach pierwotnego zamówienia. 8 Podkreślenia wymaga, iż to na zamawiającym ciąży obowiązek takiego kształtowania postępowania z dołożeniem należytej staranności, aby przewidzieć wszelkie możliwe do przewidzenia w danym momencie skutki podjętych, bądź zaniechanych działań i jednocześnie to zamawiający ponosi za to kształtowanie pełną odpowiedzialność. Stąd też, w przypadku zamówień skomplikowanych co do przedmiotu oraz rozłożonych w czasie, dotyczących powiązanych ze sobą funkcjonalnie przedmiotów, w szczególności o mieszanym charakterze łączącym w sobie co najmniej dwa spośród trzech zamówień tj. dostaw, usług i robót budowlanych, niezwykle istotne jest określenie horyzontu czasowego i przedmiotowego zamówienia lub grupy powiązanych ze sobą zamówień z możliwie najwyższą starannością zgodnie z pełnym stanem posiadanej w danym momencie wiedzy. Ten bowiem moment jest w przeważającej większości przypadków decydujący dla wszelkich dalszych zamówień, w tym też takich, których przewidzenie w momencie początkowym nie było obiektywnie możliwe. Tylko takie kształtowanie procesu zamówienia, które uwzględnia kompleksowo wymienione uwarunkowania pozwolić może na zachowanie najwyższej możliwej konkurencyjności postępowania oraz idącej za tym również racjonalności wydatkowania środków publicznych zgodnie z zasadą konieczności uzyskiwania możliwie najlepszych efektów przy minimalizacji kosztów, a także zgodnie z obowiązującym w tym zakresie Pzp, nie tylko na etapie inicjalnym, ale także w jego dalszych, w tym trudno, bądź nieprzewidywalnych etapach. Wydaje się, iż budując system informatyczny, szczególnie dedykowany do pewnych ściśle określonych zadań, o znacznym stopniu skomplikowania i unikatowości zastosowanych rozwiązań, w oparciu o architekturę otwartą nie sposób wprawdzie przewidzieć wszelkich możliwych potrzeb dotyczących jego utrzymania, rozwoju i modyfikacji. Jednakże sam fakt, iż takie potrzeby występują już po zbudowaniu systemu i są one nierozerwalnie związane z funkcjonowaniem systemu jest oczywisty i powszechnie znany. W celu eliminacji negatywnego zjawiska unikania stosowania trybów konkurencyjnych w przypadku zamówień dotyczących systemów IT niezbędne jest zatem takie kształtowanie procesu szeroko pojętego udzielania zamówienia publicznego, aby było ono konkurencyjne w możliwie największym stopniu/największej jego części. W przeciwnym bowiem przypadku wykonawcy będą mieli słuszne prawo skarżenia zamawiających, a przy tak wielkiej skali zamówień również Polski przed KE. Podkreślić należy również jednoczesne negatywne skutki takiego działania dla racjonalności wydatkowania środków publicznych oraz ograniczenia postępu technicznego i organizacyjnego wykonawców przez brak wymuszania takiego postępu konkurencją rynkową. Skala i zakres zjawiska nadużywania przez zamawiających trybu z wolnej ręki wywołuje duży niepokój. Stąd też by ustrzec przed nieuzasadnionym stosowaniem zamówienia z wolnej ręki UZP przygotował rekomendacje w zakresie właściwego przeprowadzania postępowania w taki sposób, by wyeliminować lub ograniczyć ryzyko późniejszej konieczności stosowania tego trybu. Powoływanie się przez zamawiającego na okoliczności faktyczne mające uzasadniać stosowanie trybu zamówienia z wolnej ręki w zakresie IT, które jednak wynikają z błędów popełnianych na etapie pierwotnego postępowania o udzielenie zamówienia publicznego, w szczególności wskazanych w Rekomendacjach, może być traktowane jako obiektywnie nieuzasadniające stosowanie trybu zamówienia z wolnej ręki. 8 Ibidem, pkt
13 2. Słownik pojęć 1. Cykl życia systemu informatycznego ciąg następujących po sobie faz związanych z funkcjonowaniem systemu w organizacji od jego zbudowania aż po wycofanie z użytkowania. 2. Dedykowany system informatyczny system informatyczny zbudowany na wyłączne zamówienie danego zamawiającego, system taki odznacza się unikatowością rozwiązań technicznych, sposobu i zasad działania. 3. Konfigurowalny system specjalizowany system komercyjny dostępny na warunkach licencji, stanowiący tym samym oprogramowanie z pudełka, ale odznaczające się szerokimi możliwościami konfiguracji i dostosowania do potrzeb Zamawiającego (przykładem są systemy klasy ERP). 4. Architektura usługowa, magistrale usług architektura, w której system informatyczny jest konstruowany z pewnej liczby wytwarzanych i eksploatowanych niezależnie podsystemów, reprezentowanych na zewnątrz przez tzw. usługi (funkcje o określonych interfejsach, parametrach i funkcjonalności), między którymi zachodzi wymiana informacji celem realizacji procesów obejmujących zasięgiem więcej niż jeden system. Magistrala usług jest systemem zapewniającym wymianę informacji między niezależnymi podsystemami. 5. Incydent [w eksploatacji systemu] każde niestandardowe zdarzenie w działaniu systemu, które może utrudniać lub uniemożliwiać realizację funkcji systemu. 6. Problem [w działaniu systemu] ukryta przyczyna incydentów, której usunięcie wymaga zmian w konfiguracji lub konstrukcji systemu. 7. Metody oceny architektury metody stosowane do oceny wpływu architektury na zasadnicze atrybuty systemu (np. metoda ATAM ang. Architecture Trade-off Analysis Method opracowana przez Carnegie Mellon University polegająca na budowie zbioru tzw. scenariuszy jakościowych reprezentujących różne czynniki wpływające/mogące wpływać na działanie systemu lub jego konstrukcję w tym np. możliwe zmiany, pojawienie się nowych wymagań). 8. Kanoniczny model danych model danych niezależny od jakiejkolwiek specyficznej aplikacji, określający wspólne dla całego systemu formaty wymiany danych tych samych typów. 9. Architektura systemu informatycznego struktura systemu informatycznego wyznaczona jego komponentami składowymi i występującymi między nimi powiązaniami. 10. Interoperabilność zdolność systemów do wymiany danych z innymi systemami. 11. Pzp ustawa z dnia 29 stycznia 2004 r. Prawo zamówień poublicznych (Dz. U. z 2007 r. Nr 223, poz oraz z 2008 r. Nr 171, poz. 1056). 12. Środowisko deweloperskie, testowe i produkcyjne systemy informatyczne przeznaczone odpowiednio do prowadzenia prac programistycznych, do testowania oprogramowania i do prowadzenia rzeczywistej eksploatacji systemu. Środowisko testowe jest zwykle podobne do środowiska produkcyjnego, lecz cechuje się niższą odeń wydajnością. 12
14 3. Struktura rekomendacji Zjawisko udzielania w trybach niekonkurencyjnych, szczególnie w trybie z wolnej ręki zamówień dotyczy w przeważającej większości: $ zlecania prac nad rozbudową systemów informatycznych zamówionych pierwotnie w trybach konkurencyjnych; $ zamawiania usług, oprogramowania lub sprzętu niezbędnego do utrzymywania infrastruktury lub oprogramowania gotowego nabytego w trybach konkurencyjnych. Źródłem opisanego tu zjawiska jest zatem powstanie uzależnienia zamawiającego od pierwotnego wykonawcy systemu lub producenta sprzętu lub oprogramowania gotowego uniemożliwiające nabycie niezbędnych usług lub dostaw w trybach konkurencyjnych. Zasadnicze przyczyny opisanego zjawiska to: 1. Relacje umowne między wykonawcą a zamawiającym uniemożliwiające zlecenie prac rozwojowych podmiotowi wyłonionemu w warunkach konkurencyjnych; 2. Przyjęcie zbyt wąskiego zakresu zamówienia poprzez zignorowanie usług lub produktów związanych z pierwotnym zamówieniem, których nie będzie potem można nabyć w trybie konkurencyjnym; 3. Doraźne, bezplanowe prowadzenie rozwoju systemów informatycznych prowadzące do powstania przedwczesnych uzależnień od pojedynczych wykonawców / dostawców systemów informatycznych; 4. Architektura systemu utrudniająca prowadzenie rozwoju systemu przez wykonawców wyłonionych w trybach konkurencyjnych; 5. Niska jakość systemu i jego dokumentacji (lub jej brak) uniemożliwiająca transfer wiedzy do wykonawcy wyłonionego z zachowaniem konkurencji. Jakość, Architektura Zamawianie systemów IT Organizacja i planowanie rozwoju systemów informatycznych Rys. 1. Obszary działań niezbędnych dla ograniczenia udzielania zamówień na systemy informatyczne w trybie z wolnej ręki 13
15 Ograniczenie tego zjawiska wymaga działań w 3 zasadniczych obszarach przedstawionych na rys. 1: 1. Organizacji i planowania rozwoju systemów informatycznych; 2. Przygotowywania i prowadzenia postępowań na systemy informatyczne; 3. Architektury i jakości systemów informatycznych. Warto podkreślić, że wymienione wyżej obszary działania należy traktować zgodnie z przedstawionym diagramem, tj. obszary działań położonych niżej stanowią podstawę, a często też warunkują efektywność, działań umiejscowionych na wyższym poziomie piramidy. Poszczególne rekomendacje mogą się okazać przydatne także w doraźnym stosowaniu, niemniej w przypadku dużych organizacji i systemów informatycznych maksymalizacja wykorzystania trybów konkurencyjnych wymaga najczęściej podjęcia całej przedstawionej piramidy działań i związanych z nimi rekomendacji. Rekomendacje przedstawione w rozdziale 3 zestawiono w poniższej tabeli przypisując je do odpowiednich obszarów przedstawionych wyżej. Tabela. Przypisanie rekomendacji do obszarów działań Lp. Obszar działań Oznaczenia rekomendacji 1 Organizacja i planowanie rozwoju systemów IT R1, R2, R6 2 Zamawianie systemów IT R3, R7 3 Architektura i jakość R3, R4, R5, R6 14
16 4. Rekomendacje 4.1. Rekomendacja 1: planowanie rozwoju systemów informatycznych w organizacji Zamawiającego Wprowadzenie problemowe Coraz częściej podmioty objęte PZP wykorzystują dla swoich potrzeb pewną liczbę systemów informatycznych prowadząc ich ciągłą ewolucję i rozwój będące skutkiem wprowadzanych zmian, rozszerzeń, czy usuwania usterek. Systemy te coraz rzadziej funkcjonują niezależnie od pozostałych składników systemu, lecz zwykle wymieniają informacje z innymi podsystemami zapewniając wspólnie realizację procesów organizacyjnych. W tej sytuacji rosnącego znaczenia nabiera kwestia planowego budowania i rozwijania systemów informatycznych. Działanie takie ułatwia uniknięcie budowy rozwiązań wadliwych np.: $ powstanie systemów wyspowych / brak interoperabilności systemów tj. zdolności systemów do wymiany danych z innymi systemami, $ pokrywanie się funkcjonalności odrębnych systemów, $ rozproszenie i/lub powielenie zbiorów danych lub ich części prowadzące do niespójności; $ powstanie systemów niespójnych funkcjonalnie w efekcie stopniowego, nieprzemyślanego dodawania coraz większej liczby funkcji pozostających w luźnym związku z zasadniczym zadaniem systemu Treść rekomendacji Lp. R.1.1 Przedmiot zamówienia/ rodzaj rekomendacji Rekomendacja organizacyjna Treść rekomendacji Zamawiającym rozwijającym i utrzymującym systemy informatyczne o znacznej wartości zaleca się opracowanie tzw. polityki rozwoju systemów informatycznych. Polityka rozwoju systemów informatycznych winna określać zasady jakimi zamierza kierować się zamawiający w rozwoju systemów informatycznych. Dokument ten może obejmować w szczególności: $ wymagania odnośnie opracowywania i utrzymania planów rozwoju systemów informatycznych; $ zasady kształtowania architektury systemu; $ zasady określania i egzekwowania wymagań jakościowych; $ wymagania względem zdolności systemów do wymiany danych z innymi systemami (interoperabilność systemów); $ zakres praw przenoszonych przez wykonawcę na zamawiającego w toku realizacji zamówień na systemy informatyczne; $ wymagania odnośnie dokumentacji systemu; $ opis zasad udzielania zamówień na systemy informatyczne; $ inne istotne zasady, którym powinien podlegać rozwój systemów informatycznych. Polityka rozwoju systemów informatycznych powinna podkreślać i wspierać konkurencyjne udzielanie zamówień na systemy informatyczne i ich rozbudowę. Uzasadnienie Opracowanie, wdrożenie i przestrzeganie polityki rozwoju systemów informatycznych stanowi istotny element kształtowania kultury organizacyjnej i jej świadomości w zakresie planowania rozwoju systemów informatycznych i kształtowania ich struktury. Przyjęcie tych dokumentów uświadamia i określa kierunek działania zamawiającego w zakresie zasadniczych czynników warunkujących rozwijanie systemów informatycznych w warunkach konkurencji. 15
17 Lp. R.1.2. R.1.3 Przedmiot zamówienia/ rodzaj rekomendacji Rekomendacja organizacyjna Rekomendacja organizacyjna Treść rekomendacji Zamawiającym rozwijającym i utrzymującym systemy informatyczne o znacznej wartości zaleca się też opracowanie planu rozwoju systemów informatycznych. Plan jest w stosunku do polityki dokumentem o charakterze wykonawczym i powinien zawierać m.in.: $ określenie portfeli projektów z zakresu informatyzacji, określając ich wzajemne uzależnienia i powiązania; $ budżet projektów i ich portfeli oraz zasoby organizacji niezbędne do ich realizacji; $ harmonogram realizacji projektów i ich portfeli; $ plan udzielania zamówień na realizację projektów objętych niniejszym planem rozwoju systemów wraz ze wskazaniem trybów udzielania tych zamówień, określeniem niezbędnych usług przygotowawczych, doradczych i innych; $ określać wysokopoziomową architekturę systemów korporacyjnych; $ określać techniki integracji systemów; $ definiować metody i działania zmierzające do zagwarantowania zdolności systemów do wymiany danych z innymi systemami (interoperabilność systemów). Planując udzielanie zamówień na dalszy rozwój istniejących już systemów informatycznych lub administrację nimi należy uwzględnić czas niezbędny na przejęcie wiedzy przez nowego wykonawcę. Okres przekazywania wiedzy powinien zostać wyraźnie określony i wskazany w SIWZ i umowie z wykonawcą w adekwatnym do tego zadania okresie poprzedzającym zakończenie umowy. Uzasadnienie Rozwijanie systemów informatycznych w sposób zaplanowany pozwala uniknąć wielu sytuacji, w których nie jest możliwe zamawianie usług informatycznych w trybach konkurencyjnych. Por. rekomendacja 3. Przejęcie wiedzy o konstrukcji i działaniu systemu informatycznego jest zawsze procesem wymagającym odpowiedniej ilości czasu zależnej przede wszystkim od wielkości i złożoności systemu, ale także wielkości zespołu, umiejętności i doświadczenia oraz od sprawnego przepływu informacji od dotychczasowego wykonawcy. W skrajnych przypadkach jest to proces trwający wiele miesięcy. Sprawnemu przejęciu wiedzy przez nowego wykonawcę sprzyja zwykle zagwarantowanie możliwości jej pozyskiwania nie tylko z dokumentacji systemu, kodów źródłowych i konfiguracji, ale także bezpośrednio od poprzedniego wykonawcy. 16
18 4.2. Rekomendacja 2: zarządzanie informatyką w organizacji zgodnie z najlepszymi praktykami i standardami Wprowadzenie problemowe Istnieje obecnie wiele norm, standardów i wytycznych oraz zbiorów dobrych praktyk z zakresu zarządzania informatyką w organizacji zorientowanych na różne grupy odbiorców (np. metodyka ITIL, normy ISO (ISO i ISO ) oraz standard COBIT). Standardy te przedstawiają, jak powinno wyglądać zarządzanie informatyką w organizacji, by jak najlepiej i pełniej wspierać jej misję. Na ogólnym poziomie szczegółowości wydaje się, iż wszystkie te standardy wskazują na konieczność istnienia w organizacji między innymi następujących procesów: $ zarządzania konfiguracją, $ zarządzania zmianami, $ zarządzania wydawaniem, $ zarządzania incydentem, $ zarządzania problemem. Procesy zarządzania konfiguracją, zmianami i wydawaniem, jeśli zostały u zamawiającego prawidłowo zaimplementowane gwarantują, iż każda zmiana w konstrukcji systemu informatycznego jest przeprowadzana w ramach dobrze zdefiniowanej i kontrolowanej procedury zaczynającej się od zgłoszenia i zaakceptowania zmiany przez odpowiednio umocowanych decydentów, poprzez jej implementację, przetestowanie w środowiskach deweloperskim i testowym oraz przygotowanie wydania oprogramowania umożliwiającego dystrybucję zmiany w całym systemie. Z kolei procesy zarządzania incydentem oraz zarządzania problemem rozdzielają reakcję na pojedyncze usterki występujące w użytkowaniu systemu od rozwiązywania powtarzających się i nierozwiązywalnych na poziomie zarządzania incydentem problemów. W tym miejscu warto podkreślić, iż są to procesy odrębne i o ile proces zarządzania incydentem wymaga zwykle jedynie pewnego doświadczenia w administrowaniu systemem i dostępu do bazy wiedzy o typowych incydentach i sposobach reagowania na nie, o tyle realizacja procesu zarządzania problemem wymaga posiadania wiedzy szczegółowej na temat konstrukcji systemu, gdyż rozwiązanie problemu w działaniu systemu może wymagać zmiany jego wewnętrznej struktury, poprawek w kodzie źródłowym oprogramowania etc. Proces zarządzania problemem wiąże się także z omówionymi już procesami zarządzania konfiguracją, zmianą i wydawaniem (rozwiązanie problemu wymaga często zmian w systemie oraz przygotowania nowego wydania oprogramowania lub odpowiednich łat). Procesy te mogą i powinny być realizowane przez oddzielne zespoły. Problemem i wyzwaniem jest zapewnienie efektywnej współpracy między tymi zespołami. 17
19 Typowe błędy popełniane przez Zamawiających Lp. Określenie Komentarz B.2.1 Połączenie i uzależnienie procesów rozwoju systemu (zarządzanie zmianą) i jego bieżącego utrzymania (zarządzanie konfiguracją, zarządzanie incydentem) Utrzymanie systemu wymaga odmiennych kompetencji, aniżeli prowadzenie jego rozbudowy. W większości przypadków nie wymaga też dostępu do kodów źródłowych, do których wyłączne prawa posiada niekiedy autor systemu (w zależności od zapisów umownych), co jest stanem odwrotnym niż w przypadku rozwoju systemu. W efekcie połączenie tych dwóch istotnie różnych usług w jednym zamówieniu przenosi ograniczenie konkurencji wynikające z praw wyłącznych przysługujących podmiotowi rozwijającemu system na usługi utrzymania systemu, co do których brak jest ograniczeń prawnych i technicznych uniemożliwiających ich wykonanie przez podmiot inny aniżeli wykonawca prac rozwojowych. B.2.2 Udzielenie zamówienia na administrację systemem, obsługę incydentów, wsparcie eksploatacji systemu wykonawcy świadczącemu gwarancję na wykonany system lub dotychczasowemu wykonawcy w trybie wyłączającym konkurencję tj. w trybie z wolnej ręki Zgodnie ze standardami zarządzania systemami informatycznymi i dobrą praktyką procesy reagowania na incydenty i wsparcie eksploatacji systemu powinny być oddzielone od procesów wprowadzania zmian w systemie (stanowi element świadczenia gwarancji), wymagają także odmiennego zakresu wiedzy i kompetencji. Brak jest zatem przesłanek pozwalających na udzielenie zamówienia w trybie z wolnej ręki Treść rekomendacji 18 Lp. R.2.1 R.2.1.a R.2.1.b Przedmiot zamówienia/rodzaj rekomendacji Rekomendacja organizacyjna Rekomendacja organizacyjna Rekomendacja organizacyjna Treść rekomendacji Zarządzanie systemami informatycznymi winno być prowadzone zgodnie z odpowiednimi standardami (np. ITIL, ISO 20000, COBIT) i dobrymi praktykami w tym zakresie. Zaleca się certyfikację organizacji w zakresie zgodności systemu zarządzania usługami / systemami IT z odpowiednimi normami, w szczególności zamawiającym użytkującym / rozwijającym systemy o znacznej wartości. Procesy zarządzania zmianami (prowadzenie prac rozwojowych i rozwiązywania problemów) powinny być realizowane oddzielnie od procesów bieżącego utrzymania i konserwacji systemu (procesy zarządzania incydentami i konfiguracją). Wprowadzanie zmian w systemie powinno odbywać się w ramach dobrze zdefiniowanych i realizowanych procesów zarządzania zmianą, problemem i wydawaniem, których celem jest zminimalizowanie liczby i prawdopodobieństwa powstania zakłóceń w działaniu systemu w skutek zmian i uzupełnień wprowadzanych w systemie. Uzasadnienie Stosowanie sprawdzonych rozwiązań w zakresie zarządzania systemami IT nie tylko poprawia jakość funkcjonowania systemów IT w organizacji, ale także ułatwia zachowanie konkurencji w udzielaniu zamówień na dostawę systemów, usług i produktów informatycznych, co uszczegółowiono w rekomendacja 2.1.a 2.1.d. Rozdzielenie prac rozwojowych od bieżącego utrzymania systemu jest nie tylko dobrą praktyką, ale wynika również z odmienności kompetencji niezbędnych do ich przeprowadzania zasobów ludzkich. Prace te w większości przypadków mogą zostać więc rozdzielone między niezależne zespoły. Zastosowanie tej rekomendacji zmierza do rozdzielenia prac prowadzących do zmian w konstrukcji i działaniu systemu od prac administracyjnokonserwacyjnych.
20 Lp. R.2.1.c R.2.1.d R.2.2 Przedmiot zamówienia/rodzaj rekomendacji Rekomendacja organizacyjna Rekomendacja organizacyjna Rekomendacja organizacyjna Treść rekomendacji Zmiany przed wprowadzeniem do środowiska produkcyjnego powinny być testowane na oddzielnym środowisku (deweloperskim i/lub testowym) i po pozytywnym wyniku testów zatwierdzone do wprowadzenia /w przypadku dużych systemów IT rekomenduje się korzystanie z 3 środowisk: deweloperskiego, testowego i produkcyjnego/. Zaleca się, by wiedza o sposobach rozwiązania problemów i właściwych reakcjach na incydenty była gromadzona w sposób zaplanowany i uporządkowany. Usługi bieżącego zarządzania systemem (administracja, pomoc użytkownikom, etc.) winny być albo zamawiane łącznie z usługami w zakresie prac rozwojowych i gwarancji (najlepiej w ramach zamówienia początkowego udzielonego w trybie konkurencyjnym), albo powinny być zamawiane oddzielnie w trybie konkurencyjnym. Uzasadnienie Zalecenie to podobnie jak R.2.1.a i R.2.1.b zmierza do uniezależnienia prac rozwojowych lub innych prac wymagających zmian w budowie systemu od prac o charakterze utrzymaniowym. Zgromadzona wiedza o sposobach rozwiązywania problemów i reakcjach na incydenty pozwala zamawiającemu uniezależnić się w zakresie utrzymania systemu od jego wykonawcy. Warunkiem osiągnięcia tego celu jest zapewnienie przepływu informacji między zespołami realizującymi te dwa zadania. Wg opisanych w rekomendacji R.2.1.a-d zasad zarządzanie bieżące systemami powinno być rozdzielone od procesów wprowadzania zamian (rozwój, rozwiązywanie problemów). Wymaga też ono kadr i wiedzy innego rodzaju niż prowadzenie prac rozwojowych. W prawidłowo zarządzanym systemie powinna być możliwa realizacja tych prac niezależnie przy zachowaniu współpracy między odpowiednimi zespołami Rekomendacja nr 3: Konstruowanie zamówienia z uwzględnieniem cyklu życia systemu Wprowadzenie problemowe Analizując funkcjonowanie systemów informatycznych w podmiotach podlegających Pzp można z grubsza wyróżnić następujące fazy: 1. Fazę koncepcyjną dotyczy ona wszystkich czynności związanych z określeniem potrzeb, przeglądem dostępnych rozwiązań, oceną możliwości ich zrealizowania u zamawiającego; 2. Faza wyboru wykonawcy obejmuje czynności zmierzające do wyłonienia Wykonawcy wyspecyfikowanego systemu zwieńczone podpisaniem umowy z Wykonawcą; 3. Faza wykonania i odbioru obejmuje realizację umowy z Wykonawcą zakończoną odbiorem zamówionego systemu i wprowadzeniem go do bieżącej eksplotacji; 4. Faza eksploatacji i dalszego rozwoju zbudowany system jest użytkowany przez Zamawiającego i administrowany przez odpowiednie służby Zamawiającego lub przez wybranego w tym celu Wykonawcę. Jednocześnie odbiór systemu w aktualnym stanie rzeczy rzadko stanowi koniec jego rozwoju; wręcz przeciwnie: systemy informatyczne są najczęściej stale rozwijane równolegle z ich eksploatacją. Zmiany wprowadzane w systemach informatycznych wynikają z pojawiania się nowych wymagań (np. w skutek zmiany przepisów), wykrycia i usuwania usterek itp. 19