26c1104b-ea0f-475b-8aaa-c3421262f0dd_2105_2125

Sygn. akt: KIO 2105/24

KIO 2125/24

WYROK

Warszawa, dnia 24 lipca 2024 roku

Krajowa Izba Odwoławcza - w składzie:

Przewodnicząca: Katarzyna Prowadzisz

Katarzyna Paprocka

Rafał Malinowski

Protokolant: Piotr Cegłowski

po rozpoznaniu na rozprawie w dniu 5 lipca 2024 roku odwołań wniesionych do Prezesa Krajowej Izby Odwoławczej

A)w dniu 17 czerwca 2024 roku przez wykonawcę Asseco Poland spółka akcyjna
‎z siedzibą w Rzeszowie (sygn. akt KIO 2105/24),

B)w dniu w dniu 17 czerwca 2024 roku przez wykonawcę Comarch Polska spółka akcyjna z siedzibą w Krakowie (sygn. akt KIO 2125/24)

w postępowaniach prowadzonych przez Zamawiającego – Centrum Informatyki Resortu Finansów w Radomiu

- przy udziale uczestnika po stronie Odwołujacego w postępowaniu o sygn. akt KIO 2105/24 wykonawcy Pentacomp Systemy Informatyczne spółka akcyjna z siedziba w Warszawie

- przy udziale uczestnika po stronie Zamawiającego w postępowaniu o sygn. akt KIO 2105/24 wykonawcy GISPartner spółka z ograniczona odpowiedzialnością z siedzibą we Wrocławiu

- przy udziale uczestnika po stronie Odwołujacego w postępowaniu o sygn. akt KIO 2125/24 wykonawcy Asseco Poland spółka akcyjna z siedzibą w Rzeszowie

- przy udziale uczestnika po stronie Odwołujacego w postępowaniu o sygn. akt KIO 2125/24 wykonawcy Enigma Systemy Ochrony Informacji spółka z ograniczoną odpowiedzialnością
‎z siedzibą w Warszawie

- przy udziale uczestnika po stronie Odwołujacego w postępowaniu o sygn. akt KIO 2125/24 wykonawcy GISPartner spółka z ograniczona odpowiedzialnością z siedzibą we Wrocławiu

orzeka:

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 SWZ – 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_WFED_36_A_2. w punkcie 9.b1 i 9b2 (odpowiadających swoja treścią 9. SZPROT_WFED_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.

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

5.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 Radomiu na 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 wykonawcy Comarch 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 A S A D N I E N I E

Zamawiający – Centrum Informatyki Resortu Finansów w Radomiu prowadzi 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
‎na 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 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 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 SWZ – 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;

7)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 SWZ – 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;

11) 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;

12) Zarzut XII: TOM III SWZ – 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 SWZ – 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 SWZ – OPZ – Załącznik nr 2 do OPZ Rozwój Zdefiniowany oraz TOM I SWZ – 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 SWZ – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 3 (SZPROT_WFOG_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;

19) Zarzut XIX: TOM III SWZ – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 6 (SZPROT_WFOG_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 SWZ – 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_WFED_3, SZPROT_WFOG_12 , SZPROT_WFOG_44 (zał. 2 do OPZ odpowiednio punkty: 48, 14, 123);

21)Zarzut XXI: TOM III SWZ – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkty 9, 10, 11 (SZPROT_WFED_36_A, SZPROT_WFED_36_B, SZPROT_WFEK_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 SWZ – 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 SWZ – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 32 (SZPROT_WFOG_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 SWZ – 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 SWZ – 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 SWZ 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,
‎w uzasadnieniu niniejszego pisma, osobno w każdym zarzucie.

Odwołujący wniósł o: uwzględnienie odwołania i nakazanie Zamawiającemu dokonania modyfikacji SWZ 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
‎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ń SWZ, 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 SWZ 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.

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,
‎w jaki sposób powinien zostać sporządzony opis przedmiotu zamówienia. Art. 99 ust. 1 PZP nakłada na zamawiającego 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ę.
‎Na podstawie opisu przedmiotu zamówienia dokonują obliczenia ceny za wykonanie zamówienia.

Na Zamawiającym ciąży obowiązek takiego opracowania dokumentacji przetargowej,
‎aby wykonawca nie był obciążany konsekwencjami jej nienależytego sporządzenia,
‎w szczególności opis zamówienia nie powinien być ogólny, szacunkowy i niedookreślony, wzajemnie niespójny, 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
‎na 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
‎na 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 SWZ. 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
‎w sytuacji, w której strona umowy nie jest użytkownikiem systemu, nie korzysta z systemu.

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ń SWZ, zaś usługi świadczone na rzecz Podmiotu 1 nie spełniają wymagań SWZ. 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,
‎we wskazanym przykładzie: 500 użytkowników. W sytuacji, gdy Podmiot 1 – nie mając 500 użytkowników – nie może być wskazanie tylko Podmiotu 1 jako gwaranta
‎dla 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 SWZ §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.

12. 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
‎na poniższych warunkach, z uwzględnieniem treści Umowy.

13. 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
‎w ww. sposób.

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

15. Licencja na dokumentację dotyczącą Oprogramowania COTS obejmuje:

1) w zakresie utrwalania i zwielokrotniania – wytwarzanie dowolną techniką egzemplarzy, w tym techniką drukarską, reprograficzną, zapisu magnetycznego oraz techniką cyfrową,

2) w zakresie obrotu oryginałem albo egzemplarzami, na których ją utrwalono – wprowadzanie do obrotu, użyczenie lub najem oryginału albo egzemplarza,

3) 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ć
‎do niej dostęp w miejscu i w czasie przez siebie wybranym.

(…)

16. 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
‎w niniejszym paragrafie. W przypadku gdyby postanowienie o niewypowiadalności licencji przewidziane w zdaniu poprzedzającym okazało się nieskuteczne lub nieważne, Strony uzgadniają 10-letni (słownie: dziesięcioletni) termin jej wypowiedzenia ze skutkiem
‎na koniec roku kalendarzowego, z zastrzeżeniem, iż Wykonawca zobowiązuje się
‎nie korzystać z uprawnienia do wypowiedzenia licencji z wyjątkiem przypadków,
‎w których Zamawiający przekroczy warunki udzielonej licencji i naruszy autorskie prawa majątkowe przysługujące Wykonawcy oraz nie zaniecha naruszenia mimo wezwania Wykonawcy i wyznaczenia mu w tym celu odpowiedniego terminu,
‎nie krótszego niż 30 dni.

(…)

17. Wykonawca dostarczy wraz z Oprogramowaniem COTS certyfikaty autentyczności, klucze instalacyjne oraz inne dokumenty i zabezpieczenia.

(…)

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

(…)

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

(…)

20. 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 SWZ – 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
‎na 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
‎w przypadku dostarczenia oprogramowania COTS, stoi w zupełnej sprzeczności do definicji Oprogramowania COTS. 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
‎na 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: “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
‎w niniejszym paragrafie. “

Wskazać należy, że Zamawiający nakłada na Wykonawcę zobowiązanie niemożliwe
‎do wykonania. Oprogramowanie gotowe to bardzo często oprogramowanie pochodzące
‎od dużych dostawców IT (Vendorów), którzy ustalają zasady licencyjne takie same
‎dla 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
‎do 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,
‎gdy 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
‎nie 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
‎w wymaganiach wydajnościowych, o których mowa w Załączniku nr 1 do OPZ.”

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órej utrzymanie 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
‎nie 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,
‎tak 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.

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 SIWZ 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
‎w ramach Umowy ma naprawiać Błędy w funkcjonowaniu Systemu oraz wykonywać modyfikacje Systemu, definicja 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
‎w Załączniku 1 do OPZ „Opis Systemu SZPROT”

Zarzut IVC. Definicja Błędu

1.Obecne w TOM III SWZ – 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 SWZ 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
‎do 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
‎do 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
‎od 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:

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

2) 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
‎na środowisku testowym na etapie uzupełnienia Zgłoszenie Zmiany.”

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

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

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

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,
‎co 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
‎w każdym przypadku Autoryzacji zmiany rozszerzającej zakres opisanych w OPZ technologii.

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.

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

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ń
‎co do jakości zgłoszeń, w tym nie określono w SWZ 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
‎on 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
‎do 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
‎na 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
‎do 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
‎do 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ć,
‎ile 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ętowo-Programowa, 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ętowo-Programowej warunkuje już to zobowiązanie, cyt. „…o ile Wykonawca jest
‎w stanie wykryć te nieprawidłowości”. Dochodzi więc do sprzeczności wymagań dot. zobowiązań Wykonawcy w przypadku nieprawidłowego działania Systemu, gdzie w ramach usługi Konserwacji Systemu Zamawiający słusznie dostrzega się, iż Wykonawca może
‎nie mieć możliwości wykryć nieprawidłowości w Platformie Sprzętowo-Programowej,
‎ale 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,
‎w szczególności w następującym zakresie:

(…)

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 Systemu-

brak 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ć
‎ani 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ć
‎w ramach Usług Utrzymania. Należy wskazać, iż w momencie składania ofert Wykonawca nie ma żadnych informacji w oparciu, o które mógłby przewidzieć ilość, częstotliwość, a przede wszystkim konieczny zakres dostosowania Systemu do nowych wersji Oprogramowania gotowego – a zatem nie można wycenić tej usługi.

Tym samym Wykonawca w oparciu o tak postawione wymagania nie jest w stanie skalkulować ceny oferty z uwagi na zupełnie nieokreślony zakres. Konieczność dostosowywania Systemu do nowych wersji Oprogramowania gotowego może okazać się istotną i kosztowną przebudową, której jednak nie da się wycenić na etapie przygotowania oferty. zmodyfikowanie punktu 5.4.1. ppkt 3) w następujący sposób:

Żądanie:

Wobec powyższego wniósł o:

1.zmodyfikowanie punktu 5.4.1. ppkt 3) w następujący sposób:

2.modyfikacje punktu 4.2.3 poprzez dodanie ppktu 6)

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;

6) ze zmian Oprogramowania gotowego wykorzystywanego przez System.

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

1.Obecne w OPZ punkt 5.4.1 6) zawarte jest brzmienie:

„W ramach konserwacji Systemu Wykonawca zobowiązany będzie do:

(…)

6) dostosowania Systemu, przy uwzględnieniu także konieczności zmiany wersji komponentów Systemu, do nowych lub zaktualizowanych komponentów Platformy Sprzętowo-Programowej stosowanych w Systemie, wynikającego z:

a) instalacji, rekonfiguracji i aktualizacji oprogramowania systemowego, narzędziowego i aplikacyjnego,

b) instalacji poprawek dla oprogramowania systemowego, narzędziowego i aplikacyjnego,

c) instalacji i aktualizacji sterowników do zainstalowanych urządzeń lub podzespołów,

d) instalacji i konfiguracji podzespołów oraz urządzeń dodatkowych np. kart rozszerzeń, modułów usługowych, urządzeń zewnętrznych, itp., wspieranych przez przedstawiciela bądź producenta sprzętu,

e) rekonfiguracji systemów pamięci masowych w zakresie zmiany trybu pracy, organizacji przestrzeni dyskowej, udostępniania obszarów dyskowych do serwerów np. zmiana trybu RAID, zmiana numeracji LUN itp.,

f) wymiany komponentów sprzętowych, modułów lub podzespołów w związku z awarią lub uszkodzeniem,

g) modyfikacji konfiguracji sprzętowej,

h) przeniesienia maszyn wirtualnych na inny serwer fizyczny lub inną platformę sprzętową,

i) uaktualnienia oprogramowania wewnętrznego (tzw. firmware),

usuwania ujawnionych podatności bezpieczeństwa, w terminie wskazanym przez Zamawiającego.”

Odwołujący podał, że w momencie składania ofert Wykonawca nie ma żadnych informacji
‎w oparciu, o które mógłby przewidzieć ilość, częstotliwość a przede wszystkim konieczny zakres dostosowania Systemu do nowych lub zaktualizowanych komponentów Platformy Sprzętowo-Programowej stosowanych w Systemie. Zamawiający nie określił w wymaganiu warunków realizacji, w szczególności nie wskazał jak często ani do jakich wersji oprogramowania Platformy Sprzętowo-Programowych ma być dostosowany System. Przedstawiony wymóg dostosowywania Systemu jest na etapie przygotowania oferty niemożliwy do oszacowania a jest istotnym i kosztownym zadaniem, w szczególności
‎w zakresie przebudowy Oprogramowania dedykowanego systemu SZPROT.

Wynagrodzenie za Konserwację Systemu jest wynagrodzeniem ryczałtowym – a nie jest możliwe na dzień złożenia oferty wycenić tych usług. Odwołujący nie przeczy, że taka usługa może okazać się konieczna w toku realizacji Umowy i użytkowania systemu przez Zamawiającego – jednakże Zamawiający nie może całego ryzyka związanego z jej realizacją przerzucać na wykonawcę. W przypadku tego typu usług – tj. usług, których pracochłonności nie da się określić na dzień złożenia oferty – wynagrodzenie za ewentualne wykonanie takiej usługi w przyszłości powinno być określane osobno dla każdego przypadku zlecanego przez Zamawiającego. Zamawiający przewidział taką pulę usług w rozdziale 4.2 Rozwój
‎na Zgłoszenie pkt 4.2.3 ppkt. 5

Żądanie:

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

1.Usunięcie wymagania opisanego OPZ punkt 5.4.1 6) z usługi Konserwacji Systemu

2.Dodanie przedmiotowej usługi do zadań realizowanych w ramach Rozwoju na Zgłoszenie.

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

Obecne w OPZ punkt 5.4.1 7) zawarte jest brzmienie:

„5.4.1.

W ramach konserwacji Systemu Wykonawca zobowiązany będzie do:

(…)

7) przeniesienia Systemu na nowe bloki architektoniczne w związku ze zmianą Platformy Sprzętowo-Programowej i uruchomienie na nowych blokach, nie częściej niż raz na 2 lata;

Odwołujący podał, że w momencie składania ofert Wykonawca nie ma żadnych informacji
‎w oparciu, o które mógłby przewidzieć zakres prac koniecznych do wykonania. Jeżeli Zamawiający planuje modyfikacje w blokach architektonicznych, to powinien w SWZ opisać planowane zmiany tak, aby potencjalny wykonawca miał możliwości oszacowania kosztów realizacji tego zadania. Należy podkreślić, że zmiana bloków architektonicznych w praktyce oznacza nowe wdrożenie Systemu (co powinno być zadaniem Usług Rozwoju
‎na Zgłoszenie). Ponadto zmiany w blokach architektonicznych mogą wiązać się
‎z koniecznością dostosowania do nich Systemu jak i konieczności wymiany lub aktualizacji Oprogramowania gotowego. Zamawiający nie określił kto w takim przypadku będzie zobowiązany do dostarczenia nowych wersji lub aktualizacji, a jeśli obowiązek ten będzie spoczywał na Wykonawcy, co pośrednio może wynikać z definicji Platformy Programowej jak i obecności w Umowie § 7 opisującego wymagania dotyczącego dostarczanych licencji COTS, to brak informacji o zmianach w blokach uniemożliwia wyliczenia kosztu zakupu licencji. Obecne zastosowane Oprogramowanie gotowe posiada ograniczenia, tj. producenci tego oprogramowania mogą nie gwarantować poprawnego działania z aktualnymi wersjami oprogramowania, więc może okazać się w danym przypadku, że usługa przeniesienia może być niewykonalna – byłaby to zatem umowa o świadczenie niemożliwe.

Możliwość realizacji danej usługi przeniesienia jest możliwa do oceny tylko ad causam,
‎w przypadku zgłoszenia przez Zamawiającego konkretnych zadań przeniesienia.

Żądanie:

Mając powyższe na uwadze Odwołujący wniósł o:

a.Doprecyzowanie zmian zastosowanych w nowych blokach architektonicznych
‎w stosunku do obecnych ew. zapewnienie, że nowe bloki nie wprowadzają zmian.

b.Określenie, że w przypadku konieczności zmiany lub aktualizacji Oprogramowania gotowego Zamawiający jest odpowiedzialny za zapewnienie licencji lub aktualizacji.

c.Zapewnienie, że nowe bloki architektoniczne będą zgodne z rekomendacjami producentów zastosowanego Oprogramowania gotowego.

d.Zapewnienie, że oprogramowanie zastane Systemu SZPROT zostanie dostosowane do nowych bloków architektonicznych w ramach Usług Rozwoju na Zgłoszenie.

Alternatywnie - jeśli powyższe nie jest możliwe, Odwołujący wnosi o wykreślenie wymagania i realizację całego zadania w ramach Usług Rozwoju na Zgłoszenie.

Ad. 16

Zarzut: XVI: TOM III SWZ – 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.

Obecne w TOM III SWZ – OPZ pkt. 5.4.1 9) zawarte jest brzmienie:

uwzględnienia uwag Zamawiającego do zapewnienia dostępności cyfrowej Systemu sformułowanych na podstawie informacji, o której mowa w pkt 3.5.2., w terminie wskazanym przez Zamawiającego.

Obecne w TOM III SWZ – OPZ pkt. 5.4.3 zawarte jest brzmienie:

„W przypadku zakresu wskazanego w pkt 5.4.1. ppkt. 6, 7 i 9, Zamawiający przekaże Wykonawcy Zgłoszenie konserwacji za pośrednictwem systemu CSD lub poczty elektronicznej. Wykonawca po otrzymaniu Zgłoszenia konserwacji ma obowiązek wykonania czynności konserwacyjnych w terminie określonym w Zgłoszeniu konserwacji. W Zgłoszeniu konserwacji Zamawiający określi ich przedmiot i termin realizacji.”

W propozycji OPZ Zamawiający nie wskazał konkretnego planu jego aktualizacji, czy jasnych wymagań, do jakich wersji oprogramowania System musi być zaktualizowany. Co ważne – Zamawiający wskazał, że dostosowanie Systemu ma odbyć się w oparciu
‎o niesprecyzowane przesłanki „uwzględnienia uwag Zamawiającego” czy „do nowych lub zaktualizowanych komponentów Platformy Sprzętowo-Programowej” – czyli Zamawiający świadomie na etapie składania ofert tworzy sytuacje, w której nie jest znany zakres obowiązków Wykonawcy. W w/w wymaganiach Zamawiający więc oczekuje od Wykonawcy dostosowania Systemu o nieokreślonej na moment podpisywania Umowy skali i ilości wystąpień, przy jednoczesnym utrzymaniu wymaganych parametrów wydajnościowych Systemu w terminach przez siebie jednostronnie określonych. Wymagania te nie uwzględniają uwarunkowań technicznych, np. czy ze względu na zakres prac termin w ogóle może być do dotrzymania, nie uwzględnia czasu potrzebnego do przeprowadzenia testów regresji, nie uwzględnia kolizji z innymi już zaplanowanymi pracami, nie uwzględnia czasu potrzebnego na dostosowanie Sytemu do zmian. Wykonawcy pozostaje tylko liczyć na dobrą wolę Zamawiającego w określeniu wskazanego terminu.

Żądanie:

Mając powyższe na uwadze Odwołujący wniósł o następujące modyfikacje treści:

1.zmiana treści TOM III SWZ – OPZ pkt. 5.4.1 9):

„uwzględnienia uwag Zamawiającego do zapewnienia dostępności cyfrowej Systemu sformułowanych na podstawie informacji, o której mowa w pkt 3.5.2., w terminie uzgodnionym przez Strony

2.o usunięcie wymagania TOM III SWZ – OPZ pkt. 5.4.3.

Ad.17

Zarzut: XVII: TOM III SWZ – OPZ – Załącznik nr 2 do OPZ Rozwój Zdefiniowany oraz TOM I SWZ – IDW Formularz cenowy nr 2.2. - Naruszenie art. art. 431 ust. 1 pkt 1 PZP poprzez nieprawidłowe określenie terminów wykonania zadań w datach kalendarzowych zamiast w dniach, tygodniach, miesiącach lub latach.

W Formularzu cenowym nr 2.2 dla Załącznika nr 2 do OPZ – Rozwój Zdefiniowany, Zamawiający w kolumnie F przewidział terminy dostarczania poszczególnych Zadań. Dodatkowo w Załączniku nr 2 do OPZ Opis wymagań w zakresie Rozwoju Zdefiniowanego Zamawiający wskazał datę dostarczenia każdego zadania wymienionego w niniejszym załączniku. Zatem ustalił końcowy termin, do którego mają zostać wykonane poszczególnego zadania, wskazując konkretną datę kalendarzową.

Takie określenie terminu realizacji zakończenia usługi jest sprzeczne jest z obligatoryjnymi postanowieniami umowy - Ustawodawca w art. 436 ust. 1 pkt 1 Ustawy Pzp wyraźnie nałożył na Zamawiającego obowiązek przedstawienia daty w dniach, tygodniach, miesiącach lub latach. Jedynie wyjątkowo możliwe jest wskazanie przez zamawiającego daty wykonania umowy, gdy jest to uzasadnione obiektywną przyczyną. Jednak takiej sytuacji Zamawiający nie wskazał w OPZ – w szczególności nie wskazał w Ogłoszeniu o zamówieniu, że projekt zamówienia nie jest finansowany z funduszy UE lub też, że wprowadzenie w/w zmian
‎w Systemie wynika z terminów ustawowych, np. wejście w życie jakiegoś nowego przepisu, aktualizującego nowe obowiązki dla Zamawiającego, realizowane wyłącznie przez system SZPROT.

Zatem można stwierdzić, że Zamawiający uchybił postanowieniu art. 436 ust. 1 pkt 1 Ustawy Pzp wskazując daty kalendarzowe. Termin dostarczenia poszczególnych zadań jest istotnym elementem umowy i nic nie stoi na przeszkodzie, aby był on określony poprzez odniesienie do dnia zawarcia umowy, np. wskazując na okres dni, tygodni, miesięcy czy lat od dnia zawarcia umowy. Określenie terminu datą dzienną powinno być wyjątkiem i może być zastosowane tylko wtedy, gdy jest to uzasadnione obiektywną przyczyną. W pozostałych przypadkach termin ten powinien być określony w dniach, tygodniach, miesiącach lub latach.

Żądanie:

Mając powyższe na uwadze Odwołujący wniósł o:

Wykreślenie w Formularzu cenowym nr 2.2 dla Załącznika nr 2 do OPZ – Rozwój Zdefiniowany, Zamawiający oraz Załączniku nr 2 do OPZ Opis wymagań w zakresie Rozwoju Zdefiniowanego dat kalendarzowych oraz wprowadzenie w to miejsce terminów dostarczenia zadań w dniach, tygodniach, miesiącach lub latach od daty zawarcia umowy.

Ad. 18

Zarzut XVIII: TOM III SWZ – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 3 (SZPROT_WFOG_4) - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP – poprzez 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.

Obecne w zał. 2 do OPZ punkt 3.2 zawarte jest brzmienie:

„Celem zadania jest implementacja serwera Wildfly w najnowszej wersji, co umożliwi usunięcie podatności bezpieczeństwa oraz kompatybilność z innymi Komponentami w najnowszych wersjach.

Obecnie System wykorzystuje Wildfly w wersji 14 oraz OpenJDK 8. Po zaktualizowaniu serwera aplikacji Wildfly wykorzystywane będzie OpenJDK w najnowszej wersji LTS dostępnej wersji na dzień rozpoczęcia Usługi Utrzymania (obecnie to OpenJDK 21). W ramach zadania Zamawiający dostarczy nowe bloki architektoniczne ze zaktualizowanymi Komponentami, takimi jak Wildfly, baza danych PostgreSQL, pgPool.

Przedmiotem zamówienia jest dostosowanie Systemu SZPROT do wykorzystania zaktualizowanych Komponentów i przeniesienie Systemu na nowe bloki architektoniczne.”

Odwołujący podkreślił, że tak zdefiniowane zadanie nie precyzuje:

a) nr wersji oprogramowania, do którego należy System dostosować z uwagi
‎na sformułowanie „w najnowszej wersji dostępnej na dzień rozpoczęcia Usługi Utrzymania”,

b) specyfikacji nowych bloków architektonicznych ze zaktualizowanymi Komponentami takimi jak WildFly, baza danych PostreSQL, pgPool, które będą dostarczone przez Zamawiającego w przyszłości,

c) pełnej listy komponentów i ich technologii, na których zadanie miałoby być realizowane,

co w przypadku realizacji zadań związanych ze zmianami użytych technologii i oceny
‎ich wpływu na systemy o dużej złożoności integracji pomiędzy różnymi komponentami
‎i użytymi w nich technologiami – stanowi kluczową informację. Zatem Wykonawca w chwili składania oferty nie jest w stanie ustalić zakresu prac umożliwiającego dokonanie wyceny
‎i oszacować czasu trwania przedmiotowego zadania – co skutkuje tym, że nie jest możliwe dokonanie wyceny oferty w tym zakresie.

Z drugiej strony – jeśli wymaganie to jest dla Zamawiającego konieczne, to należy rozważyć jego realizację w ramach Rozwoju na Zgłoszenie.

Żądanie:

Mając powyższe na uwadze Odwołujący wniósł o usunięcie zadania opisanego w zał. 2
‎do OPZ punkt 3 z zakresu Rozwoju Zdefiniowanego i realizację tego zadania w ramach Rozwoju na Zgłoszenie.

Ad.19

Zarzut XIX: TOM III SWZ – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 6 (SZPROT_WFOG_7) - 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 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.

Obecne w zał. 2 do OPZ punkt 6.2 zawarte jest brzmienie:

„Celem wymagania jest zapewnienie w Systemie SZPROT kompletu danych (poprzez rozbudowę bazy operacyjnej SZPROT) potrzebnych do zasilania Komponentów Komunikacyjnych SZPROT na PUESC oraz zapewnienie spójności danych.

Obecnie System SZPROT w bazie relacyjnej nie posiada kompletnych danych biznesowych. Część z tych danych znajduje się w odpowiednich słownikach PDR PL/UE i jest traktowana jako baza referencyjna dla systemów operacyjnych i Komponentów Komunikacyjnych Systemu SZPROT na PUESC. Część danych znajduje się również w repozytorium CRKiD (w SEAP).

Po zmianach, dane powinny zapisywać się w Systemie SZPROT w jego lokalnej bazie danych. W bazie danych Systemu mają zapisywać się dane zarówno z wniosków, jak i wydanych pozwoleń /zezwoleń/decyzji. Następnie dane z Systemu SZPROT powinny być replikowane do słowników PDR PL/UE.

W systemie SZPROT Wykonawca wytworzy mechanizm zapewniający spójność danych replikowanych do bazy PDR PL/UE z danymi w Systemie SZPROT. Nadrzędną bazą danych ma być baza Systemu SZPROT, a baza PDR PL/UE musi być z nią spójna. System SZPROT ma również posiadać mechanizm przywracania spójności danych w przypadku, gdyby spójność została naruszona. […]”

I dalej:

„Docelowo korzystanie z bazy danych SZPROT zastąpi korzystanie ze słowników PDR PL/UE. Wszędzie w zadaniach w załączniku nr 2 gdzie występuje odwołanie do pobierania danych ze słowników PDR PL/UE należy rozumieć po tej zmianie jako odwołanie do nowej bazy Systemu SZPROT.”

Zdaniem Odwołujacego tak zdefiniowane zadanie nie precyzuje pełnego zakresu prac. Ponadto z treści zadania wynika, że stanowi bardzo złożony, wieloetapowy proces zmiany architektury Systemu, polegający na odwróceniu zależności integracji pomiędzy Systemem
‎a dwoma innymi (PDR PL/U, CRKiD w SEAP) kluczowymi systemami Zamawiającego oraz zapewnieniu mechanizmów zachowania i przywracania spójności pomiędzy wskazanymi systemami. Dla tak skomplikowanej zmiany architektonicznej oszacowanie
‎jej pracochłonności wymaga podania w OPZ informacji na temat szczegółowych wymagań technicznych dotyczących sposobu jej realizacji, w tym założeń i ograniczeń związanych
‎z realizacją tego zadania.

Żądanie:

Mając powyższe na uwadze Odwołujący wniósł o:

a)Uzupełnienie zadania o szczegóły techniczne dotyczące sposobu jej realizacji, w tym założeń i ograniczeń lub o dołączenie projektu technicznego zmiany (lub równoważnego opracowania – jeśli takie istnieje)

lub

b)usunięcie zadania opisanego w zał. 2 do OPZ punkt 6 z zakresu Rozwoju Zdefiniowanego i realizację tego zadania w ramach Rozwoju na Zgłoszenie.

Ad.20

Zarzut XX: TOM III SWZ – 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 – poprzez 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_WFED_3, SZPROT_WFOG_12 , SZPROT_WFOG_44 ( zał. 2 do OPZ odpowiednio punkty: 48, 14, 123).

Obecne w zał. 2 do OPZ punkt 9.2 zawarte jest brzmienie:

„Celem modyfikacji jest dostosowanie formularzy wniosków o wydanie decyzji, pozwolenia, do wymagań wynikających z:

przepisów unijnych lub krajowych,

zmian w modelu danych w innych systemach, np. EOS, PDR PL/UE,

potrzeb Zamawiającego.

Modyfikacji wymaga także obsługa (proces) tych wniosków w postępowaniu w Systemie SZPROT. Ponadto modyfikacji wymaga także zakres danych i ich format w rejestrach pozwoleń.

Modyfikacji wymagają szablony wydawanych pozwoleń, decyzji (także tych wydawanych
‎„z urzędu”). Dane rozstrzygnięcia są przekazywane do innych systemów wewnętrznych SISC i zewnętrznych (poza systemami SISC). […]”

I dalej:

„Model danych dotyczący wniosków/pozwoleń celnych wymienionych w załączniku A
‎do rozporządzenia delegowanego i wykonawczego do Unijnego Kodeksu Celnego nie jest stały i będzie podlegał kolejnym zmianom w związku ze zmianami tych rozporządzeń. […]”

I dalej:

„Pełny zakres zmian w Komponentach Komunikacyjnych (formularzach) wniosków będzie przedmiotem prac analitycznych i warsztatów z Wykonawcą. […]”

I dalej:

„Nowe funkcjonalności dla wniosków będą dotyczyły przykładowo: [lista kilkunastu przykładów] […]”

I dalej:

„Nowe funkcjonalności dla procesów będą dotyczyły przykładowo: [lista kilkunastu przykładów] […]”

I dalej:

„Zakres modyfikacji pozwoleń celnych, decyzji dotyczą przykładowo: [lista kilku przykładów] […]”

Odwołujący podkreślił, że tak zdefiniowane zadanie:

a)w żaden sposób nie precyzuje zakresu jak również nie określa liczebności wystąpień wymagań, z których ma wynikać obowiązek realizacji zakresu zadania, tj.: nie zawiera ostatecznej treści przepisów unijnych lub krajowych, zmian w modelu danych w innych systemach, potrzeb Zamawiającego,

b)w żaden sposób nie precyzuje w sposób pełny zakresu oczekiwanych modyfikacji, przy czym brak takiego określenia dotyczy również zadania odnośnego: SZPROT_WFOG_12,

c)w żaden sposób nie precyzuje ani nie ogranicza liczby elementów, w których modyfikacje są oczekiwane, przy czym dotyczy to również zadań odnośnych: SZPROT_ WFED_3 oraz SZPROT_WFOG_44,

d)w swojej treści z góry zakłada, iż ich pełny zakres dopiero w toku prac projektowych „będzie przedmiotem prac analitycznych i warsztatów”.

Zatem Wykonawca w chwili składania oferty nie jest w stanie ustalić zakresu prac umożliwiającego dokonanie wyceny i czasu trwania przedmiotowego zadania, jak również wskazanych zadań odnośnych.

Żądanie:

Mając powyższe na uwadze Odwołujący wniósł o usunięcie zadania opisanego w zał. 2
‎do OPZ punktów 9, oraz zadań odnośnych opisanych w punktach: 48, 14, 123 z zakresu Rozwoju Zdefiniowanego i realizację tych zadań w ramach Rozwoju na Zgłoszenie.

Ad.21

