rodzaj: WYROK
data dokumentu: 2020-07-09
rok: 2020

sygnatury akt.:

KIO 937/20

Komisja w składzie:
Przewodniczący: Agata Mikołajczyk Członkowie: Emilia Garbala, Izabela Niedziałek - Bujak Protokolant: Cegłowski, Piotr

po rozpoznaniu na rozprawie z
udziałem stron w dniu 8 lipca 2020 r. w Warszawie odwołania
wniesionego w dniu 15 kwietnia 2020
r. przez odwołującego Asseco Poland S.A. z Rzeszowa
(ul. Olchowa 14, 35-
322 Rzeszów) w postępowaniu prowadzonym przez zamawiającego:
Zakład Ubezpieczeń Społecznych w Warszawie (ul. Szamocka 3,5, Warszawa 01-748),

- przy udziale wykonawcy: Comarch Polska S.A. z Krakowa
(Al. Jana Pawła Il 39A, 31-864
Kraków) zgłaszającego przystąpienie do postępowania odwoławczego po stronie
zamawiającego,

orzeka:
1. Umarz
a postępowanie odwoławcze w zakresie zarzutów podniesionych: a) w pkt 2 do 10 i
w pkt 12
uzasadnienia odwołania z powodu ich uwzględnienia w tej części przez
zamawiającego oraz wobec niewniesienia sprzeciwu przez uczestnika postępowania
odwoławczego, który przystąpił do postępowania po stronie zamawiającego; b) w pkt 13
uzasadnienia odwołania z uwagi na jego cofnięcie przez odwołującego na posiedzeniu;
2.
W pozostałym zakresie oddala odwołanie;
3.
Kosztami postępowania odwoławczego obciąża odwołującego: Asseco Poland S.A. z
Rzeszowa (ul. Olchowa 14, 35-
322 Rzeszów) i:
3.1.
zalicza w poczet kosztów postępowania odwoławczego kwotę 15.000 zł 00 gr (słownie:
piętnaście tysięcy złotych, zero groszy) uiszczoną przez odwołującego tytułem wpisu od
odwołania;
3.2.
zasądza na rzecz zamawiającego: Zakład Ubezpieczeń Społecznych w Warszawie od
odwołującego: Asseco Poland S.A. z Rzeszowa kwotę 3.600 zł 00 gr (słownie: trzy
tysiące sześćset złotych zero groszy) tytułem wynagrodzenie pełnomocnika.

Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. -
Prawo zamówień publicznych
(Dz. U. z 2019 r., poz. 1843) na niniejszy wyrok -
w terminie 7 dni od dnia jego doręczenia -
przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu
Okręgowego w Warszawie.

……………………………

……………………………

……………………………





Sygn. akt: KIO 937/20
Uzasadnienie
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;
6.
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;
7.
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.
8. 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:
1)
Całkowita cena oferty brutto - 60%
2)
Poziom dostępności usług (SLA) - 30%
3)
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
przedmiotoweg
o 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 Odw
oł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:

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
Zamawiający

Postępowanie

Poza cenowe kryterium oceny ofert

GŁÓWNY URZĄD
GEODEZJI I
KARTOGRAFII

Budowa oraz rozwój e-usług i
narzędzi w ramach projektów
CAPAP, ZSIN Faza 11 i K-GESUT
wraz ze szkoleniami.

Numer sprawy: BO-

ZP.2610.41.2016.IZ.CAPAP. ZSIN

Faza II. K-GESUT

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.

30%-Zasady oceny według kryterium kryteria techniczno-
jakoś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
RODZINY, PRACY 1
POLITYKI
SPOŁECZNEJ

Usługi dotyczące Centralnego
Systemu Informatycznego
Zabezpieczenia Społecznego
(CSIZS).

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.

GŁÓWNY

INSPEKTORAT

TRANSPORTU

DROGOWEGO

Budowa, wdrożenie, utrzymanie i
rozwój Krajowego Rejestru
Elektronicznego Przedsiębiorców
Transportu Drogowego Numer
sprawy: BDG.ZPB.230.13.2016

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.

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.

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 po
dlegać będą obszary kompetencji niezbędne zarówno
do dostosowywa
nia 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. Anali
za 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.
3)
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.

2.
„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 kompon
entó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
k
omercyjnych 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
sta
ndardowe 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
potrz
eby 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 k
od ź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
kre
ują 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
r
ozwoju 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ą:

1. Aplikacje portalowe:
a) P
ortal 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 p
rzeglądarce internetowej.
e) e-
Płatnik,
f) konsola pracownika.
g) konsola administratora.
2. SSOBP (Single Sign-On Bank PUE) -
moduł integracji zewnętrznych systemów bankowych
z PUE:
3. SSOGP (Single Sign-On portal biznes.gov.pl do Portalu PUE) -
moduł integracji
zewnętrznego systemu z PUE z gov.pl:
4.
SAG Środowisko symulacyjne elektronicznych Zaświadczeń Lekarskich (eZLA);
5.
Szyna Usług ESB;
6. 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,
1)
Squid Proxy,
m)
ClamAVt
n)
Silnik wirtualnego doradcy - Stanusch Technologies (obecnie Omni-

Channel Chat Bot),
o)
Openshift Origin,
p)
Keycloak.
2. [bez zmian]
3. Przedmiot Umowy obejmuje:
1. 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 elek
tronicznego 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:
2. przeprowadzenie inst
ruktaży w formie warsztatów, instruktaży i praktyk:
3.
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;
4.
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.
5.
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
W
ykonawcy. 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:

(…)
4)
z wykonania audytu Zamawiający sporządzi protokół, który może zawierać zalecenia
usunięcia niezgodności;
5)
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.
5) 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ą
uzgodnien
ia przez Strony wspólnego stanowiska, zastosowanie ma procedura eskalacji
przewidziana w Załączniku 4".
4.
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 postanowienia
ch 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
O
programowania 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."

5.
Wynagrodzenie z tytułu usług Utrzymania - Wzór umowy, Artykuł 12 „Zasady
ustal
ania 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
106
4535 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 Punk
t 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
wykonan
ia 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
Funk
cyjnego. 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).

6.
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 gwaranto
wanym 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
czt
eroletnim 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).
Wartość parametru

(parametr Dostępności) w
metrykach Usług
aplikacyjnych - zgodnie z
ofertą

Wysokość obniżenia wynagrodzenia w PLN

Parametr:

DST.2

Parametr:

AVN.2; AVN.3; DST.l;
DST.3

Parametr:

AVN.l; AVZ.l; AVE.l

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.
3) Nadanie nowego brzmienia Art.11 ust. 10 Umowy:
„10. W przypadku niedotrzymania przez Wykonawcę Parametrów Usług utrzymania
okr
eślonych w Metrykach, wynagrodzenie Wykonawcy ulega obniżeniu zgodnie z
Załącznikiem 13."

7.
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:

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.

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 wszelk
ich 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 od
powiedzialnoś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.

8.
Załącznik 1 do Umowy: Definicje: „Incydent niski", „Incydent średni",
„Incydent krytyczny”
Zamawia
jący w Załączniku 1 „Definicje" zawarł definicję pojęć: Incydent niski, Incydent średni,
Incy
dent krytyczny, określając w ten sposób te pojęcia oraz kryteria kwalifikacji Incydentu do
danej kategorii. D
la 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;
Za
mawiają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
Ub
ezpieczeń 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
Rejestr
u 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
zobo
wią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
za
kwalifikowanie 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żą
oferento
m ś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”.

Incy
dent ś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. Potencj
alnie 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.”.

2)
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."
3)
Dodanie do algorytmu obsługi usługi SYS USM ODI oraz usługi SYS USM WD
dodatkowego kroku:
Weryfikacja klasyfikacji i

