Wyrok KIO 2105/24 z 24 lipca 2024

1. Umarza postępowanie odwoławcze w sprawie sygn. akt KIO 2105/23 w zakresie: -zarzutów IVB, IVC, V, IX, XII, XIV, XXII, XXIV, XXV i XXVI – z powodu uwzględnienia zarzutów odwołania przez Zamawiającego, -zarzutów III, VII, XVIII, XXI, XXIII – z powodu ich wycofania przez Odwołujacego zarzutów, -zarzutów X i XVI, zarzutu II w odniesieniu do §7 ust. 12, 21, 24 – z uwagi ​ na ich bezprzedmiotowość.
2. Umarza postępowanie odwoławcze w sprawie sygn. akt KIO 2125/23 w zakresie: -zarzutu 1 – z uwagi na jego bezprzedmiotowość, - zarzutu 6 – z powodu uwzględnienia zarzutu odwołania przez Zamawiającego.
3. Uwzględnia w części odwołanie sygn. akt KIO 2105/24 i nakazuje Zamawiającemu: -wykreślenie z Tom II SW Z – Projektowane postanowienia umowy treści określonych w § 7 ust. 13, 14, 15, 16, 17, 18, 20, 23, 25, 29, 30 (zarzut II), -wykreślenie punktu 4.2.6 OPZ w całości w związku tym, że brzmienie jakie przyjął nie jest wyczerpujące (zarzut VI A, zarzut VI B), -uzupełnienie punktu 5.3.3 OPZ przez podanie godzinowego limitu udzielanych Konsultacji w miesiącu (zarzut XI), -wykreślenie punktu 5.4.1. ppkt 7 OPZ oraz nakazuje wprowadzenie całego zadania w ramach Usług Rozwoju na Zgłoszenie (zarzut XV), -wykreślenie w Formularzu cenowym Załącznika nr 2 do OPZ (Formularz 2.2.) - Rozwój Zdefiniowany oraz w Załączniku nr 2 do OPZ Opis wymagań ​ w zakresie Rozwoju Zdefiniowanego dat dziennych w systemie dzień/miesiąc/rok oraz określenie terminów w dniach, tygodniach, miesiącach lub latach (jednostkach czasu) od daty zakończenia Okresu Przejściowego (zarzut XVII), -wykreślenie z Załącznika nr 2 do OPZ Opis wymagań w zakresie Rozwoju Zdefiniowanego postanowień 9b.

SZPROT_W FED_36_A_2. w punkcie 9.b1 i 9b2 (odpowiadających swoja treścią 9.

SZPROT_W FED_36_A) oraz nakazuje wprowadzenie zadania w ramach Usług Rozwoju na Zgłoszenie (zarzut XX).

W pozostałym zakresie zarzuty odwołania Izba uznała za niezasadne.

1. Uwzględnia w części odwołanie sygn. akt KIO 2125/24 i nakazuje Zamawiającemu ​ w TOM III SWZ Opis przedmiotu zamówienia na „Świadczenie usług rozwoju ​ i utrzymania Systemu SZPROT” w definicji „Okres przejściowy” wykreślenie zdania pierwszego i wprowadzenie w to miejsce zdania: „Okres 3 miesięcy od dnia zawarcia umowy do Przejęcia Systemu” oraz dodanie zdania: „Okres przejściowy może zostać skrócony za porozumieniem Stron”.

W pozostałym zakresie zarzuty odwołania Izba uznała za niezasadne.

1. Kosztami postępowania obciąża wykonawcę Asseco Poland spółka akcyjna ​ z siedzibą w Rzeszowie oraz wykonawcę Comarch Polska spółka akcyjna z siedziba w Krakowie oraz Zamawiającego – Centrum Informatyki Resortu Finansów ​ w Radomiu 5.1zalicza w poczet kosztów postępowania odwoławczego:

kwotę 15 000,00 zł (słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez wykonawcę Asseco Poland spółka akcyjna z siedzibą w Rzeszowie tytułem wpisu od odwołania, kwotę 15 000,00 zł (słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez wykonawcę Comarch Polska spółka akcyjna z siedziba w Krakowie tytułem wpisu od odwołania, kwotę 4 428,00 zł (słownie: cztery tysiące czterysta dwadzieścia osiem złotych zero groszy) poniesioną przez wykonawcę Asseco Poland spółka akcyjna z​ siedzibą w Rzeszowie tytułem wynagrodzenia pełnomocnika, kwotę 4 428,00 zł (słownie: cztery tysiące czterysta dwadzieścia osiem złotych zero groszy) poniesioną przez wykonawcę Comarch Polska spółka akcyjna z​ siedziba w Krakowie tytułem wynagrodzenia pełnomocnika, 5.2zasądza od Zamawiającego Centrum Informatyki Resortu Finansów w Radomiuna rzecz wykonawcy Asseco Poland spółka akcyjna z siedzibą w Rzeszowie kwotę 10 146,00 zł (słownie: dziesięć tysięcy sto czterdzieści sześć złotych zero groszy) stanowiącą koszty postępowania odwoławczego poniesione przez Asseco Poland spółka akcyjna z siedzibą w Rzeszowie stosowanie do wyniku postępowania, 5.3zasądza od Zamawiającego Centrum Informatyki Resortu Finansów w Radomiu na rzecz wykonawcyComarch Polska spółka akcyjna z siedziba w Krakowie kwotę 4 650,00 zł (słownie: cztery tysiące sześćset pięćdziesiąt złotych zero groszy) stanowiącą koszty postępowania odwoławczego poniesione przez Comarch Polska spółka akcyjna z siedziba w Krakowie stosowanie do wyniku postępowania, Na orzeczenie - w terminie 14 dni od dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu Okręgowego w Warszawie - sądu zamówień publicznych.

Przewodnicząca

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

Sygn. akt

KIO 2105/24

KIO 2125/24 U Z AS AD N I E N I E Zamawiający – Centrum Informatyki Resortu Finansów w Radomiuprowadzi postępowanie o udzielenie zamówienia publicznego prowadzonego w trybie przetargu nieograniczonego na „Świadczenie usług rozwoju i utrzymania Systemu SZPROT”. Numer postępowania: PN/22/24/IATS Publikacja ogłoszenia w Dzienniku Urzędowym Unii Europejskiej: nr wydania: Dz.U. S: 110/2024 z dnia 07 czerwca 2024 roku, Numer publikacji ogłoszenia: 337557-2024.

Sygn. akt

KIO 2105/24

W dniu 17 czerwca 2024 roku Odwołujący Asseco Poland spółka akcyjna z siedzibą w Rzeszowie działając na podstawie ustawy z dnia 11 września 2019 r. Prawo zamówień publicznych (tj. Dz.U. z 2023 r. poz. 1610 ze zm.; dalej „PZP” lub „ustawa”) wniósł odwołanie od niezgodnych z przepisami Ustawy czynności Zamawiającego, polegających n​ a sformułowaniu Specyfikacji Warunków Zamówienia (dalej „SWZ”) z naruszeniem przepisów prawa. Postanowienia SWZ objęte odwołaniem wskazano szczegółowo poniżej, osobno w każdym zarzucie.

Odwołujący zarzuciła Zamawiającemu:

1. zarzut I: TOM I IDW - w Formularzu 3.6 „Wykaz usług” - Naruszenie art. 128 ust. 5 PZP w związku z art. 112 ust. 1 PZP – przez brak wymogu określenia w Formularzu 3.6 „Wykaz usług” podmiotu, który jest w posiadaniu informacji oraz dokumentów istotnych dla oceny spełniania przez wykonawcę warunków udziału w postępowaniu oraz kryteriów selekcji; 2)zarzut II: TOM II SWZ – PROJEKTOWANE POSTANOWIENIA UMOWY (PPU) ​ §7 „Prawa własności intelektualnej” - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP w zw. z art. 387 KC przez opisanie warunków udzielenia licencji w sposób uniemożliwiający realizację wymagań w zakresie licencji na oprogramowanie COTS ​ i dokumentację, co skutkuje niemożnością przygotowania oferty; 3)Zarzut III: TOM II SW Z – PROJEKTOWANE POSTANOW IENIA UMOW Y (dalej: PPU) §8 ust. 4 – Wykonanie zastępcze – Naruszenie art. 99 ust. 1 w związku z art. 16 PZP pkt 1 i 3 PZP w zw. z art. 3531 KC w zw. z art. 8 ust. 1 PZP przez opisanie przedmiotu zamówienia w sposób niejednoznaczny i niewyczerpujący, oraz w sposób całkowicie otwarty, co prowadzi do uznania PPU w niezmienionym kształcie ​ za naruszające zasady uczciwej konkurencji oraz równego traktowania stron stosunku zobowiązaniowego oraz uniemożliwiający skalkulowanie ceny oferty; 4)Zarzut IV: TOM III OPZ – Definicje –Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP - przez opisanie przedmiotu zamówienia w zakresie dotyczących zobowiązań Wykonawcy w sposób otwarty, niedookreślony, uniemożliwiający skalkulowanie oferty przez Wykonawcę. -Zarzut IVA – Definicja Awarii, -Zarzut IV B – Definicja Systemu, -Zarzut IV C – Definicja Błędu; 5)Zarzut V: TOM III SWZ – OPZ punkt 3.6.20 - Naruszenie art. 99 ust. 1 w związku ​ z art. 16 PZP – przez opisanie przedmiotu zamówienia w sposób niemożliwy ​ do zrealizowania zadania, co skutkuje niemożnością przygotowania oferty; 6)Zarzut VI: TOM III SW Z – OPZ pkt. 4.2.6 – Naruszenie art. 99 ust. 1 w związku z art. 16 PZP przez opisanie przedmiotu zamówienia w sposób niejednoznaczny ​ i niewyczerpujący, uniemożliwiający realizacje zobowiązań umownych wykonawcy ​ w zakresie „Autoryzacja zmian Systemu wykonanych przez Zamawiającego lub podmioty trzecie”, co skutkuje niemożliwością skalkulowanie ceny oferty -Zarzut VIA, -Zarzut VIB;
2. Zarzut VII: TOM III SWZ – OPZ punkt 5.1.5) - Naruszenie art. 99 ust. 1 w związku ​ z art. 16 PZP – przez opisanie przedmiotu zamówienia przez powiązanie Niedostępności Systemu z Błędem Blokującym, co powoduje, że przedmiot zamówienia w zakresie dotyczącym zobowiązań Wykonawcy jest opisany w sposób otwarty, niedookreślony, uniemożliwiający skalkulowanie oferty przez Wykonawcę; 8)Zarzut VIII: TOM III SW Z – OPZ punkt 5.2.4 4) - Naruszenie art. 99 ust. 1 w związku z art. 16 PZP – przez opisanie przedmiotu zamówienia w sposób niemożliwy ​ do oszacowania kosztu realizacji oraz w sposób niemożliwy do realizacji; 9)Zarzut IX: TOM III SWZ – OPZ punkt 5.2.5 - Naruszenie art. 99 ust. 1 w związku ​ z art. 16 PZP przez opisanie przedmiotu zamówienia w sposób niemożliwy ​ do oszacowania kosztu realizacji oraz w sposób niemożliwy do realizacji; 10)Zarzut X: Tom III SWZ – OPZ punkt 5.2.7 - Naruszenie art. 99 ust. 1 w związku ​ z art. 16 PZP przez opisanie przedmiotu zamówienia w sposób niejasny ​ i uniemożliwiający przygotowanie oferty, co skutkuje niemożnością przygotowania oferty;
3. Zarzut XI: TOM III SWZ – OPZ punkt 5.3.3 - Naruszenie art. 99 ust. 1 i 4 w zw. ​ z art. 16 PZP – przez opisanie przedmiotu zamówienia w sposób niemożliwy ​ do oszacowania kosztów realizacji wymagania w zakresie kompleksowego wsparcia, w tym udzielania konsultacji, co skutkuje niemożnością przygotowania oferty;
4. Zarzut XII: TOM III SW Z – OPZ punkt 5.3.5 - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP – przez sporządzenie dokumentacji postępowania w sposób niejasny, niepełny i ostatecznie uniemożliwiający oszacowanie kosztu realizacji wymagania dotyczącego spotkań (stacjonarnych lub zdalnych); 13)Zarzut XIII: TOM III SWZ - OPZ punkt 5.4.1. 3) - Naruszenie art. 99 ust. 1 i 4 w zw. ​ z art. 16 PZP przez opisanie przedmiotu zamówienia w sposób niemożliwy ​ do oszacowania kosztu realizacji; 14)Zarzut XIV: TOM III SWZ - OPZ punkt 5.4.1 6) - Naruszenie art. 99 ust. 1 i 4 w zw. ​ z art. 16 PZP – poprzez opisanie przedmiotu zamówienia w sposób niemożliwy ​ do oszacowania kosztu realizacji wymagania dotyczącego dostosowania Systemu ​ ze względu na zmiany w Platformie Sprzętowo-Programowej; 15)Zarzut XV: TOM III SWZ – OPZ punkt 5.4.1 7) - Naruszenie art. 99 ust. 1 i 4 w zw. ​ z art. 16 PZP - przez opisanie przedmiotu zamówienia w sposób otwarty ​ i uniemożliwiający oszacowanie kosztu realizacji wymagania dotyczącego przeniesienia Systemu na nowe bloki architektoniczne; 16)Zarzut: XVI: TOM III SW Z – OPZ pkt. 5.4.1 9) oraz pkt.5.4.3 - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP w zw. z art. 387 KC - Opisanie przedmiotu zamówienia ​ w sposób narzucający przez Zamawiającego terminy dokonywania zmian ​ w systemie, co uniemożliwia skalkulowanie ceny oferty na etapie ofertowania, ​ a na etapie realizacji umowy - wykonanie zobowiązania; 17)Zarzut: XVII: TOM III SW Z – OPZ – Załącznik nr 2 do OPZ Rozwój Zdefiniowany oraz TOM I SW Z – IDW Formularz cenowy nr 2.2. - Naruszenie art. art. 431 ust. 1 pkt 1 PZP przez nieprawidłowe określenie terminów wykonania zadań w datach kalendarzowych zamiast w dniach, tygodniach, miesiącach lub latach; 18)Zarzut XVIII: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 3 (SZPROT_W FOG_4) - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP – przez opisanie przedmiotu zamówienia w sposób uniemożliwiający oszacowanie kosztu realizacji wymagania dotyczącego dostosowania Systemu do korzystania z serwera aplikacji WildFly w najnowszej dostępnej wersji wolnej od podatności luk bezpieczeństwa;
5. Zarzut XIX: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 6 (SZPROT_W FOG_7) - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP –przez opisanie przedmiotu zamówienia w sposób niemożliwy ​ do oszacowania kosztu realizacji wymagania dotyczącego Rozbudowy bazy relacyjnej SZPROT oraz wytworzenia mechanizmu utrzymującego spójność danych pomiędzy bazą danych Systemu SZPROT a bazą danych PDR PL/UE ​ z wykorzystaniem istniejących usług PDR PL/UE; 20)Zarzut XX: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 9 (SZPROT_WFED_36_A) - Naruszenie art. 99 ust. 1 i 4 ​ w zw. z art. 16 PZP – przez opisanie przedmiotu zamówienia w sposób niemożliwy do oszacowania kosztu realizacji wymagania dotyczącego modyfikacji Komponentów Komunikacyjnych Systemu SZPROT na PUESC (wniosków o wydanie decyzji, pozwoleń celnych), modyfikacji procesów obsługi tych wniosków, modyfikacja rejestrów pozwoleń, formularzy oraz szablonów wydruków w Systemie, jak również odnoszone w treści punktu 9 zadania: SZPROT_W FED_3, SZPROT_W FOG_12 , SZPROT_W FOG_44 (zał. 2 do OPZ odpowiednio punkty: 48, 14, 123); 21)Zarzut XXI: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkty 9, 10, 11 (SZPROT_W FED_36_A, SZPROT_W FED_36_B, SZPROT_W FEK_32) - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP – przez opisanie przedmiotu zamówienia w sposób niemożliwy do zrealizowania, co skutkuje niemożnością przygotowania oferty; 22)Zarzut XXII: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 26 (SZPROT_WFOG_25) - Naruszenie art. 99 ust. 1 i 4 ​ w zw. z art. 16 PZP – przez opisanie przedmiotu zamówienia w sposób niemożliwy do oszacowania kosztu realizacji lub wręcz uznania jako niemożliwy do realizacji – ​ w zakresie wymagania dotyczącego budowy funkcjonalności konfigurowania treści prezentowanych ostrzeżeń; 23)Zarzut XXIII: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 32 (SZPROT_W FOG_31_B) - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP – przez opisanie przedmiotu zamówienia w sposób niemożliwy do oszacowania kosztu realizacji wymagania dotyczącego dostępności

