KIO 1878/14

Komisja w składzie:
Przewodniczący: Agnieszka Trojanowska Protokolant: Agata Dziuban

po rozpoznaniu na rozprawie w Warszawie w dniu 23 września 2014 r. odwołania
wniesionego do Prezesa Krajowej Izby Odwoławczej w dniu 12 września 2014 r. przez
wykonawcę Asseco Poland Spółka Akcyjna z siedzibą w Rzeszowie, ul. Olchowa 14 w
postępowaniu prowadzonym przez zamawiającego Bank Gospodarstwa Krajowego z
siedzibą w Warszawie, Al. Jerozolimskie 7

przy udziale wykonawcy Comarch Polska Spółka Akcyjna z siedzibą w Krakowie, Al.
Jana Pawła II 39a zgłaszającego swoje przystąpienie w sprawie sygn. akt KIO 1878/14 po
stronie zamawiającego

orzeka:
1. oddala odwołanie,
2. kosztami postępowania obciąża wykonawcę Asseco Poland Spółka Akcyjna z siedzibą
w Rzeszowie, ul. Olchowa 14 i :
2.1.zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000zł. 00 gr.
(słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez wykonawcę
Asseco Poland Spółka Akcyjna z siedzibą w Rzeszowie, ul. Olchowa 14 tytułem
wpisu od odwołania,
2.1 zasądza od wykonawcy Asseco Poland Spółka Akcyjna z siedzibą w
Rzeszowie, ul. Olchowa 14 na rzecz Banku Gospodarstwa Krajowego z
siedzibą w Warszawie, Al. Jerozolimskie 7 kwotę 3 600 zł. 00 gr (słownie : trzy
tysiące sześćset złotych zero groszy) tytułem zwrotu kosztów postępowania
odwoławczego tj. zastępstwa prawnego.

Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. - Prawo zamówień
publicznych (t.j. Dz. U. z 2013r., poz. 907 ze zm.) na niniejszy wyrok - w terminie 7 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 1878/14
Uzasadnienie
Postępowanie o udzielenie zamówienia w trybie przetargu nieograniczonego na Nową
Bankowość Elektroniczną zostało wszczęte przez zamawiającego Bank Gospodarstwa
Krajowego z siedzibą w Warszawie, Al. Jerozolimskie 7 ogłoszeniem opublikowanym w
Dzienniku Urzędowym Unii Europejskiej w dniu 3 września 2014r. za numerem 2014/S 168-
299376.
W dniu 12 września 2014r. pisemne odwołanie na treść ogłoszenia i specyfikacji istotnych
warunków zamówienia (dalej siwz) wniósł odwołujący. Odwołanie zostało podpisane przez
pełnomocnika działającego na podstawie pełnomocnictwa z dnia 10 września 2014r. i
udzielonego dwóch wiceprezesów zarządu ujawnionych w KRS i upoważnionych do łącznej
reprezentacji, zgodnie z odpisem z KRS załączonym do odwołania. Kopia odwołania została
przekazana zamawiającemu drogą elektroniczną w dniu 12 września 2014r.
Odwołujący zarzucił zamawiającemu naruszenie następujących przepisów: art. 7 ust. 1 i 3
ustawy z dnia 29 stycznia 2004r. Prawo zamówień publicznych (Dz. U. t.j. z 2013r. poz. 907
ze zm. – dalej ustawy), art. 29 ust. 1 i 2 ustawy, art. 36 ust, 1 ustawy, art. 89 ust. 1 pkt 2)
ustawy, art. 139 ust. 2 ustawy, art. 140 ustawy, art. 144 ustawy oraz art. 5, art. 58, art.
353(1), art. 387 ust. 1 Kodeksu cywilnego w związku z art. 14 i art. 139 ust. 1 ustawy oraz
innych przepisów wskazanych w uzasadnieniu odwołania. Naruszenie powyższych
przepisów może doprowadzić, zdaniem odwołującego, do naruszenia przepisu art. 93 ust. 1
pkt 7 ustawy.
Odwołujący wniósł o uwzględnienie odwołania i nakazanie zamawiającemu dokonania
modyfikacji ogłoszenia i specyfikacji istotnych warunków zamówienia (dalej siwz) w zakresie
wskazanym w niniejszym odwołaniu poprzez zmianę wskazanych zapisów w sposób
wskazany w niniejszym odwołaniu.
W przypadku uwzględnienia przez zamawiającego w całości zarzutów przedstawionych w
odwołaniu (art. 186 ust. 2 ustawy) odwołujący żądał od zamawiającego: dokonania
czynności zgodnie ze wskazanym powyżej żądaniem odwołania.
Odwołujący wskazał, że ma interes we wniesieniu niniejszego odwołania, gdyż wskazane
niżej niezgodne z prawem wymagania powodują, że odwołujący nie ma możliwości złożenia
oferty i tym samym utraci szansę na uzyskanie zamówienia. Odwołujący może zatem
ponieść szkodę w wyniku naruszenia przez zamawiającego przepisów ustawy wskazanych w
odwołaniu. Gdyby nie sprzeczność z prawem objętych odwołaniem postanowień siwz i
ogłoszenia odwołujący mógłby złożyć ofertę, uzyskać zamówienie - a następnie należycie
realizować zamówienie. Ustalenie przez zamawiającego przedmiotowej treści siwz i
ogłoszenia uniemożliwia odwołującemu udział w postępowaniu.

Ponadto - w wyniku w/w naruszeń przepisów ustawy może dojść do następczego
unieważnienia postępowania-co także naraziłoby odwołującego na poniesienie szkody.
Odwołujący uważa, że załącznik nr 1 do siwz - Opis Przedmiotu Zamówienia (dalej OPZ),
Wymagania Funkcjonalne zawiera niejednoznaczny i niewyczerpujący opis przedmiotu
zamówienia.
Zamawiający w wielu zapisach załącznika nr 1 do siwz OPZ wskazał, że wymagania
funkcjonalne dla zamawianego systemu będą określone dopiero na etapie analizy.
Jednocześnie siwz, według odwołującego, nie zawiera żadnych wytycznych, jak takie
ustalenia już po podpisaniu umowy będą dokonywane. Można tym samym odwołujący
domniemuje, że to zamawiający będzie wskazywał dopiero na etapie realizacji umowy, jaki
ma być rzeczywisty zakres przedmiotu zamówienia.
Z sytuacją taką mamy do czynienia w następujących przypadkach w pkt: W pkt 1.7 str. 4
OPZ
,
VI.B.10 str. 11 OPZ
,
VIII.2 str. 22 OPZ
,
XI.1 str. 27 OPZ
,
XI.6.18 str. 29 OPZ
,
Wymagania funkcjonalne 2.2 poz.11
,
Wymagania funkcjonalne 4.13 poz. 32
,
Wymagania
funkcjonalne 8.2 poz. 57
,
Wymagania funkcjonalne 8.3 poz. 58, Wymagania funkcjonalne
8.5 poz.60
,
Wymagania funkcjonalne 8.8 poz.63
,
Wymagania funkcjonalne 8.9 poz.64
,
Wymagania funkcjonalne 8.13 poz.68
,
Wymagania funkcjonalne 10.1 poz.77
,
Wymagania
funkcjonalne 11.2 poz.82
,
Wymagania funkcjonalne 12.10 poz.98
,
Wymagania funkcjonalne
14.1 poz. 108
,
Wymagania funkcjonalne 14.3 poz.110
,
Wymagania funkcjonalne 14.5
poz.112
,
Wymagania funkcjonalne 14.7 poz.114
,
Wymagania funkcjonalne 15.10 poz.128
,
Wymagania funkcjonalne
16.16
poz.145
,
Wymagania funkcjonalne 16.19 poz.148
,
Wymagania funkcjonalne 18.11 poz.168
,
Wymagania funkcjonalne 19.1 poz.176
,
Wymagania funkcjonalne 19.15 poz.190
,
Wymagania funkcjonalne 20.4 poz.195
,
Wymagania funkcjonalne 21.5 poz.217
,
Wymagania funkcjonalne 23.2 poz.231
,
Wymagania
funkcjonalne 23.3 poz.232
,
Wymagania funkcjonalne 23.4 poz.233
,
Wymagania
funkcjonalne 23.5 poz.234
,
Wymagania funkcjonalne 23.6 poz.235
,
Wymagania
funkcjonalne 23.13 poz.242, Wymagania funkcjonalne 23.21 poz.250, Wymagania
funkcjonalne 23.24 poz.253, Wymagania funkcjonalne 29.4 poz.318, Wymagania
funkcjonalne 29.9 poz.323, Wymagania funkcjonalne 30.5 poz.330, Wymaganie funkcjonalne
31.6 poz. 343, Wymaganie funkcjonalne 32.1 poz. 345.

Skutkiem powyższego jest, według odwołującego nieokreślenie przez zamawiającego
przedmiotu zamówienia w zakresie wymagań funkcjonalnych i pozafunkcjonalnych. Zgodnie
z przepisem art. 29 ust. 1 ustawy przedmiot zamówienia powinien być opisany w sposób
jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń.
Wobec faktu, że z siwz nie wynika ostateczny i konkretny zakres przedmiotu zamówienia, a

wynika wprost sytuacja, że zamawiający będzie ten przedmiot zamówienia określał
ostatecznie na etapie realizacji umowy - przedmiot zamówienia staje się w sposób sprzeczny
z przepisem art. 29 ust. 1 ustawy niejednoznaczny, nieostry, określony w sposób
niedokładny. Co więcej – według odwołującego można powiedzieć, że przedmiot
zamówienia został przez zamawiającego opisany w sposób otwarty. Bowiem zwrot, że
niektóre elementy przedmiotu zamówienia zostaną określone lub doszczegółowione na
etapie analizy, poprzez swoje niedookreślenie powoduje, że zamawiający może wymagać od
wykonawcy dostarczenia systemu informatycznego o dowolnej funkcjonalności, określonej
przez zamawiającego na etapie analizy.
Odwołujący wskazał przykładowo orzeczenia Krajowej Izby Odwoławczej wskazujące, że
określenie przedmiotu zamówienia w sposób pełny i jednoznaczny jest obowiązkiem
zamawiającego: wyrok z dnia 24 lutego 2012 r., sygn. KIO 302/12, wyrok KIO z 24 lutego
2012 r. KIO 318/12 oraz wyrok z dnia 10 kwietnia 2012 r., sygn. KIO 550/12, wyrok z dnia 9
września 2010 roku, KIO 1832/10.
Skutek takiego nieostrego opisania przedmiotu zamówienia jest dla odwołującego bardzo
poważny- otóż wobec faktu, że siwz nie określa w sposób zamknięty zakresu funkcjonalnego
zamawianego systemu, a tym samym nie określa w sposób ostateczny przedmiotu
zamówienia, odwołujący nie jest w stanie ani w sposób należyty sporządzić oferty, ani też nie
jest w stanie wycenić dostaw czy usług ani oszacować ryzyk związanych z realizacją
zamówienia. Powoduje to, iż przy obecnym brzmieniu siwz odwołujący w ogóle nie jest w
stanie złożyć wiążącej i profesjonalnej oferty. Wskazane postanowienia siwz naruszają
zatem także obowiązek zamawiającego uwzględnienia w opisie przedmiotu zamówienia
wszystkich wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty (art. 29
ust. 1 ustawy).
Wskazane zapisy siwz, w ocenie odwołującego, naruszają także przepis art. 353(1) Kodeksu
cywilnego w związku z art. 14 i art. 139 ust. 1 ustawy. Gdyby przyjąć za uprawniony brak
określenia przez zamawiającego przedmiotu zamówienia w sposób zamknięty,
powodowałoby to, iż przedmiot umowy nie zostałby dookreślony, pozostawałby otwarty - a
niewątpliwie przekracza to granice swobody umów, gdyż treść takiego stosunku prawnego
sprzeciwiałaby się naturze tego stosunku, ustawie oraz zasadom współżycia społecznego.
Oczywistym jest bowiem, że każda umowa powinna w sposób zamknięty i szczegółowy
określać wszystkie istotne obowiązki stron. Tymczasem umowa zawarta na podstawie
takiego siwz nie określałaby tych obowiązków. Warto w tym miejscu wskazać, że zakres
obowiązków wykonawcy to essentialia negotii umowy, a zatem bez ich określenia umowa w
ogóle nie może dojść do skutku. Należy uznać, że umowa, w której zamawiający celowo nie
określa w sposób należyty essentialia negotii, powinna zostać uznana za umowę zarówno
sprzeczną z ustawą, jak i taką, której celem jest obejście prawa (obowiązku pełnego i

należytego opisania przedmiotu zamówienia). Tym samym umowa taka zgodnie z art. 58 § 1
Kodeksu Cywilnego, według odwołującego, jest nieważna z mocy prawa. Byłby to skutek dla
zamawiającego bardzo poważny.
Ograniczenie zupełnej swobody zamawiającego w korzystaniu ze swobody umów uznała
także za słuszne Krajowa Izba Odwoławcza w wyroku z dnia 27 grudnia 2011 roku, KIO
2649/11. Z wywodu Krajowej Izby Odwoławczej wynika, że zamawiający w swoich
uprawnieniach i uznaniowości jest jednak ograniczony, w szczególności nie jest uprawniony
do takiego kształtowania treści stosunku prawnego, który byłby korzystny tylko dla
zamawiającego i nakładał nieuzasadnione obowiązki na wykonawcę. Odwołujący uznał, że
stworzenie umowy z otwartym zakresem przedmiotu zamówienia czy też z otwartym
zakresem obowiązków wykonawcy jest właśnie takim nadużyciem. A zatem sprzeczne jest
zarówno z art. 5, jak i art. 58 § 2 Kodeksu Cywilnego. Ustawodawca uznał bowiem za
nadużycie prawa (nie korzystające z ochrony) czynienie użytku ze swego uprawnienia, który
to użytek byłby sprzeczny z zasadami współżycia społecznego czy też ze społeczno-
gospodarczym przeznaczeniem takiego uprawnienia. Z kolei w art. 58 § 2 Kodeksu
Cywilnego wskazano wprost, że umowa sprzeczna z zasadami współżycia społecznego jest
nieważna. Zdaniem odwołującego umowa, w której zakres obowiązków wykonawcy jest
otwarty i nieokreślony, z całą pewnością jest sprzeczna z zasadami współżycia społecznego.
Ponadto wynikający z przedmiotowych zapisów siwz zakres zobowiązania wykonawcy (tj.
zakres otwarty) powoduje, że naruszona zostaje także zasada ekwiwalentności świadczeń
stron wynikających z umowy wzajemnej wyrażona w art. 487 § 2 kodeksu cywilnego. Trudno
według odwołującego mówić o ekwiwalentności świadczeń w sytuacji, w której wykonawca
kalkulując cenę swojej oferty nie jest w stanie odnieść jej do dającego się przewidzieć
zakresu przedmiotu zamówienia. Sprzeczność przyjętego przez zamawiającego w
przedmiotowym postępowaniu sposobu określenia/opisu przedmiotu zamówienia z
przepisami ustawy oraz Kodeksu cywilnego znajduje potwierdzenie w orzecznictwie Krajowej
Izby Odwoławczej (wyrok z dnia 2 marca 2010 r. sygn. akt KIO/UZP 184/10 oraz wyrok z
dnia 14 lipca 2009 r. sygn. akt KIO/UZP 812/09, KIO/UZP 833/09). Także brak takiej
ekwiwalentności oraz ścisłego określenia zakresu obowiązków wykonawcy stanowi
naruszenie art. 5 KC (w związku z art. 14 i art. 139 ustawy).
Zdaniem odwołującego działanie zamawiającego mające na celu stworzenie otwartego
zakresu obowiązków wykonawcy może stać w sprzeczności także z zasadą dokonywania
wydatków publicznych wyrażoną w art. 44 ust. 3 ustawy z dnia 27 sierpnia 2009 r. o
finansach publicznych (tekst jednolity Dz.U. 2013r., poz. 885) (dalej „UoFB"). Wydatki
publiczne powinny być dokonywane w sposób celowy i oszczędny, z zachowaniem zasady
uzyskiwania najlepszych efektów z danych nakładów oraz doboru optymalnych środków.
Zamawiający może co prawda starać się przerzucić całe ryzyko realizacji danego

zamówienia na wykonawców - ale musi się liczyć z tym, że takie dodatkowe ryzyka (w tym
przypadku związane z nieokreślonym zakresem świadczenia wykonawcy) wpłyną na
określenie przez wykonawców ceny ofertowej. Gdyby odwołujący zdecydował się na
złożenie oferty przy takim brzmieniu siwz (co jest bardzo wątpliwe), musiałby wziąć pod
uwagę rozszerzony zakres ryzyk i wycenić je w ofercie - co doprowadzi do odpowiedniego
podniesienia ceny ofertowej. Tym samym zamawiający sam doprowadzi do podwyższenia
ceny, poprzez nieprawidłowe sformułowanie siwz.
Mając powyższe na uwadze odwołujący wniósł o:
1.
wykreślenie wskazanych postanowień w zakresie, w jakim przedmiot zamówienia
miałby być określany dopiero na etapie analizy, po podpisaniu umowy,
2.
wpisanie w to miejsce wymagań zamawiającego odnośnie przedmiotu zamówienia.
Odwołujący nie wskazał konkretnych zapisów siwz, które powinny być umieszczone w siwz,
gdyż nie są mu znane wymagania, jakie zamawiający stawia przedmiotowi zamówienia we
wskazanych zapisach siwz. Tym samym odwołujący, żądając dodania konkretnych zapisów
siwz, musiałby zastąpić zamawiającego w zakresie określania i opisania przedmiotu
zamówienia.
Odwołujący zarzucił, że załącznik nr 1 do siwz - OPZ w związku z siwz Rozdział XVI Kryteria
oceny ofert oraz ich znaczenie pkt 4 ppkt 1) siwz jest niejednoznaczny i niewyczerpujący,
uniemożliwiający przygotowanie oferty.
Zamawiający w Rozdziale XVI siwz „Kryteria oceny ofert oraz ich znaczenie" ustanowił 2
kryteria oceny ofert: cena z wagą 60% i funkcjonalność z wagą 40%. Zgodnie z
postanowieniami pkt 4 ppkt 1) Rozdziału XVI siwz wykonawcy zobowiązani są do
wypełnienia załącznika nr 1 do OPZ - Wymagania funkcjonalne/formularz oceny technicznej i
wskazania, które elementy funkcjonalności wymaganej przez zamawiającego jako
standardowa oferują w ofercie, co oznacza, że wykonawcy mają zadeklarować, jakie
elementy funkcjonalne wymagane przez zamawiającego posiadają już w chwili ofertowania,
które są elementem oprogramowania standardowego.
Jednocześnie zamawiający określił swoje wymagania odnośnie funkcjonalnych wymagań
oprogramowania standardowego w sposób otwarty, nieokreślony na etapie przygotowania i
składania ofert tj. w punktach W pkt 1.7 str. 4 OPZ
,
VI.B.10 str. 11 OPZ
,
VIII.2 str. 22 OPZ
,
XI.1 str. 27 OPZ
,
XI.6.18 str. 29 OPZ
,
Wymagania funkcjonalne 2.2 poz.11
,
Wymagania
funkcjonalne 4.13 poz. 32
,
Wymagania funkcjonalne 8.2 poz. 57
,
Wymagania funkcjonalne
8.3 poz. 58, Wymagania funkcjonalne 8.5 poz.60
,
Wymagania funkcjonalne 8.8 poz.63
,
Wymagania funkcjonalne 8.9 poz.64
,
Wymagania funkcjonalne 8.13 poz.68
,
Wymagania
funkcjonalne 10.1 poz.77
,
Wymagania funkcjonalne 11.2 poz.82
,
Wymagania funkcjonalne
12.10 poz.98
,
Wymagania funkcjonalne 14.1 poz. 108
,
Wymagania funkcjonalne 14.3

poz.110
,
Wymagania funkcjonalne 14.5 poz.112
,
Wymagania funkcjonalne 14.7 poz.114
,
Wymagania funkcjonalne 15.10 poz.128
,
Wymagania funkcjonalne
16.16
poz.145
,
Wymagania funkcjonalne 16.19 poz.148
,
Wymagania funkcjonalne 18.11 poz.168
,
Wymagania funkcjonalne 19.1 poz.176
,
Wymagania funkcjonalne 19.15 poz.190
,
Wymagania funkcjonalne 20.4 poz.195
,
Wymagania funkcjonalne 21.5 poz.217
,
Wymagania
funkcjonalne 23.2 poz.231
,
Wymagania funkcjonalne 23.3 poz.232
,
Wymagania
funkcjonalne 23.4 poz.233
,
Wymagania funkcjonalne 23.5 poz.234
,
Wymagania
funkcjonalne 23.6 poz.235
,
Wymagania funkcjonalne 23.13 poz.242, Wymagania
funkcjonalne 23.21 poz.250, Wymagania funkcjonalne 23.24 poz.253, Wymagania
funkcjonalne 29.4 poz.318, Wymagania funkcjonalne 29.9 poz.323, Wymagania funkcjonalne
30.5 poz.330, Wymaganie funkcjonalne 31.6 poz. 343, Wymaganie funkcjonalne 32.1 poz.
345, Wymagania funkcjonalne 33.2 poz.358.
W ocenie odwołującego, mamy zatem do czynienia z wadliwością siwz, która uniemożliwia
sporządzenie oferty. Z jednej strony zamawiający wymaga, aby wykonawcy zadeklarowali,
czy oferowane przez nich oprogramowanie posiada, czy nie posiada daną funkcjonalność. Z
drugiej zaś strony - zamawiający stwierdza, że funkcjonalność ta zostanie określona dopiero
na etapie analizy. Takie zapisy siwz, zdaniem odwołującego, uniemożliwiają sporządzenie
oferty-gdyż wykonawcy nie są w stanie zgodnie ze stanem faktycznym zadeklarować
posiadania danej funkcjonalności w arkuszu Wymagania Funkcjonalne, skoro zamawiający
nie określił tej funkcjonalności w sposób zgodny z art. 29 ust. 1 ustawy.
Powyższe sformułowanie siwz narusza przepisy wskazane w uzasadnieniu powyżej.
Odwołujący wniósł o:
1.
wykreślenie wskazanych postanowień w zakresie, w jakim przedmiot zamówienia
miałby być określany dopiero na etapie analizy, po podpisaniu umowy,
2.
wpisanie w to miejsce wymagań zamawiającego odnośnie przedmiotu zamówienia.
Odwołujący nie wskazał konkretnych zapisów siwz, które powinny być umieszczone w siwz,
gdyż nie są mu znane wymagania, jakie zamawiający stawia przedmiotowi zamówienia we
wskazanych zapisach siwz. Tym samym odwołujący, żądając dodania konkretnych zapisów
siwz, musiałby zastąpić zamawiającego w zakresie określania i opisania przedmiotu
zamówienia.
W zakresie załącznika nr 2 do siwz - Istotne Postanowienia Umowy - Rozdział 11, zdaniem
odwołującego zostało niedookreślone zobowiązanie dotyczące przekazania wiedzy.
Postanowieniami §§ 111. - 116 zamawiający ustanowił obowiązki i zasady dotyczące
przekazania wiedzy zamawiającemu przez wykonawcę. Obejmują one udzielanie wyjaśnień
na żądanie zamawiającego oraz przeprowadzenie szkoleń. Niestety poszczególne
zobowiązania w żaden sposób nie zostały „zwymiarowane" przez zamawiającego. Tym

samym zamawiający określił swoje wymagania odnośnie transferu wiedzy w sposób otwarty,
nieokreślony na etapie przygotowania i składania ofert.
Mamy zatem do czynienia z wadliwością siwz, która uniemożliwia sporządzenie oferty.
W związku z powyższym, odwołujący wniósł o nakazanie zamawiającemu wpisania w
postanowienia Rozdziału 11. skonkretyzowanych wymagań zamawiającego dotyczących
przekazania wiedzy, poprzez zdefiniowanie maksymalnej pracochłonności w kwartale dla
zleceń dotyczących przekazania wiedzy.
Odwołujący nie wskazał konkretnych zapisów siwz, które powinny być umieszczone w siwz,
gdyż nie są mu znane wymagania, jakie zamawiający stawia przedmiotowi zamówienia we
wskazanych zapisach siwz. Tym samym odwołujący, żądając dodania konkretnych zapisów
siwz, musiałby zastąpić zamawiającego w zakresie określania i opisania przedmiotu
zamówienia.
Odnośnie do załącznika nr 2 do siwz - Istotne Postanowienia Umowy - §
134,135,136,137,140,156 odwołujący zarzucił, że postanowienia umowne nakładają
odpowiedzialność wykonawcy także w przypadku braku winy wykonawcy.
Zamawiający ustanowił w § 134, 135, 136, 137, 140 umowy, iż wykonawca zobowiązany jest
do zapłaty kary umownej w przypadkach opóźnienia w wykonaniu wskazanych obowiązków
umownych. Z kolei w § 156 ust. 3 i 4 umowy ustanowił prawo odstąpienia od umowy w
przypadkach opóźnienia w wykonaniu wskazanych obowiązków umownych.
Tym samym zamawiający zmodyfikował ogólną zasadę odpowiedzialności kontraktowej
określoną w art. 471 Kodeksu Cywilnego, zgodnie z którą dłużnik nie ponosi
odpowiedzialności, gdy skutecznie ekskulpuje się - czyli wykaże, że niewykonanie lub
nienależyte wykonanie zobowiązania wynika z okoliczności, za które dłużnik nie ponosi
odpowiedzialności. Co prawda możliwe jest umowne rozszerzenie odpowiedzialności
dłużnika zgodnie z przepisem art. 473 § 1 KC. Zdaniem odwołującego zamawiający naruszył
regulację art. 473 § 1 KC (w związku z art. 14 i art. 139 ustawy) w przedmiotowym zapisie.
Otóż rozszerzenie odpowiedzialności zgodnie z art. 473 § 1 KC możliwe wyłącznie w
przypadku wskazania w umowie „oznaczonych okoliczności, za które na mocy ustawy
odpowiedzialności nie ponosi. Zgodnie z art. 471 KC dłużnik nie jest zobowiązany do
naprawienia szkody, jeśli jest ona skutkiem okoliczności, za które nie ponosi dłużnik
odpowiedzialności. A zatem nie ponosi odpowiedzialności - jeśli jest ona skutkiem działania
osób trzecich, samego Zamawiającego czy siły wyższej. Tymczasem zamawiający nie
określił w przedmiotowym zapisie umowy - wbrew regulacji art. 473 § 1 KC - tych
konkretnych, oznaczonych okoliczności, na które odpowiedzialność miałaby być
rozszerzona, której to odpowiedzialności zgodnie z ogólnymi zasadami odpowiedzialności
kontraktowej wykonawca nie ponosi. Brak takiego wskazania powoduje, że umowne
rozszerzenie odpowiedzialności kontraktowej staje się nieskuteczne. Odwołujący uważa, że

