Wyrok KIO 937/20 z 9 lipca 2020

Odwołanie zostało wniesione w postępowaniu o udzielenie zamówienia publicznego prowadzonym w trybie przetargu ograniczonego na podstawie ustawy z dnia 29 stycznia 2004r. Prawo zamówień publicznych (Dz. U. z 2019 r. poz. 1843.), [ustawa Pzp lub Pzp] przez Zamawiającego: Zakład Ubezpieczeń Społecznych w Warszawie w przedmiocie zamówienia publicznego na: „Rozwój i utrzymanie Portalu klienta oraz Szyny usług (ESB) w ramach Platformy usług elektronicznych ZUS”. Numer referencyjny: TV271/89/19. Ogłoszenie o zamówieniu zostało opublikowane w Dz. Urz. UE w dniu 21/04/2020, 2020/S 078- 184546.

Wnoszący odwołanie wykonawca: Asseco Poland S.A. z Rzeszowa podniósł w odwołaniu zarzuty wobec postanowień specyfikacji istotnych warunków zamówienia (SIWZ) i jej załączników wskazując na naruszenie następujących przepisów:

1. art. 29 ust. 1 Pzp - opisanie przedmiotu zamówienia, w tym obowiązków wykonawcy w sposób niejednoznaczny, niewystarczający, niepełny, niejasny, który uniemożliwia przygotowanie oferty;
2. art. 29 ust. 1 Pzp - zaniechanie podania w SIWZ wszystkich okoliczności i wymagań mogących mieć wpływ na sporządzenie oferty;
3. art. 29 ust. 2 Pzp w związku z art. 7 ust. 1 Pzp - opisanie obowiązków wykonawcy w sposób, który mógłby utrudniać uczciwą konkurencję;
4. art. 91 ust. 2c i 2d Pzp w związku z art. 7 ust. 1 Pzp - określenie pozacenowych kryteriów oceny ofert w sposób niepowiązany z przedmiotem zamówienia i w sposób uniemożliwiający ich należytą weryfikację oraz z naruszeniem zasady przejrzystości;
5. art. 471 Kodeksu cywilnego, art. 473 Kodeksu Cywilnego, art. 353 (1) KC w z art. 14 i art.

139 ust. 1 Pzp - określenie odpowiedzialności wykonawcy niezgodnie z zasadami odpowiedzialności kontraktowej oraz zasadą swobody umów;

1. art. 140 ust. 1 Pzp i art. 144 ust. 1 pkt 1 i 2 Pzp w związku z art. 2 pkt 13 Pzp - wymaganie, aby część usług świadczona była nieodpłatnie;
2. art. 7 ust. 1 Pzp w związku z w/w przepisami - prowadzenie postępowania z naruszeniem zasad Prawa zamówień publicznych, tj. z naruszenie zasady zachowania uczciwej konkurencji, zasady równego traktowania wykonawców, zasadą proporcjonalności oraz zasadą przejrzystości.
3. art. 44 ust. 3 ustawy z dnia 27 sierpnia 2009 r. o finansach publicznych - naruszenie zasady, iż wydatki publiczne powinny być dokonywane w sposób celowy i oszczędny, z zachowaniem zasady uzyskiwania najlepszych efektów z danych nakładów oraz doboru optymalnych środków.

Odwołujący wniósł o uwzględnienie odwołania i nakazanie Zamawiającemu dokonania modyfikacji Specyfikacji Istotnych Warunków Zamówienia w zakresie wskazanym w odwołaniu poprzez zmianę wskazanych zapisów w sposób wskazany - szczegółowo w każdym zarzucie.

W przypadku uwzględnienia przez Zamawiającego w całości zarzutów przedstawionych w odwołaniu (art. 186 ust. 2 Ustawy), Odwołujący żądał od Zamawiającego dokonania czynności zgodnie ze wskazanym powyżej żądaniem Odwołania.

Podał, że Odwołujący ma interes we wniesieniu niniejszego odwołania, gdyż wskazane w odwołaniu niezgodne z prawem postanowienia SIWZ powodują, że Odwołujący nie ma możliwości złożenia oferty i tym samym utraci szansą na uzyskanie zamówienia. Odwołujący może zatem ponieść szkodę w wyniku naruszenia przez Zamawiającego przepisów Ustawy wskazanych w odwołaniu. Gdyby nie sprzeczność z prawem objętych odwołaniem postanowień SIWZ, Odwołujący mógłby złożyć ofertę, uzyskać zamówienie - a następnie należycie realizować zamówienie. Ustalenie przez Zamawiającego przedmiotowej treści SIWZ uniemożliwia Odwołującemu udział w postępowaniu. Ponadto - w wyniku w/w naruszeń przepisów Ustawy może dojść do następczego unieważnienia postępowania - co także naraziłoby Odwołującego na poniesienie szkody.

1. SIWZ - Pkt 7„Kryteria i zasady oceny ofert" Zamawiający w SIWZ w pkt 7.2. określił w SIWZ 3 kryteria oceny ofert:
2. Całkowita cena oferty brutto - 60%
3. Poziom dostępności usług (SLA) - 30%
4. Doświadczenie personelu -10% Zdaniem Odwołującego kryterium „Poziom dostępności usług (SLA)" jest pozornym kryterium poza cenowym, zwłaszcza mając na uwadze wysoką wagę, jaką Zamawiający nadał temu kryterium. Każdy wykonawca zdaje sobie sprawę, że zobowiązany będzie dochować SLA i usuwać Incydenty. Minimalny poziom dostępności Systemu wynosi 98%. W ramach przedmiotowego kryterium wykonawcy mogą zadeklarować podniesienie dostępności o 1% do 99%. Każdy wykonawca, który zadeklaruje ten 1% większą dostępność dla 4 elementów wskazanych w kryterium - otrzyma 30 punktów, maksymalną liczbę punktów w tym kryterium.

Świadczenie takich usług wiąże się z ponoszeniem przez wykonawcę konkretnych kosztów kosztów utrzymania zespołu ludzi, który świadczy takie usługi. A zatem ewentualne podniesienie poziomu SLA z 98% do 99% wpływa jedynie na cenę oferty, a nie jest kryterium innym niż cena/koszt wykonania. Zgodnie z doświadczeniem Odwołującego, w przypadku takiego nieweryfikowalnego na etapie oceny ofert kryterium pozacenowego wszyscy wykonawcy i tak oferują, a w zasadzie deklarują najwyższy możliwy poziom SLA, co sprowadza się do tego, że wybór oferty najkorzystniejszej dokonuje się wyłącznie na podstawie ceny zaoferowanych ofert - z ewentualnym minimalnym wpływem (w wysokości 10%) za doświadczenie personelu. Zatem w praktyce ukształtowanie takiego kryterium stanowi obejście przepisu art. 91 ust. 2a Pzp, który wskazuje, że cena może stanowić maksymalnie 60% wagi oceny ofert - w przypadku niniejszego postępowania wynosi ona bowiem w praktyce aż 90%. Zdaniem wykonawcy jest to również kryterium nieweryfikowalne na etapie oceny ofert. SIWZ dopuszcza bowiem sytuację, w której wszyscy wykonawcy wskażą maksymalny poziom SLA, a następnie zaś na etapie realizacji Umowy wybrany wykonawca nie będzie tego SLA dochowywał. Zatem weryfikacja ofert w tym kryterium dokonywana byłaby dopiero na etapie wykonywania Umowy (zamiast na etapie oceny ofert).

Na etapie oceny ofert Zamawiający może jedynie przyjąć „na wiarę" deklarację wykonawcy.

Podczas gdy ustawodawca w przepisie art. 91 ust. 2d ustawy Pzp wymaga, aby kryteria oceny ofert zostały określone w sposób umożliwiający sprawdzenie informacji przedstawionych przez wykonawców. Zamawiający powinien zatem tak skonstruować SIWZ, aby możliwe było dokonanie już na etapie oceny ofert odpowiedniej weryfikacji zgodnie z przepisem art. 91 ust.

2d Pzp. Zdaniem Odwołującego jedyny możliwy sposób weryfikacji kryterium poza cenowego, to żądanie od wykonawców, aby w ofercie zamieszczano informacje obiektywne, możliwe do sprawdzenia przez Zamawiającego, które jednocześnie nie są kryteriami pozornymi, przekładającymi się wyłącznie na cenę realizacji przedmiotu zamówienia. Wskazał ponadto, że Zamawiający w równolegle prowadzonym przez ZUS postępowaniu na „Świadczenie usług wsparcia eksploatacji i utrzymania Kompleksowego Systemu Informatycznego Zakładu Ubezpieczeń Społecznych” sformułował 2 weryfikowalne kryteria poza cenowe: - 30% - Test kompetencji technicznych (T) - w kryterium tym zostanie przeprowadzona weryfikacja sposobu świadczenia usługi przez wykonawcę na przykładzie klasy zadań, jakie mogą występować w ramach realizacji usług utrzymania systemów o skali porównywalnej z KSI ZUS. - 10% - Test kompetencji biznesowych (B). W kryterium Test kompetencji biznesowych zostanie przeprowadzona weryfikacja poziomu wiedzy merytorycznej z czterech podstawowych obszarów biznesowych. Zadania Testu kompetencji biznesowych będą dotyczyły niezbędnej wiedzy dla prawidłowej realizacji usług utrzymania systemu KSI ZUS.

Nic nie stoi na przeszkodzie zatem, aby także w niniejszym postępowaniu Zamawiający wprowadził takie testy kompetencji. Wskazał również przykładowo, jakie kryteria poza cenowe są stosowane przez innych zamawiających przy zamawianiu systemów informatycznych podobnego rodzaju - co do skali i wartości - w postępowaniach z obiektywnymi i weryfikowalnymi kryteriami oceny:

Zamawiający

GŁÓWNY URZĄD GEODEZJI I KARTOGRAFII

Postępowanie

Poza cenowe kryterium oceny ofert 20% Wydajność procesu produkcji W ramach kryterium Budowa oraz rozwój e-usług i „Wydajność procesu produkcji" Wykonawca może narzędzi w ramach projektów CAPAP, ZSIN Faza 11 i K-GESUT uzyskać 0, 5,10,15 lub 20 punktów, w zależności od zaproponowanej przez Wykonawcę wydajności procesu wraz ze szkoleniami. produkcji, rozumianej jako liczby Punktów Funkcyjnych możliwych do realizacji w ramach Zleceń w ciągu miesiąca Numer sprawy: BOZP.2610.41.2016.IZ.CAPAP. ZSIN 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ż Faza II. K-GESUT oferowana w kryterium.

30%-Zasady oceny według kryterium kryteria technicznojakościowe próbki Ocena kryterium będzie dokonywana na podstawie oceny spełnienia wymagań opisanych w Załączniku do SIWZ, w załączonej przez Wykonawcę ofercie.

Jako jakość rozwiązania oferty rozumiana jest sumaryczna liczba punktów uzyskana z oceny spełnienia wymagań opisanych w Załączniku do SIWZ w złożonej przez Wykonawcę ofercie.

MINISTERSTWO Usługi dotyczące Centralnego RODZINY, PRACY 1 Systemu Informatycznego Zabezpieczenia Społecznego POLITYKI (CSIZS).

SPOŁECZNEJ

GŁÓWNY INSPEKTORAT TRANSPORTU DROGOWEGO

Znak sprawy: 10/DI/PN/2016

35% - Koncepcja realizacji pulpitu administracyjnego statystyk Centralnego Systemu Informatycznego Zabezpieczenia Społecznego Zamawiający dokona oceny w tym kryterium na podstawie załączonej do oferty koncepcji, o której mowa w SIWZ. Oceny dokonywać będą członkowie merytoryczni komisji przetargowej.

10% - Dodatkowe kwalifikacje osób zdolnych do wykonania zamówienia

Budowa, wdrożenie, utrzymanie i Zamawiający będzie oceniał, posiadane przez osoby rozwój Krajowego Rejestru Elektronicznego Przedsiębiorców zdolne do wykonania zamówienia, dodatkowe kwalifikacje (wykraczające poza projekty wskazane na Transportu Drogowego Numer potwierdzenie spełnienia warunku udziału w sprawy: BDG.ZPB.230.13.2016 postępowaniu) na podstawie Wykazu doświadczenia członków zespołu Wykonawcy, którzy będą oddelegowani do realizacji zamówienia.

25% - Ocena funkcjonalno-techniczna zaproponowanego rozwiązania Ocena funkcjonalno-techniczna zaproponowanego rozwiązania stanowi sumą punktów uzyskanych po wypełnieniu tabeli opisanej w Opis rozwiązania.

Z powyższego zdaniem Odwołującego wynika, że możliwe jest określenie w SIWZ takich kryteriów poza cenowych, które z jednej strony będą związane z przedmiotem zamówienia, a z drugiej - umożliwią sprawdzenie informacji przedstawianych przez wykonawców przed zawarciem umowy, na etapie oceny ofert. Wskazane powyżej braki SIWZ, które skutkują brakiem porównywalności i niemożliwością weryfikacji ofert w zakresie przedmiotowego kryterium, naruszają przepis art. 91 ust. 2c i 2d Ustawy PZP. 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 jest najważniejsze - umożliwiałyby sprawdzenie informacji przedstawionych przez wykonawców. Obecne brzmienie SIWZ nie zawiera żadnych, nawet minimalnych postanowień, które umożliwiłyby Zamawiającemu weryfikację oświadczenia złożonego przez wykonawców. A to z kolei skutkuje naruszeniem przepisu art. 7 ust. 1 PZP, gdyż postępowanie staje się niekonkurencyjne w zakresie przedmiotowego kryterium.

