Sygn. akt: KIO 69/21

WYROK

z dnia 12 lutego 2021 r.

Krajowa Izba Odwoławcza - w składzie:

Przewodniczący: Ewa Kisiel

Magdalena Grabarczyk

Monika Kawa-Ogorzałek

Protokolant:  Łukasz Listkiewicz

po rozpoznaniu na rozprawie w dniu 8 lutego 2021 r. w Warszawie odwołania wniesionego do Prezesa Krajowej Izby Odwoławczej w dniu 4 stycznia 2021 r. przez wykonawcę Comarch Polska S.A. z siedzibą w Krakowie w postępowaniu prowadzonym przez zamawiającego Bank Gospodarstwa Krajowego z siedzibą w Warszawie,

przy udziale wykonawcy Sygnity S.A. z siedzibą w Warszawie, zgłaszającego przystąpienie do postępowania odwoławczego po stronie odwołującego

orzeka:

1.Umarza postępowanie odwoławcze w części dotyczącej zarzutów odnoszących się do naruszenia art. 7 ust. 1, art. 29 ust. 1 i 2 oraz art. 36 ust. 1 pkt 3 Pzp wskazanych w odwołaniu w następujących punktach: 1, 8.2, 8.3, 8.4, 8.8, 8.12, 8.17, 8.19, 8.20.

2.Uwzględnia odwołanie wykonawcy Comarch Polska S.A. z siedzibą w Krakowie i nakazuje zamawiającemu Bankowi Gospodarstwa Krajowego z siedzibą w Warszawie modyfikację specyfikacji istotnych warunków zamówienia w części Załącznika nr 1 „Opis Przedmiotu zamówienia” (OPZ) w odniesieniu do:

zarzutu nr 2 dotyczącego określenia przedmiotu zamówienia w zakresie integracji z Hurtownią danych w rozdziale 5.4 „Przypadki Użycia – wybranych wymagań biznesowych (PU)” w pkt 8 „WB.008 – Zasilanie Hurtowni Danych (HD)” przez dokonanie modyfikacji OPZ w ten sposób, że zamawiający określi, jakie dane będą miały być udostępnione do Hurtowni danych;

zarzutu nr 4 dotyczącego określenia wymagań w zakresie integracji z systemem centralnym zamawiającego w rozdziale 6 „Wymagania w zakresie integracji (WI)” w tabeli pod nr WI.001 „Integracja z centralnym systemem zamawiającego” przez dokonane modyfikacji OPZ, polegającej na podaniu niezbędnych informacji w zakresie usług służących do integracji z systemem centralnym, które są lub będą dostępne na szynie integracyjnej;

zarzutu nr 5 dotyczącego integracji z systemem bankowości elektronicznej BGK w rozdziale 6 „Wymagania w zakresie integracji (WI)” w tabeli pod nr WI.002 „Integracja z systemem bankowości elektronicznej BGK” przez wyspecyfikowanie, jakie usługi służące do integracji są lub będą udostępnione przez system bankowości elektronicznej;

zarzutu nr 7 dotyczącego doprecyzowania pojęcia „systemy Zamawiającego” przez wymienienie wszystkich systemów Zamawiającego, z którymi ma się integrować budowany system H2H,

zarzutu nr 8.5 dotyczącego wsparcia w rozwiązywaniu problemów przez modyfikację OPZ w rozdziale 21 w pkt 5 polegającą na sprecyzowaniu przez zamawiającego określonego limitu godzin wsparcia, którego ma udzielać wykonawca w rozwiązywaniu problemów w ramach zaoferowanej ceny ryczałtowej,

zarzutu nr 8.11 dotyczącego wymagań PU.006, PU.034, PU.035, PU.036, PU.045. (str. 16 i 18 OPZ) przez określenie zasad integracji z systemem bankowości elektronicznej;

zarzutu nr 8.22 dotyczącego wymagań wskazanych w rozdziale 25 „Asysta Techniczna” pkt 2 lit. a) OPZ przez zdefiniowanie pojęcia „Pomoc”, które ma polegać na wyspecyfikowaniu określonych czynności mających składać się na świadczenie przez wykonawcę owej „pomocy”, z tym zastrzeżeniem, że czynności te mają być związane z przedmiotem zamówienia, a ponadto w tym zakresie zamawiający powinien sprecyzować limit godzin, który będzie wchodził w skład ryczałtu zaoferowanego przez wykonawcę w cenie ofertowej;

3.W pozostałym zakresie oddala odwołanie.

4.Kosztami postępowania obciąża wykonawcę Comarch Polska S.A. z siedzibą w Krakowie w części 27/34 i zamawiającego Bank Gospodarstwa Krajowego z siedzibą w Warszawie w części 7/34 i:

4.1zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr (słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez wykonawcę Comarch Polska S.A. z siedzibą w Krakowie tytułem wpisu od odwołania,

4.2zasądza od zamawiającego Banku Gospodarstwa Krajowego z siedzibą w Warszawie na rzecz wykonawcy Comarch Polska S.A. z siedzibą w Krakowie kwotę 3 830 zł (słownie: trzy tysiące osiemset trzydzieści złotych).

Stosownie do art. 579 i 580 ustawy z dnia 11 września 2019 r. - Prawo zamówień publicznych (Dz. U. z 2019 r. poz. 2019 ze zm.) na niniejszy wyrok - w terminie 14 dni od
‎dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu Okręgowego w Warszawie.

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

  ………………..………….

………………..………….

Sygn. akt KIO 69/21

Uzasadnienie

Bank Gospodarstwa Krajowego z siedzibą w Warszawie (dalej: „Zamawiający” lub „BGK”) prowadzi, na podstawie przepisów ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz.U. z 2019 r., poz. 1843 j.t.), zwanej dalej: „ustawą” lub „Pzp”, postępowanie o udzielenie zamówienia publicznego w trybie przetargu nieograniczonego pn. „Dostawa, wdrożenie, serwis i integracja Systemu Host2Host dla klientów Banku Gospodarstwa Krajowego”.

Wartość zamówienia przekracza kwoty określone w przepisach wykonawczych wydanych na podstawie art. 11 ust. 8 Pzp.

Ogłoszenie o zamówieniu zostało opublikowane w Dzienniku Urzędowym Unii Europejskiej w dniu 23 grudnia 2020 r. pod numerem nr 2020/S 250-623767. W tej samej dacie została opublikowana Specyfikacja istotnych warunków zamówienia (dalej: „SIWZ”, „specyfikacja”).

W dniu 4 stycznia 2021 r. wykonawca Comarch Polska S.A. z siedzibą w Krakowie (dalej: „Odwołujący” lub „Comarch”) wniósł na podstawie art. 514 ustawy z dnia 11 września 2019 r. Prawo zamówień publicznych (Dz.U. z 2019 r., poz. 2019 ze zm.) - zwane dalej: „Nustawą" lub „NPzp") wobec czynności Zamawiającego, podjętej w postępowaniu o udzielenie zamówienia publicznego, polegającej na sporządzeniu specyfikacji w sposób niezgodny z przepisami ustawy.

Odwołujący zarzucał Zamawiającemu:

1.opisanie przedmiotu zamówienia w sposób niejednoznaczny, niewyczerpujący, nieuwzględniający wszystkich wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty, niespójny z formularzem ofertowym i utrudniający uczciwą konkurencję - czym naruszył art. 7 ust. 1, art. 29 ust. 1 i 2 oraz art. 36 ust. 1 pkt 3 Pzp;

2.sformułowanie postanowień SIWZ w zakresie Załącznika do SIWZ - Wzór Umowy, w sposób utrudniający uczciwą konkurencję i niezapewniający równego traktowania wykonawców, niejednoznaczny i obarczony wadą w postaci niezgodności postanowień umownych z przepisami prawa i zasadami współżycia społecznego - czym naruszył art. 7 ust. 1, art. 29 ust. 1 i 2, art. 36 ust. 1 pkt 3 i 16 Pzp w zw. z art. 5, art. 58 § 1 i 2 oraz art. 353¹ Kodeksu cywilnego w zw. z art. 139 Pzp, a także inne normy i zasady wskazane w uzasadnieniu odwołania.

W związku z powyższym Odwołujący wnosił o uwzględnienie odwołania i nakazanie Zamawiającemu modyfikacji treści SIWZ w sposób wskazany szczegółowo w uzasadnieniu złożonego odwołania.

W uzasadnieniu zarzutów odwołania wykonawca Comarch podnosił, że:

1.Zarzut nr 1 - Nieprecyzyjne określenie przedmiotu zamówienia w zakresie Infrastruktury IT.

Odwołujący stwierdził, że nie ma możliwości złożenia oferty, ponieważ aby móc wycenić czynności serwisowe, którym miałaby podlegać Infrastruktura IT Zamawiającego (w szczególności takie czynności jak aktualizacja firmware) wykonawca powinien posiadać wiedzę o tym, jakie konkretnie elementy tej infrastruktury będzie musiał obsługiwać. Przykładowo w celu określenia czy w ogóle jest możliwe objęcie danego elementu infrastruktury aktualizacją firmware należy znać typ i nazwę urządzenia, datę jego produkcji i numer seryjny urządzenia. Zamawiający nie przedstawił takich informacji w OPZ, co czyni niemożliwym skalkulowanie oferty.

Żądanie: Dokonanie przez Zamawiającego zmian w OPZ w taki sposób, aby pojęcie Infrastruktura IT Zamawiającego zostało zdefiniowane wyczerpująco poprzez wymienienie enumeratywnie wszystkich elementów tej infrastruktury z podaniem producenta, nazwy i typu urządzenia, daty produkcji i numeru seryjnego.

2.Zarzut nr 2 - Nieprecyzyjne określenie przedmiotu zamówienia w zakresie integracji z Hurtownią danych.

Zamawiający zawarł w OPZ wymaganie WB.008 o treści:

„WB.008 Zasilanie Hurtowni Danych

Rozwiązanie umożliwi przekazywanie danych do hurtowni danych w postaci ekstraktów lub udostępniania widoków danych w sposób niezakłócający działania Systemu H2H."

Wymaganie to zostało przez Zamawiającego doszczegółowione na stronie 24 OPZ w postaci tabeli:

8.WB.008 - Zasilenie Hurtowni Danych (HD)

PU.001 - Zasilenie HD - Rozwiązanie umożliwi przekazywanie danych do HD w postaci ekstraktów lub udostępniania widoków danych w sposób niezakłócający działania Systemu H2H.

PU.002 - Rodzaje ekstraktów zasilenia HD- Rozwiązanie musi zapewnić możliwość generowania ekstraktów pełnych oraz przyrostowych. 

PU.003 - Zasilenie HD dostępność danych - Dla opcji udostępniania widoków danych rozwiązanie musi zapewnić mechanizm dostępności danych w okresie 4 dni od ich wygenerowania.

PU.004 - Generowanie ekstraktów i informowanie o zakończeniu procesu przygotowywania danych do zasilenia HD:

1. W przypadku generowania ekstraktów mechanizm ma zapisywać dane do wskazanej lokalizacji sieciowej, wystawiając na koniec plik end. Nazewnictwo ekstraktów do ustalenia w tracie prac projektowych.

2. W przypadku udostępnienia danych za pomocą widoków (stage), kopiowanie danych powinno być zakończone wpisem do tabeli logów z informacją o dostępności danych na potrzeby HD”.

Odwołujący stwierdził, że Zamawiający nie określił jednak w żadnym miejscu OPZ, jakie dane mają być przekazywane do Hurtowni Danych. Jest to kluczowa informacja dla wykonawcy, który miałby wycenić przygotowanie zarówno samej hurtowni jak i tylko mechanizmu ekstrakcji i przekazywania danych do tej hurtowni. Od ilości rodzajów (wymiarów) danych, ich struktury (elementów składowych poszczególnych rekordów), czy sposobu ich agregacji zależy złożoność, a co za tym idzie pracochłonność wykonania mechanizmów zasilających hurtownię. Wobec obecnego nieprecyzyjnego kształtu zapisów OPZ nie sposób sporządzić wycenę, która uwzględniałaby wymagane przez OPZ prace związane z mechanizmami zasilania Hurtowni Danych.

Żądanie: Dokonanie modyfikacji OPZ w ten sposób, że zostanie określone, jakie dane, z jakich źródeł i w jakim układzie ich wzajemnej relacji będą miały być udostępniane do Hurtowni danych.

3.Zarzut nr 3 - Określenie raportów, które mają być generowane przez moduł raportowy w sposób otwarty, co uniemożliwia sporządzenie wyceny.

Zamawiający zawarł w OPZ następujące wymaganie:

„PU.001 - Moduł raportowy - Rozwiązanie musi zapewnić funkcjonalność generowania raportów (z możliwością zapamiętania i modyfikowania ich definicji) z aktywności w kanale H2H prezentujących, np.:

1. Listę klientów H2H i ich status, datę aktywacji, datę zablokowania, datę ważności Certyfikatu komunikacyjnego.

2. Listę klientów H2H i ich status oraz listę usług, które mają/mieli udostępnione,

3. Listę klientów i ich status, listę użytkowników i ich statusy oraz uprawnienia oraz termin ważności Certyfikatu autoryzacyjnego

4. Liczę i wartość Dyspozycji (ogółem i per klient) zleconych w danym okresie (i ich aktualny status),

5. Liczbę wywołań usług w zadanym okresie per klient i Użytkownik,

6. Listę dyspozycji złożonych przez wskazanego Klienta lub Użytkownika w zadanym okresie (rodzaj dyspozycji, aktualny status, wartość, rachunek obciążany, rachunek uznawany, termin realizacji, dane osób autoryzujących),

7. Listę adresów Ip dla wskazanego Klienta (ze wskazaniem dni i okresów udostępniania, użytkowników),

8. Listę połączeń dla wskazanego Klienta (Ip, data i godzina rozpoczęcia połączenia, data i godzina zakończenia połączenia, liczba i wartość złożonych dyspozycji w podziale na typy),

9. Listę Certyfikatów komunikacyjnych (daty ważności, daty aktywacji, data zablokowania, status),

10. Listę Certyfikatów autoryzacyjnych (daty ważności, daty aktywacji, data zablokowania, status, użytkownik, status, firma, status) w tym listę statusów do autoryzacji,

11. Listę zmian statusów firmy we wskazanym okresie (dane firmy, status pierwotny, status zmieniony, data i godzina zmiany, użytkownik zmieniający status, opis powodu zmiany statusu),

12. Listę zmian statusów użytkowników firmy we wskazanym okresie (dane użytkownika firmy, status pierwotny, status zmieniony, data i godzina zmiany, czas, który upłynął od uzyskania status do jego zmiany, użytkownik zmieniający status, opis powodu zmiany statusu),

13. Raport z listy błędów w obsłudze Dyspozycji w zadanym okresie (rodzaj dyspozycji, rodzaj usługi, kod i opis błędu, data i godzina zapytania, data i godzina odpowiedzi, połączenie do szczegółów zapytania I odpowiedzi, użytkownik, firma, Ip),

14. Liczbę przetworzonych wywołań usług w podziale na typy usług I klientów w przedziale czasowym,

15. Listę zrealizowanych wywołań usług z określonym zestawem filtrów umożliwiających zawężenie do poziomu pojedynczych pozycji,

16. Statystyki procesowanych wywołań usług w zadanej jednostce czasu,

17. Zestawienie liczby transakcji w podziale na wprowadzone do bgk24, systemu transakcyjnego oraz błędnych autoryzacji.

Szczegółowe wymagania zostaną ustalone na etapie Analizy przedwdrożeniowej rozwiązania”.

Zdaniem Odwołującego takie ujęcie wymagania zawarte OPZ jest nieostre. Wykonawca nie jest, bowiem w stanie ustalić z całkowitą pewnością, czy przedmiotem realizacji w ramach modułu raportowego będzie wyłącznie wymienione 17 raportów, czy też więcej. Zamawiający użył, bowiem określenia „np.”, co sugeruje, że wymienił jedynie część przykładowych raportów a nie wszystkie. Wykonawca nie jest, zatem w stanie określić czy predefiniowanych raportów do realizacji będzie siedemnaście czy może więcej. Dodatkowo Zamawiający nie opisał wystarczająco precyzyjnie, jakie „szczegółowe wymagania" zostaną ustalone na etapie Analizy przedwdrożeniowej. Nie wiadomo, zatem, czy to, co Zamawiający opisał w wymaganiu definiuje zawartość informacyjną poszczególnych raportów, czy też będzie wymagał dodatkowych wymiarów czy też filtrów. Nie wiadomo, czy „szczegółowe wymagania", o których pisze Zamawiający dotyczą treści czy też np. układu i wyglądu tych raportów. Tak sformułowany opis przedmiotu zamówienia jest nieprecyzyjny i nie pozwala na sporządzenie oferty, gdyż nie daje wykonawcom wystarczających informacji, co do tego ile pracy będzie związane z implementacją raportów w module raportowym.

Żądanie: Dokonanie zmiany opisu przedmiotu zamówienia w ten sposób, że z treści wymagania PU.001 zostanie usunięte określenie „np.:" oraz zdanie „Szczegółowe wymagania zostaną ustalone na etapie Analizy przedwdrożeniowej rozwiązania".

4.Zarzut nr 4 - Nieprecyzyjnie określone wymagania w zakresie integracji z systemem centralnym Zamawiającego.

Zamawiający w OPZ zawarł wymaganie WI.001 o następującej treści:

„ WI.001 Integracja z centralnym systemem BGK W celu zapewnienia spójności wymienianych danych oraz rozliczalności przepływu informacji, integracja Systemu H2H z systemem centralnym Zamawiającego musi odbywać się z wykorzystaniem szyny integracyjnej Zmawiającego. Szczegółowe zasady integracji zostaną ustalone na etapie Analizy przedwdrożeniowej rozwiązania".

Wykonawca Comarch stwierdził, że na podstawie tak określonego wymagania nie ma możliwości oceny jak pracochłonne może być wykonanie integracji systemu z systemem centralnym Zamawiającego. Pracochłonność ta jest między innymi pochodną tego, jakie usługi udostępnione będą na szynie integracyjnej Zamawiającego i jaka jest specyfikacja tych usług (na co pozwalają, jak są zaimplementowane oraz jak zdefiniowane są dla nich wymagania np. bezpieczeństwa związane z integracją). W szczególności wykonawca nie ma na podstawie OPZ żadnej podstawy, aby określić czy na szynie integracyjnej są w ogóle jakiekolwiek usługi, czy istnieje jakakolwiek dokumentacja tych usług ani jakiej jest ona jakości. Nie sposób, zatem przyjąć apriori nawet założeń, co do pracochłonności analizy, która miałaby ustalić mechanizm integracji, a co dopiero, co do implementacji mechanizmów integracji z systemem centralnym.

Żądanie: Dokonanie modyfikacji OPZ poprzez enumeratywne wyspecyfikowanie, jakie usługi służące do integracji z systemem centralnym są lub będą dostępne na szynie integracyjnej Zamawiającego oraz udostępnienie wykonawcom dokumentacji tych usług.

5.Zarzut nr 5 - Nieprecyzyjne określenie wymagań dotyczących integracji z systemem bankowości elektronicznej BGK.

Zamawiający zawarł w OPZ następujące wymaganie Wl.002 dotyczące integracji z systemem bankowości elektronicznej BGK:

„Wl.002 Integracja z systemem bankowości elektronicznej BGK Integracja Systemu H2H z systemem bankowości elektronicznej BGK musi odbywać się za pośrednictwem udostępnianych usług przez system bankowości elektronicznej BGK. Szczegółowe zasady integracji zostaną ustalone na etapie Analizy przedwdrożeniowej rozwiązania".

Wykonawca Comarch podnosił, że na podstawie tak określonego wymagania nie ma możliwości oceny jak pracochłonne może być wykonanie integracji systemu z bankowości elektronicznej Zamawiającego. Pracochłonność ta jest między innymi pochodną tego, jakie usługi udostępnione będą przez ten system i jaka jest specyfikacja tych usług (na co pozwalają, jak są zaimplementowane oraz jak zdefiniowane są dla nich wymagania np. bezpieczeństwa związane z integracją). W szczególności wykonawca nie ma na podstawie OPZ żadnej podstawy, aby określić czy usługi te są dostępne także na szynie integracyjnej, czy też wykorzystują inny (nie wiadomo, jaki mechanizm lub protokół). Nie wiadomo także, czy istnieje jakakolwiek dokumentacja tych usług ani jakiej jest ona jakości. Nie sposób, zatem przyjąć a priori nawet założeń, co do pracochłonności Analizy, która miałaby ustalić mechanizm integracji, a co dopiero, co do implementacji mechanizmów integracji z systemem bankowości elektronicznej.

Żądanie: Dokonanie modyfikacji OPZ poprzez enumeratywne wyspecyfikowanie, jakie usługi służące do integracji są lub będą udostępnione przez system bankowości elektronicznej, w jakiej technologii będą one dostępne i w oparciu, o jakie standardy/protokoły oraz udostępnienie wykonawcom dokumentacji tych usług.

6.Zarzut nr - Nieprecyzyjne określenie „poprawnego działania" w kontekście Okresu Stabilizacji i Okresu Weryfikacji Poprawności Działania.

Zamawiający w OPZ rozdział 19 określił, że:

„5. Okres Weryfikacji Poprawności Działania kończy się, jeżeli produkcyjny System H2H działa poprawne przez okres minimum jednego miesiąca liczony od ostatniego wdrożenia na środowisku produkcyjnym nowej wersji..."

Zdaniem Odwołującego użycie nieprecyzyjnego pojęcia „działa poprawnie" uniemożliwia oszacowania kosztów okresu Stabilizacji. Takie skonstruowany zapis może prowadzić do sytuacji, w której System H2H nie spełni bliżej nieokreślonego wymagania tj.: „działa poprawnie" przez bardzo długi okres a co za tym idzie wpłynie to na okres świadczenia usługi przez wykonawcę.

Żądanie: Dokonanie modyfikacji OPZ poprzez doprecyzowanie pojęcia „działa poprawnie" w sposób określający ilość błędów według ich kategorii, które mogą pojawić się w okresie jednego miesiąca od rozpoczęcia wdrożenia na środowisku produkcyjnym.

7.Zarzut nr 7 - Nieprecyzyjne określenie „Systemy Zamawiającego".

Wykonawca Comarch podniósł, że Zamawiający w OPZ posługuje się określeniem „Systemy Zamawiającego”, z którym ma być zintegrowany System H2H, przykładowo: „Wykonawca musi zapewnić wymaganą wydajność i pojemność Systemu H2H niezależnie od wydajności systemów, z którymi współpracuje (czas obsługi przez systemy zewnętrzne nie wlicza się do czasu realizacji przez System H2H), w tym możliwości obsługi różnych czasów obsługi poszczególnych usług przez systemy Zamawiającego".

lub

„Wymaganie PU.064

PU.064 - Zlecenie dyspozycji wygenerowania raportu przez systemy Zamawiającego - Dyspozycja informacyjna obsługiwana przez Usługę WS”.

Jednocześnie nigdzie w dokumentacji przetargowej nie wymienia enumeratywnie systemów Zamawiającego ani nie udostępnia stosownej dokumentacji.

Żądanie: Dokonanie modyfikacji OPZ poprzez doprecyzowanie pojęcia „Systemy Zamawiającego" w szczególności Odwołujący żądał enumeratywnego wymienienia systemów Zamawiającego, z którymi ma się integrować budowany System H2H oraz udostępnienia stosownej dokumentacji systemów w zakresie umożliwiającym realizację określonych w OPZ wymagań.

8.Pozostałe zarzuty odwołania zawarte w zarzucie nr 8 - nieprecyzyjne zapisy przedmiotu zamówienia, zapisy błędne (sprzeczne wzajemnie) oraz zapisy nie zawierające informacji umożliwiających wycenę oferty.

8.1 Zapis SIWZ: 

Zamawiający w OPZ ustalił, że:

„Czas Naprawy – Czasokres w godzinach lub dniach liczony od czasu dokonania Zgłoszenia przez Zamawiającego do czasu usunięcia Wady lub dostarczenia Obejścia eliminującego negatywne skutki Wady potwierdzonego podpisaniem protokołu odbioru naprawy oraz uaktualnienia lub skorygowania danych w Systemie H2H.

Czas Naprawy liczony jest nieprzerwanie od momentu dokonania Zgłoszenia, z zastrzeżeniem, że w przypadku Zgłoszenia Błędu lub Usterki w dniu ustawowo wolnym od pracy czas ten liczony jest od godziny 07:00 w następnym Dniu Roboczym.

W przypadku Awarii na środowiskach testowych Czas Naprawy jest odliczany od czasu na wykonanie Testów Odbiorczych”.

Żądanie: Zmiana zapisu - czasokres powinien być liczony od momentu przyjęcia zgłoszenia z kompletem danych, a nie dokonania zgłoszenia.

Zmiana zapisu - liczenie czasu naprawy powinno dotyczyć tylko sytuacji, w których zgłoszenie jest po stronie dostawcy, a nie nieprzerwanie wliczając w to czas po stronie banku.

Uzasadnienie zarzutu: Odwołujący wskazywał, że w przypadku, w którym do realizacji zgłoszenia potrzebne są dodatkowe informacje, dane, logi itd. - leżące po stronie Zamawiającego, powinno to wstrzymywać bieg czasu liczonego wykonawcy do realizacji naprawy. W przeciwnym przypadku wykonawca niesłusznie może ponosić odpowiedzialność za naruszenie terminu naprawy, pomimo że nie miał na to wpływu.

8.2. Definicja Dokumentacji.

Odwołujący wyjaśniał, że w ramach niniejszego zamówienia można albo przenosić autorskie prawa majątkowe na Zamawiającego, z czym wiąże się obowiązek przekazania kodów, albo udzielić Zamawiającemu licencji na oprogramowanie - co nie pociąga za sobą obowiązku przekazania kodów. Jest to decyzja do wyboru wykonawcy podejmowana na etapie składania oferty, skutkująca - zgodnie z pkt XII SIWZ - Kryteria oceny ofert ppkt 12.2. pppkt 2): „Kryterium „P" - dodatkowy parametr oferty tj. przeniesienie na Zamawiającego praw autorskich do dostarczonego oprogramowania" - przyznaniem odpowiednio mniejszej liczby punktów w przypadku nieprzekazywania praw autorskich. Tymczasem zaskarżony zapis SIWZ/OPZ w zakresie definicji Dokumentacji nie rozróżnia powyższej sytuacji, obligatoryjnie wymagając w pkt 5 przekazania kodów, co nie musi mieć miejsca.

8.3. Zapis SIWZ dot. Weryfikacji i Certyfikacji.

Odwołujący stwierdził, że krótki opis modyfikacji kodu źródłowego nie będzie wystarczający dla wykonawcy dla uzgodnienia pracochłonności danej Weryfikacji. Zamawiający powinien być zobowiązany do dostarczenia wykonawcy wszelkich informacji umożliwiających wykonanie oszacowania pracochłonności każdej Weryfikacji.

8.4. Zapis SIWZ - dot. Usług Rozwoju Systemu H2H - pkt. 22 ppkt 4 lit. g. OPZ.

Zdaniem Comarch wykonawca nie powinien być zobowiązywany do realizacji zleceń Rozwoju o pracochłonności przekraczającej dostępny limit roboczodni. W umowie i OPZ brak potwierdzenia takiej zasady. OPZ nie określa scenariusza, co w przypadku, gdy dojdzie do takiej sytuacji, w szczególności OPZ nie rozstrzyga, co do brak zobowiązania wykonawcy.

8.5. Zapis OPZ - dot. wsparcia w rozwiązywaniu problemów (pkt 21 OPZ Usługi serwisowe).

Zamawiający ustalił, że:

„5. Wykonawca ma obowiązek udzielać wsparcia w rozwiązaniu poniższych problemów:

a. Usuwania wirusa komputerowego, ataków na System H2H, jak również szkód spowodowanych ich działaniem,

b. Dostarczenia skryptów do modyfikacji danych w bazie danych wynikających z decyzji Zamawiającego np. korekta danych,

c. Napraw uszkodzeń również w sytuacjach udowodnionej eksploatacji Oprogramowania niezgodnie z jego Dokumentacją,

d. Usterek bądź nieprawidłowego działania sprzętu komputerowego lub oprogramowania współdziałającego z Oprogramowaniem lub Infrastrukturą, niedostarczonego przez Wykonawcę,

e. Działania czynników zewnętrznych, jak zwarcia instalacji elektrycznej”.

Żądanie: Albo usunięcie punktu 21 ppkt 5 a) - e) OPZ, jako usług Serwisowych objętych ryczałtem albo ich pozostawienie, jednak nie, jako usług ryczałtowych, lecz rozliczanych zgodnie z poniesionymi nakładami pracy przez wykonawcę, co oznacza konieczność: wprowadzenia do OPZ i wzoru umowy mechanizmu precyzującego zamówienie poszczególnych usług z pkt 5 (na kształt zlecenia usług Rozwoju) wraz z wprowadzeniem do umowy odrębnych zasad płatności za ten zakres usług wg. stawki za 1 osobodzień określonej w ofercie, będącej podstawą płatności i rozliczenia danej usługi.

Uzasadnienie zarzutu: Zaskarżony zapis OPZ obejmuje różne zobowiązania o niejednolitym charakterze. Nie mają one wspólnego mianownika poza tym, iż kształtują one swego rodzaju „pomocowe" zobowiązania wykonawcy. Odwołujący zarzucał, iż zobowiązania te nie są możliwe do wyceny na etapie oferty, z uwagi na ogólnikowość ich sformułowania oraz nieznany zakres pracochłonności. Ponadto wykonawca nie ma wpływu na wymienione w tym zapisie elementy, nie jest w stanie przede wszystkim nawet ustalić skali swego ewentualnego zaangażowania. Przykładowo wykonawca nie można przewidzieć obecnie rozmiaru ataków a, przede wszystkim rozmiaru i skali szkód. To mogą być milionowe szkody. Zapis SIWZ skutkować może nawet interpretacja, iż Wykonawca jest zobowiązany jest pokryć - gdyż jest to jedna z form „usunięcia szkód". Z drugiej strony - jeżeli zobowiązanie wykonawcy ma polegać „udzieleniu wsparcia" - jego zakres w ogóle nie jest określone. Nie jest wiadome, co wykonawca ma w ramach wsparcia odnośnie szkód zrealizować. Podobnie odnośnie zobowiązani z wszystkich pozostałych liter a) - ej - nie jest znany na ten moment, gdyż nie może być, zakres zobowiązani wykonawcy. To oznacza, że nie mogą być te zobowiązani objęte ryczałtem, gdyż zakres pracochłonności jest obecnie nieznany.

8.6. Zapis OPZ - dot. środowisk testowych i wymagań SLA.

Żądanie: Usunięcie wymagań dotyczących SLA w zakresie środowisk testowych.

Odwołujący stwierdził, że wymaganie dotyczące usuwania Wad na środowisku testowym w reżimie SLA (czasy reakcji i naprawy) nie powinno mieć miejsca, gdyż nie jest ono istota zobowiązania, a jedynie narzędziem umożliwiającym wykonanie zobowiązań umownych. Powyższy zapis wprowadza dodatkowe ryzyka dla wykonawcy, których skali nie jest w stanie oszacowań - przy wielości środowisk testowych - w cenie oferty.

8.7. Zapis OPZ - zarzut dot. wymagań biznesowych pkt 5.3.3. OPZ.

Zamawiający sprecyzował, że:

„5.3. Wysoko poziomowe wymagania biznesowe (WB)

1. Komunikacja pomiędzy Systemem H2H, a Systemem FK/ERP Klienta realizowana będzie w oparciu o następujące standardy:

a. Standard wymiany danych zgodny z Certyfikatem IS020022,

b. Rekomendację Związku Banków Polskich w sprawie przyjęcia standardu wymiany danych finansowych pomiędzy klientem, a bankiem v.3.0 z marca 2018 roku (z uwzględnieniem aktualizacji),

c. Formaty danych ELIXIR, EUROEUX1R, SĘPA,

d. Simple Object Access Protocol (SOAP) lub Representational state transfer (REST),

e. Web Services Description Language (WSDL).

2. W przypadku, jeżeli powyższe rekomendacje nie określają specyfikacji dla wybranych Dyspozycji (komunikatów biznesowych) Ich struktura zostanie określona przez Zamawiającego na etapie Analizy przedwdrożeniowej rozwiązania.

3. Rozwiązanie musi spełniać wymagania rekomendacji KNF oraz europejskich organów nadzoru oraz powszechnie obowiązującego w Polsce prawa, w szczególności Dyrektywy unijnej PSD2 oraz aktów do niej wykonawczych (tzw. RTS).

Żądanie: Wykonawca żądał enumeratywnego wymienienia w OPZ konkretnych rekomendacji KNF i europejskich organów nadzoru oraz konkretnych aktów prawnych, w tym Dyrektyw, z którymi ma być zgodny system na dzień odbioru oraz o wskazanie kryteriów odbioru systemu w tym zakresie.

8.8. Zapis OPZ - zarzut dot. wymagań biznesowych WB.009.

Zdaniem wykonawcy Comarch w obecnym kształcie opis wymagania WB.009 uniemożliwia wykonanie wyceny oferty, ze względu na brak podstawowych informacji.

8.9. Zapis OPZ - zarzut dot. wymagań biznesowych WB.016.

Zamawiający ustalił, że:

„WB.016 - Narzędzie do automatycznego przenoszenia konfiguracji i parametryzacji między środowiskamiMożliwość automatycznego przenoszenia konfiguracji 1 parametryzacji między środowiskami”.

Żądanie: Doprecyzowanie wymagania poprzez precyzyjne wskazanie elementów konfiguracyjnych, które mają być przenoszone.

Uzasadnienie zarzutu: Obecny zapis uniemożliwia wycenę oferty, nie jest wiadome, jaka jest skala pracochłonności wykonawcy w celu wykonania tego wymagania.

8.10. Zapis OPZ - zarzut dot. wymagań PU.003 i PU.004.

Zamawiający sprecyzował: „PU.003 - Konwersja dyspozycji składanych za pomocą Usług WS na usługi udostępniane przez systemy Zamawiającego - Rozwiązanie musi zapewnić konwersję zapytań z Systemów FK/ERP (składanych za pomocą Usług WS) na formaty interfejsów systemów udostępnianych przez BGK dla Systemu H2H, w tym konwersję danych na formaty XML, PDF, MT101, MT940, MT942, Videotel, CSV, TXT - w szczególności te, które są obsługiwane przez system bgk24). W przypadku obsługi niektórych Usług WS (w celu obsłużenia jednego zapytania) może wystąpić konieczność wywołania kilku różnych zapytań do systemów wewnętrznych (lub wielokrotne ich wywoływanie).

PU.004 - Konwersja odpowiedzi systemów Zamawiającego na odpowiedz] zgodne z formatami Usług WS.Rozwiązanie musi zapewnić konwersję odpowiedzi systemów Zamawiającego na format Usług WS wysyłanych przez System H2H do systemów klientów zadających zapytania za pomocą Usług WS. W przypadku obsługi niektórych Usług WS (w celu obsłużenia jednego zapytania) może wystąpić konieczność wywołania kilku różnych zapytań do systemów wewnętrznych (lub wielokrotne ich wywoływanie)”.

Żądanie: Określenie precyzyjnej i enumeratywnej listy wszystkich formatów wraz z przykładami plików oraz konkretnej listy zapytań oraz zasad wywołań dla wszystkich koniecznych do obsługi zapytań.

Uzasadnienie zarzutu: Brak powyższych informacji powoduje niemożność określenia zakresu zobowiązania wykonawcy, wymagania te są nieprecyzyjne i ogólnikowe, co uniemożliwia złożenie oferty.

8.11. Zapis OPZ- zarzut dot. wymagań PU.006, PU.034, PU.035, PU.036 i PU.045.

Zamawiający ustalił: „PU.006 - Możliwość skierowania wybranych Dyspozycji do obsługi przez system bankowości elektronicznej - Rozwiązanie musi zapewnić funkcjonalność polegająca na możliwości zlecenia wybranych Dyspozycji, które zostaną skierowane do dalszej obsługi przez system obsługi w systemie bankowości elektronicznej udostępnianej wybranym klientom. Dyspozycje mogą mieć różne zasady autoryzacji w Systemie H2H określane na poziomie konfiguracji Klienta, np. Dyspozycje kierowane do bankowości elektronicznej mogą być tylko autoryzowane Certyfikatem transportowym i nie podlegać weryfikacji schematów akceptacji i limitów w Systemie H2H.

PU.034 - Lista złożonych dyspozycji transakcyjnych (historia zleceń) - Dyspozycja informacyjna obsługiwana przez Usługę WS.

PU.035 - Status wskazanej dyspozycji transakcyjnej - Dyspozycja informacyjna obsługiwana przez Usługę WS.

PU.036 - Status dyspozycji (lista dyspozycji) - Dyspozycja informacyjna obsługiwana przez Usługę WS”.

Żądanie: Określenie precyzyjnych zasad integracji z systemem bankowości elektronicznej (wyczerpująca i enumeratywna lista API, przykładowe komunikaty dla każdego API), określenie typów dyspozycji objętych wymaganiami PU.034-do PU.036 oraz określenie precyzyjnej i enumeratywnej listy wszystkich formatów wraz z przykładami plików na potrzeby realizacji wymagania PU.045.

Uzasadnienie zarzutu: Brak powyższych informacji powoduje niemożność określenia zakresu zobowiązania wykonawcy, wymagania te są nieprecyzyjne i ogólnikowe, co uniemożliwia złożenie oferty.

8.12. Zapis OPZ - zarzut dot. wymagania PU.056.

Brak powyższych informacji powoduje niemożność określenia zakresu zobowiązania wykonawcy, wymagania te są nieprecyzyjne i ogólnikowe, co uniemożliwia złożenie oferty.

8.13. Zapis OPZ - zarzut dot. wymagania PU.057.

Zamawiający w OPZ sprecyzował, że:

„PU.057 - Pobranie wyciągów dla kredytów (również w dodatkowych formatach XML, PDF, MT94Q, Videotel, CSV, TXT) - Dyspozycja informacyjna obsługiwana przez Usługę WS”.

Żądanie: Określenie precyzyjnej i enumeratywnej listy wszystkich formatów wraz z przykładami plików.