cyfrowej Komponentów Komunikacyjnych Systemu; 24)Zarzut XXIV: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 51 (SZPROT_WFED_6) - Naruszenie art. 99 ust. 1 ​ i 4 w zw. z art. 16 PZP przez opisanie przedmiotu zamówienia w sposób niemożliwy do zrealizowania, co skutkuje niemożnością przygotowania oferty; 25)Zarzut XXV: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 55 (SZPROT_WFED_11) Naruszenie art. 99 ust. 1 ​ i 4 w zw. z art. 16 PZP – przez opisanie przedmiotu zamówienia w sposób wskazujący na realizację zadania dotyczącego funkcjonalności wskazania ze sprawy dokumentów do udostępniania użytkownikowi zewnętrznemu wyłącznie po stronie Systemu SZPROT, co skutkuje niemożnością przygotowania oferty; 26)Zarzut XXVI: TOM III SW Z OPZ - Załącznika nr 6 do OPZ (Zasady przeprowadzania testów) pkt 1 ppkt 12 przez opisanie przedmiotu zamówienia w zakresie Załącznika nr 6 do OPZ (Zasady przeprowadzania testów) pkt 1 ppkt 12 - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP przez opisanie w sposób niemożliwy do oszacowania kosztu realizacji oraz w niektórych przypadkach sposób niemożliwy do realizacji.

Odwołujący wyjaśnił, że szczegółowe wskazanie okoliczności faktycznych i prawnych (zgodnie z art. 516 ust. 1 pkt 10 PZP) zarzutów odwołania zostało dokonane poniżej, ​ uzasadnieniu niniejszego pisma, osobno w każdym zarzucie. w Odwołujący wniósł o: uwzględnienie odwołania i nakazanie Zamawiającemu dokonania modyfikacji SW Z w zakresie wskazanym w odwołaniu, przez zmianę kwestionowanych treści w sposób wskazany w odwołaniu – szczegółowo w każdym zarzucie. Obciążenie Zamawiającego kosztami postępowania odwoławczego, w tym kosztami zastępstwa procesowego przed Krajową Izbą Odwoławczą Odwołujący podał, ż e ma interes we wniesieniu niniejszego odwołania, gdyż wskazane w odwołaniu niezgodne z prawem postanowienia SWZ powodują, że Odwołujący n​ ie 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ń SW Z, 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 SW Z uniemożliwia Odwołującemu udział w postępowaniu. Ponadto – ​ wyniku w/w naruszeń przepisów Ustawy może dojść do następczego unieważnienia postępowania – co także w naraziłoby Odwołującego na poniesienie szkody.

Odwołujący przedstawił następujące uzasadnienie:

W dniu 7 czerwca 2024 roku Zamawiający opublikował dokumentację dla postępowania pn.: „Świadczenie usług rozwoju i utrzymania Systemu SZPROT”. Po analizie dokumentacji Postępowania Odwołujący stwierdził, że postanowienia dokumentacji naruszają przepisy PZP.

Nieprawidłowości dotyczą przede wszystkim naruszenia art. 99 ust. 1 PZP, który określa, ​ jaki sposób powinien zostać sporządzony opis przedmiotu zamówienia. Art. 99 ust. 1 PZP nakłada na zamawiającego w obowiązek opisania przedmiotu zamówienia w sposób jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń, uwzględnienia wszystkich wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty. Oznacza to, że na zamawiającym spoczywa obowiązek jasnego i precyzyjnego określenia przedmiotu zamówienia, a co za tym idzie – wykorzystania do jego opisania wystarczająco precyzyjnych, szczegółowych i zrozumiałych dla wykonawców z danej branży określeń. Wykonawcy składający ofertę muszą być świadomi rzeczywistego zakresu zamówienia, jego warunków oraz okoliczności wpływających na jego realizację. ​ a podstawie opisu przedmiotu zamówienia dokonują obliczenia ceny za wykonanie zamówienia.

N Na Zamawiającym ciąży obowiązek takiego opracowania dokumentacji przetargowej, a​ by wykonawca nie był obciążany konsekwencjami jej nienależytego sporządzenia, ​ szczególności opis zamówienia nie powinien być ogólny, szacunkowy i niedookreślony, wzajemnie niespójny, w przenoszący na wykonawców składających ofertę ciężar jego dookreślenia. Zamawiający nie może pozostawić domyślności wykonawcy określenia zakresu przedmiotu zamówienia, ponieważ prowadzi to do składania ofert nieporównywalnych co do rozmiarów świadczeń i ich wyceny. Takie działanie Zamawiającego mogłoby być uznane za nadużycie praw podmiotowych mających antykonkurencyjny charakter. Z nieprecyzyjnych zapisów zamawiający nie może wywodzić ujemnych skutków dla wykonawców, a wątpliwości w tym zakresie muszą być tłumaczone n​ a ich korzyść (tak wyr. KIO z 27.2.2012 r., KIO 218/12,). Opis przedmiotu zamówienia powinien więc uwzględniać wszystkie wymagania i okoliczności mogące mieć wpływ n​ a sporządzenie oferty, w tym także na umożliwienie oszacowania ceny oferty w stosunku do oznaczonego przedmiotu zamówienia (tak wyr. KIO z 25.11.2015 r., KIO 2479/15).

Krajowa Izba Odwoławcza wskazała, że „opis przedmiotu zamówienia ma mieć charakter wyczerpujący, co oznacza m.in., że powinien on umożliwiać wykonawcom prawidłową ocenę wszelkich możliwych ryzyk, jakie mogą zaistnieć przy wykonywaniu przedmiotu umowy. ​Nie jest możliwe realne oszacowanie kosztu ryzyka, którego wykonawca nie ma możliwości zidentyfikować z uwagi na brak odpowiedniej i wyczerpującej informacji w SW Z. Nie opisując w sposób odpowiedni przedmiotu zamówienia, Zamawiający sam naraża się na negatywne dla niego konsekwencje faktyczne i prawne – począwszy od nieporównywalności ofert, zawyżenia cen ofertowych wobec braku możliwości dokładnego oszacowania ryzyka, przez problemy i spory na etapie realizacji zamówienia, aż do niekorzystnego dla Zamawiającego wyniku postępowań sądowych” (wyrok z 5.3.2021 r., KIO 89/21).

Dla naruszenia przepisów PZP innych niż art. 99 ust. 1 PZP uzasadnienie zostanie wskazane w poszczególnych zarzutach.

Ad. 1 Zarzut I: TOM I IDW - w Formularzu 3.6 „Wykaz usług” -Naruszenie art. 128 ust. 5 PZP w związku z art. 112 ust. 1 PZP – poprzez brak wymogu określenia w Formularzu 3.6 „Wykaz usług” podmiotu, który jest w posiadaniu

informacji oraz dokumentów istotnych dla oceny spełniania przez wykonawcę warunków udziału w postępowaniu oraz kryteriów selekcji.

W Formularzu 3.6. „Wykaz usług” Zamawiający wymaga podania podmiotu, na rzecz którego wykonana była usługa, nie określając, co należy rozumieć pod pojęciem takiego podmiotu – w szczególności nie jest wskazane, czy należy podać rzeczywistego beneficjenta danej usługi, czy też wystarczające jest podanie podmiotu, z którym zawarta jest umowa, nawet ​ sytuacji, w której strona umowy nie jest użytkownikiem systemu, nie korzysta z systemu. w Odwołujący podał, że postanowienie to jest niewystarczające wobec praktyki, jaka ostatnio upowszechnia się w przedstawianiu wiedzy i doświadczenia. Otóż wykonawcy w wykazach usług nie podają rzeczywistych beneficjentów, rzeczywistych użytkowników systemów – ale podają podmiot pośredniczący, który nie korzysta z systemu – a zatem nie może potwierdzić prawidłowości jego wykonania, ani też jego rzeczywistych cech architektonicznych (wykorzystywanych technologii) czy parametrów eksploatacyjnych (np. liczby użytkowników).

