Slovensko.Digital zaslalo 14.8.2026 tieto pripomienky k projektu:
REFORMA VS
Zoznam zainteresovaných strán (Stakeholderov) nie je úplný.
V tabuľke zainteresovaných strán chýbajú niektoré skupiny, s ktorými projekt ďalej pracuje.
Do projektovej dokumentácie je potrebné doplniť jednoznačné definovanie :
- všetkých konkrétnych subjektov,
- súvisiacich informačných systémov a
- rolí stakeholderov
- spôsobu zapojenia stakeholderov do prípravy a realizácie projektu
a doplniť minimálne týchto stakeholderov s jednoznačným definovaním konkrétnych subjektov:
- súdy,
- redakcia Slov-Lex,
- odborná verejnosť,
- používateľia dát a
- používateľia API.
Výsledky používateľských prieskumov sa nedajú overiť.
Výsledky prieskumov sú uvedené len v percentách bez uvedenia počtu respondentov, termínov zberu, znenia otázok ani zloženia vzorky.
Do projektovej dokumentácie je potrebné doplniť metodiku, vzory dotazníkov a anonymizované výsledky zisťovaní v členení podľa skupín používateľov, počet respondentov, termíny zberu, znenie otázok a zloženie vzorky respondentov.
Chýba vyhodnotenie skúseností s existujúcim legislatívnym editorom.
Je uvedené iba to, že existujúci legislatívny editor bol pre používateľov príliš komplikovaný a v praxi sa neosvedčil.
Do projektovej dokumentácie je potrebné doplniť vecné vyhodnotenie doterajšieho riešenia legislatívneho editora, t.j. aká bola jeho cenal, ako sa používal, čo presne používateľom prekážalo a ktoré jeho časti sa dajú znovu použiť a porovnanie pôvodného legslatívneho editora s požadovanými úpravami/zmenami pre vývoj nového legislatívneho editora.
Nie je jasný rozsah spracovania historických dokumentov.
V projekte je na jednej strane vylučená plošná migrácia historických údajov, na druhej strane sa počíta so spracovaním existujúcich príloh, VZN a ďalších dokumentov. Pri prílohách sa spomína 13 876 PDF súborov so 127 404 stranami, ale nie je zrejmé, aká časť z nich je v rozpočte.
Do projektovej dokumentácie je potrebné doplniť pri každom module počet a typ historických dokumentov, ktoré sa v rámci projektu majú spracovať, spôsob ich výberu, očakávanú úspešnosť a rozsah ručnej kontroly. Spracovanie historických dokumentov v definovanom rozsahu je potrebné definovať aj v rozpočte a harmonograme realizácie.
Chýba konkrétny plán zavedenia riešenia do praxe.
Projekt počíta s používaním nových modulov samosprávami, ministerstvami a ďalšími úradmi. Pri niektorých skupinách sa však ich zapojenie plánuje až počas testovania a časť používania závisí od budúcich legislatívnych zmien.
Do projektovej dokumentácie je potrebné doplniť pilotnú prevádzku, výber pilotných organizácií, zapojenie budúcich používateľov už do prípravy analýzy, spôsobu prechodu zo súčasných postupov a plán školení a podpory. Potrebné je aj doplniť náhradný postup realizácie pre prípad, že legislatívne zmeny nebudú prijaté načas.
MERATEĽNÉ CIELE
Percentuálne KPI nemajú východiskové hodnoty.
Pri KPI K2 až K5, K7 až K10 a K13 je hodnota AS IS uvedená ako „N/A“, hoci cieľ je vyjadrený percentom alebo percentuálnym znížením. Napríklad zníženie chybovosti o 20 % sa bez dnešného počtu chýb nedá vyhodnotiť.
Do projektovej dokumentácie je potrebné doplniť východiskové hodnoty, obdobie a zdroj merania, presný spôsob výpočtu a termín dosiahnutia každého cieľa.
KPI nepreukazujú finančné prínosy projektu, na ktorých stojí CBA.
Takmer celý vyčíslený prínos projektu tvorí úspora času úradníkov.
Do projektovej dokumentácie je potrebné doplniť pre KPI prukazujúce úspory, t.j. minimálne počet spracovaní, čas procesu pred a po zavedení riešenia a skutočne ušetrené hodiny alebo FTE. Tieto ukazovatele je potrebné doplniť pre všetky procesy, ktoré vstupujú do CBA, a priamo ich prepojiť s výpočtom prínosov.
Chýbajú ukazovatele kvality a reálneho používania riešenia.
Počet nasadených modulov alebo API endpointov ešte nehovorí, či riešenie funguje dobre.
Do projektovej dokumentácie je potrebné doplniť KPI pre:
- úspešnosť importu a exportu dokumentov Word,
- presnosť OCR a extrakcie metadát,
- počtu ručných opráv,
- chybovosť výstupov,
- čas hlavných operácií,
- spokojnosť používateľov a
- používanie jednotlivých modulov.
Nesedia názvy a počet plánovaných výstupov.
Cieľ C1 uvádza päť doménových modulov a spoločnú Platformu editora, zatiaľ čo cieľová hodnota KPI K1 je päť modulov. CBA navyše samostatne rozpočtuje rozšírenie Redakčného editora.
V projektovej dokumentácii je potrebné zosúladiť počty a pomenovania výstupov v častiach ciele, KPI, rozpočet a akceptačné míľniky.
BIZNIS PRÍNOS
Nie je jasné, aká bude dostupnosť pre jednotlivé služby.
V projektovej dokumentácii sú pre produkčné prostredie uvedené prevádzkové hodiny v pracovné dni od 6:00 do 18:00 a dostupnosť 98,5 %. Nie je jasné, či sa tieto parametre vzťahujú aj na verejné API a publikačné služby, ktoré môžu byť potrebné aj mimo pracovného času.
Do projektovej dokumentácie je potrebné doplniť požiadavky na rozdelenie SLA podľa typu služby na dostupnosť, podporu a obnovovacie časy pre verejné rozhrania, editory, integrácie a dávkové spracovanie aj mimo pracovného času.
PRÍSPEVOK K INFORMATIZÁCII
Automatické spracovanie dokumentov nemá určenú požadovanú presnosť.
Projekt počíta s OCR, fragmentáciou, extrakciou metadát, tvorbou väzieb a porovnávaním dokumentov. Nie je však určené, aká chybovosť je ešte prijateľná a koľko výsledkov bude treba ručne opravovať.
Do projektovej dokumentácie je potrebné doplniť požiadavky, pre jednotlivé typy dokumentov, na minimálnu presnosť, spôsob merania a rozsah ľudskej kontroly. Pre akceptačné testy je potrebné požadovať použítie reprezentatívnej vzorky reálnych dokumentov, ktorá nebola použitá pri vývoji.
Vendor Lock-in a autorské práva
Závislosť od proprietárneho jadra nie je dostatočne vyhodnotená. Riešenie má využívať existujúce komponenty, privátny Oracle cloud a licenciu „Metalex alebo podobné“ za 1 906 500 eur. Všeobecná požiadavka na odovzdanie zdrojových kódov sama osebe nerieši závislosť od týchto komponentov.
Do projektovej dokumentácie je potrebné doplniť, ktoré časti budú proprietárne, aké práva získa štát, koľko bude stáť ďalšia podpora a obnova licencií a či bude vedieť prevádzku a rozvoj prevziať iný dodávateľ.
Zdrojový kód/ OpenSource
Pri zdrojových kódoch nie je určená otvorená licencia, ktorá umožní ich ďalšie použitie a rozvoj.
Do projektovej dokumentácie je potrebné doplniť požiadavku, aby bol zákazkovo vyvinutý kód spolu s build a deployment skriptmi priebežne odovzdávaný do centrálneho repozitára verejnej správy a sprístupnený bez obmedzení s licenciou EUPL. Výnimky pre komponenty tretích strán je potrebné konkrétne pomenovať a odôvodniť.
OpenAPI
Katalóg pri OpenAPI určuje REST a metódu GET, bez definovania konkrétnych údajov, ktorých základný rozsah má byť známy už v Prípravnej fáze projektu.
Do projektovej dokumentácie je potrebné doplniť definíciu datasetov, metadát a číselníkov, ktoré budú sprístupnené, podmienky ich používania, autentifikáciu, limity a verzovanie strojovo čitateľnej OpenAPI.
Open API
Do projektovej dokumentácie je potrebné doplniť požiadavku, že všetky služby poskytované cez GUI musia byť dostupné aj ako verejné OpenAPI rozhranie pre tretie strany (v rozsahu používateľskej funkcionality poskytovanej cez GUI).
Riadenie/migrácia údajov
Chýba úplný export údajov a exit plán. Katalóg obsahuje čiastkové požiadavky na XML import a export, nie však export celého riešenia.
Do projektovej dokumentácie je potrebné doplniť požiadavku na export všetkých dokumentov, fragmentov, metadát, väzieb, číselníkov, konfigurácie a potrebných auditných záznamov v otvorených a zdokumentovaných formátoch. Export musí byť použiteľný bez súčinnosti pôvodného dodávateľa a jeho použiteľnosť treba overiť akceptačným testom.
Dokumentácia
Projektový zámer uvádza viac požadovaných druhov dokumentácie, kým pri jednotlivých moduloch katalóg často spomína iba prevádzkovú dokumentáciu a používateľskú príručku.
V projektovej dokumentácii je potrebné zosúladiť a jednoznačne uviesť, aká dokumentácia sa odovzdáva pri každom míľniku. Úplnosť a aktuálnosť dokumentácie by mala byť súčasťou akceptácie.
Testovanie
Testovanie je opísané iba všeobecne. Dokumentácia uvádza druhy testov, ale konkrétne kritériá úspechu necháva na neskôr.
Do projektovej dokumentácie je potrebné doplniť definíciu minimálneho rozsahu funkčných, integračných, používateľských, záťažových, bezpečnostných, obnovovacích a migračných testov. Je potrebné tiež definovať reprezentatívne testovacie dáta, prípustný počet chýb a podmienky, za ktorých bude možné výstup akceptovať a fakturovať.
Testovanie
Do projektovej dokumentácie je potrebné doplniť požiadavku na vykonanie testov, ktoré preukazujú že sa skrátil čas pre procesy a činnosti stakeholderov.
Testovanie
Do projektovej dokumentácie je potrebné doplniť jednoznačnú požiadavku na vykonanie testov pre úplnú obnovu IS a čas potrebný na obnovu IS po fatálnom incidente, t.j. úplná obnova HW nastavení, inštalácie programov a nastavení z inštalačných médii, obnovy dát z backupov, obnova sieťových nastavení a integrácií a spustenie IS do produkčnej prevádzky.
KALKULÁCIA EFEKTÍVNOSTI
Vo výpočte riadenia a publicity je chyba.
Vo výpočte riadenia a publicity je neplatný odkaz. Vo vzorcoch pre projektové riadenie a publicitu sa opakuje neplatný odkaz #REF!. Odkaz je vo funkcii IFERROR, a preto sa príslušná časť výpočtu započíta ako nula. Zo zošita nie je zrejmé, či ide o zámerne nulovú položku alebo o chýbajúci náklad.
V projektovej dokumentácii je potrebné opraviť odkaz, prípadne ho nahradiť explicitnou nulou a potvrdiť, že oprava nemení celkové náklady ani výsledky CBA.
Ekonomické prínosy projektu sú nejednoznačné.
Ekonomické výsledky v Projektovom zámere a CBA sa líšia. Projektový zámer uvádza úsporu približne 9,7 milióna eur ročne a návratnosť v roku t5. V CBA je ustálený ročný prínos približne 5,286 milióna eur a kumulovaná ENPV sa dostane do plusu až v roku t6. Projektový zámer zároveň uvádza rozpočet 16 907 662 eur, kým desaťročné náklady v CBA sú 19 450 789,97 eur.
V projektovej dokumentácii je potrebné zosúladiť a jednoznačne uviesť a jasne oddeliť investičný rozpočet od celkových nákladov vlastníctva.
Podklady k výpočtu úspory času nie sú zverejnené.
Dokumentácia hovorí o empirických meraniach porovnateľných procesov, ale nie je uvedené, kde, kedy a na akej vzorke sa meralo. Nedá sa preto overiť, či sú časy AS IS a TO BE použiteľné pre Slov-Lex.
V projektovej dokumentácii je potrebné zverejniť podklady ku každému použitému objemu a času, výpočet FTE a predpokladaný nábeh používania. Súhrnný hárok CBA dnes pri FTE úradníkov uvádza iba „N/A“, hoci práve ich čas tvorí hlavný prínos projektu.
Odhad rozsahu a ceny vývoja nie je dostatočne doložený.
Rozpočet počíta približne s 19 337 externými človekodňami a externými nákladmi na vývoj približne 10,38 milióna eur. V podkladoch však nie je prieskum trhu ani porovnateľné zmluvy, z ktorých vychádza rozsah prác a použité sadzby.
V projektovej dokumentácii je potrebné zverejniť zdroje cien a vysvetliť metodiku odhadu človekodní pre jednotlivé moduly. V hárku EXTERNE_POZICIE treba tiež vysvetliť položky označené kontrolou „NAD“.
Cena a podmienky licencie sú neznáme.
Nie je doložená cena ani rozsah licencie za 1 906 500 eur. Pri položke „Metalex Licencie – alebo podobné“ je ako zdroj ceny uvedené iba „PHZ“. Nie je zrejmé, čo licencia zahŕňa, na aké obdobie a koľko používateľov alebo prostredí platí ani aké budú ďalšie poplatky.
V projektovej dokumentácii je potrebné zverejniť podklad k cene, licenčné podmienky a celkové licenčné náklady počas obdobia CBA. Zároveň treba ukázať porovnanie s inými možnosťami.
ALTERNATÍVY
Alternatívy nie sú porovnané z pohľadu nákladov a prínosov.
Alternatívy 0, 1 a 2 sú porovnané najmä kvalitatívne. Kritériá pritom do veľkej miery kopírujú požadované výstupy, takže plná alternatíva prirodzene vychádza najlepšie.
Do projektovej dokumentácie je potrebné doplniť, porovnanie a vyhodnotenie pre jednotlivé alternatívy rozsah, harmonogram, náklady, prínosy a riziká. Osobitne treba ekonomicky porovnať postupné dodávanie modulov s dodaním modulom v jednom veľkom projekte.
Posúdenie open source je príliš všeobecné.
V projektovej dokumentácii je vysvetlené, prečo nie je vhodné riešenie postavené výhradne na open source, ale neuvádza konkrétne posudzované produkty alebo komponenty. To však nevylučuje zákazkový vývoj s otvoreným zdrojovým kódom ani použitie otvorených komponentov v časti riešenia.
V projektovej dokumentácii je potrebné uviesť, ktoré možnosti boli reálne posudzované, v čom nevyhoveli a aký by bol rozdiel v nákladoch a závislosti od dodávateľa.
Chýba nákladové porovnanie Oracle cloudu s eSKa cloudom.
Umiestnenie nových modulov do privátneho Oracle cloudu sa odôvodňuje najmä tým, že v ňom už Slov-Lex beží a nebolo by vhodné udržiavať ďalšie prostredie. Podľa toho istého dokumentu však majú byť štyri nové editory oddelené od existujúcich agendových systémov, umiestnené na samostatnom serveri a v samostatnej podsieti. Samostatnú infraštruktúrnu časť pre nové moduly teda bude potrebné vytvoriť aj v Oracle cloude. Argument, že mimo Oracle cloudu by vzniklo ďalšie prostredie, preto nie je presvedčivý a samotné umiestnenie dnešného Slov-Lexu nepreukazuje, že Oracle je pre rozšírenie najvýhodnejším riešením. MIRRI navyše 31. júla 2026 uzavrelo so spoločnosťou VNET zmluvu č. 1141/2026 na poskytovanie cloudových služieb a zmluvu č. 1082/2026 na priestory dátového centra pre projekt eSKa Cloud. Ide o priamo relevantnú alternatívu, ktorú dokumentácia pri posudzovaní vládneho cloudu nezohľadňuje.
V projektovej dokumentácii je potrebné, pre všetkých päť pripravovaných modulov, rovnaký rozsah výpočtových zdrojov a prostredí TEST, ŠKOL a PROD, vyčísliť náklady prevádzky v Oracle cloude a v eSKa cloude. Porovnanie má zahŕňať najmä výpočtové zdroje, úložisko, databázové a ďalšie licencie, zálohovanie, sieťové a bezpečnostné služby, monitoring, podporu, SLA, integrácie a náklady na ukončenie alebo presun služby. Pri eSKa cloude treba vychádzať zo zazmluvnených cien a cloudových kreditov a zohľadniť už obstaranú kapacitu; fixné náklady centrálneho projektu nemožno druhýkrát pripočítať Slov-Lexu. Pri Oracle cloude treba rovnako uviesť skutočné dodatočné náklady, ktoré vyvolá tento projekt. Výsledok je potrebné premietnuť do CBA a podľa neho odôvodniť výber prevádzkového prostredia.
RIZIKÁ A ZÁVISLOSTI
Register rizík nie je dokončený.
Pri všetkých jedenástich rizikách je v termíne iba slovo „dátum“ a odhad škody je 0 eur. Chýbajú aj viaceré podstatné riziká: licenčná závislosť, kvalita importu z Wordu, úspešnosť OCR, anonymizácia rozhodnutí, prijatie riešenia používateľmi a nesplnenie predpokladaných úspor.
V projektovej dokumentácii je potrebné dopracovať register rizík, určiť konkrétnych vlastníkov a termíny a pri významných rizikách uviesť aj náhradný postup.
Kľúčové legislatívne závislosti sa odkladajú až do realizačnej fázy.
Používanie viacerých modulov závisí od budúcich pravidiel pre VZN, rezortné predpisy, prílohy, súdne rozhodnutia a Open API. Pri pravidlách pre prílohy sa dokonca uvádza, že si ich dodávateľ zadefinuje sám v spolupráci so zákazníkom. Vecné pravidlá by však mal schváliť príslušný gestor ešte pred vývojom funkcionality, ktorá je na nich závislá.
V projektovej dokumentácii je potrebné doplniť gestora, harmonogram a rozhodovacie mílniky pre každú potrebnú legislatívnu alebo metodickú zmenu.
Dokumenty
Aktivity