KIO 4174/25

Sygn. akt: KIO 4174/25

WYROK

Warszawa, dnia 7 listopada 2025 r.

Krajowa Izba Odwoławcza - w składzie:

Przewodnicząca: Danuta Dziubińska

Protokolantka: Wiktoria Ceyrowska

po rozpoznaniu na rozprawie odwołania wniesionego do Prezesa Krajowej Izby Odwoławczej w dniu 29 września 2025 r. przez wykonawcę SIMPLE Spółka Akcyjna z siedzibą w Warszawie w postępowaniu prowadzonym przez Wojewódzki Szpital Specjalistyczny we Wrocławiu

orzeka:

1.umarza postępowanie w zakresie zarzutów oznaczonych w odwołaniu: nr 1 litera a tiret pierwszy i trzeci, nr 1 litera c, nr 2, nr 4, nr 5, nr 8, nr 9, nr 10;

2. uwzględnia odwołanie w zakresie zarzutu numer 3 i nakazuje zamawiającemu wprowadzenie do Specyfikacji Warunków Zamówienia postanowień wskazujących na jego udział na własny koszt przy pozyskaniu informacji, które są niezbędne dla przeprowadzenia przewidzianej w ust. 4.2. Opisu przedmiotu zamówienia integracji zamawianego systemu z wskazanymi w tym zakresie systemami, od producentów posiadanych systemów;

3. oddala odwołanie w pozostałym zakresie;

4.kosztami postępowania obciąża odwołującego w 5/6 i zamawiającego w 1/6:

4.1.zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr (piętnaście tysięcy złotych zero groszy) uiszczoną przez odwołującego tytułem wpisu od odwołania, 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) tytułem wynagrodzenia pełnomocnika zamawiającego, 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) tytułem wynagrodzenia pełnomocnika odwołującego;

4.2.zasądza od zamawiającego - Wojewódzkiego Szpitala Specjalistycznego we Wrocławiu na rzecz odwołującego - SIMPLE Spółka Akcyjna z siedzibą
‎w Warszawie kwotę 100 zł 00 gr (sto złotych zero groszy), tytułem zwrotu części uiszczonych kosztów postępowania odwoławczego.

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 4174/25

Uzasadnienie

Wojewódzki Szpital Specjalistyczny we Wrocławiu (dalej: „Zamawiający”) prowadzi w trybie przetargu nieograniczonego, na podstawie ustawy z 11 września 2019 r. - Prawo zamówień publicznych (dalej: „ustawa Pzp”), postępowanie o udzielenie zamówienia publicznego pn. „Dostawa Szpitalnego Systemu Informatycznego klasy ERP wraz z usługą wdrożenia, udzieleniem licencji, świadczeniem usług gwarancji, nadzoru autorskiego i serwisu oraz szkoleniem użytkowników - POWTÓRKA (Szp-241/FZ-010A/2025)”.

Ogłoszenie o zamówieniu zostało opublikowane 18 września 2025 r. w Dzienniku Urzędowym Unii Europejskiej pod nr 610784-2025 (zmienione 22 września 2025 r. nr ogłoszenia: 617861-2025) oraz na stronie internetowej Zamawiającego.

Wykonawca SIMPLE Spółka Akcyjna (dalej: „Odwołujący”) wniósł odwołanie wobec postanowień Specyfikacji Warunków Zamówienia (dalej: „SWZ”), w którym zarzucili Zamawiającemu naruszenie przepisów:

1) art. 112 ust. 1 w zw. z art. 16 ustawy Pzp przez określenie w rozdz. VIII ust. 1 pkt 4 lit. a i b SWZ warunków udziału w postępowaniu:

a) odnoszących się do zdolności technicznych wykonawcy związanych z wykonaniem, w okresie pięciu lat przed upływem terminu składania ofert co najmniej jednego wdrożenia zaoferowanego systemu klasy ERP w podmiocie leczniczym, który zatrudnia co najmniej 1000 osób, w zakresie w jakim:

-przedmiotowy warunek odwołuje się do wdrożenia „zaoferowanego” systemu klasy ERP, w sytuacji w której, oferowany system jest systemem jaki ma zostać skonfigurowany, sparametryzowany i skastomizowany dla Zamawiającego, co oznacza, że referencyjny system jaki spełniać miałby przedmiotowy warunek, musiałby być identycznym systemem jaki zamawia Zamawiający (według jego własnych potrzeb), co - poza obiektywną niemożliwością spełniania tego wymagania - stanowi wymaganie oczywiście nieproporcjonalne w zakresie, w jakim warunek udziału w postępowaniu badać ma minimalny poziom zdolności wykonawcy umożliwiający wykonanie zamówienia,

-przedmiotowy warunek odwołuje się do wdrożenia systemu ERP w podmiocie leczniczym, w sytuacji w której, mając na uwadze cechy i przeznaczenie zamawianego systemu oraz jego rodzaj (typ), dla zbadania minimalnego poziomu zdolności wykonawcy umożliwiającego wykonanie zamówienia, irrelewantnym jest, czy podmiot, na którego rzecz wdrożono referencyjny system (składający się co najmniej z modułów finanse-księgowość oraz kadry–płace), był podmiotem leczniczym, co wskazuje na nieproporcjonalność warunku,

-przedmiotowy warunek odwołuje się do wymagania zatrudnienia co najmniej 1000 osób w podmiocie, w którym wdrożony został referencyjny system ERP, w sytuacji w której, mając na uwadze cechy i przeznaczenie zamawianego systemu oraz jego rodzaj (typ), dla zbadania minimalnego poziomu zdolności wykonawcy umożliwiającego wykonanie zamówienia, irrelewantną jest sama liczba osób zatrudnionych w podmiocie, w którym wdrażano referencyjny system, co wskazuje na nieproporcjonalność warunku,

b)co do zdolności technicznych wykonawcy związanych ze świadczeniem co najmniej dwóch usług (na rzecz różnych podmiotów leczniczych) obejmujących utrzymanie systemu, w zakresie w jakim przedmiotowy warunek:

-odwołuje się do świadczenia usług na rzecz podmiotów leczniczych, w sytuacji w której, mając na uwadze cechy i przeznaczenie systemu jaki w ramach zamówienia ma być utrzymywany (jego rodzaj/typ), dla zbadania minimalnego poziomu zdolności wykonawcy umożliwiającego wykonanie zamówienia, irrelewantnym jest, czy podmiot na którego rzecz świadczono usługi utrzymania był podmiotem leczniczym, co wskazuje na nieproporcjonalność warunku,

-wymaga doświadczenia dwóch usług na rzecz dwóch różnych podmiotów, w sytuacji w której już wykonanie jednej takiej usługi pozwala na stwierdzenie, że wykonawca daje rękojmię należytego wykonania zamówienia, a ponadto, dla ustalenia takiej rękojmi irrelewantnym jest podmiot dla którego wykonano usługi, a także, czy był to ten sam czy różny podmiot;

c)co do zdolności zawodowej wykonawcy związanych z dysponowaniem Kierownikiem Projektu, który musi posiadać doświadczenie kierowania projektem wdrożenia systemu klasy ERP, w co najmniej jednym podmiocie leczniczym, który zatrudnia nie mniej niż 500 osób, w zakresie w jakim przedmiotowy warunek:

-odwołuje się do wdrożenia systemu ERP w podmiocie leczniczym, w sytuacji w której, mając na uwadze cechy i przeznaczenie zamawianego systemu oraz jego rodzaj (typ), dla zbadania minimalnego poziomu zdolności osoby kierowanej do realizacji zamówienia, irrelewantnym jest, czy podmiot na którego rzecz realizowano wspomniane wdrożenie, był podmiotem leczniczym, co wskazuje na nieproporcjonalność warunku,

-przedmiotowy warunek odwołuje się do wymagania zatrudnienia co najmniej 500 osób w podmiocie na rzecz którego wdrażano system, w sytuacji w której, mając na uwadze cechy i przeznaczenie zamawianego systemu oraz jego rodzaj (typ), dla zbadania minimalnego poziomu zdolności osoby kierowanej do realizacji zamówienia, irrelewantnym jest, sama liczba osób zatrudnionych w podmiocie w którym system wdrażano, co wskazuje na nieproporcjonalność warunku,

d)co do zdolności zawodowej wykonawcy związanych z dysponowaniem Specjalistą ds. Infrastruktury Techniczno-Systemowej (ITS), który miał brać udział w co najmniej 2 projektach informatycznych związanych z wdrożeniem systemu klasy ERP, w których był odpowiedzialny za instalację i konfigurację infrastruktury techniczno-systemowej, w zakresie w jakim przedmiotowy warunek wymaga udziału w dwóch projektach, w sytuacji której udział już w jednym projekcie daje rękojmię należytego wykonania zamówienia i w tym zakresie warunek jest nieproporcjonalny

2)art. 99 ust. 1 w zw. z art. 106 i 107 w zw. z art. 16 ustawy Pzp przez wymaganie w rozdz. XVI ust. 1 pkt 2 SWZ złożenia wraz z ofertą (jako przedmiotowego środka dowodowego) dokumentu potwierdzającego możliwość integracji oferowanego systemu ERP z system AMMS oraz innymi systemami Zamawiającego w zakresie określonym w OPZ, w sytuacji w której system AMMS oraz inne systemy Zamawiającego opisane w OPZ stanowią systemy informatyczne określonych producentów, które posiada Zamawiający i dla należytego wykonania zamówienia, to Zamawiający powinien zapewnić możliwość przeprowadzenia wspomnianej integracji, gdyż w konkurencyjnym postępowaniu, Zamawiający nie może wymagać od wykonawców współpracy z podmiotami innymi niż sam Zamawiający, zwłaszcza podmiotami konkurencyjnymi do wykonawcy, zainteresowanymi pozyskaniem przedmiotowego zamówienia,

3)art. 99 ust. 1 w zw. z art. 16 ustawy Pzp przez ustanowienie w ust. 4.2 Załącznika nr 8 do SWZ - Opisie przedmiotu zamówienia (dalej: „OP”Z) wymagania w zakresie zintegrowania zamawianego systemu z systemami posiadanymi przez Zamawiającego (system AMMS oraz inne systemy Zamawiającego w zakresie określonym w OPZ), bez zapewnienia przez Zamawiającego współpracy producentów wspomnianych systemów z wykonawcą zamówienia, a także bez opisania w OPZ cech i parametrów tych systemów niezbędnych do przeprowadzenia takiej integracji oraz przy nałożeniu na wykonawcę obowiązku nawiązania współpracy z tymi producentami, w sytuacji w której system AMMS oraz inne systemy Zamawiającego opisane w OPZ stanowią systemy informatyczne określonych producentów, które posiada Zamawiający i dla należytego wykonania zamówienia, to Zamawiający powinien zapewnić możliwość przeprowadzenia wspomnianej integracji oraz zapewnić możliwość pozyskania wszystkich niezbędnych ku temu danych, gdyż w konkurencyjnym postępowaniu, Zamawiający nie może wymagać od wykonawców współpracy z podmiotami innymi niż sam Zamawiający, zwłaszcza podmiotami konkurencyjnymi do wykonawcy, zainteresowanymi pozyskaniem przedmiotowego zamówienia, bowiem to Zamawiający odpowiada za pełne sporządzenie opisu przedmiotu zamówienia, a wykonawcy nie mogą być obciążeni samodzielną weryfikacją przedmiotu i zakresu zamówienia;

4)art. 99 ust. 1 w zw. z art. 16 ustawy Pzp przez ustanowienie w ust. 4.2 Załącznika nr 8 do SWZ - Opisie przedmiotu zamówienia (OPZ) wymagania zapewnienia integracji z obecnie posiadanym systemem EZD PUW, przy zastrzeżeniu możliwości zmiany przez Zamawiającego tego systemu na system EZD RP (z którym również zintegrowany być musi zamawiany system), bez gwarancji czy obydwa systemy będą działały w taki sam sposób, na takich samych zasadach, a możliwości integracyjne w nowym systemie będą identyczne jak w obecnie posiadanym przez Zamawiającego (tj. EZD PUW);

5)art. 99 ust. 1 w zw. z art. 106 i 107 w zw. z art. 16 ustawy Pzp przez wymaganie w rozdz. XVI ust. 1 pkt 4 SWZ w zw. z Załącznikiem nr 10 do SWZ przygotowania próbki oferowanego systemu w zakresie procesu dot. Wniosku urlopowego:

