Wyrok KIO 69/21 z 12 lutego 2021

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ń SIW Z w zakresie Załącznika do SIW Z - 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. 3531 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.

1. 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:

1. 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.

1. 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".

1. 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:

„ W I.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.

1. 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.

1. 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.

1. 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ń.

1. 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.
2. 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.

1. 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 SIW Z - 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 SIW Z/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.

1. 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.

1. 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.

1. 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 SIW Z 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.

1. 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.

1. 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.

1. 8. Zapis OPZ - zarzut dot. wymagań biznesowych WB.009.

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

1. 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.

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

Zamawiający sprecyzował: „PU.003 - Konwersja dyspozycji składanych za pomocą Usług W S 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 W S) 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 W S (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 W S wysyłanych przez System H2H do systemów klientów zadających zapytania za pomocą Usług W S. W przypadku obsługi niektórych Usług W S (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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 18. Zapis OPZ - zarzut dot.

Zamawiający w SIW Z 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.

1. 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.

1. 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.

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

1. 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.

1. 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 SIW Z 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 „W B.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 W S 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ń.

1. 3 Zamawiający w OPZ podał: „W B.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ń.

1. 5. Strona 43 OPZ:

„PU.001 - Obsługa usług umożliwiających składanie/modyflkację/odwołanie pojedynczych Dyspozycji - Obsługa Usług W S umożliwiających realizację pojedynczych Dyspozycji realizowanych przez Usługi W S 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 W S umożliwiających w pojedynczym ich wywołaniu realizację jednej lub więcej Dyspozycji (tzw. paczek) Szczegółowa lista I budowa Usług W S 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ń.

1. 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ń.

1. 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}.
2. 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.

W I.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ń.

1. 10.

Zamawiający w OPZ sprecyzował: b. Przygotowanie projektu technicznego i projektu graficznego Wykonawca musi opracować 1 uzgodnić z Zamawiającym Projekt techniczny Systemu H2H oraz interfejsy graficzne oraz zasady nawigacji z uwzględnieniem zasad łatwości i ergonomii obsługi portali przeznaczonych dla użytkowników Systemu H2H.

1. Spełnienie wymagań określonych
2. Projekt techniczny, zawierający w szczególności: a)Pełną koncepcję i architekturę

budowy, Integracji i instalacji Oprogramowania b)Projekt integracji Systemu H2H z pozostałą infrastrukturą Zamawiającego c)Projekt rozwiązania generowania powiadomień z modułu raportowego d)Projekt rozwiązania zasilenia hurtowni danych

w SIWZ, Umowie oraz doprecyzowanych na etapie Analizy 2.Koncepcja techniczna i projekt Systemu H2H muszą być dostosowane do rozwiązań Zamawiającego

1. Projekt graficzny interfejsu użytkownika
2. Spełnienie wymagań

portalu Klienta 4.Projekt graficzny interfejsu użytkownika portalu Pracownika Zamawiającego

Zamawiającego określonych w SIWZ, Umowie oraz doprecyzowanych na etapie Analizy 2.Uwzględnienie wymagań w zakresie dostosowania wyglądu do stosowanych przez Zamawiającego standardów wizualizacji 3.Zaprojektowanie Systemu H2H z wykorzystaniem metod orientacji na

Żą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ń.

1. 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.

1. 12 Zamawiający w OPZ podał: e. Uruchomienie produkcy jne i stabilizacja Sy stemu H2H (O kres Stabilizacji) zakończone O dbiorem Końcow y m w drożenia Sy stemu H2H 1.Przy gotow anie i uzgodnienie z
2. Szczegółow y Plan i harmonogram działań w drożenia i Zamaw iający m szczegółow ego Planu uruchomienia produkcy jnego Sy stemu H2H w drożenia tj. szczegółow ego harmonogramu prac, zasobów , informacji, narzędzi i Dokumentacji niezbędny ch do realizacji w drożenia, w ty m szczegółów organizacji w sparcia Wy konaw cy w zakresie A sy sty Technicznej podczas w drożenia 2.Zainstalow anie Sy stemu H2H przez Zamaw iającego na środow isku produkcy jny m i konfiguracja, przy A sy ście Technicznej Wy konaw cy 3.Uruchomienie środow iska produkcy jnego Sy stemu H2H zgodnie 2 przy jęty m harmonogramem prac 4.Zdefiniow anie odpow iednich upraw nień, import/założenie kont uży tkow ników , udostępnienie i skonfigurow anie interfejsów

Kompletność zaplanow any ch prac t zgodność terminów realizacji z ofertą i SIWZ oraz doprecy zow any ch na etapie A nalizy

1. Rozpoczęcie i realizacja O kresu Stabilizacji
2. Dostarczenie dokumentów potw ierdzający ch udzielenie licencji lub przeniesienie praw autorskich do Sy stemu H2H

Kompletność dostarczony ch dokumentów , w arunki są zgodne ze SIWZ

1. Produkcy jnie uruchomiony Sy stem H2H spełniający w y magania SIWZ i Umow y oraz w y magania ustalone w trakcie fazy A nalizy
2. Protokół potw ierdzający usuniecie Wad zgłoszony ch do zakończenia O kresu Stabilizacji

Sy stemu H2H 6.Przekazanie przez Wy konaw cę w iedzy dla Uży tkow ników Sy stemu H2H 7.Usuw anie zgłaszany ch Wad 8.A udy t bezpieczeństw a środow iska produkcy jnego (realizow any na Zlecenie Zamaw iającego) 9.Dostarczenie Dokumentacji pow drożeniow ej Sy stemu H2H

1. Pozy ty w ny raport z A udy tu bezpieczeństw a
2. Realizacja w arsztatów dot. przekazania w iedzy dla Uży tkow ników