eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plBaza orzeczeń KIO2019 › Sygn. akt: KIO 2334/19
rodzaj: WYROK
data dokumentu: 2019-12-11
rok: 2019
sygnatury akt.:

KIO 2334/19

Komisja w składzie:
Przewodniczący: Ryszard Tetzlaff Protokolant: Rafał Komoń

po rozpoznaniu na rozprawie w dniu 2 i 6 grudnia 2019 r. w Warszawie o
dwołania
wniesionego do Prezesa Krajowej Izby Odwoławczej w dniu 18 listopada 2019 r. przez
wykonawcę JBD Spółka Akcyjna, ul. Ks. Bp. Tymienieckiego 25c lok. 314, 90-350 Łódź w postępowaniu prowadzonym przez Instytucje Filmową „Silesia - Film", ul. Górnicza 5
40-008 Katowice
reprezentowaną przez Bibliotekę Śląską, Pl. Rady Europy 1, 40-021
Katowice

przy udziale wykonawców Konsorcjum firm: 1) Studiotech Poland Sp. z o.o. (Lider);
2) S&T Poland Sp. z o.o. (Członek), ul. Postępu 21D, 02-676 Warszawa; z adresem dla
siedziby lidera: ul. Bażancia 53, 02-892 Warszawa
zgłaszających swoje przystąpienie do
postępowania odwoławczego po stronie zamawiającego


orzeka:

1.
oddala odwołanie



2. k
osztami postępowania obciąża JBD Spółka Akcyjna, ul. Ks. Bp. Tymienieckiego 25c
lok. 314, 90-
350 Łódź
i:



2.1.
zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr
(słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez wykonawcę JBD
Spółka Akcyjna, ul. Ks. Bp. Tymienieckiego 25c lok. 314, 90-350 Łódź
tytułem
wpisu od o
dwołania.

Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. -
Prawo zamówień
publicznych
(t.j. Dz. U. z 27 września 2019 r. poz. 1843)

na niniejszy wyrok -
w terminie 7 dni od
dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa
Krajowej Izby Odwoławczej do Sądu Okręgowego w Katowicach.


Przewodniczący:

………………………………



Sygn. akt: KIO 2334/19


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


Postępowanie o udzielnie zamówienia publicznego prowadzone w trybie przetargu
nieograniczonego z możliwością składnia ofert częściowych /(1) dostawa i instalacja
czyszczarki ultradźwiękowej do taśmy filmowej, (2) dostawa i instalacja stołów
przeglądowych do inspekcji taśmy filmowej oraz przewijarek do taśmy filmowej, (3) dostawa
i instalacja stanowisk do digitalizacji i obróbki cyfrowej, (4) dostawa i wdrożenie infrastruktury
teleinformatycznej do przetwarzania danych/ na:
„Śląskie Digestorium. Digitalizacja
i udostępnianie zasobów instytucji kultury województwa śląskiego"
; zostało wszczęte
ogłoszeniem opublikowanym w Dzienniku Urzędowym Unii Europejskiej w dniu 30.04.2019 r.
pod nr 2019/S 084-199070 przez
Instytucje Filmową „Silesia - Film", ul. Górnicza 5, 40-008
Katowice
reprezentowaną przez Bibliotekę Śląską, Pl. Rady Europy 1, 40-021 Katowice
zwaną dalej: „Zamawiającym”.
W dniu 08.11.2019 r. (
wpływ do Prezesa KIO w wersji elektronicznej podpisane
podpisem cyfrowym za pośrednictwem elektronicznej skrzynki podawczej - ePUAP)
Zamawiający poinformował o wyborze oferty najkorzystniejszej w cz. 4 Konsorcjum firm:
1) Studiotech Poland Sp. z o.o. (Lider): 2) S&T Poland Sp. z o.o. (Członek), ul. Postępu
21D, 02-676 Warszawa; z adres
em dla siedziby lidera: ul. Bażancia 53, 02-892 Warszawa
zwan3 dalej:
„Konsorcjum Studiotech Poland” albo „Przystępującym”. Drugą pozycje
w rankingu złożonych ofert w cz. 4 zajęła oferta JBD S.A., ul. Ks. Bp. Tymienieckiego 25c
lok. 314, 90-
350 Łódź zwana dalej: „JBD S.A.” albo „Odwołującym”.

W dniu 18.11.2019 r.
(wpływ bezpośredni do Prezesa KIO) JBD S.A. wniosło
odwołanie na czynność z 08.11.2019 r. dotyczącą cz. 4. Kopie odwołania Zamawiający
otrzymał w tym samym dniu (e-mailem). Zamawiającemu zarzucił naruszenie:
1) art. 7 ust. 1 i 3 w zw. z art. 89 ust. 1 pkt 2) ustawy z dnia 29 stycznia 2004 r. Prawo
zamówień publicznych (t.j. Dz. U. z 16 października 2018 r. poz. 1986 ze zm.) zwanej dalej:
„Pzp” poprzez ich bezpodstawne niezastosowanie, a w konsekwencji dokonanie wyboru
najkorzystniejszej oferty w zakresie cz. 4
zamówienia Konsorcjum Studiotech Poland oraz
zaniechanie odrzucenia jego oferty
, pomimo że oferta tego wykonawcy nie odpowiada treści
następujących wymagań Zamawiającego określonych w Specyfikacji Istotnych Warunków
Zamówienia zwanej dalej: „SIWZ”:
a. p
kt 1.3. lp. 2 zał. nr 8.4 SIWZ: System macierzy centralnej musi być zorganizowany
w postaci systemu SAN -
z klientami połączonymi poprzez FC (fibre channel) 16 Gb/s.
System ma umożliwiać zapis i odczyt to czasie rzeczywistym plików graficznych

o rozdzielnościach 2K, 4K. Wymagane jest wsparcie systemu dla formatów plików SD, HD,
2K, 4K (RGB 10,12,16 bitów), strumień w czasie rzeczywistym. Formaty danych DPX,
Cineon, TIFF, MXF, Quick Time i inne używane formaty plików wideo,
b. pkt 1.3. lp.
2 zał. nr 8.4 SIWZ: Zarówno macierz „online" jak i „nearline" musi mieć
możliwość wspierania następujące interfejsów hosta (np. poprzez wymianę kontrolera): Fibrę
Channel (32 Gbit/s, 16 Gbit/s, 8 Gbit/s),
c. pkt
1.4 lp. 3 zał. nr 8.4 SIWZ: Zamawiający wymaga możliwości przywracania fragmentów
plików (Partial Restore) po Time Code,
d. p
kt 1.4 lp. 3 zał. nr 8.4 SIWZ: W związku z pracą na plikach DPX zamawiający wymaga,
aby system zarządzania pracował z maksymalną liczbą plików w wysokości minimum 2x10
9
.
System musi pos
iadać bazę danych - której eksternalizacja (backup task) umożliwia
zachowanie danych systemu. Wnosił o:
-
unieważnienie wyboru oferty Konsorcjum Studiotech Poland jako najkorzystniejszej oferty
w zakresie cz. 4
zamówienia,
-
nakazanie Zamawiającemu dokonania ponownego wyboru najkorzystniejszej oferty
z uwzględnieniem unieważnienia oferty zaskarżonej,
- dopuszczenie i przeprowadzenie
dowodu z opinii biegłego wpisanego na listę biegłych SO
w Warszawie z zakresu informatyki oraz
dowodu z zeznań świadków: p. B. W.
i p. Z. Cz., p. P. J. oraz p. M. D. (wezwania na adresy wskazane
w odwołaniu)
na okoliczność wykazania, iż zaoferowany przez Konsorcjum Studiotech Poland sprzęt w cz.
4 zamówienia nie spełnia wymagań SIWZ wskazanych w pkt 1.3. lp. 2 oraz 1.4. lp. 3 zał. nr
8.4 SIWZ,
w szczególności na okoliczność wykazania, iż:
a. macierz QXS producenta Quantum nie obsługuje bezpośrednio opcji Fibrę Channel 32
Gbit/s,
b. system zarządzania marki XenData obsługiwany przez zewnętrzne oprogramowanie firmy
Marquis Broadcast, nie obsługuje funkcji Partial Restore dla plików o formacie DPX według
znaczników czasowych (TimeCode),
c. konsorcjum w formularzu cenowym nie uwzględniło oprogramowania firmy Marquis
Broadcast,
d. system XenData nie posiada bazy danych, której eksternalizacja (backup task) umożliwia
zachowanie danych systemu,
e. system XenData nie jest rozwiązaniem umożliwiającym archiwizację materiałów
w formacie DPX,
-
dopuszczenie i przeprowadzenie dowodów z dokumentów załączonych do odwołania
(oświadczeń oraz wiadomości e-mail) na okoliczności wskazane w uzasadnieniu niniejszego
odwołania, w szczególności na okoliczność, iż:

a. macierz QXS producenta Quantum nie obsługuje bezpośrednio opcji Fibrę Channel 32
Gbit/s,
b. wymogiem Zamawiającego określonym w SIWZ było dostarczenie macierzy, który
obsługuje prędkości interfejsu Fibrę Channel 32 Gbit/s,
c. podstawowym plikiem używanym w rekonstrukcji i postprodukcji obrazu i dźwięku jest plik
typu DPX,
d. system zarządzania marki XenData obsługiwany przez zewnętrzne oprogramowanie firmy
Marquis Broadcast, nie obsługuje funkcji Partial Restore dla plików o formacie DPX według
znaczników czasowych (TimeCode),
e. Konsorcjum w formularzu cenowym nie uwzględniło oprogramowania firmy Marquis
Broadcast,
f. system XenData nie posiada bazy
danych, której eksternalizacja (backup task) umożliwia
zachowanie danych systemu,
g. system XenData nie jest rozwiązaniem umożliwiającym archiwizację materiałów
w formacie DPX,
-
zasądzenie od Zamawiającego na rzecz Odwołującego kosztów postępowania
odwoławczego, w tym kosztów zastępstwa procesowego w wysokości 3.600 zł.
A. Brak spełnienia wymagań technicznych dla systemu specjalizowanej macierzy
centralnej
. Z
amawiający w pkt 1.3. zał. 8.4 SIWZ w sposób szczegółowy charakteryzuje
w
ymagania związane z systemem macierzy centralnej, która z uwagi na uwarunkowania
pracy całego systemu (postprodukcja i rekonstrukcja) stanowi jeden z kluczowych
elementów całego projektu. Jako jeden z kryteriów macierzy centralnej oraz elementów
składowych Zamawiający precyzyjnie określił wymagania na obsługę poszczególnych
rodzajów interfejsu Fibrę Channel macierzy „online" oraz „nearline": „Zarówno macierz
„online” jaki i „nearline" musi mieć możliwość wspierania następujące interfejsów hosta (np.
poprzez
wymianę kontrolera ): Fibrę Channel (32Gbit/s, 16Gbit/s, 8Gbit/s)"
.
Powyższy wymóg w sposób jednoznaczny wskazuje, iż Zamawiający oczekuje
rozwiązania, typu półki macierzowej z bezpośrednio dostępną opcją Fibrę Channel 32 Gbit/
s. Jest to podejście całkowicie zrozumiałe szczególnie przy budowie projektów w zakresie
postprodukcji i rekonstrukcji materiałów archiwalnych, gdzie wymagania dotyczące jakości,
a tym samym wagi poszczególnych plików niezwykle wzrastają. Sformułowanie w ten sposób
p
rzez Zamawiającego wymagań w SIWZ oznacza, iż Zamawiający oczekuje sprzętu
z otwartą drogą rozwoju oraz możliwością jego aktualizacji i rozszerzenia bez wymiany
całości sprzętu. Nabycie przez Zamawiającego macierzy o gorszych parametrach niż
określone w SIWZ, oznacza obowiązek poniesienia wysokich kosztów przez Zamawiającego
w przyszłości. Zarówno przedstawiciel spółki K3 System sp. z o.o. oraz M. J. prowadzący
działalność gospodarczą pod firmą M. J. INS Instruments zajęli w powyższym zakresie

stanowisko stwierdzając, iż sformułowane przez Zamawiającego w pkt 1.3. lp. 2 zał. nr 8.4
SIWZ kryterium wskazuje, że Zamawiający oczekuje dostarczenia macierzy kompatybilnej z
prędkością transmisji 32Gbit/ s.
Zaoferowane przez Konsorcjum macierze serii QXS nie spełniają kryteriów
oznaczonych przez Zamawiającego, bowiem najwyższą dostępną prędkością Fibrę Channel
w kontrolerach jest prędkość 16 Gbit/s, co z kolei oznacza, że jest to lina produktu
zamknięta. Sam producent macierzy QXS 12 w specyfikacji swojego produktu wskazuje
wprost, jako opcje interfejsu wyłącznie 8/16G & 10G iSCSI, a zatem nie obsługuje opcji Fibrę
Channel 32 Gbit/s. Powyższe znajduje potwierdzenie także w stanowiących załącznik do
niniejszego odwołania wiadomościach e-mail, w których przedstawiciele producenta
macierzy serii QXS - Quantum -
oświadczają, iż pamięć QXS dochodzi jedynie do 16 Gb
oraz że obecnie pamięci QXS są dostępne maksymalnie do 16 Gb/s FC. Ewentualne
rozszerzenie prędkości do 32 Gbit/ s jest prawdopodobnym rozwiązaniem przyszłościowym,
które jednak nie wejdzie w życie w najbliższym czasie.
Ponadto, fakt, iż sprzęt zaoferowany przez Konsorcjum nie spełnia wymagań SIWZ
jest oczywisty także dla podmiotów zajmujących się dystrybucją macierzy QXS. Zgodnie
bowiem z oświadczeniem spółki Veracomp S.A., będącej autoryzowanym dystrybutorem
firmy Quantum - macierze serii QXS tego prod
ucenta nie obsługują przepustowości 32 Gb/s
FC. Tożsame stanowisko zajęła spółka Arrow ECS sp. z o.o. stwierdzając, iż seria macierzy
QXS posiada maks
ymalną obsługę prędkości 16 GB/s FC i nie posiada możliwości
rozbudowy, aby mogła obsługiwać prędkość 32 GB/sFC.
B. Brak funkcji przywracania fragmentów plików (Partial Restore). Zgodnie z pkt 1.4. lp. 3 zał.
nr 8.4 SIWZ, Zamawiający wymaga możliwości przywracania fragmentów plików (Partial
Restore) po TimeCode. Funkcja Partial Restore umożliwia pobieranie z archiwum fragmentu
materiału, zamiast oczekiwania na pobranie całego, np. kilka minut filmu z kilkugodzinowego
mat
eriału. W celu realizacji cz. 4 zamówienia, Konsorcjum posługuje się produktem
XenData, czyli systemem służącym do zarządzania magazynem danych, a więc biblioteką
taśmową. Zarządzanie polega na przechowywaniu informacji o lokalizacji plików na taśmach
ETO
(w tym przypadku) oraz zarządzaniu przestrzenią i zasobami taśm. System decyduje,
gdzie
i w jaki sposób mają zostać zapisane dane oraz o czynnościach eksploatacyjnych
związanych z poprawną pracą tzn. zapisem i odczytem plików z taśm LTO. Sprzęt marki
XenData obsługiwany jest przez zewnętrzne oprogramowanie firmy Marquis Broadcast, który
z kolei nie obsługuje funkcji Partial Restore dla plików o formacie DPX według znaczników
czasowych (TimeCode). Pliki są przechowywane w strukturze katalogów i nie ma
bezpośredniej metody na pobranie materiału po TimeCode tylko po ramkach (klatkach
materiału). Oznacza to, że system XenData nie obsługuje podstawowych plików, na których
pracuje się podczas pracy na materiałach poddawanych rekonstrukcji oraz postprodukcji

