Wyrok KIO 163/16

Treść orzeczenia

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

UZASADNIENIE

Miasto Łódź – Urząd Miasta Łodzi, ul. Piotrkowska 104, 90-926 Łódź (dalej: „Zamawiający”) na podstawie przepisów ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz. U. z 2013 r., poz. 907 ze zm.) – zwanej dalej "ustawą" lub "Pzp" – prowadzi postępowanie o udzielenie zamówienia na „Dostawę i wdrożenie systemu informatycznego wspomagającego zarządzanie finansami Miasta”. Szacunkowa wartość przedmiotowego zamówienia jest wyższa od kwot wskazanych w przepisach wykonawczych wydanych na podstawie art. 11 ust. 8 Pzp. 29 stycznia 2016 r. Zamawiający opublikował ogłoszenie o zamówieniu w Dzienniku Urzędowym Unii Europejskiej pod nr 2016/S 020-31131. Specyfikacja istotnych warunków zamówienia (dalej: „siwz” lub „specyfikacja”) została opublikowana również w dniu 29 stycznia 2016 r.

KIO 163/16

W dniu 8 lutego 2016 r. wykonawca Sputnik Software Sp. z o.o., ul. Górecka 30, 60- 201 Poznań (dalej: „Odwołujący” lub „Sputnik”) wniósł do Prezesa Krajowej Izby Odwoławczej odwołanie, wobec następujących czynności Zamawiającego, polegających na: 1. opisaniu przedmiotu zamówienia przez wskazanie znaków towarowych w sposób nieuzasadniony specyfiką przedmiotu zamówienia, a tym samym utrudniający uczciwą konkurencję; 2. opisaniu przedmiotu zamówienia w sposób utrudniający uczciwą konkurencję, przez wymaganie, aby oferowane rozwiązanie było oparte o rozwiązanie, funkcjonujące na rynku od co najmniej 10 lat oraz było dostępne w wersji COTS; 3. określeniu warunków udziału w postępowaniu w sposób nieproporcjonalny do przedmiotu zamówienia i naruszający zasadę uczciwej konkurencji; 4. określenie kryteriów oceny ofert w kryterium „Jakość” oraz „Stopień gotowości Systemu” do wdrożenia w sposób niezapewniający obiektywizmu i naruszający 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