Wyrok KIO KIO 1069/26

Sygn. akt: KIO 1069/26

WYROK

Warszawa, 21 kwietnia 2026 r.

Krajowa Izba Odwoławcza – w składzie:

Przewodnicząca: Katarzyna Poprawa

Protokolantka:Sylwia Podniesińska

po rozpoznaniu na rozprawie w dniu 17 kwietnia 2026 roku odwołania wniesionego do Prezesa Krajowej Izby Odwoławczej w dniu 9 marca 2026 roku przez wykonawcęSages Spółka
‎z ograniczoną odpowiedzialnością z siedzibą w Warszawie w postępowaniu prowadzonym przez zamawiającego Uniwersytet w Białymstoku

orzeka:

1.umarza postępowanie odwoławcze w zakresie zarzutów podniesionych w petitum odwołania w punktach: 1 i 2 w całości oraz w punkcie 3 w części odnoszącej się do określenia jako wymogu równoważności względem systemu DSpace dodatkowych kryteriów dotyczących skali wdrożeń lub zasięgu geograficznego,

2.oddala odwołanie

3.kosztami postępowania obciąża odwołującego Sages Spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawiei:

3.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 Sages Spółka
‎z ograniczoną odpowiedzialnością z siedzibą w Warszawie tytułem wpisu od odwołania oraz kwotę 4 077 zł 00 zł 00 gr (słownie: cztery tysiące siedemdziesiąt siedem złotych zero groszy) poniesioną przez zamawiającego Uniwersytet
‎w Białymstoku tytułem wynagrodzenia pełnomocnika, kosztów dojazdu na posiedzenie i rozprawę oraz opłaty skarbowej od pełnomocnictwa,

3.2.zasądza od odwołującego Sages Spółka z ograniczoną odpowiedzialnością
‎z siedzibą w Warszawiena rzecz zamawiającego Uniwersytetu w Białymstoku kwotę 4 077 zł 00 zł 00 gr (słownie: cztery tysiące siedemdziesiąt siedem złotych zero groszy) stanowiącą koszty poniesione przez zamawiającegotytułem wynagrodzenia pełnomocnika, kosztów dojazdu na posiedzenie i rozprawę oraz opłaty skarbowej od pełnomocnictwa.

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 1069/26

Uzasadnienie

Zamawiający – Uniwersytet w Białymstoku prowadzi postępowanie o udzielenie zamówienia publicznego na zadanie pn.: „Wdrożenie platformy informacji naukowo badawczej Uniwersytetu w Białymstoku”, numer postępowania: Dzp.2510.39.2025: dalej jako „Postępowanie”.

Postępowanie prowadzone jest w trybie przetargu nieograniczonego na podstawie ustawy
‎z dnia 11 września 2019 roku Prawo zamówień publicznych (t.j. Dz. U. 2024 poz. 1320 ze zm.) zwanej dalej ustawa „Pzp”. Ogłoszenie o zamówieniu zostało zamieszczone w Suplemencie do Dziennika Urzędowego Unii Europejskiej w dniu 25 lutego 2025 roku pod numerem 131315-2026.

W dniu 9 marca 2026 roku do Prezesa Krajowej Izby Odwoławczej zostało wniesione odwołanie przez wykonawcę Sages Sp. z o.o. z siedzibą w Warszawie (zwanego dalej „Odwołującym”) wobec postanowień Specyfikacji Warunków Zamówienia (dalej „SWZ”)

Odwołujący postawił Zamawiającemu następujące zarzuty:

Zarzut nr 1 – naruszenia art. 112 ust. 1 Pzp w zw. z art. 16 pkt 1 i 3 Pzp w zw. z rozdziałem VIII ust. 2 pkt 4 lit. b) SWZ o treści:

Zamawiający uzna warunek za spełniony jeżeli Wykonawca wykaże, że dysponuje lub będzie dysponował osobami niezbędnymi do prawidłowej realizacji przedmiotu zamówienia, którzy zostaną skierowani do realizacji zamówienia, tj.:

- Kierownik/koordynator Projektu, który:

• w okresie ostatnich 3 lat przed upływem terminu składania ofert pełnił rolę kierownika/koordynatora/konsultanta głównego projektu w co najmniej 2 projektach informatycznych polegających na dostarczeniu, wdrożeniu, instalacji i konfiguracji oprogramowania informatycznego, o wartości projektu co najmniej 400 000,00 zł brutto (czterysta tysięcy złotych brutto) każdy. Na potrzeby oceny spełnienia niniejszego warunku udziału w postępowaniu przez wartość projektu rozumie się wyłącznie wartość oprogramowania informatycznego wraz z usługami wdrożenia, instalacji, konfiguracji, integracji, szkolenia pracowników oraz uruchomienia produkcyjnego, tj. w szczególności bez kosztów dostaw sprzętu.

• Posiada biegłą znajomość języka polskiego lub angielskiego

• Posiada wykształcenie wyższe • Uczestniczył jako Kierownik / koordynator / konsultant główny w całym procesie dostawy wdrożenia oprogramowania, țj. od momentu rozpoczęcia realizacji zamówienia (umowy) do dnia podpisania protokołu odbioru końcowego przez Zamawiającego

• posiada aktualny certyfikat Project Management Professional lub równoważny (za równoważne Zamawiający uzna w szczególności następujące certyfikaty: Prince 2 Practitioner, IPMA Level C) oraz aktualny certyfikat w zakresie zwinnego zarządzania projektami PMI Agile CertifiedPractitioner lub równoważny;

- minimum 2 (dwóch) Specjalistów wdrożeniowych, z których każdy:

• w okresie ostatnich 3 lat przed upływem terminu składania ofert pełnił funkcję specjalisty wdrożeniowego w co najmniej 2 projektach informatycznych polegających na dostarczeniu, wdrożeniu, instalacji i konfiguracji oprogramowania informatycznego o wartości projektu co najmniej 400.000,00 zł brutto (czterysta tysięcy złotych brutto) każdy. Na potrzeby oceny spełnienia niniejszego warunku udziału w postępowaniu przez wartość projektu rozumie się wyłącznie wartość oprogramowania informatycznego stanowiącego jego element wraz z usługami wdrożenia, instalacji, konfiguracji, integracji, szkolenia pracowników oraz uruchomienia produkcyjnego, tj. w szczególności bez kosztów dostaw sprzętu.

• Posiada biegłą znajomość języka polskiego lub angielskiego

• Posiada wykształcenie wyższe

• Uczestniczył jako specjalista wdrożeniowy w całym procesie dostawy i wdrożenia oprogramowania, țj. od momentu rozpoczęcia realizacji zamówienia (umowy) do dnia podpisania protokołu odbioru końcowego przez Zamawiającego

• posiada aktualny certyfikat Certified SCRUM Master lub Certified SCRUM Product Owner lub równoważne; Jedna osoba nie może pełnić kilku funkcji”,

poprzez określenie warunków udziału w postępowaniu, dotyczących zdolności technicznej
‎lub zawodowej, w sposób nieproporcjonalny do przedmiotu zamówienia, tj. poprzez obowiązek wykazania, że (i) kierownik/koordynator Projektu dysponuje aktualnym certyfikatem
‎w zakresie zwinnego zarządzania projektami PMI Agile CertifiedPractitioner lub równoważnym, (ii) specjaliści wdrożeniowi dysponują aktualnym certyfikatem Certified SCRUM Master lub Certified SCRUM Product Owner lub równoważnymi, co jest wymogiem nieuzasadnionym i nadmiarowy, a przede wszystkim zbędnym w postępowaniu ze względu na jego przedmiot, który nie będzie realizowany w metodyce zwinnej (Agile) co w konsekwencji doprowadziło do naruszenia zasady zachowania uczciwej konkurencji oraz równego traktowania wykonawców oraz zasady proporcjonalności.

Zarzut nr 2 – naruszenia art. 112 ust. 1 Pzp w zw. z art. 16 pkt 1 i 3 Pzp w zw. z rozdziałem VIII ust. 2 pkt 4 lit. a) SWZ o treści:

Zamawiający uzna warunek za spełniony jeżeli Wykonawca wykaże, że w okresie ostatnich trzech lat przed upływem terminu składania ofert, a jeżeli okres prowadzenia działalności jest krótszy – w tym okresie wykonał należycie i zakończył co najmniej dwa odrębne zamówienia (odrębne umowy)o wartości minimum 400 000 zł brutto każde, które obejmowały dostawę oraz modernizację istniejącego systemu informatycznego opartego
‎o silnik DSpace lub równoważny wraz z dostosowaniem tego systemu do wytycznych WCAG oraz integracją z systemami POL-on i PBN Ministerstwa Nauki i Szkolnictwa Wyższego, a także w co najmniej jednym z tych zamówień wykonana została zgodność wymiany danych z OpenAire na poziomie 3.0 lub 4.0 (OpenAire 3.0 funding
‎lub OpenAIREPubRepos v4.0) zgodnie z oficjalnym wykazem

poprzez określenie warunków udziału w postępowaniu dotyczących zdolności technicznej lub zawodowej, w sposób nieproporcjonalny do przedmiotu zamówienia, tj. poprzez obowiązek wykazania, że wykonawca zrealizował co najmniej dwa odrębne zamówienia (odrębne umowy), które obejmowały dostawę lub modernizację istniejącego systemu informatycznego opartego o silnik DSpace lub równoważnym, co jest wymogiem nieuzasadnionym
‎i nadmiarowym a w konsekwencji doprowadziło do naruszenia zasady zachowania uczciwej konkurencji oraz równego traktowania wykonawców raz zasady proporcjonalności.

Zarzut nr 3 - naruszenie art. 99 ust. 4 Pzp w zw. z art. 16 pkt 1 i 3 Pzp w zw. z pkt 1 Załącznika nr 1 do SWZ – Opis przedmiotu zamówienia (OPZ) o treści:

Przedmiotem zamówienia jest:

1.Wdrożenie (instalacja, konfiguracja, przygotowanie dokumentacji, opieka serwisowa systemu) platformy informacji naukowo-badawczej Uniwersytetu w Białymstoku (zwanej dalej Platformą) na podstawie otwartoźródłowego (open source) oprogramowania DSpace lub równoważnego, wraz z jej pełnym dostosowaniem do potrzeb Zamawiającego w celu umożliwienia długoterminowego i bezpiecznego przechowywania, archiwizowania, deponowania, analizowania i udostępniania danych społeczeństwu. Platforma składać się będzie z trzech powiązanych ze sobą modułów:

a.repozytoryjnego – umożliwiającego deponowanie, przechowywanie i udostępnianie w otwartym dostępie pełnych tekstów publikacji pracowników naukowych, doktorantów i studentów Uniwersytetu w Białymstoku wraz z ich indeksowaniem
‎w najważniejszych agregatorach naukowych na świecie. Ze względu na istniejącą funkcjonujące od 12 lat Repozytorium niezbędne jest zachowanie dotychczasowej nazwy i adresacji rekordów,

b.bibliograficznego – umożliwiającego gromadzenie informacji bibliograficznych na temat publikacji pracowników naukowych, doktorantów i studentów Uniwersytetu
‎w Białymstoku wraz z jego integracją z systemami sprawozdawczymi Ministerstwa Nauki i Szkolnictwa Wyższego,

c.portalu pracowników naukowych – umożliwiającego tworzenie indywidualnych profili pracowników naukowych Uniwersytetu w Białymstoku i wprowadzanie informacji na temat ich działalności naukowej, badawczej i dydaktycznej,

oraz komponentów w zakresie funkcjonalności związanych z ewaluacją oraz integracją z MNiSW to jest funkcjonalności określonych w pkt. 7.4 niniejszego dokumentu.

2.Migracja danych do Platformy z systemów Uniwersytetu w Białymstoku:
‎z funkcjonującej platformy Repozytorium Uniwersytetu w Białymstoku, systemu bibliotecznego ALEPH oraz systemu EXPERTUS.

3.Integracja Platformy z systemem USOS Uniwersytetu w Białymstoku.

4.Integracja Platformy z systemami sprawozdawczymi Ministerstwa Nauki i Szkolnictwa Wyższego POL-on i PBN, wraz z zapewnieniem interoperacyjności między tymi systemami a Platformą (import danych i pobieranie danych przy użyciu modułu integracyjnego) oraz przeprowadzenie migracji danych z systemów ministerialnych do Platformy.

5.Integracja Platformy z serwisami zewnętrznymi: OpenAire, CrossRef, Kronik@, EPO, Arxiv, PubMed, SherpaRomeo, Altmetrics.

6.Przeprowadzenie instruktażu stanowiskowego dla pracowników obsługujących Platformę (…)

