PROJEKTOVÝ ZÁMER

(Verzia dokumentu v1.82/09_2021)

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

Identifikácia projektu

Schvaľovanie dokumentu

Obsah

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 (príklady) 3

2.1.1. Konvencie – pravidlá názvoslovia, číslovania a verzionovania - požiadaviek (príklady) 3

2.1.2. Použité skratky (príklady) 4

2.1.3. Konvencie pre typy požiadaviek (príklady) 4

1. DEFINOVANIE PROJEKTU. 5

3.1.    Manažérske zhrnutie. 5

3.2.    Motivácia a rozsah projektu. 5

3.3.    Zainteresované strany/Stakeholderi 5

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

3.5.    Špecifikácia potrieb koncového používateľa. 6

3.6.    Riziká a závislosti 7

3.7.    Alternatívy a Multikriteriálna analýza. 7

3.7.1. Stanovenie alternatív pomocou biznisovej vrstvy architektúry. 7

3.7.2. Multikriteriálna analýza. 8

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

3.7.4. Stanovenie alternatív pomocou technologickej vrstvy architektúry. 9

1. POŽADOVANÉ VÝSTUPY (PRODUKT PROJEKTU). 10
2. NÁHĽAD ARCHITEKTÚRY. 10
3. LEGISLATÍVA.. 10
4. ROZPOČET A PRÍNOSY. 10
5. HARMONOGRAM JEDNOTLIVÝCH FÁZ PROJEKTU a METÓDA JEHO RIADENIA.. 13
6. PROJEKTOVÝ TÍM.. 15
7. PRACOVNÉ NÁPLNE. 15
8. ODKAZY. 16
9. PRÍLOHY. 16

1.     POPIS ZMIEN DOKUMENTU

1.1.          História zmien

Šedý text v celom dokumente predstavuje nápovedu pre vyplnenie dokumentu, po vyplnení kapitol odporúčame text šedou farbou vymazať.

Zelenou farbou je nápoveda pre prípravnú fázu projektu a modrou farbou pre iniciačnú fázu projektu, rovnako ako v prípade šedého textu odporúčame po vyplnení zmazať.

Pre prípravnú fázu, prosím ukladajte dokumenty s prefixom P_XX (podľa vyhlášky) a pre iniciačnú fázu s prefixom I_XX.

Finálna, schválená verzia dokumentácia z predošlej fázy musí byť na karte dokumentov v MetaIS uložená s koncovkou _FIN.

Poznámka: Odporúčame aby ste si VŠETKY TABUĽKOVÉ VSTUPY evidovali a spravovali v jednom centrálnom EXCELI – s cieľom minimalizovať budúcu prácnosť s aktualizáciou a udržiavaním obsahu.

Nápoveda inštrukcie k vypĺňaniu dokumentu PROJEKTOVÝ ZÁMER:

• Text uvedený „zelenou farbou“ vypĺňate v PRÍPRAVNEJ FÁZE projektu
  • j. ešte pred akýmkoľvek schvaľovaním a odsúhlasovaním vášho projektového zámeru vo vedení úradu (OVM) alebo u vašej autority, ktorá je zodpovedná za rozpočet
  • v tejto fáze ešte nečerpáte rozpočet.
• Text uvedený „modrou farbou“ vypĺňate v INICIAČNEJ FÁZE projektu
  • j. už po úvodnom odsúhlasení vedením organizácie pokračujete v zdetailizovaní vášho projektového zámeru
  • v tejto fáze začínate alokovať pracovníkov na špecializovaných útvaroch – z dôvodu dopĺňania úvodných vstupov.

VZORY a ŠABLONY zdrojových súborov sú tu: https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html

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

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• V súlade s Vyhláškou 85/2020 Z.z. o riadení projektov - je dokument Projektový zámer pre prípravnú fázu určený na rozpracovanie informácií k projektu, aby bolo možné rozhodnúť o pokračovaní prípravy projektu, alokovaní rozpočtu, ľudských zdrojov a prechode do iniciačnej fázy.

Doplniť vstupy v  INICIAČNEJ FÁZE:

• V súlade s Vyhláškou 85/2020 Z.z. o riadení projektov - je dokument Projektový zámer pre iniciačnú fázu určený na rozpracovanie detailných informácií prípravy projektu.

