Pełny tekst orzeczenia

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:

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

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