Wyrok KIO KIO 2776/24|KIO 2791/24

Sygn. akt: KIO 2776/24

KIO 2791/24

WYROK

Warszawa, dnia 28 sierpnia 2024 r.

Krajowa Izba Odwoławcza - w składzie:

Przewodniczący: Elżbieta Dobrenko

   Joanna Gawdzik-Zawalska

   Małgorzata Jodłowska

Protokolantka: Aldona Karpińska

po rozpoznaniu na rozprawie w dniu 23 sierpnia 2024 r. odwołań wniesionych do Prezesa Krajowej Izby Odwoławczej:

w dniu 5 sierpnia 2024 r. przez wykonawcę T-Mobile Polska Business Solutions Spółka
‎z ograniczoną odpowiedzialnością z siedzibą w Warszawie (sygn. akt KIO 2776/24)

oraz w dniu 5 sierpnia 2024 r. przez wykonawcę Advatech Spółka z ograniczoną odpowiedzialnością z siedzibą we Wrocławiu (sygn. akt KIO 2791/24)

w postępowaniu prowadzonym przez zamawiającego – Zakład Ubezpieczeń Społecznych

przy udziale:

1.uczestnika po stronie odwołującego w postępowaniu o sygn. akt KIO 2776/24 – wykonawcy Advatech Spółka z ograniczoną odpowiedzialnością z siedzibą we Wrocławiu;

2. uczestnika po stronie zamawiającego w postępowaniu o sygn. akt KIO 2776/24 – wykonawcy Wako Spółka Akcyjna z siedzibą w Gliwicach;

3. uczestników po stronie zamawiającego w postępowaniu o sygn. KIO akt 2791/24:

A.wykonawcy Wako Spółka Akcyjna z siedzibą w Gliwicach;

B.wykonawcy T-Mobile Polska Business Solutions Spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie

orzeka:

1.Oddala odwołanie wniesione w sprawie o sygn. akt KIO 2776/24

2.Umarza odwołanie wniesione w sprawie o sygn. akt KIO 2791/24 w zakresie Zarzutu Nr 4

3.W pozostałym zakresie oddala odwołanie

4.Kosztami postępowania w sprawie o sygn. akt KIO 2776/24 obciąża wykonawcę T-Mobile Polska Business Solutions 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 (słownie: piętnaście tysięcy złotych zero groszy), uiszczoną przez wykonawcę
‎T-Mobile Polska Business Solutions Spółka z ograniczoną odpowiedzialnością
‎z siedzibą w Warszawie tytułem wpisu od odwołania,

4.2.zasądza od wykonawcy T-Mobile Polska Business Solutions Spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie na rzecz zamawiającego Zakład Ubezpieczeń Społecznych kwotę 3.600 zł 00 gr (słownie: trzy tysiące sześćset złotych 00 groszy), stanowiącą koszty postępowania odwoławczego poniesione z tytułu wynagrodzenia pełnomocnika

5.Kosztami postępowania w sprawie o sygn. akt KIO 2791/24 obciąża wykonawcę Advatech Spółka z ograniczoną odpowiedzialnością z siedzibą we Wrocławiu i:

5.1.zalicza w poczet kosztów postępowania odwoławczego kwotę 15.000 zł 00 gr (słownie: piętnaście tysięcy złotych zero groszy), uiszczoną przez wykonawcę
‎Advatech Spółka z ograniczoną odpowiedzialnością z siedzibą we Wrocławiu tytułem wpisu od odwołania,

5.2.zasądza od wykonawcy Advatech Spółka z ograniczoną odpowiedzialnością
‎z siedzibą we Wrocławiu na rzecz zamawiającego Zakład Ubezpieczeń Społecznych kwotę 3.600 zł 00 gr (słownie: trzy tysiące sześćset złotych 00 groszy), stanowiącą koszty postępowania odwoławczego poniesione z tytułu wynagrodzenia pełnomocnika.

‎

Na orzeczenie - w terminie 14 dni od dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu Okręgowego w Warszawie - Sądu Zamówień Publicznych.

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

  …………………………

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

Sygn. akt: KIO 2776/24

KIO 2791/24

U z a s a d n i e n i e

Zakład Ubezpieczeń Społecznych, dalej: „Zamawiający” prowadzi postępowanie o udzielenie zamówieniapn. „Zakup Macierzy dyskowych na platformę MF z możliwością rozbudowy do systemów otwartych”, dalej: „Postępowanie”.

Ogłoszenie o zamówieniu zostało opublikowane w Dzienniku Urzędowym Unii Europejskiej w dniu
‎20 października 2023 r. pod numerem 2022/S 203-639413.

I.KIO 2776/24:

W dniu 5 sierpnia 2024 r. wykonawca T-Mobile Polska Business Solutions Spółka
‎z ograniczoną odpowiedzialnością z siedzibą w Warszawie, dalej: „Odwołujący” wniósł odwołanie wobec niezgodnych z przepisami ustawy czynności i zaniechań Zamawiającego w Postępowaniu.

Odwołujący zarzucił Zamawiającemu, że w toku Postępowania naruszył przepisy:

1.art. 226 ust. 1 pkt 5 Pzp w zw. z art. 16 pkt 1-3 Pzp poprzez zaniechanie odrzucenia oferty złożonej przez Wasko S.A. z siedzibą w Gliwicach, pomimo, że jest ona niezgodna z warunkami zamówienia w zakresie, w jakim:

a.Wasko, wbrew wymaganiu, nie wskazał w załączniku nr 1A do SWZ – Specyfikacja techniczna oferowanych Macierzy Dyskowych nazwy jednego z oferowanych oprogramowań do zarządzania/elementów oprogramowania do zarządzania – „agenta do zarządzania replikacją”, co uniemożliwia weryfikację jego zgodności z wymaganiami Zamawiającego i powoduje, że Zamawiający nie wie co jest przedmiotem oferty,

b.Wasko wskazał oprogramowanie do zarzadzania w sposób, który uniemożliwia jego jednoznaczną identyfikację, a przeprowadzano przez Odwołującego analiza wskazuje, że pod taką nazwą nie występuje oprogramowanie spełniające wymagania Zamawiającego,

c.Wasko nie wskazał w załączniku nr 1A do SWZ – Specyfikacja techniczna oferowanych Macierzy Dyskowych oprogramowania niezbędnego do monitorowania macierzy z poziomu maszyny wirtualnej – oprogramowania do systemu wirtualizacji i oprogramowania systemu operacyjnego maszyny wirtualnej, pomimo że takie rozwiązanie oferował, co jest niezgodne
‎z rozdz. II pkt 34 pkt 3 OPZ,

ewentualnie, gdyby wbrew rozdz. II pkt 34 ppkt 3 OPZ Izba ustaliła, że istniała potrzeba wskazywania w pkt 4 załącznika nr 1A do SWZ licencji do oprogramowania niezbędnego do monitorowania macierzy z poziomu maszyny wirtualnej, art. 226 ust. 1 pkt 5 Pzp w zw. z art. 16 pkt 1 -3 Pzp poprzez zaniechanie odrzucenia oferty złożonej przez Wasko, pomimo że jest ona niezgodna z warunkami zamówienia w zakresie, w jakim Wasko zaoferował rozwiązanie, które wymaga licencji, które udzielane są wyłącznie na czas określony, podczas gdy Zamawiający
‎w rozdz. II pkt 30 OPZ wymagał, aby wszystkie dostarczone licencje udzielone były na czas nieograniczony,

2.art. 239 ust. 1 Pzp w zw. z art. 17 ust. 2 Pzp poprzez zaniechanie dokonania wyboru oferty najkorzystniejszej zgodnie z przepisami ustawy.

Odwołujący wniósł o uwzględnienie odwołania i nakazanie Zamawiającemu:

1.unieważnienie czynności wyboru oferty najkorzystniejszej,

2.powtórzenia czynności badania i oceny ofert z uwzględnieniem zarzutów postawionych
‎w odwołaniu, tj. odrzucenie oferty złożonej przez Wasko,

3.dokonania wyboru ofert najkorzystniejszej.

W uzasadnieniu odwołania w zakresie zarzutu nr 1, Odwołujący wskazał, w załączniku nr 1A do SWZ Specyfikacja techniczna oferowanych Macierzy Dyskowych, który bez wątpienia stanowi treść oferty, Zamawiający wymagał wskazania szeregu informacji na temat oferowanych macierzy dyskowych,
‎w tym w pkt 3 „Oprogramowanie do zarządzania ze wskazaniem nazwy, producenta, sposobu licencjonowania.

W punkcie tym wykonawca Wasko wskazał:

** Pakiet licencji Advanced w tym OpsCenter plus agent do zarzadzania replikacją oraz Hitachi Ops Center Analyzer for MainFrame.

Producent: Hitachi Vantara.

Licencjonowanie: dla każdej pojedynczej macierzy.

Instalacja: Management server (VM- Virtual Machine) plus agent na zOs.

Z oferty Wasko wynika, że do zarządzenia oferowanymi przez niego macierzami, poza „Pakietem licencji Advanced w tym Ops Center” oraz „Hitachi Vantara Center Analyzer for Mainframe” niezbędny jest również „agent do zarządzania replikacją”. Na potrzebę korzystania z „agenta” wskazano również przy sposobie instalacji. Wasko nie podał czym jest „agent do zarządzania replikacją”. Z treści oferty Wasko nie wynika czy „agent” to dodatkowe oprogramowanie, czy jakiś element/moduł oprogramowania. Taki sposób określenia Oprogramowania do Zarządzania nie spełnia wymagań Zamawiającego – Wasko nie wskazał bowiem co najmniej nazwy oferowanego „agenta”. Wasko określił Oprogramowanie do zarządzania opisowo, podając jego funkcję (w zakresie w jakim wskazał na agenta do zarządzania replikacją), bez podania nazwy, której wymagał Zamawiający. Wasko dokonał częściowo opisu oferowanego rozwiązania zamiast wyspecyfikować elementy będące przedmiotem dostawy. Działanie Wasko, w ocenie Odwołującego, można porównać w drodze analogii do sytuacji, gdy w postępowaniu np. na dostawę komputerów osobistych w ofercie wskazano „Microsoft Windows 10 plus system do obsługi poczty elektronicznej” zamiast „Microsoft Windows
‎10 plus Microsoft Outlook wraz z doprecyzowaniem wersji tego oprogramowania” (czyli bez wskazania nazwy oprogramowania do obsługi poczty elektronicznej).

Sposób ukształtowania treści złożonego przez Wasko załącznika 1A do SWZ powoduje, że Zamawiający nie miał możliwości zweryfikowania, czy oferowane Oprogramowanie do Zarządzania, w ramach którego Wasko wskazał „agenta”, spełnia wymaganie podane w OPZ zarówno w zakresie funkcjonalności jak i wymaganego przez Zamawiającego sposobu licencjonowania, gdyż nie wiadomo czym jest „agent”, co wykonawca przez to rozumiał. Zamawiający nie dokonał więc (bo treść oferty mu tego nie umożliwiała) należytej weryfikacji oferty Wasko. Zamawiających z jednej strony, w celu zidentyfikowania przedmiotu oferty wymagał dokładnego wskazania informacji dotyczącej oferowanego Oprogramowania do Zarządzania i wszelkiego innego oprogramowania niezbędnego do realizacji zamówienia,z drugiej zaś zaniechał należytej weryfikacji przekazanych informacji wybierając ofertę, która de facto nie wiadomo co obejmuje.

Tak lakoniczne określenie tego oprogramowania lub jego elementu powoduje, że Zamawiający do momentu dostawy i wdrożenia nie będzie miał wiedzy co otrzyma i za co będzie musiał zapłacić.
‎W dobie coraz częściej zdarzających się incydentów w zakresie cyberbezpieczeństwa i ryzyka ataków wrogich służb, dopuszczenie do zainstalowania w Zakładzie Ubezpieczeń Społecznych niezidentyfikowanego oprogramowania jest co najmniej ryzykowne. Odwołujący zwrócił uwagę że Wasko wskazał w Specyfikacji technicznej oferowanych Macierzy Dyskowych „Pakiet licencji Advanced w tym Ops Center plus agent do zarządzania replikacją”, a więc agent ten nie jest elementem „Pakietu licencji Advanced w tym Ops Center”. Nawet jeżeli jest to element innego oprogramowania, to należało wskazać o jakie oprogramowanie chodzi, aby istniała możliwość weryfikacji. Również w sytuacji, gdy „agent” nie ma oddzielnej nazwy, to wykonawca powinien wskazać w ofercie i opisać oferowanego agenta w sposób umożliwiający Zamawiającemu i pozostałym wykonawcom na zidentyfikowanie tego oprogramowania/elementu oprogramowania jego weryfikację. Skoro Wasko zdecydował się wskazać „agenta” w rubryce dotyczącej Oprogramowania do Zarządzania, to uznał, że jest to kwestia istotna i niezbędna, wobec tego brak jakichkolwiek jakiegokolwiek uzasadnienia, dlaczego tak lakoniczne opisanie przedmiotu oferty zostało zaakceptowane przez Zamawiającego, w sytuacji gdy uniemożliwia to weryfikację zgodności przedmiotu oferty z wymaganiami.

Wasko w Specyfikacji technicznej oferowanych Macierzy Dyskowych wskazał tylko jednego producenta oprogramowania oferowanego oprogramowania do zarządzania – Hitachi Vantara, wobec tego należy przyjąć, że również „agent” jest produktem tego samego producenta. Istotne jest, że
‎w dokumentach publikowanych przez producenta oprogramowania Hitachi brak informacji na temat „agenta do zarządzania replikacją”. Taki element oprogramowania czy oddzielne oprogramowanie nie występuje.

Wobec tego oferta Wasko jest niezgodna z warunkami zamówienia. Pomimo, że Wasko nie przedstawił wymaganych przez Zamawiającego informacji (co najmniej nazwy zaoferowanego „agenta do zarządzenia replikacją”), Zamawiający dokonał wyboru jego oferty, a co za tym idzie bliżej nieokreślonego rozwiązania (w zakresie Oprogramowania do Zarządzania).

Na marginesie Odwołujący zwrócił uwagę, że po upływie terminu składania ofert nie istnieje możliwość doprecyzowania oferty, gdyż stanowiłoby to de facto zmianę jej treści i byłoby sprzeczne z art. 223 ust. 1 in fine Ppz.

W odniesieniu do zarzutu nr 2 odwołania, Odwołujący wskazał, że w wierszu nr 3 załącznika 1A do SWZ dotyczącym oprogramowania do zarządzania, Wasko wskazał m.in. „pakiet licencji Advanced
‎w tym OpsCenter” producenta Hitachi Vantara. Nie podał jednak jednoznacznie, który z pakietów oprogramowania Hitachi został zaoferowany. Pod pojęciem pakiet licencji Advanced może kryć się kilka rodzajów pakietów. W ofercie Hitachi znajdują się bowiem następujące pakiety Advanced: Advanced Package Open System lub Advanced Package Mainframe Systems. Nazwa „pakiet licencji Advanced w tym OpsCenter” nie pozwala stwierdzić, o który z pakietów chodzi. Zgodnie
‎z rozdz. II tabela pkt 26 OPZ Zamawiający wymaga zapewnienia funkcjonalności HyperPAV.
‎Z rozdziału II pkt 14, 15, 17,18, 19 OPZ wynika zaś wymóg zapewnienia replikacji zdalnej. Jedyny pakiet z oferty Hitachi, który zapewnia spełnienie tych wymagań, to Hitachi Vantara Advanced Package Mainframe Systems. Podana w ofercie Wasko informacja – „pakiet licencji Advanced w tym OpsCenter” wskazuje, że oferowany pakiet zawiera oprogramowanie OpsCenter. Oprogramowanie OpsCenter nie jest jednak zawarte w wytypowanym powyżej Advanced Package Mainframe System, czyli jedynym oprogramowaniu Advanced, który zapewnia spełnienie wymagań Zamawiającego
‎w zakresie funkcjonalności HyperPAV i replikacji zdalnej. Oprogramowanie OpsCenter jest zawarte wyłącznie w pakietach oprogramowania dedykowanych dla systemów otwartych – Base Package Open Systems lub Advanced Package Open Systems, które z kolei nie zapewniają spełnienia wskazanych wymagań w zakresie funkcjonalności HyperPAV i replikacji zdalnej.

BASE PACKAGE OPEN SYSTEM zawiera:

 Storage Virtualization Operating System RF (SVOS RF):

Hitachi Universal Volume Manager do wirtualizacji pamięci masowych

Hitachi Local Replication dla kopii migawkowych i pełnych

 Hitachi Data Mobility dla tzw. tieringu pomiędzy różnymi macierzami i typami nośników

- Hitachi OpsCenter:

Ops Center Administrator do prostego zarządzania systemem przez interfejs GUI

Ops Center Analyzer for VM dla uzyskania różnych szczegółów pamięci masowych

Ops Centre Protector ta zarządzania kopiowaniem danych

ADVANCED PACKAGE OPEN SYSTEM zawiera:

Cały pakiet Open Base oraz:

- Storage Virtualization Operating System RF (SVOS RF)

Remote Data Protection do replikacji zdalnej i zabezpieczenia przed katastrofą (tzw. disaster recovery)

Global Active Device dla zapewnienia ciągłości działania biznesu i klastrowania typu metro

Non-Disruptive Migration

-Hitachi Ops Center

 Ops Center Automator dla automatyzacji i orkiestracji procesów

Ops Center Analyzer Predictive Analytics

Oprogramowanie OpsCenter nie zostały ujęte w pakietach Base Package Mainframe Systems lub Advanced Package Mainframe Systems.

BASE Package Mainframe Systems zawiera:

- Storage Virtualization Operating System RF (SVOS RF):

Hitachi Universal Volume Manager do wirtualizacji pamięci masowych

Hitachi Local Replication for Mainframes wykonujący kopie migawkowe i pełne

Hitachi Data Mobility dla tzw. tieringu pomiędzy różnymi macierzami i typami nośników

- Mainframe Analytics Recorder:

Hitachi Business Continuity Manager dla automatyzacji kopii lokalnych