Co więcej – w ramach wskazanej praktyki wskazywane usługi referencyjne są realizowane przez spółki z grupy kapitałowej danego wykonawcy – a zatem pozyskiwanie jakichkolwiek informacji o projekcie na mocy art. 128 ust. 5 PZP od takiego podmiotu jest obarczone brakiem obiektywności.

Zdaniem Odwołującego w pozycji „Podmiot, na rzecz którego wykonana była usługa” należy zawsze wpisać rzeczywistego użytkownika systemu, a nie podmiot pośredniczący, u którego system nie został wdrożony. Należy bowiem mieć na uwadze sytuację, w której podmiot składający ofertę: a)ma zawartą umowę z Podmiotem 1 – który nie spełnia wymagań SWZ; b)wykonuje projekt w rzeczywistości na rzecz Podmiotu 2 – który spełnia wymagania SWZ.

Przez spełnienie wymagań SWZ w stanie faktycznym niniejszego postępowania można wskazać:

1umożliwiającym jednoczesne korzystanie z systemu informatycznego przez minimum 500 użytkowników.

W przypadku, gdy w/w Podmiot 1 nie ma 500 użytkowników – oczywistym jest, że Podmiot 1 nie spełnia wymagań SW Z, zaś usługi świadczone na rzecz Podmiotu 1 nie spełniają wymagań SW Z. Tym samym nie można skutecznie wykazywać spełniania warunków udziału w postępowaniu przez umowę zawartą z Podmiotem 1.

Jeśli zaś dany wykonawca twierdzi, że rzeczywistym odbiorcą systemu jest Podmiot 2, który spełnia warunek 500 użytkowników – to w wykazie usług od razu powinna być wskazana taka okoliczność i taki rzeczywisty odbiorca systemu powinien być wskazany.

Odwołujący zidentyfikował w praktyce zamówień publicznych wskazywanie jako projekty referencyjne – projekty wykonane w ramach podwykonawstwa, bardzo często w ramach umów zawieranych w tej samej grupie kapitałowej. Jako formalny podmiot, na rzecz którego wykonano usługę wykonawcy wskazują spółkę z grupy kapitałowej, która nie jest użytkownikiem systemu, która nie posiada odpowiedniej liczby użytkowników. ​A jednocześnie – ukrywany jest przed zamawiającymi rzeczywisty beneficjent, rzeczywisty użytkownik systemu.

Tym samym w Wykazie usług jedynie formalnie wykazane jest spełniania warunków udziału. A to dlatego, że podawane informacje są całkowicie nieweryfikowalne, a wręcz nieprzydatne do stwierdzenia, czy spełniony jest warunek udziału.

Ustawa PZP nakazuje badanie relacji zamawiający (podmiot zlecający) – wykonawca (podmiot realizujący), jako relacji rzeczywistej i opisującej realną wiedzę i kompetencje nabyte przez dany podmiot. Właśnie w celu ustalenia tej realnej wiedzy i kompetencji nabytych przez dany podmiot konieczne jest ustalenie, czy w ogóle istnieje użytkownik rzeczywisty, który tak użytkuje system referencyjny – że spełnione są warunki udziału, ​ e wskazanym przykładzie: 500 użytkowników. W sytuacji, gdy Podmiot 1 – nie mając 500 użytkowników – nie może być w wskazanie tylko Podmiotu 1 jako gwaranta d​ la wystarczającego potwierdzenia, że dany wykonawca zdobył realną wiedzę i​ kompetencje.

Podanie takich informacji umożliwia Zamawiającemu skorzystanie z normy art. 128 ust. 5 PZP. Z kolei – brak takich informacji uniemożliwia rzeczywistą weryfikację spełniania warunku udziału w postępowaniu.

Żądanie:

Wobec powyższego Odwołujący wniósł o nakazanie Zamawiającemu dodanie w Formularzu 3.6. komentarza pod tabelą:

„W sytuacji, w której podmiot, na rzecz którego wykonano usługę (strona umowy) nie jest podmiotem, który rzeczywiście użytkuje system informatyczny w kolumnie „Podmiot, na rzecz którego wykonana była usługa” należy podać dane dla 2 podmiotów: a) Stronę umowy; b) Podmiot rzeczywisty użytkujący system – posiadający minimum 500 użytkowników.”

Ad. 2 Zarzut: II: TOM II SWZ – PROJEKTOWANE POSTANOWIENIA UMOWY (PPU) §7 „Prawa własności intelektualnej” - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP w zw. z art. 387 KC poprzez opisanie warunków udzielenia licencji w sposób uniemożliwiający realizację wymagań w zakresie licencji na oprogramowanie COTS i dokumentację, co skutkuje niemożnością przygotowania oferty.

TOM II SW Z §7 Prawa własności intelektualnej zawiera m.in. wskazane niżej ustępy regulujące warunki na jakich mają być udzielane licencje na oprogramowanie COTS i​ dokumentację. Zawierają one szczegółowe wymagania i warunki na jakich mają zostać udzielone licencje na oprogramowanie COTS i dokumentację. Poniżej wskazane zostały ustępy zawierające warunki licencyjne z wyróżnieniem kwestionowanych zapisów.

1. W ramach wynagrodzenia określonego w § 5 ust. 1 Umowy, Wykonawca zobowiązuje się do dostarczenia we wskazanym przez Wykonawcę zakresie Oprogramowanie COTS, a​ także dostarczyć jego dokumentację oraz udziela lub zapewnia udzielenie nieodpłatnej, bezterminowej, niewyłącznej, nieograniczonej terytorialnie i przenaszalnej licencji n​ a poniższych warunkach, z uwzględnieniem treści Umowy.
2. Licencja na Oprogramowanie COTS obejmuje trwałe lub czasowe zwielokrotnianie Oprogramowania COTS w całości

lub w części, jakimikolwiek środkami i w jakiejkolwiek formie, w tym zwielokrotnianie dokonywane podczas wprowadzania, wyświetlania, stosowania, przekazywania lub przechowywania Oprogramowania COTS, w tym także utrwalanie i zwielokrotnianie dowolną techniką, w tym techniką zapisu magnetycznego lub techniką cyfrową, taką jak zapis na płycie CD, DVD, Blu-ray, urządzeniu z pamięcią flash lub jakimkolwiek innym nośniku pamięci,tłumaczenie; przystosowywanie (customizacja), wprowadzanie zmian układu lub jakichkolwiek innych zmian, z zachowaniem wszystkich, określonych w niniejszym ustępie pól eksploatacji na części zmienione ​ ww. sposób. w 1 4 . Tłumaczenie, przystosowywanie, zmiany układu lub wprowadzanie jakichkolwiek innych zmian w Oprogramowaniu COTS może być dokonane przez Zamawiającego lub osobę trzecią działającą na jego rzecz.

1. Licencja na dokumentację dotyczącą Oprogramowania COTS obejmuje:
2. w zakresie utrwalania i zwielokrotniania – wytwarzanie dowolną techniką egzemplarzy, w tym techniką drukarską, reprograficzną, zapisu magnetycznego oraz techniką cyfrową,
3. w zakresie obrotu oryginałem albo egzemplarzami, na których ją utrwalono – wprowadzanie do obrotu, użyczenie lub najem oryginału albo egzemplarza,
4. w zakresie rozpowszechniania w sposób inny niż określony powyżej – publiczne wykonanie, wystawienie, wyświetlenie, odtworzenie oraz nadawanie i reemitowanie, a​ także publiczne udostępnianie dokumentacji w taki sposób, aby każdy mógł mieć ​ o niej dostęp w miejscu i w czasie przez siebie wybranym. d (…)
5. Zamawiający otrzymuje ciągłe, stałe i niewypowiadalne prawo do korzystania z​ Oprogramowania COTS i związanej z nim dokumentacji zasadach określonych ​ niniejszym paragrafie. W przypadku gdyby postanowienie o niewypowiadalności licencji przewidziane w zdaniu w poprzedzającym okazało się nieskuteczne lub nieważne, Strony uzgadniają 10-letni (słownie: dziesięcioletni) termin jej wypowiedzenia ze skutkiem ​ a koniec roku kalendarzowego, z zastrzeżeniem, iż Wykonawca zobowiązuje się n ​ ie korzystać z uprawnienia do wypowiedzenia licencji z wyjątkiem przypadków, n ​ których Zamawiający przekroczy warunki udzielonej licencji i naruszy autorskie prawa majątkowe w przysługujące Wykonawcy oraz nie zaniecha naruszenia mimo wezwania Wykonawcy i wyznaczenia mu w tym celu odpowiedniego terminu, ​ ie krótszego niż 30 dni. n (…)
6. Wykonawca dostarczy wraz z Oprogramowaniem COTScertyfikaty autentyczności, klucze instalacyjne oraz inne dokumenty i zabezpieczenia. (…)
7. W chwili przekazania lub udostępnienia Zamawiającemu przez Wykonawcę jakiegokolwiek nośnika zawierającego utwór objęty licencją, Wykonawca wydaje i przenosi na Zamawiającego prawo własności takiego nośnika. Dokumentacja zostanie wydana Zamawiającemu w postaci elektronicznej i papierowej. Jeżeli w okresie trwania Umowy zostanie stwierdzona wadliwość materiałowa lub wadliwość zapisu utworu na nośniku, o​ którym mowa w zdaniu poprzedzającym, Wykonawca bez odrębnego wynagrodzenia, wymieni niezwłocznie wadliwy nośnik na nośnik wolny od wad. (…)
8. Wykonawca zapewnia, że licencje na korzystanie z Oprogramowania COTS nie będą zawierały ograniczeń polegających na tym, że Oprogramowanie może być używane wyłącznie na jednej dedykowanej platformie sprzętowej lub może być wdrażane wyłącznie przez określony podmiot lub grupę podmiotów. (…)
9. W związku ze statusem prawnym Zamawiającego (państwowa jednostka budżetowa), dla uniknięcia wszelkich wątpliwości Strony potwierdzają, że prawa przyznane Zamawiającemu na podstawie Umowy, w tym OPZ,w tym w szczególności autorskie prawa majątkowe i uprawnienia wynikające z udzielonych licencji, mogą być wykonywane przez Ministra Finansów, jednostki organizacyjne podległe i​ nadzorowane przez Ministra Finansów.

Jednocześnie podkreślenia wymaga fakt, iż zawarta w punkcie 1. TOMU III SW Z – OPZ Definicja oprogramowania COTS tj.:

Oprogramowanie typu Commercial of the Shelf Software – powszechnie dostępne oprogramowanie standardowe wytwarzane seryjnie, dostarczane w formie gotowego zamkniętego produktu, inne niż Oprogramowanie dedykowane albo FOSS. stoi w bezpośredniej sprzeczności z warunkami licencyjnymi określonymi w §7 PPU.

Jak wynika z w/w definicji Oprogramowanie COTS to oprogramowanie, co do którego prawa autorskie i majątkowa przysługują jego posiadaczom/producentom. Udzielają oni zgody n​ a korzystanie z Oprogramowania COTS na warunkach przez nich ustalonych i swobodnie kształtowanych – licencja/warunki licencyjne.

Dodatkowo idąc w ślad za definicją skonstruowaną przez Zamawiającego oprogramowanie COTS to oprogramowanie posiadające następujące cechy: ·Powszechnie dostępne ·Standardowe ·wytwarzane seryjnie ·Dostarczane w formie gotowego produktu Jak widać z przytoczonej definicji oprogramowanie COTS to produkt gotowy licencjonowany na standardowych

warunkach.

Z kolei regulacja §7 w zakresie opisującym warunki licencji, jaka ma zostać udzielona ​ przypadku dostarczenia oprogramowania COTS, stoi w zupełnej sprzeczności do definicji Oprogramowania COTS. w

