Vybudovanie centrálneho komponentu v zmysle NKIVS, referenčnej architektúry eGovernmentu, ktorého cieľom je publikovanie API pre subjekty verejnej správy a aj pre subjekty mimo verejnej správy, t.j. pre súkromný sektor vo forme otvorených API (OpenAPI).
7,5M Eur (investície) + 5,6M Eur (prevádzka 10 rokov) s DPH
Úrad podpredsedu vlády SR pre investície a informatizáciu
Štúdia uskutočniteľnosti je v určitých častiach pomerne dobre a detailne rozpracovaná. Tento fakt súvisí s tým, že predmetom je technologický komponent. Problémy vidím v určitých oblastiach ako sú alternatívy a stanovenie nákladov. Z hľadiska biznis požiadaviek je možné sa s väčšinou požiadaviek stotožniť, otázne sú špecifikácie modulu monetizácie, využitia výsledkov projektu vo forme PaaS a prioritizácie publikovania pilotných služieb/API. Ako dôležitý míľnik vnímame akceptáciu a overenie aktuálne vznikajúceho riešenia MUK-P, ktorého pokračovaním je projekt opísaný v štúdii uskutočniteľnosti. Pred akceptáciou by mala byť zhodnotená biznis stránka projektu (biznis a funkčné požiadavky), náklady a zvolené technológie (štandardnosť riešenia, použité technológie, kvalita zdrojového kódu a dokumentácie, možnosť substitúcie) MUK-P.
So zameraním navrhovaného projektu súhlasíme, ide o vybudovanie centrálneho riešenia/bloku eGovernmentu pre OpenAPI, čo je koncept za ktorého realizáciu sa aj Slovensko.Digital dlhodobo zasadzuje. Pri viacerých okruhoch biznis požiadaviek projektu vidíme potrebu detailnejšieho a konštruktívnejšieho dialógu v rámci relevantných pracovných skupín. Odporúčame štúdiu uskutočniteľnosti schváliť s podmienkou overenia vhodnosti MUK-P a budovania ďalších častí projektu nad týmto riešením.
27.06.2024
Príprava projektu
Reforma VS
Merateľné ciele (KPI)
Postup dosiahnutia cieľov
Biznis prínos
Príspevok v informatizácii
Štúdia uskutočniteľnosti
Alternatívy
Kalkulácia efektívnosti
Participácia na príprave projektu
Reformný zámer existuje a schválený.
Vhodné by bolo, aby jasne popisoval procesy dátovej kancelárie na UPVII, ktorá by mala vystupovať ako biznis owner Centrálnej API manažment platformy. Integračná kancelária by mala pôsobiť ako koordinátor publikovania API, mala by realizovať prieskumy požadovaných API, realizovať ich prioritizáciu a pod. Bez týchto aktivít sa ťažko dosiahnú želané a potenciálne úspechy, ktoré otváranie API so sebou prináša.
Reformný zámer definuje aktivity a teda aj KPI pre širšiu skupinu aktivít a projektov ÚPVII. Ako rizikové vnímame naplnenie relevantných ukazovateľov spojených s týmto projektom v roku 2020.
Harmonogram implementácie by mohol byť detailnejší a viac zameraný na fázu implementácie projektu, miľníkov a pod.
Kľúčový krok predstavuje dodanie a otestovanie pilotného riešenia (MUK-P) a vyhodnotenie, či spĺňa definované požiadavky a je vhodné nad ním budovať ďalšiu funkcionalitu plánovaného projektu.
Harmonogram implementácie by mal rešpektovať iteratívnejší prístup, t.j. plánovanie projektu a jeho výstupov by malo byť zamerané na dodávanie vertikálnych rezov potrebnej funkcionality v čase.
Harmonogram by mal jasne identifikovať dodanie “must have” funkcionality a následne “nice to have” funkcionality. “Nice to have” funkcionalitu má význam dodávať až po reálnom používaní “must have” funkcionalít, aby požiadavky na rozširovanie vyplývali z reálneho používania a reálnych potrieb.
hodnotenie
Projekt plní záväzok a ciel z NKIVS.
Projekt predstavuje centrálny komponent referenčnej architektúry eGovernmentu.
Z pohľadu biznis prínosov, biznis požiadaviek kriticky vnímame moduly:
Oceňujeme plán a ambíciu publikovania pilotných agendových služieb/API do vytvoreného riešenia. Dôležité je, aby boli publikované služby s pridanou hodnotou a potenciálom na vysokú adopciu, ich využitie spolu s inými službami do komplexnejších služieb. Preto navrhujeme, aby bol zo strany UPVII vedený dialóg a prioritizácia služieb pre pilotné publikovanie. Publikovanie služieb/API systému ITMS2014+ nepovažujeme úplne za vhodné, skôr odporúčame publikovanie vhodných služieb/API UPVS.
Publikovanie pilotných služieb vnímame ako možnosť demonštrácie procesu, postupu, nákladov pre ďalšie OVM, ktoré budú povinné služby/API svojich agendových IS publikovať do Centrálnej API manažment platformy. Referenčné náklady môžu slúžiť ako vstupy do pripravovaných dopytových výziev pre OVM.
Projekt predstavuje centrálny komponent referenčnej architektúry eGovernmentu v SR.
Projekt napomáha k:
Štúdia je spracovaná v zmysle pokynov, postupov a definovaného formuláru.
Oceňujeme rozdelenie štúdie na logické celky/moduly navrhovaného projektu, pokus o definovanie “must have” a “nice to have” funkcionality jednotlivých modulov, posúdenie možností implementácie jednotlivých modulov (existujúce riešenie/produkt vs. custom vývoj), atď.
Oceňujeme snahu o komparáciu existujúcich riešení/produktov dostupných na trhu a riešenia MUK-P medzi sebou na základe definovaných požiadaviek. Na druhú stranu sme názoru, že určité vyhodnotenia nie sú korektné a zároveň MUK-P je možné voči daným požiadavkám hodnotiť len na papierovej úrovni, nakoľko dané riešenie sa ešte len implementuje.
V štúdii chýba detailnejší popis MUK-P ako riešenia, nad ktorým sa má budovať projekt. MUK-P predstavuje riešenie, ktoré ešte len vzniká. Štúdia obsahuje minimum informácií o danom riešení. Štúdia by mala jasne popísať:
Tieto informácie by prispeli k lepšiemu rozhodovaniu a posúdeniu vhodnosti MUK-P.
Alternatívy pokrývajú základné koncepty prístupu k realizácii a implementácii projektu:
Sme názoru, že kvôli objektívnosti a správnemu rozhodnutiu by napomohlo, keby alternatíva B (budovanie nad existujúcim riešením) mala 2 podalternatívy, t.j.:
Sme názoru, že porovnanie týchto 2 podalternatív je logické a žiadané, aby sa jasne určil interval nákladov, rizík vo vzťahu k použitým technológiám a pod.
Alternatívu D vzhľadom na možnosti použitia EÚ finančných prostriedkov považujeme za irelevantnú. Zároveň nie je možné očakávať, že služba dostupná ako SaaS pokryje kompletne všetky požiadavky, nakoľko je jasné, že niektoré požiadavky sú špecifické a je potrebný aj custom vývoj.
Oceňujeme snahu v kapitole 2.4.2.3 Mapovanie funkčných požiadaviek s špecifických požiadaviek na existujúce riešenia posúdiť/otestovať vhodnosť existujúcich riešení ako Kong, Tyk, apigee voči požiadavkám. Ale sme názoru, že určité požiadavky neboli vyhodnotené korektne a že nesplnenie niektorých požiadaviek by malo mať dopad na vylúčenie konkrétneho riešenia (niektoré požiadavky vnímame ako nie veľmi dôležité). Zároveň sme názoru, že nakoľko MUK-P ešte len vzniká, tak je ťažko zhodnotiť, či by tiež splnil všetky definované požiadavky.
V štúdii chýba detailnejší popis MUK-P ako riešenia, nad ktorým sa má budovať projekt. MUK-P predstavuje riešenie, ktoré ešte len vzniká. Štúdia obsahuje minimum informácií o danom riešení. Štúdia by mala jasne popísať:
Je potrebné zdôrazniť, že projekt/aktivity vyplývajúce zo štúdie budú predmetom verejnej súťaže a teda je potrebné zabezpečiť, aby MUK-P bol vysoko štandardný produkt/riešenie, aby jeho prevzatie víťazom verejného obstrávania mohlo byť bezproblémové alebo ak sa bude poskytovať vo forme licencie, tak nech cena za takúto licenciu je obdobná komerčným produktom s obdobným rozsahom funkcionality a nech prípadná substitúcia tohto produktu/riešenia je čo najjednoduchšie realizovateľná.
Rok návratnosti projektu považujeme za nie reálny. Vo vzťahu k stavu ostatných plánovaných agendových IS VS, k architektonickým princípom použitých v rámci existujúcich IS VS, k plánu financovania vytvorenia chýbajúcich služieb/API a ich publikovania cez dopytové výzvy vidíme riziko, že nebudú naplnené prínosy v tak krátkom čase. V rámci aktuálnej dopytovej výzvy na Malé zlepšenia eGov nie je predložená ani jedna ŽoNFP.
Vybratá alternatíva počíta s použitím MUK-P a teda budovania projektu nad týmto riešením. Sme názoru, že pre správne zhodnotenie z ekonomického pohľadu by mali byť výdavky na MUK-P zahrnuté do TCO projektu. Riešenie MUK-P je financované zo štátneho rozpočtu. Ide o relevantný náklad, ktorý by mal byť započítaný do TCO. Keby sa zvolila alternatíva, že sa projekt ide budovať nad existujúcim riešením dostupným na trhu, napr. Kong, Tyk, apigee, tak licenčný poplatok za takýto produkt by vstupoval do TCO projektu. Teda analogicky sme názoru, že náklady na MUK-P by mali byť zahrnuté do TCO projektu.
Zo štúdie uskutočniteľnosti a ani z CBA nie je úplne jasný postup a spôsob určenia pracnosti/počtu človekodní na jednotlivé moduly. Zverejenenie spôsobu a určenia pracnosti jednotlivých modulov by bolo prospešné pre konštruktívnejší dialóg.
Aktuálny počet pre niektoré moduly predstavuje pomerne vysokú pracnosť:
Sme názoru, že v rámci vyššie uvedených modulov a aktivít sú ocenené aj nie potrebné požiadavky. Odporúčame pred vyhlásením VO viesť odbornú diskusiu (napr. prípravné trhové konzultácie) k jednotlivým modulom a tak zefektívniť potrebnú funkcionalitu a jej potrebnú pracnosť. Zároveň odporúčame viesť diskusiu v rámci pracovných skupín k témam ako monetizácia, PaaS, publikovanie API.
CBA v rámci položky prevádzka počíta s finančnými zdrojmi na zmeny, ktoré vyplynú z legislatívnych zmien a požiadaviek na základe reálnej implementácie. Odporúčame tieto finančné prostriedky rozpočtovať a sledovať samostatne.
Veľmi pozitívne oceňujeme, že riešiteľ štúdie poskytol a viedol interaktívny dialóg s tretími stranami.
Nedostatok vidíme, že do dialógu neboli intenzívnejšie a v dostatočnom časovom predstihu zapojené subjekty/útvary, na ktoré má plánovaný projekt priamy dopad:
Diskusie k projektu na platforme:
V tomto projekte už prebehli nasledovné dôležité aktivity / míľniky: