KIO 2820/21 WYROK dnia 19 października 2021 roku

Stan prawny na dzień: 22.03.2022

Sygn. akt: KIO 2820/21 

WYROK 

z dnia 19 

października 2021 roku 

Krajowa Izba Odwoławcza   -   w składzie: 

Przewodniczący:      Irmina Pawlik 

 Protokolant:   

Rafał Komoń 

po  rozpoznaniu  na  rozprawie  w  dniu  15 

października  2021  r.  w Warszawie  odwołania 

wniesionego  do  Prezesa  Krajowej  Izby  Odwoławczej  w  dniu  24 września  2021  r.  przez 

wykonawcę  Laboratorium  EE  Spółka  z  ograniczoną  odpowiedzialnością  Spółka 

komandytowa z siedzibą  w  Warszawie  w postępowaniu prowadzonym  przez Główny  Urząd 

Nadzoru Budowlanego z siedzibą w Warszawie 

przy udziale wykonawc

ów: 

A.  Agileme 

Spółka z ograniczoną odpowiedzialnością z siedzibą w Suwałkach; 

B. 

WASKO Spółka Akcyjna z siedzibą w Gliwicach; 

zgłaszających przystąpienie do postępowania odwoławczego po stronie odwołującego 

orzeka: 

umarza postępowanie w zakresie dotyczącym zarzutów wobec treści postanowień opisu 

przedmiotu zamówienia wskazanych w pkt 5, pkt 7, pkt 12 ppkt 1 i 4, pkt 13 ppkt 2 i 3, pkt 

15  ppkt  2,  pkt  17,  pkt  19,  pkt  20,  pkt  38,  pkt  40,  pkt  41,  pkt  42  i  pkt  43  tabeli  zawartej 

uzasadnieniu odwołania; 

2.  oddala 

odwołanie; 

kosztami  postępowania  obciąża  odwołującego  Laboratorium  EE  Spółka  z  ograniczoną 

odpowiedzialnością  Spółka  komandytowa  z  siedzibą  w  Warszawie  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 odwołującego tytułem wpisu od odwołania. 


Stosownie  do  art. 

579  ust.  1  i  580  ust.  1  i  2  ustawy  z  dnia  11  września  2019  r.  -  Prawo 

zamówień publicznych (t.j. Dz. U. z 2021 r. poz. 1129) na niniejszy wyrok - w terminie 14 dni 

od  dnia  jego  doręczenia  -  przysługuje  skarga  za  pośrednictwem  Prezesa  Krajowej  Izby 

Odwoławczej do Sądu Okręgowego w Warszawie. 

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


Sygn. akt: KIO 2820/21 

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

Zamawiający Główny Urząd Nadzoru Budowlanego z siedzibą w Warszawie (dalej jako 

„Zamawiający”)  prowadzi  postępowanie  o udzielenie  zamówienia  publicznego  pn. 

„Zaprojektowanie,  budowa  i  wdrożenie  Systemu  ZONE”  (nr  ref.  BAF.260.7.2021). 

Ogłoszenie o zamówieniu zostało opublikowane w Dzienniku Urzędowym Unii Europejskiej z 

dnia 

14  września  2021  r.  pod  numerem  2021/S  178-463964.  Do  ww.  postępowania 

udzielenie zamówienia zastosowanie znajdują przepisy ustawy z dnia 11 września 2019 r. - 

Prawo  zamówień  publicznych  (t.j.  Dz.  U.  z  2021  r.  poz.  1129  ze  zm.,  dalej  „ustawa  Pzp”). 

Wartość szacunkowa zamówienia  przekracza  progi  unijne,  o których  mowa w art.  3  ustawy 

Pzp.   

W  dniu  24 

września  2021  r.  wykonawca  Laboratorium  EE  Spółka  z  ograniczoną 

odpowiedzialnością Spółka komandytowa z siedzibą w Warszawie (dalej jako „Odwołujący”) 

wn

iósł  odwołanie  wobec  treści  specyfikacji  warunków  zamówienia  („SWZ”)  i  ogłoszenia 

zamówieniu, zarzucając Zamawiającemu naruszenie: 

1.  art.  99  ust.  1  w  zw.  z  art.  16  ustawy  Pzp 

poprzez  opisanie  przedmiotu  zamówienia 

sposób  niejednoznaczny  i  niewyczerpujący,  bez  uwzględnienia  wszystkich  wymagań 

i okoliczno

ści  mogących  mieć  wpływ  na  sporządzenie  oferty,  co  narusza  zasady 

proporcjonalno

ści,  zapewnienia  zachowania  uczciwej  konkurencji  oraz  równego 

traktowania wykonawców; 

2.  art.  99  ust.  4  w  zw.  z  art.  16  ustawy  Pzp 

poprzez  opisanie  przedmiotu  zamówienia 

sposób utrudniający uczciwą konkurencję oraz zasady proporcjonalności, zapewnienia 

zachowania uczciwej 

konkurencji oraz równego traktowania wykonawców.  

Odwołujący wskazał, iż szczegółowe przypisanie naruszenia przepisów prawa zostało 

dokonane poni

żej w uzasadnieniu odwołania, osobno w każdym zarzucie. Odwołujący wniósł 

o  uwzgl

ędnienie  odwołania  i  nakazanie  Zamawiającemu  dokonania  modyfikacji  SWZ  oraz 

og

łoszenia  w  zakresie  wskazanym  w  odwołaniu  poprzez  zmianę  wskazanych  zapisów 

sposób wskazany w odwołaniu – szczegółowo w każdym zarzucie. 

W  uzasadnieniu  odwołania  wskazano,  iż  opis  przedmiotu  zamówienia  został 

sporządzony  w  sposób  naruszający  art.  99  ust.  1  i  4  ustawy  Pzp.  Odwołujący  wskazał,  iż 

podstawowym  obowi

ązkiem  Zamawiającego  jest  prawidłowe  sporządzenie  SWZ,  w  tym 

sporz

ądzenie  kompletnego  i  jednoznacznego  opisu  przedmiotu  zamówienia,  jako  elementu 

istotnego  i  warunkuj

ącego  złożenie  prawidłowej  oferty  przez  zainteresowanych 

wykonawców.  Tymczasem  Zamawiający,  dokonując  w  postępowaniu  opisu  przedmiotu 

zamówienia, nie dostarczył w SWZ szeregu informacji, które są niezbędne do przygotowania 


oferty. Ich  brak ma  istotny  wp

ływ na niepewność wyceny i może być różnie interpretowany 

przez  oferentów,  co  narusza  zasady  zapewnienia  zachowania  uczciwej  konkurencji  oraz 

równego traktowania wykonawców. 

W  tabeli 

przedstawionej  w  uzasadnieniu  odwołania  Odwołujący  wyszczególnił 

najbardziej  istotne  w  jego  ocenie  braki  w  OPZ, 

które  uniemożliwiają  dokonanie  rzetelnej 

kalkulacji ceny ofertowej: 

OPZ 6.1.1.3 Usługa walidacji i zasilenia bazy danych CEEB 

Opis wymagania: Us

ługa pobiera dane z Katalogu danych tymczasowych i na podstawie 

zdefiniowanych Regu

ł zarządzania danymi, zasila wszystkie magazyny danych Systemu 

ZONE tj: - Dotacji 

– dane pobierane są z systemów zewnętrznych w zakresie możliwego 

i udzielonego  wsparcia  finansowego  na  przedsi

ęwzięcia  termomodernizacyjne  oraz 

programów  dotacyjnych;  -  Ubóstwo  energetyczne  –  dane  pobierane  są  z  systemów 

zewn

ętrznych w zakresie socjalnego wsparcia finansowego. 

Uwagi  Odwołującego:    OPZ  nie  precyzuje  w  jakim  zakresie  i  w  jaki  sposób  dane  mają 

by

ć przekazywane do systemu ZONE. 

2.  OPZ 6.1.3.3 Centralne Repozytorium Analityczne 

Opis  wymagania:  Modu

ł  analityczno-raportowy  umożliwi  jego  użytkownikom  tworzenie 

zaawansowanych  analiz  i  raportów  przy  użyciu  wielu  i  nieustrukturyzowanych  źródeł 

danych,  umo

żliwiając  wykrywanie  powiązań  i  zależności  pomiędzy  rejestrami,  w  tym 

ocen

ę  skuteczności  podejmowanych  działań  i  identyfikację  rezultatów  Projektu  w  wielu 

powi

ązanych  ze  sobą  obszarach.  Powyższe  determinuje,  że  Centralne  Repozytorium 

Analityczne b

ędzie bazą grafową, dodatkowo Moduł musi umożliwiać analizę wszystkich 

powy

ższych  danych  w  oparciu  o  analitykę  grafową,  pozwalającą  na  wykrywanie 

zale

żności  pomiędzy  różnymi  obiektami  poszczególnych  rejestrów  w  powiązaniu  z  ich 

lokalizacj

ą  przestrzenną.  Ponadto,  powinien  zapewniać  możliwość  włączenia  kolejnych 

rejestrów do analizy, bez konieczności przeprojektowywania struktury danych. Włączane 

rejestry powinny w sposób automatyczny wykrywać powiązania z istniejącymi rejestrami.”  

Uwagi Odwołującego:  OPZ nie wyjaśnia jakie analizy ma Zamawiający na myśli w tym 

wymaganiu  (do  czego  b

ędzie  moduł  wykorzystywany).  OPZ  nigdzie  nie  podaje 

przyk

ładów  takich  analiza  i  takiego  „kolejnego  rejestru”,  który  automatycznie  wykryje 

powi

ązania  z istniejącymi  rejestrami.  OPZ  nigdzie  nie  wskazuje  przykładów 

nieustrukturyzowanych 

źródeł danych i powiązań oraz zależności w zakresie tworzonego 

Systemu. 

3.  OPZ 6.1.4 

Moduł e-learning 

Opis  wymagania:  Modu

ł  odpowiedzialny  jest  za  monitorowanie  procesu  nauczania 

interesariuszy  Systemu  ZONE.  Wykonawca  w  ramach  dostarczenia  Modu

łu  e-


learningowego  odpowiada  za:  Przygotowywanie  materia

łów  i  szkoleń  e-learnigowych, 

Przypisywanie  uczestników  lub  grup  użytkowników  do  wskazanych  szkoleń, 

Przygotowywanie testów dla uczestników szkoleń, Rejestrowanie postępów uczestników 

szkole

ń. 

Uwagi  Odwołującego:  Moduł  to  mechanizm,  materiały  to  usługa,  gdzie  należy  je 

przygotowa

ć  i  nimi  zasilić  moduł  –  prezentacje,  filmy,  testy.  OPZ  nigdzie  nie  precyzuje 

ilo

ści i zakresu materiałów szkoleniowych.  

4.  OPZ 6.1.8.1 Dotacje  

Opis  wymagania:  Podmodu

ł  odpowiedzialny  za  przechowywanie  informacji  odnośnie 

mo

żliwego 

udzielonego 

wsparcia 

finansowego 

na 

przedsi

ęwzięcia 

termomodernizacyjne. 

Uwagi  Odwołującego:  Nieprecyzyjne  wymagania  na  „Model  wartościowania  programów 

dotacyjnych”,  który  wykonawca  ma  zaprojektować  i  przedstawić  do  akceptacji.  Zakres 

tego  modu

łu jest  otwarty  –  wymagana  jest  co  najmniej  przewidywana  liczba  atrybutów, 

wag. 

Poza 

wymienionymi 

integracjami 

–  o  jakich  innych  dodatkowych 

integracjach/systemach  jest  mowa  w 

przypadku  Dotacji  („w  zakresie  programów 

dotacyjnych  dane  pobierane  s

ą  z systemów  zewnętrznych  lub  wprowadzane  przez 

operato

ra”). 

5.  OPZ 6.1.9.1 Kontrola 

środowiskowa 

Opis  wymagania:  Podmodu

ł  umożliwia  wprowadzanie  danych  do  Systemu  ZONE 

z przeprowadzonej kontroli 

środowiskowej, która odbywa się poza Systemem ZONE.  

Uwagi  Odwołującego:  Wymaganie  nie  precyzuje  czy  podmoduł  ma  służyć  do 

przeprowadzania ju

ż zleconych kontroli czy również do wnioskowania o nie. 

6.  OPZ 6.1.9.2 

Przegląd Kominiarski 

Opis  wymagania:  Podmodu

ł  umożliwia  realizację  zamówienia  usługi  przeglądu 

kominiarskiego  wraz  z  pe

łną  funkcjonalnością  do  zarządzania  zamówieniem,  czyli 

elektroniczn

ą  rezerwację  terminu  usługi  przeglądu  kominiarskiego,  wybór  wykonawcy 

us

ługi  poprzez  wybór  kominiarza  lub  wystawienie  zapytania  ofertowego,  zarządzanie 

terminem  realizacji  przegl

ądu  kominiarskiego  (np.  zmiana  terminu,  jej  odwołanie, 

edytowanie  danych),  pobranie  dokumentu  z  wynikami  przeprowadzonego  przegl

ądu 

kominiarskiego,  niezb

ędnego  do  ubiegania  się  o  różne  formy  pomocy  publicznej  na 

termomodernizacj

ę  i/lub  wymianę  źródeł  ciepła  w  budynkach.  Przyczyni  się  to  przede 

wszystkim  do  poprawy  bezpiecze

ństwa  mieszkańców,  a  przedstawicielom  administracji 

publicznej umo

żliwi monitorowanie stanu przeglądów kominiarskich oraz pozyskanych tą 

drog

ą  danych  opisujących  stan  budynku/  lokalu  i  zainstalowanych  w  nim  źródeł  ciepła, 

dane  te  b

ędą  dostępne  w  Module  Analityczno-Raportowym.  Wybierając  wykonawcę 

us

ługi poprzez wystawienie zapytania ofertowego w Systemie ZONE umożliwia składanie 


ofert  przez  osoby  posiadaj

ące  odpowiednie  uprawnienia  na  zamówienia  przeglądu 

kominiarskiego oraz wprowadzanie danych po jego wykonaniu. 

Uwagi  Odwołującego:  1.  “Podmoduł  umożliwia  realizację  zamówienia  usługi  przeglądu 

kominiarskiego  wraz  z  pe

łną  funkcjonalnością  do  zarządzania  zamówieniem,  czyli 

elektroniczn

ą  rezerwację  terminu  usługi  przeglądu  kominiarskiego“  -  natomiast  w  tabeli 

pliku  “Załącznik  nr  1  Mapowanie  użytkowników  Systemu  ZONE  na  poszczególne 

modu

ły funkcjonalne” widnieje informacja, że tylko kominiarz może wprowadzać dane w 

tej  sekcji.  2.  Nie  jest  jasne,  czy  to  tylko  modu

ł  do  składania  i  przyjmowania  zamówień, 

czy również do podglądu efektów dla uprawnionych stron (np. samorządy…). 3. Eksport 

danych  do  systemów  referencyjnych  –  usługa  powinna  łączyć  się  z  innymi  systemami, 

poza  CEEB.  Wymaganie  nie  wyja

śnia  w  jaki  sposób  będą  zabezpieczane  dane 

u

żytkowników  oraz  przez  jaki  okres  czasu  powinny  być  przechowywane  dane 

u

żytkowników. 

7.  OPZ 6.1.9.4 

„Kopciuchy” 

Opis  wymagania:  Podmodu

ł  umożliwia  zgłoszenie  tzw.  „kopciucha”.  Zgłoszenie 

realizowane  jest  przez  u

żytkownika  zarejestrowanego.  Podmoduł  zgłoszenia  kopciucha 

ma  na  celu  zlokalizowanie  i  wyeliminowanie  nieefektywnego 

źródła  ciepła.  Informacje 

wprowadzone  do  systemu  umo

żliwiają  dalsze  jego  procedowanie  służbom  kontrolnym 