Advanced Package Mainframe Systems zawiera:

Cały pakiet Mainframe Base oraz

-Mainframe Essentials Package

-Storage Virtualization Operating System RF (SVOS RF)

Hitachi Business Continuity Manager Extended dla automatyzacji Remote Data Protection

Remote Data Protection (MF) do replikacji zdalnej i zabezpieczenia przed katastrofą (tzw. disaster recovery)

Non-Disruptive Migration

- Mainframe Analytics Recorder

 Non-Disruptive Migration

-Mainframe Analytics Recorder

Hitachi Business Continuity Manager dla automatyzacji kopii lokalnych

(Informacje dotyczące zawartości pakietów pochodzą z dokumentu „Modern Data Center Software Solutions for Al- driven Operations” dostępnego na stronie internetowej producenta: )

Wobec tego, oferta Wasko jest niezgodna z warunkami zamówienia również z uwagi na błędne wskazanie nazwy Oprogramowania do Zarządzania. Wskazane przez Wasko oprogramowanie do założenia – „pakiet licencji Advanced w tym OpsCenter nie istnieje. Nawet podjęte próby dopasowania tego opisu do któregośz oferowanych przez Hitachi pakietów oprogramowania, okazały się bezskuteczne. Wobec tego Wasko nie będzie w stanie dostarczyć pakietów oprogramowania do zarządzania, które będzie oferowane przez Hitachi, a jednocześnie będzie zgodne z ofertą i będzie zapewniało wymagane przez Zamawiającego funkcjonalności. Jeżeli Wasko uznało, że do realizacji zamówienia niezbędne są oba pakiety - Advanced Package Mainframe Systems oraz jeden
‎z pakietów dla systemów otwartych - Base Package Open Systems lub Advanced Package Open Systems, to powinien wskazać w pkt 3 załącznika numer 1A do SWZ oba oprogramowania. Wykonawca jest zobowiązany do jednoznacznego określenia przedmiotu oferty, w sposób który umożliwi weryfikację jego zgodności z wymaganiami, co w tym przypadku nie jest możliwe.

W odniesieniu do zarzutu nr 3 odwołania, Odwołujący wskazał, że Zamawiający przewidział w rozdz. II punkt 34 OPZ dopuszczalne sposoby zarządzania i monitorowania macierzy. Zgodnie z rozdz. II pkt 34 OPZ:

„W zależności od sposobu zarządzania i monitorowania Macierzy, konieczne jest zaoferowanie minimum jednego z poniższych wariantów:

1. jeżeli Macierze są monitorowane z poziomu stacji roboczej, wówczas każda Macierz musi być wyposażona co najmniej w co najmniej dwie stacje robocze do zarządzania konfiguracją, monitorowania wydajności i stanu Macierzy wraz z oprogramowaniem. Wykonawca musi uwzględnić wszystkie wymagane licencje na to oprogramowanie,

2. jeżeli Macierze są zarządzane i monitorowane z poziomu hosta (serwera Mainframe), Wykonawca musi uwzględnić wszystkie wymagane licencje na oprogramowanie monitorujące i zarządzając instalowane na serwerach Mainframe,

3. jeżeli Macierze są monitorowane z poziomu maszyny wirtualnej, Wykonawca musi dostarczyć obraz maszyny wirtualnej wraz ze wszystkimi wymaganymi licencjami.”

W pkt 3 Specyfikacji technicznej oferowanych Macierzy Dyskowych Wasko wskazał: „Instalacja: Management server (VM - Virtual Machine) plus agent na zOS”.

Wykonawca przyznał więc że oprogramowanie do zarządzania zainstaluje na zewnętrznym serwerze, wirtualnej maszynie, poza macierzą, która jest przedmiotem zamówienia. Wykonawca wybrał więc trzeci ze wskazanych w OPZ wariantów (rozdz. II pkt 34).

Zgodnie z rozdz. II pkt 34 OPZ, „jeżeli Macierze są monitorowane z poziomu maszyny wirtualnej, Wykonawca musi dostarczyć obraz maszyny wirtualnej wraz ze wszystkimi wymaganymi licencjami.”

Z dokumentu, w którym Hitachi wskazuje warunki instalacji zaoferowanego przez Wasko oprogramowania OpsCenter System Requirements” wynika, że w przypadku systemów instalowanych na maszynie wirtualnej wymagane jest oprogramowanie Vmware vSphere Hypervisor. Odwołujący wskazał, że dokumentu zawartego na stronie , wynika, zgodnie ztłumaczeniem, że Instalacja Ops Center Ova wymaga Vmware vSphere Hypervisor (Vmware ESXi) 7.0, 8.0, 8.0 update1 lub 8.0 update 2 oraz

Uwaga: Linux KVM i Microsoft Hyper-V nie są obsługiwane, ponieważ tylko Vmware obsługuje instalacje OVA.

Oprócz oprogramowania do zarządzania (które należało wskazać w pkt 3 załącznik nr 1A do SWZ), realizacja zamówienia przez Wasko będzie wymagała również licencji na system wirtualizacji, a więc dodatkowego oprogramowania. Skoro z powyższego wynika, że Ops Center w wersji na maszynę wirtualną wymaga oprogramowania VMware vSphere Hypervisor, a Zamawiający wyraźnie wymagał, że należy „dostarczyć obraz maszyny wirtualnej wraz ze wszystkimi wymaganymi licencjami”,
‎to Wasko powinien takie oprogramowanie dostarczyć w ramach oferty, a co za tym idzie powinien
‎w pkt 4 załącznika nr 1A do SWZ wskazać nazwę, producenta i sposób licencjonowania tego oprogramowania. Oprogramowanie VMware jest bowiem osobnym niezależnym produktem, którego producentem jest Vmware, a nie Hitachi. Z treści SWZ nie wynika, że Zamawiający posiada Vmware, z którego wykonawca będzie mógł korzystać, wobec tego niezbędne było jego uwzględnienie
‎w ofercie.

Odwołujący wskazał, że z uwagi na wybrany przez Wasko sposób realizacji zamówienia, do realizacji zamówienia niezbędne będzie również oprogramowanie systemu operacyjnego maszyny wirtualnej. W tym zakresie wykonawca może w zasadzie skorzystać z różnych rozwiązań, w tym nawet rozwiązań darmowych typu Open Source, nawet jeżeli Wasko będzie korzystało z darmowego oprogramowania, to nie oznacza to, że takie oprogramowanie nie jest odrębnie licencjonowane. Zamawiający wymagał wskazani w pkt 4 każdego oprogramowania, które wymaga udzielenia odrębnej licencji, nie wyłączył
‎z tego obowiązku oprogramowania Open Source. Nawet w przypadku oprogramowania ogólnie dostępnego - Open Source producent udziela licencji, a zatem również należało takie oprogramowanie wskazać w pkt 4 załącznika nr 1A do SWZ, czego Wasko zaniechał.

W podsumowaniu Odwołujący wskazał z uwagi na przyjęty przez Wasko sposób realizacji zamówienia - instalacja oprogramowania do zarządzania na zewnętrznym serwerze, wirtualnej maszynie - poza oprogramowaniem do zarządzania wskazanym w pkt 3 załącznika 1A do SWZ,
‎w pkt 4 tego załącznika Wasko był zobowiązany do wskazania również oprogramowania do monitorowania macierzy z poziomu maszyny wirtualnej (ze wskazaniem nazw, producentów, sposobu instalacji), czego zaniechał. W pkt 4 ww. załącznika Wasko wskazał „nie dotyczy”. Wynika z tego, że w ocenie Wasko monitorowanie macierzy z poziomu maszyny wirtualnej nie będzie wiązało się
‎z udzieleniem odrębnych licencji, co jak wykazał Odwołujący nie jest możliwe.

Hitachi nie jest producentem jakiegokolwiek rozwiązania wirtualnego, jakiejkolwiek maszyny wirtualnej, wobec tego nie jest możliwe, że oprogramowanie wskazane w pkt 3 obejmuje licencje niezbędne do monitorowania macierzy z poziomu maszyny wirtualnej, tj. licencje na system wirtualizacji i licencje na system operacyjny i maszyny wirtualnej. Odwołujący zwrócił uwagę, że również treść wyjaśnień ceny złożonych przez Wasko wskazuje, że licencje na system wirtualizacji i licencje na oprogramowanie systemu operacyjnego maszyny wirtualnej nie zostały ujęte w cenie oferty, taka pozycja w złożonej kalkulacji nie występuje.

Wobec tego ofertą Wasko nie jest objęte oprogramowanie, które umożliwi monitorowanie macierzy
‎z poziomu macierzy maszyny wirtualnej, pomimo że taka koncepcja realizacji zamówienia wynika wprost z oferty Wasko. Oferta jest więc niezgodna z warunkami zamówienia.

W odniesieniu do zarzutu ewentualnego Odwołujący wskazał, że nawet gdyby uznać, że nie istniała potrzeba wskazywanie w pkt 4 załącznika nr 1A do SWZ licencji do oprogramowania niezbędnego do monitorowania macierzy z poziomu maszyny wirtualnej, co byłoby wprost sprzeczne
‎z brzmieniem rozdz. II pkt 34 ppkt 3 OPZ, to Odwołujący zwrócił uwagę, że skoro wskazane przez Wasko oprogramowanie Ops Center w wersji na maszynę wirtualną wymaga oprogramowania Vmware vSphere Hypervisor (co wynika z oficjalnych dokumentów producentach Hitachi i co wykazano w ust. IX odwołania), to licencje na to oprogramowanie są niezgodne z warunkami zamówienia.

Zgodnie z rozdziałem II pkt 30 OPZ „Wszystkie dostarczone licencje powinny zostać udzielone
‎na czas nieograniczony wraz ze wsparciem na czas obowiązywania Usług Serwisu i Usług Wsparcia.”

Odwołujący wskazał, że zgodnie z powszechnie dostępnymi informacjami kilka miesięcy temu VMware zmienił swoją politykę i od tego czasu nie oferuje już licencji wieczystych, nieograniczonych, a jedynie licencji czasowe, co odbiło się szerokim echem w środowisku IT. Odwołujący zaprezentował przykładowe informacje w tym zakresie zamieszczona na stronach branżowych.

Odwołujący wskazał, że licencje czasowe nie spełniają wymagania, wyspecyfikowanego
‎w rozdziale II pkt 30 OPZ. Skoro zaoferowane przez Wasko oprogramowanie OpsCenter (wskazano je w pkt 3 załącznika nr 1A do SWZ) w wersji na maszynę wirtualną wymaga oprogramowania VMware vSphere Hypervisor, co wynika z oficjalnej strony producenta Hitachi Vantara, to zaoferowanie tego rozwiązania i tego oprogramowania de facto oznacza brak możliwości dostarczenia rozwiązania zgodnego z warunkami zamówienia. Licencje do programowania VMware vSphere Hypervisor nie są już bowiem udzielane na czas nieoznaczone, a taki wymóg sformułował Zamawiający w OPZ.

Na tym etapie Wasko nie może dokonać modyfikacji treści oferty, a Zamawiający nie może zrezygnować z tego wymagania, gdyż stanowiłoby to, co najmniej, naruszenie zasady równego traktowania wykonawców i uczciwej konkurencji.

Odwołujący podkreślił, że zgodnie z art. 226 ust. 1 pkt 5 Pzp oferta podlega odrzuceniu, jeżeli jej treść jest niezgodna z warunkami zamówienia. Stosownie zaś do treści art. 7 punkt 29 Pzp warunki zamówienia to warunki, które dotyczą zamówienia lub postępowania o udzielenie zamówienia, wynikające w szczególności z opisu przedmiotu zamówienia. Przepisy wskazują, że OPZ jest częścią dokumentacji postępowania, pod kątem zgodności, z którą Zamawiający zobowiązany jest oceniać oferty. Wobec tego niespełnienie przez oferowane oprogramowanie wymagań wyspecyfikowanych
‎w OPZ oraz brak zaoferowania niezbędnego oprogramowania należy traktować jako niezgodność
‎z warunkami zamówienia, a zatem oferta Wasko powinna zostać odrzucona na podstawie art. 226 ust. 1 pkt 5 Pzp.

W odpowiedzi na odwołanie – piśmie z 21 sierpnia 2024 r. Zamawiający wniósł o oddalenie odwołania w całości oraz obciążanie Odwołującego kosztami postępowania, w tym kosztami zastępstwa procesowego.

W uzasadnieniu pisma Zamawiający wskazał, że zarzuty odwołania jego zdaniem są pozbawione należytych podstaw, wobec czego odwołanie powinno zostać oddalone.

Zarzuty postawione przez Odwołującego sprowadzały się do twierdzenia, że macierze Hitachi zaoferowane przez WASKO S.A. nie spełniają poniższych wymagań Zamawiającego:

Zarzut 1 – (punkt VII uzasadnienia Odwołania) - brak wskazania nazwy każdego oferowanego oprogramowania do zarządzania.

Zarzut 2 – (punkt VIII uzasadnienia Odwołania) - zaoferowany pakiet Oprogramowania do zarządzania nie spełnia wymagań Zamawiającego.

Zarzut 3 – (punkt IX, X i XI uzasadnienia Odwołania) - brak zaoferowania oprogramowania
‎do monitorowania macierzy z poziomu maszyny wirtualnej.

Zarzut 4 – (punkt XII uzasadnienia Odwołania) – zaoferowanie licencji, które są niezgodne
‎z warunkami zamówienia.

Zamawiający wyjaśnił, że wymagał złożenia wraz z ofertą przedmiotowego środka dowodowego na potwierdzenie, że zaoferowane przez Wykonawców rozwiązania spełniają określone wymagania SWZ. Zamawiający, na podstawie informacji zawartych w dokumencie

„Specyfikacja techniczna oferowanych Macierzy Dyskowych”, złożonym z ofertą, sporządzonym wg Załącznika nr 1A do SWZ, był w stanie zweryfikować, jakie rozwiązania zostały zaoferowane oraz że zaoferowane rozwiązania spełniają wymagania określone przez Zamawiającego. Do weryfikacji, czy zaoferowane rozwiązania spełniają wymagania SWZ, Zamawiający nie wymagał wyspecyfikowanej pełnej listy wszystkich elementów oprogramowania, a jedynie takie wskazanie, które umożliwiało identyfikację oferowanego oprogramowania.

Zamawiający na etapie oceny oferty, na podstawie wskazania Wykonawcy, iż oferuje, cyt.: „Pakiet licencji Advanced w tym OpsCenter plus agent do zarządzania replikacją oraz Hitachi Ops Center Analyzer for Mainframe. Producent: Hitachi Vantara. Licencjonowanie: dla każdej pojedynczej macierzy.” Posiłkując się dokumentacją producenta - , Zamawiający zweryfikował, że oprogramowanie do zarządzania macierzami Hitachi OpsCenter udostępniane jest przez producenta na różnych poziomach licencjonowania: Basic, oraz Advanced. Ponadto istnieje możliwość zakupu dodatkowych funkcjonalności (Additional Software), które mogą być uzupełnieniem poziomu Basic lub Advanced.

Istotne jest to, że oprogramowanie w pakietach na poziomie Advanced zawiera wszystkie produkty
‎z pakietów na poziomie Basic (w przywołanym przez Odwołującego na stronie 6 Odwołania fragmencie dokumentacji producenta: „ADVANCED PACKAGE MAINFRAME SYSTEMS zawiera: Cały pakiet Mainframe Base oraz:..”).

W odniesieniu do zarzutu 1 Zamawiający wskazał, że Odwołujący zarzucił, że Wykonawca WASKO S.A. w Załączniku nr 1A nie sprecyzował, jakie oprogramowanie kryje się pod pojęciem „agent do zarządzania replikacją”. Zamawiający poinformował, że na podstawie pełnej treści tego dokumentu złożonego przez WASKO S.A., wiedział, jakie oprogramowanie, zostało zaoferowane przez tego Wykonawcę i że spełnia ono wymagania SWZ. W języku stosowanym w informatyce, pojęcie „agent” oznacza autonomiczny program komputerowy lub system, który jest zdolny do wykonywania określonych zadań w imieniu użytkownika lub innego systemu. Działania agenta często obejmuje zdolność do interakcji z innymi agentami lub systemami. Biorąc pod uwagę informacje przekazane przez WASKO S. A. w Załączniku nr 1A, oprogramowanie agent do zarządzania replikacją ma być zainstalowany po stronie systemu operacyjnego z/OS, czyli na platformie mainframe. W tym przypadku agentem jest oprogramowaniem, które będzie komunikowało się z pozostałym oprogramowaniem do zarządzania, w celu zarządzania replikacją na charakterystycznej platformie mainframe. Zgodnie z dokumentacją producenta, istnieją podstawowe metody replikacji: TrueCopy do zewnętrznej replikacji synchronicznej lub asynchronicznej, Universal Replicator do asynchronicznej replikacji na długie odległości oraz ShadowImage do wewnętrznej replikacji. Zgodnie z dokumentacją producenta - i tłumaczeniem: „Istnieją dwa typy licencji dla Business Continuity Manager: licencja na korzystanie z podstawowych funkcji i licencje na korzystanie z opcjonalnych funkcji. Po zainstalowaniu licencji na korzystanie z podstawowych funkcji możesz definiować i zarządzać grupami kopii ShadowImage (SI), TrueCopy (TC) i Universal Replicator (UR). Aby korzystać z opcjonalnych funkcji, zainstaluj wymaganą licencję.”

Zgodnie z tą informacją oprogramowanie do zarządzania replikacją tzn. Business Continuity Manager zawiera oprogramowanie do replikacji zewnętrznej oraz wewnętrznej, które spełniają wymagania Zamawiającego zawarte w SWZ. Oprogrogramowanie Business Continuity Mangaer instalowane jest po stronie systemu operacyjnego z/OS i komunikuje się z oprogramowaniem Replication Manager: „Business Continuity Manager is supported for the following versions of z/OS®: V1R13, and V2R1 to V2R5.