Uzasadnienie zarzutu: Brak powyższych informacji powoduje niemożność określenia zakresu zobowiązania wykonawcy, wymagania te są nieprecyzyjne i ogólnikowe, co uniemożliwia złożenie oferty.

8.13. - Zapis OPZ - zarzut dot. wymagania PU.061.

Zamawiający w OPZ sprecyzował, że: „PU.061 – Weryfikacja występowania rachunku odbiorcy Dyspozycji transakcyjnej na 1 iście podatników VAT - Dyspozycja informacyjna obsługiwana przez Usługę WS”.

Żądanie: Usunięcie wymagania PU.061 ze względu na brak istniejącego rozwiązania back-end po stronie Zamawiającego.

Uzasadnienie zarzutu: Wymaganie to nie jest możliwe do zrealizowania z przyczyn technicznych, związanych z brakiem po stronie rozwiązania back-end po stronie Zamawiającego.

8.14. Zapis OPZ - zarzut dot. wymagania PU.064.

Zamawiający w OPZ ustalił, że: „PU.064 - Zlecenie dyspozycji wygenerowania raportu przez systemy Zamawiającego - Dyspozycja informacyjna obsługiwana przez Usługę WS”.

Żądanie: Określenie precyzyjnej i enumeratywnej listy wszystkich raportów wraz z określeniem ich zawartości poprzez sporządzenie - jako załączników do SIWZ - wzorów oczekiwanych raportów.

Uzasadnienie zarzutu: Brak powyższych informacji powoduje niemożność określenia zakresu zobowiązania wykonawcy, wymagania te są nieprecyzyjne i ogólnikowe, co uniemożliwia złożenie oferty.

8.15. Zapis OPZ - zarzut dot. wymagania PU.010.

Zamawiający w OPZ ustalił, że: „PU.010 - Mechanizm konwersji komunikatów - Rozwiązanie musi zapewnić mechanizm dwukierunkowego mapowania i transformacji danych z formatów specyficznych dla systemów Zamawiającego na format wystawiany dla systemów ERP/FK.

PU.011 - Obsługa błędów - Rozwiązanie musi zapewnić mechanizm obsługi błędów związanych z procesem przetwarzania dyspozycji Klienta (Szczegółowe zasady obsługi błędów zostaną uzgodnione na etapie Analizy przedwdrożeniowej rozwiązania)”.

Żądanie: Określenie na potrzeby PU.010 precyzyjnej i enumeratywnej listy wszystkich formatów danych do mapowania ¡transformacji wraz z przykładami plików.

Uzasadnienie zarzutu: Brak powyższych informacji powoduje niemożność określenia zakresu zobowiązania wykonawcy, wymagania te są nieprecyzyjne i ogólnikowe, co uniemożliwia złożenie oferty.

8.16. Zapis OPZ - zarzut dot. zakresu Usług serwisowych wobec „innych Produktów".

Zamawiający w OPZ sprecyzował: „2. Wykonawca zobowiązuje się do świadczenia Usług Serwisowych w odniesieniu do poszczególnych części Systemu H2H, Systemu H2H, jako całości, w tym w odniesieniu do całego Oprogramowania, Infrastruktury IT i innych Produktów”.

Żądanie: Usunięcie nieprecyzyjnego zapisu „i innych Produktów" i określenie precyzyjnej listy Produktów i zakresu czynności wymaganych przez Zamawiającego w ich zakresie.

Uzasadnienie zarzutu: Brak powyższych informacji powoduje niemożność określenia zakresu zobowiązania wykonawcy, wymagania te są nieprecyzyjne i ogólnikowe, co uniemożliwia złożenie oferty.

8.17. Zapis OPZ - zarzut dot. dostosowania Systemu H2H do współpracy z nowymi wersjami Oprogramowania Pomocniczego.

Wykonawca Comarch podnosił, że nie jest w stanie spełnić powyższego wymagania, zarówno wobec wymagania „niezwłoczności". Zakres prac dostosowawczych na chwilę złożenia oferty jest nieznany i niemożliwy do przewidzenia.

8.18. Zapis OPZ - zarzut dot.

Zamawiający w SIWZ wskazał, że: „g. Zobowiązanie Wykonawcy do zapewnienia ciągłości dostępu i przetwarzania danych w każdej kolejnej, nowej i ulepszonej wersji Oprogramowania poprzez dostosowywanie lub opracowanie funkcji eksportu/ importu Oprogramowania lub dostawę innych specjalizowanych do tego celu narzędzi lub przygotowanie przeprowadzenia migracji baz danych. W szczególności Wykonawca musi zapewnić jednoczesność wprowadzenia niezbędnych zmian u klientów w sposób automatyczny lub z pełnym wsparciem dla klientów”.

Żądanie: Usunięcie zapisu.

Uzasadnienie zarzutu: Wykonawca nie jest w stanie spełnić powyższego wymagania, są one nierealne, a zakres prac na chwilę złożenia oferty jest nieznany i niemożliwy do przewidzenia.

8.19. Zapis OPZ - zarzut dot.

Odwołujący wskazywał, że obydwa zapisy wykluczają się. Wykonawca nie jest w stanie jednocześnie ich spełnić. Ponadto zapis (pkt 14) jest nieprecyzyjny, co uniemożliwia poprawna wykładnię i stosowanie tego zapisu.

8.20. Zapis OPZ - zarzut dot. pomniejszenia czasochłonności.

Wykonawca Comarch stwierdził, że czasochłonność jest szacowana i pomniejsza pulę przed realizacją zamówienia, zatem nie można jej pomniejszać po odebraniu Usługi rozwoju.

8.21. Zapis OPZ - zarzut dot.

Zamawiający w OPZ ustalił, że: „c. Zgłoszenie Serwisowe uznaje się za dokonane z chwilą, gdy zostało prawidłowo zarejestrowane i przekazane do Wykonawcy,

d. Kwalifikacji Wady dokonuje Zamawiający. W przypadku odmiennej oceny w zakresie kwalifikacji Wady, przyjmuje się kwalifikację Wady wskazaną przez Zamawiającego, jako właściwą do trybu podjęcia I realizacji działań zmierzających do usunięcia Wady, a pełnomocnicy stron podejmują działania w zakresie ostatecznego rozstrzygnięcia kwestii sporu i polubownego rozwiązania problemu,”

Żądanie: Zmiana zapisu - Zgłoszenie Serwisowe powinno być uznane za dokonane od podjęcia reakcji zgodnie ustalonym Czasem Reakcji oraz dostarczeniem kompletu danych wymaganych do analizy zgłoszenia.

Uzasadnienie zarzutu: Zapis nie uwzględniania konieczności dostarczenia kompletu danych wymaganych do analizy zgłoszenia, przerzucając ryzyko związane z jego niepełnym lub wadliwym opisem na wykonawcę. Zamawiający powinien być zobowiązany do dostarczenia kompletu danych wymaganych do analizy zgłoszenia, a uchybienia w tym zakresie nie powinny obciążać wykonawcę.

8.22. Zapis OPZ - zarzut dot.

Zamawiający w OPZ sprecyzował, że: „a. Pomoc w analizie I rozwiązywaniu problemów z Oprogramowaniem i infrastrukturą IT, w tym Infrastrukturą Zamawiającego,”

Żądanie: Określenie precyzyjnego zakresu zobowiązań wykonawcy w ramach wymaganej „pomocy" w sposób umożliwiający oszacowanie usługi, albo - w przypadku braku takiej możliwości - usuniecie usługi z usług o charakterze ryczałtowym i objęcie jej mechanizmem zlecania po określeniu zakresu pracochłonności i jej uzgodnieniu przez strony oraz rozliczania jej na podstawie ceny za 1 dzień roboczy podanej w ofercie, stosownie do wykonanych prac.

9. Zarzut dot. braku opisu przedmiotu zamówienia poprzez odesłanie w celu określenia zakresu zobowiązań wykonawcy do etapu „Analizy przedwdrożeniowej".

Odwołujący wyjaśniał, że uzasadnia powyższy zarzut łącznie. Wszystkie niżej wymienione zapisy OPZ nie precyzują wymagań, co do przedmiotu zamówienia zgodnie z Pzp, w wyniku, czego na dzień składania ofert zakres tych zobowiązani jest nieznany. Zamawiający postanowił, bowiem o ich określeniu dopiero po zawarciu umowy, na etapie Analiz przedwdrożeniowej. W związku z powyższym jest oczywiste, że na etapie ofertowania wykonawca nie jest w stanie podjąć z SIWZ wiedzy ani okreśiić/oszacować zakresu prac, które musi wycenić w ofercie. Odwołujący wskazywał, że dla wszystkich niżej wymienionych zapisów żąda zobowiązania Zamawiającego do określenia precyzyjnego wszystkich wymagań OPZ, co, do których zdecydował o ich dookreślenie na etapie Analizy przedwdrożeniowej - już w treści samej specyfikacji, by była dostępna wykonawcom przed złożeniem oferty.

9.1.

Zamawiający w OPZ sprecyzował, że: „5.3. Wysokopoziomowe wymagania biznesowe (WB)

1. Komunikacja pomiędzy Systemem H2H, a Systemem FK/ERP Klienta realizowana będzie w oparciu o następujące standardy:

a. Standard wymiany danych zgodny z Certyfikatem IS020022,

b. Rekomendację Związku Banków Polskich w sprawie przyjęcia standardu wymiany danych finansowych pomiędzy klientem, a bankiem v.3.0 z marca 2018 roku {z uwzględnieniem aktualizacji),

c. Formaty danych ELIXIR, EUROELIXIR, SĘPA,

d. Simple Object Access Protocol (SOAP) lub Representational state transfer (REST),

e. Web Services Description Language (WSDL).

2. W przypadku, jeżeli powyższe rekomendacje nie określają specyfikacji dla wybranych Dyspozycji (komunikatów biznesowych) ich struktura zostanie określona przez Zamawiającego na etapie Analizy przedwdrożeniowej rozwiązania.

3. Rozwiązanie musi spełniać wymagania rekomendacji KNF oraz europejskich organów nadzoru oraz powszechnie obowiązującego w Polsce prawa, w szczególności Dyrektywy unijnej PSD2 oraz aktów do niej wykonawczych [tzw. RTS)”.

Żądanie: Usunięcie nieprecyzyjnego zapisu 53.2 („na etapie Analizy przedwdrożeniowej") i zastąpienie precyzyjnym opisem określającym zakres wymagań.

9.2.

Zamawiający w OPZ ustalił, że „WB.006 - Interfejs użytkownika - Rozwiązanie musi zapewnić graficzne interfejsy użytkownika (osobny portal dla użytkowników Klientów Zamawiającego i dla Pracowników Zamawiającego) pozwalające na konfigurację, monitorowanie i zarządzanie procesem obsługi Usługi WS oraz zarządzanie Certyfikatami autoryzacyjnymi i transportowymi. Szata graficzna interfejsów zostanie przygotowana zgodnie ze standardami określonymi w Księdze Identyfikacji Wizualnej Zamawiającego, przekazanej Wykonawcy na etapie Analizy przedwdrożeniowej rozwiązania. Układ interfejsu zostanie uzgodniony na etapie Analizy przedwdrożeniowej rozwiązania. Interfejs portalu dl Klienta powinien zapewniać pełną obsługę zarówno w języku polskim jak i angielskim (alternatywnie). Treść (dla każdego z obsługiwanych języków) menu, etykiet, komunikatów informacyjnych oraz o błędach, animacji i grafiki, oraz pomocy powinno być możliwa do modyfikacji przez Administratora Biznesowego. Szczegóły zostaną uzgodnione na etapie Analizy przedwdrożeniowej rozwiązania”.

Żądanie: Usunięcie zapisu „Szczegóły zostaną uzgodnione na etapie Analizy przedwdrożeniowej rozwiązania". Określenie precyzyjnych wymagań.

9.3

Zamawiający w OPZ podał: „WB.012 - API dla systemów zewnętrznych - 1. Rozwiązanie udostępni interfejs programistyczny API. Szczegóły zostaną ustalone na etapie Analizy przedwdrożeniowej rozwiązania.2. Dostarczone API musi zawierać obsługę funkcjonalności obsługiwanych w interfejsach użytkownika dostępnych dla Pracowników Zamawiającego i jego klientów. API będzie w przyszłości wykorzystywane do integracji Systemu H2H np. z systemami workflow lub front/backend w zakresie obsługi klientów lub udostępniania funkcjonalności przeznaczonej dla klientów w Systemie H2H”. 

Żądanie: Usunięcie zapisu „Szczegóły zostaną ustalone na etapie Analizy przedwdrożeniowej rozwiązania". Określenie precyzyjnych wymagań.

9.4.

Zamawiający w OPZ podał: „PU.012 - Uwierzytelnienie Klienta w portalu do zarządzania Certyfikatami - Rozwiązanie musi zapewnić mechanizmy Uwierzytelnienia dostępu Klienta i jego użytkowników do portalu Klienta służącego do zarządzania Certyfikatami. Szczegóły rozwiązania zostaną opracowane na etapie Analizy przedwdrożeniowej rozwiązania”.

Żądanie: Usunięcie zapisu „Szczegóły rozwiązania zostaną opracowane na etapie Analizy przedwdrożeniowej rozwiązania". Określenie precyzyjnych wymagań.

9.5. Strona 43 OPZ:

„PU.001 - Obsługa usług umożliwiających składanie/modyflkację/odwołanie pojedynczych Dyspozycji - Obsługa Usług WS umożliwiających realizację pojedynczych Dyspozycji realizowanych przez Usługi WS wymienionych niżej. Szczegółowa lista I budowa Usług WS zostanie określona na etapie Analizy przedwdrożeniowej rozwiązania.

PU.002 - Obsługa usług umożliwiających składanie/modyfikację/odwołanie dyspozycji postaci paczek (jednej lub więcej niż jedna liczba Dyspozycji) - Obsługa Usług WS umożliwiających w pojedynczym ich wywołaniu realizację jednej lub więcej Dyspozycji (tzw. paczek) Szczegółowa lista I budowa Usług WS obsługujących paczki zostanie określona na etapie Analizy przedwdrożeniowej rozwiązania”.

Żądanie: Usunięcie zapisów „zostanie określona na etapie Analizy przedwdrożeniowej rozwiązania". Określenie precyzyjnych wymagań.

9.6. Zapis OPZ - zarzut dot. wymagania PU.011 

Zamawiający w OPZ podał: „PU.010 - Mechanizm konwersji komunikatów - Rozwiązanie musi zapewnić mechanizm dwukierunkowego mapowania i transformacji danych z formatów specyficznych dla systemów Zamawiającego na format wystawiany dla systemów ERP/FK.

PU.011 - Obsługa błędów -Rozwiązanie musi zapewnić mechanizm obsługi błędów związanych z procesem przetwarzania dyspozycji Klienta (Szczegółowe zasady obsługi błędów zostaną uzgodnione na etapie Analizy przedwdrożeniowej rozwiązania)”.

Żądanie: Usunięcie zapisów „zostanie uzgodniona na etapie Analizy przedwdrożeniowej rozwiązania". Określenie precyzyjnych wymagań.

9.7. - 5. WB.005 - Autoryzacja dyspozycji Klienta

Zamawiający w OPZ ustalił: „PU.001 – Autoryzacja dyspozycji Klienta - 1.Rozwiązanie musi zapewnić funkcjonalność weryfikacji dyspozycji Klienta składanych z poziomu systemów ERP/FK zgodnie ze zdefiniowanymi regułami biznesowymi:

a. Weryfikacją adresów IP uprawnionych do korzystania z konkretnie udostępnionej Usługi H2H,

b. Weryfikacją usług dostępnych dla Klienta/użytkownika,

c. Weryfikacją rachunków,

d. Weryfikacją schematów akceptacji,

e. Weryfikacją limitów transakcyjnych,

f. Weryfikacji ważności podpisów w formacie XADES.

(Szczegółowe zasady walidacji zostaną uzgodnione na etapie Analizy przedwdrożeniowej rozwiązania}.

1.Rozwiązanie musi zapewnić funkcjonalność parametryzowania reguł biznesowych na poziomie udostępnionej usługi H2H dla

PU.003 - Obsługa błędów - Rozwiązanie musi zapewnić mechanizm obsługi błędów związanych z procesem autoryzacji dyspozycji Klienta (Szczegółowe zasady obsługi błędów zostaną uzgodnione na etapie Analizy przedwdrożeniowej rozwiązania)”.

Żądanie: Usunięcie zapisów „zostaną uzgodnione na etapie Analizy przedwdrożeniowej rozwiązania". Określenie precyzyjnych wymagań.

9.8.

Zamawiający w OPZ podał: „PU.006 – Moduł raportowy - Rozwiązanie musi umożliwiać bieżące monitorowanie stanu realizacji Dyspozycji, czasu ich realizacji i czasu ich oczekiwania na realizacją oraz funkcjonalność automatycznego generowania powiadomień alarmowych (mail, sms, system monitoringu Zamawiającego) informujących o przekroczeniu określonych w OPZ oraz na etapie Analizy przedwdrożeniowej rozwiązania - progów alarmowych dla obsługi dla poszczególnych typów Dyspozycji. System H2H musi umożliwiać swobodną parametryzacją przez Zamawiającego progów alarmowych oraz kanałów informowania o ich przekroczeniu dla poszczególnych Dyspozycji”.

Żądanie: Usunięcie zapisu „oraz na etapie Analizy przedwdrożeniowej rozwiązania". Określenie precyzyjnych wymagań. Określenie precyzyjnego zakresu parametryzacji (rodzaje zmian, parametry konfiguracyjne).

9.9.

Zamawiający w OPZ podał: „Wl.001 - Integracja z centralnym systemem BGK - W celu zapewnienia spójności wymienianych danych oraz rozliczalności przepływu informacji, integracja Systemu H2H z systemem centralnym Zamawiającego musi odbywać sią z wykorzystaniem szyny integracyjnej Zmawiającego. Szczegółowe zasady integracji zostaną ustalone na etapie Analizy przedwdrożeniowej rozwiązania.

WI.002 - Integracja z systemem bankowości elektronicznej BGK - Integracja Systemu H2Hz systemem bankowości elektronicznej BGK musi odbywać sią za pośrednictwem udostępnianych usług przez system bankowości elektronicznej BGK. Szczegółowe zasady integracji zostaną ustalone na etapie Analizy przedwdrożeniowej rozwiązania”.

Żądanie: Usunięcie zapisów „Szczegółowe zasady integracji zostaną ustalone na etapie Analizy przedwdrożeniowej rozwiązania". Określenie precyzyjnych wymagań.

9.10.

Zamawiający w OPZ sprecyzował:

Żądanie: Usunięcie zapisów „oraz doprecyzowanych na etapie Analizy przedwdrożeniowej rozwiązania." (dwa razy), „muszą być dostosowane do rozwiązań Zamawiającego". Określenie precyzyjnych wymagań.

9.11. d) Dostarczenie Systemu H2H i Testy Odbiorcze.

Odwołujący w tym miejscu w formie tabelarycznej przytoczył stosowne postanowienia OPZ.

Żądanie: Usunięcie nieprecyzyjnego zapisu „Uzgodnienie Scenariuszy testowych przez Zamawiającego i Wykonawcę przed planowanym terminem rozpoczęcia Testów Odbiorczych". Zastąpienie precyzyjną listą scenariuszy testowych.

