rodzaj: WYROK
data dokumentu: 2014-03-28
rok: 2014
data dokumentu: 2014-03-28
rok: 2014
Powiązane tematy:
sygnatury akt.:
KIO 486/14
KIO 486/14
po rozpoznaniu na rozprawie w dniu 28 marca 2014 r. w Warszawie odwołania wniesionego
do Prezesa Krajowej Izby Odwoławczej w dniu 13 marca 2014 r. przez
Comarch Polska
Spółkę Akcyjną w Krakowie w postępowaniu prowadzonym przez Województwo
Małopolskie w Krakowie
przy udziale wykonawcy
COMP Spółka Akcyjna w Warszawie, zgłaszającego przystąpienie
do postępowania odwoławczego po stronie zamawiającego
do Prezesa Krajowej Izby Odwoławczej w dniu 13 marca 2014 r. przez
Comarch Polska
Spółkę Akcyjną w Krakowie w postępowaniu prowadzonym przez Województwo
Małopolskie w Krakowie
przy udziale wykonawcy
COMP Spółka Akcyjna w Warszawie, zgłaszającego przystąpienie
do postępowania odwoławczego po stronie zamawiającego
orzeka:
1.
oddala odwołanie
2. kosztami postępowania obciąża
Comarch Polska Spółkę Akcyjną w Krakowie 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
Comarch Polska
Spółkę Akcyjną w Krakowie tytułem wpisu od odwołania
2.2 zasądza od
Comarch Polska Spółki Akcyjnej w Krakowie na rzecz Województwa
Małopolskiego w Krakowie kwotę 660 zł 00 gr (słownie: sześćset sześćdziesiąt
złotych zero groszy), stanowiącą koszty postępowania odwoławczego poniesione z
tytułu dojazdu na posiedzenie Izby.
Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. - Prawo zamówień
publicznych (Dz. U. z 2013 r., poz. 907 ze zmianami) 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
Krakowie.
………………………………
Sygn. akt: KIO 486/14
Uzasadnienie
Zamawiający – Województwo Małopolskie z siedzibą w Krakowie – prowadzi
postępowanie o udzielenie zamówienia publicznego na dostawę i wdrożenie zamówienia
publicznego prowadzonego w trybie przetargu nieograniczonego na dostawę i wdrożenie
zintegrowanego systemu informatycznego wspomagającego zarządzanie Województwem
Małopolskim wraz z zakupem sprzętu komputerowego i oprogramowania wraz z usługą
szkoleniową.
Postępowanie prowadzone jest na podstawie przepisów ustawy z dnia 29 stycznia
2004 roku – Prawo zamówień publicznych (Dz. U. z 2013 roku, poz. 907 ze zmianami),
zwanej dalej ustawą Pzp.
W dniu 13 marca 2014 roku wykonawca Comarch Polska SA w Krakowie (dalej
odwołujący ) wniósł odwołanie wobec treści specyfikacji istotnych warunków zamówienia,
zarzucając zamawiającemu naruszenie:
art. 29 ust. 1 pzp oraz art. 353
1
Kodeksu cywilnego w związku z art. 139 ust. 1 ustawy
Pzp poprzez wprowadzenie do specyfikacji istotnych warunków zamówienia postanowień
niejasnych, niejednoznacznych, a także wprowadzających znaczną nierównowagę stron
stosunku zobowiązaniowego - szczegółowo przywołanych w treści uzasadnienia odwołania;
art. 29 ust. 1 ustawy Pzp poprzez opisanie przedmiotu zamówienia w sposób
niewyczerpujący, bez uwzględnienia wszystkich okoliczności mogących mieć wpływ na
przygotowanie oferty - szczegółowo przywołanych w treści uzasadnienia odwołania;
art. 29 ust. 3 oraz art. 29 ust. 2 i art. 7 ust. 1 ustawy Pzp poprzez:
a)
opisanie przedmiotu zamówienia przez wskazanie znaku towarowego (Java) pomimo,
iż nie jest to uzasadnione specyfiką zamówienia i zamawiający może opisać przedmiot
zamówienia za pomocą dostatecznie dokładnych określeń,
b)
opisanie przedmiotu zamówienia przez wskazanie znaku towarowego (Java) *
jednoczesne nieokreślenie kryteriów, którymi zamawiający będzie się kierował przy ocenie
równoważności zaoferowanych rozwiązań (określenie tych kryteriów w sposób na tyle
ogólny, że w praktyce uniemożliwiający dokonanie przez wykonawców oceny, czy oferowane
rozwiązanie będzie uznane za równoważne];
c]
opisanie przedmiotu zamówienia w sposób, który może utrudnić uczciwą
konkurencję, ze względu na wymaganie wykorzystania konkretnego, wskazanego z nazwy
rozwiązania (języka programowania java], podczas gdy istnieją na rynku inne rozwiązania,
zapewniające w równym stopniu osiągnięcie opisanego przez zamawiającego celu
(otwartość technologiczna].
W zakresie zarzutu wadliwie sporządzonego opis przedmiotu zamówienia -
postanowienia naruszające art. art 29 ust. 1 ustawy Pzp oraz art. 353
1
Kodeksu cywilnego w
związku z art. 139 ust. 1 ustawy Pzp odwołujący podniósł, że:
1.1. Zgodnie z treścią § 1 ust. 7 Załącznika nr 7 do SIWZ (wzór umowy], zamawiający
określił pięć etapów, w których ma być zrealizowany przedmiot zamówienia. Termin
wykonania czterech etapów określony jest przez wskazanie ilości miesięcy od określonego
zdarzenia (etap I, II i III - od dnia podpisania umowy, a etap V - od zakończenia etapu IV].
Natomiast termin wykonania etapu IV określony został przez zamawiającego na dzień 30
stycznia 2015 r.
W ocenie odwołującego tego rodzaju konstrukcja jest dla wykonawców skrajnie
ryzykowna ze względu na szereg okoliczności. Po pierwsze, przedłużeniu może ulec sama
procedura przetargowa. Nawet przy założeniu, że termin składania ofert nie zostanie
przesunięty (w chwili obecnej to 11 kwietnia 2014 r.], umowa nie zostanie zawarta wcześniej,
niż w drugiej połowie kwietnia. Oznacza to, że przy założeniu błyskawicznej oceny ofert i
braku odwołań, na realizację etapu IV (wdrożenie systemu] wykonawcy pozostanie 9
miesięcy. Biorąc pod uwagę fakt, iż zamawiający nie określił w SIWZ precyzyjnych wymagań
dla wdrożenia (pierwszym etapem ma być przygotowanie Karty Projektu, następnie
Koncepcji Wdrożenia], na samo wdrożenie pozostanie maksymalnie 6 miesięcy. Praktyka
wskazuje jednak na to, że w tego rodzaju postępowaniach terminy składania ofert są
przesuwane, zamawiający potrzebują więcej niż kilku dni na ocenę ofert (choćby ze względu
na konieczność przeprowadzenia procedury wyjaśnień i uzupełnień), a czynność wyboru
oferty bywa często zaskarżona do Krajowej Izby Odwoławczej. Każde tego rodzaju
standardowe przedłużenie procedury przetargowej skraca realny czas na wykonanie
wdrożenia. Może się zatem okazać, że wykonawca, który złożył ofertę, będzie zmuszony do
wyboru „mniejszego zła": utraty wadium ze względu na odmowę podpisania umowy albo
podpisania umowy ze świadomością, że terminu wdrożenia nie da się dotrzymać, a więc
konieczna będzie zapłata kar umownych, a nawet wykluczenie z ubiegania się o udzielenie
zamówienia publicznego przez okres 3 lat
Po drugie - niezrozumiałe jest określenie terminu wykonania czterech etapów poprzez
wskazanie okresu liczonego od określonego zdarzenia (od dnia podpisania umowy i od dnia
zakończenia etapu IV), a jednego etapu poprzez wskazanie konkretnej daty. Wykonawca
powinien mieć możliwość wykonania wdrożenia w określonym czasie, liczonym od dnia
ustalenia z zamawiającym sposobu realizacji zamówienia. Termin na wykonanie etapu IV
powinien być więc liczony od dnia zakończenia etapu III. Może się bowiem okazać, że - z
przyczyn nieleżących po stronie wykonawcy - realizacja pierwszych trzech etapów przedłuży
się tak, że dotrzymanie terminu określonego konkretną datą albo liczonego od dnia zawarcia
umowy będzie niemożliwe.
Odwołujący wnosi zatem o określenie terminu wykonania etapu IV poprzez wskazanie ilości
miesięcy od dnia zakończenia etapu III.
1.2.
Odwołujący wskazał, że zgodnie z treścią § 1 ust. 11 Załącznika nr 7 do SIWZ (wzór
umowy): „W ramach Umowy, Wykonawca zobowiązuje się zapewnić pełną zgodność
Systemu z przepisami prawa i zasadami obowiązującymi w Polsce. W szczególności
wykonawca zapewnia, że funkcjonalność Systemu będzie zgodna z przepisami prawa w
zakresie wymienionym w załączniku nr 1 do umowy. Ocena zgodności Systemu z
wymaganiami, o których mowa w zdaniu poprzedzającym będzie dokonywana w oparciu o
stan istniejący w chwili zgłoszenia gotowości Systemu do Odbioru"
W ocenie odwołującego z powołanego postanowienia jednoznacznie wynika, że
zgodność Systemu z przepisami prawa oceniana ma być na moment zgłoszenia Systemu do
odbioru, jednocześnie jednak System ma być zgodny z Kartą Projektu i Koncepcją
Wdrożenia, ponieważ jak wynika z § 2 ust 5 Załącznika nr 7 do SIWZ (wzór umowy): „Po
odbiorze; Karta Projektu, Koncepcja Wdrożenia lub inne koncepcje, analizy czy dokumenty
opracowane i zaakceptowane przez Strony zgodnie z postanowieniami Umowy, staną się
integralną częścią Umowy (bez konieczności sporządzania odrębnego aneksu) i od tego
czasu wymienione dokumenty staną się częścią zapisów, na podstawie których oceniane
będzie należyte wykonanie zobowiązań przez Wykonawcę. Podstawą do odbioru jest
wykonanie Systemu zgodnie z Umową i wszystkimi jej załącznikami, w tym, w szczególności,
z Kartą Projektu oraz Koncepcją Wdrożenia."
Spełnienie obu powołanych wymagań będzie niemożliwe, jeśli pomiędzy dniem odbioru
Karty Projektu i Koncepcji Wdrożenia a dniem odbioru Systemu zmienią się przepisy prawa.
Wymaganie, aby kryterium odbioru Systemu była jego zgodność z Kartą Projektu i
Koncepcją Wdrożenia, jest wymaganiem racjonalnym i zgodnym z dobrymi praktykami, w
szczególności z powszechnie przyjętymi metodykami wdrożeń. Zmiany przepisów
oczywiście powinny być uwzględniane w Systemie, lecz w ramach utrzymania, po jego
odbiorze przez Zamawiającego.
Dlatego też odwołujący wniósł o wykreślenie ostatniego zdania z ust. 11 § 1 Załącznika nr 7
do SIWZ (wzoru umowy). Ponadto odwołujący wniósł o dodanie w § 9 ust. 7 Załącznika nr 7
do SIWZ (wzór umowy), że wadą jest niezgodność z przepisami obowiązującymi w dniu
zatwierdzenia Koncepcji Wdrożenia.
1.3. Odwołujący stwierdził, iż zgodnie z treścią § 5 ust. 10 Załącznika nr 7 do SIWZ (wzór
umowy), zamawiający wymaga, aby wykonawca udzielił zamawiającemu niewyłącznych
licencji na korzystanie z Oprogramowania dostarczonego w Etapie III, między innymi na polu
eksploatacji obejmującym „tłumaczenie, przystosowywanie, zmiana układu lub jakichkolwiek
innych elementów w przedmiocie umowy, których celem jest rozbudowa, przebudowa,
rozwijanie, unowocześnianie, podwyższanie wersji (zwane upgrade’owaniem), usuwanie
problemów i awarii oraz konserwacja wykonanego przedmiotu umowy' (lit b).
Odwołujący zwrócił uwagę na fakt, iż w ramach budowy Systemu wykorzystane
muszą być różne rodzaje oprogramowania, czego nie uwzględnia powołane postanowienie.
Oczywiście, biorąc pod uwagę konieczność uniezależnienia się od jednego wykonawcy i
swobodę rozwoju Systemu zamawiający musi zapewnić sobie prawo do modyfikacji warstwy
aplikacyjnej oprogramowania. Nieracjonalne natomiast i przede wszystkim w większości
niewykonalne dla wykonawców jest zapewnienie, iż zamawiającemu będzie przysługiwało
uprawnienie do modyfikacji oprogramowania umieszczonego w głębokich warstwach
Systemu (oprogramowanie bazodanowe, np. Oracle, oprogramowanie serwerowe,
oprogramowanie narzędziowe). Wykonawcy nie są twórcami tego oprogramowania, nie mają
zatem wpływu na warunki jego licencjonowania. Z kolei twórcy tego oprogramowania
licencjonują je na standardowych warunkach, które nie umożliwiają modyfikowania
oprogramowania.
Odwołujący wniósł o dostosowanie pól eksploatacji określonych w umowie do pól
eksploatacji dla programów komputerowych oraz dodanie w § 5 ust. 10 Załącznika nr 7 do
SIWZ (wzór umowy) zastrzeżenia, iż pole eksploatacji określone w lit. b) nie dotyczy
oprogramowania:
•
niezbędnego do wirtualizacji;
•
serwera bazy danych;
•
systemów operacyjnych;
•
serwera aplikacyjnego i/lub serwera www;
•
antywirusowego;
•
oprogramowania narzędziowego dostarczanego wraz urządzeniami peryferyjnymi.
Ze względu na fakt, iż warunki licencjonowania standardowego oprogramowania podmiotów
trzecich często przewidują, iż licencja udzielana jest bezpośrednio na rzecz zamawiającego
(a nie przez wykonawcę jako licencjodawcę udzielającego zamawiającemu sublicencji),
odwołujący wniósł również o zmianę § 5 ust. 1 Załącznika nr 7 do SIWZ (wzór umowy)
poprzez nadanie mu następującego brzmienia: „W ramach wynagrodzenia, o którym mowa
w § 3 ust 1 i ust 4 lit c) Wykonawca udziela Zamawiającemu (lub zapewni udzielenie przez
producenta oprogramowania) niewyłącznych licencji na korzystanie z Oprogramowania
dostarczonego w Etapie III z chwilą podpisania protokołu odbioru za Etap III, na
następujących polach eksploatacji
1.4. Odwołujący podniósł, że zgodnie z treścią § 9 ust. 1 Załącznika nr 7 do SIWZ (wzór
umowy): „Wykonawca jest odpowiedzialny względem Zamawiającego z tytułu rękojmi za
wady, jeżeli przedmiot umowy ma wady zmniejszające jego wartość lub użyteczność ze
względu na cel oznaczony w niniejszej umowie, lub wynikający z okoliczności łub
przeznaczenia Projektu, niezgodne z parametrami ustalonymi w Specyfikacji Istotnych
Warunków Zamówienia i w złożonej przez Wykonawcę ofercie
Odwołujący podkreślił, że odpowiedzialność wykonawcy za niewykonanie lub
nienależyte wykonanie umowy określona została w § 14 umowy. Wskazane zostały w
szczególności okoliczności, które spowodują naliczenie wykonawcy kar umownych w
związku z niewykonaniem lub nienależytym wykonaniem umowy (opóźnieniem w wykonaniu
poszczególnych etapów oraz innych czynności określonych umową, usunięciem wad). W
definicjach zamawiający określił bardzo precyzyjnie, co uznawane będzie za wadę, i jak
wady będą klasyfikowane (Awaria, Błąd, Usterka).
Wadą w rozumieniu umowy jest „każda niezgodność funkcjonalna Systemu z wymaganiami
określonymi w Umowie lub niezgodność działania Systemu z Dokumentacją lub najlepszymi
praktykami dotyczącymi działania systemów informatycznych
Awaria to „Problem polegający na zatrzymaniu lub poważnym zakłóceniu pracy Systemu lub
współdziałających z nim innych systemów informatycznych Zamawiającego z przyczyn
wynikających z Systemu, w wyniku czego nie jest możliwa realizacja co najmniej jednego z
kluczowych zadań zamawiającego. Nie będzie uznawany za Awarię, lecz za Błąd problem,
co do którego wykonawca zastosuje lub wskaże skuteczne, możliwe do zastosowania u
zamawiającego i uzasadnione kosztowo obejście umożliwiające funkcjonowanie Systemu i
umożliwiające zachowanie niezakłóconej realizacji zadań. Za Awarię uznaje się również
jednoczesne wystąpienie szeregu problemów będących Błędami łub Usterkami, w przypadku
gdy takie problemy występujące jednocześnie mają ten sam skutek co Awaria." Błąd
określony został jako „Problem polegający na zakłóceniu pracy Systemu lub
współdziałających z nim innych systemów informatycznych Zamawiającego z przyczyn
wynikających z Systemu, skutkujący ograniczeniem możliwości realizacji lub uciążliwościami
w realizacji zadań Zamawiającego wspieranych przez System, dla którego to problemu
Wykonawca wskazał skuteczne obejście umożliwiające funkcjonowanie Systemu i
umożliwiające zachowanie ciągłości realizacji zadań Zamawiającego. Jeśli Wykonawca nie
wskazał obejścia Błędu lub wskazane obejście wymaga nakładów nieuzasadnionych z
ekonomicznego punktu widzenia albo nie kwalifikuje się do zastosowania ze względu na
standardy i/lub sposób prowadzenia działalności przez Zamawiającego, obejście nie jest
uznawane za skuteczne i taki Błąd jest kwalifikowany jako Awaria". Usterka natomiast to
„Problem polegający na zakłóceniu pracy Systemu, mogący mieć wpływ na funkcjonalność
Systemu lub inne systemy informatyczne Zamawiającego współdziałające z Systemem, z
przyczyn wynikających z Systemu, natomiast nie ograniczający zdolności operacyjnych
Systemu do obsługi i wspomagania zadań Zamawiającego. Usterki oznaczają wszelkie
problemy z Systemem, które nie mają istotnego wpływu na jego zastosowanie,
funkcjonowanie lub utrzymanie oraz dalszy jego rozwój, nie będące Awariami, ani Błędami."
W ocenie odwołującego powołana klauzula ogólna, zawarta w § 9 ust. 1 Załącznika
nr 7 do SIWZ, będąca w istocie nieco zmodyfikowanym przepisem art. 556 § 1 kodeksu
cywilnego (przepisu określającego odpowiedzialność sprzedawcy za wady rzeczy
sprzedanej) nie przystaje do umowy wdrożeniowej, w której zamawiający definiuje pojęcie
wady, a ponadto określa odpowiedzialność związaną z niewykonaniem lub nienależytym
wykonaniem poszczególnych obowiązków wykonawcy. Istniejący w chwili obecnej dualizm
zasad, według których dokonywana będzie ocena należytego wykonania umowy, prowadzić
może w praktyce do niemożności rozstrzygnięcia, czy wykonawca ponosi odpowiedzialność,
czy też nie. Dla przykładu, powołane postanowienie § 9 ust. 1 wzoru umowy odwołuje się do
funkcjonalności określonych w SIWZ i ofercie wykonawcy, podczas gdy z postanowień
umowy wynika, że ostateczny kształt Systemu ustalany będzie później, w ramach Koncepcji
Wdrożenia - i kształt ten może różnić się do określonego w SIWZ i ofercie. Tak ogólna
klauzula stanowi dla wykonawców istotną przeszkodę w określeniu ryzyka związanego z
realizacją zamówienia. Wykonawcy nie mają bowiem możliwości precyzyjnego ustalenia, w
jakich przypadkach będą ponosić odpowiedzialność z tytułu rękojmi.
Odwołujący wnosi zatem o wykreślenie § 9 ust. 1 Załącznika nr 7 do SIWZ, bądź też zmianę
jego brzmienia w sposób dostosowany do specyfiki projektu, na następującą: „Wykonawca
jest odpowiedzialny względem Zamawiającego z tytułu rękojmi za wady, jeżeli przedmiot
umowy ma wady zmniejszające jego wartość lub użyteczność ze względu na cel oznaczony
w niniejszej umowie, lub wynikający z okoliczności lub przeznaczenia Projektu, niezgodne z
parametrami ustalonymi przez Strony na podstawień niniejszej Umowy"
1.5. Odwołujący podniósł, że zgodnie z treścią § 10 ust. 33 Załącznika nr 7 do SIWZ (wzór
umowy): „przywołane powyżej terminy na usunięcie Wad należy stosować odpowiednio do
innych nieprawidłowości prac wdrożeniowych, których skutki będą analogiczne jak opisane w
definicjach poszczególnych rodzajów Wad".
Przywołana klauzula na etapie realizacji umowy stanowi dla wykonawcy istotne
ryzyko związane z prawdopodobnym sporem, czy dana okoliczność jest okolicznością, o
której mowa z § 10 ust. 33 umowy, i przede wszystkim jaki skutek osiągnąć ma wykonawca,
aby nie narazić się na obowiązek zapłaty kar umownych. Albo dana okoliczność jest Wadą, i
w takim przypadku wykonawca ma obowiązek ją usunąć (definicja Naprawy wskazuje, jaki
skutek ma być osiągnięty), albo nie jest - i w takim przypadku wykonawca nie powinien być
obciążany obowiązkiem wykonywania niesprecyzowanych czynności w celu osiągnięcia
nieokreślonego skutku pod rygorem zapłaty kar umownych za opóźnienie w usunięciu Wady.
Odwołujący wniósł zatem o wykreślenie wskazanego postanowienia.
1.6.
Odwołujący wskazał, że jednym z obowiązków wykonawcy w ramach realizacji
umowy będzie świadczenie, w okresie 5 lat od dnia podpisania końcowego protokołu
odbioru, usług wsparcia. W ramach tych usług wykonawca ma m.in. dokonywać zmian w
systemie
(parametryzacja
procesów
biznesowych,
modyfikacja
Oprogramowania,
opracowanie nowych funkcjonalności) w wymiarze 1500 roboczogodzin. Jak wynika z
opisanej procedury, zamawiający będzie zgłaszał potrzebę dokonania zmiany, a wykonawca
przedstawi informację o ilości roboczogodzin koniecznych do jej wykonania.
Zgodnie z treścią § 11 ust. 17 Załącznika nr 7 do SIWZ (wzór umowy): „Zamawiający
zastrzega sobie prawo do weryfikacji ilości roboczogodzin przedstawionych przez
Wykonawcę u firmy trzeciej". Zamawiający nie określił jednak, jaki może być skutek takiej
weryfikacji. Za niedopuszczalną należałoby uznać sytuację, w której skutkiem weryfikacji
byłoby narzucenie wykonawcy ilości roboczogodzin, którą ma poświęcić na wykonanie
modyfikacji stworzonego przez siebie systemu, przez podmiot trzeci. Oczywiście
Zamawiającemu przysługuje uprawnienie do zakwestionowania ilości roboczogodzin, którą
wykonawca zamierza przeznaczyć na realizację zmiany, lecz kwestia ta powinna być
rozstrzygana w ramach standardowej procedury rozstrzygania sporów między stronami
umowy, a nie w wyniku arbitralnej decyzji podmiotu trzeciego.
Odwołujący wniósł albo o wykreślenie wskazanego postanowienia, albo o doprecyzowanie,że ostateczną decyzję o ilości roboczogodzin strony podejmą wspólnie.
1.7.
Odwołujący podniósł, że zgodnie z treścią § 12 Załącznika nr 7 do SIWZ (wzór
umowy): ust. 1: Jakiekolwiek zmiany w strukturze konsorcjum będą wymagały uzyskania
uprzedniej pisemnej zgody Zamawiającego. W przypadku zmian w strukturze konsorcjum,
zmiany lidera konsorcjum, czy też otrzymania przez Zamawiającego od członków
konsorcjum wzajemnie sprzecznych lub niespójnych informacji w tym zakresie Zamawiający
będzie uprawniony do wstrzymania wszelkich czynności związanych z niniejszą umową, w
tym w szczególności wypłaty wynagrodzenia, o którym mowa w § 3 ust 1 niniejszej umowy,
do czasu uzyskania zgodnego oświadczenia wszystkich członków konsorcjum lub
otrzymania prawomocnego orzeczenia sądowego w tym zakresie"; ust. 7: „Wszelkie
oświadczenia składane przez Wykonawcę na podstawie niniejszej umowy dla swej ważności
i skuteczności muszą zostać złożone przez wskazanego zamawiającemu lidera konsorcjum,
który będzie działał w imieniu wszystkich członków konsorcjum.
Odwołujący zwrócił uwagę na fakt, iż zobowiązanie do uzyskiwania zgody na zmiany
struktury konsorcjum może być niemożliwe do wykonania przez wykonawców (np. ze
względu na likwidację jednego z konsorcjantów). Niezrozumiałe jest także wprowadzenie
uprawnienia do wstrzymania się przez Zamawiającego z wykonywaniem czynności
związanych z umową w przypadku zmiany lidera konsorcjum. Podkreślenia wymaga, że
zasadą jest wprowadzenie w umowach obowiązku porozumiewania się Zamawiającego z
liderem konsorcjum, jak również dokonywania rozliczeń z liderem konsorcjum. Natomiast w
przypadku wątpliwości co do osoby, na rzecz której świadczenie ma być spełnione, zgodnie
z ogólnymi zasadami art. 467 kodeksu cywilnego (które mają zastosowanie do umowy w
sprawie zamówienia publicznego na podstawie art. 14 ustawy Pzp) zamawiający może
złożyć przedmiot świadczenia do depozytu sądowego. Odwołujący nie widzi podstaw do
wstrzymywania przez Zamawiającego czynności związanych z umową, ponieważ może to
doprowadzić do niewykonania lub nienależytego wykonania umowy przez wykonawcę,
pomimo iż jeden z konsorcjantów był gotowy do wykonania obowiązków umownych, a z
przyczyn dotyczących innego konsorcjanta i Zamawiającego doznał przeszkód w ich
wykonaniu. Postanowienie ust. 7 może natomiast prowadzić do trudności w realizacji umowy
w przypadku, gdy w trakcie realizacji umowy nastąpi spór pomiędzy konsorcjantami.
Również ta sytuacja powinna być rozstrzygana zgodnie z ogólnymi zasadami prawa
cywilnego. Podkreślenia wymaga, że konsorcjum nie jest odrębnym bytem prawnym, zatem
wprowadzenie zasady nieskuteczności oświadczenia złożonego przez jednego z
konsorcjantów jest sprzeczne z zasadami składania oświadczeń woli, określonymi w
przepisach kodeksu cywilnego.
Odwołujący wniósł o wykreślenie powołanych postanowień.
1.8. Odwołujący wskazał, że zgodnie z treścią § 13 ust. 11 Załącznika nr 7 do SIWZ (wzór
umowy): „Datą zgłoszenia danego Produktu/Etapu/Systemu do Odbioru jest data
przekazania Zamawiającemu Produktu/Etapu/Systemu do przeprowadzenia procedury
odbiorowej, jeżeli data zgłoszenia będzie późniejsza niż data wskazana w ust 3, sytuacja
taka będzie traktowana jako opóźnienie z przyczyn leżących po stronie Wykonawcy w
dokonaniu zgłoszenia do Odbioru."
Oczywiste jest, że opóźnienie w zgłoszeniu może również wynikać z przyczyn leżących po
stronie Zamawiającego. Powołane postanowienie obciąża wykonawcę odpowiedzialnością
za okoliczności pozostające poza jego kontrolą, w tym również za okoliczności, za które
odpowiedzialny jest Zamawiający, co stanowi przekroczenie zasady swobodnego
kształtowania obowiązków stron stosunku zobowiązaniowego.
Odwołujący wniósł o wykreślenie drugiego zdania powołanego ust. 11.
Paragraf 13 ust. 12 Załącznika nr 7 do SIWZ zawiera analogiczne postanowienie przy
protokole odbioru. Powołując się na tę samą argumentację, jak w przypadku ust. 11,
odwołujący wniósł o wykreślenie drugiego zdania powołanego ustępu. Nie ma przy tym
istotnego znaczenia fakt, że powołane postanowienie wyłącza odpowiedzialność wykonawcy
w przypadku, gdy „brak podpisania protokołu" wynikał będzie z winy zamawiającego. Tak
ujęte postanowienie nie wyłącza bowiem odpowiedzialności Zamawiającego za opóźnienie w
zgłoszeniu Produktu/Etapu/Systemu do odbioru i przedłużoną z jego przyczyn procedurę
odbiorową.
Odwołujący wniósł o wykreślenie drugiego zdania powołanego ust. 12.
1.9.
Odwołujący stwierdził, że zgodnie z treścią § 16 ust. 3 Załącznika nr 7 do S1WZ
(wzór umowy): Jeżeli z przyczyn obiektywnych (w szczególności choroby, wypadku, innych
udokumentowanych zdarzeń losowych] zaistnieje konieczność dokonania zmiany osoby
wchodzącej w skład Personelu Wykonawcy wskazanej w załączniku nr 5 do Umowy,
Wykonawca niezwłocznie zaproponuje i przedstawi Kierownikowi Projektu ze strony
Zamawiającego do akceptacji osobę posiadającą kompetencje i doświadczenie w zakresie
realizacji przedmiotu Umowy, zgodne z warunkami udziału w postępowaniu."
Odwołujący zwrócił uwagę na obiektywną niemożliwość spełnienia wskazanego wymagania,
ponieważ nowa osoba (która wcześniej nie pełniła danej funkcji w projekcie) nie może mieć
takiego samego doświadczenia w zakresie realizacji przedmiotu umowy, co osoba
zastępowana, Uzasadnione i standardowo stosowane jest natomiast wymaganie, aby osoba
zastępująca miała kompetencje i doświadczenie zgodne z warunkami udziału w
postępowaniu.
Odwołujący wniósł o wykreślenie wymagania, aby osoba posiadała kompetencje i
doświadczenie „w zakresie realizacji przedmiotu Umowy".
1.10. Odwołujący podniósł, że zgodnie z treścią § 19 ust. 3 Załącznika nr 7 do SIWZ (wzór
umowy) - „Zawiadomienia dokonane w sposób określony w ust. 2 niniejszego paragrafu
będą uważane za dokonane z chwilą doręczenia, a w przypadku zawiadomień przesłanych
faksem lub pocztą elektroniczną doręczenia uważa się za dokonane z chwilą wysyłki.
Równocześnie Strony ustalają, iż w razie nieodebrania przez Stronę poprawnie adresowanej
jednokrotnie awizowanej przesyłki następuje skutek doręczenia. Każda ze Stron może
zmienić swój adres poprzez zawiadomienie przekazane drugiej Stronie w sposób określony
powyżej.”
W ocenie odwołującego postanowienie to wprowadza zmianę zasad dotyczących
składania oświadczeń woli, w stosunku do określonych w przepisach Kodeksu cywilnego,
przy czym w świetle wprowadzonych zmian w przypadku zawiadomień przesyłanych faksem
lub pocztą elektroniczną moment doręczenia byłby uzależniony od woli drugiej strony, co w
ocenie odwołującego jest zbyt daleko idącą ingerencją w zasadę równowagi uprawnień i
obowiązków stron stosunku zobowiązaniowego.
Odwołujący wniósł o wykreślenie wskazanego postanowienia, a co najmniej
wykreślenie fragmentu „a w przypadku zawiadomień przesłanych faksem lub pocztą
elektroniczną doręczenia uważa się za dokonane z chwila potwierdzenia ich odbioru przez
druga Stronę"
1.11. Odwołujący podniósł, że zgodnie z treścią § 20 Załącznika nr 7 do SIWZ (wzór
umowy), wykonawca zobowiązany jest do transferu wiedzy na temat Systemu, podejmując
aktywne działania zmierzające do umożliwienia osobom wskazanym przez zamawiającego
pozyskania wiedzy oraz wykształcenia umiejętności i kompetencji umożliwiających realizację
zadań objętych usługami Opieki Gwarancyjnej i Pogwarancyjnej oraz Asysty Technicznej, a
także usług rozwoju Systemu.
Postanowienia umowy nie określają jednak, jaki ma być czasowy rozmiar zaangażowania
wykonawcy w transfer wiedzy. W ocenie odwołującego oczywistym jest, że podmiot, który
budował system, zawsze przed przejęciem utrzymania systemu będzie miał większą wiedzę
na jego temat od podmiotu, który to utrzymanie przejmuje i nierealnym jest dążenie do stanu,
w którym wiedza dotychczasowego wykonawcy będzie równa wiedzy podmiotu
wstępującego w jego obowiązki. Zakres obowiązków wykonawcy powinien być zatem
określony czasowo, aby wykonawca mógł oszacować zasoby niezbędne do realizacji tych
obowiązków i wysokość kosztów, jakie się z tym wiążą - a w konsekwencji cenę oferty.
Odwołujący wniósł o określenie, jaki będzie wymiar czasowy (ilość roboczogodzin)
obowiązków wykonawcy związanych z transferem wiedzy.
2. W zakresie zarzutu wadliwego opius przedmiotu zamówienia - naruszenie art. 29 ust. 3,
art. 29 ust. 2 i art. 7 ust. 1 ustawy Pzp odwołujący podniósł, że zgodnie z treścią pkt 3.7
Załącznika nr 1 do umowy (Szczegółowy Opis Przedmiotu Zamówienia): „Zamawiający
wskazuje technologię java EE jako wymaganą przy tworzeniu rozwiązania",
W ocenie odwołującego wskazując na tę konkretną technologię zamawiający po
pierwsze opisał zatem przedmiot zamówienia za pomocą znaków towarowych. Java EE jest
standardem tworzenia aplikacji w języku oprogramowania Java. Java zaś jest znakiem
towarowym, tym samym wymagając użycia technologii Java EE Zamawiający narzucił
wykonawcom obowiązek stworzenia oprogramowania w konkretnym języku Java, co
aktualizuje obowiązek określony w art. 29 ust. 3 pzp.
We wstępie Załącznika nr 1 do umowy (Szczegółowym Opisie Przedmiotu Zamówienia)
Zamawiający wskazał co prawda, że jeżeli w szczegółowym opisie przedmiotu zamówienia
zostały wskazane znaki towarowe, patenty lub pochodzenie zamawiający w każdym
przypadku dopuszcza rozwiązania równoważne pod względem m.in. funkcji, materiałów,
jakości, parametrów", jednak tak ogólne wskazanie jest w zasadzie jednoznaczne z
nieokreśleniem kryteriów, którymi zamawiający będzie się kierował badając równoważność
zaoferowanych rozwiązań:
a)
sformułowanie „m.in." oznacza, że zamawiający może badać równoważność na
podstawie również innych, niewymienionych we wskazanym fragmencie elementów;
b)
zamieszczenie takiej ogólnej klauzuli na początku dokumentu zawierającego 210-
stronicowy opis przedmiotu zamówienia, w którym zamawiający w wielu miejscach posługuje
się znakami towarowymi dla bardzo różnych elementów składowych systemu, jest wyłącznie
pozornym wykonaniem obowiązku określonego w art. 29 ust. 3 ustawy Pzp. W ocenie
odwołującego jest rzeczą oczywistą, że równoważność nie oznacza „tożsamości" rozwiązań
- nie istnieją dwa identyczne produkty oznaczone tym samym znakiem towarowym.
Konieczne jest zatem określenie kryteriów równoważności konkretnie dla danego produktu.
Stwierdzenie, że równoważność może zachodzić „pod względem funkcji, materiałów, jakości,
parametrów" nie jest tak naprawdę oznaczeniem sposobu badania równoważności.
Wykonawcy narażają się zatem na ryzyko odrzucenia ich oferty ze względu na uznanie
przez Zamawiającego, że pod względem funkcji, materiałów, jakości lub parametrów
zaoferowana przez nich technologia nie jest równoważna do technologii Java EE (język
oprogramowania, w którym oferują wykonanie systemu, nie jest równoważny do języka
Java), ponieważ różnią się pod względem funkcji czy parametrów, co jest przecież
oczywiste. Rozwiązania równoważne różnią się między sobą, a istotą równoważności jest ich
podobieństwo w określonych aspektach. Aspektów tych zamawiający w odniesieniu do
technologii Java EE nie wskazał, z całą pewnością za wskazanie takie nie można bowiem
uznać ogólnej klauzuli, odnoszącej się do wszystkich elementów opisu przedmiotu
zamówienia, nieokreślającej sposobu badania równoważności.
W ocenie odwołującego naruszenie art. 29 ust. 3 ustawy Pzp w odniesieniu do
technologii Java EE polega również na tym, że zgodnie z treścią powołanego przepisu
zasadą jest zakaz opisywania przedmiotu zamówienia za pomocą znaków towarowych -
można tego dokonać wyłącznie w przypadku, gdy jest to uzasadnione specyfiką przedmiotu
zamówienia i zamawiający nie może opisać przedmiotu zamówienia za pomocą dostatecznie
dokładnych określeń. Jako uzasadnienie dla wymagania budowy systemu w technologii Java
EE Zamawiający wskazał otwartość tej technologii - jak bowiem wynika z pkt. 3.7 Załącznika
nr 1 do umowy: „Zamawiający wskazuje technologię java EE jako wymaganą przy tworzeniu
rozwiązania. Chcąc uniknąć uzależnienia się od jednej technologii serwerowej i jednego
systemu operacyjnego, Zamawiający wskazuje technologię Java EE ze względu na fakt, że
gwarantuje ona otwartość w zakresie stosowania różnych platform sprzętowych, zarówno
x86/x64 jak też RISC, co z kolei pozwala na stosowanie różnych platform systemów
operacyjnych. Celem Zamawiającego jest zatem uniknięcie uzależnienia się od jednej
technologii serwerowej i jednego systemu operacyjnego, osiągnięcie otwartości w zakresie
stosowania platform sprzęgowych, zarówno x86/x64 jak też RISC, co z kolei pozwala na
stosowanie różnych platform systemów operacyjnych. Wystarczające byłoby zatem
dokonanie opisu przedmiotu zamówienia właśnie w ten sposób, ponieważ jest to
dostatecznie dokładne określenie potrzeb Zamawiającego. Zamawiający jest w stanie
osiągnąć oczekiwany skutek bez wskazywania na konkretną technologię, co widać właśnie
choćby w treści zdania drugiego pkt. 3.7. lub treści pkt. 3.8, zgodnie z którym: „System musi
pozwalać Zamawiającemu m.in. na samodzielne jego parametryzowanie w zakresie
procesów, co uniezależni Zamawiającego od jednego Wykonawcy oraz wskazuje, że
rozwiązania technologiczne zastosowane w projekcie będą miały charakter otwarty."
Nieuzasadnione jest zatem dodatkowo wskazywanie konkretnej technologii, która - jako
jedna z kilku możliwych - zapewnia osiągnięcie opisanych przez Zamawiającego celów
(otwartość technologiczną). Działanie takie narusza zasadę opisywania przedmiotu
zamówienia za pomocą cech technicznych i jakościowych, a ponadto komplikuje ocenę ofert
i stwarza ryzyko odwołań ze względu na konieczność ustalenia, czy dana technologia jest,
czy też nie jest równoważna do technologii Java EE.
Odwołujący wskazał, że zamawiający opisał przedmiot zamówienia za pomocą znaku
towarowego, co przy obecnym braku kryteriów równoważności stanowi zdecydowaną
preferencję dla technologii Java EE i języka oprogramowania Java, a ze względu na dalsze
wymagania OPZ (choćby dla serwerów aplikacyjnych) w zasadzie jedyną technologią, którą
można zaoferować, jest technologia Java EE. Ponieważ również inne technologie
zapewniają
osiągnięcie
zakładanych
przez
Zamawiającego
celów
(otwartości
technologicznej). Zdaniem odwołującego zamawiający ograniczył konkurencję bez
uzasadnionej przyczyny, co narusza dyspozycję art. 29 ust 2 ustawy Pzp.
W związku z tym odwołujący wniósł o:
1)
usunięcie z pkt. 3.7 Załącznika nr 1 do umowy (Szczegółowego opisu przedmiotu
zamówienia] zdania pierwszego, zgodnie z którym: „Zamawiający wskazuje technologię Java
EE jako wymaganą przy tworzeniu rozwiązania,‘, ze względu na fakt, iż inne postanowienia
tego załącznika definiują potrzeby Zamawiającego i nie ma potrzeby dokonywania opisu
przez wskazanie znaku towarowego, ewentualnie:
2)
określenie kryteriów równoważności dla technologii Java EE, to jest wskazanie, że za
technologię równoważną do Java EE Zamawiający uzna technologię, dla której:
a.
translator (program komputerowy (lub urządzenie), dokonujący tłumaczenia
(translacji) programu napisanego w języku programowania, z postaci źródłowej do postaci
wynikowej, zrozumiałej dla maszyny) lub Interpreter (program komputerowy, który analizuje
kod źródłowy programu, a przeanalizowane fragmenty wykonuje), dostępny jest dla
większości znaczących systemów operacyjnych w tym dla środowisk opartych na rodzinie
Unix i Windows, i umożliwia uruchomienie aplikacji zarówno przy architekturze 32- jak i 64-
bitowej jak i RISC;
b.
serwery aplikacyjne lub serwer www, umożliwiające uruchomienie aplikacji jako witryn
internetowych, dostępne są dla większości znaczących systemów operacyjnych w tym dla
środowisk opartych na rodzinie Unix i Windows i umożliwiają pracę zarówno w architekturze
32- jak i 64-bitowej jak i RISC.
W związku z koniecznością modyfikacji SIWZ zgodnie z wnioskiem zawartym w pkt.
1) i 2) powyżej, odwołujący wniósł o modyfikację punktów: 12, 12.1, 13.2.1, 13.2.2, 13.2.3,
13.2.4, 13.2.5, 13.2.6 i 13.2.7 Załącznika nr 1 do umowy (Szczegółowego Opisu Przedmiotu
Zamówienia), dotyczących serwera aplikacji, gdyż wymagania w nich opisane są
skonstruowane w taki sposób, że dopuszczają zaoferowanie rozwiązania, które jest
kompatybilne jedynie ze zbiorem mechanizmów technicznych ściśle związanych z Java EE.
Odwołujący wniósł zatem o takie skonstruowanie postanowień SIWZ odnoszących
się do serwera aplikacji i serwera www, aby realne stało się zaoferowanie rozwiązania
równoważnego technologii Java - przy uwzględnieniu kryteriów równoważności określonych
w pkt. 1) i 2) powyżej.
Wskutek uwzględnienia części zarzutów i zmodyfikowania niektórych z nich przez
zamawiającego na posiedzeniu przed otwarciem rozprawy odwołujący cofnął zarzuty
określone w pkt 1.3, 1.4, 1.5, 1.6 i 1.9 odwołania. Na rozprawie odwołujący cofnął zarzut
wskazany w pkt 1.11 odwołania.
Izba stwierdziła, że wskazany przez odwołującego w odwołaniu stan faktyczny
jest zgodny z ustaleniami dokonanymi przez Izbę.
Izba zważyła, co następuje:
Odwołanie jest bezzasadne.
W pierwszej kolejności Izba ustaliła, że odwołujący ma interes w uzyskaniu
zamówienia uzasadniający wnoszenie środków ochrony prawnej w rozumieniu art. 179 ust. 1
ustawy Pzp.
Izba nie uwzględniła opisanych w pkt. 1 odwołania zarzutów naruszenia przez
zamawiającego art. art 29 ust. 1 ustawy Pzp oraz art. 353
1
Kodeksu cywilnego w związku z
art. 139 ust. 1 ustawy Pzp. Wszystkie te zarzuty te dotyczą wykonywania przez wybranego
wykonawcę zawartej pomiędzy stronami umowy. W szczególności Izba nie widzi możliwości
narzucania zamawiającemu, w jaki sposób ma być wykonywana jego umowa, bez
konkretnych i pewnych podstaw prawnych w tym zakresie.
Zgodnie z art. 353
1
K.c. strony zawierające umowę mogą ułożyć stosunek prawny
według swojego uznania, byle jego treść lub cel nie sprzeciwiały się właściwości (naturze)
stosunku, ustawie albo zasadom współżycia społecznego. W przypadku zamówienia
publicznego, to zamawiający w sposób dyskrecjonalny kształtuje większość essentialiae i
accidentaliae negotii przygotowując własną siwz. Zasada swobody kontraktowania ze strony
wykonawcy nie zostaje w ten sposób ograniczona - przed terminem złożenia ofert może on
składać wszelkie propozycje co do kształtu i brzmienia postanowień umownych, które
zamawiający zgodnie z własnymi interesami zawsze może uwzględnić. Natomiast w
przypadku, gdy postanowienia takie wykonawcy nie odpowiadają, może do tego stosunku
umownego - co jest jego fundamentalnym uprawnieniem - w ogóle nie przystąpić (nie
składać oferty w postępowaniu). Ponadto przez składanie ofert w postępowaniu o udzielenie
zamówienia publicznego to wykonawca kształtuje część przyszłych postanowień umownych
(w tym zawsze cenę) i w ten sposób może dostosować swoją ofertę do warunków wykonania
zamówienia narzuconych przez zamawiającego, np. tak skalkulować cenę, aby w jej ramach
uwzględnić kompensację wszelkich ryzyk i obowiązków, które wynikają dla niego z umowy w
sprawie zamówienia.
Jak daleko posunięta jest swoboda stron w ułożeniu łączącego je stosunku
prawnego, w niektórych aspektach wprost wskazują przepisy Kodeksu cywilnego, gdzie np,
art. 473 § 1 stanowi, iż dłużnik może przez umowę przyjąć (a więc druga strona może
oczekiwać, że przyjmie i uzależniać od tego możliwość zawarcia z nim umowy)
odpowiedzialność za niewykonanie lub nienależyte wykonanie zobowiązania z powodu
oznaczonych okoliczności, za które na mocy ustawy odpowiedzialności nie ponosi.
Oczywiście realizacja tego typu uprawnień podlegała będzie ocenie w świetle klauzul i zasad
ogólnych K.c.
W myśl art. 180 ust. 1 ustawy Pzp odwołanie przysługuje wyłącznie od niezgodnej z
przepisami ustawy czynności zamawiającego podjętej w postępowaniu o udzielenie
zamówienia lub zaniechania czynności, do której zamawiający jest zobowiązany na
podstawie ustawy. Podnoszone przez odwołującego zarzuty nie świadczą o naruszeniu
przez zamawiającego wskazanych przepisów, lecz o próbie ukształtowania przez
odwołującego postanowień przyszłej umowy w sposób najbardziej dla niego korzystny.
Odwołujący nie udowodnił wszakże, że do naruszenia jakiegokolwiek przepisu doszło, co
musi skutkować oddaleniem podniesionych zarzutów.
Odnosząc się do opisanego w pkt. 2 odwołania zarzutu nieprawidłowego opisu
przedmiotu zamówienia Izba stwierdziła, że zarzut ten nie zasługuje na uwzględnienie.
Stosownie do art. 29 ust. 3 ustawy Pzp przedmiotu zamówienia nie można opisywać
przez wskazanie znaków towarowych, patentów lub pochodzenia, chyba że jest to
uzasadnione specyfiką przedmiotu zamówienia i zamawiający nie może opisać przedmiotu
zamówienia za pomocą dostatecznie dokładnych określeń, a wskazaniu takiemu towarzyszą
wyrazy „lub równoważne”.
W pierwszej kolejności zważyć należy, iż Java EE nie jest zarejestrowanym znakiem
towarowym, lecz otwartym standardem. Fakt ten został przyznany przez wszystkich
uczestników postępowania. Oznacza to, iż zamawiający nie był obowiązany do wskazywania
parametrów równoważności stosownie do art. 29 ust. 3 ustawy Pzp.
Celem wprowadzenia przepisu art. 29 ust.3 ustawy Pzp jest uniknięcie sytuacji, gdy
przedmiot zamówienia będzie mógł zrealizować wyłącznie jeden wykonawca bądź też w
postępowaniu będzie mógł zostać zaoferowany produkt jednego producenta. Takie działanie
stanowiłoby naruszenie zasady uczciwej konkurencji i równego traktowania wykonawców. Z
sytuacją taką nie mamy do czynienia w rozpoznawanym przypadku.
Nie jest okolicznością sporną pomiędzy stronami fakt, iż „Java EE” stanowi otwarty
standard, odznaczający się następującymi cechami:
- jest opublikowany, a jego specyfikacja jest dostępna dla wszystkich
zainteresowanych bezpłatnie lub po kosztach druku i możliwa dla wszystkich do kopiowania,
dystrybuowania i używania bezpłatnie lub w cenie kosztów operacyjnych,
- wszelkie prawa autorskie, patenty i inna własność przemysłowa związane ze
standardem są nieodwołalnie udostępnione bez opłat,
- nie ma żadnych ograniczeń w jego wykorzystaniu.
Skoro każdy podmiot jest uprawniony do wykorzystywania standardu Java EE, nie
może być mowy o ograniczaniu konkurencji i nierównym traktowaniu wykonawców. Każdy
potencjalny wykonawca, w tym również odwołujący, na równych prawach ma dostęp do
przedmiotowego standardu. Należy zwrócić uwagę na stanowisko odwołującego wyrażone
na rozprawie, iż zarzut naruszenia art. 29 ust. 2 ustawy Pzp nie polega na uniemożliwieniu
udziału w postępowaniu w ogóle, ale na uniemożliwieniu w wyznaczonym terminie
stworzenia produktu wykonawcom, którzy mają inne technologie.
W ocenie Izby taka sytuacja nie stanowi o naruszeniu wskazanego przepisu.
Zamawiający dokonując opisu przedmiotu zamówienia nie tylko nie ma obowiązku
zapewnienia możliwości realizacji przedmiotu zamówienia wszystkim podmiotom działającym
na rynku w danej branży, ale tym bardziej nie musi zapewniać wszystkim wykonawcom
czasu umożliwiającego im stworzenie wymaganego produktu. Za naruszenie zasad uczciwej
konkurencji nie można uznać sytuacji, w której oferty nie może złożyć każdy wykonawca z
danej branży z uwagi na to, że w swoim profilu działalności nie posiada akurat produktu o
wymaganej przez zamawiającego funkcjonalności.
Powyższe potwierdza orzecznictwo Zespołu Arbitrów i Krajowej Izby Odwoławczej,
m.in. wyrok ZA z dnia 28 czerwca 2000 r., Sygn. akt UZP/ZO/0-602/00 oraz wyrok KIO z 30
lipca 2012 roku sygn. akt KIO 1516/12, zgodnie z którymi wskazanie w SIWZ wymogów
technicznych dotyczących przedmiotu zamówienia trudnych do spełnienia przez
odwołującego lub innego oferenta nie stanowi dostatecznej podstawy do uznania, że
przedmiot zamówienia określony został w sposób naruszający zasadę z art. 17 ust. 2 ustawy
o zamówieniach publicznych.
Biorąc pod uwagę powyższe orzeczono jak w sentencji.
O kosztach postępowania odwoławczego orzeczono na podstawie art. 192 ust. 9 i 10
ustawy Pzp, czyli stosownie do wyniku postępowania.
………………………………………
1.
oddala odwołanie
2. kosztami postępowania obciąża
Comarch Polska Spółkę Akcyjną w Krakowie 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
Comarch Polska
Spółkę Akcyjną w Krakowie tytułem wpisu od odwołania
2.2 zasądza od
Comarch Polska Spółki Akcyjnej w Krakowie na rzecz Województwa
Małopolskiego w Krakowie kwotę 660 zł 00 gr (słownie: sześćset sześćdziesiąt
złotych zero groszy), stanowiącą koszty postępowania odwoławczego poniesione z
tytułu dojazdu na posiedzenie Izby.
Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. - Prawo zamówień
publicznych (Dz. U. z 2013 r., poz. 907 ze zmianami) 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
Krakowie.
………………………………
Sygn. akt: KIO 486/14
Uzasadnienie
Zamawiający – Województwo Małopolskie z siedzibą w Krakowie – prowadzi
postępowanie o udzielenie zamówienia publicznego na dostawę i wdrożenie zamówienia
publicznego prowadzonego w trybie przetargu nieograniczonego na dostawę i wdrożenie
zintegrowanego systemu informatycznego wspomagającego zarządzanie Województwem
Małopolskim wraz z zakupem sprzętu komputerowego i oprogramowania wraz z usługą
szkoleniową.
Postępowanie prowadzone jest na podstawie przepisów ustawy z dnia 29 stycznia
2004 roku – Prawo zamówień publicznych (Dz. U. z 2013 roku, poz. 907 ze zmianami),
zwanej dalej ustawą Pzp.
W dniu 13 marca 2014 roku wykonawca Comarch Polska SA w Krakowie (dalej
odwołujący ) wniósł odwołanie wobec treści specyfikacji istotnych warunków zamówienia,
zarzucając zamawiającemu naruszenie:
art. 29 ust. 1 pzp oraz art. 353
1
Kodeksu cywilnego w związku z art. 139 ust. 1 ustawy
Pzp poprzez wprowadzenie do specyfikacji istotnych warunków zamówienia postanowień
niejasnych, niejednoznacznych, a także wprowadzających znaczną nierównowagę stron
stosunku zobowiązaniowego - szczegółowo przywołanych w treści uzasadnienia odwołania;
art. 29 ust. 1 ustawy Pzp poprzez opisanie przedmiotu zamówienia w sposób
niewyczerpujący, bez uwzględnienia wszystkich okoliczności mogących mieć wpływ na
przygotowanie oferty - szczegółowo przywołanych w treści uzasadnienia odwołania;
art. 29 ust. 3 oraz art. 29 ust. 2 i art. 7 ust. 1 ustawy Pzp poprzez:
a)
opisanie przedmiotu zamówienia przez wskazanie znaku towarowego (Java) pomimo,
iż nie jest to uzasadnione specyfiką zamówienia i zamawiający może opisać przedmiot
zamówienia za pomocą dostatecznie dokładnych określeń,
b)
opisanie przedmiotu zamówienia przez wskazanie znaku towarowego (Java) *
jednoczesne nieokreślenie kryteriów, którymi zamawiający będzie się kierował przy ocenie
równoważności zaoferowanych rozwiązań (określenie tych kryteriów w sposób na tyle
ogólny, że w praktyce uniemożliwiający dokonanie przez wykonawców oceny, czy oferowane
rozwiązanie będzie uznane za równoważne];
c]
opisanie przedmiotu zamówienia w sposób, który może utrudnić uczciwą
konkurencję, ze względu na wymaganie wykorzystania konkretnego, wskazanego z nazwy
rozwiązania (języka programowania java], podczas gdy istnieją na rynku inne rozwiązania,
zapewniające w równym stopniu osiągnięcie opisanego przez zamawiającego celu
(otwartość technologiczna].
W zakresie zarzutu wadliwie sporządzonego opis przedmiotu zamówienia -
postanowienia naruszające art. art 29 ust. 1 ustawy Pzp oraz art. 353
1
Kodeksu cywilnego w
związku z art. 139 ust. 1 ustawy Pzp odwołujący podniósł, że:
1.1. Zgodnie z treścią § 1 ust. 7 Załącznika nr 7 do SIWZ (wzór umowy], zamawiający
określił pięć etapów, w których ma być zrealizowany przedmiot zamówienia. Termin
wykonania czterech etapów określony jest przez wskazanie ilości miesięcy od określonego
zdarzenia (etap I, II i III - od dnia podpisania umowy, a etap V - od zakończenia etapu IV].
Natomiast termin wykonania etapu IV określony został przez zamawiającego na dzień 30
stycznia 2015 r.
W ocenie odwołującego tego rodzaju konstrukcja jest dla wykonawców skrajnie
ryzykowna ze względu na szereg okoliczności. Po pierwsze, przedłużeniu może ulec sama
procedura przetargowa. Nawet przy założeniu, że termin składania ofert nie zostanie
przesunięty (w chwili obecnej to 11 kwietnia 2014 r.], umowa nie zostanie zawarta wcześniej,
niż w drugiej połowie kwietnia. Oznacza to, że przy założeniu błyskawicznej oceny ofert i
braku odwołań, na realizację etapu IV (wdrożenie systemu] wykonawcy pozostanie 9
miesięcy. Biorąc pod uwagę fakt, iż zamawiający nie określił w SIWZ precyzyjnych wymagań
dla wdrożenia (pierwszym etapem ma być przygotowanie Karty Projektu, następnie
Koncepcji Wdrożenia], na samo wdrożenie pozostanie maksymalnie 6 miesięcy. Praktyka
wskazuje jednak na to, że w tego rodzaju postępowaniach terminy składania ofert są
przesuwane, zamawiający potrzebują więcej niż kilku dni na ocenę ofert (choćby ze względu
na konieczność przeprowadzenia procedury wyjaśnień i uzupełnień), a czynność wyboru
oferty bywa często zaskarżona do Krajowej Izby Odwoławczej. Każde tego rodzaju
standardowe przedłużenie procedury przetargowej skraca realny czas na wykonanie
wdrożenia. Może się zatem okazać, że wykonawca, który złożył ofertę, będzie zmuszony do
wyboru „mniejszego zła": utraty wadium ze względu na odmowę podpisania umowy albo
podpisania umowy ze świadomością, że terminu wdrożenia nie da się dotrzymać, a więc
konieczna będzie zapłata kar umownych, a nawet wykluczenie z ubiegania się o udzielenie
zamówienia publicznego przez okres 3 lat
Po drugie - niezrozumiałe jest określenie terminu wykonania czterech etapów poprzez
wskazanie okresu liczonego od określonego zdarzenia (od dnia podpisania umowy i od dnia
zakończenia etapu IV), a jednego etapu poprzez wskazanie konkretnej daty. Wykonawca
powinien mieć możliwość wykonania wdrożenia w określonym czasie, liczonym od dnia
ustalenia z zamawiającym sposobu realizacji zamówienia. Termin na wykonanie etapu IV
powinien być więc liczony od dnia zakończenia etapu III. Może się bowiem okazać, że - z
przyczyn nieleżących po stronie wykonawcy - realizacja pierwszych trzech etapów przedłuży
się tak, że dotrzymanie terminu określonego konkretną datą albo liczonego od dnia zawarcia
umowy będzie niemożliwe.
Odwołujący wnosi zatem o określenie terminu wykonania etapu IV poprzez wskazanie ilości
miesięcy od dnia zakończenia etapu III.
1.2.
Odwołujący wskazał, że zgodnie z treścią § 1 ust. 11 Załącznika nr 7 do SIWZ (wzór
umowy): „W ramach Umowy, Wykonawca zobowiązuje się zapewnić pełną zgodność
Systemu z przepisami prawa i zasadami obowiązującymi w Polsce. W szczególności
wykonawca zapewnia, że funkcjonalność Systemu będzie zgodna z przepisami prawa w
zakresie wymienionym w załączniku nr 1 do umowy. Ocena zgodności Systemu z
wymaganiami, o których mowa w zdaniu poprzedzającym będzie dokonywana w oparciu o
stan istniejący w chwili zgłoszenia gotowości Systemu do Odbioru"
W ocenie odwołującego z powołanego postanowienia jednoznacznie wynika, że
zgodność Systemu z przepisami prawa oceniana ma być na moment zgłoszenia Systemu do
odbioru, jednocześnie jednak System ma być zgodny z Kartą Projektu i Koncepcją
Wdrożenia, ponieważ jak wynika z § 2 ust 5 Załącznika nr 7 do SIWZ (wzór umowy): „Po
odbiorze; Karta Projektu, Koncepcja Wdrożenia lub inne koncepcje, analizy czy dokumenty
opracowane i zaakceptowane przez Strony zgodnie z postanowieniami Umowy, staną się
integralną częścią Umowy (bez konieczności sporządzania odrębnego aneksu) i od tego
czasu wymienione dokumenty staną się częścią zapisów, na podstawie których oceniane
będzie należyte wykonanie zobowiązań przez Wykonawcę. Podstawą do odbioru jest
wykonanie Systemu zgodnie z Umową i wszystkimi jej załącznikami, w tym, w szczególności,
z Kartą Projektu oraz Koncepcją Wdrożenia."
Spełnienie obu powołanych wymagań będzie niemożliwe, jeśli pomiędzy dniem odbioru
Karty Projektu i Koncepcji Wdrożenia a dniem odbioru Systemu zmienią się przepisy prawa.
Wymaganie, aby kryterium odbioru Systemu była jego zgodność z Kartą Projektu i
Koncepcją Wdrożenia, jest wymaganiem racjonalnym i zgodnym z dobrymi praktykami, w
szczególności z powszechnie przyjętymi metodykami wdrożeń. Zmiany przepisów
oczywiście powinny być uwzględniane w Systemie, lecz w ramach utrzymania, po jego
odbiorze przez Zamawiającego.
Dlatego też odwołujący wniósł o wykreślenie ostatniego zdania z ust. 11 § 1 Załącznika nr 7
do SIWZ (wzoru umowy). Ponadto odwołujący wniósł o dodanie w § 9 ust. 7 Załącznika nr 7
do SIWZ (wzór umowy), że wadą jest niezgodność z przepisami obowiązującymi w dniu
zatwierdzenia Koncepcji Wdrożenia.
1.3. Odwołujący stwierdził, iż zgodnie z treścią § 5 ust. 10 Załącznika nr 7 do SIWZ (wzór
umowy), zamawiający wymaga, aby wykonawca udzielił zamawiającemu niewyłącznych
licencji na korzystanie z Oprogramowania dostarczonego w Etapie III, między innymi na polu
eksploatacji obejmującym „tłumaczenie, przystosowywanie, zmiana układu lub jakichkolwiek
innych elementów w przedmiocie umowy, których celem jest rozbudowa, przebudowa,
rozwijanie, unowocześnianie, podwyższanie wersji (zwane upgrade’owaniem), usuwanie
problemów i awarii oraz konserwacja wykonanego przedmiotu umowy' (lit b).
Odwołujący zwrócił uwagę na fakt, iż w ramach budowy Systemu wykorzystane
muszą być różne rodzaje oprogramowania, czego nie uwzględnia powołane postanowienie.
Oczywiście, biorąc pod uwagę konieczność uniezależnienia się od jednego wykonawcy i
swobodę rozwoju Systemu zamawiający musi zapewnić sobie prawo do modyfikacji warstwy
aplikacyjnej oprogramowania. Nieracjonalne natomiast i przede wszystkim w większości
niewykonalne dla wykonawców jest zapewnienie, iż zamawiającemu będzie przysługiwało
uprawnienie do modyfikacji oprogramowania umieszczonego w głębokich warstwach
Systemu (oprogramowanie bazodanowe, np. Oracle, oprogramowanie serwerowe,
oprogramowanie narzędziowe). Wykonawcy nie są twórcami tego oprogramowania, nie mają
zatem wpływu na warunki jego licencjonowania. Z kolei twórcy tego oprogramowania
licencjonują je na standardowych warunkach, które nie umożliwiają modyfikowania
oprogramowania.
Odwołujący wniósł o dostosowanie pól eksploatacji określonych w umowie do pól
eksploatacji dla programów komputerowych oraz dodanie w § 5 ust. 10 Załącznika nr 7 do
SIWZ (wzór umowy) zastrzeżenia, iż pole eksploatacji określone w lit. b) nie dotyczy
oprogramowania:
•
niezbędnego do wirtualizacji;
•
serwera bazy danych;
•
systemów operacyjnych;
•
serwera aplikacyjnego i/lub serwera www;
•
antywirusowego;
•
oprogramowania narzędziowego dostarczanego wraz urządzeniami peryferyjnymi.
Ze względu na fakt, iż warunki licencjonowania standardowego oprogramowania podmiotów
trzecich często przewidują, iż licencja udzielana jest bezpośrednio na rzecz zamawiającego
(a nie przez wykonawcę jako licencjodawcę udzielającego zamawiającemu sublicencji),
odwołujący wniósł również o zmianę § 5 ust. 1 Załącznika nr 7 do SIWZ (wzór umowy)
poprzez nadanie mu następującego brzmienia: „W ramach wynagrodzenia, o którym mowa
w § 3 ust 1 i ust 4 lit c) Wykonawca udziela Zamawiającemu (lub zapewni udzielenie przez
producenta oprogramowania) niewyłącznych licencji na korzystanie z Oprogramowania
dostarczonego w Etapie III z chwilą podpisania protokołu odbioru za Etap III, na
następujących polach eksploatacji
1.4. Odwołujący podniósł, że zgodnie z treścią § 9 ust. 1 Załącznika nr 7 do SIWZ (wzór
umowy): „Wykonawca jest odpowiedzialny względem Zamawiającego z tytułu rękojmi za
wady, jeżeli przedmiot umowy ma wady zmniejszające jego wartość lub użyteczność ze
względu na cel oznaczony w niniejszej umowie, lub wynikający z okoliczności łub
przeznaczenia Projektu, niezgodne z parametrami ustalonymi w Specyfikacji Istotnych
Warunków Zamówienia i w złożonej przez Wykonawcę ofercie
Odwołujący podkreślił, że odpowiedzialność wykonawcy za niewykonanie lub
nienależyte wykonanie umowy określona została w § 14 umowy. Wskazane zostały w
szczególności okoliczności, które spowodują naliczenie wykonawcy kar umownych w
związku z niewykonaniem lub nienależytym wykonaniem umowy (opóźnieniem w wykonaniu
poszczególnych etapów oraz innych czynności określonych umową, usunięciem wad). W
definicjach zamawiający określił bardzo precyzyjnie, co uznawane będzie za wadę, i jak
wady będą klasyfikowane (Awaria, Błąd, Usterka).
Wadą w rozumieniu umowy jest „każda niezgodność funkcjonalna Systemu z wymaganiami
określonymi w Umowie lub niezgodność działania Systemu z Dokumentacją lub najlepszymi
praktykami dotyczącymi działania systemów informatycznych
Awaria to „Problem polegający na zatrzymaniu lub poważnym zakłóceniu pracy Systemu lub
współdziałających z nim innych systemów informatycznych Zamawiającego z przyczyn
wynikających z Systemu, w wyniku czego nie jest możliwa realizacja co najmniej jednego z
kluczowych zadań zamawiającego. Nie będzie uznawany za Awarię, lecz za Błąd problem,
co do którego wykonawca zastosuje lub wskaże skuteczne, możliwe do zastosowania u
zamawiającego i uzasadnione kosztowo obejście umożliwiające funkcjonowanie Systemu i
umożliwiające zachowanie niezakłóconej realizacji zadań. Za Awarię uznaje się również
jednoczesne wystąpienie szeregu problemów będących Błędami łub Usterkami, w przypadku
gdy takie problemy występujące jednocześnie mają ten sam skutek co Awaria." Błąd
określony został jako „Problem polegający na zakłóceniu pracy Systemu lub
współdziałających z nim innych systemów informatycznych Zamawiającego z przyczyn
wynikających z Systemu, skutkujący ograniczeniem możliwości realizacji lub uciążliwościami
w realizacji zadań Zamawiającego wspieranych przez System, dla którego to problemu
Wykonawca wskazał skuteczne obejście umożliwiające funkcjonowanie Systemu i
umożliwiające zachowanie ciągłości realizacji zadań Zamawiającego. Jeśli Wykonawca nie
wskazał obejścia Błędu lub wskazane obejście wymaga nakładów nieuzasadnionych z
ekonomicznego punktu widzenia albo nie kwalifikuje się do zastosowania ze względu na
standardy i/lub sposób prowadzenia działalności przez Zamawiającego, obejście nie jest
uznawane za skuteczne i taki Błąd jest kwalifikowany jako Awaria". Usterka natomiast to
„Problem polegający na zakłóceniu pracy Systemu, mogący mieć wpływ na funkcjonalność
Systemu lub inne systemy informatyczne Zamawiającego współdziałające z Systemem, z
przyczyn wynikających z Systemu, natomiast nie ograniczający zdolności operacyjnych
Systemu do obsługi i wspomagania zadań Zamawiającego. Usterki oznaczają wszelkie
problemy z Systemem, które nie mają istotnego wpływu na jego zastosowanie,
funkcjonowanie lub utrzymanie oraz dalszy jego rozwój, nie będące Awariami, ani Błędami."
W ocenie odwołującego powołana klauzula ogólna, zawarta w § 9 ust. 1 Załącznika
nr 7 do SIWZ, będąca w istocie nieco zmodyfikowanym przepisem art. 556 § 1 kodeksu
cywilnego (przepisu określającego odpowiedzialność sprzedawcy za wady rzeczy
sprzedanej) nie przystaje do umowy wdrożeniowej, w której zamawiający definiuje pojęcie
wady, a ponadto określa odpowiedzialność związaną z niewykonaniem lub nienależytym
wykonaniem poszczególnych obowiązków wykonawcy. Istniejący w chwili obecnej dualizm
zasad, według których dokonywana będzie ocena należytego wykonania umowy, prowadzić
może w praktyce do niemożności rozstrzygnięcia, czy wykonawca ponosi odpowiedzialność,
czy też nie. Dla przykładu, powołane postanowienie § 9 ust. 1 wzoru umowy odwołuje się do
funkcjonalności określonych w SIWZ i ofercie wykonawcy, podczas gdy z postanowień
umowy wynika, że ostateczny kształt Systemu ustalany będzie później, w ramach Koncepcji
Wdrożenia - i kształt ten może różnić się do określonego w SIWZ i ofercie. Tak ogólna
klauzula stanowi dla wykonawców istotną przeszkodę w określeniu ryzyka związanego z
realizacją zamówienia. Wykonawcy nie mają bowiem możliwości precyzyjnego ustalenia, w
jakich przypadkach będą ponosić odpowiedzialność z tytułu rękojmi.
Odwołujący wnosi zatem o wykreślenie § 9 ust. 1 Załącznika nr 7 do SIWZ, bądź też zmianę
jego brzmienia w sposób dostosowany do specyfiki projektu, na następującą: „Wykonawca
jest odpowiedzialny względem Zamawiającego z tytułu rękojmi za wady, jeżeli przedmiot
umowy ma wady zmniejszające jego wartość lub użyteczność ze względu na cel oznaczony
w niniejszej umowie, lub wynikający z okoliczności lub przeznaczenia Projektu, niezgodne z
parametrami ustalonymi przez Strony na podstawień niniejszej Umowy"
1.5. Odwołujący podniósł, że zgodnie z treścią § 10 ust. 33 Załącznika nr 7 do SIWZ (wzór
umowy): „przywołane powyżej terminy na usunięcie Wad należy stosować odpowiednio do
innych nieprawidłowości prac wdrożeniowych, których skutki będą analogiczne jak opisane w
definicjach poszczególnych rodzajów Wad".
Przywołana klauzula na etapie realizacji umowy stanowi dla wykonawcy istotne
ryzyko związane z prawdopodobnym sporem, czy dana okoliczność jest okolicznością, o
której mowa z § 10 ust. 33 umowy, i przede wszystkim jaki skutek osiągnąć ma wykonawca,
aby nie narazić się na obowiązek zapłaty kar umownych. Albo dana okoliczność jest Wadą, i
w takim przypadku wykonawca ma obowiązek ją usunąć (definicja Naprawy wskazuje, jaki
skutek ma być osiągnięty), albo nie jest - i w takim przypadku wykonawca nie powinien być
obciążany obowiązkiem wykonywania niesprecyzowanych czynności w celu osiągnięcia
nieokreślonego skutku pod rygorem zapłaty kar umownych za opóźnienie w usunięciu Wady.
Odwołujący wniósł zatem o wykreślenie wskazanego postanowienia.
1.6.
Odwołujący wskazał, że jednym z obowiązków wykonawcy w ramach realizacji
umowy będzie świadczenie, w okresie 5 lat od dnia podpisania końcowego protokołu
odbioru, usług wsparcia. W ramach tych usług wykonawca ma m.in. dokonywać zmian w
systemie
(parametryzacja
procesów
biznesowych,
modyfikacja
Oprogramowania,
opracowanie nowych funkcjonalności) w wymiarze 1500 roboczogodzin. Jak wynika z
opisanej procedury, zamawiający będzie zgłaszał potrzebę dokonania zmiany, a wykonawca
przedstawi informację o ilości roboczogodzin koniecznych do jej wykonania.
Zgodnie z treścią § 11 ust. 17 Załącznika nr 7 do SIWZ (wzór umowy): „Zamawiający
zastrzega sobie prawo do weryfikacji ilości roboczogodzin przedstawionych przez
Wykonawcę u firmy trzeciej". Zamawiający nie określił jednak, jaki może być skutek takiej
weryfikacji. Za niedopuszczalną należałoby uznać sytuację, w której skutkiem weryfikacji
byłoby narzucenie wykonawcy ilości roboczogodzin, którą ma poświęcić na wykonanie
modyfikacji stworzonego przez siebie systemu, przez podmiot trzeci. Oczywiście
Zamawiającemu przysługuje uprawnienie do zakwestionowania ilości roboczogodzin, którą
wykonawca zamierza przeznaczyć na realizację zmiany, lecz kwestia ta powinna być
rozstrzygana w ramach standardowej procedury rozstrzygania sporów między stronami
umowy, a nie w wyniku arbitralnej decyzji podmiotu trzeciego.
Odwołujący wniósł albo o wykreślenie wskazanego postanowienia, albo o doprecyzowanie,że ostateczną decyzję o ilości roboczogodzin strony podejmą wspólnie.
1.7.
Odwołujący podniósł, że zgodnie z treścią § 12 Załącznika nr 7 do SIWZ (wzór
umowy): ust. 1: Jakiekolwiek zmiany w strukturze konsorcjum będą wymagały uzyskania
uprzedniej pisemnej zgody Zamawiającego. W przypadku zmian w strukturze konsorcjum,
zmiany lidera konsorcjum, czy też otrzymania przez Zamawiającego od członków
konsorcjum wzajemnie sprzecznych lub niespójnych informacji w tym zakresie Zamawiający
będzie uprawniony do wstrzymania wszelkich czynności związanych z niniejszą umową, w
tym w szczególności wypłaty wynagrodzenia, o którym mowa w § 3 ust 1 niniejszej umowy,
do czasu uzyskania zgodnego oświadczenia wszystkich członków konsorcjum lub
otrzymania prawomocnego orzeczenia sądowego w tym zakresie"; ust. 7: „Wszelkie
oświadczenia składane przez Wykonawcę na podstawie niniejszej umowy dla swej ważności
i skuteczności muszą zostać złożone przez wskazanego zamawiającemu lidera konsorcjum,
który będzie działał w imieniu wszystkich członków konsorcjum.
Odwołujący zwrócił uwagę na fakt, iż zobowiązanie do uzyskiwania zgody na zmiany
struktury konsorcjum może być niemożliwe do wykonania przez wykonawców (np. ze
względu na likwidację jednego z konsorcjantów). Niezrozumiałe jest także wprowadzenie
uprawnienia do wstrzymania się przez Zamawiającego z wykonywaniem czynności
związanych z umową w przypadku zmiany lidera konsorcjum. Podkreślenia wymaga, że
zasadą jest wprowadzenie w umowach obowiązku porozumiewania się Zamawiającego z
liderem konsorcjum, jak również dokonywania rozliczeń z liderem konsorcjum. Natomiast w
przypadku wątpliwości co do osoby, na rzecz której świadczenie ma być spełnione, zgodnie
z ogólnymi zasadami art. 467 kodeksu cywilnego (które mają zastosowanie do umowy w
sprawie zamówienia publicznego na podstawie art. 14 ustawy Pzp) zamawiający może
złożyć przedmiot świadczenia do depozytu sądowego. Odwołujący nie widzi podstaw do
wstrzymywania przez Zamawiającego czynności związanych z umową, ponieważ może to
doprowadzić do niewykonania lub nienależytego wykonania umowy przez wykonawcę,
pomimo iż jeden z konsorcjantów był gotowy do wykonania obowiązków umownych, a z
przyczyn dotyczących innego konsorcjanta i Zamawiającego doznał przeszkód w ich
wykonaniu. Postanowienie ust. 7 może natomiast prowadzić do trudności w realizacji umowy
w przypadku, gdy w trakcie realizacji umowy nastąpi spór pomiędzy konsorcjantami.
Również ta sytuacja powinna być rozstrzygana zgodnie z ogólnymi zasadami prawa
cywilnego. Podkreślenia wymaga, że konsorcjum nie jest odrębnym bytem prawnym, zatem
wprowadzenie zasady nieskuteczności oświadczenia złożonego przez jednego z
konsorcjantów jest sprzeczne z zasadami składania oświadczeń woli, określonymi w
przepisach kodeksu cywilnego.
Odwołujący wniósł o wykreślenie powołanych postanowień.
1.8. Odwołujący wskazał, że zgodnie z treścią § 13 ust. 11 Załącznika nr 7 do SIWZ (wzór
umowy): „Datą zgłoszenia danego Produktu/Etapu/Systemu do Odbioru jest data
przekazania Zamawiającemu Produktu/Etapu/Systemu do przeprowadzenia procedury
odbiorowej, jeżeli data zgłoszenia będzie późniejsza niż data wskazana w ust 3, sytuacja
taka będzie traktowana jako opóźnienie z przyczyn leżących po stronie Wykonawcy w
dokonaniu zgłoszenia do Odbioru."
Oczywiste jest, że opóźnienie w zgłoszeniu może również wynikać z przyczyn leżących po
stronie Zamawiającego. Powołane postanowienie obciąża wykonawcę odpowiedzialnością
za okoliczności pozostające poza jego kontrolą, w tym również za okoliczności, za które
odpowiedzialny jest Zamawiający, co stanowi przekroczenie zasady swobodnego
kształtowania obowiązków stron stosunku zobowiązaniowego.
Odwołujący wniósł o wykreślenie drugiego zdania powołanego ust. 11.
Paragraf 13 ust. 12 Załącznika nr 7 do SIWZ zawiera analogiczne postanowienie przy
protokole odbioru. Powołując się na tę samą argumentację, jak w przypadku ust. 11,
odwołujący wniósł o wykreślenie drugiego zdania powołanego ustępu. Nie ma przy tym
istotnego znaczenia fakt, że powołane postanowienie wyłącza odpowiedzialność wykonawcy
w przypadku, gdy „brak podpisania protokołu" wynikał będzie z winy zamawiającego. Tak
ujęte postanowienie nie wyłącza bowiem odpowiedzialności Zamawiającego za opóźnienie w
zgłoszeniu Produktu/Etapu/Systemu do odbioru i przedłużoną z jego przyczyn procedurę
odbiorową.
Odwołujący wniósł o wykreślenie drugiego zdania powołanego ust. 12.
1.9.
Odwołujący stwierdził, że zgodnie z treścią § 16 ust. 3 Załącznika nr 7 do S1WZ
(wzór umowy): Jeżeli z przyczyn obiektywnych (w szczególności choroby, wypadku, innych
udokumentowanych zdarzeń losowych] zaistnieje konieczność dokonania zmiany osoby
wchodzącej w skład Personelu Wykonawcy wskazanej w załączniku nr 5 do Umowy,
Wykonawca niezwłocznie zaproponuje i przedstawi Kierownikowi Projektu ze strony
Zamawiającego do akceptacji osobę posiadającą kompetencje i doświadczenie w zakresie
realizacji przedmiotu Umowy, zgodne z warunkami udziału w postępowaniu."
Odwołujący zwrócił uwagę na obiektywną niemożliwość spełnienia wskazanego wymagania,
ponieważ nowa osoba (która wcześniej nie pełniła danej funkcji w projekcie) nie może mieć
takiego samego doświadczenia w zakresie realizacji przedmiotu umowy, co osoba
zastępowana, Uzasadnione i standardowo stosowane jest natomiast wymaganie, aby osoba
zastępująca miała kompetencje i doświadczenie zgodne z warunkami udziału w
postępowaniu.
Odwołujący wniósł o wykreślenie wymagania, aby osoba posiadała kompetencje i
doświadczenie „w zakresie realizacji przedmiotu Umowy".
1.10. Odwołujący podniósł, że zgodnie z treścią § 19 ust. 3 Załącznika nr 7 do SIWZ (wzór
umowy) - „Zawiadomienia dokonane w sposób określony w ust. 2 niniejszego paragrafu
będą uważane za dokonane z chwilą doręczenia, a w przypadku zawiadomień przesłanych
faksem lub pocztą elektroniczną doręczenia uważa się za dokonane z chwilą wysyłki.
Równocześnie Strony ustalają, iż w razie nieodebrania przez Stronę poprawnie adresowanej
jednokrotnie awizowanej przesyłki następuje skutek doręczenia. Każda ze Stron może
zmienić swój adres poprzez zawiadomienie przekazane drugiej Stronie w sposób określony
powyżej.”
W ocenie odwołującego postanowienie to wprowadza zmianę zasad dotyczących
składania oświadczeń woli, w stosunku do określonych w przepisach Kodeksu cywilnego,
przy czym w świetle wprowadzonych zmian w przypadku zawiadomień przesyłanych faksem
lub pocztą elektroniczną moment doręczenia byłby uzależniony od woli drugiej strony, co w
ocenie odwołującego jest zbyt daleko idącą ingerencją w zasadę równowagi uprawnień i
obowiązków stron stosunku zobowiązaniowego.
Odwołujący wniósł o wykreślenie wskazanego postanowienia, a co najmniej
wykreślenie fragmentu „a w przypadku zawiadomień przesłanych faksem lub pocztą
elektroniczną doręczenia uważa się za dokonane z chwila potwierdzenia ich odbioru przez
druga Stronę"
1.11. Odwołujący podniósł, że zgodnie z treścią § 20 Załącznika nr 7 do SIWZ (wzór
umowy), wykonawca zobowiązany jest do transferu wiedzy na temat Systemu, podejmując
aktywne działania zmierzające do umożliwienia osobom wskazanym przez zamawiającego
pozyskania wiedzy oraz wykształcenia umiejętności i kompetencji umożliwiających realizację
zadań objętych usługami Opieki Gwarancyjnej i Pogwarancyjnej oraz Asysty Technicznej, a
także usług rozwoju Systemu.
Postanowienia umowy nie określają jednak, jaki ma być czasowy rozmiar zaangażowania
wykonawcy w transfer wiedzy. W ocenie odwołującego oczywistym jest, że podmiot, który
budował system, zawsze przed przejęciem utrzymania systemu będzie miał większą wiedzę
na jego temat od podmiotu, który to utrzymanie przejmuje i nierealnym jest dążenie do stanu,
w którym wiedza dotychczasowego wykonawcy będzie równa wiedzy podmiotu
wstępującego w jego obowiązki. Zakres obowiązków wykonawcy powinien być zatem
określony czasowo, aby wykonawca mógł oszacować zasoby niezbędne do realizacji tych
obowiązków i wysokość kosztów, jakie się z tym wiążą - a w konsekwencji cenę oferty.
Odwołujący wniósł o określenie, jaki będzie wymiar czasowy (ilość roboczogodzin)
obowiązków wykonawcy związanych z transferem wiedzy.
2. W zakresie zarzutu wadliwego opius przedmiotu zamówienia - naruszenie art. 29 ust. 3,
art. 29 ust. 2 i art. 7 ust. 1 ustawy Pzp odwołujący podniósł, że zgodnie z treścią pkt 3.7
Załącznika nr 1 do umowy (Szczegółowy Opis Przedmiotu Zamówienia): „Zamawiający
wskazuje technologię java EE jako wymaganą przy tworzeniu rozwiązania",
W ocenie odwołującego wskazując na tę konkretną technologię zamawiający po
pierwsze opisał zatem przedmiot zamówienia za pomocą znaków towarowych. Java EE jest
standardem tworzenia aplikacji w języku oprogramowania Java. Java zaś jest znakiem
towarowym, tym samym wymagając użycia technologii Java EE Zamawiający narzucił
wykonawcom obowiązek stworzenia oprogramowania w konkretnym języku Java, co
aktualizuje obowiązek określony w art. 29 ust. 3 pzp.
We wstępie Załącznika nr 1 do umowy (Szczegółowym Opisie Przedmiotu Zamówienia)
Zamawiający wskazał co prawda, że jeżeli w szczegółowym opisie przedmiotu zamówienia
zostały wskazane znaki towarowe, patenty lub pochodzenie zamawiający w każdym
przypadku dopuszcza rozwiązania równoważne pod względem m.in. funkcji, materiałów,
jakości, parametrów", jednak tak ogólne wskazanie jest w zasadzie jednoznaczne z
nieokreśleniem kryteriów, którymi zamawiający będzie się kierował badając równoważność
zaoferowanych rozwiązań:
a)
sformułowanie „m.in." oznacza, że zamawiający może badać równoważność na
podstawie również innych, niewymienionych we wskazanym fragmencie elementów;
b)
zamieszczenie takiej ogólnej klauzuli na początku dokumentu zawierającego 210-
stronicowy opis przedmiotu zamówienia, w którym zamawiający w wielu miejscach posługuje
się znakami towarowymi dla bardzo różnych elementów składowych systemu, jest wyłącznie
pozornym wykonaniem obowiązku określonego w art. 29 ust. 3 ustawy Pzp. W ocenie
odwołującego jest rzeczą oczywistą, że równoważność nie oznacza „tożsamości" rozwiązań
- nie istnieją dwa identyczne produkty oznaczone tym samym znakiem towarowym.
Konieczne jest zatem określenie kryteriów równoważności konkretnie dla danego produktu.
Stwierdzenie, że równoważność może zachodzić „pod względem funkcji, materiałów, jakości,
parametrów" nie jest tak naprawdę oznaczeniem sposobu badania równoważności.
Wykonawcy narażają się zatem na ryzyko odrzucenia ich oferty ze względu na uznanie
przez Zamawiającego, że pod względem funkcji, materiałów, jakości lub parametrów
zaoferowana przez nich technologia nie jest równoważna do technologii Java EE (język
oprogramowania, w którym oferują wykonanie systemu, nie jest równoważny do języka
Java), ponieważ różnią się pod względem funkcji czy parametrów, co jest przecież
oczywiste. Rozwiązania równoważne różnią się między sobą, a istotą równoważności jest ich
podobieństwo w określonych aspektach. Aspektów tych zamawiający w odniesieniu do
technologii Java EE nie wskazał, z całą pewnością za wskazanie takie nie można bowiem
uznać ogólnej klauzuli, odnoszącej się do wszystkich elementów opisu przedmiotu
zamówienia, nieokreślającej sposobu badania równoważności.
W ocenie odwołującego naruszenie art. 29 ust. 3 ustawy Pzp w odniesieniu do
technologii Java EE polega również na tym, że zgodnie z treścią powołanego przepisu
zasadą jest zakaz opisywania przedmiotu zamówienia za pomocą znaków towarowych -
można tego dokonać wyłącznie w przypadku, gdy jest to uzasadnione specyfiką przedmiotu
zamówienia i zamawiający nie może opisać przedmiotu zamówienia za pomocą dostatecznie
dokładnych określeń. Jako uzasadnienie dla wymagania budowy systemu w technologii Java
EE Zamawiający wskazał otwartość tej technologii - jak bowiem wynika z pkt. 3.7 Załącznika
nr 1 do umowy: „Zamawiający wskazuje technologię java EE jako wymaganą przy tworzeniu
rozwiązania. Chcąc uniknąć uzależnienia się od jednej technologii serwerowej i jednego
systemu operacyjnego, Zamawiający wskazuje technologię Java EE ze względu na fakt, że
gwarantuje ona otwartość w zakresie stosowania różnych platform sprzętowych, zarówno
x86/x64 jak też RISC, co z kolei pozwala na stosowanie różnych platform systemów
operacyjnych. Celem Zamawiającego jest zatem uniknięcie uzależnienia się od jednej
technologii serwerowej i jednego systemu operacyjnego, osiągnięcie otwartości w zakresie
stosowania platform sprzęgowych, zarówno x86/x64 jak też RISC, co z kolei pozwala na
stosowanie różnych platform systemów operacyjnych. Wystarczające byłoby zatem
dokonanie opisu przedmiotu zamówienia właśnie w ten sposób, ponieważ jest to
dostatecznie dokładne określenie potrzeb Zamawiającego. Zamawiający jest w stanie
osiągnąć oczekiwany skutek bez wskazywania na konkretną technologię, co widać właśnie
choćby w treści zdania drugiego pkt. 3.7. lub treści pkt. 3.8, zgodnie z którym: „System musi
pozwalać Zamawiającemu m.in. na samodzielne jego parametryzowanie w zakresie
procesów, co uniezależni Zamawiającego od jednego Wykonawcy oraz wskazuje, że
rozwiązania technologiczne zastosowane w projekcie będą miały charakter otwarty."
Nieuzasadnione jest zatem dodatkowo wskazywanie konkretnej technologii, która - jako
jedna z kilku możliwych - zapewnia osiągnięcie opisanych przez Zamawiającego celów
(otwartość technologiczną). Działanie takie narusza zasadę opisywania przedmiotu
zamówienia za pomocą cech technicznych i jakościowych, a ponadto komplikuje ocenę ofert
i stwarza ryzyko odwołań ze względu na konieczność ustalenia, czy dana technologia jest,
czy też nie jest równoważna do technologii Java EE.
Odwołujący wskazał, że zamawiający opisał przedmiot zamówienia za pomocą znaku
towarowego, co przy obecnym braku kryteriów równoważności stanowi zdecydowaną
preferencję dla technologii Java EE i języka oprogramowania Java, a ze względu na dalsze
wymagania OPZ (choćby dla serwerów aplikacyjnych) w zasadzie jedyną technologią, którą
można zaoferować, jest technologia Java EE. Ponieważ również inne technologie
zapewniają
osiągnięcie
zakładanych
przez
Zamawiającego
celów
(otwartości
technologicznej). Zdaniem odwołującego zamawiający ograniczył konkurencję bez
uzasadnionej przyczyny, co narusza dyspozycję art. 29 ust 2 ustawy Pzp.
W związku z tym odwołujący wniósł o:
1)
usunięcie z pkt. 3.7 Załącznika nr 1 do umowy (Szczegółowego opisu przedmiotu
zamówienia] zdania pierwszego, zgodnie z którym: „Zamawiający wskazuje technologię Java
EE jako wymaganą przy tworzeniu rozwiązania,‘, ze względu na fakt, iż inne postanowienia
tego załącznika definiują potrzeby Zamawiającego i nie ma potrzeby dokonywania opisu
przez wskazanie znaku towarowego, ewentualnie:
2)
określenie kryteriów równoważności dla technologii Java EE, to jest wskazanie, że za
technologię równoważną do Java EE Zamawiający uzna technologię, dla której:
a.
translator (program komputerowy (lub urządzenie), dokonujący tłumaczenia
(translacji) programu napisanego w języku programowania, z postaci źródłowej do postaci
wynikowej, zrozumiałej dla maszyny) lub Interpreter (program komputerowy, który analizuje
kod źródłowy programu, a przeanalizowane fragmenty wykonuje), dostępny jest dla
większości znaczących systemów operacyjnych w tym dla środowisk opartych na rodzinie
Unix i Windows, i umożliwia uruchomienie aplikacji zarówno przy architekturze 32- jak i 64-
bitowej jak i RISC;
b.
serwery aplikacyjne lub serwer www, umożliwiające uruchomienie aplikacji jako witryn
internetowych, dostępne są dla większości znaczących systemów operacyjnych w tym dla
środowisk opartych na rodzinie Unix i Windows i umożliwiają pracę zarówno w architekturze
32- jak i 64-bitowej jak i RISC.
W związku z koniecznością modyfikacji SIWZ zgodnie z wnioskiem zawartym w pkt.
1) i 2) powyżej, odwołujący wniósł o modyfikację punktów: 12, 12.1, 13.2.1, 13.2.2, 13.2.3,
13.2.4, 13.2.5, 13.2.6 i 13.2.7 Załącznika nr 1 do umowy (Szczegółowego Opisu Przedmiotu
Zamówienia), dotyczących serwera aplikacji, gdyż wymagania w nich opisane są
skonstruowane w taki sposób, że dopuszczają zaoferowanie rozwiązania, które jest
kompatybilne jedynie ze zbiorem mechanizmów technicznych ściśle związanych z Java EE.
Odwołujący wniósł zatem o takie skonstruowanie postanowień SIWZ odnoszących
się do serwera aplikacji i serwera www, aby realne stało się zaoferowanie rozwiązania
równoważnego technologii Java - przy uwzględnieniu kryteriów równoważności określonych
w pkt. 1) i 2) powyżej.
Wskutek uwzględnienia części zarzutów i zmodyfikowania niektórych z nich przez
zamawiającego na posiedzeniu przed otwarciem rozprawy odwołujący cofnął zarzuty
określone w pkt 1.3, 1.4, 1.5, 1.6 i 1.9 odwołania. Na rozprawie odwołujący cofnął zarzut
wskazany w pkt 1.11 odwołania.
Izba stwierdziła, że wskazany przez odwołującego w odwołaniu stan faktyczny
jest zgodny z ustaleniami dokonanymi przez Izbę.
Izba zważyła, co następuje:
Odwołanie jest bezzasadne.
W pierwszej kolejności Izba ustaliła, że odwołujący ma interes w uzyskaniu
zamówienia uzasadniający wnoszenie środków ochrony prawnej w rozumieniu art. 179 ust. 1
ustawy Pzp.
Izba nie uwzględniła opisanych w pkt. 1 odwołania zarzutów naruszenia przez
zamawiającego art. art 29 ust. 1 ustawy Pzp oraz art. 353
1
Kodeksu cywilnego w związku z
art. 139 ust. 1 ustawy Pzp. Wszystkie te zarzuty te dotyczą wykonywania przez wybranego
wykonawcę zawartej pomiędzy stronami umowy. W szczególności Izba nie widzi możliwości
narzucania zamawiającemu, w jaki sposób ma być wykonywana jego umowa, bez
konkretnych i pewnych podstaw prawnych w tym zakresie.
Zgodnie z art. 353
1
K.c. strony zawierające umowę mogą ułożyć stosunek prawny
według swojego uznania, byle jego treść lub cel nie sprzeciwiały się właściwości (naturze)
stosunku, ustawie albo zasadom współżycia społecznego. W przypadku zamówienia
publicznego, to zamawiający w sposób dyskrecjonalny kształtuje większość essentialiae i
accidentaliae negotii przygotowując własną siwz. Zasada swobody kontraktowania ze strony
wykonawcy nie zostaje w ten sposób ograniczona - przed terminem złożenia ofert może on
składać wszelkie propozycje co do kształtu i brzmienia postanowień umownych, które
zamawiający zgodnie z własnymi interesami zawsze może uwzględnić. Natomiast w
przypadku, gdy postanowienia takie wykonawcy nie odpowiadają, może do tego stosunku
umownego - co jest jego fundamentalnym uprawnieniem - w ogóle nie przystąpić (nie
składać oferty w postępowaniu). Ponadto przez składanie ofert w postępowaniu o udzielenie
zamówienia publicznego to wykonawca kształtuje część przyszłych postanowień umownych
(w tym zawsze cenę) i w ten sposób może dostosować swoją ofertę do warunków wykonania
zamówienia narzuconych przez zamawiającego, np. tak skalkulować cenę, aby w jej ramach
uwzględnić kompensację wszelkich ryzyk i obowiązków, które wynikają dla niego z umowy w
sprawie zamówienia.
Jak daleko posunięta jest swoboda stron w ułożeniu łączącego je stosunku
prawnego, w niektórych aspektach wprost wskazują przepisy Kodeksu cywilnego, gdzie np,
art. 473 § 1 stanowi, iż dłużnik może przez umowę przyjąć (a więc druga strona może
oczekiwać, że przyjmie i uzależniać od tego możliwość zawarcia z nim umowy)
odpowiedzialność za niewykonanie lub nienależyte wykonanie zobowiązania z powodu
oznaczonych okoliczności, za które na mocy ustawy odpowiedzialności nie ponosi.
Oczywiście realizacja tego typu uprawnień podlegała będzie ocenie w świetle klauzul i zasad
ogólnych K.c.
W myśl art. 180 ust. 1 ustawy Pzp odwołanie przysługuje wyłącznie od niezgodnej z
przepisami ustawy czynności zamawiającego podjętej w postępowaniu o udzielenie
zamówienia lub zaniechania czynności, do której zamawiający jest zobowiązany na
podstawie ustawy. Podnoszone przez odwołującego zarzuty nie świadczą o naruszeniu
przez zamawiającego wskazanych przepisów, lecz o próbie ukształtowania przez
odwołującego postanowień przyszłej umowy w sposób najbardziej dla niego korzystny.
Odwołujący nie udowodnił wszakże, że do naruszenia jakiegokolwiek przepisu doszło, co
musi skutkować oddaleniem podniesionych zarzutów.
Odnosząc się do opisanego w pkt. 2 odwołania zarzutu nieprawidłowego opisu
przedmiotu zamówienia Izba stwierdziła, że zarzut ten nie zasługuje na uwzględnienie.
Stosownie do art. 29 ust. 3 ustawy Pzp przedmiotu zamówienia nie można opisywać
przez wskazanie znaków towarowych, patentów lub pochodzenia, chyba że jest to
uzasadnione specyfiką przedmiotu zamówienia i zamawiający nie może opisać przedmiotu
zamówienia za pomocą dostatecznie dokładnych określeń, a wskazaniu takiemu towarzyszą
wyrazy „lub równoważne”.
W pierwszej kolejności zważyć należy, iż Java EE nie jest zarejestrowanym znakiem
towarowym, lecz otwartym standardem. Fakt ten został przyznany przez wszystkich
uczestników postępowania. Oznacza to, iż zamawiający nie był obowiązany do wskazywania
parametrów równoważności stosownie do art. 29 ust. 3 ustawy Pzp.
Celem wprowadzenia przepisu art. 29 ust.3 ustawy Pzp jest uniknięcie sytuacji, gdy
przedmiot zamówienia będzie mógł zrealizować wyłącznie jeden wykonawca bądź też w
postępowaniu będzie mógł zostać zaoferowany produkt jednego producenta. Takie działanie
stanowiłoby naruszenie zasady uczciwej konkurencji i równego traktowania wykonawców. Z
sytuacją taką nie mamy do czynienia w rozpoznawanym przypadku.
Nie jest okolicznością sporną pomiędzy stronami fakt, iż „Java EE” stanowi otwarty
standard, odznaczający się następującymi cechami:
- jest opublikowany, a jego specyfikacja jest dostępna dla wszystkich
zainteresowanych bezpłatnie lub po kosztach druku i możliwa dla wszystkich do kopiowania,
dystrybuowania i używania bezpłatnie lub w cenie kosztów operacyjnych,
- wszelkie prawa autorskie, patenty i inna własność przemysłowa związane ze
standardem są nieodwołalnie udostępnione bez opłat,
- nie ma żadnych ograniczeń w jego wykorzystaniu.
Skoro każdy podmiot jest uprawniony do wykorzystywania standardu Java EE, nie
może być mowy o ograniczaniu konkurencji i nierównym traktowaniu wykonawców. Każdy
potencjalny wykonawca, w tym również odwołujący, na równych prawach ma dostęp do
przedmiotowego standardu. Należy zwrócić uwagę na stanowisko odwołującego wyrażone
na rozprawie, iż zarzut naruszenia art. 29 ust. 2 ustawy Pzp nie polega na uniemożliwieniu
udziału w postępowaniu w ogóle, ale na uniemożliwieniu w wyznaczonym terminie
stworzenia produktu wykonawcom, którzy mają inne technologie.
W ocenie Izby taka sytuacja nie stanowi o naruszeniu wskazanego przepisu.
Zamawiający dokonując opisu przedmiotu zamówienia nie tylko nie ma obowiązku
zapewnienia możliwości realizacji przedmiotu zamówienia wszystkim podmiotom działającym
na rynku w danej branży, ale tym bardziej nie musi zapewniać wszystkim wykonawcom
czasu umożliwiającego im stworzenie wymaganego produktu. Za naruszenie zasad uczciwej
konkurencji nie można uznać sytuacji, w której oferty nie może złożyć każdy wykonawca z
danej branży z uwagi na to, że w swoim profilu działalności nie posiada akurat produktu o
wymaganej przez zamawiającego funkcjonalności.
Powyższe potwierdza orzecznictwo Zespołu Arbitrów i Krajowej Izby Odwoławczej,
m.in. wyrok ZA z dnia 28 czerwca 2000 r., Sygn. akt UZP/ZO/0-602/00 oraz wyrok KIO z 30
lipca 2012 roku sygn. akt KIO 1516/12, zgodnie z którymi wskazanie w SIWZ wymogów
technicznych dotyczących przedmiotu zamówienia trudnych do spełnienia przez
odwołującego lub innego oferenta nie stanowi dostatecznej podstawy do uznania, że
przedmiot zamówienia określony został w sposób naruszający zasadę z art. 17 ust. 2 ustawy
o zamówieniach publicznych.
Biorąc pod uwagę powyższe orzeczono jak w sentencji.
O kosztach postępowania odwoławczego orzeczono na podstawie art. 192 ust. 9 i 10
ustawy Pzp, czyli stosownie do wyniku postępowania.
………………………………………
Wcześniejsze orzeczenia:
- Sygn. akt KIO 263/15 z dnia 2015-12-23
- Sygn. akt KIO 245/15, KIO 305/15 z dnia 2015-03-04
- Sygn. akt KIO 270/15 z dnia 2015-03-03
- Sygn. akt KIO 273/15 z dnia 2015-02-27
- Sygn. akt KIO 267/15 z dnia 2015-02-27