materiałów filmowych, czyli plików DPX. Powyższe zostało stwierdzone przez trzy niezależne
podmioty specjalizujące się w postprodukcji i rekonstrukcji obrazu, tj. AKFilm Service and
Solutions Artur Kieszek, ATM System sp. z o.o.
oraz Wytwórnię Filmów Dokumentalnych
i Fabularnych.
Oferta zaproponowana przez Konsorcjum nie spełnia zatem wymogu SIWZ
w zakresie funkcji Partial Restore, bowiem nie posługuje się oprogramowaniem
obsługującym tę funkcję. Co więcej, Konsorcjum nie uwzględniło w formularzu cenowym
oprogramowania Marquis Broadcast, umożliwiającego pobieranie danych fragmentarycznych
z archiwum, a więc warunkującego funkcję Partial Restore, co oznacza, że Konsorcjum takiej
funkcji wbrew wymag
aniom Zamawiającego nie obsługuje. Powyższe znajduje potwierdzenie
w oświadczeniu Content Networks Sp. z o.o. z 15.11.2019 r., tj. autoryzowanego partnera
handlowego XenData na terenie Polski, zgodnie z którym Funkcja Partial Restore, czyli
podbieranie danych frag
mentarycznych z archiwum, jest obsługiwana poprzez zewnętrzny
produkt firmy Marąuis Broadcast. W dokumentacji produktu i zestawieniu obsługiwanych
formatów nie ma obsługi plików DPX z uwzględnieniem TimeCode, czyli wybranego zakresu
podając znaczniki czasowe materiału.
Zamawiający w sposób jednoznaczny określił w SIWZ, iż wymaga możliwości
przywracania fragmentów plików. Usterka systemu XenData wyklucza możliwość pracy
archiwum oraz całego mechanizmu postprodukcji opisanego w SIWZ przez Zamawiającego.
Z kolei brak funkcji Partial Restore będzie skutkowało brakiem możliwości pobrania materiału
według znaczników czasowych (TimeCode).
C. Brak bazy danych, której eksternalizacja (backup task) umożliwia zachowanie danych
systemu.
Zamawi
ający w pkt 1.3 lp. 2 zał. 8.4 SIWZ określił, jakie formaty danych używanych
plików wideo musi obsługiwać system macierzy centralnej, wskazując jako jeden z formatów
DPX. Jednocześnie, zgodnie z pkt 1.4. lp. 3 ww. zał. w związku z pracą na plikach DPX
Z
amawiający wymaga, aby system zarządzania pracował z maksymalną liczbą plików
w wysokości minimum 2x10
9
. System musi pos
iadać bazę danych - której eksternalizacja
(backup task) umożliwia zachowanie danych systemu. Odnosząc do powyższego oraz do
oferty Kon
sorcjum wskazać należy, iż system XenData nie został zaprojektowany do formatu
DPX oraz nie posiada jednorodnej bazy danych. Dane są rozproszone i przechowywyane
w kliku warstwach, czyli w plikach XML oraz w samych plikach z materiałem znajdującym się
w strukturze katalogowej systemu. Brak zastosowania bazy danych, przechowującej
w jednym miejscu całego zestawu metadanych dyskwalifikuje produkt XenData do
zastosowania go przy archiwizacji materiałów w formacie DPX. Format ten nie składa się
z jednego pliku tylko z tylu plików, ile jest ramek (klatek) materiału. W zależności od formatu
może to być od 20 do 60 plików dla jednej sekundy. Godzinny materiał to co najmniej 90.000
plików, a sto materiałów to 9.000.000 plików. XenData podczas funkcji backup musi wykonać

pobranie informacji z kliku miejsc, między innymi z plików, a przy tak dużej ilości plików
operacja ta blokuje system.
System XenData nie został zaprojektowany do przechowywania
wymaganych pr
zez Zamawiającego plików DPX i nie może do tego służyć, ponieważ nie
sprawdza się przy formatach, gdzie materiał wideo jest rozproszony. Operatorzy systemu nie
będą więc w stanie wykonywać funkcji backup po zarchiwizowaniu kilku dziesięciu
materiałów. Brak możliwości wykonania kopii bezpieczeństwa spowoduje niezwykle dotkliwe
skutki dla Zamawiającego, tj. możliwość utraty wszystkich danych. Nadto, operator systemu
XenData wraz z powiększającą się liczbą materiałów w archiwum będzie miał problemy
z wykonywaniem kopii awaryjnych, a w przypadku awarii nie będzie miał możliwości
odtworzenia systemu.
Powyższe zostało potwierdzone przez TVP S.A. w wiadomości e-mail
z 18.11.
2019 r., która korzysta z systemu XenData. Zgodnie z ww. wiadomością System ten
znajduje zastosowanie przy archiwizacji małej ilości plików i nie nadaje się do
archiwizowania dużej ilości materiałów co ma miejsce przy formacie DPX. Wraz ze wzrostem
ilości materiałów system zaczyna mieść problem z wydajnością. Biorąc pod uwagę nasze
doświadczenie z tym produktem nie zalecamy tego rozwiązania do archiwizacji plików DPX.
Ponadto, o wadliwości systemu XenData, w takim zastosowaniu, którym posługuje
się Przystępującego i który nie spełnia wymogów Zamawiającego zawartych SIWZ świadczy
również stanowisko spółki Content Networks sp. z o.o. Zgodnie bowiem z oświadczeniem
spółki, System XenData nie posiada bazy danych zawierającej pełen zestaw metadanych.
Brak silnika bazodanowego z narzędziami bazodanowymi skutkuje niemożliwością
wykonania klasyc
znych operacji np. pełnej eksternalizacji, czyli wykonania pełnej kopi
danych do zewnętrznej lokalizacji. Brak takiej funkcjonalności uniemożliwia realizację
wykonania pełnej kopii zapasowej systemu jak również przywrócenia jej po awarii.
Powyższa argumentacja w sposób jednoznaczny wykazuje, iż oferta Przystępującego
w zakresie cz.
4 zamówienia nie spełnia warunków Zamawiającego określonych w SIWZ.
W ocenie odwołującego, niezgodność oferty Przystępującego z SIWZ następuje wobec
trzech kryteriów w zakresie:
1. braku spełnienia wymagań technicznych dla systemu specjalizowanej macierzy centralnej
z uwagi na fakt, iż zaoferowane przez Konsorcjum macierze serii QXS nie spełniają kryteriów
oznaczonych przez Zamawia
jącego, bowiem najwyższą dostępną prędkością Fibrę Channel
w kontrolerach jest prędkość 16 Gbit/s, a zatem nie obsługują opcji Fibrę Channel 32 Gbit/s,
2. nieobsługiwania przez system XenData funkcji przywracania fragmentów plików (Partial
Restore) dla pl
ików o formacie DPX według znaczników czasowych (TimeCode),
3. braku bazy danych, której eksternalizacja (backup task) umożliwia zachowanie danych
systemu z uwagi na fakt, iż system XenData nie został zaprojektowany do przechowywania
wymaganych przez Zamaw
iającego plików DPX.

Nadto, wskazał na wyrok KIO z 09.05.2019 r., sygn. akt: KIO 729/19 i wyrok KIO
z 16.052019 r., sygn. akt: KIO
775/19. Po
dkreślił, iż Odwołujący przegrał
z
Przystępującym przetarg w cz. 4 zamówienia różnicą 4,80 pkt, przy czym różnica ta
powstała jedynie wskutek zaoferowanej ceny. Jednocześnie podnieść należy, iż różnica
w cenie wynikła z uwagi na fakt, iż Odwołujący zaoferował sprzęt lepszej jakości, który
w pełni wyczerpuje kryteria określone przez Zamawiającego w SIWZ, zaś gorsze parametry
sprzętu zaproponowanego przez Przystępującego determinowały niższą wartość
zamówienia. Odwołujący przedstawił dodatkowo szereg oświadczeń podmiotów
niezależnych zajmujących się rekonstrukcją i postprodukcją obrazu oraz autoryzowanych
dystrybutorów
sprzętu
zaoferowanego
przez
Przystępującego,
posiadających
wyspecjalizowaną wiedzę w tym zakresie, którzy w sposób jednoznaczny potwierdzili, iż
oferta Przystępującego jest niezgodna z SIWZ.
Zamawiający w dniu 19.11.2019 r. wezwał (wpływ do Prezesa KIO w wersji
elektronicznej podpisane podpisem cyfrowym za pośrednictwem elektronicznej skrzynki
podawczej - ePUAP)
wraz kopią odwołania, w trybie art. 185 ust.1 Pzp, uczestników
postępowania przetargowego do wzięcia udziału w postępowaniu odwoławczym.
W dniu 20.11.2019 r.
(wpływ bezpośredni do Prezesa KIO) Konsorcjum Studiotech
Poland
zgłosił przystąpienie do postępowania odwoławczego po stronie Zamawiającego
wnosząc o oddalanie odwołania. Kopia zgłoszenia została przekazana Zamawiającemu oraz
Odwołującemu. W konsekwencji Izba uznała skuteczność przystąpienia do postępowania
odwoławczego po stronie Zamawiającego: Konsorcjum Studiotech Poland.
Do otwarcia posiedzenia Zamaw
iający wobec wniesienia odwołanie do Prezesa KIO
nie wniósł na piśmie, w trybie art. 186 ust. 1 Pzp, odpowiedzi na odwołanie.

Skład orzekający Krajowej Izby Odwoławczej po zapoznaniu się z przedstawionymi
poniżej dowodami, po wysłuchaniu oświadczeń, jak i stanowisk stron złożonych
ustnie do pro
tokołu w toku rozprawy, ustalił i zważył, co następuje.

Skład orzekający Izby ustalił, że nie została wypełniona żadna z przesłanek
skutkujących odrzuceniem odwołania na podstawie art. 189 ust. 2 Pzp, a Wykonawca
wnoszący odwołanie posiadał interes w rozumieniu art. 179 ust. 1 Pzp, uprawniający do jego
złożenia. Odwołujący, którego oferta uplasowała się na drugiej pozycji w rankingu złożonych
ofert, w wypadku potwierdzenia zarzutów ma szanse na uzyskanie zamówienia.

Przystępujący w swoim piśmie procesowym z 02.12.2019 r. stwierdził, że: „(…)
odwołanie (…) nie spełnia wymogów konstrukcyjnych, a zatem nie może odnieść skutku
pożądanego przez Odwołującego. Brak jest bowiem zarzutu dotyczącego wyboru
najkorzystniejszej
oferty oraz wskazania naruszenia przepisu postępowania, który o tej
czynności stanowi. Odwołujący zarzucił bowiem Zamawiającemu naruszenie wyłącznie
przepisu art. 7 ust. 1 i 3 p.z.p. dotyczącego ogólnych zasad postępowania oraz przepisu art.
89 ust. 1 pkt
2) p.z.p. stanowiącego o odrzuceniu oferty. W niniejszym odwołaniu, tak
w petitum, jak i w uzasadnieniu faktycznym brak jest zarzutu (obejmującego nie tylko
podstawę prawną, ale wskazującego okoliczności faktyczne) w zakresie ww. czynności
w
yboru oferty przez Zamawiającego. Jeżeli bowiem odwołujący zmierzał do
zakwestionowania w niniejszym postępowaniu czynności wyboru najkorzystniejszej oferty, to
zarzut wskazany w petitum odwołania winien uwzględniać art. 91 p.z.p. ze wskazaniem
konkretnej
jednostki redakcyjnej przepisu związanej z zastrzeżeniami składanymi przez
odwołującego. Powołanie się wyłącznie na art. 89 ust. 1 pkt 2) p.z.p. uznać należy za zarzut
skierowany wyłącznie w odniesieniu do nieodrzucenia oferty Konsorcjum. (…)”
. Izba
w okolicznościach przedmiotowej sprawy nie podzieliła wskazanych wątpliwości
Przystępującego. Odwołanie bowiem, w petitum wprost odnosi się do czynności wyboru
oferty najkorzystniejszej
Przystępującego, będącej podstawą wniesionego środka ochrony
prawnej
– wnosząc o jej unieważnienie i jest de facto odwołaniem na zaniechanie odrzucenia
oferty Przystępującego. W konsekwencji zarzuty Odwołującego konsumują w sobie także
negacje prawidłowości czynności wyboru oferty najkorzystniejszej.
Skład orzekający Izby działając zgodnie z art. 190 ust. 7 Pzp dopuścił w niniejszej
sprawie dowody z:
dokumentacji postępowania o zamówienie publiczne nadesłanej przez
Zamawiającego na płytce CD. Dotyczy to w szczególności treści SIWZ oraz odpowiedzi na
py
tania, a zwłaszcza odpowiedzi na pytanie 27 – pismo z 30.05.2019 r., oferty
Przystępującego i jego formularza cenowego w cz. 4, także I - wezwania do wyjaśnień
z 20.08.2019 r., udzielonych I -
wyjaśnień z 27.08.2019 r., załączonego do nich
oświadczenia producenta Quantum z 21.08.2019 r. /przedstawiciela producenta na Polskę/,
oświadczenie producenta XenData z 23.08.2019 r., II - wezwania do wyjaśnień z 17.09.2019
r. i udzielonych II -
wyjaśnień z 25.09.2019 r. Należy także uznać jako dowód opinie
Inżyniera Kontraktu /Fxgrail Sp. z o.o./ z 07.10.2019 r., która jednakże jak oświadczył
Zamawiający na rozprawie 02.12.2019 r. miała charakter tylko i wyłącznie doradczy, czyli nie
była wiążąca dla Komisji Przetargowej.
Podobnie, Izba zaliczyła w poczet materiału dowodowego załączone do odwołania
przez Odwołującego jako dowód:

1. specyfikacja
techniczna macierzy dyskowych linii produktów Quantum QXS 12g Storage
/DS00503A-v03 czerwiec 2019/ wraz
z tłumaczeniem uwierzytelnionym z j. angielskiego;
2.
oświadczenie AK Film Service and Solutions A. K. /bez daty/;
3.
wiadomość e-mailowa S. S. oraz T. D. /Wytwórnia Filmów Dokumentalnych i Fabularnych/
z 17 i 18.11.2019 r.;
4. oświadczenie ATM System Sp. z o.o. z 18.11.2019 r.;
5. prze
tłumaczone i uwierzytelnione z j. angielskiego wiadomości e-mailowe między spółką
Fujitsu Technology Solutions Sp. z o.o., a pracownikiem Wsparcia Oprogramowania
Quantum p. A. J. z USA
– korespondencja z 22, 23 i 26.08.2019 r.;
6.
przetłumaczone i uwierzytelnione z j. angielskiego wiadomości e-mailowe między
pracownikiem Quantum p. N. C.,
a firmą Rocket Science – korespondencja z 13, 15
i 16.08.2019 r.;
7
. przetłumaczone i uwierzytelnione z j. angielskiego wiadomości e-mailowe między
pracownikiem Wsparcia Oprogramowania Quantum p. A. J. z USA,
a firmą Bright
Technologies, Inc.
– korespondencja z 13 i 14.08.2019 r.;
8
. oświadczenie spółki Veracomp S.A. /bez daty/;
9
. oświadczenie spółki Arrow ECS Sp. z o.o. /bez daty/;
10.
oświadczenie M. J. INS Instruments z 15.11.2019 r.;
11
. oświadczenie K3 System Sp. z o.o. z 15.11.2019 r.;
12. trzy
oświadczenia spółki Content Networks Sp. z o.o. każde z 15.11.2019 r.;
13.
wiadomość e-mailowa A. K. /TVP/ z 18.11.2019 r.
Dod
atkowo elementem materiału dowodowego jest przywołany przez Zamawiającego
w odpowiedzi na odwołanie z 29.11.2019 r. fragment z dokumentacji producenta XenData
wraz z tłumaczeniem dotyczący wersji 7.02 (str. 16 –
https://xendata.com/downloads/production_releases/7.02p2/assets/XenData_Archive_Series
.pdf
).
Podobnie, Izba zaliczyła w poczet materiału dowodowego również załączone przez
Przystępującego do pisma procesowego z 02.12.2019 r. jako dowód:
1)
oświadczenia Prezesa producenta XenData z 25.11.2019 r. wraz z tłumaczeniem;
2)
oświadczenia Prezesa producenta XenData z 29.11.2019 r. wraz z tłumaczeniem;
3)
oświadczenia Prezesa producenta XenData z 01.12.2019 r. wraz z tłumaczeniem.
/dołączone również oświadczenie z 21.08.2019 r. przedstawiciela Qunatum na Polskę było
elementem I -
wyjaśnień z 27.08.2019 r. udzielonych Zamawiającemu na wezwanie przez
Przystępującego w toku postępowania przetargowego przed wyborem oferty
najkorzystniejszej w zadaniu 4/