Odwołujący wniósł o zmianę SIWZ poprzez:

1. wykreślenie kryterium „Poziom dostępności usług „SLA"
2. wprowadzenie w to miejsce kryterium „Test kompetencji technicznych" - w kryterium tym zostanie przeprowadzona weryfikacja sposobu świadczenia usługi przez wykonawcę na przykładzie klasy zadań, jakie wystąpią w ramach realizacji Umowy - ze względu na zakres przedmiotu zamówienia konieczne byłoby przeprowadzenie osobno testów dla usług utrzymaniowych, a osobno dla usług rozwojowych, a. Test kompetencji technicznych dla usług rozwojowych - w kryterium tym zostanie przeprowadzona weryfikacja, czy wykonawca posiada umiejętności niezbędne do rozwoju Systemu. Weryfikacji podlegać będą obszary kompetencji niezbędne zarówno do dostosowywania Systemu do nowych wymagań, jak i do świadczenia usług serwisu oprogramowania, czyli: i. umiejętność tworzenia specyfikacji wymagań, ii. umiejętność przeprowadzenia analizy systemowej i opisanie jej zgodnie z narzucona przez Zamawiającego metodyka, iii. umiejętność analizy kodu źródłowego wytworzonego przez poprzednich Wykonawców i wykrywanie w nim błędów, iv. umiejętność wprowadzania zmian do kodu źródłowego. v. umiejętność budowania i uruchamianie aplikacji.

Zadania realizowane będą z wykorzystaniem narzędzi, które są w posiadaniu Zamawiającego.

Oznacza to, że zadania z obszaru i. oraz ii. wykonywane będą z wykorzystaniem Enterprise Architect, a do wykonania zadań z obszarów iii., iv. oraz v. wykorzystywane będą technologie programistyczne oraz środowisko specyficzne dla Systemu ti.: ■ Postgres Plus Adyanced Server, ■ Webmethods, ^JBoss/Java, ■ LiferayOpenShift/Docker, ■ HTML5. b. Test kompetencji technicznych dla usług utrzymaniowych - w kryterium tym zostanie przeprowadzona weryfikacja sposobu świadczenia usług przez Wykonawcę na przykładzie klasy zadań, jakie mogą występować w ramach realizacji usług utrzymania systemów o skali, złożoności i krytyczności usług porównywalnej z PUE, Zadania będą realizowane przy pomocy standardowego oprogramowania narzędziowego, z wykorzystaniem jego specyficznych operacji i będą dotyczyły problemów związanych z administrowaniem systemami informatycznymi występującymi w systemie o skali, złożoności i krytyczności usług porównywalnej z PUE. Zakres technologiczny weryfikacji: i. Postgres Plus Adyanced Server • Strojenie i rekonfiguracja motoru Postgres oraz struktury bazodanowej wraz z weryfikacją biegłości operowania na danych. Zakres tematyczny zadań: a. Analiza logów b. Aktualizacja statystyk c. Zarządzanie struktura bazy danych d. Znajomość ról i uprawnień ii. Liferay • Strojenie i rekonfiguracia platformy Liferay. Zakres tematyczny zadań: a. Analiza logów b. Wykonywanie publikacji iii. Webmethods • Strojenie i rekonfiguracia platformy Webmethods. Zakres tematyczny zadań: a. Analiza logów b. Umiejętność wykorzystania WebMethods Integration Server iv. Red Hat • Wykonanie zadań konfigurowania systemu w celu realizacji określonych funkcjonalności, weryfikacji zdolności poruszania się w środowisku Red Hat wraz z reagowaniem na sytuację awaryjne. Zakres tematyczny zadań: a. Analiza logów b. Konfiguracja Kernel c. Zarządzanie dyskami d. Konfiguracja sieci LAN e. Zarządzanie uprawnieniami v. OpenShift • Realizacja zadań instalacyjnych, administracyjnych oraz konfiguracyjnych na platformie Openshift. Zakres tematyczny zadań: a. Instalacja i konfiguracja aplikacji kontenerowych na platformie OpenShift b. Konfiguracja node'ów klastra OpenShift do stanu opisanego w treści zadania c. Konfiguracja oraz podłączenie zasobów trwałych do aplikacji kontenerowych na platformie OpenShift.

1. wprowadzenie zasad przeprowadzenia „Testu kompetencji technicznych" - można zastosować odpowiednio postanowienia z w/w postępowania na „Świadczenie usług

wsparcia eksploatacji i utrzymania Kompleksowego Systemu Informatycznego Zakładu Ubezpieczeń Społecznych”, ze wskazaniem, że personel skierowany do w/w testów powinien stanowić personel wykonawcy kierowany przez wykonawcę do realizacji zamówienia.

1. „Wzór umowy”, Artykuł 2 „Przedmiot Umowy", ust. 1: Wirtualny Doradca oraz Rozwój i Utrzymanie Oprogramowania Standardowego W art. 2 ust 1 Zamawiający zdefiniował ogólnie przedmiot umowy jako: „Przedmiotem Umowy jest rozwój i utrzymanie Systemu", a w dalszej części ust. 1 nie odnosząc się już w ogóle do przedmiotu zamówienia. W dalszej części ust. 1 Zamawiający wymienił komponenty, z jakich zbudowany jest System, wymieniając .poszczególne elementy programowe Systemu - dzieląc je na 6 grup, w tym Oprogramowanie standardowe. Dalej w art. 2 ust. 3 Zamawiający wskazuje przedmiot umowy poprzez doprecyzowanie, na czym polegać mają usługi utrzymania i rozwoju. Przedstawiony w art. 2 ust 3 przedmiot umowy jest nieprecyzyjny i niejasny.

Zmawiający nie wskazuje, które dokładnie komponenty Systemu (wymienione w ust. 1) podlegają utrzymaniu, a które rozwojowi. Aktualne brzmienie art, 2 ust. 1 i 2 może wskazywać, że obowiązkiem Wykonawcy będzie świadczenie zarówno usług rozwoju jak i utrzymania dla wszystkich komponentów Systemu, które zostały wymienione w art. 2 ust. 1. Taka sytuacja jest jednak niemożliwa do realizacji z uwagi na to, że na liście komponentów wchodzących w skład Systemu znajduje się m.in. oprogramowanie komercyjne, które jest rozwijane tylko przez komercyjnych dostawców i tylko te podmioty są uprawnione do dokonywania zmian w oprogramowaniu. Zatem świadczenie usług rozwoju następującego oprogramowania: Liferay, Postgres Plus Advanced Server, MS SQL Server, Kontrolka KIR Szafir SDK, Wirtualny Doradca, Wirtualny Inspektorat, Silnik Wirtualnego Doradcy - Stanusch Technologies (obecnie Omni-Channel Chat Bot), JBoss Enterprise Aplication Platform z obiektywnych powodów jest nierealizowalne przez podmioty inne niż firmy, które posiadają odpowiednie prawa własności intelektualnej. Zarówno Zamawiający jak i Odwołujący nie mają odpowiednich praw własności intelektualnej, ani tym bardziej kodów źródłowych, aby móc rozwijać lub modyfikować tego typu oprogramowanie. Nie jest też możliwe zawarcie odpowiednich umów, gdyż firmy dysponujące prawami do w/w oprogramowania nie zawierają takich umów. Dodatkowo na liście Oprogramowania standardowego, z którego zbudowany jest System, wymienione jest oprogramowanie rozwijane na zasadzie wolnego oprogramowania (ang. open source): Nginx, Apache SOLR, Apache http server, HAproxy Apache Tomcat, Squid Proxy, ClamAV Open shift Origin Keycloak. Rozwój tego typu oprogramowania odbywa się przez szeroką społeczność programistów z całego świata. Teoretycznie rozwój tego typu oprogramowania jest możliwy przez podmiot realizujący Umowę, zgodnie z licencją open source. Takie podejście jest jednak całkowicie nieracjonalne ze względów na niską efektywność oraz niewystarczający poziom bezpieczeństwa. Wykorzystywane w Systemie Oprogramowanie standardowe open source to skomplikowane i rozbudowane rozwiązania. Samo środowisko Apache Tomcat to ok 0,5 min linii kodu źródłowego rozwijane przez kilkusetosobowy zespół programistyczny. Samodzielne rozwijanie produktów open source przez wykonawcę na potrzeby realizacji Umowy doprowadziłoby do kastomizacji tego oprogramowania na potrzeby ZUS i tym samym spowodowałoby problemy w innych obszarach. Po takiej kastomizacji nie będzie można w prosty sposób zastosować poprawek wydawanych przez społeczność dla tego oprogramowania. Wprowadzone na etapie rozwoju kastomizacje doprowadziłyby do tego, że aktualizacja oprogramowania open source byłaby bardzo utrudniona, pracochłonna i kosztowna, a w skrajnych przypadkach aktualizacja będzie wręcz niemożliwa. Dodatkowo przy tego typu podejściu nie można wykluczyć obniżenia poziomu bezpieczeństwa. Jedną z zalet stosowania oprogramowania na licencji open source jest dostęp do kodu źródłowego dla wszystkich zainteresowanych. Społeczność internetowa ma możliwość przeglądu kodu źródłowego, co zdecydowanie zwiększa prawdopodobieństwo wykrycia podatności w tym oprogramowaniu. Podatności te następnie będą mogły być sprawnie wyeliminowane poprzez wydanie stosownej poprawki. Przy samodzielnym rozwoju oprogramowania open source, nowy kod źródłowy nie trafi do szerokiej społeczności i nie będzie możliwa jego analiza przez tak szeroki zespół specjalistów. Drugi ważny aspekt związany z bezpieczeństwem to problem instalowania poprawek w tym wypadku eliminujących zidentyfikowane podatności. Tak jak zostało wspomniane powyżej, kastomizacja może utrudnić lub wręcz uniemożliwić instalowanie poprawek dystrybuowanych w ramach danego projektu. Jak wynika z powyższego, przedmiotowe postanowienia SIWZ są co najmniej nieprecyzyjne, jeśli wręcz nie kreują zobowiązania niemożliwego do wykonania. Na podstawie w/w postanowień Odwołujący nie jest w stanie na etapie przygotowania oferty ustalić, jaki zakres prac będzie musiał realizować w trakcie realizacji umowy, a tym samym nie jest w stanie przygotować oferty, co narusza art. 29 ust. 1 Ustawy PZP. Obecnie Odwołujący nie ma możliwości wyceny usług rozwoju i modyfikacji dla w/w oprogramowania. Zatem konieczne jest wskazanie w przedmiocie umowy, w stosunku do których elementów Systemu świadczone będą usługi rozwoju i modyfikacji, a w stosunku do których tylko usługi utrzymania - przy czym rozdzielenie tych dwóch zakresów powinno zostać dokonane z uwzględnieniem zachowania praw własności intelektualnej podmiotów trzecich oraz racjonalnego zakresu korzystania przez

Zamawiającego z oprogramowania typu open source.

Odwołujący wniósł o nakazanie Zamawiającemu zmianę treści art. 2 ust. 1 i 3 na następujące:

1. Przedmiotem Umowy jest rozwój i utrzymanie Systemu, w skład którego wchodzą:
2. Aplikacje portalowe: a) Portal PUE, składający się z: • części informacyjnej - ogólnodostępnej, • informacji spersonalizowanych dostępnych PO zalogowaniu, • usług transakcyjnych: b) Wirtualny Doradca. c) Wirtualny Inspektorat, d) kontrolki do stosowania podpisu elektronicznego w przeglądarce internetowej. e) e-Płatnik, f) konsola pracownika. g) konsola administratora.
3. SSOBP (Single Sign-On Bank PUE) - moduł integracji zewnętrznych systemów bankowych z PUE:
4. SSOGP (Single Sign-On portal biznes.gov.pl do Portalu PUE) - moduł integracji zewnętrznego systemu z PUE z gov.pl:
5. SAG Środowisko symulacyjne elektronicznych Zaświadczeń Lekarskich (eZLA);
6. Szyna Usług ESB;
7. Oprogramowanie standardowe fw tym bazy danych PUE) - w ramach Platformy Usług Elektronicznych ZUS (według stanu na dzień zawarcia Umowy): a) Webmethods, b) Kontrolka KIR Szafir SDK, c) JBoss Enterprise Aolication Platform, d) Nginx, e) Liferay f) Aoache SOLR w Liferay, g) Aoache http server. h) HAproxy, i) Apache Tomcat, j) Postgres Plus Advanced Server, k) MS SQL Server, l) Squid Proxy, m) ClamAVt n) Silnik wirtualnego doradcy - Stanusch Technologies (obecnie OmniChannel Chat Bot), o) Openshift Origin,

p) Keycloak.

1. [bez zmian]
2. Przedmiot Umowy obejmuje:
3. Rozwój i Modyfikacje Systemu w zakresie następujących komponentów Systemu: a) Aplikacje portalowe: a. Portal PUE. składający się z: o części informacyjnej - ogólnodostępnej, o informacji spersonalizowanych dostępnych po zalogowaniu, o usług transakcyjnych; b. kontrolki do stosowania podpisu elektronicznego w przeglądarce internetowej, c. e-Płatnik, d. konsolapracownika, e. konsola administratora, f. APeZLA Autonomiczny Pulpit Lekarza; b) SSOBP (Single Sign-On Bank PUE) - moduł integracji zewnętrznych systemów bankowych z PUE; c) SSOGP (Single Sign-On portal btznes.gov.pl do Portalu PUE) - moduł integracji zewnętrznego systemu z PUE z gov.pl: d) SAG Środowisko symulacyjne elektronicznych Zaświadczeń Lekarskich jeZLA); e) Pakiety Oprogramowania użytkowego na Szynie Usług ESB:
4. przeprowadzenie instruktaży w formie warsztatów, instruktaży i praktyk:
5. Usługi dodatkowe obejmujące w szczególności: a) migracje rozwiązania na infrastruktury techniczno-systemowe posiadane przez Zamawiającego, b) wsparcie doradcze w zakresie usług rozwoju i utrzymania, c) wytwarzanie narzędzi wspierających rozwój i utrzymanie, d) opracowywanie i dostarczanie dokumentacji związanej ze świadczeniem Usług dodatkowych;
6. Usługi utrzymania w zakresie następujących komponentów Systemu, z zastrzeżeniem zapisów w art. 11 ust 2: a) Komponenty wymienione w ust. 1 pkt 1 b) JBoss Enterprise Aplication Platform, c) Nginx, d) Apache SOLR w Liferay, e) Apache http server, f) HAproxv, g) Apache Tomcat, h) Sauid Proxv, i) ClamAV, j) Wirtualny Doradca,

k) Wirtualny Inspektorat l) Silnik wirtualnego doradcy - Stanusch Technologies (obecnie Omni- Channel Chat Bot). m) Openshift Origin, n) Keycloak.

1. przenoszenie autorskich praw majątkowych do Rezultatów prac. Kodów źródłowych i Dokumentacji Wykonawcy oraz udzielanie sublicencji lub dostarczenie licencji na Oprogramowanie standardowe wchodzące w zakres przedmiotu Umowy”.
2. Wzór umowy, Artykuł 5 „ Oświadczenia i obowiązki Wykonawcy", ust. 8 pkt 4 i 5.

Zmawiający w art. 5 ust. 7 ustanowił dla siebie uprawnienie do przeprowadzenia audytu prac Wykonawcy. W art 5 ust. 8 określił zasady przeprowadzenia tego audytu. Wykonawca zakwestionował pkt 4 i 5. „8. Audyt, o którym mowa w ust 7, prowadzony będzie na następujących zasadach: (■■■)

1. z wykonania audytu Zamawiający sporządzi protokół, który może zawierać zalecenia usunięcia niezgodności;
2. Wykonawca zobowiązany jest do usunięcia niezgodności w terminie określonym przez Dyrektorów Umowy."

Postanowienia pkt 4 i 5 naruszają postanowienia art. 29 ust. 1 ustawy Pzp - Zamawiający tak określił obowiązki wykonawcy, że na etapie przygotowania oferty obowiązki takie nie są znane ani też nie istnieje możliwość ich przewidzenia. Otóż w obecnym brzmieniu w/w pkt 4 i 5 Zamawiający może zawrzeć w protokole z audytu dowolne zalecenia usunięcia niezgodności, zaś wykonawca jest zobowiązany usunąć takie wskazane przez Zamawiającego niezgodności. Zatem samą podstawą powstania zobowiązań po stronie wykonawcy jest umieszczenie w protokole jakichś żądań Zamawiającego. Umowa nie wskazuje, że „zalecenia usunięcia niezgodności" mają być w jakimkolwiek stopniu powiązane z opisem przedmiotu zamówienia. Zatem Zamawiający może ukonstytuować dowolną treść protokołu, nawet wpisując do protokołu żądania i wymagania, które uprzednio nie były umieszczone w SIWZ. Z kolei wykonawca nie ma nawet prawa zgłosić zastrzeżeń - zgodnie z pkt 5 wykonawca ma tylko bezwzględny obowiązek usunięcia niezgodności. Powyższa konstrukcja w sposób oczywisty narusza też zasadę równości stron-obecnie to Zamawiający autorytarnie, na etapie realizacji Umowy, może określać dodatkowe obowiązki wykonawcy nieznane na etapie wyceny oferty.

Odwołujący wniósł o nakazanie Zamawiającemu wykreślenia dotychczasowej treści art. 5 ust.

8 pkt 4 i 5 Umowy i w to miejsce wpisanie:

„4) z wykonania audytu Zamawiający sporządzi protokół, który może zawierać zalecenia usunięcia niezgodności; Zamawiający jest zobowiązany uzasadnić w protokole zarówno samo stwierdzenie niezgodności, jak i zalecenie jej usunięcia, podając podstawę faktyczna i prawna.

1. W przypadku akceptacji treści protokołu Wykonawca zobowiązany jest do usunięcia niezgodności w terminie określonym przez Dyrektorów Umowy. Wykonawca jest uprawniony do zgłoszenia uzasadnionych uwag do treści protokołu. W takim przypadku Zamawiający może zaakceptować bądź odrzucić zgłoszone uwagi W przypadku podtrzymania przez Wykonawcę zgłoszonych uwag, skutkującego niemożnością uzgodnienia przez Strony wspólnego stanowiska, zastosowanie ma procedura eskalacji przewidziana w Załączniku 4".
2. Wzór umowy, Artykuł IX „Usługi utrzymania i gwarancja", ust 2 oraz SIWZ: Pkt II ppkt 4

Zamawiający w SIWZ w punkcie II w podpunkcie 4 in fine wskazał: „Usługi utrzymania nie będą obejmować oprogramowania standardowego: Postgres, Webmethods, Liferay, kontrolka KIR Szafir SDK, MS SQL Server."

Jednocześnie w art. 11 ust. 2 Umowy Zamawiający określił zakres prac związanych z utrzymaniem systemu w następujący sposób: „Usługi utrzymania, o którym mowa w ust 1, nie obejmują Oprogramowania standardowego; Postgres, Webmethods, Liferay, kontrolka KIR Szafir SDK, MS SQL Server z zastrzeżeniem realizacji obowiązku wskazanego w ust. 1 pkt 3."

W obu w/w postanowieniach Zamawiający wskazał wyłączenia - tj. wskazał, które Oprogramowanie standardowe nie będzie objęte usługami utrzymania. Przy czym w postanowieniu art. 11 ust. 2 na końcu wskazał dodatkowe zastrzeżenie. Z powyższego wynika, że Oprogramowanie standardowe Postgres, Webmethods, Liferay, kontrolka KIR Szafir SDK oraz MS SQL Server ma być objęte usługami utrzymania w zakresie wskazanym w ust. 1 pkt 3, czyli - mają być w stosunku do nich świadczone usługi konfiguracji i parametryzacji, zgodnie z postanowieniem art. 11 ust. 1 pkt 3 Umowy: „3) konfiguracja i parametryzacja Oprogramowania standardowego wchodzącego w skład Systemu oraz Infrastruktury techniczno-systemowej w oparciu, o którą zbudowany jest System;" Porównanie w/w postanowień wskazuje, że we wskazanym obszarze istnieje ewidentna sprzeczność pomiędzy dokumentami. W SIWZ, Zamawiający wyłącza z całości usług utrzymania wymienione Oprogramowanie standardowe, natomiast w Umowie Zamawiający wskazuje, że jednak w pewnym zakresie usługi takie mają być świadczone. Na podstawie takich rozbieżnych zapisów Odwołujący nie jest w stanie na etapie przygotowania oferty ustalić, jaki zakres prac będzie musiał realizować w trakcie realizacji umowy, a tym samym nie jest w stanie przygotować oferty co narusza art. 29 ust. 1 ustawy Pzp.

Odwołujący wniósł o nakazanie Zamawiającemu dokonania zmian w art. 11 ust. 2:

„2. Usługi utrzymania, o którym mowa w ust. 1 nie obejmują Oprogramowania standardowego:

Postgres, Webmethods, Liferay, kontrolka KIR Szafir SDK, MS SQL Server"

1. Wynagrodzenie z tytułu usług Utrzymania - Wzór umowy, Artykuł 12 „Zasady ustalania wysokości wynagrodzenia", ust. 1 pkt 2, Załącznik 5 do Umowy W Załączniku 5 ust. 5 Zamawiający wskazał, że współczynnik rocznego wynagrodzenia z tytułu Usług utrzymania Systemu wynosi 7,2%. Należy z tego wnioskować, że wynagrodzenie to będzie pochodną ceny Punktu Funkcyjnego oraz złożoności Systemu mierzonej w Punktach Funkcyjnych.

Zdaniem Odwołującego wynikający z obiektywnych przesłanek rzeczywisty poziom rocznych kosztów świadczenia Usług utrzymania, jest znacznie wyższy i wskazany współczynnik roczny w wysokości 7,2% jest nieadekwatny do tego poziomu.

System PUE, który jest przedmiotem utrzymania, to obecnie jeden z najbardziej krytycznych systemów funkcjonujących w ZUS. System ten wspomaga istotne ze względu na funkcjonowanie Państwa procesy, takie jak: • przyjmowanie elektronicznych zwolnień lekarskich, • przyjmowanie wniosków 500+, • przyjmowanie elektronicznych dokumentów ubezpieczeniowych, • przyjmowanie wniosków wynikających z realizacji ustawy o szczególnych rozwiązaniach związanych z zapobieganiem, przeciwdziałaniem i zwalczaniem C0V1D-19, innych chorób zakaźnych oraz wywołanych nimi sytuacji kryzysowych.

W związku ze wsparciem tak istotnych procesów wymagane jest przez Zamawiającego, aby System funkcjonował stabilnie i bezawaryjnie, a w przypadku zaistnienia awarii w bardzo krótkim czasie przywrócona była jego funkcjonalność i dostępność usług. Istotność prawidłowego funkcjonowania Systemu Zamawiający wyraził w SIWZ poprzez bardzo rygorystyczne i wyśrubowane wartości oczekiwanych parametrów SLA oraz bardzo wysokie kary umowne przewidziane w przypadku niedotrzymania parametrów SLA. Przykładowo zgodnie z zapisami Załącznika nr 9 do Wzoru Umowy, Zamawiający wymaga, aby Incydent krytyczny został obsłużony w czasie nie przekraczającym 4 godziny, a kalendarz świadczenia

usługi serwisowej to 24 godziny na dobę przez 7 dni w tygodniu (24/7). W przypadku jednak, gdy Wykonawca nie dotrzyma tego parametru SLA, Zamawiający zastrzegł sobie w art. 14 ust.

2 pkt 7) karę umowną za każdą rozpoczętą godzinę opóźnienia w wysokości 10 000 PLN, Spełnienie tak wygórowanych parametrów SLA wymaga od Wykonawcy zwrócenia szczególnej uwagi na proces utrzymania Systemu oraz zapewnienie odpowiedniego zespołu specjalistów pod względem kompetencji merytorycznych oraz liczebności. Tymczasem Zamawiający - poprzez ustalenie wysokości rocznego wynagrodzenia z tytułu usług utrzymania poprzez współczynnik 7,2% - narzuca wykonawcom bardzo niską wartość tego wynagrodzenia, nie pokrywającą nawet kosztów świadczenia usługi na takim poziomie.

Zamawiający nie jest konsekwentny. W ramach KSI ZUS eksploatowany jest system informatyczny o zbliżonej do PUE biznesowo merytoryce, jest to Interaktywny Płatnik Plus (IPP). Oba systemy PUE oraz IPP to systemy o wysokiej krytyczności z uwagi na wspierane przez nie procesy biznesowe w Zakładzie. Oba te systemy wspierają bezpośrednią obsługę Klientów zewnętrznych Zakładu Ubezpieczeń Społecznych z wykorzystaniem elektronicznych kanałów komunikacji. Również kalendarz świadczenia usług jest identyczny dla obu systemów 24/7/365. Prawidłowe i niezawodne funkcjonowanie obu tych rozwiązań jest niezwykle istotne dla Zakładu ze względu na jego zobowiązania ustawowe oraz wizerunek.

Złożoność Systemu IPP to według najlepsze] wiedzy Odwołującego ok. 8 400 CFP, czyli jest to złożoność zdecydowanie mniejsza niż zadeklarowana przez Zamawiającego w SIWZ złożoność PUE (załącznik 5 pkt 5-12.399,8 CFP). Utrzymanie IPP w ramach umowy nr 1064535 na usługę wsparcia eksploatacji i utrzymania KSI ZUS jest realizowane na podstawie metryk usług aplikacyjnych IT udostępniania portali. Miesięczna wysokość wynagrodzenia z tego tytułu to kwota co najmniej 340 tys. PLN brutto (kwota wyliczona na podstawie znanych Odwołującemu wartości wynagrodzenia z tytułu świadczenia tych usług pomniejszona o wynagrodzenie z tytułu bieżącego administrowania w celu uzyskania porównywalności z zakresem usług w ramach niniejszego postępowania). W ramach IPP funkcjonują jeszcze dwie metryki, dla których Odwołujący nie zna wartości i nie uwzględnił ich w w/w kwocie 340 tys.

PLN brutto. Zatem wynagrodzenie z tytułu świadczenia usług utrzymania dla IPP jest na pewno większe od w/w. Gdyby wykonawca chciał otrzymać przy obecnym brzmieniu SIWZ analogiczne wynagrodzenie (co jest racjonalne ze względu na wykazane powyżej podobieństwa pomiędzy systemami PUE i IPP), to musiałby zaoferować cenę za 1 Punkt funkcyjny w wysokości co najmniej 4 569, 97 zł brutto.

Cena 1 CFP = 340.000 zł /(12.399,8 CFP * 0,6%) = 4.569,97 zł gdzie:

