I-02 Projektový zámer (projektovy_zamer)

Version 7.1 by Jozef Ferleťák on 2024/11/26 17:47

SABLONA_I-02_PROJEKTOVY_ZAMER_Projekt_XYZ_YYMMDD_v0.1_5d283de4ad3c0b7a.png
PROJEKTOVÝ ZÁMER
Vzor pre manažérsky výstup I-02
podľa vyhlášky MIRRI č. 401/2023 Z. z.

Povinná osobaSlovenská agentúra pre rozvoj investícií a obchodu
Názov projektuRozvoj procesov Interaktívneho systému dodávateľských reťazcov 
Zodpovedná osoba za projektPetra Sasinková (Projektový manažér)
Realizátor projektuSlovenská agentúra pre rozvoj investícií a obchodu
Vlastník projektu Slovenská agentúra pre rozvoj investícií a obchodu
Schvaľovanie dokumentu
PoložkaMeno a priezviskoOrganizáciaPracovná pozíciaDátum

Podpis
(alebo elektronický súhlas)

Vypracoval     

1.História DOKUMENTU

VerziaDátumZmenyMeno
0.126.11.2024Dokumentácia na schvaľovanieSARIO
    
    

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

V súlade s Vyhláškou č. 401/2023 Z.z. je dokument I-02 Projektový zámer určený na rozpracovanie detailných informácií prípravy projektu, aby bolo možné rozhodnúť o pokračovaní prípravy projektu, pláne realizácie, alokovaní rozpočtu a ľudských zdrojov.

Účelom predkladaného dokumentu je súhrnný rámcový popis informácií o zmysle a dôvodoch realizácie projektu, odhadovaných prínosoch a nákladoch projektu, odôvodnení alokácie nevyhnutných zdrojov projektu, časovom rámci realizácie a odhadovaných rizikách projektu.

Dokument je vypracovaný v rámci prípravno-iniciačnej fázy projektu v súlade s Vyhláškou Ministerstva investícií, regionálneho rozvoja a informatizácie Slovenskej republiky č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy.

2.1 Použité skratky a pojmy

SKRATKA/POJEMPOPIS
B2BBiznis to biznis
CBACost benefit analysis
FOFyzická osoba
IS CSRÚInformačný systém Centrálnej správy referenčných údajov
IS CDPIInformačný systém Centrálna platforma dátovej integrácie
ISDRInteraktívny systém dodávateľských reťazcov
MHSRMinisterstvo hospodárstva Slovenskej republiky
MCAMultikriteriálna analýza
MSPMalé a stredné podniky
NKIVSNárodná koncepcia informatizácie verejnej správy
POPrávnická osoba
SARIOSlovenská agentúra pre rozvoj investícií a obchodu
 TCOTotal cost of ownership
ÚPVSÚstredný portál verejnej správy
  

 

2.2 Konvencie pre typy požiadaviek

Hlavné kategórie požiadaviek v zmysle katalógu požiadaviek sú rozdelené na funkčné, nefunkčné a technické. Podskupiny v hlavných kategóriách je možné rozšíriť v závislosti od potrieb projektu, napríklad:

Funkčné požiadavky používajú konvenciu:

RF_xxx

  • RF – funkčná požiadavka
  • xxx – číslo požiadavky

Nefunkčné a technické požiadavky používajú konvenciu:

RNF_xxx

  • RNF – nefunkčná požiadavka
  • xxx – číslo požiadavky

Ostatné typy požiadaviek môžu byť ďalej definované objednávateľom/PM.

3.DEFINOVANIE PROJEKTU

3.1Manažérske zhrnutie

Tento projekt je vypracovaný v súlade s vyhláškou č. 401/2023 Z. z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy.

Slovenská agentúra pre rozvoj investícií a obchodu je príspevková organizácia v pôsobnosti Ministerstva hospodárstva SR. Medzi strategické ciele SARIO patrí:

  1. Rast investícií s exportným potenciálom a dôrazom na: vyššiu pridanú hodnotu, priame investície do výskumu a vývoja a transfer technológií;
  2. diverzifikáciu sektorov – prezentácia Slovenska ako destinácie pre elektrotechnický priemysel, IT, priemysel vrátane elektromobility;
  3. rast zamestnanosti v najmenej rozvinutých regiónoch Slovenska – znižovanie rozdielov medzi jednotlivými regiónmi, podpora malých a stredných podnikov;
  4. šírenie a napĺňanie posolstiev značky Slovensko.

Systematická podpora etablovaných investorov pri ich rozširovaní a inovácií v smerovaní na možnosti zvýšenia finalizácie produkcie v Slovenskej republike s dôrazom na:

  1. komplexné služby podporujúce ich ekonomický rast;
  2. podporu expanzií a technologického výkonu;
  3. zapájanie lokálnych subjektov do dodávateľských reťazcov do zahraničných investorov – internacionalizácia MSP v zahraničí, podpora teritoriálneho rastu MSP;
  4. zvyšovanie záujmu o joint venture projekty slovenských subjektov.

Posilňovanie prepojenia slovenských subjektov v rámci jednotnej zahraničnej politiky prostredníctvom:

  1. podpory nárastu exportu produktov a služieb v strategicky dôležitých odvetviach, najmä do rýchlorastúcich trhov;
  2. podpory exportu technológií, inovácií a investícií;
  3. podpory účasti na významných veľtrhoch a výstavách;
  4. šírenia a napĺňania posolstiev značky Slovensko. 

Pre tieto strategické ciele je využívaný mimo iných aj Interaktívny systém dodávateľských reťazcov, ktorý slúži na mapovanie a rozvoj dodávateľských reťazcov a zabezpečuje agendovú podporu pre zamestnancov SARIO. Sieť MSP pôsobiacich v relevantných odvetviach slovenského hospodárstva nie je doposiaľ dokonale zmapovaná a podchytená v elektronickom nástroji, ktorý by umožňoval efektívnu prácu s týmito subjektami – vyhľadávanie, oslovovanie, evidencia zrealizovaných aktivít a služieb poskytnutých jednotlivým spoločnostiam. SARIO v rámci projektu plánuje rozvíjať vznikajúci elektronický nástroj (ISDR) a obohacovať ho o inovatívne prvky v súlade s vývojom v oblasti informačných technológií. Individuálny prístup na strane dopytu aj ponuky a adresné poskytovanie služieb je v tomto prípade nevyhnutnosťou.

Kvantitatívne prínosy v rámci navrhovaného projektu sú:

  • Šetrenie času zamestnanca na manažment a realizáciu B2B podujatí a stretnutí
  • Šetrenie finančných nákladov na vytvorenie B2B podujatia externou spoločnosťou
  • Šetrenie času podnikateľa na registráciu a manažment B2B stretnutí s ďalšími podnikateľmi
  • Šetrenie finančných nákladov na získanie a publikovanie údajov na Findin.sk
  • Šetrenie času zamestnanca na prípravu dotazníkov po podujatiach a na konci roka

Kvalitatívne prínosy v rámci navrhovaného projektu sú:

  • Poskytovanie zvýšenej kvality údajov na findin.sk a zlepšenie prepojenia medzi investormi a podnikateľmi na Slovensku

