KIO 2776/24 KIO 2791/24 WYROK Warszawa, dnia 28 sierpnia 2024 r.

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; 

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  

W pozostałym zakresie oddala odwołanie 

4.  K

osztami 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: 

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, 

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.  K

osztami postępowania w sprawie o sygn. akt KIO 2791/24 obciąża wykonawcę Advatech  

Spółka z ograniczoną odpowiedzialnością z siedzibą we Wrocławiu i: 

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, 

zasądza  od  wykonawcy  Advatech  Spółka  z  ograniczoną  odpowiedzialnością  

z  siedzibą  we  Wrocławiu  na  rzecz  zamawiającego  Zakład  Ubezpieczeń 

Społecznych kwotę 3.600 zł 00 gr (słownie: trzy tysiące sześćset złotych 00 groszy), 

stanowiącą koszty postępowania odwoławczego poniesione z tytułu wynagrodzenia 

pełnomocnika. 

Na  orzeczenie  - 

w  terminie  14  dni  od  dnia  jego  doręczenia  -  przysługuje  skarga  za 

pośrednictwem  Prezesa  Krajowej  Izby  Odwoławczej  do  Sądu  Okręgowego  w  Warszawie  - 

Sądu Zamówień Publicznych. 

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

………………………… 

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

Sygn. akt: KIO 2776/24  

KIO 2791/24 

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

Zakład  Ubezpieczeń  Społecznych,  dalej:  „Zamawiający”  prowadzi  postępowanie  o  udzielenie 

zamó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 SWZ – Specyfikacja techniczna 

oferowanych  Macierzy  Dyskowych  nazwy  jednego  z  oferowanych 

oprogramowań  do 

zarządzania/elementów oprogramowania do zarządzania – „agenta do zarządzania replikacją”, 

co uniemożliwia weryfikację jego zgodności z wymaganiami Zamawiającego i powoduje, że 

Zamawiający nie wie co jest przedmiotem oferty, 

b. 

Wasko  wskazał  oprogramowanie  do  zarzadzania  w  sposób,  który  uniemożliwia  jego 

jednoznaczną identyfikację, a przeprowadzano przez Odwołującego analiza wskazuje, że pod 

taką nazwą nie występuje oprogramowanie spełniające wymagania Zamawiającego, 

c. 

Wasko  nie  wskazał  w  załączniku  nr  1A  do  SWZ  –  Specyfikacja  techniczna  oferowanych 

Macierzy Dyskowych oprogramowania 

niezbędnego do monitorowania macierzy z poziomu 

maszyny  wirtualnej 

–  oprogramowania  do  systemu  wirtualizacji  i  oprogramowania  systemu 

operacyjnego maszyny wirtualnej, pomimo 

że takie rozwiązanie oferował, co jest niezgodne  

z rozdz. II pkt 34 pkt 3 OPZ, 

ewentualnie,  gdyby  wbrew  rozdz.  II  pkt  34  ppkt  3  OPZ 

Izba  ustaliła,  że  istniała  potrzeba 

wskazywania w pkt 4 załącznika nr 1A do SWZ licencji do oprogramowania niezbędnego do 

monitorowania macierzy z poziomu maszyny wirtualnej, art. 226 ust. 1 pkt 5 Pzp w zw. z art. 16 

pkt 1 -3 Pzp 

poprzez zaniechanie odrzucenia oferty złożonej przez Wasko, pomimo że jest ona 

niezgodna z warunkami 

zamówienia w zakresie, w jakim Wasko zaoferował rozwiązanie, które 

wymaga licencji

, które udzielane są wyłącznie na czas określony, podczas gdy Zamawiający  

w rozdz. II pkt 30 OPZ wymagał, aby wszystkie dostarczone licencje udzielone były na czas 

nieograniczony, 

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

najkorzystniejszej zgodnie z przepisami ustawy. 

O

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

1.  u

nieważnienie czynności wyboru oferty najkorzystniejszej, 

powtórzenia  czynności  badania  i  oceny  ofert  z  uwzględnieniem  zarzutów  postawionych  

w odwołaniu, tj. odrzucenie oferty złożonej przez Wasko, 

3.  dokonania wyboru ofert najkorzystniejszej. 

W uzasadnieniu odwołania w zakresie zarzutu nr 1, Odwołujący wskazał, w załączniku nr 1A do SWZ 

Specyfikacja techniczna oferowanych Macierzy Dyskowych, 

który bez wątpienia stanowi treść oferty, 

Z

amawiają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. W

asko 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ń 

Z

amawiają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  z

arzą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. D

ziałanie Wasko, w ocenie Odwołującego, można porównać w drodze analogii 

do  sytuacji, 

gdy  w  postępowaniu  np.  na  dostawę  komputerów  osobistych  w  ofercie  wskazano 

„Microsoft Windows 10 plus system do obsługi poczty elektronicznej” zamiast „Microsoft Windows  

10 plus Microsoft Outlook wraz z doprecyzowaniem wersji tego oprogramowania

” (czyli bez wskazania 

nazwy oprogramowania do obsługi poczty elektronicznej). 

Spos

ób  ukształtowania  treści  złożonego  przez  Wasko  załącznika  1A  do  SWZ  powoduje,  że 

Zamawiający nie miał możliwości zweryfikowania, czy oferowane Oprogramowanie do Zarządzania, 

w ramach którego Wasko wskazał „agenta”, spełnia wymaganie podane w OPZ zarówno w zakresie 

funkcjonalności jak i wymaganego przez Zamawiającego sposobu licencjonowania, gdyż nie wiadomo 

czym jest 

„agent”, co wykonawca przez to rozumiał. Zamawiający nie dokonał więc (bo treść oferty mu 

tego  nie  umożliwiała)  należytej  weryfikacji  oferty  Wasko.  Zamawiających  z  jednej  strony,  w  celu 

zidentyfikowania  przedmiotu  oferty  wymagał  dokładnego  wskazania  informacji  dotyczącej 

oferowanego Oprogramowania do Z

arzą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. 

T

ak 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 

W

asko  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 

Z

arzą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  Z

amawiającego,  w  sytuacji  gdy  uniemożliwia  to  weryfikację  zgodności 

przedmiotu oferty z wymaganiami. 

Wasko  w  Specyfikacji  technicznej  oferowanych  Macierzy  D

yskowych  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 O

dwołujący zwrócił uwagę, że po upływie terminu składania ofert nie istnieje możliwość 

doprecyzowania oferty, 

gdyż stanowiłoby to de facto zmianę jej treści i byłoby sprzeczne z art. 223 ust. 

1 in fine Ppz. 

W odniesieniu do zarzutu nr 

2 odwołania, Odwołujący wskazał, że w wierszu nr 3 załącznika 1A do 

SWZ dotyczącym oprogramowania do zarządzania, Wasko wskazał m.in. „pakiet licencji Advanced  

w  tym  OpsCenter

” producenta  Hitachi Vantara.  Nie podał jednak jednoznacznie, który  z pakietów 

oprogramowania H

itachi 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  Z

amawiają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 

Ops

Center 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 Ops

Center 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: 

C

ał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  

(I

nformacje dotyczące zawartości pakietów pochodzą z dokumentu „Modern Data Center Software 

Solutions  for  Al-  driven  Operations

”  dostępnego  na  stronie  internetowej  producenta: 

https://www.hitachivantara.com/en-us/pdf/datasheet/base-advaced-software-packages-for-vsp-5000-

series-datasheet.pdf)  

Wobec  tego,  oferta  W

asko  jest  niezgodna  z  warunkami  zamówienia  również  z  uwagi  na  błędne 

wskazanie nazwy Oprogramowania do Z

arzą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  W

asko  nie  będzie  w  stanie  dostarczyć  pakietów  oprogramowania  do 

zarządzania, które będzie oferowane przez Hitachi, a jednocześnie będzie zgodne z ofertą i będzie 

zapewniało wymagane przez Zamawiającego funkcjonalności. Jeżeli Wasko uznało, że do realizacji 

zamówienia  niezbędne  są  oba  pakiety  -  Advanced  Package  Mainframe  Systems  oraz  jeden  

z pakietów dla systemów otwartych - Base Package Open Systems lub Advanced Package Open 

Systems, 

to  powinien  wskazać  w  pkt  3  załącznika  numer  1A  do  SWZ  oba  oprogramowania. 

W

ykonawca  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: 

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, 

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, 

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  W

asko  wskazał:  „Instalacja: 

Management server (VM - Virtual Machine) plus agent na 

zOS”. 

W

ykonawca 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, 

W

ykonawca 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 https://docs.hitachivantara.com/r/en-us/ops-

center/11.0.x/mk-99ops002/hitachi-ops-center-system-requirementsa/hitachi-ops-center-ova-

requirements/included-products,  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. 

O

prócz oprogramowania do zarządzania (które należało wskazać w pkt 3 załącznik nr 1A do SWZ), 

realizacja zamówienia przez Wasko będzie wymagała również licencji na system wirtualizacji, a więc 

dodatkowego oprogramowania. S

koro z powyższego wynika, że Ops Center w wersji na maszynę 

wirtualną wymaga oprogramowania VMware vSphere Hypervisor, a Zamawiający wyraźnie wymagał, 

że  należy  „dostarczyć  obraz  maszyny  wirtualnej  wraz  ze  wszystkimi  wymaganymi  licencjami”,  

to Wasko powinien takie 

oprogramowanie dostarczyć w ramach oferty, a co za tym idzie powinien  

w  pkt  4 

załącznika  nr  1A  do  SWZ  wskazać  nazwę,  producenta  i  sposób  licencjonowania  tego 

oprogramowania. Oprogramowanie VMware 

jest bowiem osobnym niezależnym produktem, którego 

producentem jest Vmware, a nie Hitachi. Z 

treści SWZ nie wynika, że Zamawiający posiada Vmware, 

z  którego  wykonawca  będzie  mógł  korzystać,  wobec  tego  niezbędne  było  jego  uwzględnienie  

w ofercie. 

Odwołujący wskazał, że z uwagi na wybrany przez Wasko sposób realizacji zamówienia, do realizacji 

zamówienia niezbędne będzie również oprogramowanie systemu operacyjnego maszyny wirtualnej. 

W 

tym zakresie wykonawca może w zasadzie skorzystać z różnych rozwiązań, w tym nawet rozwiązań 

darmowych typu Open Source, n

awet 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 O

dwoł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 

o

programowaniem  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  W

asko  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. 

W

obec 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. O

ferta jest więc niezgodna z warunkami zamówienia. 

W odniesieniu do zarzutu ewentualnego O

dwołujący wskazał, że nawet gdyby uznać, że nie istniała 

potrzeba wskazywanie w pkt 4 

załącznika nr 1A do SWZ licencji do oprogramowania niezbędnego do 

monitorowania  macierzy  z  poziomu  maszyny  wirtualnej, 

co  byłoby  wprost  sprzeczne  

z brzmieniem rozdz. II pkt 34 ppkt 3 OPZ, to O

dwoł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.  

Z

godnie  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 

VM

ware zmienił swoją politykę i od tego czasu nie oferuje już licencji wieczystych, nieograniczonych, 

a jedynie licencji czasowe, 

co odbiło się szerokim echem w środowisku IT. Odwołujący zaprezentował 

przykładowe informacje w tym zakresie zamieszczona na stronach branżowych. 

Odwołujący  wskazał,  że  licencje  czasowe  nie  spełniają  wymagania,  wyspecyfikowanego  

w rozdziale II pkt 30 OPZ. Skoro zaoferowane przez Wasko oprogramowanie OpsCenter (wskazano 

je w pkt 

3 załącznika nr 1A do SWZ) w wersji na maszynę wirtualną wymaga oprogramowania VMware 

vSphere Hypervisor, co wynika z oficjalnej strony producenta Hitachi Vantara, to zaoferowanie tego 

rozwiązania  i  tego  oprogramowania  de  facto  oznacza  brak  możliwości  dostarczenia  rozwiązania 

zgodnego z warunkami zamówienia. Licencje do programowania VMware vSphere Hypervisor nie są 

już bowiem udzielane na czas nieoznaczone, a taki wymóg sformułował Zamawiający w OPZ.  

Na  tym  etapie  Wasko 

