Wyrok KIO 1471/17 z 8 sierpnia 2017

I. Centrum Systemów Informacyjnych Ochrony Zdrowia w W. (zwane dalej Zamawiającym), prowadzi postępowanie na wykonanie zamówienia publicznego pn. Elektroniczna Platforma Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach M. (Projekt P1), jego utrzymanie i rozwój.

Ogłoszenie o zamówieniu zostało opublikowane w Dzienniku Urzędowym WE z dnia 5 lipca 2017 roku, poz. 2017/S126-256810. Zamawiający zamieścił specyfikację istotnych warunków zamówienia (dalej: SIWZ) na swojej stronie internetowej. Postępowanie prowadzone jest w trybie przetargu nieograniczonego na podstawie ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (t.j. Dz. U. z 2015, poz. 2164 z poźn. zm.; dalej: Prawo zamówień publicznych albo Ustawa).

W dniu 17 lipca 2017 r. wykonawca A. P. spółka akcyjna w R. dalej: (Odwołujący) wniósł odwołanie, w którym zarzucił Zamawiającemu naruszenie przepisów art. 7 ust. 1 i 3 Ustawy, art. 9a ust. 2 Ustawy, art. 29 ust. 1 Ustawy, art. 91 ust. 1 i ust. 2c i ust. 2d Ustawy, art. 139 ust. 2 Ustawy, art. 140 Ustawy, art. 144 Ustawy. Naruszenie powyższych przepisów

2

może zdaniem Odwołującego doprowadzić w konsekwencji do naruszenia przepisu art. 93 ust. 1 pkt. 7 Ustawy.

Odwołujący uzasadnił swoje zarzuty następująco:

1. Specyfikacja Istotnych Warunków Zamówienia: pkt. III Opis przedmiotu zamówienia, ppkt 1, ppkt 2, ppkt 5 „Informacja o opcjach" - brak wskazania przedmiotu zamówienia bez opcji, nadmierne wymagania dotyczące wyłączności personelu W pkt. III Opis przedmiotu zamówienia Zamawiający zamieścił ppkt 1 i 2 o brzmieniu:

„1. Przedmiotem zamówienia jest Dokończenie budowy Projektu pn. Elektroniczna Platforma Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (Projekt P1), jego utrzymanie i rozwój.

Część I zamówienia pn.: Dokończenie budowy Projektu pn. Elektroniczna Platforma Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (Projekt P1 ), jego utrzymanie i rozwój.

Część II zamówienia pn.: Dokończenie budowy Projektu pn. Elektroniczna Platforma Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (Projekt P1) oraz jego rozwój.

1. Szczegółowy opis przedmiotu zamówienia znajduje się dla:

Części I: w Załączniku nr lado SIWZ Opis przedmiotu zamówienia.

Części II: w Załączniku nr lb do SIWZ Opis przedmiotu zamówienia”.

Odwołujący podnosił, że wskazane powyżej postanowienia w ogóle nie zawierają Opisu przedmiotu zamówienia. Sformułowania w pkt. 1 są bardzo ogólne, właściwie ograniczają się do nazwy zamówienia, w żadnym przypadku nie można stwierdzić, że zawierają one chociażby minimalny opis przedmiotu zamówienia.

Ten sam zarzut można postawić ppkt. 2 w związku z treścią Załączników la i lb do SIWZ:

1. Załącznik nr 1a do SIWZ obejmuje 1,5 (słownie: półtorej) strony i zawiera: pkt. I, w którym wskazano 3 usługi (4 linijki tekstu);

3 pkt. II, w którym zawarto zobowiązanie do zatrudnienia na podstawie umowy o pracę przez cały okres realizacji zamówienia osób pełniących rolę Kierownika Projektu oraz Zastępcy Kierownika Projektu.

1. Załącznik nr 1a do SIWZ obejmuje 1 i 1/4 (słownie: jeden i jedną czwartą) strony i zawiera: pkt. 1, w którym wskazano 1 usługę (2 linijki tekstu); pkt. II, w którym zawarto zobowiązanie do zatrudnienia na podstawie umowy o pracę przez cały okres realizacji zamówienia osób pełniących rolę Kierownika Projektu oraz Zastępcy Kierownika Projektu.

Co więcej - załączniki te nie zawierają nawet żadnych odwołań do innych elementów SIWZ, w tym np. nie zawierają odwołań do Załączników, które opisują usługi. Oczywiście można się domyślać, że to Umowa i Załączniki do niej zawierają opis przedmiotu zamówienia. Przy czym wykonawcy na etapie sporządzania oferty nie powinni domyślać się treści SIWZ, czy też zakresu przedmiotu zamówienia, ale kwestie te powinny być wprost w SIWZ uregulowane.

Obecnie można przyjąć, że z naruszeniem art. 29 ust. 1 Prawa zamówień publicznych Zamawiający w ogóle nie zawarł w SIWZ opisu przedmiotu zamówienia. Brak ten powinien zostać naprawiony poprzez prawidłowe opisanie przedmiotu zamówienia w samym dokumencie SIWZ, w tym w załącznikach nazwanych przez Zamawiającego „Opis przedmiotu zamówienia".

Powyższy zarzut jest bardzo istotny zwłaszcza w kontekście brzmienia pkt. 5 „Informacja o opcjach". W pierwotnym brzmieniu pkt. ten miał brzmienie:

„5. informacja o opcjach:

W ramach przedmiotowego zamówienia są przewidziane opcje, zgodnie z poniższym zakresem:

Część I: Zamawiający gwarantuje 12% z Usług Tworzenia Oprogramowania i dwóch Usług Gwarancyjnych oraz 90% z pozostałych Usług Gwarancyjnych i Usług Autoryzacji Część II: Zamawiający gwarantuje 10% całości przedmiotu zamówienia" W dniu 13 Iipca 2017 roku Zamawiający opublikował modyfikacją SIWZ, między innymi w zakresie w/w pkt. 5 i nadał mu brzmienie:

„5. informacja o opcjach:

4 W ramach przedmiotowego zamówienia są przewidziane opcje, zgodnie z poniższym zakresem:

Część I: 90% Usług Tworzenia Oprogramowania, 100% Usług Autoryzacji, 100% Szkoleń oraz 50% Usług Gwarancyjnych.

Część lI: 90% Usług Tworzenia Oprogramowania oraz 100% Szkoleń" Pierwotnie przedmiotowe postanowienie nie odnosiło się nie do opcji, ale wręcz przeciwnie-do przedmiotu zamówienia NIE objętego opcjami. W treści pkt. 5 Zamawiający wskazywał, jakie części zamówienia będą wykonane na pewno. Natomiast w informacji o opcjach - zgodnie z logiką - Zamawiający powinien wskazać, te części zamówienia, które są opcją i być może zostaną zamówione. Błąd ten został poprawiony ww. modyfikacją SIWZ.

Z brzmienia w/w pkt 5 po modyfikacji wynika, że przedmiotem zamówienia w zakresie części I jest wyłącznie 10% Usług Tworzenia Oprogramowania i 50 % Usług gwarancyjnych, zaś w zakresie części II wyłącznie 10% Usług Tworzenia Oprogramowania. Istotne jest też, że Zamawiający nie określił, które Usługi gwarancyjne są opcją.

Z kolei Zamawiający wymaga dedykowania zespołu 84 osób do realizacji części I i 66 osób do realizacji części II zamówienia. W Załączniku nr 71 i 7b do SIWZ Zamawiający wymaga wskazana w ofercie listy 84 osób dla części I i 66 osób do części II, którymi dysponuje wykonawca do realizacji zamówienia. W treści załącznika zamieszczono oświadczenie:

„Wykonawca oświadcza, że do realizacji zamówienia dysponuje osobami, które posiadają następujące kwalifikacje i doświadczenie zawodowe wymienione poniżej w tabeli:"

Z powyższej treści można wnioskować, że Zamawiający oczekuje, aby Wykonawca dedykował do realizacji Umowy w zakresie części I zespół 84 osób i w zakresie części II zespół 66 osób.

Jednocześnie w Umowie brak jest zobowiązań Wykonawcy odnośnie w/w zespołu. Brak ten narusza art. 29 ust. 1 Ustawy, gdyż na etapie składania ofert nie jest jasne, czy przedmiotowy wymóg został przez Zamawiającego sformułowany jedynie jako podmiotowy warunek udziału w postępowaniu, czy też wolą Zamawiającego było, aby Wykonawca rzeczywiście dedykował zespół liczący aż 84 osoby (lub 66 w przypadku części II) na potrzeby realizacji Umowy. Z jednej strony - mając na uwadze istotność Projektu P1 - można uważać, że wolą Zamawiającego było, aby Wykonawca, który będzie realizować Umowę, zapewnił do realizacji tej Umowy duży, stabilny, dedykowany zespół. Znajduje to tez oparcie w szacunkowej wartości zamówienia podanej w SIWZ. Z drugiej zaś strony Umowa nie zawiera żadnych obowiązków

5 Wykonawcy w tym zakresie, w szczególności treść Załącznika nr 13 do Umowy w żadnym stopniu nie odwołuje się do Załączników 7a i 7b do oferty.

Powyższe braki naruszają z całą pewnością art. 29 ust. 1 Prawa zamówień publicznych i powinny zostać usunięte. Obecne brzmienie SIWZ powoduje, że każdy Wykonawca może inaczej zrozumieć brzmienie SIWZ w zakresie obowiązku zatrudnienia zespołu w okresie realizacji Umowy i inaczej w związku z tym oszacuje cenę oferty. Doprowadzi to do sytuacji, że złożone oferty będą nieporównywalne, gdyż ich cena będzie opierać się na innych założeniach w zakresie kosztów osobowych.

Inną kwestią powiązaną z powyższym jest relacja pomiędzy liczebnością dedykowanego zespołu a zakresem zamówienia. Jak wskazano powyżej właściwie całość przedmiotu zamówienia to opcje, Zamawiający gwarantuje jedynie 10% Usług Tworzenia Oprogramowania i 50% Usług Gwarancyjnych. Przy takim szerokie zakresie opcji i wąskim zakresie gwarantowanego przedmiotu zamówienia byłoby wymaganiem nadmiernym, aby Wykonawca miał obowiązek dedykować zespół aż 84 osób, skoro Wykonawca ma gwarancję realizacji przedmiotu umowy w bardzo małym zakresie. Liczebność zespołu powinna być powiązana zrealną wartością przedmiotu zamówienia. O ile zatem bardzo istotne jest, aby Zamawiający określił wprost w SIWZ obowiązki Wykonawcy odnośnie personelu, w tym w szczególności liczebność dedykowanego zespołu - to z całą pewnością wymaganie aż 84 osób przez cały okres realizacji umowy jest nadmierny.

