Wyrok Krajowej Izby Odwoławczej z 24 lipca 2024 r., sygn. KIO 2105/24

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 wykonawcyPentacomp

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 wykonawcyGISPartner

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/24wykonawcy 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 SW Z – Projektowane postanowienia umowy treści określonych w § 7 ust. 13, 14, 15, 16,

17, 18, 20, 23, 25, 29, 30 (zarzut II),

-wykreślenie punktu 4.2.6 OPZ w całości w związku tym, że brzmienie jakie przyjął nie jest wyczerpujące

(zarzut VI A, zarzut VI B),

-uzupełnienie punktu 5.3.3 OPZ przez podanie godzinowego limitu udzielanych Konsultacji w miesiącu (zarzut

XI),

-wykreślenie punktu 5.4.1. ppkt 7 OPZ oraz nakazuje wprowadzenie całego zadania w ramach Usług Rozwoju

na Zgłoszenie (zarzut XV),

-wykreślenie w Formularzu cenowym Załącznika nr 2 do OPZ (Formularz 2.2.) - Rozwój Zdefiniowany oraz w

Załączniku nr 2 do OPZ Opis wymagań

​

w zakresie Rozwoju Zdefiniowanego dat dziennych w systemie dzień/miesiąc/rok oraz

określenie terminów w dniach, tygodniach, miesiącach lub latach (jednostkach czasu) od daty zakończenia

Okresu Przejściowego (zarzut XVII),

-wykreślenie z Załącznika nr 2 do OPZ Opis wymagań w zakresie Rozwoju Zdefiniowanego postanowień 9b.

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

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

(zarzut XX).

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

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 Radomiuna rzecz wykonawcy Asseco

Poland spółka akcyjna z siedzibą w Rzeszowie kwotę 10 146,00 zł (słownie: dziesięć tysięcy sto czterdzieści

sześć złotych zero groszy) stanowiącą koszty postępowania odwoławczego poniesione przez Asseco Poland

spółka akcyjna z siedzibą w Rzeszowie stosowanie do wyniku postępowania,

5.3zasądza od Zamawiającego Centrum Informatyki Resortu Finansów w Radomiu na rzecz wykonawcyComarch

Polska spółka akcyjna z siedziba w Krakowie kwotę 4 650,00 zł (słownie: cztery tysiące sześćset pięćdziesiąt

złotych zero groszy) stanowiącą koszty postępowania odwoławczego poniesione przez Comarch Polska

spółka akcyjna z siedziba w Krakowie stosowanie do wyniku postępowania,

Na orzeczenie - w terminie 14 dni od dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby

Odwoławczej do Sądu Okręgowego w Warszawie - sądu zamówień publicznych.

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

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

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

Sygn. akt: KIO 2105/24

KIO 2125/24

U Z AS AD N I E N I E

Zamawiający – Centrum Informatyki Resortu Finansów w Radomiuprowadzi postępowanie o udzielenie

zamówienia publicznego prowadzonego w trybie przetargu nieograniczonego na „Świadczenie usług rozwoju i

utrzymania Systemu SZPROT”. Numer postępowania: PN/22/24/IATS

Publikacja ogłoszenia w Dzienniku Urzędowym Unii Europejskiej: nr wydania: Dz.U. S: 110/2024 z dnia 07 czerwca 2024

roku, Numer publikacji ogłoszenia: 337557-2024.

Sygn. akt KIO 2105/24

W dniu 17 czerwca 2024 roku Odwołujący Asseco Poland spółka akcyjna z siedzibą w Rzeszowie działając na

podstawie ustawy z dnia 11 września 2019 r. Prawo zamówień publicznych (tj. Dz.U. z 2023 r. poz. 1610 ze zm.; dalej

„PZP” lub „ustawa”) wniósł odwołanie od niezgodnych z przepisami Ustawy czynności Zamawiającego, polegających

​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 SW Z – PROJEKTOWANE POSTANOW IENIA UMOW Y (dalej: PPU) §8 ust. 4 – Wykonanie

zastępcze – Naruszenie art. 99 ust. 1 w związku z art. 16 PZP pkt 1 i 3 PZP w zw. z art. 3531 KC w zw. z art. 8

ust. 1 PZP przez opisanie przedmiotu zamówienia w sposób niejednoznaczny i niewyczerpujący, oraz w sposób

całkowicie otwarty, co prowadzi do uznania PPU w niezmienionym kształcie

​ za naruszające zasady uczciwej konkurencji oraz równego traktowania stron stosunku zobowiązaniowego

oraz uniemożliwiający skalkulowanie ceny oferty;

4)Zarzut IV: TOM III OPZ – Definicje –Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP - przez opisanie przedmiotu

zamówienia w zakresie dotyczących zobowiązań Wykonawcy w sposób otwarty, niedookreślony, uniemożliwiający

skalkulowanie oferty przez Wykonawcę.

-Zarzut IVA – Definicja Awarii,

-Zarzut IV B – Definicja Systemu,

-Zarzut IV C – Definicja Błędu;

5)Zarzut V: TOM III SWZ – OPZ punkt 3.6.20 - Naruszenie art. 99 ust. 1 w związku