poprzez opisanie przedmiotu zamówienia w sposób, który jedynie pozornie dopuszcza konkurencję poprzez dopuszczenie rozwiązań równoważnych do oprogramowania DSpace,
‎a w rzeczywistości prowadzi do uprzywilejowania konkretnego rozwiązania informatycznego – oprogramowania otwartoźródłowego (open source) funkcjonującego na rynku (oprogramowanie DSpace) i oprogramowania udostępnionego w formule SaaS (Science Cloud) oraz wykonawcę oferującego to rozwiązanie (PCG Akademia Sp. z o.o.), co
‎w konsekwencji stanowi naruszenie zasad zachowania uczciwej konkurencji oraz równego traktowania wykonawców oraz proporcjonalności.

Zarzut nr 4 – naruszenia art. 99 ust. 4 Pzp w zw. z art. 16 pkt 1 i 3 Pzp w zw. z ppkt F.17
‎i F.20 pkt 7.1. załącznika nr 1 do SWZ – Opis przedmiotu zamówienia o treści:

F.17 Wyświetlanie pól na podstawie typu

System musi umożliwiać obsługę wyświetlania różnych pól w formularzu
‎w zależności od wybranego typu osiągnięcia. System powinien wyświetlać pola dynamicznie jedynie na podstawie zmiany typu w formularzu bez konieczności przeładowania strony lub przełączania się do innego formularza lub kolekcji

F.20 Możliwość konfiguracji pól formularzy zgodnie ze standardem XML i Dublin Core.

System powinien umożliwiać konfigurację pól formularzy zgodnie ze standardem XML i Dublin Core. W ramach konfiguracji określane powinny być szczegółowe informacje dla każdego z pól formularza: wymagalność, widoczność na różnych etapach workflow, widoczność w zależności od wybranego typu, podpowiedzi. Ponadto system powinien pozwalać na konfigurację struktury całego formularza, na którą składają się: kolejność pól, ich ułożenie na stronie, ich typ oraz podział na sekcje

poprzez opisanie przedmiotu zamówienia w sposób, który jedynie pozornie dopuszcza konkurencję poprzez dopuszczenie rozwiązań równoważnych do oprogramowania DSpace,

a w rzeczywistości prowadzi do uprzywilejowania konkretnego rozwiązania informatycznego – oprogramowania otwartoźródłowego (open source) funkcjonującego na rynku (oprogramowanie DSpace), co w konsekwencji stanowi naruszenie zasad zachowania uczciwej konkurencji oraz równego traktowania wykonawców oraz proporcjonalności.

Zarzut nr 5 - naruszenia art. 99 ust. 4 Pzp w zw. z art. 16 pkt 1 i 3 Pzp w zw. z rozdziałem
‎V Specyfikacji Warunków Zamówienia, termin wykonania zamówienia o treści:

Etap 1 - w terminie do 2 tygodni od dnia zawarcia Umowy:

a. uruchomienie Systemu w środowisku testowym,

b. uruchomienie integratora danych do systemów Ministerstwa Nauki i Szkolnictwa Wyższego POL-on i PBN, wraz z zasileniem bazy danymi pochodzącymi z tych systemów w zakresie osiągnięć naukowych i danych o pracownikach i doktorantach.

Etap 2 - w terminie do 4 tygodni od dnia zawarcia Umowy:

c. przedstawienie projektu technicznego obejmującego szczegółowy proces wdrożenia i konfiguracji funkcjonalności Platformy,

d. wykonanie Analizy Przedwdrożeniowej i Koncepcji Wdrożenia wraz
‎z Harmonogramem Wdrożenia, jego przedstawienie Zamawiającemu w formie pisemnej lub elektronicznej i jego akceptację przez Zamawiającego;

Etap 3 - w terminie do 4 miesięcy od dnia zawarcia Umowy:

e. wykonanie projektów graficznych, w interfejsu zatwierdzonego przez Zamawiającego i implementacja projektów graficznych interfejsu Platformy,

f. migracja danych z systemów wewnętrznych Zamawiającego do Platformy.

Etap 4 - w terminie 6 miesięcy od dnia zawarcia Umowy:

g. uruchomienie wersji produkcyjnej Platformy,

h. szkolenia, w tym instruktaż stanowiskowy dotyczący korzystania z Platformy.

Etap 5 - w terminie do 8 miesięcy od dnia zawarcia Umowy:

i.Uruchomienie e-usług portalu pracowniczego w środowisku produkcyjnym

poprzez określenie realizacji zamówienia w sposób nieracjonalny, niezgodny z zasadami realizacji projektów informatycznych oraz prowadzący do nieuzasadnionego ograniczenia konkurencji, w tym w szczególności poprzez wymagania prezentacji gotowego już rozwiązania informatycznego niezwłocznie po złożeniu ofert w postępowaniu, co w konsekwencji stanowi naruszenie zasad zachowania uczciwej konkurencji oraz równego traktowania wykonawców oraz proporcjonalności.

Zarzut nr 6 - naruszenie art. 239 ust. 1 Pzp w zw. z art. 16 pkt 1 i 3 Pzp w zw. z pkt 3 załącznika nr 1B do Specyfikacji Warunków Zamówienia – Oferowane funkcjonalności Platformy, poprzez ustanowienie kryteriów oceny ofert w zakresie funkcjonalności opcjonalnych podlegających punktacji w ramach kryteriów oceny ofert w sposób nieproporcjonalny oraz prowadzący
‎do uprzywilejowania określonego rozwiązania informatycznego funkcjonującego na rynku oraz wykonawców oferujących to rozwiązanie, a także ustanowienie kryteriów, które sa pozbawione merytorycznego znaczenia i uzasadnienia, co doprowadziło do uprzywilejowania
‎lub wyeliminowania niektórych wykonawców lub produktów, a w konsekwencji stanowi naruszenie zasad zachowania uczciwej konkurencji oraz równego traktowania wykonawców.

W związku z powyższymi zarzutami Odwołujący wniósł o:

1. uwzględnienie niniejszego odwołania w całości,

2. nakazanie Zamawiającemu dokonania zmiany SWZ w następujący sposób:

(a) dokonanie zmiany treści rozdziału VIII ust. 2 pkt 4 lit. b) SWZ, poprzez usunięcie wymogu posiadania przez Kierownika/koordynatora Projektu aktualnego certyfikatu Project Management Professional lub równoważnego (za równoważne Zamawiający uzna w szczególności następujące certyfikaty: Prince 2 Practitioner, IPMA Level C) oraz aktualny certyfikat w zakresie zwinnego zarządzania projektami PMI Agile Certified Practitioner lub równoważnego,

(b) dokonanie zmiany treści rozdziału VIII ust. 2 pkt 4 lit. b) SWZ, poprzez usunięcie wymogu posiadania przez 2 (dwóch) Specjalistów wdrożeniowych aktualnego certyfikatu Certified SCRUM Master lub Certified SCRUM Product Owner lub równoważnego,

(c) dokonanie zmiany treści rozdziału VIII ust. 2 pkt 4 lit. a) SWZ, poprzez dopuszczenie

możliwości wykazania doświadczenia w realizacji wdrożeń systemów repozytoryjnych bez wskazywania szczegółowych wymagań dotyczących architektury technicznej lub konkretnych rozwiązań technologicznych,
‎w szczególności poprzez usunięcie z opisu tego warunku szczegółowej listy wymagań technicznych i nietechnicznych dotyczących systemu równoważnego
‎do DSpace,

(d) dokonanie zmiany treści rozdziału VIII ust. 2 pkt 4 lit. a) SWZ, poprzez dopuszczenie

możliwości wykazania doświadczenia w realizacji zamówień obejmujących dostarczenie lub wdrożenie systemu zgodnego z wymaganiami WCAG, niezależnie od tego, czy dostosowanie do tych wymagań zostało wykonane w ramach danego projektu, czy też nastąpiło wcześniej w toku rozwoju produktu,

(e) dokonanie zmiany treści rozdziału VIII ust. 2 pkt 4 lit. a) SWZ, poprzez dopuszczenie

możliwości wykazania doświadczenia w zakresie integracji z platformą OpenAIRE

również w ramach innych projektów lub etapów współpracy niż projekty referencyjne

wskazane do spełnienia warunku udziału w Postępowaniu oraz poprzez rezygnację z wymogu dotyczącego konkretnego zakresu danych przekazywanych do OpenAIRE, przyjmując jako wystarczające wykazanie doświadczenia w realizacji integracji systemu repozytoryjnego z platformą OpenAIRE,

(f) dokonanie zmiany treści punktu 1 podpunkt 1 OPZ, poprzez usunięcie wymogu oparcia rozwiązania o oprogramowanie open source oraz usunięcie wymogu równoważności względem systemu DSpace zdefiniowanej poprzez dodatkowe kryteria dotyczące skali wdrożeń lub zasięgu geograficznego, tak aby dopuszczalne było dostarczenie systemu repozytoryjnego lub systemu informacji naukowej spełniającego wymagania funkcjonalne określone w OPZ, niezależnie od modelu licencjonowania oraz historii wdrożeń danego oprogramowania, albo alternatywnie,

(g) dokonanie zmiany treści punktu 1 podpunkt 1 OPZ, poprzez nakazanie Zamawiającemu podziału zamówienia na części, obejmujące co najmniej:

i. wdrożenie systemu repozytoryjnego spełniającego wymagania określone
‎w OPZ,

ii. dostarczenie systemu analitycznego i sprawozdawczego wraz z integracją
‎z systemami POL-on i PBN, oraz odpowiednią zmianę dokumentacji postępowania w tym zakresie,

(h) dokonanie zmiany treści rozdziału V SWZ - Termin wykonania zamówienia, poprzez

przeniesienie czasu realizacji funkcjonalności polegających na integracji
‎z systemami POL-on i PBN do późniejszego etapu realizacji projektu, tj. po wykonaniu analizy przedwdrożeniowej oraz opracowaniu projektu technicznego systemu, w szczególności do końcowego etapu realizacji zamówienia,

(i)dokonanie zmiany SWZ poprzez zmianę wskazanych poniżej podpunktów zamieszczonych w punkcie 7.1 załącznika nr 1 do SWZ - OPZ i nadanie
‎im następującego brzmienia:

F.17 Wyświetlanie pól na podstawie typu.

System musi umożliwiać obsługę wyświetlania różnych pól w formularzu
‎w zależności od wybranego typu osiągnięcia.

F.20 Możliwość konfiguracji pól formularzy zgodnie ze standardem XML i Dublin Core.

System powinien umożliwiać konfigurację pól formularzy. W ramach konfiguracji określane powinny być szczegółowe informacje dla każdego z pól formularza: wymagalność, widoczność na różnych etapach workflow, widoczność w zależności od wybranego typu, podpowiedzi. Ponadto system powinien pozwalać
‎na konfigurację struktury całego formularza, na którą składają się: kolejność pól,
‎ich ułożenie na stronie, ich typ oraz podział na sekcje.

(j) dokonanie zmiany SWZ poprzez usunięcie w całości załącznika nr 1A do SWZ, przewidującego wymaganie przeprowadzenia prezentacji gotowego już rozwiązania

informatycznego niezwłocznie po złożeniu ofert w Postępowaniu,

(k)  dokonanie zmiany SWZ poprzez usunięcie w całości punktu 3 (Funkcjonalności systemu związane z ewaluacją oraz integracją z MNiSW (E)) załącznika nr 1B do SWZ -Oferowane funkcjonalności Platformy,

3. przeprowadzenie dowodu z dokumentacji Postępowania,

4.zasądzenie od Zamawiającego na rzecz Odwołującego kosztów postępowania odwoławczego, w tym kosztów zastępstwa procesowego.

Odwołujący wskazał, że posiada interes we wniesieniu odwołania myśl art. 505 ust. 1 Pzp, jest bowiem podmiotem w pełni zdolnym i realnie zainteresowanym wykonaniem przedmiotu zamówienia w Postępowaniu. Na skutek wspomnianych powyżej naruszeń przepisów Pzp dokonanych przez Zamawiającego, Postępowanie zostało przeprowadzone wadliwie od strony formalnej. Obecnie obowiązująca treść SWZ może uniemożliwić Odwołującemu złożenie oferty w Postępowaniu, co naraża Odwołującego na poniesienie szkody majątkowej wynikającej z braku możliwości uzyskania zamówienia oraz braku możliwości wykonania przedmiotu potencjalnie zawartej z Zamawiającym Umowy, z czym z kolei wiązałaby się utrata potencjalnego zysku.

Izba ustaliła następujący stan faktyczny

Zamawiający prowadzi postępowanie o udzielenie zamówienia publicznego w trybie przetargu nieograniczonego o wartości zamówienia przekraczającej progi unijne na dostawę pn. „Wdrożenie platformy informacji naukowo-badawczej Uniwersytetu w Białymstoku", numer

postępowania: Dzp.2510.39.2025.W treści Specyfikacji Warunków Zamówienia (dalej: „SWZ”) znalazły się postanowienia, które w ocenie Odwołującego naruszają obowiązujące przepisy Pzp, w tym w szczególności poprzez utrudnienie uczciwej konkurencji.

