Wyrok KIO 3612/26 z 26 sierpnia 2026

Zamawiający, Aplikacje Krytyczne sp. z o.o. w Warszawie prowadzi postępowanie o udzielenie zamówienia publicznego, w trybie przetargu nieograniczonego, pn. „Utrzymanie i rozwój informatyczny systemu zarządzania budżetami jednostek samorządu terytorialnego - BeSTi@ i SJO BeSTi@, oraz BeSTi@ API i BeSTi@ Subwencje”, wewnętrzny identyfikator:

PZP/2026/11/W NP-002776. Ogłoszenie o zamówieniu zostało zamieszczone w Suplemencie do Dziennika Urzędowego Unii Europejskiej dnia 13 lipca 2026 r., pod nr: 2026/S 132-479986. Wartość szacunkowa zamówienia przekracza progi unijne.

W dniu 23 lipca 2026 r. do Prezesa Krajowej Izby Odwoławczej wpłynęło odwołanie wykonawcy CGI Polska S.A. w Warszawie (dalej jako: „Odwołujący” lub „CGI”) wobec treści dokumentów zamówienia, w szczególności Specyfikacji Warunków Zamówienia (dalej jako: „SW Z"), Opisu Przedmiotu Zamówienia (dalej jako: „OPZ"), Projektowanych Postanowień Umowy (dalej jako: „PPU") oraz załączników do SWZ i PPU.

Odwołujący zarzucił Zamawiającemu następujące naruszenia:

1. 16 pkt 1 i 3 ustawy z dnia 11 września 2019 r. Prawo zamówień publicznych (tekst jedn. Dz.U. z 2026 r., poz. 793 ze zm., dalej jako „PZP”) oraz art. 112 ust. 1 i 2 PZP poprzez określenie warunku udziału dotyczącego doświadczenia w sposób nieproporcjonalny, nadmiernie szczegółowy i ograniczający konkurencję, ponieważ warunek wymaga wykazania dwóch usług o wartości co najmniej 4.500.000,00 zł netto każda oraz szeregu łącznie ujętych cech funkcjonalnych, organizacyjnych i technologicznych odpowiadających w istocie charakterystyce utrzymywanych Systemów BeSTi@ i SJO BeSTi@;
2. art. 16 pkt 1 i 3 oraz art. 112 ust. 1 i 2 PZP poprzez określenie wymagań wobec osób skierowanych do realizacji

zamówienia w sposób nieproporcjonalny, zbyt wąski i premiujący doświadczenie zdobyte przy systemach odpowiadających obecnej architekturze oraz technologii Systemów Zamawiającego;

1. art. 16 pkt 1–3, art. 240 ust. 1 i 2 oraz art. 242 ust. 1 PZP poprzez ustanowienie kryteriów jakościowych opartych na ocenie elementów eksperckich, niewystarczająco zobiektywizowanych i wymagających informacji o istniejącym Systemie, niedostępnych wszystkim wykonawcom;
2. art. 16 pkt 1 i 3, art. 99 ust. 1 i 4 oraz art. 240 ust. 1 i 2 PZP poprzez zobowiązanie wykonawców do przygotowania szczegółowych koncepcji realizacji ZAD1 i ZAD2 bez udostępnienia informacji technicznych koniecznych do rzetelnego opracowania tych koncepcji;
3. art. 16 pkt 1 i 3 oraz art. 99 ust. 1 P PZP poprzez brak określenia procesu przejęcia utrzymania Systemów przez nowego wykonawcę, pomimo że usługi utrzymaniowe mają rozpocząć się od dnia zawarcia umowy, nie wcześniej niż od 1 stycznia 2027 r.;
4. art. 16 pkt 1 i 3 oraz art. 99 ust. 1 PZP poprzez nieudostępnienie danych niezbędnych do rzetelnego oszacowania kosztów utrzymania Systemów, w tym danych historycznych Service Desk, informacji o stanie Systemów, backlogu, długu technicznym, otwartych zgłoszeniach, kodzie źródłowym, procesie build/deploy oraz historii SLA;
5. art. 16 pkt 1–3, art. 17 ust. 1, art. 99 ust. 1 i 4, art. 112 ust. 1 i 2 oraz art. 240 ust. 1–2 PZP poprzez ukształtowanie dokumentacji w sposób, który łącznie uprzywilejowuje wykonawcę posiadającego historyczną wiedzę o Systemach Zamawiającego;
6. art. 16 pkt 1 i 3 oraz art. 99 ust. 1 i 4 PZP poprzez brak jednoznacznego uregulowania procedury przygotowania, uzgadniania, zlecania, realizacji, odbioru i rozliczania Usług Rozwoju realizowanych w ramach puli 18.000 roboczogodzin.

Mając powyższe na uwadze, Odwołujący wniósł o uwzględnienie odwołania oraz nakazanie Zamawiającemu modyfikacji dokumentów zamówienia, tj. co do:

1. rozdziału VI pkt 2.4 lit. A SW Z – przez określenie warunku doświadczenia jako doświadczenia w utrzymaniu systemów informatycznych o porównywalnej skali, krytyczności i złożoności, bez konieczności wykazania łącznie wszystkich szczegółowych cech Systemów BeSTi@ i SJO BeSTi@ oraz bez wymogu identycznego stosu technologicznego;
2. rozdziału VI pkt 2.4 lit. B SW Z w zakresie Kierownika Projektu, Eksperta ds. Jakości, Eksperta ds. Finansów JST, Eksperta ds. Wieloletniej Prognozy Finansowej, Analityka Systemowego i Projektanta/Wdrożeniowca – przez dopuszczenie doświadczenia personelu w systemach porównywalnych oraz dopuszczenie równoważnych metodyk zarządzania projektami i technologii równoważnych;
3. rozdziału XIX pkt 1. ppkt 1 i 2 SW Z w zakresie kryteriów K1 i K2 przez wskazanie mierzalnych, obiektywnych i weryfikowalnych zasad oceny „poprawności merytorycznej", „kompletności", „spójności" i „wpływu na system" albo usunięcie elementów wymagających wiedzy nieudostępnionej wykonawcom;
4. całokształtu postępowania poprzez udostępnienie dokumentacji technicznej i danych niezbędnych do przygotowania koncepcji ZAD1 i ZAD2, w szczególności informacji o architekturze, modelu danych, zależnościach komponentów, procesie build/deploy, repozytoriach, backlogu, długu technicznym i znanych ograniczeniach;
5. PPU/OPZ poprzez wprowadzenie procedury przejęcia utrzymania Systemów obejmującej transfer wiedzy, przekazanie dokumentacji, środowisk, repozytoriów, bazy zgłoszeń, backlogu, otwartych błędów i ustalenie momentu rozpoczęcia odpowiedzialności za SLA;
6. całokształtu postępowania poprzez udostępnienie historycznych danych eksploatacyjnych i utrzymaniowych, w tym statystyk Service Desk, historii awarii, naruszeń SLA, danych o dostępności, liczbie i strukturze zgłoszeń, sezonowości oraz średnich czasach obsługi;
7. całokształtu postępowania poprzez uzupełnienie dokumentacji o kompletną procedurę realizacji Usług Rozwoju w ramach puli 18.000 roboczogodzin, obejmującą inicjowanie, estymację, uzgadnianie, wykonywanie, odbiór i rozliczanie zleceń, wraz z procedurą postępowania w razie rozbieżności stanowisk stron;
8. całokształtu postępowania poprzez wprowadzenie odpowiedniego przedłużenia terminu składania ofert, tak aby wykonawcy mogli przygotować oferty z uwzględnieniem zmienionej i uzupełnionej dokumentacji.

Ponadto, Odwołujący wniósł o zasądzenie od Zamawiającego na rzecz Odwołującego kosztów postępowania odwoławczego, w tym kosztów zastępstwa przed KIO, według norm przepisanych lub według przedłożonego spisu kosztów. Przedstawił fakturę na kwotę 3.600,00 zł tytułem wynagrodzenia pełnomocnika.

W uzasadnieniu Zarzutu nr 1 – nazwanego: „nieproporcjonalny warunek udziału dotyczący doświadczenia wykonawcy” wskazał, że warunek, o którym mowa w rozdziale VI ust. 2 pkt 4 lit. A SW Z został sformułowany w sposób nadmiernie kazuistyczny, gdyż nie ogranicza się do wykazania doświadczenia w utrzymaniu systemów informatycznych o

porównywalnej skali i złożoności, lecz wymaga wykazania doświadczenia odpowiadającego szczegółowym cechom funkcjonalnym, organizacyjnym i technologicznym obecnych Systemów Zamawiającego. Zdaniem Odwołującego, tak skonstruowany warunek nie ma na celu wyłącznie zweryfikowania zdolności wykonawcy do realizacji zamówienia, lecz w praktyce odpowiada charakterystyce utrzymywanego obecnie Systemu BeSTi@, co prowadzi do nieuzasadnionego ograniczenia konkurencji – faworyzuje bowiem podmioty, które realizowały zadania niemal identyczne jak obecny System BeSTi@. Odwołujący wskazał na wymagania takie, jak: obsługa minimum 1.500 lokalizacji i 3.000 instytucji, architektura rozproszona, wszystkie technologie łącznie: .NET Framework, ASP.NET, React, SOAP, MS SQL, XAdES, PAdES oraz PKI. Wg Odwołującego, Zamawiający nie wykazał, aby wszystkie wskazane cechy doświadczenia pozostawały w bezpośrednim związku z należytym wykonaniem zamówienia lub aby ich łączne spełnienie było niezbędne do oceny zdolności wykonawcy do realizacji zamówienia, w szczególności brak jest uzasadnienia, by doświadczenie w systemach o porównywalnej skali i złożoności, lecz wykorzystujących częściowo odmienne rozwiązania technologiczne, nie miało zapewniać należytego wykonania zamówienia. Jak wskazał Odwołujący, szczególnie ograniczające jest wymaganie doświadczenia w konkretnym, historycznie ukształtowanym stosie technologicznym – lecz wystarczające byłoby, wykazanie doświadczenia w utrzymaniu systemów o porównywalnej złożoności technologicznej i organizacyjnej, przy jednoczesnym zapewnieniu odpowiednich kompetencji zespołu skierowanego do realizacji zamówienia. W zakresie Zarzutu nr 2 pn. „Nieproporcjonalne wymagania wobec personelu”, Odwołujący wskazał, że w rozdziale VI ust. 2 pkt 4 lit.

B i Załączniku nr 12 do SW Z, w odniesieniu do poszczególnych stanowisk wymagania wobec personelu powielają problem wskazany przy warunku doświadczenia wykonawcy, gdyż Zamawiający nie poprzestał na określeniu minimalnych kompetencji niezbędnych do realizacji usług utrzymania i rozwoju Systemów, lecz wymaga od poszczególnych osób doświadczenia osadzonego w bardzo wąskim kontekście funkcjonalnym, organizacyjnym i technologicznym oraz skali i technologii Systemów, co odpowiada niemal dokładnie architekturze, technologii oraz skali obecnie eksploatowanego systemu BeSTi@. Wskazał, na konieczność równoczesnego spełnienia wymagań, takich jak: doświadczenie zdobyte przy systemach funkcjonujących w określonej liczbie lokalizacji, doświadczenie zdobyte przy systemach obsługujących określoną liczbę instytucji, doświadczenie wyłącznie w bardzo wąskich obszarach funkcjonalnych, doświadczenie w konkretnym stosie technologicznym, wymagania dotyczące konkretnych metodyk zarządzania projektami. Konkretne wymagania odniósł do poszczególnych stanowisk. W szczególności, w odniesieniu do Kierownika Projektu wskazał, że Zamawiający wymaga doświadczenia w projektach obejmujących co najmniej 3.000 instytucji oraz certyfikatu PRINCE2, lecz nie wykazał, dlaczego doświadczenie zdobyte przy projektach o mniejszej skali lub prowadzenie projektów zgodnie z innymi uznanymi metodykami (PMI/PMBOK, IPMA, AgilePM) nie zapewnia należytego wykonania zamówienia w stopniu porównywalnym. Dalej, co do Eksperta ds. Finansów JST, zdaniem Odwołującego, wymaganie doświadczenia wyłącznie w systemach finansów JST eliminuje osoby posiadające doświadczenie w innych dużych systemach finansowych sektora publicznego, mimo że zakres kompetencji może być równoważny. Podobnie co do Eksperta ds. Wieloletniej Prognozy Finansowej, gdzie Zamawiający wymaga wąskiej specjalizacji w zakresie Wieloletniej Prognozy Finansowej. W kontekście stanowiska Analityka Systemowego, Odwołujący wskazał, że wymagania odnoszą się do znajomości konkretnej architektury technologicznej obecnego systemu, a nie do kompetencji analitycznych. Dodał, że liczba lokalizacji nie stanowi obiektywnego miernika kompetencji Analityka Systemowego. Analogicznie w odniesieniu do Projektanta/Wdrożeniowca. Podsumował, że takie wymagania prowadzą do nieuzasadnionego zawężenia dostępnego rynku specjalistów, gdyż tworzą system wymagań, którego spełnienie jest możliwe przede wszystkim przez osoby uczestniczące wcześniej w realizacji projektów odpowiadających niemal dokładnie architekturze, technologii oraz organizacji obecnie eksploatowanego systemu. W ocenie Odwołującego bowiem, liczba lokalizacji lub instytucji korzystających z systemu nie jest sama w sobie miernikiem kompetencji projektowych, analitycznych, jakościowych lub wdrożeniowych, podobnie jak wymóg doświadczenia wyłącznie w PRINCE2 nie uwzględnia równoważnych, uznanych metodyk zarządzania projektami, takich jak PMI/PMBOK, IPMA czy AgilePM. W zakresie Zarzutu nr 3 pn. „Nieproporcjonalne i niewystarczająco zobiektywizowane kryteria oceny koncepcji ZAD1 i ZAD2”, Odwołujący podniósł, że SW Z w rozdziale XIV ust. 7-8 ustanawia kryteria oceny ofert, które zostały opisane w sposób niedookreślony, obejmują ocenę elementów niemających charakteru obiektywnie weryfikowalnego i przez to nie zapewniają wykonawcom możliwości przewidzenia, jakie rozwiązania będą oceniane najwyżej. Wskazał, że dokumentacja postępowania nie wskazuje, według jakich obiektywnych kryteriów komisja przetargowa będzie

weryfikowała: a) poprawność analizy wpływu proponowanych zmian na istniejący system, b) poprawność identyfikacji ryzyk, c) prawidłowość proponowanego harmonogramu, d) zasadność deklarowanej pracochłonności, e) wpływ proponowanego rozwiązania na utrzymanie i rozwój systemu, ani nie określa jakie konkretne cechy rozwiązania uzasadniają przyznanie 50% punktów, a jakie 100% punktów dla każdego z ocenianych elementów, tzn. nie wskazano, jakie minimalne wymagania należy spełnić, aby opis został uznany za „kompletny”, ani jakie braki powodują zakwalifikowanie go jako jedynie „niepełnego”, w konsekwencji granica pomiędzy oceną 50% i 100% pozostaje całkowicie uznaniowa. Wg Odwołującego, szczególnie problematyczna jest kwestia oceny wpływu rozwiązania na istniejący system, jego architekturę, utrzymanie i rozwój, a także ocena ryzyk oraz pracochłonności, gdyż te elementy wymagają szczegółowej wiedzy o rzeczywistej architekturze, jakości kodu, zależnościach pomiędzy komponentami, procesie wdrożeniowym i utrzymaniowym, której dokumentacja postępowania nie udostępnia w sposób wystarczający wykonawcom. Zatem, w ocenie Odwołującego, kryterium to nie pozwala racjonalnie przygotować oferty ani przewidzieć sposobu jej oceny, gdyż ocena ofert nie będzie opierała się na możliwych do zweryfikowania parametrach, lecz na eksperckiej ocenie komisji. W odniesieniu do uzasadnienia Zarzutu nr 4, pn. „Niewystarczający opis przedmiotu zamówienia poprzez zobowiązanie do przygotowania koncepcji ZAD1 i ZAD2 bez udostępnienia niezbędnych informacji technicznych”, Odwołujący wskazał, że w tym zakresie, Zamawiający naruszył przepisy PZP poprzez opisanie przedmiotu zamówienia w sposób niewystarczający do sporządzenia ofert oraz jednoczesne zobowiązanie wykonawców do przygotowania szczegółowych koncepcji realizacji zadań ZAD1 i ZAD2, których opracowanie wymaga informacji technicznych nieudostępnionych wykonawcom, w tym analizy wpływu na system i jego architekturę, identyfikacji ryzyk, harmonogramu oraz pracochłonności. Wskazał, że w dokumentacji postępowania zabrakło informacji nt. architektury technicznej systemów, zależności pomiędzy komponentami, modelu danych, architektury integracyjnej, dokumentacji repozytoriów kodu źródłowego, procesu budowy i wdrażania oprogramowania, procesu wersjonowania, backlogu zmian, długu technicznego, znanych ograniczeń architektonicznych, wyników audytów technicznych, informacji o aktualnym stanie systemu. Wskazał na wymagania podlegające ocenie w ramach ww. kryteriów i informacje niezbędne do ich przygotowania. Podkreślił, że bez udostępnienia dokumentacji technicznej wykonawcy mogą jedynie formułować przypuszczenia co do rzeczywistej architektury rozwiązania, a zatem ocenie będą podlegać nie analizy odnoszące się do faktycznego stanu systemu, lecz hipotezy wykonawców oparte na niepełnych informacjach. Dodał, że brak informacji niezbędnych do sporządzenia wymaganych analiz powoduje, że wykonawca posiadający wiedzę wynikającą z wcześniejszego uczestnictwa w utrzymaniu lub rozwoju systemu znajduje się w istotnie korzystniejszej sytuacji niż pozostali uczestnicy postępowania, gdyż posiada on wiedzę dotyczącą rzeczywistej architektury systemu, zależności pomiędzy komponentami, istniejących ograniczeń technicznych oraz procesu rozwoju systemu, która nie została udostępniona wszystkim wykonawcom. Co do Zarzutu nr 5 pt. „Brak określenia zasad przejęcia utrzymania Systemów”, wykonawca CGI zarzucił, że w treści dokumentów zamówienia Zamawiający nie określił zasad przejęcia świadczenia usług utrzymaniowych przez nowego wykonawcę, pomimo że przedmiot zamówienia dotyczy utrzymania rozbudowanego, wieloletniego systemu informatycznego o znaczeniu krytycznym. Wymienił elementy, których określenia brakuje, w szczególności okresu przejściowego, procesu transferu wiedzy, współpracy z dotychczasowym wykonawcą, harmonogramu przekazania systemu, zasad przekazania środowisk, zasad przekazania otwartych zgłoszeń, zasad przekazania backlogu, zasad przekazania konfiguracji środowisk, procedur przekazania repozytoriów i procesu build/deploy, momentu rozpoczęcia pełnej odpowiedzialności nowego wykonawcy za świadczenie usług, procedury przekazania uprawnień administracyjnych, zasady przekazania certyfikatów, kluczy i kont technicznych. Podkreślił, że dokumentacja przewiduje obowiązek transferu wiedzy po zakończeniu realizacji umowy, jednocześnie nie przewiduje analogicznego mechanizmu umożliwiającego przejęcie wiedzy i odpowiedzialności przez nowego wykonawcę przed rozpoczęciem świadczenia usług. W konsekwencji, zdaniem Odwołującego, nałożenie pełnej odpowiedzialności od pierwszego dnia w tym odpowiedzialności za dotrzymanie parametrów SLA oraz kar umownych, bez procedury transition, przenosi na wykonawcę ryzyka, na które nie ma wpływu. Dodał, że dokumentacja nie określa również, od jakiego momentu rozpoczyna się bieg parametrów SLA w odniesieniu do zgłoszeń istniejących w chwili przejęcia utrzymania ani czy czas niezbędny na przekazanie wiedzy, uzyskanie dostępów oraz przejęcie środowisk podlega wyłączeniu z odpowiedzialności wykonawcy, co powoduje niemożność określenia rzeczywistego zakresu odpowiedzialności kontraktowej już od pierwszego dnia realizacji umowy. W konsekwencji, w ocenie Odwołującego,

