Wyrok KIO 3812/24

Postępowanie o udzielenie zamówienia w trybie przetargu nieograniczonego pn. „Dostawa infrastruktury i oprogramowania na potrzeby środowisk wytwórczych (3 części)” ogłoszono w Dzienniku Urzędowym Unii Europejskiej pod nr 233807- 2024 z 19 kwietnia 2024 r.

4 października 2024 r. zamawiający poinformował o wyniku postępowania.

14 października 2024 r. Comarch Polska spółka akcyjna z siedzibą w Krakowie wniósł odwołanie przez pełnomocnika działającego na podstawie pełnomocnictwa z 14 października 2024 r. udzielonego przez wiceprezesa i członka zarządu.

Do odwołania dołączono dowód jego przekazania zamawiającemu oraz wniesienia wpisu.

Zamawiającemu odwołujący zarzucił naruszenie:

1. art. 226 ust. 1 pkt 5 ustawy oraz art. 16 pkt 1 ustawy przez zaniechanie odrzucenia oferty ESKOM IT Sp. z o.o. (dalej „ESKOM”) pomimo, że oferta tego wykonawcy jest niezgodna z warunkami zamówienia, a wybór oferty tego wykonawcy jako najkorzystniejszej narusza zasadę prowadzenia postępowania z zachowaniem uczciwej konkurencji i równego traktowania wykonawców; 2.art. 109 ust. 1 pkt. 10 ustawy przez zaniechanie wykluczenia wykonawcy ESKOM IT pomimo że wykonawca ten w wyniku lekkomyślności lub niedbalstwa przedstawił informacje wprowadzające w błąd, co mogło mieć (i miało) istotny wpływ na decyzje podejmowane przez zamawiającego w postępowaniu o udzielenie zamówienia; 3.art. 226 ust. 1 pkt 5 ustawy oraz art. 16 pkt 1 ustawy przez zaniechanie odrzucenia oferty Data Experts Sp. z o.o. (dalej „Data Experts”) również na innych, niż wskazane przez zamawiającego podstawach, pomimo, że oferta tego wykonawcy jest niezgodna z warunkami zamówienia, a zaniechanie odrzucenia oferty tego wykonawcy na wskazanej podstawie narusza zasadę prowadzenia postępowania z zachowaniem uczciwej konkurencji i równego traktowania wykonawców; 4.ewentualny, w przypadku nieuwzględnienia zarzutów 1-3, art. 255 pkt. 6 ustawy w zw. z art. 457 pkt 1 ustawy przez zaniechanie unieważnienia postępowania, pomimo że postępowanie obarczone jest niemożliwą do usunięcia wadą uniemożliwiającą zawarcie niepodlegającej unieważnieniu umowy w sprawie zamówienia publicznego.

Wniósł o nakazanie zamawiającemu:

1. unieważnienie czynności badania i oceny ofert; 2.unieważnienie czynności wyboru oferty ESKOM IT; 3.powtórzenie czynności oceny i badania ofert, zgodnie z przepisami ustawy oraz SWZ; 4.odrzucenie oferty ESKOM IT na podstawie art. 226 ust. 1 pkt 5 ustawy ze względu na brak spełnienia wymagania określonego w § 7 ust. 10 pkt. 5 Rozdziału III SW Z – PPU dla Części 1 w zw. z pkt. IX Rozdziału II – Opis przedmiotu

zamówienia Część 1, to jest możliwości dotrzymania Czasu Reakcji w przypadku Awarii Krytycznej Oprogramowania - 1 h od chwili Zgłoszenia; 5.wykluczenie wykonawcy ESKOM IT z postępowania na podstawie art. 109 ust. 1 pkt. 10 ustawy ze względu na wprowadzenie przez tego wykonawcę zamawiającego w błąd, co miało istotny wpływ na decyzje podejmowane przez zamawiającego w postępowaniu o udzielenie zamówienia; 6.odrzucenie oferty Data Experts na podstawie art. 226 ust. 1 pkt 5 ustawy z uzupełnioną podstawą odrzucenia (ze względu na brak spełnienia wymagania określonego w § 7 ust. 10 pkt. 5 Rozdziału III SW Z – PPU dla Części 1 w zw. z pkt. IX Rozdziału II – Opis przedmiotu zamówienia Część 1, to jest możliwości dotrzymania Czasu Reakcji w przypadku Awarii Krytycznej Oprogramowania - 1 h od chwili Zgłoszenia); 7.ewentualnie – w przypadku nieuwzględnienia zarzutów 1-3, unieważnienie postępowania ze względu na fakt, że jest ono obarczone niemożliwą do usunięcia wadą uniemożliwiającą zawarcie niepodlegającej unieważnieniu umowy w sprawie zamówienia publicznego.

W przypadku uwzględnienia przez zamawiającego w całości zarzutów przedstawionych w odwołaniu (art. 522 ust. 1 ustawy), odwołujący żąda od zamawiającego wykonania czynności zgodnych z żądaniami zawartymi w odwołaniu.

Odwołujący wskazał, że ma interes w uzyskaniu zamówienia, ponieważ jest podmiotem zdolnym do jego wykonania, posiadającym w tym zakresie odpowiednie kompetencje i doświadczenie, a także złożył ofertę w tym postępowaniu, która uplasowała się na drugim miejscu w rankingu oceny ofert.

Wskutek zaskarżonych w tym odwołaniu zaniechań zamawiającego odwołujący może utracić możliwość uzyskania zamówienia. W rezultacie w wyniku w/w naruszenia przez zamawiającego przepisów ustawy, odwołujący może ponieść szkodę polegającą na braku uzyskania przedmiotowego zamówienia. Uwzględnienie odwołania otwiera odwołującemu szansę na wybór jego oferty i pozyskanie przedmiotowego zamówienia publicznego. W odniesieniu do wykonawcy Data Expert odwołujący podniósł zarzuty wobec zaniechania odrzucenia oferty tego wykonawcy na dodatkowych (nieuwzględnionych przez zamawiającego podstawach) ze względu na fakt, że z formalnego punktu widzenia możliwe jest, że w toku postępowania odwoławczego wykonawca DATA Expert będzie dążył do przywrócenia swojej oferty do postępowania i w konsekwencji do uzyskania wyższej od odwołującego pozycji w rankingu ofert.

Zamawiający opisał wymagania dla przedmiotu zamówienia w Rozdziale II SW Z (Opis przedmiotu zamówienia), gdzie w pkt. IX na str. 43 określił, że „Pozostałe wymagania zostały opisane w Projektowanych Postanowieniach Umowy, które zawarte są w Rozdziale III SW Z – Projektowane Postanowienia Umowy.”. W § 7 ust. 10 pkt. 5 Rozdziału III SW Z (Projektowane Postanowienia Umowy) Zamawiający określił wymaganie, aby: „Czas Reakcji w przypadku Awarii Krytycznej Oprogramowania wynosił 1 h od chwili Zgłoszenia).” Czas Reakcji, jak to określa § 1 pkt 6 Rozdziału III SW Z, to czas między dokonaniem Zgłoszenia a uzyskaniem potwierdzenia przystąpienia do usunięcia Awarii. Jednocześnie w paragrafie 7 ust. 10 pkt 1 Rozdziału III SW Z zamawiający wymaga, aby dostarczone Oprogramowanie było objęte 36 miesięczną usługą Wsparcia Technicznego, świadczoną przez producenta oprogramowania lub podmiot autoryzowany przez producenta oprogramowania.

Definicja pojęcia „oprogramowanie”, jest określona § 1 pkt 15 Rozdziału III SW Z. W podpunkcie 3 „Oprogramowanie systemu operacyjnego w serwerach obliczeniowych typ 2 wskazane w pkt.VIII.2 ppkt. 1.13 OPZ”. Tym samym zamawiający wymaga, aby oprogramowanie systemu operacyjnego było objęte wsparciem technicznym na zasadach określonych w (§ 7 ust. 10 pkt. 3), czyli czas przystąpienia do usuwania Awarii Krytycznej wynosił maksymalnie 1 godzinę.

Zgodnie z treścią pkt. 13.3 SW Z (Sposób przygotowania oferty) wykonawcy zobowiązani byli do przygotowania oferty przy pomocy „Formularza ofertowego” wg wzoru stanowiącego Rozdział IV do SW Z, udostępnionego przez zamawiającego na Platformie e-Zamówienia (pkt. 13.3.2 SW Z). W Części 1 wykonawcy zobowiązani byli do wypełnienia Załącznika nr 6a do Formularza oferty, zawierającego wykaz parametrów oferowanych lub opis sposobu spełniania wymagań zawartych w OPZ – składany wraz z ofertą w celu potwierdzenia parametrów wymaganych w OPZ.

Jak wynika z załączonego do oferty ESKOM IT wykazu parametrów (Załącznika nr 6a do Formularza ofertowego) Wykonawca ESKOM IT zaoferował w pkt. 1.13.2 (str. 37) licencję (subskrypcję) na oprogramowanie „Red Hat Enterprise Linux Server 9 Standard”. Subskrypcja ta obejmuje również wsparcie techniczne producenta. Subskrypcja zaoferowana przez ESKOM IT nie zapewnia jednak możliwości przystąpienia do usuwania Awarii Krytycznej w czasie 1 godziny.

Przystąpienie do usuwania Awarii Krytycznej w czasie 1 godziny umożliwia wyłącznie licencja „Red Hat Enterprise Linux Server Premium”.

Dowód: Załącznik 6 - zrzutz ekranu wraz z tłumaczeniem strony RedHat SLA https://access.redhat.com/support/offerings/production/sla Dowód: Załącznik 7 - zrzut z ekranu wraz z tłumaczeniem strony RedHat Godziny Pracy https://access.redhat.com/articles/2623321 Dowód: Załącznik 8 – korespondencja mailowa przedstawicieli odwołującego z osobami uprawnionymi do informowania

o warunkach handlowych wsparcia technicznego ze strony RedHat (na potwierdzenie różnic subskrypcji STANDARD vs PREMIUM) ESKOM IT nie jest Autoryzowanym Partnerem RedHat, mogącym świadczyć usługę wsparcia technicznego, ponieważ RedHat nie oferuje partnerom handlowym takiej ścieżki autoryzacyjnej. ESKOM IT może zaoferować bardzo dobre warunki na zakup subskrypcji oraz skutecznie wdrożyć rozwiązania technologiczne i biznesowe w oparciu o oprogramowanie open source RedHat, lecz nie może świadczyć usługi wsparcia technicznego.