Zarzut dotyczący wymaganego wykazu osób – Zarzut nr 1.

W rozdz. VIII ust. 2 pkt 4 lit. b) SWZ Zamawiający postawił wymagania dotyczące posiadania

określonych certyfikatów przez osoby skierowane do realizacji zamówienia. W szczególności:

a) dla specjalistów wdrożeniowych wymagany jest „certyfikat Certified Serum Master lub

Certified Serum Product Owner lub równoważny",

b) dla kierownika projektu wymagany jest certyfikat „PMI Agile Certified Practitioner".

Tymczasem charakter przedmiotowego zamówienia oraz sposób jego realizacji nie uzasadniają wymagania posiadania certyfikatów związanych z metodykami zwinnymi. Opis przedmiotu zamówienia nie przewiduje bowiem realizacji projektu w metodyce zwinnej, ani nie nakłada obowiązku stosowania takich metod zarządzania projektem.W konsekwencji wymaganie w Postępowaniu, personelu posiadającego certyfikaty związane z metodykami zwinnymi pozostaje bez związku z przedmiotem zamówienia oraz sposobem jego realizacji przewidzianym przez Zamawiającego. Wymóg ten nie znajduje także uzasadnienia
‎w potrzebach Zamawiającego wynikających z OPZ, gdyż celem zamówienia jest uzyskanie

określonego efektu w postaci wdrożenia informatycznego, a nie doprowadzenie do tego wdrożenia konkretna metodą (wdrożenie zwinne).

Zarzut dotyczący wymaganego wykazu usług – Zarzut nr 2.

Odwołujący nie zgadza się z postawionym przez Zamawiającego warunkiem dotyczącym

doświadczenia wykonawcy w zakresie realizacji zamówień opartych wyłącznie o system DSpace lub inne oprogramowanie otwartoźródłowe o równoważnych funkcjonalnościach, określonym w rozdz. VIII ust. 2 pkt 4 lit. a) SWZ.

W ocenie Odwołującego warunek ten jest nieuzasadniony oraz nieproporcjonalny
‎do przedmiotu zamówienia, gdyż w sposób nieuprawniony ogranicza możliwość wykazania doświadczenia wyłącznie do projektów realizowanych w oparciu o oprogramowanie open source.Tymczasem fakt, czy dany system repozytoryjny jest rozwijany i licencjonowany jako

oprogramowanie otwartoźródłowe, czy też jako rozwiązanie własne (proprietary), pozostaje bez wpływu na zakres kompetencji wykonawcy w zakresie projektowania, wdrażania oraz integracji systemów repozytoryjnych.W szczególności doświadczenie zdobyte przy realizacji wdrożeń systemów repozytoryjnych opartych na oprogramowaniu własnym może obejmować identyczny zakres prac technicznych jak w przypadku wdrożeń systemów open source, w tym w szczególności: projektowanie architektury systemu, implementację mechanizmów przechowywania i opisu danych, integrację z systemami zewnętrznymi, zapewnienie interoperacyjności z wykorzystaniem standardowych protokołów wymiany danych,

czy dostosowanie systemu do wymagań dostępności cyfrowej.

W konsekwencji Odwołujący wnosi o uchylenie wskazanego ograniczenia oraz dopuszczenie możliwości wykazania doświadczenia polegającego również na realizacji wdrożeń systemów

repozytoryjnych opartych na oprogramowaniu własnym, o ile systemy te zapewniały funkcjonalności odpowiadające funkcjonalnościom wymaganym przez Zamawiającego.

Zarzut naruszenia zasad uczciwej konkurencji poprzez pozorne dopuszczenie rozwiązań równoważnych – zarzut nr 3.

Odwołujący zarzuca Zamawiającemu naruszenie art. 16 pkt 1 i 3 oraz art. 99 ust. 4 Pzp
‎w zw. z pkt 1 OPZ poprzez opisanie przedmiotu zamówienia w sposób, który jedynie pozornie dopuszcza konkurencję, a w rzeczywistości prowadzi do uprzywilejowania konkretnego modelu rozwiązania funkcjonującego na rynku.

Zgodnie z SWZ przedmiotem zamówienia jest wdrożenie platformy informacji naukowo-badawczej opartej o otwartoźródłowe oprogramowanie DSpace lub równoważne. Jednocześnie Zamawiający przewiduje integrację z systemami ministerialnymi POL-on i PBN.

Zamawiający określa tę funkcjonalność jako „integrację" z systemami ministerialnymi,
‎co sugeruje jedynie techniczne połączenie systemów. Tymczasem analiza OPZ wskazuje,
‎że zakres wymaganych funkcjonalności wykracza daleko poza prostą integrację i w istocie obejmuje udostępnienie dedykowanego systemu analityczno-sprawozdawczego w modelu SaaS na okres 60 miesięcy, który gromadzi, przetwarza oraz analizuje dane naukowe oraz realizuje integrację z systemami POL-on i PBN.

Taki sposób opisania przedmiotu zamówienia prowadzi w praktyce do zastosowania modelu

wdrożeniowego polegającego na wykorzystaniu bezpłatnego systemu repozytoryjnego DSpace jako warstwy bazowej, przy jednoczesnym dostarczeniu zamkniętego oprogramowania realizującego funkcje analityczne i integracyjne.

W praktyce rynkowej oznacza to, że zasadnicza wartość ekonomiczna zamówienia nie dotyczy

samego systemu DSpace - który jest oprogramowaniem open source i nie posiada kosztu licencyjnego - lecz zamkniętego oprogramowania ewaluacyjnego i analitycznego, dostarczanego przez wykonawcę.

Na rynku polskim funkcjonuje obecnie jeden dostawca, który oferuje gotowy model takiego

rozwiązania - polegający na wdrożeniu repozytorium DSpace wraz z własnym, zamkniętym

systemem obsługującym procesy ewaluacyjne oraz integrację z systemami POL-on i PBN. Podmiot ten dysponuje również gotowym integratorem tych systemów.

W konsekwencji opis przedmiotu zamówienia powoduje, że choć formalnie postępowanie dotyczy wdrożenia systemu open source, natomiast faktycznie obejmuje dostarczenie zamkniętego oprogramowania o znacznej wartości, którego zakres odpowiada rozwiązaniu oferowanemu przez jednego wykonawcę funkcjonującego na rynku. Tak skonstruowany opis przedmiotu zamówienia prowadzi do sytuacji, w której rzeczywisty przedmiot zamówienia - obejmujący system analityczny i sprawozdawczy - zostaje ukryty pod pozorem wdrożenia oprogramowania open source. W praktyce oznacza to, że bezpłatne oprogramowanie repozytoryjne stanowi jedynie niewielką część wartości projektu, podczas gdy zasadnicza część zamówienia dotyczy zamkniętego oprogramowania dostarczanego przez wykonawcę. Taki sposób konstruowania zamówienia narusza zasady przejrzystości i uczciwej konkurencji, gdyż rzeczywisty zakres i wartość ekonomiczna zamówienia nie są wprost ujawnione w opisie

przedmiotu zamówienia. Dodatkowo Zamawiający wskazał, że nie dopuszcza składania ofert

częściowych, co uniemożliwia wykonawcom ubieganie się o realizację poszczególnych elementów systemu i dodatkowo ogranicza konkurencję.

W konsekwencji wykonawcy oferujący własne systemy repozytoryjne lub systemy informacji

naukowej - które nie są dystrybuowane w modelu open source - zostają z góry wykluczeni
‎z możliwości ubiegania się o zamówienie, mimo że mogliby dostarczyć rozwiązanie funkcjonalnie odpowiadające potrzebom Zamawiającego.

Na marginesie należy również wskazać, że dokumentacja postępowania zawiera celowo wprowadzone przez Zamawiającego, ograniczające konkurencję, postanowienia dotyczące określonego modelu dostarczania systemu. Z jednej strony przedmiot zamówienia został opisany jako klasyczne wdrożenie systemu informatycznego u Zamawiającego, natomiast jednocześnie przewidziano 60-miesięczny okres utrzymania oraz aktualizacji systemu, przy czym dokumentacja dopuszcza również świadczenie części funkcjonalności w modelu usługowym. W praktyce oznacza to, że zamówienie w znacznej części może przyjąć charakter usługi systemowej świadczonej w sposób ciągły przez okres pięciu lat, typowy dla modeli subskrypcyjnych (SaaS), a nie jednorazowego wdrożenia systemu informatycznego. Okoliczność ta dodatkowo potwierdza, że rzeczywisty charakter zamówienia wykracza poza deklarowane wdrożenie repozytorium open source i obejmuje długoterminowe korzystanie
‎z rozbudowanego systemu analitycznego rozwijanego przez wykonawcę.

Dodatkowo należy wskazać, że Zamawiający wprowadził bardzo szczegółowe kryteria uznania oprogramowania za równoważne wobec DSpace, obejmujące m.in. wymóg funkcjonowania rozwiązania w wielu krajach oraz posiadania znacznej liczby wdrożeń.
‎W praktyce prowadzi to do sytuacji, w której formalne dopuszczenie rozwiązań równoważnych ma charakter jedynie pozorny, gdyż kryteria te zostały sformułowane w sposób odpowiadający najbardziej rozpowszechnionemu na świecie systemowi repozytoryjnemu. Co więcej, wymagania dotyczące globalnej skali wdrożeń pozostają w oczywistej sprzeczności
‎z pozostałymi elementami OPZ, które w dużej mierze odnoszą się do specyficznych regulacji krajowych związanych z polskim systemem ewaluacji działalności naukowej.

W związku z powyższym Odwołujący wnosi o:

1. nakazanie Zamawiającemu zmiany opisu przedmiotu zamówienia poprzez usunięcie wymogu oparcia rozwiązania o oprogramowanie open source oraz usunięcie wymogu równoważności względem systemu DSpace zdefiniowanej poprzez dodatkowe kryteria dotyczące skali wdrożeń lub zasięgu geograficznego, tak aby dopuszczalne było dostarczenie systemu repozytoryjnego lub systemu informacji naukowej spełniającego wymagania funkcjonalne określone w OPZ, niezależnie od modelu licencjonowania oraz

historii wdrożeń danego oprogramowania, albo alternatywnie

2. nakazanie Zamawiającemu podziału zamówienia na części, obejmujące co najmniej:

a)  wdrożenie systemu repozytoryjnego spełniającego wymagania określone w OPZ,

b) dostarczenie systemu analitycznego i sprawozdawczego wraz z integracją
‎z systemami POL-on i PBN, oraz odpowiednią zmianę dokumentacji Postępowania
‎w tym zakresie.

Zarzut naruszenia zasad uczciwej konkurencji poprzez nieracjonalne określenie

harmonogramu realizacji zamówienia – Zarzut nr 5.

Odwołujący zarzuca Zamawiającemu naruszenie art. 16 pkt 1 i 3 oraz art. 99 ust. 4 Pzp
‎w zw. z rozdz. V SWZ poprzez określenie harmonogramu realizacji zamówienia w sposób nieracjonalny oraz prowadzący do nieuzasadnionego ograniczenia konkurencji.

Zgodnie z harmonogramem realizacji zamówienia Zamawiający wymaga, aby w Etapie 1,
‎w terminie do 2 tygodni od dnia zawarcia umowy, wykonawca uruchomił integrator danych do

systemów Ministerstwa Nauki i Szkolnictwa Wyższego POL-on i PBN wraz z zasileniem bazy

danymi z tych systemów. Jednocześnie dopiero w Etapie 2, przewidzianym do 4 tygodni
‎od dnia zawarcia umowy, Zamawiający przewiduje wykonanie analizy przedwdrożeniowej, opracowanie koncepcji wdrożenia oraz przygotowanie projektu technicznego systemu.
‎Taki sposób ukształtowania harmonogramu pozostaje w oczywistej sprzeczności
‎z podstawowymi zasadami realizacji projektów informatycznych. W praktyce wdrożeniowej integracje systemowe oraz implementacja funkcjonalności systemu poprzedzone są analizą przedwdrożeniową oraz przygotowaniem projektu technicznego określającego architekturę rozwiązania i sposób realizacji integracji.

W Postępowaniu Zamawiający wymaga natomiast wykonania jednej z najbardziej złożonych

funkcjonalności systemu - integracji z systemami POL-on i PBN - jeszcze przed wykonaniem

analizy przedwdrożeniowej oraz przed opracowaniem projektu technicznego systemu.

W praktyce oznacza to, że wykonawca musi dysponować gotowym, wcześniej przygotowanym

rozwiązaniem integracyjnym, możliwym do uruchomienia w bardzo krótkim czasie
‎od podpisania umowy. Taki wymóg w sposób oczywisty ogranicza konkurencję
‎w Postępowaniu do podmiotów, które już wcześniej opracowały dedykowany integrator współpracujący z systemem repozytoryjnym DSpace oraz systemami ministerialnymi.

