KIO 739/17 WYROK dnia 26 kwietnia 2017 r.

Sygn. akt: KIO 739/17 

WYROK 

z dnia 26 kwietnia 2017 r. 

Krajowa Izba Odwoławcza   –   w składzie: 

Przewodniczący:     Anna Packo 

Protokolant:             Sylwia Muniak  

po  rozpoznaniu  na  rozprawie  w  dniu  25  kwietnia  2017  r.,  w  Warszawie,  odwołania 

wniesionego  do  Prezesa  Krajowej  Izby  Odwoławczej  w  dniu  14  kwietnia  2017  r.  przez 

wykonawców wspólnie ubiegających się o udzielenie zamówienia 

C. P. S.A. al. (…) i  

C. S.A. al. (…) 

w postępowaniu prowadzonym przez

A. R. M. ul. (…) 

przy  udziale  wykonawcy 

S.  S.  P.  Sp.  z  o.o.  ul.  (…)  zgłaszającego  przystąpienie  do 

postępowania odwoławczego po stronie zamawiającego

orzeka: 

1.  uwzględnia  odwołanie  i  nakazuje  A.  R.  M.  :  unieważnienie  czynności  badania  i 

oceny  ofert,  unieważnienie  czynności  odrzucenia  oferty  wykonawców  wspólnie 

ubiegających  się  o  udzielenie  zamówienia  C.  P.  S.A.  i  C.  S.A.,  unieważnienie 

czynności unieważnienia postępowania o udzielenie zamówienia publicznego oraz 

dokonanie powtórnej czynności badania i oceny ofert, 

2. kosztami postępowania obciąża A. R. M. i:  

2.1.  zalicza  w  poczet  kosztów  postępowania  odwoławczego  kwotę  15  000  zł  00  gr 

(słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez wykonawców 

wspólnie 

ubiegających 

się 

o 

udzielenie 

zamówienia 

C. 

P. 

S.A.  

si C. S.A. tytułem wpisu od odwołania, 

2.2. zasądza  od  A.  R.  M.  na  rzecz  wykonawców  wspólnie  ubiegających  się  o 

udzielenie  zamówienia  C.  P.  S.A.  i  C.  S.A.  kwotę  15  000  zł  00  gr  (słownie: 

piętnaście  tysięcy  złotych  zero  groszy)  stanowiącą  koszty  postępowania 

odwoławczego poniesione z tytułu połowy wpisu. 

Stosownie  do  art.  198a  i  198b  ustawy  z  dnia  29  stycznia  2004  r.  –  Prawo  zamówień 

publicznych (t.j. Dz. U. z 2015, 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 Warszawie. 

Przewodniczący:      ……………………..… 

Sygn. akt: KIO 739/17 

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

Zamawiający  –  A.  R.  M.  prowadzi  postępowanie  o  udzielenie  zamówienia  publicznego  na 

„zakup zintegrowanego oprogramowania klasy E. wraz z usługami serwisu utrzymaniowego i 

pracami  rozwojowymi”  na  podstawie  ustawy  z  dnia  29  stycznia  2004  r.  Prawo  zamówień 

publicznych  (t.j.  Dz.  U.  z  2015  r.  poz.  2164  z  późn.  zm.),  w  trybie  przetargu 

nieograniczonego. 

Ogłoszenie o zamówieniu zostało opublikowane 1 grudnia 2016 r. w Dzienniku Urzędowym 

Unii  Europejskiej  pod  numerem  2016/S  232-423298.  Wartość  zamówienia  jest  większa  niż 

kwoty określone na podstawie art. 11 ust. 8 ustawy Prawo zamówień publicznych. 

I Zarzuty i żądania odwołania: 

Odwołujący  –  wykonawcy  wspólnie  ubiegający  się  o  udzielenie  zamówienia  C.  P.  S.A.  i  C. 

S.A. wniósł odwołanie wobec: 

1. czynności odrzucenia oferty Odwołującego na podstawie art. 89 ust. 1 pkt 2 ustawy Prawo 

zamówień  publicznych  –  jako  że  jej  treść  nie  odpowiada  treści  specyfikacji  istotnych 

warunków  zamówienia,  w  sytuacji  gdy  oferta  Odwołującego  spełnia  wszystkie  wymagania 

Zamawiającego,  co  w  konsekwencji  prowadzi  do  braku  podstaw  odrzucenia  oferty,  czym 

naruszono art. 89 ust. 1 pkt 2 w zw. z art. 7 ust. 1 ustawy Prawo zamówień publicznych, 

2.  czynności  unieważnienia  postępowania  na  podstawie  art.  93  ust.  1  pkt  4  ustawy  Prawo 

zamówień publicznych – z tego powodu, iż cena najkorzystniejszej oferty przewyższa kwotę, 

którą  Zamawiający  zamierza  przeznaczyć  na  sfinansowanie  zamówienia,  w  sytuacji,  gdy 

oferta  Odwołującego  nie  powinna  być  odrzucona  i  była  merytorycznie  i  formalnie  zgodna  

z  treścią  specyfikacji  istotnych  warunków  zamówienia,  a  także  mieściła  się  w  budżecie 

Zamawiającego,  w  związku  z  czym  nie  ma  podstaw  do  unieważnienia  postępowania  na  tej 

podstawie,  gdyż  oferta  Odwołującego  jest  ofertą  najkorzystniejszą  w  rozumieniu  przepisów 

ustawy Prawo zamówień publicznych, czym naruszono art. 93 ust. 1 pkt 4 w zw. z art. 89 ust. 

1  pkt  2  w  zw.  z  art.  2  pkt  5  lit.  a,  w  zw.  z  art.  91  ust.  1  i  2  ustawy  Prawo  zamówień 

publicznych, 

3. art. 91 ust. 1 w zw. z art. 7 ust. 1 ustawy Prawo zamówień publicznych poprzez wybór jako 

najkorzystniejszej  oferty  wykonawcy  S.  S.  Sp.  z  o.o.,  podczas  gdy  oferta  ta  nie  jest  ofertą 

najkorzystniejszą. 

Odwołujący  wniósł  o  uwzględnienie  odwołania  i  nakazanie  Zamawiającemu:  unieważnienia 

czynności  unieważnienia  postępowania,  unieważnienia  czynności  oceny  ofert,  dokonanie 

ponownej  czynności  oceny  ofert  i  dokonanie  wyboru  oferty  Odwołującego  jako  oferty 

najkorzystniejszej. 

W  uzasadnieniu  Odwołujący  wskazał,  iż  za  najkorzystniejszą  ofertę  Zamawiający  uznał 

ofertę  S.  S.  P.  Sp.  z  o.o.  z  ceną  brutto  7.648.509,00  PLN.  Odwołujący  złożył  ofertę  w 

wysokości  3.952.601,31  PLN  brutto.  Kwota,  jaką  Zamawiający  zamierzał  przeznaczyć  na 

sfinansowanie  zamówienia  to  4.784.700,00  PLN  brutto.  W  postępowaniu  złożono  dwie 

oferty.  Oferta  Odwołującego  została  odrzucona  na  podstawie  art.  89  ust.  1  pkt  2  ustawy 

Prawo  zamówień  publicznych,  tj.  jej  treść  nie  odpowiada  treści  specyfikacji  istotnych 

warunków  zamówienia.  Jednocześnie  Zamawiający  wskazał,  że  unieważnia  postępowanie 

na  podstawie  art.  93  ust.  1  pkt  4  ustawy  Prawo  zamówień  publicznych,  gdyż  cena 

najkorzystniejszej  oferty  przewyższa  kwotę,  którą  Zamawiający  zamierza  przeznaczyć  na 

sfinansowanie zamówienia.  

Odwołujący  nie  zgadza  się  z  decyzją  o  odrzuceniu  jego  oferty  oraz  z  decyzją  

o unieważnieniu postępowania. 

Odnośnie  zarzutu  1.  wskazanego  w  informacji  o  odrzuceniu  oferty  dotyczącego  tego,  że 

oferta  swoim  zakresem  nie  obejmuje  wdrożenia  podstawowych  funkcjonalności 

przewidzianych jako funkcjonalności Magazynu Wysokiego Składowania. Zamawiający czyni 

zarzut  Odwołującemu,  iż  zadeklarował  on  w  ramach  oferty  „jedynie”  38  wymagań  na  107 

wymagań  wyspecyfikowanych  przez  Zamawiającego  dla  obszaru  WMS,  co  stanowi  udział 

35,51% wszystkich wymagań WMS. 

Odwołujący nie podziela argumentów Zamawiającego. 

Zgodnie z opublikowaną dokumentacją przetargową Zamawiający ustalił 8 kryteriów oceny, 

wśród  których  ujęto  m.in.  kryterium  nr  3:  ocena  funkcjonalności  (25%)  –  stopień  spełnienia 

stawianych  w  przedmiocie  zamówienia  wymagań  funkcjonalnych  opisanych  szczegółowo  

w  załączniku  nr  1  do  opisu  przedmiotu  zamówienia  oraz  kryterium  nr  7:  ocena  spełnienia 

wymagań  pozafunkcjonalnych  (5%)  –  stopień  spełnienia  stawianych  w  przedmiocie 

zamówienia  wymagań  pozafunkcjonalnych  opisanych  szczegółowo  w  opisie  przedmiotu 

zamówienia.  Przyjętą  przez  Zamawiającego  konstrukcję  kryteriów  oceny  trudno  uznać  za 

akcentującą  w  sposób  szczególny  funkcjonalność  oferowanego  systemu  E.,  w  tym  m.in. 

obszar Magazynu Wysokiego Składowania. 

W  treści  załącznika  nr  1  do  specyfikacji  istotnych  warunków  zamówienia  (opis  przedmiotu 

zamówienia),  Zamawiający  przedstawił,  jak  należy  wypełniać  Arkusz  Funkcjonalności 

(Załącznik nr 1 do opisu przedmiotu zamówienia) i jak oferenci powinni interpretować statusy 

nadane przez Zamawiającego wymaganiom funkcjonalnym i pozafunkcjonalnym.  

Pkt  3.  Wymagania  funkcjonalne:  wymagania  dla  obszarów  funkcjonalnych  zawarte  są  

w  załączniku  nr  1  do  opisu  przedmiotu  zamówienia.  Zostały  one  identyfikowane  w  oparciu  

o  predefiniowane  tabele  PASS,  uzupełniane  w  trakcie  wywiadów  o  dodatkowe,  wymagane 

przez 

użytkowników 

funkcjonalności. 

Każdemu 

obszarowi 

przypisane 

zostały 

funkcjonalności,  które  zostaną  poddane  ocenie  przez  Zamawiającego.  Funkcjonalności, 

którym  w  kolumnie  „Poziom”  przypisano  wartość  2,  są  wymaganiami  kluczowymi  dla 

Zamawiającego,  których  spełnienie  stanowi  jedno  z  podstawowych  kryteriów  oceny  ofert. 

Funkcjonalności, którym w kolumnie „Poziom” przypisano  wartość 1, zostały określone jako 

ważne  lub  mogące  okazać  się  przydatne  w  przyszłości.  Poziom  spełnienia  tych 

funkcjonalności będzie stanowił dodatkowe kryterium oceny rozwiązania. 

Przyjęta przez Zamawiającego definicja mówi wyraźnie, że choć wymagania z poziomem 2. 

są  wymaganiami  „kluczowymi”,  to  stanowią  jedynie  jedno  z  kryteriów  oceny,  a  zatem 

Zamawiający  dopuścił  możliwość  dowolnego  oznaczania  przez  oferentów  wymagań 

wyspecyfikowanych  w  Arkuszach  Funkcjonalności.  Potwierdza  to  dalszy  opis  punktu  3. 

przedstawiający  sposób  wypełniania  arkuszy  wymagań  dedykowanych  dla  obszarów 

działalności  Zamawiającego:  w  przypadku,  gdy  oferowany  system  spełnia  daną 

funkcjonalność  w  standardzie  należy,  w  kolumnie  „STD”  wpisać  1.  Jeżeli  dana 

funkcjonalność nie jest możliwa do zrealizowania w proponowanym systemie, należy wpisać 

0.  Każdy  inny  zapis  będzie  traktowany  jak  wartość  0.  Jeżeli  dana  funkcjonalność  zostanie 

dostarczona  w  wyniku  modyfikacji  systemu,  w  kolumnie  „MDF”  należy  wpisać  1  natomiast  

w  kolumnie  „STD”  wstawić  wartość  0.  Umieszczenie  zapisu  1  w  kolumnie  „MDF”  jest 

równoznaczne z zapewnieniem Zamawiającemu modyfikacji systemu o daną funkcjonalność 

w  ramach  oferty.  W  przypadku,  gdy  wykonawca  umieścił,  w  którymś  z  wierszy  kolumny 

„MDF”  zapis  1,  proszony  jest  o  wypełnienie  kolumny  „Uwagi”  informacjami  dotyczącymi 

krótkiego  opisu  zmian  dostosowujących  lub  modyfikacji  systemu  oraz  szacunkowej 

przewidywanej  pracochłonności  (roboczogodzin).  Ostatni  wiersz  tabeli  2.  „Przykład 

wypełnienia  tabeli  PASS  przez  Wykonawcę”  wskazuje  dobitnie,  że  Zamawiający  założył 

możliwość  niedeklarowania  przez  oferentów  realizacji  wymagań  (w  tym  „kluczowych”) 

ujętych  w  Arkuszach  Funkcjonalności  dla  wymagań  funkcjonalnych  (w  tym  dla  wymagań  

z  obszaru  WMS).  Analogicznie,  również  dla  wymagań  pozafunkcjonalnych  Zamawiający 

przyjął 

podobne 

założenia: 

pkt 

wymagania 

pozafunkcjonalne: 

wymagania 

pozafunkcjonalne  zawarte  są  w  załączniku  nr  1  do  opisu  przedmiotu  zamówienia,  arkusz 

„PFU”.  Wymagania  pozafunkcjonalne  zostały  zidentyfikowane  w  oparciu  o  predefiniowane 

tabele PASS, uzupełniane w trakcie wywiadów o dodatkowe, wymagane przez użytkowników 

funkcjonalności,  które  zostaną  poddane  ocenie  przez  Zamawiającego.  Również  dla 

wymagań  pozafunkcjonalnych  przyjęta  przez  Zamawiającego  definicja  wymagań 

„kluczowych”  oznaczanych  w  Arkuszu  Funkcjonalności  w  kolumnie  „Poziom”  cyfrą  „2”, 

wskazuje, że choć są to wymagania „kluczowe” dla Zamawiającego, to stanowią tylko jedno 

z  kryteriów  oceny  proponowanego  rozwiązania.  Tym  samym  w  przypadku,  gdy  oferowany 

system  spełnia  daną  funkcjonalność,  należy  w  kolumnie  „Spełnia”  wpisać  1.  Jeżeli  dana 

funkcjonalność nie jest możliwa do zrealizowania w proponowanym systemie, należy wpisać 

0. Każdy inny zapis będzie traktowany jak wartość 0 itd. Zarówno opis sposobu wypełnienia 

arkusza  zawierającego  wymagania  pozafunkcjonalne  („Jeżeli  dana  funkcjonalność  nie  jest 

możliwa do zrealizowania w proponowanym systemie, należy wpisać 0”), jak i ostatni wiersz 

Tabeli 4. „Przykład wypełnienia tabeli PASS przez Wykonawcę” wskazuje jednoznacznie, że 

Zamawiający założył możliwość niedeklarowania przez oferentów realizacji wymagań (w tym 

„kluczowych”)  ujętych  w  Arkuszu  Funkcjonalności  dla  wymagań  pozafunkcjonalnych.  Także 

wskazane  przez  Zamawiającego  wzory,  w  oparciu  o  które  będzie  dokonywał  oceny 

przyznania punktów w ramach kryteriów nr 3 ocena funkcjonalności i nr 7 ocena spełnienia 

wymagań  pozafunkcjonainych  dowodzą,  iż  oferenci  mieli  możliwość  dowolnego 

deklarowania  (spełniania  lub  niespełniania)  wymagań,  zyskując  lub  tracąc  jedynie  punkty  

w kryteriach oceny ofert. . 

Dla  kryterium  nr  3  jest  to  wzór:  kryterium  oceny  funkcjonalności  będzie  rozpatrywane  na 

podstawie  formularza  wymagań  funkcjonalnych  wypełnionego  przez  wykonawcę.  Ocena 

funkcjonalności  będzie  obliczana  na  podstawie  wzoru:  PF=(PF2ofs+0,3*PF2ofm)* 

75/PF2max+(PF1ofs+0,3*PF1ofm)*25/PF1max,  gdzie:  PF  –  punkty  przyznane  za  ocenę 

funkcjonalności, PF2ofs - ilość spełnionych wymagań z priorytetem 2 w standardzie systemu, 

PF2ofm  –  ilość  spełnionych  wymagań  z  priorytetem  2  w  modyfikacji,  PF2max  –  ilość 

wymagań  z  priorytetem  2  zdefiniowanych  w  tabelach  PASS,  PFlofs  –  ilość  spełnionych 

wymagań  z  priorytetem  1  w  standardzie  systemu,  PFlofm  –  ilość  spełnionych  wymagań  

z  priorytetem  1  w  modyfikacji,  PFlmax  –  ilość  wymagań  z  priorytetem  1  zdefiniowanych  

w  tabelach  PASS.  Przy  czym  75%  punktacji  przypada  na  realizację  wymagań  2,  25% 

punktacji  przypada  na  realizację  wymagań  1,  spełnienie  wymagania  w  standardzie  ma 

współczynnik 1, spełnienie wymagania w modyfikacji ma współczynnik 0,3.  

Powyższy  wzór  dowodzi,  że  Zamawiający  skonstruował  kryterium  oceny  funkcjonalności  

w sposób pozwalający  wykonawcom na oferowanie rozwiązania spełniającego różną liczbę 

wymagań,  zatem  wymagania  „kluczowe”  nie  miały  charakteru  wymagań  obligatoryjnych  

i zgodnie z powyższym wzorem umożliwiały  wykonawcy uzyskanie większej liczby punktów 

w związku z przeliczaniem ich przez współczynnik 75%. 

Dla  kryterium  nr  7  jest  to  następujący  wzór:  kryterium  oceny  spełnienia  wymagań 

pozafunkcjonalnych 

będzie 

rozpatrywane 

na 

podstawie 

formularza 

wymagań 

pozafunkcjonalnych wypełnionego przez wykonawcę. Ocena będzie obliczana na podstawie 

wzoru:  PNF  =  PF2of*  75/  PF2max  +  PFlof*  25/  PFlmax  gdzie:  PNF  -  punkty  przyznane  za 

ocenę  wymagań  pozafunkcjonalnych,  PF2of  -  ilość  spełnionych  wymagań  z  priorytetem  2, 

PF2max  -  ilość  wymagań  z  priorytetem  2  zdefiniowanych  w  tabelach  PASS,  PFlof  -  ilość 

spełnionych  wymagań  z  priorytetem  1,  PFlmax  -  ilość  wymagań  z  priorytetem  1 

zdefiniowanych  w  tabelach  PASS.  75%  punktacji  przypada  na  realizację  wymagań  2,  25% 

punktacji przypada na realizację wymagań 1.  

Również  w  przypadku  wymagań  pozafunkcjonalnych  ww.  wzór  dowodzi,  że  Zamawiający 

skonstruował  kryterium  oceny  spełnienia  wymagań  pozafunkcjonalnych  w  sposób 

pozwalający  oferentom  na  oferowanie  rozwiązania  spełniającego  różną  liczbę  wymagań,  

w  tym  „kluczowych”  uzyskując  zgodnie  z  przywołanym  wzorem  określoną  liczbę  punktów,  

a  zatem  wymagania  „kluczowe”  nie  miały  charakteru  wymagań  obligatoryjnych,  lecz 

umożliwiały  oferentowi  uzyskanie  większej  liczby  punktów  w  związku  z  przeliczaniem  ich 

przez współczynnik 75%. 

Zamawiający  zatem  pozostawił  wykonawcom  dowolność  w  deklarowaniu  oferowanych 

funkcjonalności zamieszczonych w Arkuszu Funkcjonalności, których łączna liczba wyniosła 

2.223  wymagania,  przy  czym  rezygnacja  z  deklarowania  danej  liczby  wymagań 

funkcjonalnych i pozafunkcjonalnych wiązała się z utratą punktów.  

W  ocenie  Odwołującego  niezrozumiałe  jest  zatem  stanowisko  Zamawiającego,  że 

Odwołujący zadeklarował w ramach obszaru Magazynu Wysokiego Składowania jedynie 38 

wymagań i z tego powodu oferta Odwołującego winna być odrzucona. Argument ten nie ma 

oparcia  w  warunkach  postępowania.  Oferenci  mieli  możliwość  zadeklarowania  w  Arkuszu 

Funkcjonalności  dowolnej  liczby  funkcjonalności  i  do  ich  oceny  należała  decyzja,  jak 

skalkulować ofertę w odniesieniu do zadeklarowanego zakresu funkcjonalnego, w tym ocena 

ryzyka/zasadności  utraty  punktów  w  związku  z  deklarowaniem  mniejszej  liczby 

funkcjonalności.  Zamawiający  wręcz  musiał  się  liczyć  z  tym,  że  oferenci  mogą  złożyć 

poprawne  formalnie  oferty  nawet  w  całości  rezygnując  z  deklarowania  jakichkolwiek 

wymagań  z  obszaru  WMS,  ponieważ  konstrukcja  kryteriów  oceny  nie  zakazywała  takiej 

praktyki. 

Niezrozumiała  też  jest  argumentacja  dotycząca  zadeklarowanych  przez  Odwołującego  

w  ofercie  38  wymagań  z  obszaru  WMS,  w  których  w  ocenie  Zamawiającego  brak  jest 

„podstawowych”  wymagań  niezbędnych  do  obsługi  WMS.  Sam  Zamawiający  dokonywał 

podziału  wymagań  funkcjonalnych  na  poszczególne  obszary  merytoryczne  zamówienia,  

w  tym  m.in.  dokonał  podziału  wymagań  na  obszar  Gospodarka  Magazynowa  (GM)  

i  Magazyn  Wysokiego  Składowania  (WMS),  a  zatem  czynienie  zarzutu  Odwołującemu,  że 

zadeklarowane przez Odwołującego w obszarze funkcjonalności WMS (wyspecyfikowanych 

przez  Zamawiającego)  nie  stanowią  w  ocenie  Zamawiającego  zakresu  funkcjonalnego 

obszaru WMS, a Jedynie „powtórzenie” funkcjonalności obszaru GM, jest niezrozumiałe. 

Zamawiający w specyfikacji istotnych warunków zamówienia założył też możliwość realizacji 

„prac  rozwojowych  i  dodatkowych”,  a  w  formularzu  ofertowym  wykonawcy  deklarowali 

stawkę za roboczogodzinę tych prac. W ocenie Odwołującego istnieje więc możliwość, aby 

wybrane  elementy  funkcjonalne  wyspecyfikowane  w  Arkuszach  Funkcjonalności,  

a niezadeklarowane w ofercie, były realizowane w ramach dodatkowych prac realizowanych 

po stawce wskazanej przez wykonawcę w formularzu ofertowym. 

Zamawiający  przytacza  definicję  WMS,  z  którą  Odwołujący  nie  zamierza  polemizować,  ale 

poniższe  nie  ma  w  ocenie  Odwołującego  żadnego  znaczenia  w  świetle  przyjętych  przez 

Zamawiającego  kryteriów  ocen.  Oczekiwania  Zamawiającego  zaakcentowane  w  piśmie  

o  unieważnieniu  nie  korespondują  z  kształtem  dokumentacji  przetargowej  i  warunkami 

zakreślonymi w kryteriach oceny przez samego Zamawiającego. 

Za  chybiony  argument  należy  również  uznać  weryfikację  przez  Zamawiającego  strony 

produktowej oferowanego w ramach niniejszego postępowania systemu C. E. E. Zgodnie z 

warunkami  zakreślonymi  w  dokumentacji  przetargowej  oferenci  mieli  możliwość 

deklarowania rozbudowy/modyfikacji (w toku procesu wdrożeniowego) oferowanego systemu 

E. o funkcjonalności, których ich systemy E. nie posiadają na dzień składania ofert. A zatem 

oferowany przez Odwołującego system C. E. E. nie musiał na dzień składania ofert posiadać 

w swoim zakresie funkcjonalności obsługi WMS. 

Odnośnie  zarzutu  2.  wskazanego  w  informacji  o  odrzuceniu  oferty  –  niezgodność 

oferowanego  rozwiązania  z  wymaganiami  bezwzględnymi  sprecyzowanymi  przez 

Zamawiającego  w  rozdziale  5.  załącznika  nr  1  do  specyfikacji  istotnych  warunków 

zamówienia (opisie przedmiotu zamówienia).  

Zamawiający powołał się na trzy punkty z wymagań bezwzględnych:  

„6. Wszystkie obszary Systemu powinny korzystać z jednej zbiorczej kartoteki kontrahentów. 

Kartoteka,  powinna  być  podzielona  co  najmniej  na  kontrahentów  wewnętrznych  – 

pracowników  Agencji  i  kontrahentów  zewnętrznych  –  klientów.  W  ramach  kartoteki  będzie 

możliwość definiowania nowych grup kontrahentów”; 

„14. System będzie posiadać możliwość identyfikacji użytkownika wprowadzającego zmiany 

do Systemu i historię wprowadzanych zmian z uwzględnieniem daty i czasu”; 

„15.  System  będzie  zapewniać  rejestrację  realizowanych  funkcji  eksportu  danych  wraz  ze 

wskazaniem użytkownika, daty oraz zakresu eksportowanych danych”. 

Odwołujący  nie  podziela  argumentów  Zamawiającego.  Wskazane  przez  Zamawiającego 

wymagania  bezwzględne  nie  zostały  ujęte  w  Arkuszach  Funkcjonalności,  bowiem  literalne 

brzmienie  treści  przytoczonych  wymagań  nie  ma  odzwierciedlenia  w  wymaganiach 

podlegających  deklarowaniu  przez  oferentów  zgodnie  z  Arkuszami  Funkcjonalności.  Jeśli 

Zamawiający  oczekiwał  deklarowania  przez  oferentów  ww.  wymagań,  powinien  umieścić  je 

w  ich  literalnym  i  dokładnym  brzmieniu,  przy  czym  powinien  wówczas  dla  tych  wymagań 

wyłączyć  możliwość  dowolnego  deklarowania  przez  oferentów  spełnienia  przedmiotowych 

wymagań  z  uwagi  na  ich  obligatoryjność.  Zamawiający  tego  nie  uczynił,  a  w  piśmie  

o  odrzuceniu  oferty  Odwołującego  „mapuje”  wymagania  bezwzględne  z  rozdziału  5.  na 

wybrane  z  Arkuszy  Funkcjonalności  wymagania,  które  podlegały  fakultatywnemu 

deklarowaniu  przez  oferentów:  Zamawiający  powołał  się  na  pkt  6  „Baza  kontrahentów 

wspólna  dla  wszystkich  spółek  i  oddziałów  (wielofirmowość  i  wielooddziałowość),  jednak 

treść  punktu  6  nie  odpowiada  treści  wymagania  SID1.2,  gdyż  w  treści  punktu  6.  nie  ma 

wymogu m.in. obsługi „wielu spółek” i „wielofirmowości”. Nie jest zatem zrozumiałe, dlaczego 

Zamawiający łączy oba wymagania. Wymaganie zakreślone w punkcie 6. akcentuje wymóg, 

aby  wszystkie  obszary  systemu  korzystały  z  jednej  zbiorczej  kartoteki  kontrahentów 

(podzielonej  co  najmniej  na  kontrahentów  wewnętrznych  –  pracowników  Agencji  

i  kontrahentów  zewnętrznych  –  klientów)  i  aby  w  ramach  kartoteki  była  możliwość 

definiowania  nowych  grup  kontrahentów.  Tak  sformułowane  wymaganie  spełnia 

zaoferowany przez Odwołującego system C. E. E., którego jednym z bazowych modułów jest 

Centralna  Kartoteka  Kontrahentów  (CKK),  która  umożliwia  rejestrację  danych,  a  także 

grupowanie  podmiotów  występujących  w  otoczeniu  danej  organizacji  (instytucji),  

w  oparciu  o  definiowalne  przez  użytkownika  kryteria.  Wymaganie  SID1.2  akcentuje 

natomiast  aspekt  wspólnej  bazy  kontrahentów  w  środowisku  wielofirmowym  (czyli  

w  podmiotach  typu  grupa  kapitałowa  złożona  z  wielu  spółek),  co  nie  koresponduje  

z kontekstem wymagania nr 6. Odwołujący nie zadeklarował w ofercie realizacji wymagania 

SID1.2 z uwagi na to, że z wymagań opisu przedmiotu zamówienia nie wynikała konieczność 

oferowania  systemu  E.  w  modelu  wielofirmowym.  Odwołujący  zadeklarował  jednak 

spełnienie wymagania SID1.1 baza kontrahentów wspólna dla wszystkich modułów systemu 

ERP,  co  potwierdza,  że  zaoferowany  system  C.  E.  E.  zapewnia  w  standardzie 

funkcjonalność obsługi „bazy kontrahentów” wspólnej dla wszystkich modułów systemu E. 

Analogicznie  spełnienie  funkcjonalności  obsługi  „Kartoteki  kontrahentów”  wspólnej  dla 

wszystkich  modułów  systemu  E.,  Odwołujący  potwierdził  również  przy  wymaganiu  ZAK1.5. 

kartoteka  kontrahentów  wspólna  dla  wszystkich  modułów  systemu  E.  Odwołujący 

zadeklarował  również  w  swojej  ofercie  wymaganie  z  kategorii  określanej  przez 

Zamawiającego  jako  „ważne  lub  mogące  okazać  się  przydatne  w  przyszłości”  (oznaczone  

w kolumnie „Poziom” cyfrą 1), a związane z możliwością prowadzenia rejestru „potencjalnych 

kontrahentów”.  

Każde  z  przywołanych  powyżej  wymagań  potwierdza,  że  oferta  Odwołującego  spełnia 

wymaganie zakreślone punktem 6. rozdziału 5 załącznika nr 1. 

Co do punktu 14. rozdziału 5. załącznika nr 1 – SID8.2 śledzenie historii i stopnia realizacji 

zamówień  na  poziomie  pozycji  zamówienia,  RI2.26  historia  zmian  planu  (osoba 

odpowiedzialna  za  wprowadzenie  zmian),  GM1.16  historia  zmian  stawki  VAT,  GM  1.18 

historia zmian stawki podatku akcyzowego, GM1.20 historia zmian stawki cła. 

Także  w  tym  przypadku  brak  jest  literalnego  odzwierciedlenia  wymagań  z  rozdziału  5. 

załącznika nr 1 w wymaganiach Arkusza Funkcjonalności, gdyż brzmienie treści wymagania 

z  punktu  14.  nie  odpowiada  przywołanym  wymaganiom  z  Arkusza  Funkcjonalności. 

Wymaganie  nr  14  odnosi  się  do  wymagania  ogólnego  związanego  z  „auditingiem”  operacji 

dokonywanych  przez  użytkowników  w  systemie,  a  przywołane  przez  Zamawiającego 

wymagania SID8.24, RI2.26, GM1.16, GM1.18 i GM1.20 to konkretne wymagania biznesowe 

z obszarów SID (Sprzedaż i Dystrybucja), Rl (Remonty I Inwestycje) oraz GM (Gospodarka 

Magazynowa). 

Odwołujący  zadeklarował  w  swojej  ofercie  wymaganie,  które  w  ocenie  Odwołującego 

potwierdza  spełnienie  oczekiwań  Zamawiającego  ujętych  w  punkcie  14.  rozdziału  5.,  tj. 

wymaganie  OG4.13  monitorowanie  tworzenia/modyfikacji  danych,  rejestrowanie  kto  i  kiedy 

wprowadził  zmianę  (również  usunął  rekord).  Oferowany  system  C.  E.  E.  posiada 

funkcjonalność 

tzw. 

„auditingu”. 

Dla 

wszystkich 

rekordów 

wprowadzanych  

w systemie C. E. E. jest zapamiętywany użytkownik, który dany rekord utworzył, a także data 

i 

godzina 

wprowadzenia 

rekordu 

do 

bazy 

oraz 

nazwa 

komputera,  

z którego dokonano operacji. System zapamiętuje również analogiczne informacje dotyczące 

ostatniej modyfikacji rekordu. Dane kto i kiedy utworzył lub zmodyfikował rekord określane są 

jako  informacje  auditingowe.  Administrator  ma  możliwość  włączenia  audytu  systemu  na 

wybranych  polach  tabeli. W  momencie  wstawienia,  modyfikacji  lub  usunięcia  danych  z  pól, 

informacje  o  tym  zostaną  zapisane  i  będą  dostępne  do  wglądu  z  raportu  „Aktywność 

użytkowników”.  Zapisywane  będą  przy  tym  szczegóły  operacji,  tj.  wartości  „przed”  i  „po” 

audytowanych  pól.  Istnieje  również  możliwość  wygenerowania  raportu  przedstawiającego 

informacje  audytowe  systemu,  to  znaczy  zmiany  na  polach  audytowanych.  Włączenie  

i wybór śledzonych operacji należy do administratora systemu C. E. E. 

Odwołujący  nie  widzi  więc  związku  pomiędzy  typowo  „administracyjno-technicznym” 

ogólnym  wymaganiem  z  punktu  14.  rozdziału  5.  załącznika  nr  1,  które  spełnia  (na  dowód 

czego zadeklarował w ofercie spełnienie wymagania OG4.13), a konkretnymi wymaganiami 

„biznesowymi”  z  obszarów  SID,  Rl  i  GM  ujętymi  w  Arkuszu  Funkcjonalności.  Poprzez 

mechanizm  „auditingu”  administrator  Zamawiającego  będzie  miał  możliwość  weryfikacji 

zmiany  danych,  o  których  mowa  w  wymaganiach  biznesowych,  ale  w  ujęciu  typowo 

„administracyjnym”, czyli sięgając do danych zapisywanych w tzw. logach systemu. 

Wymaganie  SID8.24  „śledzenie  historii  i  stopnia  realizacji  zamówień  na  poziomie  pozycji 

zamówienia” odnosi się  do konkretnego procesu biznesowego dostępnego dla użytkownika  

z  poziomu  formatki  systemu.  Ponieważ  wymaganie  akcentuje  również  „śledzenie  stopienia 

realizacji  zamówień  na  poziomie  pozycji  zamówienia”,  oferent  nie  deklarował 

przedmiotowego wymagania w ofercie. 

Wymaganie RI2.26 „historia zamian planu (osoba odpowiedzialna za wprowadzenie zmian)” 

to również wymaganie typowo biznesowe realizowane przez użytkownika/operatora systemu 

w  obszarze  Remonty  i  Inwestycje.  Z  treści  wymagania  wynika,  że  akcent  położony  jest  na 

rejestrowanie  danych  o  osobie  odpowiedzialnej  za  wprowadzenie  zmian,  a  nie  na  osobie 

dokonującej zmiany (a mogą to być oczywiście dwie różne osoby). Poza tym RI2.26 to jedno 

z  wymagań  z  obszaru  Rl  (Remonty  i  Inwestycje),  a  wymagania  z  obszaru  Rl  są 

wymaganiami  opcjonalnymi,  które  nie  były  nawet  oceniane  w  zakresie  kryterium 

funkcjonalności. 

Wymaganie  GM1.16  „dane  materiałów  i  usług,  historia  zmian  stawki  VAT”  odnosi  się  do 

konkretnego  procesu  biznesowego  dostępnego  dla  użytkownika  z  poziomu  formatki 

systemu, i oferent ocenił, że realizacja wymagania wiązałaby się z dodatkową konfiguracją, 

co  w  efekcie  podnosiłoby  cenę  oferty.  Podobne  przyczyny  wiązały  się  z  brakiem 

deklarowania w ofercie realizacji wymagań GM1.18 „dane materiałów i usług, historia zmian 

stawki podatku akcyzowego” i GM1.20 „dane materiałów i usług, historia zmian stawki cła”. 

Wymagania  „biznesowe”  nie  były  jednak  wymaganiami  obligatoryjnym  i  nie  korespondują  

z  wymaganiem  z  punktu  14.  rozdziału  5.  załącznika  nr  1,  a  Odwołujący  zadeklarował  

w  ofercie  wymaganie  OG4.13,  które  potwierdza  spełnienie  oczekiwań  Zamawiającego  

w omawianym zakresie. 

Również argumentacja dotycząca punktu nr 15 rozdziału 5. załącznika nr 1 nie jest zasadna. 

Zgodnie  z  wymaganiem  OG3.19  system  powinien  zapewniać  możliwość  eksportu  wg 

wcześniej  zdefiniowanych  szablonów  formularzy  do  plików  formatu  xls,  z  zachowaniem 

uwzględnionych  w  formularzach  list  słownikowych,  typów  danych,  warunków  walidujących 

spójność  i  zakres  danych;  SID2.2T  eksport  cenników  do  MS  Word,  MS  Excel;  SID6.18 

możliwość eksportu oferty do MS Word, MS Excel, Open Office. 

Treść  wymagania  odnosi  się  do  „rejestracji”  realizowanych-funkcji  eksportu,  a  nie  do 

„możliwości  eksportu”  oferowanego  systemu.  Zamawiający  łączy  wymaganie  nr  15  

z  wymaganiem  ogólnym  OG3.19  oraz  wymaganiami  biznesowymi  obszaru  SID  (Sprzedaż  

i  Dystrybucja),  które  mówią  o  możliwościach  eksportu,  odpowiednio:  „wcześniej 

zdefiniowanych  szablonów  formularzy  do  plików  formatu  xls,  cenników  i  ofert.  Żadne  

z  przywołanych  przez  Zamawiającego  wymagań  nie  odnosi  się  do  możliwości  „rejestracji” 

realizowanych funkcji eksportu danych wraz ze wskazaniem użytkownika, daty oraz zakresu 

eksportowanych danych. 

Wymaganie  OG3.19  akcentuje  możliwość  eksportu  według  wcześniej  zdefiniowanych 

szablonów formularzy do plików formatu xls, z zachowaniem uwzględnionych w formularzach 

list słownikowych, typów danych, warunków walidujących spójność i zakres danych. Z kolei 

wymaganie SID2.21 kładzie nacisk na możliwość eksportowania cenników do MS Word, MS 

Excel. Podobnie SID6.18 podkreśla możliwość eksportu oferty do MS Word, MS Excel, Open 

Office.  Żadne  z  tych  wymagań  nie  ma  zatem  związku  z  wymaganiem  15.  Zamawiający 

wskazał na konkretne wymagania „biznesowe”, które nie były  wymaganiami obligatoryjnymi  

i które nie korespondują z wymaganiem z punktu 15.  

Realizację  wymagania  nr  15.  Odwołujący  zamierza  realizować  poprzez  wspomniany 

mechanizm  „auditingu”  systemu  C.  E.  E.,  co  potwierdza  deklaracja  z  punktu  OG4.13 

monitorowanie  tworzenia/modyfikacji  danych,  rejestrowanie  kto  i  kiedy  wprowadził  zmianę 

(również usunął rekord). 

Zgodnie  z  treścią  art.  89  ust.  1  pkt  2  ustawy  Prawo  zamówień  publicznych  zmawiający 

odrzuca  ofertę,  eżeli  jej  treść  nie  odpowiada  treści  specyfikacji  istotnych  warunków 

zamówienia, z zastrzeżeniem art. 87 ust. 2 pkt 3. Odrzucenie oferty na ww. podstawie może 

mieć  miejsce  wyłącznie,  gdy  istnieje  niezgodność  treści  ofert  z  wymogami  specyfikacji 

istotnych  warunków  zamówienia  wyartykułowanymi  w  sposób  jednoznaczny.  Podstawą 

odrzucenia  oferty  może  być  tylko  niespełnienie  wymagań  wyartykułowanych  w  specyfikacji 

istotnych 

warunków 

zamówienia 

lub 

w 

wyjaśnieniach 

do 

specyfikacji. 

Oferta 

nieodpowiadająca treści specyfikacji to taka, która jest sporządzona odmiennie, niż określają 

to  postanowienia  specyfikacji  istotnych  warunków  zamówienia.  Odmienność  ta  powinna 

przejawiać  się  przede  wszystkim  w  zakresie  proponowanego  przedmiotu  zamówienia  czy 

sposobu  jego  realizacji.  Wszelkie  niejasności  należy  rozpatrywać  na  korzyść  wykonawców. 

Funkcjonalność  przedmiotu  zamówienia  wymagana  bezwzględnie  w  ramach  opisu 

przedmiotu zamówienia i której niespełnienie skutkuje odrzuceniem oferty na podstawie art. 

89  ust.  1  pkt  2  ustawy  Prawo  zamówień  publicznych,  jest  czym  innym  niż  funkcjonalność 

będąca  kryterium  oceny  ofert,  w  ramach,  której  zamawiający  dopuszcza  różne  możliwe 

opcje,  a  najbardziej  lub  najmniej  pożądanym  przyznaje  odpowiednio  większą  lub  mniejszą 

liczbę punktów.  

Zamawiający  rozbudował  znacząco  kryteria  oceny  ofert.  Funkcjonalności  ważne,  kluczowe, 

czy  jakkolwiek  inaczej  wskazane  przez  Zamawiającego,  będące  tylko  i  wyłącznie  kryterium 

oceny  ofert,  w  postaci  kryteriów  m.in.  funkcjonalnych  i  pozafunkcjonalnych,  którym 

każdorazowo  przyznawał  mniejszą  lub  większą  ilość  punktów,  nie  mogły  być  podstawą  do 

odrzucenia  oferty  Odwołującego.  Oferta  złożona  przez  Odwołującego  w  pełni  była  zgodna  

z  merytoryczną  zawartością  specyfikacji  istotnych  warunków  zamówienia  i  jakiekolwiek 

elementy  oferty  nie  zostały  sporządzone  odmiennie  do  zapisów  specyfikacji  istotnych 

warunków  zamówienia.  Ponadto,  skoro  Zamawiający  nie  wskazał  minimalnych  wymogów  

w  poszczególnych  kryteriach,  tylko  pozostawił  swego  rodzaju  dowolność  każdemu 

wykonawcy w konstruowaniu oferty, to niedopuszczalne jest egzekwowanie takich wymogów 

na  etapie  oceny  ofert.  Zamawiający  zatem  ocenił  ofertą  Odwołującego  niezgodnie  

z  zasadami,  które  sam  określił  w  specyfikacji  istotnych  warunków  zamówienia,  przez  co 

naruszył  zarówno  art.  91  ust.  1,  jak  i  określone  w  art.  7  ust.  1  ustawy  Prawo  zamówień 

publicznych  zasady  prowadzenia  postępowania  z  zapewnieniem  uczciwej  konkurencji  

i  równego  traktowania  wykonawców.  Wykonawcy  biorący  udział  w  postępowaniu  

o  udzielenie  zamówienia  publicznego  nie  mają  obowiązku  badać  zasadności  ani 

racjonalności  działań  zamawiającego  przy  konstruowaniu  treści  specyfikacji  istotnych 

warunków  zamówienia.  Swoją  wadliwą  decyzją  Zamawiający  pozbawia  Odwołującego, 

działającego  w  dobrej  wierze  i  w  zaufaniu  do  treści  specyfikacji  istotnych  warunków 

zamówienia  przygotowanej  przez  Zamawiającego,  możliwości  uzyskania  zamówienia 

publicznego, a w efekcie zawarcia umowy. 

II Stanowisko zamawiającego  

Zamawiający wniósł o oddalenie odwołania.  

Odnośnie zarzutu 1. wskazanego w informacji o odrzuceniu oferty Zamawiający wskazał, iż 

Odwołujący  zniekształca  postawiony  przez  Zamawiającego  zarzut.  Według  Odwołującego 

powodem  odrzucenia  jego  oferty  jest  to,  że  nie  zadeklarował  spełnienia  wymagań 

przypisanych do obszaru funkcjonalnego „Magazyn wysokiego składowania”, które nie miały 

charakteru wymagań obligatoryjnych. Tymczasem istota zarzutu sprowadza się do tego, że 

oferowane  przez  Odwołującego  oprogramowanie  C.  E.  E.  w  ogóle  nie  obejmuje  obsługi 

posiadanych przez Zamawiającego magazynów wysokiego składowania, czego Odwołujący 

zdaje  się  nie  zauważać.  Odwołujący  stoi  na  stanowisku,  że  oferta  nie  musiała  obejmować 

swoim  zakresem  wdrożenia  Systemu  w  obszarze  Magazyn  Wysokiego  Składowania. 

Zdaniem  Odwołującego  wsparcie  funkcjonowania  magazynu  wysokiego  składowania  nie 

było  bezwzględnie  wymaganym  warunkiem,  tylko  funkcjonalnością  realizowaną  zgodnie  z 

deklaracją  wykonawcy  wynikającą  z  formularza  ofertowego  (Arkuszy  Funkcjonalności).  Na 

wysunięty  przez  Zamawiającego  argument,  że  na  stronie  internetowej  nie  znaleziono 

informacji,  iż  System  C.  E.  E.  posiada  funkcjonalności  wspierające  funkcjonowanie 

magazynu  wysokiego  składowania,  Odwołujący  odpowiedział,  iż  zgodnie  z  warunkami  w 

dokumentacji przetargowej oferenci mieli możliwość deklarowania rozbudowy/modyfikacji (w 

toku 

procesu 

wdrożeniowego) 

oferowanego 

systemu 

E.  

o  funkcjonalności,  których  ich  system  nie  posiada  na  dzień  składania  ofert.  A  zatem 

oferowany przez Odwołującego system C. E. E. nie musiał na dzień składania ofert posiadać 

w 

swoim 

zakresie 

funkcjonalności 

obsługi 

WMS. 

Natomiast 

zgodnie  

z  rozdziałem  2.  załącznika  nr  1  do  specyfikacji  istotnych  warunków  zamówienia  pn:  „Opis 

przedmiotu  zamówienia”  zakres  zamówienia  obejmie  wdrożenie  Zintegrowanego  Systemu 

Informatycznego 

klasy 

E. 

w 

A. 

R. 

M. 

w: 

a) 

Centrali 

w 

W.;  

b)  Oddziałach  terenowych  i  składnicach  ARM  zlokalizowanych  na  terenie  Polski;  

