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

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

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
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/
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: „§
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 §
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. §
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. §
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,

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

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."
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".
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."
dopisania w Rozdziale XVI siwz sposobu oceny przez Zamawiającego próbki potwierdzającej posiadanie deklarowanych funkcjonalności standardowych,
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.
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.
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:
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ą:
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.
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/
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/
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.
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.
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.
poz. 98 – powiadomienia o zdarzeniach – jak wyżej, Wymaganie 14.
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.
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.
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.
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.
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.
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
2- 19.5 i określają one precyzyjnie wymagania dla tego obszaru. Wymaganie 19.
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.
poz. 195 – to wymaganie dotyczy jedynie prezentacji danych, zakres prezentowanych danych, według zamawiającego nie ma znaczenia dla pracochłonności. Wymaganie 21.
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.
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.
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.
poz. 233 i 23.5 poz. 234,
6 poz. 235– jak wyżej Wymaganie 23.
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.
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-
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/
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/
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.
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).
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;
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;
Szata graficzna zostanie przygotowana zgodnie ze standardami określonymi w Księdze Identyfikacji Wizualnej Banku Gospodarstwa Krajowego, przekazanej przez Bank Wykonawcy na etapie analizy:
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;
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;
Świadczenie usług Rozwoju i Walidacji w stosunku do dostarczonego SystemuBE na warunkach opisanych w Istotnych Postanowieniach Umowy. III. Wymagania funkcjonalne
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ść.
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).
Brak zaoferowania w Ofercie którejkolwiek z funkcjonalności skutkować będzie odrzuceniem Oferty ze względu na jej niezgodność z treścią SIWZ.
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.
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.
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
Obowiązki wykonawcy modyfikacji w kontekście budowania paczek produkcyjnych oraz oznaczania wersji w repozytorium zostaną uszczegółowione na etapie analizy.
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).
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.
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
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
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.
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ęcznika
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. ‘&’, ‘ 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
PRZEBIEG PRAC WDROŻENIOWYCH określił weryfikację Oprogramowania Standardowego, jako: §
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. §
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. §
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,

§ 71

W rozdziale
PRZEKAZANIE WIEDZY wskazał, że: §
Od dnia zawarcia Umowy Wykonawca zobowiązany jest do przekazania do Za- mawiającego wiedzy na temat SystemuBE, na zasadach opisanych poniżej. §
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. §
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. §
Działania,

ROZDZIAŁ 11.§ 112 i następnych obejmują:

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.
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.
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. §
Każde działanie,

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

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
ODPOWIEDZIALNOŚĆ. KARY UMOWNE zamawiający m. in. określił poniższe kary umowne: §
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:
kary umownej w wysokości 50000 złotych brutto za każdy rozpoczęty tydzień opóźnienia w wykonaniu Fazy w ramach Etapu 1;
kary umownej w wysokości 35000 złotych brutto za każdy rozpoczęty tydzień opóźnienia w wykonaniu Fazy w ramach Etapu 2;
kary umownej w wysokości 20000 złotych brutto za każdy rozpoczęty tydzień opóźnienia w wykonaniu Fazy w ramach Etapu 3; §
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. §
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. §
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:
w przypadku Awarii – 2000 zł brutto za każdą rozpoczętą godzinę udostępnienia usług, objętych Awarią;
w przypadku Błędów – 2000 zł brutto za każdą rozpoczęty kolejny dzień roboczy naprawy;
w przypadku Usterek – 1000 zł brutto za każdą rozpoczętą (drugą i następne) krotność czasu przewidzianego Umową dla usunięcia Usterki;
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. §
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. §
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:
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,
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 §
W takim przypadku Wykonawcy nie będzie przysługiwało wynagrodzenie za wykonaną pracę,
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,
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,
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,
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,
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 §
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:
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.
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.
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.
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.
Zamawiający może zlecić innym podmiotom tłumaczenia, adaptację (opracowań),wprowadzanie zmian, uzupełnień i modyfikacji.
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.
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 §
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.
Prawa,

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.
Licencja ma charakter niewyłączny.
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.
Przejście na Zamawiającego praw lub ich udzielenie,

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

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

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.
Wraz z przeniesieniem praw,

§ 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,

§ 7

, powoduje przejście na BGK prawa własności nośników na których Oprogramowanie zostało przekazane Zamawiającemu. §

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.
Wykonawca spowoduje udzielenie licencji na Oprogramowanie w dniu podpisania Protokołu odbioru, ale w żadnym wypadku, nie później niż w dniu Startu Produkcyjnego.
Licencje,

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,

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ą toc

🔗 Do źródła urzędowego

Wyjaśnienie AI na podstawie urzędowego tekstu ustawy. Orientacyjne, nie zastępuje porady prawnej.