Zgodnie z treścią § 7 Wykonawca ma zagwarantować Licencję obejmującą m.in.: ·nieograniczoną terytorialnie ·przenaszalną ·dającą możliwość Zamawiającego wprowadzania jakichkolwiek zmian układu lub jakichkolwiek innych zmian ·umożliwiającą tłumaczenie, przystosowywanie, ·dającą niewypowiadalne prawo do korzystania z oprogramowania COTS ​ i dokumentacji ewentualnie 10 letni termin wypowiedzenia w przypadku ograniczony jedynie do przypadków naruszenia autorskich praw majątkowych ·dającą prawa do używania oprogramowania przez Ministra Finansów, jednostki organizacyjne i jedynie nadzorowane przez Ministra Finansów Przedstawione powyżej zapisy wymagań co do zakresu licencji skutkują brakiem możliwości dostarczenia oprogramowania COTS przez wykonawców, którzy nie są producentami danego oprogramowania COTS - a tym samym czynią przedmiotowe świadczenie niemożliwym do realizacji. Wynika to z faktu, iż Wykonawca nie ma wpływu na warunki udzielanej licencji, gdyż nie jest on producentem oprogramowania standardowego a tym samym nie należą do niego prawa autorskie stanowiące podstawę do udzielania licencji. Wykonawca chcąc dostarczyć oprogramowanie COTS nabywa licencje od producentów, którzy to będąc właścicielami praw autorskich decydują, na jakich warunkach udzielają licencji. Wykonawca nie ma wpływu na warunki licencji oprogramowania COTS. W PPU mamy natomiast do czynienia z bardzo szczegółowymi i wyśrubowanymi warunkami licencji, które to narzuca Zamawiający. Zdaniem Odwołującego uzyskanie licencji na zasadach określonych w §7 jest niemożliwe do realizacji.

Takie warunki licencji na Oprogramowanie COTS są niespotykane w postepowaniach o​ udzielenie zamówienia publicznego. Wszyscy profesjonalni zamawiający publiczni doskonale zdają sobie sprawę, że większość wykonawców nie jest po prostu w stanie dostarczyć licencji na Oprogramowanie COTS na takich warunkach.

W przypadku, gdy do realizacji przedmiotu zamówienia konieczne jest wykorzystanie oprogramowanie COTS – wykonawca nie byłby w stanie zagwarantować warunków licencji opisanych w §7 PPU odnoszącym się do Oprogramowania COTS. Oprogramowanie COTS jako standardowe oprogramowanie sprzedawane jest bowiem przez producentów do wielu odbiorców na standardowych warunkach licencyjnych producenta. Producenci takiego oprogramowania nie dopuszczają możliwości jego przystosowywania, wprowadzenia poprawek, jakichkolwiek (dowolnych) zmian. Wykonawca nie ma wpływu na zakres udzielanej licencji przez jego producenta. Producent oprogramowania COTS ma całkowitą swobodę w zakresie definiowania warunków użytkowania oprogramowania COTS.

Skoro n​ a przykład producent Oprogramowania COTS nie dopuszcza prawa do zmian przez licencjobiorcę, to niemożliwym jest, aby Wykonawca mógł zagwarantować, że Zamawiający będzie miał prawo do swobodnego rozwoju Systemu przez podmioty nie posiadające autorskich praw majątkowych do takiego oprogramowania.

Dodatkowo należy wskazać, że zgodnie z § 7 ust. 17 Projektowanych Postanowień Umowy: “Z amawiający otrzymuje ciągłe, stałe i niewypowiadalne prawo do korzystania z​ Oprogramowania COTS i związanej z nim dokumentacji zasadach określonych ​ niniejszym paragrafie. “ w Wskazać należy, że Zamawiający nakłada na Wykonawcę zobowiązanie niemożliwe d​ o wykonania. Oprogramowanie gotowe to bardzo często oprogramowanie pochodzące o​ d dużych dostawców IT (Vendorów), którzy ustalają zasady licencyjne takie same d​ la każdego z klientów. Żaden z Wykonawców nie ma wpływu na warunki licencyjne dużych podmiotów zewnętrznych w szczególności takich jak Microsoft.

Wymaganie, zgodnie z którym Wykonawca zapewni, że “producent Oprogramowania gotowego nie będzie korzystał z ustawowego uprawnienia do wypowiedzenia umowy licencyjnej, ani prawa do odstąpienia od umowy.” jest zobowiązaniem niemożliwym d​ o wykonania.

Warunki licencyjne większości producentów oprogramowania gotowego nie zawierają takich postanowień, a tacy producenci sprzedają software wraz z gotowymi warunkami licencyjnymi i Wykonawca jako nabywca takiego oprogramowania, może albo takie oprogramowania nabyć, albo nie zdecydować się na zakup.

Wykonawca w odniesieniu do oprogramowania gotowego w większości przypadków nabywa je “as is” czyli w takim zakresie faktycznym i prawnym jak oferuje producent, bez możliwości negocjacji.

Żądanie:

Mając powyższe na uwadze Odwołujący wniósł o wykreślenie postanowień zawartych w § 7 ust. 13, 14, 15, 16, 17, 18, 20, 21, 23, 24, 25, 29, 30 i zastąpienia ich zapisem, że warunki licencji na Oprogramowanie COTS będą zgodne z warunkami licencji producenta dostarczanego oprogramowania COTS.

Ad.3 Zarzut III: TOM II SWZ – PROJEKTOWANE POSTANOWIENIA UMOWY (dalej: PPU) §8 ust. 4 – Wykonanie zastępcze – Naruszenie art. 99 ust. 1 w związku z art. 16 PZP pkt 1 i 3 PZP w zw. z art. 3531 KC w zw. z art. 8 ust. 1 PZP poprzez opisanie przedmiotu zamówienia w sposób niejednoznaczny i niewyczerpujący, oraz w sposób całkowicie otwarty, co prowadzi do uznania PPU w niezmienionym kształcie za naruszające zasady uczciwej konkurencji oraz równego traktowania stron stosunku zobowiązaniowego oraz uniemożliwiający skalkulowanie ceny.

W §8 ust. 4 PPU Zamawiający wskazuje: “4. Strony zgodnie ustalają, że Zamawiający, bez konieczności uzyskania odrębnego orzeczenia sądu, ma prawo zlecić na koszt i ryzyko Wykonawcy, wykonanie osobie trzeciej w całości lub części obowiązków Wykonawcy wynikających z Przedmiotu Umowy w tym rękojmi i gwarancji, w przypadku niewywiązania się Wykonawcy w całości lub części z tych zobowiązań, po uprzednim wezwaniu Wykonawcy z wyznaczeniem Wykonawcy dodatkowego terminu (umowne wykonanie zastępcze). Zamawiający w takim przypadku zachowuje prawo do naliczenia kar umownych, o których mowa w § 6 Umowy, oraz ma prawo potrącenia należności z tytułu wykonania zastępczego z wynagrodzenia za wykonanie przedmiotu Umowy oraz zabezpieczenia należytego wykonania Umowy.”

Z powyższych postanowień jednoznacznie wynika, że w przypadku uznania przez Zamawiającego, że Wykonawca nie wywiązuje się z jakiejkolwiek części jakiegokolwiek zobowiązania umownego - Zamawiający ma prawo zlecić umowne wykonanie zastępcze – zgodnie z zasada wykonania zastępczego wszystkie koszty w takim przypadku zobowiązany pokryć jest Wykonawca.

Jednocześnie Zamawiający w żaden sposób nie precyzuje szczegółowych warunków, kiedy wykonanie zastępcze może być zastosowane. Zamawiają wskazuje, że może to mieć miejsce w przypadku niewywiązania się Wykonawcy z części lub całości jakiegokolwiek zobowiązania. Mamy wiec do czynienia z sytuacją, w której Zamawiający całkowicie swobodnie, w oparciu o własną subiektywną ocenę decyduje, kiedy stosować omawianą sankcję. Mało tego, nie jest w żaden sposób określone, jak duża część Umowy może zostać niezrealizowana, aby wykonanie zastępcze zostało wdrożone. Dodatkowo PPU nie regulują kwestii, iż wykonanie zastępcze może zostać zastosowanie jedynie w zakresie odpowiadającym zakresowi niewykonanych zobowiązań. W skrajnym przypadku, g​ dy Wykonawca nie zrealizuje drobnego wniosku zmiany, Zamawiający może zlecić wykonanie zastępcze w znacznie szerszym zakresie. Bardzo mocno należy podkreślić, i​ ż wykonanie zastępcze odbywa się na koszt i ryzyko Wykonawcy bez konieczności odrębnego orzeczenia sądu. Tym samym Zamawiający pozostawia sobie całkowitą swobodę ustalenia kosztu wykonania zastępczego na co Wykonawca w świetle przedmiotowego ustępu nie ma żadnego wpływu, koszt realizacji wykonania zastępczego nie jest z nim uzgadniany ani konsultowany.

Tak szerokie określenie zakresu wykonania zastępczego skutkuje tym, że Zamawiający może zakres przedmiotowej umowy zlecić dowolnemu podmiotowi trzeciemu za dowolne wynagrodzenie. Taka regulacja stanowi obejście przez Zamawiającego obowiązku stosowania Prawa zamówień publicznych.

Kolejną sankcją grożącą Wykonawcy równolegle do stosowania wykonania zastępczego jest prawo Zamawiającego do zastosowania kar umownych. Wynika z tego, że Wykonawca n​ ie dość, że zobowiązany byłby zapłacić wynagrodzenie, jakie otrzyma podmiot trzeci (dowolne wynagrodzenie, w tym wielokrotnie wyższe, niż wynagrodzenie, jakie przysługiwałoby Wykonawcy), to jeszcze zobowiązany byłby zapłacić karę umowną. ​W ten to sposób Zamawiający może zrealizować przedmiot zamówienia na koszt wykonawcy, a jeszcze uzyskać dodatkowy przychód w postaci kar umownych.

Mając na uwadze regulacje zawarte w wskazanym ustępie PPU Wykonawca jest obciążany ryzykiem, którego skali i wartości nie jest w stanie skalkulować na etapie przygotowania oferty. Ponadto, skoro Zamawiający zastrzega sobie prawo naliczania wysokich kar umownych za uchybienia w zakresie wykonania przedmiotu umowy, obciążanie Wykonawcy dodatkowymi sankcjami jest całkowicie nieuzasadnione i prowadzi wprost do podwójnego karania, którego wysokość jest niemożliwa do oszacowania.

Żądanie:

Mając powyższe na uwadze Odwołujący wnosi o wykreślenie z §8 ustępu 4 PPU.

Ad.4 Zarzut IV: TOM III OPZ – Definicje –Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP - poprzez opisanie przedmiotu zamówienia w zakresie dotyczących zobowiązań Wykonawcy w sposób otwarty, niedookreślony, uniemożliwiający skalkulowanie oferty przez Wykonawcę.

Zarzut IVA. Definicja Awarii 1.Obecne w TOM III SWZ - OPZ w definicjach zawarte jest brzmienie definicji Awarii:

„Błąd powodujący całkowite unieruchomienie Systemu lub jednego z jego Komponentów lub brak dostępu do co najmniej jednego z jego Komponentów. Błąd ten powoduje brak możliwości pobierania lub przekazywania danych lub uniemożliwia pracę użytkowników. Przejawem wystąpienia Awarii może być w szczególności zawieszanie się aplikacji, samoczynne zamykanie się aplikacji niezgodne z Dokumentacją, brak możliwości obsługi procesów biznesowych, wadliwy zapis danych, brak możliwości korzystania z danych zapisanych w bazach danych, niewłaściwy odczyt danych.

Jako Awaria traktowane jest również obniżenie parametru wydajnościowego Systemu o​ więcej niż 50% w stosunku do poziomu określonego przez Zamawiającego ​ wymaganiach wydajnościowych, o których mowa w Załączniku nr 1 do OPZ.” w Jak wynika z powyższej treści SWZ dla pojęcia Awaria Zamawiający wskazuje otwarte i​ nieostre przesłanki uznania danej sytuacji za Awarię. Otóż zgodnie z definicją Zamawiającego Awarią jest dosłownie wszystko: brak możliwości pobierania lub przekazywania danych, uniemożliwienie pracy użytkowników, zawieszanie się aplikacji, samoczynne zamykanie się aplikacji, brak możliwości obsługi procesów biznesowych, wadliwy zapis danych, brak możliwości korzystania z danych zapisanych w bazach danych.

W definicji Awarii nie powinno być zapisów, na podstawie których to Wykonawca jest zobowiązany usuwać błędy wynikające z błędów Platformy Sprzętowo-Programowej, która nie jest objęta przedmiotem Umowy i za którejutrzymanie odpowiada Zamawiający, a​ na której poprawność działania i dostępność Wykonawca nie ma żadnego wpływu. Należy podkreślić, że czas usunięcia Awarii Systemu spowodowanej błędem Platformy Sprzętowo-Programowej, pomimo, może być niewystarczający do usunięcia Awarii przez Wykonawcę (​ 4 godzin).