Nadto, Izba zaliczyła w poczet materiału dowodowego załączone przez
Odwołującego do jego pisma procesowego z 04.12.2019 r. /odpowiedź na pismo
Zamawiającego z 29.11.2019 r oraz Przystępującego z 02.12.2019 r./ jako dowód:
 tłumaczenie fragmentu dokumentacji do wersji systemu XenData ze strony:
https://xendata.com/xendata-xml-interface/
;
Dodatkowo elementem materiału dowodowego jest przywołany przez Odwołującego
na str. 13 pisma procesowym z 04.12.2019 r.
/odpowiedź na pismo Zamawiającego
z 29.11.2019 r oraz Przystępującego z 02.12.2019 r./ fragment z dokumentacji producenta
XenData wraz z tłumaczeniem dotyczący wersji 7.02 – w zakresie pkt. 9.1 – dotyczy
http://xendata.com/downloads/production_releases/7.04p2/assets/XenData_Archive_Series.
pdf
.
Odnośnie opinii złożonych przez Odwołującego wraz z pismem z 04.12.2019 r.
będącym odpowiedzią na pismo Zamawiającego z 29.11.2019 r oraz Przystępującego
z 02.12.2019 r., tj.
dwóch opinii z 03.12.2019 r. P.H.U. Si-Tech R. K.; Informacji Technicznej
z 03.12.2019 r. AK Film Service and Solutions; opinii prywatnej 218/12/2019 z
04.12.2019 r., w tym opinii
biegłego sadowego, Izba przypomina za judykaturą odnośnie, że
mają one charakter opinii prywatnych, które jednakże nie mogą stanowić dowodu
w sprawie wskazując, iż na podstawie art. 278 k.p.c opinią biegłego jest
wyłącznie opinia sporządzona przez osobę wyznaczoną przez sąd (uzasadnienie wyroku SN
z 10.12.1998 r., I CKN 922/97).
Według judykatury, nie może być traktowana jako dowód
w postępowaniu opinia biegłego (w tym również biegłego sądowego) sporządzona na
polecenie strony i złożona do akt sądowych (za wyrokiem SO we Wrocławiu z 22.01.2009 r.,
sygn. akt: X Ga 22/08). W
konsekwencji stwierdzając, że niniejsze opinie prywatne stanowią
stanowisko strony, w tym
wypadku Odwołującego, stanowi ona jedynie dowód tego, że
osoba lub osoby, które ją podpisały wyraziły zawarty w niej pogląd, nie korzystają one
natomiast z domniemania zgodności z prawdą zawartych w niej twierdzeń.
Stanowisko
doktryny jasno pokazuje, że ekspertyza prywatna nie może być podstawą
wniosków sądu pozostających w opozycji do stanowiska strony przeciwnej. W orzecznictwie
SN wyrażono także stanowisko, że gdyby ekspertyzę prywatną przyjęto za podstawę
orzeczenia, stanowiłoby to istotne uchybienie procesowe, które mogłoby być nawet
podstawą skutecznego zarzutu apelacyjnego (tak SN w wyroku z 29.09.1956 r., III CR
121/56, OSN 1958, nr 1, poz. 16).

Podkreśla się również, że gdy o wyborze osoby biegłego
rozstrzyga jedna ze stron, która ze względów oczywistych nie może być bezstronna w swojej
sprawie w sensie procesowym (nemo iudex in causa sua),
to przekłada się na wątpliwości co
do bezstronności biegłego. Tym bardziej, gdy materiał badawczy określa strona, która
swobodnie udostępnia (lub nie) pełne informacje o okolicznościach faktycznych istotnych dla

opiniowania. W takiej sytuacji:
„nie można wykluczyć swoistego „dopasowywania” opinii
prywatnej do potrzeb zlecającego, „solidaryzowania się" jej autom z poglądami zlecającego,
obdarzenia go sympatią czy wreszcie motywu finansowego (skoro zlecono komuś wykonanie
za wynagrodzeniem stosownego opracowania w określonym celu, zleceniobiorca może czuć
się w obowiązku wykonać zamówienie, by cel ten został osiągnięty)”
- tak m.in. w wyroku SO
w Łodzi z 30.06.2017 r., sygn. akt: III Ca 531/17. Nadto należy stwierdzić, za wyrokiem KIO
z 25.02.201
9 r., sygn. akt: KIO 181/19, że: „w postępowaniu przed Krajową Izbą
Odwoławczą wnioski dowodowe, których celem nie jest stwierdzenie faktów,
a transponowanie do materiału dowodowego subiektywnych ocen, ocen co do prawa,
stanowiska co do wykładni czy polemik o charakterze prawnym są z zasady
niedopuszczalne
, jako nieznane procedurze postępowania przed Izbą. Omawiany ”dowód”
ma taki właśnie charakter - nie został powołany na okoliczność faktów, a stanowi nic więcej,
jak próbę transponowania do materiału dowodowego ocen, twierdzeń i subiektywnych
przekonań autora co do tego jak należy interpretować SIWZ. Powyższa zaś kwestia, tj.
interpretacji postanowień SIWZ znajduje się w kognicji Izby, a nie autora opinii prywatnej.
Z uwagi na to, wniosek dowodowy w tym zakresie należało pominąć jako niedopuszczalny,
albowiem nie zmierzający do ustalenia faktów, z których strona wywodzi skutki prawne”
.
Nadto, Izba zaliczyła w poczet materiału dowodowego załączone przez
Zamawiającego do jego pisma procesowego z 05.12.2019 r., tj. odpowiedzi na pismo
Odwo
łującego z 04.12.2019 r., jako dowód:
1) kartę katalogową macierzy Quantum QXS – 424 (dotyczy Quantum QXS – 4 Hybrid
Storage, w tym modelu QXS
– 424) z przywołanym w piśmie fragmencie (nienumerowana
karta 7 pisma procesowego z 05.12.2019 r.
) wskazującym na Multi Path Support;
2) potwierdzenie konfiguracji mechanizmu MPIO dla macierzy AccelStor wraz
z tłumaczeniem ostatniego akapitu (nienumerowana karta 9 pisma procesowego
z 05.12.2019 r.).
Podobnie, Iz
ba zaliczyła w poczet materiału dowodowego załączone przez
Przystępującego do jego pisma procesowego z 05.12.2019 r., tj. odpowiedzi na pismo
Odwołującego z 04.12.2019 r., jako dowód:
1) oświadczenie właściciela firmy Tibigen z 05.12.2019 r.;
2) oświadczenie Veracomp S.A. /bez daty/;
3) oświadczenie Quantum Corporation z 05.12.2019 r. wraz z tłumaczeniem
z j. angielskiego;
4)
kartę katalogową /techniczna /opis/ Multi Path Director Reference Guide firmy ATTO dla
karty ATTO
wraz z tłumaczeniem z j. angielskiego.

Odnośnie wniosku Odwołującego o powołanie dowodu z opinii biegłego z dziedziny
informatyki i elektroniki, ze szczeg
ólnym uwzględnieniem specjalizacji w zakresie
programowania (API) oraz technologii sieci IT, maci
erzy oraz serwerów (wniosek
doprecyzowany w piśmie procesowym z 04.12.2019 r. będącym odpowiedzią Odwołującego
na pismo Zamawiającego z 29.11.2019 r oraz Przystępującego z 02.12.2019 r.), Izba wobec
przedstawionych stanowisk, biorąc pod uwagę przedstawioną argumentacje na rozprawie
dnia 02 i 06.12.2019 r.
, jak i brak możliwości porozumienia w zakresie ewentualnego
biegłego, Izba postanowiła wniosek oddalić. Stosownie bowiem do art. 190 ust. 6 Pzp,
przeprowadzenie tego dowodu prowadziłoby do zbędnej zwłoki w postępowaniu, a ponadto
istnieje obiektywna możliwość wydania rozstrzygnięcia w przedmiotowej sprawie bez
odwoływania się do specjalisty, w oparciu o inne dowody, w tym przede wszystkim biorąc
pod uwagę dokumentację z postępowania o zamówienie publiczne. Jednocześnie Izba
wskazuje, że wzięte zostało, w szczególności pod uwagę stanowisko Zamawiającego co do
całości projektu i zagrożenie jego realizacji (przedstawione tak na rozprawie 02, jak
i 06.12.2019 r. oraz w
piśmie procesowym Zamawiającego z 05.12.2019 r.
/5 nienumerowana karta/, stanowiącym odpowiedź na pismo Odwołującego z 04.12.2019 r.).
Z kolei
każda ze stron ma prawo do wniesienia skargę do sądu i zgłoszenie wniosku
dowodowego z opinii
biegłego. W ocenie Izby, zgromadzony materiał dowodowy pozwala na
wydanie wyroku. Zwraca
także uwagę, że pewne postanowienia SIWZ wymagają
interpretacji, których co do zasady nie może dokonać biegły, a leży to w gestii Izby, co
również wpłynęło na decyzję co do oddalenia złożonego wniosku.
Dodatkowo,
Izba wskazuje, że specyfika postępowania odwoławczego każdorazowo
wymaga ustalenia, czy na podstawie innych dowodów istnieje realna możliwość wydania
orzeczenia co do poszczególnych zarzutów. Dowód z opinii biegłego to w postępowaniu
odwoławczym ostateczność – jego powoływanie jest celowe jeśli po pierwsze konieczne są
wiadomości specjalne [możliwość powołania tego środka dowodowego występuje wtedy, gdy
ustalenie lub ocena stanu faktycznego sprawy wymaga wiadom
ości specjalnych (wyrok SO
we Wrocławiu z 15.01.2010 r., sygn. akt: X Ga 380/09); podobnie KIO w wyroku z 09.04.
2013 r., sygn. akt: KIO 556/13:
„Izba podnosi, że "Celem dowodu z biegłych, w świetle art.
278 KPC, nie jest ustalenie faktów mających znaczenie w sprawie, lecz udzielenie sądowi
wyjaśnień w kwestiach wymagających wiadomości specjalnych. Biegły nie może zatem
wyręczać sądu w wyjaśnieniu rzeczywistej treści stosunków faktycznych (...). Fakty istotne
dla rozstrzygnięcia sprawy sąd ustala w oparciu o inne dowody (z dokumentów, z zeznań
świadków, przesłuchania stron)"
(M. Rybarczyk, Biegły w postępowaniu cywilnym, Opinia,
Odpowiedzialność, Wynagrodzenie, Warszawa, 2001, s. 28.) (...) do zadań biegłego należy
przedstawienie sądowi swych wiadomości specjalnych (Ibidem, s. 34)."
], po drugie brak jest
innych dowodów pozwalających na ustalenie istotnych faktów dla rozstrzygnięcia sprawy.

Powyższe nie zachodzi w okolicznościach przedmiotowej sprawy. Nie mniej ważne jest
ustalenie, czy postanowienia SIWZ, co
było już podnoszone powyżej, pozwalają
ewentualnemu biegłemu na wydanie miarodajnej opinii, tzn. czy nie są wzajemnie
sprzeczne.
W tym ostatnim zakresie Izba wskazuje na wyrok KIO z 13.09.2011 r., sygn. akt: KIO
1864/11:
„Dla oceny zgodności z SIWZ oferty niezbędne jest przede wszystkim dokonanie
wykładni spornego postanowienia SIWZ, tj. ustalenie, jaki można wywieść sposób jego
rozumienia, z zast
osowaniem reguł znaczeniowych i składniowych języka polskiego, jak
również z uwzględnieniem charakteru zamówienia. Uznanie, iż brzmienie SIWZ było na tyle
niejednoznaczne, że pozwalało na wywiedzenie wniosku, iż zapalarka wysokoenergetyczna
miała być bezwzględnie użyta w procesie zapalania palnika, jednak nie było to tożsame
z niedopuszczenie
m innych środków współuczestniczących w procesie zapalania palnika
(np. propanu w celu zwiększenia stabilności zapłonu), tj. wyłączeniem kombinowanych
systemów zapłonu i poprzestaniu wyłącznie za zapłonie elektrycznym, oznacza iż niejasne,
niejednoznaczne
czy pozwalające na różną wykładnię postanowienia SIWZ muszą być
interpr
etowane na korzyść wykonawców. (...) Przy wykładni znaczenia postanowień SIWZ
należy kierować się zwykłym znaczeniem słów, wyrażeń i zwrotów, ustalonym
z uwzględnieniem reguł znaczeniowych i składniowych języka polskiego. Tym samym,
kluczowa dla oceny, czy oferta Konsorcjum może być uznana za sprzeczną z treścią SIWZ
i podlegać odrzuceniu, jest wykładnia spornego postanowienia SIWZ, co wymaga przede
wszystkim analizy językowej, do czego nie są niezbędne wiadomości specjalne
uzasadniające konieczność posłużenia się dowodem z opinii biegłego z zakresu instalacji
palnikowych.
.

Izba na podstawie art. 190 ust. 3 Pzp
dopuściła i przeprowadziła zawnioskowany
przez Odwołującego w odwołaniu dowód z zeznań nw. świadków podczas rozprawy w dniu
02.12.2019 r.:
 p. Z. Cz., p. P. J. oraz p. M. D. - na okoliczność tego, jakie informacje i od kogo uzyskali i z
jakiego źródła w związku z produktem firmy Quantum, czyli określonych faktów. W tym
zakresie, Izba wzięła pod uwagę, że tezy i okoliczności wskazane w odwołaniu mają
charakter otwarty, co wynika
w szczególności ze sformułowania: „w szczególności na
okoliczność”
.
 p. B. W. - na okoliczność tego, jakie informacje i od kogo uzyskali i z jakiego źródła w
związku z produktem firmy XenData, czyli określonych faktów. W tym zakresie, Izba wzięła
pod uwagę, że tezy i okoliczności wskazane w odwołaniu mają charakter otwarty,
w szczególności sformułowanie „w szczególności na okoliczność”.

Izba na podstawie art. 190 ust. 3 Pzp
dopuściła i przeprowadziła zawnioskowany
przez Przystępującego na rozprawie w dniu 02.12.2019 r. dowód z zeznań świadka:
 p. M. K. – na okoliczność umocowania świadka do reprezentacji producenta Ouantmum
na Polskę oraz na okoliczność funkcjonaliści produktu producenta Quantum
zakwestionowanej przez Odwołującego.
Przy rozpoznawaniu przedmiotowej sprawy skład orzekający Izby wziął pod uwagę
także złożone pisma procesowe w sprawie, stanowiska i oświadczenia złożone ustnie do
protokołu przez strony oraz Przystępującego.
Odnosząc się do podniesionych w treści odwołania zarzutów stwierdzić należy, że
odwołanie nie zasługuje na uwzględnienie.
Odwołujący sformułował w odwołaniu następujące zarzuty:
1) art. 7 ust. 1 i 3 w zw. z art. 89 ust. 1 pkt 2 Pzp poprzez ich bezpodstawne
niezastosowanie, a w konsekwencji dokonanie wyboru najkorzystniejszej oferty w zakresie
cz. 4 zamówienia Konsorcjum Studiotech Poland oraz zaniechanie odrzucenia jego oferty,
pomimo że oferta tego Wykonawcy nie odpowiada treści następujących wymagań
Zamawiającego określonych w SIWZ:
a)
pkt 1.3. lp. 2 zał. nr 8.4 SIWZ: /System macierzy centralnej musi być zorganizowany
w postaci systemu SAN -
z klientami połączonymi poprzez FC (fibre channel) 16 Gb/s.
System ma umożliwiać zapis i odczyt to czasie rzeczywistym plików graficznych
o rozdzielnościach 2K, 4K. Wymagane jest wsparcie systemu dla formatów plików SD, HD,
2K, 4K (RGB 10,12,16 bitów), strumień w czasie rzeczywistym. Formaty danych DPX,
Cineon, TIFF, MXF, Quick Time i inne używane formaty plików wideo/
,
b)
pkt 1.3. lp. 2 zał. nr 8.4 SIWZ: /Zarówno macierz „online" jak i „nearline" musi mieć
możliwość wspierania następujące interfejsów hosta (np. poprzez wymianę kontrolera): Fibrę
Channel (32 Gbit/s, 16 Gbit/s, 8 Gbit/s)/
,
c)
pkt 1.4 lp. 3 zał. nr 8.4 SIWZ: /Zamawiający wymaga możliwości przywracania fragmentów
plików (Partial Restore) po Time Code/
,
d)
pkt 1.4 lp. 3 zał. nr 8.4 SIWZ: /W związku z pracą na plikach DPX zamawiający wymaga,
aby system zarządzania pracował z maksymalną liczbą plików w wysokości minimum 2x10
9
.
System musi posiadać bazę danych - której eksternalizacja (backup task) umożliwia
zachowanie danych systemu/
.
Izba dokonała następujących ustaleń odnośnie do przedmiotowego odwołania:
W pierwszej kolejności Izba przywołuje stan faktyczny wynikający z treści pism
przedłożonych przez strony oraz Przystępującego.