2.1.         Použité skratky (príklady)

2.1.1.      Konvencie – pravidlá názvoslovia, číslovania a verzionovania - požiadaviek (príklady)

2.1.2.      Použité skratky (príklady)

2.1.3.      Konvencie pre typy požiadaviek (príklady)

Hlavné kategórie požiadaviek v zmysle katalógu požiadaviek, rozdeľujeme 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:

Užívateľské požiadavky majú nasledovnú konvenciu:

U_nn_Rxx

• U – užívateľská požiadavka
• nn – typ používateľa
• R – označenie požiadavky
• xx – číslo požiadavky

Procesné požiadavky majú nasledovnú konvenciu:

P_ABXY_Rxx

• P – procesná požiadavka
• AB – označenie procesu
• XY – číslo podprocesu
• R – označenie požiadavky
• xx – číslo požiadavky

Reportingové požiadavky majú nasledovnú konvenciu:

R_nn_Rxx

• R – reportingová požiadavka
• nn – číslo reportu
• R – označenie požiadavky
• xx – číslo požiadavky

Kapacitné požiadavky majú nasledovnú konvenciu:

Bezpečnostné požiadavky majú nasledovnú konvenciu: ...

Prevádzkové požiadavky majú nasledovnú konvenciu: ...

Ostatné požiadavky majú nasledovnú konvenciu: ...

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

3.     DEFINOVANIE PROJEKTU

3.1.          Manažérske zhrnutie

Doplniť vstupy v PRÍPRAVNEJ FÁZE:

Stručný popis projektu, dôvod jeho realizácie, obsah projektu (vývoj SW, nákup HW/licencie, migrácia do vládneho cloudu a pod.), indikatívna výška finančných prostriedkov určených na realizáciu projektu, prínosy a časový horizont realizácie projektu. Očakáva sa, že stručne, jasne a štruktúrovane popíšete základné zdôvodnenie, prečo by sa mal projekt realizovať. Vo vašom popise odpovedajte najmä na otázky „Prečo chcete projekt zrealizovať? Čo je predmetom projektu? Pre koho sú výsledky projektu určené? Za akú sumu? Čo to prinesie cieľovej skupine?

V prípade projektov financovaných z európskych fondov je potrebné uviesť zdôvodnenie využitia národného/dopytového projektu, prijímateľa/partnera projektu a dôvod jeho určenia, príslušnosť národného/dopytového projektu k prioritnej osi príslušného operačného programu.

V prípade potreby doplniť informácie v INICIAČNEJ FÁZE.

3.2.          Motivácia a rozsah projektu

Doplniť vstupy v PRÍPRAVNEJ FÁZE:

• Popísať PROBLÉM, ktorý chcete realizáciou projektu odstrániť
• STRUČNE popísať koľko a aké vaše biznis procesy sú predmetom projektu
• doplniť informácie o OBLASTI (AGENDA / ŽIVOTNÁ SITUÁCIA), ktorým sa projekt venuje
• doplniť rámcový popis ROZSAHU projektu (subjekty a ISVS, ktorých sa problém a projekt týka)
• doplniť MOTIVÁCIU na dosiahnutie budúceho stavu a OBMEDZENIA pre dosiahnutie cieľov projektu.

V prípade potreby doplniť informácie v INICIAČNEJ FÁZE.

3.3.          Zainteresované strany/Stakeholderi

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• doplniť KTO (zoznam subjektov/osôb) sa zúčastňuje projektu a akú rolu zastáva

Doplniť vstupy v  INICIALIČNEJ FÁZE:

• do už vytvoreného dokumentu PROJEKTOVÝ ZÁMER z Prípravnej fázy aktualizovať a detailne rozpracovať – ak relevantné.

3.4.          Ciele projektu a merateľné ukazovatele

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• Do tabuľky nižšie doplniť CIEĽ /CIELE PROJEKTU a súvisiace merateľné ukazovatele. Ciele musia byť S.M.A.R.T. - konkrétne, merateľné, dosiahnuteľné, relevantné, časovo ohraničené
• Nie je správne uvádzať všeobecné ciele OPII alebo NKIVS, prípadne princípy NKIVS.

Ciele/Merateľné ukazovatele

Nápoveda (inštrukcie) k vyplneniu obsahu tabuľky:

• doplniť zmerané hodnoty stavu AS IS (pre oblasti, ktoré chceme realizáciou projektu zlepšiť)
• doplniť základné cieľové merateľné a výkonnostné hodnoty stavu TO BE
• ku každej hodnote doplniť spôsob, ako zmeriame dosiahnutie CIEĽA, výkonnostného ukazovateľa, atď.
• vzory merateľných ukazovateľov pre projekt sú publikované v Checkliste pre agendu Merateľné ukazovatele/KPI (https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html)

POŽIADAVKY: stručne popíšte, aké cieľové merateľné ukazovatele chcete dosiahnuť    

• ASIS merateľné ukazovatele – t. j. popíšte, aké merateľné ukazovatele máte teraz (vpíšte výsledky meraní – v časových/merateľných jednotkách) .
• TOBE merateľné ukazovatele – t. j. popíšte cieľové merateľné ukazovatele, ktoré chcete dosiahnuť.
  • Odporúčame, aby váš budúci IS už mal automatizovaný reporting (na pravidelnej báze, napr. týždenne) vami stanovených merateľných ukazovateľov – s cieľom, aby ste mohli riadiť službu, produkt, proces, ľudí
  • V prípade financovania cez EŠIF uvádzať aj Projektové merateľné ukazovatele z operačného programu (špecifické ciele, merateľné ukazovatele atď).

Doplniť vstupy v  INICIAČNEJ FÁZE:

• do už vytvoreného dokumentu PROJEKTOVÝ ZÁMER z Prípravnej fázy aktualizovať a detailnejšie rozpracovať, ak relevantné.

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

Táto časť sa týka SW 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, ďalej koncových používateľov. 

Špecifikácia požiadaviek koncových používateľov musí byť výsledkom používateľského prieskumu a v súlade s platnou legislatívou.  

Doplniť vstupy v  INICIAČNEJ FÁZE: 

• Definovať 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. (Vytvoriť prvú “iteráciu”  popisu cieľových skupín koncových používateľov, ktorá bude neskôr doplnená o poznatky z používateľského prieskumu. Príklad definície skupín koncových používateľov , tzv. persón nájdete napríklad v metodike pre tvorbu používateľsky kvalitných elektronických služiebalebo v tomto článku).   
• Potreby resp. ciele koncových používateľov (ideálne formou tzv.  používateľského príbehu) ktoré identifikujú to, čo jednotlivé skupiny koncových používateľov od elektronickej  služby požadujú (čiže  ako k naplneniu potreby pristupujú popísané formou príbehu).

•  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ť (performanceindiká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 PromoterScore, 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. (Ako vybrať vhodnú metódu používateľského prieskumu).

• 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ď.
• Doplnenie popisu skupín koncových používateľov o poznatky z používateľského prieskumu (overenie predpokladov charakteristík skupín koncových používateľov používateľským prieskumom a doplnenie týchto poznatkov do popisu skupín používateľov - vytvorenie persón, ktoré boli predtým “protopersónami”). 
• Doplniť Katalóg požiadaviek o priorizované požiadavky z používateľského prieskumu.

3.6.          Riziká a závislosti

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

Doplňte/stručne popíšte RIZIKÁ a ZÁVISLOSTI (detail v prílohe 1 P_01 a I_01_Príioha 1: 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 z EŠIF 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 majú 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.7.          Alternatívy a Multikriteriálna analýza

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• doplniť/stručne popísať možné alternatívy riešenia projektu.

Doplniť vstupy v  INICIAČNEJ FÁZE:

• doplniť/stručne popísať podkapitoly nižšie.

3.7.1.      Stanovenie alternatív pomocou biznisovej vrstvy 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 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.

3.7.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.

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

Príklad šablóny pre vyhodnotenie MCA

3.7.3.      Stanovenie alternatív pomocou aplikačnej vrstvy 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 CBA
• 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.

3.7.4.      Stanovenie alternatív pomocou technologickej vrstvy 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í vládneho cloudu.

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 vládny cloud a časť vlastný HW žiadateľa, resp. časť aplikácii využíva komerčný cloud), 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.

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 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 CBA,
• 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)

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• Doplniť informácie – POPIS PRODUKTU - čo bude/čo chcete, aby bolo po ukončení projektu dodané
  • doplniť informáciu k aktuálnemu stavu vašich biznis procesov, ktoré sú predmetom projektu
  • aktuálne (AS IS) procesy nie sú automatizované (bez podpory IS)
  • manuálne vypisujete viackrát tie isté dokumenty (vstupy do dokumentov)
  • manuálne si vytvárate pravidelné reporty z IS
  • požadujete úradné procesy zautomatizovať (+ napíšte, ktoré hlavné činnosti, chcete automatizovať).