nie  może  dokonać  modyfikacji  treści  oferty,  a  Zamawiający  nie  może 

zrezygnować  z  tego  wymagania,  gdyż  stanowiłoby  to,  co  najmniej,  naruszenie  zasady  równego 

traktowania wykonawców i uczciwej konkurencji. 

Odwołujący podkreślił, że zgodnie z art. 226 ust. 1 pkt 5 Pzp oferta podlega odrzuceniu, jeżeli jej treść 

jest  niezgodna  z  warunkami  zamówienia.  Stosownie  zaś  do  treści  art.  7  punkt  29  Pzp  warunki 

zamówienia  to  warunki,  które  dotyczą  zamówienia  lub  postępowania  o  udzielenie  zamówienia, 

wynikające w szczególności z opisu przedmiotu zamówienia. Przepisy wskazują, że OPZ jest częścią 

dokumentacji postępowania, pod kątem zgodności, z którą Zamawiający zobowiązany jest oceniać 

oferty. W

obec tego niespełnienie przez oferowane oprogramowanie wymagań wyspecyfikowanych  

w  OPZ oraz  brak zaoferowania 

niezbędnego oprogramowania należy traktować jako niezgodność  

z warunkami zamówienia, a zatem oferta Wasko powinna zostać odrzucona na podstawie art. 226 ust. 

1 pkt 5 Pzp. 

W 

odpowiedzi na odwołanie – piśmie z 21 sierpnia 2024 r. Zamawiający wniósł o oddalenie odwołania 

w  całości  oraz  obciążanie  Odwołującego  kosztami  postępowania,  w  tym  kosztami  zastępstwa 

procesowego. 

W uzasadnieniu pisma Zamawiający wskazał, że zarzuty odwołania jego zdaniem są pozbawione 

należytych podstaw, wobec czego odwołanie powinno zostać oddalone. 

Zarzuty  postawione  przez  Odwołującego  sprowadzały  się  do  twierdzenia,  że  macierze  Hitachi 

zaoferowane przez WASKO S.A. nie spełniają poniższych wymagań Zamawiającego: 

Zarzut  1 

–  (punkt  VII  uzasadnienia  Odwołania)  -  brak  wskazania  nazwy  każdego  oferowanego 

oprogramowania do zarządzania. 

Zarzut 2 

– (punkt VIII uzasadnienia Odwołania) - zaoferowany pakiet Oprogramowania do zarządzania 

nie spełnia wymagań Zamawiającego. 

Zarzut  3 

–  (punkt  IX,  X  i  XI  uzasadnienia  Odwołania)  -  brak  zaoferowania  oprogramowania  

do monitorowania macierzy z poziomu maszyny wirtualnej. 

Zarzut  4 

–  (punkt  XII  uzasadnienia  Odwołania)  –  zaoferowanie  licencji,  które  są  niezgodne  

z warunkami zamówienia. 

Zamawiający wyjaśnił, że wymagał złożenia wraz z ofertą przedmiotowego środka dowodowego na 

potwierdzenie,  że  zaoferowane  przez  Wykonawców  rozwiązania  spełniają  określone  wymagania 

SWZ. Zamawiający, na podstawie informacji zawartych w dokumencie  

„Specyfikacja techniczna oferowanych Macierzy Dyskowych”, złożonym z ofertą, sporządzonym wg 

Załącznika nr 1A do SWZ, był w stanie zweryfikować, jakie rozwiązania zostały zaoferowane oraz że 

zaoferowane rozwiązania spełniają wymagania określone przez Zamawiającego. Do weryfikacji, czy 

zaoferowane rozwiązania spełniają wymagania SWZ, Zamawiający nie wymagał wyspecyfikowanej 

pełnej  listy  wszystkich  elementów  oprogramowania,  a  jedynie  takie  wskazanie,  które  umożliwiało 

identyfikację oferowanego oprogramowania.  

Zamawiający na etapie oceny oferty, na podstawie wskazania Wykonawcy, iż oferuje, cyt.: „Pakiet 

licencji Advanced w tym OpsCenter plus agent do zarządzania replikacją oraz Hitachi Ops Center 

Analyzer  for  Mainframe.  Producent:  Hitachi  Vantara.  Licencjonowanie:  dla  każdej  pojedynczej 

macierzy.”  Posiłkując  się  dokumentacją  producenta    -  https://www.hitachivantara.com/en-

us/pdf/datasheet/base-advanced-software-packages-for-vsp-5000-series-datasheet.pdf, 

Zamawiający  zweryfikował,  że  oprogramowanie  do  zarządzania  macierzami  Hitachi  OpsCenter 

udostępniane jest przez producenta na różnych poziomach licencjonowania: Basic, oraz Advanced. 

Ponadto istnieje możliwość zakupu dodatkowych funkcjonalności (Additional Software), które mogą 

być uzupełnieniem poziomu Basic lub Advanced.  

Istotne jest to, że oprogramowanie w pakietach na poziomie Advanced zawiera wszystkie produkty  

z  pakietów  na  poziomie  Basic  (w  przywołanym  przez  Odwołującego  na  stronie  6  Odwołania 

fragmencie dokumentacji producenta: „ADVANCED PACKAGE MAINFRAME SYSTEMS zawiera: 

Cały pakiet Mainframe Base oraz:..”). 

W odniesieniu do zarzutu 1 

Zamawiający wskazał, że Odwołujący zarzucił, że Wykonawca WASKO 

S.A. w Załączniku nr 1A nie sprecyzował, jakie oprogramowanie kryje się pod pojęciem „agent do 

zarządzania replikacją”. Zamawiający poinformował, że na podstawie pełnej treści tego dokumentu 

złożonego  przez  WASKO  S.A.,  wiedział,    jakie  oprogramowanie,  zostało  zaoferowane  przez  tego 

Wykonawcę i że spełnia ono wymagania SWZ. W języku stosowanym w informatyce, pojęcie „agent” 

oznacza  autonomiczny  program  komputerowy  lub 

system,  który  jest  zdolny  do  wykonywania 

określonych  zadań  w  imieniu  użytkownika  lub  innego  systemu.  Działania  agenta  często  obejmuje 

zdolność do interakcji z innymi agentami lub systemami. Biorąc pod uwagę informacje przekazane 

przez WASKO S. A. w Załączniku nr 1A, oprogramowanie agent do zarządzania replikacją ma być 

zainstalowany  po  stronie  systemu  operacyjnego  z/OS,  czyli  na  platformie  mainframe.  W  tym 

przypadku  agentem  jest  oprogramowaniem,  które  będzie  komunikowało  się  z  pozostałym 

oprogramowaniem  do 

zarządzania, w celu zarządzania replikacją na charakterystycznej platformie 

mainframe. Zgodnie z dokumentacją producenta, istnieją podstawowe metody replikacji: TrueCopy do 

zewnętrznej replikacji synchronicznej lub asynchronicznej, Universal Replicator do asynchronicznej 

replikacji na długie odległości oraz ShadowImage do wewnętrznej replikacji. Zgodnie z dokumentacją 

producenta 

https://docs.hitachivantara.com/r/en-us/business-continuity-manager/9.8.7/mk-

95hc104/overview-of-hitachi-business-continuity-manager 

i tłumaczeniem: „Istnieją dwa typy licencji 

dla  Business  Continuity  Manager:  licencja  na  korzystanie  z  podstawowych  funkcji  i  licencje  na 

korzystanie z opcjonalnych funkcji. Po zainstalowaniu licencji na korzystanie z podstawowych funkcji 

możesz definiować i zarządzać grupami kopii ShadowImage (SI), TrueCopy (TC) i Universal Replicator 

(UR). Aby korzystać z opcjonalnych funkcji, zainstaluj wymaganą licencję.” 

Zgodnie z tą informacją oprogramowanie do zarządzania replikacją tzn. Business Continuity Manager 

zawiera  oprogramowanie  do  replikacji  zewnętrznej  oraz  wewnętrznej,  które  spełniają  wymagania 

Zamawiającego zawarte w SWZ. Oprogrogramowanie Business Continuity Mangaer instalowane jest 

po stronie systemu operacyjnego z/OS i komunikuje się z oprogramowaniem Replication Manager: 

„Business Continuity Manager is supported for the following versions of z/OS®: V1R13, and V2R1 to 

V2R5. 

•  Use  z/OS  V2R1  or  a  later  version  to  establish  HTTPS  communication  between  Replication 
Manager and Business Continuity Manager by using TLS 1.2.” - https://docs.hitachivantara.com/r/en-

us/business-continuity-manager/9.8.7/mk-95hc104/overview-of-hitachi-business-continuity-

manager/prerequisite-conditions  - 

rozdział  „Prerequisite  conditions”  Oprogramowanie  Business 

Continuity Manager zawiera w sobie agenta, którego instaluje się np. po stronie lokalnej oraz zdalnej 

(awaryjnej). 

Zamawiający wskazał na przykład instalacji agentów Business Continuity Manager wraz 

z połączeniem z Replicator Managerem (poza platformą mainframe), którego schemat pochodzi ze 

strony  producenta  -  https://docs.hitachivantara.com/r/en-us/business-continuity-manager/9.8.7/mk-

95hc104/setting-up-the-environment-when-linking-with-replication-manager/creating-initialization-

parameters/examples-of-specifying-initialization-parameters/for-business-continuity-manager-agent-

on-local-and-remote-sites. 

Oznaczenia TC oraz UR ze schematu 

oznaczają kolejno TrueCopy oraz Universal Replication, które 

wchodzą w skład oprogramowania Business Continuity Manager. 

W  dokumentacji  przywołanej  przez  Odwołującego,  w  pakiecie  „Advanced  Package  Mainframe 

Systems”  występuje  m.in.  oprogramowanie  „Hitachi  Business  Continuity  Manager  Extended  for 

automating Remote Data Protection” oraz „Hitachi Business Continuity Manager utility for automating 

local replication”.  

Cały  powyższy  wywód  dowodzi,  że  Zamawiający  był  w  stanie  jednoznacznie  zweryfikować,  że 

zaoferowane oprogramowanie spełnia wymagania Zamawiającego. 

W odniesieniu do zarzut 2 

odwołania wykonawca WASKO S. A., w Załączniku nr 1A wskazał „Pakiet 

licencji Advanced w tym OpsCenter plus agent do zarządzania replikacją”. Przywołany zapis, poprzez 

użycie zwrotu „w tym”, potwierdza, że oprogramowanie OpsCenter znajduje się w pakiecie licencyjnym 

Advanced.  Skoro,  jak  sam  Odwołujący  wskazał,  oprogramowanie  OPS  Center  nie  znajduje  się  

w pakiecie licencyjnym Advanced, to należy przyjąć, że określenie „w tym” odnosi się do oferty, a nie 

„Pakietu  licencyjnego  Advanced”.  Powyższe  nie  pozwalało  kwestionować  Zamawiającemu,  że 

zaoferowane oprogramowanie wg treści oferty odpowiada wymaganiom zawartym w SWZ. Istotne 

było,  czego  nie  wskazał  Odwołujący,  że  w  dokumentacji  producenta,  przywołanej  przez 

Odwołującego,  przy  każdej  tabeli  jest  adnotacja  nr  1,  w  oryginalnym  brzmieniu:  „Combined  open 

systems  and  mainframe  base,  advanced  and  additional  options  are  available  for  mixed  open  and 

mainframe VSP 5000 environments.” 

Tłumaczenie: „Dostępne są łączone (licencje na - przyp. red.) systemy otwarte i baza mainframe, opcje 

zaawansowane i dodatkowe dla mieszanych środowisk otwartych i mainframe VSP 5000”. 

Zamawiający  zwrócił  uwagę,  iż  nie  wyklucza  wykorzystania  macierzy  jednocześnie  w  środowisku 

mainframe, 

jak i środowisku systemów otwartych, co wynika z części postanowień zawartych w treści 

OPZ (np. w poz. nr 9 Rozdział II OPZ). W takim przypadku możliwe będzie mieszanie licencji, a co za 

tym idzie niezbędne jest oprogramowanie OpsCenter, do zarządzania macierzami. 

Zamawiający  zwrócił  uwagę,  jak  już  wskazano  we  wcześniejszym  fragmencie  odpowiedzi, 