wykonawcy nie są w stanie określić, kiedy uzyskają rzeczywisty dostęp do systemu, kiedy będą mogli rozpocząć analizę kodu źródłowego, kiedy przejmą odpowiedzialność za zgłoszenia będące w toku, od którego momentu będą ponosić odpowiedzialność za dotrzymanie parametrów SLA, jaki nakład prac należy uwzględnić na przejęcie utrzymania systemu. Odwołujący wskazał, że w postępowaniach dotyczących przejęcia utrzymania rozbudowanych systemów informatycznych określenie procedury transition jest standardem rynkowym. Odnosząc się do Zarzutu nr 6 pn. „Niepełny opis przedmiotu zamówienia uniemożliwiający rzetelną kalkulację ceny oferty”, Odwołujący wskazał, że Zamawiający przewidział model wynagrodzenia ryczałtowego, a zatem ryzyko ekonomiczne powinno być możliwe do oszacowania na podstawie dokumentacji postępowania, tymczasem Zamawiający nie udostępnił informacji pozwalających wykonawcom określić rzeczywisty zakres prac, poziom ryzyka technicznego i ekonomicznego oraz przewidywane koszty świadczenia usług utrzymaniowych, w szczególności takich jak: statystyki Service Desk, informacje o rzeczywistym stanie systemu, informacje w zakresie oceny jakości kodu źródłowego, informacje o rzeczywistym procesie utrzymania, historyczne dane dot. realizacji SLA. Wyjaśnił, w jaki sposób brak podania ww. kategorii danych wpływa na możliwość skalkulowania oferty.

Podsumował, że w takiej sytuacji, oferty mogą okazać się nieporównywalne, co pozostaje w sprzeczności z zasadami uczciwej konkurencji oraz obowiązkiem jednoznacznego i wyczerpującego opisu przedmiotu zamówienia. W zakresie Zarzutu nr 7 pn. „Naruszenie zasad konkurencji przez łączny efekt postanowień dokumentacji”, Odwołujący podniósł, że Zamawiający naruszył zasadę uczciwej konkurencji oraz równego traktowania wykonawców poprzez ukształtowanie dokumentacji postępowania w sposób, który w efekcie prowadzi do uprzywilejowania wykonawcy posiadającego wiedzę wynikającą z wcześniejszego uczestnictwa w utrzymaniu lub rozwoju systemu BeSTi@. Zarzut ten Odwołujący odniósł w związku z oddziaływaniem całokształtu wymagań oraz braków dokumentacji, które jego zdaniem wzajemnie się uzupełniają i powodują, że wykonawcy nieposiadający wcześniejszej wiedzy o systemie nie mają rzeczywistej możliwości przygotowania oferty konkurencyjnej na równych zasadach. Wskazał, że do powstania ww. sytuacji prowadzi jednoczesne występowanie następujących okoliczności: bardzo szczegółowo określonych warunków udziału odnoszących się do doświadczenia wykonawcy, bardzo szczegółowych wymagań dotyczących doświadczenia personelu, nieudostępnienia dokumentacji technicznej systemu, nieudostępnienia informacji o architekturze rozwiązania, nieudostępnienia informacji o backlogu, długu technicznym i znanych ograniczeniach systemu, nieudostępnienia informacji dotyczących rzeczywistego procesu budowy, wdrażania oraz utrzymania systemu, obowiązku przygotowania szczegółowych koncepcji realizacji zadań ZAD1 i ZAD2, oceny wpływu proponowanych zmian na istniejącą architekturę systemu, oceny wpływu zmian na utrzymanie i rozwój systemu, oceny identyfikacji ryzyk, oceny harmonogramu realizacji, oceny deklarowanej pracochłonności. Jak uznał Odwołujący, każdy z powyższych elementów rozpatrywany oddzielnie mógłby zostać uznany za dopuszczalny, jednak ich jednoczesne zastosowanie powoduje efekt kumulacji ograniczeń, w wyniku którego wykonawcy nieposiadający wcześniejszej wiedzy o systemie nie mają rzeczywistej możliwości przygotowania oferty na równych zasadach. W szczególności, wg Odwołującego, wykonawca aktualnie utrzymujący system dysponuje wiedzą, której pozostali uczestnicy postępowania nie są w stanie pozyskać wyłącznie na podstawie dokumentacji przetargowej – tym samym, wykonawca posiadający taką wiedzę uzyskuje przewagę konkurencyjną, której pozostali wykonawcy nie są w stanie zniwelować pomimo posiadania odpowiedniego doświadczenia oraz potencjału technicznego, skąd wynika naruszenie zasad uczciwej konkurencji. Wg Zarzutu nr 8 pn.

