Wyrok KIO 3445/21 z 29 grudnia 2021

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 zastosowaniem 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 ustawy 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 proporcjonalnoś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 zamó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 zamawiają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 przejrzystoś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. 3531 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,
8. art. 483 § 1, art. 484 § 2, art. 3531 KC 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. 3531 w związku z art. 644 KC, poprzez przyznanie zamawiają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 uczciwej 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:

1. uwzględnienie odwołania,
2. dokonania modyfikacji Ogłoszenia i SWZ w zakresie wskazanym w odwołaniu szczegółowo w każdym zarzucie,
3. 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 zamawiają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 odwoł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 unieważ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 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 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 odwoł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 traktowanie 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 zamawiający wskazał, co następuje.

W odpowiedzi na żą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 ubezpieczeniowych spółek holdingowych i ubezpieczeniowych spółek holdingowych prowadzących działalność mieszaną”.

Zamawiają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 zamawiają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 odwoł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 postępowania.

Mając na uwadze powyższe, zamawiający wniósł o oddalenie zarzutu nr 2.

Krajowa Izba Odwoł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 warunku 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) zamawiane 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.

Nie istnieją funkcjonaliści systemu BPM typowe tylko dla określonego zbioru/klasy instytucji (jak finansowe), b) zdefiniowany Proces Główny obejmuje podprocesy występujące w instytucjach wielu branż, nie tylko branży finansowej. Proces ten obejmuje typowe dla wielu branż podprocesy 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 wskazuje, ż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 następnie go rozwijał, musi wykazać się doświadczeniem dla instytucji finansowej.