Mając powyższe na uwadze Odwołujący wnosił o nakazanie Zamawiającemu:

1. prawidłowe opisanie przedmiotu zamówienia w samym dokumencie SIWZ, w tym w załącznikach nazwanych przez Zamawiającego „Opis przedmiotu zamówienia".
2. wskazanie w treści pkt. 5 „Informacją o opcjach", które Usługi Gwarancyjne objęte są opcją.
3. wskazanie w SIWZ zakresu obowiązków Wykonawcy odnośnie zapewnienia dedykowanego zespołu przez cały okres realizacji Umowy, w szczególności poprzez wskazanie, liczebności zespołu, kompetencji członków, przy czym liczebność zespołu powinna uwzględniać wielkość opcji: w szczególności z uwzględnieniem, że gwarantowany przedmiot zamówienia stanowi wyłącznie w części I: 10% Usług Tworzenia Oprogramowania i 50% Usług Gwarancyjnych, a w części II: 10% przedmiotu zamówienia.

6

1. Specyfikacja istotnych Warunków Zamówienia: Pkt III Opis przedmiotu zamówienia, ppkt 14 dotyczący wizji lokalnej Zamawiający zawarł w SIWZ postanowienia dotyczącej wizji lokalnej:

„14. Zamawiający na podstawie art. 9a ust 2 Prawa zamówień publicznych oraz w związku z wymogiem zawartym w Umowie wykorzystania produktów będących w posiadaniu Zamawiającego zapewni możliwość dostępu do posiadanych materiałów powstałych podczas realizacji I Fazy Projektu P1 oraz do materiałów, które dotyczą realizacji II Fazy Projektu P1 (w zakresie e-Recepty) podczas wizji lokalnej, która odbędzie się w siedzibie Zamawiającego.

Dostęp zostanie zapewniony potencjalnym Wykonawcom, najpóźniej na 10 dni przed terminem składania ofert. Każdy Wykonawca otrzyma dostęp do materiałów przez maksymalnie 3 dni w godz. 8:00 -16:00 przy jednym stanowisku."

Zamawiający nie zawarł w SIWZ żadnych dokumentów dotyczących opisu funkcjonalnego Projektu P1 w części już wykonanej. Sama nazwa postępowania - Dokończenie budowy Projektu pn. Elektroniczna Platforma Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (Projekt P1) - wskazuje, że Zamawiający jest już w posiadaniu Projektu P1 w jakiejś części, a tym samym - jest w posiadaniu dokumentacji opisującej ten Projekt.

Powyższe wynika także z treści w/w pkt 14. Zamawiający potwierdza w nim, że posiada materiały powstałe podczas realizacji I Fazy Projektu P1 oraz materiały, które dotyczą realizacji II Fazy Projektu P1 (w zakresie e-Recepty). Zdaniem Odwołującego materiały te - wobec faktu, ze opisują Projekt P1 - powinny stanowić część SIWZ jako element opisu przedmiotu zamówienia. Brak dołączenia tych materiałów do SIWZ stanowi naruszenie art. 29 ust. 1 i ust. 2 Prawa zamówień publicznych. Po pierwsze - Wykonawcy nie znają obecnie zawartości tych materiałów i nie mogą sporządzić oferty, po drugie - nie można wykluczyć sytuacji, że niektórzy wykonawcy (którzy tworzyli te materiały uprzednio na zlecenie Zamawiającego) będą mieli większą wiedzę na etapie tworzenia oferty, co z pewnością utrudnia zachowanie uczciwej konkurencji w postępowaniu.

Zastosowanie przez Zamawiającego instytucji wizji lokalnej wskazanej w art. 9a ust. 2 Prawa zamówień publicznych stanowi nadużycie. Z całą pewnością wizja lokalna dotyczy innej sytuacji, niż zapoznanie się z materiałami. Instytucja ta może być stosowana przykładowo przy zapoznaniu się z placem budowy. Jednakże materiały wskazywane przez Zamawiającego mogą być z całą pewnością udostępnianie jako załączniki do SIWZ.

7 Z kolei odnośnie dokumentów przepis art. 9a ust. 2 Prawa zamówień publicznych statuuje instytucję „sprawdzenia dokumentów". Tymczasem w celu złożenia oferty niezbędne jest zapoznanie się przez Wykonawców z materiałami, a nie ich „sprawdzenie". Tym samym Zamawiający w ogóle nie był uprawniony do zastosowania regulacji przepisu art. 9a ust. 2 Prawa zamówień publicznych.

Zastosowana przez Zamawiającego instytucja wizji lokalnej uniemożliwia Wykonawcom sporządzenie oferty.

Wykonawca może zapoznać się z tymi materiałami wyłącznie przez 3 dni, gdyż takie ograniczenie wprowadził Zamawiający. Co więcej - dostęp ten będzie możliwy najpóźniej 10 dni przed dniem złożenia ofert. Jeśli zaś po upływie tego terminu lub po wyczerpaniu limitu 3 dni dany Wykonawca poweźmie wątpliwości co do treści czy zawartości materiałów, nie będzie on uprawniony do żądania ponownego dostępu. Z całą pewnością uniemożliwia to sporządzenie oferty, gdyż Wykonawcy nie będą mieli w okresie ostatnich 10 dni przed dniem złożenia oferty dostępu do w/w materiałów i możliwości weryfikowania treści oferty w oparciu o te materiały.

W ocenie Odwołującego, obecnie mamy do czynienia z sytuacją, że - jak wykazano w zarzucie

1 - Zamawiający w ogóle nie zamieścił w SIWZ opisu przedmiotu zamówienia, a jednocześnie bezpodstawnie i bez uzasadnienia ogranicza Wykonawcom możliwość zapoznania się z posiadanymi materiałami.

Mając powyższe na uwadze Odwołujący wnosił o nakazanie Zamawiającemu:

1. wykreślenie pkt III ppkt 14 SIWZ;
2. dołączenia do SIWZ materiałów powstałych podczas realizacji I Fazy Projektu P1 oraz materiałów, które dotyczą realizacji II Fazy Projektu P1 (w zakresie e-Recepty).
3. Specyfikacja istotnych Warunków Zamówienia: Pkt XIII Opis kryteriów, którymi Zamawiający będzie się kierował przy wyborze oferty, wraz z podaniem wag tych kryteriów i sposobu oceny ofert - Kryterium oceny oferty „Cena brutto za Punkt Funkcyjny rozwijanego oprogramowania" w związku z treścią Załącznika nr 6 dla Części I oraz treścią Załącznika nr 4 dla Części II przedmiotu zamówienia przy braku w SIWZ określenia Strategii Wymiarowania.

Zamawiający jako jedno z kryteriów cenowych w obu częściach przedmiotu zamówienia wskazał cenę Punktu Funkcyjnego, doprecyzowanego w SIWZ oraz w załączniku „Zasady szacowania PF", jako Punkt Funkcyjny w rozumieniu metodyki COSMIC. Specyfikacja metody

8 COSMIC opisana jest w „Podręczniku Wymiarowania" metody COSMIC (oryginał:

„Measurement Manual") oraz w specyfikacji normy ISO/IEC 19761, którą to normę metoda COSMIC spełnia.

Zgodnie ze specyfikacją metody COSMIC wymiar liczbowy pomiaru w CFP musi być zawsze podawany wraz z jednoczesnym wskazaniem Strategii Wymiarowania, która była podstawą tego pomiaru.

„W rozdziale tym [przyp. Strategia Pomiaru] omówione są cztery parametry pomiaru funkcjonalnego rozmiaru oprogramowania, które należy wziąć pod uwagę przed podjęciem pomiaru, a mianowicie cel i zakres pomiaru oraz identyfikacje użytkowników funkcjonalnych i poziom granulacji. Określenie tych parametrów pomoże nam odpowiedzieć na pytanie, „który rozmiar powinniśmy mierzyć?" lub, jeśli chodzi nam o pomiaru już wykonany, „jak powinniśmy

go interpretować?" [źródło: Podręcznik Wymiarowania metody COSMIC 3.0.1 PL - rozdział 2, 1 akapit, pogrubienie własne Odwołującego] Wskazać należy, że miara rozmiaru oprogramowania w metodzie COSMIC (podobnie jak w innych analogicznych metodach, np. IFPUG) nie jest miarą metryczną. Oznacza to, iż nie istnieje jeden wzorzec ilości wyprodukowanego oprogramowania o rozmiarze 1 CFP (Cosmic Function Point). Zatem jednostka miary, jaką jest 1 CFP, nie jest taką samą, obiektywną i zawsze taką samą jednostką miary, jak np. wzorzec długości 1 m czy też wzorzec wagi 1 kg.

Zgodnie z metodą COSMIC taki wzorzec jest ustalany dla danego procesu pomiaru w dokumencie nazwanym Strategią Wymiarowania poprzez podanie wymaganych przez metodą COSMIC informacji. Metoda COSMIC to zbiór reguł i zasad pozwalających dla danego oprogramowania policzyć, ile jednostek wzorca „ilości", tj. ile CFP jest w tym oprogramowaniu.

Przy czym takie wyliczenie jest możliwe wyłącznie w przypadku, jeśli jedną z danych istniejących dla tego pomiaru jest ustalona wcześniej Strategia Wymiarowania. Tym samym bez określenia specyficznej dla danego oprogramowania Strategii Wymiarowania dla danego CFP sama określona liczba CFP jest wartością nieokreśloną, nieweryfikowalną oraz - co najważniejsze - wartością, która może być zupełnie inaczej rozumiana i używana przez każdego z wykonawców, a jeszcze inaczej - przez Zamawiającego. Bez określenia Strategii Wymiarowania nie jest możliwie stwierdzenie, jakiej „ilości" oprogramowania odpowiada 1 CFP.

W konsekwencji brak Strategii Wymiarowania powoduje, że nie jest możliwe obiektywne podanie rozmiaru oprogramowania w konkretnej liczbie CFP - obiektywne, czyli takie, które będzie porównywalne u kilku wykonawców. Zgodnie z zapisami podręcznika COSMIC wartości

9 liczbowe Punktu Funkcyjnego bez określenia Strategii Wymiarowania nie mogą być wykorzystywane do porównywania. ,,Podczas rejestrowania wyników jakiegokolwiek pomiaru, należy zarejestrować dane w powstałe w fazie Strategii Pomiaru {jak wymieniono w części 5.2). Niepowodzenie w zdefiniowaniu i zarejestrowaniu tych danych, może prowadzić do uzyskania pomiarów, które

