PROJEKTOVÝ ZÁMER

(Project brief)

Identifikovanie požiadaviek na funkčnú časť riešenia

Identifikácia projektu

Schvaľovanie dokumentu

Obsah

Obsah         2

1. POPIS ZMIEN DOKUMENTU................................................................................................................... 3

1.1.              História zmien................................................................................................................................. 3

1. ÚČEL DOKUMENTU, SKRATKY (KONVENCIE) A DEFINÍCIE.................................................................... 3

2.1.              Použité skratky............................................................................................................................... 3

2.1.1.                  Konvencie pre typy požiadaviek.......................................................................................... 3

1. DEFINOVANIE PROJEKTU....................................................................................................................... 4

3.1.              Manažérske zhrnutie...................................................................................................................... 4

3.1.1.                  Predstavenie Sociálnej poisťovne........................................................................................ 4

3.1.2.                  Organizačné usporiadanie a agendy................................................................................... 4

3.1.3.                  Kontext projektu a poslania Sociálnej poisťovne................................................................ 5

3.2.              Motivácia a rozsah projektu........................................................................................................... 6

3.2.1.                  Problém, ktorý bude realizáciou projektu odstránený....................................................... 7

3.2.2.                  Biznis procesy, ktoré sú predmetom projektu.................................................................... 9

3.2.3.                  Informácie o oblasti (OBSAH / AGENDA / ŽIVOTNÁ SITUÁCIA), ktorým sa projekt venuje                  9

3.3.              Zainteresované strany/Stakeholderi.............................................................................................. 9

3.4.              Ciele projektu a merateľné ukazovatele....................................................................................... 10

3.5.              Riziká a závislosti.......................................................................................................................... 11

3.6.              Alternatívy a Multikriteriálna analýza........................................................................................ 13

3.6.1.                  Stanovenie alternatív pomocou biznisovej vrstvy architektúry...................................... 13

3.6.2.                  Multikriteriálna analýza..................................................................................................... 14

3.6.3.                  Stanovenie alternatív pomocou aplikačnej vrstvy architektúry...................................... 18

1. POŽADOVANÉ VÝSTUPY (PRODUKT PROJEKTU)................................................................................ 18

4.1.1.                  Stanovenie alternatív pomocou technologickej vrstvy architektúry............................... 21

1. NÁHĽAD ARCHITEKTÚRY...................................................................................................................... 21

5.1.              Popis budúceho cieľového produktu projektu z pohľadu biznis architektúry............................... 21

5.1.1.                  Používatelia riešenia.......................................................................................................... 21

5.1.2.                  Základné biznis požiadavky................................................................................................ 22

5.1.3.                  Vplyv na existujúci proces  a okolité prostredie............................................................... 23

5.1.4.                  Súlad s legislatívou............................................................................................................. 23

5.1.5.                  Integrácie............................................................................................................................ 25

5.1.6.                  Navrhovaná biznis architektúra riešenia.......................................................................... 26

5.2.              Popis budúceho cieľového produktu projektu z pohľadu aplikačnej architektúry........................ 26

5.2.1.                  Popis budúceho stavu aplikačnej architektúry................................................................. 26

5.2.2.                  Navrhovaná aplikačná architektúra.................................................................................. 27

5.3.              Návrh technologickej architektúry.............................................................................................. 27

1. ROZPOČET A PRÍNOSY.......................................................................................................................... 28

6.1.              Náklady projektu.......................................................................................................................... 28

6.2.              Interpretácia prínosov.................................................................................................................. 28

6.2.1.                  Úspora času procesov........................................................................................................ 29

6.2.2.                  Úspora nákladov na materiál............................................................................................. 32

6.2.3.                  Vyhodnotenie nákladov a prínosov................................................................................... 33

1. HARMONOGRAM JEDNOTLIVÝCH FÁZ PROJEKTU a METÓDA JEHO RIADENIA................................ 33
2. PROJEKTOVÝ TÍM.................................................................................................................................. 34
3. PRACOVNÉ NÁPLNE............................................................................................................................. 35
4. ODKAZY................................................................................................................................................. 35
5. PRÍLOHY................................................................................................................................................ 35

1.   POPIS ZMIEN DOKUMENTU

1.1.        História zmien

2.   ÚČEL DOKUMENTU, SKRATKY (KONVENCIE) A DEFINÍCIE

Účelom dokumentu je v súlade s Vyhláškou 85/2020 Z. z. o riadení projektov, v rámci iniciačnej fázy rozpracovanie detailných informácií prípravy projektu informačný systém REGISTRATÚRA (REG).

2.1.        Použité skratky

2.1.1.     Konvencie pre typy požiadaviek

Požiadavky v rámci projektu boli rozdelené na:

• Funkčné
• Nefunkčné
• Technické

Číslovanie je vzostupné od čísla 1 až po konečné číslo vyjadrujúci požiadavku. Pre číslo je zaradená skratka ID

3.   DEFINOVANIE PROJEKTU

3.1.        Manažérske zhrnutie