a)który jest konfiguracją wdrożeniową zależną od instrukcji obiegu dokumentów, a modelowanie tego procesu jest elementem właściwym dla realizacji zamówienia (analizy przedwdrożeniowej), a wykonawcy, na etapie przygotowanie oferty nie mają możliwości pozyskania danych gwarantujących prawidłowość działania tej funkcjonalności, co daje też duże pole do nadużyć przy ocenie spełnienia tego wymagania,

b)gdy zakres próbki w tym obszarze (zakres wymaganych do przedstawienia funkcjonalności) wykracza poza możliwość zaprezentowania go w 10-15 min (zgodnie z wymaganiami Zamawiającego),

6)art. 99 ust. 1 w zw. z art. 16 ustawy Pzp przez ustanowienie w Załączniku nr 9 do SWZ – Zestawieniu funkcjonalności (zakładka „Lista funkcjonalności”), wymagania zgodnie z którym 584 na 1157 funkcjonalności obowiązkowych zamawianego systemu, oraz wybrane funkcjonalności opcjonalne, muszą być dostępne na moment złożenia oferty (co wykonawca ma potwierdzić wypełniając kolumny oznaczone jako [pisownia oryginalna] „DOSTAWCA POSIADANA FUNKCJONALNOŚĆ”, „DOSTAWCA DOSTARCZY FUNKCJONALNOŚĆ DO TERMINU WDROŻENIA”, „POZYCJA ZE SPECYFIKI DOSTAWCY” Załącznika nr 9 do SWZ), w sytuacji, w której, oferowany system jest systemem jaki ma zostać skonfigurowany, sparametryzowany i skastomizowany dla Zamawiającego, a tym samym, wprowadzenie takiego wymagania:

a)stanowi wymaganie spełnienia znacznej części zamawianego świadczenia przed wyborem oferty danego wykonawcy jako najkorzystniejszej,

b)nie jest możliwe do spełnienia ze względu m.in. na inne wymagania Zamawiającego związane z realizacją przedmiotu zamówienia w zakresie konfiguracji systemu, które wymagają pozyskania wiedzy na etapie Analizy przedwdrożeniowej (stanowiącej etap realizacji zamówienia), determinujące sposób w jaki sposób wykonawca zrealizuje wymagane funkcjonalności,

c)wypełnienie pozycji „POZYCJA ZE SPECYFIKI DOSTAWCY” nie jest obecnie możliwe bowiem ofertowany system ma dopiero zostać skonfigurowany, sparametryzowany i skastomizowany dla Zamawiającego (nie istnieje więc „POZYCJA ZE SPECYFIKI DOSTAWCY” dla tych funkcjonalności), a co więcej, Zamawiający nie określił w SWZ w jakim stopniu szczegółowości te informacje mają zostać podane. Ponadto, narzędziem jakie Zamawiającemu ma służyć w celu potwierdzenia zgodności oferty z dokumentami zamówienia (w zakresie najważniejszych funkcjonalności) jest próbka systemu;

7)art. 99 ust. 1 w zw. z art. 16 ustawy Pzp przez ustanowienie w Załączniku nr 9 do SWZ - Zestawieniu funkcjonalności (zakładka „Lista funkcjonalności”) listy wymagań funkcjonalnych z różnymi terminami ich dostępności (tj. „dzień złożenia oferty” i „termin wdrożenia modułu”), w sytuacji w której różne elementy (funkcjonalności systemu) są ze sobą ściśle powiązane i działają one z dużą wzajemną zależnością, a konfiguracja jednej funkcjonalności wpływa na dostępność drugiej, co w praktyce prowadzi do tego, że wszystkie funkcjonalności realnie dostępne będą dla Zamawiającego na moment startu produkcyjnego systemu (wcześniej i tak nie będzie mógł z nich korzystać), a wymaganie dostępności funkcjonalności na etapie składania ofert, czy nawet wdrożenia jest w rzeczywistości wymaganiem iluzorycznym, sztucznym oraz oderwanym od specyfiki zamówienia,

8)art. 99 ust. 1 w zw. z art. 16 ustawy Pzp przez ustanowienie w Załączniku nr 9 do SWZ w szczególności wymagań poz. 465, 531, 553 i 554 mających na celu wyłącznie pozbawienie możliwości ubiegania się o zamówienie dotychczasowych dostawców zamawianego rozwiązania, zgodnie z którymi:

a) zamawiany system jako całość musi być wykonany w konkretnej technologii - w architekturze trójwarstwowej (czyli technologii klient <-> serwer aplikacji <-> baza danych, dane są przechowywane w modelu relacyjnym baz danych z wykorzystaniem aktywnego serwera baz danych):

-pomimo, iż ustanowienie takiego wymagania nie ma żadnego uzasadnienia funkcjonalnego i z punktu widzenia potencjalnych grup użytkowników tego systemu, co najmniej równoważnym rozwiązaniem jest oprogramowanie pracujące w technologii dwuwarstwowej,

-ustanowienie takiego wymagania uniemożliwia złożenie oferty tym Wykonawcom, których system oparty jest na architekturze dwuwarstwowej (tzw. „gruby klient”), mimo, że z punktu widzenia jakościowego czy funkcjonalnego, takie rozwiązanie nie jest gorsze niż rozwiązanie oparte na architekturze trójwarstwową, co ogranicza znacznie krąg potencjalnych Wykonawców mogących ubiegać się o to zamówienie,

b) interfejs użytkownika jak i administratora musi być zgodny z wytycznymi WCAG w wersji aktualnej na dzień odbioru produktu (obecnie jest to wersja 2.2) w sytuacji w której wytyczne WCAG (Web Content Accessibilty Guidelines) odnoszą się do treści dostępnych za pośrednictwem stron internetowych udostępnianych/publikowanych przez Zamawiającego w ogólnodostępnej sieci Internet, i co do zasady nie dotyczą rozwiązań desktopowych które służą realizacji procesów wewnętrznych Zamawiającego,

c) wszystkie moduły systemu muszą działać w oparciu o jeden motor bazy danych oraz wszystkie moduły systemu ERP muszą pochodzić od jednego producenta, w sytuacji w której te wymagania nie przekładają się w żaden sposób na warstwę użytkową zamawianego systemu i dotyczą specyfiki rozwiązań stosowanych przez konkretnych wykonawców, a wprowadzenie tych wymagań wyłącznie ogranicza konkurencję, eliminując możliwość zaoferowania rozwiązań wpisujących się w potrzeby Zamawiającego,

9)art. 99 ust. 1 w zw. z art. 16 ustawy Pzp przez ustanowienie w Załączniku nr 9 do SWZ nieprecyzyjnych i niejednoznacznych wymagań lub wymagań niepodyktowanych uzasadnionymi potrzebami Zamawiającego, uregulowanych w poz. 468, 84, 604, 613, 614, 687, 797 – 801, 278, 395, 519, 520, 540, 1178, 895, 1117, 1144 w zakresie szczegółowo omówionym w uzasadnieniu odwołania,

10)art. 433 pkt 2 i 3, 434 ust. 1, w zw. z art. 99 ust. 1 w zw. z art. 16 w zw. z art. 8 ustawy Pzp w zw. z art. 5 w zw. z art. 353(1) w zw. z art. 627 w zw. z art. 632 k.c. wyrażające się w ustanowieniu w załączniku nr 2 do SWZ - Projekcie Umowy postanowień §7 ust. 2, § 6 ust. 11,  § 13, zgodnie z którymi, Zamawiający nadużywając swojej dominującej pozycji, ustanawia niedozwolone na gruncie przepisów ustawy Pzp klauzule umowne, w tym obciążające wykonawcę ryzykami, których wykonawca nie może przewidzieć na etapie sporządzania oferty, a związanymi z nieopisaniem przez Zamawiającego przedmiotu zamówienia w sposób prawidłowy i kompletny.

Wskazując na powyższe zarzuty, Odwołujący wniósł o uwzględnienie odwołania i nakazanie Zamawiającemu dokonania czynności modyfikacji dokumentacji postępowania, tj.:

a) zmiany warunku udziału w postępowaniu, o którym mowa w rozdz. VIII ust. 1 pkt 4 lit. a SWZ przez:

-usunięcie z opisu warunku słowa „zaoferowanego” w kontekście referencyjnego systemu klasy ERP jaki miał być wdrożony przez wykonawcę ubiegającego się o zamówienie, a ponadto:

-usunięcie z opisu warunku wymagania wdrożenia referencyjnego systemu klasy ERP na rzecz podmiotu leczniczego,

-usunięcie z opisu warunku wymagania dotyczącego liczby pracowników zatrudnionych w podmiocie w którym wdrażany był referencyjny system,

-usunięcie z opisu warunku wymagania świadczenia usług utrzymania systemu informatycznego klasy ERP na rzecz podmiotu leczniczego oraz wymagań świadczenia usług na rzecz co najmniej dwóch podmiotów oraz świadczenia usług na rzecz co najmniej dwóch różnych podmiotów,

b) zmiany warunku udziału w postępowaniu, o którym mowa w rozdz. VIII ust. 1 pkt 4 lit. b SWZ przez:

-usunięcie z opisu warunku dot. doświadczenia Kierownikiem Projektu wymagania kierowania wdrożeniem na rzecz podmiotu leczniczego oraz wymagania w zakresie liczby pracowników zatrudnionych w podmiocie na rzecz którego wdrożenie było realizowane,

-usunięcie z opisu warunku dot. doświadczenia Specjalisty ds. Infrastruktury Techniczno-Systemowej(ITS), wymagania udziału w dwóch referencyjnych projektach informatycznych,

c)usunięcia wymagania opisanego w rozdz. XVI ust. 1 pkt 2 SWZ dot. złożenia wraz z ofertą przedmiotowego środka dowodowego – tj. dokumentu potwierdzającego możliwość integracji oferowanego Systemu ERP z system AMMS oraz innymi systemami Zamawiającego w zakresie określonym w OPZ,

d)zmiany ust. 4.2. OPZ przez:

-wprowadzenie do SWZ oraz wzoru Umowy zapewnienia, że Zamawiający pozyska (z wyłączeniem systemów/rejestrów publicznych) we własnym zakresie i na własny koszt wszelkie umożliwiające przeprowadzenie integracji informacje i dane od producentów lub autorów eksploatowanych systemów, z którymi ma nastąpić integracja, a także zapewni na własny koszt wsparcie tych producentów w przypadku problemów z przeprowadzeniem integracji, jak również zapewni wsparcie przy procesie testowania integracji,

-przedstawienie zakresu czynności jakie ma zrealizować Wykonawca oraz Zamawiający, aby można było uznać, że zostały spełnione wymagania w zakresie integracji,

e)zmiany ust. 4.2. OPZ przez usunięcie wymagania integracji zamawianego systemu także z systemem EZD RP,

f)zmiany ust. 4.2 OPZ przez wprowadzenie postanowień określających odpowiedzialność Zamawiającego w zakresie:

-zlecenia prac w zakresie integracji do producentów systemu/ oprogramowania integrującego,

-aktywnego udziału Zamawiającego w ustaleniach pomiędzy Wykonawcą a producentami systemu / oprogramowania integrującego,

g)zmiany Załącznika nr 10 do SWZ przez wykreślenie wymagania prezentacji procesu Akceptacji wniosku urlopowego pracownika lub modyfikację tego wymagania przez wybór tych funkcjonalności do zaprezentowania, które możliwe będą do zaprezentowania bez konieczności wykonania prac analitycznych właściwych realizacji zamówienia oraz możliwe będą do zaprezentowania w rygorach czasowych narzuconych przez Zamawiającego,

h)zmiany Załącznika nr 9 do SWZ - Zestawienie funkcjonalności przez całkowite usunięcie postanowień w zakresie terminu realizacji wymagania jako oznaczonych „dzień złożenia oferty” dla wszystkich funkcjonalności oraz usunięcie następujących kolumn z tego Załącznika: „DOSTAWCA POSIADANA FUNKCJONALNOŚĆ”, „DOSTAWCA DOSTARCZY FUNKCJONALNOŚĆ DO TERMINU WDROŻENIA”, „POZYCJA ZE SPECYFIKI DOSTAWCY”,

i)zmiany Załącznika nr 9 do SWZ - Zestawienie funkcjonalności przez ujednolicenie postanowień w zakresie terminów realizacji i wprowadzenie postanowienia, zgodnie z którym wszystkie funkcjonalności mają być dostępne na moment startu produkcyjnego,