iż oprócz licencji na poziomie Basic oraz Advanced, producent umożliwia wykupienie dodatkowych 

funkcjonalności,  które  rozszerzają  licencje  na  poziomie  Basic  oraz  Advanced.  Jak  pokazuje 

przywołana przez Odwołującego strona producenta, wśród dodatkowego oprogramowania (Additional 

Software)  dla  platformy  mainframe  znajduje  się  „Ops  Center  Analyzer”  w  wielu  wersjach 

funkcjonalnych.  

Wykonawca WASKO w Załączniku nr 1A, wskazał oferowane oprogramowanie „Ops Center Analyzer 

for Mainframe”, przez co należy rozumieć, że chodzi o wszystkie produkty Hitachi OpsCenter Analyzer 

z kategorii „ADDITIONAL SOFTWARE OPTIONS MAINFRAME”. 

W  odniesieniu  do  zarzutu  3  i  4 

odwołania,  Zamawiający  wskazał,  że  Odwołujący  zarzucił,  

iż zaoferowane przez WASKO S.A. macierze Hitachi Vantara VSP 5600 nie spełniają wymagania 

zawartego w pkt 34 Rozdziału 2 OPZ.  

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

„W  zależności  od  sposobu  zarządzania  i  monitorowania  Macierzy,  konieczne  jest  zaoferowanie 

minimum jednego z poniższych wariantów:  

1.  jeżeli  Macierze  są  monitorowane  z  poziomu  stacji  roboczej,  wówczas  każda  Macierz  musi  być 

wyposażona  w  co  najmniej  dwie  stacje  robocze  do  zarządzania  konfiguracją,  monitorowania 

wydajności  i  stanu  Macierzy  wraz  z  oprogramowaniem.  Wykonawca  musi  uwzględnić  wszystkie 

wymagane licencje na to oprogramowanie,  

2. jeżeli Macierze są zarządzane i monitorowane z poziomu hosta (serwera Mainframe), Wykonawca 

musi  uwzględnić  wszystkie  wymagane  licencje  na  oprogramowanie  monitorujące  i  zarządzające 

instalowane na serwerach Mainframe,  

3. jeżeli Macierze są monitorowane z poziomu maszyny wirtualnej, Wykonawca musi dostarczyć obraz 

maszyny wirtualnej wraz ze wszystkimi wymaganymi licencjami.”.  

Wykonawca WASKO S. A. w Załączniku nr 1A wskazał, że miejscem instalacji oprogramowania do 

zarządzania  będzie  „Management  server  (VM-Virtual  Machine)”.  Odwołujący  na  podstawie  tego 

wskazał, iż WASKO S.A. zaoferował rozwiązanie, o którym mowa wariancie 3 w pkt 34 Rozdziału  

2 OPZ. Wykonawca WASKO S.A. zaoferował zatem oprogramowanie Hitachi Ops Center w wersji na 

maszynę  wirtualną,  które  wymaga  oprogramowania  VMware  vSphere  Hypervisor,  a  ściślej  – 

wskazane oprogramowanie VMware jest wymagane dla zainstalowania Ops Center.  

Zamawiający wskazał, że zestawiając powyższe, z postanowieniami zawartymi w OPZ, Odwołujący 

wywnioskował,  iż  Wykonawca  WASKO  S.A.  winien  Zamawiającemu  dostarczyć  wraz  z  obrazem 

maszyny wirtualnej również oprogramowanie VMware vSphere Hypervisor, potrzebne do instalacji 

Ops Center. W powiązaniu z tym Odwołujący dodatkowo wskazał, iż na oprogramowanie VMware 

vSphere  Hypervisor  Zamawiający  nie  uzyska  licencji  wieczystej,  lecz  wyłącznie  licencję  czasową, 

przez co również nie zostały zachowane wymagania określone w pkt 30 Rozdział 2 OPZ, zgodnie  

z którym Zamawiający wymagał dostarczenia licencji wieczystych. 

Odwołujący wskazał, że WASKO S. A. powinien w Załączniku nr 1A wpisać informację o wszystkich 

licencjach niezbędnych do realizacji zamówienia. Takie zobowiązanie nie wynika jednak z żadnego 

wymagania Zamawiającego. W Załączniku nr 1A należało wskazać jedynie nazwę oprogramowania, 

na podstawie której Zamawiający będzie w stanie zweryfikować czy zaoferowane rozwiązanie spełnia 

wymagania  SWZ.  Oprogramowanie  VMware  oraz  system  operacyjny,  na  którym  będzie 

zainstalowane  oprogramowanie  do  zarządzania,  jest  oprogramowaniem  nie  wynikającym  wprost  

z zapisów SWZ, a co za tym idzie, nie jest to oprogramowanie realizujące funkcjonalności macierzy 

wskazanych w OPZ. W związku z tym wymaganie zawarte w pkt 30 Rozdział II OPZ dotyczy tylko  

i wyłącznie oprogramowania realizującego funkcjonalności macierzy wskazane w OPZ.  

Wobec powyższego,  wpisanie  przez  WASKO  S.  A. tego oprogramowania  nie  wniosłoby żadnych 

dodatkowych informacji, które byłyby niezbędne na etapie weryfikacji oferty. 

Zamawiający  wskazał,  że  wobec  powyższego,  zarzuty  stawiane  przez  Odwołującego  co  do 

niezgodności oferowanych macierzy przez WASKO S.A. z treścią pkt 30 i/ lub 34 Rozdziału II OPZ 

należało uznać za bezzasadne, a w konsekwencji – winny zostać przez Izbę oddalone w całości. 

Po  przeprowadzeniu  rozprawy,  na  podstawie  zgromadzonego  w  sprawie  materiału 

dowodowego  oraz  stanowisk  Stron  zawartych  w  odwołaniu  i  odpowiedzi  na  odwołanie, 

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

Izba  ustaliła,  iż  nie  została  wypełniona  żadna  z  przesłanek  skutkujących  odrzuceniem  odwołania,  

a odwołanie nie zawierało braków formalnych i mogło zostać rozpoznane merytorycznie. 

Izba ustaliła, że Odwołujący wykazał interes w korzystaniu ze środków ochrony prawnej. Wykonawca 

jest podmiotem, który złożył ofertę w postępowaniu i jest zainteresowany uzyskaniem zamówienia oraz 

możliwość poniesienia szkody w wyniku naruszenia przez Zamawiającego przepisów ustawy.  

Do postępowania odwoławczego przystąpienie po stronie Odwołującego zgłosił wykonawca Advatech 

Spółka z ograniczoną odpowiedzialnością z siedzibą we Wrocławiu, dalej: „Przystępujący Advatech”, 

po  stronie 

Zamawiającego  -  wykonawca  Wako  Spółka  Akcyjna  z  siedzibą  w  Gliwicach,  dalej: 

„Przystępujący Wasko”. 

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

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

swoje stanowisko. 

Izba zaliczyła do materiału dowodowego sprawy dokumenty pochodzące z akt sprawy odwoławczej 

oraz złożone podczas rozprawy w dniu 23 sierpnia 2024 r. 

Na  podstawie  przekazanej  dokumentacji  postępowania  Izba  ustaliła,  że  Zamawiający  Zakład 

Ubezpieczeń Społecznych, prowadzi postępowanie o udzielenie zamó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: 

Zamawiający  wymaga  złożenia  przedmiotowego  środka  dowodowego  na  potwierdzenie 

spełniania wymaga dotyczących przedmiotu zamówienia, tj.: 

2.1.5.1.1. Specyfikacji  technicznej  oferowanych 

Macierzy  Dyskowych,  według  wzoru  stanowiącego 

Załącznik 1A do SWZ.  

Zamawiający w załączniku 1A do SWZ – Specyfikacja techniczna oferowanych Macierzy Dyskowych 

w pkt 3 i 4 

wymagał wskazania następujących parametrów wraz ze specyfikacją: 

3. Oprogramowania do Zarzadzania, ze wskazaniem:  

1) nazwy, 

2) producenta, 

3) sposobu licencjonowania. 

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.  j

eż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. 

O

programowanie  do  zarządzania  replikacją  tzw.  Business  Continuity  Manager  zawiera 

oprogramowanie  do  replikacji  zewnętrznej  oraz  wewnętrznej,  które  spełniają  wymagania 

Z

amawiają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 n

ależało podać: nazwę, 

producenta, sposób licencjonowania, czyli informacji dotyczących oprogramowania do zarządzania. 

Jak  podkreślił  Zamawiający  agent  do  zarzadzania  replikacją  w  przypadku  wskazanym  przez 

Przystępującego Wasko był oprogramowaniem komunikującym się z pozostałym oprogramowaniem 

do zarządzania w celu zarządzania replikacją na platformie Mainframe.  

Wobec  powyższego,  w  związku  z  tym,  że  podanie  nazwy  oprogramowania  agenta  jako 

oprogramowania 

komunikującego  się  z  pozostałym  oprogramowaniem  zarządzania,  podanie 

informacji w pkt 3 Załącznika 1A nie było przez Zamawiającego wymagane, Zamawiający nie miał 

problemu z weryfikacją zgodności „agenta do zarządzania replikacją” z wymaganiami określonymi  

w  SWZ 

a  Odwołujący  nie  wykazał  niezgodności  treści  oferty  z  warunkami  zamówienia,  zarzut 

powyższy podlegał oddaleniu.  

W odniesieniu do zarzutu nr 1b 

odwołania Izba wskazuje: 

W odpowiedzi na 

powyższy zarzut, Zamawiający wskazał, że z dokumentacji producenta macierzy 

wynika, 

że  dostępne  są  łączone  systemy  otwarte  i  baza  mainframe,  opcje  zaawansowane  

i dodatkowe dla mieszanych środowisk otwartych i mainframe VSP 5000, a on sam nie wykluczył 

możliwości wykorzystania macierzy jednocześnie w środowisku mainframe jak i środowisku systemów 

otwartych,  co  wynika

ło  z  postanowień  zawartych  w  treści  OPZ  (np.  poz.  Nr  9  Rozdział  

II OPZ). W

ówczas możliwe będzie mieszanie licencji i wówczas niezbędne będzie oprogramowanie 

OpsCenter.  

Jaj podkreślił Zamawiający, producent oprócz licencji na poziomie Basic oraz Advanced umożliwia 

wykupienie dodatkowych funkcjonalności, które rozszerzają licencje na poziomie Basic i Advanced. Ze 

strony  producenta

,  na  którą  powołał  się  Odwołujący,  wynika  również,  że  wśród  dodatkowego 

oprogramowania  dla  platformy  mainframe  znajduje  się  Ops  Center  Analyzer  w  wielu  wersjach 

funkcjonalnych. 

Ponieważ Przystępujący Wasko w Załączniku nr 1A zaoferował oprogramowanie Ops 

Center Analyzer for Mainframe, Z

amawiający przez to oprogramowanie rozumiał wszystkie produkty 

Hitachi Ops Center Analyzer z kategorii Additional Software Options Mainframe. 

Ponadto, j

ak słusznie podkreślił Przystępujący Wasko w wierszu nr 3 w Załączniku nr 1A zobowiązany 

był wskazać nazwę, producenta oprogramowania do zarządzania, a nie nazwy pakietów licencyjnych 

lub innego oprogramowania, które nie było oprogramowaniem do zarządzania.  

Okoliczności wskazane przez Odwołującego w uzasadnieniu zarzutu 1b nie dowodziły niezgodności 

oferty Przystępującego z warunkami zamówienia. 

Wobec  faktu,  iż  Odwołujący  nie  wykazał  niezgodności  treści  oferty  Przystępującego  z  warunkami 

zamówienia, zarzut nr 1b odwołania podlegał oddaleniu. 

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

Izba 

podkreśla, że jak wynika z treści Załączniku nr 1A do SWZ należało tam wskazać jedynie nazwę 

oprogramowania,  które  realizowało  funkcjonalności  macierzy  wskazane  w  OPZ,  a  nie  całego 

oprogramowania koniecznego do realizacji zamówienia, w tym oprogramowania platformy sprzętowej, 

na  której  zostanie  zainstalowany  obraz  maszyny  wirtualnej.  Dokumenty  Postępowania 

