Pełny tekst orzeczenia

Sygn. akt: KIO 965/17


POSTANOWIENIE
z dnia 5 czerwca 2017 r.


Krajowa Izba Odwoławcza – w składzie:

Przewodniczący: Marek Koleśnikow

Protokolant: Adam Skowroński

po rozpoznaniu na rozprawie w dniu 29 maja 2017 r. w Warszawie odwołania wniesionego
do Prezesa Krajowej Izby Odwoławczej w dniu 12 maja 2017 r. przez wykonawcę Comarch
Polska S.A. z siedzibą w Krakowie, Al. Jana Pawła II 39A, 31-864 Kraków
w postępowaniu prowadzonym przez zamawiającego Miasto Katowice, ul. Młyńska 4,
40-098 Katowice
przy udziale wykonawców wspólnie ubiegających się o udzielenie zamówienia
1) COIG S.A. z siedzibą w Katowicach, ul. Mikołowska 100, 40-065 Katowice,
2) S&T Services Polska Sp. z o.o. z siedzibą w Warszawie, ul. Postępu 21D, 02-676
Warszawa,
3) Sputnik Software Sp. z o.o. z siedzibą w Poznaniu, Górecka 30, 60-201 Poznań
– zgłaszających przystąpienie do postępowania odwoławczego po stronie odwołującego


postanawia:


1) odrzuca odwołanie;

2) kosztami postępowania obciąża odwołującego Comarch Polska S.A. z siedzibą
w Krakowie, Al. Jana Pawła II 39A, 31-864 Kraków i zalicza w poczet kosztów
postępowania odwoławczego kwotę 15 000 zł 00 gr (słownie: piętnaście tysięcy złotych
zero groszy) uiszczoną przez wykonawcę Comarch Polska S.A. z siedzibą
w Krakowie, Al. Jana Pawła II 39A, 31-864 Kraków tytułem wpisu od odwołania.

Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. – Prawo zamówień
publicznych (Dz. U. z 2015 r. poz. 2164 oraz z 2016 poz. 831, 996, 1020, 1250, 1265, 1579
i 1920) na niniejsze postanowienie – 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 Katowicach.


Przewodniczący: ………………………………

Sygn. akt KIO 965/16

U z a s a d n i e n i e

Zamawiający Miasto Katowice, ul. Młyńska 4, 40-098 Katowice wszczął postępowanie w
trybie przetargu nieograniczonego na »Realizację projektu Miejskie Centrum Usług
Wspólnych w Katowicach«.

Ogłoszenie o zamówieniu zostało opublikowane w Dzienniku Urzędowym Unii
Europejskiej 11.04.2017 r. pod nrem 2017/S 071-134291.

Postępowanie jest prowadzone zgodnie z przepisami ustawy z dnia 29 stycznia 2004 r.
– Prawo zamówień publicznych (Dz. U. z 2015 r. poz. 2164 oraz z 2016 poz. 831, 996, 1020,
1250, 1265, 1579 i 1920) zwanej dalej w skrócie Pzp lub ustawą bez bliższego określenia.

Zamawiający udzielił 02.05.2017 r. odpowiedzi na pytania wykonawców do SIWZ
zgodnie z art. 38 ust. 1 Pzp.

Wykonawca Comarch Polska S.A., z siedzibą w Krakowie, Al. Jana Pawła 39a, 31-864
Kraków, zgodnie z art. 182 ust. 1 pkt 1 Pzp, wniósł 12.05.2017 r. do Prezesa KIO odwołanie.
na odpowiedzi zamawiającego do specyfikacji istotnych warunków zamówienia.

Odwołujący zarzucił zamawiającemu naruszenie:
1) art. 38 ust. 1 Pzp, a w konsekwencji – również art. 29 ust. 1 Pzp – przez
zaniechanie udzielenia odpowiedzi na pytania o wyjaśnienie treści SIWZ w sposób
prowadzący do wyjaśnienia wątpliwości co do treści SIWZ i zaniechania
doprowadzenia do dokonania opisu przedmiotu zamówienia w sposób zgodny z
przepisami ustawy, to jest jednoznaczny, wyczerpujący, z uwzględnieniem
wszystkich wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty;
2) art. 7 ust. 1 Pzp oraz art 90 ust. 1 Pzp przez wymaganie przedstawienia opisu
zmian dostosowujących lub modyfikacji systemu oraz szacunkowej przewidywanej
pracochłonności (roboczogodzin);
3) art. 7 ust. 1 Pzp w zw. z art. 87 ust. 1 Pzp w zw. z art. § 13 ust. 1 pkt 1
Rozporządzenia Ministra Rozwoju z dnia 26 lipca 2016 r. w sprawie rodzajów
dokumentów, jakich może żądać zamawiający od wykonawcy w postępowaniu o
udzielenie zamówienia (Dz. U. z 2016 r., poz. 1126):
a) przez określenie zasad przeprowadzania oceny ofert w ten sposób, że
Zamawiający może żądać przeprowadzenia demonstracji działania systemu tylko

w odniesieniu do niektórych wykonawców, a także – w różnym zakresie – co naru-
sza zasadę prowadzenia postępowania z zachowaniem uczciwej konkurencji
i równego traktowania wykonawców,
b) przez zaniechanie określenia przebiegu demonstracji (zaniechanie określenia
jakiegokolwiek scenariusza demonstracji) oraz kryteriów oceny, czy zaprezento-
wana funkcjonalność spełnia wymagania Zamawiającego, co uniemożliwia
wykonawcom zweryfikowanie przed terminem składania ofert, czy ich oferta może
być uznana za niezgodną z SIWZ, co również narusza zasadę uczciwej
konkurencji i równego traktowania wykonawców.

Odwołujący wniósł o:
modyfikację SIWZ w sposób określony w uzasadnieniu odwołania.

Argumentacja odwołującego
Zarzut naruszenia art. 38 ust. 1 Pzp oraz art. 29 ust. 1 Pzp
1.1. Charakter „Studium Wykonalności”
Zgodnie z treścią SIWZ, Zamawiający wskazał Załącznik nr 7 „Studium Wykonalności
dla projektu Miejskie Centrum Usług Wspólnych w Katowicach” jako element dokumentacji
przetargowej (załącznik do SIWZ). Jednocześnie pomiędzy treścią OPZ, a treścią Studium
Wykonalności zachodzi szereg sprzeczności, które Odwołujący przykładowo wskazał w
pytaniu nr 1 z 24 kwietnia 2017 r., wnosząc o określenie, że Studium Wykonalności ma
charakter wyłącznie informacyjny, a przedmiot zamówienia określony jest w Opisie
przedmiotu zamówienia.
Zamawiający udzielił następującej odpowiedzi: „Zamawiający potwierdza, że załączone
Studium Wykonalności projektu stanowi rolę dokumentu informacyjnego umożliwiającego
Wykonawcy pozyskanie informacji w kwestiach nieuregulowanych w Załączniku Nr 3 do
SIWZ – Szczegółowy Opis Przedmiotu Zamówienia. Nadrzędnym dokumentem nad Studium
Wykonalności jest Załącznik Nr 3 do SIWZ – Szczegółowy Opis Przedmiotu Zamówienia.
Ponadto na pytanie Odwołującego (Pytanie nr 2): „Prosimy o uzupełnienie SIWZ (jeśli
występuje taka potrzeba) o elementy wskazane przez Zamawiającego, a które to elementy
ujęto w „Studium Wykonalności dla projektu Miejskie Centrum Usług Wspólnych” – tak aby
SIWZ [z wyłączeniem Załącznika nr 7 „Studium Wykonalności dla projektu Miejskie Centrum
Usług Wspólnych”] stanowił kompletną dokumentację opisującą w sposób wyczerpujący
przedmiot zamówienia. Jednocześnie prosimy o korektę poniższych postanowień Załącznika
nr 3, tak aby jego treść nie odwoływała się do „Studium Wykonalności dla projektu Miejskie
Centrum Usług Wspólnych”:

– 3.4, Produkty i rezultaty (cele szczegółowe) wraz z metodologią ich monitoringu (...)
Produkty i rezultaty projektu przedstawione zostały w Studium Wykonalności projektu.
– 3.4.1. Produkty projektu (...) Szczegółowy wykaz wymaganych e-usług przedstawiono
w Studium Wykonalności”. Zamawiający udzielił następującej odpowiedzi;
„Zamawiający nie dokonuje zmiany SIWZ w tym zakresie. Odniesienia do Studium
Wykonalności w Załączniku Nr 3 do SIWZ – Szczegółowy Opis Przedmiotu
Zamówienia są wystarczająco jasno sformułowane”.

Powołane odpowiedzi oznaczają, że przedmiot zamówienia w dalszym ciągu opisany
jest nieprecyzyjnie i niejednoznacznie, ponieważ de facto Studium Wykonalności ma
uzupełniać OPZ, podczas gdy te dwa dokumenty – jak wskazano w pytaniu – pozostają ze
sobą w rozbieżności. Studium Wykonalności dla projektu Miejskie Centrum Usług Wspólnych
w Katowicach to obszerny dokument (323 strony) opracowany na potrzeby ubiegania się
Zamawiającego o dofinansowanie inwestycji ze środków UE i jego konstrukcja [zarówno w
formie, jak i w treści) odpowiada warunkom zakreślonym dokumentacją konkursową RPO
Województwa Śląskiego na lata 2014-2020. Przedmiotowy kształt Studium Wykonalności dla
projektu Miejskie Centrum Usług Wspólnych, jak również szczegółowa jego treść nie
koresponduje w sposób jednoznaczny i spójny z dokumentacją przetargową SIWZ, dla
przykładu:
A) Już sam harmonogram projektu przedstawiony w Studium Wykonalności nie
odpowiada harmonogramowi prac dla tego projektu, ponieważ w Studium
Wykonalności jako czas realizacji projektu wskazano na okres od 30.03.2016 do
31.12.2019, co stoi w sprzeczności z założeniami SIWZ i z racji wskazywania dat
historycznych [2016 r.] oczywiście nie jest możliwe w realizacji.
B) Również analiza szczegółowych postanowień Studium Wykonalności wskazuje na
rozbieżności w stosunku do postanowień SIWZ. Przykładem może być zakres
integracji. W Studium Wykonalności podkreślono integrację z systemem CEPIK
(integracja w zakresie zapytań o właściciela/użytkownika pojazdu, zapytanie dot.
pojazdu, zapytanie o kierowcę lub import danych) [str. 267], a w dokumentacji SIWZ
takiej integracji Zamawiający nie wymaga.
C) Sam Zamawiający podkreśla rozbieżności pomiędzy SIWZ a Studium Wykonalności,
co wskazano w Załączniku nr 3 do SIWZ, np.: 3.3. Architektura Systemu;
Przedstawiony w Studium Wykonalności zarys architektury Systemu nie obejmuje
Systemu Zarządzania Oświatą. Wykonawca w projekcie technicznym ma uwzględnić
zmiany wynikające z SIWZ.
Takich rozbieżności jest więcej i dotyczą one różnych aspektów przedmiotu zamówienia.
Nie jest rolą wykonawcy porównywanie postanowień treści SIWZ/OPZ z treścią Studium

Wykonalności i decydowanie, jakie postanowienia i z którego dokumentu są wiążące,
zwłaszcza, że brzmienie wyspecyfikowanych wymagań funkcjonalnych w SIWZ również nie
jest kopią 1:1 wymagań ze Studium Wykonalności, a różnica w treści wymagań ma istotne
przełożenie na wycenę przedmiotu zamówienia. W Studium Wykonalności Zamawiający
umieścił szereg wymagań, które nie mają odzwierciedlenia w SIWZ – np. wymagania
sprzętowe do szaf i serwerowni, a przykładów takich jest znacznie więcej.