​ z art. 16 PZP – przez opisanie przedmiotu zamówienia w sposób niemożliwy

​ do zrealizowania zadania, co skutkuje niemożnością przygotowania oferty;

6)Zarzut VI: TOM III SW Z – OPZ pkt. 4.2.6 – Naruszenie art. 99 ust. 1 w związku z art. 16 PZP przez opisanie

przedmiotu zamówienia w sposób niejednoznaczny

​ i niewyczerpujący, uniemożliwiający realizacje zobowiązań umownych wykonawcy

​ w zakresie „Autoryzacja zmian Systemu wykonanych przez Zamawiającego lub podmioty trzecie”, co skutkuje

niemożliwością skalkulowanie ceny oferty

-Zarzut VIA,

-Zarzut VIB;

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 SW Z – OPZ punkt 5.2.4 4) - Naruszenie art. 99 ust. 1 w związku z art. 16 PZP – przez opisanie

przedmiotu zamówienia w sposób niemożliwy

​ do oszacowania kosztu realizacji oraz w sposób niemożliwy do realizacji;

9)Zarzut IX: TOM III SWZ – OPZ punkt 5.2.5 - Naruszenie art. 99 ust. 1 w związku

​ z art. 16 PZP przez opisanie przedmiotu zamówienia w sposób niemożliwy

​ do oszacowania kosztu realizacji oraz w sposób niemożliwy do realizacji;

10)Zarzut X: Tom III SWZ – OPZ punkt 5.2.7 - Naruszenie art. 99 ust. 1 w związku

​ z art. 16 PZP przez opisanie przedmiotu zamówienia w sposób niejasny

​ i uniemożliwiający przygotowanie oferty, co skutkuje niemożnością przygotowania oferty;

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 SW Z – OPZ punkt 5.3.5 - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP – przez sporządzenie

dokumentacji postępowania w sposób niejasny, niepełny i ostatecznie uniemożliwiający oszacowanie kosztu

realizacji wymagania dotyczącego spotkań (stacjonarnych lub zdalnych);

13)Zarzut XIII: TOM III SWZ - OPZ punkt 5.4.1. 3) - Naruszenie art. 99 ust. 1 i 4 w zw.

​ z art. 16 PZP przez opisanie przedmiotu zamówienia w sposób niemożliwy

​ do oszacowania kosztu realizacji;

14)Zarzut XIV: TOM III SWZ - OPZ punkt 5.4.1 6) - Naruszenie art. 99 ust. 1 i 4 w zw.

​ z art. 16 PZP – poprzez opisanie przedmiotu zamówienia w sposób niemożliwy

​ do oszacowania kosztu realizacji wymagania dotyczącego dostosowania Systemu

​ ze względu na zmiany w Platformie Sprzętowo-Programowej;

15)Zarzut XV: TOM III SWZ – OPZ punkt 5.4.1 7) - Naruszenie art. 99 ust. 1 i 4 w zw.

​ z art. 16 PZP - przez opisanie przedmiotu zamówienia w sposób otwarty

​ i uniemożliwiający oszacowanie kosztu realizacji wymagania dotyczącego przeniesienia Systemu na nowe

bloki architektoniczne;

16)Zarzut: XVI: TOM III SW Z – OPZ pkt. 5.4.1 9) oraz pkt.5.4.3 - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP w zw.

z art. 387 KC - Opisanie przedmiotu zamówienia

​ w sposób narzucający przez Zamawiającego terminy dokonywania zmian

​ w systemie, co uniemożliwia skalkulowanie ceny oferty na etapie ofertowania,

​ a na etapie realizacji umowy - wykonanie zobowiązania;

17)Zarzut: XVII: TOM III SW Z – OPZ – Załącznik nr 2 do OPZ Rozwój Zdefiniowany oraz TOM I SW Z – IDW Formularz

cenowy nr 2.2. - Naruszenie art. art. 431 ust. 1 pkt 1 PZP przez nieprawidłowe określenie terminów wykonania

zadań w datach kalendarzowych zamiast w dniach, tygodniach, miesiącach lub latach;

18)Zarzut XVIII: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 3

(SZPROT_W FOG_4) - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP – przez opisanie przedmiotu zamówienia

w sposób uniemożliwiający oszacowanie kosztu realizacji wymagania dotyczącego dostosowania Systemu do

korzystania z serwera aplikacji WildFly w najnowszej dostępnej wersji wolnej od podatności luk bezpieczeństwa;

19) Zarzut XIX: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 6

(SZPROT_W FOG_7) - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP –przez opisanie przedmiotu zamówienia

w sposób niemożliwy

​ do oszacowania kosztu realizacji wymagania dotyczącego Rozbudowy bazy relacyjnej SZPROT oraz

wytworzenia mechanizmu utrzymującego spójność danych pomiędzy bazą danych Systemu SZPROT a bazą

danych PDR PL/UE

​ z wykorzystaniem istniejących usług PDR PL/UE;

20)Zarzut XX: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 9

(SZPROT_WFED_36_A) - Naruszenie art. 99 ust. 1 i 4

​ w zw. z art. 16 PZP – przez opisanie przedmiotu zamówienia w sposób niemożliwy do oszacowania kosztu

