KIO 163/16, KIO 170/16

Sygn. akt: KIO 163/16 Sygn. akt: KIO 170/16 WYROK z dnia 2 marca 2016 r. Krajowa Izba Odwoławcza - w składzie: Przewodniczący: Ewa Kisiel Protokolant: Łukasz Listkiewicz po rozpoznaniu na rozprawie w dniach 23 i 26 lutego 2016 r. odwołań wniesionych do Prezesa Krajowej Izby Odwoławczej: A. w dniu 8 lutego 2016 r. przez wykonawcę Sputnik Software Sp. z o.o., ul. Górecka 30, 60-201 Poznań (Sygn. akt KIO 163/16), B. w dniu 8 lutego 2016 r. przez wykonawcę Comarch Polska S.A., al. Jana Pawła II 39a, 31-864 Kraków (Sygn. akt KIO 170/16), w postępowaniu prowadzonym przez Miasto Łódź – Urząd Miasta Łodzi, ul. Piotrkowska 104, 90-926 Łódź; przy udziale: A. wykonawcy COIG S.A., ul. Mikołowska 100, 40-065 Katowice, zgłaszającego swoje przystąpienie do postępowania odwoławczego o sygn. akt: KIO 163/16 po stronie odwołującego; B. wykonawcy Qumak S.A., al. Jerozolimskie 134, 02-305 Warszawa, zgłaszającego swoje przystąpienie do postępowania odwoławczego o sygn. akt: KIO 163/16 po stronie odwołującego; C. wykonawcy "S&T Services" Polska Sp. z o.o., ul. Postępu 21d, 02-676 Warszawa, zgłaszającego swoje przystąpienie do postępowania odwoławczego o sygn. akt: KIO 170/16 po stronie odwołującego; D. wykonawcy Sputnik Software Sp. z o.o., ul. Górecka 30, 60-201 Poznań, zgłaszającego swoje przystąpienie do postępowania odwoławczego o sygn. akt: KIO 170/16 po stronie odwołującego; E. wykonawcy Comarch Polska S.A., al. Jana Pawła II 39a, 31-864 Kraków, zgłaszającego swoje przystąpienie do postępowania odwoławczego o sygn. akt: KIO 163/16 po stronie zamawiającego orzeka: 1. uwzględnia oba odwołania (sygn. akt KIO 163/16 i KIO 170/16) i nakazuje Miastu Łódź – Urzędowi Miasta Łodzi, ul. Piotrkowska 104, 90-926 Łódź dokonanie zmiany specyfikacji istotnych warunków zamówienia (SIWZ): - na str. 7 Załącznika nr 1 SIWZ - Opis Przedmiotu Zamówienia, po słowie „Uwaga!”, doprecyzowanie informacji w odniesieniu do rodzajów szablonów raportów; - w pkt. 568 na str. 99 Załącznika nr 1 SIWZ - Opis Przedmiotu Zamówienia, uszczegółowienie informacji, przez podanie wszystkich niezbędnych danych do prawidłowego wykonania procesu integracji; - wykreślenie pkt. 37 lit b) ii. Załącznika nr 3 - Opisu przedmiotu zamówienia, dotyczącego tego, że wykonawca powinien dokonywać prezentacji zgodnie z kolejnością opisanych w SIWZ scenariuszy testowych; - w pkt 1.1 lit. i) na str. 3 Załącznika nr 1 SIWZ - Opis Przedmiotu Zamówienia – zastąpienie słowa „oprogramowania” określeniem „Oprogramowania Aplikacyjnego”; - pkt. 30 Załącznika nr 3 do Opisu przedmiotu zamówienia przez wydłużenie długości łącznego czasu prezentacji z 6 godzin zegarowych do co najmniej 7 godzin zegarowych; - w pkt. 37 na str. 41 Załącznika nr 1 SIWZ - Opis Przedmiotu Zamówienia – usunięcie skrótu „np.” i określenie katalogu wymaganych przez Zamawiającego formatów; - w pkt. 2 na str. 1 Załącznika nr 1 SIWZ - Opis Przedmiotu Zamówienia podanie dokładnych lokalizacji wykonywania zamówienia, z wyszczególnieniem wszystkich jednostek, w których będzie realizowane zamówienie; - w pkt. 6.6.3 na str. 133 Załącznika nr 1 SIWZ - Opis Przedmiotu Zamówienia określenie liczby administratorów, w odniesieniu do których wykonawca ma obowiązek zapewnienia szkoleń; - w tabeli Załącznika nr 5 do Opisu przedmiotu zamówienia – Zakres do migracji i systemy źródłowe w miejskich jednostkach organizacyjnych Zamawiającego, w kolumnie „Nazwa i producent aktualnie eksploatowanego systemu. Technologia” uzupełnienie danych, dotyczących producenta oraz technologii, w odniesieniu do wskazanych przez Zamawiającego w tabeli, systemów dla poszczególnych jednostek; - w pkt 13.8 SIWZ doprecyzowanie definicji, służących indywidualnej ocenie prezentacji, w ramach poszczególnych wymagań, w kryterium „Jakość”. 2. W pozostałym zakresie oddala oba odwołania. 3. Kosztami postępowania obciąża Miasto Łódź – Urząd Miasta Łodzi, ul. Piotrkowska 104, 90-926 Łódź i: 3.1. zalicza w poczet kosztów postępowania odwoławczego kwotę 30 000 zł 00 gr (słownie: trzydzieści tysięcy złotych zero groszy) uiszczoną przez wykonawców: Sputnik Software Sp. z o.o., ul. Górecka 30, 60-201 Poznań i Comarch Polska S.A., al. Jana Pawła II 39a, 31-864 Kraków, w kwotach równych po 15 000 zł 00 gr (słownie: piętnaście tysięcy złotych zero groszy) każdy z wykonawców, tytułem wpisów od odwołań, 3.2. zasądza od Miasta Łódź – Urząd Miasta Łodzi, ul. Piotrkowska 104, 90-926 Łódź kwotę 37 335 zł 00 gr (słownie: trzydzieści siedem tysięcy trzysta trzydzieści pięć złotych zero groszy), w tym: A. kwotę 18 735 zł 00 gr (słownie: osiemnaście tysięcy siedemset trzydzieści pięć złotych zero groszy) na rzecz wykonawcy Sputnik Software Sp. z o.o., ul. Górecka 30, 60-201 Poznań, stanowiącą koszty postępowania odwoławczego poniesione z tytułu wpisu od odwołania, wynagrodzenia pełnomocnika oraz dojazdu, B. kwotę 18 600 zł gr (słownie: osiemnaście tysięcy sześćset złotych zero groszy) na rzecz wykonawcy Comarch Polska S.A., al. Jana Pawła II 39a, 31-864 Kraków, stanowiącą koszty postępowania odwoławczego poniesione z tytułu wpisu od odwołania oraz wynagrodzenia pełnomocnika. Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. - Prawo zamówień publicznych (t.j. Dz. U. z 2015 r., poz. 2164) na niniejszy wyrok - w terminie 7 dni od dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu Okręgowego w Łodzi. Przewodniczący: …………………………… Sygn. akt: KIO 163/16 Sygn. akt: KIO 170/16 UZASADNIENIE Miasto Łódź – Urząd Miasta Łodzi, ul. Piotrkowska 104, 90-926 Łódź (dalej: „Zamawiający”) na podstawie przepisów ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz. U. z 2013 r., poz. 907 ze zm.) – zwanej dalej "ustawą" lub "Pzp" – prowadzi postępowanie o udzielenie zamówienia na „Dostawę i wdrożenie systemu informatycznego wspomagającego zarządzanie finansami Miasta”. Szacunkowa wartość przedmiotowego zamówienia jest wyższa od kwot wskazanych w przepisach wykonawczych wydanych na podstawie art. 11 ust. 8 Pzp. 29 stycznia 2016 r. Zamawiający opublikował ogłoszenie o zamówieniu w Dzienniku Urzędowym Unii Europejskiej pod nr 2016/S 020-31131. Specyfikacja istotnych warunków zamówienia (dalej: „siwz” lub „specyfikacja”) została opublikowana również w dniu 29 stycznia 2016 r. KIO 163/16 W dniu 8 lutego 2016 r. wykonawca Sputnik Software Sp. z o.o., ul. Górecka 30, 60- 201 Poznań (dalej: „Odwołujący” lub „Sputnik”) wniósł do Prezesa Krajowej Izby Odwoławczej odwołanie, wobec następujących czynności Zamawiającego, polegających na: 1. opisaniu przedmiotu zamówienia przez wskazanie znaków towarowych w sposób nieuzasadniony specyfiką przedmiotu zamówienia, a tym samym utrudniający uczciwą konkurencję; 2. opisaniu przedmiotu zamówienia w sposób utrudniający uczciwą konkurencję, przez wymaganie, aby oferowane rozwiązanie było oparte o rozwiązanie, funkcjonujące na rynku od co najmniej 10 lat oraz było dostępne w wersji COTS; 3. określeniu warunków udziału w postępowaniu w sposób nieproporcjonalny do przedmiotu zamówienia i naruszający zasadę uczciwej konkurencji; 4. określenie kryteriów oceny ofert w kryterium „Jakość” oraz „Stopień gotowości Systemu” do wdrożenia w sposób niezapewniający obiektywizmu i naruszający zasadę uczciwej konkurencji; 5. opisaniu przedmiotu zamówienia w sposób niewyczerpujący, nieuwzględniający wszystkich wymagań mających wpływ na sporządzenie oferty. Sputnik zarzucał Zamawiającemu naruszenie następujących przepisów Pzp: 1. art. 29 ust. 2 i 3 ustawy, przez opisanie przedmiotu zamówienia z wykorzystaniem takich znaków towarowych jak MS SQL Server 2014 i Simpana, a tym samym ograniczenie konkurencji; 2. art. 29 ust. 2 ustawy, przez nieuzasadnione wymaganie, aby oferowane rozwiązanie było oparte o rozwiązanie funkcjonujące na rynku od co najmniej 10 lat oraz było dostępne w wersji COTS; 3. art. 7 ust. 1 w związku z art. 22 ust. 4 ustawy, przez sformułowanie warunków udziału w postępowaniu, które uniemożliwiają złożenie ofert wykonawcom zdolnym do wykonania przedmiotu zamówienia, oferującym rozwiązania oparte o technologie typu Open Source; 4. art. 7 ust. 2 w związku z art. 91 ust. 1 i 2 ustawy, przez sformułowanie kryteriów oceny ofert w sposób niezapewniający obiektywizmu podczas oceny ofert w kryterium „Jakość”; 5. art. 7 ust. 1 w związku z art. 91 ust. 1 i 2 ustawy, przez sformułowanie kryteriów oceny ofert w sposób utrudniający uczciwą konkurencję w zakresie scenariuszy testowych w obszarze podatki i opłaty lokalne; 6. art. 29 ust. 1 ustawy, przez zaniechanie precyzyjnego i wyczerpującego określenia wymagań, dotyczących obowiązku wykonawcy do opracowania, w ramach wykonania przedmiotu zamówienia 250 szablonów raportów w Systemie zgodnie z wzorami uzgodnionymi w ramach Projektu Rozwiązania; 7. art. 29 ust. 1 ustawy, przez zaniechanie precyzyjnego i wyczerpującego określenia wymagań, dotyczących przedmiotu zamówienia w zakresie integracji z istniejącymi u Zamawiającego systemami informatycznymi. W związku z powyższym Odwołujący żądał nakazania Zamawiającemu: 1. wykreślenia z siwz możliwości udostępnienia przez Zamawiającego rozwiązań MS SQL Server 2014, 2. wykreślenia z siwz obowiązku dostarczenia licencji SIMPANA i zastąpienia go obowiązkiem dostawy rozwiązania zapewniającego odpowiednią, wymaganą przez Zamawiającego funkcjonalność, 3. wykreślenia wymagania, aby oferowane rozwiązanie oparte było o rozwiązania, funkcjonujące na rynku od co najmniej 10 lat, 4. wykreślenia wymagania, aby oferowane rozwiązanie oparte było o rozwiązania dostępne w wersji COTS, 5. modyfikacji warunku udziału w postępowaniu określonego w rozdz. 5 ust. 5.1. pkt 5.1.2. ppkt 5.1.2.1. siwz, przez jego następującą zmianę: należycie wykonał lub wykonuje w jednostce sektora finansów publicznych w rozumieniu ustawy - ustawa z dnia 27 sierpnia 2009 r. o finansach publicznych (Dz.U. z 2013 r., poz. 885, z późn.zm.) zamówienie polegające na dostawie systemu informatycznego (o wartości nie mniejszej niż 2 500 000,00 PLN brutto, podana wartość dostawy systemu i jego wdrożenia nie obejmuje dostawy sprzętu i wartości licencji baz danych i systemów operacyjnych) i jego wdrożeniu również w jednostkach podległych Zamawiającemu, obejmujące swoim zakresem obszary analogiczne do obszaru budżetowo-księgowego oraz podatkowego w rozumieniu siwz, 6. wykreślenia kryterium „Jakość”, jako nieistotnego z punktu widzenia oceny oferty i niezapewniającego obiektywizmu, oraz przeniesienie odpowiednich elementów do wymagań odnośnie prac projektowych po podpisaniu umowy lub alternatywnie nakazanie Zamawiającemu doprecyzowania kryterium oceny oferty „Jakość” w taki sposób, aby wykonawca składający ofertę mógł w sposób jednoznaczny ocenić, jaką ocenę jest w stanie uzyskać, w odniesieniu do posiadane obecnie rozwiązania, 7. wykreślenia z załącznika nr 4 do siwz, scenariuszy testowych w odniesieniu do obszaru opłat i podatków; 8. doprecyzowania wymagań w zakresie obowiązku wykonawcy do opracowania w ramach wykonania przedmiotu zamówienia 250 szablonów raportów w Systemie lub alternatywnie do wykreślenia rzeczonych wymagań z siwz, 9. doprecyzowania wymagań, w zakresie integracji z istniejącymi u Zamawiającego systemami informatycznymi, szczegółowe opisanie wszystkich WebSerwisów i/lub plików wymiany wraz z opisem i wskazaniem danych wejściowych oraz danych wyjściowych. W uzasadnieniu odwołania Odwołujący wyjaśniał: I. Zgodnie z rozdz. 1 pkt 1.1. lit. c) Załącznika nr 1 do specyfikacji, Zamawiający wymaga, aby oferowane rozwiązanie umożliwiało eksploatację na platformie bazy danych MS SQL Server 2014, którą Zamawiający zamierza przeznaczyć do realizacji zamówienia. W przypadku, gdy oferowane przez wykonawcę rozwiązanie będzie funkcjonowało na bazie danych innej niż ta, którą Zamawiający zamierza przeznaczyć do realizacji niniejszego zamówienia, wykonawca zobowiązany jest zapewnić licencje bazy danych, na nieograniczoną liczbę użytkowników, niezbędne do pełnego wdrożenia oferowanego systemu, zgodnie z wymaganiami niniejszego dokumentu. Jednocześnie, zgodnie z rozdz. 2 pkt 2.2. Zamawiający wskazał, jaką infrastrukturę zamierza przeznaczyć do realizacji przedmiotowego zamówienia. Zgodnie z lit. c) ma to być m.in. licencja MS SQL Server 2014 w wersji Enterprise na 2 serwery. Powyższe, w ocenie Odwołującego, w znaczący sposób ogranicza konkurencję w przedmiotowym postępowaniu, przez preferowanie rozwiązań opartych o konkretne, wskazane środowisko bazodanowe. W szczególności wykonawcy oferujący rozwiązania oparte o środowisko MS SQL Server 2014, takie jak np. Microsoft Dynamics AX, mogą zaoferować wykonanie przedmiotu zamówienia po znacznie niższej cenie niż konkurencja, której rozwiązania oparte zostały na odmiennej technologii. Oznacza to, iż Zamawiający w sposób być może nieświadomy, ogranicza możliwość zastosowania rozwiązań alternatywnych, które nawet pomimo np. swojej innowacyjności czy otwartości, pozwoliłyby na zapewnienie dłuższego cyklu życia produktu, jakim jest zamawiany system. Podnosił, iż na rynku istnieją konkurencyjne, zapewniające tożsamą funkcjonalność rozwiązania bazodanowe takich producentów jak Oracle, czy IBM. Co jeszcze istotniejsze, istnieją również rozwiązania typu Open Source, które jako tzw. wolne oprogramowanie nie wymuszają na zamawiających ponoszenia istotnie większych kosztów utrzymania baz danych, przy jednoczesnym zapewnieniu możliwości ciągłego rozwoju oprogramowania przez profesjonalne podmioty informatyczne. Sputnik podkreślał, że w żadnej części siwz Zamawiający nie wskazał, z jakiego powodu takie środowisko jest przez niego preferowane, nie wspominając już o tym, że nie wyjaśnia, w jakim celu nabył takie licencje wcześniej, a w przedmiotowym postępowaniu chce je udostępnić potencjalnemu wykonawcy. Zauważyć również trzeba, iż specyfika przedmiotu zamówienia nie wymusza na Zamawiającym takiego działania. Powszechną praktyką na rynku informatycznym jest wymaganie przez Zamawiających, aby dostarczyli kompletne rozwiązanie informatyczne, składające się nie tylko z oprogramowania aplikacyjnego, ale również wszelkiego oprogramowania niezbędnego do prawidłowej pracy oprogramowana aplikacyjnego, w tym m.in. odpowiednich baz danych. Jednocześnie, zgodnie z rozdz. 1 pkt 1.1. lit. d) Załącznika nr 1 do siwz (Zamówienie obejmuje - str. 4) Zamawiający wskazał, iż przedmiot zamówienia obejmuje m.in. dostarczenie licencji Simpana10 SB-C-DPA-5T-A na 6TB (licencja obejmująca prawo do wykonywania kopii baza danych i serwerów aplikacyjnych), instalację, konfigurację i uruchomienie oprogramowania klienckiego dla serwerów aplikacyjnych i bazodanowych zapewniających możliwość tworzenia kopii zapasowych z wykorzystaniem posiadanego przez Zamawiającego serwera kopii zapasowych Simpana CommVault. Odwołujący wyjaśniał, że mając na uwadze, iż na rynku istnieją alternatywne rozwiązania takie jak EMC Networker, Veritas NetBackup, IBM TSM, czy też Storage Craft, to Zamawiający jednoznacznie ograniczył konkurencję w przedmiotowym postępowaniu. Uwzględniając fakt, iż Zamawiający dysponuje serwerem kopii zapasowych SimpanaCommVault, nie można bowiem przyjąć, iż niedopuszczenie rozwiązań konkurencyjnych jest uzasadnione, gdyż jak to sam wskazał dysponuje on jedynie serwerem kopii zapasowych SimpanaCommVault, bez wymaganych licencji do wykonywania kopii zapasowych z serwerów Systemu. Tym samym posiadane przez Zamawiającego rozwiązanie nie zapewnia wymaganej w przedmiotowym postępowaniu funkcjonalności, a nie sposób arbitralnie uznać, iż rozwiązania konkurencyjne byłyby dla Zamawiającego nieuzasadnione ekonomicznie, natomiast określone przez Zamawiającego wymagania wskazują na przyjęcie takiego założenia przez Zamawiającego. Odwołujący twierdził, że Zamawiający w sposób nieuzasadniony ograniczył konkurencję poprzez wskazanie konkretnych rozwiązań informatycznych, wskazując na preferowane. II. Sputnik wskazywał, że zgodnie z rozdz. 1 pkt 1.1. lit. k) Załącznika nr 1 do siwz, Zamawiający wymagał, aby oferowane rozwiązanie było zbudowane w oparciu o standardowe rozwiązanie klasy ERP dostępne na rynku w wersji COTS (commercial off-the- shelf) przynajmniej od 10 lat, a w oferowanej wersji co najmniej rok. W pierwszej kolejności zauważał, iż pojęcie użyte w przywołanym postanowieniu siwz, tj. standardowe rozwiązanie klasy ERP jest definiowane poprzez listę ppkt, w którym jest użyte (lit. od a) do m) w pkt 1.1. Powoduje to swoistego rodzaju problem logiczny utrudniający jednoznaczną interpretację tego pojęcia. Przyjmując jednakże, iż wymagania te należy interpretował łącznie uznać należy, iż Zamawiający wymaga aby dostarczone rozwiązanie opierało się o rozwiązanie ERP dostępne na rynku w wersji COTS przynajmniej 10 lat, a w oferowanej wersji co najmniej rok, spełniające jednocześnie pozostałe wymagania określone w lit. a)-j) oraz lit. l)-m). Zdaniem Odwołującego tak sformułowane wymaganie w sposób jedynie pozorny dopuszcza zastosowanie różnych rozwiązań. Jeśli bowiem uwzględnić wszystkie wymagania określone w przywołanym pkt 1.1, a w szczególności lit. a), c), d) zgodnie z wiedzą Odwołującego praktycznie jedynym rozwiązaniem spełniającym wymagania Zamawiającego będzie rozwiązanie ERP pod nazwą Microsoft Dynamics AX. Bez względu jednakże na powyższe, w ocenie Odwołującego wymaganie, aby rozwiązanie ERP na którym ma opierać się rozwiązanie oferowane w przedmiotowym postępowaniu Zamawiającemu dostępne było w wersji COTS przynajmniej od 10 lat w sposób zupełnie nieuzasadniony ogranicza konkurencję, przez uniemożliwienie zastosowania nowoczesnych i innowacyjnych rozwiązań, które funkcjonują na rynku w krótszym okresie, np. 3-4 lat. Również samo wymaganie wersji COTS nie jest uzasadnione specyfiką przedmiotu zamówienia. Podkreślić należy, iż sam Zamawiający poprzez wiele zapisów siwz, zapewnia sobie pełne prawo do kupowanego rozwiązania, np. rozdz. 1 pkt 1.1. lit. i), rozdz. 1 pkt 1.1. lit. I), u), w) i y) (Zamówienie obejmuje - str. 5), § 13-15 załącznika nr 7 do siwz. Tym samym zdaniem Sputnika w zakresie prawie dopuszczalnym będzie mógł przeprowadzić postępowanie na utrzymanie czy wręcz rozbudowę powstałego systemu, udostępniając wybranemu nowemu wykonawcy odpowiednie kody źródłowe i informacje niezbędne do jego wykonania. Podkreślał, że każdy z podmiotów profesjonalnie działających na rynku informatycznym na podstawie danych w posiadaniu, których będzie Zamawiający, powinien być w stanie wykonać tego typu zamówienie. Odwołujący twierdził, że wymaganie, aby oferowane rozwiązanie funkcjonowało na rynku co najmniej 10 lat, jak również aby rozwiązanie to było dostępne w wersji COTS jest całkowicie bezzasadne, a w sposób znaczący ogranicza, jeśli wręcz nie eliminuje całkowicie konkurencji. III. Następnie Odwołujący wskazywał, że zgodnie z rozdz. 5 ust. 5.1. pkt 5.1.2. ppkt 5.1.2.1. specyfikacji Zamawiający wymaga, aby wykonawca ubiegający się o udzielenie przedmiotowego zamówienia należycie wykonał lub wykonuje w jednostce sektora finansów publicznych w rozumieniu ustawy - ustawa z dnia 27 sierpnia 2009 r. o finansach publicznych (Dz.U. z 2013 r., poz. 885, z późn.zm.) zamówienie polegające na dostawie systemu informatycznego (o wartości nie mniejszej niż 10 000 000,00 PLN brutto, podana wartość dostawy systemu i jego wdrożenia nie obejmuje dostawy sprzętu) i jego wdrożeniu również w jednostkach podległych Zamawiającemu, obejmujące swoim zakresem obszar finansowo-księgowy. W ocenie Odwołującego, tak sformułowany warunek w sposób nieuzasadniony ogranicza konkurencję, przez preferowanie wykonawców, którzy posiadają doświadczenie jedynie w części, odpowiadającej przedmiotowi zamówienia i to wręcz w znikomym stopniu, a jednocześnie oferują rozwiązania oparte o rozwiązania, charakteryzujące się wysokimi kosztami licencji podmiotów trzecich. Jak wynika bowiem z treści przywołanego warunku, Zamawiający wymaga, aby zamówienie, które przedstawi wykonawca obejmowało obszar finansowo-księgowy. Oznacza to, iż Zamawiający dopuszcza, aby przedstawione zamówienie obejmowało również inne niż wskazane obszary. Tym samym możliwe jest przedstawienie zamówienia, które spełniając pozostałe wymagania zawarte w warunku, obejmowało przykładowo w 99% system obiegu dokumentów, czy np. system klasy GIS, a jedynie w 1% dotyczyło obszaru finansowo- księgowego. Zauważyć również trzeba, iż pojęcie obszaru finansowo-księgowego nie zostało nigdzie zdefiniowane, co w konsekwencji może oznaczać, iż przedstawiane zamówienie w ogóle może nie obejmować kluczowego obszaru, jaki wynika z OPZ w przedmiotowym postępowaniu, tj. podatków i opłat lokalnych. Jednocześnie Sputnik zwracał uwagę na bardzo wysoką wartość, jaką musi posiadać przedstawione zamówienie. Jest to o tyle zadziwiające, iż jak sam wskazał to Zamawiający do wartości tej nie może być zaliczona wartość dostawy sprzętu. Nie zostały natomiast wyłączone takie elementy systemu jak: wartość licencji baz danych, czy też oprogramowania systemowego. Oznacza to, iż w przypadku rozwiązań opartych o bazy danych, takich producentów jak Microsoft, IBM, Oracle, wartość samych licencji, dostarczanych baz danych może stanowić dominującą część całej wartości dostawy systemu informatycznego. Przykładowo, przy wartości całości dostawy na poziomie 10 mln zł, przy wyłączeniu wartości sprzętu, wartość licencji MS SQL Server lub podobnych może wynosić 6-7 mln zł, a wartość pozostałych elementów systemu, wraz z wdrożeniami i szkoleniami 3-4 mln zł. Oznacza to, iż poprzez tak sformułowany warunek udziału w postępowaniu Zamawiający uniemożliwia udział w postępowaniu wykonawców, których rozwiązania wykorzystują rozwiązania typu Open Source, które przez wiele instytucji, w tym np. Prezesa Urzędu Zamówień Publicznych są zalecane do stosowania w administracji publicznej. Na marginesie należy w tym miejscu wspomnieć, iż łącząc przedmiotowy warunek udziału w postępowaniu, z wymaganiami, dotyczącymi przedmiotu zamówienia przywołanymi wcześniej, na podstawie których można wywnioskować jako preferujących technologię firmy Microsoft nasuwa się przypuszczenie, że poprzez nieświadomy zbieg wszystkich wymagań przedmiotowe zamówienie będzie mógł wykonać jedynie wykonawca posiadający rozwiązania typu Microsoft Dynamics AX. IV. Sputnik wyjaśniał, że zgodnie z rozdz. 13 ust. 13.8 siwz, Zamawiający wskazał, iż w odniesieniu do kryterium "Jakość" ocena ofert dokonana zostanie przez członków merytorycznych komisji przetargowej, na podstawie indywidualnej karty oceny prezentacji. Jednakże w żadnej części siwz, Zamawiający nie wskazał sposobu przyznawania odpowiedniej ilości punktów w odniesieniu do danego wymagania. Tak więc bezsprzecznie uznać należy, iż Zamawiający przyjął, iż ocena będzie polegała na subiektywnej ocenie ofert przez poszczególnych członków merytorycznych komisji przetargowej. W ocenie Odwołującego, taki sposób oceny ofert stanowi bezpośrednie naruszenie zasady uczciwej konkurencji. Może bowiem prowadzić do sytuacji, w której przykładowo, w odniesieniu do wymagania „wygląd aplikacji”, możliwa będzie sytuacja, w której dla tak samo skonstruowanej aplikacji pod względem czytelności, przejrzystości i układu pól na ekranie i niebieskiej szacie graficznej, jeden z ekspertów przyzna 1 pkt, a drugi pkt. 4, gdzie pierwszy uzna, iż kolor niebieski jest nieestetyczny i mało atrakcyjny, a drugi z ekspertów uzna ten właśnie kolor za najbardziej odpowiedni do oferowanej aplikacji. Zauważyć w tym miejscu należy, iż większość z elementów wskazanych jako wymagania, czy też elementy podlegające ocenie może być w krótkim czasie lub wręcz zmieniona „od ręki” na etapie wdrożenia systemu po uzyskaniu informacji zwrotnych od użytkowników końcowych. Podkreślić również trzeba, iż Zamawiający przewidział w przedmiotowym postępowaniu etap projektowania systemu. W ramach tego etapu wszystkie elementy wskazane w kryterium jakość, mogą zostać ustalone i dostosowane do indywidualnych potrzeb użytkowników. Możliwa jest wręcz sytuacja, w której w dwóch różnych jednostkach podległych Zamawiającemu szata graficzna w zakresie np. przyjętej kolorystyki będzie odmienna. V. Następnie Odwołujący wskazywał, że zgodnie z załącznikiem nr 4 do siwz, w odniesieniu do obszaru opłat i podatków Zamawiający przewiduje następujące scenariusze: 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 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 Aplikacyjnego. Wykonawca dostarczy szczegółowe zestawienie dostarczonego Oprogramowania, które zostanie zawarte w Dokumentacji powykonawczej Natomiast z definicji zawartych w załączniku nr 1 do siwz jego zdaniem wynika, że: a) Projekt Rozwiązania oznacza dokument, zawierający wyniki prac związanych z analizą wymagań funkcjonalnych, sposobem implementacji Rozwiązania w środowisku Zamawiającego, Migracji danych i integracji Systemu, a także przygotowaniem szczegółowego Harmonogramu prac z uwzględnieniem procesu Migracji danych. b) Oprogramowanie Aplikacyjne oznacza, wykonane przez Wykonawcę rozbudowy (przykładowo nowe moduły, warstwy, funkcjonalności) standardowego rozwiązania klasy ERP, mające na celu dostosowanie standardowego rozwiązania klasy ERP do wymogów Zamawiającego wraz z interfejsami wymiany danych (m.in. WebService), wspierające realizację zadań wynikających z przedmiotu zamówienia. Wobec tego zdaniem Sputnika, powyższe w sposób jednoznaczny wskazuje, iż Zamawiający dopuszcza, aby wymagane przez Zamawiającego funkcjonalności, w tym te w zakresie podatków i opłat lokalnych zostały zaprojektowane i wykonane przez wykonawcę w ramach nowych modułów czy też warstw. Mając to na uwadze, Odwołujący uznał, iż wprowadzenie kryteriów oceny ofert, które preferują jednego wykonawcę na polskim rynku przy jednoczesnym braku obiektywnych przesłanek do zapewnienia, wynikających ze scenariuszy testowych funkcjonalności w zakresie podatków i opłat lokalnych, w sposób bezsprzeczny narusza zasadę uczciwej konkurencji. VI. Odwołujący podnosił, że zgodnie z uwagą w rozdz. 1 pkt 1.1. w Załączniku nr 1 do siwz (str. 6) Zamawiający wskazał, że w ramach realizacji Zamówienia wykonawca musi opracować 250 szablonów raportów w Systemie, zgodnie z wzorami uzgodnionymi w ramach Projektu Rozwiązania, z zastrzeżeniem, iż w ramach ww. szablonów Zamawiający uwzględnia raporty wskazane w wymaganiach funkcjonalnych Opisu Przedmiotu Zamówienia oraz nie uwzględni sprawozdań budżetowych i finansowych, wynikających z przepisów prawa ogólnie obowiązującego. Sputnik zwracał uwagę na możliwe zróżnicowanie pomiędzy raportami, które mogą być generowane z systemów objętych przedmiotowym zamówieniem. Część raportów może mieć postać jednostronicowych dokumentów, które są jedynie podsumowaniem danych, zawartych w systemie. Jednakże część raportów może mieć postać złożonych, wielostronicowych dokumentów, które działają nie tylko jako forma zagregowania pewnych łatwo dostępnych z systemu informacji, ale mają cechy analityczne. Powyższe oznacza, iż jeden raport może charakteryzować się stosunkowo niewielką pracochłonnością, gdzie natomiast inny raport poza pracą programisty może wymagać konieczności zaangażowania eksperta z danej dziedziny. Tym samym, przy tak sformułowanym wymaganiu pojawia się wątpliwość, w jaki sposób może to zostać wycenione, a tym samym w jaki sposób powinno to zostać uwzględnione w przygotowywanej ofercie. Fakt, iż zakres raportów ma określony dopiero na etapie Projektu Rozwiązania przerzuca na wykonawcę w całości ryzyko, związane z wyceną elementów nieokreślonych i w żaden sposób nie zdefiniowanych. VII. Odwołujący wskazywał, że zgodnie z rozdz. 4 pkt 4.2. ppkt 4.2.7 Załącznika nr 1 do siwz, Zamawiający zawarł następujący wymóg: Wszystkie połączenia (Integracja) wykonane pomiędzy systemami powinny być wykonane z wykorzystaniem szyny usług/danych, których licencje opisał Zamawiający w punkcie 2.2 podpunkt g. W innym przypadku Wykonawca zobowiązany jest dostarczyć licencje oprogramowania szyny usług/danych spełniającego wymagania opisane w punkcie 4.2.26 w ilości zapewniającej sprawne działanie Systemu z zachowaniem wydajności opisanej w punkcie 4.1.2. Jednocześnie, zgodnie z pkt 4.6 Załącznika nr 1 do siwz,, Zamawiający wskazał, iż wymaga, aby integracja między Systemem, a systemami zewnętrznymi odbywała się z wykorzystaniem zewnętrznych Web- Services nie wbudowanych w aplikację. W przypadku, gdy taka integracja jest niemożliwa, Zamawiający dopuszcza po uprzednim uzgodnieniu pomiędzy stronami inne rodzaje integracji, włącznie z zasileniem Systemu danymi wprowadzanymi, przez formatki lub pliki wymiany danych zaciągane przez funkcje systemowe. Połączenia pomiędzy systemami powinny być wykonane z wykorzystaniem szyny usług/danych Zamawiającego, wykazanych w punkcie 2.2 podpunkcie g, w przeciwnym wypadku zobowiązany jest do dostarczenia licencji oprogramowania szyny usług/danych spełniających warunki opisane w punkcie 4.2.26. W ocenie Odwołującego przywołane informacje jedynie w sposób częściowy pozwalają na określenie, w jaki sposób i przy jakich nakładach pracy będzie możliwe zapewnienie, wymaganej przez Zamawiającego integracji. Jak można na podstawie siwz przypuszczać, Zamawiający posiada wiedzę na temat niezbędnych do przeprowadzenia integracji informacji, jakie powinny być udostępnione, w odniesieniu do ogólnego wskazania na Web- Services. Jak wynika bowiem z wymagań dotyczących dokumentacji podwykonawczej, Zamawiający wymaga, aby wykonawca podał wykaz wszystkich WebSerwisów i/lub plików wymiany wraz z opisem i wskazaniem danych wejściowych oraz danych wyjściowych (Rozdz. 7 pkt 7.5. ppkt 7.5.9 tiret 13 Załącznika nr 1 do siwz). Zdaniem Sputnik informacje podane w specyfikacji w zakresie integracji są niepełne i powinny zostać uzupełnione przynajmniej o następujące dane: wykaz wszystkich WebSerwisów i/lub plików wymiany wraz z opisem i wskazaniem danych wejściowych oraz danych wyjściowych. W dniu 23 lutego 2016 r. Zamawiający, w formie pisemnej, złożył odpowiedź na odwołanie opisane powyżej. W treści pisma wnosił o oddalenie odwołania w całości oraz przedstawił szczegółową argumentację w tym zakresie. KIO 170/16 W dniu 8 lutego 2016 r. wykonawca Comarch Polska S.A., al. Jana Pawła II 39a, 31- 864 Kraków (dalej: „Odwołujący” lub „Comarch”) wniósł do Prezesa Krajowej Izby Odwoławczej odwołanie od: 1. Czynności opisania „próbki": • w sposób zawierający nieuzasadnione i ograniczające konkurencję oraz możliwość uzyskania zamówienia zapisy, dotyczące technicznego sposobu przygotowania próbki oraz przebiegu prezentacji próbki; • w sposób niejednoznaczny i nieprecyzyjny, co utrudnia wykonawcy określenie, jakie są wymagania Zamawiającego w stosunku do prezentowanego systemu; • przez określenie zadania testowego w sposób, umożliwiający wpływ Zamawiającego na ocenę ofert w tym kryterium i powodujący brak przyznania punktacji w sytuacji, w której oferowany system realizuje wymagane i testowane funkcjonalności, jak i poprzez określenie zadania testowego w sposób umożliwiający preferowanie określonych wykonawców, - co stanowi naruszenie przepisu art. 7 ust. 1 Pzp w związku z art. 91 ust. 1 Pzp i art. 29 ust. 1 Pzp oraz art. 25 ust. 1 pkt. 2 Pzp w zw. z § 6 ust. 1 pkt. 1 Rozporządzenia Prezesa Rady Ministrów z dnia 19 lutego 2013 r. w sprawie rodzajów dokumentów, jakich może żądać zamawiający od wykonawców, oraz form, w jakich te dokumenty mogą być składane (Dz. U. z 2013 r. poz. 231). 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 dokonanie oceny subiektywnej i uznaniowej, co utrudnia uczciwą konkurencję, gdyż nie zapewnia obiektywizmu oceny oferty i porównania ofert, - co stanowi naruszenie przepisu art. 7 ust. 1 w zw. z art. 36 ust. 1 pkt 13 ustawy w zw. ,z art. 91 ust. 2 ustawy. W związku z powyższym Odwołujący wnosił o uwzględnienie odwołania i nakazanie Zamawiającemu modyfikacji treści siwz w sposób wskazany w treści uzasadnienia odwołania, tak, aby zmodyfikowane zapisy siwz były zgodne z ustawą. W uzasadnieniu odwołania Comarch wyjaśniał: I. Zarzut dotyczący zestawu testowego - złożenie zestawu testowego na jednym notebooku Zamawiający określił w pkt 3 dokumentu Załącznik nr 3 do Opisu przedmiotu zamówienia (str. 1) następujące wymaganie: „3. Zestaw testowy, który Wykonawca jest zobowiązany do dołączenia do oferty musi zawierać sprzęt niezbędny do uruchomienia wersji demonstracyjnej Systemu w postaci co najmniej: wyłącznie 1 komputera tyou notebook. na którym będzie zainstalowany system demonstracyjny, Oprogramowania, w tym standardowego oprogramowania klasy ERP, Oprogramowania Aplikacyjnego w wersji demonstracyjnej, nośnika danych zawierającego obraz dysku/dysków komputera typu notebook z wygenerowany sumami kontrolnymi MD5, wydruk zawierający wszystkie sumy kontrolne MD5 dla wszystkich plików oraz innych komponentów niezbędnych do wykonania prezentacji. Odwołujący zarzucał, że taki wymóg poważnie utrudnia udział w postępowaniu i złożenie oferty, bowiem - gdyby w/w zapis został utrzymany - będzie wiązał się z poniesieniem przez wykonawców bardzo wysokich kosztów zakupienia, odpowiedniego notebooka o bardzo wysokich i niestandardowych parametrach wydajnościowych, umożliwiających uruchomienie wersji demonstracyjnej Systemu. Wymaganie, aby próbka czy też zestaw testowy mogła być dostarczona w ofercie „wyłącznie" na jednym komputerze typu notebook jest niezrozumiałe. Zdaniem Comarch na wymaganie to należy spojrzeć pod kątem zakresu wymaganego do zaprezentowania w ramach demonstracji próbki. Otóż na w/w notebooku musi zostać uruchomione całe środowisko demonstracyjne w architekturze 3- warstwowej [system ERP, baza, serwer aplikacji]. Nie ma to uzasadnienia ani w sprawności przeprowadzenia procesu testowego, ani też nie wynika w żaden sposób z przepisów prawa. Odwołujący zwraca uwagę, że przedmiotem prezentacji nie jest prosty system Finansowo Księgowy, ale rozwiązanie klasy „Enterprise", będące demonstracją części funkcjonalności systemu docelowego, mającego wspomagać zarządzanie finansami Miasta Łódź, dla którego docelowo sam Zamawiający zadeklarował infrastrukturę złożoną z ośmiu serwerów, którą zaprezentował w Załączniku nr 1 do siwz str. 24-25: „Zamawiający zamierza przeznaczyć wyłącznie na potrzeby realizacji niniejszego zamówienia następujące elementy infrastruktury informatycznej: a) 6 serwerów o parametrach: 4 CPU (4 x 10 Core), 512 GB RAM, 600 GB HDD dla potrzeb uruchomienia komponentów serwera/ów aplikacyjnych wraz z szyną usług/danych i WebService-ami. Każdy serwer będzie posiadał licencję Windows Server 2012 R2 w wersji DataCenter oraz licencję CAL dla każdego użytkownika, b) 2 serwery o parametrach: 2 CPU (2 x 8 Core), 512 GB RAM, 600 GB HDD dla potrzeb uruchomienia k/astra bazy danych w trybie Active-Passive na wszystkie dane Rozwiązania, każdy serwer będzie posiadał licencję Windows Server. 2012 R2 oraz licencję CAL dla każdego użytkownika". W ocenie Odwołującego nie zachodzą żadne przeszkody, aby prezentowany System mógł być zainstalowany na większej liczbie komputerów. Przede wszystkim zaś należy podkreślić, iż decyzja co do sposobu prezentacji próbki w zakresie liczby i jakości sprzętu winna należeć wyłącznie do wykonawcy, zaś narzucanie Ilościowych wymagań sprzętowych - dotyczących wszak sprzętu wykonawcy, wprost przekłada się na koszt sporządzenia oferty. Należy nadmienić, iż notebooki które udźwignęłyby wydajnościowo potrzeby prezentacji istnieją na rynku, lecz nie jest to sprzęt typowy, będący na stanie każdego z wykonawców. Konieczność jego zakupu jest nieuzasadnionym wydatkiem, wpływającym na koszt przygotowania oferty. W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz, przez usunięcie wymagania ograniczającego zestaw testowy do wyłącznie jednego notebooka. Każdy z Wykonawców samodzielnie powinien decydować na jakim sprzęcie zostanie zainstalowany zestaw testowy. Zdaniem Comarch umożliwi to sprawne przeprowadzenie procesu testowego oraz usunie niczym nie uzasadnione wymaganie ograniczające możliwość złożenia ofert przez wykonawców, oferujących systemy informatyczne, wymagające złożenia próbki oprogramowania w formie innej niż wyłącznie na jednym notebooku. II. Zarzut dotyczący zestawu testowego - sumy kontrolne MP5 Zamawiający określił w pkt 3 dokumentu „Załącznik nr 3 do Opisu przedmiotu zamówienia" (str. 1) następujące wymaganie: „3. Zestaw testowy, który Wykonawca jest zobowiązany do dołączenia do oferty musi zawierać sprzęt niezbędny do uruchomienia wersji demonstracyjnej Systemu w postaci co najmniej: wyłącznie 1 komputera typu notebook, na którym będzie zainstalowany system demonstracyjny, Oprogramowania, w tym standardowego oprogramowania klasy ERP, Oprogramowania Aplikacyjnego w wersji demonstracyjnej, nośnika danych zawierającego obraz dysku/dysków komputera typu notebook z wygenerowany sumami kontrolnymi MD5. wydruk zawierający wszystkie sumy kontrolne MD5 dla wszystkich plików oraz innych komponentów niezbędnych do wykonania prezentacji. Odwołujący zarzucał, że taki wymóg w praktyce uniemożliwia przygotowanie zestawu testowego, ponieważ z przedmiotowego zapisu wynika, że sumy kontrolne MD5 mają zostać wygenerowane dla „wszystkich plików" - co oznacza, że w grę wchodzą również np. pliki systemu operacyjnego zainstalowanego na dostarczonym sprzęcie, a zatem również np. dla plików systemowych (Windows). Przygotowanie obrazu dysków z wygenerowanymi sumami kontrolnymi MD5 dla „wszystkich" plików wymaga ponadstandardowego zaangażowania zasobów na potrzeby przygotowania próbki, jest też niezwykle czasochłonne, wreszcie trudno wykluczyć powstanie niezamierzonego błędu, który mógłby potencjalnie rodzić negatywne konsekwencje dla wykonawcy (np. poprzez pominięcie sumy kontrolnej dla jednego ze wszystkich plików, lub nawet przypadkowe usunięcie lub zmianę jednej cyfry w liczbie kontrolnej). Wymaganie takie nie jest uzasadnione ani ochroną zestawu testowego przed nieuprawnioną modyfikacją, ani też zapewnieniem sprawności przeprowadzenia procesu testowania (sporządzanie sumy kontrolnej dla plików systemowych nie ma po prostu sensu). W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz, przez usunięcie z w/w wymagania słowa „wszystkich" i doprecyzowanie, iż chodzi o sumy kontrolne dla plików, gdzie przez plik należy rozumieć obraz dysku/dysków III. Zarzut dotyczący zestawu testowego - instrukcja do samodzielnej prezentacji Systemu Zamawiający określił w pkt 8 dokumentu Załącznik nr 3 do Opisu przedmiotu zamówienia (str. 2) następujące wymaganie: „8. Zestaw testowy musi zawierać również instrukcję w postaci wydrukowanej, która umożliwi Zamawiającemu samodzielne wykonanie prezentacji Systemu oraz/i odtworzenie „obrazu" Systemu, zainstalowanego na dysku/dyskach komputera typu notebook. Instrukcja może być dostarczona najpóźniej do chwili zakończenia prezentacji przeprowadzanej przez danego Wykonawcę" Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione. Zestaw testowy będzie prezentowany przez przedstawicieli wykonawcy, którzy posiadają wiedzę na temat oferowanego systemu i to przeprowadzona przez nich prezentacja podlega ocenie w procesie wyboru oferty najkorzystniejszej. Odwołujący nie znajdował uzasadnienia dla samodzielnego wykonywania prezentacji i odtwarzania scenariuszy testowych przez Zamawiającego, gdyż nie jest to przedmiotem oceny, a także z uwagi na to, że zestaw testowy będzie zaawansowanym i złożonym rozwiązaniem klasy ERP, którego efektywna i samodzielna obsługa przez użytkownika końcowego wymaga - dla prawidłowego procesu obsługi czy prezentacji Systemu - co najmniej kilkudniowych szkoleń i warsztatów. Odpowiednie szkolenia użytkowników są jednym z elementów zamówienia na etapie jego wykonania, w ramach prezentacji będącej elementem oceny oferty nie ma zaś na nie miejsca. Przede wszystkim zaś należy podkreślić, iż wymóg złożenia w ofercie instrukcji umożliwiającej samodzielne przeprowadzenie prezentacji przez Zamawiającego niczemu nie służy - bowiem ocena oferty wręcz nie może pochodzić z takiej samodzielnej prezentacji wykonanej przez samego Zamawiającego. Nie można bowiem wykluczyć błędów po stronie Zamawiającego, wynikających choćby właśnie z braku dostatecznej wiedzy o oferowanym Systemie lub niewłaściwego przyswojenia przekazanych w instrukcji Informacji. Nie istnieje zaś taka instrukcja, która ze 100-procentową pewnością gwarantowałaby prawidłową obsługę systemu przez Zamawiającego. Zamawiający powinien być świadom tego, iż obsługa poszczególnych funkcjonalności danego Systemu musi wiązać się z procesem długotrwałego szkolenia użytkownika i wymaga wiedzy, której po prostu nie da się uzyskać jedynie poprzez zapoznanie się z instrukcją obsługi systemu. Zdaniem Odwołującego również dołączanie instrukcji odtworzenia „obrazu" Systemu nie ma uzasadnienia i wpływa na koszt wykonania oferty, jak i rodzi ryzyko dla jego oceny przez Zamawiającego za pomocą poza proceduralnych ocen, tj. osiągniętych poza przewidzianą w siwz procedurą oceny próbki z udziałem wykonawców. Nie jest bowiem możliwe przygotowanie takiej instrukcji, w której przewidziane zostaną wszystkie możliwe warianty. Odtwarzanie środowiska z obrazu dysku ma też pewne ograniczenia techniczne. Przykładowo odtworzenie powinno być wykonane na identycznym środowisku jak środowisku pierwotne - tylko taki wariant gwarantuje, że oprogramowanie Wykonawcy nie będzie wymagało rekonfiguracji/reinstalacji. Przywrócony z obrazu system operacyjny wraz ze sterownikami musi pasować do urządzenia, na którym wykonywane Jest odtwarzanie. Przykładowo wczytanie obrazu na komputer, który ma inny chipset płyty głównej czy kartę sieciową innego producenta skutkować będzie zmianą adresu fizycznego MAC. Do odtworzenia konieczne będzie wgranie innych sterowników dla urządzeń sieciowych i innych sterowników wynikających ze zmiany chipset'u płyty głównej. Cały ten proces spowoduje między innymi zmianę konfiguracji sieciowej urządzenia i konieczność wykonania rekonfiguracji komputera, na którym odtwarzany jest obraz. O ile wykonawca jest w stanie przewidzieć pewne komplikacje jak np. konieczność przywrócenia konkretnej konfiguracji sieciowej, to nie jest w stanie przewidzieć wszystkich przypadków samodzielnego działania Zamawiającego, a tym bardziej tych, które zależą od właściwości i parametrów sprzętu, na którym będzie wykonane przez Zamawiającego odtwarzanie środowiska, jeśli nie jest ono najpierw precyzyjnie określone. W związku, z tym wykonawca nie jest w stanie zagwarantować, że w instrukcji przewidzi wszystkie komplikacje, które mogą wystąpić w trakcie odtwarzania, co pozwoli na prawidłowe uruchomienie oprogramowania. Nie jest też jasny cel wymaganego odtworzenia „obrazu" Systemu zestawu testowego przez Zamawiającego. Jeżeli cel ten wiąże się z postępowaniem dowodowym, dla którego potrzebna jest próbka w postaci zestawu testowego, to odtworzenie takie powinno być komisyjne w obecności wykonawcy i być elementem oceny oferty z jego udziałem, a wtedy nie istniałaby konieczność wykonania takiego odtworzenia samodzielnie przez Zamawiającego. W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz poprzez usuniecie w/w wymagania w całości. IV. Zarzut dotyczący prezentacji Systemu - czas przeznaczony na prezentacje zestawu testowego Zamawiający określił w Załączniku nr 4 do Opisu przedmiotu zamówienia Scenariusze testowe, będące przedmiotem oceny. Zakres prezentacji Systemu jest bardzo szeroki i obejmuje: • Obszar I [Scenariusze testowe dla obszaru budżetowo-księgowego] - Scenariusz testowy nr 1: Wprowadzenie i zaksięgowanie uchwały budżetowej wraz ze zmianą w planie budżetu - obejmujący 9 zadań do wykonania, - Scenariusz testowy nr 2: Ewidencja umów zakupu i sprzedaży wraz z ich realizacją - obejmujący 21 zadań do wykonania, - Scenariusz testowy nr 3: Ewidencja sprawozdań jednostkowych w organie wraz z generowaniem sprawozdań zbiorczych - obejmujący 6 zadań do wykonania, • Obszar II [Scenariusze testowe dla obszaru opłat i podatków] - Scenariusz testowy nr 1: Obsługa wpłat masowych i windykacja zaległości - obejmujący 18 zadań do wykonania, - Scenariusz testowy nr 2: Obsługa wpłaty zobowiązanego na należność objętą tytułem Wykonawczym - obejmujący 9 zadań do wykonania, - Scenariusz testowy nr 3: Określenie przypisu podatku na podstawie korekty deklaracji Podatkowej - obejmujący 3 zadania do wykonania, - Scenariusz testowy nr 4: Ustalenie podatku od nieruchomości w wyniku prowadzenia postępowania podatkowego (decyzje ustalające, zmieniające lub uchylające) - obejmujący 6 zadań do wykonania - Scenariusz testowy nr 5: Egzekucja Należności Pieniężnych - obejmujący 9 zadań do wykonania - Scenariusz testowy nr 6: Windykacja Należności Cywilnoprawnych - obejmujący 6 zadań do wykonania. Comarch podnosił, że na przeprowadzenie prezentacji Zamawiający przeznaczył 6 godzin - zgodnie z pkt. 30 Załącznika nr 3 do OPZ (str. 4) „30. Łączny czas prezentacji nie może przekroczyć 6 godzin zegarowych, w przypadku, gdy w tym czasie Wykonawca nie zaprezentuje wszystkich scenariuszy Zamawiający przyzna punkty wyłącznie za scenariusze zaprezentowane w całości w kryterium oceny: „Stopień gotowości Systemu do wdrożenia" oraz w kryterium oceny: „Jakość". Zatem wykonawcy łącznie muszą zaprezentować 87 zadań w ciągu 6 godzin zegarowych, co daje średnio 4 minuty na jedno zadanie, a należy w tym miejscu podkreślić, że wybrane zadania składają się z wielu podzadań, co znacząco obniży średnią arytmetyczną czasu prezentacji każdego z wymagań. Na przykład w Scenariuszu testowym nr 6 (Windykacja Należności Cywilnoprawnych) w zadaniu 1. wyróżniono 8 podzadań - str. 6 Załącznika nr 4 do OPZ: „ Wprowadzanie ręczne do systemu sprawy w treści, której muszą znaleźć się: a) oznaczenie kolejnego numeru sprawy, b) oznaczenie rodzaju zobowiązania, c) oznaczenie tytułu wykonawczego: sygnatura akt sądowych, organ, który wydał, tytuł, data wydania tytułu, d) oznaczenie dłużnika: Imię, nazwisko / nazwa, adres, PESEL /NIP/ KRS, e) w przypadku wielości dłużników rozróżnienie na zobowiązania solidarne (wtedy „wspólna" wysokość zobowiązania, a wszystkie czynności dokonane muszą dotyczyć wszystkich dłużników solidarnych) i niesolidarne (wtedy oddzielnie wprowadzona wysokość zobowiązania, zaś czynność dokonane muszą dotyczyć każdego z dłużników osobno), f) oznaczenie wierzyciela: nazwa, adres, numer rachunku bankowego, g) oznaczenie organu egzekucyjnego, h) kwota zadłużenia z rozbiciem na należność główną, odsetki, koszty sądowe i koszty egzekucyjne" Odwołujący zarzucał, że czas przeznaczony na prezentację tak obszernych funkcjonalności jest niewystarczający i może uniemożliwić po pierwsze prawidłową weryfikację przeprowadzenia poszczególnych scenariuszy testowych, nawet zakładając poprawne przeprowadzenie danego scenariusza przy pierwszej próbie, a po drugie - w/w limit czasu prezentacji wprowadzony w siwz skutkuje tym, że wykonawcy nie uzyskają zaliczenia danego scenariusza, pomimo, że merytorycznie system spełniałaby określone w scenariuszu wymagania. Wynika to z faktu, iż Zamawiający zastrzegł w siwz, że w przypadku gdy wykonawca nie zmieści się w czasie 6 godzin, funkcjonalności które nie zostały zaprezentowane zostaną uznane za takie, których system nie posiada - str. 6 Załącznika nr 3 do OPZ: „iv. W przypadku nie powodzenia prezentacji danego scenariusza testowego, Wykonawca może powtórzyć go nieograniczoną liczbę razy dokonując rekonfiguracji wersji demonstracyjnej Systemu z zastrzeżeniem pkt 33. Przeprowadzenie powtórnej próby scenariusza testowego nie wydłuża łącznego czasu (6 godzin zegarowych) na przeprowadzenie prezentacji wszystkich scenariuszy testowych. v. Punkty zostaną przyznane jedynie za scenariusze testowe zakończone w całość. vi. W przypadku. gdy scenariusz testowy nie zostanie przeprowadzony w całość lub w ogólne się nie rozpocznie, zostanie uznany za scenariusz niewykonany i zostanie przyznane zero („0") punktów z puli punktów przewidzianych dla tego scenariusza testowego." Zdaniem Odwołującego ocena końcowa funkcjonalności systemu będzie wobec tego niewspółmiernie obniżona pomimo tego, że system dane funkcjonalności posiada, ale czas przeznaczony na prezentację systemu został wyczerpany. Odwołujący zwraca uwagę, że przeprowadzenie prezentacji tak szerokiej gamy funkcjonalności jest bardzo pracochłonne i czasochłonne, nawet dla osób znających dogłębnie prezentowany system i na co dzień zajmujących się jego obsługą. Odwołujący zwraca również uwagę, że czym innym jest przeprowadzenie danej operacji w procesie użytkowania produkcyjnego systemu, a czym innym przeprowadzenie prezentacji dla Zamawiającego. Jednym z elementów takiej prezentacji jest komunikacja prezentującego z przedstawicielami Zamawiającego i ewentualne udzielanie odpowiedzi na pytania przedstawicieli Zamawiającego. Powyższe - co wynika z doświadczeń Odwołującego - znacząco wpływa na czas prezentacji. Prezentacja scenariuszy jest procesem dużo bardziej czasochłonnym niż wykonanie danych procesów przez pracownika użytkującego system produkcyjnie. W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz, przez wydłużenie czasu prezentacji do 8 godzin zegarowych. V. Zarzut dotyczący prezentacji zestawu testowego - dopuszczenie przedstawiciel pozostałych Wykonawców w roli obserwatorów na prezentacji danego Wykonawcy. Zamawiający określił w pkt 27 Załącznik nr 3 do OPZ (str. 4) następujące wymaganie: „27. Zamawiający dopuszcza by w trakcie prezentacji/testu obecni byli przedstawiciele pozostałych Wykonawców w roli obserwatorów (po jednym dla każdego Wykonawcy). Osoby te muszą posiadać ważny dokument uprawniający ich do reprezentowania Wykonawców. W przypadku, gdy wykonawca skutecznie zastrzeże w złożonej ofercie, że zaoferowany system stanowi tajemnicę przedsiębiorstwa w rozumieniu ustawy z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji (Dz.U. 2003 Nr 153 poz. 1503 z późn. zm.), Zamawiający nie dopuść by w trakcie prezentacji/testu obecni byli przedstawiciele pozostałych Wykonawców w roli obserwatorów (...)". Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione, ponieważ prowadzi do nierównego traktowania wykonawców. Wykonawca, który jako ostatni będzie prezentować swój zestaw testowy, a weźmie udział we wcześniejszych prezentacjach konkurentów, będzie bogatszy o niesłychanie istotną wiedzę w zakresie przede wszystkim tego, jak Zamawiający interpretuje poszczególne wymagania oraz na jakie aspekty systemu i pod jakim kątem Zamawiający zwraca uwagę w toku prezentacji. Jest to niesłychanie istotna wiedza, wpływająca na sprawność i czas przeprowadzenia prezentacji przez wykonawców. Głównym powodem nierównego traktowania wykonawców w tym zakresie jest jednak to, że wykonawcy prezentujący system jako ostatni będą mieli czas na odpowiednie przygotowanie się do swojej prezentacji, tak aby uzyskać lepszą ocenę od konkurentów - co nie będzie dane wykonawcy, który odbywać będzie prezentację jako pierwszy. Odwołujący zwracał też uwagę na dodatkowy aspekt w/w zapisu. Otóż uniemożliwia on skuteczne zastrzeżenie próbki Systemu jako tajemnicy przedsiębiorstwa - do czego każdy z wykonawców - o ile tylko spełnia przesłanki ustawowe tej definicji - ma prawo. Tymczasem zapis o jawnej prezentacji z udziałem choćby konkurencji niejako na wstępnie - działaniem samego Zamawiającego (zapisem siwz) - eliminuje jedną z przesłanek tajemnicy przedsiębiorstwa, a mianowicie tę dotyczącą podjęcia przez wykonawcę działań w celu zachowania informacji w tajemnicy. W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz poprzez usunięcie w/w wymagania w całości. VI. Zarzut dotyczący prezentacji Systemu - ograniczenie liczby przedstawicieli Wykonawcy Zamawiający określił w pkt 27 Załącznika nr 3 do OPZ (str. 4) następujące wymaganie: „27. (...) Zamawiający dopuszcza udział maksymalnie 5 przedstawicieli Wykonawcy do przeprowadzenia prezentacji." Odwołujący zarzucał, że przedmiotowe wymaganie jest nieuzasadnione i ingeruje w proces przeprowadzenia próbki w zakresie w jakim winno to zależeć od decyzji samego wykonawcy. W ocenie Odwołującego nie ma podstaw do ograniczenia liczby osób reprezentujących Wykonawcę do pięciu, zwłaszcza, że zakres funkcjonalny prezentowanego zestawu testowego jest bardzo szeroki. Wykonawca może i powinien móc dysponować osobnym pracownikiem od każdego testowanego obszaru - tak by mógł optymalnie zaprezentować system z wykorzystaniem najlepszych specjalistów. Jeżeli intencja Zamawiającego jest uniknięcie „tłoku" na prezentacji - wystarczającym zapisem byłoby ograniczenie, iż każdorazowo na sali, na której odbywa się prezentacja, obecnych mogłoby być jednocześnie pięciu przedstawicieli Wykonawcy, jednak ich skład powinien być jednak możliwy do zmiany w toku prezentacji, jeśli wystąpi taka potrzeba ze strony wykonawcy, w szczególności w przypadku, gdy po stronie wykonawcy występuje specjalizacja konsultantów prezentujących poszczególne obszary oprogramowania. W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz, przez usunięcie limitu osób prezentujących zestaw testowy lub modyfikację w taki sposób, aby dopuszczona była wymiana przedstawicieli wykonawcy przy założeniu, że jednocześnie podczas prezentacji obecnych będzie na sali, na której odbywa się prezentacja nie więcej niż 5 osób ze strony wykonawcy. VII. Zarzut dotyczący prezentacji zestawu testowego - narzucona kolejność realizacji scenariuszy testowych Zamawiający określił w pkt 37 Załącznika nr 3 do OPZ (str. 5) następujące wymaganie: ,,b) ii. Wykonawca powinien dokonywać prezentacji zgodnie z kolejnością opisanych w SIWZ scenariuszy testowych". Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione i ogranicza konkurencję, bowiem może powodować eliminację wykonawców, których system - z uwagi na jego wewnętrzną logikę - w optymalny sposób posługiwałby się inną kolejnością prezentacji poszczególnych podzadań czy zadań. Aspekt ograniczenia konkurencji polega, w tym przypadku na tym, że odmienna od optymalnego dla danego konkretnego systemu kolejność realizacji scenariuszy testowych - w kontekście celu próbki czyli zbadania czy dany system realizuje daną funkcjonalność jest nadmiarowy i szkodzi wykonawcom w ten sposób, iż wpływa na wydłużenie czasu prezentacji - co przy jego limicie może w skrajnym przypadku prowadzić do nieprzeprowadzenia do końca danego scenariusza. Aspekt kolejności scenariuszy testowych i przeprowadzanych w ich ramach zadań czy podzadań powinien należeć wyłącznie do decyzji wykonawcy. Z punktu widzenia oceny próbki jest to niesłychanie istotne. Dlatego że nie można zapominać o tym, iż prezentacja próbki jest elementem oceny oferty. Wykonawca powinien mieć w tym zakresie pełną, nieskrępowaną możliwość wpływu na treść swej oferty - podobnie jak ma to miejsce w zakresie np. ceny. Ograniczenia typowe dla prezentacji jak choćby czasu prezentacji czy wybór przez Zamawiającego funkcjonalności do zaprezentowania są naturalne, składają się bowiem na element zadania dla Wykonawcy, z uwzględnieniem realiów pracy Zamawiającego. Jednak już aspekt kolejności prezentacji scenariuszy ingeruje w samą istotę i merytorykę systemu, a zatem ingeruje w treść oferty, bowiem nie uwzględnia nieznanej Zamawiającemu - co oczywiste - logiki danego systemu. W ten sposób w/w zapis ingeruje w ocenę oferty - bowiem eliminuje lub może eliminować szansę danego wykonawcy na uzyskanie zamówienia, co może być pochodną narzuconego, nieoptymalnego i sprzecznego z logiką danego systemu sposobu prezentacji (kolejności prezentacji). Jeśli logika oferowanego systemu będzie wymagała dla jego optymalnego zaprezentowania (również w czasie) innej kolejności prezentacji poszczególnych punktów scenariusza, to Zamawiający powinien dopuścić i uznać taką zmianę w każdym przypadku, jeśli tylko efekt końcowy realizacji scenariuszy testowych będzie zgodny z oczekiwaniem Zamawiającego i będzie spełniał wymagania wynikające z przepisów prawa. Tym bardziej, że przedmiotem scenariuszy jest złożona funkcjonalność, która w nowoczesnych systemach informatycznych może być realizowana za pomocą różnych funkcjonalności pośrednich. Na tym polega główna różnica między konkurencyjnymi systemami, że zapewniają one różny poziom automatyzacji dla realizacji zadań Zamawiającego wynikających z przepisów prawa. W przeciwnym razie wszystkie systemy byłyby identyczne. Wymóg realizacji scenariusza ściśle według założonej kolejności zadań sprawia wrażenie, że Zamawiający stworzył scenariusze na podstawie jednego z systemów istniejących na rynku, a wpisując to jako wymóg siwz ogranicza konkurencję uniemożliwiając złożenie konkurencyjnej oferty innym wykonawcom. W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz, przez usunięcie wymagania w całości. VIII. Zarzut dotyczący prezentacji Systemu - sposób punktacji scenariuszy testowych Zamawiający określił w pkt v. Załącznika nr 3 do OPZ (str. 6) następujące wymaganie: „v. Punkty zostaną przyznane jedynie za scenariusze testowe zakończone w całości" oraz „vi. W przypadku, gdv scenariusz testowy nie zostanie przeprowadzony w całości lub w ogólne się nie rozpocznie, zostanie uznany za scenariusz niewykonany i zostanie przyznane zero („0") punktów z puli punktów przewidzianych dla tego scenariusza testowego". Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione, ogranicza konkurencyjność w postępowaniu i narusza zasadę równego traktowania wykonawców. Wynik i przebieg prezentacji ma bowiem bezpośredni wpływ na ocenę oferty wg kryterium „Stopień gotowości Systemu do wdrożenia (SGSW)". Zamawiający wskazał bowiem, że punkty zostaną przyznane jedynie za scenariusze testowe zakończone w całości. Tym samym Zamawiający wskazał, że nie ma możliwości uzyskania jakichkolwiek punktów za daną grupę funkcjonalności, jako ocenę cząstkową w ramach scenariusza. W ocenie Odwołującego tak określony sposób przyznawania punktacji nie jest obiektywny dla wykonawców i uniemożliwia prawidłową ocenę oferowanego systemu informatycznego. Przez prawidłową ocenę Odwołujący ma na myśli ocenę merytoryczną, polegającą na przyznaniu punktów za zrealizowane przecież bez uwag zadania czy punkty scenariusza. Nierówne traktowanie wykonawców, w omawianym zakresie przejawia się w tym, iż każdorazowo przebieg prezentacji przez danego wykonawcę będzie inny - w tym w szczególności inna może być postawa Zamawiającego, liczba zadawanych przez niego pytań, czy podejmowane przez Zamawiającego inne działania w czasie prezentacji - co wszystko przekłada się na czas. W tej sytuacji niezakończenie scenariusza w całości z uwagi na upływ czasu oznaczać będzie brak punktów za cały scenariusz, pomimo że jego poszczególne punkty zostały prawidłowo przeprowadzone. Zamawiający może zyskiwać - wykorzystując ten zapis - wpływ na ocenę oferty: odpowiednio sterując przeprowadzenie prezentacji może wpłynąć na brak czasu danego wykonawcy na pełne zakończenie scenariusza - co będzie równoznaczne z nieprzyznaniem punktów. Takie ryzyko występuje, zwłaszcza w sytuacji sprzyjania przez Zamawiającego określonemu wykonawcy. W ocenie Odwołującego zasadne jest określenie zasad przyznawania punktacji, gdy część danego scenariusza testowego zostanie zrealizowana. W innym przypadku wykonawca, który zaprezentuje np. 17 zadań z 18 wskazanych przez Zamawiającego w ramach Scenariusza testowego nr 1 (Obsługa wpłat masowych i windykacja zaległości) uzyska taki sam (zerowy) wynik jak wykonawca, który nie zaprezentuje żadnego z 18 zadań składających się na Scenariusz testowy nr 1. Tymczasem z punktu widzenia oceny gotowości Systemu do wdrożenia która jest jedna z kryteriów oceny ofert podana różnica ma kluczowe znaczenie. W ramach testowanego zakresu jeden wykonawca może mieć zatem system w ogóle nie posiadający danej funkcjonalności - co oznacza iż w ogóle nie jest on gotowy do wdrożenia, podczas gdy drugi wykonawca - zasadniczo - ma system gotowy do wdrożenia w tym zakresie (bez jednego z 18 wymagań). Trudno zaakceptować jako zgodną z art. 7 ust. 1 ustawy ocenę, że oferty obydwu wykonawców są w tym zakresie takie same (otrzymują zero punktów). Jest to również dodatkowy przejaw nierównego traktowania wykonawców. W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz poprzez usunięcie w/w wymagania w całości i przyznanie punktów za poszczególne zadania w ramach scenariusza. IX. Zarzut dotyczący prezentacji zestawu testowego - zależność pomiędzy scenariuszami testowymi Zamawiający określił w pkt vi. Załącznika nr 3 do OPZ (str. 6) następujące wymaganie: „vi. W przypadku, gdy scenariusz testowy nie zostanie przeprowadzony w całości lub w ogólne się nie rozpocznie, zostanie uznany za scenariusz niewykonany i zostanie przyznane zero („0") punktów z puli punktów przewidzianych dla tego scenariusza testowego" oraz Zamawiający określił w pkt 21. dokumentu Załącznik nr 4 do OPZ (str. 3) następujące wymaganie „21. Warunkiem uzyskania oceny za scenariusz nr 2 jest wykonanie scenariusza nr 1." oraz Zamawiający określił w pkt 21. dokumentu Załącznik nr 4 do OPZ (str. 3) następujące wymaganie „6. Warunkiem uzyskania oceny za scenariusz nr 3 jest wykonanie scenariusza nr 2." Odwołujący zarzucał, że powyższe wymagania są nieuzasadnione, bowiem w przypadku Obszaru I [„Scenariusze testowe dla obszaru budżetowo-księgowego"] złożonego z trzech scenariuszy testowych, brak zaprezentowania w pełni Scenariusza 1, eliminuje możliwość uzyskania punktów za Scenariusz 2 i 3, ponieważ ostatnie punkty w przedmiotowych scenariuszach mają brzmienie jak przytoczono. Taka konstrukcja wymagań powoduje efekt wręcz przeciwny, bowiem premiuje system o mniejszej gotowości do wdrożenia: wyższą punktację może uzyskać system, który jest w znacznie mniejszym, stopniu gotowy do wdrożenia, a tym samym zasady oceny w ramach tego kryterium mają wadę logiczną. Zamawiający określił następującą punktację za poszczególne scenariusze (Załącznik nr 3 do OPZ str. 9): Scenariusz nr 1: 7 pkt Scenariusz nr 2: 8 pkt Scenariusz nr 3: 7 pkt Określona przez Zamawiającego punktacja pokazuje, że każdy z 3 scenariuszy ma podobną wagę (znaczenie) dla oceny stopnia gotowości Systemu do wdrożenia. Tymczasem jeżeli jeden z wykonawców zaprezentuje tylko i wyłącznie scenariusz nr 1 w ogóle nie przystępując do prezentacji scenariuszy 2 i 3 otrzyma 7 pkt. Natomiast wykonawca, który w ramach scenariusza nr 1 nie zaprezentuje jednej drobnej funkcjonalności, natomiast będzie wstanie zaprezentować scenariusze 2 i 3 w całości, mógłby otrzymać 15 pkt, ale z uwagi na kwestionowane w odwołaniu zapisy otrzyma zero punktów. Tym samym wyższą ocenę otrzyma system, który w ramach obszaru budżetowo-księgowego jest w stanie zrealizować scenariusz za 7 punktów, a oferta której przedmiotem jest system realizujący w tym obszarze scenariusze za 15 punktów zostanie oceniona niżej, mimo tego, że jej wynik w ocenie punktowej jest dwa razu „lepszy". W przedstawionej symulacji pominięto fakt, że określając 8 pkt. za scenariusz nr 2 Zamawiający wskazał, że jest on bardziej istotny dla oceny stopnia gotowości Systemu do wdrożenia, niż scenariusz nr 1. Jednak określenie zależności między scenariuszami powoduje, że system realizujący scenariusz bardziej istotny dla Zamawiającego (8 pkt w ocenie jednostkowej) będzie gorzej oceniony, niż system realizujący wyłącznie scenariusz nr 1, który jest mniej istotny dla Zamawiającego w ramach tego kryterium (7 pkt, w ocenie jednostkowej). Zdaniem Comarch powyższe zapisy w sposób nieuzasadniony ingerują również w wynik oceny ofert i w sferę odpowiedzialności wykonawcy za jego, ofertę, bowiem narzucają zależność pomiędzy oceną poszczególnych scenariuszy - co nie powinno mieć miejsca. Zwraca uwagę fakt, iż z punktu widzenia celu prezentacji wskazana zależność wpływa tak naprawdę na przyznanie punktacji. Równie dobrze można wyobrazić sobie siwz bez w/w zapisu. Co traciłby Zamawiający, gdyby nie było zakazanych zapisów? Otóż traciłby prawo odmowy przyznania punktu za zrealizowany przez danego wykonawcę scenariusz np. scenariusz 3 - co prowadzi do absurdu. Skoro w siwz istnieją zapisy które powodują, że za zrealizowany scenariusz wykonawca nie otrzymuje punktów - należy wskazać, iż ograniczają one konkurencję, zafałszowują ocenę oferty w kryterium gotowości systemu do wdrożenia i de facto stanowią narzędzie wpływu poprzez postanowienia siwz na wynik oceny ofert. Z takim postanowieniami nie można się zgodzić. Waga w/w kryterium oceny oferty jest tak duża, iż każdy zapis który pozwoli Zamawiającemu nie przyznać punktu za zrealizowany scenariusz należy uznać za niezgodny z ustawą. W związku z powyższym Odwołujący wnosi o nakazanie Zamawiającemu modyfikacji siwz, przez usunięcie w/w wymagań w całości i uniezależnienie scenariuszy od siebie oraz o dopuszczenie - w przypadku niewykonania jednego ze scenariuszy - iż na potrzeby kolejnego scenariusza wykonawca wykorzysta dane nie pochodzące z poprzedniego scenariusza. X. Zarzut dotyczący jednolitości technologii i interfejsu w całym systemie Zamawiający określił w pkt f) Załączniku nr 1 OPZ (str. 3) następujące wymaganie: „f. Zamawiający wymaga, aby wszystkie moduły oferowanego rozwiązania napisane były w tej samej technologii" oraz Zamawiający określił w pkt 4.2.22 dokumentu Załącznik nr 1 do OPZ (str. 32) następujące wymaganie: „4.2.22. System musi zapewniać jednolity interfejs użytkownika dla wszystkich obszarów funkcjonalnych, a funkcje powtarzające się w różnych Modułach powinny być dostępne dla użytkownika pod taką samą nazwą w menu i pod takim samym klawiszem skrótu, zapewniając w maksymalny sposób jednolitość obsługi." Odwołujący zarzucał, że takie wymagania są nieuzasadnione i ograniczają konkurencję poprzez organicznie technologii, przy czym ograniczenie takie w tym konkretnym przypadku nie ma żadnego uzasadnienia funkcjonalnego ani technicznego. Narzędzia raportujące mają inną zasadę działania i inne przeznaczenie niż reszta systemu klasy ERP. Interfejs użytkownika systemu ERP służy do wyszukiwania pojedynczych informacji oraz do wprowadzania pojedynczych informacji. Przykładowo wyszukujemy konkretny dokument np. decyzję podatkową lub rejestrujemy konkretny dokument, np. decyzję podatkową. Tymczasem moduł raportujący nie wyszukuje konkretnego zapisu z bazy danych, a służy raczej zestawieniu wielu zapisów na pojedynczym raporcie spełniających określone parametry i w żadnym stopniu nie służy do wprowadzania jakichkolwiek danych. Zamiast wprowadzania danych musi umożliwiać zarówno użytkownikom zaawansowanym, jak i zwykłym użytkownikom tworzenie definicji raportów, a więc elementy projektowania i programowania. Dla narzędzi raportujących zupełnie inaczej wygląda charakterystyka dostępu do danych - zawsze zakładają wyszukanie i pobranie z bazy danych, a następnie zaprezentowanie użytkownikowi całego zestawu danych, który pasuje do zadanych parametrów - np. wydruk decyzji podatkowych dotyczących danej ulicy. Tymczasem pozostałe moduły systemu mają za zadanie zaprezentowanie konkretnego rekordu, konkretnych danych i nawet w przypadku zapytania dotyczącego decyzji podatkowych danej ulicy w interfejsie użytkownika nie są prezentowane wszystkie decyzje, a jedynie co najwyżej ich paczka licząca kilka - więcej po prostu nie zmieści się na ekranie. Dlatego w przypadku narzędzi innych niż Generator Raportów strategią dostępu do danych jest strategia, która można określić jako „pokaż mi pierwszą daną spełniającą warunki zapytania", tak w przypadku narzędzi raportujących strategia tą można opisać stwierdzeniem „pokaż mi wszystkie dane spełniające warunki zapytania". Biorąc pod uwagę powyższe normą dla największych i nowoczesnych biznesowych rozwiązań informatycznych jest budowanie narzędzi raportujących w innej technologii i z innym interfejsem użytkownika niż pozostałe moduły systemu. Takie podejście jest jak najbardziej powszechne i racjonalne, ponieważ narzędzia raportujące służą do zupełnie innych celów niż standardowe ekrany systemu ERP. Inne jest ich przeznaczenie, logika działania, sposób dostępu do danych, optymalizacja zapytań. W zasadzie moduł raportujący i pozostałe moduły różni wszystko. Zatem nie ma konieczności ani żadnego racjonalnego uzasadnienia, aby narzędzia typu „Generator Raportów" były wykonane w tej samej technologii co system główny (ERP). Żądanie Zamawiającego jest zatem zbędne, technologicznie nieuzasadnione i ogranicza konkurencję, ponieważ eliminuje wykonawców, który posiadają rozwiązanie typu Generator Raportów zbudowane w sposób racjonalny i nowoczesny, ale wykonane w innej technologii. Spójność technologiczna ani jednolitość interfejsu nie są warunkami skuteczności takiego narzędzia, którego rolą jest pozyskiwanie danych z systemu ERP do celów analitycznych i ich odpowiednie przedstawienie użytkownikowi. Zamawiający jeżeli chce otrzymać skuteczne narzędzie raportujące wręcz powinien żądać, aby jego technologia i Interfejs użytkownika były zoptymalizowane do funkcji jakie te narzędzia mają pełnić. W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz poprzez usunięcie w/ w wymagania w całości lub wyłączenie z tego wymogu narzędzi raportujących, tak by mogły one cechować się inną technologią oraz odmiennym Interfejsem w stosunku do Systemu. XI. Zarzut dotyczący otwartości kodu oprogramowania Zamawiający określił w pkt i) Załącznika nr 1 do siwz (str. 3) następujące wymaganie: „i. Oferowane rozwiązanie musi udostępniać w ramach opłaty licencyjnej dostęp do otwartego kodu oprogramowania ". Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione. Pojęcie „otwartego kodu" używane jest do oprogramowania typu „Open Source”. Ponadto zgodnie z definicjami stosowanymi przez Zamawiającego Kod Źródłowy odnosi się wyłącznie do Oprogramowania Aplikacyjnego, czyli oprogramowania wytworzonego w toku wdrożenia, a nie do standardowego systemu ERP - zgodnie z Załącznikiem nr 1 do siwz, str. 13: „Kod źródłowy - oznacza pliki źródłowe, skrypty, biblioteki .dli i inne niestandardowe narzędzia, niezbędne w procesie kompilacji l/lub konsolidacji Oprogramowana Aplikacyjnego, a także strukturę baz danych i opis struktury baz danych, słowników, definicji niezbędnych dla dalszego utrzymywania Systemu. Pliki te muszą być dostarczone w formie, która nie wymaga deasemblacji ani dekompilacji i pozwala na ich modyfikację oraz dokumentację/materiały/ Kod źródłowego" „Oprogramowanie Aplikacyjne - oznacza, wykonane przez Wykonawcę rozbudowy (przykładowo nowe moduły, warstwy, funkcjonalności) standardowego rozwiązania klasy ERP, mające na celu dostosowanie standardowego rozwiązania klasy ERP do wymogów Zamawiającego wraz z Interfejsami wymiany danych (m.in. WebService), wspierające realizację zadań wynikających z przedmiotu zamówienia”. Zdaniem Comarch nie jest do końca jasne w jakim kontekście Zamawiający użył określenia „otwartego kodu". Jeżeli miał na myśli oprogramowanie typu „ Open Source", to zasada dostępu do kodu źródłowego wynika z licencji użycia takich narzędzi i Zamawiający nie może integrować w te zasady. Jeżeli Zamawiający miał na myśli, że dostarczone rozwiązanie ma mieć dla niego „otwarty kod", to takie wymaganie może powodować naruszenie ochrony praw autorskich producentów rozwiązania COTS, które zgodnie z wymogami siwz jest obok Oprogramowania Aplikacyjnego, przedmiotem zamówienia (Załącznik nr 1 do siwz str. 3: „k. Oferowane rozwiązanie powinno być zbudowane w oparciu o standardowe rozwiązanie klasy ERP dostępne na rynku w wersji COTS (commerciai off- the-sheif) przynajmniej od 10 lat, a w oferowanej wersji co najmniej rok. W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz, przez zawężenie tego wymogu do Oprogramowania Aplikacyjnego. XII. Zarzut dotyczący dostosowanie Oprogramowania Aplikacyjnego do zmian wynikających z przepisów wewnętrznych Zamawiający określił w pkt r) Załącznika nr 1 do siwz (str. 5) następujące wymaganie: ,,r) Dostosowanie Oprogramowania Aplikacyjnego do zmian wynikających ze zmian prawa miejscowego - uchwały wydawane przez Radę Miejską, a także przepisów wewnętrznych np. regulaminy, uchwały nie będące aktami prawa miejscowego, zarządzenia itp." Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione i rodzi dla wykonawcy poważne ryzyko realizacyjne i kosztowe. Przede wszystkim zaś powyższe wymaganie uniemożliwia prawidłowe oszacowanie ceny oferty. Powyższy zapis umożliwia bowiem Zamawiającemu w dowolnym momencie realizacji rozszerzyć zakres zamówienia. Nie można bowiem wykluczyć możliwości, że wewnętrzne regulacje Zamawiającego doprowadzą do rozszerzenia wymaganych funkcjonalności systemu informatycznego. Zawsze będzie można stworzyć odpowiedni „regulamin", który przypadkiem zawierał będzie zapisy wskazujące na konieczność wprowadzenia dowolnych, aktualnie potrzebnych Zamawiającemu funkcjonalności. Tymczasem dostosowanie systemu do zmian w przepisach prawa ma inny cel i inna funkcje: jest pochodna odpowiedzialności wykonawcy za zgodność systemu z prawem, w tym prawem miejscowym. Rozszerzanie aktów normatywnych na nikomu nieznane regulacje wewnętrzne (nie jest wykonawcy znane pojęcie „przepisu wewnętrznego") stanowić może furtkę wymuszania na wykonawcy dokonywania istotnych zmian systemu - pod pozorem dostosowywania ich do uregulowań normatywnych. W zakresie dostosowania systemu do zmian w ustawodawstwie oraz aktach prawa miejscowego uchwalanych przez organ stanowiący gminy zakłada się racjonalności ustawo i uchwałodawcy. W przypadku wewnętrznych regulaminów i zarządzeń system prawny nie wprowadza takiego domniemania. Tym bardziej, że formułując wymaganie Zamawiający w żadnej sposób nie zawęził co stanowi przepisy wewnętrzne, używając zwrotów „np." oraz „itp.". W ten sposób przepisem wewnętrznym może być wszystko, nawet dowolna decyzja każdego z pracowników Zamawiającego. W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz poprzez usunięcie z w/w wymagania słów: „a także przepisów wewnętrznych np. regulaminy, uchwały nie będące aktami prawa miejscowego, zarządzenia Itp." oraz poprzez wskazanie w siwz enumeratywnego katalogu uregulowań, tj. ustaw wraz z przepisami wykonawczymi oraz uchwał organu stanowiącego gminy które będą objęte w/w wymaganiem. XIII. Zarzut dotyczący czasów odpowiedzi systemu na działania operacyjne użytkowników Zamawiający określił w pkt 4.1.2.2. Załącznika nr 1 do siwz (str. 28-29) następujące wymaganie: „4.1.2.2. Zaproponowane rozwiązanie musi zapewnić następujące czasy odpowiedzi: a. średni czas odpowiedzi przy transakcjach bez zapisu informacji do bazy danych nie może przekraczać 5 sek., czas maksymalny 20 sek.; b. średni czas odpowiedzi przy transakcjach z zapisem informacji do bazy danych nie może przekraczać 10 sek., czas maksymalny 30 sek.; c. przez czas odpowiedzi rozumie się czas upływający od momentu wykonania przez użytkownika na końcówce Systemu akcji wyzwalającej działanie Systemu (naciśnięcie odpowiedniego do sytuacji klawisza lub kontrolki w oknie aplikacji, itp.) do momentu uzyskania oczekiwanych wyników tej akcji na końcówce użytkownika. 4.1.2.3. Wymagane czasy odpowiedzi z pkt. 4.1.2.2 nie dotyczą wykonywania raportów okresowych, dla których maksymalny czas odpowiedzi nie może przekraczać 10 min." Comarch wskazywał, że określony przez Zamawiającego w pkt. b wymagania 4.1.2.2 średni i maksymalny czas odpowiedzi oraz w punkcie 4,1.2.3 maksymalny czas odpowiedzi w powiązaniu z definicją czasu odpowiedzi w pkt. c) wymagania 4.1.2.2 jest nieracjonalny i niemożliwy do uzyskania. Zdaniem Odwołującego Zamawiający, formułując takie wymagania, nie wziął pod uwagę tzw. operacji masowych. Przykładowo w systemie będącym przedmiotem zamówienia wystawia się decyzje podatkowe. Założenie, że wygenerowanie pojedynczej decyzji nie może przekraczać 30s, a czas średni czas generacji nie może przekraczać 10s jest jak najbardziej racjonalny. Jednak system podatkowy posiada nie tylko operacje pojedyncza, ale również operacje masowe, np. wystawienie decyzji dla danej grupy kartotek podatkowych. I taka operacja masowa, której uruchomienie odbywa się za pomocą naciśnięcia odpowiedniej kontrolki, często może dotyczyć generacji kilku tysięcy decyzji. Nie ma możliwości zapewnienia, aby operacja ta nie przekroczyła czasu 30s. Podobnie w przypadku wymagania 4.1.2.3 zachowanie maksymalnego czasu 10 min, dla operacji wydruku masowego, np. wydruku kilku tysięcy decyzji podatkowych, nie jest możliwe do spełnienia. Tym bardziej, że czas ten zależy nie tylko od wydajności oferowanego systemu, a również konfiguracji serwerów, sieci, jakości i konfiguracji urządzeń drukujących, a wszystkie te elementy nie są przedmiotem zamówienia i zapewnia je Zamawiający. Powyższe operacje masowe i wydruki masowe są jedynie przykładami, a funkcjonalność systemu będącego przedmiotem zamówienia zawiera wiele tego typu operacji. Podsumowując powyższe Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione, ponieważ Zamawiający nie powiązał wymaganych reżimów czasowych z liczbą wykonywanych przez użytkowników operacji, Jak również nie wyłączył z nich tzw. operacji masowych, Czasy operacji powinny odnosić się do zakresu wykonywanych w systemie prac, które muszą być docelowo wykonane i zakończone w podanym reżimie czasowym, gdyż to jest Istotne z punktu widzenia organizacji pracy Zamawiającego. Należy również podkreślić, że czasy poszczególnych operacji w systemie są zależne od wielu elementów, nie tylko od konstrukcji i wydajności oferowanego systemu, ale również od liczby użytkowników jednocześnie korzystających w danym momencie z systemu, jak również od specyfikacji serwerów i parametrów sieciowych, ich konfiguracji, a elementy związane z szeroko rozumianą platformą sprzętową nie należą do przedmiotowego postępowania i zapewnia je Zamawiający, a zatem są one niezależne od wykonawcy. W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz, przez usunięcie w/w wymagania w całości. XIV. Zarzut dotyczący eksportu widoków ekranowych i raportów do wskazanych formatów Zamawiający określił w pkt 37 Załącznika nr 1 do siwz (str. 41) następujące wymaganie: „37. System musi zapewnić możliwość eksportu wszystkich widoków ekranowanych/ wygenerowanych raportów do formatów np. .txt, .xls, .doc z możliwością sortowania raportów." Odwołujący zarzuca, że takie wymaganie jest nieuzasadnione. Użycie zwrotu „np," skutkuje brakiem enumeratywnego wyspecyfikowania, co składa się na przedmiot zamówienia, a tym samym zapis ten nie spełnia wymagań art. 29 ust. 1 ustawy. Dodatkowo w zakresie eksportu widoków ekranowych do formatów DOC I XLS Odwołujący podnosił, że są to formaty nie do końca otwarte, będące własnością firmy Microsoft, a tym samym specyfikując takie formaty Zamawiający w sposób nieuzasadniony preferuje rozwiązania dostarczane lub budowane przez firmę Microsoft. Ponadto eksport widoków ekranowych dotyczy eksportu do pliku surowych danych w celu ich dalszej obróbki. Dane w sformatowanym i narzuconym układzie otrzymuje się za pomocą raportów generujących określone zestawienia i dokumenty z wykorzystaniem predefiniowanych szablonów. Wymóg eksportu danych z wszystkich widoków ekranowych oznacza konieczność zapisania w pliku surowych danych (inaczej mówiąc wartości poszczególnych pól widoku ekranowego). Formaty DOC i XLS są formatami natywnymi narzędzi MS Word oraz MS Excel. Są również obsługiwane (czytane) przez inne oprogramowanie biurowe np. OpenOffice. Jednak konieczność eksportu widoków ekranowych do tych formatów jest nadmiarowa, ponieważ każde z narzędzi obsługujących format DOC, czy XLS jest w stanie obsługiwać również format TXT- tak samo dobrze i skutecznie. Podobnie w przypadku konieczności eksportu wygenerowanych raportów do formatów DOC i XLS żądanie Zamawiającego jest nadmiarowe, nieuzasadnione I preferuje jedno konkretne rozwiązanie firmy Microsoft. Również w przypadku raportów eksport surowych danych do formatu TXT jest wystarczający. Ponadto, jeżeli Zamawiający chciałby eksportować raporty stanowiące dokumenty do formatu pozwalającego na edycję przez użytkownika to w ramach wymagania 4.2.27, pkt. 19 (Załącznik nr 1 do siwz str. 39) Zamawiający zapewnił sobie, że raporty tworzone przy użyciu Generatora Raportów musza mieć możliwość zapisu do pliku min. w formacie RTF. Format RTF w przeciwieństwie do formatu DOC jest formatem otwartym i jest akceptowany (czytany) przez wszystkie edytory obsługujące format DOC, a ponadto przez wiele innych narzędzi, które obsługują format RTF, a nie obsługują formatu DOC. Przy czym Odwołujący nie kwestionuje konieczności stosowania w dostarczonym Systemie eksportu do formatów XLS i DOC, a jedynie nieuzasadniony wymóg eksportu wszystkich widoków ekranowych i raportów do formatów XLS. DOC. w przypadku gdy eksport do formatu TXT test wystarczający I nie ogranicza konkurencji przez preferowanie rozwiązań budowanych przez lub w technologii Microsoft. W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz, przez usunięcie zwrotu „np." oraz usunięcie formatów„.xls, ,doc". XV. Zarzut dotyczący niewskazania miejsca wykonania wdrożenia Zamawiający określił w pkt 2 Załącznika nr 1 do siwz (str, 1) następujące wymaganie: „2. Miejsce wykonania: w Lokalizacjach Zamawiającego" Odwołujący zarzucał, że takie wymaganie jest nieprecyzyjne. Zamawiający nie określił w jakich lokalizacjach będzie odbywać się wdrożenie. Nie można wykluczyć sytuacji, w której Zamawiający posiada np. ośrodki wczasowe poza miastem - siedzibą Zamawiającego - i będzie oczekiwał przeprowadzenia np. szkoleń użytkowników w tych ośrodkach co znacząco wpływa na wycenę tych szkoleń (z powszechnie dostępnych danych wynika, że Zamawiający posiada np. ośrodek w Zakopanym). W związku z powyższym Odwołujący wnosi o nakazanie Zamawiającemu modyfikacji siwz, przez doprecyzowanie lokalizacje i określenie ich w sposób enumeratywny. XVI. Zarzut dotyczący niespójności w zakresie licencji Zamawiający określił w pkt h) Załącznika nr 1 do siwz (str. 3) następujące wymaganie: „h. Licencje dostarczone dla oferowanego rozwiązania muszą umożliwiać obsługę nieograniczonej liczby jednostek organizacyjnych" Odwołujący zarzucał, że takie wymaganie jest niejasne. Wymaganie ma charakter „otwarty" i uniemożliwia przygotowanie wyceny oferty. Ponadto jest sprzeczne z zapisem o 500 licencjach, które Zamawiający może zakupić w ramach Opcji - zgodnie z Załącznikiem nr 1 do SIWZ str. 150 pkt. 2 a) Zamawiający ma prawo „zakupić dodatkowe licencje dla standardowego rozwiązania klasy ERP maksymalnie 500 licencji'. W związku z powyższym Odwołujący wnosi o nakazanie Zamawiającemu modyfikacji siwz poprzez usunięcie wymagania. XVII. Zarzut dotyczący harmonogramu wdrożenia Zamawiający określił w pkt 1.1.2. „Etapowanie prac" dokumentu „Załącznik nr 1 do SIWZ" (str. 8-10) następujące wymaganie: „ETAP I- do 4 miesięcy od daty podpisania Umowy (...) ETAPU do 2 miesięcy od daty zakończenia ETAPU I(...) ETAP III do 12 miesięcy od daty zakończenia ETAPU II (...) ETAP IV- do 6 miesięcy od daty zakończenia ETAPU III (odbiór i rozpoczęcie pełnej eksploatacji Systemu) (...) ETAP V – od zakończenia ETAPU IV do końca Umowy (..)" oraz Zamawiający określił w pkt 3 „Ograniczenia" dokumentu Załącznik nr 1 do SIWZ (str. 26) następujące wymaganie: „W poszczególnych obszarach objętych projektem mogą wystąpić ograniczenia dostępności zasobów po stronie Zamawiającego wynikające z terminów realizacji zadań ustawowych. Powyższe ograniczenia zostaną doprecyzowane w Projekcie Rozwiązania." Odwołujący zarzucał, że takie wymaganie uniemożliwia wdrożenie przedmiotu zamówienia w takim reżimie czasowym. Uwzględniając powyższe dane należy stwierdzić, że Zamawiający założył w ramach Etapu II i IIII [czyli łącznie 14 miesięcy] objęcie pełnym wdrożeniem [w zakresie funkcjonalności oznaczonych priorytetem 1, stanowiących zdecydowaną większość w wymagania funkcjonalnych OPZ] ponad kilkadziesiąt jednostek organizacyjnych. Zdaniem Comarch realizacja tak złożonego wdrożenia i w tak wielu jednostkach organizacyjnych nie jest możliwa w perspektywie 14 miesięcy założonych harmonogramie prac przez Zamawiającego. Wdrożenie systemów klasy ERP jest procesem złożonym, który wymaga dużego zaangażowania zasobów po obu stronach, zarówno Wykonawcy jak i Zamawiającego. Przy tak znaczącej liczbie zadań wdrożeniowych jak zakreślono w siwz, nawet w przypadku zastosowania prekonfigurowanego rozwiązania ERP, w ocenie Odwołującego wdrożenie w terminach wskazanych przez Zamawiającego i przy jednoczesnym pierwotnym założeniem ograniczeń w dostępności zasobów po stronie Zamawiającego nie jest zadaniem możliwym do wykonania. Ponadto Etap II musi się zakończyć do 2 miesięcy po zakończeniu Etapu I. Równocześnie w ramach etapu II należy dokonać wdrożenia funkcjonalności objętych wymaganiami z priorytetem 1 w obszarze budżetowo- księgowym w zakresie planowania w UMŁ i 10 jednostkach podległych. Aby dokonać realizacji (wdrożenia) należy wykonać co najmniej następujące prace: zainstalować standardowy System COTS, dokonać jego dostosowania do potrzeb Zamawiającego, dokonać integracji z Systemami Zamawiającego, dokonać migracji przeniesienia danych z systemów źródłowych do rozwiązania docelowego (testowej i produkcyjnej), przeprowadzić szkolenia testerów, przeprowadzić testy akceptacyjne rozwiązania, przeprowadzić szkolenia użytkowników. Te wszystkie zadania poza instalacją standardowego rozwiązania COTS można realizować dopiero po zakończeniu Etapu I, a więc po opracowaniu i odebraniu (zaakceptowaniu) przez Zamawiającego Projektu Rozwiązania. W ramach prac objętych Etapem I (zgodnie z zapisami Załącznika nr 1 do siwz str. 8): „ Wykonawca przeprowadzi prace analityczne związane m.in. z analizą i przygotowaniem sposobu realizacji prac objętych zamówieniem, a w szczególności dotyczących: projektu technicznego i logicznego Rozwiązania, wymagań funkcjonalnych, migracji i standaryzacji danych, integracji systemu." Biorąc pod uwagę powyższe zapisy wykonawca ma na wszystkie prace w ramach Etapu II jedynie 2 miesiące. Równocześnie Zamawiający nie określił liczby użytkowników do przeszkolenia z poszczególnych obszarów w poszczególnych jednostkach. Tym samym nie przedstawił rozmiaru prac jakie są do realizacji w ramach 2 miesięcy (Etapu II). W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz przez • wydłużenie terminu wdrożenia Etapów II i III odpowiednio o dodatkowe 3 miesiące i dodatkowe 3 miesiące [czyli łącznie dodatkowe 6 miesięcy], • wprowadzenie zapisu, iż ograniczenia po stronie Zamawiającego nie mogą wywoływać wobec Wykonawcy negatywnych konsekwencji, w tym Wykonawca nie ponosi odpowiedzialności z tytułu kar umownych na niedotrzymanie terminów wynikających z umowy z uwagi na te ograniczenia. XVIII. Zarzut dotyczący kosztów szkoleń Zamawiający określił w pkt d) w Załącznik nr 1 do siwz (str. 129) następujące wymaganie: ,,d) Wykonawca zobowiązany jest do zorganizowania i pokrycia wszelkich kosztów związanych z przeprowadzeniem szkoleń. Odwołujący zarzucał, że takie wymaganie jest niedoprecyzowane. Zamawiający nie wskazał co rozumie przez zorganizowanie i pokrycie wszelkich kosztów związanych z przeprowadzeniem szkoleń, a pozycja ta z uwagi na bardzo znaczącą liczbę użytkowników do przeszklenia [kilkaset osób] może być wielkością znaczącą w cenie oferty. Zapis w obecnym brzmieniu nie pozwala ocenić co wchodzi w koszt szkoleń pokrywanych przez wykonawcę np. koszt wynajmu sal szkoleniowych, koszt wynajmu stacji roboczych, koszt organizacji przerw kawowych i lunchu, koszt przejazdów uczestników szkoleń, itp. w szczególności z uwagi na brak wymagań Zamawiającego w tym zakresie, W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz, przez podanie enumeratywnie jakie konkretnie koszty musi pokryć wykonawca [koszt wynajmu sal szkoleniowych, koszt wynajmu stacji roboczych, koszt organizacji przerw kawowych i lunchu, koszt przejazdów uczestników szkoleń, itp.]. XIX. Zarzut dotyczący szkoleń administratorów Zamawiający określił w pkt 6.6.3 Załącznika nr 1 do siwz (str. 133) następujące wymaganie: „6.6.3. W przypadku wykorzystania przez Wykonawcę Innego rozwiązania szyny usług/danych, szkolenie również powinno być przeprowadzone w certyfikowanych ośrodkach szkoleniowych". Odwołujący zarzucał, że takie wymaganie jest niedoprecyzowane. Zamawiający nie wskazał ilu administratorów ma zostać przeszkolonych w przypadku zaoferowania „innego rozwiązania szyny usług/danych", ani nie potwierdził, że liczba ta jest analogiczna (tzn. dwóch administratorów) jak dla przypadku szkoleń z posiadanej przez Klienta „Oracle SOA Suitę". W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz przez doprecyzowanie ilu administratorów ma zostać przeszkolonych z zakresu „innego rozwiązania szyny usług/danych". XX. Zarzut dotyczący zestawienia jednostek objętych projektem i zakresu funkcjonalnego Zamawiający w załączniku nr 2 przedstawił w formie tabeli wykaz jednostek objętych projektem. Odwołujący zarzucał, że takie zestawienie jest niedoprecyzowane. Zamawiający nie zamieścił żadnej legendy, wyjaśnienia które pozwoliłoby wykonawcom zrozumieć intencje Zamawiającego w zakresie oznaczenia kolorami: białym, żółtym, czerwonym i czarnym komórek zestawienia Excel, prezentującego podmioty objęte projektem oraz zakres funkcjonalny wdrożenia w kontekście wpływu tego podziału na proces przygotowania oferty i wykonania zamówienia. Nie sposób zatem jednoznacznie i obiektywnie zinterpretować przedmiotowego zestawienia - a jest ono kluczowe dla określenia złożoności projektu i oszacowania kosztu wdrożenia. W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz poprzez doprecyzowanie w siwz [Załącznik nr 2] znaczenia kolorów wykorzystanych w tabeli, to jest w jakich jednostkach i w jakim zakresie wykonawca ma wykonać wdrożenie. XXI. Zarzut dotyczący liczby jednostek objętych projektem Zamawiający przedstawił w siwz Załącznik nr 2 [plik 2115_zalacznik_siwz_2016-01- 29_2]. Odwołujący zarzucał, że takie zestawienie jest niedoprecyzowane. Zamawiający nie wyspecyfikował jednostek, które wchodzą w skład pozycji: „II MJO - PLACÓWKI OŚWIATOWE", tak jak to uczynił dla pozycji „III MJO" oraz „IV MJO - PLACÓWKI OPIEKI SPOŁECZNEJ". W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz przez: • wskazanie w siwz enumeratywnej listy placówek oświatowych wskazanej w wierszu II, • wyjaśnienie w siwz czy podmioty wskazane w zestawieniu Załącznika nr 2 to licencjobiorcy? XXII. Zarzut dotyczący migracji Zamawiający przedstawił w Załączniku nr 5 [plik 2115_zalacznlk_siwz_2016-01-29_5] dwa zestawienia w zakładkach pliku Excel: • Zakładka „ZFM-systemy w MJO", • Zakładka „ZFM-zakres migracji". Odwołujący zarzucał, że przedmiotowe zestawienia są niedoprecyzowane. Na zakładce „ZFM-zakres migracji" Zamawiający nie przedstawił kompletnej informacji, która powinna być wyspecyfikowana zgodnie z nagłówkami kolumn. Zestawienie w zakładce „ZFM-systemy w MJO" cechuje informacja różnej jakości. Pomimo nadania przez Zamawiającego trzeciej kolumnie przedmiotowego zestawienia nazwy „Nazwa i producent aktualnie eksploatowanego systemu. Technologia” dla wielu pozycji informacje są niekompletne, a w szczególności nie zawierają informacji na temat producenta i technologii. Zdaniem Comarch oba zestawienia zaprezentowane w zakładce „ZFM-systemy w MJO" mają charakter niespójny, chaotyczny i niekompletny. Należy zaznaczyć, że zestawienia tabelaryczne dotyczą bardzo ważnego i kosztochłonnego aspektu wdrożenia jakim jest migracja danych. Ma to szczególne znaczenie w świetle treści pkt. 5. „Migracja danych" ppkt. c) z Załącznika nr 1 do siwz [str. 119], gdzie Zamawiający podkreślił m.in. rolę informacji na temat technologii systemów posiadanych przez Zamawiającego, ponieważ dane źródłowe dla celów migracji będą w formatach zgodnych z formatem baz danych obecnie funkcjonujących lub w formacie możliwym bezpośrednio do uzyskania z obecnie funkcjonujących aplikacji. ,,c) Wykonawca przy współpracy z Zamawiającym przygotuje Dane Źródłowe w formatach zgodnych z formatem baz danych obecnie funkcjonujących lub w formacie możliwym bezpośrednio do uzyskania z obecnie funkcjonujących aplikacji, według stanu na dzień wskazany w Harmonogramie w Projekcie Rozwiązania; Uwaga! Zamawiający zobowiązuje się udostępnić Dane Źródłowe w formatach zgodnych z formatem baz danych obecnie funkcjonujących systemów oraz dokumentację będącą w posiadaniu Zamawiającego, w zakresie w jakim dokumentacja ta może zostać udostępniona Wykonawcy;" W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz przez: • uzupełnienie tabeli w zakładce „ZFM-systemy w MJO" o kompletne informacje odpowiadające nagłówkom kolumn, • uzupełnienie tabeli w zakładce „ZFM-zakres migracji" o informacje zapewniające spójność z danym przedstawionymi w tabeli z zakładki „ZFM- systemy w MJO", • wprowadzenie do siwz oświadczenia Zamawiającego, że rolą/odpowiedzialnością Zamawiającego jest zapewnienie jakości danych podlegających migracji. XXIII. Zarzut dotyczący technologii - przechowywanie plików typu: skan Zamawiający określił w pkt 4.2.14 oraz 4.2.15 Załącznika nr 1 do siwz (str. 30-31) następujące wymaganie: „4.2.14. Wszystkie dane zgromadzone w Systemie powinny być przechowywane w wspólnej bazie danych z wyłączeniem plików z załącznikami, które muszą być przechowywane w systemie plikowym serwera aplikacyjnego. Zamawiający nie zaakceptuje rozwiązania, w którym obiekty (np. skany dokumentów jako załączniki itp.) są przechowywane w bazie danych w polach typu BLOB. 4.2.15. Załączniki, skany dokumentów itp. muszą być umieszczane na dyskach serwera aplikacyjnego jako pliki. Wykonawca musi zaproponować sposób katalogowania tych materiałów na dyskach tak, aby ograniczenia systemu operacyjnego nie miały wpływu na zarządzanie plikami." Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione, ponieważ ogranicza konkurencję. Funkcjonujące na rynku systemy ERP w alternatywny sposób rozwiązują zagadnienie związane z przechowywaniem obiektów typu skan dokumentu bezpośrednio w bazie danych. Tymczasem Zamawiający w nieuzasadniony sposób, poprzez sformułowanie negatywne ograniczył konkurencje: „Zamawiający nie zaakceptuje rozwiązania, w którym obiekty (np. skany dokumentów jako załączniki itp.) są przechowywane w bazie danych w polach typu BLOB. Zdaniem Odwołującego takie ograniczenie nie jest uzasadnione, ponieważ można wykazać, że przechowywanie załączników dokumentów w strukturach bazy danych jest rozwiązaniem bezpieczniejszym i bardziej niezależnym od technologii (co jest dla jednostki budżetowej korzystniejsze) niż składowanie ich w systemie operacyjnym. Przechowywanie załączników w systemie plików uzależnia System od konkretnego systemu plików, a więc często od konkretnego systemu operacyjnego. Powoduje, że każda z osób uzyskująca dostęp do katalogu, w którym zapisano pliki ma dostęp do wszystkich plików i często (w zależności od systemu operacyjnego) nie da się definiować uprawnień do poszczególnych plików I załączników. Ponadto wymagane jest objęcie struktury katalogów przechowujących takie pliki dodatkowymi zadaniami tworzenia kopii zapasowych, będących zabezpieczeniem przed utratą danych w przypadku awarii. Wszystkich tych wad pozbawione jest rozwiązanie przechowywania plików w bazie danych. To właśnie min. dla takich zastosowań producenci baz danych umożliwili składowanie plików w bazie danych w kolumnach typu BLOB. Funkcjonalność systemu bazodanowego umożliwia udostępnianie poszczególnym użytkownikom systemu dostępu nie tylko na poziomie struktury (tabeli) przechowującej dane, ale również do poszczególnym rekordów - w tym przypadku do poszczególnych załączników - skanów, przechowywanych w bazie danych. Ponadto załączniki te są zabezpieczone przed utratą za pomocą mechanizmów realizacji kopii bazy danych. Współczesne systemy zarządzania bazą danych pozwalają na optymalizację dostępu do danych typu BLOB, w sposób nie gorszy niż składowanie ich w systemie plików. Zdaniem Odwołującego nie ma więc uzasadnienia do traktowania przechowywania plików w polach BLOB jako rozwiązania gorszego. W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji SIWZ poprzez usunięcie w/w wymagania. XXIV. Zarzut dotyczący technologii - narzędzie do raportowania Zamawiający określił w pkt 19 dokumentu Załącznik nr 1 do siwz (str. 39) następujące wymaganie: „19. Generator raportów: System powinien umożliwiać tworzenie nowych raportów lub modyfikowanie standardowych ustawień istniejących raportów w sposób przyjazny dla użytkownika. Wymagana jest: (...) - przedstawienie zbiorów danych w formie rozwijanych list do wyboru (...) - przedstawienie list pól danej tabeli w formie rozwijanych list do wyboru (...)" Odwołujący zarzucał, że takie wymaganie jest nieuzasadnione, ponieważ ogranicza konkurencję, a w różnych narzędziach raportujących dostępnych na rynku taka funkcjonalność może być zrealizowana w inny sposób. W ocenie Odwołującego do realizacji wskazanych wymagań można użyć innych, alternatywnych kontrolek Interfejsu GUI (a nie tylko list rozwijanych), których w żadnym przypadku nie można uznać jako rozwiązań gorszych od wymaganych przez Zamawiającego. Tak sformułowane wymaganie sprawia, stwarza możliwość preferowania tylko jednego z rozwiązań istniejących na rynku. Zdaniem Odwołującego wystarczające byłoby wymaganie - bez wskazywania konkretnego sposobu realizacji, typu: - przedstawienie zbiorów danych w formie listy do wyboru (...) - przedstawienie listy poi danej tabeli do wyboru (...) W związku z powyższym Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji siwz poprzez usunięcie w/w wymagania. XXV. Zarzut dotyczący odpowiedzialności

[... tekst skrócony ...]