Odwołujący zarzuca, że odpowiedź Zamawiającego jest niejasna, niespójna i powoduje
naruszenie przepisów ustawy Pzp. W ocenie Odwołującego użyty w odpowiedzi
Zamawiającego zwrot, że Studium Wykonalności projektu stanowi rolę dokumentu
informacyjnego „umożliwiającego Wykonawcy pozyskanie informacji – w kwestiach
nieuregulowanych w Załączniku Nr 3 do SIWZ – Szczegółowy Opis Przedmiotu Zamówienia”
nie usuwa niejednoznaczności roli Studium Wykonalności w kontekście zakresu OPZ.
Odwołujący nie wie, jak Zamawiający interpretuje zwrot „w kwestiach nieuregulowanych”.
Taka konstrukcja odpowiedzi Zamawiającego może wskazywać w skrajnej sytuacji na
realizację wszystkich elementów/zagadnień opisanych w „Studium Wykonalności”, które nie
znalazły się w Załączniku Nr 3 do SIWZ (Opis Przedmiotu Zamówienia). Nie jest rolą
Odwołującego, aby oceniać, które elementy Studium Wykonalności stanowią uzupełnienie
„kwestii nieuregulowanych” w OPZ (Załącznik nr 3 do SIWZ).
Odwołujący zarzuca, że odpowiedź Zamawiającego jest niezgodna z przepisami ustawy
Pzp wskazującymi, że przedmiot zamówienia winien być opisany w sposób jednoznaczny i
wyczerpujący. Na Zamawiającym spoczywa obowiązek jasnego i precyzyjnego określenia
przedmiotu zamówienia, a udzielona przez Zamawiającego odpowiedź stoi w sprzeczności z
art. 29 ust. 1 Pzp wskazującym, że przedmiot zamówienia ma być opisany za pomocą
dostatecznie dokładnych i zrozumiałych określeń, z uwzględnieniem wszystkich wymagań i
okoliczności mogących mieć wpływ na sporządzenie oferty.
Tę nieprecyzyjną koncepcję i konstrukcję SIWZ Zamawiającego potwierdza również
odpowiedź na Pytanie nr 2, w którym Odwołujący, chcąc postawić wyraźną granicę między
dokumentacją przetargową [m.in. Załącznik nr 3 do SIWZ – OPZ], a treścią Studium
Wykonalności, zwrócił się do Zamawiającego o uzupełnienie SIWZ (jeśli występuje taka
potrzeba) o elementy wskazane przez Zamawiającego, a które to elementy ujęto w „Studium
Wykonalności dla projektu Miejskie Centrum Usług Wspólnych” – tak aby SIWZ [z
wyłączeniem Załącznika nr 7 „Studium Wykonalności dla projektu Miejskie Centrum Usług
Wspólnych”] stanowił kompletną dokumentację opisującą w sposób wyczerpujący przedmiot
zamówienia.

Jednocześnie Odwołujący wniósł o korektę postanowień Załącznika nr 3 do SIWZ, tak
aby jego treść nie odwoływała się do „Studium Wykonalności dla projektu Miejskie Centrum
Usług Wspólnych”, a takie odwołanie ma miejsce w pkt:
– 3.4. Produkty i rezultaty (cele szczegółowe) wraz z metodologią ich monitoringu:
„Produkty i rezultaty projektu przedstawione zostały w Studium Wykonalności
projektu”,
– 3.4.1. Produkty projektu: „Szczegółowy wykaz smaganych e-usług przedstawiono w
Studium Wykonalności”.
Zamawiający nie dokonał zmiany SIWZ w tym zakresie, uznając, że odniesienia do
Studium Wykonalności w Załączniku Nr 3 do SIWZ „są wystarczająco jasno sformułowane”.
Z opinią tą nie można się zgodzić. Utrzymanie przywołanych postanowień w obecnym
brzmieniu (pomimo uznania przez Zamawiającego, że Studium Wykonalności jest
dokumentem o charakterze informacyjnym i podrzędnym w stosunku do dokumentacji
przetargowej) skutkuje de facto „włączeniem” Studium Wykonalności do dokumentacji
składającej się na Specyfikację Istotnych Warunków Zamówienia również w postanowieniach
sprzecznych z SIWZ (np. w zakresie bazy danych Oracle).
Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ przez uzupełnienie SIWZ
o zmianę dokumentacji postępowania tak, aby opis przedmiotu zamówienia określony w
SIWZ był jednoznaczny – co wiązać się musi z określeniem wyłącznie
poglądowego/informacyjnego charakteru Załącznika nr 7 „Studium Wykonalności dla
projektu Miejskie Centrum Usług Wspólnych”, bez jakiejkolwiek koncepcji „uzupełniania”
przez ten załącznik treści OPZ.

1.2. Niespójna i niekompletna specyfikacja posiadanej przez Zamawiającego platformy
sprzętowo-programowej
Zgodnie z pkt 3.1 Przedmiot zamówienia obejmuje: dostawę i instalację Infrastruktury
technicznej niezbędnej do realizacji przedmiotu zamówienia oraz zapewnienia ciągłego i
prawidłowego funkcjonowania Systemu; dostawę i instalację licencji na Standardowe
Oprogramowanie Systemowe; które jest niezbędne do realizacji Przedmiotu Zamówienia
oraz zapewnienia ciągłego i prawidłowego funkcjonowania Systemu”.
W pytaniu nr 3 Odwołujący zwrócił się z następującym wnioskiem: „Prosimy o
wyjaśnienie jak powyższe postanowienia korespondują z informacjami przedstawionymi w
Załączniku nr 5 „Opis infrastruktury Zamawiającego” w szczególności prosimy o wyraźne
określenie jakie elementy platformy sprzętowo-programowej na potrzeby przedmiotowego
wdrożenia zapewni Zamawiający, a jakie elementy platformy sprzętowo-programowej ma
dostarczyć Wykonawca?”.

Zamawiający udzielił następującej odpowiedzi: Wykonawca winien dostarczyć i
zainstalować w ramach zamówienia infrastrukturę systemową tak, aby w sumie z dotychczas
posiadaną przez Zamawiającego infrastrukturą zapewniała prawidłowe działanie
oferowanego systemu. To Wykonawca musi sam ocenić, o jakie elementy należy uzupełnić
infrastrukturę Zamawiającego wymienioną w Załączniku nr 5 „Opis infrastruktury
Zamawiającego”, aby zaoferowane przez Wykonawcę oprogramowanie działało prawidłowo i
zgodnie z wymogami SIWZ.

Ponadto, na pytanie Odwołującego (Pytanie nr 11): Prosimy o szczegółowe
wyspecyfikowanie posiadanych przez Zamawiającego licencji na oprogramowanie
bazodanowe. W Załączniku nr 5 „Opis infrastruktury Zamawiającego” Zamawiający wskazuje
na bazę Oracle Standard Edition, natomiast w Studium Wykonalności, Zamawiający
wskazuje na bazę Oracle Enterprise Edition” – Zamawiający udzielił następującej
odpowiedzi: „Zamawiający wyjaśnia, że posiada aktualnie zarówno licencję bazy danych
Oracle Database Standard na 2 procesory jak i Oracle Database Enterprise Perpetual na 4
procesory, która będzie w bieżącym roku upgrade'owana do wersji 11. Licencja Oracle
Database Standard objęta jest asystą producenta do 2018 r; Licencja Oracle w wersji
Enterprise nie ma wykupionej asysty producenta od początku 2016 r.”.
W Pytaniach nr 3 i nr 11 Odwołujący zwrócił się o przedstawienie w sposób kompletny i
spójny specyfikacji podsiadanej przez Zamawiającego platformy sprzętowo-programowej.
Odwołujący wykazał w sposób jednoznaczny niespójność [na przykładzie bazy danych]
pomiędzy treścią Załącznika nr 5 „Opis infrastruktury Zamawiającego” a dokumentem
„Studium Wykonalności”. W Załączniku nr 5 Zamawiający wskazał, że posiada bazę Oracle
Standard Edition, natomiast w Studium Wykonalności Zamawiający potwierdził, że
dysponuje bazą Oracle Enterprise Edition. To dwa różne produkty charakteryzujące się
innymi cechami i warunkami licencyjnymi.
Przedmiotowe rozbieżności dotyczące bazy danych Oracle nie są wyjątkiem. Są też inne
różnice pomiędzy Załącznikiem nr 5 do SIWZ a Studium Wykonalności (Załącznik nr 7 do
SIWZ).

W Załączniku nr 5 do SIWZ jest mowa o 22 procesorach z ESX [2x8 + 2x3 = 22]
5.1.1. Serwery
Tabela 39. Zestawienie parametrów fizycznych serwerów typu....

Procesor Rozmiar pamięci RAM [GB] Liczba sztuk System operacyjny
2xE5-2670 256 8 ESX 5.5u3
2xE5-2670v3 384 3 ESX 5,5u3
2xX5570 144 2 Ms-SQL

A w Studium Wykonalności (Załącznik nr 7 do SIWZ) na str. 152 Zamawiający wskazuje
na 20 procesorów z ESX.
»Istnieje możliwość wykorzystania Istniejących rozwiązań wirtualizacji zrealizowanych z
pomocą VMWare ESX. UMK posiada licencję na 20 procesorów oraz w ramach licencji ESX
posiada licencje na 16 procesorów MS Server Data Center 2012, W momencie opracowania
[…] koncepcji, utylizacja procesora wynosi średnio 3%. Utylizacja pamięci wynosi ok. 30%.
Utylizacja sieci wynosi ok. 1%«.
W Studium Wykonalności (Załącznik nr 7 do SIWZ) na str. 152 jest informacja o
systemie backup.
»W przypadku mechanizmów przechowywania danych archiwalnych oraz Ich
odtwarzania, istnieje możliwość wykorzystania istniejących mechanizmów backupu, w tym:
a) Bibliotekę LTO5 Quantum;
b) System do backupu Symantec Net8ackup, Wykorzystywany jest w trzech
lokalizacjach;
c) VTL IBM 3500, protectTlER«.

Powyższej Informacji (o systemie backup] nie ma w Załączniku nr 5 do SIWZ.
W Studium Wykonalności (Załącznik nr 7 do SIWZ) od str. 169 do str. 175 w pkt 5,4
opisane są warianty docelowego stanu zasobów IT Urzędu Miasta Katowice i Jednostek
Organizacyjnych:
»5.4 Docelowy stan zasobów IT UMK I JO.
Docelowy stan zasobów IT UMK I JO zależy od podjętych decyzji, w tym m.in. wariantów
kolokacji oraz praktycznych efektów wdrożeń rozwiązań (np. sieci SilesiaNet). W ramach
zarządzania infrastrukturą zostaną świadczone usługi wspierające infrastrukturę techniczną
systemu, wyszczególnione poniżej.
W zależności od przyjętego wariantu przedstawionego w poprzednim rozdziale poniżej
przedstawiono wymagania dotyczące Infrastruktury technicznej związane z każdym z nich«.

Natomiast brak jest w Załączniku nr 5 do SIWZ informacji (korespondującej ze Studium
Wykonalności) o obecnych i udostępnionych zasobach do realizacji zamówienia,

Tym samym udzielone przez Zamawiającego odpowiedzi uniemożliwiają dokonanie
Wykonawcy miarodajnej oceny, o jakie elementy należy doposażyć infrastrukturę systemową
Zamawiającego, tak, aby w sumie z dotychczas posiadaną przez Zamawiającego
infrastrukturą zapewniała prawidłowe działanie oferowanego systemu zgodnie z wymogami
SIWZ. Odwołujący wskazał, że biorąc pod uwagę skalę tego projektu koszt rozbudowy
platformy sprzętowo-programowej Zamawiającego będzie kosztem znaczącym w cenie

oferty, stąd niezbędna jest kompletna i nie budząca wątpliwości informacja o posiadanej
przez Zamawiającego infrastrukturze sprzętowo-programowej, którą Wykonawca będzie
mógł wykorzystać na potrzeby realizacji projektu.
Zamawiający przyznał, że występuje rozbieżność między treścią Załącznika nr 5 „Opis
infrastruktury Zamawiającego” a dokumentem „Studium Wykonalności”, ale nie dokonał
żadnej modyfikacji (uzupełnienia) Załącznika nr 5, tak aby przedmiotowy załącznik faktycznie
przedstawiał kompletną specyfikację platformy sprzętowo-programowej Zamawiającego.
Zatem Wykonawca wciąż nie posiada kompletnej wiedzy o posiadanej faktycznie przez
Zamawiającego infrastrukturze sprzętowo-programowej, z której Wykonawca będzie mógł
skorzystać w toku realizacji przedmiotowego projektu.

Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ przez uzupełnienie SIWZ
(w szczególności Załącznika nr 5) o elementy dotyczące Infrastruktury
sprzętowo-programowej wskazanej przez Zamawiającego, a które to elementy ujęto w
„Studium Wykonalności dla projektu Miejskie Centrum Usług Wspólnych” – tak aby SIWZ [z
wyłączeniem Załącznika nr 7 „Studium Wykonalności dla projektu Miejskie Centrum Usług
Wspólnych”) stanowi kompletną dokumentację opisującą w sposób wyczerpujący przedmiot
zamówienia w zakresie udostępnionej na potrzeby realizacji przedmiotowego zamówienia
przez Zamawiającego platformy sprzętowo-programowej.

