Wyrok KIO 1878/14

Sygn. akt: KIO 1878/14 WYROK z dnia 25 września 2014 r. Krajowa Izba Odwoławcza - 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. 3531 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. 3531 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. 3531 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: ……………