Zarzut XXI: TOM III SWZ – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkty 9, 10, 11 (SZPROT_WFED_36_A, SZPROT_WFED_36_B, SZPROT_WFEK_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.

Obecne w zał. 2 do OPZ punkt 9.2, 10.2, w punktach listujących zakres prac, zawarte jest wymaganie o brzmieniu: „dostosowanie szablonów wydruków z uwzględnieniem mechanizmu dziedziczenia (Wymaganie: SZPROT_WFOG_12).”, a w punkcie 11.2: „zastosowanie mechanizmu dziedziczenia elementów szablonów wydruków w Systemie SZPROT”.

W toku spotkań Wykonawcy z Zamawiającym podczas etapu Wstępnych Konsultacji Rynkowych dla przedmiotowego postępowania, Wykonawca zwrócił uwagę na aspekt dziedziczenia elementów szablonów wydruku jako technicznie niemożliwy do realizacji. Wówczas aspekt ten dotyczył również odnośnego wymania: SZPROT_WFOG_12.
‎Na obecnym etapie postępowania, Zamawiający w zał. 2 do OPZ w kontekście wymagania SZPROT_WFOG_12 usunął wymaganie na dziedziczenie, jednocześnie pozostawił wymaganie dziedziczenia w przedmiotowych 3 wymaganiach, tj. SZPROT_WFED_36_A, SZPROT_WFED_36_B, SZPROT_WFEK_32.

Żądanie:

Mając powyższe na uwadze Odwołujący wniósł o usunięcie wymagania dotyczącego dziedziczenia elementów szablonów wydruku również z punktów 9.2, 10.2, 11.2 zał. 2
‎do OPZ.

Ad. 22

Zarzut XXII: TOM III SWZ – 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 – poprzez 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ń.

Obecne w zał. 2 do OPZ punkt 26.2 zawarte jest brzmienie:

„Celem zadania jest dostarczenie administratorom funkcjonalności edycji wszystkich ostrzeżeń wykorzystywanych w Systemie SZPROT dzięki czemu ostrzeżenia będą bardziej zrozumiałe dla użytkownika. […]”

W treści definicji zadania nie określono ilości ostrzeżeń do konfiguracji. Przy nieokreślonym wymiarze Wykonawca nie jest w stanie oszacować kosztów realizacji zadania. Ponadto część ostrzeżeń wynika z zastosowanej technologii i jest poza możliwością konfiguracji tworzonego systemu/oprogramowania lub zachodzi sytuacja, w której komunikat jest wspólny dla wszystkich elementów danego typu, a w z związku z tym zadanie jest niemożliwe do realizacji.

Żądanie:

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

1.usunięcie zadania opisanego w zał. 2 do OPZ punkt 3 z zakresu Rozwoju Zdefiniowanego i realizację tego zadania w ramach Rozwoju na Zgłoszenie

lub

1.zdefiniowanie listy ostrzeżeń, które mają podlegać konfiguracji.

Ad. 23

Zarzut XXIII: TOM III SWZ – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 32 (SZPROT_WFOG_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.

Obecne w zał. 2 do OPZ punkt 32.2 zawarte jest brzmienie:

„Komponenty Komunikacyjne muszą być realizowane zgodnie z wytycznymi zawartymi
‎w Specyfikacji Komponentów Komunikacyjnych PUESC, które zostaną przekazane
‎po zawarciu Umowy. ”

Odwołujący podał, że tak zdefiniowane zadanie odnosi się do wymagań i wytycznych niedostępnych dla Wykonawcy przed złożeniem oferty, a jako takie nie jest możliwe określenie przez Wykonawcę kosztu jego realizacji. Nie jest zrozumiałe, dlaczego Zamawiający nie załączył tych wytycznych do dokumentacji postepowania. Zakres obowiązków wykonawcy powinien być określony w dokumentacji postepowania i nie jest dopuszczalne, aby zakres ten był ustalany przez Zamawiającego po zawarciu umowy, poprzez dostarczenie wskazanego w OPZ dokumentu.

Żądanie:

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

a)Udostępnienie / dodanie do zadana wytycznych, o których mowa w treści zadania,

lub

b)usunięcie zadania opisanego w zał. 2 do OPZ punkt 32 z zakresu Rozwoju Zdefiniowanego i realizację tego zadania w ramach Rozwoju na Zgłoszenie.

Ad. 24

Zarzut XXIV: TOM III SWZ – 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 poprzez opisanie przedmiotu zamówienia w sposób niemożliwy
‎do zrealizowania, co skutkuje niemożnością przygotowania oferty.

Obecne w zał. 2 do OPZ punkt 51.2 zawarte jest wymaganie o brzmieniu:

„Celem jest zapewnienie użytkownikom wewnętrznym SZPROT elastycznego zarządzania adresatami (innymi niż odbiorcy główni) dokumentów tworzonych w systemie oraz wyboru załączników dla poszczególnych adresatów.”.

Odwołujący uzasadniał, że ze względu na zapisy dotyczące różnej listy załączników
‎dla każdego adresata – zadanie nie jest możliwe do realizacji. Pojedyncze pismo zawiera listę załączników do niego podłączonych. Jeśli każdy adresat („Do wiadomości”) mógłby otrzymywać inny zestaw załączników pisma, oznaczałoby to, że trzeba by tworzyć kilka różnych pism (dla różnych zestawów) – ponieważ w przeciwnym przypadku podpisane pismo wraz z załącznikami utraciłoby nienaruszalność podpisu i integralność dokumentu
‎i jego wszystkich załączników. Powyższe skutkuje tym, że wykonawca na etapie sporządzenia oferty nie ma możliwości wyceny usługi niemożliwej do wykonania. wykreślenie oczekiwania dotyczącego możliwości wysyłki różnego zestawu załączników
‎do pisma dla różnych adresatów z zakresu Usług Rozwoju Zdefiniowanego Dopuszczenie tworzenia odrębnych pism w zależności od potrzeb wysyłki różnych zestawów załączników.

Żądanie:

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

a)wykreślenie oczekiwania dotyczącego możliwości wysyłki różnego zestawu załączników do pisma dla różnych adresatów z zakresu Usług Rozwoju Zdefiniowanego

lub

b)Dopuszczenie tworzenia odrębnych pism w zależności od potrzeb wysyłki różnych zestawów załączników.

Ad.25

Zarzut XXV: TOM III SWZ – 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 – poprzez 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.

Obecne w zał. 2 do OPZ punkt 55.2 zawarte jest brzmienie:

„[…] Obecnie jest nie jest możliwe ukrycie/wyłączenie dokumentu z akt sprawy. W Systemie SZPROT konieczne jest zbudowanie funkcjonalności pozwalającej w zakładce "Dokumenty" na odznaczenie dokumentów, które nie powinny być widoczne w teczce dokumentów
‎do udostępnienia. […]”

Pełny zakres biznesowej funkcjonalności teczki akt (sprawy) jest obecnie zaimplementowany zarówno po stronie systemu SZPROT jak i systemu SEAP (niebędącego przedmiotem niniejszego postępowania). Dopiero dokonanie odpowiednich i uzgodnionych na etapie projektowania zmian w obu systemach umożliwi realizację funkcjonalności wymaganej przez Zamawiającego. W związku z tym, że realizacja wymagania SZPROT_WFED_11 polegająca na modyfikacji obecnej funkcjonalności teczki akt, jest uzależniona od sposobu realizacji modyfikacji po stronie systemu SEAP niemożliwe jest oszacowanie na etapie przygotowania kosztów realizacji tej zmiany jak i również potwierdzenia terminu jej realizacji.

Żądanie:

Mając powyższe na uwadze Odwołujący wniósł o przeniesienie realizacji wymagania
‎do Usług Rozwoju na Zgłoszenie.

Ad.26

Zarzut XXVI: TOM III SWZ OPZ - Załącznika nr 6 do OPZ (Zasady przeprowadzania testów) pkt 1 ppkt 12 poprzez 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 poprzez opisanie w sposób niemożliwy do oszacowania kosztu realizacji oraz w niektórych przypadkach sposób niemożliwy do realizacji.

Pkt 1 ppkt 12 Załącznika nr 6 do Opisu Przedmiotu Zamówienia Zamawiający wskazuje, że:

„Szczegółowe definicje oraz opis Procesu testowania reguluje Metodyka testowania, która zostanie udostępniona Wykonawcy po zawarciu Umowy”

Odwołujący podał, że Metodyka testowania jest podstawowym i niezwykle istotnym dokumentem z punktu widzenia procesu testowego, a zawarte w niej postanowienia mają kluczowy wpływ na zakres i sposób przeprowadzania testów automatycznych, akceptacyjnych. W konsekwencji mają wpływ na zakres, sposób realizacji oraz możliwość oszacowania pracochłonności prac leżący po stronie Wykonawcy. W związku z powyższym Odwołujący stoi na stanowisku, że brak takiego dokumentu na etapie przygotowywania oferty uniemożliwia dokonanie poprawnej kalkulacji ceny oferty w tym zakresie, jak również nie pozwala ocenić czy oczekiwana przez Zamawiającego Metodyka testowania jest możliwa do zrealizowania.

Żądanie:

Wobec powyższego Wykonawca wniósł o dokonanie modyfikacji SWZ przez dołączenie dokumentu Metodyka testowania do dokumentacji postepowania oraz odpowiednią zmianę terminu złożenia oferty, umożliwiającą dokonanie kalkulacji oferty w tym zakresie.

Sygn. akt KIO 2125/24

W dniu 17 czerwca 2024 roku Odwołujący wykonawcę Comarch Polska spółka akcyjna działając na podstawie art. 513 pkt 2 oraz art. 515 ust. 2 pkt 1 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 wobec dokumentów zamówienia.

Odwołujący zarzuciła Zamawiającemu naruszenie następujących przepisów:

1) art. 134 ust. 1 pkt. 4 PZP, art. 99 ust. 1 oraz art. 353[1] kodeksu cywilnego w zw.
‎z art. 8 ust 1 PZP, w zw. z art. 16 i 17 PZP - brak udostępnienia niezbędnych informacji
‎o systemie umożliwiających oszacowanie nakładów pracy na realizację przewidzianych umową usług;

2) art. 134 ust. 1 pkt. 4 PZP, art. 99 ust. 1 PZP w zw. z art. art. 16 i 17 PZP i art. 353[1] kc. w zw. z art. 8 ust. 1 PZP – niejasny/nieprecyzyjny opis wymagań Rozwoju Zdefiniowanego uniemożliwiający rzetelne oszacowanie jego kosztów;

3) art. 134 ust. 1 pkt. 4 PZP, art. 99 ust. 1 oraz art. 353[1] kodeksu cywilnego w zw.
‎z art. 8 ust 1 PZP oraz art. 16 i 17 PZP - udostępnienie informacji o systemie w sposób uniemożliwiający oszacowanie nakładów pracy na realizację zadań przewidzianych
‎w ramach Rozwoju Zdefiniowanego;

4) art. 134 ust. 1 pkt. 4 PZP, art. 99 ust. 1 oraz art. 353[1] kodeksu cywilnego w zw.
‎z art. 8 ust 1 PZP oraz art. 16 i 17 PZP - brak gwarantowanego czasu na przygotowanie się do świadczenia usług;

5) art. 353[1] kodeksu cywilnego oraz art. 387 § 1 kodeksu cywilnego w zw. z art. 8 ust. 1 PZP - ustanowienie terminów dostarczenia poszczególnych zadań Rozwoju Zdefiniowanego w datach sztywnych (określonych kalendarzowo), których dotrzymanie przez Wykonawcę jest w praktyce niemożliwe lub mało prawdopodobne;

6) art. 134 ust. 1 pkt. 4 PZP, art. 99 ust. 1 oraz art. 353[1] kodeksu cywilnego w zw.
‎z art. 8 ust 1 PZP oraz art. 16 i 17 PZP – niejasny/nieprecyzyjny opis Zadania nr 9 Rozwoju Zdefiniowanego uniemożliwiający rzetelne oszacowanie kosztów jego realizacji oraz konieczności zapewnienia parametrów wydajnościowych o nieznanej wysokości.

Odwołujący wniósł o uwzględnienie niniejszego odwołania i nakazanie Zamawiającemu modyfikacji dokumentów zamówienia w sposób określony w uzasadnieniu odwołania.

Odwołujący podał, że ma interes w uzyskaniu zamówienia w rozumieniu art. 505 ust. 1 PZP oraz poniósł lub może ponieść szkodę w wyniku naruszenia przez Zamawiającego wskazanych przepisów ustawy, ponieważ nieprawidłowe postanowienia dokumentów zamówienia mogą uniemożliwić złożenie Odwołującemu oferty.

W uzasadnieniu zarzutów odwołania:

Ad.1

Naruszenie art. 134 ust. 1 pkt. 4 PZP, art. 99 ust. 1 oraz art. 353[1] kodeksu cywilnego w zw. z art. 8 ust 1 PZP, w zw. z art. 16 i 17 PZP - brak udostępnienia kluczowych informacji bezpośrednio wpływających na oszacowanie kosztów świadczenia Usługi Utrzymania

Sporządzając ofertę w postępowaniu na utrzymanie dowolnego systemu, które obejmuje usuwanie awarii, błędów czy wad, wykonawca musi wziąć pod uwagę trzy aspekty:

reżim SLA, tj. wymagany czas naprawy awarii, błędów czy wad;

statystyczną częstotliwość występowania awarii, błędów i wad;

etap cyklu życia produktu na jakim znajduje się System oraz jego poszczególne komponenty/moduły/procesy.

Złożenie tych trzech elementów pozwala oszacować pracochłonność oraz liczbę etatów zespołu, który powinien zostać skierowany do realizacji zadań utrzymaniowych –
‎a w rezultacie – oszacować koszty realizacji zamówienia i wycenę oferty. Oczywistym jest, że inny zespół będzie wymagany do utrzymania systemu ustabilizowanego, a inny
‎w przypadku systemu na świeżo oddanego do eksploatacji, w którym częstotliwość występowania błędów będzie początkowo dużo większa. Oczywistym jest również, iż System ulegający częstym awariom wymagać będzie większej liczby specjalistów, ponieważ żaden specjalista nie jest w stanie obsługiwać więcej niż określoną liczbę problemów jednocześnie. Historyczne statystyki dają Wykonawcy obraz tego, jak kształtuje się dotychczasowa awaryjność systemu, a więc pośrednio wiedzę o jakości jego wykonania, potencjalnych obszarach problemowych, czy w końcu o klasie występujących w Systemie błędów i ich potencjalnej złożoności. Wiedza historyczna pozwala oszacować potencjalną pracochłonność w przyszłości, jeżeli nie wprost, to przez oszacowanie ryzyka wystąpienia zwiększonej pracochłonności związanej z usuwaniem błędów czy awarii. Bez takiej wiedzy sporządzenie wyceny może być zatem niemożliwe.

Tymczasem Zamawiający, opisując System SZPROT, nie zawarł w OPZ żadnej informacji
‎na temat tego, na jakim etapie budowy znajdują się poszczególne komponenty Systemu SZPROT, czy wszystkie procesy opisane w OPZ zostały uruchomione produkcyjnie, oraz czy System posiada jakiekolwiek zdiagnozowane i zarejestrowane błędy. Zamawiający
‎nie zawarł też w SWZ żadnej statystyki awarii, wad, błędów oraz problemów które miały miejsce w odpowiednim, miarodajnym okresie poprzedzającym ogłoszenie zamówienia.

Brak takich informacji jest istotną wadą SWZ uniemożliwiającą sporządzenie oferty, pozbawia bowiem Wykonawców informacji kluczowej, tj. jak stabilny lub jak bardzo awaryjny jest System, za którego utrzymanie Wykonawca ma wziąć odpowiedzialność w trakcie realizacji zamówienia. Odwołujący podkreśla, że zgodnie z art. 134 ust. 1 pkt 4 PZP w SWZ Zamawiający ma obowiązek dokonać opisu przedmiotu zamówienia,
‎a zgodnie z art. 99 ust. 1 PZO opis ten powinien być wyczerpujący i precyzyjnie opisany, gdyż Wykonawca, przygotowując ofertę, opiera się na informacjach zawartych w SWZ (i OPZ).

Odwołujący podkreślił, że Wykonawca, składając ofertę, ma obowiązek oszacować pracochłonność utrzymania nie abstrakcyjnego, teoretycznego systemu, ale systemu istniejącego faktycznie i mającego konkretne określone cechy. Tymi cechami jest miedzy innymi sposób zaimplementowania określonych procesów czy funkcji, wyrażający się między innymi tym, czy działają one w sposób poprawny, czy też wymagają manualnej interwencji, ponieważ występują w nich błędy.

Podkreślił, iż zamieszczone w Załączniku nr 1 do OPZ - Opis Systemu daty wdrożenia oraz statystyki nie mogą być traktowane jako sprostanie potrzebom informacyjnym Wykonawców w zakresie stabilności Systemu SZPROT. Przede wszystkim rozdział 5 ww. dokumentu, dotyczący awaryjności Systemu SZPROT, obejmuje dane wyłącznie za okres od 01.12.2022 r. do 16.10.2023 r. Zamieszczone tam statystyki zgłoszeń nie mówią zatem, co działo się z Systemem przez ostatnie 8 miesięcy przed ogłoszeniem zamówienia, czyli są po prostu stare. Dodatkowo nie wiadomo, jakiego zakresu Systemu te statystyki w rzeczywistości dotyczą, bowiem OPZ nie precyzuje, czy budowa Systemu SZPROT została ukończona,
‎i czy został on w całości oddany do eksploatacji.

Zamieszczona lakoniczna informacja o datach wdrożenia jest niewystarczająca w tym względzie (Załącznika nr 1 do OPZ – Opis Systemu, Roz.1, str.4):

„System posiada następujące moduły:

1Moduł e-Klient - został wdrożony 1 lutego 2021 r.

Moduł e-Decyzje - został wdrożony 30 listopada 2021 r.”

Podczas prowadzonych przez Zmawiającego wstępnych konsultacji rynkowych, poprzedzających przedmiotowe postępowanie, których jednym z uczestników
‎był Odwołujący, podnoszono podobne kwestie. Zamawiający wyjaśniał wówczas,
‎iż nie wszystkie procesy przewidziane zakresem zostały uruchomione w podanych datach,
‎a pracę nad budową i uruchomieniem pozostałych nadal są prowadzone przez obecnego Wykonawcę Systemu SZPROT. Wątpliwości te nie zostały jednoznacznie wyjaśnione
‎w SWZ. Niestety, Opis Systemu nie został uzupełniony w tym zakresie. Trzeba zaznaczyć,
‎iż informacje te, w kontekście przedstawionej w Opisie Systemu niskiej awaryjności, mają szczególne znaczenie dla przeprowadzenia prawidłowej interpretacji zamieszczonych danych o błędach. Można bowiem domniemywać, że informacja o niskiej awaryjności systemu ma związek z jego niekompletnym wdrożeniem produkcyjnym. Takie z pozoru niewinne niedopowiedzenie w OPZ może skutkować niedoszacowaniem pracochłonności Usługi Utrzymania przez Wykonawców innych niż ASSECO, przeświadczonych o dużo lepszej kondycji Systemu, niż ona ma miejsce w rzeczywistości. Przy obecnym stanie wiedzy wynikającym z OPZ łatwo o pominięcie w kalkulacji szeregu ryzyk, co nie miałoby miejsca, gdyby wiedza o stanie wdrożenia poszczególnych procesów Systemu SZPROT była pełna. Przykładowo moduły, które zostały zgodnie z pojęciami w SWZ „wdrożone” - mogą nie być jeszcze eksploatowane przez wszystkich użytkowników, co skutkuje niewielką lub wręcz zerową liczbą procesowanych w nich spraw. Tak eksploatowany system będzie,
‎co oczywiste, trapiony niewielką liczbą błędów, gdyż te ujawniają się najczęściej właśnie
‎w trakcie intensywnego korzystania przez użytkowników. Należy podkreślić, iż rzetelny
‎i zgodny z przepisami opis przedmiotu zamówienia winien szczegółowo i jednoznacznie określać wszystkie kluczowe aspekty przedmiotu zamówienia, w tym status eksploatacji poszczególnych elementów systemu.

Obecnie szczegółowe informacje o fazie eksploatacji Systemu SZPROT i jego awaryjności posiada jedynie Zamawiający oraz Wykonawca umowy na budowę Systemu SZPROT,
‎co skutkuje naruszeniem art. 16 PZP przez naruszenie zasady równego traktowania Wykonawców i uczciwej konkurencji.

Żądanie:

Odwołujący wniósł o nakazanie Zamawiającemu modyfikacji SWZ przez uzupełnienie
‎jej zapisów o:

datę zakończenia eksploatacji „starego” Systemu SZPROT;

datę uruchomienia produkcyjnego „nowego” Systemu SZPROT, w podziale
‎na moduły Systemu (e-Klient, e-Decyzje) i poszczególne procesy, jeśli przekazywanie ich
‎do eksploatacji następowało w różnych momentach czasowych, z uwzględnieniem dat przyszłych;

datę i warunki wygaśnięcia umowy aktualnego Wykonawcy Systemu SZPROT;

warunki przekazania Systemu SZPROT (tzw. Exit Planu), w tym warunki transferu wiedzy, które obowiązują aktualnego Wykonawcę Systemu SZPROT na mocy podpisanych
‎z Zamawiającym umów;

warunki świadczenia gwarancji przez Wykonawcę Systemu SZPROT;

statystyki występowania Błędów z ostatnich 24 miesięcy funkcjonowania systemu SZPROT obejmującej ich liczbę w układzie miesięcznym w podziale na kategorie Błędu, wraz ze wskazaniem modułu systemu SZPROT, w którym Błąd wystąpił.

Ad.2

Naruszenie art. 134 ust. 1 pkt. 4 PZP art. 99 ust. 1 PZP w zw. z art. art. 16 i 17 PZP i art. 353[1] kc. w zw. z art. 8 ust. 1 PZP – poprzez niejasny/nieprecyzyjny opis wymagań Rozwoju Zdefiniowanego uniemożliwiający rzetelne oszacowanie jego kosztów

Załącznik nr 2 do OPZ zawiera opis Zadań Rozwoju Zdefiniowanego do zrealizowania
‎w ramach Zamówienia Podstawowego w ściśle określonych terminach po zaoferowanym
‎w Formularzu Cenowym koszcie. Sposób zdefiniowania Zadań do realizacji w ramach Rozwoju Zdefiniowanego jest lakoniczny, dodatkowo dla części z Zadań Zamawiający przesunął moment doprecyzowania wymagań na etap analityczny, co w obliczu aktualnego sposobu rozliczania tych zadań należy uznać za niedopuszczalne.

Odwołujący podniósł, że aby możliwe było precyzyjne oszacowanie kosztu wykonania Zadań Rozwoju Zdefiniowanego Wykonawca musi zaplanować sposób ich realizacji jeszcze
‎na etapie ofertowania, Zamawiający nie może zatem odsuwać w czasie momentu doprecyzowania wymagań na etap realizacji umowy. Odwołujący pragnie przypomnieć,
‎że przedmiot zamówienia powinien być opisany w sposób jasny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń, uwzględniając wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty. Brak podania w OPZ szczegółowych informacji stanowi naruszenie art. 99 ust 1 PZP.

W przypadku Zadań, dla których Zamawiający nie jest w stanie precyzyjnie opisać wymagań, lub chciałby pozostawić sobie możliwość decydowania o wykonaniu bądź doprecyzowania sposobu realizacji danej funkcjonalności, Zamawiający powinien skorzystać z możliwości zlecenia realizacji takiego Zadania/funkcjonalności w ramach Rozwoju na Zgłoszenie
‎i przewidzianej tam puli roboczogodzin.

Żądanie

Odwołujący wniósł o nakazanie Zamawiającemu, aby dokonał modyfikacji SWZ przez doprecyzowanie już w OPZ opisu realizacji Zadań, wobec których planowano doprecyzowanie sposobu realizacji dopiero na etapie analizy, alternatywnie, jeśli nie jest to możliwe na obecnym etapie, Odwołujący wnosi o wykreślenie tych zadań z Rozwoju Zdefiniowanego i przesunięcie ich realizacji do Rozwoju na Zgłoszenie.

Ad.3

Naruszenie art. 134 ust. 1 pkt. 4 PZP, art. 99 ust. 1 oraz art. 353[1] kodeksu cywilnego w zw. z art. 8 ust 1 PZP oraz art. 16 i 17 PZP przez udostępnienie informacji
‎o systemie w sposób uniemożliwiający oszacowanie nakładów pracy na realizację zadań przewidzianych w ramach Rozwoju Zdefiniowanego

Zamawiający nie udostępnił w SWZ dokumentacji Systemu SZPROT, ani jego kodów źródłowych. Aby jednak oszacować nakład pracy konieczny do realizacji zadań Rozwoju Zdefiniowanego Wykonawcy muszą mieć dostęp do dokumentacji jeszcze na etapie ofertowania. Zamawiający co prawda zobowiązał się do ich udostępnienia w trakcie trwania postępowania przetargowego, ale w sposób naruszający dyspozycję art. 99 ust. 1 PZP i art. 16 i 17 PZP. Zgodnie z SWZ dokumentacja oraz kody źródłowe po złożeniu odpowiedniego wniosku zostaną udostępnione danemu Wykonawcy wyłącznie do wglądu w siedzibie Zamawiającego na czas 2 dni (łącznie 12h).

Zdaniem Odwołującego prowadzi to do niedopuszczalnego faworyzowania Wykonawcy, który zbudował System SZPROT. Tylko on, poza Zamawiającym oczywiście, posiada pełną wiedzę na temat tego, w jaki sposób system został zbudowany i z jakimi pracami wiąże się zaplanowana w ramach zamówienia podstawowego jego rozbudowa. Tylko dotychczasowy wykonawca posiada nieograniczoną czasowo możliwość dostępu do kodów źródłowych,
‎co w oczywisty sposób stawia go na uprzywilejowanej pozycji względem innych wykonawców. Należy podkreślić, że w celu przygotowania się do złożenia oferty
‎na utrzymanie i rozwój dużego systemu informatycznego nie wystarczy przez 12 godzin przeglądać udostępnione kody źródłowe. Do oszacowania potencjalnych ryzyk, czy też obszarów zwiększonej pracochłonności konieczna jest wnikliwa analiza, włącznie z próbami komplikacji kodów i ich weryfikacji z dokumentacją. Weryfikacji wymaga np. aktualność
‎i dostępność bibliotek, poprawność działania skryptów budujących, użyte wzorce kodowania, adekwatność dokumentacji do udostępnionego kodu. Takie czynności zajmują zwykle zdecydowanie dłużej niż 12 godzin, co więcej zazwyczaj nie są możliwe do przeprowadzenia w trybie „wizji lokalnej” a jedynie przez przygotowanie próbnego środowiska
‎z udostępnionych kodów, z zaangażowaniem na wiele godzin zespołu specjalistów.

Tymczasem oczekiwaniem Zamawiającego jest, by każdy inny Wykonawca niż autor Systemu SZPROT zaprojektował sposób realizacji wymaganych modyfikacji, a następnie dokonał oszacowania ponad 100 wymagań Rozwoju Zdefiniowanego bez znajomości Systemu, wyłącznie na podstawie wglądu do dokumentacji, trwającego do 12 godzin zegarowych.

Aby zrozumieć skalę absurdu zaistniałej sytuacji, warto zauważyć, iż wartość Rozwoju Zdefiniowanego Zamawiający oszacował na poziomie blisko 40.000.000,00 PLN brutto,
‎a oczekuje od Wykonawcy by przeanalizował dokumentację, zaprojektował sposób realizacji poszczególnych modyfikacji i dokonał oszacowania ich pracochłonności na postawie
‎2-dniowej wizji.

Jako alternatywny sposób udostępnienia dokumentacji i kodów Odwołujący chciałby przywołać przykład Agencji Rozwoju i Modernizacji Rolnictwa (ARiMR). Agencja od lat
‎na pisemny wniosek Wykonawcy, po podpisaniu stosownego „Oświadczenia o udzieleniu praw korzystania z utworów” udostępnia Wykonawcom za pośrednictwem platformy zakupowej (po uprzednim uwierzytelnieniu loginem i hasłem) uporządkowaną dokumentację oraz kody źródłowe do wszystkich komponentów/podsystemów Systemu będącego przedmiotem zamawianych w danym postępowaniu usług. Udzielenie praw korzystania
‎z utworów następuje wyłącznie na potrzeby postępowania – każde naruszenie postanowień podpisanego Oświadczenia skutkuje naliczeniem Wykonawcy kary wysokości 100 000,00 zł. Po zakończeniu postępowania Wykonawca zobowiązany jest do utylizacji pozyskanych materiałów i przekazania Zamawiającemu „Protokołu ze zniszczenia”. W ostatnim postępowaniu na „Utrzymanie i rozwój systemu informatycznego OFSA (DPiZP.2610.1.2022)” prowadzonym przez ARiMR zastosowano w tym zakresie następujące zapisy SWZ:

„I.1.1. Sposób udostępnienia przez Zamawiającego Dokumentacji tj. Dokumentacji Technicznej, Użytkownika, Analitycznej i Administratora, ujednoliconej ze stanem
‎na 1 kwartał 2023 roku i kodów źródłowych dla systemu OFSA związanych z opisem przedmiotu zamówienia, stanowiących części SWZ o poufnym charakterze.

1.Zamawiający, mając na uwadze art. 133 ust. 3 ustawy, informuje, że Dokumentacji
‎tj. Dokumentacji Technicznej, Użytkownika, Analitycznej i Administratora, ujednoliconej
‎ze stanem na 1 kwartał 2023 roku i kody źródłowe dla systemu OFSA zostaną przekazane na wniosek Wykonawcy złożony w postaci elektronicznej za pośrednictwem Platformy Zakupowej na adres: https://platformazakupowa.pl/pn/arimr. Warunkiem przekazania przez Zamawiającego Dokumentacji tj. Dokumentacji Technicznej, Użytkownika, Analitycznej
‎i Administratora, ujednoliconej ze stanem na 1 kwartał 2023 roku i kodów źródłowych
‎dla systemu OFSA jest podpisanie przez Wykonawcę kwalifikowanym podpisem elektronicznym przez osoby upoważnione do tych czynności „Oświadczenia ARiMR
‎o udzieleniu praw do korzystania z utworów”, sporządzonego zgodnie z Załącznikiem nr 7 do SWZ. Zamawiający przekaże każdemu Wykonawcy dokumentację w tożsamym brzmieniu.

2.Wniosek Wykonawcy o wydanie części SWZ, o której mowa w pkt 1 powinien zawierać niezbędne dane do przygotowania „Oświadczenia ARiMR o udzielenie prawa
‎do korzystania z utworów”, tj.: nazwę (firmę) Wykonawcy, adres siedziby, nr KRS
‎i oznaczenie Sądu Rejonowego prowadzącego rejestr przedsiębiorców lub dane z innego właściwego rejestru, nr REGON, NIP oraz wskazanie osoby upoważnionej do złożenia
‎w imieniu Wykonawcy oświadczenia o przyjęciu warunków wynikających z „Oświadczenia ARiMR o udzieleniu prawa do korzystania z utworów” i odbioru części SWZ, o której mowa
‎w pkt 1. Wniosek powinien także zawierać dane do kontaktu, w tym imię i nazwisko osoby upoważnionej oraz nr telefonu, lub adres poczty elektronicznej.

3.Zamawiający w ciągu 3 Dni Roboczych od złożenia przez Wykonawcę wniosku,
‎o którym mowa w pkt 1 przygotuje „Oświadczeniem ARiMR o udzielenie prawa
‎do korzystania z utworów” sporządzonym zgodnie z Załącznikiem nr 7 do SWZ które, przekaże Wykonawcy za pośrednictwem platformy zakupowej, na adres poczty elektronicznej wskazany przez Wykonawcę w złożonym wniosku.

4.Po otrzymaniu przez Zamawiającego „Oświadczenia ARiMR o udzielenie prawa
‎do korzystania z utworów” sporządzonym zgodnie z Załącznikiem nr 7 do SWZ” podpisanego kwalifikowanym podpisem elektronicznym przez reprezentujące Wykonawcę osoby upoważnione do tych czynności, Zamawiający w ciągu 2 Dni Roboczych od złożenia przez Wykonawcę „Oświadczenia ARiMR o udzielenie prawa do korzystania z utworów” przekaże część SWZ, o której mowa w pkt 1 za pośrednictwem platformy zakupowej
‎na adres poczty elektronicznej wskazany przez Wykonawcę w złożonym wniosku.