Use z/OS V2R1 or a later version to establish HTTPS communication between Replication Manager and Business Continuity Manager by using TLS 1.2.” - https://docs.hitachivantara.com/r/en-us/business-continuity-manager/9.8.7/mk-95hc104/overview-of-hitachi-business-continuity-manager/prerequisite-conditions - rozdział „Prerequisite conditions” Oprogramowanie Business Continuity Manager zawiera w sobie agenta, którego instaluje się np. po stronie lokalnej oraz zdalnej (awaryjnej). Zamawiający wskazał na przykład instalacji agentów Business Continuity Manager wraz z połączeniem z Replicator Managerem (poza platformą mainframe), którego schemat pochodzi ze strony producenta - https://docs.hitachivantara.com/r/en-us/business-continuity-manager/9.8.7/mk-95hc104/setting-up-the-environment-when-linking-with-replication-manager/creating-initialization-parameters/examples-of-specifying-initialization-parameters/for-business-continuity-manager-agent-on-local-and-remote-sites.

Oznaczenia TC oraz UR ze schematu oznaczają kolejno TrueCopy oraz Universal Replication, które wchodzą w skład oprogramowania Business Continuity Manager.

W dokumentacji przywołanej przez Odwołującego, w pakiecie „Advanced Package Mainframe Systems” występuje m.in. oprogramowanie „Hitachi Business Continuity Manager Extended for automating Remote Data Protection” oraz „Hitachi Business Continuity Manager utility for automating local replication”.

Cały powyższy wywód dowodzi, że Zamawiający był w stanie jednoznacznie zweryfikować, że zaoferowane oprogramowanie spełnia wymagania Zamawiającego.

W odniesieniu do zarzut 2 odwołania wykonawca WASKO S. A., w Załączniku nr 1A wskazał „Pakiet licencji Advanced w tym OpsCenter plus agent do zarządzania replikacją”. Przywołany zapis, poprzez użycie zwrotu „w tym”, potwierdza, że oprogramowanie OpsCenter znajduje się w pakiecie licencyjnym Advanced. Skoro, jak sam Odwołujący wskazał, oprogramowanie OPS Center nie znajduje się
‎w pakiecie licencyjnym Advanced, to należy przyjąć, że określenie „w tym” odnosi się do oferty, a nie „Pakietu licencyjnego Advanced”. Powyższe nie pozwalało kwestionować Zamawiającemu, że zaoferowane oprogramowanie wg treści oferty odpowiada wymaganiom zawartym w SWZ. Istotne było, czego nie wskazał Odwołujący, że w dokumentacji producenta, przywołanej przez Odwołującego, przy każdej tabeli jest adnotacja nr 1, w oryginalnym brzmieniu: „Combined open systems and mainframe base, advanced and additional options are available for mixed open and mainframe VSP 5000 environments.”

Tłumaczenie: „Dostępne są łączone (licencje na - przyp. red.) systemy otwarte i baza mainframe, opcje zaawansowane i dodatkowe dla mieszanych środowisk otwartych i mainframe VSP 5000”.

Zamawiający zwrócił uwagę, iż nie wyklucza wykorzystania macierzy jednocześnie w środowisku mainframe, jak i środowisku systemów otwartych, co wynika z części postanowień zawartych w treści OPZ (np. w poz. nr 9 Rozdział II OPZ). W takim przypadku możliwe będzie mieszanie licencji, a co za tym idzie niezbędne jest oprogramowanie OpsCenter, do zarządzania macierzami.

Zamawiający zwrócił uwagę, jak już wskazano we wcześniejszym fragmencie odpowiedzi,
‎iż oprócz licencji na poziomie Basic oraz Advanced, producent umożliwia wykupienie dodatkowych funkcjonalności, które rozszerzają licencje na poziomie Basic oraz Advanced. Jak pokazuje przywołana przez Odwołującego strona producenta, wśród dodatkowego oprogramowania (Additional Software) dla platformy mainframe znajduje się „Ops Center Analyzer” w wielu wersjach funkcjonalnych.

Wykonawca WASKO w Załączniku nr 1A, wskazał oferowane oprogramowanie „Ops Center Analyzer for Mainframe”, przez co należy rozumieć, że chodzi o wszystkie produkty Hitachi OpsCenter Analyzer z kategorii „ADDITIONAL SOFTWARE OPTIONS MAINFRAME”.

W odniesieniu do zarzutu 3 i 4 odwołania, Zamawiający wskazał, że Odwołujący zarzucił,
‎iż zaoferowane przez WASKO S.A. macierze Hitachi Vantara VSP 5600 nie spełniają wymagania zawartego w pkt 34 Rozdziału 2 OPZ.

Zamawiający zamieścił pełne brzmienie treści pkt 34 Rozdział 2 OPZ (cyt):

„W zależności od sposobu zarządzania i monitorowania Macierzy, konieczne jest zaoferowanie minimum jednego z poniższych wariantów:

1. jeżeli Macierze są monitorowane z poziomu stacji roboczej, wówczas każda Macierz musi być wyposażona w co najmniej dwie stacje robocze do zarządzania konfiguracją, monitorowania wydajności i stanu Macierzy wraz z oprogramowaniem. Wykonawca musi uwzględnić wszystkie wymagane licencje na to oprogramowanie,

2. jeżeli Macierze są zarządzane i monitorowane z poziomu hosta (serwera Mainframe), Wykonawca musi uwzględnić wszystkie wymagane licencje na oprogramowanie monitorujące i zarządzające instalowane na serwerach Mainframe,

3. jeżeli Macierze są monitorowane z poziomu maszyny wirtualnej, Wykonawca musi dostarczyć obraz maszyny wirtualnej wraz ze wszystkimi wymaganymi licencjami.”.

Wykonawca WASKO S. A. w Załączniku nr 1A wskazał, że miejscem instalacji oprogramowania do zarządzania będzie „Management server (VM-Virtual Machine)”. Odwołujący na podstawie tego wskazał, iż WASKO S.A. zaoferował rozwiązanie, o którym mowa wariancie 3 w pkt 34 Rozdziału
‎2 OPZ. Wykonawca WASKO S.A. zaoferował zatem oprogramowanie Hitachi Ops Center w wersji na maszynę wirtualną, które wymaga oprogramowania VMware vSphere Hypervisor, a ściślej – wskazane oprogramowanie VMware jest wymagane dla zainstalowania Ops Center.

Zamawiający wskazał, że zestawiając powyższe, z postanowieniami zawartymi w OPZ, Odwołujący wywnioskował, iż Wykonawca WASKO S.A. winien Zamawiającemu dostarczyć wraz z obrazem maszyny wirtualnej również oprogramowanie VMware vSphere Hypervisor, potrzebne do instalacji Ops Center. W powiązaniu z tym Odwołujący dodatkowo wskazał, iż na oprogramowanie VMware vSphere Hypervisor Zamawiający nie uzyska licencji wieczystej, lecz wyłącznie licencję czasową, przez co również nie zostały zachowane wymagania określone w pkt 30 Rozdział 2 OPZ, zgodnie
‎z którym Zamawiający wymagał dostarczenia licencji wieczystych.

Odwołujący wskazał, że WASKO S. A. powinien w Załączniku nr 1A wpisać informację o wszystkich licencjach niezbędnych do realizacji zamówienia. Takie zobowiązanie nie wynika jednak z żadnego wymagania Zamawiającego. W Załączniku nr 1A należało wskazać jedynie nazwę oprogramowania, na podstawie której Zamawiający będzie w stanie zweryfikować czy zaoferowane rozwiązanie spełnia wymagania SWZ. Oprogramowanie VMware oraz system operacyjny, na którym będzie zainstalowane oprogramowanie do zarządzania, jest oprogramowaniem nie wynikającym wprost
‎z zapisów SWZ, a co za tym idzie, nie jest to oprogramowanie realizujące funkcjonalności macierzy wskazanych w OPZ. W związku z tym wymaganie zawarte w pkt 30 Rozdział II OPZ dotyczy tylko
‎i wyłącznie oprogramowania realizującego funkcjonalności macierzy wskazane w OPZ.

Wobec powyższego, wpisanie przez WASKO S. A. tego oprogramowania nie wniosłoby żadnych dodatkowych informacji, które byłyby niezbędne na etapie weryfikacji oferty.

Zamawiający wskazał, że wobec powyższego, zarzuty stawiane przez Odwołującego co do niezgodności oferowanych macierzy przez WASKO S.A. z treścią pkt 30 i/ lub 34 Rozdziału II OPZ należało uznać za bezzasadne, a w konsekwencji – winny zostać przez Izbę oddalone w całości.

Po przeprowadzeniu rozprawy, na podstawie zgromadzonego w sprawie materiału dowodowego oraz stanowisk Stron zawartych w odwołaniu i odpowiedzi na odwołanie, Krajowa Izba Odwoławcza ustaliła i zważyła, co następuje:

Izba ustaliła, iż nie została wypełniona żadna z przesłanek skutkujących odrzuceniem odwołania,
‎a odwołanie nie zawierało braków formalnych i mogło zostać rozpoznane merytorycznie.

Izba ustaliła, że Odwołujący wykazał interes w korzystaniu ze środków ochrony prawnej. Wykonawca jest podmiotem, który złożył ofertę w postępowaniu i jest zainteresowany uzyskaniem zamówienia oraz możliwość poniesienia szkody w wyniku naruszenia przez Zamawiającego przepisów ustawy.

Do postępowania odwoławczego przystąpienie po stronie Odwołującego zgłosił wykonawca Advatech Spółka z ograniczoną odpowiedzialnością z siedzibą we Wrocławiu, dalej: „Przystępujący Advatech”, po stronie Zamawiającego - wykonawca Wako Spółka Akcyjna z siedzibą w Gliwicach, dalej: „Przystępujący Wasko”.

Zgłoszenia spełniały warunki określone w art. 525 ust. 1 ustawy Pzp.

Przystępujący Wasko w piśmie z 23 sierpnia 2024 r. wniósł o oddalenie odwołania oraz przedstawił swoje stanowisko.

Izba zaliczyła do materiału dowodowego sprawy dokumenty pochodzące z akt sprawy odwoławczej oraz złożone podczas rozprawy w dniu 23 sierpnia 2024 r.

Na podstawie przekazanej dokumentacji postępowania Izba ustaliła, że Zamawiający Zakład Ubezpieczeń Społecznych, prowadzi postępowanie o udzielenie zamówieniapn. „Zakup Macierzy dyskowych na platformę MF z możliwością rozbudowy do systemów otwartych”.

Stosownie do pkt 4.3.1 i pkt 4.3.1.1. Specyfikacji Warunków Zamówienia, ofertę składa się na Formularzu oferty stanowiącym Załącznik nr 1 do SWZ.

Na ofertę składa się Formularz oferty wypełniony zgodnie z Załącznikiem nr 1 do SWZ.

Zgodnie z pkt 2.1.5 oraz 2.1.5.1. SWZ Przedmiotowe środki dowodowe:

2.1.5.1.Zamawiający wymaga złożenia przedmiotowego środka dowodowego na potwierdzenie spełniania wymaga dotyczących przedmiotu zamówienia, tj.:

2.1.5.1.1.Specyfikacji technicznej oferowanych Macierzy Dyskowych, według wzoru stanowiącego Załącznik 1A do SWZ.

Zamawiający w załączniku 1A do SWZ – Specyfikacja techniczna oferowanych Macierzy Dyskowych w pkt 3 i 4 wymagał wskazania następujących parametrów wraz ze specyfikacją:

3. Oprogramowania do Zarzadzania, ze wskazaniem:

1) nazwy,

2) producenta,

3) sposobu licencjonowania.

4. Wykazu innego (niż Oprogramowanie do Zarządzania) niezbędnego oprogramowania (na które udzielone będą odrębne licencje), ze wskazaniem:

1) nazwy,

2) producenta,

3) sposobu licencjonowania.

Stosowanie do definicji oprogramowania zawartej we wzorze umowy – Załączniku nr 16, przez Oprogramowanie należało rozumieć oprogramowanie mikrokodowe lub oprogramowanie do zarządzania, monitorowania i raportowania. Lub inne oprogramowanie dostarczone wraz
‎z Macierzą lub niezbędne do prawidłowego działania Macierzy; nie musi być określone
‎w Ofercie i Protokole Odbioru jako odrębna pozycja.

Zgodnie z pkt 26 w Rozdziale 2 – Szczegółowe wymagania dla Macierzy dyskowych – Macierze muszą posiadać mechanizmy wspierające równoczesny dostęp do danych PAV
‎i HyperPAV dla całej pojemności Macierzy.

Stosownie do pkt 30 ww. Rozdziału 2 – Wszystkie dostarczone licencje powinny zostać udzielone na czas nieograniczony wraz ze wsparciem na czas obowiązywania Usług Serwisu i Usług Wsparcia,
‎a pkt 34 ppkt 3 stanowił, iż: W zależności od sposobu zarządzania i monitorowania Macierzy, konieczne jest zaoferowanie minimum jednego z poniższych wariantów:

3.jeżeli Macierze są monitorowane z poziomu maszyny wirtualnej, wykonawca musi dostarczyć obraz maszyny wirtualnej wraz z wszystkimi wymaganymi licencjami.

W dniu 26 lipca 2024 r. Zamawiający przekazał informację o wyborze oferty Przystępującego Wasko jako oferty najkorzystniejszej.

Od powyższej czynności oraz zaniechania odrzucenia oferty ww. wykonawcy, jako niezgodnej
‎z warunkami zamówienia, odwołanie wniósł wykonawca T-Mobile Polska Business Solutions Spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie.

Po zapoznaniu się z argumentacją stron i uczestnika postępowania odwoławczego, wyrażoną we wniesionych w nim pismach oraz przedstawioną w trakcie rozprawy Izba uznała, że odwołanie podlegało oddaleniu.

Zgodnie z art. 226 ust. 1 pkt 5 ustawy Pzp, Zamawiający odrzuca ofertę, jeżeli jej treść jest niezgoda
‎z warunkami zamówienia.

Stosownie do art. 7 pkt 29 ustawy Pzp, 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.

Izba wskazuje, że odrzucenie oferty wykonawcy, na podstawie art. 226 ust. 1 pkt 5 ustawy Pzp, jest możliwe wówczas, gdy ta niezgodność ma charakter zasadniczy i nieusuwalny, a Zamawiający może w sposób jednoznaczny stwierdzić, mając na uwadze treść złożonej oferty, że nie jest możliwa realizacja zamierzonego w postępowaniu celu.

Odnosząc się do zarzut nr 1a odwołania, Izba wskazuje:

Izba ustaliła, że wbrew twierdzeniu Odwołującego, iż Zamawiający z uwagi na brak wskazania nazwy oferowanego oprogramowania do zarządzania – agenta do zarządzania replikacją nie będzie w stanie zweryfikować jego zgodności z wymaganiami zamówienia i nie będzie wiedział, co jest przedmiotem zamówienia, Zamawiający, jak wynika z odpowiedzi na odwołanie, biorąc pod uwagę treść oferty oraz przedmiotowych środków dowodowych, złożonych przez Przystępującego Wasko nie miał żadnych problemów z identyfikacją oprogramowania do zarządzania – agenta do zarządzania replikacją. Zamawiający zidentyfikował pojęcie „agent”. Zamawiający wskazał, że zgodnie z informacją pochodzącą ze strony producenta Hitachi Vantara istnieją dwa typy licencji dla Business Continuity Manager: licencja na korzystanie z podstawowych funkcji i licencje na korzystanie z opcjonalnych funkcji.

Oprogramowanie do zarządzania replikacją tzw. Business Continuity Manager zawiera oprogramowanie do replikacji zewnętrznej oraz wewnętrznej, które spełniają wymagania Zamawiającego zawarte w SWZ.

Również z dokumentacji, na którą powołał się Odwołujący, w pakiecie Advanced Package Mainframe system występuje m.in. oprogramowanie Hitachi Business Continuity Manager Extended for Automatic Remote Data Protection oraz Hitachi Business continuity manager utility for automatic local replication.

Odwołujący na okoliczność wykazania, że oferta Przystępującego Wasko jest niezgodna
‎z warunkami zamówienia wskazał na pkt 3 Specyfikacji technicznej oferowanych Macierzy Dyskowych, w którym należało wskazać Oprogramowanie do Zarządzania.

Zgodnie z definicją pojęcia „oprogramowanie” zawartą w Załączniku nr 16 do wzoru umowy: „Oprogramowanie” to oprogramowanie mikrokodowe lub oprogramowani do zarządzania, monitorowania i raportowania, lub inne oprogramowanie dostarczone wraz z Macierzą lub niezbędne do prawidłowego działania Macierzy, nie musi być określone w Ofercie i Protokole Odbioru jako odrębna pozycja.

Zatem w pkt 3 Specyfikacji technicznej oferowanych Macierzy Dyskowych należało podać: nazwę, producenta, sposób licencjonowania, czyli informacji dotyczących oprogramowania do zarządzania. Jak podkreślił Zamawiający agent do zarzadzania replikacją w przypadku wskazanym przez Przystępującego Wasko był oprogramowaniem komunikującym się z pozostałym oprogramowaniem do zarządzania w celu zarządzania replikacją na platformie Mainframe.

Wobec powyższego, w związku z tym, że podanie nazwy oprogramowania agenta jako oprogramowania komunikującego się z pozostałym oprogramowaniem zarządzania, podanie informacji w pkt 3 Załącznika 1A nie było przez Zamawiającego wymagane, Zamawiający nie miał problemu z weryfikacją zgodności „agenta do zarządzania replikacją” z wymaganiami określonymi
‎w SWZ a Odwołujący nie wykazał niezgodności treści oferty z warunkami zamówienia, zarzut powyższy podlegał oddaleniu.

W odniesieniu do zarzutu nr 1b odwołania Izba wskazuje:

W odpowiedzi na powyższy zarzut, Zamawiający wskazał, że z dokumentacji producenta macierzy wynika, że dostępne są łączone systemy otwarte i baza mainframe, opcje zaawansowane
‎i dodatkowe dla mieszanych środowisk otwartych i mainframe VSP 5000, a on sam nie wykluczył możliwości wykorzystania macierzy jednocześnie w środowisku mainframe jak i środowisku systemów otwartych, co wynikało z postanowień zawartych w treści OPZ (np. poz. Nr 9 Rozdział
‎II OPZ). Wówczas możliwe będzie mieszanie licencji i wówczas niezbędne będzie oprogramowanie OpsCenter.