j)usunięcia wymagania poz. 465 Załącznika nr 9 do OPZ i przywrócenie postanowienia z poprzednio prowadzonego postępowania, nienarzucającego stosowania technologii trójwarstwowej,

k)usunięcia wymagań poz. 531, 553 i 554 Załącznika nr 9 do SWZ,

l)zmodyfikowania poz. 468, 84, 604, 613, 614, 687, 797 – 801, 278, 395, 519, 520, 540, 1178, 895, 1117, 1144 Załącznika nr 9 do SWZ w zakresie omówionym w uzasadnieniu odwołania,

m)wykreślenia postanowień §7 ust. 2 i § 6 ust. 11 oraz § 13 z załącznika nr 2 do SWZ - Projektu umowy.

Zamawiający w piśmie z 31 października 2025 r., zawierającym odpowiedź na odwołanie, podał, że uznaje zasadność odwołania w części i dokonuje zmiany SWZ w zakresie:

1. określenia warunków udziału w postępowaniu w postępowaniu w zakresie zdolności technicznej poprzez zmianę ust. 1 pkt. 4) lit. a Rozdziału VIII - WARUNKI UDZIAŁU W POSTĘPOWANIU poprzez nadanie mu następującego brzmienia: „zdolności technicznej lub zawodowej tzn.

a) zdolność techniczna

1) Wykonawca spełni warunek, jeśli wykaże, że w okresie ostatnich pięciu latach przed upływem terminu składania ofert, a jeżeli okres prowadzenia działalności jest krótszy w tym okresie, wykonał należycie lub wykonuje (Zamawiający wymaga spełnienia wszystkich niżej wymienionych warunków):

- co najmniej jedno wdrożenie zaoferowanego Systemu klasy ERP (przy czym Zamawiający nie wymaga w tym zakresie wdrożenia Systemu klasy ERP w konfiguracji, parametryzacji, kastomizacji jak wymagana przez Zamawiającego w ramach niniejszego postępowania) w podmiocie leczniczym, który zatrudnia co najmniej 500 osób. Wdrożony System musi składać się co najmniej z modułów finanse - księgowość oraz kadry płace z pełną integracją tych modułów. - co najmniej jedną prawidłową migrację danych do oferowanego programu.

- świadczenie co najmniej dwóch usług (na rzecz różnych podmiotów leczniczych) obejmujących utrzymanie systemu, a więc zarówno nadzór autorski jak i usługi serwisu (w tym usługi rozwojowe) trwających co najmniej 3 ostatnie lata (wymóg dotyczy całego okresu świadczenia usług, usługi nie muszą być świadczone na podstawie jednej umowy. W przypadku kilku umów wymaga się, aby nie występowały pomiędzy nimi przerwy przekraczające 30 dni). Usługi muszą być wykonywane na rzecz podmiotów leczniczych zatrudniających co najmniej 500 osób, system, którego dotyczy utrzymanie musi składać się co najmniej z modułów finanse - księgowość oraz kadry - płace,”

2. określenia warunków udziału w postępowaniu w postępowaniu w zakresie zdolności zawodowej poprzez zmianę ust. 1 pkt 4 lit. b w zakresie dotyczącym wymogów przewidzianych dla Kierownika Projektu Rozdziału VIII - WARUNKI UDZIAŁU W POSTĘPOWANIU poprzez nadanie mu brzmienia:

„Wykonawca spełni warunek, jeśli wykaże, że dysponuje lub będzie dysponował i wyznacza na czas realizacji zamówienia:

- Kierownika Projektu ze strony Wykonawcy, który musi spełniać następujące warunki:

- Posiadać wykształcenie wyższe,

- Kierownik Projektu realizujący przedmiot zamówienia musi posiadać doświadczenie kierowania projektem wdrożenia Systemu klasy ERP, w co najmniej trzech podmiotach, których prawidłowość została potwierdzona protokołem wdrożenia, przy czym wartość każdego projektu (wdrożenia oraz dostarczonych licencji) musiała wynosić min. 2 000 000 zł. 

- Kierownik Projektu realizujący przedmiot zamówienia musi legitymować się certyfikatem managera projektu z metodyki zarządzania projektami na poziomie Prince2 Practitioner lub równoważnym, zgodnie z tabelą: (…) albo certyfikatem z metodyki zarzadzania projektami Prince2 Foundation lub równoważnym zgodnie z tabelą (…)

3.zmiany ust. 4.2. OPZ przez modyfikację wymagania integracji zamawianego systemu także z systemem EZD RP poprzez dodanie zapisu: „Z zastrzeżeniem, że EZD RP BĘDZIE DZIAŁAĆ NA TAKICH SAMYCH ZASADACH CO EZD PUW a gdyby zmiana systemu następowała później niż wdrożenie systemu ERP to dostawca drugiego systemu będzie musiał się dostosować do systemu ERP.”

4.zmiany Załącznika nr 10 - Scenariusze prezentacji dla pozycji 2 w obszarze: Moduł: Elektroniczny Obieg Dokumentów (EOD) poprzez nadanie mu następującego brzmienia: l) System umożliwi realizację procesu Akceptacji wniosku urlopowego pracownika składającego się z następujących kroków:

a)Rejestracja w oferowanym systemie ERP (lub poprzez Portal Pracowniczy) Wniosków urlopowych dwóch pracowników,

b)Przekazanie Wniosków urlopowych do kierownika w oparciu o zdefiniowaną relację,

c)Akceptacja przez kierownika urlopu jednego pracownika,

d)Przekazanie danych o urlopie do modułu Kadrowo-Płacowego systemu ERP,

e)Odrzucenie przez kierownika urlopu drugiego pracownika z podaniem przyczyny,

f)Informacja zwrotna do pracowników o akceptacji lub odrzuceniu wniosku,

g)Aktualizacja terminu urlopu przez drugiego pracownika, poprzez aktualizację Wniosku urlopowego.

h)Przekazanie Wniosku urlopowego do kierownika w oparciu o zdefiniowaną relację,

i)Akceptacja przez kierownika urlopu.

j)Przekazanie danych o urlopie drugiego pracownika do modułu Kadrowo-Płacowego systemu ERP.

k)Informacja zwrotna do drugiego pracowników o akceptacji,

Oczekiwany efekt:

i.Zaktualizowana ewidencja kadrowa pracowników, umożliwiająca m.in. prawidłowe naliczenie wynagrodzeń,

ii.Uaktualnione limity urlopów pozostające do wykorzystania przez pracowników,

iii. Aktualne dane o urlopach i dostępności pracowników w module KadrowoPłacowym systemu ERP i Portalu pracowniczym, iv. Możliwość prześledzenia procesów Akceptacji wniosku urlopowego pracownika, dla każdego z pracowników.”

5.Zmiana Załącznika nr 9 do SWZ w zakresie wymagań poz. 465 poprzez dodanie następującego zastrzeżenia: „Zamawiający dopuszcza rozwiązanie, gdzie System jest wykonany w technologii klient-serwer, a dane są przechowywane w modelu relacyjnym baz danych z wykorzystaniem aktywnego serwera baz danych.”

6. Zmiana Załącznika nr 9 do SWZ w zakresie wymagania 531 poprzez usunięcie tego wymagania;

7. Zmiana Załącznika nr 9 do SWZ w zakresie wymagania 554 poprzez usunięcie tego wymagania,

8.Zmiana Załącznika nr 9 do SWZ w zakresie wymagania 687 poprzez dodanie uzupełnienia w brzmieniu:

„Zamawiający informuje, że wymaganie zostanie uznane za spełnione, jeżeli w danych i formularzach dotyczących pracowników oraz list płac system będzie umożliwiał użytkownikowi korzystanie ze słowników (klasyfikacji) uzupełnianych przez użytkownika. W szczególności - jeśli w miejscach (polach, formularzach), gdzie wprowadzane są powtarzalne informacje (np. stanowiska, grupy zawodowe, źródła finansowania, rodzaje umów, kategorie dodatków itp.), system podpowiada i/ lub pozwala na wybór wartości ze zdefiniowanych słowników, które następnie mogą być wykorzystywane do grupowania, filtrowania i raportowania danych.”

9.Zmiany Załącznika nr 2 do SWZ- Projektu umowy w zakresie par. 6 ust. 11 poprzez nadanie mu brzmienia:

„11. Po omówieniu zmian/poprawek Wykonawca zobowiązuje się uzupełnić/poprawić DAP w uzgodnionym przez Strony zakresie i terminie. W przypadku, gdy uwzględnienie zmian zaproponowanych przez Zamawiającego powoduje konieczność wykonania dodatkowych prac programistycznych lub usług wdrożeniowych wykraczających poza zakres określony w OPZ lub Zestawieniu wymaganych funkcjonalności (załącznik nr 9 do SWZ), Strony uzgodnią w formie aneksu odpowiednie zmiany harmonogramu i wynagrodzenia.”

10.Zmiany Załącznika nr 2 do SWZ - Projektu umowy w zakresie par. 7 ust. 2 poprzez nadanie mu brzmienia:

„W przypadku kiedy na etapie ofertowania Wykonawca nie przewidział sprzedaży pewnych Modułów Oprogramowania, a taka potrzeba wynika z OPZ i Zestawienia wymaganych funkcjonalności (załącznik nr 9 do SWZ), Wykonawca dostarczy te Moduły w ramach wynagrodzenia umownego, o którym mowa w par 18 ust. 1 Umowy.”

11. Zmiany Załącznika nr 2 do SWZ - Projektu umowy w zakresie par. 13 ust. 7 poprzez nadanie mu brzmienia:

„1. W przypadku zgłoszeń rozwojowych:

- Autorskie prawa majątkowe do wprowadzonych zmian przysługują wspólnie (w częściach równych) Zamawiającemu i Wykonawcy, o ile przedmiot wniosku lub przedmiot modyfikacji, zgłoszony przez Zamawiającego, stanowi przedmiot ochrony prawnoautorskiej ;

- Zgłoszenia rozwojowe są rozliczane odrębnie od zgłoszeń serwisowych (na podstawie odrębnej faktury);

- Protokół odbioru zgłoszenia rozwojowego określa każdorazowo wzrost wartości Systemu z uwzględnieniem wprowadzonego rozwiązania rozwojowego.” 

W pozostałym zakresie Zamawiający wniósł o oddalenie odwołania.

Zamawiający podał, że Informacja dotycząca częściowego uwzględnienia odwołania została umieszczona na stronie internetowej postępowania w dniu 29 października 2025 r. (Informacja nr 7). Dodatkowo Zamawiający wskazał, że dokonał modyfikacji SWZ wraz z załącznikami na skutek wniosków wykonawców o złożenie wyjaśnień, dodając, że modyfikacje dotyczą również postanowień zakwestionowanych przez Odwołującego w ramach postępowania.

Odwołujący na posiedzeniu z udziałem stron złożył oświadczenie o wycofaniu zarzutów oznaczonych w odwołaniu: nr 1 litera a tiret pierwszy i trzeci, nr 1 litera c, nr 2, nr 4, nr 5, nr 8, nr 9, nr 10.

Krajowa Izba Odwoławcza stwierdziła, że wobec wycofania na posiedzeniu przez Odwołującego ww. zarzutów odwołanie w tym zakresie podlegało umorzeniu na podstawie art. 568 pkt 1 ustawy Pzp.

W konsekwencji wycofania przez Odwołującego części zarzutów, rozpoznaniu przez Izbę podlegały zarzuty oznaczone w odwołaniu: nr 1 lit. a tiret drugi, nr 1 lit. b i lit. d, nr 3, nr 6, nr 7.

Izba dopuściła w poczet materiału dowodowego dokumentację postępowania, przekazaną przez Zamawiającego oraz złożone przez Odwołującego dowody w postaci wyciągów z dokumentów zamówienia sporządzonych przez innych zamawiających (szt. 9), oraz wydruk z korespondencji e-mail z 17 kwietnia 2025 r.

Krajowa Izba Odwoławcza rozpoznając odwołanie, uwzględniając dokumentację postępowania, złożone dowody oraz stanowiska zaprezentowane w sprawie, ustaliła i zważyła co następuje:

W ocenie Krajowej Izby Odwoławczej nie wystąpiła żadna z podstaw odrzucenia odwołania, o których mowa w art. 528 ustawy Pzp.

