rodzaj: WYROK
data dokumentu: 2017-01-23
rok: 2016
data dokumentu: 2017-01-23
rok: 2016
sygnatury akt.:
KIO 2439/16
KIO 2439/16
Komisja w składzie:
Przewodniczący: Emil Kuriata, Marek Koleśnikow, Piotr Kozłowski Protokolant: Agata Dziuban, Rafał Komoń,
Przewodniczący: Emil Kuriata, Marek Koleśnikow, Piotr Kozłowski Protokolant: Agata Dziuban, Rafał Komoń,
po rozpoznaniu na rozprawie
11 i 18 stycznia 2017 r. w Warszawie odwołania wniesionego
23 grudnia 2016 r. do Prezesa Krajowej Izby Odwoławczej
przez wykonawcę:
Sputnik Software sp. z o.o. z siedzibą w Poznaniu
w postępowaniu o udzielenie zamówienia publicznego pn. Dostawa i wdrożenie systemu
informatycznego wspomagającego zarządzanie finansami Miasta (nr postępowania
DOA-ZP-VIII.271.71.2015)
prowadzonym przez zamawiającego:
Miasto Łódź
przy udziale
wykonawców wspólnie ubiegających się o udzielenie zamówienia: Asseco
Data Systems S.A. z siedzibą w Gdyni, Asseco Poland S.A. z siedzibą w Rzeszowie,
DahliaMatic sp. z o.o. z siedzibą w Warszawie
11 i 18 stycznia 2017 r. w Warszawie odwołania wniesionego
23 grudnia 2016 r. do Prezesa Krajowej Izby Odwoławczej
przez wykonawcę:
Sputnik Software sp. z o.o. z siedzibą w Poznaniu
w postępowaniu o udzielenie zamówienia publicznego pn. Dostawa i wdrożenie systemu
informatycznego wspomagającego zarządzanie finansami Miasta (nr postępowania
DOA-ZP-VIII.271.71.2015)
prowadzonym przez zamawiającego:
Miasto Łódź
przy udziale
wykonawców wspólnie ubiegających się o udzielenie zamówienia: Asseco
Data Systems S.A. z siedzibą w Gdyni, Asseco Poland S.A. z siedzibą w Rzeszowie,
DahliaMatic sp. z o.o. z siedzibą w Warszawie
orzeka:
1. Oddala odwołanie.
2. Kosztami postępowania obciąża Sputnik Software sp. z o.o. z siedzibą w Poznaniu
i zalicza w poczet kosztów postępowania odwoławczego kwotę
15000 zł 00 gr (słownie:
piętnaście tysięcy złotych zero groszy) uiszczoną przez powyższego
odwołującego
tytułem wpisu od odwołania.
Sygn. akt KIO 2439/16
Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. – Prawo zamówień
publicznych (t.j. Dz. U. z 2015 r. poz. 2164 ze zm.) 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 Łodzi.
Przewodniczący:
………………………………
………………………………
………………………………
Sygn. akt KIO 2439/16
U z a s a d n i e n i e
Zamawiający – Miasto Łódź – prowadzi na podstawie ustawy z dnia 29 stycznia
2004 r. – Prawo zamówień publicznych (t.j. Dz. U. z 2015 r. poz. 2164 ze zm.) {dalej również:
„ustawa pzp”, „pzp”} w trybie przetargu nieograniczonego postępowanie o udzielenie
zamówienia publicznego na dostawy pn. Dostawa i wdrożenie systemu informatycznego
wspomagającego
zarządzanie
finansami
Miasta
(nr
postępowania
DOA-ZP-
VIII.271.71.2015).
Ogłoszenie o tym zamówieniu zostało zamieszczone w Dzienniku Urzędowym Unii
Europejskiej nr 2016/S_047-078958 z 29 stycznia 2016 r., w tym samym dniu Zamawiający
zamieścił ogłoszenie o zamówieniu w swojej siedzibie oraz na swojej stronie internetowej
{http://przetargi.bip.uml.lodz.pl}, na której również od tego dnia udostępnił specyfikację
istotnych warunków zamówienia {dalej również: „specyfikacja” , „SIWZ” lub „s.i.w.z.”}.
Ustalona przez Zamawiającego wartość zamówienia przekracza kwoty, których mowa
w przepisach wydanych na podstawie art. 11 ust. 8 pzp.
14 grudnia 2016 r. Zamawiający przesłał drogą elektroniczną Odwołującemu –
Sputnik Software sp. z o.o. z siedzibą w Poznaniu {dalej również: „Sputnik”} – zawiadomienie
o wyborze jako najkorzystniejszej oferty złożonej przez wykonawców wspólnie ubiegających
się o udzielenie zamówienia: Asseco Data Systems S.A. z siedzibą w Gdyni, Asseco Poland
S.A. z siedzibą w Rzeszowie, DahliaMatic sp. z o.o. z siedzibą w Warszawie {dalej również:
„Konsorcjum Asseco”}, a także o odrzuceniu oferty Odwołującego.
23 grudnia 2016 r. Odwołujący wniósł w formie pisemnej do Prezesa Krajowej Izby
Odwoławczej odwołanie (zachowując wymóg przekazania jego kopii Zamawiającemu)
od powyższej czynności Zamawiającego, któremu zarzucił następujące naruszenia ustawy
pzp:
1. Art. 91 ust. 1 w zw. z art. 7 ust. 1 – przez zaniechanie ich zastosowania i wybór oferty
niebędącej najkorzystniejszą w rozumieniu SIWZ.
2. Art. 89 ust. 1 pkt 2 – przez bezpodstawne jego zastosowanie i odrzucenie oferty
Odwołującego.
3. Art. 7 ust. 1 – przez zaniechanie jego zastosowania i nierówne traktowanie
wykonawców.
Odwołujący wniósł o uwzględnienie odwołania i nakazanie Zamawiającemu:
1. Unieważnienia wyboru oferty najkorzystniejszej.
2. Unieważnienia odrzucenia oferty złożonej przez Sputnik.
Sygn. akt KIO 2439/16
3. Dokonania ponownej oceny ofert z udziałem oferty Odwołującego.
Odwołujący sprecyzował powyższą listę zarzutów przez zbiorcze podanie
następujących okoliczności prawnych i faktycznych dla uzasadnienia wniesienia odwołania.
Odwołujący zrelacjonował, że pismem z 14 grudnia 2016 r., na skutek ponownej
oceny ofert nakazanej wyrokiem Krajowej Izby Odwoławczej z 23 września 2016 r. (sygn.
akt: KIO 1641/16, 1652/16, 1662/16), Zamawiający zawiadomił wykonawców o powtórnym
wyborze oferty Konsorcjum Asseco oraz o ponownym odrzuceniu oferty Odwołującego. Jako
podstawę prawną odrzucenia oferty Odwołującego wskazano art. 89 ust. 1 pkt 2 pzp, zaś
faktyczną – niewłaściwe i niezgodne z SIWZ przygotowanie zestawu testowego
na podstawie którego przeprowadzona została prezentacja Systemu w dniu 1 czerwca
2016 r., co Zamawiający stwierdził w oparciu o odpowiedź Odwołującego z 27 czerwca
2016 r., informacje uzyskane w trakcie rozpraw w KIO oraz opinię Politechniki Rzeszowskiej.
Ponadto Zamawiający przedstawił wymagania postawione w SIWZ, powołując się
na definicję Systemu, w którego skład wchodzą Oprogramowanie, Oprogramowanie
Aplikacyjne, Dokumentacja, Kody źródłowe inne elementy.
W załączniku nr 1 do SIWZ – Opis przedmiotu zamówienia w pkt. 1 Zamawiający
jednoznacznie wskazał, że wsparcie dla zarządzania finansami Miasta musi być zapewnione
na poziomie standardowego rozwiązania klasy ERP, co w praktyce oznacza konieczność
dostarczenia przez wykonawcę komponentu aplikacyjnego.
Oznacza to, że standardowe rozwiązanie klasy ERP musi zawierać komponent aplikacyjny
standardowego rozwiązania klasy ERP, który przynajmniej w części realizuje funkcjonalności,
których oczekuje Zamawiający w zakresie zarządzania finansami miasta.
Rozumienie to zostało również potwierdzone w trakcie rozprawy przed KIO w dniu
26.02.2016 r., gdzie strony zgodnie stwierdziły, że komponent aplikacyjny stanowi co
najmniej 50% funkcjonalności opisanej w OPZ. Co więcej standardowe rozwiązanie klasy
ERP musi być dostępne na rynku w wersji COTS (czyli w wersji komercyjnej, seryjnie
produkowanej i gotowej do sprzedaży).
Zatem oferta każdego Wykonawcy oprócz dokumentów wymaganych musiała
zawierać odpowiednio przygotowany zestaw testowy zawierający wersję demonstracyjną
Systemu jw.:
• oprogramowanie = komponenty techniczne ERP, komponenty aplikacyjne ERP,
• oprogramowanie aplikacyjne zawierające rozbudowy standardowego rozwiązania
klasy ERP (w obszarze komponentu aplikacyjnego).
Według Odwołującego z podanego uzasadnienia wynika, że brak w jego zestawie
Sygn. akt KIO 2439/16
testowym wspomnianego „komponentu aplikacyjnego standardowego rozwiązania klasy
ERP” stanowi o stwierdzonej przez Zamawiającego niezgodności oferty z SIWZ. Odwołujący
zakwestionował takie rozstrzygnięcie, twierdząc, że jego oferta jest w całości zgodna
z treścią SIWZ, zarzucając jednocześnie Zamawiającemu, że w istocie nie wskazał
jakiegokolwiek punktu tej specyfikacji, któremu ta oferta by nie odpowiadała.
W szczególności w żadnym postanowieniu SIWZ nie ma obowiązku wykonania zestawu
testowego lub Systemu z wykorzystaniem „komponentu aplikacyjnego standardowego
rozwiązania klasy ERP”, a na takim błędnym założeniu opiera się uzasadnienie
Zamawiającego.
Odwołujący zrelacjonował również, że przedmiotem zamówienia jest dostawa,
wdrożenie, dostosowanie do potrzeb Zamawiającego, uruchomienie oraz serwis gwarancyjny
i usługi asysty technicznej standardowego rozwiązania klasy ERP wspierającego
zarządzanie finansami miasta w Urzędzie Miasta Łodzi i Miejskich Jednostkach
Organizacyjnych wymienionych w załączniku nr 2 do załącznika nr 1 do SIWZ
Odwołujący następnie zacytował, że zgodnie z definicjami przyjętymi w SIWZ (tabela
pkt 1.2 załącznika nr 1 do SIWZ – Opis przedmiotu zamówienia {dalej również: „OPZ”}:
Oprogramowanie oznacza łącznie: oprogramowanie systemowe, bazodanowe, narzędziowe
lub ogólnego przeznaczenia; oprogramowanie systemowe dostarczone przez Wykonawcę
w Rozwiązaniu o ile jest ono konieczne do realizacji przedmiotu zamówienia. Obejmuje
system operacyjny, zarządzanie systemem i siecią, standardowe rozwiązania klasy ERP oraz
oprogramowanie diagnostyczne;
oprogramowanie bazodanowe oznacza silnik bazy danych i narzędzia do zarządzania bazą
danych; oprogramowanie narzędziowe obejmuje narzędzia programistyczne służące do
budowy, kompilacji, modyfikacji, przystosowywania i uruchamiania Oprogramowania
Aplikacyjnego, w szczególności narzędzia typu CASE, narzędzia zarządzania bazą danych,
kompilatory, interpretatory;
oprogramowanie ogólnego przeznaczenia obejmuje m.in. edytor tekstu, arkusz kalkulacyjny,
itp.
Oprogramowanie Aplikacyjne oznacza, wykonane przez Wykonawcę rozbudowy
(przykładowo nowe moduły, warstwy, funkcjonalności standardowego rozwiązania klasy ERP.
mające na celu dostosowanie standardowego rozwiązania klasy ERP do wymogów
Zamawiającego wraz z interfejsami wymiany danych (m.in. WebService), wspierające
realizację zadań wynikających z przedmiotu zamówienia .
Według Odwołującego z tych definicji jasno wynika, że w postępowaniu chodzi
o rozbudowę standardowego rozwiązania klasy ERP mającą na celu dostosowanie go do
wymogów Zamawiającego. To wykonawca ma dostarczyć nowe „moduły, warstwy,
Sygn. akt KIO 2439/16
funkcjonalności” adekwatne do potrzeb Zamawiającego opisanych w SIWZ. Nigdzie
Zamawiający nie narzucił, aby odbywało się to poprzez „dostarczenie przez wykonawcę
komponentu aplikacyjnego standardowego rozwiązania klasy ERP”. Wręcz odwrotnie,
w definicji Oprogramowania Aplikacyjnego wyraźnie wskazano na nowe „moduły, warstwy,
funkcjonalności”.
Ponadto Odwołujący zacytował, że przez standardowe rozwiązanie klasy ERP
Zamawiający rozumie system, który spełnia warunki z pkt 1.1 OPZ:
a) Oferowane rozwiązanie powinno posiadać interfejs aplikacji umożliwiający pracę
w środowisku Microsoft Windows w wersji 7 lub wyższej;
b) Wszystkie komponenty serwerowe oferowanego rozwiązania powinny być wykonane w 64
bitowej technologii;
c) Oferowane rozwiązanie musi umożliwiać eksploatację na platformie bazy danych MSSQL
Server 2014, którą Zamawiający zamierza przeznaczyć do realizacji zamówienia.
d) W przypadku, gdy oferowane przez Wykonawcę rozwiązanie będzie funkcjonowało
na bazie danych innej niż ta, którą Zamawiający zamierza przeznaczyć do realizacji
niniejszego zamówienia, Wykonawca zobowiązany jest zapewnić licencje bazy danych,
na nieograniczoną liczbę użytkowników, niezbędne do pełnego wdrożenia oferowanego
systemu, zgodnie z wymaganiami (OPZ).
e) Oferowane rozwiązanie musi umożliwiać integrację z oprogramowaniem biurowym MS
Office w wersji co najmniej 2007, co najmniej w zakresie importu i eksportu danych
z poziomu interfejsu użytkownika;
f) Oferowane rozwiązanie musi obsługiwać wielowalutowość;
g) Wszystkie moduły oferowanego rozwiązania w przypadku klienta desktopowego muszą
działać w ramach jednego interfejsu i jednej aplikacji klienckiej (bez konieczności
wychodzenia z jednej aplikacji i wchodzenia do drugiej);
h) Licencje dostarczone dla oferowanego rozwiązania muszą umożliwiać obsługę
nieograniczonej liczby jednostek organizacyjnych;
i) Oferowane rozwiązanie musi udostępniać w ramach opłaty licencyjnej dostęp do otwartego
kodu Oprogramowania Aplikacyjnego;
j) Oferowane rozwiązanie powinno być zbudowane w oparciu o standardowe rozwiązanie
klasy ERP, wdrażane i serwisowane przez sieć partnerską firm wdrażających, autoryzowaną
przez producenta standardowego rozwiązania klasy ERP obejmującą co najmniej 5 firm
wdrożeniowych, niezależnych kapitałowo od siebie i od producenta standardowego
rozwiązania klasy ERP;
k) Oferowane rozwiązanie powinno być zbudowane w oparciu o standardowe rozwiązanie
klasy ERP dostępne na rynku w wersji COTS (commercial off-the-shelf) przynajmniej od 10
Sygn. akt KIO 2439/16
lat, a w oferowanej wersji co najmniej rok;
l) Oferowane rozwiązanie musi być wdrażane i serwisowane w modelu umożliwiającym
realizację projektów wdrożeniowych przez co najmniej pięciu partnerów autoryzowanych
przez producenta standardowego rozwiązania klasy ERP, niezależnych kapitałowo od siebie i
od producenta standardowego rozwiązania klasy ERP;
m) Oferowane rozwiązanie nie może w żaden sposób ograniczać Zamawiającego w wyborze
przyszłego wykonawcy mogącego utrzymać rozwiązanie po zakończeniu projektu.
Odwołujący dodał, że w tym samym punkcie OPZ wskazano, że zamówienie
obejmuje:
a) Wykonanie Projektu Rozwiązania;
b) Dostawę, Instalację Systemu i Konfigurację Oprogramowania, Oprogramowania
Aplikacyjnego.
Wykonawca
dostarczy
szczegółowe
zestawienie
dostarczonego
Oprogramowania, które zostanie zawarte w Dokumentacji powykonawczej;
c) Instalację i konfigurację Oprogramowania, które Zamawiający przeznaczył do realizacji
zamówienia, a które Wykonawca wykorzysta do wykonania Rozwiązania, zgodnie z punktem
2.2 Opisu Przedmiotu Zamówienia
(...)
g) Dostosowanie Oprogramowania Aplikacyjnego do potrzeb Zamawiającego oraz
zapewnienia jego interoperacyjności zgodnie z zapisami „Opisu Przedmiotu Zamówienia”;
Wreszcie Odwołujący przybliżył, że w zakresie wymagań dotyczących licencji w pkt
11 OPZ określono, że w ramach realizacji przedmiotu zamówienia Wykonawca w zależności
od posiadanych praw zobowiązany jest do Udzielenia licencji/sublicencji na:
11.1. Oprogramowanie standardowego rozwiązania klasy ERP na użytkownika nazwanego
800 licencji z możliwością Udzielania licencji/sublicencji na innych użytkowników, wraz
z prawem do aktualizacji, nowych wersji oraz pomocy technicznej, na cały okres trwania
Umowy i na warunkach określonych przez producenta ww. Oprogramowania standardowego;
11.2. Oprogramowanie Aplikacyjne, Wykonawca zobowiązany jest do Udzielenia
licencii/sublicencii/przeniesienia praw autorskich zgodnie z zapisami Istotnych Postanowień
Umowy. Wykonawca Udzieli licencji/sublicencji na Oprogramowanie Aplikacyjne bez limitów
(użytkowników, kont, rodzaju ilości stanowisk, ilości przetwarzanych danych, z prawem
przeniesienia/powielenia na nowe/inne/te same urządzenia) na pełne korzystanie
z oferowanego Oprogramowania Aplikacyjnego;
Odwołujący wywiódł, że w SIWZ:
– występuje wielopłaszczyznowe rozróżnienie Oprogramowania i Oprogramowania
Aplikacyjnego;
– Oprogramowanie Aplikacyjne nie jest tym samym co oprogramowanie standardowe;
Sygn. akt KIO 2439/16
– w żadnym miejscu nie ma również adnotacji, że Oprogramowanie Aplikacyjne musi być
wykonane na bazie komponentu aplikacyjnego standardowego rozwiązania klasy ERP.
Odwołujący podniósł, że również wymagania dotyczące zestawu testowego
nie nawiązują do komponentu aplikacyjnego standardowego rozwiązania klasy ERP.
Odwołujący powołał się na to, że zgodnie z załącznikiem nr 3 do OPZ – Regulamin
oraz harmonogram prezentacji Systemu:
pkt 1.1 Zakres i sposób dostarczenia – odbioru zestawu testowego do prezentacji Systemu,
ppkt 3: Zestaw testowy, który Wykonawca jest zobowiązany do dołączenia do oferty musi
zawierać sprzęt niezbędny do uruchomienia wersji demonstracyjnej Systemu w postaci co
najmniej: wyłącznie 1 komputera typu notebook, na którym będzie zainstalowany system
demonstracyjny, Oprogramowania, w tym standardowego oprogramowania klasy ERP,
Oprogramowania Aplikacyjnego w wersji demonstracyjnej, nośnika danych zawierającego
obraz dysku/dysków komputera typu notebook z wygenerowany sumami kontrolnymi MD5,
wydruk zawierający wszystkie sumy kontrolne MD5 dla wszystkich plików oraz innych
komponentów niezbędnych do wykonania prezentacji;
ppkt 4 Prezentacja wersji demonstracyjnej Systemu musi być wykonana w oparciu o
standardowe rozwiązanie klasy ERP (zgodnie z opisem zawartym w OPZ) i musi być
wykonana w tej samej technologii, co System oferowany w niniejszym postępowaniu;
ppkt 6 Na zestawie testowym zainstalowane Oprogramowanie w tym standardowe
rozwiązanie klasy ERP i Oprogramowanie Aplikacyjne musi być licencjonowane. Licencja
musi umożliwiać uruchomienia i wykonanie prezentacji Systemu w okresie od złożenia oferty
do końca trwania Umowy. Oprogramowanie i Oprogramowanie Aplikacyjne musi być już
zainstalowane na komputerze z zestawu testowego, tak aby podczas przygotowania do
prezentacji oraz w jej trakcie nie były instalowane żadne komponenty Systemu.
Odwołujący zarzucił, że w świetle takich postanowień SIWZ uzasadnienie podane
przez Zamawiającego, jest całkowicie nieuprawnione, gdyż:
– Zamawiający nie może oceniać ofert z punktu widzenia bliżej nieokreślonej „praktyki” (nie
wiadomo czyjej i jakiej), lecz postanowień SIWZ;
– Zamawiający wprowadził nieistniejące na gruncie SIWZ pojęcie „komponentu
aplikacyjnego ERP” (o którym nie ma mowy w definicji Oprogramowania ani
Oprogramowania aplikacyjnego), czyli aplikacji wspierającej zarządzania finansami miasta
producenta ERP w modelu COTS, wyłącznie na potrzeby odrzucenia oferty Odwołującego;
– warstwa aplikacyjna ma dopiero powstać w ramach Oprogramowania Aplikacyjnego
realizowanego przez wykonawcę na podstawie przyszłej umowy, nie ma mowy
o komponencie aplikacyjnym ERP;
– schematy blokowe przedstawione przez Zamawiającego (mające zapewne wizualnie
Sygn. akt KIO 2439/16
oddziaływać na czytelnika i obrazowo tłumaczyć rzekomą niezgodność oferty z SIWZ) są
kompletnie oderwane od treści SIWZ i nie zasługują na jakąkolwiek uwagę;
– nigdzie w SIWZ nie ma wymogu, aby Oprogramowanie (zwłaszcza standardowy ERP)
obejmowało komponenty aplikacyjne ERP ani tym bardziej nie ma w SIWZ parametru, aby
Oprogramowanie Aplikacyjne było zrealizowane przez wykonawcę wyłącznie w obszarze
komponentu aplikacyjnego ERP.
Odwołujący podsumował, że zdecydowanie odrzucić należy tezę Zamawiającego,
jakoby przedstawiony przez Odwołującego podczas prezentacji System stanowi próbę
obejścia wymagań SIWZ i wprowadzenia w błąd Zamawiającego. Według Odwołującego
zestaw testowy został wykonany ściśle według instrukcji zawartych w SIWZ,
a Zamawiającemu zaprezentowano rozwiązanie w oparciu o „Standardowe rozwiązanie klasy
ERP” w tej samej technologii co oferowany w niniejszym postępowaniu System. Technologia
Oracle występuje zarówno w części standardowego rozwiązania klasy ERP jak
i Oprogramowania Aplikacyjnego. Odwołujący architekturę systemu wymaganego przez
Zamawiającego zgodnie zapisami SIWZ zobrazował za pomocą schematu zamieszczonego
w odwołaniu {rysunki nr 1 i 2 dot. wersji demonstracyjnej systemu Sputnik Software}.
Według odwołującego potwierdzeniem zgodności technologicznej Oprogramowania
Aplikacyjnego Oracle Forms ze Standardowym rozwiązaniem klasy ERP Oracle E-Business
Suite jest model architektury rozwiązania Oracle E-Business Suite {rys. nr 3 w odwołaniu}.
A zastosowane na potrzeby przygotowania zestawu testowego Oprogramowanie klasy ERP
na
bazie
Oracle
E-Business
Suite
jest
całkowicie
zgodne
technologicznie
z Oprogramowaniem Aplikacyjnym zainstalowanym na zestawie dołączonym do oferty.
Odwołujący dodał, że licencja Oracle E-Business Suite zawiera następujące
komponenty, które można użytkować zgodnie z wybranym modelem licencyjnym: Oracle
Forms Services (w tym Forms), Oracle Reports Services, TopLink and Application
Development Services (w tym Forms), Oracle Report Services, ToLink and Application
Development Framework, portal, Discoverer Viewer, Disovewer Plus (WEB Functionality),
IdentityManagement, Application InterConnect Toolkit, Integration and Enterprise Service
Bus, JavaSE, WebLogic Server Basic, Oracle Access Manager Basic, and Personalization.
Oracle określa rówenież, które komponenty technologiczne są zgodne licencyjnie.
Zdaniem Odwołującego zarzut Zamawiającego niezastosowania „komponentu
aplikacyjnego ERP” o nazwie „Oracle Financials”, który wchodzi w skład Oracle E-Business
Suite, jest błędny i może wynikać z nieznajomości technologii Oracle EBS. Dla lepszego
zobrazowania budowy modułowej rozwiązania Oracle E-Business Suite (spełniającego
wymagania dla standardowego rozwiązania ERP) Odwołujący zaprezentował schemat
graficzny {rys. nr 4 w odwołaniu} obejmujący następujący wykaz modułów: a) Manufacturing
Sygn. akt KIO 2439/16
(produkcja), b) Inventory (inwentaryzacja), c) Fulfillment (logistyka) d) Finacial&Asset
Management {nazywane również „Financials”} (finanse i zarządzanie aktywami),
e) Customer Service (obsługa klienta), f) Customer Relations Management (zarządzanie
relacjami z klientami), g) Sales & Order Management (zarządzanie sprzedażą
i zamówieniami), h) Procurement (dostawy), i) Business Inteligence (analityka biznesowa),
k) Custom (niestandardowy).
Odwołujący wyjaśnił, że rozwiązanie klasy ERP Oracle-E-Business Suite
w standardzie realizuje funkcjonalności związane z obsługą przedsiębiorstw na całymświecie. A z uwagi na jego pochodzenie (USA) nie ma możliwości, aby w podstawowym
pakiecie funkcjonalnym obsługiwał polskie czy inne jednostki sektora publicznego z obszaru
Unii Europejskiej. Dzięki budowie modułowej i mechanizmowi dostosowywania (za pomocą
modułów niestandardowych – w tym przypadku Oprogramowaniu Aplikacyjnemu) istnieje
możliwość dostosowania rozwiązania do potrzeb klienta docelowego. Przykładowo, aby
spełnić wymagania załącznika nr 1 do SIWZ w zakresie Oprogramowania Aplikacyjnego
dostarczane przez Sputnik rozwiązanie klasy ERP musi zostać dostosowane. Innymi słowy
muszą zostać dobudowane nowe warstwy funkcjonalne stanowiące podstawę nowych
modułów
np.
podatkowych.
Dostosowanie
może
być
realizowane
w
oparciu
o programowanie nowych fragmentów kodu na bazie technologii Oracle Forms lub
implementacji gotowych warstw funkcjonalnych. W tym przypadku będzie miało
zastosowanie obu form, co nie oznacza, że Zamawiający otrzyma tożsamy system z obecnie
wykorzystywanym, gdyż powstanie nowy produkt spełniający wszystkie wymagania
wyspecyfikowane w OPZ.
Odwołujący zarzucił ponadto, że obecnie Zamawiający, nawet wbrew swoim
wcześniejszym ocenom, próbuje narzucić nieadekwatne do treści tej specyfikacji wymagania.
Odwołujący zrelacjonował, że poprzednio Zamawiający odrzucił jego ofertę m.in.
z tego powodu, że Wykonawca nie dysponuje wszystkimi komponentami zaoferowanego
Rozwiązania, ponieważ nie jest ich producentem, imputując nawet, że na zestawie testowym
zostało zainstalowane nielegalne oprogramowanie. Natomiast obecnie Zamawiający twierdzi,że w toku prezentacji zobaczył system niemalże identyczny z aktualnie eksploatowanym
systemem w Urzędzie Miasta Łodzi tj. ZSJ Magistrat 2000.
W tych okolicznościach Odwołującego zastanawiają dwa zagadnienia. Po pierwsze,
skoro Zamawiający 1 czerwca 2016 r. rzekomo zobaczył należący do Odwołującego system
ZSI Magistrat 2000, na jakiej podstawie zarzucił Odwołującemu że zainstalowane
oprogramowanie, w tym Oprogramowanie Aplikacyjne nie jest licencjonowane? Po drugie,
jeśli Zamawiającemu został zaprezentowany ZSI Magistrat 2000, który aktualnie użytkuje,
dlaczego w toku oceny ofert przyznał Odwołującemu tylko 2 punkty w kryterium „SGSW”
Sygn. akt KIO 2439/16
i stwierdził, że zaprezentowany system (rzekomo ten sam, który użytkuje od 17 lat!) nie
realizuje większości wymaganych funkcjonalności z Obszaru budżetowo-księgowego oraz
Obszaru opłat i podatków (lub że są realizowane sprzecznie z obowiązującymi
przepisami...)?
Odwołujący dodał, że Zamawiający badał jego ofertę wszechstronnie, zarówno
w warstwie merytorycznej, jak i formalnej. Sprawdzał bardzo drobiazgowo spełnienie
każdego warunku udziału w postępowaniu, wystosował do Odwołującego kilkanaście
różnego rodzaju wezwań, aby finalnie nie stwierdzić niezgodności zestawu testowego lub
zaoferowanego Systemu z treścią SIWZ. Ponadto w toku badania ofert oraz podczas
rozprawy przed Krajową Izbą Odwoławczą Zamawiający posiłkował się ekspertami; którzy
oceniali próbkę (zestaw testowy) i nie stwierdzili jej niezgodności z treścią SIWZ .
Zdaniem Odwołującego obecne działania Zamawiającego stoją w jaskrawej
sprzeczności z jego wcześniejszymi czynnościami. Odwołującemu, patrząc przekrojowo na
przebieg postępowania, wydaje się, że celem Zamawiającego nie jest i nie była rzetelna i
obiektywna ocena ofert; lecz dokonanie wyboru oferty Konsorcjum Asseco , droższej o blisko
15 mln zł. Zamawiający uprzednio nie widział żadnej merytorycznej wady zestawu
testowego, a wręcz zarzucał, że Odwołujący nie posiada odpowiednich licencji Oracle
umożliwiających mu wykonanie takiego zestawu. W tej chwili twierdzi, że w tym zestawie
jakiegoś komponentu Oracle w ogóle nie było.
29 grudnia 2016 r. wpłynęło w formie pisemnej do Prezesa Izby zgłoszenie przez
Konsorcjum Asseco
przystąpienia
do
postępowania
odwoławczego
po
stronie
Zamawiającego
Wobec dokonania zgłoszenia w odpowiedniej formie, z zachowaniem 3-dniowego
terminu oraz wymogu przekazania jego kopii Stronom postępowania (zgodnie z art. 185 ust.
2 pzp) – Izba nie miała podstaw do stwierdzenia nieskuteczności przystąpienia, co do
którego nie zgłoszono również opozycji.
Przystępujący wniósł o oddalenie odwołania.
5 stycznia 2016 r. wpłynęła do Izby odpowiedź na odwołanie, w której Zamawiający
wniósł o jego oddalenie w całości, uzasadniając swoje stanowisko odnośnie każdego
z zarzutów.
Sygn. akt KIO 2439/16
Ponieważ odwołanie nie zawierało braków formalnych, a wpis od niego został
uiszczony – podlegało rozpoznaniu przez Izbę.
W toku czynności formalnoprawnych i sprawdzających Izba nie stwierdziła,
aby odwołanie podlegało odrzuceniu na podstawie przesłanek określonych w art. 189 ust. 2
pzp. Nie zgłaszano w tym zakresie odmiennych wniosków.
Z uwagi na brak podstaw do odrzucenia odwołania lub umorzenia postępowania
odwoławczego sprawa została skierowana do rozpoznania na rozprawie, podczas której
Odwołujący, Zamawiający i Przystępujący podtrzymali dotychczasowe stanowisko.
Po
przeprowadzeniu
rozprawy
z
udziałem
Odwołującego,
Zamawiającego
i Przystępującego, uwzględniając zgromadzony materiał dowodowy, jak również
biorąc pod uwagę oświadczenia i stanowiska zawarte w odwołaniu, dalszych pismach
z 11 i 16 stycznia 2017 r., odpowiedzi na odwołanie, dalszym piśmie z 18 stycznia
2017 r., zgłoszeniu przystąpienia i dalszych pismach z 10 i 16 stycznia 2017 r., a także
wyrażone ustnie na rozprawie i odnotowane w protokole, Izba ustaliła i zważyła, co
następuje:
Z art. 179 ust. 1 pzp wynika, że odwołującemu przysługuje legitymacja do wniesienia
odwołania, gdy ma (lub miał) interes w uzyskaniu zamówienia oraz może ponieść szkodę
w wyniku naruszenia przez zamawiającego przepisów ustawy.
W ocenie Izby Odwołujący wykazał, że ma interes w uzyskaniu przedmiotowego
zamówienia, skoro złożył ofertę, która według kryteriów oceny przyjętych w tym
postępowaniu mogłaby okazać się najkorzystniejsza. Stąd Odwołujący może ponieść szkodę
w związku z zarzucanymi Zamawiającemu naruszeniami przepisów ustawy pzp w związku
z odrzuceniem oferty Odwołującego, gdyż w przeciwnym razie mógłby liczyć na uzyskanie
przedmiotowego zamówienia.
Zostały również wzięte pod uwagę przez Izbę pozostałe pisma złożone przez
Odwołującego {pierwsze trzy wymienione.} i Przystępującego {ostatnie z wymienionych} tj:
– Ekspertyza technologiczna Oracle E-Business Suite 12 z 19 grudnia 2016 r. autorstwa
J.N., pracownika Oracle Polska sp. z o.o. z siedzibą w Warszawie {która została w całości
inkorporowana do treści odwołania};
– Ekspertyza. Ocena zgodności oferty firmy Sputnik sp. z o.o. na „dostawę i wdrożenie
Sygn. akt KIO 2439/16
systemu informatycznego wspomagającego zarządzanie finansami Miasta… z 10 stycznia
2017 r. autorstwa mgr. Inż. A.K. {dalej: „Ekspertyza A. K.”};
– Wykonanie ekspertyzy w zakresie zgodności oferty firmy Sputnik Software Sp. z o.o.
z wymaganiami
przetargu
na
dostawę
i
wdrożenie
systemu
informatycznego
wspomagającego zarządzanie finansami Miasta… z 10 stycznia 2017 r. Instytutu Automatyki
i Robotyki Politechniki Warszawskiej autorstwa prof. dr. hab. inż. R.P. {dalej: „Ekspertyza
PW”};
– Opinia ekspercka dotycząca postępowania o udzielenie zamówienia na „Dostawę
i wdrożenie systemu informatycznego wspomagającego zarządzanie finansami Miasta”…
z 13 stycznia 2017 r. autorstwa dr hab. inż. A.Z. {dalej: „Ekspertyza A. Z.”}.
Izba zaznacza, że ponieważ w postępowaniu odwoławczym nie zgłoszono wniosku
o przeprowadzenie dowodu z opinii biegłego ani Izba nie uznała za konieczne dopuszczenie
takiego dowodu z urzędu, powyższe pisma zostały uznane li tylko za uszczegółowienie
stanowisk Odwołującego i Przystępującego, a nie za dowód na poparcie ich twierdzeń.
W ocenie Izby odmienny status ma Wykonanie ekspertyzy w zakresie oceny
zgodności zaprezentowanej przez firmę Sputnik próbki w ramach testów gotowości systemu
a zaoferowanym rozwiązaniem Oracle E-Business Suite (EBS) w wersji 12 Wydziału
Elektromechaniki i Informatyki Politechniki Rzeszowskiej z 21 listopada 2016 r. autorstwa dr.
inż. M.N. {dalej: „Ekspertyza PR”}, na którą powołano się w uzasadnieniu odrzucenia oferty
Sputnika, gdyż zgodnie z art. 21 ust. 4 pzp jeżeli dokonanie określonych czynności
związanych z przygotowaniem lub przeprowadzeniem postępowania o udzielenie
zamówienia wymaga wiadomości specjalnych, kierownik zamawiającego, z własnej
inicjatywy lub na wniosek komisji przetargowej, może powołać biegłych, a zatem podlega
ona ocenie jako materiał dowodowy.
Izba uznała za spóźnione i bezprzedmiotowe zgłoszone dopiero na rozprawie przez
Odwołującego zastrzeżenia odnośnie bezstronności Politechniki Rzeszowskiej. Po pierwsze
– termin na zgłoszenie tego typu zarzutu upłynął wraz z terminem na wniesienie odwołania.
Po drugie – wywodzenie rzekomego barku bezstronności z informacji prasowych oraz
zamieszczonych na stronach internetowych zainteresowanych instytucji dotyczącej
współpracy Politechniki Rzeszowskiej z Asseco Poland, jest nieudowodnioną spekulacją.
{rozstrzygnięcie zarzutów z pkt 2. listy zarzutów}
Izba ustaliła poniższe okoliczności jako istotne dla rozstrzygnięcia.
W odniesieniu do rozumienia użytego w s.i.w.z. terminu „Standardowe rozwiązanie
Sygn. akt KIO 2439/16
klasy ERP”:
– Określenie klasy systemów informatycznych służących wspomaganiu zarządzania
przedsiębiorstwem w różnych obszarach biznesu. System ten składa się zawsze z wielu
komponentów aplikacyjnych (…) wśród standardowych komponentów aplikacyjnych
wyróżnia się chociażby: obsługę klientów, produkcję, finanse i księgowość, zarządzanie
zasobami ludzkimi, zaopatrzenie. {odpowiedź na odwołanie, str. 2}.
– (…) w powszechnym rozumieniu oznacza standardowe rozwiązania, zaszyte w pakiecie
zintegrowanego <oprogramowania> służącego do zarządzania zasobami organizacji, bez
wskazywania na jej charakter i specyfikę działalności. (…) Cechą wspólną dla wszystkich
systemów ERP jest podział <oprogramowania> na moduły funkcjonalne, wspólne struktury
danych dla różnych modułów, oraz ujednolicona logika przechowywania, dostępu,
przetwarzania i prezentacji danych, (…) W rozumieniu powszechnym pojęcie (…) nie
obejmuje efektów „dostosowania” ani „rozbudowy” (przykładowo o nowe moduły, warstwy,
funkcjonalności). {Ekspertyza A. K., str. 6}
– (…) w świetle teorii i praktyki systemów ERP może jedynie oznaczać, że jest to system: I)
oparty na podejściu procesowym do zarządzania organizacją ; II) (...) który zapewnia
integrację funkcji i danych organizacji; III) umożliwia standaryzację funkcji i wzorów
z najlepszymi wzorcami dostępnymi w biznesie. {Ekspertyza PW, str. 3}
– Oznacza system informatyczny służący do prowadzenia wszelkich ewidencji związanych
z działalnością firmy (rachunkowość finansowa i zarządcza, rozrachunki z kontrahentami,
kadry, płace, produkcje, nieruchomości i in.), wspierający realizację związanych z tymi
ewidencjami
procesów
biznesowych,
pozwalający
jednocześnie
na
planowanie
i raportowanie w zakresie objętym zakresem systemu. Cechą charakterystyczną systemów
ERP jest integracja w ramach jednego systemu wszystkich danych opisujących całą
działalność przedsiębiorstwa z tego powodu systemy tej klasy bywają nazywane
zintegrowanymi. {Ekspertyza A. Z., str. 14}
Reasumując innymi słowy, niesporne pomiędzy uczestnikami postępowania
odwoławczego było, że „standardowe rozwiązanie klasy ERP” to określenie dotyczące
systemów informatycznych służących wspomaganiu zarządzania przedsiębiorstwem
(organizacją), w tym optymalizacji wykorzystania zasobów przedsiębiorstwa (organizacji)
oraz zachodzących w nim procesów, dzięki gromadzeniu danych oraz umożliwieniu
wykonywania, co realizowane jest w oparciu o bazę danych, z której korzystają
poszczególne moduły aplikacyjne (tzw. komponenty aplikacyjne wg terminologii
z uzasadnienia odwołania), obejmujące poszczególne obszary działalności przedsiębiorstwa
(organizacji).
Sygn. akt KIO 2439/16
Na poziomie najbardziej ogólnym według specyfikacji przedmiot tego zamówienia
obejmuje dostawę, wdrożenie i dostosowanie do potrzeb Zamawiającego, uruchomienie oraz
serwis gwarancyjny i usługi asysty technicznej rozumianego w powyższy sposób
standardowego rozwiązania klasy ERP (Enterprise Resource Planning) wspierającego
zarządzanie finansami miasta, czyli uzyskanie docelowego Rozwiązania (rozumianego jako
System funkcjonujący na infrastrukturze teleinformatycznej Zamawiającego), czyli
wdrożonego Systemu (obejmującego wszystkie przewidziane umową dostarczone,
zainstalowane, zintegrowane i wdrożone Produkty (Oprogramowanie, Oprogramowanie
Aplikacyjne, Dokumentacja, Kody źródłowe oraz inne elementy dostarczone przez
wykonawcę w celu realizacji Rozwiązania) {pkt 1 załącznika nr 1 do s.i.w.z., pkt 1.1 Ogólny
Opis Przedmiotu Zamówienia… in principio oraz pkt 1.2 Przyjęte definicje załącznika nr 1 do
OPZ}
Przy czym Zamawiający wskazał również {w pkt 1.1 lit. j), k) oraz l) załącznika nr 1 do
OPZ }, że takie standardowe rozwiązanie klasy ERP oznacza w szczególności, że jest:
– ono wdrażane i serwisowane przez sieć partnerską firm wdrażających, autoryzowaną przez
producenta standardowego rozwiązania klasy ERP, obejmującą co najmniej 5 firm
wdrożeniowych, niezależnych kapitałowo od siebie i od producenta standardowego
rozwiązania klasy ERP;
– dostępne na rynku w wersji COTS (commercial off-the-shelf) przynajmniej od 10 lat, a
w oferowanej wersji co najmniej rok;
– możliwe jego wdrażane i serwisowane w modelu umożliwiającym realizację projektów
wdrożeniowych przez co najmniej pięciu partnerów autoryzowanych przez producenta
standardowego rozwiązania klasy ERP, niezależnych kapitałowo od siebie i od producenta
standardowego rozwiązania klasy ERP.
Z kolei Oprogramowanie Aplikacyjne obejmuje wykonane przez wykonawcę
rozbudowy (począwszy od dodanych funkcjonalności, warstw aż do nowych modułów) tak
rozumianego standardowego rozwiązania klasy ERP, mające na celu jego dostosowanie
do wymogów Zamawiającego {wg definicji podanej w pkt 1.2 załącznika nr 1 do OPZ}, czyli
specyfiki działalności Zamawiającego, której nie uwzględniają występujące w standardowym
rozwiązaniu klasy ERP moduły (komponenty) aplikacyjne.
Zamawiający w prowadzonym postępowaniu wymagał od wykonawców, oprócz
złożenia pisemnej oferty, dołączenia do niej zestawu testowego z zainstalowaną wersją
demonstracyjną Systemu, w tym standardowym oprogramowaniem klasy ERP oraz
Oprogramowaniem Aplikacyjnym, służącego przeprowadzeniu prezentacji Systemu według
scenariuszy testowych (dla obszarów: budżetowo-księgowego oraz opłat i podatków), w celu
Sygn. akt KIO 2439/16
weryfikacji stopnia jego gotowości do wdrożenia, stanowiącego jedno z kryteriów oceny ofert
o wadze 40% {pkt 10.11.2.1-10.11.2.2 s.i.w.z.; załącznik nr 3 do OPZ – Regulamin oraz
harmonogram prezentacji Systemu pkt 1-2; załącznik nr 4 do OPZ; pkt 13.7 s.i.w.z.}.
Zamawiający podkreślił dodatkowo, że prezentacja wersji demonstracyjnej Systemu
musi być wykonana w oparciu o standardowe rozwiązanie klasy ERP (zgodnie z opisem
zawartym w OPZ) i musi być wykonana w tej samej technologii, co oferowany System {pkt
10.11.2.2 s.i.w.z.; pkt 2 załącznika nr 3 do OPZ}.
Standardowe rozwiązanie klasy ERP produkowane przez Oracle o nazwie
E-Bussines Suite w wersji 12 w swej standardowej postaci, tj. takiej, w jakiej producent
udostępnia i wprowadza je do obrotu rynkowego, zawiera następujące moduły (komponenty)
aplikacyjne, które jednocześnie wyznaczają zakres dziedzinowy zastosowania tego
rozwiązania standardowego: a) Manufacturing (produkcja), b) Inventory (inwentaryzacja), c)
Fulfillment (logistyka) d) Finacial&Asset Management {nazywane również „Financials”}
(finanse i zarządzanie aktywami), e) Customer Service (obsługa klienta), f) Customer
Relations Management (zarządzanie relacjami z klientami), g) Sales & Order Management
(zarządzanie sprzedażą i zamówieniami), h) Procurement (dostawy), i) Business Inteligence
(analityka biznesowa), k) Custom (interfejs na dołączanie modułów niestandardowych)
{odwołanie, str. 12; Ekspertyza A. K., str. 7.; odpowiedź na odwołanie, str. 4}
Systemy ERP innych producentów obejmują bardzo podobny zakres dziedzinowy.
Różnice polegają na sposobach implementacji procesów biznesowych, struktur danych,
funkcjonalności i zastosowanych sposobów pararametryzacji i narzędzi do kastomizacji
rozwiązań. {Ekspertyza A. K., str. 7}
Oracle Financials jest centralnym miejscem w aplikacjach Oracle, w którym następuje
obsługa finansowa następujących obszarów funkcjonalnych: księgi głównej, należności,
zobowiązań, środków pieniężnych, środków trwałych i kas gotówkowych. Przy czym owo
rozwiązanie finansowe Oracle jest zgodne z prawodawstwem polskim, szczególnie
w zakresie ustawy o rachunkowości, ustaw podatkowych i ustawy o ochronie danych
osobowych {str. 3 i 9 Oracle E-Business Suite. Oracle Financials. Opis funkcjonalności
produktu.}
Oracle E-Bussines Suite 12 oparte jest m.in. na technologii Oracle Forms, czyli
oprogramowaniu narzędziowym, za pomocą którego zostały utworzone ekrany systemu
i które umożliwia tworzenie funkcjonalnych modułów aplikacyjnych {odwołanie, str. 10-11;
oświadczenie Oracle Polska sp. z o.o. z 20 września 2016 r.; pismo Zamawiającego z 18
stycznia 2017 r., str. 3; pisma Przystępującego z 10 i 16 stycznia 2017 r., odpowiednio pkt 7 i
II.2}
Sygn. akt KIO 2439/16
Oracle uznaje tworzenie nowych modułów z wykorzystaniem technologii Oracle
Forms jako mieszczące się w ramach tzw. Platformy E-Business Suite 12, a nie jako element
standardowego rozwiązania klasy ERP Oracle E-Business Suite 12 {oświadczenie Oracle
Polska sp. z o.o. z 20 września 2016 r.}
Niesporne jest, że zestaw testowy załączony do oferty Sputnika nie obejmowałżadnego z modułów (komponentów) aplikacyjnych wchodzących w skład Oracle E-Bussines
Suite sprzedawanego jako COTS, w szczególności Oracle Financials, a całość funkcji
objętych prezentacją realizowana była przez wykonane w ramach Oprogramowania
Aplikacyjnego moduły własne Sputnika zaprogramowane od podstaw z wykorzystaniem
technologii Oracle Forms.
Sputnik nie deklaruje również wykorzystania gotowych modułów aplikacyjnych Oracle
E-Bussines Suite w oferowanym docelowym Systemie, gdyż uważa, że w żadnym
postanowieniu SIWZ nie ma obowiązku wykonania zestawu testowego lub Systemu
z wykorzystaniem „komponentu aplikacyjnego standardowego rozwiązania klasy ERP” {fraza
pogrubiona na str. 3 odwołania}.
Reasumując, Izba stwierdziła, co następuje:
– Skoro niesporne w postępowaniu odwoławczym było, że standardowe rozwiązanie klasy
ERP produkcji Oracle o nazwie E-Bussines Suite 12 dostępne jako oprogramowanie COTS
zawiera moduły aplikacyjne wyznaczające zakres jego możliwego zastosowania, w tym
w odniesieniu do zarządzania finansami moduł Oracle Financials {powyżej nazywany
również Finacial&Asset Management}, nie można jednocześnie twierdzić, że bez tego typu
modułów nadal stanowi „standardowe rozwiązanie klasy ERP”, gdyż w takiej okrojonej
postaci jest ono niekompletne i nie spełnia żadnych funkcji, do których jest przeznaczone,
a zatem nie wspiera również zarządzania finansami.
– Rozwiązanie zaprezentowane i oferowane przez Sputnik, w którym zamiast standardowych
modułów aplikacyjnych Oracle E-Bussines Suite 12 są wyłącznie moduły zaprogramowane
od podstaw przez Sputnika z użyciem technologii Oracle Forms, nie odpowiada treści opisu
przedmiotu zamówienia s.i.w.z. obowiązującej w tym postępowaniu, gdyż zamiast wykonania
rozbudowy Oracle E-Bussines Suite 12, czyli standardowego rozwiązania klasy ERP,
o niewystępujące w nim funkcjonalności wymagane przez Zamawiającego, dzięki
zaprogramowaniu nowych funkcjonalności, warstw lub nowych modułów, oferuje zastąpienie
wszystkich istniejących standardowych modułów własnymi, wykonanymi według tej samej
technologii w oparciu o tzw. platformę Oracle E-Bussines Suite 12.
Ponadto Izba stwierdziła, że w zawiadomieniu przekazanym Sputnikowi Zamawiający
Sygn. akt KIO 2439/16
zawarł uzasadnienie odrzucenia oferty, które uwzględniało powyżej ustalone okoliczności.
Obszerne uzasadnienie faktyczne z użyciem terminu „komponent aplikacyjny” oraz
diagramów służyło jak najdokładniejszemu wyjaśnieniu stwierdzonej adekwatnie przez
Zamawiającego niezgodności zestawu testowego z oferty Sputnika z treścią postanowień
s.i.w.z.
W tych okolicznościach Izba stwierdziła, że odwołanie jest niezasadne
Odwołujący bezpodstawnie domaga się uchylenia odrzucenia jego oferty
na podstawie art. 89 ust. 1 pkt 2 pzp, gdyż odwołanie opiera się na wybiórczej interpretacji
postanowień opisu przedmiotu zamówienia, w szczególności definicji Oprogramowania
Aplikacyjnego, przy jednoczesnym zanegowaniu, że wymagane było zaoferowanie Systemu,
który będzie opierał się na standardowym rozwiązaniu klasy ERP jako oprogramowaniu
COTS rozbudowanym przez wykonawcę zamówienia jedynie w niezbędnym zakresie.
Odwołujący, wbrew treści opisu przedmiotu zamówienia, sprowadza rozumienie
„standardowego rozwiązania klasy ERP” do wymogu wykonania przez wykonawcę
zamówienia modułów aplikacyjnych w oparciu o to samo oprogramowanie narzędziowe co
standardowe moduły aplikacyjne producenta tego rozwiązania służące wsparciu dziedzin
działalności objętej przedmiotem zamówienia.
Skład orzekający Izby podziela utrwalony w doktrynie i orzecznictwie pogląd,że zarówno treść s.i.w.z., jak i treść oferty stanowią merytoryczne postanowienia oświadczeń
woli odpowiednio: zamawiającego, który w szczególności przez opis przedmiotu zamówienia
precyzuje, 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. Wobec tego – co do zasady –
porównanie zaoferowanego przez wykonawcę świadczenia z opisem przedmiotu
zamówienia, sposobem i terminem jego realizacji wymaganymi przez zamawiającego,
przesądza o tym, czy treść złożonej oferty odpowiada treści s.i.w.z. – jest z nią zgodna.
Aby zapewnić możliwość sprawdzenia zgodności treści oferty z treścią s.i.w.z.,
ustawa pzp z jednej strony obliguje zamawiającego, aby prowadził całe postępowanie
o udzielenie zamówienia w formie pisemnej (art. 9 ust. 1 pzp), w tym przekazał i udostępnił
specyfikację istotnych warunków zamówienia (art. 37 ust. 1 i 2 pzp), która ma zawierać
w szczególności opis przedmiotu zamówienia, określenie terminu wykonania zamówienia,
istotne warunki umowy w sprawie zamówienia publicznego oraz opis sposobu przygotowania
ofert (art. 36 ust. 1 pkt 3, 4, 16 i 10 pzp). Z drugiej strony art. 82 ust. 2 pzp zastrzega
Sygn. akt KIO 2439/16
dla oferty składanej przez wykonawcę w postępowaniu o udzielenie zamówienia publicznego
formę pisemną pod rygorem nieważności, a w art. 82 ust. 3 pzp wprost wskazuje, że treść
takiej oferty musi odpowiadać treści specyfikacji.
W doktrynie i orzecznictwie przyjmuje się również, że rozumienie terminu oferta
należy opierać na art. 66 § 1 Kodeksu cywilnego, zgodnie z którym jest nią oświadczenie
drugiej stronie woli zawarcia umowy, jeżeli określa istotne postanowienia tej umowy. Z uwagi
na odpłatny charakter zamówień publicznych, nieodzownym elementem treści oferty będzie
zawsze określenie ceny za jaką wykonawca zobowiązuje się wykonać zamawianeświadczenie. W pozostałym zakresie to zamawiający określa w s.i.w.z. wymagany
od wykonawcy zakres i sposób konkretyzacji oświadczenia woli, który będzie podstawą dla
oceny zgodności treści złożonej oferty z merytorycznymi wymaganiami opisu przedmiotu
zamówienia.
W konsekwencji nie tylko treść wynikająca explicite ze złożonej oferty, ale również
nieskonkretyzowanie jej treści przez wykonawcę w sposób lub w zakresie wymaganym przez
zamawiającego, może być podstawą do stwierdzenia niezgodności oferty z treścią s.i.w.z.,
gdyż – co do zasady – niedopuszczalne jest precyzowanie i poprawianie treści złożonej
oferty, w szczególności z uwagi za naczelne zasady równego traktowania wykonawców
i zachowania uczciwej konkurencji.
W zakresie zastosowania przesłanki odrzucenia oferty z art. 89 ust. 1 pkt 2 pzp
mieści się bowiem również sporządzenie oferty w inny sposób, niż żądał tego zamawiający,
o ile niezgodność taka dotyczy elementów treści oferty w aspekcie formalnym i materialnym,
choć nie może tu chodzić wyłącznie o niezgodność sposobu spełnienia tych aspektów {por.
J. Pieróg w: Prawo zamówień Publicznych. Komentarz, wyd. C.H. Beck, Warszawa 2009}.
Innymi słowy niezgodność treści oferty z treścią s.i.w.z. może polegać na sporządzeniu
i przedstawieniu oferty w sposób niezgodny z wymaganiami specyfikacji, z zaznaczeniem,że chodzi tu o wymagania s.i.w.z. dotyczące sposobu wyrażenia, opisania i potwierdzenia
zobowiązania (świadczenia) ofertowego, a więc wymagania, co do treści oferty, a nie
wymagania co do jej formy, które również zamieszczane są w s.i.w.z. {por. np. uzasadnienie
wyroku Izby z 13 listopada 2013 r., sygn. akt KIO 2478/13}.
W ramach wymaganego od wykonawcy sposobu potwierdzenia treści oferty mieści
się również oparte na art. 25 ust. 1 pkt 2 pzp żądanie przez zamawiającego oświadczeń lub
dokumentów potwierdzających spełnianie jego wymagań (określonych w s.i.w.z.) przez
oferowane dostawy, usługi lub roboty budowlane. Niezamknięty katalog tych dokumentów
został określony w § 6 rozporządzenia Prezesa Rady Ministrów z dnia 19 lutego 2013 r.
w sprawie rodzajów dokumentów, jakich może żądać zamawiający od wykonawcy, oraz form,
w jakich te dokumenty mogą być składane (Dz. U. poz. 231; dalej również: „rozporządzenie
Sygn. akt KIO 2439/16
o dokumentach”). Dokumenty te należy rozpatrywać jako kwalifikowaną formę potwierdzenia
zgodności oferowanego świadczenia z wymaganym przez zamawiającego. Zadeklarowana
przez wykonawcę treść oferty ma bowiem dodatkowo znaleźć potwierdzenie w dokumentach
co do zasady pochodzących od niezależnego od wykonawcy podmiotu zewnętrznego
(co wprost wskazano przy określeniu rodzaju dokumentów wyliczonych w § 6 ust. 1 pkt 2 - 4
rozporządzenia), względnie w próbkach, opisach lub fotografiach produktów, które mają być
dostarczone, których autentyczność musi być poświadczona przez wykonawcę na żądanie
zamawiającego (rodzaje środków dowodowych wymienione w § 6 ust. 1 pkt 1
rozporządzenia).
W konsekwencji brak takiego kwalifikowanego potwierdzenia również jest podstawą
do odrzucenia oferty jako niezgodnej z treścią s.i.w.z., co przejawia się zarówno w aspekcie
formalnym – niezgodności z postanowieniem formułującym żądanie złożenia takich
dokumentów, jak i przede wszystkim materialnym – niewykazaniu zgodności oferowanych
produktów z wymaganiami zamawiającego w zakresie parametrów, które miały znaleźć
potwierdzenie w tych dokumentach. Resumując, jak trafnie zauważono w uzasadnieniu
wyroku Izby z 16 października 2012 r. (sygn. akt KIO 2162/12), konsekwencją
nieuzupełnienia dokumentu przedmiotowego (innego niż potwierdzającego spełnienie
warunku udziału w postępowaniu) jest konieczność odrzucenia oferty na podstawie art. 89
ust. 1 pkt 2 ustawy pzp jako nieodpowiadającej treści specyfikacji.
Niezależnie od charakteru niezgodności, aby zastosować podstawę odrzucenia oferty
z art. 89 ust. 1 pkt 2 pzp musi być możliwe uchwycenie na czym konkretnie taka niezgodność
polega, czyli co i w jaki sposób w ofercie nie jest zgodne z konkretnie wskazanymi,
skwantyfikowanymi i ustalonymi jednoznacznie postanowieniami s.i.w.z. W odniesieniu do
dokumentów, o których mowa w art. 25 ust. 1 pkt 2 pzp, oznacza to konieczność
zidentyfikowania parametru oferowanego produktu, który nie znalazł w nich kwalifikowanego
potwierdzenia, pomimo że w ofercie został zadeklarowany przez wykonawcę jako zgodny z
parametrem wymaganym według opisu przedmiotu zamówienia.
Zgodnie z art. 87 ust. 1 pzp w toku badania i oceny ofert zamawiający może żądać od
wykonawców wyjaśnień dotyczących treści złożonych ofert. Niedopuszczalne jest
prowadzenie między zamawiającym a wykonawcą negocjacji dotyczących złożonej oferty
oraz z zastrzeżeniem ust. 1a i 2 pzp, dokonywanie jakiejkolwiek zmiany w jej treści.
Z wyjątkiem trybu dialogu konkurencyjnego zmiany te sprowadzają się to do wspominanej
powyżej instytucji poprawienia omyłek polegających na niezgodności oferty ze specyfikacją,
co nie może jednak powodować istotnej zmiany treści oferty.
Z kolei z art. 26 ust. 3 pzp wynika, że zamawiający wzywa wykonawców, którzy
w określonym terminie nie złożyli wymaganych przez niego oświadczeń lub dokumentów,
Sygn. akt KIO 2439/16
o których mowa w art. 25 ust. 1 pkt 2 pzp, lub którzy złożyli takie dokumenty zawierające
błędy, do ich złożenia w wyznaczonym terminie. Złożone na wezwanie zamawiającego
oświadczenia i dokumenty powinny potwierdzać spełnianie przez oferowane dostawy, usługi
lub roboty budowlane wymagań określonych przez zamawiającego, nie później niż w dniu,
w którym upłynął termin składania ofert.
Ponadto zamawiający może w odniesieniu do złożonych pierwotnie lub uzupełnionych
dokumentów zażądać od wykonawcy wyjaśnień w trybie art. 26 ust. 4 pzp. Oczywiste jest,że instytucja ta służy wyjaśnieniu niezrozumiałej dla zamawiającego treści dokumentu,
w szczególności ustaleniu gdzie znajduje się informacja potwierdzająca spełnianie wymagań,
a nie zmianie treści dokumentu, co jest możliwe w trybie art. 26 ust. 3 pzp. Jak trafnie
zauważono w uzasadnieniu wyroku Izby z 13 września 2010 r. (sygn. akt KIO 1863/10) nie
można wyjaśnieniami przywrócić sobie możliwości ponownego uzupełnienia wadliwie
złożonego dokumentu.
Wystąpienie stanu niezgodności treści oferty z treścią s.i.w.z. nie zawsze będzie to
podstawą do odrzucenia oferty, gdyż art. 89 ust. 1 pkt 2 pzp wprost odsyła do art. 87 ust. 2
pkt 3 pzp. Odrzuceniu podlega zatem wyłącznie oferta, której treść jest niezgodna z treścią
s.i.w.z. w sposób zasadniczy i nieusuwalny, gdyż obowiązkiem zamawiającego jest
poprawienie w złożonej ofercie niezgodności z s.i.w.z. niemających istotnego charakteru.
O ile każdorazowo treść oświadczenia woli składanego w postępowaniu w ramach
oferty należy rozpatrywać przez pryzmat zamiaru wykonawcy, wyrażającego się wolą
uczestnictwa w postępowaniu, a w konsekwencji – złożenia oferty zgodnej z s.i.w.z. {tak
m.in. wyroki Izby wydane: 3 kwietnia 2012 r. (sygn. akt KIO 556/12), 9 listopada 2012 r.
(sygn. akt: KIO 2343/12, KIO 2346/12), 22 listopada 2012 r. (sygn. akt: KIO 2396/12, KIO
2416/13), 10 czerwca 2013 r. (sygn. akt KIO 1266/13)} – o tyle kluczową sprawą jest, czy
w konkretnym stanie faktycznym możliwe jest ustalenie treści oświadczenia co do
oferowanego przedmiotu w sposób nie naruszający nadrzędnej zasady zachowania uczciwej
konkurencji pomiędzy wykonawcami. Ustawa Prawo zamówień publicznych przewiduje
instrumenty służące odczytaniu treści złożonego oświadczenia woli – jeśli jest ono
niejednoznaczne {instytucja wyjaśnień z art. 87 ust. 1 pzp}, a także służące poprawieniu
oferty – jeśli wprost nie odpowiada ona treści s.i.w.z. {instytucja poprawiania omyłek z art. 87
ust. 2 pkt 3 pzp}. Art.87 ust. 2 pkt 1 i 2 pzp obliguje natomiast zamawiającego do
poprawienia w ofercie oczywistych omyłek pisarskich oraz oczywistych omyłek
rachunkowych, z uwzględnieniem konsekwencji rachunkowych dokonanych poprawek.
W postępowaniu o zamówienie publiczne nie została bowiem wyłączona ogólna,
charakterystyczna dla prawa cywilnego zasada ustalania treści złożonego oświadczenia woli
w sposób odzwierciedlający zamiar strony i cel złożenia oświadczenia.
Sygn. akt KIO 2439/16
Jednakże istotne elementy tego oświadczenia woli – jak skonkretyzowany w sposób
wymagany przez Zamawiającego przedmiot oferowanego świadczenia – powinny się jednak
w ofercie znaleźć, w przeciwnym razie nie sposób ustalić treści tego oświadczenia bez jego
istotnej zmiany lub prowadzenia ustaleń z wykonawcą już po terminie składania ofert, co jest
niedopuszczalne na mocy klauzuli zawartej w art. 87 ust. 1 zd. 2 pzp. Zgodnie z art. 87 ust. 1
pzp w toku badania i oceny ofert zamawiający może żądać od wykonawców wyjaśnień
dotyczących treści złożonych ofert, jednakże niedopuszczalne jest prowadzenie między
zamawiającym a wykonawcą negocjacji dotyczących złożonej oferty oraz, z zastrzeżeniem
ust. 2, dokonywanie jakiejkolwiek zmiany w jej treści. Przywołane powyżej instytucje służą
jak najwierniejszemu odtworzeniu intencji wykonawcy w zakresie złożonego zamawiającemu
oświadczenia woli, odczytaniu jego treści. Zastosowanie tych instrumentów jest jednak
możliwe wtedy, gdy wykonawca w swojej ofercie wyartykułował oświadczenie woli w sposób
umożliwiający takie odczytanie bezpośrednio lub pośrednio, choćby przez pryzmat
załączonych do oferty dokumentów składanych na potwierdzenie, że przedmiot oferty
odpowiada wymaganiom zamawiającego.
Reasumując, przywołane powyżej instytucje służą jak najwierniejszemu odtworzeniu
intencji wykonawcy w zakresie złożonego zamawiającemu oświadczenia woli, odczytaniu
jego treści. Jednakże zastosowanie tych instrumentów jest możliwe tylko wtedy, gdy
wykonawca w swojej ofercie wyartykułował oświadczenie woli w sposób umożliwiający takie
odczytanie bezpośrednio lub pośrednio, choćby przez pryzmat załączonych do oferty
dokumentów składanych na potwierdzenie, że przedmiot oferty odpowiada wymaganiom
zamawiającego.
Zdaniem Izby w tej sprawie oferta Sputnika jest niezgodna z opisem przedmiotu
zamówienia w zasadniczy i nieodwracalny sposób, stąd nawet przy wykorzystaniu
powyższych instrumentów nie da się uzyskać stanu zgodności jej treści z treścią s.i.w.z.
W szczególności ponieważ zestaw testowy stanowił w tym przypadku część treści oferty
podlegającej ocenie, niemożliwe jest jego uzupełnienie lub zmiana na inny, gdyż
prowadziłoby to niedopuszczalnej zmiany treści oferty po upływie terminu składania ofert.
{rozstrzygnięcie zarzutów z pkt 1. i 3. listy zarzutów}
Ponieważ zarzut z pkt 1 listy zarzutów ma charakter niesamoistny, gdyż jeżeli nie
naruszono art. 89 ust. 1 pkt 2 pzp, nie mogło dojść do naruszenia art. 91 ust. 1 pzp, jest on
również niezasadny.
W odniesieniu do naruszenia art. 7 ust. 1 pzp, co do którego w uzasadnieniu
Sygn. akt KIO 2439/16
odwołania nie podano żadnych odrębnych okoliczności, uniemożliwia odrębne rozpoznanie
tak sformułowanego zarzutu.
Mając powyższe na uwadze, Izba – działając na podstawie art. 192 ust. 1 i 2 ustawy
pzp – orzekła, jak w pkt 1 sentencji.
O kosztach postępowania odwoławczego orzeczono stosownie do jego wyniku
na podstawie art. 192 ust. 9 i 10 ustawy pzp w zw. z § 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 (Dz. U. Nr 41, poz. 238) – obciążając Odwołującego kosztami tego postępowania,
na które złożył się uiszczony przez niego wpis.
Przewodniczący:
………………………………
………………………………
………………………………
1. Oddala odwołanie.
2. Kosztami postępowania obciąża Sputnik Software sp. z o.o. z siedzibą w Poznaniu
i zalicza w poczet kosztów postępowania odwoławczego kwotę
15000 zł 00 gr (słownie:
piętnaście tysięcy złotych zero groszy) uiszczoną przez powyższego
odwołującego
tytułem wpisu od odwołania.
Sygn. akt KIO 2439/16
Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. – Prawo zamówień
publicznych (t.j. Dz. U. z 2015 r. poz. 2164 ze zm.) 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 Łodzi.
Przewodniczący:
………………………………
………………………………
………………………………
Sygn. akt KIO 2439/16
U z a s a d n i e n i e
Zamawiający – Miasto Łódź – prowadzi na podstawie ustawy z dnia 29 stycznia
2004 r. – Prawo zamówień publicznych (t.j. Dz. U. z 2015 r. poz. 2164 ze zm.) {dalej również:
„ustawa pzp”, „pzp”} w trybie przetargu nieograniczonego postępowanie o udzielenie
zamówienia publicznego na dostawy pn. Dostawa i wdrożenie systemu informatycznego
wspomagającego
zarządzanie
finansami
Miasta
(nr
postępowania
DOA-ZP-
VIII.271.71.2015).
Ogłoszenie o tym zamówieniu zostało zamieszczone w Dzienniku Urzędowym Unii
Europejskiej nr 2016/S_047-078958 z 29 stycznia 2016 r., w tym samym dniu Zamawiający
zamieścił ogłoszenie o zamówieniu w swojej siedzibie oraz na swojej stronie internetowej
{http://przetargi.bip.uml.lodz.pl}, na której również od tego dnia udostępnił specyfikację
istotnych warunków zamówienia {dalej również: „specyfikacja” , „SIWZ” lub „s.i.w.z.”}.
Ustalona przez Zamawiającego wartość zamówienia przekracza kwoty, których mowa
w przepisach wydanych na podstawie art. 11 ust. 8 pzp.
14 grudnia 2016 r. Zamawiający przesłał drogą elektroniczną Odwołującemu –
Sputnik Software sp. z o.o. z siedzibą w Poznaniu {dalej również: „Sputnik”} – zawiadomienie
o wyborze jako najkorzystniejszej oferty złożonej przez wykonawców wspólnie ubiegających
się o udzielenie zamówienia: Asseco Data Systems S.A. z siedzibą w Gdyni, Asseco Poland
S.A. z siedzibą w Rzeszowie, DahliaMatic sp. z o.o. z siedzibą w Warszawie {dalej również:
„Konsorcjum Asseco”}, a także o odrzuceniu oferty Odwołującego.
23 grudnia 2016 r. Odwołujący wniósł w formie pisemnej do Prezesa Krajowej Izby
Odwoławczej odwołanie (zachowując wymóg przekazania jego kopii Zamawiającemu)
od powyższej czynności Zamawiającego, któremu zarzucił następujące naruszenia ustawy
pzp:
1. Art. 91 ust. 1 w zw. z art. 7 ust. 1 – przez zaniechanie ich zastosowania i wybór oferty
niebędącej najkorzystniejszą w rozumieniu SIWZ.
2. Art. 89 ust. 1 pkt 2 – przez bezpodstawne jego zastosowanie i odrzucenie oferty
Odwołującego.
3. Art. 7 ust. 1 – przez zaniechanie jego zastosowania i nierówne traktowanie
wykonawców.
Odwołujący wniósł o uwzględnienie odwołania i nakazanie Zamawiającemu:
1. Unieważnienia wyboru oferty najkorzystniejszej.
2. Unieważnienia odrzucenia oferty złożonej przez Sputnik.
Sygn. akt KIO 2439/16
3. Dokonania ponownej oceny ofert z udziałem oferty Odwołującego.
Odwołujący sprecyzował powyższą listę zarzutów przez zbiorcze podanie
następujących okoliczności prawnych i faktycznych dla uzasadnienia wniesienia odwołania.
Odwołujący zrelacjonował, że pismem z 14 grudnia 2016 r., na skutek ponownej
oceny ofert nakazanej wyrokiem Krajowej Izby Odwoławczej z 23 września 2016 r. (sygn.
akt: KIO 1641/16, 1652/16, 1662/16), Zamawiający zawiadomił wykonawców o powtórnym
wyborze oferty Konsorcjum Asseco oraz o ponownym odrzuceniu oferty Odwołującego. Jako
podstawę prawną odrzucenia oferty Odwołującego wskazano art. 89 ust. 1 pkt 2 pzp, zaś
faktyczną – niewłaściwe i niezgodne z SIWZ przygotowanie zestawu testowego
na podstawie którego przeprowadzona została prezentacja Systemu w dniu 1 czerwca
2016 r., co Zamawiający stwierdził w oparciu o odpowiedź Odwołującego z 27 czerwca
2016 r., informacje uzyskane w trakcie rozpraw w KIO oraz opinię Politechniki Rzeszowskiej.
Ponadto Zamawiający przedstawił wymagania postawione w SIWZ, powołując się
na definicję Systemu, w którego skład wchodzą Oprogramowanie, Oprogramowanie
Aplikacyjne, Dokumentacja, Kody źródłowe inne elementy.
W załączniku nr 1 do SIWZ – Opis przedmiotu zamówienia w pkt. 1 Zamawiający
jednoznacznie wskazał, że wsparcie dla zarządzania finansami Miasta musi być zapewnione
na poziomie standardowego rozwiązania klasy ERP, co w praktyce oznacza konieczność
dostarczenia przez wykonawcę komponentu aplikacyjnego.
Oznacza to, że standardowe rozwiązanie klasy ERP musi zawierać komponent aplikacyjny
standardowego rozwiązania klasy ERP, który przynajmniej w części realizuje funkcjonalności,
których oczekuje Zamawiający w zakresie zarządzania finansami miasta.
Rozumienie to zostało również potwierdzone w trakcie rozprawy przed KIO w dniu
26.02.2016 r., gdzie strony zgodnie stwierdziły, że komponent aplikacyjny stanowi co
najmniej 50% funkcjonalności opisanej w OPZ. Co więcej standardowe rozwiązanie klasy
ERP musi być dostępne na rynku w wersji COTS (czyli w wersji komercyjnej, seryjnie
produkowanej i gotowej do sprzedaży).
Zatem oferta każdego Wykonawcy oprócz dokumentów wymaganych musiała
zawierać odpowiednio przygotowany zestaw testowy zawierający wersję demonstracyjną
Systemu jw.:
• oprogramowanie = komponenty techniczne ERP, komponenty aplikacyjne ERP,
• oprogramowanie aplikacyjne zawierające rozbudowy standardowego rozwiązania
klasy ERP (w obszarze komponentu aplikacyjnego).
Według Odwołującego z podanego uzasadnienia wynika, że brak w jego zestawie
Sygn. akt KIO 2439/16
testowym wspomnianego „komponentu aplikacyjnego standardowego rozwiązania klasy
ERP” stanowi o stwierdzonej przez Zamawiającego niezgodności oferty z SIWZ. Odwołujący
zakwestionował takie rozstrzygnięcie, twierdząc, że jego oferta jest w całości zgodna
z treścią SIWZ, zarzucając jednocześnie Zamawiającemu, że w istocie nie wskazał
jakiegokolwiek punktu tej specyfikacji, któremu ta oferta by nie odpowiadała.
W szczególności w żadnym postanowieniu SIWZ nie ma obowiązku wykonania zestawu
testowego lub Systemu z wykorzystaniem „komponentu aplikacyjnego standardowego
rozwiązania klasy ERP”, a na takim błędnym założeniu opiera się uzasadnienie
Zamawiającego.
Odwołujący zrelacjonował również, że przedmiotem zamówienia jest dostawa,
wdrożenie, dostosowanie do potrzeb Zamawiającego, uruchomienie oraz serwis gwarancyjny
i usługi asysty technicznej standardowego rozwiązania klasy ERP wspierającego
zarządzanie finansami miasta w Urzędzie Miasta Łodzi i Miejskich Jednostkach
Organizacyjnych wymienionych w załączniku nr 2 do załącznika nr 1 do SIWZ
Odwołujący następnie zacytował, że zgodnie z definicjami przyjętymi w SIWZ (tabela
pkt 1.2 załącznika nr 1 do SIWZ – Opis przedmiotu zamówienia {dalej również: „OPZ”}:
Oprogramowanie oznacza łącznie: oprogramowanie systemowe, bazodanowe, narzędziowe
lub ogólnego przeznaczenia; oprogramowanie systemowe dostarczone przez Wykonawcę
w Rozwiązaniu o ile jest ono konieczne do realizacji przedmiotu zamówienia. Obejmuje
system operacyjny, zarządzanie systemem i siecią, standardowe rozwiązania klasy ERP oraz
oprogramowanie diagnostyczne;
oprogramowanie bazodanowe oznacza silnik bazy danych i narzędzia do zarządzania bazą
danych; oprogramowanie narzędziowe obejmuje narzędzia programistyczne służące do
budowy, kompilacji, modyfikacji, przystosowywania i uruchamiania Oprogramowania
Aplikacyjnego, w szczególności narzędzia typu CASE, narzędzia zarządzania bazą danych,
kompilatory, interpretatory;
oprogramowanie ogólnego przeznaczenia obejmuje m.in. edytor tekstu, arkusz kalkulacyjny,
itp.
Oprogramowanie Aplikacyjne oznacza, wykonane przez Wykonawcę rozbudowy
(przykładowo nowe moduły, warstwy, funkcjonalności standardowego rozwiązania klasy ERP.
mające na celu dostosowanie standardowego rozwiązania klasy ERP do wymogów
Zamawiającego wraz z interfejsami wymiany danych (m.in. WebService), wspierające
realizację zadań wynikających z przedmiotu zamówienia .
Według Odwołującego z tych definicji jasno wynika, że w postępowaniu chodzi
o rozbudowę standardowego rozwiązania klasy ERP mającą na celu dostosowanie go do
wymogów Zamawiającego. To wykonawca ma dostarczyć nowe „moduły, warstwy,
Sygn. akt KIO 2439/16
funkcjonalności” adekwatne do potrzeb Zamawiającego opisanych w SIWZ. Nigdzie
Zamawiający nie narzucił, aby odbywało się to poprzez „dostarczenie przez wykonawcę
komponentu aplikacyjnego standardowego rozwiązania klasy ERP”. Wręcz odwrotnie,
w definicji Oprogramowania Aplikacyjnego wyraźnie wskazano na nowe „moduły, warstwy,
funkcjonalności”.
Ponadto Odwołujący zacytował, że przez standardowe rozwiązanie klasy ERP
Zamawiający rozumie system, który spełnia warunki z pkt 1.1 OPZ:
a) Oferowane rozwiązanie powinno posiadać interfejs aplikacji umożliwiający pracę
w środowisku Microsoft Windows w wersji 7 lub wyższej;
b) Wszystkie komponenty serwerowe oferowanego rozwiązania powinny być wykonane w 64
bitowej technologii;
c) Oferowane rozwiązanie musi umożliwiać eksploatację na platformie bazy danych MSSQL
Server 2014, którą Zamawiający zamierza przeznaczyć do realizacji zamówienia.
d) W przypadku, gdy oferowane przez Wykonawcę rozwiązanie będzie funkcjonowało
na bazie danych innej niż ta, którą Zamawiający zamierza przeznaczyć do realizacji
niniejszego zamówienia, Wykonawca zobowiązany jest zapewnić licencje bazy danych,
na nieograniczoną liczbę użytkowników, niezbędne do pełnego wdrożenia oferowanego
systemu, zgodnie z wymaganiami (OPZ).
e) Oferowane rozwiązanie musi umożliwiać integrację z oprogramowaniem biurowym MS
Office w wersji co najmniej 2007, co najmniej w zakresie importu i eksportu danych
z poziomu interfejsu użytkownika;
f) Oferowane rozwiązanie musi obsługiwać wielowalutowość;
g) Wszystkie moduły oferowanego rozwiązania w przypadku klienta desktopowego muszą
działać w ramach jednego interfejsu i jednej aplikacji klienckiej (bez konieczności
wychodzenia z jednej aplikacji i wchodzenia do drugiej);
h) Licencje dostarczone dla oferowanego rozwiązania muszą umożliwiać obsługę
nieograniczonej liczby jednostek organizacyjnych;
i) Oferowane rozwiązanie musi udostępniać w ramach opłaty licencyjnej dostęp do otwartego
kodu Oprogramowania Aplikacyjnego;
j) Oferowane rozwiązanie powinno być zbudowane w oparciu o standardowe rozwiązanie
klasy ERP, wdrażane i serwisowane przez sieć partnerską firm wdrażających, autoryzowaną
przez producenta standardowego rozwiązania klasy ERP obejmującą co najmniej 5 firm
wdrożeniowych, niezależnych kapitałowo od siebie i od producenta standardowego
rozwiązania klasy ERP;
k) Oferowane rozwiązanie powinno być zbudowane w oparciu o standardowe rozwiązanie
klasy ERP dostępne na rynku w wersji COTS (commercial off-the-shelf) przynajmniej od 10
Sygn. akt KIO 2439/16
lat, a w oferowanej wersji co najmniej rok;
l) Oferowane rozwiązanie musi być wdrażane i serwisowane w modelu umożliwiającym
realizację projektów wdrożeniowych przez co najmniej pięciu partnerów autoryzowanych
przez producenta standardowego rozwiązania klasy ERP, niezależnych kapitałowo od siebie i
od producenta standardowego rozwiązania klasy ERP;
m) Oferowane rozwiązanie nie może w żaden sposób ograniczać Zamawiającego w wyborze
przyszłego wykonawcy mogącego utrzymać rozwiązanie po zakończeniu projektu.
Odwołujący dodał, że w tym samym punkcie OPZ wskazano, że zamówienie
obejmuje:
a) Wykonanie Projektu Rozwiązania;
b) Dostawę, Instalację Systemu i Konfigurację Oprogramowania, Oprogramowania
Aplikacyjnego.
Wykonawca
dostarczy
szczegółowe
zestawienie
dostarczonego
Oprogramowania, które zostanie zawarte w Dokumentacji powykonawczej;
c) Instalację i konfigurację Oprogramowania, które Zamawiający przeznaczył do realizacji
zamówienia, a które Wykonawca wykorzysta do wykonania Rozwiązania, zgodnie z punktem
2.2 Opisu Przedmiotu Zamówienia
(...)
g) Dostosowanie Oprogramowania Aplikacyjnego do potrzeb Zamawiającego oraz
zapewnienia jego interoperacyjności zgodnie z zapisami „Opisu Przedmiotu Zamówienia”;
Wreszcie Odwołujący przybliżył, że w zakresie wymagań dotyczących licencji w pkt
11 OPZ określono, że w ramach realizacji przedmiotu zamówienia Wykonawca w zależności
od posiadanych praw zobowiązany jest do Udzielenia licencji/sublicencji na:
11.1. Oprogramowanie standardowego rozwiązania klasy ERP na użytkownika nazwanego
800 licencji z możliwością Udzielania licencji/sublicencji na innych użytkowników, wraz
z prawem do aktualizacji, nowych wersji oraz pomocy technicznej, na cały okres trwania
Umowy i na warunkach określonych przez producenta ww. Oprogramowania standardowego;
11.2. Oprogramowanie Aplikacyjne, Wykonawca zobowiązany jest do Udzielenia
licencii/sublicencii/przeniesienia praw autorskich zgodnie z zapisami Istotnych Postanowień
Umowy. Wykonawca Udzieli licencji/sublicencji na Oprogramowanie Aplikacyjne bez limitów
(użytkowników, kont, rodzaju ilości stanowisk, ilości przetwarzanych danych, z prawem
przeniesienia/powielenia na nowe/inne/te same urządzenia) na pełne korzystanie
z oferowanego Oprogramowania Aplikacyjnego;
Odwołujący wywiódł, że w SIWZ:
– występuje wielopłaszczyznowe rozróżnienie Oprogramowania i Oprogramowania
Aplikacyjnego;
– Oprogramowanie Aplikacyjne nie jest tym samym co oprogramowanie standardowe;
Sygn. akt KIO 2439/16
– w żadnym miejscu nie ma również adnotacji, że Oprogramowanie Aplikacyjne musi być
wykonane na bazie komponentu aplikacyjnego standardowego rozwiązania klasy ERP.
Odwołujący podniósł, że również wymagania dotyczące zestawu testowego
nie nawiązują do komponentu aplikacyjnego standardowego rozwiązania klasy ERP.
Odwołujący powołał się na to, że zgodnie z załącznikiem nr 3 do OPZ – Regulamin
oraz harmonogram prezentacji Systemu:
pkt 1.1 Zakres i sposób dostarczenia – odbioru zestawu testowego do prezentacji Systemu,
ppkt 3: Zestaw testowy, który Wykonawca jest zobowiązany do dołączenia do oferty musi
zawierać sprzęt niezbędny do uruchomienia wersji demonstracyjnej Systemu w postaci co
najmniej: wyłącznie 1 komputera typu notebook, na którym będzie zainstalowany system
demonstracyjny, Oprogramowania, w tym standardowego oprogramowania klasy ERP,
Oprogramowania Aplikacyjnego w wersji demonstracyjnej, nośnika danych zawierającego
obraz dysku/dysków komputera typu notebook z wygenerowany sumami kontrolnymi MD5,
wydruk zawierający wszystkie sumy kontrolne MD5 dla wszystkich plików oraz innych
komponentów niezbędnych do wykonania prezentacji;
ppkt 4 Prezentacja wersji demonstracyjnej Systemu musi być wykonana w oparciu o
standardowe rozwiązanie klasy ERP (zgodnie z opisem zawartym w OPZ) i musi być
wykonana w tej samej technologii, co System oferowany w niniejszym postępowaniu;
ppkt 6 Na zestawie testowym zainstalowane Oprogramowanie w tym standardowe
rozwiązanie klasy ERP i Oprogramowanie Aplikacyjne musi być licencjonowane. Licencja
musi umożliwiać uruchomienia i wykonanie prezentacji Systemu w okresie od złożenia oferty
do końca trwania Umowy. Oprogramowanie i Oprogramowanie Aplikacyjne musi być już
zainstalowane na komputerze z zestawu testowego, tak aby podczas przygotowania do
prezentacji oraz w jej trakcie nie były instalowane żadne komponenty Systemu.
Odwołujący zarzucił, że w świetle takich postanowień SIWZ uzasadnienie podane
przez Zamawiającego, jest całkowicie nieuprawnione, gdyż:
– Zamawiający nie może oceniać ofert z punktu widzenia bliżej nieokreślonej „praktyki” (nie
wiadomo czyjej i jakiej), lecz postanowień SIWZ;
– Zamawiający wprowadził nieistniejące na gruncie SIWZ pojęcie „komponentu
aplikacyjnego ERP” (o którym nie ma mowy w definicji Oprogramowania ani
Oprogramowania aplikacyjnego), czyli aplikacji wspierającej zarządzania finansami miasta
producenta ERP w modelu COTS, wyłącznie na potrzeby odrzucenia oferty Odwołującego;
– warstwa aplikacyjna ma dopiero powstać w ramach Oprogramowania Aplikacyjnego
realizowanego przez wykonawcę na podstawie przyszłej umowy, nie ma mowy
o komponencie aplikacyjnym ERP;
– schematy blokowe przedstawione przez Zamawiającego (mające zapewne wizualnie
Sygn. akt KIO 2439/16
oddziaływać na czytelnika i obrazowo tłumaczyć rzekomą niezgodność oferty z SIWZ) są
kompletnie oderwane od treści SIWZ i nie zasługują na jakąkolwiek uwagę;
– nigdzie w SIWZ nie ma wymogu, aby Oprogramowanie (zwłaszcza standardowy ERP)
obejmowało komponenty aplikacyjne ERP ani tym bardziej nie ma w SIWZ parametru, aby
Oprogramowanie Aplikacyjne było zrealizowane przez wykonawcę wyłącznie w obszarze
komponentu aplikacyjnego ERP.
Odwołujący podsumował, że zdecydowanie odrzucić należy tezę Zamawiającego,
jakoby przedstawiony przez Odwołującego podczas prezentacji System stanowi próbę
obejścia wymagań SIWZ i wprowadzenia w błąd Zamawiającego. Według Odwołującego
zestaw testowy został wykonany ściśle według instrukcji zawartych w SIWZ,
a Zamawiającemu zaprezentowano rozwiązanie w oparciu o „Standardowe rozwiązanie klasy
ERP” w tej samej technologii co oferowany w niniejszym postępowaniu System. Technologia
Oracle występuje zarówno w części standardowego rozwiązania klasy ERP jak
i Oprogramowania Aplikacyjnego. Odwołujący architekturę systemu wymaganego przez
Zamawiającego zgodnie zapisami SIWZ zobrazował za pomocą schematu zamieszczonego
w odwołaniu {rysunki nr 1 i 2 dot. wersji demonstracyjnej systemu Sputnik Software}.
Według odwołującego potwierdzeniem zgodności technologicznej Oprogramowania
Aplikacyjnego Oracle Forms ze Standardowym rozwiązaniem klasy ERP Oracle E-Business
Suite jest model architektury rozwiązania Oracle E-Business Suite {rys. nr 3 w odwołaniu}.
A zastosowane na potrzeby przygotowania zestawu testowego Oprogramowanie klasy ERP
na
bazie
Oracle
E-Business
Suite
jest
całkowicie
zgodne
technologicznie
z Oprogramowaniem Aplikacyjnym zainstalowanym na zestawie dołączonym do oferty.
Odwołujący dodał, że licencja Oracle E-Business Suite zawiera następujące
komponenty, które można użytkować zgodnie z wybranym modelem licencyjnym: Oracle
Forms Services (w tym Forms), Oracle Reports Services, TopLink and Application
Development Services (w tym Forms), Oracle Report Services, ToLink and Application
Development Framework, portal, Discoverer Viewer, Disovewer Plus (WEB Functionality),
IdentityManagement, Application InterConnect Toolkit, Integration and Enterprise Service
Bus, JavaSE, WebLogic Server Basic, Oracle Access Manager Basic, and Personalization.
Oracle określa rówenież, które komponenty technologiczne są zgodne licencyjnie.
Zdaniem Odwołującego zarzut Zamawiającego niezastosowania „komponentu
aplikacyjnego ERP” o nazwie „Oracle Financials”, który wchodzi w skład Oracle E-Business
Suite, jest błędny i może wynikać z nieznajomości technologii Oracle EBS. Dla lepszego
zobrazowania budowy modułowej rozwiązania Oracle E-Business Suite (spełniającego
wymagania dla standardowego rozwiązania ERP) Odwołujący zaprezentował schemat
graficzny {rys. nr 4 w odwołaniu} obejmujący następujący wykaz modułów: a) Manufacturing
Sygn. akt KIO 2439/16
(produkcja), b) Inventory (inwentaryzacja), c) Fulfillment (logistyka) d) Finacial&Asset
Management {nazywane również „Financials”} (finanse i zarządzanie aktywami),
e) Customer Service (obsługa klienta), f) Customer Relations Management (zarządzanie
relacjami z klientami), g) Sales & Order Management (zarządzanie sprzedażą
i zamówieniami), h) Procurement (dostawy), i) Business Inteligence (analityka biznesowa),
k) Custom (niestandardowy).
Odwołujący wyjaśnił, że rozwiązanie klasy ERP Oracle-E-Business Suite
w standardzie realizuje funkcjonalności związane z obsługą przedsiębiorstw na całymświecie. A z uwagi na jego pochodzenie (USA) nie ma możliwości, aby w podstawowym
pakiecie funkcjonalnym obsługiwał polskie czy inne jednostki sektora publicznego z obszaru
Unii Europejskiej. Dzięki budowie modułowej i mechanizmowi dostosowywania (za pomocą
modułów niestandardowych – w tym przypadku Oprogramowaniu Aplikacyjnemu) istnieje
możliwość dostosowania rozwiązania do potrzeb klienta docelowego. Przykładowo, aby
spełnić wymagania załącznika nr 1 do SIWZ w zakresie Oprogramowania Aplikacyjnego
dostarczane przez Sputnik rozwiązanie klasy ERP musi zostać dostosowane. Innymi słowy
muszą zostać dobudowane nowe warstwy funkcjonalne stanowiące podstawę nowych
modułów
np.
podatkowych.
Dostosowanie
może
być
realizowane
w
oparciu
o programowanie nowych fragmentów kodu na bazie technologii Oracle Forms lub
implementacji gotowych warstw funkcjonalnych. W tym przypadku będzie miało
zastosowanie obu form, co nie oznacza, że Zamawiający otrzyma tożsamy system z obecnie
wykorzystywanym, gdyż powstanie nowy produkt spełniający wszystkie wymagania
wyspecyfikowane w OPZ.
Odwołujący zarzucił ponadto, że obecnie Zamawiający, nawet wbrew swoim
wcześniejszym ocenom, próbuje narzucić nieadekwatne do treści tej specyfikacji wymagania.
Odwołujący zrelacjonował, że poprzednio Zamawiający odrzucił jego ofertę m.in.
z tego powodu, że Wykonawca nie dysponuje wszystkimi komponentami zaoferowanego
Rozwiązania, ponieważ nie jest ich producentem, imputując nawet, że na zestawie testowym
zostało zainstalowane nielegalne oprogramowanie. Natomiast obecnie Zamawiający twierdzi,że w toku prezentacji zobaczył system niemalże identyczny z aktualnie eksploatowanym
systemem w Urzędzie Miasta Łodzi tj. ZSJ Magistrat 2000.
W tych okolicznościach Odwołującego zastanawiają dwa zagadnienia. Po pierwsze,
skoro Zamawiający 1 czerwca 2016 r. rzekomo zobaczył należący do Odwołującego system
ZSI Magistrat 2000, na jakiej podstawie zarzucił Odwołującemu że zainstalowane
oprogramowanie, w tym Oprogramowanie Aplikacyjne nie jest licencjonowane? Po drugie,
jeśli Zamawiającemu został zaprezentowany ZSI Magistrat 2000, który aktualnie użytkuje,
dlaczego w toku oceny ofert przyznał Odwołującemu tylko 2 punkty w kryterium „SGSW”
Sygn. akt KIO 2439/16
i stwierdził, że zaprezentowany system (rzekomo ten sam, który użytkuje od 17 lat!) nie
realizuje większości wymaganych funkcjonalności z Obszaru budżetowo-księgowego oraz
Obszaru opłat i podatków (lub że są realizowane sprzecznie z obowiązującymi
przepisami...)?
Odwołujący dodał, że Zamawiający badał jego ofertę wszechstronnie, zarówno
w warstwie merytorycznej, jak i formalnej. Sprawdzał bardzo drobiazgowo spełnienie
każdego warunku udziału w postępowaniu, wystosował do Odwołującego kilkanaście
różnego rodzaju wezwań, aby finalnie nie stwierdzić niezgodności zestawu testowego lub
zaoferowanego Systemu z treścią SIWZ. Ponadto w toku badania ofert oraz podczas
rozprawy przed Krajową Izbą Odwoławczą Zamawiający posiłkował się ekspertami; którzy
oceniali próbkę (zestaw testowy) i nie stwierdzili jej niezgodności z treścią SIWZ .
Zdaniem Odwołującego obecne działania Zamawiającego stoją w jaskrawej
sprzeczności z jego wcześniejszymi czynnościami. Odwołującemu, patrząc przekrojowo na
przebieg postępowania, wydaje się, że celem Zamawiającego nie jest i nie była rzetelna i
obiektywna ocena ofert; lecz dokonanie wyboru oferty Konsorcjum Asseco , droższej o blisko
15 mln zł. Zamawiający uprzednio nie widział żadnej merytorycznej wady zestawu
testowego, a wręcz zarzucał, że Odwołujący nie posiada odpowiednich licencji Oracle
umożliwiających mu wykonanie takiego zestawu. W tej chwili twierdzi, że w tym zestawie
jakiegoś komponentu Oracle w ogóle nie było.
29 grudnia 2016 r. wpłynęło w formie pisemnej do Prezesa Izby zgłoszenie przez
Konsorcjum Asseco
przystąpienia
do
postępowania
odwoławczego
po
stronie
Zamawiającego
Wobec dokonania zgłoszenia w odpowiedniej formie, z zachowaniem 3-dniowego
terminu oraz wymogu przekazania jego kopii Stronom postępowania (zgodnie z art. 185 ust.
2 pzp) – Izba nie miała podstaw do stwierdzenia nieskuteczności przystąpienia, co do
którego nie zgłoszono również opozycji.
Przystępujący wniósł o oddalenie odwołania.
5 stycznia 2016 r. wpłynęła do Izby odpowiedź na odwołanie, w której Zamawiający
wniósł o jego oddalenie w całości, uzasadniając swoje stanowisko odnośnie każdego
z zarzutów.
Sygn. akt KIO 2439/16
Ponieważ odwołanie nie zawierało braków formalnych, a wpis od niego został
uiszczony – podlegało rozpoznaniu przez Izbę.
W toku czynności formalnoprawnych i sprawdzających Izba nie stwierdziła,
aby odwołanie podlegało odrzuceniu na podstawie przesłanek określonych w art. 189 ust. 2
pzp. Nie zgłaszano w tym zakresie odmiennych wniosków.
Z uwagi na brak podstaw do odrzucenia odwołania lub umorzenia postępowania
odwoławczego sprawa została skierowana do rozpoznania na rozprawie, podczas której
Odwołujący, Zamawiający i Przystępujący podtrzymali dotychczasowe stanowisko.
Po
przeprowadzeniu
rozprawy
z
udziałem
Odwołującego,
Zamawiającego
i Przystępującego, uwzględniając zgromadzony materiał dowodowy, jak również
biorąc pod uwagę oświadczenia i stanowiska zawarte w odwołaniu, dalszych pismach
z 11 i 16 stycznia 2017 r., odpowiedzi na odwołanie, dalszym piśmie z 18 stycznia
2017 r., zgłoszeniu przystąpienia i dalszych pismach z 10 i 16 stycznia 2017 r., a także
wyrażone ustnie na rozprawie i odnotowane w protokole, Izba ustaliła i zważyła, co
następuje:
Z art. 179 ust. 1 pzp wynika, że odwołującemu przysługuje legitymacja do wniesienia
odwołania, gdy ma (lub miał) interes w uzyskaniu zamówienia oraz może ponieść szkodę
w wyniku naruszenia przez zamawiającego przepisów ustawy.
W ocenie Izby Odwołujący wykazał, że ma interes w uzyskaniu przedmiotowego
zamówienia, skoro złożył ofertę, która według kryteriów oceny przyjętych w tym
postępowaniu mogłaby okazać się najkorzystniejsza. Stąd Odwołujący może ponieść szkodę
w związku z zarzucanymi Zamawiającemu naruszeniami przepisów ustawy pzp w związku
z odrzuceniem oferty Odwołującego, gdyż w przeciwnym razie mógłby liczyć na uzyskanie
przedmiotowego zamówienia.
Zostały również wzięte pod uwagę przez Izbę pozostałe pisma złożone przez
Odwołującego {pierwsze trzy wymienione.} i Przystępującego {ostatnie z wymienionych} tj:
– Ekspertyza technologiczna Oracle E-Business Suite 12 z 19 grudnia 2016 r. autorstwa
J.N., pracownika Oracle Polska sp. z o.o. z siedzibą w Warszawie {która została w całości
inkorporowana do treści odwołania};
– Ekspertyza. Ocena zgodności oferty firmy Sputnik sp. z o.o. na „dostawę i wdrożenie
Sygn. akt KIO 2439/16
systemu informatycznego wspomagającego zarządzanie finansami Miasta… z 10 stycznia
2017 r. autorstwa mgr. Inż. A.K. {dalej: „Ekspertyza A. K.”};
– Wykonanie ekspertyzy w zakresie zgodności oferty firmy Sputnik Software Sp. z o.o.
z wymaganiami
przetargu
na
dostawę
i
wdrożenie
systemu
informatycznego
wspomagającego zarządzanie finansami Miasta… z 10 stycznia 2017 r. Instytutu Automatyki
i Robotyki Politechniki Warszawskiej autorstwa prof. dr. hab. inż. R.P. {dalej: „Ekspertyza
PW”};
– Opinia ekspercka dotycząca postępowania o udzielenie zamówienia na „Dostawę
i wdrożenie systemu informatycznego wspomagającego zarządzanie finansami Miasta”…
z 13 stycznia 2017 r. autorstwa dr hab. inż. A.Z. {dalej: „Ekspertyza A. Z.”}.
Izba zaznacza, że ponieważ w postępowaniu odwoławczym nie zgłoszono wniosku
o przeprowadzenie dowodu z opinii biegłego ani Izba nie uznała za konieczne dopuszczenie
takiego dowodu z urzędu, powyższe pisma zostały uznane li tylko za uszczegółowienie
stanowisk Odwołującego i Przystępującego, a nie za dowód na poparcie ich twierdzeń.
W ocenie Izby odmienny status ma Wykonanie ekspertyzy w zakresie oceny
zgodności zaprezentowanej przez firmę Sputnik próbki w ramach testów gotowości systemu
a zaoferowanym rozwiązaniem Oracle E-Business Suite (EBS) w wersji 12 Wydziału
Elektromechaniki i Informatyki Politechniki Rzeszowskiej z 21 listopada 2016 r. autorstwa dr.
inż. M.N. {dalej: „Ekspertyza PR”}, na którą powołano się w uzasadnieniu odrzucenia oferty
Sputnika, gdyż zgodnie z art. 21 ust. 4 pzp jeżeli dokonanie określonych czynności
związanych z przygotowaniem lub przeprowadzeniem postępowania o udzielenie
zamówienia wymaga wiadomości specjalnych, kierownik zamawiającego, z własnej
inicjatywy lub na wniosek komisji przetargowej, może powołać biegłych, a zatem podlega
ona ocenie jako materiał dowodowy.
Izba uznała za spóźnione i bezprzedmiotowe zgłoszone dopiero na rozprawie przez
Odwołującego zastrzeżenia odnośnie bezstronności Politechniki Rzeszowskiej. Po pierwsze
– termin na zgłoszenie tego typu zarzutu upłynął wraz z terminem na wniesienie odwołania.
Po drugie – wywodzenie rzekomego barku bezstronności z informacji prasowych oraz
zamieszczonych na stronach internetowych zainteresowanych instytucji dotyczącej
współpracy Politechniki Rzeszowskiej z Asseco Poland, jest nieudowodnioną spekulacją.
{rozstrzygnięcie zarzutów z pkt 2. listy zarzutów}
Izba ustaliła poniższe okoliczności jako istotne dla rozstrzygnięcia.
W odniesieniu do rozumienia użytego w s.i.w.z. terminu „Standardowe rozwiązanie
Sygn. akt KIO 2439/16
klasy ERP”:
– Określenie klasy systemów informatycznych służących wspomaganiu zarządzania
przedsiębiorstwem w różnych obszarach biznesu. System ten składa się zawsze z wielu
komponentów aplikacyjnych (…) wśród standardowych komponentów aplikacyjnych
wyróżnia się chociażby: obsługę klientów, produkcję, finanse i księgowość, zarządzanie
zasobami ludzkimi, zaopatrzenie. {odpowiedź na odwołanie, str. 2}.
– (…) w powszechnym rozumieniu oznacza standardowe rozwiązania, zaszyte w pakiecie
zintegrowanego <oprogramowania> służącego do zarządzania zasobami organizacji, bez
wskazywania na jej charakter i specyfikę działalności. (…) Cechą wspólną dla wszystkich
systemów ERP jest podział <oprogramowania> na moduły funkcjonalne, wspólne struktury
danych dla różnych modułów, oraz ujednolicona logika przechowywania, dostępu,
przetwarzania i prezentacji danych, (…) W rozumieniu powszechnym pojęcie (…) nie
obejmuje efektów „dostosowania” ani „rozbudowy” (przykładowo o nowe moduły, warstwy,
funkcjonalności). {Ekspertyza A. K., str. 6}
– (…) w świetle teorii i praktyki systemów ERP może jedynie oznaczać, że jest to system: I)
oparty na podejściu procesowym do zarządzania organizacją ; II) (...) który zapewnia
integrację funkcji i danych organizacji; III) umożliwia standaryzację funkcji i wzorów
z najlepszymi wzorcami dostępnymi w biznesie. {Ekspertyza PW, str. 3}
– Oznacza system informatyczny służący do prowadzenia wszelkich ewidencji związanych
z działalnością firmy (rachunkowość finansowa i zarządcza, rozrachunki z kontrahentami,
kadry, płace, produkcje, nieruchomości i in.), wspierający realizację związanych z tymi
ewidencjami
procesów
biznesowych,
pozwalający
jednocześnie
na
planowanie
i raportowanie w zakresie objętym zakresem systemu. Cechą charakterystyczną systemów
ERP jest integracja w ramach jednego systemu wszystkich danych opisujących całą
działalność przedsiębiorstwa z tego powodu systemy tej klasy bywają nazywane
zintegrowanymi. {Ekspertyza A. Z., str. 14}
Reasumując innymi słowy, niesporne pomiędzy uczestnikami postępowania
odwoławczego było, że „standardowe rozwiązanie klasy ERP” to określenie dotyczące
systemów informatycznych służących wspomaganiu zarządzania przedsiębiorstwem
(organizacją), w tym optymalizacji wykorzystania zasobów przedsiębiorstwa (organizacji)
oraz zachodzących w nim procesów, dzięki gromadzeniu danych oraz umożliwieniu
wykonywania, co realizowane jest w oparciu o bazę danych, z której korzystają
poszczególne moduły aplikacyjne (tzw. komponenty aplikacyjne wg terminologii
z uzasadnienia odwołania), obejmujące poszczególne obszary działalności przedsiębiorstwa
(organizacji).
Sygn. akt KIO 2439/16
Na poziomie najbardziej ogólnym według specyfikacji przedmiot tego zamówienia
obejmuje dostawę, wdrożenie i dostosowanie do potrzeb Zamawiającego, uruchomienie oraz
serwis gwarancyjny i usługi asysty technicznej rozumianego w powyższy sposób
standardowego rozwiązania klasy ERP (Enterprise Resource Planning) wspierającego
zarządzanie finansami miasta, czyli uzyskanie docelowego Rozwiązania (rozumianego jako
System funkcjonujący na infrastrukturze teleinformatycznej Zamawiającego), czyli
wdrożonego Systemu (obejmującego wszystkie przewidziane umową dostarczone,
zainstalowane, zintegrowane i wdrożone Produkty (Oprogramowanie, Oprogramowanie
Aplikacyjne, Dokumentacja, Kody źródłowe oraz inne elementy dostarczone przez
wykonawcę w celu realizacji Rozwiązania) {pkt 1 załącznika nr 1 do s.i.w.z., pkt 1.1 Ogólny
Opis Przedmiotu Zamówienia… in principio oraz pkt 1.2 Przyjęte definicje załącznika nr 1 do
OPZ}
Przy czym Zamawiający wskazał również {w pkt 1.1 lit. j), k) oraz l) załącznika nr 1 do
OPZ }, że takie standardowe rozwiązanie klasy ERP oznacza w szczególności, że jest:
– ono wdrażane i serwisowane przez sieć partnerską firm wdrażających, autoryzowaną przez
producenta standardowego rozwiązania klasy ERP, obejmującą co najmniej 5 firm
wdrożeniowych, niezależnych kapitałowo od siebie i od producenta standardowego
rozwiązania klasy ERP;
– dostępne na rynku w wersji COTS (commercial off-the-shelf) przynajmniej od 10 lat, a
w oferowanej wersji co najmniej rok;
– możliwe jego wdrażane i serwisowane w modelu umożliwiającym realizację projektów
wdrożeniowych przez co najmniej pięciu partnerów autoryzowanych przez producenta
standardowego rozwiązania klasy ERP, niezależnych kapitałowo od siebie i od producenta
standardowego rozwiązania klasy ERP.
Z kolei Oprogramowanie Aplikacyjne obejmuje wykonane przez wykonawcę
rozbudowy (począwszy od dodanych funkcjonalności, warstw aż do nowych modułów) tak
rozumianego standardowego rozwiązania klasy ERP, mające na celu jego dostosowanie
do wymogów Zamawiającego {wg definicji podanej w pkt 1.2 załącznika nr 1 do OPZ}, czyli
specyfiki działalności Zamawiającego, której nie uwzględniają występujące w standardowym
rozwiązaniu klasy ERP moduły (komponenty) aplikacyjne.
Zamawiający w prowadzonym postępowaniu wymagał od wykonawców, oprócz
złożenia pisemnej oferty, dołączenia do niej zestawu testowego z zainstalowaną wersją
demonstracyjną Systemu, w tym standardowym oprogramowaniem klasy ERP oraz
Oprogramowaniem Aplikacyjnym, służącego przeprowadzeniu prezentacji Systemu według
scenariuszy testowych (dla obszarów: budżetowo-księgowego oraz opłat i podatków), w celu
Sygn. akt KIO 2439/16
weryfikacji stopnia jego gotowości do wdrożenia, stanowiącego jedno z kryteriów oceny ofert
o wadze 40% {pkt 10.11.2.1-10.11.2.2 s.i.w.z.; załącznik nr 3 do OPZ – Regulamin oraz
harmonogram prezentacji Systemu pkt 1-2; załącznik nr 4 do OPZ; pkt 13.7 s.i.w.z.}.
Zamawiający podkreślił dodatkowo, że prezentacja wersji demonstracyjnej Systemu
musi być wykonana w oparciu o standardowe rozwiązanie klasy ERP (zgodnie z opisem
zawartym w OPZ) i musi być wykonana w tej samej technologii, co oferowany System {pkt
10.11.2.2 s.i.w.z.; pkt 2 załącznika nr 3 do OPZ}.
Standardowe rozwiązanie klasy ERP produkowane przez Oracle o nazwie
E-Bussines Suite w wersji 12 w swej standardowej postaci, tj. takiej, w jakiej producent
udostępnia i wprowadza je do obrotu rynkowego, zawiera następujące moduły (komponenty)
aplikacyjne, które jednocześnie wyznaczają zakres dziedzinowy zastosowania tego
rozwiązania standardowego: a) Manufacturing (produkcja), b) Inventory (inwentaryzacja), c)
Fulfillment (logistyka) d) Finacial&Asset Management {nazywane również „Financials”}
(finanse i zarządzanie aktywami), e) Customer Service (obsługa klienta), f) Customer
Relations Management (zarządzanie relacjami z klientami), g) Sales & Order Management
(zarządzanie sprzedażą i zamówieniami), h) Procurement (dostawy), i) Business Inteligence
(analityka biznesowa), k) Custom (interfejs na dołączanie modułów niestandardowych)
{odwołanie, str. 12; Ekspertyza A. K., str. 7.; odpowiedź na odwołanie, str. 4}
Systemy ERP innych producentów obejmują bardzo podobny zakres dziedzinowy.
Różnice polegają na sposobach implementacji procesów biznesowych, struktur danych,
funkcjonalności i zastosowanych sposobów pararametryzacji i narzędzi do kastomizacji
rozwiązań. {Ekspertyza A. K., str. 7}
Oracle Financials jest centralnym miejscem w aplikacjach Oracle, w którym następuje
obsługa finansowa następujących obszarów funkcjonalnych: księgi głównej, należności,
zobowiązań, środków pieniężnych, środków trwałych i kas gotówkowych. Przy czym owo
rozwiązanie finansowe Oracle jest zgodne z prawodawstwem polskim, szczególnie
w zakresie ustawy o rachunkowości, ustaw podatkowych i ustawy o ochronie danych
osobowych {str. 3 i 9 Oracle E-Business Suite. Oracle Financials. Opis funkcjonalności
produktu.}
Oracle E-Bussines Suite 12 oparte jest m.in. na technologii Oracle Forms, czyli
oprogramowaniu narzędziowym, za pomocą którego zostały utworzone ekrany systemu
i które umożliwia tworzenie funkcjonalnych modułów aplikacyjnych {odwołanie, str. 10-11;
oświadczenie Oracle Polska sp. z o.o. z 20 września 2016 r.; pismo Zamawiającego z 18
stycznia 2017 r., str. 3; pisma Przystępującego z 10 i 16 stycznia 2017 r., odpowiednio pkt 7 i
II.2}
Sygn. akt KIO 2439/16
Oracle uznaje tworzenie nowych modułów z wykorzystaniem technologii Oracle
Forms jako mieszczące się w ramach tzw. Platformy E-Business Suite 12, a nie jako element
standardowego rozwiązania klasy ERP Oracle E-Business Suite 12 {oświadczenie Oracle
Polska sp. z o.o. z 20 września 2016 r.}
Niesporne jest, że zestaw testowy załączony do oferty Sputnika nie obejmowałżadnego z modułów (komponentów) aplikacyjnych wchodzących w skład Oracle E-Bussines
Suite sprzedawanego jako COTS, w szczególności Oracle Financials, a całość funkcji
objętych prezentacją realizowana była przez wykonane w ramach Oprogramowania
Aplikacyjnego moduły własne Sputnika zaprogramowane od podstaw z wykorzystaniem
technologii Oracle Forms.
Sputnik nie deklaruje również wykorzystania gotowych modułów aplikacyjnych Oracle
E-Bussines Suite w oferowanym docelowym Systemie, gdyż uważa, że w żadnym
postanowieniu SIWZ nie ma obowiązku wykonania zestawu testowego lub Systemu
z wykorzystaniem „komponentu aplikacyjnego standardowego rozwiązania klasy ERP” {fraza
pogrubiona na str. 3 odwołania}.
Reasumując, Izba stwierdziła, co następuje:
– Skoro niesporne w postępowaniu odwoławczym było, że standardowe rozwiązanie klasy
ERP produkcji Oracle o nazwie E-Bussines Suite 12 dostępne jako oprogramowanie COTS
zawiera moduły aplikacyjne wyznaczające zakres jego możliwego zastosowania, w tym
w odniesieniu do zarządzania finansami moduł Oracle Financials {powyżej nazywany
również Finacial&Asset Management}, nie można jednocześnie twierdzić, że bez tego typu
modułów nadal stanowi „standardowe rozwiązanie klasy ERP”, gdyż w takiej okrojonej
postaci jest ono niekompletne i nie spełnia żadnych funkcji, do których jest przeznaczone,
a zatem nie wspiera również zarządzania finansami.
– Rozwiązanie zaprezentowane i oferowane przez Sputnik, w którym zamiast standardowych
modułów aplikacyjnych Oracle E-Bussines Suite 12 są wyłącznie moduły zaprogramowane
od podstaw przez Sputnika z użyciem technologii Oracle Forms, nie odpowiada treści opisu
przedmiotu zamówienia s.i.w.z. obowiązującej w tym postępowaniu, gdyż zamiast wykonania
rozbudowy Oracle E-Bussines Suite 12, czyli standardowego rozwiązania klasy ERP,
o niewystępujące w nim funkcjonalności wymagane przez Zamawiającego, dzięki
zaprogramowaniu nowych funkcjonalności, warstw lub nowych modułów, oferuje zastąpienie
wszystkich istniejących standardowych modułów własnymi, wykonanymi według tej samej
technologii w oparciu o tzw. platformę Oracle E-Bussines Suite 12.
Ponadto Izba stwierdziła, że w zawiadomieniu przekazanym Sputnikowi Zamawiający
Sygn. akt KIO 2439/16
zawarł uzasadnienie odrzucenia oferty, które uwzględniało powyżej ustalone okoliczności.
Obszerne uzasadnienie faktyczne z użyciem terminu „komponent aplikacyjny” oraz
diagramów służyło jak najdokładniejszemu wyjaśnieniu stwierdzonej adekwatnie przez
Zamawiającego niezgodności zestawu testowego z oferty Sputnika z treścią postanowień
s.i.w.z.
W tych okolicznościach Izba stwierdziła, że odwołanie jest niezasadne
Odwołujący bezpodstawnie domaga się uchylenia odrzucenia jego oferty
na podstawie art. 89 ust. 1 pkt 2 pzp, gdyż odwołanie opiera się na wybiórczej interpretacji
postanowień opisu przedmiotu zamówienia, w szczególności definicji Oprogramowania
Aplikacyjnego, przy jednoczesnym zanegowaniu, że wymagane było zaoferowanie Systemu,
który będzie opierał się na standardowym rozwiązaniu klasy ERP jako oprogramowaniu
COTS rozbudowanym przez wykonawcę zamówienia jedynie w niezbędnym zakresie.
Odwołujący, wbrew treści opisu przedmiotu zamówienia, sprowadza rozumienie
„standardowego rozwiązania klasy ERP” do wymogu wykonania przez wykonawcę
zamówienia modułów aplikacyjnych w oparciu o to samo oprogramowanie narzędziowe co
standardowe moduły aplikacyjne producenta tego rozwiązania służące wsparciu dziedzin
działalności objętej przedmiotem zamówienia.
Skład orzekający Izby podziela utrwalony w doktrynie i orzecznictwie pogląd,że zarówno treść s.i.w.z., jak i treść oferty stanowią merytoryczne postanowienia oświadczeń
woli odpowiednio: zamawiającego, który w szczególności przez opis przedmiotu zamówienia
precyzuje, 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. Wobec tego – co do zasady –
porównanie zaoferowanego przez wykonawcę świadczenia z opisem przedmiotu
zamówienia, sposobem i terminem jego realizacji wymaganymi przez zamawiającego,
przesądza o tym, czy treść złożonej oferty odpowiada treści s.i.w.z. – jest z nią zgodna.
Aby zapewnić możliwość sprawdzenia zgodności treści oferty z treścią s.i.w.z.,
ustawa pzp z jednej strony obliguje zamawiającego, aby prowadził całe postępowanie
o udzielenie zamówienia w formie pisemnej (art. 9 ust. 1 pzp), w tym przekazał i udostępnił
specyfikację istotnych warunków zamówienia (art. 37 ust. 1 i 2 pzp), która ma zawierać
w szczególności opis przedmiotu zamówienia, określenie terminu wykonania zamówienia,
istotne warunki umowy w sprawie zamówienia publicznego oraz opis sposobu przygotowania
ofert (art. 36 ust. 1 pkt 3, 4, 16 i 10 pzp). Z drugiej strony art. 82 ust. 2 pzp zastrzega
Sygn. akt KIO 2439/16
dla oferty składanej przez wykonawcę w postępowaniu o udzielenie zamówienia publicznego
formę pisemną pod rygorem nieważności, a w art. 82 ust. 3 pzp wprost wskazuje, że treść
takiej oferty musi odpowiadać treści specyfikacji.
W doktrynie i orzecznictwie przyjmuje się również, że rozumienie terminu oferta
należy opierać na art. 66 § 1 Kodeksu cywilnego, zgodnie z którym jest nią oświadczenie
drugiej stronie woli zawarcia umowy, jeżeli określa istotne postanowienia tej umowy. Z uwagi
na odpłatny charakter zamówień publicznych, nieodzownym elementem treści oferty będzie
zawsze określenie ceny za jaką wykonawca zobowiązuje się wykonać zamawianeświadczenie. W pozostałym zakresie to zamawiający określa w s.i.w.z. wymagany
od wykonawcy zakres i sposób konkretyzacji oświadczenia woli, który będzie podstawą dla
oceny zgodności treści złożonej oferty z merytorycznymi wymaganiami opisu przedmiotu
zamówienia.
W konsekwencji nie tylko treść wynikająca explicite ze złożonej oferty, ale również
nieskonkretyzowanie jej treści przez wykonawcę w sposób lub w zakresie wymaganym przez
zamawiającego, może być podstawą do stwierdzenia niezgodności oferty z treścią s.i.w.z.,
gdyż – co do zasady – niedopuszczalne jest precyzowanie i poprawianie treści złożonej
oferty, w szczególności z uwagi za naczelne zasady równego traktowania wykonawców
i zachowania uczciwej konkurencji.
W zakresie zastosowania przesłanki odrzucenia oferty z art. 89 ust. 1 pkt 2 pzp
mieści się bowiem również sporządzenie oferty w inny sposób, niż żądał tego zamawiający,
o ile niezgodność taka dotyczy elementów treści oferty w aspekcie formalnym i materialnym,
choć nie może tu chodzić wyłącznie o niezgodność sposobu spełnienia tych aspektów {por.
J. Pieróg w: Prawo zamówień Publicznych. Komentarz, wyd. C.H. Beck, Warszawa 2009}.
Innymi słowy niezgodność treści oferty z treścią s.i.w.z. może polegać na sporządzeniu
i przedstawieniu oferty w sposób niezgodny z wymaganiami specyfikacji, z zaznaczeniem,że chodzi tu o wymagania s.i.w.z. dotyczące sposobu wyrażenia, opisania i potwierdzenia
zobowiązania (świadczenia) ofertowego, a więc wymagania, co do treści oferty, a nie
wymagania co do jej formy, które również zamieszczane są w s.i.w.z. {por. np. uzasadnienie
wyroku Izby z 13 listopada 2013 r., sygn. akt KIO 2478/13}.
W ramach wymaganego od wykonawcy sposobu potwierdzenia treści oferty mieści
się również oparte na art. 25 ust. 1 pkt 2 pzp żądanie przez zamawiającego oświadczeń lub
dokumentów potwierdzających spełnianie jego wymagań (określonych w s.i.w.z.) przez
oferowane dostawy, usługi lub roboty budowlane. Niezamknięty katalog tych dokumentów
został określony w § 6 rozporządzenia Prezesa Rady Ministrów z dnia 19 lutego 2013 r.
w sprawie rodzajów dokumentów, jakich może żądać zamawiający od wykonawcy, oraz form,
w jakich te dokumenty mogą być składane (Dz. U. poz. 231; dalej również: „rozporządzenie
Sygn. akt KIO 2439/16
o dokumentach”). Dokumenty te należy rozpatrywać jako kwalifikowaną formę potwierdzenia
zgodności oferowanego świadczenia z wymaganym przez zamawiającego. Zadeklarowana
przez wykonawcę treść oferty ma bowiem dodatkowo znaleźć potwierdzenie w dokumentach
co do zasady pochodzących od niezależnego od wykonawcy podmiotu zewnętrznego
(co wprost wskazano przy określeniu rodzaju dokumentów wyliczonych w § 6 ust. 1 pkt 2 - 4
rozporządzenia), względnie w próbkach, opisach lub fotografiach produktów, które mają być
dostarczone, których autentyczność musi być poświadczona przez wykonawcę na żądanie
zamawiającego (rodzaje środków dowodowych wymienione w § 6 ust. 1 pkt 1
rozporządzenia).
W konsekwencji brak takiego kwalifikowanego potwierdzenia również jest podstawą
do odrzucenia oferty jako niezgodnej z treścią s.i.w.z., co przejawia się zarówno w aspekcie
formalnym – niezgodności z postanowieniem formułującym żądanie złożenia takich
dokumentów, jak i przede wszystkim materialnym – niewykazaniu zgodności oferowanych
produktów z wymaganiami zamawiającego w zakresie parametrów, które miały znaleźć
potwierdzenie w tych dokumentach. Resumując, jak trafnie zauważono w uzasadnieniu
wyroku Izby z 16 października 2012 r. (sygn. akt KIO 2162/12), konsekwencją
nieuzupełnienia dokumentu przedmiotowego (innego niż potwierdzającego spełnienie
warunku udziału w postępowaniu) jest konieczność odrzucenia oferty na podstawie art. 89
ust. 1 pkt 2 ustawy pzp jako nieodpowiadającej treści specyfikacji.
Niezależnie od charakteru niezgodności, aby zastosować podstawę odrzucenia oferty
z art. 89 ust. 1 pkt 2 pzp musi być możliwe uchwycenie na czym konkretnie taka niezgodność
polega, czyli co i w jaki sposób w ofercie nie jest zgodne z konkretnie wskazanymi,
skwantyfikowanymi i ustalonymi jednoznacznie postanowieniami s.i.w.z. W odniesieniu do
dokumentów, o których mowa w art. 25 ust. 1 pkt 2 pzp, oznacza to konieczność
zidentyfikowania parametru oferowanego produktu, który nie znalazł w nich kwalifikowanego
potwierdzenia, pomimo że w ofercie został zadeklarowany przez wykonawcę jako zgodny z
parametrem wymaganym według opisu przedmiotu zamówienia.
Zgodnie z art. 87 ust. 1 pzp w toku badania i oceny ofert zamawiający może żądać od
wykonawców wyjaśnień dotyczących treści złożonych ofert. Niedopuszczalne jest
prowadzenie między zamawiającym a wykonawcą negocjacji dotyczących złożonej oferty
oraz z zastrzeżeniem ust. 1a i 2 pzp, dokonywanie jakiejkolwiek zmiany w jej treści.
Z wyjątkiem trybu dialogu konkurencyjnego zmiany te sprowadzają się to do wspominanej
powyżej instytucji poprawienia omyłek polegających na niezgodności oferty ze specyfikacją,
co nie może jednak powodować istotnej zmiany treści oferty.
Z kolei z art. 26 ust. 3 pzp wynika, że zamawiający wzywa wykonawców, którzy
w określonym terminie nie złożyli wymaganych przez niego oświadczeń lub dokumentów,
Sygn. akt KIO 2439/16
o których mowa w art. 25 ust. 1 pkt 2 pzp, lub którzy złożyli takie dokumenty zawierające
błędy, do ich złożenia w wyznaczonym terminie. Złożone na wezwanie zamawiającego
oświadczenia i dokumenty powinny potwierdzać spełnianie przez oferowane dostawy, usługi
lub roboty budowlane wymagań określonych przez zamawiającego, nie później niż w dniu,
w którym upłynął termin składania ofert.
Ponadto zamawiający może w odniesieniu do złożonych pierwotnie lub uzupełnionych
dokumentów zażądać od wykonawcy wyjaśnień w trybie art. 26 ust. 4 pzp. Oczywiste jest,że instytucja ta służy wyjaśnieniu niezrozumiałej dla zamawiającego treści dokumentu,
w szczególności ustaleniu gdzie znajduje się informacja potwierdzająca spełnianie wymagań,
a nie zmianie treści dokumentu, co jest możliwe w trybie art. 26 ust. 3 pzp. Jak trafnie
zauważono w uzasadnieniu wyroku Izby z 13 września 2010 r. (sygn. akt KIO 1863/10) nie
można wyjaśnieniami przywrócić sobie możliwości ponownego uzupełnienia wadliwie
złożonego dokumentu.
Wystąpienie stanu niezgodności treści oferty z treścią s.i.w.z. nie zawsze będzie to
podstawą do odrzucenia oferty, gdyż art. 89 ust. 1 pkt 2 pzp wprost odsyła do art. 87 ust. 2
pkt 3 pzp. Odrzuceniu podlega zatem wyłącznie oferta, której treść jest niezgodna z treścią
s.i.w.z. w sposób zasadniczy i nieusuwalny, gdyż obowiązkiem zamawiającego jest
poprawienie w złożonej ofercie niezgodności z s.i.w.z. niemających istotnego charakteru.
O ile każdorazowo treść oświadczenia woli składanego w postępowaniu w ramach
oferty należy rozpatrywać przez pryzmat zamiaru wykonawcy, wyrażającego się wolą
uczestnictwa w postępowaniu, a w konsekwencji – złożenia oferty zgodnej z s.i.w.z. {tak
m.in. wyroki Izby wydane: 3 kwietnia 2012 r. (sygn. akt KIO 556/12), 9 listopada 2012 r.
(sygn. akt: KIO 2343/12, KIO 2346/12), 22 listopada 2012 r. (sygn. akt: KIO 2396/12, KIO
2416/13), 10 czerwca 2013 r. (sygn. akt KIO 1266/13)} – o tyle kluczową sprawą jest, czy
w konkretnym stanie faktycznym możliwe jest ustalenie treści oświadczenia co do
oferowanego przedmiotu w sposób nie naruszający nadrzędnej zasady zachowania uczciwej
konkurencji pomiędzy wykonawcami. Ustawa Prawo zamówień publicznych przewiduje
instrumenty służące odczytaniu treści złożonego oświadczenia woli – jeśli jest ono
niejednoznaczne {instytucja wyjaśnień z art. 87 ust. 1 pzp}, a także służące poprawieniu
oferty – jeśli wprost nie odpowiada ona treści s.i.w.z. {instytucja poprawiania omyłek z art. 87
ust. 2 pkt 3 pzp}. Art.87 ust. 2 pkt 1 i 2 pzp obliguje natomiast zamawiającego do
poprawienia w ofercie oczywistych omyłek pisarskich oraz oczywistych omyłek
rachunkowych, z uwzględnieniem konsekwencji rachunkowych dokonanych poprawek.
W postępowaniu o zamówienie publiczne nie została bowiem wyłączona ogólna,
charakterystyczna dla prawa cywilnego zasada ustalania treści złożonego oświadczenia woli
w sposób odzwierciedlający zamiar strony i cel złożenia oświadczenia.
Sygn. akt KIO 2439/16
Jednakże istotne elementy tego oświadczenia woli – jak skonkretyzowany w sposób
wymagany przez Zamawiającego przedmiot oferowanego świadczenia – powinny się jednak
w ofercie znaleźć, w przeciwnym razie nie sposób ustalić treści tego oświadczenia bez jego
istotnej zmiany lub prowadzenia ustaleń z wykonawcą już po terminie składania ofert, co jest
niedopuszczalne na mocy klauzuli zawartej w art. 87 ust. 1 zd. 2 pzp. Zgodnie z art. 87 ust. 1
pzp w toku badania i oceny ofert zamawiający może żądać od wykonawców wyjaśnień
dotyczących treści złożonych ofert, jednakże niedopuszczalne jest prowadzenie między
zamawiającym a wykonawcą negocjacji dotyczących złożonej oferty oraz, z zastrzeżeniem
ust. 2, dokonywanie jakiejkolwiek zmiany w jej treści. Przywołane powyżej instytucje służą
jak najwierniejszemu odtworzeniu intencji wykonawcy w zakresie złożonego zamawiającemu
oświadczenia woli, odczytaniu jego treści. Zastosowanie tych instrumentów jest jednak
możliwe wtedy, gdy wykonawca w swojej ofercie wyartykułował oświadczenie woli w sposób
umożliwiający takie odczytanie bezpośrednio lub pośrednio, choćby przez pryzmat
załączonych do oferty dokumentów składanych na potwierdzenie, że przedmiot oferty
odpowiada wymaganiom zamawiającego.
Reasumując, przywołane powyżej instytucje służą jak najwierniejszemu odtworzeniu
intencji wykonawcy w zakresie złożonego zamawiającemu oświadczenia woli, odczytaniu
jego treści. Jednakże zastosowanie tych instrumentów jest możliwe tylko wtedy, gdy
wykonawca w swojej ofercie wyartykułował oświadczenie woli w sposób umożliwiający takie
odczytanie bezpośrednio lub pośrednio, choćby przez pryzmat załączonych do oferty
dokumentów składanych na potwierdzenie, że przedmiot oferty odpowiada wymaganiom
zamawiającego.
Zdaniem Izby w tej sprawie oferta Sputnika jest niezgodna z opisem przedmiotu
zamówienia w zasadniczy i nieodwracalny sposób, stąd nawet przy wykorzystaniu
powyższych instrumentów nie da się uzyskać stanu zgodności jej treści z treścią s.i.w.z.
W szczególności ponieważ zestaw testowy stanowił w tym przypadku część treści oferty
podlegającej ocenie, niemożliwe jest jego uzupełnienie lub zmiana na inny, gdyż
prowadziłoby to niedopuszczalnej zmiany treści oferty po upływie terminu składania ofert.
{rozstrzygnięcie zarzutów z pkt 1. i 3. listy zarzutów}
Ponieważ zarzut z pkt 1 listy zarzutów ma charakter niesamoistny, gdyż jeżeli nie
naruszono art. 89 ust. 1 pkt 2 pzp, nie mogło dojść do naruszenia art. 91 ust. 1 pzp, jest on
również niezasadny.
W odniesieniu do naruszenia art. 7 ust. 1 pzp, co do którego w uzasadnieniu
Sygn. akt KIO 2439/16
odwołania nie podano żadnych odrębnych okoliczności, uniemożliwia odrębne rozpoznanie
tak sformułowanego zarzutu.
Mając powyższe na uwadze, Izba – działając na podstawie art. 192 ust. 1 i 2 ustawy
pzp – orzekła, jak w pkt 1 sentencji.
O kosztach postępowania odwoławczego orzeczono stosownie do jego wyniku
na podstawie art. 192 ust. 9 i 10 ustawy pzp w zw. z § 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 (Dz. U. Nr 41, poz. 238) – obciążając Odwołującego kosztami tego postępowania,
na które złożył się uiszczony przez niego wpis.
Przewodniczący:
………………………………
………………………………
………………………………
Wcześniejsze orzeczenia:
- Sygn. akt KIO 54/17 z dnia 2017-01-27
- Sygn. akt KIO 37/17 z dnia 2017-01-26
- Sygn. akt KIO 93/17 z dnia 2017-01-24
- Sygn. akt KIO 2444/16 z dnia 2017-01-24
- Sygn. akt KIO 51/17 z dnia 2017-01-24