w  następujących  obszarach  działalności  Zamawiającego:  a)  Finanse  i  księgowość;  

b)  Środki  trwałe;  c)  Budżet;  d)  Kadry;  e)  Płace;  f)  Gospodarka  magazynowa;  9)  Magazyn 

wysokiego  składowania;  h)  Sprzedaż  i  dystrybucja;  i)  Zakupy  i  zaopatrzenie;  j)  Remonty  

i  inwestycje  (funkcjonalność  opcjonalna,  realizacja  zgodnie  z  deklaracją  wykonawcy  

w Formularzu ofertowym).   

Z powyższego opisu wyraźnie wynika, że obsługa modułu Magazyn Wysokiego Składowania 

jest  bezwzględnie  wymaganą  funkcjonalnością.  Jedyną  funkcjonalnością  opcjonalną, 

realizowaną zgodnie z deklaracją wykonawcy jest funkcjonalność „Remonty i inwestycje”. 

Ponadto  Zamawiający  w  rozdziale  5.8  opisu  przedmiotu  zamówienia  wymagał  od 

wykonawcy  zaplanowania,  zorganizowania  i  przeprowadzenia  odrębnego  szkolenia 

dotyczącego obsługi systemu w obszarze funkcjonalnym Magazyn Wysokiego Składowania 

