Wyrok KIO 1646/26|KIO 1648/26
Krajowa Izba Odwoławcza · 18 maja 2026 · oddalone
Metryka orzeczenia
Przywołane przepisy
- art. 226 ust. 1 pkt 5 Pzp
- art. 218 ust. 2 Pzp
- art. 66 § 1 KC
- art. 8 ust. 1 Pzp
- art. 239 ust. 1 Pzp
- art. 220 ust. 3 Pzp
- art. 220 ust. 5 Pzp
- art. 97 ust. 5 Pzp
- art. 97 ust. 6 Pzp
- art. 226 ust. 1 pkt 12 Pzp
- art. 226 ust. 1 pkt 14 Pzp
- art. 16 pkt 1) - 3) Pzp
- art. 242 ust. 2 pkt 1 Pzp
- art. 220 ust. 4 Pzp
Zagadnienia
- oferta nieważna
- termin związania ofertą
- zamawiający
- odrzucenie oferty
- niezgodność z warunkami zamówienia
Treść orzeczenia
Sygn. akt: KIO 1646/26
KIO 1648/26
WYROK
Warszawa, 18 maja 2026 r.
Krajowa Izba Odwoławcza - w składzie:
Przewodniczący: Ernest Klauziński Protokolantka: Karina Karpińska
po rozpoznaniu na rozprawie odwołań wniesionych 10 kwietnia 2026 r. do Prezesa Krajowej Izby Odwoławczej:
A. przez odwołującego: Omnilogy spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie (KIO 1646/26), B. przez odwołującego: Kyndryl Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie (KIO 1648/26), w postępowaniu prowadzonym przez zamawiającego: Zakład Ubezpieczeń Społecznych z siedzibą w Warszawie
przy udziale uczestników po stronie zamawiającego:
1. Kyndryl Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie w sprawie KIO 1646/26,
2. Linux Polska spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie w sprawach KIO 1646/26 i KIO 1648/26, przy udziale uczestnika po stronie odwołującego:
1. Omnilogy spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie w sprawie KIO 1648/26,
orzeka:
1. Oddala odwołanie w sprawie o sygn. akt KIO 1646/26.
2. Odrzuca odwołanie w sprawie o sygn. akt KIO 1648/26 w zakresie zarzutu nr 1a, a w pozostałej części oddala odwołanie.
3. Kosztami postępowania w sprawie KIO 1646/26 obciąża odwołującego: Omnilogy spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie i:
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 tytułem wpisu od odwołania, 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) stanowiącą koszt wynagrodzenia pełnomocnika zamawiającego oraz 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) stanowiącą koszt wynagrodzenia pełnomocnika wykonawcy Kyndryl Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie;
3.2 zasądza od odwołującego Omnilogy spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie na rzecz zamawiającego kwotę 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) tytułem zwrotu kosztów postępowania odwoławczego i na rzecz wykonawcy Kyndryl Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie kwotę 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) tytułem zwrotu kosztów postępowania odwoławczego.
4. Kosztami postępowania w sprawie o sygn. akt KIO 1648/26 obciąża odwołującego:
Kyndryl Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie i:
4.1 zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr (piętnaście tysięcy złotych zero groszy) uiszczoną przez odwołującego tytułem wpisu od odwołania oraz 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) stanowiącą koszt wynagrodzenia pełnomocnika zamawiającego;
4.2 zasądza od odwołującego Kyndryl Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie na rzecz zamawiającego kwotę 3 600 zł 00 gr (trzy tysiące sześćset złotych zero groszy) tytułem zwrotu kosztów postępowania odwoławczego.
Na orzeczenie - w terminie 14 dni od dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu Okręgowego w Warszawie - Sądu Zamówień Publicznych.
Przewodniczący ……………………………………………..............
Sygn. akt: KIO 1646/26
KIO 1648/26
U z a s a d n i e n i e
Zakład Ubezpieczeń Społecznych z siedzibą w Warszawie (dalej: Zamawiający) prowadzi na podstawie przepisów ustawy z 11 września 2019 r. Prawo zamówień publicznych postępowanie w trybie przetargu nieograniczonego pn.: „Zakup oprogramowania do monitorowania aplikacji i infrastruktury Portalu PUE/eZUS wraz ze wsparciem”, Numer postępowania: 993200.271.149.2025-DZP (dalej: Postępowanie).
Ogłoszenie o zamówieniu zostało opublikowane 18 sierpnia 2025 r. w Dzienniku Urzędowym Unii Europejskiej, numer publikacji ogłoszenia: 535338-2025, numer wydania Dz.U. S: 156/2025.
KIO 1646/26
10 kwietnia 2026 r. wykonawca Omnilogy spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie (dalej: Odwołujący Omnilogy), wniósł odwołanie i zarzucił Zamawiającemu:
1. art. 226 ust. 1 pkt 5 w zw. z art. 218 ust. 2 Pzp oraz w zw. z art. 66 § 1 KC w zw. z art. 8 ust. 1 Pzp i w zw. z art. 239 ust. 1 Pzp przez zaniechanie odrzucenia oferty Linux i jej wybór jako najkorzystniejszej, mimo że jest ona niezgodna z warunkami zamówienia, w tym z wymaganiami Zamawiającego określonymi w dokumentach zamówienia odnoszącymi się do obowiązku identyfikacji oferowanego oprogramowania i jego producenta, ze względu na jej niejednoznaczność, co uniemożliwia ustalenie rzeczywistej treści oferty Linux w istotnym jej elemencie, jakim jest określenie przedmiotu świadczenia (tj. jaki konkretnie produkt jakiego producenta został zaoferowany), a skonkretyzowanie przedmiotu oferty musiałoby nastąpić dopiero po upływie terminu składania ofert w drodze niedozwolonych negocjacji pomiędzy Zamawiającym a Linux, które na gruncie art. 223 ust. 1 Pzp byłyby niedopuszczalne;
2. art. 239 ust. 1 w zw. z art. 242 ust. 2 pkt 1 Pzp przez przyznanie Ofercie Linux 15 punktów w kryterium „Pozycja w Gartner ®Magic Quadrant™ Observbility na rok 2025”, podczas gdy produkt wskazany przez Linux w ofercie nie znajduje się w Gartner ®Magic Quadrant™ Observbility na rok 2025;
3. art. 226 ust. 1 pkt 5 Pzp przez zaniechanie odrzucenia oferty Linux z uwagi na niezgodność treści oferty z warunkami zamówienia polegającą na zaoferowaniu produktu (rozwiązania) niespełniającego wymagań określonych w dokumentach zamówienia;
4. art. 226 ust. 1 pkt 12 w zw. z art. 220 ust. 3 - 5 i w zw. z art. 16 pkt 1) - 3) Pzp przez zaniechanie odrzucenia oferty wykonawcy Kyndryl, mimo że wykonawca ten nie wyraził skutecznie pisemnej zgody na przedłużenie terminu związania ofertą na okres wskazany przez Zamawiającego, tj. do 16 maja 2026 r., lecz wyłącznie do 30 kwietnia 2026 r., a więc na okres krótszy niż objęty wezwaniem Zamawiającego, w konsekwencji czego doszło do nierównego traktowania wykonawców w Postępowaniu, braku przejrzystości Postępowania i naruszenia zasady proporcjonalności, polegających na zaakceptowaniu wobec wykonawcy Kyndryl krótszego okresu związania ofertą i krótszego okresu zabezpieczenia wadialnego niż wymagany od pozostałych wykonawców, którzy złożyli oferty w Postępowaniu, podczas gdy pozostali wykonawcy przedłużyli termin związania ofertą oraz wadium zgodnie z wezwaniem Zamawiającego, tj. do 16 maja 2026 r.;
5. art. 226 ust. 1 pkt 14) w zw. z art. 220 ust. 5 i w zw. z art. 97 ust. 5 i 6 i w zw. z art. 16 pkt 1) -3) Pzp przez zaniechanie odrzucenia oferty wykonawcy Kyndryl, mimo że Kyndryl nie przedłużył ważności wadium ani nie wniósł nowego wadium na pełny wymagany przez Zamawiającego przedłużony okres związania ofertą do 16 maja 2026 r., ograniczając ochronę wadialną wyłącznie do 30 kwietnia 2026 r., a tym samym nie wykonał ustawowego warunku skutecznego przedłużenia terminu związania ofertą i nie wniósł wadium/wniósł w sposób nieprawidłowy/nie utrzymywał wadium nieprzerwanie do upływu terminu związania ofertą, w konsekwencji czego doszło do nierównego traktowania wykonawców w Postępowaniu, braku przejrzystości Postępowania i naruszenia zasady proporcjonalności, polegających na zaakceptowaniu wobec wykonawcy Kyndryl krótszego okresu związania ofertą i krótszego okresu zabezpieczenia wadialnego niż wymagany od pozostałych wykonawców, którzy złożyli oferty w Postępowaniu, podczas gdy pozostali wykonawcy przedłużyli termin związania ofertą oraz wadium zgodnie z wezwaniem Zamawiającego, tj. do 16 maja 2026 r.
Odwołujący wniósł o uwzględnienie odwołania i nakazanie Zamawiającemu:
1. unieważnienia czynności wyboru najkorzystniejszej oferty;
2. ponowienia czynności badania i oceny ofert;
3. odrzucenia oferty złożonej przez Linux oraz oferty złożonej przez Kyndryl;
4. powtórzenia czynności wyboru oferty najkorzystniejszej.
W uzasadnieniu zarzutów odwołania Odwołujący Omnilogy wskazał m.in.:
Zarzuty dotyczące oferty Linux
Zarzut 1 Zgodnie ze wzorem Formularza oferty (załącznik nr 1 do SWZ) wykonawcy zobowiązani byli (w pkt 4.1 pn. Formularz cenowy) określić przedmiot oferty, wskazując nazwę oferowanego oprogramowania i producenta oferowanego oprogramowania.
Dowód: - Wzór Formularza oferty - Załącznik nr 1 do SWZ – w dokumentacji Postępowania Jak wskazano powyżej w opisie staniu faktycznego, Linux złożył ofertę, w której oferowany przez siebie przedmiot określił w sposób następujący:
Oferta Linux dotyczy zatem oprogramowania określonego jako „Enterprise”, którego producent został skonkretyzowany jako „Elasticsearch”. Mając na uwadze powyższą treść oferty wykonawcy Linux Odwołujący wskazuje, że takie oznaczanie produktu nie pozwala na jego jednoznaczną identyfikację, a więc stanowi o braku skonkretyzowania przedmiotu świadczenia objętego ofertą. W zakresie wymagania wskazania producenta, należy zauważyć, że oznaczenie producenta jako „Elasticsearch” jest nieprawidłowe i wieloznaczne.
Powyższe wnika z tego, że „Elasticsearch” stanowi nazwę technologii (oprogramowania), a nie oznaczenie producenta . Wprawdzie wyrażenie „Elasticsearch” występuje w nazwach konkretnych spółek zależnych w grupie kapitałowej Elastic, np. Elasticsearch B.V., Elasticsearch Federal Inc., jednak podmiotem powszechnie identyfikowanym na rynku jako producent i dostawca komercyjnych rozwiązań opartych na technologii „Elasticsearch” jest spółka Elastic N.V. Poza tym posłużenie się nazwą „Elasticsearch” jako wskazaniem producenta prowadzi do niejednoznaczności, gdyż może odnosić się zarówno do oprogramowania rozwijanego przez Elastic (choć nie wiadomo jakiego konkretnie – o czym poniżej), jak i do jego różnych implementacji lub dystrybucji tworzonych przez inne podmioty.
Stąd wskazanie producenta jako „Elasticsearch” nie pozwala na jednoznaczne ustalenie, jaki podmiot odpowiada za oferowane rozwiązanie, ani – o czym szerzej poniżej - jakie konkretnie oprogramowanie zostało zaoferowane.
W zakresie wymagania wskazania nazwy oprogramowania, należy z kolei zauważyć, że zawarte w ofercie Linux określenie „Enterprise” także nie prowadzi do identyfikacji (konkretnego) oferowanego produktu. Określenie „Enterprise” jest to bowiem jedynie nazwa poziomu subskrypcji lub wariantu licencyjnego. Ma ono charakter ogólny i funkcjonuje wyłącznie jako element szerszego oznaczenia produktu. Należy przy tym podkreślić, że nazwa „Enterprise” stosowana przez różnych producentów (np. Windows 11 Enterprise to edycja systemu operacyjnego firmy Microsoft). Użycie tego wyrażenia bez wskazania pełnej nazwy rozwiązania uniemożliwia ustalenie, jakie oprogramowanie zostało faktycznie zaoferowane.
W konsekwencji, przy tak oznaczonym przedmiocie oferty, jaki występuje w ofercie Linux, brak jest jakichkolwiek danych pozwalających ustalić, jakie dokładnie oprogramowanie zostało zaoferowane, w tym ustalenie jego funkcjonalności, modelu licencjonowania czy zakresu wsparcia, itp., a więc także to, czy zaoferowano rozwiązanie zgodne z warunkami zamówienia. Powyższe prowadzi do konstatacji, że oferta Linux jest niejednoznaczna w zakresie określenia jej przedmiotu, a tym samym nie jest stanowczym oświadczeniem woli zaoferowania konkretnego przedmiotu świadczenia. Odwołujący podnosi więc, że wbrew wymaganiom dokumentów zamówienia, zgodnie z którymi wykonawcy mieli obowiązek wskazania producenta oferowanego oprogramowania oraz nazwę oferowanego oprogramowania, Linux nie dokonał w Formularzu ofertowym jednoznacznego oznaczenia w ofercie producenta i nazwy oprogramowania, tzn. nie skonkretyzował przedmiotu oferowanego świadczenia. Oznaczenie w ofercie Linux producenta jako „Elasticserch” i oprogramowania jako „Enterprise” nie identyfikuje jednoznacznie oferowanego rozwiązania i uzasadnia zarzut niezgodności treści oferty z wymaganiami identyfikacyjnymi.
Już tylko to przesądza o niegodności treści oferty Linux z warunkami zamówienia i stanowić powinno dla Zamawiającego podstawę do odrzucenia oferty Linux (art. 226 ust 1 pkt 5 Pzp). Zaniechanie odrzucenia tej oferty w opisanych okolicznościach faktycznych stanowi naruszenie Pzp. Podnieść należy, że złożenie oferty zgodnej z warunkami zamówienia oznacza złożenie oświadczenia woli o charakterze jednoznacznym, obejmującego zobowiązanie do wykonania skonkretyzowanego i możliwego do identyfikacji świadczenia.
Oferta jako podstawowy element postępowania o udzielenie zamówienia publicznego, musi umożliwiać zamawiającemu ustalenie jej rzeczywistej treści, w szczególności w zakresie oferowanego przedmiotu zamówienia. Wymóg ten wynika zarówno z zasady przejrzystości i równego traktowania wykonawców (art. 16 Pzp), jak i z obowiązku jednoznacznego opisu oraz zgodności treści oferty z warunkami zamówienia. Nie można więc uznać, że doszło do skutecznego złożenia jednej oferty w sytuacji, gdy z jej treści nie wynika, jakie konkretnie świadczenie wykonawca oferuje. Oferta, której elementy przedmiotowo istotne pozostają nieokreślone lub niejednoznaczne, nie pozwala bowiem na ustalenie zakresu zobowiązania wykonawcy, a tym samym nie może stanowić podstawy do jej oceny i porównania z innymi ofertami.
Zgodnie z art. 66 § 1 Kodeksu cywilnego (w zw. z art. 8 ust. 1 Pzp): „oświadczenie drugiej stronie woli zawarcia umowy stanowi ofertę, jeżeli określa istotne postanowienia tej umowy ”.
Przedmiot świadczenia niewątpliwie stanowi istotne postanowienie przyszłej umowy – w szczególności, gdy zamawiający żąda podania w ofercie producenta i nazwy oferowanego produktu (oprogramowania). Odwołujący podkreśla także, że okoliczności sprawy świadczą jednoznacznie, że nie można stwierdzić, jaki konkretny produkt został Zamawiającemu zaoferowany. Jednocześnie dookreślenie tego wymagałoby ustalenia przez Zamawiającego z Linux, jaka jest treść oferty w jej kluczowym elemencie, czyli co jest jej przedmiotem (jakie oprogramowanie jakiego producenta). Jednakże konkretyzacja w tym zakresie powinna nastąpić już na etapie składania ofert – w formularzu cenowym, a nie dopiero po upływie terminu składnia ofert. Jednocześnie konkretyzacja taka po upływie terminu składnia ofert prowadziłoby do niedozwolonych negocjacji pomiędzy Zamawiającym a Linux dotyczących złożonej oferty (co zostało zaoferowane – co dostarczyć Zamawiającemu) oraz musiałoby prowadzić do zmiany treści tej oferty – przez skonkretyzowanie jej treści w zakresie określenia producenta i nazwy oprogramowania.
Takie działania są zaś wprost zakazane przepisem art. 223 ust. 1 zdanie 2 Pzp, który stanowi: „W toku badania i oceny ofert zamawiający może żądać od wykonawców wyjaśnień dotyczących treści złożonych ofert oraz przedmiotowych środków dowodowych lub innych składanych dokumentów lub oświadczeń. Niedopuszczalne jest prowadzenie między zamawiającym a wykonawcą negocjacji dotyczących złożonej oferty oraz, z uwzględnieniem ust. 2 i art. 187, dokonywanie jakiejkolwiek zmiany w jej treści”. W związku z powyższym ofertę wykonawcy Linux należy uznać za niezgodną z wymaganiami SWZ w zakresie dotyczącym obowiązku wskazania konkretnego oferowanego oprogramowania.
Jednocześnie brak jednoznacznego określenia przedmiotu świadczenia oznacza, że oferta nie spełnia wymogu stanowczości i kompletności oświadczenia woli, przez co nie może zostać uznana za skuteczną ofertę w rozumieniu Pzp i KC.
W związku z powyższym oferta Linux powinna zostać odrzucona na podstawie art. 226 ust. 1 pkt 5 w zw. z art. 218 ust. 2 Pzp oraz w zw. z art. 66 § 1 KC w zw. z art. 8 ust. 1 ustawy jako niezgodna z wymaganiami Zamawiającego określonymi w dokumentach zamówienia.
Zarzut 2 Jak wskazano wyżej, oferta Linux dotyczy oprogramowania określonego jako „Enterprise”, którego producent został wskazany jako „Elasticsearch”.
Tak oznaczony produkt, tak oznaczonego producenta, nie wstępuje w Gartner ®Magic Quadrant™ Observbility na rok 2025:
W raporcie Gartner Magic Quadrant for Observability Platforms 2025 oceniane jest rozwiązanie nazywane Elastic Observability: „Elastic został uznany za lidera w Gartner Magic Quadrant 2025 dla platform obserwacji po raz drugi z rzędu! Elastic ma zaszczyt ponownie zostać uznanym za Lidera w Gartner® Magic Quadrant™ 2025 dla platform obserwacji. The Magic Quadrant przeanalizował 20 dostawców pod kątem kryteriów oceny, aby pomóc przedsiębiorstwom w procesie selekcji. Elastic został uznany za lidera ze względu na zdolność realizacji i kompletność wizji zarówno w 2024, jak i 2025 roku”.
Wobec powyższego ofercie Linux nie powinno zostać przyznane żadne punkty w kryterium oceny ofert - „Pozycja w Gartner ®Magic Quadrant™ Observbility na rok 2025”.
Stąd zarzut naruszenia art. 239 ust. 1 w zw. z art. 242 ust. 2 pkt 1 Pzp jest w pełni zasadny.
Zarzut 3 Zgodnie z art. 226 ust. 1 pkt 5 Pzp zamawiający ma obwiązek odrzucić ofertę, której treść jest niezgodna z warunkami zamówienia. Warunki zamówienia należy rozumieć zgodnie z definicją wyrażoną w art. 7 pkt 29 Pzp, który stanowi, że przez warunki zamówienia należy rozumieć warunki, które dotyczą zamówienia lub postępowania o udzielenie zamówienia, wynikające w szczególności z opisu przedmiotu zamówienia , wymagań związanych z realizacją zamówienia , kryteriów oceny ofert, wymagań proceduralnych lub projektowanych postanowień umowy w sprawie zamówienia publicznego. Linux nie skonkretyzował przedmiotu oferty, a zatem nie można na podstawie jej treści ustalić jakie konkretnie oprogramowanie oferta obejmie, jednakże zakładając, że zamiarem Linux było złożenie oferty na jakieś rozwiązanie rodziny Elastic, Odwołujący podnosi, że żadne z nich nie spełnia poniższych wymagań opisu przedmiotu zamówienia:
A. wymaganie 27.14 . - prezentować drzewo wywołania kodu Java, .NET i PHP w ramach ścieżki wykonania – do poziomu nazwy wywoływanej metody, zarówno dla wątków wywoływanych synchronicznie jak i asynchronicznie. Zbliżona funkcjonalność realizowana jest w produktach Elastic, jednak ta aplikacja śledzi żądania http w ramach ścieżki wykonania end-to-end jako transakcje/spany na poziomie framework'a programistycznego wyłącznie dla wybranych fragmentów drzewa (HTTP requests, bazy danych), ale nie daje wglądu w każde indywidualne wywołanie metody/klasy w drzewie wykonania kodu.
B. wymaganie 27.17. - umożliwiać prezentację wartości parametrów metody JAVA, .NET lub PHP, nagłówków http/s, parametrów zapytań http/s. Przechwytywanie nagłówków i parametrów zapytań http jest dostępne w produktach Elastic, jednak brak jest możliwości przechwytywania wartości parametrów metod. Aby uzyskać funkcjonalność zbliżoną do wymaganej Zamawiający (nie dostawca) musiałby wykonać zmiany w kodzie własnych aplikacji, ponosząc dodatkowy nakład finansowy przez zlecenie zewnętrznych prac programistycznych podmiotom odpowiedzialnym za rozwój oprogramowania przeznaczonego do monitorowania.
C. wymaganie 27.19. - monitorować serwery webowe Apache, Nginx oraz IIS w zakresie wprowadzanych przez nie opóźnień w czasie realizacji transakcji webowej oraz błędów pojawiających się na tychże serwerach, a w szczególności monitoring musi pokazywać wpływ poszczególnych modułów działających na serwerach WWW na czasy wykonania transakcji. Produkty Elastic mogą monitorować opóźnienia na poziomie Apache/Nginx/IIS przez metryki oraz trace-y dla aplikacji działającej za serwerem. Jednak wpływ poszczególnych modułów na czas transakcji nie jest automatycznie raportowany. Nawet zastosowanie Opentelemetry, które Zamawiający (nie dostawca) musiałby zaimplementować po stronie serwerów webowych nie udostępnia możliwości pokazywania wpływu poszczególnych modułów na czasy wykonywania transakcji.
D. wymaganie 27.23. - umożliwiać wykonywanie zrzutów pamięci ze sterty Java oraz jej analizę pod względem wycieków i optymalizacji. Zrzut pamięci nie może zatrzymywać działającej aplikacji, Produkty Elastic nie posiadają funkcjonalności zbierania szczegółowych informacji z pracy GC - typu dokładna alokacja pamięci, nie posiada również funkcjonalności zrzutu danych z alokacji pamięci, w szczególności nie zatrzymując procesu JVM.
E. wymaganie 27.35. - umożliwiać monitoring połączeń między poszczególnymi serwerami i udostępniać mapę połączeń w formie graficznej. W przypadku wykrycia anomalii skutkującej wygenerowaniem alertu serwer musi zostać oznaczony na wizualizacji w sposób jednoznacznie wskazujący na wystąpienie problemu .
W produktach Elastic wizualizacja powiązań między usługami możliwa jest dzięki funkcji Service Map, jednak brak możliwości wizualizacji połączeń pomiędzy elementami infrastrukturalnymi. Implementacja wizualizacji połączeń przez dobudowane przez Dostawcę funkcjonalności wymagałaby dostarczenie przez Zamawiającego do platformy danych z ruchu sieciowego, co nie jest przedmiotem Postępowania .
F. wymaganie 27.36 . - umożliwiać monitoring połączeń między poszczególnymi procesami uruchomionymi na serwerach objętych monitoringiem i udostępniać mapę połączeń w formie graficznej. W przypadku wykrycia anomalii skutkującej wygenerowaniem alertu proces musi zostać oznaczony na wizualizacji w sposób jednoznacznie wskazujący na wystąpienie problemu, W produktach Elastic wizualizacja powiązań między usługami możliwa jest dzięki funkcji Service Map, jednak brak możliwości wizualizacji połączeń pomiędzy procesami uruchomionymi na serwerach, w szczególności gdy komunikacja między procesami następuje w ramach tego samego serwera.
G. wymaganie 27.44. - w przypadku wykrycia problemu system musi automatycznie wskazać najbardziej prawdopodobną przyczynę ̨wystąpienia problemu . Produkty Elastic nie wykrywają przyczyny problemu, a bazują na mechanizmie korelacji czasowej usług i elementów, na których coś się dzieje: https://www.elastic.co/docs/solutions/observability/apm/findtransaction-latency-failure-correlations.
W przypadku zastosowania dodatkowych (nie będących częścią oferty Elastic) silników analizujących opartych jedynie o duże model językowe, zakres danych oraz oparcie o korelację czasową zdarzeń skutkuje zjawiskiem halucynacji przy potencjalnym wnioskowaniu o najbardziej prawdopodobnej przyczynie problemu.
H. wymaganie 27.56. - wykrywanie podatności nie może wymagać instalowania dodatkowego oprogramowania, poza tym, które wchodzi w skład platformy do monitorowania . Zgodnie z dokumentacją w produktach Elastic podatności mogą być zbierane dwojako albo przez zewnętrzne integracje z programami trzecimi, albo przez CloudNativeVulnerabilityManagement w skrócie CNVM. Oznacza to ograniczone wsparcie wyłącznie dla jednego typu usługi chmury publicznej AWS nie spełniając wymagania Zamawiającego.
I. wymaganie 27.58 . - dla wykrytych podatności klasyfikować je wg CVSS wraz z uwzględnieniem informacji o ekspozycji na atak z publicznego internetu oraz dostępu do danych; W produktach Elastic CNVM wskazuje wektor ataku, ale nie wskazuje czy dane są narażone na dostęp z publicznego internetu i czy zasoby są wystawione na zewnątrz i są podatne na atak z publiczego internetu. Oznacza to ograniczone wsparcie wyłącznie dla jednego typu usługi chmury publicznej AWS nie spełniając wymagania Zamawiającego.
J. wymaganie 27.69. - zapewniać monitorowanie pracy użytkownika końcowego (user experience) bez konieczności instalacji dodatkowych komponentów po stronie użytkownika i wykonywania zmian konfiguracji, serwerów WWW lub aplikacyjnych; zmiana konfiguracji czy też włączenie/wyłączenie monitorowania zachowań użytkownika musi odbywać się z konsoli narzędzia, bez potrzeby restartu serwerów monitorowanego środowiska. W produktach Elastic monitorowanie pracy użytkownika końcowego wymaga przekonfigurowania niektórych elementów wraz z restartem. Odwołujący wskazuje, że spełnienie wymagania w zakresie ww. funkcjonalności w Elastic wymaga zbudowania ponownie aplikacji lub modyfikacji w kodzie HTML.
K. wymaganie 27.71. - umożliwiać dostarczanie informacji nt. charakteru każdej interakcji w systemie dla każdego pojedynczego użytkownika ze wskazaniem tzw. landing pages, bounces, wpływ „third party” czy ładowania asynchroniczne AJAX. Produkty Elastic zbierają i analizują tylko część z wymaganych informacji, brak np. bounces.
Mając na uwadze powyższe nie ulega wątpliwości, że oferta Linux powinna podlegać odrzuceniu na podstawie art. 226 ust. 1 pkt 5 Pzp.
Zarzuty dotyczące oferty wykonawcy Kyndryl
Zarzut 4 Uwzględniając zmiany dokumentów zamówienia, finalny termin składania ofert został ustalony na 18 grudnia 2025 r. na g. 12:00. Mając na względzie powyższe, pierwotny termin związania ofertą upływał z dniem 17 marca 2026 r. Dowód: Informacja o zmianie terminu składania i otwarcia ofert praz terminu związania ofertą z 02 grudnia 2025 r. (plik pn. „odpowiedzi_na_pytania zest V.pdf”. – w dokumentacji Postępowania Ogłoszenie o zmianie ogłoszenia o zamówieniu nr 803861-2025 – w dokumentacji Postępowania Jednocześnie, zgodnie z pkt 3.1. SWZ wykonawca składający ofertę w Postępowaniu zobowiązany był wnieść wadium w wysokości 200 000,00 zł i utrzymywać je nieprzerwanie do upływu terminu związania ofertą (por. pkt 3.3.1. SWZ). Niewniesienie wadium, wniesienie w sposób nieprawidłowy, nieutrzymywanie wadium nieprzerwanie do upływu terminu związania ofertą lub złożenie wniosku o zwrot wadium w przypadku, o którym mowa w pkt 3.4.2.3 SWZ, skutkować miało odrzuceniem oferty Wykonawcy (pkt 3.3.8. SWZ). Jednocześnie za przepisem art. 97 ust. 6 Pzp, Zamawiający wskazał w pkt 3.3.9. SWZ, że „ Przedłużenie terminu związania ofertą jest dopuszczalne tylko z jednoczesnym przedłużeniem okresu ważności wadium albo, jeżeli nie jest to możliwe, z wniesieniem nowego wadium na przedłużony okres związania ofertą ”.
W Postępowaniu oferty złożyło trzech wykonawców: Odwołujący Omnilogy, który wniósł wadium w formie gwarancji bankowej ważnej do 17 marca 2026 r. Wykonawca Linux, który wniósł wadium w formie pieniężnej (potwierdzenie przelewu z 16 grudnia 2025 r. załączono do oferty) Wykonawca Kyndryl, który wniósł wadium w formie gwarancji bankowej nr DOK5160GWB25SS z 6 listopada 2025 r. ważnej do 30 kwietnia 2026 r. Dowód: gwarancje wadialne Omnilogy i Kyndryl i potwierdzenie wniesienia wadium w formie pieniężnej przez Linux – w dokumentacji Postępowania Pismem z 13 marca 2026 r. Zamawiający zwrócił się do wykonawców, którzy złożyli w Postępowaniu oferty, z wnioskiem o przedłużenie terminu związania ofertą oraz okresu ważności wadium, wskazując w ww. piśmie: „Zamawiający, stosownie do postanowień art. 220 ust. 3 ustawy Prawo zamówień publicznych (t.j. Dz. U. 2024 r. poz. 1320 ze zm.)., dalej „ustawa Pzp”, zwraca się z prośbą o wyrażenie zgody na przedłużenie terminu związania ofertą o 60 dni tj. do 16 maja 2026 r. Obecny termin związania ofertą upływa 17 marca 2026 r. Przedłużenie terminu związania ofertą, wymaga złożenia przez Wykonawcę pisemnego oświadczenia o wyrażeniu zgody na przedłużenie terminu związania ofertą. Przekazanie zgody na przedłużenie terminu związania ofertą, podpisane przez osobę uprawnioną do reprezentowania Wykonawcy, winno nastąpić do upływu obecnego terminu związania ofertą, tj. do 17 marca 2026 r., z uwzględnieniem postanowień pkt. 1.5. specyfikacji warunków zamówienia w przedmiotowym postępowaniu (dalej: „SWZ”).
Zgodnie z art. 220 ust. 5 Pzp przedłużenie terminu związania ofertą dopuszczalne jest tylko wraz z przedłużeniem okresu ważności wadium, albo jeżeli nie jest to możliwe z wniesieniem nowego wadium na przedłużony okres związania ofertą.
Przedłużenie okresu ważności wadium lub wniesienie nowego wadium, obejmującego wydłużony termin związania ofertą, w kwocie 200 000,00 zł w jednej z form wskazanych w pkt. 3.2. SWZ, winno nastąpić zgodnie z wymogami określonymi w pkt. 3.3. SWZ, do upływu obecnego terminu związania ofertą, tj. do 17 marca 2026 r.”.
Dowód: wezwanie do przedłużenia terminu związania ofertą oraz okresu ważności wadium z 13 marca 2026 r. – w dokumentacji Postępowania W odpowiedzi na ww. wezwanie wykonawca Omnilogy złożył 16 marca 2026 r. oświadczenie o wyrażeniu zgody na przedłużenie terminu związania ofertą o 60 dni, tj. do 16 maja 2026 r., załączając jednocześnie do ww. oświadczenia aneks do gwarancji wadialnej złożonej wraz z ofertą, przedłużający ważność wadium do 16 maja 2026 r. (ANEKS NR 5 DO GWARANCJI BANKOWEJ NR DOK4280GWB25MV z 16 września 2025 r.) Dowód: pismo Omnilogy z 16 marca 2026 r. w sprawie przedłużenia terminu związania ofertą i wadium – w dokumentacji Postępowania Odpowiedzi na ww. wezwanie udzielił również Wykonawca Linux, który 13 marca 206 r. złożył oświadczenie o wyrażeniu zgody na przedłużenie terminu związania ofertą o 60 dni, tj. do 16 maja 2026 r. i jednocześnie potwierdził przedłużenie okresu ważności wadium w kwocie 200.000,00 zł do 16 maja 2026 r. Dowód: pismo Linux z 13 marca 2026 r. w sprawie przedłużenia terminu związania ofertą i wadium – w dokumentacji Postępowania Z kolei Wykonawca Kyndryl 16 marca 2026 r. przekazał Zamawiającemu pismo o następującej treści: „ W odpowiedzi na Państwa pismo z 13 marca 2026 roku, zawierające prośbę o wyrażenie zgody na przedłużenie terminu związania ofertą o 60 dni tj. do 16 maja 2026 r. uprzejmie informuję, że wyrażamy zgodę na przedłużenie ważności naszej oferty do 30 kwietnia 2026 roku tj. do końca okresu ważności aktualnego wadium. Na przedłużenie terminu wadium w formie aneksu do gwarancji bankowej potrzebne nam jest około 14 dni.
W tym czasie zostanie do Państwa dostarczone nowe wadium z terminem ważności 16 maja 2026 roku oraz zgoda na przedłużenie ważności oferty na ten okres”.
Dowód: pismo Kyndryl z 16 marca 2026 r. w sprawie przedłużenia terminu związania ofertą do 30 kwietnia 2026 r. – w dokumentacji Postępowania 31 marca 2026 r. Zamawiający dokonał wyboru jako najkorzystniejszej oferty wykonawcy Linux, wskazując w pkt III Informacji o wyborze oferty najkorzystniejszej, że: „ Zamawiający informuje, że w przedmiotowym postępowaniu nie dokonał odrzucenia oferty”.
Mając na względzie powyższe, Odwołujący wskazuje, że w jego ocenie czynność badania i oceny ofert została dokonana wadliwie, a Zamawiający bezzasadnie zaniechał odrzucenia oferty wykonawcy Kyndryl na podstawie art. 226 ust. 1 pkt 12 Pzp, jak również art. 226 ust. 1 pkt 14 Pzp. Zgodnie z treścią Pzp w przypadku, gdy wybór najkorzystniejszej oferty nie nastąpi przed upływem terminu związania ofertą, zamawiający przed upływem terminu związania ofertą, zwraca się jednokrotnie do wykonawców o wyrażenie zgody na przedłużenie tego terminu o wskazywany przez niego okres, nie dłuższy niż 60 dni. Przedłużenie terminu związania ofertą wymaga złożenia przez wykonawcę pisemnego oświadczenia o wyrażeniu zgody na przedłużenie terminu związania ofertą. Jednocześnie art. 220 ust. 5 Pzp stanowi, że „W przypadku, gdy zamawiający żąda wniesienia wadium, przedłużenie terminu związania ofertą, o którym mowa w ust. 2, następuje wraz z przedłużeniem okresu ważności wadium albo, jeżeli nie jest to możliwe, z wniesieniem nowego wadium na przedłużony okres związania ofertą”, co koresponduje z art. 97 ust. 5 i 6 Pzp, wedle których: wadium wnosi się przed upływem terminu składania ofert i utrzymuje nieprzerwanie do upływu terminu związania ofertą, przedłużenie terminu związania ofertą jest dopuszczalne tylko z jednoczesnym przedłużeniem okresu ważności wadium albo, jeżeli nie jest to możliwe, z wniesieniem nowego wadium na przedłużony okres związania ofertą, Mając na względzie powyższe regulacje, do skutecznego, tj. zgodnego z przepisami Pzp, przedłużenia terminu związania ofertą konieczne jest kumulatywne spełnienie kilku wymogów:
a) po pierwsze wykonawca zobowiązany jest złożyć oświadczenie woli w przedmiocie zgody na przedłużeniu terminu związania ofertą o wskazany przez Zamawiającego okres (co wynika wprost z art. 220 ust. 3 Pzp),
b) po drugie, oświadczenie to powinno być z zachowaniem właściwej formy, a więc pisemnie (przy czym pisemność powinna być rozumiana przez pryzmat definicji legalnej z art. 7 pkt 16 Pzp) i przez osobę do tego uprawnioną,
c) po trzecie, oświadczenie w przedmiocie zgody na przedłużenie terminu związania ofertą o wskazany przez Zamawiającego okres musi być złożone przed upływem pierwotnego terminu związania ofertą, po czwarte, w przypadku, gdy zamawiający wymagał zabezpieczenia oferty wadium, przedłużenie terminu związania ofertą musi nastąpić z jednoczesnym przedłużeniem okresu ważności wadium albo, jeżeli nie jest to możliwe, z wniesieniem nowego wadium na przedłużony okres związania ofertą.
Brak któregokolwiek z tych elementów oznacza brak skutecznej zgody w rozumieniu Pzp, skutkujący ziszczeniem się przesłanki odrzucenia oferty wskazanej w art. 226 ust. 1 pkt 12 Pzp. Przepis ten nie może być przy tym rozumiany stricte formalistycznie jako regulacja wymagająca „jakiegokolwiek pisma z jakąkolwiek zgodą”. Taka interpretacja niweczyłaby sens art. 220 ust. 3 Pzp.
Wyrażona przez Kyndryl zgoda na przedłużenie terminu związania ofertą nie objęła pełnego okresu wskazanego we wniosku Zamawiającego. Wykonawca Kyndryl oświadczył bowiem, że wyraża zgodę na przedłużenie terminu związania ofertą jedynie do 30 kwietnia 2026 r., nie zaś do 16 maja 2026 r., o co wnioskował Zamawiający. Jednocześnie - mimo, że Zamawiający wymagał w postępowaniu zabezpieczenia oferty wadium, przedłużenie terminu związania ofertą nie nastąpiło o wymagany przez Zamawiającego okres z jednoczesnym przedłużeniem na ten okres albo – jeżeli nie jest to możliwe, z wniesieniem na ten przedłużony okres związania ofertą - nowego wadium na przedłużony okres związania ofertą, zgodnie z żądaniem Zamawiającego. Skoro więc zgoda nie została wyrażona skutecznie, ziściła się przesłanka odrzucenia oferty, o której mowa w art. 226 ust. 1 pkt 12 Pzp. Prawidłowość i skuteczność wezwania do przedłużenia terminu związania oferta i wadium Nie ulega jednocześnie wątpliwości, że wniosek Zamawiającego o przedłużenie terminu związania ofertą i przedłużenie/wniesienie nowego wadium odpowiadał dyspozycji art. 220 ust. 3 i 4 Pzp. Okres wskazany w żądaniu wynosił 60 dni, a więc tyle, ile maksymalnie dopuszcza przepis. Skoro wezwanie Zamawiającego było w pełni skuteczne i zgodne z prawem, to zgoda wyrażona na inny okres przedłużenia terminu związania ofertą niż wynikający z wniosku o wyrażenie zgody wystosowanego przez Zamawiającego, nie może być w żadnym razie poczytana jako skuteczne i zgodne z przepisami Pzp przedłużenie terminu związania ofertą.
Zamawiający zwraca się o wyrażenie zgody na przedłużenie terminu związania ofertą o określony w wezwaniu okres . Przepis art. 220 ust. 3 Pzp nie stanowi o zwróceniu się o wyrażenie „ogólnej zgody” na przedłużenie terminu związania ofertą. Jednocześnie prawo i obowiązek określenia tego okresu przedłużenia spoczywa tylko na zamawiającym.
To zamawiający ustala arbitralnie długość przedłużenia i jest w tym zakresie ograniczony jedynie 60-dniowym okresem wynikającym z art. 220 ust. 3 Pzp. W sytuacji więc, gdy Zamawiający, wypełniając dyspozycję przepisu art. 220 ust. 3 Pzp, zażąda wyrażenia zgody na przedłużenie terminu związania oferta o okres 60 dni (tu: do 16 maja 2026 r.), to wykonawca, aby nie narazić się na sankcję określoną w art. 226 ust. 1 pkt 12) Pzp, zobowiązany jest do wyrażenia ww. zgody na przedłużenie terminu związania ofertą właśnie o ten konkretny, sprecyzowany w żądaniu Zamawiającego, okres.
Wykonawca nie został uprawniony do wyrażenia „jakiejkolwiek”, czy „ogólnej” zgody na przedłużenie terminu związania ofertą, ale jego oświadczenie o zgodzie na przedłużenie terminu musi być zgodne z żądaniem Zamawiającego w zakresie wymaganego terminu przedłużenia terminu związania ofertą. Co należy podkreślić, przepisy nie przyznają wykonawcom prawa do samodzielnego decydowania o okresie przedłużenia terminu związania ofertą. Wykonawca nie może dowolnie modyfikować i skracać tego okresu , ustalając sobie samowolnie zależny tylko od niego „harmonogram przedłużeń”. Powyższe chroni przejrzystość postępowania. Inaczej każdy wykonawca mógłby jednostronnie kształtować sobie własny okres związania ofertą, co niweczyłoby sens jednokrotnego wezwania i jednolitych warunków postępowania dla wszystkich wykonawców ubiegających się o dane zamówienie . Powyższe jest zresztą logiczne, bowiem okres związania ofertą stanowi uciążliwość dla wykonawcy. Wykonawca w okresie tym musi, nie zaś może , zawrzeć umowę z zamawiającym. Powyższe ma szczególne znaczenie w sytuacji, gdy Zamawiający, tak jak to miało miejsce w niniejszym Postępowaniu, żąda zabezpieczenia oferty wadium, które ulega przepadkowi, w przypadku, gdy wykonawca uchyla się od zawarcia umowy z zamawiającym, bądź gdy wykonawca nie wnosi zabezpieczenia należytego wykonania umowy (które w ramach niniejszego Postępowania było wymagane – vide: pkt 8 SWZ). Upływ terminu związania ofertą i skorelowanego z nim obowiązku utrzymywania zabezpieczenia wadialnego powoduje więc, że wykonawca nie ma obowiązku zawarcia umowy, a co za tym idzie - nie ponosi negatywnych konsekwencji odmowy jej zawarcia. Co należy podkreślić, w okresie związania ofertą zabezpieczoną wadium zamawiający ma realnie najsilniejsze instrumenty wobec wykonawcy: może przyjąć ofertę przez jej wybór, oczekiwać zawarcia umowy na warunkach wskazanych w ofercie, a w razie odmowy lub uchylania się – przy spełnieniu ustawowych przesłanek – zatrzymać wadium oraz przejść do trybu z art. 263 Pzp. Celem zachowania tych uprawnień i zabezpieczenia swoich interesów, Zamawiający może jeden raz wystąpić o wyrażenie zgody na przedłużenie terminu związania ofertą o wskazany wprost w wezwaniu, nie dłuższy niż 60 dni, okres.
Tym samym ustawodawca przyznał Zamawiającemu jednokrotne i ściśle ograniczone czasowo uprawnienie do zagwarantowania sobie możliwości skorzystania z ww. instrumentów. W przypadku braku zabezpieczenia przez wykonawcę możliwości skorzystania przez Zamawiającego z ww. instrumentów, oferta wykonawcy podlega odrzuceniu (art. 226 ust. 1 pkt 12) i 14) Pzp). Tym samym wykonawca, który nie godzi na ww. uciążliwość, musi liczyć się ze skutkiem w postaci odrzucenia oferty. Dopiero w sytuacji, gdy termin związania ofertą – w przypadku jego przedłużenia w trybie art. 220 ust. 3 i 4 Pzp – przedłużony termin związania ofertą, upłynął przed wyborem oferty najkorzystniejszej, zamawiający zobowiązany jest wezwać wykonawcę, którego oferta otrzymała najwyższą ocenę, do wyrażenia, w wyznaczonym przez zamawiającego terminie, pisemnej zgody na wybór jego oferty (art. 252 ust. 2 Pzp). W terminie związania ofertą (również przedłużonym), wykonawca jest nią więc po prostu związany, a zamawiający przez wybór przyjmuje ofertę, co obliguje wykonawcę do zawarcia umowy na warunkach w niej wskazanych i naraża go na ryzyko utraty wadium, w przypadku uchylania się od zawarcia ww. umowy, bądź niewniesienia zabezpieczenia należytego jej wykonania. Po upływie terminu związania ofertą z kolei - instrumentarium zamawiającego prowadzące do zawarcia umowy ogranicza się jedynie do „zapytania” wykonawcy, czy zgodzi się, by wybrać jego ofertę, mimo, że nie jest on już nią związany. Wykonawca może przy tym takiej zgody odmówić bez żadnych konsekwencji, w szczególności zaś nie jest w takiej sytuacji narażony na zatrzymanie wadium. Biorąc pod uwagę powyższe, mylne byłoby więc twierdzenie, że wyrażenie zgody na przedłużenie terminu związania ofertą na okres krótszy niż wskazany we wniosku Zamawiającego nie ma realnego znaczenia dla losów postępowania, ponieważ zamawiający może wybrać ofertę takiego wykonawcy nawet w sytuacji, gdy ten nie jest już nią związany i wyrazi na to zgodę. Powyższe rozumowanie należy uznać za błędne, gdyż pomija ono kluczowy fakt, że, jeżeli wykonawca chce brać udział w postępowaniu, to – w przypadku skorzystania przez Zamawiającego z dyspozycji art. 220 ust. 3 - 5 Pzp, jest zobowiązany, pod rygorem odrzucenia, do wyrażenia zgody na przedłużenie terminu związania ofertą i wadium, o wskazany przez Zamawiającego okres, pod rygorem odrzucenia. Wykonawca uzyskuje prawo do wyrażania lub nie zgody na wybór jego oferty dopiero wówczas, gdy termin związania ofertą upłynął przed wyborem najkorzystniejszej oferty. Oczywistym jest przy tym, że nie chodzi tu o upływ terminu związania ofertą z jakiejkolwiek przyczyny, a w szczególności leżącej po stronie wykonawcy. Ustawodawca określił bowiem w ustawie Pzp skutki niewyrażenia zgody na przedłużenie terminu związania ofertą, wskazując, że konsekwencją takiej sytuacji jest odrzucenie oferty wykonawcy.
Zastosowanie tego przepisu byłoby zdaniem Odwołującego niedopuszczalne w odniesieniu do wykonawcy, który wyraził zgodę na przedłużenie terminu związania ofertą, jednak na okres krótszy niż żądany przez Zamawiającego w trybie art. 220 ust. 3 Pzp, bowiem oferta takiego wykonawcy powinna w takim przypadku podlegać odrzuceniu, skutkiem czego nie mogłaby ona otrzymać najwyższej oceny w rozumieniu przepisu art. 252 ust. 2 Pzp.
Obowiązek zamawiającego odrzucenia oferty wykonawcy w sytuacji, w której na jego wezwanie do przedłużenia terminu związania ofertą, wykonawca takiej zgody skutecznie nie wyrazi zachodzi więc nie tylko w przypadku całkowitego braku takiej zgody, ale również w przypadku złożenia oświadczenia o wyrażeniu zgody, jednak na warunkach innych niż narzucone wprost przez zamawiającego w wezwaniu. Przepis art. 220 ust. 3 Pzp nie stanowi bowiem o wyrażeniu zgody „co do zasady”, ale zgoda ma korelować i być odpowiedzią na żądanie Zamawiającego o ściśle określonej treści. Tą treścią jest wskazanie okresu, na jaki terminu związania ofertą ma być przedłużony. Jeżeli wykonawca nie akceptuje w pełni żądania Zamawiającego, to nie można mówić, że wyraził on „zgodę” na jego wniosek. Każda modyfikacja oświadczenia wykonawcy składanego w odpowiedzi na wezwanie wystosowane w trybie art. 220 ust. 3 Pzp względem żądania Zamawiającego stanowi więc o niezgodności z tym żądaniem, podlegając prostej kwalifikacji jako niewyrażenie zgody. Odpowiedź Kyndryl można również zakwalifikować jako odmowę wykonania wezwania w pełnym zakresie w zakreślonym terminie, połączoną z zapowiedzią przyszłego, niepewnego i warunkowego dopełnienia, a więc jako brak skutecznego przystąpienia do reżimu przedłużonego związania ofertą przewidzianego przez ustawę Pzp. Złożone przez Kyndryl oświadczenie odnoszące się do przedłużenia terminu związania ofertą nie stanowi więc „zgody” przedłużającej termin związania ofertą zgodnie z żądaniem Zamawiającego i jest nieskuteczne.
W niniejszym Postępowaniu Zamawiający zwrócił się o wyrażenie zgody na wydłużenie terminu związania ofertą i wadium do 16 maja 2026 r. do wszystkich trzech wykonawców, którzy złożyli oferty. Odwołujący i wykonawca Linux wyrazili zgodę na przedłużenie terminu związania ofertą w pełni zgodną z żądaniem Zamawiającego, tj. do 16 maja 2026 r., przedłużając równocześnie do tego dnia termin wadium. Wykonawcy Ci nie tylko podtrzymali więc swoją ofertą, ale też ponieśli ekonomiczny ciężar przedłużenia wadium na wymagany przez Zamawiającego okres. Mimo, że skierowane wezwanie o wyrażenie zgody na przedłużenie terminu związania ofertą i wadium do 16 maja 2026 r. jednakowo dotyczyło wszystkich wykonawców, to Kyndryl jako jedyny nie sprostał mu. Kyndryl oświadczył bowiem wprost, że przedłuża termin związania ofertą nie do 16 maja 2026 r., ale jedynie do 30 kwietnia 2026 r. Literalna treść oświadczenia i okoliczności jego złożenia wskazują przy tym na świadome ograniczenie terminu do okresu aktualnego wadium. Kyndryl przed upływem terminu związania ofertą, nie wniósł również wadium na przedłożony termin związania ofertą wymagany przez Zamawiającego, gdyż z jego oświadczenia wynika jasno, że utrzymuje on wadium jedynie do 30 kwietnia 2026 r., podczas, gdy wadium miało zabezpieczać ofertę przez cały wymagany przez Zamawiającego przedłużony termin związania ofertą, który upływać miał dla każdego wykonawcy 16 maja 2026 r. Mimo tego, że ustawa Pzp zakazuje nierównego traktowania wykonawców w takiej samej sytuacji, Zamawiający wprost naruszył ww. zasadę. Nie ulega wątpliwości, że z założenia ustawodawca dąży do sytuacji, w której to postępowanie o udzielenie zamówienia publicznego jest transparentne i równe dla wszystkich ubiegających o jego udzielenie. Stąd sytuacja, w której to jeden z ubiegających się o udzielenie zamówienia publicznego, na skutek własnych, niezgodnych z Pzp decyzji, miałby bardziej uprzywilejowaną sytuację od konkurentów startujących w tym samym postępowaniu jest zdaniem Odwołującego absolutnie niedopuszczalna. Pozostali wykonawcy ponieśli koszt pełnego wydłużenia terminu związania ofertą i wadium do 16 maja 2026 r., zaś wykonawca Kyndryl tego zaniechał. Utrzymanie jego oferty w postępowaniu mimo to, prowadzi do nierównego traktowania wykonawców. Dopuszczenie Kyndryl do dalszego udziału w postępowaniu, mimo niewyrażenia zgody na przedłużenie terminu związania oferta i wadium zgodnie z żądaniem Zamawiającego, faworyzuje go ekonomicznie i organizacyjnie. Krótszy okres związania ofertą oznacza bowiem mniejsze ryzyko i niższe koszty utrzymania wadium. Jeżeli wezwanie zamawiającego jest jednolite, to także odpowiedzi wykonawców muszą być oceniane według jednolitych kryteriów. Zaakceptowanie tego rozwiązania narusza więc wprost art. 16 pkt 1 i 3 Pzp, ponieważ Zamawiający wbrew regulacjom Pzp traktuje wykonawców nierówno i akceptuje sytuację, w której wykonawcy nie są obciążeni w taki sam sposób.
Niezależnie od powyższego należy wskazać, że ustawa Pzp, przeciwnie do Pzp z 2004 r., nie przewiduje możliwości samodzielnego wydłużenia terminu związania ofertą przez wykonawcę. Co więcej, w orzecznictwie wskazuje się wprost, że takie przedłużenie, jako nieprzewidziane w ustawie Pzp, jest nieskuteczne. Gdyby więc wykonawca Kyndryl na etapie po złożeniu oświadczenia o wyrażeniu zgody na przedłużenie terminu składania ofert i wadium jedynie do 30 kwietnia 2026 r., próbował przekazać Zamawiającemu kolejne oświadczenie przedłużające termin i wadium do 16 maja 2026 r., to nie sposób poczytać takiego oświadczenia inaczej niż samodzielne przedłużenie terminu związania ofertą i wadium, którego regulacje Pzp nie przewidują. Uprawnienie do wyrażenia zgody na przedłużenie terminu związania ofertą o okres wskazany przez Zamawiającego może być bowiem zrealizowane jedynie przed upływem pierwotnego terminu związania ofertą. W konsekwencji powyższego, jedynie złożone przed upływem pierwotnego terminu związania ofertą oświadczenie w przedmiocie wyrażenia zgody, o której mowa w art. 220 ust. 3 Pzp, może być uznane za zgodę w rozumieniu tego przepisu. Potencjalne kolejne oświadczenia w przedmiocie dalszego przedłużenia terminu składania ofert (i wadium), nie byłoby więc zgodą na żądanie Zamawiającego wystosowane na podstawie art. 220 ust. 3 i 4 Pzp, ale samodzielnym, nieprzewidzianym w ustawie Pzp działaniem wykonawcy Kyndryl, które cechowałaby bezskuteczność.
Podsumowując, zdaniem Odwołującego oferta Kyndryl powinna podlegać odrzuceniu na podstawie w zw. z art. 220 ust. 3 -5 Pzp z uwagi na brak wyrażenia zgody na przedłużenia terminu związania ofertą o wymagany przez Zamawiającego okres.
Zarzut 5 Jednocześnie, zgodnie z art. 220 ust. 5 Pzp przedłużenie terminu związania ofertą jest dopuszczalne tylko z jednoczesnym przedłużeniem okresu ważności wadium albo jeżeli nie jest to możliwie, z wniesieniem nowego wadium na przedłużony okres związania ofertą. Powyższy przepis konstruuje więc ustawowy warunek skutecznego przedłużenia terminu związania ofertą w postępowaniach, w których zamawiający żądają zabezpieczenia wadialnego. Wykonawca Kyndryl w oświadczeniu w przedmiocie przedłużenia terminu związania ofertą i wadium z 16 marca 2026 r. wprost przyznał, że jego gwarancja wadialna obowiązuje jedynie do 30 kwietnia 2026 r. i dlatego tylko do tej daty „przedłuża” termin związania ofertą. Innymi słowy, wykonawca Kyndryl sam potwierdził, że na moment odpowiedzi na wezwanie nie dysponuje wadium na okres, do którego zabezpieczenia oferty wadium Zamawiający żądał w wezwaniu wystosowanym w trybie art. 220 ust. 3 Pzp, tj. do 16 maja 2026 r. Tym samym wykonawca Kyndryl nie spełnił wymogu z art. 220 ust. 5 Pzp. Jednocześnie Kyndryl naruszył dyspozycję przepisu art. 97 ust. 6 Pzp, która wskazuje wprost, że przedłużenie terminu związania ofertą jest dopuszczalne tylko z jednoczesnym przedłużeniem okresu ważności wadium albo, jeżeli nie jest to możliwe, z wniesieniem nowego wadium na przedłużony okres związania ofertą. Art. 97 ust. 5 Pzp określa z kolei cezurę czasową dla utrzymania wadium, co w praktyce oznacza, że gwarancja wadialna powinna zachowywać ważność do końca terminu związania ofertą – w przypadku żądania jego przedłużania – do przedłużonego terminu związania ofertą.
Skuteczne przedłużenie terminu związania ofertą, tj. zgodnie z żądaniem Zamawiającego, wymagało wydłużenia terminu związania ofertą do 16 maja 2026 r. i wniesienia na ten okres nowego wadium, lub przedłużenia obecnego. Wykonawca ma przy tym obowiązek wniesienia wadium się przed upływem terminu składania ofert i utrzymywania go nieprzerwanie do upływu terminu związania ofertą. Przedłużenie terminu związania ofertą jest dopuszczalne tylko z jednoczesnym przedłużeniem okresu ważności wadium albo, jeżeli nie jest to możliwe, z wniesieniem nowego wadium na przedłużony okres związania ofertą. W obliczu oświadczenia wykonawcy Kyndryl złożonego na wezwanie w trybie art. 220 ust. 3 Pzp, nie sposób uznać, że Kyndryl przedłużył termin związania ofertą do 16 maja 2026 r., jak również przedłużył/wniósł nowe wadium zabezpieczające ofertę do tej daty włącznie. Nie ulega wątpliwości, że wadium musi być wniesione od razu na cały okres związania ofertą/przedłużonego terminu związania ofertą. Nie jest możliwe przyjęcie, że zawarty w przepisie wymóg jego nieprzerwanego utrzymywania byłby zachowany także wówczas, gdyby wadium wniesiono początkowo na część przedłużonego okresu związania ofertą, a przed jego upływem przedłużono aż do końca tego przedłużonego terminu, jak chciałby tego wykonawca Kyndryl, biorąc pod uwagę treść jego oświadczenia woli z 16 marca 2026 r. Taka interpretacja przepisu jest zdaniem Odwołującego błędna – ponieważ istotą wadium jest zabezpieczenie zobowiązania wynikającego z oferty. Ustawodawca przedłużanie terminu związania ofertą wiąże z obowiązkiem przedłużenia ważności wadium na cały przedłużony okres związania (art. 97 ust. 6 i art. 220 ust. 5 Pzp). Skoro więc skuteczne przedłużenie terminu związania ofertą, tj. zgodne z wnioskiem/żądaniem Zamawiającego, w tym o okres ściśle w nim skonkretyzowany, możliwe jest jedynie jednocześnie z przedłużeniem lub wniesieniem nowego wadium na cały przedłużany, zgodnie z żądaniem zamawiającego okres, to konieczne jest jednorazowe, uprzednie przedłużenie wadium o wymagany przez zamawiającego okres/wniesienie nowego wadium na cały przedłużany okres. Nie sposób racjonalnie przyjąć, że przy podstawowym, jak również przedłużanym terminie związania ofertą, możliwe jest wnoszenie wadium na kolejne, krótsze okresy (nieobejmujące całego wymaganego terminu związania ofertą), aż do osiągnięcia docelowego terminu związania ofertą, gdyż stałoby w sprzeczności z regulacjami art. 97 ust. 6 i 220 ust. 5 Pzp. Gdyby wykonawca wraz z oferta wniósł wadium na niepełny okres związania ofertą i zadeklarował, że dośle aneks wydłużający wadium do docelowego terminu związania ofertą „później”, oferta takiego wykonawcy podlegałaby odrzuceniu. Wniesione wraz z ofertą wadium musi bowiem zabezpieczać od razu cały okres związania ofertą. Analogicznie jest przy przedłużeniu terminu związania ofertą. Również w tym przypadku wadium powinno zabezpieczać ofertę od razu na cały - przedłużany zgodnie z żądaniem Zamawiającego – okres.
KIO 1648/26
10 kwietnia 2026 r. wykonawca Kyndryl Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie (dalej: Odwołujący Kyndryl), wniósł odwołanie i zarzucił Zamawiającemu:
1. art. 239 ust. 1 w zw. z art. 16 pkt 1-3 Pzp, przez nieprawidłowe przyznanie wykonawcy Linux Polska Sp. z o.o. maksymalnej liczby punktów w kryterium oceny ofert „Pozycja w Gartner® Magic Quadrant™ Observability na rok 2025”, podczas gdy prawidłowa ocena powinna skutkować brakiem przyznania jakichkolwiek punktów, ponieważ:
a) przy zastosowaniu literalnej wykładni kryterium określonego przez Zamawiającego żadna z ofert – w tym oferta Linux Polska Sp. z o.o., nie spełnia kryteriów uzasadniających przyznanie jakichkolwiek punktów;
b) [zarzut ewentualny względem zarzutu 1a] w raporcie Gartnera, na podstawie którego Zamawiający zobowiązał się do weryfikacji informacji zawartych w formularzu ofertowym wykonawcy Linux Polska Sp. z o.o., w kategorii „Liderzy” nie znajduje się podmiot „Elasticsearch”, którego oprogramowanie zaoferował Linux Polska Sp. z o.o.
2. art. 239 ust. 1 w zw. z art. 226 ust. 1 pkt 5 Pzp przez zaniechanie odrzucenia oferty wykonawcy Linux Polska Sp. z o.o. w sytuacji, w której jej treść jest niezgodna z warunkami zamówienia.
W oparciu o podniesione zarzuty Odwołujący Kyndryl wniósł o nakazanie Zamawiającemu:
1. Unieważnienia czynności wyboru oferty najkorzystniejszej,
2. Powtórzenia czynności badania i oceny ofert, a w jej ramach:
a) Przyznania wykonawcy Linux Polska Sp. z o.o. 0 pkt w kryterium pn.: „Pozycja w Gartner Magic Quadrant Observability na rok 2025”,
b) Odrzucenia oferty Linux Polska Sp. z o.o. na podstawie art. 226 ust. 1 pkt 5 Pzp.
W uzasadnieniu swojego stanowiska Odwołujący Kyndryl wskazał m.in.:
31 marca 2026 r. Zamawiający dokonał wyboru oferty najkorzystniejszej, którą okazała się oferta wykonawcy Linux Polska Sp. z o.o. W kryterium Pozycja w Gartner® Magic Quadrant ™ Observability na rok 2025 ww. wykonawca otrzymał maksymalną ilość punktów, tj. 15. Ostatecznie przełożyło się to również na punktację w wysokości 99,70 pkt. Punktacja wszystkich wykonawców przedstawia się następująco:
Zarzut nr 1a:
W pierwszej kolejności należy wskazać, że w kryterium pn.: „Pozycja w Gartner® Magic Quadrant™ Observability na rok 2025” , każdy z oferentów powinien był otrzymać 0 punktów. Wynika to z błędnej konstrukcji ww. kryterium, która uniemożliwia przyznanie jakichkolwiek punktów któremukolwiek z wykonawców. Z analizy SWZ w omawianym zakresie wynika, że punkty w ramach ww. kryterium mógł uzyskać wykonawca, którego zaoferowany produkt znajduje się w określonej pozycji rankingu Gartnera. a. 0 punktów otrzyma wykonawca, którego zaoferowany produkt znajduje się w pozycji Gracze Niszowi, a także wykonawca, który wskazał pozycję w Gartner® Magic Quadrant ™ Observability na rok 2025 dla zaoferowanego produktu niezgodnie ze stanem faktycznym bądź nie wypełnił Tabeli 1 w pkt 1.6 Formularza oferty. b. 2 punkty otrzyma wykonawca, którego zaoferowany produkt znajduje się w pozycji Wizjonerzy. c. 7 punktów otrzyma wykonawca, którego zaoferowany produkt znajduje się w pozycji Kandydaci. d. 15 punktów otrzyma wykonawca, którego zaoferowany produkt znajduje się w pozycji Liderzy.
Potwierdza to również treść formularza ofertowego, w którego punkcie 1.6 należało wpisać: „ Informacja o pozycji zaoferowanego produktu w Gartner® Magic Quadrant™ Observability na rok 2025, bądź informacja, że zaoferowany produkt nie znajduje się w Gartner® Magic Quadrant™ Observability na rok 2025, zgodnie z wymogiem 7.3.3. SWZ”. Również pod Tabelą 1 zawarto stosowną uwagę, zgodnie z którą „wypełnia Wykonawca przez wpisanie „x” tylko w jednej, właściwej kolumnie, w zależności od pozycji zaoferowanego produktu w Gartner® Magic Quadrant™ Observability na rok 2025 / zaoferowany produkt nie znajduje się w Gartner® Magic Quadrant™ Observability na rok 2025, z zastrzeżeniem pkt 7.3.3.1.SWZ”.
Z powyższego wynika, że w ramach omawianego kryterium, zgodnie z literalną treścią SWZ oraz pozostałych dokumentów zamówienia , obowiązkiem Zamawiającego było przyznanie określonej ilości punktów wyłącznie w oparciu o pozycję zaoferowanego produktu w rankingu Gartnera. Ocenie podlega wyłącznie to, czy i w jakim segmencie rankingu Gartnera znajduje się produkt wskazany w ofercie danego wykonawcy. Należy jednak podkreślić, że tak ukształtowana treść przedmiotowego kryterium w praktyce uniemożliwia przyznanie jakichkolwiek punktów któremukolwiek z wykonawców, w konsekwencji czego wszyscy oferenci powinni otrzymać 0 punktów w jego ramach. Wynika to z faktu, że w rankingu Gartnera klasyfikacji podlegają poszczególne podmioty (firmy), a nie oferowane przez nie produkty. Wyjaśnienie tej materii należy rozpocząć od zdefiniowania czym jest w ogóle wspomniany ranking. Gartner Magic Quadrant ™ to narzędzie wizualne oparte na rygorystycznej metodologii, które przedstawia graficzne porównanie pozycji dostawców technologii i usług na określonym rynku. Ocenia ono dostawców na podstawie dwóch kluczowych kryteriów: zdolności do realizacji (Ability to Execute) oraz kompletności wizji (Completeness of Vision). Źródło: Oficjalna strona internetowa rankingu Gartnera: quadrant Na skutek ewaluacji poszczególnych firm tworzone jest ich porównanie w formie graficznej, które przyporządkowuje każdą z nich do jednej z 4 kategorii, tj. Gracze Niszowi (Niche Players), Wizjonerzy (Visionaries), Kandydaci (Challengers) oraz Liderzy (Leaders). Ranking taki tworzony jest w wielu różnych kategoriach, w tym m. in. w kategorii Observability Platforms, do której odnosił się Zamawiający w niniejszym postępowaniu w ramach kryteriów oceny ofert . W omawianej kategorii ranking przedstawia się następująco:
Zgodnie jednak z treścią samego raportu (str. 31-36) , przyporządkowanie poszczególnych firm do jednej z ww. kategorii nie zależy tylko i wyłącznie od jakości oferowanego przez nich produktu, a od szeregu innych czynników, które składają się na ich całościową ocenę.
Wśród tych czynników można wymienić m. in. : Ogólna wykonalność („Overall viability”), Realizacja sprzedaży/cennik („Sales execution/pricing”), Responsywność na rynek („Market responsiveness”), Realizacja działań marketingowych („Marketing execution”), Zadowolenie klienta („Customer experience”), Strategia sprzedaży („Sales strategy”), Model biznesowy („Business Model”) i inne.
Dowód: raport pn.: „Magic Quadrant for Observability Platforms” wraz z tłumaczeniem fragmentów (str. 31 -36) na j ęzyk polski.
Produkt lub usługa stanowią tylko jeden z wielu ocenianych kryteriów. Na ostateczną ocenę wpływ ma jednak szereg innych czynników. Powyższe prowadzi do wniosku, że o pozycji w rankingu nie przesądza jakość zaoferowanego produktu, a ogólna kondycja ocenianego wykonawcy. Co więcej, to nie produkt zajmuje określoną pozycję w rankingu tylko dostawca. Ranking ma więc charakter podmiotowy, a nie przedmiotowy. Tym samym możliwa jest sytuacja, w której firma posiadająca produkt o najwyższej możliwej jakości nie znajdzie się kategorii „Liderzy”, gdyż nisko zostanie oceniona jej strategia marketingowa i biznesowa czy sprzedażowa, przez co ostatecznie wyląduje w niższej kategorii lub w ogóle nie znajdzie się w rankingu. Biorąc powyższe pod uwagę należy stwierdzić, że przyznanie przez Zamawiającego punktów w omawianym kryterium oceny ofert w jego obowiązującym brzmieniu jest niemożliwe. Kryterium to zostało bowiem skonstruowane w sposób wewnętrznie sprzeczny. Z jednej strony odnosi się wyłącznie do produktu oferowanego przez wykonawcę, z drugiej zaś odwołuje się do narzędzia oceny (Gartner Magic Quadrant™ ), które w istocie nie klasyfikuje produktów, lecz całościową pozycję rynkową dostawców, uwzględniając szereg czynników wykraczających poza sam produkt. W konsekwencji brak jest możliwości przypisania konkretnego produktu do określonej kategorii wskazanej w rankingu Gartnera w sposób zgodny z literalnym brzmieniem kryterium. Ranking ten nie przewiduje bowiem klasyfikacji na poziomie produktu, lecz na pozio mie podmiotu (dostawcy), którego ocena jest wynikiem kompleksowej analizy obejmującej m.in. strategię biznesową, zdolności operacyjne czy pozycję rynkową. Tym samym nie istnieje obiektywne i weryfikowalne kryterium pozwalające na ustalenie, w jakiej „pozycji” znajduje się konkretny produkt oferowany przez wykonawcę. Pozycję tę zajmuje bowiem określony podmiot, a nie produkt. Powyższe prowadzi do sytuacji, w której Zamawiający chcąc zastosować przedmiotowe kryterium zmuszony byłby w istocie dokonać jego wykładni rozszerzającej, polegającej na przypisaniu określonej ilości punktów nie z uwagi na pozycję danego produktu w rankingu, a z uwagi na pozycję danego dostawcy w rankingu, co nie ma oparcia w literalnej treści ustanowionego kryterium.
To z kolei nasuwa wniosek , że w ramach omawianego kryterium każdy z wykonawców powinien otrzymać 0 punktów, gdyż nie ma obiektywnej możliwości ustalenia czegoś takiego jak „pozycja zaoferowanego produktu w Gartner Magic Quadrant”. Zgodnie z art. 239 ust. 1 Pzp zamawiający wybiera najkorzystniejszą ofertę na podstawie kryteriów oceny ofert określonych w dokumentach zamówienia. Z tego przepisu wynika zasada związania zamawiającego zasadami oceny ofert opisanymi w dokumentach zamówienia, w tym ustalonymi kryteriami oraz opisem sposobu przyznawania punktów w ramach poszczególnych kryteriów. Zamawiający do oceny ofert może zastosować wyłącznie takie kryteria i zasady, jakie wskazał w dokumentach zamówienia. Zamawiający, oceniając oferty, nie może zatem ani uszczegółowić zasad oceny przez badanie w sposób, który nie został jednoznacznie wyartykułowany w zapisach SWZ, ani też odstępować od zasad, które opisał uprzednio (…). W związku z powyższym Zamawiający, postępując zgodnie z literalną treścią ustanowionego przez siebie kryterium, powinien był w jego ramach przyznać każdemu z wykonawców , w tym wykonawcy Linux Polska Sp. z o.o., 0 punktów. Przyznanie wskazanemu wykonawcy maksymalnej ilości punktów w omawianym kryterium nie znajduje uzasadnienia w jego literalnym brzmieniu. T o nie produkt oferowany przez firmę Elastic zajmuje bowiem określoną pozycję w rankingu, a ta firma, która oceniana jest przez pryzmat szeregu kryteriów. Powyższe przesądza o zasadności postawionego zarzutu.
Zarzut nr 1b [ewentualny wobec zarzutu nr 1a]:
Zgodnie z treścią SWZ pkt 7.2.3.2. Zamawiający dokonuje oceny w kryterium „Pozycja w Gartner® Magic Quadrant™ Observability na rok 2025” na podstawie informacji podanej przez Wykonawcę w Formularzu Oferty w zakresie zaoferowanego produktu, którą Zamawiający zweryfikuje na podstawie rankingu dostępnego pod adresem: https://www.gartner.com W treści formularza ofertowego wykonawca Linux Polska Sp. z o.o. wskazał, że oferowany przez niego produkt został sklasyfikowany w Gartner® Magic Quadrant™ Observability na rok 2025 w pozycji Liderzy (Leaders). Nie jest to jednak informacja prawdziwa. Zaoferowany przez ww. wykonawcę produkt został przez niego zindywidualizowany w punkcie 4 formularza ofertowego, gdzie wskazano następująco: - producent oprogramowania: Elasticsearch, - nazwa oprogramowania: Enterprise.
Tymczasem w raporcie Gartnera, na podstawie którego Zamawiający zobowiązał się do weryfikacji informacji zawartych w formularzu ofertowym, w kategorii „Liderzy” nie znajduje się podmiot „Elasticsearch”, którego oprogramowanie zaoferował Linux Polska Sp. z o.o. W ramach ww. kategorii w raporcie znalazły się następujące podmioty: Chronosphere, IBM, Splunk. Elastic, New Relic, Dynatrace, Datadog oraz Grafana Labs. Zamawiający nie miał więc podstawy by przyznać Linux Polska Sp. z o.o. jakiekolwiek punkty w omaw ianym kryterium. Źródło, w którym Zamawiający zobowiązał się do weryfikacji informacji zawartych w formularzach ofertowych wykonawców, nie wymienia bowiem podmiotu Elasticsearch. To z kolei powinno skutkować przyznaniem ww. wykonawcy 0 punktów w omawianym kryterium.
Zarzut nr 2:
W formularzu ofertowym wykonawca Linux Polska Sp. z o.o. wskazał, że oferuje następujący produkt: Producent oprogramowania: Elasticsearch, nazwa oprogramowania: Enterprise.
W skazać jednak należy, że zaoferowany przez Linux produkt nie spełnia części wymogów wskazanych w OPZ, tj. przede wszystkim niespełnione są wymogi wskazane w punkcie II.25, II.27.64, II.27.69 oraz II.27.55 szczegółowego opisu przedmiotu zamówienia.
Z aoferowany produkt nie spełnia wymogu wskazanego w punkcie II.25 Szczegółowego opisu przedmiotu zamówienia/umowy . Zgodnie z punktem II.25 SOPZ , zmodyfikowanym 26 września 2025 r. w ramach udzielonych wyjaśnień do SWZ:
„Aktualizacje Oprogramowania muszą mieć możliwość automatycznego pobierania na serwer. Aplikacja musi mieć możliwość ustawienia automatycznego lub ręcznego sposobu instalowania aktualizacji. Aktualizacja musi mieć możliwość wykonywania z poziomu centralnej konsoli serwera”.
Wskazać należy, że funkcjonalność automatycznego pobierania na serwer oraz możliwość automatycznego lub ręcznego sposobu instalowania aktualizacji nie jest jednak dostępna w systemie Elasticsearch. Funkcjonalność ta jest osiągalna jedynie przez integrację z wykorzystaniem rozwiązań firm trzecich. Powyższe oznacza, że deklarowan a przez wykonawcę funkcjonalność nie stanowi parametru gwarantowanego w każdych warunkach, lecz jest wartością możliwą do osiągnięcia jedynie w sytuacji spełnienia dodatkowych przesłanek technicznych, które nie wynikają z treści wymagań określonych przez Zamawiającego , tj. w razie zintegrowania oferowanego oprogramowania z rozwiązaniami stron trzecich. Tym samym oferowany wyrób nie zapewnia samodzielnie wymaganej funkcjonalności, lecz uzależnia jej osiągnięcie od czynników zewnętrznych, co należy ocenić jako odstępstwo od wymogu Zamawiającego określonego w sposób jednoznaczny i bezwarunkowy. Powyższa teza znajduje potwierdzenie w opinii wydanej przez certyfikowanego inżyniera Elastic Observability, w której wskazuje on, że:
„Rozwiązanie Elasticsearch Enterprise nie ma możliwości automatycznego pobierania aktualizacji oprogramowania na serwer. Musimy to robić ręcznie lub za pomocą narzędzi automatyzacji, takich jak Ansible czy Puppet”.
Dowód: opinia certyfikowanego inżyniera Elastic Observability p. R.S. wraz z tłumaczeniem na język polski.
Z aoferowany produkt nie spełnia wymogu wskazanego w punkcie II.27.64 Szczegółowego opisu przedmiotu zamówienia/umowy . Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:
„umożliwiać automatyczne sprawdzanie dostępności aplikacji przez wykonywanie skryptu symulującego pracę użytkownika; przygotowanie skryptu nie może wymagać od użytkownika umiejętności programistycznych, musi wykorzystywać mechanizm „rekordreplay””.
W zakresie powyższego wymogu Zamawiający udzielił następującego wyjaśnienia treści dokumentów zamówienia:
Pytanie nr 39 Czy zamawiający dopuści realizację wymagań z punktu 27.64 przez drugi produkt, bez konieczności znajomości narzędzi programistycznych? Pozwoli to dopuścić do postępowania rozwiązania i niższej cenie?
Odpowiedź:
Zamawiający podtrzymuje postanowienia SWZ.
System , którego producentem jest firma Elastic umożliwia syntetyczny monitoring dostępności aplikacji, jednak przygotowanie scenariuszy symulujących pracę użytkownika wymaga tworzenia skryptów programistycznych (JavaScript/TypeScript) i nie wykorzystuje mechanizmu record/replay. Tym samym nie spełnia wymogów Zamawiającego określonych w OPZ. Przede wszystkim bowiem przygotowanie skryptów wymaga od użytkownika umiejętności programistycznych, co jest wprost niezgodne z wymaganiem punktu II.27.64.
Ponownie ww. stanowisko znajduje potwierdzenie w opinii wydanej przez certyfikowanego inżyniera Elastic Observability, w której wskazuje on, że:
„Automatyczne sprawdzanie dostępności aplikacji może być wykonane za pomocą narzędzia APM lub rozwiązania APM Elasticsearch, czyli monitorowania wydajności aplikacji. Jednak wymagani „agenci” muszą być pobrani ze strony aplikacji, konieczne jest dostrojenie agentów po stronie aplikacji. Nie wymaga pisania dodatkowego skryptu, ale sam skrypt aplikacji musi zostać lekko zmodyfikowany, aby zintegrować APM”.
Dowód: opinia certyfikowanego inżyniera Elastic Observability p. R.S. wraz z tłumaczeniem na język polski.
Zaoferowany produkt nie spełnia wymogu wskazanego w punkcie II.27. 69 Szczegółowego opisu przedmiotu zamówienia/umowy . Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:
„zapewniać monitorowanie pracy użytkownika końcowego (user experience) bez konieczności instalacji dodatkowych komponentów po stronie użytkownika i wykonywania zmian konfiguracji, serwerów WWW lub aplikacyjnych; zmiana konfiguracji czy też włączenie/wyłączenie monitorowania zachowań użytkownika musi odbywać się z konsoli narzędzia, bez potrzeby restartu serwerów monitorowanego środowiska”.
System Elasticsearch realizuje monitoring doświadczenia użytkownika w oparciu o RUM, który wymaga modyfikacji aplikacji lub konfiguracji serwerów WWW . Włączenie lub wyłączenie monitoringu nie odbywa się wyłącznie z poziomu konsoli narzędzia i może wymagać ponownego wdrożenia aplikacji , co jest wprost niezgodne ze wspomnianym punktem OPZ.
Ponownie powyższe stanowisko potwierdził certyfikowany inżynier Elastic Observability w swojej opinii, gdzie wskazano następująco: „To stwierdzenie nie jest w pełni poprawne dla Elasticsearch. Elastic zapewnia monitorowanie doświadczenia użytkownika końcowego (RUM), ale wymaga agenta po stronie klienta, pewnych zmian konfiguracji i nie może być całkowicie sterowany wyłącznie z konsoli, choć wiele zmian nie wymaga restartu serwera”.
Dowód: opinia certyfikowanego inżyniera Elastic Observability p. R.S. wraz z tłumaczeniem na język polski.
Zaoferowany produkt nie spełnia wymogu wskazanego w punkcie II.27. 55 Szczegółowego opisu przedmiotu zamówienia/umowy .
Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi: „wykrywać podatności bezpieczeństwa w bibliotekach wykorzystywanych przez aplikacje w trybie ciągłym (24/7). Baza podatności musi być aktualizowana automatycznie, w trybie ciągłym i nie wymagać konfiguracji po stronie Zamawiającego”. System Elasticsearch nie zapewnia natywnej funkcjonalności ciągłego (24/7) wykrywania podatności w bibliotekach wykorzystywanych przez aplikacje ani autonomicznie aktualizowanej bazy podatności w tym zakresie. Konieczna jest wykluczona przez Zamawiającego integracja z zewnętrznym rozwiązaniem. W przedłożonej jako dowód opinii certyfikowanego inżyniera Elastic Observability wskazano następująco:
„Elastic może nieustannie monitorować systemy pod kątem znanych luk, korzystając z zaktualizowanych informacji wywiadu zagrożeń, ale nie jest przede wszystkim zaprojektowany do automatycznego skanowania bibliotek aplikacji/zależności bez dodatkowych narzędzi, takich jak snyk ”.
Dowód: opinia certyfikowanego inżyniera Elastic Observability p. R.S. wraz z tłumaczeniem na język polski.
Niezależnie od powyższych okoliczności, które zostały poparte opinią certyfikowanego inżyniera Elastic Observability, Odwołujący wskazuje, że produkt zaoferowany przez wykonawcę Linux Polska Sp. z o.o. nie spełnia innych, kategorycznych wymagań SOPZ, tj.:
33. [zaoferowany produkt nie spełnia wymogu wskazanego w pkt II.14 Szczegółowego opisu przedmiotu zamówienia/umowy ] Zgodnie z punktem II.14 OPZ „Dla oferowanego Oprogramowania opieka serwisowa musi być świadczona w języku polskim”. Produkt zaoferowany przez wykonawcę Linux Poland sp. z o.o. stwarza jedynie pozory spełniania ww. wymogu, w rzeczywistości będąc z nim niezgodny.
W pierwszej kolejności należy wskazać, że jednym z przejawów spełniania wymogu z punktu II.14 jest posiadanie polskiej wersji strony internetowej dla produktów Elastic, dostępnej pod adresem: https://info.elastic.co/cemea Strona ta jest jednak tylko pozorną „nakładką” na anglojęzyczną stronę producenta. Potwierdzają to następujące okoliczności:
(a) Odnośniki do warunków świadczenia usług oraz oświadczenia dot. prywatności są w języku angielskim;
(b) link do rzekomej grupy polskich użytkowników rozwiązań elastic jest linkiem odsyłającym do nieistniejącej strony;
(c) Materiały, do których linki działają są sporządzone w języku angielskim np. (d) Próba otworzenia rzekomo polskojęzyczn ych materiałów (np. Elasticsearch: pierwsze kroki skutkuje przeniesieniem do anglojęzycznej wersji strony bez wyświetlenia polskojęzycznego materiału .
Zgodnie z punktem II.27.6 SOPZ w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi: „umożliwiać własną definicję warstwy/usługi, która zostanie włączona w reprezentację graficzną przez wskazanie punktu startowego - metody wykonywanego kodu. Taka warstwa/usługa powinna być raportowana w ramach pełnego przebiegu transakcji (end-2-end) oraz niezależnie od przebiegu”.
Wskazać należy, że ww. funkcjonalność możliwa jest do osiągnięcia przez system Elastic przez ingerencję w kod aplikacji i dopisanie linii kodu umożliwiających wysyłanie odpowiednich informacji do systemu. Oznacza to, że ww. system nie spełnia wymogu OPZ w sposób bezwarunkowy, a dopiero po uwzględnieniu dodatkowego nakładu pracy programisty i związanego z tym wynagrodzenia. Zamawiający oczekiwał spełnienia ww. funkcjonalności przez oferowany produkt bezwarunkowo i samodzielnie co oznacza, że oferta Linux Polska Sp. z o.o. jest niezgodna warunkami zamówienia .
Zgodnie z punktem II.27.6 SOPZ w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:
„umożliwiać własną definicję warstwy/usługi, która zostanie włączona w reprezentację graficzną przez wskazanie punktu startowego - metody wykonywanego kodu. Taka warstwa/usługa powinna być raportowana w ramach pełnego przebiegu transakcji (end-2-end) oraz niezależnie od przebiegu”. Wskazane wymaganie spełnione jest przez system Elastic tylko częściowo co oznacza, że w pozostałej części jest niezgodne z OPZ bowiem wymaga modyfikacji kodu aplikacji, a nie wyłącznie konfiguracji systemu monitorującego. Oznacza to, że nie jest to tożsame z wymogiem zapisanym przez Zamawiającego w SOPZ.
Zgodnie z punktem II.27.1 6 SOPZ w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:
„prezentować zapytania SQL wykonane w ramach transakcji z możliwością uzyskania informacji o liczbie zwróconych wierszy”. Dla spełnienia ww. wymogu przez system Elastic wymagana jest modyfikacja kodu. Żeby spełnić wymaganie „SQL + liczba zwróconych wierszy”, trzeba dostarczyć tę informację spoza standardowego APM, np.: Instrumentacja w aplikacji wymaga dopisania funkcjonalności w kodzie.
Zgodnie z punktem II.27.23 SOPZ w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi: „umożliwiać wykonywanie zrzutów pamięci ze sterty Java oraz jej analizę pod względem wycieków i optymalizacji. Zrzut pamięci nie może zatrzymywać działającej aplikacji”.
Wymóg ten wzbudzał liczne wątpliwości, które zostały przez Zamawiającego sprecyzowane w toku postępowania:
Pytanie nr 11 Wykonawca zwraca się z wnioskiem o wykreślenie z treści SWZ pkt. 27.23 z Załącznika 7, rozdz. II. Zapis w obecnym kształcie może wskazywać na preferowanie jednego producenta (Dynatrace) oraz ryzyko ograniczenia konkurencji w Postępowaniu. Alternatywnie czy Zamawiający dopuszcza możliwość spełnienia tego wymagania przez integrację zaoferowanego przez Wykonawcę rozwiązania z istniejącymi na złożenia oferty narzędziami zewnętrznymi.
Odpowiedź:
Zamawiający oczekuje funkcjonalności określonej w pkt 27.23 – oferowane oprogramowanie ma „umożliwiać wykonywanie zrzutów pamięci ze sterty Java oraz jej analizę pod względem wycieków i optymalizacji. Zrzut pamięci nie może zatrzymywać działającej aplikacji”. Zamawiający dopuszcza możliwość spełnienia tego wymagania przez integrację zaoferowanego przez Wykonawcę rozwiązania z istniejącymi na złożenia oferty narzędziami zewnętrznymi objętymi ofertą Wykonawcy.
Pytanie nr 51 Ad Załącznik nr 7 do SWZ „Szczegółowy opis przedmiotu zamówienia/Umowy”. Pkt II, ppkt 27.23 „Czy Zamawiający dopuści rozwiązanie, które nie posiada funkcjonalności wykonywania automatycznego zrzutu pamięci ze sterty Java, przy czym umożliwia automatyczne wykrywanie wycieków pamięci celem wczesnego ostrzegania o możliwych problemach z wydajnością aplikacji Java oraz łatwiejszą analizy przyczyn źródłowych tych problemów?" Zastosowany zapis jest właściwy dla firmy Dynatrace i uniemożliwia zaoferowanie innych rozwiązań niż Dynatrace Managed Odpowiedź: Zamawiający podtrzymuje postanowienia SWZ, jednocześnie patrz odpowiedź na Pytanie nr 11.
Oferowany przez wykonawcę Linux Polska system nie posiada natywnej funkcjonalności wykonywania zrzutów pamięci sterty Java (heap dump) dla monitorowanych aplikacji Zamawiającego ani ich analizy pod kątem wycieków pamięci i optymalizacji. Realizacja tego wymagania wymaga zastosowania zewnętrznych narzędzi lub profilerów JVM (np. narzędzi JDK lub dedykowanych rozwiązań APM), a Elastic pełni jedynie rolę platformy zbierania i korelacji danych . Z oferty Linux nie wynika, aby takie zewnętrzne narzędzia zostały z aoferowane.
Dodatkowo, mechanizmy wykonywania heap dumpów w środowiskach zarządzanych przez Elastic (np. ECE) powodują pauzę JVM w trakcie tworzenia zrzutu, co oznacza czasowe wstrzymanie przetwarzania aplikacji. W konsekwencji nie jest spełniony wymóg OPZ, zgodnie z którym zrzut pamięci nie może zatrzymywać działającej aplikacji. Powyższe okoliczności powinny skłonić Zamawiającego do uznania, że w rzeczywistości produkt zaoferowany przez wykonawcę Linux Polska Sp. z o.o. nie spełnia warunku wskazanego w pkt II.27.23 SOPZ.
Zgodnie z ww. wymogiem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:
„posiadać własny interfejs do tworzenia lub konfigurowania własnych wtyczek monitorujących rozszerzających standardowe funkcjonalności narzędzia”.
Dla spełnienia ww. wymogu przez system Elastic wymagana jest jego integracja z rozwiązaniami firm trzecich. Elastic nie spełnia wymagania posiadania własnego interfejsu do tworzenia lub konfigurowania wtyczek monitorujących; realizacja rozszerzeń funkcjonalnych wymaga prac programistycznych oraz użycia narzędzi zewnętrznych.
Zgodnie z punktem II.27.26 SOPZ w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:
„umożliwiać maskowanie adresów IP użytkowników. Maskowanie musi być wykonane przed zapisem adresu IP do bazy danych narzędzia”. System Elastic by spełnić ww. wymaganie wymaga integracji z rozwiązaniami trzecimi (brak natywnej funkcjonalności). Elastic zapewnia automatyczny monitoring wszystkich procesów na poziomie metryk systemowych. Rozszerzony monitoring procesów Java, .NET i PHP (wątki, sterta, GC) realizowany jest warunkowo i wymaga instalacji oraz konfiguracji dedykowanych agentów APM - nie jest aktywowany automatycznie dla każdego nowo wykrytego procesu. To oznacza, że wskazane wymaganie nie jest spełnione bezwarunkowo. Dla poprawnego działania systemu, w zgodzie z zapisami OPZ, niezbędnym jest spełnienie dodatkowych wymogów, co potwierdza, że oferta jest niezgodna z warunkami zamówienia i powinna zostać o drzucona.
Zgodnie z punktem II.27.37 SOPZ w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi: „umożliwiać monitoring wszystkich procesów działających na serwerach objętych monitoringiem na poziomie co najmniej metryk systemowych: wykorzystanie CPU, pamięci, operacji IO, wykorzystanie sieci. Dla procesów JAVA, .NET i PHP dodatkowo monitoring musi obejmować statystyki wykorzystania wątków, sterty JVM i CLR oraz wpływ działania Garbage Collector’a na proces. Nowe procesy muszą być wykrywane i monitorowane automatycznie bez potrzeby ręcznej konfiguracji”.
Wymóg ten został dodatkowo doprecyzowany przez Zamawiającego:
Pytanie nr 95 Dotyczy punktu 27.37: Jakie konkretne dane lub metryki dotyczące działania Garbage Collector'a są wymagane dla aplikacji PHP? Czy wymagane jest monitorowanie GC na poziomie szczegółowym (czas, częstotliwość), czy wystarczą dane ogólne, np. wzrost zużycia pamięci lub opóźnień?
Odpowiedź: Zamawiający wymaga monitorowania Garbage Colletora na poziomie szczegółowym. System oferowany przez wykonawcę Linux Polska Sp. z o.o., nie ma takiej natywnej funkcjonalności i wymaga integracji z rozwiązaniami trzecimi. Ponownie świadczy to o tym, że wymaganie Zamawiającego nie jest spełnione w sposób bezwarunkowy przez oferowane rozwiązanie . Elastic zapewnia automatyczny monitoring wszystkich procesów na poziomie metryk systemowych. Rozszerzony (szczegółowy) monitoring procesów Java, .NET i PHP (wątki, sterta, GC) realizowany jest warunkowo i wymaga instalacji oraz konfiguracji dedykowanych agentów APM. nie jest aktywowany automatycznie dla każdego nowo wykrytego procesu. Tym samym nie jest spełniony wymóg, na którym szczególnie zależy Zamawiającemu, tj. monitor owanie Garbage Collectora na poziomie szczegółowym.
Tym samym spełnienie przedmiotowego wymogu uzależnione jest od dalszych działań implementacyjnych, wykraczających poza zakres standardowej funkcjonalności oferowanego oprogramowania, co pozostaje w sprzeczności z jednoznacznie określonymi wymaganiami SOPZ.
Powyższe okoliczności powinny skłonić Zamawiającego do uznania, że w rzeczywistości produkt zaoferowany przez wykonawcę Linux Polska Sp. z o.o. nie spełnia warunku wskazanego w pkt II.27.37 SOPZ.
Odnośnie do wyżej wskazanych postanowień OPZ należy zwrócić uwagę na odpowiedź Zamawiającego na pytanie nr 38. W odpowiedzi tej Zamawiający podkreślił, że interesuje go rozwiązanie, w ramach którego nie jest konieczne użycie drugiego produktu.
Pytanie nr 38 Czy zamawiający dopuści realizacje wymagań z punktów 27.55-27.61 SWZ przed drugi produkt, bez wpływu na jakość danych, co pozwoli dopuścić do postępowania rozwiązania i niższej cenie?
Odpowiedź:
Zamawiający podtrzymuje postanowienia SWZ.
Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:
„wykrywanie podatności nie może wymagać instalowania dodatkowego oprogramowania poza tym, które wchodzi w skład platformy do monitorowania”.
By spełnić ww. wymaganie system Elastic wymaga integracji z rozwiązaniem firm trzecich. Elastic nie realizuje wykrywania podatności w bibliotekach aplikacyjnych w ramach własnej platformy monitorującej. Spełnienie wymagania wymaga zastosowania i instalacji zewnętrznego oprogramowania.
Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi :
„dla wykrytych podatności prezentować listę wszystkich procesów, które posiadają wykrytą podatność oraz serwerów, na których te procesy działają”.
System Elastic nie zapewnia natywnej funkcjonalności prezentowania listy procesów oraz serwerów dotkniętych wykrytymi podatnościami w bibliotekach aplikacyjnych. Konieczna jest wykluczona przez Zamawiającego integracja z zewnętrznym rozwiązaniem.
Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi:
„dla wykrytych podatności klasyfikować je wg CVSS wraz z uwzględnieniem informacji o ekspozycji na atak z publicznego internetu oraz dostępu do danych”.
Ponownie dla spełnienia wskazanego punktu SOPZ system Elastic musi zostać zintegrowany z rozwiązaniem firm trzecich. System ten nie zapewnia natywnej klasyfikacji podatności aplikacyjnych wg CVSS ani ich oceny w kontekście ekspozycji na atak z publicznego Internetu oraz dostępu do danych. Realizacja wymagania wymaga zastosowania zewnętrznego rozwiązania.
Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi: „dla wykrytych podatnościach prezentować informacje o istnieniu exploitów, które mogą być wykorzystane do ataku”.
System Elastic nie zapewnia natywnej prezentacji informacji o istnieniu exploitów dla wykrytych podatności aplikacyjnych. Konieczna jest zakazana przez Zamawiającego integracja z zewnętrznym rozwiązaniem.
Zgodnie z ww. punktem w zakresie wymagań dotyczących sposobu i zakresu monitorowania systemów, oprogramowanie musi: „dla wykrytych podatności prezentować ich opis oraz sposób remediacji, o ile taki istnieje”.
System Elastic nie zapewnia natywnej prezentacji opisów podatności aplikacyjnych ani zaleceń remediacyjnych. Konieczna jest zakazana przez Zamawiającego integracja z zewnętrznym rozwiązaniem.
Mając na uwadze powyższe, należy stwierdzić, że oferowane rozwiązanie ponownie nie spełnia wymagań OPZ w sposób bezwarunkowy. Kluczowe funkcjonalności SOPZ nie są dostępne natywnie w ramach systemu Elastic i wymagają zastosowania dodatkowych, zewnętrznych narzędzi, co pozostaje w sprzeczności z jednoznacznym stanowiskiem Zamawiającego wyrażonym w odpowiedzi na pytanie nr 38. W konsekwencji oznacza to, że treść oferty jest niezgodna z warunkami zamówienia, co powinno skutkować jej odrzuceniem na podstawie art. 226 ust. 1 pkt 5 Pzp.
D la wykazania okoliczności, o których mowa w punktach 33 - 41 Odwołujący załącza dodatkowo opinię ekspercką wykonaną przez p. J.S., który również jest Certyfikowanym Inżynierem Elastic.
Potwierdza ona fakt, że oferta wykonawcy Linux Polska Sp. z o.o. jest niezgodna z warunkami zamówienia, co powinno prowadzić do jej odrzucenia na podstawie art. 226 ust. 1 pkt 5 Pzp .
Zamawiający 24 kwietnia 2026 r. złożył odpowiedzi na oba odwołania i:
1. Uwzględnił zarzuty nr 4 i 5 odwołania KIO 1646/26, a w pozostałym zakresie wniósł o oddalenie odwołania,
2. wniósł o oddalenie odwołania KIO 1648/26.
Przystępujący Kyndryl wniósł sprzeciw wobec częściowego uwzględnienia przez Zamawiającego odwołanie KIO 1646/26.
Po przeprowadzeniu rozprawy Izba, uwzględniając dokumentację przedmiotowego postępowania o udzielenie zamówienia publicznego, w tym w szczególności treść SWZ, jak również biorąc pod uwagę oświadczenia i stanowiska Stron i Przystępujących zawarte w odwołaniach, odpowiedziach na odwołania i pismach procesowych, a także wyrażone ustnie na rozprawie i odnotowane w protokole, ustaliła i zważyła, co następuje.
Izba odrzuciła odwołanie KIO 1648/26 w zakresie zarzutu nr 1a uznając, że został on wniesiony po upływie ustawowego terminu. Zarzut ten dotyczył przede wszystkim konstrukcji pozacenowego kryterium oceny ofert – większość argumentów podniesionych przez Odwołującego sprowadzało się do faktycznego kwestionowania kryterium „Pozycja w Gartner® Magic Quadrant™ Observability na rok 2025”. Odwołujący kwestionował fakt przyznania punktów ofercie Linux, ale konsekwentnie wskazywał, że kryterium jest wadliwe, więc żadna oferta nie powinna uzyskać punktów w ramach tego kryterium. Uzasadnienie zarzutu zostało przytoczone wyżej w całości – jednoznacznie wynika z niego, że Odwołujący w zarzucie nr 1a w sposób faktyczny zmierza do zmiany zasad punktacji ofert określonych w SWZ, mimo, że postępowanie jest na etapie wyboru najkorzystniejszej oferty.
Izba stwierdziła, że w zakresie pozostałych zarzutów odwołań nie została wypełniona żadna z przesłanek ustawowych skutkujących ich odrzuceniem, wynikających z art. 528 Pzp.
Izba merytorycznie rozpoznała odwołania, uznając, że nie zasługują one na uwzględnienie.
Rozpoznając odwołania Izba przeprowadziła dowody z dokumentacji postępowania, oraz wszystkie wnioskowane przez Strony i Przystępującego dowody z dokumentów. Izba nie znalazła podstaw do pominięcia któregokolwiek z dowodów z dokumentów na podstawie art. 541 Pzp.
Izba ustaliła, co następuje:
KIO 1646/26
Zarzut nr 1 Podstawą zarzutu było twierdzenie Odwołującego Omnilogy o niejednoznacznym sposobie oznaczenia oprogramowania oferowanego przez Przystępującego Linux.
Z dowodów i pism zgromadzonych w sprawie jasno wynika jednak, że żaden z uczestników postępowania nie miał wątpliwości co jest przedmiotem oferty Linux. Odwołujący twierdził, że określenie Elasticsearch jest wieloznaczne, ale nie wykazał jakie jeszcze znaczenia w kontekście przedmiotu zamówienia miałoby mieć to słowo. Izba uznała zatem, że wątpliwości Odwołującego Omnilogy miały wyłącznie charakter taktyczny - na potrzeby podniesienia zarzutu odwołania. Dodatkowym potwierdzeniem tego wniosku jest fakt, że Odwołujący podniósł zarzut niezgodności oferty Przystępującego Linux z warunkami zamówienia. W zarzucie nr 3 Odwołujący wprawdzie podtrzymał twierdzenie o niejednoznacznym charakterze kwestionowanej oferty, ale mimo to był w stanie podnieść precyzyjne, techniczne zarzuty dotyczące oprogramowania zaoferowanego przez Linux.
W konsekwencji Izba oddaliła zarzut uznając, że dla wszystkich uczestników postępowania treść oferty Przystępującego miała jasny i oczywisty charakter.
Zarzut nr 2 W odpowiedzi na ten zarzut Zamawiający wskazał:
„Jak już w wspomniano w punkcie poprzedzającym - Elasticsearch jest powszechnie rozpoznawalną marką technologiczną i handlową, identyfikowaną w branży IT jednoznacznie z produktami spółki Elastic N.V. Skoro Zamawiający bez trudu ustalił, że przedmiotem oferty Linux jest Elasticsearch o poziomie Enterprise firmy Elastic, to nie ulega wątpliwości, że użycie w raporcie „Gartner Magic Quadrant for Observability Platforms 2025” wyrazu „Elastic” oznacza, że chodzi o „platformę do obserwacji” firmy Elastic, czyli właśnie Elasticsearch”.
Argumentacja Odwołującego Omnilogy nawiązuje z kolei do założenia, na którym oparty został zarzut nr 1.
W konsekwencji Izba uznała przytoczone wyżej stanowisko Zamawiającego za zasadne i oddaliła zarzut.
Zarzut nr 3 Zarzut stanowił zbiór twierdzeń Odwołującego Omnilogy – zostały one przytoczone w całości w uzasadnieniu odwołania i nie wymagają ponownego przytoczenia. Co istotne – Odwołujący poprzestał wyłącznie na tych twierdzeniach. Odwołujący nie podjął jednak choćby próby dowiedzenia zasadności tych twierdzeń. W konsekwencji Izba oddaliła zarzut jako gołosłowny i nieudowodniony.
Zarzuty nr 4 i 5 Po przeprowadzeniu dowodu z dokumentacji postępowania Izba uznała, że Odwołujący Omnilogy w uzasadnieniu odwołania w prawidłowy sposób opisał stan faktyczny dotyczący obydwu zarzutów. Izba odstąpiła zatem od własnego opisu stanu faktycznego. W uzupełnieniu wskazać jedynie należy, że Przystępujący Kendryl uzupełnił gwarancję wadialną (Aneks do gwarancji) oraz oświadczenie o wydłużeniu terminu związania ofertą do terminu żądanego przez Zamawiającego.
Zgodnie z art. 554 ust. 1 pkt 1 Pzp Izba uwzględnia odwołanie w całości lub w części, jeżeli stwierdzi naruszenie przepisów ustawy, które miało wpływ lub może mieć istotny wpływ na wynik postępowania o udzielenie zamówienia, konkursu lub systemu kwalifikowania wykonawców. Przepis powyższy miał kluczowe znaczenie dla oddalenia obu omawianych zarzutów. Oferta Przystępującego Kyndryl została sklasyfikowana na drugim miejscu w rankingu ofert, a zarzuty obu odwołań dotyczące oferty Linux zostały oddalone. Czynność wyboru najkorzystniej oferty została zatem utrzymana w mocy.
Uwagi te mają znaczenie w sprawie, ponieważ zarzuty nr 4 i 5 odwołania potwierdziły się, ale zostały oddalone ze względu na brak wpływu na wynik postępowania. Niecelowym jest bowiem unieważnienie wyboru najkorzystniejszej oferty tylko po to, by nakazać Zamawiającemu odrzucenie oferty, która nie została wybrana. Izba podkreśla jednak, że Odwołujący słusznie podniósł, że oferta Przystępującego Kyndryl podlegała odrzuceniu z postępowania na podstawie art. 226 ust. 1 pkt 12 Pzp.
Zgodnie z art. 220 ust. 3-5 Pzp:
3. W przypadku gdy wybór najkorzystniejszej oferty nie nastąpi przed upływem terminu związania ofertą, o którym mowa w ust. 2, zamawiający przed upływem terminu związania ofertą, zwraca się jednokrotnie do wykonawców o wyrażenie zgody na przedłużenie tego terminu o wskazywany przez niego okres, nie dłuższy niż 60 dni.
4. Przedłużenie terminu związania ofertą, o którym mowa w ust. 2, wymaga złożenia przez wykonawcę pisemnego oświadczenia o wyrażeniu zgody na przedłużenie terminu związania ofertą.
5. W przypadku gdy zamawiający żąda wniesienia wadium, przedłużenie terminu związania ofertą, o którym mowa w ust. 2, następuje wraz z przedłużeniem okresu ważności wadium albo, jeżeli nie jest to możliwe, z wniesieniem nowego wadium na przedłużony okres związania ofertą.
Kluczowe znaczenie w sprawie ma interpretacja powyższych przepisów. Stroną inicjującą wydłużenie terminu związania ofertą jest zamawiający. Jego uprawnienie w tym zakresie jest jednokrotne i ograniczone pod względem okresu na jaki termin związania ofertą ma być wydłużony. W tej sprawie Zamawiający wystąpił do wykonawców o wydłużenie terminu o maksymalny, dopuszczalny czas, tj. 60 dni. Przytoczony przepis nie daje wykonawcom swobody, co do sposobu odpowiedzi na wezwanie z art. 220 ust. 3 Pzp – mogą oni wyłącznie pisemnie wyrazić zgodę na wydłużenie terminu związania ofertą w sposób zgodny z żądaniem zamawiającego albo odmówić tej zgody – wprost bądź przez brak odpowiedzi na wezwanie. Skutkiem odmowy wydłużenia terminu związania ofertą jest jej odrzucenie na podstawie art. 226 ust. 1 pkt 12 Pzp.
Żaden przepis Ustawy nie daje jednak wykonawcy uprawnienia do wydłużenia terminu związania ofertą na warunkach innych, niż te narzucone przez zamawiającego w wezwaniu na podstawie art. 220 ust. 3 Pzp.
W tej sprawie Przystępujący Kyndryl nie zastosował się do przedmiotowego wezwania – jego odpowiedź wprawdzie wskazywała na zamiar wydłużenia terminu związania na okres oczekiwany przez Zamawiającego, ale dopiero na późniejszym etapie. Bezpośrednio w odpowiedzi wykonawca wydłużył termin na okres krótszy – do 30 kwietnia, a nie zgodnie z wezwaniem – do 16 maja 2026 r. Fakt ten winien skutkować odrzuceniem jego oferty z postępowania – zgoda na wydłużenie terminu związania ofertą albo ma jednoznaczny charakter albo nie jest zgodą.
Przystępujący wyjaśnił Zamawiającemu, że potrzebuje dodatkowego czasu na aneksowanie gwarancji wadialnej, ale nie wskazał żadnej przyczyny dla której nie był tego w stanie zrobić niezwłocznie. Aneks wydłużający gwarancję wadialną nie jest niczym niezwykłym w postępowaniach o udzielenie zamówienia publicznego, a jego uzyskanie nie wymaga wiele czasu. Dlatego też w ocenie Izby potrzeba takiego aneksu nie uzasadniała oświadczenie o wydłużeniu terminu związania ofertą w sposób niezgodny z oczekiwaniem Zamawiającego.
KIO 1648/26
Zarzut nr 1b odwołania miał charakter ewentualny wobec odrzuconego jako spóźnionego zarzutu nr 1a.
Zarzut nr 1b ma przy tym analogiczny charakter do zarzutu nr 2 odwołania KIO 1646/26. Izba w zakresie uzasadnienia oddalenie tego zarzutu odsyła do zarzutu nr 2 odwołania KIO 1646/26.
Zarzut nr 2 Na potwierdzenie tego zarzutu Odwołujący Kyndryl złożył dowody w postaci opinii certyfikowanych specjalistów. W ocenie Izby dowody te miały jednak charakter opinii prywatnych. Izba nie ma podstaw by kwestionować kwalifikacje osób, które je złożyły, ale wskazuje, że wiarygodność tego rodzaju dowodów w przypadku zarzutu niezgodności oferty z warunkami zamówienia jest niewystarczająca. Niezgodność taka musi być wykazana za pomocą jednoznacznych dowodów, a nie opinii, które ze swej natury mają subiektywny charakter.
W konsekwencji Izba oddaliła zarzut nr 2 uznając go za gołosłowny i nieudowodniony.
O kosztach postępowania odwoławczego orzeczono stosownie do wyniku sprawy na podstawie art. 575 Pzp oraz w oparciu o przepisy rozporządzenia Prezesa Rady Ministrów z 30 grudnia 2020 r. w sprawie szczegółowych rodzajów kosztów postępowania odwoławczego, ich rozliczania oraz wysokości i sposobu pobierania wpisu od odwołania (Dz. U. z 2020 r. poz. 2637).
Mając powyższe na uwadze, orzeczono jak w sentencji.
Przewodniczący ……………………………………………..............
Inne spory tego zamawiającego
- KIO 1726/26oddalone19 maja 2026
- KIO 1735/26uwzględnione19 maja 2026
- KIO 1874/26oddalone18 maja 2026
- KIO 1391/26umorzenie postępowania30 kwietnia 2026
- KIO 497/26umorzenie postępowania18 marca 2026
- KIO 825/26umorzenie postępowania17 marca 2026