brzmienie przedmiotowych zapisów nie jest działaniem zamierzonym przez zamawiającego -
a to ze względu na fakt, że naruszałby art. 473 § 1 KC.
Niedopuszczalność takiego rozszerzenia odpowiedzialności wykonawców potwierdziła
zarówno Krajowa Izba Odwoławcza w wyroku KIO 35/08 oraz Sąd Najwyższy w wyroku z
dnia 27 września 2013 roku, sygnatura akt I CSK 748/12. Ponadto przedmiotowy zapis
narusza także zasadę ekwiwalentności świadczeń stron wynikających z umowy wzajemnej
wyrażona w art. 487 § 2 KC (w związku z art, 14 i art. 139 ustawy). Trudno tymczasem
mówić o ekwiwalentności świadczeń w sytuacji, w której wykonawca kalkulując cenę swojej
oferty nie jest w stanie odnieść jej do dającego się przewidzieć ryzyka wykonania umowy
oraz dającego się przewidzieć zakresu odpowiedzialności z tytułu nienależytego wykonania
umowy. A taka sytuacja zachodzi - gdyż zgodnie z przedmiotowym zapisem wykonawca
ponosi odpowiedzialność za działania i zaniechania osób trzecich i zamawiającego, za
których zgodnie z KC odpowiedzialności nie ponosi. Co więcej, w ocenie odwołującego, brak
takiej ekwiwalentności stanowi także naruszenie art. 5 i art. 58 § 1 i 2 KC (w związku z art.
14 i art. 139 ustawy) - gdyż takie określenie przez zamawiającego zakresu
odpowiedzialności wykonawcy jest sprzeczne ze społeczno-gospodarczym przeznaczeniem
tego prawa oraz sprzeczne z zasadami współżycia społecznego. Według odwołującego nie
można bowiem uznać za zgodne z obowiązującymi zasadami nałożenie na wykonawcę
konieczności ponoszenia odpowiedzialności w przypadku, gdy nie można mu przypisać winy.
Odwołujący wskazał, że pogląd o niemożności naliczenia kary umownej w przypadku braku
winy potwierdzany był wielokrotnie przez Sąd Najwyższy, przykładowo już w wyroku z dnia
20 marca 1968 r. II CR 419/67, w wyroku z dnia 27 września 2013 roku, sygnatura akt I CSK
748/12, a także w wyrokach : wyrok z dnia 26 stycznia 2011 r. II CSK 318/10, wyrok z dnia 6
października 2010 r. II CSK 180/10, wyrok z dnia 11 stycznia 2008 r. V CSK 362/07, wyrok z
dnia 21 września 2007 r. V CSK 139/07, wyrok z dnia 11 marca 2004 r. V CSK 369/03,
wyrok z dnia 11 czerwca 2003 r. III CKN 50/01, wyrok z dnia 27 czerwca 2003 r. IV CKN
300/01.
Takie stanowisko zaprezentowała również Krajowa Izba Odwoławcza w wyroku z dnia 21
maja 2014 roku, KIO 923/14, w wyroku z dnia 14 marca 2012, KIO 399/1.
Zaskarżone zapisy siwz powodują, że umowa jest korzystna tylko dla jednej ze stron - dla
zamawiającego, a obowiązki nałożone są tylko na wykonawcę. Krajowa Izba Odwoławcza, w
ocenie odwołującego, wielokrotnie krytykowała takie kształtowanie stosunków umownych
przez zamawiającego - jak choćby w wyroku z dnia 23 sierpnia 2010 roku, KIO/UZP
1698/10.
W związku z powyższym odwołujący wniósł o wykreślenie w : § 134, 135, 136, 137, 140, 156
słowa „opóźnienie" i zastąpienie go odpowiednio słowem „zwłoka".

W zakresie załącznika nr 2 do siwz - Istotne Postanowienia Umowy - § 134 i 135 –
odwołujący uważa, że została zastrzeżona rażąco wysoka kara umowna i zachodzi brak
adekwatności wysokości kary do wynagrodzenia wykonawcy.
Zamawiający w § 134 uregulował karę umowną w sposób, który powoduje, że realna kara
nie będzie w ogóle powiązana z wynagrodzeniem wykonawcy. Kara ta bowiem została
określona kwotowo, a nie procentowo i powoduje to powstanie sytuacji, w której wykonawca
oferujący niższą cenę będzie bardziej karany, niż wykonawca, który zaoferuję cenę wyższą.
Kara określona kwotowo jest bardziej dolegliwa dla wykonawcy, który będzie się starał
zaoferować jak najniższą cenę. Takie sformułowanie kary powoduje też, że wykonawcy będą
zmuszeni uwzględnić w cenie oferty takie wysokie kary i odpowiednio dodać do ceny oferty
rezerwę na takie ryzyko.
Z kolei kara umowna przewidziana w § 135 jest karą rażąco wysoką. Kara w wysokości 1%
za jeden dzień zwłoki, w ocenie odwołującego, nie stanowi już bowiem środka, który
motywuje wykonawcę, ale prowadzi wyłącznie do wzbogacenia po stronie zamawiającego.
Zdaniem odwołującego nie należy zapominać, że kara umowna jest substytutem
odszkodowania i w żadnym przypadku nie powinna prowadzić do wzbogacenia po stronie
strony, na rzecz której jest zastrzegana. Zapisy umowy, jak powyżej kwestionowane, nie
mogą zostać uznane za prawidłowe i zgodne z zasadami współżycia społecznego. Pogląd
taki znajduje uzasadnienie w orzecznictwie Sądu Najwyższego (por. orzeczenia Sądu
Najwyższego z dnia: 11 kwietnia 2002 r,, III CKN 492/01, 11 czerwca 2008 r., V CSK 8/08,
30 września 2010 r., I CSK 342/10, 11 października 2013 r., I CSK 697/12). Narusza to
bowiem art. 471 KC w związku z art,483 i art. 484 KC, a także art. 3531 KC w związku z art.
14 i art. 139 ustawy.
Odwołujący wniósł o:
1. wykreślenie dotychczasowej treść § 134 i w to miejsce wpisanie:
„W przypadku zwłoki Wykonawcy w wykonaniu danego Etapu lub Fazy w stosunku do
Harmonogramu wdrożenia, Wykonawca, na żądanie Zamawiającego, zobowiązany będzie
do zapłaty Zamawiającemu:
1.
kary umownej w wysokości 0,5% wynagrodzenia za daną Fazę za każdy rozpoczęty
tydzień opóźnienia w wykonaniu Fazy w ramach Etapu 1;
2.
kary umownej w wysokości 0,3596 wynagrodzenia za daną Fazę za każdy
rozpoczęty tydzień opóźnienia w wykonaniu Fazy w ramach Etapu 2;
3.
kary umownej w wysokości 0,2% wynagrodzenia za daną Fazę za każdy rozpoczęty
tydzień opóźnienia w wykonaniu Fazy w ramach Etapu 3."
2.
wykreślenie dotychczasową treść § 135 i w to miejsce wpisanie:

„W przypadku zwłoki Wykonawcy w wykonaniu zamówienia realizowanego w ramach usług
Rozwoju i Walidacji, Wykonawca zapłaci Zamawiającemu korę umowną w wysokości 0,1%
wartości złożonego zamówienia za każdy dzień zwłoki"
Podnosząc zarzuty związane z załącznikiem nr 2 do siwz - Istotne Postanowienia Umowy -
Załącznik nr 3 do Umowy- Prawa własności intelektualnej, §6 ust.3) i 4), §7 ust. 5) –
odwołujący zakwestionował sposób zapewnienia zamawiającemu prawa do obrotu oraz
rozpowszechniania pozostałej dokumentacji oraz oprogramowania.
Postanowienia Załącznika nr 3 do Umowy regulują stosunki pomiędzy stronami w zakresie
dotyczącym praw autorskich w rozumieniu ustawy z dnia 4 lutego 1994 r. o prawie autorskim
i prawach pokrewnych (dalej „UPAiPP"). Całkowicie zrozumiałą dla odwołującego jest
potrzeba zamawiającego zapewnienia sobie „władztwa" nad produktami, w tym
oprogramowaniem dostarczanymi w ramach realizacji postanowień umowy, zapewnienie
prawa do korzystania i modyfikowania w zakresie, jaki jest niezbędny do prowadzenia
działalności przez zamawiającego zdefiniowanej przepisami prawa i Statutem
zamawiającego. Zapewnienie „władztwa" niewątpliwie służy zarówno zapewnieniu
bezpieczeństwa działania zamawiającego, ale także „uniezależnieniu"' się od wykonawców.
Odwołujący zwrócił jednak uwagę, iż postanowienia §6 ust.2 pkt. 3) i 4) oraz §7 ust. 1 pkt 5)
Załącznika nr 3 wykraczają znacząco poza uregulowania dotyczące zapewnienia
skutecznego prawa do korzystania i modyfikowania w związku z prowadzoną działalnością.
Zastosowana przez zamawiającego konstrukcja „narusza" właścicielskie ramy autorskich
praw majątkowych chroniących wykonawcę i jemu służących i w ocenie odwołującego jest
absolutnie nieuzasadniona.
Postanowienia §6 ust.2 pkt. 3) i 4) oraz §7 ust. 1 pkt 5) zapewniają zamawiającemu prawo
nie tylko do uzasadnionego wykorzystywania produktów autorstwa wykonawcy w ramach
prowadzonej działalności i w celu prowadzenia działalności, ale zapewniają także
zamawiającemu prawo do wszelkich form rozporządzania i rozpowszechniania przedmiotem
prawa autorskiego, również w celach komercyjnych. Zapisy wyraźnie wskazują więc na wolę
zamawiającego, którą jest nie tylko wspomaganie bieżącej działalności, ale również
rozporządzanie utworem w bliżej nieokreślonym celu, w tym w celach komercyjnych.
Udzielenie przez wykonawcę prawa zamawiającemu w opisanym zakresie, jak również na
osobę trzecią stanowi, w ocenie odwołującego, narażenie wykonawcy na nieszacowalną, w
tym momencie, szkodę. Wykonawca „otwiera" bowiem swoją „własność", z której czerpie
dochody, której produkcja, rozwój i utrzymanie jest źródłem dochodu wykonawcy,
pozbawiając się tym samym źródła tego dochodu. Przeniesienie praw autorskich w
opisanych zakresie powoduje bowiem, iż potencjalny kontrahent będzie miał dostęp do
produktu w wyniku udostępnienia go przez zamawiającego. Tak szeroki zakres prawa, które
zastrzega zamawiający, jako zakres do przeniesienia dodatkowo „uderza" w zagadnienia

związane z ochroną know-how wykonawcy i jego tajemnicy przedsiębiorstwa. Informacje
wrażliwe dla wykonawcy tracą w tym momencie swoją ochronę.
Takie podejście zamawiającego, w ocenie odwołującego, stanowi naruszenie zasady
uczciwej konkurencji, co potwierdza Krajowa Izba Odwoławcza przy Urzędzie Zamówień
Publicznych wyrokiem w sprawie o sygn. akt KIO/UZP-423/08. Odwołujący wniósł o
nakazanie zamawiającemu zmiany treści siwz poprzez zmianę umowy w zakresie Załącznika
nr 3 poprzez zmianę §6 ust. 2 pkt 3) i 4) oraz §7 ust. 1 pkt 5) i ustalenie następującego
brzmienia odpowiednio §6 ust. 2 i §7 ust. 1:
§6 ust.2
„2. Licencja ma charakter niewyłączny i uprawnia BGK do korzystania z Pozostałej
Dokumentacji i jej poszczególnych elementów na terytorium Rzeczypospolitej Polskiej, na
następujących polach eksploatacji:
1)
w zakresie korzystania w całości lub części;
2)
w zakresie utrwalania i zwielokrotniania - wytwarzanie dowolną techniką egzemplarzy
utworu, w tym techniką drukarską, reprograficzną, zapisu magnetycznego oraz techniką
cyfrową,
3)
w zakresie tłumaczenia, adaptacji (opracowań), wprowadzania zmian, uzupełnień i
modyfikacji,
4)
w zakresie prawa zezwalania na wykonywanie zależnego prawa autorskiego na
polach eksploatacji wymienionych w punktach poprzedzających."
§7 ust.2
„1. Prawa, o których mowa w niniejszym § 7 uprawniają BGK do korzystania z SystemuBE i
jego poszczególnych elementów na terytorium Rzeczypospolitej Polskiej co najmniej na
następujących polach eksploatacji:
1)
korzystanie w całości lub części z Oprogramowania;
2)
dokonywanie dowolnych zmian Oprogramowania, niezależnie od zakresu, formy,
sposobu (środków) ich dokonania oraz przeznaczenia, z zastrzeżeniem , że nie dotyczy to
utworów na które została udzielona jedynie licencja;
3)
trwałe lub czasowe zwielokrotnianie u Oprogramowania w całości lub w części
jakimikolwiek środkami i w jakiejkolwiek formie;
4)
wielokrotny obrót oryginałem albo egzemplarzami, na których Oprogramowanie
utrwalono - wprowadzenie do obrotu, użyczenie lub najem oryginału albo egzemplarzy, z
zastrzeżeniem, że nie dotyczy to Oprogramowania na które została udzielona jedynie
licencja;
5)
wielokrotnego wprowadzania do pamięci komputera Oprogramowania;
6)
zezwalania na wykonywanie zależnego prawa autorskiego na polach eksploatacji
wymienionych w punktach poprzedzających, z zastrzeżeniem, że nie dotyczy to utworów, w

szczególności Oprogramowania Standardowego oraz Oprogramowania Pomocniczego na
które została udzielona jedynie licencja."
Co do załącznika nr 2 do siwz - Istotne Postanowienia Umowy - Załącznik nr 3 do Umowy-
Prawa własności intelektualnej, §8, gdzie zamawiający ustanowił odrębne zasady
licencjonowania oprogramowania dla wykonawców, którym nie przysługują prawa własności
intelektualnej do oprogramowania, to odwołujący podniósł, że postanowienia te regulują
stosunki pomiędzy stronami w zakresie dotyczącym praw autorskich w rozumieniu ustawy z
dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (dalej „UPAiPP").
Zamawiający reguluje postanowieniami załącznika nr 3 różne zakresy „metody", w tym
zakresy pełnienia „władztwa" nad produktami dostarczonymi w związku z realizacją
przedmiotu zamówienia. Zamawiający wskazuje zatem, w celu zapewniania sobie
możliwości korzystania z dostarczanych produktów (Dokumentów, Dokumentacji oraz
Oprogramowania), jako „metodę" akceptowalną: przeniesienie na zamawiającego autorskich
praw majątkowych, udzielenie licencji uprawniającej do korzystania z Dokumentów,
Dokumentacji oraz Oprogramowania. Zamawiający dodatkowo różnicuje zakres uprawnień w
zależności od „metody", co jest absolutnie zrozumiałe i prawnie poprawne.
Odwołujący nie znajduje jednak uzasadnienia dla dodatkowego zróżnicowania zakresu,
którego przesłanką jest niejako „gatunek" wykonawcy. Otóż w §8 Zamawiający wskazuje
odrębny zakres uprawnień do korzystania z Oprogramowania Standardowego oraz
Oprogramowania Pomocniczego, których przeniesienia żąda od wykonawcy, któremu nie
przysługują Prawa własności intelektualnej. O ile takie podejście wydaje się uzasadnione do
Oprogramowania Pomocniczego, które jest wystandaryzowanym oprogramowaniem „z
półki", o tyle odnośnie do oprogramowania standardowego wydaje się kompletnie
niezasadne. Istotne jest, w ocenie odwołującego, bowiem, że ten zakres może być „węższy"
niż zakres uprawnień licencyjnych, które przewidział zamawiający w §7 Załącznika nr 3.
Takie postanowienia kreują preferencję wykonawcy, który nie jest producentem
oprogramowania standardowego będącego potencjalnie przedmiotem zamówienia, które to
oprogramowanie standardowe jest licencjonowane przez producenta w „węższym zakresie"
niż zakres przewidziany w § 7 Załącznika nr 3.
W opinii odwołującego takie zróżnicowanie zakresów w odniesieniu do wykonawców-
producentów i wykonawców-nieproducentów, stanowi naruszenie zasady równego
traktowania wykonawców. Konieczność respektowania tej zasady potwierdziła Krajowa Izba
Odwoławcza przy Urzędzie Zamówień Publicznych w wyroku z dnia 14 marca 2011 r. w
sprawi o sygn. akt KIO/UZP 387/11.
Dodatkowo Odwołujący podniósł, że zróżnicowanie wykonawców i zróżnicowanie zakresów
może mieć wpływ na wycenę zamówienia, jak również spowodować, że oferty będą
nieporównywalne.

W związku z powyższym, odwołujący wniósł o nakazanie zamawiającemu zmiany treści siwz
poprzez zmianę umowy w zakresie załącznika nr 3 poprzez zmianę §8 zdanie pierwsze i
nadanie mu następującego brzmienia:
„§ 8. W przypadkach innych niż wymienione w § 7 powyżej, wykonawca, w ramach
wynagrodzenia przewidzianego za wykonanie Przedmiotu Umowy, spowoduje udzielenie
Zamawiającemu licencji do korzystania z Oprogramowania Pomocniczego, do których nie
przysługują Wykonawcy Prawa własności intelektualnej, na warunkach przewidzianych w
niniejszym paragrafie. Postanowienia zawarte w niniejszym paragrafie dotyczące udzielenia
licencji do Oprogramowania Pomocniczego dotyczą również wszystkich ich późniejszych
zmian, aktualizacji i modyfikacji dokonanych m.in. w ramach Aktualizacji, Walidacji i Rozwoju
System u BE."
Odnośnie do załącznika nr 2 do siwz - Istotne Postanowienia Umowy, § 70 - 72 w związku z
Rozdziałem XVI „Kryteria oceny ofert oraz ich znaczenie" siwz pkt 4, odwołujący zarzucił
zamawiającemu brak zasad oceny ofert.
Zamawiający w Rozdziale XVI siwz „Kryteria oceny ofert oraz ich znaczenie" ustanowił 2
kryteria oceny ofert: cena z wagą 60% i funkcjonalność z wagą 40%. Zgodnie z
postanowieniami pkt 4 wykonawcy zobowiązani są do wypełnienia załącznika nr 1 do OPZ -
Wymagania funkcjonalne/formularz oceny technicznej i wskazania, które elementy
funkcjonalności wymaganej przez zamawiającego jako standardowa oferują w ofercie, co
oznacza, że wykonawcy mają zadeklarować, jakie elementy funkcjonalne wymagane przez
zamawiającego posiadają już w chwili ofertowania, które są elementem oprogramowania
standardowego.
Odwołujący wskazał, że zamawiający nie przewidział w żadnym postanowieniu siwz
weryfikacji prawdziwości i prawidłowości wypełnienia przez wykonawców załącznika nr 1 do
OPZ - Wymagania funkcjonalne/formularz oceny technicznej. Zamieścił jedynie w pkt 4 ppkt
4 o brzmieniu: „Zamawiający zastrzega, że w przypadku podania przez Wykonawcę w
formularzu oceny technicznej Załącznika nr 1 do OPZ - Wymagania funkcjonalne
nieprawdziwych informacji w zakresie funkcjonalności deklarowanych jako Standardowe,
uprawniać to będzie Zamawiającego do uchylenia się od skutków prawnych złożonego przez
siebie oświadczenia woli, na podstawie art. 86 Par. 1 k.c., w związku z wykryciem błędu,
który podstępnie wywołał Wykonawca." Postanowienie to nie jest jednak opisem sposobu
oceny oferty w zakresie prawidłowości przedmiotowej części oferty. Tym samym, zdaniem
odwołującego, należy uznać, że zamawiający w ogóle nie przewiduje rzeczywistej oceny
ofert w zakresie kryterium funkcjonalność, a jedynie przyzna ofertom punkty zgodnie z
oświadczeniami wykonawców. Z oświadczeniami, które na etapie ofert nie będą w ogóle
weryfikowane. Jednocześnie zamawiający w umowie przewidział następującą regulację:
„ Weryfikacja Oprogramowania Standardowego

§ 70. W ramach Fazy I Etapu I, Wykonawca w terminie uzgodnionym przez Strony, ale nie
dłuższym niż 30 Dni od wezwania przez Zamawiającego, udostępni system uruchomiony w
oparciu o Oprogramowanie Standardowe.
§ 71. BGK przystąpi do weryfikacji, czy zainstalowane Oprogramowanie Standardowe
spełnia wymogi i posiada funkcjonalności, które w Ofercie zostały określone jako mieszczące
się w standardzie na podstawie scenariuszy testowych dostarczonych wraz ze standardową
dokumentacją Oprogramowania Standardowego. Wykonawca ma obowiązek, na żądanie
Zamawiającego, udzielić wyjaśnień na temat działania Oprogramowania Systemowego i jego
standardowych funkcjonalności.
§ 72. W razie niewykonania zobowiązania, o którym mowa w § 70, a także w przypadku, gdy
Zamawiający stwierdzi, że Oprogramowanie Standardowe nie spełnia wymogów, o których
mowa w § 71 BGK, Zamawiający wzywa Wykonawcę do odpowiednio wykonania
zobowiązania, o którym mowa w §70 lub usunięcia stwierdzonych nieprawidłowości
wyznaczając termin nie krótszy niż 10 Dni Roboczych. Po bezskutecznym upływie tego
terminu Zamawiający może odstąpić od Umowy zgodnie z ROZDZIAŁ 15.§ 159."
Z przedmiotowych zapisów umowy, zdaniem odwołującego, wynika, że zamawiający na
etapie realizacji umowy będzie dokonywał weryfikacji zgodności oferty z siwz oraz jej
prawdziwości i prawidłowości. Zaś w przypadku, gdy okaże się, że oferta nie była zgodna z
siwz, przyznano jej zbyt dużo punktów, zaś wykonawca podał w ofercie nieprawdziwe
informacje - wtedy zamawiający przewidział, że odstąpi od umowy.
Zdaniem odwołującego rozwiązanie zastosowane przez zamawiającego jest nieprawidłowe.
Otóż zamawiający nie przeprowadza odpowiedniej oceny ofert na odpowiednim etapie
postępowania, jednocześnie zaś dokonuje takiej oceny na etapie, na którym jest to już
niemożliwe. Bowiem podstawą odstąpienia od umowy nie będzie de facto nienależyte
wykonanie jakiegoś obowiązku umownego na etapie realizacji Umowy, ale podstawą takiego
odstąpienia będzie nie spełnienie przez ofertę wymogów siwz. Należy wskazać, że skutki
takiego odstąpienia nie będą miały żadnego znaczenia dla samego postępowania o
udzielenie zamówienia publicznego. Po podpisaniu umowy zamawiający nie może bowiem
dokonać (także w przypadku odstąpienia od Umowy w trybie wskazanym w § 72) powtórnej
oceny ofert i wybrać innej oferty najkorzystniejszej.
Powyższe narusza art. 7 ust. 3 ustawy - gdyż zamówienie może zostać udzielone
wykonawcy, który złożył ofertę podlegającą odrzuceniu. Skutkiem zaniechania przez
zamawiającego badania na etapie oceny ofert prawidłowości ofert będzie wybór jako
najkorzystniejszej oferty, która powinna zostać odrzucona. Naruszony jest także przepis art.
89 ust, 1 pkt 2) ustawy, gdyż zamawiający sam pozbawił się możliwości weryfikacji ofert, a
tym samym doprowadzi do sytuacji, w której nie odrzuci ofert, których treść sprzeczna będzie
z siwz - pomimo iż taki obowiązek odrzucenia na zamawiającym ciąży.