Izba stwierdziła, że Odwołujący legitymuje się uprawnieniem do skorzystania w przedmiotowym postępowaniu ze środków ochrony prawnej. Zostały bowiem wypełnione przesłanki, o których mowa w art. 505 ust. 1 ustawy Pzp.

Następnie Izba ustaliła:

Zgodnie z rozdz. IV SWZ z 16 września 2025 r.:

1.Przedmiotem zamówienia jest dostawa Szpitalnego Systemu Informatycznego (dalej: „System”), składającego się z systemu klasy ERP (dalej „System ERP”) zawierającego lub uzupełnionego o zintegrowane z nim programy, zapewniające wsparcie pracy w obszarach funkcjonalności określonych w Ofercie oraz OPZ wraz z usługą wdrożenia, udzieleniem licencji, świadczeniem usług gwarancji, nadzoru autorskiego i serwisu oraz szkoleniem użytkowników dla Wojewódzkiego Szpitala Specjalistycznego we Wrocławiu.

2.Przedmiot zamówienia obejmuje:

1.Etap I - Analiza przedwdrożeniowa, w tym: 

a) analiza funkcjonalności i procesów biznesowych, w tym szczególnie funkcjonalności i procesów biznesowych na styku nowego Systemu z innymi systemami użytkowanymi przez Zamawiającego, w celu wypracowania najlepszej możliwej metody realizacji procesów biznesowych oraz integracji systemów,

b) opracowanie szczegółowego Harmonogramu wdrożenia, 

c) przygotowanie Dokumentu Inicjującego Projekt (DIP),

d)przygotowanie Dokumentacji Analizy Przedwdrożeniowej (DAP),

2.Etap II - Dostarczenie zaoferowanego Systemu (w tym ERP) wraz z bazą danych* niezbędną do jego uruchomienia oraz udzielenie licencji, a także dostarczenie licencji innych, wymaganych do funkcjonowania Systemu programów**.

3.Etap III - Wdrożenie zaoferowanego Systemu, w tym: 

a) Instalację na potrzeby wdrożenia instalacji testowej, szkoleniowej, i produkcyjnej Systemu,  

b)Konfigurację, parametryzację, dostosowanie Systemu w sposób zgodny z OPZ i założeniami Analizy Przedwdrożeniowej,  

c) Zaimplementowanie w Systemie funkcjonalności i procesów biznesowych opisanych w OPZ i Analizie Przedwdrożeniowej,

d) integrację Systemu z Oprogramowaniem Zamawiającego w zakresie określonym w OPZ oraz Analizie Przedwdrożeniowej,  

e) Wykonanie Migracji danych, 

f) Szkolenia, instruktaże pracowników zamawiającego w zakresie obsługi Systemu,  

g)Uruchomienie produkcyjne Systemu, 

h) Wsparcie użytkowania po starcie produkcyjnym Systemu,

i) Świadczenie usługi wczesnego wsparcia powdrożeniowego w okresie nie krótszym niż 2 miesiące i obejmującym minimum jeden miesięczny, zamknięty okres rozliczeniowy,

j) Opracowanie i dostarczenie powdrożeniowej dokumentacji Systemu. 

4) Etap IV - Udzielenie Zamawiającemu rękojmi oraz gwarancji, a także świadczenie usług nadzoru autorskiego i serwisu na zasadach i w czasie określonym w projekcie Umowy, stanowiącej załącznik nr 2 do SWZ.

(…)

Zgodnie z rozdz. VIII ust. 1 pkt 4 lit. a i b SWZ w brzmieniu sprzed wprowadzenia zmian, o których mowa w odpowiedzi na odwołanie, wykonawcy winni spełniać warunki udziału w postępowaniu dotyczące:

4) zdolności technicznej lub zawodowej tzn.

a) zdolność techniczna

Wykonawca spełni warunek, jeśli wykaże, że w okresie ostatnich pięciu latach przed upływem terminu składania ofert, a jeżeli okres prowadzenia działalności jest krótszy w tym okresie, wykonał należycie lub wykonuje (Zamawiający wymaga spełnienia wszystkich niżej wymienionych warunków):

- co najmniej jedno wdrożenie zaoferowanego Systemu klasy ERP w podmiocie leczniczym, który zatrudnia co najmniej 1000 osób. Wdrożony System musi składać się co najmniej z modułów finanse- księgowość oraz kadry - płace z pełną integracją tych modułów.

- co najmniej jedną prawidłową migrację danych do oferowanego programu.

- świadczenie co najmniej dwóch usług (na rzecz różnych podmiotów leczniczych) obejmujących utrzymanie systemu, a więc zarówno nadzór autorski jak i usługi serwisu (w tym usługi rozwojowe) trwających co najmniej 3 ostatnie lata (wymóg dotyczy całego okresu świadczenia usług, usługi nie muszą być świadczone na podstawie jednej umowy. W przypadku kilku umów wymaga się, aby nie występowały pomiędzy nimi przerwy przekraczające 30 dni). Usługi muszą być wykonywane na rzecz podmiotów leczniczych zatrudniających co najmniej 1000 osób, system, którego dotyczy utrzymanie musi składać się co najmniej z modułów finanse - księgowość oraz kadry - płace,

b) zdolność zawodowa

Wykonawca spełni warunek, jeśli wykaże, że dysponuje lub będzie dysponował i wyznacza na czas realizacji zamówienia:

- Kierownika Projektu ze strony Wykonawcy, który musi spełniać następujące warunki:

- Posiadać wykształcenie wyższe,

- Kierownik Projektu realizujący przedmiot zamówienia musi posiadać doświadczenie kierowania projektem wdrożenia Systemu klasy ERP, w co najmniej jednym podmiocie leczniczym, który zatrudnia nie mniej niż 500 osób.

(…)

- Specjalista ds. Infrastruktury Techniczno-Systemowej (ITS): w ciągu ostatnich 3 lat brał udział w co najmniej 2 projektach informatycznych związanych z wdrożeniem systemu klasy ERP, w których był odpowiedzialny za instalację i konfigurację infrastruktury techniczno-systemowej.

(…)

W pkt 4.2 OPZ Integracje do uruchomienia lub odtworzenia Zamawiający zastrzegł m.in., że Integracja będzie obejmowała wskazane systemy wykorzystywane przez Zamawiającego, w tym: Asseco Medical Management System (AMMS) firmy ASSECO POLSKA S.A. w podanym zakresie. Zamawiający wskazał m.in.:

W ramach Analizy przedwdrożeniowej Wykonawca zobowiązany jest do analizy potrzeb Zamawiającego w zakresie integracji danych wykorzystywanego obecnie przez Zamawiającego oprogramowania i nowego Systemu. Następnie, w ramach wdrożenia Systemu, Wykonawca zobowiązany jest uruchomić lub odtworzyć integracje w zakresie nie mniejszym niż jest obecnie uruchomiona. Koszty uruchomienia, w oparciu o nowe oprogramowanie i jego mechanizmy integracyjne lub odtworzenia w oparciu o użytkowane przez Zamawiającego oprogramowanie oraz dalszy rozwój zgodnie z Analizą przedwdrożeniową powyższych integracji, ponosi Wykonawca. Zamawiający przekaże Wykonawcy dane kontaktowe do firm będących producentami/dostawcami/wykonawcami systemów informatycznych wskazanych powyżej, z którymi Wykonawca będzie miał obowiązek kontaktować się bezpośrednio. Wykonawca we własnym zakresie przygotuje i udostępni producentowi integrowanego systemu/oprogramowania, dokumentację użytkową oraz specyfikację protokołu komunikacji w wersji elektronicznej. Zamawiający będzie pełnił rolę wspierającą w ustaleniach między Wykonawcą a producentem systemu/oprogramowania integrującego. Wykonawca jest zobowiązany do opracowania i przekazania Zamawiającemu procedur/instrukcji wprowadzania danych, które wymagane są do prawidłowego działania integracji.

W Informacji nr 6 dla wykonawców z 29 października 2025 r., w odpowiedzi na pytanie nr 142, dotyczące Załącznika nr 9 do SWZ - Zestawienie funkcjonalności, w którym wykonawca wskazał m.in., że żądanie spełnienia większości wymagań funkcjonalnych już na etapie składania ofert jest całkowicie nieuzasadnione i czasem wręcz niewykonalne, choćby ze względu na szereg wymagań dotyczących integracji z systemami Zamawiającego lub wymagających konfiguracji i wiedzy przekazanej przez Zamawiającego na etapie Analizy przedwdrożeniowej lub wręcz wskazanie, że Zamawiający zdefiniuje zakres dopiero podczas analizy przedwdrożeniowej (…), Zamawiający poinformował, że wymagania oznaczone jako „OBOWIĄZKOWE” - „Dzień zwożenia oferty” zostały określone w taki sposób, aby umożliwić Zamawiającemu ocenę minimalnej funkcjonalności oferowanego systemu w momencie składania oferty („Dzień złożenia oferty”). Funkcjonalności te muszą być obecne w oferowanym systemie w standardzie producenta, nie wymagają natomiast pełnej konfiguracji pod specyficzne procesy Zamawiającego.

1.Wymagania dotyczące integracji z systemami zewnętrznymi (np. HIS, KSeF) mogą zostać zrealizowane w toku wdrożenia, zgodnie z harmonogramem określonym w OPZ. Wymóg „na dzień złożenia oferty” dotyczy możliwości technicznej integracji i dostępności funkcjonalności w standardzie oferowanego systemu, a nie wykonanej implementacji pod konkretne środowisko Zamawiającego.

2.Kolumny „DOSTAWCA POSIADANA FUNKCJONALNOŚĆ”, „DOSTAWCA DOSTARCZY FUNKCJONALNOŚĆ DO TERMINU WDROŻENIA” oraz „POZYCJA ZE SPECYFIKI DOSTAWCY” pozostają w Załączniku nr 9 zgodnie z instrukcjami dla Wykonawców i służą ułatwieniu oceny zgodności oferty z wymaganiami SWZ. Wypełnienie tych kolumn przez Wykonawcę nie oznacza, że wymaga się pełnej konfiguracji funkcjonalności w dniu składania oferty, lecz jedynie wskazania dostępności danej funkcjonalności w oferowanym systemie.

3.W przypadku funkcjonalności oznaczonych jako OPCJONALNE: 158, gdzie termin realizacji wymagania pierwotnie określono jako „Dzień złożenia oferty” (pozycje: 3), Zamawiający dokonuje zmiany terminu realizacji na „Termin wdrożenia modułu”.

4.Szczegółowa konfiguracja systemu, dostosowanie do procesów Zamawiającego oraz implementacja integracji będą realizowane w toku wdrożenia, w ramach Etapu III - Wdrożenie Systemu, zgodnie z harmonogramem wdrożenia oraz Analizą Przedwdrożeniową.

5.Wymaganie posiadania funkcjonalności w standardzie systemu w dniu składania oferty nie ogranicza konkurencyjności postępowania, gdyż każdy oferowany system ERP musi w swojej standardowej wersji zapewniać podstawowe możliwości integracyjne i funkcjonalne przewidziane w OPZ.

Z powyższych względów Zamawiający nie wprowadza dalszych zmian w Załączniku nr 9 w zakresie terminów realizacji funkcjonalności ani w kolumnach dotyczących deklaracji Wykonawcy.

W Informacji nr 6 dla wykonawców z 29 października 2025 r., w odpowiedzi na pytanie nr 144, dotyczące Załącznika nr 9 do SWZ - Zestawienie funkcjonalności, w którym wykonawca wskazał m.in., że Opis przedstawiony przez Zamawiającego przenosi większość odpowiedzialności związanej z integracja z oprogramowaniem firm trzecich na stronę Wykonawcy, co zaburza zasadę równego traktowania i uczciwej konkurencji. Producenci/dostawcy/wykonawcy systemów informatycznych przedstawionych na liście systemów podlegających integracji nie są stronami Umowy pomiędzy wyłonionym Wykonawcą a Zamawiającym i nie mają żadnego interesu w tym, żeby współpracować z Wykonawcą, który potencjalnie może stanowić dla niego konkurencję, Zamawiający podał:

Zamawiający informuje, że zapis dotyczący integracji z oprogramowaniem firm trzecich nie ma na celu przeniesienia odpowiedzialności za działania tych podmiotów na Wykonawcę.

Wskazany obowiązek Wykonawcy dotyczy jedynie realizacji integracji po stronie oferowanego Systemu oraz zapewnienia zgodności i poprawności wymiany danych zgodnie z wymaganiami określonymi w OPZ i w Analizie Przedwdrożeniowej.