Przeprowadzenie weryfikacji klasyfikacji

Przekazanie informacji o

kategoryzacji.

i kategoryzacji Zgłoszenia. Uzgodnienie z

zmianie kategoryzacji lub

Realizuje w uzgodnieniu z

Zamawiającym ewentualnej zmiany

klasyfikacji Zgłoszenia.

Zamawiającym a CS
Wykonawcy

klasyfikacji lub kategoryzacji.

9.
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:
Krok

Czynność

Realizujący

czynność


Wynik

Uwagi

5

Uzgodnienie

zakresu

Metryki

Zamawiający/

Wykonawca


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.
2.
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.
16. 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:
Krok

Czynność

Realizujący

czynność

Wynik

Uwagi

5 a

Uzgodnienie

współczynnika

rocznego

wynagrodzenia

Zamawiający/

Wykonawca

Uzgodniona nowa

wartość

współczynnika

rocznego

wynagrodzenia

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

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

10.
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 Zamawi
ają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
ok
reś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
cz
ym 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 i
nformacje, 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 inicjalneg
o 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
zg
odnie z zasadami określonymi w pkt 17 -19. stosowanymi odpowiednio."
2)
Dodania zobowiązania Zamawiającego do aktualizowania wartości wskazanej w Załączniku
5 pkt 5 w okresie od dnia publikacj
i SIWZ do dnia złożenia ofert - w przypadku, gdyby
złożoność Systemu uległa zmianie.

11.
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:

Lp.

Etap
obsługi
Zgłoszenia

Działania

Komunikacja z
Zamawiającym

C*

Prośba o

przekazanie

dodatkowych

informacji.

Realizuje CS

Wykonawcy

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ń; przedmiotem prośby nie mogą
być dane lub czynności, które Wykonawca może posiąść
lub wykonać samodzielnie, korzystając z posiadanych
uprawnień;

- zgłoszenia przez Wykonawcę Zapotrzebowania na
przeprowadzenie Konsultacji utrzymaniowej z innym
wykonawcą, współpracującym z Zamawiającym na
podstawie umowy.

Przekazanie zapytania
/komunikatu do CZ
Zamawiającego - komunikat P

CZAS OBSŁUGI - STOP ~ tylko w
przypadku pierwszej prośby i
tylko dla poziomów
świadczenia Usługi serwisowej
innych niż Incydent krytyczny.

Jednocześnie dla wspomnianych Usług serwisowych zakres danych wymaganych do
zarejestrowania zgłoszenia określony został jako:
„1. identyfikator niniejszej Usługi serwisowej,
2.
Identyfikator Usługi, której dotyczy Zgłoszenie,
3.
Poziom świadczenia Usługi serwisowej,
4.
Dane jednoznacznie określające upoważnionego członka Personelu zgłaszającego (...),
5. Dane jednoznacznie
określające pracownika, u którego zidentyfikowano Incydent (...),
6.
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 kryte
ria 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
m
odel 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.
Z
astosowanie 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 zega
rowe, 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:

albo:
3)
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ę;
4)
wprowadzenie do algorytmu obsługi incydentów postanowień o braku skuteczności
z
gł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;
5)
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ł
dod
atkowych 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.

12.
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
Lp.

Etap
obsługi
Zgłoszenia

Działania

Komunikacja z
Zamawiającym

C*

Prośba o

przekazanie

dodatkowych

informacji.

Realizuje CS

Wykonawcy

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ń;

- zgłoszenia przez Wykonawcę Zapotrzebowania na
przeprowadzenie Konsultacji utrzymaniowej z Innym wykonawcą,
współpracującym z Zamawiającym na podstawie umowy.

W przypadku, kiedy Wykonawca bezpośrednio, we własnym
zakresie, pozyskuje niezbędne do obsługi Incydentu informacje,
poinformowanie CZ Zamawiającego o rozpoczęciu czynności, o
tym jakie informacje są pozyskiwane wraz z uzasadnieniem
zawieszenia czasu obsługi Zgłoszenia oraz o przewidywanym
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 zapytania
/komunikatu do CZ
Zamawiającego -
komunikat P

CZAS OBSŁUGI - STOP

dostarczania Rozwiązań Incydentów w ramach usługi serwisowej SYSJJSM_ODl i
SYS_USM_WD dla Oprogramowania standardowe
go, 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
o
dpowiednich 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
stand
ardowego. 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 Tomcat" 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

13.
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
niekomple
tnej 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, kom
pletne, 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 Za
mawiają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 przys
zł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
Kodów źródłowych lub są one niezgodne z oprogramowaniem użytkowym zainstalowanym w
środowisku produkcyjnym - w takiej sytuacji, odtworzenie Kodów źródłowych musiałoby być
realizowane w ramach czasu przeznaczonego na usunięcie Incydentu. Odtworzenie Kodów
źródłowych jest czynnością długotrwałą w stosunku do określonych przez Zamawiającego
czasów obsługi zgłoszeń - nawet dla poziomu Incydentu niskiego konieczność odtwarzania
Kodów źródłowych stanowi istotne ryzyko niedotrzymania terminów SLA, dla wyższych
poziomów przekroczenie takie jest praktycznie pewne, a jednocześnie skutkuje wysoką karą
za opóźnienie naprawy (przykładowo dla Incydentu krytycznego czas na naprawę to 4 godziny
w kalendarzu 24/7, a kara za każdą rozpoczętą godzinę opóźnienia naprawy to 10 000 zł).
Tymczasem sam czas odtworzenia kodów źródłowych w zależności od skali braku może zająć
od kilku godzin nawet do kilku dni -
zatem czas dłuższy, niż czas przewidziany przez
Zamawiającego na usunięcie Incydentu. Oznacza to, że ewentualne przekroczenie czasu
obsługi zgłoszenia, za które wykonawca może być obciążony karą umowną lub obniżeniem
wynagrodzenia, będzie wynikać z okoliczności nie wynikających z winy wykonawcy.
Niezgodności Kodów źródłowych mogą również powodować, że oprogramowanie będące
rezultatem Modyfikacji będzie miało - w obszarach niezmienianych Modyfikacją - inną
funkcjonalność niż oczekiwana i zamówiona przez Zamawiającego w poprzednich
Modyfikacjach. Będzie to wynikać z faktu zbudowania Modyfikacji przez wykonawcę w dobrej
wierze w oparciu o Kody źródłowe znajdujące się w Repozytorium Kodów źródłowych, a
niezgodne z zainstalowanymi w środowisku produkcyjnym pakietami instalacyjnymi. Taka
sytuacja wygeneruje Incydenty, które wykonawca będzie zobowiązany obsłużyć-podczas gdy
przyczyna tych Incydentów nie będzie wynikać z winy wykonawcy. W takich przypadkach
również konieczne będzie odtworzenie Kodów źródłowych, mogące spowodować wydłużenie
czasu obsługi zgłoszenia, a w konsekwencji - karę umowną lub obniżenie wynagrodzenia, z
przyczyn nie leżących w zakresie odpowiedzialności wykonawcy. Tym samym Zamawiający
konstruuje odpowiedzialność wykonawcy na zasadzie ryzyka (czy też na zasadach zbliżonych
do zasady ryzyka), zupełnie oderwanej od odpowiedzialności opartej na zasadzie winy.
Narusza to zatem zasady odpowiedzialności kontraktowej określone w art. 471 Kodeksu
Cywilnego oraz zasadę swobody umów określoną w art. 353 (1) KC.

Odwołujący wniósł o następujące zmiany:
1)
Zamieszczenie w załącznikach do 5IWZ szczegółowych informacji o brakach w Kodach
źródłowych, uwzględniających zarówno zakres braków, jak i obszary funkcjonalne, w których