Zamawiają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ą jest 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 oferty (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:

1. [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 wykonawcy 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 poprzez fakt, iż warunki nie dotyczą zamówienia i nie wynikają z opisu przedmiotu zamówienia, ani z wymagań związanych z realizacją zamówienia,
2. [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 jednym z kryteriów oceny ofert) - w sposób utrudniający przygotowanie oferty, przeprowadzenie prezentacji 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 wykonawcy, 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 nieograniczoną swobodę wyboru najkorzystniejszej oferty oraz uniemożliwia weryfikację i porównanie poziomu oferowanego wykonania przedmiotu zamówienia na podstawie informacji przedstawianych w ofertach,

1. [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 odwołujący wniósł o zwrot kosztów postępowania, w tym zwrot kosztów wynagrodzenia 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 naruszają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 odwołujący może ponieść szkodę polegającą na braku uzyskania przedmiotowego zamówienia. Ponadto odwołujący wskazał, że ma interes we wniesieniu odwołania, gdyż w wyniku uregulowania 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 odwoł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 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 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 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).

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 postę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 udział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 realizacji 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 zamawiają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 postę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 odwoł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 Izby Odwoławczej zarzut jest bezzasadny. Izba w całości podziela argumentację 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. Zwró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.

1. 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. konfigurację ś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.

Odwoł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.

Wykonawca, 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.

Rozwó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 alternatywy 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

infrastruktury 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 zamawiają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. konfigurację ś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, odwoł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 podwarunku 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 brzmieć „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 wykonawcy, 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 odwołujący opisuje istniejące na rynku rozwiązania, którymi zamawiają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 (proporcjonalnego 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 wdroż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 następnie w jego rozwoju. Zamawiający nie ma obowiązku dopuszczenia do zamówienia wszystkich działających na rynku podmiotów, lecz powinien postawić warunki udziału w postę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 sposó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, natomiast 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 realizować 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 ograniczenia 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 integrowanych systemów do 5 (pkt. 1.1.1.1.1.3).

Odwołujący wskazał, iż wymaganie zamawiającego, aby system integrował się dla co najmniej 10 innych systemów klienta jest nadmiarowe i ograniczając zakres dopuszczalnych referencji. Zdaniem odwoł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 zewnę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.

Odwołujący twierdzi, że wymaganie zamawiającego, aby system integrował się z co najmniej 10 innymi systemami klienta jest nadmiarowe i ograniczające zakres dopuszczalnych referencji. Odwołujący postawił dwa żądania w ramach podniesionego zarzutu:

1. Dotyczące liczby integrowanych systemów (zmniejszenia z 10 do 5)
2. Dopuszczenia 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 wymaganie 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 postę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).

Odwołujący wskazał, iż wymaganie, aby system obsługiwał 1000 użytkowników przy zapewnieniu jednoczesnego 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 wykonywanych 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 rozliczeń 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).

Zamawiają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 wymaganej ilości wniosków jakie obsłużył system (pkt.

1. 1.1.2.5).

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 wysokoś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 zamawiany. Z tą różnicą - iż klient takiego Banku podlega licznym ograniczeniom, 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 wnioskowi 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 zamawiają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 zmiany 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 postę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 odwołujący ponawia argumentacje dotyczącą niekonkurencyjnego przeniesienia na warunek udziału w postępowaniu specyfiki właściwej dla zamawiającego - omówione wyżej w zakresie 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 dokumentu niż umowa: „1.1.1.2.6. system obsłużył w każdym roku co najmniej 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 zamawiają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ż zamawiają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 zamawiają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 realiów rynkowych, w których parametry takie, jak 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 zamawiającego (pkt. 1.1.1.3).

Odwoł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, do 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 specyfikacją - uwzględnienia wręcz rodzaju prowadzonej działalności i detalicznych list rodzaju 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 odbiorcy. 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 poszerzył definicję odbiorcy zamówienia dopuszczając wykazanie referencji od ARiMR.

Zamawiają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 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ą.”.

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 3445/21.

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ł:

1. gotowość Sytemu, tj. dostępną w systemie wymaganą funkcjonalność oraz
2. 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 funkcjonalność (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 zamawiającego jest zakup Systemu opartego o Oprogramowanie Standardowe w zakresie zdefiniowanym szczegółowo w SWZ. Na potrzeby badania Próbki Systemu zamawiają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 procentowym z możliwych 40 punktów do zdobycia. Jednocześnie zamawiają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 badania 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 wykonawcę 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 opisany 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 wydają 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 przygotowywania 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 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, podczas gdy grupa B zawiera wymagania fakultatywne, 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 wszystkich, poprzez usunięcie z Etapu pierwszego badania wymagań z grupy A, oraz b. wskazania 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 rozwiania 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 na dzień złożenia oferty i których sposób wykonania musi zostać zaprezentowany podczas weryfikacji 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 zostać 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 przyznanie 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. Warunkiem 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 zaprezentowania 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 finansowych. 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 zamawiającego im bardziej ustandaryzowany jest produkt (im więcej funkcjonalności posiada w standardowej wersji, bez konieczności rozbudowy), tym lepiej.

Dlatego zamawiają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. weryfikacja, 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 zamawiają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 zamawiają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 wykonawca 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 zamawiają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 sprzętowo-systemowej lub komunikacyjnej stanowiącej środowisko uruchomieniowe prezentowanego Systemu. Podejście takie rodzi poważne ryzyko niewykazania 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, awaria sprzętowa, niespodziewany błąd działania systemu operacyjnego lub konieczność wprowadzenia zmian konfiguracyjnych w celu dostosowania systemu do importu otrzymanego od zamawiają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 prezentowanych funkcjonalności, tylko oferowany system informatyczny w celu oceny:

1. gotowości Sytemu, tj. dostępnej w systemie wymaganej funkcjonalność oraz
2. gotowości 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.

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 postfactum. W przypadku informowania wykonawców o wyniku oceny każdej ocenianej funkcjonalności oraz umożliwieniu powtórzenia prezentacji danego elementu w przypadku oceny negatywnej, zamawiają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 zamawiają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 wykonawcy 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 SWZ 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 SWZ 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 konfiguracyjnych, poprosić o zatrzymanie czasu prezentacji. Łączny czas trwania dokonywania takich zmian lub naprawy nie może przekroczyć jednej godziny.”
3. Modyfikacja SWZ poprzez dodanie zapisu 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.

Odwołujący w ramach zarzutu II. C. stawia trzy niezależne żądania.

Po pierwsze, odwoł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 prezentacji 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, zamawiają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 konfiguracyjnych, poprosić o zatrzymanie czasu prezentacji. Łączny czas trwania dokonywania takich zmian lub naprawy nie może przekroczyć jednej godziny.”.

Zamawiający podniósł, iż w ramach pierwszego i trzeciego żądania odwołujący chce wprowadzenia przez zamawiają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ą