nie mogą być interpretowane jako wiarygodne> porównywalne czy też wykorzystane jako dane wejściowe w procesach takich jak szacowanie projektów." [źródło: Podręcznik Wymiarowania metody COSMIC 3.0.1 PL - rozdział 2,3 akapit] Część 5.2, do której zamieszczono odwołanie w powyższym cytacie, zawiera regułę metody COSMIC - Reguła: Raportowanie pomiarów COSMIC wskazujące, jakie dane powinny być dodatkowo przedstawione wraz z wynikiem wymiarowania COSMIC. Dopiero znając te dane jest możliwe zinterpretowanie liczby Punktów Funkcyjnych i wykorzystanie jej np. do porównania.

Jak wynika z powyższego bez określenia Strategii Wymiarowania w SIWZ każdy z wykonawców oferuje za 1 Punkt Funkcyjny inną ilość oprogramowania, a zatem ceny za 1 Punkt Funkcyjny różnych wykonawców są nieporównywalne. Jeśli zaś cena 1 PF nie jest mierzalna i porównywalna według tych samych zasad, nie może być podstawą oceny ofert gdyż nie jest kryterium obiektywnym. Oznacza to w dalszej kolejności, iż wartości liczbowe w kryterium „Cena brutto za Punkt Funkcyjny rozwijanego oprogramowania" również nie mogą być porównywane, gdyż dla każdego wykonawcy dotyczą innej - nieznanej Zamawiającemu ilości oprogramowania, jaką dostarczy w tej cenie dany wykonawca. Zatem nie jest spełniona zasada prowadzenia postępowania z zachowaniem uczciwej konkurencji oraz równego traktowania wykonawców. Przedmiotowy brak SIWZ narusza także kolejne zasady określone w art. 7 Prawa zamówień publicznych - tj. zasadę proporcjonalności i przejrzystości. Nie można bowiem mówić o zachowaniu zasady przejrzystości w sytuacji, gdy - wobec braku w SIWZ Strategii Wymiarowania - kryterium ceny przestaje być kryterium obiektywnym i porównywalnym.

Odwołujący podkreślał, że przedmiotowy brak powoduje także negatywne skutki dla Zamawiającego. Przy obecnym brzmieniu SIWZ Zamawiający nie będzie mógł w żaden sposób kontrolować „ilości" oprogramowania wytworzonego w ramach 1 PF przez wykonawcę, z którym Zamawiający zawrze umowę. Przy braku Strategii Wymiarowania każda ilość oprogramowania wytworzona w ramach 1 PF będzie musiała zostać przez Zamawiającego uznana za prawidłową, nawet, jeśli będzie to minimalna ilość oprogramowania.

10 W celu zlikwidowania powyżej wskazanych braków i zapewnienia porównywalności ofert w kryterium „Cena brutto za Punkt Funkcyjny rozwijanego oprogramowania" poprzez jednoznaczne wskazanie wymaganej przez siebie „ilości" oprogramowania w 1 PF niezbędne jest uzupełnienie SIWZ o Strategię Wymiarowania Oprogramowania P1, zawierającą wskazane w rozdziale 5 Podręcznika Wymiarowania metody COSMIC informacje specyficzne dla Oprogramowania P1.

Aktualnie SIWZ nie zawiera Strategii Wymiarowania w rozumieniu metody COSMIC. SIWZ zawiera co prawda dla Części I - Załącznik 6 do Umowy „Zasady szacowania PF" oraz dla Części II - Załącznik 4 do Umowy „Zasady szacowania PF", jednakże treść tych załączników nie może być uznana w żaden sposób za równoważną Strategii Wymiarowania (obligatoryjnej zgodnie z zasadami metody COSMIC).

Być może przedmiotowy brak SIWZ wynika z faktu, że niniejsze postępowanie jest pierwszym postępowaniem prowadzonym przez Zamawiającego, w którym Zamawiający jako kryterium ceny ofert używa ceny 1 PF, co powoduje, że Zamawiający nie ma ani odpowiedniego doświadczenia w tym zakresie, ani też świadomości, w jaki sposób osiągnąć zarówno konkurencyjność, jak i porównywalność ofert. Odwołujący wskazuje, że we wszystkich znanych mu postępowaniach, w których cena oferty określana była przez cenę 1 Punktu Funkcyjnego, Zamawiający zawsze zamieszczali w SIWZ odpowiednie Strategie Wymiarowania. Wskazać tutaj należy:

1. Postępowanie prowadzone przez K. na „Usługi rozwoju systemu W. oraz jego utrzymanie, a także związane z nim usługi integracyjne", gdzie zastosowano metodę COSMIC, a Załącznik nr 6 do SIWZ „Wymiarowanie Modyfikacji metodą COSMIC" zawiera Strategię Wymiarowania zgodną z normą ISO/IEC19761,
2. Postępowanie prowadzone przez KRUS na „Kompleksową obsługę i rozwój systemów informatycznych wspomagających obsługę ubezpieczeń i świadczeń krótkoterminowych", gdzie zastosowano metodę COSMIC, a Załącznik nr 11 „Standardy analizy i projektowania" zawiera Strategię Wymiarowania zgodną z normą ISO/IEC 19761,
3. Postępowanie prowadzone przez KRUS na „Kompleksową obsługę systemu informatycznego wspomagającego obsługę świadczeń emerytalno-rentowych rolników", gdzie zastosowano metodę COSMIC, a Załącznik nr 11 „Standardy analizy i projektowania" zawiera

Strategię Wymiarowania zgodną z normą ISO/IEC 19761,

11

1. Postępowanie prowadzone przez Z. na „Rozwój Platformy Usług Elektronicznych" gdzie zastosowano metodę COSMIC, a SIWZ zawiera Podręcznik Wymiarowania dla Systemów Informatycznych ZUS, obejmujący Strategię Wymiarowania zgodną z normą ISO/IEC 19761,
2. Postępowanie prowadzone przez Z. na „Rozbudowa i wdrożenie nowych funkcjonalności oraz utrzymanie i rozwój systemu Elektronicznej Platformy Wymiany Danych (EPWD) oraz budowa Centralnego Rejestru Klientów Zakładu (CRKZ)", gdzie zastosowano metodę COSMIC, a SIWZ zawiera Podręcznik Wymiarowania dla Systemów Informatycznych ZUS, obejmujący Strategię Wymiarowania zgodną z normą ISO/IEC 19761,
3. Postępowanie prowadzone przez Urząd M. S. W. (…) na „Budowa, wdrożenie i serwis zintegrowanego systemu informatycznego do obsługi zasobu geodezyjnego i kartograficznego rn.st. Warszawy", gdzie zastosowano metodę COSMIC, a SIWZ zawiera Podręcznik Wymiarowania, obejmujący Strategię Wymiarowania zgodną z normą ISO/IEC 19761,
4. Postępowanie prowadzone przez A. na „Utrzymanie, modyfikacje i ulepszanie systemów aplikacyjnych OFSA, OFSA-PROW, OFSA-PROW-DD, RG-PROW", gdzie zastosowano metodę IFPUG, a SIWZ zawiera Podręcznik Wymiarowania, obejmujący Strategię Wymiarowania zgodną z normą ISO/IEC 19761, 8} Postępowanie prowadzone przez A. na „Utrzymanie i rozwój systemów aplikacyjnych OFSA, OFSA-PROW, OFSA-PROW-DD, RG.PROW", gdzie zastosowano IFPUG, a SIWZ zawiera Podręcznik Wymiarowania, obejmujący Strategię Wymiarowania zgodną z normą ISO/IEC 19761,
5. Postępowanie prowadzone przez A. na: „UTRZYMANIE I ROZWÓJ APLIKACJI SIA, PA, PZSIP, FOTO SIP NA LATA 2013-2015", gdzie zastosowano IFPUG, a SIWZ zawiera Podręcznik Wymiarowania, obejmujący Strategię Wymiarowania zgodną z normą ISO/IEC 19761,
6. Postępowanie prowadzone przez A. na „Utrzymanie i rozwój aplikacji EBS" , gdzie zastosowano IFPUG, a SIWZ zawiera Podręcznik Wymiarowania, obejmujący Strategię Wymiarowania zgodną z normą ISO/IEC 19761,
7. Postępowanie prowadzone przez A. na „Utrzymanie, Rozwój i Modyfikacje Aplikacji EBS oraz zmiana wersji Aplikacji EBS z wersji nr 11 na wersję nr 12", gdzie zastosowano IFPUG, a SIWZ zawiera Podręcznik Wymiarowania, obejmujący Strategię Wymiarowania zgodną z normą ISO/IEC 19761,

12

1. Postępowanie prowadzone przez A. na „Utrzymanie i Rozwój Systemu Informatycznego Agencji - SIA (ZSZiK, lACSplus, GIS, SIZ, PZSIPplus, PA)" , gdzie zastosowano IFPUG, a SIWZ zawiera Podręcznik Wymiarowania, obejmujący Strategię Wymiarowania zgodną z normą ISO/IEC 19761.

Odwołującemu nie jest znane żadne postępowanie o udzielenie zamówienia publicznego porównywalnej wielkości, w którym z jednej strony cena oferty czy też element ceny oferty określana byłyby jako cena 1 Punktu Funkcyjnego, a jednocześnie Zamawiający nie określiłby w SIWZ dla takiego postępowania Strategii Wymiarowania w rozumieniu normy ISO/IEC 19761.

Wskazane powyżej braki SIWZ, które skutkują brakiem porównywalności i niemożliwością weryfikacji ofert w zakresie kryterium cena naruszają przepis art. 91 ust. 2c i 2d Ustawy.

Zamawiający ma obowiązek tak określić kryteria oceny ofert w SIWZ, aby kryteria te były jednoznaczne i zrozumiałe oraz - co według Odwołującego najważniejsze - umożliwiały sprawdzenie informacji przedstawionych przez wykonawców. W przypadku braku uzupełnienie SIWZ o wskazane treści z zakresu Strategii Wymiarowania kryterium ceny 1 Punktu Funkcyjnego staje się kryterium niejednoznacznym i niemożliwym do weryfikacji.

Mając powyższe na uwadze Odwołujący wnosił o:

1. Uzupełnienie Załącznika 6 do Umowy dla Części I oraz Załącznika 4 do Umowy dla Części II lub innej części SIWZ) o Strategię Wymiarowania Oprogramowania P1, spełniającą wymogi metody COSMIC, a uwzględniające w szczególności: a) Wskazanie dokładnych definicji przypadków użycia jako procesów funkcjonalnych dla poszczególnych składowych dokumentacji Oprogramowania P1 oraz wskazanie przykładowych

przypadków użycia jako procesów funkcjonalnych b) Określenie zasad postępowania w przypadku gdy dany przypadek użycia w dokumentacji Oprogramowania P1 nie spełnia definicji procesu funkcjonalnego w Strategii Wymiarowania fiest np. technicznym przypadkiem użycia) c) Określenie zasad postępowania w przypadku powiązanych ze sobą przypadków użycia za pomocą relacji notacji UML: włączania, rozszerzania i specjalizacji d) Wskazanie dokładnych definicji elementów modelu dziedziny jako grup danych dla poszczególnych składowych dokumentacji Oprogramowania P1 oraz wskazanie przykładowych elementów modelu dziedziny jako grup danych