0, 6% - współczynnik dla jednego miesiąca: 7,2% /12 miesięcy = 0,6% 12.399,8 CFP - wskazana w SIWZ złożoność systemu PUE Zdaniem Odwołującego przy obecnej nieadekwatnej wartości współczynnika tylko powyższa cena Punktu Funkcyjnego pokrywa koszty świadczenia usług utrzymania. Wychodząc od rzeczywistego poziomu kosztów świadczenia usługi utrzymania wykonawca właściwie jest wręcz zmuszony obliczyć cenę Punktu Funkcyjnego według powyższego wzoru. W efekcie to koszt usług utrzymania zdeterminuje cenę Punktu Funkcyjnego podczas gdy znakomita większość przedmiotu Umowy to usługi rozwoju Systemu i to ich koszt powinien wyznaczać cenę Punktu Funkcyjnego. Wynagrodzenie z tytułu usług utrzymania może być pochodną ceny za Punkt Funkcyjny, ale obliczaną według adekwatnego, a nie istotnie zaniżonego współczynnika. Przy obecnym brzmieniu pkt 5 w Załączniku 5 zaoferowanie niższej ceny Punktu Funkcyjnego byłoby albo naruszeniem przepisu art. 2 pkt 13) Ustawy PZP i oferowaniu wykonania nieodpłatnie części przedmiotu zamówienia lub też zastosowaniem niedozwolonej inżynierii cenowej, w ramach której część kosztów świadczenia usług utrzymania zostałaby przeniesiona do kosztów usług Modyfikacji - koszty usług utrzymania musiałyby być pokryte częściowo z wynagrodzenia za wykonanie Modyfikacji. Z kolei w/w cena Punktu Funkcyjnego byłaby ceną znacznie wyższą niż cena obliczona na potrzeby świadczenia usług rozwoju systemu PUE. Jednakże wykonawcy mogą wskazać w ofercie tylko 1 cenę Punktu Funkcyjnego. Musieliby zatem zastosować cenę obliczoną na potrzeby określenia wynagrodzenia za usługi utrzymania, gdyż w przeciwnym przypadku złożyliby ofertę podlegająca odrzuceniu (o czym powyżej). W efekcie spowodowałoby to konieczność sztucznego zawyżenia ceny 1 CFP, co z pewnością nie leży w interesie Zamawiającego.

Sytuacja powyższa jest skutkiem przyjęcia przez Zamawiającego zbyt niskiego współczynnika dla usług utrzymania. Przyjmuje się, że utrzymanie to koszt minimum 1% wartości systemu miesięcznie i takie też wartości są stosowane powszechnie na rynku - także przez Zamawiającego w innych postępowaniach - jak w w/w wskazanym przypadku utrzymania systemu IPP. Nie jest zatem zrozumiałe, dlaczego Zamawiający w niniejszym postępowaniu tak znacznie zaniżył przedmiotowy współczynnik i ustanowił go na poziomie 0,6% miesięcznie.

Odwołujący wniósł o zmianę w Załączniku nr 5 ust. 5 współczynnika rocznej wartości utrzymania Systemu na wartość 12% (1 % miesięcznie).

1. Wzór umowy, Artykuł 14 „Kary umowne i odpowiedzialność", ust. 5 oraz Załącznik 13 „Matryca kar umownych" Zamawiający określił w Umowie terminy usuwania Incydentów oraz oczekiwany poziom świadczenia usług. Umowa w tym zakresie jest typową umową typu SLA {Service Level Agreement, poi.: Umowa o gwarantowanym poziomie świadczenia usług). Umowy tego rodzaju określają oczekiwane przez Zamawiającego poziomy świadczenia usług. Na rynku usług informatycznych świadczenie usługi utrzymania poniżej oczekiwanego poziomu nie jest równoznaczne z nienależytym świadczeniem usługi - system jest nadal dostępny, możliwe jest działanie Zamawiającego. Skutkiem tego, że usługi świadczone są poniżej oczekiwanego poziomu zmniejszony jest komfort pracy Zamawiającego. Dlatego też przyjęte jest, że Zamawiający nie domaga się kar umownych, a w przypadku niedotrzymania oczekiwanego poziomu usług stosowana jest konstrukcja obniżenia wynagrodzenia wykonawcy, zgodnie z regułami zawartymi w umowie.

Określone przez Zamawiającego czasy usuwania Incydentów są bardzo rygorystyczne. Przy czteroletnim okresie świadczenia usług utrzymania, prawdopodobieństwo niedotrzymania któregoś parametru jest dość wysokie. Z kolei ewentualne - nawet jednokrotne - przekroczenie terminu usunięcia Incydentu nawet o 1 godzinę skutkowałoby naliczeniem kary umownej, co z kolei jest jednoznaczne z uznaniem przez Zamawiającego usług jako nienależycie świadczonych. Z kolei w przypadku takiego uznania nie byłoby możliwe wystawienie przez Zamawiającego na rzecz Wykonawcy listu referencyjnego/poświadczenia. I to także w przypadku, gdyby Zamawiający generalnie był zadowolony ze sposobu realizacji Umowy przez Wykonawcę i gdyby uznawał ten sposób realizacji za zgodny ze standardami obowiązującymi na rynku usług IT, Co więcej - taki Wykonawca umowy nie mógłby w następnym postępowaniu powołać się na wiedzę i doświadczenie uzyskane przy realizacji tej Umowy. I to pomimo tego, że Zamawiający nie stawiałby mu żadnych zarzutów związanych z nienależytą realizacją przedmiotu zamówienia. Analogiczna sytuacja związana jest ze świadczeniem usług opisanych w Załączniku nr 10 „Zakres i poziom świadczenia Usług aplikacyjnych".

Zamawiający minimalny oczekiwany poziom świadczenia usług określił jako dostępność na poziomie 98%. Nie oznacza to, że zapewnienie przez wykonawcę wartości poniżej tej granicy jest nieakceptowalne przez Zamawiającego, zagraża realizacji procesów biznesowych czy też uniemożliwia korzystanie z Systemu. Tym bardziej, że Zamawiający wprowadził w SIWZ w pkt 7.2. poza cenowe kryterium oceny ofert związane z oferowanym poziomem parametrów usług, tj. kryterium Poziom dostępności usług (SLA) - 30%. Poziom dostępności może zostać podniesiony przez wykonawców aż do 99%. W sytuacji, w której wykonawca zaoferowałby poziom parametrów wyższy (np. 99%) niż dopuszczalny oczekiwany (98%), to w przypadku jego niedotrzymania (np. 98,5%), zgodnie z postanowieniami umowy, wykonawca zostałby ukarany karą umowną, co zostałoby uznane za nienależyte świadczenie umowy. A przecież poziom świadczenia usług byłby wyższy od dopuszczalnego oczekiwanego czyli 98%.

Podkreślił, że sam Zamawiający od lat stosuje właśnie instytucję obniżenia wynagrodzenia w kolejnych umowach na Świadczenie usług wsparcia eksploatacji i utrzymania Kompleksowego Systemu Informatycznego Zakładu Ubezpieczeń Społecznych. W szczególności, taka właśnie konstrukcja zastosowana jest w prowadzonym równocześnie przez Zamawiającego postępowaniu na „Świadczenie usług wsparcia eksploatacji i utrzymania Kompleksowego Systemu Informatycznego Zakładu Ubezpieczeń Społecznych (KSI ZUS)". Nie jest zrozumiałe, dlaczego w przedmiotowym postępowaniu Zamawiający zaniechał zastosowania tej powszechnej konstrukcji. Tym bardziej biorąc pod uwagę podnoszone przez Zamawiającego wielokrotnie dążenie do ujednolicania zasad i warunków zawieranych umów z dostawcami. Przedmiotowe postanowienia SIWZ naruszają art. 29 ust. 1 ustawy Pzp w związku z art. 7 ust. 1 ustawy Pzp w związku z art. 44 ust. 3 ustawy z dnia 27 sierpnia 2009 r. o finansach publicznych. Wydatki publiczne powinny być dokonywane w sposób celowy i oszczędny, z zachowaniem zasady uzyskiwania najlepszych efektów z danych nakładów oraz doboru optymalnych środków. Zamawiający powinien racjonalnie określać warunki realizacji Umowy, w tym także stosować kary umowne tylko tam, gdzie jest to niezbędne. Nadmierne zastrzeżenie kar umownych, podczas gdy można zastosować instytucję obniżenia wynagrodzenia wpływa na podniesienie przez wykonawców ceny ofert - wykonawcy do ceny oferty dodają także wysoką rezerwę na ewentualne kary umowne. Tym samym Zamawiający sam doprowadzi do podwyższenia ceny, poprzez nieuzasadnione nadmierne wymagania SiWZ - i to w sytuacji, w której w analogicznych sytuacjach stosuje powszechnie przyjętą instytucję obniżenia wynagrodzenia.

Odwołujący wniósł:

1. o zastąpienie mechanizmu naliczania kar umownych w odniesieniu do usług usuwania Incydentów oraz świadczenia usług aplikacyjnych mechanizmem obniżenia wynagrodzenia Wykonawcy w sposób następujący - analogicznie do zasad obowiązujących w innych umowach Zamawiającego:
2. wykreślenie w Umowie w art. 14 ust. 2 pkt 7) -12) oraz ust. 5.
3. skreślenie dotychczasowej treści Załącznika 13 „Matryca Kar Umownych" i wpisanie w to miejsce:

„ZAŁĄCZNIK 13: Matryca obniżenia wynagrodzenia a) Matryca obniżenia wynagrodzenia z tytułu niedotrzymania pojedynczego Parametru Usług utrzymania dla każdej z Usług aplikacyjnych, o których mowa w Załączniku 10 (zgodnie z art.

14 ust. 5 Umowy).

Wysokość obniżenia wynagrodzenia w PLN Wartość parametru Parametr: (parametr Dostępności) w Parametr:

Parametr: metrykach Usług aplikacyjnych - zgodnie z AVN.2; AVN.3; DST.l; AVN.l; AVZ.l; AVE.l DST.2 ofertą DST.3 98,0% 1 500,00 3 000,00 4 500,00 od 98,1% do 98,3% 1 800,00 3 600,00 5 400,00 od 98,4% do 98,6% 2 250,00 4 500,00 6 750,00 od 98,7% do 99,0% 3 000,00 6 000,00 9 000,00

b) Obniżenie wynagrodzenia z tytułu niedotrzymania parametrów Usług serwisowych, o których mowa w Załączniku 9 do Umowy Dla parametrów Usług serwisowych nalicza się obniżenie w wysokości: • 1000,00 zł PLN (słownie: jeden tysiąc złotych 00/100) za każdy rozpoczęty dzień opóźnienia w udzielaniu Konsultacji utrzymaniowych, • 2 500,00 zł PLN (słownie: dwa tysiące pięćset złotych 00/100) za każdy rozpoczęty dzień opóźnienia w usuwaniu Incydentów niskich, • 5 000,00 PLN (słownie: pięć tysięcy złotych 00/100) za każdy rozpoczęty dzień opóźnienia w usuwaniu Incydentów średnich, • 10 000,00 PLN (słownie: dziesięć tysięcy złotych 00/100) za każdą rozpoczętą godzinę opóźnienia w usuwaniu Incydentów krytycznych.

Obniżenia naliczone w okresie pierwszych 3 miesięcy kalendarzowych świadczenia Usług serwisowych podlegają obniżeniu o 50%. c) Obniżenie wynagrodzenia z pozostałych tytułów * 1000,00 zł PLN (słownie: jeden tysiąc złotych 00/100) za każdy rozpoczęty dzień opóźnienia w przekazaniu prognozowanego zapotrzebowania na zasoby, o którym mowa w art. 11 ust. 1 pkt 7. • 40 000,00 PLN (słownie złotych: czterdzieści tysięcy złotych 00/100) z tytułu odchylenia większego niż 10% pomiędzy prognozowanym zapotrzebowaniem na zasoby Środowiska produkcyjnego przedstawionym w prognozie za ostatni kwartał (art. 11 ust. 1 pkt 7) a obciążeniem rzeczywistym obliczonym na koniec kwartału objętego prognozą zapotrzebowania); kara będzie naliczana odrębnie za każdy parametr. d) Zasady obliczania obniżenia za Usługi utrzymania: i. Podstawą obniżenia wynagrodzenia będą wartości parametrów lub dane wyszczególnione w uzgodnionych raportach, o których mowa w Art. 11 ust.9 Umowy. ii. Obniżenie wynagrodzenia dokonywane jest poprzez wystawienie faktury korygującej za miesiąc, w którym nie dotrzymano parametrów. Faktura korygująca zostanie wystawiona na podstawie podpisanego obustronnie Miesięcznego raportu zbiorczego niedotrzymanych parametrów usług. iii. Obniżenie wynagrodzenia naliczone zgodnie z Załącznikiem 13 za pierwsze trzy miesiące kalendarzowe świadczenia Usług utrzymania podlegają obniżeniu o 50%. iv. Obniżenie wynagrodzenia nie jest uzależnione od zaistnienia lub wykazania przez Zamawiającego poniesienia szkody wskutek niedotrzymania Parametrów usług

Wykonawcy. Jeśli jednak szkoda taka zaistniała, kwota obniżenia wynagrodzenia zalicza się na poczet ewentualnego roszczenia odszkodowawczego Zamawiającego z tego tytułu.

1. Nadanie nowego brzmienia Art.11 ust. 10 Umowy:

„10. W przypadku niedotrzymania przez Wykonawcę Parametrów Usług utrzymania określonych w Metrykach, wynagrodzenie Wykonawcy ulega obniżeniu zgodnie z Załącznikiem 13."

1. Załącznik 1 do Umowy, Definicja Rozwiązania W Załączniku 9 dla każdej Metryki w pkt 2) "Zakresu usług" Obsługi Incydentów, Zamawiający zobowiązuje Wykonawcę do dostarczania Rozwiązań dla przekazanych do jego obsługi Zgłoszeń Incydentów.

