KIO 69/21 WYROK dnia 12 lutego 2021 r.

Sygn. akt: KIO 69/21 

WYROK 

z dnia 12 lutego 2021  r. 

K

rajowa Izba Odwoławcza   -   w składzie: 

Przewodniczący:      Ewa Kisiel 

Magdalena Grabarczyk 

Monika Kawa-

Ogorzałek 

Protokolant:   

Łukasz Listkiewicz 

po  rozpoznaniu  na  rozprawie  w  dniu  8  lutego  2021  r.  w Warszawie 

odwołania wniesionego 

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

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. 

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; 

W 

pozostałym zakresie oddala odwołanie.

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:

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, 

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:  

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; 

sformułowanie postanowień SIWZ w zakresie Załącznika do SIWZ - Wzór Umowy, w 

sposób  utrudniający  uczciwą  konkurencję  i  niezapewniający  równego  traktowania 

wykonawców,  niejednoznaczny  i  obarczony  wadą  w  postaci  niezgodności 

postanowień  umownych  z  przepisami  prawa  i  zasadami  współżycia  społecznego  - 

czym naruszył art. 7 ust. 1, art. 29 ust. 1 i 2, art. 36 ust. 1 pkt 3 i 16 Pzp w zw. z art. 5, 

art. 58 § 1 i 2 oraz art. 353

  Kodeksu  cywilnego  w 

zw. z art. 139 Pzp, a także inne 

normy i zasady wskazane w uzasadnieniu odwołania. 

W związku z powyższym Odwołujący wnosił o uwzględnienie odwołania i nakazanie 

Zamawiającemu  modyfikacji treści  SIWZ  w  sposób  wskazany  szczegółowo w  uzasadnieniu 

złożonego odwołania. 

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

1.  Zarzut  nr  1  - 

Nieprecyzyjne  określenie  przedmiotu  zamówienia  w  zakresie 

Infrastruktury IT. 

Odwołujący  stwierdził,  że  nie  ma  możliwości  złożenia  oferty,  ponieważ  aby  móc 

wycenić czynności serwisowe, którym miałaby podlegać Infrastruktura IT Zamawiającego (w 

szczególności  takie  czynności  jak  aktualizacja  firmware)  wykonawca  powinien  posiadać 

wiedz

ę  o  tym,  jakie  konkretnie  elementy  tej  infrastruktury  będzie  musiał  obsługiwać. 

Przykładowo  w  celu  określenia  czy  w  ogóle  jest  możliwe  objęcie  danego  elementu 

infrastruktury aktualizacją firmware należy znać typ i nazwę urządzenia, datę jego produkcji i 

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: 

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

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. 

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

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

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

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

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

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

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

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 

Spełnienie wymagań 

określonych w SIWZ, Umowie 
oraz doprecyzowanych na 
etapie Analizy 

Koncepcja techniczna i projekt 

Systemu H2H muszą być 
dostosowane do rozwiązań 
Zamawiającego 

Projekt graficzny interfejsu 

użytkownika portalu Klienta 

Projekt graficzny interfejsu 

użytkownika portalu Pracownika 
Zamawiającego 

Spełnienie wymagań 

Zamawiającego określonych 
w SIWZ, Umowie oraz 
doprecyzowanych na etapie 
Analizy 

Uwzględnienie wymagań w 

zakresie dostosowania 
wyglądu do stosowanych 
przez Zamawiającego 
standardów wizualizacji 

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. 

Zamawiający w OPZ podał: 

e. Uruchomienie produkcyjne i stabilizacja Systemu H2H (Okres Stabilizacji) zakończone Odbiorem Końcowym wdrożenia 

Systemu H2H

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

Zainstalowanie Systemu H2H przez 

Zamawiającego na środowisku 
produkcyjnym i konfiguracja, przy 
Asyście Technicznej Wykonawcy

Uruchomienie środowiska produkcyjnego 

Systemu H2H zgodnie 

 przyjętym 

harmonogramem prac

Zdefiniowanie odpowiednich uprawnień, 

import/założenie kont użytkowników, 
udostępnienie i skonfigurowanie 
interfejsów

Rozpoczęcie i realizacja Okresu 

Stabilizacji Systemu H2H

Przekazanie przez Wykonawcę wiedzy dla 

Użytkowników Systemu H2H

Usuwanie zgłaszanych Wad

Audyt bezpieczeństwa środowiska 

produkcyjnego (realizowany na 
Zlecenie Zamawiającego)

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

Protokół potwierdzający usuniecie 

Wad zgłoszonych do zakończenia 
Okresu Stabilizacji

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. 

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: 

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.  

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.  

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.  

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.  

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.  

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.  

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 

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, 

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: 

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

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

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

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

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. 

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.  

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: 

Raport z testów funkcjonalnych potwierdzający spełnienie wymagań Zamawiającego i 

brak Wad uniemożliwiających wdrożenie produkcyjne,  

Raport z testów bezpieczeństwa potwierdzający spełnienie wymagań Zamawiającego 

i brak Wad uniemożliwiających wdrożenie produkcyjne,  

Raport  z  Testów  wydajnościowych  potwierdzający  spełnienie  wymagań 

Zamawiającego i brak Wad uniemożliwiających wdrożenie produkcyjne,  

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:  

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

Stabilizacji, 

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. 

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.  

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. 

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. 

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

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

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