Zamawiający będzie brał czynny udział w pozyskaniu wszelkich niezbędnych informacji dotyczących integracji wspólnie z Dostawcą nowego Systemu. Jako że Zamawiający nie posiada odpowiedniej wiedzy technicznej w zakresie możliwych rozwiązań integracyjnych, nie jest w stanie samodzielnie pozyskać takich informacji bez udziału Dostawcy. Co więcej, wystąpienie z prośbą o przekazanie konkretnych danych lub dokumentacji możliwe będzie dopiero po wyborze Wykonawcy - dlatego szczegółowe ustalenia w tym zakresie będą prowadzone na etapie Analizy Przedwdrożeniowej.

W przypadku konieczności uzyskania dodatkowych informacji, danych technicznych, dokumentacji integracyjnej lub wsparcia producenta oprogramowania firm trzecich, Zamawiający podejmie działania w celu ich pozyskania. Wszelkie koszty wynikające z udziału lub obsługi obecnych dostawców ponosi Zamawiający.

Wykonawca nie będzie zobowiązany do świadczenia serwisu ani nadzoru autorskiego dla oprogramowania, którego nie jest producentem. Zakres jego odpowiedzialności obejmuje przygotowanie, konfigurację i uruchomienie integracji po stronie oferowanego Systemu, w oparciu o dostępne mechanizmy i interfejsy udostępnione przez producentów systemów zewnętrznych.

Szczegółowy sposób realizacji integracji, w tym techniczne metody wymiany danych i zakresy integracyjne, zostaną doprecyzowane na etapie Analizy Przedwdrożeniowej przez ekspertów Wykonawcy, w uzgodnieniu z Zamawiającym.

Izba zważyła, co następuje:

Odwołanie zasługuje na uwzględnienie w zakresie zarzutu nr 3. W pozostałym zakresie odwołanie podlega oddaleniu.

Ad zarzut nr 3, dotyczący integracji zamawianego systemu z systemami posiadanymi przez Zamawiającego

Zgodnie z art. 99 ust. 1 ustawy Pzp 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.

Stosownie do art. 16 ustawy Pzp 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.

W uzasadnieniu tego zarzutu, Odwołujący podał m.in., że integracja systemów IT to proces łączenia różnych systemów i aplikacji w celu umożliwienia im współpracy i wymiany danych. Celem integracji jest stworzenie spójnego środowiska IT, w którym różne systemy mogą łatwo komunikować się i dzielić się informacjami. Z dokumentacji postępowania, w szczególności pkt 4.2. OPZ, wynika, że Zamawiający obciążył wykonawcę wszystkimi obowiązkami związanymi ze zintegrowaniem zamawianego systemu z systemami posiadanymi obecnie przez Zamawiającego, z których obecnie korzysta, w tym wyłączył swój czynny udział w realizacji tej integracji, a tym samym swoją odpowiedzialność w tym zakresie. Zamawiający określił tylko oczekiwany finalny efekt integracji zamawianego systemu z systemami, z których obecnie korzysta, bez wskazania wykonawcom podstawowych danych, które umożliwią złożenie oferty w tym zakresie, w całości odsyłając do podmiotów trzecich. Dla przeprowadzenia integracji niezbędne jest jednak zapewnienie dokumentacji systemów, z którymi przeprowadzona ma być integracja oraz opisanie wszystkich technicznych danych wspomnianych systemów. Wspomniane dokumentacje i dane muszą zostać pozyskane od producentów systemów, dotychczas funkcjonujących u Zamawiającego. Tymczasem, OPZ nie dostarcza wspomnianych dokumentacji i danych, oraz przenosi na przyszłego wykonawcę obowiązek ich pozyskania. Tak ukształtowany opis przedmiotu zamówienia jest wadliwy, bowiem nie można na ten moment ocenić zakresu zamówienia i kosztów jego wykonania. Powołując na orzecznictwo KIO, Odwołujący podał, że sprzeczne z ustawą Pzp jest przenoszenie na wykonawców obowiązku pozyskania danych i dokumentacji systemów integrowanych, sprowadza się to bowiem do niedozwolonego narzucenia potencjalnemu wykonawcy współpracy z innym, niż zamawiający, podmiotem, często bezpośrednio z nim konkurującym. Równoznaczne jest to z brakiem opisania przedmiotu zamówienia i przerzucenie na wykonawcę zamówienia obowiązku identyfikowania jego zakresu i rozmiarów świadczenia. Jak wskazuje się w ugruntowanym orzecznictwie Izby: Odnosząc powyższe rozważania do niniejszego stanu faktycznego stwierdzić należy, że sam fakt odesłania do podmiotów trzecich potwierdza, że nawet w ocenie Zamawiającego zakres danych dotyczących integracji zamieszczony w SIWZ nie był pełny, skoro wymagał informacji pochodzących od podmiotów trzecich. W postępowaniu o udzielnie zamówienia stroną dla wykonawcy może być jedynie zamawiający, a nie jakikolwiek podmiot trzeci, zatem w ocenie Izby tego rodzaju odesłania pozostają bezskuteczne. Zamawiający oczywiście może powierzyć pomocnicze działania zakupowe własnej jednostce organizacyjnej lub osobie trzeciej lub włączyć do prac komisji przetargowej biegłych z danej dziedziny. Niemniej to Zamawiający, jako gospodarz postępowania, jest autorem dokumentów decydujących o kształcie tego postępowania, a odesłanie po informacje, niezbędne do sporządzenia i złożenia oferty, do podmiotu trzeciego należy uznać za naruszenie art. 29 ust 1 w zw. z art. 7 ust. 1 ustawy Pzp (por. Wyrok KIO z dnia 9 stycznia 2018 r. sygn. akt KIO 2682/17, podobnie Wyrok KIO z 21 lutego 2017 r., sygn. akt KIO 269/17). Producentami oprogramowania, z którym ma być zintegrowany zamawiany system, są m.in. podmioty mogące potencjalnie ubiegać się o pozyskanie niniejszego zamówienia. Nie mają one nie tylko jakiegokolwiek obowiązku formalnoprawnego, ale i też celu gospodarczego, aby wejść we współpracę z potencjalnym, konkurencyjnym wykonawcą w celu umożliwienia mu realizacji zamówienia na rzecz Zamawiającego. Tym bardziej, obwiązek pełnego opisania przedmiotu zamówienia w zakresie integracji, w tym pozyskanie wszystkich koniecznych danych do przeprowadzenia tej integracji, spoczywać powinno na Zamawiającym.

W odpowiedzi na odwołanie Zamawiający wskazał m.in., że na tym etapie postępowania wymaga od dostawców określenia braku przeciwskazań technicznych do integracji z obecnymi systemami, które posiada. Zamawiający dysponuje konkretnymi systemami, określonymi w OPZ. Z punktu widzenia organizacji pracy, istotna jest integracja tych systemów z nowym systemem, który jest przedmiotem postępowania. Przykładowo dane zawarte w systemie AMMS (systemie służącym do prowadzenia dokumentacji medycznej pacjentów Wojewódzkiego Szpitala Specjalistycznego we Wrocławiu) są podstawą do wystawiania dokumentów rozliczeniowych w zakresie udzielanych przez Zamawiającego świadczeń opieki zdrowotnej. Z puntu widzenia Zamawiającego istotne jest tu zagwarantowanie współpracy/wymiany danych między programami. Wymiana danych jest również istotna w zakresie gospodarki lekami i wyrobami medycznymi, z puntu widzenia Zamawiającego istotna jest wymiana danych pomiędzy stanami magazynowymi a np. zleceniami lekarskimi i przebiegami pielęgniarskimi w zakresie podaży leków. Z tego powodu konieczne jest zapewnienie automatycznego importu /wymiany tych danych i zapewnienie ich zgodności w obu systemach. Integracja nowego, dostarczanego systemu z innymi systemami, które już funkcjonują w środowisku nabywcy oprogramowania jest rozwiązaniem typowo stosowanym na rynku. Wymóg integracji jest częścią funkcjonalności systemu, a nie dodatkiem, bez niej system nie spełnia swojej roli. Integracja zaś jest elementem wdrożenia systemu. Działania w tym zakresie odbywają się bez udziału nabywcy systemów, który nie ma ani wiedzy, ani doświadczenia czy środków technicznych umożliwiających mu udział w tych czynnościach. Zlecenie tej czynności jednemu podmiotowi, dostawcy nowego oprogramowania jest też rozwiązaniem prawidłowym ze względu na ochronę interesu nabywcy oprogramowania. Rozwiązanie to jednoznacznie wskazuje, który podmiot odpowiada za prawidłowość integracji i ewentualnie jest zobowiązany do podjęcia działań w przypadku kiedy nie przebiegła ona w sposób prawidłowy. Ponadto zgodnie z zasadą odpowiedzialności za dostarczane rozwiązanie Dostawca systemu jest odpowiedzialny za dostarczenie kompletnego, funkcjonalnego rozwiązania zgodnego z wymaganiami zamawiającego, w tym za jego zdolność do współpracy z istniejącym środowiskiem IT. Nie ma tu żadnego znaczenia, że podmiot, którego autorstwa oprogramowanie jest integrowane z nowym rozwiązaniem może prowadzić działalność konkurencyjną w stosunku do dostawy nowego systemu. Do integracji dochodzi po wyborze ofert. Zdarzenie to nie ma więc wpływu na ograniczenie konkurencji. Zdaniem Zamawiającego za bezzasadne uznać należy stanowisko Odwołującego, że konieczne jest zapewnienie udziału Zamawiającego w procesie integracji. Zamawiającemu nie przysługują prawa autorskie do systemu dostarczanego przez dostawcę, Zamawiający jest uprawniony jedynie do korzystania z tego systemu na warunkach określonych w umowie licencyjnej, co za tym idzie Zamawiający nie ma wpływu na sposób działania nowego systemu, jego architekturę ani technologię. To dostawca projektuje i wdraża rozwiązanie, więc to on musi zapewnić jego kompatybilność z istniejącym środowiskiem. Standardy rynkowe i dobre praktyki w projektach wdrożeniowych wskazują, że to dostawca systemu odpowiada za jego integrację z systemami zamawiającego. W przypadku podmiotów publicznych, do grona których zalicza się Zamawiającego, zgodnie z Rozporządzeniem Rady Ministrów z dnia 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności, systemy informatyczne muszą spełniać minimalne wymagania, w tym: „Systemy teleinformatyczne projektuje się, wdraża oraz eksploatuje z uwzględnieniem ich interoperacyjności, czyli zdolności do wymiany danych z innymi systemami.” Oznacza to, że dostawca systemu musi zapewnić jego zdolność do współpracy z innymi systemami, a nie przerzucać odpowiedzialności za to na Zamawiającego. Na marginesie Zamawiający wskazał, że Odwołujący jest aktualnym dostawcą oprogramowania klasy ERP, wdrożonego u Zamawiającego. Oprogramowanie to jest zintegrowane z systemem AMMS, stąd też w ocenie Zamawiającego Odwołujący nie ma interesu w skarżeniu tego wymogu.

W ocenie Izby, w pierwszej kolejności wskazania wymaga, że nie sposób zgodzić się ze stanowiskiem Zamawiającego co do braku interesu Odwołującego w postawieniu omawianego zarzutu. Jakkolwiek nie jest sporne, że Odwołujący dostarczył Zamawiającemu oprogramowanie klasy ERP przed wielu laty, to jednak Zamawiający nie wykazał, że wymagania co do integracji i uwarunkowania, w jakich ona następowała w poprzednim i ma nastąpić w ramach aktualnego zamówienia, są analogiczne.

W związku z tym zarzut ten polegał rozpoznaniu przez Izbę.

Tytułem ogólnej uwagi, wskazania wymaga, że sporządzenie opisu przedmiotu zamówienia, w sposób, który umożliwia dokonanie wyceny zakresu świadczenia, należy do Zamawiającego, który w dokumentach zamówienia powinien w sposób jasny przekazać wykonawcom informacje, pozwalające im na ocenę, co i w jakim wymiarze stanowi przedmiot zamówienia, jaki jest zakres świadczeń podlegających wycenie w ofercie. Opis przedmiotu zamówienia powinien być tak przedstawiony przez Zamawiającego, aby pozwolił wykonawcom na równych zasadach, na sporządzenie oferty i określenie jej ceny z uwzględnieniem wszystkich czynników na nią wpływających. Oferty powinny być bowiem porównywalne.