Dowód: Załącznik nr 9 - zrzut z ekranu witryny internetowej ESKOM IT.

Tym samym zaoferowanie subskrypcji „Red Hat Enterprise Linux Server 9 Standard” jest jednoznaczne z niespełnieniem wymagania określonego w § 7 ust. 10 pkt. 5 Rozdziału III SW Z (Projektowane Postanowienia Umowy) w zw. z pkt. IX Rozdziału II SW Z (Opis przedmiotu zamówienia) i winno skutkować odrzuceniem oferty wykonawcy ESKOM IT jako niezgodnej z warunkami zamówienia.

Odwołujący podkreślił, że koszty licencji „Red Hat Enterprise Linux Server 9 Standard” oraz licencji „Red Hat Enterprise Linux Server Premium” są oczywiście różne - licencja Premium jest droższa, właśnie ze względu na konieczność zapewnienia wyższych standardów wsparcia technicznego, tzn. szybszego, 60 minut zegarowych, przystąpienia do usuwania awarii krytycznej, w tym w godzinach nocnych oraz w święta.

Dowód: Załącznik nr 10 - ceny subskrypcji STANDARD vs PREMIUM, oferta Exclusive Network - dystrybutora RedHat.

Zaoferowanie przez ESKOM IT innej (tańszej) subskrypcji, niezapewniającej spełnienia wymagań zamawiającego stwarza sytuację, w której oferty są nieporównywalne. Odwołujący zaoferował licencję Premium w celu spełnienia wymagań określonych w § 7 ust. 10 pkt. 5 Rozdziału III SW Z (Projektowane Postanowienia Umowy) w zw. z pkt. IX Rozdziału II SW Z (Opis przedmiotu zamówienia), co spowodowało zwiększenie ceny oferty odwołującego o kwotę 63 833,98 zł.: •cena katalogowa licencji Premium to 3 086,42 EUR (13 395,06 PLN po przeliczeniu na PLN według kursu 4,34 z 12 czerwca 2024 r.), natomiast cena licencji Standard to 1 898,42 EUR netto (8 239,14 PLN po przeliczeniu na PLN według kursu 4,34 z 12 czerwca 2024 r.) •wartość wskazana w ostatniej kolumnie pozycji 2 litery c) oferty odwołującego (odnosząca się do wartości licencji Red Hat Enterprise Linux Server, Premium (Physical or Virtual Nodes), spadłaby z wartości 50 324,22 zł. do kwoty 30 953,83 zł. (obniżyłaby się o 19 370,30 zł.). •koszt usługi instalacji, konfiguracji i uruchomienia dostarczonych Urządzeń i Oprogramowania oraz integracji z Platformą konteneryzacji, wartość wskazana w ostatniej kolumnie pozycji 4 , jako powiązany z wartością licencji, spadłby z wartości 1 263 508,89 zł. na wartość 1 219 045,30 zł. (cena oferty obniżyłaby się o dalsze 44 463,59 zł.); •łącznie odwołujący mógłby zatem zaoferować ofertę tańszą o 63 833,89 zł., a więc w cenie w wysokości 5 336 165,00 zł., co oznaczałoby, że cena oferty odwołującego jest niższa od ceny oferty wykonawcy ESKOM IT (który zaoferował cenę w wysokości 5 344 350,00 zł.).

Tym samym gdyby odwołujący zaoferował taką samą licencję, jaką zaoferował ESKOM IT, Odwołujący byłby na pierwszym miejscu w rankingu oceny ofert. Zaoferowanie przez ESKOM IT licencji niespełniającej wymagań zamawiającego pozwoliło zatem temu wykonawcy na uzyskanie niższej ceny i uplasowanie się na pierwszym miejscu w rankingu ofert.

Okoliczność opisana w Zarzucie nr 1 stanowi również podstawę do wykluczenia wykonawcy ESKOM IT z postępowania na podstawie art. 109 ust. 1 pkt. 10 ustawy w zw. z pkt. 2, ppkt. 8.2.6 SW Z, zgodnie z którym: Zamawiający wykluczy również Wykonawcę, w przypadku zaistnienia okoliczności określonych w art. 109 ust. 1 pkt 1, 2, 3, 4, 8 i 10 ustawy Pzp, tj. Wykonawcę, który w wyniku lekkomyślności lub niedbalstwa przedstawił informacje wprowadzające w błąd, co mogło mieć istotny wpływ na decyzje podejmowane przez zamawiającego w postępowaniu o udzielenie zamówienia.

Wykonawca ESKOM IT, deklarując spełnianie wymagań określonych przez zamawiającego w SW Z i OPZ, w tym również tych określonych zgodnie z treścią pkt. IX OPZ w postanowieniach umownych (§7 ust. 10 pkt. 5), wprowadził zamawiającego w błąd, a nie tylko mogło to mieć wpływ na wynik zamówienia – lecz ze względu na wybór oferty tego wykonawcy jako najkorzystniejszej, miało wpływ na decyzję zamawiającego w postępowaniu o udzielenie zamówienia.

Tym samym wykonawca ESKOM IT winien być wykluczony z postępowania na podstawie art. 109 ust. 1 pkt. 10 ustawy w zw. z pkt. 2, ppkt. 8.2.6 SW Z, ponieważ w wyniku lekkomyślności lub niedbalstwa przedstawił informacje wprowadzające w błąd, co mogło mieć istotny wpływ na decyzje podejmowane przez zamawiającego w postępowaniu o udzielenie zamówienia.

Powołał wyrok z dnia 20 lutego 2023 r., sygn. KIO 261/23.

Ze względu na zadeklarowanie przez wykonawcę ESKOM IT licencji na poziomie Standard nie umożliwia spełnienia przez tego wykonawcę wymagania zamawiającego w zakresie czasu reakcji na Awarię Krytyczną na poziomie 1 godziny. Wykonawca ten jednakże zadeklarował, że będzie to możliwe (że wymaganie jest spełnione). Wykonawca wprowadził zatem zamawiającego w błąd, co jednocześnie spowodowało u zamawiającego błędne przekonanie, że

oferta wykonawcy jest zgodna z warunkami zamówienia, a ze względu na kryteria oceny ofert i fakt zaoferowania najniższej ceny, oferta tego wykonawcy została przez zamawiającego uznana za najkorzystniejszą. Złożenie przez wykonawcę ESKOM IT oświadczenia niezgodnego z rzeczywistością było wynikiem co najmniej niedochowania przez tego wykonawcę należytej staranności, wymaganej od wykonawcy jako od profesjonalisty. Jest zatem przejawem lekkomyślności lub niedbalstwa tego wykonawcy i spełnia przesłanki określone w art. 109 ust. 1 pkt. 10 ustawy.

Wykonawca Data Experts zaoferował dokładnie tę samą licencję w celu spełnienia wymagania określonego w pkt. 1.13.2 Załącznika nr 6a do Formularza ofertowego, jaką zaoferował wykonawca ESKOM IT - „Red Hat Enterprise Linux Server 9 Standard”. Również ten wykonawca nie będzie zatem w stanie spełnić wymagania określonego zgodnie z treścią pkt. IX Rozdziału II SW Z (Opisu przedmiotu zamówienia) w § 7 ust. 10 pkt. 5 Rozdziału III SW Z (Projektowane Postanowienia Umowy). Nie będzie bowiem w stanie zagwarantować czasu przystąpienia do usuwania Awarii Krytycznej w ciągu 1 godziny. Dowody na powołaną okoliczność są dokładnie takie same jak w przypadku wykonawcy ESKOM IT, tym samym Odwołujący wniósł o dopuszczenie powołanych w zarzucie nr 1 dowodów również na okoliczność zarzutu zaniechania odrzucenia oferty wykonawcy ESKOM IT na podstawie art. 226 ust. 1 pkt. 5 ustawy - oferta tego wykonawcy jest niezgodna z warunkami zamówienia również ze względu na niemożność spełnienia przez tego wykonawcę wymagania określonego w § 7 ust. 10 pkt. 5 Rozdziału III SWZ (Projektowane Postanowienia Umowy).

Oferta wykonawcy Data Experts winna podlegać odrzuceniu nie tylko na podstawach wskazanych przez zamawiającego, lecz również na podstawie art. 226 ust. 1 pkt. 5 ustawy, z przyczyn wskazanych w omówieniu zarzutu nr 1 (dotyczącego wykonawcy ESKOM IT).

W ocenie odwołującego w przypadku, gdy okoliczności wskazane w zarzucie nr 1 nie będą wystarczające do uznania, że oferta wykonawcy ESKOM IT (oraz wykonawcy Data Experts) podlega odrzuceniu na podstawie art. 226 ust. 1pkt. 5 ustawy (i wykonawcy ESKOM IT nie podlega wykluczeniu ze względu na wprowadzenie zamawiającego w błąd w wyniku lekkomyślności lub niedbalstwa), postępowanie powinno być unieważnione ze względu na obarczenie go niemożliwą do usunięcia wadą, uniemożliwiającą zawarcie niepodlegającej unieważnieniu umowy w sprawie zamówienia publicznego.

Jak odwołujący wskazał w uzasadnieniu zarzutu nr 1, jedynie oferta odwołującego jest ofertą zgodną z warunkami zamówienia (umożliwiającą zachowanie czasu reakcji na poziomie 1 godziny). Wykonawca, do którego stosuje się wyższy miernik staranności (uznaje się go za profesjonalistę), powinien uwzględnić w ofercie taką licencję, która umożliwi usunięcie czasu reakcji na poziomie 1 godziny, tym samym winien zaoferować licencję równoważną do licencji Standard (licencję Premium), zapewniającą spełnianie tych wymagań, tak jak to uczynił odwołujący.

Pozostałe dwie oferty (ESKOM IT oraz Data Experts), jako niezapewniające spełnienia wymagań zamawiającego, są nieporównywalne z ofertą odwołującego. Jak odwołujący wskazał w uzasadnieniu zarzutu nr 1, oferta odwołującego byłaby tańsza od oferty uznanej za najkorzystniejszą w przypadku zaoferowania licencji zaoferowanych przez pozostałych wykonawców, czyli licencji Standard. Jeśli zatem okoliczności te nie mogłyby być uznane za podstawę do odrzucenia ofert wykonawców ESKOM IT i Data Experts, a z pewnością nie mogą być również podstawą do wyboru oferty wykonawcy ESKOM IT jako oferty najkorzystniejszej, a w konsekwencji postępowanie winno być unieważnione ze względu na nieusuwalną wadę w rozumieniu art. 255 pkt 6 ustawy.

Profesjonalny wykonawca powinien uwzględnić wszystkie wymagania zamawiającego opisane w SW Z, a w przypadku, gdy ma wątpliwości co do ich treści – zadać odpowiednie pytania na etapie publikacji SW Z. Dla odwołującego oczywiste było, że należy zaoferować licencję Premium w celu spełnienia wymagań zamawiającego określonych w projektowanych postanowieniach umowy. W przypadku uznania, że wykonawcy uprawnieni byli do zaoferowania subskrypcji na poziomie Standard, odwołujący wniósł o unieważnienie postępowania, gdyż wybór oferty ESKOM IT prowadzić będzie do wyboru oferty niezgodnej z warunkami zamówienia, a więc będzie naruszał dyspozycję art. 226 ust. 1 pkt. 5 ustawy, a złożone oferty będą nieporównywalne, co jest nieusuwalną wadą postępowania, uniemożliwiającą zawarcie umowy niepodlegającej unieważnieniu.

4 listopada 2024 r. zamawiający złożył odpowiedź na odwołanie wnosząc o jego oddalenie w całości. Podkreślił, że odwołujący nadinterpretowuje treść SW Z, w której zamawiający wprost postawił wymóg pkt. 1.13.2 załącznika nr 6a do SW Z, w którym zamawiający wymagał licencji lub subskrypcji na oprogramowanie Red HAT Enterprise Linux Server 9 Standard (Physical or Virtual Nodes) lub równoważne, taki sam wymóg zamawiający zawarł w pkt 1.13.2 OPZ.

Zamawiający zatem w dwóch miejscach dokumentów zamówienia zawarł identyczny wymóg, co do rodzaju wymaganej licencji, która może i powinna być w wariancie Standard. To świadczy o zgodności oferty uczestnika z warunkami zamówienia. Zamawiający nie wymagał także obsługi awarii w wariancie Premium. Zamawiający potwierdził, że cytat zawarty w odwołaniu z postanowień PPU dotyczący czasu reakcji na Awarię Krytyczną był prawidłowy, ale podkreślił, że nie wymagał, aby potwierdzenie przystąpienia do usuwania awarii pochodziło od producenta, nie wskazał też formy i zakresu tego potwierdzenia. Inna rozumienie postanowień PPU zaostrzałoby wymagania postawione w SW Z, do czego zamawiający nie jest uprawniony. Według zamawiającego założenie odwołującego, aby wymóg czasu reakcji miał oznaczać, że w ciągu 1 h od chwili zgłoszenia producent lub autoryzowany przez niego partner przystąpił do określonych

działań, które będą się wiązały z czynnym usuwaniem awarii, jest nieuprawnione. Również tej tezy nie potwierdzają załączone dowody, w tym dowód nr 6 wskazujący na zapewnienie „pierwszej reakcji”. Również dowód nr 8 nie potwierdza, aby w ciągu godziny miało nastąpić przystąpienie przez producenta do usunięcia awarii rozumiane jako fizyczne usuwanie awarii. Zdaniem zamawiającego potwierdzone przez producenta rozumienie funkcjonowania wsparcia technicznego na poziomie Premium zostało przedstawione nie z perspektywy postanowień SW Z, ale z uwzględnieniem sposobu rozumienia tych postanowień przez odwołującego. Postanowienia PPU nie zostały skonstruowane w sposób, który wymagałby od producenta podjęcia precyzyjnie określonych działań mających na celu usunięcie awarii.

Zamawiający w żadnym miejscu nie wskazał jaki ma być wymagany czas naprawy dla usuwania awarii oprogramowania.

Wszystkie te okoliczności zostały pozostawione warunkom wsparcia technicznego, które zgodnie z postanowieniami OPZ mogło zostać zaoferowane w wariancie Standard. Zamawiający nie przewidział z tego tytułu żadnych kar umownych i pozostawił dużą dowolność co do tego jak ma wyglądać reakcja na zgłoszenie awarii oprogramowania. Nie przewidział również z tego tytułu możliwości odstąpienia od umowy lub jej wypowiedzenia. Nawet jeśli uznać, żr postanowienia OPZ w powiązaniu z PPU mogą być różnie interpretowane, to ewentualne nieścisłości w dokumentach zamówienia powinny być interpretowane na korzyść wykonawcy, który złożył ofertę powiązaną z tymi wątpliwościami. W tym miejscu zamawiający powołał orzecznictwo Sądu Najwyższego i KIO. Zamawiający podniósł też, że wymóg czasu reakcji polegający na potwierdzeniu przystąpienia do usuwania awarii jest wymogiem etapu realizacji zamówienia i nie można na etapie ofertowania ustalić, czy nie zostanie dochowany, bo nie jest pewne czy w ogóle wystąpi awaria krytyczna. Powołał orzeczenie KIO. Odnośnie zarzutu zaniechania odrzucenia oferty wykonawcy, który wprowadził zamawiającego w błąd, to z uwagi na to, że zarzut ten oparty był o ten sam stan faktyczny, co zarzut zaniechania odrzucenia oferty niezgodnej z warunkami zamówienia, to zamawiający w całości podtrzymał dotychczasową argumentację. W zakresie zarzutów dotyczących oferty Data Experts, zamawiający podniósł, że oferta ta jest ostatecznie odrzucona i rozszerzenie podstaw odrzucenia tej oferty nie ma wpływu na wynik postepowania.

Odwołujący sam w odwołaniu wskazał, że profesjonalny wykonawca powinien był zaoferować licencję równoważną do licencji Standard – licencję Premium, co w ocenie zamawiającego wskazuje, że licencja Standard jest produktem referencyjnym, zatem nie może podlegać odrzuceniu. Zamawiający uznał, że odwołujący nie udowodnił twierdzeń o tym, że oferta odwołującego byłaby ofertą najtańszą, gdyby nie zaoferował licencji Premium. Zamawiający uznał, że argumentacji odwołującego w zakresie zarzutu ewentualnego zaniechania unieważnienia postępowania jest wewnętrznie sprzeczna, co uniemożliwia racjonalną polemikę.

4 listopada 2024 r. przystępujący w pisemnym stanowisku wniósł o oddalenie odwołania. Wskazał na treści zawarte w jego formularzu ofertowym i podkreślił, że jednoznacznie potwierdzały one, że oferowany produkt jest zgodny z PPU.

Podkreślił, że z postanowień pkt. VIII 2. 1.13 pkt. 1 i 2 wynika, że zamawiający oczekiwał dostawy konkretnego oprogramowania Red NAT Enterprise Linux Server 9 Standard. Odwołujący dokonał w sposób dla siebie korzystny nadinterpretacji par. 7 ust. 10 pkt 3 i 5 PPU pomijając par. 3 ust. 2 i pat. 7 ust. 10 pkt 1 PPU. W ocenie przystępującego z tych postanowień wynika, że obowiązek obsługi zgłoszeń leży po stronie wykonawcy i to on, a nie producent powinien zgłoszenie przyjąć i wykazać stosowaną reakcję w czasie 1 godziny. Zdaniem przystępującego trudno sobie wyobrazić sytuację, w której etap rejestracji i zgłoszenia awarii pozostaje p[oza wiedzą wykonawcy, który z zamawiającym zawarł umowę i z której realizacji będzie rozliczany. Przystępujący wniósł o dopuszczenie dowodu z korespondencji mejlowej z producentem Red Hat na okoliczność wykazania, że producent będzie świadczył usługę wsparcia technicznego przez okres 36 miesięcy. Zdaniem przystępującego dowód nr 6 do odwołania wskazuje wyłącznie na czas reakcji według oferty producenta i w obu wariantach wynosi 1 godzinę przy czym w wersji Standard jest to 1 business hour. Definicja business hour z dowodu nr 7 jest bez znaczenia, skoro reakcja na awarię to zobowiązanie wykonawcy, nie zaś producenta.

Dowód nr 8, opiera się na założeniu, że zgłoszenie i rejestracja awarii, to zobowiązanie producenta, co według przystępującego nie znajduje potwierdzenia w PPU. Argumentacja, co do kosztów licencji Premium jest bez znaczenia z uwagi na wymaganie SW Z zaoferowania licencji Standard. Zaoferowanie licencji równoważnej Premium nie uzasadnia unieważnienia postępowania, bowiem wada kwalifikująca podstawę unieważnienia umowy musi być szczególna i prowadzić do niemożności zawarcia ważnej umowy, czego odwołujący nie wykazał. Z samego faktu błędnego odczytania wymogów SW Z nie można wywodzić konieczności unieważnienia postępowania. Przystępujący nie wprowadził zamawiającego w błąd, a jego oferta odpowiada warunkom zamówienia. Przystępujący złożył jednoznaczne oświadczenie jaką oferuje licencję i była to ta licencja, której wymagał w OPZ zamawiający. Nie ma zatem mowy o wprowadzeniu w błąd.

Stan faktyczny:

Rozdział I Instrukcja dla Wykonawców pkt. 4.2. Wszystkie wymagania określone w Rozdziale II SW Z – Opis przedmiotu zamówienia stanowią wymagania minimalne, a ich spełnienie jest obligatoryjne. Niespełnienie ww. wymagań minimalnych będzie skutkować odrzuceniem oferty na podstawie art. 226 ust. 1 pkt 5 ustawy Pzp, jako niezgodnej z warunkami zamówienia.

Rozdział I pkt. 5. Termin wykonania zamówienia 5.1. w zakresie Części 1 – rozbudowa posiadanych przez Zamawiającego dwóch Platform konteneryzacji OpenShift:

1. licencje na Oprogramowanie zostaną objęte wsparciem technicznym wraz z dostępem do aktualizacji pochodzących z oficjalnego kanału producenta, przez okres 36 miesięcy od dnia podpisania przez strony bez zastrzeżeń Protokołu odbioru jakościowego.

Rozdział II OPZ III. Definicje:

W Opisie Przedmiotu Zamówienia zwrotom pisanym z wielkiej litery nadaje się znaczenie zawarte w § 1 Umowy – Definicje VII.

Wymagania ogólne

1. W zakresie rozbudowy dwóch Platform konteneryzacji 1.4 Dostarczane przez Wykonawcę licencje na Oprogramowanie muszą być zgodne z warunkami licencyjnymi producentów Oprogramowania. Odpowiedzialność w tym zakresie spoczywa na Wykonawcy, a wszelkie niezgodności i roszczenia wynikające z niewłaściwego licencjonowania oprogramowania pokrywa Wykonawca. W takim przypadku Wykonawca na własny koszt będzie zobowiązany uzupełnić liczbę lub rodzaj licencji.
2. 7 Wykonawca jest zobowiązany do przekazania Zamawiającemu aktualnego zestawienia w formacie *.xlsx wszystkich dostarczonych pozycji w zakresie Oprogramowania zawierającego informacje m.in. dotyczące numeru partii, pełną nazwę produktu, metrykę licencyjną, wersję i edycję oprogramowania, rodzaj licencji, okres obowiązywania licencji lub subskrypcji, okres obowiązywania wsparcia technicznego, poziom wsparcia technicznego, minimum jeden dzień roboczy przed wyznaczonym terminem dostawy.
3. Warunki dostawy 2.6. Wykonawca zobowiązany jest dostarczyć: licencje Zamawiającemu wraz wykazem urządzeń na adres e-mail który zostanie wskazanym w umowie.
4. 7. Dokument potwierdzający Oprogramowania potwierdzające dostawę licencji i objęcie ich wsparciem technicznym na poziomie zgodnym z wskazanym w OPZ; 2.8. Adresy poczty elektronicznej, nr telefonów oraz dane dostępowe do portalu klienckiego, umożliwiające Zamawiającemu korzystanie z Wsparcia technicznego świadczonego przez producenta Oprogramowania w pełnym zakresie; 2.9. Dokumenty licencji na Oprogramowanie, w tym certyfikaty licencji lub subskrypcji wystawione przez producenta;
5. Serwery obliczeniowe typu 2 sztuk: 6 (po 3 serwery do każdej z Lokalizacji) 1.13. Oprogramowanie systemu operacyjnego dla serwerów 1.13.1. Oprogramowanie musi być w pełni kompatybilne z dostarczanymi serwerami typu 2 i ich podzespołami 1.13.2. Licencja lub subskrypcja na oprogramowanie „Red Hat Enterprise Linux Server 9 Standard (Physical or Virtual Nodes)” lub równoważne, pozwalająca na uruchomienie dwóch systemów wirtualnych (po jednym per Data Center) „Red Hat Enterprise Linux 9” na których zostanie zainstalowane repozytorium obrazów „RedHat Quay”, które posiada zamawiający, wraz z wsparciem technicznym i dostępem do aktualizacji na okres równy okresowi wsparcia dostarczanych serwerów.

IX. Pozostałe wymagania zostały opisane w Projektowanych Postanowieniach Umowy, które zawarte są w Rozdziale III SWZ – Projektowane Postanowienia Umowy.

Rozdział III Projektowane Postanowienia Umowy (dalej PPU) par. 1 Definicje

1. Awaria Krytyczna - Nieprawidłowe działanie powodujące całkowity brak możliwości korzystania z dostarczonych Urządzeń lub Oprogramowania albo takie ograniczenie możliwości korzystania z Urządzeń lub Oprogramowania, które skutkuje brakiem możliwości realizowania ich podstawowych funkcji.
2. Czas Naprawy - Czas między dokonaniem Zgłoszenia a usunięciem Awarii.
3. Czas Reakcji - Czas między dokonaniem Zgłoszenia a uzyskaniem potwierdzenia przystąpienia do usunięcia Awarii.
4. Dni Robocze - Dni od poniedziałku do piątku od godz. 9:00 do godz. 17:00, z wyłączeniem dni ustawowo wolnych od pracy na terenie Rzeczpospolitej Polskiej.
5. Oprogramowanie - Całość lub dowolny element oprogramowania dostarczanego wraz z Urządzeniami przez Wykonawcę. W skład Oprogramowania wchodzi:
6. Oprogramowanie wbudowane w Urządzenia wraz z oprogramowaniem do zarządzania Urządzeniami – w serwerach obliczeniowych typu 1 i 2 wskazane w pkt. VIII OPZ;
7. Oprogramowanie konteneryzacji – Oprogramowanie RedHat OpenShift Platform Plus (Bare Metal Node ) lub równoważne – w serwerach obliczeniowych typ 1 wskazane w pkt.VIII.1 ppkt. 1.13 OPZ;
8. Oprogramowanie systemu operacyjnego w serwerach obliczeniowych typ 2 wskazane w pkt.VIII.2 ppkt. 1.13 OPZ;
9. Oprogramowanie do wirtualizacji serwerów obliczeniowych typ 2 wskazane w pkt.VIII.2 ppkt. 1.14 OPZ; lub inne Oprogramowanie niezbędne do prawidłowego funkcjonowania Platformy konteneryzacji
10. Wsparcie Techniczne - Usługi wsparcia technicznego świadczone przez producenta Urządzeń lub podmiot autoryzowany przez producenta zgodnie z § 7 Umowy i OPZ.
11. Zgłoszenie - Poinformowanie o wystąpieniu Awarii. Za moment Zgłoszenia przyjmuje się dzień i godzinę poinformowania przez Zamawiającego o Awarii przez jeden ze wskazanych Umowie kanałów komunikacji. Jeżeli Awaria została zgłoszona więcej niż jednym kanałem, za moment Zgłoszenia uznaje się to Zgłoszenie, które zostało dokonane wcześniej. § 2 Przedmiot umowy
12. W celu uniknięcia wątpliwości przyjmuje się, że jeżeli Strony nie zdefiniowały danego działania niezbędnego do prawidłowej realizacji Umowy jako obowiązku Zamawiającego, a zobowiązanie takie nie wynika z obowiązujących przepisów prawa lub nie jest w sposób oczywisty zobowiązaniem Zamawiającego, Stroną zobowiązaną do wykonania takiego działania jest Wykonawca. par. 3 Termin wykonania umowy
13. Wykonawca zobowiązuje się do zapewnienia Gwarancji i Wsparcia Technicznego przez okres 36 miesięcy od dnia podpisania przez Strony bez zastrzeżeń Protokołu Odbioru Jakościowego. § 5 Dostawy oraz odbiór ilościowy
14. Wykonawca wraz z Urządzeniami oraz Oprogramowaniem dostarczy Zamawiającemu do Lokalizacji lub na adres email wskazany w § 16 ust. 1 Umowy
15. dane umożliwiające skorzystanie przez Zamawiającego z pełnego zakresu Gwarancji i Wsparcia Technicznego, w tym co najmniej: numerów telefonicznych, adresów e-mail lub adresu strony i danych dostępowych do dedykowanego portalu do Zgłoszeń. § 7 Gwarancja i wsparcie techniczne [Gwarancja]
16. Odpowiedzialność z tytułu Gwarancji jakości obejmuje zarówno wady powstałe z przyczyn tkwiących w Urządzeniach w chwili dokonania ich odbioru przez Zamawiającego, jak i wszystkie inne wady fizyczne powstałe z przyczyn, za które gwarant ponosi odpowiedzialność, jeśli wady te ujawnią się w okresie obowiązywania Gwarancji.
17. Serwis gwarancyjny na dostarczone Urządzenia realizowany będzie na następujących zasadach:
18. realizowany każdorazowo w Lokalizacji, w Dni Robocze;
19. Zamawiający jest uprawniony do dokonywania Zgłoszeń w trybie 24 godzin na dobę, 7 dni w tygodniu za pośrednictwem dedykowanego portalu zgłoszeniowego umożliwiającego Zamawiającemu śledzenie statusów Zgłoszeń lub poczty elektronicznej oraz telefonicznie. W przypadku dokonania Zgłoszenia telefonicznie Wykonawca niezwłocznie potwierdzi otrzymanie Zgłoszenia na adres e-mail Zamawiającego.
20. W przypadku odmowy przez producenta lub podmiot autoryzowany przez producenta świadczenia usług w ramach serwisu gwarancyjnego na warunkach zgodnych z Umową, zobowiązanym z tytułu Gwarancji jest Wykonawca. O odmowie świadczenia usług w ramach serwisu gwarancyjnego przez producenta Urządzeń lub podmiot autoryzowany przez producenta, Zamawiający poinformuje Wykonawcę, przy czym nie wyłącza to odpowiedzialności za zapewnienie przez Wykonawcę czasu usunięcia Awarii określonego w ust. 2 pkt 3 powyżej. [Wsparcie Techniczne]
21. W ramach Wsparcia Technicznego dla Oprogramowania Zamawiający wymaga, aby:
22. dostarczone Oprogramowanie było objęte 36 miesięczną usługą Wsparcia Technicznego, świadczoną przez producenta oprogramowania lub podmiot autoryzowany przez producenta oprogramowania polegającą m.in. na zapewnianiu Aktualizacji.
23. Aktualizacje Oprogramowania, w szczególności nowe wersje, wersje aktualnych, wydania uzupełniające, poprawki programistyczne, nie naruszały praw twórców i właściciela praw autorskich oraz nie będą ograniczały praw Zamawiającego oraz Ministra Cyfryzacji do korzystania z tego Oprogramowania.
24. Wsparcie Techniczne dla Oprogramowania było realizowane poprzez obsługę Zgłoszeń drogą elektroniczną lub telefonicznie w języku polskim lub angielskim na zasadach określonych przez producenta.
25. rejestrowanie i zgłaszanie Awarii Oprogramowania było realizowane 24 godziny na dobę, 7 dni w tygodniu, we wszystkie dni w roku, poprzez dedykowany portal zgłoszeniowy umożliwiający Zamawiającemu śledzenie statusów zarejestrowanych Zgłoszeń, e-mail lub nr telefonu, wskazane w Umowie.
26. Czas Reakcji w przypadku Awarii Krytycznej Oprogramowania wynosił 1 h od chwili Zgłoszenia).
27. Obsługa Awarii Oprogramowania była świadczona na zasadach określonych przez producentów tego Oprogramowania.
28. Wykonawca zapewnił elektroniczny dostęp do informacji (bazy wiedzy) w języku polskim lub angielskim na temat posiadanego Oprogramowania, wykazu znanych symptomów i rozwiązań w języku polskim lub angielskim (w tym programy korygujące do oprogramowania) biuletynów technicznych, dokumentacji technicznych poprawek błędów i zabezpieczeń, dostęp do źródeł, kodów binarnych, dokumentacji oprogramowania oraz bazy danych zgłoszonych problemów technicznych przez 24 godziny na dobę, 7 dni w tygodniu - pod wskazanym przez Wykonawcę portalem producenta. Dodatkowo portal powinien umożliwiać: a) dostęp do bazy wiedzy zawierającej rozpoznane i rozwiązane problemy, artykuły eksperckie oraz pełną dokumentację techniczną; b) pobieranie i użytkowanie aktualizacji i poprawek Oprogramowania.
29. dostarczone przez Wykonawcę Aktualizacje Oprogramowania były wolne od mechanizmów celowo blokujących jego funkcje i wolne od wirusów, koni trojańskich, robaków i innych szkodliwych programów. Wykonawca zobowiązuje się do świadczenia usług Wsparcia Technicznego w sposób zapobiegający utracie danych, do których będzie miał dostęp w czasie świadczenia wsparcia.
30. warunki licencji i warunki Wsparcia Technicznego pozostały niezmienne przez cały okres obowiązywania Umowy w przedmiotowym postepowaniu.