braki występują;
2)
Uwzględnienie w procedurach obsługi Incydentów wstrzymania czasu obsługi zgłoszenia
na czas niezbędny do odtworzenia Kodów źródłowych w przypadku ich braku lub
niezgodności, gdy jest to niezbędne do prawidłowej obsługi zgłoszenia;
3)
Uwzględnienie w procedurach obsługi Incydentów sytuacji, w której Błąd jest skutkiem
zbudowania Oprogramowania dedykowanego w oparciu o Kody źródłowe udostępnione w
Repozytorium, niezgodne z pakietami instalacyjnymi wdrożonymi produkcyjnie.


Do postępowania odwoławczego po stronie Zamawiającego przystąpienie
zgłosił wykonawca Comarch Polska S.A. z Krakowa wnosząc o oddalenie odwołania.
Wskazał, że (…) Przystępujący ma interes w tym, aby odwołanie Odwołującego zostało
rozstrzygnięte poprzez jego oddalenie. W interesie Przystępującego leży uzyskanie
korzystnego rozstrzygnięcia na rzecz Zamawiającego - poprzez oddalenie odwołania.
Uwzględnienie odwołania doprowadziłoby do wprowadzenia nowych postanowień
określonych w żądaniach odwołania, które są nieproporcjonalne do przedmiotu zamówienia,
w sposób niedozwolony faworyzują Odwołującego, przez co utrudniają uczciwą konkurencję”.
Wskazał dalej, że: „Podniesione przez Odwołującego zarzuty w zakresie „Kryteria i zasady
oceny ofert” i sformułowane żądania są nieuzasadnione. Odwołujący dąży jedynie do
ograniczenia konkurencji w przedmiotowym postępowaniu. Określenie zapisów SIWZ leży w
gestii Zamawiającego jako gospodarza postępowania, który jest uprawniony do
samodzielnego określenia wymagań, w tym kryteriów oceny ofert, w sposób odpowiadający
jego potrzebom i zapewniający osiągniecie zamierzonego celu, pod warunkiem dochowania
zasad uczciwej konkurencji i równego traktowania wykonawców – co Zamawiający w
niniejszym postępowaniu, w zakresie zaskarżonych postanowień, uczynił. Przystępujący
zast
rzega sobie prawo wniesienia dodatkowej argumentacji merytorycznej w piśmie
procesowym bądź bezpośrednio na rozprawie”.

Zamawiający w odpowiedzi na odwołanie (pismo z dnia 7/07/2020 r.) wniósł o:
(1)
umorzenie postępowania w zakresie zarzutów (jego zdaniem) cofniętych przez
wykonawcę: to jest zarzutów 2 -10 i 12 oraz (2) oddalenie odwołania w pozostałym zakresie.
W uzasadnieniu stanowiska podał w szczególności, że na skutek modyfikacji postanowień
SIWZ dokonanych 29 maja 2020 r., w tym wzoru Umowy, część postanowień SIWZ będących
podstawą formułowanych przez Odwołującego w odwołaniu zarzutów nr 11 i 13 uległo
częściowej modyfikacji. Podkreślił, że czynność modyfikacji postanowień SIWZ, w tym wzoru
Umowy, jest skuteczna z chwilą przekazania Wykonawcom, wówczas poprzednie
postanowienia tej dokumentacji stają się nieaktualne. Tym samym w chwili rozstrzygania
odwołania przez Krajową Izbę Odwoławczą mamy do czynienia z innym stanem faktycznym

niż w chwili wniesienia odwołania. Oznacza to, że zarzuty oparte na poprzednio
obowiązujących postanowieniach SIWZ, po dokonaniu ich modyfikacji straciły swoją
aktualność, prowadząc do upadku podstawy faktycznej zarzutów i stają się przez to
bezprzedmiotowe. Zgodnie z art. 191 ust. 2 ustawy Pzp wydając wyrok Izba bierze za
po
dstawę stan rzeczy ustalony w toku postępowania. Oznacza to, że w przypadku zarzutów
odnoszących się do częściowo zmodyfikowanych zapisów dokumentacji, o ile pozostają
aktualne mimo zmiany brzmienia tych zapisów i nie zostały przez Odwołującego cofnięte,
p
owinny być rozpatrzone, ale w odniesieniu do stanu ustalonego w toku postępowania, a więc
stanu po dokonaniu modyfikacji.
W szczególności wskazał, że rozstrzyganie co do
nieistniejących już zapisów SIWZ stoi w sprzeczności z przepisem art. 192 ust. 2 ustawy Pzp,
który do uwzględnienia odwołania wymaga stwierdzenia naruszenia przepisów ustawy Pzp,
które miało lub może mieć istotny wpływ na wynik postępowania. Takiego wpływu na pewno
nie miały i nie będą mieć zapisy historycznie, które już w żaden sposób nie wiążą zarówno
Za
mawiającego jak i uczestników postępowania. Odnosząc się co do meritum zarzutów (jego
zdaniem podtrzymanych) wskazał, że „W uzasadnieniu odpowiedzi na odwołanie przyjęto
systematykę zarzutów zastosowaną w odwołaniu. Pojęcia rozpoczynające się wielką literą
zostały użyte zgodnie z ich znaczeniem nadanym we „Wzorze umowy”, stanowiącym załącznik
2 do SIWZ”.
1. Zarzut 1 -
SIWZ, Pkt 7 „Kryteria i zasady oceny ofert”
Odwołujący zarzuca Zamawiającemu, że poziom dostępności usług (SLA) jest kryterium oceny
ofert niezwiązanym z przedmiotem zamówienia oraz jest kryterium pozornym. Zarzut ten jest
zupełnie chybiony, a określone przez Zamawiającego kryterium oceny ofert odnosi się wprost
do istoty Umowy, której zawarcie jest przedmiotem postępowania. Umowa na rozwój i
utrzymanie Portalu Klienta oraz Szyny Usług (ESB) w ramach Platformy Usług Elektronicznych
ZUS obejmuje szereg świadczeń o niejednorodnym charakterze. Umowa obejmuje m.in.
Modyfikacje Systemu, które zakwalifikować można jako dzieło, Usługi dodatkowe, które w
zależności od danego zlecenia mogą stanowić dzieło lub usługi konsultingu, a także usługi
szkoleniowe oraz Usługi utrzymania. Umowa w zakresie Usług utrzymania nie jest
standardową umową o świadczenie usług w rozumieniu art. 750 k.c. W zakresie tych
świadczeń można uznać ją za umowę o świadczenie usług o charakterze zbliżonym do tak
zwanych umów rezultatu, których przedmiotem jest indywidualnie oznaczony wytwór (rezultat).
Na gruncie Umowy, w odniesieniu do Metryk Usług Wykonawcy rezultatem tym jest uzyskanie
przez Wykonawcę określonego w tych metrykach SLA (Service Level Agreement), to jest
osiągnięcie założonych parametrów: dostępności, ciągłości, czasu rozwiązania incydentu itp.
Gwarancja SLA z założenia ma ułatwiać użytkownikowi dochodzenie uprawnień, a
odpowiedzialność wykonawcy nie jest oparta o dochowanie należytej staranności i bardzo
często ma wręcz charakter gwarancyjny. Poprzez zdefiniowanie poziomów usługi określa się

