rodzaj: WYROK
data dokumentu: 2017-04-26
rok: 2017
data dokumentu: 2017-04-26
rok: 2017
sygnatury akt.:
KIO 739/17
KIO 739/17
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
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
4.
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: ……………………..…
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
4.
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: ……………………..…
Wcześniejsze orzeczenia:
- Sygn. akt KIO 86/17 z dnia 2017-12-01
- Sygn. akt KIO 732/17 z dnia 2017-05-17
- Sygn. akt KIO 714/17 z dnia 2017-05-15
- Sygn. akt KIO 711/17 z dnia 2017-05-15
- Sygn. akt KIO 542/17 z dnia 2017-05-12
