Wdrożenie Centralnego Systemu Bankowego (CSB)

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