Usunięcie nieprecyzyjnego zapisu „i brak Wad uniemożliwiających wdrożenie produkcyjne". Zastąpienie precyzyjną definicją Wad, które uniemożliwiają wdrożenie.

Usunięcie zapisu „Wsparcie w zakresie przygotowania i realizacji Testów Odbiorczych, które są przeprowadzane przez Zamawiającego lub przez podmioty trzecie, którym zlecił on ich realizację na własny koszt". Doprecyzowanie zakresu wsparcia.

Usunięcie zapisu „oraz doprecyzowanych na etapie Analizy" (wszystkie wystąpienia w ramach powyższego fragmentu). Doprecyzowanie zakresu w ramach SIWZ.

9.12

Zamawiający w OPZ podał:

Żądania: Usunięcie nieprecyzyjnego zapisu „Zdefiniowanie odpowiednich uprawnień, import/założenie kont użytkowników, udostępnienie i skonfigurowanie interfejsów". Zastąpienie precyzyjną listą czynności do wykonania. 

Usunięcie zapisu „oraz doprecyzowanych na etapie Analizy" (wszystkie wystąpienia w ramach powyższego fragmentu). Doprecyzowanie zakresu w ramach SIWZ.

Usunięcie nieprecyzyjnego fragmentu „i jakości przeprowadzonych warsztatów" ze względu na brak definicji kryteriów jakościowych.

9.13.

Zamawiający w OPZ ustalił: „3. W zakresie obsługi zgłoszeń Serwisowych Strony obowiązują poniższe zasady:

a. Osoba upoważniona ze strony Zamawiającego powiadamia Wykonawcę o wystąpieniu Wady dokonując Zgłoszenia Serwisowego,

b. Zgłoszenie Serwisowe polega na przekazaniu do Wykonawcy informacji o Wadzie, jej zakresie, znanych przyczynach ¡skutkach. Przekazanie informacji winno nastąpić za pośrednictwem systemu informatycznego, zapewniającego zapisywanie logów czynności i zdarzeń, dokumentującego działania obu stron, w systemie serwisowym, telefonicznie lub poczty elektronicznej, na adres Zalecane jest stosowanie poczty elektronicznej z potwierdzeniem przekazania i odczytania wiadomości, przekazywane dane nie mogą zawierać dane osobowe lub stanowiących tajemnicę bankową w przypadku konieczności przekazania takich danych Wykonawca przed okres dostarczy i będzie utrzymywał (w szczególności dostosowywał do zmian Systemu H2H) przez okres obowiązywania Umowy odpowiednie narzędzia do anonimizacji takich danych w sposób, który uniemożliwią odczytanie danych osobowych i ujawnienie danych stanowiących tajemnicę bankową. Zakres danych objętych anonimizacją oraz sposób ich przekazywania i sposób okres przechowywania przez Zamawiającego zostanie ustalony na Etapie analizy przedwdrożeniowej rozwiązania”.

Żądanie: Usunięcie zapisu „ustalony na etapie Analizy przedwdrożeniowej rozwiązania". Doprecyzowanie zakresu w ramach SIWZ.

Zamawiający odpowiedział na złożone odwołanie na piśmie, w którym wnosił o: oddalenie odwołania w całości. W uzasadnieniu Zamawiający podnosił m. in., że:

1.Nieprecyzyjne określenie przedmiotu zamówienia w zakresie Infrastruktury IT.

W dniu 5 lutego 2021 r. dokonano zmiany SIWZ, w zakresie kwestionowanego przez Odwołującego postanowienia. Zamawiający podkreślał, że dokonana zmiana nie stanowi uwzględnienia zgłoszonego zarzutu.

2.Nieprecyzyjne określenie przedmiotu zamówienia w zakresie integracji z Hurtownią danych.

Zamawiający podniósł, że wymaganie dotyczy informacji biznesowych o przeprowadzonych transakcjach a wykonawca będzie zobowiązany do przygotowania projektu i zaproponowania określonego rozwiązania technicznego. Zamawiający stwierdził, że jednoznacznie określił w OPZ, iż wymagane jest „Przekazywanie informacji biznesowych o przeprowadzonych transakcjach do hurtowni danych” oraz, że „Wykonawca musi opracować i uzgodnić z Zamawiającym Projekt techniczny Systemu H2H…”, który w szczególności będzie zawierał „Projekt rozwiązania zasilenia hurtowni danych”. Zamawiający wskazał, że nie zna konkretnego rozwiązania, które zostanie wdrożone w ramach wybranej oferty. Na wykonawcy, który ma doświadczenie we wdrożeniach Systemu H2H i wie, jakie dane są przetwarzane przez oferowany przez niego system oraz jakie dane oraz w jakim układzie mogą być udostępniane dla Hurtowni Danych. Zamawiający podkreślał, że nie narzuca wykonawcy rozwiązania w tym zakresie. W ocenie Zamawiającego wykonawca, jako profesjonalista, który ma doświadczenie we wdrożeniach Systemów H2H jest w stanie oszacować i wycenić niezbędny zakres prac.

3.Określenie raportów, które mają być generowane przez moduł raportowy w sposób otwarty, co uniemożliwia sporządzenie wyceny.

Zamawiający stwierdził, że zarzut sformułowano w oparciu o błędną interpretację wymagań a wskazana lista nie stanowi listy raportów, a listę aktywności, dla których będzie można wygenerować raporty. Zamawiający wskazał, że określił wymaganie „WB.007 Moduł raportowy”: „Rozwiązanie musi zapewnić funkcjonalność generowania raportów z poziomu interfejsu użytkownika przeznaczonego dla Pracowników Zamawiającego”. Doprecyzowując to wymaganie zamawiający określił, iż: „Rozwiązanie musi zapewnić funkcjonalność generowania raportów (z możliwością zapamiętania i modyfikowania ich definicji) z aktywności w kanale H2H prezentujących, np.: ….” Zamawiający wyjaśniał, że wymieniona dalej lista nie stanowi listy raportów, ale listę aktywności, dla których będzie można wygenerować raporty, których definicję można zapamiętać i później zmodyfikować). Szczegółowe wymagania dotyczące realizacji wymagań zależą od zaproponowanego przez wykonawcę rozwiązania, Zamawiający nie zna rozwiązania, które zostanie wdrożone w ramach wybranej oferty. Zamawiający podkreślała, że przyjął założenie, że wykonawca może dysponować szerszym zakresem funkcjonalnym modułu raportowania adekwatnym do zaproponowanego rozwiązania. Zamawiający uważał, że dochował najwyższej staranności, aby przedmiot zamówienia sformułowany został w sposób wyczerpujący wszystkie wskazania określone w art. 29 Pzp. Dodatkowo wskazywał, że przepis art. 29 ust. 1 Pzp nakazujący sporządzenie opisu przedmiotu zamówienia w sposób wyczerpujący i jednoznaczny, nie wymaga, aby każdy element przedmiotu zamówienia musiał mieć charakter zamknięty. Z przyczyn obiektywnych (uzasadnionych technicznie) nie jest możliwe zdefiniowanie każdego pojęcia w sposób ściśle dookreślony. W ocenie Zamawiającego określił on przedmiot umowy oraz wymagania w sposób precyzyjny, zastrzegając jedynie, iż szczegółowe określenie niektórych wymagań zostanie dokonane na etapie analizy przedwdrożeniowej także w zależności od możliwości i funkcjonalności proponowanego przez wykonawcę rozwiązania. Model taki jest na gruncie ustawy dopuszczalny, ponieważ Zamawiający nigdy na etapie badania ofert nie uzyskuje pełnej wiedzy o oferowanym produkcie, w szczególności funkcjonalności i możliwościach konkretnego produktu teleinformatycznego. Wykonanie analizy przedwdrożeniowej ma na celu uszczegółowienie przedmiotu umowy i opisanie sposobu jej realizacji. W trakcie prac mających na celu stworzenie analizy, wykonawca, działając zgodnie z najlepszą wiedzą, powinien zweryfikować i przedstawić Zamawiającemu optymalne działania zmierzające do zapewnienia wykonania umowy i osiągnięcia jej celów. W szczególności wykonawca może zaproponować modyfikację wymagań Zamawiającego dotyczących oprogramowania, które nie mają uzasadnienia funkcjonalnego lub informatycznego.

Następnie Zamawiający podkreślał, że w projektach teleinformatycznych wyodrębnienie etapu analizy przedwdrożeniowej jest powszechnie stosowanym standardem.

4.Nieprecyzyjnie określone wymagania w zakresie integracji z systemem centralnym Zamawiającego.

Zamawiający podniósł, że dokumentacja usług zostanie udostępniona wykonawcy po zawarciu umowy, z uwagi na specyfikę danych, dokumentacja nie może być udostępniona na tym etapie. Po stronie wykonawcy leży wykonanie analizy usług w szczególności dotyczącej ich ewentualnej modyfikacji. Liczba niezbędnych usług do integracji z systemem centralnym jest pochodną Usług WS wymienionych w przypadkach użycia dla WB.003 – Obsługa usług WebService. Co do zasady BGK planuje zastosowanie takich samych usług, które są używane przez system bankowości elektronicznej bgk24 (dostarczony przez grupę Comarch), chyba, że w wyniku analizy z wykonawcą niektóre z tych usług zostaną zmodyfikowane (np. uproszczone, bo zawierają więcej informacji niż jest to potrzebne do obsługi WS). Zamawiający wyjaśnił, że ze względu na newralgiczność informacji szczegółowa dokumentacja zostanie udostępniona wykonawcy po zawarciu umowy.

5.Nieprecyzyjne określenie wymagań dotyczących integracji z systemem bankowości elektronicznej BGK.

Zamawiający podkreślał, że z przyczyn obiektywnych związanych z bezpieczeństwem Bank nie udostępnia publicznie dokumentacji interfejsów systemów wewnętrznych, informacje te zostaną przekazane po zawarciu umowy. Interfejsy (API) do systemu bgk24 zostały dostarczone Zamawiającemu wraz z tym systemem przez grupę Comarch. Ze względu na ich newralgiczny charakter Bank nie udostępnia publicznie dokumentacji interfejsów systemów wewnętrznych. Zgodnie ze stosowaną praktyką specyfikacje zostaną przekazane po zawarciu umowy z wykonawcą. Wskazane w OPZ rodzaje obsługiwanych dyspozycji i ich zakres danych oraz odwołania do standardów Usług WS determinuje, jakiego rodzaju usługi będą musiały być użyte. Co do zasady, dyspozycje są kierowane do systemu centralnego lub innego systemu np. dostarczającego dane. Dodatkowo Zamawiający wskazał, że określił wymaganie „WB.003 PU.006 Możliwość skierowania wybranych Dyspozycji do obsługi przez system bankowości elektronicznej: „Rozwiązanie musi zapewnić funkcjonalność polegająca na możliwości zlecenia dyspozycji, które zostaną skierowane do dalszej obsługi w systemie bankowości elektronicznej udostępnianej wybranym klientom”. Zamawiający stwierdził, że to wymaganie stanowi, że każda Dyspozycja składana za pomocą Systemu H2H, która może być dalej obsługiwana w systemie bankowości elektronicznej może być skierowana do tego systemu z Usług WS. Cechy konkretnej Dyspozycji wymienionej w OPZ wskazują czy może ona być dalej obsługiwana w systemie bankowości elektronicznej. Ze względu na newralgiczność informacji szczegółowa dokumentacja interfejsów zostanie udostępniona wykonawcy po podpisaniu umowy. W ocenie Zamawiającego wykonawca, jako profesjonalista, który ma doświadczenie we wdrożeniach Systemów H2H musi być w stanie oszacować i wycenić niezbędny zakres prac na podstawie udostępnionych wymagań i posiadanej wiedzy technicznej.

6.Nieprecyzyjne określenie „poprawnego działania” w kontekście Okresu Stabilizacji i Okresu Weryfikacji Poprawności Działania.

Zamawiający podniósł, że Odwołujący pomija postanowienia SIWZ, które nie pozostawiają wątpliwości interpretacyjnych w świetle sformułowanego zarzutu. BGK wskazał, że jednoznacznie określił kryteria zakończenia etapu projektu. Zdaniem Zamawiającego powyższe oznacza, że jednoznacznym kryterium odbioru jest usunięcie wszystkich Wad zgłoszonych do zakończenia Okresu Stabilizacji. Ewentualny odbiór Systemu H2H z Wadami jest uprawnieniem a nie obowiązkiem Zamawiającego.

7.Nieprecyzyjne określenie „Systemy Zamawiającego”.

Zamawiający wyjaśniał, że systemy jednoznacznie wskazano w SIWZ. Zamawiający określił, jakie Dyspozycje ma obsługiwać System H2H z charakteru tych usług wynika, z jakimi usługami musi zintegrować się System H2H, w szczególności są to: system centralny i system bankowości elektronicznej, hurtownia danych, Active Directory, Open ID Connect - te systemy/rozwiązania są wprost wymienione w OPZ. Jednocześnie przedmiotem zamówienia jest rozwiązanie klasy API Management (platforma do zarządzania interfejsami API), której funkcjonalnością jest umożliwienie Zamawiającemu udostępnianie klientom i innym podmiotom różnych wewnętrznych API do usług i produktów Zamawiającego poprzez udostępnienie klientom i innym podmiotom bezpiecznej, ustandaryzowanej i zarządzanej warstwy usługowej API.

8.Pozostałe zarzuty odwołania zawarte w zarzucie nr 8 - nieprecyzyjne zapisy przedmiotu zamówienia, zapisy błędne (sprzeczne wzajemnie) oraz zapisy nie zawierające inwokacji umożliwiających wycenę oferty.

8.1. Czas naprawy.

Zamawiający podkreślał, że postanowienia SIWZ nie pozostawiają wątpliwości interpretacyjnych i jako takie nie wymagają zmiany. Zmiana SIWZ powoduje ryzyko, iż wykonawca mógłby jednostronnie decydować, kiedy przyjmuje zgłoszenie - czas na usuniecie awarii nie byłby mierzony.

Zamawiający podnosił, że system H2H będzie miał charakter systemu krytycznego, tzn. musi być zbudowany w architekturze umożliwiającej zachowanie wysokiej dostępności i odpornej na awarię (wymaganie OPZ). Wydane przez Komisję Nadzoru Finansowego w Rekomendacji D zalecenia określają, co powinny zawierać umowy z dostawcami zewnętrznymi usług, w szczególności umowy powinny określać parametry dotyczące, jakości świadczonych usług oraz sposoby ich monitorowania i egzekwowania, a także zasady i tryb obsługi zgłoszeń dotyczących problemów w zakresie świadczonych usług oraz zapewniać zgodność z regulacjami wewnętrznymi i zewnętrznymi oraz przyjętymi w banku standardami.

Zamawiający wskazał, że przyjmuje na siebie szereg obowiązków w zakresie dokonania zgłoszenia. Dlatego nie zgadzał się z żądaniem „czasokres powinien być liczony od momentu przyjęcia zgłoszenia z kompletem danych, a nie dokonania zgłoszenia”. W takim wypadku wykonawca mógłby jednostronnie decydować, kiedy przyjmuje zgłoszenie i czas na usuniecie awarii nie byłby mierzony. Sformułowanie „z kompletem danych” jest nieprecyzyjne, nie jest możliwy do określenia a priori, co jest „kompletem danych” to będzie zależeć od konkretnego zgłoszenia, a nawet działań, które wykonawca będzie podejmował w celu usunięcia awarii. Dyskusyjna jest też konieczność przekazywania tych danych w ramach zgłoszenia (a nawet w ogóle), gdyż w OPZ jednoznacznie oczkujemy, iż „Usługi serwisowe Systemu H2H będą świadczone w miejscu jego instalacji.” „Zamawiający może dopuścić możliwość zdalnego diagnozowania Systemu H2H przez Wykonawcę, w tym diagnozowania zdalnego z wykorzystaniem sieci Internet w środowisku testowym niezawierającym Informacji Chronionych.” Ponadto Zamawiający przewidział, że „Zakres danych objętych anonimizacją oraz sposób ich przekazywania i sposób okres przechowywania przez Zamawiającego zostanie ustalony na Etapie analizy przedwdrożeniowej rozwiązania”.

Zdaniem Zamawiającego nie jest uzasadnione żądanie, żeby „liczenie czasu naprawy powinno dotyczyć tylko sytuacji, w których zgłoszenie jest po stronie dostawcy, a nie nieprzerwanie wliczając w to czas po stronie banku” dodatkowo takie postanowienia rodziłoby możliwość ciągłego lub nadmiernego przekierowywania zgłoszenia od Dostawcy na Zamawiającego w celu wydłużania czasu uśnięcia awarii, a Zamawiający nie jest w stanie stwierdzić, czy ewentualne kolejne żądania są faktycznie niezbędne do uśnięcia awarii. Podkreślał, że określone czasy SLA mają przed wszystkim zapewnić oczekiwany poziom dostępności systemu a nie głównie stanowić przyczynę naliczania kar, dlatego w OPZ zawarto postanowienia w tym zakresie, które daleko wychodzą naprzeciwko potrzebom wykonawcy.

Zdaniem Zamawiającego możliwości liczenia czas naprawy liczony od momentu zgłoszenia nie budzi jakichkolwiek zastrzeżeń prawnych i jako taki stanowi standard rynkowy w umowach z obszaru IT. Stawiany zarzut w zakresie obawy braku stosownych informacji w zgłoszeniu nie znajduje oparcia w treści IPU - zgłoszenie określa dane możliwe do określenia przez Zamawiającego, co oznacza, iż Zamawiający w zgłoszeniu ma obowiązek podania wszelkich posiadanych informacji dotyczących ujawnionego błędu. W przypadku nieprawidłowego działania systemu teleinformatycznego, do którego zdalny dostęp ma wykonawca nie ulega wątpliwości, że jest on w stanie niezwłocznie po zgłoszeniu identyfikacji problemu i podjęcia działań celem jego usunięcia.

8.2 Definicja dokumentacji.

W ocenie Zamawiającego przytoczona definicja dokumentacji zawiera jednoznaczne stwierdzenie, że dotyczy zarówno przypadku zamówienia podstawowego i zamówienia opcjonalnego.

8.3 Zapis SIWZ – dot. Weryfikacji i Certyfikacji.

Zamawiający nie zgadzał się z żądaniem zmiany zapisu - zlecenie weryfikacji i certyfikacji składa się z kilku kroków, które pozwalają na jednoznaczne zweryfikowanie niezbędnej pracochłonności dla realizacji tego procesu.

8.4. Zapis SIWZ – dot. Usług Rozwoju Systemu H2H – pkt. 22 ppkt 4 lit. g. OPZ

Zamawiający stwierdził, że na gruncie SIWZ Zamawiający nie może zlecić takiego zamówienia, które przekracza dostępny limit roboczodni. W OPZ jednoznacznie wskazano, iż „Pracochłonność zlecenia zamówienia Usług Rozwoju Systemu H2H nie może przekroczyć aktualnego dostępnego limitu osobodni pracy, o którym mowa w pkt 2. Wyżej”.

8.5. Zapis OPZ – dot. wsparcia w rozwiazywaniu problemów (pkt 21 OPZ Usługi serwisowe).