5.Termin złożenia przez Wykonawcę wniosku o część SWZ, o której mowa w pkt 1, pozostaje bez wpływu na termin składania ofert.

6.Część SWZ, o której mowa w pkt 1, zostanie udostępniona Wykonawcom wyłącznie na potrzeby zapoznania się z nią w celu przygotowania i złożenia oferty, w formie oraz
‎o kompletnej treści posiadanej przez Zamawiającego.

7.Część SWZ, o której mowa w pkt 1, stanowi utwory w rozumieniu ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (t.j.: Dz. U. z 2018 r. poz. 1191, z późn. zm.), zwane dalej „utworami”. Wykonawcy uprawnieni będą do nieodpłatnego korzystania w tym dokonywania zwielokrotniania utworów na czas przedmiotowego postępowania wyłącznie w celu przygotowania i złożenia oferty.

8.Wykonawca nie jest uprawniony w szczególności do odsprzedawania, wynajmowania, wydzierżawiania, użyczania lub rozpowszechniania utworów w jakikolwiek inny sposób, jak również do tłumaczenia i modyfikowania lub jakiegokolwiek innego ingerowania w utwory.

9.Po zakończeniu postępowania na „Zakup usługi Utrzymania i rozwoju systemu informatycznego OFSA” (nr referencyjny: DPiZP.2610.1.2022) Wykonawca zobowiązany jest do niezwłocznego przeprowadzenia utylizacji udostępnionej przez Zamawiającego części SWZ, o której mowa w pkt 1. „

Odwołujący podał, że skoro ARiMR, rozwijający równie duże i złożone systemy
‎co Zamawiający, jest w stanie zapewnić Wykonawcom równy i niedyskryminujący dostęp
‎do dokumentacji i kodów źródłowych na etapie postępowania przetargowego, to w ocenie Odwołującego nic nie stoi na przeszkodzie, by w analogiczny sposób Zamawiający udostępnił posiadaną dokumentację Systemu SZPROT ORAZ jego kody na potrzeby przedmiotowego postępowania.

Podał, że udostępnienie dokumentacji i kodów w taki właśnie sposób jest w ocenie Odwołującego jedynym rzetelnym sposobem przekazania wykonawcom wszystkich niezbędnych informacji w SWZ, koniecznych do opracowania i złożenia oferty. Zastosowana przez Zamawiającego wizja lokalna jest działaniem jedynie pozorującym. Podczas wizji lokalnej – ze względu na jej ograniczony czas i możliwości techniczne Wykonawców –
‎nie sposób uzyskać informacji niezbędnych do przygotowywania oferty i szacowania ceny.
‎W szczególności trudno sobie wyobrazić pracę nad przygotowywaniem koncepcji realizacji zaplanowanego zamówieniem podstawowym Rozwoju Zdefiniowanego, a następnie wyceny każdego z ponad 100 lakonicznie opisanych wymagań bez stałego dostępu do dokumentacji komponentów Systemu SZPROT, których dotyczy rozbudowa. Wizja lokalna mogłaby się sprawdzić przy planowaniu robót budowlanych, być może przy mniejszych systemach,
‎lub gdy potrzeba ocenić jedynie kompletność posiadanej przez Zamawiającego dokumentacji lub jej stan, np. przed planowanym audytem.

Odwołujący przywołał także treść rekomendacji nr. 6.1 dokumentu „POSTĘPOWANIE O UDZIELENIE ZAMÓWIENIA PUBLICZNEGO NA SYSTEM INFORMATYCZNY TOM II URZĄD ZAMÓWIEŃ PUBLICZNYCH GRUDZIEŃ 2021 R.”

(- INFORMATYCZNE.pdf#%5B%7B%22num%22%3A80%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C68%2C576%2C0%5D)

„Rekomendacja szczegółowa nr 6.1: zamawiający powinien dążyć do zlikwidowania asymetrii informacyjnej między wykonawcami (likwidacja naturalnej przewagi konkurencyjnej)

Jak już wskazano we wstępie do niniejszego Tomu II, zamówienia na systemy informatyczne coraz częściej dotyczą istniejących już rozwiązań IT - rozbudowy istniejącej infrastruktury IT zamawiającego, rozwoju czy też utrzymania już funkcjonującego u zamawiającego systemu. W każdym takim przypadku istnieje wykonawca posiadający unikalną wiedzę o danym systemie czy infrastrukturze IT, której nie posiadają inni wykonawcy na rynku – jest to wykonawca już świadczący dla zamawiającego usługi. Taką sytuację można określić jako naturalną przewagę konkurencyjną. Można jednak w prosty sposób zlikwidować negatywne skutki takiej przewagi – a to poprzez zawarcie w SWZ wszystkich informacji, które taki dotychczasowy wykonawca posiada, a które mają wpływ na sporządzenie oferty. W tym celu zamawiający powinien udostępnić jako element SWZ co najmniej:

1. możliwie najpełniejszy opis systemu,

2. pełną listę posiadanej infrastruktury IT,

3. wszystkie dane historyczne, które mogą mieć wpływ na świadczenie usług: liczba i rodzaj występujących błędów, incydentów.

Zamieszczenie w SWZ wszystkich informacji, które taki dotychczasowy wykonawca posiada, z jednej strony realizuje wymóg zamieszczenia wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty, a z drugiej strony zapewnia pełną konkurencyjność postępowania - zamawiający wprowadza równowagę informacyjną pomiędzy wykonawcami. Zastrzec należy, że w przypadku informacji, których ujawnienie zagrażałoby bezpieczeństwu systemu lub usług świadczonych z jego wykorzystaniem, zamawiający powinien rozważyć postawienie wymagań dotyczących zachowania poufnego charakteru informacji (art. 18 ust. 4 PZP).

Należy także nadmienić, że jednym ze sposobów zapewnienia równego dostępu do informacji niezbędnych w celu prawidłowego sformułowania oferty oraz wykonania zamówienia, jest przewidzenie wizji lokalnej lub sprawdzenia dokumentów niezbędnych do realizacji zamówienia w siedzibie zamawiającego (art. 131 ust. 2 PZP). Mechanizm ten (zwłaszcza w wariancie obligatoryjnym) powinien być jednak stosowany świadomie i nie może być nadużywany. W szczególności wizja lokalna powinna być raczej traktowana jako uzupełnienie dokumentów zamówienia, a nie może zastępować informacji, których powinien udzielić zamawiający w celu sporządzenia oferty i realizacji zamówienia. Możliwość lub obowiązek odbycia wizji lokalnej czy sprawdzenia dokumentów w lokalizacji zamawiającego nie zwalnia też zamawiającego z obowiązku udzielenia wyjaśnień treści SWZ.”

Przy dużych, złożonych Systemach jak SZPROT, w postępowaniu w którym przedmiotem jest jego rozbudowa rozliczana na podstawie zaoferowanej z góry ceny, udostępnienie dokumentacji jedynie do wglądu, na ograniczony czas, narusza zasadę konkurencyjności
‎i równego traktowania wykonawców. Oczywistym jest przecież, że aktualny Wykonawca Systemu SZPROT ma nieograniczony dostęp do niezbędnych materiałów. W zaistniałej sytuacji tylko dotychczasowy Wykonawca ma wiedzę, w jaki sposób należy oszacować pracochłonność modyfikacji, których wyceny żąda Zamawiający. Każdy inny Wykonawca wobec niedostatecznej znajomości systemu, ograniczonej narzuconymi ramami zapoznawania się z kodami i dokumentacją, musi z konieczności zakładać wysokie bufory
‎na ryzyko obniżając konkurencyjność swojej oferty. Prowadzi to do faktycznej ukrytej monopolizacji utrzymania i rozwoju dużych, krytycznych dla administracji systemów,
‎co w oczywisty sposób godzi w ideę konkurencyjności na rynku zamówień publicznych.

Żądanie

Odwołujący wniósł o nakazanie Zamawiającemu, aby zmodyfikował SWZ przez wprowadzenie postanowień zobowiązujących Zamawiającego do udostępnienia Wykonawcom na etapie postępowania przetargowego aktualnej i ujednoliconej Dokumentacji Systemu SZPROT, tj.: Dokumentacji Technicznej, Użytkownika, Analitycznej i Administratora oraz aktualnych kodów źródłowych Systemu SZPROT, w sposób umożliwiający swobodne

i nieograniczone czasowo korzystanie z nich na potrzeby przygotowania oferty
‎w przedmiotowym postępowaniu oraz zapewnienie wykonawcom odpowiedniej ilości czasu na zapoznanie się z dokumentacją systemu (nie mniej niż 40 dni od dnia jej udostępnienia).

Ad. 4

Naruszenie art. 134 ust. 1 pkt. 4 PZP, art. 99 ust. 1 oraz art. 353[1] kodeksu cywilnego w zw. z art. 8 ust 1 PZP oraz art. 16 i 17 PZP przez brak gwarantowanego czasu
‎na przygotowanie się do świadczenia usług

Zgodnie z istniejącymi na rynku IT praktykami Okres Przejściowy rozumiany jest jako gwarantowany okres pomiędzy dniem zawarcia umowy, a dniem rozpoczęcia świadczenia usług, w którym nowy Wykonawca ma możliwość rzeczywistego zapoznania się z systemem – przez realny dostęp do Systemu i jego dokumentacji, pozwalający m.in. na weryfikację infrastruktury, dokonanie weryfikacji i kompilacji kodu, pozyskanie informacji
‎od Zamawiającego niezbędnej do praktycznej realizacji usług, jest obecnie standardem
‎na rynku, również zamówień publicznych.

Zastosowanie takiego rozwiązania jest warunkiem sine qua non zapewnienia realnej konkurencyjności w postępowaniu o udzielenie zamówień na utrzymanie systemów, a jego istota sprowadza się do wyrównania szans wykonawców zainteresowanych złożeniem oferty w przetargu i przejęciem nowego dla nich systemu oraz obecnego Wykonawcy, który aktualnie świadczy usługi utrzymaniowo-rozwojowe, i/lub jak w przypadku przedmiotowego postępowania zbudował system, przez co już go zna, w szczególności jego budowę, dokumentację, wykorzystywaną infrastrukturę i kody źródłowe.

Odwołujący podał, że Zamawiający wydaje się podziela to stanowisko, bowiem przewidział na etapie wstępnym realizacji zamówienia „Okres przejściowy”, definiując go w OPZ jako:

„Okres od dnia zawarcia Umowy do Przejęcia Systemu. W okresie tym Wykonawca zapoznaje się z Systemem poprzez dostęp do Systemu i jego Dokumentacji, pozwalający m.in. na weryfikację infrastruktury, weryfikację i kompilację kodu, pozyskanie informacji od Zamawiającego niezbędnych do realizacji Usług Utrzymania Systemu. W okresie tym Wykonawca nie jest uprawniony do dokonywania jakichkolwiek zmian w Systemie oraz nie przysługuje mu wynagrodzenie z tytułu świadczenia Usług Utrzymania Systemu.”

Odwołujący podał, że niestety sposób, w jaki Zamawiający definiuje „Przejęcie Systemu”,
‎to jest:

„Dzień, w którym Wykonawca rozpoczyna świadczenie Usługi Utrzymania Systemu,
‎po zakończeniu Okresu przejściowego, nie wcześniej niż od dnia 1 lutego 2025 r., (…).”

sprawia, iż Wykonawca nie ma w rzeczywistości zagwarantowanego określonego czasu
‎na realne wykonanie czynności przewidzianych Okresem przejściowym. W przypadku, gdy
‎w wyniku przedłużającego się postępowania przetargowego dzień zawarcia Umowy przekroczyłby datę „Przejęcia Systemu”, Okres przejściowy nie miałby podstaw zaistnieć,
‎a jeśli już - to nie wiadomo byłoby, ile miałby trwać.

Samo zagwarantowanie udostępnienia niezbędnej do świadczenia usług dokumentacji, wersji instalacyjnych systemu, bibliotek programistycznych oraz kodów źródłowych
‎w terminie 5 dni roboczych od dnia zawarcia Umowy jest niewystarczające (OPZ, pkt.3.1.4.). Zobowiązanie to nic nie mówi bowiem o przewidzianym, gwarantowanym czasie
‎dla Wykonawcy na zapoznanie się z Systemem, udostępnionym materiałem oraz wytworzeniem w rezultacie wymaganego OPZ własnego środowiska developerskiego (OPZ, pkt. 3.4.1) i testowego (OPZ, pkt. 3.1.5).

Brak zagwarantowania określonego czasu trwania Okresu przejściowego prowadzi
‎do wypaczenia również innych zobowiązań Zamawiającego mających na celu właściwe przygotowanie Wykonawcy do świadczenia usług, w szczególności:

transfer wiedzy, w ramach którego przewidziano raz w tygodniu 2-godzinne spotkania on-line z Zamawiającym:

„3.2.2. W Okresie przejściowym Zamawiający przewiduje spotkania robocze z Zespołem Wykonawcy realizowane on-line, za pośrednictwem aplikacji np. Teams, mające na celu transfer wiedzy. Terminy spotkań będą na roboczo uzgadniane pomiędzy Stronami, przy czym Zamawiający przewiduje 1 spotkanie w tygodniu, trwające nie dłużej niż 2 godziny.”

Ilość takich spotkań uzależniona jest bezpośrednio od długości trwania Okresu przejściowego - im krótszy okres przejściowy tym mniej zagwarantowanych godzin transferu wiedzy, tymczasem złożoność Systemu i potrzeba pozyskania wiedzy przez nowego Wykonawcę pozostaje ta sama.

dostęp do środowisk Systemu SZPROT na okoliczność zapoznania się z Systemem:

„3.3.1. W terminie do 20 Dni roboczych od dnia zawarcia Umowy, Zamawiający zapewni zdalny dostęp do środowisk Systemu SZPROT, tj. środowisk testowych i produkcyjnego, bez możliwości wprowadzania zmian w Systemie.”

gdzie w szczególnym przypadku, przy przedłużającym się postępowaniu przetargowym, konieczność Przejęcia Systemu, a co za tym idzie rozpoczęcie świadczenia Usługi Utrzymania, nastąpiłoby wcześniej - zanim Wykonawca zdążyłby się de facto zapoznać
‎z Systemem i przygotować do świadczenia usług.

Abstrahując od powyższego zauważa Odwołujący, że Zamawiający przewidział Okres przejściowy wyłącznie przed rozpoczęciem Usługi Utrzymania, zupełnie pomijając fakt,
‎że rozpoczęcie świadczenia usługi Rozwoju Zdefiniowanego oraz Rozwoju na Zgłoszenie również wymaga wiedzy o Systemie, zapoznania się z dokumentacją i kodami, oraz
‎co istotne przygotowania środowiska developerskiego i testowego, wymaganych zapisami OPZ.

Przy tak określonych warunkach świadczenia usług, w przypadku niekorzystnego (późnego) podpisania umowy, tylko obecny Wykonawca Systemu SZPROT może być w stanie podjąć się realizacji zobowiązań wynikających z umowy z pominięciem okresu przejściowego (poprzez kontynuację dotychczasowych świadczeń). Każdy inny Wykonawca będzie zmuszony w takiej sytuacji rozważać, czy w ogóle podpisać umowę tracąc wadium, czy podjąć się realizacji umowy bez przygotowania i ryzykować naliczenie kar oraz odstąpienie lub wypowiedzenie umowy przez Zamawiającego. W konsekwencji - brak zapewnienia gwarantowanego czasu na zapoznanie się z Systemem w połączeniu udostępnieniem lakonicznych informacji o Systemie prowadzi do preferowania aktualnego Wykonawcy Systemu SZPROT, co narusza wprost art. 99 ust. 4 PZP (jak i art. 16 PZP).

Odwołujący podał, że oceniając w sposób racjonalny i zgodny z doświadczeniem życiowym fakt, iż w niniejszym postępowaniu Zamawiający nie przewidział okresu przejściowego oraz że oczekuje on, iż nowy Wykonawca z dniem zawarcia umowy rozpocznie świadczenie usług Systemu, z którego dokumentacją i kodami nie miał szansy się zapoznać – stwierdzić należy, że oczekiwanie takie jest po prostu nierealne. Co prawda to Wykonawca przedstawia Zamawiającemu Harmonogram realizacji Projektu i teoretycznie mógłby wprowadzić czas
‎na potrzebną mu fazę rozruchową, ale przy sztywno określonych datach realizacji poszczególnych zadań i ewentualnej późnej dacie podpisania umowy, może on zostać postawiany w bardzo niekorzystnej dla siebie sytuacji, w której fazy tej faktycznie nie będzie - tylko z tego powodu, że Zamawiający nie przewidział gwarantowanego czasu trwania Okresu Przejściowego.

Odwołujący podał, że kkierując się własnym doświadczeniem oraz treścią SWZ w innych postępowaniach, a także biorąc pod uwagę złożoność Systemu Odwołujący stoi
‎na stanowisku, że niezbędne jest określenie co najmniej 3-miesięcznego Okresu przejściowego. Odwołujący wskazał i powołał wyrok Krajowej Izby Odwoławczej sygn. KIO 1544/21 – w którym Izba uwzględniając zarzut odwołania dotyczący braku okresu przejściowego nakazała zamawiającemu „wprowadzenie okresu przejściowego na poziomie minimum 3 miesięcy”.

Żądanie

Odwołujący wniósł o nakazanie Zamawiającemu, aby zmodyfikował SWZ przez wprowadzenie terminów rozpoczęcia świadczenia usług w postaci dat względnych, gwarantujących co najmniej 3 miesięczny okres pomiędzy dniem podpisania umowy
‎a dniem rozpoczęcia świadczenia usług (z uwzględnieniem Usługi Rozwoju Zdefiniowanego oraz Usługi Rozwoju na Zgłoszenie), z możliwością skrócenia tego czasu za porozumieniem stron.

Ad. 5.

Naruszenie art. 353[1] kodeksu cywilnego oraz art. 387 § 1 kodeksu cywilnego
‎w zw. z art. 8 ust. 1 PZP przez ustanowienie terminów dostarczenia poszczególnych zadań Rozwoju Zdefiniowanego w datach sztywnych (określonych kalendarzowo), których dotrzymanie przez Wykonawcę jest w praktyce niemożliwe lub mało prawdopodobne

Zamawiający określił dla każdego zadania Rozwoju Zdefiniowanego datę dostarczenia zadania przez daty sztywne (kalendarzowe) w zakresie od 02.01.2025 do 02.01.2027, gdzie data 02.01.2025 r. budzi szczególne wątpliwości co do realności jej dochowania.

Odwołujący zauważył, że na możliwość realizacji zadania w danym terminie wpływa wiele czynników, m.in.: czas trwania Okresu Przejściowego, kondycja przejmowanego Systemu, kompletność przekazanej Dokumentacji Systemu, jakość kodu źródłowego, dostępność zespołu projektowego po stronie Zamawiającego, ewentualne ograniczenia architektoniczne, oraz inne, których na obecnym etapie nie da się przewidzieć.

Odwołujący podał, że mając na uwadze również sam termin ogłoszenia przedmiotowego postępowania oraz duże dotychczasowe zainteresowanie rynku świadczeniem usług utrzymania i rozwoju Systemu SZPROT (o udział we Wstępnych Konsultacjach Rynkowych ubiegało się aż 11 Wykonawców) istnieje duże prawdopodobieństwo wystąpienia opóźnień związanych z rozstrzygnięciem postępowania, co w konsekwencji może doprowadzić
‎do sytuacji w której termin podpisania umowy wykroczy poza datę 02.01.2025r., lub nastąpi w jej pobliżu przez co uniemożliwi terminową realizację Zadań z najwcześniejszymi datami dostarczenia.

Przykładowo podał Odwołujący, jeżeli uznać konieczność zagwarantowania Okresu przejściowego na prace przygotowawcze Wykonawcy do świadczenia wszystkich usług,
‎w tym Usługi Rozwoju Zdefiniowanego (o co Odwołujący wnioskuje w argumentacji do Zarzutu 4) w minimalnym wymiarze 3 miesięcy, okazałoby się, że realizacja Zadania nr 9 musiałaby rozpocząć się w zasadzie już teraz, aby w ogóle możliwe było dochowanie wyznaczonego terminu na dzień 02.01.2025r., co z przyczyn oczywistych nie jest możliwe. Taki stan rzeczy ponownie stawia autora Systemu w SZPROT w uprzywilejowanej pozycji, bowiem tylko on mógłby podjąć się świadczenia usług z pominięciem Okresu przejściowego, w szczególności przystąpić do wcześniejszej realizacji prac w ramach Zadania nr 9.

Odwołujący podał, że Zamawiający przewidział możliwość zmiany Harmonogramu Realizacji Zadań Rozwoju Zdefiniowanego jedynie w zakresie terminów pośrednich. Daty dostarczenia poszczególnych zadań nie mogą wykraczać poza wskazane w Załączniku
‎nr 2 do OPZ/Formularzu Cenowym, które należy traktować jako graniczne, przez co nie ma możliwości ich zmiany w trakcie realizacji zamówienia, a przekroczenie ich wiąże się
‎z naliczaniem Wykonawcy kar umownych. Takie ukształtowanie postanowień stosunku prawnego narusza dyspozycję art. 353[1] k.c. w zw. z art. 387 § 1 k.c., zmusza bowiem wykonawcę do ubiegania się o zamówienie w sytuacji, w której wie, że na dochowanie terminów realizacji umowy szansa jest albo niewielka, albo nie ma jej wcale – a alternatywą jest po prostu rezygnacja ze złożenia oferty. Ponownie, tego rodzaju działanie narusza również dyspozycję przepisów art. 16 i 17 PZP, prowadząc do preferowania wykonawcy obecnie utrzymującego System SZPROT.

Żądanie

Odwołujący wniósł o nakazanie Zamawiającemu, aby dokonał modyfikacji SWZ przez zastąpienie, w Załączniku nr 2 do OPZ, oraz Formularzu cenowym, dat dostarczenia poszczególnych Zadań - terminami zależnymi od dnia zakończenia Okresu przejściowego/podpisania Umowy (w zależności od sposobu rozstrzygnięcia przez Izbę Zarzutu 4), ewentualnie od terminu zakończenia innego zadania, jeśli istnieje pomiędzy nimi powiązanie.

Ad.6

Naruszenie art. 134 ust. 1 pkt. 4 PZP, art. 99 ust. 1 oraz art. 353[1] kodeksu cywilnego w zw. z art. 8 ust 1 PZP oraz art. 16 i 17 PZP – niejasny/nieprecyzyjny opis Zadania nr 9 Rozwoju Zdefiniowanego uniemożliwiający rzetelne oszacowanie kosztów jego realizacji oraz konieczności zapewnienia parametrów wydajnościowych o nieznanej wysokości

Zamawiający w SWZ wskazał parametry wydajnościowe, w oparciu o które zbudowano System SZPROT (Załącznik nr 2 do OPZ, rozdział 109. SZPROT_WFOG_35):

System SZPROT musi obsługiwać 16000 Użytkowników wewnętrznych.

System SZPROT musi zapewnić co najmniej 2000 aktywnych, jednoczesnych sesji Użytkownika wewnętrznego w systemie.

Czas odpowiedzi na proste funkcjonalności, związane z wprowadzaniem, edycją i aktualizacją danych do 2 sekund.

Czas ładowania pliku o wielkości 500kB do kontrolek formularza nie może być większy niż 2 sekundy.

Czas walidacji 20 pól każdego formularza z wykorzystaniem mechanizmów wewnętrznych systemu nie może być większy niż 500 ms.

Maksymalny czas logowania Użytkownika wewnętrznego w systemie nie może być większy niż 5 sekund.

Przelicznik wydajnościowy środowiska testowego do środowiska produkcyjnego wynosi 1 do 4.

Odwołujący podał, że jednoczenie w ramach Zadania 109 Rozwoju Zdefiniowanego zobowiązał Wykonawcę do wykonania automatycznych testów wydajnościowych celem sprawdzenia i utrzymania wydajności Systemu w kolejnych wersjach Systemu oraz w okresie jego utrzymania. Zamawiający określa następnie, że: „Gdyby środowisko produkcyjne
‎nie spełniało wskazanych parametrów, Wykonawca zobowiązany jest do utrzymania takich samych lub wyższych parametrów wydajnościowych uzyskanych w wyniku przeprowadzenia testów w każdej następnej wersji Systemu SZPROT.”

Odwołujący podał, że powyższe nie pozwala jednoznacznie stwierdzić, jakie parametry wydajnościowe ma w rzeczywistości spełniać System, i do utrzymania których to parametrów jest zobowiązany Wykonawca. Czy wystarczy, gdy System będzie spełniał parametry wydajnościowe osiągnięte w wyniku przeprowadzenia testów, czy jednak wyższych, a jeśli tak to jakie? Czy chodzi o parametry, w oparciu o które budowano System SZPROT (choć tak naprawdę nie ma pewności czy System kiedykolwiek je spełnił/spełniał)?

Zamawiający nie ma wiedzy, jakie parametry wydajnościowe aktualnie spełnia System SZPROT (na co wskazuje cel realizacji Zadania – testy), tym samym Zamawiający nie może mieć również pewności, czy parametry wydajnościowe, w oparciu o które miał być zbudowany System, w ogóle są możliwe do osiągnięcia. Zamawiający wymaga zatem, aby wykonawca na etapie ofertowania określenia określił koszty zapewnienia parametrów wydajnościowych bez możliwości uprzedniego przeprowadzenia testów i sprawdzenia, czy założone parametry w ogóle są możliwe do osiągnięcia – co jest zadaniem oczywiście nierealnym.

Żądanie

Odwołujący wniósł o nakazanie Zamawiającemu modyfikacji SWZ poprzez doprecyzowanie:

- wymaganych minimalnych parametrów wydajnościowych, które musi spełniać System;

- przeniesienie zobowiązania Wykonawcy do dostosowania Systemu celem osiągniecia wymaganych parametrów wydajnościowych jako zobowiązania do realizacji w ramach Rozwoju na Zgłoszenie.

Po przeprowadzeniu rozprawy z udziałem Stron oraz uczestników postępowania odwoławczego na podstawie zebranego materiału w sprawie oraz oświadczeń i stanowisk Stron Krajowa Izba Odwoławcza ustaliła i zważyła,
‎co następuje:

W odniesieniu do obu spraw odwoławczych:

Izba ustaliła, że nie została wypełniona żadna z przesłanek, o których stanowi
‎art. 528 nowej ustawy skutkujących odrzuceniem każdego z odwołań. Odwołania zostały złożone do Prezesa Krajowej Izby Odwoławczej 17 czerwca 2024 roku, od czynności publikacji ogłoszenia o zamówienie oraz dokumentów zamówienia z dnia 7 czerwca 2024 roku. Kopie odwołań zostały przekazane co wynika z akt sprawy odwoławczej.

Skład orzekający Izby rozpoznając sprawę uwzględnił akta sprawy odwoławczej,
‎które zgodnie z par. 8 rozporządzenia Prezesa Rady Ministrów z dnia 30 grudnia 2020 roku w sprawie postępowania przy rozpoznawaniu odwołań przez Krajową Izbę Odwoławczą (Dz. U. z 2020 r. poz. 2453) stanowią odwołanie wraz z załącznikami oraz dokumentacja postępowania o udzielenie zamówienia w postaci elektronicznej lub kopia dokumentacji,
‎o której mowa w § 7 ust. 2, a także inne pisma składane w sprawie oraz pisma kierowane przez Izbę lub Prezesa Izby w związku z wniesionym odwołaniem.

II.

Sygn. akt KIO 2105/24

Izba uwzględniła stanowisko Odwołujacego wyrażone w piśmie z dnia 1 lipca 2024 roku „Pismo procesowe Odwołujacego”, w którym wykonawca Odwołujący podał:

W ZAKRESIE ZARZUTU 1

(…) – w związku ze zmianą otoczenia prawnego, w wyniku wydania w dniu 25 czerwca 2024 roku przez Sąd Okręgowy w Warszawie – Sąd Zamówień publicznych wyroku w sprawie
‎o sygnaturze XXIII Zs 59/24 – wskazuje, co następuje:

Kwestia objęta zarzutem 1 odwołania jest zdaniem Odwołującego problemem systemowym, który powinien zostać uregulowany w dokumentacji postępowania przez zamawiających, zaś prawidłowość czynności zamawiających powinna podlegać ewentualnej kontroli Krajowej Izby Odwoławczej i Sądu Zamówień Publicznych.

Jak wskazano w odwołaniu – ostatnio coraz częstsza jest praktyka, w ramach której wykonawcy w wykazach usług/dostaw 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 wykonania referencyjnego projektu ani też jego rzeczywistych cech architektonicznych (wykorzystywanych technologii) czy parametrów eksploatacyjnych (np. liczby użytkowników). Ponadto w ramach w/w praktyki wskazywane usługi referencyjne są realizowane przez spółki z grupy kapitałowej danego wykonawcy – co dodatkowo utrudnia weryfikację danych podawanych w wykazach. W konsekwencji fikcją staje się możliwość sprawdzenia, czy dany wykonawca rzeczywiście spełnia warunki udziału w postępowaniu.

Wobec powyższego Odwołujący konsekwentnie wnosi odwołania (we wszystkich tzw. dużych postępowaniach), w których domaga się, aby zamawiający już w składanym wykazie usług/dostaw wymagał podania danych użytkownika rzeczywistego danego systemu informatycznego.

W dniu 25 czerwca 2024 roku Sąd Okręgowy w Warszawie – Sąd Zamówień publicznych
‎w wyroku w sprawie o sygnaturze XXIII Zs 59/24 potwierdził zasadność i prawidłowość takiej zmiany SWZ.

Otóż w postępowaniu prowadzonym przez Zakład Ubezpieczeń Społecznych
‎na Świadczenie usług wsparcia eksploatacji i utrzymania Kompleksowego Systemu Informatycznego Zakładu Ubezpieczeń Społecznych Odwołujący wniósł odwołanie
‎z żądaniem analogicznym, jak w niniejszym postępowaniu.

Zakład Ubezpieczeń Społecznych uwzględnił zarzut i jednocześnie dokonał zmian SWZ. W odpowiedzi konsorcjum Comarch Polska S.A. i Comarch S.A. wniosło sprzeciw wobec uwzględnienia odwołania. Krajowa Izba Odwoławcza umorzyła jednak postępowanie odwoławcze – na podstawie art. 568 pkt 2 PZP. Następnie konsorcjum Comarch Polska S.A. i Comarch S.A. wniosło odwołanie na zmianę SWZ. Odwołanie to zostało oddalone wyrokiem KIO 442/24 z dnia 29 lutego 2024 roku.

Na w/w wyrok KIO 442/24 konsorcjum Comarch Polska S.A. i Comarch S.A. wniosło skargę – i właśnie ta skarga została oddalona wyrokiem w/w XXIII Zs 59/24. Uzasadnienie wyroku Sądu Zamówień Publicznych nie zostało jeszcze sporządzone, jednakże w ustnych motywach rozstrzygnięcia Sąd Okręgowy wskazał, że domaganie się przez zamawiającego podania w wykazie usług faktycznych danych o podmiocie użytkującym system jest zarówno dozwolone jak i zasadne. Z jednej strony mieści się bowiem w zakresie danych wskazanych w Rozporządzeniu Ministra Rozwoju, Pracy i Technologii z dnia 23 grudnia 2020 r. w sprawie podmiotowych środków dowodowych oraz innych dokumentów lub oświadczeń, jakich może żądać zamawiający od wykonawcy, z drugiej zaś strony – tylko takie pełne i rzeczywiste dane pozwolą na wykazanie spełniania warunków udziału – Sąd Okręgowy uznał, że brak takich danych powoduje wręcz brak wykazania spełnienia warunku udziału w postępowaniu.

Wobec powyższego Odwołujący – jako rozszerzenie argumentacji odwołania – załącza wyrok KIO 442/24, wskazując na jego uzasadnienie, jako dodatkową argumentację
‎dla zarzutu 1.

Wobec faktu, że na dzień wnoszenia odwołania wyrok KIO 442/24 był zaskarżony – Odwołujący nie chciał wskazywać na poglądy Izby w tym zakresie, nie wiedząc, czy zyskają one aprobatę Sądu Zamówień Publicznych.

Izba uwzględniła stanowisko Zamawiającego wyrażone w piśmie z dnia 4 lipca 2024 roku do sprawy sygn. akt KIO 2105/24 „Odpowiedź na odwołanie”– Zamawiający wniósł o oddalenie Odwołania w zakresie Zarzutu nr 1, 2, 3, 4 - IVA, 6, 7, 8, 10, 11, 13, 15, 16, 17,18, 19, 20, 21, 23.

Zamawiający uwzględniła odwołanie w zakresie Zrzutu 4 – IVB i IVC, 5, 9, 12, 14, 22, 24, 25, 26.

Izba uwzględniała stanowisko Zamawiającego przesłane za pismem z dnia 10 lipca 2024 roku wraz z załącznikami – stanowisko to przedstawia zmiany wprowadzone
‎do dokumentów zamówienia.

Izba uwzględniała stanowisko Odwołujacego, co do zakresu formalnego oraz merytorycznego, wyrażone w piśmie „Pismo procesowe Odwołujacego” z dnia 15 lipca 2024 roku.

Odwołujący w zakresie formalnym podał:

Wniosek o umorzenie postępowania odwoławczego na podstawie art. 568 pkt 3 PZP
‎w związku z uwzględnieniem części zarzutów – w zakresie zarzutów IVB, IVC, V, IX, XII, XIV, XXII, XXIV, XXV i XXV.

Zamawiający w piśmie „Odpowiedź na odwołanie” z 4 lipca 2024 roku uwzględnił odwołanie w zakresie następujących zarzutów” IVB, IVC, V, IX, XII, XIV, XXII, XXIV, XXV i XXVI.

Przystępujący do postępowania odwoławczego po stronie Zamawiającego wykonawca GIS Parter nie zgłosił sprzeciwu wobec uwzględnienia.

Wobec powyższego wniosek o umorzenie postępowania jest zasadny.

Jedynie dodatkowo Odwołujący wskazuje, że pomimo uwzględnienia niektórych zarzutów – Zamawiający dokonał zmian niezgodnych z żądaniem i postanowienia SWZ nadal naruszają przepisy PZP. W związku z czym Odwołujący zmuszony jest wnieść kolejne odwołanie, na nową treść SWZ – nie jest bowiem możliwe rozpoznawanie zarzutu po jego uwzględnieniu przez Zamawiającego. Przykładowo dotyczy to zarzutu IVC, XIV, XXII i XXIV.

Wniosek o umorzenie postępowania odwoławczego na podstawie art. 568 pkt 2 PZP w związku ze zmianą brzmienia postanowień SWZ objętych odwołaniem – w zakresie zarzutów X i XVI.

Zamawiający w piśmie „Odpowiedź na odwołanie” z 4 lipca 2024 roku zapowiedział, iż dokona zmian SWZ objętych zarzutami II, IVA, VIA, VIB, X, XI, XVI, XX.

W dniu 10 lipca 2024 roku Zamawiający dokonał zmian SWZ.

Zmiana SWZ nie pokrywa się jednak z zapowiedzią zmiany z Odpowiedzi na odwołanie – nie dokonano zapowiedzianych zmian lub też dokonano zmian zupełnie nieistotnych w zakresie następujących zarzutów:

Zarzut II – dla §7 ust. 13, 14, 15, 16, 17, 18, 20, 23, 25, 29, 30 – nie dokonano w ogóle żadnych zmian;

Zarzut IVA, VIA, VIB, XI i XX – dokonano zmian nieistotnych.

A zatem dla powyższych zarzutów konieczne jest rozpoznanie odwołania.

Natomiast w zakresie zarzutów X i XVI wniosek o umorzenie postępowania jest zasadny, gdyż pojawiła się nowa treść SWZ. Odwołujący zanalizuje nowe postanowienia SWZ i w przypadku, gdy uzna, że nadal naruszają one przepisy Prawa zamówień publicznych – skorzysta z prawa do wniesienia odwołania na nową treść SWZ.

Cofnięcie odwołania w części – w zakresie zarzutów III, VII, XVIII, XXI, XXIII.

Odwołujący – po zapoznaniu się z „Odpowiedzią na odwołanie” i zawartą w niej argumentacją Zamawiającego oraz w związku z innymi zmianami SWZ – cofa następujące zarzuty: III, VII, XVIII, XXI, XXIII.

Zakres odwołania pozostały do rozpoznania – zarzuty: I, II (w części) , IVA, VIA, VIB , VIII, XI, XIII, XV, XVII, XIX, XX.

Wobec powyższego obecnie do rozpoznania pozostały zarzuty jak poniżej: I, II (w części), IVA, VIA, VIB, VIII, XI, XIII, XV, XVII, XIX, XX.

Izba uwzględniała stanowisko Zamawiającego przesłane za pismem z dnia 18 lipca 2024 roku wraz z załącznikami – stanowisko to przedstawia zmiany wprowadzone
‎do dokumentów zamówienia.

III.

Sygn. akt KIO 2125/24

Izba uwzględniła stanowisko uczestnika postępowania odwoławczego – Asseco Poland spółka akcyjna z siedzibą w Warszawie wyrażone w piśmie z dnia 1 lipca 2024 roku, w którym wniósł wskazał, że:

przystąpił do odwołania KIO 2105/24 wniesionego przez Comarch Polska S.A wyłącznie w zakresie zarzutu 2 i 5. Zakres przystąpienia wynika z faktu, że Asseco Poland S.A. wniosło własne odwołanie o sygnaturze KIO 2105/24 na czynność sporządzenia przez Zamawiającego dokumentacji postępowania, w którym to odwołaniu podniosło zarzuty analogiczne do zarzutu 2 i 5 w przedmiotowym odwołaniu.

W pozostałym zakresie Asseco Poland S.A. nie przystąpił do odwołania i w związku z tym nie będzie zajmować stanowiska procesowego.

Izba uwzględniła stanowisko Zamawiającego wyrażone w piśmie z dnia 4 lipca 2024 roku do sprawy sygn. akt KIO 2125/24 „Odpowiedź na odwołanie”– Zamawiający wniósł o oddalenie Odwołania w zakresie Zarzutu nr 2, 3, 4, 5,

Zamawiający uwzględniła odwołanie zakresie Zrzutu nr 1 i 6.

Izba uwzględniała stanowisko Zamawiającego przesłane za pismem z dnia 10 lipca 2024 roku wraz z załącznikami – stanowisko to przedstawia zmiany wprowadzone
‎do dokumentów zamówienia.

Izba uwzględniała stanowisko Odwołujacego, co do zakresu formalnego oraz merytorycznego, wyrażone w piśmie „Pismo procesowe Odwołujacego Comarch S.A.”
‎ z dnia 15 lipca 2024 roku.

Odwołujący w zakresie formalnym podał:

Działając w imieniu Odwołującego Comarch Polska S.A. - wywiązując się z zobowiązania Izby do przedłożenia do dnia 15 lipca br. do godz. 15.00 stanowiska procesowego Odwołującego – mając na uwadze złożoną przez Zamawiającego odpowiedź na odwołanie (pismo z dnia 4 lipca 2024 r. oraz pismo z dnia 10 lipca 2024 r.) oraz mając na uwadze dokonane w dniu 3 lipca 2024 r. oraz w dniu 10 lipca 2024 r. zmiany 2 | S t r o n a

Specyfikacji Warunków Zamówienia (dalej: „SWZ”) – wskazuję co następuje w odniesieniu do poszczególnych zarzutów odwołania:

1) w zakresie zarzutu nr 1:

a. podtrzymuję zarzut w części, w której – pomimo formalnego uwzględnienia przez Zamawiającego zarzutu nr 1 odwołania, w ślad za czym dokonał on czynności modyfikacji SWZ – w dalszym ciągu istnieje substrat zaskarżenia, tj. w zakresie podstawy faktycznej zarzutu 1 dotyczącej:

i. statystyk występowania błędów w podziale na moduły systemu SZPROT (Moduł e-Decyzje i Moduł e-Klient) – bowiem Specyfikacja nadal, po uwzględnieniu zarzutu i po modyfikacji nie zawiera żądanych informacji na ten temat (podano te statystyki, lecz nie wiadomo w dalszym ciągu czy i w jakim zakresie dotyczą one Modułu e-Decyzje, a w jakim Modułu e-Klient) oraz

ii. braku podania informacji nt. daty uruchomienia produkcyjnego modułu e-Klient oraz poszczególnych procesów tego modułu (w dalszym ciągu Specyfikacja jest brakowa pod tym względem i żądne informacje nie zostały ujawnione, ponadto je natomiast wyczerpująco dla Modułu e-Decyzje)

b. w pozostałej części zarzutu nr 1 odwołania, w której w wyniku modyfikacji SWZ nie istnieje substrat zaskarżenia, tj. w zakresie podstawy faktycznej zarzutu 1 dotyczącej:

i. Braku statystyk występowania błędów jako takich (podania podano te statystyki)

ii. podania informacji nt. daty uruchomienia produkcyjnego modułu e-Decyzje oraz poszczególnych procesów tego modułu (podano te informacje)

– wnoszę o umorzenie postępowania na podstawie art. 568 pkt 2 Pzp.

2) podtrzymuję zarzut nr 2 odwołania,

3) podtrzymuję zarzut nr 3 odwołania,

4) podtrzymuję zarzut nr 4 odwołania,

5) podtrzymuję zarzut nr 5 odwołania,

6) wnoszę o umorzenie postępowania w zakresie zarzutu nr 6 odwołania z uwagi na uwzględnienie zarzutu w całości przez Zamawiającego - na postawie art. 568 pkt 3 Pzp. w zw. z art. 522 ust. 4 Pzp.

Izba uwzględniała stanowisko Zamawiającego przesłane za pismem z dnia 18 lipca 2024 roku wraz z załącznikami – stanowisko to przedstawia zmiany wprowadzone
‎do dokumentów1) zamówienia.

IV.

W zakresie postanowień wydanych w sprawie o sygn. akt KIO 2105/24

Izba umorzyła postępowanie odwoławcze w zakresie zarzutów IVB, IVC, V, IX, XII, XIV, XXII, XXIV, XXV i XXVI z uwagi na uwzględnienia zarzutów odwołania przez Zamawiającego – w związku z uwzględnieniem zarzutów przez Zamawiającego, oraz oświadczeniem uczestnika postępowania odwoławczego o niewnoszeniu sprzeciwu
‎co do uwzględnionych zarzutów odwołania.

Izba podkreśla w tym miejscu, że zaszły przesłanki do umorzenia postępowania odwoławczego w zakresie ww. zarzutów odwołania zgodnie z art. 522 ust. 1 ustawy z dnia 11 września 2019 roku Prawo zamówień publicznych oraz wydania postanowienia zgodnie
‎z art. 568 pkt 3 ustawy. Izba podkreśla, że na podstawie art. 522 ust. 1 ustawy Zamawiający wykonuje, powtarza lub unieważnia czynności w postępowaniu o udzielnie zamówienia, zgodnie z żądaniem zawartym w odwołaniu.

Izba umorzyła postępowanie odwoławcze w zakresie zarzutów III, VII, XVIII, XXI, XXIII z uwagi na ich wycofanie przez Odwołujacego.

Oświadczenie o wycofaniu ww. zarzutów zostało skutecznie złożone przez Odwołujacego. Odwołanie, a tym samym poszczególne jego zarzuty, można cofnąć w każdym czasie
‎do zamknięcia rozprawy. Cofnięcie zarzutów odwołania przez Odwołującego, zgodnie art. 568 pkt 1 ustawy oznacza, że postępowanie odwoławcze w zakresie tych zarzutów podlega umorzeniu.

Izba umorzyła postępowanie odwoławcze w zakresie zarzutów X i XVI, zarzutu II
‎w odniesieniu do §7 ust. 12, 21, 24 z uwagi na ich bezprzedmiotowość.

Zgodnie z art. 568 pkt 2 ustawy Izba umarza postępowanie odwoławcze, w formie postanowienia, w przypadku stwierdzenia, że dalsze postępowanie stało się z innej przyczyny zbędne lub niedopuszczalne.

Zamawiający pismem z dnia 10 lipca 2024 roku przekazanym do Izby przedstawił informację zmianach dokonanych w dokumentacji zamówienia.

W oparciu o stanowiskiem doktryny „podstawą do umorzenia postępowania jest również stwierdzenie przez Izbę, że postępowanie stało się z innej przyczyny zbędne

lub niedopuszczalne. Ustawodawca nie doprecyzował, o jakie sytuacje chodzi. Z pewnością dyspozycją przepisu objęte będą sytuacje utraty bytu prawnego przez stronę odwołania,

na skutek likwidacji lub śmierci odwołującego. Wydaje się również, że podstawa umorzenia zaistnieje, jeśli zamawiający przed zakończeniem rozprawy unieważni postępowanie, wówczas spór stanie się bezprzedmiotowy, a ewentualnemu zaskarżeniu w drodze odwołania będzie podlegała nowa czynność zamawiającego.” (Komentarz Prawo Zamówień Publicznych, pod red. Marzeny Jaworskiej, Wydawnictwo C. H. Beck, W-wa 2021, str. 1236).

Ponadto, jak wynika z uchwały Sądu Najwyższego - Izba Cywilna z dnia 18 stycznia 2019 r. III CZP 55/18, w którym SN analizował rozbieżność orzeczniczą skutku procesowego następczej utraty interesu prawnego: przyczyna umorzenia postępowania określona w art. 355 § 1 kpc jako zbędność postępowania stanowi ogólny przejaw uznania przez ustawodawcę, że nie jest dopuszczalne kontynuowanie postępowania w sytuacji, w której jego cel został osiągnięty w inny sposób. W rezultacie wydanie wyroku stało się zbędne. Pojęcie zbędności wydania wyroku jako przyczyny umorzenia postępowania wiązane jest najczęściej z szeroko pojętą następczą bezprzedmiotowością postępowania. Stanowi ona jej swoisty korelat (zbędność wydania wyroku jako następstwo odpadnięcia przedmiotu postępowania ewentualnie inne przypadki niecelowości wydawania wyroku). Dalej Sąd wywiódł, że skoro wskutek zgaśnięcia interesu prawnego powoda - zazwyczaj w rezultacie uzyskania ochrony prawnej poszukiwanej w toczącym się postępowaniu poza jego ramami - proces cywilny nie może doprowadzić do oczekiwanego przez powoda rezultatu (choćby powództwo to w chwili wniesienia było całkowicie zasadne), to dalsze procedowanie

w kierunku wydania wyroku oddalającego to powództwo staje się zbyteczne i bezcelowe.

w pełni wystarczające dla uczynienia zadość prawu stron do sądu i rzetelnego procesu.

Wymaga także podkreślenia, że zgodnie z treścią art. 552 ust. 1 ustawy Izba wydając orzeczenie bierze pod uwagę stan rzeczy ustalony na moment zamknięcia postępowania odwoławczego. Ustawodawca przewidział zatem sytuację, w której może dojść do zmian

w toku postępowania odwoławczego – co Izba zobowiązana jest uwzględnić wydając orzeczenie w sprawie w toku postępowania przed Izbą.

W zakresie postanowień wydanych w sprawie sygn. akt KIO 2125/24

Izba umorzyła postępowanie odwoławcze w zakresie zarzutu 6 z uwagi
‎na uwzględnienia zarzutu odwołania przez Zamawiającego.

Izba umorzyła postępowanie odwoławcze w zakresie zarzutu 1 z uwagi na jego bezprzedmiotowość.

Zamawiający pismem z dnia 10 lipca 2024 roku oraz z dnia 18 lipca 2024 roku przekazanym do Izby przedstawił informację zmianach dokonanych w dokumentacji zamówienia.

W oparciu o stanowiskiem doktryny „podstawą do umorzenia postępowania jest również stwierdzenie przez Izbę, że postępowanie stało się z innej przyczyny zbędne
‎lub niedopuszczalne. Ustawodawca nie doprecyzował, o jakie sytuacje chodzi. Z pewnością dyspozycją przepisu objęte będą sytuacje utraty bytu prawnego przez stronę odwołania,
‎na skutek likwidacji lub śmierci odwołującego. Wydaje się również, że podstawa umorzenia zaistnieje, jeśli zamawiający przed zakończeniem rozprawy unieważni postępowanie, wówczas spór stanie się bezprzedmiotowy, a ewentualnemu zaskarżeniu w drodze odwołania będzie podlegała nowa czynność zamawiającego.” (Komentarz Prawo Zamówień Publicznych, pod red. Marzeny Jaworskiej, Wydawnictwo C. H. Beck, W-wa 2021, str. 1236).

W konsekwencji trzeba przyjąć, że w sytuacji, w której potrzeba udzielenia żądanej przez strony ochrony prawnej uległa dezaktualizacji, wydanie orzeczenia kończącego postępowanie w sprawie o charakterze procesowym w postaci umorzenia procesu jest
‎w pełni wystarczające dla uczynienia zadość prawu stron do sądu i rzetelnego procesu. Wymaga także podkreślenia, że zgodnie z treścią art. 552 ust. 1 ustawy Izba wydając orzeczenie bierze pod uwagę stan rzeczy ustalony na moment zamknięcia postępowania odwoławczego. Ustawodawca przewidział zatem sytuację, w której może dojść do zmian
‎w toku postępowania odwoławczego – co Izba zobowiązana jest uwzględnić wydając orzeczenie w sprawie w toku postępowania przed Izbą.

W zakresie zarzutów skierowanych do rozpoznanie na rozprawie
‎w sprawie o sygn. akt KIO 2105/24

W zakresie zarzutu 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

- Izba zarzut uznała za niezasadny.

Izba ustaliła, że zgodnie ze Specyfikacja Warunków Zamówienia:

8. WARUNKI UDZIAŁU W POSTĘPOWANIU

8.1. O udzielenie zamówienia mogą ubiegać się Wykonawcy, którzy nie podlegają wykluczeniu oraz spełniają określone przez Zamawiającego warunki udziału
‎w postępowaniu.

8.2. O udzielenie zamówienia mogą ubiegać się Wykonawcy, którzy spełniają warunki dotyczące:

8.2.4. zdolności technicznej lub zawodowej:

1) dotyczącej Wykonawcy: Wykonawca spełni warunek jeżeli wykaże, że wykonał,
‎a w przypadku świadczeń powtarzających się lub ciągłych wykonuje, w okresie ostatnich
‎5 lat przed upływem terminu składania ofert, a jeżeli okres prowadzenia działalności jest krótszy – w tym okresie, co najmniej dwie usługi polegające na:

a) rozwoju systemu informatycznego, o wartości usługi co najmniej 3 000 000 zł brutto każda;

b) utrzymaniu systemu informatycznego przez okres co najmniej 12 miesięcy, o wartości usługi co najmniej 1 000 000 zł brutto każda.

Przez system informatyczny Zamawiający rozumie system charakteryzujący się następującymi cechami:

i. komunikacją opartą o wymianę komunikatów z wykorzystaniem przez system usług opartych na Web services w architekturze SOA,

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

iii. wykonany w technologii wielowarstwowej, a interfejs użytkownika był dostępny poprzez przeglądarkę internetową,

iv. zbudowanym w oparciu o serwery aplikacyjne,

v. zbudowany w technologii Java,

vi. wykorzystujący silnik procesów, za pomocą którego zaimplementowano co najmniej 10 procesów biznesowych,

vii. umożliwia podpisywanie dokumentów i komunikatów przetwarzanych przez system za pomocą: kwalifikowanego podpisu elektronicznego lub Profilu Zaufanego (ePUAP)1 lub e-Dowodu2;

viii. system o wysokiej dostępności HA, w trybie 24/7/365.

Przez utrzymanie systemu informatycznego Zamawiający rozumie co najmniej:

i. usuwanie błędów systemu,

ii. udzielanie konsultacji użytkownikom i administratorom systemu,

iii. aktualizację dokumentacji systemu

Przez jedną usługę rozumie się usługę świadczoną w ramach jednej umowy dla jednego podmiotu.

10. PODMIOTOWE ŚRODKI DOWODOWE

10.7. W celu potwierdzenia spełniania przez Wykonawcę warunków udziału w postępowaniu Wykonawca składa:

1) wykaz usług wykonanych, a w przypadku świadczeń powtarzających się lub ciągłych również wykonywanych, w okresie ostatnich 5 lat przed upływem terminu składania ofert,
‎a jeżeli okres prowadzenia działalności jest krótszy – w tym okresie, wraz z podaniem
‎ich wartości, przedmiotu, dat wykonania i podmiotów, na rzecz których usługi zostały wykonane lub są wykonywane, oraz załączeniem dowodów określających, czy te usługi zostały wykonane lub są wykonywane należycie, przy czym dowodami, o których mowa,
‎są referencje bądź inne dokumenty wystawione przez podmiot, na rzecz którego usługi były wykonywane, a w przypadku świadczeń powtarzających się lub ciągłych są wykonywane,
‎a jeżeli Wykonawca z przyczyn niezależnych od niego nie jest w stanie uzyskać tych dokumentów – oświadczenie wykonawcy;

w przypadku świadczeń powtarzających się lub ciągłych nadal wykonywanych, referencje bądź inne dokumenty potwierdzające ich należyte wykonywanie powinny być wystawione
‎w okresie ostatnich 3 miesięcy przed upływem terminu składania ofert (Formularz 3.6. do IDW);

zgodnie z Formularzem 3.6 do IDW – Wykaz usług, Zamawiający określił kolumny tabeli definiując zakres wymaganych informacji:

Lp.

Usługa potwierdzająca spełnienie warunku udziału w postępowaniu,
‎o którym mowa w IDW

Nazwa Wykonawcy usługi

Podmiot, na rzecz którego wykonana była usługa

Okres realizacji

początek

dzień/ miesiąc/

rok

koniec

dzień/ miesiąc/

rok

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

- art. 128 ust. 4 ustawy - Zamawiający może żądać od wykonawców wyjaśnień dotyczących treści oświadczenia, o którym mowa w , lub złożonych podmiotowych środków dowodowych lub innych dokumentów lub oświadczeń składanych w postępowaniu.

- art. 128 ust. 5 ustawy - Jeżeli złożone przez wykonawcę oświadczenie, o którym mowa w , lub podmiotowe środki dowodowe budzą wątpliwości zamawiającego, może on zwrócić się bezpośrednio do podmiotu, który jest w posiadaniu informacji lub dokumentów istotnych w tym zakresie dla oceny spełniania przez wykonawcę warunków udziału
‎w postępowaniu, kryteriów selekcji lub braku podstaw wykluczenia, o przedstawienie takich informacji lub dokumentów.

Art. 112 ust. 1 ustawy - Zamawiający określa warunki udziału w postępowaniu w sposób proporcjonalny do przedmiotu zamówienia oraz umożliwiający ocenę zdolności wykonawcy do należytego wykonania zamówienia, w szczególności wyrażając je jako minimalne poziomy zdolności.

Rozporządzenie Ministra rozwoju, pracy i technologii w sprawie podmiotowych środków dowodowych oraz innych dokumentów lub oświadczeń, jakich może żądać zamawiający od wykonawcy z dnia 23 grudnia 2020 r. – dalej: Rozporządzenie.

§ 9 ust. 1 - W celu potwierdzenia spełniania przez wykonawcę warunków udziału
‎w postępowaniu lub kryteriów selekcji dotyczących zdolności technicznej lub zawodowej, zamawiający może, w zależności od charakteru, znaczenia, przeznaczenia lub zakresu robót budowlanych, dostaw lub usług, żądać następujących podmiotowych środków dowodowych:

(…)

2) wykazu dostaw lub usług wykonanych, a w przypadku świadczeń powtarzających się lub ciągłych również wykonywanych, w okresie ostatnich 3 lat, a jeżeli okres prowadzenia działalności jest krótszy – w tym okresie, wraz z podaniem ich wartości, przedmiotu, dat wykonania i podmiotów, na rzecz których dostawy lub usługi zostały wykonane lub są wykonywane, oraz załączeniem dowodów określających, czy te dostawy lub usługi zostały wykonane lub są wykonywane należycie, przy czym dowodami, o których mowa, są referencje bądź inne dokumenty sporządzone przez podmiot, na rzecz którego dostawy lub usługi zostały wykonane, a w przypadku świadczeń powtarzających się lub ciągłych są wykonywane, a jeżeli wykonawca z przyczyn niezależnych od niego nie jest w stanie uzyskać tych dokumentów – oświadczenie wykonawcy; w przypadku świadczeń powtarzających się lub ciągłych nadal wykonywanych referencje bądź inne dokumenty potwierdzające ich należyte wykonywanie powinny być wystawione w okresie ostatnich 3 miesięcy.

Izba zważyła:

W pierwszej kolejności Izba wskazuje, że warunki udziału w postępowaniu mają zostać spełnione przez wykonawcę ubiegającego się o zamówienie (ewentualnie przy udziale podmiotu trzeciego). W art. 112 ust. 1 ustawy prawodawca jednoznacznie odwołał się do oceny zdolności wykonawcy do należytego wykonania zamówienia – taki jest zatem cel stawiania warunku udziału w postępowaniu w zakresie doświadczenia zdolności wykonawcy. Wymaga podkreślania w tym miejscu, że kształtując warunki udziału
‎w postępowaniu Zamawiający obowiązany jest do zachowania równowagi pomiędzy interesem Zamawiającego (należytego wykonania zamówienia), a interesami wykonawców.

Warunek udziału w postępowaniu określony przez Zamawiającego ma być proporcjonalny
‎do przedmiotu zamówienia, tym samym znaczenie warunku powiązane jest bezpośrednio
‎z przedmiotem zamówienia, ale jedynie w takim zakresie jaki będzie w tym warunku zawarty i nie będzie nadmiarowy. Dostrzec należy, że w ramach podniesionego zarzutu odwołania Odwołujący nie kwestionuje warunku udziału w postępowaniu – co oznacza,
‎że tak ukształtowany przez Zamawiającego warunek udziału w postępowaniu uznaje
‎za zasadny. Odwołujący nie kwestionuje również informacji określonych w zakresie wskazanego podmiotowego środka dowodowego określonego w SWZ. Jednoznacznie podaje Zamawiający w punkcie 10.7. SWZ, że w celu potwierdzenia spełniania przez Wykonawcę warunków udziału w postępowaniu Wykonawca składa wykaz usług wraz z podaniem podmiotów, na rzecz których usługi zostały wykonane lub są wykonywane. To wymaganie Zamawiającego odpowiada w sposób dokładny zakresowi jaki określa Rozporządzenie.

Przedstawienie przez wykonawcę informacji w wykazie usług oraz przedstawienie podmiotowych środków dowodowych powinny być przedstawione rzetelnie, należy mieć bowiem na uwadze, co pomija Odwołujący, że nieprzedstawienie informacji zgodnie
‎z prawdą podlegać będzie odpowiedzialności wykonawcy, którą odnajdujemy w regulacjach np. przepisów karnych ( Kodeksu karnego).

Ukształtowanie warunków udziału w postępowaniu oraz podmiotowych środków dowodowych jest w sposób szczegółowy oraz zamknięty określone w ustawie
‎i Rozporządzeniu. W tym zakresie nie ma miejsca na dowolne rozszerzanie zakresu warunków jak i zakresu informacji jakich może oczekiwać Zamawiający od wykonawcy.
‎Nie sposób w ocenie Izby uznać za właściwe rozszerzenie katalogu informacji zawartych
‎w wykazie usług, bowiem określenie zakresu informacji jakie mają zostać zawarte w wykazie usług jest wtórne do zakresu informacji jakie zostały określone w warunku udziału
‎w postępowaniu definiowanym w danym postępowaniu oraz determinowanym zakresem informacji określonych w rozporządzeniu. Przyjęcie rozwiązania, w którym możliwe byłoby pozyskiwanie w ramach wykazu usług szerszego niż określony w rozporządzeniu zakresu informacji wynikający z regulacji Rozporządzenia prowadziłby do odstąpienia
‎od obowiązujących zasad proceduralnych oraz na mogłoby wprowadzić nieskończony chaos w sformalizowanych i skodyfikowanych procedurach o udzielnie zamówienia publicznego.
‎W zakresie Rozporządzenia jednoznacznie określonym jest, że Zamawiający może żądać informacji na temat podmiotu, na rzecz którego usługa została wykonana lub jest wykonywana, w żaden sposób nie dopuszcza prawodawca szerszego zakresu informacji jakich oczekiwać może Zamawiający od wykonawców biorących udział w postępowaniu.

Zarzutem odwołania w przedmiotowej sprawie jest „brak wymogu określenia
‎w Formularzu 3.6 „Wykaz usług” podmiotu, który jest w posiadaniu informacji oraz dokumentów dla oceny spełnienia przez wykonawcę warunków udziału w postępowaniu oraz kryteriów selekcji”.

Powiązując zarzut odwołania z wnioskami podniesionymi przez Odwołujacego oraz argumentacją jednoznacznie należy stwierdzić, że Odwołujący kwestionuje brak zawarcia ww. Formularzu 3.6 wymagania wskazania, w przypadku, gdy podmiot, na rzecz którego wykonano usługę (strona umowy) nie jest podmiotem, który użytkuje system informatyczny informacji zarówno o stronie umowy oraz o podmiocie użytkującym rzeczywiście system,
‎co pozwoli na rzeczywiste wykazanie wymagania z warunku umożliwienia jednoczesnego korzystania z systemu informatycznego przez minimum 500 użytkowników.

Izba zaznacza, mając na uwadze całą powyższą argumentację, że zgodnie
‎z obowiązującymi przepisami Zamawiający dokonując oceny zdolności wykonawcy
‎do realizacji zamówienia nie ma nieograniczonych możliwości kształtowania zakresu informacji jakich może oczekiwać od wykonawcy. Rozporządzenie w zakresie informacji odnoszącego się do podmiotu jest jednoznaczne odnosząc się do podmiotu na rzecz które zrealizowano lub realizuje wykonawca umowę. W ocenie Izby na podstawie ustawy, wbrew twierdzeniu Odwołujacego nie ma możliwości rozszerzenia katalogu informacji niezbędnych do przekazania w wykazie usług, a definiowanych katalogiem określonym
‎w Rozporządzeniu. Wynika ta okoliczność z tego, że zgodnie z art. 124 pkt 2 ustawy
‎w postępowaniu o udzielnie zamówienia publicznego Zamawiający może żądać podmiotowych środków dowodowych na potwierdzenie spełniania warunku udziału
‎w postępowaniu lub kryteriów selekcji. To oznacza, że ocena w zakresie warunku dokonana może być jedynie w oparciu o podmiotowy środek dowodowy, a ten środek dowodowy jest zdefiniowany co do zakresu informacji w Rozporządzaniu. W konsekwencji prowadzi
‎to do wniosku, że nie jest możliwe w obliczu ustawy rozszerzenie katalogu informacji zawartych w wykazie usług.

