KIO/UZP 2010/10

Sygn. akt KIO/UZP 2010/10 WYROK z dnia 5 października 2010 r. Krajowa Izba Odwoławcza - w składzie: Przewodniczący: Honorata Łopianowska Członkowie: Małgorzata Rakowska Izabela Niedziałek-Bujak Protokolant: Rafał Komoń po rozpoznaniu na rozprawie w dniu 1 października 2010 r. w Warszawie odwołania wniesionego przez wykonawców wspólnie ubiegających się o udzielenie zamówienia: 1. Bazy i Systemy Bankowe Sp. z o.o. w Bydgoszczy, 2. Pentegy S.A. w Warszawie od rozstrzygnięcia przez zamawiającego Ministerstwo Spraw Zagranicznych, protestu z dnia 27 sierpnia 2010 r., przy udziale wykonawcy ComArch S.A., w Krakowie zgłaszającego swoje przystąpienie po stronie Zamawiającego, orzeka: 1. Oddala odwołanie. 2. Kosztami postępowania obciąża wykonawców wspólnie ubiegających się o udzielenie zamówienia: 1. Bazy i Systemy Bankowe Sp. z o.o. w Bydgoszczy, 2. Pentegy S.A. w Warszawie i nakazuje: 1) zaliczyć na rzecz Urzędu Zamówień Publicznych koszty w wysokości 4 444 zł. 00 gr. (słownie: cztery tysiące czterysta czterdzieści cztery złote zero groszy) z kwoty wpisu uiszczonego przez wykonawców wspólnie ubiegających się o udzielenie zamówienia: 1. Bazy i Systemy Bankowe Sp. z o.o. w Bydgoszczy, 2. Pentegy S.A. w Warszawie; 2) dokonać zwrotu kwoty 10 556 zł 00 gr (słownie: dziesięć tysięcy pięćset pięćdziesiąt sześć złotych, zero groszy) z rachunku dochodów własnych Urzędu Zamówień Publicznych na rzecz Odwołującego - wykonawców KIO/UZP 2010/10 2 wspólnie ubiegających się o udzielenie zamówienia1. Bazy i Systemy Bankowe Sp. z o.o. w Bydgoszczy, 2. Pentegy S.A. w Warszawie. U z a s a d n i e n i e Zamawiający – Ministerstwo Spraw Zagranicznych prowadzi postępowanie o udzielenie zamówienia publicznego w trybie dialogu konkurencyjnego na „Zakup systemu wspierającego zarządzanie komputerami stacjonarnymi i przenośnymi, serwerami oraz wspomagającego prace Wydziału Technicznego Wsparcia Użytkowników (Help-Desk) w Ministerstwie Spraw Zagranicznych i placówkach zagranicznych., na podstawie przepisów ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (tekst jednolity: Dz.U. z 2010, Nr 113, poz. 759 ze zm.), wymaganych przy procedurze, kiedy wartość szacunkowa zamówienia przekracza kwoty określone w przepisach wydanych na podstawie art. 11 ust. 8 ustawy Prawo zamówień publicznych – wartość zamówienia, którego przedmiotem są usługi, wynosi 6.557.377,05 zł. Ogłoszenie o zamówieniu zostało opublikowane w dniu 31 sierpnia 2009 r. w Dzienniku Urzędowym Unii Europejskiej, nr 2009/S 169-244036. W prowadzonym postępowaniu Zamawiający w dniu 16 sierpnia 2010r. dokonał wyboru najkorzystniejszej oferty, odrzucając jednocześnie ofertę Odwołującego, informując w tej samej dacie wykonawców biorących udział w postępowaniu. Na czynność wyboru najkorzystniejszej oferty w dniu 27 sierpnia 2010r. protest wniosło Konsorcjum firm: Bazy i Systemy Bankowe spółka z ograniczoną odpowiedzialnością w Bydgoszczy oraz Pentegy SA w Warszawie. Zamawiający w dniu 6 września 2010r. rozstrzygnął protest, uznając iż nie zasługuje on na uwzględnienie. W przedmiotowym postępowaniu, w dniu 16 września 2010r. Odwołujący Konsorcjum firm: Bazy i Systemy Bankowe spółka z ograniczoną odpowiedzialnością w Bydgoszczy oraz Pentegy SA w Warszawie wniosło odwołanie na czynność Zamawiającego stanowiącą odrzucenie Jego oferty. Odwołujący się przekazał jednocześnie kopię treści odwołania Zamawiającemu. Odwołujący zarzucił rozstrzygnięciu Zamawiającego: 1) naruszenie art. 87 ust. 1, ust. 1 a ustawy Prawo zamówień publicznych, poprzez jego błędną wykładnię i niewłaściwe zastosowanie; 2) naruszenie art. 89 ust. 1 pkt 2 ustawy Prawo zamówień publicznych poprzez wadliwe uznanie, iż oferta Odwołującego podlega odrzuceniu z powodu jej KIO/UZP 2010/10 3 niezgodności z treścią Specyfikacji Istotnych Warunków; 3) naruszenie art. 92 ust. 1 pkt 2 ustawy Prawo zamówień publicznych poprzez niewłaściwe wskazanie podstawy faktycznej odrzucenia oferty Odwołującego; 4) naruszenie art. 7 ust. l i 3 ustawy Prawo zamówień publicznych, poprzez błędną wykładnię i niewłaściwe zastosowanie wielu przepisów ustawy Prawo zamówień publicznych; 5) oraz innych przepisów wymienionych lub wynikających z uzasadnienia niniejszego Odwołania. W oparciu o powyższe zarzuty Konsorcjum firm: Bazy i Systemy Bankowe spółka z ograniczoną odpowiedzialnością w Bydgoszczy oraz Pentegy SA w Warszawie wniosło o nakazanie dokonania ponownego badania i oceny ofert z uwzględnieniem Oferty Odwołującego. Odwołujący w uzasadnieniu podniósł, w zakresie zarzutu naruszenia art. 87 ust. 1 i ust. 1 a ustawy Prawo zamówień publicznych, że przepis ten nie uprawnia Zamawiającego do żądania złożenia wyjaśnień przez Wykonawcę w sytuacji zaistnienia wątpliwości co do treści złożonej przez niego Oferty. Procedura wyjaśniania treści złożonej oferty nie może mieć na celu prowadzenia jakichkolwiek negocjacji pomiędzy Zamawiającym a Wykonawcą oraz dokonywania jakichkolwiek zmian w treści oferty, przy czym, ze względu na specyfikę trybu, jakim jest dialog konkurencyjny, został wprowadzony wyjątek od zakazu określonego w art. 87 ust. 1 ustawy Prawo zamówień publicznych in fine, wprowadzania zmian do treści oferty na skutek przeprowadzenia procedury wyjaśnień co wynika z treści art. 87 ust. 1 a ustawy Prawo zamówień publicznych. Odwołujący podał, że w przedmiotowym postępowaniu o udzielenie zamówienia, prowadzonym w trybie dialogu konkurencyjnego, Zamawiający aż trzykrotnie wzywał Odwołującego do złożenia wyjaśnień, wskazując przez takie zachowanie na fakt, iż poprzednio udzielona odpowiedź nie była dla Niego wystarczająca. Dla porównania, w rozstrzygnięciu Protestu, Zamawiający zwrócił uwagę na wyjaśnienia złożone przez innych Wykonawców, którzy, w Jego ocenie, złożyli je w sposób obszerny i wyczerpujący. Zdaniem Odwołującego, niewłaściwym wydaje się w ogóle przytaczanie przez Zamawiającego takiego porównania w sytuacji, gdy jedynie On zna treść złożonych przez innych Wykonawców wyjaśnień i subiektywnie stwierdza, że są one obszerne i wyczerpujące - Odwołujący nie znał treści pytań skierowanych przez Zamawiającego do innych Wykonawców, a mogły one być sformułowane w sposób bardziej precyzyjny aniżeli te skierowane do Odwołującego. Przytoczył Odwołujący wyrok Krajowej Izby Odwoławczej z dnia 9 kwietnia 2010r. (sygn. akt KIO/UZP 408/09), podając że pytania kierowane do KIO/UZP 2010/10 4 Odwołującego były sformułowane zbyt ogólnie i nie określały jednoznacznie jakich wyjaśnień oczekuje Zamawiający (wadliwość zapytań formułowanych przez Zamawiającego zostanie przedstawiona w punkcie dotyczącym zarzutu naruszenia przepisu art. 89 ust. 1 pkt 2 ustawy Prawo zamówień publicznych). Skutkowało to tym, iż w kolejnych pismach (tj. 7 i 24 lipca 2010 r.) Zamawiający, uściśliwszy nieco swoje pytania, żądał składania ponownych wyjaśnień do Oferty. Odwołujący uznaje, iż po trzykrotnym złożeniu wyjaśnień, niesłuszne jest stwierdzenie Zamawiającego zamieszczone w rozstrzygnięciu Protestu, że Odwołujący udzielił „informacji szczątkowych” lub „powtórzonych z już udzielonych, niepełnych wyjaśnień”. Nadto Zamawiający w rozstrzygnięciu Protestu podkreśla, iż art. 87 ust. 1 i la uprawnia do uzyskania wyjaśnień, podczas gdy orzecznictwo subtelnie przychyla się ku tezie przeciwnej(wyrok Krajowej Izby Odwoławczej z dnia 9 marca 2010r., sygn. akt KIO/UZP 149/10; wyrok Krajowej Izby Odwoławczej z dnia 5 listopada 2009r., sygn. akt KIO/UZP 1443/09). Odwołujący podtrzymał podniesioną w Proteście tezę i argumentację ją uzasadniającą o utożsamieniu przez Zamawiającego pojęć oprogramowania aplikacyjnego i Systemu ITSM, które to bezpośrednio wpłynęło na wyciągnięcie przez Zamawiającego błędnych wniosków i bezpodstawne odrzucenie Oferty Odwołującego poprzez wadliwą jej ocenę w zakresie zgodności z treścią SIWZ. Jak podkreślono w Proteście, o wadliwości sformułowanych przez Zamawiającego pytań, a następnie wadliwości uzasadnienia odrzucenia Oferty Odwołującego umieszczonego w zawiadomieniu o wyborze najkorzystniejszej oferty dobitnie świadczy fakt, iż Zamawiający błędnie utożsamia pojęcia oprogramowania aplikacyjnego i Systemu ITSM. Wymagania SIWZ dotyczą Systemu ITSM, który zgodnie z definicją z § 1 Załącznika nr 4 do SIWZ stanowi: „System wspierający zarządzanie komputerami stacjonarnymi i przenośnymi, serwerami oraz wspomagający prace Wydziału Technicznego Wsparcia Użytkowników (Help-Desk) w Ministerstwie Spraw Zagranicznych i placówkach zagranicznych, który zostanie wdrożony w jawnych i niejawnych środowiskach informatycznych Zamawiającego, stanowiący przedmiot niniejszej Umowy”. W tym samym paragrafie Zamawiający definiuje także oprogramowanie aplikacyjne: „Dedykowane oprogramowanie komputerowe, zapewniające wsparcie procesów Zamawiającego zgodnie z wymaganiami przedstawionymi w SIWZ, w tym w szczególności w Załączniku nr 8 do Umowy - Opis przedmiotu zamówienia". Nie ulega wątpliwości zatem, że nie są to pojęcia tożsame. Wskazał dalej Odwołujący, że w § 2 i § 3 Załącznika nr 4 do SIWZ Zamawiający określił przedmiot Umowy, która zostanie zawarta z wybranym Wykonawcą. I tak § 2 stanowi, iż „Na KIO/UZP 2010/10 5 warunkach określonych niniejszą Umową Wykonawca zobowiązuje się do wykonania dzieła w postaci systemu wspierającego zarządzanie komputerami stacjonarnymi i przenośnymi, serwerami oraz wspomagającego prace Wydziału Technicznego Wsparcia Użytkowników (Help-Desk) w Ministerstwie Spraw Zagranicznych i placówkach zagranicznych oraz Obiektach (Systemu), a Zamawiający zobowiązuje się do zapłaty umówionego wynagrodzenia”. W § 3 Zamawiający wskazuje poszczególne etapy budowy Systemu, w szczególności etap polegający na niezbędnym dostosowaniu oprogramowania aplikacyjnego do wymagań Zamawiającego: ,Dzieło, o którym mowa w § 2, składa się w szczególności z następujących elementów (Etapów): (...) Etap II - Dostawa, instalacja, konfiguracja, parametryzacja (także z wykorzystaniem zasobów sprzętowo - programowych Zamawiającego) i uruchomienie komponentów (Wdrożenie) Systemu wraz z systemem testowym, w tym Sprzętu i oprogramowania opisanych w Załączniku nr 8 do Umowy - Opis przedmiotu zamówienia (...)”. Tym samym sam Zamawiający podkreśla konieczność wykonania w ramach Wdrożenia czynności dostosowania oprogramowania aplikacyjnego do wymagań Zamawiającego i realiów technologicznych środowiska informatycznego - konfiguracji oraz parametryzacji, celem osiągnięcia dzieła w postaci Systemu ITSM, spełniającego wymagania określone w SIWZ. W odniesieniu do zarzutu naruszenia art. 92 ust. 1 pkt 2 ustawy Prawo zamówień publicznych, Odwołujący podniósł, iż przepis ten zobowiązuje Zamawiającego, niezwłocznie po dokonaniu wyboru oferty najkorzystniejszej, do zawiadomienia wykonawców, którzy złożyli oferty o wykonawcach, których oferty zostały odrzucone, z podaniem uzasadnienia faktycznego i prawnego. Odwołujący podał, że Zamawiający wskazał jedynie podstawę prawną odrzucenia Oferty Odwołującego, nie można bowiem uznać, iż sformułowanie, że „niezgodność oferty firmy Konsorcjum: Bazy i Systemy Bankowe Sp. z o.o. i Pentegy S.A.(...) z SIWZ polega na niespełnieniu przez, zaproponowane przez Wykonawcę, oprogramowanie aplikacyjne wymagań”, po czym przytoczenie odpowiednich postanowień Załącznika nr 1 do SIWZ, stanowi uzasadnienie faktyczne. Brakuje, zdaniem Odwołującego, wskazania, na czym konkretnie polega owa niezgodność. Przytoczył Odwołujący wyrok Krajowej Izby Odwoławczej z dnia 30 lipca 2010r. , sygn. akt KIO 1503/10. Zdaniem Odwołującego, Zamawiający powinien podać konkretne zapisy Oferty Odwołującego w zakresie, w jakim są one sprzeczne z przywołanymi postanowieniami Załącznika nr 1 do SIWZ, podczas gdy Zamawiający dopiero w rozstrzygnięciu protestu podał skonkretyzowane przyczyny odrzucenia oferty Odwołującego, Odwołujący nie mógł więc wiedzieć w jakim stopniu jego wyjaśnienia zostały uwzględnione, a w konsekwencji nie KIO/UZP 2010/10 6 mógł podjąć prawidłowej obrony. Nie zgodził się Odwołujący z argumentacją rozstrzygnięcia protestu, zgodnie z którą Zamawiający w uzasadnieniu odrzucenia Oferty zamieścił tylko te informacje, które zgodnie z dyspozycją art. 92 ust. 1 pkt 2 mógł przekazać wszystkim Wykonawcom ze względu na ochronę informacji stanowiących tajemnicę przedsiębiorstwa. Nie są to jednak informacje, które w jakikolwiek sposób dotykają treści Oferty złożonej przez Odwołującego. Natomiast już w rozstrzygnięciu Protestu Zamawiający podaje skonkretyzowane naruszenia, które odwołują się do treści Oferty Odwołującego. Stanowisko Zamawiającego staje się w tym momencie rozbieżne. W uzasadnieniu odrzucenia Oferty, nie wskazuje na naruszenia odnoszące się do treści Oferty Odwołującego, ponieważ jest ono przekazywane wszystkim Wykonawcom. W rozstrzygnięciu Protestu, Zamawiający jednak nie widzi przeszkód, aby odwołać się do konkretnych zapisów Oferty Odwołującego, pomimo iż do postępowania protestacyjnego przystąpiła w dniu 30 sierpnia 2010r. firma Comarch S.A., a na podstawie art. 183 ust. 4 ustawy Prawo zamówień publicznych. Zdaniem Odwołującego, argumentacja Zamawiającego w zakresie takiego sformułowania uzasadnienia faktycznego dla odrzucenia Oferty Odwołującego ze względu na ochronę informacji stanowiącej tajemnicę przedsiębiorstwa, jest bezzasadna i ma na celu zakamuflowanie przez Zamawiającego naruszenia przepisu art. 92 ust. 1 pkt 2 pzp poprzez niewskazanie uzasadnienia faktycznego. W odniesieniu do zarzutu naruszenia art. 89 ust. l pkt 2 ustawy Prawo zamówień publicznych, Odwołujący podał, że na mocy tego przepisu Zamawiający obowiązany jest odrzucić Ofertę, której treść nie odpowiada treści specyfikacji istotnych warunków zamówienia. Jednakże niezgodność ta musi rzeczywiście występować. Uwzględniając zaś przedstawione poniżej wyjaśnienia trudno przyznać rację twierdzeniom Zamawiającego, zawartym w piśmie z dnia 16 sierpnia 2010 r. - „zawiadomienie o wyborze oferty najkorzystniejszej”, zgodnie z którym Oferta Odwołującego została odrzucona z powodu rzekomej niezgodności z treścią SIWZ w 6 punktach. W odniesieniu do sformułowanego wymagania funkcjonalnego nr [WF 85] podano, że Odwołujący w ramach udzielonych Zamawiającemu wyjaśnień potwierdził, że proponowane rozwiązanie spełnia stawiane wymaganie. Odwołujący podaje, że Zamawiający użył w wymaganiu sformułowania „system powinien wymuszać dodatkowe akceptacje”, które w żadnej mierze, w kontekście prawidłowości sformułowania obligatoryjności w języku polskim nie jest jednoznaczne. Określenie „powinien wymuszać” nie jest równoważne z „musi wymuszać”, co w kontekście tego wymagania byłoby jednoznaczne. W związku z tak niejednoznacznym sformułowaniem pytania, odpowiedź Odwołującego miała na celu KIO/UZP 2010/10 7 ukazanie jedynie, w jaki sposób system może obsłużyć wymaganie [WF 85]. Jednak zgodnie z ITIL, realizacja modyfikacji okien czasowych w trakcie trwania których ze względów biznesowych nie powinno wystąpić zakłócenie funkcjonowania systemu w postaci zapisanej w przedmiotowym wymaganiu, nie jest zgodna z najlepszymi praktykami zarządzania procesami opisanymi w opublikowanych przez OGC bibliotekach ITIL. Dzieje się tak, ponieważ realizacja zmiany parametrów okien czasowych przy wymaganej wysokiej dostępności dla danego elementu konfiguracji, dotyczy złożonego procesu składającego się z kilku elementów różnych procesów ITIL, a nie tylko akceptacji określonego przełożonego. Sytuacja taka nie jest tak prostą, banalną czynnością jak tylko i wyłącznie akceptacja modyfikacji ww. parametru przez któregoś z przełożonych. Zmiany w konfiguracji okna czasowego dostępności usługi/elementu konfiguracji, przede wszystkim oznacza, że zmiana taka jest powiązana ze zmianą warunków świadczenia usługi (SLA) dla danej usługi i powinna być uprzednio uzgodniona zarówno z Gestorem usługi, Biznesem, a i pośrednio z Klientem. Wprowadzenie zmian w usłudze na innych zasadach według ITIL nie ma uzasadnienia biznesowego i jest nieuprawnione. Jeśli jednak istnieje rzeczywista, uzgodniona z Biznesem i Gestorem, poparta aneksami w stosownych umowach, potrzeba wprowadzenia zmiany dotyczącej warunków świadczenia (modyfikacja okien dostępności) danej usługi, to potrzeba wprowadzenia takiej zmiany powinna być zrealizowana jako odrębny, niezależny proces zarządzania zmianą. Ponieważ zmiana parametrów okna dostępności zmienia zapisy dotyczące parametrów elementów konfiguracji, to dotyczy to również procesu zarządzania konfiguracją. Powyższy proces zmiany jakichkolwiek parametrów usługi lub/i elementu(ów) konfiguracji nie jest więc tak prosty jak oczekiwania sformułowane w [WF 85]. Zatem wskazana dopiero w uzasadnieniu rozstrzygnięcia Protestu, a nie w SIWZ, obligatoryjność akceptacji wprowadzenia takiej zmiany, stanowi doprecyzowanie wymagania/pytania i z tego powodu Zamawiający nie mógł uzyskać uprzednio klarownej odpowiedzi. Wskazał Odwołujący, iż przedmiotowe wymaganie nie zostało sformułowane zgodnie z najlepszymi praktykami ITIL. Proponowany przez Odwołującego sposób obsługi wskazanej sytuacji przedstawiał rozwiązania, odpowiadające jedynie na postawione wymaganie. Dodatkowo w SIWZ nie ma stwierdzenia, iż wykonawca jest obligatoryjnie zobowiązany do przedstawienia odpowiedniej dokumentacji technicznej na uzasadnienie oczekiwanej w SIWZ funkcjonalności oprogramowania aplikacyjnego. Fakt, że w uzasadnieniu rozstrzygnięcia Protestu Zamawiający powołuje się na brak dokumentacji technicznej, opisującej oczekiwaną funkcjonalność, jest nadinterpretacją postanowień SIWZ. KIO/UZP 2010/10 8 W odniesieniu do sformułowanego wymagania funkcjonalnego nr [WF 152], podano, że Odwołujący w ramach udzielonych Zamawiającemu wyjaśnień potwierdził że proponowane rozwiązanie spełnia stawiane wymaganie. W przesłanych do Zamawiającego wyjaśnieniach oferty, przedstawiony został prosty przykład wyszukiwania elementów konfiguracji polegający na wyszukaniu urządzeń Blackberry. Z wymagania oraz pytań Zamawiającego nie wynikało jasno, jakie kryteria powinny zostać uwzględnione, aby identyfikowały pozycję magazynową alternatywnego elementu konfiguracji. Dopiero w uzasadnieniu rozstrzygnięcia Protestu pojawił szczegółowy opis sytuacji wydania monitora podobnego jako alternatywnego. Określenie cech wspólnych dla alternatywnych pozycji magazynowych powinno być realizowane dzięki porównaniu określonych cech funkcjonalnych. Przedstawiony w uzasadnieniu rozstrzygnięcia Protestu przykład z wyszukaniem monitora zastępczego dla komputerów stacjonarnych pomiędzy dwoma wskazanymi typami jest niereprezentatywny dla poruszonego zagadnienia. W tym sposobie realizacji porównania, nie ma możliwości przeprowadzenia jakiejkolwiek analizy cech wspólnych wymienionych dwóch monitorów, a wyszukanie jedynie polega na prostym powiązaniu w systemie magazynowym tych dwóch pozycji. Z prostoty takiego rozwiązania wynika jego ułomność polegająca na ogromnym przybliżeniu „podobieństw” pomiędzy tymi wyrobami. Odwołujący podał, że w Jego rozwiązaniu możliwe jest natomiast wyszukanie pozycji nie tylko według określonej nazwy urządzenia, ale również wyszukanie według podobieństw innych cech funkcjonalnych. Wobec tego można stwierdzić, iż Zamawiający sformułował tak wymaganie, że nie było możliwe odczytanie jego intencji. W związku z tym nie powinien dziwić fakt, że udzielone wielokrotnie odpowiedzi nie były dla Zamawiającego satysfakcjonujące. Udzielona przez Odwołującego odpowiedź, wynika więc wyłącznie ze sposobu formułowania zapytań przez Zamawiającego, który jak wykazano jest wysoce nieprecyzyjny, co może sugerować, że Zamawiający celowo, w określony sposób wielokrotnie nieprecyzyjnie, formułował nowe zapytania tak, aby uzyskane odpowiedzi nie były takie, jakich Zamawiający oczekiwał, mimo iż oferowane oprogramowanie posiada wymaganą funkcjonalność. W ocenie Odwołującego, w stanie faktycznym sprawy na tak postawione pytanie została przez Odwołującego udzielona prawidłowa i adekwatna do pytania odpowiedź. W odniesieniu do sformułowanego wymagania funkcjonalnego nr [WF 208], podano, że Odwołujący w ramach udzielonych Zamawiającemu wyjaśnień potwierdził że proponowane rozwiązanie spełnia stawiane wymaganie. Odwołujący nie poznał jednoznacznej dla Zamawiającego definicji określającej pojęcie dołączenia do obrazu systemu dowolnego KIO/UZP 2010/10 9 zestawu aplikacji użytkowych w tzw. „pojedynczym przebiegu dystrybucji nowego komputera”. Mimo iż Zamawiający trzykrotnie żądał wyjaśnień w tej kwestii, to ani razu nie doprecyzował postawionego wymagania. Szczególnie istotne jest w tym przypadku określenie „dowolności dołączanego oprogramowania”. W ten sposób sformułowane wymaganie nie specyfikujące nawet w ogólnym zarysie określenia „dowolne” i rodzi słuszną obawę, iż Zamawiający nie może w sposób korporacyjny określić zakresu wymaganych aplikacji. Z powodu nie dookreślenia przez Zamawiającego „dowolności dodawanego oprogramowania”, powstaje uzasadniona wątpliwości związana w ogóle z możliwością zrealizowania postawionego wymagania. Dlatego też Odwołujący udzielił kilkukrotnie odpowiedzi, z której jednoznacznie wynikało, iż proces instalacji dodatkowego oprogramowania zależy od oprogramowania, jakie ma zostać zainstalowane na nowym komputerze. Odwołujący wskazał przy tym, iż opracowana metoda instalacji, uzależniona jest od zakresu pożądanych aplikacji i zostanie opracowana w trakcie wdrożenia, co stanowi realne stanowisko w tej sprawie. Przy braku jakiejkolwiek szczegółowej informacji nt. specyfikacji oczekiwanego oprogramowania dodatkowego, odpowiedź nie może być inna. W odniesieniu do sformułowanego wymagania funkcjonalnego nr [NF 21], podano, że Odwołujący w ramach udzielonych Zamawiającemu wyjaśnień potwierdził że proponowane rozwiązanie spełnia stawiane wymaganie. W odniesieniu do wskazanego powyżej wymagania podkreślić należy, iż jedyną kwestią do której Zamawiający zgłosił zastrzeżenie na której oparł zarzut braku spełniania wymagań SIWZ, był poruszony w ww. wymaganiu wątek szyfrowania wskazanych danych. W kwestii związanej z szyfrowaniem bazy danych, Odwołujący podkreślił, że to zagadnienie związane jest z ogólnymi praktykami rozwiązań tego typu kwestii na świecie i oczekiwaną funkcjonalność trudno odnaleźć w rozwiązaniach podobnego typu, ponieważ jej charakter, czyli możliwość całkowicie selektywnego szyfrowania dowolnych pól bazy danych prowadzi do rozwiązania, które byłoby uniwersalne w swojej uniwersalności, co jest po prostu niemożliwe, przy czym tak szczegółowa granulacja konfiguracji szyfrowania jest, zdaniem Odwołującego, bardzo nieprzemyślana z logicznego i technicznego punktu widzenia. W odniesieniu do sformułowanego wymagania funkcjonalnego nr [NF 04], podano, że Odwołujący w ramach udzielonych Zamawiającemu wyjaśnień potwierdził że proponowane rozwiązanie spełnia stawiane wymaganie. Dodatkowo wyjaśnił, iż polonizacja dotyczyć będzie interfejsów webowych użytkownika systemu wsparcia oraz zapewnił, iż możliwość polonizacji jest przewidziana na etap wdrożenia. Oznacza to, że dla użytkowników systemu zostałby dostarczony interfejs polskojęzyczny, natomiast w zakresie administracji systemu w KIO/UZP 2010/10 10 pewnych jego częściach wymagany byłby język angielski. Zdaniem Odwołującego nie jest to cecha dyskryminująca ofertę. Dodatkowo można stwierdzić, iż w wyniku polonizacji terminów anglojęzycznych na język polski mogą występować dwuznaczności związane z trudnościami w definiowaniu w języku polskim, w sposób precyzyjny, określeń czynności dokładnie zdefiniowanych w języku angielskim. Z tego powodu, powszechnie stosowaną praktyką jest używanie przez administratorów interfejsów w języku angielskim, co nie zmniejsza funkcjonalności rozwiązania, a jedynie służy właściwemu procesowi obsługi systemu. W związku z powyższym można uznać, zdaniem Odwołującego, iż sformułowanie wymagalności polonizacji w częściach administracyjnych interfejsów systemu jest sprzeczne z ustawą o języku polskim z dnia 7.10.1999 r. (Dz.U. 1999.90.999), to jest brzmieniem jej art. 11, co czyni zasadnym wniosek, zdaniem Odwołującego, że przedmiotowe wymaganie zostało sformułowane niezgodnie z powszechnie obowiązującym w Polsce prawem. W odniesieniu do sformułowanego wymagania funkcjonalnego nr [NF 59], podano, że Odwołujący w ramach udzielonych Zamawiającemu wyjaśnień potwierdził, że proponowane rozwiązanie spełnia stawiane wymaganie. Przekazanie odpowiedzialności [NF59] - transfer odpowiedzialnego za wykonanie zadania na czas urlopu do innego analityka, nie oznacza przekazania zgłoszenia wyłącznie do osób z pierwszej linii wsparcia - operatorów. Określenie „analityk” odnosi się do wszystkich osób w proponowanym systemie, których typ dostępu jest określony jako „analityk”. W przekazanych odpowiedziach używany był przykład „ analityka”, co nie oznacza w żadnej mierze, że oferowane rozwiązanie umożliwia przekazywanie odpowiedzialności tylko operatorom Systemu ITSM. Powyższa funkcjonalność może być wykorzystywana również przez inne osoby, w tym osoby funkcyjne, zaangażowane w procesy zarządzania zmianą konfiguracją dostępnością itp. Podany został jedynie przykład ukazujący zasadę. Ponadto przedstawione rozwiązanie nie jest, jak to sugeruje Zamawiający, rozwiązaniem obejściowym, tylko standardową funkcjonalnością aplikacji. Zdaniem Odwołującego niewłaściwa ocena tej funkcjonalności wiąże się z faktem nieprecyzyjnego formułowania kolejnych zapytań, a przede wszystkim z nieprecyzyjnym określeniem wymagania. W kolejnych zapytaniach Odwołujący rozszerzał swoją odpowiedź, lecz dopiero w uzasadnieniu rozstrzygnięcia Protestu Zamawiający sformułował jakiej funkcjonalności oczekuje. W zapisach SIWZ bezpośrednio z treści wymagania [NF 59] wynika: „System winien udostępniać możliwość przejmowania roli jednego operatora systemu przez drugiego, np. na czas urlopu. Wymaganie precyzuje w jasny sposób jaki rodzaj przekazywania roli Zamawiający oczekuje. W tej sytuacji należy wnioskować, że chodzi tu o przekazywanie roli na poziomie operatora systemu, a nie o KIO/UZP 2010/10 11 przekazywanie jakichkolwiek innych ról. Zatem wniosek Zamawiającego, że oferowane rozwiązanie nie jest tym, jakiego oczekuje, a Odwołujący nie posiada systemowego rozwiązania, jest bezpodstawne. Po prostu odpowiedź, jaką Zamawiający otrzymał, jest właściwa do tak sformułowanego wymagania. Odwołujący końcowo wyartykułował zarzut naruszenia przez Zamawiającego dyspozycji art. 7 ust. 1 i 3 ustawy Prawo zamówień publicznych, uznając że Zamawiający dopuścił się bowiem naruszenia fundamentalnych, dla prawa zamówień publicznych, zasad uczciwej konkurencji oraz równego traktowania wykonawców. Odwołanie zostało poprzedzone protestem, w którym Odwołujący – Konsorcjum firm Bazy i Systemy Bankowe Sp. z o.o. w Bydgoszczy oraz Pentegy S.A. w Warszawie podniósł analogiczne zarzuty jak w odwołaniu. Do postępowania protestacyjnego, a następnie postępowania odwoławczego po stronie Zamawiającego przystąpił wykonawca Comarch SA w Krakowie. Na podstawie przedłożonej przez Zamawiającego, oryginalnej dokumentacji postepowania, oświadczeń i wyjaśnień stron i uczestnika postepowania, Krajowa Izba Odwoławcza ustaliła następujący stan faktyczny: Przedmiotem postępowania przetargowego, prowadzonego w trybie dialogu konkurencyjnego, w ramach którego Odwołujący złożył protest a następnie odwołanie jest „dostawa licencji i wdrożenie oprogramowania aplikacyjnego dla systemu wspomagającego zdalne monitorowanie, zarządzanie usługami, infrastrukturą teleinformatyczną (min. obejmującą komputery stacjonarne i przenośne, serwery oraz. urządzenia sieciowe) oraz dostawa licencji i wdrożenie oprogramowania aplikacyjnego dla systemu wspomagającego prace Wydziału realizującego wsparcie użytkowników (ang. HelpDesk) w Ministerstwie Spraw Zagranicznych i placówkach zagranicznych”. Zamawiający szczegółowo opisał przedmiot zamówienia w załączniku nr 1 do SIWZ gdzie zamieścił wszelkie informacje niezbędne do przygotowania oferty przez Wykonawców. Zamawiający zamieścił w specyfikacji istotnych warunków zamówienia opis pojęć przyjętych na użytek przedmiotowego postępowania w oparciu o Dictionary of IT Service Management. Terms, Acronyms and Abbreviations. ITIL v3 edition oraz tłumaczenia wybranych pojęć na język polski opublikowane przez ITSMF. Zamawiający zdefiniował pojęcie, przeznaczenie i umiejscowienie systemu, będącego przedmiotem zamówienia: „System jest przeznaczony do KIO/UZP 2010/10 12 wsparcia procesów zarządzania usługami IT u Zamawiającego. Pojęcie System ITSM obejmuje sprzęt, oprogramowanie, dokumentację, szkolenia, narzędzia oraz udokumentowanie procesów i działań niezbędnych do skutecznej i efektywnej realizacji zadań postawionych przed BIT (…)”. Zamawiający w specyfikacji istotnych warunków zamówienia szczegółowo przedstawił dalej katalog wymagań funkcjonalnych i niefunkcjonalnych stawianych wobec systemu ITSM, w tym między innymi wymagań funkcjonalnych: [WF 85], [WF 152], [WF 208] oraz niefunkcjonalnych: [NF 04], [NF 21] i [NF 59], o treści: - [WF 85]:„ System ITSM powinien umożliwiać definiowanie okien czasowych dla jednostek konfiguracji, w których niedostępność danej jednostki konfiguracji będzie miało poważny wpływ na funkcjonowanie organizacji. W przypadku konieczności dokonania zmiany w takim okresie system powinien wymuszać dodatkowe akceptacje ze strony osób wskazanych podczas definiowania takiego okresu”; - [WF 152] o treści: „System ITSM musi umożliwić wyszukiwanie pozycji wskazane jako alternatywne do wskazanej pozycji magazynowej."; - [WF 208]: „Podczas automatycznej instalacji systemu operacyjnego powinna istnieć możliwość dołączenia do obrazu systemu dowolnego zestawu aplikacji użytkowych (instalowanych podczas pojedynczego przebiegu dystrybucji nowego komputera; - [NF 21] o treści: „ System ITSM musi posiadać możliwość zdefiniowania tzw. dostępu warunkowego do danych. Oznacza to, że administrator systemu musi posiadać możliwość swobodnego definiowania, na podstawie dowolnych warunków logicznych zdefiniowanych na danych z rekordu, uprawnień dla użytkowników do tego rekordu m.in. czy użytkownik widzi dany rekord, które pola widzi i które pola może edytować. System ITSM musi posiadać mechanizm szyfrujący wskazane dane w bazie danych w sposób uniemożliwiający odczytanie ich wartości stosując inne narzędzia.”; - [NF 04]: „System musi być całkowicie spolonizowany łącznie z narzędziami administracyjnymi”; - NF 59]: „System winien udostępniać możliwość przejmowania roli jednego operatora systemu przez drugiego, np. na czas urlopu.”. KIO/UZP 2010/10 13 Krajowa Izba Odwoławcza zważyła, co następuje: jak W pierwszej kolejności Krajowa Izba Odwoławcza ustaliła, że wobec wszczęcia w dacie 31 sierpnia 2009r. (data ogłoszenia o zamówieniu) postępowania o udzielenie zamówienia publicznego, którego dotyczy rozpoznawane przez Izbę odwołanie, to jest przed dniem 29 stycznia 2010 r., w którym weszły w życie przepisy ustawy z dnia 2 grudnia 2009 r. o zmianie ustawy - Prawo zamówień publicznych oraz niektórych innych ustaw (Dz. U. Nr 223, poz. 1778), do jego rozpoznawania mają zastosowanie przepisy ustawy Prawo zamówień publicznych w brzmieniu wcześniejszym, przed nowelizacją dokonaną ustawą z dnia 2 grudnia 2009 r. Jednocześnie Krajowa Izba Odwoławcza ustaliła, że do przedmiotowego odwołania zastosowanie znajdują przepisy rozporządzenia Prezesa Rady Ministrów z dnia 2 października 2007 r. w sprawie regulaminu postępowania przy rozpoznawaniu odwołań (Dz. U. Nr 187, poz. 1327 oraz z 2008 r. Nr 188, poz. 1156) oraz rozporządzenie Prezesa Rady Ministrów z dnia 9 lipca 2007 r. w sprawie wysokości oraz sposobu pobierania wpisu od odwołania oraz rodzajów kosztów w postępowaniu odwoławczym i sposobu ich rozliczania (Dz. U. Nr 128, poz. 886 oraz z 2008 r. Nr 182, poz. 1122). W drugiej kolejności ustalono, że nie została wypełniona żadna z przesłanek skutkujących odrzuceniem odwołania w trybie art. 187 ust. 4 ustawy Prawo zamówień publicznych. Odwołującemu przypisano także, wbrew argumentacji Przystępującego posiadanie interesu prawnego, w rozumieniu art. 179 ust. 1 ustawy Prawo zamówień publicznych – skoro Odwołujący wnosi o o nakazanie dokonania ponownego badania i oceny ofert z uwzględnieniem jego oferty, to należało uznać, że powyższy wniosek konsumuje w swej treści żądanie uchylenia wyboru, jako najkorzystniejszej oferty złożonej przez Comarch SA w Krakowie. Oferta odwołującego jest najkorzystniejszą w postępowaniu, w którym jedynym kryterium jest cena i termin realizacji (z wagami odpowiednio tych kryteriów: 90 % oraz 10 %). Przepis art. 191 ust. 1a ustawy Prawo zamówień publicznych stanowi, że uwzględnienie odwołania może mieć miejsce tylko wtedy, gdy zostanie stwierdzone takie naruszenie przepisów ustawy, które miało lub może mieć istotny wpływ na wynik postępowania, co ze wskazanych niżej względów nie miało miejsca. Oceniając stan faktyczny sprawy oraz kwestionowaną w odwołaniu i w granicach odwołania i protestu (zgodnie z brzmieniem art. 191 ust. 3 ustawy Prawo zamówień KIO/UZP 2010/10 14 publicznych) czynność Zamawiającego polegającą na odrzuceniu oferty Odwołującego, uznać należało, że w analizowanym zakresie nie doszło do naruszenia przepisów ustawy Prawo zamówień publicznych. 1. Ustosunkowując się dalej do zarzutów odwołania należało stwierdzić w pierwszym rzędzie, że nie zasługuje na uwzględnienie zarzut naruszenia przez Zamawiającego art. 87 ust. 1 oraz 1 a ustawy Prawo zamówień publicznych. Odwołujący zdaje się stać na stanowisku, iż Zamawiający w oparciu o dyspozycje wskazanych przepisów obowiązany jest tak długo prowadzić czynności zmierzające do wyjaśnienia oferty, aż informacje złożone przez wykonawcę doprowadzą do uznania, że Jego oferta spełnia warunki postawione przez Zamawiającego. Podkreślenia wymaga, że istotnie, wskazane przepisy nakładają na zamawiającego powinność dążenia w postępowaniu do uzyskania wyjaśnień dotyczących oferty, przy czym znajdujący zastosowanie do analizowanej sytuacji (dialogu konkurencyjnego) przepis art. 87 ust. 1 a ustawy daje jednocześnie większą swobodę obu stronom, dopuszczając elementy negocjacyjne, to jest sprecyzowanie i dopracowanie treści oferty przez wykonawcę, a także przedstawienie informacji dodatkowych, zaś granicą uzyskiwania takich wyjaśnień jest obowiązek niedokonywania istotnych zmian w treści oferty. Na gruncie analizowanej sprawy Zamawiający aż trzykrotnie występował do Odwołującego o wyjaśnienie treści oferty, przy czym w odniesieniu do kwestionowanych wymagań funkcjonalnych i niefunkcjonalnych: [WF 85] – pismami z dnia 18 czerwca 2010r. oraz 21 lipca 2010r.; [WF 152] - pismami z dnia 18 czerwca 2010r., 7 lipca 2010r. oraz 21 lipca 2010r.; [WF 208] - pismami z dnia 18 czerwca 2010r., 7 lipca 2010r. oraz 21 lipca 2010r.; [NF 04] –pismem z dnia 18 czerwca 2010r.; [NF 21] - pismami z dnia 18 czerwca 2010r., 7 lipca 2010r. oraz 21 lipca 2010r. oraz w odniesieniu do warunku [NF 59] – pismami z dnia 18 czerwca 2010r., 7 lipca 2010r. oraz 21 lipca 2010r. Wskazane pisma wyraźnie wskazują na żądanie udzielenia przez Odwołującego wyjaśnień na podstawie art. 87 ust. 1- 1a ustawy Prawo zamówień publicznych. Należy uznać, że wskazane trzykrotne żądania wyjaśnienia oferty w tym samym zakresie (w odniesieniu do tych samych wymagań) są dopuszczalne i nie naruszają zasad postępowania o zamówienie publiczne, z uwagi na szczególny charakter tego postępowania, to jest przyjęty tryb dialogu konkurencyjnego, który z istoty dopuszcza pewne, opisane wyżej elementy negocjacyjne w zakresie złożonej oferty. Tym samym, wskazane czynności Zamawiającego, zdają się być podjętymi w interesie Odwołującego, zmierzając do wyjaśnienia treści oferty tak, by możliwe było przesądzenie czy spełnia ona postawione w specyfikacji istotnych warunków wymagania. Powyższe, aż KIO/UZP 2010/10 15 trzykrotne wystosowane przez Zamawiającego wezwania do wyjaśnień Odwołującego zdaje się być wynikiem życzliwego traktowania tego wykonawcy i próbą dania mu szansy wykazania, że treść jego oferty zgodna jest z treścią specyfikacji istotnych warunków zamówienia. Przytoczyć warto na powyższą okoliczność argumentację Zamawiającego, zawartą w rozstrzygnięciu protestu, wyjaśniającą powody aż trzykrotnego wezwania: „(…) Zamawiający przypuszczał, że podczas sezonu urlopowego osoby merytorycznie odpowiedzialne za projekt po stronie Protestującego przebywają na urlopach wypoczynkowych, a w ich zastępstwie treści, wyjaśnień i dodatkowych informacji przygotowywane są przez osoby nieznające oferowanego produktu. Po upływie dwóch miesięcy Zamawiający mógł na podstawie udzielanych odpowiedzi potwierdzić swoje wątpliwości i uznać ostatecznie, że treść oferty Protestującego nie odpowiada treści specyfikacji istotnych warunków zamówienia.” Treść każdego z zapytań, wbrew twierdzeniom Odwołującego w odniesieniu do wymienionych wymagań jest jednoznaczna i pozwala odczytać intencje Zamawiającego oraz zakres pożądanej odpowiedzi. Przytoczenia wymagają pytania Zamawiającego, których treść pozwala odczytać zakres pożądanego kierunku odpowiedzi: - co do wymagania [WF85]; w piśmie Zamawiającego z dnia 18 czerwca 2010 r., pytanie brzmi: „[WF85] System ITSM powinien umożliwiać definiowanie okien czasowych dla jednostek konfiguracji, w których niedostępność danej jednostki konfiguracji będzie miało poważny wpływ na funkcjonowanie organizacji. W przypadku konieczności dokonania zmiany w takim okresie system powinien wymuszać dodatkowe akceptacje ze strony osób wskazanych podczas definiowania takiego okresu”. W jaki sposób zaoferowane oprogramowanie aplikacyjne zapewnia możliwość definiowania okien czasowych dla jednostek konfiguracji, w których niedostępność danej jednostki konfiguracji będzie miała poważny wpływa na funkcjonowanie organizacji. W przypadku konieczności dokonania zmiany w takim okresie system powinien wymuszać dodatkowe akceptacje ze strony osób wskazanych podczas definiowania takiego okresu - [WF 85] SIWZ”, w piśmie Zamawiającego z dnia 7 lipca 2010r., pytanie do tego zapisu stanowi: „W jaki sposób oprogramowanie aplikacyjne wymusza uzyskanie dodatkowych akceptacji w przypadku występowania konfliktów okien serwisowych oraz w jaki sposób realizowane jest powiązanie pomiędzy procesem zatwierdzania, a atrybutem jednostki konfiguracji zgodnie z wymogiem NF85 SIWZ? Zamawiający prosi o dołączenie do odpowiedzi zrzutów ekranowych oprogramowania aplikacyjnego odpowiedzialnego za realizację ww, wymogu oraz opisu realizacji ww. wymagania zawartego w dokumentacji technicznej oprogramowania aplikacyjnego”, zaś w KIO/UZP 2010/10 16 ostatnim piśmie Zamawiającego z dnia 21 lipca 2010 r: „W związku z wymaganiem [WF 85] Zamawiający prosi o przedstawienie sposobu realizacji tego wymagania - Ponadto Zamawiający prosi o przedstawienie w jaki sposób system może wymusić przeprowadzenie dodatkowych zatwierdzeń lub też korekt w przypadku wystąpienia konfliktów w planie zmian. Zamawiający prosi także o wskazanie, jakie istniejące mechanizmy proponowanego oprogramowania aplikacyjnego zostaną wykorzystane do realizacji tego zadania." - co do wymagania [WF152]: w piśmie Zamawiającego z dnia 18 czerwca 2010 r., pytanie brzmi: „W jaki sposób zaoferowane oprogramowanie aplikacyjne umożliwi wyszukiwanie pozycji wskazane jako alternatywne do wskazanej pozycji magazynowej - [WF152]?”; w piśmie z dnia 7 lipca 2010 r.: „W odpowiedzi na pytanie nr 50 Wykonawca nie wyjaśnił precyzyjnie sposobu realizacji wymagania opisanego w WF 152. Zamawiający prosi o doprecyzowanie odpowiedzi na zadane pytanie oraz o przedstawienie opisu realizacji wymagania WF 152 zawartego w dokumentacji technicznej oprogramowania aplikacyjnego.”, a w piśmie z dnia 21 lipca 2010 r.: „W celu doprecyzowania sposobu spełniania wymagania [WF 152] Zamawiający prosi o przedstawienie z uwzględnieniem zrzutów ekranowych aplikacji sposobu definiowania alternatywnych pozycji magazynowych. Ponadto Zamawiający prosi o przedstawienie w jaki sposób definiowane są alternatywne pozycje magazynowe.”. - co do wymagania [WF 208], w piśmie Zamawiającego z dnia 18 czerwca 2010 r. pytanie brzmi: „W jaki sposób zaoferowane oprogramowanie aplikacyjne zapewnia by podczas automatycznej instalacji systemu operacyjnego istniała możliwość dołączenia do obrazu systemu dowolnego zestawu aplikacji użytkowych (instalowanych podczas pojedynczego przebiegu dystrybucji nowego komputera) - [WF 208] SIWZ”; w piśmie Zamawiającego z dnia 7 lipca 2010 r.: „ W odpowiedzi na pytanie nr 67 Wykonawca nie wyjaśnił precyzyjnie sposobu realizacji wymagania opisanego w WF 208. Zamawiający prosi o doprecyzowanie odpowiedzi na zadane pytanie oraz o przedstawienie opisu realizacji wymagania WF 208 zawartego w dokumentacji technicznej oprogramowania aplikacyjnego. Zamawiający prosi o wskazanie narzędzi odpowiedzialnych za realizację ww. wymogu oraz przyporządkowanie ich do oprogramowania aplikacyjnego wymienionego w ofercie.”, zaś w piśmie Zamawiającego z dnia 21 lipca 2010 r.: „Zamawiający w wymaganiu [WF 208] przedstawił potrzebę, istnienia możliwości dodania do wzorcowego obrazu dodatkowych aplikacji i dokonania dystrybucji tak przygotowanej paczki na docelowy komputer. Zamawiający prosi o przedstawienie sposobu realizacji tego wymagania zgodnie z jego opisem. Ponadto KIO/UZP 2010/10 17 Zamawiający prosi o wskazanie aplikacji wchodzących w skład oferowanego oprogramowania aplikacyjnego wykorzystywanego do realizacji tego wymagania." - co do wymogu [NF21], w piśmie Zamawiającego z dnia 18 czerwca 2010 r., pytanie stanowi: „W jaki sposób zaoferowane oprogramowanie aplikacyjne umożliwia zdefiniowanie tzw. warunkowego dostępu do danych - [NF21] SIWZ?”; w piśmie Zamawiającego z dnia 7 lipca 2010 r.: „W odpowiedzi na pytanie nr 22 Wykonawca nie udzielił precyzyjnej odpowiedzi w jaki sposób oferowane oprogramowania aplikacyjne umożliwia zdefiniowanie tzw. Warunkowego dostępu do danych - NF 21 SIWZ. Z odpowiedzi nie wynika, aby system potrafił nadawać w zależności od rekordu różne uprawnienia do poszczególnych pól czy funkcji systemu. Ze względu na krytyczność danych, które będą przechowywane w Systemie przez Zamawiającego muszą istnieć mechanizmy definiowania tego, co jest widoczne i edytowalne w obrębie każdego rekordu. Ponadto Zamawiający prosi o przedstawienie opisu realizacji wymagania NF 21 SIWZ zawartego w dokumentacji technicznej oprogramowania aplikacyjnego.” zaś w piśmie Zamawiającego z dnia 21 lipca 2010 r.: „W związku z wymaganiem [NF 21] Zamawiający prosi o podanie, na jakim minimalnym poziomie logicznym struktury informacyjnej oprogramowanie aplikacyjne udostępnia szyfrowanie danych tj. pola, rekordu, zestawów rekordów, całej bazy danych. Ponadto Zamawiający prosi o podanie jakie algorytmy szyfrowania udostępniane są standardowo przez oferowane oprogramowanie aplikacyjne.”; - w odniesieniu do wymogu [NF04] zawarte w piśmie Zamawiającego z dnia 18 czerwca 2010 r., pytanie brzmi: „Czy zaoferowane/ oprogramowanie aplikacyjne jest całkowicie spolonizowane łącznie z narzędziami administracyjnymi - [NF04] SIWZ?” - w zakresie wymagania [NF59], w piśmie Zamawiającego z dnia 18 czerwca 2010 r., postawione pytanie brzmi: „W jaki sposób zaoferowane oprogramowanie aplikacyjne zapewnia możliwość przejmowania roli jednego operatora systemu przez drugiego, np. na czas urlopu - [NF59] SIWZ?”; w kolejnym piśmie – z dnia 7 lipca 2010 r. pytanie brzmiało: „W jaki sposób oferowane oprogramowanie aplikacyjne zapewnia możliwość przejmowania roli jednego operatora systemu przez drugiego np. na czasu urlopu [NF 59] SIWZ? Z udzielonej przez Wykonawcę odpowiedzi wynika, że system nie oferuje systemowego rozwiązania zagadnienia zastępstwa pracownika, a Wykonawca proponuje rozwiązanie obejściowe. Zamawiający prosi przedstawienie opisu realizacji wymagania NF 59 zawartego w dokumentacji technicznej oprogramowania aplikacyjnego.”, zaś z zapytania z dnia 21 lipca 2010 r., wynika następująca treść pytania: „Jedną z istotnych dla Zamawiającego funkcjonalności jest możliwość wzajemnego przejmowania obowiązków przez pracowników. KIO/UZP 2010/10 18 Dostarczony System ITSM winien ułatwiać takie przenoszenia obowiązków, co zostało zdefiniowane w wymaganiu [NF 59]. Zamawiający prosi o opisanie i udokumentowanie za pomocą odpowiednich zrzutów t ekranów, w jaki sposób system wspomaga takie przenoszenie obowiązków.” Tym samym, przytoczone brzmienia zapytań co do realizacji postawionych przez Zamawiającego wymagań funkcjonalnych i niefunkcjonalnych wskazują wyraźnie, że wbrew twierdzeniom Odwołującego pytania były precyzyjne i dawały pełne podstawy, by wywieść, co jest ich przedmiotem i jaki winien być zakres odpowiedzi złożonej w odpowiedzi na nie. Nie sposób w tym miejscu zgodzić się z tezą zawartą w odwołaniu, zgodnie z którą mimo iż Zamawiający trzykrotnie żądał wyjaśnień w tej kwestii, to ani razu nie doprecyzował postawionego wymagania. Dostrzeżenia bowiem wymaga, że inicjatywa w zakresie zadawania zapytań w zakresie postawionych, a niezrozumiałych dla wykonawcy wymagań leżała po stronie zainteresowanego wykonawcy. W konsekwencji należało uznać, że aż trzykrotne wystosowanie przez Zamawiającego wezwań do wyjaśnienia oferty, w których postawione pytania były jasne i precyzyjne wyczerpuje realizację obowiązku określonego w art. 87 ust. 1 a ustawy Prawo zamówień publicznych, co czyni podniesiony w tym zakresie zarzut nieuzasadnionym. Bez znaczenia pozostaje tutaj podnoszona w odwołaniu okoliczność, że Zamawiający ostatecznie odrzucając ofertę Odwołującego powołał się na analogiczne wyjaśnienia innych wykonawców, podając, że były one szczegółowe i wyjaśniały zakreślone zagadnienia. Konfrontacja treści zapytań kierowanych do Odwołującego oraz do pozostałych dwóch wykonawców nie zmienia faktu, że w tym postepowaniu ocenie podlega czynność odrzucenia oferty Odwołującego, a zatem pośrednio treść zapytań skierowanych do tego wykonawcy i odpowiedzi udzielonych na te pytania, a w konsekwencji – spełnianie przez tego wykonawcę postawionych wymagań. Ocenie podlega bowiem działanie Zamawiającego w odniesieniu do oferty Odwołującego. Taki zakres wyznacza treść protestu a następnie odwołania, skierowanych wyraźnie do czynności Zamawiającego odrzucenia oferty Odwołującego. Oferty konkurencyjnych wykonawców nie podlegają i podlegać nie mogą analizie i ocenie, wobec braku zarzutów w tym zakresie. 2. Nie potwierdził się także postawiony w odwołaniu zarzut naruszenia art. 92 ust. 1 pkt 2 ustawy Prawo zamówień publicznych poprzez niewłaściwe wskazanie podstawy faktycznej odrzucenia oferty Odwołującego. Dostrzeżenia wymagało w tym zakresie, że na etapie informacji o odrzuceniu oferty Odwołującego, treści, które stały się przyczyną uznania jej niezgodności ze specyfikacją KIO/UZP 2010/10 19 istotnych warunków zamówienia były zastrzeżone przez Odwołującego jako tajemnica przedsiębiorstwa. Odwołujący zastrzegł bowiem treść wszystkich składanych wyjaśnień i dodatkowych informacji jako informacje stanowiące tajemnicę przedsiębiorstwa w rozumieniu przepisów o zwalczaniu nieuczciwej konkurencji, co musiało determinować względnie ogólny sposób uzasadnienia decyzji o odrzuceniu oferty Odwołującego. W uzasadnieniu decyzji o odrzuceniu oferty Odwołującego zawarto zatem tylko te informacje, które zgodnie z dyspozycją art. 92 ust. 1 pkt 2 ustawy Prawo zamówień publicznych, mógł przekazać wszystkim Wykonawcom, którzy złożyli oferty. Niezależnie jednak od tego, dostrzec należało, że decyzja o odrzuceniu oferty Odwołującego zawiera przytoczenie podstawy prawnej a także wskazanie wszystkich wymagań, jakie Zamawiający uznał za niespełnione na podstawie wyjaśnień Odwołującego, ze wskazaniem ich oznaczenia nadanego przez Zamawiającego oraz brzmienia postawionego wymagania. Powyższe przekonuje, że na podstawie tak opisanej decyzji Zamawiającego Odwołujący miał wystarczającą wiedzę o przyczynach odrzucenia Jego oferty, pozwalającą mu na podjęcie właściwie ukierunkowanej obrony swoich interesów w tym postępowaniu, co też uczynił wnosząc najpierw protest a następnie odwołanie. Dostrzec dalej należało, że przywołany w odwołaniu wyrok odnosi się do sytuacji, kiedy uzasadnienie decyzji o odrzuceniu oferty ma charakter blankietowy – ogólnie powołuje podstawę prawną tego odrzucenia, nie wyjaśniając dalej, jakie rzeczywiste przyczyny stanowiły o uznaniu niezgodności oferty ze specyfikacją istotnych warunków zamówienia, co nie może być porównywane z sytuacją zaistniałą w tym postępowaniu. Tym samym należało uznać, iż zakres informacyjny uzasadnienia decyzji o odrzuceniu oferty Odwołującego pozwala Odwołującemu prowadzić rzeczową polemikę z argumentami, które przemawiały za odrzuceniem jego oferty, czego wyrazem jest choćby złożenie wystarczająco uzasadnionego protestu jak i odwołania, zaś zarzut w powyższym zakresie należało uznać za bezzasadny. 3. Nie potwierdził się także zarzut naruszenia art. 89 ust. 1 pkt 2 ustawy Prawo zamówień publicznych, poprzez wadliwe uznanie, iż oferta Odwołującego podlega odrzuceniu z powodu jej niezgodności z treścią Specyfikacji Istotnych Warunków Zamówienia. Analiza postawionych przez Zamawiającego, spornych w tym postępowaniu wymagań funkcjonalnych: [WF 85], [WF 152], [WF 208] oraz niefunkcjonalnych: [NF 04], [NF 21] i [NF 59] w zestawieniu z postawionymi przez Zamawiającego zapytaniami oraz zaproponowanym w ofercie oprogramowaniem w odpowiednich jego wersjach i modułach a także zaprezentowanymi wyjaśnieniami pozwala stwierdzić, że Odwołujący nie wykazał spełniania przez zaoferowane narzędzia wymagań postawionych treścią specyfikacji istotnych KIO/UZP 2010/10 20 warunków zamówienia, w tym realizacji oczekiwanych, a opisanych w specyfikacji szczegółowych funkcjonalności. Podkreślenia na wstępie wymaga, wobec argumentacji podnoszonej przez Odwołującego, iż istotnie, postawione przez Zamawiającego funkcjonalności – obejmujące praktyczne aspekty użyteczności oferowanych narzędzi odnoszą się, w świetle brzmienia specyfikacji istotnych warunków zamówienia do systemu. System ten obejmuje szereg elementów, które Zamawiający opisał w pkt 3 Informacje ogólne, ppkt 3.2 Przeznaczenie i umiejscowienie systemu, w sposób następujący: System jest przeznaczony do wsparcia procesów zarządzania usługami IT u Zamawiającego. Pojęcie System ITSM obejmuje sprzęt, oprogramowanie, dokumentację, szkolenia, narzędzia oraz udokumentowanie procesów i działań niezbędnych do skutecznej i efektywnej realizacji zadań postawionych przed BIT (…)”. Tym samym, pojęcie „system” skonstruowane na potrzeby niniejszego postępowania obejmuje elementy sprzętu, oprogramowania, usługi szkoleniowe oraz sporządzenie dokumentacji procesów i działań związanych z funkcjonowaniem systemu, przy czym wymienione elementy po części pozostają w dyspozycji zamawiającego jako składające się na już posiadaną infrastrukturę informatyczną, po części zaś są przedmiotem tego postępowania. Poszczególne wymagania funkcjonalne dotyczące systemu, w tym sporne w tym postępowaniu [WF 85], [WF 152], [WF 208] zostały zagregowane w specyfikacji w trzynaście swego rodzaju bloków tematycznych: zarządzanie katalogiem usług; zarzadzanie poziomem usług; zarządzanie incydentami; obsługa wniosków; integracja z zarządzaniem zdarzeniami; zarządzanie zmianami; zarzadzanie wersją i zdarzeniem; zarządzanie dostępem zarządzanie komponentami oraz konfiguracją usług IT; zarządzanie wiedzą; raportowanie; podsystem wykrywania systemów informatycznych; podsystem automatycznego instalowania oprogramowania (pkt 4.1 – 4.13 specyfikacji istotnych warunków zamówienia). Odwołujący argumentuje, iż skoro wszystkie sporne wymagania postawiono w treści specyfikacji istotnych warunków zamówienia pod adresem systemu, to nieuprawnionym było dokonywanie przez Zamawiającego oceny, na podstawie zapytań i wyjaśnień z których treści wynika, że zadano je w odniesieniu do zaoferowanego oprogramowania aplikacyjnego. Odwołujący podawał na rozprawie, że każde zadane przez Zamawiający pytanie dotyczyło oprogramowania aplikacyjnego, przy czym Zamawiający w jednym z pytań położył akcent na standardowe funkcjonalności oprogramowania aplikacyjnego; że Zamawiający nigdzie nie pytał, jak przykładowo oferowany system przewiduje szyfrowanie na poziomie jednego rekordu, a zadawane pytania dotyczyły aplikacji, a nie systemu. Dostrzeżenia jednak wymaga brzmienie oferty złożonej przez Odwołującego – w formularzu Odwołujący oświadczył, iż KIO/UZP 2010/10 21 „oferowany system wspierający zarządzanie komputerami stacjonarnymi i przenośnymi, serwerami oraz wspomagającego prace Wydziału Technicznego Wsparcia Użytkowników (Help-Desk) w Ministerstwie Spraw Zagranicznych i placówkach zagranicznych składać się będzie z następującego oprogramowania aplikacyjnego (…)”. Dalej, w ujęciu tabelarycznym Odwołujący podał w dwunastu wierszach – wprost i dosłownie odpowiadających treścią opisanym wyżej trzynastu kategoriom tematycznym wymagań funkcjonalnych systemu (za wyjątkiem raportowania, które Odwołujący w tabeli pominął) odpowiadające każdej z tych kategorii oprogramowanie, wskazując jednocześnie, że jest to „wykaz oprogramowania aplikacyjnego realizującego dany proces lub funkcję (producent, nazwa, wersja)”. Tym samym należało uznać, że nie kto inny jak sam Odwołujący uznał w treści swojej oferty (formularzu ofertowym), że postawiony przez Zamawiającego katalog wymagań funkcjonalnych systemu będzie realizowany za pomocą odpowiednio dobranego do tych wymagań oprogramowania aplikacyjnego. Powyższe czyni bezzasadnym wniosek, jakoby wymagane elementy funkcjonalności systemu mogłyby być realizowane przez Odwołującego w inny sposób, aniżeli z zastosowaniem odpowiednich funkcji zaoferowanego oprogramowania aplikacyjnego, jak przykładowo innych elementów składających się na system ITSM. Trudno zresztą zgodzić się, by postawione wymagania funkcjonalne ([WF 85], [WF 152], [WF 208]), odnoszące się wyraźnie do pewnych rozwiązań programistycznych mogły być zapewnione w inny sposób, aniżeli poprzez odpowiednie ustawienia właściwie dobranego oprogramowania aplikacyjnego, przykładowo za pomocą innych elementów systemu (szkoleń, instalacji oprogramowania aplikacyjnego do środowiska Zamawiającego). Poddano zatem szczegółowej analizie zaprezentowane w wyjaśnieniach Odwołującego mechanizmy mające zapewnić realizację poszczególnych wymagań funkcjonalnych i niefunkcjonalnych systemu. I tak: W odniesieniu do wymagania funkcjonalnego [WF 85]:„ System ITSM powinien umożliwiać definiowanie okien czasowych dla jednostek konfiguracji, w których niedostępność danej jednostki konfiguracji będzie miało poważny wpływ na funkcjonowanie organizacji. W przypadku konieczności dokonania zmiany w takim okresie system powinien wymuszać dodatkowe akceptacje ze strony osób wskazanych podczas definiowania takiego okresu”, należało stwierdzić, że Odwołujący nie wykazał, by zaoferowane przez Niego oprogramowanie aplikacyjne zapewniało realizację tak opisanego wymagania. Nie sposób zgodzić się ze stanowiskiem Odwołującego, iż określenie „powinien wymuszać” nie jest równoważne z „musi wymuszać". Dostrzec trzeba jednak, że cały analizowany zapis dotyczy wymagań stawianych wobec systemu, zatem z definicji każdy zapis winien być traktowany KIO/UZP 2010/10 22 jako obligatoryjny, a nie jedynie być postrzegany w kategorii postulacyjnej, czy życzeniowej, której realizację pozostawiono swobodnemu uznaniu wykonawców. Odwołujący przyznał, że opisane przez niego rozwiązanie nie wyczerpuje postawionego wymagania. Odwołujący wskazał bowiem, iż realizacja zmiany parametrów okien czasowych przy wymaganej wysokiej dostępności dla danego elementu konfiguracji, dotyczy złożonego procesu składającego się z kilku elementów różnych procesów ITIL, a nie tylko akceptacji określonego przełożonego; sytuacja taka nie jest tak prostą, banalną czynnością jak tylko i wyłącznie akceptacja modyfikacji ww. parametru przez któregoś z przełożonych. Zmiany w konfiguracji okna czasowego dostępności usługi/elementu konfiguracji, przede wszystkim oznacza, że zmiana taka jest powiązana ze zmianą warunków świadczenia usługi (SLA) dla danej usługi i powinna być uprzednio uzgodniona zarówno z Gestorem usługi, Biznesem, a i pośrednio z Klientem. Wprowadzenie zmian w usłudze na innych zasadach według ITIL nie ma uzasadnienia biznesowego i jest nieuprawnione. Jeśli jednak istnieje rzeczywista, uzgodniona z Biznesem i Gestorem, poparta aneksami w stosownych umowach, potrzeba wprowadzenia zmiany dotyczącej warunków świadczenia (modyfikacja okien dostępności) danej usługi, to potrzeba wprowadzenia takiej zmiany powinna być zrealizowana jako odrębny, niezależny proces zarządzania zmianą. Ponieważ zmiana parametrów okna dostępności zmienia zapisy dotyczące parametrów elementów konfiguracji, to dotyczy to również procesu zarządzania konfiguracją. Powyższy proces zmiany jakichkolwiek parametrów usługi lub/i elementu(ów) konfiguracji nie jest więc tak prosty jak oczekiwania sformułowane w [WF 85]. Bez znaczenia pozostaje także argumentacja Odwołującego, iż zgodnie z ITIL, realizacja modyfikacji okien czasowych w trakcie trwania których ze względów biznesowych nie powinno wystąpić zakłócenie funkcjonowania systemu w postaci zapisanej w przedmiotowym wymaganiu, nie jest zgodna z najlepszymi praktykami zarządzania procesami opisanymi w opublikowanych przez OGC bibliotekach ITIL. Rzeczą wykonawców na tym etapie nie jest prowadzenie polemiki i wykazywanie racjonalności lub jej braku co do postawionego wymagania, lecz zastosowanie się do jego treści. Ewentualne zastrzeżenia do brzmienia specyfikacji istotnych warunków zamówienia należało podnosić w trybie oprotestowania jej brzmienia, na tym zaś etapie wykonawcy zainteresowani uzyskaniem zamówienia obowiązani są zastosować się do jej treści. W zakresie wymagania funkcjonalnego [WF 152] o treści: „System ITSM musi umożliwić wyszukiwanie pozycji wskazane jako alternatywne do wskazanej pozycji magazynowej.”, KIO/UZP 2010/10 23 Odwołujący podał, że w przesłanych do Zamawiającego wyjaśnieniach oferty, przedstawiony został prosty przykład wyszukiwania elementów konfiguracji polegający na wyszukaniu urządzeń Blackberry, przy czym z wymagania oraz pytań Zamawiającego nie wynikało jasno, jakie kryteria powinny zostać uwzględnione, aby identyfikowały pozycję magazynową alternatywnego elementu konfiguracji. Odwołujący podał, że dopiero w uzasadnieniu rozstrzygnięcia Protestu pojawił się szczegółowy opis sytuacji wydania monitora podobnego jako alternatywnego; podczas gdy określenie cech wspólnych dla alternatywnych pozycji magazynowych powinno być realizowane dzięki porównaniu określonych cech funkcjonalnych. Przedstawiony w uzasadnieniu rozstrzygnięcia Protestu przykład z wyszukaniem monitora zastępczego dla komputerów stacjonarnych pomiędzy dwoma wskazanymi typami jest niereprezentatywny dla poruszonego zagadnienia. W tym sposobie realizacji porównania, nie ma możliwości przeprowadzenia jakiejkolwiek analizy cech wspólnych wymienionych dwóch monitorów, a wyszukanie jedynie polega na prostym powiązaniu w systemie magazynowym tych dwóch pozycji. Z prostoty takiego rozwiązania wynika jego ułomność polegająca na ogromnym przybliżeniu „podobieństw” pomiędzy tymi wyrobami. W oferowanym rozwiązaniu możliwe jest natomiast wyszukanie pozycji nie tylko według określonej nazwy urządzenia, ale również wyszukanie według podobieństw innych cech funkcjonalnych. Powyższa argumentacja a także wyjaśnienia udzielone na trzykrotne wezwania Zamawiającego pozwalają na uznanie, że poprawnym był wniosek Zamawiającego, co do niespełnienia postawionego wymagania funkcjonalnego. W odniesieniu do wymagania funkcjonalnego [WF 208]: „Podczas automatycznej instalacji systemu operacyjnego powinna istnieć możliwość dołączenia do obrazu systemu dowolnego zestawu aplikacji użytkowych (instalowanych podczas pojedynczego przebiegu dystrybucji nowego komputera), dostrzeżenia wymagało w odniesieniu do stwierdzenia Zamawiającego, że Jego oferta nie spełnia tak opisanego wymogu, że Odwołujący podał, że do dnia dzisiejszego nie poznał jednoznacznej dla Zamawiającego definicji określającej pojęcie dołączenia do obrazu systemu dowolnego zestawu aplikacji użytkowych w tzw. „pojedynczym przebiegu dystrybucji nowego komputera". Mimo iż Zamawiający trzykrotnie żądał wyjaśnień w tej kwestii, to ani razu nie doprecyzował postawionego wymagania. Szczególnie istotne jest w tym przypadku określenie „dowolności dołączanego oprogramowania". W ten sposób sformułowane wymaganie nie specyfikujące nawet w ogólnym zarysie określenia „dowolne" i rodzi słuszną obawę, iż Zamawiający nie może w KIO/UZP 2010/10 24 sposób korporacyjny określić zakresu wymaganych aplikacji. Z powodu nie dookreślenia przez Zamawiającego „dowolności dodawanego oprogramowania”, powstaje uzasadniona wątpliwości związana w ogóle z możliwością zrealizowania postawionego wymagania. Dlatego też Odwołujący udzielił kilkukrotnie odpowiedzi, z której jednoznacznie wynikało, iż proces instalacji dodatkowego oprogramowania zależy od oprogramowania, jakie ma zostać zainstalowane na nowym komputerze. Odwołujący wskazał przy tym, iż opracowana metoda instalacji, uzależniona jest od zakresu pożądanych aplikacji i zostanie opracowana w trakcie wdrożenia, co stanowi realne stanowisko w tej sprawie. W odniesieniu do tak postawionego zarzutu i argumentacji go uzasadniającej, dostrzeżenia wymagało, że to na wykonawcy spoczywa ciężar wykazania spełniania postawionego warunku. Jeśli wspomniane wymaganie pozostawiało wątpliwości co do jego znaczenia wykonawca był uprawniony do zadawania pytań w tym przedmiocie. Spełnienie tego wymagania było natomiast trzykrotnie przedmiotem wezwania Zamawiającego do wyjaśnień. Powyższe mogło i powinno było dawać Odwołującemu, jeśli uznawał wezwanie do wyjaśnień za oparte na niezrozumiałych dla niego podstawach, powód do złożenia zapytania co do tego wymagania. W odniesieniu do sformułowanego wymagania niefunkcjonalnego [NF 21] o treści: „ System ITSM musi posiadać możliwość zdefiniowania tzw. dostępu warunkowego do danych. Oznacza to, że administrator systemu musi posiadać możliwość swobodnego definiowania, na podstawie dowolnych warunków logicznych zdefiniowanych na danych z rekordu, uprawnień dla użytkowników do tego rekordu m.in. czy użytkownik widzi dany rekord, które pola widzi i które pola może edytować. System ITSM musi posiadać mechanizm szyfrujący wskazane dane w bazie danych w sposób uniemożliwiający odczytanie ich wartości stosując inne narzędzia.” Odwołujący podał, że w kwestii związanej z szyfrowaniem bazy danych, podkreślić należy, że to zagadnienie związane jest z ogólnymi praktykami rozwiązań tego typu kwestii na świecie i oczekiwaną funkcjonalność trudno odnaleźć w rozwiązaniach podobnego typu, ponieważ jej charakter, czyli możliwość całkowicie selektywnego szyfrowania dowolnych pól bazy danych prowadzi do rozwiązania, w istocie niewykonalnego. Tak szczegółowa graduacja konfiguracji szyfrowania jest, w ocenie Odwołującego bardzo nieprzemyślana z logicznego i technicznego punktu widzenia. Negatywna ocena racjonalności postawionego przez Zamawiającego wymagania nie może zastępować obowiązku zastosowania się do jego brzmienia, w warunkach gdy brzmienie tego warunku nie zostało oprotestowane w swoim czasie. Stanowisko Odwołującego wskazuje jednak, że proponowane przez niego rozwiązanie KIO/UZP 2010/10 25 na ten moment nie wyczerpuje postawionego warunku. Dostrzec trzeba także, na co zwrócił także autor złożonej do akt opinii, że Odwołujący sam podał w wyjaśnieniach, że oferowany system szyfruje określonymi algorytmami całą bazę danych, co nie jest sprzeczne z postanowieniami specyfikacji istotnych warunków zamówienia. Specyfikacja jednak wyraźnie określa zakres wskazanego szyfrowania, odnosząc jednoznacznie zakres jego szczegółowości do pojedynczego rekordu, co czyni zasadnym wniosek, że Odwołujący złożonymi wyjaśnieniami nie zaprezentował Zamawiającemu spełnienia przez oferowane narzędzia postawionego wymagania. Co do wymagania niefunkcjonalnego [NF 04] o treści: „System musi być całkowicie spolonizowany łącznie z narzędziami administracyjnymi”, należało dostrzec że Odwołujący przyznał, że oferowane przez niego narzędzia nie są w pełni spolonizowane – polonizacja została przewidziana na poziomie użytkownika (klienta) nie obejmuje natomiast narzędzi administracyjnych. Odwołujący bowiem podał, że, polonizacja dotyczyć będzie interfejsów webowych użytkownika systemu wsparcia oraz zapewnił, iż możliwość polonizacji jest przewidziana na etap wdrożenia; dla użytkowników systemu zostałby dostarczony interfejs polskojęzyczny, natomiast w zakresie administracji systemu w pewnych jego częściach wymagany byłby język angielski. Zdaniem Odwołującego nie jest to cecha dyskryminująca ofertę, w wyniku polonizacji terminów anglojęzycznych na język polski mogą występować dwuznaczności związane z trudnościami w definiowaniu w języku polskim, w sposób precyzyjny, określeń czynności dokładnie zdefiniowanych w języku angielskim. Z tego powodu, powszechnie stosowaną praktyką jest używanie przez administratorów interfejsów w języku angielskim, co nie zmniejsza funkcjonalności rozwiązania, a jedynie służy właściwemu procesowi obsługi systemu. W związku z powyższym można uznać, iż sformułowanie wymagalności polonizacji w częściach administracyjnych interfejsów systemu jest sprzeczne z ustawą o języku polskim z dnia 7.10.1999 r. (Dz.U. 1999.90.999), to jest art. 11 tej ustawy. Odwołujący podał końcowo w tym zakresie, że przedmiotowe wymaganie zostało sformułowane niezgodnie z powszechnie obowiązującym w Polsce prawem. Oceniając powyższą argumentację Odwołującego, że ewentualna niezgodność specyfikacji istotnych warunków zamówienia z przepisami, jak również jej nieracjonalność mogły być podnoszone w trybie odwołania wniesionego w związku z brzmieniem specyfikacji istotnych warunków zamówienia, natomiast na tym etapie tego rodzaju zarzuty są spóźnione. Nie ulega natomiast wątpliwości, że Odwołujący nie zapewnił spełnienia opisanego wymagania. KIO/UZP 2010/10 26 W odniesieniu do sformułowanego wymagania niefunkcjonalnego nr [NF 59]: „System winien udostępniać możliwość przejmowania roli jednego operatora systemu przez drugiego, np. na czas urlopu.”. Analiza wyjaśnień złożonych przez Odwołującego, a także argumentacja zaprezentowana w odwołaniu wskazują, że zaproponowane przez Odwołującego rozwiązanie stanowi swego rodzaju „protezę” Odwołujący wykazuje, że przekazanie odpowiedzialności [NF59] - transfer odpowiedzialnego za wykonanie zadania na czas urlopu do innego analityka, nie oznacza przekazania zgłoszenia wyłącznie do osób z pierwszej linii wsparcia - operatorów. Określenie „analityk" odnosi się do wszystkich osób w proponowanym systemie, których typ dostępu jest określony jako „analityk”. W przekazanych odpowiedziach używany był przykład „ analityka ", co nie oznacza w żadnej mierze, że oferowane rozwiązanie umożliwia przekazywanie odpowiedzialności tylko operatorom Systemu ITSM. Powyższa funkcjonalność może być wykorzystywana również przez inne osoby, w tym osoby funkcyjne, zaangażowane w procesy zarządzania zmianą konfiguracją dostępnością itp. Podany został jedynie przykład ukazujący zasadę. Zdaniem Odwołującego, przedstawione rozwiązanie nie jest, jak to sugeruje Zamawiający, rozwiązaniem obejściowym, tylko standardową funkcjonalnością aplikacji. Zdaniem Odwołującego niewłaściwa ocena tej funkcjonalności wiąże się z faktem nieprecyzyjnego formułowania kolejnych zapytań, a przede wszystkim z nieprecyzyjnym określeniem wymagania. W kolejnych zapytaniach Odwołujący rozszerzał swoją odpowiedź, lecz dopiero w uzasadnieniu rozstrzygnięcia Protestu Zamawiający sformułował jakiej funkcjonalności oczekuje. Reasumując – Odwołujący wzywany trzykrotnie do wyjaśnień oferty nie wykazał Zamawiającemu spełniania opisanych warunków. W zasadniczej mierze Odwołujący nie zgadza się z poprawnością postawionych warunków, ich racjonalnością, nie kwestionując co do zasady, że w istocie postawionych warunków w sposób zakreślony przez Zamawiającego nie spełnił. Powyższy wniosek potwierdza także brzmienie złożonej do akt sprawy opinii – wskazana opinia, stanowiąca dokument prywatny zawiera zestaw ocen i wniosków wyartykułowanych w odniesieniu do specyfikacji, postawionych w niej wymagań funkcjonalnych i niefunkcjonalnych, w tym spornych na gruncie niniejszego postępowania. Opinia także nie zaprzecza, że w ofercie Odwołującego (wyjaśnieniach do tej oferty) zaprezentowano ścieżkę wykonania postawionych wymagań w sposób inny, aniżeli wymaga tego Zamawiający albo pozostający niejako „obok” tych wymagań (jak np. w odniesieniu do obowiązku polonizacji łącznie z narzędziami administracyjnymi). Dostrzec trzeba, że w zakresie, w jakim wskazana opinia stanowi polemikę lub ocenę racjonalności wymagań KIO/UZP 2010/10 27 Zamawiającego, nie sposób przypisywać jej waloru dowodowego oraz znaczenia procesowego – wobec upływu terminu na kwestionowanie treści specyfikacji istotnych warunków zamówienia, nie sposób na tym etapie dokonywać tego rodzaju wniosków. Konkluzje i ich uzasadnienie zawarte w tej opinii także przekonują – w odniesieniu do wymagania niefunkcjonalnego [NF 04] dotyczącego polonizacji systemu, że wymaganie nie zostało spełnione. Podobny wniosek należy wysnuć w odniesieniu do wymagania niefunkcjonalnego [NF 21] – opinia potwierdza słuszność wniosku, iż zaprezentowane Zamawiającemu rozwiązanie w zakresie wymagania szyfrowania dowolnie zdefiniowanego rekordu nie spełnia tego warunku. Opinia ta wskazuje bowiem, że szyfrowanie wybranych pól/rekordów może być zrealizowane na etapie wdrożenia przez role, tabele dostępu lub szyfrowanie pól typu duży obiekt binarny, a także że na podstawie wyjaśnień Odwołującego z dnia 23 lipca 2010r. system szyfruje określonymi algorytmami całą bazę danych. Tym samym należało uznać, że przedmiotowa opinia, w zakresie w jakim należało jej przyznać walor poznawczy i przydatność do wykazania okoliczności mających znaczenie dla rozstrzygnięcia sprawy nie prowadzi do wniosków odmiennych aniżeli wynikające z niniejszego orzeczenia. Z powyższych względów nie potwierdziły się także zarzuty naruszenia przez Zamawiającego przepisu art. 7 ust. 1 i 3 ustawy Prawo zamówień publicznych, podniesione w odwołaniu jako reasumpcja wcześniej przeanalizowanych zarzutów. O kosztach postępowania odwoławczego orzeczono na podstawie art. 191 ust. 6 i 7 ustawy Prawo zamówień publicznych, czyli stosownie do wyniku postępowania. Stosownie do art. 194 i 195 ustawy z dnia 29 stycznia 2004 r. - Prawo zamówień publicznych (Dz. U. z 2007 r. Nr 223, poz. 1655 ze zm.) na niniejszy wyrok – w terminie 7 dni od dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Urzędu Zamówień Publicznych do Sądu Okręgowego w Warszawie. Przewodniczący: Członkowie: ……………………………… ………………………………