Zgodnie z zał. nr 8.4 SIWZ dla cz. 4 Zamawiający określił w pkt 1.3 Serwer
produkcyjny do tymczasowego przechowywania i udostępniania kopii cyfrowych filmów
w trakcie prac digitalizacyjnych i rekonstrukcyjnych
– 1 szt.; lp. 2:

„System macierzy centralnej musi być zorganizowany w postaci systemu SAN -
z klientami połączonymi poprzez FC (fibre channel) 16 Gb/s. System ma umożliwiać zapis
i odczyt to czasie rzeczywistym
plików graficznych o rozdzielnościach 2K, 4K. Wymagane
jest wsparcie systemu dla formatów plików SD, HD, 2K, 4K (RGB 10,12,16 bitów), strumień
w czasie rzeczywistym. Formaty danych DPX, Cineon, TIFF, MXF, Quick Time i inne
używane formaty plików wideo”(…)
„Zarówno macierz „online" jak i „nearline" musi mieć możliwość wspierania
następujące interfejsów hosta (np. poprzez wymianę kontrolera): Fibrę Channel (32 Gbit/s,
16 Gbit/s, 8 Gbit/s)”
.
Zgodnie z zał. nr 8.4 SIWZ dla cz. 4 Zamawiający określił w pkt 1.4 Biblioteka
taśmowej LTO do archiwizacji głębokiej materiałów wynikowych procesów digitalizacji
i rekonstrukcji cyfrowej filmów; lp. 3: „Zamawiający wymaga możliwości przywracania
fragmentów plików (Partial Restore) po Time Code”(…)
„W związku z pracą na plikach DPX zamawiający wymaga, aby system zarządzania
pracował z maksymalną liczbą plików w wysokości minimum 2x10
9
. System musi posiadać
bazę danych - której eksternalizacja (backup task) umożliwia zachowanie danych systemu”
.
Jednocześnie, Zamawiający podał także w zał. nr 8.4 SIWZ dla cz. 4 w pkt 1.4:
„Wykonanie infrastruktury IT – serwerownia” – 1 szt.; Wymagania techniczne dla switcha FC:
„Zamawiający wymaga dostarczenia w ramach zamówienia przełącznika FC (fibre
channel) o następujących parametrach:

przełącznik fibre channel 48 portowy, w tym minimum 24 porty aktywne wraz modułami
FC SFP+ 16Gbit o parametrach (zasięg pracy) umożliwiającymi poprawną pracę switcha
z urządzeniami (hostami) zainstalowanymi w obszarze post produkcji i rekonstrukcji”
.
Nadto, konieczne jest wskazanie
na odpowiedź na pytanie 27 – pismo z 30.05.
2019 r.:
„Pytanie nr 27
W cz. 4 OPZ pkt. 1.2 oraz 1.3 Zamawiający wymaga struktury i macierzy opartej
o sieć FibreChannel 16Gb, która jest przestarzała (FC16Gb ma już ponad 8 lat, podczas gdy
nowszy FC 32Gb ma 3 lata, a w tym roku ma zostać wprowadzony format FC 64Gb)? Jest to
wymaganie tym bardziej kuriozalne gdyż wymagany dalej serwer produkcyjny ma wspierać
odtwar
zanie plików 4K RGB 16bit w czasie rzeczywistym, co może nie być możliwe za
pomocą jednego połączenia 16Gb. Istnieje natomiast wiele rozwiązań opartych o technologię
nowocześniejszą tj. s FC 32Gb lub 10Gb/40Gb ethernet, które są w stanie to osiągnąć.


Dlacz
ego Zamawiający DZIAŁA NA WŁASNĄ SZKODĘ i uniemożliwia zaoferowanie jemu
nowocześniejszych urządzeń (art. 29 ust. 3 PZP)?? Czy zatem Zamawiający może
zrezygnować z tego sztucznie ograniczającego konkurencję wymogu i zmienić go w sposób,
jak wnioskujemy na
sieć Fibrę Channel 32 GB (art. 29 ust. 1 i 2 PZP)?
Odpowiedź na pytanie nr 27
Zamawiający w trosce o całość projektu - budżet w powiązaniu z brzegowymi
warunkami technicznymi w przypadku sieci Fibrę Channel podał minimalne wymagania
funkcjonalne tj. sieć o szybkości 16Gbit, które spełnia wymagania zamawiającego opisywane
w treści SIWZ. Zamawiający opisując ten punkt brał pod uwagę całość planowanego trybu
pracy systemu oraz przepływu materiałów w obrębie planowanej pracy rekonstrukcyjno-
postprodukcyjnej. Za
mawiający dopuszcza zastosowanie przełącznika FC na wyższych
prędkościach niż minimalne wymagania określone w opisie przedmiotu zamówienia tj. FC
16Gbit. (…)”
.
Przystępujący w ramach formularza cenowego – część 4 dołączonego do formularza
ofertowego zaofer
ował:
L.p. 2.1 /przedmiot zamówienia/ - Macierz centralna (w ramach L.p. 2. Serwera
produkcyjnego
do tymczasowego przechowywania i udostępniania kopii cyfrowej filmów
w trakcie prac digitalizacyjnych i rekonstrukcyjnych
– 1 kpl); /Pełna nazwa oferowanych
urządzeń w tym numery katalogowe/: „1 x Xcellis Workflow Extender Gen2 NIC Kit,
25GbE/10GbE, Dual-Port - BXCBH-ANGQ-210A; 4 x Xcellis Workflow Extender Gen2 Fibre
Channel Kit, 16Gb, Quad-Port - BXCBH-FFGA-416A; 2 xXcellis Workflow Extender Gen2
kabel 25GbE/10GbE - BXCBH-ACBB-210C; 1 x Xcellis Workflow Director Gen2 12G,
QXS-312 12G, Fibre Channel, 48TB raw (12x4TB), HDD, non-SED, dual node - BXCBJ-
CWAF-001C; 1 x Xcellis Workflow Director Gen1/Gen2, NAS Licencja, dual node - BXCBB-
ALNA-001A; 2 x StorNext SAN lient licencja dla Windows lub Linux - WSNSE-UFYZ-001A;
1 x QXS-424 12G RAID Node, Fibre Channel SFPs, 92.16TB (24x3.84TB), SSD, non-SED -
GTB4F-CSFG-F00C; 1 x QXS-x24 12G Expansion Node, 92.16TB (24x3.84TB), SSD, non-
SED - GTEXF-CSFG-000C; 1 x QXS-312 12G RAID Node, Fibre Channel SFPs, 96TB
(12x8TB), HDD, non-SED - GTB3C-CHCN-F00C;3 x QXS-x12 12G Expansion Node, 96TB
(12x8TB), HDD, non-SED - GTEXC-CHCN-
000C”
; /Nazwa producenta/ - QUANTUM; /ilość/ -
1 szt.
L.p.
3.2 /przedmiot zamówienia/ -

System zarządzania biblioteką taśmową (w ramach
Biblioteki taśmowej LTO do archiwizacji głębokiej materiałów wynikowych procesów
digitalizacji i rekonstrukcji cyfrowej filmów – 1 kpl); /Pełna nazwa oferowanych urządzeń
w tym numery katalogowe/:
HSM System zarządzania biblioteką taśmową XAS-S-G-LM;
XAS-UPG-G/N; 215003 - API; Serwer do systemu HSM - HPE ProLiant DL380 Gen10


8SFF”; /Nazwa producenta/ - XENDATA, HEWLETT PACKARD ENTERPRISE; /ilość/ - 1
szt.
L.p.
4.1 /przedmiot zamówienia/ - System zarządzania (w ramach Stanowiska
zarządzania i administracji procesami archiwizacji kopii cyfrowych filmów – 1 kpl); /Pełna
nazwa oferowanych urządzeń w tym numery katalogowe/: „System zarządzania
i administracji procesami archiwizacji kopii cyfrowych filmów - TIBIGEN TRANSFER”
;
/Nazwa producenta/ -TIBIGEN;
/ilość/ - 1 szt.
L.p. 4.2
/przedmiot zamówienia/ - serwer systemu (w ramach Stanowiska
zarządzania i administracji procesami archiwizacji kopii cyfrowych filmów – 1 kpl); /Pełna
nazwa oferowanych urządzeń w tym numery katalogowe/: „Serwer do systemu TIBIGEN -
HPE ProLiant DL380 Gen10 8SFF”
; /Nazwa producenta/ - HEWLETT PACKARD
ENTERPRISE; /ilość/ - 1 szt.
Dodatkowo, Izba
przytacza treść I - wezwania do wyjaśnień z 20.08.2019 r. zgodnie
z którym: „(…) Zgodnie z Załącznikiem nr 8.4 - Opis przedmiotu zamówienia do SIWZ (OPZ):
1. Pkt 1.3 Serwer produkcyjny do tymczasowego przechowywania i udostępniania kopii
cyfrowych fi
lmów w trakcie prac digitalizacyjnych, Zamawiający wymagał:
Pozycja 2 - wymagania techniczne dla systemu specjalizowanej macierzy centralnej:
Zarówno macierz „Online" jak i „nearline" musi mieć możliwość wspierania
następujących interfejsów hosta (np. poprzez wymianę kontrolera):
-
Fibrę Channel (32Gbit/s, 16Gbit/s, 8Gbit/s)

Z informacji znajdujących się na stronie producenta zaoferowanych macierzy QXS-424 12G
i QXS-
312 12G firmy Quantum, nie wynika, że zaoferowane macierze „oniine" i „nearline"
wspierają interfejsy Fiber Channel 32Gbit/s. W związku z powyższym Zamawiający wzywa
do wyjaśnienia, czy zaoferowane macierze zarówna „oniine" jak i „nearline" wspierają
interfejsy Fiber Channel 32Gbit/s.
2. Pkt 1.4 Biblioteka taśmowa LTO do archiwizacji głębokiej materiałów wynikowych
procesów digitalizacji i rekonstrukcji cyfrowej filmów, Zamawiający wymagał:
Pozycja 3 -
wymagania techniczne dla systemu do zarządzania biblioteką taśmową,
m.in.: -
W związku z pracą na plikach DPX zamawiający wymaga, aby system
zarządzania pracował z maksymalną liczbą plików w wysokości minimum 2 x 10
9

,
-
System musi zapewniać dostęp do plików poprzez protokół NFS (NetWork File System),
CIFS (Common Internet File System) oraz FTP

-
Zamawiający wymaga możliwości przywracania fragmentów plików (Partial Restore) po
TimeCode.
Z informacji znajdujących się na stronie producenta zaoferowanego systemu
zarządzania biblioteką taśmową HSM firmy XENDATA, wynika, że zaoferowany system nie
obsługuje plików w formacie DPX, nie obsługuje protokołu NFS oraz nie posiada możliwości


przywracania fragmentów plików (Partial Restore) po TimeCode. W związku z powyższym
Zamawiający wzywa do wyjaśnienia, czy zaoferowany system do zarządzania biblioteką
taśmową spełnia trzy ww. wymagania, tj. obsługuje pliki DPX, na których pracuje
Zamawiający, zapewnia dostęp do plików poprzez protokół NFS i ma możliwość
przywracania fragmentów plików (Partial Restore) po TimeCode. (…)”
.
Nadto, Izba przytacza
treść I - wyjaśnień z 27.09.2019 r. udzielonych przez
Przystępującego na w/w wezwanie: „1) Wykonawca Studiotech Poland Sp. z o.o. oświadcza,
że zaoferowane macierze Quantum spełniają wymagania OPZ, zarówno macierz „online" jak
i „nearline" wspierają interfejsy hosta Fiber Channel 32Gbit/s. W załączeniu przedstawiamy,
oświadczenie producenta zaoferowanych macierzy Quantum.
2) Wykonawca oświadcza, że zaoferowany system XenData, spełnia wymagania OPZ,
a w szczególności obsługuje pliki DPX, zapewnia dostęp do plików po przez protokół NFS,
i
ma możliwość przywracania fragmentów plików (Partial Restore) po TimeCode.
W załączeniu przedstawiamy oświadczenie producenta XenData.”
.
Załączono do tych wyjaśnień oświadczenie producenta Quantum z 21.08.2019 r.: „W
imieniu firmy Quantum, 8, rue des Graviers, 92200 Neuilly-sur-Seine, Francja, producenta
bibliotek taśmowych serii Scalar i urządzeń dyskowych serii DXi i QXS oraz systemów
archiwizacji opartych na systemie plików StorNext wyjaśniam, że zaoferowane macierz
zarówno „online" jak i „nearline" wspierają interfejsy hosta Fibre Chanel: 32Gbit/s, 16Gbit/s
oraz 8Gbit/s.”

Dołączono również do tych wyjaśnień oświadczenie producenta XenData
z 23.08.2019 r.
wraz z tłumaczeniem: „Funkcjonalność oprogramowania XenData Archive
Series (…) potwierdzam, w imieniu XenData Inc .:


Obsługa Protokołów Sieciowych
Oprogramowanie XenData Archive Series, wersja 7, obsługuje protokoły sieciowe NFS, SMB
i FTP.


Maksymalna Liczba Plików i Obsługiwane Typy Plików
Oprogram
owanie XenData Archive Series zarządza systemem plików, który może zawierać
do 2x 10E9 plików, tj. do 2 000 000 plików. Akceptuje wszystkie typy plików, w tym pliki DPX.


Partial File Restore (Częściowe Przywracanie Plików)
Oprogramowanie XenData Archive Se
ries obsługuje częściowe przywracanie plików na
podstawie kodu czasowego.”.

Istotna jest również treść II - wezwania do wyjaśnień z 17.09.2019 r. zgodnie
z którym: „1.Tabela 2:1.3 Serwer produkcyjny do tymczasowego przechowywania
i udostępniania kopii cyfrowych filmów w trakcie prac digitalizacyjnych i rekonstrukcyjnych:


Wymóg Zamawiającego: „Zarówno macierz „Online" jaki i „nearline" musi mieć możliwość
wspierania następujące interfejsów hosta (np. poprzez wymianę kontrolera ): Fibrę Channel
(32Gbit/s, 16Gbit/s, 8Gbit/s)"
Na stronach www producenta oferowanej przez Wykonawcę macierzy „online" i „nearline
o nazwie QXS-424 12G i QXS-312 12G firmy Quantum:
-

https://iq.quantum.com/exLink.asp?39941248OJ78X37l158747467&DS00503A&view=1

-

https://www.quantum.com/en/products/high-performance-shared-storage/qxs- series /

https://www.quantum.com/serviceandsupport/softwareanddocumentationdownl
oads/qxshybriddisk/index.aspx?wh
attab=Third,

sekcja „Spedfications"

obsługiwane wspierane interfejsy FC to:
- Interface Options 8/16G FC lub
-
Controller Ports 16Gb, 8Gb Fibrę Channel.
W związku z powyższym brak jest wsparcia dla wymaganego interfejsu FC
o
prędkości 32Gbit/s. Ponadto na stronie www producenta macierzy