Izba ma świadomość odrębnego rozstrzygnięcia wskazanego przez Odwołujacego w sprawie sygn. akt KIO 442/24 oraz wydanego wyroku Sądu Okręgowego sygn. akt XXIII Zs 59/24. Izba zaznacza, że w powołanym orzeczeniu Izby w żaden sposób nie została uwidoczniona analiza prawna istniejącego stanu prawnego, co spowodowało, że brak jest faktycznej argumentacji uzasadniającej przyjęcie, "Dane identyfikujące usługę (w tym nazwa systemu/oprogramowania/narzędzia, oraz nazwę i dane teleadresowe jego użytkownika)" mieszczą się w pojęciu "przedmiotu zamówienia" sensu largo w rozumieniu powołanego wyżej przepisu rozporządzenia. Zgodnie z Rozporządzenie Zamawiający może oczekiwać podania co do usług informacji odnoszących się do „wartości, przedmiotu, dat wykonania
‎i podmiotów, na rzecz których dostawy lub usługi zostały wykonane lub są wykonywane”.
‎W ww. wyroku Izba bazuje na szerokim znaczeniu pojęcia „przedmiotu zamówienia” jednakże w ocenie tego składu nie ma takiej podstawy do rozszerzającego stosowania wykładni tak istotnych elementów jak wymagania w zakresie wykazania spełnienia warunku udziału w postępowaniu. Korzystanie z szerokiej wykładni prowadzi do zmiany sensu obowiązującej regulacji prawnej, bowiem prawodawca przyjął, że odpowiednim dla oceny spełnienia warunku jest wskazanie podmiotu, na rzecz którego realizowana była lub nadal jest usługa. Prawodawca nie widział potrzeby podawania innego, szerszego zakresu podmiotowego, nie widzi potrzeby podawania wielości podmiotów do jakiego dąży Odwołujący. Ta nadinterpretacja wymagań odnośnie informacji dotyczących warunku udziału w postępowaniu może skutkować w efekcie niemożliwością weryfikacji podanych danych
‎w oparciu o istniejące podstawy prawne. Jednocześnie może prowadzić do praktyki
‎w zamówieniach publicznych uzasadniających żądanie podania w ramach warunków udziału w postępowaniu informacji jakie nie są określone przez prawodawcę. Podkreślenia wymaga również, że ugruntowanym w orzecznictwie i potwierdzonym w doktrynie przedmiotu jest stanowisko ścisłego odczytywania warunków udziału w postępowaniu. Tym samym skoro warunek ma być ściśle odczytywany i nie ma miejsca na jego szeroka interpretację, to również na etapie jego kształtowania, a w ślad za tym wskazywania informacji dla jego oceny nie można odnosić do szerokiej wykładni, która nie wynika z regulacji prawnych. Stanowisko prezentowane przez Odwołujacego, mając na uwadze argumentację odnoszącą się do konieczności podania zarówno podmiotu, na rzecz którego usługa jest zrealizowana lub realizowana (strona umowy) oraz podmiotu rzeczywiście użytkującego system należałoby ująć w ramy wniosku de lege ferenda. Przy czym na etapie postępowania o zamówienie nie ma miejsca na wprowadzanie wyinterpretowanych, w żaden sposób nieuzasadniony, wymagań nieokreślonych przepisami prawa. W odniesieniu do wyroku Sądu Okręgowego Izba nie jest w stanie przedstawić stanowiska bowiem na tym etapie uzasadnienie sądu nie jest znane.

Izba zaznacza jednocześnie, że Zamawiający nie jest w żaden sposób pozbawiony możliwości weryfikacji informacji przedstawionych przez wykonawcę w ramach wykazania spełnienia warunku zamówienia na co jednoznacznie wskazuje regulacja art. 128 ust. 4 i 5 ustawy. Wymaga podkreślenia, że w powoływanym przez Odwołujacego orzeczeniu Izby sygn. akt KIO 442/24 brak jest jakiegokolwiek odniesienia do tych narzędzi przydanych Zamawiającemu przez prawodawcę.

Z art. 128 ust. 5 ustawy jednoznacznie wynika, że Zamawiający ma prawo zwrócić się
‎do podmiotu, który jest w posiadaniu informacji czy dokumentów dla oceny spełnienia przez wykonawcę warunków zamówienia. Jednoznacznie przepis pozwala Zamawiającemu
‎na weryfikację informacji, o ile zajdzie taka potrzeba, bezpośrednio u podmiotów posiadającego informacje, w tym przypadku zapewne będzie to właśnie ten podmiot który jest rzeczywistym użytkownikiem systemu. Przy czym wymaga podkreślenia,
‎że ustawodawca dowalając na takie działania Zamawiającego nie ukształtował jednoczenie wymagania w zakresie wskazania w podmiotowych środkach dowodowych nazwy tego podmiotu. Ustawodawca zdefiniował ten podmiot, jako ten który posiada informacje lub dokumenty istotne w postępowaniu – to oznacza, że nie odnosi tego uprawnienia Zamawiającego jedynie do wystawcy referencji czy podmiotu na rzecz którego realizowana była usługa. Ten podmiot został określony przez ustawodawcę szeroko, przez zdefiniowane go jako ten co posiada określone informacje i dokumenty. Taki zabieg prawodawcy pozwala Zamawiającemu na szerokie pozyskiwanie informacji w celu weryfikacji złożonych przez wykonawcę podmiotowych środków dowodowych czy oświadczeń, o których mowa w art. 125 ust. 1 ustawy. Natomiast w przypadku jakichkolwiek wątpliwości, zgodnie z art. 124 ust. 4 ustawy zawsze Zamawiający może zwrócić się o wyjaśnienia treści oświadczeń czy podmiotowych środków dowodowych. Wachlarz czynności jakie może podejmować Zamawiający jest szeroki, pozwalający na pozyskanie przez Zamawiającego oraz ocenę warunku spełnienia zamówienia przez danego wykonawcę. Natomiast wprowadzenie
‎do zakresu informacji wymagania o podaniu nazwy podmiotu, na którego rzecz nie była realizowana usługa, jak tego oczekuje Odwołujący, stanowiłaby zapewne naruszenie zasady proporcjonalności określonej w zamówieniach publicznych jako zasady generalnej. Zdaniem Izby Odwołujący nie wykazał naruszenia podnoszonych w zarzucie odwołania regulacji prawnych.

W zakresie zarzutu 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;

- Izba zarzut uznała za zasadny.

W zakresie rozpoznania zarzutów odwołania

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

- art. 16 ustawy - Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób:

1) zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców;

2) przejrzysty;

3) proporcjonalny.

- art. 99 ust. 1 ustawy - Przedmiot zamówienia opisuje się w sposób jednoznaczny
‎i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń, uwzględniając wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty.

- art. 99 ust. 4 ustawy - Przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję, w szczególności przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli mogłoby to doprowadzić do uprzywilejowania lub wyeliminowania niektórych wykonawców lub produktów.

Ustawa z dnia 23 kwietnia 1964 roku Kodeks cywilny (tj. z dnia 2 sierpnia 2023 r. (Dz.U. z 2023 r. poz. 1610) dalej: KC)

- art. 387 KC

§ 1. Umowa o świadczenie niemożliwe jest nieważna.

§ 2. Strona, która w chwili zawarcia umowy wiedziała o niemożliwości świadczenia, a drugiej strony z błędu nie wyprowadziła, obowiązana jest do naprawienia szkody, którą druga strona poniosła przez to, że zawarła umowę nie wiedząc o niemożliwości świadczenia.

Izba ustaliła:

TOM II SWZ - PROJEKTOWANE POSTANOWIENIA UMOWY (dalej: PPU)

§ 7 Prawa własności intelektualnej

15. Licencja na dokumentację dotyczącą Oprogramowania COTS obejmuje:

1) w zakresie utrwalania i zwielokrotniania – wytwarzanie dowolną techniką egzemplarzy, w tym techniką drukarską, reprograficzną, zapisu magnetycznego oraz techniką cyfrową,

2) w zakresie obrotu oryginałem albo egzemplarzami, na których ją utrwalono – wprowadzanie do obrotu, użyczenie lub najem oryginału albo egzemplarza,

3) 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ć do niej dostęp w miejscu i w czasie przez siebie wybranym.

16. Licencja na dokumentację dotyczącą Oprogramowania COTS obejmuje także zezwolenie na wykonywanie zależnych praw autorskich do wszelkich opracowań tej dokumentacji, to jest rozporządzanie i korzystanie z takich opracowań w zakresie wszystkich uprawnień nabytych przez Zamawiającego stosownie do postanowień niniejszego paragrafu.

17. 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 w niniejszym paragrafie. W przypadku gdyby postanowienie o niewypowiadalności licencji przewidziane w zdaniu poprzedzającym okazało się nieskuteczne lub nieważne, Strony uzgadniają 10-letni (słownie: dziesięcioletni) termin jej wypowiedzenia ze skutkiem na koniec roku kalendarzowego, z zastrzeżeniem, iż Wykonawca zobowiązuje się nie korzystać z uprawnienia do wypowiedzenia licencji z wyjątkiem przypadków, w których Zamawiający przekroczy warunki udzielonej licencji i naruszy autorskie prawa majątkowe przysługujące Wykonawcy oraz nie zaniecha naruszenia mimo wezwania Wykonawcy i wyznaczenia mu w tym celu odpowiedniego terminu, nie krótszego niż 30 dni. Wezwanie musi być wystosowane w formie pisemnej pod rygorem braku skutków i musi zawierać wyraźne zastrzeżenie, że Wykonawca będzie uprawniony do wypowiedzenia licencji w przypadku niezaprzestania dopuszczania się przez Zamawiającego wyraźnie i precyzyjnie wymienionych naruszeń.
‎W przypadku wypowiedzenia licencji z tej przyczyny termin wypowiedzenia licencji wynosi
‎1 (słownie: jeden) rok, ze skutkiem na koniec roku kalendarzowego.

18. Treść licencji na Oprogramowanie COTS zostanie dostarczona przez Wykonawcę razem z oprogramowaniem. Wykonawca oświadcza, że w zakresie, w jakim licencje te mogłyby zostać uznane za sprzeczne z wymaganiami Umowy opisanymi powyżej i w załącznikach do

Umowy, uzyskał od podmiotu któremu przysługują prawa majątkowe zgodę na modyfikację tych warunków, tak by licencje były zgodne z wymaganiami opisanymi Umową.

(…)

20. Wykonawca oświadcza i gwarantuje, że jeżeli w ramach opłat należnych producentowi Oprogramowania COTS mieści się opłata za jakiekolwiek dodatkowe świadczenia, w szczególności dostarczanie aktualizacji lub poprawek błędów lub inne usługi serwisowe, nieprzedłużenie korzystania z tych świadczeń przez Zamawiającego nie może powodować ustania licencji na korzystanie z Oprogramowania lub uprawniać do wypowiedzenia umowy licencyjnej.

(…)

23.

W ramach udzielonej licencji Wykonawca zapewnia, że Zamawiający może dokonywać zmian uzasadnionych potrzebami technicznymi lub ekonomicznymi lub innymi uzasadnionymi potrzebami Zamawiającego we wszystkich utworach dostarczonych przez Wykonawcę, a także powierzać dokonanie takich zmian innym osobom. Dotyczy to również powierzania usług podmiotom trzecim.

(…)

25. Licencje na Oprogramowanie COTS nie mogą ograniczać uprawnień Zamawiającego opisanych w Umowie oraz Załączniku nr 1 do Umowy, a w szczególności nie mogą ograniczać korzystania z Platformy Sprzętowo-Programowej i posiadanego oprogramowania Zamawiającego oraz innego oprogramowania zainstalowanego przez Zamawiającego lub innych uprawnionych użytkowników, a także ograniczać możliwości powierzenia utrzymania infrastruktury sprzętowej i posiadanego oprogramowania podmiotom trzecim niezależnym od Wykonawcy.

(…)

29. Zamawiający ma prawo do przeniesienia uprawnień i obowiązków wynikających z Umowy na osoby lub podmioty trzecie.

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

TOM III SWZ Opis przedmiotu zamówienia, zwany dalej: OPZ na „Świadczenie usług rozwoju i utrzymania Systemu SZPROT”

Oprogramowanie COTS

Izba zważyła:

W ramach przedmiotowego opisu przedmiotu zamówienia Zamawiający podał definicję oprogramowania COTS jako powszechnie dostępnego oprogramowania standardowego wytwarzanego seryjnie, dostarczanego w formie gotowego produktu (inne
‎niż oprogramowanie dedykowane lub FOSS).

Zmawiający w swoim stanowisku skupił w zasadzie uwagę na tym, że oprogramowanie gotowe COTS nie jest oprogramowaniem wymaganym w ramach prowadzonego postępowania, nie obliguje wykonawcy do wykorzystania tego oprogramowania. Zamawiający podnosił również, że w ramach realizacji zamówienia zgodnie z opisem przedmiotu zamówienia wykonawca może przy realizacji poszczególnych usług wykorzystać oprogramowanie COTS. W ocenie Izby słusznie zwrócił uwagę Odwołujący, poparty przez uczestników, że na tym etapie tj. procedowania postępowania o udzielnie zamówienie nie jest w stanie jednoznacznie stwierdzić, czy w ramach realizacji poszczególnych usług konieczne będzie zastosowanie Oprogramowania COTS do rozwoju systemu SZPROT.

W ocenie Izby nie uzasadnia wprowadzenia regulacji zawartych w par. 7 w poszczególnych punktach Projektowanych postanowień umowy (dalej: PPU) argumentacja Zamawiającego wskazująca na to, że aktualna wersja systemu SZPROT nie wykorzystuje odpłatnego oprogramowania typu COTS a Zamawiający pozostawia wykonawcy możliwość zastosowania oprogramowania gotowego do realizacji Nowych wersji Systemu
‎na określonych w par. 7 PPU warunkach, co ma w ocenie Zamawiającego zapewniać konkurencyjność w prowadzonym jak i w przyszłych postępowaniach.

Realizacja wymagań przedmiotu zamówienia ma być w pierwszej kolejności możliwa,
‎co oznacza, że oczekiwania Zamawiającego co do przedmiotu zamówienia, w tym przypadku dopuszczonego zastosowania Oprogramowania COTS, musi dać się wykonać
‎w ramach realizacji zamówienia. Fakt ewentualności zastosowania Oprogramowania COTS w żaden sposób również nie uzasadnia postanowień jakie nie są możliwe do spełnienia przy dostarczeniu licencji na Oprogramowanie COTS.

Zamawiający odwołuje się do „Wzorcowych klauzul w umowach IT” przy czym w żaden sposób nie wyjaśnia w jakim zakresie bazował na tych wzorcowych klauzula oraz nie przedstawia ich, natomiast nie jest to dokument powszechnie obowiązujący.

Podkreślenia wymaga, że jak to nazywa Zamawiający „przyjęte przez Zamawiającego rozwiązania są pewnym novum w sposobie usług dedykowanych dla istniejących
‎już systemów”, ale jednocześnie Zamawiający nie wyjaśnia w jaki sposób Oprogramowanie COTS, które to oprogramowanie jest standardowe wytwarzane seryjnie, dostarczane
‎w formie gotowego zamkniętego produktu, ma odpowiadać tak szczegółowym wymaganiom licencyjnym określonym w par. 7 PPU. Licencje dla oprogramowania COTS są z góry określone przez producenta/producentów tych oprogramowani i co do zasady nie podlegają żadnym zmiana i negocjacją, co jest właśnie ich istotą. W ocenie Izby podkreślenia wymaga również wskazane w trakcie rozprawy, co znajduje odzwierciedlenie w pisemnym protokole rozprawy stanowisko Zamawiającego, że postanowienia PPU dotyczą właśnie warunków licencji. Zamawiający wyjaśniał także, że istnieją oprogramowania typu framework, które pozwalają na modyfikację oprogramowania COTS do postaci określonej wymaganiami zamawiającego z pra. 7 PPU w zakresie modyfikacji oprogramowania. Jednakże takie oprogramowania nie zmieniają postanowień z góry narzuconej licencji Oprogramowania COTS, który jest gotowym produktem licencjonowanym na standardowych warunkach
‎do stanu jaki określa dla tej licencji Zamawiający w postanowieniach par. 7 PPU.

Wymagania odnoszące się do postanowień licencji jakie ukształtował Zamawiający, mając na uwadze jak podaje Zamawiający, że jest to oprogramowanie powszechnie dostępne oprogramowanie standardowe wytwarzane seryjnie, dostarczane w formie gotowego zamkniętego produktu, a zawarte w tych poszczególnych punktach paragrafu 7 PPU (takie jak między innymi: przenaszalność, dające możliwość Zamawiającemu wprowadzenia jakichkolwiek zmian układu lub jakichkolwiek innych zmian, umożliwiające tłumaczenia, przystosowania, niewypowiadalne prawo do korzystania z COTS i dokumentacji ewentualnie 10 letni termin wypowiedzenia w przypadku ograniczenia jedynie do przypadków naruszenia autorskich praw majątkowych, dające prawo do używania oprogramowania przez Ministra Finansów, jednostki organizacyjne i nadzorowane przez Ministra Finansów) przy braku wpływu wykonawcy na zakres udzielonej licencji przez producenta Oprogramowania COTS powodują, że postanowienia PPU są niemożliwe do spełnienia.

Opisanie przedmiotu zamówienia przez określenie wymagania niemożliwego do spełnienia
‎z uwagi na brak wpływu wykonawcy na producenta oprogramowania COTS co do treści udzielanej licencji, stanowi przejaw braku racjonalności w kreowaniu postanowień PPU definiujących w tym wypadku przedmiot zamówienia, których nie da się wykonać oraz nie da się wyegzekwować przymusowo. Uwzględniając stanowiska doktrynalne w zakresie art. 387 KC zaznaczyć należy, że ww. przepis w par. 1 „wyraża w istocie myśl, że kreowanie zobowiązania do spełnienia takiego świadczenia stanowi niedopuszczalną treść umów obligacyjnych” (Zobowiązania. Tom I i II. Komentarz, red. prof. dr hab. P.M.

Rok:2024, wyd. 1, Legalis).

W zakresie naruszenia regulacji ustawowych Izba stwierdza w tym miejscu,
‎że wprowadzenie do PPU postanowień par. 7 w zakresie ponoszonym przez Odwołujacego ust. 13, 14, 15, 16, 17, 18, 20, 23, 25, 29, 30, które w obliczu powyższych ustaleń i argumentów stanowią kreowanie zobowiązań niemożliwych do spełnienia świadczenia jakie określa Zamawiający ww. postanowienia umowy, a tym samym stanowią w ocenie Izby naruszenie art. 99 ust. 1 ustawy bowiem niewątpliwie mogą mieć wpływ na sporządzenie oferty oraz art. 99 ust. 4 ustawy, bowiem tak sporządzony opis przedmiotu zamówienia mogłyby uprzywilejować jedynie producentów oprogramowania COTS, którzy mieliby możliwość zmian postanowień licencji. Jednocześnie postawione naruszenia naruszają zasady prawa zamówień publicznych w tym prowadzenia postępowania o udzielnie
‎w zakresie konkurencyjności wykonawców oraz ich równości, a także proporcjonalności.

Izba wskazuje w tym miejscu, że zgodnie z art. 554 ust. 1 pkt 2 ustawy, Izba uwzględni odwołanie w całości lub w części, jeżeli stwierdzi niezgodność projektowanego postanowienia umowy z wymaganiami wynikającymi z przepisów ustawy oraz w przypadku uwzględnienia odwołania zgodnie z art. 554 ust. 3 pkt 1 lit. c ustawy, Izba może nakazać zmianę projektowanego postanowienia umowy albo jego usunięcie, jeżeli jest niezgodne z przepisami ustawy. Na podstawie art. 554 ust. 6 ustawy, Izba nie może nakazać wprowadzenia do umowy postanowień o określonej treści, co w ocenie Izby oznacza,
‎że kontrola projektowanych postanowień umowy odbywa się jedynie pod względem legalności, a nie celowości, efektywności ekonomicznej projektowanych postanowień. Izba, jeśli ustali, że dane postanowienie umowne jest niezgodne z ustawą może jedynie nakazać wykreślenie postanowienia albo jego zmianę wskazując w uzasadnieniu, na czym polegało naruszenie, ale konkretna treść zmiany pozostaje w wyłącznej gestii Zamawiającego i to on za jej brzmienie ponosi wyłączną odpowiedzialność (tak też: Wyrok Krajowej Izby Odwoławczej z dnia 18 października 2022 roku sygn. akt KIO 2592/22, wyrok z dnia 13 listopada 2023 roku sygn. akt KIO 3135/23, KIO 3136/23, KIO 3179/23). Poza zakresem kognicji Izby jest kształtowanie określonych postanowień umowy oraz nakazywanie określonej treści umowy (tak też: wyrok Krajowej Izby Odwoławczej z dnia 18 marca 2022 roku sygn. akt KIO 622/22).

Mając na uwadze powyższe, uwzględniając wniosek Odwołujacego, Izba nakazała Zamawiającemu wykreślenie z Tom II SWZ – Projektowane postanowienia umowy treści określonych w § 7 ust. 13, 14, 15, 16, 17, 18, 20, 23, 25, 29, 30.

W zakresie zarzutu IVA - 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 - Izba zarzut uznała za niezasadny.

W zakresie rozpoznania zarzutów odwołania

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

- art. 16 ustawy - Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób:

1) zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców;

2) przejrzysty;

3) proporcjonalny.

Izba ustaliła:

TOM III SWZ Opis przedmiotu zamówienia, zwany dalej: OPZ na „Świadczenie usług rozwoju i utrzymania Systemu SZPROT”

Awaria

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.

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.

Błąd Blokujący

Błąd uniemożliwiający wykonanie co najmniej jednej funkcji Systemu. Błąd Blokujący powoduje powstawanie wyników o cechach niezgodnych z opisanymi w instrukcji użytkownika i specyfikacji funkcjonalnej.

Z zastrzeżeniem przypadku opisanego w definicji Awarii, jako Błąd Blokujący będzie także traktowany każdy inny problem z wydajnością Systemu. Przez problem wydajnościowy Systemu rozumie się stwierdzone przez okres dłuższy niż 2 h, odstępstwo od parametrów minimalnych albo maksymalnych związanych z wydajnością Systemu, o których mowa w Załączniku nr 1 do OPZ.

Błąd Poważny

Błąd Średni

Błąd Drobny

Błąd regresji

Błąd dotyczący funkcjonalności działającej poprawnie we wcześniejszych wersjach Platformy Programowej.

TOM III SWZ Opis przedmiotu zamówienia, zwany dalej: OPZ na „Świadczenie usług rozwoju i utrzymania Systemu SZPROT”

5.2.7. 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, wskazując jedynie, że Błąd wynika
‎z wadliwego działania Platformy Sprzętowo-Programowej. Wykonawca oznacza Zgłoszenie serwisowe jako rozwiązane. Zamawiający weryfikuje informację przekazaną przez Wykonawcę. Zamawiający zamyka Zgłoszenie, jeżeli potwierdzi, że przyczyną Błędu jest wadliwe działanie Platformy Sprzętowo-Programowej. Zamawiający przekazuje Zgłoszenie ponownie do Wykonawcy (otwiera Zgłoszenie w CSD), jeżeli nie potwierdzi, że źródłem Błędu jest wadliwe działanie Platformy Sprzętowo-Programowej. 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.

Załącznik nr 1 do OPZ - Opis Systemu SZPROT

4.5 Minimalne wymagania wydajnościowe Systemu SZPROT

System SZPROT został zbudowany o następujące parametry wydajnościowe:

Obsługa co najmniej 16000 Użytkowników wewnętrznych,

zapewnienie co najmniej 2000 jednoczesnych sesji Użytkownika wewnętrznego w Systemie.

czas odpowiedzi na proste funkcjonalności, związane z wprowadzaniem, edycją i aktualizacją danych - do 2 sekund.

czas ładowania pliku o wielkości 500kB do kontrolek formularza nie może być większy niż 2 sekundy.

czas walidacji 20 pól każdego formularza z wykorzystaniem mechanizmów wewnętrznych Systemu nie może być większy niż 500 ms.

maksymalny czas logowania Użytkownika wewnętrznego w Systemie nie może być większy niż 5 sekund.

Według zmian Specyfikacji Warunków Zamówienia z dnia 10 lipca 2024 roku, które zostały opublikowane 10 lipca 2024 r. na stronie internetowej prowadzonego postępowania, zmieniono OPZ w następujący sposób:

Awaria

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 w wymaganiach wydajnościowych, o których mowa w Załączniku nr 1 do OPZ.

Wykonawca nie odpowiada za usunięcie Błędów, których przyczyną jest nieprawidłowe działanie Platformy Sprzętowo-Programowej.

Błąd

Stan Systemu mogący skutkować lub skutkujący ograniczeniem bądź brakiem realizacji dowolnej funkcji Systemu. W szczególności Błędem jest działanie Systemu niezgodne z Dokumentacją 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 nieprawidłowego działania otoczenia Systemu lub zmian w otoczeniu Systemu, w szczególności błędów działania Platformy Sprzętowo-Programowej, systemów zewnętrznych, zmian infrastruktury, technologii lub przepisów prawa.

Błąd Blokujący

Błąd Poważny

Błąd Średni

Błąd Drobny

Błąd regresji

Błąd dotyczący funkcjonalności działającej poprawnie we wcześniejszych wersjach Platformy Programowej.

Izba zważyła:

W ramach argumentacji odnoszącej się do zarzutu dotyczącej definicji „Awaria” Odwołujący wskazał, że przedstawione zostały w opisie definicji nieostre i otwarte przesłanki uznania danej sytuacji za Awarię. W ocenie Izby postanowienia zawarte w definicji „Awaria” w sposób jednoznaczny wskazuje, że Awarią jest błąd polegający na „całkowitym unieruchomieniu Sytemu lub jednego z jego Komponentów lub brak dostępu do co najmniej jednego z jego Komponentów”. Izba nie podziela stanowiska Odwołujacego odnoszącego się do tego, że Awaria została zdefiniowana, przez podanie w dalszej części, przejawów wystąpienia Awarii, bowiem wskazanie tych elementów stanowi w zasadzenie przykładowe wyliczenie objawów jakie Awaria wywołała. Wymaga ponownie podkreślenia,
‎że w przypadku definicji Zamawiającego Awarią Sytemu będzie w zasadzie niedostępność systemu lub jednego z jego Komponentów lub brak dostępu do co najmniej jednego
‎z komponentów.

Zamawiający podał również, że 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 w wymaganiach wydajnościowych, o których mowa w Załączniku nr 1
‎do OPZ. Przy czym w odniesieniu do tego postanowienia brak jest argumentacji Odwołujacego.

W odniesieniu do kolejnego z argumentów podniesionych przez Odwołujacego,
‎a mających zakotwiczenie w stanowisku dotyczącym nieprawidłowości postanowień dotyczących usuwania błędów wynikających z błędów Platformy Sprzętowo-Programowej Izba stwierdza w tym miejscu, że w OPZ w punkcie 5.2.7 Zamawiający przewidział jednoznacznie procedurę odnoszącą się do Awarii spowodowanej działaniem Platformy Sprzętowo - Programowej, z której jednoznacznie wynika, że w przypadku, gdy źródłem błędu jest działanie Platformy Sprzętowo- Programowej, to wykonawca ma obowiązek poinformować Zamawiającego o potencjalnym źródle Błędu, wskazując jedynie, że Błąd wynika z wadliwego działania Platformy Sprzętowo-Programowej.

Zamawiający czynnością z dnia 10 lipca 2024 roku wprowadził do definicji następującą treść Wykonawca nie odpowiada za usunięcie Błędów, których przyczyną jest nieprawidłowe działanie Platformy Sprzętowo-Programowej.

Stwierdzenie Awarii w zakresie całkowitym unieruchomieniem Systemu lub jednego z jego Komponentów lub brakiem dostępu do co najmniej jednego z jego komponentów, gdy źródłem błędu jest działanie Platformy Sprzętowo- Programowej wynika z punktu 5.2.7 OPZ czego Odwołujący w żaden sposób nie kwestionował w zakresie prowadzonej procedury.

Co do pozostałych podnoszonych w odwołaniu argumentów odnoszących się przejawów błędu stanowiącego Awarię tj. do infrastruktury przez odwołanie się np. do awarii macierzy dyskowych, niestabilnej pracy serwerów wizualizacji Izba mając na uwadze powyżej przedstawiona argumentację wyjaśnia ponownie, że poszczególne wskazane „przejawy” błędu jakie podaje przykładowo Zamawiający stanowią zwyczajnie „zewnętrzny znak czegoś” (definicja „przejaw” Słonik PWN), w tym wypadku Awarii, która skutkuje całkowitym unieruchomieniem Systemu lub jednego z jego Komponentów lub brakiem dostępu
‎do co najmniej jednego z jego komponentów.

Mając na uwadze powyższe stwierdzić należy, że doszło do naruszenia podnoszonych przepisów prawa, a tym samym zarzut odwołania Izba uznaje za niezasadny.

W zakresie zarzutu VI A - Zarzut VI: TOM III SWZ – 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 – Izba zarzut uznała za zasadny.

Oraz

W zakresie zarzutu VI B - Zarzut VI: TOM III SWZ – 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 – Izba zarzut uznała za zasadny.

W zakresie rozpoznania zarzutów odwołania

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

- art. 16 ustawy - Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób:

1) zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców;

2) przejrzysty;

3) proporcjonalny.

Izba ustaliła:

TOM III SWZ Opis przedmiotu zamówienia, zwany dalej: OPZ na „Świadczenie usług rozwoju i utrzymania Systemu SZPROT”

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.

Błąd Blokujący

Błąd Poważny

Błąd Średni

Błąd Drobny

Błąd regresji

Błąd dotyczący funkcjonalności działającej poprawnie we wcześniejszych wersjach Platformy Programowej.

Pkt 4.2.6 OPZ

4.2.6. Autoryzacja zmian Systemu wykonanych przez Zamawiającego lub podmioty trzecie

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

Błąd

Stan Systemu mogący skutkować lub skutkujący ograniczeniem bądź brakiem realizacji dowolnej funkcji Systemu. W szczególności Błędem jest działanie Systemu niezgodne z Dokumentacją 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.

Błąd Blokujący

Błąd Poważny

Błąd Średni

Błąd Drobny

Błąd regresji

Błąd dotyczący funkcjonalności działającej poprawnie we wcześniejszych wersjach Platformy Programowej.

Pkt 4.2.6 OPZ

4.2.6. Autoryzacja zmian Systemu wykonanych przez Zamawiającego lub podmioty trzecie

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. Zamawiający zobowiązuje się do wytwarzania zmian zgodnie z postanowieniami dotyczącymi świadczenia Usług Rozwoju na Zgłoszenie i Rozwoju Zdefiniowanego określonymi w OPZ.

7) 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 lub Błędów Poważnych, 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.

Izba zważyła:

Zakres podniesionego przez Odwołujacego zarzutu odwołania związany jest
‎z opisem przedmiotu zamówienia nie dającym możliwości dokonania oszacowania wartości liczby, złożoności stopnia zmian jakie będą wykonywane przez Zamawiającego lub podmiot trzeci, a w konsekwencji niemożliwości przewidzenia ilości nakładów pracy na wprowadzane zmiany.

Mając na uwadze, że istota problemu po zmianach dokonanych w ramach zmian z dnia
‎10 lipca 2024 roku nie uległa bezprzedmiotowości, bowiem nadal Zamawiający zastrzega sobie prawo do realizacji zmian Systemu samodzielnie lub za pomocą podmiotu trzeciego
‎w ramach autoryzacji zmian Systemu. Wydaje się, że kluczowym dla rozpoznania tego zarzutu było odniesienie do wniosku, że Zgłoszone zmiany przez Zamawiającego będą procedowane zgodnie z zasadami opisanymi w OPZ w pkt 4.2 Rozwój na Zgłoszenie. Wykonawca, że w ramach realizacji obowiązków autoryzacyjnych będzie miał możliwość
‎po analizie dokumentacji i kodów źródłowych wstrzymania procesu autoryzacji zmian
‎i zlecenia testów w ramach Zgłoszenia Zmian – Usługi Rozwoju na Zgłoszenie.

W wyniku zmiany OPZ dokonanej w dniu 10 lipca 2024 roku przez Zamawiającego wprowadzona została inna kwalifikacja błędów, wprowadzająca błędy takie jak: 1. Awaria, 2. Błąd Blokujący, 3. Błąd Poważny w ramach których po przeprowadzeniu testów zmian, które nie wykazały wystąpienia Awarii lub, Błędów Blokujących lub Błędów Poważnych wykonawca będzie obowiązany dokonać autoryzacji, a tym samym zmiany staną się elementem Systemu. Jak również elementem Systemu będą zmiany z identyfikowalnym błędem średnim lub drobnym, błędem regresji – które nie zostaną usunięte przez Zamawiającego przed przejęciem takich zmian do Utrzymania przez wykonawcę.

W ramach tego zarzutu Odwołujący podniósł, że nie tylko będzie obowiązany na podstawie przytoczonych wyżej regulacji OPZ, niezależnie od zmiany dokonanej 10 lipca 2024 roku, do analizy przekazanych kodów źródłowych zmiany i dokumentów, obowiązany będzie do dokonywania określonych czynności dotyczących zgłaszania uwag wskazując na konkretne braki lub niezgodności oraz wszelkich innych czynności wynikających z obowiązków określonych OPZ ale również w ramach Usług Utrzymaniowych będzie obowiązany takie nowe elementy Systemu utrzymywać (usługi utrzymaniowe - wynagrodzenie ryczałtowe) jak również przyjąć zmiany z błędami.