Na rynku polskim funkcjonuje obecnie jeden dostawca oferujący gotowy integrator tego typu, co dodatkowo potwierdza, że sposób ukształtowania harmonogramu realizacji zamówienia prowadzi do uprzywilejowania konkretnego modelu rozwiązania dostępnego na rynku.

Jednocześnie Zamawiający nie przedstawił żadnego racjonalnego uzasadnienia
‎dla konieczności uruchomienia integracji z systemami ministerialnymi już w pierwszych dwóch tygodniach realizacji projektu. Co więcej, proces ewaluacji działalności naukowej jednostek akademickich w Polsce został niedawno zakończony, a zasady kolejnej ewaluacji nie zostały jeszcze określone. Należy przy tym podkreślić, że kolejna ewaluacja odbędzie się dopiero
‎w 2030 roku. W tej sytuacji brak jest jakichkolwiek przesłanek funkcjonalnych uzasadniających konieczność natychmiastowego uruchomienia systemu integrującego dane ewaluacyjne, zwłaszcza przed wykonaniem analizy przedwdrożeniowej systemu. W konsekwencji harmonogram realizacji zamówienia został ukształtowany w sposób, który nie wynika
‎z rzeczywistych potrzeb Zamawiającego, lecz prowadzi do ograniczenia kręgu wykonawców zdolnych do realizacji zamówienia wyłącznie do podmiotów dysponujących gotowym rozwiązaniem integracyjnym.

W związku z powyższym Odwołujący wnosi o nakazanie Zamawiającemu zmiany harmonogramu realizacji zamówienia poprzez przeniesienie funkcjonalności polegających na integracji z systemami POL-on i PBN do późniejszego etapu realizacji projektu, po wykonaniu analizy przedwdrożeniowej oraz opracowaniu projektu technicznego systemu,
‎w szczególności do końcowego etapu realizacji zamówienia.

Zarzut naruszenia zasad uczciwej konkurencji poprzez ustanowienie nieproporcjonalnych kryteriów oceny ofert – Zarzut nr 6.

Odwołujący zarzuca Zamawiającemu naruszenie art. 16 pkt 1 i 3 oraz art. 239 ust. 1 Pzp
‎w zw. z pkt 3 załącznika nr 1B do SWZ poprzez ustanowienie kryteriów oceny ofert w zakresie

funkcjonalności opcjonalnych w sposób nieproporcjonalny oraz prowadzący
‎do uprzywilejowania określonego modelu rozwiązania funkcjonującego na rynku.
‎W załączniku nr 1B do SWZ Zamawiający wprowadził katalog funkcjonalności opcjonalnych

podlegających punktacji w ramach kryterium oceny ofert.

Odwołujący kwestionuje w całości sekcję „Funkcjonalności systemu związane z ewaluacją oraz integracją z MNiSW (E)", która obejmuje szereg szczegółowych funkcjonalności dotyczących analizy wyników ewaluacji działalności naukowej, w tym m.in.:

a) dashboardy prezentujące wyniki dyscyplin naukowych,

b) algorytmy obliczające punktację osiągnięć naukowych lub artystycznych,

c) narzędzia optymalizacji wyników ewaluacyjnych,

d) moduły szacowania kategorii naukowej jednostki.

Wprowadzenie do kryteriów oceny ofert bardzo szczegółowych funkcjonalności związanych
‎z konkretnymi mechanizmami obliczania wyników ewaluacji jest w obecnej sytuacji nieuzasadnione merytorycznie oraz nieproporcjonalne. Proces ewaluacji działalności naukowej w Polsce został niedawno zakończony, natomiast zasady kolejnej ewaluacji
‎nie zostały jeszcze określone i będą przedmiotem dalszych prac legislacyjnych. W takiej sytuacji punktowanie bardzo szczegółowych funkcjonalności odnoszących się do konkretnych algorytmów ewaluacyjnych prowadzi do premiowania określonych implementacji systemowych, które mogą w krótkim czasie utracić aktualność w związku ze zmianą przepisów regulujących proces ewaluacji. Z punktu widzenia potrzeb Zamawiającego istotne jest,
‎aby system umożliwiał rozwój oraz dostosowywanie funkcjonalności analitycznych w trakcie jego eksploatacji, a nie aby już na etapie składania ofert posiadał konkretne implementacje algorytmów odpowiadających aktualnemu modelowi ewaluacji.Wprowadzenie do kryteriów oceny ofert tak szczegółowych funkcjonalności prowadzi natomiast do sytuacji, w której punktowane są konkretne rozwiązania implementacyjne istniejące obecnie na rynku,
‎co w sposób nieuzasadniony ogranicza konkurencję w postępowaniu.

Specyfika rynku systemów informacji naukowej w Polsce

Dla właściwej oceny zarzutów Odwołujący wskazuje również na specyfikę rynku systemów

informacji naukowej w Polsce.

Rynek ten ma charakter stosunkowo wąski i wyspecjalizowany, a rozwiązania wspierające

zarządzanie informacją o działalności naukowej oraz procesy ewaluacyjne są dostarczane przez ograniczoną liczbę podmiotów posiadających doświadczenie w integracji z krajowymi systemami ministerialnymi, w szczególności POL-on i PBN.

W praktyce na rynku polskim funkcjonuje obecnie trzech głównych dostawców tego typu rozwiązań:

a) PCG Academia, która oferuje rozwiązanie oparte na połączeniu repozytorium open source

DSpace z własnym, zamkniętym systemem analitycznym (ScienceCloud) obsługującym

procesy ewaluacyjne oraz integrację z systemami ministerialnymi,

b) Index Copernicus, który oferuje system skoncentrowany przede wszystkim na funkcjonalnościach analitycznych i ewaluacyjnych, bez własnego rozwiązania repozytoryjnego,

c) Sages (system Omega-PSIR), który oferuje rozwiązanie kompleksowe obejmujące zarówno funkcjonalności repozytoryjne, jak i analityczne w ramach jednego systemu rozwijanego na rynku polskim.

Jednocześnie należy wskazać, że w obszarze repozytoriów naukowych wykorzystywane
‎są również rozwiązania międzynarodowe, takie jak DSpace, które ze względu na charakter projektu open source posiadają bardzo dużą liczbę wdrożeń na świecie. Funkcjonują również rozwiązania rozwijane w Polsce, takie jak dLibra, wykorzystywane w licznych instytucjach naukowych i kulturalnych.

Istotne jest przy tym, że funkcjonalności ewaluacyjne oraz integracje z systemami ministerialnymi nie są rozwijane w modelu open source, ponieważ stanowią zasadniczy element know-how poszczególnych dostawców systemów informacji naukowej. W tym kontekście sposób opisania przedmiotu zamówienia w Postępowaniu prowadzi do sytuacji,
‎w której realnie możliwe do zastosowania pozostaje jedynie jedno rozwiązanie funkcjonujące na rynku. Konstrukcja postępowania eliminuje bowiem zarówno dostawców oferujących rozwiązania skoncentrowane na funkcjonalnościach analitycznych, jak i rozwiązania kompleksowe rozwijane na rynku krajowym, które nie są dystrybuowane w modelu open source.
‎W konsekwencji Postępowanie zostało ukształtowane w sposób, który przy uwzględnieniu rzeczywistej struktury rynku prowadzi do wykluczenia większości podmiotów posiadających

doświadczenie w dostarczaniu systemów informacji naukowej w Polsce.

Odniesienie do uzasadnienia wymogu oprogramowania open source

Zamawiający wskazał, że wymóg wykorzystania oprogramowania o otwartej licencji wynika
‎z konieczności zapewnienia w szczególności przejrzystości działania systemu, możliwości jego dalszego rozwoju przez inne podmioty, zapewnienia ciągłości działania Platformy
‎w okresie trwałości projektu oraz korzystania z rozwiązań rozwijanych przez innych użytkowników tego oprogramowania.

Odwołujący wskazuje, że cele te są co do zasady uzasadnione z punktu widzenia interesu

Zamawiającego. Jednakże nie pozostają one w bezpośrednim i wyłącznym związku
‎z wymogiem zastosowania oprogramowania open source. Wskazane przez Zamawiającego cechy systemu mogą zostać osiągnięte również przy wykorzystaniu oprogramowania rozwijanego w innym modelu licencyjnym, o ile zapewnia ono odpowiednie mechanizmy dostępu do kodu źródłowego, możliwości jego rozwijania oraz zasady współdzielenia zmian pomiędzy użytkownikami systemu.

Przykładowo Odwołujący oferuje system informacji naukowej rozwijany od wielu lat na rynku

polskim, który choć nie jest dystrybuowany w modelu open source, spełnia wszystkie wskazane przez Zamawiającego cele funkcjonalne. System ten rozwijany jest w modelu współpracy środowiskowej pomiędzy uczelniami, a kierunek jego rozwoju wyznaczany jest przez społeczność użytkowników instytucjonalnych. Uczelnie korzystające z systemu posiadają możliwość rozwijania jego funkcjonalności, a zmiany wprowadzane przez poszczególnych użytkowników są udostępniane pozostałym instytucjom korzystającym
‎z systemu. Model ten zapewnia w praktyce:

a) przejrzystość działania systemu oraz możliwość weryfikacji jego funkcjonowania,

b) możliwość jego dalszego rozwoju przez użytkowników po zakończeniu wdrożenia,

c) ciągłość rozwoju i utrzymania systemu w ramach społeczności użytkowników,

d) korzystanie z funkcjonalności rozwijanych przez inne instytucje wykorzystujące
‎to rozwiązanie.

W konsekwencji wskazane przez Zamawiającego cele nie stanowią argumentu przemawiającego za koniecznością zastosowania wyłącznie oprogramowania open source, lecz odnoszą się do ogólnych zasad zapewnienia możliwości dalszego rozwoju i utrzymania systemu informatycznego.

Wymóg zastosowania oprogramowania open source prowadzi natomiast
‎do nieuzasadnionego zawężenia kręgu potencjalnych wykonawców, mimo że wskazane cele mogą zostać osiągnięte również przy wykorzystaniu innych modeli rozwoju oprogramowania.

Na tle całokształtu dokumentacji postępowania należy również wskazać, że rzeczywisty przedmiot zamówienia został w Postępowaniu opisany w sposób nieadekwatny do jego faktycznej treści ekonomicznej i funkcjonalnej. Z analizy OPZ oraz przewidzianego
‎60-miesięcznego okresu utrzymania i rozwoju systemu wynika bowiem, że zasadniczym elementem zamówienia jest w istocie długoterminowe korzystanie z systemu analitycznego wspierającego procesy ewaluacji działalności naukowej, świadczone w modelu usługowym przez okres pięciu lat. Okres ten odpowiada pełnemu cyklowi ewaluacji działalności naukowej w Polsce.

W tym kontekście repozytorium oparte o oprogramowanie DSpace pełni w Postępowaniu przede wszystkim funkcję elementu pomocniczego o relatywnie niewielkiej wartości ekonomicznej, podczas gdy zasadnicza wartość zamówienia związana jest z dostarczeniem
‎i utrzymaniem rozbudowanego systemu analitycznego oraz integracyjnego obsługującego procesy ewaluacyjne.

Taki sposób skonstruowania zamówienia prowadzi do sytuacji, w której formalnie Postępowanie zostało opisane jako wdrożenie platformy repozytoryjnej opartej
‎o oprogramowanie open source, natomiast w rzeczywistości obejmuje wieloletnie korzystanie z wyspecjalizowanego systemu ewaluacyjnego rozwijanego przez wykonawcę, co dodatkowo potwierdza, że konstrukcja Postępowania została dostosowana do konkretnego modelu rozwiązania funkcjonującego na rynku.

Wobec powyższego, Odwołujący wniósł jak na wstępie.

Zamawiający pismem z dnia 14 kwietnia 2026 roku złożył odpowiedź na odwołanie, w której uwzględnił zarzuty podniesione w petitum odwołania w pkt 1 i 2 w całości, oraz częściowo
‎w zakresie pkt 3 w części odnoszącej się do określenia jako wymogu równoważności względem systemu DSpace dodatkowych kryteriów dotyczących skali wdrożeń lub zasięgu geograficznego, oraz o oddalenie odwołania w zakresie pozostałych zarzutów.

Po przeprowadzeniu rozprawy z udziałem Stron na podstawie zgromadzonego
‎w sprawie materiału dowodowego oraz oświadczeń i stanowisk złożonych pisemnie oraz ustnie do protokołu, Krajowa Izba Odwoławcza ustaliła co następuje:

Izba ustaliła, że nie została wypełniona żadna z przesłanek, o których stanowi art. 528 ustawy Prawo zamówień publicznych (t.j. Dz. U. z 2024 r. poz.1320 ze zm.) skutkujących odrzuceniem odwołania. Odwołanie zostało wniesione do Prezesa Krajowej Izby Odwoławczej w dniu 9 marca 2026 roku wobec treści Specyfikacji Warunków Zamówienia opublikowanej
‎w dniu 25 lutego 2026 roku.