Časový harmonogram projektu je nastavený na najviac 15 mesiacov a finálnym termínom dokončenia do 30.06.2026. Projekt je naplánovaný od 04/2025 a má byť ukončený do 06/2026. Následne v rámci uzavretej servisnej zmluvy bude prebiehať bežný servis systému podľa požiadaviek gestora a podľa legislatívnych zmien a nových právnych predpisov.

IDFÁZA/AKTIVITA

ZAČIATOK

(odhad termínu)

KONIEC

(odhad termínu)

2aAnalýza a Dizajn04/202508/2025
2bNákup technických prostriedkov, programových prostriedkov a služieb  
2cImplementácia a testovanie09/202504/2026
2dNasadenie a PIP05/202606/2026

Rozpočet projektu je stanovený na sumu 919 370 EUR a pozostáva z nasledovných činností:

  • Analýza a dizajn: 314 056 EUR
  • Implementácia a testovanie: 465 960 EUR
  • Nasadenie: 139 355 EUR

3.2Motivácia a rozsah projektu

Slovenská agentúra pre rozvoj investícií a obchodu (SARIO) je príspevková organizácia v pôsobnosti Ministerstva hospodárstva SR. Misiou Slovenskej agentúry pre rozvoj investícií a obchodu je akcelerovať investičný a exportný potenciál Slovenska so zámerom vytvoriť z krajiny technologické centrum atraktívne pre zahraničných investorov, expertov a potenciálnych obchodných partnerov. Rozvíjať exportný potenciál v globálne konkurencieschopných odvetviach a teritóriách, podporovať expanzie etablovaných firiem, zahraničné investície, zvyšovať zamestnanosť v sektoroch s vysokou pridanou hodnotou a všetkých regiónoch v súlade so stratégiou a hospodárskou politikou Vlády Slovenskej republiky.

Víziou SARIO je predstaviť Slovensko ako atraktívne biznisové centrum pre zahraničných investorov s cieľom vytvárania pracovných miest prednostne v sektoroch s vysokou pridanou hodnotou a prezentovať slovenské firmy ako spoľahlivých a konkurencieschopných obchodných partnerov. 

Slovenská agentúra pre rozvoj investícií prispieva k naplneniu misie iniciovaním transferu technológií, spájaním vedeckej a komerčnej sféry, poskytovaním efektívnych proklientských služieb, nástrojov a platforiem pre podniky orientované na internacionalizáciu, rozvíjaním exportných príležitostí produktov a služieb.

Projekt svojím charakterom reflektuje hlavne na potreby (problémy a príležitosti), ktoré je potrebné realizovať pre zlepšenie aktuálnej situácie zmapovania dodávateľských reťazcov v systéme ISDR. SARIO v rámci aktivity plánuje rozvíjať uvedený elektronický nástroj (ISDR) a obohacovať ho o inovatívne prvky v súlade s vývojom v oblasti informačných technológií. Individuálny prístup na strane dopytu aj ponuky a adresné poskytovanie služieb.

Primárnym cieľom bude zvýšenie kvality a rozsahu poskytovaných služieb pre podnikateľov, ktoré budú poskytované cez privátnu zónu podnikateľa. V rámci týchto služieb bude zabezpečené, aby podnikateľ mal možnosť registrovať sa a následne sa prihlásiť za využitia autentifikačného modulu (jednoznačná overená identita štatutárneho zástupcu). V rámci tejto zóny bude mať možnosť pravidelne aktualizovať informácie o spoločnosti, publikovať dôležité informácie pre ďalších podnikateľov, využívať katalóg profilov za účelom cieleného získania dodávateľa/odberateľa bez nutnosti kontaktovania zamestnancov SARIO. Zároveň tieto informácie budú slúžiť a budú dôležité pre zamestnancov SARIO v procese ďalšieho výberu vhodných partnerov pre spracovanie zahraničného sourcingu. Údaje, ktoré SARIO využíva v procesoch zabezpečenia vhodného partnera sú historické údaje získané počas realizácie aktivít napr. osobné stretnutia, výjazdy, podujatia, ďalej to budú údaje získané prostredníctvom integrácií na základné registre štátu, ako aj údaje poskytnuté priamo podnikateľom cez webový portál. V súlade s vyššie uvedeným sú poskytované osobné údaje a súhlasy, ktoré je nutné evidovať a podporiť čiastočnou automatizáciou a tak odbúrať zbytočnú administratívnu záťaž na strane SARIO. Procesy realizácie agendy manažovania B2B rokovaní prostredníctvom na to určených podujatí, budú podporené zavedeným nástrojom, ktorý umožní: registráciu a schvaľovanie na podujatie, definovanie podmienok registrácie a zaplatenia registračného poplatku, uplatnenie zľavových kódov, vyplnenie a správu profilu spoločnosti, manažment účastníkov, párovanie B2B rokovaní a reporty/štatistiky.

Strategicka architektura.png

Obrázok 1: Motivačná architektúra

Zainteresované osoby

  • Fyzické osoby:  
    • Občan (verejnosť)
    • Podnikateľ (fyzická osoba napr. SZČO)
    • Zamestnanec SARIO
  • Právnické osoby
    • Podnikateľ (Právnická osoba)
    • Investor (zahraničný subjekt)
    • Slovenská agentúra pre rozvoj investícií a obchodu
    • Ministerstvo hospodárstva Slovenskej republiky
    • Ministerstvo investícií, regionálneho rozvoja a informatizácie SR

Dotknuté úseky VS:

  • U00008 Podpora malého podnikania a stredného podnikania vrátane podpory potravinárskych produktov, ktoré nie sú zaradené do prílohy I Zmluvy o fungovaní Európskej únie a podpory spracovania dreva a biotechnológií
  • U00009 Stratégia tvorby podnikateľského prostredia a podpora podnikateľského prostredia vrátane podpory potravinárskeho podnikateľského prostredia, ktorého produkty nie sú zaradené do prílohy I Zmluvy o fungovaní Európskej únie a podnikateľského prostredia v oblasti  spracovania dreva a biotechnológií

Dotknuté agendy VS:

  • A0000036 Posudzovanie investičného zámeru, poskytovanie a rozhodovanie o schválení investičnej pomoci
  • A0000037 Stratégia tvorby podnikateľského prostredia a podpora podnikateľského prostredia vrátane podpory potravinárskeho podnikateľského prostredia, ktorého produkty nie sú zaradené do prílohy I Zmluvy o fungovaní Európskej únie a podnikateľského prostredia v oblasti spracovania dreva a biotechnológií
  • A0003198 Podpora malého podnikania a stredného podnikania

Dotknuté Životné situácie alebo ich časti:

  • 003 Iná podpora, slobodný prístup k informáciám, prístup k odtajneným skutočnostiam, archívy

Dotknuté informačné systémy:

  • Interaktívny systém dodávateľských reťazcov (isvs_10305)

Identifikované problémy súčasného stavu