„Niejednoznaczne zasady realizacji i rozliczania puli 18 000 roboczogodzin”, Odwołujący zarzuca, że dokumentacja postępowania nie zawiera jednoznacznych zasad regulujących sposób przygotowania, uzgadniania, realizacji oraz rozliczania Zleceń dostosowań/zmian w ramach świadczenia Usług Rozwoju. W szczególności, zdaniem Odwołującego brakuje informacji nt. tego, kto sporządza analizę oraz estymację prac, kto zatwierdza estymację, czy Zamawiający jest uprawniony do jednostronnej zmiany estymacji przedstawionej przez wykonawcę, w jaki sposób postępuje się w przypadku rozbieżności stanowisk stron dotyczących zakresu lub pracochłonności planowanych prac, kiedy Zlecenie dostosowań/zmian uznaje się za uzgodnione i przyjęte do realizacji, czy oraz w jakich przypadkach wykonawca może odmówić realizacji Zlecenia, według jakich zasad następuje odbiór wykonanych prac oraz rozliczenie roboczogodzin, w jaki sposób postępuje się w przypadku przekroczenia uzgodnionej estymacji. Jak wyjaśnił Odwołujący, brak powyższych informacji powoduje, że wykonawcy zmuszeni są samodzielnie przyjmować założenia dotyczące sposobu realizacji Usług Rozwoju oraz zakresu ryzyka kontraktowego związanego z ich wykonywaniem, co prowadzi do przygotowania ofert opartych na różnych założeniach dotyczących tego samego przedmiotu zamówienia i narusza zasadę

porównywalności ofert. Zaznaczył, że chodzi o istotną część przedmiotu zamówienia, realizowanej w ramach puli 18 000 roboczogodzin.

W odpowiedzi z dnia 11 sierpnia 2026 r. na odwołanie, Zamawiający wniósł o oddalenie odwołania w całości oraz zasądzenie kosztów zastępstwa procesowego zgodnie z fakturą przedłożoną na rozprawie oraz opłaty skarbowej od pełnomocnictwa. Na rozprawie przedstawił fakturę na kwotę 2.999,99 zł brutto tytułem wynagrodzenia pełnomocnika. Na wstępie, Zamawiający opisał historię Systemów, wskazując, że funkcjonują od wielu lat jako element krajowej infrastruktury wspierającej zarządzanie finansami samorządowymi i stanowią podstawowe narzędzie wykorzystywane do gromadzenia, przetwarzania, walidacji oraz przekazywania danych finansowych pomiędzy tysiącami jednostek sektora finansów publicznych, a na ich podstawie prowadzone lub sporządzane są analizy finansowe, sprawozdania budżetowe i finansowe, realizowane zadań nadzorcze Regionalnych Izb Obrachunkowych oraz wykonywane przez Ministra Finansów obowiązki związane z monitorowaniem sytuacji finansowej jednostek samorządu terytorialnego.

Opisał Systemy, jako rozproszone środowisko teleinformatyczne, wykorzystywane przez: Ministerstwo Finansów, Regionalne Izby Obrachunkowe i ich zespoły zamiejscowe, gminy, powiaty, miasta na prawach powiatu, województwa samorządowe, związki jednostek samorządu terytorialnego, jednostki organizacyjne jednostek samorządu terytorialnego.

Jak wskazał Zamawiający, ze względu na skalę wykorzystania oraz znaczenie przetwarzanych danych systemy stanowią jedno z podstawowych narzędzi zapewniających prawidłowy przepływ informacji finansowej w sektorze samorządowym. Przedstawił dokładną charakterystykę poszczególnych Systemów, tj. BeSTi@, SJO BeSTi@, BeSTi@ API, BeSTi@ Subwencje. Odnosząc się do Zarzutu nr 1, Zamawiający wskazał, że przedstawiona argumentacja ma w znacznej mierze charakter ogólny i nie odnosi się w sposób konkretny do poszczególnych wymagań określonych w SW Z ani do rzeczywistych uwarunkowań realizacji przedmiotu zamówienia, w szczególności Odwołujący nie przeprowadza odrębnej analizy warunku w kontekście wymagań dotyczących skali systemu, jego rozproszonej architektury, charakteru obsługiwanych procesów, liczby użytkowanych podmiotów czy stosowanych technologii, ograniczając się do zakwestionowania ich łącznego ujęcia. Podkreślił, że to na Odwołującym ciąży ciężar dowodowy, podnosząc, że to Odwołujący, formułując zarzut naruszenia zasad proporcjonalności i uczciwej konkurencji, powinien przedstawić okoliczności faktyczne pozwalające stwierdzić, że Zamawiający przekroczył granice dopuszczalnego kształtowania warunków udziału w postępowaniu, zaś samo twierdzenie, że Zamawiający nie wykazał konieczności zastosowania określonego wymagania, nie zastępuje wykazania przez Odwołującego, że wymaganie to pozostaje nieproporcjonalne, niezwiązane z przedmiotem zamówienia albo nieprzydatne dla oceny zdolności wykonawcy. Niezależnie od powyższego, zdaniem Zamawiającego, zarzut nie zasługuje na uwzględnienie, gdyż poszczególne elementy warunku pozostają w bezpośrednim związku z zakresem i specyfiką zamówienia, a ich łączne wymaganie znajduje uzasadnienie w charakterze usług, które mają być świadczone przez wykonawcę. Tym samym, jak wyjaśnił Zamawiający, skoro zamówienie polega przede wszystkim na utrzymaniu Systemu o konkretnych cechach to Zamawiający ma uzasadniony interes w tym, aby wykonawca posiadał w tym zakresie doświadczenie. Podkreślił, że nie oznacza to, że Zamawiający wymaga doświadczenia w utrzymaniu Systemu BeSTi@, SJO BeSTi@ czy systemu tożsamego z systemami objętymi przedmiotem zamówienia oraz, że ustalony przez Zamawiającego warunek udziału nie wymaga doświadczenia w systemie o identycznej funkcjonalności, architekturze czy technologii. Wyjaśnił, że wymagane jest doświadczenie w utrzymaniu systemu/ów o określonych w SW Z cechach, tj. odpowiedniej skali, rozproszeniu oraz złożoności funkcjonalno-technologicznej, odpowiadającej charakterowi niniejszego zamówienia oraz, że ma to szczególne znaczenie w przypadku wymogu dotyczącego architektury rozproszonej i liczby lokalizacji (1.500 lokalizacji), przy czym te ostatnie parametry są mierzalnymi parametrami doświadczenia wykonawcy w utrzymaniu środowiska funkcjonującego jednocześnie w dużej liczbie niezależnych środowisk eksploatacyjnych. Zamawiający wyjaśnił dodatkowo, że wymagane dot. 1.500 lokalizacji stanowi mniej niż 5% liczby jednostek wskazanych w OPZ (35 tys.), a zatem wymóg ten nie może być postrzegany doświadczenie odpowiadające pełnej skali środowiska Systemu Zamawiającego. Wskazał, że analogicznie należy ocenić wymagania dot. charakteru biznesowego Systemu, gdyż Zamawiający nie wymaga doświadczenia w utrzymaniu systemu realizującego dokładnie takie same procesy jak Systemy BeSTi@, lecz by co najmniej jedna z usług obejmowała system obsługujący procesy związane ze sprawozdawaniem z realizacji budżetu, dystrybucją lub alokacją środków finansowych oraz analizami finansowymi i modelami symulacyjnymi w oparciu o dane znacznej liczby podmiotów. Wyjaśnił, że wymagania te mają potwierdzać doświadczenie wykonawcy w utrzymaniu

systemów, których funkcjonowanie jest związane z procesami finansowymi realizowanymi na dużą skalę oraz przetwarzaniem danych pochodzących od znacznej liczby niezależnych podmiotów, z kolei, wskazana przez Odwołującego kategoria „systemu enterprise” nie stanowi wystarczającego miernika doświadczenia wymaganego w niniejszym postepowaniu. Wskazał, że podobna sytuacja dot. wymagań technologicznych, tj. wymogu dot. technologii Microsoft .NET Framework (Windows Forms), ASP.NET, XAdES, PAdES, MS SQL Server, Web Services (SOAP) i React.js. i wyjaśnił, że skoro wykonawca nie będzie rozpoczynał realizacji zamówienia od zaprojektowania własnego stosu technologicznego, lecz będzie zobowiązany do utrzymywania istniejących komponentów, usuwania błędów, rozwijania funkcjonalności, dostosowywania systemu do zmian prawnych i technologicznych oraz diagnozowania problemów występujących pomiędzy poszczególnymi warstwami środowiska, a zatem wg Zamawiającego wymóg doświadczenia w łącznym wykorzystaniu wskazanych technologii pozwala zweryfikować, czy wykonawca miał już do czynienia ze środowiskiem, w którym współdziałają komponenty o różnym charakterze – aplikacyjnym, webowym, bazodanowym i integracyjnym. Odnosząc się do żądania odwołania, Zamawiający podniósł, że jest ono blankietowe, tj. pojęcia takie jak „system porównywalny”, „podobna skala”, „podobna złożoność” czy „technologie równoważne” – bez wskazania konkretnych kryteriów ich oceny – nie dają Zamawiającemu obiektywnego narzędzia do dokonania kwalifikacji podmiotowej wykonawcy, zaś w świetle przepisów PZP, warunek udziału w postępowaniu musi pozwalać tak wykonawcy, jak też zamawiającemu na ustalenie i zweryfikowanie, czy wykonawca warunek spełnia, a zatem nie może być określony w sposób nieostry. Zamawiający wskazał ponadto, że konkurencja nie może być osiągana poprzez rezygnację z możliwości rzeczywistego zweryfikowania doświadczenia niezbędnego do należytego wykonania zamówienia ani poprzez zastępowanie obiektywnych kryteriów kategoriami niedookreślonymi. W odniesieniu do Zarzutu 2, Zamawiający jest zdania, że wymagania wobec personelu zostały określone z uwzględnieniem rzeczywistego zakresu zadań przypisanych poszczególnym funkcjom oraz specyfiki usług utrzymania i rozwoju środowiska będącego przedmiotem zamówienia. Wskazał, że w przypadku Kierownika Projektu, znaczenie ma doświadczenie w zarządzaniu przedsięwzięciami informatycznymi o odpowiedniej skali oraz w stosowaniu uporządkowanej metodyki zarządzania, w przypadku Eksperta ds. Jakości – doświadczenie w kontroli jakości usług utrzymaniowych oraz znajomość ITIL i metodyk testowania, w przypadku Analityka Systemowego oraz Projektanta/Wdrożeniowca wymagania dotyczą doświadczenia w analizie, projektowaniu lub wdrażaniu systemów, w tym w środowisku o wymaganej charakterystyce technologicznej, podobnie rzecz się ma z wymaganiami dotyczącymi Eksperta ds. Finansów Samorządu Terytorialnego oraz Eksperta ds. Wieloletniej Prognozy Finansowej. Podkreślił, że zadaniem osób wskazanych na te stanowiska jest nie tylko zapewnienie kompetencji informatycznych, ale również specjalistycznej wiedzy merytorycznej dotyczącej procesów, które systemy objęte zamówieniem mają obsługiwać. Wyjaśnił, że nie chodzi o znajomość konkretnego produktu, lecz o praktyczne doświadczenie w realizacji zadań w środowisku, w którym występują wymagane technologie i mechanizmy.