W ocenie Izby jednoznacznie Odwołujący wyszczególnił czynności jakie będzie musiał wykonywać w ramach ceny ryczałtowej Usługi Utrzymania Systemu, bowiem w stosunku
‎do tych zmian nie może odmówić realizacji usługi utrzymaniowej. Jednocześnie Zamawiający nie podaje informacji w jakim zakresie w cenie ryczałtowej Usługi Utrzymania Systemu wykonawca miałby skalkulować koszty świadczenia tych „dodatkowych” usług, które pojawią się w ramach realizacji zamówienia.

Podkreślenia wymaga, że Zamawiający wskazał, że Odwołujący realizuje umowy
‎z tożsamymi postanowieniami, natomiast w ocenie Izby nie stanowi to elementu uzasadniającego wprowadzenie do wymagań przedmiotowych realizacji usług, których
‎nie sposób skalkulować na etapie kalkulacji ceny oferty, bowiem nieznany jest ich zakres,
‎a co za tym idzie nakład pracy jaki wykonawca będzie w terminach określonych musiał podjąć.

Z punktu widzenia zamówień publicznych zgodnie z art. 99 ust. 1 ustawy opis przedmiotu zamówienia musi być wyczerpujący, a jeżeli nie jest możliwe wyczerpujące opisanie danego rodzaju świadczonych usług, które mogą a nie muszą pojawić się na etapie realizacji umowy, Zamawiający ma możliwość ujęcia ich w innych postanowieniach umowy czy zastosowania regulacji, które pozwolą na skalkulowanie wartości tych usług. Niedopuszczalna jest sytuacja w zamówieniu publicznym, gdzie Zamawiający wymaga realizacji danego świadczenia ale jednocześnie nie określając jego zakresu nie przewiduje możliwości jego wyceny czy świadczenia w ramach Rozwoju na Zgłoszenie.

W ocenie Izby Zamawiający bagatelizuje kwestię Autoryzacji Zmian Systemu, bowiem wskazuje na nieliczne i nieodnoszące się do znacznej części Systemu zmiany, jak również co do błędów systemu (mniejszej wagi), których Autoryzacja jest wymagana nie widzi przeszkody w obowiązku Autoryzacji zmiany Systemu, a co za tym idzie świadczenia usługi utrzymaniowej.

W odniesieniu do stanowiska zawartego w argumentacji zarzutu VI B Izba podzieliła stanowisko Odwołujacego co do braku określenia przez Zamawiającego informacji na temat tego w jakich technologiach mogą być zgłaszane zmiany w ramach Autoryzacji zmian Systemu. Brak podania takich informacji powoduje, że w ramach każdej zmiany Zamawiający miałby możliwość rozszerzenia zakresu Systemu, przez wprowadzanie
‎do Systemu dowolnych aplikacji, jak również przez wprowadzanie do Systemu aplikacji
‎w technologiach dotychczas niewskazanych w SWZ. Nie ma żadnego postanowienia, które przeczyłoby temu stanowisko Odwołujacego. Natomiast każdy z wykonawców biorących udział w postępowaniu winien mieć taką wiedzę co do zakresu technologii w jakich mogą być wprowadzane zmiany z uwagi choćby na możliwość kalkulowania wartości oferty. Podkreślenia wymaga, że w podnoszonym zarzucie Odwołujący odnosi się do postanowienia z punk 4.2.6 OPZ odnoszącego się do zmian Systemu zgłaszanych przez Zamawiającego samodzielnie lub z pomocą podmiotu trzeciego, a wykonawca nie ma prawa odmowy świadczenia Usługi Utrzymania Systemu w stosunku do takich zmian. Tym samym wydaje się, że zasadnym jest argumentacja Odwołujacego odnosząca się do braku informacji
‎na temat technologicznego zakresu zmian, które będzie inicjował i realizował Zamawiający. Nie wymaga ponad przeciętnej wiedzy, którą w zasadzie można uznać za powszechna
‎w dzisiejszych czasach, że technologiczne zmiany pociągają za sobą określone koszty. Tym samym istotnym jest określenie przez Zamawiającego czy zmiany jakie będzie realizował będą zgodne z zakresem technologii podanych w SWZ czy też planuje rozszerzenie ponad wymagania SWZ, co wymaga podania przez Zamawiającego katalogu technologii przewidzianych w ramach zmian podlegających Autoryzacji zmian Systemu. Brak określenia tych elementów w OPZ powoduje, że opis przedmiotu zamówienia nie spełnia wymagania z art. 99 ust. 1 ustawy bowiem nie jest wyczerpujący i jednoznaczny. Więcej, stanowisko Zamawiającego z pisma procesowego potwierdza brak konkretyzacji w opisie i pozostawia dobór technologii na etapie realizacji umowy. Przy czym Izba podkreśla, że inicjowanie zmian podlegających Autoryzacji zmian Systemu jest zastrzeżonym prawem
‎dla Zamawiającego, a Zamawiający w piśmie jednoznacznie dopuszcza możliwość zmian technologii, czego w żaden sposób nie określa na poziomie OPZ. Zamawiający tłumaczy wszelkie zarzuty profesjonalizmem i doświadczeniem podmiotów, które mają kompetencje
‎w budowaniu i rozwijaniu systemów informatycznych z wykorzystaniem różnych technologii. Choć niewątpliwe podmioty zainteresowane zamówieniem są podmiotami o profesjonalnym, o ogromnym doświadczeniu i umiejętnościach – czego wyrazem może być grono podmiotów biorących udział w tym postępowaniu odwoławczym – to niewątpliwie żaden z nich nie jest
‎w stanie na etapie składania oferty przewidzieć jakie technologie może stosować
‎w zgłaszaniu zmian Zamawiający poza tymi, jakie wynikają z OPZ. Nie są w tym sanie rzeczy podmioty te przewidzieć tych okoliczności, nie są w stanie skalkulować ceny oferty
‎w sposób porównywalny bowiem na ten moment nie posiadają wyczerpującej
‎i jednoznacznej wiedzy na temat przedmiotu zamówienia, co potwierdził sam Zamawiający.

Mając na uwadze powyższe (w zakresie zarzutu VI A i VI B) w zakresie OPZ
‎w zakresie regulacji odnoszącej się do Autoryzacji Zmian Systemu w odniesieniu do braku możliwości skalkulowania kosztów tej usługi Izba uznała za zasadne nakazanie Zamawiającemu wykreślenie postanowienia z punktu 4.2.6. OPZ w całości, w brzmieniu jakie podlegało zaskarżeniu w zarzutach odwołania. Izba mając na uwadze istotne Systemu SZPROT oraz jego znaczenie nie nakazała Zamawiającemu wprowadzenia konkretnego postanowienia do OPZ np. przez odniesienie do świadczenia tych usług w ramach Rozwoju na Zgłoszenie, jak wnioskował Odwołujący, bowiem Zamawiający może w ramach swoich doświadczeń i znajomości przedmiotu zamówienia podać inny sposób, który pozwoli
‎na realne skalkulowanie ceny oferty, zminimalizowanie ryzyk, (które mogą również obciążać Zamawiającego) w zakresie sposobu kalkulowania ceny Autoryzacji Zamiany Systemu, albo może zrezygnować z realizacji tej usługi. Jednocześnie Izba stwierdza, że nakazała wykreślenie pkt 4.2.6 OPZ w związku z tym, że Zamawiający w ramach Autoryzacji Zmian Systemu wymagał dokonania tej Autoryzacji w ramach błędów „mniejszych” o wskazanych wagach oraz ich obsługi w ramach Usług Utrzymaniowych. Tak opisana Autoryzacja zmian Systemu w żaden sposób nie określa ilościowych i jakościowych zmian odnoszących się do złożoności zmiany czy technologii realizowanej przez Zamawiającego zmiany;
‎w konsekwencji nie zawiera żadnej możliwości zwiększenia wynagrodzenia ryczałtowego wykonawcy za świadczenie Usług Utrzymania w związku z prawdopodobnym zwiększeniem zakresu świadczenia tej usługi z uwagi na zmiany wprowadzane przez Zamawiającego, jak również brak wynagrodzenia za realizowane zadania w zakresie procedury autoryzacji. Jednocześnie Izba wyjaśnia, że nie nakazała wprowadzenia konkretnej zmiany jednocześnie zakreślając, że w ramach Autoryzacji Zamian Systemu musi istnieć możliwość skalkulowania kosztów przez wykonawcę w cenie oferty, z uwagi na koszty utrzymania i rozwoju Systemu jaki ponosi Zamawiający. To Zamawiający musi określić czy środki finansowe jakimi dysponuje pozwolą mu na konkretne zmiany w zakresie OPZ, czy też np. zrezygnuje z usługi Autoryzacji. Podkreślenia wymaga w tym miejscu, że na dzień składania ofert ilość Autoryzacji jest nieznana i niemożliwa do oszacowania kosztów jej realizacji, jak również nieznany jest zakres technologii wykorzystanych przy autoryzacjach realizowanych przez Zamawiające. Podkreślenia wymaga również, że o ile Zamawiający zdecyduje
‎o wprowadzeniu nowego brzmienia tych postanowień, podlegać mogą one ocenie w ramach środków ochrony prawnej.

W ocenie Izby postanowienia OPZ w kwestionowanym zakresie naruszają przepis art. 99 ust. 1 ustawy w związku brakiem wyczerpującego opisania przedmiotu zamówienia
‎nie dającego wykonawcy podstawy do faktycznego skalkulowania kosztów usługi. Takie niezdefiniowane w całości co do wymagania przedmiotowych opisy przez Zamawiającego prowadzą do nierównej konkurencyjności pomiędzy wykonawcami.

Mając na uwadze powyższe Izba nakazała Zamawiającemu wykreślenie punktu 4.2.6 OPZ w całości w związku tym, że brzmienie jakie przyjął nie jest wyczerpujące.

W zakresie zarzutu VIII - Zarzut VIII: TOM III SWZ – 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; – Izba zarzut uznała za niezasadny.

W zakresie rozpoznania zarzutów odwołania

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

- art. 16 ustawy - Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób:

1) zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców;

2) przejrzysty;

3) proporcjonalny.

Izba ustaliła:

TOM III SWZ Opis przedmiotu zamówienia, zwany dalej: OPZ na „Świadczenie usług rozwoju i utrzymania Systemu SZPROT”

5.2.4.

Obsługa Zgłoszeń serwisowych dotyczących środowiska produkcyjnego i testowego polegać będzie na:

4) 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;

4) 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 dowolną ilość razy, przy czym każde kolejne wystąpienie o uzupełnienie/ sprecyzowanie Zgłoszenia nie skutkuje zawieszeniem biegu terminów,
‎o których mowa w ppkt 5);

Izba zważyła:

W zakresie zarzutu odwołania odnoszącego się do jednokrotnego wystąpienia
‎o uzupełnienie / sprecyzowanie Zgłoszenia serwisowego Izba wskazuje, że w tym zakresie zarzut stał się bezprzedmiotowy z uwagi na wprowadzenie w dniu 10 lipca 2024 roku zmiany zezwalającej na wielokrotność wystąpień o uzupełnienie / sprecyzowanie zgłoszenia.

Jednakże zarzut w części odnoszącej się do zawieszenia biegu terminów określonych
‎w punkcie 5.2.4. podpunkt 5 OPZ pozostał aktualny, w tym zakresie zostaje poddany rozpoznaniu.

W powiazaniu zarzutu odwołania oraz wniosków jakie przedstawił Odwołujący Izba stwierdza, że Odwołujący oczekuje uprawnienia do nieskończonej ilości wystąpień
‎o uzupełnienie / sprecyzowanie Zgłoszenia serwisowego, w zasadzie niczym nieobwarowanej, bowiem w każdym przypadku skutkującej zawieszeniem biegu terminów wyżej wskazanych. Istotnym jest w przypadku rozpoznania tego zarzutu, że w propozycji zmiany postanowień OPZ ogólnie, w sposób bardzo szeroki określa podstawę
‎do wystąpienia z zawieszeniem biegu terminów „wszystkich informacji niezbędnych
‎do usunięcia Błędu”. Wskazanie to jest bardzo niedookreślone oraz niejednoznaczne, przy czym wskazuje na mechanizm zmiany jakiego oczekuje Odwołujący. Istotnym jest również to, że podnosząc w argumentacji brak określenia przez Zamawiającego wymagań
‎co do jakości zgłoszeń, nie zmierza do ich określenia w dokumentacji lecz tym argumentem uzasadnia konieczność dopuszczenia wielokrotności wystąpień o uzupełnienie
‎/ sprecyzowanie Zgłoszenia serwisowego skutkujących zawieszeniem biegu terminów wyżej wskazanych. Odwołujący nie odnosił się również do w swoim stanowisku zawartym
‎w odwołaniu do braku deklaracji czasu odpowiedzi na zgłoszenia potrzeby uzupełnienia / sprecyzowania Zgłoszenia.

W ocenie Izby Odwołujący nie wykazał zasadności wprowadzenia regulacji, która skutkowałaby w każdym przypadku wystąpienia o uzupełnienie / sprecyzowanie Zgłoszenia serwisowego koniecznością zawieszenia biegu terminów określonych w punkcie 5.2.4. podpunkt 5 OPZ. Słusznie podniósł Zamawiający, że wprowadzają regulację odnoszącą się do każdorazowego zawieszenia biegu terminu niweczyłoby to zasadność wprowadzenia przez Zamawiającego czasu usunięcia Błędów, bowiem wykonawca miałby nieograniczoną ilościowo i czasowo możliwość zgłaszania uwag do każdego zgłoszenia serwisowego,
‎co prowadziłoby do wypaczenia celu jakim jest działanie Systemu SZPROT w sposób minimalizujący wystąpienia Błędów usuwanych na bieżąco przez wykonawcę.

Mając na uwadze powyższe w ocenie Izby w żaden sposób nie zostały wykazane naruszenie regulacji art. 99 ust. 1 ustawy w zw. z art. 16 ustawy.

W zakresie zarzutu XI - 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;– Izba zarzut uznała za zasadny.

W zakresie rozpoznania zarzutów odwołania

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

- art. 16 ustawy - Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób:

1) zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców;

2) przejrzysty;

3) proporcjonalny.

Izba ustaliła:

TOM III SWZ Opis przedmiotu zamówienia, zwany dalej: OPZ na „Świadczenie usług rozwoju i utrzymania Systemu SZPROT”

5.3.3. Wykonawca będzie zobowiązany do udzielania konsultacji dotyczących Systemu,
‎w szczególności w następującym zakresie:

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

7) eksploatacji Systemu,

8) administrowania komponentami technicznymi Systemu,

9) baz danych i serwerów aplikacji,

10) współpracy Platformy Sprzętowo-Programowej z Systemem.

5.3.3. Wykonawca będzie zobowiązany do udzielania konsultacji dotyczących Systemu, w szczególności w następującym zakresie:

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 zdalna dyspozycyjność konsultanta w trakcie trwania szkolenia, w celu omówienia przypadków zgłaszanych przez Uczestników lub prowadzącego szkolenie – nie częściej niż 6 razy przez każde 12 miesięcy realizacji zamówienia,

7) eksploatacji Systemu,

8) administrowania komponentami technicznymi Systemu,

9) baz danych i serwerów aplikacji,

10) współpracy Platformy Sprzętowo-Programowej z Systemem,

11) odtwarzania przez Zamawiającego uszkodzonego Systemu do czasu przywrócenia pełnej funkcjonalności Systemu.

Izba zważyła:

Zarzut odwołania, zgodnie z argumentacją zwarta w uzasadnieniu zarzutu odnosił się do treści postanowień zawartych w podpunkcie 6 i 8 punkt 5.3.3 OPZ oraz odnosił się do wskazania przed wyliczeniem zakresów „w szczególności”.

W odniesieniu do argumentacji dotyczącej wskazania „w szczególności” Izba stwierdza, że nie sposób zgodzić się ze stanowiskiem Odwołujacego w odniesieniu
‎do pozostawienia otwartego zakresu prac. Izba podziela stanowisko Zamawiającego, zgodnie z którym w punkcie 5.3.3 OPZ jednoznacznie zostało podane, że Konsultacje dotyczyć będą Systemu. Słusznie podaje Zamawiający, że dowodzi to tego, że zakres Konsultacji ma charakter skończony, bowiem odnoszący się do Systemu. Zakres Konsultacji jaki został zakreślony w tym miejscu nie jest skończonym zakresem, a jedynie przykładowo wymienia obszary w jakich będzie obowiązany do udzielania Konsultacji.

Izba podziela jednakże stanowisko Odwołującego w zakresie konieczności ustalenia limitu godzinowego Konsultacji w miesiącu, przez okres trwania umowy. Wykonawca na etapie składania oferty musi skalkulować wartość Konsultacji, zakres przedmiotowy odnoszący się do udzielania Konsultacji w zakresie Systemu to jeden element opisu, który jest niezbędny do kalkulacji ceny za tą usługę. Jednocześnie Konsultacje w sposób jaki zostały opisane
‎w OPZ stanowią nieskończonych czasowo element przedmiotu zamówienia. Nie sposób ustalić na podstawie informacji zawartych w OPZ jakie nakłady osobowe musi przewidzieć wykonawca do realizacji usługi, a tym samym jakie koszty skalkulować w skali całego okresu realizacji zamówienia. Brak określenia pełnych danych co do zakresu świadczenia usługi Konsultacji stanowi naruszenie art. 99 ust. 1 ustawy, bowiem opis przedmiotu zamówienia ma być jednoznaczny i wyczerpujący. Tym samym prowadzi to do naruszenia zasad określonych ustawą.

W zakresie wsparcia Zamawiającego w szkoleniu użytkowników (pkt 6) w części zarzut stał się bezprzedmiotowy z uwagi na zmianę z dnia 10 lipca 2024 roku. Co do ilości, częstotliwości szkoleń Zmawiający określił ilość szkoleń w ciągu 12 miesięcy przez cały okres trwania zamówienia, oraz w odniesieniu do udziału zdalnego w tym zakresie zarzut jest bezprzedmiotowy. W części podlegającej rozpoznaniu Izba stwierdza, że zakres szkoleń definiowany jest przedmiotem zamówienia i odnosi się do Konsultacji dotyczących Sytemu
‎w zakresie omówienia przypadków zgłaszanych przez Uczestników lub prowadzącego szkolenie.

W odniesieniu do administrowania komponentami technicznymi Systemu (pkt 8) Izba stwierdza w tym miejscu, że podziela stanowisko Zamawiającego odnośnie posiadania wiedzy na temat komponentów technicznych Systemu i Platformy Sprzętowo – Programowej aby móc prawidłowo świadczyć Usługi Utrzymania także w zakresie zamawianych Konsultacji. Istotnym jest również w ocenie Izby, że stanowisko to nie było kwestionowane
‎w piśmie procesowym Odwołujacego.

Izba mając na uwadze powyższe uwzględniła zarzut odwołania i nakazała Zamawiającemu uzupełnienie w punkcie 5.3.3 OPZ przez podanie godzinowego limitu udzielanych Konsultacji w miesiącu.

W zakresie zarzutu XIII - 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 – Izba zarzut uznała za niezasadny.

W zakresie rozpoznania zarzutów odwołania

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

- art. 16 ustawy - Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób:

1) zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców;

2) przejrzysty;

3) proporcjonalny.

Izba ustaliła:

TOM III SWZ Opis przedmiotu zamówienia, zwany dalej: OPZ na „Świadczenie usług rozwoju i utrzymania Systemu SZPROT”

5.4.1. W ramach konserwacji Systemu Wykonawca zobowiązany będzie do:

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,

5.4.4. W przypadku czynności konserwacji Systemu, o których mowa w pkt. 5.4.1, ppkt. 3-4 oraz 6-9, które skutkują zmianą kodu źródłowego, Zamawiający wymaga dostarczenia przez Wykonawcę Nowej wersji Systemu, a jej odbiór następuje zgodnie z Załącznikiem nr 5 do OPZ.

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.

Załącznik nr 3 do OPZ - Architektura techniczna Systemu

8.Wymagania dotyczące licencji oprogramowania COTS wchodzącego w skład Platformy Programowej

Wykonawca w ramach realizacji przedmiotu Umowy, w zakresie dostarczonego oprogramowania zapewni minimum 4-letnie wsparcie w zakresie:

wsparcia producenta oprogramowania (zgłaszanie problemów poprzez stronę internetową, e-mail, telefon i ich realizację w określonym czasie, w zależności od priorytetu zgłoszenia);

możliwości pobierania wersji podwyższonych, wydań uzupełniających, poprawek programistycznych, korzystania z oprogramowania będącego kontynuacją linii produktowej (również dystrybuowaną pod inną nazwą handlową) dostarczanego oprogramowania;

zagwarantowania dostępu do zasobu internetowego dostarczanego oprogramowania w celu pobrania aktualizacji;

zapewnienia elektronicznego dostępu do informacji na temat posiadanego oprogramowania, wykaz znanych symptomów i rozwiązań (w tym programy korygujące do oprogramowania), biuletynów technicznych, dokumentacji technicznych poprawek programistycznych oraz bazy danych zgłoszonych problemów technicznych przez 24 godziny na dobę, 7 dni w tygodniu.

Izba zważyła:

Podkreślenia wymaga, na co wskazywał Zamawiający w odpowiedzi na odwołanie,
‎że System SZPROT, zgodnie ze stanem bieżącym, nie wykorzystuje żadnego odpłatnego Oprogramowania gotowego (COTS, FOSS, FLOSS), które wymagałoby wykupienia wersji podwyższonych. Na etapie składnia oferty nie ma więc podstaw do uwzględnienia kosztów związanych z zapewnieniem w 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.

W zakresie rozpoznania zarzutu odwołanie niezbędne jest uszczegółowienie
‎oraz wyjaśnienie, czego kwestionuje w żaden sposób Odwołujący, nie ma w zarzucie odwołania, że regulacja odnosząca się do informowania Zamawiającego o nowych wersjach oprogramowania wskazanego w punkcie 5.4.1.3) OZP odnosi się zgodnie z załączniki 3
‎do OPZ - Architektura techniczna Systemu do oprogramowania dostarczonego przez wykonawcę. Co istotne te postanowienia nie były kwestionowane przez Odwołujacego.

Stanowisko Odwołujacego z uzasadnienia odwołanie nie zasługuje na uwzględnienie, bowiem w pierwszej kolejności podnosząc argument o tym kto ma dostarczyć nowe wersje oprogramowania gotowego oraz kto ma wykonać modyfikację Systemu do owego oprogramowania gotowego Odwołujący pominął fakt, że System SZPROT, zgodnie
‎ze stanem bieżącym, nie wykorzystuje żadnego odpłatnego Oprogramowania gotowego (COTS, FOSS, FLOSS). Natomiast Zamawiający przewidziała możliwość wykorzystania Oprogramowania gotowego przez wykonawcę, niemniej to po stronie wykonawcy realizującego kompleksowo przedmiotowe zamówienie pozostaje decyzja co do wykorzystania w trakcie jego realizacji Oprogramowania gotowego, a tym samym ewentualnego skalkulowania kosztów. W odniesieniu do kwestii modyfikacji Systemu (dostosowania) do nowego Oprogramowania gotowego nie stanowi w ocenie Izby uzasadnionego zarzutu, bowiem skoro na stan bieżący System SZPROT nie wykorzystuje żadnego odpłatnego Oprogramowania gotowego (COTS, FOSS, FLOSS) to jedynie jego dostosowanie będzie konieczne w przypadku, gdy to wykonawca realizujący zamówienie podejmie decyzję o wykorzystaniu Oprogramowania gotowego w realizacji zamówienia.

Odwołanie się w piśmie procesowym przez Odwołujacego do kwestii Autoryzacji zmian Systemu stanowi w ocenie Izby okoliczność nową, nie podnoszoną w odwołaniu, tym samym Izba uznaje to stanowisko Odwołujacego za spóźnione. Przy czym jednoznacznie należy podkreślić, że w swoim stanowisku Zamawiający wyjaśnił, że wykonawca na etapie wyceny Zgłoszenia Zmiany, oceni zasadność wykorzystania Oprogramowania gotowego do realizacji

danej Zmiany i koszty tej aktualizacji uwzględni w tym zleceniu.

Mając na uwadze powyższe Izba nie stwierdziła zasadności podnoszonego zarzutu
‎i naruszenia art. 99 ust. 1 i 4 ustawy w zw. z art. 16 ustawy.

W zakresie zarzutu XV - 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 – Izba zarzut uznała za zasadny.

W zakresie rozpoznania zarzutów odwołania

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

- art. 16 ustawy - Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób:

1) zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców;

2) przejrzysty;

3) proporcjonalny.

Izba ustaliła:

TOM III SWZ Opis przedmiotu zamówienia, zwany dalej: OPZ na „Świadczenie usług rozwoju i utrzymania Systemu SZPROT”

5.4.1. W ramach konserwacji Systemu Wykonawca zobowiązany będzie do:

(…)

7) przeniesienia Systemu na nowe bloki architektoniczne w związku ze zmianą Platformy Sprzętowo-Programowej i uruchomienie na nowych blokach, nie częściej niż raz na 2 lata

Izba zważyła:

Dla rozpoznania tego zarzutu odwołania kluczowe znaczenie ma stanowisko Zamawiającego wyrażone w Odpowiedzi na odwołanie, gdzie podał, że nie ma możliwości doprecyzowania zmian zastosowanych w nowych blokach architektonicznych, w stosunku
‎do obecnych. Postanowienia OPZ w kształcie jaki obecnie mają nie spełniają wymagań określonych w art. 99 ust. 1 ustawy, bowiem opisanie przedmiotu zamówienia ma być jednoznaczne i wyczerpujące. Brak sprecyzowania, w związku z przeniesieniem Systemu
‎na nowe bloki architektoniczne, zmian zastosowanych w nowych blokach architektonicznych w stosunku od obecnych lub zapewnienie, że nowe bloki nie wprowadzą zmian prowadzi
‎do wniosku braku opisu przedmiotu w sposób wyczerpujący oraz braku możliwości skalkulowania kosztów przez wykonawcę. Natomiast sam Zamawiający wyjaśniał, że zmiana bloków architektonicznych co do zasady generować będzie konieczność przeniesienia Systemu na nowe bloki i konieczność dostosowania Platformy Programowej do działania
‎na nowych blokach. W ocenie Izby zasadnie wskazał Odwołujący na możliwość konieczności wymiany lub aktualizacji Oprogramowania gotowego, przy czym Izba podkreśla,
‎że możliwość te w tym wypadku należy odnosić do oprogramowania dostarczonego przez wykonawcę, oraz nie odnosić jedynie do oprogramowania COTS. Słusznie zwrócił uwagę Odwołujący, że w takim stanie rzeczy Zamawiający oczekuje usługi i skalkulowania oferty
‎o nieokreślonym zakresie. Nie sposób zgodzić się z argumentacją Zamawiającego
‎z rozprawy odnoszącą się do przewidywania zmian Platformy Sprzętowo – Programowej
‎i w oparciu o pozyskiwanie informacji ze stron internetowych i przewidywanie kierunku zmian.

Mając na uwadze powyższe Izba uznała zasadność podnoszonych naruszeń
‎i nakazała wykreślenie punktu 5.4.1. ppkt 7 OPZ w związku tym, że brzmienie jakie przyjął nie jest wyczerpujące oraz nakazuje wprowadzenie całego zadania w ramach Usług Rozwoju na Zgłoszenie.

W zakresie zarzutu XVII - Zarzut: XVII: TOM III SWZ – OPZ – Załącznik nr 2
‎do OPZ Rozwój Zdefiniowany oraz TOM I SWZ – 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 – Izba zarzut uznała za zasadny.

W zakresie rozpoznania zarzutów odwołania

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

- art. 436 pkt 1 ustawy - Umowa zawiera postanowienia określające w szczególności:

1) planowany termin zakończenia usługi, dostawy lub robót budowlanych, oraz, w razie potrzeby, planowane terminy wykonania poszczególnych części usługi, dostawy lub roboty budowlanej, określone w dniach, tygodniach, miesiącach lub latach, chyba że wskazanie daty wykonania umowy jest uzasadnione obiektywną przyczyną;

Izba ustaliła:

Formularz cenowy Załącznika nr 2 do OPZ (Formularz 2.2.) - Rozwój Zdefiniowany,
‎w kolumnie „Data dostarczenia zadania” Zamawiający podał dla poszczególnych 127 Zadań daty dzień w systemie dzień/miesiąc/rok.

Załącznik nr 2 do OPZ Opis wymagań w zakresie Rozwoju Zdefiniowanego, dla każdego z Zadamawiający podał datę dostarczenia zadania.

TOM II SWZ - PROJEKTOWANE POSTANOWIENIA UMOWY (dalej: PPU)

§ 2 Termin realizacji

1. Wykonawca będzie realizował przedmiot Umowy w zakresie, o którym mowa w § 1 Umowy:

1) ust. 1 pkt 1 lit. a) tiret i. przez okres 36 miesięcy od dnia zawarcia Umowy, zgodnie z Harmonogramem zatwierdzonym przez Zamawiającego;

2) ust. 1 pkt 1 lit. a) tiret ii. przez okres 48 miesięcy od dnia zawarcia Umowy albo
‎do wyczerpania liczby osobodni wskazanej w § 1 ust. 1 pkt 1 lit. a) tiret ii., w zależności które zdarzenie nastąpi wcześniej;

3) ust. 1 pkt 1 lit. b) przez okres 48 miesięcy od dnia Przejęcia Systemu;

4) ust. 1 pkt 2 lit. a) od upływu okresu realizacji albo wyczerpania puli osobodni w zakresie zamówienia podstawowego w ramach Rozwoju na Zgłoszenie, nie dłużej jednak niż
‎do zakończenia świadczenia Usługi Utrzymania Systemu z tytułu zamówienia podstawowego albo prawa opcji (o ile została uruchomiona);

5) ust. 1 pkt 2 lit. b) przez okres 24 miesięcy od zakończenia realizacji zamówienia podstawowego.

Izba zważyła:

W zakresie przedmiotowego zarzutu odwołania kluczowym problemem jest rozstrzygnięcie w zakresie określenia w Formularzu cenowy Załącznika nr 2 do OPZ - Rozwój Zdefiniowany oraz w Załącznik nr 2 do OPZ Opis wymagań w zakresie Rozwoju Zdefiniowanego dat dostarczenia zadania jako dat dziennych w systemie dzień/miesiąc/rok.

Zgodnie z uzasadnieniem do projektowanych postanowień ustawy podano: "W art. 436 nowej ustawy wskazuje się postanowienia, które obligatoryjnie powinna zawierać każda umowa, takie jak kwestie terminu jej wykonania oraz warunków płatności czy limitowanie kar umownych. Nowym rozwiązaniem jest wyraźne zobligowanie zamawiających do określenia terminu wykonania umowy, w jednostkach czasu (dniach, tygodniach, latach), chyba
‎że wskazanie daty wykonania umowy jest uzasadnione obiektywną przyczyną, niezależną
‎od zamawiającego np. w przypadku projektów finansowanych ze środków UE.”

„Regulacja ma na celu zapewnienie, by wszyscy wykonawcy mieli jednakową wiedzę
‎o czasie wymaganym do realizacji zamówienia. Ma to zapobiec sytuacji, gdy każdy wykonawca odrębnie, na podstawie własnego doświadczenia i wiedzy, estymował najpierw spodziewany termin zawarcia umowy (mimo że nie miał wpływu na tę datę), a następnie próbował wyliczać pozostały mu czas na realizację zamówienia. Powyższe zmuszało wykonawców do uwzględniania związanych z tym ryzyk kontraktowych i kosztów.” (tak: red. H. Nowak, M. Winiarz „Prawo zamówień publicznych. Komentarz.” Wydanie I).

Przepis art. 436 ust. 1 zawiera postanowienia obligatoryjne jakie musi zawierać umowa
‎o zamówienie publiczne niezależnie od przedmiotu tej umowy, jej wartości czy też trybu
‎w jakim została zawarta.