(Stra

ż  miejska  lub  gminna),  które  w  trakcie  kontroli  wprowadzają  dane  do  Systemu 

ZONE. 

Uwagi  Odwołującego:  1.  Nie  jest  jasne,  czy  osoba  zgłaszająca  jest  informowana 

o przyj

ęciu  zgłoszenia  przez  służby  kontrolne.  2.  W  wymaganiach  funkcjonalnych: 

“W odebrania  zgłoszenia  Kopciucha,  osoba  o  odpowiednich  uprawnieniach  przesyłając 

dalej  zg

łoszenie...“  –  czy  to  oznacza,  że  wymagana  jest  funkcjonalność  wspierającą 

powiadamiania 

– w jaki sposób – SMS, email, alert? Czy obsługa „kopciuchów” to proces 

wspomagany przez System ZONE? Powy

ższe informacje nie zostały doprecyzowane. 

8.  OPZ 6.1.10 

Moduł GIS 

Opis  wymagania:  Geoportal  dodatkowo  umo

żliwia  wykonywanie  zapytań  i  analiz 

przestrzennych  u

żytkownikom  z  poziomu mapy OPZ nigdzie nie precyzuje jakiego typu 

analizy przestrzenne, w oparciu o jakie dane i warstwy, maj

ą być realizowane z poziomu 

przegl

ądania  mapy.  Nie jest  również  doprecyzowane,  jaki  Moduł  GIS  ma  mieć  związek 

z Modu

łem analityczno-raportowym. 

9.  OPZ 6.1.10.3 

Serwer Usług Katalogowych 

Opis wymagania: Serwer Us

ług Katalogowych odpowiedzialny jest za: Przechowywanie, 

Tworzenie,  Udost

ępnianie  zasobu  metadanych.  Funkcjonalność  serwera  usług 

katalogowych  realizowana  jest  poprzez  us

ługę  zgodną  ze  specyfikacją  z  normami  ISO 

19115  i  ISO  19119  w  najnowszych  wersjach.  Serwer  Us

ług Katalogowych zapewnia: 1. 


Przeszukiwanie  zbiorów  metadanych,  2.  Import  metadanych  z  pliku  XML,  3.  Import 

metadanych  w  trybie  harvestingu.  Serwer  Us

ług  Katalogowych  udostępnia  usługę 

przeszukiwania zbiorów metadanych. Usługa ta umożliwia wyszukiwanie zbiorów i usług 

danych  przestrzennych. 

Szczegółowe  wymagania  w  zakresie  modułu  GIS  znajdują  się 

w Za

łączniku  nr  2,  natomiast  Wykonawca  może  zaproponować  inne  równoważne 

rozwi

ązania w zakresie prezentacji danych z wykorzystaniem najnowszych technologii. 

Uwagi Odwołującego: 1.. Wymagane jest określenia wersji standardów metadanych jakie 

ma  obs

ługiwać  Serwer  Usług  Katalogowych.  2.  Wymagane  jest  określenia  standardów 

dla importu metadanych w plikach XML. 3. Wymagane jest okre

ślenie standardów źródeł 

dla importu w trybie harverstingu. 

10. OPZ 6.1.12 ZONE App 

Opis  wymagania

W  ramach  Systemu  ZONE,  wyróżnia  się  także  aplikację  mobilną. 

Aplikacja mobilna musi zosta

ć opracowana dla najnowszych i stabilnych wersji, zarówno 

na  System  Android,  jak  i  na  iOS. 

(…)  Jedynie  podmoduł Wiadomości jest  podmodułem 

zasilanym  tre

ścią  przez  Portal  Systemu  ZONE  w  zakresie  wiadomości  i  artykułów  oraz 

Silnik Alertów w zakresie Alertów. 

Uwagi Odwołującego: 1. W dokumencie OPZ nie ma informacji czy w aplikacji mobilnej 

b

ędzie  dostępny  geoportal,  w  załączniku  nr.  2,  już  jest  -  jeżeli  tak,  to  nie  jest 

doprecyzowane,  w  jakim  zakresie. 

2.  „Jedynie  podmoduł  Wiadomości jest  podmodułem 

zasilanym  tre

ścią  przez  Portal  Systemu  ZONE  w  zakresie  wiadomości  i  artykułów  oraz 

Silnik 

Alertów  w  zakresie  Alertów”  –  nie  wiadomo  jak  należy  rozumieć  to  zdanie 

w kontek

ście wymagań na ZONE App. 

11. OPZ 6.1.15 

Zewnętrzne Systemy referencyjne współpracujące z Systemem ZONE 

Opis  wymagania:  Cz

ęść  danych  przechowywanych  w  CEEB  będzie  pozyskana 

Systemów  Referencyjnych.  Dostęp  do  wskazanych  systemów  zostanie  zapewniony 

przez:  1.  Zamawiaj

ącego w  aspekcie formalno-organizacyjnym  (np.  poprzez podpisanie 

stosownych  porozumie

ń).  2.  Wykonawcę  w  aspekcie  warstwy  technicznej.  Poniżej 

przedstawiono  jakie  dane  musz

ą  zostać  pozyskane  do  Systemu  ZONE:  (…)  8. 

Uniwersalne  API  dla  systemów  sektora  publicznego  umożliwiać  będzie  komunikację 

Systemu  ZONE  z  Zewn

ętrznymi  Systemami  Referencyjnymi,  obsługującymi  różne  typy 

danych. 

Uwagi  Odwołującego:  1.  W  p.  8  Dedykowane,  uniwersalne  API  dla  systemów  sektora 

publicznego umo

żliwiać będzie komunikację Systemu ZONE z Systemami zewnętrznymi. 

Kluczowe w kontek

ście wyceny jest wyjaśnienie co należy rozumieć pod „uniwersalnym 

API”.  2.  Nie zostało doprecyzowane, czy  w  ramach  tego API Wykonawca zobowiązany 

jest  do  zrealizowania  konkretnych  integracji  w  zakresie  wytwarzania  ZONE.  3  Zgodnie 

z przyj

ętymi  założeniami,  System  ZONE  będzie  generował  dane,  które  mogą  być 


wy

korzystane  do  aktualizacji  Systemów  Referencyjnych.  Aktualizacja  będzie  związana 

z wysy

łaniem  plików  do  Gestorów  Systemów  Referencyjnych.  Nie  zostało 

doprecyzowane,  o 

jakich  systemów  Referencyjnych,  w  jakim  formacie  oraz  czy  w 

zakresie wytwarzania b

ędzie wymagana realizacja takiej integracji. 

12. OPZ 6.4 E-

Usługi Systemu ZONE 

Opis wymagań: W ramach Projektu przewiduje się uruchomienie e-usług, które w sposób 

bezpo

średni będą odpowiadać na potrzeby obywateli oraz przedsiębiorców, a w sposób 

po

średni będą stanowić źródło informacji dla administracji w celu wypracowania strategii 

dzia

łań  na  rzecz  poprawy  jakości  powietrza.  Projektowane  e-usługi  umożliwią  odbiorcy 

m.in.  spe

łnić  obowiązek  prawny,  jakim  jest  coroczne  wykonywanie  przeglądu 

kominiarskiego  oraz  posiadanie  kot

ła zgodnego z  wymogami  prawa,  zweryfikować  stan 

energetyczny  swojego  budynku,  a  tak

że  wskażą  potrzebne  modyfikacje  i  programy 

finansuj

ące termomodernizację i wymianę kopciuchów.  

Uwagi Odwołującego: OPZ nie wyjaśnia: 1. Jaka jest różnica między modułem “E-usługi” 

i Modu

łem inwentaryzacji budynków? Z opisu wydaje się, że to są dwa sposoby opisania 

tych samych funkcjonalno

ści. 2. „w sposób pośredni będą stanowić źródło informacji dla 

administracji”  –  w  jaki  sposób?  czy  moduł  e-usługi  przewiduje  też  jakiś  sposób 

raportowania  dzia

łań  użytkowników?  Jeśli  tak,  jakie  raporty  są  potrzebne?  3. 

„Projektowane  e-usługi  umożliwią  odbiorcy  m.in.  spełnić  obowiązek  prawny,  jakim  jest 

coroczne  wykonywanie  przegl

ądu  kominiarskiego”  -  Czy  Moduł  będzie  miał 

funkcjonalno

ść przypominania zarejestrowanym użytkownikom o zbliżającym się terminie 

przegl

ądu,  przesyłania  innych  komunikatów?  Jakim  medium  (SMS,  email)?    4. 

„posiadanie  kotła  zgodnego  z  wymogami  prawa”  -  w  jaki  sposób  użytkownik  może 

zweryfikowa

ć  posiadanie  kotła  zgodnego  z  wymogami  prawa  za  pomocą  aplikacji?    5. 

„wszystkie kroki procesu (poza tymi, które muszą być wykonane manualnie: czyszczenie 

komina,  ogl

ędziny,  weryfikacja  stanu  technicznego  budynku,  itp.)  są  wspierane  przez 

System  ZONE  poprzez  komunikacj

ę  elektroniczną,”  „System  ZONE  z  punktu  widzenia 

zadeklarowanych  e-us

ług  obsługuje  w całości  (od  początku  do  końca)  wszystkie 

elementy  us

ługi  i  nie wymaga  żadnych działań "poza systemem".  Czy  system ma mieć 

mo

żliwość  przesyłania  wiadomości  między  użytkownikami?  pomiędzy  jakimi  grupami 

u

żytkowników? 

13. OPZ 6.4.1 E-

usługa – Zamów przegląd kominiarski 

Opis  wymagań:  „Użytkownik  może  sam  wybrać  termin  realizacji  usługi”  (…)  “Obywatel 

b

ędzie mógł pobrać dokument z wynikami przeprowadzonego przeglądu kominiarskiego” 

(…)  “Elektronicznie  będzie  można  zrealizować  wszystkie  czynności  od  zamówienia 

przegl

ądu, aż po dokonanie zapisów w CEEB. Wszystkie dokumenty związane z usługą 

b

ędą dostępne dla Usługobiorcy w formie elektronicznej.”(…)  


Uwagi  Odwołującego:  OPZ  nie  wyjaśnia:  1.  "Użytkownik  może  sam  wybrać  termin 

realizacji  us

ługi”  -  w  jaki  sposób  firmy  będą  wprowadzały  dostępne  usługi  i  terminy?  2. 

“Obywatel  będzie  mógł  pobrać  dokument  z  wynikami  przeprowadzonego  przeglądu 

kominiarskiego”  –  W  jaki  sposób  dokument  będzie  uwierzytelniany  (pieczęć)?  3. 

“Elektronicznie  będzie  można  zrealizować  wszystkie  czynności  od  zamówienia 

przegl

ądu, aż po dokonanie zapisów w CEEB. Wszystkie dokumenty związane z usługą 

b

ędą  dostępne  dla  Usługobiorcy  w  formie  elektronicznej.”  -  W  jaki  sposób,  w  jakim 

formacie b

ędzie można pobrać dokumenty? Jak będą uwierzytelniane (pieczęć, PKI)? 

14. OPZ 6.4.2 E-

usługa – Zamów inwentaryzację budynku 

Opis  wymagań:  „Do  zamówienia  inwentaryzacji  budynku  przez  urzędników  gminy  lub 

funkcjonariuszy  stra

ży miejskiej i gminnej.” (…) „Z punktu widzenia właściciela budynku 

otrzyma  on  elektroniczny  dokument  z  wynikami  przeprowadzonej  inwentaryzacji 

budynku” (…) „Eksport danych do systemów referencyjnych – usługa powinna łączyć się 

z innymi systemami, poza CEEB."  

Uwagi  Odwołującego:  „W  jaki  sposób  będą  zabezpieczane  dane  użytkowników?  Przez 

jaki okres czasu powinny by

ć przechowywane dane użytkowników? OPZ nie wyjaśnia: 1. 

„do  zamówienia  inwentaryzacji  budynku  przez  urzędników  gminy  lub  funkcjonariuszy 

stra

ży  miejskiej  i  gminnej.”  -  W  jaki  sposób  urzędnicy  etc.  będą  wpisywać  dostępne 

terminy  i  je  akceptowa

ć?  Jak  będą  się  komunikować  z  zamawiającymi?  Czy  to  będzie 

automatyczne,  czy  to  ma  by

ć  interfejs  do  wymiany  maili?  2.  “Z  punktu  widzenia 

w

łaściciela  budynku  otrzyma  on  elektroniczny  dokument  z  wynikami  przeprowadzonej 

inwentaryzacji 

budynku”  –  czy  te  dokumenty  będą  generowane  w  systemie  w  sposób 

automatyczny?  W  ja

ki  sposób  będą  podpisywane?  3.  Eksport  danych  do  systemów 

referencyjnych 

–  usługa  powinna  łączyć  się  z  innymi  systemami,  poza  CEEB.  W  jaki 

sposób  będą  zabezpieczane  dane  użytkowników?  Przez  jaki  okres  czasu  powinny  być 

przechowywane dane u

żytkowników? E-usługi mają być funkcjonalnościami dostępnymi 

dla  u

żytkowników  końcowych  Zone,  czyli  interfejsem  łączącym  różne  moduły  systemu. 

Brakuje  opisu,  w  jaki  sposób  ma  to  być  zrealizowane.  E-usługi  powinny  być  dostępne 

zarówno z poziomu strony internetowej, jak i aplikacji mobilnej. Nie wiadomo, czy system 

ma  zapewnia

ć  pełną  obsługę  interesantów,  czy  tylko  umożliwiać  kontakt  pomiędzy 

stronami,  co  znacz

ąco  zmienia  zakres  projektu.  Możliwe  są  dwie  opcje:  -  system 

umo

żliwia  ręczne  zarządzanie  danymi  dotyczącymi  dostępnych  terminów  wykonania 

zamawianych us

ług i pozwala na kontakt mailowy pomiędzy użytkownikami (np. poprzez 

formularz kontaktowy). W tym przypadku proces przebiega nast

ępująco: firma oferująca 

przegl

ądy  uzupełnia  dane  dotyczące  wolnych  terminów,  które  pojawiają  się  na  stronie. 

U

żytkownik  przegląda  terminy,  a  następnie  kontaktuje  się  z  firmą  za  9  pomocą 

formularza kontaktowego. Firma odpowiada na jego rezerwacj

ę, ręcznie oznacza termin 


jako niedost

ępny. Po dokonaniu przeglądu Firma przygotowuje dokument z informacjami 

o  efektach  przegl

ądu  poza  systemem,  a  następnie  przesyła  go  do  użytkownika  przy 

u

życiu  formularza.  Lub  -  system  umożliwia  pełną  obsługę  procesów,  bez  korzystania  z 

narz

ędzi  zewnętrznych.  Proponowany  proces  to:  firma  oferująca  przeglądy  uzupełnia 

dane  o  dost

ępnych  usługach  i  terminach.  Użytkownik  może  przeglądać  terminy  i 

rezerwowa

ć  je  przy  użyciu  aplikacji.  Pracownik  firmy  widzi  dokonane  rezerwacje,  ma 

mo

żliwość potwierdzenia ich, bądź zaproponowania innego terminu przy użyciu aplikacji. 

Po  potwierdzeniu  rezerwacji  przez  pracownika  firmy  termin  jest  automatycznie 

oznaczany  jako  niedost

ępny  i  znika  z  kalendarza.  W  trakcie  przeglądu  pracownik  ma 

dost

ęp do ankiety, w której może uzupełnić wyniki przeglądu. Po zakończeniu przeglądu 

na podstawie ankiety w systemie generowany jest 

automatycznie dokument, który może 

pobra

ć osoba zamawiająca przegląd. W OPZ nie zostało omówione, w jaki sposób firmy i 

organy  administracji  rz

ądowej  będą  obsługiwać  CEEB.  Powinien  istnieć  osobny  moduł, 

pozwalaj

ący  im  na  oferowanie  usług,  terminów,  dokumentowanie  wykonanych 

inwentaryzacji i przegl