1.3. Niejednoznacznie określona liczba podmiotów objętych projektem
Zgodnie z treścią Załącznika nr 3 do SIWZ, Zamawiający wskazał, że przedmiot
zamówienia zostanie zrealizowany w 209 jednostkach.
Na pytanie Odwołującego (Pytanie nr 5): „Prosimy o podanie:
liczby lokalizacji objętych wdrożeniem,
lokalizacji objętych wdrożeniem,
liczby Użytkowników w poszczególnych lokalizacjach,
średniego opóźnienia w transmisji pakietów (latency) pomiędzy centralą a
przedmiotowymi lokalizacjami”.
Zamawiający udzielił następującej odpowiedzi: „Wdrożeniem objęte zostaną wszystkie
jednostki organizacyjne miasta Katowice, jakie będą funkcjonowały przed przystąpieniem do
realizacji etapu V „Docelowe wdrożenie Systemu” Ponieważ liczba i lokalizacja jednostek
miejskich ulega zmianie, w Załączniku nr 3 podano orientacyjną liczbę jednostek i
użytkowników objętych wdrożeniem – liczbę aktualną na moment przygotowania SIWZ. W
Załączniku nr 7 „Studium Wykonalności dla projektu Miejskie Centrum Usług Wspólnych*
znajdują się adresy jednostek miejskich na moment przygotowania Studium Wykonalności
Zamawiający zakłada; że do końca wdrożenia projektu wszystkie jednostki miejskie

podlegające wdrożeniu będą podłączone do miejskiej szerokopasmowej sieci
teleinformatycznej NGN SilesiaNet”.
Odwołujący zarzuca, że odpowiedź Zamawiającego jest niezgodna z przepisami ustawy
Pzp wskazującymi, że przedmiot zamówienia winien być opisany w sposób jednoznaczny i
wyczerpujący. W ocenie Odwołującego treść odpowiedzi Zamawiającego jest
niedopuszczalna, ponieważ uniemożliwia Wykonawcy dokonanie oceny stopnia złożoności
projektu, a tym samym nie pozwala na przygotowanie rzetelnej wyceny swojej oferty.
Odwołujący zwraca uwagę, że dołączenie do projektu kolejnych jednostek to nie tylko
doliczenie dodatkowych licencji dla tychże podmiotów, ale szereg prac stricte wdrożeniowych
(konfiguracja, migracja, testy, szkolenia, uruchomienie produkcyjne, itp.), które w bardzo
istotnym stopniu determinują koszt wdrożenia, a tym samym cenę oferty. Ponadto istotne
jest jakie są to jednostki, jakie funkcjonalności realizują/jaki mają charakter działalności, co i
jak będzie integrowane, a co migrowane.

Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ przez jednoznaczne
wskazanie:
a) lokalizacji (adresów) i nazw podmiotów objętych wdrożeniem,
b) liczby Użytkowników w poszczególnych lokalizacjach,
c) średniego opóźnienia w transmisji pakietów (latency) pomiędzy centralą a
przedmiotowymi lokalizacjami,
d) szczegółowej informacji o posiadanych systemach, sposobie i zakresie migracji, oraz
sposobie i zakresie integracji z tymi systemami.

1.4. Niedookreślenie zakresu zamówienia w kontekście zgodności z regulaminami
wewnętrznymi UM Katowice i jednostek organizacyjnych miasta Katowice
Zgodnie z treścią wymagań dotyczących przedmiotu zamówienia – WN-1 Zgodność z
regulaminami wewnętrznymi UM Katowice i jednostek organizacyjnych miasta Katowice, w
tym z instrukcją obiegu dokumentów (dopuszcza się dostosowanie przepisów wewnętrznych
w wyniku wdrożenia Systemu, jednak zmiany muszą być uzgodnione i zaakceptowane przez
UM Katowice).
Na pytanie Odwołującego (Pytanie nr 57); PZ uwagi na konieczność oszacowania
kosztów oferty jak również stwierdzenia czy w standardzie system spełnia cytowane
wymaganie, prosimy o;
Załączenie do SIWZ wszystkich regulaminów wewnętrznych UM Katowice i jednostek
organizacyjnych miasta Katowice, których dotyczy to wymaganie,
Dla każdego z regulaminów wskazania funkcjonalności jakiej dotyczą te akty,

Wyjaśnienie jak w kontekście wymagania funkcjonalnego, które Oferenci potencjalnie
zadeklarują jako spełnione w standardzie, Zamawiający rozumie postanowienie: „dopuszcza
się dostosowanie przepisów wewnętrznych w wyniku wdrożenia Systemu, jednak zmiany
muszą być uzgodnione i zaakceptowane przez UM Katowice”.
Zamawiający udzielił następującej odpowiedzi: „Zamawiający udostępni wszystkie
regulaminy UM Katowice i jednostek organizacyjnych miasta Katowice na etapie realizacji
zamówienia. Wymóg ten mówi jedynie Wykonawcy, że wdrażany system po zakończeniu
wdrożenia musi realizować swoje funkcje zgodnie z wewnętrznymi regulacjami w mieście
Katowice. Wymóg WN-01 jest wymogiem niefunkcjonalnym i nie podlega ocenie w ramach
kryterium funkcjonalności systemu. W tabeli wymagań niefunkcjonalnych nie ma miejsca na
zaznaczanie, czy dany wymóg spełniony jest w standardzie, czy będzie realizowany w
trakcie wdrożenia”.
Odwołujący zarzuca, że odpowiedź Zamawiającego jest niezgodna z przepisami ustawy
Pzp wskazującymi, że przedmiot zamówienia winien być opisany w sposób jednoznaczny i
wyczerpujący. W ocenie Odwołującego treść odpowiedzi Zamawiającego jest
niedopuszczalna, ponieważ uniemożliwia Wykonawcy ocenę stopnia złożoności projektu, a
tym samym nie pozwala na przygotowanie miarodajnej wyceny swojej oferty. Wykonawca
nie dysponuje przedmiotowymi regulaminami, a udostępnienie tych dokumentów „na etapie
realizacji zamówienia”' uniemożliwia Wykonawcy dokonanie oceny stopnia złożoności tychże
regulacji prawnych, a tym samym ich wpływu na koszt wdrożenia. Podkreślić należy, że
mowa jest o ponad 200 jednostkach, z których każda może mieć inne regulacje wewnętrze i
inny regulamin. Wykonawca nie ma możliwości dokonania na etapie składania ofert oceny
jakie funkcjonalności składają się na zamówienie. To, że jak pisze w odpowiedzi
Zamawiający, przedmiotowe wymagania nie są ujęte w wymaganiach funkcjonalnych
Załącznika nr 3 do SIWZ nie oznacza, że nie determinują one zakresu funkcjonalnego.
Przedmiotowe regulacje wewnętrzne mają przy tak sformułowanym wymaganiu WN-1 istotny
wpływ na generowanie dodatkowych kosztów po stronie Wykonawcy dotyczących
konfiguracji systemu (np. obiegów dokumentów, wydruków, uprawnień] a niejednokrotnie na
funkcjonalność systemu. Niezrozumiałe jest również postanowienie, które wskazuje, że
uzgadnianie zmian w regulacjach wewnętrznych jednostek podległych miastu, a
stanowiących osobne podmioty prawne (o takich regulacjach mówi również wymaganie WN-
1) wymaga akceptacji UM Katowice. Czy z postanowienia tego wynika, że urzędnicy UM
Katowice będą akceptować zmiany w regulacjach odrębnych podmiotów prawnych?

Odwołujący wniósł o:
a) załączenie do SIWZ wszystkich regulaminów wewnętrznych UM Katowice i jednostek
organizacyjnych miasta Katowice, których dotyczy wymaganie »WN-1 Zgodność z

regulaminami wewnętrznymi UM Katowice i jednostek organizacyjnych miasta
Katowice, w tym z Instrukcją obiegu dokumentów (dopuszcza się dostosowanie
przepisów wewnętrznych w wyniku wdrożenia Systemu, jednak zmiany muszą być
uzgodnione i zaakceptowane przez UM Katowice)”,
b) wskazanie dla każdego z regulaminów funkcjonalności jakich dotyczą te akty,
c) wyjaśnienie jak w kontekście wymagania funkcjonalnego, które Oferenci potencjalnie
zadeklarują jako spełnione, Zamawiający rozumie postanowienie: „dopuszcza się
dostosowanie przepisów wewnętrznych w wyniku wdrożenia Systemu, jednak zmiany
muszą być uzgodnione i zaakceptowane przez UM Katowice Obecne brzmienie
zakład a, że UM Katowice może odmówić dostosowania regulacji co może
powodować konieczność modyfikacji systemu, a więc dodatkowe koszty, których nie
da się oszacować na etapie przygotowania oferty,
d) zmianę terminu składania ofert w taki sposób, aby wykonawcy mieli możliwość
zapoznania się z załączonymi regulacjami i uwzględnienia kosztów wynikających z
analizy tych dokumentów w złożonej ofercie.

1.5. Niedookreślenie zakresu zamówienia w kontekście migracji i integracji systemów
wyspecyfikowanych w Załączniku nr 9
Zgodnie z treścią wymagań w pkt 3,8: Wymagania w zakresie migracji danych: Obecnie
w jednostkach wykorzystywane są systemy wg załączonego wykazu (załącznik nr 9) –
uszczegółowienie z których systemów i w jakim zakresie migrowane zostaną dane zostanie
uzgodnione pomiędzy Wykonawcą i Zamawiającym na podstawie propozycji Wykonawcy
podczas realizacji Etapu ii Analiza i Projekt Techniczny Systemu. Przedstawiona propozycja
musi uwzględniać założenie, że migracji będą podlegać przynajmniej dane, które są
niezbędne do zachowania ciągłości realizacji w nowym Systemie zadań jednostki oraz
zgodnie z treścią wymagań w pkt 3.9.
Wymagania w zakresie integracji Systemu – System powinien współpracować w
zakresie wymiany danych również z innymi, używanymi w jednostkach organizacyjnych
miasta Katowice przez Zamawiającego, systemami – wykaz systemów wykorzystywanych w
jednostkach stanowi załącznik nr 9 – uszczegółowienie systemów które będą integrowane i
zakresu integracji zostanie uzgodnione pomiędzy Wykonawcą i Zamawiającym na podstawie
propozycji Wykonawcy podczas realizacji Etapu Ii Analiza i Projekt Techniczny Systemu.
Na pytanie Odwołującego (Pytanie nr 10): „Prosimy o jednoznaczne wyspecyfikowanie,
które systemy wykazane w Załączniku nr 9 będą objęte migracją, a które będą objęte
integracją” Zamawiający udzielił następującej odpowiedzi: „Decyzja o tym, dane z których
systemów dotychczas użytkowanych zostaną zmigrowane, a które objęte integracją zostanie
podjęta na podstawie propozycji Wykonawcy podczas realizacji Etapu H Analiza i Projekt