W ramach obligatoryjnych postanowień ustawodawca wprowadził obowiązek w zakresie planowanego terminu zakończenia usługi, dostawy lub robót budowlanych, oraz, w razie potrzeby, planowanych terminów wykonania poszczególnych części usługi, dostawy
‎lub roboty budowlanej muszą zostać określone w dniach, tygodniach, miesiącach lub latach. Jest to zasad podstawowa wynikająca z tego przepisu. Na podstawie powyższego jednoznacznie należy stwierdzić, że nie tylko planowany termin zakończenia zamówienia musi zostać określony w powyższej formule, lecz również planowane terminy wykonania poszczególnych części. „Powyższe rozwiązanie służy zrównoważeniu stron kontraktu, stanowi wyraz bardziej partnerskiego traktowania wykonawców przez podmioty publiczne oraz stwarza wspólne podstawy dla każdego wykonawcy do oszacowania ryzyk związanych z terminem realizacji.”

Ustawodawca przewidział wyjątek od powyższej zasady podnosząc, że dopuszcza odstępstwo od ustalania terminów przez określone w dniach, tygodniach, miesiącach lub latach w okolicznościach, że wskazanie daty wykonania umowy jest uzasadnione obiektywną przyczyną. Mając powyższe na uwadze, jak również uwzględniając art. 20 ust. 1 ustawy odnoszący się do pisemności postępowania, niezbędnym jest wyartykułowanie przez Zamawiającego w dokumentach zamówienia okoliczności stanowiących uzasadnioną obiektywną przyczynę wskazania daty wykonania umowy. W rozpoznawanej sprawie Zamawiający nie podał w dokumentach zamówienia oraz ogłoszeniu o zamówienie żadnego uzasadnienia przedstawiającego obiektywne przyczyny lezące u podstaw jego działania. Izba podkreśla również, że żadnej argumentacji uzasadniającej istnienie obiektywnej przyczyny Zamawiający nie zawarł również w swoim stanowisku pisemnym. Odwołanie się do obowiązków wynikających z przepisów prawa – bez jakiejkolwiek argumentacji faktycznej uzasadniającej to stwierdzenie, oraz odwołanie się do obowiązku zapewnienia integracji Systemu z systemami zewnętrznymi – bez jakiegokolwiek uzasadnienia merytorycznego tego powierzchownego stwierdzenia, jak również odwołanie się do korzystania z dużej ilości użytkowników wewnętrznych, których musi przeszkolić, oraz odwołanie się do korzystania
‎z Systemu przez przedsiębiorców i umożliwienie im zapoznania się ze zmianami w Systemie – w żaden sposób nie stanowią obiektywnej przyczyny wskazania dat wykonania umowy
‎i tym samym odstąpienia od zasady określania terminów w dniach, tygodniach, miesiącach
‎i latach. Gdyby przyjąć stanowisko Zamawiającego za słuszne i uzasadniające odstępnie
‎od ustawowej zasady, należałoby stwierdzić, że wystarczającym są do takiego uzasadnienia przedmiotowe podstawy prowadzenia zamówienia, bowiem jak nie czym innym
‎są argumenty Zamawiającego, jak elementem przedmiotu zamówienia i częścią obowiązków Zamawiającego. W przytoczonym na wstępie uzasadnieniu do projektu ustawy wskazano jako przykład odstąpienia od zasady z art. 436 pkt 1 ustawy, jako uzasadnioną obiektywną przyczynę, niezależną od zamawiającego przypadek projektów finansowanych ze środków UE. Tym samym w przypadkach, gdy Zamawiający odstępuje od wymagania ustawowego
‎z art. 436 ust. 1 ustawy i wykorzystuje wyjątek musi określić uzasadniającą to obiektywną przyczynę oraz musi podać informację w tym zakresie. Jest to stanowisko ugruntowane
‎w orzecznictwie, a jednocześnie sprzyja realizacji zasad zamówień publicznych,
‎w szczególności zasady konkurencyjności wykonawców ale także przejrzystości prowadzonego postępowania o udzielnie zamówienia. Na szczególną uwagę zasługuje również realizacja zasady efektywności odnosząca się w tym wypadku zarówno
‎do obowiązków informacyjnych jak również bezpieczeństwa prowadzenia postępowania
‎o zamówienie. Podkreślenia wymaga, że na zasadność określenia terminów wykonania zamówienia w dniach, miesiącach, latach wskazywano w doktrynie przedmiotu jeszcze przed wejściem w życie obowiązującej obecnie ustawy (tak np. R. Szostak „Umowy o zamówienie publiczne w zarysie”).

Zasadnym jest również wskazanie w tym miejscu, że przepis ustawy w zakresie określonego przepisem uzasadnionego wyjątku odnosi się do „daty wykonania umowy”. Mając na uwadze treść całości tego przepisu, gdzie ustawodawca posłużył się określeniem „poszczególnych części”, którego nie przenosi w warunki wyjątku podając np. „daty wykonania umowy lub poszczególnych części”.

Mając powyższe na uwadze Izba uznała zarzut odwołania za zasadny, bowiem doszło do naruszenia art. 436 pkt 1 ustawy oraz nakazała 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.

Izba przytacza w tym miejscu rozpoznanie zarzutu odwołania sygn. akt KIO 2125/24
‎w zakresie zarzutu 4 gdzie nakazała 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 zakresie zarzutu XIX - Zarzut XIX: TOM III SWZ – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 6 (SZPROT_WFOG_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 – Izba zarzut uznała za niezasadny.

W zakresie rozpoznania zarzutów odwołania

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

- art. 16 ustawy - Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób:

1) zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców;

2) przejrzysty;

3) proporcjonalny.

Izba ustaliła:

Załącznik nr 2 do OPZ Opis wymagań w zakresie Rozwoju Zdefiniowanego

6.2 Opis zadania

Celem wymagania jest zapewnienie w Systemie SZPROT kompletu danych (poprzez rozbudowę bazy operacyjnej SZPROT) potrzebnych do zasilania Komponentów Komunikacyjnych SZPROT na PUESC oraz zapewnienie spójności danych.

System SZPROT wykorzystuje usługi webservice SOAP do przekazywania danych do PDR PL/UE. Niektóre słowniki PDR PL/UE replikowane są do Systemu SZPROT z wykorzystaniem mechanizmu subskrypcji udostępnianego przez API System PDR PL/UE.

Docelowo korzystanie z bazy danych SZPROT zastąpi korzystanie ze słowników PDR PL/UE. Wszędzie w zadaniach w załączniku nr 2 gdzie występuje odwołanie do pobierania danych ze słowników PDR PL/UE należy rozumieć po tej zmianie jako odwołanie do nowej bazy Systemu SZPROT.

Izba zważyła:

W zakresie zarzutu odwołania Izba podkreśla ogólnikowość argumentacji Odwołujacego. W zakresie stanowiska Odwołujacego brak jest uzasadnienia
‎dla wskazanego wniosku oraz stwierdzenia dotyczącego konieczności podania szczegółowo wymagań technicznych dotyczących sposobu realizacji zmiany architektonicznej. Warto nadmienić w tym miejscu, że Odwołujący nie podał w uzasadnieniu zarzutu odwołania brakujących danych w opisie Zadania niezbędnych do wyceny Zadania. Podnoszenie argumentacji przez Odwołujacego na późniejszym etapie, po upływie terminu na wniesienie odwołania należy uznać za spóźnione przedstawianie uzasadnienia zarzutu odwołania. Przedstawione pismo procesowe dowodzi tego, że Odwołujący miał możliwość przedstawienia szerszej argumentacji w czasie do tego przewidzianym.

Izba podziela stanowisko prezentowane przez Zamawiającego, który wyjaśnił, że w ramach Zadania wskazał cel biznesowy i założenia architektoniczne dla tego Zadania oraz pozostawił potencjalnym wykonawcom swobodę wyboru, za pomocą jakiego rozwiązania opisane w Załączniku nr 2 do OZP wymagania funkcjonalne, zostaną osiągnięte. Zamawiający również wyjaśnił, że przyjmując taki sposób opisu Zadania, miał na celu zapewnienie jak najszerszej konkurencji oraz niedyskryminowanie żadnego z rozwiązań dostępnych na rynku. Zadanie to stanowi bardzo złożony, wieloetapowy proces zmiany architektury Systemu, polegający na odwróceniu zależności integracji pomiędzy Systemem, a dwoma innymi (PDR PL/U, CRKiD w SEAP) kluczowymi systemami Zamawiającego, jak również ma na celu zapewnienie mechanizmów zachowania i przywracania spójności pomiędzy wskazanymi systemami. Zamawiający zwrócił uwagę, że Wykonawca ma dostęp do Dokumentacji Systemu (w ramach zapoznania się z dokumentacją i kodami źródłowymi) oraz opisu Systemu zawartego w Załączniku nr 1 do OPZ, co pozwala na oszacowanie kosztów realizacji tego Zadania.

Mając na uwadze powyższe Izba uznała zarzut za niezasadny.

W zakresie zarzutu XX - Zarzut XX: TOM III SWZ – 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_WFED_3, SZPROT_WFOG_12 , SZPROT_WFOG_44 (zał. 2 do OPZ odpowiednio punkty: 48, 14, 123); – Izba zarzut uznała za zasadny.

W zakresie rozpoznania zarzutów odwołania

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

- art. 16 ustawy - Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób:

1) zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców;

2) przejrzysty;

3) proporcjonalny.

Izba ustaliła:

Załącznik nr 2 do OPZ Opis wymagań w zakresie Rozwoju Zdefiniowanego

9.2 Opis zadania

Celem modyfikacji jest dostosowanie formularzy wniosków o wydanie decyzji, pozwolenia, , do wymagań wynikających z:

przepisów unijnych lub krajowych,

zmian w modelu danych w innych systemach, np. EOS, , PDR PL/UE,

potrzeb Zamawiającego.

Modyfikacji wymaga także obsługa (proces) tych wniosków w postępowaniu w Systemie SZPROT. Ponadto modyfikacji wymaga także zakres danych i ich format w rejestrach pozwoleń.

Modyfikacji wymagają szablony wydawanych pozwoleń, decyzji (także tych wydawanych „z urzędu”). Dane rozstrzygnięcia są przekazywane do innych systemów wewnętrznych SISC i zewnętrznych (poza systemami SISC).

(…)

Pełny zakres zmian w Komponentach Komunikacyjnych (formularzach) wniosków będzie przedmiotem prac analitycznych i warsztatów z Wykonawcą. Wynikiem tych prac będzie m.in. opracowanie przez Wykonawcę we współpracy z Zamawiającym matrycy danych dla wniosków, pozwoleń w zakresie konkretnych procedur celnych oraz ich szablonów. Matryca powinna pokazywać np. dane ogólne wspólne dla wszystkich wniosków, dane specyficzne dla poszczególnych wniosków. A także np. wzajemne relacje pól, walidacje i integracje.

Lista wniosków (Komponentu Komunikacyjnego) stanowi Załącznik nr 2.1.A do niniejszego dokumentu.

(…)

Przykładowy zakres zmian formularzy wniosków, ilustrujący wymagania Zamawiającego – stanowią załącznik nr 2.6 do niniejszego dokumentu. W załączniku nr 2.6 zmiany pokazano na przykładzie wniosku o wydanie pozwolenia na uszlachetnianie bierne oraz wniosku
‎o pozwolenie na skład celny i magazyn czasowego składowania.

Nowe funkcjonalności dla wniosków będą dotyczyły przykładowo:

uporządkowania stosowanych identyfikatorów NIP/ID SISC/EORI w zależności
‎od obszaru „cło”, obszar „ordynacja podatkowa”,

zmian w układzie, kolejności pól,

dodania nowych pól,

zmian wymagalności pól lub sekcji,

zmian w strukturze pól, walidacji pól, masek na polach,

ukrywania lub odkrywania pól w zależności od wyboru przez Użytkownika Zewnętrznego określonego działania; interakcje między polami i sekcjami,

zmian etykiet, ujednolicenia etykiet dla tych samych pól i sekcji, uzupełnienia podpowiedzi (”i”) przy polach wniosku,

zasilania pól formularzy danymi z właściwych słowników, filtrowania na słownikach,

ujednolicenia typów danych,

automatycznego uzupełnienia pól danymi z Systemu SZPROT, np. na podstawie danych z kontekstu użytkownika, sprawdzanie uprawnienia,

właściwego przygotowania trybów zarządzania pozwoleniami (np. zmiana pozwolenia/decyzji, cofnięcie pozwolenia, itp. ),

zasilania pól formularzy dotyczących towarów z arkusza Excel, pliku CSV.

Zmiana i/lub rozbudowa funkcjonalności w procesach będzie dotyczyła następujących procesów:

BP.310; BP.320; BP. 330; BP.340; BP.350;

Nowe funkcjonalności dla procesów będą dotyczyły przykładowo:

transformat,

komunikatów,

zasilania rejestrów,

szablonów wydruków,

integracji z innymi systemami, p.: EOS, , PDR PL/UE,

przesyłania danych do innych systemów,

kroków w procesie,

tworzenia, podpisywania (w tym z użyciem elektronicznej pieczęci urzędowej w usłudze PKI), wysyłania dokumentów na poszczególnych krokach w procesie,

dodania nowych atrybutów lub usunięcia atrybutów,

dodawania ostrzeżeń/alertów, timerów dla użytkownika wewnętrznego w określonych sytuacjach,

konfiguracji decyzji,

udostępniania przycisku służącego do anulowania sprawy w szerszym zakresie (tam, gdzie jest on obecnie niewidoczny).

Zakres modyfikacji pozwoleń celnych, decyzji dotyczą przykładowo:

zmian w szablonie – układ, grafika,

zmian w układzie pól i sekcji w szablonach,

dodania nowych pól lub usunięcie pól w szablonach,

zmian w etykietach,

automatycznego uzupełnianie pól w szablonach,

zmian w konfiguracji szablonów,

dostosowania słowników.

9a. SZPROT_WFED_36_A _1

9a.1 Temat Zadania

Dostosowanie systemu SZPROT do nowych danych wynikających z przepisów unijnych, co obejmuje następujące elementy:

- modyfikacja Komponentów Komunikacyjnych Systemu SZPROT na PUESC (wniosków o wydanie decyzji, pozwoleń celnych) dla pozwoleń AEO, CGU, DPO i TEA,

- modyfikacja formularzy oraz szablonów wydruków w Systemie SZPROT,

- modyfikacja procesów obsługi tych wniosków (AEO, CGU, DPO, TEA), w tym dostosowanie komunikacji z EOS w procesie AEO do zmian danych w formularzach,

- modyfikacja rejestrów pozwoleń celnych, w tym komunikacji z CRS w zakresie dostosowania do przepisów unijnych.

9a.2 Opis zadania

Celem modyfikacji jest dostosowanie formularzy wniosków o wydanie pozwolenia/decyzji celnej na PUESC, formularzy i szablonów decyzji w SZPROT (także tych wydawanych „z urzędu”) oraz obsługa (proces) tych wniosków i decyzji w postępowaniu w systemie SZPROT do wymagań wynikających z przepisów unijnych, w tym wynikających z nich zmian w modelu danych w systemach EOS, CRS.

Wymaganie dotyczy obszaru biznesowego „cło” w zakresie funkcjonalności już wdrożonych produkcyjnie w SZPROT, tj. :

− dotyczących wydania/zmiany/cofnięcia/zawieszenia pozwolenia na upoważnionego przedsiębiorcę AEO,

− dotyczących wydania/zmiany/cofnięcia/zawieszenia pozwolenia na zabezpieczenie generalne CGU,

− dotyczących wydania/zmiany/cofnięcia/zawieszenia pozwolenia na odroczenie płatności DPO,

− dotyczących wydania/zmiany/cofnięcia/zawieszenia/przedłużenia pozwolenia na odprawę czasową TEA.

Ponadto modyfikacji wymaga także zakres danych i ich formatów w rejestrach wszystkich pozwoleń celnych w SZPROT:

(…)

Model danych:

1) we wnioskach o wydanie pozwolenia celnego i w decyzjach/pozwoleniach celnych wynika z przepisów unijnych, tj. rozporządzenia delegowanego oraz wykonawczego do Unijnego Kodeksu Celnego (Załącznik A – Wspólne wymogi dotyczące danych dla wniosków i decyzji).

Model danych dotyczący wniosków/pozwoleń celnych wymaga dostosowania do Rozporządzenia Delegowanego Komisji UE 2024/249 z dnia 30 listopada 2023 r. zmieniającego rozporządzenie delegowane UE 2015/2446 w odniesieniu do wspólnych wymogów dotyczących danych do celów wymiany i przechowywania niektórych informacji na mocy przepisów prawa celnego (UKC RD) oraz Rozporządzenia Wykonawczego Komisji UE 2024/250 z dnia 10 stycznia 2024 r. zmieniającego rozporządzenie wykonawcze UE 2015/2447 w odniesieniu do formatów i kodów na potrzeby wspólnych wymogów dotyczących danych do celów wymiany i przechowywania niektórych informacji na mocy przepisów prawa celnego (UKC RW).

(…)

9a.3 Data dostarczenia zadania

03.02.2025.

9b. SZPROT_WFED_36_A_2

9b.1 Temat Zadania

Modyfikacja Komponentów Komunikacyjnych Systemu SZPROT na PUESC (wniosków o wydanie decyzji, pozwoleń celnych), modyfikacja procesów obsługi tych wniosków, modyfikacja rejestrów pozwoleń, formularzy oraz szablonów wydruków w Systemie

9b.2 Opis zadania

Celem modyfikacji jest dostosowanie formularzy wniosków o wydanie decyzji, pozwolenia, do wymagań wynikających z:

1) przepisów unijnych lub krajowych,

2) zmian w modelu danych w innych systemach, np. EOS, CRS, PDR PL/UE,

3) potrzeb Zamawiającego.

Modyfikacji wymaga także obsługa (proces) tych wniosków w postępowaniu w Systemie

SZPROT.

Wnioski/pozwolenia/decyzje dotyczą obszaru biznesowego „cło”,

Model danych:

1) we wnioskach o wydanie pozwolenia celnego wynika z przepisów unijnych, tj.

rozporządzenia delegowanego oraz wykonawczego do Unijnego Kodeksu Celnego (Załącznik A – Wspólne wymogi dotyczące danych dla wniosków i decyzji). Część danych we wnioskach wynika także z przepisów krajowych oraz potrzeb Zamawiającego.

Model danych dotyczący wniosków/pozwoleń celnych wymienionych w załączniku A do rozporządzenia delegowanego i wykonawczego do Unijnego Kodeksu Celnego nie jest stały i będzie podlegał kolejnym zmianom w związku ze zmianami tych rozporządzeń. Publikacja w Dzienniku Urzędowym UE najnowszej zmiany rozporządzeń miała miejsce w lutym 2024 roku ( Rozporządzenie Delegowane Komisji UE 2024/249 z dnia 30 listopada 2023 r. zmieniające rozporządzenie delegowane UE 2015/2446 w odniesieniu do wspólnych wymogów dotyczących danych do celów wymiany i przechowywania niektórych informacji na mocy przepisów prawa celnego oraz Rozporządzenie Wykonawcze Komisji UE 2024/250 z dnia 10 stycznia 2024 r. zmieniające rozporządzenie wykonawcze UE 2015/2447 w odniesieniu do formatów i kodów na potrzeby wspólnych wymogów dotyczących danych do celów wymiany i przechowywania niektórych informacji na mocy przepisów prawa celnego). Dlatego niezbędne będą zmiany dostosowujące formularze do nowych/zmienianych danych. Przy pracach nad formularzami wniosków należy uwzględnić przykładowo rozwiązanie pozwalające np. na „ukrycie” wprowadzonych zmian do formularza i „odsłonięcie” ich później, dopiero w chwili wejścia w życie zmian wprowadzonych rozporządzeniami – wersjonowanie formularzy i schem komunikatów. Przepisy mogą bowiem przewidywać wejście w życie zmian w danym formularzu dopiero za jakiś czas, np. za rok.

Pełny zakres zmian w Komponentach Komunikacyjnych (formularzach) wniosków będzie przedmiotem prac analitycznych i warsztatów z Wykonawcą. Wynikiem tych prac będzie m.in. opracowanie przez Wykonawcę we współpracy z Zamawiającym matrycy danych dla wniosków, pozwoleń w zakresie konkretnych procedur celnych oraz ich szablonów. Matryca powinna pokazywać np. dane ogólne wspólne dla wszystkich wniosków, dane specyficzne dla poszczególnych wniosków, także np. wzajemne relacje pól, walidacje i integracje.

Izba zważyła:

Należy wskazać w tym miejscu, że zgodnie ze zmianami dokonanymi przez Zamawiającego 10 lipca 2024 roku, zarzut odwołania pomimo dokonanego podziału pozostaje aktualny w zakresie 9b. SZPROT_WFED_36_A_2. Podkreślenia wymaga,
‎że rozdzielenie zadań, a w zasadzie wydzielenie z zadania podstawowego zadania 9a. SZPROT_WFED_36_A _1 doprecyzowanego i zdefiniowanego przedmiotowo, dowodzi
‎w ocenie Izby tego, że zgodnie z argumentacją Odwołujacego możliwe jest uszczegółowienie w zakresie opisu treści zadania, która to pozwala na jego jednoznaczny
‎i wyczerpujący opis. Podkreślenia wymaga, że jednoznacznie Zamawiający wskazuje,
‎że pełny zakres zmian w Komponentach Komunikacyjnych (formularzach) wniosków będzie przedmiotem prac analitycznych i warsztatów z Wykonawcą. W ocenie Izby powyższe jednoznacznie dowodzi tego, że opis przedmiotu zamówienia jest niepełny, niewyczerpujący i pozostawiający obszary nieokreślone, co narusza podniesione w zarzucie odwołania przepisy.

Mając na uwadze powyższe Izba uznała zasadność wykreślenia z Załącznika nr 2 do OPZ Opis wymagań w zakresie Rozwoju Zdefiniowanego postanowień 9b. SZPROT_WFED_36_A_2. w punkcie 9.b1 i 9b2 odpowiadających swoja treścią 9. SZPROT_WFED_36_A oraz nakazuje wprowadzenie zadania w ramach Usług Rozwoju na Zgłoszenie.

VI.

W zakresie zarzutów skierowanych do rozpoznanie na rozprawie
‎w sprawie o sygn. akt KIO 2125/24

W zakresie zarzutu 2 - naruszenia art. 134 ust. 1 pkt. 4 PZP art. 99 ust. 1 PZP
‎w zw. z art. 16 i 17 PZP i art. 353[1] kc. w zw. z art. 8 ust. 1 PZP – przez niejasny/nieprecyzyjny opis wymagań Rozwoju Zdefiniowanego uniemożliwiający rzetelne oszacowanie jego kosztów - Izba zarzut uznała za niezasadny.

W zakresie rozpoznania zarzutów odwołania

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

- art. 8 ust. 1 ustawy - Do czynności podejmowanych przez zamawiającego, wykonawców oraz uczestników konkursu w postępowaniu o udzielenie zamówienia i konkursie oraz do umów w sprawach zamówień publicznych stosuje się przepisy ustawy z dnia 23 kwietnia 1964 r. - Kodeks cywilny (Dz.U. z 2022 r. , i oraz z 2023 r. ), jeżeli przepisy ustawy nie stanowią inaczej.

- art. 16 ustawy - Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób:

1) zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców;

2) przejrzysty;

3) proporcjonalny.

- art. 17 ustawy

1. Zamawiający udziela zamówienia w sposób zapewniający:

1) najlepszą jakość dostaw, usług, oraz robót budowlanych, uzasadnioną charakterem zamówienia, w ramach środków, które zamawiający może przeznaczyć na jego realizację, oraz

2) uzyskanie najlepszych efektów zamówienia, w tym efektów społecznych, środowiskowych oraz gospodarczych, o ile którykolwiek z tych efektów jest możliwy do uzyskania w danym zamówieniu, w stosunku do poniesionych nakładów.

2. Zamówienia udziela się wykonawcy wybranemu zgodnie z przepisami ustawy.

3. Czynności związane z przygotowaniem oraz przeprowadzeniem postępowania
‎o udzielenie zamówienia wykonują osoby zapewniające bezstronność i obiektywizm.

Ustawa z dnia 23 kwietnia 1964 roku Kodeks cywilny (tj. z dnia 2 sierpnia 2023 r. (Dz.U. z 2023 r. poz. 1610) dalej: KC)

Art. 353¹ KC - Strony zawierające umowę mogą ułożyć stosunek prawny według swego uznania, byleby jego treść lub cel nie sprzeciwiały się właściwości (naturze) stosunku, ustawie ani zasadom współżycia społecznego.

Izba ustaliła:

W zakresie ustaleń dokonanych przez Izbę w odniesieniu do zarzutu odwołania Izba wskazuje, że w zarzucie odwołania Odwołujący odnosi się do dokumentu Załącznik nr 2
‎do OPZ Opis wymagań w zakresie Rozwoju Zdefiniowanego.

Izba ustaliła, że Załącznik nr 2 do OPZ Opis wymagań w zakresie Rozwoju Zdefiniowanego zawiera opis 127 zadań.

Izba zważyła:

Izba zważyła w zakresie rozpoznania zarzutu w tym zakresie, że osią sporu jest jak podał w odwołaniu Odwołujący jest lakoniczny sposób zdefiniowania Zadań, dla części
‎z przesuniętym momentem doprecyzowania wymagań na etap analityczny, co uznaje
‎za niedopuszczalne. Odwołujący podał, że w przypadku Zadań, w których Zamawiający nie jest w stanie precyzyjnie opisać wymagań lub chciałby pozostawić sobie możliwość doprecyzowania sposobu realizacji danej funkcjonalności, Zamawiający powinien skorzystać z możliwości zlecenia realizacji takiego Zadania/funkcjonalności w ramach Rozwoju
‎na Zgłoszenie i przewidzianej tam puli roboczogodzin.

Tak postawiony zarzut odwołania jest ogólny, hasłowy i lakoniczny. Izba wskazuje,
‎że Odwołujący nie podał w swoim stanowisku nawet ilości Zadań jakie Zamawiający ujął
‎w Załączniku nr 2 do OPZ Opis wymagań w zakresie Rozwoju Zdefiniowanego. Izba ustaliła, że w ramach ww. dokumentu uwzględniono 127 Zadań gdzie wskazano opisy
‎dla każdego z Zadań z osobna. Odwołujący nie odnosi się do poszczególnych zadań,
‎nie wskazuje i nie wyjaśnia dlaczego uznaje opisy w tych Zadaniach - należy wskazać,
‎w poszczególnych zadaniach – uznaje za lakoniczne. Nie podaje w zakresie jakich Zadań
‎w jego ocenie doprecyzowanie wymagań zostało przesunięte na etap analityczny.
‎W zasadzie poza kilkoma zdaniami, które na najwyższym poziomie ogólności odnoszą się do opisu Zadań przygotowanego przez Zamawiającego zawartego na ponad 132 stronach Odwołujący nie przedstawił w zasadzie żadnej faktycznej, merytorycznej argumentacji uzasadniającej podniesione naruszenie przepisów.

Dopiero w piśmie procesowym Odwołujący przedstawia argumentację faktyczną odnoszącą się do hasłowo zasygnalizowanych w uzasadnieniu odwołania problemów jakie miałyby lec
‎u podstaw uzasadnienia zarzutów. Izba wyjaśnia, że o ile faktycznie dowody wykonawca może w trakcie rozprawy składać aż do zamknięcia rozprawy, to wymaga podkreślenia,
‎że uzasadnienie stanowiska Odwołującego mające wykazać zasadność twierdzeń musi być zawarte w odwołaniu. Przedstawienie argumentacji faktycznej w odwołaniu pozwala
‎na odniesienie się do stanowiska jakie prezentuje Odwołujący. W przypadku kwestionowania w zasadzie postanowień całego dokumentu Załącznika nr 2 do OPZ Opis wymagań
‎w zakresie Rozwoju Zdefiniowanego, opisującego 127 Zadań Odwołujący winien odnieść się do tych opisów w sposób dający poddać się ocenie i w ogóle przedstawiając argumentację. Podkreślenia wymaga, że Izba nie zastępuje Odwołujacego w argumentacji oraz
‎nie prowadzi analizy dokumentów za Odwołujacego mającej wypełnić treścią jednostkowe zdania uzasadnienia zarzutu.

Izba podkreśla, że uzasadnienie faktyczne podniesione przez Odwołującego, stanowiące nierozerwalny element podniesienia w odwołaniu zarzutów odwołania zakreśla jednocześnie zakres rozpoznania odwołania przez Izbę. Orzecznictwo sądów powszechnych jak również Krajowej Izby Odwoławczej wskazuje na potrzebę ścisłego odczytywania treści zarzutu,
‎w tym przede wszystkim niedopuszczalność wykraczania poza jego treść. Jak wskazano
‎w nieprzerwanie aktualnym wyroku Sądu Okręgowego w Gliwicach z 29 czerwca 2009 r.
‎w spr. X Ga 110/09, „Jeśli więc strona nie odwołuje się do konkretnych okoliczności faktycznych to skład orzekający nie może samodzielnie ich wprowadzić do postępowania tylko dlatego, że można je przyporządkować określonej, wskazanej w odwołaniu kwalifikacji prawnej.” Na potrzebę ścisłego traktowania pojęcia zarzutu wskazał również Sąd Okręgowy w Rzeszowie w uzasadnieniu wyroku z dnia 18 kwietnia 2012 r. w spr. o sygn. I Ca 117/12: „Z analizy powyższych przepisów można wyciągnąć dwa zasadnicze wnioski dla niniejszej sprawy. Po pierwsze, zarówno granice rozpoznania sprawy przez KIO jak i Sąd są ściśle określone przez zarzuty odwołania, oparte na konkretnej i precyzyjnej podstawie faktycznej. Sąd w postępowaniu toczącym się na skutek wniesienia skargi jest związany podniesionymi w odwołaniu zarzutami i wyznaczonymi przez nie granicami zaskarżenia.” W orzecznictwie Krajowej Izby Odwoławczej również ugruntowany jest również pogląd, że dla oceny zrzutu kluczowe znaczenie ma podanie w treści odwołania uzasadnienia faktycznego, wyczerpującego i zawierającego argumentację pozwalającą na ocenę poprawności zachowań (czynności, zaniechań) Zamawiającego, które kwestionuje we wniesionym odwołaniu Odwołujący. W orzecznictwie Sądu Najwyższego wskazuje się również, że powód nie jest obowiązany do wskazania w pozwie podstawy prawnej swego roszczenia. „Zgodnie z zasadą da mihi factum, dabo tibi ius – wynikającą w polskim prawie procesowym z nałożenia na powoda jedynie obowiązku przytoczenia okoliczności faktycznych uzasadniających żądanie – konstrukcja prawna podstawy rozstrzygnięcia należy do sądu.” (wyrok Sądu najwyższego z dnia 26 czerwca 1997 roku sygn. akt I CKN 130/97). Sąd Najwyższy podkreśla w swoim orzecznictwie, że obligatoryjnym elementem pozwu jest przytoczenie okoliczności faktycznych uzasadniających żądanie pozwu (art. 187 par. 1 ust. 2 KPC), okoliczności te stanowią podstawę faktyczną powództwa (causa petendi) – tak Sąd Najwyższy w wyroku z dnia 2 maja 1957 roku sygn. akt II CR 305/57.

W orzecznictwie Krajowej Izby Odwoławczej również ugruntowany jest pogląd,
‎że o prawidłowości konstrukcji zarzutu odwołania nie może przesądzać kwalifikacja prawna zaskarżonej czynności, ponieważ ostatecznie to do Izby należy subsumcja stanu faktycznego pod określoną normę prawną, natomiast kluczowe znaczenie ma podanie
‎w treści odwołania uzasadnienia faktycznego, wyczerpującego i zawierającego argumentację pozwalającą na ocenę zachowań (czynności, zaniechań) Zamawiającego, które kwestionuje we wniesionym odwołaniu Odwołujący. W tym zakresie aktualne pozostaje wypracowane
‎na podstawie ustawy z dnia 29 stycznia 2004 Prawo zamówień publicznych stanowisko
‎co do konieczności podania uzasadnienie faktycznego podnoszonych zarzutów, bowiem przepisy uprzednio obwiązującej ustawy nie odbiegają od treści obowiązujących obecnie. Jednocześnie wypracowane w orzecznictwie stanowisko znajduje również swoje odwzorowanie w piśmiennictwie.