Jaj podkreślił Zamawiający, producent oprócz licencji na poziomie Basic oraz Advanced umożliwia wykupienie dodatkowych funkcjonalności, które rozszerzają licencje na poziomie Basic i Advanced. Ze strony producenta, na którą powołał się Odwołujący, wynika również, że wśród dodatkowego oprogramowania dla platformy mainframe znajduje się Ops Center Analyzer w wielu wersjach funkcjonalnych. Ponieważ Przystępujący Wasko w Załączniku nr 1A zaoferował oprogramowanie Ops Center Analyzer for Mainframe, Zamawiający przez to oprogramowanie rozumiał wszystkie produkty Hitachi Ops Center Analyzer z kategorii Additional Software Options Mainframe.

Ponadto, jak słusznie podkreślił Przystępujący Wasko w wierszu nr 3 w Załączniku nr 1A zobowiązany był wskazać nazwę, producenta oprogramowania do zarządzania, a nie nazwy pakietów licencyjnych lub innego oprogramowania, które nie było oprogramowaniem do zarządzania.

Okoliczności wskazane przez Odwołującego w uzasadnieniu zarzutu 1b nie dowodziły niezgodności oferty Przystępującego z warunkami zamówienia.

Wobec faktu, iż Odwołujący nie wykazał niezgodności treści oferty Przystępującego z warunkami zamówienia, zarzut nr 1b odwołania podlegał oddaleniu.

Odnosząc się do zarzutu nr 1c odwołania, Izba wskazuje:

Izba podkreśla, że jak wynika z treści Załączniku nr 1A do SWZ należało tam wskazać jedynie nazwę oprogramowania, które realizowało funkcjonalności macierzy wskazane w OPZ, a nie całego oprogramowania koniecznego do realizacji zamówienia, w tym oprogramowania platformy sprzętowej, na której zostanie zainstalowany obraz maszyny wirtualnej. Dokumenty Postępowania nieprzewidywały konieczności wskazywania oprogramowania platformy wirtualizacyjnej.

W ocenie Izby, Odwołujący nie wykazał niezgodności treści oferty Przystępującego Wasko
‎z warunkami zamówienia, a zatem zarzut nr 1c odwołania podlegał oddaleniu.

W odniesieniu do zarzutu ewentualnego – zaoferowania przez Przystępującego Wasko rozwiązania, które wymaga licencji, które udzielane są wyłącznie na czas określony, podczas gdy Zamawiający
‎w rozdz. II pkt 30 OPZ wymagał, aby wszystkie dostarczane licencje udzielane były na czas nieograniczony, Izba wskazuje:

Izba wskazuje, że powyższy zarzut oparty został na własnych założeniach Odwołującego, zgodnie
‎z którymi, skoro wskazane przez Przystępującego Wasko oprogramowanie Ops Center w wersji na maszynę wirtualną wymaga oprogramowania Vmware vSphere Hypervisor, to licencja na to oprogramowanie jest niezgodne z warunkami zamówienia, ponieważ Vmware nie oferuje już licencji wieczystych, nieograniczonych czasowo.

Jak wskazał Przystępujący Wasko odnosząc się do powyższego zarzutu, istnieją jeszcze trzy inne oprogramowania, które można zastosować w przypadku dostarczania obrazu maszyny wirtualnej zawierającej OpsCenter. Co więcej z oferty Przystępującego Wasko oraz przedmiotowych środków dowodowych nie wynika, aby zaoferował oprogramowanieVmware vSphere Hypervisor.Wobec powyższego, w ocenie Izby, Odwołujący nie wykazał niezgodności oferty Przystępującego Wasko we wskazanym powyżej zakresie z warunkami zamówienia.

A zatem, zarzut ewentualny podlegał również oddaleniu.

W związku z faktem, iż zarzuty nr 1a-1c oraz zarzut ewentualny nie potwierdziły się,
‎w konsekwencji Izba oddaliła również zarzut 2 odwołania zarzut naruszenia art. 239 ust. 1 ustawy Pzp, zgodnie z którym, zamawiający wybiera najkorzystniejszą ofertę na podstawie kryteriów oferty określonych w dokumentach zamówienia w zw. z art. 17 ust. 2 ustawy Pzp stanowiącym,
‎iż zamówienia udziela się wykonawcy wybranemu zgodne z przepisami ustawy.

O kosztach postępowania odwoławczego orzeczono stosownie do wyniku postępowania - na podstawie  i  ustawy Pzp oraz w oparciu o przepisy ust. 2 pkt 1 w zw.
‎z § 5 pkt 2 lit. b rozporządzenia Prezesa Rady Ministrów z dnia 30 grudnia 2020 r. w sprawie szczegółowych rodzajów kosztów postępowania odwoławczego, ich rozliczania oraz wysokości
‎i sposobu pobierania wpisu od odwołania.

Wobec oddalenia odwołania w całości, koszty ponosił Odwołujący.

II.KIO 2791/24:

W dniu 5 sierpnia 2024 r. wykonawca Advatech Spółka z ograniczoną odpowiedzialnością
‎z siedzibą we Wrocławiu, dalej: „Odwołujący” wniósł odwołanie wobec czynności Zamawiającego
‎i zaniechań czynności, do których był zobowiązany na podstawie PZP, tj.:

1) czynności wyboru oferty wykonawcy WASKO S.A. („WASKO”) jako najkorzystniejszej
‎w Postępowaniu,

2) zaniechania odrzucenia ofert wykonawców:

a) wykonawcy WASKO, który zaoferował macierz Hitachi Virtual Storage Platform 5600 („VSP 5600”);

b) T-Mobile Polska Business Solutions sp. z o.o. (”T-Mobile”), który zaoferował macierz Hewlett Packard Enterprise XP8 („HPE XP8”),

c) a także zaniechania odrzucenia z Postępowania ofert wykonawców Symmetry Sp. z o.o. („Symmetry”), oraz IT Solution Factor sp. z o.o. („IT Solution Factor”), którzy również zaoferowali macierz HPE XP8.

Odwołujący zarzucił Zamawiającemu naruszenie następujących przepisów:

1) art. 226 ust. 1 pkt 5) PZP poprzez:

a) zaniechanie odrzucenia ofert wykonawców WASKO, T-Mobile, a także Symmetry i IT Solution Factor jako niezgodnych z warunkami Zamówienia (SWZ), w zakresie braku spełnienia przez oferty tych wykonawców wymagań wskazanych w pkt 37, oraz pkt.12, 14-19 Rozdział 2 - Szczegółowe wymagania dla Macierzy dyskowych, Załącznik nr 11 do SWZ Szczegółowy Opis przedmiotu Zamówienia (OPZ), tj. braku brak spełnienia wymagań z OPZ przy pomocy programów TSO, DFSMSdss, ICKDSF [Zarzut Nr 1].

b) zaniechanie odrzucenia ofert wykonawców WASKO, T-Mobile, a także Symmetry i IT Solution Factor jako niezgodnych z warunkami Zamówienia, w zakresie braku spełnienia przez oferty tych wykonawców wymagania wskazanego w pkt. 19, Rozdział 2, OPZ, tj. braku zaoferowania rozwiązania zapewniającego możliwość pracy w środowisku GDPS/PPRC [Zarzut Nr 2];

c) zaniechanie odrzucenia ofert wykonawców WASKO, T-Mobile, a także Symmetry i IT Solution Factor jako niezgodnych z warunkami Zamówienia, w zakresie braku spełnienia przez oferty tych wykonawców wymagania wskazanego w pkt. 4, Rozdział 2, OPZ (po Odpowiedzi Zamawiającego z dnia 20 listopada 2023 r. na pytanie nr 2), tj. w zakresie zaoferowania rozwiązania, które do rozbudowy macierzy wykorzystuje dyski obrotowe, pomimo braku dopuszczenia takiej możliwości przez Zamawiającego [Zarzut Nr 3];

d) zaniechanie odrzucenia oferty wykonawcy T-Mobile, a także Symmetry i IT Solution Factor, pomimo że oferowane przez tych wykonawców macierze XPE XP8 nie spełniają wymagania z pkt. 12, Rozdział 2 OPZ, tj. pomimo, że macierze XPE XP8 nie są kompatybilne z systemami operacyjnymi S/390 (z/OS i z/VM) [Zarzut Nr 4].

Odwołujący wniósł o nakazanie Zamawiającemu:

1) unieważnienia czynności wyboru oferty wykonawcy WASKO jako najkorzystniejszej
‎w Postępowaniu,

2) dokonania ponownego badania i oceny ofert złożonych w Postępowaniu,

3) odrzucenia ofert WASKO, T-Mobile, Symmetry, IT Solution Factor z Postępowania,

a ponadto o zasądzenie od Zamawiającego na rzecz Odwołującego zwrotu kosztów postępowania odwoławczego, w tym zwrotu kosztów wynagrodzenia pełnomocnika, zgodnie z fakturą, która zostanie przedłożona na rozprawie.

W uzasadnieniu odwołania Odwołujący wskazał, że Zamawiający prowadzi Postępowanie, którego przedmiotem jest Zakup Macierzy dyskowych na platformę MF z możliwością rozbudowy do systemów otwartych. Zamawiający w Rozdziale 2 OPZ wskazał na Minimalne wymagania, które powinien spełniać oferowany przedmiot zamówienia. Odwołujący wskazał, że 3 wykonawców –
‎T-Mobile, Symmetry, IT Solution Factor zaoferowało macierze HPE XP8, natomiast jeden wykonawca WASKO zaoferował macierz VSP 5600.