Zamawiający podnosił, że system H2H będzie systemem o charakterze krytycznym – w związku z tym Zamawiający oczekuje również wsparcia wykonawcy w takim zakresie, jaki określono ww. pkt 21 a) – e). Nadrzędnym celem jest zapewnienie możliwości przywrócenia działania lub poprawnego działania lub danych tego systemu. Z uwagi na fakt, że Zamawiający wskazuje zamknięty katalog zdarzeń, w ocenie Zamawiającego Wykonawca, jako profesjonalista powinien być w stanie oszacować koszt takich działań. Zamawiający nie przewiduje dodatkowego wynagrodzenia, innych zasad jego obliczenia czy wprowadzenia limitów pracochłonności danego zlecenia dotyczącego usług wsparcia wykonawcy we wskazanych obszarach.

8.6. Zapis OPZ – dot. środowisk testowych i wymagań SLA.

Zamawiający stwierdził, że dostarczenie i wdrożenie środowisk testowych jest istotą zobowiązania. Ze względu na specyfikę rozwiązania środowiska testowe będą również wykorzystywane przez klientów. Zgodnie z OPZ: „Wdrożenie obejmuje instalację i konfigurację niezbędnej infrastruktury informatycznej i oprogramowania narzędziowego i systemowego dla podstawowego i zapasowego ośrodka przetwarzania danych, niezbędne do prawidłowej instalacji oraz uruchomienia i funkcjonowania SystemuH2H w wymaganych środowiskach: produkcyjnym, przedprodukcyjnym, testowym, integracyjnym/rozwojowym, testowym udostępnianym na zewnątrz sieci Zamawiającego jak środowisko produkcyjne dla prac testowych/integracyjnych Klientów”.

Dostarczenie i wdrożenie środowisk testowych jest istotą zobowiązania. Ze względu na specyfikę rozwiązania środowiska testowe będą również wykorzystywane przez klientów, dla których standardowym procesem będzie wdrożenie interfejsów po swojej stronie i przejście procesu ich weryfikacji na środowisku testowym, a także bieżącej możliwości weryfikacji zmian w systemach klienta. Dostęp środowiska testowego będzie również elementem podstawowej usługi, którą Zamawiający będzie świadczył swoim klientom – w konsekwencji Zamawiający będzie zobowiązany do zapewnienia parametrów funkcjonowania tych środowisk w tym usuwania występujących w nich awarii. Z uwagi na fakt, że Zamawiający wskazuje zamkniętą listę tych środowisk w ocenie Zamawiającego wykonawca, jako profesjonalista powinien być w stanie oszacować koszt takich działań. Zamawiający nie przewiduje dodatkowego wynagrodzenia, innych zasad jego obliczenia czy wprowadzenia limitów pracochłonności danego zlecenia dotyczącego usług wsparcia wykonawcy we wskazanych obszarach.

8.7. Zapis OPZ - zarzut dot. wymagań biznesowych pkt 5.3.3. OPZ.

W ocenie Zamawiającego kryteria odbioru systemu zostały jasno zdefiniowane i pozostają bez związku ze sformułowanym żądaniem Odwołującego. Jeżeli spełnienie nowych wymagań w zakresie rekomendacji organów nadzoru lub prawa powszechnie obowiązującego spowodowałby konieczność realizacji dodatkowych usług to zgodnie z art. 21 ust. 3 pkt 4) IPU i w związku z art. 144 ustawy Prawo zamówień publicznych z 29 stycznia 2004 r. strony mogą dokonać właściwej zmiany umowy.

Następnie Zamawiający podniósł, że kryteria odbioru systemu zostały jednoznacznie określone w OPZ. Weryfikacja wymagań Zamawiającego musi zostać skonkretyzowana i zaplanowana w ramach specyfikacji funkcjonalnych technicznych i scenariuszy testowych. Również jednoznacznie określono kryteria odbioru końcowego i produkcyjnie uruchomionego Systemu H2H.

8.8. Zapis OPZ - zarzut dot. wymagań biznesowych WB.009.

Zamawiający wyjaśnił, że w ramach umowy oczekuje dostarczenia rozwiązania, którego elementem będzie moduł klasy API Management, które zawiera zestaw narzędzi umożliwiających realizowanie wymagań określonych w OPZ:

API Gateway

definiowania i zarządzania API dla innych niż platforma H2H systemów Banku,

zarządzania zasadami korzystania i dostępu z/do API, w tym API innych niż dostarczonych w ramach platformy H2H,

monitorowania użycia i obciążenia API.

W ramach tych wymagań Zamawiający nie oczekuje możliwości wprowadzania żadnych zmian w kodzie źródłowym tych systemów/modułów. Dostarczone rozwiązanie API Management ma umożliwić Bankowi w ramach standardowej funkcjonalności tego rozwiązania zarządzanie przez ten moduł interfejsami API protokołu SOAP i stylu REST (pkt. 28 OPZ) zgodnie z ogólnie przyjętymi praktykami w zakresie samodzielnej budowy i publikowania takich interfejsów.

Na rynku istnieje szereg rozwiązań, które umożliwiają projektowanie, budowę, publikowanie, zarządzanie oraz monitorowanie interfejsów API, wykorzystywanych przez daną organizację bez ingerencji w ich kod źródłowy - np. 3Scale, Apigee, Akana, Kong, MuleSoft. Zamawiający nie narzuca konkretnego rozwiązania.

Zgodnie z powyższym realizacja wymagania WB.009 powinna zapewnić BGK narzędzia dające możliwość zdefiniowania własnych API w technologii SOAP/REST, opublikowania ich, jako nowe interfejsy zewnętrzne lub udostępnienie ich na potrzeby innych systemów BGK, jako nowe interfejsy wewnętrzne.

8.9. Zapis OPZ - zarzut dot. wymagań biznesowych WB.016.

Zamawiający stwierdził, że w wymaganiu WB.001 oraz powiązanych z nim przypadkach użycia zdefiniował, jakie są jego oczekiwania w zakresie funkcjonalności konfiguracji i parametryzacji. Zamawiający nie zna konkretnego rozwiązania, które zostanie wdrożone w ramach wybranej oferty i jakie jeszcze elementy w tym rozwiązaniu będą podlegały konfiguracji i parametryzacji. Wykonawcy, który ma już doświadczenie we wdrożeniach Systemu H2H powinien mieć wiedzę, które  elementy (poza oczekiwanymi przez Zamawiającego) są konfigurowane i parametryzowane w oferowanym przez niego rozwiązaniu i mogą być automatycznie przenoszone pomiędzy środowiskami.

Zamawiający wyjaśnił, że w ramach wymagania oczekuje rozwiązania, które umożliwi przeniesienie parametryzacji i konfiguracji wykonanej na jednym środowisku na inne w sposób, który pozwoli na uniknięcie konieczności ponownego ręcznego wykonywania tych wszystkich czynności przez pracowników, co może być źródłem poważnych błędów lub uniemożliwić poprawne działanie systemu (np. parametryzujemy i konfigurujemy usługi dla klienta X na środowisku testowym i po pozytywnie zakończonych testach, przenosimy tę konfigurację na środowisko produkcyjne – Zamawiający ma rozwiązania, które w ten sposób realizuje procesy zmiany na środowiska IT zamawiającego) Zamawiającego wykonawca, jako profesjonalista, który ma doświadczenie we wdrożeniach systemów H2H powinien być w stanie oszacować i wycenić niezbędny zakres prac.

8.10. Zapis OPZ - zarzut dot. wymagań PU.003 i PU.004.

Zamawiający podnosił, że w wymaganiach wskazał:

1. Komunikacja pomiędzy Systemem H2H, a Systemem FK/ERP Klienta realizowana będzie w oparciu o następujące standardy:

a. Standard wymiany danych zgodny z Certyfikatem ISO20022,

b. Rekomendację Związku Banków Polskich w sprawie przyjęcia standardu wymiany danych finansowych pomiędzy klientem, a bankiem v.3.0 z marca 2018 roku (z uwzględnieniem aktualizacji),

c. Formaty danych ELIXIR, EUROELIXIR , SEPA,

d. Simple Object Access Protocol (SOAP) lub Representational state transfer (REST),

e. Web Services Description Language (WSDL).

2. W przypadku, jeżeli powyższe rekomendacje nie określają specyfikacji dla wybranych Dyspozycji (komunikatów biznesowych) ich struktura zostanie określona przez Zamawiającego na etapie Analizy przedwdrożeniowej rozwiązania.

Specyfikacje te i ww. wymagania określają formaty wymiany danych z klientami w ramach WS, a formaty niezdefiniowanych w tych specyfikacjach są pochodnymi zakresu dyspozycji opisanych w przypadkach użycia dla wymagania WB.003 – Obsługa usług WebService i jest też uzależniona od liczby opcjonalnych dyspozycji, które zaoferuje wykonawca. Ponadto Zamawiający w przytoczonych wymaganiach enumeratywnie wyliczył wszystkie dodatkowe formaty.

8.11. Zapis OPZ - zarzut dot. wymagań PU.006, PU.034, PU.035, PU.036 i PU.045.

Analogicznie do odpowiedzi na zarzut nr 5.

Interfejsy (API) Interfejsy do systemu bgk24 zostały dostarczone Zamawiającemu wraz z tym systemem przez grupę Comarch. Ze względu na newralgiczny charakter Bank nie udostępnia publicznie dokumentacji interfejsów systemów wewnętrznych. Zgodnie ze stosowaną praktyką specyfikacje zostaną przekazane po zawarciu umowy z wykonawcą. Wskazane w OPZ rodzaje obsługiwanych dyspozycji i ich zakres danych oraz odwołania do standardów Usług WS determinuje, jakiego rodzaju usługi będą musiały być użyte. Co do zasady dyspozycje są kierowane do systemu centralnego lub innego systemu np. dostarczającego dane. Dodatkowo Zamawiający określił wymaganie „WB.003 PU.006 Możliwość skierowania wybranych Dyspozycji do obsługi przez system bankowości elektronicznej: Rozwiązanie musi zapewnić funkcjonalność polegająca na możliwości zlecenia dyspozycji, które zostaną skierowane do dalszej obsługi w systemie bankowości elektronicznej udostępnianej wybranym klientom.” To wymaganie stanowi, że każda Dyspozycja składana za pomocą Systemu H2H, która może być dalej obsługiwana w systemie bankowości elektronicznej może być skierowana do tego systemu z Usług WS. Cechy konkretnej Dyspozycji wymienionej w OPZ wskazują czy może ona być dalej obsługiwana w systemie bankowości elektronicznej. Wskazane w PU.034 do PU.036 Dyspozycje - ze względu na swój charakter, który polega na pobraniu konkretnych informacji a nie przekazaniu Dyspozycji do dalszej obsługi w systemie bgk24 – z tego powodu jednoznacznie nie podlegają wymaganiu skierowania do systemu bankowości elektronicznej. Wymaganie PU.0045 jest również precyzyjne format wyciągów dla usług webservices jest określony w Rekomendację Związku Banków Polskich w sprawie przyjęcia standardu wymiany danych finansowych pomiędzy klientem, a bankiem v.3.0 z marca 2018 roku (z uwzględnieniem aktualizacji). W wymaganiu PU.0045 Zamawiający enumeratywnie wyliczył wszystkie dodatkowe formaty: xml, pdf, mt101, mt 940, Videotel, CSV, TXT).

Ze względu na newralgiczność i względy bezpieczeństwa informacji - szczegółowa dokumentacja interfejsów zostanie udostępniona wybranemu wykonawcy po podpisaniu umowy. W ocenie Zamawiającego wykonawca, jako profesjonalista, który ma doświadczenie we wdrożeniach Systemów H2H powinien być w stanie oszacować i wycenić niezbędny zakres prac na podstawie udostępnionych wymagań i posiadanej wiedzy.

8.12. Zapis OPZ - zarzut dot. wymagania PU.056.

Zdaniem Zamawiającego zgłoszone żądanie jest nieuzasadnione. Ponadto stwierdzenie „Usunięcie wymagania ze względu na brak tego typu danych w systemach źródłowych na dzień złożenia zapytania” jest nieprawdziwe. Zamawiający posiada te dane w systemach źródłowych. Zamawiający jest Bankiem, którego główną działalnością jest udzielanie kredytów – jak mógłby nie posiadać tak podstawowych danych w systemach źródłowych.

8.13. Zapis OPZ - zarzut dot. wymagania PU.057.

W wymaganiu PU.0056 Zamawiający enumeratywnie wyliczył wszystkie dodatkowe formaty: xml, pdf, CSV, TXT). Ponadto w wymaganiu PU.003 – Zamawiający określił w przypadku formatów: XML, PDF, MT101, MT940, MT942, Videotel, CSV, TXT że chodzi o formaty obsługiwane przez system bgk24, który wdrożyła u Zamawiającego grupa Comarch. Przykłady tych formatów plików są zawarte w publicznie dostępnej dokumentacji systemu bgk24, który wdrożyła u Zamawiającego grupa Comarch.

Zapis OPZ - zarzut dot. wymagania PU.061.

Zamawiający podał, że żądanie nie znajduje żadnego uzasadnienia merytorycznego. Zobowiązanie wykonawcy jest jednoznaczne i ogranicza się do dostarczania Systemu H2H, który będzie umożliwiał klientom złożenie takiego zapytania i po jego weryfikacji zgodnie z określonymi zasadami przekazania do weryfikacji za pomocą ustalonej usługi do rozwiązania, które zapewni taką weryfikację na podstawie danych udostępnianych przez Ministerstwo Finansów i przekaże do Systemu H2H wyniki tej weryfikacje, które ten system przekaże, jako odpowiedź do systemu Klienta. BGK posiada różne rozwiązania techniczne i systemy, które umożliwiają udostępnienie wymaganej dla Systemu H2H funkcjonalności. Szczegółowe informacje oraz pliki z danymi oraz dokumentacja tych plików oraz sposób weryfikacji danych są udostępniane przez Ministerstwo Finansów na stronie: ().
‎W ocenie Zamawiającego wykonawca, jako profesjonalista, który ma doświadczenie we wdrożeniach systemów H2H powinien być w stanie oszacować i wycenić niezbędny zakres prac na podstawie udostępnionych wymagań i posiadanej wiedzy. Ponadto z informacji posiadanych przez Zamawiającego wynika, iż grupa Comarch wdrożyła rozwiązanie weryfikacji rachunków w bankowości elektronicznej np. Banku PKO S.A. oraz złożyła wstępna ofertę na wdrożenie takiego rozwiązania w systemie bankowości elektronicznej bgk24, który dostarczyła i utrzymuje u Zamawiającego.

8.14. Zapis OPZ - zarzut dot. wymagania PU.064

Zamawiający wyjaśniał, że funkcjonalności zlecania generowania raportów a następnie ich pobiera są oferowane w stosowanych na polskim rynku Systemach H2H (np. ING, BNP, R-Connect, NBE). Istotą usług jest przekazanie pomiędzy systemem klienta a Zamawiającego informacji, jaki raport ma wygenerować system Zamawiającego, a następnie po jego przygotowaniu i wywołaniu kolejnej usługi przekazać ten obiekt zawierający ten raport do systemu klienta. Zamawiający nie oczekuje żadnej ingerencji Systemu H2H w przekazywane raporty ani ich generowania przez System H2H. Żądanie Wykonawcy można by porównać do oczekiwania np. producenta poczty elektronicznej, że oczekuje, że użytkownicy wskażą wszystkie rodzaje dokumentów będą przesyłali za pomocą poczty i jaka jest struktura ich treści. Dane te są wyłącznie potrzebne nadawcy i odbiorcy tych komunikatów, a nie systemowi pośredniczącemu, jakim jest system H2H.

8.15. Zapis OPZ - zarzut dot. wymagania PU.010

Zamawiający zauważał, że Odwołujący ponawia żądania, które już określił w pkt: 5; 8.10; 8.11. W wymaganiach PU.010 i PU.011 w celu uniknięcia wątpliwości Zamawiający określa, że to rozwiązanie H2H ma konwertować dane pomiędzy interfejsami systemów wewnętrznych i zewnętrznych. Odp. Zamawiającego:

Zamawiający podnosił, że w wymaganiach wskazał:

3. Komunikacja pomiędzy Systemem H2H, a Systemem FK/ERP Klienta realizowana będzie w oparciu o następujące standardy:

f. Standard wymiany danych zgodny z Certyfikatem ISO20022,

g. Rekomendację Związku Banków Polskich w sprawie przyjęcia standardu wymiany danych finansowych pomiędzy klientem, a bankiem v.3.0 z marca 2018 roku (z uwzględnieniem aktualizacji),

h. Formaty danych ELIXIR, EUROELIXIR , SEPA,

i. Simple Object Access Protocol (SOAP) lub Representational state transfer

(REST),

j. Web Services Description Language (WSDL).

4. W przypadku, jeżeli powyższe rekomendacje nie określają specyfikacji dla wybranych Dyspozycji (komunikatów biznesowych) ich struktura zostanie określona przez Zamawiającego na etapie Analizy przedwdrożeniowej rozwiązania.

Specyfikacje te i ww. wymagania określają formaty wymiany danych z klientami w ramach WS, a formaty niezdefiniowanych w tych specyfikacjach są pochodnymi zakresu dyspozycji opisanych w przypadkach użycia dla wymagania WB.003 – Obsługa usług WebService i jest też uzależniona od liczby opcjonalnych dyspozycji, które zaoferuje Wykonawca. Ponadto Zamawiający w przytoczonych wymaganiach enumeratywnie wyliczył wszystkie dodatkowe formaty. Ze względu na newralgiczny charakter bank nie udostępnia publicznie dokumentacji interfejsów systemów wewnętrznych. Zgodnie ze stosowaną praktyką specyfikacje zostaną przekazane po zawarciu umowy z wykonawcą. Wskazane w OPZ rodzaje obsługiwanych dyspozycji i ich zakres danych oraz odwołania do standardów Usług WS determinuje, jakiego rodzaju usługi będą musiały być użyte. Co do zasady, dyspozycje są kierowane do systemu centralnego lub innego systemu np. dostarczającego dane.

8.16. Zapis OPZ - zarzut dot. zakresu Usług serwisowych wobec „innych Produktów”.