3.1.1.     Predstavenie Sociálnej poisťovne

Sociálna poisťovňa bola zriadená 1. novembra 1994 zákonom č. 274/1994 Z. z. o Sociálnej poisťovni ako verejnoprávna inštitúcia poverená výkonom nemocenského poistenia a dôchodkového zabezpečenia, ktoré prevzala od svojej predchodkyne Národnej poisťovne. Od Slovenskej poisťovne prevzala 1. apríla 2002 aj poistenie zodpovednosti zamestnávateľa za škodu pri pracovnom úraze a pri chorobe z povolania – úrazové poistenie. Od 1. januára 2004 vykonáva sociálne poistenie na základe zákona č. 461/2003 Z. z. o sociálnom poistení., t.j. nemocenské poistenie, dôchodkové poistenie - starobné a invalidné, ďalej úrazové poistenie, garančné poistenie a poistenie v nezamestnanosti. Od 1. januára 2005 Sociálna poisťovňa vykonáva aj činnosti v rámci starobného dôchodkového sporenia – predovšetkým vyberá príspevky, postupuje ich dôchodkovým správcovským spoločnostiam a registruje zmluvy o starobnom dôchodkovom sporení.

SP prevádzkuje veľké množstvo informačných systémov, pričom každý z nich vzhľadom na povahu agendy SP má výrazné nároky na databázové požiadavky a štruktúry. Súčasné riešenia, ktoré sú v praxi využívané ponúkajú možnosti realizácie takých databázových riešení, ktoré poskytnú synergické efekty so znížením budúcich nárokov na prevádzkové náklady.

3.1.2.     Kontext projektu vo väzbe na informačnú štruktúru Sociálnej poisťovne

Na platforme Oracle ExaData objednávateľ prevádzkuje nasledovné databázové časti svojho informačného systému:

• Informačný systém Jednotného výberu poistného (ďalej len „JVP"),
• Informačný systém Nemocenského poistenia a lekárskej posudkovej činnosti (ďalej len „IS NP a LPČ“),
• Informačný systém Poistenia v nezamestnanosti a garančného poistenia (ďalej len „IS PvNaGP“),
• Systém elektronických služieb (ďalej len „SES"),
• Centrálny informačný ponukový systém (ďalej len „CIPS"),
• Informačný systém dávkovej agendy úrazového poistenia (ďalej len „IS DAUP"),
• Administratívny informačný systém dôchodkového poistenia (ďalej len „AIS DP"),
• Automatizovaný systém správy registratúry (ďalej len „ASSR").

V súčasnosti sa každé 4 roky vymieňajú zastaralé komponenty za komponenty modernejšie, pričom v zmluvne sa jedná o nasledovné:

Nový produkčný a testovací databázový systém Oracle ExaData nahradí doteraz prevádzkovaný produkčný a testovací databázový systém Oracle ExaData. Súvisiace služby v nadväznosti na dodávku nového produkčného a testovacieho databázového systému Oracle ExaData budú poskytnuté v nasledovnom rozsahu...

Pričom sa vôbec neuvažuje nad riešením, ktoré by komplexne poňalo databázové riešenie SP. Štvorročný kontakt je kalkulovaný na cca 6,7 mil. €, pričom:

• Dodávka technologických zariadení a LVS je 994 445 € bez DPH
• Následná podpora v priemere na rok je 1 431 889 € bez DPH

Z pohľadu horizontu 10 rokov boli náklady spojené s prevádzkou vysokodostuného a on premise riešenia v každom okamihu v hodnote 19 mil. €. V nasledujúcej tabuľke je uvedený rozpad nákladov po rokoch a typoch výdavkov:

Cieľom projektu je preto vybudovať komplexné databázové riešenie, ktorého úlohou bude poskytovať databázové služby podľa aktuálnych potrieb a vyťaženosti systémov a nie v maximálnej možnej miere v každom okamihu.

Z pohľadu možností vzhľadom na charakter databáz v rámci SP boli zvažované nasledovné alternatívy:

Keďže v tomto projekte vznikne efektívne manažovateľné cloudové prostredie pre databázové systémy v privátnom cloude, automaticky sa ponúka priestor na podobnú optimalizáciu a zvýšenie agility v oblasti existujúcich a novo vznikajúcich aplikácií SP. V rámci optimalizácie zdrojov pri prechode na ExaData je možné zároveň vytvoriť prostredie privátneho cloudu postaveného na otvorených štandardoch, ktoré umožní postupný prechod aplikačného portfólia SP do DevOps režimu prevádzky a rozvoja.

Sumárne informácie o projekte rozvoja

V nasledujúcej tabuľke sú uvedené základné premenné parametre projektu:

3.2.        Motivácia a rozsah projektu

Primárna motivácia, ktorá je determinantom realizácie tohto projektu je vybudovanie efektívnej a moderne fungujúcej inštitúcie verejnej správy. Inštitúcia takého charakteru, štruktúry a rozsahu musí mať pre svoje efektívne fungovanie vybudované dostatočné technické nástroje za zabezpečenie riadenia a organizovania.

V nasledujúcej schéme je grafické znázornenie motivačnej schémy:

Schéma 1 – Schéma motivácie realizácie projektu

Z vyššie uvedenej motivačnej architektúry je zreteľné, že primárna motivácia je:

• Vybudovať efektívne a flexibilné riešenie na zabezpečenie databázových potrieb organizácie
• Eliminovať náklady na prevádzku a obnovu riešenia
• Vylepšiť výkon využívaných nástrojov
• Umožniť škálovateľnosť riešenia podľa aktuálnych potrieb bez nutnosti technických zásahov a supportu

3.2.1.     Problém, ktorý bude realizáciou projektu odstránený

Z pohľadu problémov je potrebné sa pozrieť na existujúce zabezpečenie databázových a aplikačných potrieb spoločnosti. V nasledujúcej tabuľke sú identifikované problémy súčasného stavu ako aj popis kontribúcie projektu pre ich odstránenie resp. vyriešenie:

3.2.2.     Biznis procesy, ktoré sú predmetom projektu

Z pohľadu biznis procesov sú dotknuté procesy, ktoré súvisia s výkonom hlavnej agendy, ktorá je prostredníctvom databázového riešenia dotknutá. Jedná sa o procesy nasledovných agend:

• Jednotný výber poistného
• Úrazové poistenie
• Nemocenské poistenia
• Lekárska posudková činnosť
• Dôchodkové poistenie
• Správa registratúry
• Poistenie v nezamestnanosti
• Garančné poistenie
• Elektronické služby klientom

3.2.3.     Informácie o oblasti (OBSAH / AGENDA / ŽIVOTNÁ SITUÁCIA), ktorým sa projekt venuje

Z pohľadu projektu sú informácie o agendách a životných situáciách irelevantné, keďže sa jedná o projekt na zabezpečenie interných procesov organizácie.

3.3.        Zainteresované strany/Stakeholderi

V tejto časti sú popísaný základný stakeholdri projektu a aktéri, ktorí budú prichádzať so systémom do styku pri výkone ich agendy:

3.4.        Ciele projektu a merateľné ukazovatele

Ciele/Merateľné ukazovatele

3.5.        Riziká a závislosti

Riziká a závislostí v rámci projektu zodpovedajú typickým rizikám pre IT projekty, na druhej strane predmet projektu (registratúra) je na slovenskom trhu bežne obstarávanou službou/dielom.

Hlavné riziká preto vyplývajú zo špecifík prostredia obstarávateľa, najmä pokiaľ ide o integráciu na externé a interné IS.

Realizácia projektu bude riadená Riadiacim výborom projektu, ktorý bude zabezpečovať koordináciu projektu. Harmonogram projektu bol stanovený tak, aby umožnil riešiť prípadné problémy pri nasadení riešenia. Rovnako v rámci existujúcich štruktúr obstarávateľa existuje útvar riadenia projektov (Projektová kancelária), prostredníctvom ktorej bude projekt implementovaný dodržaním zásad projektového riadenia (PRINCE, IPMA a pod.)

Riziká projektu je možné pomenovať nasledovne.

3.6.        Alternatívy a Multikriteriálna analýza

3.6.1.     Stanovenie alternatív pomocou biznisovej vrstvy architektúry

Popis jednotlivých alternatív z biznis pohľadu

K riešeniu vyššie uvedených problémov je možné pristúpiť 3 alternatívami, pričom každá z nich v určitom rozsahu daný problém rieši.

3.6.2.     Multikriteriálna analýza

Výber alternatív prebieha na úrovni biznis vrstvy prostredníctvom MCA zostavenej na základe kapitoly Motivácia, ktorá obsahuje ciele stakeholderov, ich požiadavky a obmedzenia pre dosiahnutie uvedených cieľov. Ciele musia byť definovaný formou KPI, pričom sa dodržiava uplatnenie princípov tvorby S.M.A.R.T cieľov. Kritéria v MCA sú v dokumente zdôvodnené v kapitole Motivácia a vychádzajú zo stanovených cieľov. Kritériá, ktoré nie sú v dokumente vysvetlené, nebudú akceptované.

V nasledujúcej tabuľke sú definované jednotlivé kritéria z pohľadu vlastníkov kritérií:

Na základe definovaných kritérií boli posúdené jednotlivé varianty z toho pohľadu, či dané kritérium spĺňajú a ako ho dosiahnu. V nasledujúcej tabuľke je sumarizácia tohto posúdenia:

Z pohľadu MCA alternatívy je najvýhodnejším riešením Alternatíva 2, ktorá úplne spĺňa všetky požiadavky stakeholderov.

3.6.3.     Stanovenie alternatív pomocou aplikačnej vrstvy architektúry

Z pohľadu aplikačnej architektúry musí byť zabezpečené, aby existujúce aplikačné komponenty, ktoré využívajú súčasné databázové nástroje boli zachované a teda aby nedošlo k obmedzovaniu funkčnosti potrebnej pre zabezpečenie procesov SP, ktoré sa vykonávajú na agendových alebo iných aplikačných prvkoch (systémoch).

4.   POŽADOVANÉ VÝSTUPY  (PRODUKT PROJEKTU)

Projekt bude realizované v rámci 1 inkrementu.

Realizácia projektu bude prechádzať štandardnými etapami riadenia IT projektov a to:

• Analýza a dizajn
• Implementácia
• Testovanie
• Nasadenie

Pre tieto etapy sú definované jasné výstupy, ktoré majú byť dodané a budú predmetom akceptačných kritérií.

Výsledným produktom bude:

• Dodané databázové riešenie pre dotknuté agendové a back office systémy, ktoré bude spĺňať definované požiadavky na dostupnosť, efektívnosť a pod.
• Vytvorené integračné rozhrania pre agendové a back officové systémy, ktoré budú zdrojmi údajov.

V nasledujúcoim texte je popísaný štandardizovaný postup implementácie databázových nástrojov, pričom sa jedná o nasledovné:

Nový produkčný a testovací databázový systém nahradí doteraz prevádzkovaný produkčný a testovací databázový systém. Súvisiace služby v nadväznosti na dodávku nového produkčného a testovacieho databázového systému budú poskytnuté v nasledovnom rozsahu:

Inštalácia a konfigurácia:

Predstavuje zapojenie nových zariadení do elektrickej a komunikačnej siete LAN, otestovanie a diagnostiku hardvérových komponentov, realizáciu prepojenia pomocou komunikačných kanálov a realizáciu prepojenia a integrácie so zálohovacím systémom EMC Data Domain.

Migrácia:

Predstavuje prehodnotenie konfigurácie pamäte a počtu CPU pre každú databázu, vytvorenie nových databázových serverov vrátane inštalácie operačného systému a databázového servera, migráciu databázy a užívateľských dát z existujúcich produkčných a testovacích serverov, testovanie, reorganizáciu pamäte a počtu CPU na nových systémoch pre produkčné a testovacie prostredia, nakonfigurovanie záložných prostredí pre prípad celkového zlyhania produkčných databázových systémov, testovanie.

4.1.1.     Stanovenie alternatív pomocou technologickej vrstvy architektúry

V prípade technologickej architektúry sa bude jednať o nasadenie a prevádzku systému v existujúcom prostrední SP, pričom súčasťou dodávky a naplnenia služby bude nasledovné:

• 2x ExaC@C X9M-2 Quarter Rack s nasledujúcimi s parametrami
• Max #OCPUs is 124
• Max RAM is 2,780 GB
• Persistent memory 4.5TB
• Flash total 76 TB
• Usable Storage 192 TB
• (Triple Mirroring)

Využitie dodávaných HW komponentov je definované na nasledujúcej schéme:

5.   NÁHĽAD ARCHITEKTÚRY

Základný koncept architektúry pozostáva z biznis a aplikačnej architektúry, ktoré sú naznačené v nasledujúcich kapitolách vrátane popisu používateľov riešení ako aj aplikačných a koncových služieb.

5.1.        Popis budúceho cieľového produktu projektu z pohľadu biznis architektúry

5.1.1.     Používatelia riešenia

Používateľov systému môžeme rozdeliť nasledovne:

5.1.2.     Základné biznis požiadavky

Základnými biznis požiadavkami v prípade projektu tohto typu sú:

• Zabezpečenie stabilného výkonu podľa požiadaviek procesov
• Zabezpečenie dlhodobého supportu vytvoreného riešenia
• Zaručenie konzistentnej migrácia dát v prípade obnovy resp. výmeny databázových prostredí
• Kvalitné a kontinuálne zabezpečenie základných prevádzkových parametrov ako sú:
  • telefonický prístup k technickému supportu v režime 24x7x365,
  • poskytovanie upgrade produktu,
  • poskytovanie záplat produktu,
  • nárok na nové verzie zakúpených produktov,
  • Product Support - 24x7 prístup k technickej podpore cez webový portál My Oracle Support (support.oracle.com) prostredníctvom prideleného CSI čísla,
  • technické informácie a riešenia,
  • evidencia “Bug-ov”,
  • prístup k technickým inžinierom certifikovaných spoločnosťou Oracle,
  • články s relevantnými technickými informáciami,
  • diagnostické testy,
  • interaktívne fórum,
  • možnosť eskalovať Service Requests (ďalej len „SR“),
  • prístup k proaktívnym nástrojom: Configuration Support Manager: nástroj, ktorý napomáha predísť vzniku kritických situácii a urýchľuje riešenie SR s tým, že proaktívne a automaticky zbiera a hodnotí informácie o objednávateľovej konfigurácii,
  • aktualizácie programov, záplaty, opravy, bezpečnostné a kritické záplaty a bezpečnostné upozornenia pre softvér operačných systémov a integrovaný softvér,
  • hardvérová podpora na mieste pre server alebo storage

5.1.3.     Vplyv na existujúci proces  a okolité prostredie

Projekt má pozitívny vplyv na existujúce procesy a okolité prostredie, pričom z pohľadu procesov ako aj benefitov prináša nasledujúce:

• Prostredie umožňujúce flexibilné poskytovanie databázových služieb (jednotka výkonu/ jednotka nákladov) – škálovateľnosť zdrojov smerom hore a dole, pričom sa platí primárne za používané CPU jadrá v DB serveroch,
• Jasný prehľad s predikciou nákladov za DB služby. Užívateľ má presný prehľad o tom koľko ho služba stojí, koľko z nej už čerpal ako aj o predikcii ako sa budú vyvíjať náklady. Služba sa zazmluvňuje minimálne na 4 roky (obdobný model ako dnes) a nezohľadňuje prípadné inflačné výkyvy.
• Úspora nákladov vďaka možnosti migrácie na službový model, ktorý zahŕňa DB servis vrátane podpory všetkých HW a SW komponentov. V konečnom dôsledku môže zákazník zrušiť on premise riešenie a jeho licenčnú podporu.
• Riešenie poskytuje nové funkcionality - službový model univerzálnych kreditov obshuje v jednotke OCPU (zapnuté fyzické jadro v DB serveru) všetky databázové rozšírenia ako napr. In-Memory, RAC, Multitenant, Advanced Security, DB Vault, Label Security, Advanced Analytics, Spatial and Graph, Management Pack for Oracle DB, RAT, Partitioning, Advanced Compression, Diagnostic a Tuning Pack, Data Masking, Data
• Subsetting Pack, Database Lifecycle Management Pack. Všetky tieto rozšírenia sú v cene služby a flexibilne platené podľa času využitia.
• Väčšia bezpečnosť – služba vyžaduje minimálne šifrovanie dát a tím ich chráni pred neoprávneným čítaním, pričom obsahuje aj ďalšie bezpečnostné komponenty ako DB Vault a Advanced Security (tieto sú v cene s možnosťou implementácie a používania)
• Zvýšenie dostupnosti / ochrany existujúceho prostredia vďaka Oracle odporučenej MAA architektúre zahrňujúcej DR služby. Súčasní on-premise implementácie neobsahuje DR. Navrhované riešenie má dostatočnú rezortu a prokročilú automatizáciu pre jednoduchú implementáciu DR pomocou v cene obsiahnutého Active Dataguardu.
• Konsolidácia serverov a strorage systému a sieťovej infraštruktúry do jedného integrovateľného a plne vyladeného prostredia v režime prevádzky cloud služby
• Niektoré dátovo náročné databázové operácie sú z databázových serverov presunuté priamo na storage systémy. Týmto sa dosahujú o mnoho vyššie výkony ako pri tradičnom prístupe on-premise IT infraštruktúr. Zároveň sa tým pádnom môže lepšie optimalizovať nutný počet CPU jadier v DB serveroch.
• Výrazne zjednodušená správa (jednotný nástroj na správu databáz, serverov, storage serveru, oparačného systému ako celkku)
• Je zabezpečený rovnaký cloud interface ako v Oracle public cloude, pričom je možné použiť aj hybridné modly prevádzky, kde časť záťaže je v public cloude a časť priamo v DC zákazníka.
• Vysoká dostupnosť a spoľahlivosť celého riešenia už v rámci single rack – všetky komponenty sú zdvojené a teda je umožnená výmena za chodu a podpora je plne v cene služby.
• Plné pokrytie kapacitných a výkonnostných požiadaviek na databázovú platformu podľa merania súčasných nárokov prostredí a viac ako 50% rezerva na HW pre budúci rast.
• Platforma sa poskytuje ako cloud služba – t.j. možnosť rýchleho prideľovania výkonu jednotlivých projektom a vytvárania nových prostredí
• Zákazník sa nestará o HW, servisní požiadavky, chyby na HW, nasadzovanie pravidelných záplat, implementáciu zmien – všetky tieto služby sú zahrnuté v cene služby Oracle DB platformy

5.1.4.     Súlad s legislatívou

Informačný systém musí byť vybudovaný v súlade s platnou legislatívnou v oblasti budovania IS VS, ako aj s ostatnou legislatívou Slovenskej republiky a to najmä:

• Zákon č. 461/2003 Z. z. Zákon o sociálnom poistení
• Zákon č. 43/2004 Z. z. Zákon o starobnom dôchodkovom sporení a o zmene a doplnení niektorých zákonov
• Zákon č. 69/2018 o kybernetickej bezpečnosti a o zmene a doplnení niektorých zákonov
• Zákon č. 95/2019 o informačných technológiách vo verejnej správe a o zmene a doplnení niektorých zákonov
• Zákon č. 305/2013 Z. z. o elektronickej podobe výkonu pôsobnosti orgánov verejnej moci a o zmene a doplnení niektorých zákonov
• Zákon č. 177/2018 Z. z. o niektorých opatreniach na znižovanie administratívnej záťaže využívaním informačných systémov verejnej správy a o zmene a doplnení niektorých zákonov (zákon proti byrokracii) v aktuálne platnom znení
• Zákon č. 272/2016 o dôveryhodných službách pre elektronické transakcie na vnútornom trhu a o zmene a doplnení niektorých zákonov
• Zákon č. 215/2004 Z. z. o ochrane utajovaných skutočností a o zmene a doplnení niektorých zákonov
• Zákon č. 9/2010 Z. z. o sťažnostiach v znení neskorších predpisov
• Zákon č. 357/2004 Z. z. o ochrane verejného záujmu pri výkone funkcií verejných funkcionárov v znení neskorších predpisov
• Zákon č. 211/2000 Z. z. o slobodnom prístupe k informáciám v znení neskorších predpisov
• Zákon č. 395/2002 Z. z. o archívoch a registratúrach a o doplnení niektorých zákonov v znení neskorších predpisov.
• 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 aktuálne platnom znení
• Zákon č. 71/1967 Z. z. o správnom konaní
• Zákon č. 270/1995 Z. z. o štátnom jazyku SR
• Zákon č. 9/2010 Z. z. o sťažnostiach
• Zákon č. 431/2002 Z. z. o účtovníctve
• Zákon č. 270/1995 Z.z. o štátnom jazyku SR
• Nariadenie rady EÚ č. 2016/269 (GDPR)
• Zákon č. 18/2018 Z. z. o ochrane osobných údajov a o zmene a doplnení niektorých zákonov (ošetriť registratúru tak, aby sa nemuseli vyhľadávať v dokumentoch osobné údaje a pri skenovaní ich prekrývať)
• Vyhláška č. 410/2015 Z.z. Ministerstva vnútra Slovenskej republiky z 9. decembra 2015 o podrobnostiach výkonu správy registratúry orgánov verejnej moci a o tvorbe spisu
• Výnos 525/2011 Z.z. Ministerstva vnútra Slovenskej republiky z 12. decembra 2011 o štandardoch pre elektronické informačné systémy na správu registratúry
• Vyhláška č. 78/2020 Z.z. Úradu podpredsedu vlády SR pre investície a informatizáciu o štandardoch pre informačné technológie verejnej správy
• Vyhláška č. 85/2020 Z.z. Úradu podpredsedu vlády SR pre investície a informatizáciu o riadení projektov
• Vyhláška č. 85/2018 Z. z. o podrobnostiach o spôsobe vyhotovenia a náležitostiach listinného rovnopisu elektronického úradného dokumentu.
• Vyhláška MV SR č. 628/2002 Z. z., ktorou sa vykonávajú niektoré ustanovenia zákona o archívoch a registratúrach a o doplnení niektorých zákonov v aktuálne platnom znení
• Vyhláška MIRRI SR č. 70/2021 o zaručenej konverzii
• Vyhláška UPVII č. 179/2020 Z. z., ktorou sa ustanovuje spôsob kategorizácie a obsah bezpečnostných opatrení informačných technológií verejnej správy
• Vyhláška NBU č. 165/2018 Z. z., ktorou sa určujú identifikačné kritériá pre jednotlivé kategórie závažných kybernetických bezpečnostných incidentov a podrobnosti hlásenia kybernetických bezpečnostných incidentov v aktuálne platnom znení
• Vyhláška NBU č. 362/2018 Z. z., ktorou sa ustanovuje obsah bezpečnostných opatrení, obsah a štruktúra bezpečnostnej dokumentácie a rozsah všeobecných bezpečnostných opatrení v aktuálne platnom znení
• Nariadením európskeho parlamentu a rady (EÚ) č. 2016/679 z 27.04.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 (ďalej len „GDPR“)
• Výnos MV SR č. 525/2011 Z. z. o štandardoch pre elektronické informačné systémy na správu registratúry v aktuálne platnom znení
• Metodika pre systematické zabezpečenie organizácií verejnej správy v oblasti informačnej bezpečnosti

(https://www.csirt.gov.sk/wp-content/uploads/2021/08/MetodikaZabezpeceniaIKT_v2.1.pdf?csrt=4692042392050375121)

• Ostatné všeobecne záväzné právne predpisy ktoré sa dotýkajú predmetu obstarávania ako aj interné predpisy SP

5.1.5.     Navrhovaná biznis architektúra riešenia

Na nasledujúcej schéme je definovaná biznis architektúra navrhovaného riešenia, pričom sa jedná o štandardizovaný formát architektúry, ktorá je následne prispôsobená entitám a špecifikám daného klienta:

5.2.        Popis budúceho cieľového produktu projektu z pohľadu aplikačnej architektúry

5.2.1.     Navrhovaná aplikačná architektúra

Na nasledujúcej schéme je návrh aplikačnej architektúry riešenia, ktorá vychádza zo všeobecného schematického znázornenia, pričom je jasne vidieť, že riešenie „sedí“ u klienta, pričom služby sú poskytované ako cloudové služby so všetkými svojimi výhodami.

5.2.2.            Kalkulácia návrhu riešenia na základe existujúcej spotreby výkonu

Dimenzovanie kapacity databázy bolo navrhnuté na základe reálnych údajov o potrebnom výkone získaných zo skriptu spusteného priamo nad databázami. V nasledujúcom texte je definovaný postup a predpoklady per realizovanom výpočte budúceho stavu:

• Všetky analýzy sú založené na predchádzajúcej spotrebe zdrojov a nemusia nevyhnutne predpovedať budúcnosť
• Definované kohorty a databázy sa môžu líšiť od aktuálneho nasadenia
• Výpočty veľkosti sú založené na hodinovej priemernej spotrebe zdrojov databáz v každej jednotke
• Kohortové metriky sú zarovnané podľa času a potom sa vypočíta súčet vrcholov pre každú hodinu
• Hodinové údaje sú upravené na základe vrcholov zistených v denných údajoch za posledný rok
• Pri dimenzovaní pre Exadata C@C v závislosti od toho, ako má zákazník nakonfigurovaný pohotovostný režim, OCPU potrebné pre DR sa budú líšiť:
  • Ak je pohotovostný režim zaregistrovaný v EM, údaje sa zozbierajú a použijú na dimenzovanie
  • Ak pohotovostný režim nie je zaregistrovaný v EM, syčanie pre DR sa vykoná s ohľadom na 20 % OCPU potrebných na výrobu
• Pre databázy s jednou inštanciou sa počet OCPU požadovaných na Exadata C@C bude líšiť v závislosti od konečnej architektúry, ktorú potrebuje zákazník (každý klaster VM musí mať rovnaký počet OCPU na uzly VM)

Na nasledujúcej schéme je znázornená súčasná štruktúra prostredí:

Analýza špičiek a sezónnosti

V nasledujúcom texte sú popísané výstupy realizovaných analýz peakov a sezónnosti.

PROD prostredie

• V rámci procesu dimenzovania sa príslušné metriky DB upravia podľa predchádzajúcich vrcholov
• Posledných ~33 dní obsahuje podrobnejšie informácie na hodinovej úrovni
• Posledných 12 mesiacov ukazuje sezónne trendy na dennej úrovni
• Hodinové údaje sa upravia, ak sa zistí predchádzajúci vrchol vyšší ako vrchol za posledný mesiac
• Najrušnejšie mesiace pre prostredie PROD boli napríklad august a november 2022

Na nasledujúcej schéme je analýzy využitia uCPU v rámci PROD prostredia:

TEST prostredie

• V rámci procesu dimenzovania sa príslušné metriky DB upravia podľa predchádzajúcich vrcholov
• Posledných ~33 dní obsahuje podrobnejšie informácie na hodinovej úrovni
• Posledných 12 mesiacov ukazuje sezónne trendy na dennej úrovni
• Hodinové údaje sa upravia, ak sa zistí predchádzajúci vrchol vyšší ako vrchol za posledný mesiac
• Najrušnejšie mesiace pre prostredie TEST boli napríklad apríl, máj a november 2022

Na nasledujúcej schéme je znázornená analýza vCPU testovacím prostredím:

PROD STB prostredie

• V rámci procesu dimenzovania sa príslušné metriky DB upravia podľa predchádzajúcich vrcholov
• Posledných ~33 dní obsahuje podrobnejšie informácie na hodinovej úrovni
• Posledných 12 mesiacov ukazuje sezónne trendy na dennej úrovni
• Hodinové údaje sa upravia, ak sa zistí predchádzajúci vrchol vyšší ako vrchol za posledný mesiac
• August 2022 bol pre prostredie PROD STB najrušnejším mesiacom

Na nasledujúcej schéme je znázornená analýza spotreby vCPU pre prostredie PROD STB:

Návrh budúceho riešenia

Na nasledujúcich schémach je uvedený návrh budúceho riešenia, ktoré vychádza práve z realizovaných analýz spotreby:

Toto riešenie sa prejaví vo fyzickom usporiadaní nasledovne:

5.3.        Návrh technologickej architektúry

SP očakáva nasadenie EXADATA a privátneho cloudu v rámci svojej existujúcej infraštruktúry. Zároveň však bude predmetom ponukového konania požiadavka na dodávateľa, aby navrhol minimálne technologické požiadavky pre navrhované riešenie.

Z hľadiska škálovateľnosti dodané riešenie a jeho licenčný model bude umožňovať škálovateľnosť výkonu v súlade s rastúcimi požiadavkami na systémové zdroje. Škálovateľnosť bude horizontálna na aplikačnej úrovni (pridávanie inštancií) a na hardvérovej úrovni (musí umožňovať pridávať hw prostriedky).

6.   ROZPOČET A PRÍNOSY

V tejto časti sú popísané náklady a prínosy navrhovaného riešenia. Z titulu povahy riešenia neboli kalkulované prínosy, ktoré sú typické pre systémy ovplyvňujúce procesy a postupy v rámci organizácie.  

6.1.        Náklady projektu

Náklady riešenia boli kalkulované priamo analytickým tímom spoločnosti Oracle, pričom tieto reflektujú analýzy spotreby spoločnosťou SP. Okrem prevádzkových nákladov sú kalkulované náklady na poskytovania služby kreditov (spotreba výkonu).

Tieto náklady sú uvedené v nasledujúcej tabuľke:

Celkové náklady v horizonte 10. rokov sú teda v hodnote 16,1 mil. € bez DPH

6.2.        Interpretácia prínosov

Prínosy navrhovaného riešenia je možné identifikovať v 2 základných oblastiach:

• Šetrenie nákladov, ktoré sa dá jednoznačne preukázať modelom financovania
• Zlepšenia, ktoré vo všeobecnosti prináša navrhovaný model zabezpečenia databázových prostredí

6.2.1.     Úspora nákladov riešenia

V rámci porovnania riešení súčasného stavu a navrhovaného stavu z pohľadu nákladov je navrhované riešenie lacnejšie o 1 054 tis. € v horizonte 10 rokov, pričom ak by boli požadované všetky funkcionality navrhovaného riešenia aj v rámci súčasného stavu, bola by nákladová náročnosť ešte výrazne vyššia.

V nasledujúcej tabuľke sú porovnané náklady súčasného a navrhovaného riešenia počas 10 rokov, pričom náklady súčasného riešenia vychádzajú z existujúcej zmluvy 77090-13/2019-BA:

6.2.2.     Zlepšenia, ktoré prináša navrhovaný model

Z pohľadu identifikácie zlepšení boli brané do úvahy viaceré skúsenosti s obdobnými riešeniami, ktoré boli vyhodnotené v rôznych materiáloch a štúdiách. Ako príklad v nasledujúcej časti uvedené prínosy, ktoré boli identifikované v rámci materiálu IDC. Prínosy boli rozdelené do viacerých kategórií, pričom v nasledujúcej tabuľke sú tieto sumarizované:

Vyššie uvedené benefity sú síce benefitmi komerčnej sféry ale je potrebné povedať, že SP je organizácia založená na realizáciu biznis procesov, ktorých výsledkom je spokojný zákazník, a teda sa dá povedať, že hodnotové nastavenie organizácie má prvky a procesy komerčnej spoločnosti, ktorej základným motorom je znižovanie prevádzkových nákladov a zvyšovanie produktivity práce, k čomu navrhované riešenie jednoznačne prispieva.

Ďalšie benefity sú popísané v časti 5.1.3 Vplyv na existujúci proces a okolité prostredie

6.2.3.     Vyhodnotenie nákladov a prínosov

V nasledujúcej tabuľke sú vyhodnotené náklady a prínosy navrhovaného riešenia:

7.   HARMONOGRAM JEDNOTLIVÝCH FÁZ PROJEKTU a METÓDA JEHO RIADENIA

Gantov diagram realizácie projektu

Z pohľadu povahy projekty irelevantné

Indikatívny harmonogram VO

Fakturačné míľniky

T – dátum uzatvorenia zmluvy s dodávateľom

8.   PROJEKTOVÝ TÍM

Interný projektový tím pre fázu vypracovania dokumentov v zmysle požiadaviek MIRRI je zložený z nasledujúcich pracovných pozícií:

• Procesný analytik
• IT špecialita

Zároveň sa zostavuje sa Riadiaci výbor (RV), v minimálnom zložení:

• Predseda RV
• Zástupca vlastníkov procesov objednávateľa
• Zástupca kľúčových používateľov objednávateľa
• Zástupca dodávateľa (dopĺňa sa až po VO / voliteľný člen)

Pre potreby realizácie projektu bude zriadený projektový tím objednávateľa v nasledovnom rozsahu:

• Kľúčový používateľ
• IT Analytik
• Vlastník procesov
• Projektový manažér
• IT architekt
• Manažér kvality

V nasledujúcej tabuľke sú definované pozície a ich obsadenie:

9.   PRACOVNÉ NÁPLNE

Budú doplnené v iniciačnej fáze - doplniť podľa dokumentu z Riadiaceho Výboru projektu, prípadne zo splnomocnení alebo menovacích dekrétov - do už vytvoreného dokumentu PROJEKTOVÝ ZÁMER z Prípravnej fázy a aktualizovať a detailne rozpracovať. Tieto vstupy neskôr využijete pri dokumente PID.

10.ODKAZY

Nerelevantné

11.PRÍLOHY

V rámci prípravy projektu sú súčasťou nasledovné dokumenty:

• Príloha 1: CBA projektu
• Prílohe 3: Časť 3.5 dokumentu Riziká a závislosti
• Príloha 4: Časť 3.4 dokumentu Ciele projektu a merateľné ukazovatele

[1] rozvoj sa počíta ako 10% z celkových nákladov / rok

[2] rozvoj sa počíta ako 10% z celkových nákladov / rok