Techniczny Systemu. Generalną zasadą będzie; że dane z systemów dotychczas
użytkowanych, których funkcjonalność realizowana będzie przez zaoferowany przez
Wykonawcę System Miejskiego Centrum Usług Wspólnych, zostaną w tej części
zmigrowane, a jeśli systemy posiadają dodatkową funkcjonalność wymagającą integracji ze
zmigrowanymi danymi, to w tej części będą podlegały integracji. Do tej generalnej zasady
odnosi się stwierdzenie „migracji będą podlegać przynajmniej dane, które są niezbędne do
zachowania ciągłości realizacji w nowym Systemie zadań jednostki”.
Odwołujący zwrócił się do Zamawiającego o jednoznaczne wyspecyfikowanie, które
systemy wykazane w Załączniku nr 9 będą objęte migracją, a które będą objęte integracją i
nie uzyskał wiążącej odpowiedzi, a jedynie informację, że decyzja o tym, z których systemów
dotychczas użytkowanych dane zostaną zmigrowane, a które systemy będą objęte integracją
zostanie podjęta podczas realizacji Etapu II Analiza i Projekt Techniczny Systemu. W tym
miejscu należy podkreślić, że w Załączniku nr 9 Zamawiający wyspecyfikował systemy
działające w ponad 100 podmiotach (!), a w wybranych podmiotach eksploatowanych jest po
kilka systemów. Równocześnie Zamawiający nigdzie nie przedstawił zakresu funkcjonalnego
informującego wykonawców, jaka jest funkcjonalność tych systemów, Mówimy zatem o
bardzo znaczącej liczbie systemów. Zakres prac związanych z migracją jest kompletnie
nieporównywalny z zakresem prac realizowanych przy integracji. Pojęcia te różni specyfika
prac, stopień złożoności wdrożenia, a co za tym idzie odmienna pracochłonność tychże
czynności w toku realizacji projektu. Integracja niejednokrotnie wymaga dostosowania
systemów zewnętrznych do integracji, a nawet jeżeli prace te realizuje Zamawiający to mają
one wpływ na harmonogram, a tym samym na koszty po stronie Wykonawcy. Nie można
zatem uznać, że dla wykonawców nie stanowi żadnej różnicy, czy dany system będzie objęty
migracją czy integracją. Tym bardziej, że z odpowiedzi Zamawiającego wynika, że „jeśli
systemy posiadają dodatkową funkcjonalność wymagającą integracji ze zmigrowanymi
danymi, to w tej części będą podlegały integracji Czyli nawet przy założeniu, że dane będą
migrowane, może się okazać, że Zamawiający będzie wymagał integracji – jednak obecnie
nie przedstawiono funkcjonalności systemów, więc nie ma możliwości stwierdzenia, czy
systemy te posiadają dodatkową funkcjonalność wymagającą integracji ze zmigrowanymi
danymi, Rozróżnienie pomiędzy migracją i integracją oraz informacja dotycząca zakresu
integracji ma bezpośredni wpływ na ocenienie skali złożoności projektu, a w efekcie
przekłada się na oszacowanie kosztów prac w tym zakresie. Nie można zatem pojęć migracji
i integracji traktować jako czynności wiążących się z identycznymi nakładami pracy.
Odpowiedź Zamawiającego uniemożliwia Wykonawcy ocenę stopnia złożoności projektu, a
tym samym nie pozwala na przygotowanie miarodajnej wyceny oferty. Z odpowiedzi tej
wynika, że koszty oferty będzie można oszacować dopiero po przeprowadzeniu analizy
przedwdrożeniowej, a więc po rozstrzygnięciu przetargu i podpisaniu umowy.

Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ przez jednoznaczne
wskazanie, które systemy wykazane w Załączniku nr 9 będą objęte migracją, a które będą
objęte integracją. Równocześnie Odwołujący wniósł o nakazanie Zamawiającemu dla
każdego z migrowanych systemów określenia co najmniej zakresu, sposobu i formatu
dostarczenia danych do migracji, wolumenu danych oraz zapewnienia, że za poprawność,
spójność oraz opis merytoryczny tych danych odpowiada Zamawiający.

1.6. Niedookreślenie zakresu zamówienia w zakresie wymagania integracji z systemami
dziedzinowymi UM Katowice
Zgodnie z treścią wymagań do przedmiotu zamówienia: WF. 08 Integracja z systemami
dziedzinowymi UM Katowice (zgodnie z założeniami integracji określonymi w niemniejszym
dokumencie).
Na pytanie Odwołującego (Pytanie nr 51): „Ponieważ w ramach rozdziału 3.10
Wymagania w zakresie integracji Zamawiający oprócz publicznych systemów (np. Płatnik, e-
ZLAj Besti(g>) z udokumentowanym interfejsem wymienił inne systemy i rozwiązania np,
SELWIN, Kataster WZ, MSZKIIP, dla których standardowe rozwiązania nie mają interfejsów
wymiany danych. Równocześnie dla wymagania Zamawiający wymaga oznaczenia, czy
dana funkcjonalność jest w standardzie – co w nieuzasadniony sposób preferuje
producentów tych systemów. Prosimy w związku z tym o zmianę treści wymagania
ograniczając integrację, nie do wszystkich systemów, a jedynie do tych, dla których
integracja wynika z przepisów prawa – tj. Płatnik, e-ZLA, Besti@”.
Zamawiający udzielił następującej odpowiedzi: „Zamawiający nie zmienia SIWZ w tym
zakresie”.
W ocenie Odwołującego podtrzymanie dotychczasowego brzmienia wymagania jest
niedopuszczalne, ponieważ obecne postanowienie w nieuzasadniony sposób preferuje
producentów systemów, dla których standardowe rozwiązania nie mają interfejsów wymiany
danych np. SELWIN, Kataster WZ, MSZKIIP. Należy podkreślić, że wymaganie WF-08 ma
priorytet 1, a zgodnie z OPZ oraz wyjaśnieniami Zamawiającego wymaganie takie musi być
zaoferowane, czyli nie można go pominąć, oraz zaznaczenie takiego wymagania jako
spełnionego w standardzie ma istotny wpływ na ocenę oferty, jak również może podlegać
badaniu w ramach prezentacji po wybraniu oferty jako najkorzystniejszej, Tym samym
dostawca nie dysponujący prawami autorskimi do systemu np. SELWIN firmy Sygnity SA,
nawet jeżeli posiada taką integrację w standardzie, będzie być może musiał zaprezentować
ją w przypadku uznania jego oferty za najkorzystniejszą. Taka treść specyfikacji w
nieuzasadniony sposób preferuje producentów i partnerów rozwiązań, z którymi ma się
integrować dostarczany System. Dodatkowo integracja ma dotyczyć systemów

dziedzinowych UM Katowice (zgodnie z założeniami integracji określonymi w niemniejszym
dokumencie [SIWZ]). Tymczasem zgodnie z wyjaśnieniami Zamawiającego założenia te
zostaną określone na etapie analizy przedwdrożeniowej.

Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ przez ograniczenie
wymagania „WF. 08 Integracja z systemami dziedzinowymi UM Katowice (zgodnie z
założeniami integracji określonymi w niniejszym dokumencie)” w zakresie integracji do tych
systemów, dla których integracja wynika z przepisów prawa – tj. Płatnik, e-ZLA, Besti@.

1.7. Niedookreślenie zakresu zamówienia w kontekście obszaru Zarządzanie Majątkiem
Trwałym (Środki Trwałe)
W wyspecyfikowanych wymaganiach dotyczących systemu nie zostały opisane
wymagania odnośnie Zarządzania Majątkiem Trwałym. 0 Środkach Trwałych Zamawiający
wspomina jedynie w związku z wymianą danych, ubezpieczaniem środków oraz migracją
danych.
Odwołujący w pytaniu nr 19 prosił zatem o wyjaśnienie:
czy należy uznać, że funkcjonalności zarządzania majątkiem trwałym nie są objęte
przedmiotem zamówienia?
czy majątek trwały będzie obsługiwany przez system zewnętrzny, a jeśli tak to jaki?
czy dane o majątku będą obsługiwane jedynie księgowo, jak wtedy należy rozumieć
wymagania odnośnie komunikacji i ubezpieczeń?
Wymagania te obejmują tylko wybrane elementy majątku i zakładają integrację ze
Środkami Trwałymi:
WF.387 Ewidencja nieruchomości własnych (własność, użytkowanie wieczyste, najem)
Urzędu, w tym m.in.: gruntów, budynków. Integracja z ewidencją środków trwałych.
WF.388 Ewidencja majątku ruchomego (floty samochodów). Integracja z ewidencją
środków trwałych.
WF.399 Ewidencjonowanie ubezpieczeń majątku trwałego.
WF.405 Pełna integracja z komponentem w ramach, którego obsługiwane są środki
trwałe.
WN-1 Rozporządzenie Rady Ministrów z dnia 3 października 2016 r. w sprawie
klasyfikacji środków trwałych (Dz.U. z 2016 r. poz. 1864)
WF.267 Rejestracja i rozliczanie przydzielonych dodatkowych świadczeń,
niewymaganych przepisami prawnymi (np.: samochód służbowy, służbowy telefon
komórkowy, laptop służbowy, bony towarowo-podarunkowe). Powiązanie wyposażenia
pracownika z ewidencją Środków Trwałych.

Zamawiający udzielił następującej odpowiedzi: „Zarządzanie majątkiem jest
przedmiotem niniejszego zamówienia. System powinien przewidywać dotychczasową
funkcjonalność w ww. zakresach. Obecnie w Urzędzie Miasta Katowice księgi inwentarzowe
obsługiwane są przez komórki organizacyjne, które połączone są z systemem środki trwałe
w którym analitycznie ewidencjonuje się poszczególne składniki majątku, uzgadniając z
danymi księgowanymi w systemie finansowo – księgowym
Użytego przez Zamawiającego stwierdzenia, że „System powinien przewidywać
dotychczasową funkcjonalność w ww. zakresach” nie można uznać za opis precyzujący
zakres zamówienia w zakresie Zarządzania Majątkiem Trwałym. Odwołujący nie ma wiedzy,
jaką „dotychczasową funkcjonalność” realizują systemy eksploatowane przez
Zamawiającego w zakresie obsługi środków trwałych, W ocenie Odwołującego treść
odpowiedzi Zamawiającego jest zatem niedopuszczalna, ponieważ uniemożliwia ona
Wykonawcy ocenę stopnia złożoności projektu, a tym samym nie pozwala na przygotowanie
rzetelnej wyceny oferty.

Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ przez jednoznaczne
wyspecyfikowanie enumeratywnej listy wymagań w zakresie obszaru Zarządzanie Majątkiem
Trwałym (Środki Trwałe).

1.8. Niedookreślenie zakresu zamówienia w kontekście „Pilotażowego wdrożenia
Systemu”
Zgodnie z treścią SIWZ: Etap IV Pilotażowe wdrożenie Systemu – prace wdrożeniowe,
mające na celu dostarczenie sparametryzowanego i przetestowanego Systemu dla
wybranych jednostek organizacyjnych Zamawiającego.
Na pytanie Odwołującego [Pytanie nr 41): „Prosimy o szczegółowe opisanie oczekiwań
Zamawiającego w zakresie „Pilotażowego wdrożenia Systemu”, w tym w szczególności
prosimy o wyspecyfikowanie:
nazw jednostek objętych pilotażowym wdrożeniem,
liczby jednostek objętych pilotażowym wdrożeniem,
liczby użytkowników objętych pilotażowym wdrożeniem,
zakresu funkcjonalnego (obszary, moduły) objętego pilotażowym wdrożeniem,
zakresu prac (np. szkolenia, testy, migracja, itp.) obejmującego pilotażowe. Zamawiający
udzielił następującej odpowiedzi: „Pilotażowe wdrożenie systemu ma na celu przetestowanie
w Urzędzie Miasta i w wybranych, reprezentatywnych jednostkach miejskich. Wdrożenie
pilotażowe winno objąć wszystkie funkcjonalności wdrażanego systemu i przewidziane
migracje i integracje. Liczba i nazwy jednostek oraz liczba użytkowników zostaną określone

przez Wykonawcę w uzgodnieniu z Zamawiającym w ramach realizacji Etapu II Analiza i
Projekt Techniczny Systemu w dokumencie „Plan wdrożenia”.
W ocenie Odwołującego treść odpowiedzi Zamawiającego jest niedopuszczalna,
ponieważ uniemożliwia Wykonawcy ocenę stopnia złożoności projektu, a tym samym nie
pozwala na przygotowanie miarodajnej wyceny oferty. Odwołujący zwraca uwagę, że liczba i
typ podmiotów objętych „pilotażem” ma bezpośredni wpływ na ocenę stopnia złożoności
projektu, ocenę możliwości jego realizacji (w kontekście czasu jaki Zamawiający założył na
pilotaż – 7 miesięcy), a także determinuje koszty i cenę oferty. Nie budzi żadnych
wątpliwości, że inna złożoność prac wdrożeniowych będzie wiązała się z pilotażem kilku
jednostek, a zupełnie inna z prowadzeniem pilotażu w kilkunastu czy kilkudziesięciu
jednostkach, Istotna też będzie specyfika działalności tychże podmiotów, bo wdrożenie w
jednostce typu szkoła będzie wiązało się z innym zakresem prac niż w jednostce typu zakład
komunalny.

Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ przez jednoznaczne
wskazanie jednostek objętych pilotażowym wdrożeniem, z podaniem lokalizacji (adresów) i
nazw podmiotów objętych pilotażem.

1.9. Niejednoznaczne określenie wymagań dla zgodności z aktami prawnymi, na które
powołuje się w dokumentacji przetargowej Zamawiający
Zgodnie z treścią SIWZ system ma być zgodny z szeregiem aktów prawnych, W
większości przypadków Zamawiający wymienił akty prawne, które rzeczywiście
merytorycznie dotyczą zakresu przedmiotu zamówienia. W niektórych przypadkach jednak
wymaganie zgodności z przepisami określonej ustawy jest dla Odwołującego niejasne,
ponieważ niektóre wymienione przez Zamawiającego ustawy nie regulują wymagań dla
elementów przedmiotu zamówienia. Dlatego też Odwołujący zadał Zamawiającemu szereg
pytań z prośbą o sprecyzowanie, z jakimi konkretnie przepisami takich właśnie aktów
prawnych ma być zgodny przedmiot zamówienia.

1.9.1. Ustawa o prawie autorskim i prawach pokrewnych
WN-2 Ustawa o prawie autorskim i prawach pokrewnych z dnia 4 lutego 1994 roku (tekst
jednolity: Dz.U. 2006 nr 90 poz. 631).
Na pytanie Odwołującego (Pytanie nr 58): „Prosimy o wskazanie wymagań
funkcjonalnych, których dotyczy ustawa o prawie autorskim. informacja ta jest konieczna,
aby można było ustalić w jakim zakresie funkcjonalnym system ma być zgodny z przywołaną
ustawą?”

Zamawiający udzielił następującej odpowiedzi: „Wymaganie to nie jest wymaganiem
funkcjonalnym – wdrożony system musi spełniać wymogi określone w przywołanej ustawie w
brzmieniu obowiązującym na dzień wdrożenia systemu”.

1.9.2. Prawo geodezyjne i kartograficzne
WN-14 Ustawa z dnia 17 maja 1989 r. Prawo geodezyjne i kartograficzne (tekst
jednolity: Dz.U. 2016poz. 1629).
Na pytanie Odwołującego (Pytanie nr 60]: „Cytowana w wymaganiu ustawa reguluje:
„sprawy: 1) krajowego systemu informacji o terenie; 2) organizacji i zadań Służby
Geodezyjnej i Kartograficznej; 3) wykonywania prac geodezyjnych i kartograficznych; 4)
ewidencji gruntów i budynków; 5} zintegrowanego systemu informacji o nieruchomościach; 6)
gleboznawczej klasyfikacji gruntów; 7) rozgraniczania nieruchomości; 8) geodezyjnej
ewidencji sieci uzbrojenia terenu oraz koordynacji sytuowania tych sieci; 9) państwowego
zasobu geodezyjnego i kartograficznego; 10) uprawnień zawodowych w dziedzinie geodezji i
kartografii; 11) ewidencji miejscowości, ulic i adresów”.