realizacji wymagania dotyczącego modyfikacji Komponentów Komunikacyjnych Systemu SZPROT na PUESC

(wniosków o wydanie decyzji, pozwoleń celnych), modyfikacji procesów obsługi tych wniosków, modyfikacja

rejestrów pozwoleń, formularzy oraz szablonów wydruków w Systemie, jak również odnoszone w treści punktu 9

zadania: SZPROT_W FED_3, SZPROT_W FOG_12 , SZPROT_W FOG_44 (zał. 2 do OPZ odpowiednio punkty: 48,

14, 123);

21)Zarzut XXI: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkty 9, 10,

11 (SZPROT_W FED_36_A, SZPROT_W FED_36_B, SZPROT_W FEK_32) - Naruszenie art. 99 ust. 1 i 4 w zw. z

art. 16 PZP – przez opisanie przedmiotu zamówienia w sposób niemożliwy do zrealizowania, co skutkuje

niemożnością przygotowania oferty;

22)Zarzut XXII: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 26

(SZPROT_WFOG_25) - Naruszenie art. 99 ust. 1 i 4

​ w zw. z art. 16 PZP – przez opisanie przedmiotu zamówienia w sposób niemożliwy do oszacowania kosztu

realizacji lub wręcz uznania jako niemożliwy do realizacji –

​ w zakresie wymagania dotyczącego budowy funkcjonalności konfigurowania treści prezentowanych ostrzeżeń;

23)Zarzut XXIII: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 32

(SZPROT_W FOG_31_B) - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP – przez opisanie przedmiotu

zamówienia w sposób niemożliwy do oszacowania kosztu realizacji wymagania dotyczącego dostępności

cyfrowej Komponentów Komunikacyjnych Systemu;

24)Zarzut XXIV: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 51

(SZPROT_WFED_6) - Naruszenie art. 99 ust. 1

​ i 4 w zw. z art. 16 PZP przez opisanie przedmiotu zamówienia w sposób niemożliwy do zrealizowania, co

skutkuje niemożnością przygotowania oferty;

25)Zarzut XXV: TOM III SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju Zdefiniowanego punkt 55

(SZPROT_WFED_11) Naruszenie art. 99 ust. 1

​ i 4 w zw. z art. 16 PZP – przez opisanie przedmiotu zamówienia w sposób wskazujący na realizację zadania

dotyczącego funkcjonalności wskazania ze sprawy dokumentów do udostępniania użytkownikowi zewnętrznemu wyłącznie po stronie Systemu SZPROT, co skutkuje niemożnością przygotowania oferty;

26)Zarzut XXVI: TOM III SW Z OPZ - Załącznika nr 6 do OPZ (Zasady przeprowadzania testów) pkt 1 ppkt 12 przez

opisanie przedmiotu zamówienia w zakresie Załącznika nr 6 do OPZ (Zasady przeprowadzania testów) pkt 1 ppkt

12 - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP przez opisanie w sposób niemożliwy do oszacowania kosztu

realizacji oraz w niektórych przypadkach sposób niemożliwy do realizacji.

Odwołujący wyjaśnił, że szczegółowe wskazanie okoliczności faktycznych i prawnych (zgodnie z art. 516 ust. 1 pkt 10

PZP) zarzutów odwołania zostało dokonane poniżej,

​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 SW Z w zakresie

wskazanym w odwołaniu, przez zmianę kwestionowanych treści w sposób wskazany w odwołaniu – szczegółowo w

każdym zarzucie. Obciążenie Zamawiającego kosztami postępowania odwoławczego, w tym kosztami zastępstwa

procesowego przed Krajową Izbą Odwoławczą

Odwołujący podał, ż e ma interes we wniesieniu niniejszego odwołania, gdyż wskazane w odwołaniu niezgodne z

prawem postanowienia SWZ powodują, że Odwołujący

​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ń SW Z, Odwołujący mógłby złożyć ofertę, uzyskać zamówienie

–

​a następnie należycie realizować zamówienie. Ustalenie przez Zamawiającego przedmiotowej treści SW Z uniemożliwia

Odwołującemu udział w postępowaniu. Ponadto –

​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 SW Z. Nie opisując w sposób odpowiedni przedmiotu zamówienia,

Zamawiający sam naraża się na negatywne dla niego konsekwencje faktyczne i prawne – począwszy od

nieporównywalności ofert, zawyżenia cen ofertowych wobec braku możliwości dokładnego oszacowania ryzyka, przez

problemy i spory na etapie realizacji zamówienia, aż do niekorzystnego dla Zamawiającego wyniku postępowań

sądowych” (wyrok z 5.3.2021 r., KIO 89/21).

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

zarzutach.

Ad. 1

Zarzut I: TOM I IDW - w Formularzu 3.6 „Wykaz usług” -Naruszenie art. 128 ust. 5 PZP w związku z art. 112 ust. 1

PZP – poprzez brak wymogu określenia w Formularzu 3.6 „Wykaz usług” podmiotu, który jest w posiadaniu

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

oraz kryteriów selekcji.

W Formularzu 3.6. „Wykaz usług” Zamawiający wymaga podania podmiotu, na rzecz którego wykonana była usługa, nie

