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ę AdvatechSpół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
Uzasadnie nie
Zakład Ubezpieczeń Społecznych, dalej: „Zamawiający” prowadzi postępowanie o udzielenie zamówienia pn. „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 SW Z – 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 SW Z – 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 SW Z 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 SW Z 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 SW Z 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 SW Z 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 Aldriven 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 SW Z 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 SW Z), 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 SW Z 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 SW Z 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 SW Z 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 SW Z) 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 SW Z. 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
SW Z, 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 SW Z,
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 SW Z. 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
S W Z. 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/mk95hc104/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-environmentwhen-linking-with-replication-manager/creating-initialization-parameters/examples-of-specifying-initializationparameters/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 SW Z. 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 SW Z. Oprogramowanie VMware oraz system
operacyjny, na którym będzie zainstalowane oprogramowanie do zarządzania, jest oprogramowaniem nie wynikającym
wprost
z zapisów SW Z, 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ówienia pn. „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 SW Z.
Zamawiający w załączniku 1A do SW Z – 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 SW Z 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 SW Z 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ł oprogramowanie
Vmware 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 (SW Z), 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 SW Z
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ść SIW Z 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 SIW Z. 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 SW Z,
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 TMobile.
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 TMobile, 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 DW DM. 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 TMobile dostarczył wraz z Macierzami licencje na obsługę XRC – czego nie uczynił, jak wynika z wypełnionego załącznika
1A do SW Z 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 SW Z 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ł, żefunkcjonalność 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 SW Z (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 SW Z 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-optionmodes-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-toPeer” (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 SW Z 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 SW Z 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 SW Z 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=GUID82F20103-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-490FB4E7-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 SW Z. 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 SW Z 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 SW Z (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 AllFlash (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ówienia pn. „Zakup Macierzy dyskowych na platformę MF z możliwością
rozbudowy do systemów otwartych”.
Zamawiający w załączniku nr 11 do SW Z – 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 DW DM. 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 SW Z – 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 TMoblie 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: ………………………
………………………
………………………