Podniósł, że Odwołujący nie wykazał, aby którekolwiek z zakwestionowanych wymagań było nieprzydatne do oceny zdolności personelu do realizacji zamówienia, oderwane od zakresu powierzonych funkcji albo ustanowione ponad poziom niezbędny dla zapewnienia należytego wykonania usług. W zakresie Zarzutu nr 3, Zamawiający podniósł, że Odwołujący błędnie utożsamia obiektywność kryterium z koniecznością jego pełnej matematyzacji. Podkreślił, że wg PZP dopuszczalne są kryteria jakościowe i wymagające oceny eksperckiej, o ile ich przedmiot, zakres oraz sposób oceny zostały określone w sposób pozwalający wykonawcom przewidzieć zasady oceny ofert i podlegający późniejszej kontroli.

Wyjaśnił, że w przypadku kwestionowanych kryteriów – ocenie podlega sposób rozwiązania konkretnych problemów, które mogą wystąpić w ramach utrzymania i rozwoju Systemów, zaś zakres wymaganych koncepcji został określony przez Zamawiającego. Podniósł również, że to wykonawca ma zaproponować rozwiązanie możliwe do wdrożenia w obecnym środowisku, a zatem Zamawiający nie może przedstawić wykonawcom gotowych sposobów lub określonych parametrów. Wg Zamawiającego, nie oznacza to jednak, że ocena będzie dokonywana dowolnie, gdyż zadaniem komisji jest ocena przedstawionych przez wykonawcę rozwiązań w granicach elementów wskazanych w SW Z i przy zastosowaniu określonej w niej skali i wg tego samego mechanizmu (0%, 50% i 100%). Zamawiający wyjaśnił ponadto, że pojęcia takie jak „poprawność merytoryczna”, czy „kompletność” to naturalna konsekwencja jakościowego charakteru kryterium. Zaprzeczył, że wykonawcy mają przygotowywać Koncepcje w oderwaniu od informacji o środowisku, którego dotyczą i wskazał na dostępność dokumentacji systemów i ich wersji instalacyjnych. W konsekwencji, w ocenie Zamawiającego nie można przyjąć, że ocena Koncepcji będzie opierała się na wiedzy dostępnej wyłącznie podmiotom,

które wcześniej realizowały zamówienia na rzecz Zamawiającego. Poza tym, Zamawiający, Aplikacje Krytyczne sp. z o.o., podkreślił, że nie może zakładać, że wszystkie przyszłe prace rozwojowe da się na etapie postępowania opisać w sposób wyczerpujący i sprowadzić do z góry określonych parametrów, a zatem wykorzystanie przykładowych, konkretnie opisanych zadań pozwala zweryfikować jeszcze przed zawarciem umowy, w jaki sposób wykonawca podchodzi do analizy problemu, projektowania rozwiązania, zarządzania ryzykiem i planowania jego realizacji. Dodał, że Odwołujący nie wskazał, jaki konkretny, dodatkowy mechanizm oceny miałby zostać zastosowany, aby – przy zachowaniu charakteru jakościowego Koncepcji – możliwe było dokonanie oceny zgodnej z jego oczekiwaniami. W ramach zarzutu nr 4 Odwołującego dot. niewystarczającego opisu przedmiotu zamówienia w zakresie ZAD1 i ZAD2, Zamawiający zaznaczył po pierwsze, że zarzut ten został oparty na stanie dokumentacji, który uległ zmianie w toku postępowania. Niezależnie od powyższego, wskazał, że nie sposób zgodzić się z twierdzeniem, że przed dokonaniem modyfikacji wykonawcy nie dysponowali informacjami pozwalającymi na przygotowanie koncepcji, gdyż informacje te są w znacznym zakresie publicznie dostępne, w szczególności: dokumentacja i materiały dotyczące systemów BeSTi@ i SJO BeSTi@ udostępnione są na portalu serwisowym „SJO BeSTi@ – Portal serwisowy systemów BeSTi@ i SJO BeSTi@”, dostępnym pod adresem: https://budzetjst.pl/ W szczególności publicznie dostępna (https://budzetjst.pl/pobieranie/dokumentacja) jest dokumentacja użytkownika i administratora, specyfikacje wejściawyjścia, raporty i analizy, materiały szkoleniowe oraz materiały pomocnicze, dostępne są również pełne wersje instalacyjne systemów BeSTi@ i SJO BeSTi@. W ocenie Zamawiającego, materiały te pozwalają na zapoznanie się z funkcjonalnością Systemów, ich przeznaczeniem, sposobem obsługi, realizowanymi procesami biznesowymi oraz zakresem wymiany danych. W zakresie Zarzutu nr 5, Zamawiający wskazał, że dokonał zmian w SW Z, które pozwolą wykonawcy na przygotowanie się do świadczenia usług jeszcze przed ich rozpoczęciem, a przewidziany miesięczny okres uruchomienia usług dodatkowo zapewnia czas na organizacyjne przygotowanie realizacji zamówienia. Podkreślił jednocześnie, że w niniejszym zamówieniu nie występuje sytuacja, którą zakłada Odwołujący, tj. konieczność przejęcia przez nowego wykonawcę bieżących prac rozwojowych lub zgłoszeń rozpoczętych przez poprzedniego wykonawcę, gdyż Zamawiający przewidział zakończenie przez dotychczasowego wykonawcę realizowanych przez niego zgłoszeń i zleceń niezależnie od rozpoczęcia świadczenia usług przez wykonawcę wyłonionego w niniejszym postępowaniu. Tym samym, jak wyjaśnił, nowy wykonawca będzie zatem rozpoczynał realizację nowych zgłoszeń i nowych zleceń w ramach zawartej umowy, a nie przejmował odpowiedzialność za prace rozpoczęte przez poprzedniego wykonawcy, co oznacza, że nie zachodzi również potrzeba tworzenia szczególnej procedury przekazania otwartego backlogu, otwartych zleceń czy określania zasad przejmowania odpowiedzialności za ich realizację i związanych z nimi parametrów SLA.

Wobec Zarzutu nr 6, Zamawiający również wskazał na dokonane modyfikacje, jednocześnie podnosząc, że nie sposób uznać, że dla prawidłowej kalkulacji wynagrodzenia konieczne jest udostępnienie wykonawcom backlogu prac rozwojowych, informacji o przyszłych zmianach czy też listy zgłoszeń, które miałyby zostać przejęte przez nowego wykonawcę, zamówienie nie zakłada bowiem przejęcia przez nowego wykonawcę realizacji prac rozpoczętych przez dotychczasowego wykonawcę – wykonawca wyłoniony w niniejszym postępowaniu będzie realizował nowe zadania i nowe zlecenia. Biorąc pod uwagę procedurę zlecania prac rozwojowych, Zamawiający wyjaśnił, że wykonawca będzie dokonywał wyceny pracochłonności konkretnych zleceń, a prace będą realizowane dopiero po ich uzgodnieniu zgodnie z procedurą określoną w dokumentach zamówienia, a zatem brak wiedzy o backlogu nie może stanowić przeszkody w kalkulacji ceny oferty, skoro zakres przyszłych prac rozwojowych nie jest na tym etapie przedmiotem wyceny. Dodał, że usługi utrzymania mają charakter bieżący i są realizowane w odniesieniu do rzeczywistego stanu Systemów w okresie obowiązywania umowy, zatem nie jest ani możliwe ani konieczne opisanie z góry wszystkich przyszłych zdarzeń, problemów i potrzeb użytkowników, które mogą wystąpić w okresie 24 miesięcy świadczenia usług. W ramach Zarzutu nr 7, Zamawiający wskazał, że zarzut ten stanowi w istocie zbiorcze powtórzenie argumentacji odnoszącej się do poszczególnych postanowień dokumentacji, przy czym Odwołujący nie wykazuje, że ich łączne zastosowanie prowadzi do skutku odmiennego niż wynikający z oceny każdego z tych elementów. Zdaniem Zamawiającego, samo zestawienie kilku zgodnych z PZP wymagań nie oznacza jeszcze naruszenia art. 16 PZP, a ponadto, część założeń, na których Odwołujący opiera zarzut, jest obecnie nieaktualna, wobec dokonanych zmian SW Z. Odnosząc się na koniec do Zarzutu nr 8, Zamawiający podniósł, że zarzut ten wynika z wybiórczego odczytania dokumentacji postępowania, albowiem zasady realizacji Usług Rozwoju zostały określone w dokumentach zamówienia, w szczególności w załączniku nr 1 do

SW Z – OPZ , załączniku nr 7 do SW Z – PPU oraz Procedurze wprowadzania zmian do Systemów, zaś dokumenty te należy odczytywać integralnie, a nie w oderwaniu od siebie. Jak wskazał Zamawiający, wbrew twierdzeniom Odwołującego, dokumentacja nie ogranicza się do określenia liczby roboczogodzin oraz wzoru zlecenia – Procedura wprowadzania zmian do Systemów stanowi element dokumentacji regulującej sposób realizacji Usług Rozwoju, a wzór zlecenia służy jej wykonaniu. Dodał również, że zupełnie chybiony jest zarzut, jakoby Zamawiający mógł jednostronnie narzucić wykonawcy realizację dowolnych prac w ramach puli 18 000 roboczogodzin, skoro warunkiem realizacji zmiany jest jej uprzednie uzgodnienie przez strony, po stronie wykonawcy nie ma zatem ryzyka wykonania prac, które nie zostały przez strony uzgodnione. W konsekwencji, jak wyjaśnił Zamawiający, nie sposób przyjąć, że wykonawcy muszą samodzielnie przyjmować odmienne zasady realizacji Usług Rozwoju lub kalkulować ryzyko związane z obowiązkiem wykonania nieuzgodnionych prac, gdyż zasady te wynikają z dokumentacji postępowania, która – czytana jako całość – określa zarówno mechanizm zlecania zmian, jak i warunek ich uzgodnienia przed przystąpieniem do realizacji. W ocenie Zamawiającego dokumentacja postępowania zapewnia zatem wykonawcom jednolite i wystarczające podstawy do przygotowania ofert oraz kalkulacji ceny.