(pkt  1.  lit.  g).  Jest  to  kolejna  okoliczność  wskazująca  na  to,  iż  wsparcie  funkcjonowania 

magazynu wysokiego składowania jest wymaganiem obligatoryjnym. 

W  odwołaniu  Odwołujący  wskazuje  m.in.,  że  na  podstawie  przyjętej  przez  Zamawiającego 

konstrukcji  kryteriów  oceny  ofert  trudno  uznać,  że  akcentują  one  w  sposób  szczególny 

funkcjonalność  oferowanego  systemu  E.,  w  tym  min.  obszar  Magazynu  Wysokiego 

Składowania.  Zdaniem  Zamawiającego  powyższe  jest  potwierdzeniem,  że  Odwołujący  nie 

analizuje  dokumentacji  i  potrzeb  Zamawiającego  całościowo,  a  jedynie  skupia  się  na 

wybranych  fragmentach.  Jak  już  była  o  tym  wzmianka  w  rozdziale  2.  opisu  przedmiotu 

zamówienia,  Zamawiający  jednoznacznie  wskazał,  że  Magazyn  Wysokiego  Składowania 

objęty  jest  zakresem  zamówienia.  Wszystkie  elementy  specyfikacji  istotnych  warunków 

zamówienia  uzupełniają  się  wzajemnie  i  stanowią  nierozerwalną  całość  wymagań 

