rodzaj: WYROK
data dokumentu: 2021-02-12
rok: 2021
data dokumentu: 2021-02-12
rok: 2021
sygnatury akt.:
KIO 69/21
KIO 69/21
Komisja w składzie:
Przewodniczący: Ewa Kisiel, Magdalena Grabarczyk, Monika Kawa - , Ogorzałek Protokolant: Łukasz Listkiewicz
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 Pr
ezesa 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
odwołania wniesionego
do Pr
ezesa 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 z
amawiają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 z
amawiają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 s
ystem 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.
K
osztami 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.1
zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr
(słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez wykonawcę
Comarch Polska S.A. z siedzibą w Krakowie tytułem wpisu od odwołania,
4.2
zasądza od zamawiającego Banku Gospodarstwa Krajowego z siedzibą w
Warszawie na rzecz wykonawcy Comarch Po
lska S.A. z siedzibą w Krakowie
kwotę 3 830 zł (słownie: trzy tysiące osiemset trzydzieści złotych).
S
tosownie 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
1
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
nu
mer 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 Hurto
wnią 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
wykonawc
y, 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 agreg
acji 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. St
atystyki 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
syst
emem 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
Zamawia
ją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.
Zama
wiają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 przypad
ku 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
um
oż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
spo
wodowanych 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 Dokumentac
ją,
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ść:
wprow
adzenia 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 sta
nie 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
środowiskami Możliwość automatycznego przenoszenia konfiguracji 1 parametryzacji
między środowiskami”.
Żądanie: Doprecyzowanie wymagania poprzez precyzyjne wskazanie elementów
konfigurac
yjnych, 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
zakres
u 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 informa
cyjna 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.
Wykonawc
a 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
wymagany
ch 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 Bizne
sowego. 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ł:
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. 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
1.
Spełnienie wymagań
określonych w SIWZ, Umowie
oraz doprecyzowanych na
etapie Analizy
2.
Koncepcja techniczna i projekt
Systemu H2H muszą być
dostosowane do rozwiązań
Zamawiającego
3.
Projekt graficzny interfejsu
użytkownika portalu Klienta
4.
Projekt graficzny interfejsu
użytkownika portalu Pracownika
Zamawiającego
1.
Spełnienie wymagań
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ń.
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ł:
e. Uruchomienie produkcyjne i stabilizacja Systemu H2H (Okres Stabilizacji) zakończone Odbiorem Końcowym wdrożenia
Systemu H2H
1.
Przygotowanie i uzgodnienie z
Zamawiającym szczegółowego Planu
wdrożenia tj. szczegółowego
harmonogramu prac, zasobów,
informacji, narzędzi i Dokumentacji
niezbędnych do realizacji wdrożenia, w
tym szczegółów organizacji wsparcia
Wykonawcy w zakresie Asysty
Technicznej podczas wdrożenia
2.
Zainstalowanie Systemu H2H przez
Zamawiającego na środowisku
produkcyjnym i konfiguracja, przy
Asyście Technicznej Wykonawcy
3.
Uruchomienie środowiska produkcyjnego
Systemu H2H zgodnie
2
przyjętym
harmonogramem prac
4.
Zdefiniowanie odpowiednich uprawnień,
import/założenie kont użytkowników,
udostępnienie i skonfigurowanie
interfejsów
5.
Rozpoczęcie i realizacja Okresu
Stabilizacji Systemu H2H
6.
Przekazanie przez Wykonawcę wiedzy dla
Użytkowników Systemu H2H
7.
Usuwanie zgłaszanych Wad
8.
Audyt bezpieczeństwa środowiska
produkcyjnego (realizowany na
Zlecenie Zamawiającego)
9.
Dostarczenie Dokumentacji
powdrożeniowej Systemu H2H
1. Szczegółowy Plan i harmonogram działań wdrożenia i
uruchomienia produkcyjnego Systemu H2H
Kompletność zaplanowanych prac t
zgodność terminów realizacji z ofertą i
SIWZ oraz doprecyzowanych na etapie
Analizy
2. Dostarczenie dokumentów potwierdzających
udzielenie licencji lub przeniesienie praw
autorskich do Systemu H2H
Kompletność dostarczonych dokumentów,
warunki są zgodne ze SIWZ
3. Produkcyjnie uruchomiony System H2H
spełniający wymagania SIWZ i Umowy
oraz wymagania ustalone w trakcie fazy
Analizy
1.
Protokół potwierdzający usuniecie
Wad zgłoszonych do zakończenia
Okresu Stabilizacji
2.
Pozytywny raport z Audytu
bezpieczeństwa
4. Realizacja warsztatów dot. przekazania
wiedzy dla Użytkowników
Spełnienie wymagań określonych w SIWZ 1
Umowie w zakresie liczby i jakości
przeprowadzonych warsztatów
5. Dostarczenie dokumentacji po wdrożeń i
owej, w tym specyfikacji skalowalności
Systemu H2H (tj. jak Zamawiający może
samodzielnie rozbudować Infrastrukturę
IT Systemu H2H, aby uzyskać
oczekiwane, określone w S1WZ
powiększone parametry pojemności i
wydajności Systemu H2H
Kompletność dostarczonych dokumentów
Spełnienie wymagań Zamawiającego
określonych w SIWZ, Umowie oraz
doprecyzowanych na etapie Analizy
Żą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
prze
dwdroż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 anali
zy, 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. Nieprec
yzyjne 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,
infor
macje 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
St
abilizacji 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
sy
stem 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
warstw
y 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 n
ie 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
doko
nania 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
cza
s 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 doty
czyć 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 ul
ega 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
o
kreś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 p
rofesjonalista 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ż
wykorzystywan
e 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/integrac
yjnych 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
wyko
nawca, 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
n
owych 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
2
004 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
uni
emoż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
jednoz
nacznie 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 da
nych 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:
(https://www.podatki.gov.pl/vat/bezpiecznatransakcja/wykaz-podatnikow-vat/plik-plaski/).
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 opisany
ch 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.
Op
isane 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 zamies
zczonej 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/dostaw
cy 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:
Z
amawiają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 okre
s 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. pomniej
szenia 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
zast
rzeż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. bra
ku 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
us
zczegół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
zap
ewnienia 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
projekt
ach 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 o
cenie 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 przypa
dku 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
prze
dstawioną 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 konkurs
u, 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. Z
arzuty 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
poprz
ez 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
informacj
e 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 gener
owania 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
k
onfiguracji, 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ął
postanowie
nia 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 usu
nię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 oznaczone
go 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
syste
mu 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
dostawcam
i 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 zapew
niać 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
zapropon
owania 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 inf
ormacji 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 (t
zw. 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
uni
emoż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 be
zpieczeń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ć
jedyni
e, ż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
st
wierdził, 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. Produ
ktem 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
niezna
ny 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 cywilneg
o 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;
e
i 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: ………………………….…
………………………….…
………………………….…
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 z
amawiają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 z
amawiają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 s
ystem 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.
K
osztami 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.1
zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr
(słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez wykonawcę
Comarch Polska S.A. z siedzibą w Krakowie tytułem wpisu od odwołania,
4.2
zasądza od zamawiającego Banku Gospodarstwa Krajowego z siedzibą w
Warszawie na rzecz wykonawcy Comarch Po
lska S.A. z siedzibą w Krakowie
kwotę 3 830 zł (słownie: trzy tysiące osiemset trzydzieści złotych).
S
tosownie 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
1
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
nu
mer 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 Hurto
wnią 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
wykonawc
y, 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 agreg
acji 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. St
atystyki 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
syst
emem 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
Zamawia
ją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.
Zama
wiają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 przypad
ku 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
um
oż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
spo
wodowanych 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 Dokumentac
ją,
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ść:
wprow
adzenia 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 sta
nie 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
środowiskami Możliwość automatycznego przenoszenia konfiguracji 1 parametryzacji
między środowiskami”.
Żądanie: Doprecyzowanie wymagania poprzez precyzyjne wskazanie elementów
konfigurac
yjnych, 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
zakres
u 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 informa
cyjna 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.
Wykonawc
a 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
wymagany
ch 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 Bizne
sowego. 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ł:
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. 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
1.
Spełnienie wymagań
określonych w SIWZ, Umowie
oraz doprecyzowanych na
etapie Analizy
2.
Koncepcja techniczna i projekt
Systemu H2H muszą być
dostosowane do rozwiązań
Zamawiającego
3.
Projekt graficzny interfejsu
użytkownika portalu Klienta
4.
Projekt graficzny interfejsu
użytkownika portalu Pracownika
Zamawiającego
1.
Spełnienie wymagań
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ń.
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ł:
e. Uruchomienie produkcyjne i stabilizacja Systemu H2H (Okres Stabilizacji) zakończone Odbiorem Końcowym wdrożenia
Systemu H2H
1.
Przygotowanie i uzgodnienie z
Zamawiającym szczegółowego Planu
wdrożenia tj. szczegółowego
harmonogramu prac, zasobów,
informacji, narzędzi i Dokumentacji
niezbędnych do realizacji wdrożenia, w
tym szczegółów organizacji wsparcia
Wykonawcy w zakresie Asysty
Technicznej podczas wdrożenia
2.
Zainstalowanie Systemu H2H przez
Zamawiającego na środowisku
produkcyjnym i konfiguracja, przy
Asyście Technicznej Wykonawcy
3.
Uruchomienie środowiska produkcyjnego
Systemu H2H zgodnie
2
przyjętym
harmonogramem prac
4.
Zdefiniowanie odpowiednich uprawnień,
import/założenie kont użytkowników,
udostępnienie i skonfigurowanie
interfejsów
5.
Rozpoczęcie i realizacja Okresu
Stabilizacji Systemu H2H
6.
Przekazanie przez Wykonawcę wiedzy dla
Użytkowników Systemu H2H
7.
Usuwanie zgłaszanych Wad
8.
Audyt bezpieczeństwa środowiska
produkcyjnego (realizowany na
Zlecenie Zamawiającego)
9.
Dostarczenie Dokumentacji
powdrożeniowej Systemu H2H
1. Szczegółowy Plan i harmonogram działań wdrożenia i
uruchomienia produkcyjnego Systemu H2H
Kompletność zaplanowanych prac t
zgodność terminów realizacji z ofertą i
SIWZ oraz doprecyzowanych na etapie
Analizy
2. Dostarczenie dokumentów potwierdzających
udzielenie licencji lub przeniesienie praw
autorskich do Systemu H2H
Kompletność dostarczonych dokumentów,
warunki są zgodne ze SIWZ
3. Produkcyjnie uruchomiony System H2H
spełniający wymagania SIWZ i Umowy
oraz wymagania ustalone w trakcie fazy
Analizy
1.
Protokół potwierdzający usuniecie
Wad zgłoszonych do zakończenia
Okresu Stabilizacji
2.
Pozytywny raport z Audytu
bezpieczeństwa
4. Realizacja warsztatów dot. przekazania
wiedzy dla Użytkowników
Spełnienie wymagań określonych w SIWZ 1
Umowie w zakresie liczby i jakości
przeprowadzonych warsztatów
5. Dostarczenie dokumentacji po wdrożeń i
owej, w tym specyfikacji skalowalności
Systemu H2H (tj. jak Zamawiający może
samodzielnie rozbudować Infrastrukturę
IT Systemu H2H, aby uzyskać
oczekiwane, określone w S1WZ
powiększone parametry pojemności i
wydajności Systemu H2H
Kompletność dostarczonych dokumentów
Spełnienie wymagań Zamawiającego
określonych w SIWZ, Umowie oraz
doprecyzowanych na etapie Analizy
Żą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
prze
dwdroż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 anali
zy, 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. Nieprec
yzyjne 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,
infor
macje 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
St
abilizacji 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
sy
stem 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
warstw
y 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 n
ie 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
doko
nania 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
cza
s 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 doty
czyć 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 ul
ega 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
o
kreś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 p
rofesjonalista 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ż
wykorzystywan
e 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/integrac
yjnych 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
wyko
nawca, 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
n
owych 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
2
004 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
uni
emoż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
jednoz
nacznie 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 da
nych 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:
(https://www.podatki.gov.pl/vat/bezpiecznatransakcja/wykaz-podatnikow-vat/plik-plaski/).
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 opisany
ch 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.
Op
isane 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 zamies
zczonej 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/dostaw
cy 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:
Z
amawiają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 okre
s 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. pomniej
szenia 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
zast
rzeż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. bra
ku 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
us
zczegół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
zap
ewnienia 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
projekt
ach 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 o
cenie 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 przypa
dku 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
prze
dstawioną 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 konkurs
u, 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. Z
arzuty 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
poprz
ez 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
informacj
e 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 gener
owania 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
k
onfiguracji, 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ął
postanowie
nia 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 usu
nię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 oznaczone
go 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
syste
mu 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
dostawcam
i 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 zapew
niać 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
zapropon
owania 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 inf
ormacji 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 (t
zw. 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
uni
emoż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 be
zpieczeń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ć
jedyni
e, ż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
st
wierdził, 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. Produ
ktem 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
niezna
ny 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 cywilneg
o 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;
e
i 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: ………………………….…
………………………….…
………………………….…
Wcześniejsze orzeczenia:
- Sygn. akt KIO 222/21 z dnia 2021-03-05
- Sygn. akt KIO 28/21, KIO 32/21 z dnia 2021-02-26
- Sygn. akt KIO 18/21 z dnia 2021-02-19
- Sygn. akt KIO 10/21 z dnia 2021-02-16
- Sygn. akt KIO 158/21 z dnia 2021-02-15
