KIO 163/16

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;

1

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,

2

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: ……………………………

3

Sygn. akt: KIO 163/16

Sygn. akt: KIO 170/16

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

4

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:

1. wykreślenia z siwz możliwości udostępnienia przez Zamawiającego rozwiązań MS

5

SQL Server 2014,

2. wykreślenia z siwz obowiązku dostarczenia licencji SIMPANA i zastąpienia go dostawy rozwiązania zapewniającego odpowiednią, wymaganą przez obowiązkiem

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.

6

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.

7

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

nie można przyjąć, iż rozwiązań SimpanaCommVault, bowiem niedopuszczenie 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

8

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

9

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.

10

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:

1. Scenariusz nr 1 - Obsługa wpłat masowych i windykacja zaległości

2. Scenariusz nr 2 - Obsługa wpłaty zobowiązanego na należność objętą tytułem

wykonawczym

3. Scenariusz nr 3 - Określenie przypisu podatku na podstawie korekty deklaracji

11

podatkowej

4. Scenariusz nr 4 - Ustalenie podatku od nieruchomości w wyniku prowadzenia

postępowania podatkowego (decyzje ustalające, zmieniające lub uchylające)

5. Scenariusz nr 5 - Egzekucja Należności Pieniężnych

6. 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

Wykonawca dostarczy szczegółowe zestawienie dostarczonego Aplikacyjnego. Oprogramowania, które zostanie zawarte w Dokumentacji powykonawczej

12

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

Migracji danych i integracji Systemu, a także przygotowaniem Zamawiającego,

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

13

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

14

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).

2. 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;

3. 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

15

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

16

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.

17

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

18

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

19

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,

20

- 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,

21

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

22

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.

23

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

24

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

25

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

26

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

27

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

28

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

29

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,

30

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

31

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

32

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.

33

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.

34

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

35

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"

36

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

37

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ń

38

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".

39

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

40

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,

41

• 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

42

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.

43

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

44

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

45

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

46

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.

47

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 Maksymalna ilość punktów jakie mo e

kryterium otrzymać oferta za dane kryterium

30% 30 punktów 1. Cena oferty brutto (C)

Prace dodatkowe (cena za 4% 4 punkty 2.

osóbogodzinę) (PD)

3. Wydłu enie gwarancji (o kolejny 2% 2 punkty miesiąc) (WG)

Wydłu enie asysty technicznej (o 2% 2 punkty 4:

kolejny miesiąc) (WAT)

. 2% 2 punkty 5. Koszt dodatkowej licencji (KDL)

Stopień gotowości Systemu do 40% 40 punktów 6.

wdro enia (SGSW)

20% 20 punktów 7. Jakość (J)

100% 100 punktów Łącznie

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

48

1 pkt 2 pkt 3 pkt 4 pkt

1 Wygląd aplikacji czytelność / przejrzystość 1 szata graficzna / układ pól na ekranie

2 Intuicyjność w chronologia działań J logiczne działania zakresie obsługi

Zło oność

3 wprowadzania liczba operacji do uzyskania ‘wyniku ! czy danych/wykonywania system uwzględnia skróty klawiszowe

poleceń

Język zrozumiały dla u ytkownika np.: czy Nazewnictwo 4 opis pól jest adekwatny do modułu; czy

stosowane skróty są zrozumiałe

Pomoc dla 5 łatwość wyszukiwania informacji / zawiera u ytkownika z

ście ki postępowania poziomu aplikacji

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.:

1. 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)?

2. 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

49

zasługiwała na maksymalna liczbę punktów, a jaka będzie kolejnością gorszą, czy z tego

punktu widzenia wadliwą (nieintuicyjną)?

3. 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?

4. Ł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

50

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.

51

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).

52

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.

53

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ł.

54

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ść

55

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

56

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,

57

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

58

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

59

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

60

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.

61

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:

62

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

63

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ę.

64

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

65

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)

66

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

67

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).

68

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,

69

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

70

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.

71

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.

72

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,

73

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.

74

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

75

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 rozwiązania klasy ERP, asysty technicznej standardowego

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.

76

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

77

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.

78

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.

79

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

80

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

81

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."

82

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

83

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.

84

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).

…………………………..

85