http://qsupport.quantum.com/kb/Flare/Content/QXS/PDFs/QXSG2HWInstallMaintGuide.pdf#page=88
,
gdzie
znajduje się dokument o nazwie QXS G2 Hardware Installation and Maintenance
Guide, 6-68649-
01 Rev A, May 2019, pokazujący jak instalować i zarządzać ww.
macierzami. W instrukcji nie ma informacji o wsparciu dla FC o prędkości 32Gbit/s, np.
poprzez wymianę kontrolera, co wskazuje również, że brak jest wsparcia dla wymaganego
interfejsu FC o prędkości 32Gbit/s.
Wsparcie dla interfejsu FC o prędkości tylko 8 i 16 Gbit/s w macierzach QXS-424
12G i QXS-
312 12G firmy Quantum potwierdzili również polscy dystrybutorzy i integratorzy
producenta oferowanej przez Państwa macierzy. Wskazali, że brak jest wsparcia w tych
macierzach dla interfejsu FC o prędkości 32Bbit/s. Zamawiający dysponuje również
korespondencją z supportem firmy Quantum, który nie potwierdza wsparcia w oferowanych
przez Państwa macierzach dla interfejsu FC o prędkości tylko 32Bbit/s. (…)
2. Tabela 3:1.
4 Biblioteka taśmowa LTO do archiwizacji głębokiej materiałów wynikowych
procesów digitalizacji i rekonstrukcji cyfrowej filmów:
1)
wymóg Zamawiającego: „System musi zapewniać dostęp do plików poprzez protokół NFS
(Network File System), CIFS (
Common Internet File System) oraz FTP”.
Na stronach www producenta oferowanego przez Wykonawcę systemu zarządzania
biblioteką taśmową HSM firmy XENDATA, w skład które wchodzi m.in. oprogramowanie
XenData6 Server Software i XenData Archiye Series Software, którego dokumentacja jest
dostępna pod adresami:
-

https://xendata.com/support-xendata6- server/assets/XenData6 Server Software User Manual.pdf

-
http://xendata.com/Assets_Products/XenData_Archiye_Series_Software_User_Manual.pdf

obsługiwane protokoły to:


- Standard NetWork Protocols The solution supports CIFS/SMB and FTP file transfers lub
- Supported NetWork: Protocols: You can use CIFS/SMB, FTP or local file transfers.
W związku z powyższym brak jest wsparcia dla wymaganego protokołu NFS. (…)
2)
Wymóg Zamawiającego: „Zamawiający wymaga możliwości przywracania fragmentów
plików (Partial Restore) po TimeCode".
W skład ofertowego systemu zarządzania biblioteką taśmową HSM firmy XENPATA wchodzi
m.in. oprogramowanie XenPata Workflow A
PI, którego dokumentacja znajduje się dostępna
pod adresem

https://xendata.com/xendata-xml-interface/
.
Z informacji na końcu powyższej strony wynika, że: „The Workflow API may be extended by
adding a plugin from Marquis Broadcast to support Partial File Restore (PFR) based on
timecode. This supports MXF and QuickTime files for a wide rangę of Codecs.", tłumacząc
na język polski: „Interfejs API przepływu pracy można rozszerzyć, dodając wtyczkę Marquis
Broadcast do obsługi częściowego przywracania plików (PFR) na podstawie kodu
czasowego. Obsługuje pliki MXF i QuickTime dla szerokiej gamy kodeków.".
W ofercie Wykonawca wskazał produkt o numerze 215003 - API, firmy XenData, co
wskazuje, że Wykonawca zaoferował tylko interfejs API: XenData Workflow API.
Z powyższego wynika, że Wykonawca nie oferuje wtyczki Marquis Broadcast firmy Marquis
Broadcast Limited, zaoferował system zarządzania biblioteką taśmową HSM firmy
XENDATA, który nie ma możliwości przywracania fragmentów plików (Partial Restore) po
TimeCode". (…)
3)
Wymóg Zamawiającego: „W związku z praca na plikach DPX Zamawiający wymaga, aby
system zarządzania pracował z maksymalna liczba plików w wysokości minimum 2 x 10
9

Z informacji uzyskanych od producenta oprogramowania, firmy Marquis Broadcast, ich
„wtyczka", wymagana do obsługi mechanizmu PFR (wskazanego w pkt 2) powyżej) nie
obsługuje podstawowego formatu plików DPX.
Poniżej przedstawiony dokument firmy Marquis Broadcast „PFR Supported Codecs Jan
2017" z opisem obsługiwanych formatów, nie wskazuje możliwości obsługi plików
sekwencyjnych DPX, a nawet nie wskazuje żadnego formatu przystosowanego do post
produkcji 2k/4k wymaganej w całym projekcie.
4)
Wymóg Zamawiającego: „System musi posiadać bazę danych - której eksternalizacja
(backup task) umożliwia zachowanie danych systemu/'
Stwierdzenie 'backup task' z powyższego wymagania narzuca konieczność dostarczenia
w ramach systemu narzędzia bazodanowego służącego do tworzenia i zarządzania kopią
bezpieczeństwa w sposób ręczny i automatyczny z dostępem symultanicznym. Oferowany
przez Wykonawcę system zarządzania biblioteką taśmową HSM firmy XenData posiada
dane zagregowane w postaci pliku/plików XML, do których nie ma dedykowanych narzędzi
umożliwiających tworzenie zadań (typu task) w ramach wykonywania kopii bezpieczeństwa


i jej przywracania. Jednocześnie funkcja 'backup task' zgodnie z wymaganiami
Zamawiającego musi być elementem systemu bazy danych. Na stronie producenta nie ma
informacji dotyczącej zastosowanej w zaoferowanym produkcie bazy danych oraz sposobu
tworzenia/odtwarzania kopii bezpieczeństwa bazy danych i dostępu dla kilku
użytkowników/lokacji jednocześnie. (…)”.

Podobnie treść udzielonych II - wyjaśnień z 25.09.2019 r. udzielonych przez
Przystępującego na w/w wezwanie: „Dotyczy pytania 1.
Zgodnie z zapisami OPZ Zamawiający wymaga macierzy która: „Zarówno macierz
„online” jaki i „nearline” musi mieć możliwość wspierania następujące interfejsów hosta (np.
poprz
ez wymianę kontrolera):
• Fibre Channel (32Gbit/s, 16Gbit/s, 8Gbit/s)”
A co za tym idzie
Zamawiający nie wymagał dostarczenia macierzy z interfejsami 32Gbit/s
o czym świadczą również wymagania na przełączniki FC („przełącznik fibre channel 48
portowy, w tym minimum 24 porty aktywne wraz modułami FC SFP+ 16Gbit
o parametrach (zasięg pracy) umożliwiającymi poprawną pracę switcha z urządzeniami
(hostami) zainstalowanymi w obszarze post produkcji i rekonstrukcji”).
Z
godnie z dostarczonym oświadczeniem przedstawiciela producenta macierzy oraz
naszym udzielonym wcześniej wyjaśniamy, że zaoferowane macierze wspierają interface
hosta 32Gbit/s
. Host z takim interface podłączony do macierzy będzie mógł odczytywać
i zapisywać dane z prędkością interface macierzy. Rozbieżność informacji jaka wynika
z serwisu producenta, może wynikać ze sposobu tłumaczenia wymagań OPZ. Zwracamy
uwagę, że nasze oświadczenie zostało przesłane w języku polskim przez polski oddział
producenta, który miał wgląd do oryginalnych zapisów OPZ.
Dotyczy pytania 2.1.
Zgodnie z wcześniejszym oświadczeniem producenta oraz naszym, potwierdzamy, że
zaoferowany system XenData posiada wsparcie dla protokołu NFS.
Jednocześnie zwracamy uwagę, że przesłane przez Państwa linki do dokumentacji dotyczą
się oprogramowania XenData w wersji 6, która nie jest najnowszą wersją systemu.
Z tego powodu w przesłanej dokumentacji mogą pojawić się różnice w stosunku do
Zaoferowanego przez nas systemu.
Dotyczy pytania 2.2.
Zgodnie z wcześniejszym oświadczeniem producenta oraz naszym, potwierdzamy że
zaoferowany system w punkcie XenData Workflow API posiada wsparcie dla przywracania
fragmentów plików (Partial Restore) po time code.
zgod
nie z najnowszą wersja systemu XenData


Zwracamy uwagę, że przytoczony przez Państwa link zawiera odnośnik do szczegółów
„Workflow API programmers descreption”, który to ostatni raz był aktualizowany w listopadzie
2015r. jak i ta strona.
Zwracamy uwagę również, iż producent w różnych wersjach oprogramowania może
stosować różne modele licencjonowania w tzw. bundlle, które nie są wyspecyfikowane
w sposób szczegółowy lecz funkcjonalny.
Dlatego też, zaoferowany XenData Warkfow API zawiera już w sobie komplet modułów do
wykonania funkcjonalności dla przywracania fragmentów plików (Partial Restore) po time
code.
Dotyczy pytania 2.3.
Zaoferowany przez nas system, współpracuje z plikami DPX, o minimalnej liczbie
2x10
9.
Zwracamy uwagę, że przytoczone oprogramowanie Marquis Broadcast, służy do
obsługi mechanizmu PFR (partial file restore) z plików wideo. Sekwencja DPX jest listą
pojedynczych plików, gdzie każdy plik stanowi jedną ramkę materiału. W związku z tym, nie
jest konieczne używanie oprogramowania Marquis Broadcast do pozyskiwania z archiwum
fragmentu sekwencji plików DPX, a jest to możliwe za pośrednictwem zaoferowanego
modułu XenData Workflow API.

Dotyczy pytania. 2.4.
Oświadczamy iż zaoferowany system XenData spełnia wymagania OPZ; „system
musi posiadać bazę danych - której eksternalizacja (backup task) umożliwia zachowanie
danych systemu"
System XenData
posiada własną bazę danych, w której backup, możemy wykonać za
pośrednictwem dedykowanych mechanizmów systemu XenData.
Dodatkowo dla zewnętrznych aplikacji możliwy jest dostęp za pomocą SQL Interface, dzięki
czemu możliwe jest zadawanie pytań do wewnętrznej bazy danych systemu XenData
w postaci zapytań SQL. Przykładowy opis mechanizmu zawarty jest na stronie producenta
pod adresem:

https://xendata.com/xendata-comsql-interface/

(…)”.
Dodatkowo, Izba
wskazuje na treść załączonego przez Przystępującego do pisma
procesowego z 02.12.2019 r. jako dowód:
1)
oświadczenia Prezesa producenta XenData z 25.11.2019 r.: „(…) potwierdzam w imieniu
XenData Inc. (…)
- XenData Baza Danych i Backup
Aplikacja XenData Archive Series używa wewnętrznej bazy danych. Ta baza danych
zapewnia znacznie lepszą wydajność w porównaniu do konwencjonalnych baz danych,
szczególnie w przypadku mniejszych plików takich jak DPX. Aplikacja XenData zawiera
narzędzie Database Backup, które umożliwia automatyczny i manualny backup. (…)”
;

2)
oświadczenia Prezesa producenta XenData z 29.11.2019 r.: „(…) potwierdzam, w imieniu
XenData lnc.:
-
Obsługa Protokołów Sieciowych

Oprogramowanie XenData Archive Series, wersja 7, obsługuje protokoły sieciowe NFS,
SMB i FTP.
-
Maksymalna Liczba Plików i Obsługiwane Typy Plików

Oprogramowanie XenData Series zarządza systemem plików, który może zawierać do
2x10
Ʌ

9 plików, tj. do 2 000 000 000 plików. Akceptuje wszystkie typy plików, w tym pliki DPX
-
Partial File Restore (Częściowe Przywracanie Pliku)

Oprogramowanie XenData Series obsługuje częściowe przywracanie pliku na podstawie
kodu czasowego (…)”
.
Nadto, Izba powołuje się na treść załączonych przez Przystępującego do jego pisma
procesowego z 05.12.2019 r., tj. odpowiedzi na pismo Odwołującego z 04.12.2019 r., jako
dowód:
1)
oświadczenia właściciela firmy Tibigen z 05.12.2019 r.: „(…) oświadczamy, że aplikacja
Tibigen Transfer współpracuje j za pośrednictwem API z systemem Xendata. Dzięki temu
mechanizmowi możliwe jest by użytkownik wykonywał między innymi takie operacje jak:
archiwizacja, odtwarzanie oraz częściowe odtwarzanie na podstawie kodów | czasowych
(ang.: Partial Restore) zarówno z sekwencji DPX jak i z materiałów wideo. (…)”
;
2)
oświadczenia Veracomp S.A. /bez daty/: „Doprecyzowując informacją dot. macierzy serii
QXS firmy Quantum, przekazaną w formie oświadczenia firmie JBD SA, niniejszym
oświadczam dodatkowo, że w tym momencie macierze serii QXS firmy Quantum posiadają
interfejsy 8/16Gbps SFP+ oraz że interfejsy macierzy 16Gbps SFP+ obsłużą interfejsy hosta
8/16/32 Gbps i są z nimi kompatybilne. W przypadku agregacji portów FC możliwa jest
obsługa interfejsów hosta z prędkością 32 Gbps”
;
3)
oświadczenia Quantum Corporation z 05.12.2019 r.: „(…) Quantum z przyjemnością
udziela wyjaśnień w sprawie naszej oferty na pamięci Quantum QXS 12G i potwierdzamy
następujące informacje:
-
Seria QXS ma połączenia SFP + 16 Gbps, które mogą automatycznie wykrywać i pracować
z portami Fibrę Channel 4 Gb, 8 Gb lub 16 Gb
-
W połączeniu z przełącznikiem Fibrę Channel 32 Gb, 16 Gb SFP + w QXS są kompatybilne
z hostami 8/16/32 Gbps
-
Ubywanie wielu portów FC QXS serii 16 Gbps równolegle pozwala na osiągnięcie
wydajność hosta większej niż pojedyncze połączenie 32 Gbps (…)”
.
Odnosząc się do poszczególnych kwestii w ramach rozpatrywanych zarzutów.

Biorąc pod uwagę ustalenia i stan rzeczy ustalony w toku postępowania (art. 191
ust.1 Pzp),
Izba stwierdziła co następuje.
Odnośnie zarzutów odwołania, Izba uznała że podlegają one oddaleniu. Sprowadzają
się one do negowania przez Odwołującego spełniania przez ofertę Przystępującego dla cz. 4
przywołanych w ustaleniach faktycznych trzech funkcjonalności. W ocenie Izby, stanowisko
Odwołującego w tym zakresie jest błędne, a dokonane ustalenia przez Izbę nie potwierdzają
sformułowanych przez Odwołującego zarzutów w tym zakresie.
Odnośnie pierwszej funkcjonalności:
W pierwszej kolejności Izba wskazuje, że zgodnie z wymogiem Zamawiający
oczekiwał macierzy „online”, jak i „nearline” mającej mieć możliwość wspierania interfejsów
hosta (np. poprzez wymianę kontrolera): Fibre Channel (32 Gbit/s, 16 Gbit/s, 8 Gbit/s).
Wynika więc z tego, że niewątpliwie Zamawiający nie wymagał od razu dostarczenia
macierzy z interfejsami 32 Gbit/s, ale macierzy, które mimo, że bezpośrednio nie obsługują
prędkości 32 Gbit/s muszą wspierać interfacy hosta 32 Gbit/s, czyli zewnętrzne urządzenia.
Inaczej mówiąc należało zaoferować macierz, która na przyszłość (rozwojowo),
w ramach ewentualnej przyszłej rozbudowy (modernizacji) ma wspierać interfacy hosta 32
Gbit/s. W sposób definitywny rozstrzyga o powyższym odpowiedź na pytanie 27 (pismo
z 30.05.2019 r.), gdzie
jednoznacznie stwierdzono odnosząc się do pytania dotyczącego
wymogu
Zamawiającego dotyczącego struktury i macierzy opartej o sieć Fibre Channel 16
Gbit/s
, zwracającego uwagę na to, że odtworzenie plików 4 K w czasie rzeczywistym może
nie być możliwe za pomocą jednego połączenia 16 Gbit, wnioskującego w ostatnim zdaniu
pytania
o zmianę na sieć Fibre Channel 32 Gbit/s, że: „Zamawiający w trosce o całość
projektu
– budżetu (…) podał minimalne wymagania funkcjonalne, tj. sieć o szybkości 16
Gbit/s, która spełnia wymagania zamawiającego opisywane w treści SIWZ. (…) dopuszcza
zastosowanie przełącznika FC na wyższych prędkościach niż minimalne wymagania
określone w opisie przedmiotu zamówienia, tj. FC 16 Gbit/s”
. Wynika więc z tego
jednoznacznie, że odpowiedź dotyczy nie tylko prędkości przełączników, ale także
wymaganej prędkości macierzy, którą ma wspierać, gdyż Zamawiający określił minimalne
wymagania funkcjonalne
w oparciu o prędkość 16 Gbit/s.
Jednocześnie, w zakresie znaczenia udzielonych wyjaśnień dla obowiązków
W
ykonawców Izba utożsamia się że stanowiskiem KIO wyrażonym w wyroku KIO
z 16.07.2019 r., sygn. akt: KIO 1193/19:
„Wyjaśnienia treści specyfikacji istotnych warunków
zamówienia udzielane w trybie art. 38 p.z.p. mają takie samo znaczenie prawne tak
pierwotna treść specyfikacji istotnych warunków zamówienia i stanowią jej równorzędną
cześć; de facto często też stanowią modyfikację postanowień specyfikacji istotnych