Zamawiający wprowadził modyfikacje postanowień dokumentów zamówienia w dniach 11 oraz 21 sierpnia. Zmiany te wchodzą w zakres niektórych Zarzutów odwołania. W zakresie Zarzutu nr 1, zmiany z 11 sierpnia polegały na dopuszczeniu możliwości wykazania doświadczenia biznesowego i technologicznego w ramach tej samej albo różnych usług, a także dopuszczeniu wykazania wszystkich wymaganych technologii w ramach kilku projektów referencyjnych (przy czym co najmniej trzy w ramach jednego projektu). Zmiany te odnosiły się również do Zarzutu nr 2, w przypadku którego, Zamawiający pozwolił wykazywać wymagane doświadczenie na podstawie różnych usług i projektów, a wymagania dotyczące poszczególnych osób koncentrują się obecnie na okresie pełnienia określonych funkcji, rodzaju wykonywanych zadań oraz posiadanych kwalifikacjach i jednocześnie pozostają związane z charakterem pełnionych funkcji. Dodał, że przewidział możliwość potwierdzenia kwalifikacji osoby wskazanej na stanowisko Kierownika Projektu – certyfikatem PRINCE2 Practitioner, PMP lub certyfikatem równoważnym. W ramach Zarzutu nr 3, Zamawiający przekazał wykonawcom dodatkowe informacje dotyczące przedmiotu zamówienia, w tym statystyki zgłoszeń serwisowych, przewidział możliwość udostępnienia szczegółowej dokumentacji technicznej Systemów, a także przeprowadzenia przeglądu kodów źródłowych, po zawarciu porozumienia o zachowaniu poufności. Co do Zarzutu nr 4, zgodnie z dokonaną przez Zamawiającego modyfikacją dokumentów zamówienia z dnia 11 sierpnia 2026 r. Zamawiający przewidział możliwość udostępnienia wykonawcom szczegółowej dokumentacji technicznej oraz przeprowadzenia przeglądu kodów źródłowych Systemów po zawarciu porozumienia o zachowaniu poufności oraz udostępnił statystyki zgłoszeń serwisowych za okres 12 miesięcy wraz z podziałem na kategorie zgłoszeń. Z kolei, w zakresie Zarzutu nr 5, modyfikacją z dnia 11 sierpnia, udostępnił wykonawcom dokumentację techniczną Systemów oraz wgląd do kodów źródłowych na zasadach określonych w SW Z, a także udostępnił statystyki zgłoszeń serwisowych aplikacji BeSTi@ i SJO BeSTi@ za okres od 1 lipca 2025 r. do 30 czerwca 2026 r., z podziałem na poszczególne formy kontaktu i typy incydentów. Ponadto, Zamawiający przewidział miesięczny okres przejęcia utrzymania systemów, zgodnie z dokonaną modyfikacją. Zamawiający wprowadził dnia 11 sierpnia również modyfikacje SW Z w zakresie dot. Zarzutu nr 6, w ramach których udostępni statystki serwisowe, dokumentację techniczną oraz wgląd do kodu źródłowego.

Do postępowania przystąpienie po stronie Odwołującego zgłosił wykonawca Yarrl S.A. w Krakowie. W zgłoszeniu przystąpienia wskazał, że wnosi o uwzględnienie odwołania, a przytoczoną argumentację Odwołującego uznaje za własną.

Krajowa Izba Odwoławcza ustaliła i zważyła, co następuje.

W niniejszej sprawie, odwołanie nie zawiera braków formalnych, zaś wpis od odwołania został uiszczony w terminie i w wymaganej wysokości. Nadto, Izba stwierdziła, że odwołanie nie podlega odrzuceniu na podstawie art. 528 PZP.

Izba uznała, że wykonawca Yarrl S.A. skutecznie przystąpił do postępowania odwoławczego po stronie Odwołującego.

Postępowanie w zakresie dotyczącym Zarzutów nr 4-6 oraz 8 odwołania zostało umorzone. Zarzuty nr 6 i 8 zostały cofnięte przez Odwołującego na rozprawie, toteż postępowanie w tym zakresie podlegało umorzeniu z mocy art. 568 pkt 1 PZP. Stosownie do art. 520 ust. 1 PZP, odwołujący może cofnąć odwołanie do czasu zamknięcia rozprawy. Z kolei, w zakresie dotyczącym Zarzutów nr 4 i 5 odwołania, postępowanie na podstawie art. 568 pkt 2 PZP podlegało umorzeniu, wobec stwierdzenia, że w tej części stało się zbędne, wobec dokonanych przez Zamawiającego, po wniesieniu odwołania modyfikacji dokumentów zamówienia. W obu tych zarzutach Odwołujący podnosił, że Zamawiający nie udostępnił wystarczających danych i informacji niezbędnych do sporządzenia oferty. Dnia 11 sierpnia Zamawiający opublikował zaś wyjaśnienia i zmiany SW Z, które odpowiadały w swym zakresie zarzuconym wcześniej zaniechaniom.

Wobec powyższego, na dzień orzekania przez Izbę nie istniały już naruszenia zarzucane Zamawiającemu w Zarzutach nr 4 i 5, toteż postępowanie w tym zakresie było zbędne.

Izba uznała również, że Odwołujący jest uprawniony do wniesienia odwołania do Prezesa Krajowej Izby Odwoławczej, bowiem posiada interes w uzyskaniu zamówienia i może ponieść szkodę w wyniku naruszenia przez Zamawiającego przepisów PZP. Jak wynika z odwołania, Odwołujący prowadzi działalność na rynku usług informatycznych, posiada kompetencje i zasoby umożliwiające ubieganie się o zamówienie oraz zamierza złożyć ofertę w postępowaniu, zaś kwestionowane postanowienia dokumentów zamówienia wpływają bezpośrednio na możliwość przygotowania oferty, kalkulacji ceny, oceny ryzyk kontraktowych oraz uzyskania punktów w kryteriach jakościowych, co za tym idzie – w ich wyniku Odwołujący może ponieść szkodę polegającą w szczególności na ograniczeniu albo pozbawieniu możliwości złożenia konkurencyjnej oferty, konieczności kalkulowania ceny w warunkach istotnej niepewności co do zakresu i ryzyk realizacji zamówienia, a także utracie szansy na uzyskanie zamówienia wskutek uprzywilejowania wykonawcy dysponującego historyczną wiedzą o utrzymywanych Systemach. W świetle powyższego, Izba uznała, że spełnione są przesłanki z art. 505 ust. 1 PZP, decydujące o legitymacji procesowej Odwołującego do wniesienia odwołania.

W rozdziale III SW Z, Zamawiający opisał przedmiot zamówienia wskazując, że jest nim utrzymanie i rozwój systemu BeSTi@ – zarządzanie budżetami jednostek samorządu terytorialnego wraz z komponentami: BeSTi@ API (frontend, backend oraz portal www.finansejst.mf.gov.pl ) i BeSTi@ Subwencje, a także utrzymanie i rozwój systemu SJO BeSTi@ – zarządzanie budżetami jednostek samorządu terytorialnego – sprawozdawczość jednostek organizacyjnych. W ramach zamówienia podstawowego przewidziano świadczenie przez wykonawcę na rzecz Zamawiającego usług zapewniających utrzymanie dwóch systemów informatycznych w zakresie asysty technicznej, tj. Systemu BeSTi@ zbudowanego w ramach projektu Phare 2002/000.580.01.09 Zarządzanie finansami publicznymi, komponent B „System zarządzania budżetami jednostek samorządu terytorialnego”; oraz Systemu SJO BeSTi@ zbudowanego w ramach projektu Transition Facility 2006/018- 180.01-04 „System zarządzania budżetami jednostek samorządu terytorialnego – sprawozdawczość jednostek organizacyjnych. Z kolei, w ramach prawa opcji, Zamawiający przewidział:

1. świadczenie przez wykonawcę na rzecz Zamawiającego przez okres kolejnych 12 miesięcy Usług zapewniających utrzymanie dwóch systemów informatycznych w zakresie asysty technicznej: a)Systemu BeSTi@ zbudowanego w ramach projektu Phare 2002/000.580.01.09 Zarządzanie finansami publicznymi, komponent B „System zarządzania budżetami jednostek samorządu terytorialnego”, b)Systemu SJO BeSTi@ zbudowanego w ramach projektu Transition Facility 2006/018- 180.01-04 „System zarządzania budżetami jednostek samorządu terytorialnego organizacyjnych”;
2. świadczenie przez wykonawcę na rzecz Zamawiającego Usług Rozwoju dwóch systemów informatycznych przez okres 24 miesięcy w zakresie wprowadzania dostosowań/zmian w Systemach wymieniających między sobą dane: a)Systemu BeSTi@ zbudowanego w ramach projektu Phare 2002/000.580.01.09 Zarządzanie finansami publicznymi, komponent B „System zarządzania budżetami jednostek samorządu terytorialnego”, b)Systemu SJO BeSTi@ zbudowanego w ramach projektu Transition Facility 2006/018- 180.01-04 „System zarządzania budżetami jednostek samorządu terytorialnego organizacyjnych”;
3. przedłużenie świadczenia przez wykonawcę na rzecz Zamawiającego Usług Rozwoju dwóch systemów informatycznych przez okres kolejnych 12 miesięcy w zakresie wprowadzania dostosowań/zmian w Systemach wymieniających między sobą dane: a)Systemu BeSTi@ zbudowanego w ramach projektu Phare 2002/000.580.01.09 Zarządzanie finansami publicznymi, komponent B „System zarządzania budżetami jednostek samorządu terytorialnego”, b)Systemu SJO BeSTi@ zbudowanego w ramach projektu Transition Facility 2006/018- 180.01-04 „System zarządzania budżetami jednostek samorządu terytorialnego – sprawozdawczość jednostek organizacyjnych”;
4. realizacja zadania polegającego na wprowadzeniu mechanizmu umożliwiającego wymuszenie aktualizacji wersji aplikacji SJO BeSTi@ – Zadanie ZAD1;
5. realizacja zadania polegającego na wprowadzeniu mechanizmów zapewniających poprawność oraz weryfikację danych identyfikacyjnych JST/JO w zakresie numeru REGON – Zadanie ZAD2.

Szczegóły dotyczące opisu przedmiotu zamówienia oraz sposób jego realizacji zawarte są w Załączniku nr 1 do SW Z – Opis Przedmiotu zamówienia. Realizacja Przedmiotu Zamówienia, o którym mowa w ust. 1 powyżej, odbywać się będzie na zasadach i warunkach opisanych w Projektowanych Postanowieniach Umowy zwanych dalej PPU stanowiące Załącznik nr 8 do SW Z, w OPZ stanowiącym Załącznik nr 1 do PPU, Ofercie stanowiącej Załącznik nr 2 do PPU, Procedurze świadczenia usług asysty technicznej stanowiącej Załącznik nr 3 do PPU, Procedurze wprowadzania dostosowań/zmian stanowiącej Załącznikiem nr 4 do PPU oraz Zbiorze standardów i wymagań AK stanowiącej Załączniki nr 9 do PPU.

Zgodnie z rozdziałem IV SW Z, w ramach zamówienia podstawowego świadczenie usług zapewniających utrzymanie dwóch systemów informatycznych w zakresie asysty technicznej, będzie realizowana przez okres 24 miesięcy od dnia zawarcia umowy, nie wcześniej jednak niż od dnia 1 stycznia 2027 r. Z kolei, w ramach prawa opcji przedłużenie

świadczenia Usług zapewniających utrzymanie dwóch systemów informatycznych w zakresie asysty technicznej, będzie realizowana przez okres kolejnych 12 miesięcy lub do wyczerpania środków finansowych przeznaczonych na realizację Usługi, w zależności od tego, które ze zdarzeń nastąpi wcześniej, nie wcześniej jednak niż od dnia 1 stycznia 2029 r.