Odwołujący wskazuje, że istnieje prosty sposób naprawienia przedmiotowej wadliwości siwz.
Otóż, zdaniem odwołującego, zamawiający powinien wprowadzić obowiązek dostarczenia
wraz z ofertą tzw. próbki, gdzie próbka powinna po prostu obejmować deklarowaną przez
wykonawców funkcjonalność. Zamawiający wymaga, aby taka funkcjonalność istniała w
chwili ofertowania i była elementem Oprogramowania Standardowego, zaś wykonawcy sami
deklarują - które elementy wymaganej funkcjonalności już posiadają jako element
oferowanego oprogramowania. Zatem, w ocenie odwołującego, nic nie stoi na przeszkodzie,
aby taka istniejąca i deklarowana funkcjonalność została - celem weryfikacji zgodności oferty
z siwz i prawdziwości oświadczeń wykonawców - dostarczona wraz z ofertą w postaci próbki.
Jednocześnie siwz powinien opisywać sposób badania przez zamawiającego dostarczonych
próbek.
Odwołujący wniósł o:
1.
wykreślenie w Rozdziale XVI siwz w pkt 4 ppkt 4) o treści: „Zamawiający zastrzega,że w przypadku podania przez Wykonawcę w formularzu oceny technicznej Załącznika nr 1
do OPZ - Wymagania funkcjonalne nieprawdziwych informacji w zakresie funkcjonalności
deklarowanych jako Standardowe, uprawniać to będzie Zamawiającego do uchylenia się od
skutków prawnych złożonego przez siebie oświadczenia woli, na podstawie art. 86 Par. 1
k.c., w związku z wykryciem błędu, który podstępnie wywołał Wykonawca."
2.
wpisanie w Rozdziale XXI siwz w pkt 4 zdania: „Próbka, o której mowa w Rozdziale
XVI pkt 4, powinna być podpisana podpisem certyfikowanym".
3.
wpisanie w Rozdziale XVI siwz w pkt 4 ppkt 4) następującej treści: „W celu
potwierdzenia posiadania funkcjonalności wskazanej w arkuszu Wymagania funkcjonalne,
wykonawca składa próbkę zawierającą wszystkie zadeklarowane funkcjonalności."
4.
dopisania w Rozdziale XVI siwz sposobu oceny przez Zamawiającego próbki
potwierdzającej posiadanie deklarowanych funkcjonalności standardowych,
5.
wykreślenie § 70-72 Umowy.
Odwołujący podnosząc zarzuty do Rozdziału XVI „Kryteria oceny ofert oraz ich znaczenie"
siwz pkt 4 ppkt 3) uznał, że postanowienia tego rozdziału stanowią nieuzasadnione
zastosowanie art. 89 ust. 1 pkt2) ustawy do kryterium oceny ofert.
Zamawiający wskazał w ppkt 3), iż w przypadku, gdy wykonawca zadeklaruje, że posiada
mniej niż 70% funkcjonalności standardowej, oferta tego wykonawcy zostanie odrzucona ze
względu na jej niezgodność z treścią siwz. Odwołujący wskazał, że wymóg zamawiającego,
aby wykonawca zaoferował co najmniej 70% funkcjonalności standardowej w przypadku, gdy
funkcjonalność jest osobnym kryterium oceny ofert - jest nielogiczne. Skoro zamawiający
zdecydował się, aby funkcjonalność standardowa w całości była osobnym kryterium oceny
ofert, to nie może jednocześnie wymagać, aby jakaś część funkcjonalności była konieczna i
niezbędna do zaoferowania. Jest to bowiem sytuacja taka sama, jakby w przypadku

kryterium cena zamawiający wskazał, jaka cena będzie traktowana jako cena rażąco niska i
oferta będzie odrzucana na podstawie art. 89 ust. 1 pkt 4) ustawy. Skoro zamawiający
zdecydował się, że całość funkcjonalności standardowej jest kryterium oceny ofert i jako taka
będzie oceniana, to wyłącznie od wykonawców zależy, czy zdecydują się zaoferować
oprogramowanie posiadające dużą czy małą ilość funkcjonalności standardowej.
Wykonawca - w ramach swoich samodzielnych decyzji biznesowych - może zdecydować się
zaoferować oprogramowanie tanie, posiadające małą ilość funkcjonalności standardowych.
Zaś zamawiający, skoro zdecydował się skorzystanie z tak a nie inaczej sformułowanego
kryterium funkcjonalność, nie jest uprawniony do ingerowania w takie decyzje i ograniczania
wykonawcy w tym zakresie.
Powyższa regulacja, w ocenie odwołującego, narusza art. 89 ust. 1 pkt 2) ustawy w związku
z art. 91 ust. 1 -2 ustawy.
Odwołujący wniósł o wykreślenie w Rozdziale XVI siwz w pkt 4 ppkt 3) o treści:
„Zamawiający wymaga, aby w ramach oferowanego rozwiązania Wykonawca zaoferował co
najmniej 70% liczby funkcjonalności określanej jako Standardowa z sumarycznej liczby
funkcjonalności zawartej w Załączniku nr 1 do OPZ - Wymagania funkcjonalne/formularz
oceny technicznej. W przypadku nie osiągnięcia wyżej wymienionego poziomu ilościowego
dla funkcjonalności Standardowej, oferta Wykonawcy będzie podlegała odrzuceniu ze
względu na jej niezgodność z treścią siwz."
Odwołujący podniósł także zarzuty dotyczące załącznika nr 2 do siwz - Istotne
Postanowienia Umowy: § 1 i Załącznik nr 4 do Umowy §2 zarzucając zamawiającemu
otwarty zakres definicji Awarii, Błędu, Usterki i otwarty zakres serwisu.
Zamawiający uregulował zakres zobowiązań wykonawcy w zakresie świadczenia serwisu w
następujący sposób:
- Awaria (Błąd Krytyczny) - Wada polegająca na nieprawidłowym funkcjonowaniu
Oprogramowania, w tym funkcjonowanie niezgodne z Dokumentacją
- Błąd - niebędąca Awarią ani Usterką Wada polegająca na nieprawidłowym funkcjonowaniu
Oprogramowania SystemuBE, w tym funkcjonowanie niezgodnie z Dokumentacją
- Usterka - inna niż Awaria, Błąd lub Zgłoszenie problemu Infrastruktury Wada polegająca na
nieprawidłowym funkcjonowaniu Oprogramowania SystemuBE, w tym w szczególności
niezgodnie z Dokumentacją
- Zakres świadczeń Serwisowych obejmuje w szczególnościŻadna z wyżej wymienionych definicji nie jest definicją stworzoną zgodnie z art. 29 ust. 1
ustawy. Zamawiający naruszył wszystkie wymagania tego przepisu: zakres świadczonych
usług, który składa się na przedmiot zamówienia jest określony w sposób niejednoznaczny i
niewyczerpujący, za pomocą określeń, które nie są dokładne oraz w sposób, który nie
uwzględnia wszystkich wymagań i okoliczności, które mają wpływ na sporządzenie oferty.

Po pierwsze - zakres Usług Serwisowych jest całkowicie otwarty. Wprowadzenie zwrotów „w
tym", „w szczególności" powoduje, że Zamawiający może w ramach świadczenia Usług
Serwisowych wymagać od wykonawcy dowolnych usług, zaś wyliczenie zawarte w § 2 w ust.
2.3. jest jedynie wyliczeniem przykładowym. Jedyny sposób zdaniem odwołującego, aby
usunąć te wadę siwz jest dokonanie takich zmian w § 2 ust. 2.3. Załącznika nr 4, w wyniku
których Usługa Serwisowa zostanie określona w sposób zamknięty, pozwalający wykonawcy
wycenić swoje usługi, które będzie świadczyć na podstawie oferty.
Po drugie - tak samo otwarty i niedookreślony jest zakres Awarii, Błędu i Usterki. Także w
tym przypadku poprzez wprowadzenie zwrotu „w tym" lub „w tym w szczególności"
zamawiający, w ocenie odwołującego, stworzył sytuację, kiedy na etapie przygotowania i
złożenia oferty nie można określić, co będzie przez zamawiającego traktowane jako szeroko
rozumiane błędy oprogramowania. W szczególnych przypadkach za Awarię czy Błąd może
zostać uznane także działanie zgodne z Dokumentacją czy dobrymi zasadami rynkowymi, a
które zamawiający uzna za wadliwość oprogramowania. Obecne definicje pozwalają
zamawiającemu na pełną dowolność w tym zakresie. Rozwiązaniem, które z jednej strony
jest racjonalne, a z drugiej strony jest standardem obowiązującym na rynku to uznanie za
Awarię, Błąd czy Usterkę takiego działania oprogramowania, które jest sprzeczne z
Dokumentacją Oprogramowania. Tym samym taka właśnie definicja powinna być użyta w
siwz.
Powyższe zapisy siwz naruszają przepisy wskazane w pkt I uzasadnienia odwołania.
odwołujący w całości powołuje w tym miejscu argumentację tam wskazaną.
Odwołujący wniósł o:
1.
o wykreślenie słów „w tym" oraz „w tym w szczególności" i zastąpienie ich zwrotem
„to jest" w następujący sposób:
o.
Awaria (Błąd Krytyczny) - Wada polegająca na nieprawidłowym funkcjonowaniu
Oprogramowania, to jest funkcjonowanie niezgodne z Dokumentacją:.
b.
Błąd - niebędąca Awarią ani Usterką Wada polegająca na nieprawidłowym
funkcjonowaniu Oprogramowania SystemuBE, to jest funkcjonowanie niezgodnie z
Dokumentacją:
c.
Usterka - inna niż Awaria, Błąd lub Zgłoszenie problemu Infrastruktury Wada
polegająca na nieprawidłowym funkcjonowaniu Oprogramowania SystemuBE, to jest
niezgodnie z Dokumentacją:
2.
o wykreślenie słów „w szczególności" w Załączniku nr 4 w § 2 w ust 2.3 i nadanie mu
brzmienia: „Zakres świadczeń Serwisowych obejmuje:"

W dniu 12 września 2014r. zamawiający zamieścił na swojej stronie internetowej informację
o wniesieniu odwołania wraz z jego kopią i wezwał do wzięcia udziału w postępowaniu
odwoławczym.

W dniu 15 września 2014r. do postępowania odwoławczego na piśmie zgłosił swój udział po
stronie zamawiającego wykonawca Comarch Polska Spółka Akcyjna z siedziba w Krakowie,
Al. Jana Pawła II 39a wnosząc o oddalenie odwołania. Wskazał, że ma interes w
rozstrzygnięciu na korzyść zamawiającego, gdyż w jego interesie leży uzyskanie utrzymanie
czynności sporządzenia siwz i ogłoszenia w brzmieniu nadanym mu przez zamawiającego.
Uwzględnienie odwołania doprowadziłoby do zniesienia postawionych przez zamawiającego
istotnych wymagań, które znajdują pełne oparcie w przedmiocie zamówienia doprowadzając
do sytuacji ubiegania się o zamówienie wykonawców nie gwarantujących jego należytego
wykonania. W ocenie zgłaszającego kwestionowane postanowienia ogłoszenia i siwz nie są
niezgodne z ustawą. Określenie postanowień siwz i ogłoszenia leży w gestii zamawiającego
jako gospodarza postępowania, który jest uprawniony do samodzielnego określenia
wymagań w sposób odpowiadający jego potrzebom i zapewniający osiągnięcie
zamierzonego celu, pod warunkiem zachowania uczciwej konkurencji i równego traktowania
wykonawców. Zgłoszenie zostało podpisane przez pełnomocnika działającego na podstawie
pełnomocnictwa załączonego do zgłoszenia udzielonego przez wiceprezesa zarządu i
prokurenta ujawnionych w KRS i upoważnionych do łącznej reprezentacji, zgodnie z
odpisem z KRS załączonym do zgłoszenia. Kopia zgłoszenia została przekazana
zamawiającemu drogą elektroniczną w dniu 15 września 2014r., co zamawiający potwierdził,
a odwołującemu faksem w dniu 15 września 2014r.

W dniu 19 września 2014r. odwołujący złożył oświadczenie o wycofaniu zarzutów :
- zarzutu braku zasad oceny ofert w załączniku nr 2 do siwz Istotne Postanowienia Umowy, §
70 -72 w związku z Rozdziałem XVI „Kryteria Oceny ofert oraz ich znaczenie”
- zarzutu nieuzasadnionego zastosowania art. 89 ust. 1 pkt 2 ustawy do kryterium oceny
ofert w rozdziale XVI „Kryteria oceny ofert oraz ich znaczenie” pkt 4 ppkt. 3. Oświadczenie
zostało podpisane przez pełnomocnika działającego na podstawie pełnomocnictwa z dnia 18
września 2014r. udzielonego przez dwóch wiceprezesów zarządu ujawnionych w KRS i
upoważnionych do łącznej reprezentacji, zgodnie z odpisem z KRS załączonym do
odwołania.
Zaś na rozprawie odwołujący cofnął także zarzut dotyczący naruszenia art. 473 par. 1 i 487
par 2 kc, art. 5 i 58 kc w związku z art. 14 i 139 ustawy przez określenie odpowiedzialności
wykonawcy także w przypadku braku jego winy, zarzut naruszenia art. 484 par. 2 kc w
związku z art. 14 i 139 ustawy przez określenie rażąco wygórowanych kar umownych oraz

braku adekwatności wysokości kary umownej do wynagrodzenia wykonawcy, a także zarzut
dotyczący naruszenia przez zamawiającego art. 29 w związku z postanowieniami załącznika
nr 2 do siwz Istotnych postanowień umownych – załącznika nr 3 do umowy w zakresie jakim
zapewniały zamawiającemu prawa do obrotu oraz rozpowszechniania pozostałej
dokumentacji oraz oprogramowania.
W dniu 19 września 2014r. przystępujący złożył pismo przygotowawcze, w którym
podtrzymał wniosek o oddalenie odwołania i w zakresie zarzutów dotyczących opisu
przedmiotu zamówienia i kryteriów oceny ofert stwierdził, że odesłanie do etapu analizy nie
zwiększa w żaden sposób zakresu przedmiotu zamówienia, jedynie go doprecyzowuje.
Ponadto te same funkcjonalności których wymaga zamawiający są jako takie dookreślone w
siwz – jedynie techniczne szczegóły tych funkcjonalności mają zostać doszczegółowione
później, co jest według przystępującego normalnym zgodnym z dobrymi praktykami
elementem każdego wdrożenia. W ocenie przystępującego nie ma potrzeby przedstawiania
Księgi Identyfikacji Wizualnej Banku na etapie postępowania, gdyż w trakcie projektu ustala
się kolorystykę ekranów, wielkość i rodzaj użytych czcionek, rozmiar logo, wiedza w tym
zakresie na etapie postępowania nie zwiększa pewności wykonawcy, jaki ma być
rzeczywisty zakres przedmiotu zamówienia, ani nie uniemożliwia przygotowanie oferty.
Wymagania dotyczące metod integracji i zasad ich przeprowadzenia, są jasne i klarowne, a
ewentualne wątpliwości mogą być wyjaśnione w trybie zapytań do siwz i nie wymagają
modyfikacji siwz. Definiowanie szablonów importu/eksportu odbywa się przy użyciu wizardu
ułatwiającemu użytkownikowi wybór parametrów, gdyż systemy FK działające po stronie
klientów banków zawierają inne parametry niż systemu banku, stąd wdrażany system musi
być przygotowany do przyjęcia plików wygenerowanych przez jakikolwiek system FK. Co do
słowników są ich dwa rodzaje współdzielone – pobierane z systemów banku i dedykowane
udostępniane upoważnionym pracownikom banku. Na etapie oferty nie definiuje się
słowników, gdyż ich lista wynika ze specyfiki systemu oraz uwarunkowań rynku na jakim
system jest wdrażany. Dla określenia pełnej listy statusów i akcji możliwych do realizacji na
poszczególnych dyspozycjach niezbędna jest wiedza w zakresie interfejsów dostępnych na
szynie ESB, co stanowi tajemnicę bankową. Wiedza w tym zakresie nie jest niezbędna
wykonawcy, który ma doświadczenie we wdrażaniu systemów bankowości elektronicznej w
Polsce. W zakresie zarzutu trzeciego – przeniesienia wiedzy przystępujący podniósł, że w
Istotnych postanowieniach umownych par 111-116 zostało w sposób umożliwiający wycenę
określone jakie ma zamawiający wymagania w zakresie udzielania wyjaśnień i prowadzenia
szkoleń. Przeszkolić ma 20 pracowników w grupach maksymalnie 10 osobowych.
Pracownikami są administratorzy biznesowi, techniczny, ds. bezpieczeństwa, osoby
odpowiedzialne za rozwój. Szkolenie ma umożliwić samodzielne administrowanie i rozwój
systemu. Izba pominęła stanowisko przystępującego w zakresie zarzutu dotyczącego braku

weryfikacji oferowanych funkcjonalności za pomocą próbki, bo w tym zakresie odwołujący
cofnął odwołanie.
W dniu 23 września 2014r. przed otwarciem rozprawy zamawiający złożył odpowiedź na
odwołanie wnosząc o jego oddalenie w całości. W zakresie zarzutu niejednoznacznego i
niewyczerpującego opisu przedmiotu zamówienia zamawiający podniósł, że przedmiotem
zamówienia jest dostarczenie i wdrożenie systemu informatycznego bankowości
elektronicznej. Takie przedsięwzięcie jest wysoko zaawansowane technologicznie i
organizacyjnie i każdorazowo wymaga dostosowania do potrzeb danego banku, z tej
przyczyny etap analizy, w którym pewne funkcjonalności są dookreślane jest niezbędnym
stadium każdego wdrożenia. Systemy bankowości elektronicznej nie funkcjonują oddzielnie i
są integrowane z podstawowymi systemami finansowymi i operacyjnymi banku. Dlatego, aby
rozwiązanie mogło prawidłowo funkcjonować zgodnie z wymaganiami Prawa bankowego i
ustaw podatkowych musi być w szczegółach dostosowane do procesów biznesowych banku,
co odbywa się na etapie analizy. W zakres przedmiotu zamówienia wchodzi dokonanie
analizy i przygotowanie na jej podstawie wyników Specyfikacji Funkcjonalnej systemu BE.
Taki pogląd w ocenie zamawiającego wyrażała także Izba w wyroku z dnia 2 lipca 2010r.
sygn. akt KIO 1251/10. Ponadto etap wdrożenia został przewidziany na około 6 miesięcy,
zatem zasadne jest, aby zamawiający oczekiwał aby wdrożone funkcjonalności były jak
najbardziej aktualne i dostosowane do standardu rynkowego. Wykonawcy oferują
rozwiązania z podobnym zakresem funkcjonalności, ale różnice się implementacją i
szczegóły realizacji przedmiotu zamówienia zostaną ustalone na etapie analizy.
Zamawiający uważa, że opisał przedmiot zamówienia zgodnie z art. 29 ustawy przez
detaliczne wskazanie 279 funkcjonalności, możliwość dookreślenia pewnych elementów
przedmiotowych poszczególnych funkcjonalności na etapie prowadzonej analizy w żadnym
stopniu, w jego ocenie nie wskazuje, że przedmiot zamówienia ma charakter otwarty czy
nieokreślony. Wąski sposób określenia zamówienia w ocenie zamawiającego prowadziłby do
ograniczenia uczciwej konkurencji przez wymaganie rozwiązań pod konkretnego
wykonawcę. Poszczególne funkcjonalności mogą być w różny sposób realizowane (za
pomocą różnych parametrów, rozwiązań, formatów, akcji, operacji), stąd dopuszczenie
różnych rozwiązań otwiera konkurencyjność postępowania. Doszczegółowieniu będą
podlegać takie funkcje jak rozmieszczenie elementów ekranowych danej funkcji, zakres
walidacji, występowanie lub maskowanie szczegółowych pól danej funkcji. Często już samo
określenie danej funkcji systemu stanowi informację wystarczającą dla stworzenia i wyceny
oferty. Dotyczy to także wymagań pozafunkcjonalnych, które z kolei są związane z integracją
rozwiązania z systemami zamawiającego i jego procedurami operacyjnymi oraz zmiennym w
czasie wizerunkiem rynkowym. Zamawiany produkt nie jest produktem z „pudełka” i
obejmuje procesy wdrożeniowe. W ocenie zamawiającego jego stanowisko potwierdza

wyrok Izby z dnia 3 września 2009r. sygn. akt KIO/UZP 1081/09. W ocenie zamawiającego
odwołujący nie dokonał oceny istoty poszczególnych wymagań i z góry założył, że tam, gdzie
jest odesłanie do etapu analizy, to uniemożliwia to złożenie oferty. Nie wskazał jednak
uzasadnienia dla swojego stanowiska.
Zamawiający odniósł się do poszczególnych kwestionowanych wymagań:
Pkt. I.7.4 OPZ szata graficzna – zamawiający wskazał, ze jednoznacznie wskazano sposób i
moment opracowania szaty graficznej, choć zamawiający może już upublicznić Księgę
Identyfikacji Wizualnej Banku, to wie, że ulegnie ona zmienia na 90 lecie Banku, więc
przekazanie obecnie księgi jest sprzeczne z interesem zamawiającego i realizacją jego
potrzeb. Pracochłonność związana z opracowaniem elementów layout’ów, grafik, logo itp.,
nie zależy od momentu, kiedy przekazano wytyczne w tym zakresie,
Pkt. VI.B.10 – dotyczy szczegół1) technicznych dla przygotowania paczek i ich oznaczania
zgodnie z polityką obowiązującą w banku, oraz zgodnego z danym rozwiązaniem i dlatego
nie można tego opracować, przed wyborem wykonawcy, a doświadczony wykonawca jest w
stanie wycenić zakres prac przygotowując ofertę.
Pkt. VII.2. szczegóły dotyczące rozszerzania listy usług szyny ESB stanowią tajemnicę
przedsiębiorstwa zamawiającego i są decydujące dla bezpieczeństwa zamawiającego,
zawierają np. informacje na temat podatności systemu na nieautoryzowany dostęp z tego
względu mogą być udostępnione tylko wybranemu wykonawcy, a każdy wykonawca
powinien przewidzieć taki zakres prac przy opracowywaniu wyceny i oferty.
Pkt. XI.1 i pkt. XI.6.18 – również nie może być obecnie uszczegółowione ze względu na
bezpieczeństwo systemów informatycznych, wykonawca powinien przewidzieć te prace w
wycenie i ofercie.
Wymaganie 2.2.poz. 11 – dane dostępne offline – każde rozwiązanie posiada inną strukturę
danych prezentowanych na ekranie, to wykonawca powinien wskazać, dane, które powinny i
mogą być prezentowane w trybie offline
Wymaganie 4.13.poz. 32 – zamawiany efekt został przez zamawiającego wskazane, ale to
wykonawcy muszą wskazać sposób jego implementacji, bo są różne rozwiązania na rynku.
Wymaganie 8.2.poz. 57 – zamawiający wskazał skończoną listę wymaganych
predefiniowanych formatów dla eksportu i importu danych, przekazanie specyfikacji ze
względu na ich ciągły rozwój na obecnym etapie nie wydaje się zasadne, a poza tym są one
ogólnie dostępne i wykonawca jest w stanie skalkulować zakres prac.
Wymaganie 8.3.poz. 58 – zamawiający wskazał skończoną listę wymaganych formatów dla
eksportu i importu, ale rozwiązania dostępne na rynku oferują różne formaty dla różnych
typów danych, stąd wykonawca po konsultacji z zamawiający przyporządkuje dostępne
formaty do poszczególnych typów danych,

Wymaganie 8.5.poz.60 – zamawiający wskazał, że wymagane przez niego funkcjonalności
są dostępne na rynku, ale różnie implementowane, zatem zamawiający wskazał parametry,
które muszą być bezwzględnie dostępne, a inne pozostawił do zaproponowania
wykonawcom,
Wymaganie 8.8.poz. 63 - zamawiający opisał funkcjonalność, a nie sposób jej
zaimplementowania, ponadto sprawdzanie duplikatów każdy wykonawca realizuje w inny
sposób i zamawiający oczekuje wypracowanie optymalnego rozwiązania,
Wymagania 8.9.poz. 64 i 8.13. poz. 68 – zamawiający wskazał na skończoną listę
wymaganych zleceń, ale różne rozwiązania bankowości elektronicznej oferują różne formaty
w zależności od zlecenia, wykonawca w drodze wskazań i analiz powinien przyporządkować
dostępne formaty do poszczególnych typów zleceń,
Wymaganie 11.2 poz. 82 – zamawiający opisał funkcjonalność, ale nie sposób jej
implementacji, lista możliwych akcji jest zależna od specyfiki systemów bankowych i dopiero
na etapie analizy wykonawca pozna tę specyfikę, stad dopiero wówczas będzie w stanie
określić optymalną listę akcji dla poszczególnych statusów.
Wymaganie 12.10. poz. 98 – powiadomienia o zdarzeniach – jak wyżej,
Wymaganie 14.1. poz. 108 – zamawiający wskazał skończoną listę wymagań do konfiguracji
wyglądu systemu, bank nie jest w stanie dookreślić, które pola mogą być prezentowane w
walucie domyślnej, a które w oryginalnej – tak drobny element nie może oznaczać
niemożności sporządzenia oferty i skalkulowania wynagrodzenia.
Wymaganie 14.3. poz. 110 i 14.5 poz. 112, 18.11 poz. 168 – struktura danych
prezentowanych na ekranie w różnych systemach różni się, ostateczna struktura zostanie
uzgodniona na etapie analizy. Może się okazać, że niektóre dane nie mogą być
prezentowane użytkownikowi, albo muszą być prezentowane w szczegółach, a nie na liście
danych, zatem wskazywanie na obecnym etapie danych po których będzie się filtrować lub
do których będą przypisane akcje może się okazać bezcelowe.
Wymaganie 14.7. poz. 114 – zamawiający wskazał skończoną listę ułatwień pozwalających
na przyśpieszenie pracy i zmniejszenie ryzyka błędów, szczegółowe jednak dane, które będą
zbierane w formatkach o przekazywane do systemów zostaną określone wspólnie z
wykonawcą na etapie analizy.
Wymaganie 15.10. poz. 128 – zamawiający opisał funkcjonalność, a nie sposób jej
implementacji. Lista możliwych uprawnień będzie zależna od struktury menu, układu danych
na ekranie, sposobu implementacji poszczególnych operacji, listy dostępnych akcji.
Wymaganie 16.16. poz. 145 – wymaganie dotyczy szczegółów integracyjnych, które muszą
zostać określone na etapie analizy, tylko wykonawca wie jak powinna wyglądać integracja z
jego systemem, który oferuje.

