Sygn. akt: KIO 163/16
Sygn. akt: KIO 170/16
WYROK
z dnia 2 marca 2016 r.
Krajowa Izba Odwoławcza - w składzie:
Przewodniczący: Ewa Kisiel
Protokolant: Łukasz Listkiewicz
po rozpoznaniu na rozprawie w dniach 23 i 26 lutego 2016 r. odwołań wniesionych do
Prezesa Krajowej Izby Odwoławczej:
A. w dniu 8 lutego 2016 r. przez wykonawcę Sputnik Software Sp. z o.o., ul. Górecka
30, 60-201 Poznań (Sygn. akt KIO 163/16),
B. w dniu 8 lutego 2016 r. przez wykonawcę Comarch Polska S.A., al. Jana Pawła II
39a, 31-864 Kraków (Sygn. akt KIO 170/16),
w postępowaniu prowadzonym przez Miasto Łódź – Urząd Miasta Łodzi, ul. Piotrkowska
104, 90-926 Łódź;
przy udziale:
A. wykonawcy COIG S.A., ul. Mikołowska 100, 40-065 Katowice, zgłaszającego swoje
przystąpienie do postępowania odwoławczego o sygn. akt: KIO 163/16 po stronie
odwołującego;
B. wykonawcy Qumak S.A., al. Jerozolimskie 134, 02-305 Warszawa, zgłaszającego
swoje przystąpienie do postępowania odwoławczego o sygn. akt: KIO 163/16 po
stronie odwołującego;
C. wykonawcy "S&T Services" Polska Sp. z o.o., ul. Postępu 21d, 02-676 Warszawa,
zgłaszającego swoje przystąpienie do postępowania odwoławczego o sygn. akt: KIO
170/16 po stronie odwołującego;
D. wykonawcy Sputnik Software Sp. z o.o., ul. Górecka 30, 60-201 Poznań,
zgłaszającego swoje przystąpienie do postępowania odwoławczego o sygn. akt: KIO
170/16 po stronie odwołującego;
E. wykonawcy Comarch Polska S.A., al. Jana Pawła II 39a, 31-864 Kraków,
zgłaszającego swoje przystąpienie do postępowania odwoławczego o sygn. akt: KIO
163/16 po stronie zamawiającego
orzeka:
1. uwzględnia oba odwołania (sygn. akt KIO 163/16 i KIO 170/16) i nakazuje Miastu
Łódź – Urzędowi Miasta Łodzi, ul. Piotrkowska 104, 90-926 Łódź dokonanie
zmiany specyfikacji istotnych warunków zamówienia (SIWZ):
- na str. 7 Załącznika nr 1 SIWZ - Opis Przedmiotu Zamówienia, po słowie
„Uwaga!”, doprecyzowanie informacji w odniesieniu do rodzajów szablonów
raportów;
- w pkt. 568 na str. 99 Załącznika nr 1 SIWZ - Opis Przedmiotu Zamówienia,
uszczegółowienie informacji, przez podanie wszystkich niezbędnych danych do
prawidłowego wykonania procesu integracji;
- wykreślenie pkt. 37 lit b) ii. Załącznika nr 3 - Opisu przedmiotu zamówienia,
dotyczącego tego, że wykonawca powinien dokonywać prezentacji zgodnie z
kolejnością opisanych w SIWZ scenariuszy testowych;
- w pkt 1.1 lit. i) na str. 3 Załącznika nr 1 SIWZ - Opis Przedmiotu Zamówienia –
zastąpienie
słowa
„oprogramowania”
określeniem
„Oprogramowania
Aplikacyjnego”;
- pkt. 30 Załącznika nr 3 do Opisu przedmiotu zamówienia przez wydłużenie
długości łącznego czasu prezentacji z 6 godzin zegarowych do co najmniej 7
godzin zegarowych;
- w pkt. 37 na str. 41 Załącznika nr 1 SIWZ - Opis Przedmiotu Zamówienia –
usunięcie skrótu „np.” i określenie katalogu wymaganych przez Zamawiającego
formatów;
- w pkt. 2 na str. 1 Załącznika nr 1 SIWZ - Opis Przedmiotu Zamówienia podanie
dokładnych lokalizacji wykonywania zamówienia, z wyszczególnieniem
wszystkich jednostek, w których będzie realizowane zamówienie;
- w pkt. 6.6.3 na str. 133 Załącznika nr 1 SIWZ - Opis Przedmiotu Zamówienia
określenie liczby administratorów, w odniesieniu do których wykonawca ma
obowiązek zapewnienia szkoleń;
- w tabeli Załącznika nr 5 do Opisu przedmiotu zamówienia – Zakres do migracji
i systemy źródłowe w miejskich jednostkach organizacyjnych Zamawiającego,
w kolumnie „Nazwa i producent aktualnie eksploatowanego systemu.
Technologia” uzupełnienie danych, dotyczących producenta oraz technologii,
w odniesieniu do wskazanych przez Zamawiającego w tabeli, systemów dla
poszczególnych jednostek;
- w pkt 13.8 SIWZ doprecyzowanie definicji, służących indywidualnej ocenie
prezentacji, w ramach poszczególnych wymagań, w kryterium „Jakość”.
2. W pozostałym zakresie oddala oba odwołania.
3. Kosztami postępowania obciąża Miasto Łódź – Urząd Miasta Łodzi, ul. Piotrkowska
104, 90-926 Łódź i:
3.1. zalicza w poczet kosztów postępowania odwoławczego kwotę 30 000 zł 00 gr
(słownie: trzydzieści tysięcy złotych zero groszy) uiszczoną przez wykonawców:
Sputnik Software Sp. z o.o., ul. Górecka 30, 60-201 Poznań i Comarch Polska
S.A., al. Jana Pawła II 39a, 31-864 Kraków, w kwotach równych po 15 000 zł 00 gr
(słownie: piętnaście tysięcy złotych zero groszy) każdy z wykonawców, tytułem
wpisów od odwołań,
3.2. zasądza od Miasta Łódź – Urząd Miasta Łodzi, ul. Piotrkowska 104, 90-926 Łódź
kwotę 37 335 zł 00 gr (słownie: trzydzieści siedem tysięcy trzysta trzydzieści pięć
złotych zero groszy), w tym:
A. kwotę 18 735 zł 00 gr (słownie: osiemnaście tysięcy siedemset trzydzieści pięć
złotych zero groszy) na rzecz wykonawcy Sputnik Software Sp. z o.o., ul.
Górecka 30, 60-201 Poznań, stanowiącą koszty postępowania odwoławczego
poniesione z tytułu wpisu od odwołania, wynagrodzenia pełnomocnika oraz
dojazdu,
B. kwotę 18 600 zł gr (słownie: osiemnaście tysięcy sześćset złotych zero groszy) na
rzecz wykonawcy Comarch Polska S.A., al. Jana Pawła II 39a, 31-864 Kraków,
stanowiącą koszty postępowania odwoławczego poniesione z tytułu wpisu od
odwołania oraz wynagrodzenia pełnomocnika.
Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. - Prawo zamówień
publicznych (t.j. Dz. U. z 2015 r., poz. 2164) na niniejszy wyrok - w terminie 7 dni od dnia
jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej
do Sądu Okręgowego w Łodzi.
Przewodniczący: ……………………………
Sygn. akt: KIO 163/16
Sygn. akt: KIO 170/16
UZASADNIENIE
Miasto Łódź – Urząd Miasta Łodzi, ul. Piotrkowska 104, 90-926 Łódź (dalej:
„Zamawiający”) na podstawie przepisów ustawy z dnia 29 stycznia 2004 r. Prawo zamówień
publicznych (Dz. U. z 2013 r., poz. 907 ze zm.) – zwanej dalej "ustawą" lub "Pzp" – prowadzi
postępowanie o udzielenie zamówienia na „Dostawę i wdrożenie systemu informatycznego
wspomagającego zarządzanie finansami Miasta”.
Szacunkowa wartość przedmiotowego zamówienia jest wyższa od kwot wskazanych
w przepisach wykonawczych wydanych na podstawie art. 11 ust. 8 Pzp.
29 stycznia 2016 r. Zamawiający opublikował ogłoszenie o zamówieniu w Dzienniku
Urzędowym Unii Europejskiej pod nr 2016/S 020-31131. Specyfikacja istotnych warunków
zamówienia (dalej: „siwz” lub „specyfikacja”) została opublikowana również w dniu 29
stycznia 2016 r.
KIO 163/16
W dniu 8 lutego 2016 r. wykonawca Sputnik Software Sp. z o.o., ul. Górecka 30, 60-
201 Poznań (dalej: „Odwołujący” lub „Sputnik”) wniósł do Prezesa Krajowej Izby
Odwoławczej odwołanie, wobec następujących czynności Zamawiającego, polegających na:
1. opisaniu przedmiotu zamówienia przez wskazanie znaków towarowych w sposób
nieuzasadniony specyfiką przedmiotu zamówienia, a tym samym utrudniający
uczciwą konkurencję;
2. opisaniu przedmiotu zamówienia w sposób utrudniający uczciwą konkurencję, przez
wymaganie, aby oferowane rozwiązanie było oparte o rozwiązanie, funkcjonujące na
rynku od co najmniej 10 lat oraz było dostępne w wersji COTS;
3. określeniu warunków udziału w postępowaniu w sposób nieproporcjonalny do
przedmiotu zamówienia i naruszający zasadę uczciwej konkurencji;
4. określenie kryteriów oceny ofert w kryterium „Jakość” oraz „Stopień gotowości
Systemu” do wdrożenia w sposób niezapewniający obiektywizmu i naruszający
zasadę uczciwej konkurencji;
5. opisaniu przedmiotu zamówienia w sposób niewyczerpujący, nieuwzględniający
wszystkich wymagań mających wpływ na sporządzenie oferty.
Sputnik zarzucał Zamawiającemu naruszenie następujących przepisów Pzp:
1. art. 29 ust. 2 i 3 ustawy, przez opisanie przedmiotu zamówienia z
wykorzystaniem takich znaków towarowych jak MS SQL Server 2014 i
Simpana, a tym samym ograniczenie konkurencji;
2. art. 29 ust. 2 ustawy, przez nieuzasadnione wymaganie, aby oferowane
rozwiązanie było oparte o rozwiązanie funkcjonujące na rynku od co
najmniej 10 lat oraz było dostępne w wersji COTS;
3. art. 7 ust. 1 w związku z art. 22 ust. 4 ustawy, przez sformułowanie
warunków udziału w postępowaniu, które uniemożliwiają złożenie ofert
wykonawcom zdolnym do wykonania przedmiotu zamówienia, oferującym
rozwiązania oparte o technologie typu Open Source;
4. art. 7 ust. 2 w związku z art. 91 ust. 1 i 2 ustawy, przez sformułowanie
kryteriów oceny ofert w sposób niezapewniający obiektywizmu podczas
oceny ofert w kryterium „Jakość”;
5. art. 7 ust. 1 w związku z art. 91 ust. 1 i 2 ustawy, przez sformułowanie
kryteriów oceny ofert w sposób utrudniający uczciwą konkurencję w zakresie
scenariuszy testowych w obszarze podatki i opłaty lokalne;
6. art. 29 ust. 1 ustawy, przez zaniechanie precyzyjnego i wyczerpującego
określenia wymagań, dotyczących obowiązku wykonawcy do opracowania,
w ramach wykonania przedmiotu zamówienia 250 szablonów raportów w
Systemie zgodnie z wzorami uzgodnionymi w ramach Projektu Rozwiązania;
7. art. 29 ust. 1 ustawy, przez zaniechanie precyzyjnego i wyczerpującego
określenia wymagań, dotyczących przedmiotu zamówienia w zakresie
integracji z istniejącymi u Zamawiającego systemami informatycznymi.
W związku z powyższym Odwołujący żądał nakazania Zamawiającemu:
wykreślenia z siwz możliwości udostępnienia przez Zamawiającego rozwiązań MS
SQL Server 2014,
wykreślenia z siwz obowiązku dostarczenia licencji SIMPANA i zastąpienia go
obowiązkiem dostawy rozwiązania zapewniającego odpowiednią, wymaganą przez
Zamawiającego funkcjonalność,
3. wykreślenia wymagania, aby oferowane rozwiązanie oparte było o rozwiązania,
funkcjonujące na rynku od co najmniej 10 lat,
4. wykreślenia wymagania, aby oferowane rozwiązanie oparte było o rozwiązania dostępne
w wersji COTS,
5. modyfikacji warunku udziału w postępowaniu określonego w rozdz. 5 ust. 5.1. pkt 5.1.2.
ppkt 5.1.2.1. siwz, przez jego następującą zmianę: należycie wykonał lub wykonuje w
jednostce sektora finansów publicznych w rozumieniu ustawy - ustawa z dnia 27 sierpnia
2009 r. o finansach publicznych (Dz.U. z 2013 r., poz. 885, z późn.zm.) zamówienie
polegające na dostawie systemu informatycznego (o wartości nie mniejszej niż 2 500 000,00
PLN brutto, podana wartość dostawy systemu i jego wdrożenia nie obejmuje dostawy
sprzętu i wartości licencji baz danych i systemów operacyjnych) i jego wdrożeniu również w
jednostkach podległych Zamawiającemu, obejmujące swoim zakresem obszary analogiczne
do obszaru budżetowo-księgowego oraz podatkowego w rozumieniu siwz,
6. wykreślenia kryterium „Jakość”, jako nieistotnego z punktu widzenia oceny oferty i
niezapewniającego obiektywizmu, oraz przeniesienie odpowiednich elementów do wymagań
odnośnie prac projektowych po podpisaniu umowy lub alternatywnie nakazanie
Zamawiającemu doprecyzowania kryterium oceny oferty „Jakość” w taki sposób, aby
wykonawca składający ofertę mógł w sposób jednoznaczny ocenić, jaką ocenę jest w stanie
uzyskać, w odniesieniu do posiadane obecnie rozwiązania,
7. wykreślenia z załącznika nr 4 do siwz, scenariuszy testowych w odniesieniu do obszaru
opłat i podatków;
8. doprecyzowania wymagań w zakresie obowiązku wykonawcy do opracowania w ramach
wykonania przedmiotu zamówienia 250 szablonów raportów w Systemie lub alternatywnie do
wykreślenia rzeczonych wymagań z siwz,
9. doprecyzowania wymagań, w zakresie integracji z istniejącymi u Zamawiającego
systemami informatycznymi, szczegółowe opisanie wszystkich WebSerwisów i/lub plików
wymiany wraz z opisem i wskazaniem danych wejściowych oraz danych wyjściowych.
W uzasadnieniu odwołania Odwołujący wyjaśniał:
I.
Zgodnie z rozdz. 1 pkt 1.1. lit. c) Załącznika nr 1 do specyfikacji, Zamawiający
wymaga, aby oferowane rozwiązanie umożliwiało eksploatację na platformie bazy danych
MS SQL Server 2014, którą Zamawiający zamierza przeznaczyć do realizacji zamówienia. W
przypadku, gdy oferowane przez wykonawcę rozwiązanie będzie funkcjonowało na bazie
danych innej niż ta, którą Zamawiający zamierza przeznaczyć do realizacji niniejszego
zamówienia, wykonawca zobowiązany jest zapewnić licencje bazy danych, na
nieograniczoną liczbę użytkowników, niezbędne do pełnego wdrożenia oferowanego
systemu, zgodnie z wymaganiami niniejszego dokumentu.
Jednocześnie, zgodnie z rozdz. 2 pkt 2.2. Zamawiający wskazał, jaką infrastrukturę
zamierza przeznaczyć do realizacji przedmiotowego zamówienia. Zgodnie z lit. c) ma to być
m.in. licencja MS SQL Server 2014 w wersji Enterprise na 2 serwery.
Powyższe, w ocenie Odwołującego, w znaczący sposób ogranicza konkurencję w
przedmiotowym postępowaniu, przez preferowanie rozwiązań opartych o konkretne,
wskazane środowisko bazodanowe. W szczególności wykonawcy oferujący rozwiązania
oparte o środowisko MS SQL Server 2014, takie jak np. Microsoft Dynamics AX, mogą
zaoferować wykonanie przedmiotu zamówienia po znacznie niższej cenie niż konkurencja,
której rozwiązania oparte zostały na odmiennej technologii. Oznacza to, iż Zamawiający w
sposób być może nieświadomy, ogranicza możliwość zastosowania rozwiązań
alternatywnych, które nawet pomimo np. swojej innowacyjności czy otwartości, pozwoliłyby
na zapewnienie dłuższego cyklu życia produktu, jakim jest zamawiany system. Podnosił, iż
na rynku istnieją konkurencyjne, zapewniające tożsamą funkcjonalność rozwiązania
bazodanowe takich producentów jak Oracle, czy IBM. Co jeszcze istotniejsze, istnieją
również rozwiązania typu Open Source, które jako tzw. wolne oprogramowanie nie
wymuszają na zamawiających ponoszenia istotnie większych kosztów utrzymania baz
danych, przy jednoczesnym zapewnieniu możliwości ciągłego rozwoju oprogramowania
przez profesjonalne podmioty informatyczne.
Sputnik podkreślał, że w żadnej części siwz Zamawiający nie wskazał, z jakiego
powodu takie środowisko jest przez niego preferowane, nie wspominając już o tym, że nie
wyjaśnia, w jakim celu nabył takie licencje wcześniej, a w przedmiotowym postępowaniu
chce je udostępnić potencjalnemu wykonawcy. Zauważyć również trzeba, iż specyfika
przedmiotu zamówienia nie wymusza na Zamawiającym takiego działania. Powszechną
praktyką na rynku informatycznym jest wymaganie przez Zamawiających, aby dostarczyli
kompletne rozwiązanie informatyczne, składające się nie tylko z oprogramowania
aplikacyjnego, ale również wszelkiego oprogramowania niezbędnego do prawidłowej pracy
oprogramowana aplikacyjnego, w tym m.in. odpowiednich baz danych.
Jednocześnie, zgodnie z rozdz. 1 pkt 1.1. lit. d) Załącznika nr 1 do siwz (Zamówienie
obejmuje - str. 4) Zamawiający wskazał, iż przedmiot zamówienia obejmuje m.in.
dostarczenie licencji Simpana10 SB-C-DPA-5T-A na 6TB (licencja obejmująca prawo do
wykonywania kopii baza danych i serwerów aplikacyjnych), instalację, konfigurację i
uruchomienie oprogramowania klienckiego dla serwerów aplikacyjnych i bazodanowych
zapewniających możliwość tworzenia kopii zapasowych z wykorzystaniem posiadanego
przez Zamawiającego serwera kopii zapasowych Simpana CommVault.
Odwołujący wyjaśniał, że mając na uwadze, iż na rynku istnieją alternatywne
rozwiązania takie jak EMC Networker, Veritas NetBackup, IBM TSM, czy też Storage Craft,
to Zamawiający jednoznacznie ograniczył konkurencję w przedmiotowym postępowaniu.
Uwzględniając fakt, iż Zamawiający dysponuje serwerem kopii zapasowych
SimpanaCommVault, nie można bowiem przyjąć, iż niedopuszczenie rozwiązań
konkurencyjnych jest uzasadnione, gdyż jak to sam wskazał dysponuje on jedynie serwerem
kopii zapasowych SimpanaCommVault, bez wymaganych licencji do wykonywania kopii
zapasowych z serwerów Systemu. Tym samym posiadane przez Zamawiającego
rozwiązanie nie zapewnia wymaganej w przedmiotowym postępowaniu funkcjonalności, a
nie sposób arbitralnie uznać, iż rozwiązania konkurencyjne byłyby dla Zamawiającego
nieuzasadnione ekonomicznie, natomiast określone przez Zamawiającego wymagania
wskazują na przyjęcie takiego założenia przez Zamawiającego.
Odwołujący twierdził, że Zamawiający w sposób nieuzasadniony ograniczył
konkurencję poprzez wskazanie konkretnych rozwiązań informatycznych, wskazując na
preferowane.
II.
Sputnik wskazywał, że zgodnie z rozdz. 1 pkt 1.1. lit. k) Załącznika nr 1 do siwz,
Zamawiający wymagał, aby oferowane rozwiązanie było zbudowane w oparciu o
standardowe rozwiązanie klasy ERP dostępne na rynku w wersji COTS (commercial off-the-
shelf) przynajmniej od 10 lat, a w oferowanej wersji co najmniej rok.
W pierwszej kolejności zauważał, iż pojęcie użyte w przywołanym postanowieniu
siwz, tj. standardowe rozwiązanie klasy ERP jest definiowane poprzez listę ppkt, w którym
jest użyte (lit. od a) do m) w pkt 1.1. Powoduje to swoistego rodzaju problem logiczny
utrudniający jednoznaczną interpretację tego pojęcia. Przyjmując jednakże, iż wymagania te
należy interpretował łącznie uznać należy, iż Zamawiający wymaga aby dostarczone
rozwiązanie opierało się o rozwiązanie ERP dostępne na rynku w wersji COTS przynajmniej
10 lat, a w oferowanej wersji co najmniej rok, spełniające jednocześnie pozostałe wymagania
określone w lit. a)-j) oraz lit. l)-m).
Zdaniem Odwołującego tak sformułowane wymaganie w sposób jedynie pozorny
dopuszcza zastosowanie różnych rozwiązań. Jeśli bowiem uwzględnić wszystkie wymagania
określone w przywołanym pkt 1.1, a w szczególności lit. a), c), d) zgodnie z wiedzą
Odwołującego praktycznie jedynym rozwiązaniem spełniającym wymagania Zamawiającego
będzie rozwiązanie ERP pod nazwą Microsoft Dynamics AX. Bez względu jednakże na
powyższe, w ocenie Odwołującego wymaganie, aby rozwiązanie ERP na którym ma opierać
się rozwiązanie oferowane w przedmiotowym postępowaniu Zamawiającemu dostępne było
w wersji COTS przynajmniej od 10 lat w sposób zupełnie nieuzasadniony ogranicza
konkurencję, przez uniemożliwienie zastosowania nowoczesnych i innowacyjnych
rozwiązań, które funkcjonują na rynku w krótszym okresie, np. 3-4 lat. Również samo
wymaganie wersji COTS nie jest uzasadnione specyfiką przedmiotu zamówienia. Podkreślić
należy, iż sam Zamawiający poprzez wiele zapisów siwz, zapewnia sobie pełne prawo do
kupowanego rozwiązania, np. rozdz. 1 pkt 1.1. lit. i), rozdz. 1 pkt 1.1. lit. I), u), w) i y)
(Zamówienie obejmuje - str. 5), § 13-15 załącznika nr 7 do siwz. Tym samym zdaniem
Sputnika w zakresie prawie dopuszczalnym będzie mógł przeprowadzić postępowanie na
utrzymanie czy wręcz rozbudowę powstałego systemu, udostępniając wybranemu nowemu
wykonawcy odpowiednie kody źródłowe i informacje niezbędne do jego wykonania.
Podkreślał, że każdy z podmiotów profesjonalnie działających na rynku informatycznym na
podstawie danych w posiadaniu, których będzie Zamawiający, powinien być w stanie
wykonać tego typu zamówienie.
Odwołujący twierdził, że wymaganie, aby oferowane rozwiązanie funkcjonowało na
rynku co najmniej 10 lat, jak również aby rozwiązanie to było dostępne w wersji COTS jest
całkowicie bezzasadne, a w sposób znaczący ogranicza, jeśli wręcz nie eliminuje całkowicie
konkurencji.
III.
Następnie Odwołujący wskazywał, że zgodnie z rozdz. 5 ust. 5.1. pkt 5.1.2. ppkt
5.1.2.1. specyfikacji Zamawiający wymaga, aby wykonawca ubiegający się o udzielenie
przedmiotowego zamówienia należycie wykonał lub wykonuje w jednostce sektora finansów
publicznych w rozumieniu ustawy - ustawa z dnia 27 sierpnia 2009 r. o finansach
publicznych (Dz.U. z 2013 r., poz. 885, z późn.zm.) zamówienie polegające na dostawie
systemu informatycznego (o wartości nie mniejszej niż 10 000
000,00 PLN brutto, podana
wartość dostawy systemu i jego wdrożenia nie obejmuje dostawy sprzętu) i jego wdrożeniu
również w jednostkach podległych Zamawiającemu, obejmujące swoim zakresem obszar
finansowo-księgowy.
W ocenie Odwołującego, tak sformułowany warunek w sposób nieuzasadniony
ogranicza konkurencję, przez preferowanie wykonawców, którzy posiadają doświadczenie
jedynie w części, odpowiadającej przedmiotowi zamówienia i to wręcz w znikomym stopniu,
a jednocześnie oferują rozwiązania oparte o rozwiązania, charakteryzujące się wysokimi
kosztami licencji podmiotów trzecich. Jak wynika bowiem z treści przywołanego warunku,
Zamawiający wymaga, aby zamówienie, które przedstawi wykonawca obejmowało obszar
finansowo-księgowy. Oznacza to, iż Zamawiający dopuszcza, aby przedstawione
zamówienie obejmowało również inne niż wskazane obszary. Tym samym możliwe jest
przedstawienie zamówienia, które spełniając pozostałe wymagania zawarte w warunku,
obejmowało przykładowo w 99% system obiegu dokumentów, czy np. system klasy GIS, a
jedynie w 1% dotyczyło obszaru finansowo- księgowego. Zauważyć również trzeba, iż
pojęcie obszaru finansowo-księgowego nie zostało nigdzie zdefiniowane, co w konsekwencji
może oznaczać, iż przedstawiane zamówienie w ogóle może nie obejmować kluczowego
obszaru, jaki wynika z OPZ w przedmiotowym postępowaniu, tj. podatków i opłat lokalnych.
Jednocześnie Sputnik zwracał uwagę na bardzo wysoką wartość, jaką musi posiadać
przedstawione zamówienie. Jest to o tyle zadziwiające, iż jak sam wskazał to Zamawiający
do wartości tej nie może być zaliczona wartość dostawy sprzętu. Nie zostały natomiast
wyłączone takie elementy systemu jak: wartość licencji baz danych, czy też oprogramowania
systemowego. Oznacza to, iż w przypadku rozwiązań opartych o bazy danych, takich
producentów jak Microsoft, IBM, Oracle, wartość samych licencji, dostarczanych baz danych
może stanowić dominującą część całej wartości dostawy systemu informatycznego.
Przykładowo, przy wartości całości dostawy na poziomie 10 mln zł, przy wyłączeniu wartości
sprzętu, wartość licencji MS SQL Server lub podobnych może wynosić 6-7 mln zł, a wartość
pozostałych elementów systemu, wraz z wdrożeniami i szkoleniami 3-4 mln zł. Oznacza to, iż
poprzez tak sformułowany warunek udziału w postępowaniu Zamawiający uniemożliwia
udział w postępowaniu wykonawców, których rozwiązania wykorzystują rozwiązania typu
Open Source, które przez wiele instytucji, w tym np. Prezesa Urzędu Zamówień Publicznych
są zalecane do stosowania w administracji publicznej.
Na marginesie należy w tym miejscu wspomnieć, iż łącząc przedmiotowy warunek
udziału w postępowaniu, z wymaganiami, dotyczącymi przedmiotu zamówienia przywołanymi
wcześniej, na podstawie których można wywnioskować jako preferujących technologię firmy
Microsoft nasuwa się przypuszczenie, że poprzez nieświadomy zbieg wszystkich wymagań
przedmiotowe zamówienie będzie mógł wykonać jedynie wykonawca posiadający
rozwiązania typu Microsoft Dynamics AX.
IV.
Sputnik wyjaśniał, że zgodnie z rozdz. 13 ust. 13.8 siwz, Zamawiający wskazał, iż w
odniesieniu do kryterium "Jakość" ocena ofert dokonana zostanie przez członków
merytorycznych komisji przetargowej, na podstawie indywidualnej karty oceny prezentacji.
Jednakże w żadnej części siwz, Zamawiający nie wskazał sposobu przyznawania
odpowiedniej ilości punktów w odniesieniu do danego wymagania. Tak więc bezsprzecznie
uznać należy, iż Zamawiający przyjął, iż ocena będzie polegała na subiektywnej ocenie ofert
przez poszczególnych członków merytorycznych komisji przetargowej.
W ocenie Odwołującego, taki sposób oceny ofert stanowi bezpośrednie naruszenie
zasady uczciwej konkurencji. Może bowiem prowadzić do sytuacji, w której przykładowo, w
odniesieniu do wymagania „wygląd aplikacji”, możliwa będzie sytuacja, w której dla tak samo
skonstruowanej aplikacji pod względem czytelności, przejrzystości i układu pól na ekranie i
niebieskiej szacie graficznej, jeden z ekspertów przyzna 1 pkt, a drugi pkt. 4, gdzie pierwszy
uzna, iż kolor niebieski jest nieestetyczny i mało atrakcyjny, a drugi z ekspertów uzna ten
właśnie kolor za najbardziej odpowiedni do oferowanej aplikacji. Zauważyć w tym miejscu
należy, iż większość z elementów wskazanych jako wymagania, czy też elementy
podlegające ocenie może być w krótkim czasie lub wręcz zmieniona „od ręki” na etapie
wdrożenia systemu po uzyskaniu informacji zwrotnych od użytkowników końcowych.
Podkreślić również trzeba, iż Zamawiający przewidział w przedmiotowym postępowaniu etap
projektowania systemu. W ramach tego etapu wszystkie elementy wskazane w kryterium
jakość, mogą zostać ustalone i dostosowane do indywidualnych potrzeb użytkowników.
Możliwa jest wręcz sytuacja, w której w dwóch różnych jednostkach podległych
Zamawiającemu szata graficzna w zakresie np. przyjętej kolorystyki będzie odmienna.
V.
Następnie Odwołujący wskazywał, że zgodnie z załącznikiem nr 4 do siwz, w odniesieniu
do obszaru opłat i podatków Zamawiający przewiduje następujące scenariusze:
Scenariusz nr 1 - Obsługa wpłat masowych i windykacja zaległości
Scenariusz nr 2 - Obsługa wpłaty zobowiązanego na należność objętą tytułem
wykonawczym
Scenariusz nr 3 - Określenie przypisu podatku na podstawie korekty deklaracji
podatkowej
Scenariusz nr 4 - Ustalenie podatku od nieruchomości w wyniku prowadzenia
postępowania podatkowego (decyzje ustalające, zmieniające lub uchylające)
Scenariusz nr 5 - Egzekucja Należności Pieniężnych
Scenariusz nr 6 - Windykacja Należności Cywilnoprawnych
Sputnik wyjaśniał, że jednocześnie Zamawiający wymaga, aby dostarczone
oprogramowanie było dostępne w wersji COTS w okresie co najmniej ostatnich 10 lat oraz
aby umożliwiało eksploatację na platformie bazy danych MS SQL Server 2014.
Równocześnie, w zakresie warunków udziału w postępowaniu Zamawiający wymaga, aby
wykonawca który będzie ubiegał się o udzielenie zamówienia należycie wykonał lub
wykonuje w jednostce sektora finansów publicznych w rozumieniu ustawy - ustawa z dnia 27
sierpnia 2009 r. o finansach publicznych (Dz.U. z 2013 r., poz. 885, z późn.zm.) zamówienie
polegające na dostawie systemu informatycznego (o wartości nie mniejszej niż 10 000
000,00 PLN brutto, podana wartość dostawy systemu i jego wdrożenia nie obejmuje dostawy
sprzętu) i jego wdrożeniu również w jednostkach podległych Zamawiającemu, obejmujące
swoim zakresem obszar finansowo-księgowy.
Zdaniem Odwołującego połączenie powyższych warunków, z tak sformułowanymi
scenariuszami testowymi wskazuje, iż jedynym rozwiązaniem, które będzie w stanie uzyskać
maksymalną ilość punktów za scenariusze testowe, przy jednoczesnym spełnieniu
wszystkich pozostałych przywołanych warunków wynikających z siwz będzie rozwiązanie
Microsoft Dynamics AX wdrożone na rynku polskim przez firmę Asseco Poland S.A. /Otago
Sp. z o.o.
Odwołujący podnosił, że zgodnie z rozdz. 1 pkt 1.1. lit. a) i b) Załącznika nr 1 do siwz
(Zamówienie obejmuje - str. 4) Zamawiający wskazał, iż przedmiot zamówienia obejmuje
m.in.:
a)
Wykonanie Projektu Rozwiązania.
b)
Dostawę, Instalację Systemu i Konfigurację Oprogramowania, Oprogramowania
Aplikacyjnego.
Wykonawca
dostarczy
szczegółowe
zestawienie
dostarczonego
Oprogramowania, które zostanie zawarte w Dokumentacji powykonawczej
Natomiast z definicji zawartych w załączniku nr 1 do siwz jego zdaniem wynika, że:
a)
Projekt Rozwiązania oznacza dokument, zawierający wyniki prac związanych z
analizą wymagań funkcjonalnych, sposobem implementacji Rozwiązania w środowisku
Zamawiającego, Migracji danych i integracji Systemu, a także przygotowaniem
szczegółowego Harmonogramu prac z uwzględnieniem procesu Migracji danych.
b)
Oprogramowanie Aplikacyjne oznacza, wykonane przez Wykonawcę rozbudowy
(przykładowo nowe moduły, warstwy, funkcjonalności) standardowego rozwiązania klasy
ERP, mające na celu dostosowanie standardowego rozwiązania klasy ERP do wymogów
Zamawiającego wraz z interfejsami wymiany danych (m.in. WebService), wspierające
realizację zadań wynikających z przedmiotu zamówienia.
Wobec tego zdaniem Sputnika, powyższe w sposób jednoznaczny wskazuje, iż
Zamawiający dopuszcza, aby wymagane przez Zamawiającego funkcjonalności, w tym te w
zakresie podatków i opłat lokalnych zostały zaprojektowane i wykonane przez wykonawcę w
ramach nowych modułów czy też warstw. Mając to na uwadze, Odwołujący uznał, iż
wprowadzenie kryteriów oceny ofert, które preferują jednego wykonawcę na polskim rynku
przy jednoczesnym braku obiektywnych przesłanek do zapewnienia, wynikających ze
scenariuszy testowych funkcjonalności w zakresie podatków i opłat lokalnych, w sposób
bezsprzeczny narusza zasadę uczciwej konkurencji.
VI.
Odwołujący podnosił, że zgodnie z uwagą w rozdz. 1 pkt 1.1. w Załączniku nr 1 do
siwz (str. 6) Zamawiający wskazał, że w ramach realizacji Zamówienia wykonawca musi
opracować 250 szablonów raportów w Systemie, zgodnie z wzorami uzgodnionymi w
ramach Projektu Rozwiązania, z zastrzeżeniem, iż w ramach ww. szablonów Zamawiający
uwzględnia raporty wskazane w wymaganiach funkcjonalnych Opisu Przedmiotu
Zamówienia oraz nie uwzględni sprawozdań budżetowych i finansowych, wynikających z
przepisów prawa ogólnie obowiązującego.
Sputnik zwracał uwagę na możliwe zróżnicowanie pomiędzy raportami, które mogą
być generowane z systemów objętych przedmiotowym zamówieniem. Część raportów może
mieć postać jednostronicowych dokumentów, które są jedynie podsumowaniem danych,
zawartych w systemie. Jednakże część raportów może mieć postać złożonych,
wielostronicowych dokumentów, które działają nie tylko jako forma zagregowania pewnych
łatwo dostępnych z systemu informacji, ale mają cechy analityczne. Powyższe oznacza, iż
jeden raport może charakteryzować się stosunkowo niewielką pracochłonnością, gdzie
natomiast inny raport poza pracą programisty może wymagać konieczności zaangażowania
eksperta z danej dziedziny. Tym samym, przy tak sformułowanym wymaganiu pojawia się
wątpliwość, w jaki sposób może to zostać wycenione, a tym samym w jaki sposób powinno
to zostać uwzględnione w przygotowywanej ofercie. Fakt, iż zakres raportów ma określony
dopiero na etapie Projektu Rozwiązania przerzuca na wykonawcę w całości ryzyko,
związane z wyceną elementów nieokreślonych i w żaden sposób nie zdefiniowanych.
VII.
Odwołujący wskazywał, że zgodnie z rozdz. 4 pkt 4.2. ppkt 4.2.7 Załącznika nr 1 do
siwz, Zamawiający zawarł następujący wymóg: Wszystkie połączenia (Integracja) wykonane
pomiędzy systemami powinny być wykonane z wykorzystaniem szyny usług/danych, których
licencje opisał Zamawiający w punkcie 2.2 podpunkt g. W innym przypadku Wykonawca
zobowiązany jest dostarczyć licencje oprogramowania szyny usług/danych spełniającego
wymagania opisane w punkcie 4.2.26 w ilości zapewniającej sprawne działanie Systemu z
zachowaniem wydajności opisanej w punkcie 4.1.2. Jednocześnie, zgodnie z pkt 4.6
Załącznika nr 1 do siwz,, Zamawiający wskazał, iż wymaga, aby integracja między
Systemem, a systemami zewnętrznymi odbywała się z wykorzystaniem zewnętrznych Web-
Services nie wbudowanych w aplikację. W przypadku, gdy taka integracja jest niemożliwa,
Zamawiający dopuszcza po uprzednim uzgodnieniu pomiędzy stronami inne rodzaje
integracji, włącznie z zasileniem Systemu danymi wprowadzanymi, przez formatki lub pliki
wymiany danych zaciągane przez funkcje systemowe. Połączenia pomiędzy systemami
powinny być wykonane z wykorzystaniem szyny usług/danych Zamawiającego, wykazanych
w punkcie 2.2 podpunkcie g, w przeciwnym wypadku zobowiązany jest do dostarczenia
licencji oprogramowania szyny usług/danych spełniających warunki opisane w punkcie
4.2.26.
W ocenie Odwołującego przywołane informacje jedynie w sposób częściowy
pozwalają na określenie, w jaki sposób i przy jakich nakładach pracy będzie możliwe
zapewnienie, wymaganej przez Zamawiającego integracji. Jak można na podstawie siwz
przypuszczać, Zamawiający posiada wiedzę na temat niezbędnych do przeprowadzenia
integracji informacji, jakie powinny być udostępnione, w odniesieniu do ogólnego wskazania
na Web- Services. Jak wynika bowiem z wymagań dotyczących dokumentacji
podwykonawczej, Zamawiający wymaga, aby wykonawca podał wykaz wszystkich
WebSerwisów i/lub plików wymiany wraz z opisem i wskazaniem danych wejściowych oraz
danych wyjściowych (Rozdz. 7 pkt 7.5. ppkt 7.5.9 tiret 13 Załącznika nr 1 do siwz).
Zdaniem Sputnik informacje podane w specyfikacji w zakresie integracji są niepełne i
powinny zostać uzupełnione przynajmniej o następujące dane: wykaz wszystkich
WebSerwisów i/lub plików wymiany wraz z opisem i wskazaniem danych wejściowych oraz
danych wyjściowych.
W dniu 23 lutego 2016 r. Zamawiający, w formie pisemnej, złożył odpowiedź na
odwołanie opisane powyżej. W treści pisma wnosił o oddalenie odwołania w całości oraz
przedstawił szczegółową argumentację w tym zakresie.
KIO 170/16
W dniu 8 lutego 2016 r. wykonawca Comarch Polska S.A., al. Jana Pawła II 39a, 31-
864 Kraków (dalej: „Odwołujący” lub „Comarch”) wniósł do Prezesa Krajowej Izby
Odwoławczej odwołanie od:
1. Czynności opisania „próbki":
• w sposób zawierający nieuzasadnione i ograniczające konkurencję oraz
możliwość uzyskania zamówienia zapisy, dotyczące technicznego sposobu
przygotowania próbki oraz przebiegu prezentacji próbki;
• w sposób niejednoznaczny i nieprecyzyjny, co utrudnia wykonawcy określenie,
jakie są wymagania Zamawiającego w stosunku do prezentowanego
systemu;
• przez określenie zadania testowego w sposób, umożliwiający wpływ
Zamawiającego na ocenę ofert w tym kryterium i powodujący brak przyznania
punktacji w sytuacji, w której oferowany system realizuje wymagane i
testowane funkcjonalności, jak i poprzez określenie zadania testowego w
sposób umożliwiający preferowanie określonych wykonawców,
- co stanowi naruszenie przepisu art. 7 ust. 1 Pzp w związku z art. 91 ust. 1
Pzp i art. 29 ust. 1 Pzp oraz art. 25 ust. 1 pkt. 2 Pzp w zw. z § 6 ust. 1 pkt. 1
Rozporządzenia Prezesa Rady Ministrów z dnia 19 lutego 2013 r. w sprawie
rodzajów dokumentów, jakich może żądać zamawiający od wykonawców,
oraz form, w jakich te dokumenty mogą być składane (Dz. U. z 2013 r. poz.
231).
czynności
opisania
przedmiotu
zamówienia
w
sposób
niejasny,
niewyczerpujący, bez podania wszelkich okoliczności mogących mleć wpływ
na złożenie oferty, a także w sposób utrudniający konkurencję - co stanowi
naruszenie, art. 29 ust. 1 oraz 2 w zw. z art. 7 ust. 1 ustawy;
czynności polegającej na opisaniu kryterium oceny ofert pn. „Jakość" oraz na
określeniu jego znaczenia w sposób umożliwiający Zamawiającemu
dokonanie oceny subiektywnej i uznaniowej, co utrudnia uczciwą konkurencję,
gdyż nie zapewnia obiektywizmu oceny oferty i porównania ofert,
- co stanowi naruszenie przepisu art. 7 ust. 1 w zw. z art. 36 ust. 1 pkt 13
ustawy w zw. ,z art. 91 ust. 2 ustawy.
W związku z powyższym Odwołujący wnosił o uwzględnienie odwołania i nakazanie
Zamawiającemu modyfikacji treści siwz w sposób wskazany w treści uzasadnienia
odwołania, tak, aby zmodyfikowane zapisy siwz były zgodne z ustawą.
W uzasadnieniu odwołania Comarch wyjaśniał:
I. Zarzut dotyczący zestawu testowego - złożenie zestawu testowego na jednym
notebooku
Zamawiający określił w pkt 3 dokumentu Załącznik nr 3 do Opisu przedmiotu
zamówienia (str. 1) następujące wymaganie:
„3. Zestaw testowy, który Wykonawca jest zobowiązany do dołączenia do oferty musi
zawierać sprzęt niezbędny do uruchomienia wersji demonstracyjnej Systemu w postaci co
najmniej: wyłącznie 1 komputera tyou notebook. na którym będzie zainstalowany system
demonstracyjny, Oprogramowania, w tym standardowego oprogramowania klasy ERP,
Oprogramowania Aplikacyjnego w wersji demonstracyjnej, nośnika danych zawierającego
obraz dysku/dysków komputera typu notebook z wygenerowany sumami kontrolnymi MD5,
wydruk zawierający wszystkie sumy kontrolne MD5 dla wszystkich plików oraz innych
komponentów niezbędnych do wykonania prezentacji.
Odwołujący zarzucał, że taki wymóg poważnie utrudnia udział w postępowaniu i
złożenie oferty, bowiem - gdyby w/w zapis został utrzymany - będzie wiązał się z
poniesieniem przez wykonawców bardzo wysokich kosztów zakupienia, odpowiedniego
notebooka o bardzo wysokich i niestandardowych parametrach wydajnościowych,
umożliwiających uruchomienie wersji demonstracyjnej Systemu. Wymaganie, aby próbka czy
też zestaw testowy mogła być dostarczona w ofercie „wyłącznie" na jednym komputerze typu
notebook jest niezrozumiałe. Zdaniem Comarch na wymaganie to należy spojrzeć pod kątem
zakresu wymaganego do zaprezentowania w ramach demonstracji próbki. Otóż na w/w
notebooku musi zostać uruchomione całe środowisko demonstracyjne w architekturze 3-
warstwowej [system ERP, baza, serwer aplikacji]. Nie ma to uzasadnienia ani w sprawności
przeprowadzenia procesu testowego, ani też nie wynika w żaden sposób z przepisów prawa.
Odwołujący zwraca uwagę, że przedmiotem prezentacji nie jest prosty system Finansowo
Księgowy, ale rozwiązanie klasy „Enterprise", będące demonstracją części funkcjonalności
systemu docelowego, mającego wspomagać zarządzanie finansami Miasta Łódź, dla
którego docelowo sam Zamawiający zadeklarował infrastrukturę złożoną z ośmiu serwerów,
którą zaprezentował w Załączniku nr 1 do siwz str. 24-25:
„Zamawiający zamierza przeznaczyć wyłącznie na potrzeby realizacji niniejszego
zamówienia następujące elementy infrastruktury informatycznej:
a) 6 serwerów o parametrach: 4 CPU (4 x 10 Core), 512 GB RAM, 600 GB HDD dla
potrzeb uruchomienia komponentów serwera/ów aplikacyjnych wraz z szyną
usług/danych i WebService-ami. Każdy serwer będzie posiadał licencję Windows
Server 2012 R2 w wersji DataCenter oraz licencję CAL dla każdego użytkownika,
b) 2 serwery o parametrach: 2 CPU (2 x 8 Core), 512 GB RAM, 600 GB HDD dla
potrzeb uruchomienia k/astra bazy danych w trybie Active-Passive na wszystkie
dane Rozwiązania, każdy serwer będzie posiadał licencję Windows Server. 2012
R2 oraz licencję CAL dla każdego użytkownika".
W ocenie Odwołującego nie zachodzą żadne przeszkody, aby prezentowany System
mógł być zainstalowany na większej liczbie komputerów. Przede wszystkim zaś należy
podkreślić, iż decyzja co do sposobu prezentacji próbki w zakresie liczby i jakości sprzętu
winna należeć wyłącznie do wykonawcy, zaś narzucanie Ilościowych wymagań sprzętowych
- dotyczących wszak sprzętu wykonawcy, wprost przekłada się na koszt sporządzenia oferty.
Należy nadmienić, iż notebooki które udźwignęłyby wydajnościowo potrzeby prezentacji
istnieją na rynku, lecz nie jest to sprzęt typowy, będący na stanie każdego z wykonawców.
Konieczność jego zakupu jest nieuzasadnionym wydatkiem, wpływającym na koszt
przygotowania oferty.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz, przez usunięcie wymagania ograniczającego zestaw testowy do wyłącznie jednego
notebooka. Każdy z Wykonawców samodzielnie powinien decydować na jakim sprzęcie
zostanie zainstalowany zestaw testowy.
Zdaniem Comarch umożliwi to sprawne przeprowadzenie procesu testowego oraz
usunie niczym nie uzasadnione wymaganie ograniczające możliwość złożenia ofert przez
wykonawców, oferujących systemy informatyczne, wymagające złożenia próbki
oprogramowania w formie innej niż wyłącznie na jednym notebooku.
II. Zarzut dotyczący zestawu testowego - sumy kontrolne MP5
Zamawiający określił w pkt 3 dokumentu „Załącznik nr 3 do Opisu przedmiotu
zamówienia" (str. 1) następujące wymaganie:
„3. Zestaw testowy, który Wykonawca jest zobowiązany do dołączenia do oferty musi
zawierać sprzęt niezbędny do uruchomienia wersji demonstracyjnej Systemu w postaci co
najmniej: wyłącznie 1 komputera typu notebook, na którym będzie zainstalowany system
demonstracyjny, Oprogramowania, w tym standardowego oprogramowania klasy ERP,
Oprogramowania Aplikacyjnego w wersji demonstracyjnej, nośnika danych zawierającego
obraz dysku/dysków komputera typu notebook z wygenerowany sumami kontrolnymi MD5.
wydruk zawierający wszystkie sumy kontrolne MD5 dla wszystkich plików oraz innych
komponentów niezbędnych do wykonania prezentacji.
Odwołujący zarzucał, że taki wymóg w praktyce uniemożliwia przygotowanie zestawu
testowego, ponieważ z przedmiotowego zapisu wynika, że sumy kontrolne MD5 mają zostać
wygenerowane dla „wszystkich plików" - co oznacza, że w grę wchodzą również np. pliki
systemu operacyjnego zainstalowanego na dostarczonym sprzęcie, a zatem również np. dla
plików systemowych (Windows). Przygotowanie obrazu dysków z wygenerowanymi sumami
kontrolnymi MD5 dla „wszystkich" plików wymaga ponadstandardowego zaangażowania
zasobów na potrzeby przygotowania próbki, jest też niezwykle czasochłonne, wreszcie
trudno wykluczyć powstanie niezamierzonego błędu, który mógłby potencjalnie rodzić
negatywne konsekwencje dla wykonawcy (np. poprzez pominięcie sumy kontrolnej dla
jednego ze wszystkich plików, lub nawet przypadkowe usunięcie lub zmianę jednej cyfry w
liczbie kontrolnej). Wymaganie takie nie jest uzasadnione ani ochroną zestawu testowego
przed nieuprawnioną modyfikacją, ani też zapewnieniem sprawności przeprowadzenia
procesu testowania (sporządzanie sumy kontrolnej dla plików systemowych nie ma po prostu
sensu).
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz, przez usunięcie z w/w wymagania słowa „wszystkich" i doprecyzowanie, iż chodzi o
sumy kontrolne dla plików, gdzie przez plik należy rozumieć obraz dysku/dysków
III. Zarzut dotyczący zestawu testowego - instrukcja do samodzielnej prezentacji
Systemu
Zamawiający określił w pkt 8 dokumentu Załącznik nr 3 do Opisu przedmiotu
zamówienia (str. 2) następujące wymaganie:
„8. Zestaw testowy musi zawierać również instrukcję w postaci wydrukowanej, która umożliwi
Zamawiającemu samodzielne wykonanie prezentacji Systemu oraz/i odtworzenie „obrazu"
Systemu, zainstalowanego na dysku/dyskach komputera typu notebook. Instrukcja może być
dostarczona najpóźniej do chwili zakończenia prezentacji przeprowadzanej przez danego
Wykonawcę"
Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione. Zestaw testowy
będzie prezentowany przez przedstawicieli wykonawcy, którzy posiadają wiedzę na temat
oferowanego systemu i to przeprowadzona przez nich prezentacja podlega ocenie w
procesie wyboru oferty najkorzystniejszej. Odwołujący nie znajdował uzasadnienia dla
samodzielnego wykonywania prezentacji i odtwarzania scenariuszy testowych przez
Zamawiającego, gdyż nie jest to przedmiotem oceny, a także z uwagi na to, że zestaw
testowy będzie zaawansowanym i złożonym rozwiązaniem klasy ERP, którego efektywna i
samodzielna obsługa przez użytkownika końcowego wymaga - dla prawidłowego procesu
obsługi czy prezentacji Systemu - co najmniej kilkudniowych szkoleń i warsztatów.
Odpowiednie szkolenia użytkowników są jednym z elementów zamówienia na etapie jego
wykonania, w ramach prezentacji będącej elementem oceny oferty nie ma zaś na nie
miejsca. Przede wszystkim zaś należy podkreślić, iż wymóg złożenia w ofercie instrukcji
umożliwiającej samodzielne przeprowadzenie prezentacji przez Zamawiającego niczemu nie
służy - bowiem ocena oferty wręcz nie może pochodzić z takiej samodzielnej prezentacji
wykonanej przez samego Zamawiającego. Nie można bowiem wykluczyć błędów po stronie
Zamawiającego, wynikających choćby właśnie z braku dostatecznej wiedzy o oferowanym
Systemie lub niewłaściwego przyswojenia przekazanych w instrukcji Informacji. Nie istnieje
zaś taka instrukcja, która ze 100-procentową pewnością gwarantowałaby prawidłową
obsługę systemu przez Zamawiającego. Zamawiający powinien być świadom tego, iż
obsługa poszczególnych funkcjonalności danego Systemu musi wiązać się z procesem
długotrwałego szkolenia użytkownika i wymaga wiedzy, której po prostu nie da się uzyskać
jedynie poprzez zapoznanie się z instrukcją obsługi systemu.
Zdaniem Odwołującego również dołączanie instrukcji odtworzenia „obrazu" Systemu
nie ma uzasadnienia i wpływa na koszt wykonania oferty, jak i rodzi ryzyko dla jego oceny
przez Zamawiającego za pomocą poza proceduralnych ocen, tj. osiągniętych poza
przewidzianą w siwz procedurą oceny próbki z udziałem wykonawców. Nie jest bowiem
możliwe przygotowanie takiej instrukcji, w której przewidziane zostaną wszystkie możliwe
warianty. Odtwarzanie środowiska z obrazu dysku ma też pewne ograniczenia techniczne.
Przykładowo odtworzenie powinno być wykonane na identycznym środowisku jak
ś
rodowisku pierwotne - tylko taki wariant gwarantuje, że oprogramowanie Wykonawcy nie
będzie wymagało rekonfiguracji/reinstalacji. Przywrócony z obrazu system operacyjny wraz
ze sterownikami musi pasować do urządzenia, na którym wykonywane Jest odtwarzanie.
Przykładowo wczytanie obrazu na komputer, który ma inny chipset płyty głównej czy kartę
sieciową innego producenta skutkować będzie zmianą adresu fizycznego MAC. Do
odtworzenia konieczne będzie wgranie innych sterowników dla urządzeń sieciowych i innych
sterowników wynikających ze zmiany chipset'u płyty głównej. Cały ten proces spowoduje
między innymi zmianę konfiguracji sieciowej urządzenia i konieczność wykonania
rekonfiguracji komputera, na którym odtwarzany jest obraz. O ile wykonawca jest w stanie
przewidzieć pewne komplikacje jak np. konieczność przywrócenia konkretnej konfiguracji
sieciowej, to nie jest w stanie przewidzieć wszystkich przypadków samodzielnego działania
Zamawiającego, a tym bardziej tych, które zależą od właściwości i parametrów sprzętu, na
którym będzie wykonane przez Zamawiającego odtwarzanie środowiska, jeśli nie jest ono
najpierw precyzyjnie określone. W związku, z tym wykonawca nie jest w stanie
zagwarantować, że w instrukcji przewidzi wszystkie komplikacje, które mogą wystąpić w
trakcie odtwarzania, co pozwoli na prawidłowe uruchomienie oprogramowania.
Nie jest też jasny cel wymaganego odtworzenia „obrazu" Systemu zestawu testowego
przez Zamawiającego. Jeżeli cel ten wiąże się z postępowaniem dowodowym, dla którego
potrzebna jest próbka w postaci zestawu testowego, to odtworzenie takie powinno być
komisyjne w obecności wykonawcy i być elementem oceny oferty z jego udziałem, a wtedy
nie istniałaby konieczność wykonania takiego odtworzenia samodzielnie przez
Zamawiającego.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz poprzez usuniecie w/w wymagania w całości.
IV. Zarzut dotyczący prezentacji Systemu - czas przeznaczony na prezentacje zestawu
testowego
Zamawiający określił w Załączniku nr 4 do Opisu przedmiotu zamówienia
Scenariusze testowe, będące przedmiotem oceny. Zakres prezentacji Systemu jest bardzo
szeroki i obejmuje:
• Obszar I [Scenariusze testowe dla obszaru budżetowo-księgowego]
- Scenariusz testowy nr 1: Wprowadzenie i zaksięgowanie uchwały budżetowej wraz
ze zmianą w planie budżetu - obejmujący 9 zadań do wykonania,
- Scenariusz testowy nr 2: Ewidencja umów zakupu i sprzedaży wraz z ich realizacją -
obejmujący 21 zadań do wykonania,
- Scenariusz testowy nr 3: Ewidencja sprawozdań jednostkowych w organie wraz z
generowaniem sprawozdań zbiorczych - obejmujący 6 zadań do wykonania,
• Obszar II [Scenariusze testowe dla obszaru opłat i podatków]
- Scenariusz testowy nr 1: Obsługa wpłat masowych i windykacja zaległości -
obejmujący 18 zadań do wykonania,
- Scenariusz testowy nr 2: Obsługa wpłaty zobowiązanego na należność objętą
tytułem Wykonawczym - obejmujący 9 zadań do wykonania,
- Scenariusz testowy nr 3: Określenie przypisu podatku na podstawie korekty
deklaracji Podatkowej - obejmujący 3 zadania do wykonania,
- Scenariusz testowy nr 4: Ustalenie podatku od nieruchomości w wyniku
prowadzenia postępowania podatkowego (decyzje ustalające, zmieniające lub
uchylające) - obejmujący 6 zadań do wykonania
- Scenariusz testowy nr 5: Egzekucja Należności Pieniężnych - obejmujący 9 zadań
do wykonania
- Scenariusz testowy nr 6: Windykacja Należności Cywilnoprawnych - obejmujący 6
zadań do wykonania.
Comarch podnosił, że na przeprowadzenie prezentacji Zamawiający przeznaczył 6
godzin - zgodnie z pkt. 30 Załącznika nr 3 do OPZ (str. 4) „30. Łączny czas prezentacji nie
może przekroczyć 6 godzin zegarowych, w przypadku, gdy w tym czasie Wykonawca nie
zaprezentuje wszystkich scenariuszy Zamawiający przyzna punkty wyłącznie za scenariusze
zaprezentowane w całości w kryterium oceny: „Stopień gotowości Systemu do wdrożenia"
oraz w kryterium oceny: „Jakość".
Zatem wykonawcy łącznie muszą zaprezentować 87 zadań w ciągu 6 godzin
zegarowych, co daje średnio 4 minuty na jedno zadanie, a należy w tym miejscu podkreślić,
ż
e wybrane zadania składają się z wielu podzadań, co znacząco obniży średnią
arytmetyczną czasu prezentacji każdego z wymagań. Na przykład w Scenariuszu testowym
nr 6 (Windykacja Należności Cywilnoprawnych) w zadaniu 1. wyróżniono 8 podzadań - str. 6
Załącznika nr 4 do OPZ:
„ Wprowadzanie ręczne do systemu sprawy w treści, której muszą znaleźć się:
a)
oznaczenie kolejnego numeru sprawy,
b)
oznaczenie rodzaju zobowiązania,
c)
oznaczenie tytułu wykonawczego: sygnatura akt sądowych, organ, który
wydał, tytuł, data wydania tytułu,
d)
oznaczenie dłużnika: Imię, nazwisko / nazwa, adres, PESEL /NIP/ KRS,
e)
w przypadku wielości dłużników rozróżnienie na zobowiązania solidarne
(wtedy „wspólna" wysokość zobowiązania, a wszystkie czynności dokonane
muszą dotyczyć wszystkich dłużników solidarnych) i niesolidarne (wtedy
oddzielnie wprowadzona wysokość zobowiązania, zaś czynność dokonane
muszą dotyczyć każdego z dłużników osobno),
f)
oznaczenie wierzyciela: nazwa, adres, numer rachunku bankowego,
g)
oznaczenie organu egzekucyjnego,
h)
kwota zadłużenia z rozbiciem na należność główną, odsetki, koszty sądowe i
koszty egzekucyjne"
Odwołujący zarzucał, że czas przeznaczony na prezentację tak obszernych
funkcjonalności jest niewystarczający i może uniemożliwić po pierwsze prawidłową
weryfikację przeprowadzenia poszczególnych scenariuszy testowych, nawet zakładając
poprawne przeprowadzenie danego scenariusza przy pierwszej próbie, a po drugie - w/w
limit czasu prezentacji wprowadzony w siwz skutkuje tym, że wykonawcy nie uzyskają
zaliczenia danego scenariusza, pomimo, że merytorycznie system spełniałaby określone w
scenariuszu wymagania. Wynika to z faktu, iż Zamawiający zastrzegł w siwz, że w przypadku
gdy wykonawca nie zmieści się w czasie 6 godzin, funkcjonalności które nie zostały
zaprezentowane zostaną uznane za takie, których system nie posiada - str. 6 Załącznika nr 3
do OPZ:
„iv. W przypadku nie powodzenia prezentacji danego scenariusza testowego,
Wykonawca może powtórzyć go nieograniczoną liczbę razy dokonując
rekonfiguracji wersji demonstracyjnej Systemu z zastrzeżeniem pkt 33.
Przeprowadzenie powtórnej próby scenariusza testowego nie wydłuża
łącznego czasu (6 godzin zegarowych) na przeprowadzenie prezentacji
wszystkich scenariuszy testowych.
v. Punkty zostaną przyznane jedynie za scenariusze testowe zakończone w całość.
vi. W przypadku. gdy scenariusz testowy nie zostanie przeprowadzony w całość lub w
ogólne się nie rozpocznie, zostanie uznany za scenariusz niewykonany i
zostanie przyznane zero („0") punktów z puli punktów przewidzianych dla tego
scenariusza testowego."
Zdaniem Odwołującego ocena końcowa funkcjonalności systemu będzie wobec tego
niewspółmiernie obniżona pomimo tego, że system dane funkcjonalności posiada, ale czas
przeznaczony na prezentację systemu został wyczerpany. Odwołujący zwraca uwagę, że
przeprowadzenie prezentacji tak szerokiej gamy funkcjonalności jest bardzo pracochłonne i
czasochłonne, nawet dla osób znających dogłębnie prezentowany system i na co dzień
zajmujących się jego obsługą. Odwołujący zwraca również uwagę, że czym innym jest
przeprowadzenie danej operacji w procesie użytkowania produkcyjnego systemu, a czym
innym przeprowadzenie prezentacji dla Zamawiającego. Jednym z elementów takiej
prezentacji jest komunikacja prezentującego z przedstawicielami Zamawiającego i
ewentualne udzielanie odpowiedzi na pytania przedstawicieli Zamawiającego. Powyższe - co
wynika z doświadczeń Odwołującego - znacząco wpływa na czas prezentacji. Prezentacja
scenariuszy jest procesem dużo bardziej czasochłonnym niż wykonanie danych procesów
przez pracownika użytkującego system produkcyjnie.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz, przez wydłużenie czasu prezentacji do 8 godzin zegarowych.
V. Zarzut dotyczący prezentacji zestawu testowego - dopuszczenie przedstawiciel
pozostałych Wykonawców w roli obserwatorów na prezentacji danego
Wykonawcy.
Zamawiający określił w pkt 27 Załącznik nr 3 do OPZ (str. 4) następujące wymaganie:
„27. Zamawiający dopuszcza by w trakcie prezentacji/testu obecni byli przedstawiciele
pozostałych Wykonawców w roli obserwatorów (po jednym dla każdego Wykonawcy). Osoby
te muszą posiadać ważny dokument uprawniający ich do reprezentowania Wykonawców. W
przypadku, gdy wykonawca skutecznie zastrzeże w złożonej ofercie, że zaoferowany system
stanowi tajemnicę przedsiębiorstwa w rozumieniu ustawy z dnia 16 kwietnia 1993 r. o
zwalczaniu nieuczciwej konkurencji (Dz.U. 2003 Nr 153 poz. 1503 z późn. zm.),
Zamawiający nie dopuść by w trakcie prezentacji/testu obecni byli przedstawiciele
pozostałych Wykonawców w roli obserwatorów (...)".
Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione, ponieważ prowadzi
do nierównego traktowania wykonawców. Wykonawca, który jako ostatni będzie prezentować
swój zestaw testowy, a weźmie udział we wcześniejszych prezentacjach konkurentów,
będzie bogatszy o niesłychanie istotną wiedzę w zakresie przede wszystkim tego, jak
Zamawiający interpretuje poszczególne wymagania oraz na jakie aspekty systemu i pod
jakim kątem Zamawiający zwraca uwagę w toku prezentacji. Jest to niesłychanie istotna
wiedza, wpływająca na sprawność i czas przeprowadzenia prezentacji przez wykonawców.
Głównym powodem nierównego traktowania wykonawców w tym zakresie jest jednak to, że
wykonawcy prezentujący system jako ostatni będą mieli czas na odpowiednie przygotowanie
się do swojej prezentacji, tak aby uzyskać lepszą ocenę od konkurentów - co nie będzie
dane wykonawcy, który odbywać będzie prezentację jako pierwszy.
Odwołujący zwracał też uwagę na dodatkowy aspekt w/w zapisu. Otóż uniemożliwia
on skuteczne zastrzeżenie próbki Systemu jako tajemnicy przedsiębiorstwa - do czego każdy
z wykonawców - o ile tylko spełnia przesłanki ustawowe tej definicji - ma prawo. Tymczasem
zapis o jawnej prezentacji z udziałem choćby konkurencji niejako na wstępnie - działaniem
samego Zamawiającego (zapisem siwz) - eliminuje jedną z przesłanek tajemnicy
przedsiębiorstwa, a mianowicie tę dotyczącą podjęcia przez wykonawcę działań w celu
zachowania informacji w tajemnicy.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz poprzez usunięcie w/w wymagania w całości.
VI. Zarzut dotyczący prezentacji Systemu - ograniczenie liczby przedstawicieli
Wykonawcy
Zamawiający określił w pkt 27 Załącznika nr 3 do OPZ (str. 4) następujące
wymaganie:
„27. (...) Zamawiający dopuszcza udział maksymalnie 5 przedstawicieli Wykonawcy do
przeprowadzenia prezentacji."
Odwołujący zarzucał, że przedmiotowe wymaganie jest nieuzasadnione i ingeruje w
proces przeprowadzenia próbki w zakresie w jakim winno to zależeć od decyzji samego
wykonawcy. W ocenie Odwołującego nie ma podstaw do ograniczenia liczby osób
reprezentujących Wykonawcę do pięciu, zwłaszcza, że zakres funkcjonalny prezentowanego
zestawu testowego jest bardzo szeroki. Wykonawca może i powinien móc dysponować
osobnym pracownikiem od każdego testowanego obszaru - tak by mógł optymalnie
zaprezentować system z wykorzystaniem najlepszych specjalistów. Jeżeli intencja
Zamawiającego jest uniknięcie „tłoku" na prezentacji - wystarczającym zapisem byłoby
ograniczenie, iż każdorazowo na sali, na której odbywa się prezentacja, obecnych mogłoby
być jednocześnie pięciu przedstawicieli Wykonawcy, jednak ich skład powinien być jednak
możliwy do zmiany w toku prezentacji, jeśli wystąpi taka potrzeba ze strony wykonawcy, w
szczególności w przypadku, gdy po stronie wykonawcy występuje specjalizacja konsultantów
prezentujących poszczególne obszary oprogramowania.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz, przez usunięcie limitu osób prezentujących zestaw testowy lub modyfikację w taki
sposób, aby dopuszczona była wymiana przedstawicieli wykonawcy przy założeniu, że
jednocześnie podczas prezentacji obecnych będzie na sali, na której odbywa się prezentacja
nie więcej niż 5 osób ze strony wykonawcy.
VII. Zarzut dotyczący prezentacji zestawu testowego - narzucona kolejność realizacji
scenariuszy testowych
Zamawiający określił w pkt 37 Załącznika nr 3 do OPZ (str. 5) następujące
wymaganie:
,,b) ii. Wykonawca powinien dokonywać prezentacji zgodnie z kolejnością opisanych w SIWZ
scenariuszy testowych".
Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione i ogranicza
konkurencję, bowiem może powodować eliminację wykonawców, których system - z uwagi
na jego wewnętrzną logikę - w optymalny sposób posługiwałby się inną kolejnością
prezentacji poszczególnych podzadań czy zadań. Aspekt ograniczenia konkurencji polega, w
tym przypadku na tym, że odmienna od optymalnego dla danego konkretnego systemu
kolejność realizacji scenariuszy testowych - w kontekście celu próbki czyli zbadania czy dany
system realizuje daną funkcjonalność jest nadmiarowy i szkodzi wykonawcom w ten sposób,
iż wpływa na wydłużenie czasu prezentacji - co przy jego limicie może w skrajnym przypadku
prowadzić do nieprzeprowadzenia do końca danego scenariusza. Aspekt kolejności
scenariuszy testowych i przeprowadzanych w ich ramach zadań czy podzadań powinien
należeć wyłącznie do decyzji wykonawcy. Z punktu widzenia oceny próbki jest to
niesłychanie istotne. Dlatego że nie można zapominać o tym, iż prezentacja próbki jest
elementem oceny oferty. Wykonawca powinien mieć w tym zakresie pełną, nieskrępowaną
możliwość wpływu na treść swej oferty - podobnie jak ma to miejsce w zakresie np. ceny.
Ograniczenia typowe dla prezentacji jak choćby czasu prezentacji czy wybór przez
Zamawiającego funkcjonalności do zaprezentowania są naturalne, składają się bowiem na
element zadania dla Wykonawcy, z uwzględnieniem realiów pracy Zamawiającego. Jednak
już aspekt kolejności prezentacji scenariuszy ingeruje w samą istotę i merytorykę systemu, a
zatem ingeruje w treść oferty, bowiem nie uwzględnia nieznanej Zamawiającemu - co
oczywiste - logiki danego systemu. W ten sposób w/w zapis ingeruje w ocenę oferty -
bowiem eliminuje lub może eliminować szansę danego wykonawcy na uzyskanie
zamówienia, co może być pochodną narzuconego, nieoptymalnego i sprzecznego z logiką
danego systemu sposobu prezentacji (kolejności prezentacji). Jeśli logika oferowanego
systemu będzie wymagała dla jego optymalnego zaprezentowania (również w czasie) innej
kolejności prezentacji poszczególnych punktów scenariusza, to Zamawiający powinien
dopuścić i uznać taką zmianę w każdym przypadku, jeśli tylko efekt końcowy realizacji
scenariuszy testowych będzie zgodny z oczekiwaniem Zamawiającego i będzie spełniał
wymagania wynikające z przepisów prawa.
Tym bardziej, że przedmiotem scenariuszy jest złożona funkcjonalność, która w
nowoczesnych systemach informatycznych może być realizowana za pomocą różnych
funkcjonalności pośrednich. Na tym polega główna różnica między konkurencyjnymi
systemami, że zapewniają one różny poziom automatyzacji dla realizacji zadań
Zamawiającego wynikających z przepisów prawa. W przeciwnym razie wszystkie systemy
byłyby identyczne. Wymóg realizacji scenariusza ściśle według założonej kolejności zadań
sprawia wrażenie, że Zamawiający stworzył scenariusze na podstawie jednego z systemów
istniejących na rynku, a wpisując to jako wymóg siwz ogranicza konkurencję uniemożliwiając
złożenie konkurencyjnej oferty innym wykonawcom.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz, przez usunięcie wymagania w całości.
VIII.
Zarzut dotyczący prezentacji Systemu - sposób punktacji scenariuszy testowych
Zamawiający określił w pkt v. Załącznika nr 3 do OPZ (str. 6) następujące
wymaganie:
„v. Punkty zostaną przyznane jedynie za scenariusze testowe zakończone w całości"
oraz
„vi. W przypadku, gdv scenariusz testowy nie zostanie przeprowadzony w całości lub w
ogólne się nie rozpocznie, zostanie uznany za scenariusz niewykonany i zostanie przyznane
zero („0") punktów z puli punktów przewidzianych dla tego scenariusza testowego".
Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione, ogranicza
konkurencyjność w postępowaniu i narusza zasadę równego traktowania wykonawców.
Wynik i przebieg prezentacji ma bowiem bezpośredni wpływ na ocenę oferty wg kryterium
„Stopień gotowości Systemu do wdrożenia (SGSW)". Zamawiający wskazał bowiem, że
punkty zostaną przyznane jedynie za scenariusze testowe zakończone w całości. Tym
samym Zamawiający wskazał, że nie ma możliwości uzyskania jakichkolwiek punktów za
daną grupę funkcjonalności, jako ocenę cząstkową w ramach scenariusza. W ocenie
Odwołującego tak określony sposób przyznawania punktacji nie jest obiektywny dla
wykonawców i uniemożliwia prawidłową ocenę oferowanego systemu informatycznego.
Przez prawidłową ocenę Odwołujący ma na myśli ocenę merytoryczną, polegającą na
przyznaniu punktów za zrealizowane przecież bez uwag zadania czy punkty scenariusza.
Nierówne traktowanie wykonawców, w omawianym zakresie przejawia się w tym, iż
każdorazowo przebieg prezentacji przez danego wykonawcę będzie inny - w tym w
szczególności inna może być postawa Zamawiającego, liczba zadawanych przez niego
pytań, czy podejmowane przez Zamawiającego inne działania w czasie prezentacji - co
wszystko przekłada się na czas. W tej sytuacji niezakończenie scenariusza w całości z uwagi
na upływ czasu oznaczać będzie brak punktów za cały scenariusz, pomimo że jego
poszczególne punkty zostały prawidłowo przeprowadzone. Zamawiający może zyskiwać -
wykorzystując ten zapis - wpływ na ocenę oferty: odpowiednio sterując przeprowadzenie
prezentacji może wpłynąć na brak czasu danego wykonawcy na pełne zakończenie
scenariusza - co będzie równoznaczne z nieprzyznaniem punktów. Takie ryzyko występuje,
zwłaszcza w sytuacji sprzyjania przez Zamawiającego określonemu wykonawcy.
W ocenie Odwołującego zasadne jest określenie zasad przyznawania punktacji, gdy
część danego scenariusza testowego zostanie zrealizowana. W innym przypadku
wykonawca, który zaprezentuje np. 17 zadań z 18 wskazanych przez Zamawiającego w
ramach Scenariusza testowego nr 1 (Obsługa wpłat masowych i windykacja zaległości)
uzyska taki sam (zerowy) wynik jak wykonawca, który nie zaprezentuje żadnego z 18 zadań
składających się na Scenariusz testowy nr 1. Tymczasem z punktu widzenia oceny
gotowości Systemu do wdrożenia która jest jedna z kryteriów oceny ofert podana różnica ma
kluczowe znaczenie. W ramach testowanego zakresu jeden wykonawca może mieć zatem
system w ogóle nie posiadający danej funkcjonalności - co oznacza iż w ogóle nie jest on
gotowy do wdrożenia, podczas gdy drugi wykonawca - zasadniczo - ma system gotowy do
wdrożenia w tym zakresie (bez jednego z 18 wymagań). Trudno zaakceptować jako zgodną
z art. 7 ust. 1 ustawy ocenę, że oferty obydwu wykonawców są w tym zakresie takie same
(otrzymują zero punktów). Jest to również dodatkowy przejaw nierównego traktowania
wykonawców.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz poprzez usunięcie w/w wymagania w całości i przyznanie punktów za poszczególne
zadania w ramach scenariusza.
IX. Zarzut dotyczący prezentacji zestawu testowego - zależność pomiędzy scenariuszami
testowymi
Zamawiający określił w pkt vi. Załącznika nr 3 do OPZ (str. 6) następujące
wymaganie: „vi. W przypadku, gdy scenariusz testowy nie zostanie przeprowadzony w
całości lub w ogólne się nie rozpocznie, zostanie uznany za scenariusz niewykonany i
zostanie przyznane zero („0") punktów z puli punktów przewidzianych dla tego scenariusza
testowego"
oraz Zamawiający określił w pkt 21. dokumentu Załącznik nr 4 do OPZ (str. 3) następujące
wymaganie „21. Warunkiem uzyskania oceny za scenariusz nr 2 jest wykonanie scenariusza
nr 1."
oraz Zamawiający określił w pkt 21. dokumentu Załącznik nr 4 do OPZ (str. 3) następujące
wymaganie „6. Warunkiem uzyskania oceny za scenariusz nr 3 jest wykonanie scenariusza
nr 2."
Odwołujący zarzucał, że powyższe wymagania są nieuzasadnione, bowiem w
przypadku Obszaru I [„Scenariusze testowe dla obszaru budżetowo-księgowego"] złożonego
z trzech scenariuszy testowych, brak zaprezentowania w pełni Scenariusza 1, eliminuje
możliwość uzyskania punktów za Scenariusz 2 i 3, ponieważ ostatnie punkty w
przedmiotowych scenariuszach mają brzmienie jak przytoczono. Taka konstrukcja wymagań
powoduje efekt wręcz przeciwny, bowiem premiuje system o mniejszej gotowości do
wdrożenia: wyższą punktację może uzyskać system, który jest w znacznie mniejszym,
stopniu gotowy do wdrożenia, a tym samym zasady oceny w ramach tego kryterium mają
wadę logiczną. Zamawiający określił następującą punktację za poszczególne scenariusze
(Załącznik nr 3 do OPZ str. 9):
Scenariusz nr 1: 7 pkt
Scenariusz nr 2: 8 pkt
Scenariusz nr 3: 7 pkt
Określona przez Zamawiającego punktacja pokazuje, że każdy z 3 scenariuszy ma
podobną wagę (znaczenie) dla oceny stopnia gotowości Systemu do wdrożenia. Tymczasem
jeżeli jeden z wykonawców zaprezentuje tylko i wyłącznie scenariusz nr 1 w ogóle nie
przystępując do prezentacji scenariuszy 2 i 3 otrzyma 7 pkt. Natomiast wykonawca, który w
ramach scenariusza nr 1 nie zaprezentuje jednej drobnej funkcjonalności, natomiast będzie
wstanie zaprezentować scenariusze 2 i 3 w całości, mógłby otrzymać 15 pkt, ale z uwagi na
kwestionowane w odwołaniu zapisy otrzyma zero punktów. Tym samym wyższą ocenę
otrzyma system, który w ramach obszaru budżetowo-księgowego jest w stanie zrealizować
scenariusz za 7 punktów, a oferta której przedmiotem jest system realizujący w tym obszarze
scenariusze za 15 punktów zostanie oceniona niżej, mimo tego, że jej wynik w ocenie
punktowej jest dwa razu „lepszy". W przedstawionej symulacji pominięto fakt, że określając 8
pkt. za scenariusz nr 2 Zamawiający wskazał, że jest on bardziej istotny dla oceny stopnia
gotowości Systemu do wdrożenia, niż scenariusz nr 1. Jednak określenie zależności między
scenariuszami powoduje, że system realizujący scenariusz bardziej istotny dla
Zamawiającego (8 pkt w ocenie jednostkowej) będzie gorzej oceniony, niż system realizujący
wyłącznie scenariusz nr 1, który jest mniej istotny dla Zamawiającego w ramach tego
kryterium (7 pkt, w ocenie jednostkowej).
Zdaniem Comarch powyższe zapisy w sposób nieuzasadniony ingerują również w
wynik oceny ofert i w sferę odpowiedzialności wykonawcy za jego, ofertę, bowiem narzucają
zależność pomiędzy oceną poszczególnych scenariuszy - co nie powinno mieć miejsca.
Zwraca uwagę fakt, iż z punktu widzenia celu prezentacji wskazana zależność wpływa tak
naprawdę na przyznanie punktacji. Równie dobrze można wyobrazić sobie siwz bez w/w
zapisu. Co traciłby Zamawiający, gdyby nie było zakazanych zapisów? Otóż traciłby prawo
odmowy przyznania punktu za zrealizowany przez danego wykonawcę scenariusz np.
scenariusz 3 - co prowadzi do absurdu. Skoro w siwz istnieją zapisy które powodują, że za
zrealizowany scenariusz wykonawca nie otrzymuje punktów - należy wskazać, iż ograniczają
one konkurencję, zafałszowują ocenę oferty w kryterium gotowości systemu do wdrożenia i
de facto stanowią narzędzie wpływu poprzez postanowienia siwz na wynik oceny ofert. Z
takim postanowieniami nie można się zgodzić. Waga w/w kryterium oceny oferty jest tak
duża, iż każdy zapis który pozwoli Zamawiającemu nie przyznać punktu za zrealizowany
scenariusz należy uznać za niezgodny z ustawą.
W związku z powyższym Odwołujący wnosi o nakazanie Zamawiającemu modyfikacji
siwz, przez usunięcie w/w wymagań w całości i uniezależnienie scenariuszy od siebie oraz o
dopuszczenie - w przypadku niewykonania jednego ze scenariuszy - iż na potrzeby
kolejnego scenariusza wykonawca wykorzysta dane nie pochodzące z poprzedniego
scenariusza.
X. Zarzut dotyczący jednolitości technologii i interfejsu w całym systemie
Zamawiający określił w pkt f) Załączniku nr 1 OPZ (str. 3) następujące wymaganie:
„f. Zamawiający wymaga, aby wszystkie moduły oferowanego rozwiązania napisane były w
tej samej technologii"
oraz Zamawiający określił w pkt 4.2.22 dokumentu Załącznik nr 1 do OPZ (str. 32)
następujące wymaganie: „4.2.22. System musi zapewniać jednolity interfejs użytkownika dla
wszystkich obszarów funkcjonalnych, a funkcje powtarzające się w różnych Modułach
powinny być dostępne dla użytkownika pod taką samą nazwą w menu i pod takim samym
klawiszem skrótu, zapewniając w maksymalny sposób jednolitość obsługi."
Odwołujący zarzucał, że takie wymagania są nieuzasadnione i ograniczają
konkurencję poprzez organicznie technologii, przy czym ograniczenie takie w tym
konkretnym przypadku nie ma żadnego uzasadnienia funkcjonalnego ani technicznego.
Narzędzia raportujące mają inną zasadę działania i inne przeznaczenie niż reszta
systemu klasy ERP. Interfejs użytkownika systemu ERP służy do wyszukiwania
pojedynczych informacji oraz do wprowadzania pojedynczych informacji. Przykładowo
wyszukujemy konkretny dokument np. decyzję podatkową lub rejestrujemy konkretny
dokument, np. decyzję podatkową. Tymczasem moduł raportujący nie wyszukuje
konkretnego zapisu z bazy danych, a służy raczej zestawieniu wielu zapisów na
pojedynczym raporcie spełniających określone parametry i w żadnym stopniu nie służy do
wprowadzania jakichkolwiek danych. Zamiast wprowadzania danych musi umożliwiać
zarówno użytkownikom zaawansowanym, jak i zwykłym użytkownikom tworzenie definicji
raportów, a więc elementy projektowania i programowania. Dla narzędzi raportujących
zupełnie inaczej wygląda charakterystyka dostępu do danych - zawsze zakładają
wyszukanie i pobranie z bazy danych, a następnie zaprezentowanie użytkownikowi całego
zestawu danych, który pasuje do zadanych parametrów - np. wydruk decyzji podatkowych
dotyczących danej ulicy. Tymczasem pozostałe moduły systemu mają za zadanie
zaprezentowanie konkretnego rekordu, konkretnych danych i nawet w przypadku zapytania
dotyczącego decyzji podatkowych danej ulicy w interfejsie użytkownika nie są prezentowane
wszystkie decyzje, a jedynie co najwyżej ich paczka licząca kilka - więcej po prostu nie
zmieści się na ekranie. Dlatego w przypadku narzędzi innych niż Generator Raportów
strategią dostępu do danych jest strategia, która można określić jako „pokaż mi pierwszą
daną spełniającą warunki zapytania", tak w przypadku narzędzi raportujących strategia tą
można opisać stwierdzeniem „pokaż mi wszystkie dane spełniające warunki zapytania".
Biorąc pod uwagę powyższe normą dla największych i nowoczesnych biznesowych
rozwiązań informatycznych jest budowanie narzędzi raportujących w innej technologii i z
innym interfejsem użytkownika niż pozostałe moduły systemu. Takie podejście jest jak
najbardziej powszechne i racjonalne, ponieważ narzędzia raportujące służą do zupełnie
innych celów niż standardowe ekrany systemu ERP. Inne jest ich przeznaczenie, logika
działania, sposób dostępu do danych, optymalizacja zapytań. W zasadzie moduł raportujący
i pozostałe moduły różni wszystko. Zatem nie ma konieczności ani żadnego racjonalnego
uzasadnienia, aby narzędzia typu „Generator Raportów" były wykonane w tej samej
technologii co system główny (ERP). Żądanie Zamawiającego jest zatem zbędne,
technologicznie nieuzasadnione i ogranicza konkurencję, ponieważ eliminuje wykonawców,
który posiadają rozwiązanie typu Generator Raportów zbudowane w sposób racjonalny i
nowoczesny, ale wykonane w innej technologii. Spójność technologiczna ani jednolitość
interfejsu nie są warunkami skuteczności takiego narzędzia, którego rolą jest pozyskiwanie
danych z systemu ERP do celów analitycznych i ich odpowiednie przedstawienie
użytkownikowi. Zamawiający jeżeli chce otrzymać skuteczne narzędzie raportujące wręcz
powinien żądać, aby jego technologia i Interfejs użytkownika były zoptymalizowane do funkcji
jakie te narzędzia mają pełnić.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz poprzez usunięcie w/ w wymagania w całości lub wyłączenie z tego wymogu narzędzi
raportujących, tak by mogły one cechować się inną technologią oraz odmiennym Interfejsem
w stosunku do Systemu.
XI. Zarzut dotyczący otwartości kodu oprogramowania
Zamawiający określił w pkt i) Załącznika nr 1 do siwz (str. 3) następujące wymaganie:
„i. Oferowane rozwiązanie musi udostępniać w ramach opłaty licencyjnej dostęp do
otwartego kodu oprogramowania ".
Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione. Pojęcie „otwartego
kodu" używane jest do oprogramowania typu „Open Source”. Ponadto zgodnie z definicjami
stosowanymi przez Zamawiającego Kod Źródłowy odnosi się wyłącznie do Oprogramowania
Aplikacyjnego, czyli oprogramowania wytworzonego w toku wdrożenia, a nie do
standardowego systemu ERP - zgodnie z Załącznikiem nr 1 do siwz, str. 13:
„Kod źródłowy - oznacza pliki źródłowe, skrypty, biblioteki .dli i inne niestandardowe
narzędzia, niezbędne w procesie kompilacji l/lub konsolidacji Oprogramowana
Aplikacyjnego, a także strukturę baz danych i opis struktury baz danych, słowników, definicji
niezbędnych dla dalszego utrzymywania Systemu. Pliki te muszą być dostarczone w formie,
która nie wymaga deasemblacji ani dekompilacji i pozwala na ich modyfikację oraz
dokumentację/materiały/ Kod źródłowego"
„Oprogramowanie Aplikacyjne - oznacza, wykonane przez Wykonawcę rozbudowy
(przykładowo nowe moduły, warstwy, funkcjonalności) standardowego rozwiązania klasy
ERP, mające na celu dostosowanie standardowego rozwiązania klasy ERP do wymogów
Zamawiającego wraz z Interfejsami wymiany danych (m.in. WebService), wspierające
realizację zadań wynikających z przedmiotu zamówienia”.
Zdaniem Comarch nie jest do końca jasne w jakim kontekście Zamawiający użył
określenia „otwartego kodu". Jeżeli miał na myśli oprogramowanie typu „ Open Source", to
zasada dostępu do kodu źródłowego wynika z licencji użycia takich narzędzi i Zamawiający
nie może integrować w te zasady. Jeżeli Zamawiający miał na myśli, że dostarczone
rozwiązanie ma mieć dla niego „otwarty kod", to takie wymaganie może powodować
naruszenie ochrony praw autorskich producentów rozwiązania COTS, które zgodnie z
wymogami siwz jest obok Oprogramowania Aplikacyjnego, przedmiotem zamówienia
(Załącznik nr 1 do siwz str. 3: „k. Oferowane rozwiązanie powinno być zbudowane w oparciu
o standardowe rozwiązanie klasy ERP dostępne na rynku w wersji COTS (commerciai off-
the-sheif) przynajmniej od 10 lat, a w oferowanej wersji co najmniej rok.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz, przez zawężenie tego wymogu do Oprogramowania Aplikacyjnego.
XII. Zarzut dotyczący dostosowanie Oprogramowania Aplikacyjnego do zmian
wynikających z przepisów wewnętrznych
Zamawiający określił w pkt r) Załącznika nr 1 do siwz (str. 5) następujące wymaganie:
,,r) Dostosowanie Oprogramowania Aplikacyjnego do zmian wynikających ze zmian prawa
miejscowego - uchwały wydawane przez Radę Miejską, a także przepisów wewnętrznych np.
regulaminy, uchwały nie będące aktami prawa miejscowego, zarządzenia itp."
Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione i rodzi dla wykonawcy
poważne ryzyko realizacyjne i kosztowe. Przede wszystkim zaś powyższe wymaganie
uniemożliwia prawidłowe oszacowanie ceny oferty. Powyższy zapis umożliwia bowiem
Zamawiającemu w dowolnym momencie realizacji rozszerzyć zakres zamówienia. Nie
można bowiem wykluczyć możliwości, że wewnętrzne regulacje Zamawiającego doprowadzą
do rozszerzenia wymaganych funkcjonalności systemu informatycznego. Zawsze będzie
można stworzyć odpowiedni „regulamin", który przypadkiem zawierał będzie zapisy
wskazujące na konieczność wprowadzenia dowolnych, aktualnie potrzebnych
Zamawiającemu funkcjonalności. Tymczasem dostosowanie systemu do zmian w przepisach
prawa ma inny cel i inna funkcje: jest pochodna odpowiedzialności wykonawcy za zgodność
systemu z prawem, w tym prawem miejscowym. Rozszerzanie aktów normatywnych na
nikomu nieznane regulacje wewnętrzne (nie jest wykonawcy znane pojęcie „przepisu
wewnętrznego") stanowić może furtkę wymuszania na wykonawcy dokonywania istotnych
zmian systemu - pod pozorem dostosowywania ich do uregulowań normatywnych. W
zakresie dostosowania systemu do zmian w ustawodawstwie oraz aktach prawa
miejscowego uchwalanych przez organ stanowiący gminy zakłada się racjonalności ustawo i
uchwałodawcy. W przypadku wewnętrznych regulaminów i zarządzeń system prawny nie
wprowadza takiego domniemania. Tym bardziej, że formułując wymaganie Zamawiający w
ż
adnej sposób nie zawęził co stanowi przepisy wewnętrzne, używając zwrotów „np." oraz
„itp.". W ten sposób przepisem wewnętrznym może być wszystko, nawet dowolna decyzja
każdego z pracowników Zamawiającego.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz poprzez usunięcie z w/w wymagania słów: „a także przepisów wewnętrznych np.
regulaminy, uchwały nie będące aktami prawa miejscowego, zarządzenia Itp." oraz poprzez
wskazanie w siwz enumeratywnego katalogu uregulowań, tj. ustaw wraz z przepisami
wykonawczymi oraz uchwał organu stanowiącego gminy które będą objęte w/w
wymaganiem.
XIII.
Zarzut dotyczący czasów odpowiedzi systemu na działania operacyjne
użytkowników
Zamawiający określił w pkt 4.1.2.2. Załącznika nr 1 do siwz (str. 28-29) następujące
wymaganie:
„4.1.2.2. Zaproponowane rozwiązanie musi zapewnić następujące czasy odpowiedzi:
a.
ś
redni czas odpowiedzi przy transakcjach bez zapisu informacji do bazy
danych nie może przekraczać 5 sek., czas maksymalny 20 sek.;
b.
ś
redni czas odpowiedzi przy transakcjach z zapisem informacji do bazy
danych nie może przekraczać 10 sek., czas maksymalny 30 sek.;
c.
przez czas odpowiedzi rozumie się czas upływający od momentu wykonania
przez użytkownika na końcówce Systemu akcji wyzwalającej działanie
Systemu (naciśnięcie odpowiedniego do sytuacji klawisza lub kontrolki w oknie
aplikacji, itp.) do momentu uzyskania oczekiwanych wyników tej akcji na
końcówce użytkownika.
4.1.2.3. Wymagane czasy odpowiedzi z pkt. 4.1.2.2 nie dotyczą wykonywania raportów
okresowych, dla których maksymalny czas odpowiedzi nie może przekraczać 10 min."
Comarch wskazywał, że określony przez Zamawiającego w pkt. b wymagania 4.1.2.2
ś
redni i maksymalny czas odpowiedzi oraz w punkcie 4,1.2.3 maksymalny czas odpowiedzi
w powiązaniu z definicją czasu odpowiedzi w pkt. c) wymagania 4.1.2.2 jest nieracjonalny i
niemożliwy do uzyskania. Zdaniem Odwołującego Zamawiający, formułując takie
wymagania, nie wziął pod uwagę tzw. operacji masowych. Przykładowo w systemie będącym
przedmiotem zamówienia wystawia się decyzje podatkowe. Założenie, że wygenerowanie
pojedynczej decyzji nie może przekraczać 30s, a czas średni czas generacji nie może
przekraczać 10s jest jak najbardziej racjonalny. Jednak system podatkowy posiada nie tylko
operacje pojedyncza, ale również operacje masowe, np. wystawienie decyzji dla danej grupy
kartotek podatkowych. I taka operacja masowa, której uruchomienie odbywa się za pomocą
naciśnięcia odpowiedniej kontrolki, często może dotyczyć generacji kilku tysięcy decyzji. Nie
ma możliwości zapewnienia, aby operacja ta nie przekroczyła czasu 30s.
Podobnie w przypadku wymagania 4.1.2.3 zachowanie maksymalnego czasu 10 min,
dla operacji wydruku masowego, np. wydruku kilku tysięcy decyzji podatkowych, nie jest
możliwe do spełnienia. Tym bardziej, że czas ten zależy nie tylko od wydajności
oferowanego systemu, a również konfiguracji serwerów, sieci, jakości i konfiguracji urządzeń
drukujących, a wszystkie te elementy nie są przedmiotem zamówienia i zapewnia je
Zamawiający. Powyższe operacje masowe i wydruki masowe są jedynie przykładami, a
funkcjonalność systemu będącego przedmiotem zamówienia zawiera wiele tego typu
operacji.
Podsumowując powyższe Odwołujący zarzucał, że takie wymaganie jest
nieuzasadnione, ponieważ Zamawiający nie powiązał wymaganych reżimów czasowych z
liczbą wykonywanych przez użytkowników operacji, Jak również nie wyłączył z nich tzw.
operacji masowych, Czasy operacji powinny odnosić się do zakresu wykonywanych w
systemie prac, które muszą być docelowo wykonane i zakończone w podanym reżimie
czasowym, gdyż to jest Istotne z punktu widzenia organizacji pracy Zamawiającego. Należy
również podkreślić, że czasy poszczególnych operacji w systemie są zależne od wielu
elementów, nie tylko od konstrukcji i wydajności oferowanego systemu, ale również od liczby
użytkowników jednocześnie korzystających w danym momencie z systemu, jak również od
specyfikacji serwerów i parametrów sieciowych, ich konfiguracji, a elementy związane z
szeroko rozumianą platformą sprzętową nie należą do przedmiotowego postępowania i
zapewnia je Zamawiający, a zatem są one niezależne od wykonawcy.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz, przez usunięcie w/w wymagania w całości.
XIV. Zarzut dotyczący eksportu widoków ekranowych i raportów do wskazanych
formatów
Zamawiający określił w pkt 37 Załącznika nr 1 do siwz (str. 41) następujące
wymaganie:
„37. System musi zapewnić możliwość eksportu wszystkich widoków ekranowanych/
wygenerowanych raportów do formatów np. .txt, .xls, .doc z możliwością sortowania
raportów."
Odwołujący zarzuca, że takie wymaganie jest nieuzasadnione. Użycie zwrotu „np,"
skutkuje brakiem enumeratywnego wyspecyfikowania, co składa się na przedmiot
zamówienia, a tym samym zapis ten nie spełnia wymagań art. 29 ust. 1 ustawy.
Dodatkowo w zakresie eksportu widoków ekranowych do formatów DOC I XLS
Odwołujący podnosił, że są to formaty nie do końca otwarte, będące własnością firmy
Microsoft, a tym samym specyfikując takie formaty Zamawiający w sposób nieuzasadniony
preferuje rozwiązania dostarczane lub budowane przez firmę Microsoft. Ponadto eksport
widoków ekranowych dotyczy eksportu do pliku surowych danych w celu ich dalszej obróbki.
Dane w sformatowanym i narzuconym układzie otrzymuje się za pomocą raportów
generujących określone zestawienia i dokumenty z wykorzystaniem predefiniowanych
szablonów. Wymóg eksportu danych z wszystkich widoków ekranowych oznacza
konieczność zapisania w pliku surowych danych (inaczej mówiąc wartości poszczególnych
pól widoku ekranowego). Formaty DOC i XLS są formatami natywnymi narzędzi MS Word
oraz MS Excel. Są również obsługiwane (czytane) przez inne oprogramowanie biurowe np.
OpenOffice. Jednak konieczność eksportu widoków ekranowych do tych formatów jest
nadmiarowa, ponieważ każde z narzędzi obsługujących format DOC, czy XLS jest w stanie
obsługiwać również format TXT- tak samo dobrze i skutecznie.
Podobnie w przypadku konieczności eksportu wygenerowanych raportów do
formatów DOC i XLS żądanie Zamawiającego jest nadmiarowe, nieuzasadnione I preferuje
jedno konkretne rozwiązanie firmy Microsoft.
Również w przypadku raportów eksport surowych danych do formatu TXT jest
wystarczający. Ponadto, jeżeli Zamawiający chciałby eksportować raporty stanowiące
dokumenty do formatu pozwalającego na edycję przez użytkownika to w ramach wymagania
4.2.27, pkt. 19 (Załącznik nr 1 do siwz str. 39) Zamawiający zapewnił sobie, że raporty
tworzone przy użyciu Generatora Raportów musza mieć możliwość zapisu do pliku min. w
formacie RTF. Format RTF w przeciwieństwie do formatu DOC jest formatem otwartym i jest
akceptowany (czytany) przez wszystkie edytory obsługujące format DOC, a ponadto przez
wiele innych narzędzi, które obsługują format RTF, a nie obsługują formatu DOC.
Przy czym Odwołujący nie kwestionuje konieczności stosowania w dostarczonym
Systemie eksportu do formatów XLS i DOC, a jedynie nieuzasadniony wymóg eksportu
wszystkich widoków ekranowych i raportów do formatów XLS. DOC. w przypadku gdy
eksport do formatu TXT test wystarczający I nie ogranicza konkurencji przez preferowanie
rozwiązań budowanych przez lub w technologii Microsoft.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz, przez usunięcie zwrotu „np." oraz usunięcie formatów„.xls, ,doc".
XV.
Zarzut dotyczący niewskazania miejsca wykonania wdrożenia
Zamawiający określił w pkt 2 Załącznika nr 1 do siwz (str, 1) następujące wymaganie:
„2. Miejsce wykonania: w Lokalizacjach Zamawiającego"
Odwołujący zarzucał, że takie wymaganie jest nieprecyzyjne. Zamawiający nie
określił w jakich lokalizacjach będzie odbywać się wdrożenie. Nie można wykluczyć sytuacji,
w której Zamawiający posiada np. ośrodki wczasowe poza miastem - siedzibą
Zamawiającego - i będzie oczekiwał przeprowadzenia np. szkoleń użytkowników w tych
ośrodkach co znacząco wpływa na wycenę tych szkoleń (z powszechnie dostępnych danych
wynika, że Zamawiający posiada np. ośrodek w Zakopanym).
W związku z powyższym Odwołujący wnosi o nakazanie Zamawiającemu modyfikacji
siwz, przez doprecyzowanie lokalizacje i określenie ich w sposób enumeratywny.
XVI. Zarzut dotyczący niespójności w zakresie licencji
Zamawiający określił w pkt h) Załącznika nr 1 do siwz (str. 3) następujące
wymaganie:
„h. Licencje dostarczone dla oferowanego rozwiązania muszą umożliwiać obsługę
nieograniczonej liczby jednostek organizacyjnych"
Odwołujący zarzucał, że takie wymaganie jest niejasne. Wymaganie ma charakter
„otwarty" i uniemożliwia przygotowanie wyceny oferty. Ponadto jest sprzeczne z zapisem o
500 licencjach, które Zamawiający może zakupić w ramach Opcji - zgodnie z Załącznikiem nr
1 do SIWZ str. 150 pkt. 2 a) Zamawiający ma prawo „zakupić dodatkowe licencje dla
standardowego rozwiązania klasy ERP maksymalnie 500 licencji'.
W związku z powyższym Odwołujący wnosi o nakazanie Zamawiającemu modyfikacji
siwz poprzez usunięcie wymagania.
XVII. Zarzut dotyczący harmonogramu wdrożenia
Zamawiający określił w pkt 1.1.2. „Etapowanie prac" dokumentu „Załącznik nr 1 do
SIWZ" (str. 8-10) następujące wymaganie:
„ETAP I- do 4 miesięcy od daty podpisania Umowy (...)
ETAPU do 2 miesięcy od daty zakończenia ETAPU I(...)
ETAP III do 12 miesięcy od daty zakończenia ETAPU II (...)
ETAP IV- do 6 miesięcy od daty zakończenia ETAPU III (odbiór i rozpoczęcie pełnej
eksploatacji Systemu) (...)
ETAP V – od zakończenia ETAPU IV do końca Umowy (..)"
oraz Zamawiający określił w pkt 3 „Ograniczenia" dokumentu Załącznik nr 1 do SIWZ
(str. 26) następujące wymaganie:
„W poszczególnych obszarach objętych projektem mogą wystąpić ograniczenia
dostępności zasobów po stronie Zamawiającego wynikające z terminów realizacji zadań
ustawowych. Powyższe ograniczenia zostaną doprecyzowane w Projekcie Rozwiązania."
Odwołujący zarzucał, że takie wymaganie uniemożliwia wdrożenie przedmiotu
zamówienia w takim reżimie czasowym. Uwzględniając powyższe dane należy stwierdzić, że
Zamawiający założył w ramach Etapu II i IIII [czyli łącznie 14 miesięcy] objęcie pełnym
wdrożeniem [w zakresie funkcjonalności oznaczonych priorytetem 1, stanowiących
zdecydowaną większość w wymagania funkcjonalnych OPZ] ponad kilkadziesiąt jednostek
organizacyjnych.
Zdaniem Comarch realizacja tak złożonego wdrożenia i w tak wielu jednostkach
organizacyjnych nie jest możliwa w perspektywie 14 miesięcy założonych harmonogramie
prac przez Zamawiającego. Wdrożenie systemów klasy ERP jest procesem złożonym, który
wymaga dużego zaangażowania zasobów po obu stronach, zarówno Wykonawcy jak i
Zamawiającego. Przy tak znaczącej liczbie zadań wdrożeniowych jak zakreślono w siwz,
nawet w przypadku zastosowania prekonfigurowanego rozwiązania ERP, w ocenie
Odwołującego wdrożenie w terminach wskazanych przez Zamawiającego i przy
jednoczesnym pierwotnym założeniem ograniczeń w dostępności zasobów po stronie
Zamawiającego nie jest zadaniem możliwym do wykonania.
Ponadto Etap II musi się zakończyć do 2 miesięcy po zakończeniu Etapu I.
Równocześnie w ramach etapu II należy dokonać wdrożenia funkcjonalności objętych
wymaganiami z priorytetem 1 w obszarze budżetowo- księgowym w zakresie planowania w
UMŁ i 10 jednostkach podległych. Aby dokonać realizacji (wdrożenia) należy wykonać co
najmniej następujące prace: zainstalować standardowy System COTS, dokonać jego
dostosowania do potrzeb Zamawiającego, dokonać integracji z Systemami Zamawiającego,
dokonać migracji przeniesienia danych z systemów źródłowych do rozwiązania docelowego
(testowej i produkcyjnej), przeprowadzić szkolenia testerów, przeprowadzić testy
akceptacyjne rozwiązania, przeprowadzić szkolenia użytkowników. Te wszystkie zadania
poza instalacją standardowego rozwiązania COTS można realizować dopiero po
zakończeniu Etapu I, a więc po opracowaniu i odebraniu (zaakceptowaniu) przez
Zamawiającego Projektu Rozwiązania. W ramach prac objętych Etapem I (zgodnie z
zapisami Załącznika nr 1 do siwz str. 8): „ Wykonawca przeprowadzi prace analityczne
związane m.in. z analizą i przygotowaniem sposobu realizacji prac objętych zamówieniem, a
w szczególności dotyczących: projektu technicznego i logicznego Rozwiązania, wymagań
funkcjonalnych, migracji i standaryzacji danych, integracji systemu." Biorąc pod uwagę
powyższe zapisy wykonawca ma na wszystkie prace w ramach Etapu II jedynie 2 miesiące.
Równocześnie Zamawiający nie określił liczby użytkowników do przeszkolenia z
poszczególnych obszarów w poszczególnych jednostkach. Tym samym nie przedstawił
rozmiaru prac jakie są do realizacji w ramach 2 miesięcy (Etapu II).
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz przez
•
wydłużenie terminu wdrożenia Etapów II i III odpowiednio o dodatkowe 3
miesiące i dodatkowe 3 miesiące [czyli łącznie dodatkowe 6 miesięcy],
•
wprowadzenie zapisu, iż ograniczenia po stronie Zamawiającego nie mogą
wywoływać wobec Wykonawcy negatywnych konsekwencji, w tym
Wykonawca nie ponosi odpowiedzialności z tytułu kar umownych na
niedotrzymanie terminów wynikających z umowy z uwagi na te ograniczenia.
XVIII. Zarzut dotyczący kosztów szkoleń
Zamawiający określił w pkt d) w Załącznik nr 1 do siwz (str. 129) następujące
wymaganie:
,,d) Wykonawca zobowiązany jest do zorganizowania i pokrycia wszelkich kosztów
związanych z przeprowadzeniem szkoleń.
Odwołujący zarzucał, że takie wymaganie jest niedoprecyzowane. Zamawiający nie
wskazał co rozumie przez zorganizowanie i pokrycie wszelkich kosztów związanych z
przeprowadzeniem szkoleń, a pozycja ta z uwagi na bardzo znaczącą liczbę użytkowników
do przeszklenia [kilkaset osób] może być wielkością znaczącą w cenie oferty. Zapis w
obecnym brzmieniu nie pozwala ocenić co wchodzi w koszt szkoleń pokrywanych przez
wykonawcę np. koszt wynajmu sal szkoleniowych, koszt wynajmu stacji roboczych, koszt
organizacji przerw kawowych i lunchu, koszt przejazdów uczestników szkoleń, itp. w
szczególności z uwagi na brak wymagań Zamawiającego w tym zakresie,
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz, przez podanie enumeratywnie jakie konkretnie koszty musi pokryć wykonawca [koszt
wynajmu sal szkoleniowych, koszt wynajmu stacji roboczych, koszt organizacji przerw
kawowych i lunchu, koszt przejazdów uczestników szkoleń, itp.].
XIX. Zarzut dotyczący szkoleń administratorów
Zamawiający określił w pkt 6.6.3 Załącznika nr 1 do siwz (str. 133) następujące
wymaganie:
„6.6.3. W przypadku wykorzystania przez Wykonawcę Innego rozwiązania szyny
usług/danych, szkolenie również powinno być przeprowadzone w certyfikowanych ośrodkach
szkoleniowych".
Odwołujący zarzucał, że takie wymaganie jest niedoprecyzowane. Zamawiający nie
wskazał ilu administratorów ma zostać przeszkolonych w przypadku zaoferowania „innego
rozwiązania szyny usług/danych", ani nie potwierdził, że liczba ta jest analogiczna (tzn.
dwóch administratorów) jak dla przypadku szkoleń z posiadanej przez Klienta „Oracle SOA
Suitę".
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz przez doprecyzowanie ilu administratorów ma zostać przeszkolonych z zakresu „innego
rozwiązania szyny usług/danych".
XX.
Zarzut dotyczący zestawienia jednostek objętych projektem i zakresu
funkcjonalnego
Zamawiający w załączniku nr 2 przedstawił w formie tabeli wykaz jednostek objętych
projektem. Odwołujący zarzucał, że takie zestawienie jest niedoprecyzowane. Zamawiający
nie zamieścił żadnej legendy, wyjaśnienia które pozwoliłoby wykonawcom zrozumieć intencje
Zamawiającego w zakresie oznaczenia kolorami: białym, żółtym, czerwonym i czarnym
komórek zestawienia Excel, prezentującego podmioty objęte projektem oraz zakres
funkcjonalny wdrożenia w kontekście wpływu tego podziału na proces przygotowania oferty i
wykonania zamówienia. Nie sposób zatem jednoznacznie i obiektywnie zinterpretować
przedmiotowego zestawienia - a jest ono kluczowe dla określenia złożoności projektu i
oszacowania kosztu wdrożenia.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz poprzez doprecyzowanie w siwz [Załącznik nr 2] znaczenia kolorów wykorzystanych w
tabeli, to jest w jakich jednostkach i w jakim zakresie wykonawca ma wykonać wdrożenie.
XXI. Zarzut dotyczący liczby jednostek objętych projektem
Zamawiający przedstawił w siwz Załącznik nr 2 [plik 2115_zalacznik_siwz_2016-01-
29_2]. Odwołujący zarzucał, że takie zestawienie jest niedoprecyzowane. Zamawiający nie
wyspecyfikował jednostek, które wchodzą w skład pozycji: „II MJO - PLACÓWKI
OŚWIATOWE", tak jak to uczynił dla pozycji „III MJO" oraz „IV MJO - PLACÓWKI OPIEKI
SPOŁECZNEJ".
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz przez:
•
wskazanie w siwz enumeratywnej listy placówek oświatowych wskazanej w
wierszu II,
•
wyjaśnienie w siwz czy podmioty wskazane w zestawieniu Załącznika nr 2 to
licencjobiorcy?
XXII. Zarzut dotyczący migracji
Zamawiający przedstawił w Załączniku nr 5 [plik 2115_zalacznlk_siwz_2016-01-29_5]
dwa zestawienia w zakładkach pliku Excel:
•
Zakładka „ZFM-systemy w MJO",
•
Zakładka „ZFM-zakres migracji".
Odwołujący zarzucał, że przedmiotowe zestawienia są niedoprecyzowane. Na
zakładce „ZFM-zakres migracji" Zamawiający nie przedstawił kompletnej informacji, która
powinna być wyspecyfikowana zgodnie z nagłówkami kolumn. Zestawienie w zakładce
„ZFM-systemy w MJO" cechuje informacja różnej jakości. Pomimo nadania przez
Zamawiającego trzeciej kolumnie przedmiotowego zestawienia nazwy „Nazwa i producent
aktualnie eksploatowanego systemu. Technologia” dla wielu pozycji informacje są
niekompletne, a w szczególności nie zawierają informacji na temat producenta i technologii.
Zdaniem Comarch oba zestawienia zaprezentowane w zakładce „ZFM-systemy w
MJO" mają charakter niespójny, chaotyczny i niekompletny. Należy zaznaczyć, że
zestawienia tabelaryczne dotyczą bardzo ważnego i kosztochłonnego aspektu wdrożenia
jakim jest migracja danych. Ma to szczególne znaczenie w świetle treści pkt. 5. „Migracja
danych" ppkt. c) z Załącznika nr 1 do siwz [str. 119], gdzie Zamawiający podkreślił m.in. rolę
informacji na temat technologii systemów posiadanych przez Zamawiającego, ponieważ
dane źródłowe dla celów migracji będą w formatach zgodnych z formatem baz danych
obecnie funkcjonujących lub w formacie możliwym bezpośrednio do uzyskania z obecnie
funkcjonujących aplikacji.
,,c) Wykonawca przy współpracy z Zamawiającym przygotuje Dane Źródłowe w
formatach zgodnych z formatem baz danych obecnie funkcjonujących lub w formacie
możliwym bezpośrednio do uzyskania z obecnie funkcjonujących aplikacji, według stanu na
dzień wskazany w Harmonogramie w Projekcie Rozwiązania;
Uwaga! Zamawiający zobowiązuje się udostępnić Dane Źródłowe w formatach
zgodnych z formatem baz danych obecnie funkcjonujących systemów oraz dokumentację
będącą w posiadaniu Zamawiającego, w zakresie w jakim dokumentacja ta może zostać
udostępniona Wykonawcy;"
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz przez:
•
uzupełnienie tabeli w zakładce „ZFM-systemy w MJO" o kompletne informacje
odpowiadające nagłówkom kolumn,
•
uzupełnienie tabeli w zakładce „ZFM-zakres migracji" o informacje
zapewniające spójność z danym przedstawionymi w tabeli z zakładki „ZFM-
systemy w MJO",
•
wprowadzenie
do
siwz
oświadczenia
Zamawiającego,
ż
e
rolą/odpowiedzialnością Zamawiającego jest zapewnienie jakości danych
podlegających migracji.
XXIII. Zarzut dotyczący technologii - przechowywanie plików typu: skan
Zamawiający określił w pkt 4.2.14 oraz 4.2.15 Załącznika nr 1 do siwz (str. 30-31)
następujące wymaganie:
„4.2.14. Wszystkie dane zgromadzone w Systemie powinny być przechowywane w
wspólnej bazie danych z wyłączeniem plików z załącznikami, które muszą być
przechowywane w systemie plikowym serwera aplikacyjnego. Zamawiający nie zaakceptuje
rozwiązania, w którym obiekty (np. skany dokumentów jako załączniki itp.) są
przechowywane w bazie danych w polach typu BLOB.
4.2.15. Załączniki, skany dokumentów itp. muszą być umieszczane na dyskach
serwera aplikacyjnego jako pliki. Wykonawca musi zaproponować sposób katalogowania
tych materiałów na dyskach tak, aby ograniczenia systemu operacyjnego nie miały wpływu
na zarządzanie plikami."
Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione, ponieważ ogranicza
konkurencję. Funkcjonujące na rynku systemy ERP w alternatywny sposób rozwiązują
zagadnienie związane z przechowywaniem obiektów typu skan dokumentu bezpośrednio w
bazie danych. Tymczasem Zamawiający w nieuzasadniony sposób, poprzez sformułowanie
negatywne ograniczył konkurencje: „Zamawiający nie zaakceptuje rozwiązania, w którym
obiekty (np. skany dokumentów jako załączniki itp.) są przechowywane w bazie danych w
polach typu BLOB.
Zdaniem Odwołującego takie ograniczenie nie jest uzasadnione, ponieważ można
wykazać, że przechowywanie załączników dokumentów w strukturach bazy danych jest
rozwiązaniem bezpieczniejszym i bardziej niezależnym od technologii (co jest dla jednostki
budżetowej korzystniejsze) niż składowanie ich w systemie operacyjnym. Przechowywanie
załączników w systemie plików uzależnia System od konkretnego systemu plików, a więc
często od konkretnego systemu operacyjnego. Powoduje, że każda z osób uzyskująca
dostęp do katalogu, w którym zapisano pliki ma dostęp do wszystkich plików i często (w
zależności od systemu operacyjnego) nie da się definiować uprawnień do poszczególnych
plików I załączników. Ponadto wymagane jest objęcie struktury katalogów przechowujących
takie pliki dodatkowymi zadaniami tworzenia kopii zapasowych, będących zabezpieczeniem
przed utratą danych w przypadku awarii.
Wszystkich tych wad pozbawione jest rozwiązanie przechowywania plików w bazie
danych. To właśnie min. dla takich zastosowań producenci baz danych umożliwili
składowanie plików w bazie danych w kolumnach typu BLOB. Funkcjonalność systemu
bazodanowego umożliwia udostępnianie poszczególnym użytkownikom systemu dostępu nie
tylko na poziomie struktury (tabeli) przechowującej dane, ale również do poszczególnym
rekordów - w tym przypadku do poszczególnych załączników - skanów, przechowywanych w
bazie danych. Ponadto załączniki te są zabezpieczone przed utratą za pomocą
mechanizmów realizacji kopii bazy danych.
Współczesne systemy zarządzania bazą danych pozwalają na optymalizację dostępu
do danych typu BLOB, w sposób nie gorszy niż składowanie ich w systemie plików. Zdaniem
Odwołującego nie ma więc uzasadnienia do traktowania przechowywania plików w polach
BLOB jako rozwiązania gorszego.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
SIWZ poprzez usunięcie w/w wymagania.
XXIV. Zarzut dotyczący technologii - narzędzie do raportowania
Zamawiający określił w pkt 19 dokumentu Załącznik nr 1 do siwz (str. 39) następujące
wymaganie: „19. Generator raportów:
System powinien umożliwiać tworzenie nowych raportów lub modyfikowanie
standardowych ustawień istniejących raportów w sposób przyjazny dla użytkownika.
Wymagana jest: (...)
- przedstawienie zbiorów danych w formie rozwijanych list do wyboru (...)
- przedstawienie list pól danej tabeli w formie rozwijanych list do wyboru (...)"
Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione, ponieważ ogranicza
konkurencję, a w różnych narzędziach raportujących dostępnych na rynku taka
funkcjonalność może być zrealizowana w inny sposób. W ocenie Odwołującego do realizacji
wskazanych wymagań można użyć innych, alternatywnych kontrolek Interfejsu GUI (a nie
tylko list rozwijanych), których w żadnym przypadku nie można uznać jako rozwiązań
gorszych od wymaganych przez Zamawiającego. Tak sformułowane wymaganie sprawia,
stwarza możliwość preferowania tylko jednego z rozwiązań istniejących na rynku.
Zdaniem Odwołującego wystarczające byłoby wymaganie - bez wskazywania
konkretnego sposobu realizacji, typu:
przedstawienie zbiorów danych w formie listy do wyboru (...)
przedstawienie listy poi danej tabeli do wyboru (...)
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz poprzez usunięcie w/w wymagania.
XXV. Zarzut dotyczący odpowiedzialności za koszty wdrożenia
Zamawiający określił w pkt 4.2.1 dokumentu Załącznik nr 1 do siwz (str. 29)
następujące wymaganie:
„4,2.1. Wszelkie koszty związane z realizacją przedmiotu zamówienia ponosi
Wykonawca."
Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione, ponieważ może
sugerować, że wykonawca powinien uwzględnić w swojej ofercie również koszty nakładów
koniecznych do poniesienia po stronie Zamawiającego, w związku z udziałem
Zamawiającego w realizacji projektu [np. koszty zużycia mediów w pomieszczeniach
Zamawiającego, koszty wynagrodzeń pracowników Zamawiającego oddelegowanych do
udziału we wdrożeniu po stronie Zamawiającego, itp.].
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz przez zmianę wymagania na brzmienie: „Wszelkie koszty związane z realizacją
zobowiązań wykonawcy opisanych w siwz ponosi wykonawca. Wykonawca nie ponosi
kosztów nakładów koniecznych do poniesienia po stronie Zamawiającego w związku z jego
udziałem w realizacji umowy."
XXVI. Zarzut dotyczący niespójnej nomenklatury pojęć stosowanych w siwz
Zamawiający określił w pkt 1.2. „Przyjęte definicje" dokumentu Załącznik nr 1 do siwz
(str. 11-15) następujące definicje:
•
„Kod źródłowy oznacza pliki źródłowe, skrypty, biblioteki .dll i inne
niestandardowe narzędzia, niezbędne w procesie kompilacji i/lub konsolidacji
Oprogramowana Aplikacyjnego, a także strukturę baz danych i opis struktury
baz danych, słowników, definicji niezbędnych dla dalszego utrzymywania
Systemu. Pliki te muszą być dostarczone w formie, która nie wymaga
deasemblacji ani dekompilacji i pozwala na ich modyfikację oraz
dokumentację/materiały Kod źródłowego;
•
Moduł - oznacza Produkt odrębny pod względem: instalacji, funkcjonalnym lub
konfiguracyjnym stanowiący część Systemu
•
Oprogramowanie - oznacza łącznie: oprogramowanie systemowe,
bazodanowe, narzędziowe lub ogólnego przeznaczenia; oprogramowanie
systemowe dostarczone przez Wykonawcę w Rozwiązaniu o ile jest ono
konieczne do realizacji przedmiotu zamówienia. Obejmuje system operacyjny,
zarządzanie systemem i siecią, standardowe rozwiązania klasy ERP oraz
oprogramowanie diagnostyczne; oprogramowanie bazodanowe oznacza silnik
bazy danych i narzędzia do zarządzania bazą danych; oprogramowanie
narzędziowe obejmuje narzędzia programistyczne służące do budowy,
kompilacji, modyfikacji, przystosowywania i uruchamiania Oprogramowania
Aplikacyjnego, w szczególności narzędzia typu CASE, narzędzia zarządzania
bazą danych, kompilatory, interpretatory; oprogramowanie ogólnego
przeznaczenia obejmuje m.in. edytor tekstu, arkusz kalkulacyjny, itp.;
•
Oprogramowanie Aplikacyjne - oznacza, wykonane przez Wykonawcę
rozbudowy
(przykładowo
nowe
moduły,
warstwy,
funkcjonalności)
standardowego rozwiązania klasy ERP, mające na celu dostosowanie
•
standardowego rozwiązania klasy ERP do wymogów Zamawiającego wraz z
interfejsami wymiany danych (m.in. WebService), wspierające realizację
zadań wynikających z przedmiotu zamówienia;
•
Rozwiązanie - oznacza System funkcjonujący na infrastrukturze
teleinformatycznej Zamawiającego wykorzystywanej przez System;
• System - to część Rozwiązania, oznacza wszystkie przewidziane Umową
Produkty, dostarczone, zainstalowane, zintegrowane, wdrożone"
Odwołujący zarzuca, że w całej dokumentacji siwz Zamawiający posługuje się w/w
definicjami w sposób niespójny i niezrozumiały. Dodatkowo Zamawiający niezależnie od w/w
definicji wprowadza ich nowe znaczenia. Przykładowo w Załączniku nr 1 do SIWZ na str. 37
w pkt. 1 pojęcie „Systemu" sugeruje, że Zamawiający zawęża je do „systemu ERP", a jeśli
posłużymy się definicją z pkt. 1.2. „Przyjęte definicje" z Załącznika nr 1 do SIWZ, to „system
ERP" miałaby obejmować również m. in. bazę danych:
„1. System musi być standardowym rozwiązaniem zintegrowanym klasy ERP
(Enterprises Resource Planning), dostosowanym do wymagań Zamawiającego, w którym te
same informacje są wprowadzane tylko raz i udostępniane we wszystkich miejscach
Systemu, w których są wymagalne bez konieczności przechodzenia pomiędzy rejestrami
Systemu w celu wyszukania informacji powiązanych."
Zamawiający w wielu miejscach OPZ posługuje się zwrotem „Oprogramowanie
Aplikacyjne" sugerującym, że jest to synonim „systemu ERP". Na przykład w Załączniku nr 1
do siwz str. 37-38 [Wymagania ogólne] oraz pkt. 4.3. na str. 41 [Administracja Systemem -
uprawnienia i role] z kontekstu wynika, że Zamawiający przedstawia wymagania odnoszące
się do systemu ERP, natomiast posługuje się zamiennie zwrotem „System" i
„Oprogramowanie Aplikacyjne. W efekcie część wymagań dla których Zamawiający używa
zwrotu „Oprogramowanie Aplikacyjne", w świetle definicji z pkt. 1.2. „Przyjęte definicje" z
Załącznika nr 1 do siwz jest niezrozumiała i może być różnie interpretowana.
Na przykład - zgodnie z Załącznikiem nr 1 do siwz pkt. 4 str. 37:
„4. Polskojęzyczność Oprogramowania Aplikacyjnego powinna być realizowana przez
stosowanie języka polskiego w komunikatach, w tym w opisach w systemach pomocy,
etykietach na formatkach ekranowych, wprowadzanych danych, wydrukach, itp."
Powyższy zapis sugeruje, że system ERP może posiadać inny niż polskojęzyczny
Interfejs, a jedynie Oprogramowanie Aplikacyjne [czyli wykonane przez Wykonawcę w
ramach rozbudowy standardowego systemu ERP] musi cechować polskojęzyczność.
Podobne uwaga odnosi się do administrowania systemem, np. zgodnie z
Załącznikiem nr 1 do siwz pkt, 45 str. 41:
„45. Oprogramowanie Aplikacyjne musi zapewniać autentykację z wykorzystaniem
ś
rodowiska Active Directory, udostępnionym przez Zamawiającego"
Literalnie odczytując wymaganie, to jedynie element zamówienia związany z
rozbudową systemu ERP [czyli Oprogramowanie Aplikacyjne] musiałby zapewniać w/w
autentykację, a z kontekstu OPZ wynika, że intencją Zamawiającego jest wprowadzenie
takiego wymagania dla całego systemu ERP.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz przez weryfikację każdego z wymagań względem przedmiotu zamówienia pod kątem
prawidłowość! użycia definicji „System", „Oprogramowanie", „Oprogramowanie Aplikacyjne"
itd. oraz ujednolicenie treści wymagań, tak aby były spójne z nomenklaturą pojęciową
zdefiniowaną w punkcie pkt. 1.2. „Przyjęte definicje" z Załącznika nr 1 do siwz i we wzorze
Umowy [plik 2115_załacznik_siwz_2016-01-29_8].
XXVII. Zarzut dotyczący prac dodatkowych, w szczególności dodatkowej integracji
Systemu
Zamawiający określił w pkt h) Załącznika nr 1 do siwz (str. 5) następujące
wymaganie:
,,h) Integrację Systemu z pozostałymi elementami funkcjonującymi u Zamawiającego"
oraz Zamawiający określił w pkt 4.6. „Integracja" dokumentu Załącznik nr 1 do SIWZ (str. 98)
następujące wymaganie:
„System musi być zintegrowany z poniższymi systemami (wykaz systemów do integracji
zostanie zweryfikowany i uzupełniony w trakcie opracowania Projektu Rozwiązania) w
zakresie opisanym w Projekcie Rozwiązania.
Uwaga! Jeżeli w trakcie prac nad Projektem Rozwiązania konieczne będzie uwzględnienie
integracji z innymi systemami niż wymienione poniżej w wymaganiu nr 568, Zamawiający
zleci integrację w ramach prac dodatkowych."
oraz Zamawiający określił w pkt 9. „Prace dodatkowe" ppkt. d) dokumentu Załącznik nr 1 do
SIWZ (str. 141-142) następujące wymaganie:
„Wykonawca w ramach prac dodatkowych zobowiązany jest do świadczenia usług w łącznej
ilości 9000 osobogodzin do: (...) d. integracji z innymi systemami niż wymienione w pkt.
Integracja".
Odwołujący zarzucał, że takie wymaganie jest niedoprecyzowane. Prace dodatkowe
wpływają na realizację zakresu podstawowego, a Zamawiający nie uregulował kwestii
prawno-organizacyjnych dotyczących procedury zlecania prac dodatkowych i Ich odbioru.
Ponadto treść pkt. 4.8 z § 4 Umowy wskazuje, że w ramach prac dodatkowych będą
realizowane prace składające się na podstawowy przedmiot zamówienia, a przecież
niedopuszczalne jest dwukrotne wycenianie tych samych prac, a także nie powinien być
wykonywany podstawowy zakres SIWZ z połączeniu z pracami dodatkowymi.
4.8. W ramach prac dodatkowych, o których mowa w ust. 4.7, Wykonawca może
wykonać dodatkowe Modyfikacje, szkolenia, konsultacje nie objęte asystą techniczną a takie
inne prace zlecone przez Zamawiającego, a także prace wymienione w Załączniku nr 1 -
„Opis Przedmiotu Zamówienia".
Zdaniem Comarch brak stosownych regulacji i precyzyjnych zapisów dotyczących
prac dodatkowych uniemożliwia wycenę przedmiotu zamówienia oraz dokonanie przez
wykonawcę oceny możliwości realizacji projektu w określonych ramach czasowych.
Wykonanie prac dodatkowych nie może wpływać na. wykonanie i odbiór zakresu
podstawowego opisanego w OPZ.
W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji
siwz przez
•
usunięcie z § 4 Umowy pkt. 4.8 zwrotu „a także prace wymienione w
Załączniku nr 1- Opis Przedmiotu Zamówienia”,
•
wprowadzenie zapisu, iż wykonanie prac dodatkowych nie może wpływać na
wykonanie i odbiór zakresu podstawowego opisanego w OPZ,
•
uregulowanie procedurą zlecania prac dodatkowych i ich odbioru.
XXVIII.
Zarzut dotyczący kryterium oceny ofert pn. JAKOŚĆ - waga 20%
Zamawiający w siwz jako jedno z kryterium oceny ofert zastosował kryterium Jakość",
które zostało opisane na stronie 21 w pkt 13.8. Jest to jedno z siedmiu poniższych kryteriów:
Lp.
Kryterium
Znaczenie
procentowe
kryterium
Maksymalna ilość punktów jakie może
otrzymać oferta za dane kryterium
Cena oferty brutto (C)
30 punktów
Prace dodatkowe (cena za
osóbogodzinę) (PD)
4 punkty
Wydłużenie gwarancji (o kolejny
miesiąc) (WG)
2 punkty
Wydłużenie asysty technicznej (o
kolejny miesiąc) (WAT)
2 punkty
Koszt dodatkowej licencji (KDL)
2 punkty
Stopień gotowości Systemu do
wdrożenia (SGSW)
40 punktów
Jakość (J)
20 punktów
Łącznie
100 punktów
Odwołujący zwracał uwagę, iż zgodnie z opisem, który znajduje się w pkt 13.8 ocena
ofert w ramach powyższego kryterium „dokonana zostanie przez członków merytorycznych
komisji przetargowej na podstawie indywidualnej karty oceny prezentacji. Karta indywidualnej
oceny prezentacji stanowi załącznik do niniejszego sposobu oceny ofert. Oferta otrzyma
zaokrągloną do dwóch miejsc po przecinku ilość punktów wynikającą z działania".
W/w indywidualna karta oceny zawiera następujące elementy podlegające ocenie,
określone jako „wymagania":
INDYWIDUALNA OCENA PREZENTACJI
Lp
Wymaganie
Definicja - co podlega ocenie
Ocena
1 pkt
2 pkt
3 pkt
4 pkt
Wygląd aplikacji
czytelność / przejrzystość
szata graficzna
/ układ pól na ekranie
Intuicyjność w
zakresie obsługi
chronologia działań
J
logiczne działania
Złożoność
wprowadzania
danych/wykonywania
poleceń
liczba operacji do uzyskania ‘wyniku
czy
system uwzględnia skróty klawiszowe
Nazewnictwo
Język zrozumiały dla użytkownika np.: czy
opis pól jest adekwatny do modułu; czy
stosowane skróty są zrozumiałe
Pomoc dla
użytkownika z
poziomu aplikacji
łatwość wyszukiwania informacji / zawiera
ścieżki postępowania
Odwołujący twierdził, że określenie tak opisanego kryterium jako „jakość" stanowi
jawne nadużycie. Jego istota - ujawniona poprzez 5 doprecyzowanych „wymagań" -
sprowadza się do oceny estetyczno - „wyglądowej" i ergonomicznej. Zarówno z językowego
punktu widzenia, jako i z uwagi na specjalistyczny charakter próbki należy stwierdzić, iż
powyższe podkryteria, czy też wymagania, nie mają nic wspólnego z jakością systemu jako
dzieła stanowiącego oprogramowanie komputerowe. Normy ISO definiują jakość jako „ogół
cech I właściwości wyrobu lub usługi decydujących o zdolności wyrobu do zaspokojenia
stwierdzonych lub przewidywanych potrzeb" [PN-ISO 8402:1994 1996, s. 12]. Słownik języka
polskiego przedstawia definicję jakości jako „właściwość, rodzaj, gatunek, wartość; zespół
cech stanowiących o tym, że dany przedmiot jest tym przedmiotem, a nie innym" [Słownik
języka polskiego, 2002, t. I, s. 769]. Zdaniem Comarch powyższych „wymogów" nie można
uznać za kryterium jakościowe - co eliminuje użycie tak doprecyzowanego kryterium w siwz.
Odwołujący zarzucał, iż w/w kryteria są nieostre i niejednoznaczne, ponadto
zezwalają na całkowicie uznaniową ocenę przez Zamawiającego, wreszcie - pozbawiają
wykonawcę jakiegokolwiek wpływu na ocenę treści jego oferty w omawianym zakresie.
W/w zapisy siwz i ogłoszenia powodują, że ocena w kryterium „jakości" będzie
subiektywną oceną członków komisji przetargowej i prowadzić będzie do sytuacji, w której
ocena oferty była zupełnie dowolna i to aż w 20%.
W pierwszej kolejności Odwołujący zwracał uwagę na nieprecyzyjność i niejasność
opisanych w tym kryteriów „wymagań" - będących de facto podkryteriami, np.:
Czytelny wygląd - nie jest jasne jaki wygląd aplikacji zasługuje na maksymalną
liczbę punktów i co faktycznie oznacza (czy odbiór wizualny, czy wygląd i rozmiar czcionki,
czy słownictwo)?
Intuicyjność obsługi - doprecyzowana jako logiczne działania i chronologię
operacji - co o tyle dziwi, iż - co wynika z wcześniejszych punktów odwołania - chronologia
czy kolejność punktów scenariusza jest narzucona, a nawet gdyby nie była - do czego
zmierza odwołanie - to nie jest jasne jaka kolejność zdaniem członka komisji będzie
zasługiwała na maksymalna liczbę punktów, a jaka będzie kolejnością gorszą, czy z tego
punktu widzenia wadliwą (nieintuicyjną)?
Adekwatność opisu pól do modułu - nie jest jasne pod jakiem katem ma być
oceniana owa adekwatność, które nazwy będą mniej lub bardziej adekwatne i dlaczego?
Łatwość wyszukiwania - w dużym stopniu zależna od użytkownika i jego
biegłości, nie jest widome jaka „łatwość" jest optymalna i z jakiego punktu widzenia staje się
„mniej łatwa" czy wręcz trudna.
Comarch twierdził, iż ocena oferowanego systemu z wagą aż 20%, oparta na
enigmatycznej czytelności wyglądu aplikacji czy jej szacie graficznej powoduje, że nie jest
wiadome jaka szata graficzna spełnia „wymagania" na tyle, by uzyskać maksymalną liczbę
punktów, zwłaszcza, że każdy z członków komisji Zamawiającego może mieć inny pogląd w
tym zakresie. To samo dotyczy kwestii zrozumiałości nazewnictwa - wykonawca nie można
ponosić odpowiedzialności za poziom zrozumienia poszczególnych, nieznanych mu osób z
komisji przetargowej, nie da się tak sformułować systemu by był on jednolicie akceptowalny z
punktu widzenia wygląd, ergonomii czy nazewnictwa przez wszystkie oceniającego go
osoby.
Opisane wyżej podkryteria czy „wymagania" są też absolutnie nieweryfikowalne -
właściwie nie jest wiadome, jak miałby wyglądać czy działać system, aby spełniał wymagania
„intuicyjności" obsługi. Kwestia intuicji nie powinna absolutnie stanowić kryterium oceny ofert
- które winny mieć charakter zobiektywizowany i nie uznaniowy.
To samo dotyczy „wymogu" złożoności obsługi - pod kątem skrótów klawiaturowych -
są to elementy zupełnie zindywidualizowane, a zatem subiektywne - dla jednych dany skrót
będzie potrzeby, dla innych nie. Wykonawca prezentując system - który z założenia ma być
systemem istniejącym (wniosek z oceny ofert pod kątem gotowości do wdrożenia) siłą rzeczy
nie będzie systemem uwzględniającym indywidualne preferencje tych konkretnych członków
komisji (nie wiadomo nawet jak licznej) u tego konkretnego Zamawiającego.
Również aspekt pomocy dla użytkownika z poziomu aplikacji - pod kątem jego
„łatwości" - ma charakter subiektywny i wysoce oceny, uniemożliwiający rzeczowa i
zobiektywizowana ocenę, a także dyskusję z przyznanymi punktami w ramach tego
kryterium.
Comarch podnosił, że powyższe kryterium jest niekonkurencyjne. Jest to całkowicie
subiektywna ocena członka komisji. W ocenie Odwołującego przyjęte kryterium pn. Jakość i
jego podkryteria oceny ofert są niezrozumiałe i nieprecyzyjne, co czyni ocenę ofert przez
Zamawiającego całkowicie dowolną i uznaniową. Powyższe prowadzi również do całkowitej
dowolności interpretacyjnej przyjętych kryteriów oceny ofert przez wykonawców, co skutkuje
złożeniem w postępowaniu ofert nieporównywalnych oraz uniemożliwieniem wykonawcom
dokonania weryfikacji oceny ofert z punktu widzenia stosowania przez Zamawiającego zasad
udzielania zamówień publicznych (w tym zasady równego traktowania wykonawców -
naruszenie art. 7 ustawy).
Ponadto Odwołujący zwracał uwagę, iż kryterium to odnosi się do próbki systemu,
jaką wykonawca ma dostarczyć na potwierdzenie spełniania warunków udziału w
postępowaniu. Sam System finalnie w procesie wdrożenia będzie dostosowywany w dużej
mierze do indywidualnych potrzeb Zamawiającego. W związku z powyższym
przeprowadzenie takiej oceny na tym etapie jest bezzasadne. Jednocześnie Zamawiający
preferując z góry jakieś rozwiązanie może przydzielić maksymalną liczbę punktów w tym
kryterium, a weryfikacja powyższego przez innych wykonawców będzie niemożliwa.
W związku z powyższym Odwołujący żądał usunięcia kryterium jako
niekonkurencyjnego i nieuzasadnionego w procesie oceny próbki oprogramowania.
W dniu 23 lutego 2016 r. Zamawiający złożył pisemną odpowiedź na odwołanie w
której wnosił o oddalenie odwołania w całości jako niezasadnego.
Uwzględniając treść dokumentacji postępowania o udzielenie zamówienia
przekazanej przez Zamawiającego oraz stanowiska i oświadczenia stron oraz
przystępujących złożone w pismach procesowych i na rozprawie, Izba ustaliła i
zważyła, co następuje.
Stan faktyczny sprawy został wyczerpująco i zgodnie z rzeczywistością przytoczony w
treści odwołania (zreferowanej powyżej) i jest właściwie pomiędzy stronami bezsporny.
Strony różnią się jedynie w jego interpretacji oraz co do wniosków wyciąganych z zastanych
okoliczności faktycznych, szczególnie ich ocenie prawnej.
Na wstępie Krajowa Izba Odwoławcza stwierdza, że Odwołujący legitymują się
uprawnieniem do korzystania ze środków ochrony prawnej, o którym stanowi przepis art. 179
ust. 1 Pzp, według którego środki ochrony prawnej określone w ustawie przysługują
wykonawcy, uczestnikowi konkursu, a także innemu podmiotowi, jeżeli ma lub miał interes w
uzyskaniu danego zamówienia oraz poniósł lub może ponieść szkodę w wyniku naruszenia
przez zamawiającego przepisów niniejszej ustawy.
KIO 163/16
Odwołanie w części zasługuje na uwzględnienie.
Izba, dokonując oceny zarzutów podniesionych w odwołaniu w oparciu o
zgromadzony w sprawie materiał dowodowy, stwierdziła, że zarzuty w zakresie naruszenia
przez zamawiającego przepisów Pzp opisane w odwołaniu w części potwierdziły się.
Izba rozpoznała zgłoszone zarzuty według kolejności przytoczonej w odwołaniu:
I.
Zarzut dotyczący rozwiązania MS SQL Server 2014 oraz licencji SIMPANA.
Z ustaleń Izby wynika, że Zamawiający w pkt. 2.2 załącznika nr 1 do siwz wymienił
posiadaną infrastrukturę, którą zamierza przeznaczyć do realizacji zamówienia. W jej ramach
pod lit. c znajdowała się powołana przez odwołującego licencja MS SQL Server 2014 w
wersji Enterprise na 2 serwery.
Wskazać należy, że nie było sporne między stronami, że w prowadzonym
postępowaniu Zamawiający dopuścił zastosowanie innych rozwiązań, niż tych, opartych o
MS SQL Server 2014.
Rozstrzygnięcie niniejszego sporu wymaga odpowiedzi na pytanie, czy Zamawiający
w ramach prowadzonego postępowania mógł udostępnić posiadaną licencję MS SQL Server
2014 i czy takie działanie nie powodowało naruszenia przepisów ustawy ? Na tak zadane
pytanie należy udzielić odpowiedzi twierdzącej.
Przepis art. 29 ust. 2 Pzp stanowi, że przedmiotu zamówienia nie można opisywać w
sposób, który mógłby utrudniać uczciwą konkurencję.
Przedmiotu zamówienia nie można opisywać przez wskazanie znaków towarowych,
patentów lub pochodzenia, chyba że jest to uzasadnione specyfiką przedmiotu zamówienia i
zamawiający nie może opisać przedmiotu zamówienia za pomocą dostatecznie dokładnych
określeń, a wskazaniu takiemu towarzyszą wyrazy „lub równoważny”. (ust. 3).
W omawianym stanie faktycznym przede wszystkim należy zwrócić uwagę, że
Zamawiający używa znaków towarowych w odniesieniu do elementów, które nie są objęte
zamówieniem a jedynie w stosunku do posiadanych przez Zamawiającego urządzeń lub też
sprzętu, który zamierza udostępnić na potrzeby realizacji zamówienia. Tym samym nie
sposób dopatrzyć się w takich działaniach Zamawiającego naruszenia przepisu art. 29 ust. 3
Pzp, na który wskazywał Sputnik w złożonym odwołaniu.
Zaś co do kolejnego zarzutu to również nie można przyznać racji Odwołującemu,
który w odwołaniu oraz w toku rozprawy podnosił, że opisanie przedmiotu zamówienia w
wykorzystaniem rozwiązania MS SQL Server 2014 ogranicza konkurencje i uprzywilejowuje
jedynie grupę wykonawców.
Izba wyjaśnia, że Zamawiający w ramach prowadzonego postępowania dopuścił
zastosowanie innych rozwiązań, niż tych, opartych o MS SQL Server 2014. W związku z
powyższym, trudno w tym aspekcie mówić o ograniczeniu konkurencji.
Izba uznała za słuszne i racjonalne działanie Zamawiającego, który posiadając na
wyposażeniu określoną infrastrukturę, w postaci serwerów oraz licencji MS SQL Server 2014
w wersji Enterprise, postanowił udostępnić ją wykonawcy, który będzie realizował
zamówienie. Za niecelowe i nielogiczne należałoby uznać przeciwne działania
Zamawiającego, polegające na pozostawieniu „na stanie u Zamawiającego” urządzeń i
oprogramowania, które może być konstruktywnie wykorzystane do zbudowania systemu
informatycznego, który ma funkcjonować u Zamawiającego.
W odniesieniu do zarzutu, dotyczącego licencji SIMPANA, których zakup stanowi
również część przedmiotu zamówienia Izba również nie dopatrzyła naruszenia przepisu art.
29 ust. 3 Pzp. W tym zakresie Izba prezentuje analogiczną argumentację jak w przypadku
rozwiązania MS SQL Server 2014.
Zaś w stosunku do zarzutu opisu przedmiotu zamówienia z naruszeniem przepisu art.
29 ust. 2 Pzp Izba wskazuje, że Odwołujący zarówno w złożonym odwołaniu jak również w
toku rozprawy, nie przedstawił żadnych okoliczności, które uprawdopodabniałby ograniczenia
konkurencji, z uwagi na zakup licencji SIMPANA, w ramach prowadzonego postępowania. W
toku rozprawy Odwołujący wyjaśniał jedynie, że poszczególni wykonawcy, ubiegający się o
zamówienie, mogą mieć problem z uzyskaniem ww. licencji, ponieważ producent licencji,
stosując określoną politykę wobec różnych podmiotów może ograniczać im dostęp do tych
licencji. Izba uznała zaprezentowaną argumentację za niepotwierdzoną i niewystarczającą.
Wobec tego zgłoszony zarzut uznała za niezasadny.
Podsumowując, Izba nie stwierdziła naruszenia przepisu art. 29 ust. 2 i 3 Pzp.
II. Zarzut naruszenia art. 29 ust. 2 Pzp - wymóg, aby oferowane rozwiązanie było
zbudowane w oparciu o standardowe rozwiązanie klasy ERP dostępne na rynku w wersji
COTS przynajmniej od 10 lat
W ocenie Izby wymaganie Zamawiającego opisane w rozdziale 1 pkt 1.1. lit. k)
Załącznika nr 1 do siwz, aby oferowane rozwiązanie było zbudowane w oparciu o
standardowe rozwiązanie klasy ERP dostępne na rynku w wersji COTS (commercial-off-the-
shelf) przynajmniej od 10 lat, a w oferowanej wersji co najmniej rok, jest uzasadnione
obiektywnymi potrzebami Zamawiającego i nie powoduje naruszenia przepisów ustawy,
związanych z ograniczeniem konkurencji.
Po pierwsze, w toku rozprawy Zamawiający podnosił, że przygotowując niniejsze
postępowanie przeprowadzał analizę rynku pod kątem ilości podmiotów, które są w stanie
wykonać przedmiot zamówienia. Z jego ustaleń wynikało, że takich podmiotów jest co
najmniej dwa, tj. firma Microsoft oraz SAP. Natomiast wykonawców, którzy mogą dobudować
do rozwiązań oferowanych przez ww. firmy określone moduły, wymagane przez
Zamawiającego jest już znacznie większa ilość.
Po drugie, również w toku rozprawy Przystępujący złożył oświadczenie firmy SAP
Polska Sp. z o.o., w którym podano m. in. „ Oferowane przez firmę SAP rozwiązanie klasy
ERP dostępne na rynku w wersji COTS (…) od ponad 10 lat, nie posiada gotowej konfiguracji
obszarów wyspecyfikowanych w Załączniku nr 4 do Opisu przedmiotu zamówienia
(Scenariusze testowe dla obszaru budżetowo-księgowego). Realizacja wymaganych
scenariuszy jest możliwa w procesie wdrożenia, które zwykle trwa od kilku do kilkudziesięciu
miesięcy i jest poprzedzone dogłębną analizą wymagań klienta. To podejście jest
odzwierciedlone w dokumentacji przetargowej zakładającej etapowanie prac poprzedzonych
pracami analitycznymi i wdrożeniem rozwiązania w ciągu 24 miesięcy. Rozwiązanie SAP
ERP działa z różnymi silnikami baz danych w tym z MS SQL Server. (…)”.
W ocenie Izby okoliczności sprawy opisane powyżej potwierdzają prawdziwość
twierdzeń Zamawiającego, że na rynku występuję co najmniej dwa podmioty, które są w
stanie zaoferować rozwiązania wymagane przez Zamawiającego. Natomiast faktu, że
wykonawców, którzy mogą dobudować do rozwiązań oferowanych przez ww. firmy określone
moduły, wymagane przez Zamawiającego jest już znacznie większa ilość Przystępujący już
nie kwestionował.
Izba uznała za wiarygodne, spójne i przekonywujące wyjaśnienia Zamawiającego,
który wskazywał, że określając warunki względem standardowego rozwiązania ERP brał pod
uwagę kilka bardzo istotnych kwestii. Po pierwsze, zamawiane rozwiązanie Zamawiający
zamierza eksploatować przez okres 10-15 lat. W związku z tym wszystkie analizy kosztów i
potrzeb dokonywane były dla tak długiego okresu czasu. Po drugie, Zamawiający uwzględnił
fakt, że komponenty ERP stanowią „szkielet” aplikacji merytorycznych i muszą być
wytworzone przez podmioty, które gwarantują trwałość oferowanych rozwiązań w tym
zakresie. W ocenie Zamawiającego okres 10 lat stałego rozwijania standardowego
rozwiązania ERP oraz dostępność w wersji COTS w znacznym stopniu minimalizuje ryzyko
zakończenia rozwoju i wsparcia dla nabywanego produktu. Zamawiający zwracał również
uwagę, że wykorzystanie standardowego oprogramowania klasy ERP z wymaganiami przez
niego stawianymi, gwarantuje możliwość zlecenia rozbudowy systemu przez wielu
wykonawców, bowiem produkt klasy ERP, który jest dostępny i utrzymywany kilkanaście lat,
jest powszechnie znany i wykorzystywany przez producentów oprogramowania. Zakup
systemu wykorzystującego standardowe oprogramowanie klasy ERP pozwala
Zamawiającemu również uzyskać swobodę w zakresie wyboru wykonawcy usług
serwisowych i nie tworzy przy tym sztucznego monopolu usług.
W związku z powyższym Izba stanęła na stanowisku, że postawienie przez
Zamawiającego wymogu, aby oferowane rozwiązanie było zbudowane w oparciu o
standardowe rozwiązanie klasy ERP dostępne na rynku w wersji COTS (commercial-off-the-
shelf) przynajmniej od 10 lat, a w oferowanej wersji co najmniej rok, jest usprawiedliwione
przedmiotowym interesem Zamawiającego i nie narusza przepisów ustawy, związanych z
ograniczeniem konkurencji.
Zatem zgłoszony przez Sputnik zarzut Izba oddaliła.
III. Zarzut naruszenia art. 7 ust. 1 Pzp – przez sformułowanie warunku udziału w
postępowaniu, który uniemożliwia złożenie oferty wykonawcom zdolnym do wykonania
zamówienia, oferującym rozwiązania oparte na technologii Open Source
Na wstępie wskazać należy, że w rozdziale 5 ust. 5.1. pkt. 5.1.2 ppkt. 5.1.2.1. siwz
Zamawiający sprecyzował, że wymaga, aby wykonawca ubiegający się o udzielenie
przedmiotowego zamówienia należycie wykonał lub wykonuje w jednostce sektora finansów
publicznych w rozumieniu ustawy - ustawa z dnia 27 sierpnia 2009 r. o finansach publicznych
(Dz.U. z 2013 r., poz. 885, z późn.zm.) zamówienie polegające na dostawie systemu
informatycznego (o wartości nie mniejszej niż 10 000
000,00 PLN brutto, podana wartość
dostawy systemu i jego wdrożenia nie obejmuje dostawy sprzętu) i jego wdrożeniu również w
jednostkach podległych Zamawiającemu, obejmujące swoim zakresem obszar finansowo-
księgowy.
Przepis art. 22 ust. 1 Pzp stanowi, że o udzielenie zamówienia mogą ubiegać się
wykonawcy, którzy spełniają warunki, dotyczące:
1. posiadania uprawnień do wykonywania określonej działalności lub czynności, jeżeli
przepisy prawa nakładają obowiązek ich posiadania;
2. posiadania wiedzy i doświadczenia;
3. dysponowania odpowiednim potencjałem technicznym oraz osobami zdolnymi do
wykonania zamówienia;
4. sytuacji ekonomicznej i finansowej.
Według art. 22 ust. 4 Pzp opis sposobu dokonania oceny spełniania warunków, o
których mowa w ust. 1, powinien być związany z przedmiotem zamówienia oraz
proporcjonalny do przedmiotu zamówienia.
Natomiast zgodnie z art. 7 ust. 1 ustawy Zamawiający przygotowuje i przeprowadza
postępowanie o udzielenie zamówienia w sposób zapewniający zachowanie uczciwej
konkurencji oraz równe traktowanie wykonawców.
Po przeprowadzeniu analizy powyższego zarzutu Izba doszła do przekonania, że
zgłoszony zarzut należy uznać za bezzasadny.
Po pierwsze Izba wskazuje, że przedmiot zamówienia w ramach niniejszego
postępowania oszacowano na kwotę przewyższającą 30 mln zł netto. W związku z
powyższym, co słusznie zauważył Zamawiający, kwota 10 mln zł odnosząca się do warunku
udziału w postępowaniu, stanowi jedynie około 1/3 kosztów związanych z realizacją
przedmiotu zamówienia. Tym samym zarzut odnoszący się do zawyżonej kwoty wymagania
wykonania dostawy systemu informatycznego nie może się ostać. Co do zakresu ww.
warunku udziału w postępowaniu, to Izba zwraca uwagę, że przedmiotem zamówienia jest
dostawa i wdrożenie systemu informatycznego wspomagającego zarządzanie finansami
Miasta, a zatem żądanie Zamawiającego, aby wykonawcy ubiegający się o udzielenie
zamówienia wylegitymowali się doświadczeniem w zakresie dostawy oraz wdrożenia
systemu, obejmującego swym zakresem obszar finansowo – księgowy Izba uznała za jak
najbardziej zasadne. Wobec tego Izba nie znalazła żadnego uzasadnienia dla modyfikacji
ww. warunku według żądania Sputnik, który domagał się nie tylko obniżenia wartości 10 mln
zł zawartej w warunku do 2,5 mln zł, ale również zmiany obszaru na budżetowo-księgowy
oraz podatkowy.
W zakresie możliwości posługiwania się przez wykonawców, na potrzeby
prowadzonego postępowania, rozwiązaniami bazującymi na Open Source Izba podziela
argumentację wyrażoną przez Zamawiającego w treści odpowiedzi na odwołanie, gdzie
wskazano, że Zamawiający nie wyraża zgody na stosowanie tego oprogramowania, gdyż
jego utrzymanie w długim okresie czasu (np. 10 lat) wymagałoby bardzo indywidualnego
podejścia, a co za tym idzie, istotnych nakładów finansowych. Zamawiający wyjaśniał
również, że producenci oprogramowania klasy ERP dążą do rozwoju oprogramowania, co
pozwala na uzyskanie kompatybilności oprogramowania stacji roboczych, natomiast
rozwiązania typu Open Source takiego rozwoju nie gwarantują.
Biorąc pod uwagę powyższe Izba uznała, że zgłoszony zarzut naruszenia przepisu
art. 22 ust. 4 Pzp w zw. 7 ust. 1 Pzp jest bezzasadny i podlega oddaleniu.
IV. Zarzut naruszenia art. 7 ust. 2 w zw. z art. 91 ust. 1 i 2 Pzp przez sformułowanie
kryteriów oceny ofert w sposób niezapewniający obiektywizmu podczas oceny ofert w
kryterium „Jakość”.
W toku rozprawy nie było sporne, że Zamawiający w ramach prowadzonego
postępowania wyspecyfikował jedno z kryteriów pn. „Jakość”, któremu przyznał wagę 20%.
Ponadto w zakresie ww. kryterium Zamawiający wskazał, że będzie punktował określone
pięć wymagań. Do każdego wymagania Zamawiający przyporządkował określony katalog
definicji, który został opisany powyżej.
Istotą sporu w rozpoznawanej kwestii jest rozstrzygnięcie zagadnienia, czy tak
ukształtowane kryterium jakości jest zgodne z przepisami ustawy i zapewnia zachowanie
uczciwej konkurencji pomiędzy wykonawcami ubiegającymi się o udzielenie zamówienia ? W
ocenie Izby na tak zadane pytanie należy odpowiedzieć przecząco.
Na wstępie wskazać należy, że zgodnie z art. 91 ust. 1 i 2 Pzp zamawiający wybiera
ofertę najkorzystniejszą na podstawie kryteriów oceny ofert określonych w specyfikacji, przy
tym, że kryterium oceny ofert może być cena albo też cena i inne kryteria odnoszące się do
przedmiotu zamówienia, w szczególności tj. jakość, funkcjonalność, parametry techniczne,
aspekty środowiskowe, społeczne, innowacyjne, serwis, termin wykonania zamówienia oraz
koszty eksploatacji. Wskazać należy, że ustawodawca w powyższym przepisie nie
przedstawił kryteriów jako zamkniętego zbioru a jedynie zawarł przykładowy ich katalog.
Wobec powyższego oczywistym jest, że Zamawiający samodzielnie ustala kryteria
oceny ofert, a następnie w konsekwencji jest zobligowany do ich ścisłego przestrzegania na
etapie oceny. Zamawiający ma obowiązek przypisać określoną wagę każdemu z kryteriów, tj.
określić, jakie znaczenie przy ocenianiu będzie miał dane kryterium. Ustala się to w ten
sposób, że każdemu z kryteriów zamawiający przypisuje liczbę procentową, przy założeniu,
iż wszystkie kryteria łącznie stanowią 100 %. Tym samym sposób oceny ofert powinien być
tak realizowany, aby ograniczyć subiektywne odczucia i osobiste preferencje a zapewniać
ocenę ofert w zgodzie z zasadą uczciwej konkurencji i równego traktowania wykonawców.
W omawianym przypadku, Zamawiający co prawda w ramach kryterium
jakościowego, wskazał katalog wymagań, a w jego ramach poszczególne definicje, jednak są
one na tyle nieostre i nieprecyzyjne, że mogą powodować bardzo dowolną ocenę
poszczególnych elementów ocenianego systemu przez poszczególnych członków komisji
przetargowej. Poza tym opis kryterium, w określonym przez Zamawiającego kształcie, nie
daje wykonawcom ubiegającym się o udzielenia zamówienia, jasnych czytelnych
wytycznych, w jaki sposób mają skonstruować system, aby otrzymać jak najwyższą liczbę
punktów w ramach poszczególnych wymagań. Jedynie dla przykładu można wskazać na
definicję „szata graficzna” w zakresie wymagania „Wygląd aplikacji”. Nie budzi żadnych
wątpliwości, że z treści jedynie takiego stwierdzenia, bez dalszego uszczegółowienia nie
sposób wywieść jakie są oczekiwania Zamawiającego w powyższym zakresie. Tym samym
wykonawca nie posiada dostatecznych informacji do sporządzenia oferty. W omawianej
kwestii nie można zgodzić się z twierdzeniami Zamawiającego, że „doświadczony
wykonawca” będzie wiedział jakiego rodzaju szatę graficzną ma zaproponować, bowiem
nawet najbogatsze doświadczenie wykonawcy w konstruowaniu wyglądu aplikacji nie
determinuje tego, że jego wizja wyglądu aplikacji systemu w zakresie szaty graficznej będzie
zbieżna z oczekiwaniami Zamawiającego. W związku z powyższym Izba uwzględniła
zgłoszony zarzut i nakazała Zamawiającemu w pkt 13.8 specyfikacji doprecyzowanie
definicji, służących indywidualnej ocenie prezentacji, w ramach poszczególnych wymagań, w
kryterium „Jakość”.
V. Zarzut naruszenia art. 7 ust. 1 w zw. z art. 91 ust. 1 i 2 Pzp przez sformułowanie
kryteriów oceny ofert w sposób utrudniający uczciwą konkurencję w zakresie
scenariuszy testowych w obszarze podatki i opłaty lokalne
Z ustaleń Izby wynika, że Zamawiający postanowieniami załącznika nr 4 do siwz,
przewidział w zakresie opłat i podatków określone scenariusze testowe (od 1 do 6). Nie
budzi, żadnych wątpliwości, że powyższe scenariusze mają służyć Zamawiającemu do
oceny dojrzałości oferowanego przez wykonawcę systemu. W związku z powyższym za
słuszną należy uznać argumentację Zamawiającego, że jeżeli wykonawca nie zrealizuje
danego scenariusza to nie otrzyma w tym zakresie punktów, natomiast jego oferta nie będzie
podlegała odrzuceniu, bowiem Zamawiającemu zależy na punktowaniu rozwiązania
oferującego większą liczbę gotowych funkcjonalności, co w praktyce oznacza, że
rozwiązanie jest bardziej dojrzałe. Zdaniem Izby powyższe nie narusza przepisu art. 7 ust. 1
w zw. z art. 91 ust. 1 i 2 Pzp.
Odnosząc się zaś do zagadnienia dopuszczalności żądania przez Zamawiającego,
na etapie składania ofert, próbki systemu w zakresie, w którym ma być on dopiero
wytworzony na dalszym etapie realizacji umowy, Izba wskazuje, że takie żądanie jest jak
najbardziej dopuszczalne i uzasadnione. Przede wszystkim wskazać należy, że Zamawiający
jest uprawniony do żądania próbki zamawianego systemu, w tym również w obszarze opłat i
podatków. W rozpoznawanej sprawie Zamawiający w siwz określił kryteria, odnoszące się do
badania dojrzałości oferowanego systemu. Zatem z dużym prawdopodobieństwem można
stwierdzić, że w tym zakresie Zamawiający będzie chciał zapoznać się z rozwiązaniami
oferowanymi przez poszczególnych wykonawców i przyznać im określoną ilość punków.
Biorąc pod uwagę powyższe Izba nie dopatrzyła naruszenia przez Zamawiającego,
wskazywanych przez Odwołującego przepisów ustawy.
VI. Zarzut naruszenia art. 29 ust. 1 ustawy, przez zaniechanie precyzyjnego i
wyczerpującego określenia wymagań, dotyczących obowiązku wykonawcy do
opracowania w ramach wykonania przedmiotu zamówienia 250 szablonów raportów w
Systemie zgodnie z wzorami uzgodnionymi w ramach Projektu Rozwiązania
Przepis art. 29 ust. 1 Pzp stanowi, że przedmiot zamówienia opisuje się w sposób
jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń,
uwzględniając wszystkie wymagania i okoliczności mogące mieć wpływ na sporządzenie
oferty.
Izba wskazuje, że zgodnie z treścią przywołanego powyżej przepisu Zamawiający jest
zobowiązany do opisu przedmiotu zamówienia w taki sposób, aby uwzględniał on wszystkie
wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty. „Jasny” i „pełny” opis
przedmiotu zamówienia umożliwia wykonawcy prawidłowe obliczenie ceny oferty, z
uwzględnieniem wszystkich czynników (elementów) mających wpływ na jej wysokość.
Ponadto tak sporządzony opis przedmiotu zamówienia w dużej mierze zapewnia, że wszyscy
wykonawcy zrozumieją treść opisu tak samo.
W zakresie omawianego zarzutu Izba ustaliła, że Zamawiający co prawda określił
wymagania co do ilości szablonów raportów (250 raportów), co jednak należy uznać za
niewyczerpujące, ponieważ w treści specyfikacji brak jest informacji w zakresie rodzajów
raportów.
Zgodzić się należy z argumentacją prezentową przez Odwołującego, że
poszczególne rodzaje raportów są bardzo zróżnicowane, poczynając od raportów mających
postać jednostronicowych dokumentów, aż po raporty bardzo złożone, mające charakter
wielostronicowych, analitycznych dokumentów. W związku z powyższym mogą się one
charakteryzować stosunkowo nisko lub też bardzo dużą pracochłonnością, co wykonawca
powinien uwzględnić w kalkulacji kosztów już na etapie przygotowania oferty.
Izba nie podziela stanowiska prezentowanego przez Zamawiającego w toku
rozprawy, zasadzającego się na tym, że „doświadczony wykonawca” będzie wiedział, jak
skalkulować koszty związane z koniecznością przygotowania raportów. W miejscu ponownie
należy zwrócić uwagę, na wynikający z art. 29 ust. 1 Pzp obowiązek zamawiającego,
polegający na opisaniu przedmiotu zamówienia w sposób jednoznaczny i wyczerpujący, z
uwzględnieniem wszystkie wymagań i okoliczności, mogących mieć wpływ na sporządzenie
oferty. Brak informacji w zakresie rodzajów raportów niewątpliwe może mieć wpływ na
prawidłowe obliczenie ceny oferty, bowiem wykonawca nie posiadając wiedzy w zakresie
złożoności raportów nie jest w stanie poprawnie oszacować kosztów związanych z tą
czynnością. W konsekwencji całkowita cena oferty może być obarczona błędem, związanym
z nieprawidłowym założeniem kwoty, obejmującej opracowanie 250 szablonów raportów.
Wobec tego Izba uznała, że Zamawiający, opisując przedmiot zamówienia nie
wypełnił w sposób prawidłowy obowiązku, zawartego w art. 29 ust. 1 Pzp i nie zawarł w
opisie przedmiotu zamówienia wszystkich niezbędnych informacji, mogących mieć wpływ na
sporządzenie oferty. Zatem Izba uwzględniła powyższy zarzut i nakazała na str. 7 Załącznika
nr 1 siwz, po słowie „Uwaga!”, doprecyzować informacje w odniesieniu do rodzajów
szablonów raportów.
VII. Zarzut naruszenia art. 29 ust. 1 ustawy, przez zaniechanie precyzyjnego i
wyczerpującego określenia wymagań, dotyczących przedmiotu zamówienia w zakresie
integracji z istniejącymi u Zamawiającego systemami informatycznymi
W zakresie omawianego zarzutu Izba ustaliła, że Zamawiający opisał w Rozdziale 4.6
siwz zagadnienie, dotyczące procesu integracji. Na str. 98 Załącznika nr 1 do siwz
Zamawiający wskazał, że jeżeli w trakcie prac nad Projektem Rozwiązania konieczne będzie
uwzględnienie integracji z innymi systemami niż wymienione poniżej w wymaganiu nr 568,
Zamawiający zleci integrację w ramach prac dodatkowych. Natomiast w tabeli na str. 99
Załącznika nr 1 do siwz pod nr 568 Zamawiający wskazał, że „Zakres i sposób integracji z
poniższym oprogramowaniem musi być zrealizowany zgodnie z ogólnodostępnymi
warunkami wymiany dla poszczególnych systemów i nie stanowi przedmiotu prac
dodatkowych:
• Besti@,
• System bankowości elektronicznej banku obsługującego UMŁ(…)
• NIP-baza referencyjna,
• REGON- baza referencyjna,
• Platforma Elektroniczna IPE-PN, (…)
• CEPIK,
• US,
• Ministerstwo Finansów,
• (…)
• GUS.
W toku rozprawy Zamawiający wyjaśniał, że obecnie jest w fazie wymiany systemu
informatycznego, wobec tego nie jest w stanie podać szczegółowych danych, dotyczących
nowego systemu.
Na wstępie wyjaśnić należy, że proces integracji może być realizowany dwutorowo.
Po pierwsze - w ramach przedmiotu zamówienia - wykonawca będzie zobligowany do
przeprowadzenia procesu integracji w oparciu o pkt. 568 Załącznika nr 1 do siwz. Natomiast,
jeżeli w trakcie prac nad Projektem Rozwiązania wystąpi konieczność integracji z innymi
systemami niż opisane w pkt. 568 to wówczas Zamawiający zleci przeprowadzenie procesu
integracji w ramach prac dodatkowy.
W zakresie rozpoznawanego zarzutu Izba uznała za wiarygodną i spójną
argumentację prezentowaną przez Zamawiającego w odniesieniu zmiany systemu oraz
procesu integracji z innymi systemami niż opisane w pkt. 568. Nie budzi żadnych wątpliwości
Izby, że powyższe czynności, o ile wystąpią, będą realizowane w ramach prac dodatkowych.
Poza tym na obecnym etapie Zamawiający nie jest w stanie podać wszystkich wymaganych
danych z uwagi na wymianę systemu.
Natomiast nie budzi żadnych wątpliwości Izby, że proces integracji opisany w pkt. 568
na str. 99 Załącznika nr 1 do siwz będzie realizowany w ramach przedmiotowego
zamówienia. Tym samym Izba stwierdziła, że wykonawca powinien posiadać pełen zakres
danych niezbędnych do prawidłowego wykonania procesu integracji, podczas gdy
Zamawiający ograniczył się jedynie do zawarcia w opisie przedmiotu zamówienia
lakonicznego zapisu, że „zakres i sposób integracji z poniższym oprogramowaniem musi być
zrealizowany zgodnie z ogólnodostępnymi warunkami wymiany dla poszczególnych
systemów i nie stanowi przedmiotu prac dodatkowych”, nie precyzując, co znaczy
stwierdzenie: „ogólnodostępne warunki wymiany dla poszczególnych systemów”. Ponadto
Zamawiający w powyższym punkcie, poza nazwa poszczególnych programów np. BESTI@,
oraz nazwami określonych podmiotów (Ministerstwo Finansów, Urząd Skarbowy, Główny
Urząd Statystyczny), nie podał żadnych szczegółowych informacji w zakresie integracji. Nie
określił chociażby, w jakim zakresie ma następować wymiana pomiędzy systemem
Zamawiającego a systemem Ministerstwa Finansów czy też Urzędu Skarbowego. W ocenie
Izby informacje podane przez Zamawiającego są zbyt ubogie i niewystarczające do
prawidłowego skalkulowania ceny oferty. W zakresie omawianego zarzutu Izba prezentuje
analogiczną argumentację jak w zakresie zarzutu VI opisanego powyżej. Tym samym jej
powtarzanie Izba uznała za niecelowe.
Podsumowując, Izba uwzględniła zarzut, polegający na naruszeniu przez
Zamawiającego art. 29 ust. 1 Pzp i nakazała w pkt. 568 na str. 99 Załącznika nr 1 siwz -
Opis Przedmiotu Zamówienia, uszczegółowienie informacji, przez podanie wszystkich
niezbędnych danych do prawidłowego wykonania procesu integracji.
KIO 170/16
Odwołanie w części zasługuje na uwzględnienie.
Izba, dokonując oceny zarzutów podniesionych w odwołaniu w oparciu o
zgromadzony w sprawie materiał dowodowy, stwierdziła, że zarzuty w zakresie naruszenia
przez zamawiającego przepisów Pzp opisane w odwołaniu w części potwierdziły się.
Izba rozpoznała zgłoszone zarzuty według kolejności przytoczonej w odwołaniu:
I. Zarzut dotyczący zestawu testowego – złożenie zestawu testowego na jednym
notebooku
Z ustaleń Izby wynika, że Zamawiający w siwz sprecyzował wymaganie, aby zestaw
testowy zawierał wyłącznie 1 komputer typu notebook. Zdaniem Odwołującego
sformułowanie takiego wymagania przez Zamawiającego jest nieuzasadnione i ogranicza
możliwość złożenia ofert przez wykonawców, którzy oferują inne rozwiązania, niż te opisane
przez Zamawiającego.
W omawianym przypadku Izba uznała za słuszne i uzasadnione stanowisko
prezentowane przez Zamawiającego, który twierdził, że po pierwsze podczas testów
weryfikowana będzie jedynie określona funkcjonalność a nie określone parametry. Po drugie
zaś, ukształtowanie takiego wymogu, miało na celu zapewnienie braku możliwości ingerencji
w zaoferowany system na etapie prezentacji.
Izba wskazuje, że zarówno w odwołaniu jak i w toku rozprawy Odwołujący nie
wykazał, że postawiony wymóg jest niemożliwy do spełnienia a jedynie, że postawienie
takiego wymogu w siwz będzie wiązało się z poniesieniem przez wykonawców wysokich
kosztów zakupienia odpowiedniego sprzętu. W tym zakresie przywołać należy wyjaśnienia
Zamawiającego, który wskazywał, że przytoczone powyżej postanowienie siwz nie nakłada
na wykonawców obowiązku zakup sprzętu potrzebnego do prezentacji. Wobec tego skoro
wykonawca chciałby zmniejszyć koszty związane z zakupem notebooka o ściśle określonych
parametrach to powinien rozważyć, czy powyższego sprzętu nie pozyskać w inny sposób,
chociażby - dla przykładu - wypożyczyć.
Zatem Izba uznała zgłoszony zarzut za bezzasadny.
II. Zarzut dotyczący zestawu testowego – sumy kontrolne MD5.
Z ustaleń Izby wynika, że Zamawiający określił w pkt. 3 Załącznika nr 3 do Opisu
przedmiotu zamówienia (str. 1) następujące wymaganie: „3. Zestaw testowy, który
Wykonawca jest zobowiązany do dołączenia do oferty musi zawierać sprzęt niezbędny do
uruchomienia wersji demonstracyjnej Systemu w postaci co najmniej: wyłącznie 1 komputera
typu notebook, na którym będzie zainstalowany system demonstracyjny, Oprogramowania,
w tym standardowego oprogramowania klasy ERP, Oprogramowania Aplikacyjnego w wersji
demonstracyjnej, nośnika danych zawierającego obraz dysku/dysków komputera typu
notebook z wygenerowany sumami kontrolnymi MD5 wydruk zawierający wszystkie sumy
kontrolne MD5 dla wszystkich plików oraz innych komponentów niezbędnych do wykonania
prezentacji”.
Biorąc pod uwagę przytoczony powyżej fragment specyfikacji Izba stwierdziła, że
powyższy wymóg, dotyczący sum kontrolnych MD5 odnosi się jedynie do plików,
zawierających obraz dysku danego komputera z zestawu testowego. W zakresie
rozpoznawanego zarzutu przede wszystkich należy zwrócić uwagę, że określenie „dla
wszystkich plików” jest poprzedzone następującym stwierdzeniem „nośnika danych
zawierającego obraz dysku/dysków komputera typu notebook z wygenerowanymi sumami
kontrolnymi MD5”. Wobec tego, Izba uznała, że umiejscowienie powyższego stwierdzenia
jest punktem odniesienia w zakresie jego przyporządkowania i przeznaczenia. Powyższe
zostało także potwierdzone w toku rozprawy wyjaśnieniami Zamawiającego, który wprost
potwierdził, że powyższy wymóg miał służyć odpowiedniemu wykonaniu prezentacji, tym
samym nie mógł odnosić się do wszystkich plików, a jedynie do plików obraz dysku danego
komputera z zestawu testowego.
W związku z powyższym Izba potwierdziła, że zgłoszony zarzut należy uznać za
niezasadny.
III. Zarzut dotyczący zestawu testowego – instrukcja do samodzielnej prezentacji
Systemu
W zakresie rozpoznawanego zarzutu nie było sporne między stronami, że w siwz
Zamawiający postawił wymóg w postaci opracowania instrukcji, która umożliwi
Zamawiającemu samodzielne wykonanie prezentacji Systemu oraz/i odtworzenie „obrazu”
Systemu, zainstalowanego na dysku/dyskach komputera typu notebook.
W zakresie rozstrzyganej kwestii Izba wzięła pod uwagę wyjaśnienia złożone przez
Zamawiającego w odpowiedzi na odwołanie oraz w toku rozprawy. Zamawiający podnosił, że
celem stawianego wymogu w zakresie instrukcji jest możliwość przeprowadzenia
ewentualnego postępowania dowodowego w przyszłości bez konieczności udziału
wykonawcy, np. po 2 latach, podczas kontroli postępowania przetargowego. Dodatkowo
Zamawiający wyjaśniał również, że postanowienie ma charakter zabezpieczający, na
wypadek, gdyby w tym czasie Zamawiający był w sporze z wykonawcą, a wystąpiłaby
potrzeba samodzielnej prezentacji systemu, chociażby z uwagi na prowadzone u
Zamawiającego postępowanie kontrolę.
Biorąc pod uwagę powyższe Izba stanęła na stanowisku, że przytoczone
postanowienia specyfikacji mają dla Zamawiającego charakter ochronny i są w pełni
uzasadnione obiektywną potrzebą Zamawiającego. Tym samym zgłoszony zarzut podlega
oddaleniu jako niezasadny.
IV. Zarzut dotyczący zestawu testowego – czas przeznaczony na prezentację zestawu
testowego
Izba, w oparciu o dokumentację postępowania ustaliła, że Zamawiający w siwz na
przeprowadzenie całości prezentacji przeznaczył 6 godzin zegarowych. W toku rozprawy
strony zgodnie twierdziły, że przed i po prezentacji wykonawcy będą mieli jeszcze do
dyspozycji po godzinie czasu (łącznie 2 godziny) na przygotowanie do prezentacji oraz
rozmontowanie zestawu testowego po prezentacji. Dodatkowo w toku prezentacji
Zamawiający przewidział jeszcze 1-godziną przerwę. W związku z tym łączny czas związany
z przeprowadzeniem prezentacji to 9 godzin. Ponadto, o czym szczegółowo na dalszych
stronach uzasadnienia, Zamawiający wymagał, aby prezentacja odbywała się, po pierwsze
na sprzęcie w postaci jednego notebooka, po drugie ściśle według scenariusza określonego
przez Zamawiającego w siwz. Dodatkowo Zamawiający wskazał, że aby otrzymać określoną
ilość punktów w ramach danego scenariusza to należy wykonać wszystkie czynności
opisane w scenariuszy, bark chociaż jednej z nich spowoduje przyznanie zerowej ilości
punktów.
Wspomnieć również należy, że w złożonym odwołaniu Comarch podnosił, że
wykonawcy w ramach prezentacji muszą zademonstrować 87 zadań w ciągu 6 godzin
zegarowych, co średnio daje 4 minuty na zadanie, które często jeszcze składają się z
podzadań. Odwołujący wyjaśniał również, że czynność prezentacji ma dotyczyć próbki
nowego, dopiero tworzonego Systemu, a osobom wykonującym czynności w tym zakresie
będzie dodatkowo towarzyszył stres, co bez wątpienia stanowi czynnik jeszcze dodatkowo
spowalniający i mający wpływ na czas przeprowadzania prezentacji.
W następstwie argumentacji przestawionej powyżej Izba stwierdziła, że 6-godziny
czas na przeprowadzenie prezentacji jest czasem zbyt krótkim i może uniemożliwić
poprawną weryfikację poszczególnych scenariuszy testowych. Szczególnie, że w siwz
Zamawiający zastrzegł, że w przypadku, gdy wykonawca nie zmieści się w czasie 6 godzin
funkcjonalności, które nie zostały zaprezentowane zostaną uznane za takie, których system
nie posiada (str. 6 zał. 3 OPZ).
Tym samym Izba uznała za nieprzekonywujące i niewystarczające stanowisko
prezentowane przez Zamawiającego, który podnosił, że czas przeznaczony na prezentację
wyliczył w oparciu o pracę pracownika Zamawiającego, pracującego obecnie w systemie ZSI
MAGISTRAT. W miejscu Izba wskazuje, że niewłaściwe jest porównanie czasu pracy
pracownika Zamawiającego, pracującego obecnie w systemie ZSI MAGISTRAT z czasem
osoby przeprowadzającej prezentację próbki nowego Systemu, dostosowywanego do
potrzeb Zamawiającego. Bez wątpienia zarówno systemy, jak również okoliczności
wykonywania na ich bazie określonych czynności są skrajnie, a zatem nie mogą być ze sobą
porównywane na potrzeby ustalenia czas niezbędnego do przeprowadzenia prezentacji.
Również argument Zamawiającego oparty o trudności organizacyjne, związane z
wydłużeniem czasu pracowników zasiadających w komisji przetargowej, która ma
dokonywać oceny próbki systemu nie może się ostać, bowiem tego rodzaju trudności nie
mogą przesądzać o zasadności określenia czasu przeznaczonego na prezentację w zakresie
nieprzekraczającym 6 godzin.
Izba jedynie na marginesie zwraca uwagę, że skoro Zamawiający nie chce wydłużać
łącznego czasu przeznaczonego na prezentację ponad 9 godzin, to wówczas zasadnym
byłoby rozważenie, czy istnieje możliwość skrócenia czasu przeznaczonego na
przygotowanie i rozmontowanie zestawu testowego (łącznie 2 godziny), czy też ograniczenie
lub też całkowita likwidacja godzinnej przerwy, przewidzianej w trakcie prezentacji.
Podsumowując, Izba uznała zarzut zgłoszony przez Odwołującego za zasadny i
nakazała zmianę siwz w pkt. 30 Załącznika nr 3 do Opisu przedmiotu zamówienia przez
wydłużenie długości łącznego czasu prezentacji z 6 godzin zegarowych do co najmniej 7
godzin zegarowych.
V. Zarzut dotyczący zestawu testowego – dopuszczenie przedstawicieli pozostałych
wykonawców w roli obserwatorów na prezentacji danego wykonawcy
Izba ustaliła, że Zamawiający przytoczoną powyżej treścią siwz dopuścił, aby w
trakcie prezentacji obecni byli przedstawiciele pozostałych wykonawców w roli obserwatorów.
Jednocześnie Zamawiający sprecyzował, że w przypadku, gdy wykonawca w złożonej
ofercie skutecznie zastrzeże, że oferowany system stanowi tajemnicę przedsiębiorstwa to
Zamawiający nie dopuści, aby przedstawiciele pozostałych wykonawców byli obecni w
trakcie prezentacji.
Zgodnie z art. 8 ust. 1 Pzp postępowanie o udzielenie zamówienia jest jawne.
Zamawiający może ograniczyć dostęp do informacji związanych z postępowaniem o
udzielenie zamówienia tylko w przypadkach określonych w ustawie. (ust. 2)
Zasada jawności jest jedną z naczelnych zasad prawa zamówień publicznych, która
implikuje transparentność prowadzonego przez Zamawiającego postępowania, będąc przy
tym konsekwencją zasady konkurencyjności.
Izba rozpoznając zgłoszony zarzut stanęła na stanowisku, że dopuszczenie przez
Zamawiającego do udziału w prezentacji danego wykonawcy przedstawicieli pozostałych
wykonawców w roli obserwatorów stanowi w praktyce przejaw realizacji zasady jawności,
która służy gwarancji przejrzystość prowadzonego postępowania.
Za nietrafną Izba uznała argumentację prezentowaną przez Odwołującego,
opierającą się na tym, że wykonawca, który będzie jako ostatni prezentować swój zestaw, a
weźmie udział we wcześniejszych prezentacjach, będzie bogatszy o istotną wiedzę w
zakresie tego jak Zamawiający interpretuje poszczególne wymagania. Ponadto wskazywał,
ż
e wykonawca, który będzie dokonywał prezentacji jako ostatni, będzie mógł odpowiednio
przygotować się , aby uzyskać lepszą ocenę niż pozostali konkurenci. Przede wszystkim
podkreślić należy, że próbki Systemu zostają złożone przez wszystkich bez wyjątku
wykonawców ubiegających się o udzielenie zamówienia, nie później niż w dniu składania
ofert. Po upływie tego terminu żaden z wykonawców nie będzie miał możliwości dokonania
jakiejkolwiek, nawet najdrobniejszej modyfikacji, złożonej próbki. Wobec tego prezentowaną
przez Odwołującego argumentację należy uznać za dalece nietrafną.
W tym miejscu warto również przywołać wyjaśnienia Zamawiającego złożone w toku
rozprawy, w których Zamawiający wskazywał, że czasie prowadzenia prezentacji, osoby
uczestniczące w niej z ramienia Zamawiającego, nie będą zadawały żadnych
merytorycznych pytań, odnoszących się do prezentowanego przez danego wykonawcę
Systemu. W związku z tym upada również argument, iż uczestniczący w prezentacji
wykonawcy, występujący w roli obserwatorów, uzyskają w ten sposób informacje na temat
preferencji Zamawiającego, co pozwoli im zwiększyć przewagę nad pozostałymi
konkurentami.
W związku z powyższym Izba uznała zgłoszony zarzut za niezasadny i
niezasługujący na uwzględnienie.
VI. Zarzut dotyczący zestawu testowego – ograniczenie liczby przedstawicieli
wykonawcy
Izba ustaliła, że w siwz w pkt 27 Załącznika nr 3 OPZ (str. 4) Zamawiający zawarł
następujące postanowienie:
„ (…) Zamawiający dopuszcza udział maksymalnie 5 przedstawicieli Wykonawcy do
prowadzenia prezentacji”.
W ocenie Izby analiza przytoczonego powyżej postanowienia specyfikacji nie
potwierdza zasadności zgłoszonego zarzutu, polegającego na tym, że Zamawiający
ograniczył liczbę przedstawicieli wykonawcy, biorących udział w prezentacji. Izba wskazuje,
ż
e z literalnego brzmienia zacytowanego postanowienia wynika jedynie, że Zamawiający
dopuścił do udziału w prowadzeniu prezentacji, co najwyżej 5 przedstawicieli wykonawcy.
Należy podkreślić, że udział określonej liczby przedstawicieli odnosi się ściśle do czynności
„prowadzenia prezentacji” i z powyższego postanowienia siwz nie sposób wywieść wniosku,
ż
e Zamawiający zabronił „rotacji” przedstawicieli wykonawcy w trakcie prowadzenia
prezentacji. W opinii Izby z treść ww. punktu siwz wynika jedynie, że w toku prowadzenia
prezentacji jednocześnie może występować nie więcej niż 5 przedstawicieli wykonawcy.
Wobec tego zgłoszony zarzut Izba uznała za bezzasadny.
VII. Zarzut dotyczący zestawu testowego – narzucona kolejność realizacji scenariuszy
testowych
VIII.
Zarzut dotyczący zestawu testowego – sposób punktacji scenariuszy testowych
IX. Zarzut dotyczący zestawu testowego – zależność pomiędzy scenariuszami testowymi
Biorąc pod uwagę zależność oraz wzajemne powiązanie ww. zarzutów i argumentacji
ich dotyczącej Izba uznała za uzasadnione wspólne ich omówienie.
Na wstępie wskazać należy, że potwierdził się jedynie zarzut VII, odnoszący się do
narzuconej kolejność realizacji scenariuszy testowych. W pozostałym zakresie Izba oddaliła
zgłoszone zarzuty.
Z ustaleń Izby wynika, że Zamawiający przewidział następujący podział scenariuszy
testowych:
a) Scenariusze dla obszaru budżetowo-księgowego (od 1 do 3),
b) Scenariusze dla obszaru podatków i opłat (od 1 do 6).
W pkt 37 Załącznika nr 3 do OPZ Zamawiający sprecyzował, że wykonawca powinien
dokonywać prezentacji zgodnie z kolejnością opisanych w siwz scenariuszy testowych.
Załącznik nr 4 do OPZ od str. 2 do 7 zawiera wyspecyfikowaną kolejność ww. scenariuszy
testowych.
Następnie Zamawiający w Załączniku nr 3 do OPZ wskazał, że punkty zostaną
jedynie za scenariusze testowe zakończone w całości. W przypadku, gdy scenariusz testowy
nie zostanie przeprowadzony w całości lub w ogóle się nie rozpocznie, i zostanie uznany za
scenariusz niewykonany i zostanie przyznane „0” punktów z puli punktów przewidzianych dla
tego scenariusza testowego.
Ponadto przyznanie punktów w odniesieniu do scenariuszy w obszarze budżetowo –
księgowym Zamawiający wzajemnie od siebie uzależnił, tj. warunkiem uzyskania oceny za
scenariusz nr 2 jest wykonanie scenariusza nr 1, natomiast warunkiem uzyskania oceny za
scenariusz nr 3 jest wykonanie scenariusza nr 2.
W zakresie omawianych zarzutów, odnoszących się do zależności pomiędzy
scenariuszami testowymi, a w konsekwencji sposobem ich punktacji Izba za kluczowe uznała
wyjaśnienia Zamawiającego, który podnosił, że „przedmiotem zamówienia ma być produkt
dojrzały, funkcjonujący, a nie produkt, który jest w fazie rozwojowej. Dlatego, też m. in.
zamawia system działający na rozwiązania standardowych, a nie dedykowanych. Nie jest
zamiarem Zamawiającego ocena prostych zadań typu „wprowadzenie kontrahenta do
rejestru kontrahentów”, ale ocena całej sekwencji zdarzeń kończących się produktem
finalnym, np. wygenerowaniem określonego raportu, sporządzeniem pełnego o
prawidłowego sprawozdania RIO itp. (…) Zamawiający ponownie (…) wyjaśnia, iż wynika to
z logiki wykonywania określonych czynności Zamawiającego w ramach jego obowiązków,
wynikających z przepisów prawa, w tym ustawy o finansach publicznych. Jak wyżej zostało
to szczegółowo wyjaśnione nie ma możliwości oceny oprawności działania danej
funkcjonalności bez przeprowadzenia i wykonania całego scenariusza. Zamawiający jako
jednostka budżetowa zobowiązany jest do sporządzania szeregu analiz i raportów, w
związku z tym niewykonanie danej analizy uniemożliwia sporządzenie określonego raportu.
W związku z tym brak możliwości wykonania danego raportu oznacza, że bez znaczenia jest
wykonanie innych analiz. W wyjaśnieniach (….) Zamawiający szczegółowo wyjaśnił
powiązania logiczne kolejności scenariuszy i wykazał, że możliwość sporządzenia danego
dokumentu bez możliwości wykonania innego dokumentu z punku widzenia całej procedury
jest całkowicie bezużyteczna. Po co Zamawiającemu sprawozdanie z wykonania budżetu,
jak nie będzie miał danych wynikających z nieprawidłowo wykonanej analizy planu. Dlatego
też wykonanie wszystkich części składających się na cały scenariusz testowy wyłącznie
potwierdza prawidłowe funkcjonowanie danej funkcjonalności. Przyjęcie rozwiązania
wnioskowanego przez Wykonawcę doprowadziłoby do sytuacji, iż Zamawiający
przyznawałby punkty za poszczególne elementy funkcjonalności, która jako całość nie daje
pełnych danych, a w konsekwencji mogłoby doprowadzić do tego, że Zamawiający nabyłby
system o niesprawnie działających funkcjonalnościach, które oznaczałby dla Zamawiającego
generowanie dokumentów całkowicie bezużytecznych”.
Izba uznała powyższe wyjaśnienia za przekonywujące i spójne, oraz za takie, które
uzasadniają wzajemne powiązanie scenariuszy testowych, a w konsekwencji możliwość
uzyskania pełnej punktacji jedynie w przypadku zrealizowania wszystkich scenariuszy.
Poza tym, w toku rozprawy Zamawiający stwierdził, że nawet gdyby hipotetycznie
uznać zasadność zarzutu odnoszącego się sposobu punktacji scenariuszy testowych, w
odniesieniu do całości zakończonego scenariusza to - dla przykładu - Zamawiający nie widzi
praktycznej możliwości, w odniesieniu do scenariusza nr 2 (w obszarze budżetowo –
księgowym) „załadowania” próbki systemu wykonawcy danymi, które powinien zawierać
scenariusz nr 1, bowiem w zestawie testowym tego wykonawcy, ta aplikacja przecież „nie
działa”. Odwołujący w składanych wyjaśnieniach również nie wykazał, że istnieje taka
możliwość.
Na końcu Izba odniosła się do zarzutu w zakresie narzuconej kolejności realizacji
scenariuszy testowych. Izba dostrzega słuszność stanowiska Zamawiającego, które zostało
przytoczone powyżej. Jednak w toku rozprawy, w zakresie określonych czynności, opisanych
w scenariuszu nr 2 (pkt 7 – Wygenerowanie i wydruk ID umowy) Zamawiający stwierdził, że
numer ID umowy jest numerem bardzo istotnym i Zamawiającemu bardzo zależy na tym aby
obejrzeć wydruk z tym numerem. Wskazuje, że oczywiście nie ma znaczenia to, czy będzie
on dokonany zaraz po wprowadzeniu danych do umowy, czy wprowadzeniu danych z
aneksu do umowy, jednakże z uwagi na kolejność w formularzach do oceny prezentacji
dobrze, by było, aby znajdował się on w tej kolejności, którą zaproponował Zamawiający.
Podobną argumentację Zamawiający prezentował w odniesieniu do czynności opisanych w
scenariuszu nr 1 w pkt. 5, 6, 7.
Wobec tego Izba doszła do przekonania, że w zakresie czynności opisanych w
scenariuszach testowych znajdują się nie tylko czynności wzajemnie ze sobą powiązane, w
ramach pewnego ciągu logicznego, wynikającego z charakteru i sposobu działania
Zamawiającego, ale znajduje się tam również pewien katalog czynności, które mogą być
wykonane przez wykonawcę w innym momencie, niż te wskazany przez Zamawiającego,
bez uszczerbku dla prezentacji, czy też systemu następnie obsługiwanego przez
Zamawiającego. W ocenie Izby, wyjaśnienia Zamawiającego, zasadzające się na tym, że
kolejność czynności scenariusza jest istotna również, z uwagi na opracowane dla członków
komisji przetargowej formularze do oceny prezentacji, które są przedstawione w kolejności
czynności scenariuszy, nie są wystarczającą przesłanką do utrzymania wymogu
odpowiedniej kolejności realizacji scenariuszy testowych. Jednak podkreślić należy, że
powyższe odnosi się jedynie do katalogu czynności, które nie wynikają z opisanego powyżej
ciągu logicznego.
Konsekwencją powyższego było uwzględnienie zarzutu i nakazanie Zamawiającemu
wykreślenia pkt. 37 lit b) ii. Załącznika nr 3 - Opisu przedmiotu zamówienia, dotyczącego
tego, że wykonawca powinien dokonywać prezentacji zgodnie z kolejnością opisanych w
siwz scenariuszy testowych. Jednak powyższe nie przesądza o tym, że Zamawiający w
następstwie dokonanych zmian nie będzie mógł wprowadzi do postanowień specyfikacji
wymogu przeprowadzenia prezentacji według określonej kolejności, bazując na wzajemnym i
wzajemnym powiązaniu ze sobą czynności w ramach pewnego ciągu logicznego,
wynikającego z charakteru i sposobu działania Zamawiającego.
X. Zarzut dotyczący jednolitości technologii i interfejsu w całym systemie
Dokonując analizy zgłoszonego zarzutu Izba nie doszukała naruszenia przez
Zamawiającego przepisów Pzp, tym samym uznała zarzut za niepotwierdzony.
Izba stanęła na stanowisku, że rację ma Zamawiający, który wyjaśniał, że jednolity
interfejs jest dla niego koniecznością, również w zakresie technologii całego systemu, który
obejmuje również generator wydruku. Podkreślał, że nie wyobraża sobie aby interfejs był
różny, ponieważ mielibyśmy wówczas do czynienia z sytuacją, gdzie różne opcje
oprogramowania mogłyby być zlokalizowane w różnych miejscach, co powodowałoby bak
intuicyjności odbioru aplikacji. Zamawiający ponadto zwracał uwagę, że konieczność
jednolitego interfejsu wynika również z faktu, że Zamawiający będzie wdrażał system w
szeregu podległych sobie jednostek, a w związku z tym istotnym jest, aby system zapewniał
jednolity interfejs użytkownika dla wszystkich obszarów funkcjonalnych.
Biorąc pod uwagę powyższe Izba stwierdziła, że powyższe wymaganie jest
podyktowane obiektywną potrzebą Zamawiającego i oddaliła zgłoszony zarzut.
XI. Zarzut dotyczący otwartości kodu oprogramowania
Z ustaleń Izby wynika, że Zamawiający w pkt i) dokumentu Załącznik nr 1 do siwz
(str. 3) następujące wymaganie: „i. Oferowane rozwiązanie musi udostępniać w ramach
opłaty licencyjnej dostęp do otwartego kodu oprogramowania ".
Na str 13 i 14 załącznika nr 1 do siwz Zamawiający odrębnie zdefiniował pojęcia:
Oprogramowania i Oprogramowania Aplikacyjnego oraz pojęcie Kodu Źródłowego.
W odpowiedzi na odwołanie (str. 13) Zamawiający wyjaśnia, że przytoczone powyżej
postanowienia siwz odnoszą się do Oprogramowania Aplikacyjnego.
Zgłoszony zarzut zasługuje na uwzględnienie.
W ocenie Izby zacytowane powyżej postanowienie siwz wprost odwołuje się do
„Oprogramowania” a nie do „Oprogramowania Aplikacyjnego”. W związku z tym wyjaśnienia
Zamawiającego prezentowane w odpowiedzi na odwołanie oraz w toku rozprawy nie mają
pokrycia w treści specyfikacji. Izba uznała, że treść specyfikacji w takim kształcie może
wprowadzać w błąd wykonawców ubiegających się o udzielenie zamówienia, a zatem
uwzględniała powyższy zarzut i nakazała w pkt 1.1 lit. i) na str. 3 Załącznika nr 1 SIWZ - Opis
Przedmiotu
Zamówienia
–
zastąpienie
słowa
„oprogramowania”
określeniem
„Oprogramowania Aplikacyjnego”.
XII. Zarzut dotyczący dostosowania Oprogramowania Aplikacyjnego do zmian
wynikających z przepisów wewnętrznych
Izba ustaliła, że Zamawiający określił w pkt r) Załącznika nr 1 do siwz (str. 5)
następujące wymaganie: ,,r) Dostosowanie Oprogramowania Aplikacyjnego do Zmian
wynikających ze zmian prawa miejscowego - uchwały wydawane przez Radę Miejską, a
także przepisów wewnętrznych np. regulaminy, uchwały nie będące aktami prawa
miejscowego, zarządzenia itp."
W zakresie omawianego zarzutu Izba stwierdziła, że ww. wymaganie jest
uzasadnione potrzebami Zamawiającego i nie ma wpływu na prawidłowe oszacowanie ceny
oferty.
Po pierwsze podnieść należy, że Zamawiający jako jednostka samorządu
terytorialnego wydaje szereg aktów władztwa, w tym również regulacje, nie mające statusu
aktów prawa miejscowego, które jednak muszą być przestrzegane. W związku z tym nie
dziwi wymóg Zamawiającego, polegający na możliwości zlecania zmian w systemie, które
będą obejmowały właśnie takie sytuacje.
Po drugie, w kontekście postanowień specyfikacji zawartych na stronie 13 załącznika
nr 1 do siwz oraz § 4 ust. 4.8 Istotnych Postanowień Umowy, a także Rozdziału 9 - Prace
dodatkowe – pkt. c) stwierdzić należy, że opisane powyżej prace będą wykonywane w
ramach prac dodatkowych, które każdorazowo będą podlegały odrębnej wycenie.
W związku z tym Izba uznała, że zgłoszony zarzut jest bezzasadny.
XIII.
Zarzut dotyczący czasów odpowiedzi systemu na działania operacyjne
użytkowników
Izba ustaliła, że w załączniku nr 1 do siwz (str. 28-29) Zamawiający określił
wymagania, odnoszące się czasów reakcji systemu na działania operacyjne użytkowników.
Rozstrzygnięcie omawianego zarzutu wymaga odpowiedzi na pytanie, czy tak
skonstruowane postanowienia siwz jest zasadne i nie narusza przepisów Pzp ? W ocenie
Izby na tak zadane pytanie należy odpowiedzieć twierdząco.
Przede wszystkim Izba wskazuje, że przytoczona w odwołaniu treści siwz w
odniesieniu do wymogu związanego z czasem reakcji systemu na działania operacyjne
użytkowników jest ściśle powiązana z jakością pracy Zamawiającego. W świetle powyższego
zrozumiałym jest ustanowienie przez Zamawiającego w siwz wymogów o takim charakterze,
bowiem ich dochowanie w znacznym stopniu wpływa na usprawnienie pracy pracowników
Zamawiającego. W związku z powyższym Izba uznała za jak najbardziej zasadne
wprowadzenie do treści specyfikacji warunków w zakresie określonych czasów odpowiedzi
systemu na działania operacyjne użytkowników. W przedstawionej powyżej kompozycji
specyfikacji Izba również nie doszukała się postanowień naruszających przepisy ustawy.
Następnie Izba wskazuje, że zarówno w odpowiedzi na odwołanie jak również w toku
rozprawy, Odwołujący nie wykazał w sposób wystarczający, że wymagania Zamawiającego,
dotyczące czasów reakcji systemu na działania operacyjne użytkowników są nieracjonalne i
niemożliwe do spełnienia. Odwołujący oparł się jedynie na własnych twierdzeniach.
Izba podkreśla, że na podstawie art. 190 ust. 1 ustawy strony i uczestnicy
postępowania odwoławczego są obowiązani wskazywać dowody do stwierdzenia faktów, z
których wywodzą skutki prawne. Dowody na poparcie swych twierdzeń lub odparcie
twierdzeń strony przeciwnej strony i uczestnicy postępowania odwoławczego mogą
przedstawiać aż do zamknięcia rozprawy.
Wskazany powyżej przepis nakłada na strony postępowania obowiązek, który
zarazem jest uprawnieniem stron i polega na wykazywaniu dowodów na stwierdzenie faktów,
z których wywodzą skutki prawne.
Bez wątpienia postępowanie odwoławcze prowadzone przez Izbą stanowi
postępowanie kontradyktoryjne, czyli sporne a zatem z istoty takiego postępowania wynika,
iż spór toczą strony postępowania i to one mają obowiązek wykazywania dowodów, z
których wywodzą określone skutki prawne.
Art. 14 ustawy stanowi, że do czynności podejmowanych przez zamawiającego i
wykonawców w postępowaniu o udzielenie zamówienia publicznego stosuje się przepisy
ustawy z dnia 23 kwietnia 1964 roku – Kodeks cywilny (dalej: „k.c”), jeżeli przepisy ustawy
nie stanowią inaczej. Zgodnie z art. 6 Kodeksu cywilnego ciężar udowodnienia faktu
spoczywa na osobie, która z faktu tego wywodzi skutki prawne.
Zatem należy wskazać, iż właśnie z tej zasady wynika reguła art. 190 ust. 1 ustawy.
Przepis art. 6 Kodeksu cywilnego wyraża dwie ogólne reguły, a mianowicie wymaganie
udowodnienia powoływanego przez stronę faktu, powodującego powstanie określonych
skutków prawnych oraz usytuowanie ciężaru dowodu danego faktu po stronie osoby, która z
faktu tego wywodzi skutki prawne; ei incubit probatio qui dicit non qui negat (na tym ciąży
dowód kto twierdzi a nie na tym kto zaprzecza).
Tym samym w ocenie Izby Odwołujący nie wykazał, że wymogi odnoszące się
czasów odpowiedzi na działania operacyjne użytkowników, zostały przez Zamawiającego
określone nieprawidłowo z uwagi na to, iż są one nieuzasadnione i niemożliwe do uzyskania,
a także utrudniające uczciwą konkurencję.
Wobec tego Izba uznała ww. zarzuty zgłoszone przez Odwołującego za
niepotwierdzone.
XIV. Zarzut dotyczący eksportu widoków ekranowych i raportów do wskazanych
formatów
Izba ustaliła, że Zamawiający w pkt 37 Załącznika nr 1 do siwz sprecyzował
następujące wymaganie: „37. System musi zapewnić możliwość eksportu wszystkich
widoków ekranowanych i wygenerowanych raportów do formatów np. .txt, .xls, .doc z
możliwością sortowania raportów."
Po dokonaniu szczegółowej analizy zgłoszonego zarzutu Izba stwierdziła, że zarzut
jedynie w części jest zasadny.
W omawianej kwestii Zamawiający w treści odpowiedzi na odwołanie wyjaśniał, że
posiada i wykorzystuje w codziennej pracy oprogramowanie Microsoft Office. W związku z
tym posiada uzasadnioną potrzebę przygotowywania różnego rodzaju raportów w formacie
MS Word czy tez MS Excel. Ponadto zwracał uwagę, że w treści siwz (str. 25 pkt. 2.2. ust. h
załącznika nr 1 do siwz) wskazał pakiet MS Office jako element, który zamierza udostępnić
do realizacji zamówienia. Również w toku rozprawy Zamawiający podkreślał, że
wydrukowanie, chociażby „budżetu” w pliku .txt, przed przekazaniem odpowiednim osobom,
wymagałoby odpowiedniej obróbki, która związana byłaby z dodatkowym nakładem pracy i
byłaby bardzo czasochłonna.
W związku z tym Izba dała wiarę powyższy wyjaśnieniom Zamawiającego i
potwierdziła zasadność twierdzenia, że pliki .txt mogą być przydatne, ale tylko w określonych
sytuacjach. Tym samym nie sposób zgodzić się z Odwołującym, że posługiwanie się jedynie
formatem .txt jest w zupełności wystarczające.
Następnie Izba odnosiła się kolejnego aspektu zgłoszonego zarzutu, tj. do posłużenia
się przez Zamawiającego, przy formułowaniu wymogu, skrótem ”np.” W omawianym zakresie
istotnym jest, że Zamawiający, używając skrótu „np.” spowodował, że katalog formatów, ma
charakter katalogu otwartego. Takie działanie Zamawiającego skutkuje tym, że wykonawca
ubiegający się o udzielenie zamówienia nie posiada szczegółowej wiedzy w zakresie
formatów, ponieważ Zamawiający nie dokonał ich enumeratywnego wyliczenia, a jedynie
przykładowo wskazał na formaty .txt, .xls czy też .doc.
Zatem Izba stanęła na stanowisku, że opisane powyżej postanowienie siwz nie
spełnia wymagań przepisu art. 29 ust. 1 Pzp. Wobec tego Izba uwzględnił zgłoszony zarzut i
nakazała w pkt. 37 na str. 41 Załącznika nr 1 siwz – usunięcie skrótu „np.” i określenie
zamkniętego katalogu wymaganych przez Zamawiającego formatów.
XV.
Zarzut dotyczący niewskazania miejsca wykonania wdrożenia
XX. Zarzut dotyczący zestawienie jednostek objętych projektem i zakresu
funkcjonalnego
XXI. Zarzut dotyczący liczby jednostek objętych projektem
Biorąc pod uwagę charakter ww. zarzutów i argumentacji ich dotyczącą Izba uznała
za uzasadnione wspólne ich omówienie.
Z ustaleń Izby wynika, że Zamawiający w pkt 2 Załącznika nr 1 do siwz jako miejsce
wykonania zamówienia podał: „w lokalizacjach Zamawiającego”. Zaś co liczby jednostek
objętych projektem to Zamawiający przedstawił wykaz w formie Załącznika nr 2 [plik
2115_zalacznik_siwz_2016-01-29_2]. W załączniku w kolumnie „Nazwa jednostki”
wyspecyfikowano IV grupy jednostek. W IV grupie w pozycjach 4 oraz od 6 do 14 podano
„Dom Pomocy Społecznej”. Załącznik zawiera oznaczenia kolorystyczne: białe, żółte,
czerwone, czarne i brak jest legendy, objaśniającej ww. oznaczenie.
Przede wszystkim należy zwrócić uwagę, że przedmiotem zamówienia jest dostawa,
wdrożenie, dostosowanie do potrzeb Zamawiającego, uruchomienie oraz serwis
gwarancyjny i usługi asysty technicznej standardowego rozwiązania klasy ERP,
wspierającego zarządzanie finansami miasta w Urzędzie Miasta Łodzi i Miejskich
Jednostkach Organizacyjnych. Biorąc pod uwagę powyższe, stwierdzić należy, że w
kontekście informacji zawartych w załączniku nr 2, posłużenie się przez Zamawiającego
jedynie stwierdzeniem „w lokalizacjach Zamawiającego” należy uznać za nieprawidłowe,
bowiem takie określenie jest zbyt ogólnikowe i może rodzić szereg wątpliwości po stronie
wykonawców ubiegających się o udzielenie zamówienia. W szczególności treść załącznika,
poza podaniem nazw jednostek - które w szeregu pozycji (poz. 4 oraz od 6 do 14) są jedynie
nazwą, która w żaden sposób nie zezwala na ustalenie lokalizacji jednostki - nie zawiera
informacji na temat lokalizacji danej jednostki. O ile, zapewne bez problemu można ustalić
lokalizację jednostki, chociażby takiej jak Zarząd Dróg i Transportu (poz. 11), to w ocenie
Izby nie sposób określić lokalizacji jednostek tj. Dom Pomocy Społecznej (poz. 4 oraz od 6
do 14) bez dodatkowych informacji w tym zakresie.
W kwestii oznaczenia kolorystycznego, zawartego w załączniku nr 2 Zamawiający
wyjaśnił, że kolory nie mają w tym przypadku żadnego znaczenia, ich pojawienie się oraz
takie a nie inne przyporządkowanie, jest czysto przypadkowe. W sytuacji, gdyby oznaczenie
kolorystyczne miało czemukolwiek służyć, to Zamawiający zawarłby stosowne objaśnienie w
załączniku.
Wobec tego Izba uwzględniła ww. zarzuty odwołania opisane w pkt. XV i XXI i
nakazała Zamawiającemu zmianę siwz w pkt. 2 na str. 1 Załącznika nr 1 siwz - Opis
Przedmiotu Zamówienia przez podanie dokładnych lokalizacji wykonywania zamówienia, z
wyszczególnieniem wszystkich jednostek, w których będzie realizowane zamówienie.
Natomiast zarzut z pkt. XXI Izba uznała za niezasadny.
XVI. Zarzut dotyczący niespójności w zakresie licencji
Z ustaleń Izby wynika, że w zakresie licencji Zamawiający w siwz zawarł następujące
postanowienia:
• w pkt h) Załącznik nr 1 do siwz (str. 3) „Licencje dostarczone dla oferowanego
rozwiązania muszą umożliwiać obsługę nieograniczonej liczby jednostek
organizacyjnych";
• pkt. 11 Załącznik nr 1 do siwz (str. 146-147) „W ramach przedmiotu zamówienia
Wykonawca w zależności od posiadanych praw zobowiązany jest do udzielenia
licencji/sublicencji na: 11.1. Oprogramowanie standardowe rozwiązania klasy ERP na
użytkownika nazwanego 800 licencji z możliwością udzielania licencji/sublicencji na
innych użytkowników (…)”;
• zgodnie z Załącznikiem nr 1 do siwz str. 150 pkt. 2 a) „Zamawiający ma prawo
„zakupić dodatkowe licencje dla standardowego rozwiązania klasy ERP maksymalnie
500 licencji”.
Analiza opisanych powyżej postanowień specyfikacji, zdaniem Izby, w jasny, klarowny
sposób formułuje wymagania Zamawiającego w zakresie dostarczenia licencji. Po pierwsze
podnieść należy, że w pkt 11 Załącznika nr 1 do siwz Zamawiający zawarł wymagania
dotyczące licencji. W treści powyższego punktu Zamawiający szczegółowo opisał ilość,
rodzaj i zakres licencji, które ma dostarczyć wykonawca. Następnie w pkt 13 „Prawo opcji”
Zamawiający zastrzegł, że w ramach prawa opcji może zakupić dodatkowe licencje dla
standardowego rozwiązania klasy ERP maksymalnie 500 licencji. W ocenie Izby badanie
przytoczonych powyżej postanowień specyfikacji nie pozwala na sformułowanie wniosku, że
zapisy te są niejasne i wzajemnie sprzeczne. Natomiast treść siwz, tj. „Licencje dostarczone
dla oferowanego rozwiązania muszą umożliwiać obsługę nieograniczonej liczby jednostek
organizacyjnych" zdaniem Izby należy odnosić do jednostek organizacyjnych, objętych
zamówieniem. Rację ma Zamawiający, który wskazywał, że z literalnego brzmienia ww.
postanowienia wynika, że dostarczone prze wykonawcę licencje dla oferowanego
rozwiązania muszą umożliwiać obsługę nieograniczonej liczby jednostek. Zamawiający
wyjaśniał, że powyższy zapis jest uwarunkowany tym, że Zamawiającemu, potrzebne są
licencje nie tylko dla jego macierzystej jednostki, ale również dla różnych jednostek
organizacyjnych, które się wciąż zmieniają.
W związku z tym Izba uznała zgłoszony zarzut za niezasadny.
XVII. Zarzut dotyczący harmonogramu wdrożenia
Nie było sporne między stronami, że Zamawiający w w pkt. 1.1.2. „Etapowanie prac”
określił wymagania w zakresie harmonogramu prac związanych z wykonaniem zamówienia.
W ocenie Odwołującego żądania Zamawiającego w omawianym zakresie są niemożliwe do
spełnienia.
Po rozpoznaniu powyższego zarzutu Izba uznała, że Odwołujący nie wykazał w
sposób wystarczający, że spełnienie wymogów postawionych przez Zamawiającego jest
niemożliwe do spełnienia. Odwołujący poza własnymi twierdzeniami nie przedstawił żadnych
dowodów w celu wykazania zasadności zarzutów. Ponadto Odwołujący nie uzasadnił,
dlaczego żąda wydłużenia właśnie II i III etapu prac i dlaczego akurat 6 miesięcy. W tym
miejscu podkreślić należy, że to właśnie na Odwołujący, zgodnie z art. 190 ust. 1 Pzp
spoczywa obowiązek wykazania nierealności terminów zawartych w specyfikacji. W tym
zakresie Izba prezentuje analogiczną argumentację jak w zakresie XIII.
Zgłoszony zarzut Izba uznała za niepotwierdzony.
XVIII. Zarzut dotyczący kosztów szkoleń
XIX. Zarzut dotyczący szkoleń administratorów
Biorąc pod uwagę charakter ww. zarzutów i argumentacji ich dotyczącej Izba uznała
za uzasadnione wspólne ich omówienie.
Na początku należy wskazać, że zarzut opisany w pkt XVIII Izba uznała za
bezzasadny, natomiast analiza zarzutu z pkt. XIX potwierdziła jego słuszność.
Zgodzić się należy z Zamawiającym, że pkt. 6 Załącznika nr 1 do siwz (str. 129 – 133)
zawiera szczegółowy opis wymagań Zamawiającego w obszarze szkoleń. Zamawiający w
poszczególnych podpunktach wskazał wszystkie, niezbędne informacje tym zakresie,
poczynając od zakresu szkolenia, aż po ilość osób do przeszkolenia w poszczególnych
obszarach. Również w pkt 4.2.24 Załącznika nr 1 do siwz (str. 32) Zamawiający opisał swoje
wymagania odnośnie szkoleń: „4.2.24 Wykonawca w ramach zamówienia musi zapewnić
całe środowisko szkoleniowe niezbędne do przeprowadzenia szkoleń użytkowników
Zamawiającego”.
W ramach rozpoznania zarzutu również nie sposób pominąć ppkt 6.1 lit d), do którego
odwoływał się również Comarch, w którym Zamawiający podał, że „wykonawca zobowiązany
jest do zorganizowania i pokrycia wszelkich kosztów związanych z przeprowadzeniem
szkoleń”.
W świetle przytoczonych powyżej postanowień specyfikacji w ocenie Izby nie
budzącym żadnych wątpliwości jest, że to wykonawca powinien ponieść wszystkie koszty,
związane z przeprowadzeniem szkoleń, a zatem również te dotyczące: najmu sali, stacji
roboczych, organizacji przerw lunchowy oraz przejazdów uczestników szkoleń.
Zaś co do ilości administratorów, którzy mają być przeszkoleni to Izba stanęła na
stanowisku, że nieuprawnione jest powoływanie się przez Zamawiającego na postanowienie
pkt. 6.6.1 Załącznika nr 1 do siwz (str. 133), w którym wskazano, że szkoleniem będzie
objętych 2 administratorów, bowiem powyższy punkt dotyczy wyłącznie sytuacji, w której
wykonawca korzysta z rozwiązania, posiadanego przez Zamawiającego. Sytuacja opisana w
pkt. 6.6.3. Załącznika nr 1 do siwz (str. 133) różni się tej opisanej powyżej tym, że dotyczy
stosowania przez wykonawcę innego rozwiązania niż te opisane w pkt. 6.6.1. W związku z
tym nie można przez analogię założyć, że w tym przypadku Zamawiający również oczekuje
przeszkolenia 2 administratorów. Poza tym pkt. 6.6.3. nie zawiera żadnego odesłania do
punktu pkt. 6.6.1. Wobec tego, że Zamawiający w punkcie pkt. 6.6.3. nie podał ilości
administratorów, których należy przeszkolić to Izba uznała, że brak takiej informacji
powoduje, że informacje podane przez Zamawiającego są niepełne, a zatem mamy do
czynienia z naruszeniem art. 29 ust. 1 Pzp.
Tym samym Izba uwzględniła zgłoszony zarzut i nakazała Zamawiającemu w pkt.
6.6.3 na str. 133 Załącznika nr 1 siwz określenie liczby administratorów, w odniesieniu do
których wykonawca ma obowiązek zapewnienia szkoleń.
XXII. Zarzut dotyczący migracji
Przedmiotem ww. zarzutu jest zaniechanie Zamawiającego, polegające
nieprecyzyjnym podaniu informacji, niezbędnych wykonawcy do prawidłowego sporządzenia
oferty.
Z ustaleń Izby poczynionych w oparciu o dokumentację postępowania wynika, że
Zamawiający w formie Załącznika nr 5 do siwz (dwa zestawienia w zakładkach pliku Excel)
przedstawił 2 zestawienia, zawierające informacje na temat procesu migracji. Jedno z ww..
zestawień zawiera kolumnę „Nazwa i producent aktualnie eksploatowanego systemu.
Technologia”. W poszczególnych wierszach, kolumna nie zawiera informacji w zakresie
producenta i technologii, np. wiersze nr 1 - Centrum Informacji Turystycznej w Łodzi.
W ocenie Izby analiza tak zarysowanego stanu faktycznego prowadzi do wniosku, że
rację ma Odwołujący, który zarówno w złożonym odwołaniu jak i na rozprawie podnosił, że
informacje przedstawione przez Zamawiającego w obszarze migracji nie są kompletne i
wyczerpujące. Przed wszystkim należy zwrócić uwagę, że to właśnie Zamawiający jest
autorem opisanej powyżej tabeli, zawartej w załączniku nr 5. W związku z tym, zdziwienie
budzi, że Zamawiający jako twórca ww. dokumentu nie zawał w nim wszystkich danych,
których podanie sam narzucił, a które są niezbędne wykonawcy do prawidłowego
przygotowania i skalkulowania oferty.
Wobec tego Izba potwierdziła naruszenie przepisu art. 29 ust. 1 Pzp i nakazała
Zamawiającemu w tabeli Załącznika nr 5 do Opisu przedmiotu zamówienia – Zakres do
migracji i systemy źródłowe w miejskich jednostkach organizacyjnych Zamawiającego, w
kolumnie „Nazwa i producent aktualnie eksploatowanego systemu. Technologia”
uzupełnienie danych, dotyczących producenta oraz technologii, w odniesieniu do
wskazanych przez Zamawiającego w tabeli, systemów dla poszczególnych jednostek.
XXIII. Zarzut dotyczący technologii – przechowywanie plików typu skan
Z ustaleń Izby wynika, że w zakresie przechowywania plików Zamawiający w pkt
4.2.14 oraz 4.2.15 Załącznika nr 1 do siwz (str. 30-31) postawił następujące wymaganie:
„4.2.14. Wszystkie dane zgromadzone w Systemie powinny być przechowywane w
wspólnej bazie danych z wyłączeniem plików z załącznikami, które muszą być
przechowywane w systemie plikowym serwera aplikacyjnego. Zamawiający nie zaakceptuje
rozwiązania, w którym obiekty (np. skany dokumentów jako załączniki itp.) są
przechowywane w bazie danych w polach typu BLOB.
4.2.15. Załączniki, skany dokumentów itp. muszą być umieszczane na dyskach
serwera aplikacyjnego jako pliki. Wykonawca musi zaproponować sposób katalogowania
tych materiałów na dyskach tak, aby ograniczenia systemu operacyjnego nie miały wpływu
na zarządzanie plikami."
Osią sporu w niniejszej sprawie jest rozstrzygnięcie kwestii, czy opisane powyżej
wymagania Zamawiającego są uzasadnione jego obiektywnymi potrzebami oraz czy nie
powodują naruszenia przepisów ustawy w zakresie ograniczającym konkurencję ? W ocenie
Izby wyjaśnienia Zamawiającego uzasadniają postawienie przytoczonego powyżej wymogu i
nie powodują naruszenia przepisów ustawy.
Zamawiający w toku rozprawy wskazywał, że postawił taki wymóg w ramach
prowadzonego postępowania, ponieważ od wielu lat i na co dzień, stosuje rozwiązanie
opisane w specyfikacji. Z praktyki Zamawiającego wynika, że jest to rozwiązanie niezawodne
i proste w stosowaniu, dlatego też dokonał takich, a nie innych zapisów siwz. Zamawiający
podkreślał również, że przechowuje już pliki w opisany powyżej sposób i w związku z tym nie
chciałby stosować nowych rozwiązań, a kontynuować te dotychczas praktykowane i
sprawdzone. Ponadto Zamawiający wskazywał na wzrost kosztów utrzymania Systemu w
przypadku zastosowania rozwiązania proponowanego przez Odwołującego. Nie kwestionuje
merytorycznie rozwiązań wskazywanych przez Comarch jako możliwych do wykonania,
jednak uważa, że rozwiązanie zaproponowane przez niego jest rozwiązaniem, które będzie
lepiej funkcjonować w warunkach Zamawiającego.
W miejscu należy zwrócić uwagę, że w toku rozprawy Odwołujący, co prawda nie
zgadzał się z Zamawiającym, że proponowane przez niego rozwiązanie jest rozwiązaniem
„gorszym”, ale stwierdził również, że oba rozwiązania posiadają wady i zalety.
Biorąc pod uwagę powyższe, Izba stwierdziła, że skoro oba rozwiązania, zarówno te
wymagane przez Zamawiającego jak i te proponowanego przez odwołującego, są na
równorzędnym poziomie i są powszechnie stosowane, i skoro Zamawiający w tym momencie
już posiada określone rozwiązanie to uzasadnia to wymóg Zamawiającego, opisany w
specyfikacji w pkt 4.2.14 oraz 4.2.15 Załącznika nr 1 do siwz. W świetle przedstawionej
argumentacji również nie może się ostać zarzut naruszenia przepisów ustawy oparty o
przepis art. 29 ust. 2 Pzp.
Tym samym Izba oddaliła zgłoszony zarzut, uznając jego niezasadność.
XXIV. Zarzut dotyczący technologii – narzędzie do raportowania
Z ustaleń Izby wynika, że Zamawiający określił w pkt 19 Załącznika nr 1 do siwz (str.
39) następujące wymaganie: „19. Generator raportów: System powinien umożliwiać
tworzenie nowych raportów lub modyfikowanie standardowych ustawień istniejących
raportów w sposób przyjazny dla użytkownika. Wymagana jest: (...)
- przedstawienie zbiorów danych w formie rozwijanych list do wyboru (...)
- przedstawienie list pól danej tabeli w formie rozwijanych list do wyboru (...)"
W zakresie omawianego zarzutu Odwołujący w toku rozprawy wyjaśniał, że na rynku
istnieją różne rozwiązania dotyczące generatorów i co do zasady nie oponuje przeciwko
temu żeby Zamawiający postawił taki wymóg, a jedynie sprzeciwia się temu aby
przedstawienie zbiorów danych było w formie rozwijanych list, ponieważ takie ukształtowanie
siwz dyskryminuje inne rozwiązania, które wykorzystuje listy, które nie są rozwijane.
Natomiast Zamawiający twierdził, że rozwijane listy są dostępne we wszystkich znanych mu
systemach, zatem postawienie takiego wymogu nie ogranicza konkurencji, czemu
Odwołujący nie zaprzeczył.
Wobec tego Izba dała wiarę zaprezentowanym powyżej wyjaśnieniom
Zamawiającego i uznała, że zgłoszony zarzut nie potwierdził się.
XXV. Zarzut dotyczący odpowiedzialności za koszty wdrożenia
Izba ustaliła, że Zamawiający określił w pkt 4.2.1 Załącznika nr 1 do siwz (str. 29)
następujące wymaganie: „4,2.1. Wszelkie koszty związane z realizacją przedmiotu
zamówienia ponosi Wykonawca."
Izba uznała argumentację Odwołującego wyrażoną w odwołaniu za nietrafną,
ponieważ w ocenie Izby Odwołujący nie miał żadnych podstaw, aby uznać, że będzie
zobowiązany do ponoszenia kosztów wynagrodzeń pracowników Zamawiającego, czy też
zużycia mediów w pomieszczeniach Zamawiającego. Zdaniem Izby tego rodzaju sposób
argumentacja jest absurdalna, ponieważ gdyby uznać jej dopuszczalność, w oparciu o
przytoczone powyżej postanowienie siwz, to wówczas można by było przypuszczać, że
wykonawca ubiegający się o zamówienie, poniesie również wszystkie pozostałe koszty
Zamawiającego, które chociaż w drobnej części będą mogły być zaliczone do tych
związanych z realizacją przedmiotu zamówienia.
W związku tym Izba uznała zgłoszony zarzut za bezzasadny.
XXVI. Zarzut dotyczący niespójnej nomenklatury pojęć stosowany w siwz
Stan faktyczny sprawy związany ww. zarzutem został wyczerpująco i zgodnie z
rzeczywistością przytoczony w treści odwołania, zatem Izba zrezygnowała z ponownego
przytaczania definicji pojęć kwestionowanych przez Odwołującego.
Izba potwierdza, że Zamawiający zarówno w załączniku nr 1 do siwz jak również w §
1 Istotnych Postanowień Umowy zdefiniował poszczególne pojęcia, z jego punktu widzenia,
istotne dla prowadzonego postępowania. Izba przeprowadziła analizę definicji
wskazywanych pojęć i nie dopatrzyła się niespójności w tym zakresie.
Za wiarygodne Izba również uznała wyjaśnienia Zamawiającego, prezentowane w
toku rozprawy, odnoszące się przykładu podawanego przez Odwołującego na str. 20
odwołania w zakresie pojęcia „System”.
Wobec tego Izba oddaliła zgłoszony zarzut jako nieuzasadniony.
XXVII. Zarzut dotyczący prac dodatkowych, w szczególności dodatkowej integracji
Systemu
Z ustaleń Izby wynika, że zgodnie z pkt. h) Załącznik nr 1 do siwz (str. 5) zamówienie
obejmuje m.in. Integrację Systemu z pozostałymi elementami funkcjonującymi u
Zamawiającego.
W pkt 4.6. „Integracja" dokumentu Załącznik nr 1 do SIWZ (str. 98) następujące
wymaganie: „System musi być zintegrowany z poniższymi systemami (wykaz systemów do
integracji zostanie zweryfikowany i uzupełniony w trakcie opracowania Projektu
Rozwiązania) w zakresie opisanym w Projekcie Rozwiązania.
Uwaga! Jeżeli w trakcie prac nad Projektem Rozwiązania konieczne będzie uwzględnienie
integracji z innymi systemami niż wymienione poniżej w wymaganiu nr 568, Zamawiający
zleci integrację w ramach prac dodatkowych."
Natomiast w pkt 9. „Prace dodatkowe" ppkt. d) Załącznika nr 1 do siwz (str. 141-142)
Zamawiający określił: „Wykonawca w ramach prac dodatkowych zobowiązany jest do
ś
wiadczenia usług w łącznej ilości 9000 osobogodzin do: (...) d. integracji z innymi
systemami niż wymienione w pkt. Integracja".
W § 4 ust. 4.9 Istotnych Postanowień Umowy Zamawiający wskazał, że prace
dodatkowe będę wykonywane przez wykonawcę na podstawie zleceń Zamawiającego w
sposób i w terminach uzgodnionych przez strony oraz za wynagrodzeniem o którym mowa w
§ 21 ust. 21.2.
W § 2 ust. 2.5 Istotnych Postanowień Umowy Zamawiający podał, że odbiór każdego
etapu, kończy się podpisanie Końcowego Protokołu Odbioru Etapu. (…).
W załączniku nr 4 do umowy w rozdziale I w pkt. 1 Zamawiający podał: „ Niezależnie
od odbiorów poszczególnych Etapów, odrębnym odbiorom podlegają Produkty i Usługi
dostarczone w ramach każdego z Etapów oraz prace realizowane w ramach prac
dodatkowych i prawa opcji. (…)”.
Biorąc pod uwagę powyższe uregulowania Zamawiającego opisane powyżej Izba
stanęła na stanowisku, że Zamawiający szczegółowo opisał w specyfikacji wszystkie
niezbędne składniki i okoliczności związane z wykonanie prac dodatkowych. Tym samym
Izba nie podzieliła argumentacji, prezentowanej przez Comarch, że w siwz brak jest
stosownych regulacji i precyzyjnych zapisów, co uniemożliwia wycenę przedmiotu
zamówienia. Nie sposób również zgodzić się z zarzutem, że odbiór prac dodatkowych może
mieć wpływ na odbiór podstawowego przedmiotu umowy, bowiem zarówno treść § 2 ust. 2.5
Istotnych Postanowień Umowy, jak również rozdziału I pkt. 1 załączniku nr 4 do umowy
wprost podano, że odbiory poszczególnych etapów będą dokonywane odrębnie od odbiorów
prac dodatkowych.
Wobec tego Izba uznała zgłoszony zarzut za niezasadny.
XXIX. Zarzut dotyczący kryterium oceny ofert pn. JAKOŚĆ – waga 20 %
W zakresie powyższego zarzutu Izba prezentuje taką samą argumentacje jak w
przypadku omówienia zarzutu w pkt. 7 odwołania o sygn. akt KIO 163/16, a zatem jej
powtarzanie Izba uznała za niecelowe.
Konkludując, w kontekście przedstawionych powyżej rozważań Izby stwierdzić
należy, że Zamawiający naruszy wskazane w treści uzasadnienia przepisy Pzp, co
niewątpliwie może mieć istotny wpływ na wynik prowadzonego postępowania. Wobec tego
Izba uwzględniła odwołanie w opisanej wyżej części i nakazała w wyroku dokonanie
określonej zmiany specyfikacji.
Uwzględniając powyższe, na podstawie art. 192 ust. 1 i 2 Pzp orzeczono jak w
sentencji.
O kosztach postępowania orzeczono na podstawie art. 192 ust. 9 i 10 Pzp stosownie
do wyniku sprawy oraz zgodnie z § 3 pkt 1 i § 5 ust. 2 pkt 1 rozporządzenia Prezesa Rady
Ministrów z dnia 15 marca 2010 r. w sprawie wysokości i sposobu pobierania wpisu od
odwołania oraz rodzajów kosztów w postępowaniu odwoławczym i sposobu ich rozliczania
(Dz. U. Nr 41, poz. 238).
…………………………..
Otrzymuj raz w tygodniu aktualne informacje
o zmianach w prawie oraz komentarzach ekspertów
Otrzymasz darmowy e-book w prezencie!
„6 pytań o znowelizowane przepisy Pzp"