Zdaniem Zamawiającego zarzut ten jest o tyle niezrozumiały, iż IPU zawiera definicję produktu, więc wskazane określenie nie powinno budzić wątpliwości interpretacyjnych. Opisane w OPZ lub Dokumentacji, każde świadczenie wykonawcy, stanowiące przedmiot odbioru. Produktem jest w szczególności: Plan Wdrożenia, Specyfikacja Funkcjonalna, Projekt Techniczny, element Systemu H2H lub cały System H2H uruchomiony produkcyjnie, uruchomione rozszerzenia funkcjonalne Oprogramowania, wsparcie, szkolenia, Dokumentacja, Oprogramowanie Podstawowe, Oprogramowanie Pomocnicze oraz wsparcie uruchomieniowe, wdrożeniowe i szkolenia, Infrastruktura IT dostarczana przez wykonawcę. Ponadto, w zamieszczonej w pkt „14 Organizacja projektu” tabeli Zamawiający wskazał zakres prac objętych danym etap[em projektu oraz produkty, które będą podlegać odbiorowi oraz kryteria ich odbiorów.

8.17. Zapis OPZ - zarzut dot. dostosowania Systemu H2H do współpracy z nowymi wersjami Oprogramowania Pomocniczego.

Zamawiający wyjaśniał, że wdrażany system ma charakter „krytyczny” oznacza to, że dla Zamawiającego ma on szczególne znaczenie i zapewnienie ciągłości jego eksploatacja wymaga szczególnej staranności. Postanowienia dotyczące konieczności stosowania w ramach zamawianego systemu takich rozwiązań, dla których wymagane jest wsparcie jest standardem rynkowym. Zamawiający oczekuje takiego rozwiązania, które będzie zbudowane z elementów, które mają wsparcie ich dostawców/producentów. Informacje zakończeniu wsparcia lub wycofaniu produktów są udostępniane lub publikowane przez najważniejszy producentów (i wykonawca może też zagwarantować takie w sowich kontraktach z takimi dostawcami). Okres wsparcia producenta/dostawcy jest często również elementem udzielanej licencji na dany produkt. Pod uwagę zasługuje również fakt, iż okres obowiązywania umowy serwisowej wynosi 36 tylko miesięcy dysponując np. ww. informacjami (nie mówiąc już o informacjach od dostawców/producentów) – jak pokazują przykłady informacje te są dostępne nawet 5 lat przed wycofaniem wsparcia. Nie jest spotykane, aby produkty renomowanych dostawców traciły wsparcie bez wcześniejszego poinformowania użytkowników. Wykonawca jest w stanie stwierdzić, kiedy rozwiązanie, które planuje wykorzystać utraci wsparcie i albo zastosować inne rozwiązanie od samego początku albo dokonać dostosowania w okresie obwiązywania umowy i odpowiednio z wyporządnieniem zaplanować takie prace.

8.18 Zarzut dot. postanowienia:

Zamawiający stwierdził, że oczekuje rozwiązania, które będzie funkcjonowało bez zakłóceń i będzie rozwijane. W celu uniknięcia wątpliwości Zamawiający oczekuje, iż np., jeżeli wykonawca zmodyfikuje Oprogramowanie (np. w wyniku zamówionych zmian czy wdrożonych poprawek) to ma zapewnić, aby obsługa dotychczasowych klientów przybiegała bez zakłóceń.

8.19 Zapis OPZ - zarzut dot.

Wymagania Zamawiającego są precyzyjne i dotyczą różnych zamówień:

1. Rozdział 21 pkt 14 - w ramach zamówienia podstawowego w ramach miesięcznego wynagrodzenia ryczałtowego za serwis zamawiający oczekuje zaoferowanej puli osobodni pracy personelu do wykorzystania na realizację usług rozwoju lub przekazania wiedzy. Jeżeli pula na dany okres nie zostanie wykorzystana przechodzi na okres następny – skoro Zamawiający zapłacił za te usługi a ich nie wykorzystał to powinien móc je wykorzystać w terminie późniejszym. Zamawiający nie widzi żadnego uzasadnienia, aby miał tracić prawo do czegoś, za co już zapłacił.

2. Rozdział 22 pkt. 2 prawo zamówienia Usług Rozwoju w wymiarze do 1000 osobodni pracy personelu wykonawcy dotyczy zamówienia opcjonalnego, które nie jest powiązane z zakupem podstawowym pewnej puli takich usług w ramach zamówienia podstawowego.

8.20 Zapis OPZ - zarzut dot. pomniejszenia czasochłonności

Zamawiający stwierdził, że zarzut jest niezasadny. Ustalenie puli dostępnych 1000 osobodni wynika przede wszystkim z konieczności określenia wartości umowy i dlatego jej rozliczenie (pomniejszenie) jest powiązane z odbiorem wykonania usługi, a wiec płatnością. Oczywiście Zamawiający nie może przekroczyć wartości umowy i dokonując kolejnych zamówień musi uwzględnić to, co jest zamówione i jest w trakcie realizacji. Może wystąpić sytuacja, że mimo zamówienia nie zostanie ono zrealizowane a wiec nie powstanie obowiązek zapłaty wynagrodzenia i w konsekwencji takie zamówienie nie pomniejsza dostępnej puli. Możliwy jest też przypadek, że po zleceniu zamówienia strony ustalają inny sposób realizacji, który może mieć inną wycenę w związku z tym gdyby pula była pomniejszona już przed realizacją Zamówienia nie można byłoby jej właściwie wyliczyć w przypadku kolejnego zamówienia (w szczególności np. zamówienie nr 1 wycenione na 100 osobodni, strony ustalają, ze nie będą realizowali zamówienia nr 1 i ustalają zamówienie nr 2 wycenione na 50 dni. Gdyby czasochłonność pomniejszała pulę przed realizacją zamówienia to należałoby odjąć od puli 150 dni a nie 50, które zostały faktycznie zrealizowane.

8.21. Zapis OPZ - zarzut dot.

Zamawiający stwierdził, że zarzut został już podniesiony w pkt 8.1, gdzie szerzej odniesiono się do przedmiotowego zagadnienia. Wskazany zarzut jest nieuzasadniony. Możliwości liczenia czas naprawy liczony od momentu zgłoszenia nie budzi jakichkolwiek zastrzeżeń prawnych, nawiasem mówiąc jest standardem rynkowym w umowach z obszaru IT. Stawiany zarzut w zakresie obawy braku stosownych informacji w zgłoszeniu nie znajduje oparcia w treści IPU - zgłoszenie określa dane możliwe do określenia przez Zamawiającego, co oznacza, iż Zamawiający w zgłoszeniu ma obowiązek podania wszelkich posiadanych informacji dotyczących ujawnionego błędu. W przypadku nieprawidłowego działania systemu teleinformatycznego, do którego zdalny dostęp ma wykonawca nie ulega wątpliwości, że jest on w stanie niezwłocznie po zgłoszeniu identyfikacji problemu i podjęcia działań celem jego usunięcia.

8.22 Zapis OPZ - zarzut dot.

Zamawiający podał, że pomoc zgodnie ze znaczeniem określonym w słowniku języka polskiego to min. "działanie podjęte dla dobra innej osoby”, „coś, co pomaga w trudnej sytuacji, czyni ją mniej uciążliwą”. Wymaganie pomocy w analizie i rozwiazywaniu jest klauzulą dobrego współdziałania, która stanowi podstawę formalną do prowadzenia wspólnie takich prac w razie potrzeby i np. przekazania informacji i stanowi raczej wymaganie jakościowe. Z powyższego wynika, że o zakresie udzielonej pomocy decyduje wykonawca uwzględniając posiadane kompetencje, zasoby i szczegółowe uwarunkowania danego problemu oraz własne możliwości w zakresie udzielenia pomocy. W ocenie Zamawiającego wykonawca, jako profesjonalista, który ma doświadczenie we wdrożeniach systemów H2H powinien być w stanie oszacować i wycenić zakres prac, które może zaoferować w ramach takiej pomocy.

9. Zarzut dot. braku opisu przedmiotu zamówienia poprzez odesłanie w celu określenia zakresu zobowiązań wykonawcy do etapu „analizy przedwdrożeniowej”.

Wskazany zarzut, w ocenie Zamawiającego jest bezzasadny. Zamawiający poinformował, że dochował najwyższej staranności, aby przedmiot zamówienia sformułowany został w sposób wyczerpujący wszystkie wskazania określone w art. 29 Pzp. Dodatkowo należy wskazać, że przepis art. 29 ust. 1 Pzp nakazujący sporządzenie opisu przedmiotu zamówienia w sposób wyczerpujący i jednoznaczny, nie wymaga, aby każdy element przedmiotu zamówienia musiał mieć charakter zamknięty. Z przyczyn obiektywnych nie jest możliwe zdefiniowanie każdego pojęcia w sposób ściśle dookreślony. Zamawiający określił przedmiot umowy oraz wymagania w sposób precyzyjny, zastrzegając jedynie, iż szczegółowe określenie niektórych wymagań zostanie dokonane na etapie Analizy przedwdrożeniowej także w zależności od możliwości i funkcjonalności proponowanego przez wykonawcę rozwiązania. Model taki jest na gruncie ustawy Pzp dopuszczalny, ponieważ Zamawiający nigdy na etapie badania ofert nie uzyskuje pełnej wiedzy o oferowanym produkcie, w szczególności funkcjonalności i możliwościach konkretnego produktu teleinformatycznego. Wykonanie Analizy przedwdrożeniowej ma na celu uszczegółowienie przedmiotu umowy i opisanie sposobu jej realizacji. W trakcie prac mających na celu stworzenie analizy, Wykonawca, działając zgodnie z najlepszą wiedzą, powinien zweryfikować i przedstawić Zamawiającemu optymalne działania zmierzające do zapewnienia wykonania umowy i osiągnięcia jej celów. W szczególności wykonawca może zaproponować modyfikację wymagań Zamawiającego dotyczących oprogramowania, które nie mają uzasadnienia funkcjonalnego lub informatycznego. Zamawiający podkreślał, iż w projektach teleinformatycznych wyodrębnienie etapu analizy przedwdrożeniowej jest powszechnie stosowanym standardem.

9.1. Wysokopoziomowe wymagania biznesowe (WB).

Szersze uzasadnienie w odpowiedz na zarzut nr 9. Dodatkowo Zamawiający zwracał uwagę, że model jest dopuszczalny, ponieważ Zamawiający nigdy na etapie badania ofert nie uzyskuje pełnej wiedzy o oferowanym produkcie, w szczególności funkcjonalności i możliwościach konkretnego produktu teleinformatycznego.

9.2. Interfejs użytkownika (WB.006).

W ocenie Zamawiającego wymagania zostały precyzyjnie określone w przytoczonym wymaganiu WB.006 Zamawiający stwierdził, iż wskazał zakres oczekiwanych funkcjonalności z informacją, że szczegóły implementacji, wynikające ze specyfiki oferowanego rozwiązania, będą ustalane i doprecyzowane na etapie analizy - zgodnie ze stosowaną na rynku praktyką wdrożeniową systemów informatycznych. Zamawiający wyjaśnił, iż nie zna szczegółów rozwiązań, które mogą zaproponować wykonawcy w związku z tym doprecyzował wymagania na takim poziomi, które powinno zagwarantować realizację oczekiwanych funkcjonalności a szczegóły będą zależały od konkretnych rozwiązań, które posiada/zaproponuje wykonawca.

9.3. WB.012 API dla systemów zewnętrznych.

Uzasadnienie zgodne z odpowiedzią na zarzut nr 9.

9.4. PU.012 Uwierzytelnienie Klienta w portalu do zarządzania certyfikatami.

Uzasadnienie zgodne z odpowiedzią na zarzut nr 9.

9.5 Strona 43 OPZ:

Uzasadnienie zgodne z odpowiedzią na zarzut nr 9. Zamawiający zaznaczał, że w tym przypadku wymienił enumeratywnie, jakie funkcjonalności ma realizować system i jakie dyspozycje obsługiwać. Wymagania, co do formatów i struktury komunikatów usług WS określają przywołane OPZ specyfikacje (np. ZBP) w powstałym zakresie szczegóły rozwiązania mogą wynikać z zaoferowanego przez dostawcę rozwiązania.

9.6. Zapis OPZ - zarzut dot. wymagania PU.011.

Uzasadnienie zgodne z odpowiedzią na zarzut nr 9.

9.7. Autoryzacja dyspozycji Klienta.

Uzasadnienie zgodne z odpowiedzią na zarzut nr 9.

9.8. PU.006.

Uzasadnienie zgodne z odpowiedzią na zarzut nr 9.

9.9 WI.001, WI.002.

Uzasadnienie zgodne z odpowiedzią na zarzut nr 9.

9.10. Przygotowanie projektu technicznego i graficznego.

Uzasadnienie zgodne z odpowiedzią na zarzut nr 9.

9.11. Dostarczenie systemu H2H i Testy Odbiorcze.

Zamawiający podnosił, że zgodnie z najlepszymi praktykami scenariusze testowe są pochodne w stosunku do przygotowanej specyfikacji i powinny służyć weryfikacji określonych w niej wymagań i muszą być dopasowane do konkretnego rozwiązania. Dopiero na tej podstawie można opracować precyzyjną listę scenariuszy testowych. W ocenie Zamawiającego wykonawca, jako profesjonalista, który ma doświadczenie we wdrożeniach systemów H2H powinien być w stanie oszacować i wycenić niezbędny zakres prac dla wyspecyfikowanego w OPZ zakresu funkcjonalnego. Kryterium odbioru końcowego systemu H2H jednoznacznie stanowi, iż muszą być usunięte wszystkie wady, które zostały zgłoszone do zakończenia okresu stabilizacji. Co do zasady system zgłaszany do wdrożenia produkcyjnego nie powinien mieć żadnych wad.

Zamawiający wyjaśniał, że ponieważ nie jest możliwe przewidzenie wszystkich wad, które mogą wystąpić i w jakim zakresie mogą one wpływać na działanie systemu - Zamawiający zgodnie z przyjętymi praktykami - dopuszcza możliwość uruchomienia produkcyjnego systemu H2H o ile stwierdzone ewentualnie wady dla każdego testowanego obszaru (funkcjonalność, bezpieczeństwo, wydajność, integracja) nie będą uniemożliwiały wdrożenia produkcyjne. Decyzja czy wada uniemożliwia wdrożenie produkcyjne może być podjęta dopiero po analizie konkretnej wady i ewentualnych konsekwencji związanych z jej występowaniem.

Zamawiający wskazywał, że Testy Odbiorcze – przygotowuje i przeprowadza Zamawiający. Wsparcie dostawcy jest powszechnie stosowanym pojęciem na rynku usług IT. W IPU i OPZ wsparcie zostało zdefiniowane w ramach Usług Asysty Technicznej. Przytoczone wymaganie oznacza, że usługi wsparcia zdefiniowane w ramach Asysty Technicznej mają dotyczyć nie tylko eksploatacji/działania systemu H2H, ale dotyczą również zadań związanych z przygotowaniem i realizacją Testów Odbiorczych przez Zamawiającego lub podmioty trzecie, którym zlecił on ich przeprowadzenie.

9.12. Uruchomienie produkcyjne i stabilizacja systemu H2H.

Uzasadnienie zgodne z odpowiedzią na zarzut nr 9. Ponadto - zarzut dotyczący nieprecyzyjnego określenia dotyczącego, „jakości szkoleń” ze względu na brak definicji kryteriów jakościowych.

Zamawiający stwierdził, że zarzut jest niezasadny gdyż wskazany fragment precyzyjnie określa, iż chodzi o spełnienie wymogów ilościowych i jakościowych określonych w umowie. §2 ust. 6 -10 umowy precyzyjnie określa wskazane kryteria wskazując, iż kryterium jakości oceniane będzie na podstawie wyników ankiety przeprowadzonej wśród uczestników szkolenia. Co istotne umowa wskazuje, iż treść ankiety przygotowuje sam wykonawca (Zamawiającemu przysługuje jedynie prawo jej akceptacji). Zgodnie z ust. 7 „Wykonawca po przekazaniu wiedzy przeprowadzi pisemną ankietę wśród jego uczestników zawierającą ocenę warsztatów i przekaże wyniki Zamawiającemu. Otrzymanie minimum 50% ocen pozytywnych (dobrych i bardzo dobrych) z przeprowadzonej ankiety stanowić będzie podstawę odbioru przekazania wiedzy. Treść ankiety powinna zostać uzgodniona z Zamawiającym”. W ocenie Zamawiającego biorąc pod uwagę powyższe nie sposób przyjąć, iż nie określił on wystarczająco precyzyjnie kryterium jakościowego szkoleń.

9.13. Obsługa zgłoszeń serwisowych.

Uzasadnienie zgodne z odpowiedzią na zarzut nr 9.

Do postępowania odwoławczego po stronie Odwołującego skutecznie przystąpił wykonawca Sygnity S.A. z siedzibą w Warszawie (dalej „Sygnity” lub „Przystępujący”).

W toku posiedzenia z udziałem stron oraz rozprawy Odwołujący wycofał zarzuty odnoszące się do naruszenia art. 7 ust. 1, art. 29 ust. 1 i 2 oraz art. 36 ust. 1 pkt 3 Pzp wskazanych w odwołaniu w następujących punktach: 1, 8.2, 8.3, 8.4, 8.8, 8.12, 8.17, 8.19, 8.20.

Uwzględniając dokumentację postępowania o udzielenie zamówienia przedstawioną przez Zamawiającego oraz oświadczenia Stron oraz Przystępującego Izba ustaliła, co następuje.

Stan faktyczny sprawy został wyczerpująco i zgodnie z rzeczywistością przytoczony w treści odwołania oraz odpowiedzi na odwołanie (zreferowanej powyżej) i jest właściwie pomiędzy Stronami bezsporny. Strony różnią się jedynie w jego interpretacji oraz co do wniosków wyciąganych z zastanych okoliczności faktycznych, szczególnie ich ocenie prawnej.

Izba zważyła, co następuje.

Na wstępie Krajowa Izba Odwoławcza stwierdza, że Odwołujący legitymuje się uprawnieniem do korzystania ze środków ochrony prawnej, o którym stanowi przepis art. 505 ust. 1 Pzp, według którego środki ochrony prawnej określone w ustawie przysługują wykonawcy, uczestnikowi konkursu, a także innemu podmiotowi, jeżeli ma lub miał interes w uzyskaniu danego zamówienia oraz poniósł lub może ponieść szkodę w wyniku naruszenia przez Zamawiającego przepisów niniejszej ustawy.

Odwołanie w części zasługuje na uwzględnienie.

Wszechstronna analiza zarzutów podniesionych w treści odwołania doprowadziła skład orzekający Izby do przekonania, że zarzuty odwołania w części zasługują na uznanie.

Przytaczając, zgodnie z wymaganiami art. 196 ust. 4 Pzp, przepisy stanowiące podstawę prawną zapadłego rozstrzygnięcia, a których naruszenie przez Zamawiającego zarzucał Odwołujący, wskazać przede wszystkim należy, że zgodnie z art. 7 ust. 1 Pzp Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób zapewniający zachowanie uczciwej konkurencji i równe traktowanie wykonawców oraz zgodnie z zasadami proporcjonalności i przejrzystości.

Istotnym jest, że zgodnie z art. 29 ust. 1 Pzp przedmiot zamówienia opisuje się w sposób jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń, uwzględniając wszystkie wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty. Zaś według ust. 2 powyższego przepisu przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję.

Natomiast przepis art. 36 ust. 1 pkt 3 i 16 Pzp stanowi, że specyfikacja istotnych warunków zamówienia zawiera, co najmniej: opis przedmiotu zamówienia, istotne dla stron postanowienia, które zostaną wprowadzone do treści zawieranej umowy w sprawie zamówienia publicznego, ogólne warunki umowy albo wzór umowy, jeżeli zamawiający wymaga od wykonawcy, aby zawarł z nim umowę w sprawie zamówienia publicznego na takich warunkach;

Opis przedmiotu zamówienia jest jednym z ważniejszych elementów specyfikacji istotnych warunków zamówienia, który bezpośrednio rzutuje zarówno na wysokość cen ofert składanych w postępowaniu, jak i na ich zawartość. Tym samym niezwykle istotnym jest, aby został on sporządzony przez Zamawiającego w sposób prawidłowy i zgodny z przepisami wskazanymi w Pzp. Określenie wymagań dotyczących przedmiotu zamówienia jest obowiązkiem Zamawiającego, jako gospodarza postępowania. Dostrzeżenia również wymaga, że sporządzenie jednoznacznego i wyczerpującego opisu przedmiotu zamówienia w postępowaniu jest nie tylko zobowiązaniem Zamawiającego, które wynika z zacytowanych powyżej przepisów prawa, lecz leży również w interesie samego Zamawiającego, bowiem jeśli wykonawcy doskonale znają szczegóły przyszłego zamówienia, to są wówczas w stanie bardzo precyzyjnie określić cenę składanej oferty, bez zakładania zbędnych nadwyżek związanych z ponoszeniem różnego rodzaju ryzyk. Ponadto, w takim przypadku występuje znacznie mniejsze ryzyko niedoszacowania przez wykonawcę prac, które zostały ogólnikowo opisane w OPZ a w konsekwencji nienależytego wykonania umowy lub w ogóle niewykonania umowy. Biorąc pod uwagę powyżej zacytowane przepisy oraz przywołaną argumentację Izby nie budzi zatem żadnych wątpliwości, że powinnością Zamawiającego jest sporządzenie jednoznacznego i wyczerpującego opisu przedmiotu zamówienia.

I.Zarzuty uwzględnione przez Izbę.

Izba dokonując analizy zarzutów podniesionych w odwołaniu, z wyłączeniem tych, które zostały wycofane, stwierdziła naruszenie przepisów ustawy w odniesieniu następujących zarzutów podanych w punktach 2, 4, 5, 7, 8.5, 8.11, 8.22.

Izba stanęła na stanowisku, że w przeważającej części zarzutów uwzględnionych mamy do czynienia z sytuacją, w której Zamawiający nie zastosował się do normy zawartej w art. 29 ust. 1 Pzp i nie opisał przedmiotu zamówienia w sposób precyzyjny i wyczerpujący. Przejawia się to m. in. w odniesieniu do:

1.zarzutu nr 2 dotyczącego zasilania Hurtowni Danych (HD),

2.zarzutu nr 4 dotyczącego integracji z systemem centralnym Zamawiającego,

3.zarzutu nr 5 dotyczącego integracji z systemem bankowości elektronicznej BGK,

4.zarzutu nr 7 dotyczącego doprecyzowania pojęcia „systemy Zamawiającego”.

5.zarzutu nr 8.11 dotyczącego wymagań PU.006, PU.034, PU.035, PU.036, PU.045. (str. 16 i 18 OPZ),

Izba doszła do przekonania, że wobec niepełnego opisu przedmiotu zamówienia wykonawca w tym względzie nie jest w posiadaniu wszystkich informacji niezbędnych, które są potrzebne do sporządzenia rzetelnej wyceny składanej oferty. Izba nie kwestionuje potrzeby i zasadności przeprowadzenia przez Zamawiającego procesu Analizy Przedwdrożeniowej, niemniej jednak stoi na stanowisku, że w sytuacji, gdy określenie pewnych wymagań lub danych jest możliwe i dopuszczalne na etapie wcześniejszym, to Zamawiający powinien takie dane ustalić i określić a następnie zawrzeć w OPZ.

Sytuacja opisana powyżej dotyczy między innymi informacji związanych z zasilaniem Hurtowni danych, co przesądziło o tym, że Izba uznała zgłoszony zarzut za uzasadniony. Przemawia za tym argumentacja zasadzająca się na tym, iż wykonawca, aby zaprojektować dane rozwiązanie, musi być w posiadaniu niezbędnego zakresu informacji w odniesieniu do procesu, jakim jest przekazywanie informacji do Hurtowni Danych. Izba stwierdziła, że za takie informacje należy uznać te dotyczące danych, jakie będą udostępniane do Hurtowni Danych, które są istotne z punktu widzenia rzetelnej wyceny, którą musi sporządzić wykonawca i przedstawić w ofercie. Ponadto brak tego rodzaju informacji może powodować daleko idące skutki w postaci braku porównywalności ofert złożonych w postępowaniu, bowiem może okazać się, że każdy z wykonawców do ceny ofertowej przyjął inny zakres przedmiotowy.

Analogiczna argumentacja legła u podstaw uznania za zasadne zarzutów nr 4 i 5, dotyczących określenia wymagań w zakresie integracji z systemem centralnym zamawiającego (zarzut nr 4) oraz integracji z systemem bankowości elektronicznej BGK (zarzut nr 5 i 8.11). We wskazanym zakresie Izba stwierdziła, że w opisie przedmiotu zamówienia zabrakło podania przez Zamawiającego niezbędnych informacji w zakresie usług służących do integracji z systemem centralnym, które są lub będą dostępne na szynie integracyjnej, oraz wyspecyfikowania, jakie usługi służące do integracji są lub będą udostępnione przez system bankowości elektronicznej a także określenia zasad integracji z systemem bankowości elektronicznej.

Jeśli chodzi o zarzut nr 7 dotyczący doprecyzowania pojęcia „systemy Zamawiającego” to Izba stwierdziła, że Zamawiający, co prawda wymienił szereg posiadanych systemów, niemniej jednak dostrzeżenia wymaga, że wskazana lista ma charakter niepełny, ponieważ w tym zakresie Zamawiający posłużył się określeniem „w szczególności”. W związku z tym Izba uznała za konieczne nakazanie Zamawiającemu wymienienie wszystkich systemów Zamawiającego, z którymi ma się integrować budowany system H2H.

Izba odniosła się również do żądania udostępnienia Odwołującemu dokumentacji usług. Izba uznała powyższe żądanie za zbyt daleko idące z uwagi na okoliczności, na które powoływał się Zamawiający w postaci występowania w niej informacji wrażliwych z punktu widzenia Banku.

W tym miejscu zaznaczenia wymaga, że Izba uwzględniając odwołanie w zakresie opisanym powyżej przesądziła o nieprawidłowościach Zamawiającego w opisie przedmiotu zamówienia, polegającym na jego zbyt ogólnym określeniu. Niemniej jednak, z uwagi na charakter informacji, z którymi mamy do czynienia w tym przypadku, ich wrażliwość z punku widzenia Zamawiającego - co nie było kwestionowane przez Odwołującego i Przystępującego w toku rozprawy – Izba nie nakazała Zamawiającemu uzupełnienia opisu poprzez wymienienie enumeratywnie konkretnych, szczegółowych czynności, a ograniczyła się jedynie do ogólnych stwierdzeń w tym zakresie. Powyższe nie zwalania jednak Zamawiającego z poprawienia opisu przedmiotu zamówienia przez jego uszczegółowienie o informacje niezbędne wykonawcy w zakresie uwzględnionych zarzutów. Izba dostrzega pewną trudność w dokonaniu owego opisu, z uwagi na newralgiczność owych informacji. Niemniej jednak w takiej sytuacji Zamawiający powinien, opisując przedmiot zamówienia zastosować metodę „złotego środka” rozumianego jako potrzeba zachowania w poufności informacji wrażliwych z punktu widzenia Zamawiającego, i jednoczesnym zapewnieniem wykonawcom ubiegających się o udzielenie zamówienia dostępu do podstawowych informacji wykonawcom, które są konieczne w celu sporządzenia i złożenia oferty, co jak zaznaczono powyżej leży również w interesie samego Zamawiającego.

Kolejną grupą zarzutów, które Izba uznała za uzasadnione jest grupa związana koniecznością doprecyzowania przez Zamawiającego pewnych pojęć oraz rodzaju i limitu czynności wchodzących w ich skład. Dotyczy to:

zarzutu nr 8.5 odnoszącego się do czynności wsparcia w rozwiązywaniu problemów wskazanego w OPZ w rozdziale 21 w pkt 5,

zarzutu nr 8.22 dotyczącego wymagań wskazanych w rozdziale 25 „Asysta Techniczna” pkt 2 lit. a) OPZ

Po dokonaniu analizy zasadności zgłoszonych zarzutów Izba uznała, że rację mają Odwołujący oraz Przystępujący, iż Zamawiający zarówno w odniesieniu do usługi „wsparcia”, która miała być świadczona w ramach usług serwisowych, jak również w przypadku „pomocy”, która miała być podejmowana w ramach asysty technicznej, nie określił żadnego limitu tych czynności. Tym samym Izba dostrzega problematyczność wyceny przez wykonawców ubiegających się o udzielenie zamówienia wymienionych usług. Ponadto Zamawiający nie zdefiniował pojęcia „pomoc”, a także nie określił, na czym miałaby ona polegać. W związku z tym Izba stwierdziła, że w takim przypadku koniecznym jest określenie przez Zamawiającego konkretnego limitu tych czynności, który będzie wchodził w skład ryczałtu zaoferowanego przez wykonawcę w cenie ofertowej. Nadto Zamawiający powinien zdefiniować pojęcie „pomoc”, poprzez wskazanie, na czym miałaby ona polegać, tj. wyspecyfikować określone czynności mających składać się na świadczenie przez wykonawcę owej „pomocy”, z tym zastrzeżeniem, że czynności te mają być związane z przedmiotem zamówienia.

II.Kolejno Izba odniosła się do zarzutów, które podlegały oddaleniu.

Zarzut nr 3

Zgłoszony zarzut Izba uznała za nieuzasadniony. W omawianym zakresie Izba uznała za przekonywującą argumentację Zamawiającego, który w odpowiedzi na odwołanie wskazał, iż w tym zakresie wyspecyfikował dane aktywności, które następnie będą podstawą do generowania raportów, co w ocenie Izby jest informacją wystarczającą do ustalenia przez wykonawców ubiegających się o udzielenie zamówienia, którzy są profesjonalistami w swojej branży, odpowiedniej ceny. Na tej podstawie wykonawcy powinni móc ustalić katalog konfiguracji, które mogą wystąpić w ramach omawianego wymagania. Wobec tego jego realizacja zależy od zaproponowanego przez wykonawcę rozwiązania. Wobec tego stwierdzić należy, że w tym zakresie wykonawcom są znane niezbędne dane do ustalenia odpowiedniego rozwiązania a co za tym idzie, odpowiedniego poziomu cen wskazanych prac.

Zarzut nr 6

Zgłoszony zarzut Izba uznała za nieuzasadniony. Przy jego rozpoznaniu Izba uznała za trafną argumentację Zamawiającego, który stwierdził, że Odwołujący pominął postanowienia SIWZ, które nie pozostawiają wątpliwości interpretacyjnych w świetle sformułowanego zarzutu.

Zamawiający wyjaśniał, że w OPZ w rozdziale 14 jednoznacznie określił kryteria zakończenia etapu projektu: „e. Uruchomienie produkcyjne i stabilizacja Systemu H2H (Okres Stabilizacji) - zakończone Odbiorem Końcowym wdrożenia Systemu H2H”. W pkt 3 szczegółowe kryteria odbioru produktu „Produkcyjnie uruchomiony System H2H spełniający wymagania SIWZ i Umowy oraz wymagania ustalone w trakcie fazy Analizy” – są to:

1. Protokół potwierdzający usuniecie Wad zgłoszonych do zakończenia Okresu Stabilizacji

2. Pozytywny raport z Audytu bezpieczeństwa”.

Izba uznała, że trafnie zatem stwierdził Zamawiający, że powyższe oznacza, że jednoznacznym kryterium odbioru jest usunięcie wszystkich wad zgłoszonych do zakończenia Okresu Stabilizacji. Ewentualny odbiór Systemu H2H z wadami jest uprawnieniem, a nie obowiązkiem Zamawiającego. Skoro wykonawca jest w stanie oszacować, kiedy jego system będzie posiadał określoną liczbę błędów według poszczególnych kategorii, (co jak twierdzi będzie mu pozwalało oszacować czas trwania tego etapu), to tym bardziej musi być w stanie oszacować moment, kiedy będzie w stanie usunąć te wady.

Dostrzeżenia również wymaga, że Zamawiający w powoływanym przez Odwołującego pkt 5 rozdziału 19 OPZ jednoznacznie odwołał się do wad, ale tych zgłoszonych i to w kategorii Awaria, Błąd Krytyczny, Błąd lub Usterka. Tym samym nie można uznać za przekonywującą argumentacji Odwołującego, który stwierdził, że w tym przypadku należy brać uwagę wszystkie występujące w systemie wady. Ponadto trudno odmówić słuszności stanowisko Zamawiającego, który podnosił, że nieracjonalne i niecelowe jest wdrażanie systemu, który posiada wady.

Zarzut nr 8

W ramach zarzutu oznaczonego nr 8 odwołujący sformułował szereg zarzutów oznaczonych kolejnymi numerami od 8.1 do 8.22, które zostały przez Izbę omówione w kolejności wskazanej w odwołaniu z tym zastrzeżeniem, że przedstawiona poniżej argumentacja nie zawiera omówienia zarzutów wycofanych oraz tych, które zostały uwzględnione. Część zarzutów z racji ich podobieństwa została zagregowana w grupy.

8.1 i 8.21

Zgłoszone zarzuty o nr 8.1 i 8.21 Izba uznała za nieuzasadnione. Izba podziela zapatrywania Zamawiającego, iż postanowienia OPZ w tym zakresie nie pozostawiają wątpliwości interpretacyjnych i nie wymagają zmiany.

Na wstępie zauważyć należy, że Zamawiający wskazał, że świadczenie tej usługi jest niezwykle istotne z jego punktu widzenia, bowiem „System H2H będzie miał charakter systemu krytycznego, tzn. musi być zbudowany w architekturze umożliwiającej zachowanie wysokiej dostępności i odpornej na awarię (wymaganie OPZ). Wydane przez Komisję Nadzoru Finansowego w Rekomendacji D zalecenia określają co powinny zawierać umowy z dostawcami zewnętrznymi usług, w szczególności umowy powinny określać parametry dotyczące jakości świadczonych usług oraz sposoby ich monitorowania i egzekwowania, a także zasady i tryb obsługi zgłoszeń dotyczących problemów w zakresie świadczonych usług oraz zapewniać zgodność z regulacjami wewnętrznymi i zewnętrznymi oraz przyjętymi w banku standardami”.

Izba ustaliła również, że Zamawiający oczekując określonego poziomu usług serwisowych, w tym w szczególności zagwarantowanych czasów uśnięcia awarii lub zaproponowania obejścia umożliwiającego przywrócenie możliwości korzystania z funkcjonalności objętych Awarią sprecyzował w nie tylko, że „Zgłoszenie Serwisowe uznaje się za dokonane z chwilą, gdy zostało prawidłowo zarejestrowane i przekazane do Wykonawcy”, ale również, w pkt 14 rozdziału 24 OPZ, iż „Zamawiający zobowiązuje się dołożyć należnych starań w celu umożliwienia Wykonawcy świadczenia usług w zakresie usuwania Wad, a w szczególności:

a) Udostępnić niezwłocznie informacje niezbędne do diagnozy Systemu H2H lub jego części objętej Zgłoszeniem Serwisowym,