warunków zamówienia (już choćby poprzez ich doprecyzowanie), nawet jeśli zamawiający
formalnie nie powo
ła się na art: 38 ust. 4 p.z.p.”
. Z kolei w wyroku KIO z 28.01.2015 r., KIO
110/15,
stwierdzono, że nie jest przeszkodą dla uznania, że mamy do czynienia
z pełnowartościową i skuteczną zmianą SIWZ to, że Zamawiający wyraźnie nie podał, że
dokonuje zmiany SIWZ, choć w istocie tego dokonał. Istotną jest bowiem rzeczywista treść
samej czynności, jej charakter, które wskazują na dokonanie zmiany SIWZ, a nie tylko
w sytuacji kiedy Zamawiający udzielone wyjaśnienia tytułuje, jako „zmiana SIWZ”. W tym
zakresie istotne znaczenie ma po pierwsze analiza treści dokumentów tj. kwestionowanych
postanowień SIWZ i udzielonych przez zamawiającego treści odpowiedzi na pytania
wykonawców. W tej materii wskazać należy także na wyrok SN z 18.02.2016 r. (sygn. akt: II
CSK 197/15), w którym SN stwierdził, że udzielone wyjaśnienia przez Zamawiającego ze
s
wej istoty są bezwzględnie wiążące dla wykonawców i mogą zmienić SIWZ, a ponadto nie
mogą one stanowić podstawy do ponoszenia negatywnych konsekwencji zarówno przez
zamawiającego jak i wykonawcę. Jednakże w dalszej części uzasadnienia SN opierając się
na d
otychczasowym orzecznictwie uznał, że ustawa Pzp nie przewiduje procedury
uzupełniania wyjaśnień ani odwołania od ich treści, gdyż celem wyjaśnień jest uzyskanie
przez wykonawców wiedzy niezbędnej dla podjęcia decyzji o ubieganiu się o udzielenie
zamówienia publicznego i sporządzenia oferty.
Wracając zaś, do meritum, spór więc de facto sprowadza się do tego, czy
zaoferowana macierz przez Przystępującego w pkt 2.1 formularza cenowego QXS-424 12 G
Qunatum Storage posiadająca porty 16 Gbit/s – wspiera interfacy hosta 32 Gbit/s. Nadto, czy
jeśli odpowiedź na to pytanie jest pozytywna, tzn. że sposób zaproponowany przez
Przystępującego jest pod względem technicznym dopuszczalny, wiarygodny i możliwy do
zastosowania, to czy był on dopuszczalny postanowieniami SIWZ.
Jeżeli chodzi o pierwsze pytanie, to należy zauważyć, że tak przedstawiciel
producenta Quantum
na Polskę (zeznanie p. M. K.), którego umocowanie potwierdził jeden
ze świadków Odwołującego (zeznanie p. M. D. – str. 14 protokołu z 02.12. 2019 r.), a
Odwołujący skutecznie nie podważył, potwierdził owe wspieranie, tak w swoim oświadczeniu
pisemnym z 21.08.
2019 r., jak i podczas zeznania, które złożył na rozprawie 02.12.2019 r.
(str. od 15 do 18 protokołu z 02.12.2019 r.).
Nadto, pot
wierdza to stanowisko Zamawiającego zawarte w ramach odpowiedzi
Zamawiającego na pismo Odwołującego z 04.12.2019 r. (pismo Zamawiającego
z 05.12.2019 r.), gdzie
analizując rozwiązanie Przystępującego polegające na dołączeniu do
zaoferowanego rozwiązania - jednego switcha pracującego z prędkością 32 Gbit/s oraz
spięcia w/w switcha z macierzą za pomocą 2 portów (co daje wsparcie 32 Gbit/s) –
wskazywał ze zaoferowana macierz Quantum QXS – 424 posiada funkcjonalność MultiPath

H
igh Availabity (wielościeżkowość HA) /nienumerowana karta 7/. Ta okoliczność została
potwierdzona przez Zamawiającego poprzez wskazanie tej funkcjonalności w ramach
dołączonej do pisma, jako dowód karty katalogowej macierzy Quantum QXS – 424 (dotyczy
Quantum QXS
– 4 Hybrid Storage, w tym modelu QXS – 424).
Podniesiono tam także, że istnieje konieczność konfiguracji hosta, tak aby jego
system operacyjny rozpoznał dwa niezależne ścieżki /nienumerowana karta 8/.
Jednocześnie, Zamawiający celem potwierdzenia stosowania w praktyce takiego
rozwiązania przedstawił – potwierdzenie konfiguracji mechanizmu MPIO dla macierzy
AccelStor, z
tłumaczeniem ostatniego akapitu /nienumerowana karta 9/.
Z kolei Przystępujący powoływał się na zastosowanie karty ATTO, jako interface
hosta 32 Gbit/s i
switcha FC 32 Gbit/s, co daje możliwość uzyskania wydajności hosta na
poziomie 32 Gbit/s, także w kontekście aplikacji MultiPath /str. 12 pisma Przystępującego
z 05.12.2019 r./
, co z kolei potwierdził dowodem w postaci karty katalogowej /technicznej
/opis/ Multi Path Director Reference Guide firmy ATTO dla karty ATTO wraz z tłumaczeniem
z j. angielskiego.
Dodatkowo, przytoczył możliwość opartą o skonfigurowanie systemu plików Stornext
(SNFS) /str. 12 do 13 pism
a Przystępującego z 05.12.2019 r./ przedstawiając stosowny
schemat jego działania (str. 13 przywołanego pisma).
W tym kontekście znamienną jest również de facto zmiana stanowiska Veracomp
S.A., które doprecyzowało swoje oświadczenie załączone do odwołania – w ramach swojego
nowego oświadczenia załączonego do pisma procesowego Przystępującego z 05.12.2019 r.:
„Doprecyzowując informacją dot. macierzy serii QXS firmy Quantum, przekazaną w formie
oświadczenia firmie JBD SA, niniejszym oświadczam dodatkowo, że w tym momencie
macierze serii QXS firmy Quantum posiadają interfejsy 8/16Gbps SFP+ oraz że interfejsy
macierzy 16Gbps SFP+ obsłużą interfejsy hosta 8/16/32 Gbps i są z nimi kompatybilne.
W przypadku agregacji portów FC możliwa jest obsługa interfejsów hosta z prędkością 32
Gbps”.

Jak więc widać powyżej, tak Zamawiający, jak i Przystępujący w odpowiedzi na
wątpliwości techniczne Odwołującego wyrażone w jego piśmie procesowym z 04.12.2019 r.,
tj. odpowiedzi
na pismo Zamawiającego z 29.11.2019 r oraz Przystępującego z 02.12.
2019 r.,
co do rzeczywistej realności technicznej, co do takiego wspierania interfacy hosta 32
Gbit/s, przedstawili
konkretne przykłady poparte materiałami producenta, wykazując
zarazem ich stosowanie nie tylko
w teorii, ale również w praktyce.

Niniejsze rozwiązania są oparte o wykorzystanie więcej niż 1 portu oraz
wielościeżkowość, jak i wykorzystanie dedykowanych narzędzi programowych macierzy
i hosta.
Odwołujący de facto takich możliwości technicznych także nie wykluczał w swoim
piśmie z 04.12.2109 r., a po ich przedstawieniu w ramach pism Zamawiającego oraz
Przystępującego (oba z 05.12.2019 r.) i na samej rozprawie 06.12.2019 r., ich nie
kwestionował, lecz negował dopuszczalność wykorzystania więcej niż 1 portu macierzy
celem uzyskania wsparcia interfe
jsów hosta na poziomie 32 Gbit/s. Wskazywał, że
odwołanie w SIWZ do Fibre Channel, generuje samo w sobie wymóg wykorzystania tylko 1
portu, gdyż jest to swoisty standard określony przez Międzynarodowe Stowarzyszenie Fibre
Channel. Inaczej mówiąc uznał, że chodzi o przepustowość pojedynczego portu, a nie jego
agregacje. Stwierdził, że gdyby było inaczej nie wprowadzonoby szybszych wersji tego
systemu. Na potwierdzenie powyższego przywołał na str. 8 – 9 pisma z 04.12.2019 r.,
definicje Fibre Channel 5 generacji 16 FC
(
https://searchstorage.techtarqet.com/definition/Fibre-
Channel
)
,
gdzie stwierdza się, że: „Generacja 5 działa z określoną szybkością linii przy
przepustowości jednopasmowej (...)”
(tłumaczenie Odwołującego podane do protokołu
z rozprawy 06.12.2019 r., skorygowane poprzez autora przez translator gogle). W tym
zakresie, Izba rozważała powołanie biegłego, jednakże uznając, że istota sprowadza się do
interpretacji postanowień SIWZ, w konsekwencji biegły dokonywałby oceny prawnej. Nadto,
Izba zmuszona jest dokonywać wykładni SIWZ w kontekście całości postanowień SIWZ
i odpowiedzi na pytanie 27,
nie tylko i wyłącznie co do samego użycia sformułowania Fibre
Channel, istotny jest wiec kontekst całego sformułowania, nie tylko znaczenie Fibre Channel
„same w sobie”.
W ocenie Izby, Zamawiający wprost nie wskazywał w SIWZ, że chodzi o to, aby
macierz miała możliwość wspierania interfejsów hosta (np. poprzez wymianę kontrolerów):
Fibre Channel tylko przez 1 port, czyli za pomocą jednego połączenia. Zamawiający nie
uzależniał też od konfiguracji portów wspierania interfejsów hosta pracujących z prędkością
32 G
bit/s. Nie wymagał też, aby każdy port pracował z prędkością 32 Gbit/s.
Jednocześnie, Izba podkreśla, że wskazanie możliwości wspierania interfejsów hosta
(np. poprzez wymianę kontrolera): Fibre Channel - ma charakter przykładowy poprzez
użycie sformułowania „np.”, czyli dopuścił Zamawiający zastosowanie przez Wykonawców
innych rozwiązań. Nie ograniczył więc Zamawiający Wykonawców do jedynie wymiany
kontrolera, jako jedynego preferowanego. Te stwierdzenie wskazuje na otwarty charakter
możliwego do zastosowania rozwiązania technologicznego. Powyższe ma w ocenie Izby
kluczowe znaczenie dla oceny wymogu określonego przez Zamawiającego. Nie mniej istotna
jest odpowiedź na pytanie 27, gdzie określił Zamawiający, w odpowiedzi na wyrażone

w pytaniu wątpliwości, że działa w oparciu o całość projektu – budżetu w powiązaniu
z brzegowymi warunkami technicznymi w przypadku sieci Fibre Channel podał minimalne
wymagania funkcjonalne, tj. sieć o szybkości 16 Gbit/s. Uwzględnił całość planowanych prac
oraz przepływ materiałów. Dopuścił wyższą prędkość. Wynika więc z niej, że przyjęto
określone wymogi brzegowe z uwagi na ograniczenia budżetowe i dostępne środki, ale
dopuszcza się rozwiązanie lepsze oparte na wyższych prędkościach. Inaczej mówiąc
Zamawiający chce dobry produkt, w przystępnej cenie, w oparciu o sieć 16 Gbit/s i nie
ogranicza zastosowanych przez Wykonawców rozwiązań technicznych, które pozwolą
osiągnąć ten nadrzędny cel, nawet o szybszej przepustowości. Biorąc pod uwagę powyższe
stosując wykładnie funkcjonalną, Izba oddaliła zarzut Odwołującego w tym zakresie.
W tym kontekście przykładowe, czyli otwarte wskazanie
rozwiązania
technologicznego nie daje podstawy do zastosowania
wykładni ograniczającej wskazanej
przez
Odwołującego, mając na uwadze cel Zamawiającego i odpowiedź na pytanie 27. Izba
podkreśla, że gdyby przyjąć rozwiązanie Odwołującego zaistniałaby swoista sprzeczność
skutkująca niejednoznacznością postanowień SIWZ, które z jednej strony mają charakter
otwarty, a z drugiej strony mają charakter ograniczający do 1 portu. W takiej sytuacji owa
niejednoznaczność winna być rozstrzygana na korzyść Przystępującego, gdyż tego rodzaju
niejednoznaczność nie może być interpretowana na niekorzyść Wykonawców. Zostało to
celnie wskazane przykładowo w wyroku KIO z 16.04.2015 r. sygn. akt: KIO 660/15: "Należy
wskazać, że obowiązuje swoista "święta" zasada, że wszelkie niejasności, dwuznaczności,
niezgodności postanowień SIWZ należy rozpatrywać na korzyść wykonawców"
. Podkreślono
także w uchwale KIO z 03.08.2017 r., sygn. akt: KIO/KD 38/17, że: "Reguła ta wynika
z prawniczej paremii »In dubio contra proferentem« znaczącej w języku polskim
»Wątpliwości należy tłumaczyć przeciw autorowi«. Nie ulega wątpliwości, że Zamawiający
jest autorem ogłoszenia o zamówieniu i SIWZ, które zostały zredagowane przez
Zamawiającego."
. Podobnie w wyroku SO w Nowym Sączu z 18.03.2015 r., sygn. akt: III Ca
70/15:
"Zapisy w SIWZ (...) muszą mieć charakter precyzyjny i jednoznaczny; a wątpliwości
powstałe na tym tle muszą być rozstrzygane na korzyść wykonawcy. Obowiązek takiego
formułowania i tłumaczenia ma na celu realizację zasady uczciwej konkurencji i równego
traktowania wszystkich wykonawców przystępujących do przetargu (...)"
oraz w wyroku SO
w Szczecinie z 07.03.2018 r. (sygn. akt. VIII Ga 102/18) wskazujący, że: "Wyrażona w art. 7
ust 1 p.z.p. zasada, obecnie formułowana jako zasada przejrzystości, oznacza również
zakaz wyciągania negatywnych konsekwencji wobec wykonawcy wskutek niedopełnienia
przez niego obowiązku, który nie wynika wyraźnie z dokumentacji przetargowej lub
obowiązujących przepisów prawa krajowego, lecz jedynie z wykładni tych przepisów lub
dokumentacji, a także z uzupełniania przez krajowe organy lub sądownictwo występujących