Wymaganie 16.19. poz. 148 – zamawiający uważa, ze wskazał maksymalnie precyzyjne
wymagania co do raportów ze statystykami. Określenie bardziej precyzyjne nie jest możliwe,
z uwagi na różną strukturę danych i różny zakres dostępnych informacji w poszczególnych
systemach bankowości elektronicznej. Zamawiający określił wymagania, co do ilości
szablonów raportów, co pozwala wykonawcy na oszacowanie pracochłonności,
Wymaganie 19.1 poz. 176 – jest to jedynie podtytuł rozdziału 19 wymagań funkcjonalnych
„Lokaty” zestaw wymagań dla lokat znajduje się w wierszach poniżej od 19. 2- 19.5 i
określają one precyzyjnie wymagania dla tego obszaru.
Wymaganie 19.15. poz.190 – parametry podlegające edycji zależą od konkretnego typu
produktu, a obecnie nie są znane produkty jakie będą dostępne w BE i dlatego należy je
ustalić na etapie analizy.
Wymaganie 20.4. poz. 195 – to wymaganie dotyczy jedynie prezentacji danych, zakres
prezentowanych danych, według zamawiającego nie ma znaczenia dla pracochłonności.
Wymaganie 21.5. poz. 217 – wymaganie to oznacza, że wykonawca ma zapewnić
odpowiedni mechanizm, kwestią wtórną jest zakres danych w pliku i format pliku. Dane są
dostępne w systemie.
Wymaganie 23.2. poz. 231 – zespół pól w formatce wynika ze standardów i wymogów prawa
dotyczących transakcji Elixir i Sorbnet, a więc wymaganie nie jest otwarte, ani
niedookreślone. Do doprecyzowania pozostaje sposób obsługi danych przelewu, są to
drobne ustalenia nieuniemożliwiające sporządzenie oferty.
Wymaganie 23.3. poz. 232 - zespół pól w formatce wynika ze standardów i wymogów prawa
dotyczących transakcji np. NRB, a więc wymaganie nie jest otwarte, ani niedookreślone. Do
doprecyzowania pozostaje sposób obsługi danych przelewu, są to drobne ustalenia
nieuniemożliwiające sporządzenie oferty
Wymaganie 23.4. poz. 233 i 23.5 poz. 234, 23. 6 poz. 235– jak wyżej
Wymaganie 23.13. poz. 242 – doprecyzowania wymaga, które transakcje nie będą podlegać
autoryzacji, może to zależeć od wymogów prawa, a zatem okazać się nieaktualne na dzień
wdrożenia, są to drobne ustalenia nieuniemożliwiające sporządzenie oferty.
Wymaganie 23.21.poz. 250 – wykonawca ma przygotować mechanizm umożliwiający
modyfikację kilku przelewów w paczce, to które dane mogą tej modyfikacji podlegać jest
kwestią wtórną, sam mechanizm przy odpowiedniej parametryzacji ma umożliwić wskazanie
określonych danych.
Wymaganie 23.24. poz. 253 – wymaganie mówi jedynie o konieczności oznaczenia stanu
realizacji danego przelewu paczki, samo wskazanie listy statusów jest typowe dla okresu
analizy i nieuniemożliwiające sporządzenie oferty
Wymaganie 29.4 poz. 318 – dotyczy prezentacji w BE danych produktów Teasury. Źródłem
danych o produktach będzie szyna ESB wraz z odpowiednimi usługami. Po stronie BE

będzie mieć miejsce jedynie prezentacja udostępnionych danych a więc ich zakres nie ma
wpływu na pracochłonność,
Wymaganie 29.9 poz. 323 – wymaganie dotyczy mechanizmu pozwalającemu na złożenie
dyspozycji depozytu i automatyczne (systemowe) zaproponowanie oprocentowania,
wymaganie mówi, że ma istnieć mechanizm i jakie parametry pozwalają na ustalenie przez
system oprocentowania, uszczegółowienia wymaga ustalenie konkretnych działań
matematycznych odwzorowujących wpływ parametru na oprocentowanie
Wymaganie 30.5 poz. 330 – wymaganie opisuje konieczność zapewnienia mechanizmów
wyszukiwania, sortowania i filtrowania, aby działać mechanizmy muszą takie kryteria
obsługiwać, a kryteria są zwyczajowo ustalane na etapie analizy.
Wymaganie 31.6 poz. 343 – do uzgodnienia na etapie analizy pozostaje algorytm domyślny,
co według zamawiającego nie wpływa na pracochłonność,
Wymaganie 32.1 poz. 345 – wiersz jest podtytułem pkt 32 wymagań funkcjonalnych obsługa
gotówkowa i informuje o tym, że obsługa ta będzie się znajdować w innych systemach niż
BE, szczegóły wymagań obsługi gotówkowej określają pkt 32.1- 11. Zapoznanie się ze
specyfiką systemów bankowych następuje na etapie analizy, stąd postawione wymaganie.
Podsumowując zamawiający uznał, że zarzut odwołania nie jest zasadny i nie zasługuje na
uwzględnienie z uwagi na jego bezprzedmiotowość, co w ocenie zamawiającego potwierdza
wyrok Izby z dnia 3 września 2009r. sygn. akt KIO/UZP 1081/09.
W zakresie zarzutu dotyczącego kryteriów oceny ofert zamawiający uznał go za bezzasadny.
Zamawiający wskazał zakres oczekiwanych funkcjonalności z informacją, że szczegóły
implementacyjne, specyficzne dla poszczególnych rozwiązań zostaną ustalone na etapie
analizy, co jest zgodnie ze stosowaną na rynku praktyką wdrożeniową systemów
informatycznych. W wielu przypadkach samo określenie pożądanej funkcji systemu BE
stanowi informację wystarczającą do stworzenia i wyceny oferty, gdyż wykonawca bazując
na swoim doświadczeniu i wiedzy jest w stanie wyszacować zakres związanej z tym pracy.
Doprecyzowania, doszczegółowienia będą wymagać szczegóły techniczne, które wynikają z
integracji całego rozwiązania dostawcy z core’owym oprogramowaniem finansowym banku i
jego wizerunkiem rynkowym.
W procesie integracji dostosowaniu podlega:
- szczegółowy zakres danych wprowadzanych w ramach wykonywania danej
funkcjonalności,
- ich proces walidacji,
- rozmieszczenie elementów ekranowych.
W procesie przygotowania oferty wykonawca sam określa, czy opisany zakres wymagań
funkcjonalnych wraz z częścią możliwą do dostosowania podczas analizy i dalej wdrożenia
jest zawarty w jego obecny rozwiązaniu na moment składania oferty i stanowi funkcjonalność

standardową. Lista wymagań jest zamknięta i ustalona i nie będzie podlegała rozszerzeniu w
trakcie prac wdrożeniowych. Odwołujący w ocenie zamawiającego nie wskazał
jakiegokolwiek uzasadnienia dlaczego widzi problem ze skonstruowaniem oferty. Ponownie
zamawiający przywołał wyrok Izby sygn. akt KIO/UZP 1081/09. Zamawiający zaprezentował
przykład dwóch formatek ZIUS różnych dostawców i wskazał, że choć pola są te same, ich
rozmieszczenie jest różne i w jednym przypadku pojawia się inny sposób wprowadzania
danych. Różnice mogą dotyczyć kolejności pól, czy sposobu wprowadzania danych przez
zastosowanie standardowych mechanizmów (pola typu check-box, rozwijana lista itp.).
Uzgodnienia w tym zakresie są dokonywane na etapie analizy, a ich doprecyzowanie
obecnie mogło paradoksalnie zwiększyć pracochłonność.
W zakresie zarzutu niedookreślenia zobowiązania dotyczącego przekazania wiedzy
zamawiający uznał zarzut za nieuzasadniony, gdyż par. 114 IPU zawiera wszystkie istotne
elementy dla określenia zakresu prac związanych z tym obowiązkiem. Wskazał, że
przekazanie wiedzy odbywa się w trojaki sposób :
- udzielanie wyjaśnień,
- uzgodnienie i przeprowadzeni szkoleń,
- udzielenie wsparcia na stanowisku pracy w wymiarze maksymalnie 15 h zegarowych
kwartalnie.
Zamawiający wskazał, że co do szkoleń to zasygnalizował wykonawcom niezbędne
minimum wymogów, dla niego najistotniejszy jest skutek w postaci przygotowania
określonych osób do pełnienia wskazanych ról. Wskazanie konkretnej ilości godzin nie jest
możliwe bo każdy z oferowanych systemów może wymagać różnego nakładu pracy i to
wykonawca najlepiej wie ile powinien przewidzieć czasu na przeszkolenie.
Co do wyjaśnień to jest to element oczywistej współpracy stron przy wdrażaniu projektu
informatycznego.
Izba pominęła argumentację zamawiającego związana z wycofanymi przez odwołującego
zarzutami.
W zakresie zarzutu naruszenia zasady równego traktowania wykonawców przez odrębne
zasady licencjonowania oprogramowania dla wykonawców, którym nie przysługują prawa
własności intelektualnej do oprogramowania – zarzut zdaniem zamawiającego nie jest oparty
na jakiejkolwiek podstawie prawnej. Zamawiający uważa, ze zasada równego traktowania
nie oznacza zasady jednakowego traktowania – tak Izba w wyroku z dnia 4 czerwca 2013r.
sygn. akt KIO 1189/13, zatem odmienności wynikające z przyczyn obiektywnych i
faktycznych oraz potrzeb zamawiającego nie mogą być uznane za przejaw nierównego
traktowania wykonawców. Określone przez zamawiającego funcjonalności musi spełniać tak
wykonawca twórca oprogramowania, jak i wykonawca, który pozyskuje oprogramowanie od
podmiotów trzecich. Wobec mnogości i różnego zakresu postanowień licencyjnych

dotyczących oprogramowania zbyt szerokie określenie warunków licencyjnych mogłoby
pozbawić niektórych wykonawców możliwości udziału w postępowaniu. Warunki mają ogólny
charakter, co jednak nie przesądza, ze węższy. Co więcej par 9 załącznika nr 3 zawiera
postanowienia wspólne dla licencji udzielanych przez oba rodzaje wykonawców. W zakresie
zarzutu dotyczącego niedoprecyzowania zobowiązań wykonawców w zakresie otwartych
definicji awarii, błędu, usterki, zamawiający stwierdził, że zdefiniował awarię w par. 1 IPU, a
odwołujący z niewiadomych przyczyn przypisuje zamawiającemu posłużenie się definicją o
treści wada polegająca na nieprawidłowym funkcjonowaniu oprogramowania, w tym
funkcjonowanie niezgodne z dokumentacją. Zamawiający uważa, że w sposób rzetelny,
staranny i wyczerpujący zdefiniował ten termin awaria. Art. 29 ust. 1 ustawy nie wymaga,żeby każdy element przedmiotu miał charakter zamknięty, gdyż wiązałoby się z ogromną
kazuistyką. Zamawiający uważa, że w analogiczny sposób zdefiniował błąd i usterkę. W
ocenie zamawiającego postulat odwołującego, że definicje spornych pojęć powinny być
ograniczone do przypadków niezgodności z dokumentacją. Nadrzędny dla zamawiającego
jest efekt prawidłowo działającego sytemu BE. Uważa, ze w trakcie realizacji projektu
wykonawca powinien być zobowiązany do usuwania wszelkich nieprawidłowości
zakłócających funkcjonowanie systemu. Zamawiający wskazał na 6 nieprawidłowości, które
w jego ocenie nie są niezgodne z dokumentacją, a powodują nieprawidłowe działanie
systemu. Analogiczne stanowisko zamawiający zajął, co do zarzutu otwartości usługi
serwisowej.

Izba ustaliła następujący stan faktyczny:
Izba dopuściła dowody z dokumentacji postępowania to jest ogłoszenia o zamówieniu
publicznym i specyfikacji istotnych warunków zamówienia wraz z załącznikami.
Na podstawie tych dowodów Izba ustaliła, że:
W rozdziale XVI. KRYTERIA OCENY OFERT ORAZ ICH ZNACZENIE, zamawiający określił
następujące wymagania kryteria oceny ofert: cena rozumiana jako łączny całkowity koszt
elementów zamówienia, podanych w kwocie brutto złotych polskich, wskazanych w
FORMULARZU CENOWYM- waga 60%, funkcjonalność – waga 40%
W pkt. XVI. 4. Siwz Kryterium funkcjonalność, oceniane miało być wg następujących zasad:
1) Ocena oferty wg niniejszego kryterium zostanie dokonana na podstawie wypełnionego
przez Wykonawcę Załącznika nr 1 do OPZ – Wymagania funkcjonalne/formularz oceny
technicznej. Za każdą istniejącą funkcjonalność, która będzie wskazana przez Wykonawcę
jako Standardowa, Zamawiający przyzna liczbę punktów równą Wadze przypisanej do tej
funkcjonalności, podanej w kolumnie E. Przykładowo: jeżeli dana funkcjonalność została
wskazana przez Wykonawcę jako Standardowa, a jej Waga określona w kolumnie E równa
jest 2 to Zamawiający przyzna 2 punkty za tą funkcjonalność. Przyznane punkty za każdą z

funkcjonalności zawarte będą w kolumnie F. Suma punktów w kolumnie F „Punkty” będzie
określała ocenę za funkcjonalność dla danej Oferty.
2) Zamawiający nie będzie przyznawał punktów za funkcjonalności określane jako
Dedykowane.
3) Zamawiający wymaga, aby w ramach oferowanego rozwiązania Wykonawca zaoferował
co najmniej 70% liczby funkcjonalności określanej jako Standardowa z sumarycznej liczby
funkcjonalności zawartej w Załączniku nr 1 do OPZ – Wymagania funkcjonalne/formularz
oceny technicznej. W przypadku nie osiągnięcia wyżej wymienionego poziomu ilościowego
dla funkcjonalności Standardowej, oferta Wykonawcy będzie podlegała odrzuceniu ze
względu na jej niezgodność z treścią SIWZ.
4) Zamawiający zastrzega, że w przypadku podania przez Wykonawcę w formularzu oceny
technicznej Załącznika nr 1 do OPZ – Wymagania funkcjonalne nieprawdziwych informacji w
zakresie funkcjonalności deklarowanych jako Standardowe, uprawniać to będzie
Zamawiającego do uchylenia się od skutków prawnych złożonego przez siebie oświadczenia
woli, na podstawie art. 86 Par. 1 k.c., w związku z wykryciem błędu, który podstępnie
wywołał Wykonawca.
W załączniku nr 1 do siwz Opis Przedmiotu Zamówienia zamawiający w zakresie sporny
zawarł następujące postanowienia:
W pkt I. Przedmiotem Zamówienia jest dostarczenie, wdrożenie i świadczenie usług
gwarancyjnych i serwisowych dla Banku Gospodarstwa Krajowego (zwany również Bankiem
lub BGK) aplikacji bankowości internetowej (zwanej dalej: BE) wraz z rozwiązaniem do
administracji/obsługi funkcjonalności aplikacji bankowości internetowej (zwany dalej:
Konsolą). Całe rozwiązanie, czyli łącznie BE i Konsola, są zwane dalej SystemBE zgodnie z
definicją w Istotnych Postanowieniach Umowy. Rozwiązanie będzie przeznaczone do obsługi
klientów instytucjonalnych Banku (zwanych dalej: Klientami) przez osoby fizyczne (zwane
dalej: Użytkownikami), umocowane do korzystania z BE na podstawie pełnomocnictwa lub
upoważnienia. Użytkownicy będą korzystać z BE. Z Konsoli natomiast będą korzystać
pracownicy Banku (zwani dalej: Pracownicy).
4. Udzielenie licencji dla Oprogramowania Standardowego i Pomocniczego na nielimitowaną
liczbę użytkowników SystemuBE (w szczególności Klientów i Użytkowników) oraz na
swobodne tworzenie dowolnej ilości instancji testowych i rozwojowych, z wyłączeniem
zakupu licencji firm trzecich;
5. Przeniesienie autorskich praw majątkowych na Zamawiającego i zezwolenie na
wykonywanie zależnego prawa autorskiego do SystemuBE, w tym do Oprogramowania i
Dokumentacji w zakresie niezbędnym do samodzielnego rozwoju dostarczonego
rozwiązania na zasadach określonych w Załączniku 3 do Istotnych Postanowień Umowy;

7. Szata graficzna zostanie przygotowana zgodnie ze standardami określonymi w Księdze
Identyfikacji Wizualnej Banku Gospodarstwa Krajowego, przekazanej przez Bank
Wykonawcy na etapie analizy:
8. Przygotowanie i przekazanie przez Wykonawcę do akceptacji Banku projektu szaty
graficznej BE i Konsoli, a po zaakceptowaniu, modyfikacji wyglądu BE i Konsoli zgodnie z
projektem. Szata graficzna zostanie przygotowana zgodnie ze standardami określonymi w
Księdze Identyfikacji Wizualnej Banku Gospodarstwa Krajowego, przekazanej przez Bank
Wykonawcy na etapie analizy;
10. Przeprowadzenie szkoleń dla maksymalnie 20 pracowników Banku z zakresu zagadnień
biznesowych, technicznych, bezpieczeństwa, rozwoju, które będą niezbędne do
prawidłowego działania i eksploatacji SystemuBE;
12. Świadczenie usług Rozwoju i Walidacji w stosunku do dostarczonego SystemuBE na
warunkach opisanych w Istotnych Postanowieniach Umowy.
III. Wymagania funkcjonalne
3. Wykonawca zobowiązany jest do wykonania wszystkich funkcjonalności określonych w
Załączniku nr 1 do OPZ – Wymagania funkcjonalne / Formularz oceny technicznej, przy
czym dopuszcza się sytuację, w której część funkcjonalności nie jest standardową
funkcjonalnością oferowanego Oprogramowania i wymaga się od Wykonawcy wykonania
Oprogramowania Dedykowanego dla Banku, które pokryje wymaganą funkcjonalność.
4. Wykonawca zobowiązany jest do wskazania w Wymaganiach funkcjonalnych / Formularzu
oceny technicznej w kolumnie D czy:
1) dana funkcjonalność jest standardowa w ramach oferowanego rozwiązania (S -
Standardowa). Funkcjonalność uznaje się za standardową, gdy:
a. oferowany SystemBE posiada wymaganą funkcjonalność na dzień składania Oferty;
b. oferowany SystemBE posiada wymaganą funkcjonalność na dzień składania Oferty, ale
wymagana jest jej parametryzacja, aby dostosować ją do wymagań Zamawiającego;
2) dana funkcjonalność wymaga modyfikacji oferowanego rozwiązania - wymaga prac
rozwojowych (D - Dedykowana).
5. Brak zaoferowania w Ofercie którejkolwiek z funkcjonalności skutkować będzie
odrzuceniem Oferty ze względu na jej niezgodność z treścią SIWZ.
6. Na potrzeby oceny ofert, za każdą funkcjonalność, która będzie wskazana przez
Wykonawcę jako Standardowa w ramach oferowanego rozwiązania (tj. dostępna w
oferowanym rozwiązaniu na dzień składania Oferty), Zamawiający przyzna liczbę punktów
równą Wadze przypisanej do tej funkcjonalności w Załączniku nr 1 do OPZ – Wymagania
funkcjonalne / Formularz oceny technicznej, podanej w kolumnie E (np. jeżeli dana
funkcjonalność została wskazana przez Wykonawcę jako Standardowa, a jej Waga
określona w kolumnie E to 2, Zamawiający przyzna 2 punkty za tą funkcjonalność).

Przyznane punkty za każdą z funkcjonalności zawierać będzie kolumna F. Suma punktów w
kolumnie F (Punkty) będzie odpowiadała ocenie za funkcjonalność dla danej Oferty.
Zamawiający nie będzie przyznawał punktów za funkcjonalności określone jako
Dedykowane.
7. Zamawiający wymaga, aby w ramach oferowanego rozwiązania Wykonawca zaoferował
co najmniej 70% liczby funkcjonalności określanej jako Standardowa z sumarycznej liczby
funkcjonalności zawartej w Załączniku nr 1 do OPZ – Wymagania funkcjonalne/formularz
oceny technicznej. W przypadku nie osiągnięcia wyżej wymienionego poziomu ilościowego
dla funkcjonalności Standardowej oferta Wykonawcy będzie podlegała odrzuceniu ze
względu na jej niezgodność z treścią SIWZ.
8. Zasady wypełniania Formularza oceny technicznej:
1) W przypadku, gdy Wykonawca oceni, że oferowany SystemBE standardowo spełnia daną
funkcjonalność, Wykonawca w kolumnie "Standardowa/Dedykowana", wpisuje literę ”S”,
2) W przypadku, gdy Wykonawca oceni, że oferowany SystemBE nie spełnia standardowo
danej funkcjonalności, Wykonawca w kolumnie "Standardowa/Dedykowana", wpisuje literę
”D”,
3) Brak zapisu w kolumnie „Standardowa/Dedykowana" przy jakiejkolwiek funkcjonalności
powoduje odrzucenie oferty.
VI. Wymagania w zakresie technologii informatycznej
10. Obowiązki wykonawcy modyfikacji w kontekście budowania paczek produkcyjnych oraz
oznaczania wersji w repozytorium zostaną uszczegółowione na etapie analizy.
12. SystemBE musi pozwalać na jego dalszą rozbudowę przez Zamawiającego poprzez:
1) Rozbudowę polegającą na dołączeniu nowych lub zamianie istniejących integrowanych z
Systemem BE systemów źródłowych bez ingerencji w strukturę źródeł zasilających i
konieczności rozbudowy procesów zasilających adekwatnych źródeł danych;
2) Rozszerzanie zawartości informacyjnej struktur SystemuBE i adekwatną rozbudowę
procesów zasilających źródeł danych;
3) Swobodne korzystanie z udostępnionych przez SystemBE usług (API).
22. Wykonawca musi zapewnić wydajność (szybkość odpowiedzi) SystemuBE (zarówno w
warstwie aplikacyjnej jak i API) pozwalającą na obsługę poniższych wielkości biznesowych:
1) Liczba Klientów z aktywnym dostępem do BE – 5000;
2) Liczba Użytkowników z aktywnym dostępem do BE – 25000;
3) Maksymalna liczba jednoczesnych sesji Użytkowników – 1000;
4) Liczba Pracowników mających aktywny dostęp do Konsoli – 50;
5) Maksymalna liczba jednocześnie pracujących Pracowników w Konsoli – 25;
6) Maksymalna liczba przelewów wychodzących do innych banków na dzień – 100000;
7) Maksymalna liczba przelewów wychodzących do innych banków na godzinę – 50000;

8) Maksymalna wielkość paczki przelewów (liczba przelewów w jednej paczce) – 5000;
9) Maksymalna liczba uruchomionych procesów wydruków na sekundę w BE –50;
10) Maksymalna liczba operacji typu odczyt (np. sprawdzenie salda, sprawdzenie historii
rachunku) na sekundę z BE – 130;
11) Maksymalna liczba operacji aktywnych (np. wykonanie pojedynczego przelewu,
założenie lokaty) na sekundę z BE – 80;
12) Narzut czasu przeznaczonego na przetworzenie zapytania (komunikatu) wysłanego
przez użytkownika ze stacji końcowej, nakładanego przez SystemBE nie może być większy
niż 1 sekunda, przy czym dopuszcza się realizację 5% zapytań Użytkowników w czasie
powyżej 1 sekundy, ale nie dłużej niż 30 sekund. Dopuszcza się również realizację zapytań
w czasie przekraczającym 7 sekund, jeżeli są realizowane w trybie asynchronicznym z
kontrolą listy zapytań oczekujących na odpowiedź przed uruchomieniem drugiego tego
samego typu zapytania przez jednego Użytkownika. Do czasu przetworzenia zapytania nie
będzie wliczany czas na przesłanie informacji od klienta do serwera, o ile Wykonawca
zapewni Zamawiającemu uzyskanie informacji o rzeczywistym i statystycznym czasie
transmisji pomiędzy klientem i serwerem,
13) Czas zapisania/zatwierdzenia pojedynczego polecenia przelewu - maksymalnie 2
sekundy (w opcji przeznaczonej dla pojedynczego zlecenia przelewu),
14) Czas zapisania/zatwierdzenia paczki zawierającej 1000 pozycji - maksymalnie 10
sekund,
15) Czas udostępnienia listy produktów zawierających 10 pozycji - maksymalnie 2 sekundy.
23. Osiągnięcie maksymalnych wartości biznesowych zdefiniowanych w punkcie 22 musi być
możliwe wyłącznie poprzez rozbudowę Infrastruktury z uwzględnieniem rezerw określonych
w punkcie 24.
26. Wykonawca musi zaimplementować w rozwiązaniu mechanizmy zapewnienia jakości
danych. W szczególności wymaga się zaprojektowania i przygotowania raportów
kontrolnych, których przedmiotem będą co najmniej:
1) kontrola poprawności danych wysyłanych/zasilanych z/do SystemuBE;
2) kontrola spójności danych w SystemieBE;
3) kontrola jakości danych w wybranych obszarach SystemuBE według przygotowanych
przez Bank reguł;
4) inne reguły sprawdzające wynikające z doświadczenia Wykonawcy i najlepszych praktyk
w tym zakresie;
5) usługi umożliwiające korzystanie z centralnych kartotek klientów.
W pkt. VIII.2 str. 22 OPZ - Specyfikacja istniejących usług wraz z informacjami dotyczącymi
bezpieczeństwa zostanie udostępniona wykonawcy na etapie analizy. Podczas etapu analizy
zostaną również ustalone szczegóły dotyczące rozszerzenia listy usług szyny ESB.