Wyjaśnienia z 17 maja 2024 r.

Pytanie 6 Dotyczy - ROZDZIAŁ II – OPIS PRZEDMIOTU ZAMÓWIENIA CZĘŚĆ 1 W rozdziale VII. „Wymagania ogólne:”, pkt. 1.10 „Zamawiający nie dopuszcza dostarczenia licencji dla Oprogramowania w formie upgrade’u, licencji czasowej typu Trial, OEM Czy ppkt. 1.10 należy interpretować w taki sposób, iż niedopuszczalne jest zaoferowanie oprogramowania w wersji Trial, oraz że niedopuszczalne jest zaoferowanie oprogramowania w wersji OEM z niepełnym wsparciem producenta oprogramowania (tylko poziom L3)?

ODPOWIEDŹ:

Zamawiający wyjaśnia, że Oprogramowanie musi być dostarczone wraz z pełnym wsparciem producenta oprogramowania. Zamawiający potwierdza, że niedopuszczalne jest zaoferowanie oprogramowania w wersjach licencji:

Upgrade’u licencji, Trial, OEM, z niepełnym wsparciem producenta oprogramowania ograniczonego do poziomu L3.

Oferta Eskom:

Załącznik nr 6a 1.13.2. Licencja lub subskrypcja na oprogramowanie „Red Hat Enterprise Linux Server 9 Standard (Physical or Virtual Nodes)” lub równoważne, pozwalająca na uruchomienie dwóch systemów wirtualnych (po jednym per Data Center) „Red Hat Enterprise Linux 9” na których zostanie zainstalowane repozytorium obrazów „RedHat Quay”, które posiada zamawiający, wraz z wsparciem technicznym i dostępem do aktualizacji na okres równy okresowi wsparcia dostarczanych serwerów Spełnia Oferta zawiera licencję (subskrypcję) na oprogramowanie „Red Hat Enterprise Linux Server 9 Standard (Physical or Virtual Nodes)” pozwalającą na uruchomienie dwóch systemów wirtualnych (po jednym per Data Center) „Red Hat Enterprise Linux 9” na których zostanie zainstalowane repozytorium obrazów „RedHat Quay”, które posiada zamawiający, wraz z wsparciem technicznym i dostępem do aktualizacji na okres równy okresowi wsparcia dostarczanych serwerów Oferta Data Expert:

Załącznik nr 6a 1.13.2. Licencja lub subskrypcja na oprogramowanie „Red Hat Enterprise Linux Server 9 Standard (Physical or Virtual Nodes)” lub równoważne, pozwalająca na uruchomienie dwóch systemów wirtualnych (po jednym per Data Center) „Red Hat Enterprise Linux 9” na których zostanie zainstalowane repozytorium obrazów „RedHat Quay”, które posiada zamawiający, wraz z wsparciem technicznym i dostępem do aktualizacji na okres równy okresowi wsparcia dostarczanych serwerów.

Spełnia Subskrypcja „Red Hat Enterprise Linux Server 9 Standard (Physical or Virtual Nodes)” Dowody odwołującego:

Dowód nr 6 do odwołania- wydruk ze strony REDHAT Customer Portal z tłumaczeniem, z którego wynika, że w pakiecie Standard czas reakcji 1 stopnia na odpowiedź początkową i bieżącą wynosi 1 h roboczą, a pakiecie premia czas reakcji 1 stopnia pierwsza reakcja – 1 h i trwająca odpowiedź 1 h lub zgodnie z ustaleniami.

Dowdó nr 7 do odwołania- wydruk ze strony REDHAT Customer Portal:

Jak Red Hat definiuje standardowe godziny pracy? Red Hat stosuje ogólnie zaakceptowaną praktykę, że Standardowe

