KIO 937/20 WYROK dnia 9 lipca 2020 r.

Data: 24 sierpnia 2020

Sygn. akt: KIO 937/20 

WYROK 

z dnia 9 lipca 2020 r. 

Krajowa Izba Odwoławcza   -   w składzie: 

Przewodniczący:      Agata Mikołajczyk 

Członkowie:    

Emilia Garbala 

Izabela Niedziałek-Bujak  

Protokolant:  

Piotr  

Cegłowski 

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; 

W pozostałym zakresie oddala odwołanie; 

Kosztami  postępowania  odwoławczego  obciąża  odwołującego:  Asseco  Poland  S.A.  z 

Rzeszowa (ul. Olchowa 14, 35-

322 Rzeszów) i:  

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; 

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; 

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

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; 

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; 

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: 

Całkowita cena oferty brutto - 60% 

Poziom dostępności usług (SLA) - 30% 

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: 


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: 

wykreślenie kryterium „Poziom dostępności usług „SLA" 

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. 

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. 


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

SAG Środowisko symulacyjne elektronicznych Zaświadczeń Lekarskich (eZLA); 

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, 

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: 

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; 

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. 

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

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: 

(…) 

z  wykonania  audytu  Zamawiający  sporządzi  protokół,  który  może  zawierać  zalecenia 

usunięcia niezgodności; 

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

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


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 

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: 

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

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

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: 

wykreślenie w Umowie w art. 14 ust. 2 pkt 7) -12) oraz ust. 5. 

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

od 98,1% do 98,3%

od 98,4% do 98,6%

od 98,7% do 99,0%

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

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. 


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: 

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; 

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; 

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: 


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

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

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.

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

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

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. 

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

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

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. 

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, 

Identyfikator Usługi, której dotyczy Zgłoszenie, 

Poziom świadczenia Usługi serwisowej, 

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 (...), 

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: 

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: 

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

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; 

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. 

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  

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: 

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

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; 

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: 

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 


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 

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 

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: 

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

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. 

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 

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 


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 

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

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

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

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


wiper-pixel