W pkt XI.1 str. 27 OPZ - SystemBE musi posiadać opcje obsługi żądań Web Service i/lub
JMS z użyciem mechanizmów autentykacji, przy czym Zamawiający dopuszcza autentykacje
na warstwie transportowej - wymaganie zostanie uszczegółowione na etanie analizy.
W pkt XI.6.18 str. 29 OPZ - zapewni możliwość przesyłania logów do SIEM (z
wykorzystaniem standardowych mechanizmów ustalonych na etapie analizy)
Na str. 38-39 OPZ B. Szkolenia
1. Wykonawca zobowiązany jest do realizacji szkoleń, które przygotują Pracowników
Zamawiającego do prowadzenia samodzielnych prac administracyjnych i
Strona 39 z 39
rozwojowych SystemuBE będącego przedmiotem zamówienia. Celem szkoleń jest w
szczególności:
1) merytoryczne przygotowanie pracowników Zamawiającego do samodzielnej realizacji
zadań administracyjnych i rozwojowych;
2) przekazanie pracownikom Zamawiającego wiedzy oraz umiejętności korzystania z
oferowanego rozwiązania.
2. W ramach szkolenia Wykonawca przygotuje i dostarczy niezbędne materiały szkoleniowe
(niezbędną dokumentację szkoleniową) składające się, z co najmniej prezentacji
szkoleniowej oraz podręcznika3. Zamawiający zakłada przeszkolenie w zakresie
przewidzianym dla danej funkcji następujących osób:
1) Administratorzy biznesowi;
2) Administratorzy techniczni;
3) Administratorzy ds. bezpieczeństwa;
4) Osoby odpowiedzialne za rozwój;
na zasadach opisanych w Załączniku nr 2 do SIWZ – Istotne Postanowienia Umowy.
Wymagania funkcjonalne zał. Nr 1 do OPZ: 2.2 poz.11 - SystemBE musi umożliwić
prezentację danych Klientów i ich produktów w trybie offline, które są prezentowane w BE w
trybie online. Zakres danych dostępnych w trybie offline zostanie ustalony na etapie analizy.
Wymagania funkcjonalne 4.13 poz. 32- SystemBE musi zapewnić mechanizm czasowego
blokowania adresów IP, spod których wykryto nadmierny ruch lub próby ataku. Szczegółowe
wymagania zostaną ustalone na etapie analizy.
Wymagania funkcjonalne 8.2 poz. 57 - BE musi obsługiwać predefiniowane formaty
minimum: Elixir, VideoTel, MultiCash, MT940, MT103, Płatnik. Specyfikacje wymaganych
formatów zostaną dostarczone przez BGK na etapie analizy.
Wymagania funkcjonalne 8.3 poz.58 - BE musi zapewnić możliwość definiowania przez
Użytkownika nowych szablonów importu/eksportu opartych o format:
-
liniowy (TXT)
-
CSV,

-
XLS,
-
XML,
-
PDF (tylko dla eksportu).
Ostateczny zakres dostępnych formatów dla poszczególnych typów danych dostępnych w
SystemieBE zostanie ustalony na etapie analizy.
Wymagania funkcjonalne 8.5 poz.60 - BE musi zapewnić możliwość dodania
nowego/modyfikacji istniejącego szablonu poprzez:
-
wybór rodzaju szablonu (np. rodzaj przelewu, dane kontrahentów),
-
wprowadzenie nazwy szablonu,
-
określenie separatora danych (np.”.”lub”;” lub " |" lub "#"),
-
określenie strony kodowej (np.Windows-1250, UTF-8),
-
określenie separatora dziesiętnego (np. „,” lub „.”)
-
określenie formatu i separatora daty (np. "rr-mm-dd" i „-„)
-
możliwość wyboru opcjonalnie nazw pól w nagłówku,
-
możliwość określenia nagłówka i stopki w szablonie,
-
określenie znaków dozwolonych (np. alfanumeryczne oraz ( ).,/:;\+!@#$&*{}[]?='") i
niedozwolonych (np. ‘&’, ‘<’, ‘˃’),
-określenie pól obowiązkowych/nieobowiązkowych,
-
inne parametry określone na etapie analizy.
Należy również umożliwić wybór, które pola maja być importowane z listy dostępnych pól dla
danego rodzaju szablonu.
Wymagania funkcjonalne 8.8 poz.63 - SystemBE musi zapewnić możliwość weryfikacji
struktury pliku i sprawdzenia importowanych danych czy są zgodne z wybranym szablonem.
Musi być także możliwość sprawdzenia duplikatów w importowanym pliku po zdefiniowanych
na etacie analizy danych. BE musi prezentować rezultat sprawdzenia np.: wiersze
prawidłowe, wiersze błędne zaznaczone na czerwono oraz podsumowanie np. liczba
wczytanych wierszy z podziałem na rodzaje przelewów, kwota przelewów. Musi być
informacja o numerze linii, która jest błędna. Musi być możliwość zaimportowania danych
tylko prawidłowych lub anulowania całego importu danych.
Wymagania funkcjonalne 8.9 poz.64 - BE musi zapewnić możliwość importu zleceń/danych:
kontrahenci (wszystkie typy), przelewy (wszystkie rodzaje, w tym paczki przelewów),
polecenia zapłaty, zlecenie wypłat depozytów sądowych i gotówki oraz inne, które zostały
wskazane w poszczególnych sekcjach tego dokumentu. Na etapie analizy zostanie
określone, które formaty plików będą dostępne dla poszczególnych zleceń. Dane w plikach
muszą być walidowane (np. NRB, REGON, PESEL, NIP, data, kwota).
Wymagania funkcjonalne 8.13 poz.68 - SystemBE musi zapewnić możliwość eksportu
zleceń/danych: kontrahenci (wszystkie typy), przelewy (wszystkie rodzaje, w tym paczki

przelewów), polecenia zapłaty, kody operacji, wyciągi, raport depozytów sądowych, operacje
na rachunkach wirtualnych, zlecenia wypłat gotówkowych, wpłaty zamknięte oraz inne, które
zostały wskazane w poszczególnych sekcjach tego dokumentu. Na etacie analizy zostanie
określone, które formaty plików będą dostępne dla poszczególnych zleceń. BE musi mieć
także możliwość eksportu udostępnionych w BE słowników (np. kalendarz dni wolnych, banki
krajowe).
Wymagania funkcjonalne 10.1 poz.77 - Słowniki muszą się znajdować w SystemieBE.
Słowniki zdefiniowane w SB będą zasilane przez ESB. Słowniki dedykowane dla SystemuBE
nie będą zasilane przez ESB i należy zapewnić ich aktualizacje w SystemieBE. Część
słowników zostanie również udostępniona na formatkach operacji. Po każdej synchronizacji
danego słownika, nowe wartości będą również widoczne na odpowiedniej formatce.
Ostateczna lista słowników do ustalenia na etacie analizy.
Wymagania funkcjonalne 11.2 poz.82 - BE musi zapewnić funkcjonalność pozwalającą na
procesowanie każdej operacji finansowej/niefinansowej. Procesowanie będzie polegało na
oznaczeniu stanu realizacji danej operacji poprzez odpowiedni status. Wszystkie operacje po
zatwierdzeniu są obsługiwane w SB. Przed ostatecznym zatwierdzeniem operacja będzie
przechodziła pomiędzy różnymi akcjami wykonywanymi przez Użytkowników. Akcje te będą
wykonywane na poziomie BE bez odzwierciedlenia w systemach Banku. Kompletna lista
statusów i przejść pomiędzy nimi zostanie ustalona na etapie analizy, np.: wprowadzony, w
trakcie akceptacji, podpisany, usunięty.
Przykładowa lista akcji na dyspozycjach:
-
akceptuj razem - możliwość autoryzacji kilku operacji jednocześnie,
-
akceptuj pojedynczo - akceptacja każdej operacji oddzielnie,
-
przekaż - przekazanie do realizacji,
-
wycofaj - wycofanie autoryzacji,
-
usuń - usunięcie dyspozycji,
-
kopiuj - stworzenie drugiej takiej samej dyspozycji z możliwością edycji.
Ostateczna lista możliwych akcji na poszczególnych statusach zostanie ustalona na etacie
analizy.
Wymagania funkcjonalne 12.10 poz.98 - powiadomienia będą aktywowane samodzielnie
przez Użytkownika. Użytkownik będzie wskazywał sposób powiadamiania (SMS, e-mail).
Lista zdarzeń zostanie zdefiniowana na etapie analizy.
Wymagania funkcjonalne 14.1 poz. 108 - informacje oraz wygląd BE będą konfigurowalne
przez Użytkownika, w szczególności musi istnieć możliwość:
1.
dodawania, edycji i usuwania skrótów, które skracają obsługę niektórych
funkcjonalności, np. zlecenie przelewu, założenie lokaty,

2.
ustawienia informacji dostępnych na ekranie z widokiem wszystkich produktów (widok
360) - jakie produkty Użytkownik chce widzieć i w jakiej kolejności. Możliwość ustawienia
liczby rekordów na jednej stronie,
3.
udostępnienia Użytkownikowi funkcji kalendarza, w którym będzie można planować
płatności, zdarzenia, wprowadzać notatki i ustawiać przypomnienia, również dla innych
Użytkowników w ramach kontekstu tego samego Klienta,
4.
ustawienia parametrów dotyczących wyszukiwania takich jak liczba wyświetlanych
rekordów na stronie oraz parametrów wyświetlania (zegar 12h/24h, format wyświetlania i
separator daty, separator dziesiętny, itp.),
5.
przywracania wartości domyślnych sparametryzowanych wcześniej przez
Użytkownika. BE powróci do globalnych standardowych ustawień domyślnych, które
definiuje Bank,
6.
ustawienie domyślnej waluty, w której będą prezentowane wszystkie kwoty. Jeżeli
dana operacja lub waluta produktu jest w innej walucie niż waluta domyślna, to na ekranie
będą prezentowane kwoty w obu walutach. Na etacie analizy zostaną ustalone pola i kursy
przeliczeniowe, które będą prezentowane walucie domyślnej.
7.
ustawienia rachunku domyślnego, który będzie prezentowany jako pierwszy na
listach, np. wybór rachunku z listy w trakcie składania przelewu, na liście rachunków,
Wymagania funkcjonalne 14.3 poz.110 - BE musi umożliwiać samodzielne budowanie filtrów
przez Użytkowników w kontekście Klienta do wyszukiwania danych na ekranach. Dane, po
których będzie możliwość filtrowania zostaną określone na etapie analizy. Możliwość
zapisywania własnych filtrów wg: typu operacji, tekstu w typie operacji, nazwie
nadawcy/odbiorcy, cyfr w NRB, numeru referencyjnego (cały lub fragment), kwocie (od/do) -
każdy filtr z unikalną nazwą (max 35 znaków).
Wymagania funkcjonalne 14.5 poz.112 - należy udostępnić w BE i w Konsoli tzw. szybkie
akcje, np.: kliknięcie na Dole saldo otwiera ekran historii operacji. Obszary i linkowanie
zostanie ustalone na etacie analizy.
Wymagania funkcjonalne 14.7 poz.114 - muszą zostać wdrożone ułatwienia w BE i Konsoli
pozwalające na przyspieszenie pracy i zmniejszenie ryzyka błędów:
1.
wybór dat z kalendarza,
2.
walidacja w czasie rzeczywistym i po wysyłce pól, np. data, kwota. PESEL REGON,
NRB. Wszystkie pola, w których będzie możliwa walidacja na ekranie zostaną ustalone na
etapie analizy.
3.
wskaźnik obrazujący na jakim etapie (kroku) składania dyspozycji jest
Użytkownik/Pracownik,
4.
oznaczenie wyniku operacji kolorem, np.: zielony wynik pozytywny, a czerwony wynik
negatywny,

5.
oznaczenie statusów dyspozycji kolorem lub/i ikonkami,
6.
czytelne informacje zwrotne, tak aby Użytkownik/Pracownik w każdej chwili wiedział
co się dzieje w aplikacji z uruchomioną funkcją,
7.
pytanie Użytkownika/Pracownika o potwierdzenie wykonania akcji prowadzących do
nieodwracalnych działań takich jak np, usunięcie danych,
8.
oznaczenie w BE i Konsoli na formatkach pól obowiązkowych, które muszą zostać
wypełnione, aby zlecić daną operację.
Wymagania
funkcjonalne
15.10
poz.
128
-
musi
istnieć
możliwość
przeglądania/definiowania/modyfikowania uprawnień np.:
1.
rachunki - przeglądanie, saldo i operacje bieżące, wyciągi,
2.
przelewy - przeglądanie, dodawanie, edycja, import, akceptowanie,
3.
kontrahenci - przeglądanie, dodawanie, edycja, import, usuwanie,
3.
lokaty - przeglądanie, dodawanie, edycja, akceptowanie, zrywanie,
4.
obsługa gotówkowa - przeglądanie, dodawanie, edycja, usuwanie,
5.
depozyty sądowe - przeglądanie, dodawanie, edycja, raporty,
6.
rachunek skonsolidowany - przeglądanie, generowanie raportów,
7.
konfiguracja - przeglądanie, zmiana parametrów,
8.
wnioski - przeglądanie, składanie, edycja,
9.
obsługa raportów - przeglądanie, anulowanie, usuwanie, pobieranie. Dodatkowo dla
każdego produktu, np. rachunku, uprawnienia będą przypisywane indywidualnie. Powyżej
wymienione zostały przykładowe Uprawnienia - ostateczne zostaną ustalone na etapie
analizy.
Schematy uprawnień będzie można przeglądać/tworzyć/modyfikować/usuwać w Konsoli oraz
w BE, ale z zastrzeżeniem że w BE można tylko nadawać uprawnienia maksymalnie do
poziomu który został nadany w Konsoli. Wynika z tego, że w BE można odebrać
uprawnienia, które zostały nadane w Konsoli, a później je przywrócić.
Wymagania funkcjonalne 16.16 poz.145 - musi istnieć możliwość wykonania testu
komunikacji z systemami Banku. Po wybraniu odpowiedniej opcji, pokaże się wynik testu.
Szczegóły do ustalenia na etapie analizy.
Wymagania funkcjonalne 16.19 poz.148 - musi istnieć możliwość przeglądania statystyk i
generowania raportów, m.in.:
1.
liczba i lista Użytkowników aktywnych/korzystających (min. 1 logowanie w miesiącu) z
BE z podziałem na Użytkowników biernych i z prawem podpisu,
2.
liczba i lista Użytkowników korzystających z danego narzędzia autoryzacji,
3.
liczba i lista logowań poprawnych/niepoprawnych z wyszczególnieniem adresów IP,
4.
liczba i wolumen dyspozycji z podziałem na rodzaj operacji i status. Raporty będą
generowane w plikach tekstowych z uzgodnionym separatorem pól. Raporty mogą się

generować w trybie offline. Na etapie analizy zostanie uzgodniony ostateczny zakres i liczba
raportów, ale nie więcej niż 10 szablonów.
Wymagania funkcjonalne 18.11 poz.168 - musi istnieć możliwość filtrowania po danych
transakcji np.: zakres czasowy, rodzaj operacji, wszystkie, zakres kwot, nazwa kontrahenta.
Dokładny zakres będzie ustalony na etapie analizy.
Wymagania funkcjonalne 19.1 poz.176 - Prezentacja listy i szczegółów lokat Klienta w BE.Źródłem informacji o lokatach jest ESB, na której zostaną wystawione dedykowane usługi
pobierające dane z SB. Szczegółowy zakres danych zostanie określony na etapie analizy.
Wymagania funkcjonalne 19.15 poz.190 - musi istnieć możliwość edycji wybranych
parametrów lokat (np. sposób odnowienia lokaty). Parametry podlegające edycji zostaną
uzgodnione na etapie analizy.
Wymagania funkcjonalne 20.4 poz.195 - musi mieć miejsce prezentacja listy i szczegółów
depozytów już założonych oraz dyspozycji, które czekają w SB na realizację. JS widzą tylko
swoje środki, a MF wszystkie, które otrzymało w depozyt lub zarządzanie. Numer rachunku
MF, na którym utworzony jest depozyt terminowy lub overnight, nie jest widoczny przez JS
(zarówno w Systemie jak i na wyciągu). Na ekranie muszą być prezentowane szczegóły
depozytów czynnych i zakończonych oraz dyspozycji zrealizowanych i niezrealizowanych z
podaniem powodu niezrealizowania. Zakres danych do prezentacji zostanie ustalony na
etapie analizy.
Wymagania funkcjonalne 21.5 poz.217 - należy umożliwić eksport plików z danymi np.: dane
rachunku, dane firmy, saldo przed i po konsolidacji, typ i podtyp konsolidacji, wartość
odsetek. Szczegółowy zakres danych zostanie ustalony na etapie analizy. Musi istnieć
możliwość generowania plików z danymi z pojedynczego/wszystkich rachunków biorących
udział w danym schemacie konsolidacji.
Wymagania funkcjonalne 23.2 poz.231 Przelew zewnętrzny - w BE należy udostępnić
formatkę, na której Użytkownik będzie podawał:
-
dane odbiorcy (np. rachunek w formacie NRB, nazwę i adres),
-
dane nadawcy (np. rachunek w formacie NRB, który będzie można wybrać z listy),
-
szczegóły przelewu (np. kwota, tytuł, data realizacji, waluta tylko w PLN).
Ostateczny zakres pól na ekranie zostanie doprecyzowany na etapie analizy. Formatka musi
być zgodna z wymaganiami ELIXIR, tzn. zawierać odpowiednie pola i walidować ich
zawartość (np. pole z numerem NRB). Poprzez Elixir realizowane są przelewy poniżej kwoty
1 mln zł, przy czym przekroczenie tego progu będzie kontrolował SB.
Musi być możliwość wykonania przelewu zewnętrznego z datą bieżącą i przyszłą.
Dodatkowo w trakcie zlecania przelewu należy na formatce umożliwić:
-
utworzenie nowego zlecenia stałego,

-
zaznaczenie możliwości realizacji przelewu w trybie sorbnet bez względu na
kwotę/jako przelew natychmiastowy (np. checkbox).
Wymagania funkcjonalne 23.3 poz.232 Przelew własny (pomiędzy rachunkami jednego
Klienta) - w BE należy udostępnić formatkę, na której Użytkownik będzie mógł:
-
wybrać z listy rachunki nadawcy i odbiorcy należące do jednego Klienta, w kontekście
którego pracuje Użytkownik,
-
podać szczegóły przelewu (np. kwota, tytuł, data realizacji).
Ostateczny zakres pól na ekranie zostanie doprecyzowany na etapie analizy. Formatka
jednak musi być zgodna z wymaganiami ELIXIR, tzn. zawierać odpowiednie pola i walidować
ich zawartość (np. pole z numerem NRB).
Przelew własny może zostać zlecony pomiędzy rachunkami w różnych walutach. Wtedy na
formatce muszą pojawić się dodatkowe pola związane z przewalutowaniem (np. kwota w
walucie rachunku nadawcy i odbiorcy, kurs waluty do przeliczenia kwoty). Mechanizm
przeliczania kwot w różnych walutach zostanie zrealizowany po stronie BE.
Przelew można wykonać z datą bieżącą i przyszłą. Dodatkowo w trakcie zlecania przelewu
na formatce musi być możliwość utworzenia nowego zlecenia stałego.
Wymagania funkcjonalne 23.4 poz.233 Przelew do ZUS - w BE należy udostępnić formatkę
przelewu do Zakładu Ubezpieczeń Społecznych, na której Użytkownik będzie mógł:
-
podać szczegóły przelewu (np. typ wpłaty, numer deklaracji),
-
podać dane płatnika (np. nazwa, NIP, typ i wartość identyfikatora uzupełniającego),
-
zaznaczyć realizację wszystkich składek z podaniem kwoty na jednej formatce bez
potrzeby podawania numeru rachunku, który będzie się podstawiał automatycznie w
zależności od rodzaju składki: dla: Funduszu Pracy i Fun.GW.ŚW.PRAC, Ubezpieczenie
Zdrowotne, Ubezpieczenie Społeczne, Fundusz Emerytur Pomostowych. Wtedy jest
wykonywanych tyle przelewów ile zostało zaznaczonych składek. Autoryzacja przelewu
następuje tylko jeden raz.
Ostateczny zakres pól na ekranie zostanie doprecyzowany na etapie analizy. Formatka musi
być zgodna ze standardami w zakresie KIR i ZUS, tzn. zawierać wymagane pola oraz
walidować ich zawartość zgodnie z regułami wypełniania przelewów do ZUS. Chodzi o
zawartość pól takich jak np.: NIP, wartość identyfikatora, numer deklaracji. Na formatce
muszą być również udostępnione słowniki np.: typ identyfikatora uzupełniającego, typ wpłaty.
Musi być zapewniona możliwość wykonania przelewu z datą bieżącą i przyszłą.
Wymagania funkcjonalne 23.5 poz.234 Przelew podatku - w BE należy udostępnić formatkę
przelewu podatku do Urzędu skarbowego/innego organu podatkowego, na której Użytkownik
będzie mógł:
-
wpisać numer rachunku, nazwę i adres Urzędu skarbowego/organu podatkowego lub
wybrać z listy/wyszukać (po nazwie, NRB, adresie) Urząd skarbowy, wtedy jego dane

podstawią się automatycznie do formatki. Słownik urzędów skarbowych udostępni BGK z
bazy KIR,
-
podać szczegóły przelewu (np. symbol formularza lub płatności, identyfikator
zobowiązania, okres),
-
podać dane płatnika (np. nazwa, numer identyfikatora).
Ostateczny zakres pól na ekranie zostanie doprecyzowany na etapie analizy. Formatka musi
być zgodna ze standardami dot. przelewów podatków, tzn. zawierać wymagane pola oraz
walidować ich zawartość zgodnie z regułami wypełniania przelewów podatkowych. Chodzi o
zawartość pól takich jak np.: NIP, Pesel, Regon, okres. Na formatce muszą być również
udostępnione słowniki np.: typ identyfikatora, typ okresu, symbol formularza.
Musi być zapewniona możliwość wykonania przelewu z datą bieżącą i przyszłą.
Wymagania funkcjonalne 23.6 poz.235 Przelew SWIFT/SEPA/TARGET2 - w BE należy
udostępnić formatkę (lub formatki dla każdego typu przelewu, w zależności od
wypracowanego na etapie analizy wyglądu interfejsu użytkownika), na której Użytkownik
będzie podawał dane wymagane poprzez poszczególne standardy realizacji transakcji
SWIFT/SE PA/TARG ET2, w szczególności:
-
dane Banku odbiorcy (kod BIC, nazwę i adres banku, kraj), BE musi udostępnić
słownik kodów BIC i banków zagranicznych z możliwością wyszukiwania danych banku po
kodzie BIC, kraju i nazwie. W przypadku przelewu SEPA/TARGET2 lista banków będzie
ograniczona do tych, które biorą udział w SEPA/TARGET2. Słowniki przekaże BGK,
-
dane odbiorcy (np. rachunek w formacie IBAN lub innym jeżeli kraj banku nie należy
do EOG, nazwa, adres, kraj),
-
dane nadawcy (np. rachunek w formacie NRB, który będzie można wybrać z listy,
nazwa, adres, kraj),
-
szczegóły przelewu (np. kwota, tytuł, data realizacji, wybór ze słownika kto pokrywa
koszty przelewu w przypadku SWIFT, wybór rachunku do pobrania prowizji, zastosowany
kurs wymiany walut). BE musi informować o wartości kursu, kwocie i kosztach przelewu.
Kursy walut będą pochodziły z ESB. Dodatkowo w przypadku przelewu SWIFT BE musi
umożliwiać ustawienie samodzielnie przez BGK listy walut (np. w Konsoli), w których
Użytkownicy mogą zlecać przelewy. Dla przelewów w niektórych walutach, na formatce w
BE należy pokazywać dodatkowe pola.
Ostateczny zakres pól na ekranie zostanie doprecyzowany na etapie analizy. Formatka
jednak musi być zgodna ze standardem, odpowiednio SWIFT/SEPA/TARGET2, tzn.
zawierać wymagane pola oraz walidować ich zawartość zgodnie z regułami wypełniania
przelewów zagranicznych.
Chodzi o walidacje takie jak np.: IBAN, BIC, baza banków w SEPA/TARGET2, kontrola
waluty oraz kraju banku beneficjenta zgodnie z rodzajem przelewu i daty waluty z

kalendarzem dealerskim. Musi być możliwość wykonania przelewu z datą bieżącą i
przyszłą, ale BE musi uniemożliwiać złożenie zlecenia przelewu na dni wolne od pracy i
podpowiadać następny dzień roboczy. Musi być możliwość ustawienia samodzielnie przez
Pracownika godziny Cut off time, po której przelewy będą przyjmowane na następny dzień
roboczy. BE będzie informował Użytkownika w trakcie zlecenia przelewu, że minęła godzina
COT i przelew zostanie przyjęty dnia następnego.
Wymagania funkcjonalne 23.13 poz.242 - wykonanie przelewów będzie autoryzowane
narzędziem do autoryzacji zgodnie ze schematami akceptacji dla rachunku zleceniodawcy.
Wyjątkiem są przelewy własne, które nie zawsze muszą być autoryzowane narzędziem do
autoryzacji. Musi zostać wyodrębnione uprawnienie dla rachunków dotyczące konieczności
autoryzacji narzędziem do autoryzacji przelewów własnych. Na etapie analizy ustalone
zostanie czy dla niektórych typów przelewów zostanie zdjęta konieczność autoryzacji
narzędziem autoryzacyjnym przy pozostawieniu jednak wymogów zgodności ze schematami
akceptacji.
Wymagania funkcjonalne 23.21 poz.250 - w BE należy umożliwić modyfikację szczegółów
kilku przelewów naraz w danej paczce. Dane możliwe do modyfikacji zostaną wskazane na
etapie analizy.
Wymagania funkcjonalne 23.24 poz.253 - w BE należy umożliwić oznaczenie stanu realizacji
danego przelewu/paczki poprzez odpowiedni status. Wszystkie przelewy po zatwierdzeniu
są obsługiwane w SB. Przed ostatecznym zatwierdzeniem jednak, przelew / paczka
przechodzi pomiędzy różnymi akcjami wykonywanymi przez Użytkowników. Akcje te są
wykonywane na poziomie BE bez odzwierciedlenia w SB. Kompletna lista statusów zostanie
ustalona na etapie analizy, np.: wprowadzony, w trakcie akceptacji, podpisany, usunięty.
Wymagania funkcjonalne 29.4 poz.318 - udostępnione produkty, które będą musiały być
prezentowane to np. bony skarbowe, obligacje skarbowe, komunalne, korporacyjne. Zakres
udostępnionych produktów zostanie określony na etapie analizy.
Wymagania funkcjonalne 29.9 poz.323 - musi istnieć możliwość automatycznego oferowania
preferencyjnych stawek oprocentowania i kursów walut (w tym kursów krzyżowych) w trakcie
zlecania operacji. Do liczenia kwoty, od której włącza się oferowanie preferencyjnych stawek
oprocentowania, należy wliczać także posiadane już depozyty przez Klienta, a nie tylko
kwotę zakładanego depozytu (szczegółowe ustalenia w tym zakresie na etapie analizy)
Wymagania funkcjonalne 30.5 poz.330 - w BE musi być dostępne wyszukiwanie, sortowanie
po kolumnach, filtrowanie mikrorachunków po ustalonych na etapie analizy kryteriach (np.
numer rachunku ewidencyjnego, identyfikator, waluta, data założenia). Część Klientów może
posiadać > 1 główne rachunki depozytów sądowych i BE musi umożliwiać prezentacje
pojedynczych mikrorachunków przypisanych do konkretnego głównego rachunku depozytów
sądowych.

Wymaganie funkcjonalne 31.6 poz. 343 - zakres funkcjonalności SIMP Matching, który musi
zostać udostępniony w BE:
-
tworzenie/import kontrahentów i przypisywanie do nich rachunków wirtualnych;
-
zarządzanie kontrahentami: dodawanie manualnie i poprzez import z pliku,
modyfikacja danych, zmiana przypisania rachunku wirtualnego;
-
identyfikacja oraz potwierdzenie uzgodnienia (matchingu) płatności na zasadzie
porównania danych z wpływów faktycznych, zaksięgowanych na rachunku wirtualnym
(płatności przychodzące) z bazą płatności oczekiwanych przypisanych do kontrahentów,
którą Użytkownik generuje ze swojego systemu FK i importuje w ustalonym formacie lub
wprowadza manualnie dla Kontrahenta;
-
przypisywanie do płatności statusu, który wskazuje czy została rozliczona czy nie (np.
rozliczona, nierozliczona). Użytkownik musi mieć w BE dostępną opcję importowania pliku
płatności oczekujących oraz opcję uzgodnienia płatności oczekujących z zaksięgowanymi
płatnościami przychodzącymi na rachunki wirtualne. Po wykonaniu opcji uzgodnienia,
BE musi nadać płatności odpowiedni status i prezentować go w raporcie SIMP. Użytkownik
musi mieć możliwość ręcznej zmiany statusu dla płatności;
-
algorytm przypisywania płatności przychodzących do oczekujących do uzgodnienia
na etapie analizy np.: (numer rachunku wirtualnego + kwota + tytuł płatności). Należy
umożliwić parametryzację samodzielnie przez Użytkownika tego algorytmu w BE.
Wymaganie funkcjonalne 32.1 poz. 345 - Obsługa gotówkowa będzie znajdować się w SB.
Szczegółowe wymagania zostaną określone na etapie analizy. Wymagania dla BE:)
Wymagania funkcjonalne 33.2 poz.358 - Wersja 'light' musi pozwalać zarówno na dostęp
pasywny (podgląd) jak i aktywny (składanie dyspozycji), przy czym zakres możliwych działań
będzie węższy względem wersji BE na komputery osobiste (możliwe będzie podpisanie
przelewu, przelew na rachunek własny, przelew na odbiorcę zdefiniowanego i zaufanego).
Szczegóły dotyczące zakresu funkcjonalności aplikacji w wersji light zostaną ustalone na
etapie analizy).