13 e) Określenie zasad postępowania w przypadku gdy dany element modelu dziedziny w dokumentacji Oprogramowania P1 nie spełnia definicji grupy danych w Strategii Wymiarowania (jest np. techniczna grupą danych, np. daną słownikową, np. parametrem) f) Określenie zasad postępowania w przypadku powiązanych ze sobą elementów modelu dziedziny za pomocą relacji notacji UML: agregacji, kompozycji i specjalizacji g) Wskazanie dokładnych definicji aktorów jako użytkowników funkcjonalnych dla poszczególnych składowych dokumentacji Oprogramowania P1 oraz wskazanie przykładowych aktorów jako użytkowników funkcjonalnych h) Określenie zasad postępowania w przypadku powiązanych ze sobą aktorów za pomocą relacji notacji UML: specjalizacja i) Określenia zasad identyfikacji podprocesów przesuwania grup danych pomiędzy powiązanymi przypadkami użycia (notacja UML: relacja włączania i rozszerzania) j) Określenie zasady identyfikacji podprocesów manipulacji na grupach danych oraz powiązania ich z podprocesami manipulacji na grupach danych k) Określenie warstw Oprogramowania P1 na których należy identyfikować procesy funkcjonalne l) Określenie granic poszczególnych składowych Oprogramowania P1 m) Określenie przeliczników CFP pomiędzy składowymi Oprogramowania P1 jeśli dokumentacja poszczególnych składowych jest opracowana na różnym poziomie granulacji metody COSMiC.

1. Specyfikacja Istotnych Warunków Zamówienia: Pkt. XIII Opis kryteriów, którymi Zamawiający będzie się kierował przy wyborze oferty; wraz z podaniem wag tych kryteriów i sposobu oceny ofert - kryteria pozacenowe oceny ofert „Doświadczenie personelu wykonawcy w zakresie metodyk Agile" Zamawiający dla obu części zamówienia określił takie samo kryterium pozacenowe oceny ofert - Doświadczenie personelu wykonawcy w zakresie metodyk Agile, w części I z wagą 20% i w części II z wagą 40%.

14 Punkty przyznawane są za wykazanie w ofercie, że dysponuje się dwoma lub jednym Scrum Masterami, przy czym posiadanie certyfikatu wymagane jest tylko dla jednego Scrum Mastera. • Wykonawca otrzyma 20 lub 40 punktów (zależnie od części) za wykazanie, że dysponuje 2 Scrum Masterami, z których co najmniej 1 posiada certyfikat ze znajomości metodyk Agile (Professional Scrum Master lub równoważny, potwierdzający znajomość metodyk Agile); • Wykonawca otrzyma 10 lub 20 punktów (zależnie od części) za wykazanie, że dysponuje 1 Scrum Masterem posiadającym certyfikat ze znajomości metodyk Agile (Professional Scrum Master lub równoważny, potwierdzający znajomość metodyk Agile); • Wykonawca otrzyma 0 punktów, jeżeli nie wykaże, że dysponuje Scrum Masterem posiadającym certyfikat ze znajomości metodyk Agile (Professional Scrum Master lub równoważny, potwierdzający znajomość metodyk Agile).

W pierwszej kolejności Odwołujący wskazywał, że przedmiotowe kryterium nie ma związku z przedmiotem zamówienia. Zamawiający określił bardzo lakonicznie wymagania dla osób, które mają być w dyspozycji Zamawiającego. Zamawiający nie postawił żadnych wymagań dla tego Scrum Mastera, który nie musi posiadać certyfikatu ze znajomości metodyk Agile.

Sformułowanie o posiadaniu Scrum Mastera jest tak lakoniczne, że może je spełnić dowolna osoba. Skutkiem powyższego jest okoliczność, że w przypadku wskazania 2 Srcum Masterów

można uzyskać aż 20 lub 40 punktów można uzyskać za to kryterium w sytuacji, gdy jeden wskazany Scrum Master posiada certyfikat, a drugi wskazany Scrum Master nie musi być informatykiem, może mieć dowolne wykształcenie, dowolną wiedzę i doświadczenie - w SIWZ nie wskazano bowiem żadnych wymagań dla tego „drugiego" Scrum Mastera. Czyli w przypadku części I można uzyskać aż 10 punktów (połowa z maksymalnej liczby 20 punktów), a w części lI aż 20 punktów (połowa z maksymalnej liczby 20 punktów) za wskazanie w SIWZ dowolnej osoby, bez wiedzy, doświadczenia i certyfikatów. Powoduje to, że przedmiotowe kryterium pozacenowe nie jest współmierne do kryterium ceny. Mając na uwadze wartość zamówienia należy stwierdzić, że dla Zamawiającego wskazanie takiej 1 dowolnej osoby, bez wiedzy, doświadczenia i certyfikatów zespołu jest warte tyle samo, co wykonanie 2/5zamówienia w części II i 1/5 zamówienia w części I - tj. kilka czy kilkanaście milionów złotych.

Wobec faktu, że nie postawiono takiemu Scrum Masterowi żadnych wymagań związanych z doświadczeniem czy wiedzą w zakresie wykonania przedmiotu zamówienia, należy uznać, że przedmiotowe kryterium nie jest kryterium związanym z przedmiotem zamówienia. Przy czym takie powiązanie z przedmiotem zamówienia musi - zgodnie ze stanowiskiem Europejskiego

15 Trybunału Sprawiedliwości prowadzić do wyboru najlepszej oferty - por. wyrok ETS z 17 września 2002 roku, C- 513/99: „Po pierwsze, kryterium musi być związane z przedmiotem zamówienia. Celem stosowania kryterium oceny ofert jest wybór oferty najkorzystniejszej, zatem wszystkie kryteria muszą być nakierowane na identyfikację tej oferty, która jest najlepsza."

Po drugie - jest to kryterium nieweryfikowalne. W SIWZ określono, że można wskazać maksymalnie po 2 Scrum Masterów. Natomiast Zamawiający nie wskazał, w jaki sposób będzie dokonywał oceny ofert w tym aspekcie. Należy zatem wnioskować, że wystarczy wpisać dowolne imię i nazwisko, i wskazać, że posiada certyfikat ze znajomości metodyk Agile. SIWZ nie narzuca żadnych wymagań w tym zakresie, jedynie w rozdziale X, pkt. 1 Opis sposobu przygotowania ofert w ppkt 1.3) wskazano, że oferta ma zawierać:

„3} wykaz dysponowania Scrum Masterami, z których co najmniej 1 posiada certyfikat ze znajomości metodyk Agile (Professional Scrum Master lub równoważny, potwierdzający znajomość metodyk Agile} - dokument ma umożliwić dokonanie oceny oferty w kryterium „Doświadczenie personelu Wykonawcy w zakresie metodyk Agile" opisanym w rozdziale XIII SIWZ."

Zdaniem Odwołującego w oparciu o w/w aktualne zapisy SIWZ kryterium pozacenowe „Doświadczenie personelu wykonawcy w zakresie metodyk Agile" jest nieweryfikowalne przez Zamawiającego, choć ma bardzo istotny wpływ na wybór najkorzystniejszej oferty. Nie jest zatem zachowana zasada prowadzenia postępowania z zachowaniem uczciwej konkurencji oraz równego traktowania wykonawców. Co więcej - nieweryfikowalność tego kryterium narusza przepis art. 91 ust. 2d Prawa zamówień publicznych, zgodnie z którym Zamawiający zobowiązany jest określić kryteria oceny ofert nie tylko w sposób jednoznaczny i zrozumiały, ale także (a może przede wszystkim) umożliwiający sprawdzenie informacji przedstawianych przez wykonawców. Tymczasem SIWZ dopuszcza sytuację, w której wszyscy wykonawcy wskażą po 2 Scrum Masterów i otrzymają w przedmiotowym kryterium odpowiednio 20 lub 40 pkt.

Następnie zaś na etapie realizacji Umowy wybrany wykonawca nie przedstawi odpowiedniego zespołu lub też zespół nie będzie miał wiedzy w zakresie metodyki Agile lub nie będzie w stanie realizować zadań, dla realizacji których został dedykowany. Jedynym uprawnieniem Zamawiającego mogłoby być odstąpienie od Umowy. Zatem weryfikacja ofert w tym kryterium dokonywana byłaby dopiero na etapie wykonywania Umowy (zamiast na etapie oceny ofert).

Oczywistym jest, że Zamawiający zobowiązany jest zastosować kryterium pozacenowe, zgodnie z brzmieniem art. 91 Prawa zamówień publicznych. Jednakże Zamawiający powinien tak skonstruować SIWZ, aby takie kryterium pozacenowe to było zarówno obiektywne

16 i weryfikowalne na etapie oceny ofert, jak i związane z przedmiotem zamówienia. Jeśli Zamawiający przyznaje takiemu kryterium aż 40% czy też 20%, to zobowiązany jest już na etapie oceny ofert weryfikować oferty w tym zakresie, zgodnie z przepisem art. 91 ust. 2d

Prawa zamówień publicznych. Zdaniem Odwołującego jedyny możliwy sposób weryfikacji kryterium pozacenowego, to żądanie od wykonawców, aby w ofercie zamieszczano informacje obiektywne, możliwe do sprawdzenia przez Zamawiającego.

Odwołujący wskazywał, jakie kryteria pozacenowe są stosowane przez innych zamawiających przy podobnych zamówieniach - co do skali i wartości. Przykładowo wskazać można na następujące postępowania z obiektywnymi i weryfikowalnymi kryteriami oceny:

MINISTERSTWO SPRAWIEDLIWOŚCI: Świadczenie kompleksowych usług z zakresu IT dla Ministerstwa Sprawiedliwości, Znak sprawy: (…). Pozacenowe kryterium oceny ofert: 40% Doświadczenie Personelu Będzie rozpatrywane na podstawie informacji podanych przez Wykonawcę w Formularzu „Potencjał kadrowy - wykaz osób". Zamawiający przyzna Wykonawcy punkty za dodatkowe doświadczenie osób pełniących kluczowe funkcje w projekcie.

GŁÓWNY INSPEKTORAT TRANSPORTU DROGOWEGO: Budowa, wdrożenie, utrzymanie i rozwój Krajowego Rejestru Elektronicznego Przedsiębiorców Transportu Drogowego Numer sprawy: (…). Pozacenowe kryterium oceny ofert: 10% - Dodatkowe kwalifikacje osób zdolnych do wykonania zamówienia. Zamawiający będzie oceniał, posiadane przez osoby zdolne do wykonania zamówienia, dodatkowe kwalifikacje (wykraczające poza projekty wskazane na potwierdzenie spełnienia warunku udziału w postępowaniu) na podstawie Wykazu doświadczenia członków zespołu Wykonawcy, którzy będą oddelegowani do realizacji zamówienia.