ądów. Nie wiadomo, w jakiej formie mają być udostępniane dane w 

ramach us

ługi “Obsługa CEEB”. Czy wystarczy dostęp przez panel administracyjny? Czy 

ta us

ługa również powinna posiadać front? 

OPZ 7.3 Wymagania Przejściowe 

Opis wymagań: a. Wykonawca zobowiązany jest do pozyskania danych BDOT10k oraz 

danych  PRG  z  GUGIK  oraz  zasilenia  nimi  Systemu  ZONE.  Dane  prezentacyjne 

w Systemie ZONE b

ędą odnosiły się właśnie do budynków. b. Wykonawca zobowiązany 

jest  do  pozyskania  i  zaimportowania  danych  pochodz

ących  z  bazy  danych  CRCEB 

w zakresie  danych  o  audytorach  energetycznych,  osobach  uprawnionych  do 

sporz

ądzania świadectw charakterystyki energetycznej budynków; danych pochodzących 

ze 

świadectw charakterystyki energetycznej budynków. c. Wykonawca zobowiązany jest 

do  zaimportowania  do  Systemu  ZONE  danych  pochodz

ących  z  systemów 

teleinformatycznych  gmin.  Zamawiaj

ący  zakłada,  że  ilość  gmin,  z  których  pozyskane 

zostan

ą  dane  do  zasilenia  będzie  wynosiła  około  250  jednostek,  jednak  Zamawiający 

wskazuje, 

że liczba ta może ulec zmianie. W punkcie 7 Wykonawca zobowiązany jest do 

migracji  danych  z  Systemu  ZONE  MVP  do  Systemu  ZONE.  Wykonawca  zobowi

ązany 

jest do pozyskiwania danych. 

Uwagi  Odwołującego:    1.Ne  zostało  doprecyzowane,  jakie  są  oczekiwania 

Zamawiaj

ącego  w  ramach  wymagań:  a.  „Wykonawca  zobowiązany  jest  do  pozyskania 

danych BDOT10k oraz danych PRG z GUGIK oraz zasilenia nimi Systemu ZONE. Dane 

prezentacyjne w Systemie ZONE b

ędą odnosiły się właśnie do budynków. b. Wykonawca 

zobowi

ązany jest do pozyskania i zaimportowania danych pochodzących z bazy danych 

CRCEB  w zakresie  danych  o  audytorach  energetycznych,  osobach  uprawnionych  do 


sporz

ądzania świadectw charakterystyki energetycznej budynków; danych pochodzących 

ze 

świadectw charakterystyki energetycznej budynków. c. Wykonawca zobowiązany jest 

do  zaimportowania  do  Systemu  ZONE  danych  pochodz

ących  z  systemów 

teleinformatycznych  gmin.  Zamawiaj

ący  zakłada,  że  ilość  gmin,  z  których  pozyskane 

zostan

ą  dane  do  zasilenia  będzie  wynosiła  około  250  jednostek,  jednak  Zamawiający 

wskazuje, 

że  liczba  ta  może  ulec  zmianie.  Jakie  dane  będą  podlegały  migracji  z  gmin 

i w jakiej  postaci  oraz  formacie?  Dlaczego  taka  ilo

ść  gmin?  Jaka  jest  korelacja 

powy

ższych wymagań i wymagań zawartych w rozdziałach dot. funkcjonalności systemu. 

Do  realizacji  zadania  niezb

ędne  jest  zawarcie  przez  Zamawiającego  porozumień  z 

GUGiK w zakresie dost

ępu do danych. 2. W punkcie 7. Wykonawca zobowiązany jest do 

migracji danych z Systemu ZONE MVP do Systemu ZONE. Brak informacji czy wszystkie 

dane b

ędą w systemie źródłowym, czy część będzie jeszcze np. w formie papierowej? 3. 

Wykonawca  zobowi

ązany  jest  do  pozyskiwania  danych.  Wymaga  wyjaśnienia  w  jakim 

celu  i  dlaczego  Wykonawca  ma  je  pozyskiwa

ć,  jeżeli  jednocześnie  będzie  realizowana 

integracja  z 

wymienionymi  Systemami,  a  za  zapewnienie  warunków  formalno-

organizacyjnych (np. porozumienia pomi

ędzy jednostkami) odpowiada Zamawiający. 

16. OPZ 8.3. Kryteria Odbioru 

Opis  wymagań:  1.  W  Testach  Dopuszczeniowych  zakładane  jest  0  błędów  krytycznych 

oraz  0  b

łędów  poważnych  –  przy  czym  za  błąd  krytyczny  przyjmuje  się  m.in.  brak 

realizacji  np.  1  wymagania  pozafunkcjonalnego.  Z  racji  tego, 

że  w  wymaganiach 

pozafunkcjonalnych  zawarty  jest  również  UX  (użyteczność),  czy  brak  realizacji  np.  1 

wymagania  dla  GUI  na  UX 

–  oznacza  wystąpienie  błędu  krytycznego?  2.  W  kryteriach 

odbioru pojawia si

ę również sformułowanie „istotna funkcjonalność” oraz „inna niż istotna 

funkcjonalno

ść”.  

Uwagi Odwołującego: 1. W OPZ brak jest określenia wymagania krytyczne jakie powinny 

powodowa

ć,  że  brak  1  wymagania  pozafunkcjonalnego  powoduje  wystąpienie  błędu 

krytycznego  i  jednocze

śnie  aby  wymagania  te  odnosiły  się  do  Modułu  jako  jednostki 

autonomicznej,  a  nie  ca

łości  Systemu.  2.  OPZ  nie  precyzuje  czym  wg  Zamawiającego 

dok

ładnie  jest  „istotna  funkcjonalność”,  czy  jest  tożsama  z  konkretnymi  przypadkami 

u

życia/modułami/procesami? Jeśli tak to z którymi? 

OPZ Wymagania w zakresie szkoleń 

Opis  wymagań:  “Wykonawca  przygotuje  i  przekaże  Zamawiającemu  platformę 

elearningow

ą umożliwiającą przeprowadzenie szkoleń on-line.”  

Uwagi  Odwołującego:  OPZ  nie  wyjaśnia  czy  platforma,  o  której  tutaj  mowa  rozumiana 

jest jako modu

ł e-learningowy opisany w OPZ. 

Załącznik 8 Automatyzacja procesu tworzenia georeferencyjnej warstwy budynków 


Uwagi  Odwołującego:  Dokument  specyfikuje  utworzenie  inicjalnej  warstwy  budynków  - 

jakie  zasady  (wymagania)  maj

ą  zapewnić  aktualizację  tej  warstwy  w  systemie  ZONE 

(cz

ęstotliwość, powiązania z innymi obiektami systemu np. w przypadku zmian, usuwania 

budynku,  itd.).  Opisany  w  OPZ  przypadek  u

życia dot.  aktualizacji  danych nie precyzuje 

jakich  danych  dotyczy  i  jak  ma  si

ę  do  tego  potrzeba  aktualizacji  warstwy 

georeferencyjnej. 

19. REQ-F-287 Portal Systemu Zone 

Opis wymagań: Portal ZONE musi posiadać pracujący w trybie online edytor WYSIWYG, 

umo

żliwiający  pracę  z  treścią  publikowaną  w  Portalu  ZONE  przy  jednoczesnym 

za

łożeniu braku znajomości  kodu HTML  przez Zamawiającego.  Edytor musi  zapewniać 

mo

żliwość  edytowania  tekstów  w  sposób  typowy  dla  popularnych  pakietów  biurowych 

oraz  wklejania 

tekstów  z  zachowaniem  formatowania  przyjętego  w  edytorze  tekstu. 

Edytor  musi  posiada

ć  co  najmniej  takie  funkcje  jak:-  pole  format  -  zawierające 

predefiniowane elementy strukturalne tre

ści (P, H1, H2, H3, H4),- pole styl – zawierające 

predefiniowane style CSS, mo

żliwość wyboru czcionki i jej rozmiaru oraz predefiniowania 

domy

ślnej czcionki,- opcje: Wytnij, Kopiuj, Wklej, Wklej jako czysty tekst, Wklej z Worda,- 

opcje:  Znajd

ź,  Zamień,  Zaznacz  wszystko,  Usuń  formatowanie,-  opcje:  Pogrubienie, 

Kursywa,  Podkre

ślenie, Przekreślenie, Indeks dolny,  Indeks górny,-  opcje: Wstaw/Usuń 

numerowanie  listy,  Wstaw/Usu

ń  wypunktowanie listy,-  opcje:  Zmniejsz/Zwiększ  wcięcie, 

Wyrównaj  do  lewej,  środka,  prawej,  wyjustuj,-  opcje:  Wstaw/Edytuj/Usuń  załącznik, 

grafik

ę,  hiperłącze,  kotwicę,-  opcje:  Wstaw/Edytuj  tabelę,-  opcje:  Zmień  kolor  czcionki, 

Zmie

ń  kolor  tła,-  opcje:  Pokaż/Edytuj  kod  źródłowy,-  podział  strony  (stronicowanie).Kod 

wstawiany  przez  edytor  musi  by

ć  zgodny  minimum  ze  standardami  HTML  5  i  CSS  3. 

Praca  w  edytorze  musi  odbywa

ć  się  z  poziomu  przeglądarki  internetowej  bez 

konieczno

ści instalacji specjalnego oprogramowania klienckiego. Edytor musi posiadać 3 

tryby  wy

świetlania  zawartości:  zwykły  tryb  edycyjny  (WYSIWYG),  tryb  HTML  i  tryb 

podgl

ądu  strony  (preview).  Elementy  graficzne  dołączane  do  tekstów  muszą  mieć 

mo

żliwość  skalowania  do  dowolnych  rozmiarów,  definiowania  miejsca  położenia, 

wielko

ści, sposobu wyrównania tekstu i otwarcia w nowym oknie lub w technice „overlay” 

(przed  tekstem).  System  musi  umo

żliwiać  podgląd  strony  na  każdym  etapie  redakcji  w 

uk

ładzie  (szablonie)  w  jakim  będzie  on  prezentowany  w  Portalu  ZONE.  Edytor  musi 

posiada

ć  możliwość  ograniczenia  dostępności  wybranych  opcji  dla  określonych  grup 

u

żytkowników. 

Uwagi  Odwołującego:  Niektóre  z  wymagań  w  tym  punkcie  kolidują  z  wymaganiami  z 

innych 

punktów:  1.  Możliwość  skalowania  grafik  do  dowolnych  rozmiarów  koliduje  z 

wymaganiem  poprawnego  wy

świetlania  na  ekranach  o  różnym  rozmiarze  opisanym  w 

wymaganiu REQ-F-295. 2. Mo

żliwość edycji styli CSS koliduje z REQ-NF-60 - działania 


osoby wprowadzaj

ącej treści mogą negatywnie wpływać na wygląd strony, do czego nie 

mia

ła uprawnień. 3. Bogate możliwość formatowania treści są sprzeczne z REQ-NF-78, 

REQ-NF-81 (dobry interfejs u

żytkownika). 

20. REQ-F-320 Portal Systemu Zone  

Opis  wymagań:  Dla  Potalu  ZONE,  musi  istnieć  możliwość  dostosowywania  wyglądu, 

tre

ści oraz funkcjonalności w zależności od roli użytkownika końcowego.  

Uwagi  Odwołującego:  W  OPZ  brak  jest  doprecyzowania,  w  jakim  zakresie  ma  być 

mo

żliwe to dostosowanie. 

21. REQ-F-295 Portal Systemu Zone 

Opis wymagań: Portal ZONE będzie posiadał wersję na systemy mobilne, dostosowaną 

do  przegl

ądarek  urządzeń  przenośnych  (telefonów,  smartphone’ów,  tabletów  i  innych). 

Wersja  na  systemy  mobilne  b

ędzie  zawierała  wyłącznie  wybrane  funkcjonalności,  które 

zapewni

ą  jej  prawidłowe  funkcjonowanie  na  urządzeniach  przenośnych.  Wersja  na 

systemy mobilne b

ędzie generowana automatycznie, tzn. nie będzie wymagała ingerencji 

administratora serwisu. 

Uwagi 

Odwołującego:  Brak  określonej  zawartości  “wersji  na  systemy  mobilne”,  gdyż 

brakuje  doprecyzowania  poj

ęcia  "wybrane  funkcjonalności".  Nie  jest  wskazane  wprost 

czy “wersja na systemy mobilne” ma być zrealizowana jako serwis internetowy, czy jako 

natywna  aplikacja  mobilna.  Informacje  zawarte  w  OPZ  (np.  web  GUI  dla  modularnej 

aplikacji Systemu ZONE) nie pozwalaj

ą jednoznacznie stwierdzić, czym ma być "wersja 

na systemy mobilne". 

22. REQ-NF-32 

Wydajność 

Opis wymagań: System musi umożliwiać pracę dla nieograniczonej liczby użytkowników 

Uwagi Odwołującego: Brak doprecyzowania wymagania czy chodzi o to, aby system nie 

mia

ł  ograniczeń  licencyjnych,  czy  aby  przy  określonej  liczbie  użytkowników  (nawet 

bardzo  du

żej)  miał  określoną  charakterystykę  wydajnościową.  W  przypadku  wymagań 

wydajno

ściowych  brak  jest  określenia  liczby  jednocześnie  pracujących  użytkowników 

wraz z okre

śleniem charakterystyki wydajnościowej dla systemu (metryki). 

(w  tym  miejscu  w  tabeli  po  numerze  22  wskazano  numer  32 

–  dalsza  numeracja  zgodnie 

przyjętą w treści odwołania) 

32. REQ-F-245 ZONE.App 

Opis wymagań: Aplikacja mobilna umożliwia zbieranie danych zgodnie z 

obowi

ązującymi przepisami prawa (ustawa i rozporządzenie). 

Uwagi Odwołującego: Brak doprecyzowania, w jaki sposób Wykonawca powinien 

zabezpieczy

ć dane przechowywane na dysku urządzenia mobilnego oraz, czy 

Zamawiaj

ący określi wymagania związane z szyfrowaniem i weryfikacją tożsamości (np. 

biometryczn

ą). 


33. REQ-F-39 ZONE.App 

Opis  wymagań:  Aplikacja  będzie  posiadała  przynajmniej  poniższe  grupy  funkcjonalne:- 

Modu

ł  -  Inwentaryzacji  budynku  -  moduł  służy  do  przeprowadzania  inwentaryzacji 

budynku,  przegl

ądów  kominiarskich,  kontroli  środowiskowych  i  kontroli  kopciuchów. 

Modu

ł udostępnia informacje zapisane w CEEB i umożliwia wprowadzanie danych przy 

zastosowaniu  formularzy;-  GIS  (Geoportal)  -  modu

ł  prezentuje  w  formie  graficznej 

wszystkie  budynki.  Z  poziomu  mapy  mo

żna  zobaczyć  informację  o  obiekcie,  wybrać 

obiekty  za  pomoc

ą  wskazania,  analizy  przestrzennej  lub  atrybutowej.  Użytkownik  klika 

w wyszukany  na  mapie  budynek  i  zostaje 

przeniesiony  na  szczegóły  budynku.  Na  tym 

widoku  u

żytkownik  zobaczy  informację  przeprowadzonych  dotychczas  inwentaryzacji 

budynku,  przegl

ądów  kominiarskich  i  kontroli  środowiskowych;-  Deklaracje  -  moduł 

umo

żliwia  składanie  formularzy  deklaracji;-  Dokumenty/Wnioski  -  moduł  umożliwia 

przegl

ądanie własnych dokumentów i wniosków;- Kalendarz;- Wiadomości.  

Uwagi  Odwołującego:  Ta  lista  nie  jest  tożsama  z  podobną  listą  w  dokumencie  OPZ 

i wydaje  si

ę  narzucać  szerszy  zakres  funkcjonalności.  Nie  wiadomo  więc,  która  wersja 

jest obowi