Prosimy zatem o:
wyjaśnienie, które z tych regulacji według Zamawiającego, dotyczą funkcjonalności
systemu, który jest przedmiotem zamówienia (Zintegrowany System informatyczny klasy
ERP wspomagający procesy biznesowe w Urzędzie Miasta Katowice i jednostkach
organizacyjnych Miasta Katowice) opisanej przez wymagania funkcjonalne?
wymienienie tych regulacji i wskazanie wymagań funkcjonalnych, których zdaniem
Zamawiającego dotyczą przepisy ustawy
Zamawiający udzielił następującej odpowiedzi: „Wymaganie to nie jest wymaganiem
funkcjonalnym – wdrożony system musi spełniać wymogi określone w przywołanej ustawie w
brzmieniu obowiązującym na dzień wdrożenia systemu”.

1.9.3. Prawo o ruchu drogowym
WN-17 Ustawa z dnia 20 czerwca 1997 r. Prawo o ruchu drogowym (tekst jednolity:
Dz.U. poz. 1137).
Na pytanie Odwołującego (Pytanie nr 61): Cytowana w wymaganiu ustawa określa:
1) zasady ruchu na drogach publicznych, w strefach zamieszkania oraz w strefach
ruchu;
2) zasady i warunki dopuszczenia pojazdów do tego ruchu, a także działalność
właściwych organów i podmiotów w tym zakresie; 3) wymagania w stosunku do innych
uczestników ruchu niż kierujący pojazdami; 4) zasady i warunki kontroli ruchu drogowego/
Prosimy zatem o:

wyjaśnienie, które z tych regulacji według Zamawiającego, dotyczą funkcjonalności
systemu, który jest przedmiotem zamówienia (Zintegrowany System informatyczny klasy
ERP wspomagający procesy biznesowe w Urzędzie Miasta Katowice i jednostkach
organizacyjnych Miasta Katowice) opisanej przez wymagania funkcjonalne?
wymienienie tych regulacji i wskazanie wymagań funkcjonalnych, których zdaniem
Zamawiającego dotyczą przepisy ustawy.
Zamawiający udzielił następującej odpowiedzi: „Wymaganie to nie jest wymaganiem
funkcjonalnym – wdrożony system musi spełniać wymogi określone w przywołanej ustawie w
brzmieniu obowiązującym na dzień wdrożenia systemu/'
1.9 4. Ustawa o samorządzie gminnym
WN-19 Ustawa z dnia 8 marca 1990 r. o samorządzie gminnym (Dz.U. 2016 poz. 446 z
późn. zm.).
Na pytanie Odwołującego (Pytanie nr 62): „Cytowana w wymaganiu ustawa określa
przepisy dotyczące zakresu działania i zadania gminy, władz gminy, aktów prawa
miejscowego stanowionego przez gminę, mienia komunalnego, gminnej gospodarki
finansowej, związków i porozumień międzygminnych, stowarzyszeń gmin, nadzoru nad
działalnością gminną. W tym zakresie regulują jedynie formę i organizację pracy gminy i nie
dotyczy funkcjonalności systemu ERP
Prosimy zatem o:
wyjaśnienie, które z tych regulacji według Zamawiającego, dotyczą funkcjonalności
systemu, który jest przedmiotem zamówienia (Zintegrowany System informatyczny klasy
ERP wspomagający procesy biznesowe w Urzędzie Miasta Katowice i jednostkach
organizacyjnych Miasta Katowice) opisanej przez wymagania funkcjonalne?
wymienienie tych regulacji i wskazanie wymagań funkcjonalnych, których zdaniem
Zamawiającego dotyczą przepisy ustawy.
Zamawiający udzielił następującej odpowiedzi; „Wymaganie to nie jest wymaganiem
funkcjonalnym – wdrożony system musi spełniać wymogi określone w przywołanej ustawie w
brzmieniu obowiązującym nadzień wdrożenia systemu”.

1.9.5. Ustawa o samorządzie powiatowym
WN-20 Ustawa z dnia 5 czerwca 1998 r. o samorządzie powiatowym (tekst jednolity:
Dz.U. poz. 595).
Na pytanie Odwołującego (Pytanie nr 63]: „Cytowana w wymaganiu ustawa określa
przepisy dotyczące zakresu działania i zadań powiatu, władz powiatu, aktów prawa
miejscowego stanowione przez powiat, mienia powiatu, finansów powiatu, związków
powiatów i związków powiatowo-gminne oraz stowarzyszeń i porozumienia powiatów,
nadzoru nad działalnością powiatu, miast na prawach powiatu (jakim miastom przysługują

takie prawa, jakie są funkcje organów powiatu w miastach na prawach powiatu). W tym
zakresie regulują jedynie formę i organizację pracy powiatu (a nie gminy) i nie dotyczy
funkcjonalności systemu ERP.
Prosimy zatem o:
wyjaśnienie, które z tych regulacji według Zamawiającego, dotyczą funkcjonalności
systemu, który jest przedmiotem zamówienia (Zintegrowany System informatyczny klasy
ERP wspomagający procesy biznesowe w Urzędzie Miasta Katowice l jednostkach
organizacyjnych Miasta Katowice) opisanej przez wymagania funkcjonalne?
wymienienie tych regulacji i wskazanie wymagań funkcjonalnych, których zdaniem
Zamawiającego dotyczą przepisy ustawy „
Zamawiający udzielił następującej odpowiedzi: „Wymaganie to nie jest wymaganiem
funkcjonalnym – wdrożony system musi spełniać wymogi określone w przywołanej ustawie w
brzmieniu obowiązującym na dzień wdrożenia systemu”.

1.9.6. Ustawa o udostępnianiu informacji o środowisku i jego ochronie, udziale
społeczeństwa w ochronie środowiska oraz o ocenach oddziaływania na środowisko
WN-25 Ustawa z dnia 3 października 2008 r, o udostępnianiu informacji o środowisku i
jego ochronie, udziale społeczeństwa w ochronie środowiska oraz o ocenach oddziaływania
na środowisko (tekst jednolity: Dz.U. 2013 poz. 1235).

Na pytanie Odwołującego (Pytanie nr 64): „Cytowana w wymaganiu ustawa określa; „1)
zasady i tryb postępowania w sprawach: a) udostępniania informacji o środowisku i jego
ochronie, b) ocen oddziaływania na środowisko, c) transgranicznego oddziaływania na
środowisko; 2) zasady udziału społeczeństwa w ochronie środowiska; 3) władze publiczne
właściwe w sprawach, o których mowa w pkt 1 lit. a; 4) organy administracji właściwe w
sprawach, o których mowa w pkt 1 lit b i a” W szczególności przepisy ustawy i nie dotyczy
funkcjonalności systemu ERP.
Prosimy zatem o:
wyjaśnienie, które z tych regulacji według Zamawiającego, dotyczą funkcjonalności
systemu, który jest przedmiotem zamówienia (Zintegrowany System informatyczny klasy
ERP wspomagający procesy biznesowe w Urzędzie Miasta Katowice i jednostkach
organizacyjnych Miasta Katowice) opisanej przez wymagania funkcjonalne?
wymienienie tych regulacji i wskazanie wymagań funkcjonalnych, których zdaniem
Zamawiającego dotyczą przepisy ustawy
Zamawiający udzielił następującej odpowiedzi: „Wymaganie to nie jest wymaganiem
funkcjonalnym – wdrożony system musi spełniać wymogi określone w przywołanej ustawie w
brzmieniu obowiązującym n a dzień wdrożeń ia system w”.

1.9.7. Rozporządzenie w sprawie sposobu, zakresu i trybu udostępniania danych
zgromadzonych w rejestrze publicznym
WN-33 Rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu,
zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym (Dz.U. 2005 nr
205 poz. 1692).
Na pytanie Odwołującego (Pytanie nr 65): Cytowane w wymaganiu rozporządzenie
określa sposób postępowania oraz wzór wniosku dotyczącego udostępnienia danych
zgromadzonych w rejestrze publicznym. Dotyczy więc postępowania urzędników i może
mieć wpływ na obowiązujące procedury. Nie dotyczy natomiast funkcjonalności systemu
ERP.
Prosimy zatem o:
wyjaśnienie, które z tych regulacji według Zamawiającego, dotyczą funkcjonalności
systemu, który jest przedmiotem zamówienia (Zintegrowany System informatyczny klasy
ERP wspomagający procesy biznesowe w Urzędzie Miasta Katowice i jednostkach
organizacyjnych Miasta Katowice) opisanej przez wymagania funkcjonalne?
wymienienie tych regulacji i wskazanie wymagań funkcjonalnych, których zdaniem
Zamawiającego dotyczą przepisy rozporządzenia”.
Zamawiający udzielił następującej odpowiedzi: „Wymaganie to nie jest wymaganiem
funkcjonalnym – wdrożony system musi spełniać wymogi określone w przywołanej regulacji
w brzmieniu obowiązującym na dzień wdrożenia systemu”.