Zarzut odwołania dotyczy braku konkretnego uregulowania w SWZ wszystkich elementów niezbędnych dla wyceny tej części zamówienia, która dotyczy integracji, w tym roli Zamawiającego przy pozyskaniu koniecznych danych od producentów systemów posiadanych przez Zamawiającego, z którymi ma być przeprowadzana integracja zamawianego systemu i w konsekwencji braku zapewnienia, że wybrany wykonawca będzie mógł określonymi danymi dysponować, bez ponoszenia kosztów związanych z ich pozyskaniem, w razie gdyby zaszła taka potrzeba w ramach integracji.

Zwraca uwagę, że Zamawiający nie wykazał, że producenci posiadanych przez niego systemów, z którymi ma nastąpić integracja, zostali przez niego zobowiązani do współpracy z wykonawcą zamawianego systemu. W sytuacji zatem, gdy wykonawca nie jest producentem systemów posiadanych przez Zamawiającego i nie ma relacji z producentami tych systemów, nie jest wykluczone, że może mieć trudności z pozyskaniem niezbędnych informacji i z oszacowaniem na potrzeby kalkulacji ceny oferty, kosztów pozyskania takich danych.

W związku z tym, w ocenie Izby, skoro w dokumentach zamówienia, Zamawiający nie dokonuje opisu posiadanych systemów, to wymagając w postępowaniu przeprowadzenia integracji z tymi systemami, powinien zapewnić wykonawcy zamawianego systemu niezbędne informacje potrzebne do jego integracji z posiadanymi systemami, które na wystąpienie wykonawcy powinien na własny koszt pozyskać od producentów tych systemów i przekazać wybranemu wykonawcy.

Postanowienia jasno określające udział Zamawiającego na jego koszt, przy pozyskaniu niezbędnych informacji od producentów posiadanych systemów, powinny być zamieszczone w dokumentach zamówienia. Wykonawcy muszą bowiem, na równych zasadach, mieć możliwość złożenia porównywalnych ofert. Dla zachowania uczciwej konkurencji, producenci posiadanych przez Zamawiającego systemów, z którymi ma następować integracja, nie powinni znajdować się w uprzywilejowanej pozycji, w razie, gdy zdecydują się na złożenie oferty w postępowaniu.

W okolicznościach analizowanej sprawy, zaznaczenia wymaga, że jak wyżej zostało wskazane, Zamawiający w odpowiedzi na odwołanie podał, że dokonał modyfikacji SWZ wraz z załącznikami na skutek wniosków wykonawców o złożenie wyjaśnień. Modyfikacje dotyczą również postanowień zakwestionowanych przez Odwołującego.

Z treści przedstawionej powyżej odpowiedzi na pytanie nr 144, zawartej w Informacji nr 6 dla wykonawców z 29 października 2025 r., wynika, że Zamawiający wskazuje na swój udział w pozyskaniu dodatkowych informacji dla potrzeb integracji, danych technicznych, dokumentacji integracyjnej lub wsparcia producenta oprogramowania, a także stwierdza m.in., że ponosi wszelkie koszty wynikające z udziału lub obsługi obecnych dostawców.

Stanowisko Zamawiającego w tym zakresie, zawarte w powyżej przedstawionej odpowiedzi na odwołanie może być natomiast odczytane jako odstępstwo od udostępnionej wykonawcom Informacji nr 6, może zatem wprowadzać w stan niepewności co do rzeczywistej roli Zamawiającego w procesie przekazywania wykonawcy w procesie integracji, niezbędnych danych od producentów posiadanych systemów. Wykonawcy, przed złożeniem oferty, muszą mieć natomiast jasność co do tego, czy w razie potrzeby dysponowania na potrzeby integracji, której przeprowadzenie ich obciąża, określonymi danymi, dotyczącymi posiadanych przez Zamawiającego systemów, zostaną one im udostępnione i nie będzie się to wiązało z koniecznością poniesienia przez nich kosztów, związanych z ich pozyskaniem, których nie są w stanie wiążąco określić na etapie kalkulacji ceny oferty.

W podsumowaniu należy stwierdzić, że Zamawiający, mając na uwadze zapewnienie porównywalności ofert oraz zasadę przejrzystości i prowadzenia postępowania z zachowaniem uczciwej konkurencji, powinien na równych zasadach zapewnić wykonawcom dostęp do informacji, pozwalających na skalkulowanie ceny oferty. Skoro sam nie jest w stanie określić potrzebnych informacji lub nie dysponuje odpowiednimi danymi, a także nie jest w stanie określić ewentualnych kosztów udostępnienia przez producentów odpowiednich informacji na potrzeby integracji, powinien te koszty przejąć na siebie, tak aby wykonawcy mogli skalkulować ceny ofert na takich samych zasadach, niezależnie od tego czy są producentami posiadanych przez Zamawiającego systemów, czy nie. W sytuacji, gdy wykonawca musi zapewnić kompatybilność dostarczonego systemu z istniejącym środowiskiem, to jest zrozumiałe, że musi posiadać niezbędne do tego celu informacje, dotyczące tego środowiska. Informacje te powinien uzyskać od Zamawiającego. W związku z tym Zamawiający powinien wprowadzić do SWZ odpowiednie postanowienia wskazujące na jego udział i na leżący po jego stronie koszt przy pozyskaniu informacji, które są niezbędne dla przeprowadzenia integracji zamawianego systemu z wskazanymi w tym zakresie systemami, od ich producentów.

Ad Zarzuty nr 1 lit. a tiret drugi i nr 1 lit. b i d, dotyczące warunków udziału w postępowaniu

Zgodnie z art. 112 ust. 1 ustawy Pzp 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.

W ocenie Odwołującego, Zamawiający nie ustanowił zakwestionowanych w odwołaniu warunków udział w postępowaniu w sposób proporcjonalny. Zdaniem Zamawiającego natomiast, postawione przez niego warunki udziału w postępowaniu są proporcjonalne do przedmiotu zamówienia.

W odniesieniu do warunku dotyczącego zdolności wykonawcy, Odwołujący wskazał, że Zamawiający wadliwe kwalifikuje referowanie warunku w zakresie wdrożenia systemu oraz w zakresie utrzymania systemu, do podmiotu na rzecz którego wdrożenie systemu lub usługa utrzymania systemu były wykonywane, tj. do podmiotu leczniczego. Zdaniem Odwołującego, w sytuacji, gdy przedmiotem zamówienia jest odpowiednio wdrożenie i późniejsze utrzymanie systemu ERP, tj. systemu do zarządzania zasobami przedsiębiorstwa, mogącego z powodzeniem funkcjonować niezależnie od przedmiotu działalności organizacji, która z tego systemu korzysta, to ograniczanie możliwości wykazania się doświadczeniem wyłącznie do podmiotów leczniczych nie ma uzasadnienia z uwagi na fakt, że zamawiany system informatyczny klasy ERP, nie posiada właściwości funkcjonalnych charakterystycznych wyłącznie dla podmiotów leczniczych, lecz może być i jest wykorzystywany w większości przedsiębiorstw, uczelni, instytutów oraz innych instytucji publicznych oraz nie różnicuje ich charakter jednostki, w której są wdrażane, a ewentualnie wymagania dla danego systemu, określone przez danego zamawiającego, które nie są wspólnymi wyłącznie dla podmiotów leczniczych. Zawężanie możliwości wykazania się doświadczeniem do jednego typu jednostek ma znamiona ograniczania konkurencyjności.

W odniesieniu do warunku dotyczącego doświadczenia Specjalisty ds. Infrastruktury Techniczno - Systemowej (ITS), Odwołujący wskazał, że jego określenie jest wadliwe w zakresie w jakim Zamawiający wymaga, aby dana osoba posiadała doświadczenie w realizacji dwóch (a nie jednego) referencyjnych projektów informatycznych. Zdaniem Odwołującego, trudno znaleźć podstawę do stwierdzenia, że dopiero dwu, a nie jednokrotny udział w realizacji danego projektu, da Zamawiającemu rękojmię należytego wykonania zamówienia. Samo wykonanie zamówienia i rola jaką ta osoba ma pełnić ma też charakter jednorazowy, a nie powtarzalny.

Zamawiający w odpowiedzi na odwołanie wskazał w tym zakresie w szczególności, że wymaganie, by wykonawca wykazał się doświadczeniem we wdrożeniu systemu ERP w jednostce leczniczej o podobnej skali działania, ma na celu minimalizowanie ryzyka niepowodzenia projektu i zapewnienie, że wykonawca rozumie specyfikę sektora ochrony zdrowia. Moduły „finanse księgowość” oraz „kadry - płace” są kluczowe dla funkcjonowania każdej jednostki. Działalność podmiotów leczniczych regulują odrębne przepisy np. w zakresie czasu pracy pracowników czy zasad wynagradzania pracowników wynikające z ustawy o działalności leczniczej. W przypadku wdrożenia programu księgowo - kadrowego, jest to kwestia niezwykle istotna. W podmiotach leczniczych gwarantem realizacji prawidłowego funkcjonowania jest nie tylko wewnętrzny system kontroli wspierany przez odpowiedni, elastyczny, zwinny i sprawny system ewidencyjny ERP, jak również możliwość odzwierciedlenia złożoności procesów i relacjonowaniu stanu ich realizacji za pośrednictwem informacji pozyskanych z tego systemu na potrzeby interesariuszy zewnętrznych (kontrole NFZ) czy też np. związków zawodowych. W takim przypadku uchybienia wynikające z ułomności i niesprawności systemów nie znajdują zrozumienia, a rodzą ryzyko konfliktu i sporów. Uzależnienie możliwości udziału w postępowaniu od świadczenia usług na rzecz podmiotu zatrudniającego minimalną liczby osób związane jest z wolą Zamawiającego zwiększenia prawdopodobieństwa prawidłowego wykonania przedmiotu umowy. Podmioty, które przeprowadziły takie wdrożenie lub nim kierowały, cechuje bowiem z jednej strony umiejętność zarządzania dużym zespołem, a z drugiej umiejętność zastosowania różnych rozwiązań np. związanych z systemami czasu pracy do różnych grup pracowników. W ocenie Zamawiającego, wdrożenia wykonywane w podmiotach zatrudniających mniejszą liczbę pracowników, są mniej skomplikowane niż wdrożenia u dużych przedsiębiorców, u których występuje dużo większy stopień złożoności problemów, analizy wymaga też większa ilość bardziej skomplikowanych procesów. Odrębności w tym zakresie, występują na wszystkich etapach realizacji przedmiotu zamówienia to jest zarówno na etapie projektowym (sporządzania analizy przedwdrożeniowej), w trakcie wdrożenia jak i na etapie utrzymania i ewentualnego rozwoju serwisu. Warunki te nie wpływają na ograniczenie konkurencji. Są one dostosowane w sposób współmierny do przedmiotu postępowania.

W odniesieniu do zarzutu dotyczącego warunków udziału w postępowaniu w zakresie doświadczenia Specjalisty ds. Infrastruktury Techniczno - Systemowej (ITS) Zamawiający wskazał, że przewidziany w SWZ wymóg jest proporcjonalny. Udział w co najmniej dwóch projektach, z uwagi na stopień zróżnicowania, w tym skomplikowania, wdrożeń systemu ERP, daje możliwość potwierdzenia faktycznej wiedzy, doświadczenia i umiejętności właściwej realizacji obowiązków. Gwarancji takiej nie daje udział w jednym projekcie.

W ocenie Izby, w sprawie nie zostało wykazane, aby zakwestionowane przez Odwołującego warunki udziału w postępowaniu były nieproporcjonalne do przedmiotu zamówienia, żeby nie uwzględniały rodzaju zamówienia, jego przedmiotu i wymagań związanych z jego realizacją, w tym dotyczących jego przeznaczenia. Nie zostało wykazane, aby warunki te były nieadekwatne do osiągnięcia celu ich postawienia w postaci wyboru wykonawcy dającego rękojmię należytego wykonania umowy, aby zostały określone ponad poziom niezbędny do osiągnięcia tego celu. Wymogi te należy uznać za uzasadnione potrzebami Zamawiającego, jako związane z dbałością o jakość i rzetelność wykonania przedmiotu zamówienia.