nieprzewidywały konieczności wskazywania oprogramowania platformy wirtualizacyjnej. 

W  ocenie  Izby, 

Odwołujący  nie  wykazał  niezgodności  treści  oferty  Przystępującego  Wasko  

z warunkami 

zamówienia, a zatem zarzut nr 1c odwołania podlegał oddaleniu. 

W odniesieniu do zarzutu ewentualnego 

– zaoferowania przez Przystępującego Wasko rozwiązania, 

które wymaga licencji, które udzielane są wyłącznie na czas określony, podczas gdy Zamawiający  

w  rozdz.  II  pkt  30  OPZ  wymagał,  aby  wszystkie  dostarczane  licencje  udzielane  były  na  czas 

nieograniczony, Izba wskazuje: 

Izba wskazuje, że powyższy zarzut oparty został na własnych założeniach Odwołującego, zgodnie  

z którymi, skoro wskazane przez Przystępującego Wasko oprogramowanie Ops Center w wersji na 

maszynę  wirtualną  wymaga  oprogramowania  Vmware  vSphere  Hypervisor,  to  licencja  na  to 

oprogramowanie 

jest niezgodne z warunkami zamówienia, ponieważ Vmware nie oferuje już licencji 

wieczystych, nieograniczonych czasowo. 

Jak wskazał Przystępujący Wasko odnosząc się do powyższego zarzutu, istnieją jeszcze trzy inne 

oprogramowania,  które  można  zastosować  w  przypadku  dostarczania  obrazu  maszyny  wirtualnej 

zawierającej OpsCenter. Co więcej z oferty Przystępującego Wasko oraz przedmiotowych środków 

dowodowych  nie  wynika

,  aby  zaoferował  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 art.  557 i art.  575 ustawy  Pzp  oraz  w  oparciu  o  przepisy 

§  8  ust.  2  pkt  1  w  zw.  

z  §  5  pkt  2  lit.  b  rozporządzenia  Prezesa  Rady  Ministrów  z  dnia  30  grudnia  2020  r.  w  sprawie 

szczegółowych  rodzajów  kosztów  postępowania  odwoławczego,  ich  rozliczania  oraz  wysokości  

i sposobu pobierania wpisu od odwołania. 

Wobec oddalenia 

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

II. 

KIO 2791/24:

W  dniu  5  sierpnia  2024  r.  wykonawca 

Advatech  Spółka  z  ograniczoną  odpowiedzialnością  

z  siedzibą  we  Wrocławiu,  dalej:  „Odwołujący”  wniósł  odwołanie  wobec  czynności  Zamawiającego  

i zaniechań czynności, do których był zobowiązany na podstawie PZP, tj.: 

1)  czynności  wyboru  oferty  wykonawcy  WASKO  S.A.  („WASKO”)  jako  najkorzystniejszej  

w Postępowaniu, 

2) zaniechania odrzucenia ofert wykonawców:  

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

b)  T-

Mobile  Polska  Business  Solutions  sp.  z  o.o.  (”T-Mobile”),  który  zaoferował  macierz  Hewlett 

Packard Enterprise XP8 („HPE XP8”),  

c)  a  także  zaniechania  odrzucenia  z  Postępowania  ofert  wykonawców  Symmetry  Sp.  z  o.o. 

(„Symmetry”),  oraz  IT  Solution  Factor  sp.  z  o.o.  („IT  Solution  Factor”),  którzy  również  zaoferowali 

macierz HPE XP8. 

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

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

a)  zaniechanie  odrzucenia  ofert  wykonawców  WASKO,  T-Mobile,  a  także  Symmetry  i  IT  Solution 

Factor jako niezgodnych z warunkami Zamówienia (SWZ), w zakresie braku spełnienia przez oferty 

tych wykonawców wymagań wskazanych w pkt 37, oraz pkt.12, 14-19 Rozdział 2 - Szczegółowe 

wymagania  dla  Macierzy  dyskowych,  Załącznik  nr  11  do  SWZ  Szczegółowy  Opis  przedmiotu 

Zamówienia  (OPZ),  tj.  braku  brak  spełnienia  wymagań  z  OPZ  przy  pomocy  programów  TSO, 

DFSMSdss, ICKDSF [Zarzut Nr 1]. 

b)  zaniechanie  odrzucenia  ofert  wykonawców  WASKO,  T-Mobile,  a  także  Symmetry  i  IT  Solution 

Factor jako  niezgodnych z warunkami Zamówienia,  w zakresie braku spełnienia przez  oferty tych 

wykonawców wymagania wskazanego w pkt. 19, Rozdział 2, OPZ, tj. braku zaoferowania rozwiązania 

zapewniającego możliwość pracy w środowisku GDPS/PPRC [Zarzut Nr 2]; 

c)  zaniechanie  odrzucenia  ofert  wykonawców  WASKO,  T-Mobile,  a  także  Symmetry  i  IT  Solution 

Factor jako  niezgodnych z warunkami Zamówienia,  w zakresie braku spełnienia przez  oferty tych 

wykonawców wymagania wskazanego w pkt. 4, Rozdział 2, OPZ (po Odpowiedzi Zamawiającego z 

dnia 20 listopada 2023 r. na pytanie nr 2), tj. 

w zakresie zaoferowania rozwiązania, które do rozbudowy 

macierzy  wykorzystuje  dyski  obrotowe,  pomimo 

braku  dopuszczenia  takiej  możliwości  przez 

Zamawiającego [Zarzut Nr 3]; 

d) zaniechanie odrzucenia oferty wykonawcy T-

Mobile, a także Symmetry i IT Solution Factor, pomimo 

że oferowane przez tych wykonawców macierze XPE XP8 nie spełniają wymagania z pkt. 12, Rozdział 

2 OPZ, tj. pomimo, że macierze XPE XP8 nie są kompatybilne z systemami operacyjnymi S/390 (z/OS 

i z/VM) [Zarzut Nr 4]. 

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

1)  unieważnienia  czynności  wyboru  oferty  wykonawcy  WASKO  jako  najkorzystniejszej  

w Postępowaniu, 

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

3) odrzucenia ofert WASKO, T-

Mobile, Symmetry, IT Solution Factor z Postępowania, 

a ponadto o 

zasądzenie od Zamawiającego na rzecz Odwołującego zwrotu kosztów postępowania 

odwoławczego, w tym zwrotu kosztów wynagrodzenia pełnomocnika, zgodnie z fakturą, która zostanie 

przedłożona na rozprawie. 

W uzasadnieniu 

odwołania Odwołujący wskazał, że Zamawiający prowadzi Postępowanie, którego 

przedmiotem  jest  Zakup  Macierzy  dyskowych  na  platformę  MF  z  możliwością  rozbudowy  do 

systemów  otwartych.  Zamawiający  w  Rozdziale  2  OPZ  wskazał  na  Minimalne  wymagania,  które 

powinien  spełniać  oferowany  przedmiot  zamówienia.  Odwołujący  wskazał,  że  3  wykonawców  –  

T-

Mobile, Symmetry, IT Solution Factor zaoferowało macierze HPE XP8, natomiast jeden wykonawca 

WASKO zaoferował macierz VSP 5600.  