Ponadto, w ramach prawa opcji świadczenie Usług Rozwoju dwóch systemów informatycznych w zakresie wprowadzania dostosowań/zmian w Systemach wymieniających między sobą dane, będzie realizowana przez okres 24 miesięcy lub do wyczerpania środków finansowych przeznaczonych na realizację Usługi, w zależności od tego, które ze zdarzeń nastąpi wcześniej, nie wcześniej jednak niż od dnia 1 stycznia 2027 r. W ramach prawa opcji przedłużenie świadczenia przez wykonawcę na rzecz Zamawiającego Usług Rozwoju dwóch systemów informatycznych w zakresie wprowadzania dostosowań/zmian w Systemach wymieniających między sobą dane, przez okres kolejnych 12 miesięcy lub do wyczerpania środków finansowych przeznaczonych na realizację Usługi, w zależności od tego, które ze zdarzeń nastąpi wcześniej, nie wcześniej jednak niż od dnia 1 stycznia 2029 r. Zadanie ZAD1 będzie realizowane przez okres 36 miesięcy od dnia zawarcia umowy, nie wcześniej jednak niż od dnia 1 stycznia 2027 r., w terminie wskazanym w Formularzu Oferty stanowiącym Załącznik nr 2 do SW Z, nie później jednak niż w terminie 60 dni roboczych od podpisania zamówienia na realizację zadania (termin realizacji zadania ZAD1 stanowi pozacenowe kryterium oceny ofert). Zadanie ZAD2będzie realizowane przez okres 36 miesięcy od dnia zawarcia umowy, nie wcześniej jednak niż od dnia 1 stycznia 2027 r., w terminie wskazanym w Formularzu Oferty stanowiącym załącznik nr 2 do SW Z, nie później jednak niż w terminie 60 dni roboczych od podpisania zamówienia na realizację zadania (termin realizacji zadania ZAD2 stanowi pozacenowe kryterium oceny ofert). W przypadku chęci skorzystania z prawa opcji Zamawiający skieruje do wykonawcy zawiadomienie, na podstawie uzgodnionego z wykonawcą i zaakceptowanego przez Zamawiającego zlecenia dostosowań/zmian. Szczegółowy opis zlecenia dostosowań/zmian znajduje się w Procedurze wprowadzania dostosowań/zmian stanowiącej Załącznikiem nr 4 do PPU. Zamawiający może skorzystać z całości lub części świadczeń składających się na prawo opcji. Zamawiający zastrzega sobie prawo wielokrotnego uruchomienia prawa opcji (tj. co do poszczególnych dostosowań/zmian).

Warunki udziału w postępowaniu zostały określone w rozdziale VI SW Z. W szczególności, o zawarcie umowy mogą ubiegać się wykonawcy, którzy spełniają warunki dotyczące zdolności technicznej lub zawodowej:

1. (pkt 2.4 lit. A SW Z) Zamawiający uzna warunek za spełniony, jeżeli wykonawca wykaże, że w okresie ostatnich trzech lat, liczonych wstecz od dnia, w którym upływa termin składania ofert, a jeżeli okres prowadzenia działalności jest krótszy - w tym okresie, wykonał (lub wykonuje w przypadku usług okresowych lub ciągłych) wykonał (lub wykonuje w przypadku usług okresowych lub ciągłych) co najmniej 2 (słownie: dwie) usługi polegające na utrzymaniu systemu informatycznego/systemów informatycznych. Przez utrzymanie systemu informatycznego/systemów informatycznych Zamawiający rozumie świadczenie usługi polegającej na zapewnieniu ciągłości działania, w tym: naprawie błędów i wad, konfigurowaniu, aktualizowaniu, dostosowywaniu do zmian prawnych, poprawie funkcjonalności systemu informatycznego/systemów informatycznych, każda usługa realizowana przez okres co najmniej 12 miesięcy, przy czym: -co najmniej jedną z tych usług objęty był system obsługujący procesy biznesowe obejmujące: proces sprawozdawania z realizacji budżetu, obsługę dystrybucji (alokacji) środków finansowych; -co najmniej jedną z tych usług objęty był system obsługujący analizy finansowe oraz modele symulacyjne w oparciu o dane co najmniej 1500 instytucji lub podmiotów gospodarczych (np. jednostki samorządu terytorialnego, jednostki budżetowe); -co najmniej jedną z tych usług objęty był system, który został zbudowany i uruchomiony w architekturze rozproszonej obejmującej, co najmniej 1500 różnych lokalizacji (różne adresy pocztowe) posiadających odrębne instancje baz danych i wymieniających dane między sobą -co najmniej jedna usługa świadczona była dla systemu, z którego korzysta co najmniej 3000 instytucji lub podmiotów gospodarczych (np. jednostki samorządu terytorialnego, jednostki budżetowe); -co najmniej jedną z tych usług objęty był system, który posiada funkcjonalności zapewniające przesyłanie danych pomiędzy dwoma grupami użytkowników, niepołączonymi siecią lokalną, z których jedna grupa weryfikuje dane drugiej grupy; -co najmniej jedna z tych usług obejmowała poprawę wydajności systemu; -co najmniej jedną z tych usług objęty był system wykorzystujący łącznie następujące technologie, z których korzysta Zamawiający: • Microsoft.NET Framework (Windows forms); • ASP.NET • XadES • PAdES • MS SQL Server; • Web Services (SOAP); • React.js; -co najmniej jedną z tych usług objęty był system posiadający funkcjonalność podpisu elektronicznego w zakresie podpisywania i weryfikacji podpisów dokumentów .xml kwalifikowanym podpisem elektronicznym, w tym zapewniającego dołączanie wielu podpisów/kontrasygnat; a wartość każdej z dwóch usług, o których mowa w zdaniu pierwszym ust. 2 pkt 4 lit a) wynosiła co najmniej
2. 500.000,00 (słownie: cztery miliony pięćset tysięcy złotych) zł netto. Zamawiający wyjaśnia, że w przypadku usług, które są nadal wykonywane, wykonawca zobowiązany jest wykazać, iż do upływu terminu składania ofert wykonał usługi o wartości co najmniej 4.500.000,00 (słownie: cztery miliony pięćset tysięcy złotych) netto.

Zamawiający nie dopuszcza sumowania wartości usług (np. poprzez wskazanie kilku usług na kwotę niższą niż wskazana przez Zamawiającego) dla potwierdzenia spełniania w/w warunku udziału w postępowaniu. W przypadku, gdy w ramach realizacji wskazanej przez wykonawcę usługi, poza zakresem wymaganym przez Zamawiającego celem wykazania spełnienia warunku, były wykonywane również inne świadczenia, wykazana musi zostać wartość dotycząca tej części umowy, która obejmowała usługi z zakresu wsparcia technicznego i merytorycznego użytkowników systemów informatycznych.

1. (pkt 2.4 lit. B SW Z) Zamawiający uzna ww. warunek za spełniony, jeżeli wykonawca wykaże, że dysponuje lub będzie dysponował osobami skierowanymi do realizacji zamówienia, w tym: a)Kierownikiem Projektu posiadającym łącznie: -wykształcenie wyższe o profilu ekonomicznym lub informatycznym, -doświadczenie w pełnieniu funkcji kierownika projektu spełniające wymagania: • w okresie ostatnich trzech lat liczonych wstecz od dnia, w którym upływa termin składania ofert pełnił funkcję kierownika projektu informatycznego przez okres co najmniej 24 miesięcy, przy czym jeżeli funkcja kierownika projektu była pełniona równolegle w więcej niż jednym projekcie to okresy jednoczesnego pełnienia funkcji kierownika projektu nie sumują się, • w okresie ostatnich trzech lat liczonych wstecz od dnia, w którym upływa termin składania ofert przez co najmniej 12 miesięcy kierował projektem zgodnie z metodyką PRINCE 2, • w okresie ostatnich trzech lat liczonych wstecz od dnia, w którym upływa termin składania ofert pełnił funkcję kierownika projektu w projekcie o wartości co najmniej 1 500 000,00 zł (słownie: jeden milion pięćset tysięcy złotych), przy czym funkcja ta była pełniona przez co najmniej 6 miesięcy, • przedmiotem projektu był serwis systemu z którego korzysta co najmniej 3000 instytucji lub podmiotów gospodarczych (np. jednostki samorządu terytorialnego, jednostki budżetowe); -kwalifikacje obejmujące co najmniej: • wiedzę z zakresu metodyki PRINCE 2 zapewniającą pełnienie funkcji kierownika projektu, • wiedzę z zakresu korzystania z biblioteki dobrych praktyk ITIL; b)co najmniej jednym specjalistą ds. Obsługi Zgłoszeń (Service Desk) posiadającym łącznie: -wykształcenie co najmniej średnie, -kwalifikacje obejmujące co najmniej znajomość ogólnych zagadnień z zakresu informatyki (zagadnienia sprzętowe, systemy operacyjne, zagadnienia sieciowe, bazy danych, itd.); c)co najmniej jednym Ekspertem ds. Jakości posiadającym łącznie: -wykształcenie wyższe o profilu technicznym lub matematycznym, -doświadczenie z okresu ostatnich trzech lat liczonych wstecz od dnia, w którym upływa termin składania ofert polegające na pełnieniu funkcji osoby odpowiedzialnej za kontrolę jakości, w co najmniej trzech usługach dotyczących utrzymania systemów informatycznych, w tym: • udziału w realizacji co najmniej jednej usługi o wartości co najmniej 1.500.000,00 zł (słownie: jeden milion pięćset tysięcy złotych), przy czym funkcję tę pełnił przez co najmniej 6 miesięcy, • udziału w realizacji co najmniej jednej usługi dotyczącej systemu o wartości co najmniej 1.500.000,00 zł (słownie: jeden milion pięćset tysięcy złotych), polegającej na utrzymaniu systemu informatycznego/systemów informatycznych tj. świadczeniu usługi polegającej na zapewnieniu ciągłości działania, w tym: naprawie błędów i wad, konfigurowaniu, aktualizowaniu, dostosowywaniu do zmian prawnych, poprawie funkcjonalności systemu informatycznego/systemów informatycznych, przy czym funkcję tę pełnił przez co najmniej pół roku, • udziału w realizacji co najmniej jednej usługi, której przedmiotem była budowa lub utrzymanie systemu, o architekturze rozproszonej obejmującej, co najmniej 1.500 różnych lokalizacji (różne adresy pocztowe) posiadających odrębne instancje baz danych i wymieniających dane między sobą, • udziału w realizacji co najmniej jednej usługi, w której stosował biblioteki dobrych praktyk ITIL, -kwalifikacje obejmujące co najmniej: • posiadanie wiedzy z zakresu stosowania biblioteki dobrych praktyk ITIL, • posiadanie znajomości metodyk testowania oprogramowania; d)co najmniej jednym Ekspertem ds. Finansów Samorządu Terytorialnego posiadającym łącznie: -wykształcenie wyższe, -doświadczenie w pełnieniu w okresie ostatnich trzech lat liczonych wstecz od dnia, w którym upływa termin składania ofert funkcji analityka lub projektanta, w realizacji co najmniej jednej usługi informatycznej, w której wykorzystywał swoją znajomość zasad planowania, naliczania środków dla JST w tym