Dôvodom vypracovania navrhovaného projektu je riešenie aktuálnych problémov a identifikovaných príležitostiach na zlepšenie súčasného stavu:

  • Nízka miera automatizácie a optimalizácie procesov – viaceré aktivity v rámci agendy sú časovo náročné a používateľsky menej prívetivé.
  • Nízka miera využívania spoločných eGovernment modulov.
  • Získavanie údajov o spoločnostiach z tretej strany je finančne náročná a využívanie týchto údajov značne obmedzené – v súčasnosti sú základné údaje získavané prostredníctvom integrácie tretej strany, ktorých využívanie pre potreby SARIO je značne obmedzená cenovou politikou dodávateľa.
  • Nízka aplikačná podpora zamestnancov SARIO pri manažovaní rokovaní prostredníctvom B2B podujatí.
  • Získavanie informácií prostredníctvom prieskumu je časovo náročné.

Hlavné ciele

Hlavným cieľom projektu je Rozvoj procesov Interaktívneho systému dodávateľských reťazcov, ktorý pozostáva z:

  • Optimalizácia hlavných procesov na strane SARIO – zníženie administratívnej záťaže a zvýšenie použiteľnosti UI/UX
  • Využívanie spoločných eGovernment modulov – integrácia súčasného riešenia na modul procesnej integrácie a integrácie údajov.
  • Získavanie údajov o spoločnostiach integráciou na štátne registre prostredníctvom systému IS CSRÚ a umožnenie ich publikovania na webový portál podľa potrieb SARIO.
  • Zavedenie aplikačnej podpory pre zamestnancov SARIO pri manažovaní rokovaní prostredníctvom B2B podujatí.
  • Zavedenie aplikačnej podpory pre zamestnancov SARIO pri automatizovanom informačnom prieskume.

Aplikované princípy informatizácie VS (v zmysle NKIVS):

  • Princíp P1: Orientácia na používateľa:
  • Princíp P2: Prirodzene digitálna verejná správa:
  • Princíp P3: Údaje sú aktíva
  • Princíp P6: Bezpečnosť

3.3Zainteresované strany/Stakeholderi

IDAKTÉR / STAKEHOLDER

SUBJEKT

(názov / skratka)

ROLA

(vlastník procesu/ vlastník dát/zákazník/ užívateľ …. člen tímu atď.)

Informačný systém

(MetaIS kód a názov ISVS)

1.ObčanFOObčan v roli verejnosti, ktorá má záujem o zistenie informáciíInteraktívny systém dodávateľských reťazcov (isvs_10305)
2.PodnikateľSZČOPodnikateľ, ktorý má potrebu získať podporu podnikania v roli SZČOInteraktívny systém dodávateľských reťazcov (isvs_10305)
3.Zamestnanec SARION/AZamestnanci SARIO, ktorí realizujú procesy vo vnútri organizácieInteraktívny systém dodávateľských reťazcov (isvs_10305)
4.PodnikateľPOPodnikateľ, ktorý má potrebu získať podporu podnikania v roli právnickej osobyInteraktívny systém dodávateľských reťazcov (isvs_10305)
5.Investor (zahraničný subjekt)N/AInvestor, ktorý na Slovensku hľadá vhodných dodávateľov pre svoj investičný zámerInteraktívny systém dodávateľských reťazcov (isvs_10305)
6.Slovenská agentúra pre rozvoj investícií a obchoduSARIOVlastník a realizátor projektuInteraktívny systém dodávateľských reťazcov (isvs_10305)
7.Ministerstvo hospodárstva Slovenskej republikyMHSRNadriadená organizácia SARIO 
8.Ministerstvo investícií, regionálneho rozvoja a informatizácie SRMIRRIPrevádzkovateľ IS CSRÚ (IS CDPI) 

3.4Ciele projektu

ID

 

Názov cieľa

Názov strategického cieľaSpôsob realizácie strategického cieľa
1Dobudovať digitálne prostredie založené na zdieľaní údajov vo verejnej správePoužívanie služieb eGovernmentu občanmi (DESI)Integráciou na systém IS CDPI

3.5Merateľné ukazovatele (KPI)

  • Optimalizácia hlavných procesov na strane SARIO – zníženie administratívnej záťaže a zvýšenie použiteľnosti UI/UX
  • Využívanie spoločných eGovernment modulov – integrácia súčasného riešenia na modul procesnej integrácie a integrácie údajov.
  • Získavanie údajov o spoločnostiach integráciou na štátne registre prostredníctvom systému IS CSRÚ a umožnenie ich publikovania na webový portál podľa potrieb SARIO.
  • Zavedenie aplikačnej podpory pre zamestnancov SARIO pri manažovaní rokovaní prostredníctvom B2B podujatí.
  • Zavedenie aplikačnej podpory pre zamestnancov SARIO pri automatizovanom informačnom prieskume.
ID

 

ID/Názov cieľa

Názov
ukazovateľa (KPI)
Popis
ukazovateľa
Merná jednotka
 
AS IS
merateľné hodnoty
(aktuálne)
TO BE
Merateľné hodnoty
(cieľové hodnoty)
Spôsob ich merania
1Získavanie údajov o spoločnostiach integráciou na štátne registre prostredníctvom systému IS CSRÚPočet integrovaných registrovPočet integrovaných registrovks08Overenie integrácie
2Zavedenie aplikačnej podpory pre zamestnancov SARIOPočet vytvorených modulovPočet vytvorených modulovks01Akceptácia riešenia

3.6Špecifikácia potrieb koncového používateľa

Táto časť sa týka projektov, ktoré sú zamerané na vývoj alebo rozvoj  ISVS/s elektronickými službami , ktoré  majú grafické alebo iné používateľské rozhranie a sú určené pre občanov/podnikateľov (alebo aj pracovníkov verejnej správy pracujúcich s agendovým systémom), ďalej označených ako koncoví používatelia. 

  • Špecifikácia požiadaviek koncových používateľov musí byť v súlade s legislatívou (s aktuálne platnou alebo s návrhom jej zmien ako súčasť projektu) a postupmi pri vytváraní elektronických služieb verejnej správy, ako sú napríklad používateľský prieskum, mapovanie používateľskej cesty, vytváranie informačnej architektúry a testovanie prototypov podľa vyhlášky 547/2021 Z. z. o elektronizácii agendy verejnej správy.
  • Definujte skupiny koncových používateľov elektronických služieb a popísať cieľové skupiny koncových používateľov, vrátane sociodemografických charakteristík cieľových skupín alebo účastníkov používateľského prieskumu. Príklad definície skupín koncových používateľov, tzv. persón nájdete v metodike pre tvorbu používateľsky kvalitných elektronických služieb (Metodika pre tvorbu používateľsky kvalitných elektronických služieb).
  • Špecifikujte potreby resp. ciele koncových používateľov (ideálne formou tzv.  používateľského príbehu) ktoré identifikujú, čo jednotlivé skupiny koncových používateľov od elektronickej  služby požadujú.  Ak ide o zmenu (upgrade) elektronickej služby, ktorá už existuje, dajú sa ciele  koncových používateľov kvantitatívne odmerať: 
    • ako sa koncovým používateľom svoje potreby (resp. ciele) darí napĺňať (performance indikátory) - napr. priemerný čas pre naplnenie potreby, miera chybovosti, miera dokončenia, pomer online/offline transakcií, 
    • ako sú koncoví používatelia (ne)spokojní s existujúcou  elektronickou službou (Net Promoter Score, Customer effort Score, customer satisfaction....),
  • Pri rozvoji existujúcej elektronickej služby je možné použiť výstupy zo zisťovania spätnej väzby k elektronickej službe, ak z nich vyplývajú požiadavky koncových používateľov na rozvoj služby.  
  • Ak ide o vytváranie novej koncovej služby, realizuje sa používateľský prieskum spravidla metódou kvalitatívneho prieskumu (formou štruktúrovaného rozhovoru alebo dotazníka, ktorého cieľom je pomenovať základné ciele/potreby koncových používateľov) a očakávania od kvality a funkcionalít plánovanej elektronickej služby (odkaz návod (v angličtine): Ako vybrať vhodnú metódu používateľského prieskumu).
  • Priložte Report zákazníckeho prieskumu ako prílohu Projektového zámeru,  ktorý popíše priebeh a metódy prieskumu, základné kvantitatívne ukazovatele, veľkosť vzorky atď. 
  • Doplňte Katalóg požiadaviek (funkčné, nefunkčné) o priorizované požiadavky z používateľského prieskumu v dokumente M-05 Analýza nákladov a prínosov, karta Katalóg požiadaviek I-04 Katalóg požiadaviek.
    .