Izba ustaliła, że Odwołujący przekazał w ustawowym terminie kopię odwołania Zamawiającemu. Izba ustaliła również, że zostały wypełnione łącznie przesłanki z art. 505 ust 1 ustawy – środki ochrony prawnej określone w niniejszym dziale przysługują wykonawcy, uczestnikowi konkursu, a także innemu podmiotowi, jeżeli ma lub miał interes w uzyskaniu danego zamówienia oraz poniósł lub może ponieść szkodę w wyniku naruszenia przez Zamawiającego przepisów niniejszej ustawy - to jest posiadania interesu w uzyskaniu danego zamówienia oraz możliwości poniesienia szkody.

Przywołując regulacje prawne stanowiące podstawę zarzutów wniesionego odwołania należy wskazać, iż zgodnie z:

art. 16 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;

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

art. 239 ust. 1 Pzp - Zamawiający wybiera najkorzystniejszą ofertę na podstawie kryteriów oceny ofert określonych w dokumentach zamówienia.

Krajowa Izba Odwoławcza zważyła co następuje:

Izba umorzyła postępowanie odwoławcze w zakresie zarzutów uwzględnionych przez Zamawiającego, podniesionych w petitum odwołania w pkt 1 i 2 w całości, oraz częściowo
‎w pkt 3 - w części odnoszącej się do określenia jako wymogu równoważności względem systemu DSpace dodatkowych kryteriów, dotyczących skali wdrożeń lub zasięgu geograficznego. Zmiany treści SWZ, do których wprowadzenia zobowiązał się Zamawiający, spełniają żądania Odwołującego – co Izba ustaliła podczas posiedzenia.

Biorąc pod uwagę zgromadzony w sprawie materiał dowodowy, poczynione ustalenia faktyczne oraz orzekając w granicach zarzutów zawartych w odwołaniu, Izba stwierdziła, że odwołanie nie zasługują na uwzględnienie.

Izba wskazuje, że rozpoznając zarzuty podniesione w odwołaniu ocenia czynności podjęte przez Zamawiającego w okolicznościach danej sprawy, odpowiadając na pytanie,
‎czy Zamawiający poprzez ich wykonanie lub zaniechanie czynności do których wykonania był zobowiązany na podstawie ustawy Pzp (tu kwestionowane postanowienia Specyfikacji Warunków Zamówienia oraz Opisu Przedmiotu Zamówienia) naruszył przepisy prawa zamówień publicznych mające lub mogące mieć istotny wpływ na wynik postępowania
‎o udzielenie zamówienia publicznego.

W analizowanym stanie faktycznym w ocenie Izby, Zamawiający nie naruszył przepisów prawa zamówień publicznych mających lub mogących mieć istotny wpływ na wynik postępowania
‎o udzielenie zamówienia publicznego, w zakresie podnoszonym w odwołaniu.

W pierwszej kolejności Izba podkreśla, że argumentacja podniesiona w treści odwołania oraz podczas rozprawy, nie dała podstaw Izbie do uznania, że Zamawiający ukształtował postanowienia Specyfikacji Warunków Zamówienia oraz Opisu Przedmiotu Zamówienia z naruszeniem przepisów Pzp.

Przedstawiając rozważania natury ogólnej, Izba podkreśla, że stawiane żądania
‎w zakresie modyfikacji postanowień SWZ i OPZ powinny prowadzić do eliminacji niezgodności z przepisami ustawy Pzp, a nie do udogadniania warunków realizacji zamówienia wykonawcy podnoszącemu te żądania. Wymagań Zamawiającego nie należy rozpatrywać z perspektywy konkretnego wykonawcy, Iecz z perspektywy potrzeb Zamawiającego, bowiem jego celem jest wybór oferty, która będzie spełniała uzasadnione potrzeby Zamawiającego. Istotne jest natomiast to, aby nie naruszały one przepisów i zasad obowiązujących w Pzp.

Odwołujący podnosząc zarzut, winien wykazać, dlaczego kwestionowane postanowienia naruszają przepisy Pzp, oraz wskazać uzasadnienie dla proponowanej przez siebie modyfikacji, której wprowadzenie doprowadzi do stanu zgodności z przepisami ustawy Pzp, a w ocenie Izby tego nie uczynił.

Odwołujący nie przedstawił żadnych obiektywnych argumentów, wskazujących dlaczego kwestionowane postanowienia naruszają przepisy Pzp, a skoncentrował się jedynie na postulacie ich modyfikacji w sposób korzystny dla siebie. Nie wykazał również, dlaczego oferta wybrana zgodnie z wnioskowaną w odwołaniu treścią modyfikacji, będzie dla Zamawiającego najbardziej adekwatna w stosunku do jego uzasadnionych potrzeb.

W ocenie Izby Zamawiający uzasadnił, dlaczego kwestionowane przez Odwołującego postanowienia SWZ i OPZ są dla niego istotne, oraz wykazał ich zgodność z przepisami Pzp,
‎co zaprzecza zarzutom stawianym w odwołaniu.

W odniesieniu do zarzutów nieuwzględnionych przez Zamawiającego, Izba wskazuje, że oddaliła zarzut 3 dotyczący naruszenia art. 99ust. 4 Pzp w zw. z art. 16 pkt 1 i 3 Pzp w zw. z pkt 1 Załącznika nr 1 do SWZ – Opis przedmiotu zamówienia (OPZ) w części nieuwzględnionej przez Zamawiającego.

W pierwszej kolejności Izba w pełni podziela stanowisko podniesione w odpowiedzi
‎na odwołanie przez Zamawiającego, zgodnie z którym Odwołujący zaskarżył w odwołaniu jedynie zapisy Załącznika nr 1 do SWZ – Opis przedmiotu zamówienia. W treści zarzutu nr 3 Odwołujący jednoznacznie wskazał, że rzekome naruszenie Pzp przez Zamawiającego dotyczy sposobu sformułowania pkt 1 Załącznika nr 1 do SWZ – Opis przedmiotu zamówienia. W sformułowanych wnioskach lit. f) i g) Odwołujący wnosi jedynie o zmianę punktu 1 ppkt 1 Załącznika nr 1 – Opis przedmiotu zamówienia. Z tego wynika, że Odwołujący nie zaskarżył tym zakresie żadnych innych zapisów dokumentów zamówienia poza wskazanym pkt 1 ppkt 1 Załącznika nr 1 do SWZ – Opis przedmiotu zamówienia.

Zarzut, z uwagi na jego ograniczenie co do zapisów, powinien zostać oddalony. Zmiana w zakresie, w jakim Odwołujący o nią wnosi, nie doprowadzi w rzeczywistości do zmiany wymagań Zamawiającego, które w ocenie Odwołującego naruszają uczciwą konkurencję. Odwołujący zaskarżył wyłącznie pkt 1 ppkt 1 Załącznika nr 1 do SWZ – Opis przedmiotu zamówienia, zaś wymagania w zakresie konieczności dostarczenia oprogramowania opartego o rozwiązanie otwartoźródłowe wynika również z innych zapisów dokumentów zamówienia, m.in.:

1)z pkt 2.1. i pkt 5.1. ogłoszenia o zamówieniu (…),

2)z części III ust. 2 Specyfikacji Warunków Zamówienia (…),

3)z pkt 3 ppkt 12 i 13 Załącznika nr 1 do SWZ – Opis Przedmiotu Zamówienia (…),

4)z § 3 ust. 1 pkt 7 wzoru umowy (…),

5)z Załącznika nr 3 do SWZ – Wzór umowy (…).

Izba wskazuje, że w przypadku odwołania na treść dokumentacji zamówienia Izba bierze pod uwagę nie tylko treść podnoszonych zarzutów, ale i konstrukcję żądania Odwołującego co do modyfikacji tej dokumentacji, której celem ma być doprowadzenie
‎do zgodności z przepisami Pzp. Izba nie może więc samodzielnie za Zamawiającego kształtować treści tej dokumentacji ani za Odwołującego dokonywać interpretacji czy rozszerzenia stawianych żądań.

W analizowanym stanie faktycznym, odnosząc się ściśle do proponowanych przez Odwołującego zmian treści SWZ i OPZ, z pominięciem postanowień, które wskazał
‎Zamawiający, brak jest możliwości wyeliminowania niezgodności z przepisami Prawa zamówień publicznych, których istnienie zarzuca Odwołujący. Już sama ta okoliczność wskazuje na brak możliwości uwzględnienia zarzutu.

Odnosząc się również do merytorycznej treści zarzutu, Izba nie podzieliła stanowiska Odwołującego dotyczącego pozornego dopuszczenia konkurencji przez Zamawiającego,
‎co ma prowadzić do uprzywilejowania konkretnego modelu rozwiązania funkcjonującego
‎na rynku.

W treści Opisu przedmiotu zamówienia Zamawiający określił przedmiot zamówienia, wskazał moduły wchodzące w jego zakres oraz komponenty dotyczące funkcjonalności związane
‎z ewaluacją oraz integracją z MNiSW. Podstawowym elementem przedmiotu zamówienia jest wdrożenie platformy informacji naukowo-badawczej na podstawie otwartoźródłowego (open source) oprogramowania DSpace – rozwiązania posiadanego i funkcjonującego
‎u Zamawiającego, dla którego Zamawiający dopuścił możliwość zaoferowania oprogramowania równoważnego, określając kryteria równoważności.

Izba wskazuje, że Zamawiający uwzględnił zarzuty dotyczące określenia kryteriów równoważności w zakresie liczby wdrożeń, krajów wdrożeń i społeczności międzynarodowej, odnosząc je do wymiaru technicznego, dotyczącego funkcjonalności systemu i zasad licencji udzielonej przez wykonawcę. Tym samym, zgodnie z żądaniem Odwołującego dokonał modyfikacji treści OPZ.

W ocenie Izby, niezmieniony wymóg Zamawiającego dotyczący wdrożenia platformy opartej o oprogramowanie udostępniane na zasadzie licencji otwartoźródłowej nie może stanowić naruszenia zasady równego traktowania wykonawców, uczciwej konkurencji czy proporcjonalności, ponieważ oprogramowanie takie jest ogólnodostępne i bezpłatne, a dostęp do niego nie jest niczym i dla nikogo ograniczony. Dostępne jest również na takich samych zasadach dla Odwołującego.

Odwołujący nie wykazał bowiem, a nawet nie zaprzeczał podczas rozprawy, że nie jest
‎w stanie zaoferować rozwiązania opartego na oprogramowaniuotwartoźródłowym. Wskazywał jedynie na pewne ograniczenia techniczne i czasowe. Jednakże takie okoliczności nie zostały objęte zarzutem odwołania, dlatego muszą zostać przez Izbę pominięte.

Całkowicie niezrozumiały dla Izby jest argument Odwołującego, że zasadnicza wartość ekonomiczna zamówienia nie dotyczy samego systemu DSpace – który jako bezpłatny stanowi warstwę bazową, lecz zamkniętego oprogramowania ewaluacyjnego i analitycznego dostarczonego przez wykonawcę.

Taki model zamówienia został określony przez Zamawiającego i każdy z wykonawców ma możliwość zaoferowania rozwiązania opartego na oprogramowaniu otwartoźródłowym
‎z komponentami zamkniętego oprogramowania ewaluacyjnego i analitycznego. Wartość tak ustalonego zamówienia została przez Zamawiającego uwzględniona przy szacowaniu zamówienia. Natomiast zamówienie w całości oparte o rozwiązania komercyjne, stanowiłoby wyższy koszt niż oparte jedynie w części na oprogramowaniu komercyjnych, co niewątpliwie jest argumentem mającym przełożenie na wartość ekonomiczną.

Zamawiający, wyjaśnił ponadto w odpowiedzi na odwołanie oraz podczas rozprawy, że mając świadomość, że żaden wykonawca na rynku nie będzie skłonny do udzielenia licencji open source na komponenty - gdyż są to elementy wytwarzane i udostępniane typowo komercyjnie, wyraźnie oddzielił system od komponentów i określił odrębne zasady uzyskiwania praw
‎do tych elementów przedmiotu zamówienia przez Zamawiającego.

Izba dała wiarę wyjaśnieniom Zamawiającego, co do jego obiektywnych
‎i uzasadnionych potrzeb związanych z koniecznością posiadania platformy opartej
‎o rozwiązanie otwartoźródłowe, określonych w Opisie przedmiotu Zamówienia, (pkt 3 ppkt 15 OPZ), tj.:

Wymóg wykorzystania oprogramowania o otwartej licencji (zgodnej z definicją Open Source Initiative) wynika z konieczności zapewnienia:

a. pełnej przejrzystości działania Platformy,