określając, co należy rozumieć pod pojęciem takiego podmiotu – w szczególności nie jest wskazane, czy należy podać

rzeczywistego beneficjenta danej usługi, czy też wystarczające jest podanie podmiotu, z którym zawarta jest umowa,

nawet

​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ń SW Z,

zaś usługi świadczone na rzecz Podmiotu 1 nie spełniają wymagań SW Z. Tym samym nie można skutecznie wykazywać

spełniania warunków udziału w postępowaniu przez umowę zawartą z Podmiotem 1.

Jeśli zaś dany wykonawca twierdzi, że rzeczywistym odbiorcą systemu jest Podmiot 2, który spełnia warunek 500

użytkowników – to w wykazie usług od razu powinna być wskazana taka okoliczność i taki rzeczywisty odbiorca systemu

powinien być wskazany.

Odwołujący zidentyfikował w praktyce zamówień publicznych wskazywanie jako projekty referencyjne – projekty wykonane

w ramach podwykonawstwa, bardzo często w ramach umów zawieranych w tej samej grupie kapitałowej. Jako formalny

podmiot, na rzecz którego wykonano usługę wykonawcy wskazują spółkę z grupy kapitałowej, która nie jest użytkownikiem

systemu, która nie posiada odpowiedniej liczby użytkowników.

​A jednocześnie – ukrywany jest przed zamawiającymi rzeczywisty beneficjent, rzeczywisty użytkownik systemu.

Tym samym w Wykazie usług jedynie formalnie wykazane jest spełniania warunków udziału. A to dlatego, że podawane

informacje są całkowicie nieweryfikowalne, a wręcz nieprzydatne do stwierdzenia, czy spełniony jest warunek udziału.

Ustawa PZP nakazuje badanie relacji zamawiający (podmiot zlecający) – wykonawca (podmiot realizujący), jako relacji

rzeczywistej i opisującej realną wiedzę i kompetencje nabyte przez dany podmiot. Właśnie w celu ustalenia tej

realnej wiedzy i kompetencji nabytych przez dany podmiot konieczne jest ustalenie, czy w ogóle istnieje użytkownik

rzeczywisty, który tak użytkuje system referencyjny – że spełnione są warunki udziału,

​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 SW Z §7 Prawa własności intelektualnej zawiera m.in. wskazane niżej ustępy regulujące warunki na jakich mają być

udzielane licencje na oprogramowanie COTS

​i dokumentację. Zawierają one szczegółowe wymagania i warunki na jakich mają zostać udzielone licencje na

oprogramowanie COTS i dokumentację. Poniżej wskazane zostały ustępy zawierające warunki licencyjne z wyróżnieniem

kwestionowanych zapisów.

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.

1 4 . Tłumaczenie, przystosowywanie, zmiany układu lub wprowadzanie jakichkolwiek innych zmian w

Oprogramowaniu COTS może być dokonane przez Zamawiającego lub osobę trzecią działającą na jego rzecz.

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 COTScertyfikaty 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 SW Z – OPZ Definicja oprogramowania COTS

tj.:

Oprogramowanie typu Commercial of the Shelf Software – powszechnie dostępne oprogramowanie standardowe

wytwarzane seryjnie, dostarczane w formie gotowego zamkniętego produktu, inne niż Oprogramowanie dedykowane albo

FOSS.

stoi w bezpośredniej sprzeczności z warunkami licencyjnymi określonymi w §7 PPU.

Jak wynika z w/w definicji Oprogramowanie COTS to oprogramowanie, co do którego prawa autorskie i majątkowa

przysługują jego posiadaczom/producentom. Udzielają oni zgody

​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: “Z amawiający otrzymuje

ciągłe, stałe i niewypowiadalne prawo do korzystania

​z Oprogramowania COTS i związanej z nim dokumentacji zasadach określonych

​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órejutrzymanie

odpowiada Zamawiający,

​a na której poprawność działania i dostępność Wykonawca nie ma żadnego wpływu. Należy podkreślić, że czas usunięcia

Awarii Systemu spowodowanej błędem Platformy Sprzętowo-Programowej, pomimo, może być niewystarczający do

usunięcia Awarii przez Wykonawcę

​(4 godzin).

Odwołujący wskazał elementy definicji Awarii, które nie dotyczą zakresu obowiązków Wykonawcy:

a)„brak możliwości pobierania/przekazywania danych” – mamy tu niesprecyzowane źródło problemu. Problem może

wynikać z błędu Platformy Programowej, jak i z błędów Platformy Sprzętowo-Programowej, utrzymywanej przez

Zamawiającego. W definicji

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

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.

Zarzut IVB. Definicja Systemu

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

„System - Komponent wchodzący w skład SISC. Jeśli System zbudowany jest z Modułów, przez pojęcie System

rozumiemy cały System, jak i jego poszczególne Moduły oraz wszystkie interfejsy integracyjne. System obejmuje również

dane przez niego przetwarzane, dokumentację z nim związaną oraz wszelkie powiązane instrukcje, procedury. Jeśli nie

wskazano inaczej, należy rozumieć jako System Zintegrowanej Rejestracji Przedsiębiorców i Obsługi Wniosków