W zakresie odniesienia w opisie warunków, dotyczących wdrożenia, jak też utrzymania systemu ERP, do podmiotów leczniczych, zauważenia wymaga, że Zamawiający nie wymagał wykazania się doświadczeniem w wykonaniu usług dla tożsamego podmiotu, np. co do stosowanych systemów pracy czy dokładnie takiej samej liczby zatrudnionych na poszczególnych stanowiskach, lecz odniósł warunki do doświadczenia zdobytego w realizacji zamówienia na rzecz podmiotów leczniczych. Zamawiający jest jednym z podmiotów leczniczych, które mają swoją specyfikę działania, w tym związaną z systemami pracy i ich rozliczaniem.

Celem ww. warunków udziału w postępowaniu jest wybór wykonawcy dającego rękojmię należytego wykonania zamówienia, zatem oczekiwanie, aby taki wykonawca miał doświadczenie związane z realizacją zamówień na rzecz podmiotów o zbliżonej specyfice działania, nie jest wymaganiem nieproporcjonalnym do przedmiotu zamówienia. Zgodzić się należy z Zamawiającym, że doświadczenie w zakresie wdrożenia w podmiotach leczniczych, które łączy się ze znajomością konkretnych rozwiązań, daje większą gwarancję realizacji przedmiotu zamówienia w sposób właściwy. Daje również pewność, że wykonawca zna charakter branży, towarzyszącą jej specyfikę i stosuje z powodzeniem różne metody zarządzania, dostosowując je do charakteru i zmienności warunków, jakie musi spełniać i jakim musi sprostać podmiot leczniczy.

Nie jest wymaganiem nadmiernym, wskazanie przez Zamawiającego na wymóg dotyczący doświadczenia w realizacji dwóch usług w zakresie utrzymania systemu na rzecz różnych podmiotów leczniczych, jak też wymóg dotyczący doświadczenia Specjalisty ds. Infrastruktury Techniczno - Systemowej (ITS) w udziale w dwóch projektach informatycznych, związanych z wdrożeniem systemu klasy ERP, w których był odpowiedzialny za instalację i konfigurację infrastruktury techniczno -systemowej.

Przy tego rodzaju złożonych projektach, Zamawiający ma prawo oczekiwać od wykonawców oraz ich personelu, że będą posiadać rzeczywiste doświadczenie w wymaganym zakresie. Nie chodzi bowiem o gotowy produkt, dostępny w analogicznym zakresie dla wszystkich odbiorców, lecz o system, który jest konfigurowany i dostosowywany do poszczególnych odbiorców. Zatem wymóg posiadania powtarzalnego doświadczenia na rzecz różnych podmiotów leczniczych, nie jest nieproporcjonalny do przedmiotu zamówienia. Potwierdzają to także dowody złożone przez Odwołującego w postaci wyciągów z dokumentów zamówienia z postępowań prowadzonych przez innych zamawiających, w których zostały postawione bardziej wymagające warunki, np. Agencja Badań Medycznych wymaga doświadczenia w realizacji co najmniej 3 usług, ze wskazaniem dodatkowo na minimalną ich wartość.

Podobnie, zdaniem Izby, należy ocenić wymóg dotyczący udziału w co najmniej dwóch projektach przez Specjalistę ds. Infrastruktury Techniczno - Systemowej (ITS). Z uwagi w szczególności na specyfikę wdrożeń systemu ERP i związaną z tym m.in. konfigurację infrastruktury techniczno-systemowej, udział w dwóch projektach nie jest wymogiem określonym ponad minimalny poziom zdolności. Zgodzić się należy z Zamawiającym, że powtarzalność doświadczenia w tym zakresie, w tym z uwagi na stopień skomplikowania, wdrożeń systemu ERP, daje możliwość potwierdzenia rzeczywistego doświadczenia i związanej z tym umiejętności realizacji zdań z tym związanych. Nie zostało wykazane przez Odwołującego, że jednokrotne doświadczenie takiego specjalisty jest wystarczające dla stwierdzenia rękojmi należytego wykonania przez niego zamówienia.

Ad zarzuty nr 6 i 7 dotyczące dostępności funkcjonalności