GŁÓWNY URZĄD GEODEZJI I KARTOGRAFII: Budowa oraz rozwój e-usług i narzędzi w ramach projektów (…) wraz ze szkoleniami. Numer sprawy: (…). Pozacenowe kryterium oceny ofert: 20% - Wydajność procesu produkcji. W ramach kryterium „Wydajność procesu produkcji" Wykonawca może uzyskać 0, 5,10,15 lub 20 punktów, w zależności od zaproponowanej przez Wykonawcę wydajności procesu produkcji, rozumianej jako liczby Punktów Funkcyjnych możliwych do realizacji w ramach Zleceń w ciągu miesiąca kalendarzowego. Wykonawca zobowiązany jest udowodnić, że realizował usługi przez łączny okres min. 6 miesięcy ze średniomiesięczną wydajnością nie gorszą, niż oferowana w kryterium.

17 PROKURATURA KRAJOWA: Zaprojektowanie, przygotowanie, wdrożenie rozbudowy Systemu Digitalizacji Akt Postępowań Przygotowawczych (iSDA). Pozacenowe kryterium oceny ofert:

15% - sposób wykonania zamówienia, 25% - Doświadczenie personelu kluczowego Wykonawcy.

GŁÓWNY INSPEKTORAT RUCHU DROGOWEGO: Budowa, wdrożenie, utrzymanie i rozwój krajowego rejestru elektronicznego przedsiębiorców transportu drogowego. Pozacenowe kryterium oceny ofert: 10% dodatkowe kwalifikacje osób zdolnych do wykonania zamówienia, 25% - ocena funkcjonalno- techniczna zaproponowanego rozwiązania, 15% - skrócenie terminu budowy wersji podstawowej systemu KREPTD.

Jak wynika z powyższego, możliwe jest takie określenie w SIWZ kryterium pozacenowego, które z jednej strony będzie związane z przedmiotem zamówienia, a z drugiej umożliwi sprawdzenie informacji przedstawianych przez wykonawców.

Odwołujący zwracał uwagę, że kryteria pozacenowe nie muszą odnosić się w głównej mierze tylko do zespołu, który ma realizować umowę, ale możliwe jest także ustanowienie jako takie kryterium kwestii związanych z procesem produkcji (jak wskazuje art, 91 ust. 2c Prawa zamówień publicznych), jak chociażby wydajność czy próbka.

Mając powyższe na uwadze Odwołujący wnosił o zmianę SIWZ poprzez wykreślenie kryterium „Doświadczenie personelu wykonawcy w zakresie metodyk Agile" i wprowadzenie w to miejsce kryterium związanego z przedmiotem zamówienia, zgodnego z przepisem art. 91 ust. 2c i 2d Prawa zamówień publicznych, według wyboru Zamawiającego. Odwołujący nie wskazywał brzmienia takiego kryterium, gdyż określenie kryterium jest uprawnieniem Zamawiającego, jednocześnie Odwołujący wskazał przykładowe, prawidłowe kryteria pozacenowe stosowane w analogicznych postępowaniach.

1. Wzór umowy; Załącznik nr 2a do SIWZ i Załącznik nr 2b do SIWZ - Art. 1 Definicje: „Ogólne Kryteria Jakościowe" Zamawiający wprowadził następującą definicję pojęcia „Ogólne Kryteria Jakościowe": dokument powstały w trakcie Okresu Przygotowawczego, zawierający wymagania dotyczące Oprogramowania i Dokumentacji stworzonych na podstawie odrębnej, innej umowy lub

Dyspozycji Operacyjnej, których spełnienie pozwala na dokonanie jego Autoryzacji.

18 Z definicji tej wynika, że dokument „Ogólne Kryteria Jakościowe" ma powstać w trakcie Okresu Przygotowawczego, przy czym nie wskazano w definicji, kto przygotowuje, na jakich podstawach, itp.

Jednym z załączników do Umowy jest Załącznik nr 8 Okres przygotowawczy. Przy czym w tym załączniku, z dnia ogłoszenia zamówienia nie było żadnych postanowień dotyczących Ogólnych Kryteriów Jakościowych. Zamawiający w aktualizacji z 13 lipca 2017 uzupełnił pkt. 20 w treści Załącznika nr 8:

„20) uzgodnienie dokumentu Ogólne Kryteria Jakościowe; Weryfikacja: otrzymanie dokumentu opisującego wymagania dla Kodu Źródłowego i Dokumentacji wymagane do świadczenia Usług Gwarancyjnych."

Z kolei w samej Umowie pojęcie „Ogólne Kryteria Jakościowe" pojawia się w definicjach innych pojęć: Autoryzacja, Oprogramowanie, Tworzenie Oprogramowania; a następnie w art. 5 Usługi Autoryzacji oraz w pkt 22.1.19, gdzie ukonstytuowana jest kara umowna.

Z żadnego w/w postanowienia Umowy nie wynika, jaki jest zakres tego dokumentu, kto go tworzy, na jakiej podstawie, itp. Jedynie z postanowień art. 5 wynika, że ma być on podstawą szeregu zobowiązań Wykonawcy. W art.5 pkt. 5.13 i 5.14 Zamawiający definiuje jak ogromne znaczenie ma dokument dla prawidłowej współpracy Stron Umowy, a co za tym idzie oczekiwania co do najważniejszych jego zapisów powinny być identyczne dla wszystkich Oferentów.

Nie jest jednak zgodne z art. 29 ust. 1 Prawa zamówień publicznych, aby jakiś bliżej nieokreślony dokument był podstawą zobowiązań Wykonawcy. Każdy taki dokument musi zostać dołączony do SIWZ, gdyż SIWZ musi zawierać całość informacji, które stanowią podstawą przygotowania oferty.

Mając powyższe na uwadze Odwołujący wnosił o: 1. wykreślenie z SIWZ wszystkich postanowień dotyczących dokumentu Ogólne Kryteria Kwalifikacji lub 2. jeśli Zamawiający uważa, że dokument ten zawiera treści niezbędne do realizacji przedmiotu zamówienia – o dołączenie tego dokumentu do SIWZ oraz o zmianę w art. 1 Definicje treści punktu „Ogólne Kryteria Jakościowe" w sposób następujący: ,,Ogólne Kryteria Jakościowe: Załącznik nr 18, zawierający wymagania dotyczące Oprogramowania i Dokumentacji stworzonych na podstawie odrębnej, innej umowy lub Dyspozycji Operacyjnej, których spełnienie pozwala na dokonanie jego Autoryzacji.

19

1. Wzór umowy: Załącznik nr 2a do SIWZ i Załącznik nr 2b do SIWZ - Art. 2 Przedmiot Umowy, pkt 2.4,2.7,2.8.

Zamawiający w następujący sposób uregulował w art. 2 cel umowy „2.1. Przedmiotem Umowy, realizowanym w celu dokończenia budowy Projektu P1. rozumianej jako dokończenie budowy projektu „Elektroniczna Platforma Gromadzenia, Analizy i Udostępniania zasobów cyfrowych o Zdarzeniach Medycznych (PI) - faza 2" jest. (...)

1. 4. Celem Umowy jest realizacja Projektu P1, w szczególności zbudowanie Systemu P1 – w zakresie wynikającym z Umowy i składanych przez Zamawiającego Dyspozycji. (...)
2. 7. Brak osiągnięcia celu Projektu P1 w ramach realizacji Umowy z przyczyn leżących po stronie Wykonawcy uznaje się za nienależyte wykonanie Umowy w części, w której niedotrzymanie celu Projektu P1 nastąpiło.
3. 8. Wykonawca oświadcza, że jest świadom, że wszelkie realizowane przez niego Usługi mają doprowadzić do skutków, jakimi są budowa, utrzymanie oraz rozwój Systemu P1" Zamawiający wyraźnie określił, że celem umowy jest realizacja Projektu P1, w szczególności zbudowanie Systemu P1, zaś Wykonawca odpowiada za brak osiągnięcia celu Projektu P1.

Z kolei Projekt P1 zgodnie z definicją z art. 1 to „przedsięwzięcie, w ramach którego są realizowane budowa i uruchomienie Systemu P1".

Pierwotnie w samym dokumencie SIWZ nie było żadnych informacji, które by się do tego celu odnosiły. Jak już wskazywano powyżej - załączniku zawierające Opis przedmiotu zamówienia dla każdej z części to dokumenty zawierające mniej niż 2 strony treści, przy czym treść

odnosząca się rzeczywiście do przedmiotu zamówienia to odpowiednio 2 i 4 linijki.

Dopiero Modyfikacją SIWZ z dnia 13 lipca 2017 roku Zamawiający wskazał w SIWZ cel Projektu P1, wskazując je w Załączniku nr 1 do Umowy „Opis aktualny i docelowy Projektu P1".

Jednakże ta zmiana nie likwiduje stanu wadliwości SIWZ w zakresie powiązania celu Projektu P1 z celem umowy i zakresem zobowiązań Wykonawcy w kontekście użytych przez Zamawiającego konstrukcji i metodyk realizacji.

20 W przedmiocie umowy określonym w art. 2 Umowy Zamawiający wyraźnie wskazał, że przedmiotem tym w zakresie Tworzenia Oprogramowania jest „Tworzenie Oprogramowania, na podstawie i w zakresie wynikającym z poszczególnych Dyspozycji składanych przez Zamawiającego". Jeśli zatem Zamawiający nie złoży Dyspozycji, to nie będzie miało miejsce stworzenie oprogramowania. A jeśli nie będzie miało miejsce stworzenie oprogramowania, to nie będzie też miało miejsce dokończenie budowy Projektu P1. Jest to o tyle istotne, że Zamawiający sam wskazał, że w zakresie tworzenia oprogramowania poziom gwarantowanej realizacji przedmiotu zamówienia to zaledwie 10%.

Analiza w/w postanowień Umowy wyraźnie wskazuje, że Wykonawca nie może ponosić żadnej odpowiedzialności za osiągnięcie celu umowy wskazanego w pkt 2.4., gdyż Zamawiający nie gwarantuje, że dokona Dyspozycji, które doprowadzą do Tworzenia Oprogramowania.

Co więcej - nawet cel umowy jest przy takich postanowienia nadużyciem i postanowieniem nadmiernym. O celu umowy można bowiem mówić tylko w takiej sytuacji, w której Zamawiający określiłby w SIWZ zakres oprogramowania, jakie ma być stworzone, zaś Wykonawca składając ofertę zobowiązałby się do wykonania takiego oprogramowania. Tymczasem obecnie Wykonawca zobowiązuje się jedynie do tworzenia oprogramowania w przypadku złożenia Dyspozycji przez Zamawiającego oraz do świadczenia Usług Gwarancyjnych, przy czym te usługi nie służą ze swej istoty realizacji celu, tj. dokończenia budowy Projektu P1.

