sygn. akt: KIO 3445/21, KIO 3447/21
WYROK
z dnia 29 grudnia 2021 r.
Krajowa Izba Odwoławcza - w składzie:
Przewodniczący:
Emil Kuriata
Członkowie:
Aneta Mlącka
Monika Szymanowska
Protokolant:
Adam Skowroński
po rozpoznaniu na rozprawie w dniach: 7, 15 i 22 grudnia 2021 r., w Warszawie,
odwołań
wniesionych do Preze
sa Krajowej Izby Odwoławczej:
a) w dniu 25 listopada 2021 r. przez
wykonawcę Asseco Poland S.A. z siedzibą
w Rzeszowie (KIO 3445/21)
b) w dniu 25 listopada 2021
r. przez wykonawcę Comarch Polska S.A. z siedzibą
w Krakowie (KIO 3447/21)
w postępowaniu prowadzonym przez zamawiającego Agencja Restrukturyzacji
i Modernizacji Rolnictwa, A
l. Jana Pawła II 70; 00-175 Warszawa,
przy udziale:
a) wykonawcy Asseco Poland S.A.
z siedzibą w Rzeszowie - zgłaszającego
przystąpienie do postępowania odwoławczego - po stronie odwołującego (KIO
b) wykonawcy Comarch Polska S.A.
z siedzibą w Krakowie - zgłaszającego
przystąpienie do postępowania odwoławczego - po stronie odwołującego (KIO
orzeka:
Umarza postępowanie odwoławcze w zakresie zarzutów uwzględnionych przez
zamawiającego i wycofanych przez odwołującego (KIO 3445/21).
Uwzględnia odwołanie w zakresie zarzutu nr 2 odwołania i nakazuje zamawiającemu
dokonanie zmiany warunk
u udziału w postępowaniu dotyczącego doświadczenia
i zastąpienie obecnej treści warunku następującą „Rozdział III pkt. III.2 ppkt. 1.1.1.3.
zamówienia były wykonane dla: Agencji Restrukturyzacji i Modernizacji Rolnictwa lub
innych instytucji lub instytucji finansowyc
h, przez co należy rozumieć: przedsiębiorstwo
inne niż instytucja, którego podstawową działalnością jest nabywanie pakietów akcji lub
wykonywanie co najmniej jednego spośród rodzajów działalności wymienionych w pkt 2–
12 i pkt 15 załącznika I do dyrektywy 2013/36/UE, pojęcie to obejmuje finansowe spółki
holdingowe, finansowe
spółki holdingowe o działalności mieszanej, instytucje płatnicze w
rozumieniu dyrektywy 2007/64/WE Parlamentu Europejskiego i Rady z dnia 13 listopada
2007 r.
w sprawie usług płatniczych w ramach rynku (1) i spółki zarządzania aktywami, nie
obejmuje jednak ubezpieczenio
wych spółek holdingowych i ubezpieczeniowych spółek
holdingowych prowadzących działalność mieszaną” oraz zmianę pozostałych
postanowień SWZ, będących konsekwencją dokonanej zmiany (KIO 3445/21).
Umarza postępowanie odwoławcze w zakresie zarzutów uwzględnionych przez
zamawiającego i wycofanych przez odwołującego (KIO 3447/21).
Uwzględnia odwołanie w zakresie zarzutu dotyczącego warunku udziału
w postępowaniu i dokonanie zmiany warunku udziału w postępowaniu dotyczącego
doświadczenia i zastąpienie obecnej treści warunku następującą „Rozdział III pkt.
III.2 ppkt.
1.1.1.3. zamówienia były wykonane dla: Agencji Restrukturyzacji i Modernizacji
Rolnictwa lub innych instytucji lub instytucji
finansowych, przez co należy rozumieć:
przedsiębiorstwo inne niż instytucja, którego podstawową działalnością jest nabywanie
pakietów akcji lub wykonywanie co najmniej jednego spośród rodzajów działalności
wymienionych w pkt 2
–12 i pkt 15 załącznika I do dyrektywy 2013/36/UE, pojęcie to
obejmuje finansowe spółki holdingowe, finansowe spółki holdingowe o działalności
mieszanej, instytucje płatnicze w rozumieniu dyrektywy 2007/64/WE Parlamentu
Europejskiego i Rady z dnia 13 listopada 2007 r. w
sprawie usług płatniczych w ramach
rynku (1) i spółki zarządzania aktywami, nie obejmuje jednak ubezpieczeniowych spółek
holdingowych i ubezpieczeniowych spółek holdingowych prowadzących działalność
mieszaną” oraz zmianę pozostałych postanowień SWZ, będących konsekwencją
dokonanej zmiany. (KIO 3447/21).
W pozostałym zakresie zarzuty odwołania oddala (KIO 3447/21).
6. K
osztami postępowania obciąża: wykonawcę Comarch Polska S.A. z siedzibą
w Krakowie oraz
zamawiającego Agencja Restrukturyzacji i Modernizacji Rolnictwa
z siedzibą w Warszawie i:
.1. zalicza w poczet kosztów postępowania odwoławczego kwotę 30 000 zł 00 gr
(słownie: trzydzieści tysięcy złotych zero groszy) uiszczoną przez wykonawców:
a) Asseco Poland S.A.
z siedzibą w Rzeszowie (15.000,00 zł), b) Comarch
Polska S.A.
z siedzibą w Krakowie (15.000,00 zł), tytułem wpisu od odwołań,
zasądza od zamawiającego Agencja Restrukturyzacji i Modernizacji Rolnictwa
z siedzibą w Warszawie na rzecz wykonawcy Asseco Poland S.A. z siedzibą
w Rzeszowie,
kwotę 18 600 zł 00 gr (słownie: osiemnaście tysięcy sześćset
złotych, zero groszy) stanowiącą koszty postępowania odwoławczego poniesione
z tytułu wpisu od odwołania oraz wynagrodzenia pełnomocnika (KIO 3445/21).
zasądza od zamawiającego Agencja Restrukturyzacji i Modernizacji Rolnictwa
z siedzibą w Warszawie na rzecz wykonawcy Comarch Polska S.A. z siedzibą
w Krakowie,
kwotę 9 300 zł 00 gr (słownie: dziewięć tysięcy trzysta złotych, zero
groszy) stanowiącą ½ kosztów postępowania odwoławczego poniesionych z tytułu
wpisu od odwo
łania oraz wynagrodzenia pełnomocnika (KIO 3447/21).
Stoso
wnie do art. 579 ust. 1 i art. 580 ust. 1 i 2 ustawy z dnia 11 września 2019 r. Prawo
zam
ówień publicznych (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:
…………………………
Członkowie:
…………………………
…………………………
sygn. akt: KIO 3445/21, KIO 3447/21
Uzasadnienie
Zamawiający – Agencja Restrukturyzacji i Modernizacji Rolnictwa, prowadzi
postępowanie o udzielenie zamówienia publicznego, którego przedmiotem jest „Budowa
systemu CSOB wraz z wdrożeniem oraz usługą utrzymania i rozwoju, wraz z dostarczeniem
sprzętu i oprogramowania wspierającego”.
Ogłoszenie o zamówieniu zostało opublikowane w Dzienniku Urzędowym Unii
Europejskiej z dnia 15 listopada 2021 r., pod nr 2021/S 221-582815.
Zamawiający prowadzi postępowanie o udzielenie zamówienia publicznego
z zastosowani
em przepisów ustawy Prawo zamówień publicznych wymaganych przy
procedurze, której wartość szacunkowa zamówienia przekracza kwoty określone
w przepisach wydanych na podstawie art. 3
ustawy Prawo zamówień publicznych.
KIO 3445/21
Dnia 25 listopada 2021 roku wykonawca Asseco Poland S.A.
z siedzibą w Rzeszowie
(dalej „Odwołujący”) wniósł odwołanie do Prezesa Krajowej Izby Odwoławczej od niezgodnej
z przepisami u
stawy czynności zamawiającego polegającej na sformułowaniu Ogłoszenia
oraz Specyfikacji Warunków Zamówienia (dalej „SWZ”) z naruszeniem przepisów prawa.
Odwołujący zarzucił zamawiającemu naruszenie:
1. art. 99 ust. 1 ustawy Pzp,
poprzez opisanie przedmiotu zamówienia, w tym
obowiązków wykonawcy w sposób niejednoznaczny, niewystarczający, niepełny,
niejasny,
który uniemożliwia przygotowanie oferty, co stanowi prowadzenie
postępowania z naruszeniem zasad Prawa zamówień publicznych, tj. z naruszeniem
zasady zachowania uczciwej konkurencji, zasady równego traktowania wykonawców,
zasady proporcj
onalności oraz zasady przejrzystości,
2. art. 99 ust. 2 ustawy Pzp,
poprzez opisanie przedmiotu zamówienia poprzez
wskazanie cech dostaw, które nie są związane z przedmiotem zamówienia oraz nie są
proporcjonalne do jego wartości i celów,
3. art. 99 ust. 4 ustawy Pzp, poprzez opisanie przedmiotu za
mówienia w sposób mogący
utrudniać uczciwą konkurencję, co prowadzi do uprzywilejowania lub wyeliminowania
niektórych wykonawców,
4. art. 134 ust. 1 pkt 18) w zw. z art. 240 ust. 1 oraz ust. 2 ustawy Pzp, poprzez
określenie pozacenowych kryteriów oceny ofert w sposób pozostawiający
z
amawiającemu nieograniczoną swobodę wyboru oferty najkorzystniejszej,
uniemożliwiający ich należytą weryfikację i porównanie poziomu oferowanego
wykonania przedmiotu umowy oraz z naruszeniem zasady p
rzejrzystości,
5. art. 112 ust. 1 ustawy Pzp,
poprzez ustalenie warunków udziału w postępowaniu
w sposób nieproporcjonalny do przedmiotu zamówienia i niezwiązany z przedmiotem
zamówienia,
6. art. 471, art. 473, art. 353
KC w zw. z art. 431 oraz art. 433 ustawy Pzp, poprzez
określenie odpowiedzialności kontraktowej wykonawcy niezgodnie zasadami prawa
cywilnego przy naruszeniu zasady swobody umów,
7. art. 99 ust. 1
w związku z art. 16 ustawy Pzp oraz w związku z art. 44 ust. 3 ustawy
z dnia 27 sierpnia 2009 r. o finansach publicznych poprzez opisanie przedmiotu
zamówienia w sposób naruszający zasadę celowego i oszczędnego wydatkowania
środków publicznych, z zachowaniem zasady uzyskiwania najlepszych efektów
z danych nakładów oraz doboru optymalnych środków,
art. 483 § 1, art. 484 § 2, art. 353
K
C w związku z art. 431 i 433 pkt 2 ustawy Pzp,
poprzez zastrzeżenie w umowie kar umownych w wysokości rażąco wysokiej
względem sankcjonowanego naruszenia,
9. art. 431, art. 433 pkt 4 ustawy Pzp, art. 353
w związku z art. 644 KC, poprzez
przyznanie
z
amawiającemu możliwości zrezygnowania z realizacji umowy
w całkowicie nieograniczonym zakresie,
10. art. 16 ustawy Pzp,
w związku z w/w przepisami poprzez prowadzenie postępowania
z naruszeniem zasad Prawa zamówień publicznych, tj. z naruszeniem zasady
zachowania ucz
ciwej konkurencji, zasady równego traktowania wykonawców, zasadą
proporcjonalności oraz przejrzystości.
W związku z powyższym odwołujący wniósł o:
uwzględnienie odwołania,
dokonania modyfikacji Ogłoszenia i SWZ w zakresie wskazanym w odwołaniu –
szczegółowo w każdym zarzucie,
obciążenie zamawiającego kosztami postępowania odwoławczego, w tym kosztami
zastępstwa procesowego przed Krajową Izbą Odwoławczą.
Odwołujący wskazał, że ma interes we wniesieniu odwołania, gdyż wskazane
w odwołaniu niezgodne z prawem postanowienia SWZ powodują, że odwołujący nie ma
możliwości złożenia najkorzystniejszej oferty i tym samym utraci szansę na uzyskanie
zamówienia. Odwołujący może zatem ponieść szkodę w wyniku naruszenia przez
z
amawiającego przepisów ustawy Pzp wskazanych w odwołaniu. Gdyby nie sprzeczność
z prawem objętych odwołaniem postanowień SWZ, odwołujący mógłby złożyć
najkorzystniejszą ofertę, uzyskać zamówienie – a następnie należycie realizować
zamówienie. Ustalenie przez zamawiającego przedmiotowej treści SWZ, uniemożliwia
o
dwołującemu udział w postępowaniu. Interes odwołującego polega też na tym, że obecnie
postępowanie obarczone jest istotną wadą, a zatem w przypadku braku zmian SWZ
wskazanych w odwołaniu – konieczne będzie unieważnienie postępowania. Takie
unie
ważnienie naraziłoby odwołującego na poniesienie szkody – odwołujący zainwestował
już bowiem czas i środki na przygotowanie się do złożenia oferty w niniejszym
postępowaniu.
Izba ustaliła i zważyła, co następuje.
Izba stwierdziła, że nie zachodzą przesłanki do odrzucenia odwołania, o których stanowi
przepis art. 528 ustawy Pzp.
Krajowa Izba Odwoławcza stwierdziła, że odwołujący posiada interes w uzyskaniu
przedmiotowego zamówienia, kwalifikowanego możliwością poniesienia szkody w wyniku
naruszenia przez za
mawiającego przepisów ustawy, o których mowa w art. 505 ust. 1
ustawy Pzp
, co uprawniało go do złożenia odwołania.
W procesie wymiany pism procesowych oraz przeprowadzonych posiedzeń, strony –
odpowiednio
złożyły oświadczenia o: uwzględnieniu zarzutów odwołania (zamawiający) oraz
wycofaniu zarzutów (odwołujący). Część z zarzutów w związku z wprowadzonymi przez
zamawiającego modyfikacjami SWZ podlegała również umorzeniu – jako bezprzedmiotowe –
odwołujący nie zakwestionował poprawności wprowadzonych zmian, czyli uznał je za
prawidłowe.
Wobec powyższych stanowisk, Izba na rozprawę, do merytorycznego rozpoznania,
skierowała te z zarzutów, które podtrzymał odwołujący, tj. zarzut opisany w odwołaniu pod
numerem: 2.
Uwzględniając dokumentację z przedmiotowego postępowania o udzielenie
zamówienia publicznego, jak również biorąc pod uwagę oświadczenia i stanowiska
stron, oraz uczestnika postępowania odwoławczego, złożone w pismach
procesowych, jak też podczas rozprawy Izba stwierdziła, iż odwołanie zasługuje na
uwzględnienie.
W zakresie podtrzymanego przez
odwołującego zarzutu, odwołujący wskazał, co
następuje.
Zarzut nr 2.
Specyfikacja Warunków Zamówienia Rozdział III pkt. III.2 warunki udziału
w postępowaniu ppkt. 1.1.1.3.
Zamawiający w SWZ Rozdział III pkt. III.2 „Warunki udziału w postępowaniu” wskazał,
iż o zamówienie mogą ubiegać się Wykonawcy, którzy wykażą, że wykonali co najmniej dwa
(2) zamówienia dotyczące systemu klasy BPM, dla klienta o rozproszonej strukturze
organizacyjnej
– przy czym w pkt 1.1.1.3 postawił warunek: „zamówienia były wykonane dla
instytucji finansowych
, przez co należy rozumieć: przedsiębiorstwo inne niż instytucja,
którego podstawową działalnością jest nabywanie pakietów akcji lub wykonywanie co
najmniej jednego spo
śród rodzajów działalności wymienionych w pkt 2–12 i pkt 15
załącznika I do dyrektywy 2013/36/UE, pojęcie to obejmuje finansowe spółki holdingowe,
finansowe spółki holdingowe o działalności mieszanej, instytucje płatnicze w rozumieniu
dyrektywy 2007/64/WE Parlamentu Europejskiego i Rady z dnia 13 listopada 2007 r. w
sprawie usług płatniczych w ramach rynku (1) i spółki zarządzania aktywami, nie obejmuje
jednak ubezpieczeniowych spółek holdingowych i ubezpieczeniowych spółek holdingowych
prowadzących działalność mieszaną”.
Przedmiotowy warunek nie jest do końca jasny – odwołujący w dniu 19.11.2021 zadał
pytanie,
czy pod pojęciem „instytucja finansowa” zamawiający rozumie powszechne
i potoczne znaczenie i obejmuje nim także szeroko rozumiane instytucje publiczne
realizujące usługi i świadczenia związane z usługami płatniczymi – mowa tutaj o takich
instytucjach publicznych jak ARiMR, ZUS, KRUS czy Ministerstwa.
Zamawiający nie udzielił odpowiedzi do dnia złożenia odwołania.
Zdaniem o
dwołującego, projekty wykonane dla instytucji takich jak ARiMR, ZUS, KRUS
powinny być traktowane jako projekty referencyjne – taki warunek udziału jest bowiem
proporcjonalny do przedmiotu zamówienia.
Powyższe stanowi wymaganie nieadekwatne do przedmiotu zamówienia, co narusza
przepis art. 16 oraz przepis art. 112 ust. 1 ustawy Pzp.
Żądanie:
Wobec powyższego odwołujący wniósł o nakazanie zamawiającemu dokonania
następującej zmiany - usunięcie ograniczenia, które utrudnia uczciwą konkurencję i równe
tra
ktowanie wykonawców poprzez wskazanie, że warunek określony w pkt 1.1.1.3 realizują
projekty,
których odbiorcami są: Agencja Restrukturyzacji i Modernizacji Rolnictwa, Zakład
Ubezpieczeń Społecznych, Kasa Rolniczego Ubezpieczenia Społecznego.
W odniesieniu do przedmiotowego zarzutu zam
awiający wskazał, co następuje.
W odpowiedzi n
a żądanie odwołującego, zamawiający poszerza definicję odbiorcy
zamówienia dopuszczając wykazanie referencji od ARiMR. Zamawiający zmienia SWZ
w następujący sposób (zmiana została opublikowana w dniu 10.12.2021 r. – przyp. Izby):
„1.1.1.3. zamówienia były wykonane dla Agencji Restrukturyzacji i Modernizacji Rolnictwa
lub dla instytucji finansowych, przez co należy rozumieć: przedsiębiorstwo inne niż instytucja,
którego podstawową działalnością jest nabywanie pakietów akcji lub wykonywanie co
najmniej jednego spośród rodzajów działalności wymienionych w pkt 2–12 i pkt 15
załącznika I do dyrektywy 2013/36/UE, pojęcie to obejmuje finansowe spółki holdingowe,
finansowe
spółki holdingowe o działalności mieszanej, instytucje płatnicze w rozumieniu
dyrektywy 2007/64/WE Parlamentu Europejskiego i Rady z dnia 13 listopada 2007 r.
w sprawie usług płatniczych w ramach rynku (1) i spółki zarządzania aktywami, nie obejmuje
jednak ubezpieczenio
wych spółek holdingowych i ubezpieczeniowych spółek holdingowych
prowadzących działalność mieszaną”.
Z
amawiający wskazał, że przedmiotem zamówienia jest system, który działa tak jak
systemy w instytucjach finansowych (zgodnie z definicją w SWZ), a nie jakikolwiek system
centralny. W ocenie z
amawiającego ARIMR działa podobnie do instytucji finansowej, dlatego
też zgadza się na dodanie ARIMR jako odbiorcy usługi referencyjnej. Zamawiający nie
zgadza się natomiast z żądaniem dodania do kręgu odbiorców projektów referencyjnych
podmiotów ZUS oraz KRUS, bowiem procesy prowadzone w ramach działalności tych
podmiotów znacząco różnią się od procesów prowadzonych w instytucjach finansowych.
Żądanie odwołującego zmierza de facto do modyfikacji warunku pod swoje doświadczenie –
o
dwołujący żąda usunięcia z warunku instytucji finansowych wraz z ich definicją oraz zmianę
na ARIMR, ZUS oraz KRUS. Skutkiem uwzględnienia żądania odwołującego byłoby
częściowe zawężenie warunku i zmianę kręgu odbiorców zamówienia referencyjnego, co
doprowadziłoby do tego, że zamówienie mógłby otrzymać wykonawca, który nigdy wcześniej
nie realizował zamówienia takiej klasy i takiego rodzaju, jakie jest przedmiotem niniejszego
p
ostępowania.
Mając na uwadze powyższe, zamawiający wniósł o oddalenie zarzutu nr 2.
Krajowa Izba Odw
oławcza niniejszym odniesie się łącznie do zarzutów uwzględnionych
przez Izbę w zakresie obu odwołań (KIO 3445/21 – Asseco oraz KIO 3447/21 - Comarch).
Zdaniem Krajowej
Izby Odwoławczej zarzut jest zasadny.
Klasa BPM
– najistotniejsza część warunku, która dotyczy projektu, który może być
wykonywany dla każdego zainteresowanego podmiotu, występującego na rynku, bez
względu na charakter prowadzonej przez niego działalności. Liczy się doświadczenie
zdobyte na systemach klasy BPM o
określonych przez zamawiającego parametrach, a nie
doświadczenie zdobyte w usłudze dla określonego podmiotu – instytucji finansowej.
Jak słusznie bowiem wywodził w swojej opinii biegły, którego prywatną opinię
sporządzoną na rzecz odwołującego Comarch, powołał ten odwołujący, którą Izba dopuściła,
iż systemy Business Process Management (BPM) nie są wyłącznie związane z żadną
pojedynczą branżą, a w tym nie tylko z instytucją finansową, ale i jakąkolwiek inną. Systemy
BPM są uniwersalne i niezależne od specyfiki, czy właściwości użytkownika (klienta). Istota
systemu BPM polega na tym, że stanowi on zbiór narzędzi, pozwalających na modelowanie
i uruchomienie dowolnego procesu biznesowego. Ten sam system BPM pozwoli na
zaprojektowanie modelu i później obsługę procesów nie tylko instytucji finansowych, ale
i
wszystkich innych podmiotów, którymi mogą być instytucje tak komercyjne, jak i publiczne,
niezależnie od branży biznesowej, czy statutowej użytkownika (klienta). Ponadto
sporządzający opinię wskazał, iż proces obsługiwany przez system BPM nigdy nie jest
funkcjonalnością systemu BPM. Funkcjonalności systemu BPM w kontekście procesów
biznesowych sprowadzają się wyłącznie do dostarczania narzędzi umożliwiających
skonfigurowanie dowolnego procesu, a następnie do obsługi tak wytworzonego procesu.
Co najważniejsze może to być dowolny proces i w każdym systemie BPM procesy
obsługiwane mogą być inne, a funkcjonalności systemu BPM pozostają takie same. System
klasy BPM wdrożony w podmiotach innych niż instytucja finansowa będzie miał
funkcjonalno
ści systemu BPM, które były tu zaplanowane, wdrożone i skonfigurowane
niezależnie od rodzaju instytucji, a jednocześnie pozwoli na wdrożenie tego samego systemu
dla obsługi procesów charakterystycznych dla instytucji finansowych.
Izba, podzielając stanowisko sporządzającego opinię stwierdza, za odwołującymi,
że opisane w SWZ procesy są uniwersalne i nie są charakterystyczne tylko dla instytucji
finansowej.
W szczególności każdy z podanych procesów może być obsługiwany w innych
instytucjach niż instytucja finansowa:
Różne ścieżki procesowania dla różnych wnioskodawców i różnych produktów - np.
telekomunikacja (Wniosek o łącze światłowodowe, Wniosek o zmianę taryfy), energetyka
(Wniosek o wymianę licznika na dwukierunkowy, Wniosek o zwiększenie mody przyłącza);
Weryfikacja wystąpień na czarnych listach - np. usługi/handel (Weryfikacja podmiotu
przed podpisaniem kontraktu), KNF;
Analizy krzyżowe wniosków - np. ZUS, KRUS, NFOŚIGW;
Scoring wniosków - np. ubezpieczenia (Weryfikacja klienta pod kątem np. bezszkodowej
jazdy);
Zarządzanie limitami - np. PARP, NCBiR, NCN (Narodowe Centrum Nauki), branża
handlowa, spółki zarządzające flotą, telekomunikacyjne (limitowanie połączeń);
Stosowanie zabezpieczeń finansowania - np. ubezpieczenia, instytucje publiczne
zawierające umowy objęte zabezpieczeniem należytego wykonania umowy, KOWR
Przygotowanie i obsługa umów/aneksów - Dowolna branża;
Weryfikacja wniosków o płatność - np. ubezpieczenia, ZUS, KRUS, NCN, PARP,
NCBiR;
Obsługa odwołań/środków zaskarżenia - np. instytucje publiczne stosujące PZP, KIO;
- Windykacja -
Dowolna branża, np. branża handlowa, telekomunikacja, energetyka;
Obsługa świadczeń w oparciu o kursy walut - np. ubezpieczenia (Wypłata ubezpieczenia
w walucie innej niż PLN), NFZ (Obsługa świadczeń obywateli polskich realizowanych za
granicą).
Dodatkowym potwierdzeniem powyższego jest fakt, iż zamawiający wpisał w alternatywie
ARiMR obok instytucji finansowej, chociaż sam instytucją finansową w podanej przez siebie
w ramach w
arunku udziału definicji instytucji finansowej, nie jest.
Po zapoznaniu się z określoną w Opisie Wymagań Systemu Informatycznego
specyfikacją oprogramowania klasy BPM oraz z przedstawionym w Załącznik A2.1 do
Umowy Wdrożeniowej specyfikacji Procesu Głównego, biegły stwierdził, że:
a) z
amawiane oprogramowanie klasy BPM nie zawiera żadnych specyficznych dla
instytucji finansowych funkcjonalności. Każde oprogramowanie klasy BPM ma
podobne funkcjonalności, które pozwalają na skonfigurowanie dowolnych procesów.
Ni
e istnieją funkcjonaliści systemu BPM typowe tylko dla określonego zbioru/klasy
instytucji (jak finansowe),
b) z
definiowany Proces Główny obejmuje podprocesy występujące w instytucjach wielu
branż, nie tylko branży finansowej. Proces ten obejmuje typowe dla wielu branż
podproce
sy związane z obsługą umów, wniosków, płatności, kontroli itp.
Podsumowując należy jednoznacznie stwierdzić, że systemy klasy BPM są wdrażane
w wielu branżach i u wielu klientów. Zaś ich główną cechą jest możliwość modelowania
praktycznie dowolnych proces
ów z wykorzystaniem np. edytora procesów i uruchamianie ich
zarówno przez wykonawców jak i samych klientów. Co za tym idzie nie da się w żaden
sposób potwierdzić, że wdrożenia polegające na przygotowaniu skomplikowanych procesów
składających się z podprocesów są domeną jedynie instytucji finansowych, dlatego też Izba
nakazała zamawiającemu dokonanie zmiany spornego warunku, przez rozszerzenie
doświadczenia o inne instytucje, w których były wdrażane, utrzymywane i rozwijane systemy
klasy BPM.
Ponadto Izba ws
kazuje, że zamawiający nie wykazał (udowodnił), że na rynku obecne są
podmioty (więcej niż jeden), które mogłyby legitymować się wymaganym (w pierwotnym
brzmieniu SWZ)
doświadczeniem.
Powoływane przez zamawiającego dowody złożone na okoliczność istnienia istotnych
różnic pomiędzy funkcjonowaniem instytucji finansowych oraz ARiMR a funkcjonowaniem
ZUS i KRUS
potwierdzają jedynie, że takie różnice występują. Nie potwierdzają
jednocześnie, że podmiot, który wykonywał wdrożenie, utrzymywał wdrożony system
a na
stępnie go rozwijał, musi wykazać się doświadczeniem dla instytucji finansowej.
Z
amawiający zamawia system informatyczny klasy BPM o specyficznych cechach, który
ma spełniać wszystkie wymagania zamawiającego. Jednakże identyfikowanie wdrożenia dla
określonej grupy podmiotów jest w ocenie Izby, naruszeniem przepisów ustawy Pzp. Istotną
jes
t bowiem okoliczność, aby doświadczenie podmiotu dotyczyło stricte przedmiotu
zamówienia, oczywiście w odpowiedniej korelacji związanej z uczciwą konkurencją
i zachowaniem
zasady proporcjonalności. Zdaniem Izby przy zachowaniu wszystkich
parametrów związanych z wolumetrią zadań, rozszerzenie warunku doświadczenia
o
możliwość wykazania się doświadczeniem dla systemów BPM również w innych
instytucjach (nie tylko finansowych oraz ARiMR), pozwoli
zamawiającemu na dokonanie
wyboru ofert
y (wykonawcy), dającego rękojmię należytego wykonania zamówienia.
Biorąc pod uwagę powyższe, orzeczono jak w sentencji.
KIO 3447/21
Dnia 25 listopada 2021 roku wykonawca Comarch S.A. (dalej
„Odwołujący”) wniósł
odwołanie do Prezesa Krajowej Izby Odwoławczej od czynności sformułowania treści
ogłoszenia oraz treści specyfikacji warunków zamówienia niezgodnie z Pzp, poprzez
naruszenie:
zarzuty dotyczące warunków udziału w postępowaniu] art. 112 ust. 1 i 2 w związku
z art. 16 ustawy Pzp -
poprzez określenie warunków udziału w postępowaniu w sposób
nieproporcjonalny do przedmiotu zamówienia oraz uniemożliwiający ocenę zdolności
wykona
wcy do należytego wykonania zamówienia, jak też w sposób nie dotyczący zdolności
technicznej lub zawodowej wykonawcy, lecz odnoszący się do właściwości procesów
i działalności zamawiającego, nieprzekładalnych na doświadczenie rynkowe wykonawców
oraz poprze
z fakt, iż warunki nie dotyczą zamówienia i nie wynikają z opisu przedmiotu
zamówienia, ani z wymagań związanych z realizacją zamówienia,
zarzuty dotyczące kryteriów oceny ofert – próbka] art. 241 ust. 1 i 2 w zw. z art. 16
Pzp
– poprzez określenie zapisów dotyczących oceny kryteriów w zakresie próbki (będącej
je
dnym z kryteriów oceny ofert) – w sposób utrudniający przygotowanie oferty,
przeprowadzenie prezen
tacji i uzyskanie maksymalnej liczby punktów (a tym samym
utrudniający konkurencję), co może mieć wpływ na wynik postępowania i liczbę punktów
przyznanych wyk
onawcy, jak również w sposób, który nie jest jednoznaczny i zrozumiały
oraz powodujący, że kryterium oceny ofert i jej opis pozostawia zamawiającemu
nie
ograniczoną swobodę wyboru najkorzystniejszej oferty oraz uniemożliwia weryfikację
i porównanie poziomu oferowanego wykonania przedmiotu zamówienia na podstawie
informacji przedstawianych w ofertach,
zarzuty dotyczące niejasnego i utrudniającego konkurencję opisu przedmiotu
zamówienia] art. 99 ust. 1 i 4 w zw. z art. 16 ustawy Pzp - poprzez (opisany szczegółowo
w uzasadnieniu): opis przedmiotu zamówienia w sposób niejednoznaczny i niewyczerpujący,
za pomocą niedostatecznie dokładnych i zrozumiałych określeń, bez uwzględnienia
wymagań i okoliczności mogące mieć wpływ na sporządzenie oferty oraz w sposób
utrudniający uczciwą konkurencję.
Wnioski i żądania odwołującego zostały przedstawione pod zarzutami.
Ponadto o
dwołujący wniósł o zwrot kosztów postępowania, w tym zwrot kosztów
wynagro
dzenia pełnomocnika zastępującego odwołującego w postępowaniu odwoławczym.
Odwołujący wskazał, że ma interes w uzyskaniu zamówienia, ponieważ jest podmiotem
zdolnym do
jego wykonania, posiadającym w tym zakresie odpowiednie kompetencje
i doświadczenie. Poprzez sformułowanie przez zamawiającego postanowień SWZ w sposób
naru
szający przepisy ustawy odwołujący może być pozbawiony możliwości złożenia oferty
i uzyskania zam
ówienia, tym samym w wyniku naruszenia przez zamawiającego przepisów
ustawy o
dwołujący może ponieść szkodę polegającą na braku uzyskania przedmiotowego
za
mówienia. Ponadto odwołujący wskazał, że ma interes we wniesieniu odwołania, gdyż
w wyniku uregulowan
ia zapisów SWZ w sposób naruszający przepisy ustawy został
pozbawiony uczestnictwa w post
ępowaniu na uczciwych i zgodnych z prawem warunkach,
w tym możliwości złożenia ważnej i konkurencyjnej oferty przez wykonawców
gwarantujących prawidłowe wykonanie zamówienia ze względu na posiadanie
odpowiedniego doświadczenia. Odwołujący ma interes w uzyskaniu zamówienia, a w wyniku
działań zamawiającego odwołujący został narażony na szkodę. Gdyby nie naruszające
przepisy zaskarżone elementy SWZ, odwołujący mógłby z powodzeniem ubiegać się
o przedmiotowe zamówienie, co w razie jego uzyskania wiązałoby się z określonymi
korzyściami finansowymi. Na tym etapie postępowania krąg podmiotów mogących
skutecznie bronić swoich interesów w uzyskaniu zamówienia obejmuje każdego
potencjalnego wykonawcę, mogącego samodzielnie zrealizować zamówienie. Interes
o
dwołującego wyraża się również w tym, aby postępowanie o udzielenie zamówienia
przeprowadzone zostało zgodnie z przepisami prawa.
Izba ustaliła i zważyła, co następuje.
Izba s
twierdziła, że nie zachodzą przesłanki do odrzucenia odwołania, o których stanowi
przepis art. 528 ustawy Pzp.
Krajowa Izba Odwoławcza stwierdziła, że odwołujący posiada interes w uzyskaniu
przedmiotowego zamówienia, kwalifikowanego możliwością poniesienia szkody w wyniku
naruszenia przez zamawiającego przepisów ustawy, o których mowa w art. 505 ust. 1
ustawy Pzp
, co uprawniało go do złożenia odwołania.
W proce
sie wymiany pism procesowych oraz przeprowadzonych posiedzeń, strony –
odpowiednio
złożyły oświadczenia o: uwzględnieniu zarzutów odwołania (zamawiający) oraz
wycofaniu zarzutów (odwołujący).
Wobec powyższych stanowisk, Izba na rozprawę, do merytorycznego rozpoznania
skierowała te z zarzutów, które podtrzymał odwołujący, tj. zarzuty opisane w odwołaniu pod
numerami:
zakres I (warunki udziału w postępowaniu) punkt: 1, 2, 3 (w zakresie nie
uwzględnionym przez zamawiającego), 7, 8, 9, 10, zakres II (kryteria oceny ofert - próbka)
litera: a, c, d, e, j, m, zakres III (OPZ)
– w całości.
Uwzględniając dokumentację z przedmiotowego postępowania o udzielenie
zamówienia publicznego, jak również biorąc pod uwagę oświadczenia i stanowiska
stron,
oraz
uczestnika
po
stępowania odwoławczego, złożone w pismach
procesowych, jak też podczas rozprawy Izba stwierdziła, iż odwołanie w części
zasługuje na uwzględnienie.
W zakresie podtrzymanych przez
odwołującego zarzutów, odwołujący wskazał, co
następuje.
Zakres I (warunki udzi
ału w postępowaniu).
Punkt 1
– Zarzut dotyczący 3-letniego okresu referencyjnego. Żądanie wprowadzenie
referencyjnego okresu 5 lat przed dniem składnia ofert, zamiast obecnych 3 lat
(z zachowaniem 12 miesięcznego okresu utrzymania) - (pkt. 1.1.1).
Zgodnie
z § 9 ust. 4 rozporządzenia z dnia 23 grudnia 2020 r. w sprawie podmiotowych
środków dowodowych oraz innych dokumentów lub oświadczeń, jakich może żądać
zamawiający od wykonawcy (dalej rozporządzenie) zamawiający ma możliwość wyboru
czasookresu wykazania si
ę doświadczeniem przez wykonawcę poza podstawowy okres
3 lat:
„4. W celu zapewnienia odpowiedniego poziomu konkurencji w postępowaniu,
zamawiający może dopuścić, aby wykaz: 2) o którym mowa w ust. 1 pkt 2, dotyczył dostaw
lub usług wykonanych, a w przypadku świadczeń powtarzających się lub ciągłych – również
wykonywanych, w okresie dłuższym niż ostatnie 3 lata”.
Sam ustawodawca wskazał, iż wydłużenie czasookresu jest wskazane ze względu na
zwiększenie konkurencyjności. Warunki udziału w postępowaniu mają na celu dokonanie
selekcji wykonawców, którzy legitymują się odpowiednim doświadczeniem. Trudno uznać,
iż wykonawca, który wdrożył system np. 4 lata temu jest w innej sytuacji niż wykonawca,
który wykonał analogiczny system rok później. Żądanie, aby wykonawca wykazał się
wykonaniem systemu w okresie 3 ostatnich lat jest ograniczaniem konkurencji. Tym bardziej,
iż zamawiający nie wskazał żadnej szczególnej technologii, będącej nowością na rynku,
takiej która nie była sprzedawana i wdrażana wcześniej. Wydłużenie czasokresu
doświadczenia wykonawcy jest uzasadnione także z uwagi na obecne brzmienie warunku
w zakresie doświadczenia wykonawcy. Zamawiający, bowiem wymaga w jednej usłudze
wykazanie wdrożenia oraz minimum 12 miesięcznego utrzymania i rozwoju, wykonane nie
wcześniej niż 3 lata przed upływem składania ofert, a zatem rzeczywisty czas w jakiem
mog
łoby się odbyć wdrożenie to de facto tylko 2 lata. Ponadto biorąc pod uwagę liczne
podwarunki omawianego wymagania, które łącznie powodują, iż jest to wymaganie bardzo
wyśrubowane – dobór adekwatnego projektu referencyjnego jest sam przez się ograniczony.
Tym bardziej zatem wskazane jest wydłużenie okresu referencyjnego ponad okres wskazany
w
Specyfikacji.
Zamawiający ma obowiązek formułowania warunków udziału
w postępowaniu w taki sposób, aby nie utrudniał on uczciwej konkurencji. Zamawiający
zobowiązany jest również określić warunki udziału w taki sposób, aby do realizacji
zamówienia został dopuszczony wyłącznie wykonawca posiadający doświadczenie
w realizac
ji zadań zapewniające należyte wykonanie zamówienia, przy czym określenie
warunku jest obowiązkiem i uprawnieniem zamawiającego, który dokonując tej czynności
zobowiązany jest brać pod uwagę przedmiot zamówienia, cel przedsięwzięcia oraz
zapewnienie równego traktowania wykonawców i uczciwej konkurencji.
Ograniczenie wykazania doświadczenia do 3 lat nie jest niczym uzasadnione. Służy
wyłącznie ograniczaniu konkurencji.
W odniesieniu do przedmiotowego zarzutu
zamawiający wskazał, co następuje.
Postawienie przez z
amawiającego zaskarżonego wymagania jest uzasadnione
i proporcjonalne do przedmiotu zamówienia, a żądanie odwołującego jest bezpodstawne,
ponieważ jest ogromna różnica pomiędzy projektami realizowanymi 5 lat temu i 3 lata temu.
Ostatnie trzy lata są okresem dynamicznego rozwoju technologicznego, co skutkuje tym,
że technologie sprzed 5-ciu lat są przestarzałe i zdezaktualizowane. Ponadto 5-cio letni
okres referencyjny oznacza, że realizacja projektu mogła rozpocząć się dużo wcześniej (na
przykład 7 lat przed terminem składania ofert – co oznacza, że użyto technologii sprzed
7 lat). Oznacza to, że zamawiający musiałby dopuścić wykazanie przez wykonawców
doświadczenia, które nie będzie dawało rękojmi należytego wykonania przedmiotowego
zamówienia. Przykładowo, w okresie dłuższym niż 3 lata przed terminem składania ofert
techniki low code
i obsługa technologii mobilnych były znacznie mniej wykorzystywane niż
w przedmiotowym zamówieniu, tymczasem zastosowanie technik low code ma na celu
między innymi obniżenie kosztów rozwoju systemu, co jest dla zamawiającego kluczowym
celem wdrożenia nowego systemu. Ponadto, zgodnie z rozporządzeniem Ministra Rozwoju,
Pracy i Technologii w sprawie podmiotowych środków dowodowych oraz innych
dokumentów lub oświadczeń, jakich może żądać zamawiający od wykonawcy z dnia
23 grudnia 2020 r. (Dz.U. z 2020 r. poz. 2415)
(dalej: „rozporządzenie”) zamawiający ma
możliwość, a nie obowiązek wydłużenia 3-letniego okresu referencyjnego do 5-ciu lat i to
tylko w sytuacji, gdy ma to na celu zapewnienie odpowiedniego poziomu konkurencji.
Natomiast w przedmiotowym p
ostępowaniu wydłużenie okresu referencyjnego miałoby
odwrotny cel, gdyż dopuściłoby do zamówienia wykonawców, którzy nie posiadają aktualnej
wiedzy i doświadczenia w technologii używanej w przedmiotowym zamówieniu.
Odwołujący twierdzi także, że wydłużenie okresu referencyjnego do 5-ciu lat jest
uzasadnione także z tego względu, że zamawiający wymaga w jednym zamówieniu
(wykonanym nie wcześniej niż 3 lata przez upływem terminu składania ofert) wykazania
wdrożenia oraz trwających minimum 12 miesięcy usług utrzymania i rozwoju, co zdaniem
o
dwołującego oznacza, że rzeczywisty czas w jakim mogłoby odbyć się wdrożenie to de
facto
tylko 2 lata. Mając na uwadze powyższe, zamawiający zmienił wymaganie poprzez
usunięcie wymagania aby utrzymanie i rozwój trwały co najmniej 12 miesięcy. Po zmianie
SWZ wymaganie
otrzymał następujące brzmienie:
III.2. Warunki udziału w postępowaniu (…). 1.1.1.1. każde obejmujące swym przedmiotem
wdrożenie utrzymanie i rozwój systemu informatycznego klasy BPM (przy czym utrzymanie i
rozwój trwające co najmniej przez okres 12 miesięcy), gdzie:”
Mając na uwadze powyższe, w tym zmianę SWZ, zamawiający wniósł o oddalenie
zarzutu.
Zdaniem Krajowej Izb
y Odwoławczej zarzut jest bezzasadny. Izba w całości podziela
argument
ację zamawiającego przyjmując, iż faktycznie, jeżeli chodzi o rozwój dziedziny jaką
jest szeroko rozumiana informatyka
, niezasadne byłoby rozszerzanie okresu doświadczenia
do 5 lat. Zw
rócić bowiem należy uwagę na fakt, iż projekty informatyczne odpowiadają na
bieżące potrzeby rynku, a historyczne realizacje, które w skrajnych przypadkach mogłyby
zostać rozpoczęte nawet 7 lat temu, z pewnością nie odpowiadają bieżącemu poziomowi
rozwoju i wymagań zamawiającego.
Punkt 2
– Zarzut dotyczący jednoczesnego doświadczenia odrębnie we wdrożeniu
i rozwoju. Żądanie dopuszczenia rozwoju sytemu jako alternatywny do wdrożenia systemu
(a nie jako odrębnej fazy utrzymania systemu) z jednoczesnym wydzieleniem do odrębnego
warunku wymogów charakterystycznych wyłączenie dla wdrożenia, a dotyczących (pkt.
a. Opracowania koncepcji architektury systemu oraz projektu technicznego systemu,
b. Instalacji i konfiguracji infrastruktury spr
zętowo-systemowo-narzędziowej w tym
1. instalację niezbędnej do prawidłowego działania systemu infrastruktury
teleinformatycznej
, 2. konfigurację środowisk systemu, 3. instalację i konfigurację
oprogramowania systemowego oraz oprogramowania bazodanowego),
c. Instalacji i konfigur
ację systemu w tym budowę interfejsów dla co najmniej 10 innych
systemów współpracujących z wdrażanym systemem.
d. Dostawy
wymaganej
liczby
licencji
oprogramowania
systemowego
oraz
oprogramowania bazodanowego,
e. Przeprowadzenie
warsztatów i szkoleń dla użytkowników systemu.
O
dwołujący wskazał, iż wymaganie, aby w jednym zamówieniu referencyjnym
zrealizowane było odrębnie wdrożenie systemu i rozwój systemu jest nadmiarowe.
W praktyce rynkowej w obszarze IT liczba wdrożeń systemu jest mniejsza niż usług
rozwojowych
– będących w praktyce odrębnym wdrożeniem, tyle że w obrębie już
istniejącego (wdrożonego uprzednio) systemu. Jest to powszechna praktyka. Liczni klienci
firm informatycznych, posiadając już zinformatyzowane swoje główne procesy – korzysta
właśnie z tej drugiej możliwości. Stąd wykonawcy w ramach prac wdrożeniowych częściej
mają do czynienia z tą formą wdrożenia, która z czasem, w wyniku tak prowadzonego
rozwoju
– powoduje, że aktualny system istotnie odbiega od pierwotnego zakresu wdrożenia.
Wyk
onawca, który wdrożył system np. 10 lat temu i od tego czasu stale go rozwija, ulepsza,
powiększa - według aktualnego brzmienia Specyfikacji nie spełniałby warunku udziału
w postępowaniu, a posiadałby doświadczenie pod kątem merytorycznym.
R
ozwój istniejącego systemu informatycznego w zakresie np. nowych funkcjonalności,
zawiera w sobie i
wdrożenie, jak i uruchomienie – w zasadzie jest de facto usługą wdrożenia
w obrębie systemu informatycznego. Dlatego też zasadne jest rozdzielenie i dopuszczenie
altern
atywy wdrożenie lub rozwój, gdyż w obecnym brzmieniu warunek de facto się dubluje
(rozwój -wdrożenie). Główna różnica dotycząca rozwoju systemu i wdrożenia systemu od
podstaw polega na tym, że nie w każdym rozwoju dostarcza się i konfiguruje infrastrukturę
sprzętowo – programistyczną oraz nie w każdym rozwoju występuje etap szkoleniowy. Stąd
– by w wyniku uwzględnienia zarzutu i żądania odwołania – wdrożenie i rozwój były
porównywalne zakresowo – wykonawca żąda wydzielenia doświadczenia w zakresie
infrastru
ktury i szkoleń do odrębnego warunku.
Wyjaśniając szczegóły w odniesieniu do zapisów Specyfikacji odwołujący wskazał,
iż biorąc pod uwagę, iż rozwój nie obejmuje (według definicji wdrożenia wskazanej przez
z
amawiającego w SWZ - Rozdział III , podrozdział III.2 pkt. 1.ppkt. 1.1.1.):
a. Opracowania koncepcji architektury systemu oraz projektu technicznego systemu,
b.
Instalacji i konfiguracji infrastruktury sprzętowo-systemowo-narzędziowej w tym
1. instalację niezbędnej do prawidłowego działania systemu infrastruktury
teleinformatycznej, 2. konfigu
rację środowisk systemu, 3. instalację i konfigurację
oprogramowania systemowego oraz oprogramowania bazodanowego),
c. Instalacji
i konfigurację systemu w tym budowę interfejsów dla co najmniej 10 innych
system
ów współpracujących z wdrażanym systemem.
d. Dostawy
wymaganej
liczby
licencji
oprogramowania
systemowego
oraz
oprogramowania bazodanowego,
e.
Przeprowadzenie warsztatów i szkoleń dla użytkowników systemu,
o
dwołujący postuluje wydzielenie tych elementów do osobnego warunku. Wszystkie
elementy żadne przez zamawiającego zostaną zachowane.
Konsekwencją uwzględnienia tego zarzutu powinno być:
wykre
ślenie podwarunku w zakresie wartości rozwoju (pkt. 1.1.1.2.3);
Wykreślenie jest konsekwencją propozycji wykonawcy zastosowania alternatywy w opisie
doświadczenia: wdrożenie lub rozwój (pkt. 2 odwołania). Uzasadnienie zarzutu w tym
zakresie oddano powyżej (w tym miejscu odwołujący opisuje jego konsekwencje).
modyfikacja zapisu podwa
runku w zakresie wartości usług wdrożenia (pkt. 1.1.1.2.1);
Jak wyżej. Wzmiankowana modyfikacja jest konsekwencją propozycji wykonawcy
zastosowania alternatywy w opisie doświadczenia: wdrożenie lub rozwój (pkt. 2 Odwołania).
Zapis powinien brz
mieć „całkowita wartość utrzymania lub rozwoju, w zakresie co najmniej
jak w pkt 1.1
.1.1.1 lub 1.1.1.1.3 powyżej, była nie mniejsza niż 1 500 000 brutto.
W odniesieniu do przedmiotowego zarzutu
zamawiający wskazał, co następuje.
Zamawiający postawił warunki udziału w postępowaniu w taki sposób, aby doświadczenie
wyk
onawcy, który otrzyma zamówienie, było adekwatne do projektu jaki będzie realizował.
Przedmiotem zamówienia jest wdrożenie, na które składa się: (i) wdrożenie Systemu
Informatycznego opartego na standardowym rozwiązaniu typu „out of the box” oraz Procesu
Głównego w ramach takiego Systemu Informatycznego, a następnie (ii) świadczenie Usług.
Jest oczywiste, że zamawiający oczekuje doświadczenia proporcjonalnego do
przedmiotowego zamówienia. Czym innym jest posiadanie doświadczenia we wdrożeniu
standardowego „pudełkowego” rozwiązania informatycznego zgodnie ze standardami
a następnie oraz w rozwoju takiego systemu zgodnie z wymogami producenta, a czym innym
jest doświadczenie wyłącznie w rozwoju systemu wdrożonego przez inny podmiot.
W uzasadnieniu zarzutu o
dwołujący opisuje istniejące na rynku rozwiązania, którymi
z
amawiający nie jest zainteresowany (rozwój już istniejącego systemu). Zamawiający
wymaga wdrożenia nowego systemu a następnie jego rozwój i takiego też doświadczenia
(propo
rcjonalnego do zamówienia) wymaga od wykonawców, którzy będą ubiegać się
o zamówienie. To, że jak twierdzi odwołujący, w praktyce rynkowej w obszarze IT liczba
w
drożeń systemu jest mniejsza niż usług rozwojowych, oznacza tylko tyle, że nie każde
zamówienie spełnia postawione przez zamawiającego wymagania i nie każdy wykonawca
mający w portfolio rozwój systemu, posiada doświadczenie we wdrożeniu nowego systemu
a na
stępnie w jego rozwoju. Zamawiający nie ma obowiązku dopuszczenia do zamówienia
wszystkich dz
iałających na rynku podmiotów, lecz powinien postawić warunki udziału
w p
ostępowaniu w taki sposób, aby otrzymać rękojmię należytego wykonania
przedmiotowego zamówienia. Zdaniem zamawiającego, wykonawca nieposiadający
doświadczenia we wdrożeniu a następnie rozwoju systemu nie posiada wystarczającego
doświadczenia aby zrealizować przedmiotowe zamówienie. Ponadto odwołujący w żaden
s
posób nie wykazał, że postawiony przez zamawiającego warunek jest nadmierny,
nieproporcjonalny
czy naruszający konkurencję. Odwołujący nie wykazał, że na rynku nie ma
referencyjnych
projektów spełniających postawione przez zamawiającego wymagania,
natomias
t ze znajomości rozwiązań dostępnych na rynku (np. systemy, z których korzystają
instytucje finansowe) wynika, że są dostępne rozwiązania, które spełniają postawione
wymagania.
Mając na uwadze powyższe, zamawiający wniósł o oddalenie zarzutu.
Zdaniem
Krajowej Izby Odwoławczej zarzut jest bezzasadny.
Izba
, nawiązując do argumentacji wyżej prezentowanej, dotyczącej uwzględnionego przez
Izb
ę zarzutu podnosi, iż przedmiot zamówienia jest opisany przez zamawiającego
kompleksowo, tj. zawiera w sobie
elementy, które zdaniem Izby są ze sobą ściśle
powiązane, a warunek doświadczenia wprost do nich referuje. Dlatego też żądanie
odwołującego de facto doprowadziłoby do braku możliwości weryfikacji wykonawcy w całym
zakresie związanym z zamówieniem.
Jak zasadnie wskazał zamawiający, nie jest zrozumiałe z jakiego względu odwołujący
konsekwentnie stoi na stanowisku, że nie jest uzasadnione wymaganie, by wykonawca, który
ma real
izować zadanie polegające zarówno na wdrożeniu, jak i na rozwoju, wykazał
posiadanie doświadczenia w realizacji zamówień, które polegają właśnie zarówno na
wdrożeniu, jak i na rozwoju. Żądanie dopuszczenia alternatywnego wykazania
doświadczenia (we wdrożeniu lub rozwoju), jest wprost sprzeczne z zasadą
proporcjonalności. Zupełnie innym projektem jest wdrożenie rozwiązania, a innym jego
rozbudowa czy modyfikacja
dlatego też w ocenie Izby, zamawiający prawidłowo oczekuje
doświadczenia w obu tych obszarach.
Punkt 3 (w zakresie nie
uwzględnionym przez zamawiającego) – Zarzut dotyczący
ogranicze
nia interfejsów tylko do systemów wewnętrznych klienta. Żądanie: dopuszczenie
w ramach wydzielonego nowego warunku dotyczącego budowy interfejsów - interfejsów nie
tylko dla systemów klienta, lecz również dla systemów zewnętrznych oraz organicznie liczby
i
ntegrowanych systemów do 5 (pkt. 1.1.1.1.1.3).
O
dwołujący wskazał, iż wymaganie zamawiającego, aby system integrował się dla co
najmniej 10 innych sys
temów klienta jest nadmiarowe i ograniczając zakres dopuszczalnych
referencji. Zdaniem o
dwołującego, wystarczającym do wykazania się jest, aby system
integrował się z minimum 5 systemami - bez znaczenia czy są to systemy klienta, czy też
nie
. Mogą to być zarówno systemy wewnętrzne klienta jak również zewnętrzne. Nacisk
w tym wymaganiu powinien być postawiony na możliwość systemu do integracji, bo jest to
funkcjonalność, która ma dla zamawiającego znaczenie. System, który integruje się
z zew
nętrznymi systemami, potrafi też integrować się z systemami wewnętrznymi.
Ponadto
odwołujący zarzucił, że liczba systemów jest zawyżona z uwagi, iż efektywna
integracja z systemami zależy od specyfiki odbiorcy i jego potrzeb, jest niezależna od
wykonawcy.
W związku z tym doświadczenie wykonawcy prezentujące integrację z minimum
5 systemami jest wystarczające.
W odniesieniu do przedmiotowego zarzutu
zamawiający wskazał, co następuje.
Od
wołujący twierdzi, że wymaganie zamawiającego, aby system integrował się z co
najmniej 10 innymi systemami kl
ienta jest nadmiarowe i ograniczające zakres
dopuszczalnych referencji.
Odwołujący postawił dwa żądania w ramach podniesionego
zarzutu:
1. D
otyczące liczby integrowanych systemów (zmniejszenia z 10 do 5)
2. Dopuszcze
nia w ramach wykazania spełnienia warunku – integracji nie tylko z
systemami klienta ale także z systemami zewnętrznymi.
Odnosz
ąc się do pierwszego żądania, zamawiający wskazał, że wymaganie nie jest
nadmiarowe, gdyż przedmiot zamówienia będzie finalnie obejmował integrację z 29
wewnętrznymi systemami i 4 zewnętrznymi systemami (str.14-22 Załącznika nr A2 – Opis
Wymagań Systemu Informatycznego do Umowy). Zamawiający stawiając przedmiotowe
wymagani
e wziął pod uwagę fakt, że 10 to liczba najważniejszych, kluczowych systemów do
integracji. Ponadto wymaganie to wpływa na: (i) wydajność systemu, ponieważ więcej
integracji przekłada się na to, że system musi być wydajniejszy, (ii) zapewnienie
prawidłowości komunikacji z systemami, (iii) odporność na tzw. zakleszczanie,
tj. blokowanie, zawieszanie systemu przy równoczesnej komunikacji z wieloma systemami.
Stawiając powyższy warunek, zamawiający wziął także pod uwagę realia rynkowe.
Przegląd rynku zamówień publicznych pozwala na stwierdzenie, że wymóg integracji
z 10-cioma systemami nie jest nietypowy i nadmiarowy. Tym samym postawienie wymagania
integracji z 10-cioma systemami ani
w sposób nieuprawniony nie ogranicza konkurencji ani
nie jest nieproporcjonalny (33 systemy do integracji w ramach przedmiotowego
po
stępowania).
Zamawiający zgodził się z drugim żądaniem dopuszczenia integracji nie tylko
z systemami klienta ale także z systemami zewnętrznymi i w tym zakresie zmienił SWZ. Po
zmianie warunek ma
następujące brzmienie: „1.1.1.1.1.3. Instalację i konfigurację systemu w
tym budowę interfejsów dla co najmniej 10 innych systemów klienta lub systemów
zewnętrznych współpracujących z wdrażanym systemem”.
Mając na uwadze powyższe, w tym zmianę SWZ, zamawiający wniósł o oddalenie
zarzutu.
W zakresie powyższego Izba w całości podziela stanowisko zamawiającego stwierdzając,
iż wymaganie zamawiającego nie jest nadmiarowe i nie narusza zasady proporcjonalności.
Punkt 7
– Zarzut dotyczący liczby użytkowników systemu. Żądanie modyfikacji
podwarunku dotyczącego liczby użytkowników systemu (pkt. 1.1.1.2.4).
O
dwołujący wskazał, iż wymaganie, aby system obsługiwał 1000 użytkowników przy
zapewnieniu jednoc
zesnego dostępu do systemu w zakresie wszystkich jego funkcjonalności
jest nadmiarowe. Sformułowanie „w zakresie wszystkich jego funkcjonalności” wskazuje,
iż wymagani użytkownicy to użytkownicy wewnętrzni/pracownicy organizacji klienta. Nie
każdy pracownik ma dostęp do wszystkich funkcjonalności systemu. Poziomy dostępu są
różne. Dodatkowo sam zamawiający w OPZ wskazał, iż oferowany przez wykonawcę system
ma definiować różne poziomy do systemu w zależności od pełnionej funkcji. Warunek w tym
zakresie w związku z tym nie jest adekwatny ani proporcjonalny do przedmiotu zamówienia,
jedynie niepotrzebnie ogranicza dobór referencji oraz konkurencyjność postępowania.
Ponadto, żądanie aby liczba użytkowników była na poziomie 1000 jest zdecydowanie
nadmiarowe. System, który ma możliwość obsługi kilkuset użytkowników jest już systemem
zaawansowanym technologicznie na poziomie, który oczekuje zamawiający. Zwiększenie
liczby użytkowników to wyłącznie kwestia skalowalności systemu, bez wpływu na jego
funkcjonalność. Zapis warunku po modyfikacji spełniający wymagania konkurencyjności
powinien
brzmieć/żądanie:
„liczba
obsługiwanych
użytkowników
(wewnętrznych
i zewnętrznych) przez system była nie mniejsza niż 100”.
W odniesieniu do przedmiotowego zarzutu
zamawiający wskazał, co następuje.
Odwołujący twierdzi, że wymóg, aby w zakresie utrzymania systemu wymagane było
raportowanie wykonywanyc
h usług utrzymania, do tego w okresach miesięcznych, w formie
raportów przesyłanych do klienta jest nadmiarowe. Raportowanie jest standardem
w wi
ększości projektów obejmujących usługi utrzymania. Raporty są często podstawą do
roz
liczeń pomiędzy stronami. Zamawiający zgodził się z odwołującym, że w celu weryfikacji
doświadczenia wykonawcy nie jest kluczowa ani forma raportów ani okres ich generowania.
Jednakże żądanie odwołującego, aby w całości usunąć przedmiotowy warunek jest zbyt
daleko idące (odwołujący nie wyjaśnił dlaczego samo wymaganie raportowania – które jest
standardem
i jak wskazał odwołujący, jest czynnością techniczną - miałoby być nadmiarowe
i ograniczające konkurencję, skoro przedmiot zamówienia obejmuje raportowanie).
Z
amawiający, mając na uwadze argumentację odwołującego, zmienił SWZ w następujący
sposób: „1.1.1.1.2.4 Cykliczne raportowanie wykonywania usług utrzymania w okresach
miesięcznych w formie raportów przesyłanych do klienta.”.
Mając na uwadze powyższe, w tym zmianę SWZ, zamawiający wniósł o oddalenie
zarzutu.
Punkt 8
– Zarzut dotyczący liczby wniosków obsługiwanych rocznie przez system.
Modyfikacja podwarunku w zakresie wymagane
j ilości wniosków jakie obsłużył system (pkt.
Wymaganie, aby
„system obsłużył w każdym roku średnio co najmniej 500 000 wniosków
co oznacza, iż wnioski w podanej liczbie były wprowadzone do systemu oraz
przeprocesowane w pełnym zakresie procesów, zgodnie z wdrożonymi procesami
biznesowymi
” jest zdaniem odwołującego wymaganiem nadmiarowym i istotnie
ograniczającym konkurencję. Liczba wprowadzonych wniosków jest wartością niezależną od
wykonawcy, bowiem system może mieć możliwość wprowadzenia 500 tyś. wniosków,
a z przyczyn niezależnych od wykonawcy te wnioski nie zostaną wprowadzone w żądanej
wysok
ości, jest to parametr zewnętrzny. Celem badania doświadczenia wykonawców
w postępowaniu nie jest znalezienie u wykonawcy doświadczenia identycznego lub prawie
takiego samego
– jak specyfika danego zamawiającego oraz związanego z nią przedmiotu
zamówienia. W przypadku zamawiającego, duża liczba obsługiwanych wniosków jest wprost
zależna od specyfiki zamawiającego. Zamawiający w uproszczeniu – wypłaca rolnikom
bezzwrotne dotacje/dopłaty. Innymi słowy to zamawiający wypłaca pieniądze swoim
„klientom”. Tymczasem doświadczenia i praktyka rynkowa są zgoła odmienne. Przepływ
pieniądza odbywa się z reguły w drugą stronę: to Banki, inne przedsiębiorstwa potencjalnie
referencyjne
– zarabiają na swych klientach z tytułu świadczonych im usług (udzielone kwoty
kredytów podlegają zaś zwrotowi). Gdyby zawarta w specyfikacji w omawianym warunku
liczba wniosków nie uległa zmianie – potencjalnie możliwa referencja pochodząca od Banku
mogłaby być wyeliminowana, jako nie spełniająca wymagania. Nie mniej jednak system taki
realizuje podobne procesy jak system zam
awiany. Z tą różnicą – iż klient takiego Banku
podlega licznym ograniczeni
om, musi mieć określoną zdolność kredytową, musi być go
„stać” na usługi banku. Ponadto – przykładowo wniosek o kredyt również nie jest równy
wniosk
owi o wypłatę dopłat. Każdy kredyt trzeba spłacić (z kosztem po stronie klienta) – co
samo w sobie wpływa na mniejszą liczbę wniosków w tym zakresie. Powyższa argumentacja
dotyczy również liczby umów (wskazane poniżej).
Podsumowując - odwołujący wskazał, że z punktu widzenia zamawiającego i jej
wolumenu wniosków/umów wymagania co do liczby tych wniosków/umów może nie są
wyśrubowane. Jednak z punktu widzenia doświadczenia rynkowego i występującego na
rynku kręgu potencjalnych umów referencyjnych od innego typu klientów, niż sam
zamawiający, którzy mogliby potwierdzić dane doświadczenia – liczby te są wręcz zaporowe.
Tym bardziej,
że są one podane w skali corocznej. Gdyby brać przykładowo pod uwagę
liczbę umów o obsługę kredytów dla klientów korporacyjnych – przez okres 3 lat zostałaby
wyczerpana w ogóle liczba firm jaka istnieje na krajowym rynku. Zatem wymóg winien
dotyczyć możliwości systemu do wprowadzenia wniosków w określonej ilości.
Propozycja zapisu/żądanie: „1.1.1.2.5. system ma możliwość obsłużenia w każdym roku
średnio co najmniej 500 000 wniosków co oznacza, iż wnioski w podanej liczbie mogłyby być
wprowadzone do systemu oraz mogłyby być przeprocesowane w pełnym zakresie procesów,
zgodnie z wdrożonymi procesami biznesowymi”. Alternatywnie żądanie: zmniejszenie ilości
wniosków: „1.1.1.2.5. system obsłużył w każdym roku średnio co najmniej 50 000 wniosków
co oznacza, iż wnioski w podanej liczbie były wprowadzone do systemu oraz
przeprocesowane w pełnym zakresie procesów, zgodnie z wdrożonymi procesami
biznesowymi
”.
W odniesieniu do przedmiotowego zarzutu za
mawiający wskazał, co następuje.
Żądanie odwołującego zmierza do tego, aby wykonawcy mogli wykazać doświadczenie
we wdrożonej funkcjonalności, która de facto nie została zweryfikowana. Jeżeli zamawiający
dopuściłby zmianę SWZ zgodnie z żądaniem, oznaczałoby to, że wykonawca posiada
doświadczenie we wdrożeniu systemu, który tylko prawdopodobnie posiada wydajność
pozwalającą na obsługę w każdym roku średnio 500.000 wniosków, ale w praktyce nie
wiadomo, czy taki system rzeczywiście obsłużyłby taki wolumen wniosków. Propozycja takiej
zmia
ny stoi w sprzeczności z celem stawiania warunków udziału w postępowaniu w zakresie
doświadczenia wykonawcy. To prawda, że wykonawca nie miał wpływu na to ile wniosków
zostało obsłużonych, ale to nie ma związku ze spełnianiem warunku udziału
w p
ostępowaniu, gdyż oznacza to, że system nie został zweryfikowany pod kątem obsługi
takiej liczby wniosków. System, który jest przedmiotem postępowania, będzie funkcjonalnie
zbliżony do systemów bankowych, które średnio rocznie obsługują dużo większy wolumen
wniosków niż wskazany w wymaganiu. Wykonawca, który nie posiada wymaganego
doświadczenia nie daje gwarancji, że wdrożony przez niego system będzie w stanie
obsłużyć wnioski w bieżącej dzielności zamawiającego.
Mając na uwadze powyższe, zamawiający wniósł o oddalenie zarzutu.
Punkt 9
– Zarzut dotyczący liczby umów generowanych rocznie przez system.
Modyfikacja podwarunku w zakresie wymaganej ilości wygenerowanych umów w systemie
(pkt. 1.1.1.2.6).
Wymaganie aby, „system obsłużył w każdym roku co najmniej 400 000 umów co oznacza,
iż do systemu zostały wprowadzone dane i zostały wygenerowane umowy wynikające
z procesu w wymaganej minimalnej liczbie
” jest zdaniem odwołującego wymaganiem
nadmiarowym, ograniczającym konkurencję. Liczba obsługiwanych/wygenerowanych umów
jest wartością niezależną od wykonawcy, bowiem system może mieć możliwość
wygenerowania 400 tyś. umów, a z przyczyn niezależnych od wykonawcy umowy nie
zostaną wygenerowane, bo wnioskodawca odstąpił od zamiaru jej zawarcia, bądź nie spełnia
wymogów niezbędnych do jej zawarcia, jest to parametr zewnętrzny. Zatem wymóg winien
dotyczyć możliwości systemu do wygenerowania dokumentów w określonej ilości, na skutek
złożonego wniosku. Bez znaczenia powinno być czy wygenerowany dokument nosi nazwę
umowa, czy zamówienia czy też aneks do umowy. Nacisk powinien być położony na
procesie, którego finalnym produktem jest wygenerowany dokument. W tym zakresie
o
dwołujący ponawia argumentacje dotyczącą niekonkurencyjnego przeniesienia na warunek
u
działu w postępowaniu specyfiki właściwej dla zamawiającego – omówione wyżej
w zak
resie liczby wniosków. W świetle doświadczeń rynkowych, zwłaszcza komercyjnych -
tak duża liczba umów obsługiwanych rocznie przez system jest zaporowa i uniemożliwia
złożenie oferty pomimo, że wykonawca wdrożył i utrzymuje system realizujący analogiczne
i wymagane procesy.
Propozycja zapisu/żądanie: „1.1.1.2.6. system ma możliwość
obsłużenia w każdym roku co najmniej 400 000 umów co oznacza, iż do systemu mogłyby
zostać wprowadzone dane i mogłyby zostać wygenerowane umowy wynikające z procesu
w wymaganej minimalnej liczbie
”. Alternatywnie - żądanie: zmniejszenie ilości umów,
wprowadzenie innej kategorii do
kumentu niż umowa: „1.1.1.2.6. system obsłużył w każdym
roku co najmni
ej 20 000 umów, aneksów lub innych dokumentów, co oznacza, iż do systemu
zostały wprowadzone dane i zostały wygenerowane umowy, aneksy, bądź inne dokumenty
wynikające z procesu w wymaganej minimalnej liczbie”.
W odniesieniu do przedmiotowego zarzutu zamaw
iający wskazał, co następuje.
Odwołujący postawił dwa alternatywne zarzuty. Odwołujący żąda albo zmiany wymagania
analogicznie jak w zarzucie I.(ix)
– na możliwość obsłużenia wskazanego w warunku
wolumenu umów albo zmniejszenia liczby umów z 400 000 do 20 000 i poszerzenia
wymagania o „aneksy lub inne dokumenty”.
Zamawiający wskazał, że nie może w całości uwzględnić żadnego z żądań, ponieważ
z
amawiający zamierza rocznie obsłużyć (wprowadzić i wygenerować) ok. 2 miliony
dokumentów, wobec czego oczekuje doświadczenia wykonawcy we wdrożeniu systemu,
który realnie obsłużył rocznie co najmniej 400 000 dokumentów (co oznacza, że wdrożył na
tyle wydajny system, który realnie był w stanie obsłużyć większą liczbę dokumentów).
Natomiast pod kątem funkcjonalnym, dla zamawiającego nie ma znaczenia czy te
dokumenty to będą same umowy, czy też aneksy i inne dokumenty, wobec czego
z
amawiający zmienił SWZ częściowo uwzględniając żądanie odwołującego: „1.1.1.2.6.
system obsłużył w każdym roku co najmniej 400 000 umów lub innych dokumentów co
oznacza, iż do systemu zostały wprowadzone dane i zostały wygenerowane umowy lub inne
dokumenty wynikające z procesu w wymaganej minimalnej liczbie”.
Mając na uwadze powyższe, w tym zmianę SWZ, zamawiający wniósł o oddalenie
zarzutu.
Izba w
całości podzielając stanowisko zamawiającego, odnosząc się wspólnie do
zarzutów z pkt 7, 8 i 9 wskazuje za zamawiającym, iż wskazane w warunku minimalne
parametry (liczba użytkowników systemu, wniosków i umów obsługiwanych przez system)
nie mają znaczenia. Są to parametry, które w oczywisty sposób definiują skalę systemu,
a więc wprost mają przełożenie na doświadczenie wykonawców, którzy takie systemy
wdrażali. Teoretycznie można sobie wyobrazić system o niewielkiej wartości czy liczbie
użytkowników, którego wdrożenie wymaga od wykonawcy takiego samego nakładu sił i takiej
samej wiedzy, jak wdrożenie systemu o dużej wartości czy liczbie użytkowników. Jest to
jednak sytuacja czysto hipotetyczna, oderwana od real
iów rynkowych, w których parametry
takie, j
ak cena, liczba użytkowników, wolumen przetwarzanych danych, etc. jednoznacznie
pokazują wielkość systemu, a więc i doświadczenie wykonawcy, który dany system wdrożył,
utrzymywał i rozwijał.
Tym samym
, zarzuty powyższe Izba uznała za bezzasadne.
Punkt 10
– Zarzut dotyczący usunięcia podwarunku, który ogranicza wykonanie
zamówień wyłącznie do podmiotów, które były instytucjami finansowymi w rozumieniu
definicji przytoczonej przez za
mawiającego (pkt. 1.1.1.3).
O
dwołujący wskazał, że postępowanie doznaje istotnego ograniczenia w zakresie strony
podmiotowej potencjalnych wystawców referencji, a zatem eliminuje duży krąg potencjalnego
doświadczenia wykonawców – jako nieadekwatnego z tego powodu dla potrzeb ubiegania
się o to zamówienie. Odwołujący stoi na stanowisku, że ograniczenie możliwego
doświadczenia referencyjnego wyłącznie do zdobytego w realizacji systemów (wdrożeń
i utrzymania) dla instytucji finansowej, d
o tego specyficznie rozumianej (już przykładowo
eliminującej instytucje ubezpieczeniowe) – jest niekonkurencyjne i niczym nieuzasadnione.
Nie jest jasne dlaczego możliwe doświadczenia referencyjne mogą pochodzić wyłącznie
od instytucji finansowej? Do tego
nie każdej. Dlaczego wykonawca mający wdrożony
i utrzymywany system, odpowiadający w całości warunkowi udziału w postępowaniu, lecz
akurat wdrożony u klienta nie będącego instytucja finansową – nie będzie mógł złożyć
oferty?
Dlaczego doświadczenie z wdrożenia/rozwoju i utrzymania takiego samego systemu
(odpowiadającego warunkowi) raz będzie referencyjne i umożliwi złożenie oferty (gdyż
odbiorcą będzie jakaś instytucja finansowa), a raz już nie będzie się można nim posłużyć –
tylko z uwagi na właściwość podmiotową odbiorcy (np. byłby to ubezpieczyciel czy jednostka
finansów publicznych). Odesłanie do definicji instytucji finansowej wymaga ponadto –
zgodnie ze s
pecyfikacją – uwzględnienia wręcz rodzaju prowadzonej działalności
i detalicznych list rodza
ju działalności określonych w odnośnych przepisach Dyrektywy.
Eliminują one niektóre z nich (jak depozyty). W efekcie powstaje niezwykle skomplikowany
zakres możliwego doboru przez wykonawcę doświadczenia/referencji – również w zakresie
doboru samego odb
iorcy. Powyższe jest niczym nieuzasadnione, dodatkowo zawężając i tak
niezwykle złożony i zawężający konkurencyjność warunek udziału w postępowaniu
(niniejszym zarzutem objęty jest JEDEN warunek udziału, choć wydaje się, że kilka, z uwagi
na jego zakres).
Odwołujący rozumie dbałość zamawiającego o odpowiedni dobór
wykonawców – doświadczonych i o dużym potencjalne. Jednakże całościowa analiza
warunku powoduje,
że właściwie nie wiadomo do jakiego kręgu wykonawców kierowane jest
niniejsze zamówienie.
W odniesieniu do przedmiotowego zarzutu
zamawiający wskazał, co następuje.
Odwołujący żąda w całości usunięcia warunku dotyczącego charakteru odbiorcy
zamówienia referencyjnego. Zamawiający nie może zgodzić się na taką zmianę i nie zgadza
się z argumentacją odwołującego. Postawienie wymogu dotyczącego odbiorcy zamówienia
ma znaczenie, ponieważ system, który ma zostać wdrożony, funkcjonalnie jest zbliżony do
systemów funkcjonujących w instytucjach finansowych opisanych w warunku (1.1.1.3 SWZ).
System wdrożony w innych podmiotach nie będzie miał w swoich funkcjonalnościach
charakterystycznych dla instytucji finansowych
procesów takich jak: różne ścieżki
procesowania dla różnych wnioskodawców i różnych produktów, weryfikacja wystąpień na
czarnych listach, analizy krzyżowe wniosków, scoring wniosków, zarządzanie limitami,
stosowanie zabezpieczeń finansowania, przygotowanie i obsługa umów/aneksów,
weryfikacja wniosków o płatność, obsługa odwołań/środków zaskarżenia, windykacja,
obsługa świadczeń w oparciu o kursy walut itd. Jednakże, czyniąc zadość części zarzutu
z odwołania drugiego odwołującego się wykonawcy – Asseco Poland S.A., zamawiający
poszerz
ył definicję odbiorcy zamówienia dopuszczając wykazanie referencji od ARiMR.
Zam
awiający zmienił SWZ w następujący sposób „1.1.1.3. zamówienia były wykonane dla
Agencji Restrukturyzacji i Modernizacji Rolnictwa lub dla instytucji finansowych, przez co
należy rozumieć: przedsiębiorstwo inne niż instytucja, którego podstawową działalnością jest
nabywanie pakietów akcji lub wykonywanie co najmniej jednego spośród rodzajów
działalności wymienionych w pkt 2–12 i pkt 15 załącznika I do dyrektywy 2013/36/UE,
pojęcie to obejmuje finansowe spółki holdingowe, finansowe spółki holdingowe o działalności
mi
eszanej, instytucje płatnicze w rozumieniu dyrektywy 2007/64/WE Parlamentu
Europejskiego i Rady z dnia 13 listopada 2007 r. w sprawie usług płatniczych w ramach
rynku (1) i spółki zarządzania aktywami, nie obejmuje jednak ubezpieczeniowych spółek
holdingow
ych i ubezpieczeniowych spółek holdingowych prowadzących działalność
mieszaną.”.
Mając na uwadze powyższe, zamawiający wniósł o oddalenie zarzutu.
Zdaniem
Krajowej Izby Odwoławczej zarzut jest zasadny. W zakresie omawianego
zarzutu, Izba odwołuje się do argumentacji przywołanej jak w odwołaniu o sygn. akt KIO
Zakres II (kryteria oceny ofert -
próbka).
Punkt A
– Zamawiający wymaga przygotowania i przeprowadzenia próbki systemu.
Zgodnie z kryterium „gotowość Systemu” pkt.1.3 w rozdziale XI SWZ, zamawiający będzie
oceniał:
gotowość Sytemu, tj. dostępną w systemie wymaganą funkcjonalność oraz
gotowość Systemu do modyfikacji i konfiguracji w zakresie opisanym w Załączniku nr
1 do Formularza Ofertowego stanowiącego Załącznik nr 1 do SWZ, bez konieczności
programowania, na podstawie weryfikacji
próbki.
Wykonawca otrzyma jeden punkt procentowy za każdą wybraną przez zamawiającego
funkcjona
lność (ze zbioru wszystkich funkcjonalności), która będzie dostępna bez
konieczności kodowania podczas testowania próbki, przy czym nie więcej niż 40 punktów.
Celem z
amawiającego jest zakup Systemu opartego o Oprogramowanie Standardowe
w zakresie zdefinio
wanym szczegółowo w SWZ. Na potrzeby badania Próbki Systemu
z
amawiający definiuje dwie grupy wymagań:
Grupa A
– wymagania, które muszą być spełnione przez Oprogramowanie Standardowe
w dniu złożenia oferty i będą na ten dzień opisane w dokumentacji Oprogramowania
Standardowego. Brak spełniania tych wymagań przez System będzie jednoznaczny
z odrzuceniem oferty.
Grupa B
– wymagania, które muszą być spełnione przez System w dniu podpisania
protokołu odbioru wdrożenia Procesu Głównego i będą na ten dzień opisane w dokumentacji
Systemu. Spełnianie wymagań z tej Grupy przez Oprogramowanie Standardowe na dzień
składania Ofert może zostać zadeklarowane przez wykonawcę i będzie punktowane
w ramach kryteriów oceny ofert.
W grupie A znalazło się 50 wymagań obligatoryjnych, natomiast w grupie B znalazło się
17 wymagań fakultatywnych, za których spełnienie na dzień składania oferty zamawiający
przyzna po 1 punkcie procento
wym z możliwych 40 punktów do zdobycia. Jednocześnie
z
amawiający określił zasady zaproszenia na badanie Próbki, z których wynika, że nie
zostaną na Próbkę zaproszeni wykonawcy, którzy nie zadeklarują spełnienia wymagań
z Grupy A i B (załącznik 9.1 Przebieg badania Próbki systemu, pkt.2 lit. a.). Nie wystarczy
zatem zadeklarowanie spe
łniania wymagań z grupy A, ale także z fakultatywnej grupy B.
Żądanie: Modyfikacja zapisów tak, aby możliwe było uzyskanie zaproszenia do Próbki
także w przypadku zadeklarowania tylko spełniania wymagań z Grupy A.
Zgodnie z Harmonogramem i sposobem przeprowadzenia badan
ia Próbki (pkt 3
załącznika 9.1) zamawiający wybierze tylko część wymagań z grupy A do zaprezentowania
w Etapie I razem z prezentacją przejścia całego Scenariusza Próbki Systemu. Jednocześnie
zgodnie z Informacjami dotyczącymi badania Próbki Systemu (pkt. 4 zał. 9.1) zamawiający
podtrzymuje, że wykonawca musi wykazać spełnienie wszystkich wymagań z grupy A pod
rygorem odrzucenia oferty oraz zadeklarowanych przez w
ykonawcę z wymagań z grupy B
pod rygorem nieprzyznania określonej liczby punktów. Zatem zamawiający oczekuje
zaprezentowania i wykazania spełnienia wszystkich wymagań z Grupy A podczas wszystkich
trzech etapów, czyli w czasie 7 godzin. Jednocześnie nieprecyzyjnie określił przebieg
badania zgodności wymagań z grupy A dzieląc je na Etap I i Etap II i opisując, że dokona
w nieznany, nieujawniony i mogący prowadzić do nierównego traktowania sposób wyboru
części wymagań w Etapie I – nie została określona ich ilość oraz 8 wymagań w Etapie II.
Ze względu na czasy trwania tych etapów – Etap I 1,5h, a etap II 2h, można wysnuć
wniosek, że zamawiający przeznacza średnio 15 minut na zbadanie jednego wymagania
z grupy A w etapie II (2h=120m/8=15m). Etap I posiada opis
any w załączniku 9.3 scenariusz
badania procesu nazwany mylnie „Scenariuszem Próbki Systemu” składający się z dwóch
przebiegów o 25 i 16 krokach. Wynika z tego, że zamawiający przeznaczył średnio niespełna
2 minuty i 12 sekund na przejście każdego z kroków scenariusza badania procesu (1,5h=90
minut/41 = 12 minut i 11,7 sekund). Oba te czasy wy
dają się racjonalne i akceptowalne,
jednak dodatkowo wnioskować należy, że w Etapie I zamawiający zamierza zbadać
zgodność pozostałych 42 wymagań z grupy A (50-8=42), na co powinien przeznaczyć 10,5
godziny dodatkowego czasu (42*15=630/60=10,5).
Żądanie: Zmiana zakresu Etapów Próbki tak, aby zakres był klarowny i sprawiedliwy dla
wszystkich poprzez usunięcie z Etapu pierwszego badania wymagań z grupy A (ponieważ
etap
ten służy badaniu przejścia całego Scenariusza Próbki Systemu) oraz wskazania już na
etapie prz
ygotowywania oferty i przygotowywania Próbki konkretnych 8, dla wszystkich
wykonawców jednakowych wymagań z grupy A podlegających badaniu w Etapie II.
W odniesieniu do przedmiotowego zarzutu
zamawiający wskazał, co następuje.
Odwołujący w ramach zarzutu II. A. postawił faktycznie dwa oddzielne zarzuty (oddzielne
żądania). W ramach pierwszego zarzutu odwołujący twierdzi, że zamawiający określił zasady
zaproszeni
a na badanie Próbki z których wynika, że nie zostaną na Próbkę zaproszeni
wykonawcy, którzy nie zadeklarują spełnienia wymagań z grupy A i B, podczas gdy grupa B
zawiera wymagania fakulta
tywne, za które są przyznawane punkty. Zamawiający uwzględnił
w tym zakresie zarzut i zmieni
ł SWZ w taki sposób, aby z SWZ jednoznacznie wynikało, że
zaproszenie
do badania Próbki otrzymają także wykonawcy, którzy zadeklarują wyłącznie
spełnienie wymagań z grupy A. Po zmianie pkt 2 lit. a Załącznika 9.1 do SWZ będzie miał
następujące brzmienie:
„2. Zasady zaproszenia na badanie Próbki.
a. a. Na badanie Próbki zostaną zaproszeni Wykonawcy, którzy w Załączniku 1 do
Formularza Ofertowego stanowiącego Załącznik 1 do SWZ zadeklarują na dzień składania
oferty spełnienie wymagań z Grupy A oraz z grupy B, jeśli w ramach Grupy B Wykonawca
zadeklarował „TAK” w załączniku nr 1 do Formularza Ofertowego stanowiącego Załącznik 1
do SWZ w kolumnie „Czy spełnione przez Oprogramowanie Standardowe w dniu składania
ofert (TAK/NIE)
”.
W drugiej części zarzutu odwołujący żąda:
a.
zmiany zakresu Etapów Próbki tak, aby zakres był klarowny i sprawiedliwy dla
wszys
tkich, poprzez usunięcie z Etapu pierwszego badania wymagań z grupy A, oraz
b. wskazan
ia już na etapie przygotowania oferty i Próbki konkretnych 8, dla wszystkich
wykonawców jednakowych wymagań z grupy A podlegających badaniu w Etapie II.
Zamawiający wskazał, iż nie może zgodzić się z żądaniami odwołującego, ponieważ takie
same wymagania z grupy A będą badane u wszystkich wykonawców, zatem zakres badania
jest sprawiedliwy i równy dla wszystkich. Zamawiający dokonał odpowiednich zmian w SWZ
w celu ro
zwiania wszelkich wątpliwości, dodając następujące postanowienia do Załącznika
nr 9.1 do SWZ:
„Etap II – badanie 8 wskazanych przez Zamawiającego wymagań
funkcjonalnych z Grupy A , spośród tych, które muszą być spełnione przez Oprogramowanie
Standardowe n
a dzień złożenia oferty i których sposób wykonania musi zostać
zaprezentowany podczas weryfi
kacji Próbki.
a.
Wymagania wybrane do tego etapu przez Zamawiającego spośród wymagań z Grupy
A oraz oczekiwania w zakresie ich spełnienia zostaną wskazane Wykonawcy na początku
spotkania badania Próbki. Każdy z Wykonawców otrzyma do zaprezentowania taki sam
zestaw wymagań i oczekiwań w zakresie ich spełnienia.
b.
Spełnienie wszystkich 8 wybranych przez Zamawiającego wymagań funkcjonalnych
musi z
ostać zaprezentowane przez Wykonawcę, co jest warunkiem otrzymania wyniku
pozytywnego w tej części testów.
c. Na Etap II przewidziano 2 godziny.
Etap III
– badanie 17 wymagań funkcjonalnych (Grupa B), których spełnienie przez
Oprogramowanie Standardowe warunkuje przyznan
ie punktów w kryterium Gotowości
Systemu. Wymagania te należą do grupy zadeklarowanych przez Wykonawcę jako
spełnione w Załączniku 1 do Formularza Ofertowego stanowiącego Załącznik 1 do SWZ.
Złożenie takiej deklaracji przez Wykonawcę jest równoznaczne z tym, że oferowane
Oprogramowanie Standardowe spełnia dane wymaganie funkcjonalne już na dzień złożenia
oferty i możliwa jest weryfikacja jego spełnienia poprzez badanie Próbki zgodnie z niniejszym
Załącznikiem.
a. Podczas badania Próbki Wykonawca zaprezentuje jedynie te spośród 17 wymagań
funkcjonalnych, które zadeklarował jako spełnione w Załączniku 1 do Formularza
Ofertowego stanowiącego Załącznik 1 do SWZ. Każdy z Wykonawców otrzyma do
zaprezentowania taki sam zestaw wymagań i oczekiwań w zakresie spełnienia
zadeklarowanych wymagań.
b.
Na początku spotkania badania Próbki do wymagań z Grupy B wskazanych przez
Wykonawcę, Zamawiający przekaże oczekiwania w zakresie ich spełnienia.
c.
Wykaz wymagań z Grupy B oraz punktacja za ich spełnianie zdefiniowany został w
Załączniku A2 – Opis Wymagań Systemu Informatycznego do Umowy Wdrożeniowej.
d. War
unkiem otrzymania punktów w tej części testów jest wykazanie przez Wykonawcę
spełnienia wymagań z Grupy B, które zadeklarował jako dostępne w Systemie na dzień
składania ofert w Załączniku 1 do Formularza Ofertowego stanowiącego Załącznik 1 do
SWZ.
e. W
przypadku wykazania w Załączniku 1 do Formularza Ofertowego stanowiącego
Załącznik 1 do SWZ spełnienia danego wymagania Wykonawca otrzyma maksymalną liczbę
punktów jaką może uzyskać za dane wymaganie. W przypadku, gdy Wykonawca nie wykaże
spełnienia danego wymagania, nie otrzyma za nie punktów.
f.
Na Etap III przewidziano 3,5 godziny.
”.
Dla Etapu I w punkcie b zastosowano analogiczny zapis jak dla
Etapu II wskazujący,
że każdy wykonawca będzie przechodził weryfikację tych samych wymagań.
„b) Wymagania wybrane do tego etapu przez Zamawiającego zostaną wskazane
Wykonawcy na początku spotkania badania Próbki. Każdy z Wykonawców otrzyma do
zaprezento
wania taki sam zestaw wymagań i oczekiwań w zakresie ich spełnienia.”
Zakres badania
Próbki jest także klarowny, ponieważ wykonawcy już na etapie składania
ofert mają wiedzę jakie wymagania mogą być badane w ramach Próbki. Zamawiający nie
będzie badał wszystkich wymagań, tylko wybrane przez siebie z dostępnej listy wymagań.
Jeżeli wykonawcy mieli jakiekolwiek wątpliwości, co do sposobu lub zakresu badania
konkretnych wymagań (w tym czasu badania), to zarówno mogli w tym zakresie złożyć
odwołanie jak i zadać odpowiednie pytania dotyczące konkretnych wymagań. Zamawiający
nie może ujawnić, które wymagania będą badane, gdyż przeczyłoby to idei prezentacji
próbki. Zamawiający chce otrzymać gotowe rozwiązanie, które będzie posiadało wymagane
funkcjonalności. Skoro zatem próbka nie będzie posiadała tych funkcjonalności, to znaczy,
że system nie spełnia wymagań SWZ. Ujawnienie na etapie sporządzenia oferty wymagań,
które będą badane, mogłoby skutkować tym, że wykonawcy „napiszą” system specjalnie pod
próbkę i zamawiający nie otrzyma gotowego rozwiązania zawierającego oczekiwane
funkcjonalności.
Mając na uwadze powyższe, zamawiający częściowo uwzględnił zarzut oznaczony jako II.
A (w zakresie pierwszego żądania) i wniósł o oddalenie zarzutu w pozostałym zakresie.
Zdaniem
Krajowej Izby Odwoławczej zarzut jest bezzasadny.
Podzielając w całości argumentację zamawiającego, Izba wskazuje, że celem
postępowania jest nabycie rozwiązania ustandaryzowanego, w formule „out of the box”, czyli
takiego, które jest oferowane na rynku jako standardowy produkt. Z wiedzy zamawiającego
wynika, że tego rodzaju rozwiązania istnieją i są z powodzeniem stosowane w dużych
instytucjach fin
ansowych. Budowa Centralnego Systemu Obsługi Beneficjenta (CSOB) na
bazie uznanych platform workflow (BPM
) jest jednym z głównych celów strategicznych
wprost wskazanym w Strategii IT. Wynika to zarówno z dążenia do zapewnienia stabilności
i przewidywalności rozwiązania (budowa w oparciu o istniejące na rynku i zweryfikowane
komponenty), jak i z konieczności zapewnienia interoperacyjności oraz możliwości
samodzielnego obsługiwania i rozwoju systemu przy wykorzystaniu standardowych narzędzi.
Z tego względu w postępowaniu postawiono szereg wymagań, których spełnienie
w standardowym oprogramowaniu jest konieczne (wymagania z Grupy A).
Zamawiający
wskazał, że zdaje sobie sprawę z tego, że budowa rozwiązania o specyfice i skali takich jak
CSOB, może wymagać nie tylko dostosowania istniejącego narzędzia, ale również jego
rozbudowy o komponenty konieczne dla zamawiaj
ącego, ale nie występujące
w standardowym produkcie. Z tego względu zamawiający zdefiniował szereg wymagań,
których spełnienie jest wprawdzie konieczne, ale dopuszczalne jest w tym celu
rozbudowanie standardowej wersji oprogramowania (wymagania z Grupy B). Z punktu
widzenia potrzeb z
amawiającego im bardziej ustandaryzowany jest produkt (im więcej
funkcjonalności posiada w standardowej wersji, bez konieczności rozbudowy), tym lepiej.
Dlatego z
amawiający przewidział kryterium oceny ofert, w ramach którego przyznaje punkty
takim rozwiązaniom, które posiadają najwięcej wymagań w wersji standardowej. Z uwagi na
fakt, iż celem zamawiającego jest dokładna weryfikacja ofert i wybór narzędzia, który
faktycznie będzie spełniał zdefiniowane w SWZ wymagania i kryteria, zamawiający
przewidział w SWZ procedurę badania próbki systemu. Cele tej procedury są dwa:
1) weryfikacja, czy standardowa wersja oprogramowania posiada wymagane
funkcjonalności (prowadzona poprzez „wyrywkowe” badanie, a więc testowanie w
ramach próbki jedynie wybranych funkcjonalności z Grupy A), oraz
2) w
eryfikacja, czy wszystkie funkcjonalności, które zostały przewidziane w ramach
kryterium pozacenowego i zostały przez wykonawców zadeklarowane jako spełnione
w wersji standardowej, są faktycznie zapewnione przez standardową wersję
oprogramowania.
Dodatkowo, za
zamawiającym podnieść należy, że twierdzenia odwołującego są
bezpodstawne, ponieważ zamawiający w żadnym miejscu w SWZ nie zamieścił informacji
o tym, że będzie badał wszystkie wymagania z grupy A w ramach próbki w Etapie I. Punkt 4
dotyczy skutku niewykazania spełnienia wszystkich badanych wymagań. Ponadto, po
zmianie SWZ z
amawiający wprost wskazał, że będzie badał u wszystkich wykonawców te
same wymagania z grupy A, co także oznacza, że nie będą badane wszystkie wymagania,
lecz te,
które wskaże zamawiający (takie same u wszystkich wykonawców). Fakt,
że zamawiający nie będzie badał wszystkich wymagań z grupy A w ramach próbki w Etapie I
wynika także z opisu scenariusza znajdującego się w Załączniku nr 9.3 – Warunki Wstępne
i Scenariusz Próbki Systemu. Jeżeli odwołujący prześledziłby cały przebieg procesu oraz
oczekiwane rezultaty (od str. 7 Załącznika 9.3) to już z tego scenariusza wynika, że nie
wszystkie wymagania z grupy A będą badane w Etapie I. Przykładowo, z przebiegu procesu
wynika, że zamawiający nie będzie badał wymagań A08, B02, B07. Ponadto, w Załączniku
9.1, w opisie Etapu I lit. a. jest wskazane, że Proces Biznesowy przygotowany przez
z
amawiającego został zamodelowany w taki sposób, aby wykonawca mógł zaprezentować
spełnienie wybranych przez zamawiającego wymagań funkcjonalnych z Grupy A spośród
tych, które muszą być spełnione przez Oprogramowanie Standardowe na dzień złożenia
oferty.
Łącznie wymagań dla Grupy A jest 42 (wartość pomniejszona o wymagania RODO
przeniesione do Grupy C), a przy uwzględnieniu 8 zaplanowanych do sprawdzenia na etapie
II pozostaje 34. Uwzględniając uwarunkowania wynikające ze scenariusza, o którym
wspomniano
powyżej, w ramach Etapu I nie będzie możliwe sprawdzenie wszystkich tych
wymagań. Scenariusz w zasadzie wprost definiuje, które z wymagań mogą być
zweryfikowane i profesjonalny w
ykonawca nie powinien mieć żadnego problemu
z ustaleniem, o które wymagania chodzi.
Zdaniem Izby,
nie można się również zgodzić z żądaniem odwołującego, dotyczącym
wcześniejszego przekazania wykonawcom konkretnych 8 (lub innej liczby) wymagań z grupy
A, gdyż mogłoby to skutkować tym, że zamiast funkcjonalności oferowanych w standardzie,
wykonawcy napiszą funkcjonalności specjalnie na potrzeby próbki, co byłoby wprost
sprzeczne z wyraźnie komunikowaną potrzebą nabycia rozwiązania maksymalnie
ustandaryzowanego.
Punkt C
– Brak możliwości powtórzenia części prezentacji Próbki Systemu oraz brak
możliwości przeprowadzenia przerwy technicznej.
Zdaniem
odwołującego, przedstawione w SWZ przebieg badania Próbki Systemu
wskazuje, iż zamawiający nie będzie informował wykonawcy o spełnianiu wyniku oceny
zaprezentowanej funkcjonalności, (Załącznik nr 9.1 do SWZ, pkt 4, ppkt e). Ponadto
z
amawiający nie przewiduje żadnej możliwości powtórzenie części prezentacji w przypadku
niepowodzenia
spowodowanego niezależnymi od wykonawców zdarzeniami losowymi, jak
np. niespodziewana awaria sprzętu lub przerwa w dostawie energii elektrycznej (Załącznik nr
9.1 do SWZ, pkt 4, ppkt o).
Przedstawione w SWZ przebieg badania Próbki Systemu nie
przewiduje również żadnej możliwości przeprowadzenia przerwy technicznej w przypadku
niespodziewanej awarii infrastruktury spr
zętowo-systemowej lub komunikacyjnej stanowiącej
środowisko uruchomieniowe prezentowanego Systemu. Podejście takie rodzi poważne
ryzyko nie
wykazania spełniania wszystkich wymagań w wymaganym czasie ze względu na
zdarzenia losowe, których nie da się przewidzieć z wyprzedzeniem. Zdarzeniami takimi
mogą być przykładowo: przerwa w dostawie energii elektrycznej, przerwa w łączności
internetowej, a
waria sprzętowa, niespodziewany błąd działania systemu operacyjnego lub
konieczność wprowadzenia zmian konfiguracyjnych w celu dostosowania systemu do
importu otrzymanego od z
amawiającego zestawu danych. Brak informowania wykonawcy
o wyniku oceny prezentowanych elementów scenariusza badania Próbki Systemu podczas
prezentacji oraz uniemożliwienie ewentualnego ponownego zaprezentowania elementu
scenariusza badania Próbki Systemu rodzi poważne ryzyko, iż zamawiający odrzuci ofertę
tylko i wyłącznie z powodu niezrozumienia lub błędnego zrozumienia prezentowanego
elementu scenariusza lub niezaobserwowana prezentowanych treści, podczas gdy
prezentowana Próbka Systemu spełniała będzie wszystkie wymagania wskazane w SWZ.
Podejście takie ponadto stanowi sposobność do manipulacji oraz nadużyć przy ocenie ofert.
Zamawiający post-factum będzie mógł odrzucić lub przyznać mniej punktów ofercie jedynie
ze względu na fakt, iż dane funkcjonalność została zaprezentowana w sposób budzący
wątpliwości zamawiającego wynikający tylko i wyłącznie z błędnego zrozumienia
prezentowanych treści lub nieprecyzyjnego omówienia prezentowanych treści. Należy
podkreślić, iż przedmiotem badania Próbki Systemu nie jest sposób prezentacji
zapewniający precyzyjne omówienie wszelkich aspektów technicznych wynikających
z prezentowanyc
h funkcjonalności, tylko oferowany system informatyczny w celu oceny:
1) gotow
ości Sytemu, tj. dostępnej w systemie wymaganej funkcjonalność oraz
gotowości Systemu do modyfikacji i konfiguracji w zakresie opisanym w Załączniku nr
1 do Formularza Oferto
wego stanowiącego Załącznik nr 1 do SWZ, bez konieczności
programowania, na pod
stawie weryfikacji próbki.
Zamawiający powinien dążyć do jak najbardziej obiektywnej oceny oraz rozwiania
wszelkich wątpliwości podczas samej prezentacji, a nie gromadzenie wątpliwości, które
mogą wynikać z błędnego zrozumienia prezentowanych treści oraz dokonanie oceny post-
factum. W przypadku informowania wyk
onawców o wyniku oceny każdej ocenianej
funkc
jonalności oraz umożliwieniu powtórzenia prezentacji danego elementu w przypadku
oceny negatywnej, z
amawiający zapewni możliwość ponownego zaprezentowania danej
funkcjonalności w inny sposób, który może rozwiać wszelkie wątpliwości zamawiającego.
Takie
podejście jest standardem rynkowym i jest stosowane jest przez niemal wszystkich
z
amawiających stosujących prezentację próbek Systemu podczas oceny ofert. Na poparcie
ww. twierdzenia
odwołujący wskazał kilka przykładów postępowań, w których zamawiający
zapewnili bieżące informowanie wykonawcy o wyniku oceny elementów prezentacji próbki
systemu wraz z możliwością przeprowadzenia ponownej prezentacji wybranego elementu.
Zapewnienie w
ykonawcy możliwości skorzystania z przerwy technicznej podczas
prezentacji próbki systemów informatycznych jest działaniem standardowo stosowanym
przez zamawiających podczas oceny próbek systemów.
Żądanie:
1. Modyfikacja S
WZ poprzez nadanie następującego brzmienia zapisowi SWZ –
Załącznik nr 9.1 do SWZ, pkt 4, ppkt e): „W trakcie badania Próbki Systemu Zamawiający
będzie informował Wykonawcę o spełnieniu oczekiwań w kontekście zaprezentowanego
wymagania
”,
2. Modyfikacja SW
Z poprzez nadanie następującego brzmienia zapisowi SWZ –
Załącznik nr 9.1 do SWZ, pkt 4, ppkt o): „W przypadku wystąpienia awarii lub błędu
w działaniu sprzętu i oprogramowania, które Wykonawca będzie wykorzystywał do
przeprowadzenia badania Próbki, Wykonawca może, celem usunięcia awarii, błędu lub
dokonania zmian konfig
uracyjnych, poprosić o zatrzymanie czasu prezentacji. Łączny czas
trwania dokonywania takich zmian lub napraw
y nie może przekroczyć jednej godziny.”
3. Modyfikacja SWZ poprzez dodanie zap
isu dotyczącego przebiegu badania Próbki
Systemu: „W przypadku niespełnienia oczekiwań w kontekście zaprezentowanego
wymagania, Zamawiający informuje Wykonawcą o powodzie niespełnienia oczekiwań
w kontekście zaprezentowanego wymagania oraz Wykonawcy przysługuje prawo do
ponownego zaprezentowanie realizacji wymagania. Przeprowadzenie ponownej weryfikacji
nie skutkuje przedłużeniem wyznaczonego czasu badania Próbki Systemu.”
W odniesieniu do przedmiotowego zarzutu
zamawiający wskazał, co następuje.
Od
wołujący w ramach zarzutu II. C. stawia trzy niezależne żądania.
Po pierwsze, o
dwołujący wskazał na ryzyko niewykazania spełnienia wszystkich
wymagań podczas prezentacji Próbki ze względu na zdarzenia losowe oraz brak możliwości
powtórzenia badania (żądanie nr 2, część 1 uzasadnienia). Odwołujący żąda umożliwienia
zatrzymania p
rezentacji na czas nie dłuższy niż 1 godzina. Zamawiający stoi na stanowisku,
że odpowiedzialność za prawidłowe przygotowanie próbki spoczywa na wykonawcy i nie jest
możliwe powtórzenie testu w razie jego niepowodzenia. Jednakże, wychodząc naprzeciw
oczekiwaniom wykonawcy, z
amawiający umożliwi zatrzymanie prezentacji i w związku z tym
dokona
ł zmiany SWZ, wprowadzając dodatkowo (obok istniejących postanowień)
następujące, zaproponowane przez odwołującego postanowienie:
„Załącznik nr 9.1 do SWZ, pkt 4, ppkt o): Wykonawca ponosi wyłączną odpowiedzialność
na zasadzie ryzyka za prawidłowe działanie sprzętu i oprogramowania, które będzie
wykorzystywał do przeprowadzenia badania Próbki. Skutki ewentualnych nieprawidłowości
w działaniu sprzętu lub oprogramowania Wykonawcy, w tym m.in. awarii, błędów, problemów
z dostępem do internetu etc. obciążają wyłącznie Wykonawcę i nie mogą stanowić podstawy
powtórzenia badania Próbki innego dnia. Nie mniej w przypadku wystąpienia awarii lub błędu
w działaniu sprzętu i oprogramowania, które Wykonawca będzie wykorzystywał do
przeprowadzenia badania Próbki, Wykonawca może, celem usunięcia awarii, błędu lub
dokonania zmian konfiguracyjnyc
h, poprosić o zatrzymanie czasu prezentacji. Łączny czas
trwania dokonywania takich zmian lub
naprawy nie może przekroczyć jednej godziny.”.
Z
amawiający podniósł, iż w ramach pierwszego i trzeciego żądania odwołujący chce
wprowadzenia przez z
amawiającego bieżącej oceny i weryfikacji wymagań podczas
prezentacji Próbki, co uzasadnia ryzykiem odrzucenia oferty z powodu niezrozumienia lub
błędnego zrozumienia prezentowanego wymagania. Twierdzenia i obawy odwołującego są
bezpodstawne, ponieważ przebieg badania Próbki będzie utrwalony (w celu rozwiania
wątpliwości zamawiający zmienił treść Załącznika 9.1 pkt 4 lit. f poprzez zmianę z „zastrzega
sobie możliwość utrwalania” na „utrwali”), a w razie uznania przez odwołującego, że jego
oferta została bezpodstawnie odrzucona na skutek „niezrozumienia” lub „błędnego
zrozumienia” prezentowanego wymagania, będą mu służyły środki odwoławcze zgodnie
z ustawą PZP. Ponadto prezentacja Próbki będzie oceniana przez komisję i nie jest możliwe,
aby po prezentacji każdego wymagania, komisja zbierała się na naradę i po naradzie
informowała wykonawcę o wyniku oceny spełnienia konkretnego wymagania wraz
z uzasadnieniem. Jak już wskazano we wstępie, to zamawiający jest gospodarzem
p
ostępowania i działając w ramach prawa, może ustalić w jaki sposób będzie przebiegało
badanie Próbki. Odwołujący nie uzasadnił w jaki sposób brak bieżącej weryfikacji wymagań
narusza przepisy PZP.
Mając na uwadze powyższe, w tym zmianę SWZ, zamawiający wniósł o oddalenie
zarzutu.
Zdaniem
Krajowej Izby Odwoławczej zarzut jest bezzasadny. Zdaniem Izby, proces oceny
złożonych próbek odpowiada obecnie obowiązującym standardom i brak jest podstaw do
twierdzenia przeciwnego. Jak słusznie wskazał zamawiający, nie ma możliwości
automatycznej weryfikacji prezentowanych wymagań (ze względu na ich specyfikę).
Spełnienie każdego wymagania nie jest tylko czynnością techniczną, ale wymaga oceny
komisji, która musi podjąć wspólną decyzję. Cała procedura weryfikacji będzie przebiegała
zgodnie przepisami Prawa zamówień publicznych, a niespełnienie wymagań będzie albo
skutkowało odrzuceniem oferty (w przypadku wymagań z grupy A) albo nieprzyznaniem
punktów (w przypadku wymagań z grupy B). Interes odwołującego jest więc wystarczająco
zabezpieczony poprzez możliwość wniesienia środka ochrony prawnej oraz poprzez fakt,
iż przebieg badania będzie rejestrowany.
Punkt D
– Aktualnie w załącznikach nr 9.1, 9.2, 9.3 znajduje się opis sposobu
przygotowania i wymagania w zakresie próbki, nigdzie natomiast nie jest przedstawiony
dokładny scenariusz badania próbki dla wymagań Grupy A i B. Zamawiający publikuje
jednak scenariusz ba
dania próbki dla Procesu Głównego i w zakresie sposobu weryfikacji
wskazuje (Załącznik 9.1). Aktualnie brakuje scenariusza badania próbki w zakresie Grupy
wymagań A i B (czyli w ramach Etapów II i III) i w związku z tym, iż wymagania te zostały
opisane w s
posób pozostawiający szerokie pole do dowolnej interpretacji, co jest
niedopuszczalne w trakcie procesu weryfikacji oprogramowania, o
dwołujący nakazuje
z
amawiającemu przygotowanie dedykowanych scenariuszy badania dla wszystkich
wymagań z zakresu A i B. Dodatkowo odwołujący zauważył, iż zamawiający wskazuje,
iż po prezentacji danego wymagania nie będzie informował o pozytywnym, czy negatywnym
wyniku prezentacji tegoż wymagania, co przy obecnym, nie precyzyjnym sformułowaniu ich
treści, daje prawo zamawiającemu w zasadzie w dowolny sposób dokonać oceny oferty
wykonawcy i doprowadzić do odrzucenia oferty wykonawcy. Odwołujący zwrócił uwagę,
iż duża liczba wymagań została opisana w sposób nieprecyzyjny lub uniemożliwiający
prezentację w całości tego wymagania w trakcie prezentacji próbki. Dodatkowo zamawiający
w sposób niedopuszczalny wskazuje, iż swoje oczekiwania w zakresie spełnienia wymagań
dla Grup wymagań A i B, przekaże na początku spotkania. Jest to niedopuszczalne ze
względu na konieczność właściwego przygotowania odwołującego do prezentacji próbki.
Scenariusz prezentacji, wraz z oczekiwaniami zamaw
iającego w zakresie ich spełnienia,
powinien zostać przedstawiony przed terminem składania ofert wraz z opisem przebiegu
Próbki.
Żądanie: Nakazanie zamawiającemu opublikowanie w celu przygotowania Próbki
precyzyjnego scenariusza dla Etapów II i III badania Próbki wraz z oczekiwaniami
z
amawiającego w zakresie ich spełnienia, czyli precyzyjnymi kryteriami oceny spełniania
każdego wymagania (dla każdego wymagania kryteria spełniania wymagania przez Próbkę),
które są niezbędne do przygotowania i weryfikacji Grupy wymagań A i Grupy wymagań B.
W odniesieniu do przedmiotowego zarzutu
zamawiający wskazał, co następuje.
Z
amawiający podniósł, iż odwołujący wskazuje, że zamawiający nie udostępnił
scenariusza badania próbki w ramach Etapu II i III i jest to jego zdaniem niedopuszczalne
(nie wskazując przy tym w jaki sposób narusza to przepisy PZP), ze względu na to,
że wymagania zostały opisane w sposób nieprecyzyjny lub uniemożliwiający prezentację
w całości wymagania w ramach próbki. Jednocześnie odwołujący nie powołuje się na
konkretne wymagania, które są jego zdaniem nieprecyzyjne lub uniemożliwiające
prezentację.
Zamawiający wskazał, że nie udostępnia scenariuszy testów ponieważ celem badania
Próbki jest weryfikacja, czy zaoferowane rozwiązanie spełni wymagania. Udostępnienie
scenariuszy testów może spowodować, że wykonawca zamiast zaoferowania gotowego
rozwiązania, napisze program pod testy. Natomiast na rynku są dostępne rozwiązania, przy
k
tórych możliwa jest weryfikacja wskazanych wymagań ad hoc, bez wcześniejszego
dodatkowego programowania.
Zamawiający nie naruszył żadnych przepisów PZP
zamierzając przeprowadzić wyrywkowy test wymagań, bez udostępnienia scenariuszy
testów. Wszyscy wykonawcy zaproszeni do prezentacji otrzymają taki sam zestaw wymagań
i oczek
iwań, zatem wszyscy wykonawcy będą w takiej samej sytuacji. Ponadto, jeżeli któreś
z wymagań jest tak jak wskazuje odwołujący – nieprecyzyjne lub niemożliwe do weryfikacji,
to powinien j
e wprost wskazać. Zamawiający, gdy powziął informację (z dalszej części
o
dwołania) o tym, że któreś z wymagań jest niemożliwe do weryfikacji podczas prezentacji
Próbki lub jest szczególnie problematyczne ze względów organizacyjnych (np. prezentacja
na kilku
przeglądarkach), to w tym zakresie dokonał odpowiednich zmian SWZ. Ponadto
jeszcze przez zaproszeniem do prezentacji Próbki zamawiający wymaga oświadczenia
o spełnieniu wskazanych w SWZ wymagań, co oznacza, że do prezentacji zostaną
zaproszeni wyłącznie wykonawcy, których rozwiązania posiadają wymagane funkcjonalności
i nie
mają w tym zakresie wątpliwości.
Mając na uwadze powyższe, zamawiający wniósł o oddalenie zarzutu.
Zdaniem
Krajowej Izby Odwoławczej zarzut jest bezzasadny. Izba wskazuje, że celem
badania p
róbki, jest stwierdzenie prawdziwości oświadczeń składanych przez wykonawcę.
Skoro zatem wykonawca o
świadczy, że próbka spełnia określonego wymagania, to nie
powinien mi
eć zastrzeżeń czy wątpliwości, co do czynności zamawiającego, który w zakresie
złożonego oświadczenia będzie badał zaoferowane funkcjonalności. Jak słusznie podniósł
zamawiający, chce on nabyć rozwiązanie ustandaryzowane, tj. takie, które posiada jak
najwięcej funkcjonalności w standardzie. Jeżeli zamawiający udostępniłby wykonawcom
pełen scenariusz (konkretne wymagania z grupy A, które będzie weryfikował wraz
z oczekiwaniami w zakresie ich spełnienia), to istniałoby ryzyko, że wykonawcy napiszą
(zaprogramują) próbkę systemu konkretnie pod prezentację i nie zaoferują zamawiającemu
rozwiązania, który oferuje wymagane funkcjonalności w standardzie. Przekazanie z góry
scenariusza badania stawia pod znakiem zapytania sens prowadzenia samego badania,
które ma na celu weryfikację zdolności standardowego oprogramowania do szybkiej
parametryzacji i konfiguracji, czyli
cechy kluczowej dla przyszłej eksploatacji systemu przez
z
amawiającego.
Punkt E
– Zamawiający w ramach weryfikacji próbki – Wymaganie z Grupy A wskazuje:
„A01. Dostęp do Systemu musi być możliwy we wszystkich wymienionych przeglądarkach
internetowych: MS Edge, Firefox, Chrome ze wsparciem wstecznym
dwóch wersji.”
Odwołujący wskazuje, iż przy zakładanym czasie weryfikacji każdego z wymagań
w ramach Etapu II sprawdzenia próbki, niemożliwym jest zaprezentowanie dostępu do
Systemu na wszystkich wskazanych przeglądarkach we wszystkich wskazanych wersjach
w czasie 15 minut (aktualny średni czas prezentacji wymagania). Zamawiający nie wskazuje
jakie funkcje będą weryfikowane, co może doprowadzić do nieuzasadnionego wydłużenia
czasu prezentacji wymagania i tym samym nie
wystarczający czas na prezentację
pozost
ałych wymagań. Dodatkowo z punktu widzenia dostępnego czasu praktycznie
niemożliwe jest pokazanie dostępu do Systemu dla 2 wersji wstecz każdej z przeglądarek,
gdyż to wymaga od wykonawcy przygotowania środowiska / środowisk z łącznie 9 wersjami
(aktualna
i dwiema wstecz dla każdej z typów przeglądarek).
Żądanie: Nakazanie modyfikacji wymagania A01 w kontekście prezentacji próbki na
nast
ępujące: „A01 - W czasie prezentacji próbki wykonawca będzie zobligowany do
pokazania działania Systemu w aktualnej stabilnej wersji jednej wybranej przez Wykonawcę
przeglądarki MS Edge, Firefox lub Chrome. Docelowo Dostęp do Systemu musi być możliwy
we wszystkich wymieniony
ch przeglądarkach internetowych: MS Edge, Firefox, Chrome ze
wsparciem wstecznym dla dwóch wersji.”
W odniesieniu do przedmiotowego zarzutu
zamawiający wskazał, co następuje.
Odwołujący twierdzi, że przy zakładanym przez zamawiającego czasie weryfikacji
k
ażdego z wymagań w ramach Etapu II, nie jest możliwe zaprezentowanie dostępu do
Systemu na wszystkich wskazanych przeglądarkach we wszystkich wskazanych wersjach
(Zamawiający wymaga (A01) aby dostęp do Systemu był możliwy w przeglądarkach: MS
Edge, Firefox
oraz Chrome ze wsparciem wstecznym dwóch wersji). Tym samym odwołujący
żąda modyfikacji wymagania A01 w taki sposób, aby w czasie prezentacji wykonawca był
zobligowany do pokazania działania Systemu w wybranej przez wykonawcę przeglądarce.
Zamawiający wskazał, że zgadza się z argumentacją przedstawioną przez odwołującego
w uzasadnieniu zarzutu, jednakże nie zgadza się z żądaniem. Zamawiający zamierza
przeprowadzić weryfikację w takich samych warunkach dla wszystkich wykonawców.
Uwzględniając argumentację odwołującego, zamawiający zmienił wymaganie A01 w taki
sposób, aby prezentacja odbyła się na konkretnej przeglądarce – Edge. Tym samym zarzut
dotyczący braku czasu na prezentację działania Systemu na wszystkich przeglądarkach
przestaje być aktualny. Zmiana SWZ: „Załącznik nr 1 do Formularza ofertowego: A01 Dostęp
do Systemu musi być możliwy we wszystkich wymienionych przeglądarkach internetowych:
MS Edge, Firefox, Chrome ze wsparciem wstecznym dwóch wersji. W czasie prezentacji
Próbki wykonawca będzie zobligowany do zaprezentowania dostępu do Systemu
w przeglądarce internetowej MS Edge zgodnie z wymaganiem.”.
Mając na uwadze powyższe, w tym zmianę SWZ, zamawiający wniósł o oddalenie
zarzutu.
Zdaniem
Krajowej Izby Odwoławczej zarzut jest bezzasadny. Podnieść należy,
że zamawiający zmienił wymaganie uwzględniając swoją i częściowo odwołującego intencję.
Z opisu wymagania nie wynika, że zamawiający będzie badał wymaganie na trzech wersjach
przeglądarki. Wymaganie mówi jedynie o wsparciu wstecznym dwóch wersji (tej samej
przeglądarki), co oznacza, że zamawiający wymaga wsparcia aktualnej przeglądarki lub
dwóch jej wersji wstecz.
Punkt J
– Zamawiający w ramach weryfikacji próbki – Wymaganie z Grupy B wskazuje:
„D07 - Zdefiniowane formularze muszą być w pełni responsywne, tj. prawidłowo się
wyświetlać i funkcjonować na urządzeniach mobilnych.”
Odwołujący wskazuje, iż w trakcie prezentacji próbki nie jest możliwe właściwe
zaprezentowanie przedmiotowej funkcjonalności, gdyż w żaden sposób nie zostało
określone jakie dokładnie widoki w systemie mają być zaprezentowane, ani nie wskazano na
jakim dokładnie urządzeniu ma odbyć się prezentacja. Z racji na ograniczony czas
prezentacji każdej z funkcjonalności, zamawiający nie powinien wymagać prezentacji
wymagania na d
użej liczbie urządzeń, a jedynie na jednym wybranym lub wyłącznie
z wykorzystaniem emulatora takiego urządzenia.
Żądanie: Nakazanie modyfikacji wymagania D07 w kontekście prezentacji próbki na
następujące: „D07 - Zdefiniowane formularze muszą być w pełni responsywne, tj. prawidłowo
się wyświetlać i funkcjonować na urządzeniach mobilnych. W zakresie prezentacji próbki
wykonawca powinien z
aprezentować na jednym wybranym urządzeniu lub na emulatorze
takiego urządzenia jeden wybrany formularz, który powinien być prezentowany bez dolnego
paska przewijania
”.
W odniesieniu do przedmiotowego zarzutu
zamawiający wskazał, co następuje.
Zdaniem o
dwołującego, w trakcie prezentacji próbki nie jest możliwe właściwe
zaprezentowanie przedmiotowej funkcjonalności, ponieważ (i) nie zostało określone jakie
dokładnie widoki w systemie mają być zaprezentowane, (ii) nie wskazano na jakim
urządzeniu ma się odbyć prezentacja. Odwołujący wnosi o modyfikację wymagania w taki
sposób, aby podczas prezentacji próbki wykonawca zaprezentował wymaganie na jednym
wybranym urządzeniu lub emulatorze, jeden wybrany formularz, który powinien być
prezentowany bez dolnego paska.
Zamawiający oświadczył, że częściowo zgadza się z argumentacją odwołującego
i wskaz
ał, że weryfikacja wymagania podczas prezentacji Próbki odbędzie się za pomocą
narzędzi dostępnych w przeglądarce MS Edge (dostęp do narzędzi poprzez przycisk „F12” –
emulator urządzenia mobilnego). Natomiast zamawiający nie zgodził się na zaproponowane
zawężenie definicji responsywności do prezentacji formularza bez paska. Responsywność
została zdefiniowana w wymaganiu jako prawidłowe wyświetlanie i funkcjonowanie. Dla
każdego profesjonalisty definicja responsywności jest zrozumiała. Mając na uwadze
powyższe, zamawiający dokonał zmiany SWZ: „D07. Zdefiniowane formularze muszą być
w pełni responsywne, tj. prawidłowo się wyświetlać i funkcjonować na urządzeniach
mobilnych.
Weryfikacja wymagania podczas prezentacji Próbki odbędzie się za pomocą
narzędzi dostępnych w przeglądarce MS Edge (dostęp do narzędzi poprzez przycisk „F12” –
emulator urządzenia mobilnego).”
Mając na uwadze powyższe, w tym zmianę SWZ, zamawiający wniósł o oddalenie
zarzutu.
Zdaniem
Krajowej Izby Odwoławczej zarzut jest bezzasadny. Za zamawiającym wskazać
należy, że Próbka powinna posiadać funkcjonalności docelowego systemu w standardzie –
co oznacza, że jeżeli w ramach próbki nie będzie możliwe zaprezentowanie dowolnego
formularza w wersji responsywnej, to będzie oznaczało, że docelowy system nie będzie miał
takiej funkc
jonalności. Dlatego też stwierdzić należało, że wymaganie zamawiającego jest
zasadne.
Punkt M
– W zakresie wymagań nr A03, A04, A06, A10, J04, E03, F01, F03, I01, I03
niedopuszczalnym jest, zdaniem
odwołującego, aby stosować zakres, który nie jest w żaden
sposób zamknięty, a w tym kontekście zamawiający stosuje „itp.” – „i tym podobne”.
Stosowanie w ramach konkretnego wymagania tak
niedoprecyzowanego zakresu będzie
powodować w trakcie oceny próbki niejasności i wprowadzi dodatkowe ryzyko mogące
doprowadzić do przedłużenia czasu oceny ofert ze względu na wejście wykonawców w spór
z z
amawiającym. Zamawiający mający jedyną pieczę nad wymaganiami powinien dochować
należytej staranności, aby każde z nich zostało opisane w sposób precyzyjny i nie dający
pola do interpretacji. Dodatkowo, wszystkie nieprecyzyjne wymaga
nia z zakresu próbki
powinny
zostać
opisane
zgodnie
ze
standardem
SMART
(https://pl.wikipedia.org/wiki/S.M.A.R.T._(zarz%C4%85dzanie)).
Żądanie: Nakazanie modyfikacji wymagań nr A03, A04, A06, A10, J04, E03, F01, F03,
I01, I03 poprzez:
• usunięcie wszystkich otwartych wymagań albo zastąpienia ich zamkniętą enumeratywną
lis
tą,
• ujednoznacznienie zapisów w rodzaju "powinien",
• usunięcie wylistowań "co najmniej", itp.,
• usunięcie zdefiniowania pojęć, które nie są standardem branżowym (np. graficzna
pomoc.
W odniesieniu do przedmiotowego zarzutu
zamawiający wskazał, co następuje.
Zarzut, zdaniem z
amawiającego, jest całkowicie bezpodstawny. Każde z wymagań ma
jednoznacznie określony zakres. Zamawiający wyjaśnił, że:
•
wymagania wraz z przykładami w nawiasach: „(np.)” mają na celu ułatwienie
interpretacji wymagań a nie stworzenie otwartego katalogu. Wszystkie wymagania są
konkretnie opisane w dokumentacji p
ostępowania. Gdy zamawiający wskazuje przykładowe
pole, nie ozn
acza to, że daje wykonawcy dowolność, lecz pokazuje przykład pól a ich
zamknięty katalog znajduje się w dalszych wymaganiach;
•
określenie „powinien” w dokumentacji przetargowej standardowo oznacza „musi” i tak
też zamawiający interpretuje to słowo w przedmiotowym postępowaniu;
•
wylistowanie: „co najmniej” wskazuje na wymagania minimalne (co jest standardem
w specyfikacjach);
•
użyte pojęcia są standardowe i znane profesjonalistom realizującym analogiczne
zamówienia. Oprócz „graficznej pomocy”, odwołujący nie wskazał żadnego innego pojęcia,
którego nie rozumie. Natomiast odwołujący może skorzystać z instytucji zadawania pytań,
jeżeli jakieś pojęcia są dla niego niezrozumiałe.
Mając na uwadze powyższe, zamawiający wniósł o oddalenie zarzutu.
Zakres III (OPZ).
W zakresie wymagań OPZ zamawiający stosuje otwarte wymagania pisząc: „co
najmniej”,”itp.”, „itd.”, nie zamyka list wartości, stosuje stwierdzenia nie będące standardem
branżowym np. graficzna pomoc oraz stosuje wymagania określone jako „powinien” – co nie
jest równoznaczne z „musi”. Stosowanie w ramach konkretnego wymagania tak
niedoprecyzowanego zakresu będzie powodować w trakcie odbioru systemu niejasności
i wprowadzi do projektu dodatkowe ryzyko. Zamawiający mający jedyną pieczę nad
wymaganiami powinien dochować należytej staranności, aby każde z nich zostało opisane
w sposób precyzyjny i nie dający pola do interpretacji. Dodatkowo wszystkie nieprecyzyjne
wymagania z zakresu OPZ powinny zostać opisane zgodnie ze standardem SMART
(https://pl.wikipedia.org/wiki/S.M.A.R.T._(zarz%C4%85dzanie)).
Żądanie: Nakazanie modyfikacji wszystkich nieprecyzyjnie sformułowanych wymagań
zawierających wady opisane powyżej, poprzez:
• usunięcie wszystkich otwartych wymagań albo zastąpienia ich zamkniętą
enumeratywną listą,
• ujednoznacznienie zapisów w rodzaju "powinien",
• usunięcie katalogów otwartych/wylistowań "co najmniej", itp.
Odnosząc się łącznie do zarzutów (II.M. oraz III), Izba wskazuje, co następuje.
Zdaniem
Krajowej Izby Odwoławczej zarzuty są bezzasadne.
W
odwołaniu z dnia 25 listopada 2021 r., nie ma zarzutu co do wymagania A08, tym
samym podnoszenie zarzutu w
piśmie z dnia 17 grudnia 2021 r., Izba uznała za spóźnione.
Jak podał zamawiający, istnieje istotna różnica pomiędzy metodyką badania wymagań
a funkcjonalnością wymagania. Jeżeli wykonawca uważał, że nie ma możliwości zbadania
konkretnego wymagania w ramach próbki, to powinien złożyć odwołanie na kwalifikacje tego
konkretnego wymagania, wskazując na przykład, że wymaganie nie powinno być w grupie A.
Skoro o
dwołujący w terminie na złożenie odwołania nie postawił takiego zarzutu, to
podnoszenie go w kolejnym piśmie procesowym należało uznać za spóźnione. Odnosząc się
do przykładowego katalogu wskazanego w wymaganiu A06 wskazać należy, że usunięcie
przykładów niczego nie zmieni. Bez podanych przykładów wymaganie będzie brzmiało:
W portalu pracownika muszą być widoczne komunikaty skierowane przez Administratorów
do wybranych grup Użytkowników. Zamawiający dodał przykład „np. o przerwie technicznej
itp.” aby ułatwić wykonawcom interpretację wymagania. Zarówno z przykładem jak i bez
przykładu wymaganie ma takie samo znaczenie – w portalu pracownika muszą być widoczne
komunikaty
– zamawiający oczekuje, że widoczne będą dowolne komunikaty skierowane
przez Administratorów do wybranych grup Użytkowników.
Biorąc pod uwagę powyższe, orzeczono jak w sentencji.
O kosztach postępowania orzeczono stosownie do wyniku.
Przewodniczący:
…………………………
Członkowie:
…………………………
…………………………
Otrzymuj raz w tygodniu aktualne informacje
o zmianach w prawie oraz komentarzach ekspertów
Otrzymasz darmowy e-book w prezencie!
„6 pytań o znowelizowane przepisy Pzp"