rodzaj: WYROK
data dokumentu: 2021-10-19
rok: 2021
data dokumentu: 2021-10-19
rok: 2021
sygnatury akt.:
KIO 2820/21
KIO 2820/21
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
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:
1.
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
w
uzasadnieniu odwołania;
2. oddala
odwołanie;
3.
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
o
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
o
zamówieniu, zarzucając Zamawiającemu naruszenie:
1. 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 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
w
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
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:
1.
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
i
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
z
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
z
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?
15.
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?
17.
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.
18.
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
z
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,
w
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
w
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
1
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
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;
2.
Szczegółowe wymagania w zakresie Modułu Analityczno-Raportowego określone są
w
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
i
raportów ad-hoc, na podstawie źródeł danych zgromadzonych w CEEB.
3.
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
z
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.
4.
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
i
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.
5.
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.
6.
1. w Załączniku nr 1 do OPZ określone są kolejne osoby, które mogą wprowadzać dane
w
ramach podmodułu "Przegląd kominiarski". 2.Zgodnie z OPZ dane dostępne
w
podmodule "Przegląd kominiarski” będą widoczne w Module Analityczno-Raportowym.
3.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.: - 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
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.”
8.
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.
9.
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.
10.
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.
11.
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-
379.
"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.
13.
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.”
14.
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.
15.
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
w
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
z
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.
17.
Z treści OPZ wynika, iż platforma rozumiana jest jako moduł elearningowy.
18.
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.
19.
Wylistowane zagadnienia dotyczą sposobu wykorzystywania narzędzia przez
administratora, a nie budowy tego narzędzia, do którego zobowiązany jest Wykonawca.
20.
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.”
21.
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
w
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.
32.
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.
33.
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
i
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.
34.
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
z
systemem.”
35.
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ń.
37.
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.
39.
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
w
przyszłości.
44.
Wymaganie powinno zostać zrealizowane w ramach Modułu Analityczno-Raportowego.
45.
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
z
ograniczoną odpowiedzialnością z siedzibą w Suwałkach po stronie odwołującego, jak
i
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
w
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ą
w
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
i
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-
16
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
z
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
w
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
z
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ą
z
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,
z
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
w
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ń
w
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
w
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: ……………………………….………
1.
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
w
uzasadnieniu odwołania;
2. oddala
odwołanie;
3.
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
o
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
o
zamówieniu, zarzucając Zamawiającemu naruszenie:
1. 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 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
w
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
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:
1.
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
i
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
z
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
z
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?
15.
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?
17.
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.
18.
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
z
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,
w
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
w
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
1
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
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;
2.
Szczegółowe wymagania w zakresie Modułu Analityczno-Raportowego określone są
w
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
i
raportów ad-hoc, na podstawie źródeł danych zgromadzonych w CEEB.
3.
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
z
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.
4.
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
i
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.
5.
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.
6.
1. w Załączniku nr 1 do OPZ określone są kolejne osoby, które mogą wprowadzać dane
w
ramach podmodułu "Przegląd kominiarski". 2.Zgodnie z OPZ dane dostępne
w
podmodule "Przegląd kominiarski” będą widoczne w Module Analityczno-Raportowym.
3.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.: - 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
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.”
8.
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.
9.
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.
10.
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.
11.
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-
379.
"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.
13.
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.”
14.
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.
15.
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
w
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
z
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.
17.
Z treści OPZ wynika, iż platforma rozumiana jest jako moduł elearningowy.
18.
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.
19.
Wylistowane zagadnienia dotyczą sposobu wykorzystywania narzędzia przez
administratora, a nie budowy tego narzędzia, do którego zobowiązany jest Wykonawca.
20.
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.”
21.
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
w
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.
32.
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.
33.
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
i
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.
34.
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
z
systemem.”
35.
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ń.
37.
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.
39.
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
w
przyszłości.
44.
Wymaganie powinno zostać zrealizowane w ramach Modułu Analityczno-Raportowego.
45.
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
z
ograniczoną odpowiedzialnością z siedzibą w Suwałkach po stronie odwołującego, jak
i
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
w
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ą
w
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
i
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-
16
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
z
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
w
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
z
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ą
z
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,
z
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
w
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ń
w
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
w
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: ……………………………….………
Wcześniejsze orzeczenia:
- Sygn. akt KIO 211/22 z dnia 2022-02-18
- Sygn. akt KIO 206/22 z dnia 2022-02-15
- Sygn. akt KIO 66/22, KIO 79/22 z dnia 2022-02-01
- Sygn. akt KIO 72/22 z dnia 2022-01-31
- Sygn. akt KIO 30/22 z dnia 2022-01-31