Odwołujący wskazał elementy definicji Awarii, które nie dotyczą zakresu obowiązków Wykonawcy: a)„brak możliwości pobierania/przekazywania danych” – mamy tu niesprecyzowane źródło problemu. Problem może wynikać z błędu Platformy Programowej, jak i z błędów Platformy Sprzętowo-Programowej, utrzymywanej przez Zamawiającego. W definicji n​ ie może znajdować się element zupełnie nieokreślony, gdyż jest to błąd definicyjny nazywany ignotum per ignotum; b)“uniemożliwienie pracy użytkowników” – nie wskazano liczby użytkowników, a zatem można przyjąć, że tylko 2, podczas gdy pozostałe 1998 użytkowników (przy wymogu 2000 jednoczesnych użytkowników) korzysta z Systemu prawidłowo.

Problem może wynikać zarówno z błędu Platformy Programowej jak i z np. infrastruktury, za którą odpowiada Zamawiający, np. jakości połączeń sieciowych; c)„zawieszanie się aplikacji” – problem może wynikać zarówno z błędu Platformy Programowej, jak i z np. infrastruktury,

za którą odpowiada Zamawiający, np. zły stan techniczny oprogramowania stacji użytkownika; d)„samoczynne zamykanie się aplikacji niezgodne z dokumentacją” - problem może wynikać zarówno z błędu Platformy Programowej jak i z np. infrastruktury, za którą odpowiada Zamawiający, np. niestabilna praca serwerów wirtualizacji; e)„brak możliwości obsługi procesów biznesowych” – ponieważ nie ma definicji oraz opisu procesów biznesowych, nie można stwierdzić, czy proces dotyczy konkretnej funkcji wykonywanej przez użytkownika czy wielu funkcjonalności wykonywanych jednocześnie, t​ ak więc nie ma możliwości określenia ryzyka częstotliwości takiej Awarii oraz jej przyczyny np. może być wynikiem błędów użytkownika f)„wadliwy zapis danych” – problem może wynikać zarówno z błędu Platformy Programowej jak i z np. infrastruktury, za którą odpowiada Zamawiający, np. awarie macierzy dyskowych; g)„brak możliwości korzystania z danych zapisanych w bazach danych, niewłaściwy odczyt danych” – problem może wynikać zarówno z błędu Platformy Programowej jak i z np. infrastruktury, za którą odpowiada Zamawiający, np. awarie macierzy dyskowych.

Odwołujący podał, że sama definicja Awarii jest stosowana przez różne jednostki organizacyjne Ministerstwa Finansów – nie tylko CIRF, ale także Izbę Skarbową w Krakowie w różnych postępowaniach dotyczących utrzymania systemów informatycznych użytkowanych przez Ministerstwo Finansów. Odwołujący w przypadku, gdy ma zamiar ofertować w danym postępowaniu – wnosi odwołania dotyczące wadliwej definicji Awarii.

Przykładowo można tutaj wskazać postępowania prowadzone przez Izbę Administracji Skarbowej w Krakowie na: a)„Rozbudowę, modernizację i rozwój Systemu ZEFIR 2, w tym dostosowanie funkcjonalności do zmian wynikających z obowiązujących przepisów prawa polskiego i unijnego oraz rozbudowę Systemu ZEFIR 2 o nowe funkcjonalności wynikające ​ ze zmian otoczenia, zmian organizacyjnych i prawnych, a także dla potrzeb współpracy z komponentami i systemami działającymi/budowanymi w resorcie finansów” nr postępowania: 1201-ILL-5.260.58.2020; b)„Rozwój, modernizacja i utrzymanie komponentów SISC w obszarze Obrotu Towarowego z Krajami Trzecimi i Przemieszczeń Akcyzowych” nr postępowania 1201-ILL-5.260.48.2020; c)„Świadczenie Usług Wsparcia Utrzymania Systemu ZEFIR2” nr postępowania” 1201-ILL-2.260.25.2024, w których analogiczne brzmiąca definicja była również przedmiotem odwołań a Zamawiający w każdym przypadku uwzględnił zarzuty Odwołującego, dokonując modyfikacji definicji Awarii zgodnie z żądaniem z odwołań przed terminem rozpoznania odwołań (co doprowadziło do umorzenia postępowania odwoławczego w tym zakresie). Przykładowo:

Żądanie:

Mając powyższe na uwadze Odwołujący wniósł o wykreślenie obecnej definicji Awarii i​ wpisanie w to miejsce:

Błąd uniemożliwiający działanie Systemu, spowodowany Błędami w Platformie Programowej, powodujący niefunkcjonowanie Systemu, uniemożliwiający pracę 50% zalogowanych użytkowników Systemu.

Jako Awaria traktowane jest również obniżenie parametru wydajnościowego Systemu o​ więcej niż 50% w stosunku do poziomu określonego przez Zamawiającego ​ wymaganiach wydajnościowych, o których mowa w Załączniku nr 1 do OPZ. w

Zarzut IVB. Definicja Systemu 1.Obecne w OPZ – Definicje – System Zamawiający wskazuje otwartą nieprecyzyjną definicję.:

„System - Komponent wchodzący w skład SISC. Jeśli System zbudowany jest z Modułów, przez pojęcie System rozumiemy cały System, jak i jego poszczególne Moduły oraz wszystkie interfejsy integracyjne. System obejmuje również dane przez niego przetwarzane, dokumentację z nim związaną oraz wszelkie powiązane instrukcje, procedury. Jeśli nie wskazano inaczej, należy rozumieć jako System Zintegrowanej Rejestracji Przedsiębiorców i Obsługi Wniosków „SZPROT”.

Odwołujący podał, że jest to bardzo ważna definicja, ponieważ o nią oparta jest cała Umowa. Jest użyta zarówno w

usługach, jakie mają być świadczone w ramach Umowy, jak i na niej oparte są definicje Błędów.

Jak wynika z powyższej treści SIW Z Zamawiający określił System w sposób całkowicie otwarty, nie tworząc właściwie definicji zgodnej z zasadami logiki. Definicja powinna składać się z: definiendum – czyli wyrażenia definiowanego definiensu - wyrażenia definiującego, tj. wyrażenia, za pomocą którego definicja informuje o​ znaczeniu wyrażenia definiowanego.

Tymczasem z definicji można wywnioskować, że System to „cały System” i jego dokumentacja. Dodatkowo definicja zawiera warunkowość „jeśli System …” sugerująca, ż​ e na etapie OPZ nie wiadomo, jak zbudowany jest System. Ponieważ wykonawca ​ ramach Umowy ma naprawiać Błędy w funkcjonowaniu Systemu oraz wykonywać modyfikacje Systemu, definicja w Systemu musi jasno określać, z jakich elementów składa się System tak, by można było jasno określić za które elementy odpowiada Wykonawca. Obecne brzmienie df „Systemu” uniemożliwia sporządzenie rzetelnej i profesjonalnej oferty, gdyż wykonawca nie wie, jaki jest zakres jego obowiązków.

Żądanie:

Odwołujący wniósł o dokonanie zmian w OPZ – Definicje – System System Zintegrowanej Rejestracji Przedsiębiorców i Obsługi Wniosków (SZPROT) opisany ​ Załączniku 1 do OPZ „Opis Systemu SZPROT” w

Zarzut IVC. Definicja Błędu 1.Obecne w TOM III SW Z – OPZ Definicje – Błąd - zawarte jest brzmienie:

Błąd Stan Systemu mogący skutkować lub skutkujący ograniczeniem bądź brakiem realizacji dowolnej funkcji Systemu.

Kategorie błędu usuwane w ramach Usługi Utrzymania:

1. Awaria,
2. Błąd Blokujący,
3. Błąd Poważny,
4. Błąd Średni,
5. Błąd Drobny.

Za Błąd nie uznaje się sytuacji, w której nie działają funkcjonalności Systemu wskutek zmian w otoczeniu Systemu, jak zmiany infrastruktury, technologii lub przepisów prawa.

Odwołujący podał, że przy obecnym brzmieniu definicji Zamawiający będzie mógł dowolne zdarzenia kwalifikować jako Błędy – zamiast określić w SW Z przesłanki uznania zdarzeń jako Błędy. Tak sformułowana definicja powoduje, że Wykonawca na etapie przygotowania oferty nie może nawet szacunkowo ocenić liczby występujących Błędów. Nie jest bowiem możliwe oszacowanie, ile pojawi się Błędów wynikających ze źródeł nie zależnych d​ o Wykonawcy. Skutkuje to tym, że Wykonawca nie jest w stanie określić pracochłonności usługi.

Trudno w/w definicję uznać za prawidłowe określenie przez Zamawiającego obowiązków Wykonawcy, czyli określenie w sposób zamknięty, pełny i jasny. Jest to klasyczny przypadek czystej uznaniowości Zamawiającego w kształtowaniu zobowiązań umownych wykonawcy. Zamawiający jako Błąd może wskazać dowolne zdarzenie, w tym także takie, którego przyczyna tkwi w działaniach czy zaniechaniach Zamawiającego. Postanowienie to pozwala Zamawiającemu całkowicie arbitralnie ustalać, co jest Błędem, co narusza art. 99 ust. 1 Ustawy PZP. Co więcej Wykonawca byłby zobowiązany do usunięcia Błędu i ponosi konsekwencje umowne w tym zakresie, pomimo iż powstanie Błędu nie wynika z​ okoliczności, za które Wykonawca ponosi odpowiedzialność. 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.

Konieczne jest odwołanie do Dokumentacji Systemu – tylko taki element definicji stanowi bowiem obiektywny element.

Dokumentacja Systemu opisuje, jak powinien prawidłowo działać System i na jej podstawie można zweryfikować przypadki jego działania niezgodnego z tą dokumentacją, które to sytuacje wykonawca zobowiązany jest usunąć.

Żądanie:

Odwołujący wniósł o zmianę definicji Błędu na:

Działanie Systemu niezgodne z Dokumentacją, które ze względu na ograniczenia w poprawnym, zgodnym z Dokumentacją działaniu Systemu określany jest jako:

1. Awaria
2. Błąd Blokujący
3. Błąd Poważny
4. Błąd Średni
5. Błąd Drobny Za Błąd nie uznaje się sytuacji, w której nie działają funkcjonalności Systemu wskutek nieprawidłowego działania lub zmian w otoczeniu Systemu, w szczególności błędów działania Platformy Sprzętowo-Programowej, systemów zewnętrznych, zmiany infrastruktury, technologii lub przepisów prawa.

Ad.5 Zarzut V: TOM III SWZ – OPZ punkt 3.6.20 - Naruszenie art. 99 ust. 1 w związku z art. 16 PZP – poprzez opisanie przedmiotu zamówienia w sposób niemożliwy do zrealizowania zadania, co skutkuje niemożnością przygotowania oferty.

Obecne w OPZ punkt 3.6.20 zawarte jest wymaganie o brzmieniu:

„Wykonawca jest zobowiązany do realizacji Usług Rozwoju i Utrzymania Systemu w taki sposób, aby każda opcja konfiguracyjna, definiowalny parametr, definicja przebiegu, przełącznik oraz każdy inny element związany z konfiguracją Systemu, był możliwy d​ o zdefiniowania przez administratorów systemu z poziomu GUI. Zamawiający nie dopuszcza umieszczania parametrów w kodzie programistycznym, bądź ich konfigurowania z poziomu bezpośredniego dostępu do serwera bazy danych, serwera aplikacji lub jakiegokolwiek komponentu innego niż GUI."

Odwołujący podkreślił, iż każdy system zawiera parametry ustawiane niezależnie o​ d wytwarzanego oprogramowania. Są to przykładowo parametry inicjalne czy uruchomieniowe. Wykonawca zatem nie jest w stanie zapewnić konfigurowalności dowolnego/każdego parametru systemu - z poziomu interfejsu administracyjnego GUI.

Zobowiązanie realizacji wymagania w ramach Usług Utrzymania dla zastanej części Systemu skutkuje niemożnością oszacowania kosztów realizacji Usług Utrzymania.

Żądanie:

Mając powyższe na uwadze Odwołujący wnosi o zmianę treści wymagania na:

„Wykonawca jest zobowiązany do realizacji Usług Rozwoju w taki sposób, aby każda opcja konfiguracyjna, definiowalny parametr, definicja przebiegu, przełącznik oraz każdy inny element związany z konfiguracją Systemu, był możliwy do zdefiniowania przez administratorów systemu z poziomu GUI w zakresie uwzględniającym ograniczenia wynikające z Oprogramowania gotowego. Zamawiający nie dopuszcza umieszczania parametrów w kodzie programistycznym bądź ich konfigurowania z poziomu bezpośredniego dostępu do serwera bazy danych, serwera aplikacji lub jakiegokolwiek komponentu innego niż GUI, jeżeli Oprogramowanie gotowe dopuszcza taką możliwość."

Ad.6 Zarzut VI: TOM III SWZ – OPZ pkt. 4.2.6 – Naruszenie art. 99 ust. 1 w związku z art. 16 PZP poprzez opisanie przedmiotu zamówienia w sposób niejednoznaczny i niewyczerpujący, uniemożliwiający realizacje zobowiązań umownych wykonawcy w zakresie „Autoryzacja zmian Systemu wykonanych przez Zamawiającego lub podmioty trzecie”, co skutkuje niemożliwością skalkulowanie ceny oferty.

Zarzut VI A.

W pkt 4.2.6 ppkt 1 Opisu Przedmiotu Zamówienia Zamawiający wskazuje, że:

„1) Zamawiający zastrzega sobie prawo do realizacji zmian Systemu samodzielnie lub z pomocą podmiotów trzecich. W takiej sytuacji, Wykonawca nie może odmówić świadczeń Usług Utrzymania Systemu w stosunku do takich zmian Systemu, jeżeli procedura poniżej wskazana, zakończyła się podpisaniem przez Wykonawcę Raportu Autoryzacyjnego."

Z kolei w pkt. 4.2.6 ppkt 7) OPZ Zamawiający wskazuje, że:

1. Jeżeli Wykonawca nie zgłasza uwag do dokumentacji zmiany lub testy zmiany przeprowadzone przez Wykonawcę nie wykazały wystąpienia Awarii lub Błędów Blokujących, Wykonawca dokona Autoryzacji. Autoryzacja oznacza, że zmiana zostaje objęta Usługami Utrzymania z dniem wdrożenia przez Zamawiającego zmiany w Systemie.Wykonawca ma obowiązek podpisania Raportu Autoryzacyjnego w terminie do 3 Dni roboczych od dnia zakończenia testów, nie później niż w terminie wskazanym we Wniosku Zmiany.

Z powyższych postanowień jednoznacznie wynika, że w Wykonawca nie może odmówić podpisania Raportu Autoryzacyjnego, co z kolei skutkuje dokonaniem Autoryzacji i​ obowiązkiem świadczenia Usług Utrzymania w stosunku do zmian Systemu, których Wykonawca nie jest autorem. W szczególności obowiązek Autoryzacji KAŻDEJ ZMIANY powoduje, że Wykonawca ma obowiązek świadczyć usługi co do

zmian, które będą mogły być zmianami wadliwymi, zawierającymi (w rozumieniu Umowy) nieznaną liczbę błędów innych kategorii niż wskazane w pkt. 4.2.6 ppkt 7) a zdefiniowanych przez Zamawiającego w OPZ, tj.:

Błąd Poważny Błąd powodujący brak co najmniej jednej funkcjonalności Systemu lub obniżający użyteczność Platformy Programowej, wymuszający na użytkownikach lub administratorach zastosowanie obejścia, utrudnia wykonywanie operacji w Systemie.

Błąd Średni Błąd, który utrudnia wykonanie pojedynczych operacji w Systemie bądź powoduje konieczność wykonania dodatkowych czynności w celu skorzystania z funkcjonalności Systemu, w tym problem nieprawidłowego wyświetlania danych.

Błąd Drobny Błąd, który nie utrudnia wykonywania pojedynczych operacji, ale wpływa negatywnie na komfort pracy użytkownika. Może być związany m.in. z interfejsem użytkownika, kolejnością wykonania operacji, rozmiarem, kolorem ekranu i czcionki, a także obejmuje inne Błędy niepowodujące powstawania wyników o cechach niezgodnych z opisanymi w instrukcji użytkownika.

Odwołujący stoi na stanowisku, że obecne zapisy dotyczące procesu Autoryzacji zmian mogą prowadzić do sytuacji, w której błędy świadomie lub nieświadomie nieusunięte przed przekazaniem do procesu Autoryzacji przez danego wykonawcę zmiany Systemu (firma trzecia lub. np. jednostka organizacyjna Zamawiającego – Aplikacje Krytyczne) staną się automatycznie elementem Systemu i Wykonawca będzie musiał takie nowe elementy Systemu obsługiwać w ramach Usług Utrzymania. Tymczasem zgodnie z zasadami prawa cywilnego, to podmiot wykonujący dany element Systemu powinien takie błędy usunąć, zanim dany nowy element Systemu zostanie włączony i zintegrowany z całym Systemem.

Tym samym całe, niemożliwe do oszacowania ryzyko związane z obsługą takich błędów przenoszone jest na Wykonawcę przedmiotowej Umowy, realizującego Usługi Utrzymania.

Dodatkowo na moment szacowania ceny oferty Wykonawca nie będzie znał liczby, stopnia złożoności zmian wykonywanych przez Zamawiającego lub podmioty trzecie a w skrajnym przypadku realnej możliwości i czasu potrzebnego na Autoryzację zmian Systemu jak i​ naprawę błędów. Tymczasem wynagrodzenie z tytułu Usług Utrzymania jest wynagrodzeniem ryczałtowym. A ponadto świadczenie tych usług jest objęte rygorem kar umownych za terminową naprawę, w określonych przez Zamawiającego czasach naprawy dla poszczególnych kategorii błędów. Dodatkowo należy wskazać na fakt, że w zakresie kategoryzacji błędów i tym samym wymaganych czasów ich naprawy zgodnie z ust. 5.2.4 pkt 3) OPZ, to Zamawiający ma ostateczne zdanie w zakresie przypisania priorytetu Błędu, co w sposób bezpośredni determinuje wymagany czas jego naprawy.

Jednocześnie w pkt. 4.2.6 ppkt. 3 Zamawiający wskazuje:

„3) Wykonawca ma obowiązek w ramach Autoryzacji dokonać analizy przekazanych kodów źródłowych zmiany i dokumentów. Jeśli w ocenie Wykonawcy, dokumentacja zmiany jest niekompletna lub niezgodna z Procedurą Wytwarzania Oprogramowania Zamawiającego, Wykonawca ma obowiązek zgłosić uwagi Zamawiającemu, wskazując na konkretne braki lub niezgodności, w terminie nie dłuższym niż 3 Dni robocze od dnia ich przekazania."

Zapisy te wprost obligują Wykonawcę do realizacji prac związanych z analizą przekazanych kodów źródłowych zmiany i dokumentów, bez dodatkowego wynagrodzenia, w nieznanym na dzień składania oferty wymiarze (nieznana liczba autoryzacji) a tym samym niemożliwej do oszacowania pracochłonności, jednocześnie narzucając termin ich realizacji i bez możliwości potwierdzenia wykonalności takiej analizy. W przypadku dużej zmiany Systemu – wykonanie analizy kodów źródłowych zmiany i dokumentów w 3 dni jest świadczeniem niemożliwym.

Żądanie:

Odwołujący wniósł o zmianę Opisu Przedmiotu Zamówienia w następujący sposób:

1. Modyfikację postanowień pkt. 4.2.6 ppkt. 2) przez dodanie nowej litery c):

„c) Zgłoszenie Zmiany” i nadanie treści:

1. W przypadku Autoryzacji Wykonawca otrzyma od Zamawiającego: a) informacje o zakresie zmiany planowanej do instalacji w środowisku produkcyjnym, wraz z określeniem terminu planowanej instalacji; b) kompletną Dokumentację zmiany wraz z kodami źródłowymi zmiany. c) Zgłoszenie Zmiany, które będzie procedowane zgodnie z zasadami opisanymi w pkt. 4.2 Rozwój na Zgłoszenie 2.Modyfikację postanowień pkt. 4.2.6 ppkt. 4) przez usunięcie zdania „Zamawiający skieruje do Wykonawcy Wniosek Zmiany”. i nadanie mu brzmienia:

„W przypadku, gdy przekazana dokumentacja zmiany uzasadnia potrzebę wykonania dodatkowych testów, Wykonawca może zgłosić konieczność ich przeprowadzenia n​ a środowisku testowym na etapie uzupełnienia Zgłoszenie Zmiany."

1. Modyfikację postanowień pkt. 4.2.6 ppkt. 7) przez wydłużenie terminu z 3 dni roboczych na 5 dni roboczych, usunięcie słowa “Awarii” i nadanie mu brzmienia:

„Jeżeli Wykonawca nie zgłasza uwag do dokumentacji zmiany lub testy zmiany przeprowadzone przez Wykonawcę nie wykazały wystąpienia Błędów, Wykonawca dokona Autoryzacji. Autoryzacja oznacza, że zmiana zostaje objęta Usługami Utrzymania z dniem wdrożenia przez Zamawiającego zmiany w Systemie. Wykonawca ma obowiązek podpisania Raportu Autoryzacyjnego w terminie do 5 Dni roboczych od dnia zakończenia testów, nie później niż w terminie wskazanym we Wniosku Zmiany."

1. Modyfikację postanowień pkt. 4.2.6 ppkt. 8) przez wydłużenie terminu z 2 dni roboczych na 5 dni roboczych oraz usunięcie słowa “Awarii” i nadanie mu brzmienia:

„Jeżeli Wykonawca zgłasza uwagi do dokumentacji zmiany lub testy wykazały wystąpienie Błędów, Wykonawca jest zobowiązany niezwłocznie, lecz nie później niż w terminie 5 Dni roboczych od zakończenia testów i nie później niż w terminie wskazanym we Wniosku Zmiany, przekazać uwagi do Zamawiającego wraz z uzasadnieniem w Raporcie Autoryzacyjnym i odmówić autoryzacji zmian Systemu.„ 5.Modyfikację postanowień pkt. 4.2.6 ppkt. 9) przez usunięcie dotychczasowego pkt a) „a) odrzuci uwagi zgłoszone przez Wykonawcę do dokumentacji zmiany, podając uzasadnienie i potwierdzi konieczność Autoryzacji albo”, dodanie w pkt a) sformułowania “oraz zaktualizowane Zgłoszenie Zmiany wraz ze zaktualizowaną czasochłonnością Autoryzacji zmiany” i nadanie ppkt. 9 brzmienia:

„W przypadku odmowy autoryzacji, Zamawiający zapozna się z przyczynami odmowy sformułowanymi przez Wykonawcę w Raporcie Autoryzacyjnym i: a) przedłoży Wykonawcy poprawioną zmianę w zakresie zgłoszonych uwag oraz zaktualizowane Zgłoszenie Zmiany wraz ze zaktualizowaną czasochłonnością Autoryzacji zmiany albo b) uwzględni uwagi Wykonawcy i zrezygnuje z wprowadzenia zmiany do Systemu.

1. Usunięcie postanowień pkt. 4.2.6 ppkt. 10) i poprawienie numeracji 7.Zmianę postanowień pkt. 4.2.6 dotychczasowy ppkt. 11) (ppkt 10 po zmianach) i nadanie mu brzmienia:

„W przypadku, o którym mowa w ppkt 9 lit.a), po przedłożeniu przez Zamawiającego Wykonawcy poprawionej zmiany w zakresie zgłoszonych przez Wykonawcę uwag, Wykonawca ma obowiązek dokonać autoryzacji zmiany w uzgodnionym we Wniosku Zmiany terminie liczonym od dnia przekazania przez Zamawiającego poprawionej zmiany."

Zarzut VI B.

W pkt 4.2.6 ppkt 1 Opisu Przedmiotu Zamówienia Zamawiający wskazuje, że:

„1) Zamawiający zastrzega sobie prawo do realizacji zmian Systemu samodzielnie lub z pomocą podmiotów trzecich. W takiej sytuacji, Wykonawca nie może odmówić świadczeń Usług Utrzymania Systemu w stosunku do takich zmian Systemu, jeżeli procedura poniżej wskazana, zakończyła się podpisaniem przez Wykonawcę Raportu Autoryzacyjnego."