Zamawiającego  i  odzwierciedlają  wszystkie  jego  potrzeby.  W  odwołaniu  Odwołujący 

wskazał,  że  Zamawiający  musiał  się  liczyć  z  tym,  że  oferenci  mogą  złożyć  poprawne 

formalnie  oferty  nawet  w  całości  rezygnując  z  deklarowania  jakichkolwiek  wymagań  

z  obszaru  WMS,  ponieważ  konstrukcja  kryteriów  oceny  nie  zakazywała  takiej  praktyki. 

Należałoby  więc  przyjąć,  że  zgodnie  z  tokiem  rozumowania  Odwołującego,  Zamawiający 

zostałby zmuszony do wybrania jako najkorzystniejszej i spełniającej wymagania specyfikacji 

istotnych  warunków  zamówienia  oferty,  w  której  wykonawca  zrezygnowałby  w  całości  

z deklarowania jakichkolwiek wymagań z obszarów wymienionych powyżej. W tym wypadku 

przedmiot zamówienia ograniczyłby się prawdopodobnie do dostarczenia pustego nośnika. 

Odwołujący  wskazał  również,  że  zgodnie  Zamawiający  założył  możliwość  realizacji  prac 

rozwojowych  i  dodatkowych,  a  w  formularzu  ofertowym  wykonawcy  deklarowali  stawkę  za 