subwencjonowania, alokacji środków dla JST, przekazywania, zgodnie z ustawą o dochodach JST oraz sprawozdawczości budżetowej; e)co najmniej jednym Ekspertem ds. Wieloletniej Prognozy Finansowej posiadającym łącznie: -wykształcenie wyższe; -doświadczenie w pełnieniu w okresie ostatnich trzech lat liczonych wstecz od dnia, w którym upływa termin składania ofert, przez okres minimum 1 roku, funkcji analityka lub projektanta, w co najmniej jednej usłudze informatycznej, w której wykorzystywał swoją: • znajomość zasad opracowywania Wieloletniej Prognozy Finansowej (W PF) dla Jednostek Samorządu Terytorialnego (JST) (zgodnie z Ustawą z dnia 27 sierpnia 2009 r. o finansach publicznych (Dz. U. z 2023 r. poz. 1270 z późn. zm.) oraz rozporządzeniem Ministra Finansów z dnia 10 stycznia 2013 r. w sprawie wieloletniej prognozy finansowej jednostki samorządu terytorialnego (Dz. U. z 2021 r. poz. 83), • umiejętność stosowania technik prognozowania tj., modelowanie deterministyczne i ekonometryczne, ekspercka opinia i analiza; f)co najmniej jednym Analitykiem Systemowym posiadającym łącznie: -wykształcenie wyższe o profilu ekonomicznym lub informatycznym, -doświadczenie w pełnieniu w okresie ostatnich trzech lat liczonych wstecz od dnia, w którym upływa termin składania ofert funkcji konsultanta lub analityka systemowego w co najmniej trzech usługach informatycznych, z których każda trwała co najmniej 12 miesięcy i: • co najmniej jedna z nich dotyczyła finansów publicznych, • co najmniej jedna z nich obejmowała system, który został zbudowany i uruchomiony w architekturze rozproszonej obejmującej, co najmniej 1500 różnych lokalizacji (różne adresy pocztowe) posiadających odrębne instancje baz danych i wymieniających dane między sobą, • co najmniej jedna z nich obejmowała system wykorzystujący łącznie następujące technologie, z których korzysta Zamawiający: • Microsoft.NET Framework (Windows forms); • ASP.NET; • XadES; • PAdES; • MS SQL Server; • Web Services (SOAP); • React.js; • PKI, XML Signature (w wersji zgodnej z Ustawą z dnia 5 września 2016 r. o usługach zaufania oraz identyfikacji elektronicznej (UOUZ), w tym spełniającej art. 137 tj. zgodnej z notacją i strukturą atrybutów certyfikatu kwalifikowanego wynikającą ze standardu ETSI EN 319 412 oraz stosującej zaawansowane podpisy elektroniczne i zaawansowane pieczęci elektroniczne z funkcją skrótu SHA-2); g)co najmniej jednym Projektantem/Wdrożeniowcem posiadającym łącznie: -wykształcenie wyższe o profilu informatycznym, -doświadczenie w pełnieniu przez okres co najmniej 6 miesięcy w okresie ostatnich trzech lat liczonych wstecz od dnia, w którym upływa termin składania ofert funkcji projektanta lub wdrożeniowca lub architekta, w co najmniej trzech usługach informatycznych, z których: • każda usługa trwała co najmniej 12 miesięcy, • co najmniej jedna z usług dotyczyła finansów publicznych, • co najmniej jedna z nich obejmowała system, który został zbudowany i uruchomiony w architekturze rozproszonej obejmującej, co najmniej 1500 różnych lokalizacji (różne adresy pocztowe) posiadających odrębne instancje baz danych i wymieniających dane między sobą, -który projektował systemy, w których zostały zastosowane łącznie następujące technologie, z których korzysta Zamawiający: ▪ Microsoft.NET Framework (Windows forms); ▪ ASP.NET; ▪ XadES; ▪ PAdES; ▪ MS SQL Server; ▪ Web Services (SOAP); ▪ React.js; ▪ PKI, XML Signature (w wersji zgodnej z Ustawą z dnia 5 września 2016 r. o usługach zaufania oraz identyfikacji elektronicznej (UOUZ), w tym spełniającej art. 137 tj. zgodnej z notacją i strukturą atrybutów certyfikatu kwalifikowanego wynikającą ze standardu ETSI EN 319 412 oraz stosującej zaawansowane podpisy elektroniczne i zaawansowane pieczęci elektroniczne z funkcją skrótu SHA-2).

W przypadku wykonawców wspólnie ubiegających się o udzielenie zamówienia, spełnianie ww. warunków, wykonawcy wykazują łącznie.

Zgodnie z rozdziałem XIV pkt 2.7 SWZ, do oferty wykonawca zobowiązany jest dołączyć, w szczególności:

1. Opis koncepcji realizacji Zadania ZAD1 zgodny z opisem Zadania zawartym w ust. 1 pkt B ppkt 4) OPZ stanowiącego Załącznik nr 1 do SW Z zawierający: a) harmonogram realizacji zadania potwierdzający realizację zadania zgodnie z Umową oraz czasem realizacji zadania nie dłuższym niż 60 dni roboczych od przesłania Zlecenia Wykonania Prac, b) Szczegółowy opis sposobu realizacji zadania ZAD1, potwierdzający zgodność oferowanego rozwiązania z zapisami Opisu Przedmiotu Zamówienia, uwzględniający co najmniej następujące zagadnienia: • opis zrozumienia problemu oraz jego kontekstu funkcjonalnego i biznesowego; • opis proponowanego rozwiązania, w tym jego założeń, logiki działania oraz kluczowych elementów; • uzasadnienie przyjętego zidentyfikowanego problemu • opis wpływu proponowanego rozwiązania na użytkowników końcowych oraz istniejące procesy; • opis wpływu rozwiązania na system, w tym jego architekturę, utrzymanie oraz dalszy

rozwój; • identyfikację potencjalnych ryzyk oraz ograniczeń związanych z realizacją rozwiązania; • opis podejścia do realizacji zadania (w tym ogólne założenia dotyczące wdrożenia rozwiązania); • harmonogram realizacji zadania; • deklarowaną pracochłonność / wycenę realizacji zadania wraz z uzasadnieniem przyjętych założeń; • opracowanie w formie czytelnego i uporządkowanego dokumentu umożliwiającego jednoznaczną ocenę przedstawionej koncepcji. W przypadku braku załączenia ww. koncepcji w zakresie realizacji zadania ZAD1 wykonawca otrzyma 0 pkt w kryterium oceny ofert opisanym w Rozdziale XIX ust. 2 pkt 3) SWZ;

1. Opis koncepcji realizacji Zadania ZAD2 zgodny z opisem Zadania zawartym w ust. 1 pkt B ppkt 5) OPZ stanowiącego Załącznik nr 1 do SW Z zawierający: a) harmonogram realizacji zadania potwierdzający realizację zadania zgodnie z Umową oraz czasem realizacji zadania nie dłuższym niż 60 dni roboczych od przesłania Zlecenia Wykonania Prac, b) Szczegółowy opis sposobu realizacji zadania ZAD2, potwierdzający zgodność oferowanego rozwiązania z zapisami Opisu Przedmiotu Zamówienia, uwzględniający co najmniej następujące zagadnienia: • opis zrozumienia problemu oraz jego kontekstu funkcjonalnego i biznesowego; • opis proponowanego rozwiązania, w tym jego założeń, logiki działania oraz kluczowych elementów; • uzasadnienie przyjętego zidentyfikowanego problemu; • opis wpływu proponowanego rozwiązania na użytkowników końcowych oraz istniejące procesy; • opis wpływu rozwiązania na system, w tym jego architekturę, utrzymanie oraz dalszy rozwój; • identyfikację potencjalnych ryzyk oraz ograniczeń związanych z realizacją rozwiązania; • opis podejścia do realizacji zadania (w tym ogólne założenia dotyczące wdrożenia rozwiązania); • harmonogram realizacji zadania; • deklarowaną pracochłonność / wycenę realizacji zadania wraz z uzasadnieniem przyjętych założeń; • opracowanie w formie czytelnego i uporządkowanego dokumentu umożliwiającego jednoznaczną ocenę przedstawionej koncepcji. W przypadku braku załączenia ww. koncepcji w zakresie realizacji zadania ZAD2, wykonawca otrzyma 0 pkt w kryterium oceny ofert opisanym w Rozdziale XIX ust. 2 pkt 4) SWZ.

W rozdziale XIX SW Z Zamawiający opisał kryteria, którymi będzie kierował się przy wyborze oferty, wraz z podaniem wag tych kryteriów i sposobu oceny ofert. Wskazał na następujące kryteria: Cena brutto oferty (C) – 60%, Koncepcja realizacji zadania ZAD1 (K1) – 10%, Koncepcja realizacji zadania ZAD2 – 10%, Termin realizacji zadania ZAD1 – 10% oraz Termin realizacji zadania ZAD2 – 10%. Zakres Koncepcji został wskazany w OPZ – pkt I.1.B. Szczegółowy opis sposobu realizacji zadań ZAD1 oraz ZAD2 (koncepcja), potwierdzający zgodność oferowanego rozwiązania z OPZ, powinien uwzględniać co najmniej następujące zagadnienia: a) opis zrozumienia problemu oraz jego kontekstu funkcjonalnego i biznesowego; b) opis proponowanego rozwiązania, w tym jego założeń, logiki działania oraz kluczowych elementów; c) uzasadnienie przyjętego podejścia w odniesieniu do zidentyfikowanego problemu; d) opis wpływu proponowanego rozwiązania na użytkowników końcowych oraz istniejące procesy; e) opis wpływu rozwiązania na system, w tym jego architekturę, utrzymanie oraz dalszy rozwój; f) identyfikację potencjalnych ryzyk oraz ograniczeń związanych z realizacją rozwiązania; g) opis podejścia do realizacji zadania (w tym ogólne założenia dotyczące wdrożenia rozwiązania); h) harmonogram realizacji zadania; i) deklarowaną pracochłonność / wycenę realizacji zadania wraz z uzasadnieniem przyjętych założeń; j) opracowanie w formie czytelnego i uporządkowanego dokumentu umożliwiającego jednoznaczną ocenę przedstawionej koncepcji. W rozdziale XIX SW Z, Zamawiający wskazał, że ocena koncepcji (kryterium K1 i K2) będzie polegać na osobnej ocenie każdego z elementów wymaganych w Koncepcji, a następnie punkty przyznane za poszczególne elementy Koncepcji będą sumowane. W tabeli podane są maksymalne liczby punktów, jakie wykonawca może uzyskać za przygotowanie poszczególnych elementów Koncepcji i wyjaśniona jest zasada przyznawania ocen pośrednich. Ocena koncepcji zostanie dokonana osobno przez poszczególnych Członków Komisji Przetargowej. Członkowie Komisji przyznają każdej ze złożonych ofert, w ramach niniejszego kryterium liczbę punktów. Następnie dla każdej oferty, w ramach niniejszego kryterium, zostanie obliczona średnia arytmetyczna (suma punktów przyznana przez poszczególnych członków komisji / liczba członków komisji dokonujących oceny). Wynik ten pomnożony przez 10% (wagę niniejszego kryterium oceny ofert) stanowił będzie ostateczną liczbę punktów jaką dana oferta uzyska w ramach niniejszego kryterium oceny ofert. Poniższa tabela dot. punktacji kryterium K1.

Poniższa tabela dot. punktacji kryterium K2.

Izba zaliczyła w poczet akt postępowania, w tym jako dowód w sprawie dokumentację przekazaną w postaci elektronicznej przez Zamawiającego w dniu 7 sierpnia 2026 r., w szczególności ogłoszenie o zamówieniu, SW Z wraz z załącznikami.

Biorąc pod uwagę zgromadzony w sprawie materiał dowodowy, poczynione ustalenia faktyczne oraz orzekając w granicach zarzutów zawartych w odwołaniu, Krajowa Izba Odwoławcza stwierdziła, co następuje.

Odwołanie podlegało oddaleniu w części, w której odwołanie nie zostało cofnięte i co do zarzutów, których rozpoznanie,

pomimo dokonanych przez Zamawiającego zmian dokumentów zamówienia, nie okazało się zbędne.

W odniesieniu do Zarzutów nr 1 i nr 2, co do których argumentacja Odwołującego była zbieżna, bowiem dotyczyła zbyt surowo, tj. kazuistycznie i nieproporcjonalnie określonych wymogów odnoszących się do warunków udziału w postepowaniu, w zakresie doświadczenia wykonawcy oraz personelu, Izba stwierdziła, że zarzuty te nie potwierdziły się.