b) Zapewnić bezpośrednią obecność Administratora Systemu H2H lub osoby przez niego upoważnionej posiadającej uprawnienie do podejmowania działań niezbędnych do usunięcia Wady.”

Ponadto Izba ustaliła, że Zamawiający w OPZ w treści rozdziału 24 w pkt 3 lit b) ustalił, że: „Zgłoszenie Serwisowe polega na przekazaniu do Wykonawcy informacji o Wadzie, jej zakresie, znanych przyczynach i skutkach.”

W kontekście powyższego, powtarzając za Zamawiający, Izba uznała, że Zamawiający w tym zakresie przyjął na siebie szereg obowiązków w zakresie dokonania zgłoszenia. W tym miejscu należy również zwrócić uwagę na postanowienia OPZ w rozdziale 24 pkt 3 lit. g), treścią, których ustalono, że:

„Usługi serwisowe Systemu H2H będą świadczone w miejscu jego instalacji”,

„Zamawiający może dopuścić możliwość zdalnego diagnozowania Systemu H2H przez Wykonawcę, w tym diagnozowania zdalnego z wykorzystaniem sieci Internet w środowisku testowym niezawierającym Informacji Chronionych.”

Ponadto należy zwrócić uwagę na postanowienie o treści: „Zakres danych objętych anonimizacją oraz sposób ich przekazywania i sposób okres przechowywania przez Zamawiającego zostanie ustalony na Etapie analizy przedwdrożeniowej rozwiązania”. W odniesieniu do powołanej treści Zamawiający wyraził przekonanie, że w tym przypadku dopuszczalne będzie zastosowanie rozwiązania, które pozwoli niemal na bieżąco przekazywanie do wykonawcy ustalonych zanonimizowanych logów. W ocenie Izby przyjęcie takiego rozwiązania bez wątpienia przyczyni się do samodzielnego i szybkiego uzyskiwania przez wykonawcę informacji związanych diagnostyką występujących wad.

Izba uznała za wiarygodną i przekonywującą, a także mającą oparcie w postanowieniach OPZ argumentację Zamawiającego, który podkreślał, że „określone czasy SLA mają przed wszystkim zapewnić oczekiwany poziom dostępności systemu a nie głównie stanowić przyczynę naliczania kar, dlatego w OPZ zawarliśmy postanowienia w tym zakresie, które daleko wychodzą naprzeciwko potrzebom wykonawcy: „Jeżeli w trakcie świadczenia usług okaże się, że całkowite usunięcie Wady możliwe jest wyłącznie poprzez opracowanie poprawki do Oprogramowania o znacznym stopniu złożoności, Wykonawca może wystąpić do Zamawiającego o zgodę na:

a.Wydłużenie Czasu Naprawy,

b.Przedłużenie czasu zastosowanie Obejścia”.

Wobec powyższego Izba uznała, że możliwość liczenia czasu naprawy od momentu zgłoszenia jest uzasadniona i nie budzi zastrzeżeń ze strony Izby. Odnosząc się zaś do argumentacji Odwołującego zasadzającej się na obawie braku stosownych informacji w zgłoszeniu Izba stwierdziła, że jest nieprzekonywująca. Zaprezentowane stanowisko Izba oparła przede wszystkim na przekonaniu, że skoro świadczenie omawianych usługi jest niezwykle istotne z jego punktu widzenia Zamawiającego, bowiem zamawiany system H2H będzie miał charakter systemu krytycznego to przede właśnie Zamawiającemu będzie zależało na jak najszybszym usunięciu awarii. Zatem mało prawdopodobnym jest, aby Zamawiający w takiej sytuacji blokował jej usunięcie poprzez nieprzekazanie Odwołującemu stosownych informacji niezbędnych w celu podjęcia działań naprawczych. Co więcej, Zamawiający w treści specyfikacji jednoznacznie uregulował, że ma obowiązek podania wszelkich posiadanych informacji dotyczących ujawnionego błędu.

W kontekście powyższego Izba stwierdziła, że zgłoszony zarzut jest bezzasadny, co skutkowało jego oddaleniem.

8.6

Izba uznała, że zgłoszony zarzut podlega oddaleniu. Za przyjęciem takiego stanowiska przemawia przede wszystkim ustalenie przez Izbę, że w treści odwołania wykonawca Comarch domagał się wykreślenia z OPZ wymagań dotyczących SLA. Natomiast podczas rozprawy wykonawca ten oświadczył, że po zapoznaniu z treścią odpowiedzi na odwołanie uznaje zasadność tego wymagania wskazanego przez Zamawiającego w OPZ i modyfikuje zarzut w ten sposób, że oczekuje jedynie doprecyzowania danych w tym zakresie, tj. SLA. Tego rodzaju modyfikację zarzutu Izba uznała za nowy zarzut, którego zgłoszenie na etapie rozprawy należy uznać za niedopuszczalne.