W załączniku nr 2 Istotne postanowienia umowne zamawiający określił:
W rozdziale I Definicje
Analiza - ogół działań obejmujący m.in.: identyfikację realnych celów strategicznych,
weryfikację obecnej struktury procesów, optymalizację struktury organizacyjnej, badanie
obiegu informacji (w tym dokumentów),funkcjonujących systemów informatycznych oraz
docelowych rozwiązań, w wyniku których otrzymuje się pełen zakres informacji niezbędnych
do efektywnego i optymalnego wdrożenia lub modyfikacji systemu informatycznego, a
przede wszystkim do podjęcia trafnej decyzji w zakresie doboru optymalnego rozwiązania

Awaria (Błąd Krytyczny) - Wada polegająca na nieprawidłowym funkcjonowaniu
Oprogramowania, w tym funkcjonowanie niezgodne z Dokumentacją, które:
(i) powoduje zawieszanie się pracy SystemuBE, lub
(ii) skutkuje techniczną niespójnością w bazie danych, lub
(iii) skutkuje zaburzeniami w integralności danych, lub
(iv) powoduje, że SystemBE w ogóle nie funkcjonuje, lub
(v) powoduje, że SystemBE nie obsługuje którejś z krytycznych funkcjonalności określonych
w Dokumentacji, lub
(vi) powoduje spadek wydajności dla co najmniej 20% liczby operacji poniżej wymaganej
wydajności, określonej w OPZ lub Dokumentacji. Spadek wydajności rozumiany jest jako
wydłużenie czasu pojedynczej wykonywanej funkcji o co najmniej 25% w stosunku do
analogicznego czasu rejestrowanego dla sprawnie działającego SystemuBE, lub
(viii) powoduje, limitowanie usług dla wszystkich lub co najmniej 10% Klientów jednocześnie,
lub
(ix) polega na zdarzeniu powtarzającym się, przy wystąpieniu nie mniej niż 5 zdarzeń w
okresie kolejnych 5 Dni Roboczych zarejestrowanych Błędów.
Błąd - niebędąca Awarią ani Usterką Wada polegająca na nieprawidłowym funkcjonowaniu
Oprogramowania SystemuBE, w tym funkcjonowanie niezgodnie z Dokumentacją,
skutkujące błędnym albo nieskutecznym wprowadzaniem, przetwarzaniem, lub
wyprowadzaniem informacji oraz każda sytuacja, w której niespełnione zostały parametry
wydajnościowe określone w OPZ lub Dokumentacji.
Oprogramowanie - programy komputerowe wchodzące w skład Systemu-BE; łącznie
rozumiane
Oprogramowanie
Standardowe,
Oprogramowanie
Dedykowane,
Oprogramowanie Pomocnicze jak również każde z nich z osobna.
Oprogramowanie Dedykowane - wszelkie oprogramowanie zapewniające wsparcie
procesów Zamawiającego, stworzone, zmodyfikowane i dostarczone przez Wykonawcę w
związku z realizacją Przedmiotu Umowy, w szczególności modyfikacje i rozszerzenia
Oprogramowania Standardowego lub poszczególnych jego elementów, zmiany koduźródłowego, modyfikacje, opracowania Oprogramowania wykonane w celu realizacji
SystemuBE, w tym dostosowania Oprogramowania do indywidualnych potrzeb BGK.
Oprogramowanie Pomocnicze-oprogramowanie typu COTS (Commercial off-the-shelf) lub
inne oprogramowanie o funkcjonalnościach wystandaryzowanych na rynku, dostarczone
przez Wykonawcę lub osoby trzecie, których zastosowanie jest niezbędne dla działania
SystemuBE oraz jego utrzymania poprzez świadczenie Usług Serwisu i przy-szłego Rozwoju
oraz Walidacji.
Oprogramowanie Standardowe - oprogramowanie core’owe dostarczane przez Wyko-nawcę,
w ramach niniejszej Umowy, stanowiące pod-stawę SystemuBE. W skład Oprogramowania

Standardowego wchodzi również wszelkie oprogramowanie o ile nie stanowi
Oprogramowania Dedykowanego lub Pomocniczego, wymagane do działania SystemuBE.
Prawa własności intelektualnej - Oznaczają wszelkie prawa autorskie i prawa pokrewne, jak
również wszelkie patenty i dodatkowe prawa ochronne na wynalazki, prawa ochronne na
wzory użytkowe, prawa z rejestracji wzorów przemysłowych, prawa do zarejestrowanych i
niezarejestrowanych wzorów wspólnotowych, prawa ochronne na znaki towarowe oraz
prawa z rejestracji wspólnotowych znaków towarowych, prawa ochronne na oznaczenia
geograficzne, prawa z rejestracji topografii układów scalonych, oraz prawa do zgłoszeń i
prawa do dokonania zgłoszeń wyżej wymienionych przedmiotów praw własności
przemysłowej, jak również prawa do baz danych, prawa do niezarejestrowanych oznaczeń
odróżniających, prawa do oznaczeń przedsiębiorstw (firm), prawa do nazw handlowych, i
wszelkie inne prawa na dobrach niematerialnych chronionych ustawowo, bez względu na to
czy zostały zarejestrowane i opublikowane zgodnie z właściwymi przepisami, jak również
know-how i tajemnice przedsiębiorstwa w rozumieniu Ustawy – o zwalczaniu nieuczciwej
konkurencji.
Prawo własności przemysłowej - Ustawa z dnia 30 czerwca 2000 r. Prawo własności
Parametryzacja - dostosowanie SystemuBE do specyfiki potrzeb Zamawiającego poprzez
zmiany dostępnych dla Zamawiającego ustawień SystemuBE w sposób szczegółowo
opisany w Projektach Technicznych lub Dokumentacji SystemuBE. Parametryzację naśrodowiskach produkcyjnych i wymagającej uprawnień Administratora SystemuBE wykonuje
Personel BGK na podstawie otrzymanych od Wykonawcy instrukcji.
Rozwój - modyfikacje SystemuBE skutkujące zmianą lub rozszerzeniem funkcjonalności lub
sposobu funkcjonowania SystemuBE, w szczególności wynikające ze zmian przepisów
prawa oraz rozwoju standardu Oprogramowania, określone szczegółowo w Załączniku nr 4
do Umowy.
Scenariusze Testowe - przygotowane przez Wykonawcę przypadki testowe umożliwiające
Zamawiającemu sprawdzenie poprawności działania SystemuBE.
Usterka - inna niż Awaria, Błąd lub Zgłoszenie problemu Infrastruktury Wada polegająca na
nieprawidłowym funkcjonowaniu Oprogramowania SystemuBE, w tym w szczególności
niezgodnie z Dokumentacją, nieograniczająca zakresu funkcjonalnego SystemuBE.
Usterkami mogą być na przykład błędy w prezentacji graficznej (nie obejmujące cyfr),
semantyczne i składniowe, które nie rodzą konieczności istotnych dodatkowych nakładów
pracy użytkownikom lub administratorom SystemuBE.
Wada - stwierdzone nieprawidłowe działanie SystemuBE lub jego elementu, w szczególności
niezgodne z Umową, z jego Dokumentacją lub podstawowymi zasadami działania systemów
informatycznych. Wada może mieć postać Awarii, Błędu, Usterki lub Zgłoszenia problemu
Infrastruktury.

W rozdziale 8. PRZEBIEG PRAC WDROŻENIOWYCH określił weryfikację Oprogramowania
Standardowego, jako:
§ 70. W ramach Fazy I Etapu I, Wykonawca w terminie uzgodnionym przez Strony, ale nie
dłuższym niż 30 Dni od wezwania przez Zamawiającego, udostępni system uruchomiony w
oparciu o Oprogramowanie Standardowe.
§ 71. BGK przystąpi do weryfikacji, czy zainstalowane Oprogramowanie Standardowe
spełnia wymogi i posiada funkcjonalności, które w Ofercie zostały określone jako mieszczące
się w standardzie na podstawie scenariuszy testowych dostarczonych wraz ze standardową
dokumentacją Oprogramowania Standardowego. Wykonawca ma obowiązek, na żądanie
Zamawiającego, udzielić wyjaśnień na temat działania Oprogramowania Systemowego i jego
standardowych funkcjonalności.
§ 72. W razie niewykonania zobowiązania, o którym mowa w § 70, a także w przypadku, gdy
Zamawiający stwierdzi, że Oprogramowanie Standardowe nie spełnia wymogów, o których
mowa w § 71 BGK, Zamawiający wzywa Wykonawcę do odpowiednio wykonania
zobowiązania, o którym mowa w §70 lub usunięcia stwierdzonych nieprawidłowości
wyznaczając termin nie krótszy niż 10 Dni Roboczych. Po bezskutecznym upływie tego
terminu Zamawiający może odstąpić od Umowy zgodnie z ROZDZIAŁ 15.§ 159.
W rozdziale 11. PRZEKAZANIE WIEDZY wskazał, że:
§ 111. Od dnia zawarcia Umowy Wykonawca zobowiązany jest do przekazania do Za-
mawiającego wiedzy na temat SystemuBE, na zasadach opisanych poniżej.
§ 112. Obowiązek Wykonawcy przekazania wiedzy obejmuje działania zmierzające do
umożliwienia osobom wskazanym przez Zamawiającego, pozyskania wiedzy oraz
wykształcenia umiejętności i kompetencji umożliwiających realizację zadań objętych
Usługami Serwisowymi oraz Asysty Technicznej, a także usług Rozwoju SystemuBE oraz
przygotowanie
i
przekazanie
Zamawiającemu
odpowiednich
materiałów
szkoleniowych/instruktażowych.
§ 113. Zamawiający może zmieniać osoby, którym Wykonawca ma obowiązek przekazać
wiedzę. W przypadku zmiany takiej osoby, Wykonawca nie ma obowiązku ponownego
przekazania wiedzy, przekazanej poprzedniej osobie.
§ 114. Działania, o których mowa w ROZDZIAŁ 11.§ 112 i następnych obejmują:
1. Udzielanie niezwłocznie, na każde zgłoszenie Członków Zespołu wskazanych przez
Kierownika Projektu ze strony BGK, wyjaśnień co do działania SystemuBE i jego
poszczególnych elementów, a także zapisów zawartych w Dokumentacji.
2. Uzgodnienie i przeprowadzenie szkoleń w zakresie działania SystemuBE i zasad jego
obsługi w zakresie niezbędnym do samodzielnego wykonywania niżej wymienionych ról, w
szczególności:

1) szkoleń metodycznych, produktowych i warsztatów dla maksymalnie 20 członków Zespołu
Projektowego (administrator bezpieczeństwa, administrator biznesowy, administrator
eksploatacji aplikacji, administrator techniczny, osoby odpowiedzialne za rozwój);
2) szkolenia i warsztaty mogą być łączone dla grup uczestników nie większych niż 10 osób.
Przewiduje się rozłożenie szkoleń i działań wspomagających przekazanie wiedzy do
odpowiednich Faz Planu Wdrożenia;
3) w ciągu 5 Dni Roboczych od zwrócenia się przez Zamawiającego Wykonawca jest
zobowiązany do ustalenia terminu szkolenia.
3. Udzielenie wsparcia na stanowisku pracy przez Wykonawcę prac Wdrożeniowych, które
pracownik Zamawiającego jest w stanie wykonać po odpowiednim instruktażu zgodnie z
otrzymaną Dokumentacją, w wymiarze maksymalnie 15 godzin zegarowych kwartalnie.
§ 115. Każde działanie, o których mowa w § 114, kończy się podpisaniem przez
Zamawiającego protokołu wykonania przez Wykonawcę działań w przypisanym im
wymiarze, co oznacza, że Wykonawca prawidłowo przeprowadził przekazanie wiedzy.
§ 116. Wykonawca ma obowiązek dokonywania przekazania wiedzy niezależnie od tego, czy
jest zobowiązany do wykonywania jakichkolwiek innych świadczeń na rzecz Zamawiającego.
Jednak Wykonawca nie ma obowiązku dokonywania prze-kazania wiedzy w przypadku
odstąpienia od umowy i wskazania, że odstąpienie następuje z mocą wsteczną.
W rozdziale 13. ODPOWIEDZIALNOŚĆ. KARY UMOWNE zamawiający m. in. określił
poniższe kary umowne:
§ 134. W przypadku opóźnienia Wykonawcy w wykonaniu danego Etapu lub Fazy w
stosunku do Harmonogramu wdrożenia, Wykonawca, na żądanie Zamawiającego,
zobowiązany będzie do zapłaty Zamawiającemu:
1. kary umownej w wysokości 50000 złotych brutto za każdy rozpoczęty tydzień opóźnienia
w wykonaniu Fazy w ramach Etapu 1;
2. kary umownej w wysokości 35000 złotych brutto za każdy rozpoczęty tydzień opóźnienia
w wykonaniu Fazy w ramach Etapu 2;
3. kary umownej w wysokości 20000 złotych brutto za każdy rozpoczęty tydzień opóźnienia
w wykonaniu Fazy w ramach Etapu 3;
§ 135. W przypadku opóźnienia Wykonawcy w wykonaniu zamówienia realizowanego w
ramach usług Rozwoju i Walidacji, Wykonawca zapłaci Zamawiającemu karę umowną w
wysokości 1% wartości złożonego zamówienia za każdy dzień opóźnienia.
§ 136. W przypadku opóźnienia Wykonawcy w wykonaniu wstępnej analizy wykonalności
zamówienia realizowanego w ramach usług Rozwoju i Walidacji, Wykonawca zapłaci
Zamawiającemu karę umowną w wysokości 1000 złotych brutto za każdy rozpoczęty tydzień
opóźnienia.

§ 137. W przypadku opóźnienia w usuwaniu Wad w okresie świadczenia Usług Serwisu i
Usług Gwarancji na środowisku produkcyjnym, Wykonawca zapłaci BGK karę umowną w
wysokości:
1. w przypadku Awarii – 2000 zł brutto za każdą rozpoczętą godzinę udostępnienia usług,
objętych Awarią;
2. w przypadku Błędów – 2000 zł brutto za każdą rozpoczęty kolejny dzień roboczy naprawy;
3. w przypadku Usterek – 1000 zł brutto za każdą rozpoczętą (drugą i następne) krotność
czasu przewidzianego Umową dla usunięcia Usterki;
4. w przypadku Zgłoszeń problemów Infrastruktury - 2000 zł brutto za każdą rozpoczętą
godzinę udostępnienia usług, objętych Zgłoszeniem problemów Infrastruktury.
§ 140. W wypadku opóźnienia w przekazaniu przez Wykonawcę kodów źródłowych w
terminie określonym w Harmonogramie, Wykonawca zapłaci karę umowną w wysokości
5000 złotych brutto za każdy dzień opóźnienia.
§ 156. Niezależnie od pozostałych przewidzianych w Umowie lub wynikających z przepisów
prawa podstaw odstąpienia, Zamawiającemu przysługuje prawo do odstąpienia od Umowy:
1. do chwili dokonania odbioru Planu Wdrożenia. W takim przypadku Wykonawcy będzie
przysługiwało wynagrodzenie za faktycznie wykonaną pracę. W żadnym przypadku takie
wynagrodzenie nie będzie wyższe niż 50000 złotych brutto,
2. po zgłoszeniu do odbioru Projektu Technicznego Etapu I, w przypadku odmowy przyjęcia
Projektu Technicznego Etapu I przez Zamawiającego na zasadach określonych w
Załączniku nr 5 do Umowy w § 2. W takim przypadku Wykonawcy nie będzie przysługiwało
wynagrodzenie za wykonaną pracę,
3. w przypadku opóźnienia po stronie Wykonawcy terminu rozpoczęcia lub zakończenia
Etapu lub Fazy o co najmniej 20 Dni Roboczych, przy czym nie dotyczy to sytuacji, gdy to
przedłużenie jest wcześniej uzgodnione i zaakceptowane przez Zamawiającego zgodnie z
warunkami określonymi w Umowie,
4. w przypadku opóźnienia realizacji zadań projektowych w stosunku do Harmonogramu o co
najmniej 20 Dni Roboczych, przy czym nie dotyczy to sytuacji, gdy to przedłużenie jest
wcześniej uzgodnione i zaakceptowane przez Zamawiającego, zgodnie z warunkami
określonymi w Umowie,
5. w przypadku niewykonania lub nienależytego wykonania Umowy, gdy skutki takiego
naruszenia będą niemożliwe do usunięcia bądź nie zostaną usunięte przez Wykonawcę w
terminie 20 Dni Roboczych od otrzymania przez Wykonawcę pisemnego wezwania do
usunięcia takiego naruszenia,
6. w przypadku naruszenia zobowiązania do przekazania przez Wykonawcę kodówźródłowych i nie naprawienia tego naruszenia w ciągu 20 Dni Roboczych od otrzymania
przez Wykonawcę pisemnego zawiadomienia określającego to naruszenie,

7. w przypadku odstąpienia lub wypowiedzenia umowy licencyjnej przez licencjodawcę
Oprogramowania Standardowego lub Pomocniczego, do którego autorskie prawa majątkowe
przysługują podmiotom trzecim, innym niż Wykonawca i niemożliwości uzyskania i
dostarczenia przez Wykonawcę nowej licencji na to samo Oprogramowanie albo inne
Oprogramowanie posiadające te same funkcje i parametry w terminie 14 dni od dnia
uzyskania od Zamawiającego pisemnej informacji o tej okoliczności, co uniemożliwia
Zamawiającemu prawidłowe i zgodne z Przedmiotem umowy korzystanie z SystemuBE.
W załączniku nr 3 do załącznika nr 2 do siwz zamawiający w zakresie spornym określił
następujące warunki przeniesienia wiedzy:
Pozostała Dokumentacja
§ 6. W odniesieniu do Dokumentacji innej, niż wskazana w ROZDZIAŁ 1.§ 1 - ROZDZIAŁ 1.§
5 powyżej oraz do jej późniejszych zmian, modyfikacji oraz aktualizacji dokonanych m.in. w
ramach Aktualizacji, Walidacji oraz Rozwoju SystemuBE (Pozostała Dokumentacja), w
ramach wynagrodzenia przewidzianego za wykonanie Przedmiotu Umowy, Wykonawca
udziela licencji, a w przypadkach, gdy nie dysponuje prawem do jej udzielenia spowoduje
udzielenie Zamawiającemu licencji na Dokumentację, na warunkach określonych poniżej:
1. Licencja udzielona zostaje na czas nieoznaczony. Strony zastrzegają, że Wykonawca lub
inny licencjodawca nie może wypowiedzieć umowy licencyjnej w ciągu 30 lat od dnia jej
zawarcia.
2. Licencja ma charakter niewyłączny i uprawnia BGK do korzystania z Pozostałej
Dokumentacji i jej poszczególnych elementów na terytorium Rzeczypospolitej Polskiej, na
następujących polach eksploatacji:
1) w zakresie korzystania w całości lub części;
2) w zakresie utrwalania i zwielokrotniania - wytwarzanie dowolną techniką egzemplarzy
utworu, w tym techniką drukarską, reprograficzną, zapisu magnetycznego oraz techniką
cyfrową,
3) w zakresie obrotu oryginałem albo egzemplarzami, na których dany utwór utrwalono -
wprowadzanie do obrotu, użyczenie lub najem oryginału albo egzemplarzy,
4) w zakresie rozpowszechniania w sposób inny niż określony w punkcie 2) powyżej -
publiczne wykonanie, wystawienie, wyświetlenie, odtworzenie oraz nadawanie i
reemitowanie, a także publiczne udostępnianie utworu w taki sposób, aby każdy mógł mieć
do niego dostęp w miejscu i w czasie przez siebie wybranym, w tym w sieci Internet, oraz
innych sieciach teleinformatycznych (w tym intranet, extranet) i platformach cyfrowych,
5) w zakresie tłumaczenia, adaptacji (opracowań), wprowadzania zmian, uzupełnień i
modyfikacji,
6) w zakresie prawa zezwalania na wykonywanie zależnego prawa autorskiego na polach
eksploatacji wymienionych w punktach poprzedzających.