pewien rezultat i wykazanie braku tego rezultatu jest wystarcz
ające do udowodnienia
niewykonania lub nienależytego wykonania zobowiązania, a więc jednej z przesłanek
odpowiedzialności określonych w art. 471 k.c. W przeciwnym razie, konieczne byłoby
udowodnienie nienależytej staranności wykonawcy oraz pozostałych przesłanek
odpowiedzialności wykonawcy, co w praktyce jest niemal niemożliwe. Kwalifikacja prawna
Usług utrzymania objętych Umową przesądza w sposób jednoznaczny ścisły związek
ustalonego przez Zamawiającego kryterium dotyczącego SLA z przedmiotem zamówienia.
Również nietrafiony jest zarzut „pozorności” omawianego kryterium oceny ofert. SLA jest
klasycznym kryterium kontraktowym, który odnosi się do sposobu realizacji zamówienia na
usługę. Brak dotrzymania zadeklarowanych w ofercie parametrów SLA dla Usług
apli
kacyjnych skutkować będzie obniżeniami wynagrodzenia, których wartość została ustalona
w sposób progresywny (vide załącznik 13 „Matryca obniżenia wynagrodzenia” dodany na
mocy Modyfikacji 21 z dnia 29 maja 2020 r.). Zgodnie z art. 14 ust. 5 wzoru Umowy
„Zamawiający za każdą rozpoczętą 0,1 punktu procentowego niedotrzymania pojedynczego
Parametru Usług utrzymania dla każdej z Usług aplikacyjnych, o których mowa w Załączniku
10, w rozliczeniu miesięcznym naliczy obniżenie wynagrodzenia w wysokości określonej w
Matrycy obniżenia wynagrodzenia, stanowiącej Załącznik 13. Obniżenia wynagrodzenia
naliczone zgodnie z Matrycą obniżenia wynagrodzenia za pierwsze trzy miesiące
kalendarzowe świadczenia Usług utrzymania podlegają obniżeniu o 50%”. Na przykład jeżeli
wyk
onawca w ofercie zadeklaruje dostępność do usługi e-ZLA na poziomie 99% (symbol
parametru AVE.I), a następnie nie dotrzyma oferowanego parametru i parametr ten osiągnie
98 0,4, wynagrodzenie miesięczne z tytułu Usług utrzymania ulegnie obniżeniu o kwotę 116
000 zł (iloczyn kwoty 11.600,00 zł, określonej w „Matrycy obniżenia wynagrodzenia” dla
parametru AVE 1 i oferowanej wartości parametru z przedziału 98,7% do 99,0%, oraz liczby
dziesiętnych części punktu procentowego niedotrzymania parametru (11.600,00 zł x 10).
Niedotrzymanie parametru dostępności dla jednej tylko metryki skutkuje więc dotkliwymi
sankcjami finansowymi.
Wyjaśnienia wymaga również o jakiej niedostępności godzinowej
usługi jest mowa. Różnica pomiędzy deklarowanymi w ofercie wartościami dostępności dla
98% i 99% prezentuję się w następujący sposób:
Dostępność usługi w ciągu
miesiąca:

liczba dni w miesiącu
Wymagana dostępność systemu
przy wartości parametru (w
godzinach)
Różnica w
godzinach

30
705,6
712,8
7,2

31
729,1
736,6
7,5

Ozna
cza to, że dla metryki „SYS_ AVE#00_Dostęp do eZLA”, przy zaoferowaniu maksymalnej
dostępności (99%) niezapewnienie dostępności przez 7 godzin skutkuje obniżeniem
wynagrodzenia o 116 000 zł. Jeżeli weźmie się pod uwagę, że pomiarom dostępności
podlegają 4 metryki, sankcja finansowa za niedotrzymanie oferowanych parametrów usług jest
dotkliwa. W tym kontekście twierdzenie o pozorności kryterium jest całkowicie nieuprawnione.
Zupełnie karkołomna jest próba argumentacji Odwołującego, że kryterium „Poziom
dostępności usług (SLA)” nie jest kryterium innym niż cena/koszt wykonania. Twierdzenie, że
utrzymanie odpowiedniego SLA wiąże się z zatrudnieniem odpowiedniego zespołu osób, czyli
kosztem, można odnieść do większości kryteriów jakościowych, w tym również do kryterium
„test kompetencji technicznych", którego wprowadzenia żąda Odwołujący. Można przecież
powiedzieć, że przebieg testu w ramach tego kryterium uzależniony jest od zatrudnienia
odpowiedniego zespołu osób, które posiadają stosowne kompetencje, co rodzi określone
koszty. Uwagę taką można poczynić również do kryterium „doświadczenie personelu”, którego
Odwołujący nie kwestionuje. Reasumując, podwyższenie jakości usług, dostaw tub robót
budowlanych zawsze skutkuje podwyższeniem kosztów wykonania zamówienia, a przecież
nikt nie próbuje twierdzić, że kryteria jakościowe są de facto ukrytym kryterium cenowym.
Odwołujący w uzasadnieniu zarzutu prezentuje również zupełnie błędną wykładnię art. 91 ust.
2d ustawy Pzp, w odniesieniu do wymogu określenia kryterium w sposób „umożliwiający
sprawdzenie informacji przedstawionych przez Wykonawców". Twierdzenie, że określenie
parametru SLA przyszłych usług jest „niesprawdzalne” w rozumieniu ar. 91 ust. 2d ustawy Pzp,
oznaczałoby, że zamawiający nie mogą korzystać z takich kryteriów jak np. termin czy sposób
dostawy, bowiem parafrazując Odwołującego, „wszyscy wykonawcy wskażą najkorzystniejszy
termin i sposób dostawy, a następnie na etapie realizacji Umowy wybrany wykonawca nie
dotrzyma oferowanych warunków”. Wniosek taki byłby oczywiście sprzeczny z treścią art. 91
ust.2 pkt 6 ustawy, który wprost wskazuje na tego rodzaju kryteria. Z przedstawionych
względów Zamawiający wnosi o oddalenie zarzutu.
2. Zarzut 11 -
Załącznik 9 do Umowy rozdział III pkt C ppkt 1 i ppkt 3 - Nieprawidłowo
zdefiniowany proces obsługi Zgłoszeń
Zamawiający na wstępie informuje, że na mocy Modyfikacji nr 10 z dnia 29 maja 2020 r.
częściowo zmodyfikował kwestionowane postanowienie Załącznika 9 do Wzoru Umowy
nadając mu następujące brzmienie: „CZAS OBSŁUGI — STOP tylko w przypadku pierwszej
prośby”. Oznacza to, że mechanizm ten został przewidziany do wszystkich poziomów Usługi
serwisowej w tym dla Incydentu krytycznego. Jego zdaniem, nieprawdziwe jest twierdzenie
Odwołującego, że uchyla się od wsparcia Wykonawcy w realizacji jego zobowiązań, w tym od
przekazania mu informacji, o jakie będzie wnioskował w celu obsługi incydentów. Zamawiający
będzie odpowiadał na wszelkie prośby i pytania Wykonawcy jak ma to miejsce obecnie.
Kwestionowana procedura jedynie zakłada, że czas w którym Wykonawca zobowiązał się do

wykonywania swoich obowiązków nie będzie wstrzymywany w efekcie zadawania kolejnych
pytań. Jedynie jedno pytanie wstrzymuje bieg terminu realizacji usługi. Przedmiotowe
postanowienie jest w pełni uzasadnione tak potrzebami Zamawiającego jak i jego
doświadczeniami wynikającymi z obecnej praktyki. Na gruncie obecnie realizowanych umów
każde zadane pytanie wstrzymuje czas, w jakim wykonawca realizuje swoje zadanie czyniąc
zobowiązanie Wykonawcy do naprawy błędu lub usunięcia innej nieprawidłowości w
przewidzianym w SIWZ czasie
— iluzorycznym. Zamawiający może podać wiele przykładów,
gdzie obsługa zgłoszeń serwisowych przeciągała się. Wykonawcy poprzez mnożenie pytań
de facto nie czuli się związani jakimkolwiek reżimem czasowym obsługi incydentu. Obecna
regulacja przewiduje mechanizm zatrzymania czasu w przypadku pierwszego pytania
powinno zatem ono być sformułowane w taki sposób, aby obejmowało wszystkie brakujące
Wykonawcy informacje do właściwego rozwiązania problemu. Po otrzymaniu tych informacji
czas obsługi zaczyna biec. Nie oznacza to natomiast, że Zamawiający nie odpowie na zadane
dodatkowo pytania, a jedynie że ich zadanie nie zatrzyma na nowo czasu przewidzianego w
SIWZ do realizacji zadania. Tym samym W
ykonawcy będą musieli zadać niezbędne i właściwe
pytania za pierwszym razem, a nie wykorzystywać procedury, niezgodnie z jej
przeznaczeniem, na zadawanie serii pytań w celu przedłużenia sobie czasu na obsługę
incydentów, bez ponoszenia jakiejkolwiek z tego tytułu odpowiedzialności. Na marginesie
wskaz
ał, że argumentacja Odwołującego jakoby istniały dwa standardy/modele obsługi
incydentów, co uniemożliwia zastosowanie rozwiązań przewidzianych przez Zamawiającego
jest gołosłowna. Żaden przepis prawa zamówień publicznych nie został naruszony poprzez
przyjęcie kwestionowanych postanowień Umowy, w szczególności art. 29 ustawy Pzp
ponieważ zakres obowiązków Wykonawcy został określony wyraźnie i precyzyjnie. Skutkiem
uchylenia kwestionowanych postanowień Umowy będzie natomiast uzależnienie poziomu
świadczenia usług od „sprytu wykonawcy” a nie od obiektywnych niezależnych od jego
indywidulanych cech lub umiejętności okoliczności. Tak jak zostało już zauważone,
przedmiotowa Umowa ma charakter umowy rezultatu
— rezultatem jest utrzymanie
sprawności systemu na określonym poziomie. Za ten rezultat Wykonawca bierze
odpowiedzialność z zastrzeżeniem wyjątków określonych właściwymi postanowieniami. Nie
można zatem jednocześnie dawać Wykonawcy instrumentów pozwalających manipulować
tym rezultatem.
Także na marginesie wskazał, że niemal tożsamy zarzut, dotyczący
analogicznej treści załącznika nr 9 do wzoru Umowy w postępowaniu na świadczenie usług
wsparcia eksploatacji i utrzymania Kompleksowego Systemu Informatycznego Zakładu
U
bezpieczeń Społecznych (KSI ZUS), znak postępowania: TZ/271/65/19, został oddalony
przez Krajow
ą Izbę Odwoławczą wyrokiem z 19.06.2020 r. sygn. KIO 452/20 wydanym w
sprawie
odwołania Asseco Poland SA.

3. Zarzut 13 -
Załącznik 8 do SIWZ „Opis Systemu PUE” - Brak w Umowie postanowień
dotyczących postępowania z niekompletnymi Kodami źródłowymi opisanymi w
Załączniku 8: Opis systemu PUE punkt Kody źródłowe
W zakresie w pkt. 1) Zamawiający uwzględnił żądanie Odwołującego, to jest opublikował
szczegółowe informacje o brakach w kodach źródłowych — patrz Modyfikacja nr 5 SIWZ z
dnia 29.05.2020 r.
W zakresie pkt. 2, 3 i 4 Zamawiający wnosi o oddalenie zarzutu.
Zdaniem Zamawiającego wprowadzenie proponowanych przez Odwołującego dodatkowych
zmian do przedstawionych proc
edur jest nadmiarowe ponieważ zaproponowane w SIWZ
procedury już obecnie dopuszczają obsługę takich sytuacji. Procedury obsługi Incydentów
opisane w Załączniku nr, 9 Zakres oraz poziom świadczenia Usług serwisowych już obecnie
dopuszczają wstrzymanie czasu obsługi zgłoszenia, w tym również z powodu braku kodów
źródłowych. W takiej sytuacji należy zastosować komunikat ZN - Zalecenia naprawcze
(Rozwiązanie). Odwołujący jest tego w pełni świadomy ponieważ podczas realizacji prac w
ramach obecnej umowy wielokro
tnie korzystał z tego mechanizmu. Na przykład podczas
realizacji zgłoszenia ZS438934 Odwołujący wydał Zalecenia naprawcze o treści ,12/03/2020
Poprawka wymaga dokonania zmian w kodach źródłowych samego formularza ZUS Z-3
(zmiana atrybutu w HTML). W repo
zytorium brak jest kodów źródłowych dla tego formularza.
Wprowadzenie poprawki będzie mogło zostać dokonane po ewentualnym odtworzeniu kodów
źródłowych.” Dowód: diagnoza dla zgłoszenia ZS438934 - wydruk z systemu obsługi zgłoszeń
Zamawiającego HP SM. Również (jego zdaniem) nieuzasadnione są obawy Odwołującego
odnoszące się do wykonania Modyfikacji Systemu w sytuacji niekompletnych kodów
źródłowych dla zmienianego obszaru Systemu. Opisana w Umowie w Art. 4 ust. 4 - 7
procedura zlecenia Modyfikacji wskazuje,
że strony wspólnie prowadzą negocjacje, w wyniku
których Wykonawca przedkłada do akceptacji Zamawiającego Uzgodnienie projektowe (UP).
Następnie, na podstawie wspólnie uzgodnionego UP, Wykonawca składa Zamawiającemu
Ofertę, która powinna zawierać między innymi szczegółowy opis zakresu Modyfikacji lub
Usługi dodatkowej wraz z pracochłonnością. Katalog zagadnień objętych ofertą ma charakter
otwarty, a zatem szczegółowy opis może zawierać również informację o potrzebie odtworzenia
Kodów źródłowych na potrzeby realizacji danej Modyfikacji, wraz z wyceną tych prac.
Natomiast jeżeli braki w zakresie kodów źródłowych ujawnią się w toku realizacji Modyfikacji
wykonawca zawsze może wystąpić z Wnioskiem o Zmianę Modyfikacji, w której zaproponuje
sposób podejścia do problemu braków lub niezgodności kodów z wersję wynikową
oprogramowania. Reasumując, kodyfikacja procedur dotyczących każdego z zagadnień, które
mogą się ujawnić na etapie negocjacji lub realizacji Modyfikacji jest niecelowa. Negocjacyjny
charakter ustalania
zakresu i wyceny Modyfikacji powoduje, że Zamawiający świadomie
uregulował procedurę negocjacji w sprawie Modyfikacji w sposób dość ogólny i elastyczny.