8.7

W odniesieniu do zarzutu zgłoszonego przez Odwołującego pod nr 8.7 Izba uznała, że jest on nieuzasadniony.

Izba prezentuje pogląd, iż wykonawca ubiegający się o udzielenie zamówienia powinien znać otoczenie formalne i prawne oferowanego produktu, który powinien być zgodny z przepisami prawa, jak również innymi wymogami, które nakładają odrębne regulacje w postaci dyrektyw czy też rekomendacji.

Jeśli zaś chodzi o sformułowanie „kryteriów odbioru” to, zarówno w treści odwołania jak i na rozprawie, Odwołujący nie wskazał na jakieś szczególne wymogi Zamawiającego w tym zakresie. Natomiast Zamawiający przyznał, że nie przewiduje, jakiegoś szczególnego odbioru pod tym względem. Tym samym należy uznać za chybioną argumentację Odwołującego oraz Przystępującego, iż treść wymagania znajdująca się w punkcie 5.5.3 odwołująca się do tego, iż oferowane przez wykonawców rozwiązanie musi spełniać wymagania rekomendacji KNF oraz europejskich organów nadzoru oraz powszechnie obowiązującego w Polsce prawa, w szczególności Dyrektywy unijnej PSD2 oraz aktów do niej wykonawczych (tzw. RTS) jest problematyczna w aspekcie przyszłego odbioru przedmiotu zamówienia. Wręcz przeciwnie. Izba zwraca uwagę, że Zamawiający sprecyzował w OPZ (rozdział 14) kryteria odbioru systemu wskazując w tym zakresie na:

1.Raport z testów funkcjonalnych potwierdzający spełnienie wymagań Zamawiającego i brak Wad uniemożliwiających wdrożenie produkcyjne,

2.Raport z testów bezpieczeństwa potwierdzający spełnienie wymagań Zamawiającego i brak Wad uniemożliwiających wdrożenie produkcyjne,

3.Raport z Testów wydajnościowych potwierdzający spełnienie wymagań Zamawiającego i brak Wad uniemożliwiających wdrożenie produkcyjne,

4.Raport z testów integracyjnych potwierdzający spełnienie wymagań Zamawiającego w zakresie współpracy z innymi systemami Zamawiającego i brak Wad uniemożliwiających wdrożenie produkcyjne.

Również jednoznacznie określono kryteria odbioru końcowego i Produkcyjnie uruchomionego Systemu H2H:

1.Protokół potwierdzający usuniecie Wad zgłoszonych do zakończenia Okresu Stabilizacji,

2.Pozytywny raport z Audytu bezpieczeństwa.

Biorąc pod uwagę powyższe w ramach zgłoszonego zarzutu Izba uznała argumentację Odwołującego za chybioną, co skutkowało oddaleniem ww. zarzutu.

8.9

Izba stwierdziła, że zgłoszony zarzut należy uznać za nieuzasadniony z uwagi na to, że obecnie nie jest jeszcze rozwiązanie, które zostanie dopiero zaoferowane, a dopiero kolejno przyjęte przez Zamawiającego. Zatem w tej sytuacji trudno jest ustalić, jakie elementy będą podlegały konfiguracji i parametryzacji. Zatem Zamawiający mógł wskazać jedynie, że oczekuje rozwiązania, które umożliwi przeniesienie i konfigurację wykonanej w jednym środowisku na inne w sposób, który pozwoli na uniknięcie konieczności ponownego ręcznego wykonywania tych wszystkich czynności przez pracowników. W aspekcie powyższego stwierdzić należy, że zgłoszony zarzut jest bezzasadny i jako taki podlegał oddaleniu przez Izbę.

8.10 i 8.13 (wymaganie PU.057) i 8.15

Izba uznała zgłoszone zarzuty w pkt 8.10, 8.13 i 8.15 za takie, które podlegają oddaleniu. Izba stwierdziła, że Zamawiający wyliczył enumeratywnie wszystkie wymagane formaty, co zostało przez Zamawiającego potwierdzone w odpowiedzi na odwołanie, gdzie Zamawiający ponownie je powtórzył w pkt 8.10, 8.13 (wymaganie PU.057) oraz 8.15. Izba odstępuje od ich powielania z uwagi na to, że treść odpowiedzi na odwołanie została powyżej szczegółowo przytoczona przez Izbę w niniejszym uzasadnieniu.

8.13 (wymaganie PU.061)

Izba uznała, że zgłoszony zarzut podlega oddaleniu. Za przyjęciem takiego stanowiska przemawia przede wszystkim ustalenie przez Izbę, że w treści odwołania wykonawca Comarch domagał się wykreślenia z OPZ wymagania PU.061 ze względu na brak istniejącego rozwiązania back-end po stronie Zamawiającego. Natomiast podczas rozprawy wykonawca ten oświadczył, że modyfikuje zarzut w ten sposób, że nie domaga się usunięcia wymagania, a jedynie oczekuje doprecyzowania, w jaki sposób informacje te będą pozyskiwane. Tego rodzaju modyfikację zarzutu Izba uznała za nowy zarzut, którego zgłoszenie na etapie rozprawy należy uznać za niedopuszczalne.

8.14

Izba stanęła na stanowisku, że zarzut zawarty w pkt. 8.14 odwołania należy uznać za nieuzasadniony.

Celem przypomnienia Izba wskazuje, że w OPZ w PU.064 Zamawiający sprecyzował: „Zlecenie dyspozycji wygenerowania raportu przez system Zamawiającego – Dyspozycja informacyjna obsługiwana przez Usługę WS”. W ramach zgłoszonego zarzutu Odwołujący domagał się jedynie określenia precyzyjnej i enumeratywnej listy wszystkich raportów rezygnując z określenia przez Zamawiającego ich zawartości poprzez sporządzenie - jako załączników do SIWZ - wzorów oczekiwanych raportów.

Zamawiający w odpowiedzi na odwołanie wyjaśnił, że „istotą wskazywanych usług jest przekazanie pomiędzy systemem klienta a Zamawiającego informacji, jaki raport ma wygenerować system Zamawiającego, a następnie po jego przygotowaniu i wywołaniu kolejnej usługi przekazać ten obiekt zawierający ten raport do systemu klienta (…) Żądanie Wykonawcy możnaby porównać do oczekiwania np. producenta poczty elektronicznej, że oczekuje, że użytkownicy wskażą wszystkie rodzaje dokumentów będą przesyłali za pomocą poczty i jaka jest struktura ich treści. Dane te są wyłącznie potrzebne nadawcy i odbiorcy tych komunikatów, a nie systemowi pośredniczącemu, jakim jest System H2H”.

Wobec tego, uwzględniając powołaną powyżej treść wymagania, w rozpoznawanym zakresie Izba uznała za trafna i przekonywującą argumentację Zamawiającego, który stwierdził, iż nie oczekuje żadnej ingerencji systemu H2H w przekazywane raporty ani ich generowania przez system. Tym samym za bezzasadne Izba uznała żądanie Odwołującego do określenia precyzyjnej i enumeratywnej listy wszystkich raportów.

8.16

Po dokonaniu analizy zgłoszonego zarzutu Izba uznała, że jest on bezzasadny. Izba ustaliła, że Zamawiający w projekcie umowy zdefiniował pojęcie „Produkt”, za który uznał „opisane w OPZ lub Dokumentacji, każde świadczenie Wykonawcy, stanowiące przedmiot odbioru. Produktem jest w szczególności: Plan Wdrożenia, Specyfikacja Funkcjonalna, Projekt Techniczny, element Systemu H2H lub cały System H2H uruchomiony produkcyjnie, uruchomione rozszerzenia funkcjonalne Oprogramowania, wsparcie, szkolenia, Dokumentacja, Oprogramowanie Podstawowe, Oprogramowanie Pomocnicze oraz wsparcie uruchomieniowe, wdrożeniowe i szkolenia, Infrastruktura IT dostarczana przez Wykonawcę”.

Ponadto, w zamieszczonej w pkt „14 Organizacja projektu” w tabeli Zamawiający wskazał zakres prac objętych danym etapem projektu oraz produkty, które będą podlegać odbiorowi oraz kryteria ich odbiorów.

W kontekście powyższego Izba stwierdziła, że w kwestionowanym postanowieniu OPZ odwołującym się do stwierdzenia „inne Produkty” mamy do czynienia z elementami, które zostały wymienione w ramach definicji produktu, co zostało również potwierdzone przez Zamawiającego w odpowiedzi na odwołanie.

8.18

Izba oddaliła zgłoszony uznając, że nie został on wykazany przez wykonawcę Comarch.

Odwołujący wskazywał, że Zamawiający w treści OPZ podał, że „W szczególności Wykonawca musi zapewnić jednoczesność wprowadzenia niezbędnych zmian u klientów w sposób automatyczny lub z pełnym wsparciem dla klientów” Powyższe dotyczyło zobowiązania wykonawcy do zapewnienia ciągłości dostępu i przetwarzania danych w każdej kolejnej nowej i ulepszonej wersji Oprogramowania poprzez dostosowanie lub opracowanie funkcji eksportu/importu Oprogramowania lub dostawy innych specjalizowanych do tego celu narzędzi lub przygotowania przeprowadzenia migracji baz danych.

Wykonawca Comarch w uzasadnieniu odwołania ograniczył się jedynie do stwierdzenia, że „nie jest w stanie spełnić powyższego wymagania, zarówno wobec wymagania „niezwłoczności". Zakres prac dostosowawczych na chwilę złożenia oferty jest nieznany i niemożliwy do przewidzenia”. Natomiast w toku rozprawy Odwołujący stwierdził, że Zamawiający oczekuje jednoczesności wprowadzenia niezbędnych zmian w sposób automatyczny, co w jego ocenie jest wymaganiem bardzo wyśrubowanym, a wręcz niemożliwym do spełnienia.

Natomiast Zamawiający wyjaśnił, że oczekuje rozwiązania, które będzie funkcjonowało bez zakłóceń i będzie rozwijane: „W celu uniknięcia wątpliwości Zamawiający oczekuje, iż np. jeżeli Wykonawca zmodyfikuje Oprogramowanie (np. w wyniku zamówionych zmian czy wdrożonych poprawek) to ma zapewnić, aby obsługa dotychczasowych klientów przybiegała bez zakłóceń”.

Izba stanęła na stanowisku, że wymaganie Zamawiającego opisane powyżej jest w pełni uzasadnione. Natomiast Odwołujący nie wykazał, iż niemożliwe lub bardzo utrudnione jest dokonanie czynności wskazanych w zgłoszonym zarzucie, podczas, gdy ciężar dowodu zgodnie z art. 6 k.c. spoczywał w tym zakresie właśnie na Odwołującym, jako na tym, który wywodzi z tego faktu skutki prawne. Skutkiem przyjęcia przez Izbę takiego zapatrywania jest konieczność oddalenia ww. zarzutu.

Zarzuty zawarte w pkt 9 odwołania.

Jeśli chodzi o grupę zarzutów wskazanych w pkt. 9 odwołania to strony były zgodne, co do tego, że zostały one w zasadzie oparte o wymaganie Odwołującego zasadzające się na wykreśleniu z konkretnych postanowień OPZ sformułowań odnoszących się do tego, że pewne uzgodnienia lub też uszczegółowienia zostaną dokonane na etapie analizy przedwdrożeniowej.

W tym miejscu Izba wskazuje, że w tym zakresie aktualna pozostaje argumentacja Izby zaprezentowana wcześniej w zakresie możliwości oraz zasadności przeprowadzenia przez Zamawiającego analizy przedwdrożeniowej, która bez wątpienia może się przyczynić do uzyskania realnych korzyści w postaci skrócenia czasy realizacji projektu oraz usprawnienia komunikacji pomiędzy stronami na dalszym etapie współpracy.

Odwołujący w treści odwołania wskazał, że uzasadnia powyższy zarzut z pkt 9 - łącznie. W jego ocenie wszystkie wymienione postanowienia OPZ nie precyzują wymagań, co do przedmiotu zamówienia zgodnie z Pzp, w wyniku, czego na dzień składania ofert zakres tych zobowiązań jest nieznany. Zamawiający postanowił bowiem o ich określeniu dopiero po zawarciu umowy, na etapie analizy przedwdrożeniowej. W związku z powyższym na etapie ofertowania wykonawca nie jest w stanie podjąć z SIWZ wiedzy ani określić/oszacować zakresu prac, które musi wycenić w ofercie.

Ponadto Odwołujący podał, że dla wszystkich wymienionych w pkt 9 zapisów żąda zobowiązania Zamawiającego do określenia precyzyjnego wszystkich wymagań OPZ, co, do których zdecydował o ich dookreślenie na etapie Analizy przedwdrożeniowej - już w treści samej specyfikacji, by była dostępna wykonawcom przed złożeniem oferty.

Izba uznała zarzuty zgłoszone w pkt od 9.1 do 9.13 za niewykazane. Na wstępie dostrzeżenia wymaga, że w treści odwołania w zakresie zgłoszonych zarzutów Odwołujący w pkt 9 przedstawił jedynie krótkie kilkuzdaniowe i ogólne uzasadnienie wspólne dla wszystkich zarzutów. Natomiast w poszczególnych podpunktach od 9.1 do 9.13 ograniczył się w zasadzie jedynie do zacytowania postanowień OPZ i dwuzdaniowego żądania mniej więcej na kształt „usuniecie zapisu „Szczegóły zostaną uzgodnione na etapie analizy przedwdrożeniowej rozwiązania”. Określenie precyzyjnych wymagań”. W treści żądania ani też na rozprawie w tym zakresie Odwołujący w przeważającej części w treści zarzutów nie skonkretyzował konkretnych braków OPZ i nie doprecyzował, jakie wymagania lub też parametry powinny być dookreślone przez Zamawiającego. Odwołujący poprzestał jedynie na stwierdzeniu, że Zamawiający może i powinien doprecyzować swoje wymagania już teraz a nie dopiero na etapie analizy przedwdrożeniowej. Jedynie w treści zarzutów z pkt 9.8 oraz 9.11 Odwołujący pokusił się o szerszą treść w tym zakresie.

Izba stanęła na stanowisku, że Odwołujący w omawianym zakresie tj. zarzutów z punktu 9 odwołania nie wykazał, że opis przedmiotu zamówienia nie pozwala mu na złożenie ważnej oferty, podczas, gdy ciężar dowodu obciążał Odwołującego.

W tym zakresie należy odwołać się do treści art. 534 ust. 1 NPzp strony i uczestnicy postępowania odwoławczego są obowiązani wskazywać dowody dla stwierdzenia faktów, z których wywodzą skutki prawne. Natomiast przepis art. art. 535 NPzp stanowi, że dowody na poparcie swoich twierdzeń lub odparcie twierdzeń strony przeciwnej, strony i uczestnicy postępowania odwoławczego mogą przedstawiać aż do zamknięcia rozprawy.

Powołane przepisy nakładają na strony postępowania obowiązek, który zarazem jest uprawnieniem stron, wykazywania dowodów na stwierdzenie faktów, z których wywodzą skutki prawne. Postępowanie przez Izbą stanowi postępowanie kontradyktoryjne, czyli sporne a z istoty tego postępowania wynika, iż spór toczą strony postępowania i to one mają obowiązek wykazywania dowodów, z których wywodzą określone skutki prawne. Powołując w tym miejscu regulację art. 8 ust. 1 NPzp ustawy do czynności podejmowanych przez zamawiającego, wykonawców oraz uczestników konkursu w postępowaniu o udzielenie zamówienia i konkursie oraz do umów w sprawach zamówień publicznych stosuje się przepisy ustawy z dnia 23 kwietnia 1964 r. – Kodeks cywilny (Dz. U. z 2019 r. poz. 1145 i 1495), jeżeli przepisy ustawy nie stanowią inaczej. Przechodząc do art. 6 Kodeksu cywilnego ciężar udowodnienia faktu spoczywa na osobie, która z faktu tego wywodzi skutki prawne, należy wskazać, iż właśnie z tej zasady wynika reguła art. 534 ust 1 NPzp. Przepis art. 6 Kodeksu cywilnego wyraża dwie ogólne reguły, a mianowicie wymaganie udowodnienia powoływanego przez stronę faktu, powodującego powstanie określonych skutków prawnych oraz usytuowanie ciężaru dowodu danego faktu po stronie osoby, która z faktu tego wywodzi skutki prawne;
‎ei incubit probatio qui dicit non qui negat (na tym ciąży dowód kto twierdzi a nie na tym kto zaprzecza).

Zgodnie z art. 557 NPzp, w wyroku oraz w postanowieniu kończącym postępowanie odwoławcze Izba rozstrzyga o kosztach postępowania odwoławczego. Z kolei w świetle art. 575 NPzp strony oraz uczestnik postępowania odwoławczego wnoszący sprzeciw ponoszą koszty postępowania odwoławczego stosownie do jego wyniku.

Jak wskazuje się w piśmiennictwie, reguła ponoszenia przez strony kosztów postępowania odwoławczego stosownie do wyników postępowania odwoławczego oznacza, że „obowiązuje w nim, analogicznie do procesu cywilnego, zasada odpowiedzialności za wynik procesu, według której koszty postępowania obciążają ostatecznie stronę „przegrywającą” sprawę (por. art. 98 § 1 k.p.c.)” Jarosław Jerzykowski, Komentarz do art.192 ustawy - Prawo zamówień publicznych, w: Dzierżanowski W., Jerzykowski J., Stachowiak M. Prawo zamówień publicznych. Komentarz, LEX, 2014, wydanie VI.

W związku z tym Izba kosztami postepowania odwoławczego w sprawie o sygn. akt KIO 69/21 zgodnie z art. 575 NPzp oraz § 2 ust. 1 pkt 2 w zw. z § 5 ust. 2 lit. b oraz § 7 ust. 2 pkt 1 rozporządzenia Prezesa Rady Ministrów z dnia 30 grudnia 2020 r. w sprawie szczegółowych rodzajów kosztów postępowania odwoławczego, ich rozliczania oraz wysokości i sposobu pobierania wpisu od odwołania (Dz. U. z 2020 r. poz. 2437). W rozpoznawanej sprawie Izba ustaliła koszty postępowania odwoławczego na kwotę 18.600 zł. Do kosztów postępowania odwoławczego Izba zaliczyła wpis uiszczony przez Odwołującego w kwocie 15.000 zł oraz koszty poniesione przez Odwołującego w zakresie wynagrodzenia pełnomocnika. Izba ustaliła, że Odwołujący w złożonym Odwołaniu zgłosił 43 zarzuty, z których 9 zostało wycofany, co po ich odjęciu od wartości wszystkich zarzutów daje wynik 34 zarzutów, które zostały merytorycznie rozpoznane przez Izbę. Izba uwzględniła 7 zarzutów natomiast pozostałe 27 z nich podlegało oddaleniu. Powyższe oznacza, że Zamawiający ponosi koszt postępowania w kwocie 3.830 zł. Natomiast Odwołujący powyższe koszty ponosi w kwocie 14 770 zł.

Mając powyższe na uwadze, orzeczono jak w sentencji.

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

………………………….…

………………………….…