„SZPROT”.

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

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

Jak wynika z powyższej treści SIW Z Zamawiający określił System w sposób całkowicie otwarty, nie tworząc właściwie

definicji zgodnej z zasadami logiki. Definicja powinna składać się z:

definiendum – czyli wyrażenia definiowanego

definiensu - wyrażenia definiującego, tj. wyrażenia, za pomocą którego definicja informuje

​o znaczeniu wyrażenia definiowanego.

Tymczasem z definicji można wywnioskować, że System to „cały System” i jego dokumentacja. Dodatkowo definicja

zawiera warunkowość „jeśli System …” sugerująca,

​że na etapie OPZ nie wiadomo, jak zbudowany jest System. Ponieważ wykonawca

​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 SW Z – OPZ Definicje – Błąd - zawarte jest brzmienie:

Błąd Stan Systemu mogący skutkować lub

skutkujący ograniczeniem bądź brakiem realizacji dowolnej funkcji Systemu.

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

1) Awaria,

2) Błąd Blokujący,

3) Błąd Poważny,

4) Błąd Średni,

5) Błąd Drobny.

Za Błąd nie uznaje się sytuacji, w której nie działają funkcjonalności Systemu wskutek zmian w otoczeniu Systemu, jak

zmiany infrastruktury, technologii lub przepisów prawa.

Odwołujący podał, że przy obecnym brzmieniu definicji Zamawiający będzie mógł dowolne zdarzenia kwalifikować jako

Błędy – zamiast określić w SW Z przesłanki uznania zdarzeń jako Błędy. Tak sformułowana definicja powoduje, że

Wykonawca na etapie przygotowania oferty nie może nawet szacunkowo ocenić liczby występujących Błędów. Nie jest

bowiem możliwe oszacowanie, ile pojawi się Błędów wynikających ze źródeł nie zależnych

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

„1) Zamawiający zastrzega sobie prawo do realizacji zmian Systemu samodzielnie lub z pomocą podmiotów trzecich. W

takiej sytuacji, Wykonawca nie może odmówić świadczeń Usług Utrzymania Systemu w stosunku do takich zmian

Systemu, jeżeli procedura poniżej wskazana, zakończyła się podpisaniem przez Wykonawcę Raportu Autoryzacyjnego.”

Z powyższego wynika, że przedmiot umowy staje się zupełnie niedookreślony, uznaniowy

​i jednostronnie definiowany przez Zamawiającego. W ramach Autoryzacji Zamawiający może swobodnie rozszerzyć

zakres Systemu, włączając do niego dowolne aplikacje, które dotychczas nie stanowiły przedmiotu dokumentacji

Systemu. W ramach takiego rozszerzenia mogą zostać wprowadzone aplikacje w technologiach dotychczas

niewskazanych w SWZ,

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

Kalendarz dostępności: dla Systemu - 24 godziny na dzień, 7 dni w tygodniu, 365 dni w roku względnie (366 dni w roku

przestępnym). Do gwarantowanego poziomu dostępności Systemu nie jest wliczana jego niedostępność wynikająca z

przyczyn leżących po stronie Platformy Sprzętowo-Programowej Zamawiającego, w tym awarią łączy teletransmisyjnych,

awarią sprzętu komputerowego, awarią zasilania lub brakiem danych niezbędnych do odtworzenia Systemu lub

spowodowanych działaniem siły wyższej. Poziom dostępności Systemu obliczany jest wg wzoru:

(TD – Σ TN) / TD*100% [%]

gdzie:

TD – określony w minutach czas dostępności Systemu w Okresie rozliczeniowym wynikający z Kalendarza dostępności

Systemu po odjęciu uzgodnionych ograniczeń dostępności usługi (Okien serwisowych) oraz niedostępności wynikających

z przyczyn leżących po stronie Zamawiającego oraz migracji danych,

Σ TN – suma czasów w minutach niedostępności Systemu w Okresie rozliczeniowym, gdzie czasem niedostępności

Systemu jest czas, w którym w Systemie występuje Błąd w kategorii: Awaria dla którego nie dostarczono procedury

zastępczej.

Ad.8

Zarzut VIII: TOM III SWZ – OPZ punkt 5.2.4 4) - Naruszenie art. 99 ust. 1 w związku z art. 16 PZP – poprzez opisanie

przedmiotu zamówienia w sposób niemożliwy do oszacowania kosztu realizacji oraz w sposób niemożliwy do

realizacji.

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

Wykonawca ma prawo do jednokrotnego wystąpienia o uzupełnienie/ sprecyzowanie Zgłoszenia serwisowego, wówczas

czas oczekiwania na odpowiedź Zamawiającego zawiesza bieg terminów, o których mowa w ppkt 5) (zawieszenie

Zgłoszenia w CSD). Wykonawca na każdym etapie ma możliwość wystąpienia do Zamawiającego o informacje dotyczące

Zgłoszenia serwisowego, przy czym nie skutkuje to kolejnym jego zawieszeniem;

W ramach OPZ Zamawiający wymaga, aby Wykonawca na podstawie jednokrotnego wniosku o uzupełnienie był w stanie