1.9.8. Rozporządzenie Ministra Nauki I Informatyzacji z dnia 19 października 2005 r. w
sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji
tego badania
WN-34 Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005 r. w
sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji
tego badania (Dz.U. 2005 nr 217 poz. 1836).
Na pytanie Odwołującego (Pytanie nr 66): „Cytowane w wymaganiu rozporządzenie
dotyczy testów akceptacyjnych oraz badania oprogramowania interfejsowego. Przy czym
„badaniu podlega wyłącznie oprogramowanie interfejsowe, służące do łączenia i
wymiany informacji z takimi systemami teleinformatycznymi używanymi do realizacji zadań
publicznych, z którymi podmioty niebędące podmiotami publicznymi wymieniają dane drogą
elektroniczną”.
Prosimy zatem o wskazanie jakie oprogramowanie interfejsowe będące przedmiotem
zamówienia, według Zamawiającego, służy do łączenia i wymiany informacji z takimi

systemami teleinformatycznymi używanymi do realizacji zadań publicznych, z którymi
podmioty niebędące podmiotami publicznymi wymieniają dane drogą elektroniczną.
Zamawiający udzielił następującej odpowiedzi: „Wymaganie to nie jest wymaganiem
funkcjonalnym – wdrożony system musi spełniać wymogi określone w przywołanej regulacji
w brzmieniu obowiązującym na dzień wdrożenia systemu”.

1.9.9. Rozporządzenie Ministra Pracy i Polityki Społecznej z dnia 2 listopada 2007 r. w
sprawie systemów teleinformatycznych stosowanych w jednostkach organizacyjnych pomocy
społecznej
WN-35 Rozporządzenie Ministra Pracy i Polityki Społecznej z dnia 2 listopada 2007 r. w
sprawie systemów teleinformatycznych stosowanych w jednostkach organizacyjnych pomocy
społecznej (Dz.U. 2007 nr 216 poz. 1609),
Na pytanie Odwołującego (Pytanie nr 67): „Prosimy o wskazanie wymagań
funkcjonalnych opisanych w SIWZ, do których stosują się zdaniem Zamawiającego przepisy
rozporządzenia, o którym mowa w wymaganiu”.
Zamawiający udzielił następującej odpowiedzi: „Wymaganie to nie jest wymaganiem
funkcjonalnym – wdrożony system musi spełniać wymogi określone w przywołanej regulacji
w brzmieniu obowiązującym na dzień wdrożenia systemu”.

1.9.10. Ustawa o ochronie baz danych
WN-38 Ustawa z dnia 27 lipca 2001 r. o ochronie baz danych (Dz.U. 2001 nr 128 poz.
1402 z późn.zm.),
Na pytanie Odwołującego (Pytanie nr 69): „Cytowana ustawa dotyczy ochrony baz
danych niezależnej od ochrony przyznanej na podstawie ustawy z dnia 4 lutego 1994 r. o
prawie autorskim i prawach pokrewnych (Dz. U. z 2006 r. Nr 90, poz. 631, Nr 94, poz. 658,
Nr 121, poz. 843 oraz z 2007 r, Nr 99, poz. 662) bazom danych spełniającym cechy utworu,
Nie dotyczy żadnych wymagań systemu ERP będącego przedmiotem zamówienia. Prosimy
w związku z tym o wskazanie wymagań funkcjonalnych opisanych w SIWZ, do których
stosują się zdaniem Zamawiającego przepisy rozporządzenia, o którym mowa w
wymaganiu”.
Zamawiający udzielił następującej odpowiedzi: „Wymaganie to nie jest wymaganiem
funkcjonalnym – wdrożony system musi spełniać wymogi określone w przywołanej ustawie w
brzmieniu obowiązującym na dzień wdrożenia systemu”.

1.9.11. Prawo o ochronie środowiska
WN-48 Ustawa z dnia 27 kwietnia 2001 r. Prawo o ochronie środowiska (tekst jednolity
Dz. U. z 2014 r. poz. 672 z późn. zm.).

Na pytanie Odwołującego (Pytanie nr 70): „Cytowana w wymaganiu „Ustawa określa
zasady ochrony środowiska oraz warunki korzystania z jego zasobów, z uwzględnieniem
wymagań zrównoważonego rozwoju, a w szczególności: 1) zasady ustalania: a) warunków
ochrony zasobów środowiska, b) warunków wprowadzania substancji łub energii do
środowiska, c) kosztów korzystania ze środowiska; 4) obowiązki organów administracji; 5)
odpowiedzialność i sankcje. Nie dotyczy natomiast funkcjonalności systemu ERP.
Prosimy zatem o:
wyjaśnienie, które z tych regulacji według Zamawiającego, dotyczą funkcjonalności
systemu, który jest przedmiotem zamówienia (Zintegrowany System informatyczny klasy
ERP wspomagający procesy biznesowe w Urzędzie Miasta Katowice i jednostkach
organizacyjnych Miasta Katowice) opisanej przez wymagania funkcjonalne?
wymienienie tych regulacji i wskazanie wymagań funkcjonalnych, których zdaniem
Zamawiającego dotyczą przepisy ustawy.
Zamawiający udzielił następującej odpowiedzi: „Wymaganie to nie jest wymaganiem
funkcjonalnym – wdrożony system musi spełniać wymogi określone w przywołanej ustawie w
brzmieniu obowiązującym na dzień wdrożenia systemu.

1.9.12. Prawo geologiczne i górnicze
WN-52 Ustawa z dnia 9 czerwca 2011 r. Prawo geologiczne i górnicze (Dz.U. z 2016 r.
poz. 1331 z późn. zm.).
Na pytanie Odwołującego [Pytanie nr 71); „Cytowana w wymaganiu „ustawa określa
zasady i warunki podejmowania, wykonywania oraz zakończenia działalności w zakresie: 1)
prac geologicznych; 2) wydobywania kopalin ze złóż; 3) podziemnego bezzbiornikowego
magazynowania substancji; 4) podziemnego składowania odpadów; 5) podziemnego
składowania dwutlenku węgła w celu przeprowadzenia projektu demonstracyjnego wychwytu
i składowania dwutlenku węgła, 2, Ustawa określa także: 1) wymagania w zakresie ochrony
złóż kopalin, wód podziemnych oraz innych elementów środowiska w związku z
wykonywaniem działalności, o której mowa w ust. 1; 2) zasady wykonywania nadzoru i
kontroli nad działalnością regulowaną ustawą” Nie dotyczy natomiast funkcjonalności
systemu ERP.
Prosimy zatem o:
wyjaśnienie, które z tych regulacji według Zamawiającego, dotyczą funkcjonalności
systemu, który jest przedmiotem zamówienia (Zintegrowany System informatyczny klasy
ERP wspomagający procesy biznesowe w Urzędzie Miasta Katowice i jednostkach
organizacyjnych Miasta Katowice) opisanej przez wymagania funkcjonalne?
wymienienie tych regulacji i wskazanie wymagań funkcjonalnych, których zdaniem
Zamawiającego dotyczą przepisy ustawy.

Zamawiający udzielił następującej odpowiedzi: „Wymaganie to nie jest wymaganiem
funkcjonalnym – wdrożony system musi spełniać wymogi określone w przywołanej ustawie w
brzmieniu obowiązującym na dzień wdrożenia systemu.
Odwołujący podkreśla, iż w związku z powoływaniem się Zamawiającego na akty
prawne, które w ocenie Odwołującego nie korespondują w jednoznaczny sposób z zakresem
zamówienia – Odwołujący zwrócił się w pytaniach nr 58, nr 60-67 oraz nr 69- 71, o
wskazanie które z przedmiotowych regulacji według Zamawiającego, dotyczą
funkcjonalności systemu, który jest przedmiotem zamówienia [Zintegrowany System
informatyczny klasy ERP wspomagający procesy biznesowe w Urzędzie Miasta Katowice
jednostkach organizacyjnych Miasta Katowice) opisanej przez wymagania funkcjonalne.
Odwołujący poprosił również o wymienienie tych regulacji i wskazanie wymagań
funkcjonalnych, których zdaniem Zamawiającego dotyczą przywołane w SIWZ przepisy.

Zamawiający na każde z Pytań nr 58, 60-67 oraz nr 69-71 udzielił odpowiedzi, których
nie można uznać za akceptowalne. Odwołujący zarzuca, że tak ogólnie sformułowane
odpowiedzi Zamawiającego („wdrożony system musi spełniać wymogi określone w
przywołanej ustawie w brzmieniu obowiązującym na dzień wdrożenia systemu) dają
Zamawiającemu podstawę do wymagania od Wykonawcy realizacji znacznie szerszego
zakresu funkcjonalnego niż przedstawia to enumeratywna lista funkcjonalności z Załącznika
nr 3 do SIWZ (OPZ). W efekcie Zamawiający otrzymuje narzędzie do dowolnego
interpretowania zakresu zamówienia, a Wykonawca nie ma możliwości dokonania na etapie
składania ofert oceny, jakie funkcjonalności składają się na zamówienie. To, że jak pisze w
odpowiedzi Zamawiający, przedmiotowe wymagania nie są ujęte w wymaganiach
funkcjonalnych Załącznika nr 3 do SIWZ nie oznacza, że nie determinują one zakresu
funkcjonalnego. Tym bardziej, że treść Załącznika nr 3 do SIWZ rozdział 3.6 potwierdza, że
Zamawiający rozumie wymagania niefunkcjonalne jako mające bezpośredni związek z
funkcjonalnością oferowanego Systemu. W załączniku Zamawiający wpisał: „Wymagania dla
obszarów niefunkcjonalnych zostały zidentyfikowane w trakcie wywiadów przeprowadzonych
z kluczowymi użytkownikami Urzędu Miejskiego w Katowicach. Każdemu obszarowi
przypisane zostały funkcjonalności które zostały poddane ocenie przez Zamawiającego”.

Wykonawca składający ofertę zobowiązany jest do wypełnienia wymagań w następujący
sposób:
W przypadku, gdy oferowany System spełnia daną funkcjonalność należy, w kolumnie
Wykonawca wpisać 1.
Jeżeli dana funkcjonalność nie jest możliwa do zrealizowania w proponowanym
systemie, należy wpisać 0. Każde inne wpisanie będzie traktowany jak wartość 0.

Z powyższych postanowień oraz praktyki realizacji wymagań niefunkcjonalnych wynika,
że przedmiotowe regulacje prawne mogą istotnie wpływać na generowanie dodatkowych
kosztów po stronie Wykonawcy w sytuacji, gdy Zamawiający uzna, że oczekuje realizacji
dodatkowych funkcjonalności, które co prawda choć nie mają odzwierciedlenia w
wymaganiach funkcjonalnych Załącznika nr 3 do SIWZ (OPZ), to można ich realizacji
oczekiwać, powołując się na wspomniane akty prawne. Brzmienie odpowiedzi
Zamawiającego wprowadza też element nieporównywalności ofert, ponieważ każdy z
wykonawców może dowolnie oceniać, jakie elementy z przywołanych regulacji prawnych
mają być objęte wdrożeniem.

Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ przez wskazanie które z
przedmiotowych regulacji według Zamawiającego, dotyczą funkcjonalności systemu, który
jest przedmiotem zamówienia (Zintegrowany System informatyczny klasy ERP
wspomagający procesy biznesowe w Urzędzie Miasta Katowice i jednostkach
organizacyjnych Miasta Katowice) opisanej przez wymagania funkcjonalne oraz o
wymienienie tych regulacji I wskazanie wymagań funkcjonalnych, których zdaniem
Tabela 10. Objaśnienie wartości przypisanych poszczególnym wymaganiom
Opis
1 Funkcjonalności, którym w kolumnie ”Priorytet” przypisano wartość l/są v ;
wymaganiami kluczowymi dla Zamawiającego, ich spełnienie stanowi jedno
podstawowych kryteriów oceny proponowanego rozwiązania :
2 Funkcjonalność}, którym w kolumnie „Priorytet” przypisano wartość 2, zostały
określone jako ważne lub mogące okazać się przydatne w przyszłości. Po2lom
spełnienia tych funkcjonalności będ2le stanowi! dodatkowe kryterium oceny
rozwiązania
Tabela 11. Przykład wypełnienia tabeli PASS przez Oferenta
Znaczenie Wykonawca
System spełnia daną funkcjonalność . „
Brak możliwości realizacji funkcjonalności w Systemie 0

Zamawiającego dotyczą przywołane w SIWZ przepisy. Odwołujący wniósł również o
nakazanie Zamawiającemu modyfikacji SIWZ przez jednoznaczne wskazanie, że
zamieszczona w SIWZ lista aktów prawnych ma jedynie zastosowanie do funkcjonalności
systemu wynikających z wymagań funkcjonalnych zamieszczonych w specyfikacji.