w tej dokumentacji luk [por. postanowienie TSUE z 13.07.2017 r. w sprawie C-35/17,
Saferoad Grawil sp. z o.o. i Saferoad Kabex sp. z o. o. v. Generalna Dyrekcja Dróg
Krajowych i Autostrad, Oddział w Poznaniu; wyrok TSUE z 2.06.2016 r. w sprawie C-27/15,
Pizzo v. CRGT Srl; wyrok TSUE z 7.04.2016 r. w sprawie C-324/14, Partner A. D. v.
Zarządowi Oczyszczania Miasta, Monitor Prawniczy z 2016 r., Nr 11, s. 570; oraz wyrok
TSUE z 10.05.2012 r. w sprawie C-368/10, Ko
misja Europejska v. Królestwo Niderlandów"
.
Izba przedstawia
powyższe jedynie po to, by unaocznić, że nawet argumentacja
Odwołującego prowadzi, do tego samego rezultatu, tj. oddalenia zarzutu. Generalnie bowiem
Izba uważa, że należy przyznać prymat otwartym wymogom technicznym określonym przez
Zamawiającego,
które
wskazują
jedynie
przykładowo
ewentualne
rozwiązanie
technologiczne.
Odnosząc się zaś, do załączonej do odwołania przez Odwołującego korespondencji
e-mailowej /
przetłumaczone i uwierzytelnione z j. angielskiego wiadomości e-mailowe
między spółką Fujitsu Technology Solutions Sp. z o.o., a pracownikiem Wsparcia
Oprogramowania Quantum p. A. J. z USA
– korespondencja z 22, 23 i 26.08.2019 r.;
przetłumaczone i uwierzytelnione z j. angielskiego wiadomości e-mailowe między
pracownikiem Quantum p. N.
C., a firmą Rocket Science – korespondencja z 13, 15
i 16.08.2019 r.;
przetłumaczone i uwierzytelnione z j. angielskiego wiadomości e-mailowe
między pracownikiem Wsparcia Oprogramowania Quantum p. A. J. z USA, a firmą Bright
Technologies, Inc.
– korespondencja z 13 i 14.08.2019 r./, Izba wskazuje, że wynika
z niej, że adresaci odnosili jedynie do załączonej karty technicznej, karty katalogowej,
danych w interne
cie, w żaden sposób nie wynika z nich, aby odbiorcy byli świadomi, czy też
odnosili się do postanowień SIWZ obowiązujących w przedmiotowym postępowaniu
przetargowym
, czy też odpowiedzi na pytanie 27.
Względem zaś, załączonych do odwołania przez Odwołującego oświadczeń co do
sposobu rozumienia pierwszej funkcjonalności (oświadczenie M. J. INS Instruments z
15.11.2019 r.;
czy też oświadczenie K3 System Sp. z o.o. z 15.11.2019 r.), Izba nie
podzieliła wyrażonej tam wykładni SIWZ, która m.in. ignoruje odpowiedź na pytanie 27. W
tym zakresie podobną wykładnie przedstawiał podczas zeznania świadek Odwołującego p.
Z. C.
zupełnie ignorując odpowiedź na pytanie 27, błędnie ją odczytując, zupełnie nie
przyjmując do wiadomości, iż kwestia wymiany kontrolera odnosiła się nie do elementu
aktualnego, ale na przyszłość, także potwierdzając, że to jego osoba formułowała pytania do
partnerów technologicznych zawarte w załączonej korespondencji e-mailowej. Odpowiedział
on także negatywnie na pytanie czy, według informacji świadka została przekazana
specyfikacja i OPZ oraz odpowiedź na pytanie 27 producentom. Następnie, wyjaśniając, że

na pewno nie przekazano odpowiedzi na pytanie 27. W rezultacie, w ocenie Izby, jego
z
eznania są nieprzydatne dla okoliczności sprawy.
W zakresie
zeznania świadka p. P. J., który jest także autorem oświadczenie K3
System Sp. z o.o. z 15.11.2019 r.
należy zauważyć, że świadek stwierdził, że: „na zlecenie
Odwołującego analizował rynek i istniejące produkty pod kątem wykorzystywania
i zaoferowania zgodnie z wymaganiami Zamawiającego. (…) po uzyskaniu informacji, że
zaoferowano macierz QXS i została ona wybrana przez Zamawiającego, analizował
parametry technicz
ne tego produktu i w wyniku tej analizy okazało się, że nie spełnia
wymogu obsługiwania opcji Fibre Channel 32 Gbit/s. (…) oświadczył, że celem weryfikacji
tych negatywnych ustaleń poprosił o stanowisko dystrybutora firmy Veracomp, która
potwierdziła tą okoliczność. Podobnie uczyniono w stosunku do firmy Arrow, która
potwierdziła również, że taka możliwość nie istnieje.”
. W dalszej kolejności: „na pytanie (…)
dotyczące pytania nr 27 (…), czy w ocenie świadka odpowiedź na to pytanie zmienia
wymagania techni
czne i w konsekwencji oferowany produkt spełnia zawarte w tej odpowiedzi
oczekiwania świadek oświadczył, że odpowiedź na to pytanie nie zawierała informacji
o zmianie postanowień SIWZ. W jego ocenie nie było tam informacji o zmianie OPZ. (…) nie
wnioskował o dalsze odpowiedzi, gdyż Zamawiający nie zawarł w tej odpowiedzi, że zmienia
postanowienia OPZ.”
. W zakresie zeznań tego świadka wynika z nich jednoznacznie, że po
pierwsze została zignorowana odpowiedź na pytanie 27, po drugie świadek zaniechał
ewentualnego dopytania z czysto uznaniowych okoliczności. Dodatkowo stanowisko firmy
Veracomp de facto uległo zmianie, czemu dano wyraz w oświadczeniu załączonym do pisma
procesowego Przystępującego z 05.12.2019 r.
W zakresie
zeznania świadka p. M. D., to przyznał świadek, że nie był bezpośrednim
autorem załączonej do odwołania korespondencji e-mailowej, lecz inna osoba z Fujitsu
Technology Solutions
. Następnie w kontekście odpowiedzi na pytanie 27: „(…) czy ta
odpowiedź zmienia funkcjonalność oczekiwana przez Zamawiającego stwierdził, iż nie ma
tam wprost informacji o zmianie postanowień SIWZ i uważa, że mimo tej odpowiedzi nadal
są wymagane interfejsy o prędkości 32 Gbit/s macierzy. Uważa, że ta odpowiedź dotyczy
bardziej przełączników. Na pytanie (…) i wskazanie pierwszego zdania w pytaniu, świadek
podtrzymuje swoją wcześniejszą odpowiedź. Na pytanie (…), czy w inny sposób, niż za
pomocą korespondencji mailowej próbowano otrzymać informacje w przedmiocie
zadawanych pytań udziela odpowiedzi negatywnej. (…) Czy świadek miał wiedzę, kto był
przedstawicielem firmy Quantum na Polskę oświadcza, że tak, był to pan M. K (…), którego
zna od lat. Na pytanie (…), dlaczego, skoro zna osobę będącą przedstawicielem Quantum,
nie zwrócił się od niej bezpośrednio z pytaniem w zakresie przedmiotu sporu stwierdził, że
nie widział takiej konieczności, z uwagi na treść SIWZ. (…)”
. W ocenie Izby, zeznania są

nieprzydatne dla okoliczności sprawy (za wyjątkiem potwierdzenia umocowania
przedstawicielem fi
rmy Quantum na Polskę), gdyż błędnie interpretują odpowiedź na pytanie
27, jak i z mało wiarygodnych przyczyn świadek nie zwrócił się bezpośrednio do
przedstawiciela firmy Quantum na Polskę z pytaniem w zakresie przedmiotu sporu.
W kwestii oświadczenia spółki Arrow ECS Sp. z o.o. /bez daty/ załączonej do
odwołania przez Odwołującego, Izba zwraca uwagę, że w swej treści odnosiło się sensu
sticte
tylko do macierzy a nie wspierania hosta.
W rezultacie, uznając że zaoferowany produkt w ofercie Przystępującego spełnia
oczekiwaną przez Zamawiającego funkcjonalność.
Odnośnie drugiej funkcjonalności:
Zamawiający wymagał możliwości przywracania fragmentów plików (Partial Restore)
po TimeCode.
W ramach złożonej oferty w formularzu cenowym – część 4 - Przystępujący
zaoferował w pkt 3.2 produkt API o numerze katalogowym 215003 producenta XenData:
„w ramach systemu zarzadzania biblioteką taśmowa”, a w pkt 4: „stanowisko zarządzania
i administracji procesam
i archiwizacji kopii cyfrowych filmów”
– pkt 4.1 „System zarzadzania
i administracji procesami archiwizacji kopii cyfrowych filmów”
– Tibigen Transfer, pkt 4.2
„Serwer systemu” – serwer do systemu Tibigien.
Ze stanowiska z rozprawy z 06.12.2019 r. wynika,
że ostatecznie Odwołujący uważa,
że Przystępujący w sposób niedopuszczalny rozszerza zakres swojej oferty po jej złożeniu,
gdyż brak jest wskazania systemu Tibigen w rubryce formularza cenowego w pkt 3.2, a jest
w pkt 4.1 i 4.2, stwierdzając, że w tym punkcie jest to system archiwizacji, a nie zarządzania
biblioteką. Nadto, zastrzega, że uznałaby wskazane oprogramowanie Tibigen, gdyby
jednoznacznie podano przy nim, że dotyczy przywracania fragmentów plików. Zaś, w replice
podnosił, że ten program winień być wskazany tak w pkt 4, jak i pkt. 3.2 z racji dwóch
odrębnych funkcji.
Izba odnosząc się do powyższego i respektując wymogi SIWZ, określone
w formularzu ofertowym
, co do sposobu jego wypełnienia, wskazuje że podstawą odrzucenia
wynik
ające z art. 89 ust.1 pkt 2 Pzp jest niezgodność treści oferty z treścią SIWZ, tzn. gdy
przedmiot zamówienia wynikający z oferty nie odpowiada w pełni przedmiotowi zamówienia
opisanemu w SIWZ. Ta niekompatybilność może być oparta na wielu płaszczyznach oferty.
Jednocześnie za niezgodność z treści SIWZ nie uważa się sytuacje, w których aspekty
formalne oferty nie odpowiadają zapisom SIWZ (podobnie w wyrok KIOz dnia 15.10.2019 r.,
sygn. akt: KIO 1863/19).

Dodatkowo t
ytułem przykładu Izba wskazuje na inne orzeczenia w tym zakresie:
"Niezgodność treści oferty z treścią SIWZ w rozumieniu art. 89 ust. 1 pkt 2 Pzp polega na
niezgodności zobowiązania, które w swojej ofercie wyraża wykonawca i przez jej złożenie na
siebie przyjmuje, z z
akresem zobowiązania, którego przyjęcia oczekuje zamawiający i które
opisał w SIWZ"
(wyrok z 09.04.2015 r., sygn. akt: KIO 627/15). Podobnie: "Zarówno treść
SIWZ, jak i treść oferty należy rozumieć jako merytoryczną zawartość oświadczenia woli
odpowiednio:
zamawiającego, który w szczególności przez opis przedmiotu zamówienia
oświadcza jakiego świadczenia oczekuje po zawarciu umowy w sprawie zamówienia
publicznego, oraz wykonawcy, który zobowiązuje się do wykonania tego świadczenia w razie
wyboru złożonej przez niego oferty jako najkorzystniejszej"
(wyrok z 17.04.2015 r., sygn. akt:
KIO 674/15);
"Niezgodność oferty z treścią SIWZ, uzasadniająca odrzucenie oferty, musi
dotyczyć merytorycznych wymagań określonych w specyfikacji. Nie uzasadnia odrzucenia
oferty
jej niezgodność z SIWZ mająca charakter wyłącznie formalny, formalizm
postępowania o udzielenie zamówienia publicznego nie jest bowiem celem samym w sobie,
lecz ma służyć realizacji celu postępowania o udzielenie zamówienia publicznego
(dokonaniu wyboru na
jkorzystniejszej oferty, odpowiadającej potrzebom zamawiającego),
z poszanowaniem zasad jawności, przejrzystości, zachowania uczciwej konkurencji
i równego traktowania wykonawców"
(wyrok z 16.07.2015 r., sygn. akt: KIO 1414/15);
"Złożenie oferty - co do zasady - stanowi de facto zaakceptowanie przez wykonawcę
jednostronnie określonych przez zamawiającego oczekiwań co do zaoferowanego
przedmiotu zamówienia. Stąd jako zasadę należy przyjąć; że wykonawca podejmując
d
ecyzję o uczestnictwie w postępowaniu i złożeniu w nim oferty chce przez to uczynić
zadość postawionym w postępowaniu wymaganiom, w szczególności co do przedmiotu
zamówienia, aby oferta odpowiadała treści siwz. W konsekwencji - jeżeli jakieś konkretne
okol
iczności dobitnie nie wskazują, że jest inaczej - należy przyjąć założenie; zgodnie
z którym wykonawcy składają oferty w dobrej wierze i na serio, a zatem z zamiarem
zaoferowania świadczenia we wszystkich elementach zgodnego z wymaganiami określonymi
w opisie przedmiotu zamówienia"
(wyrok z 22.07.2015 r., sygn. akt: KIO 1472/15).
W ocenie Izby, taka sytuacja ma miejsce w przedmiotowych okolicznościach sprawy.
Odwołujący bowiem nie kwestionował ostatecznie na rozprawie 06.12.2019 r. aspektów
merytorycznych wskazanego oprogramowania Tibigen, ale jedynie jego umiejscowienie. Izba
musi się także zgodzić, że stanowiskiem Zamawiającego, że zbyt daleko idące
wyspecyfikowanie mogłoby uczynić ofertę nieczytelną. W konsekwencji uznając, że oferta
Pr
zystępującego zawiera oprogramowanie gwarantujące sporną funkcjonalność.
Jednocześnie Izba celem pełnej analizy zgromadzonego materiału dowodowego
wskazuje
w pierwszej kolejności na oświadczenie producenta XenData z 23.08.2019 r.
załączone do I – wyjaśnień z 27.08.2019 r. odnoszące się do wersji 7, co Zamawiający

zweryfikował zgodnie bowiem z informacją przywołaną przez Zamawiającego w odpowiedzi
na odwołanie – pismo z 29.11.2019 r. (karta 13 nie numerowana) opartą na materiałach
producenta XenData, dostarczone oprogramowanie XenData nr katalogowy 215003
– API
wersja 7.02 posiada tą funkcjonalność (str. 16 przywołanego dokumentu z, przetłumaczona
na j. polski przez Zamawiającego:
https://xendata.com/downloads/production_releases/7.02p2/assets/XenData_Archive_Series.pdf
)
.
Odwołujący
powyższe kwestionował załączoną do pisma z 04.12.2019 r. ulotką producenta XenData
(przetłumaczoną na j. polski przez Odwołującego), z której wynika, że ta
funkcjonalność/mechanizm do API trzeba dodać poprzez oprogramowanie zewnętrzne, tj.
program Marquis Broadcast (MB). Dodatkowo podnosząc, że API nie jestem gotowym
oprogramowaniem, ale czymś co trzeba napisać, tzn. biblioteką umożliwiającą dopisanie
wymaganego oprogramowania. W ocenie Izby,
te wątpliwości Odwołującego nie negują
istnieniu tej funkcjonalności w oferowanym oprogramowaniu, gdyż Zamawiający nie zawęził
zakresu ewentualnych
oferty tylko i wyłącznie do produktów gotowych, czy też nie wyłączył
oferowania produktów dedykowanych pod potrzeby Zamawiającego, mógł więc być to także
produkt dedykowany zawierający np. rozszerzenia program Marquis Broadcast (MB). Należy
podkreślić, że oferowanie produktu dedykowanego w postępowaniach o udzielenie
zamówienia publicznego nie jest niczym niezwykłym, naturalnie pod warunkiem, że
Zamawiający wyraźnie w SIWZ nie wyłączył takiej możliwości i nie ograniczył zakresu
przyszłej oferty w ramach postanowień przedmiotu zamówienia nakazujących ofertowanie
jedynie w zakresie produktów gotowych. Możliwy jest też wariant mieszany.
Ostatecznie Izba wskazuje, że Przystępujący do swojego pisma z 02.12.2019 r.
załączył nowe oświadczenie producenta XenData z 29.11.2019 r. ponownie potwierdzające
ocz
ekiwaną funkcjonalność. Z samego zaś, pisma Przystępującego wynika, że będzie to
współpraca API z aplikacją Tibigen, co potwierdziło oświadczenie właściciela aplikacji
Tibigen z 05.12.2019 r.:
„(…) aplikacja Tibigen współpracuje za pośrednictwem API z system
XenData (…)”
.
Podczas rozprawy 06.12.2019 r.
Przystępujący wyjaśnił, że oprogramowanie Tibigen
przywraca sekwencje plików DPX oraz przywraca fragmentu video, a wskazywany program
Marquis Broadcast (MB)
odnosił się do przywracania fragmentów video. Izba zwraca uwagę,
że już w II - wyjaśnieniach z 25.09.2019 r. odnośnie pytania 2.2 i 2.3, Przystępujący
podnosił, że nie jest konieczne używanie oprogramowanie Marquis Broadcast (MB) do
plików DPX, ale modułu API. Jeśli więc nawet uznać, że brak jest jednoznacznego dowodu,
czy oprogramowanie Marquis Broadcast (MB)
zostało zaoferowane, choć mogło być dodane
do API i według ustaleń Zamawiającego zostało w wersji 7.02, to pozostaje niewątpliwie
Tibigen.
Inaczej mówiąc XenData Archive Series, czyli API wersja 7 (zarządza systemem
plików) i współpracuje z aplikacja Tibigen, która przywraca w konsekwencji fragmenty plików

(PR) po Time
Codzie tak dla fragmentów video, jak i plików DPX (na podstawie przywołanego
powyżej oświadczenia właściciela aplikacji Tibigen). Unaocznił niniejsze Przystępujący na
schemacie na str. 14 pisma z 02.12.2019 r. oraz w opisie
i rozróżnieniu /sekwencja DPX
a pliki wideo/ na str. od 12 do 14
tego pisma. Jeśli więc API zarządza systemem plików
i współpracuje z Tibigen, to także musi akceptować plik DPX, jak i zgodnie z oświadczeniem
producenta XenData
obsługiwać częściowe przywracanie plików na podstawie kodu
czasowego.
W konsekwencji, jak było to już wskazywane na wstępie uzasadnienia
rozpatrywującego kwestie sporne dotyczące tej funkcjonalności, Odwołujący nie
kwestionował ostatecznie na rozprawie 06.12.2019 r. charakteru produktu, ale jego
umiejscowienie (Tibigen) w formularzu ofertowym i kwestie charakteru produktu API, uznając
że miały być to tylko produkty gotowe. To tych kwestii Izba odniosła się powyżej.
W zakresie
zaś, zeznania świadka p. B. W., który stwierdził, że: „(…)system nie
spełnia wymogu tworzenia kopii zapasowych potwierdza tą okoliczność. Na dalsze pytanie
wyjaśnia, że informacje w tym zakresie uzyskał m.in. od użytkowników, tu podaje przykład
Telewizji Polskiej. Zwraca uwagę na pliki DPX. (…) stwierdza iż nie ma system XanData, nie
ma takiego rozwiązania, które już samo w sobie zawierałoby funkcjonalność wtyczki MB,
konieczne jest z
awsze to oprogramowanie. (…) świadek w ramach analizy i przygotowania
oferty kontaktował się w zakresie owych brakujących funkcjonalności bezpośrednio z
producentem odpowiedział negatywnie wyjaśniając, że konsultował tą kwestię z firmą
C
ontent Networks Sp. z o.o. (…) Na pytanie (…) na jakiej podstawie świadek uznał, że
zastosowanie API generuje konieczność dopisania oprogramowania, skoro nie zapoznał się
z ofertą Przystępującego oświadczył, że API jest elementem, który determinuje dopisanie
oprogramowania. Na pytanie (…), czy jest znane mu oprogramowanie Tibigen i jego
producent oświadcza, że, z tego co pamięta, jest to firma o tej samej nazwie. Jest to firma,
która zajmuje się zarządzaniem oprogramowaniem medialnym. (…)”.
W ocenie Izby,
zeznania są nieprzydatne dla okoliczności sprawy, gdyż świadek po pierwsze ignoruje
możliwość zastosowania rozwiązania dedykowanego, po drugie abstrahuje od
zaoferowanego oprogramowania Tibigen.
W tym miejscu Izba także sygnalizuje względem oświadczeń Content Networks Sp.
z o.o.
, o czym więcej w dalej części, oświadczenie XenData z 01.12.2019 r., iż tylko
Studiotech Poland, czyli lider konsorcjum Przystępującego jest jedyną polska firmą
upoważnioną do reprezentowania XenData.
W rezultacie, uznając że zaoferowane produkty w ofercie Przystępującego spełniają
oczekiwaną przez Zamawiającego funkcjonalność.
Odnośnie trzeciej funkcjonalności:

W związku z pracą na plikach DPX zamawiający wymaga, aby system zarządzania
pracował z maksymalna liczba plików w wysokości minimum 2x 10
9
. System musi posiadać
bazę danych – której eksternalizację (backup task) umożliwia zachowanie danych systemu.
W ramach tej funkcjonalności była kwestionowana:
1) kwestia tego rodzaju, ze system XenData u
możliwia archiwizacje materiałów w formacie
DPX (kwestia tego rodzaju, że pliki DPX są podstawowym plikiem do rekonstrukcji
o p
ostpodrukcji nie było sporne między Odwołującym, a Zamawiającymi i Przystępującym
w rezultacie
załączone do odwołania przez Odwołującego oświadczenia na tą okoliczność, tj.
oświadczenie ATM System Sp. z o.o. z 18.11.2019 r.; oświadczenie AK Film Service and
Solutions A. K.
/bez daty/; wiadomość e-mailowa S. S. oraz T. D. /Wytwórnia Filmów
Dokumentalnych i Fabularnych/ z 17 i 18.11.2019 r.
miały charakter bezprzedmiotowy).

