KIO 739/17

Sygn. akt: KIO 739/17 WYROK z dnia 26 kwietnia 2017 r. Krajowa Izba Odwoławcza – w składzie: Przewodniczący: Anna Packo Protokolant: Sylwia Muniak po rozpoznaniu na rozprawie w dniu 25 kwietnia 2017 r., w Warszawie, odwołania wniesionego do Prezesa Krajowej Izby Odwoławczej w dniu 14 kwietnia 2017 r. przez wykonawców wspólnie ubiegających się o udzielenie zamówienia C. P. S.A. al. (…) i C. S.A. al. (…) w postępowaniu prowadzonym przez A. R. M. ul. (…) przy udziale wykonawcy S. S. P. Sp. z o.o. ul. (…) zgłaszającego przystąpienie do postępowania odwoławczego po stronie zamawiającego orzeka: 1. uwzględnia odwołanie i nakazuje A. R. M. : unieważnienie czynności badania i oceny ofert, unieważnienie czynności odrzucenia oferty wykonawców wspólnie ubiegających się o udzielenie zamówienia C. P. S.A. i C. S.A., unieważnienie czynności unieważnienia postępowania o udzielenie zamówienia publicznego oraz dokonanie powtórnej czynności badania i oceny ofert, 2. kosztami postępowania obciąża A. R. M. i: 2.1. zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr (słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez wykonawców wspólnie ubiegających się o udzielenie zamówienia C. P. S.A. si C. S.A. tytułem wpisu od odwołania, 2.2. zasądza od A. R. M. na rzecz wykonawców wspólnie ubiegających się o udzielenie zamówienia C. P. S.A. i C. S.A. kwotę 15 000 zł 00 gr (słownie: piętnaście tysięcy złotych zero groszy) stanowiącą koszty postępowania odwoławczego poniesione z tytułu połowy wpisu. Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. – Prawo zamówień publicznych (t.j. Dz. U. z 2015, poz. 2164 ze zm.) na niniejszy wyrok – w terminie 7 dni od dnia jego doręczenia – przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu Okręgowego w Warszawie. Przewodniczący: ……………………..… Sygn. akt: KIO 739/17 U z a s a d n i e n i e Zamawiający – A. R. M. prowadzi postępowanie o udzielenie zamówienia publicznego na „zakup zintegrowanego oprogramowania klasy E. wraz z usługami serwisu utrzymaniowego i pracami rozwojowymi” na podstawie ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (t.j. Dz. U. z 2015 r. poz. 2164 z późn. zm.), w trybie przetargu nieograniczonego. Ogłoszenie o zamówieniu zostało opublikowane 1 grudnia 2016 r. w Dzienniku Urzędowym Unii Europejskiej pod numerem 2016/S 232-423298. Wartość zamówienia jest większa niż kwoty określone na podstawie art. 11 ust. 8 ustawy Prawo zamówień publicznych. I Zarzuty i żądania odwołania: Odwołujący – wykonawcy wspólnie ubiegający się o udzielenie zamówienia C. P. S.A. i C. S.A. wniósł odwołanie wobec: 1. czynności odrzucenia oferty Odwołującego na podstawie art. 89 ust. 1 pkt 2 ustawy Prawo zamówień publicznych – jako że jej treść nie odpowiada treści specyfikacji istotnych warunków zamówienia, w sytuacji gdy oferta Odwołującego spełnia wszystkie wymagania Zamawiającego, co w konsekwencji prowadzi do braku podstaw odrzucenia oferty, czym naruszono art. 89 ust. 1 pkt 2 w zw. z art. 7 ust. 1 ustawy Prawo zamówień publicznych, 2. czynności unieważnienia postępowania na podstawie art. 93 ust. 1 pkt 4 ustawy Prawo zamówień publicznych – z tego powodu, iż cena najkorzystniejszej oferty przewyższa kwotę, którą Zamawiający zamierza przeznaczyć na sfinansowanie zamówienia, w sytuacji, gdy oferta Odwołującego nie powinna być odrzucona i była merytorycznie i formalnie zgodna z treścią specyfikacji istotnych warunków zamówienia, a także mieściła się w budżecie Zamawiającego, w związku z czym nie ma podstaw do unieważnienia postępowania na tej podstawie, gdyż oferta Odwołującego jest ofertą najkorzystniejszą w rozumieniu przepisów ustawy Prawo zamówień publicznych, czym naruszono art. 93 ust. 1 pkt 4 w zw. z art. 89 ust. 1 pkt 2 w zw. z art. 2 pkt 5 lit. a, w zw. z art. 91 ust. 1 i 2 ustawy Prawo zamówień publicznych, 3. art. 91 ust. 1 w zw. z art. 7 ust. 1 ustawy Prawo zamówień publicznych poprzez wybór jako najkorzystniejszej oferty wykonawcy S. S. Sp. z o.o., podczas gdy oferta ta nie jest ofertą najkorzystniejszą. Odwołujący wniósł o uwzględnienie odwołania i nakazanie Zamawiającemu: unieważnienia czynności unieważnienia postępowania, unieważnienia czynności oceny ofert, dokonanie ponownej czynności oceny ofert i dokonanie wyboru oferty Odwołującego jako oferty najkorzystniejszej. W uzasadnieniu Odwołujący wskazał, iż za najkorzystniejszą ofertę Zamawiający uznał ofertę S. S. P. Sp. z o.o. z ceną brutto 7.648.509,00 PLN. Odwołujący złożył ofertę w wysokości 3.952.601,31 PLN brutto. Kwota, jaką Zamawiający zamierzał przeznaczyć na sfinansowanie zamówienia to 4.784.700,00 PLN brutto. W postępowaniu złożono dwie oferty. Oferta Odwołującego została odrzucona na podstawie art. 89 ust. 1 pkt 2 ustawy Prawo zamówień publicznych, tj. jej treść nie odpowiada treści specyfikacji istotnych warunków zamówienia. Jednocześnie Zamawiający wskazał, że unieważnia postępowanie na podstawie art. 93 ust. 1 pkt 4 ustawy Prawo zamówień publicznych, gdyż cena najkorzystniejszej oferty przewyższa kwotę, którą Zamawiający zamierza przeznaczyć na sfinansowanie zamówienia. Odwołujący nie zgadza się z decyzją o odrzuceniu jego oferty oraz z decyzją o unieważnieniu postępowania. Odnośnie zarzutu 1. wskazanego w informacji o odrzuceniu oferty dotyczącego tego, że oferta swoim zakresem nie obejmuje wdrożenia podstawowych funkcjonalności przewidzianych jako funkcjonalności Magazynu Wysokiego Składowania. Zamawiający czyni zarzut Odwołującemu, iż zadeklarował on w ramach oferty „jedynie” 38 wymagań na 107 wymagań wyspecyfikowanych przez Zamawiającego dla obszaru WMS, co stanowi udział 35,51% wszystkich wymagań WMS. Odwołujący nie podziela argumentów Zamawiającego. Zgodnie z opublikowaną dokumentacją przetargową Zamawiający ustalił 8 kryteriów oceny, wśród których ujęto m.in. kryterium nr 3: ocena funkcjonalności (25%) – stopień spełnienia stawianych w przedmiocie zamówienia wymagań funkcjonalnych opisanych szczegółowo w załączniku nr 1 do opisu przedmiotu zamówienia oraz kryterium nr 7: ocena spełnienia wymagań pozafunkcjonalnych (5%) – stopień spełnienia stawianych w przedmiocie zamówienia wymagań pozafunkcjonalnych opisanych szczegółowo w opisie przedmiotu zamówienia. Przyjętą przez Zamawiającego konstrukcję kryteriów oceny trudno uznać za akcentującą w sposób szczególny funkcjonalność oferowanego systemu E., w tym m.in. obszar Magazynu Wysokiego Składowania. W treści załącznika nr 1 do specyfikacji istotnych warunków zamówienia (opis przedmiotu zamówienia), Zamawiający przedstawił, jak należy wypełniać Arkusz Funkcjonalności (Załącznik nr 1 do opisu przedmiotu zamówienia) i jak oferenci powinni interpretować statusy nadane przez Zamawiającego wymaganiom funkcjonalnym i pozafunkcjonalnym. Pkt 3. Wymagania funkcjonalne: wymagania dla obszarów funkcjonalnych zawarte są w załączniku nr 1 do opisu przedmiotu zamówienia. Zostały one identyfikowane w oparciu o predefiniowane tabele PASS, uzupełniane w trakcie wywiadów o dodatkowe, wymagane przez użytkowników funkcjonalności. Każdemu obszarowi przypisane zostały funkcjonalności, które zostaną poddane ocenie przez Zamawiającego. Funkcjonalności, którym w kolumnie „Poziom” przypisano wartość 2, są wymaganiami kluczowymi dla Zamawiającego, których spełnienie stanowi jedno z podstawowych kryteriów oceny ofert. Funkcjonalności, którym w kolumnie „Poziom” przypisano wartość 1, zostały określone jako ważne lub mogące okazać się przydatne w przyszłości. Poziom spełnienia tych funkcjonalności będzie stanowił dodatkowe kryterium oceny rozwiązania. Przyjęta przez Zamawiającego definicja mówi wyraźnie, że choć wymagania z poziomem 2. są wymaganiami „kluczowymi”, to stanowią jedynie jedno z kryteriów oceny, a zatem Zamawiający dopuścił możliwość dowolnego oznaczania przez oferentów wymagań wyspecyfikowanych w Arkuszach Funkcjonalności. Potwierdza to dalszy opis punktu 3. przedstawiający sposób wypełniania arkuszy wymagań dedykowanych dla obszarów działalności Zamawiającego: w przypadku, gdy oferowany system spełnia daną funkcjonalność w standardzie należy, w kolumnie „STD” wpisać 1. Jeżeli dana funkcjonalność nie jest możliwa do zrealizowania w proponowanym systemie, należy wpisać 0. Każdy inny zapis będzie traktowany jak wartość 0. Jeżeli dana funkcjonalność zostanie dostarczona w wyniku modyfikacji systemu, w kolumnie „MDF” należy wpisać 1 natomiast w kolumnie „STD” wstawić wartość 0. Umieszczenie zapisu 1 w kolumnie „MDF” jest równoznaczne z zapewnieniem Zamawiającemu modyfikacji systemu o daną funkcjonalność w ramach oferty. W przypadku, gdy wykonawca umieścił, w którymś z wierszy kolumny „MDF” zapis 1, proszony jest o wypełnienie kolumny „Uwagi” informacjami dotyczącymi krótkiego opisu zmian dostosowujących lub modyfikacji systemu oraz szacunkowej przewidywanej pracochłonności (roboczogodzin). Ostatni wiersz tabeli 2. „Przykład wypełnienia tabeli PASS przez Wykonawcę” wskazuje dobitnie, że Zamawiający założył możliwość niedeklarowania przez oferentów realizacji wymagań (w tym „kluczowych”) ujętych w Arkuszach Funkcjonalności dla wymagań funkcjonalnych (w tym dla wymagań z obszaru WMS). Analogicznie, również dla wymagań pozafunkcjonalnych Zamawiający przyjął podobne założenia: pkt 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: ……………………..…