2. Zarzut naruszenia art. 7 ust. 1 Pzp oraz art, 90 ust. 1 Pzp przez wymaganie
przedstawienia opisu zmian dostosowujących lub modyfikacji systemu oraz szacunkowej
przewidywanej pracochłonności (roboczogodzin)
Zgodnie z treścią SIWZ:
Formularz opisu funkcjonalności oferowanego Systemu
W poniższych tabelach w przypadku; gdy oferowany System spełnia daną
funkcjonalność w standardzie należy, w kolumnie „STD, wpisać 1. jeżeli dana funkcjonalność
nie jest możliwa do zrealizowania w proponowanym systemie, należy wpisać 0. Każde inne
wpisanie będzie traktowane jak wartość 0, jeżeli dana funkcjonalność zostanie dostarczona
w wyniku modyfikacji systemu, w kolumnie „MDF” należy wpisać 1 natomiast w kolumnie
„STD” wstawić wartość 0. Umieszczenie wpisu 1 w kolumnie „MDF” jest równoznaczne z
zapewnieniem Zamawiającemu modyfikacji systemu o daną funkcjonalność w ramach oferty.
W przypadku, gdy Wykonawca umieścił, w którymś z wierszy kolumny „MDF” wpis 1,
wypełnienia kolumnę Uwagi krótkim opisem zmian dostosowujących lub modyfikacji systemu
oraz szacunkowej przewidywanej pracochłonności (roboczogodzin)
Na pytanie Odwołującego (Pytanie nr 9): „W naszej ocenie, przedstawienie [na etapie
składania ofert) opisu (nawet krótkiego) zmian dostosowujących lub modyfikacji systemu do
wymagań, które Wykonawca zamierza zrealizować w toku prac wdrożeniowych – jest
nieuzasadnione. Decyzja o sposobie dostosowania/modyfikacji systemu będzie
podejmowana i weryfikowana na etapie Analizy Przed wdrożeniowej. Również w naszej
ocenie przedstawienie w ofercie szacunkowej (przewidywanej) pracochłonności w
roboczogodzinach dla planowanych zmian/modyfikacji systemu jest niezasadne. Dane te nie
przedstawiają dla Zamawiającego żadnej wartości, ponieważ Wykonawca jest zobowiązany
do realizacji przedmiotu zamówienia w zakreślonym umową terminie i budżecie, bez względu
na to jakie nakłady wewnętrznie będzie ponosił na realizację projektu. Prosimy zatem o
wykreślenie przywołanych postanowień z Załącznika nr 3 do Oferty i Załącznika nr 3 do
SIWZ, oraz usunięcie kolumny „Uwagi” z przedmiotowych zestawień tabelarycznych.*
Zamawiający udzielił następującej odpowiedzi: „Zamawiający nie dokonuje zmiany SIWZ
w tym zakresie”
Należy zauważyć, że decyzja o sposobie dostosowania/modyfikacji systemu będzie
podejmowana i weryfikowana na etapie Analiza i Projekt Techniczny Systemu (na który
Zamawiający założył czas 10 miesięcy}, który to etap zgodnie z SIWZ będzie miał na celu

„przygotowanie specyfikacji analitycznej Systemu i projektu technicznego Przygotowanie
przedmiotowych opisów na etapie oferty (zwłaszcza, że jak podkreśla to Zamawiający w
SIWZ część zagadnień będzie doprecyzowana/uzgadniana na etapie Analizy
Przedwdrożeniowej) byłoby de facto realizowaniem części prac wdrożeniowych (które są
domeną etapu Analiza Przedwdrożeniowa) na etapie postępowania ofertowego. Co więcej,
przedstawienie tychże opisów w ofercie może być zagadnieniem spornym na etapie Analiza i
Projekt Techniczny Systemu w sytuacji, gdy Wykonawca [mający nieporównywalnie większą
wiedzę na etapie Analizy Przedwdrożeniowej niż na etapie ofertowania] podejmie decyzję o
innej, niż przedstawił to w opisie oferty, koncepcji modyfikacji systemu do wymagań, które
Wykonawca zamierza zrealizować w toku prac wdrożeniowych.
Przedstawienie w ofercie szacunkowej (przewidywanej) pracochłonności w
roboczogodzinach dla planowanych zmian/modyfikacji systemu również w ocenie
Odwołującego jest niezasadne. Dane te nie przedstawiają dla Zamawiającego żadnej
wartości, ponieważ Wykonawca jest zobowiązany do realizacji przedmiotu zamówienia w
zakreślonym umową terminie i budżecie, bez względu na to, jakie nakłady wewnętrznie
będzie ponosił na realizację projektu. Odwołujący zwraca uwagę, że kalkulacja
pracochłonności w formacie wskazanym przez Zamawiającego (liczba roboczogodzin per
wymaganie funkcjonalne) nie jest możliwa w przypadku zastosowania np. wyceny w oparciu
o metodę punktów funkcyjnych, ponieważ wycena ta opiera się na obszarach
funkcjonalnych, a nie na konkretnych funkcjonalnościach z danego obszaru.
Odwołujący zarzuca zatem, że wymaganie od wykonawców na etapie oferty
przedmiotowych opisów i kalkulacji modyfikacji jest niezasadne, zwłaszcza że ani
przedmiotowe opisy, ani przedmiotowe kalkulacje pracochłonności nie są oceniane przez
Zamawiającego, a cel ich przedstawienia w ofercie nie jest dla Odwołującego zrozumiały, a
prowadzi de facto do naruszenia zasad prowadzenia postępowania z zachowaniem uczciwej
konkurencji i równego traktowania wykonawców, ponieważ różni wykonawcy będą
zobowiązani do stworzenia różnego rodzaju ofert – w zależności od tego, co oferowane
przez nich systemy mają w standardzie. Należy podkreślić, że wymaganie dotyczące
przedstawienia pracochłonności może być uzasadnione w przypadku wyjaśnień treści oferty
w zakresie rażąco niskiej ceny – w praktyce Zamawiający już na etapie składania ofert
wymaga od wykonawców, którzy nie mają określonych funkcjonalności w standardzie,
złożenia wyjaśnień mających uzasadnić realność zaoferowanej przez nich ceny, co jest
obejściem przepisu art. 90 ust. 1 Pzp i narusza przepis art. 7 ust. 1 Pzp.

Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ przez wykreślenie
postanowienia „W przypadku, gdy Wykonawca umieścił w którymś z wierszy kolumny „MDF”
postanowienie 1 „wypełnienia kolumnę Uwagi krótkim opisem zmian dostosowujących lub

modyfikacji systemu oraz szacunkowej przewidywanej pracochłonności (roboczogodzin)” z
Załącznika nr 3 do Oferty i Załącznika nr 3 do SIWZ, oraz usunięcie kolumny „Uwagi” z
przedmiotowych zestawień tabelarycznych.

3. Zarzut naruszenia art. 7 ust. 1 Pzp w zw. z art 87 ust. 1 Pzp w zw. z § 13 ust. 1 pkt 1
Rozporządzenia Ministra Rozwoju z dnia 26 lipca 2016 r. w sprawie rodzajów dokumentów,
jakich może żądać zamawiający od wykonawcy w postępowaniu o udzielenie zamówienia
(Dz. U. z 2016 r. poz. 1126)
Zgodnie z treścią punktu 57 w Części X SIWZ – Dokumenty wymagane od wykonawcy,
którego oferta została najwyżej oceniona: W celu potwierdzenia, że oferowane dostawy lub
usługi odpowiadają wymaganiom określonym przez zamawiającego, zamawiający wymaga
załączenia do oferty: a) programów komputerowych, których autentyczność musi zostać
poświadczona przez wykonawcę na żądanie zamawiającego – tj. Wykonawca, którego oferta
została najwyżej oceniona zobowiązany będzie do zaprezentowania na wezwanie
Zamawiającego w siedzibie Zmawiającego funkcjonalności oznaczonych w formularzu
ofertowym jako „w standardzie” (STD).
Odwołujący sformułował następujące pytanie, dotyczące powołanych zasad (Pytanie nr
45]: „Prosimy o wykreślenie przedmiotowego wymagania z SIWZ, Jeśli Zamawiający
zamierza utrzymać przywołane wymaganie prosimy o:
Wyjaśnienie sprzeczności „formalnej”. Z treści pkt 57 wynika, że Zamawiający żąda
dołączenia do oferty „programów komputerowych”, a z drugiej strony Zamawiający umieścił
to wymaganie w sekcji „dokumentów” wymaganych od Wykonawcy, którego oferta została
najwyżej oceniona [„Części X – Dokumenty wymagane od wykonawcy, którego oferta
została najwyżej oceniona, a więc de facto można uznać, że „programy komputerowe”
powinny być dostarczone w odpowiedzi na zgłoszone żądanie Zamawiającego [więc już po
terminie otwarcia ofert – a zatem na jakim etapie postępowania przetargowego Wykonawca
winien przekazać przedmiotowe „programy komputerowe”,
Wyjaśnienie w jakiej formie ma być przygotowana „próbka”, w oparciu o którą będzie
odbywać się prezentacja „programów komputerowych” – czy chodzi o notebook?
Wyjaśnienie czy jeśli Zamawiający będzie wymagał dołączenia „próbki” w formie
notebook'a jako załącznika do oferty – to Zamawiający po dokonaniu wyboru Wykonawcy
dokona zwrotu próbek/notebooków oferentom uczestniczącym w postępowaniu
przetargowym?
Ograniczenie zakresu prezentowanych funkcjonalności do konkretnej, enumeratywnej
listy funkcjonalności oznaczonych przez Wykonawcę, jako spełnianych „w standardzie”
(STD).

Treść pkt 57 przedstawia zbyt szeroki katalog wymagań aniżeli praktykowany w
zamówieniach publicznych zakres „próbki”/demo, ponieważ Zamawiający zastrzega
możliwość weryfikacji wszystkich wymagań oznaczonych w formularzu ofertowym jako „w
standardzie” (STD) – a powinien żądać co najwyżej „próbki”, która z samej definicji winna
stanowić jedynie niewielką część całego rozwiązania. Zatem Zamawiający nie może żądać
testu/weryfikacji całego rozwiązania [w którym liczba wymagań funkcjonalnych wynosi ok.
700]. Posiadanie określonych wymagań „w standardzie” oferowanego systemu ERP nie
oznacza, że z przedmiotowymi wymaganiami nie wiążą się żadne nakłady pracy.
Zbudowanie i dostarczenie kompletnego rozwiązania (w tym instalacja i konfiguracja
wymagań „standardowych”) obejmującego wszystkie moduły jest przecież elementem
procesu wdrożeniowego, w szczególności parametryzacji Systemu pod oczekiwania Klienta
wynikające z SIWZ – a przedmiotowe prace będą prowadzone dopiero na etapie
implementacji Systemu (w horyzoncie czasowym zakreślonym przez Zamawiającego na 36
miesięcy).
Uregulowanie w sposób formalny zagadnień odnoszących się do wspomnianej
„prezentacji”, przez przedstawienie:
Regulaminu prezentacji,
Scenariusza prezentacji [enumeratywnego wykazu funkcjonalności objętych
prezentacją],
Warunków/Kryteriów oceny prezentacji, w szczególności określenie zasad dotyczących
kryteriów prezentacji (jakie parametry muszą być spełnione, aby Zamawiający uznał
oprogramowanie za spełniające wymagania określone w SIWZ.
Na tak sformułowane pytanie Zamawiający udzielił następującej odpowiedzi:
Ad a) Zamawiający wymaga dostarczenia dokumentów określonych w ust. 57 na
wezwanie Zamawiającego – Zamawiający dokonuje zmiany w SIWZ w tym zakresie.
Ad b) Próbka ma zostać dostarczona w formie maszyny wirtualnej na dysku
zewnętrznym. Wykonawca winien na swoim sprzęcie z wykorzystaniem dostarczonego
dysku zewnętrznego zaprezentować Zamawiającemu (z wykorzystaniem rzutnika i ekranu
Zamawiającego) funkcjonalności systemu, które zaznaczył, jako realizowane w standardzie.
Ad c) Dostarczony dysk z maszyną wirtualną zostanie dołączony do dokumentacji
przetargowej i nie będzie podlegał zwrotowi Wykonawcy.
Ad d) Zamawiający zmienia postanowienie w części X Dokumenty wymagane od
wykonawcy, którego oferta została najwyżej oceniona w ust. 57 lit. a na „próbek, opisów,
fotografii, planów-projektów, rysunków, modeli, wzorów, programów komputerowych oraz
innych podobnych materiałów, których autentyczność musi zostać poświadczona przez
wykonawcę na żądanie zamawiającego – tj. Wykonawca, którego oferta została najwyżej
oceniona zobowiązany będzie do zaprezentowania na wezwanie Zamawiającego w siedzibie