roboczogodzinę  tychże  prac,  istnieje  więc  możliwość,  aby  wybrane  elementy  funkcjonalne 

nie  zadeklarowane  w  ofercie  były  realizowane  w  ramach  dodatkowych  prac,  tymczasem 

zgodnie  z  §  8  projektu  umowy  prace  rozwojowe  dotyczą  systemu  uruchomionego 

produkcyjnie,  spełniającego  wszystkie  wymagania  Zamawiającego  obejmującego  wszystkie 

obszary  wskazane  w pkt 2 opisu przedmiotu zamówienia. Zatem funkcjonalność Magazynu 

Wysokiego  Składowania  powinna  być  wdrożona  i  odebrana  na  etapie  uruchomienia 

systemu, a nie w ramach prac rozwojowych. 

W  wyniku  prac  przygotowawczych  do  przeprowadzenia  postępowania  Zamawiający 

przeprowadził  szczegółową  analizę  wszystkich  procesów  biznesowych  i  niezbędnych 

funkcjonalności  zamawianego  oprogramowania  klasy  E.,  w  szczególności  dotyczących 

działalności  statutowej  Zamawiającego.  Część  składnic  Zamawiającego  pełni  funkcję 

kompleksowych  Magazynów  Wysokiego  Składowania,  tym  samym  twierdzenie,  jakoby 

Zamawiający  nie  wymagał  zamówienia  w  postępowaniu  przetargowym  modułu,  który 

odpowiada za funkcjonalności Magazynu Wysokiego Składowania, jest nieprawdziwe. 

Wobec  braku  zaoferowania  wdrożenia  Systemu  C.  E.  E.  w  obszarze  działalności  Magazyn 

Wysokiego  Składowania  oferta  Odwołującego  nie  spełnia  wymagań  określonych  w  opisie 

przedmiotu zamówienia. 

Odnośnie  zarzutu  2.  wskazanego  w  informacji  o  odrzuceniu  oferty  –  Zamawiający  zgodnie  

z  rozdziałem  5.1.  wymagania  bezwzględne  opisu  przedmiotu  zamówienia  wymagał:  

„6.  Wszystkie  obszary  Systemu  powinny  korzystać  z  jednej  zbiorczej  kartoteki 

kontrahentów.”  Zakres  zamówienia  obejmuje  wdrożenie  Zintegrowanego  Systemu 

Informatycznego 

klasy 

E. 

w 

A. 

R. 

M. 

w: 

a) 

Centrali 

w 

W.;  

b)  oddziałach  terenowych  i  składnicach  ARM  zlokalizowanych  na  terenie  Polski.  Z  tego 

względu  warunek  SID1.2.  „Baza  kontrahentów  wspólna  dla  wszystkich  spółek  i  oddziałów 

(wielofirmowość  i  wieloodziałowość)”  musi  być  bezwzględnie  spełniony.  W  przeciwnym 

wypadku  wymóg  jednej  zbiorczej  kartoteki  kontrahentów  dla  całej  ARM  (centrala,  oddziały 

terenowe  i  składnice  ARM)  nie  będzie  zagwarantowany,  skoro  oferent  nie  zadeklaruje 

realizacji  bazy  kontrahentów  wspólnej  dla  wszystkich  oddziałów  ARM.  Obydwa  warunki  są 

bowiem ze sobą logicznie powiązane. 

Odnośnie  zarzutu  3.  i  4.  wskazanych  w  informacji  o  odrzuceniu  oferty  –  Zamawiający 

zgodnie  z  rozdziałem  5.1.  opisu  przedmiotu  zamówienia  wymagał  jako  wymagania 

bezwzględne:  „14.  System  będzie  posiadać  możliwość  identyfikacji  użytkownika 

wprowadzającego  zmiany  do  Systemu  i  historię  wprowadzanych  zmian  z  uwzględnieniem 

daty i czasu.” oraz „15. System będzie zapewniać rejestrację realizowanych funkcji eksportu 

danych wraz ze wskazaniem użytkownika, daty oraz zakresu eksportowanych danych.” 

Odwołujący  wychodzi  z  założenia,  że  oba  wymagania  dotyczą  funkcjonalności  dostępnej 

wyłącznie  z  poziomu  administratora  systemu,  w  związku  z  tym  oferowany  przez  niego 

System C. E. E. spełnia te wymagania zapewniając funkcjonalność tzw. „auditingu”. Poprzez 

mechanizm  „auditingu”  administrator  Zamawiającego  będzie  miał  możliwość  weryfikacji 

zmiany 

danych, 

o 

których 

mowa 

w 

wymaganiach 

biznesowych, 

ale  

w  ujęciu  typowo  „administracyjnym”,  czyli  sięgając  do  danych  zapisanych  w  tzw.  logach 

systemu.  Jednocześnie  przyznaje,  że  zaoferowany  przez  niego  system  nie  posiada 

funkcjonalności  identyfikacji  użytkownika  wprowadzającego  zmiany  (lub  eksportującego 

dane)  i  śledzenia  historii  zmian  (lub  eksportu  danych)  dostępnej  dla  użytkownika  tego 

systemu  z  poziomu  formatki  systemu.  Argumentacja  Odwołującego  jest  nielogiczna. 

Zamawiający  zamawia  System  aby  wesprzeć  pracę  użytkowników  Systemu,  a  nie  pracę 

administratorów 

Systemu, 

dlatego 

wszystkie 

wymagane 

przez 

Zamawiającego 

funkcjonalności, to funkcjonalności dostępne dla użytkowników systemu. 

III Ustalenia Izby  

Na wstępie Izba stwierdziła, że nie zachodzi żadna z przesłanek skutkujących odrzuceniem 

odwołania, opisanych w art. 189 ust. 2 ustawy Prawo zamówień publicznych, a Odwołujący 

ma interes we wniesieniu odwołania. 

Po  zapoznaniu  się  z  przedmiotem  sporu  oraz  argumentacją  obu  Stron,  w  oparciu  o  stan 

faktyczny  ustalony  podczas  rozprawy  Izba  ustaliła  i  zważyła,  co  następuje:  odwołanie 

zasługuje na uwzględnienie. 

Izba ustaliła, iż stan faktyczny postępowania nie jest sporny między Stronami.  

W postępowaniu złożono dwie oferty. Za najkorzystniejszą ofertę Zamawiający uznał ofertę 

Przystępującego  –  S.  S.  Polska  Sp.  z  o.o.  z  ceną  brutto  7.648.509,00  PLN,  odrzucając 

jednocześnie  ofertę  Odwołującego  (z  ceną  3.952.601,31  PLN  brutto),  na  podstawie  art.  89 

ust.  1  pkt  2  ustawy  Prawo  zamówień  publicznych,  tj.  ze  względu  na  to,  że  jej  treść  nie 

odpowiada  treści  specyfikacji  istotnych  warunków  zamówienia.  Jednocześnie  Zamawiający 

unieważnił  postępowanie  w  oparciu  o  art.  93  ust.  1  pkt  4  ustawy  Prawo  zamówień 

publicznych,  gdyż  cena  najkorzystniejszej  oferty  przewyższa  kwotę,  którą  zamierzał 

przeznaczyć  na  sfinansowanie  zamówienia.  Odwołujący  wskazał,  iż  gdyby  jego  oferta  nie 

została  odrzucona,  na  podstawie  ustalonych  kryteriów  oceny  ofert  zostałaby  uznana  za 

najkorzystniejszą, a przy tym mieszczącą się w kwocie budżetu Zamawiającego.   

Zamawiający wskazał następujące przyczyny odrzucenia oferty: 

Oferta  swoim  zakresem  nie  obejmuje  wdrożenia  podstawowych  funkcjonalności 

przewidzianych  jako  funkcjonalności  Magazynu  Wysokiego  Składowania.  W  opisie 

przedmiotu  zamówienia  Zamawiający  określił,  iż  zakres  zamówienia  obejmie  wdrożenie 

Zintegrowanego Systemu Informatycznego klasy E. w następujących obszarach działalności 

Zamawiającego: 

a) 

Finanse 

i 

księgowość; 

b) 

Ś

rodki 

trwałe; 

c) 

Budżet;  

d) Kadry; e) Płace; f) Gospodarka magazynowa; g)  Magazyn 

wysokiego 

składowania;  

h) Sprzedaż i dystrybucja; i) Zakupy i zaopatrzenie; j) Remonty i inwestycje (funkcjonalność 

opcjonalna, realizacja zgodnie z deklaracją wykonawcy w formularzu ofertowym). W ofercie 

wskazano,  które  z  określonych  przez  Zamawiającego  wymagań  będą  realizowane  przez 

zaoferowany  system  C.  E.  E.  Dla  obszaru  Magazyn  Wysokiego  Składowania  spośród  107 

wymagań  wyspecyfikowanych  przez  Zamawiającego  (w  tym  95  zdefiniowanych,  jako 

wymagania 

kluczowe 

dla 

Zamawiającego, 

których 

spełnienie 

stanowi 

jedno  

z  podstawowych  kryteriów  oceny  proponowanego  rozwiązania  oraz  12  wymagań 

zdefiniowanych, jako wymagania ważne lub mogące okazać się przydatne w przyszłości, dla 

których  poziom  spełnienia  będzie  stanowił  dodatkowe  kryterium  oceny  rozwiązania), 

