Zmluva o dielo č. C-NBS1-000-073-444 na IS DWH – Dátový sklad uzatvorená podľa § 536 až 565 zákona č. 513/1991 Zb. Obchodný zákonník v znení neskorších predpisov a licenčná zmluva podľa § 65 a nasl. zákona č. 185/2015 Z. z. autorský zákon v znení...

Zmluva o dielo č. C-NBS1-000-073-444

na IS DWH – Dátový sklad

uzatvorená podľa § 536 až 565 zákona č. 513/1991 Zb. Obchodný zákonník v znení neskorších predpisov

a licenčná zmluva podľa § 65 a nasl. zákona č. 185/2015 Z. z. autorský zákon v znení neskorších predpisov

(ďalej len „zmluva o dielo“) medzi:

Zmluvné strany

1. Objednávateľ:

Názov: Národná banka Slovenska

Sídlo: Xxxxxxx Xxxxxxx 1, 813 25 Bratislava

Zastúpená: <vyplní VO>

IČO: ^30844789

DIČ: ^2020815654

IČ DPH: ^SK2020815654

Bankové spojenie: Národná banka Slovenska

Číslo účtu (IBAN): XX00 0000 0000 0000 0000 0000 – platí pre domáceho zhotoviteľa

XX00 0000 0000 0000 0000 0000 – platí pre zahraničného zhotoviteľa

NBS je zriadená zákonom NR SR č. 566/1992 Zb. o Národnej banke Slovenska v znení neskorších predpisov

(ďalej len „objednávateľ“ alebo „NBS“ v príslušnom gramatickom tvare)

a

2. Zhotoviteľ:

Obchodné meno: <vyplní uchádzač>

Sídlo: <vyplní uchádzač>

Zastúpený: <vyplní uchádzač>

IČO: <vyplní uchádzač>

DIČ: <vyplní uchádzač>

IČ DPH: <vyplní uchádzač>

Bankové spojenie: <vyplní uchádzač>

Číslo účtu (IBAN): <vyplní uchádzač>

Zapísaný: <vyplní uchádzač>

(ďalej len „zhotoviteľ“ v príslušnom gramatickom tvare)

(objednávateľ a zhotoviteľ ďalej spoločne označení ako „zmluvné strany“)

Preambula

1. Objednávateľ ako verejný obstarávateľ vyhlásil oznámením č. <doplní verejný obstarávateľ>, zverejneným vo Vestníku verejného obstarávania č. <doplní verejný obstarávateľ> dňa <doplní verejný obstarávateľ>, nadlimitnú zákazku podľa § 66 zákona č. 343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov (ďalej len „zákon o verejnom obstarávaní“) s názvom Konsolidácia údajov DWH/BI.

2. Na základe vyhodnotenia ponúk bola ponuka zhotoviteľa vyhodnotená ako ponuka úspešného uchádzača. Vzhľadom na túto skutočnosť a predloženú ponuku zhotoviteľa sa zmluvné strany na základe slobodnej vôle a v súlade s právnymi predpismi platnými na území Slovenskej republiky rozhodli uzatvoriť túto zmluvu o dielo.

3. Súčasne s touto zmluvou o dielo objednávateľ so zhotoviteľom uzatvára aj Servisnú zmluvu č. C-NBS1-000-074-008 na poskytovanie služieb technickej podpory prevádzky, údržby a rozvoja dodaného informačného systému – Centrálny celobankový dátový sklad.

Článok I

Účel zmluvy

Účelom tejto zmluvy o dielo je vytvorenie dátového skladu, v ktorom budú všetky relevantné informácie a dáta, ktoré NBS používa na každodennej báze, dostupné z jedného bodu. Vytvorený dátový sklad má priniesť zvýšenie produktivity a efektivity v rámci riadenia a využívania dát NBS, zároveň má zabezpečiť zníženie operačného rizika spracovania dát, či zabezpečenie štandardnej kvality poskytovaných služieb NBS.

Článok II

Predmet zmluvy

1. Zhotoviteľ sa zaväzuje na vlastné náklady a nebezpečenstvo, riadne a včas, za cenu a za ďalších podmienok stanovených touto zmluvou o dielo pre objednávateľa:

   1. vytvoriť a dodať informačný systém - Centrálny celobankový dátový sklad (ďalej len „Dielo“ alebo „dodaný informačný systém“), Dielo sa skladá z piatich častí, osobitných fáz, ktoré musia byť zhotovené, dodané, vzájomne aj jednotlivo funkčné, vzájomne integrované, a to postupne podľa termínov podľa Prílohy č. 3 Harmonogram platobných míľnikov (ďalej aj ako „čiastkové plnenie“). Súčasťou každej fázy bude akceptačné testovanie a skúšobná prevádzka čiastkového plnenia samostatne ako aj v integrácii už s odovzdanými čiastkovými plneniami dodávaného informačného systému, pričom súčasťou vykonávania Diela je aj:

   2. poskytovanie služby podpora a údržba (ďalej spolu ako „servisné služby“) pre každé čiastkové plnenie odo dňa dodania čiastkového plnenia do dňa riadneho dodania Diela upravené v Prílohe č. 2 tejto zmluvy o dielo;

   3. udelenie súhlasu na používanie autorských diel, resp. iných predmetov práv duševného vlastníctva, ktoré boli vytvorené na základe, resp. v rámci plnenia tejto zmluvy o dielo, a to v rozsahu požadovanom objednávateľom podľa tejto zmluvy o dielo;

   4. dodanie, resp. zabezpečenie poskytnutia potrebných produktov, licencií SW produktom zhotoviteľa a 3. strán.

2. Zhotoviteľ sa zaväzuje vytvoriť, zhotoviť Dielo v nasledovnom rozsahu a jednotlivých plneniach:

   1. zhotovenie Diela (dodaného informačného systému) v súlade s požiadavkami uvedenými v Prílohe č. 2 – Požiadavky na predmet zmluvy, vrátane súvisiacej dokumentácie;

   2. realizácia riešenia, vrátane implementácie a testovania, ktorá zahŕňa:

      1. vývoj, zabezpečenie a poskytnutie súčinnosti objednávateľovi pri implementácii dodaného informačného systému alebo čiastkového plnenia a pri uvedení produkčného prostredia

      2. vyhotovenie podporných prostriedkov a konverzných programov vrátane vyhotovenia súvisiacej dokumentácie,

      3. inštalácia, nastavenie parametrov a užívateľského nastavenia dodaného informačného systému a ich integrácia,

      4. overenie funkčnosti a úplnosti dodaného informačného systému,

      5. tvorba manuálov k SW (tvorba užívateľskej dokumentácie – užívateľských príručiek),

      6. vyhotovenie dokumentácie o dodanom informačnom systéme,

   3. vypracovanie detailnej analýzy požiadaviek objednávateľa,

   4. vypracovanie návrhu dátového modelu na základe detailnej analýzy požiadaviek objednávateľa,

   5. dodanie riešenia, ktoré bude v prípade spracovania osobných údajov pokrývať celý životný cyklus administrácie osobných údajov od evidencie až po ich

likvidáciu (vrátane vymazania osobných údajov na základe žiadosti dotknutej osoby).

6. realizácia integrácie na zdrojové systémy, vrátane pravidelného nahrávania dát do dátového skladu,

7. vypracovanie návrhu kapacitného plánu,

8. dodanie odporučenia konfigurácie DataLake a dodávka všetkých potrebných licencií tejto časti,

9. inštalácia SW zabezpečenia (DataLake časť DWH, Frameworky, ETL nástroja),

10. prevádzka a podpora SW zabezpečenia (DataLake časť DWH, Frameworky) počas trvania zmluvy o dielo,

11. vypracovanie návrhu a implementácia nového Knowledge Moduloi ODI,

12. implementovanie dátového modelu a dodávka inštalačných scriptov,

13. implementovanie ETL úloh a dodanie inštalačných nastavení,

14. implementácia reportov a analýzy podľa požiadaviek na predmet zmluvy,

15. implementovanie OUT objektov a transformácií dát do požadovaného formátu pre koncového odberateľa (Príloha č. 2 zmluvy o dielo)

16. dodanie nastavenia BI nástroja,

17. dodanie nasledovných frameworkov a nastavení metadát týchto frameworkov:

    1. pre podporu správu, riadenie a monitoring aktualizačných úloh,

    2. pre správu číselníkov, mostíkov, referenčných dát,  hierarchií jednotlivých dimenzií a manuálnych vstupov,

    3. pre nahrávanie veľkého počtu a rôznych súborov,

    4. pre správu, automatické spúšťanie a vyhodnocovanie dátovej kvality,

    5. pre správu prístupov (riadenie bezpečnosti) k dátam,

    6. pre správu dokumentácie k DWH a iných metadát (o modeli, o reportoch, mapovaní zdroj-cieľ) pre správu riadenia dátovej retencie.

18. poskytnutie projektového riadenia zastrešujúceho dodanie Diela;

19. vytvorenie a odovzdanie technickej dokumentácie implementovaného riešenia v súlade s požadovanými výstupmi;

20. zaškolenie obsluhy a používateľov objednávateľa dodaného informačného systému;

21. poskytovanie súčinnosti pri inštalácii a prevádzke neprodukčných prostredí DEv a TEST dodávaného informačného systému;

22. poskytovanie súčinnosti pre podporu produkčného prostredia dodaného informačného systému (súčasťou Diela je aj prevádzkový manuál);

23. poskytovanie súčinnosti pri inštalácii Diela na produkčné prostredia.

1. Zhotoviteľ sa zaväzuje dodať aj ostatné dodávky, činnosti a práce nevyhnutné pre realizáciu Diela, ktoré nie sú výslovne stanovené ako povinnosť objednávateľa, prípadne sú uvedené v Prílohe č. 2 tejto zmluvy o dielo alebo v článku XIII tejto zmluvy o dielo.

2. Zhotoviteľ sa zaväzuje na vlastné náklady zabezpečiť pre objednávateľa produkt (predplatné - subscription) pre DataLake na dobu od začiatku 2. fázy podľa Prílohy č. 3 tejto zmluvy o dielo do riadneho dodania Diela t. j. po podpísaní Záverečného akceptačného protokolu.

3. Zhotoviteľ sa zaväzuje na vlastné náklady zabezpečiť pre objednávateľa licencie SW v špecifikácii pracovnej stanice vývojára v zmysle príloh tejto zmluvy o dielo, ktoré sú pre vytvorenie a dodanie Diela nevyhnutné a nie sú súčasťou poskytnutých SW licencií od objednávateľa (Príloha č. 2 zmluvy o dielo). Tieto licencie sú pre objednávateľa zhotoviteľom zabezpečené s podporou výrobcu na dobu od začiatku vykonávania Diela po moment jeho riadneho dodania Diela t.j. po podpísaní Záverečného protokolu). Produkty (predplatné-subscription a licencie) podľa bodu 2.4. a bodu 2.5. sú spolu ďalej označené ako „ďalšie licencie“.

(ďalej bod 2.1.,2.2.,2.3.,2.4. a 2.5. spolu ako „predmet zmluvy“ alebo „predmet plnenia“).

6. Súčasťou predmetu zmluvy nie je:

   1. dodanie a inštalácia HW serverov ani HW,

   2. dodávka licencií produktov Oracle (DB, ODI) a Microsoft (DB, PoweBI).

   3. inštalácia databázy pre relačnú časť DWH (ako DB, tak aj PowerBI),

   4. inštalácia a prevádzka virtuálnych strojov s Linux OS (pre DataLake časť DWH),

   5. inštalácia a prevádzka virtuálneho stroja s  aplikačnom serverom ,

   6. dodanie licencií aplikácie pre Dátové modelovanie.

7. Zhotoviteľ sa zaväzuje dodať predmet zmluvy v rozsahu a v súlade s požiadavkami, ktoré sú uvedené v Prílohe č. 2 – Požiadavky na predmet zmluvy, v Prílohe č. 3 – Harmonogram platobných míľnikov a v súlade s Prílohou č. 1- Všeobecné podmienky objednávateľa tejto zmluvy o dielo (ďalej len „Všeobecné podmienky“).

8. Ak sa budú na strane zhotoviteľa podieľať viaceré subjekty (konzorcium subjektov), práva z tejto zmluvy o dielo voči objednávateľovi môže uplatňovať výlučne ten subjekt na strane zhotoviteľa, ktorý bude mať podľa osobitnej dohody subjektov postavenie vedúceho subjektu. Subjekty na strane zhotoviteľa si v rámci osobitnej dohody podľa predošlej vety určia a vysporiadajú vzájomné záväzky a oprávnenia vyplývajúce im z tejto zmluvy o dielo. Subjekt, ktorý bude mať postavenie vedúceho subjektu na strane zhotoviteľa bude vo vzťahu k objednávateľovi zodpovedať za fakturáciu, odovzdávanie Diela alebo jeho časti, vrátane všetkých a akýchkoľvek úkonov týkajúcich sa plnenia tejto zmluvy o dielo a objednávateľ bude komunikovať výlučne s ním ohľadom všetkých zmluvných záležitostí. Ten subjekt na strane zhotoviteľa, ktorý má postavenie vedúceho subjektu na strane zhotoviteľa, je povinný bezodkladne oznámiť túto skutočnosť objednávateľovi. (Text platí ak sa na strane zhotoviteľa budú podieľať viaceré subjekty, ak nie uchádzač tento bod odstráni)

9. Objednávateľ sa zaväzuje riadne a včas dodaný predmet zmluvy resp. jeho časti prevziať v súlade s touto zmluvou o dielo a zaplatiť zaň dohodnutú cenu v rozsahu a za podmienok dohodnutých v tejto zmluve o dielo.

Článok III.

Miesto a termíny dodania predmetu zmluvy

1. Miestom dodania predmetu zmluvy je sídlo objednávateľa nachádzajúce sa na adrese Národná banka Slovenska, Xxxxxxx Xxxxxxx 0, 000 00 Xxxxxxxxxx, Xxxxxxxxx xxxxxxxxx.

2. Objednávateľ si vyhradzuje právo v prípade potreby zmeniť miesto dodania predmetu zmluvy na záložné technologické pracovisko nachádzajúce sa v Datacentre, Kopčianska 92, 851 01 Bratislava, pričom túto skutočnosť vopred bez zbytočného odkladu písomne oznámi zhotoviteľovi bez potreby písomného dodatku k tejto zmluve o dielo.

3. Ak to technické podmienky umožňujú, tak prednostne platí, že zhotoviteľ dodáva predmet zmluvy prostredníctvom vzdialeného prístup zabezpečeného sieťového VPN spojenia. Zhotoviteľ sa zaväzuje rešpektovať všetky bezpečnostné, organizačné a technické opatrenia a ďalšie relevantné predpisy objednávateľa spojené s prácou v priestoroch objednávateľa i so vzdialeným prístupom k informačným technológiám a sieti objednávateľa podľa článku V Prílohy č. 1: Všeobecné podmienky k zmluve o dielo ako aj v zmysle platných predpisov a štandardov objednávateľa, ktoré zhotoviteľovi zabezpečí oprávnená osoba objednávateľa počas celej doby trvania podpory prevádzky dodaného informačného systému

4. Zhotoviteľ sa zaväzuje vytvoriť a dodať Dielo do 36 mesiacov odo dňa nadobudnutia účinnosti tejto zmluvy o dielo. Deň dodania Diela sa považuje deň podpisu Záverečného akceptačného protokolu.

5. Zhotoviteľ sa zaväzuje dodať jednotlivé čiastkové plnenia na základe dohodnutého časového harmonogramu uvedeného v Prílohe č. 3 zmluvy o dielo.

6. Zhotoviteľ sa zaväzuje poskytovať servisné služby podľa zmluvy o dielo odo dňa dodania 1. čiastkového plnenia do dňa dodania Diela.

7. Ak prípadné omeškanie objednávateľa s poskytnutím súčinnosti, ktorú je povinný poskytnúť zhotoviteľovi má alebo preukázateľne bude mať vplyv na dodržanie časového harmonogramu, tzn. ak sa jedná o neposkytnutie takej súčinnosti, ktorá je nevyhnutná pre včasné vykonanie Diela, zhotoviteľ nie je v omeškaní so zhotovením Diela a lehota na vykonanie jednotlivých čiastkových plnení sa po písomnom schválení Riadiacou radou predĺži o čas omeškania objednávateľa s poskytnutím súčinnosti. To však platí len za predpokladu, že najneskôr druhý pracovný deň po vzniku omeškania objednávateľa zhotoviteľ písomne upozornil oprávnenú osobu objednávateľa na konkrétne vymedzenú povinnosť súčinnosti, s ktorou je objednávateľ v omeškaní, a toto upozornenie pravidelne písomne obnovoval najmenej jedenkrát za 5 dní až do dosiahnutia nápravy. Pokiaľ tento postup nebude dodržaný a Riadiaca rada neschváli predĺženie času, lehoty na vykonanie jednotlivých čiastkových plnení, lehota na vykonanie Diela sa nebude predlžovať. Pre zamedzenie pochybností sa stanovuje, že lehotu na vytvorenie a dodanie Diela ako celku je možné predĺžiť iba na základe písomného dodatku k tejto zmluve o dielo uzatvoreného v súlade s § 18 zákona o verejnom obstarávaní.

Článok IV

Cena a platobné podmienky

1. Zmluvné strany sa dohodli na určení maximálnej ceny za predmet tejto zmluvy o dielo v celkovej sume:

<uchádzač vyplní cenu uvedenú v Tabuľke č. 4 „Celková cena predmetu zmluvy“ v Prílohe č.4 - Špecifikácia ceny tejto zmluvy o dielo> eur bez DPH

(slovom: <vyplní uchádzač> eur bez DPH), pričom

(ďalej ako „celková cena predmetu zmluvy“),

z celkovej ceny predmetu zmluvy je celková cena Diela v celkovej sume:

<uchádzač vyplní cenu uvedenú v Tabuľke č. 1„Celková cena Diela“ v Prílohe č.4 - Špecifikácia ceny tejto zmluvy o dielo> eur bez DPH

(slovom: <vyplní uchádzač> eur bez DPH),

(ďalej ako „cena Diela“),

z celkovej ceny predmetu zmluvy je celková maximálna cena za ďalšie licencie

<uchádzač vyplní cenu uvedenú v Tabuľke č. 2 + Tabuľke č. 3 „Celková cena ďalších licencií“ v Prílohe č.4 - Špecifikácia ceny tejto zmluvy o dielo> eur bez DPH

(slovom: <vyplní uchádzač> eur bez DPH).

2. Maximálna celková ceny predmetu tejto zmluvy o dielo zahŕňa akékoľvek a všetky náklady na vykonanie, dodanie, poskytnutie predmetu zmluvy.

3. Ceny za predmet zmluvy uvedené v prílohe č. 4 tejto zmluvy o dielo sú stanovené dohodou zmluvných strán v súlade so zákonom NR SR č. 18/1996 Z. z. o cenách v znení neskorších predpisov a vyhlášky Ministerstva financií SR č. 87/1996 Z. z. v znení neskorších predpisov, ktorou sa vykonáva zákon NR SR č. 18/1996 Z. z. o cenách v znení neskorších predpisov. Ceny za predmet zmluvy sú pevne stanovené.

4. Zmluvné strany sa dohodli, že celková cena predmetu zmluvy je tvorená súčtom cien v detailnom rozpočte stanovenom v Prílohe č. 4 tejto zmluvy o dielo pre jednotlivé časti Diela (čiastkové plnenia) a ceny za ďalšie licencie. Cena za dodanie čiastkového plnenia (jednotlivé fázy) v sebe zahŕňa poskytovanie servisných služieb pre čiastkové plnenie.

5. Celková cena predmetu zmluvy predstavuje odplatu za splnenie všetkých zmluvných záväzkov zhotoviteľa vyplývajúcich z tejto zmluvy o dielo a zahŕňa všetky náklady a výdavky zhotoviteľa na riadne a včasné zhotovenie Diela, resp. jeho jednotlivých častí (čiastkových plnení) podľa tejto zmluvy o dielo, cenu za udelenie licencie k Dielu podľa článku X zmluvy o dielo a poskytovanie servisných služieb k čiastkovému plneniu, cenu za licencie 3. strán a celkovú cenu za ďalšie licencie.

6. Zhotoviteľ je oprávnený fakturovať cenu v podľa bodu 4.1 zmluvy o dielo, okrem ceny za ďalšie licencie, zodpovedajúcu prevzatej časti Diela (čiastkovému plneniu) v platobných míľnikoch podľa Prílohy č. 3 tejto zmluvy o dielo. Zmluvné strany sa dohodli, že zhotoviteľ vystaví objednávateľovi faktúru za prevzaté časti Diela (čiastkové plnenia) po:

1. ukončení procesu akceptácie odovzdávanej časti Diela (čiastkového plnenia) v zmysle článku V tejto zmluvy o dielo,

2. podpísaní príslušného Akceptačného protokolu, a 

3. schválení výkazov prác k prevzatej časti Diela (čiastkovému plneniu).

1. Prílohou k faktúre je:

1. podpísaný Akceptačný protokol, pričom môže ísť aj o Akceptačný protokol s výhradou, vzťahujúci sa k fakturovanej časti Diela (čiastkovému plneniu), a

2. schválené výkazy práce vzťahujúce sa k fakturovanej časti Diela (čiastkovému plneniu).

8. Zhotoviteľ je oprávnený fakturovať cenu za ďalšie licencie po ich dodaní a potvrdení ich dodania objednávateľom prostredníctvom písomného protokolu. Poskytovateľ sa zaväzuje vystaviť príslušné faktúry za dodanie ďalších licencií do 14 dní od ich riadneho dodania. Xxxx za ďalšie licencie sa stanovuje podľa Xxxxxxx č. 2 a Tabuľky č. 3 Prílohy č. 4 – Špecifikácia ceny zmluvy o dielo.

9. Oprávnená osoba zhotoviteľa predkladá oprávnenej osobe objednávateľa pravidelne, na mesačnej báze, najneskôr do 10 (desiateho) kalendárneho dňa v mesiaci výkazy prác. Oprávnená osoba objednávateľa je povinná výkazy prác podľa predchádzajúcej vety následne schváliť alebo neschváliť v lehote do 5 (piatich) pracovných dní od ich predloženia zhotoviteľom. Ak oprávnená osoba objednávateľa bez oprávneného dôvodu neschváli výkaz prác podľa tohto bodu zmluvy o dielo alebo nezašle zhotoviteľovi žiadne výhrady k zaslanému výkazu prác do 5 (piatich) pracovných dní od jeho predloženia, považuje sa tento výkaz prác za schválený. Pri uplatnení výhrad oprávnenou osobou objednávateľa začína plynúť nová lehota 5 (piatich) pracovných dní na schválenie alebo neschválenie výkazu prác odo dňa opätovného predloženia opraveného výkazu prác zhotoviteľom.

10. Výdavky vo faktúre musia byť rozdelené do jednotlivých položiek s jednotkovými cenami zaokrúhlenými na 2 (dve) desatinné miesta s jednoznačnou identifikáciou, ktorej položky rozpočtu podľa prílohy č. 4 tejto zmluvy o dielo sa predmetná fakturovaná čiastka týka. Ku každej faktúre musí byť priložený originál akceptačného protokolu podpísaného Zmluvnými stranami.

11. Zhotoviteľ je oprávnený fakturovať a  objednávateľ uhradí zhotoviteľovi dohodnutú celkovú cenu Diela uvedenú v bode 4.1. tohto článku zmluvy na základe faktúry nasledovne:

1. 16 % z celkovej ceny Diela, t.j. celkovej ceny za jednotlivú 1. fázu – čiastkové plnenie predmetu zmluvy uvedené v tabuľke č. 2 Prílohy č. 4 – Špecifikácia ceny po dodaní a po úspešnom ukončení akceptačného testovania v rámci jednotlivej fázy aktualizovaného dodaného informačného systému a po podpísaní Akceptačného protokolu.

1. 24 % z celkovej ceny Diela, t.j. celkovej ceny za jednotlivú 2. fázu – čiastkové plnenie predmetu zmluvy uvedené v tabuľke č. 2 Prílohy č. 4 – Špecifikácia ceny po dodaní a po úspešnom ukončení akceptačného testovania v rámci jednotlivej fázy aktualizovaného dodaného informačného systému a po podpísaní Akceptačného protokolu.

2. 29 % z celkovej ceny Diela, t.j. celkovej ceny za jednotlivú 3. fázu – čiastkové plnenie predmetu zmluvy uvedené v tabuľke č. 2 Prílohy č. 4 – Špecifikácia ceny po dodaní a po úspešnom ukončení akceptačného testovania v rámci jednotlivej fázy aktualizovaného dodaného informačného systému a po podpísaní Akceptačného protokolu.

3. 19 % z celkovej ceny Diela, t.j. celkovej ceny za jednotlivú 4. fázu – čiastkové plnenie predmetu zmluvy uvedené v tabuľke č. 2 Prílohy č. 4 – Špecifikácia ceny po dodaní a po úspešnom ukončení akceptačného testovania v rámci jednotlivej fázy aktualizovaného dodaného informačného systému a Akceptačného protokolu.

4. 12 % z celkovej ceny Diela t.j. celkovej ceny za jednotlivú 5. fázu – čiastkové plnenie predmetu zmluvy uvedené v tabuľke č. 2 Prílohy č. 4 – Špecifikácia ceny po dodaní a po úspešnom ukončení akceptačného testovania v rámci jednotlivej fázy aktualizovaného dodaného informačného systému a po podpísaní Záverečného akceptačného protokolu.

1. Ceny za predmet zmluvy sú uvedené bez DPH. Zhotoviteľ k dohodnutým cenám uplatní DPH podľa všeobecne záväzného právneho predpisu platného v čase fakturácie. (Text platí pre tuzemského zhotoviteľa, zahraničný zhotoviteľ text druhej vety odstráni).

2. Faktúry sú splatné do 30 dní odo dňa ich doručenia objednávateľovi. Úhrada faktúry sa bude realizovať bezhotovostným prevodom na účet zhotoviteľa. Za deň splnenia peňažného záväzku sa považuje deň odpísania dlžnej sumy z účtu objednávateľa v prospech zhotoviteľa. Za správne vyčíslenie výšky DPH zodpovedá v plnom rozsahu zhotoviteľ.

3. Zmluvné strany sa dohodli a výslovne súhlasia s tým, že zhotoviteľ bude zasielať len elektronické faktúry z e-mailovej adresy zhotoviteľa <vyplní uchádzač> na e-mailovú adresu objednávateľa xxxxxxx.xxx@xxx.xx vo formáte PDF. Zmluvné strany vyhlasujú, že majú výlučný prístup k uvedeným e-mailovým adresám. Zmluvné strany sú oprávnené zmeniť e-mailové adresy a to len písomne s uvedením novej e-mailovej adresy, pričom z dôvodu tejto zmeny nie je potrebné uzatvoriť dodatok k tejto zmluve o dielo. Zhotoviteľ nie je povinný podpísať elektronickú faktúru zaručeným elektronickým podpisom. Elektronická faktúra musí spĺňať všetky náležitosti faktúry podľa § 74 zákona č. 222/2004 Z. z. o dani z pridanej hodnoty v znení neskorších predpisov.

4. Zmluvné strany sú povinné bezodkladne písomne oznámiť druhej strane akúkoľvek zmenu, ktorá by mohla mať vplyv na doručovanie elektronických faktúr, najmä zmenu kontaktnej e-mailovej adresy.

5. V prípade, že faktúra nebude po vecnej a/alebo formálnej stránke správne vyhotovená, objednávateľ je oprávnený ju vrátiť zhotoviteľovi bez zaplatenia na doplnenie (prepracovanie), pričom nová lehota splatnosti faktúry začne plynúť dňom doručenia správne doplnenej (prepracovanej) faktúry objednávateľovi.

6. Zhotoviteľ sa zaväzuje, že uvedenú daň na faktúre odvedie správcovi dane v lehote ustanovenej v § 78 ods. 1 zákona č. 222/2004 Z. z. o dani z pridanej hodnoty v znení neskorších predpisov. Porušenie tejto daňovej povinnosti vyplývajúcej zo všeobecne záväzného právneho predpisu je podstatným porušením tejto zmluvy a oprávňuje objednávateľa na okamžité odstúpenie od tejto zmluvy. (Text platí pre zahraničného zhotoviteľa, tuzemský zhotoviteľ tento text aj s bodom odstráni)

7. Zhotoviteľ najneskôr do doby vyhotovenia prvej faktúry predloží objednávateľovi originál potvrdenia o mieste svojej daňovej rezidencie, alebo jeho úradne overenú fotokópiu. Počas trvania zmluvy zhotoviteľ predmetné potvrdenie predloží objednávateľovi na začiatku každého nového zdaňovacieho obdobia. Zhotoviteľ vyhlasuje a zaväzuje sa, že v prípade vzniku stálej prevádzkarne na území Slovenskej republiky počas trvania zmluvy bude o tejto skutočnosti objednávateľa bezodkladne písomne informovať. Zhotoviteľ čestne vyhlasuje, že je konečným príjemcom platieb uvedených v tejto zmluve. (Text platí pre tuzemského zhotoviteľa, zahraničný zhotoviteľ tento text aj s bodom odstráni).

Článok V

Odovzdanie a prevzatie Diela

1. Odovzdanie a prevzatie Diela alebo jeho časti sa uskutoční najneskôr v termínoch špecifikovaných v časovom harmonograme podľa Prílohy č. 3 tejto zmluvy o dielo. Výsledkom odovzdania čiastkového plnenia a dodania ďalších licencií predmetu zmluvy (napr. časť Diela) zhotoviteľom a jeho prevzatia objednávateľom je podpísanie akceptačného protokolu oprávnenými osobami zmluvných strán tejto zmluvy o dielo (ďalej ako „Akceptačný protokol“). Akceptačný protokol musí byť pred jeho podpisom schválený Riadiacou radou. Fungovanie a mandát Riadiacej rady je upravený v Prílohe č. 2 zmluvy o dielo. Akceptačný protokol obsahuje najmä: identifikačné údaje zmluvných strán, identifikáciu oprávnených osôb zmluvných strán, identifikáciu predmetu akceptácie (označenie produktu, kontrola kvality), informácie povinne uvedené v zápisnice o vykonaných akceptačných testoch. Vyjadrenie objednávateľa môže byť:

   1. A/plná akceptácia (odovzdanie predmetu plnenia prebehlo bez výhrad a v plnom súlade požiadavkami objednávateľa a so zmluvou o dielo);

   2. B/podmienečná akceptácia (odovzdanie predmetu plnenia prebehlo s výhradami, ktoré nebránia jeho prebratiu a používaniu, pričom objednávateľ súhlasí s úhradou predmetu plnenia, čo v prípade čiastkového plnenia znamená 0 závažných vád, 0 zásadných vád a maximálne 10 nepodstatných vád);

   3. C/odmietnutie prevzatia predmetu plnenia objednávateľom.

2. Vlastnícke právo k Dielu alebo jeho časti prechádza na objednávateľa odovzdaním a prevzatím Diela alebo jeho časti, tzn. podpísaním Akceptačného protokolu/Záverečného akceptačného protokolu vzťahujúceho sa k odovzdávanej časti Diela oboma zmluvnými stranami, pričom platí, že vlastnícke právo k Dielu ako celku prechádza na objednávateľa podpísaním Záverečného akceptačného protokolu (finálna akceptácia) oboma zmluvnými stranami.

3. Objednávateľ neprevezme Dielo, ak vykazuje Dielo právne a/alebo faktické vady. Dielo má vady, ak je zhotovené v rozpore podmienkami stanovenými v tejto zmluve o dielo a/alebo v rozpore so všeobecne záväznými právnymi predpismi.

4. Prílohou Akceptačného protokolu je:

   1. zápisnica o vykonaných akceptačných testoch, ak sa Akceptačným protokolom odovzdáva dodávaný informačný systém alebo jeho časť,

   2. zoznam autorov diel a zoznam autorských diel vytvorených v rámci plnenia tejto zmluvy o dielo, ak sú súčasťou odovzdávaného Diela alebo jeho časti,

   3. prezenčné listiny zo školení, ak boli vykonané pre užívateľov Xxxxx, spolu so školiacim materiálom,

   4. dokumenty a doklady osvedčujúce kompletnosť (napr.: zoznam dodávok, osvedčenie o akosti a kompletnosti, návody na obsluhu), ak takéto dokumenty už neboli súčasťou ponuky predloženej objednávateľovi.

5. Akceptačný protokol sa vyhotovuje v 4 (štyroch) vyhotoveniach, z ktorých 2 (dve) vyhotovenia sa určené pre objednávateľa a 2 (dve) vyhotovenia sú určené pre zhotoviteľa.

6. Ak zhotoviteľ odovzdáva dodaný informačný systém alebo jeho časť, zmluvné strany vykonajú vo vzájomnej súčinnosti akceptačné testy. Akceptačné testy sa vykonajú v prostredí a na infraštruktúre objednávateľa a v oddelených testovacích prostrediach (t. j. bez možnosti ovplyvniť bežnú činnosť objednávateľa, mimo produkčných databáz), ak sa zmluvné strany vopred výslovne nedohodnú inak. Pre úspešné vykonanie akceptačných testov sa vyžaduje osobná prítomnosť oprávnených osôb zmluvných strán podľa článku VI tejto zmluvy o dielo alebo nimi preukázateľne splnomocnených osoba na ich zastúpenie; inak sa akceptačné testy nemôžu vykonať. Výsledky akceptačných testov sa zachytia v zápisnici podpísanej oprávnenými osobami zmluvných strán podľa tejto zmluvy o dielo.

7. Akceptačné testy dodaného informačného systému alebo jeho časti sa uskutočnia v súlade s časovým plánom akceptačných testov špecifikovaným v časovom harmonograme podľa Xxxxxxx č. 3 tejto zmluvy o dielo. Ak sa akceptačné testy uskutočnia v inom termíne, ako sú plánované podľa časového harmonogramu, zmluvné strany sa na novom termíne dohodnú písomne. Zhotoviteľ písomne informuje objednávateľa o návrhu nového termínu akceptačných testov najmenej 5 (päť) pracovných dní pred ich pôvodným termínom uskutočnenia. Ak akceptačné testy prebehli úspešne v zmysle bodu 5.11. tohto článku zmluvy o dielo, časové obdobie medzi úspešnými akceptačnými testami a odovzdaním a prevzatím dodaného informačného systému alebo jeho časti potvrdeným podpisom Akceptačného protokolu nepresiahne 30 (slovom: tridsať) kalendárnych dní.

8. Ak pri zhotovení dodaného informačného systému dôjde k zhotoveniu databázy v súlade s § 135 Autorského zákona, uvedie sa táto skutočnosť v príslušnom Akceptačnom protokole. V tomto prípade bude súčasťou akceptačných testov, ktorých vykonanie predchádza vyhotoveniu Akceptačného protokolu, detailná špecifikácia databázy tvoriacej súčasť dodaného informačného systému alebo jeho časti.

9. Ak dodaný informačný systém alebo jeho časť nespĺňa akceptačné kritériá podľa tohto článku zmluvy o dielo, objednávateľ uvedie a popíše všetky identifikované právne a/alebo faktické vady dodaného informačného systému (ďalej len „vady dodaného informačného systému“) v zápisnici o akceptačných testoch a navrhne nový termín pre vykonanie akceptačných testov. Zhotoviteľ sa zaväzuje odstrániť vady dodaného informačného systému uvedené v zápisnici o akceptačných testoch v zmysle tohto článku zmluvy o dielo a opätovne uskutočniť nevyhnutné akceptačné testy, a to aj opakovane maximálne však 5 (päť) krát vo vzťahu ku každej odovzdávanej časti dodaného informačného systému. Ak napriek opakovaným akceptačným testom nebude dodaný informačný systém alebo jeho časť bez vád, t. j. nebudú splnené všetky kritériá akceptácie podľa bodu 5.11. tohto článku zmluvy o dielo uvedené sa považuje za podstatné porušenie povinnosti podľa tejto zmluvy o dielo..

10. Zmluvné strany sa zaväzujú dodržiavať časový plán akceptačných testov a pri výskyte vád dodaného informačného systému vynaložiť nevyhnutné úsilie na jeho dodržanie. Vady dodaného informačného systému, ktoré sa vyskytnú pri akceptačných testoch, budú klasifikované podľa ich závažnosti špecifikovanej v prílohe č. 8 tejto zmluvy o dielo. Zápisnica o akceptačných testoch musí obsahovať správu o priebehu akceptačného testu a klasifikáciu zistených vád dodaného informačného systému podľa stupňa ich závažnosti špecifikovaných v Prílohe č. 8 tejto zmluvy o dielo.

11. Zmluvné strany sa dohodli, že akceptačné testy prebehli úspešne a akceptačné kritériá sú splnené, t. j. dodaný informačný systém alebo jeho časť je bez vád, ak neobsahuje žiadny závažný nedostatok (finálna akceptácia), žiadny zásadný nedostatok a obsahuje maximálne 10 (desať) nepodstatných vád (podmienečná akceptácia),  opakovanie akceptačných testov nie je potrebné, zhotoviteľ je však naďalej povinný v lehotách podľa tohto článku zmluvy o dielo odstrániť na vlastné náklady všetky vady dodaného informačného systému alebo jeho časti podľa príslušnej zápisnice o akceptačných testoch.

12. Zhotoviteľ sa zaväzuje odstrániť všetky vady dodávaného informačného systému uvedené v zápisnici o akceptačných testoch v nej uvedenej lehote. Ak zápisnica o akceptačných testoch neobsahuje lehotu na odstránenie vady dodávaného informačného systému, zhotoviteľ je povinný odstrániť vady úrovne B do 5 (piatich) pracovných dní od podpísania zápisnice o akceptačnom teste a vady úrovne C do 10 (desiatich) pracovných dní od podpísania zápisnice o akceptačnom teste.

13. Ak sa zmluvné strany nedohodnú inak, zhotoviteľ je povinný odovzdať objednávateľovi dokumentáciu k Dielu alebo jeho časti na elektronickom zariadení/nosiči dát (USB prenosné zariadenie) alebo na inom vhodnom, dohodnutom nosiči dát a v prípade potreby a požiadavky objednávateľa aj v jednom vyhotovení v písomnej forme pri podpise Akceptačného protokolu. Dokumentácia, ktorá je súčasťou Diela, bude akceptovaná nasledovne:

    1. technickú dokumentáciu v slovenskom jazyku, ktorá bude obsahovať: postup skompilovania aplikácie, dátový model Informačného systému, popis integračnej, aplikačnej a technickej architektúry, väzby na iné systémy, popis tokov dát, procesné modely elektronických služieb,

    2. prevádzkovú dokumentáciu v slovenskom jazyku, ktorá bude obsahovať: inštalačný postup aplikácie, konfiguráciu systémového SW, serverov a pracovných staníc, chybové stavy a postup ich riešenia, popis mechanizmu riadenia prístupu užívateľov k dátam a k funkciám aplikácie, popis procedúr pre zálohovanie a obnovu dát, popis použitých a navrhovaných technických číselníkov, ich naplnenie pri inicializácii.

    3. užívateľskú dokumentáciu v slovenskom jazyku v písomnej forme v počte 2 (dvoch) kusov, ktorá bude obsahovať: popis počítačového programu a jeho funkcií, postupy a úkony potrebné pre riadne užívanie počítačového programu, chybové a neštandardné stavy a dostupné spôsoby ich riešenia.

14. Objednávateľ je oprávnený zaslať pripomienky k dokumentácii k Dielu v dohodnutom formáte v lehote do 10 (desiatich) pracovných dní odo dňa jej odovzdania objednávateľovi,

15. Zhotoviteľ je povinný pripomienky odborne posúdiť a upraviť dokumentáciu podľa vznesených pripomienok, ktoré nerozširujú predmet Diela, najneskôr do 7 (siedmich) pracovných dní od zaslania pripomienok objednávateľa podľa bodu 5.13.. Ak nie je možné niektorú z pripomienok objednávateľa akceptovať, zhotoviteľ túto skutočnosť bezodkladne oznámi a písomne vysvetlí Objednávateľovi v lehote podľa predchádzajúcej vety,

16. Objednávateľ je povinný do 5 (piatich) pracovných dní od dodania prepracovanej dokumentácie podľa bodu 5.14. preveriť spôsob zapracovania pripomienok a v prípade nesúhlasu v uvedenej lehote zaslať svoje stanovisko zhotoviteľovi, pričom Akceptačný protokol nemôže byť podpísaný.

17. Márne uplynutie ktorejkoľvek z lehôt v zmysle bodu 5.13. a 5.14. tejto zmluvy o dielo spôsobené nekonaním zmluvnej strany je omeškaním druhej zmluvnej strany.

18. Vytvorené zdrojové kódy spôsobom ako je dohodnuté v článku IX tejto zmluvy o dielo,

19. Ak došlo k odovzdaniu a prevzatiu Diela a zároveň zhotoviteľ odstránil všetky vady dodaného informačného systému, zmluvné strany vyhotovia záverečný akceptačný protokol (ďalej len „Záverečný akceptačný protokol“) s tým, že jeho prílohou je konečná správa o plnení Diela. Záverečný akceptačný protokol musí byť pred jeho podpisom písomne schválený Riadiacou radou projektu. Podpísaním Záverečného akceptačného protokolu oprávnenými osobami zmluvných strán podľa článku VI tejto zmluvy o dielo sa považuje Xxxxx za riadne zhotovené a odovzdané zhotoviteľom a prevzaté objednávateľom.

20. Záverečný akceptačný protokol sa vyhotovuje v 4 (štyroch) vyhotoveniach, z ktorých 2 (dve) vyhotovenia sú určené pre objednávateľa a 2 (dve) vyhotovenia sú určené pre zhotoviteľa.

Článok VI

Oprávnené osoby a 

komunikácia zmluvných strán

1. Zhotoviteľ sa zaväzuje do piatich (5) pracovných dní od uzavretia tejto zmluvy o dielo vymenovať oprávnenú osobu, ktorá bude počas účinnosti tejto zmluvy o dielo oprávnená konať za zhotoviteľa v určených záležitostiach súvisiacich s plnením tejto zmluvy o dielo a v tej istej lehote písomne oznámiť objednávateľovi jej meno, priezvisko a kontaktné údaje.

2. Objednávateľ sa zaväzuje do piatich (5) pracovných dní od podpisu tejto zmluvy o dielo vymenovať oprávnenú osobu, ktorá bude počas účinnosti tejto zmluvy o dielo oprávnená konať za objednávateľa v určených záležitostiach súvisiacich s plnením tejto zmluvy o dielo a v tej istej lehote písomne oznámiť objednávateľovi jej meno, priezvisko a kontaktné údaje.

3. Prostredníctvom určených oprávnených osôb zmluvné strany:

   1. zabezpečia vzájomnú komunikáciu zmluvných strán týkajúcu sa všetkých záležitostí týkajúcich sa plnenia tejto zmluvy o dielo,

   2. plnia vymedzené úlohy zmluvných strán podľa tejto zmluvy o dielo,

   3. uskutočnia všetky organizačné záležitosti s ohľadom na všetky aktivity a činnosti súvisiace s plnením tejto zmluvy o dielo,

   4. zabezpečia koordináciu jednotlivých aktivít a činností zmluvných strán súvisiacich s plnením tejto zmluvy o dielo,

   5. sledujú priebeh plnenia tejto zmluvy o dielo,

   6. navrhujú potrebné zmeny technických riešení a technickej povahy v zmysle tejto zmluvy o dielo a

   7. zabezpečia vzájomnú spoluprácu a súčinnosť.

4. Zmena oprávnených osôb v zmysle tohto článku zmluvy o dielo sa vykoná prostredníctvom písomného protokolu o zmene oprávnenej osoby podpísaného oboma zmluvnými stranami.

5. Zmluvné strany sa dohodli, že ich vzájomná komunikácia ohľadom akejkoľvek záležitosti týkajúcej sa tejto zmluvy o dielo bude vykonávaná prostredníctvom oprávnených osôb zmluvných strán.

6. Zmluvné strany sa ďalej dohodli, že bežná komunikácia (napr. komunikácia týkajúca sa organizácii stretnutí alebo iných organizačných záležitosti alebo podkladov pre fakturáciu a pod.) bude vykonávaná prostredníctvom emailu.

7. Komunikácia zmluvných strán, ktorá  má povahu právneho úkonu (napr. odstúpenie od zmluvy, uplatnenie zmluvnej pokuty a pod.) bude vykonávaná písomne v listinnej podobe s doporučeným doručovaním druhej zmluvnej strane prostredníctvom poštovej služby alebo kuriérskej služby.

8. Každá zo zmluvných strán môže zmeniť oprávnené osoby. Takáto zmena je účinná dňom doručenia písomného oznámenia o zmene obsahujúceho aj meno a kontaktné údaje novej oprávnenej osoby druhej zmluvnej strane.

Článok VII

Zodpovednosť za vady, záruka a odstraňovanie vád

dodaného informačného systému počas záruky

1. Zhotoviteľ zodpovedá za to, že dodaný informačný systém je ku dňu podpisu Záverečného akceptačného protokolu a počas záručnej doby bez vád, t. j. najmä zodpovedá funkčným a technickým vlastnostiam opísaným v  Prílohe č. 2 tejto zmluvy o dielo.

2. Zhotoviteľ poskytuje na dodaný informačný systém a jeho jednotlivé časti záruku počas trvania záručnej doby od riadneho odovzdania a prevzatia príslušnej časti dodaného informačného systému až do uplynutia 24 (slovom: dvadsiatich štyroch) mesiacov (vrátane skúšobnej prevádzky, ktorá trvá 2 mesiace). Odovzdaním dodaného informačného systému ako celku, t. j. dňom podpísania Záverečného akceptačného protokolu, začína plynúť záručná doba na celý dodaný informačný systém vrátane všetkých jeho častí. Počas plynutia záručnej doby zhotoviteľ zodpovedá za funkcionality a funkčnosť dodaného informačného systému, ktoré musia byť v súlade s touto zmluvou o dielo a najmä Prílohou č. 2 tejto zmluvy o dielo. Zhotoviteľ zaručuje, že v záručnej dobe bude dodaný informačný systém spôsobilý na použitie na účel zodpovedajúci jeho určeniu.

3. Zhotoviteľ zaručí, že odovzdaný, dodaný informačný systém alebo jeho časti, nemá v čase odovzdania a prevzatia právne vady, predovšetkým nie je zaťažený právami tretích osôb z priemyselného alebo iného duševného vlastníctva. Zhotoviteľ sa zaväzuje nahradiť objednávateľovi škodu spôsobenú uplatnením nárokov tretích osôb z titulu porušenia ich chránených práv súvisiacich s plnením zhotoviteľa alebo jeho subdodávateľov podľa tejto zmluvy o dielo.

4. Zhotoviteľ zaručí, že k dodanému informačnému systému alebo jeho časti neexistujú v čase jeho odovzdania objednávateľovi akékoľvek právne nároky tretích strán vyplývajúce zo zmlúv s tretími stranami a že dodaný informačný systém nie je predmetom vecného bremena alebo iného obdobného právneho vzťahu, ktorý by prípadne obmedzil objednávateľa v užívaní dodaného informačného systému.

5. Objednávateľ je povinný oznámiť zhotoviteľovi vady dodaného informačného systému alebo jeho časti podľa tohto článku kedykoľvek do uplynutia záručnej doby podľa bodu 7.2 tejto zmluvy o dielo, a to bez zbytočného odkladu po tom, kedy sa objednávateľ o výskyte vady dodaného informačného systému alebo jeho časti dozvedel. Objednávateľ je oprávnený požadovať od zhotoviteľa bezplatné odstránenie vady dodaného informačného systému alebo jeho časti, na ktorú sa vzťahuje záruka podľa tejto zmluvy o dielo bezodkladne, ak sa zmluvné strany písomne nedohodnú na osobitnej lehote.

6. Objednávateľ je povinný pri uplatnení vady stanoviť úroveň vady dodaného informačného systému alebo jeho časti. Zhotoviteľ je povinný bez zbytočného odkladu potvrdiť prijatie nahlásenej vady dodaného informačného systému.

7. Zmluvné strany sa zaväzujú potvrdiť odstránenie vady dodaného informačného systému v zápisnici o odstránení vady dodaného informačného systému podpísanej oboma zmluvnými stranami, v ktorej uvedú aj predmet vady dodaného informačného systému, spôsob a čas jej odstránenia.

8. Nahlásenie vady zo strany objednávateľa sa vykoná prioritne prostredníctvom objednávateľovho IS Service desk. V rámci nahlásenia vady objednávateľ najmä opíše, ako sa reklamovaná vada prejavuje; ak to vie posúdiť, uvedie tiež o vadu akej úrovne/ kategórie podľa klasifikácie v zmysle tejto zmluvy o dielo sa jedná. Zhotoviteľ je oprávnený posúdiť správnosť kategorizácie vady objednávateľom. V prípade nesprávnej kategorizácie vady objednávateľom je zhotoviteľ oprávnený odôvodnene odmietnuť kategorizáciu vady objednávateľom. Ak objednávateľ nevie posúdiť, o vadu akej kategórie sa jedná, pre účely určenia lehoty na odstránenie vád sa bude táto považovať za nepodstatnú vadu (C). Prijatie nahlásenia vady zhotoviteľ bezodkladne potvrdí objednávateľovi v IS Service desk a reklamovanú vadu bezplatne v stanovenej lehote, počítanej počnúc nahlásením vady v súlade s týmto bodom tejto zmluvy o dielo, na svoje náklady odstráni.

Článok VIII

Kľúčový experti

1. Zhotoviteľ sa zaväzuje vytvoriť a dodať predmet zmluvy prostredníctvom kľúčových expertov t. j. fyzické osoby označené zhotoviteľom, prostredníctvom ktorých zhotoviteľ preukazoval splnenie podmienok účasti a/alebo boli predmetom hodnotenia kritérií vo verejnom obstarávaní, ktorého výsledkom je táto zmluva o dielo a ktoré sú uvedené v Prílohe č. 5 zmluvy o dielo, prostredníctvom ktorých sa zhotoviteľ zaväzuje poskytovať plnenie predmetu zmluvy.

2. Zhotoviteľ vyhlasuje a zaväzuje sa, že zabezpečí účasť na plnení predmetu zmluvy kľúčovými expertmi v rozsahu počtu osobodní podľa prílohy č. 5 tejto zmluvy o dielo, čo bude dokladovať mesačnými výkazmi odpracovaných hodín (výkazmi práce). V prípade, ak zhotoviteľ poruší záväzok uvedený v predchádzajúcej vete, má objednávateľ právo na zmluvnú pokutu od zhotoviteľa vo výške 5.000 eur bez DPH za každé jednotlivé porušenie stanoveného záväzku zhotoviteľa.

3. Pri prípadnej zmeny kľúčového experta zhotoviteľa uvedeného v prílohe č. 5 tejto zmluvy musí byť počas celej doby trvania zmluvy zabezpečená minimálne rovnocenná úroveň odbornosti, kvalifikácie a skúseností, ktorú bude objednávateľ posudzovať rovnakým spôsobom, aký bol použitý pre účely vyhodnotenia ponúk vo verejnom obstarávaní zákazky, z ktorej vzišla táto zmluva o dielo.

4. Nedodržanie týchto požiadaviek podľa bodu 8.2. alebo 8.3. tohto článku zmluvy oprávňuje objednávateľa odstúpiť od tejto zmluvy s okamžitou účinnosťou ku dňu doručenia písomného odstúpenia od zmluvy z dôvodu podstatného porušenia zmluvy o dielo.

Článok IX

Zdrojový kód dodaného informačného systému

1. Zhotoviteľ je povinný v procese prevzatia a odovzdania Diela (čl. V) odovzdať objednávateľovi funkčné vývojové a produkčné prostredie, ktoré je súčasťou dodaného informačného systému.

2. Zhotoviteľ je povinný pri akceptácii dodávaného informačného systému alebo jeho časti odovzdať objednávateľovi Vytvorený zdrojový kód v jeho úplnej aktuálnej podobe, zapečatený, na neprepisovateľnom technickom nosiči dát s označením časti a verzie dodaného informačného systému, ktorej sa týka. Za odovzdanie Vytvoreného zdrojového kódu objednávateľovi sa na účely tejto zmluvy o dielo rozumie odovzdanie technického nosiča dát oprávnenej osobe objednávateľa. O odovzdaní a prevzatí technického nosiča dát bude oboma zmluvnými stranami spísaný a podpísaný preberací protokol.

3. Dodávaný informačný systém (Dielo) v súlade so požiadavkami na predmet zmluvy špecifikovaný v Prílohe č. 2 zmluvy o dielo neobsahuje Modul.

4. Dňom prevzatia dodaného informačného systému sa prístup k vytvorenému zdrojovému kódu vo vývojovom a produkčnom prostredí, vrátane nakladania s týmto zdrojovým kódom, začne riadiť podmienkami dohodnutými v Servisnej zmluve.

5. Vytvorený zdrojový kód musí byť v podobe, ktorá zaručuje možnosť overenia, že je kompletný a v správnej verzii, t. j. v takej, ktorá umožňuje kompiláciu, inštaláciu, spustenie a overenie funkcionality, a to vrátane kompletnej dokumentácie zdrojového kódu (napr. interfejsov a pod.) takejto Informačného systému alebo jeho časti. Zároveň odovzdaný Vytvorený zdrojový kód musí byť pokrytý testami (aspoň na 90%) a dosahovať rating kvality (statická analýza kódu) podľa CodeClimate/CodeQL a pod. (minimálne stupňa B). 

6. Pre zamedzenie pochybností, povinnosti zhotoviteľa týkajúce sa Vytvoreného zdrojového kódu platí i na akékoľvek opravy, zmeny, doplnenia, upgrade alebo update Vytvoreného zdrojového kódu a/alebo vyššie uvedenej dokumentácie, ku ktorým dôjde pri plnení tejto zmluvy o dielo alebo v rámci záručných opráv. Vytvorené zdrojové kódy budú vytvorené vyexportovaním z produkčného prostredia a budú odovzdané objednávateľovi na elektronickom médiu v zapečatenom obale. Zhotoviteľ je povinný umožniť objednávateľovi pri odovzdávaní Vytvoreného zdrojového kódu, pred zapečatením obalu, skontrolovať v priestoroch objednávateľa prítomnosť Vytvoreného zdrojového kódu na odovzdávanom elektronickom médiu.

7. Nebezpečenstvo poškodenia zdrojových kódov prechádza na objednávateľa momentom prevzatia dodaného informačného systému alebo jeho časti, pričom objednávateľ sa zaväzuje uložiť zdrojové kódy takým spôsobom, aby zamedzil akémukoľvek neoprávnenému prístupu tretej osoby. Momentom platnosti Servisnej zmluvy umožní objednávateľ poskytovateľovi, za predpokladu, že to je nevyhnutné, prístup k Vytvorenému zdrojovému kódu výlučne na účely plnenia povinností z  uzatvorenej Servisnej zmluvy.

Článok X

Práva duševného vlastníctva

1. Zhotoviteľom v rámci plnenia predmetu tejto zmluvy o dielo poskytnuté plnenie, alebo jeho časť, ktoré môže mať povahu, prípadne môže zahŕňať jedno alebo viac autorských diel podľa Autorského zákona. Autorské dielo na účely tejto zmluvy o dielo je najmä, ale nie len počítačový program (dodaný informačný systém) vrátane všetkých jeho súčastí, všetky druhy dokumentácie, zdrojový, strojový kód, databázy, a to ako celok alebo jednotlivé časti, ktoré boli vytvorené alebo ktorých vytvorenie bolo zhotoviteľom zabezpečené špecificky na účely predmetu plnenia podľa tejto zmluvy o dielo bez ohľadu na ich verziu (ďalej ktorékoľvek z nich len „Autorské dielo“). Dodaný informačný systém, ktorý bol vyvinutý na základe špecifických požiadaviek objednávateľa. Účelom úpravy autorských práv je vylúčiť akúkoľvek závislosť objednávateľa od zhotoviteľa pri použití s dodaným informačným systémom v autorskoprávnom rozsahu.

2. Zmluvné strany sa dohodli, že pokiaľ zhotoviteľ vytvorí v rámci plnenia tejto zmluvy o dielo pre objednávateľa Autorské dielo, tak zhotoviteľ na akékoľvek takéto Autorské dielo udeľuje objednávateľovi výhradnú, počas celej doby trvania majetkových práv, územne, vecne neobmedzenú a v cene za dielo splatnú licenciu.  Licencia zahŕňa všetky spôsoby použitia Autorského diela podľa § 19 ods. 4 Autorského zákona. Pre vylúčenie pochybností licencia zahŕňa právo Autorské dielo spracovať (dokončenie diela, zmenu diela, začlenenia do iných diel alebo iný zásah do diela), vrátane v rovnakom rozsahu výkonu autorských práv k strojovým a zdrojovým kódom najmä právo ich kopírovania, prekladania, prispôsobovania, modifikovania, upravovania a začleňovania do iných diel), a to prostredníctvom objednávateľa alebo tretej osoby. Zhotoviteľ nie je oprávnený využívať Autorské dielo alebo ktorúkoľvek jeho časť diela pre vlastné produkty a služby, ak sa zmluvné strany písomne nedohodnú inak. Objednávateľ je oprávnený udeliť sublicenciu tretím osobám. Vlastnícke právo k veciam, prostredníctvom ktorých je Autorské dielo vyjadrené, nadobúda objednávateľ ich prevzatím.

3. Zmluvné strany sa dohodli, že účinnosť licencie podľa bodu 10.2. tohto článku zmluvy o dielo nastáva prevzatím Diela alebo jeho časti (čiastkové plnenie). V prípade predčasného ukončenia tejto zmluvy o dielo bez odovzdania diela alebo jeho časti je licencia udelená v súlade s touto zmluvou dňom ukončenia zmluvy. Zhotoviteľ je oprávnený Autorské dielo používať v rozsahu vymedzenom touto zmluvou o dielo počas jej trvania.

4. Odmena za udelenie licencie k Autorskému dielu (dodanému informačnému systému) alebo jeho časti spôsobom, v rozsahu a na čas uvedený v tomto článku zmluvy o dielo je súčasťou ceny za dodanie Diela, v  súlade s článkom IV tejto zmluvy o dielo. V prípade pochybností o sume zodpovedajúcej cene licencie bude cena licencie výlučne na účely tejto zmluvy o dielo zodpovedať 10 % celkovej ceny Diela.

5. Zmluvné strany výslovne deklarujú, že ak pri poskytovaní plnenia podľa tejto zmluvy o dielo vznikne činnosťou zhotoviteľa a objednávateľa dielo spoluautorov a ak sa nedohodnú zmluvné strany výslovne inak, bude sa mať za to, že objednávateľ vykonáva majetkové práva autora k dielu spoluautorov. Celková cena Diela podľa článku IV tejto zmluvy o dielo je stanovená so zohľadnením tohto ustanovenia a zhotoviteľovi nevzniknú v prípade vytvorenia diela spoluautorov žiadne nové nároky na odmenu.

6. Zhotoviteľ vyhlasuje, že vykonáva majetkové práva autora ku každému Autorskému dielu vytvorenému a dodanému na základe tejto zmluvy o dielo a žiadna tretia osoba nie je oprávnená vykonávať majetkové práva autora k Autorskému dielu alebo s Autorským dielom v zmysle Autorského zákona. Zhotoviteľ vyhlasuje, že je oprávnený udeliť objednávateľovi licenciu v rozsahu a v súlade s touto zmluvou o dielo. V prípade, ak tretia strana sa bude voči objednávateľovi domáhať porušenia svojich autorských práv je zhotoviteľ povinný bezodkladne vysporiadať s takouto treťou stranou autorské práva, aby zodpovedali jeho vyhláseniam a udelenej licencií v tejto zmluve o dielo a zároveň zodpovedá za všetku škodu, ktorá objednávateľovi tým vznikla.

7. Ak sa zmluvné strany nedohodnú inak, zhotoviteľ touto zmluvou o dielo prevádza na objednávateľa všetky osobitné práva zhotoviteľa databázy podľa § 135 ods. 1 Autorského zákona, ktoré má zhotoviteľ, ako zhotoviteľ databázy, k súčastiam plnenia predmetu tejto zmluvy dielo, ktoré sú databázou, a to v rozsahu uvedenom v tomto článku zmluvy o dielo.

8. Zmluvné strany sa dohodli, že pokiaľ zhotoviteľ pri plnení zmluvy o dielo, ako súčasť Diela použije (spravidla ich spracovaním) SW 3. strany (vrátane prípadu, ak autorizovaným poskytovateľom licencie k SW 3. strany je zhotoviteľ), v takomto prípade zabezpečí objednávateľovi oprávnenie používať takýto SW 3. strany v súlade s osobitnými licenčnými podmienkami (ďalej len „proprietárny SW“).

9. Špecifikácia proprietárneho SW tvorí prílohu č. 7 tejto zmluvy o dielo. Na použitie proprietárneho SW musí platiť, že zabezpečia úplnú a neobmedzenú realizáciu predmetu zmluvy a licencie budú časovo trvať minimálne do uplynutia obdobia trvania záručnej doby podľa bodu 7.2. tejto zmluvy o dielo. Pre použitie zhotoviteľom modifikovaného open source softvéru platí, že zhotoviteľ nemôže k open source softvéru pridať doplňujúce podmienky v rozpore s licenciou udelenou podľa tejto zmluvy.

10. Prípadná zmena v osobe zhotoviteľa (napr. právne nástupníctvo) nebude mať vplyv na oprávnenia udelené v rámci tejto zmluvy o dielo zhotoviteľom objednávateľovi.

11. Zhotoviteľ sa zaväzuje samostatne zdokumentovať všetky využitia proprietárneho SW a predložiť objednávateľovi ich ucelený prehľad vrátane ich licenčných podmienok najneskôr v čase podpísania Záverečného akceptačného protokolu v zmysle bodu 5.19. tejto zmluvy o dielo.

12. Ak sú s použitím proprietárneho SW, služieb podpory k nemu v rozsahu v akom sú nevyhnutné, či iných súvisiacich plnení, spojené akékoľvek poplatky, je zhotoviteľ povinný v súlade s bodom 4.5. tejto zmluvy o dielo riadne uhradiť všetky tieto poplatky za celú dobu trvania zmluvy o dielo a tiež počas obdobia trvania záručnej doby; to neplatí pre ďalšie licencie.

13. Zhotoviteľ v súlade s článkom IV tejto Zmluvy o dielo zodpovedá za úhradu licenčných poplatkov za použitie proprietárneho SW a súvisiacich služieb podpory a iných plnení.

14. SW, ktoré sú počítačovým programom, proprietárne SW, iné ako uvedené v Prílohe č. 7 tejto zmluvy o dielo je možné urobiť súčasťou Diela len na základe predchádzajúceho písomného súhlasu objednávateľa.

Článok XI

Vyhlásenia zmluvných strán

1. Zhotoviteľ vyhlasuje, že je spôsobilý uzatvoriť túto zmluvu o dielo a riadne plniť záväzky z nej vyplývajúce.

2. Zhotoviteľ vyhlasuje, že disponuje všetkými oprávneniami požadovanými príslušnými orgánmi a/alebo vyžadovanými príslušnými právnymi predpismi a že má k dispozícii nevyhnutné kapacity a technické schopnosti na riadne a včasné zhotovenie Diela podľa podmienok dohodnutých v tejto zmluve o dielo.

3. Zhotoviteľ vyhlasuje, že má splnené povinnosti, ktoré mu vyplývajú v zmysle zákona o registri partnerov verejného sektora a počas trvania tejto zmluvy o dielo bude udržiavať zápis v tomto registri a riadne plniť všetky povinnosti vyplývajúce pre neho zo zákona o registri partnerov verejného sektora.

4. Zhotoviteľ vyhlasuje, že pre prípad zodpovednosti za škodu spôsobenú pri plnení povinností podľa tejto zmluvy o dielo uzatvorí poistnú zmluvu s predmetom plnenia v prospech objednávateľa, čo preukazuje objednávateľovi pred podpisom zmluvy o dielo predložením platnej a účinnej poistnej zmluvy, ktorej predmetom je poistenie zodpovednosti za škodu spôsobenú konaním zhotoviteľa v súvislosti s plnením podľa tejto zmluvy o dielo na poistnú sumu v minimálnom  rozsahu celkovej ceny predmetu zmluvy.

5. Objednávateľ podpisom zmluvy o dielo vyhlasuje, že na účely plnenia tejto zmluvy o dielo zhotoviteľom má zabezpečenú IT infraštruktúru takým spôsobom, že riadne a včasné plnenie povinností zhotoviteľom bude objektívne možné a bude v súlade s preambulou tejto zmluvy o dielo

Článok XII

Všeobecné práva a povinnosti zmluvných strán

1. Objednávateľ sa zaväzuje, pokiaľ to nevylučujú všeobecne záväzné právne predpisy, iné zmluvné záväzky alebo interné predpisy objednávateľa:

   1. zabezpečiť zhotoviteľovi v primeranom rozsahu potrebné informácie a prípadné konzultácie k postaveniu alebo štatútu, organizačnej štruktúre, procesnému riadeniu a vnútorným predpisom objednávateľa,

   2. zabezpečiť pre zhotoviteľa, pri dodržaní bezpečnostných a ďalších predpisov objednávateľa, nevyhnutné poverenia na plnenie tejto zmluvy o dielo,

   3. sprístupniť, pri dodržaní bezpečnostných a ďalších predpisov objednávateľa, technickú, komunikačnú a systémovú infraštruktúru pre zhotovovanie Diela a podľa potreby vzdialeného prístupu dohodnutou technológiou a zabezpečiť zhotoviteľovi na jeho žiadosť včasný prístup k všetkým zariadeniam, ku ktorým je jeho prístup potrebný pre zhotovenie Diela, vrátane zdrojov energie, elektronickej komunikačnej siete, vrátane zabezpečenia vzdialeného prístupu, v rozsahu nevyhnutnom pre riadne zhotovenie Diela na náklady objednávateľa, s výnimkou nákladov na prevádzku komunikačnej linky pre vzdialený prístup,

   4. zabezpečiť zhotoviteľovi všetky relevantné legislatívne, metodické, koncepčné, dokumentačné, normatívne a ďalšie materiály týkajúce sa Diela, ak bude objednávateľ takými informáciami disponovať a zhotoviteľ ich bude potrebovať k zhotoveniu Diela, to však len za predpokladu, že zhotoviteľ nemá k takýmto materiálom sám prístup a len v rozsahu, v akom si tento prístup nevie zhotoviteľ zabezpečiť sám,

   5. zabezpečiť nevyhnutné relevantné prístupy na pracoviská objednávateľa pre zamestnancov zhotoviteľa vykonávajúcich práce na Diele alebo jeho časti počas pracovných dní a počas pracovnej doby objednávateľa,

   6. zabezpečiť vstup na pracoviská objednávateľa výlučne za prítomnosti Oprávnenej osoby objednávateľa prípadne v sprievode inej poverenej osoby objednávateľa,

   7. vykonať všetky úkony, ktoré je možné od neho spravodlivo požadovať pri poskytovaní súčinnosti objednávateľa zhotoviteľovi,

   8. informovať zhotoviteľa o všetkých skutočnostiach, ktoré sú významné pre splnenie povinností zmluvných strán podľa tejto zmluvy o dielo, v súvislosti so zhotovením Diela podľa tejto zmluvy o dielo a/alebo o dôvodoch, ktoré objednávateľovi bránia riadne a včas splniť svoje povinnosti podľa tejto zmluvy o dielo, a to do 48 (štyridsiatich ôsmich) hodín odkedy sa o nich objednávateľ dozvedel.

2. Zhotoviteľ sa zaväzuje:

   1. pri plnení povinností podľa tejto zmluvy o dielo dodržiavať pokyny a podklady objednávateľa, ktoré nie sú v rozpore s ustanoveniami tejto zmluvy o dielo,

   2. neodkladne písomne informovať objednávateľa o každom prípadnom omeškaní, či iných skutočnostiach, ktoré by mohli ohroziť riadne a včasné zhotovenie a/alebo dodanie Diela,

   3. poskytnúť oprávnenej osobe objednávateľa alebo inej poverenej osobe objednávateľa informáciu o stave plnenia zmluvy o dielo alebo informáciu súvisiacu s plnením na základe žiadosti objednávateľa s lehotou vybavenia neprevyšujúcou päť kalendárnych dní,

   4. bez zbytočného odkladu prerokúvať s objednávateľom všetky otázky, ktoré by mohli negatívne ovplyvniť zhotovenie Diela pri plnení jeho záväzkov podľa tejto zmluvy o dielo,

   5. zabezpečiť vedenie pracovných výkazov a zabezpečiť, aby aj jeho subdodávatelia priebežne viedli pracovné výkazy (okrem prípadov uvedených v tejto zmluve o dielo) a bezodkladne ich poskytnúť na požiadanie objednávateľovi,

   6. udržiavať nasadené časti dodaného informačného systému do prevádzky v súlade s dodanou administrátorskou dokumentáciou, a to až do odovzdania a  prevzatia dodaného informačného systému ako celku,

   7. poskytovať objednávateľovi nevyhnutnú súčinnosť za účelom používania nasadených častí dodaného informačného systému,

   8. umožniť objednávateľovi vykonať audit bezpečnosti dodaného informačného systému a vývojového prostredia zhotoviteľa na overenie miery dodržiavania bezpečnostných požiadaviek vyplývajúcich z platných a účinných právnych predpisov a zmluvných požiadaviek,

   9. prijať opatrenia na zabezpečenie nápravy zistení z auditu bezpečnosti dodaného informačného systému,

   10. poskytnúť objednávateľovi a jemu nadriadeným orgánom plnú súčinnosť pri riešení bezpečnostného incidentu a vyšetrovaní bezpečnostnej udalosti, ktoré súvisia s plnením tejto zmluvy o dielo,

   11. poskytnúť objednávateľovi kompletnú dokumentáciu dodaného informačného systému vrátane administrátorských prístupov,

   12. vypracovať posúdenie vplyvu na ochranu údajov v zmysle čl. 35 GDPR, ak pri používaní Informačného systému dochádza k spracovateľským operáciám osobných údajov,

   13. zabezpečiť, aby zhotovený, dodaný informačný systém umožňoval poskytovať automatizovaný monitoring SLA parametrov dodaných koncových a aplikačných služieb,

   14. dodržiavať pokyny a podklady objednávateľa, ktoré nie sú v rozpore s ustanoveniami tejto zmluvy o dielo.

Článok XIII

Súčinnosť zhotoviteľa

1. Zhotoviteľ sa zaväzuje spolupracovať s objednávateľom počas vykonávania Diela a vyvinúť maximálne úsilie a súčinnosť z jeho strany tak, aby bolo Dielo vykonané v súlade s touto zmluvou o dielo.

2. Zhotoviteľ sa zaväzuje, že pri predčasnom ukončení tejto zmluvy o dielo zo strany objednávateľa a zmene subjektu na strane zhotoviteľa poskytne objednávateľovi alebo subjektu určenému objednávateľom primeranú súčinnosť pri prechode na nový subjekt na strane zhotoviteľa, najmä v oblasti architektúry a integrácie informačných systémov a informuje nový subjekt na strane zhotoviteľa o všetkých procesných a iných úkonoch pri plnení tejto zmluvy o dielo so zreteľom na úkony týkajúce sa odovzdania Diela alebo jeho časti v súlade s článkom V tejto zmluvy o dielo. Zhotoviteľ je povinný poskytnúť súčinnosť novému subjektu na strane zhotoviteľa podľa tohto bodu v období maximálne 6 (šesť) mesiacov od predčasného ukončenia tejto zmluvy o dielo a v rozsahu minimálne 40 osobohodín konzultácií a ďalších činností/úkonov v zmysle bodu 13.3. tohto článku zmluvy o dielo za kalendárny mesiac. Objednávateľ a zhotoviteľ môžu za týmto účelom podpísať písomný dodatok k zmluve o dielo, ktorého predmetom bude poskytnutie súčinnosti tretej strane teda novému subjektu na strane zhotoviteľa.

3. Zhotoviteľ sa zaväzuje poskytnúť súčinnosť v zmysle predchádzajúceho bodu tohto článku Zmluvy o dielo, najmä v oblasti:

   1. podpory a prípravy verejného obstarávania za účelom vysúťaženia nového zhotoviteľa (najmä vo forme konzultácií zo strany zhotoviteľa),

   2. nevyhnutnej podpory nového zhotoviteľa po podpise zmluvy (najmä vo forme zaškolenia zamestnancov nového zhotoviteľa),

   3. konkrétnych konzultácii vzťahujúcim sa k Dielu, a to aj po uplynutí platnosti a účinnosti tejto zmluvy o dielo.

4. Objednávateľ a zhotoviteľ sa dohodli, že súčinnosť v zmysle tohto článku zmluvy o dielo je súčasťou celkovej ceny Diela.

Článok XIV

Ochrana zamestnancov zhotoviteľa a subdodávateľov

1. Zhotoviteľ pri plnení tejto zmluvy o dielo zodpovedá za svojich zamestnancov, ich bezpečnosť a ochranu zdravia pri práci, a tiež za svojich subdodávateľov. Zhotoviteľ je povinný vykonať všetky nevyhnutné opatrenia, aby zabezpečil v súvislosti s plnením tejto zmluvy o dielo bezpečnosť svojich zamestnancov, zamestnancov objednávateľa, subdodávateľov a ďalších osôb, ktoré sa s vedomím objednávateľa zdržujú v mieste plnenia tejto zmluvy o dielo.

2. Zhotoviteľ je povinný v súvislosti s plnením tejto zmluvy o dielo vykonať opatrenia a určiť postupy na zaistenie bezpečnosti svojich zamestnancov a subdodávateľov a zabezpečiť prostriedky potrebné na ochranu života a zdravia zamestnancov v mieste plnenia tejto zmluvy o dielo pre prípad vzniku bezprostredného a vážneho ohrozenia života alebo zdravia; o vykonaných opatreniach je zhotoviteľ povinný informovať objednávateľa a ďalšie osoby zdržujúce sa na mieste plnenia tejto zmluvy o dielo.

3. Objednávateľ je povinný v mieste plnenia tejto zmluvy o dielo a v jeho priestoroch objednávateľa zabezpečiť pracovné podmienky súladné s pravidlami bezpečnosti a ochrany zdravia práci.

4. Zhotoviteľ je povinný bezodkladne oboznamovať objednávateľa o nedostatkoch a iných závažných skutočnostiach v priestoroch objednávateľa tvoriacich miesto plnenia tejto zmluvy o dielo, ktoré by pri práci mohli ohroziť bezpečnosť alebo zdravie zamestnancov zhotoviteľa alebo jeho subdodávateľov, zamestnancov objednávateľa alebo tretích osôb, o ktorých sa dozvedel v súvislosti s plnením tejto zmluvy o dielo.

5. Zhotoviteľ je povinný bezodkladne oboznámiť objednávateľa o mimoriadnej udalosti (nebezpečná udalosť, pracovný úraz zamestnanca zhotoviteľa alebo inej osoby konajúcej v mene zhotoviteľa), ktorá sa stala v súvislosti s plnením tejto zmluvy o dielo v priestoroch objednávateľa a ktorá sa týka ochrany zamestnancov zhotoviteľa a jeho subdodávateľov. Povinnosť zhotoviteľa podľa predchádzajúcej vety platí aj vtedy, ak k mimoriadnej udalosti nedošlo v súvislosti s plnením tejto zmluvy o dielo, ale došlo k nej na pracoviskách objednávateľa.

6. Zhotoviteľ je povinný zaraďovať zamestnancov na výkon práce so zreteľom na ich zdravotný stav, schopnosti, kvalifikačné predpoklady a odbornú spôsobilosť podľa právnych predpisov a ostatných predpisov na zaistenie bezpečnosti a ochrany zdravia pri práci a nedovoliť, aby vykonávali práce, ktoré nezodpovedajú ich zdravotnému stavu a schopnostiam a na ktoré nemajú vek, kvalifikačné predpoklady alebo doklad o odbornej spôsobilosti podľa právnych predpisov a  iných normatívnych aktov na zaistenie bezpečnosti a ochrany zdravia pri práci.

Článok XV

Osobitné záväzky zhotoviteľa

1. Zhotoviteľ a objednávateľ sa dohodli, že počas trvania zmluvy o dielo bude pre evidovanie vád, chýb, nedostatkov, incidentov a žiadostí využívaný informačný systém na evidenciu a správu prevádzkových incidentov poskytnutý objednávateľom (ďalej aj „IS Service Desk“), pokiaľ sa zmluvné strany písomne nedohodnú inak. IS Service Desk je používaný aj na poskytovanie servisných služieb podľa tejto zmluvy o dielo. IS Service Xxxx eviduje vadu a chybu ako incident.

2. Zhotoviteľ ďalej nie je oprávnený postúpiť a ani založiť akékoľvek svoje pohľadávky voči objednávateľovi vzniknuté na základe alebo v súvislosti s touto zmluvou alebo s plnením záväzkov podľa tejto zmluvy bez predchádzajúceho písomného súhlasu objednávateľa. Zhotoviteľ nie je oprávnený jednostranne započítať akúkoľvek svoju pohľadávku voči objednávateľovi vzniknutú z akéhokoľvek dôvodu proti pohľadávke objednávateľa voči zhotoviteľovi vzniknutej na základe alebo v súvislosti s touto zmluvou o dielo bez predchádzajúceho písomného súhlasu objednávateľa. Zhotoviteľ nie je oprávnený postúpiť práva a povinnosti z tejto zmluvy o dielo na tretiu osobu.

Článok XVI

Xxxxx Xxxxx, zmeny zmluvy o dielo

1. Ak objednávateľ v priebehu plnenia tejto zmluvy o dielo zistí, že pre zabezpečenie funkčnosti a kompatibility Diela ako celku je nevyhnutné rozšíriť Dielo o ďalšiu časť alebo časti, je oprávnený zabezpečiť zhotovenie takej časti alebo častí prostredníctvom uzatvorenia písomného dodatku k tejto zmluve o dielo; písomný dodatok k tejto zmluve o dielo nie je povinné uzatvoriť, ak hodnota všetkých zmien je vo finančnom vyjadrení nižšia ako 10 % hodnoty (pôvodnej) tejto zmluvy o dielo v súlade s § 18 ods. 3 písm. b) zákona o verejnom obstarávaní (de minimis) a táto zmena zmluvy o dielo je schválená Riadiacou radou projektu.

2. Akékoľvek zmeny tejto zmluvy o dielo v zmysle predchádzajúceho bodu, okrem dodatku de minimis, možno realizovať na základe oboma zmluvnými stranami podpísaného dodatku k zmluve o dielo; to neplatí ak je inde v zmluve výslovne upravené inak, a to za predpokladu, že sú splnené podmienky podľa § 18 zákona o verejnom obstarávaní;

3. Zmena termínu dodania čiastkového plnenia mimo termínu fakturačného míľnika nevyžaduje písomný dodatok k tejto zmluve o dielo. Takúto zmenu musí schváliť Riadiaca rada projektu.

Článok XVII

Zmluvné pokuty

1. Objednávateľ je oprávnený požadovať od zhotoviteľa zmluvnú pokutu vo výške:

   1. 0,10 % (slovom jedna desatina percenta) z celkovej ceny Diela, za každý (aj začatý) deň omeškania, ak je zhotoviteľ v omeškaní so splnením povinnosti odovzdať Dielo v termíne podľa bodu 3.4. tejto zmluvy o dielo o viac ako 7 (sedem) kalendárnych dní,

   2. 0,05 % z celkovej ceny Diela, za každý (aj začatý) deň omeškania, ak je zhotoviteľ v omeškaní so splnením povinnosti poskytnúť, aj jednotlivú, súčinnosť podľa článku XIII tejto zmluvy o dielo,

   3. 0,10 % z celkovej ceny Diela, za každý (aj začatý) deň omeškania, ak je zhotoviteľ v omeškaní so splnením povinnosti odovzdať jednotlivé čiastkové plnenie (časť Diela) v termíne špecifikovanom v časovom harmonograme podľa prílohy č. 3 tejto zmluvy o dielo,

   4. 0,10 % z celkovej ceny Diela, za každý (aj začatý) deň omeškania, ak je zhotoviteľ v omeškaní so splnením povinnosti odstrániť Zásadnú vadu Diela (A) do 2 pracovných dní v zmysle prílohy č. 8 tejto zmluvy o dielo,

   5. 0,05 % z celkovej ceny Diela, za každý (aj začatý) deň omeškania, ak je zhotoviteľ v omeškaní so splnením povinnosti odstrániť Závažnú vadu Diela úrovne (B) do 5 pracovných dní alebo Nepodstatnú vadu do 10 pracovných dní (C) v zmysle prílohy č. 8 tejto zmluvy o dielo,

   6. 10.000,- eur (slovom: desaťtisíc eur), za každý (aj začatý) deň omeškania, ak je zhotoviteľ v omeškaní so splnením povinnosti odovzdať vývojové prostredie dodaného informačného systému podľa bodu 9.1. tejto zmluvy o dielo,

   7. 10.000,- eur (slovom: desaťtisíc eur) za každý aj začatý deň omeškania, ak je zhotoviteľ v omeškaní so splnením povinnosti v zmysle bodu 9.2. tejto zmluvy o dielo,

   8. 10 % z celkovej ceny Diela, ak zhotoviteľ poruší povinnosť zhotoviteľa podľa bodu 2.1.1. tejto zmluvy o dielo,

   9. 1 % z celkovej ceny Diela, ak zhotoviteľ neposkytne ktorúkoľvek z licencií podľa článku X tejto zmluvy o dielo objednávateľovi (pre odstránenie pochybností je objednávateľ uplatniť zmluvnú pokutu za neposkytnutie každej licencie samostatne), a to za každý deň omeškania s poskytnutím licencie podľa článku X zmluvy o dielo,

   10. 5 % z celkovej ceny Diela, ak zhotoviteľ nevyvíja Dielo v bezpečnom vývojovom prostredí podľa metodiky vývoja upravenej v Prílohe č. 2 tejto zmluvy o dielo

   11. 5 % z celkovej ceny Diela, ak zhotoviteľ nepostupuje pri zhotovení Diela podľa pokynov a/alebo podkladov poskytnutých objednávateľom podľa bodu 18.5 tejto zmluvy o dielo,

   12. 2 % z celkovej ceny Diela, ak zhotoviteľ bez zbytočného odkladu písomne neupozorní objednávateľa na nevhodnú povahu pokynov a/alebo podkladov poskytnutých objednávateľom s adekvátnym odôvodnením nevhodnosti povahy takýchto pokynov a/alebo podkladov, ak mohol túto nevhodnosť zistiť pri vynaložení odbornej starostlivosti.

   13. 2 % z celkovej ceny Diela, ak zhotoviteľ poruší niektorú z povinností zhotoviteľa podľa bodu 12.2. tejto zmluvy o dielo.

2. Objednávateľ je oprávnený uplatniť si zmluvné pokuty podľa bodu 17.1 tejto zmluvy o dielo maximálne však do výšky 50 % celkovej ceny Diela.

3. Ak sa objednávateľ dostane do omeškania so splnením peňažného záväzku alebo jeho časti, má zhotoviteľ právo uplatniť si z nezaplatenej sumy úroky z omeškania v súlade s § 369a Obchodného zákonníka a v sadzbe podľa Nariadenia vlády Slovenskej republiky č. 21/2013 Z. z., ktorým sa vykonávajú niektoré ustanovenia Obchodného zákonníka v znení neskorších predpisov.

4. Ak sa zhotoviteľ dostane do omeškania so splnením peňažného záväzku alebo jeho časti, má objednávateľ právo uplatniť si z nezaplatenej sumy úroky z omeškania v súlade s § 369 Obchodného zákonníka a v sadzbe podľa Nariadenia vlády Slovenskej republiky č. 21/2013 Z. z., ktorým sa vykonávajú niektoré ustanovenia Obchodného zákonníka v znení neskorších predpisov.

5. Zaplatením zmluvnej pokuty nie je dotknutý nárok zmluvnej strany na náhradu škody v celom rozsahu, ktorá bola spôsobená porušením povinnosti, na ktorú sa vzťahuje zmluvná pokuta.

Článok XVIII

Zodpovednosť za škodu a náhrada škody

1. Nebezpečenstvo škody na Diele a jeho časti prechádza na objednávateľa podpísaním Akceptačného protokolu vzťahujúceho sa k odovzdávanej časti Diela oboma zmluvnými stranami, pričom nebezpečenstvo škody na Diele ako celku prechádza na objednávateľa podpísaním Záverečného akceptačného protokolu podpísaného oboma zmluvnými stranami.

2. Každá zo zmluvných strán nesie zodpovednosť za spôsobenú škodu porušením všeobecne platných a účinných právnych predpisov Slovenskej republiky a tejto zmluvy o dielo. Zmluvné strany sa zaväzujú vyvinúť maximálne úsilie k predchádzaniu škodám a k minimalizácii vzniknutých škôd. Zmluvné strany sa zaväzujú k vyvinutiu maximálneho úsilia na odvrátenie a prekonanie okolností vylučujúcich zodpovednosť.

3. Zhotoviteľ zodpovedá za škodu spôsobenú objednávateľovi jeho zamestnancami a/alebo subdodávateľmi, pričom ustanovenia Obchodného zákonníka o náhrade škody aplikovateľné na škodu spôsobenú subdodávateľmi, týmto nie sú dotknuté.

4. Zhotoviteľ zodpovedá za škodu spôsobenú vadou dodaného informačného systému, ktorá vznikne objednávateľovi aj po uplynutí trvania tejto zmluvy o dielo počas plynutia záručnej doby podľa článku VII tejto zmluvy o dielo.

5. Zhotoviteľ je povinný postupovať pri plnení pokynov a zadaní zo strany objednávateľa s odbornou starostlivosťou, pričom je povinný bez zbytočného odkladu písomne upozorniť objednávateľa na nevhodnú povahu pokynov a/alebo podkladov poskytnutých objednávateľom s adekvátnym odôvodnením nevhodnosti povahy takýchto pokynov a/alebo podkladov, ak mohol túto nevhodnosť zistiť pri vynaložení odbornej starostlivosti. Ak zhotoviteľ písomne neupozorní objednávateľa na nevhodnosť pokynov, nemôže sa zbaviť zodpovednosti za vzniknutú škodu, iba ak nevhodnosť nemohol zistiť ani pri vynaložení odbornej starostlivosti. Zhotoviteľ nezodpovedá za škodu, ktorá vznikla v dôsledku nevhodného pokynu alebo podkladu zo strany objednávateľa, ak zhotoviteľ bezodkladne písomne upozornil objednávateľa na nevhodnosť tohto pokynu alebo podkladu a objednávateľ na takom pokyne alebo podklade naďalej trval.

6. Ak nevhodné pokyny a/alebo podklady dané objednávateľom prekážajú v riadnom plnení povinností zhotoviteľa podľa tejto zmluvy o dielo, je zhotoviteľ povinný ich plnenie v nevyhnutnom rozsahu prerušiť do doby výmeny nevhodných podkladov alebo zmeny pokynov objednávateľa alebo písomného oznámenia, že objednávateľ trvá na poskytnutí plnení podľa tejto zmluvy o dielo s použitím jeho podkladov a pokynov. O dobu, po ktorú bolo potrebné plnenie povinností zhotoviteľa podľa tejto zmluvy o dielo prerušiť sa predlžuje lehota určená na ich splnenie. Zhotoviteľ má takisto nárok na úhradu preukázaných a odôvodnených nákladov spojených s prerušením plnenia jeho povinností podľa tejto zmluvy o dielo za podmienok uvedených v tomto bode alebo s použitím nevhodných podkladov objednávateľa do doby, keď sa ich nevhodnosť mohla zistiť; uvedené neplatí, ak zhotoviteľ objednávateľa na nevhodnosť pokynov objednávateľa neupozornil a nevhodnosť mohol zistiť pri vynaložení odbornej starostlivosti.

7. Zmluvné strany sa zaväzujú upozorniť písomne druhú zmluvnú stranu bez zbytočného odkladu na vzniknuté okolnosti vylučujúce zodpovednosť, brániace riadnemu plneniu tejto zmluvy o dielo. O dobu, po ktorú bolo potrebné plnenie povinností zhotoviteľa podľa predchádzajúcej vety prerušiť, možno predĺžiť lehotu určenú na ich splnenie na základe rozhodnutia a schválenia Riadiacou radou projektu.

8. Zhotoviteľ je oprávnený zabezpečiť plnenie tejto zmluvy o dielo alebo jej časti prostredníctvom subdodávateľov v súlade s podmienkami verejného obstarávania a touto zmluvou o dielo. Zhotoviteľ zodpovedá za každé plnenie takéhoto subdodávateľa v rozsahu, ako keby plnenie poskytoval sám.

Článok XIX

Záverečné ustanovenia

1. Vzájomné práva a povinnosti zmluvných strán sú tiež upravené vo všeobecných podmienkach uvedených v Prílohe č. 1 tejto zmluvy o dielo.

2. Táto Zmluva o dielo môže byť menená v súlade s príslušnými ustanoveniami zákona o verejnom obstarávaní len formou písomných a očíslovaných dodatkov, ktoré budú schválené a podpísané oprávnenými zástupcami oboch zmluvných strán; to neplatí ak je v tejto zmluve o dielo uvedené inak.

3. Pojmy, výrazy, skratky uvedené v zmluve o dielo a v jej prílohách, pokiaľ z obsahu zmluvy o dielo nevyplýva niečo iné, majú význam definovaný v Prílohe č. 5 - Slovník pojmov, ktorá tvorí neoddeliteľnú súčasť zmluvy o dielo.

4. V prípade zmeny ktoréhokoľvek z údajov uvedených v záhlaví tejto zmluvy o dielo je príslušná zmluvná strana, ktorej sa zmena týka, povinná túto skutočnosť bezodkladne písomne oznámiť druhej zmluvnej strane, pričom v prípade tejto zmeny nie je potrebné uzatvárať písomný dodatok. Ak zmluvné strany nesplnia svoju oznamovaciu povinnosť, má sa zato, že platia posledné známe identifikačné údaje alebo údaje vyplývajúce z príslušného registra.

5. V prípade akýchkoľvek nejasností, neprevzatia písomností či pochybností pri doručovaní písomností bude za deň doručenia považovaný tretí pracovný deň nasledujúci po dni, kedy bola písomnosť preukázateľne odoslaná na adresu zmluvnej strany uvedenú v záhlaví tejto zmluvy o dielo, resp. na inú adresu písomne oznámenú druhej zmluvnej strane.

6. Táto zmluva o dielo je uzavretá podľa právneho poriadku Slovenskej republiky, pričom práva, povinnosti a právne vzťahy neupravené touto zmluvou sa riadia príslušnými ustanoveniami zákona č. 513/1991 Zb. Obchodného zákonníka v znení neskorších predpisov a inými príslušnými všeobecne záväznými právnymi predpismi.

7. Zmluvné strany sa zaväzujú, že budú postupovať v súlade s oprávnenými záujmami druhej strany a že vykonajú všetky právne úkony, ktoré sa ukážu byť nevyhnutné pre realizáciu činností upravených touto zmluvou o dielo. Záväzok súčinnosti sa vzťahuje len na také úkony, ktoré prispejú alebo majú prispieť k dosiahnutiu účelu tejto zmluvy o dielo.

8. Zmluvné strany sa zaväzujú prípadné zmeny právneho stavu, ktoré by mohli mať vplyv na plnenie podmienok tejto zmluvy o dielo, oznámiť písomne druhej zmluvnej strane najneskôr 30 dní pred predpokladanou zmenou.

9. V prípade sporného výkladu ustanovení tejto zmluvy o dielo alebo neplnenia záväzkov zmluvných strán sa obidve zmluvné strany budú snažiť prednostne dosiahnuť vzájomnú dohodu. Pokiaľ sa zmluvné strany nedohodnú, budú sa snažiť dosiahnuť súdny zmier. Prípadné spory týkajúce sa výkladu a realizácie tejto zmluvy o dielo budú riešené vecne a miestne príslušnými súdmi Slovenskej republiky.

10. V prípade rozporu medzi ustanoveniami tejto zmluvy o dielo a dispozitívnymi ustanoveniami všeobecne záväzných právnych predpisov právneho poriadku Slovenskej republiky, platia ustanovenia tejto zmluvy o dielo. V prípade rozporu medzi ustanoveniami tejto zmluvy o dielo a ustanoveniami všeobecne záväzných právnych predpisov právneho poriadku Slovenskej republiky, ktoré je možné dohodou zmluvných strán vylúčiť, platia ustanovenia tejto zmluvy o dielo a uvedené ustanovenia všeobecne záväzných právnych predpisov právneho poriadku Slovenskej republiky sa považujú za výslovne vylúčené.

11. V prípade rozporu medzi ustanoveniami tejto zmluvy o dielo a ustanoveniami uvedenými vo všeobecných podmienkach majú odchylné ustanovenia tejto zmluvy o dielo prednosť.

12. Zmluva o dielo bude záväzná pre všetkých právnych nástupcov zhotoviteľa, kým nebude ukončená v súlade s ustanoveniami uvedenými v tejto zmluva o dielo.

13. V prípade, ak sa niektoré ustanovenie tejto zmluvy o dielo stane neplatným, neúčinným alebo nevykonateľným, nie sú tým dotknuté ostatné ustanovenia tejto zmluvy o dielo. Príslušné ustanovenie zmluvy o dielo sa nahradí takým platným a účinným zákonným ustanovením, ktoré je mu svojím významom a účelom najbližšie.

14. Objednávateľ pri spracúvaní osobných údajov, poskytnutých zhotoviteľom pre účely plnenia tejto zmluvy, postupuje v súlade so zákonom č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov a nariadenia Európskeho parlamentu a Rady (EÚ) č. 2016/679 z 27. apríla 2016 o ochrane fyzických osôb pri spracúvaní osobných údajov a o voľnom pohybe takýchto údajov, ktorým sa zrušuje smernica 95/46/ES. Informácia o podmienkach spracúvania osobných údajov dotknutých osôb je zverejnená na webovom sídle objednávateľa: xxxxx://xxx.xxx.xx/xx/xxxxxxx-xxxxxxxx-xxxxxx.

15. V prípade, ak bude objednávateľ poskytovať alebo sprístupňovať zhotoviteľovi v súvislosti s plnením podľa tejto zmluvy o dielo informácie obsahujúce osobné údaje chránené v zmysle nariadenia Európskeho parlamentu a rady (EÚ) 2016/679 o ochrane fyzických osôb pri spracúvaní ich osobných údajov a o voľnom pohybe takýchto údajov, ktorým sa zrušuje smernica 95/46/ES (všeobecné nariadenie o ochrane údajov) a zákona č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov v znení neskorších predpisov, je zhotoviteľ povinný s objednávateľom uzatvoriť zmluvu v zmysle § 28 zákona č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov.

16. Táto zmluva o dielo je vyhotovená a uzavretá v (4) štyroch rovnopisoch, pričom objednávateľ dostane (3) tri rovnopisy a zhotoviteľ dostane (1) jeden rovnopis. Všetky rovnopisy sú považované za rovnocenné.

17. Táto zmluva o dielo (vrátane jej prípadných dodatkov) patrí medzi povinne zverejňované zmluvy podľa ustanovení § 5a zákona o slobodnom prístupe k informáciám (zákona č. 211/2000 Z. z. v znení neskorších predpisov) v spojení s ustanoveniami § 1 ods. 2 Obchodného zákonníka (zákona č. 513/1991 Zb. v znení neskorších predpisov) a ustanoveniami § 47a Občianskeho zákonníka (zákona č. 40/1964 Zb. v znení neskorších predpisov). Zhotoviteľ súhlasí so zverejnením tejto zmluvy o dielo (vrátane jej prípadných dodatkov) a faktúr Zhotoviteľa doručených objednávateľovi, a to zverejnenie objednávateľom počas trvania jeho povinnosti podľa § 5a ods. 1, 6 a 9 a § 5b zákona o slobodnom prístupe k informáciám.

18. Táto zmluva o dielo nadobúda platnosť a je pre zmluvné strany záväzná odo dňa jej podpísania oprávnenými zástupcami oboch zmluvných strán; ak oprávnení zástupcovia oboch zmluvných strán nepodpíšu túto zmluvu o dielo v ten istý deň, tak rozhodujúci je deň neskoršieho podpisu. Táto zmluva o dielo bude následne zverejnená na webovom sídle objednávateľa a nadobudne účinnosť najskôr odo dňa účinnosti zmluvy o dielo, v súlade s ustanoveniami § 47a ods. 2 Občianskeho zákonníka v spojení s § 1 ods. 2 Obchodného zákonníka a § 5a ods. 1, 6 a 9 zákona o slobodnom prístupe k informáciám.

19. Zmluvné strany (každá za seba) zhodne vyhlasujú, že sú plne spôsobilé na právne úkony, že ich zmluvná voľnosť nie je žiadnym spôsobom obmedzená, že sú oprávnené plniť si v celom rozsahu záväzky dohodnuté touto zmluvou. Súčasne zmluvné strany (každá za seba) zhodne vyhlasujú, že sa s touto zmluvou dôkladne oboznámili a jej obsahu porozumeli, pričom táto zmluva je určitá a zrozumiteľná a plne zodpovedá slobodnej, vážnej a určitej vôli zmluvných strán. Na dôkaz týchto skutočností zmluvné strany prostredníctvom svojich oprávnených zástupcov podpísali túto zmluvu.

20. Neoddeliteľnou súčasťou tejto zmluvy sú prílohy:

Príloha č. 1 – Všeobecné podmienky k zmluve o dielo

Príloha č. 2 – Požiadavky na predmet zmluvy

Príloha č. 3 – Harmonogram fakturačných míľnikov

Príloha č. 4 – Špecifikácia ceny

Príloha č. 5 – Zoznam osôb zhotoviteľa určených na plnenie zmluvy a zoznam subdodávateľov zhotoviteľa

Príloha č. 6 – Slovník pojmov

Príloha č. 7 – Zoznam použitých SW a SW 3. strán

Príloha č. 8 – Klasifikácia vád dodaného informačného systému, lehoty na ich odstránenie

Za objednávateľa: Za zhotoviteľa:

V Bratislave, dňa __.__.20__ V <vyplní uchádzač >, dňa __.__.20__

___________________________________ ___________________________________

<vyplní VO> <vyplní uchádzač>

Príloha č. 1

Všeobecné podmienky k zmluve o dielo

(ďalej aj „všeobecné podmienky“, alebo „podmienky“)

Tieto všeobecné podmienky tvoria ako Príloha č. 1 neoddeliteľnú súčasť zmluvy o dielo (ďalej len „zmluva“ ako aj „zmluva o dielo“). Odchylné dojednania v zmluve o dielo uzavretej v zmysle týchto všeobecných podmienok majú prednosť pred ustanoveniami uvedenými v týchto všeobecných podmienkach.

Článok I

Zodpovednosť za vady, záruka a odstraňovanie vád

1. Zhotoviteľ zodpovedá za to, že Dielo, predmet plnenia dodané, poskytnuté na základe zmluvy o dielo bude mať vlastnosti a funkcionalitu požadovanú objednávateľom,  budú poskytnuté v dohodnutom čase a ich poskytnutím nebude ohrozená prevádzka iného informačného systému objednávateľom.

2. Zhotoviteľ zodpovedá za to, že dodané Dielo alebo čiastkové plnenie ku dňu podpisu Akceptačného protokolu/Záverečného protokolu a počas záručnej doby je bez vád.

3. Zhotoviteľ zaručuje, že predmet plnenia v čase jeho poskytnutia/odovzdania nemá vecné a právne vady, predovšetkým nie je zaťažené právami tretích osôb z autorského alebo iného práva duševného vlastníctva.

4. Objednávateľ je oprávnený požadovať od zhotoviteľa bezplatné a bezodkladné odstránenie vady na ktorú sa vzťahuje záruka podľa tejto zmluvy o dielo a na ktorú sa nevzťahuje odstraňovanie vád podľa špecifickej klasifikácie a stanovených lehôt ich odstránenia podľa zmluvy o dielo. Na uplatnenia nároku sa použije IS Service Desk objednávateľa, ak sa zmluvné strany písomne nedohodnú inak. Zhotoviteľ je povinný prijatie nahlásenia vady bez zbytočného odkladu potvrdiť. Zmluvné strany sa zaväzujú potvrdiť odstránenie vady v zápisnici o odstránení vady podpísanej oboma zmluvnými stranami, v ktorej uvedú aj predmet vady, spôsob a čas jej odstránenia, alebo prostredníctvom IS Service Desk objednávateľa.

5. Nároky z vád sa nedotýkajú nároku na náhradu škody a nároku na zmluvnú pokutu.

6. Za účelom odstránenia pochybností sa stanovuje, že treba rozlišovať medzi:

a) vadou dodaného informačného systému (Diela), na ktorú sa vzťahuje záručná doba v zmysle zmluvy o dielo a práva a povinnosti zmluvných strán sa budú riadiť zmluvou o dielo;

b) vadou Servisných služieb spôsobenou neposkytnutím Servisných služieb podľa Servisnej zmluvy riadne (napr. vada Objednávkovej služby spôsobí nefunkčnosť dodaného informačného systému alebo iného diela zodpovedajúcu vade úrovne A alebo B), a v takom prípade sa budú práva a povinnosti zmluvných strán v súvislosti s takou vadou riadiť Servisnou zmluvou.

7. Záručná doba zo zmluvy o dielo a záručná doba z tejto Servisnej zmluvy majú rozdielny právny základ a ich plynutie je rozdielne.

Článok II

Vzdialený prístup

1. Objednávateľ umožní zhotoviteľovi vzdialený prístup k Dielu alebo čiastkovému plneniu s využitím systému pre vzdialený prístup objednávateľa. Tento vzdialený prístup bude pre zhotoviteľa zriadený v nevyhnutnom rozsahu, v ktorom je potrebný na plnenie zmluvy o dielo.

2. Zhotoviteľ bude využívať vzdialený prístup v dňoch a časoch, ako je stanovené v popisoch pre dostupnosť služieb v Prílohe č. 2 tejto zmluvy, a to výlučne na poskytovanie predmetu zmluvy poskytovaných zhotoviteľovom na základe zmluvy o dielo.

3. Objednávateľ poskytuje vzdialený prístup pre zhotoviteľa bez akýchkoľvek záruk a vyhradzuje si právo dočasne prerušiť poskytovanie vzdialeného prístupu v prípade podozrenia na jeho zneužitie alebo aj bez udania dôvodu. Takéto prerušenie poskytovania vzdialeného prístupu nemôže byť chápané ako prekážka vo výkone poskytovania vzdialeného prístupu alebo porušenie zmluvy o dielo a zhotoviteľ si z tohto titulu nemôže nárokovať akúkoľvek náhradu škody alebo zľavy v ostatných zmluvných vzťahoch medzi objednávateľom a zhotoviteľom.

4. Objednávateľ poskytuje zhotoviteľovi podporu pre systém pre vzdialený prístup v pracovných dňoch v čase 8:00 h až 16:00 h.

5. Zhotoviteľ je oprávnený požiadať o zriadenie prístupového účtu externého používateľa iba pre osoby oprávnené vzdialene pristupovať v mene zhotoviteľa podľa článku II týchto všeobecných podmienok.

6. Zhotoviteľ je oprávnený požiadať o vzdialený prístup k IKT objednávateľa prostredníctvom oprávnenej osoby. Schvaľovanie vzdialeného prístupu externého používateľa prebieha podľa osobitných vnútorných právnych predpisov objednávateľa, s ktorými bude zhotoviteľ oboznámený.

7. Zhotoviteľ sa zaväzuje, že zabezpečí, aby externí používatelia pri vzdialenom prístupe dodržiavali všetky zmluvné a všeobecne záväzné právne predpisy vzťahujúce sa k vzdialenému prístupu k IKT objednávateľa. Zhotoviteľ sa ďalej zaväzuje, že po nadobudnutí účinnosti zmluvy o dielo sa riadne a preukázateľne oboznámi so všetkými relevantnými vnútornými právnymi predpismi objednávateľa týkajúcimi sa informačnej bezpečnosti.

8. Zhotoviteľ sa zaväzuje, že zabezpečí, aby jeho externí používatelia dodržiavali povinnosti externých používateľov uvedené v tomto bode. Externý používateľ je povinný:

a) dodržiavať pravidlá a postupy podľa bodu 10. až 16. tohto článku,

b) požiadať oprávnenú osobu objednávateľa o neodkladné zablokovanie svojho prístupového účtu v prípade výskytu akejkoľvek udalosti, v dôsledku ktorej by mohlo dôjsť k zneužitiu vzdialeného prístupu zriadeného externému používateľovi,

c) pri výskyte závažnej udalosti týkajúcej sa chránených informácií neodkladne informovať oprávnenú osobu objednávateľa,

d) upozorniť oprávnenú osobu objednávateľa na zistené nedostatky, ktoré sa vyskytnú počas vzdialeného prístupu,

e) poskytnúť súčinnosť pri riešení incidentov týkajúcich sa vzdialeného prístupu,

f) vrátiť hardvérový token alebo iný fyzický prostriedok, ktorý mu bol pridelený pri zriadení používateľského účtu a ktorý sa využíva pre potreby viacfaktorovej autentifikácie, pri zrušení alebo ukončení využívania vzdialeného prístupu.

9. Porušenie záväzkov zhotoviteľa uvedených (aj jednotlivo určených) v bodoch 7., 8.,10., 11., 12., 13., 14., 15., 16. a 17. tohto článku všeobecných podmienok sa považuje za podstatné porušenie zmluvy o dielo.

10. Zmluvné strany sa dohodli, že zriadenie a prevádzka prístupových účtov pre externých používateľov zhotoviteľa sa nespoplatňuje. Vzdialený prístup nie je zo strany zhotoviteľa nárokovateľný a zhotoviteľ rešpektuje právo objednávateľa zriaďovať vzdialené prístupy v rozsahu, ktorý objednávateľ považuje za potrebný.

11. Externý používateľ pri využívaní vzdialeného prístupu postupuje podľa používateľskej dokumentácie, ktorá mu bude dodaná po zriadení jeho prístupového účtu. Dokumentácia obsahuje:

a) Postup pre kontrolu výpočtovej techniky pred pripojením,

b) Postup pre vzdialené pripojenie a odpojenie,

c) Postup pre nahlasovanie incidentov,

d) Poučenie používateľov vzdialeného prístupu.

12. Externý používateľ smie na vzdialené pripojenie do NBS používať iba schválenú výpočtovú techniku uvedenú v žiadosti o zriadenie/zrušenie prístupového účtu externého používateľa s aktualizovaným operačným systémom a inštalovaným a aktuálnym antivírusovým softvérom.´

13. Nie je dovolené vzdialene sa pripájať k IKT objednávateľa z výpočtovej techniky, ktorá obsahuje alebo obsahovala počítačový vírus alebo škodlivý softvér, o ktorom bol externý používateľ notifikovaný antivírusovým softvérom a ktorý nebol odborne odstránený.

14. Externý používateľ nesmie hardvérový token, alebo iný fyzický prostriedok, ktorý sa využíva pre potreby viacfaktorovej autentifikácie poskytnúť inej osobe a je povinný v najkratšom možnom čase ohlásiť jeho stratu alebo odcudzenie kontaktnej osobe objednávateľa.

15. Externý používateľ nesmie počas využívania vzdialeného prístupu opustiť pripojenú výpočtovú techniku, dovoliť iným osobám prístup k tejto technike, alebo sledovanie jej aktívnej obrazovky.

16. Externý používateľ smie vzdialene pristupovať výhradne k IS a infraštruktúram IS, ktoré sú definované v bode 1 tohto článku.

17. Externý používateľ nesmie na virtuálne PC inštalovať žiadny dodatočný softvér. V prípade potreby inštalácie dodatočného softvéru na virtuálne PC o jej vykonanie požiada kontaktnú osobu objednávateľa.

18. Zhotoviteľ sa zaväzuje, že vráti objednávateľovi všetky technické prostriedky a vybavenie, ktoré mu boli zo strany objednávateľa poskytnuté za účelom vzdialeného prístupu, najneskôr do 5 dní od dňa ukončenia trvanie zmluvy o dielo.

19. V prípade nedodržania záväzku zhotoviteľa podľa bodu 18., bude objednávateľ oprávnený uplatniť voči zhotoviteľovi zmluvnú pokutu, ktorú sa Zhotoviteľ zaväzuje uhradiť. Zmluvná pokuta sa vypočíta ako súčin poplatku 200 eur s DPH (ktorý pokrýva náklady objednávateľa na technické vybavenie jedného používateľa) a počtu používateľov zhotoviteľa.

20. Zhotoviteľ sa zaväzuje objednávateľovi uhradiť zmluvnú pokutu do 14 pracovných dní od doručenia písomného uplatnenia zmluvnej pokuty (výzvou resp. doručením faktúry) zo strany objednávateľa. Čiastku zmluvnej pokuty uhradí Zhotoviteľ objednávateľovi bezhotovostným prevodom. Údaje pre vykonanie bezhotovostného prevodu zmluvnej pokuty oznámi objednávateľ zhotoviteľovi v písomnom uplatnení zmluvnej pokuty.

Článok III

Informačná bezpečnosť

1. Zhotoviteľ sa v súvislosti s plnením predmetu zmluvy o dielo zaväzuje dodržiavať pri podpore prevádzky dodaného informačného systému bezpečnostnú politiku objednávateľa a objednávateľom vydané platné bezpečnostné smernice a štandardy.

2. Oprávnené osoby a pracovníci zhotoviteľa, ktorí budú vykonávať pre objednávateľa činnosti súvisiace s plnením zmluvy o dielo, musia byť poučení o povinnostiach podľa predchádzajúceho bodu tohto článku a o tomto poučení musí zhotoviteľ vytvoriť záznam, ktorý bude podpísaný poučenou osobou a osobou, ktorá poučenie vykonala. Za riadne poučenie zodpovedá zhotoviteľ. Zhotoviteľ je povinný predložiť objednávateľovi potvrdenie o oboznámení zamestnancov a subdodávateľov s platnými bezpečnostnými štandardmi objednávateľa, a to podľa vzoru objednávateľa, ak zhotoviteľovi takýto vzor poskytne.

3. Zhotoviteľ sa zaväzuje v priebehu trvania vykonávania Diela priebežne sledovať a vyhodnocovať bezpečnosť a odolnosť čiastkového plnenia voči aktuálne známym typom útokov, resp. poskytovať súčinnosť objednávateľovi pri zaisťovaní bezpečnosti odolnosti.

4. Zhotoviteľ sa zaväzuje poskytnúť objednávateľovi kontaktnú osobu zodpovednú za kybernetickú bezpečnosť zhotoviteľa.

5. Objednávateľ je oprávnený zaslať  kontaktnej osobe zhotoviteľa informácie ohľadom podozrení na bezpečnostne relevantné udalosti týkajúce sa zhotoviteľa.

6. Objednávateľ je oprávnený na zisťovanie stavu kybernetickej bezpečnosti zhotoviteľa použiť služby tretích strán.

7. Objednávateľ je oprávnený zbierať informácie o kybernetickej bezpečnosti IT prostredia zhotoviteľa bez predchádzajúceho upozornenia a oznámenia rozsahu a spôsobu zisťovania.

8. Zhotoviteľ poskytne objednávateľovi písomné vyjadrenie k odstráneniu príčin problémov v oblasti kybernetickej bezpečnosti.

9. V prípade kritických nedostatkov v kybernetickej bezpečnosti  musí zhotoviteľ zabezpečiť bezodkladnú nápravu nedostatkov. Každý takýto kritický nedostatok v kybernetickej bezpečnosti bude evidovaný, riadený, sledovaný a vyhodnocovaný ako bezpečnostný incident.

10. Zhotoviteľ sa zaväzuje informovať objednávateľa o každom svojom závažnom bezpečnostnom incidente.

11. Zhotoviteľ sa zaväzuje aplikovať a dodržiavať písomne vypracované pravidlá bezpečného vývoja, uvedené v Prílohe č. 2 tejto zmluvy o dielo, počas celej doby trvania zmluvného vzťahu a na požiadanie poskytnúť NBS.

12. Zhotoviteľ sa zaväzuje, že jeho zamestnanci a osoby ktoré sa podieľajú na tvorbe a úpravách zdrojových kódov sú preukázateľne regulárne vyškolení na pre bezpečný vývoj aplikácií.

13. Pravidlá bezpečného vývoja aplikácií obsahujú oblasti podľa “best practices”, ako napr. komentáre, funkčné testovanie, predchádzanie typickým bezpečnostným chybám, pravidelné bezpečnostné testovanie kódu integrované do procesu vývoja.

14. Objednávateľ je oprávnený posúdiť pravidlá bezpečného vývoja informačných systémov, aplikácií zhotoviteľa prostredníctvom tretej strany.

15. Zhotoviteľ sa zaväzuje dodržiavať štandardy stanovené objednávateľom a zakomponovať ich do svojich pravidiel bezpečného vývoja aplikácií pre dodaný informačný systém a zmeny dodaného informačného systému poskytované pre objednávateľa. 

16. Pred odovzdaním akejkoľvek zmeny dodaného informačného systému objednávateľa, Zhotoviteľ preverí bezpečnosť kódu a vyhotoví o tom záznam, kde budú zachytené vykonané testy a ich výsledky, tento záznam uchová po dobu min 24 mesiacov od mesiaca vykonania konkrétnej zmeny.

17. Ak odovzdávané dielo/zmena dodaného informačného systému obsahuje bezpečnostné nedostatky, ktoré sú klasifikované objednávateľom ako zásadný bezpečnostný incident, tak toto dielo/zmena nebude prevzaté do prevádzky objednávateľa, kým nebudú uvedené bezpečnostné nedostatky primerane odstránené, resp. ošetrené.

18. Súčasťou akceptácie akejkoľvek zmeny zo strany NBS je prehlásenie dodávateľa, že boli vykonané všetky predpísané úkony, existuje k nim dokumentácia a kód neobsahuje žiadne známe zraniteľnosti

19. Objednávateľ je oprávnený vykonávať preverenie bezpečnosti diela, pričom zhotoviteľ sa zaväzuje poskytnúť potrebnú súčinnosť (napr. dokumentáciu, vysvetlenia). Objednávateľ je oprávnený na preverenie bezpečnosti diela/zmeny použiť služby tretích strán.

Článok IV

Ochrana dôverných informácií

1. Dôverné informácie sú všetky informácie sprístupnené, poskytnuté objednávateľom zhotoviteľovi počas trvania zmluvy o dielo, ktoré nie sú verejne prístupné, a to najmä technické, obchodné, finančné alebo všetky iné informácie, ktoré objednávateľ poskytne zhotoviteľovi v akejkoľvek podobe či už zachytené hmotne alebo ústne poskytnuté, ako aj informácie prijaté od inej osoby ako je objednávateľ, pokiaľ je táto osoba zaviazaná s nimi nakladať ako s dôvernými (ďalej len „dôverné informácie“).

2. Dôvernými informáciami nie sú informácie, ktoré sú, alebo sa následne stanú verejne dostupnými inak ako porušením povinností podľa tejto zmluvy o dielo zhotoviteľom, verejne dostupnými sa stávajú dňom zverejnenia.

3. Zhotoviteľ sa zaväzuje:

- dodržiavať a prijať zodpovedajúce technické, organizačné a iné opatrenia potrebné na ochranu dôverných informácií v rozsahu ako je primerane obvyklé za účelom zabezpečenia neoprávneného pozmenenia, zničenia, straty, odcudzenia, zverejnenia, zneužitia alebo neoprávneným sprístupnením neoprávnenej osobe (ďalej ako „neoprávnená manipulácia s dôvernými informáciami“),

- dôverné informácie viesť od iných dôverných informácií, ktorými disponuje, aby sa predišlo ich zmiešaniu alebo zámene,

- bezodkladne oznámiť objednávateľovi každú neoprávnenú manipuláciu s dôvernými informáciami a zabezpečiť obnovu všetkých opatrení na ochranu dôverných informácií v zmysle tejto Servisnej zmluvy.

4. Zhotoviteľ je oprávnený využívať dôverné informácie iba pre účely plnenia zmluvy o dielo a po jej skončení nesmie bez akéhokoľvek časového obmedzenia použiť dôverné informácie na akýkoľvek účel. Likvidáciu dôverných informácií zabezpečí zhotoviteľ v súlade s článkom VI bod 17 všeobecných podmienok.

5. Zhotoviteľ nie je oprávnený dôverné informácie poskytnúť inej osobe, ako zamestnancom, oprávneným osobám zhotoviteľa a subdodávateľom ustanovenými v súlade s ustanoveniami zmluvy o dielo, ak ďalej nie je uvedené inak. Zároveň je povinný zaviazať všetky takéto osoby záväzkami mlčanlivosti a nakladania s dôvernými informáciami minimálne v rozsahu ako je zaviazaný sám touto zmluvou.

6. Zhotoviteľ je oprávnený poskytnúť dôverné informácie v nevyhnutnom rozsahu:

- príslušnému súdnemu, správnemu orgánu v súvislosti s akýmkoľvek súdnym, správnym, či iným úradným konaním vzniknutým a vedeným v súvislosti s obchodnými vzťahmi medzi zmluvnými stranami, alebo

- ak je ich poskytnutie požadované na základe rozhodnutia vydaného príslušným súdnym orgánom alebo orgánom verejnej správy, ktoré nadobudlo právne účinky, pričom sa zaväzuje včas a vopred oznámiť takúto povinnosť poskytnúť dôverné informácie objednávateľovi.

7. Zhotoviteľ môže poskytnúť dôverné informácie inej osobe ako je uvedená v bode 6 tohto článku iba po predchádzajúcom písomnom súhlase objednávateľa s takýmto poskytnutím a súčasne takáto osoba, ktorej sa majú poskytnúť dôverné informácie uzavrela dohodu o ochrane dôverných informácií s zhotoviteľ v rozsahu stanovenom zmluvou o dielo.

8. V prípade, že bude u zhotoviteľa inštalované vývojové prostredie dodaného informačného systému smie byť toto využívané len pre vykonanie činností pre zabezpečenie dodania predmetu zmluvy pre objednávateľa. Zhotoviteľ nie je oprávnený používať inštalované prostredia dodaného informačného systému pre prevádzku výpočtového strediska, teda za účelom spracovania dát tretích strán a/alebo osôb, napr. tým, že dovolí tretej strane a/alebo osobe užívanie dodaného informačného systému akýmkoľvek technickým spôsobom, alebo tým, že využije alebo umožní využitie dodaného informačného systému pre účely tretej strany a/alebo osoby.

9. Zmluvné strany písomne zaviažu svojich zamestnancov, iné strany a osoby, ktoré budú pracovať na základe zmluvy o dielo a týchto podmienok, na dodržiavanie povinností podľa tohto článku všeobecných podmienok.

10. Objednávateľ neposkytne zhotoviteľovi informácie, ktoré patria do zoznamu utajovaných skutočností v zmysle všeobecne záväzného právneho predpisu, ak tieto informácie nie sú nutné na splnenie predmetu zmluvy. V prípade, že tieto informácie budú potrebné k splneniu predmetu zmluvy o dielo bude sa postupovať v zmysle všeobecne záväzných predpisov upravujúcich ochranu utajovaných skutočností.

11. Zmluvné strany sa dohodli, že v prípade porušenia akejkoľvek povinnosti zhotoviteľa uvedenej v tomto článku všeobecných podmienok, má objednávateľ právo uplatniť voči zhotoviteľovi zmluvnú pokutu vo výške 70.000,- eur bez DPH (slovom: sedemdesiat tisíc eur), a to za každé jednotlivé porušenie povinnosti zhotoviteľa. Zmluvná pokuta je splatná do 3 dní odo dňa doručenia výzvy na zaplatenie zmluvnej pokuty. Povinnosť uhradiť zmluvnú pokutu vzniká bez ohľadu na skutočnosť, či objednávateľovi vznikla škoda v dôsledku porušenia povinnosti zhotoviteľa. Tým nie je dotknuté právo poškodenej osoby (objednávateľa) na náhradu škody v zmysle § 373 a nasl. Obchodného zákonníka.

Článok V

Subdodávatelia, register partnerov verejného sektora a iné povinnosti zhotoviteľa

1. Zhotoviteľ je povinný riadne a načas plniť záväzky vyplývajúce zo zmluvy o dielo a týchto podmienok vo vlastnom mene, na vlastný účet, na svoje náklady a na svoje nebezpečenstvo. Pokiaľ zhotoviteľ poverí plnením ktoréhokoľvek zo záväzkov podľa zmluvy o dielo a týchto podmienok tretiu stranu, má zhotoviteľ voči objednávateľovi rovnakú zodpovednosť za zhotovenie predmetu zmluvy a jeho poskytovanie a  za prípadné škody, náklady a únik dôverných informácií spôsobený treťou stranou, ako by plnil tieto záväzky sám.

2. Zhotoviteľ je povinný požiadať objednávateľa o zriadenie/zrušenie prístupu do dodaného informačného systému v súlade s  postupmi pre zabezpečenie prístupu do dodaného informačného systému v rámci zmluvy o dielo.

3. Zhotoviteľ podpisom tejto zmluvy potvrdzuje a zaväzuje sa, že na plnení zmluvy o dielo sa budú podieľať iba osoby legálne zamestnané zhotoviteľom v súlade s právnym poriadkom Slovenskej republiky.

4. V prípade, ak zhotoviteľ poruší svoju povinnosť podľa bodu 3 tohto článku všeobecných podmienok zmluvy o dielo a kontrolný orgán uloží objednávateľovi pokutu za porušenie zákazu prijať prácu alebo službu podľa § 7b ods. 5 zákona č. 82/2005 Z. z. o nelegálnej práci a nelegálnom zamestnávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov, tak sa zhotoviteľ zaväzuje uhradiť objednávateľovi zmluvnú pokutu v sume rovnajúcej sa pokute uplatnenej kontrolným orgánom u objednávateľa, a to do siedmich dní odo dňa jej uplatnenia u zhotoviteľa objednávateľom.

5. Zhotoviteľ je povinný na požiadanie objednávateľa bezodkladne poskytnúť v nevyhnutnom rozsahu doklady (pracovné zmluvy, dohody o prácach vykonávaných mimo pracovného pomeru v zmysle Zákonníka práce) a osobné údaje fyzických osôb, prostredníctvom ktorých plní zmluvu o dielo, a ktoré sú potrebné na to, aby objednávateľ mohol skontrolovať, či Zhotoviteľ neporušuje zákaz nelegálneho zamestnávania.

6. Zhotoviteľ sa zaväzuje, že zabezpečí, aby jeho zamestnanci a ostatné osoby zhotoviteľa konajúce v mene zhotoviteľa pri plnení zmluvy o dielo v objektoch objednávateľa dodržiavali všetky všeobecne záväzné právne predpisy vzťahujúce sa k vykonávaniu činností, hlavne predpisy súvisiace s bezpečnosťou práce a požiarnou bezpečnosťou, interné predpisy objednávateľa, najmä predpisy o vstupe do objektov objednávateľa a k bezpečnosti systémov a aby sa riadili organizačnými pokynmi oprávnených zamestnancov objednávateľa.

7. Objednávateľ na základe písomnej žiadosti zhotoviteľa je povinný zabezpečiť vstupy
   do svojich priestorov povereným osobám zhotoviteľa. Tento prístup zhotoviteľa bude vykonaný vždy len pod priamym dozorom objednávateľa za účelom včasného plnenia záväzkov zhotoviteľa dohodnutých v tejto zmluve o dielo a v súlade s internými predpismi objednávateľa upravujúcimi vstup zamestnancov cudzích organizácií a vykonávanie činnosti v priestoroch objednávateľa a bude platiť len na obdobie trvania tejto zmluvy o dielo.

8. Zhotoviteľ sa zaväzuje, že viacerí používatelia zhotoviteľa nebudú pristupovať do testovacieho a vývojového prostredia Diela (dodaný informačný systém) pod jedným identifikačným názvom.

9. Zhotoviteľ zodpovedá za plnenie zmluvy o dielo v súlade s § 41 ods. 8 zákona o verejnom obstarávaní a zhotoviteľ je povinný odovzdávať objednávateľovi plnenia sám, na svoju zodpovednosť, v dohodnutom čase a v dohodnutej kvalite.

10. Zhotoviteľ sa zaväzuje, počas celej doby trvania tejto zmluvy o dielo byť zapísaný v registri partnerov verejného sektora, a to v prípade, ak má túto povinnosť podľa zákona č. 315/2016 Z. z. o registri partnerov verejného sektora a o zmene a doplnení niektorých zákonov v znení neskorších predpisov (ďalej len „zákon č. 315/2016 Z. z.“). U subdodávateľa táto povinnosť platí, ak mu takáto povinnosť v zmysle zákon č. 315/2016 Z. z. vzniká, pričom za jej splnenie zodpovedá zhotoviteľ.

11. Zhotoviteľ potvrdzuje, že podľa § 41 ods. 3 zákona o verejnom obstarávaní uviedol v príslušnej prílohe zmluvy o dielo údaje o všetkých známych subdodávateľoch, údaje o osobe oprávnenej konať za subdodávateľoch v rozsahu meno a priezvisko, adresa pobytu/sídlo, dátum narodenia/IČO. Zhotoviteľ je povinný písomne oznámiť objednávateľovi akúkoľvek zmenu údajov o subdodávateľoch uvedených v príslušnej prílohe zmluvy o dielo do troch pracovných dní odo dňa uskutočnenia tejto zmeny.

12. V prípade zmeny subdodávateľa alebo doplnenia nového subdodávateľa, je zhotoviteľ povinný písomne oznámiť objednávateľovi údaje o navrhovanom subdodávateľovi v rozsahu podľa bodu 11 tohto článku, najmenej štyri pracovné dni pred jeho plánovaným využitím.

13. Počas trvania zmluvy o dielo je zhotoviteľ oprávnený zmeniť subdodávateľa uvedeného v príslušnej prílohe zmluvy o dielo výlučne na základe predchádzajúceho písomného oznámenia a predchádzajúceho písomného odsúhlasenia objednávateľom, pričom objednávateľ si vyhradzuje právo odmietnuť subdodávateľa, a to najmä v prípade, ak existuje dôvodný predpoklad, že plnenie záväzkov subdodávateľa podľa zmluvy o dielo je ohrozené a v prípade, ak subdodávateľ nespĺňa požiadavky na odborno-technickú spôsobilosť vo vzťahu k tej časti predmetu plnenia, ktorá má byť subdodávateľom plnená. Za účelom preukázania splnenia povinnosti v zmysle bodu 11 tohto článku všeobecných podmienok je zhotoviteľ povinný kedykoľvek na výzvu objednávateľa bezodkladne, najneskôr však do troch pracovných dní, predložiť objednávateľovi všetky zmluvy so subdodávateľmi identifikovanými v príslušnej prílohe zmluvy o dielo, resp. následne doplnenými/ zmenenými postupom podľa bodu 12 tohto článku všeobecných podmienok a zároveň predložiť zoznam všetkých subdodávateľov v zmysle § 2 ods. 1 písm. a) bod 7 zákona č. 315/2016 Z. z., ktorí napĺňajú definičné znaky partnera verejného sektora v zmysle § 2 ods. 1 písm. a) bod 7 a § 2 ods. 2 zákona č. 315/2016 Z. z., v dôsledku ich participácie na plnení zmluvy o dielo. Za úplnosť a pravdivosť poskytnutých údajov nesie plnú zodpovednosť zhotoviteľ.

14. V prípade, ak zhotoviteľ poruší povinnosť v zmysle bodu 11 tohto článku všeobecných podmienok, a teda bude zmluva o dielo plnená (resp. budú na jej plnení participovať) subdodávateľmi, ktorí si riadne nesplnili svoju zákonnú povinnosť zápisu (resp. jeho udržiavania) do registra partnerov verejného sektora, má objednávateľ právo na zmluvnú pokutu od zhotoviteľa vo výške 3 000,- eur bez DPH za každé jednotlivé porušenie stanovenej povinnosti.

15. V prípade omeškania zhotoviteľa so splnením záväzku (povinnosti) v zmysle bodu 11 tohto článku všeobecných podmienok, má objednávateľ právo na zmluvnú pokutu vo výške 1.000,- eur bez DPH, a to za každý aj začatý deň omeškania.

16. Zhotoviteľ sa môže odvolávať na objednávateľa vo svojich verejných materiáloch v tom zmysle, že ide o zákazníka zhotoviteľa s písomným súhlasom objednávateľa a nesmie bez predchádzajúceho písomného súhlasu objednávateľa, publikovať prácu zhotoviteľa podľa tejto zmluvy o dielo. Každá zo zmluvných strán sa zaväzuje, že nebude publikovať prácu vykonanú druhou zmluvnou stranou tak, že by použil názov druhej zmluvnej strany bez jej predchádzajúceho písomného súhlasu. V prípade odstúpenia od zmluvy o dielo sa zhotoviteľ zaväzuje dňom odstúpenia od zmluvy o dielo zrušiť odvolávku vo svojich verejných materiáloch o tom, že ide o zákazníka zhotoviteľa.

17. Zhotoviteľ je povinný na požiadanie objednávateľa po ukončení zmluvy o dielo vydať objednávateľovi všetky hmotné nosiče, ich kópie a vymazať programy uložené do pamäti, ako aj vydať všetku sprievodnú dokumentáciu a ostatné náležitosti patriace k dodanému informačnému systému, ktoré boli poskytnuté od objednávateľa.

18. Zhotoviteľ sa zaväzuje riadiť internými pravidlami riadenia projektov objednávateľa s ktorými ich po nadobudnutí účinnosti zmluvy o dielo objednávateľ oboznámi.

Článok VI

Zmluvné pokuty

Zaplatením zmluvnej pokuty nebude dotknutý nárok objednávateľa na náhradu škody. Zmluvné pokuty sa nezapočítavajú na úhradu škôd, ktoré objednávateľovi vzniknú porušením zmluvných povinností zhotoviteľa.

Článok VII

Zodpovednosť za škodu

1. Zhotoviteľ zodpovedá objednávateľovi za škody spojené s predmetom zmluvy o dielo v zmysle § 373 - § 386 Obchodného zákonníka.

2. Pre vylúčenie pochybností a príkladom platí, že zhotoviteľ zodpovedá objednávateľovi za škody spojené s predmetom zmluvy o dielo a jeho dodávkou, a to:

1. vzniknuté v dôsledku toho, že chod a funkčnosť dodaného informačného systému, komponentov, programov a funkcií, pokiaľ nebudú modifikované objednávateľom a ak objednávateľ neporuší svoje povinnosti, nebude zodpovedať chodu a funkčnosti dodaného systému uvedenému v sprievodnej dokumentácií dodaného informačného systému, ktorú zhotoviteľ odovzdal objednávateľovi a ktorá bola objednávateľom prijatá podľa tejto zmluvy o dielo,

2. takým spôsobom zapríčinené následné škody, ušlý zisk, straty dát alebo porušenia technických zariadení,

3. škody vzniknuté iným nedovoleným konaním, škody vzniknuté nedbanlivosťou, porušením zmluvy o dielo,

4. škody spôsobené na majetku objednávateľa zamestnancami a subdodávateľmi zhotoviteľa pri plnení tejto zmluvy o dielo.

Článok VIII

Ukončenie zmluvy o dielo

1. Zmluva o dielo zaniká:

a) uplynutím doby, na ktorú bola uzavretá,

b) písomnou dohodou zmluvných strán,

c) písomným odstúpením od zmluvy o dielo zmluvnou stranou podľa podmienok ustanovených v zmluve o dielo,

2. Odstúpiť od zmluvy o dielo je možné z dôvodov podstatného porušenia zmluvných povinností druhou zmluvnou stranou alebo v prípade nepodstatného porušenia zmluvných povinností zmluvy o dielo druhou zmluvnou stranou v prípadoch, ak to upravuje všeobecne záväzný právny predpis (napr. v zmysle § 19 ods. 3 zákona č. 343/2015 Z. z. alebo § 15 ods. 1 zákona č. 315/2016 Z. z. o registri partnerov verejného sektora a o zmene a doplnení niektorých zákonov v znení neskorších predpisov) alebo zmluva o dielo. Odstúpenie od zmluvy o dielo musí byť v písomnej forme doručené na adresu druhej zmluvnej strany.

3. Za nepodstatné porušenie zmluvy o dielo sa považuje každé porušenie zmluvy o dielo, okrem porušení zmluvy o dielo upravených v zmluve o dielo a/alebo v všeobecných podmienkach ako podstatné porušenie zmluvy o dielo. V prípade, ak ktorákoľvek zo zmluvných strán poruší nepodstatným spôsobom niektorú zo svojich povinností dohodnutých v zmluve o dielo a nesplní svoju povinnosť ani v dodatočne určenej primeranej lehote stanovenej dotknutou zmluvnou stranou, môže táto zmluvná strana od zmluvy o dielo zmluvy odstúpiť. Výzva na splnenie povinnosti s určením dodatočnej primeranej lehoty musí byť písomná a doručená druhej zmluvnej strane. Právne účinky odstúpenia od zmluvy o dielo zmluvy nastanú dňom doručenia písomného oznámenia o odstúpení druhej zmluvnej strany.

4. Ukončením zmluvy o dielo zmluvy nie je dotknutý nárok na náhradu škody vzniknutej porušením ustanovení zmluvy o dielo a tiež nie je dotknutý nárok na úhrady sumy zodpovedajúcej zmluvnej pokute, ktorý vznikol do účinnosti odstúpenia. Skončenie zmluvy o dielo nemá vplyv na ustanovenia, ktorých platnosť a účinnosť vzhľadom na ich povahu má trvať aj po skončení zmluvy o dielo.

5. Ak bude zmluva o dielo predčasne ukončená dohodou zmluvných strán, tvorí stanovenie spôsobu vysporiadania vzťahov vzniknutých na základe zmluvy o dielo podstatnú náležitosť dohody o ukončení účinnosti zmluvy o dielo. V rámci tejto dohody sa vysporiada aj udelenie licencií k odovzdanému dodanému informačnému systému alebo jeho časti v súlade s ustanoveniami o právach duševného vlastníctva podľa zmluvy o dielo.

6. Zmluvné strany sa dohodli, že objednávateľ môže odstúpiť od zmluvy o dielo, ak:

   1. zhotoviteľ preruší alebo skončí svoju podnikateľskú činnosť alebo stratí podnikateľské oprávnenie potrebné pre plnenie zmluvy o dielo,

   2. zhotoviteľ vstúpi do likvidácie bez právneho nástupcu,

   3. je zhotoviteľ preukázateľne v úpadku,

   4. sa zhotoviteľ stane spoločnosťou v kríze v zmysle § 67a Obchodného zákonníka,

   5. je majetok zhotoviteľa predmetom exekučného konania,

   6. bol zhotoviteľovi právoplatne uložený trest zrušenia právnickej osoby, trest zákazu činnosti, trest zákazu prijímať dotácie alebo subvencie, trest zákazu prijímať pomoc a podporu poskytovanú z fondov Európskej únie, trest zákazu účasti vo verejnom obstarávaní podľa zákona č. 91/2016 Z. z. o trestnej zodpovednosti právnických osôb a o zmene a doplnení niektorých zákonov v znení neskorších predpisov,

   7. bol štatutárny orgán zhotoviteľa alebo člen štatutárneho alebo dozorného orgánu zhotoviteľa právoplatne odsúdený za niektorý z trestných činov korupcie (trestné činy podľa ôsmej hlavy tretieho dielu osobitnej časti Trestného zákona), trestný čin legalizácie príjmov z trestnej činnosti (§ 233 Trestného zákona), trestný čin poškodzovania finančných záujmov Európskej únie (§ 263 Trestného zákona), trestný čin machinácie vo verejnom obstarávaní alebo vo verejnej dražbe (§ 266 Trestného zákona), ako aj za akýkoľvek trestný čin, ktorého skutková podstata súvisí s podnikaním zhotoviteľa v oblasti IT technológií alebo výkonom jeho činnosti,

   8. ak preukázateľne nastala skutočnosť, ktorá môže viesť k výmazu zhotoviteľa alebo jeho subdodávateľa v zmysle ustanovení zmluvy o dielo z registra partnerov verejného sektora podľa zákona o registri partnerov verejného sektora.

7. Zmluvné strany sa dohodli, že môžu odstúpiť od zmluvy o dielo, ak strana porušujúca zmluvu o dielo vedela v čase jej uzatvorenia alebo v tomto čase bolo možné rozumne predvídať s prihliadnutím na účel zmluvy o dielo, ktorý plynie z jej obsahu a z okolností jej uzatvorenia, že druhá zmluvná strana nebude mať záujem na plnení povinností pri takom porušení zmluvy o dielo.

Článok IX

Záverečné ustanovenia

1. Všetky dokumenty, oznámenia, žiadosti, správy, výzvy, požiadavky a ostatné písomnosti určené druhej zmluvnej strane (ďalej len „písomnosti“) musia byť doručené, ak zmluva o dielo neustanovuje inak v písomnej forme:

a) v listinnej podobe prostredníctvom pošty doporučene s doručenkou; za deň doručenia sa považuje dátum prevzatia zásielky,

b) osobne do sídla druhej zmluvnej strany alebo

c) elektronicky prostredníctvom informačného systému objednávateľa Service desk, e-mailom, a pri bežnej komunikácii zaslaním spätného potvrdzujúceho e-mailu príjemcom, pričom za spätný potvrdzujúci e-mail príjemcu sa nepovažuje správa automaticky vygenerovaná systémom.

2. V prípade, ak je to účelné a potrebné, objednávateľ sprístupní zhotoviteľovi v mieste poskytovania predmetu zmluvy na dobu a pre účel zhotovenia, dodania, poskytnutia predmetu zmluvy podľa tejto zmluvy o dielo a všeobecných podmienok nevyhnutný počet licencií na použitie softvéru, ktorý má objednávateľ v užívaní.

3. Zmluva o dielo a tieto podmienky sa riadia slovenským právnym poriadkom.

4. Všetky spory zo zmluvy a týchto podmienok alebo súvisiace s jej porušením, ukončením alebo neplatnosťou budú riešené s konečnou platnosťou vecne a miestne príslušným súdom Slovenskej republiky.

5. Práva a povinnosti zmluvných strán neupravené v zmluve o dielo a týchto podmienkach sa riadia príslušnými ustanoveniami Obchodného zákonníka a ďalšími všeobecne záväznými právnymi predpismi platnými na území Slovenskej republiky.

6. Komunikácia medzi objednávateľom a zhotoviteľom vrátane zmluvnými stranami vytvorenej písomnej dokumentácie sa bude v priebehu trvania zmluvy o dielo uskutočňovať výhradne v slovenskom a/alebo českom jazyku.

Príloha č. 2: Požiadavky na predmet zmluvy

Opis predmetu zákazky

Zmluvné strany 1

1. Objednávateľ: 1

2. Zhotoviteľ: 1

Preambula 3

A. Objednávateľ ako verejný obstarávateľ vyhlásil oznámením č. <doplní verejný obstarávateľ>, zverejneným vo Vestníku verejného obstarávania č. <doplní verejný obstarávateľ> dňa <doplní verejný obstarávateľ>, nadlimitnú zákazku podľa § 66 zákona č. 343/2015 Z. z. o verejnom obstarávaní a o zmene a doplnení niektorých zákonov v znení neskorších predpisov (ďalej len „zákon o verejnom obstarávaní“) s názvom Konsolidácia údajov DWH/BI. 3

B. Na základe vyhodnotenia ponúk bola ponuka zhotoviteľa vyhodnotená ako ponuka úspešného uchádzača. Vzhľadom na túto skutočnosť a predloženú ponuku zhotoviteľa sa zmluvné strany na základe slobodnej vôle a v súlade s právnymi predpismi platnými na území Slovenskej republiky rozhodli uzatvoriť túto zmluvu o dielo. 3

C. Súčasne s touto zmluvou o dielo objednávateľ so zhotoviteľom uzatvára aj Servisnú zmluvu č. C-NBS1-000-074-008 na poskytovanie služieb technickej podpory prevádzky, údržby a rozvoja dodaného informačného systému – Centrálny celobankový dátový sklad. 3

Článok I 3

Účel zmluvy 3

Účelom tejto zmluvy o dielo je vytvorenie dátového skladu, v ktorom budú všetky relevantné informácie a dáta, ktoré NBS používa na každodennej báze, dostupné z jedného bodu. Vytvorený dátový sklad má priniesť zvýšenie produktivity a efektivity v rámci riadenia a využívania dát NBS, zároveň má zabezpečiť zníženie operačného rizika spracovania dát, či zabezpečenie štandardnej kvality poskytovaných služieb NBS. 3

Článok II 4

Predmet zmluvy 4

2.1. Zhotoviteľ sa zaväzuje na vlastné náklady a nebezpečenstvo, riadne a včas, za cenu a za ďalších podmienok stanovených touto zmluvou o dielo pre objednávateľa: 4

2.1.1. vytvoriť a dodať informačný systém - Centrálny celobankový dátový sklad (ďalej len „Dielo“ alebo „dodaný informačný systém“), Dielo sa skladá z piatich častí, osobitných fáz, ktoré musia byť zhotovené, dodané, vzájomne aj jednotlivo funkčné, vzájomne integrované, a to postupne podľa termínov podľa Prílohy č. 3 Harmonogram platobných míľnikov (ďalej aj ako „čiastkové plnenie“). Súčasťou každej fázy bude akceptačné testovanie a skúšobná prevádzka čiastkového plnenia samostatne ako aj v integrácii už s odovzdanými čiastkovými plneniami dodávaného informačného systému, pričom súčasťou vykonávania Diela je aj: 4

2.1.2. poskytovanie služby podpora a údržba (ďalej spolu ako „servisné služby“) pre každé čiastkové plnenie odo dňa dodania čiastkového plnenia do dňa riadneho dodania Diela upravené v Prílohe č. 2 tejto zmluvy o dielo; 4

2.1.3. udelenie súhlasu na používanie autorských diel, resp. iných predmetov práv duševného vlastníctva, ktoré boli vytvorené na základe, resp. v rámci plnenia tejto zmluvy o dielo, a to v rozsahu požadovanom objednávateľom podľa tejto zmluvy o dielo; 4

2.1.4. dodanie, resp. zabezpečenie poskytnutia potrebných produktov, licencií SW produktom zhotoviteľa a 3. strán. 4

2.2. Zhotoviteľ sa zaväzuje vytvoriť, zhotoviť Dielo v nasledovnom rozsahu a jednotlivých plneniach: 4

2.2.1. zhotovenie Diela (dodaného informačného systému) v súlade s požiadavkami uvedenými v Prílohe č. 2 – Požiadavky na predmet zmluvy, vrátane súvisiacej dokumentácie; 4

2.2.2. realizácia riešenia, vrátane implementácie a testovania, ktorá zahŕňa: 4

2.2.2.1. vývoj, zabezpečenie a poskytnutie súčinnosti objednávateľovi pri implementácii dodaného informačného systému alebo čiastkového plnenia a pri uvedení produkčného prostredia 4

2.2.2.2. vyhotovenie podporných prostriedkov a konverzných programov vrátane vyhotovenia súvisiacej dokumentácie, 4

2.2.2.3. inštalácia, nastavenie parametrov a užívateľského nastavenia dodaného informačného systému a ich integrácia, 4

2.2.2.4. overenie funkčnosti a úplnosti dodaného informačného systému, 4

2.2.2.5. tvorba manuálov k SW (tvorba užívateľskej dokumentácie – užívateľských príručiek), 4

2.2.2.6. vyhotovenie dokumentácie o dodanom informačnom systéme, 4

2.2.3. vypracovanie detailnej analýzy požiadaviek objednávateľa, 4

2.2.4. vypracovanie návrhu dátového modelu na základe detailnej analýzy požiadaviek objednávateľa, 4

2.2.5. dodanie riešenia, ktoré bude v prípade spracovania osobných údajov pokrývať celý životný cyklus administrácie osobných údajov od evidencie až po ich 4

likvidáciu (vrátane vymazania osobných údajov na základe žiadosti dotknutej osoby). 4

2.2.6. realizácia integrácie na zdrojové systémy, vrátane pravidelného nahrávania dát do dátového skladu, 4

2.2.7. vypracovanie návrhu kapacitného plánu, 4

2.2.8. dodanie odporučenia konfigurácie DataLake a dodávka všetkých potrebných licencií tejto časti, 4

2.2.9. inštalácia SW zabezpečenia (DataLake časť DWH, Frameworky, ETL nástroja), 4

2.2.10. prevádzka a podpora SW zabezpečenia (DataLake časť DWH, Frameworky) počas trvania zmluvy o dielo, 4

2.2.11. vypracovanie návrhu a implementácia nového Knowledge Moduloi ODI, 4

2.2.12. implementovanie dátového modelu a dodávka inštalačných scriptov, 4

2.2.13. implementovanie ETL úloh a dodanie inštalačných nastavení, 4

2.2.14. implementácia reportov a analýzy podľa požiadaviek na predmet zmluvy, 4

2.2.15. implementovanie OUT objektov a transformácií dát do požadovaného formátu pre koncového odberateľa (Príloha č. 2 zmluvy o dielo) 4

2.2.16. dodanie nastavenia BI nástroja, 4

2.2.17. dodanie nasledovných frameworkov a nastavení metadát týchto frameworkov: 4

2.2.17.1. pre podporu správu, riadenie a monitoring aktualizačných úloh, 5

2.2.17.2. pre správu číselníkov, mostíkov, referenčných dát,  hierarchií jednotlivých dimenzií a manuálnych vstupov, 5

2.2.17.3. pre nahrávanie veľkého počtu a rôznych súborov, 5

2.2.17.4. pre správu, automatické spúšťanie a vyhodnocovanie dátovej kvality, 5

2.2.17.5. pre správu prístupov (riadenie bezpečnosti) k dátam, 5

2.2.17.6. pre správu dokumentácie k DWH a iných metadát (o modeli, o reportoch, mapovaní zdroj-cieľ) pre správu riadenia dátovej retencie. 5

2.2.18. poskytnutie projektového riadenia zastrešujúceho dodanie Diela; 5

2.2.19. vytvorenie a odovzdanie technickej dokumentácie implementovaného riešenia v súlade s požadovanými výstupmi; 5

2.2.20. zaškolenie obsluhy a používateľov objednávateľa dodaného informačného systému; 5

2.2.21. poskytovanie súčinnosti pri inštalácii a prevádzke neprodukčných prostredí DEv a TEST dodávaného informačného systému; 5

2.2.22. poskytovanie súčinnosti pre podporu produkčného prostredia dodaného informačného systému (súčasťou Diela je aj prevádzkový manuál); 5

2.2.23. poskytovanie súčinnosti pri inštalácii Diela na produkčné prostredia. 5

2.3. Zhotoviteľ sa zaväzuje dodať aj ostatné dodávky, činnosti a práce nevyhnutné pre realizáciu Diela, ktoré nie sú výslovne stanovené ako povinnosť objednávateľa, prípadne sú uvedené v Prílohe č. 2 tejto zmluvy o dielo alebo v článku XIII tejto zmluvy o dielo. 5

2.4. Zhotoviteľ sa zaväzuje na vlastné náklady zabezpečiť pre objednávateľa produkt (predplatné - subscription) pre DataLake na dobu od začiatku 2. fázy podľa Prílohy č. 3 tejto zmluvy o dielo do riadneho dodania Diela t. j. po podpísaní Záverečného akceptačného protokolu. 5

2.5. Zhotoviteľ sa zaväzuje na vlastné náklady zabezpečiť pre objednávateľa licencie SW v špecifikácii pracovnej stanice vývojára v zmysle príloh tejto zmluvy o dielo, ktoré sú pre vytvorenie a dodanie Diela nevyhnutné a nie sú súčasťou poskytnutých SW licencií od objednávateľa (Príloha č. 2 zmluvy o dielo). Tieto licencie sú pre objednávateľa zhotoviteľom zabezpečené s podporou výrobcu na dobu od začiatku vykonávania Diela po moment jeho riadneho dodania Diela t.j. po podpísaní Záverečného protokolu). Produkty (predplatné-subscription a licencie) podľa bodu 2.4. a bodu 2.5. sú spolu ďalej označené ako „ďalšie licencie“. 5

(ďalej bod 2.1.,2.2.,2.3.,2.4. a 2.5. spolu ako „predmet zmluvy“ alebo „predmet plnenia“). 5

2.6. Súčasťou predmetu zmluvy nie je: 5

2.6.1. dodanie a inštalácia HW serverov ani HW, 5

2.6.2. dodávka licencií produktov Oracle (DB, ODI) a Microsoft (DB, PoweBI). 5

2.6.3. inštalácia databázy pre relačnú časť DWH (ako DB, tak aj PowerBI), 5

2.6.4. inštalácia a prevádzka virtuálnych strojov s Linux OS (pre DataLake časť DWH), 5

2.6.5. inštalácia a prevádzka virtuálneho stroja s  aplikačnom serverom , 5

2.6.6. dodanie licencií aplikácie pre Dátové modelovanie. 5

2.7. Zhotoviteľ sa zaväzuje dodať predmet zmluvy v rozsahu a v súlade s požiadavkami, ktoré sú uvedené v Prílohe č. 2 – Požiadavky na predmet zmluvy, v Prílohe č. 3 – Harmonogram platobných míľnikov a v súlade s Prílohou č. 1- Všeobecné podmienky objednávateľa tejto zmluvy o dielo (ďalej len „Všeobecné podmienky“). 5

2.8. Ak sa budú na strane zhotoviteľa podieľať viaceré subjekty (konzorcium subjektov), práva z tejto zmluvy o dielo voči objednávateľovi môže uplatňovať výlučne ten subjekt na strane zhotoviteľa, ktorý bude mať podľa osobitnej dohody subjektov postavenie vedúceho subjektu. Subjekty na strane zhotoviteľa si v rámci osobitnej dohody podľa predošlej vety určia a vysporiadajú vzájomné záväzky a oprávnenia vyplývajúce im z tejto zmluvy o dielo. Subjekt, ktorý bude mať postavenie vedúceho subjektu na strane zhotoviteľa bude vo vzťahu k objednávateľovi zodpovedať za fakturáciu, odovzdávanie Diela alebo jeho časti, vrátane všetkých a akýchkoľvek úkonov týkajúcich sa plnenia tejto zmluvy o dielo a objednávateľ bude komunikovať výlučne s ním ohľadom všetkých zmluvných záležitostí. Ten subjekt na strane zhotoviteľa, ktorý má postavenie vedúceho subjektu na strane zhotoviteľa, je povinný bezodkladne oznámiť túto skutočnosť objednávateľovi. (Text platí ak sa na strane zhotoviteľa budú podieľať viaceré subjekty, ak nie uchádzač tento bod odstráni) 5

2.9. Objednávateľ sa zaväzuje riadne a včas dodaný predmet zmluvy resp. jeho časti prevziať v súlade s touto zmluvou o dielo a zaplatiť zaň dohodnutú cenu v rozsahu a za podmienok dohodnutých v tejto zmluve o dielo. 6

Článok III. 6

Miesto a termíny dodania predmetu zmluvy 6

3.1. Miestom dodania predmetu zmluvy je sídlo objednávateľa nachádzajúce sa na adrese Národná banka Slovenska, Xxxxxxx Xxxxxxx 0, 000 00 Xxxxxxxxxx, Xxxxxxxxx xxxxxxxxx. 6

3.2. Objednávateľ si vyhradzuje právo v prípade potreby zmeniť miesto dodania predmetu zmluvy na záložné technologické pracovisko nachádzajúce sa v Datacentre, Kopčianska 92, 851 01 Bratislava, pričom túto skutočnosť vopred bez zbytočného odkladu písomne oznámi zhotoviteľovi bez potreby písomného dodatku k tejto zmluve o dielo. 6

3.3. Ak to technické podmienky umožňujú, tak prednostne platí, že zhotoviteľ dodáva predmet zmluvy prostredníctvom vzdialeného prístup zabezpečeného sieťového VPN spojenia. Zhotoviteľ sa zaväzuje rešpektovať všetky bezpečnostné, organizačné a technické opatrenia a ďalšie relevantné predpisy objednávateľa spojené s prácou v priestoroch objednávateľa i so vzdialeným prístupom k informačným technológiám a sieti objednávateľa podľa článku V Prílohy č. 1: Všeobecné podmienky k zmluve o dielo ako aj v zmysle platných predpisov a štandardov objednávateľa, ktoré zhotoviteľovi zabezpečí oprávnená osoba objednávateľa počas celej doby trvania podpory prevádzky dodaného informačného systému 6

3.4. Zhotoviteľ sa zaväzuje vytvoriť a dodať Dielo do 36 mesiacov odo dňa nadobudnutia účinnosti tejto zmluvy o dielo. Deň dodania Diela sa považuje deň podpisu Záverečného akceptačného protokolu. 6

3.5. Zhotoviteľ sa zaväzuje dodať jednotlivé čiastkové plnenia na základe dohodnutého časového harmonogramu uvedeného v Prílohe č. 3 zmluvy o dielo. 6

3.6. Zhotoviteľ sa zaväzuje poskytovať servisné služby podľa zmluvy o dielo odo dňa dodania 1. čiastkového plnenia do dňa dodania Diela. 6

3.7. Ak prípadné omeškanie objednávateľa s poskytnutím súčinnosti, ktorú je povinný poskytnúť zhotoviteľovi má alebo preukázateľne bude mať vplyv na dodržanie časového harmonogramu, tzn. ak sa jedná o neposkytnutie takej súčinnosti, ktorá je nevyhnutná pre včasné vykonanie Diela, zhotoviteľ nie je v omeškaní so zhotovením Diela a lehota na vykonanie jednotlivých čiastkových plnení sa po písomnom schválení Riadiacou radou predĺži o čas omeškania objednávateľa s poskytnutím súčinnosti. To však platí len za predpokladu, že najneskôr druhý pracovný deň po vzniku omeškania objednávateľa zhotoviteľ písomne upozornil oprávnenú osobu objednávateľa na konkrétne vymedzenú povinnosť súčinnosti, s ktorou je objednávateľ v omeškaní, a toto upozornenie pravidelne písomne obnovoval najmenej jedenkrát za 5 dní až do dosiahnutia nápravy. Pokiaľ tento postup nebude dodržaný a Riadiaca rada neschváli predĺženie času, lehoty na vykonanie jednotlivých čiastkových plnení, lehota na vykonanie Diela sa nebude predlžovať. Pre zamedzenie pochybností sa stanovuje, že lehotu na vytvorenie a dodanie Diela ako celku je možné predĺžiť iba na základe písomného dodatku k tejto zmluve o dielo uzatvoreného v súlade s § 18 zákona o verejnom obstarávaní. 6

Článok IV 6

Cena a platobné podmienky 6

4.1. Zmluvné strany sa dohodli na určení maximálnej ceny za predmet tejto zmluvy o dielo v celkovej sume: 6

<uchádzač vyplní cenu uvedenú v Tabuľke č. 4 „Celková cena predmetu zmluvy“ v Prílohe č.4 - Špecifikácia ceny tejto zmluvy o dielo> eur bez DPH 6

(slovom: <vyplní uchádzač> eur bez DPH), pričom 6

<uchádzač vyplní cenu uvedenú v Tabuľke č. 1„Celková cena Diela“ v Prílohe č.4 - Špecifikácia ceny tejto zmluvy o dielo> eur bez DPH 7

(slovom: <vyplní uchádzač> eur bez DPH), 7

<uchádzač vyplní cenu uvedenú v Tabuľke č. 2 + Tabuľke č. 3 „Celková cena ďalších licencií“ v Prílohe č.4 - Špecifikácia ceny tejto zmluvy o dielo> eur bez DPH 7

(slovom: <vyplní uchádzač> eur bez DPH). 7

4.2. Maximálna celková ceny predmetu tejto zmluvy o dielo zahŕňa akékoľvek a všetky náklady na vykonanie, dodanie, poskytnutie predmetu zmluvy. 8

4.3. Ceny za predmet zmluvy uvedené v prílohe č. 4 tejto zmluvy o dielo sú stanovené dohodou zmluvných strán v súlade so zákonom NR SR č. 18/1996 Z. z. o cenách v znení neskorších predpisov a vyhlášky Ministerstva financií SR č. 87/1996 Z. z. v znení neskorších predpisov, ktorou sa vykonáva zákon NR SR č. 18/1996 Z. z. o cenách v znení neskorších predpisov. Ceny za predmet zmluvy sú pevne stanovené. 8

4.4. Zmluvné strany sa dohodli, že celková cena predmetu zmluvy je tvorená súčtom cien v detailnom rozpočte stanovenom v Prílohe č. 4 tejto zmluvy o dielo pre jednotlivé časti Diela (čiastkové plnenia) a ceny za ďalšie licencie. Cena za dodanie čiastkového plnenia (jednotlivé fázy) v sebe zahŕňa poskytovanie servisných služieb pre čiastkové plnenie. 8

4.5. Celková cena predmetu zmluvy predstavuje odplatu za splnenie všetkých zmluvných záväzkov zhotoviteľa vyplývajúcich z tejto zmluvy o dielo a zahŕňa všetky náklady a výdavky zhotoviteľa na riadne a včasné zhotovenie Diela, resp. jeho jednotlivých častí (čiastkových plnení) podľa tejto zmluvy o dielo, cenu za udelenie licencie k Dielu podľa článku X zmluvy o dielo a poskytovanie servisných služieb k čiastkovému plneniu, cenu za licencie 3. strán a celkovú cenu za ďalšie licencie. 8

4.6. Zhotoviteľ je oprávnený fakturovať cenu v podľa bodu 4.1 zmluvy o dielo, okrem ceny za ďalšie licencie, zodpovedajúcu prevzatej časti Diela (čiastkovému plneniu) v platobných míľnikoch podľa Prílohy č. 3 tejto zmluvy o dielo. Zmluvné strany sa dohodli, že zhotoviteľ vystaví objednávateľovi faktúru za prevzaté časti Diela (čiastkové plnenia) po: 8

a) ukončení procesu akceptácie odovzdávanej časti Diela (čiastkového plnenia) v zmysle článku V tejto zmluvy o dielo, 8

b) podpísaní príslušného Akceptačného protokolu, a  8

c) schválení výkazov prác k prevzatej časti Diela (čiastkovému plneniu). 8

4.7. Prílohou k faktúre je: 8

a) podpísaný Akceptačný protokol, pričom môže ísť aj o Akceptačný protokol s výhradou, vzťahujúci sa k fakturovanej časti Diela (čiastkovému plneniu), a 8

b) schválené výkazy práce vzťahujúce sa k fakturovanej časti Diela (čiastkovému plneniu). 8

4.8. Zhotoviteľ je oprávnený fakturovať cenu za ďalšie licencie po ich dodaní a potvrdení ich dodania objednávateľom prostredníctvom písomného protokolu. Poskytovateľ sa zaväzuje vystaviť príslušné faktúry za dodanie ďalších licencií do 14 dní od ich riadneho dodania. Xxxx za ďalšie licencie sa stanovuje podľa Xxxxxxx č. 2 a Tabuľky č. 3 Prílohy č. 4 – Špecifikácia ceny zmluvy o dielo. 8

4.9. Oprávnená osoba zhotoviteľa predkladá oprávnenej osobe objednávateľa pravidelne, na mesačnej báze, najneskôr do 10 (desiateho) kalendárneho dňa v mesiaci výkazy prác. Oprávnená osoba objednávateľa je povinná výkazy prác podľa predchádzajúcej vety následne schváliť alebo neschváliť v lehote do 5 (piatich) pracovných dní od ich predloženia zhotoviteľom. Ak oprávnená osoba objednávateľa bez oprávneného dôvodu neschváli výkaz prác podľa tohto bodu zmluvy o dielo alebo nezašle zhotoviteľovi žiadne výhrady k zaslanému výkazu prác do 5 (piatich) pracovných dní od jeho predloženia, považuje sa tento výkaz prác za schválený. Pri uplatnení výhrad oprávnenou osobou objednávateľa začína plynúť nová lehota 5 (piatich) pracovných dní na schválenie alebo neschválenie výkazu prác odo dňa opätovného predloženia opraveného výkazu prác zhotoviteľom. 8

4.10. Výdavky vo faktúre musia byť rozdelené do jednotlivých položiek s jednotkovými cenami zaokrúhlenými na 2 (dve) desatinné miesta s jednoznačnou identifikáciou, ktorej položky rozpočtu podľa prílohy č. 4 tejto zmluvy o dielo sa predmetná fakturovaná čiastka týka. Ku každej faktúre musí byť priložený originál akceptačného protokolu podpísaného Zmluvnými stranami. 8

4.11. Zhotoviteľ je oprávnený fakturovať a  objednávateľ uhradí zhotoviteľovi dohodnutú celkovú cenu Diela uvedenú v bode 4.1. tohto článku zmluvy na základe faktúry nasledovne: 8

4.11.1. 16 % z celkovej ceny Diela, t.j. celkovej ceny za jednotlivú 1. fázu – čiastkové plnenie predmetu zmluvy uvedené v tabuľke č. 2 Prílohy č. 4 – Špecifikácia ceny po dodaní a po úspešnom ukončení akceptačného testovania v rámci jednotlivej fázy aktualizovaného dodaného informačného systému a po podpísaní Akceptačného protokolu. 8

4.11.2. 24 % z celkovej ceny Diela, t.j. celkovej ceny za jednotlivú 2. fázu – čiastkové plnenie predmetu zmluvy uvedené v tabuľke č. 2 Prílohy č. 4 – Špecifikácia ceny po dodaní a po úspešnom ukončení akceptačného testovania v rámci jednotlivej fázy aktualizovaného dodaného informačného systému a po podpísaní Akceptačného protokolu. 9

4.11.3. 29 % z celkovej ceny Diela, t.j. celkovej ceny za jednotlivú 3. fázu – čiastkové plnenie predmetu zmluvy uvedené v tabuľke č. 2 Prílohy č. 4 – Špecifikácia ceny po dodaní a po úspešnom ukončení akceptačného testovania v rámci jednotlivej fázy aktualizovaného dodaného informačného systému a po podpísaní Akceptačného protokolu. 9

4.11.4. 19 % z celkovej ceny Diela, t.j. celkovej ceny za jednotlivú 4. fázu – čiastkové plnenie predmetu zmluvy uvedené v tabuľke č. 2 Prílohy č. 4 – Špecifikácia ceny po dodaní a po úspešnom ukončení akceptačného testovania v rámci jednotlivej fázy aktualizovaného dodaného informačného systému a Akceptačného protokolu. 9

4.11.5. 12 % z celkovej ceny Diela t.j. celkovej ceny za jednotlivú 5. fázu – čiastkové plnenie predmetu zmluvy uvedené v tabuľke č. 2 Prílohy č. 4 – Špecifikácia ceny po dodaní a po úspešnom ukončení akceptačného testovania v rámci jednotlivej fázy aktualizovaného dodaného informačného systému a po podpísaní Záverečného akceptačného protokolu. 9

4.12. Ceny za predmet zmluvy sú uvedené bez DPH. Zhotoviteľ k dohodnutým cenám uplatní DPH podľa všeobecne záväzného právneho predpisu platného v čase fakturácie. (Text platí pre tuzemského zhotoviteľa, zahraničný zhotoviteľ text druhej vety odstráni). 9

4.13. Faktúry sú splatné do 30 dní odo dňa ich doručenia objednávateľovi. Úhrada faktúry sa bude realizovať bezhotovostným prevodom na účet zhotoviteľa. Za deň splnenia peňažného záväzku sa považuje deň odpísania dlžnej sumy z účtu objednávateľa v prospech zhotoviteľa. Za správne vyčíslenie výšky DPH zodpovedá v plnom rozsahu zhotoviteľ. 9

4.14. Zmluvné strany sa dohodli a výslovne súhlasia s tým, že zhotoviteľ bude zasielať len elektronické faktúry z e-mailovej adresy zhotoviteľa <vyplní uchádzač> na e-mailovú adresu objednávateľa xxxxxxx.xxx@xxx.xx vo formáte PDF. Zmluvné strany vyhlasujú, že majú výlučný prístup k uvedeným e-mailovým adresám. Zmluvné strany sú oprávnené zmeniť e-mailové adresy a to len písomne s uvedením novej e-mailovej adresy, pričom z dôvodu tejto zmeny nie je potrebné uzatvoriť dodatok k tejto zmluve o dielo. Zhotoviteľ nie je povinný podpísať elektronickú faktúru zaručeným elektronickým podpisom. Elektronická faktúra musí spĺňať všetky náležitosti faktúry podľa § 74 zákona č. 222/2004 Z. z. o dani z pridanej hodnoty v znení neskorších predpisov. 9

4.15. Zmluvné strany sú povinné bezodkladne písomne oznámiť druhej strane akúkoľvek zmenu, ktorá by mohla mať vplyv na doručovanie elektronických faktúr, najmä zmenu kontaktnej e-mailovej adresy. 9

4.16. V prípade, že faktúra nebude po vecnej a/alebo formálnej stránke správne vyhotovená, objednávateľ je oprávnený ju vrátiť zhotoviteľovi bez zaplatenia na doplnenie (prepracovanie), pričom nová lehota splatnosti faktúry začne plynúť dňom doručenia správne doplnenej (prepracovanej) faktúry objednávateľovi. 9

4.17. Zhotoviteľ sa zaväzuje, že uvedenú daň na faktúre odvedie správcovi dane v lehote ustanovenej v § 78 ods. 1 zákona č. 222/2004 Z. z. o dani z pridanej hodnoty v znení neskorších predpisov. Porušenie tejto daňovej povinnosti vyplývajúcej zo všeobecne záväzného právneho predpisu je podstatným porušením tejto zmluvy a oprávňuje objednávateľa na okamžité odstúpenie od tejto zmluvy. (Text platí pre zahraničného zhotoviteľa, tuzemský zhotoviteľ tento text aj s bodom odstráni) 9

4.18. Zhotoviteľ najneskôr do doby vyhotovenia prvej faktúry predloží objednávateľovi originál potvrdenia o mieste svojej daňovej rezidencie, alebo jeho úradne overenú fotokópiu. Počas trvania zmluvy zhotoviteľ predmetné potvrdenie predloží objednávateľovi na začiatku každého nového zdaňovacieho obdobia. Zhotoviteľ vyhlasuje a zaväzuje sa, že v prípade vzniku stálej prevádzkarne na území Slovenskej republiky počas trvania zmluvy bude o tejto skutočnosti objednávateľa bezodkladne písomne informovať. Zhotoviteľ čestne vyhlasuje, že je konečným príjemcom platieb uvedených v tejto zmluve. (Text platí pre tuzemského zhotoviteľa, zahraničný zhotoviteľ tento text aj s bodom odstráni). 9

Článok V 9

Odovzdanie a prevzatie Diela 9

5.1. Odovzdanie a prevzatie Diela alebo jeho časti sa uskutoční najneskôr v termínoch špecifikovaných v časovom harmonograme podľa Prílohy č. 3 tejto zmluvy o dielo. Výsledkom odovzdania čiastkového plnenia a dodania ďalších licencií predmetu zmluvy (napr. časť Diela) zhotoviteľom a jeho prevzatia objednávateľom je podpísanie akceptačného protokolu oprávnenými osobami zmluvných strán tejto zmluvy o dielo (ďalej ako „Akceptačný protokol“). Akceptačný protokol musí byť pred jeho podpisom schválený Riadiacou radou. Fungovanie a mandát Riadiacej rady je upravený v Prílohe č. 2 zmluvy o dielo. Akceptačný protokol obsahuje najmä: identifikačné údaje zmluvných strán, identifikáciu oprávnených osôb zmluvných strán, identifikáciu predmetu akceptácie (označenie produktu, kontrola kvality), informácie povinne uvedené v zápisnice o vykonaných akceptačných testoch. Vyjadrenie objednávateľa môže byť: 10

5.1.1. A/plná akceptácia (odovzdanie predmetu plnenia prebehlo bez výhrad a v plnom súlade požiadavkami objednávateľa a so zmluvou o dielo); 10

5.1.2. B/podmienečná akceptácia (odovzdanie predmetu plnenia prebehlo s výhradami, ktoré nebránia jeho prebratiu a používaniu, pričom objednávateľ súhlasí s úhradou predmetu plnenia, čo v prípade čiastkového plnenia znamená 0 závažných vád, 0 zásadných vád a maximálne 10 nepodstatných vád); 10

5.1.3. C/odmietnutie prevzatia predmetu plnenia objednávateľom. 10

5.2. Vlastnícke právo k Dielu alebo jeho časti prechádza na objednávateľa odovzdaním a prevzatím Diela alebo jeho časti, tzn. podpísaním Akceptačného protokolu/Záverečného akceptačného protokolu vzťahujúceho sa k odovzdávanej časti Diela oboma zmluvnými stranami, pričom platí, že vlastnícke právo k Dielu ako celku prechádza na objednávateľa podpísaním Záverečného akceptačného protokolu (finálna akceptácia) oboma zmluvnými stranami. 10

5.3. Objednávateľ neprevezme Dielo, ak vykazuje Dielo právne a/alebo faktické vady. Dielo má vady, ak je zhotovené v rozpore podmienkami stanovenými v tejto zmluve o dielo a/alebo v rozpore so všeobecne záväznými právnymi predpismi. 10

5.4. Prílohou Akceptačného protokolu je: 10

5.5. Akceptačný protokol sa vyhotovuje v 4 (štyroch) vyhotoveniach, z ktorých 2 (dve) vyhotovenia sa určené pre objednávateľa a 2 (dve) vyhotovenia sú určené pre zhotoviteľa. 11

5.6. Ak zhotoviteľ odovzdáva dodaný informačný systém alebo jeho časť, zmluvné strany vykonajú vo vzájomnej súčinnosti akceptačné testy. Akceptačné testy sa vykonajú v prostredí a na infraštruktúre objednávateľa a v oddelených testovacích prostrediach (t. j. bez možnosti ovplyvniť bežnú činnosť objednávateľa, mimo produkčných databáz), ak sa zmluvné strany vopred výslovne nedohodnú inak. Pre úspešné vykonanie akceptačných testov sa vyžaduje osobná prítomnosť oprávnených osôb zmluvných strán podľa článku VI tejto zmluvy o dielo alebo nimi preukázateľne splnomocnených osoba na ich zastúpenie; inak sa akceptačné testy nemôžu vykonať. Výsledky akceptačných testov sa zachytia v zápisnici podpísanej oprávnenými osobami zmluvných strán podľa tejto zmluvy o dielo. 11

5.7. Akceptačné testy dodaného informačného systému alebo jeho časti sa uskutočnia v súlade s časovým plánom akceptačných testov špecifikovaným v časovom harmonograme podľa Xxxxxxx č. 3 tejto zmluvy o dielo. Ak sa akceptačné testy uskutočnia v inom termíne, ako sú plánované podľa časového harmonogramu, zmluvné strany sa na novom termíne dohodnú písomne. Zhotoviteľ písomne informuje objednávateľa o návrhu nového termínu akceptačných testov najmenej 5 (päť) pracovných dní pred ich pôvodným termínom uskutočnenia. Ak akceptačné testy prebehli úspešne v zmysle bodu 5.11. tohto článku zmluvy o dielo, časové obdobie medzi úspešnými akceptačnými testami a odovzdaním a prevzatím dodaného informačného systému alebo jeho časti potvrdeným podpisom Akceptačného protokolu nepresiahne 30 (slovom: tridsať) kalendárnych dní. 11

5.8. Ak pri zhotovení dodaného informačného systému dôjde k zhotoveniu databázy v súlade s § 135 Autorského zákona, uvedie sa táto skutočnosť v príslušnom Akceptačnom protokole. V tomto prípade bude súčasťou akceptačných testov, ktorých vykonanie predchádza vyhotoveniu Akceptačného protokolu, detailná špecifikácia databázy tvoriacej súčasť dodaného informačného systému alebo jeho časti. 11

5.9. Ak dodaný informačný systém alebo jeho časť nespĺňa akceptačné kritériá podľa tohto článku zmluvy o dielo, objednávateľ uvedie a popíše všetky identifikované právne a/alebo faktické vady dodaného informačného systému (ďalej len „vady dodaného informačného systému“) v zápisnici o akceptačných testoch a navrhne nový termín pre vykonanie akceptačných testov. Zhotoviteľ sa zaväzuje odstrániť vady dodaného informačného systému uvedené v zápisnici o akceptačných testoch v zmysle tohto článku zmluvy o dielo a opätovne uskutočniť nevyhnutné akceptačné testy, a to aj opakovane maximálne však 5 (päť) krát vo vzťahu ku každej odovzdávanej časti dodaného informačného systému. Ak napriek opakovaným akceptačným testom nebude dodaný informačný systém alebo jeho časť bez vád, t. j. nebudú splnené všetky kritériá akceptácie podľa bodu 5.11. tohto článku zmluvy o dielo uvedené sa považuje za podstatné porušenie povinnosti podľa tejto zmluvy o dielo.. 11

5.10. Zmluvné strany sa zaväzujú dodržiavať časový plán akceptačných testov a pri výskyte vád dodaného informačného systému vynaložiť nevyhnutné úsilie na jeho dodržanie. Vady dodaného informačného systému, ktoré sa vyskytnú pri akceptačných testoch, budú klasifikované podľa ich závažnosti špecifikovanej v prílohe č. 8 tejto zmluvy o dielo. Zápisnica o akceptačných testoch musí obsahovať správu o priebehu akceptačného testu a klasifikáciu zistených vád dodaného informačného systému podľa stupňa ich závažnosti špecifikovaných v Prílohe č. 8 tejto zmluvy o dielo. 11

5.11. Zmluvné strany sa dohodli, že akceptačné testy prebehli úspešne a akceptačné kritériá sú splnené, t. j. dodaný informačný systém alebo jeho časť je bez vád, ak neobsahuje žiadny závažný nedostatok (finálna akceptácia), žiadny zásadný nedostatok a obsahuje maximálne 10 (desať) nepodstatných vád (podmienečná akceptácia),  opakovanie akceptačných testov nie je potrebné, zhotoviteľ je však naďalej povinný v lehotách podľa tohto článku zmluvy o dielo odstrániť na vlastné náklady všetky vady dodaného informačného systému alebo jeho časti podľa príslušnej zápisnice o akceptačných testoch. 11

5.12. Zhotoviteľ sa zaväzuje odstrániť všetky vady dodávaného informačného systému uvedené v zápisnici o akceptačných testoch v nej uvedenej lehote. Ak zápisnica o akceptačných testoch neobsahuje lehotu na odstránenie vady dodávaného informačného systému, zhotoviteľ je povinný odstrániť vady úrovne B do 5 (piatich) pracovných dní od podpísania zápisnice o akceptačnom teste a vady úrovne C do 10 (desiatich) pracovných dní od podpísania zápisnice o akceptačnom teste. 11

5.13. Ak sa zmluvné strany nedohodnú inak, zhotoviteľ je povinný odovzdať objednávateľovi dokumentáciu k Dielu alebo jeho časti na elektronickom zariadení/nosiči dát (USB prenosné zariadenie) alebo na inom vhodnom, dohodnutom nosiči dát a v prípade potreby a požiadavky objednávateľa aj v jednom vyhotovení v písomnej forme pri podpise Akceptačného protokolu. Dokumentácia, ktorá je súčasťou Diela, bude akceptovaná nasledovne: 12

5.13.1. technickú dokumentáciu v slovenskom jazyku, ktorá bude obsahovať: postup skompilovania aplikácie, dátový model Informačného systému, popis integračnej, aplikačnej a technickej architektúry, väzby na iné systémy, popis tokov dát, procesné modely elektronických služieb, 12

5.13.2. prevádzkovú dokumentáciu v slovenskom jazyku, ktorá bude obsahovať: inštalačný postup aplikácie, konfiguráciu systémového SW, serverov a pracovných staníc, chybové stavy a postup ich riešenia, popis mechanizmu riadenia prístupu užívateľov k dátam a k funkciám aplikácie, popis procedúr pre zálohovanie a obnovu dát, popis použitých a navrhovaných technických číselníkov, ich naplnenie pri inicializácii. 12

5.13.3. užívateľskú dokumentáciu v slovenskom jazyku v písomnej forme v počte 2 (dvoch) kusov, ktorá bude obsahovať: popis počítačového programu a jeho funkcií, postupy a úkony potrebné pre riadne užívanie počítačového programu, chybové a neštandardné stavy a dostupné spôsoby ich riešenia. 12

5.14. Objednávateľ je oprávnený zaslať pripomienky k dokumentácii k Dielu v dohodnutom formáte v lehote do 10 (desiatich) pracovných dní odo dňa jej odovzdania objednávateľovi, 12

5.15. Zhotoviteľ je povinný pripomienky odborne posúdiť a upraviť dokumentáciu podľa vznesených pripomienok, ktoré nerozširujú predmet Diela, najneskôr do 7 (siedmich) pracovných dní od zaslania pripomienok objednávateľa podľa bodu 5.13.. Ak nie je možné niektorú z pripomienok objednávateľa akceptovať, zhotoviteľ túto skutočnosť bezodkladne oznámi a písomne vysvetlí Objednávateľovi v lehote podľa predchádzajúcej vety, 12

5.16. Objednávateľ je povinný do 5 (piatich) pracovných dní od dodania prepracovanej dokumentácie podľa bodu 5.14. preveriť spôsob zapracovania pripomienok a v prípade nesúhlasu v uvedenej lehote zaslať svoje stanovisko zhotoviteľovi, pričom Akceptačný protokol nemôže byť podpísaný. 12

5.17. Márne uplynutie ktorejkoľvek z lehôt v zmysle bodu 5.13. a 5.14. tejto zmluvy o dielo spôsobené nekonaním zmluvnej strany je omeškaním druhej zmluvnej strany. 12

5.18. Vytvorené zdrojové kódy spôsobom ako je dohodnuté v článku IX tejto zmluvy o dielo, 12

5.19. Ak došlo k odovzdaniu a prevzatiu Diela a zároveň zhotoviteľ odstránil všetky vady dodaného informačného systému, zmluvné strany vyhotovia záverečný akceptačný protokol (ďalej len „Záverečný akceptačný protokol“) s tým, že jeho prílohou je konečná správa o plnení Diela. Záverečný akceptačný protokol musí byť pred jeho podpisom písomne schválený Riadiacou radou projektu. Podpísaním Záverečného akceptačného protokolu oprávnenými osobami zmluvných strán podľa článku VI tejto zmluvy o dielo sa považuje Xxxxx za riadne zhotovené a odovzdané zhotoviteľom a prevzaté objednávateľom. 12

5.20. Záverečný akceptačný protokol sa vyhotovuje v 4 (štyroch) vyhotoveniach, z ktorých 2 (dve) vyhotovenia sú určené pre objednávateľa a 2 (dve) vyhotovenia sú určené pre zhotoviteľa. 12

Článok VI 12

Oprávnené osoby a  12

komunikácia zmluvných strán 12

Článok VII 14

Zodpovednosť za vady, záruka a odstraňovanie vád 14

dodaného informačného systému počas záruky 14

Článok VIII 15

Kľúčový experti 15

Článok IX 16

Zdrojový kód dodaného informačného systému 16

Článok X 17

Práva duševného vlastníctva 17

Článok XI 19

Vyhlásenia zmluvných strán 19

Článok XII 20

Všeobecné práva a povinnosti zmluvných strán 20

Článok XIII 22

Súčinnosť zhotoviteľa 22

Článok XIV 22

Ochrana zamestnancov zhotoviteľa a subdodávateľov 22

Článok XV 23

Osobitné záväzky zhotoviteľa 23

Článok XVI 24

Xxxxx Xxxxx, zmeny zmluvy o dielo 24

Článok XVII 24

Zmluvné pokuty 24

Článok XVIII 26

Zodpovednosť za škodu a náhrada škody 26

Článok XIX 27

Záverečné ustanovenia 27

Príloha č. 1 1

Všeobecné podmienky k zmluve o dielo 1

Článok I 2

Zodpovednosť za vady, záruka a odstraňovanie vád 2

Článok II 2

Vzdialený prístup 2

Článok III 5

Informačná bezpečnosť 5

Článok IV 6

Ochrana dôverných informácií 6

Článok V 8

Subdodávatelia, register partnerov verejného sektora a iné povinnosti zhotoviteľa 8

Článok VI 10

Zmluvné pokuty 10

Článok VII 11

Zodpovednosť za škodu 11

Článok VIII 11

Ukončenie zmluvy o dielo 11

Článok IX 13

Záverečné ustanovenia 13

Príloha č. 2: Požiadavky na predmet zmluvy 14

Referencie 31

Zoznam použitých skratiek a pojmov 31

Používané skratky odborov NBS 32

Predmet verejného obstarávania 33

Úvod 33

Rozsah dodávky 33

Realizácia riešenia NBS DWH 35

Opis predmetu zákazky 36

Východisková situácia 36

Procesy a systémy pre spracovanie dát 36

Súčasná architektúra aplikačnej vrstvy práce s dátami 41

Pilot DWH 49

Technické požiadavky 54

Úvod 54

Požadovaná architektúra aplikačnej vrstvy práce s dátami 54

Logická architektúra 55

Fyzická architektúra 56

Aplikačná architektúra 61

Metodika vývoja 69

Relačná časť NBS DWH 72

DataLake časť NBS DWH 79

Informačná bezpečnosť 81

Iniciálny load 83

Migrácia dát z projektu Pilot DWH 83

Metodika fyzického vývoja a inštalácie na produkciu 83

Nástroje na podporu prevádzky 84

Nástroje pre Data Governance a riešenia Master Data Managamentu 98

Biznisové požiadavky 98

Zdrojové (vstupné) systémy 98

Reportingová oblasť 103

Výstupné dátové oblasti 107

Funkčné požiadavky 111

Požiadavky na organizáciu a výstupy projektu 112

Projektové riadenie 112

Prístup k projektu a RACI matica 113

Pravidlá pre riadenie komunikácie 114

Projektový plán 119

Požadované výstupy projektu 121

Akceptačné kritériá 128

Riziká projektu 128

Opis predmetu zákazky pre služby podpory prevádzky a rozvoja 130

Úvod 130

Požiadavky na služby aplikačnej podpory prevádzky NBS DWH 130

Zoznam činností vykonávaných v rámci Služieb podpory prevádzky 131

Parametre kvality poskytovanej služby podpory prevádzky 132

Požiadavky na služby rozvoja systému 132

Požiadavky na realizáciu zmien na základe požiadaviek verejného obstarávateľa 132

Parametre kvality poskytovanej služby rozvoja systému 132

Servisné služby čiastkového plnenia 133

Prílohy 134

A – Zdrojové systémy NBS DWH 134

B – DataMarty NBS DWH 134

C – Metodika k predpisu NBS č.20/2020 o projektovom riadení 134

D – RACI matica 134

E – Projektový plán 134

F - Zmluva o prevádzke, údržbe a rozvoji systému 134

G -Špecifikácia Servisných služieb čiastočného plnenia 135

Príloha č. 3: Harmonogram fakturačných míľnikov 135

Príloha č. 4: Špecifikácia ceny 137

Príloha č. 5: 140

Zoznam osôb zhotoviteľa určených na plnenie zmluvy 140

Zoznam osôb zhotoviteľa určených na plnenie zmluvy a subdodávateľov zhotoviteľa 145

Zoznam subdodávateľov zhotoviteľa 145

Príloha č. 6 k zmluve o dielo 146

Slovník pojmov 146

Príloha č. 7 Zoznam použitých SW a SW 3. strán 154

Príloha č. 8 155

Klasifikácia vád dodaného informačného systému, lehoty na ich odstránenie 155

Zásadná vada (A) 156

Reakčná doba 156

do 4 pracovných hodín 156

Doba neutralizácie vady 156

do 8 pracovných hodín 156

Doba trvalého vyriešenia 156

do 2 pracovných dní 156

Závažná vada (B) 156

Reakčná doba 156

do 4 pracovných hodín 156

Doba neutralizácie vady 156

do 8 pracovných hodín 156

Doba trvalého vyriešenia 156

do 5 pracovných dní 156

Nepodstatná vada (C) 156

Reakčná doba 156

do 3 pracovných dní 156

Doba neutralizácie vady 156

do 6 pracovných dní 156

Doba trvalého vyriešenia 156

do 10 pracovných dní 156

Referencie

Zoznam použitých skratiek a pojmov

Skratka / Pojem	Vysvetlenie
API	Aplikačný interface
BI	Business intelligence. Skratka a teminus technikus zväčša používaný pre definovanie rámca reportingu a analytických nástrojov.
DL = Data Lake	Časť NBS DWH založená na BigData technológiách pre spracovanie neštruktúrovaných dát
DWH	Dátový sklad
ETL	Extraction – Transformation – Load, proces spracovania a transformácie dát do DHW
HW	Hardware-Hardvér
NBS	Národná banka Slovenska
NBS DWH	Celobankový Ddátový sklad NBS. Pozostáva z dvoch častí: 1.Relačnej časti 2. DataLake
ODI	Oracle Data Integrátor
OUT	Výstupná vrstva relačnej časti NBS DWH
PL	Prezentačná vrstva relačnej časti NBS DWH
RBÚZ	Register bankových úverov a záruk
RS	Register subjektov
SW	Software-Softvér
ŠZP	Štatistický zberový portál
TL	Transakčná vrstva relačnej časti NBS DWH
UID	Jedinečný prístupový identifikátor/užívateľské meno
VO	Verejné obstarávanie
Pilot DWH	Pilotný projekt DWH

Tabuľka 1: Zoznam použitých skratiek a pojmov

Používané skratky odborov NBS

Skratka odboru	Názov odboru
OBO	Odbor bankových obchodov
ODB	Odbor dohľadu nad bankovníctvom
ODK	Odbor dohľadu nad kapitálovým trhom
OEM	Odbor ekonomických a menových analýz
OFI	Odbor finančných technológií a inovácií
OFR	Odbor finančného riadenia
OFS	Úsek dohľadu a ochrany finančného spotrebiteľa
OIA	Odbor interného auditu
OIT	Odbor informačných technológií
OPD	Odbor dohľadu nad poisťovníctvom a dôchodkovým sporením
OPH	Odbor riadenia peňažnej hotovosti
OPM	Odbor finančnej stability
OPS	Odbor platobných systémov
ORR	Odbor riadenia rizika
OST	Odbor štatistiky
OVM	Odbor výskumu
OVO	Odbor vysporiadania bankových obchodov

Tabuľka 2: Skratky odborov

Predmet verejného obstarávania

Úvod

Predmetom verejného obstarávania je výber uchádzača, ktorý v súčinnosti s verejnýcm obstarávateľaom (ďalej aj ako „NBS“) dodá riešenie centrálneho celobankového dátového skladu (ďalej aj ako „NBS DWH“). Riešenie novej dátovej integrácie je navrhnuté ako jeden dátový ekosystém v kombinácii dvoch platforiem:

• DataLake

• Relačná časť

Uchádzač musí vyvinúť/dodať nové komponenty dátového skladu, ktoré budú:

• Integrovať dáta z existujúcich informačných systémov NBS a z externých systémov

• Poskytovať operatívny reporting, meranie výkonnosti a podporu analytických procesov nad dátami pre potreby jednotlivých organizačných zložiek spoločnosti.

• Podporovať prevádzku systému

• Umožnia samostatný rozvoj NBS DWH pracovníkmi IT a ďalších organizačných zložiek spoločnosti

Ďalej musí uchádzač v maximálnej miere vyžiť výsledky projektu Pilot DWH, ktorý mal za úlohu otestovať možnosti niektorých technológií. Časti projektu Pilot DWH, ktoré je nutné prepoužiť sú:

• Technickú infraštruktúru – Oracle DB, MS SQL/TOLAP a PowerBI

• Know-how pri extrakcii dát zo ŠZP a RBUZ

• Oracle Data Integrator ako ETL nástroj pre NBS DWH ako výsledok interného výberu.

Rozsah dodávky

Súčasťou dodávky uchádzača je splnenie a dodávka nasledovných úloh:

1. Vypracovať detailnú analýzu požiadaviek

2. Vypracovať návrh dátového modelu na základe detailnej analýzy biznisových požiadaviek

3. Dodať riešenie, ktoré bude v prípade spracovania osobných údajov pokrývať celý životný cyklus administrácie osobných údajov od evidencie až po ich likvidáciu (vrátane vymazania osobných údajov na základe žiadosti dotknutej osoby).

4. Realizácia integrácie na zdrojové systémy, vrátane pravidelného nahrávania dát do dátového skladu (kap. 3.3.1)

5. Vypracovať návrh kapacitného plánu

6. Dodať odporučenia konfigurácie DataLake a dodávka všetkých potrebných licencií tejto časti.

7. Inštalácia SW zabezpečenia (DataLake časť DWH, Frameworky, ETL nástroja).

8. Prevádzka a podpora SW zabezpečenia (DataLake časť DWH, Frameworky) počas trvania projektu.

9. Vypracovať návrh a implemenovať nové Knowledge Xxxxxxx ODI

10. Implementovať dátový model a dodať inštalačné scripty

11. Implementovať ETL úlohy a dodať inštalačné nastavenia

12. Implementovať reporty a analýzy (kap. 3.3.2)

13. Implementovať OUT objekty a transformácie dát do požadovaného formátu pre koncového odberateľa (kap. 3.3.3)

14. Dodať nastavenia BI nástroja

15. Dodať nasledovné frameworky a nastavanie metadát týchto frameworkov:

    • pre podporu správu, riadenie a monitoring aktualizačných úloh

    • pre správu číselníkov, mostíkov, referenčných dát,  hierarchií jednotlivých dimenzií a manuálnych vstupov

    • pre nahrávanie veľkého počtu a rôznych súborov

    • pre správu, automatické spúšťanie a vyhodnocovanie dátovej kvality

    • pre správu prístupov (riadenie bezpečnosti) k dátam

    • pre správu dokumentácie k DWH a iných metadát (o modeli, o reportoch, mapovaní zdroj-cieľ) pre správu riadenia dátovej retencie

16. Poskytnúť projektové riadenie zastrešujúce dodávku dátového skladu

17. Vytvoriť a odovzdať technickú dokumentáciu implementovaného riešenia (kap. 3.4.6)

18. Zaškoliť obsluhu a používateľov DWH (kap. 3.4.6)

19. Poskytnúť súčinnosť pri inštalácii a prevádzke neprodukčných prostredí DEV a TEST dodávaného informačného systému

20. Poskytnúť súčinnosť pre podporu produkčného prostredia PROD informačného systému dátový sklad (súčasťou dodávky uchádzača je aj prevádzkový manuál) - (kap. 4.2 a 4.3)

21. Poskytnúť súčinnosť pri inštalácii riešenia na PROD prostredia (relačná časť, DataLake časť, aplikačné servery). Pod pojmom poskytnúť súčinnosť sa pre účely tejto zákazky myslí aj dodávka inštalačných materiálov pre NBS prostredie.

22. Dodať licencie pre SW špecifikáciu pracovnej stanice vývojára (rozšírenie oproti poskytnutým licenciám NBS)

23. Ďalšie podľa detailného popisu v kapitole 3.2 (technické požiadavky)

Súčasťou dodávky uchádzača NIE sú nasledovné časti:

1. Dodávka HW serverov – zabezpečí NBS v konfigurácií po dohode s vybratým uchádzačom.

2. Dodávka licencií produktov Oracle (DB, ODI) a Microsoft (DB, PoweBI). Zabezpečí NBS, alebo už existujú v NBS.

3. Inštaláciu databázy pre relačnú časť DWH zabezpečí NBS (ako DB, tak aj PowerBI)

4. Inštaláciu a prevádzku virtuálnych strojov s Linux OS zabezpečí NBS (pre DataLake časť DWH).

5. Inštaláciu a prevádzku virtuálneho stroja s Tomcat aplikačnom serverom zabezpečí NBS.

6. Dodávka licencií aplikácie pre Dátového modelovanie.

7. Inštalácia riešenia na PROD prostredia je kompetencii NBS na základe súčinnosti uchádzača.

Realizácia riešenia NBS DWH

Verejný obstarávateľ požaduje realizáciu riešenia NBS DWH do 36 mesiacov odo dňa nadobudnutia účinnosti zmluvy o dielo. Realizácia bude mať definované fázy dodávky s jednotlivými iteráciami (biznis výstup) s postupným pribúdaním funkcionality. Fázovanie dodávky je navrhnuté v kapitole 3.4, uchádzač je povinný toto fázovanie odborne pripomienkovať.

Opis predmetu zákazky

Táto kapitola opisuje celkový predmet zákazky a delí informácie do týchto častí:

• Východiská situácia – opis stavu prípravy a zberu dát pre štatistické účely v NBS

• Požiadavky na riešenie NBS DWH:

  • Technické požiadavky

    • Požiadavky na Relačnú časť a DataLake DWH

    • Požiadavky na podporné frameworky (podpora prevádzky a správy dát)

    • Bezpečnostné požiadavky

  • Biznisové požiadavky

    • Integrácie zdrojov

    • Interný reporting NBS

    • Výstupné oblasti NBS DWH pre tretie strany

  • Projektové požiadavky, x. x. xxxxxxxxxx na organizáciu a výstupy projektu

    • Projektový plán

    • Požadovaná dokumentácia a výstupy projektového manažmentu

Východisková situácia

Východiskový stav je ďalej popísaný z pohľadu procesov spracovania dát, hlavných systémov využívaných v NBS v súvislosti so spracovaním dát. Zvláštna pozornosť je venovaná popisu aktuálnej architektúry systémov a nástrojov používaných pre prácu s integrovanými dátami, ich reportingom a analýzou. Dôležitým faktorom pre budovanie cieľového riešenia je potom existujúce pilotné riešenie dátového skladu, ktorého niektoré komponenty sú k dispozícii pre ďalšie využitie.

Procesy a systémy pre spracovanie dát

NBS je pre výkon svojej činnosti v prevažujúcej miere závislá na množstve externých dát zbieraných od subjektov na finančnom a nefinančnom trhu a externých poskytovateľov ekonomických informácií, a to na mikroekonomickej úrovni (dáta o konkrétnych subjektoch a finančných inštrumentoch), ako aj makroekonomickej úrovni (makro dáta – agregované ukazovatele o ekonomickej situácii a trendoch v jednotlivých sektoroch trhu). Tieto dáta sú zbierané, analyzované, čiastočne sa odvodzujú nové dáta ako produkt makroekonomických prognóz a výskumov. Niektoré dáta sú ďalej zdieľané v rámci medzinárodných inštitúcií (najmä ESAs, v rámci Eurosystému alebo Jednotného mechanizmu dohľadu) alebo aj s verejnosťou. Menšia časť dát vzniká primárne v NBS ako produkt vlastných aktivít NBS, napr. registre o subjektoch na trhu v rámci dohľadu a ďalšie dáta v rámci obchodných procesov, riadenia peňažnej hotovosti alebo finančného riadenia spoločnosti. Preto ďalej popisujeme spracovanie dát v týchto oblastiach, ktoré majú osobitný prístup k spracovaniu dát:

• Produkcia štatistických dát

• Hlavné procesy produkujúce dáta

• Analytické procesy

• Podporné procesy

Produkcia štatistických dát

Zber dát pre štatistické spracovanie sa deje v NBS niekoľkými kanálmi:

1. Proces zberu a produkcie štatistických dát je v NBS riešený primárne v systéme ŠZP (Štatistický zberový portál), pričom je za tento proces zodpovedný predovšetkým Odbor štatistiky. Systém ŠZP je zákazkové riešenie od externého zhotoviteľa na mieru pre potreby NBS. Štatistické dáta sú však zbierané aj formou e-mailových príloh, systémom RBÚZ a RS, ktoré sú vyčlenené z pôsobnosti odboru štatistiky – viď ďalej.

2. ŠZP umožňuje definovanie používateľských, štandardných výstupov s exportom do CSV a XLSX pre ďalšie spracovanie (typicky pre zabezpečenie lokálnych požiadaviek) a automatizovanú výmenu niektorých dát s ESMA (XML štandard) a EBA/EIOPA (v štandarde XBRL).

3. Pre účely dohľadu nad finančným sprostredkovaním a finančným poradenstvom sa pre zber dát využíva aj systém RegFAP, ktorého vlastníkom je odbor ODK a je vyvíjaný na odbore OFI.

4. Zber dát pre niektoré agendy je však stále riešený aj manuálne cez e-mail a dáta v MS Excel.

5. Zber detailných dát pre AnaCredit a ich výmena s ECB sú riešené samostatným systémom RBUZ/RS (Register bankových úverov a záruk / Register subjektov). Tento systém bol vytvorený pre účely dohľadu, nie štatistiky, ale z povahy pravidelného spracovania dát od vykazujúcich subjektov sleduje rovnaký proces. Z pohľadu ECB je AnaCredit tiež štatistický systém, no v NBS nebol takto implementovaný.

Obrázok 1: Oblasť spracovania dát – Produkcia štatistických dát

Uvedené riešenia pre zber dát od vykazujúcich subjektov a ich ďalšie spracovanie však nezahŕňajú nástroje pre reporting, analýzy a systematickú distribúciu výstupov. Za týmto účelom vyvinul odbor štatistiky pre svoje vlastné potreby riešenie Xxxxxxx s analytickým nástrojom Qlik Sense, ktoré malo za cieľ suplovať neexistujúcu analytickú platformu (resp. DWH/BI).

Existujú používatelia, ktorí pristupujú k dátam priamo cez SQL, R resp. Python.

V NBS prebiehajú alebo sa plánujú tieto súvisiace aktivity:

• Moderná štatistika – konsolidácia agendy zberu dát na OST do systému ŠZP

• Upgrade ŠZP (vyššia flexibilita definovania štatistických výkazov a výstupov, zlepšenie výstupného rozhrania pre dátovú integráciu a ďalšie...)

• Zber detailných dát o úveroch fyzických osôb a vytvorenie riešenia pre register fyzických osôb

• ŠZP ESAs - presun časti funkcionality štatistického procesu zameraného na výkazy vo formáte XBRL zo ŠZP do nového dedikovaného systému ŠZP ESAs

Ďalšie procesy produkujúce dáta

Niektoré dáta vznikajú vnútri NBS pri výkone niektorých hlavných činností, ktoré nespadajú do oblasti produkcie štatistických dát, ako sú:

• Dohľad (zodpovednosť za vedenie rôznych registrov a údaje o individuálnych procesoch/konaniach so subjektmi)

• Bankové operácie (údaje o vykonaných obchodoch – systém IBFO/WSS)

• Xxxxxxxx xxxxxx (analytické systémy Riskhouse, Credit Manager a Risk Manager)

• Riadenie hotovosti (údaje o stave a obehu hotovosti – systém EZO)

• Platobné systémy (údaje o transakciách – systémy SIPS, Target2)

Pre každú agendu existuje špecializovaný informačný systém, ktorý poskytuje aj operatívne výstupy. V prípade využívania spoločných informačných systémov na úrovni Európskej únie (IMAS pre procesy dohľadu nad významnými bankami, Target2 – zúčtovanie veľkých platieb) sú k dispozícii súčasne aj analytické reporty a výstupy pre uspokojenie dátových potrieb relevantných odborov.

Obrázok 2: Oblasť spracovania dát – Hlavné procesy produkujúce dáta

Dáta jednotlivých odborov (hlavných procesných oblastí) sú spracúvané a využívané viac menej pre vlastné potreby každého príslušného odboru a sú zdieľané iba obmedzene. Výnimkou sú spolupracujúce odbory Bankových operácií a Riadenia rizika, ktoré majú vytvorený vlastný analytický systém Riskhouse, ktorý napĺňa požiadavky týchto odborov bez potreby ďalšej konsolidácie s inými systémami.

Napriek malému prieniku týchto dátových oblastí prináša neexistencia jednotnej integrovanej (resp. analytickej) platformy komplikácie užívateľom niektorých odborov v oblastiach:

• Manuálna a netransparentná príprava dát pre reporting (mimo existujúcich analytických platforiem)

• Chýbajúci nástroj pre tvorbu vlastných reportov a analýz

• Duplicitné spracovanie externých dát

• Neznalosť a nemožnosť analyzovať dáta v kontexte dát z iných odborov

• Chýbajúce prepojenie registrov a IDAS/ASDR s vykazovanými údajmi dohliadaných subjektov z oblasti štatistiky

Aktuálne strategické aktivity NBS v tejto oblasti sú:

• ASDR – Implementácia jednotného agendového systému pre dohľad a reguláciu (proces manažment dohľadu), ktorý má nahradiť IDAS

• DMS / ECM – Implementácia integrovaného systému pre správu dokumentov (DMS) a Enterprise Content Managementu

Analytické procesy

Osobitná skupina procesov z pohľadu spracovania dát sú:

• Finančná stabilita

• Menová politika

• Výskum

Tieto procesy sú konzumentom dát publikovaných z procesu štatistiky a ďalej množstva externých ekonomických dát a zdrojov, ktoré sú predmetom rôznych analýz, modelovaní a predikcií. V každom prípade sú tieto procesy životne závislé na integrovaných dátach a súčasne poskytujú nové dáta, respektíve obohacujú agregované štatistické dáta o odvodené ukazovatele a predikcie.

Obrázok 3: Oblasť spracovania dát – Analytické proces

Dnes sú činnosti príslušných útvarov závislé na manuálnej príprave dát cez MS Excel a štatistických nástrojoch.

Podporné činnosti

Medzi podporné činnosti sú v NBS radené procesy:

• účtovníctvo a finančné riadenie (SAP FINU/HRO + BW)

• hospodársko-prevádzkové činnosti a služby (SAP FINU/HRO + BW)

• interný audit

• legislatívno-právna agenda

• IT

• ochrana a bezpečnosť

• medzinárodné vzťahy

• komunikácia

• riadenie ľudských zdrojov

• agenda riadiacich orgánov

V rámci týchto procesov vzniká iba obmedzené množstvo údajov, ktoré prakticky nemajú využitie v hlavných procesoch NBS.

Obrázok 4: Oblasť spracovania dát – Podporné procesy

Aktuálne strategické aktivity NBS v tejto oblasti sú:

• Migrácia SAP FINU/HRO na technológiu S4HANA

Súčasná architektúra aplikačnej vrstvy práce s dátami

Nasledujúci obrázok znázorňuje relevantnú časť súčasnej architektúry aplikácií a systémov v NBS, pričom tieto sú zoskupené do logických skupín podľa účelu.

Obrázok 5: Aplikačná vrstva – súčasný stav

• Externé zdroje – zdroje dát a informácií využívané pri analýzach a reportingu. Vo väčšine prípadov sú dáta z týchto zdrojov získavané manuálne, prípadne dochádza k výmene dát cez zdieľané úložisko.

• Primárne systémy – aplikačné systémy a registre prevádzkované NBS pre podporu primárnych a podporných procesov a úloh. Ich dáta sú čiastočne integrované v rôznych lokálnych databázach (viď Integračná vrstva), resp. sú exportované do Excelov pre ďalší reporting a analýzy. Medzi zdrojové systémy z tohto pohľadu zahŕňame aj Makroekonomickú databázu, ktorá je iba zdieľaným úložiskom časových radov v MS Excel.

• Integračná vrstva – riešenia pre integráciu dát NBS, ktoré vznikli v priebehu histórie pre podporu individuálnych potrieb jednotlivých odborov NBS; zahŕňajú ETL procesy pre plnenie integrovanej dátovej základne a prípadné data xxxxx. V NBS sa využívajú databázové systémy Oracle (Pilot DWH, SAP BW) a Microsoft SQL Server (Apoštol databáza, Riskhouse, AŠI) + ETL systém MS Integration Services.

• Prezentačná / Analytická vrstva – obsahuje nástroje a služby Business Intelligence, ktoré sprostredkovávajú prístup k dátam pre koncových užívateľov (Qlik Sense v prípade Apoštol, MS Analysis Services Tabular Model pre Pilot DWH, resp. MS Reporting Services pre Riskhouse)

• Aplikačná vrstva BI – predstavuje koncové klientske nástroje pre prístup k integrovaným dátam

Externé zdroje

Rôzne odbory využívajú nasledujúce externé zdroje:

Štátna správa

Označenie	Názov	Komentár k používaným dátam
ŠÚ SR	Štatistický úrad SR	vybrané datasety podľa požiadaviek odborov xxxxx://xxxx.xxxxxxxxxx.xx/xxx/xxxx/xxxx-xx.xxxx
KaPor	Katastrálny portál
FR SR	Finančné riaditeľstvo SR	súbory údajov z daňových výkazov a z registrov daňových subjektov
Sociálna poisťovňa	Sociálna poisťovňa	v súčasnosti veľmi obmedzený prístup k dátam, vo vyjednávaní je dohodnutie prístupu k širším anonymizovaným dátam (počty zamestnancov vo firmách, mikrodáta o poistencoch a poberateľoch dávok)
Finančná správa	Dáta z Finančnej správy na základe zmluvy	mesačné agregáty, daňové priznania PO a FO k dani z príjmov – mikrodáta - ročné, daňové priznania DPH mikrodáta – mesačné a kvartálne
Register trestov	xxxxxx.xxx.xx
Štátna pokladnica		dáta o plnení verejných rozpočtov, ručne sťahované a integrované v AŠI databáze
Ardal	Agentúra pre riadenie dlhu a likvidity	Výmena údajov na základe zmluvy cez SFTP úložisko
Eurofondy	Systém ITMS 2014+	OEM využíva 1 dataset cez API prevolávané z Matlab a odkladané do lokálnej databázy
SILC	Survey of Income and Living Conditions	Dáta prieskumu o vývoji príjmov a životných podmienok domácností od ŠÚ SR – manuálny vstup
Vzorka podnikov	Zjednodušené finančné výkazy pre vzorku cca 5000 podnikov	CSV súbor posielaný zo ŠÚ SR cez SFTP
eKasa	Dáta o tržbách podnikov z Finančnej správy	Atomické anonymizované dáta; dnes prenos e-mailom
Počty sporiteľov	Štatistika MPSVaR o počtoch klientov a objeme príspevkov	za každú DSS polročne - manuálny vstup

Tabuľka 3: Prehľad externých zdrojov – štátna správa

Verejné registre

Označenie	Názov	Komentár k používaným dátam
RÚZ	Register účtovných závierok	1x/mesiac automatický download do RS
RPO	Register právnických osôb	primárny zdroj Registra subjektov (denná synchronizácia); využívané aj na jednotlivých odboroch
RO	Register organizácií	zdroj Registra subjektov
Gleif	GLEIF - Global Legal Entity Identifier Foundation	zdroj Registra subjektov
RPVS	Register partnerov verejného sektora	aktuálne využívané pri AML validáciách protistrán xxxxx://xxxx.xxx.xx/XxxxXxxx/xxxxxxx/xx/xxxxx
ŽR SR	Živnostenský register

Tabuľka 4: Prehľad externých zdrojov – verejné registre

EÚ

Označenie	Názov	Komentár k používaným dátam
ECB SDW	ECB Statistical Data Warehouse	všetky datasety kde figuruje krajina "SK"
KL	Kurzový lístok ECB
ESMA	European Securities and Market Authority	údaje zo systémov TREM, FIRDS, FITRS, EMIR a SFTR (XML ISO 200022) + shortselling, Registre ESMA (XML dáta) – veľké dáta, v súčasnosti prebieha problematické ručné spracovanie
CSDB	Centralised Securities Database - databáza cenných papierov	4x CSV export manuálne stiahnutý 1x/mesiac do Apoštol
Eurostat	Štatistický úrad EÚ	štatistiky na európskej úrovni, ktoré umožňujú porovnávanie medzi krajinami a regiónmi
SHSDB	Securities Holdings Statistics Database - databáza držby cenných papierov	dáta zo SHSDB 1x za mesiac stiahnuté ručne cez Lotus Notes a nahraté do Apoštolu
ECB/FIS

Tabuľka 5: Prehľad externých zdrojov – EÚ

Zdroje ekonomických informácií

Označenie	Názov	Komentár k používaným dátam
Bloomberg	Bloomberg	prístup cez Excel plug-in očakáva sa možnosť flexibilného rozširovania požiadaviek na preberanie údajov z Bloomberg (API)
Bisnode	Bisnode - poskytovateľ digitálnych obchodných informácií	závierky vo formáte CSV cez http; 1x/mesiac do platformy Apoštol; ďalej údaje o konkurzoch a iné podnikové mikrodáta
CRIBIS	CRIBIS - Register informácií o firmách, majetkové a personálne prepojenia
Reuters / Refinitiv	Najväčší poskytovateľ multimediálneho spravodajstva na svete	Používaný pre monitoring spravodajstva. nie sú k dispozícii konkrétne požiadavky na integráciu
Tradeweb	elektronické mimoburzové trhy na obchodovanie s produktmi s pevným výnosom, ETF a derivátmi
Macrobond	Integrátor finančných a ekonomických dát	Ad-hoc dáta pre potreby ekonomických analýz pre OEM
CRN	Ceny rezidenčných nehnuteľností	XLS, štruktúrované dáta, cca 100 záznamov, manuálne poskytované / kvartálne
United Classifieds	Spoločnosť poskytujúca online inzerciu (nehnuteľnosti)	Dáta o cenách nehnuteľností na sekundárnom trhu, štruktúrované dáta v CSV

Tabuľka 6: Prehľad externých zdrojov – zdroje ekonomických informácií

Primárne systémy

Hlavné interné systémy a dátové zdroje relevantné pre dátovú integráciu sú nasledujúce:

Označenie	Názov	Hlavná funkcia
ŠZP	Štatistický zberový portál	Centrálny systém pre výkazy a hlásenia od subjektov finančného trhu pre štatistické účely a výkon funkcie dohľadu - core systém pre povinné výkazníctvo, zber dát od cca 7000 subjektov
ŠZP ESAS (Fujitsu XBRL)	Štatistický zberový portál (European Supervisory Authorities)	Nový systém pre výkazníctvo subjektov vo formáte XBRL (EIOPA, EBA) – v súčasnosti riešené samostatným modulom ŠZP
RBÚZ	Register bankových úverov a záruk	Lokálna implementácia AnaCredit - zber údajov o bankových úveroch a zárukách – prepojený s Registrom subjektov a systémom AnaCredit
RS	Register subjektov	Master systém pre subjekty, ktorých úvery sú vykazované cez RBÚZ (právnické osoby a podnikatelia) – založený na dátach ŠÚSR, RPO, RO a ďalších zdrojoch
Subjekty 2.0	Subjekty 2.0	Systém pre správu statických údajov o subjektoch finančného trhu pre účely dohľadu
REGFAP	Register finančných agentov a finančných poradcov	Systém pre evidenciu dohliadaných subjektov a pre zber dát a hlásení o ich činnosti. Evidenčné informácie sa plánujú integrovať do Subjekty 2.0, zber dát do ŠZP
CERI	CERI - Centrálna evidencia regulovaných informácií	Databáza regulovaných informácií, ktorými sú emitenti cenných papierov - neštruktúrované informácie - prospekty k emisiám cenných papierov, oznámenia, výročné správy, pre reporting sa požadujú iba metadáta o dokumentoch pre štatistiky
Register OFV		Odborná spôsobilosť finančných agentov a poradcov - register osôb (cca 70.000 FO), ktoré absolvovali OFV alebo odbornú skúšku podľa zákona o finančnom sprostredkovaní
Skúšky		Databáza otázok na skúšky, cvičné testy, ich výsledky, termíny skúšok
SIPS	Platobný systém SIPS	Retailový platobný systém určený na spracovanie klientskych platieb prevádzkovaný NBS
SAP FINU/HRO	Finančné účtovníctvo, hospodárenie a rozpočet, platobný styk	Implementácia na báze SAP s kompletnou kustomizáciou pre NBS (moduly SAP ECC v6.0 - účtovné jadro, SAP BCA - Bank Customer Accounts modul pre správu klientskych účtov, SAP FI, CO, IM, MM, SD, PO)
IDAS	Agendový systém dohľadu	Lotus Notes aplikácia pre podporu agendy dohľadu ODK, OPD a ODB pre menej významné banky
ASDR	Agendový systém dohľadu a regulácie	Tiež označovaný ako ISD (Informačný systém dohľadu) - Systém vo vývoji
IBFO/WSS	Investičné bankovníctvo a finančné obchodovanie	Kustomizovaná implementácia Wall Street Suite (WSS) pre podporu obchodných procesov NBS – t. j. realizáciu a vysporiadanie obchodných operácií realizovaných na OBO a OVO, vrátane ich účtovania na OFR.
Makroek. DB	Makroekonomická databáza	Konsolidované dáta pre tvorbu modelov na oddelení makroekonomických analýz OEM - spoločné úložisko časových radov. Kópia sa publikuje na webe NBS pre verejný prístup.
Credit Manager		Aplikácie pre riadenie rizík na odbore ORR
Risk Manager
EZO	Euro zásoby a obeh	Funkcie pre správu emisií bankoviek a mincí, evidenciu stavu hotovosti v ekonomike a na účtoch NBS, peňažné toky medzi NBS a tretími stranami. Interný vývoj
HFCS	Zisťovanie o financiách a spotrebe domácností	Dáta prieskumu o vývoji životných podmienok domácností – manuálny vstup - cca 6000 domácností
BLS	Bank Lending Survey	Dotazník o vývoji ponuky a dopytu na trhu úverov – manuálny vstup

Tabuľka 7: Prehľad interných zdrojov – primárne systémy

V NBS sa využívajú tiež niektoré ďalšie systémy pre podporu primárnych procesov, ktoré ale neboli identifikované ako relevantné pre dátovú integráciu (v prílohe A NBS DWH - Systemy.xlsx v stĺpce H označené ako „N“):

• Target2-SK – lokálny komponent systému Target2 prevádzkovaného Eurosystémom na spracovanie veľkých platieb, externý Target2 poskytuje tiež reportingovú službu CRSS postačujúcu pre potreby OPS

• IMAS (SSM Information Management System) – spoločná európska procesná platforma pre podporu dohľadových procesov vo významných finančných inštitúciách

• IDRA (IMAS Data Reporting and Analytics) - reportingová služba nad dátami IMAS

Integračná vrstva

Rôzne odbory využívajú rôzne platformy pre spracovanie dát z rôznych zdrojov. Dlhodobým cieľom je migrácia reportingu na zjednotenú platformu DWH a DataLake.

Označenie	Názov
Apoštol databáza	Analytická platforma odboru štatistiky – predstavuje databázu integrovaných dát (MS SQL Server), kde hlavným zdrojovým systémom je ŠZP a k nemu sa nahrávajú najrôznejšie ďalšie registre a manuálne vstupy. Nad touto databázou je sprevádzkovaný in-memory BI nástroj Qlik Sense, v ktorom je tiež implementované množstvo integračnej a výpočtovej logiky.
Pilot DWH	Hlavným cieľom pilotného projektu DWH/BI bolo vybudovanie infraštruktúry DWH/BI (Oracle + MS Analysis Services + MS Power BI) a vytvorenie riešenia pre základné procesy spojené so spracovaním dát DWH a analytickými výstupmi v podobe BI riešenia. Projekt, ktorý začal v 03/2020, sa zameral na spracovanie vybraných dát zo systémov RBÚZ, RS a ŠZP. Projekt Pilot DWH vytvoril základ pre budúce riešenie, rešpektuje štandardné prístupy pre budovanie dátových skladov a môže byť využitý ako základ pre ďalší rozvoj DWH.
Riskhouse	Riskhouse predstavuje vlastný DWH systém odboru ORR (MS SQL Server), ktorého vývoj začal v roku 2012 a ktorý bol navrhnutý s klasickým prístupom a architektúrou pre budovanie dátových skladov na podporu procesov zverených odboru ORR. Hlavným zdrojom dát je systém IBFO/WSS, ktorý poskytuje iba slabú analytickú podporu. Predpokladá sa, že riešenie Riskhouse bude v strednodobom horizontu zachované, vzhľadom k tomu, že implementuje množstvo špecifickej biznisovej logiky pre účely riadenia rizík.
SAP BW	SAP Business Warehouse v 7.3 predstavuje komodizovaný dátový sklad (Oracle), ktorý je dodávaný ako samostatný modul balíka podnikových aplikácií SAP. V NBS je nasadený SAP BW najmä pre reportingové potreby OFR, pričom jeho kontrolingová časť je kustomizovaná pre vykazovanie podľa ESCB metodiky COMCO. V súvislosti s plánovaným prechodom na S4HANA bude treba zvážiť alternatívny prechod na BW4HANA, alebo pokrytie požiadaviek jednotným DWH systémom.
AŠI	Databáza (MS SQL Server) o subjektoch verejnej správy, vytvorená najmä ako dátová základňa pre analytické spracovanie údajov zo Štátnej pokladnice vnútri odboru OEM, oddelenia fiškálnych a štrukturálnych analýz. Databáza nebola koncipovaná ako DWH.
Makroek. databáza	Úložisko v MS Excel, v ktorom sú konsolidované dáta pre tvorbu modelov na oddelení makroekonomických analýz OEM. Databáza nebola koncipovaná ako DWH, ale spoločné úložisko časových radov. Pre prístup sa využívajú rôzne nástroje (Matlab, EViews, WinSolve, BEAR, R Studio, Python), pomocou ktorých sa aj generujú výstupy pre management a analytické správy. Databáza sa tiež kopíruje na web NBS pre prístup zo strany verejnosti.

Tabuľka 8: Prehľad integračných platforiem v NBS

Prezentačná / Analytická vrstva

Pre prístup k dátam v jednotlivých integračných platformách sa využívajú rôzne nástroje:

Prezentačná / Analytická vrstva	Integračná vrstva	Názov
Qlik Sense	Apoštol databáza	Qlik Sense je self-service BI systém s in-memory analytikou a schopnosťami stavať analytické riešenia nad rôznymi dátovými zdrojmi. Aj v rámci riešenia Apoštol sa silne využíva skriptovanie pre transformácie dát a dodatočné integrovanie externých a manuálnych vstupov. Prípravu analytických priestorov a dashboardov zabezpečuje odbor OST.
MS Analysis Services	DWH Pilot	Dáta z data martov pilotného DWH sú spracúvané do tabulárnych modelov na MS SQL Serveri (in-memory OLAP), ku ktorým sa pristupuje cez MS Power BI klienta. Spracovanie dát zabezpečuje OIT.
MS Reporting Services	Riskhouse	Prístup k dátam v integrovanej databáze Riskhouse je zabezpečený cez MS Reporting Services, ktoré sa využívajú pre operatívny reporting pre bežných užívateľov s obmedzenými možnosťami ďalšej manipulácie. Reporty pripravuje a dokumentuje odbor ORR, ktorý sa tiež stará o celé riešenie Riskhouse.

Tabuľka 9: Analytické vrstvy v NBS

Aplikačná vrstva BI

Koncové nástroje pre prístup k dátam, reportom a dashboardom boli zavedené v súvislosti s podkladovými analytickými systémami:

Prezentačná / Analytická vrstva	Integračná / Analytická vrstva	Názov
Browser (webový prehliadač)	Apoštol databáza / Qlik Sense	Analytické dashboardy sa otvárajú cez tenkého klienta (webový prehliadač)
MS Power BI (+ Power BI Report Server)	DWH Pilot / MS Analysis Services	Dáta tabulárnych modelov sú otvárané z klienta MS Power BI, vytvárané reporty sú publikované do MS Power BI Report Servera.
Browser (webový prehliadač)	Riskhouse / MS Reporting Services	Prístup k reportom publikovaným na MS Reporting Services cez webový prehliadač.
MS Excel (Business Explorer add-in)	SAP BW	Prístup k dátam je realizovaný cez Business Explorer (Excel plug-in), ktorý umožňuje získanie dát zo SAP BW do Excelu, ale bez možnosti ďalšieho formátovania výstupov a tvorby grafov. Tieto výstupy sa robia následne v MS Excel ručne.
Štatistické nástroje	AŠI	Pre prístup sa využívajú rôzne nástroje (Matlab, EViews, WinSolve, BEAR, R Studio, Python), pomocou ktorých sa aj generujú výstupy pre management a analytické správy (vo formáte pdf a MS Excel s tabuľkami a grafmi)
	Makroek. databáza

Tabuľka 10: Aplikačná vrstva BI v NBS

Pilot DWH

Hlavným cieľom projektu Pilot DWH bolo vybudovanie infraštruktúry DWH/BI, zadefinovanie pojmov a základného data governence. Hlavným cieľom bolo otestovanie rôznych technológií a ich vhodnosť pre prostredie NBS. V neposlednom rade išlo o vytvorenie riešenia pre základné procesy spojené so spracovaním dát DWH a analytickými výstupmi v podobe BI riešenia.

Projekt, ktorý začal v 03/2020, sa zameral na spracovanie vybraných dát zo systémov ŠZP, RBUZ a RS. V súčasnosti zahŕňa asi 5 % rozsahu dát NBS.

Logická architektúra Pilot DWH

Obrázok 6: DWH – Logická architektúra

Pre účely DWH bola zvolená 3-vrstvová architektúra, ktorá pozostáva zo Stage vrstvy (L0), Integračnej (L1) a Prezentačnej vrstvy (PL). L1 a PL sú modelované prístupom X. Xxxxxxx, pričom v L1 vrstve sú dáta perzistované a PL vrstva obsahuje dáta perzistované (oblasť ŠZP) ako aj pohľady nad L1 vrstvou.

V rámci PL vrstvy boli logicky vytvorené viaceré star schémy nad objektami L1 vrstvy. SSAS tabulárny model obsahuje objekty štrukturálne rovnaké ako sú objekty v PL vrstve a pomocou technického účtu si dáta preberá 1:1 z PL vrstvy. PL vrstva slúži aj pre zabezpečenie prístupov, či už riadkovú ako aj stĺpcovú.

Integrované dáta

Zdrojové systémy pre Pilot DWH sú:

• ŠZP (Štatistický zberový portál) - Centrálny systém pre výkazy a hlásenia od subjektov finančného trhu pre štatistické účely a výkon funkcie dohľadu - core systém pre povinné výkazníctvo, zber dát od cca 7000 subjektov. Z toho integrované časti sú:

  • Menová a finančná štatistika

  • Cenné papiere

  • Bilančná trieda

• RBÚZ (Register bankových úverov a záruk) – Lokálna implementácia AnaCredit – zber údajov o bankových úveroch a zárukách – prepojený s Registrom subjektov a systémom AnaCredit. Do DWH sa prenášajú:

  • Údaje nástroja

  • Údaje protistrana – nástroj

  • Údaje spoločných záväzkov

  • Celkom cca 50 % atribútov.

• RS (Register subjektov) - Master systém pre subjekty, ktorých úvery sú vykazované cez RBÚZ (právnické osoby a podnikatelia) – založený na dátach ŠÚSR, RPO, RO a ďalších zdrojoch. Do DWH sa preberajú všetky autoritatívne záznamy.

Tieto zdrojové systémy z pohľadu komplexnosti poskytnutých informácií celej NBS boli v projekte Pilot DWH integrované na cca 20 %.

Dátové oblasti L1 vrstvy

L1 vrstva obsahuje tieto star schémy

Zdroj	Star schéma	Obsah
RBUZ	Inštrument a finančné dáta	Statické a finančné údaje o inštrumentoch
RBUZ/RS	Subjekty	Agregované finančné údaje z RBUZ na úrovni subjektu vystupujúceho v roli debtor (dlžník), informácie o subjektoch.
ŠZP	Trieda MFŠ	Menová a finančná štatistika dohľadaných subjektov. Star schéma je organizovaná vo forme key-value, kde key atribút určuje významovosť hodnoty
ŠZP	Trieda bilancie	Bilančné výkazy dohľadaných subjektov. Star schéma je organizovaná vo forme key-value, kde key atribút určuje významovosť hodnoty
ŠZP	Trieda Cenné papiere	Výkazy cenných papierov dohľadaných subjektov. Star schéma je organizovaná vo forme key-value, kde key atribút určuje významovosť hodnoty
DWH (MFŠ, RBUZ/RS)	Konsolidovaný model MFŠ-RBÚZ	Konsolidácia údajov zo štatistickej triedy MFŠ a RBUZ/RS. Porovnanie nominálnej hodnoty vykázanej ako agregát v ŠZP a napočítaného údaju z granulárnych dát RBUZ/RS podľa BSI metodiky (ECB).
RBUZ/RS	Prepojenie subjektu a inštrumentu	Prepojenie inštrumentu na subjekt vystupujúci v konkretnej roli (debtor, creditor...), údaje spoločných záväzkov a nominálnej hodnoty napočítanej podľa BSI štatistiky (ECB).

Tabuľka 11: Star-schémy DWH – vrstvy L1

Technická architektúra Pilot DWH“

Obrázok 7: DWH – Technická architektúra

Ako základ pre DWH bola zvolená databáza od firmy Oracle. Pre BI riešenie bolo zvolené Microsoft SQL Server Analysis Services s reporting platformou Power BI.

V rámci DWH existujú 2 prostredia:

1. DEV používané ako na vývoj tak aj testovanie  

2. Samotné produkčné prostredie.

Každé prostredie má samostatnú databázu a samostatný HW.

Spracovanie zdrojových dát prebieha nasledujúcim spôsobom:

1. Dáta sa extrahujú cez databázovú linku Oracle->Oracle cez extrakčné pohľady, pričom z nich si berie full množinu dát.

2. Dáta sú prenesené do temporárnych tabuliek v DWH.

3. V L0 schéme sú však za daný deň uložené full snímky ako aj inkrementálne snímky, ktoré sú tvorené porovnaním 2 po sebe idúcich full snímkov. Tabuľky v L0 schéme sú organizované podľa zdrojového systému a samotného extrakčného pohľadu. Výnimku tvorí hlavná tabuľka výkazov ŠZP, ktorá obsahuje cez 1 mld záznamov. Z tejto tabuľky sú dáta ukladané do osobitných, štrukturálne rovnakých tabuliek podľa samotných tried. Nedochádza k transformácii dát zo zdrojových systémov.

4. Ako posledný krok beží vloženie všetkých chýbajúcich záznamov tak, aby inkrementálne snímky zachovali referenčnú integritu.

5. Integrácia dát do L1 vrstvy je zabezpečená pomocou PL/SQL procedúr, ktorých úlohou je:

• Vygenerovanie umelých kľúčov pre príslušnú tabuľku

• Transformovanie dát do perzistentných LD tabuliek, ktoré sú obrazom tabuliek L1.

• Historizácia dát z LD tabuliek do L1 v závislosti na typu tabuľky

Na spracovanie dát v rámci DWH (microscheduling) sa používa custom workflow nástroj vyvinutý zhotoviteľom pilotu.

Na spracovanie dát do tabulárnych modelov SSAS sa používa SQL Server Integration Services.

Dostupná dokumentácia k pilotnému DWH/BI

• Základné princípy DWH/BI - Teoretický materiál

• Funkčný návrh DWH/BI - Logický a funkčný návrh riešenia PL vrstvy, popisuje zvolenú metodiku modelovania podľa X.Xxxxxxxx, popis star schém (xxxxxxxxxx), fyzický návrh modelu PL vrstvy

• Architektúra DWH/BI - Návrh integrácie okolitých systémov, ETL architektúra a workflow manažment, BI a reporting

• Technické požiadavky na zabezpečenie DWH/BI - Popis HW a SW požiadaviek na zabezpečenie serverových komponentov DWH a BI, špecifikácia prostredí

• Menné konvencie

• Technické riešenie DWH - Detailný technický popis jednotlivých vrstiev DWH/BI, ETL objektov, logovaní a zabezpečenie DWH/BI

Reporting

Projekt Pilot DWH zaviedol BI infraštruktúru pre reporting postavenú na nástroji MS Power BI a MS Power BI Report Server.

HW špecifikácia Pilot DWH

HW komponent	Typ	Parametre
DB server	Výrobca/ verzia	Oracle 19c EE + Partitioning option
	Operačný systém	Oracle Linux 8 (RedHat)
	RAM (Typ, počet)	512GB, DB má dedikované SGA/PGA na úrovni 50GB/40GB
	CPU (Typ, počet)	1xCPU Xeon Gold 6244 (8 cores), 3,6 GHz; 1 slot ešte voľný
	Súčasná utilizácia CPU	v maxime 30%
	Veľkosť DB	2TB (dáta a indexy)
	Diskové pole (Typ HDD, počet, veľkosť)	14x 3TB SSD lokálne disky, zapojené do RAID6, cez PCI RAID radič, je možné zriadiť prístup aj na centrálne diskové pole 3PAR, lebo server má 2x 16 Gbit FC karty
	LAN na diskové pole (rýchlosť, počet)	-
	LAN do siete (rýchlosť, počet)	4x 10GBit
Reporting / BI server	Výrobca/ verzia	MS SQL Server 2019 Enterprise
	Operačný systém	Windows Server 2022 Data Center edícia.
	RAM	32 GB
	CPU	4 vCPU
	Diskové pole	3PAR
Aplikačný server	Výrobca/ verzia	Apache Tomcat/9.0.56
	Operačný systém	Red Hat Enterprise Linux 7.9
	RAM	10 GB
	CPU	6 vCPU, Intel(R) Xeon(R) Gold 6134 CPU @ 3.20GHz
	HDD	25 GB

Tabuľka 12: Pilot DWH – HW špecifikácia

Poznámka: na databázovom serveri nebeží len Pilot DWH databáza, ale ďalšie produkčné databázy NBS. Súčasné vyťaženie CPU je na úrovni 30 %. Pilot DWH obsahuje cca 2TB dát.

Technické požiadavky

Úvod

Táto kapitola obsahuje technické požiadavky na nový systém NBS DWH. Požiadavky sú rozdelené do jednotlivých oblastí ako:

1. Architektúra (logická, fyzická a aplikačná)

2. Popis vlastností jednotlivých komponentov na úrovni relačnej databázy a DataLake

3. Popis aplikačných vlastností podporných aplikácií DWH.

Rovnako sa táto kapitola zaoberá bezpečnostnými požiadavkami a požiadavkami na spustenie systému (iniciálny load).

Požadovaná architektúra aplikačnej vrstvy práce s dátami

Plánované zmeny zachytáva nasledujúci diagram, ktorý vychádza zo schválenej dátovej stratégie bankovou radou NBS v apríli 2022:

Obrázok 8: Aplikačná vrstva – budúci stav

Logická architektúra

Riešenie novej dátovej integrácie je navrhnuté ako jeden dátový ekosystém v kombinácii dvoch platforiem:

• DataLake

• Relačná časť, ktorý sa skladá z:

  • Oracle DB, ktorá rieši problematiku dát ako je atomicita, konzistencia, izolovanosť, trvanlivosť, či unikátnosť

  • MS SQL DB s in-memory T-OLAP podporou pre PowerBI reporting.

Každá z týchto platforiem nie je osobitnou aplikáciou, ale súborom technológií, nástrojov a na mieru naprogramovaných procesov a integrácií, ktoré vo svojom celku plnia úlohu dátovej integrácie a spracovania dát pre účely reportingu a pokročilých analýz. Z tohto dôvodu sú v ďalšom texte obe platformy ďalej dekomponované na jednotlivé dátové vrstvy, dátové toky, funkčné bloky a použité technológie.

Obrázok 9: Logická architektúra nového riešenia

Predmetom riešenia sú tieto komponenty architektúry:

• Relačná časť – Dátový sklad, jeho dátové vrstvy, dátové toky, metadátové nastavenia a podporné frameworky

• DL – DataLake, jeho dátové vrstvy, dátové toky, metadátové nastavenia a podporné frameworky

• Spoločné frameworky – aplikácie a nástroje, ktoré nie sú súčasťou samotných platforiem dátovej integrácie, ale využívajú sa pre celkové riadenie spracovania dát a podporu odborových používateľov.

Nasledujúce časti aplikačnej architektúry sú dotknuté týmto riešením:

• BI platformy – existujúce BI aplikácie, ktoré budú v rámci projektu pripojené na DWH a DataLake pre čítanie dát.

• Štatistický framework – existujúce portfólio štatistických nástrojov, pre ktoré budú zadefinované mechanizmy prístupu k DWH a DataLake

• Zdrojové systémy s priamym prístupom – reprezentuje všetky systémy, ktoré budú poskytovať priamy prístup ku svojím dátam, resp. cez vyhradené databázové rozhranie

• Externé systémy poskytujúce extrakty - reprezentuje všetky systémy, ktoré budú poskytovať extrakt svojich dát, ktorý bude vymieňaný s Data Landing zónou cez SFTP server alebo extranet Sharepoint.

• Zdrojové systémy poskytujúce služby - reprezentuje všetky systémy (interné aj externé), ktoré budú poskytovať svoje dáta prostredníctvom vystavenej služby (REST API, SOAP).

Fyzická architektúra

Verejný obstarávateľ požaduje aby, navrhnutý datawarehouse pozostával z rozširovateľných a otvorených komponentov. Všetky logické komponenty budú prevádzkované formou „On-Premise“ v dátových centrách NBS ako fyzické či virtuálne servery.

Fyzicky bude infraštruktúra rozvrhnutá nasledovne na 4 skupiny:

• Relačná časť

• DataLake

• Aplikačný server pre podporné aplikácie

• BI oblasť

Nasledujúca tabuľka obsahuje súpis HW požiadaviek.

Platforma	Uzly	Navrhované riešenie
Relačná časť	PROD-DB TEST-DB DEV-DB	NBS DWH bude nasadený na existujúcej infraštruktúre prevádzkovaný interným oddelením OIT na 2 samostatné servery v oddelených lokáciách s rovnakým výkonom v konfigurácii: Existujúce fyzické servery: CPU: 1x X86 CPU 8 cores s potencionálnym rozšírením o ďalší CPU RAM: 512 GB RAM s potencionálnym rozšírením na 1 TB SSD: 4x3,2TB v RAID s potencionálnym rozšírením Na serveroch je inštalovaná Oracle 19c EE + Partitioning option Pre zabezpečenie vysokej dostupnosti je vytvorená standby produkčná inštancia cez Oracle Data Guard na vývojový server. Na serveri budú ďalej bežať RunTime ETL nástroja Oracle Data Integrator, dodané a inštalované uchádzačom.
DataLake	Worker Node Master Node UI Node Edge Node	Pre DataLake bude potrebné vytvoriť novú celkovú infraštruktúru cez 3 prostredia. V každom prostredí bude vytvorená sieť výpočtových uzlov, na ktorých pobežia služby Big Data. Vzhľadom na predpokladanú veľkosť dát v NBS s funkciou vysokej dostupnosti sa očakáva vybudovanie infraštruktúry vo virtuálnom prostredí NBS s možnosťou prechodu na fyzické servery. Virtuálne servery budú škálované podľa licenčnej politiky vybratej Enterprise softwarovej podpory. Predpoklad je v krokoch 1vCPUx8GB RAM. Budovanie jednotlivých uzlov bude postupné. Architektúra DataLake má charakter vysokej dostupnosti a nebude potrebné budovať standby inštanciu, ale použije sa roztiahnutie produkčných uzlov cez obe lokality. Produkčné uzly: 4x Worker Node (2+2 v lokalitách) CPU: X86 8 cores RAM: 64GB Disk: 20 TB 3x Master Node (1+2 v lokalitách) CPU: X86 8 cores RAM: 64GB Disk: 2 TB 2x Edge Node+UI Node (1+1 v lokalitách) CPU: X86 4 cores RAM: 32GB Disk: 3 TB Test uzly: 2x Worker Node (1+1 v lokalitách) CPU: X86 4 cores RAM: 32 GB Disk: 10 TB 2x Worker Node + Master Node+ Edge Node+UI Node (1+1 v lokalitách) CPU: X86 4 cores RAM: 32GB Disk: 3 TB Vývojové uzly: 3x Worker Node + Master Node+ Edge Node+UI Node (1 v lokalite) CPU: X86 4 cores RAM: 32GB Disk: 3 TB
Aplikačný server		Existujúci aplikačný server na beh aplikácií (frameworkov DWH). Tento komponent je podobne ako BI server tvorená virtualizačnou platformou NBS . Apache Tomcat/9.0.56 aplikačný server na Red Hat Enterprise Linux prostredí CPU: 4 vCPU RAM: 10 GB Disk: 25 GB Vysoká dostupnosť (failover) je riešená na úrovni virtualizačnej platformy NBS.
Reporting / BI server	PROD-BI DEV-BI TEST-BI	Exsitujúce BI servery sú virtualizované na platforme VMware ESX, virtualizačná platforma je v správe IT NBS. Výkon je možné prideliť podľa potreby. MS SQL Server 2019 Enterprise Windows Server 2022 Data Center edícia. CPU: 4 vCPU (s možnosťou navýšiť na 8 vCPU) RAM: 32 GB Vysoká dostupnosť (failover) je riešená na úrovni virtualizačnej platformy. Budú dve platformy: PROD-DB (produkčný BI server) DEV-DB (vývojový BI server) + TEST-BI (testovací BI server)
PC	PC	Inštalované komponenty, ktoré zabezpečí NBS (do 15 pracovných staníc): VMware Horizon, MS Windows 10, 4vCPU, 16GB RAM SQL Server Data Tools - pre vývojára ETL pre spracovanie tabulárnych modelov v MS SQL Server Analysis Services Oracle client pre vývojára ETL, resp. reportov Oracle SQL developer pre vývojára ETL Oracle Data Integrátor pre vývojára ETL Ostatné potrebné SW komponenty musia byť dodané v rámci ponuky uchádzača , ako napríklad: MS Power BI Pro MS Visual Studio

Tabuľka 13: Prehľad HW komponent riešenia

NBS plánuje využitie svojej existujúcej HW a SW infraštruktúry pomocou svojho IT oddelenia pre prevádzku. Táto infraštruktúra musí byť uchádzačom cieľového riešenia posúdená z pohľadu kapacity a dostupnosti s prípadným dopadom na SW licencie.

Z hľadiska vytvorenia vysokej dostupnosti bude fyzická architektúra nastavená nasledovne:

Obrázok 10: Vysoká dostupnosť nového riešenia

Aplikačná architektúra

Úvod

Nasledujúci infraštruktúrny diagram popisuje požadovanú novú aplikačnú architektúru NBS DWH z  hľadiska inštalácie jednotlivých produktov.

Obrázok 11: Aplikačná architektúra nového riešenia

Navrhované riešenie tvorené:

1. relačným DWH a BI platformou bude prevádzkované s využitím existujúcej aplikačnej infraštruktúry projektu Pilot DWH.

2. DataLake - potreba vybudovania novej aplikačnej infraštruktúry.

V prípade DWH je základným software komponentom databázový systém a systém pre ETL. NBS preferuje využiť existujúcu investíciu do projektu Pilot DWH, ktorý je postavený na:

• Databáza – Oracle DB v edícii Enterprise

• Reporting – MS SQL Server Analysis Services a MS Power BI

Navyše je v riešení NBS DWH požadované vytvorenie DataLake prostredia ako oblasť pre uloženie dát pre data discovery.

Jednotlivé komponenty riešenia budú vyžadovať nasledujúci software, a to minimálne v 3 oddelených prostrediach (vývoj, test, produkcia) v súlade s detailnými požiadavkami:

Platforma	Software	Navrhované riešenie
DWH	Operačný systém	Výber operačného systému je podriadený voľbe databázy, prípadne podkladovej HW infraštruktúry. V prípade existujúceho pilotného DWH sa využíva Oracle Linux 8 (RedHat distribúcia).
	Databáza	Existujúci Pilot DWH je postavený na relačnej databáze Oracle 19c Enterprise Edition + Partitioning Option.
	Doplnkové časti DB	Súčasné nastavenie DB a vybrané opcie (Partitioning Option) sú dostatočné a neplánuje sa úprava.
DataLake	Operačný systém	Výber operačného systému pre DataLake bude podriadený voľbe Big Data platformy, ktorá musí mať pre daný operačný systém podporu. NBS preferuje Red Hat Linux.
	Big Data platforma	Výber Big Data platformy je predmetom výberového konania.
	Platform Management	Výber Platform Management systému je predmetom výberového konania.
ETL systém	SQL ETL	Ako ETL framework je preferovaný nástroj Oracle Data Integrator
	Big Data ETL	Výber Big Data platformy je predmetom výberového konania. Podmienka NBS je použitie Enterprise riešenia pred čistým OpenSource.
	Ingestion framework	Projekt NBS DWH nebude o veľkosti spracovávaných dát, ale o počte rôznorodých dátových vstupov a vzorov. Denne/mesačne budú prichádzať stovky rôzne štruktúrovaných súborov, ktoré sa počas životnosti môžu a budú meniť. Preto požadujeme dodať v projekte systém na metadátové riadené spracovanie súborov. Bližšie v kapitolách 3.2.13.
BI	Operačný systém	Výber operačného systému je podriadený voľbe BI servera, prípadne podkladovej HW infraštruktúry. V prípade existujúceho pilotného BI servera, ktorý je postavený na technológiách Microsoft a virtualizačnej platforme VMware ESX, sa využíva Windows Server 2022 Data Center edícia. Aktuálne je zalicencovaná celá virtualizačná platforma, prípadné rozšírenie kapacity BI je preto bez dopadu na potrebu ďalších licencií OS.
	BI server	NBS využíva MS SQL Server 2019 Enterprise pre BI riešenie, konkrétne Analysis Services (tabulárne modely) a MS Power BI Report Server pre publikáciu a zdieľanie reportov a analýz. Na odbore štatistiky je to ďalej Qlik Sense – NBS však nepredpokladá ďalšie rozširovanie tohto systému mimo odbor štatistiky. Tabulárne modely v pilotnom režime boli vyvíjané na odboroch OFI a OST. Aktuálne je zalicencované a prevádzkované 1 produkčné a 1 vývojové prostredie (2x 4 jadra).
	BI klient	NBS využíva MS Power BI (On-premise) pre tvorbu reportov a plánuje tento nástroj naďalej využívať ako jednotnú aplikáciu pre reporting a analýzy. Aktuálne je k dispozícii 13 licencií MS Power BI Pro.
	Štatistický framework	Štatistické nástroje používané analytickými oddeleniami sú rôzne a používajú sa vždy podľa konkrétneho účelu. Tento štatistický framework zahŕňa nástroje Matlab, R studio, Eviews, Stata, jazyky SQL, Python, Scala a pod. Predmetom projektu nie je dodávka ďalších nástrojov alebo licencií.
	AI/ML	Nástroje pre umelú inteligenciu a Machine Learning sa zatiaľ nepoužívajú. Platforma Data Lake by však mala vytvoriť predpoklad pre ich budúce nasadenie. Predmetom projektu nie je dodávka licencií, resp. infraštruktúry pre AI/ML.
Aplikačné frameworky	Workflow Manager	Pre orchestráciu spracovania cez rôzne platformy bude zavedený jednotný nástroj. Výber konkrétneho nástroja je súčasťou výberového konania.
	Dátové modelovanie	Nástroj pre dátové modelovanie je potrebný pre zabezpečenie celého procesu vývoja dátovej integračnej platformy. Výber konkrétneho nástroja pre dátové modelovanie je súčasťou výberového konania.
	RDM DQM Metadata Management	Nástroje pre správu referenčných dát (RDM), Data Quality Management (DQM), a Metadata Management ako sú popísané v kapitolách 3.2.13 Výber konkrétnych nástrojov je súčasťou výberového konania.

Tabuľka 14: Software komponenty riešenia

Relačná databáza

Existujúci Pilot DWH je postavený na relačnej databáze Oracle 19c Enterprise Edition + Partitioning Option. Riešenie NBS DWH počíta s prepoužitím už existujúcich komponentov.

Oracle DB prináša robustnosť a širokú škálu funkcionality pre DWH riešenia. DB je optimalizovaná pre spracovanie veľkého objemu dát pomocou hromadných operácií, s využitím partícií a kompresie je možné efektívne využívať diskový priestor a znížiť nároky na diskové pole, a to ako z pohľadu kapacity, tak aj z pohľadu výkonnosti. Medzi ďalšie výhody Oracle DB patrí možnosť využívať bitmapové a funkčné indexy, ktoré spolu s DB paralelizmom umožňujú skracovať nielen ELT čas, ale aj zbiehanie užívateľských reportov. Vo svete DWH sa veľmi často využívajú analytické funkcie, ktoré umožňujú jednoducho vytvárať aj veľmi komplexné reporty bez potreby ukladania medzivýsledkov v DB. Z pohľadu security je veľmi užitočnou vlastnosťou Virtual Private Database, ktorá umožňuje riadiť prístup nielen na úrovni objektov, ale aj na úrovni riadkov a atribútov. Oracle Database Resource Manager umožňuje administrátorom riadiť prideľovanie zdrojov (CPU a IO operácií) pre jednotlivých užívateľov a procesy. Pre komplexné monitorovanie výkonu a optimálne využívanie DB slúži Oracle Enteprise Manager spolu s Automatic Workload Repository, ktoré poskytujú kompletný prehľad o využívaní zdrojov jednotlivými procesmi. Oracle DB v prípade potreby umožňuje jednoducho rozširovať funkcionalitu o ďalšie možnosti ako je napríklad: In-memory, OLAP DML, datamining.

Aplikačné frameworky, ktoré majú pomôcť zrýchliť vývoj DWH, zjednodušiť správu a spríjemniť technické riešenie pre netechnických používateľov. Z aplikačného hľadiska sú to (detailný popis je nasledujúcich kapitolách):

• Nástroje pre podporu prevádzky a odborových používateľov:

  • Podporu správy, riadenia a monitoring aktualizačných úloh (Workflow Management – Data Orchestration).

  • Správa číselníkov, mostíkov, referenčných dát, hierarchií jednotlivých dimenzií a manuálnych vstupov.

  • Bezpečné nahrávanie veľkého počtu a rôznych súborov, t. j. všetky a práve raz (Ingestion framework)

  • Správa dátovej kvality - automatické spúšťanie a vyhodnocovanie testov

  • Správa prístupov (riadenie bezpečnosti) k dátam

  • Správa dokumentácie k DWH a iných metadát (o modeli, o reportoch, mapovaní zdroj-cieľ)

  • Riadenie dátovej retencie

ETL framework

ETL (Extraction – Transformation – Load) framework je základným subsystémom pre integráciu dát v DWH a jeho voľba do značnej miery určuje budúcnosť ďalšieho rozvoja a správy integračnej platformy.

ETL framework by mal najmä spĺňať tieto požiadavky:

• Poskytovať štandardizované prostredie pre vývoj, prevádzku a ďalší rozvoj DWH a integrácie dátových zdrojov a spracovanie dát

• Štandardizovať prístup k vývoju ETL kódu a minimalizovať technické chyby v implementácii

• Podporovať kolaboratívny prístup k vývoju, umožňovať spoluprácu vývojárov a vývojových tímov

• Poskytovať systematickú podporu pre verziovanie kódu a release management

• Poskytovať metadáta pre technickú data lineage

• Poskytnúť prostredie na aplikovanie templatov a prednastavených ETL častí. Vyžaduje sa podpora a prístup low-code, všetky parametre mapovania ETL musia byť uložené v metadátach. Samotné vytvorenie ETL kódu do SQL nastane kompiláciou contextového nastavenia topológie infraštruktúry, zvolenej technológie a znalostných templatov.

• ETL framework by mal mať API na hromadné nastavenie metadát.

• ETL framework by mal mať popísané metedáta pre hromadný export do metadata management aplikácie.

• Poskytnúť možnosť vymeniť template ETL kódu bez nutnosti zmeny nastavenia samotného mapovanie, napr. pri ladení ETL.

• Ako nástroj vývoja spracovania dát by mal byť jednoducho použiteľný a na slovenskom trhu by mal byť dostatok kvalifikovaných IT špecialistov

Na základe hore uvedených požiadaviek je odporúčaný nástroj Oracle Data Integrátor.

Oracle Data Integrátor (ODI) umožňuje jednoducho a rýchlo integrovať údaje z rôznych technológií. Knowledge Module (KM), ktoré sa využívajú pri vytváraní rozhraní prinášajú na rozdiel od tradičných ETL nástrojov, možnosť využiť natívne vlastnosti danej technológie pri spracovaní údajov v jednotlivých krokoch extrakcie, transformácie a nahrávaní. Široké možnosti definovania fyzickej a logickej topológie a ich prepojení pomocou kontextu dávajú veľkú voľnosť pri zmene infraštruktúry bez potreby zásadných zásahov do ELT procesu. Napriek tomu, že KM sú dodávané spolu s produktom ODI je ich možné upravovať podľa potreby konkrétnej riešenej úlohy. Prostredníctvom ODI API je možné vytvárať mapovania ako aj aktualizovať ODI metadáta (topológiu, security, ODI model, atď.). Táto možnosť sa využíva predovšetkým pri hromadných zmenách, prostredníctvom API je možná hromadná zmena KM spolu s vygenerovaním ODI scenárov a ich nasadením do produkčného repozitára. Pri správnom používaní ODI je veľkou výhodou možnosť robiť impact analýzu pri zmenách na zdrojových systémoch a rovnako pri dohľadaní zdroja, ktorý sa používa na aktualizáciu DWH objektov. Okrem toho, že ODI priamo podporuje vytváranie impact analýz, zdokumentované ODI metadáta slúži na generovanie online ETL dokumentácie v rámci Data Governance stratégie.

DataLake

DataLake je súbor aplikačných komponentov, ktoré majú používateľovi priniesť :

• Distribuovaný súborový systém umožňujúci spoľahlivo uchovávať dáta v rôznych formátoch

• Nástroje umožňujúce vytváranie databáz, tabuliek, partícií a iných komponentov

• Distribuovaný výpočtový framework umožňujúci spracovanie nad dátami

• Grafický interface pre potreby správy platformy

• Granulárne riadenie prístupov do platformy auditnými funkciami

• Správa zdrojov platformy

• Nástroje umožňujúce prístup k dátam použitím tradičného SQL jazyka ako aj programovacích jazykov (R, Python, Scala, ...)

Správa DataLake

DataLake platforma je zložená zo súboru technológií, ktoré medzi sebou komunikujú a zabezpečujú bezproblémový chod platformy. Každá technológia, ktorá je súčasťou platformy zastrešuje inú funkcionalitu, ktorá je od DataLake očakávaná. Tieto technológie sú zväčša inštalované na viaceré lokácie z dôvodu zabezpečenia vysokej dostupnosti a robustnosti platformy.

Pre efektívne spravovanie platformy je vyžadované, aby existoval nástroj s grafickým rozhraním, ktorý ponúka možnosti na spravovanie a monitorovanie platformy. V prípade, že by nebol využitý nástroj na správu platformy, je nutné všetky zmeny vykonávať manuálne alebo polo-manuálne prostredníctvom zmien v konfiguračných súboroch, ktoré sa môžu veľa krát nachádzať na rôznych serveroch. Práve z tohto dôvodu vznikli nástroje, ktoré umožňujú jednoduchú správu DataLake platformy, či už platforma pozostáva z troch serverov alebo z desiatok/stoviek.

Pomocou takéhoto nástroja bude možné jednoduchým spôsobom konfigurovať a sledovať stav platformy. Požiadavky na nástroj :

• Grafické rozhranie

• Podpora pridávania a modifikovania DataLake služieb

• Podpora reštartovania služieb, prípadne celej platformy

• Podpora real-time monitorovania stavu platformy

• Podpora analýzy historických dáta z monitorovania behu v podobe grafov a metrík

• Podpora konfigurácie custom alertov na základe aktuálneho stavu platformy

• Možnosť upgradovať platformu priamo z nástroja

• Podpora správy užívateľov

Storage (Distribuovaný súborový systém)

Hlavným pilierom DataLake platformy bude distribuovaný súborový systém, ktorý zabezpečuje robustné a spoľahlivé riešenie na ukladanie a následné procesovanie veľkého množstva dát. Distribuované súborové systémy DataLake platformy budú optimalizované na čítanie a zápis veľkého množstva dát v akomkoľvek formáte.

Tieto technológie zväčša využívajú master/slave architektúru. Master server uchováva jednotlivé metadáta o súboroch a na slave serveroch sú rozdistribuované jednotlivé dátové bloky. Vysoká dostupnosť dát bude zabezpečená replikáciou metadát ako aj jednotlivých dátových blokov naprieč servermi DataLake platformy. Replikácia dát zabezpečuje bezproblémový chod platformy aj v prípade výpadku viacerých diskov, poprípade celých serverov.

ETL framework (DataLake)

ETL (Extraction – Transformation – Load) framework je základným subsystémom pre integráciu dát v DataLake platforme obdobne ako pre DWH. ETL frameworky umožňujú jednoduchým spôsobom:

• integrovať externé dáta do platformy - štruktúrované, pološtruktúrované aj neštruktúrované dáta (csv, xml, json, logy, pdf, obrázky …)

• efektívne spracovanie dát do finálnych štruktúr

• export dát do ďalších systémov.

Moderné DataLake platformy ponúkajú rôzne prístupy riešenia ETL požiadaviek. V rámci budovania DataLake je potrebné zabezpečiť nasledujúce potreby:

• možnosť čítania dát z externých databáz pomocou štandardných JDBC/ODBC konektorov, SFTP serverov, distribuovaných file-systémov (HDFS, S3, ..)

• distribuované spracovanie dát pomocou štandardných SQL príkazov a syntaxe, ako aj možnosť použitia programovacích jazykov (Python, Java, Scala, R). Technológia by mala umožniť aj kombináciu oboch prístupov (SQL + programovací jazyk) v jednom ETL.

• možnosť exportovať napočítané dáta do štandardných relačných databáz ako aj NoSQL databáz. Taktiež možnosť exportovať dáta priamo do DataLake platformy či už vo forme súborov alebo vo forme dát v tabuľkách.

Orchestrácia ETL úloh

Každá úloha musí spustená práve v správnom čase a práve v presnej závislosti na iné úlohy. O tieto úlohy sa stará systém na orchestráciu. Je vyžadované:

• Každá úloha ETL frameworku DataLake-u musí logovať svoj stav do dohodnutej DB tabuľky

• Úlohy ETL DL bude možné zavolať cez WebService z Oracle prostredia aplikačného frameworku pre zabezpečenie globálneho riadenia. T. j. je vyžadované aby makro scheduller bežal na relačnej časti DWH. ETL DL bude riadený vzdialene ako ucelené bloky. Ich podčasti je možné kontrolovať mimo DWH makroscheduller, ale všetky časti bude možné skontrolovať z jedného miesta.

• ETL DL nebude plánované samostatne, ale len ako jeden celok DWH (relačná + DL časť)

JDBC prístup

Jednou z najdôležitejších požiadaviek na DataLake platformu je možnosť napojenia štatistických a BI nástrojov na dáta, ktoré sú súčasťou platformy. Najštandardnejším spôsobom, ktorý je využívaný v BI a štatistických nástrojoch je práve spôsob dotazovania pomocou JDBC a ODBC technológií.

DataLake platforma musí poskytovať spôsob napojenia pomocou týchto technológií.

Požiadavky na JDBC/ODBC:

• Možnosť dotazovania pomocou JDBC/ODBC spojenia

• Možnosť granulárnej konfigurácie oprávnení pre JDBC/ODBC spojenia

  • Pre technických aj biznis používateľov

  • obmedzenia na čítanie/zápis len pre vybrané objekty

• Dotaz definovaný v JDBC/ODBC spojení musí byť distribuovane spracovaný DataLake platformou.

Import súborových dát priamo do DataLake

DataLake platforma by mala poskytovať rozhranie na ukladanie a čítanie súborov z distribuovaného súborového systému prostredníctvom grafického rozhrania. Týmto spôsobom je možné pridávať, poprípade kontrolovať súbory ktoré sa nachádzajú na distribuovanom súborovom systéme.

Požiadavky:

• Možnosť čítania súborov na distribuovanom súborovom systéme

• Možnosť zápisu dát na distribuovaný súborový systém

• Možnosť granulárnej konfigurácie oprávnení pre manipuláciu so súbormi na úrovni súborov a adresárov.

Pomocou priameho prístupu na distribuovaný súborový systém je možné nahrávať do platformy dátové zdroje, pre ktoré neexistuje automatizovaná integrácia (tento prístup je možné použiť aj v prípade manuálnych korekcií dát).

Resource Management

DataLake platforma by mala poskytovať Resource Management službu, ktorá by zastrešovala prerozdeľovanie dostupného výpočtového výkonu DataLake platformy medzi technické aplikácie a biznis užívateľov. Je nutné si uvedomiť že aplikácie, ktoré budú využívať výpočtový výkon DataLake platformy sú súčasťou ETL spracovania alebo sú súčasť biznisových procesov (machine learning, ad-hoc štatistika, ...). Resource Management služba by mala byť schopná zabezpečiť možnosť definovať prioritu a dostupné zdroje (CPU + RAM) pre rozdielne ETL aplikácie a rozdielnych biznis užívateľov (poprípade skupinu užívateľov). Takýmito pravidlami je možné zabezpečiť vyváženosť prerozdeľovania výpočtového výkonu DataLake platformy medzi rozdielne aplikácie.

V prípade, že by služba Resource Managementu nebola dostupná pre DataLake platformu mohli by nastávať situácie využívania celkového výkonu platformy v prospech jednej (alebo viac) aplikácie, pričom ostatné aplikácie by neboli schopné alokovať potrebné zdroje.

Resource manager DataLake platformy by mal byť schopný zabezpečiť:

• Možnosť konfigurácie resource group na úroveň užívateľov, skupiny užívateľov a skupiny technických aplikácií

  • Minimálne a maximálne zdroje.

• Efektívne prerozdeľovanie dostupných zdrojov

• Monitoring dostupných a využitých zdrojov

Bezpečnosť (security)

DataLake platforma musí spĺňať bezpečnostné štandardy, ktoré zabezpečia že dáta uchovávané a spracúvané v DataLake platforme budú dostupné len používateľom a aplikáciám s prislúchajúcimi právami.

Nároky na bezpečnosť prostredia DataLake platformy:

• Centrálne riadené

• Možnosť granulárnej konfigurácie oprávnení

  • databázy, tabuľky, stĺpce

  • adresáre a súbory prislúchajúceho distribuovaného súborového systému

• Grafické rozhranie na správu prístupových oprávnení

• Auditovanie údajov (všetky aktivity na DataLake musia byť auditované a dostupné v reálnom čase)

  • Prístupy a modifikácie tabuliek a databáz

  • Prístupy a modifikácie na súborovom systéme

  • Spúšťanie distribuovaného spracovania

Metodika vývoja

Pri vývoji DWH musia byť dodržané metodické postupy, aby návrh DWH bol:

• Nezávislý na platforme - Navrhnutý dátový model by mal byť v čo najväčšej miere nezávislý od technológie, na ktorej bude DWH prevádzkovaný. Dátový model by mal byť prenositeľný medzi jednotlivými platformami (MS SQL, Oracle, PostgreSQL, atď.) a nemal by sa spoliehať na špecifiká vybraného databázového systému. Rozdiely plynúce zo syntaxe resp. samotného jazyka DDL jednotlivých platforiem nie sú považované za systémové špecifikum. Súčasť dodávky však budú tvoriť DDL definície iba pre dodanú platformu. V rámci projektu NBS DWH sa prepoužije technológia z Pilotu DWH.

• Nezávislý od zdrojových systémov - Navrhnutý dátový model by mal byť čo najmenej závislý od zdrojových systémov. Predpokladá sa, že v dlhodobom horizonte, v čase životnosti nového dátového skladu dôjde k výmene niektorých biznis systémov.

• Flexibilný - Dátový sklad by mal byť z dlhodobého hľadiska rozšíriteľný na nové okruhy dát podľa budúcich požiadaviek zákazníka ako napr. nové typy produktov, zmena procesov atď.

• Časová nezávislosť dát - Navrhnutý dátový model musí zabezpečiť ako aktuálny, tak aj historický pohľad na dáta v DWH na základe výberu časového intervalu. Dátová retencia bude dohodnutá počas projektu. Predpokladaná dĺžka histórie je 10 rokov, granularita dát minimálne na úrovni kalendárneho dňa.

• Aktuálnosť - Dáta v dátovom sklade by mali byť aktualizované minimálne raz denne. V DWH by sa mal nachádzať stav dát s platnosťou minimálne D-1. Avšak môžu existovať definované typy dát, kde bude potrebné navrhnúť a použiť aj nižšiu frekvenciu aktualizácie (cyklické near-online spracovanie).

• Interaktívny a inkremetálny vývoj - Ktorákoľvek úloha v rámci projektu, alebo po ňom môže byť predmetom iterácie. Či iterovať alebo nie, rovnako ako počet iterácií, toto rozhodnutie je rôzne od prípadu k prípadu. Úlohy môžu byť iterované za účelom zvýšenia kvality výstupov na požadovanú úroveň, za účelom získania dostatočnej miery detailu alebo vylepšenia a rozšírenia výstupov na základe spätnej väzby používateľa.

Uchádzač bude preukázateľne disponovať skúsenosťami v oblasti dátového modelovania a návrhu dátových modelov pre dátové sklady. V rámci projektu zhotoviteľ navrhne a zdokumentuje:

• metodiku tvorby a ďalšej správy dátových modelov relevantných pre projekt

• súvisiace dizajn štandardy (štandardy a postupy návrhu dátových modelov v jednotlivých vrstvách DWH a DataLake (typy modelov, ich účel, previazanosť a forma zápisu)

• menné konvencie pre jednotlivé typy modelov a dátové vrstvy

• prevádzkový model, x. x. xxxxxx procesy a role súvisiace so správou modelov (reverse engineering zdrojov, design nových modelov, kolaborácia používateľov a riadenie prístupu, exporty resp. publikácia metadát pre zdieľanie, release management)

Tieto štandardy budú odsúhlasené s Data Governance kanceláriou a následne aplikované počas realizácie projektu.

V rámci projektu budú zavedené minimálne tieto dátové modely a súvisiace výstupy:

• Konceptuálny dátový model – dokumentujúci biznisové koncepty a pojmy podľa definície NBS

• Fyzické dátové modely:

  • DataLake

    • Primárna vrstva

    • Discovery vrstva

  • DWH

    • Transakčné repozitory (L1 – Integračná vrstva)

    • Prezentačná vrstva (L2 - Analytická vrstva)

Úroveň detailu zachytenia fyzických parametrov databázových objektov bude dohodnutá tak, aby efektívne podporovala dizajn, vývoj, nasadenie príslušných objektov a súčasne udržateľnosť modelu a jeho dokumentačnú funkciu.

Podobne požadujeme dodanie popisu dátových modelov a procesov jednotlivých funkčných frameworkov (napr. schémy s referenčnými dátami, lookup tabuľkami, chybovými tabuľkami, metadátami a výsledkami kontrol kvality a automatických testov, manuálne korekcie, žurnál spracovania apod.)

Dátové toky a transformácie dát budú systematicky a metadátovo popísané tak, aby bolo možné tieto metadáta využiť pre navigáciu v dátových tokoch, zisťovanie dátových zdrojov pre cieľové atribúty a analýzu dopadov pri zmenách v dátových zdrojoch na cieľové štruktúry.

Nasledujúce princípy návrhu dátového modelu musia byť počas projektu dodržané a považujeme ich za kritické pre konzistentnosť, integritu, otvorenosť a výkonnosť DWH riešenia ako celku.

• Model transakčnej (L1) a prezentačnej vrstvy (L2/PL) sú integrované a spoločné. Jedna entita je mapovaná do jednej tabuľky bez ohľadu na počet inštancií danej entity v zdrojových systémoch.

• Dimenzie v prezentačnej vrstve sú denormalizované a zdieľané a využívané cez všetky biznis oblasti. Existuje iba jedna dimenzia zákazníkov, iba jedna dimenzia umiestnení, atď. Zdieľané dimenzie podporujú krížové analýzy cez jednotlivé biznis oddelenia v spoločnosti.

• Prezentačná vrstva pozostáva zo star schém, ak je to možné bez snowflake. Inými slovami faktová tabuľka je spojená priamo s dimenziou nie je nutný viacnásobný join. Je možné, že budú existovať výnimky, ktoré je potrebné pred implementáciou explicitne schváliť NBS.

• Všetky dimenzie a referenčné tabuľky sú prepojené výlučne pomocou umelých kľúčov. Umelé kľúče chránia dátový sklad pred zmenami v zdrojových systémoch a umožňujú integráciu viacerých zdrojov do jednej tabuľky v DWH.

• Všetky dimenzie, prepojovacie lookup tabuľky (v prípade potreby aj faktové tabuľky) obsahujú aj prirodzené kľúče a identifikátor zdrojového systému. To znamená, že záznam v DWH môže byť dohľadaný v zdrojovom systéme.

• Multitenant – globalizácia a efektívne využívanie zdrojov vedie k situáciám, kedy v jednom zdrojovom systéme sa prevádzkujú údaje viacerých spoločností. V tomto prípade nestačí v DWH rozlišovať z ktorého zdrojového systému prišiel do DWH daný záznam, ale je potrebné riešiť kto „vlastní“ daný záznam v zdrojovom systéme. V DWH je potrebné sledovať vlastníka („tenanta“) daného záznamu. Táto informácia sa používa v určitých typoch reportov, kde je potrebné rozdeliť údaje o jednom zákazníkovi z pohľadu daného vlastníka napriek tomu, že ide o jednu a tú istú právnickú alebo fyzickú osobu.

• V prípade potreby budú údaje v DWH unifikované. Bude dohodnuté, ktoré dáta a ako budú unifikované. Prístup k unifikácií využíva dve rozdielne techniky:

  • Riadková unifikácia, napríklad v prípade zákazníkov. V tomto prípade je jedna informácia v DWH reprezentovaná jedným záznamom bez ohľadu na počet záznamov v zdrojových systémoch. Údaje sú unifikované pomocou rôznych čistiacich a unifikačných procedúr.

  • Druhý prístup je unifikácia pomocou hierarchií. Tento prístup sa využíva v prípade dimenzií (napr. produkty). V tomto prípade má každý produkt v DWH jeden záznam rovnako ako v zdrojovom systéme. Nad takouto dimenziou je vytvorená hierarchia, ktorá v reportoch zgrupuje identické produkty do jedného záznamu.

• Všetky riadky v tabuľke majú zhodnú granularitu a význam. To znamená, že nie je akceptovateľné miešať detailné a agregované údaje alebo údaje s rôznou granularitou.

• Integritná konzistencia (primárne, unikátne a umelé kľúče) bude definovaná pre všetky tabuľky v transakčnej a prezentačnej vrstve. Avšak pre veľké tabuľky bude integrita dát kontrolovaná zabezpečená designom ETL, nebude kontrolovaná na úrovni DB, z dôvodu výkonnostných problémov ELT.

• Pre veľké tabuľky je nutné využiť Oracle DB partície, aby sa uľahčil ELT proces, zvládol nárast historických údajov a zlepšila výkonnosť ako používateľských dotazov, tak aj ELT nahrávania dát.

• Jedným zo základných princípov pri budovaní DWH je, že budovanie histórie v transakčnej vrstve DWH je s prihliadnutím, že údaje sa v DWH nikdy fyzicky nemažú. Počas projektu bude stanovená retenčná doba jednotlivých dát.

• V rámci dátového modelovania budú udržiavané prípadné ďalšie metadáta k jednotlivým štruktúram na podporu data governance procesov, ako sú napr.:

  • klasifikácia dát z pohľadu citlivosti a GDPR

  • väzby na referenčné dáta / katalógy / domény

  • účelu použitia

  • prípadne iné podľa požiadaviek Data Governence kancelárie

Dátový sklad na prezentačnej úrovni bude budovaný ako tzv. dimenzionálny dátový sklad, ktorý obsahuje dva základné typy objektov:

• Fakty, t. j. numerické hodnoty, ktoré sú sledované. Fakty sú spravidla aditívne, resp. semiaditívne hodnoty, ktoré je možné sčítať resp. spriemerovať podľa požadovaných kritérií. Fakty sú zoskupené do tzv. faktových tabuliek.

• Dimenzie, t. j. kritériá, na základe ktorých sú fakty členené. Príkladom je čas, nákladové stredisko, organizačná štruktúra atď. Dimenzie väčšinou obsahujú veľké množstvo atribútov a úrovní, ktoré prvok na dimenzii charakterizujú. Z úrovní je možné tvoriť hierarchie a prirodzeným spôsobom tak prechádzať z agregovanej hodnoty (vyššia úroveň) na detailnejšie dáta (nižšia úroveň). Dimenzie v dimenzionálnom dátovom sklade musia byť unifikované pre zdieľanie medzi rôznymi faktovými tabuľkami. Jedine tak je možné prechádzať („Drill Accross“) medzi faktami z rôznych faktových tabuliek - t. j. na základe rovnakých hodnôt spoločných dimenzií.

Relačná časť NBS DWH

Úvod

NBS DWH bude logicky členený na niekoľko dátových vrstiev, pričom každá bude plniť špecifickú úlohu. Vrstvy sú navrhnuté v súlade so zavedenými prístupmi pre vnútorný návrh DWH.

Obrázok 12: DWH Relačná časť - vrstvy DB a jej aplikačné časti

Preto je požadované v  návrhu DWH dodržať zásady spísané v nasledujúcich podkapitolách.

Stage oblasť/L0

Vstupná vrstva dátového skladu, ktorá obsahuje dáta v štruktúre zdrojových systémov, resp. ich výstupných interfejsov. Účel tejto vrstvy je:

• Poskytnúť obraz vzájomne konzistentných zdrojových dát pre spracovanie v DWH na spoločnej technologickej platforme

• Štandardizovať dátové typy (zmena časového pásma dátumu/času, štandardizácia číselných údajov, ignorovanie tzv. white spaces v textových poliach, úprava kódovej stránky a podobne)

• Poskytnúť krátkodobú cache (historizáciu vstupných dát) pre prípadné dohľadávanie chýb a podozrivých stavov v dátach

Dáta môžu byť prenášané do STAGE vrstvy vo forme kompletných kópií zdrojových dát (napr. kmeňové dáta a referenčné dáta) alebo zmenových prírastkov (nové transakcie, resp. záznamy, kde došlo k zmene od posledného spracovania). Pre každý dátový interface (zdrojový systém, je jedno či ide o databázu, súbor, alebo záložku napr. v XLS) je vyžadované aby vznikol dokument tzv. „Dohoda o extrakcii“ (Interface agreement), template dodá NBS. Kde bude popísané:

• Forma interface (DB, súbor, WebService)

• Veľkosť zdrojového systému a predpokladaný denný/mesačný inkrement

• Spôsob prenosu dát (dblink, FTP, JDBC, ODBC, http, ...)

• Umiestnenie systému (IP adresa, Linka, ...)

• Predpis extrakcie a štandardizácie dátových typov

• Základný ER diagram zdroja

• Spôsob prípravy vzorky dát pre TEST a DEV prostredie

• Identifikácia citlivých a osobných údajov

• Nastavenie a spôsob (inkrement, celá snímka) historizácie vstupných dát – ak je požadovaná, alebo potrebná

Stage vrstva musí mať vlastnosť samočistenia, t. j. bude sama odmazávať a defragmentovať priestor na základe metadát z nastavenia historizácie vstupných dát.

Názvy tabuliek a stĺpcov by mali reflektovať názvy v zdrojových systémoch. Počas projektu bude dohodnutá názvová konvencia, ktorá stanoví štandardy pre názvy tabuliek (a ich prefixy/sufixy), spôsob pomenovania biznis stĺpcov a názvy technických stĺpcov.

Princípy zachytávania zmien (Change Data Capture)

Prístup k zachytávaniu zmien údajov bude implementovaný spôsobom, ktorý minimalizuje množstvo údajov, ktoré majú byť spracovávané a taktiež zmeny riadkov, ktoré sú potrebné pre SCD. Budú použité niektoré z nasledujúcich techník, ktoré sú plne podporované ODI.

• Priamo systém poskytuje interface s potrebnými dátami na extrakciu.

  • Dáta budú zo systému priamo extrahované a uložené do STAGE. Toto uloženie bude označené metadátovou značkou, kedy dáta boli prenesené pre spätnú kontrolu kvality prípravy extraktu na zdroji – identifikácia prípadných duplicít, alebo opravných setov dát.

• Systém neposkytuje priamo dáta.

  • Pre malé a stredne veľké tabuľky budú sa robiť full extrakty zo zdrojových systémov. Tieto full extrakty sa porovnajú s údajmi, ktoré sa už nachádzajú v DWH buď množinovou operáciou MINUS alebo pomocou FULL OUTER JOIN na identifikáciu zmien.

  • Ak zdrojové tabuľky obsahujú spoľahlivú časovú známku, budú extrahované zo zdrojového systému riadky, ktoré majú časovú známku novšiu ako je predchádzajúca extrahovaná časová známka. Prenesené dáta musia byť označené metadátovou značkou.

  • V prípade, že extrakcia založená na časových známkach nie je možná, pripadá do úvahy extrakcia s využitím DB trigrov. Vyžadujú si úpravy na strane zdrojových systémov (vytvorenie DB trigrov – ako je MVIEW a podobne) a preto nepredpokladáme využitie tejto metódy v NBS DWH.

Pre účely riadenia zápisu zistených zmien na zdrojovej strane sa vyžaduje použitie nasledujúcej schémy ETL procesy:

1. Pri použití historizovaného STAGE/L0

Obrázok 13: ETL schéma historizovanej vrstvy STAGE

2. Pri použití klasického nehistorizovaného STAGE/L0

Obrázok 14: ETL schéme nehistorizovanej vrstvy STAGE

Reference Data Oblasť (INP)

Účel tejto vrstvy je:

• Udržať konzistenciu dát na úrovni číselníkov

• Vstupná brána pre používateľov cez aplikačné GUI pre doplnenie dát do DWH

• Poskytnúť cez REST API tieto číselníky ostatných odberateľom v NBS

Táto oblasť preto obsahuje číselníky a čistiace, či mostíkové tabuľky pre:

• mapovanie zdrojových hodnôt na DW kľúče,

• doplnenie hierarchií a údržbu master dimenzií,

• pridávať ďalšie informácie importom súborov cez aplikačné GUI

Návrh dátového modelu tejto časti je silne v tretej normálnej forme s plným nastavením primárnych a unikátnych indexov pre zabezpečenie kvality dát. Rovnako vzťahy medzi objektami typu master-slave musia byť podporené cez FK (vzdialený alebo cudzí kľúč) a iné obmedzenia.

Transakčné repozitory (L1 – Integračná vrstva)

Táto oblasť je základ dátového skladu, kde sa uchovávajú údaje na najnižšom detaile ako je možné. V transakčnej vrstve sa tvorí jedna pravda na jednom mieste, ktorá generuje históriu a sleduje zmeny v čase. Pri aktualizácii sú povolené výlučne technické transformácie a biznisové transformácie, ktoré nie sú ovplyvňované rozhodnutiami biznisu. Táto vrstva je striktne navrhovaná ako tretia normálna forma (metodika Billa Inmona) a vytvára deliacu čiaru medzi ďalšími komponentmi dátové skladu. Ak je potrebné zmeniť alebo doplniť ďalší zdrojový systém, upraví sa len prislúchajúca časť ETL v tejto vrstve. Všetky ostatné časti DWH sa nemenia. Navyše táto vrstva vytvára predpoklady na integráciu a normalizáciu údajov. Keďže transakčná vrstva zohľadňuje všetky relácie medzi objektmi, je možné vytvárať komplexné analýzy a dotazy, ktoré sú nad rámec dimenzionálneho sveta.

Pri návrhu transakčnej časti DWH je nutné v súčasnosti prihliadať aj na nové poznatky a metodiky, ktoré dopĺňajú a rozširujú skôr spomenuté prístupy modelovania. Pomáhajú zrýchliť, zjednodušiť ETL procesy napríklad použiť aj princípy modelovania metódy Data Vault 2.0¹ .

Ako nadstavba nad týmto transakčným repozitárom je vytvorená prezentačná vrstva v zmysle dimenzionálneho modelu ako ju navrhuje Xxxxx Xxxxxxx pre vytváranie reportov a analýz.

Dátový model zachytáva konkrétne koncepty, entity, ich vzťahy a klasifikácie nezávisle na tom, ako sú zodpovedajúce dáta organizované v zdrojových systémoch. Vlastníkom dátového modelu je NBS.

T. j. cieľom tejto vrstvy dát je:

• Poskytnúť aktuálny aj historický pohľad na dáta, resp. ich historické verzie k akémukoľvek bodu v čase (použitie umelých kľúčov, vymedzenie platnosti záznamov – tzv. SCD2 mechanizmus u „pomaly sa meniacich“ dimenzií a väzobných tabuliek, resp. transakčné a snímkovacie tabuľky pre „rýchlo sa meniace údaje“)

• Organizovať dáta zrozumiteľne podľa biznisových entít (entitno-relačný model), t. j. dáta z rôznych systémov zodpovedajúce jednej entite sú uložené spoločne, t. j. tabuľky odpovedajú reálnym konceptom/entitám, ktorým rozumie biznis užívateľ (napr. subjekt, transakcia, inštrument, cenný papier, účet, výkaz, položka výkazu, apod.)

• Štandardizovať, resp. unifikovať dáta (vynútenie jednotného spôsobu zápisu údajov s rovnakým významom)

• Nahradiť neznáme, prípadne nekvalitné dáta dohodnutým spôsobom (default hodnoty a ošetrenie tzv. „late arriving“ údajov)

• Konsolidovať klasifikácie dát z rôznych zdrojov pre spoločný reporting (okrem uloženia pôvodných referenčných hodnôt to prebieha ako premapovanie cez konsolidované číselníky pomocou dát uložených v „Reference Data Oblasti“).

• Konsolidovať dátové entity podľa konceptuálneho návrhu dátového skladu. Ako sú napr.:

  • údaje o subjektoch (právnických aj fyzických osobách), ktoré môžu byť reprezentované v rôznych zdrojových systémoch pomocou rôznych identifikátorov a kódov – ich prepojenie bude implementované cez dohodnutý algoritmus tak, aby bolo možné prepojiť údaje súvisiace s konkrétnym výskytom subjektu pochádzajúcich z rôznych zdrojov.

  •  údaje o entitách typu cenné papier/finančný inštrument.

Pri návrhu bude potrebné počítať minimálne s týmito požiadavkami:

• Dáta budú spracúvané a ukladané čo najoptimálnejším spôsobom podľa best-practice budovania dátových skladov s využitím technológií databáze (partitioning, paralelné spracovanie, správa indexov, optimálne rozloženie dát podľa ich povahy a volatility apod.)

• Bude vytvorený mechanismus pre archiváciu (resp. presun do záložných štruktúr) a výmaz nepotrebných historických dát z DWH podľa zadaných parametrov na úrovni jednotlivých tabuliek.

Pre každú tabuľku bude zabezpečený iniciálny load, ktorý zabezpečí prvotné naplnenie všetkými dátami, ktoré sú potrebné pre ďalšie inkrementálne spracovanie so zachovaním referenčnej integrity. Historický load bude zabezpečený pre zvolené dátové oblasti podľa definície jednotlivých dátových zdrojov, t. j. pre každý dátový zdroj je individuálne definovaná hĺbka histórie, spracované budú relevantné cieľové tabuľky DWH. Cieľom historického loadu je rekonštruovať historické stavy dát, t. j.:

• historické transakcie / udalosti

• historické položky dimenzionálnych tabuliek a číselníkov (kmeňových dát), na ktoré sa odkazujú historické fakty pre zachovanie referenčnej integrity

• historické stavy hodnôt atribútov v dimenzionálnych tabuľkách

• historické snímky stavových ukazovateľov a relevantných popisných údajov

• historické platnosti vzťahov (relácií) medzi entitami

Biznisová oblasť

Podobne ako oblasť DWH nazývaná „referenčné dáta“, ktorá obsahuje dimenzie a číselníky pre doplnenie ETL procesu počas normalizácie a konsolidácie zo stage do transakčnej oblasti, tak oblasť nazývaná „biznisová oblasť“ obsahuje mostíky, šablóny a prioritizačné tabuľky pre riadenie (ak je to potrebné, nie každé ETL to potrebuje) spracovanie z transakčnej oblasti do prezentačnej vrstvy.

Na prvý pohľad číselník a mostík vyzerajú rovnako. Do číselníka môže biznisový používateľ cez RDM systém zadávať hodnoty, pridávať hierarchie, alebo definovať vzťahy medzi dátami. Ale väčšinou ide o jednu informáciu v jednej dimenzii. V mostíku sa môže definovať vzťah medzi viacerými dimenziami a ako sa má tento vzťah konvertovať na novú dimenziu. T. j. z jednej a viac vzniká nová odvodená (premostená) hodnota dimenzie. Kde toto spojenie nie je triviálne čo do počtu kombinácií (nakoľko ide o kartézsky súčin všetkých hodnôt v dimenziách) požadujeme vytvoriť systém využívajúce šablóny, kde biznisový používateľ bude vedieť definovať pravidlá cez „stanovené postačujúce podmienky“ (presne definované pravidlá) a zvyšné časti opakujúcich sa spojení systém dogeneruje počas (alebo pred) ETL spracovania.

Prezentačná vrstva (PL + L2 - Analytická vrstva)

Prezentačná vrstva je replikovaná časť transakčného repozitára, vytvorená na základe špeciálnej „biznisovej“ požiadavky. Zvyčajne sa navrhuje metódami Xxxxxx Xxxxxxxx a má dimenzionálny charakter, t. j. táto vrstva DWH poskytuje pohľad na dáta v štruktúre, ktorá je vhodná pre konkrétne analytické resp. reportingové účely. Organizácia dát je podriadená konkrétnym požiadavkám užívateľov a BI aplikácií.

Na rozdiel od technických transformácii sa v priebehu ETL procesu z transakčnej do prezentačnej vrstvy využívajú predovšetkým biznisové transformácie, ktoré sa v čase môžu zmeniť. V prípade zmeny biznisovej definície je možné podľa požiadavky prepočítať spätne časť alebo celú históriu na základe údajov uchovaných v transakčnej vrstve. V ETL proces sa využívajú špeciálne transformačné techniky (na základe definícií uložených v biznisovej vrstve DWH), ktoré umožňujú údaje transformovať na základe používateľských mostíkov, šablón a priorít.

Účelom tejto vrstvy je teda:

• Organizovať dáta optimálne pre konkrétne analytické a reportingové požiadavky do star-schém s potrebnou denormalizáciou a prípadnou agregáciou

• Poskytovať dodatočné vypočítané/odvodené dáta, ktoré sú špecifické pre danú analytickú potrebu.

Pri návrhu bude potrebné počítať minimálne s týmito požiadavkami (okrem tých čo sú uvedené pre L1 vrstvu a v celkovej metodike vývoja):

• Dátový model bude navrhnutý ako dimenzionálny s potrebnou úrovňou denormalizácie dátového modelu. Bude obsahovať detailné, prípadne aj agregované dáta. Nepredpokladá sa však ukladanie dát v štruktúre výstupných reportov.

Výstupná vrstva (OUT)

Výstupná vrstva je obdobou „Prezentačnej vrstvy“, dáta sú však organizované do dátových štruktúr, ktoré sú požadované na výstupe odoberajúcim systémom, resp. externým užívateľom (open data, ECB, iné inštitúcie, Off loading do DataLake a pod.). Táto štruktúra teda nemusí spĺňať princípy pre modelovanie analytických dát pre reporting, je podriadená špecifickým požiadavkám následného použitia, resp. zverejnenia.

Z tejto vrstvy sa generujú výstupné extrakty pre distribúciu (disemináciu).

Podobne ako stage vrstva je definovaná dokumentom „Interface Agreement“ (Dohoda o extrakcii), tak OUT vrstva musí byť definovaná a dohodnutá cez dokument „Dohoda o poskytnutí dát z DWH“. Podobne ako dokument „Dohoda o extrakcii“ musí byť dokument popisujúci OUT vrstvu podpísaný oboma stranami dátovej komunikácie.

Dáta v OUT vrstve sú tvorené ETL procesmi z transakčnej vrstvy, ale aj z dát prezentačných datamartov.

DWH SandBox

DWH SandBox je dohodnuté miesto tvorené špeciálnym používateľom, ktorý má právo:

1. čítať dohodnuté dáta z DWH/DL

2. vytvárať nové tabuľky a pohľady

3. napĺňať tieto tabuľky

4. vymazávať dáta a celé objekty

5. pre pokročilých používateľov aj vytvárať procedúry a iné programy, ktoré môžu slúžiť na spustenie časti ETL a napr. pre overenie určitej hypotézy.

Sandbox nemá slúžiť na pravidelné prevádzkovanie časti spracovania DWH/DL. Pokiaľ je používateľ spokojný z pokusom je veľmi dôležité zapojiť IT do finálnej optimalizácie a zaradenia do pravidelného (denného) behu vytvorenej novej časti spracovania.

DataLake časť NBS DWH

Úvod

Podobne ako pri návrhu relačnej časti DWH musia tieto predpoklady platiť pri vývoji DataLake. Nasledujúce podkapitoly popisujú úlohu DataLake platformy v navrhovanej architektúre.

Obrázok 15: DWH DataLake vrstvy a jej toky dát

Dátové vrstvy DataLake budú logicky rozdelené na niekoľko vrstiev tak ako v prípade logického členenia dátových vrstiev DWH. Dátové vrstvy DataLake platformy môžu kopírovať aj DWH model.

Landing zóna

Dáta nachádzajúce sa v tejto oblasti obsahujú 1:1 informácie zo zdrojových systémov. Dáta sa môžu nachádzať buď vo forme tabuliek (štruktúrované dáta exportované zo zdrojových DB) alebo vo forme RAW súborov rôznych formátov pripravených na ďalšie spracovanie. Dáta môžu prichádzať buď inkrementálne alebo vo forme celkových snímok.

DataLake by mal poskytovať mechanizmy na import dát z nasledujúcich typov zdrojových systémov:

• Databázové (za použitia JDBC/ODBC).

• Súborové (možnosť stiahnuť dáta z externého SFTP, interného SFTP , alebo interného Sharepoint SSL úložiska (časť dát z externých inštitúcii, kde sa momentálne využíva protokol WebDAV sa presunie na zabezpečené Sharepoint SSL úložisko).

• API + WEB (možnosť importovať dáta dostupné cez API rozhranie (SOAP/REST), alebo dát dostupných za použitia parsovania public webu).

Podobne musí DataLake umožňovať priamo zapisovať dáta do Landing zóny iným ETL nástrojom.

Primárna stage

Dáta nachádzajúce sa v tejto oblasti obsahujú informácie, ktoré boli spracované z Landing vrstvy. Dáta v tejto vrstve majú vopred určenú štruktúru na základe biznisových a technických požiadaviek (vo forme tabuliek/partícií alebo dátových súborov). Dáta v tejto vrstve už nemusia obsahovať všetky informácie, ktoré boli exportované zo zdrojových systémov. Typickým príkladom v prostredí NBS môžu byť rozsiahle XML súbory, ktoré sú exportované zo zdrojových systémov, pričom len malé množstvo atribútov je následne procesovaných vo vyšších vrstvách. Pred vstupom dát do Primárnej stage vrstvy sú dáta kontrolované na dátovú kvalitu a transformované do finálnej podoby. Čiže hlavné transformácie dát spracúvaného obdobia zo zdrojových štruktúr do štruktúr Landing integračnej vrstvy sú:

• Štandardizácie/unifikácie dát

• Technických kontrol dátovej kvality

• Ošetrenia default hodnôt

• Výpočet spoločných odvodených údajov

• Historizácie dát v Primárnej stage

Dáta z primárnej stage vrstvy môžu byť exportované do iných systémov pre potreby ďalšieho spracovania.

Discovery

Dáta nachádzajúce sa v Discovery vrstve obsahujú spracované dáta pripravené na použitie pre analytické a štatistické potreby. Tieto dáta sú obohacované a transformované na základe biznisových a technických požiadaviek ETL procesmi, ktoré zabezpečujú potrebnú kvalitu dát.

Transformácia dát spracúvaného obdobia zo zdrojových štruktúr Primárnej stage do Discovery analytickej vrstvy prebieha najmä z dôvodu:

• Denormalizácie dát

• Dodatočných výpočtov

• Optimalizácie pre reporting (napr. materializácie výpočtov, ich joinov a agregácií)

• Historizácie dát v Discovery vrstve podľa konkrétnej analytickej potreby

Štatistické a analytické nástroje využívajú primárne dáta z tejto vrstvy na vytváranie analýz a reportov.

DataLake Sandbox

DataLake platforma by mala umožňovať dátovým vedcom vytváranie “sandboxov“ pre potreby importovania a manipulácie aj väčšieho množstva dát. Výhodou takýchto “sandboxov“ je možnosť spájania externých dát s dátami, ktoré sú dostupné v DataLake platforme bez nutnosti zapojenia IT. Platforma by mala poskytovať jednoduché rozhranie, ktoré by dátovým vedcom umožňovalo import externých dát v podobe súborov a možnosť nad takto importovanými súbormi vytvárať databázové tabuľky, poprípade používať tieto súbory pre účely analýz za použitia programovacích/štatistických jazykov. DataLake platforma by mala umožňovať pri analyzovaní takto importovaných súborov využívať celkový výpočtový potenciál platformy.

Dáta v sandboxoch by mali byť logicky oddelené a nemali by byť súčasťou dát v Discovery vrstve.

Informačná bezpečnosť

Autentifikácia používateľov

Systém musí zabezpečiť jednoznačné overenie používateľa pred akýmkoľvek prístupom. Požiadavky na autentifikáciu:

• Každý používateľ musí mať jedinečný prístupový identifikátor/užívateľské meno (UID)

• Autentifikácia sa bude riadiť autentifikačnými štandardami NBS, je nutné predpokladať, že bude použitá dvojfaktorová autentifikácia

• Každý užívateľ sa musí autentifikovať minimálne pomocou UID a hesla.

• Heslá musia byť v systéme uložené tak aby boli nedešifrovateľné

• Systém by mal ponúkať možnosť napojenia na SSO riešenie

Prístup k dátam

Systém musí poskytnúť možnosť na riadenie prístupov na všetkých úrovniach technickej architektúry. Aplikované postupy a princípy riadenia oprávnení používateľov budú zdokumentované v relevantnej dokumentácii riešenia.

Prístup k dátam musí byť definovateľný:

• Na úrovni rolí jednotlivých používateľov minimálne pomocou riadenia prístupu k jednotlivým entitám dátového modelu pre analytické role.

• V systéme sú identifikované nezlučiteľné role a oprávnenia. T. z. sú definované také role alebo oprávnenia, ktoré nemá mať pridelený jeden používateľ alebo správca.

• Riadenie prístupu k objektom. V rámci technického riešenia očakávame dve riešenia:

  • Security Framework pre relačnú časť - riadenie prístupu na úrovni DB objektov

    • Riadenie prístupu k záznamom (riadková bezpečnosť)

    • Riadenie prístupu k informačným typom (stĺpcová bezpečnosť) najmä z dôvodu zavedenia chránenia citlivých dát

  • DataLake nástroj pre možnosť granulárnej konfigurácie oprávnení pre adresáre a súbory uložené v HDFS z grafického rozhrania.

    • Z hľadiska riadenia prístupu k citlivým dátam uložených v DataLake bude vypracovaný v rámci bezpečnostného dokumentu postup ako modelovať „dátový model“ DataLake, aby spĺňal požiadavku ochrany citlivých dát.

• Osobitné oddelenie manažmentu rolí a prideľovania oprávnení užívateľom

Pri komunikácii PowerBI reporting nástroja s Relačnou časťou DWH požadujeme, aby nástroj preberal nastavenia práv viditeľnosti dát z tejto časti DWH. Vytvorenie špeciálnej vrstvy v DWH len za účelom poskytnutia zabezpečenia dát sa nám javí ako nebezpečné, t. j. neúplné a netransparentné z pohľadu riadenia prístupu a viditeľnosti dát.

Logovanie používateľských aktivít

Systém musí zabezpečiť záznam všetkých používateľských aktivít ohľadne prístupu k dátam (databáza, DataLake). Zo záznamov by malo byť spätne identifikovateľné kto, kedy a k akým dátam pristupoval. Záznam by mal obsahovať minimálne:

• Dátum a čas operácie

• Identifikátor používateľa

• Názov a adresa pracovnej stanice užívateľa

• Vykonaná operácia a/alebo dátová požiadavka (napr. kópia SQL príkazu)

• Úspech/neúspech vykonanej operácie

Používateľské biznis frameworky musia zachytávať minimálne nasledovné udalosti:

• Prihlásenie/odhlásenie užívateľa

• Používateľský prístup k dátam

• Aktivita

Prístup k správe logov musí byť nasledovný:

• V logoch nie je možné ukladať citlivé informácie.

• Riadený prístup k logom systému (t. j. na základe prístupový práv)

• Minimálne udalosti popísané hore musia byť propagovateľné cez API do bezpečnostného systému NBS, ktorým je SIEM.

Návrh aplikačnej vrstvy

Návrh aplikačnej vrstvy DWH musí spĺňať tieto požiadavky:

• Komponenty systému sú umiestnené on-premise, t. j. komponenty nesmú byť umiestnené x xxxxxx.

• Komponenty systému sú konfigurované v súlade s vhodným bezpečnostným štandardom (hardening), napr. CIS benchmark. Odchýlky od zvoleného štandardu musia byť zdokumentované a zdôvodnené.

• V prípade realizácie bezpečnostného testovania poskytne uchádzať súčinnosť a odstráni na vlastné náklady identifikované zraniteľnosti.

• Včasné nasadzovanie bezpečnostných opráv vydaných výrobcami jednotlivých komponentov systému, ktoré dodáva v rámci projektu uchádzač.

• Systém umožní zálohovať konfiguráciu komponentov a údajov:

  • Všetky metadáta a konfigurácie aplikačných frameworkov musia byť uložené v DWH databáze pre jednoduché (synchrónne) zálohovanie.

  • Ak niektoré konfigurácie sú uložené priamo v súborovom systéme serverov (napr. DataLake), toto uloženie musí byť jasne a presne zdokumentované.

• Komunikácia používateľov aj správcov s komponentami systému musí byť realizovaná bezpečným komunikačným kanálom, t. j. komunikácia cez webové rozhranie, komunikácia "tučného" klienta, vzdialený prístup správcov do OS a pod.

• Komunikácia samostatných komponentov systému musí byť realizovaná bezpečným komunikačným kanálom.

• Komunikácia systému s inými systémami (externými alebo internými, s databázou, mailovým serverom, doménovými radičmi a pod.) musí byť realizovaná bezpečným komunikačným kanálom.

• Použitie štandardov pre bezpečný vývoj.

Iniciálny load

Pre každú tabuľku DWH v transakčnej vrstve bude zabezpečený tzv. „iniciálny load“ - prvotné nahratie kompletného obrazu dát zo zdrojového systému. To môže obsahovať aj historické položky číselníkov a kmeňových dát, ak existujú, prípadne historické transakcie a snímky, ak ich daný systém udržiava v produkčných tabuľkách (veľmi často teda ide napr. o historické transakcie - k nim musia byť dohraté aj relevantné referenčné a kmeňové dáta, aj keď dnes už nemusia byť aktívne - dlhopis, platobná karta, subjekt).

Zvyčajne sa nerekonštruujú historické stavy statických, resp. pomaly sa meniacich dát, ak tieto zmeny neobsahuje aj samotný zdrojový systém vo svojich základných zdrojových štruktúrach.

Migrácia dát z projektu Pilot DWH

Nie je vyžadovaná migrácie dát z riešenia Pilot DWH do nového riešenia.

Metodika fyzického vývoja a inštalácie na produkciu

Z dôvodu zabezpečenia bezpečnej prevádzky a ochrany údajov v DWH budú požité na vývoj, testovanie a samotnú prevádzku 3 prostredia:

• DEV – development prostredie, jeho charakteristiky:

  • málo dát,

  • anonymizované, alebo vybratá reprezentatívna vzorka, ktorá ale neporušuje predpisy ochrany údajov

  •  vykonanie systém testov

• TEST – testovacie prostredie, jeho charakteristiky:

  • väčšie množstvo dát pre vykonanie určitých performance testov

  • vykonanie integračných testov

  • úvodné UAT testy biznis používateľov

• PROD – produkčné prostredie

  • záverečné UAT testy biznis používateľov

  • bežná prevádzka

Vývoj bude prebiehať v nasledujúcom predpise:

• DEV prostredie je plne R/W. Vývoj bude prebiehať pre ETL/Workflow len nastavením metadát. Nie je dovolené používať PL/SQL procedúry pre ETL úlohy. Všetky aplikačné PL/SQL procedúry musia byť uložené ako metadáta (anonymné bloky) vo workflow frameworku, kde majú svoju historickú verziu a metadáta dôvodu vzniku.

• TEST prostredie je plne R/W ale v koordinácii s DEV. Prostredia musia byť synchronizované pravidelne na metadátovej úrovni. ETL/Workflow, ktorý je vo vývoji bude mať metaznačku.

• PROD prostredie je čisté R/O prostredie pre metadáta. Prenos z TEST do PROD sa vykoná cez inštalačný balíček. Zápis do metadát ETL/Workflow je možný len počas riešenia produkčného incidentu 1. stupňa (hot fix). Pri iných riešeniach incidentov bude použitý štandardný postup DEV->TEST->PROD.

Pri fyzickej inštalácii jednotlivých častí diela požadujeme dodržať:

• Všetky dodané UI budú podporovať prehliadač Chrome, ktorý je štandardom v NBS prostredí. Okrem výnimiek popísaných nižšie.

• Všetky metadáta frameworkov budú uložené v DWH relačnej časti. Okrem presne dohodnutých a NBS vopred odsúhlasených oblastí (napr. pre DataLake, ale aj tu požadujeme dohodu a preferujeme použiť DWH relačnú časť pred iným riešeniami). Názvoslovie technických používateľov dodá NBS.

• Fyzická implementácia bude na HW a SW ako je popísaný vyššie (popis je vo Fyzickej infraštruktúre).

• Pre inštaláciu riešenia nebude potrebný Admin alebo Root alebo iný super používateľ. Okrem presne striktne vopred dohodnutých postupov, ktoré musia byť vopred (čiže na začiatku projektu) oznámené, spísané v dokumentácii a NBS schválené.

Nástroje na podporu prevádzky

Súčasťou dodávky budú aj aplikácie a nástroje na podporu prevádzky DWH, novo vznikajúcich procesov a zjednodušenie/sprehľadnenie práce odborných používateľov. Najmä požadujeme adresovať tieto oblasti či procesy:

• Podporu správy, riadenia a monitoring aktualizačných úloh (Workflow Management – Data Orchestration).

• Správa číselníkov, mostíkov, referenčných dát, hierarchií jednotlivých dimenzií a manuálnych vstupov.

• Bezpečné nahrávanie veľkého počtu a rôznych súborov, t. j. všetky a práve raz (Ingestion framework).

• Správa dátovej kvality - automatické spúšťanie a vyhodnocovanie testov.

• Správa prístupov (riadenie bezpečnosti) k dátam.

• Správa dokumentácie k DWH a iných metadát (o modeli, o reportoch, mapovaní zdroj-cieľ).

• Riadenie dátovej retencie.

Tieto nástroje budú dodané a nasadené v kontextu implementácie platforiem DataLake a DWH, ale rozsah ich využitia by nemal byť v budúcnosti obmedzený iba na tieto platformy. Tieto nástroje by mali byť schopné aplikovať potrebné koncepty a procesy aj v rámci ďalších systémov NBS.

Workflow Management – Data Orchestration

Kvalitné riadenie a správa aktualizácie dátového skladu je jedným z kritických ukazovateľov úspešnosti implementácie dátového skladu. Len aktualizácia, ktorá dáva presný obraz o svojom behu dáva dôveru biznis používateľovi, že dáta uložené v dátovom sklade sú korektné a pripravené spracovanie v reportoch. Preto takýto framework musí umožňovať:

Nastavenie kalendára a času spustenia jednotlivých úloh

Riadenie závislostí (dynamické zapínanie a vypínanie)

Error handling – znovu spustenie, nastavenie chybovej vetvy behu

Manuálne spustenie úlohy

Nastavenie cyklického spracovania dát

Riadenie heterogénneho prostredia, t. j. ako relačnej časti DWH, tak aj DataLake časti

Logovanie behu úloh

Analytiku nad logmi behov jednotlivých úloh

Nastavenie používateľských práv a prístupov

Riadenie prístupu do aplikácie cez login modul napojeného na NBS LDAP/AD.

Webové rozhranie použiteľne v prehliadači Chrome, ktorý je štandardom v NBS prostredí. Editor metadát môže byť riešený ako inštalovaná aplikácia vo MS Windows 10 prostredí.

Všetky metadáta uložené v databáze s prehľadným API

Framework je možné rozdeliť do viacerých logických celkov:

1. Požiadavky na editovanie metadát schedullera/workflow manažéra:

   1. Vytváranie/Vymazávanie úloh

   2. Prioritizácia úloh

   3. Rozdelenie úloh do vertikálnych a horizontálnych skupín, presun existujúcej úlohy medzi skupinami, možnosť riadenia skupín samostatne

   4. Možnosť definovania parametru pre maximálny paralelný beh jednotlivých úloh v rámci skupiny

   5. Rozdelenie úloh na automaticky spúšťané podľa kalendára, manuálne spúšťané, alebo automaticky v definovaných cykloch

   6. Definovanie závislostí medzi úlohami v heterogénnom prostredí (PL/SQL, ODI, JAVA, WebService, ShellScript a iné)

   7. Možnosť definovania závislosti aj medzi úlohami v rôznych skupinách

   8. Možnosť zapínať a vypínať jednotlivé skupiny (zaradenie a vyradenie z denného behu).

   9. Možnosť definovania anonymného bloku SQL namiesto zavolania externej úlohy

   10. Definovanie kalendára

   11. Vyhľadávanie v metadátach (Fulltext, podľa definovaných polí) a vložených anonymných blokov SQL

   12. Verzionovanie zmien, vyhľadávanie v zmenách, porovnanie verzií a detailné zobrazenie rozdielov

   13. Logovanie používateľských aktivít

   14. Nastavenie prístupových práv používateľov pre právo tvorby metadát podľa vertikálnych a horizontálnych skupín, t. j. môže existovať používateľ, ktorý má len právo čítať všetky metadáta

   15. Podpora spolupráce medzi používateľmi:

       1. Check-in/check-out metóda (nutnosť riešiť problematiku hraničného prípadu nečakaného pádu aplikácie a automatického check-out po stanovenej časovej hranici – napr. 4 hodiny nečinnosti).

       2. iný používatelia uvidia v GUI, že daný uzol ETL je v režime check-in (uzamknutý)

       3. vkladanie poznámok

   16. Vkladanie metadát pomocou predpripravených šablón. T. j. pri vkladaní uzla úlohy do stromu závislostí úloh sa napríklad:

       1. automaticky vytvoria podúlohy na riadenie chybových stavov pre reštart a samoopravu preddefinovaných chybových stavov

       2. pre rôzne typy úloh (ODI, SQL, Ozee, Nifi, ...) sú povinné iné nastavenia, ktoré definuje šablóna

       3. možnosť doplnenia šablóny (pridať ďalšiu funkcionalitu vkladania uzla do stromu závislostí) prostredníctvom plugin, t. j. bez nutnosti novej verzie aplikácie (GUI)

   17. Základný monitoring behu úlohy:

       1. Prehľad logu behu, vyhľadávanie v správach, filtrovanie len chybových správ

       2. Stav predchodcov – analýza zisťovania, prečo sa úloha ešte nespustila

       3. Reporting konzumácie pamäťových častí servera – TEMP, PGA

   18. Ak je úloha volaná do ODI agenta, tak editor by mal mať možnosť zobraziť metadáta ODI (aj cez verzie) a tiež generovaný SQL skript systémom ODI na kontrolu kvality skriptov

   19. Základné vlastnosti uzla úlohy:

       1. Id, meno

       2. Typ úlohy (SQL, PL/SQL, UNIX shell script, JAVA volanie, ODI volanie, WebService volanie)

       3. Čas spustenia – ak nie je zadaný, spustí hneď ako sú splnené závislosti

       4. Čas pozdržania pri chybe pre vyskúšanie samoobnovy. Ak je definovaná chybová vetva spustenia, tá sa spustí okamžite. Tento parameter sa ignoruje

       5. Parametre uzla – context spustenia (vstupy pre ODI, bankový deň, prostredie, používateľ)

       6. Závislosti na predchodcov a nasledovníkov

       7. 32kB freetext pre skript

   20. GUI pre editovanie metadát by malo jednotlivé uzly ETL procesu vedieť zobraziť ako stromovú štruktúru (podobne ako súborový prehliadač v MS Windows):

       1. podľa vertikálnych a horizontálnych skupín

       2. závislostí a vedieť sa v závislostiach pohybovať cez prelinky (predchodcovia, nasledovníci)

       3. možnosť zobrazenia viacerých editačných okien pre viacero uzlov naraz

       4. možnosť hromadného zavretia nepotrebných okien

2. Požiadavky pre RunTime časť:

   1. Automatická príprava default kalendára (ak neexistuje konkrétny pre daný deň) a plánu spustenia úloh, t. j. RunTime vytvorí dennú kópiu metadát, ktoré bude postupne spúšťať

   2. RunTime časť by mala používať DBMS_SCHEDULER balíček DWH relačnej časti a to z dôvodu riešenia hraničných stavov počas pádu celej databázy a transparentného nábehu.

   3. Spúšťanie úloh podľa kalendára, závislostí a stavov (zaradenie a vyradenie) ich skupín. Úloha sa môže pustiť len práve raz a včas.

   4. Automatická reštartovateľnosť úlohy pri definovanej chybe

   5. Automatická prioritizácia úloh podľa výsledku behu

   6. Úlohy, ktoré nemajú definovaný presný čas spustenia, sa spustia okamžite po dobehnutí všetkých jej predchodcov.

   7. Cyklická úloha ak náhodou bežala dlhšie ako bol definovaný čas dĺžky cyklického samospustenia, sa spustí okamžite ako skončí. Za predpokladu, že nemá iné závislosti.

   8. Logovanie behu

   9. Manažment Runtimu nesmie zaťažovať server nadmiernou aktivitou. Toto bude overené cez AWR reporting.

   10. Manažment Runtimu nesmie vykazovať v relačnej časti DWH žiadne LATCH, alebo DEAD LOCK. Zamykanie metadát musí byť maximálne na úrovni 1% behu všetkých úloh. Bude merané cez AWR reporting.

3. Požiadavky pre sledovanie, kontrolu a riadenie behu (monitoring):

   1. GUI podporujúci admin konzolu pre bežný dohľad - Celkový pohľad na end-to-end spracovanie z jedného miesta

   2. Sledovanie stavu behu ETL:

      1. na najvyššej úrovni v near-online režime (+/- 5 minút)

         1. stav kontrolných bodov (počet úloh do dosiahnutie cieľa; percento spracovania; linka na úlohu, ktorá blokuje beh);

         2. celkový pohľad na stav skupiny úloh

         3. počet aktuálne chybných úloh

         4. zoznam posledných 10 úloh, ktoré boli v chybe

         5. kontrola behu podľa tradičného (vážená snímka minulosti) behu

         6. Xxxxx a reporty s podporou drill-down na detailné zobrazenia.

      2. Detailný pohľad na stav úlohy v reálnom režime s funkcionalitou:

         1. Pozastaviť úlohu

         2. Znovu spustiť

         3. Úplne zastaviť

         4. Zrušiť beh – t. j. strom nasledujúcich úloh sa rozbehne ako keby úloha dobehla korektne

         5. Dátum čas spustenia, ukončenia úlohy

      3. Detail ETL úloh:

         1. Sledovanie logu a kódu, ktorý zbehne/zbiehal (SQL, ODI, OOZEE, ...)

         2. Nastavenia úlohy – tradičný čas behu, v akej skupine sa úloha nachádza a podobne.

         3. Prechádzať na nasledujúcu/predchádzajúcu úlohu

      4. Zobrazenie kritickej cesty pre zvolenú úlohu a zvolený deň spracovania so zobrazením časov behu aktualizácie, dĺžky jednotlivých úloh a meškaní (predbiehaní) oproti tradičnému behu.

      5. GUI pre manuálny štart neautomatizovaných úloh s možnosťou zadania parametrov

      6. Analýza štatistík o spúšťaní jednotlivých úloh v histórii až 180 dní v dvoch grafoch:

         1. Časy spustenia a dokončenia úlohy s porovnaním na tradičný beh. Ak úloha sa reštartovala z dôvodu chybového stavu je zobrazený minimálny čas spustenia a maximálny čas dobehnutia.

         2. Dĺžka behu úlohy s porovnaním na tradičný beh. Ak úloha sa reštartovala z dôvodu chybového stavu je zobrazený len posledný úspešný beh.

      7. Analýza dohodnutej SLA o dobehnutí ETL úloh

   3. GUI podporujúci zjednodušenú konzolu pre kontrolný dohľad, napr. vybraným biznisovým používateľom

   4. Manuálna reštartovateľnosť úloh v prípade poruchy – schopnosť nadviazať na už vykonané úlohy

   5. XXX pre spustenie výpočtu tradičného (vážená snímka minulosti) behu

   6. Notifikácie (e-mail) v prípade dobehnutia alebo chybových stavov spracovania

   7. Definovanie kontrolných bodov a reporting na sledovanie dosiahnuteľnosti týchto kontrolných bodov:

      1. Počet úloh, ktoré musia zbehnúť v tomto behu na dosiahnutie kontrolného bodu

      2. Predpokladaný čas na dosiahnutie kontrolného bodu

      3. Tradičný čas na dosiahnutie kontrolného bodu

      4. Indikátor (smerník) na úlohu, ktorá práve blokuje dosiahnutie kontrolného bodu

      5. Graf času dosiahnutia kontrolného bodu v histórii až 180 dní

4. procedúry pre logovanie a samotné logovacie tabuľky:

   1. Popísané API na jednotné logovanie

   2. Integrované API (VIEW) pre čítanie ODI logov

   3. Existencia API pre zasielanie informácií do centrálneho monitoringu IT prostredia (položky ako v bode 3.g. bez grafu)

Riadenie spracovania dát v prostredí NBS bude riešené jedným spoločným nástrojom, ktorý bude dostatočne technologicky zdatný dizajnovať, spúšťať a administrovať tok spracovania cez rôzne technické platformy. Táto požiadavka zabezpečí, že jednotlivé kroky dátového spracovania bude možné vykonávať na rozdielnych platformách, čo bude mať za dôsledok efektívnejšiu správu zdrojov nad platformami.

Správu číselníkov, mostíkov, referenčných dát a hierarchií

Pre klasifikáciu údajov v DWH/BI je možné vychádzať z číselníkov a klasifikácií, ktoré sú poskytované zdrojovými systémami ako súčasť jeho natívneho dátového modelu.

Pre reporting však vznikajú aj požiadavky na triedenie dát podľa odvodených charakteristík, prípadne unifikovaných klasifikácií, ktorých kódovníky nie sú v zdrojových systémoch k dispozícii, resp. zdrojové systémy neposkytujú potrebné údaje (napr. užívateľské hierarchie, súčtové prvky, príznaky, deskriptívne názvy a pod.).

Na správu týchto rôznych číselníkov a sú základom pre kvalitný reporting, je nevyhnutné mať viac ako menej rôznych formulárov, ktoré podporia:

• Správa referenčných dát a hierarchií údajov.

  • číselníky / kódovníky

  • klasifikácie a iné malé dimenzie

  • definície hierarchie

  • lookup tabuľky pre konsolidáciu číselníkov a ich obohatenie o dodatočné informácie (popisy, príznaky)

• Správa konverzných mostíkov (napr. aj pre potreby ETL – transformácia technických transakcií na biznisové definície pre niektoré hviezdicové schémy):

  • parametre (zoznamy, podmnožiny hodnôt) používané v rozhodovacej logike spracovania dát

  • rozhodovacie tabuľky pre odvodenie dát a aplikáciu obchodných pravidiel pri spracovaní dát v DWH

• Udržovanie nastavení DWH metadát – napr. spôsob distribúcie niektorých automatických reportov cez e-mail a podobne.

• Manuálne vstupy statických dát malého rozsahu, ktoré nie sú primárne uložené a obhospodarované v inom systéme

Tento systém by mal poskytovať minimálne tieto funkcie a nástroje pre správu referenčných dát:

• umožniť používateľom (odborným aj technickým) modifikovať referenčné dáta cez jednoduchý GUI formou selfservice:

  • pridanie nového záznamu (ak je používateľ oprávnený)

  • odstránenie záznamu (ak je používateľ oprávnený)

  • zneplatnenie záznamu (ak je používateľ oprávnený)

  • editácia záznamu (ak je používateľ oprávnený)

  • podpora triedenia, filtrovania, pop-up nápovedy

  • podpora master-slave dát, x. x. xxxxxxxxxx dát v drop-down/pickliste z master objektu

  • možnosť nastaviť niektoré (definovateľné) stĺpce ako R/O (len na čítanie)

  • možnosť exportu dát do dohodnutého formátu - CSV, XSL, JSON.

  • v závislosti od návrhu číselníkov mať možnosť nastaviť platnosť dát

• všetky dáta a metadáta budú uložené v technickom používateľovi v Relačnej časti DWH. ETL DWH bude tieto dáta aktualizovať pravidelna počas ETL procesov v dennom režime a micro-batch režime v priebehu dňa - napr. pri zmene v dátach, rovnako ako pre Relačnú časť tak aj pre DataLake.

• riadiť prístup k jednotlivým referenčným dátam s autentifikáciou a autorizáciou užívateľov k jednotlivým referenčným dátam

• auditovať všetky akcie a verzovať zmeny v záznamoch s časovými značkami

• umožňovať definíciu nových referenčných dát s validáciami vstupných dát (minimálne na doménovú a referenčnú integritu)

• sprístupniť dáta pre ETL proces cez definované rozhranie

• poskytne mechanismus pre notifikáciu resp. spustenie micro-batch spracovania v prípade zmeny v dátach

• poskytovať online služby pre ostatné aplikačné systémy, ktoré chcú svoje referenčné dáta delegovať na RDM, t. j. systém bude vedieť vystaviť REST API pre definovaný číselník s funkciou READ vo formáte JSON.

• vytváranie číselníkov (pridávanie nových referenčných štruktúr) bude s podporou a prístupom low-code/no-code (bez softvérového vývoja), všetky parametre číselníkov musia byť uložené v metadátach.

• automatická notifikácia cez e-mail definovanému odbornému pracovníkovi, ak nastane nejaká udalosť v číselníku (napr. vloženie nového záznamu s default hodnotou)

• Webové rozhranie použiteľne v prehliadači Chrome, ktorý je štandardom v NBS prostredí.

• Riadenie prístupu do aplikácie cez login modul napojeného na NBS LDAP/AD.

Riešenie RDM bude koncipované ako „s úložiskom priamo v DWH“ s možnosťou batchovej či okamžitej synchronizácie do DWH/DataLake. Rovnako musí prostredie RDM poskytnúť REST API pre prístup k dátam iným aplikačným systémom.

Manuálne vstupy – selfservice pre používateľov

Táto požiadavka rozširuje požiadavku pre GUI RDM pre “Manuálne vstupy statických dát malého rozsahu” a funkcionalitu vytvorenia importného medzikroku na kontrolu dátovej kvality importovaných dát na základe zadefinovaných pravidiel.

Proces manuálneho importu používateľom bude následne vyzerať (navyše okrem štandardnej RDM funkcionality):

• Importované dáta zo známeho a predom dohodnutého formátu sú transformované (rozšírené o mapované dohodnuté dimenzie) do medzipamäte

• XXX zobrazí stav importu s tým, že chybné dáta sa zobrazia červenou farbou. Chybné dáta budú rozoznateľné cez nastavené pravidlá:

  • neexistuje JOIN na číselník

  • hodnota je mimo definovaný povolený rozsah

• GUI nemusí mať podporu na opravu týchto dát

• Po kontrole a správnom nastavení všetkých riadkov sa importný balík označí metaznačkou v STAGE vrstve DWH

• Importovacie GUI musí obsahovať sumárny report (súbor, kedy, stav, počet chýb, atď.) pre sledovanie importnej činnosti priamo používateľom.

• Webové rozhranie použiteľne v prehliadači Chrome, ktorý je štandardom v NBS prostredí.

• Riadenie prístupu do aplikácie cez login modul napojeného na NBS LDAP/AD.

Ingestion framework - nahrávania veľkého počtu rôznych súborov

Súčasťou DWH/DL platformy by mal byť Ingestion framework, ktorý by primárne zabezpečoval importovanie externých zdrojov do Stage Zóny platformy. Externé zdroje sú dostupné prostredníctvom API rozhraní, parsovania public  webových stránok alebo sťahovania dát zo vzdialených SFTP serverov mimo alebo v NBS infraštruktúre. Spracovanie Ingestion frameworku musí byť riadené prostredníctvom Workflow managera.

Požiadavky na Ingestion Framework :

• Schopnosť pridávania nových externých zdrojov do frameworku:

  • SOAP/REST API, parsovanie Web stránok, SFTP, Xxxxx, JDBC, súborový systém, MS Sharepoint, HDFS

• Možnosť nastavenia odkladania spracovaných dát na „archívne“ miesto

• Možnosť nastavenia vymazania zdroj dát

• Schopnosť metadátovo definovať parser čítača pre známe formáty ako je CSV, AVRO, JSON , XML, DBF a podobne.

• Schopnosť priamo čítať ZIP na vstupe

• Schopnosť metadátovo definovať mapovania zdroj-cieľ (low-code/no-code programovanie)

• Schopnosť priamo počas spracovania dát tieto dáta obohacovať o iné dáta definovanou reláciou na mapovacie dimenzie.

  • toto obohacovanie a transformácia dát má prebiehať nezávisle od zdroja a formátu dát aj s možnosťou zmeny zdroja bez nutnosti úpravy transformácií

  • schopnosť spracovať transformácie in-memory

  • relácie môžu byť definované aj ako best-match (hľadaj najbližší najlepší), t. j. nie je nutné mať definované tvrdé 1:1 prepojenie

  • mapovania by mali byť definovateľné deklaratívne spôsobom low-code

• Spúšťaný z centralizovaného Workflow managera.

• Schopnosť importovať len inkrementy dát pričom Ingestion framework by mal byť zodpovedný za udržiavanie kompletného prehľadu o už spracovaných dávkach. T. j. musí mať mechanizmy ako spracovať „práve raz a všetky“ vstupné zdroje. napr. pri zdroji so súborového systému je možné definovať spracovanie cez masku súboru. Framework vyberie a spracuje len tie súbory, ktoré vyhovujú nastaveniu. Pri iných typoch zdrojov sú to iné nastavenia, ktoré podporia požiadavku udržania kompletnosti spracovania.

• Spracovanie musí byť kontrolované, auditované a reportovateľné – interface, beh, čas, počet spracovaných vstupných riadkov, počet výstupných riadkov, počet chybových riadkov, počet zahodených riadkov z dôvodu duplicita a atd.

• Udržiavať si metadáta o externých zdrojoch (API kľúče, mená, heslá, tokeny, logy, aktuálny stav spracovania + v prípade inkrementálneho spracovania všetky potrebné informácie potrebné pre stiahnutie ďalšieho inkrementu, počty exportovaných záznamov pre každé spustenie)

• Schopnosť spracované dáta uložiť cez JDBC do STAGE DWH, alebo cez HDFS konektor priamo do zóny DL.

• Schopnosť robiť tzv. multi-insert, t. z. keď vstupný tok dát obsahuje viac rôznych dátových formátov, tak dodaný framework tieto formáty bude vedieť rozoznať a uložiť do rôznych cieľových objektov v rôznych technológiách, t. j. či DataLake, alebo Relačná časť DWH.

• Schopnosť v cykle vyčítať jednotlivé záznamy z WebService, kedy nie je možné vyčítať všetky záznamy, ale je nutné volať WebAPI cez parameter. Zoznam všetkých hodnôt parametrov bude si framework vedieť prečítať z databázovej tabuľky, ktorá bude metadátovo nastaviteľná pre každé vlákno zvlášť.

• Schopnosť odložiť chybné záznamy počas spracovania do iného dohodnutého objektu na ďalšiu analýzu. Túto schopnosť bude možné nastaviť metadátovo.

• Schopnosť identifikovať duplicity v dohodnutom spracovávanom okne a v rámci jedného streamu. Kontrolu duplicít bude možné nastaviť metadátovo.

• Podpora tvorby dokumentácie z kódu spracovania vo formáte HTML, PDF, Excel, API na vkladanie do databázy

• Rýchlosť spracovania (bez transformácie dát) na úrovni 1 milióna riadkov z XML súboru za 15 minút pri jednovláknovom spracovaní do Oracle DB na konfigurácii CPU podľa kapitoly 3.2.4.

• Detailné logovanie behu a spracovania:

  • Online monitoring a management procesov spracovanie cez JMX

  • Rozdelenie logov podľa typov a príslušnosti procesu. Detailné logy môžu byť vo file systéme servera

  • Jeden centrálny log (najlepšie v databáze) s integráciou na workflow manažér, ktorý hovorí o aktuálnom dni spracovania, ktorý súbor (alebo skupina súborov) je už spracovaný, či čaká na spracovanie a s akým výsledkom (počet vstupných, výstupných, odložených, chybných riadkov). Dátum čas začatia a skončenia procesu.

Prvý príklad použitia vyššie uvedených požiadaviek je čítanie dát z ESMA zdroja (xxxxx://xxx.xxxx.xxxxxx.xx/). Tento zdroj kategorizujú tieto atribúty:

• Veľký objem dát – rádovo stovky GB až desiatky TB

• Dáta sú vo formáte XML

• Súbory sú ZIPnuté

• Jeden súbor XML obsahuje viac podstromov

t. z., že je vyžadované pri tomto zdroji čítať priamo ZIP (nebude miesto na unzip), v pamäti parsovať XML, vyberať definované podstromy a robiť MULTI-INSERT do rôznych objektov v DWH bez rozdielu cieľa technológie, t. j. či DataLake, alebo Relačná časť.

Ako druhý príklad je ITMS2014 (xxxxx://xxxxxxxx.xxxx0000.xx/xxxxxxx/?xxxx/x0/xxxxxxx.xxxx) kde je nutné cez REST API vyčítavať informácie v cykle, kde nie je známe o aké a koľko dát pôjde. Tieto dáta budú ukladané podľa definície do rôznych (napr. /v2/ciselniky) alebo rovnakých tabuliek (napr. /v2/dodavatelia/{dodavatelId}). Niektoré vstupné vlákna obsahujú rozvetvené podstromy.

Tretí príklad je import dát z Katastrálneho úradu Slovenskej republiky. Tieto dáta po podpísaní zmluvy sa dajú stiahnuť v stanovený deň a čas zo zabezpečeného úložiska ako ZIP súbor, ktorý obsahuje niekoľko DBF (formát dBase) súborov. T. j. systém musí vedieť všetky a práve raz tieto súbory načítať do určených objektov. Pokiaľ sa nepodarí nahrať všetky súbory do cieľového stavu, musí framework vedieť generovať chybový kód na zastavenie behu vo Workflow managerovi.

Data Quality Management

Systém pre DQM (Prostredie pre správu, spúšťanie a vyhodnocovanie dátovej kvality) bude riešiť nasledujúcu funkcionalitu:

• Konfigurovať pravidlá pre meranie dátovej kvality (DQ indikátory)

• Organizovať pravidlá DQ do skupín a plánov ich spúšťania

• Spúšťať a plánovať spúšťanie vybraných skupín indikátorov

• Monitorovať výsledky meraní cez reporty a grafy

• Možnosť zasielať výsledky kontrol na e-mail - generovať podklady pre Data Quality Incident

• odkladanie chybných záznamov do špeciálnych tabuliek pre následnú kontrolu a riešenie incidentov

• zastavenie ETL procesu pri prekročení hraničného počtu chýb

• zakomponovanie spustenia DQ kontroly do procesu ETL – ako samostatný krok spracovania

Tento systém bude pripojený na DWH, nad ktorým bude prebiehať meranie indikátorov kvality cez rôzne dátové vrstvy. Riešenie by malo obsahovať komponenty pre podporu riadenia dátovej kvality na úrovni:

• Technických kontrol – štandardné/generické kontroly vyplývajúce z dátového modelu

• Biznisový kontrol – užívateľsky definované parametre kvality na úrovni atribútov (data quality indikátory)

Technické kontroly by mali zahŕňať:

• Dátové typy

• Obmedzenia (Constraints) – povinné hodnoty, unikátnosť, referenčná integrita

• Doménové kontroly – validácia na prípustné hodnoty

• Kvalita zbehnutia SCD

Spúšťanie technických kontrol by malo byť integrálnou súčasťou ETL procesu.

Biznisové kontroly môžu byť voľne definované zo strany užívateľov (resp. Data Stewardov) vo forme tzv. indikátorov dátovej kvality (DQI), napríklad:

• hraničné (podozrivé) hodnoty atribútov

• neočakávané kombinácie hodnôt súvisiacich atribútov

• neočakávané vzory v dátach a pod.

Tieto indikátory môžu mať komplexnú definíciu, a teda môžu byť definované vo forme SQL dotazu.

Testovací framework

Testovací framework (softwarový komponent, ktorý je možné konfigurovať matadátami) predstavuje funkcie pre definíciu a automatizované spúšťanie a vyhodnocovanie testovacích scenárov cez rôzne prostredia. Typicky slúži na automatizované (alebo opakované) vykonávanie rôznych testovacích prípadov v rámci SDLC procesu, napr.:

• kontroly stavu prostredia

• funkčné testy (správne plnenie cieľových štruktúr)

• regresné testy

Framework by mal poskytovať minimálne tieto funkcie:

• repozitár testovacích skriptov (SQL)

• mechanizmus pre automatizované spúšťanie zvolených testovacích skriptov

• logovanie výsledkov testov a ich sprístupnenie pre vyhodnotenie (SQL, resp. v reportoch cez BI nástroj)

• Webové rozhranie použiteľne v prehliadači Chrome, ktorý je štandardom v NBS prostredí.

  • Jednoduchý reporting GUI pre sledovanie zbehnutia a výsledku zbehnutia

  • Riadenie prístupu do aplikácie cez login modul napojeného na NBS LDAP/AD.

• Všetky metadáta uložené v databáze s prehľadným API

Je možné tento framework spojiť s DQM podporou, ale potom sa vyžaduje aby nastavenie metadát DQM a jeho exekúcia, prípadne reporting boli jasne, zrozumiteľne a ľahko oddeliteľné od zadaných Testovacích scenárov.

Security GUI (relačná časť DWH)

Framework pre správu prístupov je kritický komponent, ktorý umožňuje riadiť viditeľnosť dát a celkové práva používateľov DWH systému.

Framework má mať dve časti:

• GUI

  • Webové rozhranie použiteľne v prehliadači Chrome, ktorý je štandardom v NBS prostredí.

  • Riadenie prístupu do aplikácie cez login modul napojeného na NBS LDAP/AD.

• Server DB časť

Framework GUI musí umožňovať:

Definícia skupiny používateľov a priradenie reálneho používateľa z DB

Definícia objektovej skupiny (prístupovej role) a priradenie reálnej role z DB

Definícia riadkovej bezpečnosti objektu

Definícia stĺpcovej bezpečnosti objektu

Priradenie riadkovej a stĺpcovej bezpečnosti objektu k objektovej skupine

Priradenie role objektová skupina na skupinu používateľov

Možnosť simulovaného behu nastavenia rolí a bezpečnostných pravidiel

Framework nesmie umožňovať z bezpečnostných dôvodov:

Definícia DB používateľa,

Definícia DB role,

tieto informácie musí vedieť v DWH identifikovať a ponúknuť v zozname (pick list) pri nastavení práv.

Framework Server DB časť musí vedieť na požiadanie:

• Vygenerovať požadované pridelenie rolí, nastaviť VPD politiky a vytvoriť požadovanú stĺpcovú bezpečnosť pre jednotlivých používateľov,

• Skontrolovať nastavenia a prípadné nezrovnalosti v DB nastavení so schváleným nastavením v metadátach odobrať. T. j. ide o odobratie prístupových práv ak by niekto urobil zmeny ručne mimo systém.

Metadata Management / Wikipédia o DWH

V procesoch DWH vzniká množstvo metadát, ktoré popisujú vecnú aj technickú stránku spracúvaných a publikovaných dát, ktoré je potrebné efektívne sprístupniť širšej základni používateľov a analytikov, a uľahčiť tak ich navigáciu v dostupných dátach.

Budúci systém integrácie dát by mal byť doplnený o riešenie pre správu metadát, ktoré bude poskytovať NBS nástroje pre správu biznis katalógov, data lineage, data katalog a navigáciu v nich.

Medzi tieto metadáta patria:

• Biznis slovník pojmov

• Dátové katalógy – popisujúce dostupné dáta, zdroje, DataLake, DWH

• Ďalšie katalógy, napr. KPI katalóg, DQI katalóg, katalóg reportov

• Relácie medzi pojmami a dátovými modelmi resp. dátovými katalógmi

• Údaje o dostupnosti a kvalite dát

Nástroj pre manažment metadát bude umožňovať tieto funkcie:

• Správa a audit Biznisového slovníka:

  • Nástroje pre správu biznisového slovníka, x. x. xxxxxxxxx definíciu dôležitých konceptov a pojmov, ich významu a klasifikácie.

• Správa a audit Dátového katalógu s popisom dát v dátových zdrojoch, DWH a DataLake

• Automatické (na spustenie) naplnenie metadát z dostupných metadát DB, ODI, Workflow Managera a podobne. Vyžaduje sa minimalizácia (na úrovni jednotiek hodín do mesiaca) manuálnej správy informácií.

• Funkcionalita data lineage a impact analýzy nad objektami zaznamenanými v katalógoch (biznisové pojmy, KPI, DQI) a importovanými metadátami o objektoch.

• Jednoduchá navigácia medzi objektami dátového modelu na základe zachytených väzieb (lineage informácie)

• Funkcia fulltextového vyhľadávania v rámci všetkých atribútov katalógov a importovaných metadát

• Portál s webovým frontend-om pre navigáciu biznisových používateľov v metadátach:

  • Stránky sa musia generovať dynamicky (t. j. môže ich byť ľubovoľne veľa a v čase sa rozširovať) na základe nastavených metadát a definovaného template. Požadované template:

    • Jednoduchý report

      • Názov

      • Popis

      • Výsledok SQL SELECT z Relačnej časti DWH databázy (vrátené hodnoty riadkov môžu obsahovať dohodnuté TAGY na prelinkovanie na ďalšie objekty/stránky)

    • Informačná stránka, alebo skupinová stránka

      • Názov

      • Popis

      • Obrázok (napr. diagram dátového modelu pre vizualizáciu entít a vzťahov medzi nimi)

      • Linky na ďalšie podstránky

      • Linky na dokumenty uložené v Sharepointe NBS (nebude sa zobrazovať ak k danej stránky nebudú žiadne priradené)

    • Objekt (automatický import z DB)

      • Názov

      • Popis

      • Stĺpec

      • Popis (okrem popisu objektu, bude toto pole obsahovať dohodnuté TAGY na prelinkovanie na ďalšie objekty/stránky)

    • Metadata z  ETL mapovania (obsah podľa metadát ODI), t. j. minimálne:

      • Názov

      • Popis

      • Zdroje (s prelinkovaním na ne)

      • Cieľe (s prelinkovaním na ne)

      • Použitý Knowledge modul s jeho nastaveniami v danom mapovaej úlohe

      • Parametre SQL, ako sú typy a nastavenia JOIN, WHERE a atď.

      • Detainé mapovanie stĺpcov

    • Metadata z Workflow managera (obsah podľa metadát), t. j. minimálne:

      • Názov uzla ETL úlohy

      • Popis

      • Predchodca a nasledovník (s prelinkovaním na ne)

      • Typ uzla (SQL, REST API, volanie DL úlohy, volanie Ingestion úlohy, atď.)

      • Nastavenie

      • Plné znenie volania (text SQL, alebo volanie REST API atď) uzla ETL úlohy

    • Metadata z RDM

      • Zoznam číselníkov a mostíkov s popisom

      • Zoznam hlavných gestorov číselníkov

      • Zoznam používateľov číselníkov s pridelenými právami

  • Fulltextové prehľadávanie a navigácia na vyhľadané topicy, či TAGY

  • Portál bude nastavený v design manuáli NBS

• Nastavenie používateľských práv a prístupov

• Podpora LDAP/AD.

• Webové rozhranie použiteľne v prehliadači Chrome, ktorý je štandardom v NBS prostredí.

Riadenie dátovej retencie – management partícií

Dátový sklad umožňuje uložiť dáta v histórii podľa požiadaviek používateľov, zvyčajne v nekonečnej. Avšak musí existovať retenčná politika napr. z dôvodu ochrany investícií do IT infraštruktúry, alebo z prípadných legislatívnych dôvodov.

Je požadované aby v rámci projektu NBS DWH bol dodaný framework kde:

Dátová retencia bude definovaná metadátami pre každý objekt (tabuľka) zvlášť.

Spustenie frameworku bude riadiť workflow manažér

Framework musí vedieť zalogovať svoj stav do riadiacej konzoly

Framework musí podporovať tvorbu názvoslovia databázových tablespace a partícií

Detailné požiadavky na automatizáciu riadenia časových partícií:

• pridávanie,

• rozdelenie poslednej časovej partície

• odpájanie (retencia) „starých “ dátových particií

• presúvanie a defragmentovanie s nastaviteľnou možnosťou a výberom kompresie a tablespace.

Riadenie zámeny dát cez partície

•  Výmena (zámena) partícií v objekte – zámena dát

• podpora automatického znovu vytvorenia databázových indexov po procese zámeny

Dátové modelovanie

Nástroj pre dátové modelovanie by mal podporovať vývojárov pri analýze, dizajne, implementácii, testovaní a nasadzovaní softwarových riešení. Okrem toho plní dokumentačnú funkciu, je zdrojom metadát dokumentujúcich dátové štruktúry a závislosti pre business data lineage (závislosti dát DWH na ultimatívnych zdrojových štruktúrach). V jednotlivých fázach SDLC sa využíva nasledujúcim spôsobom:

• Analýza – reverse-engineering a dokumentácia dátových zdrojov, dopadová analýza zmien v zdrojových štruktúrach na štruktúry v DL/DWH, komunikačný prostriedok so zadávateľom

• Dizajn – návrh a dokumentácia nových dátových štruktúr, definícia logiky mapovania na dátové zdroje, generovanie časti dokumentácie

• Implementácia – generovanie kódu pre tvorbu a modifikáciu databázových štruktúr, exportovanie metadát pre generovanie niektorých transformácií a technických kontrol pri spracovaní dát v DL/DWH

• Testovanie – zdroj informácií pre testerov k dátovému modelu a očakávanej transformačnej logike

• Nasadzovanie - generovanie kódu a metadát pre nasadenie, sledovanie stavu vývoja a nasadzovania štruktúr cez prostredia

Voľba konkrétneho nástroja pre dátové modelovanie tak môže výrazne ovplyvniť spôsob a kvalitu implementácie. Prosíme odporučiť nástroj na podporu hore popísaného procesu, ktorý bude zakúpený separátne. Preferovaným nástrojom v NBS je Sparx Enterprise Architect (existujúce licencie) a/alebo Oracle Data Modeler (voľná licencia).

Nástroje pre Data Governance a riešenia Master Data Managamentu

Projekt celobankového NBS DWH nebude pokrývať komplexitu MDM/DG procesu. Túto tému bude analyzovať paralelná štúdia pre MDM a zavedenia Data Governance. Táto veta ale neznamená, že vyššie popísané technické požiadavky kapitoly 3.2 nie je nutné naplniť, práve naopak.

Až táto štúdia a ďalšie diskusie udajú implementačný zámer v celej šírke problematiky DG a MDM.

Biznisové požiadavky

V rámci dodávky projektu požadujeme implementáciu end to end (E2E)reportingového nástroja, ktorý bude podporovať analytické procesy.

Na základe pred-analýzy boli identifikované kľúčové oblasti pre:

1. Dátovú integráciu zdrojových systémov

2. Reporting a analýzy

3. Výstupné dátové oblasti

Zdrojové (vstupné) systémy

Tabuľka nižšie obsahuje zoznam zdrojových systémov, ktoré je potrebné integrovať do nového NBS DWH. Tabuľka obsahuje systémy označené ako:

1. Interné – systém, ktorý nesie dáta požadované pre integráciu do DWH a je v internej sieti (infraštruktúre) NBS. Dáta sú uložené buď v databázach, alebo v extraktoch vo forme súborov.

2. Externé – systém, ktorý obsahuje dáta požadované pre integráciu a je mimo infraštruktúry NBS. K dátam sa môže pristupovať rôzne cez API (Web Service) až po súborové rozhrania (HTTPS/SFTP a iné.)

3. Manuálne dátové vstupy - ide o dáta získavané z neštruktúrovaných dátových zdrojov ako je napr. e-mail, web, ročenka, výročné správy, ktoré je možné ukladať v štruktúrovanej podobe do strojovo spracovateľných formátov, avšak ide o výsledok manuálnej práce spracovateľov týchto dát. V prehľade nižšie je rámcový výpis takýchto zdrojov rozdelených podľa účelu použitia v aktuálne dostupnom formáte. Predpokladom pre automatizáciu bude aj vytvorenie rozhrania, cez ktoré sa budú rôznorodé manuálne vstupy do procesu integrovať. Momentálne takéto rozhranie neexistuje a každé spracovanie používa prispôsobené logiky pre prácu s manuálnymi vstupmi a potrebné dáta extrahuje cez vlastný dekóder. Pozri kapitolu 3.2.13

Význam ďalších atribútov tabuľky je nasledovný:

• Fáza- predpokladaná fáza dodávky dátovej integrácie do DWH (pozri kapitolu 3.4.5)

• Dôvod integrácie:

  • BI - dáta z označeného systému pôjdu primárne použiť v BI reportingu

  • OUT - dáta z takto označeného systému sú potrebné pre výstupy z DWH na odosielanie mimo NBS v presne definovanej štruktúre

• Databázový systém

  •  DB - dáta uložené v NBS databáze (Oracle, MS SQL, MySQL)

  •  Súbor - lokálne uložené súbor (CSV, MS Excel) na FTP úložisku alebo SharePoint v prostredí NBS

  •  WebAPI - Exsitencia WebAPI na externom serveri mimo NBS

  •  Lotus Notes - dokumentačná databáza LN

• Objem dát (GB) - predpokladaný objem dát v Gigabajtoch (1.000.000.000 bajtov)

• Počet objektov - tabuliek/súborov/API endpointov

Názov systému	Popis systému	Interný /externý	Fáza	Dôvod integrácie	Databázový systém	Objem dát (GB)	Počet objektov
KL	Kurzový lístok ECB	externý	1	BI, OUT	WEB API (XML)	1	2
RPO	Register právnických osôb	externý	1	BI	WEB API (XML)	2	10
RS	Register subjektov	interný	1	BI	DB – Oracle (Tabuľky)	60	18
Subjekty 2.0	Subjekty 2.0	interný	1	BI	DB – MySQL (Tabuľky/JSON)	0,4	4
ESMA	European Securities and Market Authority	externý	2	BI	Súbor (XML)	500	5
LEI kódy / GLEIF		externý	2	BI	WEB API (XML)	0,05	1
RBUZ	Register bankových úverov a záruk	interný	2	BI	DB – Oracle (Tabuľky)	30,6	24
REGFAP	Register finančných agentov a finančných poradcov	interný	2	BI	DB – MySQL (Tabuľky)	1	30
RO	Register organizácií (pre spracovanie MFI BSI, FA)	externý	2	OUT	Súbor (CSV)	0,3	2
RUZ	Register účtovných závierok	externý	2	BI	WEB API (JSON)	1	6
SU SR	Číselníky a registre poskytované štatistickým úradom SR (pre spracovanie GFS, IC, BoP, FA a iné)	externý	2	BI, OUT	Súbor (JSON, XML (štandard SDMX-ML), XLSX, CSV, ACCDB)	1	30
ŠZP ESAS	ŠZP ESAS (XBRL Fujitsu)	interný	2	BI	Súbor (XBRL)	80	100
ŠZP ESAS	ŠZP ESAS (XBRL Fujitsu)	interný	2	BI, OUT	DB – Oracle (Tabuľky/BLOB obsahujú XML v ZIPe)	1	100
ŠZP	Štatistický zberový portál	interný	2	BI	DB – Oracle (Tabuľky)	250	100
ARDAL	Agentúra pre riadenie dlhu alikvidity - údaje o úveroch, vkladoch, CP, derivátoch, repo obchodoch (stavy a transakcie); (pre spracovanie GFS, BoP, FA)	externý	3	OUT	Súbor (XLSX)	1	2
BISNODE	Databáza firiem - kvantitatívne akvalitatívne informácie o subjektoch	externý	3	BI, OUT	WEB API (CSV)	1,3	14
CERI	Centrálna evidencia regulovaných informácií	interný	3	BI	MySQL DB (Tabuľky/JSON)	1	3
CSDB	Centralised Securities Database	interný	3	BI, OUT	WEB API (XML)	170	4
ESKN	Katastrálny úrad (nehnuteľnosti, listy vlastníctva, vlastníci, prepojenia medzi dátami)	externý	3	BI	Súbor (DBF)	2	15
Eurofondy	Exporty dát z čerpania eurofondov	externý	3	BI	WEB API (JSON)	50	39
Finančná správy SR	Tabuľky Finančnej správy SR pre spracovanie BoP	externý	3	OUT	Súbor (XLSX)	0,5	2
Makroek. DB	Makroekonomická databáza	interný	3	BI	Súbor (XLS/CSV)	5	8
manuálne vstupy	Konfiguračné metadáta pre všetky spracovania	interný	3	OUT	Súbor (XLS/CSV)	1	60
manuálne vstupy	Týždenné štatistické ukazovatele	interný	3	OUT	Súbor (XLS/CSV)	8	100
manuálne vstupy	Ročné štatistické ukazovatele	interný	3	OUT	Súbor (XLS/CSV)	2	20
manuálne vstupy	Manuálne výkazy a kompilácie údajov NBS	interný	3	OUT	Súbor (XLS/CSV)	3	40
Ministerstvo financií SR	Tabuľky MF SR pre spracovanie BoP, FA	externý	3	OUT	Súbor (XLSX)	1	3
SHSDB	Securities Holdings Statistics Database	interný	3	BI, OUT	WEB API (XML)	170	4
Skúšky	Databáza otázok na skúšky, cvičné testy, ich výsledky, termíny skúšok	interný	3	BI	DB – MySQL (Tabuľky)	0,1	3
Štátna pokladnica	Tabuľky Štátnej pokladnice pre spracovanie GFS	externý	3	OUT	Súbor (XLSX)	5	5
BLMBRG	Bloomberg - obchodná platform	externý	4	BI	WEB API (JSON/XML)	1	50
CRIBIS	CRIBIS - databáza firiem, majetkové a personálne prepojenia	externý	4	BI	REST API	1	1
ECB SDW	European Central Bank Statistical Data Warehouse - všetky datasety kde figuruje krajina "SK"	externý	4	BI	Súbor (CSV/XML)	1	50
IDAS	Agendový systém dohľadu	interný	4	BI	Súbor (CSV)	55	10
Register OFV		interný	4	BI	DB – Oracle (Tabuľky)	0,1	2
Sociálna poisťovňa	Tabuľky Sociálnej poisťovne pre spracovanie BoP	externý	4	BI, OUT	Súbor (XLSX)	0,2	4
ASDR	Agendový systém dohľadu a regulácie - ISD (Informačný systém dohľadu)	interný	5	BI	Oracle DB	9	100
xxxxxx.xxx.xx	Register trestov	externý	5	BI	WEB API (-)	1	1

Tabuľka 15: Zoznam hlavných zdrojových systémov pre NBS DWH, ktoré budú integrované do relačnej časti DWH

V rámci dátovej architektúry NBS existujú aj ďalšie databázy a importy z externých zdrojov, ktoré plánujeme počas projektu integrovať. Detaily sú v prílohe A - Zdrojové systémy NBS DWH. Stĺpec H označuje systémy relevantné pre tento projekt. Celkovo systémov na integráciu je 64. V hornej tabuľke č. 17 je zobrazených 36 systémov a priradených do jednotlivých fáz projektu. Tých, ktoré nie sú uvedené v hornej tabuľke ostáva 28. Tieto systémy majú rôzny rozsahu náročnosti integrácie. Niektoré z týchto systémov plánujeme integrovať priamo do relačnej časti DWH (registre, číselníky) a niektoré dátové zdroje plánujeme požadovať uložiť len do DataLake Stage vrstvy pre Data discovery účely. Táto integrácia prebehne v 3. až 5. etape projektu a je požadované tieto práce vykonať uchádzačom. Pre nacenenie projektu môžeme počítať pravidlo, že spôsob integrácie bude nasledovný:

• 36 systémov primárne integrované do relačnej časti DWH (tabuľka č. 17) v TL a PL vrstvách podľa potrieb reportingu, viď. nasledovná kapitola. Označené v stĺpci B ako „BI“, „OUT“, „BI, OUT“.

• 13 systémov z prílohy pôjde tiež do primárne do relačnej časti DWH (registre, číselníky), integrácia dát bude požadovaná na úrovni TL vrstvy. Označené v stĺpci B ako „REGISTER“.

• 15 systémov z oblasti transakčných dát, t. j. tie ktoré nie sú registrami, či číselníkmi budú cez Ingestion framework načítané do DataLake v tabulárnom formáte bez zložitých transformácií, max 5 mapovaní na číselníky, či registre. Označené v stĺpci B ako „DISCOVERY“.

Reportingová oblasť

Integrácia dátových zdrojov do konsolidovanej dátovej základne bude hlavným predpokladom pre vybudovanie analytickej dátovej vrstvy – datamarty. Sú požadované vytvoriť aj ukážkové reporty, ale predpokladáme že ďalšie reporty a analýzy si NBS vytvorí na základe naučených vedomostí z projektu.

Tieto datamarty budú slúžiť za účelom:

• „self-service“ vytvárania analytických výstupov (produktov):

  • pre podporu manažérskeho rozhodovania,

  • pre podporu strategických činností NBS – dohľad, regulácia, štatistika, ochrana spotrebiteľa,

  • pre podporu operatívneho rozhodovania.

• zdieľania analytických údajov a prehľadov v interaktívnej grafickej podobe naprieč spoločnosťou,

• ukladanie a historizáciu analytických údajov,

• prepojenie individuálnych a agregovaných údajov (a ich rekonciliácií),

• vytvorenie konsolidovanej informácie o subjektoch finančného trhu.

Je požadované mať možnosť nastaviť v metadátach datamartoch, ktoré dáta za aké obdobie majú byť prepočítavané (a v akej periodicite) a ktoré obdobia majú byť už uzamknuté.

V rámci požadovaného projektu je zadefinovaných týchto 11 analytických oblastí:

ID	Označenie datamartu	Fáza	Popis datamartu	Rámcový popis požadovaných prvkov
1	REPORTS	2	Datamarty pre štatistické údaje vyzbierané cez výkazy portálu ŠZP.	časové rady ekonomických položiek, medzimesačné zmeny objemov súvahových položiek podľa rôznych ekonomických členení, výpočet vážených priemerov, etc.
2	MFI_ESAS_ANACREDIT	2	Datamarty pre údaje o bankových úveroch a ich protistranách. Datamart pre konsolidáciu agregovaných údajov ŠZP (menová a finančná štatistika) a individuálnych údajov RBÚZ. Datamart na rekonciliáciu údajov ESAS (COREP a FINREP) na RBÚZ, resp. kosolidované porovnanie týchto dát	časové rady ekonomických veličín (nominálna hodnota, priemerná úroková sadzba, etc.), prehľady podľa subjektu, nástroja, prijatého zabezpečenia, rizika protistrany, etc. konsolidované porovnanie nominálnych hodnôt agregátov menovej štatistiky a individuálnych nástrojov s možnosťou drill-down analýzy v zmysle BSI metodiky časové rady položiek, zmeny medzi referenčnými dátumami položiek (objemy a percentá), poradia subjektov
5	AML	2	Datamart pre spracovanie dát AML pre risk assessment.	výpočet AML rizikových indexov z výkazov ŠZP
6	EXR	2	Datamart pre kurzový lístok	prehľad kurzového lístka, časové rady výmenných kurzov
4	SECURITIES	3	Datamart pre konsolidáciu údajov o cenných papieroch CSDB a vykazovaných údajoch o cenných papieroch ŠZP	konsolidované porovnanie atribútov cenných papierov z výkazov ŠZP voči databáze CSDB a SHSDB
11	ESMA	3	Datamart pre cenné papiere Datamart pre ESMA dáta	Obsah reportov približne obdobne ako v publikáciách ESMA: xxxxx://xxx.xxxx.xxxxxx.xx/xxxx/000000/xxxxxxxx?xxxxxxxXx0xxXX xxxxx://xxx.xxxx.xxxxxx.xx/xxxx/000000/xxxxxxxx?xxxxxxXx0XxXX0
16	MACROP___1	3	Datamart pre monitoring fin. inštitúcií + CBD Datamart pre proticyklický smerovník	Reporty zamerané na základný monitoring a analýzu rizík predovšetkým v bankovom sektore v členení podľa jednotlivých oblastí - ziskovosť, kapitálová primeranosť, kvalita aktív, štruktúra bilancie, likvidita a pod. Možnosť uskutočňovať medzinárodné porovnania indikátorov pomocou údajov z databázy ECB SDW. Report na výpočet konsolidovaných bankových údajov (CBD), ktoré sa zasielajú na pravidelnej báze do ECB. Reporty zamerané na základný monitoring a analýzu rizík v nebankových sektoroch v členení podľa jednotlivých sektorov - DSS, DDS, KI, OCP. Report ma kvantifikáciu trhových rizík a výpočty stresového testovania pre fin, inštitúcie.
19	MACROP___3	3	Datamart pre podnikový sektor	Na komplexné pokrytie monitoringu podnikového sektora (primárne na účely finančnej stability)
9	ESAS	4	Datamart pre dohľad nad kapitálovým trhom Datamart pre dohľad nad platobnými službami Datamart pre risk-based supervison Datamart pre dohľad nad poisťovníctvom Datamart pre údaje bankového dohľadu v portáli ESAs	súvaha, výsledovka, analýza 1 subjektu, trhová analýza, zloženie portfólia aktív, výkonnosť, časové rady, medziročné zmeny, vážené priemery, definovanie vhodného metapopisu na integrované dáta, risk dashboard, SREP skóre, kapitálová primeranosť, pákový efekt, systémové riziko. Sektory: centrálny depozitár, burza, obchodníci s cennými papiermi, správcovské spoločnosti a ich fondy, limity pre fondy časový pohľad na vývoj vybraných atribútov (napr. fin. ukazovateľov) 1 subjektu vrátane agregovaného výstupu za sektor vo forme tabuľky príp. grafu vrátane medzimesačného a medziročného porovnania; analýza 1 subjektu v podobe tabuľky (zahŕňajúca údaje z viacerých zdrojov od finančných ukazovateľov, rôzne kvalitatívne zdroje napr. údaje o osobách, konaniach...) risk dashboard zahrňujúci analýzu časových radov, prehľad osôb, etc. časový pohľad na portfólio aktív v tabuľkových a grafických prezentáciách (statické tabuľky, kontingenčné tabuľky, koláčové grafy, etc.), medzimesačné, medziročné vývojové indexy časové rady položiek, zmeny medzi referenčnými dátumami položiek (objemy a percentá), poradia subjektov
17	MACROP___2	4	Datamart pre databázu fin. aktív držaných fin. inštitúciami	Reporty zamerané na základný monitoring a analýzu rizík v nebankových sektoroch v členení podľa jednotlivých sektorov - DSS, DDS, KI, OCP. Report ma kvantifikáciu trhových rizík a výpočty stresového testovania pre fin, inštitúcie.
14	ASDR	5	Datamart pre účely ASDR Datamart pre dohľad nad kapitálovým trhom Datamart pre dohľad nad kapitálovým trhom	Spájanie údajov (kvalitatívne, kvantitatívne a procesné údaje) pre účely dohľadu, ktoré má NBS k dispozícií o danom subjekte podľa jednotlivých sektorov. Early warnings, vykazovanie načas, KPIs, benchmarkové porovnania. Prehľady subjektov podľa sektorov, pôsobenie osôb vo funkciách, konflikty záujmov, nedôverihodnosť, odborná spôsobilosť...

Tabuľka 16: Zoznam DataMartov pre projekt NBS DWH

V nasledujúcej tabuľke je kvantifikácia komplexnosti dátových oblastí pre BI reporting. Každá oblasť je definovaná požadovanou dátovou integráciou, predpokladanou náročnosťou výpočtu jednotlivých KPI a predpokladaným rozsahom faktových tabuliek. Počet a rozdelenie dátových oblastí sa môže meniť (ale nie zásadne) pri návrhu realizovaného riešenia.

ID	Označenie datamartu	Počet dátových zdrojov na integráciu	Odhad počtu DIM tabuliek	Odhad počtu Faktových tabuliek	Odhad počtu atribútov	Odhad počtu metrík	Zložitosť výpočtu metrík	Počet vzorových reportov
1	REPORTS	3	100	50	400	50	Stredná	10
2	MFI_ESAS_ANACREDIT	4	67	3	270	30	Nízka	5
5	AML	1	14	1	80	50	Vysoká	2
6	EXR	1	3	2	10	0	Nízka	1
4	SECURITIES	4	18	2	100	10	Nízka	2
11	ESMA	8	N/A	25	1000	100	Vysoká	10
16	MACROP___1	4	N/A	N/A	N/A	100	Vysoká	5
19	MACROP___3	6	N/A	10	100	50	Nízka	4
9	ESAS	13	75	25	500	100	Stredná	10
17	MACROP___2	5	75	25	500	10	Vysoká	5
14	ASDR	12	N/A	N/A	N/A	N/A	N/A	N/A
	11 DataMartov		352	143	2960	500		54

Tabuľka 17: Predpokladaná maximálna náročnosť jednotlivých DataMartov a prezentačnej vrstvy (PL) relačnej časti DWH

Poznámka 1: Odhady komplexnosti jednotlivých DataMartov vychádzajú z výsledkov Pilotu DWH a metodiky vývoja podľa Xxxxxx Xxxxxxx

Poznámka 2: Detailná tabuľka je v prílohe „DataMarty NBS DWH“ .

Výstupné dátové oblasti

Druhá veľká časť výstupov NBS DWH sú výstupy dát v presne definovanej štruktúre pre potreby odosielania týchto dát mimo NBS.

Cieľom tejto časti je rámcový popis požiadavky na automatizáciu procesov diseminácie v štatistickom spracovaní dát z pohľadu:

• integrácie požadovaných dát z identifikovaných dátových zdrojov (referencia na tabuľku) do databáz DWH/DL,

• vytvorenia dátových modelov pre účely štatistického spracovania dát v prostredí databáz DWH/DL a nástrojov BI,

• návrhu transformačných a výpočtových procedúr vo vrstvách DWH/DL a nástrojov BI

• prípravy a archivácie výstupov v exportných formátoch (GESMES/TS / SDMX/ML),

• automatizácie kontrol dátovej kvality výstupov.

Výstupy zo štatistického spracovania je možné kategorizovať do nasledovných oblastí:

• odvetvové

• nástrojové

• komplexné

V rámci odvetvových a nástrojových oblastí spracovania je požadované zaviesť automatizované a semi-automatizované procesy, a generovanie výstupných formátov (GESMES/TS/SDMX/ML/TSV/CSV) podľa špecifikácie konkrétneho spracovania. V súčasnej dobe sú využívané dostupné self-service nástroje, pričom logiky spracovania sú decentralizované v rámci týchto nástrojov (VBA, self-service BI, SQL, manuálna práca MS EXCEL). Rámcové ohraničenie rozsahu a štruktúry dátových zdrojov, nad ktorými sa budú vykonávať výpočtové operácie sú uvedené v úvode tejto kapitoly.

V prípade výstupov označených ako komplexné, nie je vzhľadom na povahu a rozsah možné zabezpečenie plne automatizovaného „end-to-end“ spracovania a to najmä kvôli častej potrebe manuálnych korekcií a ad-hoc intervenciám v procese kompilácie výstupov zo strany zostavovateľov štatistík. V tomto prípade bude požadované minimálne zabezpečenie aktuálnych a dostupných dát zo všetkých dátových zdrojov pre efektívne spracovanie výstupov prostredníctvom na to určených „self-service“ nástrojov.

Oblasti štatistického spracovania sa pri tvorbe výstupných súborových formátov vyznačujú rôznorodosťou potrebných dátových zdrojov v kombinácií s ich vysokou dostupnosťou. Tieto dátové zdroje možno rozčleniť na:

• manuálne dátové vstupy (dáta, ktoré nemožno získať z interných alebo externých systémov a sú výsledkami práce expertov danej domény),

• dáta z interných systémov NBS (interné databázy, portály, súbory),

• dáta z externých inštitúcii (štatistické údaje v rôznych prenosových formátoch, ktorých rozsah a spôsob výmeny je dohodnutý v bilaterálnych zmluvách).

Zoznam štatistických domén, v ktorých je požadované zvýšenie úrovne automatizácie, sa nachádza v tabuľke nižšie:

Výstup	Doména	Typ			Spôsob spracovania dát v DWH				Počet dátových zdrojov
		Komplexné	Sektorové / odvetvové	Nástrojové	príprava dátových zdrojov	Transformácia dát	Tvorba OUT	Nastavenie DQ
DM.001	Government Finance Statistics	X			X				24
DM.002	MFI Interest Rate Statistics		X		X	X	X	X	2
DM.003	MFI Balance Sheet Items		X		X	X	X	X	4
DM.004	Securities Issues			X	X				9
DM.005	Securities Holdings SHSE			X	X	X	X	X	2
DM.006	Securities Holdings SHSS			X	X				4
DM.007	Investment Funds		X		X	X	X	X	3
DM.008	Factoring, Leasing and Consumer Credit Companies		X		X	X	X	X	1
DM.009	Financial Accounts	X			X				8
DM.010	Insurance Corporations, (sektorovo / odvetvové)		X		X	X	X	X	8
DM.011	Pensions Funds		X		X	X	X	X	6
DM.012	Balance of Payments	X			X				13
DM.013	Payment statistics			X	X	X	X	X	3
DM.014	Payment institutions and institutions of electronic money		X		X	X	X	X	9
DM.015	Bank for the Accounts of Companies Harmonised		X		X				5

Tabuľka 18: Zoznam štatistických domén

V DWH databáze sú požadované vytvorenie v OUT vrstve príslušné tabuľky v štruktúre požadovanej pre jednotlivé výstupy. Výstupy budú generované ako 1:1 tieto tabuľky so zmenou do požadovaného formátu:

	Doména	Cieľ	Výmenný formát
OP.001	MFI Interest Rate Statistics	ECB EXDI	XML (SDMX-ML 3.0)
OP.002	MFI Interest Rate Statistics	WEB NBS	CSV
OP.003	MFI Balance Sheet Items	ECB EXDI	XML (SDMX-ML 3.0)
OP.004	MFI Balance Sheet Items	WEB NBS	CSV
OP.005	Securities Holdings SHSE	ECB EXDI	CSV
OP.006	Investment Funds	ECB EXDI	XML (SDMX-ML 3.0)
OP.007	Investment Funds	WEB NBS	CSV
OP.008	Factoring, Leasing and Consumer Credit Companies	WEB NBS	CSV
OP.009	Factoring, Leasing and Consumer Credit Companies	ECB EXDI	XML (SDMX-ML 3.0)
OP.010	Inssurance Corporations	ECB EXDI	XML (SDMX-ML 3.0)
OP.011	Inssurance Corporations	EIOPA	XML (XBRL)
OP.012	Pension Funds	ECB EXDI	XML (SDMX-ML 3.0)
OP.013	Pension Funds	EIOPA	XML (XBRL)
OP.014	Payment Statistics	ECB EXDI	XML (SDMX-ML 3.0)
OP.015	Payment Statistics	EBA	XML (SDMX-ML 3.0)

Tabuľka 19Zoznam výstupov

Zmena na požadovaný formát a odosielanie (cez SFTP) na distribučný server je súčasťou projektu. Vytvorenie distribučného servera nie je predmetom tohto projektu.

Spracovanie vyžaduje historizáciu zmien vstupných a aj výstupných dát vrátane archivácie výmenných formátov vo frekvencii, v akej sú zo zdrojových systémov zbierané a v cieľovom systéme spracovávané.

Transformačné logiky jednotlivých spracovaní sú v súčasnosti decentralizované a umiestnené v rôznych komponentoch v závislosti od použitých nástrojov. Jedným zo základných predpokladov automatizácie je zmapovanie a centralizácia týchto logík do prostredia, v ktorom sa bude spracovanie vykonávať. Tieto operácie sa opakujú a možno zhrnúť do nasledovných oblastí:

	Operácia	Popis
a.	Preklad a mapovanie	Aplikovanie pravidiel pre preklad prvkov číselníkov, atribútov riadkov, stĺpcov zo vstupného na požadovaný výstupný formát.  Napr.: Preklad adresy dátového bodu národného dátového modelu na adresu dátového bodu dátového modelu ECB (typ 1:N, N:1).
b.	Obohacovanie metadátami	Denormalizácia, pripájanie a kombinovanie s inými dátovými zdrojmi na základe mapovacích pravidiel.  Napr.: Pripojenie atribútov cenného papiera z databázy cenných papierov na základe jednoznačného ID cenného papiera k vykázaným údajom z databázy IS ŠZP.
c.	Filtrovanie	Výber relevantných objektov (záznamy, ich atribúty) na základe filtrovacích pravidiel.
d.	Agregácia a sumarizácia	Výpočet (aj viackrokový) dátových bodov v požadovanej granularite aplikovaním sumarizačných výpočtov.  Napr.: Výpočet váženého priemeru na základe predpočítanej váhy a hodnoty, súčet za podmienky, počet, etc.
e.	Formátovanie	Príprava predpočítaných dát do finálnej štruktúry výstupného formátu – súboru.  Napr.: Formátovanie vypočítaných dátových bodov do formátu XML v štandarde SDMX-ML 3.0.
f.	Matematické operácie	Aplikovanie matematických výpočtov na dáta podľa stanovených pravidiel a metodík.  Napr.: Výpočet odhadov, prenásobenie koeficientom.

Tabuľka 20: Transformačné logiky jednotlivých spracovaní pre OUT vrstvu

Funkčné požiadavky

Z pohľadu biznis používateľského komfortu ale aj z pohľadu rýchlosti na reagovanie zmien, poprípade testovania nových častí výpočtov požadujeme:

• ETL procesy budú programované ako fixné, t. j. mapovanie, transformácie, spájanie a agregácie bude definované cez nástroj Oracle Data Integrátor.

• Parametre mapovaní, t. j. napr. ktoré číselníkové dáta vstupujú, prípadne s akými váhami je striktné požadované vytvoriť ako parametrické. Tieto parametre bude používateľ mať možnosť cez mostíkový číselník meniť bez zadania zmenového listu na odbor IT a zmeny ETL úloh .

• Rovnako sa počíta, že transformácia do výstupných formátoch bude definovaná v ODI.

• Pokiaľ výstupné formáty budú príliš komplikované na ODI (je zakázané, až na dohodnuté výnimky programovať – požadujeme low-code metódy implementácie) je možné použiť na transformáciu Ingestion framework, ktorý by mal poznať formáty na spracovanie. Preto predpokladáme, že keď bude vedieť čítať, mal vedieť aj ich generovať.

• Súčasťou projektu je aj analýza primárneho zdroja dát a prepojenie číselníkov rôznych zdrojových systémov cez Referenčné hodnoty. Biznisová požiadavka je mať nástroj na udržiavanie týchto hodnôt bez priamej podpory IT ako je popísané v kapitole 3.2.13 Správa číselníkov.

• Dáta budú primárne integrované do relačnej časti DWH. Niektoré vybrané zdroje budú spracovávané/ukladané cez DataLake. Toto bude dohodnuté v mapovacom dokumente počas Návrhu riešenia. V rámci spracovania dát sa požaduje:

  • automatické sťahovanie a ukladanie dát

  • transformácia do relačnej podoby pre analýzy

  • sprístupnenie relačnej štruktúry pre dátovú analýzu

  • asistencia pri definovaní relevantnej množiny záznamov a atribútov pre ďalšie spracovanie (analýza a rozhodnutie o dátach na strane NBS)

  • integrácia relevantnej podmnožiny dát do DWH

  • sprístupnenie relevantných dát pre reporting nad DWH

  • automatizácia spracovania v danom rozsahu

  • vzhľadom ku charakteru rozsahu spracúvaných dát bude navrhnutý efektívny mechanizmus ukladanie v rámci DataLake

  • dáta z DWH bude možné off-loadovať do DataLake, napr. z výstupnej vrstvy DWH (OUT) alebo výpočty z Prezentačnej vrstvy DWH (L2).

• V rámci projektu požadujeme dodať metodiku a implementáciu konsolidačných mechanizmov pre oblasti (identifikácia primárnej informácie, vytvorenie kmeňového záznamu, nastavenie kvalitatívnych ukazovateľov (DQI)):

  • Subjekty

  • Cenné papiere

  • Adresy Slovenskej republiky

• V rámci dodávky bude sprevádzkovaný prístup koncových nástrojov MS Power BI, QlikSense k relevantným vrstvám DWH a DataLake, tj. bude demonštrovaný aj SQL prístup k štruktúram DWH a DataLake s rešpektovaním uvedených prevádzkových a bezpečnostných požiadaviek.

• Vytvorenie OUT vrstvy pre generovanie štandardných a dohodnutých exportov do rôznych systémov NBS a aj mimo NBS (OpenData, ECB, EBA a podobne).

Požiadavky na organizáciu a výstupy projektu

Projektové riadenie

Požiadavky na zabezpečenie projektového riadenia zo strany verejného obstarávateľa zahŕňajú:

• zabezpečenie projektového riadenia v súlade s metodikou projektového riadenia v NBS, ktorú určuje pracovný predpis NBS č. 20/2020 o projektovom riadení. Metodika je založená na princípoch metodiky PRINCE2 viď príloha C.

• vytvorenie plánu kvality v súlade s metodikou riadenia kvality projektového riadenia v NBS

• prácu s MS Project Professional v minimálnom rozsahu tvorby a aktualizácie plánu projektu

Prístup k projektu a RACI matica

Organizácia projektu je ukotvená schémou v organizačnej štruktúre projektu viď obrázok:

Obrázok 16: Organizačná štruktúra projektu

Projekt bude dodávaný v piatich (5) implementačných fázach, z ktorých každá musí obsahovať nasledovné aktivity:

1. Analýza

2. Dizajn

3. Implementácia

4. Nábeh do produkcie

5. Produkcia

Na strane NBS sa predpokladá zapojenie nasledovných rolí:

Rola NBS	Popis	Predpokladané fázy účasti na projekte
Projektový manažér	Riadenie projektu – interné	Analýza a Návrh, Implementácia a Nasadenie
Solution architekt	Špecialista pre validáciu a odsúhlasenie návrhu architektúry	Analýza a Návrh, a Nasadenie
Databázový špecialista	Špecialista pre validáciu a odsúhlasenie návrhu úložiska a databáz	Analýza a Návrh, Implementácia a Nasadenie
Testeri pre akceptačné testovanie	Zástupca odborného útvaru, ktorý bude používateľom	Testovanie a nasadenie
Biznis používatelia	Špecialisti nominovaní pre formuláciu funkčných požiadaviek a odsúhlasovanie špecifikácie	Analýza a Návrh, Akceptačné testovanie
Biznis vlastníci	Vedúci pracovníci, ktorí sú nominovaný na finálne odsúhlasovanie výstupov za odbory.	Analýza a Návrh, Akceptačné testovanie
IT aplikačný špecialista	Špecialista pre validáciu a odsúhlasenie návrhu aplikácií	Analýza a Návrh, Akceptačné testovanie a Nasadenie

Tabuľka 21: Projektové role na strane NBS

Na strane uchádzača požadujeme zapojenie minimálne kľúčových expertov, a to: Kľúčový expert č. 1 – Projektový manažér, Kľúčový expert č. 2 – Architekt riešenia (Relačná časť DWH), Kľúčový expert č. 3 – Architekt riešenia (BigData/DataLake časť DWH), Kľúčový expert č. 4 – Senior Dátový Analytik, Kľúčový expert č. 5 – Data Ingestion Špecialista, Kľúčový expert č. 6 – ETL Špecialista, Kľúčový expert č. 7 – BI Špecialista ktorí sú uvedení v zmluve o dielo, v podmienkach účasti, ktoré sú súčasťou týchto súťažných podkladov verejného obstarávania.

Rozhodovanie sporov

V prípade rozporov medzi PM NBS a PM zhotoviteľa prerokuje spory Riadiaca rada projektu a rozhodnutie vydáva výlučne Sponzor projektu, ktorý nesie hlavnú zodpovednosť za celý projekt.

V prípade, že toto rozhodnutie je v zásadnom rozpore s platnou zmluvou, iniciuje Xxxxxxx projektu negociácie a popr. konanie k zmenovým požiadavkách.

RACI matica základných projektových aktivít je uvedená prílohe D.

Pravidlá pre riadenie komunikácie

Táto kapitola obsahuje popis spôsobu a frekvencie komunikácie jednotlivých zainteresovaných strán (ako interných tak aj externých). Takýto spôsob zabezpečuje kontrolovanú a správne usmerňovanú komunikáciu všetkých zainteresovaných strán v realizačných projektoch.

Zainteresované strany

• riadiaca rada (RR), 

• hlavný zhotoviteľ projektu, 

• projektový manažér objednávateľa , 

• projektový manažér zhotoviteľa, 

• projektový tím objednávateľa

• projektový tím zhotoviteľa

Zaobchádzanie s informáciami

Berúc do úvahy význam dôležitosti niektorých informácií získaných v projekte a potreby udržiavať tieto informácie dôvernými majú všetky role v projekte povinnosť zaobchádzať so získanými informáciami, ktoré sú verejne neprístupné, a to technické, obchodné, finančné, komerčné alebo prevádzkové informácie, špecifikácie, plány, dáta, počítačové programy, softvér alebo dokumentácia v akejkoľvek podobe, či už zachytené hmotne alebo ústne poskytnuté ako s chránenými. 

Každá rola v projekte musí dodržiavať a prijať zodpovedajúce technické, organizačné a iné opatrenia potrebné na ochranu informácií, ktoré mu boli alebo mu budú poskytnuté, alebo sprístupnené, pred neoprávnenou manipuláciou s nimi, minimálne však také opatrenia, ktoré sú porovnateľné s opatreniami aké dodržiava pri ochrane vlastných údajov podobnej povahy a dôležitosti. 

Riadenie komunikácie

Pre úspešné naplnenie cieľov realizačného projektu je potrebné vytvoriť vhodné podmienky pre efektívnu komunikáciu. Pre všetkých účastníkov projektu je kľúčové, aby pochopili svoje úlohy a zodpovednosti, ako aj úlohy a zodpovednosti ostatných členov projektu. 

Komunikácia a jej toky sú primárne definované a odvíjajú sa od nastavenia riadenia projektu, t. j. od štruktúry riadenia projektu. 

Z hľadiska formálnosti sa komunikácia v rámci projektu rozdeľuje na formálnu a neformálnu. 

Komunikácia na projekte bude prebiehať v zmysle čiar autority, a to na nasledovných úrovniach: 

• riadená komunikácia (využívajúca všetky dostupné spôsoby komunikácie), 

• stretnutia, 

• eskalácia. 

Riadená komunikácia 

Najdôležitejším aspektom komunikácie na projekte je komunikácia projektového manažéra. Predmetom tejto komunikácie je najmä: 

• operatívne riadenie projektu pozostávajúce najmä z/zo: 

  • pravidelných a ad hoc stretnutí, ktorých výsledkom je: 

    • aktualizácia projektových registrov, 

    • (pre)rozdelenie a (pre)plánovanie projektových úloh, 

    • eskalovanie problematických záležitostí, 

    • riešenie incidentov, 

  • vedenia registra rizík, 

  • správy verzií výstupov, 

  • zabezpečenia kvality výstupov, 

• preberanie a odovzdávanie výstupov projektu. 

Všetky formálne náležitosti sú komunikované emailovou komunikáciou, resp. úradnou listinnou komunikáciou. 

Využitie elektronickej pošty sa predpokladá v rámci všetkých komunikačných procesov projektu. Prostredníctvom elektronickej pošty sa vymieňajú jednak informácie obsiahnuté v správach a jednak elektronické súbory v prílohe správ. Každá elektronická správa obsahujúca informácie alebo súbory týkajúce sa projektu musí mať identifikáciu projektu v predmete správy. 

V projekte sa nepredpokladá masívne využívanie listovej korešpondencie a pokiaľ nie je stanovené inak, primárnym nástrojom komunikácie je elektronická pošta. Listovú korešpondenciu je možné odoslať prostredníctvom podateľne, doporučeným listom, prostredníctvom kuriérskej služby alebo faxom. 

V projekte sa predpokladá aj využitie telekonferenčných a videokonferenčných zariadení. Pri organizácii telekonferencií a videokonferencií platia rovnaké pravidlá ako pre organizáciu bežných stretnutí. Navyše však zvolávateľ stretnutia zabezpečuje včasnú distribúciu údajov potrebných pre pripojenie vzdialených účastníkov.  

V projekte sa predpokladá časté využitie telefonických zariadení, najmä pri riešení operatívnych a organizačných záležitostí. Využitie telefónu nie je vhodné pre zadávanie úloh a rozhodovanie o dôležitých záležitostiach. V prípade, že je výsledkom telefonického rozhovoru rozhodnutie alebo zadanie úlohy je potrebné potvrdiť túto skutočnosť aj prostredníctvom elektronickej pošty. 

Neformálnou komunikáciou sa rozumie doplnkový spôsob komunikácie pre efektívne riešenie každodenných náležitostí. Pre tento spôsob komunikácie môžu byť využívané adekvátne nástroje a technológie, ktoré zabezpečia efektívny a nenáročný spôsob komunikácie (videohovory, chaty a pod.). 

Projektové stretnutia

Okrem riadenej komunikácie a predkladania požadovaných výstupov budú v rámci realizácie projektu organizované rôzne typy pravidelných aj nepravidelných stretnutí. 

Tieto stretnutia budú realizované za účelom: 

• úvodného oboznámenia sa s projektom a jeho nastavením realizácie, 

• plánu realizácie úloh, 

• revízie plnenia úloh, 

• revízie stavu projektu, 

• odovzdávania/preberania projektových výstupov a poskytovania vyžiadanej súčinnosti, 

• výmeny ponaučení a odporúčaní, 

• sumarizácie a zhodnotenia realizácie projektu. 

Pre potreby zdieľania dokumentov je zriadené spoločné zdieľané projektové úložisko dokumentov na SharePointe, kde budú ukladané pracovné verzie dokumentov ako aj ich finálne verzie, ktoré budú vytvorené po schválení výstupov/produktov na RR. Komunikácia bude podporovaná projektovými dokumentmi, predovšetkým zápismi zo stretnutí, výstupmi jednotlivých úloh a nástrojmi projektového riadenia ako sú projektový plán, register úloh, register rizík, a pod. 

Základnými typmi projektových stretnutí sú:

Názov	Agenda	Periodicita	Účastníci	Čas a trvanie
Zasadnutie RR	schvaľovanie kľúčových dokumentov a výstupov, odpočet a stanovovanie strategických úloh, strategické riadenie projektu zodpovednosť za organizáciu projektu, schvaľovanie zmenových požiadaviek projektu	Minimálne 1x za 2 mesiace	členovia RR a prizvaní účastníci	podľa dohody, cca 1 hodina
Stretnutia s projektovým vlastníkom	operatívne prijímať rozhodnutia k predchádzaniu problémov, rizikám, riešenie otázok, konzultácia zmien	ad hoc podľa potreby	Vlastníci projektu a prizvaní účastníci	podľa dohody, cca1 hodina
Projektový tím (PTO) míting	odpočet a stanovovanie operatívnych úloh, operatívne riadenie projektu, návrhy a rozhodovanie o zmenách v projekte, aktualizácia rizík, otvorených otázok a pod.	1x týždenne	projektový manažér, PMO, vedúci tímu, členovia projektového tímu podľa potreby a kľúčoví experti podľa potreby	určený deň v týždni, cca 1-2 hodiny
Pracovný tím	stretnutie pracovných tímov ku konkrétnym témam projektu (analýzy, procesy, funkčná špecifikácia, finančný model, zmluva, legislatíva, prevádzka a pod.)	podľa potreby	Expert, zástupcovia pracovných tímov a prizvaní účastníci	podľa potreby

Tabuľka 22: Projektové stretnutia

Zápis vo všeobecnosti vyhotovuje organizátor stretnutia, prípadne ním poverená osoba.

Zápis zo stretnutia musí obsahovať: 

• identifikáciu projektu, 

• číslo zápisu, 

• dátum a čas, 

• miesto konania, 

• typ stretnutia, 

• zoznam prítomných účastníkov, 

• tému stretnutia, 

• agendu stretnutia, 

• stručný záznam z rokovania, 

• závery stretnutia rozdelené v zmysle nasledovnej kategorizácie: 

• informácie, 

• prijaté rozhodnutia, 

• otvorené otázky, 

• predpoklady, 

• riziko, 

• odsúhlasené úlohy vrátane určenia zodpovedných osôb za úlohy a termínov úloh, 

• prílohy (podľa potreby). 

Za správnosť návrhu zápisu zo stretnutia, jeho prípadných medziverzií a jeho finálneho znenia podľa vyššie uvedených požiadaviek zodpovedá organizátor stretnutia, ak sa nedohodne inak; je ďalej zodpovedný aj za správne uloženie návrhu zápisu zo stretnutia a jeho prípadných medziverzií na spoločné zdieľané projektové úložisko dokumentov. 

Postupy eskalácie

Počas životného cyklu projektu môže dôjsť k neočakávaným situáciám, ktoré nie je možné vyriešiť bez zapojenia vyšších zložiek riadenia alebo ak je potrebné prijať rozhodnutie, vyžadujúce si schválenie vyšším manažmentom. Pre dosiahnutia riešenia, resp. rozhodnutia pre takéto situácie bude v rámci projektu zavedený eskalačný mechanizmus, ktorý bude využívať nasledujúce eskalačné úrovne: 

• prvý stupeň eskalácie – projektový manažér, 

• druhý stupeň eskalácie – vyšší manažment (riadiaci pracovníci/manažment – vlastníci projektu ako nositelia úlohy z Bankovej rady), 

• tretí stupeň eskalácie – Riadiaca rada projektu (zloženie v zmysle Štatútu). 

Pri eskalácii je vždy potrebné písomné oboznámenie so vzniknutou situáciou, ktoré okrem popisu vzniknutej situácie popisuje aj dopad na chod projektu, identifikovanie dotknutých osôb, návrh možného riešenia, a pod. 

Problematická situácia bude eskalovaná do doby, kým nebude vyriešená, pričom o rozhodnutí o riešení eskalovanej situácie sú informované všetky dotknuté osoby. Eskaláciu je potrebné používať ako nástroj nemožnosti vyriešenia úlohy na danej úrovni. Všetky eskalačné požiadavky musia byť zaznamenané písomnou formou.

Projektový plán

Požadovaný termín na finalizáciu dodávky riešenia je do 36 mesiacov odo dňa účinnosti zmluvy o dielo. Navrhovaný projektový plán je súčasťou prílohy E.

Obrázok 17: Časový plán projektu

Projekt je rozdelený do piatich fáz (dropov):

Fáza	Popis	Platobný rozsah (z investičnej ceny implementácie celého diela)
1	Nastavenie relačnej časti DWH, príprava infraštruktúry, technických používateľov Integrácia zdrojových systémov pre 1. fázu pre relačnú časť DWH Návrh a implementácia modelu DWH transakčnej vrstvy (L1) Inštalácia frameworkov (Ingestion, Workflow manager, Security, Dátová retencia), ich úvodné nastavenie a odsúhlasenie ich funkcionalít	16 %
2	Integrácia zdrojových systémov pre 2. fázu Návrh a implementácia modelu DWH transakčnej vrstvy (L1) Návrh a implementácia prezentačnej vrstvy relačnej časti (L2) Návrh a implementácia OUT vrstvy Nastavenie DataLake časti DWH, príprava infraštruktúry, technických používateľov, inštalácia BigData komponentov Inštalácia frameworkov (Manuálne vstupy, RDM, Test framework, Data Quality framework)	24 %
3	Integrácia zdrojových systémov pre 3. fázu Návrh a implementácia modelu DWH transakčnej vrstvy (L1) Návrh a implementácia prezentačnej vrstvy relačnej časti (L2) a príprava Datamartov a Reportov Návrh a implementácia OUT vrstvy Implementácia DataLake časti (nábeh do produkcie) Inštalácia frameworku – Metadata Management (InfoHUB)	29 %
4	Integrácia zdrojových systémov pre 4. fázu Návrh a implementácia modelu DWH transakčnej vrstvy (L1) Návrh a implementácia prezentačnej vrstva relačnej časti (L2) a príprava Datamartov a Reportov Implementácia DataDiscovery infraštruktúry na DataLake Vytvorenie Sand boxov pre power-userov	19 %
5	Integrácia zdrojových systémov pre 5. fázu Tvorba prezentačnej vrstva relačnej časti (L2) a príprava Datamartov a Reportov	12 %

Tabuľka 23 Projektové fázy a finančné rozdelenie

Toto rozdelenie je za týchto podmienok:

• Každá fáza obsahuje svoje časti Analýza, Design, Implementácia, Nábeh do produkcie, Produkcia, t. j. každá fáza bude implementovaná inkrementálne a postupne. Bude mať produkčný nábeh a biznisový výstup pre NBS používateľov. Očakávame, že jednotlivé systémy sa budú zapájať postupne a postupne testovať.

• Druhá fáza bude môcť začať až keď skončí prvá fáza, ostatné môžu mať (čiastočne) paralelný súbeh a môžu začať aj pred ukončením akceptácie predchádzajúcich fáz.

V tomto bode je požadované aby vybratý uchádzač riešil:

• Riadenie celkovej dodávky riešenia v rozsahu, ktorý je popísaný v tomto dokumente.

• Vypracovanie detailného projektového plánu na začiatku projektu a jeho ďalšia aktualizácia po celú dĺžku trvania projektu.

• Pravidelný reporting o stave projektu pre riadiace orgány projektu s frekvenciou podľa požiadaviek objednávateľa.

• Zabezpečenie a organizácia zdrojov projektu na strane zhotoviteľa a poskytovanie súčinnosti vedeniu projektu na strane banky.

• Manažovanie projektových závislostí a rizík a organizovanie aktivít na ich predchádzanie a riešenie na strane zhotoviteľa.

• Príprava a predkladanie špecifických výstupov riadenia projektu, ako sú status prezentácie, prezentácie pre riadiacu radu projektu, projektové plány, žurnál projektových rizík a incidentov (risk log/issue log)

Požadované výstupy projektu

Nasledujúce kapitoly obsahujú minimálny zoznam dodaných projektových výstupov v jednotlivých častiach projektu.

Analýza

Najvyšším cieľom tejto fázy je získať jednotný názor medzi všetkými účastníkmi projektu na ciele životného cyklu projektu. Preto je táto fáza kritická pre každý projekt, pretože rozsah následných prác, high-level požiadavky a dôležité riziká musia byť pochopené, kým projekt môže pokračovať.

V tejto fáze projektu sú systematicky zbierané požiadavky biznisu na cieľové riešenie a je vykonaná ich prioritizácia. Vo fáze analýzy sú typicky vedené analytické interview s užívateľmi a workshopy, na ktorých sú zisťované, triedené (klasifikované) a overované jednotlivé požiadavky používateľov na dátový sklad, posudzovaná ich realizovateľnosť v IT prostredí NBS a vzťah k iným existujúcim systémom, pričom sú jednotlivé požiadavky popísané vo forme používateľských scenárov (use cases), tak aby jednoznačne reprezentovali a interpretovali ich požiadavky.

Výstup	Formát	Popis
Špecifikácia požiadaviek (Requirements Traceability Matrix)	Dokument (XLSX)	Tabuľka priorít projektu, ktorá sumárne popisuje dohodnutý rozsah spôsobom „Must“, „Should“, „Could“, „Won‘t“. Tabuľka definuje priority a hlavné ciele.
Opis Architektúry (Project Blueprint)	Dokument (DOCX)	Dokument popisujúci architektúru a príslušné rozhrania v rámci implementácie riešenia, rovnako obsahujúci analýzu vplyvu implementácie projektu na NBS. Tento dokument môže byť predmetom aktualizácie v ďalších fázach projektu, ale iba v kontexte pridávania úrovne detailu. Dokument pokrýva detailné rozpracovanie nasledujúcich oblastí: Návrh prostredí - vývojového, testovacieho a produkčného prostredia vrátane konfiguračného manažmentu: Logická architektúra riešenia (RDBMS, integračná platforma, API, toky dát, riadenie dátovej kvality, metadáta). Fyzická architektúra riešenia, HW a SW architektúra, Topológia riešenia (ETL architektúra a dátové toky pre DataLake/DWH/BI) Workflow management, monitoring a notifikácie Požiadavky na dostupnosť (service level expectations). High availability stratégia. Back-up a recovery procesy. Stratégia historizácie a archivácie dát. Skupiny používateľov, prístup k bezpečnosti dát (matica a riadenie prístupových práv)
Analýza zdrojových systémov (Interface Agreement)	Dokument (XLSX)	Analýza zdrojových systémov definuje (popisuje) hlavný komunikačné cesty zo zdrojových systémov do DWH. Dokument taktiež popisuje základný subjektový model zdrojového systému. Template pre IA dodá NBS OIT.
Dokumentácia k testovaniu	Dokument (DOCX, XLSX)	Dokumentácia musí obsahovať nasledovné časti: Prístup k testovaniu Testovací plán Testovacie scenáre Akceptačné kritériá pre testovanie

Tabuľka 24: Tabuľka výstupov fázy Analýza

Dizajn

Táto fáza do detailu rozpracováva výstupy predchádzajúcej projektovej fáze, t. j. do detailu popisuje funkčné a nefunkčné požiadavky na riešenie. Jej obsahom sú tieto oblasti (výstupy):

Výstup	Formát	Popis
Návrh akvizície a konverzie dát (Interface Agreement)	Dokument (XLSX)	Doplnenie dokumentov z fázy Analýzy o: Rozhrania zdrojových a cieľových systémov, pre každý systém špecifikácia rozhrania, typu (text file, db link, API, service access atď.), typu aktualizácie (full vs. prírastkový), frekvencie aktualizácie (on-line, batch, frekvencia) a obsahu. Architektúra dátových tokov, vrátane zoznamu a detailného popisu dátových tokov a frekvencie, závislostí, detailný návrh workflow a job scheduling managementu, vrátane notifikácie užívateľov o prebehnutej aktualizácii dát. Inicializačný load, vrátane popisu zdrojových systémov, rozhraní, požadovaných a dostupných entít, požadovanej a dostupnej histórie, očakávaných objemov a prístupov automatizácie. Data refresh strategy – detailný popis postupov aktualizácie dát vo všetkých vrstvách DWH a pre všetky typy dát (číselníky, dimenzie, fakty, odvodené atribúty atd.). Procesy dátovej kvality pre data acquisition – error handling, error notification, error recovery.
Funkčný detailný design – Logický model a mapovanie	Dokument (DOCX;XLSX a EAP)	Definuje logický dátový model poskytujúci detailnú definíciu biznis dátového modelu. Obsahuje entity, atribúty, vzájomné vzťahy, domény, unikátne a alternatívne identifikátory. Atribúty a domény sú opísané formátmi, povolenými hodnotami alebo rozsahmi hodnôt. Obsahuje identifikáciu citlivých a osobných údajov, taktiž definuje ochranu týchto údajov Definuje hlavné predpoklady pre akvizíciu dát, mapovanie medzi zdrojovými dátami a cieľovými objektmi logickej databázy, mapovacie pravidlá a logiku, ktoré sú potrebné na vytvorenie konverzií a rozhraní v rámci riešenia DWH. Účelom dokumentu je poskytnúť potrebné informácie pre vývojový tím na vytváranie správnej extrakčnej (load) a transformačnej logiky
Security dokument	Dokument (DOCX)	Definuje na ktorom komponente sú aké osobné údaje a spôsob ich ochrany (pseudonymizácia, šifrovanie a pod). Definuje metodiku tvorby prístupových práv, tvorby rolí a prístupov Definuje metodiku celého životného cyklu dát: Administrácia osobných údajov Nastavenie dátovej retencie
Stratégia prechodu do produkcie	Dokument (DOCX)	High-level opis krokov uvedenia predmetného riešenia do prevádzky.
ETL vývojové štandardy	Dokument (DOCX)	Detaily o využívaní ETL nástroja pre projekt. Je kritickým elementom pre samotný ETL vývoj nakoľko definuje nevyhnutné štandardy. Dokument adresuje nižšie uvedené oblasti pre ODI (Oracle Data Integrator) v kontexte štandardov pre vývoj a prístup do ETL managera: Vývojové cykly Používanie verzionovania Definícia vykonateľného „jobu“ Definícia štandardov a pravidiel Menné konvencie Používanie Workflow frameworku pre definíciu závislostí Preukázateľné používanie revízie kódu s cieľom nájsť a odstrániť programové chyby.
Prístup k testovaniu riešenia	Dokument (DOCX)	Dokument bude obsahovať: požiadavky na otestovanie riešenia, akceptačné kritériá zároveň adresuje spôsob akým úspešný uchádzač interne otestuje predmetné riešenie a akú formu podpory dodá pri akceptačných testoch
Prístup k metadátam	Dokument (DOCX)	Katalóg metadát Prístup k metadátam Prístup k bezpečnosti

Tabuľka 25: Tabuľka výstupov fázy Design

Implementácia

Cieľom implementačnej fázy je prevedenie riešenia od detailných modelov požiadaviek, cez konfiguráciu štandardných balíkov softvérovej funkcionality, vývoj a testovanie frameworkových komponentov a integrácia do formy systému, ktorý je pripravený na prvý „release“ na uvedenie do prevádzky. V skratke ide o kompletizáciu vývoja aplikácie, validáciu či všetky komponenty spolu „sedia“, a prípravu systému na akceptačné testy a nasadenie.

Výstup	Formát	Popis
Fyzický model, ETL komponenty, frameworky	SW (export z EAP, ODI Metadata, súbory pre inštaláciu na aplikačné servere)	Implementácia systému podľa špecifikácií získaných v predchádzajúcich fázach. Budú konfigurované všetky reusable komponenty a vyvinuté a otestované komponenty definované pre Data Acquisition a Data Access. Logický dátový model bude základom pre vývoj a implementáciu fyzického dátového modelu. Na základe metadát bude vygenerovaný ETL kód, nastavené závislosti úloh a kalendár automatického spúšťania.
Komentované zdrojové kódy dodávane v rámci riešenia zhotoviteľom	Zdrojový kód podľa použitého programovacieho jazyka	Zdrojový kód obohatený o komentáre s vysvetlením obsahu programovej funkčnej časti (procedúry, funkcie)
Image pracovnej stanice vývojára	Súbor vo formáte príslušnej virtualizácie	Uložená HW a SW konfigurácia pracovnej stanice vývojára podľa špecifikácie dodanej zhotoviteľom
BI oblasť	SW	Implementácia dátových modelov v analytickej vrstve MS Analysis Services (Tabulárne modely) podľa dohodnutých design princípov a konvencií. Prototyping a implementácia analytických výstupov (reporty a grafy) v prostredí MS Power BI s publikáciu na MS Power BI Report Server.
Dokumentácia k testovaniu	Dokument (DOCX, XLSX)	Dokumentácia musí obsahovať nasledovné časti: Detailný testovací plán Testovacie scenáre Žurnál z testovania Akceptačné protokoly
Návrh iniciálneho nahratia dát	Dokument (DOCX)	Popis ako sa projekt zachová k dátami v zdrojových systémoch, t. j.: Ktoré dáta budú nahrané do DWH ako celok Ktoré dáta vyžadujú iný spôsob ETL pre denný beh a celkový nábeh Návrh podmienok iniciálnej migrácie tak, aby nebola ohrozené prevádzka a výkon zdrojových systémov
Návrh infraštruktúry podpory produkcie	Dokument (DOCX)	definuje požiadavky na prevádzkovanie riešenia a adresuje ich z procesného hľadiska. Tento dokument je predmetom aktualizácie v ďalších fázach projektu a na jeho konci kompletne definuje proces podpory a prevádzky riešenia návrh obnovy komponentov systému a údajov zo zálohy.
Školenie	Školenie a dokument (PPTX, video vo formáte MP4)	Školenie vybraných používateľov NBS. Do 30 používateľov: Vykonanie jedného jednodňového školenia pre bežných užívateľov. Vykonanie jedného jednodňového školenia pre analytikov a kľúčových užívateľov. Vykonanie jedného jednodňového školenia pre operátorov. Súčasťou školenia bude dodávka školiace materiálu vo forme PPT.
Používateľská a technická dokumentácia	Dokument (DOCX)	Rozšírenie školiaceho materiálu o ďalšie informácie dôležité počas prevádzky a rozvoja systému.

Tabuľka 26: Tabuľka výstupov fázy Implementácia

Nábeh do produkcie

Cieľom fázy nábehu do produkcie je uviesť ucelené riešenie od inštalácie na produkčný systém cez akceptačné testy po naštartovanie živej aplikácie, otvorenej a pripravenej na biznis. Validuje že riešenie je testované systematicky a je sprístupnené pre koncových používateľov.

Úlohy v tejto fáze:

• Uzatvorenie vývojovej verzie aplikácií v definovanom stave (code freeze).

• Príprava skriptov pre vytváranie / modifikáciu systémových, databázových a programových súčastí riešenia – tzv. inštalačný balíček

• Validácia technickej dokumentácie (predovšetkým dátového modelu).

• Migrácia testovacieho prostredia na produkčné prostredie a nasadenie aplikovateľných extraktorov na produkčné zdrojové systémy.

• Spustenie (exekúcia) skriptov pre vytváranie / modifikáciu systémových, databázových a programových súčastí riešenia na produkčnom prostredí.

• Súčasťou implementácie a akceptačných testov musí byť overenie obnovy komponentov systému a údajov zo zálohy.

• Akceptácia dokumentácie

• Skúšobná prevádzka

Výstup	Formát	Popis
Inštalácia na produkcii	SW	Spustenie inštalačných balíčkov
Vykonanie iniciálneho loadu	SW / FTE	Prvotná inicializácia DWH na základe dohodnutých pravidiel. Inicializačný load bude musieť byť s najväčšou pravdepodobnosťou opakovaný niekoľkonásobne, z dôvodov jeho technického, funkčného a používateľského testovania. Požadujeme podporu celkovo pre 2 úspešné iniciálne nahratia dát. Pred spustením produkčného iniciálneho loadu musí prebehnúť performance test, ktorý preukáže, že iniciálny load nebude trvať dlhšie ako 24 hodín. Pokiaľ sa preukáže, že iniciálny load nevie prebehnúť počas 24 hodinového okna, dodá zhotoviteľ plán rozdelenia iniciálneho nahrávania tak, aby sa využil už normálny inkrementálny beh.
Finálna akceptácia	UAT	Finálne testovanie na testovacom prostredí, na ktorom sa overí finálna kvalita a odsúhlasenie riešenia biznisovými používateľmi
Performance test	FTE	Vykonanie testu výkonnosti systému. V tejto úlohe požadujeme dodať protokol, kde bude zhodnotený beh ETL úloh z pohľadu komlexnosti ETL a počtu spracovaných dát a kvality samotného ETL scriptu. Požiadavka je aby beh ETL v NBS DWH bola ukončená do 08:00

Tabuľka 27: Tabuľka výstupov fázy Nábeh do produkcie

Produkcia

Cieľom fázy „produkcia“ je prevádzkovanie novo vyvinutého systému, vyhodnotenie úspešnosti nového systému, monitorovanie systémových problémov a ich adresovanie. Toto zahŕňa monitorovanie systému a vhodné zásahy aby bola udržaná prevádzková schopnosť, meranie výkonu systému, operačné a prevádzkové systémy, odpovedania na požiadavky o pomoc a asistenciu, na chybové hlásenia a funkčné požiadavky užívateľov; a riadenie aplikovateľného procesu kontroly zmien tak aby defekty a nové funkcionality boli prioritizované a pridelené do budúcich „releasov“ a bol zostavený plán budúcich rozšírení aplikácie rovnako ako určenie, vývoj a implementácia požadovaných aktualizácií.

Výstup	Formát	Popis
Onsite podpora	FTE	Požadujeme počas záverečnej fázy projektu aby úspešný uchádzač dodal podporu systému vo forme 1 onsite konzultanta po dobu 10 dní. Po uplynutí tejto periódy je kompetencia za riešenie presunutá na interný prevádzkový tím.
Bezpečnostné testovanie	FTE	Realizácia po akceptačnom testovaní (zabezpečí NBS). Potrebná súčinnosť pri realizácii bezpečnostného testovania. Oprava identifikovaných zraniteľností.
Overenie vykonateľnosti havarijného plánu	FTE	Realizácia po akceptačnom testovaní (zabezpečí NBS). Potrebná súčinnosť pri realizácii testu postupu obnoviteľnosti systému.

Tabuľka 28: Tabuľka výstupov fázy Produkcia

Projektová dokumentácia

Výstup	Formát	Popis
Zadanie projektu	DOCX/PDF/XLSX/MPP	Projektová inicializačná dokumentácia
Plán projektu, revízie plánu projektu a etapové plány projektu,	DOCX/PDF/XLSX/MPP	Dokument popisujúci projektový plán v zmysle dohodnutej projektovej metodiky
Plán komunikácie projektu (organizácia, plán meetingov, spoločný projektový priestor, zápisy)	DOCX/PDF/XLSX/MPP	Dokument popisujúci organizáciu projektu a komunikáciu na projekte v zmysle dohodnutej projektovej metodiky
Štandardy pre zaistenie kvality realizácie projektu a zaistenie kvality dodávaného systému.	DOCX/PDF/XLSX/MPP	Dokument popisujúci prístup ku kvalite, spôsob jej merania a vyhodnocovania.
Plán školení používateľov,	DOCX/PDF/XLSX/MPP	Dokument popisujúci prístup ku školeniam, formu, obsah a časové rámce školení jednotlivých rolí používateľov.
Plán skúšobnej prevádzky	DOCX/PDF/XLSX/MPP
Správy o stave realizácie projektu	DOCX/PDF/XLSX/MPP	Dokument popisujúci aktuálny stav projektu dodávaný zhotoviteľom
Dokumentácia k ukončeniu projektu	DOCX/PDF/XLSX/MPP	Záverečná správa projektu v zmysle dohodnutej projektovej metodiky
Register rizík	DOCX/PDF/XLSX/MPP	Evidenčný zoznam projektových rizík
Register problémov	DOCX/PDF/XLSX/MPP	Evidenčný zoznam riešených problémov
Register zmien projektu	DOCX/PDF/XLSX/MPP	Evidenčný zoznam zmien na projekte
Register výstupov projektu	DOCX/PDF/XLSX/MPP	Zoznam odovzdávanej výstupnej dokumentácie pri akceptačných míľnikoch

Tabuľka 29: Tabuľka projektovej dokumentácie

Akceptačné kritériá

Chybovosť dodávky pred nasadením do PROD:

• 0 závažných nedostatkov z UAT

• 0 zásadných nedostatkov z UAT

• Max 10 nepodstatných nedostatkov z UAT

Exekúcia 100% odsúhlasených testovacích scenárov.

Priebežná príprava a predkladanie výstupnej dokumentácie

Akceptované všetky požadované výstupy projektu pre danú fázu podľa kapitoly 3.4.5.

Zhotoviteľ dodá mesačné výkazy prác kľúčových expertov definovaných v súťažných podkladoch.

Zhotoviteľ zabezpečí prítomnosť minimálne dvoch pracovníkov v priestoroch banky počas celého trvania projektu. (Maximálna kapacita priestorov objednávateľom poskytnutých pre takýto typ práce je 12 pracovníkov).

Riziká projektu

V rámci verejného obstarania požadujeme vytvoriť register rizík projektu, ktoré budú mať vplyv na projekt v podobe nasledujúcej tabuľky:

Názov a popis rizika Kategória dopadu na projekt (H/M,/L) Kategória možnosti výskytu rizika (H/M,/L) Popis návrhu na zmiernenie dopadu

Tabuľka 30: Riziká projektu

Opis predmetu zákazky pre služby podpory prevádzky a rozvoja

Úvod

Zabezpečenie prevádzky vychádza z predpokladu trvalej udržateľnosti celého riešenia NBS DWH po dobu 3 rokov od ukončenia projektu (akceptácie diela) a nasadenia do produkcie.

Úroveň L1 podpory prevádzky NBS DWH bude zabezpečená vlastnými personálnymi kapacitami NBS, ktorá zabezpečí nasledovné služby prevádzky:

1. technická podpora pracovných staníc používateľov,

2. riadenie oprávnení,

3. správu centrálneho systému riadenia identít

4. riešenie prípadných problémov komunikačnej infraštruktúry (databázy, sieť, aplikačné servere) na strane NBS.

5. riadenie nasadzovania aplikácií,

6. prevádzku centrálneho SeriveDesk-u

7. poskytovanie základného poradenstva pre koncových používateľov informačného systému.

Úroveň L2 podpory prevádzky NBS DWH bude zabezpečená interným DWH tímom OIT NBS.

Úroveň L3 podpory prevádzky NBS DWH zabezpečí vybraný externý poskytovať na základe Zmluvy o poskytovaní služieb podpory prevádzky a rozvoja NBS DWH, ktorý bude garantovať:

• dostupnosť, funkčnosť a technickú podporu aplikačných komponentov riešenia

• riešenie aplikačných incidentov

• realizáciu vyžiadaných úprav a zmenových konaní v informačnom systéme

a to podľa požiadaviek uvedených v nasledujúcich častiach opisu.

Požiadavky na služby aplikačnej podpory prevádzky NBS DWH

Služby podpory prevádzky NBS DWH zahŕňajú predovšetkým:

1. Zabezpečenie bežnej servisnej podpory NBS DWH odbornými zamestnancami poskytovateľa pre riešenie hlásených incidentov, a to denne, v čase od 8:00 do 16:00 hodiny počas pracovných dní SR.

2. Odstraňovanie hlásených incidentov a odstraňovanie chýb v jednotlivých komponentoch NBS DWH, brániacich bezproblémovému používaniu informačného systému, s dodržaním požadovaných reakčných časov, resp. poskytnutie náhradného riešenia pri riešení incidentov.

3. Raz za štvrťrok vytvorenie reportu ako zhodnotenie stavu a priebehu aktualizácie dát v DWH

Zoznam činností vykonávaných v rámci Služieb podpory prevádzky

Služby podpory prevádzky NBS DWH zahŕňajú nasledovné činnosti:

• Podpora (Hotline)

  • Poskytovanie poradenstva súvisiaceho s prevádzkou

  • Vykonávanie bežných operatívnych zásahov (bez zmeny funkcionality)

  • pravidelná údržba riešenia – monitorovanie prostredia, pravidelné aplikovanie publikovaných SW záplat (okrem databáz).

  • denný monitoring ETL procesov (vyhodnocovanie systémových logov priebehu aktualizácie DWH) a opravovanie prípadných chýb implementácie.

  • proaktívna kontrola (profylaktika) ETL procesu – jej výsledkom je odporúčanie aktivít pre krátky a stredný časový horizont na zabezpečenie úspešného a optimálneho chodu aktualizácie

  • reportovanie zamerané na spracovávanie požadovaných reportov o incidentoch a operatívnych informácií o ich riešení,

  • poskytnúť súčinnosť požadovanú NBS pri prenesení uzavretého Problému do Produkčného prostredia.

  • Proaktívne informovať NBS o chybách v DWH systémoch, ktoré zistil sám

• Údržba (riadenie incidentov)

  • vedenie evidencie nahlásených Incidentov v systéme na evidenciu problémov.

  • identifikácia problému, jeho analýza a samotné riešenie

  • poskytovanie konzultácii o incidentoch

  • projektové riadenie servisných činností

  • riešenie eskalácií

• Školenia

  • Zabezpečovanie odborných školení podľa požiadaviek NBS (opcia na ročný rozsah vzdelávania a hodinové sadzby)

• Konzultačné služby

  • poskytovanie rád (odborných telefonických, mailových a osobných konzultácií) administrátorom a používateľom DWH ekosystému (opcia na ročný rozsah vzdelávania a hodinové sadzby)

• Implementácia (riadenie zmien)

  • analýza a realizácia požiadaviek na zmeny zo stany NBS – popísané v kap. 1.3

• Podpora SW tretích strán

  • Sledovanie nových verzií SW tretích strán

  • Podpora pri nasadzovaní nových verzií SW tretích strán

  • Sledovanie záplat pre SW tretích strán

  • Podpora pri nasadzovaní záplat SW tretích strán

• Doplnkové služby

  • Exit služba – podpora pri prechode na nového poskytovateľa

  • Podpora nového poskytovateľa 6 mesiacov po zmene poskytovateľa

Služby podpory prevádzky NBS DWH nezahŕňajú nasledovné činnosti:

• Riešenie problémov súvisiacich s kvalitou dát, resp. spracovaním dát v zdrojových systémoch

• Práce súvisiace s administráciou prostredí (UNIX, databázy, aplikačný server, BI nástroje)

• Realizácia požiadaviek na zmenu – tie sú riešené podľa kapitoly 4.3

Parametre kvality poskytovanej služby podpory prevádzky

Kvalita služieb podpory prevádzky DWH je definovaná nasledujúcimi ukazovateľmi:

• Dostupnosť podpory systému v rozsahu 8x5, t. j. denne, v čase od 8:00 do 16:00 hodiny počas pracovných dní SR.

• Reakčný čas odozvy na hlásený incident podľa zaradenia incidentu do kategórie. Zaradenie incidentu do príslušnej kategórie je na prvotnom posúdení verejného obstarávateľa. V prípade rozporu o zaradení incidentu budú obe strany rokovať o zaradení do príslušnej kategórie.

Detailné podmienky sú v návrhu zmluvy o prevádzke a údržbe systému (viď príloha).

Požiadavky na služby rozvoja systému

Požiadavky na realizáciu zmien na základe požiadaviek verejného obstarávateľa

Služby, ktoré sú požadované v rámci podpory riešenia:

• Realizácia zmien v riešení (formou požiadaviek na zmenu):

  • analýza požiadavky

  • vytvorenie technickej špecifikácie na riešenie požiadavky

  • implementácia nových ETL častí DWH riešenia

    • Vytvorenie programového kódu dohodnutého rozsahu

    • Nastavenie metadát príslušných frameworkov

    • Testovanie

    • Súčinnosť pri nasadení na produkciu

    • Údržba dokumentácie

  • implementácia dátových integrácií

  • úprava a dopĺňanie nových výstupných zostáv a reportov

• reinštalácie a rekonfigurácie modulov a softvérových komponentov DWH v prípade technologických zmien v prostredí NBS,

• verejným obstarávateľom vyžiadané školenia pre nové verzie frameworkov, ETL nastavení, číselníkov referenčných dát a iné

• verejným obstarávateľom vyžiadané administrátorské práce.

Parametre kvality poskytovanej služby rozvoja systému

Detailné podmienky sú uvedené v Zmluve o prevádzke, údržbe a rozvoji systému v prílohe F.

Servisné služby čiastkového plnenia

Verejný obstarávateľ požaduje poskytovanie týchto služieb od nasadenia jednotlivých fáz riešenia do produkcie. Služby budú poskytované do začiatku účinnosti Zmluvy o prevádzke, údržbe a rozvoji systému. Špecifikácia týchto služieb ja popísaná v prílohe G.

Prílohy

A – Zdrojové systémy NBS DWH

B – DataMarty NBS DWH

C – Metodika k predpisu NBS č.20/2020 o projektovom riadení

D – RACI matica

E – Projektový plán

F - Zmluva o prevádzke, údržbe a rozvoji systému

– osobitný dokument

G -Špecifikácia Servisných služieb čiastočného plnenia

Príloha č. 3: Harmonogram fakturačných míľnikov

Poradové číslo fakturačného celku/ Fáza Diela	Obsah fakturačného celku	Fakturačný míľnik – počet kalendárnych mesiacov od účinnosti zmluvy o dielo	Podiel ceny fakturačného míľniku z celkovej ceny predmetu zmluvy
1. Fáza Implementácia Relačnej časti DWH a začiatok dátovej integrácie	Infraštruktúra DWH (inštalácia frameworkov, vytvorenie DB, nastavenie governance)	6	16 %
	Design a Implementácia DWH (Rel. časť) + dátový model pre vybrané 4 zdroje (L0, L1)
	Integrácia vybratých 4 zdrojových systémov ako funkčný test frameworkov
	Vytvorenie DB časti (Datamart pre vybratný rozsah reportov)
	Vytvorenie základného rozsahu reportov (do 20)
	UAT
	Inštalácia na PROD
	Finálna akceptácia fázy
	Skúšobná prevádzka
2. Fáza Hlavné zdrojové systémy, príprava DL	Integrácia 10 zdrojových systémov	16	24 %
	Vytvorenie DB časti (Transakčná časť)
	Vytvorenie DB časti (Datamarty 1. etapy - kap. 3.3.2)
	Vytvorenie DL
	Vytvorenie "Výstupné zostavy" pre 3 strany pre 1. etapu
	Vytvorenie reportov pre 1. etapu
	UAT
	Inštalácia na PROD
	Finálna akceptácia fázy
	Skúšobná prevádzka
3. Fáza ďalšie zdrojové systémy, tvorba Datamartov, implemtácia DL	Integrácia 15 zdrojových systémov	27	29 %
	Vytvorenie DB časti (Transakčná časť)
	Vytvorenie DB časti (Datamarty 2. etapy - kap. 3.3.2)
	Výstupné zostavy pre 3 strany pre 2. etapu
	Vybudovanie sandboxov
	Napojenie DWH (rel.časť a DL) na štatistické frameworky
	Qlik - Napojenie na DWH – priame a ľahké transformácie z Qlik do DWH ETL
	UAT
	Inštalácia na PROD
	Finálna akceptácia fázy
	Skúšobná prevádzka
4. Fáza Dokončenie datamartov a DataDiscovery	Integrácia 3 zdrojových systémov + nezatriedené systemy	33	19 %
	Vytvorenie DB časti (Transakčná časť)
	Vytvorenie DB časti (Datamarty 3. etapy - kap. 3.3.2)
	Data Discovery vrstva DL
	UAT
	Inštalácia na PROD
	Finálna akceptácia fázy
	Skúšobná prevádzka
5. Fáza Ostatné zdroje	Integrácia zvyšných zdrojových systémov + nezatriedené systémy	36	12 %
	Vytvorenie DB časti (Transakčná časť)
	Vytvorenie DB časti (Datamarty 4. etapy - kap. 3.3.2)
	UAT
	Inštalácia na PROD
	Finálna akceptácia fázy
	Skúšobná prevádzka

Príloha č. 4: Špecifikácia ceny

< Vyplní uchádzač návrh cien uvedený v tabuľkách, ktoré na základe požiadaviek uvedených v časti „Spôsob určenia ceny“ súťažných podkladov predložil v rámci svojej súťažnej ponuky>

TABUĽKA č. 1 Cena za Dielo - dodaný informačný systém*

Položka		Označenie s popisom	Podiel ceny za xxxx Xxxxx z celkovej ceny Diela – dodaný informačný systém	Cena v EUR bez DPH
F1	1	Cena za 1. fázu Diela	16 %	<vyplní uchádzač>
F2	2	Cena za 2. fázu Diela	24 %	<vyplní uchádzač>
F3	3	Cena za 3. fázu Diela	29 %	<vyplní uchádzač>
F3	4	Cena za 4. fázu Diela	19 %	<vyplní uchádzač>
F5	5	Cena za 5. fázu Diela	12 %	<vyplní uchádzač>
CIR		Celková cena za Dielo/dodaný informačný systém CIR = F1 + F2 + F3 + F4 + F5	100 %	<vyplní uchádzač>

* celková cena za Dielo – dodaný informačný systém resp. čiastkového plnenia (jednotlivá fáza Diela) zahŕňa cenu Diela, resp. čiastkového plnenia, poskytovanie servisných služieb pre každé čiastkové plnenie do riadneho dodania Diela, udelenie súhlasu na používanie autorských diel, resp. iných predmetov práv duševného vlastníctva a dodanie resp. zabezpečenie poskytnutia potrebných licencií k SW produktom zhotoviteľa a 3. strán.

TABUĽKA č. 2 Cena za produkt subscription (predplatné) na DataLake

Položka	Názov produktu s popisom	Cena v EUR bez DPH produktu
Produkt – subscription (predplatné) na DataLake na 2,5 roka (30 mesiacov) podľa konfigurácie opísanej v opise predmetu zákazky kapitola 3.2.4 Fyzická architektúra (92CPU, 736 RAM)	<názov produktu a jeho popis vyplní uchádzač>	<vyplní uchádzač>
CCLDL	Celková cena za produkty – subscription (predplatné) na DataLake	<vyplní uchádzač>

TABUĽKA č. 3 Cena za ďalšie licencie pre SW

Xxxxxxx	Xxxxx licencie s popisom	Počet licencií	Xxxx v EUR bez DPH jedného kusu licencie
Ďalšie licencie pre SW (DL) s podporou výrobcu na 3 roky	<názov licencie a jej popis vyplní uchádzač>	<vyplní uchádzač>	<vyplní uchádzač>
	...	...	...
CCDL	Celková cena za ďalšie licencie pre  SW s podporou výrobcu vypočítaná ako: CCDL = počet kusov ďalších licencií pre SW x cena za jeden kus ďalšej licencie pre SW		<vyplní uchádzač>

TABUĽKA č. 4 Celková cena za predmet zmluvy

Položka	Označenie s popisom	Xxxx v EUR bez DPH
XXX	Xxxxxxx cena za Xxxxx	<vyplní uchádzač>
CCLDL	Celková cena za produkt subscription (predplatné) na DataLake	<vyplní uchádzač>
CCDL	Celková cena za ďalšie licencie pre SW	<vyplní uchádzač>
CCPZ	Celková cena predmetu zmluvy CCPZ = CIR + CCLDL + CCDL	<vyplní uchádzač>

Príloha č. 5:

Zoznam osôb zhotoviteľa určených na plnenie zmluvy

< Vyplní uchádzač – v tabuľke uvedie meno a priezvisko pracovníka, funkciu v projekte a kontaktné údaje, počet riadkov doplní uchádzač podľa potreby>

1. Zoznam zamestnancov zhotoviteľa určených na plnenie zmluvy

Meno a priezvisko	Funkcia	Telefónny kontakt	E-mailová adresa
< Vyplní úspešný uchádzač>	< Vyplní úspešný uchádzač>	< Vyplní úspešný uchádzač>	< Vyplní úspešný uchádzač>

2. Zoznam kľúčových expertov zhotoviteľa určených na plnenie zmluvy

Kľúčový expert	Xxxx a priezvisko	Telefónny kontakt	E-mailová adresa	Počet osobodní na predmete plnenia*
Kľúčový expert č. 1 – Projektový manažér	< Vyplní uchádzač>	< Vyplní uchádzač>	< Vyplní uchádzač>	< Vyplní uchádzač>
Kľúčový expert č. 2 – Architekt riešenia (Relačná časť DWH)	< Vyplní uchádzač>	< Vyplní uchádzač>	< Vyplní uchádzač>	< Vyplní uchádzač>
Kľúčový expert č. 3 – Architekt riešenia (BigData/DataLake časť DWH)	< Vyplní uchádzač>	< Vyplní uchádzač>	< Vyplní uchádzač>	< Vyplní uchádzač>
Kľúčový expert č. 4 – Senior Dátový Analytik	< Vyplní uchádzač>	< Vyplní uchádzač>	< Vyplní uchádzač>	< Vyplní uchádzač>
Kľúčový expert č. 5 – Data Ingestion Špecialista	< Vyplní uchádzač>	< Vyplní uchádzač>	< Vyplní uchádzač>	< Vyplní uchádzač>
Kľúčový expert č. 6 – ETL Špecialista	< Vyplní uchádzač>	< Vyplní uchádzač>	< Vyplní uchádzač>	< Vyplní uchádzač>
Kľúčový expert č. 7 – BI Špecialista	< Vyplní uchádzač>	< Vyplní uchádzač>	< Vyplní uchádzač>	< Vyplní uchádzač>

*osobodeň znamená jedna (1) osoba a osem (8) hodín práce počas pracovnej doby (od 8:00 h do 16:00 h) počas pracovných dní, pričom sa počíta iba naplnených osem hodín.

Kľúčový expert č. 1 – Projektový manažér:

Meno, priezvisko: <vyplní uchádzač>

Počet jeho osobodní na predmet plnenia: <vyplní uchádzač>

Expert musí spĺňať nasledujúce minimálne požiadavky:

• Minimálne 5 rokov odborných skúseností s projektovým riadením komplexných projektov oblasti informačných technológií; túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Získaný a platný certifikát PRINCE 2 Foundation na odbornú spôsobilosť pre riadenie projektov alebo ekvivalent (napr. IPMA B, PMP) daného certifikátu vydaný od inej akreditačnej a certifikačnej autority; túto podmienku účasti uchádzač preukáže kópiou certifikátu.

• Minimálne 1 praktická skúsenosť s realizáciou zákazky týkajúcej sa tvorby dátového skladu na pozícii projektového manažéra projektu počas celej doby trvania projektu s minimálnou hodnotou vo výške 1 500 000 eur bez DPH na implementáciu informačných systémov (a integrácií) v rozsahu analýza, návrh riešenia, implementácia a nasadenie informačného systému; túto podmienku účasti uchádzač u experta preukáže profesijným životopisom,

• Kľúčový expert č. 1 je zodpovedný za riadenie projektu na strane zhotoviteľa.

Kľúčový expert č. 2 – Architekt riešenia (Relačná časť DWH)

Meno, priezvisko: <vyplní uchádzač>

Počet jeho osobodní na predmet plnenia: <vyplní uchádzač>

Expert musí spĺňať nasledujúce minimálne požiadavky:

• Minimálne 7 rokov odbornej praxe v oblasti budovania DWH a dátovej integrácie, z toho minimálne 3 roky v roli Architekt; Kľúčový expert musí preukázať znalosť používania niektorých globálnych metodík (napr. Data Vault 2.0) budovania dátových skladov na daných projektoch; túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Predloženie minimálne jednej zákazky vo finančnej funkčnej oblasti (účtovníctvo, kontroling a podobne; nemusí byť z finančného sektora)
  v tejto metodike; túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Skúsenosti s Oracle SQL, PL/SQL, ladenie DB, dátového modelovanie, infraštruktúra, bezpečnostných nastavení riešenia; túto podmienku účasti uchádzač preukáže profesijným životopisom.

• Minimálne 1 praktická skúsenosť s realizáciou zákazky týkajúcej sa tvorby dátového skladu s minimálnym počtom 15 integrovaných systémov (nie objektov) v rôznych technológiách a spôsobov spracovania na pozícii architekta s tým, že na projekte musel odpracovať minimálne 200 osobodní (osobodeň znamená jedna (1) osoba a osem (8) hodín práce počas pracovnej doby (napr. od 8.00 h do 16.00 h) počas pracovných dní, pričom sa počíta iba naplnených osem hodín); túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Kľúčový expert č. 2 je zodpovedný za celkovú architektúru relačnej časti DWH, tvorbu konceptuálneho modelu DWH, návrh fyzického modelu, návrh data flow.

Kľúčový expert č. 3 – Architekt riešenia (BigData/DataLake časť DWH)

Meno, priezvisko: <vyplní uchádzač>

Počet jeho osobodní na predmet plnenia: <vyplní uchádzač>

Expert musí spĺňať nasledujúce minimálne požiadavky:

• Minimálne 7 rokov odbornej praxe v oblasti budovania DWH a dátovej integrácie, z toho minimálne 3 roky odbornej praxe v oblasti budovania DataLake s BigData technológiami; túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Skúsenosti s technológiami a metódami BigData – HDFS, Hive, Hbase, Spark, Nifi, Impala, SQL, ladenie prostredí, infraštruktúra, bezpečnostných nastavení riešenia; preukazuje účasťou na predchádzajúcich projektoch v v roli Architekta, a/alebo Špecialistu ETL a/alebo Dátového dizajnéra; túto podmienku účasti uchádzač preukáže profesijným životopisom.

• Minimálne 1 praktická skúsenosť s realizáciou zákazky týkajúcej sa tvorby dátového skladu s minimálnym počtom 15 integrovaných systémov (nie objektov) na pozícii dátového architekta s tým, že na projekte musel odpracovať minimálne 200 osobodní (osobodeň znamená jedna (1) osoba a osem (8) hodín práce počas pracovnej doby (napr. od 8.00 h do 16.00 h) počas pracovných dní, pričom sa počíta iba naplnených osem hodín) na pozícii dátového architekta; túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Kľúčový expert č. 3 je zodpovedný za celkovú architektúru DataLake časti DWH, tvorbu konceptuálneho modelu, návrh fyzického modelu, návrh data flow.

Kľúčový expert č. 4 – Senior Dátový Analytik

Meno, priezvisko: <vyplní uchádzač>

Počet jeho osobodní na predmet plnenia: <vyplní uchádzač>

Expert musí spĺňať nasledujúce minimálne požiadavky:

• Minimálne 5 rokov odbornej praxe v oblasti analýzy a modelovania informačných systémov; túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Minimálne 1 praktická skúsenosť s riešením úloh spojených s analýzou systémov, s investigatívou funkčností systémov, návrhov dátových modelov zákazky týkajúcej sa tvorby dátového skladu na pozícii Data Acquisition experta, či dátového analytika alebo dátového návrhára zodpovedného za tvorbu Konceptuálny dátový modelu a fyzický dátový modelu riešenia s tým, že na projekte musel odpracovať minimálne 200 osobodní (osobodeň znamená jedna (1) osoba a osem (8) hodín práce počas pracovnej doby (napr. od 8.00 h do 16.00 h) počas pracovných dní, pričom sa počíta iba naplnených osem hodín) na vyššie uvedenej pozícií; túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Kľúčový expert č. 4 je zodpovedný za analýzu a návrh dátového modelu NBS DWH, participuje pri tvorbe dokumentácie Architecture Blueprint a priamo je zodpovedný za informácie v dokumentoch: Analýza zdrojových systémov, Konceptuálny dátový model a fyzický dátový model.

Kľúčový expert č. 5 – Data Ingestion Špecialista

Meno, priezvisko: <vyplní uchádzač>

Počet jeho osobodní na predmet plnenia: <vyplní uchádzač>

Expert musí spĺňať nasledujúce minimálne požiadavky:

• Minimálne 5 rokov odbornej praxe v oblasti budovania dátových skladov na pozícii ETL developer pre úlohy získavania dát (Data Acquisition); túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Minimálne 1 praktická skúsenosť s riešením úloh spojených s metodikami spracovania veľkého objemu dát, in-memory spracovaním, data enrichment (rozšírením dátových tokov o odvodené dáta), analýzou dát a prípravou vstupného mapovania zákazky týkajúcej sa tvorby dátového skladu, kde bol zodpovedný za návrh a implementáciu nástroja na spracovanie transakcií s minimálnym počtom 15 zdrojových systémov a v rozsahu spracovania v súhrne minimálne 15 miliónov transakcií v jednom dennom spracovaní a na projekte musel odpracovať minimálne 200 osobodní (osobodeň znamená jedna (1) osoba a osem (8) hodín práce počas pracovnej doby (napr. od 8.00 h do 16.00 h) počas pracovných dní, pričom sa počíta iba naplnených osem hodín) na pozícii vyššie uvedenej pozícií; túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Kľúčový expert č. 5 je zodpovedný za implementáciu a nastavenie kľúčového komponentu NBS DWH - Ingestion frameworku.

Kľúčový expert č. 6 – ETL Špecialista

Meno, priezvisko: <vyplní uchádzač>

Počet jeho osobodní na predmet plnenia: <vyplní uchádzač>

Expert musí spĺňať nasledujúce minimálne požiadavky:

• Minimálne 5 rokov odbornej praxe v oblasti budovania dátových skladov na pozícii ETL developer s použitím nástroja Oracle Data Integrátor, minimálne 2 roky na administrátorskej úrovni tohto nástroja; túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Expertné skúsenosti s ETL technológiami (no-code/low-code techniky) a ladením Oracle SQL úloh (nevyžaduje sa znalosť ladenia databázy); túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Minimálne 1 praktická skúsenosť s realizáciou zákazky týkajúcej sa tvorby dátového skladu, kde bol zodpovedný za návrh a implementáciu ETL a na projekte musel odpracovať minimálne 200 osobodní (osobodeň znamená jedna (1) osoba a osem (8) hodín práce počas pracovnej doby (napr. od 8.00 h do 16.00 h) počas pracovných dní, pričom sa počíta iba naplnených osem hodín) na pozícii ETL developer; túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Kľúčový expert č. 6 je zodpovedný za nastavenie prostredí ETL nástroja, nastavenie topológie, prístupových práv, vytvorenie dokumentov popisujúcich štandardy vývoja, prípravu nových Knowledge modulov, inštalácia a prevádzka Workflow manager frameworku

Kľúčový expert č. 7 – BI Špecialista

Meno, priezvisko: <vyplní uchádzač>

Počet jeho osobodní na predmet plnenia: <vyplní uchádzač>

Expert musí spĺňať nasledujúce minimálne požiadavky:

• Minimálne 5 rokov odbornej praxe v oblasti budovania dátových skladov na pozícii BI developer s použitím nástroja Microsoft Power BI, minimálne 2 roky na administrátorskej úrovni tohto nástroja; túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Expertné skúsenosti s SQL, Microsoft TOLAP, Microsoft SQL Server a jej ladenie); túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Minimálne 1 praktickú skúsenosť s riešením úloh spojených s návrhom a realizáciou BI riešenia zákazky týkajúcej sa tvorby dátového skladu na pozícii BI špecialista a na projekte musel odpracovať minimálne 150 osobodní (osobodeň znamená jedna (1) osoba a osem (8) hodín práce počas pracovnej doby (napr. od 8.00 h do 16.00 h) počas pracovných dní, pričom sa počíta iba naplnených osem hodín) na pozícii BI špecialista; túto podmienku účasti uchádzač u experta preukáže profesijným životopisom.

• Kľúčový expert č. 7 je zodpovedný za návrh a nastavenie BI platformy, ETL časti DWH pre načítanie dát do TOLAP. Takisto bude zodpovedný za návrh a nastavenie celkovej bezpečnosti prístupu k dátam v BI oblasti. Vyžaduje sa preukázať schopnosť s nastavením bezpečnostných pravidiel Power BI s priamym napojením na Oracle DB.

Zoznam osôb zhotoviteľa určených na plnenie zmluvy a subdodávateľov zhotoviteľa

Zoznam subdodávateľov zhotoviteľa

V súlade s ustanovením § 41 ods. 3 zákona o verejnom obstarávaní verejný obstarávateľ požaduje od úspešného uchádzača, aby najneskôr v čase uzavretia zmluvy uviedol:

1. údaje všetkých známych subdodávateľoch v rozsahu obchodné meno, sídlo, IČO, zápis do príslušného obchodného registra;

2. údaje o osobe oprávnenej konať za subdodávateľa v rozsahu meno a priezvisko, adresa pobytu, dátum narodenia.

< Vyplní uchádzač – v tabuľke uvedie obchodné meno subdodávateľa ako je uvedené v obchodnom registri SR, sídlo subdodávateľa., počet riadkov doplní uchádzač podľa potreby>

Obchodné meno, sídlo subdodávateľa a IČO	Osoba oprávnená konať za subdodávateľa (meno a priezvisko, adresa pobytu, dátum narodenia)
< Vyplní uchádzač>	< Vyplní uchádzač>

Príloha č. 6 k zmluve o dielo

Slovník pojmov

Pojem (y) / Výraz / Skratka	Vysvetlenie Pojmu / Výrazu / Skratky
Aktualizácie	zmluvné strany rozumejú zmeny, zdokonalenia alebo zlepšenia dodávaného systému (licencovaných programov), ktoré zhotoviteľ bude podľa vlastného uváženia určovať a voliť na zabudovanie do dodávaného systému (licencovaných programov) a vytváranie ich častí, namiesto separátnych softvérových programov. Uvedené aktualizácie poskytuje zhotoviteľ objednávateľovi podľa podmienok tejto zmluvy.
Dielo	zmluvné strany rozumejú všetky služby, práce a súvisiace plnenia, ktoré je zhotoviteľ povinný plniť za podmienok tejto zmluvy o dielo v prospech objednávateľa, vrátane udelenia licenčných práv na používanie diela a dodanie dokumentácie diela.
Dodať podľa tejto zmluvy, Odovzdať	zmluvné strany rozumejú dodanie dodávky, uvedenej v popise predmetu zmluvy a záväzkoch zhotoviteľa v tejto zmluve zhotoviteľom objednávateľovi podľa zmluvných podmienok, záväzkov, štandardov, postupov a oprávnení uvedených v tejto zmluve. Táto skutočnosť musí byť písomne potvrdená zhotoviteľom a objednávateľom v príslušnom protokole.
Dodávaný/dodaný systém alebo dodávaný/dodaný informačný	Centrálny celobankový dátový sklad – Dielo, ktoré je predmetom tejto zmluvy o dielo
Dostupnosť služby	rozumie sa čas, kedy je služba zhotoviteľa poskytovaná objednávateľovi.
Doba odozvy	rozumie sa časové obdobie, počas ktorého je zhotoviteľ povinný začať vykonávať príslušnú činnosť od nahlásenia požiadavky objednávateľa na jej vykonanie.
Dôverná informácia druhej zmluvnej strany	zmluvné strany rozumejú každý dokument, materiál, myšlienku, údaje alebo iné informácie vzťahujúce sa k výskumu a vývoju, obchodným tajomstvám, bankovým a služobným tajomstvám alebo obchodným záležitostiam zhotoviteľa alebo objednávateľa alebo sú označené ako dôverné, a ktorejkoľvek zo strán dané druhou stranou iba pre účely tejto zmluvy.
HTP	Hlavné technologické pracovisko Národnej banky Slovenska
Chyba	Chybu predstavuje akékoľvek nesplnenie požiadaviek na dodávaný informačný systém, nesplnenie stanovených štandardov, neschválené odchýlky od stanovenej funkcionality dodávaného systému, nedodržanie postupov stanovených pre analýzu, návrh, implementovanie, testovanie a spracovanie dokumentácie dodávaného systému a používanie iných ako stanovených softvérových nástrojov. Chybu predstavuje aj nevykonávanie alebo iba čiastočné vykonávanie funkcií komponentov, modulov, objektov a programov špecifikovaných v sprievodnej dokumentácií dodávaného systému.
Incident	každá udalosť, ktorá nie je štandardnou funkčnosťou dodávaného systému, infraštruktúry dodávaného systému alebo prevádzky osobných počítačov používateľov dodávaného systému a môže spôsobiť alebo spôsobila výpadok alebo zníženie funkcionality a výkonnostných parametrov dodávaného systému, infraštruktúry dodávaného systému alebo prevádzky osobných počítačov používateľov dodávaného systému.
Inštalácia	zmluvné strany rozumejú inštaláciu všetkých komponentov, programov a dát dodávaného informačného systému. Táto inštalácia môže byť vykonaná testovacom prostredí a/alebo v produkčnom prostredí u objednávateľa.
Kľúčoví experti	Riešitelia na strane zhotoviteľa s nasledujúcimi zodpovednosťami: Kľúčový expert č. 1 – Projektový manažér Kľúčový expert č. 2 – Architekt riešenia (Relačná časť DWH) Kľúčový expert č. 3 – Architekt riešenia (BigData/DataLake časť DWH) Kľúčový expert č. 4 – Senior Dátový Analytik Kľúčový expert č. 5 – Data Ingestion Špecialista Kľúčový expert č. 6 – ETL Špecialista Kľúčový expert č. 7 – BI Špecialista
Konfigurácia	konfigurácia je úplný technický popis logicky zviazanej sady konfiguračných položiek potrebný pre tvorbu, testovanie, prevzatie, inštaláciu, prevádzku, údržbu a podporu dodávaného systému. Zahŕňa dodávaný systém a jeho sprievodnú dokumentáciu.
Konfigurácia, verzia	konfigurácia môže mať niekoľko verzií zobrazujúcich kompletizáciu dodávaného systému. Konfigurácia prechádza úpravami pri vývoji, testovaní a opravovaní zistených chýb alebo implementácii požiadaviek na zmenu. Prvá verzia konfigurácie je zaznamenaná ako verzia 1.00.0. Zmeny konfigurácie sú odlišované číslom verzie, revízie a čiastkovej revízie.
Kontrola kvality	kontrola kvality je porovnaním produktu (alebo skupiny súvisiacich produktov) s odsúhlasenými kritériami kvality. Tieto kritéria sú definované pre všetky typy produktov a sú súčasťou sprievodnej dokumentácie.
KPI	Metrika (meraný parameter), ktorá pomáha riadiť a spravovať proces, IT službu alebo aktivitu. Je možné merať rôzne metriky (parametre - typicky počet, čas, kapacita), ale iba najdôležitejšie z nich sa definujú ako KPI a používajú sa pre aktívne manažovanie a reportovanie procesu, IT služby, alebo aktivity.
Kritérium kvality	kritérium kvality predstavuje tie charakteristiky produktu, ktoré určujú, či produkt spĺňa požiadavky pre produkt stanovené.
Kvalita	celkový súhrn znakov prvku, ktoré ovplyvňujú jeho schopnosť uspokojiť stanovené a predpokladané potreby.
Lehota služby	rozumie sa časové obdobie, počas ktorého je zhotoviteľ povinný dokončiť vykonávanie príslušnej činnosti od prevzatia požiadavky vyhlasovateľa na jej vykonanie. V prípade zásadného, závažného a nepodstatného incidentu môže uchádzač navrhnúť náhradné riešenie, čím však nie je zbavený povinností vyriešiť incident v náhradnom termíne dohodnutom vyhlasovateľom.
Nedostatok	predstavuje nesplnenie skúšobnej podmienky stanovenej na overenie požadovaných funkčných, technických, prevádzkových a bezpečnostných vlastností dodávaného systému počas akceptačného testovania dodávaného systému.
Osobodeň	zmluvné strany rozumejú práce a služby 1 osoby počas 8 hodín pracovného dňa
Požiadavka na zmenu	predstavuje prostriedok na modifikáciu dodávaného systému, t.j. akýkoľvek návrh a podnet, ktorého cieľom je zmeniť vlastnosti dodávaného systému voči požiadavkám na systém so zámerom zlepšiť vlastnosti dodávaného systému a podporiť úspešnosť realizácie projektu.
Pracovná doba	Za pracovnú dobu sa pre účely zmluvy rozumie časové obdobie v pracovných dňoch medzi 8.00 h – 16.00 h, pričom pre účely odstraňovania incidentov dodávaného systému sa pracovnou dobou počas Skúšobnej prevádzky dodávaného systému rozumie časové obdobie medzi 7.00 – 23.00 h v pracovných dňoch platobného systému TARGET2, ktorými sú všetky dni okrem soboty, nedele, Nového roku, Veľkého piatku a Veľkonočného pondelka (podľa kalendára platného v sídle ECB),1. mája, prvého sviatku vianočného a druhého sviatku vianočného .
Prijatý, Xxxxxxxx, Prijať	pojmy „Prijatý“, ”Prijatie”, „Prijať“ tak, ako sú uvádzané v zmluve znamenajú pre obidve zmluvné strany, že: akákoľvek dodávka uvedená v popise predmetu tejto zmluvy a/alebo akýkoľvek záväzok zhotoviteľa boli zo strany zhotoviteľa splnené podľa podmienok, štandardov, procedúr a kritérií tejto zmluvy, a ktorých splnenie objednávateľ podľa podmienok tejto zmluvy písomne odsúhlasil (akceptoval), akákoľvek dodávka uvedená v popise predmetu tejto zmluvy a/alebo akýkoľvek záväzok zhotoviteľa boli na základe predchádzajúceho objednávateľom odsúhlaseného splnenia (akceptácie) fyzicky dodané zhotoviteľom objednávateľovi v mieste objednávateľa a ktoré objednávateľ fyzicky prijal.
Prevzatý, Prevzatie, Prevziať	pojmy „Prevzatý“, ”Prevzatie”, Prevziať“ tak ako sú uvádzané v zmluve znamenajú pre obidve zmluvné strany, že: akákoľvek dodávka uvedená v popise predmetu tejto zmluvy a/alebo akýkoľvek záväzok zhotoviteľa boli zo strany zhotoviteľa fyzicky dodané objednávateľovi v mieste objednávateľa za účelom ich prevzatia napr. na informovanie objednávateľa, na vykonanie akceptačného testovania, na vykonanie pripomienkovania a akceptovania dokumentov, na zaistenie kvality riadenia projektu a na zaistenie kvality dodávaného systému a objednávateľ ich k uvedenému účelu fyzicky prevzal. fyzické prevzatie dodávky a/alebo záväzku zhotoviteľa potvrdia zhotoviteľ a objednávateľ písomne vo funkčnom prijímacom protokole. účel a stav dodávky alebo záväzku zhotoviteľa musí byť jednoznačne uvedený prijímacom protokole.
Problém	predstavuje akúkoľvek skutočnosť identifikovanú počas a priamo súvisiace s realizáciou predmetu zmluvy o dielo, ktorú zhotoviteľ a/alebo objednávateľ považujú za prekážku pri ďalšej realizácii predmetu zmluvy o dielo podľa schváleného plánu projektu.
Produkčné prostredie	zmluvné strany rozumejú technické zariadenia a programové vybavenie (softvér) a všetky údaje nachádzajúce sa u objednávateľa vrátane nastavenia ich parametrov určené k produkčnej prevádzke dodávaného informačného systému.
Produkt	predstavuje akýkoľvek výstup projektu, t.j. softvér, hardvér, dokumentácia a údaje. Popis produktu popisuje jeho účel, formát (podobu), prvky, z ktorých sa skladá, t.j. komponenty, a kvalitatívne kritéria, ktorým musia vyhovieť. Každý produkt má svoj popis. Čiastkové produkty komplexných produktov môžu mať svoje vlastné popisy a samotné sa môže skladať z ďalších produktov, podproduktov.
Prostredie	zmluvné strany rozumejú testovacie a/alebo produkčné prostredie objednávateľa, ktoré je inštalované v priestoroch objednávateľa na používanie s dodávaným systémom.
Riadenie	proces plánovania, zabezpečenia, kontrolovania a vyhodnocovania činností pri realizácii projektu a kompletizovaní dodávaného systému.
Riadiaci orgán projektu	predstavuje tú úroveň v rámci riadiacej organizačnej štruktúry projektu, ktorá má oprávnenia a zodpovednosť na rozhodovanie o vecnej oblasti riadenia projektu, t.j. riadiaci orgán projektu predstavujú vedúci projektu zhotoviteľa a objednávateľa v rámci oprávnení a zodpovedností delegovaných vedúcemu projektu objednávateľa riadiacou radou projektu, resp. riadiaca rada projektu, ak vedúci projektu zhotoviteľa a objednávateľa nedokážu zaujať spoločné stanovisko k prerokovávanej vecnej oblasti projektu alebo vedúci projektu objednávateľa nemá postačujúce oprávnenia rozhodovať o vecnej oblasti projektu. V prípade, že ani riadiaca rada projektu nemá dostatočné oprávnenia rozhodovať, o vecnej oblasti projektu rozhoduje štatutárny orgán objednávateľa.
Riziko	predstavuje akúkoľvek skutočnosť identifikovanú pred začatím realizácie projektu, resp. začatím realizácie jednotlivých etáp projektu, ktoré môžu negatívne ovplyvniť úspešnosť realizácie projektu a kvalitu dodávaného systému, a ktorých dopad na úspešnosť realizácie projektu je možné včasným prijatím protiopatrení zmenšiť alebo odstrániť.
SLA	Service level agreement – dohoda o úrovni poskytovaných služieb, definuje rozsah, úroveň a intenzitu služieb poskytovaných zhotoviteľom objednávateľovi.
Testovacie prostredie	zmluvné strany rozumejú technické zariadenia a programové vybavenie (softvér) a všetky údaje nachádzajúce sa u objednávateľa vrátane nastavenia ich parametrov určené k akceptačnému testovaniu dodávaného systému.
Výkaz	zmluvné strany rozumejú tlačový výstup vyhotovený vo formáte a grafickej úprave, ktorý je predpísaný internými aktmi riadenia objednávateľa alebo všeobecne záväznými právnymi predpismi. Tlač môže byť vykonávaná na (čistý) papier formátu A4 a A3 podľa formátu požadovaného výkazu.
Zhotoviteľ	subjekt/organizácia/spoločnosť/firma, ktorá dodáva, zabezpečuje a zodpovedá za dodávky, práce a služby uvedené v popise predmetu tejto zmluvy a vo svojich záväzkoch v tejto zmluve pre objednávateľa.
Zmluva, zmluva, táto zmluva, tejto zmluvy	rozumie sa zmluva o dielo číslo E-531.10.1006.00. Uvedený pojem zahŕňa zmluvu vrátane všetkých príloh, ktoré tvoria jej neoddeliteľnú súčasť a každý iný dokument, ktorý sa dohodne medzi stranami a výslovne určí, aby tvoril súčasť tejto zmluvy a zahŕňa každú zmenu tejto zmluvy, ktorú zmluvné strany dohodli písomne.
Zmluvná strana	rozumie sa objednávateľ alebo zhotoviteľ.
ZTP	Záložné technologické pracovisko Národnej banky Slovenska
Modul	je od zvyšku dodaného informačného systému oddeliteľná časť vytvorená zhotoviteľom pri plnení tejto zmluvy o dielo, a ktorá je bez úpravy použiteľná aj tretími osobami, aj na iné alebo podobné účely, ako je účel vyplývajúci z tejto zmluvy o dielo
Proprietárny SW	je softvér 3. strany na ktorý sa nevzťahujú osobitné licenčné podmienky upravené v zmluve o dielo
SW 3. strany	je softvérový produkt/softvérové riešenie, ktoré spĺňa znaky preexistentného obchodne dostupného softvéru, preexistentného obchodne nedostupného softvéru, preexistentného open source softvéru
HW	je hardvérový produkt, t. j. hotový výrobok/tovar týkajúci sa alebo predstavujúci celkové technické vybavenie počítača, servera alebo iného technického zariadenia; HW samostatne nie je výsledkom tvorivej duševnej činnosti, ale súčasťou HW môže byť aj SW alebo SW 3. strany
SW	je softvérový produkt/softvérové riešenie, ktoré spĺňa znaky počítačového programu/počítačových programov, a tvorí súčasť dodaného informačného systému vrátane s ním súvisiacej dokumentácie a manuálov a bol dodaný zhotoviteľom v rámci plnenia tejto zmluvy o dielo
Dokumentácia	dokumentáciou sa rozumie technická, prevádzková, užívateľská a iná dokumentácia, ktorá vyplýva z ustanovení tejto zmluvy o dielo alebo ktorá čo i len sčasti súvisí s vyhotovením a dodaním Diela /dodaného informačného systému
Skratky právnych predpisov
Autorský zákon		zákon č. 185/2015 Z. z. Autorský zákon v znení neskorších predpisov
GDPR		nariadenie Európskeho parlamentu a Rady (EÚ) 2016/679 z 27. apríla 2016 o ochrane fyzických osôb pri spracúvaní osobných údajov a o voľnom pohybe takýchto údajov, ktorým sa zrušuje smernica 95/46/ES (všeobecné nariadenie o ochrane údajov)
Obchodný zákonník		zákon č. 513/1991 Zb. Obchodný zákonník v znení neskorších predpisov
Trestný poriadok		zákon č. 301/2005 Z. z. Trestný poriadok v znení neskorších predpisov
Trestný zákon		zákon č. 300/2005 Z. z. Trestný zákon v znení neskorších predpisov
Zákon o ochrane osobných údajov		zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov v znení neskorších predpisov
Zákon o registri partnerov verejného sektora		zákon č. 315/2016 Z. z. o registri partnerov verejného sektora a o zmene a doplnení niektorých zákonov v znení neskorších predpisov
Zákon o slobodnom prístupe k informáciám		zákon č. 211/2000 Z. z. o slobodnom prístupe k informáciám a o zmene a doplnení niektorých zákonov (zákon o slobode informácií) v znení neskorších predpisov
Zákon o trestnej zodpovednosti právnických osôb		zákon č. 91/2016 Z. z. o trestnej zodpovednosti právnických osôb a o zmene a doplnení niektorých zákonov v znení neskorších predpisov

Príloha č. 7 Zoznam použitých SW a SW 3. strán

A. Použitý SW zhotoviteľa

Xxxxxxx	Xxxxx s popisom	Výrobca/autor a typ použitého SW	Licencia k SW	Počet ks	Jednotková cena	Celková cena
1	vyplní uchádzač	vyplní uchádzač	vyplní uchádzač	vyplní uchádzač	vyplní uchádzač	vyplní uchádzač
x	...	...	..	...	...	...
Spolu:		-	-	vyplní uchádzač	vyplní uchádzač	vyplní uchádzač

B. Použitý SW 3. strán

Xxxxxxx	Xxxxx s popisom	Výrobca/autor a typ použitého SW	Licencia k SW	Počet ks	Jednotková cena	Celková cena
1	vyplní uchádzač	vyplní uchádzač	vyplní uchádzač	vyplní uchádzač	vyplní uchádzač	vyplní uchádzač
x	...	...	...	...	...	...
Spolu:		-	-	vyplní uchádzač	vyplní uchádzač	vyplní uchádzač

Zoznam SW, ktoré plánuje zhotoviteľ použiť pri vytváraní, zhotovovaní a dodaní Diela (dodávaného informačného systému) a ktoré sú mu známe ku dňu podpisu tejto zmluvy o dielo).

^{Obsah tohto zoznamu je možné meniť na projektovej úrovni, schválen}ím Riadiacou radou bez nutnosti osobitného písomného dodatkovania tejto zmluvy o dielo.

Príloha č. 8

Klasifikácia vád dodaného informačného systému, lehoty na ich odstránenie

1. Klasifikácia vád dodaného informačného systému

Ak je výsledkom vykonania akceptačných testov zistenie, že Dielo alebo jeho časť nespĺňa dohodnutú funkčnosť Diela v zmysle Prílohy č. 2 tejto zmluvy o dielo a tým nenapĺňa účel a cieľ tejto zmluvy o dielo, a to z dôvodov, za ktoré zodpovedá zhotoviteľ, Dielo má vady. Zhotoviteľ zodpovedá za vady Xxxxx v čase jeho odovzdania objednávateľovi. Vady Diela sú klasifikované nasledovne:

1. „Zásadná vada (A)“

je spôsobený chybou alebo nedostatkom Diela a táto chyba a/alebo nedostatok zabraňuje jeho riadnemu používaniu v prevádzke (neschopnosť spracovať bežnú prevádzkovú záťaž) a dodržanie predpokladaného časového plánu akceptačných testov nie je možné, pričom spôsobuje že:

1. aplikačné funkcie Diela nie sú funkčné ako celok, alebo ide o takú chybu alebo nedostatok Diela, ktorý neumožní úspešne realizovať bankové procesy v NBS podporované Dielom alebo

2. aplikačné funkcie Diela, prostredníctvom ktorých sa realizujú časovo závislé bankové procesy súvisiace najmä s hotovostnými, majetkovými prevodmi a účtovnými procedúrami, nie sú úplne funkčné, alebo

3. aplikačné funkcie Diela, ktoré majú priamy dopad na riadny chod NBS, nie sú funkčné.

2. „Závažná vada (B)“

je spôsobený chybou alebo nedostatkom Diela a táto chyba a/alebo nedostatok zabraňuje jeho plnohodnotné používaniu v prevádzke (neschopnosť spracovať maximálnu možnú prevádzkovú záťaž) a ohrozuje ďalšie pokračovania akceptačných testov, pričom spôsobuje, že:

1. aplikačné funkcie Diela neumožňujú vykonanie činnosti a/alebo vytvorenie výstupov, ktoré NBS potrebuje na splnenie svojich záväzkov voči externým subjektom,

2. aplikačné funkcie Diela, prostredníctvom ktorých sa realizujú časovo závislé bankové procesy súvisiace najmä s využívaním dát z dátového skladu, napr. v procese výkonu verejnej moci nie sú čiastočne funkčné.

3. „Nepodstatná vada (C)“

do tejto klasifikácie spadajú všetky chyby alebo nedostatky prevádzky Diela, ktoré nie sú klasifikované ako Zásadná vada (A) alebo Závažná vada (B), pričom sa jedná o vadu, ktorá spôsobí čiastočný neúspech akceptačných testov a ktorá sa prejaví iba niekedy, pričom:

1. incidenty tejto klasifikácie síce obmedzujú používanie Diela, ale v zásade neobmedzujú základné funkcie a prevádzku tohto Diela.

2. Doby, Lehoty v súvislosti s odstraňovaním vád

Reakčná doba je pre zhotoviteľa stanovený čas, do ktorého vykoná prevzatie, potvrdenie prevzatia a preverenie nahlásenej vady a zaháji jej riešenie konkrétnym riešiteľom a ktorá začína plynúť nahlásením vady postupom v zmysle článku VII bod 7.8. tejto zmluvy o dielo. Do reakčnej doby sa nezapočítava čas, kedy nie je možné zo strany objednávateľa sprístupnenie Diela za účelom odstránenia vady.

Doba neutralizácie vady je čas, do ktorého je zhotoviteľa povinný zabezpečiť, resp. dosiahnuť dočasný režim funkčnosti Diela objednávateľa (funkcia a plánovaná použiteľnosť Diela objednávateľa je v zmysle požiadaviek a funkčnej špecifikácie síce poskytovaná odlišne, avšak nie je podstatne ovplyvňované jej pôvodne plánované použitie) vytvorením náhradného postupu alebo dočasného riešenia; čas je počítaný iba v rámci pracovných hodín uvedených nižšie od okamihu nahlásenia vady objednávateľom.

Doba trvalého vyriešenia je čas, do ktorého je Zhotoviteľ povinný zabezpečiť, resp. uplatniť trvalé riešenie do Diela objednávateľa (funkčnosť Diela objednávateľa, resp. jeho jednotlivých funkčností alebo služieb v zmysle dokumentácie Diela objednávateľa bola plne obnovená), pričom čas je počítaný iba v rámci pracovných hodín uvedených nižšie od okamihu nahlásenia vady Oprávnenou osobou objednávateľa.

Klasifikácia vady	Typ doby	Požadované lehoty
Zásadná vada (A)	Reakčná doba	do 4 pracovných hodín
	Doba neutralizácie vady	do 8 pracovných hodín
	Doba trvalého vyriešenia	do 2 pracovných dní
Závažná vada (B)	Reakčná doba	do 4 pracovných hodín
	Doba neutralizácie vady	do 8 pracovných hodín
	Doba trvalého vyriešenia	do 5 pracovných dní
Nepodstatná vada (C)	Reakčná doba	do 3 pracovných dní
	Doba neutralizácie vady	do 6 pracovných dní
	Doba trvalého vyriešenia	do 10 pracovných dní

1 Xxxxxx Xxxxxxxx, Xxxxxxx Xxxxxxxxx (2015). Building a Scalable Data Warehouse with Data Vault 2.0. Xxxxxx Xxxxxxxx. ISBN: 978-0-12-802510-9