Z powyższego wynika, że przedmiot umowy staje się zupełnie niedookreślony, uznaniowy i​ jednostronnie definiowany przez Zamawiającego. W ramach Autoryzacji Zamawiający może swobodnie rozszerzyć zakres Systemu, włączając do niego dowolne aplikacje, które dotychczas nie stanowiły przedmiotu dokumentacji Systemu. W ramach takiego rozszerzenia mogą zostać wprowadzone aplikacje w technologiach dotychczas niewskazanych w SWZ, c​ o może się wiązać z poważnym wzrostem kosztów, niemożliwych do wycenienia na etapie składania ofert, koniecznością rozbudowy Platformy Sprzętowo- Programowej (zgodnie z​ zapisami pkt 4.2.5 ppkt. 3) a nawet brakiem możliwości realizacji w przypadku niszowych technologii. Wskazane postanowienia stanowią naruszenie przepisów m.in. art. 99 ust. 1 PZP w związku z art. 16 PZP w zw. z art. 353(1) k.c.

Żądanie Biorąc pod uwagę wskazane naruszenia Odwołujący wnosi o wprowadzenie stosownych regulacji do dokumentacji postępowania skutkujących obowiązkiem autoryzacji jedynie takich rozwiązań, które są zgodne zakresem technologii wskazanych w SWZ lub podania szczegółowego katalogu technologii dopuszczalnych w ramach autoryzacji.

Jako żądanie alternatywne Odwołujący wnosi o wprowadzenie postanowień umożliwiających odmówienie przez Wykonawcę Autoryzacji, w przypadku braku zwiększenia wynagrodzenia za Utrzymanie z tego tytułu lub też każdorazowe zwiększanie wynagrodzenia wykonawcy ​ każdym przypadku Autoryzacji zmiany rozszerzającej zakres opisanych w OPZ technologii. w

Ad.7 Zarzut VII: TOM III SWZ – OPZ punkt 5.1.5) - Naruszenie art. 99 ust. 1 w związku z art. 16 PZP –poprzez opisanie przedmiotu zamówienia poprzez powiązanie Niedostępności Systemu z Błędem Blokującym,co powoduje, że przedmiot zamówienia w zakresie dotyczącym zobowiązań Wykonawcy jest opisany w sposób otwarty, niedookreślony, uniemożliwiający skalkulowanie oferty przez Wykonawcę.

Obecne w TOM III SWZ – OPZ punkt 5.1.5 - zawarte jest brzmienie:

Wykonawca gwarantuje dostępność Systemu (rozumianą jako czas działania Systemu bez Awarii i Błędu Blokującego) na poziomie nie niższym niż 99,4% w Okresie rozliczeniowym, z wyłączeniem ograniczeń dostępności usługi, o których mowa w pkt 3.8.2 ppkt. 4.

Kalendarz dostępności: dla Systemu - 24 godziny na dzień, 7 dni w tygodniu, 365 dni w roku względnie (366 dni w roku przestępnym). Do gwarantowanego poziomu dostępności Systemu nie jest wliczana jego niedostępność wynikająca z przyczyn leżących po stronie Platformy Sprzętowo-Programowej Zamawiającego, w tym awarią łączy teletransmisyjnych, awarią sprzętu komputerowego, awarią zasilania lub brakiem danych niezbędnych do odtworzenia Systemu lub spowodowanych działaniem siły wyższej. Poziom dostępności Systemu obliczany jest wg wzoru: (TD – Σ TN) / TD*100% [%] gdzie:

TD – określony w minutach czas dostępności Systemu w Okresie rozliczeniowym wynikający z Kalendarza dostępności Systemu po odjęciu uzgodnionych ograniczeń dostępności usługi (Okien serwisowych) oraz niedostępności wynikających z przyczyn leżących po stronie Zamawiającego oraz migracji danych, Σ TN – suma czasów w minutach niedostępności Systemu w Okresie rozliczeniowym, gdzie czasem niedostępności Systemu jest czas, w którym w Systemie występuje Błąd w kategorii: Awaria lub Błąd Blokujący.

Odwołujący podkreślił, iż wystąpienie Błędu Blokującego zgodnie z definicją, nie musi doprowadzić do niedostępności Systemu, np. Błąd Blokujący będzie się wiązał z​ odstępstwem od parametrów wydajnościowych. W takim przypadku będzie zapewnione funkcjonowanie Systemu i użytkownicy będą realizować swoje obowiązki z wykorzystaniem Systemu. Natomiast zgodnie z w/w zapisami Wykonawcy zostanie naliczony czas niedostępności – pomimo tego, że niedostępność nie zaistniała.

Ponadto, z niedostępności Zamawiający nie wyklucza czasu obejścia (procedury zastępczej), co w znaczący sposób ogranicza czas naprawy zgłoszeń przez obejście. Zamawiający określił dostępność systemu na poziomie 99,4% w skali

roku, co przekłada się na maksymalnie 53 godzin niedostępności Systemu w ciągu roku. Przykładowo, sumaryczny czas naprawy 3 Błędów Blokujących z obejściem to 72 godziny, jednak, aby dochować parametry dostępności na naprawę i na usunięcie trzech Błędów Blokujących z obejściem pozostaje po 17,5 godziny na każdy z Błędów Blokujących.

Żądanie:

Wobec powyższego Zamawiający wnosi o modyfikację Wymagania punkt 5.1.5.

Wykonawca gwarantuje dostępność Systemu (rozumianą jako czas działania Systemu bez Awarii) na poziomie nie niższym niż 99,4% w Okresie rozliczeniowym, z wyłączeniem ograniczeń dostępności usługi, o których mowa w pkt 3.8.2 ppkt. 4.

Kalendarz dostępności: dla Systemu - 24 godziny na dzień, 7 dni w tygodniu, 365 dni w roku względnie (366 dni w roku przestępnym). Do gwarantowanego poziomu dostępności Systemu nie jest wliczana jego niedostępność wynikająca z przyczyn leżących po stronie Platformy Sprzętowo-Programowej Zamawiającego, w tym awarią łączy teletransmisyjnych, awarią sprzętu komputerowego, awarią zasilania lub brakiem danych niezbędnych do odtworzenia Systemu lub spowodowanych działaniem siły wyższej. Poziom dostępności Systemu obliczany jest wg wzoru: (TD – Σ TN) / TD*100% [%] gdzie:

TD – określony w minutach czas dostępności Systemu w Okresie rozliczeniowym wynikający z Kalendarza dostępności Systemu po odjęciu uzgodnionych ograniczeń dostępności usługi (Okien serwisowych) oraz niedostępności wynikających z przyczyn leżących po stronie Zamawiającego oraz migracji danych, Σ TN – suma czasów w minutach niedostępności Systemu w Okresie rozliczeniowym, gdzie czasem niedostępności Systemu jest czas, w którym w Systemie występuje Błąd w kategorii: Awaria dla którego nie dostarczono procedury zastępczej.

Ad.8 Zarzut VIII: TOM III SWZ – OPZ punkt 5.2.4 4) - Naruszenie art. 99 ust. 1 w związku z art. 16 PZP – poprzez opisanie przedmiotu zamówienia w sposób niemożliwy do oszacowania kosztu realizacji oraz w sposób niemożliwy do realizacji.

Obecne w TOM III SWZ – OPZ punkt 5.2.4 4) - zawarte jest brzmienie:

Wykonawca ma prawo do jednokrotnego wystąpienia o uzupełnienie/ sprecyzowanie Zgłoszenia serwisowego, wówczas czas oczekiwania na odpowiedź Zamawiającego zawiesza bieg terminów, o których mowa w ppkt 5) (zawieszenie Zgłoszenia w CSD). Wykonawca na każdym etapie ma możliwość wystąpienia do Zamawiającego o informacje dotyczące Zgłoszenia serwisowego, przy czym nie skutkuje to kolejnym jego zawieszeniem; W ramach OPZ Zamawiający wymaga, aby Wykonawca na podstawie jednokrotnego wniosku o uzupełnienie był w stanie dostarczyć rozwiązanie dla zgłaszanego Błędu. Jednocześnie Zamawiający na etapie postępowania nie wskazał żadnych wymagań c​ o do jakości zgłoszeń, w tym nie określono w SW Z minimalnej treści zgłoszenia. Skoro zamawiający przewidział procedurę uzupełnienia zgłoszenia, zakłada, że zgłoszenia mogą być o różnym poziomie opisu, wręcz nie kompletne.

Wymaganie to zupełnie pomija fakt, ż​ e zgłoszenie po uzupełnieniu może okazać się zgłoszeniem nowym lub może być nadal niekompletne. Ponieważ za poprawność zgłoszenia odpowiada Zamawiający, nie może o​ n przenosić odpowiedzialności za swoje obowiązki tj. za prawidłowo i skuteczne zgłoszone, klarownie opisane i kompletne zgłoszenia na Wykonawcę.

Żądanie:

Wobec powyższego Zamawiający wnosi o zmianę punkt 5.2.4 4) W przypadku, gdy Zgłoszenie serwisowe nie zawiera wszystkich informacji niezbędnych d​ o usunięcia Błędu Wykonawca ma prawo do wystąpienia o uzupełnienie/ sprecyzowanie Zgłoszenia serwisowego. W takim przypadku czas oczekiwania na odpowiedź Zamawiającego zawiesza bieg terminów, o których mowa w ppkt 5) (zawieszenie Zgłoszenia w CSD).

Ad.9 Zarzut IX: TOM III SWZ – OPZ punkt 5.2.5 - Naruszenie art. 99 ust. 1 w związku z art. 16 PZP poprzez opisanie przedmiotu zamówienia w sposób niemożliwy do oszacowania kosztu realizacji oraz w sposób niemożliwy do realizacji.

Obecne w TOM III SWZ – OPZ punkt 5.2.5) - zawarte jest brzmienie:

W ramach Zgłoszeń serwisowych Zamawiający może zlecić Wykonawcy konieczność wsparcia Zamawiającego przy odtwarzaniu uszkodzonego Systemu. Wykonawca zobowiązany jest świadczyć wsparcie aż do czasu przywrócenia pełnej funkcjonalności Systemu. Wsparcie Wykonawcy polegać będzie na samodzielnym wykonaniu przez niego niezbędnych czynności do odtworzenia Systemu lub przekazaniu Zamawiającemu sposobu wykonania tych czynności w formie szczegółowych opisów lub procedur.

Ponieważ zgodnie z definicją Zgłoszenie serwisowe to sposób przekazania do Wykonawcy Błędu do usunięcia, wymaganie pkt 5.2.5. jest niczym innym jak przeniesieniem n​ a Wykonawcę dalszej obsługi Błędu w ramach czasu naprawy. Należy przypomnieć, i​ ż w ramach obsługi Błędu opisanej w punkcie 5.2.4 5) Wykonawca jest zobowiązany d​ o dostarczenia rozwiązania. Może dojść więc do sytuacji, w której Wykonawca przekaże rozwiązanie Zamawiającemu zgodnie z czasem naprawy, ale Zamawiający po zapoznaniu się z rozwiązaniem zleci konieczność wsparcia, na które nie wystarczy już czasu przewidzianego na obsługę Błędu i w związku z tym wymaganie może być nie możliwe d​ o spełnienia. Ponadto Zamawiający nie podał uzasadnienia, dlaczego Wykonawcę miałby obowiązywać czas naprawy dla błędów wynikających z innych źródeł niż Platforma Programowa. Wykonawca na etapie przygotowania oferty nie jest w stanie przewidzieć, i​ le może być Błędów z koniecznością wsparcia Zamawiającego ani ile może być Błędów spowodowanych błędami w Platformie Sprzętowo-Programowej, koszty realizacji przedmiotu zamówienia w zakresie konieczność wsparcia Zamawiającego przy odtwarzaniu uszkodzonego Systemu są całkowicie niemierzalne i niemożliwe do oszacowania na etapie przygotowania oferty.

Żądanie:

Wobec powyższego Wykonawca wnosi o wykreślenie pkt 5.2.5.

Ad.10 Zarzut X: Tom III SWZ – OPZ punkt 5.2.7- Naruszenie art. 99 ust. 1 w związku z art. 16 PZP poprzez opisanie przedmiotu zamówienia w sposób niejasny i uniemożliwiający przygotowanie oferty, co skutkuje niemożnością przygotowania oferty.