Godziny pracy są od 9:00 do 18:00 czasu lokalnego dla Ameryki Północnej lub 9:00 do 17:00 (0900-1700) dla Ameryki Północnej. Standardowe godziny pracy nie obejmują weekendów ani lokalnych świąt państwowych.

Obliczanie standardowych godzin pracy odbywa się według lokalizacji w portalu klienta Red Hat (czasami nazywanym identyfikatorem RHN). Na przykład, jeśli klient jest w Nowym Jorku i ma ustawione konto w Portalu Klienta z poprawnymi informacjami o adresie, to Standard Business Hours będą godzinami 9:00-18:00 EST lub EDT, w zależności od pory roku.

Jak to działa w praktyce? Jeśli klient z Ameryki Północnej skontaktował się z regionalnym biurem wsparcia Red Hat o 17:45 (17:45) czasu lokalnego z krytyczną awarią systemu, a klient ma standardową obsługę, to początkowa odpowiedź SLA dla krytycznego problemu Severity 1 to 1 godzina pracy. Ponieważ koniec lokalnego dnia roboczego to 18:00 (18:00), klient może otrzymać odpowiedź do dnia następnego dnia roboczego. Jeśli to wydarzenie miało miejsce w piątek i poniedziałek, jest to lokalne święto, sprawa nie zostanie ponownie rozwiązana, dopóki nie zostanie wznowione normalne godziny pracy.

Dowód nr 8 do odwołania- z korespondencji mejlowej pomiędzy K.S., a A.J. wynika, że Pan K.S. na podstawie otrzymanej od A.J. dokumentacji oczekiwał :

Proszę potwierdzić bądź mnie poprawić. Doszedłem do następujących wniosków po analizie przesłanych przez Panią informacji.

Aby wsparcie techniczne oprogramowania było realizowane w reżimie 7/24 (siedem dni w tygodniu włącznie ze świętami przez 24 godziny na dobę) z czasem reakcji dla Awarii Krytycznej wynoszącym 1 (jedna) godzina zegarowa musi to być wsparcie techniczne na poziomie Premium.

Poziom Standard nie jest wystarczający, gdyż nawet dla Awarii Krytycznej świadczenie usługi wsparcia jest realizowane od poniedziałku do piątku, z wyłączeniem świąt, w godzinach od 9:00 do 17:00. Czas reakcji wynosi 1 godzinę biznesową czyli reakcja na zgłoszenie w piątek o 16:30 przypadnie nie później niż w poniedziałek o 9:30. Oczywiście o ile nie jest to Lany Poniedziałek Świąt Wielkiej Nocy bo wtedy upłynie we wtorek o 9:30.

Musi być to Poziom Premium, gdyż ten poziom dla Awarii Krytycznej oferuje usługę wsparcia w reżimie 7/24 (siedem dni w tygodniu włącznie ze świętami przez 24 godziny na dobę) i czas reakcji dla Awarii Krytycznej to jedna godzina zegarowa. Czyli dla zgłoszenia w niedzielę o 3:00 rano czas reakcji upływa w tę samą niedzielę 60 minut później czyli o 4:00 rano.

A.J. wyjaśniła: zgadza się. Takie są różnice pomiędzy wsparcie Standard a Premium.

Dowód nr 9 do odwołania- Na stronie Eskom strona główna/technologie/Red Hat znajduje się następująca informacja:

Red Hat ESKOM jest Partnerem firmy Red Hat – rynkowego lidera w dziedzinie rozwoju oprogramowania z rodziny open source przeznaczonego dla przedsiębiorstw i organizacji. Dzięki posiadanemu statusowi partnerskiemu oraz umiejętnościom naszych inżynierów, ESKOM może zaoferować bardzo dobre warunki na zakup subskrypcji oraz skutecznie wdrożyć rozwiązania technologiczne i biznesowe w oparciu o open source.

Warto nadmienić, że rozwiązania oznaczone znakiem Red Hat cieszą się bardzo wysokim poziomem zaufania – w mniejszym lub większym zakresie używa ich około 90 proc. firm umieszczonych na liście Fortune 500.