Jednocześnie w Załączniku 1 „Definicje" Zamawiający definiuje pojęcie Rozwiązanie następująco:

Całkowite i skuteczne usunięcie Incydentu, jego przyczyn i skutków, w szczególności

Rozwiązanie polegające na Naprawie, w przypadku, gdy przyczyną incydentu jest Błąd. W ramach

Rozwiązania powinno nastąpić także podanie i opisanie przyczyn i skutków wystąpienia Incydentu i udokumentowanie Rozwiązania. W szczególnych przypadkach, decyzją Zamawiającego Obejście może zostać potraktowane jako Rozwiązanie.

Bezspornym jest, że w toku realizacji Umowy zaistnieją przypadki kierowania do obsługi Wykonawcy Zgłoszeń Incydentów, które będą spowodowane okolicznościami leżącymi poza zakresem odpowiedzialności Wykonawcy. Przykładem takich zgłoszeń mogą być zgłoszenia dotyczące: • nieprawidłowego działania oprogramowania spowodowanego działaniem Innych wykonawców; • nieprawidłowego działania oprogramowania mającego swoją przyczynę w infrastrukturze technicznej Zamawiającego.

Zapewne można podać szereg innych przykładów, dla których Wykonawca zgodnie z przytoczoną definicją zobowiązany jest do dostarczania Rozwiązania, pomimo iż wystąpienie Incydentu spowodowane jest okolicznościami leżącymi poza zakresem odpowiedzialności Wykonawcy. Taka definicja jest sprzeczna z dobrymi praktykami obowiązującymi na rynku IT.

Jest także sprzeczna z zasadą odpowiedzialności kontraktowej określoną w art. 471 Kodeksu Cywilnego. Zamawiający pragnie ukonstytuować odpowiedzialność kontraktową Wykonawcy niezależnie od zasady winy. Odwołujący wskazał, że niezależnie od dążenia Zamawiającego do tego, aby dla wszelkich Incydentów dotyczących Systemu wykonawca dostarczał Rozwiązania, należy też uwzględnić słuszny interes wykonawcy, który jest obecnie naruszony dwukrotnie. Po pierwsze wykonawca nie jest w stanie przewidzieć liczby i skali takich nieprawidłowości, co przekłada się na niemożność określenia ceny oferty. Po drugie zaś, wykonawca jest karany przez Zamawiającego w każdym przypadku niedochowania terminów Rozwiązania incydentów - skoro Incydent może być spowodowany okolicznościami będącymi poza zakresem jego odpowiedzialności, to karany jest nawet w sytuacji, w której nie można mu przypisać odpowiedzialności. Należy przy tym rozróżnić 2 kwestie: - racjonalne i uzasadnione wymaganie Zamawiającego, aby wszystkie Incydenty zostały rozwiązane przez wykonawcę poprzez: dostarczenie Rozwiązania dla Incydentów, które mieszczą się w zakresie odpowiedzialności Wykonawcy oraz • •

dostarczenie diagnozy dla Incydentów dotyczących obszarów, za które odpowiada Zamawiający lub strona trzecia. - nakładanie na Wykonawcę sankcji z tytułu rzekomo nienależytej realizacji Umowy w sytuacji, gdy nie można mu przypisać winy za zaistnienie takiej sytuacji - podczas gdy odpowiedzialność kontraktowa powinna być oparta na zasadzie winy.

Odwołujący wniósł o zmianę definicji w brzmieniu:

Rozwiązanie: Całkowite i skuteczne usunięcie incydentu, jego przyczyn i skutków, w szczególności polegające na

Naprawie, w przypadku, gdy przyczyną incydentu jest Błąd. W ramach Rozwiązania powinno nastąpić także podanie i opisanie przyczyn i skutków wystąpienia Incydentu i udokumentowanie Rozwiązania.

W szczególnych przypadkach, decyzją Zamawiającego Obejście może zostać potraktowane jako Rozwiązanie.

Rozwiązaniem jest również prawidłowa (zgodna ze stanem faktycznym) informacja, że zgłoszony incydent dotyczy obszaru, za który odpowiedzialny jest Inny wykonawca lub Zamawiający.

1. Załącznik 1 do Umowy: Definicje: „Incydent niski", „Incydent średni", „Incydent krytyczny” Zamawiający w Załączniku 1 „Definicje" zawarł definicję pojęć: Incydent niski, Incydent średni, Incydent krytyczny, określając w ten sposób te pojęcia oraz kryteria kwalifikacji Incydentu do danej kategorii. Dla pojęcia „Incydent krytyczny” Zamawiający wskazuje otwarte i nieostre przesłanki uznania poszczególnych Incydentów za krytyczne. Otóż zgodnie z definicją Zamawiającego, Incydentem krytycznym może być incydent występujący na jednym z wielu serwerów, na których świadczona jest dana usługa i który dopiero może - ale wcale nie musi - skutkować poważniejszymi ograniczeniami w realizacji procesów biznesowych w organizacji klienta. Kryterium polegające na tym, że dane zdarzenie na podstawie nieokreślonych przesłanek można uznać za krytyczne, należy ocenić jako przypadek czystej uznaniowości Zamawiającego w kształtowaniu zobowiązań umownych Wykonawcy. Ten sam Incydent, w zależności od uznania Zamawiającego, raz może być Incydentem niskim, a drugi raz może być Incydentem krytycznym. Celem klasyfikacji incydentów na grupy krytyczności jest dostosowanie wymaganego czasu obsługi zgłoszenia do wpływu jaki istniejący incydent wywiera na organizację Zamawiającego i zapewnienie, żeby incydenty o dużym wpływie na system były prawidłowo identyfikowane i obsługiwane możliwie szybko. Dlatego też jako incydenty krytyczne klasyfikowane powinny być te, których wpływ na organizację Zamawiającego jest największy, a kryteria oceny takiego wpływu są obiektywne i jasne dla obu stron. Dodatkowo w przytoczonych powyżej definicjach, w odniesieniu do wszystkich kategorii incydentów, Zamawiający wskazał, że jako incydenty na określonym poziomie będą również klasyfikowane „wszelkie błędy dotyczące bezpieczeństwa Zdefiniowane w ten sposób zobowiązanie obejmuje również błędy bezpieczeństwa pochodzące z oprogramowania czy też ITS, za których naprawę odpowiedzialne są strony trzecie, a co za tym idzie - ich obsługa w reżimie SLA danego typu incydentu nie może być zobowiązaniem Wykonawcy. W/w definicje rażąco naruszają przepis art. 29 ust. 1 ustawy Pzp. Wykonawca po zapoznaniu się z definicjami nie wie, które Incydenty będą Incydentami Krytycznymi, a które Średnimi czy Niskimi. Uniemożliwia to sporządzenie oferty.

Odwołujący wniósł o ograniczenie tego zobowiązania nałożonego na Wykonawcę wyłącznie do Błędów Oprogramowania użytkowego.

Podał, że Definicje krytyczności Incydentów (określające poziom świadczenia usługi serwisowej) są niezbędne do obiektywnej oceny przez Strony krytyczności Zgłoszenia Incydentu i zobowiązań Wykonawcy z tego wynikających. Tymczasem w Załączniku (pkt II ppkt B. tiret 10) Zamawiający określa jedną z zasad obsługi zgłoszeń następująco: „10.

Zamawiający decyduje o poziomie zgłoszeń serwisowych (incydentów)." Zapis taki jest nieprecyzyjny i może sugerować, że to Zamawiający arbitralnie będzie decydował o poziomie obsługi incydentów, gdzie tymczasem jest to uprawnienie Stron, które powinno być realizowane w oparciu o zawarte w Umowie definicje krytyczności incydentów. Prawdą jest, że to obowiązkiem Zamawiającego jest inicjalnie określenie poziomu obsługi incydentu - w oparciu o definicje - natomiast Wykonawca w ramach obsługi incydentu powinien mieć zagwarantowane prawo do weryfikacji klasyfikacji incydentu na podstawie obowiązujących Strony definicji z Umowy. Zaznaczył, że Zamawiający w Umowie w art. 14 określa bardzo wysokie wartości kar z tytułu niedotrzymania parametrów Usług serwisowych dla poszczególnych kategorii incydentów:

1. Opóźnienia w usuwaniu Incydentów krytycznych -10 000,00 PLN (słownie złotych: dziesięć tysięcy złotych 00/100) za każdą rozpoczętą godzinę opóźnienia;
2. Opóźnienia w usuwaniu Incydentów średnich - 5 000,00 PLN (słownie złotych: pięć tysięcy złotych 00/100) za każdy rozpoczęty dzień opóźnienia;
3. Opóźnienia w usuwaniu Incydentów niskich - 2 500,00 PLN (słownie złotych: dwa tysiące pięćset złotych 00/100) za każdy rozpoczęty dzień opóźnienia; Zamawiający ma świadomość istotności zamieszczenia w SIWZ prawidłowych definicji dla poszczególnych Incydentów. Kwestia ta była już przedmiotem sporu pomiędzy Stronami - w ramach odwołania i skargi na niezgodną z prawem czynność sformułowania przez Zakład Ubezpieczeń Społecznych postanowień SIWZ w postępowaniu o udzielenie zamówienia publicznego na „Rozbudowę i wdrożenie nowych funkcjonalności oraz utrzymania i rozwoju systemu Elektronicznej Platformy Danych (EPWD) oraz budowy i utrzymania Centralnego Rejestru Klientów Zakładu". Ostatecznie rację przyznano Odwołującemu - Sąd Okręgowy w

Warszawie w wyroku z dnia 19 grudnia 2016 roku, sygn. akt XXIII Ga 780/16 miedzy innymi nakazał ZUS szczegółowe zdefiniowanie pojęć "incydent niski", "incydent średni11, "incydent krytyczny11. Sąd Okręgowy uznał, że są to pojęcia niezmiernie istotne dla określenia zobowiązań wykonawcy: „Stanowisko Sądu Okręgowego jest tożsame ze stanowiskiem skarżącej spółki. Nie sposób było nie zgodzić się z argumentację Asseco, co do zasady. Muszą być definicje incydentów. Złe doświadczenia Zakładu Ubezpieczeń Społecznych z kwestią reklamacji czy dany incydent można zakwalifikować do danej kategorii nie może stanowić podstawy do podejmowania decyzji o charakterze arbitralnym, tym bardziej gdy zakwalifikowanie danego incydentu wiąże się z nie tylko koniecznością szybszej reakcji Wykonawcy, ale także jego odpowiedzialnością z tytułu kar umownych, w przypadku incydentów krytycznych bardzo dotkliwych sięgających 20% wynagrodzenia za Modyfikację.

Sąd Okręgowy dał jednak Zamawiającemu możliwość ułożenia definicji, nie znajdując uzasadnionych podstaw, aby narzucać mu treść wskazaną przez skarżącą Asseco, czyli potencjalnego Wykonawcę. Gdyby okazało się, że definicje te będą wadliwe, zawsze służą oferentom środki ochrony prawnej przewidziane w Pzp. Brak określenia incydentów (zdaniem wykonawcy)skutkował naruszeniem przez Zamawiającego art 29 ust. 1 Pzp."

Odwołujący wniósł o wprowadzenie:

1. prawidłowych definicji Incydentu niskiego. Incydentu średniego i Incydentu krytycznego o treści:

„Incydent niski: Incydent, nie będący Incydentem krytycznym i średnim, powodujący, że część Systemu funkcjonuje niezgodne z Dokumentacją Zamawiającego, Dokumentacją Wykonawcy, Wymaganiami lub Wymaganiami dla Oprogramowania użytkowego, skutkiem czego zostały ujawnione błędy, które: - skutkują nieergonomiczną pracą, - są utrudnieniem w realizacji niekluczowych funkcjonalności, - wystąpiły lub występują incydentalnie oraz dotyczą jedynie wąskiego grona odbiorców usług, - dotyczą konfiguracji środowisk testowych.

Za incydent niski rozumie się także wadę Dokumentacji Zamawiającego lub Dokumentacji Wykonawcy.

Jako incydenty niskie rozumiane są również wszelkie Błędy Oprogramowania użytkowego dotyczące bezpieczeństwa powodujące zagrożenie niskie, które występuje wtedy, gdy zidentyfikowany problem nie stanowi bezpośredniego zagrożenia dla bezpieczeństwa składowanych i przetwarzanych informacji.

Może natomiast przekształcić się w problem poważniejszy, jeśli wystąpią dodatkowe okoliczności”.

Incydent średni: Incydent, który powoduje, że część Systemu funkcjonuje niezgodne z Dokumentacją Zamawiającego, Dokumentacją Wykonawcy, Wymaganiami lub Wymaganiami dla Oprogramowania użytkowego.

Incydent ten może powodować lub powoduje: - utrudnienie realizacji procesów biznesowych, - zmniejszenie wydajności systemu, - błędne przetwarzanie danych, - generowanie zwiększonego zapotrzebowania na zasoby.

Jako incydenty średnie rozumiane są również wszelkie Błędy Oprogramowania użytkowego dotyczące bezpieczeństwa powodujące zagrożenie średnie, które występuje wtedy, gdy zidentyfikowany problem, którego ono dotyczy jest w stanie bezpośrednio zagrozić bezpieczeństwu informacji lub może pomóc w przeprowadzeniu bardziej skomplikowanych ataków. Jednak atak nie jest tak prosty do wykonania jak w przypadku incydentu krytycznego, bądź skutki nie są tak rozległe”.