Odwołujący podnosił, że tak określone wymagania odnoszące się do skali, złożoności i rozwiązań technologicznych systemów, w zakresie utrzymania których wykonawca lub jego personel posiada doświadczenie odpowiadają doświadczeniu, jakie ma podmiot, który realizował już zadania identyczne jak obecny System BeSTi@. Zarzucił Zamawiającemu, że nie wykazał, że tylko tak określone doświadczenie jest odpowiednie i proporcjonalne, lecz sam pominął, że zgodnie z art. 534 ust. 1 PZP, strony i uczestnicy postępowania odwoławczego są obowiązani wskazywać dowody dla stwierdzenia faktów, z których wywodzą skutki prawne. Rację ma zatem Zamawiający, że uzasadnienie odwołania jest ogólne, a oba zarzuty nieudowodnione. Po pierwsze, Odwołujący nie wykazał, że Zamawiający wymaga doświadczenia odpowiadającego szczegółowym cechom funkcjonalnym, organizacyjnym i technologicznym obecnych Systemów Zamawiającego. W szczególności, jak wykazał Zamawiający, wymóg odnoszący się do 1.500 lokalizacji nie jest zbieżny z parametrem obecnego Systemu, który obejmuje ok. 35.000 lokalizacji. Odwołujący nie wskazał na inne rozwiązania technologiczne, ani nie dowiódł, że pozwalałyby one wykazać doświadczenie, na jakim zależy Zamawiającemu i jednocześnie odpowiadające wymaganiom art. 112 ust. 1 i ust. 2. Należy pamiętać, że art. 112 ust. 1 PZP wskazuje, że warunek udziału w postępowaniu ma być proporcjonalny do przedmiotu zamówienia, a nie do uwarunkowań rynkowych. Owszem, nie może blokować uczciwej konkurencji (art. 16 pkt 1 PZP), ale jednocześnie nie oznacza to, że może dopuszczać do zamówienia wszystkich zainteresowanych wykonawców, skoro PZP wymaga, by był określony na takim poziomie, aby umożliwiał ocenę zdolności wykonawcy do należytego wykonania danego, konkretnego zamówienia. Tym samym, jak słusznie wskazał Zamawiający, warunków udziału w postępowaniu, nie można oceniać w oderwaniu od konkretnych warunków zamówienia. Warunki udziału mogą i powinny odnosić się do specyficznych cech danego zamówienia, a nie jedynie uwzględniać branżę i wynikające stąd kwalifikacje podmiotowe wykonawców. W szczególności, Odwołujący podnosił, że wartości mniejsze dziesięciokrotnie, tj. wymóg np. 150 lokalizacji również odpowiadałby potrzebom zapewnienia stosownego doświadczenia wykonawcy, gdyż zwiększanie tej liczby powoduje już tylko multiplikację elementów infrastruktury, a nie różni się wiedzą i zdobytym doświadczeniem wykonawcy – lecz w żaden sposób tego nie wykazał. Nie wykazał również zupełnie, że sposób, w jaki Zamawiający określił zakwestionowane warunki udziału w postępowaniu ograniczają konkurencję, w tym nie przedstawił dowodów np. na fakt, że na rynku istnieje tylko jeden podmiot spełniający ww. wymagania lub, że brak jest systemów, których parametry odpowiadają wymaganym w niniejszym postępowaniu, a co za tym idzie, których utrzymanie pozwoliłoby zdobyć wykonawcom lub ich personelowi stosowne doświadczenie. Nie wykazał również, że doświadczenie osoby na Kierownika Projektu, zdobyte przy projektach prowadzonych zgodnie z innymi uznanymi metodykami (PMI/PMBOK, IPMA, AgilePM) zapewnia należyte wykonanie zamówienia w stopniu porównywalnym, w szczególności nie wskazał na różnice lub podobieństwa tych metodyk. Pominął również, że wprowadzone przez Zamawiającego zmiany SW Z z 11 sierpnia podążały w kierunku uwzględnienia części żądań Odwołującego, tzn. by możliwie najszerzej otworzyć warunki dotyczące kwalifikacji podmiotowej wykonawców na konkurencję, a co za tym idzie wychodziły naprzeciw oczekiwaniom wykonawcy, w zakresie, w jakim dopuszczają to przepisy PZP.

Izba oddaliła również Zarzut nr 3 dotyczący ustanowienia, niewystarczająco zobiektywizowanych, kryteriów jakościowych „Koncepcja realizacji zadania ZAD1” i „Koncepcja realizacji zadania ZAD2”. W tym zakresie, Izba podzieliła stanowisko Zamawiającego, iż sposób przeprowadzenia oceny kryteriów jakościowych nie nadaje się do opisania w dokumentach zamówienia za pomocą matematycznych wzorów, lecz w pewnym zakresie musi opierać się na subiektywnych wrażeniach oceniającego. Zgodnie z art. 240 ust. 1 PZP, zamawiający opisuje kryteria oceny ofert w sposób jednoznaczny i zrozumiały. Odwołujący wskazał, że kryteria oceny koncepcji odnoszą się do niedookreślonych pojęć takich jak: „kompletność”, „poprawność merytoryczna”, lecz nie wskazano jednocześnie, jakie minimalne wymagania należy spełnić, aby opis został uznany za „kompletny”, ani jakie braki powodują zakwalifikowanie go jako jedynie „niepełnego” itp. Z powyższym nie sposób się zgodzić, Izba oceniła opis jakościowych kryteriów oceny ofert K1 i K2 jako zrozumiały i jednoznaczny, w możliwie najwyższym stopniu, jaki może odnosić do kryteriów jakościowych, w szczególności polegających na ocenie wymyślonej przez wykonawcę koncepcji, w ramach której Zamawiający oczekuje przedstawienia rozwiązania danego problemu. Rację ma Zamawiający, że każde wprowadzenie parametrów oceny prowadziłoby do zniweczenia celów ustanowienia takiego kryteriów, ponieważ ograniczałoby kreatywność wykonawcy, a co za tym idzie możliwość rzetelnego zweryfikowania jego podejścia do realizacji zadania i jakości tego podejścia.

Podkreślenia wymagają wymagania art. 240 ust. 2 PZP, by kryteria oceny ofert i ich opis nie pozostawiały zamawiającemu nieograniczonej swobody wyboru najkorzystniejszej oferty oraz umożliwiały weryfikację i porównanie poziomu oferowanego wykonania przedmiotu zamówienia na podstawie informacji przedstawianych w ofertach. W ocenie Izby, dowolność oceny została zniwelowana poprzez opis zasady przyznawania punktacji danego elementu

Koncepcji – na podstawie tego opisu możliwe jest ustalenie, czym jest opis „kompletny” (obejmuje wszystkie elementy wskazane przez Zamawiającego) i „niepełny” (nie obejmuje wszystkich elementów wskazanych przez Zamawiającego), opis wskazuje też jasno, że brak opisu danego elementu jest równoznaczny z przyznaniem 0 pkt. Z kolei, jak wskazał Zamawiający w odpowiedzi na odwołanie, poprawność merytoryczna będzie weryfikowana poprzez zestawienie z parametrami funkcjonującego Systemu i ocenę możliwości wdrożenia takiego rozwiązania w funkcjonującym środowisku. Oceny będą zaś dokonywać eksperci w ramach udokumentowanego procesu. Zatem, w ocenie Izby, brak jest w zaskarżonym zakresie dotyczącym obu kryteriów oceny ofert – przyznania nieograniczonej swobody w zakresie wyboru najkorzystniejszej oferty. Zamawiający precyzyjnie opisał oceniane elementy oraz kryteria tej oceny w ramach maksymalne liczby punktów. Tym samym, swoboda oceny została ograniczona jasnymi zasadami punktacji. Każda oferta będzie podlegać jednolicie opisanym zasadom punktacji, co pozwoli na porównanie poziomu oferowanego wykonania przedmiotu zamówienia, wskutek ustalenia ostatecznej liczby pkt, jaką dana oferta uzyska w ramach każdego z obu kryteriów. Ocena nie będzie następowała bezpośrednio poprzez porównanie ofert, tj. jak wskazał Odwołujący, stwierdzenie, że analiza wpływu proponowanego rozwiązania, dokonana przez danego wykonawcę jest trafniejsza od analizy innego wykonawcy, lecz każda z tych analiz będzie oceniana odrębnie pod kątem poprawności merytorycznej oraz szczegółowości opisu, tj. tego czy jest poprawny merytorycznie i pełny, a nie tego, czy jest trafny, tj. ocenie nie będzie podlegać wartość, czy też przydatność danej koncepcji, w których to przypadkach rzeczywiście moglibyśmy mieć do czynienia z niemal nieograniczoną i niejednoznaczną oceną. Podkreślić również należy, że 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 (art. 554 ust.

1 pkt 1 PZP). Odwołujący zarzucił niezgodność ww. Koncepcji (kryteria K1 i K2) z art. 16 pkt 1–3, art. 240 ust. 1 i 2 i art.

242 ust. 1 PZP, lecz w żaden sposób nie wykazał naruszenia tych przepisów, ani realnego wpływu zakwestionowanych postanowień SWZ na wynik postępowania o udzielenie zamówienia.

Zarzut 7 pn. „łączny efekt postanowień dokumentacji jako konsekwencja”, stanowił jak stwierdził sam Odwołujący konsekwencję wszystkich wskazanych w odwołaniu naruszeń łącznie. Izba stwierdziła, że zarzut ten nie został wykazany, w szczególności Izba nie stwierdziła naruszenia zasady uczciwej konkurencji oraz równego traktowania wykonawców poprzez ukształtowanie dokumentacji postępowania w sposób, który w efekcie prowadzi do uprzywilejowania wykonawcy posiadającego wiedzę wynikającą z wcześniejszego uczestnictwa w utrzymaniu lub rozwoju systemu BeSTi@. Odwołujący nie przedstawił ku temu żadnych dowodów. Poza tym zarzut jest blankietowy, odnosi się do całokształtu postanowień SW Z, bez wskazania na konkretne postanowienia – do tych odnoszą się z kolei szczegółowe zarzuty zawarte w innych punktach petitum odwołania. Tym samym, w zakresie, w jakim zarzut ten odnosi się do kwestii opisanych już w ramach innych zarzutów, stanowi on zbędne powielenie, skoro naruszenie art. 16 pkt 1-3 PZP zostało zarzucone w ramach wszystkich pozostałych zarzutów. Co prawda, w uzasadnieniu tego zarzutu Odwołujący wskazał, że chodzi o kumulację ograniczeń wywołanych jednoczesnym zastosowaniem różnych postanowień SW Z, które mogłyby samodzielnie zostać uznane za dopuszczalne i sprecyzował, że chodzi o wszystkie zakwestionowane postanowienia SW Z razem, pominął jednak, że połowa zarzutów nie podlegała merytorycznemu rozpoznaniu przez Izbę. Pozostała zaś ich część, tj. zbyt szczegółowo zdaniem Odwołującego określone warunki udziału odnoszące się do doświadczenia wykonawcy, łącznie z obowiązkiem przygotowania szczegółowych koncepcji realizacji zadań ZAD1 i ZAD2 wraz ze sposobem ich oceny – rozpatrywane łącznie nie świadczą, zdaniem Izby, o takim nagromadzeniu wymagań i ograniczeń, które wskazują na faworyzowanie wykonawców, którzy już wcześniej świadczyli podobne usługi na rzecz Zamawiającego. Izba uznała bowiem dwa pierwsze zarzuty za niewykazane co do zasady, z kolei w odniesieniu do Zarzutu nr 3 Izba również nie stwierdziła, by zakwestionowane postanowienia rozdziału XIV ust. 78 SW Z wprowadzały jakiekolwiek ograniczenia dla wykonawców, utrudniające im złożenie oferty, w tym z korzyścią dla innego wykonawcy. Odwołujący pominął w tym zakresie, że ciążył na nim obowiązek dowodowy w zakresie podnoszonych twierdzeń.

Biorąc powyższe pod uwagę, na podstawie art. 552 ust. 1, art. 553 zd. 1, art. 554 ust. 1 pkt 1 PZP, orzeczono jak w sentencji.

O kosztach postępowania orzeczono stosownie do wyniku postępowania – na podstawie 557 PZP oraz w oparciu o przepisy 1 i pkt 2 lit. a) i b) w zw. z 8 ust. 2 pkt 1 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 pobieraniu wpisu od odwołania (Dz. U. poz. 2437 ze zm.).

Biorąc powyższe pod uwagę, Izba orzekła jak w sentencji.

Przewodnicząca

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