3.7Riziká a závislosti

Doplňte/stručne popíšte RIZIKÁ a ZÁVISLOSTI (detail v prílohe ZOZNAM RIZÍK a ZÁVISLOSTI) Zoznam RIZÍK a ZÁVISLOSTI - je potrebné počas celej realizácie projektu aktualizovať.

  • V prípade projektov financovaných zo zdrojov EÚ je povinné vyhodnotenie rizík súvisiacich s:
  • Realizáciou verejného obstarávania (t.j. napr. pred vyhlásením VO bude dopad na projekt Fatálny, ak má objednávateľ už uzatvorenú dodávateľskú zmluvu, bude dopad nevýznamný a pod...)
  • Legislatívou: vyhodnotiť potrebu zmeny legislatívy (ak je potrebné prijať nový zákon tak bude dopad Fatálny)
  • Časovým priebehom: ak je harmonogram realizácie naplánovaný do konca roka 2023, tak bude dopad Fatálny.

3.8Stanovenie alternatív v biznisovej vrstve architektúry

Na základe identifikovaného rozsahu problému navrhujete v projektovom zámere rôzne riešenia biznis procesov (podmnožiny problému). Alternatíva môže pokrývať procesy všetkých stakeholderov (zainteresované strany) alebo iba vybraných, celú životnú situáciu alebo len časť. Na úrovni stanovenia alternatívy je budúci stav biznis procesov popísaný rámcovo, pri zúžení alternatív na tie, ktoré vstupujú do CBA konkrétne.
SABLONA_I-02_PROJEKTOVY_ZAMER_Projekt_XYZ_YYMMDD_v0.1_6f4954d8b4fa4b84.png

3.9Multikriteriá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.
Niektoré (nie všetky) kritériá môžu byť označené ako KO kritériá. KO kritériá označujú biznis požiadavky na riešenie, ktoré sú z hľadiska rozsahu identifikovaného problému a motivácie nevyhnutné pre riešenie problému a všetky akceptovateľné alternatívy ich tak musia naplniť. Alternatívy, ktoré nesplnia všetky KO kritériá, môžu byť vylúčené z ďalšieho posudzovania. KO kritériá nesmú byť technologické (preferovať jednu formu technologickej implementácie voči druhej).
Príklad šablóny pre spracovanie MCA

 KRITÉRIUMZDÔVODNENIE KRIÉRIA

STAKEHOLDER
1

STAKEHOLDER
2

STAKEHOLDER
3

BIZNIS VRSTVAKritérium A (KO) XXX
Kritérium B (KO) XX 
Kritérium C (KO)  XX
Kritérium D (KO)  XX
Kritérium E XX 
Kritérium F X X
Príklad šablóny pre vyhodnotenie MCA
Zoznam kritérií

Alternatíva
1

Spôsob
dosiahnutia

Alternatíva 2

Spôsob
dosiahnutia

Kritérium Aánovysvetlenie prečo ánoánovysvetlenie prečo áno
Kritérium Bánovysvetlenie prečo ánonie 
Kritérium Cánovysvetlenie prečo ánonie 
Kritérium Dánovysvetlenie prečo ánonie 

3.10Stanovenie alternatív v aplikačnej vrstve architektúry

Alternatívy na úrovni aplikačnej architektúry reflektujú alternatívy vypracované na základe „nadradenej“ architektonickej biznis vrstvy, pričom vďaka uplatneniu nasledujúcich princípov aplikačná vrstva architektúry dopĺňa informácie k alternatívam stanoveným pomocou biznis architektúry.
Pre klasifikáciu alternatív za účelom ďalšieho porovnania aplikačnej vrstvy a architektúry je potrebné zadefinovať nasledovné požiadavky:

  • Nutné – aplikačné moduly/funkcionality, ktoré sú nevyhnutné pre dosiahnutie cieľov
  • Preferované – aplikačné moduly/funkcionality, ktoré rozvíjajú biznis alternatívu a vytvárajú dodatočné prínosy, započítané v Analýze nákladov a prínosov M-05 (BC/CBA povinná pre projekty nad 1 000 000,- EUR)
  • Aplikačná vrstva by mala byť schopná rozdeliť moduly do skupín podľa koncových služieb/funkcionalít, ktoré plnia nutné a preferované požiadavky.
    SABLONA_I-02_PROJEKTOVY_ZAMER_Projekt_XYZ_YYMMDD_v0.1_5701ef6f26440efc.png

3.11Stanovenie alternatív v technologickej vrstve architektúry