Obecne w TOM III SWZ – OPZ punkt 5.2.7) - zawarte jest brzmienie:

Jeżeli rozwiązanie Zgłoszenia jest niemożliwe ze względu na wadliwe działanie Platformy Sprzętowo-Programowej, Wykonawca ma obowiązek poinformować Zamawiającego o potencjalnym źródle Błędu. Wykonawca oznacza Zgłoszenie serwisowe jako rozwiązane. Zamawiający weryfikuje informację przekazaną przez Wykonawcę. Zamawiający zamyka Zgłoszenie lub przekazuje Zgłoszenie ponownie do Wykonawcy (otwiera Zgłoszenie w CSD). Wówczas czas na usunięcie Błędu liczony jest od momentu przekazania przez Zamawiającego pierwotnego Zgłoszenia serwisowego do czasu ponownego oznaczenia przez Wykonawcę statusu Zgłoszenia serwisowego w systemie CSD jako rozwiązane. Czas, w którym Zamawiający weryfikuje rozwiązanie Zgłoszenia, nie jest wliczany do terminów usuwania Błędów.

Zgodnie z definicją na Infrastrukturę techniczną Systemu składa się Platforma Programowa oraz Platforma SprzętowoProgramowa, zatem poprawność działania Systemu zależna jest nie tylko od Wykonawcy, ale też od Zamawiającego. W przedmiotowym pkt natomiast oczekuje się nieomylności Wykonawcy co do diagnozy Platformy Sprzętowo-Programowej, należy nadmienić, iż na etapie postępowania nie wiadomo do jakich elementów Platformy Sprzętowo-Programowej Wykonawca będzie miał dostęp, zatem nie jest znana możliwość diagnozy tej platformy przez Wykonawcę. Zamawiający sam zauważa, iż Wykonawca może nie móc spełnić tego wymagania i w wymaganiu 5.4.1 ppkt. 2 gdzie zobowiązuje Wykonawcę do informowania o nieprawidłowym działaniu Systemu ze względu na elementy Platformy SprzętowoProgramowej warunkuje już to zobowiązanie, cyt. „…o ile Wykonawca jest ​ stanie wykryć te nieprawidłowości”. Dochodzi więc do sprzeczności wymagań dot. zobowiązań Wykonawcy w w przypadku nieprawidłowego działania Systemu, gdzie w ramach usługi Konserwacji Systemu Zamawiający słusznie dostrzega się, iż Wykonawca może n​ ie mieć możliwości wykryć nieprawidłowości w Platformie Sprzętowo-Programowej, a​ le dla Usługi Utrzymania, kiedy Zamawiający to nieprawidłowe działanie nazwie Błędem, Wykonawca już taką nieprawidłowość musi jednoznacznie wykryć.

Żądanie:

Wobec powyższego Zamawiający wnosi o wykreślenie punkt 5.2.7.

Ad.11 Zarzut XI: TOM III SWZ – OPZ punkt 5.3.3 - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP – poprzez opisanie przedmiotu zamówienia w sposób niemożliwy do oszacowania kosztów realizacji wymagania w zakresie kompleksowego wsparcia, w tym udzielania konsultacji, co skutkuje niemożnością przygotowania oferty.

Obecne w OPZ punkt 5.3.3 zawarte jest brzmienie:

„Wykonawca będzie zobowiązany do udzielania konsultacji dotyczących Systemu, ​ szczególności w następującym zakresie: w (…)

1. wykrywania przyczyn Błędów, w tym przyczyn Błędów powiązanych ze sobą,
2. tworzonych rozwiązań zmierzających do uniknięcia wszelkich przyszłych Błędów tego samego typu,
3. udzielania Zamawiającemu wsparcia w diagnostyce nieprawidłowości związanych z działaniem Systemu,
4. usuwania Błędów,
5. nowych funkcjonalności Systemu dostarczanych przez Wykonawcę,
6. wsparcia Zamawiającego w szkoleniu Użytkowników wewnętrznych, rozumiane jako dyspozycyjność konsultanta w trakcie trwania szkolenia, w celu omówienia przypadków zgłaszanych przez Uczestników lub prowadzącego szkolenie,
7. eksploatacji Systemu,
8. administrowania komponentami technicznymi Systemu,
9. baz danych i serwerów aplikacji,
10. współpracy Platformy Sprzętowo-Programowej z Systemem.

Opisując zakres konsultacji Zamawiający użył zwrotu „w szczególności”, przez co pozostawił otwarty zakres prac, uniemożliwiając Odwołującemu oszacowanie pracochłonności.

Zamawiający opisał w ppkt. 6 i 8 zakres konsultacji w sposób, który na etapie sporządzania oferty nie daje możliwości oszacowania pracochłonności ich realizacji: a)wsparcia Zamawiającego w szkoleniu Użytkowników wewnętrznych, rozumiane jako dyspozycyjność konsultanta w trakcie trwania szkolenia, w celu omówienia przypadków zgłaszanych przez Uczestników lub prowadzącego szkolenie, Zamawiający nie wskazuje zakresu szkoleń, ilości, terminów, częstotliwości czy nawet informacji czy wymagana jest obecność zdalna czy stacjonarna. Tym samym Odwołujący nie ma możliwości oszacowania kosztów realizacji tego wymagania. b)administrowania komponentami technicznymi Systemubrak definicji i określenia zakresu komponentów technicznych, które są objęte konsultacjami. Część komponentów dostarczana i utrzymywana jest przez Zamawiającego zgodnie z założeniem Platformy Sprzętowo-Programowej.

Wynagrodzenie z tytułu konsultacji ma charakter ryczałtowy – a zatem wykonawcy są zobowiązani określić już w ofercie wynagrodzenie w tym zakresie. W tym celu konieczne jest określenie pełnego i zamkniętego zakresu obowiązków.

Żądanie:

Mając na uwadze powyższe Odwołujący wniósł o: a.Usunięcie z wymagania zwrotu „w szczególności” b.Wskazanie godzinowego limitu konsultacji w miesiącu lub

usunięcie całego wymagania opisanego w TOM III SWZ – OPZ punkt 5.3.3. c) Doprecyzowanie wymagania: a. 6) wsparcia Zamawiającego w szkoleniu Użytkowników wewnętrznych, przez wskazanie: i.zakresu szkoleń, ii.planowanej ilości szkoleń, iii.planowanych terminów lub częstotliwości szkoleń, iv.informacji czy wymagana jest obecność zdalna czy stacjonarna. v.rozumiane jako dyspozycyjność konsultanta w trakcie trwania szkolenia, w celu omówienia przypadków zgłaszanych przez Uczestników lub prowadzącego szkolenie lub b. Usunięcie pkt 6 „6) wsparcia Zamawiającego w szkoleniu Użytkowników wewnętrznych, d) Usunięcie z zakresu świadczonych konsultacji punktu: a. 8). administrowania komponentami technicznymi Systemu lub b.Doprecyzowanie wymagania przez wskazanie zamkniętej listy komponentów technicznych, za których utrzymanie odpowiadać będzie Wykonawca.

Ad. 12 Zarzut XII: TOM III SWZ – OPZ punkt 5.3.5 - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP – poprzez sporządzenie dokumentacji postępowania w sposób niejasny, niepełny i ostatecznie uniemożliwiający oszacowanie kosztu realizacji wymagania dotyczącego spotkań (stacjonarnych lub zdalnych) Obecnie w OPZ pkt 5.3.5 zawarte jest brzmienie:

„Konsultacje mogą odbywać się zgodnie z wyborem Zamawiającego w kilkuosobowych grupach stacjonarnie w lokalizacji wskazanej przez Zamawiającego lub zdalnie z​ zachowaniem interaktywnej formy konsultacji - o ile jest to konieczne. Uczestnicy w czasie rzeczywistym muszą widzieć i słyszeć konsultanta, móc zadawać pytania i wyjaśniać wątpliwości. Konsultant musi udostępniać na bieżąco na ekranie materiały konsultacyjne, w szczególności niezbędną Dokumentację Systemu. Uczestnicy muszą również widzieć i słyszeć siebie wzajemnie. Zamawiający wymaga, aby konsultacje, zgodnie z wyborem Zamawiającego, zostały przeprowadzone z wykorzystaniem narzędzia Teams lub innego zapewnionego przez Wykonawcę."

W momencie składania ofert Wykonawca nie ma żadnych informacji w oparciu, o które mógłby przewidzieć ilość, częstotliwość spotkań, konieczne do przygotowania materiały konsultacyjne oraz zakres tematyczny spotkań, a w związku z tym kompetencje konsultanta. Tym samym Wykonawca w oparciu o tak postawione wymagania nie jest w stanie skalkulować ceny oferty z uwagi na zupełnie nieokreślony zakres. Przedstawiane tematy spotkań mogą znacząco wpłynąć na skład osobowy oraz czas potrzebny do przygotowania się do spotkania, składowe te mogą okazać się znacznym kosztem. Jest to element obrazujący zupełny brak zakresu jaki ma wykonać Wykonawca. doprecyzowanie maksymalnej liczby spotkań stacjonarnych i zdalnych w Okresie Rozliczeniowym oraz zakres merytoryczny spotkań usunięcie wymagania – jeśli podanie powyższych danych w SWZ jest niemożliwe na obecnym etapie Żądanie:

Odwołujący wniósł o:

1. doprecyzowanie maksymalnej liczby spotkań stacjonarnych i zdalnych w Okresie Rozliczeniowym oraz zakres merytoryczny spotkań lub 2.usunięcie wymagania – jeśli podanie powyższych danych w SWZ jest niemożliwe na obecnym etapie.

Ad.13 Zarzut XIII: TOM III SWZ - OPZ punkt 5.4.1. 3) - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP poprzez opisanie przedmiotu zamówienia w sposób niemożliwy do oszacowania kosztu realizacji.

Obecne w TOM III SWZ – OPZ zawarte jest brzmienie punkt 5.4.1. 3) -:

„3) niezwłocznego informowania Zamawiającego o nowych wersjach oprogramowania, w szczególności: Oprogramowania COTS, Free and Open-Source Software (FOSS), Free/Libre and Open Source Software (FLOSS), wersjach podwyższonych, wydaniach uzupełniających oraz poprawkach programistycznych i aktualizacjach w zakresie komponentów Platformy Programowej będących Oprogramowaniem COTS, FOSS, FLOSS wraz z analizą wpływu zainstalowania ww. elementów na działanie Systemu wraz z rekomendacją instalacji. W przypadku, gdy Zamawiający zdecyduje o instalacji, Wykonawca zobowiązany jest do instalacji w terminie uzgodnionym z Zamawiającym,” Rozdział 4.2 Rozwój na Zgłoszenie pkt 4.2.3 4.2.3. Zakres dokonywanych w Systemie Zmian wynikać będzie w szczególności:

1. ze zmian przepisów prawa, w szczególności w zakresie dostosowania Systemu do wymagań Unijnego Kodeksu Celnego i Ordynacji podatkowej;
2. ze zmian metodologicznych przekazywanych przez instytucje krajowe lub zagraniczne (np. Komisję Europejską, itp.);
3. z wymagań wynikających ze współpracy Systemu z innymi systemami;
4. ze zmian postulowanych przez Użytkowników wewnętrznych lub administratorów Systemu, związanych z koniecznością poprawy wydajności lub funkcjonalności Systemu;
5. ze zmian Platformy Sprzętowo-Programowej wykorzystywanej przez System.

Zamawiający wymaga, aby w ramach usługi Konserwacji Systemu Wykonawca instalował nowe wersje Oprogramowania gotowego w terminie uzgodnionym z Zamawiającym. Jednocześnie Zamawiający nie określa, kto ma to oprogramowanie dostarczyć a​ ni kto ma wykonać niezbędne modyfikacje dostosowujące System do nowego Oprogramowania gotowego.

Ulokowanie wymagania w usłudze Konserwacji Systemu i jednocześnie pominięcie takiej podstawy w usłudze Rozwoju na Zgłoszenie pkt 4.2.3 sugeruje, że prace mają się odbyć ​ ramach Usług Utrzymania. Należy wskazać, iż w momencie składania ofert Wykonawca nie ma żadnych informacji w w oparciu, o które mógłby przewidzieć ilość, częstotliwość, a przede wszystkim konieczny zakres dostosowania Systemu