KIO 2439/16 WYROK dnia 23 stycznia 2017 r.

WYROK 

z dnia 23 stycznia 2017 r. 

Krajowa Izba Odwoławcza – w składzie:  

Przewodniczący: Piotr Kozłowski 

Emil Kuriata 

Marek Koleśnikow 

Protokolant: Rafał Komoń, 

Agata Dziuban 

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 

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.  

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: 

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

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

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

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. 

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 

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, 

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 

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; 

–  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 

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 

(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” 

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. 

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 

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 

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

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 

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}   

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 

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 

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 

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, 

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.  

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 

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: 

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

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

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