ązującą. Zakres w OPZ nie wspomina również o tym, że czynności w aplikacji 

mobilnej  maj

ą  odbywać  się  poprzez  „klikanie”  na  mapie,  co  może  nie  być  najlepszym 

rozwi

ązaniem UX na tak małym ekranie. 

34. REQ-F-11 

Moduł Administracyjny  

Opis  wymaga

ń:  System  musi  być  wyposażony  w  pulpit  administratora,  umożliwiający 

wykonywanie 

czynno

ści 

administracyjnych, 

szczególności 

zarz

ądzanie 

u

żytkownikami,  uprawnieniami,  konfiguracją,  w  tym  konfiguracją  przepływu  pracy, 

struktur

ą  organizacyjną  jednostki,  formularzami,  interfejsami  integracyjnymi,  a  także 

umo

żliwiający  podgląd  procesów  przepływu  pracy,  raportowanie,  wykrywanie  i 

rozwi

ązywanie typowych problemów z systemem. 

Uwagi  Odwołującego:  Brak  doprecyzowania  wymagań  w  zakresie  zarządzania: 

1. Konfiguracj

ą  2.  konfiguracją  przepływu  pracy  3.  Formularzami  4.  interfejsami 

integracyjnymi 

35.  REQ-F-22 

Moduł Administracyjny  

Opis  wymaga

ń:  Administrator  musi  mieć  możliwość  definiowania  ról  i  uprawnień 

w Systemie 

oraz przydzielania poszczególnych użytkowników lub grup użytkowników do 

zdefiniowanych ról.  

Uwagi  Odwołującego:    Brak  doprecyzowania,  jaka  jest  relacja  pomiędzy  "grupami 

u

żytkowników", a pozycjami w drzewie organizacji. Czy to jest to samo? 

36. REQ-F-23 

Moduł Administracyjny  

Opis wymagań: System powinien umożliwiać wielopoziomowe definiowanie uprawnień. 


Uwagi  Odwołującego:  Brak  doprecyzowania  wymagań  w  zakresie:  "wielopoziomowe 

definiowanie uprawnie

ń". Po WKR zostało dodane wyjaśnienie, w jakich modułach ma to 

by

ć możliwe, ale nie wiadomo, co oznacza "wielopoziomowe definiowanie uprawnień" 

37. REQ-F-236 

Moduł Administracyjny  

Opis  wymagań:  System  musi  udostępniać  jeden  uniwersalny  interfejs  komunikacji  dla 

Systemów  zewnętrznych.  Interfejs  będzie  umożliwiał  wywoływanie  głównych  funkcji 

Systemu.  Wykonawca  zobowi

ązany  jest  do  opisu  ww.  interfejsu  komunikacji. 

S

zczegółowy  zakres  komunikacji  zostanie  ustalony  pomiędzy  Zamawiającym 

a Wykonawc

ą w ramach projektowania Systemu.  

Uwagi Odwołującego: Brak jest wskazania konkretnych funkcji oraz jakie wymagania ma 

spe

łniać ten interfejs - wydajność, pojemność, rodzaj interfejsu, etc. 

38. REQ-F-109 Baza danych CEEB 

Opis  wymagań:  Centralna  Ewidencja  Budynków  Centralna  Ewidencja  Budynków  nie 

mo

że mieć ograniczenia rozmiaru bazy danych.  

Uwagi Odwołującego: Zapis tak sformułowany jest nierealizowalny 

39. REQ-F-106 Baza danych CEEB 

Opis  wymagań:  Centralna  Ewidencja  Budynków  nie  może  posiadać  ograniczeń 

licencyjnych  zwi

ązanych  z  rozbudową  infrastruktury  sprzętowej  (serwery  danych, 

dodatkowe procesory). 

Uwagi  Odwołującego:  Brak  jest  doprecyzowania  wymagania:  -  Czy  Wykonawca  ma 

dostarczy

ć  licencje  dla  oprogramowania  wchodzącego  w  skład  Systemu,  które 

uprawniaj

ą  Zamawiającego  do  wykorzystania  na  nieograniczonej  infrastrukturze 

sprz

ętowej?  -  Czy  Zamawiający  dopuszcza  wykorzystanie  oprogramowania 

standardowego, które będzie zapewniane jako usługi w chmurze i Zamawiający będzie 

rozlicza

ł  jego  wykorzystanie  w modelu  płatności  za  zużycie  czy  też  dostępną 

zdefiniowan

ą moc obliczeniową? 

40. REQ-F-100 Baza danych CEEB 

Opis  wymagań:  Centralna  Ewidencja  Budynków  musi  umożliwiać  deklarowanie 

wyzwalaczy 

(triggerów)  na  poziomie  instrukcji  DML  (INSERT,  UPDATE,  DELETE) 

wykonywanej  na  tabeli,  poziomie  ka

żdego  wiersza  modyfikowanego  przez  instrukcję 

DML oraz na poziomie zdarze

ń bazy danych (np. próba wykonania instrukcji DML, start 

serwera,  stop  serwera,  próba  zalogowania  Użytkownika,  wystąpienie  specyficznego 

b

łędu na serwerze). 

Uwagi  Odwołującego:  Zapis  rozumiany  literalnie  wyklucza  możliwość  wykorzystania 

szeroko  wykorzystywanego  w  tego  typu  rozwi

ązaniach  silnika  bazy  PostgreSQL,  które 

wprost  nie  ma  takiej  funkcji  (tj.  wyzwalaczy  after  startup,  before  logon,  on  error).  Brak 

jest uzasadnienia potrzeby dla takiego wymagania. 


41. REQ-F-99 Baza danych CEEB 

Opis  wymagań:  Centralna  Ewidencja  Budynków  musi  umożliwiać  kompilację  procedur 

sk

ładowanych w bazie do kodu binarnego (biblioteki dzielonej). 

Uwagi  Odwołującego:  Zapis  rozumiany  literalnie  istotnie  ogranicza  wybór  dostępnych 

baz  danych,  wyklucza  np.  mo

żliwość  wykorzystania  PostgreSQL,  który  wprost  nie  ma 

takiej funkcji. Brak jest uzasadnienia potrzeby dla takiego wymagania. 

42. REQ-F-92 Baza danych CEEB  

Opis  wymagań:  Centralna  Ewidencja  Budynków  musi  umożliwiać  odtworzenie  wielu 

aktywnych 

zbiorów rezultatów (zapytań, instrukcji DML) w jednej sesji bazy danych.  

Uwagi Odwołującego: Brak jest zdefiniowania/doprecyzowania terminu "odtworzenie".  

43. REQ-F-91 Baza danych CEEB 

Opis  wymagań:  Centralna  Ewidencja  Budynków  musi  umożliwiać  uruchomienie  wielu 

sesji  bazy  danych  przy  wykorzystaniu  jednego  po

łączenia  z  serwera  aplikacyjnego  do 

serwera bazy danych.  

Uwagi  Odwołującego:  Zapis  rozumiany  literalnie  wyklucza  możliwość  wykorzystania 

PostgreSQL, 

które wprost nie ma takiej funkcji, na rzecz rozwiązań Microsoftu. Brak jest 

uzasadnienia potrzeby dla takiego wymagania. 

44. REQ-F-360 

Moduł Analityczny  

Opis  wymagań:  Administrator  ma  możliwość  definiowania  parametrów  jakościowych 

i ilo

ściowych  kontroli  budynków  dla  gmin,  powiatów,  województw.  Definiowanie  ww. 

parametrów  odbywa  się  poprzez  wskazanie  pojedynczych  obiektów  lub  ich  grup  (np. 

wszystkich gmin z 

województwa).  

Uwagi  Odwołującego:  Brak  jest  wskazania  czy  to  wymaganie  powinno  zostać 

zrealizowane  w  ramach  Modu

łu  Analitycznego  (definiowanie  parametrów  zbieranych 

podczas  kontroli  mo

że  być  możliwe  również  przez  moduł  inwentaryzacji  albo  nie  być 

mo

żliwe do definiowania w aplikacji, a jedynie przez zmianę kodu systemu). 

45. REQ-F-240 

Moduł Analityczny 

Opis  wymagań:  Ilość  danych  w  raportach  musi  być  ograniczona  w  zależności  od 

uprawnie

ń użytkowników.  

Uwagi 

Odwołującego: Brak jest doprecyzowania na czym ma polegać ta reglamentacja. 

W ocenie Odwołującego powyższe braki wskazują, że obecne brzmienie SWZ narusza 

art. 99 ust. 1 i 4 w zw. z art. 16 ustawy Pzp. Wobec faktu, 

że z SWZ nie wynika zamknięty 

zakres  zobowi

ązania  wykonawcy  –  przedmiot  zamówienia  staje  się  –  w  sposób  sprzeczny 

z przepisem  art.  99  ust.  1  ustawy  Pzp  -  niejednoznaczny,  nieostry,  okre

ślony  w  sposób 

niedok

ładny.  Co  więcej,  można  powiedzieć,  że  przedmiot  zamówienia  został  przez 

Zamawiaj

ącego  opisany  w  sposób  otwarty.  Odwołujący  powołał  się  także  na  przykładowe 


orzeczenia  Krajowej  Izby  Odwo

ławczej  wskazujące,  że  określenie  przedmiotu  zamówienia 

sposób  pełny  i  jednoznaczny  jest  obowiązkiem  Zamawiającego:  wyrok  z  dnia  24  lutego 

2012  r.,  sygn.  KIO  302/12,  wyrok  z  dnia  24  lutego  2012  r.  KIO  318/12,  wyrok  z  dnia  10 

kwietnia 2012 r., sygn. KIO 550/12, wyrok z dnia 9 wrze

śnia 2010 roku, KIO 1832/10, wyrok 

z  dnia  14  stycznia  2013  r.  sygn.  akt  KIO  2888/12.  Skutek  takiego  nieostrego  opisania 

przedmiotu zamówienia jest  dla Odwołującego bardzo  poważny  –wobec faktu,  że  SWZ nie 

okre

śla w sposób zamknięty zakresu obowiązków wykonawcy, Odwołujący nie jest w stanie 

ani w sposób należyty sporządzić oferty, ani też nie jest w stanie wycenić swoich usług ani 

oszacowa

ć  ryzyk  związanych  z  realizacją  zamówienia.  Powoduje  to,  iż  przy  obecnym 

brzmieniu  SWZ  Odwo

łujący  nie  jest  w  stanie  złożyć  wiążącej  i  profesjonalnej  oferty. 

Wskazane  postanowienia  SWZ  naruszaj

ą  zatem  także  obowiązek  Zamawiającego 

uwzgl

ędnienia  w  opisie  przedmiotu  zamówienia  wszystkich  wymagań  i  okoliczności 

mog

ących mieć wpływ na sporządzenie oferty (art. 99 ust. 1 ustawy Pzp).  

Przedmiotowe  braki  SWZ 

zdaniem  Odwołującego  naruszają  także  przepis  art.  353

Kodeksu cywilnego w zwi

ązku z art. 8 ust. 1 ustawy Pzp. Gdyby przyjąć za uprawniony brak 

okre

ślenia  przez  Zamawiającego  przedmiotu  zamówienia  w  sposób  zamknięty, 

powodowa

łoby to, iż przedmiot umowy pozostawałby otwarty – a niewątpliwie przekracza to 

granice  swobody  umów,  gdyż  treść  takiego  stosunku  prawnego  sprzeciwiałaby  się  naturze 

tego stosunku, ustawie oraz zasadom współżycia społecznego. Oczywistym jest bowiem, że 

ka

żda  umowa  powinna  w  sposób  zamknięty  i  szczegółowy  określać  wszystkie  istotne 

obowi

ązki  stron.  Tymczasem  umowa  zawarta  na  podstawie  takiego  SWZ  nie  określałaby 

tych  istotnych  obowi

ązków.  Odwołujący  wskazał,  że  zakres  obowiązków  wykonawcy  to 

essentialia  negotii  umowy  o 

świadczenie  usług,  a  zatem  bez  jednoznacznego  określenia 

tego zakresu umowa w ogóle nie może dojść do skutku. Należy uznać, że umowa, w której 

Zamawiaj

ący  celowo  nie  określa  w  sposób  należyty  essentialia  negotii,  powinna  zostać 

uznana za umow

ę zarówno sprzeczną z ustawą, jak i taką, której celem jest obejście prawa 

(obowi

ązku  pełnego  i  należytego  opisania  przedmiotu  zamówienia).  Tym  samym  umowa 

taka zgodnie z art. 58 § 1 Kodeksu Cywilnego jest nieważna z mocy prawa. Byłby to skutek 

dla  Zamawiaj

ącego  bardzo  poważny.  Ograniczenie  zupełnej  swobody  Zamawiającego  w 

korzystaniu ze swobody umów uznała także za słuszne Krajowa Izba Odwoławcza w wyroku 

z  dnia  27  grudnia  2011  roku,  KIO  2649/11

.  Odwołujący wskazał,  iż  Zamawiający  w  swoich 

uprawnieniach i uznaniowo

ści jest jednak ograniczony, w szczególności nie jest uprawniony 

do  takiego  kszta

łtowania  treści  stosunku  prawnego,  który  byłby  korzystny  tylko  dla 

Zamawiaj

ącego i nakładał nieuzasadnione obowiązki na wykonawcę. Uznać zaś należy, że 

stworzenie  umowy  z  otwartym  zakresem  obowi

ązków  Wykonawcy  jest  właśnie  takim 

nadu

życiem. A zatem sprzeczne jest zarówno z art. 5, jak i art. 58 § 2 Kodeksu Cywilnego. 


Ustawodawca  uzna

ł  bowiem  za  nadużycie  prawa  (nie  korzystające  z  ochrony)  czynienie 

u

żytku  ze  swego  uprawnienia,  który  to  użytek  byłby  sprzeczny  z  zasadami  współżycia 

spo

łecznego  czy  też  ze  społeczno-gospodarczym  przeznaczeniem  takiego  uprawnienia.  Z 

kolei w art. 58 § 2 Kodeksu Cywilnego wskazano wprost, że umowa sprzeczna z zasadami 

współżycia  społecznego  jest  nieważna.  Zdaniem  Odwołującego  umowa,  w  której  zakres 

obowi

ązków  Wykonawcy  jest  otwarty  i  nieokreślony,  z całą  pewnością  jest  sprzeczna  z 

zasadami  współżycia  społecznego.  Ponadto  wynikający  z SWZ  zakres  zobowiązań 

wykonawcy  (tj.  zakres  otwarty)  powoduje, 

że  naruszona  zostaje  także  zasada 

ekwiwalentno

ści świadczeń stron wynikających z umowy wzajemnej wyrażona w art. 487 § 2 

Kodeksu  Cywilnego.  Trudno  tymczasem  mówić  ekwiwalentności  świadczeń  w sytuacji,  w 

której wykonawca kalkulując cenę swojej oferty nie jest w stanie odnieść jej do dającego się 

przewidzie

ć  zakresu  usług.  Także  brak  takiej  ekwiwalentności  oraz  ścisłego  określenia 

zakresu  obowi

ązków  wykonawcy  stanowi  zdaniem  Odwołującego  naruszenie  art.  5  k.c.  (w 

zwi

ązku z art. 8 ust. 1 ustawy Pzp).  

Odwołujący wniósł o modyfikację OPZ poprzez zdefiniowanie i doprecyzowanie zakres 

us

ług w miejscach wskazanych w odwołaniu. 

Zamawiający w dniu 15 października 2021 r. złożył pisemną odpowiedź na odwołanie. 

Wskazał, iż uwzględnia odwołanie w części, tj. co do zarzutów oznaczonych nr 38, 40, 41, 42 

i  43  tabeli  zawartej  w  odwołaniu  i  w  tym  zakresie  wniósł  o  umorzenie  postępowania 

odwoławczego. W pozostałym zakresie Zamawiający wniósł o oddalenie odwołania.  