Zamawiającego wybranych przez Zamawiającego funkcjonalności oznaczonych w
formularzu ofertowym jako „w standardzie” (STD) w liczbie max 100”.
Ad e) Scenariusz prezentacji wraz z enumeratywnym wykazem funkcjonalności objętych
prezentacją zostanie przekazany Wykonawcy w zaproszeniu do przeprowadzenia
prezentacji. Zamawiający uzna, że wskazane jako STD funkcjonalności spełniają wymagania
określone w SIWZ, jeśli będą realizowały funkcjonalność opisaną w danym warunku.
W ocenie Odwołującego odpowiedzi udzielonej przez Zamawiającego nie można uznać
za wyczerpującą zagadnienia podniesione przez Odwołującego w kontekście „próbki” i
prezentacji systemu, ponadto wprowadzone przez Zamawiającego zasady prezentacji
funkcjonalności nie umożliwiają porównywalności ofert i prowadzenia postępowania z
zachowaniem zasady uczciwej konkurencji i równego traktowania wykonawców.
Ograniczenie wymagań podlegających ocenie Zamawiającego do liczby „max 100”
wymagań funkcjonalnych oznaczonych jako spełnione w standardzie (STD) nie rozwiązuje
problemu traktowania oferentów w sposób sprawiedliwy i równorzędny, Odwołujący zwraca
uwagę, że Zamawiający użył konstrukcji „max 100”, co w przypadku gdy np. mamy trzech
oferentów, którzy oznaczyli w standardzie (STD) ponad 100 funkcjonalności – dopuszcza
sytuację weryfikacji u wykonawcy 1 np. 100 funkcjonalności, u wykonawcy 2 np. 50
funkcjonalności, a u wykonawcy 3 np. 1 funkcjonalność. Nawet jeśli będziemy brać pod
uwagę tę samą liczbę wymagań dla wszystkich oferentów, to należy podkreślić, że
poszczególne wymagania funkcjonalne często są nieporównywalne w kontekście nakładów
związanych z ich przygotowaniem i zaprezentowaniem, np. zupełnie innego nakładu czasu
wymaga prezentacja prostej operacji zaksięgowania dokumentu, a innego czasu
„zamknięcie” roku obrachunkowego, które może trwać nawet kilka godzin.
Odwołujący zwraca uwagę też na inny możliwy scenariusz. W sytuacji, gdy wykonawca
1 nie oznaczy żadnej funkcjonalności w standardzie (co oczywiście będzie mieć przełożenie
na punktację w kryteriach oceny, ale nie będzie dyskwalifikowało jego oferty) – jego oferta
nie będzie podlegała weryfikacji w zakresie „próbki”. W przypadku więc, gdy pozostali
wykonawcy nie uzyskają od Zamawiającego pozytywnej oceny z weryfikacji swoich „próbek”
Zamawiający będzie zmuszony dokonać wyboru oferty z pominięciem oceny „próbki”. Może
się zatem okazać, że Zamawiający wybierze w ten sposób ofertę z najwyższą ceną i
najmniej korzystnym bilansem pozostałych zaoferowanych parametrów – tylko z tego
powodu, że pozostali wykonawcy zobligowani byli do przeprowadzenia demonstracji
działania systemu na nieznanych sobie warunkach, bez regulaminu prezentacji i bez
scenariuszy oceny funkcjonalności – co spowodowało odrzucenie ich ofert. Doprowadzić to
może do skrajnie niekorzystnego rozporządzenia mieniem Zamawiającego.
Brak szczegółowego Regulaminu Prezentacji, o który wnioskował w pytaniu Odwołujący,
uniemożliwia wykonawcom ocenę możliwości efektywnego zrealizowania przedmiotowej

prezentacji. Praktyką powszechnie stosowaną przez zamawiających wymagających
prezentacji systemów IT w toku prowadzonych postępowań przetargowych jest publikacja
Regulaminu Prezentacji, regulującego wiele kwestii zarówno formalnych [godzina
rozpoczęcia prezentacji, czas prezentacji, procedura na wypadek problemów technicznych,
itp.], jak i merytorycznych [zasady prezentacji, sposób oceniania, scenariusz prezentacji,
itp.]. W ocenie Odwołującego pozostawianie tych aspektów na etap już po terminie składania
ofert – uniemożliwia wykonawcom właściwe przygotowanie się do przedmiotowej prezentacji,
ale również podjęcie decyzji związanych z przygotowaniem oferty, w tym w szczególności w
zakresie oznaczania funkcjonalności dostępnych w standardzie (STD), które potencjalnie
mogą podlegać weryfikacji w ramach „próbki” i które mogą skutkować odrzuceniem oferty w
przypadku braku możliwości ich zaprezentowania.
Powyższe w sposób dobitny wskazuje, że zagadnienia dotyczące „próbki” i jej
prezentacji mogą prowadzić do nierównego traktowania oferentów, dużej dowolności –
subiektywności działań Zamawiającego w kontekście weryfikacji „próbki”, a w skrajnej
sytuacji do wyboru Wykonawcy, który oferując niskiej jakości system (bez jakiejkolwiek
funkcjonalności w standardzie) nie będzie podlegał weryfikacji w zakresie „próbki”.

Odwołujący wniósł o nakazanie Zamawiającemu zmiany SIWZ przez wskazanie, że
Zamawiający dokona wyboru np. 10 wymagań funkcjonalnych ze zbioru tych samych
wymagań zadeklarowanych w standardzie przez wszystkich wykonawców (które będą
Identyczne dla wszystkich) lub przez wskazanie np. 10 wymagań funkcjonalnych, które
muszą być przez wszystkich wykonawców oznaczone w ofercie jako spełnione w
standardzie (STD) – i te funkcjonalności będą prezentowane przez wykonawcę, którego
oferta zostanie uznana przez Zamawiającego za najkorzystniejszą.

Odwołujący wniósł również o uregulowanie w sposób formalny zagadnień odnoszących
się do wspomnianej „prezentacji”, przez przedstawienie:
a) regulaminu prezentacji,
b) scenariusza prezentacji (enumeratywnego wykazu funkcjonalności objętych
prezentacją);
c) warunków/kryteriów oceny prezentacji, w szczególności określenie zasad dotyczących
kryteriów prezentacji (jakie parametry muszą być spełnione, aby Zamawiający uznał
oprogramowanie za spełniające wymagania określone w SIWZ).

Odwołujący przesłał w terminie kopię odwołania zamawiającemu 12.05.2017 r. (art. 180
ust. 5 i art. 182 ust. 1-4 Pzp).

Zamawiający przesłał w terminie 2 dni kopię odwołania innym wykonawcom 15.05.2017
r. (art. 185 ust. 1 in initio Pzp).

17.05.2017 r. wykonawca COIG S.A. z siedzibą w Katowicach, ul. Mikołowska 100,
40-065 Katowice złożył (1) Prezesowi KIO, z kopiami dla (2) zamawiającego i (3)
odwołującego, pismo o zgłoszeniu przystąpienia do postępowania po stronie odwołującego
do postępowania toczącego się w wyniku wniesienia odwołania (art. 185 ust. 2 Pzp).

18.05.2017 r. wykonawca S&T Services Polska Sp. z o.o. z siedzibą w Warszawie, ul.
Postępu 21D, 02-676 Warszawa złożył (1) Prezesowi KIO, z kopiami dla (2) zamawiającego i
(3) odwołującego, pismo o zgłoszeniu przystąpienia do postępowania po stronie
odwołującego do postępowania toczącego się w wyniku wniesienia odwołania (art. 185 ust. 2
Pzp).

18.05.2017 r. wykonawca Sputnik Software Sp. z o.o. z siedzibą w Poznaniu, ul.
Górecka 30, 60-201 Poznań złożył (1) Prezesowi KIO, z kopiami dla (2) zamawiającego i (3)
odwołującego, pismo o zgłoszeniu przystąpienia do postępowania po stronie odwołującego
do postępowania toczącego się w wyniku wniesienia odwołania (art. 185 ust. 2 Pzp).

Zamawiający wniósł odpowiedź na odwołanie do czasu zamknięcia rozprawy 26.05.2017
r. (art. 186 ust. 1 Pzp). Zamawiający stwierdził, że odwołanie podlega oddaleniu i
ustosunkował się merytorycznie do każdego z zarzutów odwołania.

Krajowa Izba Odwoławcza ustaliła, co następuje:
Odwołujący wniósł odwołanie na zaniechanie udzielenia wyjaśnień na zapytania do
SIWZ zgodnie z art. 38 ust. 1 wprowadzenie do wyliczenia Pzp, które brzmi »Wykonawca
może zwrócić się do zamawiającego o wyjaśnienie treści specyfikacji istotnych warunków
zamówienia. Zamawiający jest obowiązany udzielić wyjaśnień niezwłocznie, jednak nie
później niż […]«. Izba stwierdza, że mimo formalnego odniesienia się odwołującego w
odwołaniu do odpowiedzi, która została udzielona przez zamawiającego 2.05.2017 r.,
wszystkie zakwestionowania i wnioskowania odwołującego odnosiły się do specyfikacji
istotnych warunków zamówienia (dalej SIWZ lub specyfikacja), którą zamawiający zamieścił
11.04.2017 r. we właściwym miejscu, na swojej stronie internetowej.
W związku z tym, że zamawiający zamieścił SIWZ na stronie internetowej 11.04.2017 r.
termin na wniesienie odwołania odnośnie postanowień specyfikacji upłynął 21.04.2017 r.
zgodnie z art. 182 ust. 2 pkt 1 Pzp, który brzmi »Odwołanie wobec treści ogłoszenia o
zamówieniu, a jeżeli postępowanie jest prowadzone w trybie przetargu nieograniczonego,

także wobec postanowień specyfikacji istotnych warunków zamówienia, wnosi się w terminie
[…] 10 dni od dnia publikacji ogłoszenia w Dzienniku Urzędowym Unii Europejskiej lub
zamieszczenia specyfikacji istotnych warunków zamówienia na stronie internetowej – jeżeli
wartość zamówienia jest równa lub przekracza kwoty określone w przepisach wydanych na
podstawie art. 11 ust. 8«. Sprawa trybu zamówienia [przetarg nieograniczony] oraz wartości
zamówienia [przekraczającej kwoty określone w przepisach wydanych na podstawie art. 11
ust. 8 Pzp] nie była przedmiotem sporu.
Ponadto Izba stwierdza, że na rozprawie odwołujący ani uczestnik postępowania nie
wykazali, że zarzuty i wnioskowania odwołania odnoszą się rzeczywiście do odpowiedzi na
pytania, a nie do samej SIWZ. W rozpoznawanym odwołaniu relewantne jest także to, że
zamawiający nie dokonał zmian w specyfikacji istotnych warunków zamówienia w zakresie
objętym odwołaniem.
Ze względu na faktyczne nakierowanie odwołania na postanowienia SIWZ, Izba musiała
wziąć pod uwagę fakt, że termin na wniesienie odwołania na postanowienia SIWZ zaczął
biegnąć od momentu opublikowania SIWZ czyli od 11.04.2017 r. i upłynął 21.04.2017 r.
Zgodnie z przepisami ustawy termin ten nie ulega przywróceniu. Z tego powodu Izba musi
odrzucić odwołanie na podstawie art. 189 ust. 2 pkt 3 Pzp, który brzmi »Izba odrzuca
odwołanie, jeżeli stwierdzi, że […] odwołanie zostało wniesione po upływie terminu
określonego w ustawie«.

O kosztach postępowania odwoławczego orzeczono na podstawie art. 192 ust. 9 i 10
Pzp, czyli stosownie do wyniku postępowania.



Przewodniczący: ………………………………