Incydent krytyczny: Incydent stanowiący zdarzenie globalne, o masowym charakterze dla całego PUE, uniemożliwiające lub istotnie utrudniające świadczenie usług przez organizację IT Zamawiającego na poziomie określonym w metrykach. Skutkuje zatrzymaniem bądź poważnym globalnym ograniczeniem realizacji procesów biznesowych, uszkodzeniem danych lub utratą ich spójności. Jako incydenty krytyczne rozumiane są również błędy Oprogramowania użytkowego dotyczące bezpieczeństwa powodujące zagrożenie krytyczne, które występuje wtedy, gdy zidentyfikowany problem jest w stanie bezpośrednio zagrozić poufności, integralności lub dostępności informacji bądź systemom ich przetwarzania. Potencjalnie atak możliwy jest do przeprowadzenia przez znaczną liczbę użytkowników, np. możliwy do wykonania z Internetu, publicznie dostępny kod exploita, itp. ”.

1. Zastąpienie zapisu z Załącznika 9 fpkt II ppkt B. tiret 10) o treści:

„10. Zamawiający decyduje o poziomie zgłoszeń serwisowych (incydentów)."

Zapisem:

„10. Przekazując Zgłoszenie Zamawiający określa wstępnie poziom zgłoszenia serwisowego (incydentu), a w ramach realizacji procesu obsługi Wykonawca weryfikuje poziom zgłoszenia i w przypadku rozbieżności w stosunku do poziomu określonego przez Zamawiającego, Strony uzgadniają właściwy poziom w oparciu o definicje z Umowy."

1. Dodanie do algorytmu obsługi usługi SYS USM ODI oraz usługi SYS USM WD dodatkowego kroku:

Weryfikacja klasyfikacji i kategoryzacji.

Realizuje w uzgodnieniu z Zamawiającym a CS Wykonawcy

Przeprowadzenie weryfikacji klasyfikacji i kategoryzacji Zgłoszenia. Uzgodnienie z Przekazanie informacji o zmianie kategoryzacji lub Zamawiającym ewentualnej zmiany klasyfikacji Zgłoszenia. klasyfikacji lub kategoryzacji.

1. Załącznik nr 4 do Umowy, pkt. ll, ppkt 8, procedura nr 4- Brak wynagrodzenia za nowy zakres prac zlecany zgodnie z procedurą „Powołanie nowej lub zmiana Metryki usługi aplikacyjnej / usługi serwisowej".

W załączniku nr 4 do Umowy w pkt II ppkt 8 Zamawiający zawarł Procedury utrzymania systemu. Zgodnie z procedurą nr 4 Powołanie nowej lub zmiana metryki usługi aplikacyjnej i usługi serwisowej, Zamawiający przewidział możliwość powołania nowej lub zmiany istniejącej usługi opisanej Metryką. W punkcie 5 procedury zostały przewidziane uzgodnienia zakresu nowej/zmienionej usługi opisanej Metryką oraz warunków jej świadczenia:

Realizujący Krok Czynność

Wynik

Uwagi

czynność Uzgodnienie Zamawiający/ 5

zakresu Wykonawca Metryki

Uzgodnione warunki nowej/ zmienionej usługi

Uzgodnień dokonują osoby wskazane przez Dyrektorów Umowy Zamawiającego i Wykonawcy.

Strony uzgadniają m.in. zakres, datę rozpoczęcia świadczenia usługi opisanej Metryką.

Z procedury tej nie wynika, w jaki sposób Zamawiający zamierza uzgodnić wysokość wynagrodzenia za nową lub zmienioną usługę. Co więcej, zgodnie z zasadami obliczania wynagrodzenia dotyczącego Usług utrzymania, zawartymi w Umowie, Zamawiający w ogóle nie przewiduje dodatkowego wynagrodzenia za nowy zakres prac zlecany zgodnie z procedurą 4. Zgodnie z Art. 12 ust. 1 pkt 2 Umowy, wynagrodzenie Wykonawcy z tytułu „Usług utrzymania ustalane jest w oparciu o zasady określone w Załączniku 5, na podstawie liczby Punktów Funkcyjnych, wyrażającej złożoność Systemu oraz ceny Punktu Funkcyjnego;".

W załączniku 5 do Umowy zasady obliczania wynagrodzenia za Usługi utrzymania zostały opisane w następujący sposób:

„1. Wynagrodzenie z tytułu Usług utrzymania Systemu ustala się w oparciu o rozliczeniowa złożoność Systemu wyrażona w Punktach Funkcyjnych. Na złożoność Systemu składają się zmiany funkcjonalne.

1. Wynagrodzenie roczne z tytułu świadczenia Usług utrzymania Systemu, określa się jako iloczyn współczynnika rocznego wynagrodzenia oraz wartości rozliczeniowej złożoności Systemu." oraz „5. Na potrzeby inicjalnego określenia wartości wynagrodzenia z tytułu Usług utrzymania Systemu przyjmuje się złożoność Systemu (jako rozliczeniową złożoność Systemu) według stanu na dzień zawarcia Umowy na poziomie ............/złożoność Systemu zostanie uzupełniona wg stanu na dzień zawarcia Umowy przy czym nie będzie ona mniejsza niż 12 399,8 CFP/Punktów Funkcyjnych oraz współczynnika rocznego wynagrodzenia na

poziomie 7.20%."

Z powyższych zapisów wynika, że wartość Usług utrzymania zależy od złożoności Systemu wyrażonego w Punktach Funkcyjnych oraz od współczynnika rocznego wynagrodzenia.

Złożoność Systemu zmienia się w trakcie trwania umowy i zależy od zrealizowanych Modyfikacji Systemu przeliczonych na liczbę Punktów Funkcyjnych. Natomiast współczynnik rocznego wynagrodzenia został określony przez Zamawiającego na poziomie 7,2 %. Przy czym współczynnik ten został określony dla zakresu obowiązków określonych SIWZ, który jest znany na dzień składania oferty. Jednocześnie w pkt 15 i 16 Załącznika 5 do Umowy, Zamawiający przewidział możliwość zmiany tego współczynnika w następujący sposób:

„15. Zmiana współczynnika rocznego wynagrodzenia następuje na podstawie Zlecenia Modyfikacji, w którym określono poziom wzrostu współczynnika rocznego wynagrodzenia.

1. Zmieniony współczynnik rocznego wynagrodzenia obowiązuje w okresie określonym w Zleceniu Modyfikacji."

Oznacza to, że Zamawiający dopuszcza, że w związku z nowym zakresem Usług utrzymania (nową lub zmienioną Metryką), wynikającym ze zlecanej Modyfikacji, Wykonawca otrzyma zwiększone wynagrodzenie. W analogiczny sposób powinien być określony sposób zwiększenia wynagrodzenia w związku z powołaniem nowej lub ze zmianą Metryki usługi aplikacyjnej i usługi serwisowej, której potrzeba powołania nie wynika wprost ze zlecanej Modyfikacji a z innych potrzeb Zamawiającego. Procedura nr 4 nie opisuje kroku polegającego na zmianie współczynnika rocznego wynagrodzenia, na podstawie którego oblicza się wynagrodzenie Wykonawcy za Usługi utrzymania. Obecne postanowienia SIWZ wskazują, że Zamawiający oczekuje, że w przypadkach wskazanych powyżej część usług byłaby świadczona przez Wykonawcę przy niezmienionym wynagrodzeniu z tytułu utrzymania, czyli nieodpłatnie, co rażąco narusza Prawo zamówień publicznych. Przepis art. 2 pkt 13 Ustawy PZP wyraźnie stanowi, iż zamówienie publiczne może obejmować tylko usługi odpłatne.

Tymczasem Zamawiający przewidział możliwość zwiększenia zakresu obowiązków wykonawcy (np. zmiana parametrów SLA), nie zwiększając wynagrodzenia z tytułu świadczenia usług.

Odwołujący wniósł o dodanie do procedury nr 4 Powołanie nowej lub zmiana metryki usługi aplikacyjnej i usługi serwisowej, znajdującej się na str. 30-32 Załącznika 4 do Umowy, dodatkowego kroku:

Realizujący Krok

Czynność

Wynik

Uwagi

czynność Uzgodniona nowa Uzgodnienie wartość

Uzgodnień dokonują osoby wskazane przez Dyrektorów Umowy Zamawiającego i

współczynnika

Wykonawcy.

rocznego

Strony uzgadniają nową wartość współczynnika rocznego wynagrodzenia, która uwzględni zmianę zakresu Usług utrzymania

współczynnika Zamawiający/ 5a rocznego

Wykonawca

wynagrodzenia wynagrodzenia

1. Załącznik 5 do Umowy „Zasady ustalani a wynagrodzenia z tytułu Usług utrzymania" - brak jednoznacznego określenia złożoności Systemu W art. 2 ust. 2 Umowy Zamawiający określił, że System składa się z oprogramowania i dokumentacji nabytych, wytworzonych lub zmodyfikowanych na podstawie wymienionych 13 umów-w tym umów, których realizacja trwa, a System jest wciąż rozwijany na ich podstawie.

Rozwój Systemu powoduje, że zwiększa się złożoność Systemu, mierzona w Punktach Funkcyjnych. Na podstawie obecnie obowiązujących umów wykonywane są Modyfikacje Systemu, które znacznie zwiększają jego funkcjonalność. Złożoność Systemu wpływa wprost na koszty świadczenia usług utrzymania systemu. Im większy jest System, tym przeciętnie więcej roboczogodzin poświęca się na usuwanie zaistniałych Błędów i Incydentów. Jest to okoliczność bezsporna - sam Zamawiający określił wysokość wynagrodzenia jako pochodną złożoności Systemu, wskazują w pkt 1 Załącznika 5:

„1. Wynagrodzenie z tytułu Usług utrzymania Systemu ustala się w oparciu o rozliczeniową złożoność Systemu wyrażoną w Punktach Funkcyjnych."

Zatem wykonawca musi na etapie przygotowania oferty znać złożoność Systemu - a to w celu określenia pracochłonności wykonania usługi, a następnie przełożenia tej pracochłonności na cenę za ten element przedmiotu zamówienia. Brak takiego określenia stanowiłby naruszenie art. 29 ust. 1 Pzp. Wydawać by się mogło, że skoro sam Zamawiający określa wysokość wynagrodzenia za usługi Utrzymania jako pochodną złożoności, to zdaje sobie sprawę, jak ważne jest określenie tej złożoności w SIWZ. Tymczasem Zamawiający w praktyce zachował się dokładnie odwrotnie - otóż świadomie i celowo nie określił wielkości złożoności w SIWZ, wskazując, że wielkość ta zostanie wpisana do Umowy dopiero w dniu zawarcia Umowy:

„5. Na potrzeby inicjalnego określenia wartości wynagrodzenia z tytułu Usług utrzymania Systemu przyjmuje się złożoność Systemu (jako rozliczeniową złożoność Systemu) według stanu na dzień zawarcia Umowy na poziomie ./złożoność Systemu zostanie uzupełniona wg stanu na dzień zawarcia Umowy przy czym nie będzie ona mniejsza niż 12 399,8 CFP/ Punktów Funkcyjnych oraz współczynnika rocznego wynagrodzenia na poziomie 7,20%" Powyższe postanowienie wskazuje jedynie na wartość 12.399,8 Punktów Funkcyjnych, przy czym nie wiadomo, czy to jest złożoność Systemu na dzień publikacji SIWZ, czy też np. przewidywana przez Zamawiającego na dzień zawarcia Umowy. W celu wypełnienia obowiązku określonego w art. 29 ust. 1 Ustawy PZP Zamawiający powinien podać w SIWZ wszystkie informacje, jakie posiada, a które mają wpływ na przygotowanie oferty. Z całą pewnością taką informacją jest złożoność na dzień publikacji SIWZ - gdyż jest to obiektywna wartość, znana Zamawiającemu, a która wpływa na treść oferty. Stopień złożoności Systemu wpływa bowiem na pracochłonność Usług utrzymania, zaś wysokość wynagrodzenia za Usługi utrzymania jest określona w SIWZ, jako pochodna tej właśnie złożoności. Zatem wykonawca musi znać złożoność Systemu na dzień złożenia oferty, tylko wtedy jest bowiem w stanie tak określić cenę oferty (cenę Punktu Funkcyjnego), aby obejmowała ona rzeczywiste koszty świadczenia Usług utrzymania.

Wykonawca wniósł o nakazanie dokonania następujących zmian w SIWZ:

1. wykreślenie w Załączniku nr 5 dotychczasowej treści pkt 5 i w to miejsce wpisanie:

„5. Złożoność Systemu na dzień publikacji SIWZ wynosi 12 399,8 CFP/ Punktów Funkcyjnych.

Na potrzeby inicjalnego określenia wartości wynagrodzenia z tytułu Usług utrzymania Systemu przyjmuje się złożoność Systemu (jako rozliczeniowa złożoność Systemu) według stanu na dzień zawarcia Umowy na poziomie - wartość ta została ustalona przez Zamawiającego zgodnie z zasadami określonymi w pkt 17 -19. stosowanymi odpowiednio."

1. Dodania zobowiązania Zamawiającego do aktualizowania wartości wskazanej w Załączniku 5 pkt 5 w okresie od dnia publikacji SIWZ do dnia złożenia ofert - w przypadku, gdyby złożoność Systemu uległa zmianie.
2. Załącznik 9 do Umowy rozdział III pkt C ppkt 1 i ppkt 3 - Nieprawidłowo zdefiniowany proces obsługi Zgłoszeń W Załączniku 9 do Wzoru Umowy Zamawiający określił zasadę liczenia czasu obsługi zgłoszenia dla Usługi serwisowej Obsługa i Diagnozowanie Incydentów oraz dla Usługi serwisowej Obsługa Incydentów w zakresie Wirtualnego Doradcy oraz platformy Jboss następująco:

Etap obsługi Lp.