Dowód nr 10 do odwołania- Z oferty dla odwołującego od Exclusive Networks wynika, żeRH00004F3 Red Hat Enterprise Linux Server, Standard (Physical or Virtual Nodes) kosztuje € 1 898,42, a RH00003F3 Red Hat Enterprise Linux Server, Premium (Physical or Virtual Nodes) - € 3 086,42 Dowód nr 1 na rozprawie – kalkulacja kosztów wdrożenia projektu dla COI – KIO oceniła dowód jako nieprzydatny dla rozstrzygnięcia, gdyż nie wskazuje on która z kalkulacji dotyczy licencji Premium, a która Standard, nadto nie można ustalić, dlaczego wykazany w dowodzie nr 10 do odwołania koszt licencji przekłada się dodatkowo na inne koszty wskazane w pkt 1.8 str. 5 odwołania, Dowód nr 2 na rozprawie – korespondencja mejlowa pomiędzy W.F. a R.K., z której wynika, że Pan R.K. przed zadaniem pytań poinformował, że w wymaganiach klienta jest Czas Reakcji: w przypadku Awarii Krytycznej Oprogramowania wynosił 1 h od chwili Zgłoszenia oraz, że Czas Reakcji – czas między dokonaniem Zgłoszenia, a uzyskaniem potwierdzenia przystąpienia do usunięcia Awarii. Pytający dodał, że wie, że taki czas reakcji jest oferowany przez RH w usłudze Premium, ale czy biorąc pod uwagę tabele poniżej, istnieje jakiś sposób (umiejętność, zestaw narzędzi), który umożliwiłby mi jako wykonawcy [przystąpić do usuwania Awarii RH Enterprise Linux Server 9 w ciągu godziny? Podkreślił, że nie chodzi mu o odnotowanie w systemie zgłoszeń, że „przystąpienie do usuwania awarii” i czekanie, aż usługę – w skrajnym przypadku weekendu np. po 48h – zacznie w usłudze Standard realizować RH. Chodzi mi o realne przystąpienie do usuwania Awarii tak, żeby ją usunąć lub tak, żeby później usuwanie awarii przejął RH.

Pan F. na następującego pytania udzielił odpowiedzi:

1. Jak zapewnić 1 godzinny (60 minut zegarowych) czas reakcji, 24/7 dla systemu operacyjnego Red HAT Enterprise Linux, dla awarii krytycznych?

Aby zapewnić taki poziom wsparcia niezbędna jest subskrypcja Premium.

1. Czy jest możliwe spełnienie tego wymagania przy użyciu subskrypcji Standard?

Nie, w szczególności nie ma możliwości wsparcia w weekendy i dni robocze poza godzinami pracy (8/5).

1. Czy firma Red Hat realizuje bezpośrednio wsparcie techniczne Standard i Premium dla nabywanych subskrypcji?

Tak, w ramach subskrypcji Red Hat realizuje pełne wsparcie (L1-L3) zarówno dla subskrypcji Standard jak i Premium.

1. Czy istnieje ścieżka certyfikacyjna, po przejściu której partner będzie mógł świadczyć wsparcie techniczne Standard lub Premium?

Taka możliwość występuje tylko w przypadku producentów sprzętów, który realizują wsparcie L1-L2 w ramach subskrypcji OEM. Nie ma takiej możliwości/ścieżki certyfikacyjnej dla partnerów innego typu.

Dowód przystępującego: - korespondencja mejlowa pomiędzy G.W., a R.B. z 31 października 2024 r. z której wynika, że G.W. potwierdził, że zarówno produkt Red Hat Enterprise Linux Server 9 Standard jak i Red Hat Enterprise Linux Server 9 Premium zapewniają dostęp do dokładnie takich samych funkcjonalności. Dodatkowo w przypadku wykupienia subskrypcji Red Hat jest zobligowany do świadczenia wsparcia zgodnie z warunkami kontraktowymi.

Dowody:

KIO przyjęła w poczet materiału dowodowego dowody odwołującego dołączone do odwołania i złożone na rozprawie, dokumentację postępowania o udzielenie zamówienia przekazaną przez zamawiającego, dowód złożone przez przystępującego na rozprawie. KIO oparła się głównie na dokumentacji postępowania, gdyż istota sporu sprowadzała się do ustalenia treści SW Z i postawionych przez zamawiającego warunków zamówienia. Uzupełniająco KIO wzięła pod uwagę korespondencję mejlową dotyczącą zasad licencjonowania przez Red HAT złożoną przez odwołującego i przystępującego.

Rozważania KIO:

Krajowa Izba Odwoławcza (dalej KIO) uznała, że odwołanie nie zasługuje na uwzględnienie tak w zakresie zarzutów podstawowych jak i zarzutu ewentualnego i oddaliła odwołanie w całości. KIO w całej rozciągłości podziela pogląd odwołującego, że warunki zamówienia określone tak w SW Z, OPZ jak i PPU powinny być jednoznaczne, traktowane jako równie ważne, przestrzegane przez wykonawców przy składaniu ofert, jak i przestrzegane przez zamawiającego przy ocenie tych ofert. KIO podziela także pogląd zamawiającego i uczestnika, że niejednoznaczności warunków zamówienia, jeśli w danych dokumentach zamówienia wystąpią nie mogą być wykładane na niekorzyść wykonawcy, który się do nich zastosował. KIO podziela także stanowisko zamawiającego i uczestnika, że nie jest podstawą do unieważnienia postępowania okoliczność, że wykonawcy różnie rozumieli tę samą treść dokumentów, o ile możliwe jest ustalenie, które odczytanie dokumentów było prawidłowe w świetle postanowień dokumentacji lub wykładni językowej tej dokumentacji prowadzącej do ustalenia rozumienia SWZ.

W ocenie KIO istota problemu w tej sprawie sprowadzała się do ustalenia czy SW Z określa, kto udziela zamawiającemu potwierdzenia przystąpienia do usuwania awarii.

Aby odpowiedzieć na tak postawione pytanie trzeba przeanalizować postanowienia SW Z. I tak z rozdziału I pkt. 4.2 SW Z wynika, że zamawiający określił, które wymagania ocenia jako obligatoryjne warunki zamówienia, których nie spełnienie spowoduje odrzucenie oferty na podstawie art. 226 ust. 1 pkt 5 ustawy. Zamawiający wyraźnie wskazał, że „Wszystkie wymagania określone w Rozdziale II SW Z – Opis przedmiotu zamówienia stanowią wymagania minimalne, a ich spełnienie jest obligatoryjne. Niespełnienie ww. wymagań minimalnych będzie skutkować odrzuceniem oferty na podstawie art. 226 ust. 1 pkt 5 ustawy, jako niezgodnej z warunkami zamówienia.” Wymóg ten można zatem odczytać w ten sposób, że tylko to co postanowiono w rozdziale II SW Z ma być potwierdzone w treści oferty, a warunki zamówienia określone w innych dokumentach nie są dla zamawiającego na tyle znaczące, aby odrzucać z tego powodu ofertę. To wskazywałoby na to, że należało zaoferować jak minimalny poziom licencjonowania Red Hat Enterprise Linux Server 9 Standard, bo takie wymaganie wynikało z pkt. VIII.2.1.13.2. Dostrzec też należy, że w rozdziale II pkt. III zamawiający nadał znaczenie zwrotom pisanym dużą literą w Opisie przedmiotu zamówienia, zgodnie z par. 1 PPU, tylko, że w pkt.

VIII.2.1.13.2 użył pojęcia „wsparcie techniczne” pisząc je małą literą, tym samym nie było to wsparcie definiowane w par.

1 pkt 26. Zamawiający wprawdzie w Rozdziale II pkt. IX wskazał, że „Pozostałe wymagania zostały opisane w Projektowanych Postanowieniach Umowy, które zawarte są w Rozdziale III SW Z – Projektowane Postanowienia Umowy.”, jednak nie wskazał jak będzie oceniał brak potwierdzenia ich spełnienia na etapie badania i oceny ofert. Już tylko z tego względu wykonawca odczytując pkt. 4.2 rozdziału I oraz pkt VIII.2.1.13.2 rozdziału II mógł odczytać warunki zamówienia w ten sposób, że ma zaoferować wariant Standard jako minimalny, może zaoferować inny wariant pod warunkiem, że spełnia wymagania równoważności opisane w pkt. VIII.2.1.13.3. Czy to oznacza, że wykonawcy nie

powinni byli analizować innych postanowień SW Z, w tym postanowień PPU, oczywiście, że nie. To oznacza tyle, że zamawiający nie mógł odrzucić oferty wykonawcy, który wykazał się spełnienie warunków minimalnych określonych przez zamawiającego. Zamawiający sam taki sposób badania ofert zadeklarował w SW Z i miał obowiązek się go trzymać. Natomiast to nie zmienia faktu, że ustawodawca w art. 7 pkt 29 ustawy zdefiniował warunki zamówienia i objął nimi także projektowane postanowienia umowne, a nie wyłącznie, jak wskazał to w rozdziale I IDW zamawiający obligatoryjne warunki zamówienia – wymagania minimalne. Z tego względu oceniając zaistnienie podstawy odrzucenia oferty w oparciu o przepis art. 226 ust. 1 pkt 5 ustawy zamawiający nie mógł ograniczyć się do jego wąskiego brzmienia nadanego własną SW Z, ale powinien był dokonać badania w odniesieniu do warunków zamówienia zdefiniowanych przez ustawodawcę. Z tego względu Izba dokonała analizy projektowanych postanowień umownych w celu ustalenia wynikających z nich warunków zamówienia. Przechodząc zatem do oceny spornego pomiędzy stronami postanowienia par. 7 ust. 10 pkt 5 PPU i wymagania zamawiającego dotyczącego „Czas Reakcji w przypadku Awarii Krytycznej Oprogramowania wynosił 1 h od chwili Zgłoszenia).”, to należy poczynić następujące uwagi. Definicja Wsparcia Technicznego z par. 1 pkt. 26 PPU nie jest spójna z par. 7 PPU, z którego wynika, że gwarancja jest udzielana na urządzenia, a wsparcie techniczne na oprogramowanie, natomiast z definicji wsparcia technicznego wynika, że Usługi wsparcia technicznego świadczone przez producenta Urządzeń lub podmiot autoryzowany przez producenta zgodnie z § 7 Umowy i OPZ. Ta definicja jest także niespójna w par. 7 ust. 10 pkt 1 PPU, w którym jest mowa o wymaganiu zamawiającego, aby dostarczone Oprogramowanie było objęte 36 miesięczną usługą Wsparcia Technicznego, świadczoną przez producenta oprogramowania lub podmiot autoryzowany przez producenta oprogramowania polegającą m.in. na zapewnianiu Aktualizacji. Zamawiający zatem nie użył konsekwentnie pojęć odnoszących się do podmiotu, który ma świadczyć usługę wsparcia technicznego dla oprogramowania. Z definicji wynika producent urządzeń, z par. 7 ust. 10 pkt 1 producent oprogramowania. Niewątpliwie może być tak, że producent urządzeń może być jednocześnie producentem oprogramowania, ale nie jest to jedyna taka możliwość, zwłaszcza, że zamawiający dopuszczał zaoferowanie rozwiązań równoważnych tak co do oferowanych urządzeń jak i oferowanego oprogramowania. Nie mniej dla KIO nie budzi wątpliwości, że usuwać awarie miał producent, bo wynika to z par. 7 ust. 10 pkt 6 PPU oraz zostało przez odwołującego i przystępującego wykazane korespondencją mejlową z Panem G.W. i panem W.F.. Natomiast spór koncentruje się wokół tego, czy zamawiający wymagał potwierdzenia przystąpienia do usunięcia Awarii od producenta, czy też takie potwierdzenie mogło pochodzić od wykonawcy, a zamawiający nie narzucił jednego modelowego rozwiązania. Na potrzeby odpowiedzi na to pytanie należy wziąć pod uwagę, że zamawiający osobno zdefiniował czas reakcji i czas naprawy :