Izba ustaliła następujący stan faktyczny tej sprawy:

Odwołujący w piśmie z dnia 17 czerwca 2020 r. informując o modyfikacji w SIWZ (i jej
załącznikach) z dnia 29 maja 2020 r. co do części zarzutów wniósł o umorzenie postępowania
odwoławczego uznając, że ta modyfikacja spowodowała, że jego żądania zostały spełnione.
Ostateczne stanowisko, sformułował w piśmie procesowym z dnia 2 lipca 2020 r. w którym
stwierdził: „Zamawiający w dniu 24 czerwca 2020 roku dokonał kolejnych zmian SIWZ.
Odwołujący po dokonaniu szczegółowej analizy przedmiotowych zmian stwierdził, że część
zmian jest skutkiem Odwołania KIO 937/20 wniesionego przez Asseco Poland S.A. (dalej
„Odwołanie”), zaś treść zmian może wpływać zarówno na zakres rozpatrzenia odwołania, jak
i
na argumentację podnoszoną w odwołaniu. W związku z powyższym, podtrzymując
stanowisko wskazane w piśmie z dnia 17 czerwca 2020 roku, Asseco Poland S.A. wskazuje,
że:
(…) Zarzut 2. Załącznik nr 2 do SIWZ „ Wzór umowy”, Artykuł 2 „Przedmiot Umowy”, ust. 1:
Wirtualny Doradca oraz Rozwój i Utrzymanie Oprogramowania Standardowego
Zamawiający dokonał zmian zgodnie z żądaniem Zarzutu 2 — Modyfikacją nr 1 z 24.06.2020r.
Tym samym Zamawiający poprzez czynność faktyczną dokonał uwzględnienia odwołania w
przedmiotowej części. Wobec powyższego Odwołujący wnosi o umorzenie postepowania w
zakresie Zarzutu 2
”.
(…) Zarzut 10: Załącznik 5 do Umowy „Zasady ustalania wynagrodzenia z tytułu Usług
utrzymania” — brak jednoznacznego określenia złożoności Systemu
Zamawiający dokonał zmian zgodnie z żądaniem Zarzutu 10 — Modyfikacją nr 2 i 3 z
24.06.2020r. Tym samym Zamawiający poprzez czynność faktyczną dokonał uwzględnienia
odwołania w przedmiotowej części. Wobec powyższego Odwołujący wnosi o umorzenie
postepowania w zakresie Zarzutu 10
”.
Wobec powyższego Odwołujący wniósł o:
„1. Skierowanie na rozprawę zarzutów 1, 11 i 13;
2. Um
orzenie postępowania w zakresie zarzutów 2 — 10 i 12. Odwołujący oświadcza, że
modyfikuje żądania zarzutów 2 — 10 i 12 zgodnie ze zmianami dokonanymi przez
Zamawiającego. W związku z powyższym obecna sytuacja faktyczna wskazuje na faktyczne
uwzględnienie odwołania przez Zamawiającego w zakresie zarzutów 2 - 10 i 12.
Odwołujący wskazuje, że analogiczna sytuacja procesowa miała miejsce w toku postępowania
KIO 452/20, gdzie Zamawiający po złożenia oświadczenia jak powyżej uwzględnił odwołanie
w części”.

