Wdrożenie Centralnego Systemu Bankowego (CSB)
Transkrypt
Wdrożenie Centralnego Systemu Bankowego (CSB)
Załącznik nr 2 do Zaproszenia do udziału w dialogu technicznym – Wdrożenie Centralnego Systemu Bankowego (CSB) Warszawa, 17 czerwca 2014 Wdrożenie Centralnego Systemu Bankowego (CSB) etap dialogu technicznego – informacje o zakresie zamówienia Strona 1 z 18 Spis treści CEL DOKUMENTU .............................................................................................................................................................................................................................. 3 FUNKCJONALNY ZAKRES SYSTEMU .................................................................................................................................................................................................. 3 FUNKCJONALNOŚCI NIETYPOWE, KTÓRE MOGĄ WYMAGAĆ SPECYFICZNEJ IMPLEMENTACJI DLA BGK ......................................................................................... 7 INFORMACJA O APLIKACJACH, Z KTÓRYMI WYKONAWCA ZINTEFEJSUJE OFEROWANY SYSTEM .................................................................................................. 10 PODSUMOWANIE POZAFUNKCJONALNEGO ZAKRESU PROJEKTU ................................................................................................................................................ 12 INFORMACJE O PRZEWIDYWANEJ SKALI UŻYCIA SYSTEMU ............................................................................................................................................................ 16 ISTOTNE POSTANOWIENIA UMOWY MOGĄCE MIEĆ WPŁYW NA KOSZT PROJEKTU ..................................................................................................................... 17 Strona 2 z 18 CEL DOKUMENTU Celem niniejszego dokumentu jest przedstawienie zakresu planowanego zamówienia publicznego na wdrożenie Centralnego Systemu Bankowego (Systemu CSB), jak również ułatwienie uczestnikom zrozumienia zakresu funkcjonalności oczekiwanej przez Zamawiającego od Systemu CSB. Dokument ten nie może być traktowany jako specyfikacja wymagań i nie może być używany w ewentualnych sporach dotyczących zakresu oczekiwanej funkcjonalności Systemu CSB. Dokument stanowi załącznik do ogłoszenia o przeprowadzeniu dialogu technicznego. FUNKCJONALNY ZAKRES SYSTEMU Zakres funkcjonalności oczekiwany przez Zamawiającego: Obszar Komentarz do zakresu funkcjonalnego Funkcjonalność podstawowej działalności bankowej Obejmuje standardową (podstawową) dla rynku polskiego funkcjonalność oferowaną przez większość systemów bankowych: Kartoteki klienta (CIF – Customer Identification File) Rachunków bieżących i lokat terminowych (w tym O/N) Obsługi identyfikacji masowych płatności przychodzących (SIMP) Rachunków wirtualnych i technicznych Płatności krajowych i międzynarodowych (przelewy krajowe w tym US, ZUS, przelewy krajowe natychmiastowe, przelewy SORBNET2, przelewy zagraniczne SEPA, TARGET2, SWIFT) Kredytów, poręczeń i gwarancji krajowych, zabezpieczeń Kart płatniczych Trade finance Zarządzania gotówką w oddziale Usługi płynnościowe Konsolidacja sald (rzeczywista, wirtualna), Sweeping, saldo netto) Strona 3 z 18 Obszar Komentarz do zakresu funkcjonalnego W obszarze tym wymaganych jest ok. 200 raportów operacyjnych i sprawozdawczości dodatkowej. Przez raporty operacyjne rozumie się raporty wykorzystywane przez użytkowników systemu w codziennej pracy operacyjnej w celu np. potwierdzenia prawidłowości wykonania operacji i księgowań, ustalenia listy rachunków, zabezpieczeń, etc., które wymagają określonych manualnych czynności administracyjnych. Opis sprawozdawczości dodatkowej znajduje się w dalszej części dokumentu. Funkcjonalność wspierająca obszar Działalność Zlecona Fundusze i Programy – DZ(FP) W ramach obszaru DZ(FP) Bank obsługuje m.in.: 1. fundusze związane z działalnością zleconą: - fundusze przepływowe mające na celu zarządzenie środkami finansowymi powierzonymi bankowi na określone cele budżetowe, - fundusze kredytowe mające na celu dofinansowywanie konkretnych inwestycji, 2. pozostałe inicjatywy i programy. Działalność operacyjna obszaru DZ(FP) jest częściowo zautomatyzowana przy pomocy platformy typu workflow komunikującej się z obecnym systemem transakcyjnym poprzez szynę ESB – BGK planuje zachowanie używanej obecnie platformy workflow. Oczekiwany zakres funkcjonalny dla Systemu CSB: umożliwienie ewidencji księgowej produktów (rachunków bieżących, kredytów, etc.) otwartych w ramach poszczególnych funduszy i programów w odrębnych księgach lub podksięgach otwieranie i prowadzenie (modyfikację) kartotek klientów CIF otwieranie i prowadzenie standardowych rachunków bankowych wykonywanie płatności w ciężar tych rachunków zróżnicowanie prowadzonej ewidencji księgowej w zależności od typu produktu umożliwienie wygenerowania bilansu, rachunku zysków i strat, rachunku obrotów dla poszczególnych funduszy i programów generowanie raportów sprawozdawczości dodatkowej, specyficznych dla poszczególnych funduszy i programów W obecnym systemie dla poszczególnych programów i inicjatyw otwartych jest do kilku typów rachunków, na których Strona 4 z 18 Obszar Komentarz do zakresu funkcjonalnego gromadzone są dedykowane środki powierzone bankowi na konkretne cele budżetowe. Każdy z tych rachunków ma zdefiniowany indywidualny zestaw schematów księgowych na bazie kont księgowych dedykowanych do obsługi programu/inicjatywy, co pozwala na ujęcie księgowe środków zgodnie z ich przeznaczeniem oraz pozyskania informacji dla celów sprawozdawczych. Funkcjonalność wspierająca rachunkowość Zasady (polityka) rachunkowości BGK prowadzone są na podstawie zasad określonych w ustawie z dnia 29 września 1994 roku o rachunkowości (Dz. U. z 2013 r. poz. 330, z późn. zm.) oraz wydanych na jej podstawie przepisach wykonawczych. Istotnym wymaganiem dla obszaru rachunkowości jest: 1. optymalnie możliwość utworzenia dwóch planów kont: „bankowego” oraz „ewidencyjnego” (jeśli drugi plan kont nie jest dostępny bezpośrednio, dopuszczalne - poprzez funkcjonalności księgi) 2. możliwość prowadzenia osobnych ksiąg z możliwością bilansowania się pojedynczej księgi oraz zdefiniowanej grupy ksiąg (w pojedynczej księdze obowiązuje jeden z dwóch w/w planów kont. Nie zachodzi przypadek: dwa plany kont w pojedynczej księdze) System CSB musi zapewnić m.in. następujące funkcjonalności: prowadzenia ewidencji w odrębnych księgach rachunkowych standardowe funkcjonalności księgi: prowadzenie w języku polskim, w PLN, posiadanie dziennika i ewidencji syntetycznej możliwość sporządzenia bilansu, rachunku zysków i start, pozycji pozabilansowych dla sumy wybranych ksiąg (oraz pojedynczej księgi) możliwość konsolidacji kilku wybranych ksiąg w jedną księgę główną, zmianę liczby ksiąg w wyniku odpowiedniego sparametryzowania elastyczne parametryzowanie ksiąg zgodnie z potrzebami (w tym tworzenie podksiąg) definiowanie indywidualnych schematów księgowych dla wszystkich produktów obsługiwanych przez Bank i ich późniejszą modyfikację definiowanie schematów księgowych dla operacji nietypowych (co najmniej: restrukturyzacja umów, aneksowanie umów, ugody, indywidualna obsługa klienta, umorzenie kredytów, zwrot umorzenia). W obecnej strukturze występuje 10 ksiąg dla działalności własnej i funduszy przepływowych. Ewidencja księgowa pozostałych Strona 5 z 18 Obszar Komentarz do zakresu funkcjonalnego inicjatyw i programów prowadzona jest w ramach wydzielonych podksiąg w ramach działalności własnej. Patrz tabela Rodzaje działalności i implikacje na księgi Banku. Patrz Podzakres Funkcjonalność wspierająca obszar DZ(FP). Sprawozdawczość Obszar ten obejmuje raportowanie, które Bank jest zobowiązany przygotowywać dla instytucji nadzorujących (NBP, KNF, etc.) oraz raporty statutowe (roczne lub okresowe sprawozdanie finansowe). Obowiązek ich sporządzenia oraz zakres wynika z powszechnie obowiązującego prawa (ustawy, rozporządzenia krajowe i unijne), aktów prawnych pochodzących od organów NBP, które dotyczą działalności ogółu banków w Polsce. Sprawozdanie finansowe Banku sporządzane jest zgodnie z przepisami ustawy z dnia 29 września 1994 roku o rachunkowości (t.j. Dz. U. z 2013 r. poz. 330) i wydanymi na jej podstawie przepisami, rozporządzeniem Ministra Finansów z dnia 19 lutego 2009 r. w sprawie informacji bieżących i okresowych przekazywanych przez emitentów papierów wartościowych oraz warunków uznawania za równoważne informacji wymaganych przepisami prawa państwa niebędącego państwem członkowskim (t.j. Dz. U. z 2014 r. poz. 133) oraz rozporządzeniem Ministra Finansów z dnia 18 października 2005 r. w sprawie zakresu informacji wykazywanych w sprawozdaniach finansowych i skonsolidowanych sprawozdaniach finansowych, wymaganych w prospekcie emisyjnym dla emitentów z siedzibą na terytorium Rzeczypospolitej Polskiej, dla których właściwe są polskie zasady rachunkowości (t.j. Dz. U. z 2014r. poz. 300). Data mart sprawozdawczy. Wdrażając oferowany system Wykonawca może użyć aplikacji SPID używanej obecnie przez Bank. Repozytorium danych systemu ułożone w modelu umożliwiającym na ich podstawie realizowanie funkcji raportowania analitycznego, sprawozdawczości oraz przekazania zbiorów danych na potrzeby wyceny MSSF i do aplikacji sprawozdawczej. Ekstrakcja danych z wdrażanego systemu do data martu oraz Zarządczej Hurtowni Danych (ZHD jest poza zakresem projektu) powinna być realizowana jednym spójnym mechanizmem. Raporty sprawozdawczości dodatkowej rozumiane jako raporty wynikające z umów z klientami Banku, w tym także ministerstwami, agencjami rządowymi, etc., realizowane w ramach obsługi przez Bank sprzedanego produktu lub usługi. W specyficznych przypadkach Raporty te mogą być wymagane na skutek ustaw lub aktów niższego rzędu dedykowanych działalności wyłącznie BGK, nie są jednak kwalifikowane jako raporty sprawozdawczości obowiązkowej. Strona 6 z 18 Strona 7 z 18 FUNKCJONALNOŚCI NIETYPOWE, KTÓRE MOGĄ WYMAGAĆ SPECYFICZNEJ IMPLEMENTACJI DLA BGK Niniejszy rozdział zawiera informację o funkcjonalnościach nietypowych, które mogą wymagać implementacji specyficznej dla BGK. Obszar (Potencjalnie) nietypowa funkcjonalność wymagana dla BGK Rachunki Bieżące i Lokaty Depozyt@24 (Sumy depozytowe) Funkcjonalność oparta na prowadzeniu wielu rachunków wirtualnych do jednego głównego rachunku sum depozytowych i ewidencji na nich środków przyporządkowanych do konkretnej sprawy Klienta. Do każdego rachunku wirtualnego naliczane są odsetki od daty utworzenia do daty likwidacji rachunku wirtualnego. Funkcjonalność produktu zezwala na wielokrotne wpłacanie lub wypłacanie środków z rachunku wirtualnego. Oprocentowanie jest przypisane zarówno do rachunku głównego jak i do wszystkich rachunków wirtualnych. Poszczególne rachunki wirtualne posiadają własny numer NRB oraz dodatkowe rejestry (pola pomocnicze). Konsolidacja finansów Skarbu Państwa Procesowi konsolidacji finansów Skarbu Państwa podlegają wyłącznie wskazane rachunki prowadzone na rzecz podmiotów określonych w Ustawie. W przypadku wykonywania procesu konsolidacji na rachunku z uruchomioną usługą Depozyt@24, przeksięgowanie środków nie ma wpływu na historię operacji dla poszczególnych mikrolokat, w tym dla procesu naliczania odsetek dla każdej z nich. Odsetki naliczone w procesie konsolidacji mogą być rozliczane na wyodrębnionym rachunku. SIMP System Identyfikacji Masowych Płatności (SIMP) jest instrumentem opartym o transakcje/operacje wpłat identyfikowane przez tzw. „rachunki wirtualne" powiązane ze wskazanym rachunkiem do masowych płatności. Strona 8 z 18 Obszar (Potencjalnie) nietypowa funkcjonalność wymagana dla BGK Kredyty, Poręczenia i Gwarancje Obsługa SIMIK Karty BGK używa zewnętrznej firmy do obsługi kart. System outsourcera kart odpowiedzialny jest za: Obsługa Gotówki System musi umożliwiać powiązanie umowy kredytowej i stowarzyszonych rachunków z kodem SIMIK (System Informatyczny Monitoringu i Kontroli finansowej Funduszy Strukturalnych i Funduszu Spójności.). Powiązanie dotyczy rachunków ewidencjonowanych w księgach Banku, rachunków ewidencyjnych oraz operacji wykonywanych na tych rachunkach. Pełnienie funkcji Visa Access Point Wydanie karty oraz autoryzacje i rozliczanie transakcji Interfejs do systemu pośredniczącego w wymianie informacji z podmiotami zewnętrznymi, pełniącymi funkcję agenta BGK dla operacji gotówkowych (obciążenia i uznania rachunków bieżących, blokady środków,) Strona 9 z 18 INFORMACJA O APLIKACJACH, Z KTÓRYMI WYKONAWCA ZINTEFEJSUJE OFEROWANY SYSTEM Obszar integracji Opis Do wykonania przez Wykonawcę Biuro Informacji Kredytowej Biuro Informacji Kredytowej w zakresie systemu BIK Kredytobiorcy oraz BIK Przedsiębiorcy -Interfejs wyjściowy w zakresie BIK Kredytobiorcy oraz BIK Przedsiębiorcy DiMon System analizy transakcji powiązanych i podejrzanych oraz sprawozdawczości obowiązkowej w zakresie raportowania do GIIF -Interfejs plikowy: zestaw danych na potrzeby raportowania do GIIF ElixirOK Międzybankowy system pośredniczący w elektronicznej wymianie komunikatów o zleceniach płatniczych oraz wierzytelnościach -Interfejs plikowy: zgodnie z dokumentacją ElixirOK System autoryzacji i rozliczeń kart płatniczych -Interfejs plików: Operacje, salda, autoryzacje (blokady), obciążenia/uznania, raporty, wnioski -Interfejs BIC-ISO: salda online SGP Aplikacja realizująca funkcjonalność zastępczej obsługi kasowejobsługa wypłat i wpłat gotówki zleconych przez klientów w Systemie/SystemieBE - Plikowy w standardzie Elixir oraz WebService SWIFT Alliance Access Society for Worldwide Interbank Financial Telecommunication -Interfejs plikowy: zgodnie z dokumentacją SWIFT Bankowy Rejestr klientów niesolidnych Związku Banków Polskich -Database: Interfejs w zakresie obsługi bankowego rejestru informacji o osobach i podmiotach gospodarczych, które: • czasowo nie wywiązują się ze zobowiązań kredytowych wobec banków • spełniają kryteria określone dla Podmodułu „F” tzw. baza miękka. Baza Dokumentów Zastrzeżonych -Database: Interfejs w zakresie obsługi zastrzeżeń z bazą DZ System rozliczeniowy do rozliczeń wysokokwotowych, prowadzony przez NBP -Interfejs plikowy: zgodnie z dokumentacją Sorbnet 2 System (u) outsourcera kart System BR (MIG BR) System DZ (dawny MIG DZ) UPPS SORBNET2 Strona 10 z 18 Obszar integracji MSSF Opis System wyliczający impairment kredytowy wg MSSF Do wykonania przez Wykonawcę - Interfejs plikowy wyjściowy zawierający informacje niezbędną do wyliczenia impairmentu kredytowego. - interfejs plikowy wejściowy ładujący wyliczony impairment kredytowy. def3000/TR (iForce) SAK - KFM Szyna ESB HR System do obsługi transakcji skarbowych i instrumentów finansowych, na rynku międzybankowym oraz z klientami wewnętrznymi Banku System Administracji Kredytów Krajowego Funduszu Mieszkaniowego - Interfejs on-line: dekrety księgowe, weryfikacja sald / blokady środków na rachunku bieżącym, pobranie kartoteki klienta, dane do pralni, dane dotyczące lokat negocjowanych i transakcji na bonach skarbowych - interfejs wsadowy: komunikaty swift WE / WY MT 103, parametry transakcji / dane transakcyjne -Interfejs request / response: interfejs księgowy (syntetyka), dyspozycje na wypłatę transz, dane do pralni; Interfejs wsadowy: dane na potrzeby HD Warstwa integracyjna udostępniana przez Bank (Red Hat Fuse ESB wersja 4.4 lub nowsza lub Red Hat JBoss FUSE 6 lub nowsza) -Implementacja usług udostępnianych przez Szynę ESB, od strony systemu centralnego Platforma bazodanowa SAP-HR na której wspólnie są osadzone systemy kadrowe eHR, mHR, eLearning -Interfejs wsadowy plikowy. Z uwagi na brak funkcjonalności importu danych kadrowych bezpośrednio z pliku do systemu centralnego defBank, dane te wprowadzane są ręcznie. Dla uproszczenia interfejs ten jest zamodelowany jako plikowy. Poniżej wymienione są systemy, wykorzystujące usługi wystawione na szynie ESB. Obowiązkiem Dostawcy będzie zapewnienie tego typu usług/funkcji po stronie wdrażanego systemu CSB, w taki sposób, aby mogły być one udostępnione wymienionym niżej systemom. Księga Gospodarki Własnej- księga pomocnicza zapewniająca CGW ewidencję zobowiązań i należności (rozrachunki z dostawcami i (Microsoft odbiorcami), oraz rozliczanie z pracownikami (wyjazdy służbowe, Dynamics AX) zaliczki, rozliczanie kart kredytowych pracowników), ewidencję majątku banku, zarządzanie gospodarką własną Banku. Bankowość System Bankowości Elektronicznej -Interfejs dwustronny pomiędzy CGW a Księgą Główną -Interfejs dwustronny - Konieczność udostępnienia funkcji/usług Strona 11 z 18 Obszar integracji Opis Do wykonania przez Wykonawcę Elektroniczna Ferryt Wyciągi Procesowa platforma workflow -Interfejs dwustronny - Konieczność udostępnienia funkcji/usług Generowanie wyciągów w dedykowanych dla poszczególnych klientów formatach (np. MT950, inne formaty tekstowe) -Funkcja zwracająca dane niezbędne do wygenerowania wyciągu PODSUMOWANIE POZAFUNKCJONALNEGO ZAKRESU PROJEKTU Zakres prac i dostaw niezwiązany z funkcjonalnością systemu może być podsumowany jako: 1. Migracja danych o BGK odpowiedzialny jest za dostarczenie danych z systemów źródłowych, wykonanie eksportu danych z obecnie eksploatowanych systemów, zgodnie ze specyfikacją migracji danych opracowaną przez Wykonawcę o BGK odpowiedzialny jest za dostarczenie dokumentacji tych danych o Wykonawca odpowiedzialny jest za transformację danych i ładowanie do instalowanego systemu o Migracja danych obejmuje następujące systemy: Zakres funkcjonalny System(y) Komentarz Podstawowa działalność bankowa Przeniesienie bilansem otwarcia wszystkich obrotów z systemu Zamawiającego. główny system transakcyjny: kartoteka klienta wraz z wszystkimi numerami modulo klienta (baza główna oraz wszystkie archiwa) rachunki bieżące (wraz z kredytami w rachunku bieżącym) w tym: W przypadku gdy przeniesienie obrotami będzie Strona 12 z 18 Zakres funkcjonalny System(y) a/ Depozyty@24 (Sumy depozytowe) b/ rachunki podlegające konsolidacji Finansów Publicznych (w tym Depozyty@24) c/ rachunki objęte systemem identyfikacji masowych płatności (SIMP) d/ zlecenia stałe rachunki depozytów terminowych w tym: a/ depozyty terminowe u Ministra Finansów księga główna płatności krajowe i zagraniczne (w tym zlecenia z datą przyszłą) system obsługi kredytów w tym: Umowy zaewidencjonowane w systemie Harmonogramy Zabezpieczenia Bilans otwarcia dla operacji wypłat i spłat Bilans otwarcia ESP system zarządzający kartami i interfejsami do outsourcera kart Komentarz niewystarczające – przeniesienia pojedynczych transakcji. Przeniesienie wszystkich rachunków funkcjonujących w bazie głównej oraz archiwum. Opracowanie przez Wykonawcę przy współpracy z Zamawiającym procedury i specyfikacji migracji danych oraz tabeli konwersji. oraz słowniki tabele oraz algorytmy stóp procentowych parametry dla obsługi PSD tabele walut wraz z kursami (w tym historyczne) Strona 13 z 18 2. Dostarczenie infrastruktury w architekturze trójwarstwowej: o dla środowiska produkcyjnego i preprodukcji dla systemu transakcyjnego w (konfiguracji HA) o dla środowisk nieprodukcyjnych – BGK przewiduje użycie 3 środowisk dla własnych celów o Infrastruktura będzie rozmieszczona w dwóch udostępnianych przez Bank ośrodkach obliczeniowych CPD i RCPD połączonych dwoma światłowodami w odległości po łączu do 30 km o Zwymiarowanie niezbędnej rozbudowy infrastruktury HD dla potrzeb datamartu sprawozdawczego Usługi sieci fizycznej dostarcza Bank. 3. Oprogramowanie narzędziowe: o Bazy danych, monitory transakcji, etc. 4. Utrzymanie aplikacyjnych środowisk nieprodukcyjnych: o Inicjalna instalacja środowisk aplikacyjnych o Implementacja początkowej parametryzacji biznesowej o Przekazanie procedur eksploatacyjnych dla zespołu Banku 5. Szkolenia o Szkolenia dla pracowników eksploatacji IT oraz użytkowników końcowych W przypadku użytkowników końcowych zakładane jest podejście train the trainer Szkolenia powinny być zgodne z dostarczoną dokumentacją systemu i dokumentacja szkoleniową 6. Usługi serwisowe i gwarancyjne: o Świadczenie tych usług rozpoczyna się w momencie pierwszego uruchomienia produkcyjnego systemu o Świadczenie tych usług kończy się 3 lata po zakończeniu projektu o Usługi te obejmują: Diagnostykę i naprawę błędów Strona 14 z 18 o o Wsparcie pracowników eksploatacji i utrzymania Banku Rozwiązywanie problemów wydajnościowych Aktualizację systemu i infrastruktury Dostosowanie systemu do koniecznych zmian technologicznych i infrastruktury, dla których producenci ogłosili wycofanie wsparcia. Weryfikację koncepcji rozbudowy infrastruktury Asystę techniczną Aktualizację dokumentacji Dostosowanie raportów sprawozdawczości SLA serwisowych i gwarancyjnych, w tym w zakresie usuwania nieprawidłowości działania systemu w terminach nie gorszych niż: Usunięcie Awarii – do 24 godzin od momentu przyjęcia zgłoszenia Usunięcie błędu – do 48 godzin od momentu przyjęcia zgłoszenia Usunięcie usterki – w najbliższym wydaniu/wersji ale nie później niż 90 dni kalendarzowych od przyjęcia zgłoszenia SLA dla infrastruktury 4 godziny naprawy lub obejścia Serwis producenta 7. Specyficzne oczekiwania pozafunkcjonalne: o System powinien mieć: otwarte API oraz oferować usługi integracyjne, których zakres musi umożliwić budowanie własnych frontendów. generator prostych raportów, które mogą być następnie udostępniane w ramach raportów operacyjnych mechanizmy umożliwiające techniczne i biznesowe monitorowanie wydajności systemu/aplikacji (wykrywanie błędów) pełne logowanie aktywności i zmian w systemie z możliwością sterowania wyłączeniami skali takiej rejestracji system powinien umożliwiać zarządzanie uprawnieniami na poziomie funkcji, danych, limitów itp. Strona 15 z 18 INFORMACJE O PRZEWIDYWANEJ SKALI UŻYCIA SYSTEMU Liczba rekordów opisujących klienta (firmy, osoby fizyczne, pełnomocnicy, poręczyciele, etc.): 250 000 Liczba aktywnych rachunków bankowych prowadzonych dla klientów : 100 000 Liczba rachunków technicznych (własnych Banku): 150 000 Liczba rachunków wirtualnych (o charakterystyce jak produkt SIMP): 2 000 000 Liczba rachunków wirtualnych (o charakterystyce jak produkt Depozyt@24): 1 000 000 Liczba użytkowników wewnętrznych (pracowników): 450 Średnia liczba jednoczesnych użytkowników wewnętrznych: 300. Oczekiwany czas trwania procesu EoD: <6 h. Czas niedostępności usług w trakcie EOD: < 3h. Oczekiwany czas zasilania zewnętrznych źródeł danych Hurtownia: <3 h. Rozmiar bazy danych CSB (TB) - obejmuje poziom skalowalności systemu, jest to rozmiar bazy danych produkcyjnej. Obecnie o rozmiar bazy systemu wynosi 2,1 TB z przyrostem rocznym na poziomie 200 GB o rozmiar hurtowni danych 3,5 TB z przyrostem rocznym na poziomie 400 GB o Oczekiwany łączny rozmiar to 20 TB. Maksymalna liczba transakcji do innych banków (wychodzących) / dzień - 200 000. Maksymalna liczba przelewów do innych banków (wychodzących) / godzina - 100 000 Maksymalna wielkość paczki przelewów (liczba przelewów w jednej paczce) - 50 000 Strona 16 z 18 ISTOTNE POSTANOWIENIA UMOWY MOGĄCE MIEĆ WPŁYW NA KOSZT PROJEKTU Celem niniejszego rozdziału przedstawienie wymagań w zakresie praw i obowiązków Wykonawcy, które Zamawiający zamierza umieścić w Istotnych Postanowieniach Umowy (IPU) Planowana długość wdrożenia – 3 lata. Wykonawca może zaproponować podział zakresu na etapy projektu. Bank wyróżnia trzy kategorie dostarczanego oprogramowania o Oprogramowanie Główne – oprogramowanie stanowiące standardowy produkt (instalowany w instytucjach finansowych) na rynku zapewniające obsługę i algorytmizację produktów bankowych i realizujące usługi w zakresie wsparcia procesów bankowych dostarczane przez producentów oprogramowania posiadające referencje z wykorzystania w wielu bankach. W skład Oprogramowania Głównego wchodzi wszelkie oprogramowanie niestanowiące Oprogramowania Dedykowanego ani Pomocniczego, wymagane do działania Systemu CSB. o Oprogramowanie Dedykowane – oprogramowanie dostarczane przez Wykonawcę na indywidualne zamówienie Banku realizujące unikalną na rynku funkcjonalność lub oprogramowanie integrujące ze środowiskiem IT Banku oraz zapewniające dostosowanie Oprogramowania Głównego dla potrzeb zapewnienia zgodności z prawodawstwem polskim. o Oprogramowanie Pomocnicze - oprogramowanie typu COTS lub drobne oprogramowanie o funkcjonalnościach wystandaryzowanych na rynku możliwe do zastąpienia przez produkty innych producentów bez konieczności ich modyfikacji. Bank oczekuje możliwości swobodnego rozwoju i modyfikacji Systemu. zaprezentowany w toku dialogu technicznego. Bank oczekuje praw licencyjnych do Oprogramowania Głównego zapewniającego swobodę rozwoju, co najmniej jaką posiada Wykonawca (integrator), dla Oprogramowania Dedykowanego przeniesienia praw majątkowych w pełnym zakresie w tym do kodów źródłowych i dokumentacji projektowej oraz do Oprogramowania Pomocniczego zgodnie z prawami licencyjnymi producentów oprogramowania. Bank oczekuje, że System zapewni możliwość wdrażania samodzielnie lub z wykorzystaniem osób trzecich kolejnych wersji i aktualizacji Systemu pochodzących zarówno od producentów Oprogramowania Głównego jak również od producentów Oprogramowania Pomocniczego. Oczekiwany przez Zamawiającego sposób modyfikacji zostanie Strona 17 z 18 Bank oczekuje dostarczenia systemu wykorzystującego usługi szyny ESB do komunikacji pomiędzy oprogramowaniem różnych producentów oraz rozróżnialnych handlowo modułów jednego producenta. Bank oczekuje swobody w wykorzystaniu tych wszystkich usług na szynie ESB na zasadach określonych w dokumentacji producentów lub wykonawcy oraz możliwości dodawania przez Bank nowych usług do szyny ESB. Bank oczekuje zawarcia umowy escrow na kody źródłowe, do których praw nie nabędzie, w zakresie Oprogramowania Głównego. Bank oczekuje zawarcia kontraktu, jako umowy outsourcingowej zgodnie z wymogami prawa bankowego. Umowa podlega wszystkim restrykcjom Prawa Zamówień Publicznych. Umowa będzie zawarta na prawie polskim. Bank oczekuje dostosowania systemu do wymagań prawnych obowiązujących sektor bankowy w Polsce oraz zdefiniowanych przez Zamawiającego funkcjonalności wynikających ze szczególnych aktów prawnych dotyczących działalności Banku, w tym dotyczących zarządzania obszarami technologii informatycznej i bezpieczeństwa środowiska informatycznego w bankach (Rekomendacja D) oraz w zakresie sprawozdawczości i raportowania, na dzień podpisania umowy. Przez cały okres obowiązywania Umowy, Wykonawca zobowiązany będzie, na zlecenie, wprowadzić zmiany w Systemie mające zapewnić funkcjonowanie Systemu zgodnie z obowiązującym prawem, oraz potrzebami biznesowymi Zamawiającego. Za zmiany o których mowa w niniejszym punkcie będzie przysługiwało Wykonawcy dodatkowe wynagrodzenie. System musi posiadać interfejs użytkownika w języku polskim (dopuszcza się język angielski w zakresie obsługi ekranów dla funkcjonalności i administracji IT) Bank będzie realizował usługi eksploatacji we własnym zakresie Oczekiwania eksploatacyjne od systemu: o Dostępność kluczowych usług dla klientów 12x5 o Dostępność infrastruktury opartej na rozwiązaniach HA 99,99% o RTO < 2 godziny o RPO - równy 0 - odnosi się do danych już zapisanych oraz operacji potwierdzonych Strona 18 z 18