KIO 965/17 POSTANOWIENIE dnia 5 czerwca 2017 r.

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  

COIG S.A. z siedzibą w Katowicach, ul. Mikołowska 100, 40-065 Katowice,  

S&T Services Polska Sp. z o.o. z siedzibą w Warszawie, ul. Postępu 21D, 02-676 

Warszawa, 

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 

ESX 5.5u3 

2xE5-2670v3 

ESX 5,5u3 

2xX5570 

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 

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 

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 : 

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 

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: 

………………………………