dostarczyć rozwiązanie dla zgłaszanego Błędu. Jednocześnie Zamawiający na etapie postępowania nie wskazał żadnych

wymagań

​co do jakości zgłoszeń, w tym nie określono w SW Z minimalnej treści zgłoszenia. Skoro zamawiający przewidział

procedurę uzupełnienia zgłoszenia, zakłada, że zgłoszenia mogą być o różnym poziomie opisu, wręcz nie kompletne.

Wymaganie to zupełnie pomija fakt,

​że zgłoszenie po uzupełnieniu może okazać się zgłoszeniem nowym lub może być nadal niekompletne. Ponieważ za

poprawność zgłoszenia odpowiada Zamawiający, nie może

​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ętowoProgramowa, zatem poprawność działania Systemu zależna jest nie tylko od Wykonawcy, ale też od Zamawiającego. W

przedmiotowym pkt natomiast oczekuje się nieomylności Wykonawcy co do diagnozy Platformy Sprzętowo-Programowej,

należy nadmienić, iż na etapie postępowania nie wiadomo do jakich elementów Platformy Sprzętowo-Programowej

Wykonawca będzie miał dostęp, zatem nie jest znana możliwość diagnozy tej platformy przez Wykonawcę. Zamawiający

sam zauważa, iż Wykonawca może nie móc spełnić tego wymagania i w wymaganiu 5.4.1 ppkt. 2 gdzie zobowiązuje

Wykonawcę do informowania o nieprawidłowym działaniu Systemu ze względu na elementy Platformy SprzętowoProgramowej warunkuje już to zobowiązanie, cyt. „…o ile Wykonawca jest

​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 Systemubrak definicji i określenia zakresu komponentów technicznych, które są objęte konsultacjami. Część komponentów

dostarczana i utrzymywana jest przez Zamawiającego zgodnie z założeniem Platformy Sprzętowo-Programowej.

Wynagrodzenie z tytułu konsultacji ma charakter ryczałtowy – a zatem wykonawcy są zobowiązani określić już w ofercie

wynagrodzenie w tym zakresie. W tym celu konieczne jest określenie pełnego i zamkniętego zakresu obowiązków.

Żądanie:

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

a.Usunięcie z wymagania zwrotu „w szczególności”

b.Wskazanie godzinowego limitu konsultacji w miesiącu

lub

usunięcie całego wymagania opisanego w TOM III SWZ – OPZ punkt 5.3.3.

c) Doprecyzowanie wymagania:

a. 6) wsparcia Zamawiającego w szkoleniu Użytkowników wewnętrznych,

przez wskazanie:

i.zakresu szkoleń,

ii.planowanej ilości szkoleń,

iii.planowanych terminów lub częstotliwości szkoleń,

iv.informacji czy wymagana jest obecność zdalna czy stacjonarna.

v.rozumiane jako dyspozycyjność konsultanta w trakcie trwania szkolenia, w celu omówienia przypadków zgłaszanych

przez Uczestników lub prowadzącego szkolenie

lub

b. Usunięcie pkt 6 „6) wsparcia Zamawiającego w szkoleniu Użytkowników wewnętrznych,

d) Usunięcie z zakresu świadczonych konsultacji punktu:

a. 8). administrowania komponentami technicznymi Systemu

lub

b.Doprecyzowanie wymagania przez wskazanie zamkniętej listy komponentów technicznych, za których utrzymanie

odpowiadać będzie Wykonawca.

Ad. 12

Zarzut XII: TOM III SWZ – OPZ punkt 5.3.5 - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP – poprzez

sporządzenie dokumentacji postępowania w sposób niejasny, niepełny i ostatecznie uniemożliwiający

oszacowanie kosztu realizacji wymagania dotyczącego spotkań (stacjonarnych lub zdalnych)

Obecnie w OPZ pkt 5.3.5 zawarte jest brzmienie:

„Konsultacje mogą odbywać się zgodnie z wyborem Zamawiającego w kilkuosobowych grupach stacjonarnie w lokalizacji

wskazanej przez Zamawiającego lub zdalnie

​z zachowaniem interaktywnej formy konsultacji - o ile jest to konieczne. Uczestnicy w czasie rzeczywistym muszą widzieć i

słyszeć konsultanta, móc zadawać pytania i wyjaśniać wątpliwości. Konsultant musi udostępniać na bieżąco na ekranie

materiały konsultacyjne, w szczególności niezbędną Dokumentację Systemu. Uczestnicy muszą również widzieć i słyszeć

siebie wzajemnie. Zamawiający wymaga, aby konsultacje, zgodnie z wyborem Zamawiającego, zostały przeprowadzone z

wykorzystaniem narzędzia Teams lub innego zapewnionego przez Wykonawcę.”

W momencie składania ofert Wykonawca nie ma żadnych informacji w oparciu, o które mógłby przewidzieć ilość,

częstotliwość spotkań, konieczne do przygotowania materiały konsultacyjne oraz zakres tematyczny spotkań, a w

związku z tym kompetencje konsultanta. Tym samym Wykonawca w oparciu o tak postawione wymagania nie jest w

stanie skalkulować ceny oferty z uwagi na zupełnie nieokreślony zakres. Przedstawiane tematy spotkań mogą znacząco