3. Udzielenie licencji następuje najpóźniej z chwilą odbioru przez BGK poszczególnych
elementów Pozostałej Dokumentacji. Termin odbioru Pozostałej Dokumentacji określony jest
w Harmonogramie Ramowym i może być dalej uszczegółowiony w Harmonogramie
Wdrożenia.
4. BGK będzie uprawniony do udzielenia sublicencji osobom trzecim na korzystanie z
Pozostałej Dokumentacji w zakresie posiadanej przez BGK licencji,
w szczególności:
1) na rzecz podmiotów z nim powiązanych zgodnie z definicją jednostki powiązanej zawartą
w ustawie z dnia 29 września 1994 r. o rachunkowości (tj. Dz. U. z 2002 r., Nr 76, poz. 694,
ze zm.);
2) w celu świadczenia usług i wykonywania prac oraz innych świadczeń przez osoby trzecie
na potrzeby BGK i jednostek powiązanych, w tym w zakresie usług rozwoju i utrzymania
oprogramowania;
3) w celu świadczenia przez BGK lub jednostki powiązane lub zależne od BGK w rozumieniu
przepisów ustawy o rachunkowości, usług i wykonywania prac oraz innych świadczeń
leżących w zakresie działalności statutowej lub przewidzianej przepisami.
5.
Zamawiający
może
zlecić
innym
podmiotom
tłumaczenia,
adaptację
(opracowań),wprowadzanie zmian, uzupełnień i modyfikacji.
6. Wraz z udzieleniem licencji Wykonawca upoważnia Zamawiającego do wykonywania
zależnych praw autorskich do Pozostałej Dokumentacji oraz za-pewni upoważnienia innych
osób do wykonywania takich praw.
7. Przeniesienie praw licencyjnych do dokumentów wskazanych w niniejszym paragrafie
powoduje przejście na BGK prawa własności nośników na których Dokumentacja została
utrwalona.
Warunki licencji oraz warunki przeniesienia autorskich praw majątkowych do SystemuBE
§ 7. W ramach wynagrodzenia przewidzianego za wykonanie Przedmiotu Umowy,
Wykonawca niniejszym stosownie do ustawy z dnia 4 lutego 1994 r. o prawie autorskim i
prawach pokrewnych (tj. Dz. U. z 2006 r., nr 90, poz. 631 ze zm.) udziela Zamawiającemu
prawa do korzystania (licencji) z Oprogramowania Standardowe-go oraz Oprogramowania
Pomocniczego oraz przenosi autorskie prawa majątkowe do Oprogramowania
Dedykowanego, do których przysługują Wykonawcy autorskie prawa majątkowe i które
zostały wykorzystane do wykonania SystemuBE na warunkach przewidzianych w niniejszym
paragrafie. Postanowienia zawarte w niniejszym § 7 dotyczące przeniesienia praw autorskich
lub udzielenia licencji do Oprogramowania Standardowego, Pomocniczego i Dedykowanego,
dotyczą również wszystkich późniejszych zmian, aktualizacji i modyfikacji dokonanych m.in.
w ramach Aktualizacji, Walidacji i Rozwoju SystemuBE.

1. Prawa, o których mowa w niniejszym § 7 uprawniają BGK do korzystania z SystemuBE i
jego poszczególnych elementów na terytorium Rzeczypospolitej Polskiej co najmniej na
następujących polach eksploatacji:
1) korzystanie w całości lub części z Oprogramowania ;
2) dokonywanie dowolnych zmian Oprogramowania, niezależnie od zakresu, formy, sposobu
(środków) ich dokonania oraz przeznaczenia, z zastrzeżeniem , że nie dotyczy to utworów
na które została udzielona jedynie licencja;
3) trwałe lub czasowe zwielokrotnianie u Oprogramowania w całości lub w części
jakimikolwiek środkami i w jakiejkolwiek formie;
4) wielokrotny obrót oryginałem albo egzemplarzami, na których Oprogramowanie utrwalono
– wprowadzenie do obrotu, użyczenie lub najem oryginału albo egzemplarzy, z
zastrzeżeniem, że nie dotyczy to Oprogramowania na które została udzielona jedynie
licencja;
5) wielokrotne rozpowszechnianie Oprogramowania Dedykowanego osobom trzecim w
sposób inny niż określony powyżej a także publiczne udostępnianie w taki sposób, aby
każdy mógł mieć do niego dostęp w miejscu i w czasie przez siebie wybranym;
6) wielokrotnego wprowadzania do pamięci komputera Oprogramowania;
7) zezwalania na wykonywanie zależnego prawa autorskiego na polach eksploatacji
wymienionych w punktach poprzedzających, z zastrzeżeniem, że nie dotyczy to utworów, w
szczególności Oprogramowania Standardowego oraz Oprogramowania Pomocniczego na
które została udzielona jedynie licencja.
2. Licencja na Oprogramowanie Standardowe i Pomocnicze, do którego autorskie prawa
majątkowe przysługują Wykonawcy, udzielona zostaje na czas nieoznaczony. Strony
zastrzegają, że Wykonawca nie może wypowiedzieć umowy licencyjnej w ciągu 30 lat od
dnia jej zawarcia.
3. Licencja ma charakter niewyłączny.
4. BGK będzie uprawniony do udzielenia sublicencji osobom trzecim na korzystanie z
Oprogramowania Standardowego i Pomocniczego w zakresie posiadanej przez BGK licencji,
w szczególności:
1) na rzecz podmiotów z nim powiązanych zgodnie z definicją jednostki powiązanej zawartą
w ustawie z dnia 29 września 1994 r. o rachunkowości (tj. Dz. U. z 2002 r., Nr 76, poz. 694,
ze zm.);
2) w celu świadczenia usług i wykonywania prac oraz innych świadczeń przez osoby trzecie
na potrzeby BGK i jednostek powiązanych, w tym w zakresie usług rozwoju i utrzymania
oprogramowania;

3) w celu świadczenia przez BGK lub jednostki powiązane lub zależne od BGK w rozumieniu
przepisów ustawy o rachunkowości, usług i wykonywania prac oraz innych świadczeń
leżących w zakresie działalności statutowej lub przewidzianej przepisami.
5. Przejście na Zamawiającego praw lub ich udzielenie, o których mowa w niniejszym § 7,
nastąpi w dniu podpisania Protokołu odbioru, ale w żadnym wypadku, nie później niż w dniu
Startu Produkcyjnego poszczególnych elementów SystemuBE oraz całego Systemu w
terminie przewidzianym w Harmonogramie Ramowym Wykonawcy, który może być dalej
uszczegółowiony w Harmonogramie Wdrożenia. W razie jednak wcześniejszego rozwiązania
Umowy z jakiejkolwiek przyczyny i w jakikolwiek sposób, jak również odstąpienia od Umowy
przejście praw o których mowa w § 7 do Systemu BE oraz jego poszczególnych elementów
następuje najpóźniej z chwilą rozwiązania Umowy bądź odstąpienia od Umowy, na zasadach
określonych w ROZDZIAŁ 15 niniejszej Umowy.
6. Wykonawca oświadcza, że w dacie przeniesienia autorskich praw majątkowych na BGK
do wykonanego w ramach realizacji Przedmiotu Umowy Oprogramowania Dedykowanego
oraz jego późniejszych modyfikacji, zmian i uzupełnień dokonanych w ramach m.in.
Aktualizacji, Walidacji oraz Rozwoju SystemuBE, Wykonawca będzie uprawniony i
umocowany do przeniesienia tych praw oraz że prawa te zostaną przeniesione na BGK bez
jakichkolwiek obciążeń i ograniczeń ze strony innych podmiotów, w szczególności osób
uprawnionych z tytułu osobistych praw autorskich do Oprogramowania Dedykowanego.
7. Wraz z przeniesieniem praw, o których mowa w § 7, Wykonawca upoważnia BGK do
wykonywania zależnych praw autorskich do Oprogramowania Dedykowanego, o którym
mowa w niniejszym paragrafie oraz zapewni upoważnienia innych osób do wykonywania
takich praw.
8. Przeniesienie praw, o których mowa w § 7, powoduje przejście na BGK prawa własności
nośników na których Oprogramowanie zostało przekazane Zamawiającemu.
§ 8. W przypadkach innych niż wymienione w § 7 powyżej, Wykonawca, w ramach
wynagrodzenia przewidzianego za wykonanie Przedmiotu Umowy, spowoduje udzielenie
Zamawiającemu licencji do korzystania z Oprogramowania Standardowego oraz
Oprogramowania Pomocniczego, do których nie przysługują Wykonawcy Prawa własności
intelektualnej, na warunkach przewidzianych w niniejszym paragrafie. Postanowienia
zawarte w niniejszym paragrafie dotyczą-ce udzielenia licencji do Oprogramowania
Standardowego oraz Oprogramowania Pomocniczego dotyczą również wszystkich ich
późniejszych zmian, aktualizacji i modyfikacji dokonanych m.in. w ramach Aktualizacji,
Walidacji i Rozwoju SystemuBE.
1. Wykonawca spowoduje udzielenie licencji na Oprogramowanie w dniu podpisania
Protokołu odbioru, ale w żadnym wypadku, nie później niż w dniu Startu Produkcyjnego.

2. Licencje, o których mowa w niniejszym paragrafie zostaną udzielone na standardowych
warunkach producenta tego oprogramowania, z tym że:
1) Licencje te nie mogą zawierać ograniczeń polegających na tym, że dane Oprogramowanie
może być używane wyłącznie z innym Oprogramowaniem lub może być wdrażane,
serwisowane, itp. wyłącznie przez określony podmiot lub grupę podmiotów;
2) Licencje te uprawniać będą Zamawiającego do korzystania z Oprogramowania i jego
poszczególnych elementów co najmniej na terytorium Rzeczypospolitej Polskiej;
3) Licencje muszą zapewniać możliwość swobodnego administrowania Oprogramowaniem,
jego optymalizacji i parametryzacji;
4) Licencje będą uprawniały BGK do korzystania z najnowszych aktualizacji
Oprogramowania w ramach wynagrodzenia przewidzianego za wykonanie Przedmiotu
Umowy. Licencje będą udzielone na czas nieokreślony od Startu Produkcyjnego. Licencje
nie będą mogły być wypowie-dziane przez okres 30 lat. Jeżeli wypowiedzenie licencji nastąpi
w okresie 30 lat od momentu jej udzielenia albo licencjodawca odstąpi od umowy licencyjnej,
Wykonawca zobowiązany jest spowodować udzielenie Zamawiającemu w ramach
wynagrodzenia z tytułu realizacji Przedmiotu Umowy nowej licencji na to samo
oprogramowanie albo inne oprogramowanie posiadające te same funkcje i parametry
odpowiadające warunkom wskazanym w niniejszym § 8, w terminie 14 dni od dnia uzyskania
pisemnej informacji o tym zdarzeniu od Zamawiającego. W przypadku nieuzyskania nowej
licencji dla Zamawiającego, Zamawiający uprawniony jest do żądania od Wykonawcy kary
umownej w wysokości równej trzykrotności wynagrodzenia za udzielenie licencji, którą
wypowiedziano, zapłaconemu uprzednio Wykonawcy przez Zamawiającego. Kara Umowna
będzie płatna w terminie 30 dni od dnia doręczenia Wykonawcy wezwanie w tym
przedmiocie.
W załączniku nr 4 do Istotnych Postanowień Umowy:
Opieka serwisowa: gwarancyjna i pogwarancyjna, Asysta Techniczna, Rozwój.
§ 3. ROZWÓJ SYSTEMUBE
3.1. Świadczenie Usług Rozwoju SystemuBE polegać będzie na dokonywaniu zmian w
SystemieBE, w szczególności zmian w parametryzacji procesów biznesowych, modyfikacji
Oprogramowania (z wyjątkiem Oprogramowania Pomocniczego), opracowaniu nowych
funkcjonalności na wniosek Zamawiającego, dostosowania do zmian przepisów prawa.
3.2. W ramach Umowy, Zamawiający ma prawo zamówić Usługi Rozwoju w wymiarze do
1000 osobodni pracy Personelu Wykonawcy w okresie obowiązywania Umowy, począwszy
od rozpoczęcia Etapu I, przy czym stawka wynagrodzenia za osobodzień pracy za każdego
członka personelu Wykonawcy wynosić będzie nie więcej niż ___________ zł brutto.
Niewykorzystanie limitu w całości przez Zamawiającego nie uprawnia Wykonawcy dożadnych świadczeń ze strony Zamawiającego.

3.3. W razie stwierdzenia, że SystemBE wymaga zmian, o których mowa w ustępie 3.1
powyżej, BGK zawiadomi o tym fakcie Wykonawcę. Nowa wersja Oprogramowania zostanie
wdrożona na poniższych zasadach, przy uwzględnieniu faktu, że dla zmian związanych z
dostosowaniem SystemuBE do wymogów prawa, wprowadzono dodatkowe warunki zawarte
w ustęp 3.4 niniejszego paragrafu:
a) BGK w zawiadomieniu dla Wykonawcy wskaże funkcjonalności, jakie powinna realizować
nowa wersja Oprogramowania,
b) W terminie 10 Dni Roboczych Wykonawca przedstawi wstępną analizę wykonalności,
zawierającą w szczególności szacunek liczby osobodni niezbędnej dla wdrożenia danego
rozwiązania oraz szacowany czas realizacji,
c) W terminie 20 Dni Roboczych Zamawiający akceptuje lub nie akceptuje wstępną analizę
wykonalności,
d) Po akceptacji przez Zamawiającego wstępnej analizy wykonalności, Wykonawca
przygotuje wiążącą ofertę zawierającą:
(1) liczbę osobodni niezbędną dla wdrożenia zmiany,
(2) harmonogram, zawierający termin wdrożenia zmiany,
(3) projekt i plan czynności,
(4) plan testów i poprawy błędów,
(5) plan aktualizacji stosownej Dokumentacji, transfer wiedzy,
e) Kierownik Projektu Wykonawcy i Administrator SystemuBE uzgodnią szczegółowe
warunki dotyczące dostawy, instalacji i uruchomienia nowej wersji Oprogramowania.
Uzgodnienia mogą spowodować zmianę warunków oferty, o której mowa w ustępie 3.3 d)
powyżej,
f) Uzgodnienia będą toczyć się do chwili podjęcia przez Zamawiającego decyzji w
przedmiocie dostawy, instalacji i uruchomienia nowej wersji Oprogramowania. Zamawiający
może na każdym etapie uzgodnień zrezygnować z realizacji nowej wersji Oprogramowania.
Dla uniknięcia wątpliwości Strony potwierdzają, że nie stosuje się przepisu 68[2] k.c.,
g) Osobami uprawnionymi do zawarcia i podpisania zamówienia na dostawę, instalację i
uruchomienie nowej wersji Oprogramowania są pracownicy Zamawiającego posiadający te
uprawnienia zgodnie z obowiązującymi regulacjami wewnętrznymi Zamawiającego.
Informacja o osobach uprawnionych do składania zamówień na dostawę będzie
przekazywana do Wykonawcy w formie pisemnej.
3.4. Dostosowanie SystemuBE do zmian prawa polega na dostosowywaniu do wymogów
prawa mających zastosowanie w działalności Zamawiającego, które dotyczą obszaru
funkcjonalnego SystemuBE objętego Umową, pod warunkiem że Zamawiający przekaże
Wykonawcy materiały, będące podstawą do dostosowania. Wykonawca zapewni zgodność
SystemuBE z obowiązującymi przepisami prawa polskiego oraz oficjalnymi stanowiskami

Podmiotów Nadzoru, polskich organów podatkowych lub innych organów administracji
rządowej, wydanych w jakiejkolwiek formie, w szczególności, w formie rekomendacji,
zarządzeń, zaleceń, uchwał, decyzji lub wykładni bez względu na to, czy stanowisko takie
kierowane jest indywidualnie do Zamawiającego, czy też nie. Ponadto SystemBE musi
zapewniać zgodność z prawem Unii Europejskiej stosowanym bezpośrednio w krajach
członkowskich oraz zgodność z umowami i standardami obowiązującymi w stosunkach
międzybankowych. Zamawiający jest zobowiązany powiadomić Wykonawcę o zmianach
przepisów prawa w ciągu 20 Dni Roboczych, po ogłoszeniu przez odpowiedni podmiot.
Wykonawca jest zobowiązany umożliwić Zamawiającemu wdrożenie nowej wersji
Oprogramowania na środowisko produkcyjne najpóźniej na 10 Dni Roboczych przed datą
wejścia w życie zmienionych przepisów prawnych. Jeśli z przyczyn niezależnych od
Wykonawcy nie będzie możliwe dotrzymanie powyższego zobowiązania, Strony mogą
ustalić inny termin przekazania i wdrożenia nowej wersji Oprogramowania. Jeśli
Zamawiający nie poinformuje Wykonawcy w ustalonym terminie o zmianach przepisów
prawa, Wykonawca może dostarczyć nową wersję Oprogramowania w terminie późniejszym,
przesuniętym o liczbę Dni spóźnienia Zamawiającego w poinformowaniu Wykonawcy o
wymaganej zmianie.
3.5. Wynagrodzenie z tytułu usług Rozwoju będzie płatne po odebraniu przez
Zamawiającego danych rezultatów prac Wykonawcy, na podstawie faktury VAT. Warunkiem
wystawienia przez Wykonawcę faktury VAT jest podpisanie przez Zamawiającego, bez
zastrzeżeń, odpowiedniego protokołu odbioru nowej wersji Oprogramowania.
3.6. W protokole odbioru nowej Wersji Oprogramowania zostaną wskazane:
a) opis wykonanych prac;
b) liczba osobodni poświęconych na wdrożenie rozwiązania;
3.7. Limit wynagrodzenia wskazany w ROZDZIAŁ 12.§ 117.3 Umowy zostanie pomniejszony
o kwotę odpowiadającą czasochłonności zaakceptowanej przez Zamawiającego w
zamówieniu.
3.8. Wykonawca jest zobowiązany w terminie dostawy lub nie później niż 14 Dni Roboczych
do daty instalacji nowej wersji Oprogramowania objętego usługami rozwoju dostarczyć nową
lub zaktualizowaną w formie suplementu wersję Dokumentacji w postaci elektronicznej.
3.9. Jeżeli po instalacji nowej wersji Oprogramowania objętego usługami rozwoju okaże się,że występują nieprawidłowości w funkcjonowaniu SystemuBE, Wykonawca usunie je
zgodnie z postanowieniami niniejszego załącznika, tj. naprawi Wady.
3.10. Wykonawca zobowiązuje się do zapewnienia wsparcia w trakcie instalacji nowych
wersji Oprogramowania, jeżeli proces instalacji nie jest wyłącznie prostą operacją aktualizacji
bazy danych i / lub aktualizacji bibliotek i nie został opracowany przez Wykonawcę i
dostarczony BGK w formie opisu wprowadzenia zmiany z załączonymi skryptami i / lub

plikami wymiany. Osobą uprawnioną do żądania wsparcia instalacji nowych wersji
Oprogramowania, będzie Administrator SystemuBE.
3.11. W przypadku wprowadzenia nowej wersji Oprogramowania o istotnym zakresie zmian
funkcjonalności Oprogramowania, Wykonawca jest zobowiązany do przedłożenia
Zamawiającemu oferty szkolenia użytkowników Oprogramowania oraz Administratora
SystemuBE.
3.12. W przypadku niewykonywania lub nienależytego wykonywania przez Wykonawcę
obowiązków opisanych w niniejszym paragrafie, BGK jest uprawniony do skorzystania
z osoby trzeciej, która wykona te obowiązki za Wykonawcę i obciążenia Wykonawcy
wszystkimi wynikającym stąd kosztami

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

Izba stwierdziła, że zgłoszone przystąpienie spełnia wymogi formalne określone w art. 185
ust. 2 ustawy.
Izba nie dopatrzyła się okoliczności, które mogłyby skutkować odrzuceniem odwołania na
podstawie art. 189 ust. 2 ustawy.

Izba stwierdziła, że odwołujący ma interes w uzyskaniu zamówienia, gdyż jest wykonawcą,
który prowadzi działalność gospodarcza w zakresie objętym przedmiotem zamówienia. Ma
więc szansę na złożenie oferty i ubieganie się o uzyskanie zamówienia. Odwołujący
zarzucając zamawiającemu przede wszystkim opis przedmiotu zamówienia w sposób
uniemożliwiający sporządzenie i wycenę oferty wskazał na możliwość poniesienia przez
niego szkody w postaci nieprzystąpienia do postępowania i uniemożliwienia uzyskania
zysku, w przypadku uzyskania zamówienia. Przesłanka materialnoprawna z art. 179 ust. 1
ustawy została wypełniona.

Zarzut naruszenia przez zamawiającego art. 29 ust. 1 ustawy oraz nr 1 do SIWZ - Opis
Przedmiotu zamówienia, Wymagania Funkcjonalne w sposób niejednoznaczny i
niewyczerpujący opisującego przedmiot zamówienia

Zarzut nie został przez odwołującego udowodniony. Odwołujący powołał wszystkie punkty i
pozycje z załącznika nr 1 do siwz – OPZ oraz z załącznika nr 1 do OPZ za wyjątkiem pkt.
4.13 poz. 32 załącznika nr 1 do OPZ, które pozostawiały jakiś element w ramach opisanych
przez zamawiającego funkcjonalności ustaleniom stron na etapie analizy. Zamawiający
zdefiniował w IPU pojęcie analizy jako ogół działań obejmujący m.in.: identyfikację realnych

celów strategicznych, weryfikację obecnej struktury procesów, optymalizację struktury
organizacyjnej, badanie obiegu informacji (w tym dokumentów),funkcjonujących systemów
informatycznych oraz docelowych rozwiązań, w wyniku których otrzymuje się pełen zakres
informacji niezbędnych do efektywnego i optymalnego wdrożenia lub modyfikacji systemu
informatycznego, a przede wszystkim do podjęcia trafnej decyzji w zakresie doboru
optymalnego rozwiązania. Co więcej w załączniku nr 9 do załącznika nr 2 do siwz – IPU –
Harmonogram Ramowy zamawiający dla każdego etapu przewidział fazę analizy i założył
limit wynagrodzenia w wysokości 10% wynagrodzenia brutto za dany etap. Odwołujący
zakwestionował 47 funkcjonalności z 279 wszystkich funkcjonalności (wielkości tej
odwołujący nie kwestionował) opisanych przez zamawiającego nie dokonując w odwołaniu
jakiejkolwiek analizy danej funkcjonalności, co do tego jakie elementy pozostawione do
ustalenia na etapie analizy wywołują, jakie trudności z ich wyszacowaniem na etapie
sporządzenia oferty, czy uniemożliwiają deklarację wykonawcy w zakresie wskazania, czy
dana funkcjonalność jest dla wykonawcy funkcjonalnością standardową w rozumieniu rozdz.
3 pkt 4 ust. 1a i b OPZ, czy dedykowaną w rozumieniu rozdz. 3 pkt 4 ust. 2 OPZ. Taką
polemikę odwołujący podjął dopiero z odpowiedzią zamawiającego na odwołanie
ograniczając się jednak do 10 funkcjonalności tj. wymagań:
Wymaganie 2.2 poz. 11 – kwestionując brak zakresu danych dostępnych w trybie offline.
Wymaganie 8.9 poz. 64 i 8.13. poz. 68- kwestionując brak określenia formatów danych,
jakie mają być zastosowane
Wymaganie 11.2 poz. 82 –kwestionując brak określenia liczby akcji i ich rodzaju
Wymaganie 12.10 poz. 98 – kwestionując brak listy zdarzeń co do zaistnienia których
użytkownik będzie powiadamiany,
Wymaganie 16.19 poz. 148 - kwestionując brak określenia zakresu i liczby raportów oraz
tego z jakich danych mają być sporządzane te raporty,
Wymaganie 23.21 poz. 250 – kwestionując brak wymagań co do stanu tych przelewów
Wymaganie 23.24 poz. 253 - kwestionując brak skończonej lista statusów
Wymaganie 29.4 poz. 318 - kwestionując brak zakresu produktów do prezentacji,
Wymaganie 33.2 poz. 358 – kwestionując brak zakresu funkcji dla jakich wersja light ma być
udostępniona.
Wskazując na powyższe braki odwołujący podnosił, że niedookreślenie wpływa na koszty,
ewentualnie przekłada się na potrzebę zakupu sprzętu określonej wydajności.
W pozostałym zakresie odwołujący uznał, że zamawiający przyznał mu rację dokonując
wyjaśnień postanowień siwz i te wyjaśnienia odwołujący ocenił jako wystarczające.
W ocenie Izby stanowisko odwołującego, co do przyznania zamawiającego zasadności

zarzutów odwołania jest sprzeczne z jednoznaczną wolą zamawiającego wyrażoną w
odpowiedzi na odwołanie. Zamawiający wprost oświadczył, że wnosi o oddalenie odwołania
w całości, a postawiony zarzut uznał za bezzasadny, w tym stanie rzeczy Izba nie miała
podstaw do zastosowania art. 190 ust. 5 zd. 2 ustawy, gdyż nawet jeśli przyjąć, że
zamawiający składając odpowiedź na odwołanie, jakieś fakty przyznał, to to przyznanie wświetle oświadczenia o żądaniu oddalenia odwołania musi budzić wątpliwości, co do jego
zgodności z rzeczywistym stanem rzeczy. Izba nadto nie stwierdziła w treści odpowiedzi na
odwołanie, że zamawiający przyznał zasadność zarzutów odwołania, przeciwnie
zamawiający ustosunkowując się do zarzutów związanych z poszczególnymi wymaganiami,
albo wskazywał na powody, dla których dane elementy muszą być uzupełnione dopiero na
etapie analizy – tajemnica przedsiębiorstwa zamawiającego, wola otrzymania rozwiązania
aktualnego na etapie wdrożenia, albo wskazywał na brak znaczenia wskazania konkretnych
danych dla wyceny i sporządzenia oferty i na swoją obawę przed uznaniem opisu
przedmiotu zamówienia za preferujący określonego wykonawcę przez użycie pojęć
charakterystycznych dla konkretnego rozwiązania programistycznego dostępnego na rynku.
W tym stanie rzeczy Izba nie była władna uznać, że funkcjonalności zakwestionowane przez
odwołującego zostały w jakieś części przyznane przez zamawiającego jako naruszające art.
29 ust. 1 ustawy. Zatem zgodnie z dyspozycją art. 190 ust. 1 ustawy to na stronie, która
wywodzi określone skutki prawne ciąży obowiązek dowodowy. W konsekwencji, to
odwołujący, który twierdził, że wylistowane przez niego funkcjonalności z uwagi na ich
otwarty charakter uniemożliwiają mu sporządzenie oferty i jej wycenę, zobowiązany był to
twierdzenie udowodnić. Odwołujący w toku postępowania odwoławczego nie przejawił
jednak jakiejkolwiek inicjatywy dowodowej. Ustalenie stanu faktycznego niniejszej sprawy
mogło mieć miejsce wyłącznie z uwagi na przeprowadzenie przez Izbę postępowania
dowodowego z urzędu w postaci dowodów z dokumentacji postępowania o udzielenie
zamówienia publicznego tj. specyfikacji istotnych warunków zamówienia wraz z
załącznikami. Na podstawie tych dokumentów Izba ustaliła, że rzeczywiście zamawiający w
odniesieniu do elementów kilkudziesięciu funkcjonalności wskazał, że zostaną one ustalone
na etapie analizy. Z tego ustalenia nie da się jednak wywieść dalszych twierdzeń
odwołującego, co do niemożności sporządzenia oferty i wyceny kosztów. Odwołujący
jedynie co do części funkcjonalności twierdził, że wpłyną one na koszty np. w postaci
konieczności podjęcia decyzji o zakresie zakupowanego sprzętu na potrzeby tego
postępowania – twierdzenia tego nie poparł dowodem, czy zwiększenia lub braku
możliwości oszacowania pracochłonności – również brak dowodu, co do tego, że brak
sprecyzowania na etapie opracowania siwz konkretnych elementów funkcjonalności ma
wpływ na zwiększenie lub zmniejszenie pracochłonności. Rację należy przyznać
zamawiającemu, że art. 29 ust. 1 ustawy nie nakazuje zamawiającemu w każdym przypadku