Alternatívy na úrovni technologickej architektúry reflektujú alternatívy vypracované na základe „nadradenej“ architektonickej aplikačnej vrstvy, pričom sa prioritne uvažuje o využití služieb vládneho cloudu (privátne aj verejné cloudové služby zverejnené v katalógu služieb vládneho cloudu (odkaz na katalóg služieb ).
V prípadoch, kedy by nebolo ekonomicky výhodné využiť vládny cloud v plnom rozsahu projektu, je možné uvažovať aj o iných/ďalších alternatívach: hybridnej (časť aplikácií využíva privátny vládny cloud a časť vlastný HW žiadateľa, resp. časť aplikácii využíva služby komerčného poskytovateľa cloudových služieb), nasadenie v prostredí komerčného cloudu alebo v krajnom prípade sú všetky aplikácie nasadené v prostredí vlastného HW žiadateľa (prípady zohľadnenia bezpečnosti alebo iných povinností).
Ekonomická výhodnosť technologickej alternatívy je preukázaná nižšími nákladmi na TCO projektu. Spracovateľ projektového zámeru je povinný preukázať, že zvolené riešenie je ekonomicky výhodnejšie. V prípade, že z bezpečnostných alebo iných dôvodov nezvolil najvýhodnejšiu alternatívu (resp. neposudzoval viacero alternatív), spracovateľ doloží zdôvodnenie potreby daného technologického riešenia. V zdôvodnení sú uvedené konkrétne požiadavky a ich parametre, ktoré neumožnili zvoliť najvýhodnejšie riešenie alebo porovnať viacero alternatív.
SABLONA_I-02_PROJEKTOVY_ZAMER_Projekt_XYZ_YYMMDD_v0.1_a966e8b8a99b13da.png
Ako alternatívu nepovažujeme porovnanie krabicových „off-the-shelf“ riešení (COTS) riešení s alternatívou vývoja aplikácií „na zelenej lúke“ a to z dôvodu toho, že žiadateľ pre zachovanie nediskriminačných podmienok vo verejnom obstarávaní nevie vopred určiť, či dostane ponuku od uchádzača k vývoju na zelenej lúke, alebo sa všetky ponuky od uchádzačov vo verejnom obstarávaní budú vzťahovať na COTS riešenie. Výnimka je v prípade, ak žiadateľ uvažuje použiť konkrétne COTS riešenie ako podmienku pre uchádzača v rámci procesu verejného obstarávania a to vzhľadom na ekonomické alebo iné dôvody preukázané v dokumente.
Výber alternatív prebieha v dvoch kolách. Prvé kolo predstavuje uplatnenie multikriteriálnej analýzy (ďalej len „MCA“) – výber relevantných alternatív. Druhé kolo predstavuje vypracovanie Analýzy nákladov M-05 BC/CBA. Do druhého kola vstupujú alternatívy ktoré splnili všetky vylučovacie kritéria stanovené v multikritériálnej analýze. Minimálny počet variant, je stanovený na 3:

  • nulový variant, ktorý sa neposudzuje v MCA a je automaticky porovnávajúcim variantom v M-05 Analýza nákladov a prínosov,
  • preferovaný variant, ktorý splnil všetky kritéria MCA,
  • minimalistický variant“, ktorý vychádza z rovnakého biznis variantu ako preferovaný variant, ale realizuje iba „nutné“ aplikačné moduly.

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

  • Doplňte informácie – POPIS PRODUKTU - čo bude/čo chcete, aby bolo po ukončení projektu dodané
    • projektové výstupy podľa vyhlášky 401/2023 o riadení projektov (vrátane zdrojových kódov)
    • koncové služby a biznis procesy, ktoré sú predmetom dodávky projektu
    • biznis objekty, ktoré majú byť vstupmi a výstupmi zo systému – napr. podania, formuláre, rozhodnutia, reporty, dáta, aplikačné rozhrania
  • Doplniť informáciu, resp. identifikovať VLASTNÍKOV PROCESOV (toto je dôležitá informácia pre budúce riadenie projektu a schvaľovanie výstupov projektu).

5.NÁHĽAD ARCHITEKTÚRY

  • Doplňte krátky POPIS BUDÚCEHO CIEĽOVÉHO PRODUKTU PROJEKTU z pohľadu biznis/aplikačnej/technologickej architektúry v závislosti od charakteru projektu a výsledku analýzy alternatív riešenia,
  • Doplňte a detailne spracujte funkčné a nefunkčné požiadavky vyplývajúce z analýz alternatív riešenia vo všetkých vrstvách architektúry a vyplňte požiadavky v dokumente  M-05 Analýza nákladov a prínosov, karta Katalóg požiadaviek., I-04 Katalóg požiadaviek
  • Doplňte stručný náhľad budúcej IT architektúry (biznis, aplikačná, technologická) riešenia, ktorý podľa potreby pozostáva aj z viacerých obrázkov (diagramov), aby dostatočne zrozumiteľne znázornil predmet dodávky, jeho kontext a zmeny v architektúre verejnej správy (objednávateľa, realizátora projektu), ktoré projekt realizuje,
    • Náhľad architektúry vytvorte v modelovacom nástroji pomocou notácie ArchiMate (https://publications.opengroup.org/standards/archimate), v prípade potreby väčšej detailizácie biznis procesov môžete použiť notáciu BPMN (http://www.omg.org/spec/BPMN/2.0/),
    • Pre vytvorenie náhľadu architektúry použite modelovací nástroj, ktoré môže byť buď integrovaný na spoločný repozitár2 architektonických modelov verejnej správy, alebo modelovací nástroj, ktorý podporuje export modelu do štandardizovaných výmenných formátov súborov (The Open Group ArchiMate Model Exchange File Format Standard) 3 a export súborov podľa špecifikácie BPMN 2.04,
    • Pre jednoznačnú identifikovateľnosť komponentov v náhľade architektúry uveďte aj ich MetaIS kódy
    • Očakáva sa, že ak realizujete popis dizajn procesov podľa pravidiel EVS, tak všetky výstupy musia byť v súlade s metodikou a postupom: https://www.minv.sk/?np-optimalizacia-procesov-vo-verejnej-sprave&subor=255448 .
    • Náhľad architektúry v tomto výstupe I-02 Projektový zámer by mal byť v súlade s jeho detailizáciou vo výstupe I-03 Prístup k projektu, ak objednávateľ podľa prílohy č. 1 vyhlášky 401/2023 Zz pripravuje aj výstup I-03 Prístup k projektu.
    • Náhľad architektúry v tomto výstupe I-02 Projektový zámer by mal byť v súlade s výstupom M-06 - aktualizáciou evidencie e-Government komponentov v centrálnom metainformačnom systéme verejnej správy (MetaIs) a komponenty, ktorých sa projekt týka by mali mať upravenú evidenciu ich stavu a fázu ich životného cyklu.
    • Príklad náhľadu na architektúru podľa metamodelu e-Government komponentov evidovaných v MetaIS:
      Obrázok 8
      Obrázok 1 Príklad náhľadu architektúry v notácii ArchiMate

5.1Prehľad e-Government komponentov

Ak bude vytváraný aj výstup I-03 Prístup k projektu, môže byť táto kapitola z dokumentu I-02 Projektový zámer vypustená, pretože jej obsah bude spracovaný vo výstupe I-03 Prístup k projektu.
Obsah tejto kapitoly je prehľadom realizácie výstupu M-06 - aktualizácia evidencie e-Government komponentov v centrálnom metainformačnom systéme verejnej správy (MetaIs). Objednávateľ5 plní výstupom M-06 povinnosti orgánu riadenia sprístupňovať a aktualizovať informácie o informačných technológiách verejnej správy prostredníctvom centrálneho metainformačného systému verejnej správy (MetaIS) bezodkladne podľa § 12 ods. 1 písm. b) zákona 95/2019 Z.z.
V okamihu odovzdania výstupu I-02 Projektový zámer objednávateľ:

  1. vytvorí náhľady architektúry v modelovacom nástroji, ktorý môže byť buď integrovaný na spoločný repozitár  architektonických modelov verejnej správy, alebo ktorý podporuje export modelu do štandardizovaných výmenných formátov súborov,
  2. uloží architektonické modely súčasnej a budúcej architektúry riešenia buď do repozitára architektonických modelov verejnej správy alebo do projektovej dokumentácie I-02 ako prílohu  vo výmennom formáte pre uloženie modelu, 
  3. aktualizuje v MetaIS e-Government komponenty, ktoré budú realizované alebo menené projektom alebo veľkou zmenovou požiadavkou a to koncové služby, ISVS, ich moduly, aplikačné služby, atribúty a vzájomné vzťahy týchto e-Government komponentov a ich vzťahy (integrácie) na spoločné ISVS alebo ISVS iných správcov, ktoré budú využívať. 
    Objednávateľ v tejto kapitole uvedie prehľad nasledovných e-Government komponentov, ktoré budú výstupom projektu (dodané nové alebo zmenené) a ktoré evidoval v rámci výstupu M-06 v MetaIS:

5.1.1Prehľad koncových služieb – budúci stav:

Kód KS (z MetaIS)Názov KSPoužívateľ KS (G2C/G2B/G2G/G2A)Životná situáciab(+ kód z MetaIS)Úroveň elektronizácie KS

5.1.2Prehľad budovaných/rozvíjaných ISVS v projekte – budúci stav:

Kód ISVS (z MetaIS)Názov ISVSModul ISVS (zaškrtnite ak ISVS je modulom)Stav IS VSTyp IS VSKód nadradeného ISVS (v prípade zaškrtnutého checkboxu pre modul ISVS)
isvs_10305Interaktívny systém dodávateľských reťazcovVyberte jednu z možností
c_stav_isvs.3
Vyberte jednu z možností
c_typ_isvs.1
  

5.1.3Prehľad budovaných aplikačných služieb – budúci stav:

Kód AS (z MetaIS)Názov ASISVS/modul ISVS (kód z MetaIS)Aplikačná služba realizuje KS (kód KS z MetaIS)
as_66328Konzumácia údajov z CSRÚ   

5.1.4Prehľad integrácii ISVS na spoločné ISVS6 a ISVS iných OVM alebo IS tretích strán

  • Uviesť prehľad ISVS, pri ktorých sa plánuje využívanie služieb iných ISVS, spoločných blokov (SaaS) alebo služieb tretích strán v TO BE stave.
  • Uviesť prehľad ISVS integrovaných na spoločné moduly podľa zákona č. 305/2013 Zz.
  • Plánované využívanie a integrácie služieb iných ISVS musí byť evidované v MetaIS – zaevidovanie vzťahu na aplikačnú službu určenú na externú integráciu poskytujúcim ISVS

Kód ISVS
(z MetaIS)

Názov ISVS

Kód integrovaného ISVS
(z MetaIS)

Názov integrovaného ISVS
    
    
  • Na informáciu je v nasledujúcej tabuľke prehľad AS na externú integráciu Spoločných modulov podľa § 10 zákona 305/2013 Zz. Vo finálnom dokumente túto tabuľku prehľadu AS spoločných modulov vymažte:
 
MetaIS kódNázovAS na externú integráciu (využitie Spoločného modulu)
isvs_8846Autentifikačný modulAutentifikácia používateľa na ÚPVS (BOK) (as_59698)
isvs_8847Elektronické schránkyVytváranie, odosielanie a prijímanie elektronických správ (as_59630)
isvs_8848Modul elektronických formulárovPoskytnutie vzorov e_formulárov (sluzba_is_185)
isvs_9369Modul elektronického doručovaniaCentrálne úradné doručovanie (as_59701)
isvs_8850Platobný modulRealizácia platieb správnych a súdnych poplatkov (as_59700)
isvs_9368Modul centrálnej elektronickej podateľneOverovanie elektronického podpisu (KEP) (as_59702)
isvs_8851Modul dlhodobého uchovávania (nepovinný)Uchovávanie elektronických dokumentov (as_59703)
isvs_9370Notifikačný modul (nepovinný)Zasielanie oznámení prostredníctvom elektronických komunikačných kanálov (sms, email) (as_59699)
isvs_9513Centrálna API manažment Platforma (CAMP) ako realizácia Modulu procesnej integrácie a integrácie údajovPoskytovanie služby integráciou na AS CAMP (as_60157)
isvs_9513Centrálna API manažment Platforma (CAMP) ako realizácia Modulu procesnej integrácie a integrácie údajovKonzumovanie služby iného ISVS prostredníctvom CAMP (as_60158)
isvs_5836IS CSRÚ ako realizácia Modulu procesnej integrácie a integrácie údajovPoskytovanie dát na integráciu (as_59119)
isvs_5836IS CSRÚ ako realizácia Modulu procesnej integrácie a integrácie údajovPoskytnutie konsolidovaných údajov o subjekte (sluzba_is_49250)
isvs_5836IS CSRÚ ako realizácia Modulu procesnej integrácie a integrácie údajovPoskytnutie konsolidovaných referenčných údajov z IS CSRÚ na synchronizáciu (sluzba_is_49253)

5.1.5Aplikačné služby na integráciu

Uveďte v nasledujúcej tabuľke budované aplikačné služby a ich využitie na integráciu na spoločné moduly a iné ISVS alebo ich poskytovanie na externú integráciu a predpokladané vybudovanie cloudových služieb “softvér ako služba“ (SaaS),

  • Plánované aplikačné služby musia byť evidované v MetaIS s fázou životného cyklu a musia mať v MetaIs evidované všetky povinné atribúty a vzťahy,
  • Evidencia integrácií v MetaIS sa realizuje evidovaním vzťahov aplikačných služieb budovaného//rozvíjaného ISVS na príslušné aplikačné služby nadrezortných ISVS. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS, kap. 2.1.3.3.1 a kap. 2.1.3.3.2. Detailný popis služieb IS CSRÚ a poskytovaných objektov evidencie je v aktuálnej verzii integračného manuálu IS CSRÚ.
  • Ak IS povinnej osoby potrebuje konzumovať alebo poskytovať služby iným ISVS alebo IS tretích strán prostredníctvom modulu Centrálna API Manažment Platforma (CAMP) a jej modulu API Gateway, je potrebné aplikačné služby IS Povinnej osoby naviazať na príslušné integračné služby CAMP (API Gatewy).
  • Budované aplikačné služby musia mať v MetaIs evidované SLA parametre pre východiskový a cieľový stav. Podrobné informácie sú uvedené v Používateľskej príručke MetaIS, kap. 2.1.3.
    AS (Kód MetaIS)Názov ASRealizuje ISVS (kód MetaIS)Poskytujúca alebo KonzumujúcaIntegrácia cez CAMPIntegrácia s IS tretích stránSaaSIntegrácia na AS poskytovateľan (kód MetaIS)

5.1.6Poskytovanie údajov z ISVS do IS CSRÚ

Uveďte v tabuľke prehľad poskytovaných údajov (objektov evidencie, ďalej OE) z ISVS do IS CSRÚ v TO BE stave.

ID OENázov (poskytovaného) objektu evidencieKód ISVS poskytujúceho OENázov ISVS poskytujúceho OE
    
    
    

5.1.7Konzumovanie údajov z IS CSRÚ

Uveďte v tabuľke prehľad konzumovaných údajov z IS CSRÚ v TO BE stave. Súčasné dostupné objekty evidencie a údaje v IS CSRÚ sú uvedené v integračnom manuáli IS CSRÚ.

ID OENázov (konzumovaného) objektu evidencieKód a názov ISVS konzumujúceho OE z IS CSRÚKód zdrojového ISVS v MetaIS
    
    
    

5.1.8Prehľad plánovaného využívania infraštruktúrnych služieb (cloudových služieb) – budúci stav:

Zaevidujte MetaIS využívanie cloudových infraštruktúrnych služieb vašimi ISVS. Podrobné informácie o evidencii využívania infraštruktúrnych služieb sú uvedené v Používateľskej príručke MetaIS, kap. 2.1.4.3 ISVS využívajúci infraštruktúrne služby.

Kód infraštruktúrnej služby
(z MetaIS)

Názov infraštruktúrnej služby

Kód využívajúceho ISVS
(z MetaIS)

Názov využívajúceho ISVS
    
    
V súlade s NKIVS by technologická architektúra mala byť založená na cloudových službách uvedených v katalógu služieb, ktoré prešli procesom klasifikácie, hodnotenia, registrácie a zaradenia do katalógu služieb zverejnenom na stránke MIRRI: https://www.mirri.gov.sk/sekcie/informatizacia/egovernment/vladny-cloud/katalog-cloudovych-sluzieb.

6.LEGISLATÍVA

Doplniť popis potrebných zmien v oblasti legislatívy pre naplnenie cieľov a dodanie výstupov projektu.
Uviesť konkrétne zákony, prípadne aj paragrafy, ktoré budú predmetom legislatívnych zmien.
Doplniť popis, aký je negatívny dopad na výstupy projektu, jeho ciele a rozsah a časový harmonogram, ak vyššie uvedené zmeny v zákonoch nebudú realizované.

7.ROZPOČET A PRÍNOSY

Počas Prípravnej a iniciačnej fázy, je potrebné predložiť samostatný dokument M-05 Analýza nákladov a prínosov (xls. BC/CBA) v predpísanej štruktúrovanej forme.(povinné v prípade projektov nad 1 000 000,- EUR). Pre iný, než veľký projekt - projekt pod 1 000 000,- EUR - objednávateľ detailne opíše nákladovú a prínosovú stránku a postup, ktorý je zvolený na cenovú kalkuláciu nákladov a prínosov projektu.
V tejto časti dokumentu sa od Vás očakáva štruktúrovane popísať:

  • vypočítané náklady (vývoj + prevádzka) v T10 (t.j. na 10 rokov dopredu)
  • vypočítané prínosy v T10 (t.j. na 10 rokov dopredu)
  • slovne popísať výpočet prínosov, z čoho sú čerpané vstupné hodnoty
  • rok návratnosti (doplnenie ukazovateľov: ENPV, FNPV, BCR)

7.1Sumarizácia nákladov a prínosov

Náklady

Názov
modulu

Názov
modulu

Názov
modulu

Všeobecný materiál   
IT - CAPEX   
Aplikácie   
SW   
HW   
IT - OPEX- prevádzka   
Aplikácie   
SW   
HW   
Prínosy   
Finančné prínosy   
Administratívne poplatky   
Ostatné daňové a nedaňové príjmy   
Ekonomické prínosy   
Občania (€)   
Úradníci (€)   
Úradníci (FTE)   
Kvalitatívne prínosy   
    
Interpretácia výsledkov:
Ekonomická a finančná efektívnosť projektu je v analýze prínosov nákladov hodnotená kvantitatívne pomocou nasledujúcich ukazovateľov (prahové hodnoty v zmysle platných dokumentov v prípade financovania zo zdrojov EÚ sú uvedené):
  • Pomer prínosov a nákladov (BCR): viac ako 1,00
  • Ekonomická vnútorná výnosová miera vyjadrená v % (EIRR): viac ako 5,0 %
  • Ekonomická čistá súčasná hodnota vyjadrená v eurách (ENPV): viac ako 0
    Pre účely financovania z prostriedkov EU vyjadruje Analýza nákladov a prínosov BC/CBA aj nasledovné ukazovatele:
  • Finančná vnútorná výnosová miera v % (FIRR)
  • Finančná čistá súčasná hodnota v eur (FNPV).
    Nie všetky sociálno-ekonomické vplyvy sa dajú vždy vyčísliť a zhodnotiť. Je to preto, že okrem odhadu ukazovateľov výkonnosti by sa mala zohľadniť aj úvaha o nepeňažných nákladoch a výnosoch, najmä vo vzťahu k týmto otázkam: (čistý) dosah na zamestnanosť, ochrana životného prostredia, sociálna rovnosť a rovnaké príležitosti.
    V prípade ak dosiahnu uvedené hodnoty viaceré varianty posudzované v rámci Analýzy nákladov, odporúča sa pri výbere finálnej alternatívy zohľadniť výšku BCR, dôležitosť nekvantifikovaných spoločenských prínosov a mieru naplnenia stanovených cieľov. Po vzore krajín ako Veľká Británia sa prioritne odporúča realizovať projekty, kde prínosy prevyšujú náklady štvornásobne (BCR aspoň 4,00).
    Príklad: Kvalitatívne prínosy projektov
    Problém: Proces získania stavebného povolenia jeden z najdlhších v EÚ.
    Príklady kvalitatívnych prínosov projektu, ktoré je možné finančne oceniť:
  • Zvýšenie ekonomickej aktivity v stavebnom sektore (zvýšenie rastu HDP)
  • Nižšie spoločenské škody, spojené s búraním čiernych stavieb
    Príklady kvalitatívnych prínosov projektu, ktoré nie je možné spoľahlivo finančne oceniť:
  • Zníženie miery korupcie
  • Zníženie miery stresu zamestnancov stavebných úradov
    Vyššia spokojnosť verejnosti s procesmi územného a stavebného konania.

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

Doplňte highlevel HARMONOGRAM, ktorý sa neskôr (v ďalších fázach/dokumentoch) bude detailizovať:

  • KEDY potrebujete (chcete) ZAČAŤ? Napíšte TERMÍN (mesiac/rok)
  • KEDY potrebujete (chcete) SKONČIŤ (mať dodaný výstup)? Napíšte TERMÍN (mesiac/rok).
  • Fakturačné míľniky: jednotlivé míľniky projektu naviažte aj na fakturačné míľniky (v jednej tabuľke), aby ste si mohli kontrolovať cashflow v projekte.
  • Míľniky Verejného obstarávania (VO) – do harmonogramu si doplňte aj míľnik procesu verejného obstarávania (celý proces).
IDFÁZA/AKTIVITA

ZAČIATOK
(odhad termínu)

KONIEC
(odhad termínu)

POZNÁMKA
1.Prípravná fáza a Iniciačná fázanapr. 01/2020napr. 02/2020 
2.Realizačná fázanapr. 05/2020napr. 10/2020 
2aAnalýza a Dizajnnapr. 05/2020napr. 06/2020 
2bNákup technických prostriedkov, programových prostriedkov a služiebnapr. 07/2020napr. 08/2020Napr. Je potrebné obstarať dodávateľa IS riešenia/ licencie7/ konzultačné služby
2cImplementácia a testovanienapr. 05/2020napr. 06/2020 
2dNasadenie a PIPnapr. 12/2020napr. 02/2021PIP - 3 mesiace po nasadení
3.Dokončovacia fázanapr. 11/2020napr. 12/2020 
4.Podpora prevádzky (SLA)napr. 01/2021napr. 01/2025Napr. Je potrebné obstarať SLA zmluvu (Zmluvu o podpore prevádzky IS)?
Odporúčame – pre reportovacie účely projektu si vytvorte high-level projektový plán v MS EXCEL alebo v inom formáte/nástroji pre projektové riadenie.
Doplňte informácie o vybranej metóde riadenia projektu a zdôvodniť výber:
Ak realizujete projekt metódou Waterfall:
Waterfall - vodopádový prístup počíta s detailným naplánovaním jednotlivých krokov a následnom dodržiavaní postupu pri vývoji alebo realizácii projekty. Projektovému tímu je daný minimálny priestor na zmeny v priebehu realizácie. Vodopádový prístup je vhodný a užitočný v projektoch, ktorý majú jasný cieľ a jasne definovateľný postup a rozdelenie prác.
Objednávateľ projektu vypracuje funkčnú a technickú špecifikáciu,
SABLONA_I-02_PROJEKTOVY_ZAMER_Projekt_XYZ_YYMMDD_v0.1_ea8a81537e587b5e.png
Ak realizujeme projekt metódou Agile:
Agilný prístup k riadeniu projektov sa uplatňuje v projektoch, u ktorých je jasný rámcový cieľ, ale z najrôznejších dôvodov je nemožné presne definovať všetky dlhodobé požiadavky bez priebežných prototypov. Pri agilných metódach práce sa realizujú malé porcie výsledkov v každom vývojovom cykle, iterácii, v tesnej spolupráci so zákazníkom. Agile metódu je možné aplikovať za podmienok definovaných vo vyhláške MIRRI č. 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke.
SABLONA_I-02_PROJEKTOVY_ZAMER_Projekt_XYZ_YYMMDD_v0.1_dcd0f7fe8c3f7b57.png

9.PROJEKTOVÝ TÍM

Zostavuje sa Riadiaci výbor (RV), v minimálnom zložení:

  • Predseda RV
  • Biznis vlastník
  • Zástupca prevádzky
  • Zástupca dodávateľa (dopĺňa sa až po VO / voliteľný člen)
  • Projektový manažér objednávateľa (PM)
    Zostavuje sa Projektový tím objednávateľa
  • kľúčový používateľ,
  • IT analytik alebo biznis analytik,
  • IT architekt,
  • biznis vlastník
  • manažér kvality (nepovinný člen pre projekty do 1 000 000,- EUR, povinný pri veľkých projektoch nad 1 000 000,- EUR,
  • manažér IT prevádzky (nepovinný člen)
  • manažér kybernetickej a informačnej bezpečnosti (nepovinný člen)
  • UX dizajnér (nepovinný člen)
  • iná špecifická rola (nepovinný člen)
  • doplniť tabuľku zodpovedných osôb, ktoré budú participovať v projekte
IDMeno a PriezviskoPozíciaOddelenieRola v projekte
1.Doplniť meno a priezviskoDoplniť pozíciu (pracovné zaradenie v línii)Doplniť názov org. útvaruDoplniť rolu v projekte
2.Doplniť meno a priezviskoDoplniť pozíciu (pracovné zaradenie v línii)Doplniť názov org. útvaruDoplniť rolu v projekte
3.Doplniť meno a priezviskoDoplniť pozíciu (pracovné zaradenie v línii)Doplniť názov org. útvaruDoplniť rolu v projekte
Vzor organizačnej štruktúry
SABLONA_I-02_PROJEKTOVY_ZAMER_Projekt_XYZ_YYMMDD_v0.1_d9faa472f626899.png
SABLONA_I-02_PROJEKTOVY_ZAMER_Projekt_XYZ_YYMMDD_v0.1_a6af23de6588b10b.png

9.1 PRACOVNÉ NÁPLNE

Doplniť podľa dokumentu z Riadiaceho Výboru projektu, prípadne zo splnomocnení alebo menovacích dekrétov . Tieto vstupy neskôr využijete pri dokumente PID.
VZORY a ŠABLONY zdrojových súborov sú tu: https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html  
Poznámka: Odporúčame – pozrite si VZOR pre MENOVACIE DEKRÉTY členov projektového tímu – vzor obsahuje názorný popis všetkých projektových rolí, ktoré vyžaduje Vyhláška 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke.

10.ODKAZY

Doplniť odkazy na už existujúce produkty v maximálnej miere – vyhnúť sa duplikovaným informáciám.

11.PRÍLOHY

Príloha : Zoznam rizík a závislostí (Excel): https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html
Poznámka: Odporúčame, si evidovať a vyhodnotiť pripomienky odbornej verejnosti

  • Podľa § 4 odsek 10 – Vyhláška 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke je potrebné zrealizovať pripomienkovanie Projektového zámeru odbornou verejnosťou
  • Odporúčame túto aktivitu formalizovať (do dokumentu)
  • Odporúčame vyhodnotenie zverejniť na webové sídlo objednávateľa (do projektového adresára) – v súlade s Vyhláškou 401/2023 Zz. Oznámenie o začatí verejného pripomienkovania sa zverejní v centrálnom metainformačnom systéme verejnej správy na mieste určenom Orgánom vedenia. Na schválenie riadiacemu výboru v prípravnej a iniciačnej fáze sa tieto výstupy predkladajú až po zverejnení vyhodnotenia pripomienok.
    Koniec dokumentu
    1 Notácia ArchiMate: https://publications.opengroup.org/standards/archimate
    2 Aktuálny spoločný repozitár architektonických modelov verejnej správy je https://avssr.horizzon.cloud/. O prístup do repozitára a poskytnutie licencie pre modelovací nástroj pracujúci s repozitárom modelov je potrebné požiadať na e-mailovej adrese: sprava_EA@mirri.gov.sk.
    3 Napr. modelovací nástroj Archi - Open Source ArchiMate Modelling: https://www.archimatetool.com.
    4 Napr. modelovací nástroj pre BPMN - Camunda Modeler - Open Source Desktop Modeler: https://camunda.com/download/modeler/.
    5 Podľa § 2 ods. 1 písm. i) vyhlášky MIRRI č. 401/2023 Z.z. o riadení projektov a zmenových požiadaviek v prevádzke informačných technológií verejnej správy sa objednávateľom rozumie správca alebo prevádzkovateľ ITVS, ktorý projekt realizuje alebo chce realizovať.
    6 Spoločné moduly podľa zákona č. 305/2013 e-Governmente
    7 EUPL licencie: https://joinup.ec.europa.eu/sites/default/files/inline-files/EUPL%201_1%20Guidelines%20SK%20Joinup.pdf