wpłynąć na skład osobowy oraz czas potrzebny do przygotowania się do spotkania, składowe te mogą okazać się

znacznym kosztem. Jest to element obrazujący zupełny brak zakresu jaki ma wykonać Wykonawca. doprecyzowanie

maksymalnej liczby spotkań stacjonarnych i zdalnych w Okresie Rozliczeniowym oraz zakres merytoryczny spotkań

usunięcie wymagania – jeśli podanie powyższych danych w SWZ jest niemożliwe na obecnym etapie

Żądanie:

Odwołujący wniósł o:

1.doprecyzowanie maksymalnej liczby spotkań stacjonarnych i zdalnych w Okresie Rozliczeniowym oraz zakres

merytoryczny spotkań

lub

2.usunięcie wymagania – jeśli podanie powyższych danych w SWZ jest niemożliwe na obecnym etapie.

Ad.13

Zarzut XIII: TOM III SWZ - OPZ punkt 5.4.1. 3) - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP poprzez opisanie

przedmiotu zamówienia w sposób niemożliwy do oszacowania kosztu realizacji.

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

„3) niezwłocznego informowania Zamawiającego o nowych wersjach oprogramowania, w szczególności: Oprogramowania

COTS, Free and Open-Source Software (FOSS), Free/Libre and Open Source Software (FLOSS), wersjach

podwyższonych, wydaniach uzupełniających oraz poprawkach programistycznych i aktualizacjach w zakresie

komponentów Platformy Programowej będących Oprogramowaniem COTS, FOSS, FLOSS wraz z analizą wpływu

zainstalowania ww. elementów na działanie Systemu wraz z rekomendacją instalacji. W przypadku, gdy Zamawiający

zdecyduje o instalacji, Wykonawca zobowiązany jest do instalacji w terminie uzgodnionym z Zamawiającym,”

Rozdział 4.2 Rozwój na Zgłoszenie pkt 4.2.3

4.2.3. Zakres dokonywanych w Systemie Zmian wynikać będzie w szczególności:

1) ze zmian przepisów prawa, w szczególności w zakresie dostosowania Systemu do wymagań Unijnego Kodeksu Celnego

i Ordynacji podatkowej;

2) ze zmian metodologicznych przekazywanych przez instytucje krajowe lub zagraniczne (np. Komisję Europejską, itp.);

3) z wymagań wynikających ze współpracy Systemu z innymi systemami;

4) ze zmian postulowanych przez Użytkowników wewnętrznych lub administratorów Systemu, związanych z koniecznością

poprawy wydajności lub funkcjonalności Systemu;

5) ze zmian Platformy Sprzętowo-Programowej wykorzystywanej przez System.

Zamawiający wymaga, aby w ramach usługi Konserwacji Systemu Wykonawca instalował nowe wersje Oprogramowania

gotowego w terminie uzgodnionym z Zamawiającym. Jednocześnie Zamawiający nie określa, kto ma to oprogramowanie

dostarczyć

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

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

Dostosowanie Systemu do zmodyfikowanego oprogramowania odbywać się będzie w ramach Rozwoju na

Zgłoszenie na zasadach określonych punkcie 4.2.”

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 SW Z 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 SZPROTzostanie 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 OPZOpis 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_W FOG_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_W FED_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 SW Z 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 SW Z ż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ą SW Z 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 SW Z

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 SW Z „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 SW Z 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 SW Z 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 SW Z

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 SW Z. Zamawiający

przekaże każdemu Wykonawcy dokumentację w tożsamym brzmieniu.

2.Wniosek Wykonawcy o wydanie części SW Z, 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 SW Z 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 SW Z” 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ęść SW Z, o której mowa w pkt 1, pozostaje bez wpływu na termin

składania ofert.

6.Część SW Z, 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ęść SW Z, 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 SW Z, 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ÓW IENIA

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 SW Z 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 SW Z 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ł SW Z 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ściowywyłą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ą SW Z 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ł SW Z 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 SW Z 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 SW Z 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:

I.

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 SW Z. 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ę SW Z. 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 SW Z nadal naruszają przepisy PZP. W związku z czym Odwołujący zmuszony

jest wnieść kolejne odwołanie, na nową treść SW Z – 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 SW Z objętych

zarzutami II, IVA, VIA, VIB, X, XI, XVI, XX.

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

Zmiana SW Z 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 SW Z 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.Awyłą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: „SW Z”) – 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 SW Z – 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 SW Z 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 XXV

I 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 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 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 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 zarzutu 1 z uwagi na jego 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 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).

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

V.

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:

Usługa potwierdzająca

Nazwa

Podmiot, na

rzecz

Okres realizacji

Lp.

spełnienie warunku udziału w

postępowaniu,

​o którym mowa w IDW

Wykonawcy

usługi

którego

wykonana