Odwołujący  zadeklarował,  iż  w  ramach  oferty  zrealizuje  jedynie  38  wymagań.  Stanowi  to 

jedynie  35,51%  wyspecyfikowanych  wymagań.  Wśród  wymagań  zadeklarowanych,  jako 

realizowane  są  wymagania,  które  są  realizowane  przez  obszar  gospodarka  magazynowa. 

Brakuje  natomiast  realizacji  podstawowych  wymagań  niezbędnych  do  obsługi  magazynu 

wysokiego  składowana,  w  szczególności  związanych  z  określaniem  lokalizacji  towarów  

w  magazynie  w  podziale  na  sektory,  regały  oraz  gniazda  magazynowe  w  ramach  regałów.  

W  szczególności  brakuje  realizacji  następujących  wymagań:  podział  na  regały  w  ramach 

sektorów;  podział  na  gniazda  magazynowe  w  ramach  regałów;  rezerwowanie  miejsca 

składowania;  rezerwowanie  pól  odkładczych;  rezerwowanie  zasobów;  na  podstawie 

przeliczenia;  na  podstawie  wagi;  na  podstawie  objętości;  określenie  optymalnych  tras 

rozłożenia  towaru;  miejsca  składowania;  alternatywne  miejsce  składowania;  obsługa 

informacji o błędzie w lokalizacji. 

Zgodnie  z  powszechnie  na  rynku  używanymi  definicjami,  magazyn  wysokiego  składowania 

umożliwia  przechowywanie  różnego  typu  towarów  na  lub  w  specjalnych  jednostkach 

ładunkowych  (np.  paleta,  pojemnik)  na  półkach  specjalistycznych  regałów  magazynowych 

wysokiego składowania. Ideą systemów wspierających magazyn wysokiego składowania jest 

bezbłędna  lokalizacja  towarów  w  magazynie  oraz  pełna  kontrola,  na  którym  miejscu 

(gnieździe) znajduje się towar. Każda lokalizacja posiada w systemie swój indywidualny kod. 

Towar  przeznaczony  do  wydania  przedstawiany  jest  magazynierowi  w  postaci  listy 

kompletacyjnej,  uwzględniającej  ilości  towarów  i  ich  rozlokowanie  w  kontekście 

maksymalnego uproszczenia procesu wydawania produktów. Możliwe jest określenie zasad 

zarządzania magazynem, zgodnie z FIFO lub LIFO.  

Dla  Zamawiającego  bardzo  istotne  jest  wsparcie  przez  system  obsługi  posiadanego 

magazynu  wysokiego  składowania.  Wsparcie  w  postaci  funkcji  przewidzianych  w  ofercie 

wykonawcy  dla  magazynu  jest  niewystarczające.  Zdefiniowane  wymagania  nie  zapewniają 

obsługi magazynowej zgodnej z wymaganiami Zamawiającego.  

Na  stronie  internetowej  www.egeria.comarch.com  zawarto  ogólny  opis  oferowanych 

funkcjonalności w podziale na obszary. Dla podmiotów administracji publicznej określono, iż 

system  posiada  funkcje  z  obszaru  logistyka  obejmujące:  sprzedaż,  zakupy,  gospodarkę 

magazynową, zamówienia, transport, iLOG, nie ma natomiast informacji, iż system C. E. E. 

posiada funkcjonalności wspierające funkcjonowanie magazynu wysokiego składowania. 

Dodatkowym  argumentem  przemawiającym  za  odrzuceniem  oferty  jest  niezgodność 

oferowanego  rozwiązania  z  wymaganiami  bezwzględnymi  sprecyzowanymi  przez 

Zamawiającego  w  rozdziale  5  załącznika  nr  1  do  specyfikacji  istotnych  warunków 

zamówienia, czyli opisem przedmiotu zamówienia. 

Zamawiający zgodnie z rozdziałem 5.1 opisu przedmiotu zamówienia wymagał:  

„6. Wszystkie obszary Systemu powinny korzystać z jednej zbiorczej kartoteki kontrahentów. 

Kartoteka  powinna  być  podzielona  co  najmniej  na  kontrahentów  wewnętrznych  – 

pracowników  Agencji  i  kontrahentów  zewnętrznych  –  klientów.  W  ramach  kartoteki  będzie 

możliwość definiowania nowych grup kontrahentów.” 

Wykonawca  w  ofercie  przypisał  wartość  „0”  dla  wymagań,  które  realizują  powyższe,  tj. 

SID1.2  baza  kontrahentów  wspólna  dla  wszystkich  spółek  i  oddziałów  (wielofirmowość  

i wielooddziałowość) 

Zamawiający zgodnie z rozdziałem 5.1 opisu przedmiotu zamówienia wymagał: 

„14. System będzie posiadać możliwość identyfikacji użytkownika wprowadzającego zmiany 

do  Systemu  i  historię  wprowadzanych  zmian  z  uwzględnieniem  daty  i  czasu.”  Wykonawca  

w ofercie przypisał wartość „0” dla wymagań, które realizują powyższe, tj.:  

SID8.24 – śledzenie historii i stopnia realizacji zamówień na poziomie pozycji zamówienia; 

RI2.26 – historia zmian planu (osoba odpowiedzialna za wprowadzenie zmian); 

Dane  materiałów  i  usług:  GM1.16  –  historia  zmian  stawki  VAT;  GM1.18  –  historia  zmian 

stawki podatku akcyzowego; GM1.20 – historia zmian stawki cła. 

Zamawiający zgodnie z rozdziałem 5.1 opis przedmiotu zamówienia wymagał: 

„15.  System  będzie  zapewniać  rejestrację  realizowanych  funkcji  eksportu  danych  wraz  ze 

wskazaniem  użytkownika,  daty  oraz  zakresu  eksportowanych  danych.”  Wykonawca  

w ofercie przypisał wartość „0” dla wymagań, które realizują powyższe, tj. 

OG3.19  –  system  powinien  zapewniać  możliwość  eksportu  wg  wcześniej  zdefiniowanych 

szablonów formularzy do plików formatu xls, z zachowaniem uwzględnionych w formularzach 

list słownikowych, typów danych, warunków walidujących spójność i zakres danych; 

SID2.21 – eksport cenników do MS Word, MS Excel; 

SID6.18 – możliwość eksportu oferty do MS Word, MS Excel, Open Office. 

Jednak w ocenie Izby na gruncie postanowień specyfikacji istotnych warunków zamówienia 

należy  przyznać  rację  Odwołującemu,  iż  powyższe  podstawy  nie  powinny  stanowić 

przyczyny  odrzucenia  oferty  jako  niezgodnej  ze  specyfikacją  istotnych  warunków 

zamówienia.  Jak  słusznie  wskazał  bowiem  Odwołujący,  przywołane  z  oferty  wymagania, 

opisane  w  przygotowanym  przez  Zamawiającego  Arkuszu  Funkcjonalności  stanowiącym 

załącznik  nr  1  do  opisu  przedmiotu  zamówienia,  odnoszą  się  nie  do  wymagań 

bezwzględnych  Zamawiającego  warunkujących  zgodność  oferty  ze  specyfikacją  istotnych 

warunków  zamówienia,  ale  wymagań,  które  odnosiły  się  do  kryteriów  oceny  ofert  i  w  ich 

ramach  były  punktowane,  czyli  kryterium  oceny  funkcjonalności  („stopień  spełniania 

stawianych  w  przedmiocie  zamówienia  wymagań  funkcjonalnych  opisanych  szczegółowo  

w  załączniku  nr  1  do  OPZ”)  i  kryterium  oceny  spełniania  wymagań  pozafunkcjonalnych 

(„stopień  spełniania  stawianych  w  przedmiocie  zamówienia  wymagań  pozafunkcjonalnych 

opisanych szczegółowo w załączniku nr 1 do OPZ”) – rozdział XXII specyfikacji.  

Tym samym już z założenia wymagania te są fakultatywne, a za ich spełnienie lub spełnienie  

w  stopniu  lepszym  z  punktu  widzenia  Zamawiającego  przyznawana  jest  dodatkowa 

punktacja. I a contrario – jeśli spełnienie danych wymagań Zamawiającego jest obowiązkowe 

w ten sam sposób dla wszystkich, to nie ma uzasadnienia logicznego przyznawanie punktów 

w tym zakresie, gdyż nie jest to zakres wartościujący oferty.  

Należy  zauważyć,  że  wymagania  specyfikacji  istotnych  warunków  zamówienia  odnoszące 

się  do  kryteriów  oceny  ofert  powszechnie  rozumiane  są  (także  w  rozumieniu  „ustalonych 

zwyczajów”,  o  których  mowa  w  art.  65  §  1  Kodeksu  cywilnego)  jako  wymagania,  których 

spełnienie jest opcjonalne.  

Tak  też  wymagania  te,  jak  już  wskazano  powyżej  –  prawidłowo,  odczytał  Odwołujący  

i  dostosował  do  nich  swoją  ofertę  podejmując  decyzję  strategiczną  i  biznesową,  czy  złożyć 

ofertę  z  programem  uboższym  w  funkcje,  a  tańszym,  czy  też  program  wzbogacić  o  nowe 

funkcje, co podroży ofertę.  

Należy  też  podkreślić,  że  Zamawiający  w  żadnym  miejscu  specyfikacji  istotnych  warunków 

zamówienia  nie  wskazał,  że  spełnienie  którejkolwiek  z  funkcji  opisanych  w  Arkuszu 

Funkcjonalności  jest  obowiązkowe  –  nie  wskazał  też  takiego  miejsca  ani  w  piśmie 

procesowym, ani podczas rozprawy (do punktów wskazanych przez niego jako obligatoryjne 

Izba odniesie się w dalszej części uzasadnienia).  

Zamawiający  nie  określił  też,  że  dla  akceptacji  oferty  wymaga  zadeklarowania  spełnienia 