Zamawiający  w  ramach  uwag  natury  ogólnej  wskazał,  że  przed  ogłoszeniem 

z

amówienia,  Zamawiający  przeprowadził  Wstępne  Konsultacje  Rynkowe  („  WKR”)  w  trybie 

art.  84  ustawy  Pzp

.  Przedmiotem  WKR  było  udzielenie  Zamawiającemu  informacji  o 

możliwych  rozwiązaniach  rynkowych  w  zakresie  zaprojektowania,  budowy  i  wdrożenia 

Systemu ZONE. Informacje dotyczyły w szczególności: zagadnień i rozwiązań technicznych, 

technologicznych,  wykonawczych,  organizacyjnych,  handlowych,  ekonomicznych  oraz 

logistycznych,  zw

iązanych  z  realizacją  przedmiotowego  zamówienia,  zgodnie  z  potrzebami 

Zamawiającego; ustalenia wartości planowanego zamówienia; zebrania informacji służących 

do  opracowania  dokumentacji  planowanego  zamówienia.  Informacja  o  zamiarze 

przeprowadzenia  WKR  zos

tała  umieszczona  14  lipca  2021  r.  na  stronie  internetowej 

Zamawiającego  https://www.gunb.gov.pl/.  Wraz  z  ww.  informacją  opublikowane  zostały 

następujące dokumenty: ogłoszenie o WKR, regulamin WKR, zgłoszenie do udziału w WKR 

oraz  opis  przedmiotu  konsultacj

i.  WKR  prowadzono  w  formie  spotkań  online  -  przy 

wykorzystaniu  środków  komunikacji  elektronicznej,  za  pośrednictwem  programu  Zoom. 

Spośród  7  (siedmiu)  podmiotów,  które  zgłosiły  chęć  udziału  w  WKR  w  wyznaczonym 

terminie znalazły się takie podmioty jak Odwołujący oraz Asseco Poland S.A. Zamawiający 


wskazał  na  ten  ostatni  podmiot,  albowiem  zarzuty  Odwołującego  podniesione  w  odwołaniu 

zostały w przeważającej mierze przygotowane w oparciu o pytania postawione przez Asseco 

Poland S.A. 

w toku WKR, które zostały wniesione w formie pisemnej w dniu 5 sierpnia 2021 

r.  (

jako  dowód  Zamawiający  załączył  protokół  z  WKR  oraz    materiały  przekazane  przez 

Asseco  Poland  S.A. 

z  dokładnym  określeniem  i  wyszczególnieniem  (kolor  żółty)  tej  części 

pytań, która została następnie wykorzystana przez Odwołującego składającego odwołanie w 

niniejszym  postępowaniu,  jako  własne  zarzuty).  Zamawiający  wskazał  link  do  strony,  na 

której dostępna jest całość dokumentacji z przeprowadzonych WKR.  

Ponadto  Zamawiający  wskazał,  że  na  skutek  przeprowadzonych  WKR,  w  tym  z 

udziałem m. in. Asseco Poland S.A. Zamawiający dokonał takich zmian i modyfikacji Opisu 

Przedmiotu Zamówienia lub jego załączników, które wynikały z pojawiających się pytań tego 

uczestnika  WKR  i  które  w  ocenie  Zamawiającego  doprecyzowały  ujęte  tam  wymagania. 

Najlepszym potwierdzeniem tej okoliczności pozostaje fakt w postaci braku odwołania, jak i 

nie przystąpienia po stronie Odwołującego w niniejszym postępowaniu przez Asseco Poland 

S.A.  

jako autora tych pytań. Nie bez znaczenia zdaniem Zamawiającego pozostaje również 

fakt,  że  w  oparciu  o  zmodyfikowaną  treść  Opisu  Przedmiotu  Zamówienia,  w  ramach 

prowadzonych WKR, uwzględniających już uprzednio zgłoszone „zarzuty odwoławcze” przez 

Asseco Poland 

S.A.. (w formie pytań o wyjaśnienia), sam Odwołujący dokonał szacunkowej 

wyceny  oferty  na  „Zaprojektowanie,  budowę  i  wdrożenie  systemu  ZONE”,  przedkładając  w 

dniu 26 sierpnia 2021 r. szacunek na kwotę 11.987.887,50 zł brutto. Zamawiający wskazał, 

że Odwołujący na etapie dokonywania wyceny usługi nie zgłosił żadnych wątpliwości, ani nie 

zwrócił się o wyjaśnienie jakichkolwiek zapisów Opisu Przedmiotu Zamówienia, co świadczy 

o  braku  zastrzeżeń  Odwołującego  do  treści  tego  Opisu.  Ponadto  przedstawiona  wartość 

usługi, która została wyceniona z dużą dokładnością potwierdza, że wszelkie elementy Opisu 

pozwalały na tak dokładną wycenę (jako dowód Zamawiający załączył  pismo Odwołującego 

z  dnia  26  sierpnia  2021  r.  - 

Szacunkowa  wycena  „Zaprojektowania,  budowy  i  wdrożenia 

Systemu  ZONE”.  Dodatkowo  Zamawiający  wskazał,  że  zarzuty  podniesione  w  odwołaniu, 

zostały po raz kolejny przekopiowane i wklejone do pytań Odwołującego o wyjaśnienie treści 

SWZ  zgłoszonych  Zamawiającemu  w  trybie  art.  135  ustawy  Pzp,  za  pismem  z  dnia  1 

października 2021 r. Okoliczność ta dodatkowo potwierdza prawidłowość sporządzenia opisu 

przedmiotu  zamówienia  przez  Zamawiającego,  która  wymaga  jedynie  stosownego 

wyjaśnienia zrozumienia projektowanych  wymagań  systemu  (de facto  poczynionych w toku 

WKR). 

Zamawiający załączył pismo Odwołującego z dnia 1 października 2021 r. 

Następnie  Zamawiający  przedstawił  stanowisko w  zakresie  poszczególnych  zarzutów 

formie tabeli, wskazując co do kolejnych punktów: 


1.  Zakres 

danych  ogranicza  się  do  zakresu  danych  gromadzonych  w  Systemie  ZONE. 

Sposób przekazywania danych do Systemu ZONE opisany jest w pkt 6.1.15 OPZ; 

Szczegółowe  wymagania  w  zakresie  Modułu  Analityczno-Raportowego  określone  są 

OPZ oraz w Załączniku nr 2 do OPZ, gdzie wskazane zostały rodzaje analiz, sposób 

prezentacji danych oraz opisana zo

stała analityka zastosowana w module. Zamawiający 

oczekuje  zapewnienia  uniwersalnego  narzędzia  umożliwiającego  tworzenie  analiz 

raportów ad-hoc, na podstawie źródeł danych zgromadzonych w CEEB. 

Zakres  modułu  szkoleniowego  określony  jest  w  Załączniku  nr  2  do  OPZ,  w  którym 

precyzyjnie  wskazano,  jakie  materiały  powinny  być  wytworzone  w  ramach  każdego 

modułów.  Biorąc  pod  uwagę  specyfikę  tworzonego  Systemu  ZONE  i  unikatowość 

każdego  z  modułów,  nie  jest  możliwe  na  tym  etapie  wskazanie  konkretnej  ilości 

materi

ałów 

szkoleniowych. 

Istotne 

pozostaje 

stworzenie 

takich 

materiałów 

szkoleniowych,  które  będą  odpowiadały  na  potrzeby  Zamawiającego,  przy  czym,  bez 

znaczenia pozostaje ilość dostarczonych materiałów szkoleniowych. Nie jest istotna ilość, 

a jakość dostarczonych materiałów. 

Zakres pobierania danych określony jest w punkcie 6.1.15 OPZ i wynika wprost z Ustawy 

z  dnia  28  października  2020  r.  o  zmianie  ustawy  o  wspieraniu  termomodernizacji 

remontów oraz niektórych innych ustaw (Dz. U. poz. 2127) oraz projektu rozporządzenia 

wykonawczego do tej ustawy. W OPZ jest wskazana liczba atrybutów i wag. 

W  OPZ  określone  jest,  iż  przeznaczeniem  podmodułu  jest  wprowadzanie  danych  do 

Systemu  ZONE  z  przeprowadzonej  kontroli  środowiskowej.  Podmoduł  nie  służy  do 

przep

rowadzania już zleconych kontroli czy wnioskowania o nie. 

1. w Załączniku nr 1 do OPZ określone są kolejne osoby, które mogą wprowadzać dane 

ramach  podmodułu  "Przegląd  kominiarski".  2.Zgodnie  z  OPZ  dane  dostępne 

podmodule "Przegląd kominiarski” będą widoczne w Module Analityczno-Raportowym. 

3.Dane  gromadzone  w  rejestrach  publicznych  należy  zabezpieczać,  wymieniać 

przechowywać  zgodnie  z  zasadami  określonymi  w  przepisach  prawa  powszechnie 

obowiązującego,  m.in.:  -  ustawą  z  dnia  5  lipca  2018  r.  o  krajowym  systemie 

cyberbezpieczeństwa  (Dz.  U.  z  2020  r.,  poz.  1369);  -  ustawą  z  dnia  10  maja  2018  r. 

ochronie  danych  osobowych  (Dz.  U.  z  2019  r.  poz.  1781,  z  późn.  zm.)  - 

rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram 

Interoper

acyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji 

w  postaci  elektronicznej  oraz  minimalnych  wymagań  dla  systemów  teleinformatycznych 

(Dz. U. z 

2017 r. poz. 2247, z późn. zm.). 

7.  1.Zgodnie  z  OPZ  System  ZONE(w  PUGU6-

001)  wysyła  potwierdzenie  zgłoszenia  do 

zarejestrowanego użytkownika. 2. W Załączniku nr 2 do OPZ w wymaganiu REF-F-352 

jest  wskazane,  iż  "Po  odebraniu  zgłoszenia  Kopciucha,  osoba  o  odpowiednich 


uprawnieniach  przesyłając  dalej  zgłoszenie  (czynność  pozasystemowa)  ma  możliwość 

zweryfikowania w terenie wskazanego zgłoszenia oraz jego opisania.” 

W  OPZ  określone  jest,  że:  "Geoportal  dodatkowo  umożliwia  wykonywanie 

standardowych  zapytań  i  analiz  przestrzennych  użytkownikom  z  poziomu  mapy  na 

zdefiniowanych  przez  administratora  da

nych  udostępnionych  przez  System  ZONE.” 

Poprzez  standardowe  analizy  przestrzenne  rozumie  się  m.in.:  -  selekcje  obiektów 

zawierających  się,  -  przecinających  się,  -nakładających  się,  przy  uwzględnieniu 

dodatkowo zadanych wartości  atrybutów.  Poprzez standardowe zapytania przestrzenne 

rozumie  się  operacje  pozwalające  na  określenie  m.in.:  odległości  pomiędzy  dwoma 

podanymi obiektami, -

części wspólnej obiektów, -stykanie się obiektów, -pokrywanie się 

obiektów. Zgodnie z punktem 6 OPZ "Ogólny opis architektury docelowego rozwiązania” 

Moduł GIS i Moduł Analityczno-Raportowy stanowią odrębne moduły Systemu ZONE. 

1. W OPZ opisane jest, iż: "Funkcjonalność serwera usług katalogowych realizowana jest 

poprzez  usługę  zgodną  ze  specyfikacją  z  normami  ISO  19115  i  ISO  19119  w 

najnowszych  wersjach.”  2-3.  Wymagany  przez  Zamawiającego  standard  do 

implementacji w ramach Serwera Usług Katalogowych to CSW 2.0.2 lub wyższy, a źródła 

dla importu w trybie 

harvestingu muszą być przedmiotem analizy Wykonawcy na Etapie l, 

z  zastrzeżeniem,  że  dostarczone  narzędzie  musi  mieć  możliwość  importu  Danych  w 

trybie harvestingu. 

1.Geoportal  powinien  być  dostępny  również  w  aplikacji  mobilnej,  w  zakresie  wymagań 

zdefiniowanych  w  załączniku  nr  2.  W  załączniku  nr  1  do  OPZ  w  Module  ZONE.App 

wskazany  jes

t  Geoportal  wraz  z  określeniem  uprawnień  poszczególnych  ról  w  ramach 

danej  instytucji  w  Systemie  ZONE.  2.  Zgodnie  z  Załącznikiem  nr  1  i  nr  2  do  OPZ 

ZONE.App  jest  aplikacją  instalowaną  na  urządzeniu  mobilnym  i  musi  być  zasilana 

treściami  pochodzącymi  z  Portalu  Systemu  ZONE.  Połączenia  i  zależności  pomiędzy 

podmodułem "Wiadomości” a pozostałymi komponentami Systemu ZONE określone są w 

punkcie 6 OPZ. 

1.  .W  OPZ  określone  jest,  iż  uniwersalne  API  powinno  obsłużyć  różne  typy  danych. 

2.Sposób postępowania w zakresie integracji określony jest w punkcie 6.1.15, wskazując 

na  wymianę  danych  ze  wskazanymi  w  tabeli  systemami.  3.W  OPZ  określone  jest,  iż: 

"Procedury  zbierania  i  walidacji  Danych  z  istniejących  źródeł  oraz  integracji  z  bazami 

danych  systemów  referencyjnych  zostały  określone  w  załączniku  nr  9,  który  stanowi 

punkt  odniesienia  w  stosunku  do  potrzeb  biznesowych  Zamawiającego.”  Zamawiający 

wyjaśnia,  iż  w  OPZ,  zgodnie  z  rozdziałem  6.1.15.  "Zewnętrzne  Systemy  referencyjne 

współpracujące  z  Systemem  ZONE”,  określone  jest,  iż  z  poziomu  Modułu  Analityczno-

Raportowego musi 

być generowany i przekazywany Raport o rozbieżnościach w danych. 


12. 1. W rozdziale 6.4 OPZ "E-

usługi Systemu ZONE” opisane jest, że e-usługi powinno się 

rozumieć  w  ujęciu  biznesowym.  Dana  e-usługa  może  być  realizowana  przez  kilka 

Modułów  funkcjonalnych.  Szczegółowe  zobrazowanie  wskazane  jest  w  rozdziale  6.4.5 

"Mapowanie  E-

usług  na komponenty  funkcjonalne Systemu ZONE”.  2.System  Zone  nie 

przewiduje  Modułu  "e-usług".  E-usługi  realizowane  przez  konkretne  moduły,  będą 

zapewniały  dane  wyjściowe  do  analizy  w  ramach  Modułu  Analityczno-Raportowego. 

Wymagania funkcjonalne Modułu Analityczno-Raportowego zostały określone w OPZ i w 

Załączniku nr 2 do OPZ. 3.W Załączniku nr 2 do OPZ znajduje się wymaganie REQ-F-

"Moduł  musi  umożliwiać  wysyłanie  zarejestrowanym  użytkownikom  wiadomości 

email o zbliżającym się terminie przeglądu kominiarskiego.” 4.W Załączniku nr 2 do OPZ 

znajduje  się  wymaganie  REQ-F-380.  "Dla  użytkowników  zarejestrowanych,  System 

ZONE musi umożliwiać zweryfikowanie na podstawie wprowadzonych danych czy dany 

kocioł  jest  zgodny  z wymaganiami  prawa  w  tym  uchwały  antysmogowej.”  5.W  OPZ  w 

punkcie 6.4.3. opisane jest, że w ramach Systemu ZONE nie przewiduje się komunikacji 

elektronicznej bezpośredniej pomiędzy użytkownikami. 

1.  W  OPZ  opisane  są  konkretne  Przypadki  Użycia  dotyczące  możliwości  Zamówienia 

przeglądu kominiarskiego, np. PU-GU1-007a 2-3.W OPZ w punkcie 6.1.9.6 opisane jest, 

iż:  Dokumenty/wnioski  obsługiwane  w  ramach  Systemu  ZONE  będą  się 

charakte

ryzowały unikalnym numerem identyfikacyjnym. W Załączniku nr 2 OPZ znajduje 

się  wymaganie  REQ-NF-82:  "Wszystkie  dokumenty  generowane  z  Systemu  ZONE 

muszą być generowane w formacie PDF wraz unikalnym numerem dokumentu oraz datą 

i godziną wygenerowania dokumentu.” 

1.  W  OPZ  znajdują  się  konkretne  Przypadki  Użycia  dotyczące  możliwości  zamówienia 

inwentaryzacji budynku, np. PU-GU2001. 2. W ramach OPZ w punkcie 6.1.9.6 jest zapis, 

iż:  "Dokumenty/wnioski  obsługiwane  w  ramach  Systemu  ZONE  będą  się 

charakteryzowały  unikalnym  numerem  identyfikacyjnym”.  W  Załączniku  nr  2  do  OPZ 

znajduje  się  wymaganie  REQ-NF-82:  "Wszystkie  dokumenty  generowane  z  Systemu 

ZONE  muszą  być  generowane  w  formacie  PDF  wraz  unikalnym  numerem  dokumentu 

oraz  datą  i  godziną  wygenerowania  dokumentu.”  Dane  gromadzone  w  rejestrach 

publicznych  należy  zabezpieczać,  wymieniać  i  przechowywać  zgodnie  z  zasadami 

określonymi w przepisach prawa powszechnie obowiązującego, m.in.: - ustawa z dnia 5 

lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz. U. z 2020 r., poz. 1369); - 

ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych (Dz. U. z 2019 r. poz. 1781, 

z  późn.  zm.);  -  rozporządzenie  Rady  Ministrów  z  dnia  12  kwietnia  2012  r.  w  sprawie 