posługiwania się katalogiem zamkniętym elementów składających się na świadczenie. W
ocenie Izby nie jest też tak, że świadczenie jednej ze stron staje się niedookreślone, jeśli
poszczególne jego elementy będą wynikiem, albo osobistego zaangażowania wykonawcy
(np. umowa o prace projektowe), albo wynikiem współdziałania wykonawcy i zamawiającego
(umowa o dzieło). Również kodeks cywilny nie zakłada jednorodności świadczeń
wzajemnych, wymaga natomiast, aby oba wzajemne świadczenia istniały i były znane
polskiemu prawu cywilnemu. Ponadto wzajemność świadczeń, to nie ich ekonomiczna
równoważność, ale to, że świadczenia stron są ze sobą sprzężone i jedno traci rację bytu
bez drugiego. Stąd bez wykazania, że brak jednoznacznego określenia poszczególnych
elementów funkcjonalności powoduje, że wykonawca nie może ustalić dla siebie
odpowiedniego ekwiwalentu, skutkuje koniecznością oddalenia niniejszego zarzutu.
Dodatkowo Izba zauważa, że w ramach repliki odwołujący uznał, że dalsze funkcjonalności
tj. wymaganie 6.9.poz. 64 i wymaganie 6.13.poz. 68 i wymaganie 23.24. poz. 253 zostały
wyjaśnione przez zamawiającego, a funkcjonalności 2.2 poz. 11, 16.19. poz. 148, 23.21. oz.
250 i 33.2 poz. 358 częściowo zostały wyjaśnione przez zamawiającego. W ocenie Izby
również ta okoliczność wskazuje, że odwołujący skupił się przede wszystkim na tym, że
ustalenie jakiś elementów ma nastąpić na etapie analizy, a nie na tym jaki jest charakter tych
elementów i jaki jest ich rzeczywisty wpływ na możliwość sporządzenia oferty i jej wyceny.
Na marginesie jedynie Izba zwraca zamawiającemu uwagę na fakt, iż rozstrzygnięcie
odwołania przez Izbę nie zwalnia zamawiającego od obowiązku udzielenia odpowiedzi na
pytania wniesione przez wykonawców w trybie art. 38 ustawy, w tym pytania wniesione
przez odwołującego.
Biorąc powyższe powodem oddalenia przedmiotowego zarzut jest brak jego udowodnienia.

Zarzut naruszenia przez zamawiającego art. 29 ust. 1 ustawy oraz przepisów art. 353
1

Kodeksu cywilnego, art. 58 § 1 Kodeksu Cywilnego, art. 5, jak i art. 58 § 2 Kodeksu
Cywilnego, art. 487 § 2 kodeksu cywilnego w związku z art. 14 i art. 139 ust. 1 ustawy przez
sporządzenie załącznika nr 1 do SIWZ - Opis Przedmiotu zamówienia: Wymagania
Funkcjonalne w związku z SIWZ Rozdział XVI Kryteria oceny ofert oraz ich znaczenie pkt 4
ppkt 1) - w sposób niejednoznaczny i niewyczerpujący opisującego przedmiot zamówienia,
uniemożliwiający przygotowanie oferty

Zarzut nie zasługuje na uwzględnienie. Izba podtrzymuje w całości argumentację
podniesioną w odniesieniu do zarzutu poprzedzającego. Dodatkowo Izba wskazuje, że
odwołujący nie kwestionował definicji funkcjonalności standardowej opisanej w rozdziale 3

pkt. 4 ust. 1 a i b OPZ i funkcjonalności dedykowanej opisanej w rozdziale 3 pkt. 4 ust. 2
OPZ. Odwołujący nie kwestionował także definicji parametryzacji zawartej w par. 1 IPU. W
ocenie Izby te postanowienia siwz pozwalają wykonawcy na zakwalifikowanie danej
funkcjonalności jako standardowej lub dedykowanej. Odwołujący nie wykazał, że
kwestionowane przez niego elementy funkcjonalności ustalane na etapie analizy w świetle
definicji parametryzacji i rozwoju zawartych w par. 1 IPU mogą być zakwalifikowane do obu
tych pojęć i stąd mogą prowadzić do wadliwych deklaracji ze strony wykonawców na etapie
składania ofert. W tym stanie rzeczy zarzut należało oddalić jako nieudowodniony.

Zarzut naruszenia przez zamawiającego art. 29 ust. 1 ustawy oraz

przepisów art. 353
1

Kodeksu cywilnego, art. 58 § 1 Kodeksu Cywilnego, art. 5, jak i art. 58 § 2 Kodeksu
Cywilnego, art. 487 § 2 kodeksu cywilnego w związku z art. 14 i art. 139 ust. 1 ustawy przez
sporządzenie załącznika nr 2 do SIWZ - Istotne Postanowienia Umowy - Rozdział 11 nie
dookreślając zobowiązań dotyczące przekazania wiedzy

Zarzut nie zasługuje na uwzględnienie. Zarzut koncentruje się na tym, że w ocenie
odwołującego zamawiający nie zwymiarował zakresu świadczenia wykonawców związanego
z przekazaniem wiedzy w postaci wyjaśnień i szkoleń.
Izba stwierdziła, że rzeczywiście w treści OPZ i IPU oraz załączników do tych dokumentów
brak jest szczegółowego określenia liczby godzin kwartalnie, w jakich wykonawca ma
udzielać wyjaśnień czy prowadzić szkolenia. Izba nie podziela jednak stanowiska
odwołującego, że zamawiający nie zwymiarował w tym zakresie swoich wymagań w inny
sposób. W szczególności kwestię związaną z wyjaśnieniami reguluje par. 61 IPU, który
stanowi, że zamawiający zapewni wykonawcy trzy miejsca w pomieszczeniu do pracy dla 3
pracowników ze strony wykonawcy dostępne w godz. [8:00 – 16:00] w dni robocze, w
przypadku zaistnienia potrzeby zgłoszonej przez którąś ze stron; zaś w par. 97 wykonawca
ma zapewnić obecność swoich konsultantów, w taki sposób by we wszystkie dni robocze w
godzinach 8:00 – 18:00 co najmniej jeden z nich był obecny u zamawiającego i mógł
udzielać porad i konsultacji w zakresie obsługi Systemu-BE oraz na bieżąco usuwać
ewentualne wady. Zatem z danych tych wynika w ocenie Izby zwymiarowanie, że minimalny
zakres udzielania wyjaśnień jaki należy wycenić to koszt jednego pracownika
wydelegowanego do pracy z zamawiającym we wszystkie dni robocze w godz. 8:00 – 18:00,
zaś ze zobowiązania zamawiającego wynika, że maksymalnie zamawiający może żądać
trzech takich pracowników, ale tych trzech może być w godz. 8:00-16:00, a na godziny
16:00-18:00 musi być jeden. Co więcej konsultacje mogą być udzielane grupowo w grupach
nie więcej niż 15 osób, a sale dla tych konsultacji zapewni zamawiający. W tej sytuacji, w

ocenie Izby, jeśli chodzi o udzielanie wyjaśnień opis przedmiotu zamówienia jest
jednoznaczny i wyczerpujący. Co do szkoleń, to zamawiający zarówno w OPZ jaki i w IPU
zawarł swoje wymagania, z których wynika, że wykonawca zobowiązany jest do realizacji
szkoleń, które przygotują pracowników zamawiającego do prowadzenia samodzielnych prac
administracyjnych i rozwojowych systemu BE będącego przedmiotem zamówienia. Celem
szkoleń jest w szczególności:
1) merytoryczne przygotowanie pracowników zamawiającego do samodzielnej realizacji
zadań administracyjnych i rozwojowych;
2) przekazanie pracownikom zamawiającego wiedzy oraz umiejętności korzystania z
oferowanego rozwiązania.
W ramach szkolenia wykonawca ma dostarczyć materiały szkoleniowe w postaci co najmniej
prezentacji szkoleniowej oraz podręcznika. Szkolenia mają być prowadzone dla danej funkcji
następujących osób:
1) Administratorzy biznesowi;
2) Administratorzy techniczni;
3) Administratorzy ds. bezpieczeństwa;
4) Osoby odpowiedzialne za rozwój.
Terminy szkoleń strony uzgodnią w planie szkoleń. Zamawiający zapewni salę szkoleniową.
Szkoleń metodycznych, produktowych i warsztatów mają być prowadzone dla maksymalnie
20 członków Zespołu Projektowego (administrator bezpieczeństwa, administrator biznesowy,
administrator eksploatacji aplikacji, administrator techniczny, osoby odpowiedzialne za
rozwój); mogą być łączone w grupach uczestników nie większych niż 10 osób. Powinny być
rozłożone odpowiednio do Faz Planu Wdrożenia. W ocenie Izby został określony cel i
sposób prowadzenia szkoleń, maksymalna liczba uczestników i maksymalna liczba osób w
grupie szkoleniowej. Odwołujący nie wykazał, że twierdzenie zamawiającego, że ilość godzin
szkoleń potrzebnych na osiągnięcie celu założonego przez zamawiającego nie jest możliwe
przez samego wykonawcę. W tym stanie rzeczy Izba uznała, że brak jest podstaw do
stwierdzenia, że opis przedmiotu zamówienia nie zawiera dostatecznie dokładnych określeń
pozwalających na sporządzenie oferty. Izba zwraca uwagę, że sam fakt określenia
przedmiotu zamówienia mniej dokładnie niż oczekuje tego wykonawca nie przesądza
jeszcze o niejednoznacznym i niewyczerpującym opisie przedmiotu zamówienia. W ocenie
Izby to na odwołującym ciążył obowiązek wykazania, że dane podane mu przez
zamawiającego nie pozwalają na sporządzenie oferty i wycenę kosztów związanych ze

świadczeniem usługi konsultacji i szkolenia. Mając powyższe na uwadze Izba nie dopatrzyła
się w działaniu zamawiającego naruszenia zarzucanych zamawiającemu przepisów ustawy.

Zarzut naruszenia przez zamawiającego art. 473 § 1 KC , art. 487 § 2 KC, art. 5 i art. 58 § 1 i
2 KC w związku z art. 14 i art. 139 ustawy przez sporządzenie załącznika nr 2 do SIWZ -
Istotne Postanowienia Umowy - § 134,135,136,137,140,156 w sposób nakładający
odpowiedzialność wykonawcy także w przypadku braku winy wykonawcy

Zarzut został cofnięty na rozprawie i nie podlegał rozpoznaniu.

Zarzut naruszenia przez zamawiającego art. 471 KC w związku z art. 483 i art. 484 KC, a
także art. 353
1
KC w związku z art. 14 i art. 139 ustawy przez sporządzenie załącznika nr 2
do SIWZ - Istotne Postanowienia Umowy - § 134 i 135 i przewidzenie rażąco wysokiej kary
umownej oraz brak adekwatności wysokości kary do wynagrodzenia wykonawcy.

Zarzut został cofnięty na rozprawie i nie podlegał rozpoznaniu.

Zarzut naruszenia przez zamawiającego właścicielskich ram autorskich praw majątkowych i
zasady uczciwej konkurencji, a także naruszenie zagadnień związanych z ochroną know-
how wykonawcy i jego tajemnicy przedsiębiorstwa przez sporządzenie załącznika nr 2 do
SIWZ - Istotne Postanowienia Umowy - załącznik nr 3 do Umowy- Prawa własności
intelektualnej, §6 ust.3) i 4), §7 ust5) w sposób zapewniający zamawiającemu prawa do
obrotu oraz rozpowszechniania pozostałą dokumentacją oraz oprogramowaniem

Zarzut został cofnięty na rozprawie i nie podlegał rozpoznaniu.

Zarzut naruszenia przez zamawiającego zasady równego traktowania wykonawców przez
sporządzenie załącznika nr 2 do SIWZ - Istotne Postanowienia Umowy - załącznika nr 3 do
Umowy- Prawa własności intelektualnej, §8 – i wprowadzenie odrębnych zasad
licencjonowania oprogramowania dla wykonawców, którym nie przysługują prawa własności
intelektualnej do oprogramowania

Zarzut nie zasługuje na uwzględnienie. Odwołujący nie kwestionował, że zamawiający w
sposób prawidłowy elastycznie podszedł do licencji wykonawców nie będących twórcami
oprogramowania. Bezsporne było pomiędzy stronami także to, że kwestionowane

postanowienia par. 8 załącznika nr 3 do IPU dotyczą wyłącznie oprogramowania
standardowego i pomocniczego, a nie dotyczą oprogramowania dedykowanego.
Zamawiający na rozprawie postawił tezę, że w przypadku wykonawców nie będących
twórcami oprogramowania nie mógł wskazać konkretnych pół eksploatacji bez narażenia się
na zarzut ograniczania konkurencji, nadto zamawiający wskazał, że zakresy przeniesienia
praw zależnych tak wykonawców twórców jak i wykonawców nietwórców są takie same.
Odwołujący natomiast nie wykazał, że zakresy te są nieporównywalne, wskazywał jedynie na
potencjalną możliwość węższego zakresu licencji wykonawców nietwórców i to jedynie w
odniesieniu do oprogramowania standardowego. Odwołujący nie wskazał w szczególności,
które postanowienia par. 8 świadczą o węższym zakresie przeniesienia praw i z których
wywodzi nieporównywalność ofert. Izba stwierdziła, że naruszenia przez zamawiającego
przepisów ustawy, a w szczególności zarzucanego art. 7 ust. 1 ustawy musi mieć charakter
realny, a nie potencjalny hipotetyczny. Odwołujący nawet nie uprawdopodobnił swoich
twierdzeń, co więcej jego żądanie nie zmierzało do doprecyzowania zakresu przeniesienia
praw wykonawców nietwórców przez choćby oczekiwanie wskazania tych samych pól
eksploatacji, co dla wykonawców twórców. Żądanie odwołującego zmierza bowiem
wyłącznie do ograniczenia zakresu zastosowania par 8 wyłącznie do licencji na
oprogramowanie pomocnicze, jednak takie żądanie powoduje, że zamawiający traci
jakiekolwiek prawa do żądania przeniesienia praw do oprogramowania standardowego od
wykonawców nietwórców. Wynika to z faktu, że par. 7 dotyczy oprogramowania
standardowego, pomocniczego i dedykowanego do których przysługują wykonawcy
autorskie prawa majątkowe, a żądany par. 8 dotyczyłby wyłącznie licencji do korzystania z
Oprogramowania Pomocniczego, do których nie przysługują wykonawcy Prawa własności
intelektualnej. W efekcie żądanie odwołującego nie zmierza do przywrócenia równowagi
pomiędzy wykonawcami, a do zaistnienia realnej nierówności pomiędzy wykonawcami
twórcami oprogramowania standardowego, którzy muszą realizować obowiązki z par. 7 i
wykonawcami nietwórcami oprogramowania standardowego, którzy nie mają żadnych
obowiązków w wyniku proponowanej modyfikacji. Co więcej w ocenie Izby takie żądanie nie
pokrywa się z usprawiedliwionymi potrzebami zamawiającego. Mając na uwadze powyższe
Izba nie dopatrzyła się w działaniu zamawiającego naruszenia art. 7 ust. 1 ustawy.

Zarzut naruszenia przez zamawiającego art. 7 ust. 3 ustawy, gdyż zamówienie może zostać
udzielone wykonawcy, który złożył ofertę podlegającą odrzuceniu, oraz art. 89 ust, 1 pkt 2)
ustawy, gdyż zamawiający sam pozbawił się możliwości weryfikacji ofert - załącznik nr 2 do
SIWZ - Istotne Postanowienia Umowy, § 70 - 72 w związku z Rozdziałem XVI „Kryteria
oceny ofert oraz ich znaczenie" SIWZ pkt 4 przez brak zasad oceny ofert

Zarzut został cofnięty w piśmie przygotowawczym z dnia 19 września 2014r. i nie podlegał
rozpoznaniu.

Zarzut naruszenia przez zamawiającego art. 89 ust. 1 pkt 2) ustawy w związku z art. 91 ust.
1 -2 ustawy przez sporządzenie rozdziału XVI „Kryteria oceny ofert oraz ich znaczenie" SIWZ
pkt 4 ppkt 3) i nieuzasadnione zastosowanie art. 89 ust. 1 pkt 2) ustawy do kryterium oceny
ofert.

Zarzut został cofnięty w piśmie przygotowawczym z dnia 19 września 2014r. i nie podlegał
rozpoznaniu.

Zarzut naruszenia przez zamawiającego art. 29 ust. 1 ustawy przez sporządzenie załącznika
nr 2 do SIWZ - Istotne Postanowienia Umowy: § 1 i załącznika nr 4 do Umowy §2 i
określenie otwartego zakresu definicji Awarii, Błędu, Usterki i otwartego zakresu serwisu

Zarzut nie zasługuje na uwzględnienie. Art. 29 ust. 1 ustawy stanowi, że 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. Niewątpliwie na kalkulację i sporządzenie oferty
na wpływ wycena ryzyka związanego z czasem reakcji w przypadku wystąpienia wady
zaoferowanego systemu i ryzyka poniesienia kary związanej z niewywiązaniem się przez
wykonawcę z obowiązków umownych związanych z usunięciem wady. Jednak ustawodawca
mówiąc o opisie jednoznacznym i wyczerpującym mówi także o używaniu dostatecznie
dokładnych i zrozumiałych określeń. Ustawodawca zatem zakłada pewien margines
dokładności jaka musi być przez zamawiających stosowana przy definiowaniu używanych
pojęć. W przedmiotowej sprawie zamawiający zdefiniował pojęcie wady, awarii, błędu,
usterki i zgłoszenia problemu. Pojęciem wady zamawiający objął wszystkie pozostałe
nieprawidłowości i jednocześnie wbrew stanowisku odwołującego dla awarii – błędu
krytycznego w ocenie izby zamawiający skonstruował zamknięty katalog wad kwalifikujących
nieprawidłowość do awarii. Jest to wada polegająca na nieprawidłowym funkcjonowaniu
oprogramowania, w tym funkcjonowanie niezgodne z dokumentacją, które wywołuje
określone skutki lub polega na określonych zdarzeniach. Te skutki i zdarzenia zostały
wyczerpująco wymienione w 9 punktach i zaistnienie któregokolwiek z nich powoduje, że
dana wada jest awarią. Odwołujący w żaden sposób nie wykazał, że wady opisane w 9
punktach są wadami, które są charakterystyczne dla pola definicyjnego błędu czy usterki.
Dla błędu i usterki zamawiający nie dokonał enumeratywnego wyliczenia zdarzeń czy
skutków powodujących zakwalifikowanie danej nieprawidłowości jako błędu, czy usterki, ale

podał reguły interpretacyjne jakimi będzie się kierował przy kwalifikacji konkretnej
nieprawidłowości i tak błąd zachodzi wtedy, gdy nieprawidłowość jest skutkiem
niemieszczącym się w zamkniętym katalogu awarii, ani nie jest usterką, ale która skutkuje
błędnym albo nieskutecznym wprowadzaniem, przetwarzaniem, lub wyprowadzaniem
informacji oraz każda sytuacja, w której niespełnione zostały parametry wydajnościowe
określone w OPZ lub Dokumentacji, zaś usterka zachodzi wtedy, gdy wada nie jest awarią
ani błędem i nie ogranicza zakresu funkcjonalnego systemu. Zamawiający dla usterki
dodatkowo dla dokładniejszego określenia pojęcia usterka wskazał na przykładowe
nieprawidłowości, które będą przez zamawiającego kwalifikowane jako usterka - na przykład
błędy w prezentacji graficznej (nie obejmujące cyfr), semantyczne i składniowe, które nie
rodzą konieczności istotnych dodatkowych nakładów pracy użytkownikom lub
administratorom SystemuBE.
W ocenie Izby odwołujący nie wykazał wzajemnego przenikania się powyższych definicji i
poprzestał w tym zakresie na gołosłownym twierdzeniu. Izba dała natomiast wiarę
wyjaśnieniom zamawiającego, że zarzut w rzeczywistości zmierza do ograniczenia
czynności naprawczych wykonawcy jedynie do przypadków związanych z nieprawidłowością
polegającą na niezgodności z dokumentacją. Nie budzi wątpliwości Izby, że zamawiający
przedstawił kilka przykładów nieprawidłowości, które nie muszą być wynikiem niegodności z
dokumentacją, a będą powodować nieprawidłowe funkcjonowanie systemu. W ocenie Izby
odwołujący podnosząc powyższy zarzut winien był wykazać, że użyte przez zamawiającego
definicje nie są dostatecznie dokładne w rozumieniu art. 29 ust. 1 ustawy, jednak odwołujący
temu ciężarowi nie podołał. Co do zarzutu otwartości pojęcia usługi serwisowej, to
rzeczywiście zamawiający nie zawarł zamkniętego katalogu takich usług, a posłużył się
przykładowym wyliczeniem. Jednak w ocenie Izby nie można zgodzić się z twierdzeniem
odwołującego, że z powodu otwartego katalogu usług serwisowych wymienionych w par 2
załącznika nr 4 do IPU, zamawiający może zobowiązać go do świadczenia dowolnych usług.
Odwołujący pominął definicję zawartą w par. 1 IPU, a zatem to, że usługą serwisową jest
tylko taka usługa, która jest związana z utrzymaniem i prawidłowym funkcjonowaniem
systemu, pominął także definicję rozwoju i jej ścisły zakres, a także to, że w par. 2 załącznika
nr 4 do IPU w pkt 2.5. i 2.6 dodatkowo w sposób zamknięty opisano czynności wykonawcy
dodatkowo wchodzące w skład serwisu. Nadto IPU wyraźnie wskazuje także na rozróżnienie
zamawiającego pomiędzy usługami świadczonymi w okresie stabilizacji, jak i usługami
serwisowymi, a także wskazuje, że usługi serwisowe nie będą świadczone w stosunku do
elementów Infrastruktury i Oprogramowania Pomocniczego dostarczanych przez
zamawiającego. W ocenie Izby te wszystkie elementy pozwalają stronom na ocenę jakie
czynności wchodzą w skład usług serwisowych i nie pozwalają zamawiającemu na
dowolność w nakładaniu na wykonawcę obowiązków dodatkowych. Odwołujący nie wykazał

jakie usługi przy tak skonstruowanym IPU i jego załącznikach nie mieszczą się w zakresie
usług serwisowych, a mogłyby mu zostać narzucone w wyniku dopuszczalnej interpretacji
par 2. pkt 2.3. załącznika nr 4 do IPU. W tym stanie rzeczy Izba nie dopatrzyła się w
działaniu zamawiającego naruszenia art. 29 ust. 1 ustawy.

Mając na uwadze powyższe Izba orzekła jak w sentencji na podstawie art. 192 ust. 1 i 2
ustawy.

O kosztach postępowania orzeczono na podstawie art. 192 ust. 9 i 10 ustawy stosownie do
wyniku spraw oraz zgodnie z § 3 pkt. 1 i 2 lit. b i § 5 ust. 3 pkt 1 rozporządzenia Prezesa
Rady Ministrów z dnia 15 marca 2010 r. w sprawie wysokości i sposobu pobierania wpisu od
odwołania oraz rodzajów kosztów w postępowaniu odwoławczym i sposobu ich rozliczania
(Dz. U. Nr 41, poz. 238) obciążając odwołujących kosztami postępowania w postaci
uiszczonego wpisu od odwołania oraz nakazując odwołującemu zwrot zamawiającemu
kosztów zastępstwa prawnego zgodnie ze złożoną fakturą.

Przewodniczący: ……………

Wcześniejsze orzeczenia:

Sygn. akt KIO 263/15 z dnia 2015-12-23
Sygn. akt KIO 245/15, KIO 305/15 z dnia 2015-03-04
Sygn. akt KIO 270/15 z dnia 2015-03-03
Sygn. akt KIO 273/15 z dnia 2015-02-27
Sygn. akt KIO 267/15 z dnia 2015-02-27

Baza orzeczeń KIO - wyszukiwarka

Najnowsze orzeczenia

Najnowsze przetargi

Najnowsze wyniki przetargów

Kodeksy

Pokaż wszystkie