b. możliwości modyfikacji i rozwoju przez inne podmioty po zakończeniu umowy,

c. zapewnienia ciągłości niezakłóconego działania Platformy również w okresie trwałości projektu;

d.korzystania z rozwiązań wprowadzonych przez innych użytkowników tego oprogramowania.”

oraz zawartym w odpowiedzi na odwołanie i wskazanym podczas rozprawy:

Zamawiający jest uczelnią publiczną, która udziela zamówienia w ramach realizowanego projektu „Platforma informacji naukowo-badawczej Uniwersytetu w Białymstoku – nowoczesna e-usługa transferu osiągnięć uczelni do społeczeństwa” (nr projektu: FEPD.01.02-IZ.00-0006/24). Jak wskazuje charakter działalności Zamawiającego, a także cel realizowanego projektu, kluczowe znaczenie ma w niniejszym postępowaniu zapewnienie trwałości, dostępności oraz otwartości tworzonej platformy zarówno dla środowiska naukowego samej uczelni, jak i szerokiego kręgu odbiorców społecznych. Projekt ukierunkowany jest bowiem na zwiększenie dostępności zasobów wiedzy oraz wspieranie otwartej nauki (open science). W tym kontekście zastosowanie rozwiązań open source pozostaje nie tylko uzasadnione, alewręcz konieczne dla osiągnięcia zakładanychcelów projektu. Wykorzystanie oprogramowania o otwartym charakterze umożliwia szerokie udostępnianie zasobów naukowych bez ograniczeń licencyjnych, co jest w pełni zgodne z misją uczelni publicznej oraz zasadami otwartego dostępu do wiedzy.

Jednocześnie konieczność zastosowania modelu open source wynika z potrzeb Zamawiającego wywołanych długoterminowym zamiarem korzystania z platformy. Zastosowanie takiego modelu eliminuje ryzyko uzależnienia od jednego dostawcy oraz umożliwia elastyczne dostosowywanie systemu do zmieniających się potrzeb użytkowników. Nie bez znaczenia pozostaje również fakt, że rozwiązania open source sprzyjają interoperacyjności i pozwalają na wykorzystanie dorobku oraz rozwiązań wypracowanych przez społeczność użytkowników i deweloperów. Zamawiający, po okresie realizacjizamówienia, będzie mógł bezpłatnie rozwijać wdrożony system, a także korzystać z efektów rozwoju systemu przez innych jego użytkowników.

Ponadto, w przypadku projektów współfinansowanych ze środków publicznych, Zamawiający zobowiązany jest do zapewnienia trwałości projektu. Wymóg zastosowania oprogramowania open source pozostaje w bezpośrednim związku z koniecznością zachowania trwałości projektu oraz z koniecznością racjonalnego gospodarowania środkami publicznymi, gdyż ogranicza koszty utrzymania systemu w przyszłości oraz umożliwia jego dalszy rozwój i wykorzystanie bez konieczności ponoszenia dodatkowych opłat licencyjnych.W konsekwencji należy uznać, że wymóg oparcia systemu
‎o oprogramowanie otwartoźródłowe nie ma charakteru dyskryminacyjnego, lecz wynika
‎z obiektywnych, uzasadnionych i proporcjonalnych potrzeb Zamawiającego, ściśle powiązanych z charakterem jego działalności oraz celami realizowanego projektu.

Opisane powyżej szczególne właściwości oprogramowania otwartoźródłowego
‎są powszechnie rozpoznawane:

„Zalety open source:

Elastyczność – ze względu na swobodny dostęp do kodu źródłowego, programiści mogą dopasowywać oprogramowanie do unikalnych potrzeb danego biznesu.

Opłacalność – początkowe koszty wdrożenia oprogramowania typu open source są zwykle niewielkie, a nawet żadne. Dzięki oparciu się na gotowym rozwiązaniu oszczędzasz czas
‎i pieniądze na budowaniu go od podstaw.

Niezależność – decydując się na rozwiązanie open source nie uzależniasz się od jednego dostawcy konkretnego oprogramowania.

Liczna społeczność – nad oprogramowaniami open source mogą pracować deweloperzy
‎z całego świata, którzy dbają o jego rozwój i wprowadzają innowacje.

Stałe aktualizacje i bezpieczeństwo – to dzięki społeczności można mieć też pewność,
‎że wszelkie błędy i luki w otwartym oprogramowaniu zostaną szybciej znalezione
‎i naprawione. Im bardziej popularnej jest dane rozwiązanie, tym maleje ryzyko zatrzymania lub zaniechania jego rozwoju.”

Potrzeby te nie mogą być zrealizowane w żaden inny sposób jak tylko wymaganie
‎od wykonawców bazowania na oprogramowaniu otwartoźródłowym. Rozwiązania komercyjne wprowadzają bowiem istotne ograniczenia w zakresie dostępu do kodu źródłowego, jego modyfikacji oraz dalszego rozwoju przez podmioty trzecie. W praktyce oznacza to powstanie zależności Zamawiającego od konkretnego dostawcy, zarówno na etapie wdrożenia, jak i w całym okresie eksploatacji systemu. W przypadku rozwiązań komercyjnych Zamawiający nie ma również możliwości dokonywania zmian i rozbudowy systemu, co w perspektywie wieloletniego funkcjonowania platformy stanowi istotne ryzyko organizacyjne i finansowe. Ograniczenia licencyjne wpływają także na brak powszechnej dostępności systemu.

Izba za zasadne uznała również stanowisko Zamawiającego, że kluczowym elementem oprogramowania open source jest zapewnienie pełnego dostępu do kodu źródłowego wszystkim użytkownikom, a więc brak ograniczeń w zakresie dostępu do kodu źródłowego przez nieograniczony krąg podmiotów, jego swobodnej modyfikacji dalszej redystrybucji zarówno w postaci oryginalnej, jak i zmodyfikowanej oraz wykorzystywania oprogramowania do dowolnych celów bez konieczności uzyskiwania zgody. Tymczasem inne modele licencyjne, w tym model wskazywany przez Odwołującego, z samej swojej natury przewidują ograniczenia w co najmniej jednym z tych obszarów (gdyby takich ograniczeń
‎nie przewidywały można byłoby je bowiem zaklasyfikować jako otwartoźródłowe).Ograniczenia te mogą polegać na uzależnieniu dostępu do kodu źródłowego od zawarcia umowy lub uczestnictwa w określonej strukturze organizacyjnej, braku prawa do swobodnej redystrybucji zmodyfikowanego oprogramowania, konieczności uzyskiwania zgody producenta na wprowadzanie zmian lub na ich dalsze udostępnianie. Uzyskanie dodatkowych uprawnień do oprogramowania zazwyczaj związane jest z koniecznością poniesienia dodatkowych kosztów.

W konsekwencji, nawet jeśli dany system przewiduje pewien poziom współpracy między użytkownikami lub umożliwia współdzielenie wybranych rozwiązań, nie oznacza to, że spełnia on standard otwartości właściwy dla open source. Oprogramowanie inne niż open source jest jedynie modelem ograniczonej współpracy, który nie zapewnia Zamawiającemu trwałego, nieograniczonego i niezależnego dostępu do oprogramowania ani możliwości jego dalszego rozwoju przez dowolnie wybrane podmioty.W modelach komercyjnych Zamawiający pozostaje ograniczony warunkami licencyjnymi określanymi przez dostawcę, które ograniczają zakres jego uprawnień.

Tym samym brak jest podstaw do uznania, że odniesienie się w opisie przedmiotu zamówienia do oprogramowania DSpace lub równoważnego, prowadzi do uprzywilejowania jakiegokolwiek wykonawcy czy producenta. DSpace (podobnie jak inne rozwiązania open source) funkcjonuje w modelu, który z definicji eliminuje bariery dostępu typowe dla oprogramowania komercyjnego, takie jak opłaty licencyjne czy ograniczenia w zakresie modyfikacji kodu. W konsekwencji wszyscy wykonawcy znajdują się w porównywalnej sytuacji, co wzmacnia zasadę równego traktowania oraz uczciwej konkurencji.

W odniesieniu do uzasadnionych potrzeb Zamawiającego twierdzenie Odwołującego, że cel ten może on osiągnąć przy wykorzystaniu innych modeli licencyjnych, jest nieuprawnione, bowiem pomija zasadniczą różnicę pomiędzy systemem rzeczywiście otwartym, w którym uprawnienia użytkownika mają charakter nieograniczony, a systemem
‎o kontrolowanym dostępie, w którym uprawnienia te są wtórne, warunkowe. ograniczone
‎i potencjalnie odwołalne. W konsekwencji jedynie zastosowanie oprogramowania open source gwarantuje realizację wskazanych przez Zamawiającego celów.

Nie jest również zasadny argument Odwołującego, że „wykonawcy oferujący własne systemy repetytoryjne lub systemy informacji naukowej – które nie są dystrybuowane
‎w modelu open source – zostają z góry wykluczeni z możliwości ubiegania się o zamówienie, mimo, że mogliby dostarczyć rozwiązanie funkcjonalne odpowiadające potrzebom Zamawiającego”.

W ocenie Izby, Zamawiający wykazał swoje obiektywne i uzasadnione potrzeby, które mają być zrealizowane w wyniku udzielenia przedmiotowego zamówienia. Ponadto oparcie rozwiązania na oprogramowaniu komercyjnym doprowadzi do konieczności ponoszenia przez Zamawiającego w przyszłości zwiększonych kosztów. Podkreślenia wymaga, że Zamawiający nie wymaga aby całość przedmiotu zamówienia działała w oparciu o rozwiązania open source. Wymóg ten nie odnosi się do komponentów, na które może zostać udzielona licencja inna niż otwartoźródłowa.

Dodatkowo, zauważenia wymaga – co podkreślił Zamawiający, że Odwołujący chcąc spełnić postawiony wymóg, może oprzeć oferowane rozwiązanie o inne oprogramowanie, również własne, jeżeli udzieli otwartoźródłowej licencji.

Podsumowując, w ocenie Izby, Zamawiający ma prawo opisać przedmiot zamówienia w taki sposób, aby zaspokoić swoje uzasadnione potrzeby, a który nie ogranicza możliwości zaoferowania rozwiązania opartego o powszechnie dostępne, bezpłatne oprogramowanie.

Ponadto analiza dokumentacji postępowania nie potwierdziła zasadności argumentacji Odwołującego, zgodnie z którą Zamawiający wymaga dostarczenia Komponentów w modelu SaaS na okres 60 miesięcy.

Z treści warunków zamówienia wynika, że:

1) pkt 2 ppkt 4 OPZ: „Komponent – inne niż System oprogramowanie, dopuszczone w OPZ w zakresie funkcjonalności Platformy związanych z ewaluacją oraz integracją z MNiSW, dostarczone w ramach wdrożenia na licencji innej niż licencja otwartoźródłowa
‎lub w modelu SAAS”

2)pkt 3 ppkt 18 OPZ: „Dopuszczalne jest udostepnienie Komponentów w modelu SAAS przez okres 60 miesięcy od dnia podpisania protokołu odbioru wdrożenia na warunkach odpowiadających licencji do Komponentów określonych powyżej.”,

3)pkt 7.4. wiersz E.1 OPZ tabeli: „Moduł integracyjny może działać w modelu SaaS

4)§ 2 pkt 13 wzoru umowy: „Komponent – inne niż System oprogramowanie, dopuszczone w OPZ w zakresie funkcjonalności Platformy związanych z ewaluacją oraz integracją
‎z MNiSW, dostarczone w ramach wdrożenia na licencji innej niż licencja otwartoźródłowa, lub w modelu SAAS”

5)§ 8 ust. 11 wzoru umowy: „Wykonawca zobowiązuje się zapewnić Zamawiającemu
‎z chwilą przekazania licencje na korzystanie z Komponentów, która będzie:

a. licencją na okres 60 miesięcy od dnia podpisania protokołu odbioru wdrożenia

b. licencją bez ograniczeń co do liczby zarejestrowanych użytkowników,

c. licencją bez ograniczeń co do liczby jednocześnie korzystających użytkowników,

d. licencją bez ograniczeń terytorialnych,

e. licencją bez ograniczeń co do wielkości bazy danych,

f. udzieloną na polach eksplantacji wymaganych do zgodnego z przeznaczeniem korzystania z Platformy,

lub zapewnić możliwość korzystania przez Zamawiającego z Komponentów w modelu SAAS przez okres 60 miesięcy od dnia podpisania protokołu odbioru wdrożenia
‎na warunkach odpowiadających licencji do Komponentów określonych powyżej.”

Z powyższego wynika, że model SaaS jest jednym z dopuszczonych modeli realizacji komponentów Platformy, których wybór należy do Wykonawcy.

Zamawiający potwierdził również, że świadomie dopuścił alternatywne modele realizacji komponentów zarówno w formie klasycznego udzielenia licencji, jak i w modelu usługowym SaaS – uznając je za równoważne, pozostawiając wybór wykonawcy.