Działania Zgłoszenia

Komunikacja z Zamawiającym

Skierowanie do Zamawiającego: - prośby o przekazanie dodatkowych informacji bądź wykonanie dodatkowych czynności niezbędnych do Przekazanie zapytania przekazanie zdiagnozowania i rozwiązania Incydentu, które posiada /komunikatu do CZ lub może wykonać Zamawiający korzystając z Zamawiającego - komunikat P dodatkowych posiadanych uprawnień; przedmiotem prośby nie mogą CZAS OBSŁUGI - STOP ~ tylko w być dane lub czynności, które Wykonawca może posiąść C* lub wykonać samodzielnie, korzystając z posiadanych przypadku pierwszej prośby i informacji. uprawnień; tylko dla poziomów świadczenia Usługi serwisowej Realizuje CS - zgłoszenia przez Wykonawcę Zapotrzebowania na innych niż Incydent krytyczny. przeprowadzenie Konsultacji utrzymaniowej z innym Wykonawcy wykonawcą, współpracującym z Zamawiającym na podstawie umowy.

Prośba o

Jednocześnie dla wspomnianych Usług serwisowych zakres danych wymaganych do zarejestrowania zgłoszenia określony został jako:

„1. identyfikator niniejszej Usługi serwisowej,

1. Identyfikator Usługi, której dotyczy Zgłoszenie,
2. Poziom świadczenia Usługi serwisowej,
3. Dane jednoznacznie określające upoważnionego członka Personelu zgłaszającego (...),
4. Dane jednoznacznie określające pracownika, u którego zidentyfikowano Incydent (...),
5. Posiadane przez Zamawiającego informacje dotyczące Zgłoszenia."

Odwołujący wskazał, że na rynku usług IT stosowane są dwa alternatywne modele przekazywania Wykonawcy danych niezbędnych do obsługi incydentów: • w pierwszym z nich, zgłoszenie incydentu rejestrowane przez Zamawiającego nie musi zawierać kompletu danych niezbędnych do jego rozwiązania - wystarczające są symptomy zaobserwowane przez zgłaszającego. W toku obsługi zgłoszenia wykonawca, zadając kolejne pytania i wnioskując o dodatkowe dane niezbędne do ustalenia przyczyn incydentu, dokonuje diagnozy i przygotowuje rozwiązanie; • alternatywnie, zgłoszenie incydentu rejestrowane przez Zamawiającego powinno spełniać precyzyjne kryteria kompletności zapewniające, że zostały dostarczone wszelkie dane niezbędne do diagnozy i rozwiązania zgłoszenia (np. dane od użytkowników, logi aplikacyjne, logi systemowe itp.). Dopiero tak przygotowane zgłoszenie spełnia kryteria przyjęcia do obsługi przez wykonawcę. W tej sytuacji część procesu diagnostycznego obejmującą konieczność ustalenia zakresu niezbędnych do dalszej obsługi danych obciąża de facto Zamawiającego.

Dotychczasowe umowy na utrzymanie systemu PUE czy też KS1 ZUS stosowały pierwszy model obsługi. Zgłoszenia takie, co do zasady nie zawierają kompletnych danych niezbędnych do ich obsługi - zgłaszający najczęściej opisuje jedynie bezpośrednio zaobserwowane symptomy nieprawidłowego działania systemu. Zgłoszenia są przyjmowane do obsługi przez wykonawcę niezależnie od jakości i kompletności opisu, a w toku ich obsługi przyczyna błędu ustalana jest poprzez pozyskiwanie niezbędnych danych i informacji w realizowanym przez wykonawcę procesie diagnostycznym. Proces ten jest sterowany przez wykonawcę, przy czym ciężar decyzji o kierunkach procesu diagnostycznego leży po stronie wykonawcy, a czas pozyskiwania niezbędnych danych - będący poza kontrolą wykonawcy - nie wlicza się do czasu obsługi zgłoszenia. Tym samym w dotychczasowych umowach czas obsługi zgłoszenia obejmuje tylko i wyłącznie działania wykonawcy, za które może ponosić on pełną odpowiedzialność. W przedmiotowym postępowaniu Zamawiający zastosował wybiórczo elementy obu modeli stosowanych na rynku, tworząc nowy model skrajnie niekorzystny dla wykonawcy - przenoszący na niego odpowiedzialność za jakość działań Zamawiającego lub jego zaniechania. • Z jednej strony, Zamawiający ogranicza wykonawcy możliwość wstrzymania czasu obsługi zgłoszenia na okres pozyskania niezbędnych danych od zgłaszającego wyłącznie dla jednego zapytania i dodatkowo w ograniczeniu do incydentów niskich i średnich. Oznacza to, że w przypadku incydentów na poziomie krytycznym, oczekiwanie na dodatkowe informacje będące w posiadaniu lub wymagające podjęcia działania przez Zamawiającego, wlicza się do czasu obsługi zgłoszenia gwarantowanego przez wykonawcę. Analogicznie w przypadku kolejnych zapytań dla incydentów na poziomie niskim i średnim. Tym samym czas, na podstawie którego wykonawca rozliczany jest ze świadczenia Usług serwisowych

i który - w przypadku przekroczenia - skutkuje dotkliwymi sankcjami dla wykonawcy (przykładowo dla Incydentu krytycznego jest to 10 000 zł kary za każda rozpoczęta godzinę opóźnienia w usuwaniu incydentu) zależy nie tylko od działań wykonawcy, ale również od działań lub zaniechań Zamawiającego (w tym od działań lub zaniechań celowych). • z drugiej strony zakres informacyjny zgłoszenia zawiera jedynie ogólnikowe stwierdzenie stanowiące, że Zamawiający dostarczy „posiadane przez Zamawiającego informacje dotyczące zgłoszenia”. W tak ogólnym stwierdzeniu nie sposób doszukać się jednoznacznych kryteriów precyzyjnie definiujących wymagany rodzaj i zakres przekazywanych informacji. Nie stanowi ono również wymagania dostarczenia danych, które umożliwiają całkowitą i kompletną diagnozę oraz dostarczenie rozwiązania dla zgłoszonego incydentu. Co prawda Zamawiający załącza sformalizowany Formularz Zgłoszenia, ale jest to działanie pozorne, ponieważ zakres informacyjny wymagany na formularzu w żaden sposób nie zapewnia kompletności danych diagnostycznych formularz ten skupia się na danych teleadresowych i tym podobnych, a istotna jego część, tj. podanie informacji dotyczących zgłaszanego incydentu, jest ogólnikowa, bez obowiązku podania szczegółów.

Zastosowanie przez Zamawiającego tylko korzystnych dla siebie mechanizmów z dwóch modeli obsługi zgłoszeń prowadzi do rażącej dysproporcji zobowiązań Stron. Zamawiający nie jest bowiem zobowiązany do podania kompletnych danych w zgłoszeniu incydentu, a wykonawca - zmuszony w takiej sytuacji do pozyskiwania od Zamawiającego danych niezbędnych do obsługi zgłoszenia - będzie karany za niedochowanie terminu usunięcia incydentu. Taki model pozwala Zamawiającemu najpierw zarejestrować zgłoszenie jako krytyczne (do którego naprawy wykonawca jest zobowiązany w czasie zaledwie 4 godzin zegarowych) przy jednoczesnym podaniu minimalnych i niewystarczających do naprawy informacji, a następnie obciążyć wykonawcę sankcją z tytułu niedotrzymania SLA - przy czym rzeczywistą podstawą faktyczną braku terminowej obsługi będą zaniechania po stronie personelu Zamawiającego. Podkreślić tu dodatkowo należy, że Zamawiający określa w Umowie bardzo restrykcyjnie SLA na obsługę incydentu {Incydent krytyczny nie więcej niż 4 godziny zegarowe, Incydent średni nie więcej niż 1,5 dni kalendarzowych, Incydent niski nie więcej niż 5 dni kalendarzowych) oraz bardzo wysokie kary za przekroczenie czasu obsługi incydentu (Incydent krytyczny -10 000 zł za każdą rozpoczętą godzinę zegarową opóźnienia, Incydent średni - 5 000 zł za każdy rozpoczęty dzień kalendarzowy opóźnienia, Incydent niski - 2 500 zł za każdy rozpoczęty dzień kalendarzowy opóźnienia). Obecna konstrukcja odpowiedzialności wykonawcy w przypadku Zgłoszenia, które nie spełnia minimalnych nawet wymagań co do opisu Incydentu stoi w sprzeczności z zasadami odpowiedzialności kontraktowej zgodnie z prawem cywilnym. Narusza to przepis art. 471 Kodeksu Cywilnego i przekracza zasadę swobody umów określoną w art. 353(1) KC. Wskazał, że obecne brzmienie SIWZ w przedmiotowym zakresie jest także niezgodne z określonym w art. 29 ust. 1 Ustawy PZP obowiązkiem opisania przedmiotu zamówienia za pomocą dostatecznie dokładnych i zrozumiałych określeń, uwzględniających wszystkie wymagania mogące mieć wpływ na sporządzenie oferty, wykonawca nie może obecnie przewidzieć, ile zajmie mu usuwanie danego Incydentu, gdyż nie wie, jaki zakres informacji będzie otrzymywał od Zamawiającego i czy w trakcie jego obsługi uda mu się pozyskać dane niezbędne do dostarczenia rozwiązania incydentu.

Odwołujący wniósł o modyfikację zapisów Załącznika 9:

1. zastosowanie do rozwiązywania incydentów na wszystkich poziomach obsługi zgłoszeń mechanizmu stosowanego dotychczas, tj. pozwalającego na zatrzymanie czasu obsługi zgłoszenia na czas pozyskiwania danych niezbędnych do diagnostyki i naprawy w takim zakresie, w jakim nie jest to zależne od działań wykonawcy, poprzez zastąpienie zapisu kroku C* z pkt 2) metryki usługi SYS USM ODI oraz metryki usługi SYS USM WD zapisem o treści:

Etap obsługi Lp.

Działania Zgłoszenia

Komunikacja z Zamawiającym

Skierowanie do Zamawiającego: - prośby o przekazanie dodatkowych informacji bądź wykonanie dodatkowych czynności niezbędnych do zdiagnozowania i rozwiązania Incydentu, które posiada lub może wykonać Zamawiający korzystając z posiadanych uprawnień; Prośba o - zgłoszenia przez Wykonawcę Zapotrzebowania na przeprowadzenie Konsultacji utrzymaniowej z Innym wykonawcą, Przekazanie zapytania /komunikatu do CZ współpracującym z Zamawiającym na podstawie umowy.

Zamawiającego dodatkowych komunikat P C* W przypadku, kiedy Wykonawca bezpośrednio, we własnym informacji. zakresie, pozyskuje niezbędne do obsługi Incydentu informacje, poinformowanie CZ Zamawiającego o rozpoczęciu czynności, o CZAS OBSŁUGI - STOP Realizuje CS tym jakie informacje są pozyskiwane wraz z uzasadnieniem zawieszenia czasu obsługi Zgłoszenia oraz o przewidywanym Wykonawcy terminie ich pozyskania. Zamawiający może zakwestionować (Komunikat A) zasadność zakres i przewidywany termin pozyskania danych uruchamiając ponownie czas obsługi zgłoszenia. W przypadku zasadnego zakwestionowania przez Zamawiającego (tj. potwierdzonego przez Wykonawcę łub uzgodnionego przez Strony) zakresu lub terminu pozyskania danych, czas niezasadnego zawieszenia zostanie wliczony do czasu obsługi Zgłoszenia. przekazanie

albo:

1. wprowadzenie minimalnej obowiązkowej treści zgłoszenia, jako warunku koniecznego do przyjęcia zgłoszenia do obsługi przez Wykonawcę. Zgłoszenie takie powinno obejmować szczegółowy opis zdarzenia wraz z kompletem danych, w szczególności: dane od użytkownika, zrzuty ekranów, logi aplikacyjne, logi systemowe, wyciągi z zawartości bazy danych dotyczące przedmiotu zgłoszenia, a także sposób odtworzenia sytuacji błędnej będącej przedmiotem zgłoszenia. Są to dane niezbędne do kompletnej diagnozy oraz dostarczenia rozwiązania przez wykonawcę;
2. wprowadzenie do algorytmu obsługi incydentów postanowień o braku skuteczności zgłoszenia w przypadku, gdy nie spełnia ono określonych powyżej warunków dot. koniecznego zakresu informacji w zgłoszeniu do opracowania dla niego rozwiązania;
3. wprowadzenie do algorytmu obsługi incydentów postanowień o braku skuteczności zgłoszenia w przypadku, gdy Zamawiający nie odpowiedział merytorycznie lub nie wykonał dodatkowych czynności w reakcji na przekazana przez wykonawcę prośbę o przekazanie dodatkowych informacji bądź o wykonanie dodatkowych czynności niezbędnych do zdiagnozowania i rozwiązania Incydentu.
4. Załącznik 9 rozdział III pkt C ppkt 1/ppkt 3 - Dostarczanie Rozwiązań Incydentów dla Oprogramowania standardowego Zamawiający, między innymi zapisami w Załączniku 9, zobowiązuje Wykonawcę do dostarczania Rozwiązań Incydentów w ramach usługi serwisowej SYSJJSM_ODl i SYS_USM_WD dla Oprogramowania standardowego, w skład którego wchodzi 7 produktów open source: Nginx, Apache SOLR w Liferay, Apache http server, HAproxy, Apache Tomcat, Squid Proxy, ClamAV oraz 2 produkty komercyjne, JBoss Enterprise Aplication Platform oraz Silnik wirtualnego doradcy - Stanusch Technologies. W zakresie Oprogramowania standardowego - zarówno oprogramowania komercyjnego, jak i oprogramowania open source - wymaganie poprawy Błędów przez wykonawcę na zasadach określonych w Umowie jest niemożliwe. W pierwszej kolejności wskazać należy, że co do zasady wykonawca nie może dostarczać Rozwiązań dla Incydentów oprogramowania, do którego nie posiada odpowiednich praw własności intelektualnej. Aby takie prawa własności intelektualnej posiadać, wykonawca musiałby albo być autorem danego Oprogramowania standardowego, albo też musiałby posiadać odpowiednie licencje, pozwalające nie tylko na użytkowanie, ale również na dokonywanie zmian w Oprogramowaniu standardowym. Zgodnie z SIWZ usuwanie Błędów w pozostałym oprogramowaniu tj. w Oprogramowaniu użytkowym oraz Oprogramowaniu dedykowanym odbywa się właśnie na podstawie powyżej wskazanych praw - wykonawca albo jest twórcą oprogramowania (Oprogramowanie dedykowane), albo uzyskuje na podstawie postanowień Umowy odpowiednie uprawnienie od Zamawiającego, który do oprogramowania posiada majątkowe prawa autorskie (Oprogramowanie użytkowe). Sytuacja taka nie zachodzi