• 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).

Doplniť vstupy v  INICIAČNEJ FÁZE:

• do už vytvoreného dokumentu PROJEKTOVÝ ZÁMER z Prípravnej fázy aktualizovať a detailne rozpracovať – ak relevantné.

5.     NÁHĽAD ARCHITEKTÚRY

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• doplniť 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.

Doplniť vstupy v  INICIAČNEJ FÁZE:

• stručný náhľad budúcej IT architektúry (biznis, aplikačná, technologická) riešenia (high-level architektonický model, pričom detailný pohľad na architektúru je predmetom dokumentu I_03 PRÍSTUP-k-PROJEKTU).
• Detailne spracované požiadavky (funkčné, nefunkčné, technické) vyplniť v dokumente I-02 BC/CBA, karta Katalóg požiadaviek.

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.

6.     LEGISLATÍVA

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• 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ť vstupy v  INICIAČNEJ FÁZE:

• 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

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• Všetky projekty nad 200 tis. € musia mať vypracovanú CBA. Projekty v rozpätí 200 tis. € až 999 999 € nemusia mať vypracovaný slepý rozpočet, prínosy vyplývajúce z procesných máp vrátane slovného popisu výpočtu a od zdrojovania vstupných hodnôt.
• Je potrebné vyčísliť a v tejto časti dokumentu popísať indikatívne náklady a prínosy projektu, v zmysle Vyhlášky 85/2020 (P-02 popísať na tomto mieste odôvodnenie projektu).

Doplniť vstupy v  INICIAČNEJ FÁZE:

• Počas iniciačnej fázy, je potrebné predložiť samostatný dokument (xls. BC/CBA) v predpísanej štruktúrovanej forme.

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)

Sumarizácia nákladov a prínosov

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 cez OP II 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 OP II vyjadruje 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 CBA, 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).

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

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

• doplniť 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).

Odporúčame:

• 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).

Doplniť vstupy v  INICIAČNEJ FÁZE:

• do už vytvoreného dokumentu PROJEKTOVÝ ZÁMER z Prípravnej fázy aktualizovať a detailne rozpracovať – ak relevantné.

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.

Doplniť vstupy v  INICIAČNEJ FÁZE:

• doplniť informácie o vybranej metóde riadenia projektu a zdôvodniť výber.

Ak realizujeme 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ú špecifikáciu - detailnú a technickú špecifikáciu - rámcovú.

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.

Objednávateľ projektu vypracuje funkčnú špecifikáciu - detailnú a technickú špecifikáciu - rámcovú.

9.     PROJEKTOVÝ TÍM

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

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)

Určuje sa Projektový manažér objednávateľa (PM)

Zostavuje sa Projektový tím objednávateľa

• kľúčový používateľ,
• IT analytik,
• IT architekt,
• manažér kvality,
• vlastník procesov
• vlastník údajov (nepovinný člen)
• manažér kybernetickej a informačnej bezpečnosti (nepovinný člen)
• iná špecifická rola (nepovinný člen)
• doplniť tabuľku zodpovedných osôb, ktoré budú participovať v projekte

10.   PRACOVNÉ NÁPLNE

Doplniť vstupy 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.

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 85/2020 Z.z.

11.   ODKAZY

Doplniť vstupy v  PRÍPRAVNEJ FÁZE:

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

12.   PRÍLOHY

Príloha 1: Zoznam rizík a závislostí (Excel): https://www.mirri.gov.sk/sekcie/informatizacia/riadenie-kvality-qa/riadenie-kvality-qa/index.html

• Rámcový - vytvára sa v prípravnej fáze
• Detailný - vytvára sa v iniciačnej fáze

Poznámka: Odporúčame, si evidovať a vyhodnotiť pripomienky odbornej verejnosti

• Podľa §7, odsek 4 – Vyhlášky 85/2020 Z.z – 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 85/2020 Zz.

Koniec dokumentu