Niezasadnym jest również argument, że wymaganie 60-miesięcznego okresu utrzymania i aktualizacji systemu stanowi ograniczenie konkurencji. Zgodnie z OPZ elementem systemu są również komponenty w zakresie funkcjonalności związanych
‎z ewaluacją oraz integracją zMNiSW. Zasadne jest więc założenie, że Zamawiający musi zapewnić sobie możliwość korzystania z tych komponentów przez określony czas, wskazując minimalny okres. Również z uwagi na to, że przedmiotowe zamówienia realizowane jest
‎ze środków unijnych, Zamawiający zobowiązany jest do zapewnienia możliwości korzystania
‎z całości dostarczonego rozwiązania przez co najmniej przez okres realizacji projektu i przez okres utrzymania trwałości projektu. W tym kontekście określenie minimalnego
‎60-miesięcznego okresu utrzymania i aktualizacji systemu nie stanowi nadmiernego wymagania Zamawiającego, lecz jest bezpośrednio uzasadnione obowiązkami nałożonymi
‎na niego jako beneficjenta środków europejskich oraz jego obiektywnymi potrzebami. Ponadto, zasady licencjonowania dla komponentów zostały określone we wzorze umowy i nie zostały przez Odwołującego zakwestionowane.

Izba podziela również stanowisko Zamawiającego, że powyższy wymóg jest konieczny i służy zapewnieniu ciągłości działania systemu oraz jego zgodności z dynamicznie zmieniającymi się uwarunkowaniami technicznymi. Brak zagwarantowania odpowiedniego okresu utrzymania mógłby prowadzić do sytuacji, w której Zamawiający zostałby pozbawiony możliwości prawidłowego korzystania z systemu, co z kolei skutkowałoby naruszeniem zasad trwałości projektu, a Zamówienie nie mogłoby jednocześnie spełniać jego potrzeb.
‎Ponadto 60-miesięczny okres utrzymania oraz aktualizacji systemu nie ogranicza konkurencji, bowiem odnosi się w równym stopniu do wszystkich podmiotów ubiegających się o udzielenie zamówienia.

Za niezasadny Izba uznała również wniosek Odwołującego o dokonanie podziału zamówienia na części obejmujące co najmniej:

1)wdrożenie systemu repozytoryjnego spełniającego wymagania określone w OPZ,

2) dostarczenie systemu analitycznego i sprawozdawczego wraz z integracją
‎z systemami POL-on i PBN, oraz odpowiednią zmianą dokumentacji postępowania
‎w tym zakresie.

W ocenie Izby Zamawiający w sposób przekonywujący uzasadnił, dlaczego nie należy dzielić zamówienia na części wskazując, że powyższe elementy zamówienia mają charakter integralny i są ze sobą nierozerwalnie powiązane, stanowiąc jeden połączony i zintegrowany system. Dlatego ze względu na prawidłowość i użyteczność przedmiotu zamówienia, wykonanie całości przedmiotu zamówienia przez jednego wykonawcę jest konieczne. Rozdzielenie bowiem tych elementów pomiędzy różnych wykonawców prowadziłoby
‎do istotnych ryzyk zarówno na etapie realizacji, jak i późniejszej eksploatacji platformy.
‎W szczególności mogłoby to skutkować problemami w zakresie kompatybilności poszczególnych komponentów, rozmyciem odpowiedzialności za prawidłowe działanie całości rozwiązania oraz znacznym utrudnieniem w egzekwowaniu zobowiązań umownych.

Zamawiający podkreślił również, że przedmiot zamówienia został zaprojektowany jako spójny system, w którym warstwa repozytoryjna, funkcjonalności analityczne oraz integracja
‎z systemami zewnętrznymi wzajemnie na siebie oddziałują i wymagają ścisłej koordynacji
‎na etapie projektowania, wdrożenia oraz utrzymania. Powierzenie realizacji tych elementów różnym wykonawcom mogłoby prowadzić do powstania problemów z kompatybilnością
‎lub zapewnieniem pełnego działania wszystkich funkcjonalności, których usunięcie byłoby czasochłonne i obarczone znacznym ryzykiem niepowodzenia.

Dodatkowo, Izba zwraca uwagę, że Odwołujący nie przedstawił żadnej argumentacji potwierdzającej, że brak podziału zamówienia na części prowadzi do ograniczenia uczciwej konkurencyjności, a dokonanie podziału zamówienia na części w sposób wskazany przez Odwołującego, przyczyni się do jej zwiększenia.

Dodać bowiem należy, że samo wprowadzenie wymagań ograniczających konkurencję, nie świadczy jeszcze o naruszeniu uczciwej konkurencji, o której jest mowa
‎w art. 16 pkt 1 Pzp. Podkreślenia wymaga, że każde ograniczenie czy wymóg określony przez Zamawiającego, ma przełożenie na grono wykonawców, mogących ubiegać się o dane zamówienie, stanowiąc w tym zakresie ograniczenie konkurencji. Takie ograniczenie nie oznacza automatycznie, że doszło do naruszenia uczciwej konkurencji, do której zachowania zobowiązany jest Zamawiający.

Ponadto, w ocenie Izby wniosek o podział zamówienia na części nie prowadzi do zwiększenia uczciwej konkurencji, której celem winno być otrzymanie przez Zamawiającego ofert najbardziej adekwatnych do jego uzasadnionych potrzeb, a jedynie służy modyfikacji OPZ, w sposób korzystny dla Odwołującego.

Takie działania Odwołującego nie mogą podlegać ochronie przez Izbę.

Podsumowując powyższy zarzut Izba podzieliła stanowisko Zamawiającego,
‎że Odwołujący upatruje naruszenia Pzp poprzez opisanie przedmiotu zamówienia w sposób, który nie wpisuje się w gotowe rozwiązanie oferowane przez niego. Natomiast opisanie przedmiotu zamówienia poprzez wymaganie dostarczenia rozwiązania opartego
‎o oprogramowanie open source jest uzasadnione potrzebami Zamawiającego. Ponadto Odwołujący może spełnić powyższy wymóg dostosowując oferowane przez siebie rozwiązanie do zasad udzielenia licencji w sposób określony przez Zamawiającego

W odniesieniu do braku podziału zamówienia na części, Zamawiający wykazał, że jest to w pełni uzasadnione charakterem przedmiotu zamówienia oraz potrzebą zapewnienia jego prawidłowej realizacji i późniejszego funkcjonowania.

W odniesieniu do złożonych przez Odwołującego dowodów, Izba uznała je za nieprzydatne dla sprawy, bowiem:

Dowód nr 1 - odnosi się wyłącznie do etapu wdrożenia i nie potwierdza, że korzystanie
‎z platformy opartej na oprogramowaniu komercyjnym, umożliwi Zamawiającemu korzystanie z oprogramowania w okresie późniejszym, na takich samych zasadach, jak umożliwia to oprogramowanie otwartoźródłowe.

Dowód nr 2 i 3 – niczego nie wnosi do sprawy, bowiem potwierdzają, że oprogramowanie DSpace jest wyłącznie systemem repozytoryjnym – co potwierdził sam Zamawiający i jako systemem repozytoryjny jest elementem przedmiotu zamówienia, ponadto każdy podmiot może zostać zarejestrowanym dostawcą usług DSpace,

Dowód n 4 – wykaz postępowań o udzielenie zamówienia prowadzonych przez innych zamawiających – brak jest możliwości odniesienia się do wniosków, z uwagi na brak danych dotyczących tych postępowań. Ponadto, wykaz nie potwierdza, że Zamawiający dokonał opisu przedmiotu zamówienia w oderwaniu od swoich uzasadnionych potrzeb, w tym niezasadnie nie podzielił zamówienia na części.

Dowód nr 5 – nie potwierdza wymagań Zamawiającego. Zamawiający dopuścił możliwość składania ofert równoważnych wobec oprogramowania DSpace.

Dowód nr 6 – porównanie postanowień OPZ w analogicznych postępowaniach - brak jest możliwości odniesienia się do wniosków, z uwagi na brak danych dotyczących tych postępowań, ponadto wnioski odnoszą się w części do treści OPZ zmienionej przez Zamawiającego,

Dowód nr 7 – porównanie postanowień OPZ w postępowaniu prowadzonym przez Akademię Mazowiecką - brak jest możliwości odniesienia się do wniosków, z uwagi na brak danych dotyczących tych postępowań, ponadto odnosi się w części do treści OPZ zmienionej przez Zamawiającego.

Dowód nr 11, 12, 13, 14 – Zamawiający w załączniku nr 3 do umowy określił warunki licencji otwartoźródłowej, które nie zostały zakwestionowane przez Odwołującego,

Dowód nr 15 – treść korespondencji nie odnosi się do uzasadnionych potrzeb Zamawiającego, a jedynie do możliwości sprzedaży usług przez dany podmiot.

Wobec powyższego, zarzut podlegał oddaleniu.

Izba za nieuzasadniony uznała zarzut nr 4 dotyczący naruszenie art. 99 ust. 4 Pzp
‎w zw. z art. 16 pkt 1 i 3 Pzp w związku z wskazanymi podpunktami w punkcie 7.1 załącznika nr 1 do SWZ – OPZ, poprzez opisanie przedmiotu zamówienia w sposób, który jedynie pozornie dopuszcza konkurencję przez dopuszczenie rozwiązań równoważnych do oprogramowania DSpace, a w rzeczywistości prowadzi do uprzywilejowania konkretnego rozwiązania informatycznego – oprogramowania otwartoźródłowego (open source) funkcjonującego na rynku (oprogramowanie DSpace), co w konsekwencji stanowi naruszenie zasad zachowania uczciwej konkurencji oraz równego traktowania wykonawców oraz proporcjonalności.

Izba wskazuje, że Odwołujący poza kwestionowaniem przywołanych w tabeli
‎w pkt F.17 i F.20 postanowień dotyczących OPZ nie przedstawił żadnej argumentacji, wskazującej na naruszenie przez Zamawiającego zarzucanych przepisów Pzp.

Dlatego brak uzasadnienia zarzutu nie pozwala na jego analizę raz ocenę zasadności, co skutkuje koniecznością jego oddalenia.

W tych okolicznościach Izba za nieprzydatne dla sprawy uznała Dowody nr 8 i 9 odnoszące się do powyższego zarzutu.

Izba za niezasadny uznała również zarzut nr 5 dotyczący naruszenie art. 99 ust. 4 Pzp w zw. z art. 16 pkt 1 i 3 Pzp w związku z rozdz. V SWZ – Termin wykonania zamówienia, poprzez określenie harmonogramu realizacji zamówienia w sposób nieracjonalny, niezgodny
‎z zasadami realizacji projektów informatycznych oraz prowadzący do nieuzasadnionego ograniczenia konkurencji, w tym w szczególności poprzez wymaganie przeprowadzenia prezentacji gotowego już rozwiązania informatycznego niezwłocznie po złożeniu ofert
‎w Postępowaniu, co w konsekwencji stanowi naruszenie zasad zachowania uczciwej konkurencji oraz równego traktowania wykonawców oraz proporcjonalności.

W pierwszej kolejności podkreślenia wymaga, że Zamawiający zobowiązał się do zmiany harmonogramu realizacji zamówienia, poprzez zmianę terminu realizacji Etapu 1
‎z 2 tygodni na 4 tygodnie od dnia zawarcia umowy, tj. poprzez nadanie zapisowi następującej treści:

„Etap 1 – w terminie do 4 tygodni od dnia zawarcia Umowy:

a. uruchomienie Systemu w środowisku testowym,

b.uruchomienie integratora danych do systemów Ministerstwa Nauki i Szkolnictwa Wyższego POL-on i PBN, wraz z zasileniem bazy danymi pochodzącymi z tych systemów w zakresie osiągnięć naukowych i danych o pracownikach i doktorantach…”.

- co czyni zarzut w powyższym zakresie niezasadnym.

Następnie wskazać należy, że również w ramach tego zarzutu Odwołujący nie zaskarżył ani nie odniósł się wszystkich postanowień dokumentacji odnoszących się do harmonogramu realizacji zamówienia (§ 6 ust. 1 wzoru umowy, stanowiącego załącznik nr 9 do SWZ oraz formularza ofertowego, stanowiącego załącznik nr 2 do SWZ – tabela i ust. 1) − a żądanie zmiany treści SWZ referuje wyłącznie do postanowień rozdziału V SWZ.

W zakresie powyższego zarzutu, Izba wskazuje, że nie może samodzielnie za Zamawiającego kształtować treści SWZ, ani za Odwołującego dokonywać interpretacji czy rozszerzenia stawianych żądań.