Odwołujący w tym zakresie wskazał, że jednym z dokumentów zamówienia jest Załącznik nr 9 do SWZ - Zestawienie funkcjonalności. Składa się on z czterech zakładek, w których w jednej („Lista funkcjonalności) opisano funkcjonalności, jakie musi posiadać zamawiany system. Zakładka ta zawiera kolumnę „termin realizacji wymagania”, w którym Zamawiający oznaczył moment, na jaki dana funkcjonalność ma zostać spełniona przez oferowany przez wykonawców system. W kolumnach „termin realizacji wymagania”: na 1157 funkcjonalności obowiązkowych, aż 583 oznaczono jako „dzień złożenia oferty”, a 583 oznaczono jako „termin wdrożenia modułu”; na 158 funkcjonalności opcjonalnych, 3 oznaczono jako „dzień złożenia oferty”, a 155 oznaczono jako „termin wdrożenia modułu”. Zdaniem Odwołującego wymaganie to nie licuje z przedmiotem zamówienia i sposobem, w jaki zamówienie ma zostać zrealizowane. Terminy wykonania zamówienia określa z kolei m.in. rozdz. VI SWZ, zgodnie z którym: Etap I – Analiza przedwdrożeniowa – ma być wykonany do 3 miesięcy od daty zawarcia umowy, Etap II – Dostarczenie zaoferowanego Systemu (w tym ERP) wraz z bazą danych - musi zostać zrealizowany w okresie 14 dni, liczonych od dnia zatwierdzenia Analizy przedwdrożeniowej, nie później jednak niż do dnia rozpoczęcia wdrożenia poszczególnych modułów, Etap III – wdrożenie systemu ERP – ma być wykonany najpóźniej do dnia 31.12.2026 r., przy czym Wykonawca zapewni możliwość pracy na testowym i produkcyjnym Systemie zasilonym zmigrowanymi danymi, przynajmniej 2 miesiące przed startem produkcyjnym, w celu umożliwienia weryfikacji poprawności działania Systemu, w szczególności w zakresie funkcjonalności i procesów biznesowych wymienionych w dokumencie OPZ z perspektywy prowadzenia działalności przez Zamawiającego. Odwołujący podał, że oferowany system, ma zostać dostosowany do potrzeb Zamawiającego zgodnie z korelacją sporządzonych przez niego, specyficznych wymagań funkcjonalnych. System nie będzie uruchomiony bezpośrednio po zawarciu umowy, a po wykonaniu szeregu działań projektowych, w tym po opracowaniu analizy przedwdrożeniowej, która ma sprecyzować wymagania Zamawiającego i skonkretyzować sposób ich spełnienia (zgodnie z Projektem Umowy, Analizę Przedwdrożeniową stanowi: Proces, prowadzony przez Wykonawcę w ramach I Etapu Umowy, którego celem jest zdefiniowanie potrzeb Zamawiającego i dostosowania do nich Systemu, którego efektem jest przygotowanie DAP (dokumentacji analizy przedwdrożeniowej). W związku z tym wymaganie zgodnie z którym, aż ponad 50% funkcjonalności zamawianego systemu ma być gotowych na moment składania ofert, stanowi wymaganie spełnienia świadczenia przed wyborem oferty najkorzystniejszej. To wymaganie jest co najmniej nieproporcjonalne, mając na uwadze potrzeby Zamawiającego oraz sposób wykonania zamówienia opisany w SWZ i nie odzwierciedla uzasadnionych potrzeb Zamawiającego. Skoro sam Zamawiający zakłada, że wdrożenie ma zostać wykonane w przez okres ok. 12 miesięcy od dnia zawarcia umowy z wybranym wykonawcą, nie ma żadnych uzasadnionych przyczyn dla których, na moment składania ofert aż tyle funkcjonalności miałoby być gotowych. Powyższe rodzi uzasadnione wątpliwości o konkurencyjność tego rodzaju wymagań. System oferowany przez wykonawcę posiadającego zbliżone do wymaganych przez Zamawiającego funkcjonalności (w sposób intencjonalny lub nie), stawiany jest w o wiele korzystniejszej sytuacji niż wykonawców, którzy chcąc złożyć ofertę w postępowaniu, musieliby w zasadzie przygotować cały system według specyficznych wymagań Zamawiającego, bez gwarancji pozyskania zamówienia (zakładając, że z uwagi na zbliżający się termin składania ofert, jest to w ogóle możliwe). Żądanie spełnienia większości wymagań funkcjonalnych już na etapie składania ofert jest całkowicie nieuzasadnione i -w niektórych przypadkach - wręcz niewykonalne, choćby ze względu na szereg wymagań dotyczących integracji z systemami Zamawiającego lub wymagających konfiguracji i wiedzy przekazanej przez Zamawiającego na etapie Analizy przedwdrożeniowej. Niektóre postanowienia wprost stanowią, że Zamawiający zdefiniuje zakres dopiero podczas analizy przedwdrożeniowej. Zamawiający wielokrotnie też odwołuje się w wymaganiach do systemów podmiotów trzecich, z którymi ma nastąpić w toku realizacji zamówienia integracja. Nawet jeśli wykonawca posiada techniczne możliwości integracji z wieloma systemami, w tym z programem klasy HIS, który użytkuje Zamawiający i za pośrednictwem wielu standardów integracji, a nawet zrealizował już podobne integracje, to nie ma możliwości odwołania się do dokumentacji oprogramowania autorstwa podmiotu trzeciego, w celu wykazania Zamawiającemu spełnienia kwestionowanego wymagania. Taką możliwość miałby jedynie wykonawca, który jest producentem obu systemów – systemu będącego przedmiotem zamówienia i systemu, z którym należy się zintegrować.

Zamawiający w odpowiedzi na odwołanie, w odniesieniu do powyższego zarzutu wskazał w szczególności, że obecnie wymóg posiadania przez oferowany system funkcjonalności „na dzień złożenia oferty" dotyczy 44,5% funkcjonalności. Zamawiający w tej kwestii w porównaniu do poprzedniego postępowania znacznie zmniejszył swoje oczekiwania w stosunku do potencjalnych Dostawców ze względu na to, że posiada wiedzę, iż funkcjonalności wymagają kastomizacji / parametryzacji, do której dostawca uzyska wiedzę na etapie analizy przedwdrożeniowej. Wymóg posiadania funkcjonalności na etapie ofertowania wynika z woli jak najszybszej zmiany systemu w organizacji Zamawiającego ze względu na to, że obecny system nie spełnia założeń Zamawiającego, jest nieefektywny i problematyczny. Spełnienie tego warunku ma zagwarantować, że system zostanie wdrożony sprawnie bez konieczności oczekiwania, aż każda funkcjonalność zostanie przez dostawcę zaprogramowana. Określenie dostępności w tym przypadku odnosi się ściśle do tego, że dana funkcjonalność jest dostępna w podstawie oprogramowania dostawcy, a nie będzie dopiero programowana w trakcie wdrożenia, co znacznie wydłużyłoby jego czas. Aby się przed tym ustrzec są wprowadzone wymagania dotyczące terminu dostępności danej funkcjonalności oraz ich ilości na dzień złożenia oferty. Zamawiający wyjaśnił również, że z OPZ nie wynika obowiązek aby Wykonawca na dzień składania ofert dokonał kastomizacji danej funkcjonalności zgodnie z wymaganiami Zamawiającego. Celem Zamawiającego jest jedynie ustalenie, że daną funkcjonalność system posiada, a tym samym już na dzień składania ofert jest ona gotowa do wdrożenia i kastomizacji. Funkcjonalności, opisane jako dostępne na dzień złożenia oferty mają zagwarantować i określić zdolność Wykonawcę do planowej realizacji zlecenia. Ponadto Odwołujący nie podał żadnego konkretnego przykładu na poparcie swojego uzasadnienia: [... ] które wymagają pozyskania wiedzy na etapie Analizy przedwdrożeniowej (stanowiącej etap realizacji zamówienia), determinujące sposób w jaki sposób wykonawca zrealizuje wymagane funkcjonalności. A nawet gdy takie przykłady jasno wskazał, w związku z powyższymi wyjaśnieniami związanymi z brakiem wymogu kastomizacji czy dostosowania funkcjonalności do wymogów Zamawiającego nie ma podstaw, aby oferowany przez dostawców system nie posiadał w bazie podstawowych funkcjonalności, których Zamawiający oczekuje na etapie ofertowania. Każdy dostawca posiada spisane funkcjonalności dostępne w systemie (najczęściej w postaci listy funkcjonalności) lub nawet dostępne wersje demo systemów do testowania dla potencjalnych klientów - jest to normalna praktyka rynkowa. Wymaganie, aby dostawca systemu ERP posiadał dostępne około 50% funkcjonalności systemu na dzień złożenia oferty, ma zagwarantować Zamawiającemu:

a. Minimalizacja ryzyka wdrożeniowego - Gotowość funkcjonalna na starcie projektu znacząco ogranicza ryzyko opóźnień. Zapewnia, że kluczowe procesy biznesowe będą obsługiwane od początku, bez konieczności długiego oczekiwania na ich rozwój.

b. Weryfikacja dojrzałości rozwiązania - Wysoki poziom dostępnych funkcjonalności świadczy o dojrzałości systemu i jego sprawdzonym zastosowaniu w innych organizacjach. Pozwala ocenić, czy system jest stabilny, skalowalny i gotowy do pracy w środowisku produkcyjnym.

c. Efektywność kosztowa - Im więcej funkcji jest dostępnych „z pudełka”, tym mniejsze koszty dostosowań i rozwoju indywidualnego. Redukuje potrzebę angażowania zespołów developerskich po stronie dostawcy, co również niweluje koszty po stronie Dostawcy systemu.

d.Transparentność oferty - Wymóg ten zmusza dostawcę do jasnego przedstawienia stanu faktycznego systemu w momencie składania oferty. Ułatwia porównanie ofert różnych dostawców na podstawie realnych możliwości, a nie obietnic przyszłego rozwoju.

e.Szybsze osiągnięcie korzyści biznesowych - Im więcej funkcji dostępnych od razu, tym szybciej organizacja może zacząć czerpać korzyści z wdrożenia ERP - np. lepsze raportowanie, automatyzacja procesów, integracja danych.

f.Zgodność z harmonogramem wdrożenia - Wdrożenie ERP to złożony projekt - dostępność funkcji na starcie pozwala lepiej zaplanować kolejne etapy i utrzymać kontrolę nad harmonogramem.

Zamawiający, stwierdził, że zidentyfikował ryzyka w przypadku usunięcia założenia związanego z wymogiem posiadania około 50% funkcjonalności na dzień złożenia oferty:

a.Ryzyko niezgodności z wymogami sprawozdawczości, kontrolą kosztów, wymogami prawnymi - Jeżeli Dostawca nie posiada w swoim pudełkowym rozwiązaniu tych aspektów w jaki sposób może zagwarantować Zamawiającemu, że po wdrożeniu dane funkcjonalności będą dostosowane do zewnętrznych regulacji prawnych

b.Brak integracji z systemami zewnętrznymi (np. ePUAP, PI, systemy PACS) ryzyko konieczności kosztownej integracji lub ręcznego przetwarzania danych z czym Zamawiający obecnie się boryka w wielu przypadkach. Chcąc tego uniknąć w kolejnym rozwiązaniu Zamawiający zakłada pewne bezpieczniki w obecnym postępowaniu przetargowym, które mają zagwarantować bezpieczeństwo wdrożenia.

c.System z niską dostępnością funkcji może być niedojrzały technologicznie, co zwiększa ryzyko błędów i awarii oraz niesprawdzony w praktyce, co utrudnia ocenę jego stabilności i wydajności.

d.Zmniejszenie efektywność kosztowej realizacji projektu mniejsza ilość funkcjonalności oznacza dodatkowe koszty rozwoju, które mogą znacząco przekroczyć budżet oraz wydłużyć czasu wdrożenia, co generuje koszty pośrednie bardzo istotne dla Zamawiającego jak np. konieczność utrzymania starych systemów.

e.Brak transparentności ofert - wymóg dostępności funkcji chroni zamawiającego przed ofertami opartymi na obietnicach, które mogą nie zostać zrealizowane oraz ułatwia porównanie ofert na podstawie realnych możliwości systemu.

Zamawiający wskazał również, że systemy klasy ERP są trzonem zarządzania operacyjnego i finansowego. Od ich sprawności zależy dostęp do informacji i danych umożliwiających sprawność w dostępie do informacji i rzetelność w podejmowaniu decyzji. Tego również oczekuje dla systemu ERP funkcjonującego w szpitalu. Integruje on bowiem kluczowe procesy wewnętrzne i ma za zadanie obsłużenie m.in.: kadry i płace (zatrudnienie, harmonogramy, grafiki, rozliczenia wynagrodzeń), finanse i księgowość (fakturowanie, ewidencja materiałów, ewidencja zakupu, raportowanie, rachunek kosztów), gospodarkę magazynową (leki, materiały medyczne, sprzęt), zakupy i kontraktowanie, sprawozdawczość do instytucji zewnętrznych (NFZ, MZ, GUS). System i jego funkcjonowanie ma bezpośredni wpływ na bezpieczeństwo i ciągłość działania placówki. Błędy lub awarie systemu ERP mogą zdezorganizować pracę całego szpitala - od wynagrodzeń personelu, przez zakupy leków, po rozliczenia z NFZ. Ponadto błędy te mogą stanowić zagrożenie dla życia i zdrowia pacjenta (np. brak zamówienia leku ze względu na niewłaściwą informację w systemie). System bowiem odpowiada za ciągłość przepływu informacji, co ma bezpośrednie przełożenie na jakość opieki nad pacjentem (np. dostępność środków medycznych czy obsada personelu). Złożoność i specyfika szpitala determinuje poziom, skuteczność i złożoność wdrożenia systemu. W szpitalu system ten musi spełniać poza obligatoryjnymi wymogami dla tego typu systemów funkcjonujących w obiegu gospodarczym, specyficzne wytyczne i przepisy prawne i procedur sektora zdrowia, np. rozliczeń z NFZ, ustaw o działalności leczniczej, regulacji kadrowo-płacowych dla personelu medycznego, rozporządzeń ministerialnych (np. standardu rachunku kosztów ). Ponadto wybór systemu ERP ma wieloletni wpływ na funkcjonowanie szpitala, ponieważ: systemy te są wdrażane na lata, wymaga ogromnego nakładu dodatkowej pracy zespołów na etapie wdrażania, zmiana systemu wiąże się z wysokim kosztem migracji danych i reorganizacji pracy, ma na celu usprawnić dotychczasowe procesy, konsekwencje błędnej decyzji mogą się ujawnić dopiero po uruchomieniu systemu. Dlatego konieczne jest, aby system zapewniał odpowiedni katalog funkcjonalności, wykonawca miał potwierdzone doświadczenie, a kierownik projektu wysokie kompetencje. Wdrożenie nowoczesnego ERP jest niezbędne do realizacji celów cyfryzacji sektora ochrony zdrowia oraz udziału w projektach finansowanych ze środków KPO, Funduszu Medycznego czy UE. Bez sprawnego ERP nie jest możliwe: efektywne gromadzenie i przetwarzanie danych, raportowanie wskaźników efektywności, dostęp do danych, wdrażanie nowych technologii, szybkie wprowadzanie zmian, integracja z systemami zewnętrznymi (PI, e-Zdrowie, ZUS, MF itp.).

Z powyżej przestawionego stanowiska Odwołującego wynika, że zakwestionowane postanowienia SWZ rozumie on w ten sposób, że wykonawcy chcąc złożyć ofertę w postępowaniu, muszą przygotować cały system według specyficznych wymagań Zamawiającego, bez gwarancji pozyskania zamówienia. Tymczasem z uwagi na wymagania dotyczące integracji z systemami Zamawiającego lub wymagające konfiguracji i wiedzy przekazanej przez Zamawiającego na etapie Analizy przedwdrożeniowej, w niektórych przypadkach, jest to niewykonalne.

Jak wyjaśnił natomiast Zamawiający, nie chodzi o to, aby już na dzień składania ofert Wykonawca dokonał dostosowania danej funkcjonalności do określonych w SWZ wymagań Zamawiającego, lecz o to, aby system posiadał w standardzie określoną funkcjonalność, która na dzień składania ofert była gotowa do wdrożenia i kastomizacji, co ma zagwarantować zdolność wykonawcy do planowej realizacji zlecenia.

W okolicznościach analizowanej sprawy, zważywszy na to, iż w ww. Informacji nr 6 dla wykonawców z 29 października 2025 r., Zamawiający wskazał, że wprowadzone zmiany stanowią integralną część SWZ i wykonawcy są zobowiązani złożyć ofertę z ich uwzględnieniem, w omawianym zakresie nie należy pomijać odpowiedzi Zamawiającego z na pytanie nr 142 z 29 października 2025 r., dotyczącej Załącznika nr 9 do SWZ, w której Zamawiający poinformował, że wymagania oznaczone jako „OBOWIĄZKOWE” - „Dzień złożenia oferty” zostały określone w taki sposób, aby umożliwić Zamawiającemu ocenę minimalnej funkcjonalności oferowanego systemu w momencie składania oferty. Funkcjonalności te muszą być obecne w oferowanym systemie w standardzie producenta, nie wymagają natomiast pełnej konfiguracji pod specyficzne procesy Zamawiającego.

Oznacza to, że wymóg dotyczy możliwości technicznej integracji i dostępności funkcjonalności w standardzie oferowanego systemu, a nie wykonanej już implementacji pod konkretne środowisko Zamawiającego. Odwołujący nie kwestionuje możliwości technicznej integracji oferowanego systemu z systemami posiadanymi przez Zamawiającego. Przeciwnie potwierdza, że taka możliwość istnieje.

Odwołujący nie wykazał, że przedstawione przez Zamawiającego okoliczności, wskazujące, jego zdaniem, na potrzebę posiadania przez zaoferowany system w standardzie określnych funkcjonalności, nie odpowiadają realiom związanym z przedmiotem zamówienia, nie wykazał, że wymóg, aby oferowany system ERP zapewniał w swojej standardowej wersji podstawowe możliwości integracyjne i funkcjonalne przewidziane w OPZ, naruszał wskazane w odwołaniu przepisy.

W związku z powyższym, w ocenie Izby, jakkolwiek w swoim brzmieniu, postanowienia Załącznika nr 9 do SWZ mogły budzić wątpliwości, to jednak na skutek udzielonych przez Zamawiającego wyjaśnień w zakresie sposobu rozumienia użytych w nim sformułowań, odnoszących się do posiadania przez system określonych funkcjonalności, wątpliwości te zostały wyeliminowane, a stanowisko w tym zakresie zostało podtrzymane w odpowiedzi na odwołanie i na rozprawie.

Z tych względów także te zarzuty podlegają oddaleniu. Stosownie bowiem do art. 552 ust. 1 Pzp 1. Wydając wyrok, Izba bierze za podstawę stan rzeczy ustalony w toku postępowania odwoławczego.

Zgodnie z przepisem art. 554 ust. 1 pkt 1 ustawy Pzp, Izba uwzględnia odwołanie w całości lub w części, jeżeli stwierdzi naruszenie przepisów ustawy, które miało wpływ lub może mieć istotny wpływ na wynik postępowania o udzielenie zamówienia, konkursu lub systemu kwalifikowania wykonawców.

W analizowanej sprawie potwierdził się tylko jeden z sześciu podtrzymanych przez Odwołującego zarzutów odwołania, tj. zarzut nr 3. W związku z czym, w tym zakresie odwołanie podlegało uwzględnieniu, zaś pozostałe zarzuty, tj. 1 lit. a tiret 2, nr 1 lit. b, nr 1 lit. d, nr 6 i nr 7 podlegały oddaleniu. W konsekwencji koszty postepowania obciążały Odwołującego w 5/6 i Zamawiającego w 1/6.

Na koszty postępowania składa się wpis w wysokości 15 000, 00 zł oraz po 3 600,00 zł tytułem wynagrodzenia pełnomocników stron, co łącznie stanowi 22 200,00 zł. 1/5 z tej kwoty to 3 700,00 zł. Odwołujący poniósł koszty w kwocie 18 600,00 zł a powinien zapłacić 18 500,00 zł. Zamawiający poniósł koszty w kwocie 3 600,00 zł a powinien zapłacić 3 700,00 zł. W związku z tym Zamawiający powinien dokonać zapłaty na rzecz Odwołującego kwoty 100,00 zł tytułem zwrotu części kosztów postępowania odwoławczego.

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

Biorąc powyższe pod uwagę, o kosztach postępowania odwoławczego orzeczono stosownie do wyniku postępowania na podstawie art. 557 i art. 575 ustawy Pzp oraz w oparciu o przepisy § 5 pkt 1 i 2 lit. b oraz § 7 ust. 4 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).

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