W  ocenie  Odwołującego,  obie  macierze  są  podobnej  konstrukcji  –  macierz  HPE  jest  OEM`em 

macierzy  Hitachi  Vantara,  dlatego  też  obie  macierze  nie  spełniają  wymagań  opisanych  

w  Zarzutach  Nr  1,  2, 

3,  dodatkowo  macierz  HPE  nie  spełnia  wymagania  wskazanego  

w Zarzucie Nr 4. 

Odwołujący wskazał, że wykonawcy składający ofertę byli doskonale świadomi, że zakup macierzy 

dokonywany jest w ściśle określonym celu - na platformę Mainframe producenta IBM, co za tym byli  

w pełni świadomi, że rozwiązania oferowane przez nich muszą być w pełni kompatybilne z tą platformą, 

umożliwiać 

realizację 

wszystkich 

funkcjonalności 

opisanych 

przez 

Zamawiającego  

w OPZ, co ważne w sposób opisany w OPZ. 

Odwołujący  wskazał  na  aktualne  pod  rządami  obowiązującej  ustawy  PZP  orzecznictwo,  które 

wskazuje  na  obligatoryjność  odrzucenia  oferty  wykonawcy  niezgodnej  z  warunkami  zamówienia. 

Zwłaszcza taka instytucja jak ZUS, która posiada rozwiązania serwerowo-macierzowe, na których 

posadowione  są  krytyczne  dla  państwa  polskiego  systemy  i  na  których  przechowywane  są  dane 

wrażliwe obywateli musi mieć absolutną pewność, że oferta danego wykonawcy spełnia wymagania 

z OPZ, a co za tym idzie rzetelnie przeprowadzić proces badania i oceny ofert. 

Krajowa Izba Odwoławcza w wyroku z dnia 18 stycznia 2021 r. (sygn. KIO 3470/20) wskazała, że: 

„Ukształtowana  w  danym  postępowaniu  treść  SIWZ  wiąże  nie  tylko  wykonawców,  ale  także 

Zamawiającego,  który  w  toku  tego  postępowania  ma  obowiązek  respektować  ustalone  założenia,  

a  odstępstwo  od  nich  godzić  może  w  zasadę  równego  traktowania  wykonawców”.  Analogiczne 

stanowisko zajęła Krajowa Izba Odwoławcza w wyroku z dnia 9 listopada 2020 r. (sygn. KIO 2598/20), 

gdzie wskazała, że „Wykonawcy biorący udział w postępowaniu mają prawo oczekiwać, że złożone  

w postępowaniu oferty zostaną ocenione zgodnie z wymaganiami Zamawiającego wyartykułowanymi 

w  dokumentacji  postępowania,  z  poszanowaniem  wymogów  stawianych  przez  powszechnie 

obowiązujące  przepisy  prawa,  zaś  Zamawiający  wykona  ciążące  na  nim  ustawowe  obowiązki 

rzetelnego zbadania złożonych ofert, gwarantując tym samym zabezpieczenie interesów uczestników 

procesu  udzielania  zamówień  publicznych”  oraz  w  wyroku  z  dnia  10  grudnia  2020  r.  (sygn.  KIO 

3040/20) „Przestrzeganie przez zamawiającego reguł, które on sam określił w siwz oraz przepisów 

określonych w ustawie z 2004 r. - Prawo zamówień publicznych, nie jest formalizmem, ale jedynym 

sposobem prowadzenia postępowania o udzielenie zamówienia zgodnie z zasadami, o których mowa 

w art. 7 ust. 1 p.z.p.  

Wymagania  zamawiającego  służą  bowiem  (o  ile  są  sformułowane  adekwatnie  do  przedmiotu 

zamówienia) do weryfikacji tego, czy wykonawca jest zdolny do należytego wykonania zamówienia  

i czy to, co on oferuje spełnia oczekiwania zamawiającego określone w ogłoszeniu o zamówieniu  

i siwz. Zamawiający zobowiązany jest zatem rzetelnie sprawdzić spełnienie tych wymagań nie "dla 

formalności", ale dla uzyskania pewności, że zamówienie zostanie należycie zrealizowane”. 

Natomiast zgodnie z wyrokiem Krajowej Izby Odwoławczej z dnia 24 lutego 2021 r. (sygn. KIO 230/21) 

„Zgodnie  z  art.  89  ust.  1  pkt  2  p.z.p.  Zamawiający  odrzuca  ofertę  wykonawcy,  jeśli  jej  treść  jest 

niezgodna  ze  SIWZ.  Ustawodawca  zobowiązał  więc  zamawiającego  do  odrzucenia  ofert  tych 

wykonawców,  którzy  złożyli  ofertę  niezgodną  z  wymaganiami  zamawiającego  określonymi  

w  specyfikacji  istotnych  warunków  zamówienia,  co  do  zakresu,  ilości,  jakości,  warunków  realizacji  

i innych elementów istotnych dla wykonania przedmiotu zamówienia”. 

Odwołujący wskazał, że w niniejszym Postępowaniu wymagania dotyczące funkcjonalności macierzy 

i sposobu realizacji tych funkcjonalności zostały wprost wyartykułowane przez Zamawiającego w treści 

OPZ,  wyjaśnieniach  SWZ,  w  związku  z  tym  brak  spełnienia  wymagań  wskazanych  przez 

Odwo

łującego w odwołaniu powinien skutkować odrzuceniem ofert wykonawców Wasko, T-Mobile,  

a także wykonawców Symmetry i IT Solution Factor, którzy zaoferowali dokładnie takie same macierze 

co wykonawca T-Mobile. 

W odniesieniu do zarzutu nr zarzut nr 1 

– braku spełnienia wymagań przy pomocy programów TSO, 

DFSMSdss, ICKDSF, 

Odwołujący wskazał, że oferowana przez wykonawcę WASKO macierz VSP 

5000 oraz oferowana przez T-

Mobile, IT Solution Factor, Symmetry macierz HPE XP8 nie posiadają: 

a)  funkcjonalności  wykonywania  zewnętrznych  kopii  danych  do  drugiej  Macierzy,  znajdującej  się  

w drugim ośrodku przetwarzania, która musi być realizowana przy użyciu mechanizmów Macierzy, dla 

grupy wielu wolumenów dyskowych w celu uzyskania spójnej (konsystentnej) kopii tych wolumenów 

(tzw. fizyczna replikacja danych) w trybie niesynchronicznym z poziomu systemu operacyjnego z/OS 

przy  pomocy  programów  TSO  i  DFSMSdss.  Brak  tej  funkcjonalności  oznacza  nie  spełnienie 

wymagania pkt 14 i 15 w sposób nakazany w pkt 37. 

b)  funkcjonalności  wykonywania  zewnętrznych  kopii  danych  do  drugiej  Macierzy,  znajdującej  się  

w drugim ośrodku przetwarzania, która musi być realizowana przy użyciu mechanizmów Macierzy, dla 

grupy wielu wolumenów dyskowych w celu uzyskania spójnej (konsystentnej) kopii tych wolumenów 

(tzw. fizyczna replikacja danych) w trybie niesynchronicznym z wykorzystaniem jedynie kontrolerów 

dyskowych  z  poziomu  systemu  operacyjnego  z/OS  przy  pomocy  programu  ICKDSF.  Brak  tej 

funkcjonalności oznacza nie spełnienie wymagania pkt 14 w sposób nakazany w pkt 37. 

Odwołujący  przytoczył  wymagania  wskazane  pkt  37,  oraz  pkt.  12  i  14-19  Rozdziału  2-iego  OPZ, 

których nie spełniają macierze oferowane przez czterech wykonawców. 

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. 

Każda Macierz ma obsługiwać serwery System z (serwery IBM serii z), z systemem operacyjnym 

S/390 (z/OS, z/VM, Linux) 

14. Każda Macierz musi posiadać funkcjonalność wykonywania zewnętrznych kopii danych do drugiej 

Macierzy,  znajdującej  się  w  drugim  ośrodku  przetwarzania,  w  odległości  co  najmniej  40  km  za 

pośrednictwem DWDM. Funkcja musi być realizowana przy użyciu mechanizmów Macierzy, dla grupy 

wielu wolumenów dyskowych w celu uzyskania spójnej (konsystentnej) kopii tych wolumenów (tzw. 

fizyczna 

replikacja 

danych) 

w 

trybie 

synchronicznym 

oraz 

niesynchronicznym  

z wykorzystaniem jedynie kontrolerów dyskowych. 

15.  W  przypadku  zawieszenia  lub  zerwania  fizycznej  replikacji  danych,  musi  istnieć  możliwość 

resynchronizacji  wolumenów  pomiędzy  Macierzami  w  trybie  różnicowym  (propagacja  tylko  tych 

danych, które uległy zmianie). 

16.  Macierz  musi  posiadać  możliwość  wykonywania  następujących  wewnętrznych  (w  ramach 

pojedynczej Macierzy) kopii danych: 

a. kopia grupy wolumenów dyskowych wykonana przy użyciu mechanizmów Macierzy. Wolumeny 

źródłowe i docelowe są dostępne dla aplikacji hosta do aktualizacji natychmiast po wykonaniu kopii. 

Dane  fizyczne  są  kopiowane  z  wolumenów  źródłowych  na  docelowe  w  tle  w  sposób  minimalnie 

wpływający na wydajność Macierzy, 

b. kopia grupy wolumenów dyskowych wykonana przy użyciu mechanizmów Macierzy. Wolumeny 

źródłowe i docelowe są dostępne dla aplikacji hosta do aktualizacji natychmiast po wykonaniu kopii. 

Dane fizyczne nie są kopiowane z wolumenów źródłowych na docelowe z wyjątkiem ścieżek które 

ulegają zmianie na wolumenach źródłowych - przed zmianą te ścieżki są kopiowane. Praca na takich 

danych nie może powodować pogorszenia wydajności o więcej niż 10%, 

c. kopia zbioru danych wykonana przy użyciu mechanizmów Macierzy. Zbiór danych może zajmować 

część jednego lub wielu wolumenów dyskowych. Zbiór źródłowy i docelowy są dostępne dla aplikacji 

hosta do aktualizacji natychmiast po wykonaniu kopii. Dane fizyczn

e są kopiowane z w tle w sposób 

minimalnie wpływający na wydajność Macierzy. Mechanizm wykonujący kopie musi być zgodne z IBM 

FlashCopy V2 tzn. muszą w sposób poprawny interpretować i wykonywać komendy FlashCopy V2 

(tzn. być kompatybilne z FlashCopy V2). 

17. Dostarczony mechanizm replikacji pomiędzy Macierzą A i Macierzą B musi zagwarantować, iż w 

przypadku awarii Macierzy A, nie dojdzie do utraty danych na Macierzy B. 

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

i kierunku replikacji. 

19.  Macierz  A  i  Macierz  B  muszą  zapewnić  możliwość  pracy  w  środowisku  GDPS/PPRC  

z zapewnieniem następujących funkcjonalności: 

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

użyciu mechanizmu opisanego w punkcie 14, 

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

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

c. automatyzacji wykonania kopii opisanej w punkcie 2 powyżej na kilka oddzielnych grup dysków 

docelowych (tertiary), 

d. automatyzacji czynności przełączenia przetwarzania wejścia/wyjścia na dyski docelowe (secondary) 

w  trakcie  planowanej  i  nieplanowanej  niedostępności  dysków  źródłowych  (primary)  wykorzystując 

kopie opisaną w punkcie 1 powyżej - przełączenie przetwarzania nie powoduje przerwy w działaniu 

aplikacji hosta, 

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

Odwołujący dla zobrazowania kwestii niespełnienia przez macierze HPE XP8 i VSP5600 „zawiłego” 

wymagania z pkt. 37 w połączeniu z pkt. 12, 14-19 Rozdziału 2 OPZ przedstawił w odwołaniu „Tabelę 

niespełnienia wymagań”.  

W zakresie braku 

obsługi przy pomocy programów TSO i DFSMSdss Odwołujący wskazał, że jak 

widać z przedstawionej przez niego Tabeli, w rzeczywistości wymagań, które nie spełniają macierze 

HPE XP8 i VSP5600 jest wiele, natomiast Odwołujący skupił się w treści rozwinięcia Zarzutu na kilku 

kluczowych  funkcjonalnościach,  których  nie  posiadają  te  macierze,  a  które  były  wymagane  przez 

Zamawiającego w pkt. 37, w połączeniu z pkt. 12, 14-19, Rozdział 2 OPZ. 

Po  pierwsze, 

Odwołujący  podkreślił,  że  wszystkie  trzy  nazwy  występujące  w  wymaganiu  

37 (DFSMS, ICKDSF, TSO) określają dokładnie  zdefiniowane oprogramowanie uruchomione pod 

kontrolą systemu operacyjnego z/OS na serwerach IBM serii z (wskazanych w wymaganiu 12). Zatem 

Zamawiający 

opisał 

precyzyjnie 

posiadany 

serwer, 

posiadany 

system 

operacyjny  

i posiadane oprogramowanie do kopiowania danych pomiędzy macierzami. Oznacza to, że wymagał 

dostarczenia Macierzy, które będą wykonywały komendy realizujące replikację danych, wydawane 

przez program TSO i DFSMS zainstalowane na serwerze IBM System z.  

Po drugie, Oferent Macierzy miał obowiązek sprawdzić listę poleceń programów wymienionych przez 

Zamawiającego w wymaganiu 37 (DFSMSdss, ICKDSF, TSO) i dostarczyć wszystkie funkcjonalności 

niezbędne  do  prawidłowej  realizacji  komend,  które  dotyczą  replikacji  w  trybie  niesynchronicznym 

(wymaganie 14) i tych, które dotyczą resynchronizacji w trybie różnicowym (wymaganie 15). Lista 

poleceń (komend) została opisana w publicznie udostępnionej dokumentacji systemu operacyjnego 

z/OS. 

Opis  funkcjonalności  kopiowania  danych  w  systemie  operacyjnym  z/OS  z  poziomu  programów 

DFSMS i TSO jest publicznie dostępny w podręczniku „DFSMS Advanced Copy Services”  

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

Podręcznik ten opisuje, w jaki sposób wymaganie 14 (zdalna replikacja danych) jest realizowane przy 

pomocy programów DFSMS i TSO (wymaganie 37). Odwołujący zacytował nagłówek Rozdziału 2, 

aby uporządkować nazewnictwo metod replikacji dostępnych w systemie operacyjnym z/OS: 

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

Zdalna  kopia  to  rozwiązanie  do  odzyskiwania  danych  po  katastrofie,  ciągłości  biznesowej  

i  migracji  danych  oparte  na  funkcjonalnościach  Macierzy,  które  umożliwia  kopiowanie  danych  do 

zdalnej  lokalizacji  w  czasie  rzeczywistym.  „Zdalna  kopia”  odnosi  się  do  następujących  głównych 

funkcjonalności Zaawansowanych Usług Kopiowania: 

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

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

3. Global Mirror, or asynchronous PPRC 

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

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

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

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

Global Mirror, czyli asynchroniczne PPRC, to kopia zdalna grupy wielu woluminów zachowująca 

spójność danych (obraz wielu woluminów z tego samego momentu w czasie), 

z/OS Global Mirror czyli XRC, to funkcja zdalnej kopii asynchronicznej zachowująca spójność danych 

na grupie wielu woluminów i kompatybilność pomiędzy różnymi Macierzami. 

Dalej, akapit na str. 

15 informuje, że celem tego, że DFSMS obsługuje wiele metod kopiowania danych, 

jest zastosowanie w zależności od różnych sytuacji – planowanych i nieplanowanych (np. awaria). 

Zgodnie z t

łumaczenie na język polski: „W zależności od konkretnych potrzeb możesz wybrać jedną  

z kilku opcji odzyskiwania danych po awarii z kopii zdalnej: Rozszerzona kopia zdalna (XRC), kopia 

zdalna peer-to-peer (PPRC) lub PPRC-

Extended Distance.” 

Na  tej  samej  stronie  znajduje  się  tabela,  która  pomaga  operatorowi  systemu  operacyjnego  z/OS 

podejmować decyzję jaką metodę replikacji danych zastosować.  

Odwołujący wskazał, że zarówno macierze HPE XP8, jak i macierze VSP 5600 nie potrafią obsłużyć 

metod  replikacji  XRC,  Global  Mirror  oraz  Global  Copy  (PPRC-XD),  wymienionych  

w Tabeli wskazanej 

w odwołaniu przy pomocy programów TSO i DFSMS. 

W  odniesieniu  do  zarzutu  braku  replikacji  XRC  dla  macierzy  HPE  XP8  i  macierzy  VSP  5600, 

Odwołujący wskazał, że jeśli chodzi o ofertę T-Mobile, to w zakresie replikacji XRC funkcjonalność taka 

mogłaby istnieć, gdyby wykonawca T-Mobile dostarczył wraz z Macierzami licencje na obsługę XRC 

– czego nie uczynił, jak wynika z wypełnionego załącznika 1A do SWZ przez tego wykonawcę. Żadna 

z trzech licencji (LUN Manager, Remote Web Console, XP8 Mainframe Performance Advanced Suite) 

wymi

enionych w wypełnionym Załączniku 1A do SWZ nie umożliwia replikacji zdalnej w trybie XRC 

obsługiwanym przez programy TSO i DFSMS. 

Macierze  HPE  XP8  nie  potrafią  poprawnie  obsłużyć  poleceń  programów  TSO  i  DFSMS  

w  zakresie  replikacji  danych  metodą  XRC,  co  Zamawiający  może  stwierdzić  na  podstawie  braku  

w Załączniku 1A licencji producenta (firmy HPE) do replikacji asynchronicznej o nazwie „Compatible 

XRC”.  Odwołujący  dodał,  że  publicznie  dostępne  informacje  firmy  HPE  na  temat  możliwości 

zastosowania  XRC  na  macierzach  XP8  są  obłożone  restrykcjami.  W  podręczniku  „HPE  XP8 

Documentation Roadmap”  

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

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  loka

lizacji  głównej.  Następnie  SDM 

zapisuje dane na woluminie docelowym w macierzy zdalnej w tej samej kolejności, w jakiej zostały 

zapisane w lokalizacji głównej. 

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

W odniesieniu do oferty WASKO w zakresie replikacji XRC 

Odwołujący wskazał, że  funkcjonalność 

taka mogłaby istnieć, gdyby Oferent dostarczył wraz z Macierzami licencje na obsługę XRC – czego 

nie  uczynił,  jak  wynika  z  wypełnionego  załącznika  1A  do  SWZ  przez  tego  wykonawcę.  Żadna  

z licencji wymienionych przez WASKO w Załączniku 1A do SWZ (OpsCenter lub Hitachi Ops Center 

Analyzer for Mainframe) nie umożliwia replikacji zdalnej w trybie XRC obsługiwanym przez programy 

TSO i DFSMS. 

Macierze  VSP  5600  nie  potrafią  poprawnie  obsłużyć  poleceń  programów  TSO  i  DFSMS  

w  zakresie  replikacji  danych  metodą  XRC,  co  Zamawiający  może  stwierdzić  na  podstawie  braku  

w Załączniku 1A do SWZ licencji producenta (firmy HITACHI) do replikacji asynchronicznej np. Hitachi 

TruCopy for Mainframe i Universal Replicator for Mainframe. 

W  odniesieniu  do  b

rak  funkcjonalności  PPRC  i  Global  Mirror  i  macierzy  VSP  5600,  Odwołujący 

wskazał,  że  w  zakresie  replikacji  Global  Mirror  funkcjonalność  ta  nie  istnieje  „by  design”  

w oferowanej macierzy VSP 5600 z powodu ułomności architektury tej macierzy i z powodu braków 

takiej  funkcjonalności  w  jej  mikrokodzie  –  co  skutkuje  niedostosowaniem  macierzy  do  serwera 

Mainframe, 

systemu 

operacyjnego 

z/OS 

oraz 

pełnej 

obsługi 

programów 

TSO  

i  DFSMS.  Macierze  VSP  5600  nie  potrafią  poprawnie  obsłużyć  poleceń  programów  TSO  

i DFSMS w zakresie Global Mirror, co Zamawiający mógł stwierdzić żądając od oferenta wskazania 

publicznie dostępnej dokumentacji producenta (firmy HITACHI Vantara) do replikacji asynchronicznej 

realizowanej programem TSO pod systemem operacyjnym z/OS (nie ma dokumentacji producenta 

opisującego funkcjonalności, których on nie dostarcza). Odwołujący podkreślił, że nie możemy w tym 

miejscu  przytoczyć  dowodu  z  dokumentacji  VSP  5600  na  brak  obsługi  asynchronicznego 

PPRC/Global Mirror poprzez program TSO, bo dokumentacja taka nie istnieje - producent w swojej 

dokumentacji  nie  opisuje  funkcjonalności,  której  nie  posiada.  Nie  mniej  znaleźć  można  wzmiankę  

o  braku  wsparcia  w  dokumencie  „System  Administrator  Guide  for  VSP  5000  Series”  na  stronie 

https://docs.hitachivantara.com/r/en-us/virtual-storage-platform-5000-series/90-09-2x/mk-

98rd9009/system-option-modes-soms/system-option-modes-for-vsp-5000-series. 

Z  t

łumaczenia  na  język  polski  wynika:  „Chociaż  opcja  CASCADE  może  być  podana  

w komendzie ESTPAIR, to funkcjonalność PPRC-XD nie jest wspierana”. 

Odwołujący wyjaśniając treść tej wzmianki wskazał, że istotna jest informacja „funkcjonalność PPRC-

XD nie jest wspierana” – co dotyczy metody replikacji obsługiwanej przez programy DFSMS, ICKDSF 

i  TSO  cytowanej  akapit  wyżej,  natomiast  pojęcie  CASCADE  dotyczy  tworzenia  kopii  z  kopii 

(zobrazowane  w  dalszej  części  tego  dokumentu  na  rysunku),  a  komenda  ESTPAIR  dotyczy 

zestawienia pary dwóch woluminów z których pierwszy zawiera dane produkcyjne, a drugi jest jego 

kopią. 

W  odniesieniu  do  macierz  HPE  XP8  w  zakresie  replikacji  Global  Mirror 

Odwołujący  wskazał,  że 

funkcjonalność  ta  nie  istnieje  „by  design”  z  powodu  ułomności  architektury  tej  macierzy  

i z powodu braków takiej funkcjonalności w jej mikrokodzie – co skutkuje niedostosowaniem macierzy 

HPE XP8 do serwera Mainframe, systemu operacyjnego z/OS oraz pełnej obsługi programów TSO i 

DFSMS. Macierze HPE XP8 nie potrafią poprawnie obsłużyć poleceń programów TSO i DFSMS w 

zakresie  Global  Mirror,  co  Zamawiający  mógłby  stwierdzić  np.  żądając  od  oferenta  wskazania 

publicznie dostępnej dokumentacji producenta (firmy HPE) do replikacji asynchronicznej realizowanej 

programem  TSO  pod  systemem  operacyjnym  z/O

S  (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. 

Uzasadni

ając  powyższe  Odwołujący  wskazał,  że  opis  „wywoływania  funkcji  Macierzowych”  dla 

programu ICKDSF jest publicznie dostępny  

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

Lista wszystkich 15 poleceń ICKDSF znajduje się na stronie 4 (Tabela 9) „Device Support Facilities 

(ICKDSF) User's Guide and Reference”. 

Program  ICKDSF  zażąda  od  Macierzy  replikacji  asynchronicznej  (realizacji  wymagania  14)  po 

wydaniu przez użytkownika systemu z/OS komendy PPRCopy.  

Wyjaśnienie komendy PPRCopy znajduje się w Rozdziałach 20 i 21, zgodnie z tłumaczeniem: Zdalna 

Kopia  „Peer-to-Peer”  (PPRCOPY),  opisana  także  jako  PPRC,  pozwala  na  synchroniczne  

i niesynchroniczne kopiowanie wolumenów dyskowych z jednego podsystemu do innego podsystemu 

macierzowego, bez udziału centralnego serwera, dla tych macierzy, które to wspierają oraz zgodnie z 

tłumaczeniem:  ICKDSF  obsługuje  niesynchroniczne  PPRCOPY  (Global  Mirror)  udostępniając 

polecenia które umożliwią:  

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

PPRCOPY POPULATESESSION oraz PPRCOPY QUERY SESSIONSDEVICES. 

Odwołujący ponadto wskazał, że w podręczniku „Device Support Facilities (ICKDSF) User's Guide and 

Reference” opisano komendy programu ICKDSF, które realizują wymagania SWZ nr 14 i 15. Znajduje 

się  tam  m.in.  akapit,  który  zgodnie  z  tłumaczeniem  na  język  polski  brzmi:  PPRCOPY 

DEFINESESSION  jest  przeznaczony  do  zarządzania  procesem  tworzenia  grup  spójności  (grup 

woluminów). Pojedyncza grupa woluminów, dla której utworzona jest pojedyncza grupa spójności, 

nazywana jest sesją. Sesje są otwierane (tworzone) i zamykane (kończone) za pomocą polecenia 

PPRCOPY  DEFINESESSION.  Członkostwo  w  sesji  jest  kontrolowane  za  pomocą  komendy 

PPRCOPY  POPULATESESSION.  Topologię  sesji  asynchronicznej  PPRCOPY  i  pewne  atrybuty 

okresu trwania 

konfiguruje się za pomocą komendy PPRCOPY STARTASYNCCOPY, która również 

rozpoczyna przetwarzanie. 

Odwołujący wskazał, że macierze HPE XP8 i VSP 5600 nie potrafią wykonać polecenia „PPRCOPY 

DEFINESESSION”,  czyli  nie  potrafią  otworzyć  (i  zamknąć)  sesji  dla  replikacji  asynchronicznej  

w sposób opisany w wymaganiu 14, czyli: „Funkcja musi być realizowana przy użyciu mechanizmów 

Macierzy, dla grupy wielu wolumenów dyskowych w celu uzyskania spójnej (konsystentnej) kopii tych 

wolumenów  (tzw.  fizyczna  replikacja  danych)  w  trybie  synchronicznym  oraz  niesynchronicznym  

z  wykorzystaniem  jedynie  kontrolerów  dyskowych”  oraz  że  macierze  HPE  XP8  i  VSP  5600  nie 

wykonają kolejnego polecenia ICKDSF „PPRCOPY POPULATESESSION”, które realizuje dodanie 

lub usunięcie do sesji wskazanych przez operatora woluminów (zgodnie z przytoczoną dokumentacją 

ICKDSF)

.  Zgodnie  z  jej  tłumaczeniem:  Polecenie  PPRCOPY  POPULATESESSION  służy  do 

zapełnienia lub usunięcia sesji, która została wcześniej OTWARTA za pomocą polecenia PPRCOPY 

DEFINESESSION. 

Odwołujący wskazuje, że nie mógł w tym miejscu przytoczyć dowodu z dokumentacji HPE XP8 i VSP 

5600  na  brak  obsługi  asynchronicznego  PPRC/Global  Mirror  poprzez  program  ICKDSF,  bo 

dokumentacja taka nie istnieje - 

producent w swojej dokumentacji nie opisuje funkcjonalności, których 

nie  posi

ada.  Brak  takiej  funkcjonalności  wskazuje  na  ułomność  architektury  tej  Macierzy  oraz  jej 

niedostosowanie  do  platformy  serwerów  Mainframe  i  systemu  operacyjnego  z/OS.  Konsekwencją 

braku wsparcia macierzy HPE XP8 i macierzy VSP 5600 dla programu ICKDSF jest brak reakcji na 

jego komendy, co skutkuje niemożliwością wykonania następujących działań związanych z replikacją 

danych: 

a.) Brak reakcji macierzy HPE XP8 i macierzy VSP 5600 na komendę „PPRCOPY DEFINESESSION” 

uniemożliwia Zamawiającemu definiowanie „grupy wielu wolumenów dyskowych w celu uzyskania 

spójnej  (konsystentnej)  kopii  tych  wolumenów”  (wymaganie  14.)  przy  pomocy  programu  ICKDSF 

(wymaganie 37).  

b.)  Brak  możliwości  wykonania  komendy  „PPRCOPY  POPULATESESSION”  uniemożliwia 

Zamawiającemu dodawanie i usuwanie wybranych wolumenów dyskowych do grupy przy pomocy 

programu ICKDSF.  

c.) Brak możliwości wykonania komendy „PPRCOPY QUERY SESSIONSDEVICES” uniemożliwia 

Zamawiającemu 

uzyskanie 

informacji 

o 

woluminach 

dyskowych 

wchodzących  

w  skład  sesji  -  grupy  spójnej  (konsystentnej)  kopii  przy  pomocy  programu  ICKDSF  (wymaganie  

37 „raportowanie o statusie”). 

d.)  Ponadto  macierze  HPE  XP8  nie  potrafią  wykonać  polecenia  ICKDSF  „PPRCOPY 

STARTASYNCCOPY”,  które  nakazuje  dwóm  macierzom  realizację  zdalnej  kopii  asynchronicznej  

i zapewnia funkcjonalność wymagania SWZ nr 15: „W przypadku zawieszenia lub zerwania fizycznej 

replikacji danych, musi istnieć możliwość resynchronizacji wolumenów pomiędzy Macierzami w trybie 

różnicowym (propagacja tylko tych danych, które uległy zmianie)”. 

Zgodnie z tłumaczeniem: PPRCOPY STARTASYNCCOPY służy do inicjowania lub modyfikowania 

konfiguracji  asynchronicznej  sesji  PPRCOPY  oraz  do  rozpoczynania  lub  wznawiania 

asynchronicznego tworzenia grup spójności PPRCOPY. 

e.)  Oprócz  wyżej  przytoczonych  przykładów  lista  komend  PPRCOPY  programu  ICKDSF,  których 

macierze HPE XP8 nie potrafią wykonać jest dłuższa i obejmuje między innymi polecenia: 

PPRCOPY  TERMASYNCCOPY  PAUSE 

–  wstrzymanie  sesji  np.  na  czas  aktualizacji  programu 

PPRCOPY  TERMASYNCCOPY  TERMINATE 

–  zakończenie  sesji  PPRCOPY  QUERY 

ASYNCCOPY 

– uzyskanie informacji o sesji PPRCOPY QUERY OUTOFSYNCSTATE – uzyskanie 

informacji o „różnicy danych, które uległy zmianie” (wymaganie 15). 

Odwołujący wskazał na następujący wniosek: Macierze oferowane przez HPE XP8 oferowane przez 

T-

Mobile, IT Solution Factor i Symmetry oraz macierze VSP 5600 oferowane przez Wasko nie potrafią 

poprawnie obsłużyć poleceń programu ICKDSF w zakresie wykonywania replikacji asynchronicznej 

PPRC  (Global  Mi

rror),  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 producent

a opisującego 

funkcjonalności, których dana macierz nie posiada. 

W  odniesieniu  do  zarzut  nr  2 

– braku zapewnienia możliwości pracy w środowisku GDPS/PPRC, 

Odwołujący wskazał, że Zamawiający w pkt. 19, Rozdział 2 OPZ wskazał, że Macierz A i Macierz B 

muszą  zapewnić  możliwość  pracy  w  środowisku  GDPS/PPRC  z  zapewnieniem  następujących 

funkcjonalności: 

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

przy użyciu mechanizmu opisanego w punkcie 14, 

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

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

3. automatyzacji wykonania kopii opisanej w punkcie 2 powyżej na kilka oddzielnych grup dysków 

docelowych (tertiary), 

4. automatyzacji czynności przełączenia przetwarzania wejścia/wyjścia na dyski docelowe (secondary) 

w  trakcie  planowanej  i  nieplanowanej  niedostępności  dysków  źródłowych  (primary)  wykorzystując 

kopie opisaną w punkcie 1 powyżej - przełączenie przetwarzania nie powoduje przerwy w działaniu 

aplikacji hosta, 

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

Odwołujący  wskazał,  że  zarówno  macierz  HPE  X8,  jak  i  macierz  VSP  5600  nie  zapewniają  tej 

możliwości, w sposób określony przez Zamawiającego. 

Brak wyżej opisanego trybu replikacji „z wykorzystaniem jedynie kontrolerów dyskowych” (Zarzut Nr 1) 

powoduje, że macierze HPE XP 8 i VSP 5600 nie mogą zapewnić spełnienia wymagania z pkt 19.1, 

19.2  i  19.3  OPZ  powyżej,  czyli  współpracy  z  usługą  GDPS,  która  dostarcza  automatyzację  

i  konsystencję  danych  dla  wymaganego  schematu  kopiowania  A  ->  B  ->  C,  gdzie  A  oznacza 

produkcyjne woluminy „primary”, B to zdalna macierz z dyskami docelowymi „secondary”, a C to kopie 

„tertiary”.  

Po awarii dysków A nieskuteczne będzie odwrócenie relacji kopiowania i odzyskanie spójnych danych 

z kopii C poprzez polecenie ICKDSF. Lista macierzy spełniających wymagania SWZ 19.1 – 19.5 jest 

opublikowana przez dostawcę usługi GDPS pod linkiem https://www.ibm.com/products/gdps.  

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

Zgodnie z wnioskiem Odwołującego - macierze HPE XP8 oraz macierze HPE XP8 nie współpracują 

z usługą GDPS zapewniającą automatyzację procesu kopiowania spójnej grupy woluminów. 

W  odniesieniu  do  zarzutu  nr  3 

odwołania  –  rozbudowa  macierzy  z  wykorzystaniem  dysków 

obrotowych

, Odwołujący wskazał, że Zamawiający dnia 20 listopada 2023 r. udzieli Odpowiedzi na 

pytanie  nr  2)  do  wymagania  określonego  w  pkt.  4,  Rozdział  2,  OPZ,  tj.  w  którym  wskazał,  że  do 

rozbudowy macierzy nie dopuszcza wykorzystania dysków obrotowych.  

W  ocenie 

Odwołującego,  zarówno  macierz  HPE  XP  8,  jak  i  macierz  VSP  5600  dla  rozbudowy 

macierzy wymagają zastosowania dysków obrotowych. 

Macierz VSP 5600 

Według  specyfikacji  producenta  Hitachi  Vantara  „rodzina”  macierzy  VSP  5000  może  być 

rozbudowywana przez powolne dyski obrotowe HDD, co nie spełnia wymagania Zamawiającego.  

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

dwa rodzaje dysków obrotowych. 

Źródło: 

https://www.hitachivantara.com/en-us/pdf/specifications/virtual-storage-platform-vsp-5200-

5600-spec-table.pdf 

Fakt możliwości rozbudowy macierzy Hitachi VSP 5000 o dyski obrotowe HDD oznacza, że macierz 

ta  nie  spełnia  wymagania  Zamawiającego:  „Zamawiający  informuje,  iż  wymaga  dostarczenia 

Macierzy, w których nie można stosować dysków obrotowych do rozbudowy pojemności (...)” 

Macierz HPE XP8 

Według  dokumentacji  dostępnej  na  stronie  producenta  macierzy  HPE  XP8,  macierz  ta  może  być 

rozbudowywana przez powolne dyski obrotowe HDD, co nie spełnia wymagania Zamawiającego. Na 

stronie  HPE  Support  znajduje  się  wykaz  części  zamiennych  instalowanych  w  macierzy,  gdzie  po 

wpisaniu w pole wyszukiwania „HDD” publikowane są trzy rodzaje dysków obrotowych. 

Źródło:https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00093353en_u

s&page=GUID-82F20103-C3FD-490E-B904-4958658699B4.html 

Informacja o dyskach obrotowych HDD jest także powtórzona w specyfikacji macierzy XP8 jako jej 

standardowa cecha w kolumnie „increment” (rozbudowa) 

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

W  odniesieniu  do  zarzutu  nr  4 

odwołania  –  braku  kompatybilności  macierzy  XPE  XP8  

z systemami operacyjnymi S/390 (z/OS i z/VM)

, Odwołujący wskazał, że macierz HPE XP8 oferowana 

przez T-

Mobile, a także przez wykonawców Symmetry i IT Solution Factor nie spełnia wymagania 

SWZ Załącznik nr 11, Rozdział 2, pkt. 12, czyli nie jest kompatybilna z systemami operacyjnymi S/390 

(z/OS i z/VM). Zgodnie z  wymaganiem 

z pkt 12. Rozdziału 2, każda Macierz ma obsługiwać serwery 

System z (serwery IBM serii z), z systemem operacyjnym S/390 (z/OS, z/VM, Linux) 

Na stronie producenta macierzy HPE w rozdziale „Software Compatibility” dla Macierzy HPE XP8 

można znaleźć tylko jeden z wymaganych systemów, czyli Linux. 

Dowód:https://support.hpe.com/hpesc/public/docDisplay?docId=a00093353en_us&page=GUID-

BC8A4697-118A-490F-B4E7-9A75F54C9D0A.html 

W  odpowiedzi  na  odwołanie  Zamawiający  w  piśmie  z  dnia  21  sierpnia  2024  r.  wniósł  

o 

oddalenie  odwołania  w  całości  oraz  o  obciążanie  Odwołującego  kosztami  postępowania,  

w tym kosztami zastępstwa procesowego. 

W uzasadnieniu pisma, Zamawiający wskazał, że zarzuty odwołania, zdaniem Zamawiającego, są 

pozbawione należytych podstaw, wobec czego odwołanie powinno zostać oddalone. 

Odwołujący wskazał, że oferty wykonawców T-Mobile , WASKO, Symmetry oraz IT Solution Factor są 

niezgodne z Opisem Przedmiotu Zamówienia. Zamawiający wskazał, że istotne w przedmiocie sprawy 

było, jakie macierze dyskowe zostały zaoferowane przez każdego z ww. wykonawców, a także przez 

Odwołującego. 

Zamawiający zwrócił uwagę, że Odwołujący jako jedyny Wykonawca zaoferował macierze dyskowe 

firmy IBM. Odwołujący próbował w odwołaniu dowieść, że macierze dyskowe firmy HPE oraz Hitachi 

nie spełniają wymagań postawionych przez Zamawiającego w Specyfikacji Warunków Zamówienia,  

a  ściślej  rzecz  ujmując  –  wymagań  określonych  w  Szczegółowym  opisie  przedmiotu  zamówienia 

(OPZ), stanowiącym Załącznik nr 11 do SWZ. Zamawiający podkreślił, że biorąc pod uwagę fakt, że 

na rynku wiodącymi producentami w obszarze rozwiązań macierzowych dla platformy mainframe są 

firmy HPE, IBM oraz Hitachi, wywód Odwołującego może prowadzić do wniosku, że jedynie macierz 

firmy IBM spełnia wymagania Zamawiającego, natomiast Zamawiający przygotował opis przedmiotu 

zamówienia (OPZ) w taki sposób, aby dopuścić rozwiązania co najmniej kilku podmiotów, w tym tych 

trzech,  które  są  wiodącymi  na  rynku  producentów,  o  czym  świadczą  i  co  potwierdzają  m.in. 

zdefiniowane pozacenowe kryteria oceny ofert, odpowiedzi udzielone na etapie wyjaśnień treści SWZ 

oraz odpowiedzi na wcześniejsze odwołania. Nie bez znaczenia dla opisu wymagań względem OPZ 

był również fakt, że obecnie Zamawiający z powodzeniem eksploatuje u siebie, w obszarze mainframe, 

macierze  dyskowe  HPE  XP7,  które  są  poprzednią  generacją  macierzy  oferowanych  

w niniejszym postępowaniu przez wykonawców T-Mobile, Symmetry i IT Solution Factor. 

Zarzuty postawione przez Odwołującego sprowadzały się, w ocenie Zamawiającego, do twierdzenia, 

że macierze producentów HPE oraz Hitachi nie spełniają poniższych wymagań Zamawiającego: 

Zarzut 1: dotyczy

ł macierzy HPE oraz Hitachi - brak możliwości wykonywania poleceń TSO, ICKDSF 

oraz DFSMSdss w zakresie różnych metod replikacji pomiędzy macierzami: XRC, PPRC, PPRC-XD, 

Global Mirror, Cascade PPRC, Multi Target PPRC. 

Zarzut 2: dotyczy

ł macierzy HPE oraz Hitachi - brak możliwości pracy macierzy w środowisku  

GDPS/PPRC. 

Zarzut 3: dotyczy

ł macierzy HPE oraz Hitachi - możliwość rozbudowy macierzy z wykorzystaniem 

dysków obrotowych (HDD z ang. Hard Disk Drive). 

Zarzut 4: dotyczy

ł macierzy HPE - brak kompatybilności macierzy HPE XP8 z systemami operacyjnymi 

S/390 (z/OS, z/VM). 

Na  wstępie  Odwołujący  podniósł,  że  macierze  HPE  XP8  oraz  Hitachi  Vantara  VSP  5600  są 

macierzami  „podobnej  konstrukcji”,  co  miałoby  być  argumentem  wskazującym  na  niespełnienie 

wymagań  OPZ  przez  obie  ww.  macierze.  Jednak  jak  wskazał  sam  Odwołujący  zarzut  4  dotyczył 

jedynie  macierzy firmy  HPE, co  w  ocenie  Zamawiającego jednoznacznie przemawiało za tym, że 

macierze HPE XP8 oraz Hitachi Vantara VSP 5600 w pewnych elementach są od siebie różne.  

Ponadto Odwołujący, w punkcie 2 uzasadnienia odwołania podniósł, że oferowane rozwiązania muszą 

być  w  pełni  kompatybilne  z  platformą  mainframe.  Zamawiający  zwrócił  uwagę,  że  zgodnie  

z pełną nazwą zamówienia, oferowane macierze muszą mieć możliwość współpracy z systemami 

otwartymi, czyli platformą inną niż platforma mainframe. Odwołujący również stwierdził, że macierze 

muszą być w pełni kompatybilne z platformą mainframe, po czym dodał „co ważne w sposób opisany 

w  OPZ”.  Zamawiający  podkreślił,  że  oferowane  macierze  muszą  być  kompatybilne  z  platformą 

mainframe jedynie w zakresie określonym w OPZ, co ma istotne znaczenie w kontekście stawianych 

zarzutów. 

W odniesieniu do zarzutu nr 1 odwołania, Zamawiający wskazał, że Odwołujący, powołując się na 

dokumentację IBM, przywołał zaawansowane metody replikacji zewnętrznej, dostępne w systemie 

operacyjnym z/OS na platformie mainframe. Odwołujący wymienił: 

•  XRC – (ang. eXtended Remote Copy, znane również jako „Global Mirror for z/OS” – nie należy 
mylić z Global Mirror) – metoda asynchronicznej replikacji danych pomiędzy macierzami, która odbywa 

się na duże dystanse. Co istotne metoda ta zarządzana jest przez system operacyjny z/OS co w 

znaczący sposób konsumuje moc obliczeniową serwerów mainframe, na których system z/OS jest 

uruchomiony. 

•  PPRC – (ang. Peer to Peer Remote Copy) – metoda synchronicznej replikacji danych pomiędzy 
macierzami,  która  odbywa  się  na  krótsze  dystanse  (rekomendowane  do  100  km)  

z  pominięciem  systemu  operacyjnego  z/OS,  z  wykorzystaniem  jedynie  kontrolerów  macierzy 

dyskowej. Co istotne implementacją PPRC jest oprogramowanie firmy Hitachi o nazwie TrueCopy. 

•  PPRC-XD  –  (ang.  PPRC  eXtended  Distance,  znane  również  jako  Global  Copy)  –  metoda 
asynchronicznej  replikacji  danych  pomiędzy  macierzami.  Przy  zastosowaniu  protokołu  FICON 

(implementacja  protokołu  Fibre  Channel)  odległość  pomiędzy  macierzami  dyskowymi  jest 

nielimitowana. 

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

•  Cascaded PPRC (zwany Metro/Global Copy) – rozwiązanie umożliwiające połączenie dwóch par 

PPRC: synchronicznego PPRC oraz PPRC-

XD, które działają asynchronicznie. Celem kaskadowego 

PPRC jest utworzenia niedrogiej konfiguracji odzyskiwania danych po awarii n

a 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 

kompat

ybilne 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  real

izowane  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  wskaz

ał,  że  nie  wymagał,  aby  funkcje  macierzowe  były 

wywoływane poprzez polecenia ICKDSF, a jedynie z poziomu systemu operacyjnego z/OS. 

W końcowej części Zarzutu 2, Odwołujący stwierdził, że jedynie macierze Hitachi VSP 5600 posiadają 

kwalifikację IBM do działania w środowisku GDPS. Zamawiający zauważył, że macierze Hitachi VSP 

5600  są  macierzami  z  serii  Hitachi  Virtual  Storage  Platform  5000,  a  co  za  tym  idzie  objęte  są 

kwalifikacją  IBM.  Istotne  dla  sprawy  również  jest,  co  na  wstępie  zauważył  sam  Odwołujący,  że 

macierze HPE XP8 są macierzami o podobnej konstrukcji co macierze Hitachi VSP 5600 tzn. są 

„OEM’em macierzy Hitachi Vantara”. Umowa OEM (skrót od ang. Original Equipment Manufacturer) 

odnosi się w tym przypadku do umowy zawartej pomiędzy Hitachi Vantara a HPE, na podstawie której 

firma HPE może używać macierzy Hitachi VSP 5600 pod swoją własną marką i nazwą (markuje jako 

swój własny). Oznacza to, że jeżeli macierz Hitachi posiada kwalifikację IBM do działania w środowisku 

GDPS, to macierz HPE również będzie działała w tym środowisku. Zamawiający zaznaczył, że nie 

wymagał formalnego potwierdzenie producenta takiej kwalifikacji. 

W odniesieniu do zarzutu nr 3 odwołania, Zamawiający wskazał, że Odwołujący przywołał odpowiedź 

Zamawiającego na Pytanie nr 2, zawartą w piśmie nr 993200.271.IN-1130.2023, opublikowanym na 

stronie  internetowej 

prowadzonego  postępowania  w  dniu  22.11.2023  r.,  w  której  Zamawiający 

jednoznacznie wykluczył macierze dyskowe „w których nie można stosować dysków obrotowych do 

rozbudowy  pojemności”.  Zdaniem  Odwołującego  oznaczało  to,  że  Zamawiający,  zgodnie  

z  pozostałymi  wymaganiami  OPZ,  jednoznacznie  wskazał,  że  oferowana  macierz  musi  być 

zbudowana  jedynie  z  dysków  półprzewodnikowych  (flash).  Z  przytoczonego  przez  Odwołującego 

zapytania do SWZ (Pytanie nr 2) należało wnioskować, że istotą stosowania macierzy typu All-Flash 

a nie typu hybrydowego, jest zapewnienie odpowiedniej wydajności macierzy. Zostało to wyrażone 

przez  Zamawiającego  w  wymaganiu  zawartym  w  pkt  4  w  Rozdziale  2  OPZ  oraz  

w odpowiedzi Zamawiającego na Pytanie nr 2.  

Zamawiający podkreślił, że Odwołujący próbował udowodnić, że zarówno macierze Hitachi VSP 5600 

oraz HPE XP8 mają możliwość rozbudowy o dyski obrotowe (HDD). Jednak w przypadku macierzy 

Hitachi Odwołujący w tabeli w punkcie 3 na stronie 18 Odwołania, błędnie zaznaczył, że dyski HDD 

występują w modelu Hitachi VSP 5600H, a taka macierz nie była oferowana przez WASKO S.A. Firma 

Hitachi  posiada  w  swoim  portfolio  zarówno  macierze  typu  All-Flash  (model  VSP  5600)  oraz  typu 

hybrydowego (model VSP 5600H). Opierając się na udostępnionej przez Odwołującego tabeli, na 

liście nie występują dyski HDD dla modelu VSP 5600.  

Zamawiający wskazał, że biorąc pod uwagę, że macierz HPE XP8 jest „OEM’em macierzy Hitachi 

Vantara”,  podobna  sytuacja  występuje  w  macierzach  HPE.  Firma  HPE  wprowadziła  dla  jednego 

modelu XP8 dwa SKU (ang. Stock Keeping Unit): R0L99A - HPE XP8 Hybrid Storage Array oraz 

R0K99A - HPE XP8 All Flash Storage Array. Oznaczenie SKU nie jest same w sobie modelem lub 

typem danego produktu, choć dotyczy konkretnego modelu macierzy. Dlatego też wykonawcy nie byli 

zobowiązani do podania SKU w ofertach. 

Zamawiający ustanowił jako jedno z pozacenowych kryteriów oceny ofert - „Dostarczenie dysków w 

technologii NVMe (Kf5)”. Wszyscy Wykonawcy, którzy zaoferowali macierze HPE XP8 (Symmetry, 

TMobile,  IT  Solution  Factor)  zadeklarowali  w  swoich  ofertach  dostarcze

nie  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 

opa

rtej 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  po

wyż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  SWZ  –  Rozdział  2  –  Szczegółowe  wymagania  dla  Macierzy 

Dyskowych przewidział, zgodnie z pkt 37, iż:  

37. Macierze muszą posiadać możliwość wywoływania funkcji Macierzowych opisanych w punktach 

14,  15,  16,  17,  18,  19  z  poziomu  systemu  operacyjnego  z/OS  (DFSMSdss,  ICKDSF,  TSO)  

i raportowania o statusie. 

Zgodnie z pkt 14:  

Każda Macierz musi posiadać funkcjonalność wykonywania zewnętrznych kopii danych do drugiej 

Macierzy,  znajdującej  się  w  drugim  ośrodku  przetwarzania,  w  odległości  co  najmniej  40  km  za 

pośrednictwem DWDM. Funkcja musi być realizowana przy użyciu mechanizmów Macierzy, dla grupy 

wielu wolumenów dyskowych w celu uzyskania spójnej (konsystentnej) kopii tych wolumenów (tzw. 

fizyczna  replikacja  danych)  w  trybie  synchronicznym  oraz  niesynchronicznym  z  wykorzystaniem 

jedynie kontrolerów dyskowych. 

Zgodnie z pkt 15: 

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 fizyczn

e 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: 

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

replikacji. 

Zgodnie z pkt 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 

przewid

ział, ż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

”. 

W

obec powyższego, w ocenie Izby, Odwołujący nie wykazał niezgodności ofert wykonawców Wasko 

oraz T-Mobile z wymaga

niami 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 o

dwoł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: 

https://www.ibm.com/products/gdps, 

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 

https://futurumgroup.com/dokument/hitachi-vsp-5000-product-analysis/, 

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.  

W

obec powyższego, ocenie Izby Odwołujący nie wykazał, iż oferty wykonawców Wasko oraz T-Mobile 

nie 

są  zgodne  z  wymaganiami  Zamawiającego  z  pkt  19  Rozdziału  2  SWZ,  a  zatem  zarzut  nr  

2 odwołania podlegał oddaleniu. 

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

Odwołujący w uzasadnieniu zarzutu wskazał, zgodnie z odpowiedzią Zamawiającego z 20 listopada 

2023 r. do 

wymagania określonego w pkt 4 w Rozdziale 2 OPZ: „Zamawiający informuje, iż wymaga 

dostarczenia Macierzy, w których nie można stosować dysków obrotowych do rozbudowy pojemności, 

co  jednoznacznie 

wynika  z  aktualnej  treści  wymagania  zawartego  w  pkt  4  Rozdziału  

2 Załącznika 11 do SWZ – Szczegółowy opis Przedmiotu Zamówienia (OPZ)”, do rozbudowy macierzy 

Zamawiający nie dopuścił wykorzystania dysków obrotowych.  

Tymczasem,  jak  wskazał  Odwołujący,  w  odniesieniu  do  macierzy  zaoferowanej  przez 

Przystępującego T-Mobile, zgodnie z dokumentacją dostępną na stronie producenta macierzy HPE 

XP,  macierz  ta  może  być  rozbudowywana  przez  powolne  dyski  obrotowe  HDD,  co  nie  spełnia 

wymagania Z

amawiają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  P

rzystępujący  Wasko  odnosząc  się  do  zarzutu  nr  3  odwołania  wskazał,  że  zaoferował 

macierz  oznaczon

ą  symbolem  5600,  a  nie  5600H,  do  której  odnosi  się  wskazywane  przez 

Odwołującego  (znajdujące  się  na  stronie  Hitachi  z  wykazem  dysków  instalowanych  w  macierzy) 

oznaczenie HDD. 

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

Mając  na  uwadze  powyższe  okoliczności,  Izba  uznała,  że  Odwołujący  nie  wykazał,  iż  oferty 

wykonawców Wasko oraz T-Moblie są niezgodne z wymaganiami Zamawiającego – do rozbudowy 

macierzy nie dopuszcza się wykorzystania dysków obrotowych.  

A zatem zarzut 

nr 3 odwołania podlegał oddaleniu. 

Izba oddaliła zarzuty dotyczące braku spełnienia przez wykonawców Symmetry i IT Solution Factor 

wymagań Zamawiającego, o których była mowa w zarzutach 1-3 odwołania z uwagi na niewykazanie 

przez O

dwoł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 art. 557 i art. 575 ustawy Pzp oraz w oparciu o przepisy 

§ 8 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:  ……………………… 

    ……………………… 

    ………………………