Odwołujący na posiedzeniu w dniu 8 lipca 2020 r. oświadczył, że uwzględniając
dotychczasowe modyfikacje specyfikacji i jej załączników modyfikuje odpowiednio żądania w
zakresie zarzutów z punktu 2 do 10 i punktu 12 uzasadnienia odwołania, co do których w

piśmie z dnia 2 lipca 2020 r. wnioskował o umorzenie postępowania, która to modyfikacja
następuje zgodnie ze zmianami dokonanymi przez Zamawiającego spornych postanowień.

Zamawiający z uwagi na to oświadczenie wykonawcy, oświadczył z kolei, że
uwzględnia zarzuty z punktu 2 do 10 i punktu 12 uzasadnienia odwołania i na tej podstawie
wnosi o umorzenie postępowania odwoławczego zgodnie z wnioskiem Odwołującego.
Podtrzymał ponadto stanowisko co do modyfikacji postanowień, których dotyczył zarzut z
punktu 13 uzasadn
ienia odwołania.

Odwołujący mając na uwadze modyfikacje postanowień w zakresie zarzutu z punktu
13
uzasadnienia odwołania oraz stanowisko przedstawione przez Zamawiającego w
odpowiedzi na odwołanie z dnia 7 lipca 2020 r. i na posiedzeniu w dniu 8 lipca 2020 r.
oświadczył do Protokołu, że cofa zarzut podnoszony w punkcie 13 uzasadnienia odwołania.



Izba, w
obec powyższych ustaleń, stwierdziła:

P
ostępowanie odwoławcze – uwzględniając odpowiednio przepis art. 186 ust. 3 ustawy
Pzp i art. 187 ust. 8 tej ustawy -
należało umorzyć we wskazanym zakresie, a mianowicie w
zakresie
zarzutów podniesionych w uzasadnieniu odwołania:
- w pkt 2 do 10 i w pkt 12 - z powodu ich uw
zględnienia w tej części przez Zamawiającego
oraz wobec niewniesienia sprzeciwu przez u
czestnika postępowania odwoławczego, który
przystąpił do postępowania po stronie zamawiającego,
- w pkt 13 - z uwagi na jego
cofnięcie przez Odwołującego na posiedzeniu.

W pozostałym zakresie odwołanie, (co do zarzutu z pkt 1 i z pkt 11 uzasadnienia
od
wołania) podlegało rozpoznaniu przez skład orzekający. Izba rozpoznając powyższe zarzuty
uznała, że te zarzuty nie zasługują na uwzględnienie i odwołanie z tego powodu podlega
oddaleniu.

Odnośnie pierwszego zarzutu dotyczącego pkt 7 SIWZ (Kryteria i zasady oceny ofert)
wykonawca Asseco wskazał na naruszenie art. 91 ust. 2c i 2d ustawy Pzp w związku z jej art.
7 ust. 1 z uwagi na
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. Zdaniem Odwołującego kryterium „Poziom dostępności
usług (SLA)" jest także pozornym kryterium pozacenowym, zwłaszcza mając na uwadze
wysoką wagę, jaką Zamawiający nadał temu kryterium.

W myśl wskazanego art. 91 ust.2c: „Kryteria oceny ofert są związane z przedmiotem
zamówienia, jeżeli dotyczą robót budowlanych, dostaw lub usług, które mają być zrealizowane
w ramach tego zamówienia, we wszystkich aspektach oraz w odniesieniu do poszczególnych

etap
ów ich cyklu życia, w tym procesu produkcji, dostarczania lub wprowadzania na rynek,
nawet jeżeli nie są istotną cechą przedmiotu zamówienia”.
Z kolei w myśl art. 91 ust.2d.: „Zamawiający określa kryteria oceny ofert w sposób
jednoznaczny i zrozumiały, umożliwiający sprawdzenie informacji przedstawianych przez
wykonawców”.

Zamawiający w SIWZ w pkt 7.2. określił w SIWZ 3 kryteria oceny ofert: 1) Całkowita
cena oferty brutto - 60%; 2)
Poziom dostępności usług (SLA) - 30%; 3) Doświadczenie
personelu -10%. Od
nośnie spornego kryterium (Poziom dostępności usług (SLA) wskazał na
następującą procedurę oceny opisaną w punkcie 7.3.3 SIWZ:
„Poziom dostępności usług (SLA) opisanych w załączniku nr 10 do wzoru umowy (załącznik
nr 2 do SIWZ).
7.3.3.Kryterium: Poziom do
stępności usług (SLA) - Wykonawca może otrzymać punkty
obliczone według następującego wzoru: Suma liczby punktów uzyskanych przez Wykonawcę
zgodnie z Tabelami SLA1, SLA2, SLA3 i SLA4SLA = -----------------------------------------------------
---------x 30 (waga kryterium w %)
”
W tym kryterium określił cztery usługi:
1.
Wsparcie utrzymania Usługi_SYS_AVN#00_Dostęp do Systemu (Tabela SLA1):
zaznaczając, że: „Minimalny poziom dostępności (Parametr „D”) i wydajności (Parametr
„W”), który musi zapewnić Wykonawca wynosi: dla D >= 98,0 % dla W >= 98,0 %.” W tabeli
opisał szczegółowo jak będą przyznawane punkty rozwijając usługę na trzy parametry
(AVN.1, AVN.2, AVN.3)-
przyznanie punktów za każde 0,1% podwyższenia w stosunku do
wymaganych 98,0 %;
2. Wsparcie utrzymania Us
ługi_SYS_DST#00_Dostęp do widoków i sekcji Systemu (Tabela
SLA2) z zaznaczeniem także: „Minimalny poziom dostępności (Parametr „D”), który musi
zapewnić Wykonawca wynosi: D >= 98,0%”. Również w tabeli opisał szczegółowo jak będą
przyznawane punkty rozwijaj
ąc usługę na 3 parametry (DST.1, DST.2, DST.3)- przyznanie
punktów za każde 0,1% podwyższenia w stosunku do wymaganych 98,0 %;
3.
Wsparcie utrzymania Usługi_SYS_AVZ#00_Dostęp do strony ZUS (tabela SLA3) z
zaznaczeniem także: Minimalny poziom dostępności (Parametr „D”), który musi zapewnić
Wykonawca wynosi: D >= 98,0%
”. Podobnie w tabeli opisał szczegółowo jak będzie
punktowany, w tym przypadku jeden parametr (AVZ.1) -
przyznanie punktów za każde
0,1% podwyższenia w stosunku do wymaganych 98,0 %;
4. Wsparcie utrz
ymania Usługi_ SYS_AVE#00_Dostęp do eZLA (tabela SLA4) z
zaznaczeniem także: „Minimalny poziom dostępności (Parametr „D”), który musi zapewnić
Wykonawca wynosi: D >= 98,0%
”. W tabeli opisał szczegółowo jak będzie punktowany, w