Krajowych  Ram  Interoperacyjności,  minimalnych  wymagań  dla  rejestrów  publicznych  i 

wymiany  informacji  w  postaci  elektronicznej  oraz  minimalnych  wymagań  dla  systemów 

teleinformatycznych  (Dz.  U.  z 

2017 r. poz. 2247, z późn. zm.). Zgodnie z OPZ, zakłada 


się,  iż  System  ZONE  będzie  modularną  aplikacją,  składającą  się z  frontendu  w  postaci 

portalu  Web  GUI  (Portal  ZONE)  umożliwiającego  poprzez  przeglądarkę  internetową 

(protokół  https)  dostęp  do  usług  i funkcjonalności  realizowanych  przez  moduły  oraz 

komponenty. Założeniem Systemu ZONE, zgodnie z OPZ, jest to, aby e-usługi dostępne 

były  zarówno  z  poziomu  strony  internetowej  jak  i  aplikacji  mobilnej.  W  OPZ  w 

Przypadkach  Użycia  zdefiniowano  sposób  realizacji  danej  usługi  w  Systemie  ZONE.  W 

OPZ  opisane jest,  w jaki  sposób firmy  i  organy  administracji  rządowej  będą  obsługiwać 

CEEB. 

Zostały  przygotowane  dedykowane  Przypadki  Użycia,  które  są  częścią  OPZ. 

Sposób udostępniania danych wynika wprost z Ustawy z dnia 28 października 2020 r. o 

zmianie ustawy o wspieraniu termomodernizacji i remontów oraz niektórych innych ustaw 

(Dz.  U.  poz.  2

127)  oraz  projektu  rozporządzenia  wykonawczego  do  tej  ustawy,  jak 

również został opisany w OPZ (Moduł Analityczno-Raportowy) oraz m.in.: PU-GU3-001. 

1.W  OPZ  w  punkcie  6.1.15  opisane  jest,  jakie  dane  i  w  jakim  zakresie  muszą  zostać 

pozyskane do Systemu ZONE

. Przewidywana ilości gmin została oszacowana na około 

10% wszystkich gmin w Polsce, co powoduje, że około 250 jednostek posiada dane do 

zasilenia Systemu ZONE. W punkcie 6.1.15 OPZ opisane jest, iż dostęp do wskazanych 

systemów  referencyjnych  zostanie  zapewniony  przez  Zamawiającego  w  aspekcie 

formalno-

organizacyjnym  (np.  poprzez  podpisanie  stosownych  porozumień).  2.W  OPZ 

punkcie  7  opisane  jest,  iż  dane  w  systemie  MVP  ZONE  mają  formę  elektroniczną. 

3.W 

OPZ w punkcie 6.1.15 opisane jest, iż: "Dostęp do wskazanych systemów zostanie 

zapewniony  przez:  Zamawiającego  w  aspekcie  formalno-organizacyjnym  (np.  poprzez 

podpisanie  stosownych  porozumień);  Wykonawcę  w  aspekcie  warstwy  technicznej.”  

W ramach  zaplanowanej  integracji  i  migracji  dojdzie  do  pozyskania  danych 

Zewnętrznych Systemów Referencyjnych. 

16. 1.  Z  uwagi  na  uwarunkowania  prawne  Systemu  ZONE  i  jego  publiczny  charakter, 

Zamawiający  oczekuje,  aby  wszystkie  wymagania  niefunkcjonalne  zostały  spełnione. 

Brak  spełnienia  chociażby  jednego  wymagania  niefunkcjonalnego  oznaczać  będzie 

wystąpienie  błędu  krytycznego.  2.Poprzez  istotną  funkcjonalność  Zamawiający  rozumie 

taką  funkcjonalność,  której  brak  spełnienia  uniemożliwi  realizację  głównych  procesów 

Systemu ZONE. 

Z treści OPZ wynika, iż platforma rozumiana jest jako moduł elearningowy. 

Opracowanie  zasad  aktualizacji  danych  referencyjnych  będzie  przedmiotem  analizy 

wykonanej przez Wykonawcę w Etapie I oraz na podstawie Załącznika nr 8 do OPZ. Brak 

wskazania konkretnego Przypadku Użycia uniemożliwia odniesienie się Zamawiającego 

do zarzutu. 

Wylistowane  zagadnienia  dotyczą  sposobu  wykorzystywania  narzędzia  przez 

administratora, a nie budowy tego narzędzia, do którego zobowiązany jest Wykonawca. 


Odwołujący powołuje się na nieaktualne brzmienie wymagania REQ-F-320. Wymaganie 

REQ-F-

320  stanowi:  "Dla  Portalu  ZONE,  musi  istnieć  możliwość  dostosowywania 

wyglądu,  treści  oraz  funkcjonalności  w  zależności  od  roli  użytkownika  końcowego. 

Automatyczne  dostosowywanie  się  funkcjonalności  Portalu  ZONE  realizowane  jest  na 

podstawie r

ól i uprawnień przyznanych użytkownikowi.” 

1. .W wymaganiu opisane jest, iż wersja na systemy mobilne będzie zawierała wyłącznie 

wybrane funkcjonalności, które zapewnią jej prawidłowe funkcjonowanie na urządzeniach 

przenośnych.  Określenie  listy  funkcjonalności  będzie  zobowiązaniem  Wykonawcy 

ramach realizacji Etapu l. 2.Wersja na systemy mobilne powinna zostać zrealizowana 

jako  natywna  aplikacja  mobilna.  Wymagania  określone  w  Załączniku  nr  2  do  OPZ,  np. 

REQ-F29  oraz  REQ-F-

30 wskazują,  iż  aplikacja będzie dostępna  w  systemach Android 

(wersja 6.0 i nowsze), iOS (wersja 10 i nowsze) oraz iPadOS. 

22. System  ZONE  nie  powinien 

posiadać  ograniczeń  licencyjnych.  W  Załączniku  nr  2  do 

OPZ  w  wymaganiu  REQ-NF-

33  wskazane  jest,  iż  System  musi  umożliwiać  wydajną 

p

racę dla 500 jednocześnie pracujących użytkowników. 

Dane  przechowywane  na  dysku  urządzenia  mobilnego  należy  zabezpieczać  zgodnie 

z zasadami 

określonymi  w  przepisach  prawa  powszechnie  obowiązującego,  m.in.: 

ustawą z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (Dz. U. z 2020 

r.,  poz.  1369);  ustawą  z  dnia  10  maja  2018  r.  o  ochronie  danych  osobowych  (Dz.  U.  z 

2019  r.  poz.  1781,  z  późn.  zm.)  -  rozporządzeniem  Rady  Ministrów  z  dnia  12  kwietnia 

2012  r.  w  sprawie  Krajowych  Ram  Interoperacyjności,  minimalnych  wymagań  dla 

rejestrów  publicznych  i wymiany  informacji  w  postaci  elektronicznej  oraz  minimalnych 

wymagań  dla systemów  teleinformatycznych  (Dz.  U.  z  2017  r.  poz.  2247, z  późn.  zm.). 

Wymagania  związane  z weryfikacją tożsamości użytkownika są  określone w  Załączniku 

nr 2 do OPZ m.in. w REQ-F-

36 "Logowanie do aplikacji mobilnej odbywa się za pomocą 

tych  samych  danych,  co  do  Systemu  ZONE.  Zdefiniowanie  wymagań  związanych  z 

szyfrowaniem i 

zabezpieczeniem danych przechowywanych na urządzeniu mobilnym jest 

zobowiązaniem Wykonawcy w ramach Etapu l. 

W  Załączniku  nr  2  do  OPZ  w  wymaganiu  REQ-F-39  określone  jest:  "Aplikacja  będzie 

posiadała  przynajmniej  poniższe  grupy  funkcjonalne:  Inwentaryzacja  budynku  -służy  do 

przeprowadzania  inwentaryzacji  budynku,  przeglądów  kominiarskich,  kontroli 

środowiskowych  i  kontroli  kopciuchów.  Grupa  udostępnia  informacje  zapisane  w  CEEB 

umożliwia  wprowadzanie  danych  przy  zastosowaniu  formularzy;  -  Geoportal  - 

prezentuje  w  formie  graficznej  wszystkie  budynki.  Z  poziomu  mapy  można  zobaczyć 

informację  o obiekcie,  wybrać  obiekty  za  pomocą  wskazania,  analizy  przestrzennej  lub 

atrybutowej. Użytkownik klika w wyszukany na mapie budynek i zostaje przeniesiony na 

szczegóły  budynku.  Na  tym  widoku  użytkownik  zobaczy  informację  przeprowadzonych 


dotychczas inwentaryzacji budynku, przeglądów kominiarskich i kontroli środowiskowych; 

Deklaracje - 

umożliwia składanie formularzy deklaracji; Dokumenty/ Wnioski - umożliwia 

przeglądanie własnych dokumentów i wniosków; - Kalendarz; Wiadomości.” Załącznik nr 

2 do OPZ należy traktować jako dokument doprecyzowujący OPZ. Rozwiązania UX będą 

przedmiotem analizy na etapie wdrażania System ZONE. 

Odwołujący  odnosi  się  do  wymagania  w  brzmieniu,  które  nie  znajduje  się  w  aktualnym 

Załączniku nr 2 do OPZ. Aktualne brzmienie wymagania REQ-F-II to: "System musi być 

wyposażony  w  pulpit  administratora,  umożliwiający  wykonywanie  czynności 

administracyjnych,  w  szczególności  zarządzanie  użytkownikami,  uprawnieniami, 

konfiguracją  Systemu,  strukturą  organizacyjną  jednostki,  formularzami  i  danymi 

formularzy,  interfejsami  integracyjnymi,  a  także  umożliwiający  podgląd  procesów 

przepływu  pracy,  raportowanie,  wykrywanie  i  rozwiązywanie  typowych  problemów 

systemem.” 

Odwołujący  odnosi  się  do  wymagania  w  brzmieniu,  które  nie  znajduje  się  w  aktualnym 

Załączniku nr 2 do OPZ. Wymaganie REQ-F-22 to: "Administrator musi mieć możliwość 

definiowania  ról  i  uprawnień  w  Systemie  oraz  przydzielania  poszczególnych 

użytkowników lub wskazanych użytkowników do zdefiniowanych ról.” 

36. Wielopo

ziomowe  definiowanie  uprawnień  opisane  jest  w  Załączniku  nr  2  do  OPZ 

w wymaganiach  REQ-F-24  do  REQ-F27.  Poprzez  wielopoziomowe  definiowanie 

uprawnie 

Zamawiający rozumie definiowanie macierzy uprawnień. 

Funkcją  wskazanego  interfejsu  jest  zapewnienie  komunikacji  dla  Systemów 

Zewnętrznych  i  umożliwienie  wywoływania  głównych  funkcji  Systemu.  Systemy 

Zewnętrzne  opisane  są  w  punkcie  6.1.15  OPZ  i  na  podstawie  tych  informacji, 

Wykonawca powinien zaproponować określone rozwiązanie. 

Kwestie  licencji  zostały  określone  w  Projektowanych  Postanowieniach  Umowy  w  512. 

Zamawiający  nie  dopuszcza  wykorzystania  oprogramowania  standardowego.  które 

będzie  generowało  koszty  z  tytułu  opłat  licencyjnych  po  stronie  Zamawiającego 

przyszłości. 

Wymaganie powinno zostać zrealizowane w ramach Modułu Analityczno-Raportowego. 

W  Załączniku  nr  2  do  OPZ  w  wymaganiu  REQ-F-240  określona  jest  kwestia 

ograniczenia uprawnień użytkowników. "Ilość danych w raportach musi być ograniczona 

w  zależności  od  uprawnień  użytkowników  np.  ograniczenia  w  zależności  od 

przynależności  terytorialnej.”  Zakres  danych  udostępnianych  poszczególnym 

użytkownikom został określony w projekcie rozporządzenia wykonawczego do Ustawy z 

dnia  28  października  2020  r.  o  zmianie  ustawy  o  wspieraniu  termomodernizacji  i 

remontów  oraz  niektórych  innych  ustaw  (Dz.  U.  poz.  2127).”  System  ZONE  musi 

prezentować  różnym  użytkownikom,  różną  ilość  Danych  w  zależności  od  posiadanych 


uprawnień  np.  niektóre  uprawnienia  użytkowników  nie  mają  dostępu  do  danych 

osobowych. 

Po przeprowadzeniu rozprawy z 

udziałem Stron i Uczestników postępowania, na 

podstawie  zgromadzonego  w sprawie 

materiału  dowodowego,  Krajowa  Izba 

Odwoławcza ustaliła i zważyła, co następuje: 

Wobec spełnienia wymogów określonych art. 525 ust. 1-3 ustawy Pzp Izba uznała za 

skuteczne  zgłoszenie  przystąpienia  dokonane  przez  wykonawcę  Agileme  Spółka 

ograniczoną  odpowiedzialnością  z  siedzibą  w Suwałkach  po  stronie  odwołującego,  jak 

przez wykonawcę WASKO Spółka Akcyjna z siedzibą w Gliwicach po stronie odwołującego. 

Przystępujący  nie  stawili  się  na  posiedzeniu  przed  Izbą,  prawidłowo  zawiadomieni  o  jego 

terminie.  

Izba  stwierdziła,  iż  nie  została  wypełniona  żadna  z  przesłanek  skutkujących 

odrzuceniem odwołania na podstawie art. 528 ustawy Pzp. 

Izba na podstawie art. 568 pkt 1 w zw. z art. 520 ustawy Pzp umorzyła postępowanie 

odwoławcze  w  zakresie  zarzutów  wycofanych  przez  Odwołującego,  tj.  dotyczących 

postanowień OPZ wskazanych w pkt 5, pkt 7, pkt 12 ppkt 1 i 4, pkt 13 ppkt 2 i 3, pkt 15 ppkt 

2, pkt 17, pkt 19, pkt 20 tabeli zawartej w 

uzasadnieniu odwołania. 

Izba na podstawie 568 pkt 3 w zw. z art. 522 ust. 4 ustawy Pzp umorzyła postępowanie 

odwoławcze  w zakresie  zarzutów  uwzględnionych  przez  Zamawiającego,  tj.  dotyczących 