była usługa

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 SW Z. Jednoznacznie podaje Zamawiający w punkcie 10.7.SW Z, ż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 SW Z – PROJEKTOWANE POSTANOW IENIA UMOW Y (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

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. 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 SW ZOpis przedmiotu zamówienia, zwany dalej: OPZ na „Świadczenie usług rozwoju i utrzymania Systemu

SZPROT”

Oprogramowanie COTS

Oprogramowanie typu Commercial of the Shelf Software – powszechnie dostępne oprogramowaniestandardowe

wytwarzane seryjnie, dostarczane w formie gotowego zamkniętego produktu, inne niż Oprogramowanie dedykowane albo

FOSS

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ówtych 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.

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

Izba ustaliła:

TOM III SW ZOpis 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.

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.

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

Błąd regresji

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

TOM III SW ZOpis 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

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.

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

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

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ętowoProgramowej 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 PW N), 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 SW Z – OPZ pkt. 4.2.6 – Naruszenie art. 99 ust. 1 w związku z art. 16

PZP przez opisanie przedmiotu zamówienia

​w sposób niejednoznaczny i niewyczerpujący, uniemożliwiający realizacje zobowiązań umownych wykonawcy w zakresie

„Autoryzacja zmian Systemu wykonanych przez Zamawiającego lub podmioty trzecie”, co skutkuje niemożliwością

skalkulowanie ceny oferty -Zarzut VIA – Izba zarzut uznała za zasadny.

Oraz

W zakresie zarzutu VI B -Zarzut VI: TOM III SW Z – OPZ pkt. 4.2.6 – Naruszenie art. 99 ust. 1 w związku z art. 16

PZP przez opisanie przedmiotu zamówienia

​w sposób niejednoznaczny i niewyczerpujący, uniemożliwiający realizacje zobowiązań umownych wykonawcy w zakresie

„Autoryzacja zmian Systemu wykonanych przez Zamawiającego lub podmioty trzecie”, co skutkuje niemożliwością

skalkulowanie ceny oferty -Zarzut VIA – 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.

Izba ustaliła:

TOM III SW ZOpis 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 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 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.

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.

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

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

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:

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

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 SW Z. 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

SW Z czy też planuje rozszerzenie ponad wymagania SW Z, 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 SW Z – OPZ punkt 5.2.4 4) - Naruszenie art. 99 ust. 1 w związku z art.

16 PZP – przez opisanie przedmiotu zamówienia w sposób niemożliwy do oszacowania kosztu realizacji oraz w sposób

niemożliwy do realizacji; – 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. 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.

Izba ustaliła:

TOM III SW ZOpis 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;

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:

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 SW Z – 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.

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

Izba ustaliła:

TOM III SW ZOpis 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ę,

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.

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:

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 SW Z - 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.

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

Izba ustaliła:

TOM III SW ZOpis 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 4letnie 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 SW Z – 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.

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

Izba ustaliła:

TOM III SW ZOpis 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 SW Z – IDW Formularz cenowy nr 2.2. - Naruszenie art. art. 431 ust. 1 pkt 1 PZP

przez nieprawidłowe określenie terminów wykonania zadań w datach kalendarzowych zamiast w dniach, tygodniach,

miesiącach lub latach – 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 RozwojuZdefiniowanego, 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 RozwojuZdefiniowanego 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 SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju

Zdefiniowanego punkt 6 (SZPROT_W FOG_7) - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP – przez opisanie

przedmiotu zamówienia w sposób niemożliwy do oszacowania kosztu realizacji wymagania dotyczącego Rozbudowy

bazy relacyjnej SZPROT oraz wytworzenia mechanizmu utrzymującego spójność danych pomiędzy bazą danych

Systemu SZPROT a bazą danych PDR PL/UE z wykorzystaniem istniejących usług PDR PL/UEIzba

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

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.

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.

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 SW Z – OPZ Zał. 2 do OPZ – Opis wymagań w zakresie Rozwoju

Zdefiniowanego punkt 9 (SZPROT_W FED_36_A) - Naruszenie art. 99 ust. 1 i 4 w zw. z art. 16 PZP – przez opisanie

przedmiotu zamówienia w sposób niemożliwy do oszacowania kosztu realizacji wymagania dotyczącego modyfikacji

Komponentów Komunikacyjnych Systemu SZPROT na PUESC (wniosków o wydanie decyzji, pozwoleń celnych),

modyfikacji procesów obsługi tych wniosków, modyfikacja rejestrów pozwoleń, formularzy oraz szablonów wydruków w

Systemie, jak również odnoszone w treści punktu 9 zadania: SZPROT_W FED_3, SZPROT_W FOG_12 ,

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

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

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

(…)

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

(…)

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.

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 w następujący sposób:

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.

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

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_W FED_36_A_2.Podkreślenia

wymaga,

​że rozdzielenie zadań, a w zasadzie wydzielenie z zadania podstawowego zadania 9a. SZPROT_W FED_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.

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

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

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

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

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 SW Z 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.

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 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 SW Z, w tym w OPZ, stanowiącym Tom III SW Z, 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 SW Z 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 SW Z pełnej dokumentacji Systemu SZPROT oraz kodów

źródłowych.

Podkreślenia wymaga w ocenie Izby, że nieudostępnienie w SW Z 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 SW Z 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 SW Z 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 SW Z 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 SW Z, 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 SW Z 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. 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.

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

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

TOM III SW ZOpis 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 SW Z 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 SW ZOpis 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ławykreś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:

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

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

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.

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

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

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