Zamawiający zatem stara się stworzyć pojęcie celu umowy jako rodzące zobowiązania Wykonawcy, podczas gdy osiągnięcie tego celu leży całkowicie poza zakresem działań Wykonawcy. Narusza to art. 29 ust. 1 Ustawy, gdyż pojęcie celu umowy zawsze wpływać będzie na kształtowanie się obowiązków Wykonawcy, podczas gdy postanowienia celu są niejasne i uniemożliwiają sporządzenie oferty.

Mając powyższe na uwadze Odwołujący wnosił o 1. wykreślenie z umowy wszystkich postanowień dotyczących celu umowy, ze względu na okoliczność, że obecna konstrukcja umowy i gwarantowany przez Zamawiającego zakres Tworzenia Oprogramowania postanowień uniemożliwiają wpływ Wykonawcy na realizację celu umowy lub 2. zmianę dotyczących celu umowy w taki sposób, aby wynikało z nich jednoznacznie, że za osiągniecie celu umowy odpowiedzialny jest jedynie Zamawiający - a to wobec obecnej konstrukcji umowy i gwarantowanego przez Zamawiającego zakresu Tworzenia Oprogramowania wyłącznie w zakresie 10%.

21

1. Wzór umowy: Załącznik nr 2a do SIWZ i Załącznik nr 2b do SIWZ - Art. 3 Okres Przygotowawczy, Infrastruktura Projektu.

Zamawiający określił w warunkach Umowy, iż współpraca z wyłonionym w postępowaniu Wykonawcą, rozpocznie się Okresem Przygotowawczym. Definicja Okresu Przygotowawczego w art. 1 brzmi: „początkowy okres realizacji Umowy mający umożliwić Wykonawcy świadczenie Usług, w czasie którego Wykonawca wykonuje czynności opisane Umową, przygotowujące do świadczenia Usług - za co Zamawiający nie ponosi kosztów" i doprecyzowana jest postanowieniami art. 3 Umowy oraz Załącznika nr 8. Z postanowień tych jasno wynika, iż wszystkie wskazane zadania są już wyspecyfikowane przez Zamawiającego albo można je uznać za typowe zadania z katalogu Usług gwarancyjnych opisanych w Umowie wraz Załącznikami.

Odpowiednio długi Okres Przygotowawczy stanowi ważny element obniżenia ryzyka Wykonawcy, który musi zapoznać się ze skomplikowaną strukturą przejmowanych systemów, które dodatkowo funkcjonują w krytycznych reżimach SLA. Jako przykłady można wskazać płynność przejęcia utrzymania dla systemów ARiMR, czy ZUS z wielomiesięcznymi okresami

przygotowawczymi. Przy czym okresy przygotowawcze są w takich umowach konieczne, gdyż umowy dotycząc przejęcia utrzymania funkcjonującego systemu informatycznego.

Natomiast Okres Przygotowawczy opisany w Załączniku nr 8 dla Części I jest spisem prac, które mieszczą się w katalogu przewidzianym w Usłudze gwarancyjnej: • Usługa Zarządzania Kodem • Usługa Zarządzania Konfiguracją Oprogramowania • Usługa Utrzymania Dokumentacji • Usługa Administracji Środowiskami • Usługa Monitorowania Dostępności i Wydajności • Usługa Administracji Systemem • Usługa Usuwania Wad • Usługa Instalacji • Usługa Utrzymania infrastruktury Projektu

22 • Usługa Zapewnienia I linii Wsparcia • Usługa Dodatkowa W związku z tym, iż żadne z zadań Okresu Przygotowawczego nie zakłada w szczegółach złożonego procesu uczenia się po stronie Wykonawcy, które dodatkowo byłoby weryfikowane czymś więcej niż oświadczenie wnosimy o przeniesienie zadań Okresu Przejściowego do zakresu prac zaplanowanych po podpisaniu Umowy z wybranym Wykonawcą.

Zdaniem Odwołującego narusza to art. 29 ust. 1 Ustawy, gdyż opis przedmiotu zamówienia jest niejasny - usługi, które są elementem Usług Gwarancyjnych, zostały objęte Okresem Przygotowawczym. Poza tym Zamawiający nie wskazał celu Okresu Przygotowawczego.

Długość tego okresu wpływa na cenę oferty, zaś Wykonawcy nie mają obecnie dostatecznych informacji, aby dokonać szacowania ceny oferty w tym zakresie.

Mając powyższe na uwadze oraz fakt, iż okres 60 dni od zawarcia Umowy dla Części I oraz 30 dni dla Części II może być bezcenny dla celów i terminów Projektu P1, Odwołujący wnosił o:

1. usuniecie z Okresu Przygotowawczego prac, które są elementem Usługi Gwarancyjnej,
2. skrócenie Okresu Przygotowawczej do 5 dni lub jego całkowite wykreślenie.
3. Wzór umowy: Załącznik nr 2a do SIWZ i Załącznik nr 2b do SIWZ - Pkt 3.6 Zgodnie z pkt. 3.6 Umowy oraz z Załącznikiem nr 4h do wzoru umowy Wykonawca jest zobowiązany do przejęcia Infrastruktury Projektu: „3.6. W ramach Okresu Przygotowawczego, w terminach wynikających z Załącznika nr 8 lub ustalonych na bieżąco przez Strony, Wykonawca jest zobowiązany do przejęcia Infrastruktury Projektu, a następnie realizacji przy jej użyciu świadczeń zdefiniowanych w Umowie ¡składanych na jej podstawie Dyspozycjach”.

Z treści SIWZ nie wynika, czy Zamawiający wykupił dla posiadanego sprzętu i licencji, wymienionych w załączniku nr 12 tzw. usługę maintenance (utrzymania) na cały okres trwania Umowy. Z kolei Zamawiający nie wskazał, że jednym z elementów przedmiotu zamówienia jest dostarczenie przez Wykonawcę usług maintenance dla Infrastruktury Projektu. Usługa Utrzymania Infrastruktury Projektu jest opisana w Załączniku 4h, gdzie w pkt. 2 wskazano:

„Zamawiający zapewnia wsparcie producenta dla oprogramowania wspomagającego co do

23 którego wykorzystania Wykonawca jest uprawniony w imieniu Zamawiającego". Jednak mowa w nim o niezdefiniowanym „oprogramowaniu wspomagającym" i nie ma mowy o infrastrukturze sprzętowej. Tymczasem prawidłowy opis zapewnianej przez Zamawiającego usługi wsparcia producenta powinien obejmować te zakresy. Przedmiotowy brak SIWZ powoduje, że Wykonawca - z naruszeniem art. 29 ust. 1 Ustawy - nie jest w stanie określić kosztów utrzymania Infrastruktury Projektu, co skutkuje niemożliwością sporządzenia oferty.

Dopiero zmiana z dnia 13 lipca 2017 roku wprowadzono w Załączniku 4h postanowienia odnośnie wsparcia po okresie gwarancji, gdy kończy się wsparcie producenta - por, ostatni akapit w Załączniku 4h „Na co najmniej 30 dni przed upływem terminu wsparcia producenta dla elementów Infrastruktury Projektu wymienionych w Załączniku nr 12 do Umowy, Wykonawca jest zobowiązany do przekazania listy sprzętu i licencji, które są wymagane na potrzeby realizacji Projektu P1, dla których Zamawiający jest zobowiązany zapewnić wsparcie producenta". Co więcej z Załącznika 4h bynajmniej nie wynika, że na dzień składania ofert

i zawarcia Umowy Zamawiający posiada wsparcie producenta dla całej Infrastruktury Projektu.

Mając powyższe na uwadze Odwołujący wnosił o nakazanie Zamawiającemu określenia w SIWZ szczegółowej listy Infrastruktury Projektu, dla której Zamawiający zapewnia wsparcie producenta, ze wskazaniem poziomu wsparcia, okresów obowiązywania.

1. Wzór umowy: Załącznik nr 2a do SIWZ i Załącznik nr 2b do SIWZ - Pkt 3.7 W pkt 3.7 Umowy Zamawiający wymaga od Wykonawcy deklaracji, że Infrastruktura Projektu jest wystarczająca dla realizacji celu Projektu P1:

„3.7. Wykonawca oświadcza, że Infrastruktura Projektu jest wystarczająca dla realizacji celu Projektu P1, w szczególności poprzez świadczenie Usług opisanych w Umowie."

Na podstawie dokumentów załączonych do SIWZ, Wykonawca w żaden sposób nie jest w stanie zweryfikować, czy posiadana przez Zamawiającego Infrastruktura Projektu jest wystarczająca dla realizacji celu Projektu P1. Ocena właściwego zwymiarowania infrastruktury zarówno sprzętowej, jak i licencyjnej, jest zależna od wielu czynników, w tym: • złożoności środowiska; • technologii informatycznych; • architektury ITS oraz architektury osadzanych na niej rozwiązań;

24 • sposobu implementacji poszczególnych elementów oprogramowania, w tym użytych technologii, framework-ów, itp.; • przyjętych założeń; Zamawiający w Załączniku lb do Umowy - Opis Ogólnych Wymagań Niefunkcjonalnych wskazuje jakie parametry wolumetryczne i wydajnościowe mają zostać zapewnione w trakcie utrzymania i rozwoju Systemu PI. Jednakże Zamawiający nie daje możliwości zapoznać się Wykonawcy z dokumentacją techniczną, w szczególności z Projektem Infrastruktury Techniczno-Systemowej (PITS), co uniemożliwia Wykonawcy jakiekolwiek merytoryczne ustosunkowanie się do zaprojektowanych rozwiązań i weryfikacji dostępnych ilości sprzętu i licencji.

Należy również zwrócić uwagą, iż System PI jest rozwijany w ramach Fazy 2 oraz będzie dalej rozwijany w ramach niniejszego i innych postępowań. Przyjęta przez Zamawiającego metoda wytwarzania oprogramowania przez kierowanie Dyspozycji do wielu Wykonawców, w ramach różnych umów, w żaden sposób nie daje możliwości określenia jakie funkcjonalności, w jakich technologiach oraz w jakiej architekturze zostaną wytworzone i przekazane do utrzymania.

Niemożliwe zatem staje się potwierdzenie przez Wykonawcę, że wskazane w Załączniku nr 12 ITS wraz z licencjami oprogramowania standardowego są wystarczające na potrzeby rozwiązań jeszcze nawet nie zdefiniowanych przez Zamawiającego.