Wymaga odnotowania w tym miejscu, że postępowanie odwoławcze nie jest elementem procedury administracyjnej i nie wystarczy w odwołaniu wskazać, że z danymi czynnościami lub zaniechaniami Zamawiającego Odwołujący się nie zgadza, w postępowaniu odwoławczym niezbędne jest przedstawienie w odwołaniu uzasadnienia zawierającego okoliczności faktyczne i prawne uzasadniające twierdzenia Odwołującego i pozwalające Izbie, w postępowaniu kontradyktoryjnym, na ocenę działań Zamawiającego w kontekście podnoszonych przez Odwołującego naruszeń. Jedynie w zakresie naruszeń podnoszonych w uzasadnieniu faktycznym zarzutów odwołania możliwa jest zgodnie z zasadą orzekania
‎w zakresie zarzutów, ocena podnoszonych przez Odwołującego naruszeń. Wynika
‎to również z tego, że jakiekolwiek rozszerzenie argumentacji faktycznej stanowi nową, nieznaną Zamawiającemu oraz uczestnikowi postępowania odwoławczego argumentację / stanowisko Odwołującego, z którym nie mógł się on zapoznać wcześniej.

Brak argumentacji Odwołującego w uzasadnieniu odwołania potwierdza szeroko prezentowana w piśmie procesowym i w trakcie rozprawy argumentacja faktyczna Odwołujacego. Izba poddając ocenie to stanowisko Odwołującego musiałby poddać ocenie stanowiska wyrażone po upływie terminu na odwołanie. Stanowisko zawarte w uzasadnieniu odwołania nie przedstawia żadnej argumentacji dającej poddać się ocenie, bowiem zawarte tam twierdzenia nie zostały w żaden sposób uargumentowane.

Tym samym Izba uznała zarzut odwołania za niezasadny.

W zakresie zarzutu 3 - naruszenia art. 134 ust. 1 pkt. 4 PZP, art. 99 ust. 1 oraz art. 353[1] kodeksu cywilnego w zw. z art. 8 ust 1 PZP oraz art. 16 i 17 PZP przez udostępnienie informacji o systemie w sposób uniemożliwiający oszacowanie nakładów pracy na realizację zadań przewidzianych w ramach Rozwoju Zdefiniowanego - Izba zarzut uznała za niezasadny.

W zakresie rozpoznania zarzutów odwołania

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

- art. 16 ustawy - Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób:

1) zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców;

2) przejrzysty;

3) proporcjonalny.

- art. 17 ustawy

1. Zamawiający udziela zamówienia w sposób zapewniający:

1) najlepszą jakość dostaw, usług, oraz robót budowlanych, uzasadnioną charakterem zamówienia, w ramach środków, które zamawiający może przeznaczyć na jego realizację, oraz

2. Zamówienia udziela się wykonawcy wybranemu zgodnie z przepisami ustawy.

3. Czynności związane z przygotowaniem oraz przeprowadzeniem postępowania
‎o udzielenie zamówienia wykonują osoby zapewniające bezstronność i obiektywizm.

- art. 134 ust. pkt 4 ustawy - SWZ zawiera co najmniej:

4) opis przedmiotu zamówienia;

Ustawa z dnia 23 kwietnia 1964 roku Kodeks cywilny (tj. z dnia 2 sierpnia 2023 r. (Dz.U. z 2023 r. poz. 1610) dalej: KC)

Izba ustaliła:

Izba ustaliła, że zgodnie ze Specyfikacja Warunków Zamówienia:

6. OPIS PRZEDMIOTU ZAMÓWIENIA

6.12. Zamawiający przewiduje sprawdzenie przez Wykonawcę dokumentów i kodów źródłowych umożliwiających realizację Usługi zgodnie z wymaganiami zawartymi
‎w Tomie III SWZ Opis Przedmiotu Zamówienia, dostępnych na miejscu u Zamawiającego.

6.12.1. Ze względu na specyfikę przedmiotu zamówienia, Zamawiający zobowiązuje Wykonawców w dniach 17 czerwca – 2 lipca 2024 r. do sprawdzenia dokumentacji i kodów źródłowych Systemu. Sprawdzenie dokumentacji i kodów źródłowych Systemu jest obligatoryjne.

6.12.2. Zamawiający udostępni w biurze CIRF w Warszawie przy ul. Świętokrzyskiej 12,
‎na przygotowanych 4 stanowiskach komputerowych, wyłącznie do wglądu:

1) dokumentację Systemu SZPROT,

2) kody źródłowe poszczególnych modułów Systemu SZPROT.

Warunkiem koniecznym do sprawdzenia dokumentacji i kodów źródłowych Systemu jest podpisanie przez Wykonawcę i przez osoby zadeklarowane przez Wykonawcę Oświadczenia o zachowaniu poufności – Formularz 3.9. do IDW.

6.12.3. W celu sprawdzenia dokumentów i kodów źródłowych Wykonawca zobowiązany jest przesłać wypełniony i podpisany przez Wykonawcę/przedstawicieli Wykonawcy wniosek (druk, którego wzór stanowi Formularz 3.8. do IDW) oraz podpisane Oświadczenie o zachowaniu poufności (Formularz 3.9 do IDW) na adres email: j. w terminie do 12.06.2024 r. do godz. 14:00. Zamawiający potwierdzi mailowo otrzymanie wniosku o udział w sprawdzeniu dokumentacji i kodów źródłowych Systemu na adres email Wykonawcy, z którego przesłano wniosek.

6.12.4. Zamawiający najpóźniej w dniu 14.06.2024 r. poinformuje Wykonawców, o terminie sprawdzenia dokumentacji i kodów źródłowych Systemu. Każdemu Wykonawcy zostanie wyznaczony termin 2 dni roboczych następujących po sobie. Przed dokonaniem sprawdzenia dokumentacji i kodów źródłowych Systemu przez osoby zadeklarowane przez Wykonawcę, zobowiązane będą one do podpisania Oświadczenia o zachowaniu poufności – Formularz 3.9. do IDW. Sprawdzenie odbędzie się w godzinach od 9:00 do 15:00. Potwierdzeniem udziału w sprawdzeniu dokumentacji i kodów źródłowych Systemu będzie podpisana lista obecności udostępniona przez Zamawiającego w dniu sprawdzenia dokumentacji i kodów źródłowych Systemu.

Według zmian Specyfikacji Warunków Zamówienia opublikowane na stronie internetowej prowadzonego postępowania, zmieniono w następujący sposób:

6.12.

Zamawiający przewiduje sprawdzenie przez Wykonawcę dokumentów i kodów źródłowych umożliwiających realizację Usługi zgodnie z wymaganiami zawartymi w Tomie III SWZ Opis Przedmiotu Zamówienia, dostępnych na miejscu u Zamawiającego.

6.12.1. Ze względu na specyfikę przedmiotu zamówienia, Zamawiający zobowiązuje Wykonawców w dniach 19 czerwca – 23 lipca 2024 r. do sprawdzenia dokumentacji i kodów źródłowych Systemu. Sprawdzenie dokumentacji i kodów źródłowych Systemu jest obligatoryjne.

6.12.2. Zamawiający udostępni w biurze CIRF w Warszawie przy ul. Świętokrzyskiej 12, na przygotowanych 4 stanowiskach komputerowych, wyłącznie do wglądu:

1) dokumentację Systemu SZPROT,

2) kody źródłowe poszczególnych modułów Systemu SZPROT.

6.12.3. W celu sprawdzenia dokumentów i kodów źródłowych Wykonawca zobowiązany jest przesłać wypełniony i podpisany przez Wykonawcę/przedstawicieli Wykonawcy wniosek (druk, którego wzór stanowi Formularz 3.8. do IDW) oraz podpisane Oświadczenie o zachowaniu poufności (Formularz 3.9 do IDW) na adres email: j. w terminie do 08.07.2024 r. do godz. 10:00. Zamawiający potwierdzi mailowo otrzymanie wniosku o udział w sprawdzeniu dokumentacji i kodów źródłowych Systemu na adres email Wykonawcy, z którego przesłano wniosek.

6.12.4. Zamawiający najpóźniej w dniu 09.07.2024 r. poinformuje Wykonawców, o terminie sprawdzenia dokumentacji i kodów źródłowych Systemu. Każdemu Wykonawcy zostanie wyznaczony termin 7 dni roboczych. Przed dokonaniem sprawdzenia dokumentacji i kodów źródłowych Systemu przez osoby zadeklarowane przez Wykonawcę, zobowiązane będą one do podpisania Oświadczenia o zachowaniu poufności – Formularz 3.9. do IDW. Sprawdzenie odbędzie się w godzinach od 9:00 do 15:00. Potwierdzeniem udziału w sprawdzeniu dokumentacji i kodów źródłowych Systemu będzie podpisana lista obecności udostępniona przez Zamawiającego w dniu sprawdzenia dokumentacji i kodów źródłowych Systemu.

6.13. Ilekroć w treści SWZ, w tym w OPZ, stanowiącym Tom III SWZ, przedmiot zamówienia został opisany przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego Wykonawcę, Zamawiający dopuszcza zaoferowanie przez Wykonawcę rozwiązania równoważnego. Za rozwiązanie równoważne uznaje się produkt lub usługę, których istotne parametry techniczne, jakościowe, funkcjonalne spełniają parametry określone przez Zamawiającego w OPZ.

Izba zważyła:

Na wstępie Izba wskazuje, że zarzut odwołania został tak skonstruowany, że wynika z niego, że Zamawiający nie udostępnił w SWZ dokumentacji Systemu Szprot ani jego kodów źródłowych. Jednakże w to zdanie w pewien sposób już jest fałszywe, bowiem Zamawiający nie udostępnia w SWZ pełnej dokumentacji Systemu SZPROT oraz kodów źródłowych.

Podkreślenia wymaga w ocenie Izby, że nieudostępnienie w SWZ pełnej dokumentacji Systemu SZPROT i kodów żądłowych nie oznacza, że ta dokumentacja nie będzie udostępniona wykonawcom zainteresowanym postępowaniem. Zamawiający przewidział procedury udostępnienia nieudostępnionej w SWZ dokumentacji oraz kodów źródłowych.

W ocenie Izby kluczowym dla rozpoznania tego zarzutu odwołania jest odniesienie do tego, czy możliwym jest w ramach podnoszonych przepisów udostępnienie wykonawcom części dokumentacji Systemu i kodów źródłowych w sposób jaki przewidział to Zamawiający. Wymaga jednocześnie znaczenia, co niewątpliwie nie może zostać pominięte przy rozpoznaniu zarzutu odwołania, że Zamawiający wyjaśnił, że taki model udostępnienia pełnej dokumentacji i kodów źródłowych z uwagi na krytyczność Systemu SZPROT (klasyfikacja K1 – najwyższy poziom krytyczności wg klasyfikacji resortu finansów) dla obszaru celnego
‎i finansów Skarbu Państwa, nie może udostępnić pełnej dokumentacji Systemu i kodów źródłowych już na etapie składania ofert, w sposób zapewniający swobodne dysponowanie tym materiałem w nieograniczonym czasowo okresie przez wykonawców.

Zaznaczenia wymaga również, że bezprzedmiotowa stała się argumentacja odnosząca się do ilości dni (2 dni) przewidzianych na zapoznanie z nieudostępniona w SWZ częścią dokumentacji oraz kodami źródłowymi, bowiem w tym zakresie Zamawiający zmodyfikował postanowienia SWZ i jak wynika z ustaleń, wprowadził termin „7 dni roboczych”.

W ramach obowiązków Zamawiającego wynikających z art. 134 ust. 1 pkt 4 ustawy zobowiązany jest do zawarcia w SWZ opisu przedmiotu zamówienia, który to opis przedmiotu zamówienia realizowany jest w oparciu o przesłanki z art. 99 i nast. Ustawy.

W rozpoznawanej sprawie odwoławczej, co należy podkreślić, częścią opisu przedmiotu zamówienia jest procedura udostępnienia dokumentacji Systemu SZPROT oraz kodów źródłowych w siedzibie Zamawiającego. Taka forma opisu przedmiotu zamówienia,
‎z odesłaniem do przeglądu dokumentów u Zamawiającego, jak zostało ustalone powyżej, wynika z krytyczności Systemu SZPROT – klasyfikacja K1 – najwyższy poziom krytyczności
‎wg. Klasyfikacji resortu finansów. Wymaga wskazania w tym miejscu, że Odwołujący
‎nie podnosił argumentacji dotyczącej braku uzasadnienia przez Zamawiającego jego działania, jak również nie podnosił argumentacji w zakresie przyznanego poziomu klasyfikacji K1 według Klasyfikacji resortu finansów. Zarzut odwołania w zasadzie sprowadza się do tego, że nie ma możliwości oszacowania nakładów pracy na realizację zadań przewidzianych w ramach Rozwoju Zdefiniowanego. Tym samym jedynie określony obszar przedmiotu zamówienia został objęty zarzutem odwołania przez Odwołujacego.

Przechodzą dalej, w odniesieniu do opisu przedmiotu zamówienia należy odpowiedzieć
‎na pytanie, czy taki sposób dokonania opisu – jak zrobił to Zamawiający w przedmiotowym postępowaniu – wypełnia regulację art. 99 ust. 1 ustawy.

W ocenie Izby przy jednoczesnym uwzględnieniu poziomu krytyczności, klasyfikacja K1, wg. Klasyfikacji resortu finansów uzasadnione jest sporządzenie opisu przedmiotu zamówienia przez wskazanie na zapoznanie się z dokumentacją Systemu oraz kodami źródłowymi
‎w siedzibie Zamawiającego. Oczywiście jest to okoliczność wyjątkowa i nie może ona stać się zasadą w postępowaniu Zamawiającego, niemniej Zamawiający przedstawionym opisem przedmiotu zamówienia nie doprowadził do sytuacji, w której nie udostępnia dokumentacji Systemu oraz kodów źródłowych, lecz czyni to w inny sposób. Wymaga podkreślenia,
‎że całościowa dokumentacja i kody źródłowe zostaną udostępnione wykonawcy zainteresowanemu postępowaniem, a po zmianach SWZ czas na zapoznanie się
‎z dokumentacją jest wydłużony do 7 dni roboczych, przy czym w trakcie rozprawy Zamawiający deklarował, że w przypadkach wnioskowania o wydłużenie tego terminu będzie reagował na takie wnioski pozytywnie. Izba podkreśla, że taki sposób opisania przedmiotu zamówienia może nie jest rozwiązaniem standardowym i znanym nam wszystkim z wielu prowadzonych postepowań, ale jednocześnie godzi obowiązki posiania przedmiotu zamówienia przy jednoczesnym poszanowaniu zasad klasyfikacji resortu finansów
‎w odniesieniu do poziomu krytyczności K1 Systemu SZPROT. Zamawiający uzasadniał również, że dodatkowo ograniczeniem są wewnętrzne procedury bezpieczeństwa funkcjonujące w resorcie finansów.

Przechodząc dalej, Odwołujący w ocenie Izby demonizuje kwestię zapoznania się
‎z dokumentacją Systemu SZPROT oraz kodami źródłowymi. Wynika to z faktu, że w ogóle
‎w swoim stanowisku nie odnosi się do dokumentacji jaka została załączona do SWZ i z jaką może i powinien się zapoznać. Zakres dokumentów załączony do SWZ odnoszących się
‎do Rozwoju Zdefiniowanego, którego co do zasady zarzut dotyczy, to Opis wymagań
‎w zakresie Rozwoju Zdefiniowanego oraz załączniki (załącznik nr 2 do OPZ – Załączniki
‎do opisu rozwoju zdefiniowanego), jak również wszystkie pozostałe 15 załączników do OPZ, które opisują System. Odwołujący pomija je w zupełności i nie odnosi się do nich. Jednocześnie Izba pragnie podkreślić, że w ramach zamówień publicznych działają profesjonaliści – i nie jest to ani rzecz nowa, ani odkrywcza – co do których oczekiwania są podwyższone, co również jest ugruntowanym w orzecznictwie i doktrynie zarówno prawa cywilnego jak i zamówień publicznych. Tym samym, realizacja zadań polegających
‎na wglądzie w udostępnioną przez Zamawiającego dokumentację w siedzibie Zamawiającego realizowana powinna być przez osoby posiadające odpowiedni poziom wykształcenia i przygotowania oraz doświadczenia. Niewątpliwe wiodące podmioty w branży IT na polskim rynku, a jakie biorą udział w przedmiotowej sprawie odwoławczej, dysponują
‎w swoich zasobach kadrowych takimi specjalistami, którzy bez problemów będą w stanie zapoznać się z dokumentami po uprzednim zapoznaniu się dokumentacją zamieszczoną
‎przez Zamawiającego wraz z SWZ, a dotyczącą Rozwoju Zdefiniowanego. Przy czym ponownie należy odnotować, że Odwołujący w zupełności pomija kwestię zapoznania się
‎z dokumentacja przez osoby do tego faktycznie przygotowane.

Wskazać należy również, że w ramach różnych zawieranych kontraktów w przedmiocie obsługi i rozwoju systemów informatycznych podmioty ubiegające się o takie zamówienia, podobnie jak w przedmiotowej sprawie, mają jedynie wgląd w dokumentację systemu i kody źródłowe. Podkreślenia wymaga, że w ramach tego postępowania o zamówienie nie ma sytuacji w której wykonawca nie ma dostępu do dokumentacji systemu oraz kodów źródłowych. Izba jedynie w celu przypomnienia podaje w tym miejscu, że w wyniku modyfikacji SWZ Zamawiający zmienił termin na zapoznanie się z dokumentacją i kodami źródłowym z 2 na 7 dni roboczych oraz zapowiedział w trakcie rozprawy, że jest otwarty
‎na składane w tym zakresie wnioski do SWZ.

W zakresie dowodu przedstawionego przez Odwołujacego (dowód nr 1) Izba wyjaśnia,
‎że jest on bezprzedmiotowy dla rozpoznania sprawy w tym zarzucie, bowiem w żadnym przypadku Odwołujący nie wykazał, że systemy objęte tym dowodem posiadają poziom krytyczności systemu odpowiadający temu jaki posiada System SZPROT na dzień dzisiejszy. Dowód ten dowodzi jedynie tego, że w tamtych postępowania o zamówienie, prowadzonych w różnych latach stosowane były przez Zamawiającego inne rozwiązania
‎w zakresie udostępniania dokumentacji, ale w żaden sposób dowody te nie potwierdzają,
‎że działanie Zamawiającego w przedmiotowym postepowaniu jest nieprawidłowe.

Co do argumentów odnoszących się do dostępu przez aktualnego wykonawcę Systemu SZPROT do niezbędnych materiałów, nieograniczoną czasowo możliwość dostępu
‎do kodów źródłowych, Izba stwierdza, że taka argumentacja Odwołujacego nie zasługuje
‎na uwzględnienie. Każdy wykonawca zainteresowany zamówieniem będzie miał dostęp
‎do dokumentacji systemu jak również do kodów źródłowych. Przyjmując stanowisko Odwołujący pomija fakt, że wykonawca realizował usługę przez ostatnie lata, tym samym znajomość systemu i wiedzę wykonawca w tym zakresie nabywał w tym czasie. Tak więc jedynym rozwiązaniem – aczkolwiek niedopuszczalnym – byłoby niedopuszczenie tego wykonawcy do złożenia oferty z uwagi na to, ze świadczył już to zamówienie.

W odniesieniu do argumentacji zawartej w piśmie procesowym Odwołujacego, między innymi odnoszącej się do prowadzenia postępowania zgodnie z procedurą przewidzianą dla zamówień w dzianinie bezpieczeństwa i obronności w ocenie Izby jest argumentacją spóźnioną, bowiem taką niewątpliwie mógł odwołujący ponieść w odwołaniu. w tym zakresie zasadna jest argumentacja prawna zawarta w rozpoznaniu zarzutu 2, która Izba przywołuje w tym miejscu.

Mając na uwadze powyższe Izba uznała zarzut za niezasadny.

W zakresie zarzutu 4 - naruszenia art. 134 ust. 1 pkt. 4 PZP, art. 99 ust. 1 oraz art. 353[1] kodeksu cywilnego w zw. z art. 8 ust 1 PZP oraz art. 16 i 17 PZP przez brak gwarantowanego czasu na przygotowanie się do świadczenia usług - Izba zarzut uznała za zasadny.

W zakresie rozpoznania zarzutów odwołania

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

- art. 16 ustawy - Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób:

1) zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców;

2) przejrzysty;

3) proporcjonalny.

- art. 17 ustawy

1. Zamawiający udziela zamówienia w sposób zapewniający:

1) najlepszą jakość dostaw, usług, oraz robót budowlanych, uzasadnioną charakterem zamówienia, w ramach środków, które zamawiający może przeznaczyć na jego realizację, oraz

2. Zamówienia udziela się wykonawcy wybranemu zgodnie z przepisami ustawy.

3. Czynności związane z przygotowaniem oraz przeprowadzeniem postępowania
‎o udzielenie zamówienia wykonują osoby zapewniające bezstronność i obiektywizm.

- art. 134 ust. pkt 4 ustawy - SWZ zawiera co najmniej:

4) opis przedmiotu zamówienia;

Ustawa z dnia 23 kwietnia 1964 roku Kodeks cywilny (tj. z dnia 2 sierpnia 2023 r. (Dz.U. z 2023 r. poz. 1610) dalej: KC)

Izba ustaliła:

TOM III SWZ Opis przedmiotu zamówienia, zwany dalej: OPZ na „Świadczenie usług rozwoju i utrzymania Systemu SZPROT”

Okres przejściowy

Okres od dnia zawarcia Umowy do Przejęcia Systemu. W okresie tym Wykonawca zapoznaje się z Systemem poprzez dostęp do Systemu i jego Dokumentacji, pozwalający m.in. na weryfikację infrastruktury, weryfikację i kompilację kodu, pozyskanie informacji od Zamawiającego niezbędnych do realizacji Usług Utrzymania Systemu. W okresie tym Wykonawca nie jest uprawniony do dokonywania jakichkolwiek zmian w Systemie oraz nie przysługuje mu wynagrodzenie z tytułu świadczenia Usług Utrzymania Systemu.

Przejęcie Systemu

Dzień, w którym Wykonawca rozpoczyna świadczenie Usługi Utrzymania Systemu, po zakończeniu Okresu przejściowego, nie wcześniej niż od dnia 1 lutego 2025 r., potwierdzony podpisaniem przez Strony protokołu Przejęcia Systemu sporządzonego zgodnie ze wzorem Załącznika nr 16 do OPZ.

Izba zważyła:

Izba wskazuje, że w ramach przedmiotowego zarzutu odwołania nie została podniesiona argumentacja faktyczna oraz prawna odnosząca się do naruszenia art. 436 pkt 1 ustawy przez określenie dat dziennych. We wniosku zarzutu podnosi Odwołujący
‎o nakazanie Zamawiającemu modyfikacji SWZ i wprowadzenie terminów rozpoczęcia świadczenia usług w postaci dat względnych – przy czym w żaden sposób nie wyjaśnia
‎i nie podaje co też rozumie pod pojęciem daty względnej – gwarantujących co najmniej
‎3 miesięczny okres pomiędzy dniem podpisania umowy a dniem rozpoczęcia świadczenia usługi z możliwością skrócenia tego czasu za porozumieniem stron.

Wymaga dostrzeżenia, że w zakresie zarzutu podniesiona jest również argumentacja odnoszącą się do tego, że Okres Przejściowy przewidziany jest tylko wyłącznie przed rozpoczęciem Usług Utrzymania.

Stwierdzić należy, że usługi Rozwoju na zgłoszenie oraz Utrzymania rozpoczną się dopiero po przejęciu Systemu.

W ocenie Izby tak podniesiony zarzut odwołania oraz argumentacja faktyczna jaka zostało do niego przedstawiana uzasadnia stanowisko Odwołującego co do konieczności określenia Okresu Przejściowego przez podanie dokładnie jednostki czasu - ilości miesięcy jaki ten Okres Przejściowy ma obejmować. Zdaniem Izby wnioskowany przez Odwołujacego trzymiesięczny (3 miesiące) Okres Przejściowy jest uzasadnionym terminem biorąc pod uwagę złożoność Systemu – do której wielokrotnie referował Zamawiający - oraz zakres podejmowanych prac w ramach realizacji poszczególnych Zadań oraz świadczonych usług. Kwestia ciągłości świadczenia usług, do której odnosił się Zamawiający, jest w ocenie Izby bardzo istotnym argumentem ale nie sposób zapominać, że prawidłowo realizacja zamówienia wymaga również prawidłowego i jednoznacznego opisania przedmiotu zamówienia, w tym wypadku stosownego Okresu Przejściowego umożliwiającemu wykonawcy, który pozyska zamówienie, zapoznania się z całym środowiskiem realizacji zamówienia.

Izba nie znajduje uzasadnienia dla argumentacji Zamawiającego odnoszącej się
‎do harmonogramu prowadzenia postępowania i założonego co najmniej 45 dniowego Okresu Przejściowego. Podkreślić należy, że informacja ta nie wynika z żadnego dokumentu w dokumentacji zamówienia, stanowi jedynie planowane założenia w ramach prowadzenia postępowania o udzielnie zamówienia publicznego, które prawdopodobnie już się zdewaluowały, bowiem w postępowaniu o zamówienie został już przesunięty termin otwarcia ofert, a najprawdopodobniej w wyniku postępowania odwoławczego data otwarcia ofert ponownie ulegnie zmianie, natomiast termin Przejęcia systemu po zakończeniu Okresu przejściowego został określony datą dzienną 01 02 2025.

Mając na uwadze powyższe Izba nakazała 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”.

Izba przytacza w tym miejscu rozpoznanie zarzutu odwołania sygn. akt KIO 2105/24
‎w zakresie zarzutu XVII gdzie nakazała 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.

W zakresie zarzutu 5 - naruszenia art. 353[1] kodeksu cywilnego oraz art. 387 § 1 kodeksu cywilnego w zw. z art. 8 ust. 1 PZP przez ustanowienie terminów dostarczenia poszczególnych zadań Rozwoju Zdefiniowanego w datach sztywnych (określonych kalendarzowo), których dotrzymanie przez Wykonawcę jest w praktyce niemożliwe lub mało prawdopodobne - Izba zarzut uznała za niezasadny.

W zakresie rozpoznania zarzutów odwołania

Izba na wstępie wskazuję, zgodnie z art. 559 ust. 2 ustawy podstawy prawne oraz przytacza przepisy prawa:

Ustawa z dnia 23 kwietnia 1964 roku Kodeks cywilny (tj. z dnia 2 sierpnia 2023 r. (Dz.U. z 2023 r. poz. 1610) dalej: KC)

- art. 353¹ KC - Strony zawierające umowę mogą ułożyć stosunek prawny według swego uznania, byleby jego treść lub cel nie sprzeciwiały się właściwości (naturze) stosunku, ustawie ani zasadom współżycia społecznego.

- art. 387 KC § 1. Umowa o świadczenie niemożliwe jest nieważna.

Izba ustaliła:

Załącznik nr 2 do OPZ Opis wymagań w zakresie Rozwoju Zdefiniowanego, dla każdego
‎z Zadamawiający podał datę dostarczenia zadania.

Izba zważyła:

W odniesieniu do przedmiotowego zarzutu odwołania stwierdzić należy,
‎że Odwołujący podnosi zarzut ustanowienia terminów w datach dziennych „sztywnych”, których dotrzymanie przez wykonawcę jest w praktyce niemożliwe lub mało prawdopodobne.

Izba podkreśla, że w ramach przedmiotowego zarzutu odwołania nie została podniesiona argumentacja faktyczna oraz prawna odnosząca się do naruszenia art. 436 pkt 1 ustawy przez określenie dat dziennych.

W tego zarzutu tj. w zakresie opisanie przedmiotu zamówienia przez określenie wymagania niemożliwego do spełnienia z uwagi na nierealność dat dziennych określonych przez Zamawiającego dla każdego zadania Rozwoju Zdefiniowanego, gdzie data początkowa tj. 02 01 2025 w ocenie Odwołujacego budzi wątpliwości co do realności jej dochowania.

Izba podkreśla w tym miejscu, że w związku ze zamianami załącznika nr 2 do OPZ, zmiennie uległa również data z 02 01 2025 na 03 02 2025.

Izba stoi na stanowisku, mając na uwadze stanowisko Zamawiającego z odpowiedzi na odwołanie, że Odwołujący nie wykazał aby świadczenie określone przedmiotem zamówienia było niemożliwe do zrealizowania. Podkreślenia wymaga, że Izba nie odnosi się w ramach rozpoznania tego zarzutu odwołania do istoty ustanowienia dat dziennych,
‎lecz odnosi się do argumentacji uzasadniającej niemożliwość świadczenia. Sytuacja
‎w rozpoznaniu tego zarzutu jest o tyle trudna, że nie wykraczając poza zakres zarzutu Izba nie może odnieść się do ustanowienia dat dziennych.

W ramach rozpoznania zarzutu odwołania Izba stwierdza, że jak wskazał sam Odwołujący, że istnieje duże prawdopodobieństwo, z data podpisania umowy będzie późniejsza niż zakładana a to wpływanie na realizacji poszczególnych Zadań. Izba podkreśla, że są to jedynie przypuszczenia, nie poparte żadnym faktycznymi dowodami. Dowód 2 i 3 przedstawione przez Odwołujacego nie uzasadniają prawdopodobieństwa przesunięcia terminu zawarcia umowy. w zakresie dowodu nr 2 Izba podkreśla, że fakt na który był powołany nie został objęty zarzutem odwołania, bowiem Odwołujący nie kwestionował
‎w zarzucie ustalenia dat dziennych, nie wnosił o ich usuniecie jako takich dat dziennych –
‎a dowód został złożony na okoliczność odwołania się do braku podstaw prawnych ustalania dat dziennych dla poszczególnych zadań. W zakresie dowodu 3 podkreślić wymaga,
‎że odnosi się on do tego elementu, który został zmieniony przez Zamawiającego
‎tj. wykonania Zadania z dnia 02 01 2025 na 03 02 2025 jednocześnie zgodnie
‎z uzasadnieniem odwołania, założenia Odwołujacego oparte są na zagwarantowanym okresie przejściowym w wymiarze 3 miesięcy. Kształtowanie zarzutu odwołania w oparciu
‎o założenia uwzględnienia innego zarzutu odwołania, a konsekwencji dowodzenie zasadności podnoszonego zarzutu odwołania musi zostać uznane przez Izbę za niezasadne.

Mając powyższe na uwadze Izba stwierdza niezasadność zarzutu.

Koszty:

Izba uwzględniła odwołanie sygn. akt KIO 2105/24 w części, tj. przyjmując zgodnie
‎ze stanowiskiem wyrażony w uzasadnieniu wyroku proporcję 6 zarzutów uwzględnionych,
‎5 zarzutów odwołania nie uwzględnionych.

Izba uwzględniła odwołanie sygn. akt KIO 2125/24 w części, tj. przyjmując zgodnie
‎ze stanowiskiem wyrażony w uzasadnieniu wyroku proporcję 1 zarzut uwzględniony,
‎3 zarzuty odwołania nie uwzględnione.

Zgodnie z art. 557 ustawy z 2019 r., w wyroku oraz w postanowieniu kończącym postępowanie odwoławcze Izba rozstrzyga o kosztach postępowania odwoławczego.

O kosztach postępowania odwoławczego orzeczono na podstawie art. 557 ustawy
‎z 11 września 2019 r. Prawo zamówień publicznych oraz w oparciu o przepisy § 5 pkt 1 oraz § 7 ust. 1, § 11 rozporządzenia Prezesa Rady Ministrów z dnia 30 grudnia 2020 r. w sprawie szczegółowych rodzajów kosztów postępowania odwoławczego, ich rozliczania oraz wysokości i sposobu pobierania wpisu od odwołania (Dz. U. z 2020 r. poz. 2437), stosownie do wyniku postępowania.

Wobec powyższego orzeczono jak w sentencji wyroku.

Przewodnicząca: ………………………………

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