postanowień  OPZ  wskazanych  w  pkt  38,  pkt  40,  pkt  41,  pkt  42  i  pkt  43  tabeli  zawartej 

uzasadnieniu odwołania. 

Izba  uznała,  iż  Odwołujący  wypełnił  materialnoprawne  przesłanki  dopuszczalności 

odwołania,  o których mowa  w  art.  505  ust.  1  ustawy  Pzp.  Zgodnie  z  tym  przepisem  środki 

ochrony  prawnej  określone  w  niniejszym  dziale  przysługują  wykonawcy,  uczestnikowi 

konkursu  oraz  innemu  podmiotowi,  jeżeli  ma  lub  miał  interes  w  uzyskaniu  zamówienia  lub 

nagrody  w 

konkursie  oraz  poniósł  lub  może  ponieść  szkodę  w  wyniku  naruszenia  przez 

zama

wiającego  przepisów  ustawy.  W  przypadku  odwołań  dotyczących  ogłoszenia 

wszczynającego  postępowanie  o  udzielenie  zamówienia  lub  ogłoszenia  o  konkursie  oraz 

dokumentów  zamówienia  przyjąć  należy,  iż  każdy  wykonawca  deklarujący  zainteresowanie 

uzyskaniem  daneg

o  zamówienia  posiada  jednocześnie  interes  w jego  uzyskaniu,  a  szkodą 

tym  wypadku  może  być  brak  możliwości  złożenia  oferty.  Mając  na  względzie,  iż 

Odwołujący  deklarował  zainteresowanie  przedmiotowym  postępowaniem,  Izba  uznała,  iż 

treść  dokumentów  zamówienia,  w tym  opisu  przedmiotu  zamówienia, mogły  przekładać  się 

na 

jego sytuację w postępowaniu i możliwość złożenia konkurencyjnej oferty, wobec czego 

nie sposób odmówić Odwołującemu legitymacji czynnej do złożenia odwołania. 


Izba  dokonała  ustaleń  faktycznych  w  oparciu  o  dokumentację  postępowania  o 

udzielenie  zamówienia  przekazaną  przez  Zamawiającego,  w  szczególności  ogłoszenie  o 

zamówieniu,  SWZ,  modyfikacje  ogłoszenia  o  zamówieniu  i  SWZ,  wyjaśnienia  udzielone 

przez Zamawiającego w odpowiedzi na pytania wykonawców do treści SWZ. Izba dopuściła 

przeprowadziła  ponadto  dowody  z dokumentów  załączonych  przez  Zamawiającego  do 

odpowiedzi na odwołanie dotyczących przeprowadzonych wstępnych konsultacji rynkowych 

oraz złożonego przez Zamawiającego na rozprawie dowodu z dokumentu potwierdzającego 

liczbę  zarejestrowanych  na  platformie  zamówieniowej  wykonawców  zainteresowanych 

udziałem w przedmiotowym postępowaniu, na okoliczności wskazane przez Zamawiającego.  

Izba 

zważyła,  że  treść  zaskarżonych  postanowień  opisu  przedmiotu  zamówienia  nie 

była  pomiędzy  stronami  sporna,  została  ona  przytoczona  w  odwołaniu  i  odpowiedzi  na 

odwołanie, na co wskazano szczegółowo powyżej.  

Biorąc pod uwagę zgromadzony w sprawie materiał dowodowy, poczynione ustalenia 

faktyczne oraz orzekając w granicach zarzutów zawartych w odwołaniu, Izba stwierdziła, iż 

odwołanie nie zasługuje na uwzględnienie. 

Izba  uznała  zarzuty  odwołania,  tj.  zarzut  naruszenia  art.  99  ust.  1  w  zw.  z  art.  16 

ustawy  Pzp  poprzez  opisanie  przedmiotu  zamówienia  w sposób  niejednoznaczny  i 

niewyczerpuj

ący,  bez  uwzględnienia  wszystkich  wymagań  i okoliczności  mogących  mieć 

wp

ływ  na  sporządzenie  oferty,  co  narusza  zasady  proporcjonalności,  zapewnienia 

zachowania uczciw

ej konkurencji oraz równego traktowania wykonawców (zarzut nr 1) oraz 

naruszenia  art.  99  ust.  4  w  zw.  z  art.  16  ustawy  Pzp  poprzez  opisanie  przedmiotu 

zamówienia  w sposób  utrudniający  uczciwą  konkurencję  oraz  naruszający  zasady 

proporcjonalno

ści, zapewnienia zachowania uczciwej konkurencji oraz równego traktowania 

wykonawców (zarzut nr 2), za niezasadne. 

Zgodnie  z  art.  99  ust.  1  ustawy  Pzp 

przedmiot  zamówienia  opisuje  się  w  sposób 

jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń, 

uwzględniając wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty. Ust. 4 

tego  przepisu  stanowi,  że  przedmiotu  zamówienia  nie  można  opisywać  w  sposób,  który 

mógłby  utrudniać  uczciwą  konkurencję,  w  szczególności  przez  wskazanie  znaków 

towarowych,  patentów  lub  pochodzenia,  źródła  lub  szczególnego  procesu,  który 

charakteryzuje  produkty  lub  usługi  dostarczane  przez  konkretnego  wykonawcę,  jeżeli 

mogłoby  to  doprowadzić  do  uprzywilejowania  lub  wyeliminowania  niektórych  wykonawców 

lub produktów. Zgodnie zaś z art. 16 ustawy Pzp  Zamawiający przygotowuje i przeprowadza 

postępowanie  o  udzielenie  zamówienia  w  sposób:  1)  zapewniający  zachowanie  uczciwej 

konkurencji oraz równe traktowanie wykonawców; 2) przejrzysty; 3) proporcjonalny. 


Od

nosząc  się  w  pierwszej  kolejności  do  drugiego  z  zarzutów  odwołania  należy 

wskazać, że w treści  odwołania,  poza powołaniem  się w opisie zarzutu nr  2  na  naruszenie 

art.  99  ust.  4  ustawy  Pzp  poprzez  opisanie  przedmiotu  zamówienia  w  sposób  utrudniający 

uczciw

ą konkurencję, Odwołujący nie przedstawił żadnego uzasadnienia faktycznego w tym 

przedmiocie. 

W  ramach uwag  Odwołującego  do poszczególnych  wymagań  OPZ zawartych 

w tabeli  przedstawionej  w 

odwołaniu,  nie  wskazano,  aby  którekolwiek  zakwestionowane 

wymaganie  OPZ 

zostało  opisane  w  sposób  charakteryzujący  usługi  dostarczane  przez 

konkretnego  wykonawcę,  czy  mogący  w inny  sposób  prowadzić  do  uprzywilejowania  lub 

wyeliminowania  niektórych  wykonawców  lub  produktów,  a  zatem  w sposób  który 

wyczerpywałby  dyspozycję  art.  99  ust.  4  ustawy  Pzp.  Okoliczności,  które  mogłyby 

wskazywać  na  powyższe  (aczkolwiek mające  bardzo  ogólny charakter)    zawarto  jedynie  w 

pkt 40, 41 i 43 tabeli, jednak 

postępowanie odwoławcze w tym zakresie zostało umorzone z 

uwagi na uwzględnienie przez Zamawiającego zarzutów w odniesieniu do ww. punktów. W 

pozostałych  punktach  tabeli  przedstawionej  na  str.  3-16  odwołania,  Odwołujący  zwracał 

jedynie  uwagę  na  niedoprecyzowanie  wymagań  czy  też  brak  przekazania  przez 

Zamawiającego dostatecznych informacji, nie wskazywał jednak, aby sposób ukształtowania 

zaskarżonych  wymagań  OPZ  potencjalnie  utrudniać  mógł  konkurencję,  uprzywilejowując 

sytuację  jednych  wykonawców  względem  drugich.  Tym  samym,  wobec  braku  wykazania 

przesłanek,  o  których  mowa  w  art.  99  ust.  4  w  zw.  z  art.  16  ustawy  Pzp,  zarzut  nr  2 

odwołania Izba uznała za bezzasadny.  

W  tym  miejscu 

należy  podkreślić  wagę,  jaką  dla  wyniku  postępowania  ma  sposób 

skonstruowania  podstaw  faktycznych  stawianych  zarzutów.  Treść  zarzutu  nie  jest 

ograniczona  wyłącznie  do  twierdzeń  zawartych  we  wstępnej  części  odwołania  (petitum),  a 

dotyczy również okoliczności faktycznych zawartych w sformułowanym przez Odwołującego 

uzasadnieniu zarzutów. Odwołanie powinno wyrażać zastrzeżenia wobec dokonanych przez 

zamawiającego  czynności  lub  zaniechań,  co  oznacza  obowiązek  zaprezentowania  przez 

odwołującego  nie  tylko  podstawy  prawnej  takich  zastrzeżeń,  ale  przede  wszystkim 

argumentacji odnoszącej się do postulowanej oceny (por. m.in. wyrok z dnia 3 czerwca 2020 

r., sygn. akt KIO 401/20 i KIO 403/20). P

odstawa faktyczna zarzutu powinna odnosić się do 

wykazania  konkretnych  przyczyn,  które  zdaniem  Odwołującego  świadczyć  mają  o  tym,  że 

doszło  do  naruszenia  przepisów  ustawy  Pzp  –  Odwołujący  powinien  więc  przestawić 

argu

mentację, dlaczego dane postanowienie OPZ narusza przywołane w odwołaniu przepisy 

ustawy  Pzp. 

Nie  jest  zatem  wystarczające  zwrócenie  uwagi  na  istnienie  określonego 

problemu,  lecz  niezbędne  jest  przedstawienie  argumentacji,  dlaczego  dane  okoliczności 

świadczyć  mają  o  naruszenia  wskazanych  przepisów  prawa.  Granice  rozpoznania  sprawy 


przez Izbę są ściśle określone przez zarzuty odwołania, na co wskazuje art. 555 ustawy Pzp, 

zgodnie z którym Izba nie może orzekać co do zarzutów, które nie były zawarte w odwołaniu.  

Powyższa uwaga odnosi się nie tylko do wskazanego powyżej zarzutu nr 2, lecz także 

do  pierwszego  z  zarzutów  odwołania,  tj.  zarzutu  naruszenia  art.  99  ust.  1  w  zw.  z  art.  16 

ustawy  Pzp. 

Odwołujący,  kwestionując  postanowienia  OPZ,  powinien  przestawić 

ar

gumentację, dlaczego konkretne wymaganie narusza wskazane przepisy prawa. W ocenie 

składu orzekającego Odwołujący, w stosunku do żadnego ze wskazanych w tabeli wymagań 

OPZ

,  nie  tyle  nie  wykazał,  co  nawet  nie  uprawdopodobnił,  że  naruszać  one  mogą 

przywołane powyżej przepisy, uniemożliwiając prawidłowe sporządzenie oferty i jej wycenę. 

Zdecydowanie  za  niewystarczające  uznać  należy  poprzestanie  na  przywołaniu  przepisów 

prawa  w  petitum 

odwołania,  a  następnie  przedstawienie  w  końcowej  części  odwołania 

ogólnych wywodów z przytoczeniem orzecznictwa odnoszących się do sposobu opisywania 

przedmiotu zamówienia. Całość argumentacji mającej wskazywać na naruszenie art. 99 ust. 

1  ustawy  Pzp 

sprowadzała  się  do  stwierdzenia,  iż  Odwołujący  nie  jest  w  stanie  wycenić 

swoich  usług  ani  oszacować  ryzyk  związanych  z  realizacją  zamówienia  i  nie  jest  w  stanie 

złożyć  wiążącej  i  profesjonalnej  oferty  oraz  do  stwierdzenia,  że  przedmiot  zamówienia  ma 

ch

arakter  otwarty,  co  przekraczać  ma  granice  swobody  umów  i  naruszać  zasadę 

ekwiwalentności świadczeń stron. Tak postawione tezy o ogólnym charakterze nie zostały w 

żaden sposób odniesione do konkretnych wymagań OPZ, które wskazano w tabeli na str. 3-

odwołania.  Wywody  te  nie  referują  w  ogóle  do  stanu  faktycznego  sprawy  i  niewątpliwie 

posłużyć  mogą  na  potrzeby  niejednego  odwołania,  w  którym  kwestionowane  są 

postanowienia  opisu  przedmiotu  zamówienia.  Odwołujący  nie  przedstawił  konstruktywnego 

uzasadnienia,  dlaczego 

sposób  opisania  wymagań  zawartych  w  OPZ  czyni  złożenie  oferty 

niemożliwym czy obarczonym ryzykiem.  

Z  kolei  w  ramach  uwag  zawartych  w  tabeli  na  str.  3-

16  odwołania  Odwołujący 

każdorazowo poprzestawał na wskazaniu, że przywołane wymaganie OPZ nie precyzuje czy 

nie wyjaśnia pewnych kwestii, nie wskazuje przykładów lub nie definiuje pojęć. Odwołujący 

nie  przedstawił  natomiast  merytorycznej  argumentacji,  dlaczego  te  określone  dane  czy 

informacje,  których  zdaniem  Odwołującego  brakuje,  mają  wpływ  na  prawidłowe 

przygotowanie  oferty  i 

czynią  opis  przedmiotu  zamówienia  niedostatecznym  z  perspektywy 

profesjonalnego  uczestnika  rynku,  jakim  jest  Odwołujący.  Podkreślić  należy,  że  samo 

lakoniczne  wskazanie,  że  dane  zagadnienie  nie  zostało  przez  Zamawiającego  opisane  w 

OPZ w aż tak szczegółowym stopniu, w jakim życzyłby sobie tego Odwołujący, nie wykazuje, 

że  opis  przedmiotu  zamówienia  sporządzono  w  sposób  niejednoznaczny  czy 

niewyczerpujący  lub  bez  uwzględnienia  wymagań  i  okoliczności  mogących  mieć  wpływ  na 

sporządzenie oferty. Kwestionując postanowienia OPZ wykonawca powinien wykazać jakich 


konkretnie  informacji  Z

amawiający  nie  przekazał  wykonawcom  w  SWZ,  dlaczego  są  one 

istotne 

dla  należytego  przygotowania  oferty  i  wyceny  przedmiotu  zamówienia  i  jakie 

skonkretyzowane  ryzyka  występują  po  stronie  wykonawcy  z  tytuły  nieprzekazania  takich 

informacji. 

Odwołujący obowiązkowi temu nie sprostał. 

Co  istotne,  jak  zauważył  Zamawiający,  w  przedmiotowej  sprawie  uwagi  zawarte 

w od

wołaniu,  stanowiły  powielenie  pytań  zgłoszonych  Zamawiającemu  przez  jednego 

wykonawców  jeszcze  w  ramach  wstępnych  konsultacji  rynkowych,  w  których  udział  brał 

także  Odwołujący.  Odwołujący  pominął  okoliczność,  że  w  efekcie  wstępnych  konsultacji 

rynkowych 

Zamawiający dokonał modyfikacji opisu przedmiotu zamówienia, doprecyzowując 

ujęte  tam  wymagania.  Potwierdzają  to  załączone  przez  Zamawiającego  do  odpowiedzi  na 

odwołanie  dokumenty  –  pytania  zgłoszone  przez  jednego  z  wykonawców,  a  także  protokół 

ze  wstępnych  konsultacji  rynkowych,  w  którym  w  pkt  V  przedstawiono  obszerne 

podsumowanie  wpływu  tych  konsultacji  na  planowane  postępowanie  na  zaprojektowanie, 

budowę i wdrożenie systemu Zone w zakresie opisu przedmiotu zamówienia. Dokumentacja 

ze wstępnych konsultacji rynkowych została przez Zamawiającego udostępniona wszystkim 

zainteresowanym  podmiotom  na  stronie  internetowej  Zamawiającego.  Powielenie  pytań 

składanych  na  etapie  wstępnych  konsultacji  rynkowych  w  sytuacji,  gdy  opis  przedmiotu 