Podsumowując – zdaniem Odwołującego, Wykonawca na dzień złożenia oferty oraz zawierania Umowy nie będzie posiadał wszystkich wyżej wymienionych informacji, gdyż jest to skutkiem przyjętej przez Zamawiającego konstrukcji umowy oraz brakiem zamieszczenia w/w informacji w SIWZ. W związku z czym nie będzie mógł oświadczyć, że Infrastruktura Projektu jest wystarczająca dla realizacji celu Projektu P1. Tym samym oczekiwanie Zamawiającego, aby Wykonawca złożył przedmiotowe oświadczenie narusza art. 29 ust. 1 i 2 Prawa zamówień publicznych, gdyż SIWZ nie zawiera treści na podstawie których profesjonalny podmiot, działający z zachowaniem należytej staranności posiadałby podstawy do złożenia takiego oświadczenia.

Wobec powyższego Odwołujący wnosił o wykreślenie pkt. 3.7 Umowy w całości.

1. Wzór umowy: Załącznik nr 2a do SIWZ i Załącznik nr 2b do SIWZ - Pkt 2.9., 4.9, 4.10.kwestie związane z metodyką zwinną Scrum.

25 W pkt. 2.9 Umowy Zamawiający wskazał, że Umowa w zakresie Tworzenia Oprogramowania będzie realizowana zgodnie z metodyką zwinną Scrum:

„2.9. Prace informatyczne wykonywane na podstawie Umowy w ramach Tworzenia Oprogramowania, będą realizowane zgodnie z metodyką zwinną Scrum."

Metodyka zwinna Scrum to ramy procesu, które są wykorzystywane w zarządzaniu wytwarzaniem złożonych produktów od początku lat dziewięćdziesiątych. Sam w sobie Scrum nie jest procesem czy techniką wytwórczą. Opisuje jedynie ogólne sposoby postępowania,

w obrębie których możliwe jest stosowanie różnego rodzaju procesów i technik. Scrum pomaga odkrywać nieefektywności praktyk zarządczych i technik inżynierskich, by można było je doskonalić.

W obręb Scruma wchodzą Zespoły Scrumowe oraz związane z nimi role, zdarzenia, artefakty i reguły. Każdy z tych elementów służy konkretnym celom i każdy jest niezbędny do osiągnięcia sukcesu w stosowaniu Scruma.

W skład Zespołu Scrumowego wchodzą: Właściciel Produktu (ang. Product O.), Zespół Deweloperski oraz Scrum Master. Istotą metodyki Scrum jest, że Zespoły Scrumowe są samoorganizujące się i międzyfunkcjonalne. Samoorganizujące się zespoły samodzielnie decydują, w jaki sposób najlepiej wykonywać pracę, nie są przy tym w żaden sposób kierowane przez osoby spoza zespołu. Zespoły międzyfunkcjonalne posiadają wszelkie kompetencje niezbędne do ukończenia pracy, nie będąc zależnymi od osób nienależących do zespołu.

Model zespołu proponowany w Scrumie został zaprojektowany tak, aby zoptymalizować elastyczność, kreatywność i produktywność.

Jedną z cech charakterystycznych każdej metodyki zwinnej, w tym metodyki zwinnej Scrum, jest powołanie roli „Produkt Owner" (Właściciela Produktu). Rola ta odpowiedzialna jest za maksymalizację wartości produktu i pracy Zespołu Deweloperskiego.

Właściciel Produktu jest jedyną osobą zarządzającą Backlogiem Produktu (ang. Product Backlog). Pojęcie zarządzania Backlogiem Produktu mieści w sobie: • jasne artykułowanie elementów Backlogu Produktu, • ustalanie kolejności elementów Backlogu Produktu w sposób pozwalający osiągać założone cele i misje (priorytetyzacja), • optymalizowanie wartości pracy wykonywanej przez Zespół Deweloperski,

26 • zapewnianie, że Backlog Produktu jest dostępny, przejrzysty oraz jasny dla wszystkich, a także, że dobrze opisuje to, czym Zespół Scrumowy będzie się zajmował w dalszej kolejności, • zapewnianie, że Zespół Deweloperski rozumie elementy Backlogu Produktu w wymaganym stopniu. Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu pozostaje za nie odpowiedzialny.

Powszechnie obowiązujące zasady dotyczące metodyki zwinnej Scrum znajdują się na stronie internetowej organizacji Scrum - (…) Skoro Zamawiający w pkt. 2.9 Umowy, tj. w przedmiocie Umowy, wskazał wprost, że prace realizowane w ramach Tworzenia Oprogramowania będą zgodnie z metodyką zwinną Scrum, to wszystkie postanowienia dotyczące Tworzenia Oprogramowania powinny być zgodne z zasadami obowiązującymi dla tej metodyki. Tymczasem w pkt. 4.9 Umowy Zamawiający wskazał: „4.9. W celu uniknięcia wątpliwości Strony oświadczają, że niezależnie od udziału P. O. w planowaniu prac objętych Dyspozycją Rezultatu zgodnie z postanowieniem poprzedzającym, Wykonawca przyjmuje wyłączna odpowiedzialność za osiągniecie rezultatu stanowiącego przedmiot danej Dyspozycji."

Oczywistym jest, że pkt. 4.9 Umowy jest sprzeczny z zasadami metodyki zwinnej Scrum, w szczególności zaś z pkt. 2.9 Umowy. Narusza to art. 29 ust. 1 Prawa zamówień publicznych, gdyż SIWZ jest wewnętrznie sprzeczny, co uniemożliwia Wykonawcy sporządzenie oferty. Na podstawie obecnej treści SIWZ Wykonawca nie wie, czy ma stosować metodykę zwinną Scrum, którą Zamawiający wskazał w pkt 2.9 Umowy, czy też ma tej metodyki nie stosować.

Z kolei opisanie przedmiotu umowy poprzez nałożenie wyłącznej odpowiedzialności za osiągnięcie rezultatu danej Dyspozycji na Wykonawcę jest sprzeczne z postanowieniami Umowy dotyczącymi Dyspozycji. Zakres Dyspozycji został określony w Załączniku nr 7 do Umowy, jest do dokument zgodny z zasadami metodyki zwinnej Scrum i nie określa bynajmniej celu Dyspozycji. Nie określa dlatego, że zgodnie z metodyką zwinną Scrum Wykonawca nie odpowiada za osiągniecie celu. Dyspozycja zgodnie ze wzorem z Załącznika nr 7 określa jedynie:

Specyfikację przedmiotu Dyspozycji, do obejmuje wskazanie usług, do świadczenia których ma zostać oddelegowany Personel Wykonawcy, Imienną listę członków Personelu Wykonawcy wraz z opisem zakresu ich kompetencji (specjalizacji) i funkcji w procesie realizacji usług,

27

Czas, w jakim członkowie Personelu Wykonawcy mają świadczyć usługi w ramach Dyspozycji (liczba Roboczogodzin), Termin zakończenia świadczenia usług przez członków Personelu Wykonawcy w ramach Dyspozycji, Całkowity zakres niezbędnego współdziałania ze strony Zamawiającego, Inne szczególne wymagania Zamawiającego dla Dyspozycji.

Jak wynika z powyższego w ramach Dyspozycji Zamawiający de facto zamawia specjalistów do wykonania określonych usług w określonym czasie. Natomiast Zamawiający nie ma zamiaru określać w Dyspozycji żadnego rezultatu tej Dyspozycji. Tym samym Wykonawca nie może być odpowiedzialny za osiągnięcie rezultatu, gdyż nie ma żadnego wpływu na jego osiągnięcie tj. ani nie zna tego rezultatu, ani też nie ma wpływu na sposób realizacji {poza świadczeniem usług z należytą starannością).

Dalej w pkt 4.10 Umowy Zamawiający wskazał:

„4.10. Prace w zakresie Tworzenia Oprogramowania, realizowane w ramach Dyspozycji Operacyjnej, będą polegać na realizacji przez oddelegowanych członków Personelu Wykonawcy poleceń i zadań od Zamawiającego. Ponadto, Zamawiający może w ramach Dyspozycji Operacyjnej zażądać skierowania do prac członków Personelu Wykonawcy stanowiącego Zespół Deweloperski wraz ze S. M. i wówczas prace będą polegać na realizacji przez Zespół Deweloperski, w poszczególnych Sprintach (których liczbę ustali Product O.) kolejnych Wymagań wskazanych przez Product O. do wykonania w danym Sprincie (stanowiących Rejestr Wymagań Sprintu)."

Także to postanowienie Umowy stoi w sprzeczności z w/w postanowieniem pkt. 2.9 Umowy, ponieważ zgodnie z metodyką Scrum zakres prac do wykonania w ramach poszczególnych sprintów jest uzgadniany w ramach zespołu, a nie narzucany jednostronnie przez Product O..

Zgodnie z Scrum Guide, strona 9, część "Planowanie Sprintu", akapit pierwszy:

„Planowanie Sprintu Praca przeznaczona do wykonania w Sprincie jest planowana podczas Planowania Sprintu.

Plan ten powstaje w efekcie wspólnej pracy członków Zespołu S.".

Dodatkowo w ramach punktu umowy 4.41 Zamawiający oczekuje, iż:

28 „4.41 Prace w ramach Tworzenia Oprogramowania będą realizowane w Sprintach. Sprint nie może trwać dłużej niż 10 Dni Roboczych."

To postanowienie umowy wraz z pkt4.10 może doprowadzić do sytuacji, w której Zamawiający nakaże zrealizowanie nieuzgodnionego z zespołem zakresu (narzuconego przez Product O.) w terminie 10 dni Sprintu, co z jednej strony może nie dać możliwości wykonania prac w określonym terminie, a z drugiej strony daje Zamawiającemu prawo do naliczenia kar umownych.

Mając powyższe na uwadze Odwołujący wnosił o:

1. wykreślenie w całości pkt. 4.9,
2. wykreślenie dotychczasowej treści pkt. 4.10 i wpisanie w to miejsce:

„4.10. Prace w zakresie Tworzenia Oprogramowania, realizowane w ramach Dyspozycji Operacyjnej, będą polegać na realizacji przez oddelegowanych członków Personelu Wykonawcy poleceń i zadań od Zamawiającego. Ponadto, Zamawiający może w ramach Dyspozycji Operacyjnej zażądać skierowania do prac członków Personelu Wykonawcy stanowiącego Zespół Deweloperski wraz ze S. M. i wówczas prace będą polegać na realizacji przez Zespół Deweloperski, w poszczególnych Sprintach (których liczbę ustali P. O.) kolejnych Wymagań do wykonania w danym Sprincie (stanowiących Rejestr Wymagań Sprintu)."