W tym zakresie Odwołujący opierał swoje zarzuty na stanowisku Content Network
Sp. z o.o. Należy zauważyć, że oświadczenie tej firmy z 15.11.2019 r., w tym zakresie nie
ma charakteru definitywnego stwierdza się jedynie że: „(…) w dokumentacji produktu
i zestawieniu obsługiwanych formatów nie ma obsługi DPX z uwzględnieniem TimeCode,
czyli wybranego zakresu podając znaczniki czasowe materiału”
. Nadto, niniejsze
oświadczenie odnosi się jedynie, czy też tylko i wyłącznie do produktu Marquis Broadcast
(MB)
. Oświadczenie XenData uzyskane przez Zamawiającego z 23.08.2019 r. w ramach
I
– wyjaśnień (na wezwanie do wyjaśnień z 20.08.2019 r.) jest po pierwsze jednoznaczne,
gdyż stwierdza: „Oprogramowanie XenData Archive Series (…) Akceptuje wszystkie typy
plików, w tym pliki DPX”
. Nadto, odnosi się do aplikacji XenData Archive Series, wersja 7.
Jednocześnie, producent XenData potwierdził powyższe w swoich oświadczenia z 25
i 29.11.2019 r. wskazując także w swoim oświadczeniu z 01.12.2019 r. (załączonym przez
Przystępującego do pisma procesowego z 02.12.2019 r.), iż tylko Studiotech Poland, czyli
lider konsorcju
m Przystępującego jest jedyną polska firmą upoważnioną do reprezentowania
XenData:
„Studiotech Poland jest jedyną polską firmą, która jest upoważniona do
reprezentowania XenData.
Upoważnienie to daje Studiotech prawo do dostarczania
technicznych i handlowy
ch informacji o produktach oferowanych przez XenData. Żadna inna
polska firma nie jest upoważniona do udzielania takich informacji. Ponadto Studiotech jest
jedyną polską firmą wymienioną jako Preferowany Partner na stronie internetowej XenData
w następującym linku:

https://xendata.eom/purchase/#europe

(...)”. Powyższe należy odnosić do
wskazywanego sytemu plików przez API i współpracy jako wsparciem z Tibigen oraz
obsługiwaniem przywracania plików na podstawie kodów czasowych przez API.
2) kolejną kwestią tego rodzaju, jest czy baza danych, jej eksternalizacja (backup task)
umożliwia zachowanie danych systemu.

W tym zakresie Odwołujący opierał swoje zarzuty na stanowisku Content Network
Sp. z o.o. (
dwa oświadczenia z 15.11.2019 r. załączone do odwołania).

Pierwsze z nich stwierdzało, że archiwizacja ma charakter rozproszony, przez co
kopia bezpieczeństwa jest zależna od ilości zgromadzonych materiałów.
Drugie, wskazuje na brak silnika bazodanowego, c
o uniemożliwia pełną
eksternalizację, wykonanie pełnej kopii danych z bazy danych do zewnętrznej lokalizacji,
uniemożliwia to wykonanie pełnej kopii zapasowej systemu, jak i przywracanie jej po awarii.
Izba
zwraca przy tym uwagę, że Content Network Sp. z o.o. w ramach swojego
trzeciego oświadczenia także z 15.11.2019 r. powoływała się na to, że jest autoryzowanym
partnerem handlowym XenData, co wobec oświadczenia XenData z 01.12.2019 r., iż tylko
Studiotech Poland, czyli lider konsorcjum Przystępującego jest jedyną polska firmą
upoważnioną do reprezentowania XenData: „Żadna inna polska firma nie jest upoważniona
do udzielania takich informacji
, podważa samo w sobie reprezentatywność wskazanych na
wstępie oświadczeń tej spółki.
Abstrahując jednakże od tej kwestii, Izba podkreśla, że Zamawiający uzyskał w toku
postępowania wyjaśniającego zapewnienie Wykonawcy (w ramach II wyjaśnień), iż system
XenData posiada własną bazę danych, która spełnia wymóg SIWZ, z której można wykonać
backup za pomocą dedykowanego mechanizmów systemu XenData, dodatkowo przywołał
zewnętrzną aplikacje SQL Interface, a także oświadczenie producenta XenData
z 23.08.2019 r. wraz z I -
wyjaśnieniami.
Odwołujący kwestionował powyższe nie tylko przez oświadczenia Content Network
Sp. z o.o.
, ale stanowisko użytkownika (e-mail z TVP).
Izba podkreśla, że zarzuty Odwołującego przedstawione w swoich stanowiskach
pisemnych sprowadzają się do tego, że baza danych ma określone cechy, które je
dyskwalifikują, a nadto, ze funkcjonalność kopii zapasowej działa w sposób wysoce mało
wydajny. Należy zauważyć, że kwestia bazy danych nie została w SIWZ w jakiś konkretny
sposób sprecyzowany, tzn. poprzez stwierdzenie, że nie może być to baza katalogowa,
a tylko rela
cyjna, czy też plikowa. Nadto, Przystępujący przedstawił oświadczenie
producenta XenData z 25.11.2019 r.:
„(...) używa wewnętrznej bazy danych (…)”, co więcej
Przystępujący przedstawił w swoim piśmie z 02.12.2019 r. trzy zrzuty ekranu
z tego
oprogramowania XenData Archive Series potwierdzające te okoliczność (str. od 16 do
17).
Następna kwestią – jej wydajność – bo kwestia tego rodzaju, że możliwość tworzenia
kopii zapasowych istnieje
nie była kwestionowana co do zasady. Zamawiający w tym
zakresie określił, iż chodzi oto, aby można było zarządzać systemem plików z maksymalną
liczbą plików w wysokości minimum 2x10
9
. Powyższe okoliczności potwierdził producent
XenData
w swoim oświadczeniu z 23.08.2019 r., Wykonawca w II - wyjaśnieniach
z 25.09.2019 r. Dodatkowo producent XenData
w oświadczeniu z 29.11.2019 r.,
a w oświadczeniu z 23.11.2019 r. XenData potwierdził dodatkowo automatyczny i manualny

backup. Jednakże, Odwołujący wskazywał na stanowisko użytkownika TVP oraz stanowisko
z materiałów XenData wersja 7 na stronie internetowej producenta. W zakresie stanowiska
użytkownika z TVP przeciwstawił Zamawiający i Przystępujący stanowisko z telewizji
słoweńskiej (RTV Slovenia – karta 16 nienumerowana odpowiedzi na odwołanie
Zamawiającego z 29.11.2019 r. oraz str. 17 pisma procesowego Przystępującego
z 05.12.2019 r. wskazano stosowny link
źródłowy i stwierdzono, że: „System XenData (…)
jest stosowany z
powodzeniem (…)”
) i wyrażał wątpliwości, co do wiarygodności osoby,
której oświadczenie przedstawiono z ramienia TVP. Izba podkreśla, że rzeczywiście
stanowisko osoby z ramienia TVP ma ograniczona wiarygodność, gdyż nie znany jest zakres
umocowania tej oso
by do działania i reprezentowania TVP, w zakresie chociażby tego
oprogramowania. Nie znana jest wersja tam funkcjonująca, jak również zakres zasobów
w zakresie, których działa ten system w TVP. Z tych względów Izba miała do dyspozycji
oświadczenie producenta, jak i przywołane przez Odwołującego na str. 13 pisma
procesowym z 04.12.2019 r.
/odpowiedź na pismo Zamawiającego z 29.11.2019 r oraz
Przystępującego z 02.12.2019 r./ materiały producenta z jego strony internetowej:
http://xendata.com/downloads/production_releases/7.04p2/assets/XenData_Archive_Series.pdf
.
. Należy stwierdzić,
w tym kontekście, że bez względu na sposób tłumaczenia przywołanych materiałów ze
strony internetowej producenta, wynika z nich niewątpliwie, że po pierwsze backup
metadanych (pkt 9.2), backup oraz przywracanie (pkt 9.3) /
za tłumaczeniem z pisma
procesowego Przystępującego z 05.12.2019 r. – str.16/, istnieje w ramach tego systemu, po
drugie, że ma on pewne ograniczenia, a po awarii proces odtworzenia danych może, ale nie
musi być długi (dotyczy pkt 9.1). Wynika więc z tego, że jest to wypadkowa liczby
woluminów. Zamawiający określił przedział minimum 2x 10
9

plików, co jak stwierdził
producent w swoim oświadczeniu z 29.11.2019 r. wynosi 2 mld plików. Zamawiający
podczas rozprawy 06.12.2019 r. oświadczył, ze chodziło o digitalizację zasobów
w określonej liczbie 260 filmów na taśmach filmowych 16 mm i kasetach VHS, w zakresie
których zwrócił się o dofinansowanie ze środków unijnych. Jednocześnie podkreślają, że
w wypadku konieczności dalszej digitalizacji w przyszłości system będzie wykorzystywany,
ale aktualnie docelowo takie a nie inne jest przeznaczenie tego systemu.
Wskazywał także,
że trudno jest partycypować w tym, co będzie w przyszłości, a przynajmniej taki był sens
jego wypowiedzi, tym bardziej wskazywanie tego we wniosku o środki unijne, choć przyznał,
że system miał charakter rozwojowy (wsparcie interfejsów hosta 32 Gbit/s), gdyż przewiduje
rozbudowę systemu do możliwości digitalizacji taśm filmowych 35 mm. Zamawiający
i Przystępujący wskazywali także na to, że zasoby Zamawiającego są nieporównywalne
z zasobami TVP, dlatego system jest wystarczający na jego potrzeby.

Izb
a w tym zakresie zwraca uwagę, że nie było jako takich szczególnych obostrzeń
co do bazy danych i kopii zapasowych, a jedynym miernikiem jest istnienie wskazanej na

wstępie funkcjonalności – praca z maksymalną liczbą plików 2 x 10
9
, umożliwienie
zachowania danych systemu. System zapewnia funkcjonalność i ma bazę danych,
je
dnocześnie producent ostrzega, że system ma swoje ograniczenia, a ściślej proces
odtworzenia nie ma charakteru błyskawicznego i bywa powolny. Zamawiający, jak wynika
z jego stanowiska jest świadomy powyższego stanu rzeczy, jednak uważa, że na jego
zasoby jest on wystarczający, tym bardziej, że producent oświadczył, że system może
zawierać do 2 mld plików i ma backup automatyczny i manualny. Nadto, Zamawiający, co
wynika pośrednio z jego stanowisk pisemnych, był zmuszony dopasować parametry systemu
i oczekiwania do swoich możliwości finansowych i bieżących zasobów dla których jest
przeznaczony (odpowiedź na pytanie 27, czy też pismo z 05.12.2019 r.), w kontekście
zawnioskowanych środków unijnych. W konsekwencji nie można kwestionować posiadania
przez produkt XenData oczekiwanej funkcjonalności, skoro Zamawiający nie wymagał więcej
ponad to
co wskazywano, a system jest dopasowany przede wszystkim do bieżących
potrzeb Zamawiającego.
W rezultacie, uznając że zaoferowane produkty w ofercie Przystępującego spełniają
oczekiwaną przez Zamawiającego funkcjonalność.
Biorąc powyższe pod uwagę, Izba uznała jak na wstępie.

W tym stanie rzeczy, Izba oddaliła odwołanie na podstawie art. 192 ust. 1 zdanie
pierwsze i ust. 2 Pzp oraz orzekła jak w sentencji.
O kosztach postępowania orzeczono stosownie do wyniku sprawy, na podstawie
przepisu art. 192 ust. 9 i 10 Pzp w zw. z
§ 3 pkt 1 lit. a oraz § 5 ust. 3 pkt 1 rozporządzenia
Prezesa Rady Ministrów z dnia 15 marca 2010 r. w sprawie wysokości
i sposobu pobierania wpisu od odwołania oraz rodzajów kosztów w postępowaniu
odwoławczym i sposobu ich rozliczania (t.j.: Dz. U. z 2018 r. poz. 972).

Przewodniczący:

………………………………




Wcześniejsze orzeczenia:

Baza orzeczeń KIO - wyszukiwarka

od: do:

Najnowsze orzeczenia

Dodaj swoje pytanie