zamówienia  uległ  zmianie  z  założenia  jest  działaniem  nieprawidłowym,  opartym  na  nie  w 

pełni  aktualnych  danych.  Izba  zgodziła  się  z  Zamawiającym,  że  Odwołujący  nie 

przeprowadził  dostatecznej  analizy  postanowień  OPZ,  co  potwierdza  treść  odpowiedzi  na 

odwołanie  -  Zamawiający  odnosząc  się do  każdej  z  uwag Odwołującego  wskazujących,  że 

OPZ nie doprecyzowano określonych informacji, przywołał konkretne elementy OPZ, gdzie 

te  informacje  się  znajdują.  Jako  przykład  można  wskazać  tu  także  argumentację 

Odwołującego  prezentowaną na  rozprawie  w  zakresie  zarzutu z  pkt  16  tabeli  - Odwołujący 

podniósł,  iż  opisy  błędów  nie  zostały  przez  Zamawiającego  zdefiniowane,  w  sytuacji  gdy  w 

pkt 8.3 OPZ zdefiniowano wszelkie kategorie błędów. Podobnie w zakresie zarzutów z pkt 11 

i  1  tabeli,  Zamawiający  odesłał  do  pkt  6.1.15  OPZ,  gdzie  zawarto  dane,  na  brak  których 

wskazywał Odwołujący w swoich uwagach. 

Izba  stwierdziła  ponadto,  iż  Odwołujący  podczas  rozprawy,  reagując  na  stanowisko 

Zamawiającego kiedy okazało się, że wskazane w odwołaniu braki zostały w OPZ opisane, 

poszukiwał  dalszych  okoliczności,  które  jego  zdaniem  należałoby  jeszcze  bardziej 

doprecyzować. Przykładowo w zakresie zarzutów z pkt 1 i 11 tabeli Odwołujący podnosił, że 

dane  zawarte  we  wskazanym  przez  Zamawiającego  pkt  6.1.15  OPZ  nie  są  dostatecznie 

szczegółowe,  jednak  nie  wyjaśnił  dlaczego  nie  są  one  wystarczające  do  przygotowania 

oferty.  Jak 

słusznie  zauważył  Zamawiający,  idąc  tokiem  rozumowania  Odwołującego,  OPZ 

n

igdy  nie  będzie  miał  takiego  stopnia  szczegółowości,  jakiego  oczekuje  Odwołujący. 


Oczekiwania  Odwołującego  co  do  doprecyzowania  każdego,  najmniejszego  detalu  nie  są 

zatem  usprawiedliwione,  a  ponadto  stoją  w  sprzeczności  z  założeniami  przedmiotu 

zamówienia,  który  obejmuje  nie  tylko  wdrożenie  systemu,  ale  i  jego  zaprojektowanie,  jak 

również  analizę  przedwdrożeniową  (Etap  I),  mającą  na  celu  zaproponowanie  i  wskazanie 

najlepszego 

sposobu 

realizacji 

zamówienia 

uwzględnieniem 

wszystkich 

tematów/zagadnień  wymienionych  w  OPZ  (pkt  5  OPZ).  Co  więcej,  Odwołujący  zaczął 

podczas  rozprawy 

podważać  zasadność  takiej  formuły  realizacji  projektu  wskazując,  że 

dopiero  wyniki 

tej  części  analitycznej  będą  możliwe  do  wykorzystania  w części  wytwórczej, 

wskazywał  też  na  przyjęcie  niewłaściwego  w  jego  ocenie  modelu  zarządzania 

przedmiotowym  projektem.  Okoliczności  te  jednak  nie  stanowiły  podstaw  faktycznych 

zarzutów  odwołania,  a  jako  takie  nie mogły  podlegać  rozpoznaniu  przez  Izbę.  Ponadto  nie 

zostało w żaden sposób wyjaśnione dlaczego dla podmiotu profesjonalnego, trudniącego się 

projektowaniem,  wdrożeniem,  utrzymaniem  systemów  informatycznych,  jakim  niewątpliwie 

jest Odwołujący i jakimi są pozostali wykonawcy ubiegający się o udzielenie zamówienia, tak 

ukształtowana  treść  OPZ  nie  jest  dostateczna,  nie  uwzględnia  wymagań  i okoliczności 

mogących mieć wpływ na sporządzenie oferty.  

Izba  zgodziła  się  także  z  Zamawiającym,  iż  trudno  uznać  za  wiarygodne  twierdzenia 

Odwołującego  o  braku możliwości  dokonania  prawidłowej  wyceny  oferty, skoro Odwołujący 

zna przedmiotowy projekt i 

dokonał szacunkowej wyceny na potrzeby wstępnych konsultacji 

rynkowych,  a  aktualnie  opis  przedmiotu  zamówienia  został  przez  Zamawiającego 

doprecyzowany  względem  tego,  jaki  był  przedmiotem  konsultacji,  po  uwzględnieniu  uwag 

zgłoszonych  wówczas  przez  wykonawców.  Stanowisko  Odwołującego  o  niemożliwości 

przygotowania of

erty z uwagi na brak dostatecznych danych poddaje w wątpliwość również 

fakt, iż przedmiotem zamówienia jest wykonanie rejestru państwowego opartego o regulacje 

ustawowe  oraz    informacje  publicznie  dostępne.  Jak  wskazano  w  pkt  2.1  OPZ    jedną 

przyczyn  podjęcia  projektu  jest  nowelizacja  ustawy  termomodernizacyjnej,  powołująca  do 

życia nowy rejestr państwowy - CEEB. Z kolei zgodnie z pkt 2.2. OPZ System ZONE ma być 

ogólnopolskim  systemem  teleinformatycznym,  w  którym  zaplanowano  stworzenie  e-usług 

umożliwiających  obywatelom  i  przedsiębiorcom  spełnienie  ich  obowiązków,  np.  wykonanie 

przeglądu  kominiarskiego  czy  dokonanie  inwentaryzacji  budynku,  a  także  umożliwią 

odbiorcom  efektywniej  zarządzać  wydatkami  przeznaczonymi  na  ogrzewanie  swoich 

budynków.(…)  Dane  pozyskane  w  ramach  e-usług,  tj.  informacje  o  cechach  budynku, 

sposobie  ogrzewania  budynku,  rodzaju  stosowanego  opału  będą  gromadzone  w  CEEB, 

który  jest  jednym  z elementów  Systemu  ZONE.  W  tym  stanie  rzeczy  odesłanie  przez 

Zamawiającego  w  OPZ  do  konkretnych  instytucji,  ustaw  czy  aktów  wykonawczych  w 

zakresie danych, jakie będą w systemie przetwarzane, jest usprawiedliwione. 


Jak już wskazano powyżej, Odwołujący nie przedstawił  merytorycznego uzasadnienia 

dlaczego  uszczegółowienie  OPZ  o  dodatkowe  elementy  wskazane  w  odwołaniu  jest 

niezbędne  dla  prawidłowego  przygotowania  oferty.  Rozważana  dotyczące  naruszenia 

przepisów  ustawy  Pzp  przedstawiono  jedynie  w  sposób  ogólny,  w  zdecydowanej  mierze 

poprzez cytowanie poglądów orzecznictwa, bez odniesienia ich do konkretnych postanowień 

OPZ,  które  Odwołujący  kwestionował.  Wywody  ogólne  o  tym,  że  Odwołujący  nie  jest  w 

stanie  sporządzić  oferty  czy  oszacować  ryzyk  związanych  z  realizacją  zamówienia  nie 

znalazły  konkretnego  przełożenia  na  zaskarżone  postanowienia  OPZ.  Tymczasem  ogólna 

retoryka  Odwołującego  o  braku  danych,  definicji  czy  przykładów  nie  stanowi  wykazania 

naruszenia art. 99 ust. 1 w zw. z art. 16 ustawy Pzp. 

To obowiązkiem Odwołującego było taki 

stan  rzeczy  udowodnić,  Odwołujący  jednak  ani  nie  przedstawił  w  tym  zakresie  stosownej 

argumentacji,  ani  nie  złożył  żadnych  dowodów.  Zgodnie  z  ogólną  zasadą  rozkładu  ciężaru 

dowodu  wynikającą  z  art.  534  ust.  1  ustawy  Pzp  (zgodnie  z  którym  strony  i  uczestnicy 

postępowania  odwoławczego  są  obowiązani  wskazywać  dowody  dla  stwierdzenia  faktów, 

których  wywodzą  skutki  prawne),  to  Odwołującego  obciąża  obowiązek  wykazania 

zasadności  stawianych  zarzutów,  gdyż  to  Odwołujący  wywodzi  ze  sposobu  ukształtowania 

wymagań  dotyczących  przedmiotu  zamówienia  skutek  w  postaci  naruszenia  przez 

Zamawiającego  przepisów  ustawy  Pzp.  Zaniechanie  podjęcia  stosownej  inicjatywy 

dowodowej  przez  podmiot  inicjujący  postępowanie  odwoławcze  (wnoszący  odwołanie), 

wiąże się co do zasady z negatywnymi konsekwencjami procesowymi dla tego podmiotu.  

Na  gruncie  przedmiotowej  sprawy  wskazać  także  należy,  że  odwołania  dotyczące 

postanowień  SWZ,  tak  jak  dotyczące  każdej  innej  czynności  lub  zaniechania 

Zamawiającego,  służą  ochronie  wykonawców  przed  działaniami  niezgodnymi  z  przepisami 

prawa,  a  Izba  mo

że  uwzględnić  odwołanie  wyłącznie  w sytuacji,  gdy  stwierdzi  naruszenie 

przez  Zamawiającego  przepisów  ustawy  mające  wpływ  lub  mogące  mieć  istotny  wpływ  na 

wynik  postępowania (art.  554 ust.  1 pkt  1  ustawy  Pzp).  Rolą środków  ochrony prawnej  nie 

jest  minimalizowanie  wszelkich  ryzyk 

istniejących  po  stronie  wykonawców  czy 

doprowadzenie  do  udogodnienia, 

czy  ułatwienia  im  realizacji  zamówienia.  Odwołanie  służy 

konwalidacji  sprzecznych  z  prawem  czynności  zamawiającego,  które  stają  na  drodze 

wykonawcom  podczas 

ubiegania  się  o zamówienie  publiczne.  Przede  wszystkim  zaś 

odwołanie nie służy prowadzeniu negocjacji z Zamawiającym co do treści postanowień SWZ 

czy też rozwianiu wątpliwości pojawiających się po stronie wykonawcy. Temu co do zasady 

służy  instytucja  wyjaśnień  treści  SWZ  –  to  wyjaśnienia  Zamawiającego  udzielane  w 

odpowiedzi na pytania wykonawców mają rozwiać potencjalne wątpliwości pojawiające się u 

wykonawców podczas analizy dokumentów zamówienia, wyeliminować możliwe nieścisłości, 

doprecyzować  treść  SWZ.  Natomiast  środki  ochrony  prawnej  służą  sanowaniu  działań  lub 


zaniechań  zamawiającego,  które  są  niezgodne  z  ustawą  Pzp.  W  ocenie  Izby  konstrukcja 

uwag zgłoszonych w odwołaniu wskazuje, że opis przedmiotu zamówienia co najwyżej mógł 

wymagać pewnego wyjaśnienia, wytłumaczenia zawartych w nim wymagań, niż że mamy tu 

do  czynienia  z  naruszeniem 

przez  Zamawiającego  przepisów  ustawy  Pzp.  Potwierdza  to 

fakt, że tożsame uwagi Odwołujący zgłosił Zamawiającemu w ramach wniosku o wyjaśnienie 

treści  SWZ  w  dniu  1  października  2021  r.  Co  istotne,  Zamawiający  na  pytania  te  udzielił 

odpowiedzi  w  dniu  15  października  2021  r.,  a zatem  na  moment  zamknięcia  rozprawy 

wątpliwości sygnalizowane w treści odwołania zostały przez Zamawiającego już wyjaśnione, 

co  samo  w  sobie  wskazuje 

na fakt, że zarzuty te zdezaktualizowały się.  Zgodnie bowiem z 

art. 552 ust. 1 ustawy Pzp wydając wyrok, Izba bierze za podstawę stan rzeczy ustalony w 

toku postępowania odwoławczego.  

Niezależnie  od  powyższego,  nie  mniej  ważną  kwestią,  która  wpłynęła  na 

rozstrzygnięcie Izby, był brak skonkretyzowania żądań odwołania. Izba miała na uwadze, że 

Odwołujący  w petitum  odwołania  jedynie  wskazał,  iż  wnosi  o  nakazanie  Zamawiającemu 

„dokonania  modyfikacji  SWZ  w  sposób  wskazany  w  odwołaniu  –  szczegółowo  w  każdym 

zarzucie.”  Podobnie  na  ostatniej  stronie  odwołania  wskazano,  iż  Odwołujący  wnosi  o 

nakazanie Zamawiającemu „modyfikację OPZ poprzez zdefiniowanie i doprecyzowanie usług 

miejscach  wskazanych  w  odwołaniu”.  Jednocześnie  w  zawartej  w  uzasadnieniu  tabeli 

odnoszącej  się  do  poszczególnych  wymagań  OPZ  Odwołujący  nie  przedstawił  żadnych 

konkretnych żądań co do zmian, jakie Izba maiłaby nakazać Zamawiającemu w treści OPZ. 

Ich treść Izba mogłaby jedynie wywodzić w sposób dorozumiany, w oparciu o przedstawione 

w tabeli uwagi, które miały raczej charakter pytań, zastrzeżeń, wątpliwości, niż wskazania na 

konkretne  naruszenia 

przepisów  prawa.  Sposobu  eliminacji  tych  potencjalnych  naruszeń 

ogóle  nie  wskazano,  co  prowadzi  do  sytuacji,  w  której  Izba  uwzględniając  odwołanie 

musiałaby  domniemywać,  jakie  zmiany  w  OPZ  satysfakcjonowałyby  Odwołującego. 

Podkreślić należy, że to obowiązkiem wykonawcy, a nie rolą Izby, jest precyzowanie żądań, 

które uczynią zadość jego interesom w przypadku uwzględnienia odwołania, a jednocześnie 

prowadzić  będą  do  eliminacji  stwierdzonego  naruszenia  przepisów  ustawy  Pzp.  Co  więcej, 

po

dniesione żądania winny być na tyle precyzyjne, aby można było w wyroku - w przypadku 

uznania ich zasadności nakazać Zamawiającemu dokonanie konkretnej zmiany treści SWZ. 

Podkreślić  należy,  że  w  przypadku  odwołań  wobec  treści  warunków  zamówienia 

skonkretyzowanie  żądań  odwołania  ma  znaczenie  zasadnicze,  nie  mniejsze  niż 

skonkretyzowanie  zarzutów  odwołania,  ocena  zasadności  zarzutu  następuje  bowiem  przez 

pryzmat  skorelowanych  z  nim  żądań.  W przedmiotowym  przypadku  konkretne  żądania  w 

ogóle  nie  zostały  przedstawione,  nie  mówiąc  już  o  tym,  że  wymaga  się  ich  precyzyjnego 

formułowania. 


Mając  na  uwadze  wszystko  powyższe  Izba  uznała,  że  odwołanie  podlega  oddaleniu 

całości i na podstawie art. 553 ustawy Pzp orzekła jak w sentencji. 

O  kosztach 

postępowania  odwoławczego  orzeczono  stosownie  do  jego  wyniku  na 

podstawie  art.  557  i  575  ustawy  Pzp  oraz 

§    8  ust.  2  w  zw.  z  §  5  pkt  1    Rozporządzenia 

Prezesa  Rady  Ministrów  w  sprawie  szczegółowych  rodzajów  kosztów  postępowania 

odwoławczego,  ich  rozliczania  oraz  wysokości  i  sposobu  pobierania  wpisu  od  odwołania  z 

dnia 30 grudnia 2020 r. (Dz. U. z 2020 r. poz. 2437). 

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