tym przypadku jeden parametr (AVE.1) -
przyznanie punktów za każde 0,1% podwyższenia
w stosunku do wymaganych 98,0 %.
Zamieścił także w zakresie tego kryterium w tym punkcie SIWZ uwagę o treści:
„Jeżeli Wykonawca w ofercie nie poda wartości parametru dla ww. usługi/usług, Zamawiający
przyjmuje, że Wykonawca zaoferował minimalną wymaganą wartość parametru tj. 98,0 %
usług oraz otrzyma 0 pkt. w zakresie tego parametru.
Jeżeli Wykonawca w ofercie poda wartość parametru dla ww. usługi/usług poniżej zakresów
określonych w ww. tabelach, tj. poda wartość parametru poniżej min. 98,0 % poziomu
określonego w tabeli dla danej usługi - Zamawiający odrzuci ofertę Wykonawcy na podstawie
art. 89 ust. 1 pkt 2 ustawy,
Jeżeli Wykonawca w ofercie poda wartość parametru dla ww. usługi/usług powyżej zakresów
określonych w ww. tabelach, tj. poda wartość parametru powyżej 99,0 % poziomu określonego
w tabeli dla danej usługi/usług - Zamawiający przyzna punkty jak dla poziomu 99,0 % wartości
parametru
”.
Z kolei w
e Wzorze umowy (zał. nr 2 do SIWZ) w związku z tym kryterium w art. 14 ust.
5:
„Kary umowne i odpowiedzialność” Zamawiający wskazał, że:
„5. Zamawiający za każdą rozpoczętą 0,1 punktu procentowego niedotrzymania
pojedynczego Parametru Usług utrzymania dla każdej z Usług aplikacyjnych, o których mowa
w
Załączniku 10, w rozliczeniu miesięcznym naliczy karę umowną w wysokości określonej w
Matrycy kar umownych, stanowiącej Załącznik 13. Kary umowne naliczone zgodnie z Matrycą
kar umownych za pierwsze trzy miesiące kalendarzowe świadczenia Usług utrzymania
podlegają obniżeniu o 50%.”

Zatem według tych reguł minimalny poziom dostępności Systemu(SLA) wynosi 98%,
który musi dochować każdy wykonawca usuwając Incydenty. W ramach przedmiotowego
kryterium wykonawcy mogą zadeklarować podniesienie dostępności o 1% (w ramach 1 %
postąpienia o 01,%) - do 99%. Wykonawca, który zadeklaruje taką podwyższoną (do 1%)
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.
Izba
mając takie ustalenia na uwadze, w pierwszej kolejności stwierdza, że nie można
zgodzić się z Odwołującym, że to kryterium („Poziom dostępności usług (SLA)”) jest kryterium
oceny ofert niezwiązanym z przedmiotem zamówienia, co jest wymagane przepisem art. 91
ust.2c Pzp.
Tak jak wskazywał Zamawiający, kwestionowane w odwołaniu kryterium oceny
ofert
„odnosi się wprost do istoty Umowy, której zawarcie jest przedmiotem postępowania.
Umowa na rozwój i utrzymanie Portalu Klienta oraz Szyny Usług (ESB) w ramach Platformy

Usług Elektronicznych ZUS obejmuje szereg świadczeń o niejednorodnym charakterze.
Umowa obejmuje m.in. Modyfikacje Systemu, które zakwalifikować można jako dzieło, Usługi
dodatkowe, które w zależności od danego zlecenia mogą stanowić dzieło lub usługi
konsultingu, a także usługi szkoleniowe oraz Usługi utrzymania”. Niewątpliwie Umowa w
zakresie Usług utrzymania (która zostanie zawarta w wyniku tego przetargu) – jak wskazywał
zamawiający – „nie jest standardową umową o świadczenie usług w rozumieniu art. 750 k.c.
W zakresie tych świadczeń można uznać ją za umowę o świadczenie usług o charakterze
zbliżonym do tak zwanych umów rezultatu, których przedmiotem jest indywidualnie oznaczony
wytwór (rezultat). Na gruncie Umowy, w odniesieniu do Metryk Usług Wykonawcy rezultatem
tym jest uzyskanie przez Wykonawcę określonego w tych metrykach SLA (Service Level
Agreement), to jest osiągnięcie założonych parametrów: dostępności, ciągłości, czasu
rozwiązania incydentu itp. Gwarancja SLA z założenia ma ułatwiać użytkownikowi
dochodzenie uprawnień, a odpowiedzialność wykonawcy nie jest oparta o dochowanie
należytej staranności i bardzo często ma wręcz charakter gwarancyjny. Poprzez zdefiniowanie
poziomów usługi określa się pewien rezultat i wykazanie braku tego rezultatu jest
wystarczające do udowodnienia niewykonania lub nienależytego wykonania zobowiązania, a
więc jednej z przesłanek odpowiedzialności określonych w art. 471 k.c. W przeciwnym razie,
konieczne byłoby udowodnienie nienależytej staranności wykonawcy oraz pozostałych
przesłanek odpowiedzialności wykonawcy, co w praktyce jest niemal niemożliwe. Kwalifikacja
prawna Usług utrzymania objętych Umową przesądza w sposób jednoznaczny ścisły związek
ustalonego przez Zamawiającego kryterium dotyczącego SLA z przedmiotem zamówienia”.
Także zdaniem Izby nie jest słuszny zarzut „pozorności” spornego kryterium oceny ofert. Obok
ogólnych stwierdzeń, co do funkcji kryterium Poziomu dostępności usług (jak podał: SLA jest
klasycznym kryterium kontraktowym, który odnosi się do sposobu realizacji zamówienia na
usługę) Zamawiający wykazał, że jest możliwa weryfikacja zadeklarowanego w ofercie
parametru, albowiem brak jego dotrzymania (
SLA dla Usług aplikacyjnych) skutkować będzie
– jak wskazywał – „obniżeniami wynagrodzenia, których wartość została ustalona w sposób
progresywny (vide załącznik 13 „Matryca obniżenia wynagrodzenia” dodany na mocy
Modyfikacji 21 z dn
ia 29 maja 2020 r.). Zgodnie z art. 14 ust. 5 wzoru Umowy „Zamawiający
za każdą rozpoczętą 0,1 punktu procentowego niedotrzymania pojedynczego Parametru
Usług utrzymania dla każdej z Usług aplikacyjnych, o których mowa w Załączniku 10, w
rozliczeniu miesięcznym naliczy obniżenie wynagrodzenia w wysokości określonej w Matrycy
obniżenia wynagrodzenia, stanowiącej Załącznik 13. Obniżenia wynagrodzenia naliczone
zgodnie z Matrycą obniżenia wynagrodzenia za pierwsze trzy miesiące kalendarzowe
świadczenia Usług utrzymania podlegają obniżeniu 0 50%”. Tytułem przykładu podał, że: (…)
jeżeli wykonawca w ofercie zadeklaruje dostępność do usługi e-ZLA na poziomie 99% (symbol
parametru AVE.1
), a następnie nie dotrzyma oferowanego parametru i parametr ten osiągnie