W ocenie Odwołującego, obie macierze są podobnej konstrukcji – macierz HPE jest OEM`em macierzy Hitachi Vantara, dlatego też obie macierze nie spełniają wymagań opisanych
‎w Zarzutach Nr 1, 2, 3, dodatkowo macierz HPE nie spełnia wymagania wskazanego
‎w Zarzucie Nr 4.

Odwołujący wskazał, że wykonawcy składający ofertę byli doskonale świadomi, że zakup macierzy dokonywany jest w ściśle określonym celu - na platformę Mainframe producenta IBM, co za tym byli
‎w pełni świadomi, że rozwiązania oferowane przez nich muszą być w pełni kompatybilne z tą platformą, umożliwiać realizację wszystkich funkcjonalności opisanych przez Zamawiającego
‎w OPZ, co ważne w sposób opisany w OPZ.

Odwołujący wskazał na aktualne pod rządami obowiązującej ustawy PZP orzecznictwo, które wskazuje na obligatoryjność odrzucenia oferty wykonawcy niezgodnej z warunkami zamówienia. Zwłaszcza taka instytucja jak ZUS, która posiada rozwiązania serwerowo-macierzowe, na których posadowione są krytyczne dla państwa polskiego systemy i na których przechowywane są dane wrażliwe obywateli musi mieć absolutną pewność, że oferta danego wykonawcy spełnia wymagania z OPZ, a co za tym idzie rzetelnie przeprowadzić proces badania i oceny ofert.

Krajowa Izba Odwoławcza w wyroku z dnia 18 stycznia 2021 r. (sygn. KIO 3470/20) wskazała, że: „Ukształtowana w danym postępowaniu treść SIWZ wiąże nie tylko wykonawców, ale także Zamawiającego, który w toku tego postępowania ma obowiązek respektować ustalone założenia,
‎a odstępstwo od nich godzić może w zasadę równego traktowania wykonawców”. Analogiczne stanowisko zajęła Krajowa Izba Odwoławcza w wyroku z dnia 9 listopada 2020 r. (sygn. KIO 2598/20), gdzie wskazała, że „Wykonawcy biorący udział w postępowaniu mają prawo oczekiwać, że złożone
‎w postępowaniu oferty zostaną ocenione zgodnie z wymaganiami Zamawiającego wyartykułowanymi w dokumentacji postępowania, z poszanowaniem wymogów stawianych przez powszechnie obowiązujące przepisy prawa, zaś Zamawiający wykona ciążące na nim ustawowe obowiązki rzetelnego zbadania złożonych ofert, gwarantując tym samym zabezpieczenie interesów uczestników procesu udzielania zamówień publicznych” oraz w wyroku z dnia 10 grudnia 2020 r. (sygn. KIO 3040/20) „Przestrzeganie przez zamawiającego reguł, które on sam określił w siwz oraz przepisów określonych w ustawie z 2004 r. - Prawo zamówień publicznych, nie jest formalizmem, ale jedynym sposobem prowadzenia postępowania o udzielenie zamówienia zgodnie z zasadami, o których mowa w art. 7 ust. 1 p.z.p.

Wymagania zamawiającego służą bowiem (o ile są sformułowane adekwatnie do przedmiotu zamówienia) do weryfikacji tego, czy wykonawca jest zdolny do należytego wykonania zamówienia
‎i czy to, co on oferuje spełnia oczekiwania zamawiającego określone w ogłoszeniu o zamówieniu
‎i siwz. Zamawiający zobowiązany jest zatem rzetelnie sprawdzić spełnienie tych wymagań nie "dla formalności", ale dla uzyskania pewności, że zamówienie zostanie należycie zrealizowane”.

Natomiast zgodnie z wyrokiem Krajowej Izby Odwoławczej z dnia 24 lutego 2021 r. (sygn. KIO 230/21) „Zgodnie z art. 89 ust. 1 pkt 2 p.z.p. Zamawiający odrzuca ofertę wykonawcy, jeśli jej treść jest niezgodna ze SIWZ. Ustawodawca zobowiązał więc zamawiającego do odrzucenia ofert tych wykonawców, którzy złożyli ofertę niezgodną z wymaganiami zamawiającego określonymi
‎w specyfikacji istotnych warunków zamówienia, co do zakresu, ilości, jakości, warunków realizacji
‎i innych elementów istotnych dla wykonania przedmiotu zamówienia”.

Odwołujący wskazał, że w niniejszym Postępowaniu wymagania dotyczące funkcjonalności macierzy i sposobu realizacji tych funkcjonalności zostały wprost wyartykułowane przez Zamawiającego w treści OPZ, wyjaśnieniach SWZ, w związku z tym brak spełnienia wymagań wskazanych przez Odwołującego w odwołaniu powinien skutkować odrzuceniem ofert wykonawców Wasko, T-Mobile,
‎a także wykonawców Symmetry i IT Solution Factor, którzy zaoferowali dokładnie takie same macierze co wykonawca T-Mobile.

W odniesieniu do zarzutu nr zarzut nr 1 – braku spełnienia wymagań przy pomocy programów TSO, DFSMSdss, ICKDSF, Odwołujący wskazał, że oferowana przez wykonawcę WASKO macierz VSP 5000 oraz oferowana przez T-Mobile, IT Solution Factor, Symmetry macierz HPE XP8 nie posiadają:

a) funkcjonalności wykonywania zewnętrznych kopii danych do drugiej Macierzy, znajdującej się
‎w drugim ośrodku przetwarzania, która musi być realizowana przy użyciu mechanizmów Macierzy, dla grupy wielu wolumenów dyskowych w celu uzyskania spójnej (konsystentnej) kopii tych wolumenów (tzw. fizyczna replikacja danych) w trybie niesynchronicznym z poziomu systemu operacyjnego z/OS przy pomocy programów TSO i DFSMSdss. Brak tej funkcjonalności oznacza nie spełnienie wymagania pkt 14 i 15 w sposób nakazany w pkt 37.

b) funkcjonalności wykonywania zewnętrznych kopii danych do drugiej Macierzy, znajdującej się
‎w drugim ośrodku przetwarzania, która musi być realizowana przy użyciu mechanizmów Macierzy, dla grupy wielu wolumenów dyskowych w celu uzyskania spójnej (konsystentnej) kopii tych wolumenów (tzw. fizyczna replikacja danych) w trybie niesynchronicznym z wykorzystaniem jedynie kontrolerów dyskowych z poziomu systemu operacyjnego z/OS przy pomocy programu ICKDSF. Brak tej funkcjonalności oznacza nie spełnienie wymagania pkt 14 w sposób nakazany w pkt 37.

Odwołujący przytoczył wymagania wskazane pkt 37, oraz pkt. 12 i 14-19 Rozdziału 2-iego OPZ, których nie spełniają macierze oferowane przez czterech wykonawców.

37. Macierze muszą posiadać możliwość wywoływania funkcji Macierzowych opisanych
‎w punktach 14, 15, 16, 17, 18, 19 z poziomu systemu operacyjnego z/OS (DFSMSdss, ICKDSF, TSO) i raportowania o statusie.

12. Każda Macierz ma obsługiwać serwery System z (serwery IBM serii z), z systemem operacyjnym S/390 (z/OS, z/VM, Linux)

14. Każda Macierz musi posiadać funkcjonalność wykonywania zewnętrznych kopii danych do drugiej Macierzy, znajdującej się w drugim ośrodku przetwarzania, w odległości co najmniej 40 km za pośrednictwem DWDM. Funkcja musi być realizowana przy użyciu mechanizmów Macierzy, dla grupy wielu wolumenów dyskowych w celu uzyskania spójnej (konsystentnej) kopii tych wolumenów (tzw. fizyczna replikacja danych) w trybie synchronicznym oraz niesynchronicznym
‎z wykorzystaniem jedynie kontrolerów dyskowych.

15. W przypadku zawieszenia lub zerwania fizycznej replikacji danych, musi istnieć możliwość resynchronizacji wolumenów pomiędzy Macierzami w trybie różnicowym (propagacja tylko tych danych, które uległy zmianie).

16. Macierz musi posiadać możliwość wykonywania następujących wewnętrznych (w ramach pojedynczej Macierzy) kopii danych:

a. kopia grupy wolumenów dyskowych wykonana przy użyciu mechanizmów Macierzy. Wolumeny źródłowe i docelowe są dostępne dla aplikacji hosta do aktualizacji natychmiast po wykonaniu kopii. Dane fizyczne są kopiowane z wolumenów źródłowych na docelowe w tle w sposób minimalnie wpływający na wydajność Macierzy,

b. kopia grupy wolumenów dyskowych wykonana przy użyciu mechanizmów Macierzy. Wolumeny źródłowe i docelowe są dostępne dla aplikacji hosta do aktualizacji natychmiast po wykonaniu kopii. Dane fizyczne nie są kopiowane z wolumenów źródłowych na docelowe z wyjątkiem ścieżek które ulegają zmianie na wolumenach źródłowych - przed zmianą te ścieżki są kopiowane. Praca na takich danych nie może powodować pogorszenia wydajności o więcej niż 10%,

c. kopia zbioru danych wykonana przy użyciu mechanizmów Macierzy. Zbiór danych może zajmować część jednego lub wielu wolumenów dyskowych. Zbiór źródłowy i docelowy są dostępne dla aplikacji hosta do aktualizacji natychmiast po wykonaniu kopii. Dane fizyczne są kopiowane z w tle w sposób minimalnie wpływający na wydajność Macierzy. Mechanizm wykonujący kopie musi być zgodne z IBM FlashCopy V2 tzn. muszą w sposób poprawny interpretować i wykonywać komendy FlashCopy V2 (tzn. być kompatybilne z FlashCopy V2).

17. Dostarczony mechanizm replikacji pomiędzy Macierzą A i Macierzą B musi zagwarantować, iż w przypadku awarii Macierzy A, nie dojdzie do utraty danych na Macierzy B.

18. Mechanizm replikacji zewnętrznej musi zapewnić możliwość dynamicznej zmiany trybu
‎i kierunku replikacji.

19. Macierz A i Macierz B muszą zapewnić możliwość pracy w środowisku GDPS/PPRC
‎z zapewnieniem następujących funkcjonalności:

a. automatyzacji wykonania kopii dysków źródłowych (primary) na dyski docelowe (secondary) przy użyciu mechanizmu opisanego w punkcie 14,

b. automatyzacji wykonania kopii dysków źródłowych (secondary) na dyski docelowe (tertiary) przy użyciu mechanizmów opisanych w punkcie 16 podpunkt 1 i 2,

c. automatyzacji wykonania kopii opisanej w punkcie 2 powyżej na kilka oddzielnych grup dysków docelowych (tertiary),

d. automatyzacji czynności przełączenia przetwarzania wejścia/wyjścia na dyski docelowe (secondary) w trakcie planowanej i nieplanowanej niedostępności dysków źródłowych (primary) wykorzystując kopie opisaną w punkcie 1 powyżej - przełączenie przetwarzania nie powoduje przerwy w działaniu aplikacji hosta,

e. zarządzania z jednego miejsca zaimplementowanymi w GDPS/PPRC procedurami.

Odwołujący dla zobrazowania kwestii niespełnienia przez macierze HPE XP8 i VSP5600 „zawiłego” wymagania z pkt. 37 w połączeniu z pkt. 12, 14-19 Rozdziału 2 OPZ przedstawił w odwołaniu „Tabelę niespełnienia wymagań”.

W zakresie braku obsługi przy pomocy programów TSO i DFSMSdss Odwołujący wskazał, że jak widać z przedstawionej przez niego Tabeli, w rzeczywistości wymagań, które nie spełniają macierze HPE XP8 i VSP5600 jest wiele, natomiast Odwołujący skupił się w treści rozwinięcia Zarzutu na kilku kluczowych funkcjonalnościach, których nie posiadają te macierze, a które były wymagane przez Zamawiającego w pkt. 37, w połączeniu z pkt. 12, 14-19, Rozdział 2 OPZ.

Po pierwsze, Odwołujący podkreślił, że wszystkie trzy nazwy występujące w wymaganiu
‎37 (DFSMS, ICKDSF, TSO) określają dokładnie zdefiniowane oprogramowanie uruchomione pod kontrolą systemu operacyjnego z/OS na serwerach IBM serii z (wskazanych w wymaganiu 12). Zatem Zamawiający opisał precyzyjnie posiadany serwer, posiadany system operacyjny
‎i posiadane oprogramowanie do kopiowania danych pomiędzy macierzami. Oznacza to, że wymagał dostarczenia Macierzy, które będą wykonywały komendy realizujące replikację danych, wydawane przez program TSO i DFSMS zainstalowane na serwerze IBM System z.

Po drugie, Oferent Macierzy miał obowiązek sprawdzić listę poleceń programów wymienionych przez Zamawiającego w wymaganiu 37 (DFSMSdss, ICKDSF, TSO) i dostarczyć wszystkie funkcjonalności niezbędne do prawidłowej realizacji komend, które dotyczą replikacji w trybie niesynchronicznym (wymaganie 14) i tych, które dotyczą resynchronizacji w trybie różnicowym (wymaganie 15). Lista poleceń (komend) została opisana w publicznie udostępnionej dokumentacji systemu operacyjnego z/OS.

Opis funkcjonalności kopiowania danych w systemie operacyjnym z/OS z poziomu programów DFSMS i TSO jest publicznie dostępny w podręczniku „DFSMS Advanced Copy Services”

https://www.ibm.com/docs/en/SSLTBW_2.5.0/pdf/antg000_v2r5.pdf .

Podręcznik ten opisuje, w jaki sposób wymaganie 14 (zdalna replikacja danych) jest realizowane przy pomocy programów DFSMS i TSO (wymaganie 37). Odwołujący zacytował nagłówek Rozdziału 2, aby uporządkować nazewnictwo metod replikacji dostępnych w systemie operacyjnym z/OS:

Tłumaczenie na język polski: Rozdział 2. Czym jest zdalna kopia?

Zdalna kopia to rozwiązanie do odzyskiwania danych po katastrofie, ciągłości biznesowej
‎i migracji danych oparte na funkcjonalnościach Macierzy, które umożliwia kopiowanie danych do zdalnej lokalizacji w czasie rzeczywistym. „Zdalna kopia” odnosi się do następujących głównych funkcjonalności Zaawansowanych Usług Kopiowania:

1. Metro Mirror (Peer-to-Peer Remote Copy, or PPRC)

2. Global Copy (PPRC-Extended Distance, or PPRC-XD)

3. Global Mirror, or asynchronous PPRC

4. z/OS Global Mirror (Extended Remote Copy, or XRC)

Uzupełniając powyższe nazewnictwo Odwołujący wyjaśnił, że:

- Metro Mirror czyli PPRC, to funkcja zdalnej kopii synchronicznej,

- Global Copy, to funkcja zdalnej kopii asynchronicznej na duży dystans (np. międzykontynentalny),

- Global Mirror, czyli asynchroniczne PPRC, to kopia zdalna grupy wielu woluminów zachowująca spójność danych (obraz wielu woluminów z tego samego momentu w czasie),

- z/OS Global Mirror czyli XRC, to funkcja zdalnej kopii asynchronicznej zachowująca spójność danych na grupie wielu woluminów i kompatybilność pomiędzy różnymi Macierzami.

Dalej, akapit na str. 15 informuje, że celem tego, że DFSMS obsługuje wiele metod kopiowania danych, jest zastosowanie w zależności od różnych sytuacji – planowanych i nieplanowanych (np. awaria). Zgodnie z tłumaczenie na język polski: „W zależności od konkretnych potrzeb możesz wybrać jedną
‎z kilku opcji odzyskiwania danych po awarii z kopii zdalnej: Rozszerzona kopia zdalna (XRC), kopia zdalna peer-to-peer (PPRC) lub PPRC-Extended Distance.”

Na tej samej stronie znajduje się tabela, która pomaga operatorowi systemu operacyjnego z/OS podejmować decyzję jaką metodę replikacji danych zastosować.

Odwołujący wskazał, że zarówno macierze HPE XP8, jak i macierze VSP 5600 nie potrafią obsłużyć metod replikacji XRC, Global Mirror oraz Global Copy (PPRC-XD), wymienionych
‎w Tabeli wskazanej w odwołaniu przy pomocy programów TSO i DFSMS.

W odniesieniu do zarzutu braku replikacji XRC dla macierzy HPE XP8 i macierzy VSP 5600, Odwołujący wskazał, że jeśli chodzi o ofertę T-Mobile, to w zakresie replikacji XRC funkcjonalność taka mogłaby istnieć, gdyby wykonawca T-Mobile dostarczył wraz z Macierzami licencje na obsługę XRC – czego nie uczynił, jak wynika z wypełnionego załącznika 1A do SWZ przez tego wykonawcę. Żadna z trzech licencji (LUN Manager, Remote Web Console, XP8 Mainframe Performance Advanced Suite) wymienionych w wypełnionym Załączniku 1A do SWZ nie umożliwia replikacji zdalnej w trybie XRC obsługiwanym przez programy TSO i DFSMS.

Macierze HPE XP8 nie potrafią poprawnie obsłużyć poleceń programów TSO i DFSMS
‎w zakresie replikacji danych metodą XRC, co Zamawiający może stwierdzić na podstawie braku
‎w Załączniku 1A licencji producenta (firmy HPE) do replikacji asynchronicznej o nazwie „Compatible XRC”. Odwołujący dodał, że publicznie dostępne informacje firmy HPE na temat możliwości zastosowania XRC na macierzach XP8 są obłożone restrykcjami. W podręczniku „HPE XP8 Documentation Roadmap”

można znaleźć informację, która zgodnie z tłumaczeniem brzmi:

Funkcja Compatible XRC zapewnia zgodność z IBM Extended Remote Copy (XRC) niesynchronicznych kopii zdalnych, w celu tworzenia kopii zapasowych i odzyskiwania danych
‎w przypadku awarii.

W operacjach Compatible XRC dane zapisywane z hosta na woluminie podstawowym
‎w pierwszej macierzy XP8 są również tymczasowo zapisywane jako pliki w pamięci podręcznej cache XP8. W lokalizacji zdalnej oprogramowanie System Data Mover (SDM) asynchronicznie odczytuje pliki poboczne przez linie komunikacyjne z pierwszej macierzy w lokalizacji głównej. Następnie SDM zapisuje dane na woluminie docelowym w macierzy zdalnej w tej samej kolejności, w jakiej zostały zapisane w lokalizacji głównej.

UWAGA: Compatible XRC nie może być używane na macierzy HPE XP8 Gen2.

W odniesieniu do oferty WASKO w zakresie replikacji XRC Odwołujący wskazał, że funkcjonalność taka mogłaby istnieć, gdyby Oferent dostarczył wraz z Macierzami licencje na obsługę XRC – czego nie uczynił, jak wynika z wypełnionego załącznika 1A do SWZ przez tego wykonawcę. Żadna
‎z licencji wymienionych przez WASKO w Załączniku 1A do SWZ (OpsCenter lub Hitachi Ops Center Analyzer for Mainframe) nie umożliwia replikacji zdalnej w trybie XRC obsługiwanym przez programy TSO i DFSMS.

Macierze VSP 5600 nie potrafią poprawnie obsłużyć poleceń programów TSO i DFSMS
‎w zakresie replikacji danych metodą XRC, co Zamawiający może stwierdzić na podstawie braku
‎w Załączniku 1A do SWZ licencji producenta (firmy HITACHI) do replikacji asynchronicznej np. Hitachi TruCopy for Mainframe i Universal Replicator for Mainframe.

W odniesieniu do brak funkcjonalności PPRC i Global Mirror i macierzy VSP 5600, Odwołujący wskazał, że w zakresie replikacji Global Mirror funkcjonalność ta nie istnieje „by design”
‎w oferowanej macierzy VSP 5600 z powodu ułomności architektury tej macierzy i z powodu braków takiej funkcjonalności w jej mikrokodzie – co skutkuje niedostosowaniem macierzy do serwera Mainframe, systemu operacyjnego z/OS oraz pełnej obsługi programów TSO
‎i DFSMS. Macierze VSP 5600 nie potrafią poprawnie obsłużyć poleceń programów TSO
‎i DFSMS w zakresie Global Mirror, co Zamawiający mógł stwierdzić żądając od oferenta wskazania publicznie dostępnej dokumentacji producenta (firmy HITACHI Vantara) do replikacji asynchronicznej realizowanej programem TSO pod systemem operacyjnym z/OS (nie ma dokumentacji producenta opisującego funkcjonalności, których on nie dostarcza). Odwołujący podkreślił, że nie możemy w tym miejscu przytoczyć dowodu z dokumentacji VSP 5600 na brak obsługi asynchronicznego PPRC/Global Mirror poprzez program TSO, bo dokumentacja taka nie istnieje - producent w swojej dokumentacji nie opisuje funkcjonalności, której nie posiada. Nie mniej znaleźć można wzmiankę
‎o braku wsparcia w dokumencie „System Administrator Guide for VSP 5000 Series” na stronie https://docs.hitachivantara.com/r/en-us/virtual-storage-platform-5000-series/90-09-2x/mk-98rd9009/system-option-modes-soms/system-option-modes-for-vsp-5000-series.

Z tłumaczenia na język polski wynika: „Chociaż opcja CASCADE może być podana
‎w komendzie ESTPAIR, to funkcjonalność PPRC-XD nie jest wspierana”.

Odwołujący wyjaśniając treść tej wzmianki wskazał, że istotna jest informacja „funkcjonalność PPRC-XD nie jest wspierana” – co dotyczy metody replikacji obsługiwanej przez programy DFSMS, ICKDSF i TSO cytowanej akapit wyżej, natomiast pojęcie CASCADE dotyczy tworzenia kopii z kopii (zobrazowane w dalszej części tego dokumentu na rysunku), a komenda ESTPAIR dotyczy zestawienia pary dwóch woluminów z których pierwszy zawiera dane produkcyjne, a drugi jest jego kopią.

W odniesieniu do macierz HPE XP8 w zakresie replikacji Global Mirror Odwołujący wskazał, że funkcjonalność ta nie istnieje „by design” z powodu ułomności architektury tej macierzy
‎i z powodu braków takiej funkcjonalności w jej mikrokodzie – co skutkuje niedostosowaniem macierzy HPE XP8 do serwera Mainframe, systemu operacyjnego z/OS oraz pełnej obsługi programów TSO i DFSMS. Macierze HPE XP8 nie potrafią poprawnie obsłużyć poleceń programów TSO i DFSMS w zakresie Global Mirror, co Zamawiający mógłby stwierdzić np. żądając od oferenta wskazania publicznie dostępnej dokumentacji producenta (firmy HPE) do replikacji asynchronicznej realizowanej programem TSO pod systemem operacyjnym z/OS (nie ma dokumentacji producenta opisującej funkcjonalności, których producent nie dostarcza). Odwołujący podkreślił, że nie mógł
‎w tym miejscu przytoczyć dowodu z dokumentacji HPE XP8 na brak obsługi asynchronicznego PPRC/Global Mirror poprzez program TSO, bo dokumentacja taka nie istnieje - producent w swojej dokumentacji nie opisuje funkcjonalności, której nie posiada.

W odniesieniu do zarzutu braku obsługi przy pomocy programu ICKDSF, Odwołujący wskazał, że macierze HPE XP8 oferowane przez T-Mobile oraz IT Solution Factor oraz Symmetry oraz macierze VSP 5600 zaoferowane przez WASKO:

a) nie potrafią zrealizować poleceń programu ICKDSF w zakresie fizycznej replikacji danych w trybie niesynchronicznym Global Mirror.

b) nie potrafią zrealizować poleceń programu ICKDSF w zakresie resynchronizacji w trybie różnicowym w przypadku zawieszenia lub zerwania fizycznej replikacji danych.

Uzasadniając powyższe Odwołujący wskazał, że opis „wywoływania funkcji Macierzowych” dla programu ICKDSF jest publicznie dostępny

https://www.ibm.com/docs/en/zos/2.5.0?topic=SSLTBW_2.5.0/com.ibm.zos.v2r5.pdf/allpubs.html.

Lista wszystkich 15 poleceń ICKDSF znajduje się na stronie 4 (Tabela 9) „Device Support Facilities (ICKDSF) User's Guide and Reference”.

Program ICKDSF zażąda od Macierzy replikacji asynchronicznej (realizacji wymagania 14) po wydaniu przez użytkownika systemu z/OS komendy PPRCopy.

Wyjaśnienie komendy PPRCopy znajduje się w Rozdziałach 20 i 21, zgodnie z tłumaczeniem: Zdalna Kopia „Peer-to-Peer” (PPRCOPY), opisana także jako PPRC, pozwala na synchroniczne
‎i niesynchroniczne kopiowanie wolumenów dyskowych z jednego podsystemu do innego podsystemu macierzowego, bez udziału centralnego serwera, dla tych macierzy, które to wspierają oraz zgodnie z tłumaczeniem: ICKDSF obsługuje niesynchroniczne PPRCOPY (Global Mirror) udostępniając polecenia które umożliwią:

1. Zdefiniowanie i wyświetlenie topologii sesji za pomocą poleceń PPRCOPY DEFINESESSION, PPRCOPY POPULATESESSION oraz PPRCOPY QUERY SESSIONSDEVICES.

Odwołujący ponadto wskazał, że w podręczniku „Device Support Facilities (ICKDSF) User's Guide and Reference” opisano komendy programu ICKDSF, które realizują wymagania SWZ nr 14 i 15. Znajduje się tam m.in. akapit, który zgodnie z tłumaczeniem na język polski brzmi: PPRCOPY DEFINESESSION jest przeznaczony do zarządzania procesem tworzenia grup spójności (grup woluminów). Pojedyncza grupa woluminów, dla której utworzona jest pojedyncza grupa spójności, nazywana jest sesją. Sesje są otwierane (tworzone) i zamykane (kończone) za pomocą polecenia PPRCOPY DEFINESESSION. Członkostwo w sesji jest kontrolowane za pomocą komendy PPRCOPY POPULATESESSION. Topologię sesji asynchronicznej PPRCOPY i pewne atrybuty okresu trwania konfiguruje się za pomocą komendy PPRCOPY STARTASYNCCOPY, która również rozpoczyna przetwarzanie.

Odwołujący wskazał, że macierze HPE XP8 i VSP 5600 nie potrafią wykonać polecenia „PPRCOPY DEFINESESSION”, czyli nie potrafią otworzyć (i zamknąć) sesji dla replikacji asynchronicznej
‎w sposób opisany w wymaganiu 14, czyli: „Funkcja musi być realizowana przy użyciu mechanizmów Macierzy, dla grupy wielu wolumenów dyskowych w celu uzyskania spójnej (konsystentnej) kopii tych wolumenów (tzw. fizyczna replikacja danych) w trybie synchronicznym oraz niesynchronicznym
‎z wykorzystaniem jedynie kontrolerów dyskowych” oraz że macierze HPE XP8 i VSP 5600 nie wykonają kolejnego polecenia ICKDSF „PPRCOPY POPULATESESSION”, które realizuje dodanie lub usunięcie do sesji wskazanych przez operatora woluminów (zgodnie z przytoczoną dokumentacją ICKDSF). Zgodnie z jej tłumaczeniem: Polecenie PPRCOPY POPULATESESSION służy do zapełnienia lub usunięcia sesji, która została wcześniej OTWARTA za pomocą polecenia PPRCOPY DEFINESESSION.

Odwołujący wskazuje, że nie mógł w tym miejscu przytoczyć dowodu z dokumentacji HPE XP8 i VSP 5600 na brak obsługi asynchronicznego PPRC/Global Mirror poprzez program ICKDSF, bo dokumentacja taka nie istnieje - producent w swojej dokumentacji nie opisuje funkcjonalności, których nie posiada. Brak takiej funkcjonalności wskazuje na ułomność architektury tej Macierzy oraz jej niedostosowanie do platformy serwerów Mainframe i systemu operacyjnego z/OS. Konsekwencją braku wsparcia macierzy HPE XP8 i macierzy VSP 5600 dla programu ICKDSF jest brak reakcji na jego komendy, co skutkuje niemożliwością wykonania następujących działań związanych z replikacją danych:

a.) Brak reakcji macierzy HPE XP8 i macierzy VSP 5600 na komendę „PPRCOPY DEFINESESSION” uniemożliwia Zamawiającemu definiowanie „grupy wielu wolumenów dyskowych w celu uzyskania spójnej (konsystentnej) kopii tych wolumenów” (wymaganie 14.) przy pomocy programu ICKDSF (wymaganie 37).

b.) Brak możliwości wykonania komendy „PPRCOPY POPULATESESSION” uniemożliwia Zamawiającemu dodawanie i usuwanie wybranych wolumenów dyskowych do grupy przy pomocy programu ICKDSF.

c.) Brak możliwości wykonania komendy „PPRCOPY QUERY SESSIONSDEVICES” uniemożliwia Zamawiającemu uzyskanie informacji o woluminach dyskowych wchodzących
‎w skład sesji - grupy spójnej (konsystentnej) kopii przy pomocy programu ICKDSF (wymaganie
‎37 „raportowanie o statusie”).

d.) Ponadto macierze HPE XP8 nie potrafią wykonać polecenia ICKDSF „PPRCOPY STARTASYNCCOPY”, które nakazuje dwóm macierzom realizację zdalnej kopii asynchronicznej
‎i zapewnia funkcjonalność wymagania SWZ nr 15: „W przypadku zawieszenia lub zerwania fizycznej replikacji danych, musi istnieć możliwość resynchronizacji wolumenów pomiędzy Macierzami w trybie różnicowym (propagacja tylko tych danych, które uległy zmianie)”.

Zgodnie z tłumaczeniem: PPRCOPY STARTASYNCCOPY służy do inicjowania lub modyfikowania konfiguracji asynchronicznej sesji PPRCOPY oraz do rozpoczynania lub wznawiania asynchronicznego tworzenia grup spójności PPRCOPY.

e.) Oprócz wyżej przytoczonych przykładów lista komend PPRCOPY programu ICKDSF, których macierze HPE XP8 nie potrafią wykonać jest dłuższa i obejmuje między innymi polecenia:

PPRCOPY TERMASYNCCOPY PAUSE – wstrzymanie sesji np. na czas aktualizacji programu PPRCOPY TERMASYNCCOPY TERMINATE – zakończenie sesji PPRCOPY QUERY ASYNCCOPY – uzyskanie informacji o sesji PPRCOPY QUERY OUTOFSYNCSTATE – uzyskanie informacji o „różnicy danych, które uległy zmianie” (wymaganie 15).

Odwołujący wskazał na następujący wniosek: Macierze oferowane przez HPE XP8 oferowane przez T-Mobile, IT Solution Factor i Symmetry oraz macierze VSP 5600 oferowane przez Wasko nie potrafią poprawnie obsłużyć poleceń programu ICKDSF w zakresie wykonywania replikacji asynchronicznej PPRC (Global Mirror), nie istnieje żadna publicznie dostępna dokumentacja producenta Hitachi Vantara i Hewlett Packard Enterprise do replikacji asynchronicznej realizowanej programem ICKDSF pod systemem operacyjnym z/OS z prostej przyczyny - nie ma dokumentacji producenta opisującego funkcjonalności, których dana macierz nie posiada.

W odniesieniu do zarzut nr 2 – braku zapewnienia możliwości pracy w środowisku GDPS/PPRC, Odwołujący wskazał, że Zamawiający w pkt. 19, Rozdział 2 OPZ wskazał, że Macierz A i Macierz B muszą zapewnić możliwość pracy w środowisku GDPS/PPRC z zapewnieniem następujących funkcjonalności:

1. automatyzacji wykonania kopii dysków źródłowych (primary) na dyski docelowe (secondary)

przy użyciu mechanizmu opisanego w punkcie 14,

2. automatyzacji wykonania kopii dysków źródłowych (secondary) na dyski docelowe (tertiary)

przy użyciu mechanizmów opisanych w punkcie 0 podpunkt 1 i 2,

3. automatyzacji wykonania kopii opisanej w punkcie 2 powyżej na kilka oddzielnych grup dysków docelowych (tertiary),

4. automatyzacji czynności przełączenia przetwarzania wejścia/wyjścia na dyski docelowe (secondary) w trakcie planowanej i nieplanowanej niedostępności dysków źródłowych (primary) wykorzystując kopie opisaną w punkcie 1 powyżej - przełączenie przetwarzania nie powoduje przerwy w działaniu aplikacji hosta,

5. zarządzania z jednego miejsca zaimplementowanymi w GDPS/PPRC procedurami.

Odwołujący wskazał, że zarówno macierz HPE X8, jak i macierz VSP 5600 nie zapewniają tej możliwości, w sposób określony przez Zamawiającego.

Brak wyżej opisanego trybu replikacji „z wykorzystaniem jedynie kontrolerów dyskowych” (Zarzut Nr 1) powoduje, że macierze HPE XP 8 i VSP 5600 nie mogą zapewnić spełnienia wymagania z pkt 19.1, 19.2 i 19.3 OPZ powyżej, czyli współpracy z usługą GDPS, która dostarcza automatyzację
‎i konsystencję danych dla wymaganego schematu kopiowania A -> B -> C, gdzie A oznacza produkcyjne woluminy „primary”, B to zdalna macierz z dyskami docelowymi „secondary”, a C to kopie „tertiary”.

Po awarii dysków A nieskuteczne będzie odwrócenie relacji kopiowania i odzyskanie spójnych danych z kopii C poprzez polecenie ICKDSF. Lista macierzy spełniających wymagania SWZ 19.1 – 19.5 jest opublikowana przez dostawcę usługi GDPS pod linkiem https://www.ibm.com/products/gdps.

Zarówno macierzy VSP 5600, jak i macierzy HPE XP8 nie ma na tej stronie.

Zgodnie z wnioskiem Odwołującego - macierze HPE XP8 oraz macierze HPE XP8 nie współpracują z usługą GDPS zapewniającą automatyzację procesu kopiowania spójnej grupy woluminów.

W odniesieniu do zarzutu nr 3 odwołania – rozbudowa macierzy z wykorzystaniem dysków obrotowych, Odwołujący wskazał, że Zamawiający dnia 20 listopada 2023 r. udzieli Odpowiedzi na pytanie nr 2) do wymagania określonego w pkt. 4, Rozdział 2, OPZ, tj. w którym wskazał, że do rozbudowy macierzy nie dopuszcza wykorzystania dysków obrotowych.

W ocenie Odwołującego, zarówno macierz HPE XP 8, jak i macierz VSP 5600 dla rozbudowy macierzy wymagają zastosowania dysków obrotowych.

Macierz VSP 5600

Według specyfikacji producenta Hitachi Vantara „rodzina” macierzy VSP 5000 może być rozbudowywana przez powolne dyski obrotowe HDD, co nie spełnia wymagania Zamawiającego.

Na stronie HITACHI znajduje się wykaz dysków instalowanych w macierzy, gdzie opisano „HDD” - dwa rodzaje dysków obrotowych.

Źródło: https://www.hitachivantara.com/en-us/pdf/specifications/virtual-storage-platform-vsp-5200-5600-spec-table.pdf

Fakt możliwości rozbudowy macierzy Hitachi VSP 5000 o dyski obrotowe HDD oznacza, że macierz ta nie spełnia wymagania Zamawiającego: „Zamawiający informuje, iż wymaga dostarczenia Macierzy, w których nie można stosować dysków obrotowych do rozbudowy pojemności (...)”

Macierz HPE XP8

Według dokumentacji dostępnej na stronie producenta macierzy HPE XP8, macierz ta może być rozbudowywana przez powolne dyski obrotowe HDD, co nie spełnia wymagania Zamawiającego. Na stronie HPE Support znajduje się wykaz części zamiennych instalowanych w macierzy, gdzie po wpisaniu w pole wyszukiwania „HDD” publikowane są trzy rodzaje dysków obrotowych.

Źródło:https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00093353en_us&page=GUID-82F20103-C3FD-490E-B904-4958658699B4.html

Informacja o dyskach obrotowych HDD jest także powtórzona w specyfikacji macierzy XP8 jako jej standardowa cecha w kolumnie „increment” (rozbudowa)

https://support.hpe.com/hpesc/public/docDisplay?docId=a00073544enw&docLocale=en_US.

W odniesieniu do zarzutu nr 4 odwołania – braku kompatybilności macierzy XPE XP8
‎z systemami operacyjnymi S/390 (z/OS i z/VM), Odwołujący wskazał, że macierz HPE XP8 oferowana przez T-Mobile, a także przez wykonawców Symmetry i IT Solution Factor nie spełnia wymagania SWZ Załącznik nr 11, Rozdział 2, pkt. 12, czyli nie jest kompatybilna z systemami operacyjnymi S/390 (z/OS i z/VM). Zgodnie z wymaganiem z pkt 12. Rozdziału 2, każda Macierz ma obsługiwać serwery System z (serwery IBM serii z), z systemem operacyjnym S/390 (z/OS, z/VM, Linux)

Na stronie producenta macierzy HPE w rozdziale „Software Compatibility” dla Macierzy HPE XP8 można znaleźć tylko jeden z wymaganych systemów, czyli Linux.

Dowód:https://support.hpe.com/hpesc/public/docDisplay?docId=a00093353en_us&page=GUID-BC8A4697-118A-490F-B4E7-9A75F54C9D0A.html

W odpowiedzi na odwołanie Zamawiający w piśmie z dnia 21 sierpnia 2024 r. wniósł
‎o oddalenie odwołania w całości oraz o obciążanie Odwołującego kosztami postępowania,
‎w tym kosztami zastępstwa procesowego.

W uzasadnieniu pisma, Zamawiający wskazał, że zarzuty odwołania, zdaniem Zamawiającego, są pozbawione należytych podstaw, wobec czego odwołanie powinno zostać oddalone.

Odwołujący wskazał, że oferty wykonawców T-Mobile , WASKO, Symmetry oraz IT Solution Factor są niezgodne z Opisem Przedmiotu Zamówienia. Zamawiający wskazał, że istotne w przedmiocie sprawy było, jakie macierze dyskowe zostały zaoferowane przez każdego z ww. wykonawców, a także przez Odwołującego.

Zamawiający zwrócił uwagę, że Odwołujący jako jedyny Wykonawca zaoferował macierze dyskowe firmy IBM. Odwołujący próbował w odwołaniu dowieść, że macierze dyskowe firmy HPE oraz Hitachi nie spełniają wymagań postawionych przez Zamawiającego w Specyfikacji Warunków Zamówienia,
‎a ściślej rzecz ujmując – wymagań określonych w Szczegółowym opisie przedmiotu zamówienia (OPZ), stanowiącym Załącznik nr 11 do SWZ. Zamawiający podkreślił, że biorąc pod uwagę fakt, że na rynku wiodącymi producentami w obszarze rozwiązań macierzowych dla platformy mainframe są firmy HPE, IBM oraz Hitachi, wywód Odwołującego może prowadzić do wniosku, że jedynie macierz firmy IBM spełnia wymagania Zamawiającego, natomiast Zamawiający przygotował opis przedmiotu zamówienia (OPZ) w taki sposób, aby dopuścić rozwiązania co najmniej kilku podmiotów, w tym tych trzech, które są wiodącymi na rynku producentów, o czym świadczą i co potwierdzają m.in. zdefiniowane pozacenowe kryteria oceny ofert, odpowiedzi udzielone na etapie wyjaśnień treści SWZ oraz odpowiedzi na wcześniejsze odwołania. Nie bez znaczenia dla opisu wymagań względem OPZ był również fakt, że obecnie Zamawiający z powodzeniem eksploatuje u siebie, w obszarze mainframe, macierze dyskowe HPE XP7, które są poprzednią generacją macierzy oferowanych
‎w niniejszym postępowaniu przez wykonawców T-Mobile, Symmetry i IT Solution Factor.

Zarzuty postawione przez Odwołującego sprowadzały się, w ocenie Zamawiającego, do twierdzenia, że macierze producentów HPE oraz Hitachi nie spełniają poniższych wymagań Zamawiającego:

Zarzut 1: dotyczył macierzy HPE oraz Hitachi - brak możliwości wykonywania poleceń TSO, ICKDSF oraz DFSMSdss w zakresie różnych metod replikacji pomiędzy macierzami: XRC, PPRC, PPRC-XD, Global Mirror, Cascade PPRC, Multi Target PPRC.

Zarzut 2: dotyczył macierzy HPE oraz Hitachi - brak możliwości pracy macierzy w środowisku

GDPS/PPRC.

Zarzut 3: dotyczył macierzy HPE oraz Hitachi - możliwość rozbudowy macierzy z wykorzystaniem dysków obrotowych (HDD z ang. Hard Disk Drive).

Zarzut 4: dotyczył macierzy HPE - brak kompatybilności macierzy HPE XP8 z systemami operacyjnymi S/390 (z/OS, z/VM).

Na wstępie Odwołujący podniósł, że macierze HPE XP8 oraz Hitachi Vantara VSP 5600 są macierzami „podobnej konstrukcji”, co miałoby być argumentem wskazującym na niespełnienie wymagań OPZ przez obie ww. macierze. Jednak jak wskazał sam Odwołujący zarzut 4 dotyczył jedynie macierzy firmy HPE, co w ocenie Zamawiającego jednoznacznie przemawiało za tym, że macierze HPE XP8 oraz Hitachi Vantara VSP 5600 w pewnych elementach są od siebie różne.

Ponadto Odwołujący, w punkcie 2 uzasadnienia odwołania podniósł, że oferowane rozwiązania muszą być w pełni kompatybilne z platformą mainframe. Zamawiający zwrócił uwagę, że zgodnie
‎z pełną nazwą zamówienia, oferowane macierze muszą mieć możliwość współpracy z systemami otwartymi, czyli platformą inną niż platforma mainframe. Odwołujący również stwierdził, że macierze muszą być w pełni kompatybilne z platformą mainframe, po czym dodał „co ważne w sposób opisany w OPZ”. Zamawiający podkreślił, że oferowane macierze muszą być kompatybilne z platformą mainframe jedynie w zakresie określonym w OPZ, co ma istotne znaczenie w kontekście stawianych zarzutów.

W odniesieniu do zarzutu nr 1 odwołania, Zamawiający wskazał, że Odwołujący, powołując się na dokumentację IBM, przywołał zaawansowane metody replikacji zewnętrznej, dostępne w systemie operacyjnym z/OS na platformie mainframe. Odwołujący wymienił:

XRC – (ang. eXtended Remote Copy, znane również jako „Global Mirror for z/OS” – nie należy mylić z Global Mirror) – metoda asynchronicznej replikacji danych pomiędzy macierzami, która odbywa się na duże dystanse. Co istotne metoda ta zarządzana jest przez system operacyjny z/OS co w znaczący sposób konsumuje moc obliczeniową serwerów mainframe, na których system z/OS jest uruchomiony.

PPRC – (ang. Peer to Peer Remote Copy) – metoda synchronicznej replikacji danych pomiędzy macierzami, która odbywa się na krótsze dystanse (rekomendowane do 100 km)
‎z pominięciem systemu operacyjnego z/OS, z wykorzystaniem jedynie kontrolerów macierzy dyskowej. Co istotne implementacją PPRC jest oprogramowanie firmy Hitachi o nazwie TrueCopy.

PPRC-XD – (ang. PPRC eXtended Distance, znane również jako Global Copy) – metoda asynchronicznej replikacji danych pomiędzy macierzami. Przy zastosowaniu protokołu FICON (implementacja protokołu Fibre Channel) odległość pomiędzy macierzami dyskowymi jest nielimitowana.

Global Mirror (inaczej asynchroniczne PPRC) – metoda asynchronicznej replikacji danych pomiędzy macierzami.

Cascaded PPRC (zwany Metro/Global Copy) – rozwiązanie umożliwiające połączenie dwóch par PPRC: synchronicznego PPRC oraz PPRC-XD, które działają asynchronicznie. Celem kaskadowego PPRC jest utworzenia niedrogiej konfiguracji odzyskiwania danych po awarii na dużym dystansie.

Multi target PPRC – metoda replikacji, w której jedna macierz może być źródłem danych (dane podstawowe) dla wielu par PPRC. Rozwiązanie Multi-target PPRC umożliwia łączenie usług kopiowania w wielu różnych konfiguracjach (np. Metro Mirror, Global Mirror, Global Copy).

Zamawiający wskazał, że ma wiedzę, jakie możliwości udostępnia platforma mainframe. Jednak nie wszystkie metody replikacji zewnętrznej, spośród wymienionych przez Odwołującego, są objęte przedmiotem zamówienia, co jasno wskazuje, że oferowane macierze nie muszą być w pełni kompatybilne z platformą mainframe. Ponadto Odwołujący przywołał metody replikacji zewnętrznej, których producentem jest firma IBM i które obsługiwane są w sposób natywny przez oferowane przez Odwołującego macierze. Zamawiający dodał, że na niektóre wymienione przez Odwołującego metody replikacji zewnętrznej sam producent wymaga zakupu oddzielnych licencji, a Odwołujący nie wskazał

ich w swojej ofercie, a także w Specyfikacji technicznej oferowanych Macierzy Dyskowych, złożonej wraz z ofertą i sporządzonej wg Załącznika nr 1A do SWZ (dalej zwana jako Załącznik nr do oferty).

Zamawiający, wskazał, że kierując się zasadą równego traktowania uczestników postępowania
‎i zasadą uczciwej konkurencji, nie wymagał, aby każda z dostarczonych macierzy obsługiwała metody replikacji zewnętrznej opracowane przez firmę IBM. Każdy z producentów macierzy dostarcza własne metody replikacji zewnętrznej, które posiadają własne komendy, inne niż komendy obsługiwane przez rozwiązania IBM. Zamawiający opracowując wymagania celowo nie użył nazw metod replikacji zewnętrznej IBM, przywołanych przez Odwołującego. Jedynie w punkcie 19 (Rozdział 2 OPZ), Zamawiający wymagał, aby macierze zapewniały możliwość pracy w środowisku GDPS/PPRC.

Ponadto, zgodnie z wymaganiem określonym w punkcie 37 (Rozdział 2 OPZ), z poziomu systemu operacyjnego z/OS, tzn. z wykorzystaniem takich podsystemów jak TSO, DFSMSdss, ICKDSF, musi być możliwość wywoływania komend, które realizują funkcjonalności macierzy opisane
‎w punktach 14, 15, 16, 17, 18 i 19. Poprzez zastosowanie skryptowych języków programowania używanych w systemie operacyjnym z/OS (np. JCL, REXX), możliwe jest wywoływanie komend macierzy HPE XP8 oraz Hitachi Vantara VSP 5600. Różnica jest zatem pomiędzy wywoływaniem komend systemu operacyjnego z/OS, jak pisze Odwołujący, a wywoływaniem komend z poziomu systemu operacyjnego z/OS. Odwołujący błędnie uznał, że funkcje macierzowe muszą być wprost wywoływane przez komendy systemu operacyjnego. Natomiast wywoływanie funkcji macierzowych
‎z poziomu systemu operacyjnego może sprowadzać się do uruchomienia programu, który z kolei je wywoła.

Odnosząc się bezpośrednio do wymagań postawionych w OPZ, Zamawiający podkreślił, że niezależnie od faktu, że nie wymagał on konkretnych rozwiązań firmy IBM, nie wymagał także:

1) Rozwiązania XRC – OPZ Rozdział 2, pkt. 14 – „Każda Macierz musi posiadać funkcjonalność wykonywania zewnętrznych kopii danych do drugiej Macierzy, ….
‎z wykorzystaniem jedynie kontrolerów dyskowych”. Istotne jest, ze rozwiązanie IBM XRC zarządzane jest przez oprogramowanie uruchamiane na systemie operacyjnym z/OS, co w dużym stopniu wpływa na zużycie mocy obliczeniowej serwerów mainframe.

2) PPRC-XD oraz Cascaded PPRC - OPZ Rozdział 2, pkt. 14 – „Każda Macierz musi posiadać funkcjonalność wykonywania zewnętrznych kopii danych do drugiej Macierzy, znajdującej sięw drugim ośrodku przetwarzania, w odległości co najmniej 40 km…”. Rekomendowaną przezIBM odległością pomiędzy macierzami, pomiędzy którymi replikowane są dane przy pomocy zwykłego PPRC, jest 100 km. Natomiast odległość przy zastosowaniu PPRC-XD jest nielimitowana. W sposób oczywisty widać, że rozwiązania replikacji na duże odległości tj. PPRC-XD nie było wymagane przez Zamawiającego.

3) Global-Mirror (tryb niesynchroniczny, inaczej asynchroniczny) – Zamawiający co prawda zawarł wymaganie, aby oferowane macierze miały możliwość replikowania danych w trybie synchronicznym i niesynchronicznym (pkt 14, Rozdział 2 OPZ), jednak nie jest to równoznaczne i nie oznacza, że tryby te winny być realizowane za pośrednictwem rozwiązań IBM.

W odniesieniu do zarzutu nr 2 odwołania, Zamawiający wskazał, że w pkt. 19 Rozdział 2 OPZ określił, że Macierz A i Macierz B muszą zapewnić możliwość pracy w środowisku GDPS/PPRC z zapewnieniem określonych funkcjonalności. Zamawiający w tym punkcie opisał scenariusze wykonywania replikacji zewnętrznych. Oferowane macierze muszą mieć

możliwość pracy w środowisku GDPS/PPRC, w którym będą realizowane co najmniej wskazane scenariusze:

1. automatyzacji wykonania kopii dysków źródłowych (primary) na dyski docelowe (secondary) przy użyciu mechanizmu opisanego w punkcie 14,

2. automatyzacji wykonania kopii dysków źródłowych (secondary) na dyski docelowe (tertiary) przy użyciu mechanizmów opisanych w punkcie 16 podpunkt 1 i 2,

3. automatyzacji wykonania kopii opisanej w punkcie 2 powyżej na kilka oddzielnych grup dysków docelowych (tertiary),

4. automatyzacji czynności przełączenia przetwarzania wejścia/wyjścia na dyski docelowe (secondary) w trakcie planowanej i nieplanowanej niedostępności dysków źródłowych (primary) wykorzystując kopie opisaną w punkcie 1 powyżej - przełączenie przetwarzania nie powoduje przerwy w działaniu aplikacji hosta,

5. zarządzania z jednego miejsca zaimplementowanymi w GDPS/PPRC procedurami.

Zamawiający zaznaczył, że przywołany w punkcie 1 (powyżej) punkt 14 Rozdziału
‎2 OPZ odnosi się do replikacji zewnętrznych, natomiast przywołany w punkcie
‎2 (powyżej) punkt 16 Rozdziału 2 OPZ odnosi się do replikacji wewnątrz macierzy dyskowych. Odwołujący stwierdził, iż macierze HPE XP8 oraz Hitachi VSP 5600 nie mogą zapewnić spełnienia wymagań określonych w pkt 19.1, 19.2 i 19.3 Rozdziału 2 OPZ. Odwołujący jednak w żadnym miejscu nie wykazał, że realizacja takiego scenariusza jest niemożliwa. Istotne jest to, że zarówno macierze HPE XP8 jak i Hitachi VSP 5600 mają możliwość automatycznego wykonywania kopii zewnętrznych zgodnie z mechanizmem opisanym w punkcie 14 Rozdziału 2 OPZ oraz mają możliwość automatycznego wykonywania kopii wewnętrznych zgodniez mechanizmem opisanym w punkcie 16 podpunkt 1 i 2. Co istotne, procesy automatyzacji realizowane są obecnie przez środowisko GDPS/PPRC działające w instalacji Zamawiającego, a co za tym idzie, macierze nie muszą odpowiadać za proces automatyzacji.

Ponadto Odwołujący stwierdził, że po awarii dysków primary nieskuteczne będzie odwrócenie relacji kopiowania i odzyskanie spójnych danych z kopii na dyskach tertiary poprzez polecenie ICKDSF.

Po pierwsze, Zamawiający wskazał, w żadnym punkcie OPZ nie określił wymagania dotyczącego odzyskiwania danych z kopii tertiary. Jedynie w punkcie 19.2 Rozdziału 2 OPZ zawarł, że macierze mają mieć możliwość pracy w środowisku, w którym następować będzie przełączenie przetwarzania wejścia/wyjścia z dysków primary na dyski secondary, po niedostępności dysków primary.

Po drugie, Zamawiający, powołując się na argumenty podniesione we wcześniejszych fragmentach niniejszej odpowiedzi co do Zarzutu nr 1 wskazał, że nie wymagał, aby funkcje macierzowe były wywoływane poprzez polecenia ICKDSF, a jedynie z poziomu systemu operacyjnego z/OS.

W końcowej części Zarzutu 2, Odwołujący stwierdził, że jedynie macierze Hitachi VSP 5600 posiadają kwalifikację IBM do działania w środowisku GDPS. Zamawiający zauważył, że macierze Hitachi VSP 5600 są macierzami z serii Hitachi Virtual Storage Platform 5000, a co za tym idzie objęte są kwalifikacją IBM. Istotne dla sprawy również jest, co na wstępie zauważył sam Odwołujący, że macierze HPE XP8 są macierzami o podobnej konstrukcji co macierze Hitachi VSP 5600 tzn. są „OEM’em macierzy Hitachi Vantara”. Umowa OEM (skrót od ang. Original Equipment Manufacturer) odnosi się w tym przypadku do umowy zawartej pomiędzy Hitachi Vantara a HPE, na podstawie której firma HPE może używać macierzy Hitachi VSP 5600 pod swoją własną marką i nazwą (markuje jako swój własny). Oznacza to, że jeżeli macierz Hitachi posiada kwalifikację IBM do działania w środowisku GDPS, to macierz HPE również będzie działała w tym środowisku. Zamawiający zaznaczył, że nie wymagał formalnego potwierdzenie producenta takiej kwalifikacji.

W odniesieniu do zarzutu nr 3 odwołania, Zamawiający wskazał, że Odwołujący przywołał odpowiedź Zamawiającego na Pytanie nr 2, zawartą w piśmie nr 993200.271.IN-1130.2023, opublikowanym na stronie internetowej prowadzonego postępowania w dniu 22.11.2023 r., w której Zamawiający jednoznacznie wykluczył macierze dyskowe „w których nie można stosować dysków obrotowych do rozbudowy pojemności”. Zdaniem Odwołującego oznaczało to, że Zamawiający, zgodnie
‎z pozostałymi wymaganiami OPZ, jednoznacznie wskazał, że oferowana macierz musi być zbudowana jedynie z dysków półprzewodnikowych (flash). Z przytoczonego przez Odwołującego zapytania do SWZ (Pytanie nr 2) należało wnioskować, że istotą stosowania macierzy typu All-Flash a nie typu hybrydowego, jest zapewnienie odpowiedniej wydajności macierzy. Zostało to wyrażone przez Zamawiającego w wymaganiu zawartym w pkt 4 w Rozdziale 2 OPZ oraz
‎w odpowiedzi Zamawiającego na Pytanie nr 2.

Zamawiający podkreślił, że Odwołujący próbował udowodnić, że zarówno macierze Hitachi VSP 5600 oraz HPE XP8 mają możliwość rozbudowy o dyski obrotowe (HDD). Jednak w przypadku macierzy Hitachi Odwołujący w tabeli w punkcie 3 na stronie 18 Odwołania, błędnie zaznaczył, że dyski HDD występują w modelu Hitachi VSP 5600H, a taka macierz nie była oferowana przez WASKO S.A. Firma Hitachi posiada w swoim portfolio zarówno macierze typu All-Flash (model VSP 5600) oraz typu hybrydowego (model VSP 5600H). Opierając się na udostępnionej przez Odwołującego tabeli, na liście nie występują dyski HDD dla modelu VSP 5600.

Zamawiający wskazał, że biorąc pod uwagę, że macierz HPE XP8 jest „OEM’em macierzy Hitachi Vantara”, podobna sytuacja występuje w macierzach HPE. Firma HPE wprowadziła dla jednego modelu XP8 dwa SKU (ang. Stock Keeping Unit): R0L99A - HPE XP8 Hybrid Storage Array oraz R0K99A - HPE XP8 All Flash Storage Array. Oznaczenie SKU nie jest same w sobie modelem lub typem danego produktu, choć dotyczy konkretnego modelu macierzy. Dlatego też wykonawcy nie byli zobowiązani do podania SKU w ofertach.

Zamawiający ustanowił jako jedno z pozacenowych kryteriów oceny ofert - „Dostarczenie dysków w technologii NVMe (Kf5)”. Wszyscy Wykonawcy, którzy zaoferowali macierze HPE XP8 (Symmetry, TMobile, IT Solution Factor) zadeklarowali w swoich ofertach dostarczenie dysków w technologii NVMe, za co otrzymali dodatkowe punkty. Macierze HPE XP8 obsługują dwa rodzaje interfejsów dyskowych: 12 Gbps SAS lub NVMe PCIe. Poprzez interfejs 12 Gbps SAS (z ang. Serial-Attached SCSI) możliwe jest podłączenie dysków półprzewodnikowych SSD (z ang. Solit-State Drive) oraz dysków obrotowych HDD (Hard Disk Drive). Natomiast do interfejsu NVMe (z ang. Non-Volatile Memory Express) możliwe jest podłączenie jedynie dysków SSD. Macierze All-Flash są zaprojektowane z myślą o maksymalnym wykorzystaniu wydajności, jaką oferują dyski półprzewodnikowe (np. NVMe SSD). Cała architektura, w tym kontrolery, oprogramowanie zarządzające i buforowanie, są zoptymalizowane pod kątem niewielkich opóźnień i dużej liczby operacji IOPS (ang. Input/Output Operation Per Second), które oferowane są przez dyski NVMe SSD. Skonfigurowanie macierzy All-Flash dysków HDD, które maja znacznie wyższe opóźnienia i mniejszą wydajność, zmniejszyłoby ogólną wydajność platformy mainframe. Zmiana architektury All-Flash opartej tylko i wyłącznie na dyskach NVMe PCIe na architekturę hybrydową z dyskami HDD, o ile jest to możliwe, wiązałaby się z wymianą części komponentów macierzy, co generowałoby dodatkowe koszty po stronie Zamawiającego, a przy tym – spadek wydajności danej macierzy i całej platformy mainframe.

Dodatkowo Zamawiający podkreślił, że przywoływana w Zarzucie 3 odwołania odpowiedź Zamawiającego sformułowana została na konkretne Pytanie nr 2 Wykonawcy (vide pismo Zamawiającego nr 993200.271.IN-1130.2023, opublikowane na stronie internetowej prowadzonego postępowania w dniu 22.11.2023r.) i nie może służyć do wywodzenia jakichkolwiek wniosków,
‎w oderwaniu od okoliczności przedstawionych w treści tego pytania. Tymczasem w Pytaniu nr
‎2 wskazano konkretne urządzenie zbudowane w starszej technologii hybrydowej, to jest macierz IBM DS8886 model 981, co do której ma zachodzić zjawisko wykorzystania nie w pełni zasobów nośników flash, ze względu na marnowanie zasobów kontrolera na podłączenie dysków obrotowych HDD. W tej sytuacji odpowiedź Zamawiającego mogła odnosić się wyłącznie do takich urządzeń, do których nie tylko da się podłączyć dyski obrotowe, ale jedocześnie, w których spowodowałoby to analogiczny do opisanego powyżej skutek. Tymczasem Odwołujący nie wykazał, aby sam fakt potencjalnej możliwości podłączenia dysków obrotowych do macierzy oferowanych przez innych Wykonawców, uniemożliwiał obecnie pełne wykorzystanie zasobów tych ostatnich urządzeń.

Zamawiający podniósł również, że dostawa dodatkowych dysków dla rozbudowy macierzy nie jest przedmiotem zamówienia w niniejszym postępowaniu. Takie dodatkowe dyski Zamawiający musiałby nabyć w przyszłości, po przeprowadzeniu osobnego postępowania o udzielenie zamówienia publicznego, a dotyczące ich wymagania techniczne nie zostały obecnie sformułowane w treści OPZ. Zatem nie ma żadnych przeszkód do tego, aby przedmiotem kolejnego, jeszcze nie planowanego postępowania, były nośniki flash. W takiej sytuacji zarówno pytanie nr 2 jak i udzielona na nie odpowiedź nie odnosi się bezpośrednio do zakresu przedmiotowego zamówienia i tym samym nie może stanowić punktu odniesienia dla oceny zgodności złożonych ofert z warunkami ukształtowanymi przez Zamawiającego.

W odniesieniu do zarzutu nr 4 odwołania, Zamawiający wskazał, że Odwołujący przytoczył fragment dokumentacji producenta, w której wskazane są systemy operacyjne (OS od ang. Operating Systems), z którymi kompatybilne są macierze HPE XP8. Wśród kompatybilnych systemów operacyjnych wskazana jest nazwa „Mainframe”. Faktem jest, że na rynku nie ma takiego systemu operacyjnego
‎i dlatego jest to traktowane bardziej jak platforma technologiczna. Podobnie jak wskazany na liście system operacyjny „Linux”, który należy traktować jak wszystkie systemy operacyjne oparte na jądrze Linux np. Red Hat lub SUSE. Istotne jest, że również systemy operacyjne Red Hat oraz SUSE można instalować na platformie Mainframe. Dlatego Zamawiający w OPZ wskazał Linux, jako jeden
‎z systemów operacyjnych z którymi macierze muszą być kompatybilne.

Zamawiający zwrócił uwagę, że macierze HPE XP8, zgodnie ze specyfikacją dostępną na stronie producenta przywołanej również przez Odwołującego, obsługują protokół sieciowy FICON, który jest zastrzeżoną nazwą IBM i jest stosowany wyłącznie dla komputerów IBM Mainframe z systemem operacyjnym S/390 (z/OS). Stąd należało uznać, że określenie „Mainframe” przywołane przez Odwołującego na stronie HPE, oznacza systemy operacyjne S/390, w tym system operacyjny z/OS. Zostało to potwierdzone w jednej z dokumentacji „HPE XP8 Mainframe Host Attachment Guide”,
‎w której występuje system operacyjny z/OS jako jeden z obsługiwanych systemów.

Po przeprowadzeniu rozprawy, na podstawie zgromadzonego w sprawie materiału dowodowego oraz stanowisk Stron zawartych w odwołaniu i odpowiedzi na odwołanie, Krajowa Izba Odwoławcza ustaliła i zważyła, co następuje:

Izba ustaliła, iż nie została wypełniona żadna z przesłanek skutkujących odrzuceniem odwołania, a odwołanie nie zawierało braków formalnych i mogło zostać rozpoznane merytorycznie.

Izba ustaliła, że Odwołujący wykazał interes w korzystaniu ze środków ochrony prawnej. Wykonawca jest podmiotem, który złożył ofertę w postępowaniu i jest zainteresowany uzyskaniem zamówienia oraz możliwość poniesienia szkody w wyniku naruszenia przez Zamawiającego przepisów ustawy.

Do postępowania odwoławczego przystąpienie po stronie Zamawiającego zgłosili wykonawcy: Wasko Spółka Akcyjna z siedzibą w Gliwicach, dalej: „Przystępujący Wasko” oraz T-Mobile Polska Business Solutions Spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie, dalej: „Przystępujący
‎T-Mobile”.

Zgłoszenia spełniały warunki określone w art. 525 ust. 1 ustawy Pzp.

Przystępujący T-Mobile w piśmie z 22 sierpnia 2024 r. wniósł o oddalenie odwołania oraz przedstawił swoje stanowisko.

Przystępujący Wasko w piśmie z 23 sierpnia 2024 r. wniósł o oddalenie odwołania oraz przedstawił swoje stanowisko.

Odwołujący w piśmie z 22 sierpnia 2024 r. przedstawił replikę do odpowiedzi Zamawiającego.

Izba zaliczyła do materiału dowodowego sprawy dokumenty pochodzące z akt sprawy odwoławczej, załączone do pism uczestników postępowania odwoławczego oraz złożone podczas rozprawy w dniu 23 sierpnia 2024 r.

Izba pominęła złożone na rozprawie w dniu 23 sierpnia trzy dowody, złożone przez Odwołującego: na okoliczność wprowadzenia do obrotu w 2019 r. rodziny macierzy Hitachi Vantara, wydruku ze strony medium technicznego oraz dokumentu przedstawionego w celu wykazania, że konkretny model macierzy VSP 5600 wprowadzono w 2021 r. w związku z nieprzedstawieniem tłumaczenia powyższych dokumentów na język polski.

Na podstawie przekazanej dokumentacji postępowania Izba ustaliła, że Zamawiający Zakład Ubezpieczeń Społecznych, prowadzi postępowanie o udzielenie zamówieniapn. „Zakup Macierzy dyskowych na platformę MF z możliwością rozbudowy do systemów otwartych”.

Zamawiający w załączniku nr 11 do SWZ – Rozdział 2 – Szczegółowe wymagania dla Macierzy Dyskowych przewidział, zgodnie z pkt 37, iż:

37. Macierze muszą posiadać możliwość wywoływania funkcji Macierzowych opisanych w punktach 14, 15, 16, 17, 18, 19 z poziomu systemu operacyjnego z/OS (DFSMSdss, ICKDSF, TSO)
‎i raportowania o statusie.

Zgodnie z pkt 14:

14. Każda Macierz musi posiadać funkcjonalność wykonywania zewnętrznych kopii danych do drugiej Macierzy, znajdującej się w drugim ośrodku przetwarzania, w odległości co najmniej 40 km za pośrednictwem DWDM. Funkcja musi być realizowana przy użyciu mechanizmów Macierzy, dla grupy wielu wolumenów dyskowych w celu uzyskania spójnej (konsystentnej) kopii tych wolumenów (tzw. fizyczna replikacja danych) w trybie synchronicznym oraz niesynchronicznym z wykorzystaniem jedynie kontrolerów dyskowych.

Zgodnie z pkt 15:

15. W przypadku zawieszenia lub zerwania fizycznej replikacji danych, musi istnieć możliwość resynchronizacji wolumenów pomiędzy Macierzami w trybie różnicowym (propagacja tylko tych danych, które uległy zmianie).

Zgodnie z pkt 16:

16. Macierz musi posiadać możliwość wykonywania następujących wewnętrznych (w ramach pojedynczej Macierzy) kopii danych:

1. kopia grupy wolumenów dyskowych wykonana przy użyciu mechanizmów Macierzy. Wolumeny źródłowe i docelowe są dostępne dla aplikacji hosta do aktualizacji natychmiast po wykonaniu kopii. Dane fizyczne są kopiowane z wolumenów źródłowych na docelowe w tle w sposób minimalnie wpływający na wydajność Macierzy,

2. kopia grupy wolumenów dyskowych wykonana przy użyciu mechanizmów Macierzy. Wolumeny źródłowe i docelowe są dostępne dla aplikacji hosta do aktualizacji natychmiast po wykonaniu kopii. Dane fizyczne nie są kopiowane z wolumenów źródłowych na docelowe z wyjątkiem ścieżek które ulegają zmianie na wolumenach źródłowych - przed zmianą te ścieżki są kopiowane. Praca na takich danych nie może powodować pogorszenia wydajności o więcej niż 10%,

3. kopia zbioru danych wykonana przy użyciu mechanizmów Macierzy. Zbiór danych może zajmować część jednego lub wielu wolumenów dyskowych. Zbiór źródłowy i docelowy są dostępne dla aplikacji hosta do aktualizacji natychmiast po wykonaniu kopii. Dane fizyczne są kopiowane z w tle w sposób minimalnie wpływający na wydajność Macierzy. Mechanizm wykonujący kopie musi być zgodne z IBM FlashCopy V2 tzn. muszą w sposób poprawny interpretować i wykonywać komendy FlashCopy V2 (tzn. być kompatybilne z FlashCopy V2).

Zgodnie z pkt 17:

17. Dostarczony mechanizm replikacji pomiędzy Macierzą A i Macierzą B musi zagwarantować, iż
‎w przypadku awarii Macierzy A, nie dojdzie do utraty danych na Macierzy B.

Zgodnie z pkt 18:

18. Mechanizm replikacji zewnętrznej musi zapewnić możliwość dynamicznej zmiany trybu i kierunku replikacji.

Zgodnie z pkt 19:

19. Macierz A i Macierz B muszą zapewnić możliwość pracy w środowisku GDPS/PPRC
‎z zapewnieniem następujących funkcjonalności:

1. automatyzacji wykonania kopii dysków źródłowych (primary) na dyski docelowe (secondary) przy użyciu mechanizmu opisanego w punkcie 14,

2. automatyzacji wykonania kopii dysków źródłowych (secondary) na dyski docelowe (tertiary) przy użyciu mechanizmów opisanych w punkcie 0 podpunkt 1 i 2,

3. automatyzacji wykonania kopii opisanej w punkcie 2 powyżej na kilka oddzielnych grup dysków docelowych (tertiary),

4. automatyzacji czynności przełączenia przetwarzania wejścia/wyjścia na dyski docelowe (secondary) w trakcie planowanej i nieplanowanej niedostępności dysków źródłowych (primary) wykorzystując kopie opisaną w punkcie 1 powyżej - przełączenie przetwarzania nie powoduje przerwy w działaniu aplikacji hosta,

5. zarządzania z jednego miejsca zaimplementowanymi w GDPS/PPRC procedurami.

Zgodnie z pkt 4:

Każda Macierz ma być zbudowana w oparciu o nośniki w technologii flash.

W dniu 26 lipca 2024 r. Zamawiający przekazał informację o wyborze oferty Przystępującego Wasko jako oferty najkorzystniejszej.

Od powyższej czynności oraz zaniechania odrzucenia ofert wykonawców: Wasko S.A., T-Mobile Polska Business Solutions, Symmetry Sp. z o.o. oraz IT Solution Faktor Sp. z o.o., jako niezgodnych z warunkami zamówienia, w dniu 5 sierpnia 2024 r. odwołanie wniósł wykonawca Advatech Spółka
‎z ograniczoną odpowiedzialnością z siedzibą we Wrocławiu.

Izba umorzyła postępowanie odwoławcze w zakresie zarzutu nr 4 w związku z jego cofnięciem w tym zakresie.

Stosownie do art. 520 ust. 1 ustawy Pzp, odwołujący może cofnąć odwołanie do czasu zamknięcia rozprawy.

Odwołujący na rozprawie w dniu 23 sierpnia 2024 r. cofnął odwołanie w zakresie zarzutu nr 4, wobec powyższego w powyższym zakresie postępowanie odwoławcze podlegało umorzeniu.

Po zapoznaniu się z argumentacją stron i uczestnika postępowania odwoławczego, wyrażoną we wniesionych w nim pismach oraz przedstawioną w trakcie rozprawy Izba uznała, że odwołanie
‎w zakresie zarzutów nr 1-3 podlegało oddaleniu.

Zgodnie z art. 226 ust. 1 pkt 5 ustawy Pzp, Zamawiający odrzuca ofertę, jeżeli jej treść jest niezgoda
‎z warunkami zamówienia.

Stosownie do art. 7 pkt 29 ustawy Pzp, 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.

Izba wskazuje, że odrzucenie oferty wykonawcy, na podstawie art. 226 ust. 1 pkt
‎5 ustawy Pzp, jest możliwe wówczas, gdy ta niezgodność ma charakter zasadniczy i nieusuwalny,
‎a Zamawiający może w sposób jednoznaczny stwierdzić, mając na uwadze treść złożonej oferty, że nie jest możliwa realizacja zamierzonego w postępowaniu celu.

Odnosząc się do zarzut nr 1 odwołania, Izba wskazuje:

W pkt 37 w Rozdziale 2 – Szczegółowe wymagania dla Macierzy dyskowych, Zamawiający przewidział, że macierze muszą posiadać możliwość wywoływania funkcji Macierzowych opisanych
‎w punktach od 14 do 19 z poziomu operacyjnego z/OS (DFSMSdss, ICKDSF, TSO) i raportowania
‎o statusie, co w ocenie Izby oznaczało, że powyższe wymaganie odnosiło się do konieczności realizacji funkcji macierzowych, które Zamawiający opisał w punktach 14-19 z poziomu systemu operacyjnego z/OS, a nie wyłącznie przy użyciu wymienionych programów - DFSMSdss, ICKDSF, TSO.

Tymczasem Odwołujący w odwołaniu wskazał na tylko jedno możliwe w powyższym przypadku, rozwiązanie, które oferuje producent IBM. Uzasadnił to faktem, iż wymagane przez Zamawiającego programy DFSMSdss, ICKDSF, TSO współpracują z funkcjonalnościami charakterystycznymi dla macierzy IBM, takimi jak PPRC, XD czy Global Mirror.

Odwołujący przedstawił Tabelę niespełnionych wymagań, w której wskazano metody replikacji, XRC, PPEC-XD czy Global Mirror, którymi nie posługiwał się Zamawiający przy formułowaniu warunków zamówienia.

Odpowiadając na zarzut, Przystępujący T-Mobile wskazał, że również inne niż macierze producenta IBM, w tym oferowana przez niego macierz XP8, zapewniają spełnienie wymagań Zamawiającego z pkt 37 w Rozdziale 2. Dzieje się to w inny sposób niż w przypadku macierzy IBM – np. poprzez wykorzystanie własnych wbudowanych technologii zewnętrznych kopii danych (zwanej również fizyczną replikacją danych), w tym technologie replikacji niesynchronicznej. Jednak producent macierzy posługuje się własną terminologią.

Natomiast Przystępujący Wasko w odpowiedzi na ww. zarzut, wskazał, że
‎z dokumentacji Flashcopy®User Guide – producenta Hitachi Vantara (oznaczony
‎w piśmie Przystępującego Wasko jako dowód nr 1) wynika, że zaoferowane przez niego rozwiązanie zapewnia możliwość wywołania funkcji replikacji przy pomocy programów DFSMSdss, ICKDSF oraz TSO.

Zamawiający w celu opisu swoich wymagań nie posłużył się pojęciami funkcjonalności właściwymi tylko dla macierzy IBM, która jak wskazał Przystępujący T-Mobile, wynika z dokumentu „IBM DS8900 Copy Services”.

Wobec powyższego, w ocenie Izby, Odwołujący nie wykazał niezgodności ofert wykonawców Wasko oraz T-Mobile z wymaganiami sformułowanymi w pkt 37 Rozdziału 2 OPZ.

Wobec powyższego zarzut nr 1 odwołania podlegał oddaleniu.

W odniesieniu do zarzutu nr 2 odwołania, Izba wskazuje:

W celu wykazania, że oferty wykonawców Wasko, T-Moblie, Symmetry i IT Solution Factor są niezgodne z warunkami zamówienia, tzn. nie spełniają wymogu wskazanego w pkt 19 w Rozdziale 2 OPZ – pracy w środowisku GDPS/PPRC, Odwołujący wskazał, że macierze VSP 5600 oraz macierze HPE XP8 nie znajdują się na opublikowanej przez dostawcę usługi GDPS pod linkiem: , liście macierzy spełniających wymagania z pkt 19 ppkt 19.1-19.5 w Rozdziale 2 OPZ.

W odpowiedzi na powyższy zarzut, Przystępujący T-Mobile wskazał, na liście, na którą powołuje się Odwołujący. znajduje się pojęcie „VSP 5000 series”. VSP 5000 to rodzina macierzy, do której należy m.in. model VSP 5600. Nie istnieje natomiast macierz oznaczona jako Hitachi VSP 5000. Ponieważ oferowane przez Przystępującego T-Mobile macierze HPE XP8 są tożsame z macierzami Hitachi Vantara z rodziny VSP 5000 (co wynika ze wskazanej przez Przystępującego
‎T-Mobile informacji analityka The Futurum Group na stronie , zgodnie z którą HPE odsprzedaje VSP 5000, wraz z opcjami oprogramowania, jako HPE XP8), dlatego na listach innych producentów np. IBM wymieniane są tylko macierze Hitachiz rodziny VSP 5000. Macierze HPE XP8 są pomijane z uwagi na to, że są traktowane jako tożsame z VSP 5000.

Przystępujący Wasko w odniesieniu do powyższego zarzutu, przedstawił dowód – załącznik do swojego pisma z 22 sierpnia 2024 r. w postaci raportu z testu kwalifikacyjnego dla Hitachi VSP series w środowisku GDPS/PPRC z wraz z tłumaczeniem, z którego wynika, że urządzenia Hitachi VSP serii 5000 przeszły testy i spełniają wymagania dla pracy w środowisku GDPS/PPRC.

Wobec powyższego, ocenie Izby Odwołujący nie wykazał, iż oferty wykonawców Wasko oraz T-Mobile nie są zgodne z wymaganiami Zamawiającego z pkt 19 Rozdziału 2 SWZ, a zatem zarzut nr
‎2 odwołania podlegał oddaleniu.

W odniesieniu do zarzutu nr 3 odwołania, Izba wskazuje:

Odwołujący w uzasadnieniu zarzutu wskazał, zgodnie z odpowiedzią Zamawiającego z 20 listopada 2023 r. do wymagania określonego w pkt 4 w Rozdziale 2 OPZ: „Zamawiający informuje, iż wymaga dostarczenia Macierzy, w których nie można stosować dysków obrotowych do rozbudowy pojemności, co jednoznacznie wynika z aktualnej treści wymagania zawartego w pkt 4 Rozdziału
‎2 Załącznika 11 do SWZ – Szczegółowy opis Przedmiotu Zamówienia (OPZ)”, do rozbudowy macierzy Zamawiający nie dopuścił wykorzystania dysków obrotowych.

Tymczasem, jak wskazał Odwołujący, w odniesieniu do macierzy zaoferowanej przez Przystępującego T-Mobile, zgodnie z dokumentacją dostępną na stronie producenta macierzy HPE XP, macierz ta może być rozbudowywana przez powolne dyski obrotowe HDD, co nie spełnia wymagania Zamawiającego, które wykluczało taka możliwość.

Przystępujący T-Mobile w odpowiedzi na zarzut wskazał, że oferuje dostarczenie dysku w technologii NVMe, która jest obsługiwana wyłącznie przez dyski flash, a dyski obrotowe stosowane w macierzy XP8 obsługują wyłącznie technologię SAS, co wynika z dokumentacji, którą sam Odwołujący przytoczył w uzasadnieniu swojego zarzutu.

Natomiast Przystępujący Wasko odnosząc się do zarzutu nr 3 odwołania wskazał, że zaoferował macierz oznaczoną symbolem 5600, a nie 5600H, do której odnosi się wskazywane przez Odwołującego (znajdujące się na stronie Hitachi z wykazem dysków instalowanych w macierzy) oznaczenie HDD.

Zarzuty Odwołującego okazały się w powyższym zakresie chybione.

Mając na uwadze powyższe okoliczności, Izba uznała, że Odwołujący nie wykazał, iż oferty wykonawców Wasko oraz T-Moblie są niezgodne z wymaganiami Zamawiającego – do rozbudowy macierzy nie dopuszcza się wykorzystania dysków obrotowych.

A zatem zarzut nr 3 odwołania podlegał oddaleniu.

Izba oddaliła zarzuty dotyczące braku spełnienia przez wykonawców Symmetry i IT Solution Factor wymagań Zamawiającego, o których była mowa w zarzutach 1-3 odwołania z uwagi na niewykazanie przez Odwołującego interesu w uzyskaniu zamówienia i możliwości poniesienia szkody w wyniku naruszenia przez Zamawiającego przepisów ustawy w powyższym zakresie. Odwołujący zajął pozycję trzecią w rankingu ofert – po wykonawcach: Wasko S.A. oraz T-Mobile Polska Business Solutions Sp. z o.o.

O kosztach postępowania odwoławczego orzeczono stosownie do wyniku postępowania - na podstawie  i  ustawy Pzp oraz w oparciu o przepisy ust. 2 pkt 1 w zw. z § 5 pkt 2 lit. b rozporządzenia Prezesa Rady Ministrów z dnia 30 grudnia 2020 r. w sprawie szczegółowych rodzajów kosztów postępowania odwoławczego, ich rozliczania oraz wysokości i sposobu pobierania wpisu od odwołania.

Wobec oddalenia odwołania w całości, koszty ponosił Odwołujący.

Wobec powyższego orzeczono, jak w sentencji.

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

………………………

………………………