1. Czas Reakcji - Czas między dokonaniem Zgłoszenia a uzyskaniem potwierdzenia przystąpienia do usunięcia Awarii
2. Czas Naprawy - Czas między dokonaniem Zgłoszenia a usunięciem Awarii.

W par. 7 ust. 10 pkt 5 mowa jest wyłącznie o czasie reakcji. Zamawiający nie oczekiwał i nie określił w ogóle maksymalnego czasu naprawy odmiennie, niż zrobił to w przypadku serwisu gwarancyjnego, gdzie określił zarówno czasy naprawy jak i czasy reakcji różnicując je w zależności od rodzaju awarii. Co więcej jak słusznie zamawiający podnosił w odpowiedzi na odwołanie i na rozprawie, zamawiający nie oczekiwał, że awaria zostanie usunięta w terminie 1h od zgłoszenia, nie przewidział kary umownej za przekroczenie czasu reakcji w ramach wsparcia (w ramach serwisu gwarancyjnego jest przewidziana taka kara umowna).

Natomiast elementami wspólnymi dla serwisu gwarancyjnego i wsparcia technicznego jest jedna definicja Zgłoszenia z par. 1 pkt 27 - Zgłoszenie - Poinformowanie o wystąpieniu Awarii. Za moment Zgłoszenia przyjmuje się dzień i godzinę poinformowania przez Zamawiającego o Awarii przez jeden ze wskazanych Umowie kanałów komunikacji. Jeżeli Awaria została zgłoszona więcej niż jednym kanałem, za moment Zgłoszenia uznaje się to Zgłoszenie, które zostało dokonane wcześniej oraz wymaganie postawione najpierw w par. 5 ust. 6 pkt 4 PPU, gdzie zamawiający wymagał dostarczenia wraz z oprogramowaniem do lokalizacji lub na adres mejllowy podany w par. 16 ust. 1 - dane umożliwiające skorzystanie przez zamawiającego z pełnego zakresu Gwarancji i Wsparcia Technicznego, w tym co najmniej: numerów telefonicznych, adresów e-mail lub adresu strony i danych dostępowych do dedykowanego portalu do Zgłoszeń.

Następnie portal zgłoszeń pojawia się w par. 7 ust. 2 pkt 2 PPU, gdzie serwis gwarancyjny będzie realizowany m. in. w ten sposób, że zamawiający jest uprawniony do dokonywania Zgłoszeń w trybie 24 godzin na dobę, 7 dni w tygodniu za pośrednictwem dedykowanego portalu zgłoszeniowego umożliwiającego Zamawiającemu śledzenie statusów Zgłoszeń lub poczty elektronicznej oraz telefonicznie. W przypadku dokonania Zgłoszenia telefonicznie Wykonawca niezwłocznie potwierdzi otrzymanie Zgłoszenia na adres e-mail Zamawiającego.

Z tego postanowienia wynika, że zgłoszenia nie muszą być dokonywane producentowi urządzeń, a mogą być dokonywane bezpośrednio do wykonawcy, choć zgodnie z par. 7 ust. 4 PPU niewątpliwie serwis gwarancyjny miał być świadczony przez producenta urządzeń lub autoryzowany przez niego podmiot, a dopiero w przypadku odmowy świadczenia tej usługi przez samego wykonawcę. W przypadku par. 7 ust. 10 pkt 4 PPU zamawiający również przewiduje dedykowany portal zgłoszeniowy dla rejestrowania i zgłaszania awarii jak i równorzędne sposoby komunikacji

elektroniczny lub telefoniczny. Przy czym tu zamawiający nie określa, kto ma stworzyć i prowadzić portal, czyje mają być adres poczty elektronicznej czy numer telefonu. Wobec braku takiego dookreślenia zamawiający nie może w ocenie KIO następczo wymagać, aby portal, mejl, czy numer telefonu były danymi pochodzącymi wyłącznie od producenta, jak odczytuje to odwołujący. KIO zauważyła, że zamawiający kiedy oczekuje portalu producenta, to potrafi to wyraźnie wskazać. Tak też uczynił w par. 7 ust. 10 pkt 7 PPU, gdzie wskazał, że Wykonawca zapewnił elektroniczny dostęp do informacji (bazy wiedzy) w języku polskim lub angielskim na temat posiadanego Oprogramowania, wykazu znanych symptomów i rozwiązań w języku polskim lub angielskim (w tym programy korygujące do oprogramowania) biuletynów technicznych, dokumentacji technicznych poprawek błędów i zabezpieczeń, dostęp do źródeł, kodów binarnych, dokumentacji oprogramowania oraz bazy danych zgłoszonych problemów technicznych przez 24 godziny na dobę, 7 dni w tygodniu - pod wskazanym przez Wykonawcę portalem producenta. To oznacza, że w zakresie portalu nazwanego bazą wiedzy portal ten wyraźnie musi być portalem producenta i zamawiający wyłącza w tym zakresie możliwość prowadzenia portalu przez wykonawcę, czego nie uczynił w odniesieniu do portalu zgłoszeniowego.

KIO dostrzegła, że w portalu baza wiedzy jest mowa o bazie danych zgłoszonych problemów technicznych, ale w ocenie KIO, gdyby baza wiedzy musiała łączyć w sobie portal zgłoszeniowy, to pkt. par. 7 ust. 10 pkt 4 PPU byłby zbędny.

Zakładając zaś racjonalność zamawiającego w bazie wiedzy chodzi o dostęp do bazy zgłoszeń wszystkich problemów technicznych, tak aby zamawiający, jeśli dany problem techniczny już w przeszłości u jakiegokolwiek podmiotu wystąpił i został rozwiązany, miał dostęp do takiej wiedzy i mógł samodzielnie problem rozwiązać nie czekając na naprawę awarii w ramach wsparcia technicznego. Potwierdza to również pkt. 5.1 pkt. 5) rozdziału I SW Z, gdzie jest mowa o tym, że licencje na Oprogramowanie zostaną objęte wsparciem technicznym wraz z dostępem do aktualizacji pochodzących z oficjalnego kanału producenta, czyli dostęp do aktualizacji miał pochodzić z oficjalnego kanału producenta.

KIO wzięła pod uwagę jeszcze jedną okoliczność, którą pomija odwołujący, a która w ocenie KIO dodatkowo przemawia za tym, że zamawiający dopuszczał portal zgłoszeniowy prowadzony przez wykonawcę, czy zgłaszanie awarii w ramach wsparcia technicznego mejlem lub telefonicznie do wykonawcy. Zamawiający bowiem pod pojęciem Oprogramowania ukrył różne oprogramowania, które nie koniecznie muszą pochodzić od jednego producenta, na co sam zamawiający wskazuje w definicji Oprogramowania par. 1 pkt. 15, gdzie zamawiający w pkt. 1 wymienia firmware i oprogramowanie do zarządzania urządzeniami, w pkt. 2 oprogramowanie konteneryzacji (dla którego zresztą także wymienia jeden z dwóch możliwych sposobów licencjonowania – bare metal, podobnie jak w przypadku spornego oprogramowania – wariant Standard), w pkt. 3 sporne oprogramowanie systemu operacyjnego, w pkt 4 oprogramowanie do wirtualizacji i każde inne oprogramowanie niezbędne dla prawidłowego funkcjonowania platformy konteneryzacji.

Oczywiście część oprogramowania może pochodzić od jednego producenta i być objęta jednym portalem zgłoszeniowym tego producenta, ale wśród tych oprogramowań nie można wykluczyć, że są i takie, które pochodzą od innych producentów. Wówczas gdyby zamawiający ściśle wymagał portalu dedykowanego zamawiającemu od producentów oprogramowania, mogłoby się okazać, że dla poszczególnych oprogramowań musiałby dokonywać zgłoszeń na różnych portalach. W ocenie KIO zatem nie wskazanie przez zamawiającego na to, kto ma prowadzić portal zgłoszeniowy miało umożliwić także taki model obsługi zamawiającego, w którym portal zgłoszeniowy i inne formy zgłaszania i rejestracji zgłoszeń będą prowadzone przez wykonawcę. O tym, że zamawiający miał świadomość, że oprogramowanie może pochodzić, od różnych producentów świadczy także par. 7 ust. 10 pkt 6 PPU, gdzie zamawiający wprost używa zwrotu „producentów tego Oprogramowania”.

Skoro zamawiający nie wymagał, aby umożliwić mu składanie zgłoszeń awarii bezpośrednio producentowi, nie wymagał aby dedykowany portal i adresy mejlowe i numery telefonów były numerami producenta oprogramowania, to nie można uznać za usprawiedliwioną postanowieniami SWZ tezy odwołującego, że potwierdzenie przystąpienia do usunięcia awarii musi pochodzić od producenta oprogramowania. Oczywiście taki model jest uprawniony na gruncie tej SW Z, ale nie jest to model jedyny, bowiem zamawiający tam, gdzie wymagał portalu producenta, to wprost to napisał, czego nie ma przy portalu zgłoszeniowym, a przy portalu zgłoszeniowym dla serwisu gwarancyjnego wręcz jest mowa o działaniu wykonawcy. Ostatnim argumentem przemawiającym za tym, że wszędzie tam, gdzie zamawiający nie dookreślił czyje są obowiązki, to są to obowiązki wykonawcy, jest norma kolizyjna, którą zamawiający wprowadził w par. 2 ust. 4 PPU:

„W celu uniknięcia wątpliwości przyjmuje się, że jeżeli Strony nie zdefiniowały danego działania niezbędnego do prawidłowej realizacji Umowy jako obowiązku Zamawiającego, a zobowiązanie takie nie wynika z obowiązujących przepisów prawa lub nie jest w sposób oczywisty zobowiązaniem Zamawiającego, Stroną zobowiązaną do wykonania takiego działania jest Wykonawca."

Podsumowując z postanowień KIO wynika, że wymóg z par. 7 ust. 10 pkt 5 PPU mógł być obowiązkiem wykonawcy, jeśli wykonawca zaoferował model prowadzenia przyjmowania i rejestracji zgłoszeń za pomocą własnego dedykowanego portalu zgłoszeń lub własnej poczty elektronicznej lub telefonów.

KIO wskazuje, że z przedstawionych przez odwołującego informacji na temat obsługi zgłoszeń awaryjnych przez producenta Red Hat nie wynika, że subskrypcja Premium gwarantuje zamawiającemu usunięcie awarii w czasie 1

godziny. Przeciwnie, jak słusznie zauważył zamawiający w dowodzie przedstawionym przez odwołującego jest mowa o „Initial response”, czyli pierwszej reakcji, a więc nie jest to wykonanie naprawy, na co wykonanie naprawy. Tym samym przykład odwołującego pękniętej opony na autostradzie w Wielki Piątek i możliwości dojechania przy serwisie Premium do rodziny na święta Wielkanocy nie obrazował faktycznego funkcjonowania oferowanego przez odwołującego modelu licencjonowania. Był on także nieadekwatny do postanowień SW Z, bowiem zamawiający nie przewidział w SW Z maksymalnego czasu naprawy awarii krytycznej w ramach wsparcia technicznego.

Odnosząc się do argumentów podnoszonych przez odwołującego wywodzonych na podstawie Rozdziału II pkt. VII. 2 Warunki dostawy to jest postanowień:

1. 7. Dokument potwierdzający Oprogramowania potwierdzające dostawę licencji i objęcie ich wsparciem technicznym na poziomie zgodnym z wskazanym w OPZ; 2.8. Adresy poczty elektronicznej, nr telefonów oraz dane dostępowe do portalu klienckiego, umożliwiające Zamawiającemu korzystanie z Wsparcia technicznego świadczonego przez producenta Oprogramowania w pełnym zakresie.

To użyte tu pojęcie pełnego zakresu nie dotyczy czasu reakcji, ale poziomów wsparcia. O tym jak zamawiający rozumiał pełen zakres wsparcia świadczą wyjaśnienia treści SW Z z 17 maja 2024 r. udzielone na pytanie 6, na które zamawiający odpowiedział, że Oprogramowanie musi być dostarczone wraz z pełnym wsparciem producenta oprogramowania.

Zamawiający potwierdza, że niedopuszczalne jest zaoferowanie oprogramowania w wersjach licencji: Upgrade’u licencji, Trial, OEM, z niepełnym wsparciem producenta oprogramowania ograniczonego do poziomu L3.

To, że zakres wsparcia odnosi się do poziomów tego wsparcia wyjaśnił również Wojciech F. w korespondencji mejlowej stwierdzając: Tak, w ramach subskrypcji Red Hat realizuje pełne wsparcie (L1-L3) zarówno dla subskrypcji Standard jak i Premium.

Co oznacza, że argumentacja odwołującego, że subskrypcja Standard nie umożliwia zamawiającemu korzystania z wsparcia technicznego świadczonego przez producenta oprogramowania w pełnym zakresie, bo nie zapewnia czasu reakcji producenta na poziomie 1 h zegarowej, nie odnosi się do faktycznie postawionego wymogu SWZ.

W ocenie KIO odwołujący przeczytał postanowienia SW Z, jednak interpretował je w jeden z możliwych sposobów, który pozwolił mu na złożenie oferty spełniającej wymagania SW Z, jednak nie był to model oparty na minimalnych wymaganiach zamawiającego, a w konsekwencji doprowadził do złożenia przez odwołującego droższej oferty. To jednak nie oznacza, że model przyjęty przez uczestnika i Data Experts był modelem nie mającym oparcia w postanowieniach SW Z. Podsumowująco bowiem trzeba podkreślić, że zaoferowanie subskrypcji Standard wypełniało wymagania minimalne z pkt VIII.2.1.13.2 rozdziału II OPZ, a zaoferowanie modelu, w którym obsługą zgłoszeń w tym wystawianiem potwierdzenia przystąpienia do usunięcia awarii będzie zarządzał wykonawca nie było sprzeczne z postanowieniami SW Z. Z tych względów zarzut naruszenia art. 226 ust. 1 pkt 5 ustawy w związku z art. 16 pkt 1 ustawy w odniesieniu do badania ofert obu wykonawców Eskom IT i Data Experts nie potwierdził się, a w odniesieniu do Data Experts jego pozytywne rozstrzygnięcie jak słusznie podnosił zamawiający i tak nie wpływałoby na wynik postępowania, gdyż na datę

orzekania ten wykonawca był ostatecznie odrzucony.

Zarzut naruszenia art. 109 ust. 1 pkt 10 ustawy był zarzutem wynikowym i opartym na założonym przez odwołującego stanie faktycznym, że oferta uczestnika Eskom IT nie spełnia warunków zamówienia, o czym ten wykonawca wiedział wprowadzając zamawiającego w błąd w celu wywołania mylnego przekonania, że oferta jest ofertą zgodną z tymi warunkami. Skoro zatem KIO doszła do przekonania, że postanowienia SW Z odczytywane tak wąsko to jest wyłącznie przez pryzmat postanowień minimalnych wynikających z rozdziału II SW Z, jak i szeroko w odniesieniu do wszystkich postanowień SW Z nie dawały podstaw do ustalenia, że oferta przystępującego jest niezgodna z warunkami zamówienia, to również ten zarzut należało oddalić.

Skoro KIO oddaliła zarzuty podstawowe, to należało przejść do rozpoznania zarzutu ewentualnego czyli zarzutu zaniechania unieważnienia postępowania na podstawie art. 255 ust. 6 ustawy z powodu stworzenia przez zamawiającego warunków do nieporównywalności złożonych ofert. Zarzut ten oparty jest na wskazanym przez odwołującego stanie faktycznym, że oferta odwołującego oferująca subskrypcję Premium jest jedyną ofertą spełniającą wymagania SW Z, a została porównana z ofertami nie spełniającymi tych warunków. W ocenie KIO tak postawiony zarzut nie mógł zasługiwać na uwzględnienie z dwóch powodów:

1. Tak zarysowana wada nie jest wadą, której nie można usunąć na obecnym etapie postępowania, bowiem w przypadku gdyby potwierdził się opisany stan faktyczny, że oferty Eskom IT i Data Experts nie spełniają warunków zamówienia, to wadę można usunąć przez odrzucenie tych ofert z postępowania.
2. Fakt, że odwołujący zdecydował się na jeden z możliwych modeli opisanych przez SW Z i model ten był modelem spełniającym wymagania zamawiającego (zamawiający nie odrzucił oferty odwołującego i ocenił ją jako zgodną z warunkami zamówienia, czego odwołujący nie kwestionuje), ale nie był modelem oparty na minimalnych wymaganiach zamawiającego, nie powoduje, że oferty są nieporównywalne. Sam odwołujący zwracał uwagę, że

subskrypcja Standard i Premium to te same zakresy funkcjonalne, a różnią się sposobem realizacji wsparcia technicznego. Co więcej sam odwołujący wskazywał w odwołaniu, że jego model jest równoważny rozwiązaniu przyjętemu przez pozostałych wykonawców, co w ocenie KIO oznacza, że te oferty były porównywalne. Sam fakt, że model przyjęty przez odwołującego generuje wyższe koszty, które nie pozwoliły mu na uzyskanie zamówienia nie powoduje wady postępowania, która mogłaby przekładać się na późniejsze stwierdzenie nieważności umowy.

1. Odwołujący w odwołaniu, ani na rozprawie nie wskazał jakie przepisy obowiązującego prawa zarzucana zamawiającemu wada narusza w taki sposób, żeby skutkiem wady była nieważność postępowania. Aby unieważnić umowę muszą zajść okoliczności wskazane w 457 ust. 1, czy ust. 5 ustawy. Takich okoliczności odwołujący nie podnosił. Nie wskazał też na przepisy bezwzględnie obowiązujące, których naruszenie przez zamawiającego prowadziłyby do możliwości wystąpienia z żądaniem stwierdzenia nieważności umowy w oparciu o art. 189 kpc – o czym jest mowa w art. 457 ust. 4 ustawy, który w ocenie KIO stwarza podstawę do domagania się stwierdzenia nieważności postępowania o udzielenie zamówienia publicznego także w przypadku zaistnienia wady innej niż wskazane w art. 457 ust. 1 i art. 70(5) kc. Takiej argumentacji jednak w odwołaniu zabrakło.
2. Gdyby przyjąć tok rozumowania odwołującego można byłoby dojść do przekonania, że wykonawcy w tym postępowaniu nie mogli zaoferować rozwiązań równoważnych, czy posiadających parametry wyższe niż minimalne wymagane przez zamawiającego, bo takie oferty nie mogłyby być porównane. To byłoby zaprzeczenie zasadzie konkurencyjności postępowania o udzielenie zamówienia publicznego.

Z tych powodów KIO oddaliła również zarzut ewentualny.

O kosztach postępowania odwoławczego orzeczono na podstawie art. 574 i 575 ustawy, tj. stosownie do wyniku postępowania, z uwzględnienie postanowień Rozporządzenia Prezesa Rady Ministrów w sprawie szczegółowych rodzajów kosztów postępowania odwoławczego, ich rozliczania oraz wysokości i sposobu pobierania wpisu od odwołania z dnia 30 grudnia 2020 r. (Dz.U. z 2020 r. poz. 2437) na podstawie par. 8 ust. 2 pkt. 1 cyt. rozporządzenia zaliczając w poczet kosztów koszty wpisu, koszty wydatków pełnomocnika odwołującego. Skoro zarzuty odwołania nie potwierdziły się, żaden z zaliczonych kosztów odwołującego nie podlegał rozliczeniu.

Przewodnicząca

…………………………