w stosunku do Oprogramowania standardowego. Jest to oprogramowanie wytworzone przez osoby trzecie i Zamawiający nie posiada do niego majątkowych praw autorskich, a jedynie licencje pozwalające na korzystanie z takiego oprogramowania. Sam Zamawiający nie posiada licencji, które uprawniałyby go do dokonywania zmian w Oprogramowaniu standardowym. Co więcej - nie jest w ogóle możliwe nabycie licencji, które pozwalałyby mu dokonywać zmian w kodzie komercyjnego Oprogramowania standardowego - takie licencje w ogóle nie są oferowane na rynku. A tylko takie szerokie uprawnienia licencyjne upoważniałyby wykonawcę do usuwania Błędów w komercyjnym Oprogramowaniu standardowym. Tym samym Zamawiający zawarł w S1WZ obowiązki wykonawcy, które nie są możliwe do zrealizowania. Kolejną kwestią jest brak możliwości gwarantowania przez wykonawcę określonych w Umowie terminów dostarczania Rozwiązań Incydentów dla oprogramowania open source oraz komercyjnego Oprogramowania standardowego. W zakresie komercyjnego Oprogramowania standardowego wykonawca, który nie jest autorem oprogramowania i nie posiada jego kodów źródłowych, nie jest w stanie usunąć Błędu, gdyż nie posiada odpowiednich uprawnień i nie może takich uprawnień nabyć. Możliwe jest jedynie wykupienie odpowiednich usług serwisowych dla komercyjnego Oprogramowania standardowego i usuwanie Błędów w ramach takich usług przez producenta komercyjnego Oprogramowania standardowego. W zależności od producenta Oprogramowania standardowego, Błąd usuwany jest albo w kolejnej wersji oprogramowania (na termin pojawienia się której wykonawca nie ma wpływu), albo w terminie od kilku do kilkunastu dni roboczych. Przy czym wykonawca w ogóle nie ma wpływu na termin usunięcia Błędu, wynika on zawsze ze standardowych warunków umowy serwisowej, oferowanej przez danego producenta. Zdaniem Odwołującego, żaden z producentów Oprogramowania standardowego objętego naprawą Błędów w Umowie nie oferuje w ramach możliwych do wykupienia usług serwisowych naprawy Błędów na warunkach określonych w SIWZ. Z powyższego wynika, że wymagania Zamawiającego odnośnie usuwania Błędów w komercyjnym Oprogramowaniu standardowym spełnić może tylko producent oprogramowania lub podmiot, który uzyska dedykowaną licencję, nie będącą w powszechnym obrocie gospodarczym. Powoduje to, że SIWZ w sposób nieuzasadniony preferuje producentów komercyjnego Oprogramowania standardowego- co narusza art. 7 ust. 1 i art. 29 ust. 2 Ustawy Pzp. W zakresie Oprogramowania standardowego opartego o model open source (czyli niekomercyjnego), oprogramowanie takie jest rozwijane zazwyczaj przez społeczności (communities). Przykładowo Oprogramowanie standardowe „Apache Tomcat", objęte przedmiotem umowy w zakresie usuwania Błędów, jest rozwijane przez kilkusetosobową społeczność i obejmuje 500.000 linii kodu źródłowego, co jest odpowiednikiem 20.000 stron A4. W przypadku produktów rozwijanych przez społeczności lub za ich pomocą nie istnieją co prawda bariery prawne dla modyfikacji kodu źródłowego, natomiast występują ograniczenia związane z czasem naprawy błędu. Czasy wydań nowych wersji zależą bowiem od aktywności społeczności. Samodzielne poszukiwanie błędu i poprawianie produktu poza w/w społecznością jest teoretycznie możliwe, natomiast jest całkowicie nierealne w kontekście określonych w Umowie terminów usuwania Błędów i złożoności tych produktów obejmujących setki tysięcy linii kodu źródłowego. Zaznaczył, że podmioty komercyjne świadczące specjalizowane usługi serwisu Oprogramowania standardowego, w tym przypadku dla oprogramowania „Apache T omcat" wykazane na stronie (...) nie świadczą serwisu naprawy Błędów w określonym w SIWZ reżimie SLA. Swoje zobowiązania podmioty te ograniczają jedynie do podania czasu reakcji, bez gwarancji czasu naprawy. Zgodnie ze standardami obowiązującymi na rynku usług IT, to Zamawiający - jako użytkownik oprogramowania - powinien mieć zawarte odpowiednie umowy serwisowe dla Oprogramowania standardowego, zarówno komercyjnego, jak i open source. Ewentualnie, Zamawiający może wymagać, aby usługi wynikające z takich umów serwisowych zostały mu dostarczone w ramach przedmiotu zamówienia. Zamawiający może jednak wymagać jedynie dostarczenia produktu dostępnego na rynku tj. objęcia ofertą dostarczenia usługi serwisu dla Oprogramowania standardowego i realizowania tej usługi zgodnie z powszechnie obowiązującym warunkami. Dodatkowo, z niewiadomych przyczyn Zamawiający (dla innych Incydentów niż dotyczących Oprogramowania standardowego) znacznie pogorszył, w stosunku do poprzedniego postępowania na rozwój i utrzymanie Portalu Klienta oraz Szyny Usług (ESB) w ramach Platformy Usług Elektronicznych ZUS (Umowa nr 1068462 z dnia 27.11.2018), warunki SLA wstrzymania czasu obsługi zgłoszenia po dostarczonym przez Wykonawcę skutecznym Obejściu Incydentu. Czas ten skrócony został niemal o 70% i zdaniem Odwołującego jest niezasadnie krótki i w części przypadków nie pozwoli na dostarczenie Zamawiającemu Rozwiązania docelowego z dochowaniem wysokich standardów jakości. Podsumowując stwierdził, że Zamawiający zdefiniował przedmiot zamówienia w zakresie zobowiązań wykonawcy do naprawy Błędów Oprogramowania standardowego w sposób, który jest niemożliwy do spełnienia z powodów obiektywnych usługa taka i z takimi parametrami nie występuje na rynku. Powyższe stanowi naruszenie art.

29 ust. 1 i 2 Ustawy PZP w związku z art. 7 ust. 1 Ustawy PZP. SIWZ nie zawiera bowiem wszystkich informacji, które są niezbędne do przygotowania oferty, a jednocześnie w sposób nieuzasadniony uprzywilejowuje producentów Oprogramowania standardowego.

Odwołujący wniósł o modyfikację SIWZ polegająca na dostosowaniu wymagań do realiów

rynkowych: - wprowadzenie zmian w Załączniku 9 do Umowy według propozycji wykonawcy: w metryce usługi SYS USM ODI oraz w metryce usługi SYS USM WD

1. Załącznik 8 do SIWZ „Opis Systemu PUB" - Brak w Umowie postanowień dotyczących Zamawiający w Załączniku 8 do SIWZ „Opis systemu PUE", punkt „Kody źródłowe" wskazał:

„Jednocześnie Zamawiający informuje, że nie wszystkie kody źródłowe Systemu są obecnie dostępne w Repozytorium kodów źródłowych. Liczba plików pakietów WebMethods wymagających uzupełnienia: 2607. Liczba klas JAVA oprogramowania dedykowanego posiadających w RKZ źródła z niezgodnym API: 68 oraz nieposiadających źródeł w RKZ: 204."

Opis wskazuje jedynie liczbę artefaktów, dla których Kody źródłowe są niekompletne, brakuje natomiast odniesienia do całkowitej złożoności Kodów źródłowych - przez co z samej lektury załącznika do SIWZ nie wynika, jak dużej części funkcjonalności systemu dotyczą wskazane braki. Nie wiadomo zatem, czy w Repozytorium brakuje np. 1%, 10% czy 30% Kodów źródłowych całości systemu - co stanowi istotną okoliczność przy przygotowywaniu oferty.

Jednocześnie w SIWZ brak informacji o obszarach funkcjonalności, w których występują wskazane braki. Wpływ takich braków na ewentualną realizację przedmiotu Umowy - a co za tym idzie, na wycenę - jest silnie uzależniony od obszaru Systemu, w którym występują. Brak Kodów źródłowych dla podstawowych, kluczowych funkcjonalności, mogących z większym prawdopodobieństwem podlegać modyfikacjom lub serwisowi, będzie znacznie bardziej dotkliwy niż braki w obszarach rzadko zmiennych, np. takich, które nie były modyfikowane od dłuższego czasu. Powyższe stanowi naruszenie art. 29 ust. 1 Ustawy PZP w związku z art. 7 ust. 1 Ustawy PZP. SIWZ nie zawiera bowiem wszystkich informacji, które są niezbędne do przygotowania oferty. Co istotniejsze, poza przekazaniem w Załączniku 8 do SIWZ niekompletnej informacji o brakach w Kodach Źródłowych, inne postanowienia SIWZ nie definiują żadnych wyjątków w zakresie obowiązków Wykonawcy ani procedur postępowania wobec elementów Systemu, dla których brakuje Kodów źródłowych. Przykładowo, opisane w Załączniku 4. Część 4. Procedura przekazywania i odbioru Kodów źródłowych obowiązki Wykonawcy dotyczące dostarczania Kodów źródłowych w ust. 3.1 wymaga tego, że „(...)

Wykonawca potwierdza i gwarantuje, że przekazane Zamawiającemu Kody źródłowe będą autentyczne, kompletne, spójne i odpowiednie. Taki obowiązek Wykonawcy może być niemożliwy do spełnienia wobec braku Kodów źródłowych dla niektórych części Systemu.

Należy nadmienić, że przekazywanie Zamawiającemu Kodów źródłowych następuje w następstwie jednej z dwóch czynności: • wytworzenia Modyfikacji, podczas którego następuje aktualizacja Kodów źródłowych o zmiany wynikające ze zmian funkcjonalnych i niefunkcjonalnych będących rezultatem realizacji Modyfikacji; • realizacji Usług Serwisu, podczas których następuje aktualizacja Kodów źródłowych w zakresie wprowadzania poprawek niezbędnych do usunięcia Błędów, przy czym dla każdej z nich komplet aktualnych Kodów źródłowych jest warunkiem koniecznym do jej prawidłowej realizacji. Ewentualne napotkane braki kodów źródłowych w obszarach objętych Modyfikacją lub Serwisem uniemożliwiają Wykonawcy dotrzymanie zobowiązań i muszą zostać uzupełnione przed kontynuacją jego prac - co w ogólnym przypadku oznacza konieczność napisania kodu brakującego elementu od nowa. W tej sytuacji przyczyna ewentualnych opóźnień leży poza zakresem odpowiedzialności wykonawcy. Brak kompletu aktualnych kodów źródłowych w obszarach zmienianych w Modyfikacji lub wymagających naprawy w Usługach serwisu skutkowałoby koniecznością ich odtworzenia przez Zamawiającego, gdyż taki obowiązek wykonawcy nie jest objęty przedmiotem zamówienia. Odtworzenie takie co do zasady nie jest czynnością możliwą do realizacji w sposób automatyczny - najczęściej wymaga to odtworzenia szczegółowego projektu danego elementu oprogramowania (np. klasy JAVA, formularza itp.) na podstawie istniejącej dokumentacji, wiedzy o funkcjonalności odtwarzanego elementu w kontekście otoczenia, z którym współpracuje, a w ograniczonym stopniu możliwe jest również wykorzystanie wyników dekompilacji pakietów instalacyjnych. Należy mieć na uwadze, że przekazywane do Zamawiającego Kody źródłowe muszą spełniać wymagania odpowiednich Standardów eksploatacyjnych, a także m.in. wymaganie utrzymywalności, dając możliwość nie tylko doraźnego zbudowania rezultatu prac w Modyfikacji czy naprawy Błędu w ramach obsługi Incydentu. Odtworzony kod musi zatem zachować strukturę, przejrzystość, nazewnictwo zmiennych, komentarze i inne tego typu cechy umożliwiające jego dalszy rozwój i skuteczne serwisowanie w przyszłości. Pakiety instalacyjne zbudowane z odtworzonego kodu muszą z kolei zostać poddane testom potwierdzającym ich zgodność ze stanem funkcjonalności występującym na środowisku produkcyjnym, stanowiącym bazę dla procesu odtworzenia. W przypadku realizacji usług Serwisu, obecne postanowienia SIWZ nie uwzględniają sytuacji, w której serwisowi podlega element Systemu, dla którego brakuje