98 %,
wynagrodzenie miesięczne z tytułu Usług utrzymania ulegnie obniżeniu o kwotę 116
000 zł (iloczyn kwoty 11.600,00 zł, określonej w „Matrycy obniżenia wynagrodzenia” dla
parametru AVE.
1 i oferowanej wartości parametru z przedziału 98,7% do 99,0%, oraz liczby
dziesiętnych części punktu procentowego niedotrzymania parametru (11.600,00 zł x 10)”.
Niewątpliwie niedotrzymanie parametru dostępności dla jednej tylko metryki skutkuje
dotkliwymi sankcjami finansowymi.
Niewątpliwie również, utrzymanie odpowiedniego SLA
wiąże się z zatrudnieniem odpowiedniego zespołu osób, czyli kosztem, co można odnieść do
większości kryteriów jakościowych, w tym również do kryterium „test kompetencji
technicznych", którego wprowadzenia żąda Odwołujący. Zatem podwyższenie jakości w tym
usług, jak w tym przypadku wiąże się z podwyższeniem kosztów wykonania zamówienia, co
nie oznacza, że kryteria jakościowe są de facto ukrytym kryterium cenowym. Tym samym nie
jest słuszny zarzut dotyczący naruszenia art. 91 ust.2d ustawy Pzp w zw. z jej art. 7 ust. 1,
albowiem sporne kryterium
– jak wymaga przepis - jest jednoznaczne i zrozumiałe, a jego
sprawdzenie definitywne (podobnie jak i innych podobnych kryteriów) niewątpliwe nastąpi na
etapie realizacji umowy. Izba podkreśla, że Zamawiający szczegółowo wskazał na mechanizm
weryfikacji parametru i możliwych sankcji.

Odnośnie drugiego zarzutu (nr 11: Załącznik 9 do Umowy rozdział III pkt C ppkt 1 i ppkt
3 -
Nieprawidłowo zdefiniowany proces obsługi Zgłoszeń) wykonawca wskazał, że „Obecna
konstrukc
ja 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 art. 471 Kodeksu
Cywilnego i przekracz
a zasadę swobody umów określoną w art. 353(1) KC”. Wskazał ponadto,
że obecne brzmienie SIWZ w przedmiotowym zakresie jest także niezgodne z określonym w
art. 29 ust. 1 ustawy P
zp (…) 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”.
W tym przypadku Izba podzieliła stanowisko Zamawiającego, że w związku z
modyfikacj
ą nr 10 z dnia 29 maja 2020 r. częściowo zmodyfikował kwestionowane
postanowienie Załącznika 9 do Wzoru Umowy nadając mu następujące brzmienie: „CZAS
OBSŁUGI — STOP tylko w przypadku pierwszej prośby”. Oznacza to, że mechanizm ten
został przewidziany do wszystkich poziomów Usługi serwisowej w tym dla Incydentu
krytycznego.
Nie można się zgodzić się zatem z twierdzeniem wykonawcy, że Zamawiający
uchyla się od wsparcia Wykonawcy w realizacji jego zobowiązań, w tym od przekazania mu

informacji, o jakie będzie wnioskował w celu obsługi incydentów. Tym bardziej, że stanowisko
przeciwne przedstawił na rozprawie wykonawca przystępujący Comarch (potencjalnie
ubiegający się także o to zamówienie) odnosząc się negatywnie do praktyki zadawania pytań
kwalifikujących je jako nieistotne i ich nadmiernej częstotliwości. Izba także zwraca uwagę, że
ten mechanizm nie zwalnia
Zamawiającego z odpowiedzi na wszelkie prośby i pytania
wykonawcy (podobnie jak ma to miejsce obecnie). Kwestionowana procedura
zakłada
natomiast
, że czas w którym wykonawca zobowiązał się do wykonywania swoich obowiązków
nie będzie wstrzymywany w efekcie zadawania kolejnych pytań. Jedynie jedno pytanie
wstrzymuje bieg terminu realizacji usługi. W tym przypadku Odwołujący nie wykazał zdaniem
Izby, że sporny mechanizm nie jest uzasadniony tak potrzebami Zamawiającego jak i jego
doświadczeniami wynikającymi z obecnej praktyki. Obecna regulacja przewiduje mechanizm
zatrzymania czasu w przypadku pierwszego pytania, a zatem
powinno ono być sformułowane
w taki sposób, aby obejmowało wszystkie brakujące wykonawcy informacje do właściwego
rozwiązania problemu. Izba także stwierdza, że Odwołujący nie wykazał jakoby istniały dwa
standardy/modele obsługi incydentów, co uniemożliwia zastosowanie rozwiązań
przewidzianych przez z
amawiającego z punktu widzenia przepisów Pzp, w tym art. 29 ust.1
ustawy Pzp. Z
akres obowiązków wykonawcy został określony jednoznacznie i precyzyjnie, i
jednakowo dla wszystkich potencjalnych wykonawców. Należy także dodać, że w odwołaniu
nie są kwestionowane terminy przewidziane na realizację zgłoszeń serwisowych, jak i
wprowadzone ograniczenia ilościowe, co do danej grupy zgłoszeń, które to elementy OPZ w
sposób istotny określają zakres zobowiązania wykonawcy. Sam mechanizm natomiast
stanowi wyłącznie element dyscyplinujący i wpływający na efektywność świadczenia, a nie
jego zakres, co
również wskazuje, że kwestionowane w odwołaniu postanowienie SIWZ nie
narusza przepisu art. 29 ust 1 ustawy Pzp.
Izba zwraca również uwagę, że zakres modyfikacji
nr 10 zapewnia niezbędny kompromis między potrzebami Zamawiającego dotyczącymi jak
najkrótszego czasu naprawiania incydentów, a potrzebami wykonawców dotyczącymi
konieczności uzyskania niezbędnych w tym zakresie informacji.

Mając powyższe na uwadze wskazywane w odwołaniu przepisy w zakresie
rozpoznawanych za
rzutów, w tym przepisy ustawy Pzp w szczególności jej art. 91 ust. 2c i 2d
ustawy Pzp w związku z art. 7 ust. 1 tej ustawy oraz art. 29 ust. 1 ustawy Pzp nie zasługują na
uwzględnienie.

Mając powyższe na uwadze orzeczono jak w sentencji.

O kosztach post
ępowania orzeczono na podstawie art. 192 ust. 9 i 10 ustawy Pzp stosownie
do wyniku sprawy uwzględniając także przepisy rozporządzenia Prezesa Rady Ministrów z
dnia 15 marca 2010 r. w sprawie wysokości wpisu od odwołania oraz rodzajów kosztów w
postępowaniu odwoławczym i sposobu ich rozliczania (Dz. U. z 2018 r, poz. 972).


……………………………………..

……………………………………..

……………………………………..

Wcześniejsze orzeczenia:

• Sygn. akt KIO 1461/20 z dnia 2020-08-04
• Sygn. akt KIO 1367/20 z dnia 2020-08-04
• Sygn. akt KIO 1662/20 z dnia 2020-07-31
• Sygn. akt KIO 1594/20 z dnia 2020-07-31
• Sygn. akt KIO 1500/20 z dnia 2020-07-31