konkretnego  procentu  czy  minimalnej  liczby  funkcji  spośród  wskazanych  w  Arkuszu 

Funkcjonalności  –  tym  samym  nie  ma  znaczenia,  czy  na  107  wymienionych,  Odwołujący 

zadeklarował spełnienie 100, 38 czy 3 funkcji.  

Tym  samym  dla  spełnienia  wskazanych  wymagań  Zamawiającego  wystarczające  było 

wskazanie, że zakres zamówienia obejmie wdrożenie systemu w następujących obszarach: 

a)  Finanse  i  księgowość;  b)  Środki  trwałe;  c)  Budżet;  d)  Kadry;  e)  Płace;  f)  Gospodarka 

magazynowa;  g)  Magazyn  wysokiego  składowania;  h)  Sprzedaż  i  dystrybucja;  i)  Zakupy  

i zaopatrzenie – bez wskazywania konkretnych funkcji w Arkusza Funkcjonalności. 

Z  praktycznego  punktu  widzenia  może  jest  to  mało  przydatne,  ale  tak  Zamawiający 

skonstruował specyfikację istotnych warunków zamówienia i na takich założeniach się oparł 

(nawet  jeśli  po  otrzymaniu  ofert  samemu  uznał  je  za  niewystarczające  dla  osiągnięcia 

zakładanego  celu).  Jak  sam  zresztą  wskazał  podczas  rozprawy  –  sporządzając  opis 

wymagań  kierował  się  poglądem,  zgodnie  z  którym  nie  powinien  określać  wymagań 

obligatoryjnych,  aby  nie  ograniczać  liczby  systemów,  które  te  wymagania  spełnią  i  liczby 

ofert.  Jednak  ma  to  swoje  konsekwencje:  jeśli  Zamawiający  nie  określił  minimalnego 

obligatoryjnego zakresu funkcji (czy też inaczej – określił próg wymagań koniecznych na tyle 

nisko,  że  po  otrzymaniu  ofert  uznał,  iż  chciałby  posiadać  także  dodatkowe  funkcje),  musi 

przyjąć  oferty  takie,  jakie  mu  złożono,  nawet  jeśli  obecnie  wolałby,  aby  oferowany  zakres 

funkcji był inny. 

Co do „powszechnie używanych na rynku definicji magazynu wysokiego składowania” – czy 

też  dokładniej:  tego,  czym  taki  magazyn  z  punktu  widzenia  obsługi  objętej  system 

informatycznym różni się od zwykłego magazynu – to należy zauważyć, że Zamawiający na 

takie  „definicje”  (czy  raczej:  zakres  wymagań  dla  systemu,  który  wskazał  w  informacji  

o odrzuceniu oferty jako wymagań obligatoryjnych) nie powoływał się wcześniej.  

Co więcej – z postanowień specyfikacji istotnych warunków zamówienia wynikało wręcz, że 

nawet  jeśli  z  punktu  widzenia  „powszechnie  używanych  definicji”,  tj.  np.  Wikipedii,  na  którą 

powołał  się  Zamawiający,  system  dla  magazynu  wysokiego  składowania  miał  mieć  pewne 

cechy,  to  Zamawiający  określił  je  odmiennie  –  właśnie  umieszczając  w  Arkuszu 

Funkcjonalności, czyli na liście funkcji fakultatywnych. W tych okolicznościach nie może więc 

Zamawiający  przeciwstawiać  „powszechnie  używanych  definicji”  specyfikacji  istotnych 

warunków zamówienia i stawiać ich ponad postanowienia specyfikacji. 

Co  do  wymagań  obligatoryjnych  z  punktu  6.,  14.  i  15.  rozdziału  5.1  opisu  przedmiotu 

zamówienia  i  ich  przeciwstawienia  wymaganiom  wymienionym  w  Arkuszu  Funkcjonalności, 

to  również  tu  ma  miejsce  zasada,  że  skoro  wymagania  z  Arkusza  Funkcjonalności  są 

oceniane, a więc fakultatywne, to nie mogą być obligatoryjne (których niespełnienie skutkuje 

odrzuceniem  oferty),  a  więc  tym  samym  ich  znaczenie  musi  być  inne  niż  wymagań 

obligatoryjnych.  

Co  do  wymagania  6.:  „Wszystkie  obszary  Systemu  powinny  korzystać  z  jednej  zbiorczej 

kartoteki  kontrahentów.  Kartoteka  powinna  być  podzielona  co  najmniej  na  kontrahentów 

wewnętrznych  –  pracowników  Agencji  i  kontrahentów  zewnętrznych  –  klientów.  W  ramach 

kartoteki  będzie  możliwość  definiowania  nowych  grup  kontrahentów”,  to  Odwołujący 

oświadczył  podczas  rozprawy,  że  oferowany  system  wymaganie  to  spełnia  i  nie  było  to 

skutecznie kwestionowane przez stronę zamawiającą.  

Natomiast w punkcie SID1.2 „baza kontrahentów wspólna dla wszystkich spółek i oddziałów 

(wielofirmowość i wielooddziałowość)” Odwołujący, jak wyjaśnił, wskazał „0” (= nie spełnia), 

gdyż  w  opisie  wymagania  istniała  koniunkcja  „wielofirmowość  i  wielooddziałowość”, 

natomiast  jego  system  spełnia  wymóg  wielooddziałowości,  ale  nie  spełnia  wymogu 

wielofirmowości (notabene – Zamawiający nie prowadzi działalności w sposób wielofirmowy, 

więc  opis  wymogu  nie  jest  dostosowany  do  jego  potrzeb),  zatem  nie  spełnia  wymogu  

w całości i nie mógł go zadeklarować. 

Ma  też  rację  Odwołujący,  że  brzmienie  tych  wymogów  nie  jest  jednakowe  i  choć  obejmuje 

wspólne obszary, obie funkcje są nieco odmienne. 

Co  do  wymagania  14:  „System  będzie  posiadać  możliwość  identyfikacji  użytkownika 

wprowadzającego  zmiany  do  Systemu  i  historię  wprowadzanych  zmian  z  uwzględnieniem 

daty i czasu”, to Odwołujący oświadczył podczas rozprawy, że oferowany system wymaganie 

to spełnia.  

Przedmiot sporu podczas rozprawy zresztą był nieco inny: Zamawiający kwestionował to, że 

w  oferowanym  przez  Odwołującego  systemie  możliwość  identyfikacji  użytkownika 

wprowadzającego  zmiany  i  historii  wprowadzanych  zmian  następuje  z  poziomu 

administratora  systemu  (co  nie  było  kwestionowane  przez  stronę  zamawiającą),  a  nie  jego 

użytkownika, co jest wygodniejsze. Należy jednak zwrócić uwagę, że wymóg nie wskazywał, 

ż

e  możliwość  identyfikacji  użytkownika  wprowadzającego  zmiany  i  historię  tych  zmian  ma 

następować z poziomu użytkownika. 

Zatem  odpowiadając  na  pytanie:  czy  oferowany  system  będzie  posiadać  możliwość 

identyfikacji  użytkownika  wprowadzającego  zmiany  do  systemu  i  historię  wprowadzanych 

zmian  z  uwzględnieniem  daty  i  czasu?  –  należy  odpowiedzieć  twierdząco,  a  zatem  wymóg 

został spełniony.  

Co do wymogów z Arkusza Funkcjonalności, którym Odwołujący w ofercie przypisał wartość 

„0” (czyli „nie spełnia”) dla wymagań, które realizują powyższe, tj. SID8.24, RI2.26, GM1.16 

GM1.18  i  GM1.20,  to  aktualna  jest  tu  argumentacja  powyższa:  są  to  wymagania 

fakultatywne,  które  nie  muszą  zostać  spełnione,  a  ze  swojej  istoty  wymagania,  które  są 

fakultatywne nie mogą być jednocześnie obligatoryjne, nawet jeśli brzmią podobnie. Ma też 

rację Odwołujący, że brzmienie tych wymogów nie jest jednakowe i choć obejmuje wspólne 

obszary, funkcje te są nieco odmienne. 

Co do wymagania 15: „System będzie zapewniać rejestrację realizowanych funkcji eksportu 

danych  wraz  ze  wskazaniem  użytkownika,  daty  oraz  zakresu  eksportowanych  danych”,  to 

Odwołujący oświadczył podczas rozprawy, że oferowany system wymaganie to spełnia i nie 

było to skutecznie kwestionowane.  

Podobnie jak w wymaganiu 14. – jeśli odpowiedź na pytanie „czy system będzie zapewniać 

rejestrację  realizowanych  funkcji  eksportu  danych  wraz  ze  wskazaniem  użytkownika,  daty 

oraz zakresu eksportowanych danych?” brzmi twierdząco, to oznacza, że oferent wymaganie 

spełnił. Ma też rację Odwołujący, że czym innym jest funkcja rejestracji realizowanych funkcji 

eksportu danych, a czym innym zakres danych, które będą eksportowane.  

Zamawiający nie wskazał w specyfikacji istotnych warunków zamówienia, jakie i ile formatów 

musi  być  obligatoryjnie  eksportowanych,  zatem  nie  może  teraz  stawiać  Odwołującemu 

zarzutów,  że  któreś  z  nich  nie  są  eksportowane  przez  system,  zatem  fakt,  że  oferowany 

system  nie  spełnia  wymogów  OG3.19,  SID2.21  i  SID6.18  opisanych  w  Arkuszu 

Funkcjonalności, co do których stwierdzono już powyżej, że są wymaganiami fakultatywnymi 

ocenianymi w ramach oceny ofert, nie może być podstawą odrzucenia oferty.  

W związku z powyższym Izba orzekła jak w sentencji uwzględniając odwołanie.  

O kosztach postępowania odwoławczego orzeczono na podstawie art. 192 ust. 9 i 10 ustawy 

Prawo zamówień publicznych, stosownie do wyniku postępowania, zgodnie z § 1 ust. 1 pkt 

2,  §  3  i  §  5  ust.  2  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 ze zm.). 

Przewodniczący:      ……………………..…