A zatem w analizowanym stanie faktycznym, odnosząc się ściśle do proponowanych przez Odwołującego zmian treści SWZ, z pominięciem postanowień odnoszących się do harmonogramu realizacji zamówienia, brak jest możliwości wyeliminowania niezgodności
‎z przepisami Prawa zamówień publicznych, których istnienie zarzuca Odwołujący. Okoliczność ta wskazuje na brak możliwości uwzględnienia zarzutu.

Ponadto Odwołujący kwestionuje wskazany przez Zamawiającego harmonogram realizacji zamówienia, odnosząc swoje zastrzeżenia do rozwiązań powszechnie przyjętych, stosowanych w praktyce, co nie oznacza i nie potwierdza, że harmonogram Zamawiającego narusza przepisy Pzp. Odwołujący nie przedstawił żadnej argumentacji, potwierdzającej,
‎że założenia przyjęte przez Zamawiającego są nierealne a wykonanie zamówienia
‎w określonym zakresie w przyjętym harmonogramie jest obiektywnie niemożliwe
‎czy nadmiernie utrudnione.

Nadto, termin 4 tygodni od dnia podpisania umowy dotyczy uruchomienia integratora danych do systemów Ministerstwa Nauki i Szkolnictwa Wyższego POL-on i PBN wraz
‎z zasileniem bazy danymi z tych systemów i nie wymaga posiadania w pełni gotowego rozwiązania technicznego przez wykonawców w tym zakresie. Zamawiający nie wymaga dostarczenia kompletnego, docelowego rozwiązania integracyjnego w terminie 4 tygodni, lecz jedynie uruchomienia mechanizmu umożliwiającego pobranie i wstępne przetworzenie danych. Przedmiotem tego etapu jest jedynie wycinek całej platformy, obejmujący konkretną funkcjonalność integracyjną, a nie kompleksowe wdrożenie całego rozwiązania, jak błędnie zarzuca Odwołujący.

Ponadto Zamawiający uzasadnił konieczność i potrzebę uruchomienie integratora
‎w terminie 4 tygodni od dnia zawarcia umowy wskazując, że uruchomienie integratora danych do systemów Ministerstwa Nauki i Szkolnictwa Wyższego POL-on i PBN wraz z zasileniem bazy danych z tych systemów w zakresie osiągnięć naukowych i danych o pracownikach
‎i doktorantach w terminie 4 tygodni od dnia zawarcia umowy jest niezbędne do realizacji celu całego wdrożenia.

Aktualnie Zamawiający stosuje kilka sposobów rejestracji osiągnięć naukowych
‎i danych o pracownikach, m.in. poprzez różne systemy własne Uczelni (ALEPH, Expertus)
‎lub poprzez wprowadzenie ich bezpośrednio do systemów Ministerstwa. W rezultacie danepozostałe w zasobach Zamawiającego są niekompletne, rozproszenie i zarejestrowane
‎w różnych systemach, a więc także w odmiennych formatach lub polach opisu. W efekcie Zamawiający ma poważny problem w gromadzeniu, archiwizowaniu i udostępnianiu całego dorobku naukowo-badawczego, co jest jednym z kluczowych zadań Zamawiającego jako uczelni publicznej, a także głównym celem realizowanego projektu.

Dlatego też migracja danych z wyżej wymienionych systemów Ministerialnych została wskazana jako jeden z pierwszych etapów całego wdrożenia – Zamawiający musi odzyskać te dane w pierwszej kolejności, tak aby na początku wdrożenia przewidzieć wszelkie trudności oraz działania związane z różnorodnością i odmienną proweniencją danych z systemów własnych i zewnętrznych. Dzięki temu działaniu wdrożenie będzie realizowane
‎z uwzględnieniem specyfiki danych, które mają być przetwarzane i udostępnianie
‎po uruchomieniu platformy informacji naukowo-badawczej (co powinno znaleźć swoje odzwierciedlenie także w koncepcji wdrożenia).

Kluczowym celem pierwszego etapu projektu jest bowiem możliwie szybkie zaewidencjonowanie pełnego dorobku naukowego Zamawiającego oraz pozyskanie danych
‎z rozproszonych źródeł, obejmujących zarówno:

1) systemy wewnętrzne uczelni wskazane w OPZ,

2) jak i systemy zewnętrzne, w szczególności POL-on oraz PBN.

Dane te stanowią podstawę do dalszych prac analitycznych i projektowych.
‎Ich wczesne pozyskanie umożliwia:

1) identyfikację rzeczywistej struktury danych,

2) wykrycie rozbieżności i błędów jakościowych,

3) ocenę kompletności informacji o dorobku naukowym,

4) określenie rzeczywistych potrzeb integracyjnych i transformacyjnych.

W konsekwencji integracja na wstępnym etapie projektu nie ma charakteru docelowego wdrożenia funkcjonalności, lecz służy wsparciu procesu analizy przedwdrożeniowej.
‎Bez wcześniejszego zasilenia systemu danymi z kluczowych źródeł, przeprowadzenie rzetelnej i kompletnej analizy byłoby istotnie utrudnione, a jej wyniki – obarczone wysokim ryzykiem błędu.

Tym samym przyjęta kolejność działań nie pozostaje w sprzeczności z zasadami realizacji projektów informatycznych, lecz odpowiada podejściu opartemu na pracy na rzeczywistych danych (data-drivenanalysis), które jest szczególnie uzasadnione w projektach dotyczących systemów informacji naukowej i ewaluacji dorobku. (…)

Nadmieniam, że będąca przedmiotem projektu platforma informacji naukowo-badawczej Uniwersytetu w dniu jej uruchomienia w środowisku produkcyjnym powinna być już napełniona danymi zarówno z baz własnych Uczelni (w tym dane z Repozytorium Uniwersytetu w Białymstoku – ponad 18 tys. publikacji, oraz dane z systemów Expertus
‎i ALEPH) jak i z systemów Ministerialnych. Natomiast projekt, w ramach którego odbywa się wdrożenie, wymaga, aby dane udostępnione na platformie przeszły odpowiednią kontrolę, obejmującą także ich weryfikację, ujednolicenie czy uzupełnienie o brakujące składowe opisu. Wiąże się to ze sprawdzeniem, na ile zaimportowane dane odpowiadają np. rzeczywistej liczbie publikacji zgromadzonych w dotychczasowych bazach własnych i systemach sprawozdawczych MNiSW, czy dane są kompletne oraz czy wymagają uzupełnienia. Weryfikacja dotyczy również treści związanych z tytułami grantów, numerami umów
‎i wysokościami dofinansowania.

Prace związane z weryfikacją poprawności zaimportowanych danych przewidziane zostały jako działania powdrożeniowe, realizowane przez pracowników Zamawiającego.
‎W związku z tym Zamawiający wskazuje, że działania związane z importem danych
‎z systemów Ministerialnych powinny odbyć się na początku wdrożenia, na pewno jednak nie mogą być przeniesione na ostatni etap wdrożenia. Wszelkie prace związane z importem danych do platformy powinny odbyć się jako integralny element wdrożenia tak, aby budowana platforma została odpowiednio dostosowana do zakresu tych danych oraz do różnych sposobów ich udostępniania na zewnątrz. Przesunięcie terminu importu na koniec wdrożenia wpłynęłoby negatywnie na realizację całego przedsięwzięcia w sytuacji, gdy system obsługujący platformę nie będzie odpowiednio przygotowany do przyjęcia danych z systemów zewnętrznych, a takie ryzyko istnieje, jeśli na początkowym etapie przedsięwzięcia Zamawiający nie będzie dysponować kompletem swoich danych naukowo-badawczych.

W konsekwencji, aby zapewnić możliwość dalszej realizacji zadań statutowych oraz prawidłowego funkcjonowania procesów wewnętrznych, Zamawiający musi w możliwie najkrótszym czasie uzyskać dostęp do tych danych poprzez ich ponowne pobranie z systemów ministerialnych.

Jednocześnie, podkreślić należy, że dane te nie służą Zamawiającemu wyłącznie na potrzeby ewaluacji, jak to próbuje wywieść Odwołujący.

W tym kontekście określenie 4 tygodniowego terminu na uruchomienie integratora nie ma charakteru arbitralnego czy naruszającego konkurencję, lecz wynika z rzeczywistych, obiektywnych potrzeb Zamawiającego.

W tych okolicznościach twierdzenie Odwołującego, jakoby realizacja powyższego elementu w przewidzianym przez Zamawiającego terminie wymagała posiadania w pełni gotowego, uprzednio stworzonego systemu, pozostaje nieuprawniona i nie znajduje potwierdzenia w realiach rynkowych i dokumentacji postępowania.

Izba wskazuje również, że zakresem tego zarzutu wskazanym w petium odwołania, Odwołujący objął wymóg przeprowadzenia prezentacji gotowego już rozwiązania informatycznego niezwłocznie po złożeniu ofert w postępowaniu. Jednakże w treści uzasadnienia dla powyższego zarzutu Odwołujący nie przedstawił żadnej argumentacji umożliwiającej Izbie odniesienie się do jego zasadności.

W odniesieniu do dowodu nr 10 Izba wskazuje na brak jego związku z zarzutem nr 5 i 6

Wobec powyższego zarzut podlegał oddaleniu.

Izba za niezasadny uznała również zarzut nr 6 dotyczący naruszenie art. 239 ust. 1 Pzp w zw. z art. 16 pkt 1 i 3 Pzp w zw. z pkt 3 („Funkcjonalności systemu związane
‎z ewaluacją oraz integracją z MNiSW (E)") załącznika nr 1B do SWZ - Oferowane funkcjonalności Platformy, poprzez ustanowienie kryteriów oceny ofert w zakresie funkcjonalności opcjonalnych podlegających punktacji w ramach kryterium oceny ofert
‎w sposób nieproporcjonalny oraz prowadzący do uprzywilejowania określonego rozwiązania informatycznego funkcjonującego na rynku oraz wykonawców oferujących to rozwiązanie,
‎a także ustanowienie kryteriów, które są pozbawione merytorycznego znaczenia
‎i uzasadnienia, co doprowadziło do uprzywilejowania lub wyeliminowania niektórych wykonawców lub produktów, a w konsekwencji stanowi naruszenie zasad zachowania uczciwej konkurencji oraz równego traktowania wykonawców oraz proporcjonalności.

Izba wskazuje, że całość argumentacji Odwołującego odnosi się wyłącznie do próby wskazania, że kwestionowane kryteria oceny ofert są obecnie nieuzasadnione oraz nieproporcjonalne, bowiem punktowane mechanizmy obliczenia wyników ewaluacji mogą
‎w niedługim czasie utracić aktualność.

W ocenie Izby argumentacja ta w żaden sposób nie potwierdza, że kryteria oceny ofert zostały określone w sposób naruszający przepisy Pzp, regulujące sposób i zasady ich ustanawiania. Natomiast przywołane przepisy prawne stanowiące rzekomą podstawę prawną naruszenia, nie odnoszą się do ustanowienia kryteriów oceny ofert.

Ponadto Izba podziela stanowisko Zamawiającego, zgodnie z którym w ramach kryterium jakościowego Zamawiający punktuje konkretne funkcjonalności, które mogą być elementem systemu. Zamawiający nie punktuje zupełnie nowych, wykreowanych przez siebie funkcjonalności, ale takie, które w tego rodzaju platformach mogą zostać uwzględnione, a co wpłynie na podwyższenie jakości zaoferowanej platformy.

Należy jednak podkreślić, że celem kryterium jakościowego oceny ofert jest premiowanie rozwiązań o wyższej jakości, lepszych od rozwiązań zaoferowanych przez innych wykonawców. Zamawiający w tym zakresie nie można przyjąć, że nie może przyznawać punktów za elementy przedmiotu zamówienia, które podwyższają jego jakość, gdyż nie wszyscy wykonawcy takie elementy oferują na rynku. Celem określania jakościowych kryteriów oceny ofert jest właśnie różnicowanie sytuacji wykonawców stosownie do jakości przedmiotu zamówienia (a zatem ze względy na cechy oferowanego produktu, a nie wykonawcy).

Dodać należy, że wprowadzenie kwestionowanego kryterium oceny ofert nie wyklucza możliwości złożenia oferty przez Odwołującego. Niespełnienie punktowanych funkcjonalności będzie skutkowało jedynie brakiem przyznania punktów w ramach kryteriów oceny ofert.

W tych okolicznościach zarzut nie mógł zostać uwzględniony.

Wobec powyższego należało orzec jak w sentencji.

O kosztach postępowania odwoławczego Izba orzekła na podstawie art. 557 i 575 ustawy Pzp w zw. z § 5 pkt 1), pkt 2) lit. a) i b) oraz § 8 ust. 2 pkt 1) rozporządzenia Prezesa Rady Ministrów w sprawie szczegółowych rodzajów kosztów postępowania odwoławczego, ich rozliczania oraz wysokości i sposobu pobierania wpisu od odwołania z dnia 30 grudnia 2020 r. (Dz.U.

z 2020 r. poz. 2437).  

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