1. Wzór Umowy: Załącznik nr 2a do SIWZ i Załącznik nr 2b do SIWZ - Art. 4 Tworzenie Oprogramowania W art. 4 Umowy Zamawiający w szczególności uregulował wytwarzanie przez Wykonawcę oprogramowania w trybie tzw. Dyspozycji Rezultatu. Poszczególne postanowienia dotyczącego Dyspozycji Rezultatu zawarte są w wielu punktach art. 4, w tym bezpośrednio w 4.6.1, 4.7-4.9., 4.12- 4.14, 4.22-4.28,4.47-4.51, 4.52-4.58. Zawarte w szczegółowych postanowieniach art. 4 uregulowania prowadzą do konkluzji, iż w ramach Dyspozycji Rezultatu, Zamawiający wymaga od Wykonawcy osiągnięcia „(…) określonego rezultatu opisanego daną Dyspozycją z uwzględnieniem zmian zakresu wprowadzonych zgodnie z procedurą zarządzania zmianą, o której mowa w Rozdziale 19 Umowy" (pkt. 4.6.1). Ponadto zgodnie z pkt. 4.2. zapytanie Zamawiającego w stosunku do Wykonawcy w zakresie Dyspozycja Rezultatu będzie

obejmować m.in. „oczekiwania Zamawiającego w stosunku do rezultatów prac Wykonawcy oraz sposobu ich prowadzenia (...), terminu zakończenia prac, wybór rozliczenia

29 w Roboczogodzinach lub Punktach Funkcyjnych, proponowaną liczbę Roboczogodzin lub, odpowiednio, Punktów Funkcyjnych niezbędnych do realizacji przedmiotu danej Dyspozycji albo łączną wartość proponowanego wynagrodzenia Wykonawcy z tego tytułu. Może także definiować inne kwestie istotne dla Zamawiającego”. Postanowienia te są rozwinięte w pkt 4.27 i 4.28. Z przytoczonych postanowień jednoznacznie wynika, że oczekiwaniem Zamawiającego od Wykonawcy jest wykonanie zdefiniowanego działa, w określonych terminie i za określonym wynagrodzeniem (które to parametry zgodnie z procedurą zawartą w umowie po przeprowadzeniu stosownych negocjacji podlegają uzgodnieniu pomiędzy Stronami). Kolejnym potwierdzeniem tej tezy, co do charakteru Dyspozycji Rezultatu są dalsze dyspozycje dotyczące prowadzenia testów oprogramowania powstałego w rezultacie danej Dyspozycji Rezultatu (dzieła).

Nie mniej jednak, pomimo dość – w ocenie Odwołującego - jednoznacznej i klarownej definicji, iż w istocie zgodnie ze sposobem opisania Dyspozycji Rezultatu jest ta Dyspozycją umową o dzieło, w całym art. 4 Umowy Zamawiający wprowadza klauzule, które są niedopuszczalne dla tego typu umowy. Zamawiający bowiem z jednej strony oczekuje, iż Wykonawca będzie odpowiedzialny za wykonanie określonego dzieła, w uzgodnionym czasie i za uzgodnionym wynagrodzeniem (wyrażonym ilością dniówek, punktów funkcyjnych bądź wprost wynagrodzeniem) - z drugiej zaś strony wprowadza postanowienia metodyki Scrum, która jest zaprzeczeniem umowy o dzieło i jest typowym zleceniem, zamówieniem usług świadczonych we wskazanych terminach przez wskazane osoby. Mowa tutaj o:

1. Wprowadzeniu zasady, że poszczególne Dyspozycje Rezultatu mają być prowadzone zgodnie z metodyką Scrum (tj. realizacja w Sprintach wg pkt. 4.7), która, co do zasady wprowadza elastyczność, polegającą na tym, że przy realizacji Sprintu dopuszczalna jest modyfikacja celów lub wymagań, o ile faktyczna realizacja wskazuje na taką potrzebę, co przeczy zasadzie wykonania dzieła o określonych cechach, co w rzeczy samej jest przedmiotem Dyspozycji Rezultatu. Fakt, iż Zamawiający w ten sposób również rozumie istotę Sprintu (którego rezultat może być odmienny od wstępnie zakładanego), potwierdza wprost postanowienie pkt. 4.44: ,,W przypadku niewykonania w danym Sprincie wszystkich wyznaczonych podczas Planowania Sprintu Wymagań, Wykonawca zrealizuje te brakujące Wymagania w kolejnych Sprintach w ramach danej Dyspozycji, zgodnie z ustaleniami podjętymi z Product O.". Wobec takiego rozumienia wymaganie polegające na narzuceniu Wykonawcy wykonaniu dzieła, o ściśle zdefiniowanych parametrach, poprzez Sprinty, ale z narzuconym terminem wykonania i określonym wynagrodzeniem jest wymaganiem niezgodnym z istotą zamówienia (umowy) dzieła. Ponadto narzucenie metody Sprintów dla wykonania dzieła jest sprzeczne z art. 29 ust. 1 Prawa zamówień publicznych, gdyż Wykonawca powinien niezbędne

30 informacje do wyceny określonego dzieła. Tymczasem SIWZ zakłada, że dzieło ma być wyceniane jak umowa o świadczenie usług.

1. Wprowadzenie P. O.(przedstawiciela Zamawiającego), jako osoby która de facto decyduje o sposobie realizacji danej Dyspozycji Rezultatu, poprzez definicję konkretnych Sprintów w ramach których dana dyspozycja jest realizowana. Mówi o tym wprost postanowienie punktu 4.43.1: „Zakres Sprintu: celem tego zdarzenia jest stworzenie Rejestru Wymagań Sprintu, czyli zakresu prac do wykonania w danym Sprincie i ich rezultatów. W celu uniknięcia wątpliwości ostateczna decyzja co do ustalenia zakresu Sprintu i rozpoczęcia prac w jego ramach; należy do P. O.". Rola P. O.(Zamawiającego), jako osoby mającej decydujący wpływ na sposób realizacji dzieła występuje również w cytowanym już powyżej pkt. 4.44, a także w pkt 4.7. Takie postanowienia całkowicie przeczą istocie „umowy o dzieło", jaką jest Dyspozycja Rezultatu, gdyż realizacja takiej umowy nie może się odbywać pod wymaganym w powyższych zapisach de facto kierownictwem Zamawiającego, bowiem nie pozwala to Wykonawcy na zarządzaniem ryzykiem związanym ze swoim zobowiązaniem wykonania określonego dzieła w zadanym terminie i za określone wynagrodzenie. Wady powyższych zapisów nie umniejsza fakt, iż Zamawiający (zapewne samemu rozumiejąc, iż proponowana konstrukcja Dyspozycji Rezultatu

jest w istocie wadliwa) zawarł następujące postanowienie „4.9 W celu uniknięcia wątpliwości Strony oświadczają, że niezależnie od udziału P. O. w planowaniu prac objętych Dyspozycją Rezultatu zgodnie z postanowieniem poprzedzającym, Wykonawca przyjmuje wyłączną odpowiedzialność za osiągnięcie rezultatu stanowiącego przedmiot danej Dyspozycji.", bowiem fakt tego oświadczenia nie zmienia stanu faktycznego polegającego na tym, iż obecność P. O. w proponowanej w Umowie roli stoi w sprzeczności z istotą wykonywania działa przez Wykonawcę.

W związku z powyższym Wykonawca wnosił o zmianę postanowień Umowy w zakresie postanowień związanych z Dyspozycja Rezultatu, w sposób zgodny z istota „umowy o dzieło", ti.: - wymagania zastosowania podejścia opartego na Scrum do realizacji dzieła w określonym terminie i za określonym wynagrodzeniem, - powierzenie Wykonawcy wyłącznego kierownictwa nad realizacja dzieła oraz ograniczenia udziału Zamawiającego do sprawowania ogólnego nadzoru w realizacji Dyspozycji w trakcie jej trwania w miejsce obecnego bezpośredniego uczestnictwa, - eliminacje nieuzasadnionych obowiązków ewidencyjnych.

31 Odwołujący nie wskazuje konkretnych zapisów po zmianach, gdyż wiąże to się z szeroka zmianą SIWZ, pozostającą w dyspozycji Zamawiającego. Celem zmiany ma być zlikwidowanie stanu sprzeczności pomiędzy wprowadzoną dla Dyspozycji Rezultatu konstrukcją umowy o dzieło a postanowienia sprzecznymi z tą konstrukcją.

1. Wzór Umowy: Załącznik nr 2a do SIWZ i Załącznik nr 2b do SIWZ - Art. 16 Wynagrodzenie i rozliczenia, pkt 16.7 W pkt. 16.7 Umowy Zamawiający definiuje wynagrodzenie za poszczególne Usługi Autoryzacji w następujący sposób:

„16.7. Za poszczególne Usługi Autoryzacji Wykonawca otrzyma wynagrodzenie stanowiące iloczyn stawki jednostkowej za Roboczogodzinę określonej w 16.10.1 lub stawki za Punkt Funkcyjny określonej w 16.10.2 oraz 10% liczby Roboczogodzin lub Punktów Funkcyjnych zawartych w protokole odbioru po rozliczeniu dyspozycji przez Zamawiającego na rzecz dostawcy danego oprogramowania podlegającego autoryzacji."

Z powyższego wynika, że za Usługę Autoryzacji Wykonawca otrzyma wynagrodzenie stanowiące 10% kosztów wytworzenia autoryzowanego produktu. Zdaniem Odwołującego wynagrodzenie w tej wysokości w żaden sposób nie pokryje rzeczywistych kosztów Usługi Autoryzacji.

Odwołujący zwracał uwagę, że średnio szacuje się, że same koszty testowania oprogramowania to ponad 20% kosztów wytworzenia oprogramowania (przykładowo za (…)).

Tymczasem w wypadku Usługi Autoryzacji Wykonawca nie tylko będzie musiał przeprowadzić testy oprogramowania przekazanego do autoryzacji, ale także przed rozpoczęciem testów: zapoznać się z merytoryką rozwiązania, zweryfikować wszystkie elementy rozwiązania, w tym: dokumentację analityczną, o o dokumentację projektową, o wytworzone oprogramowanie, w tym co najmniej: o ■ audyt kodu źródłowego, audyt zgodności z przyjętymi zasadami programowania,

32 dokumentację testową, w tym: o ■ plany testów, ■ scenariusze testowe, ■ przypadki testowe, ■ skrypty testowe, ■ dane testowe,

dokumentację administracyjną, o o dokumentację techniczną, o dokumentację użytkownika, o skrypty instalacyjne. o Dopiero taka weryfikacja umożliwi przeprowadzenie procesu testowania rozwiązania, w tym oprócz testów funkcjonalnych przeprowadzenie testów: modułowe, integracyjne, wydajności, skalowalności, bezpieczeństwa, użyteczności, zgodności z wymaganiami w stosunku do interfejsu użytkownika (np. WCAG), regresji.