Red Flags: Zvyšovanie úžitkovej hodnoty digitálnych služieb pre občanov, podnikateľov a inštitúcie verejnej správy

Názov: Zvyšovanie úžitkovej hodnoty digitálnych služieb pre občanov, podnikateľov a inštitúcie verejnej správy

Garant: Národná agentúra pre sieťové
a elektronické služby

Stručný opis: Rozvoj ústredného portálu slovensko.sk a spoločných modulov o časti zo strategických priorít (portfólio klienta, responzívny dizajn, udelovanie oprávnení tretím stranám (Open API), štátny chat/messanger)

Náklady na projekt: 18 711 280 EUR s DPH

Aktuálny stav projektu: Príprava projektu

Čo sa práve deje:

  • Prebieha podávanie žiadostí o NFP
  • 21.9.2018 Dátum uzavretia výzvy

Zhrnutie hodnotenia Red Flags: Projekt je v súlade so schválenými prioritami informatizácie a jeho kľúčové časti sú kritické pre posun informatizácie. Projekt obsahuje niekoľko nesúvisiach častí/modulov, ktoré by bolo vhodné posudzovať úplne samostatne, kedže majú iné biznis prínosy, merateľné ukazovatele či alternatívy. Uvedené alternatívy preto považujeme za fiktívne, nevhodné pričom pre jednotlivé časti projektu chýbajú zrejmé alternatívy. Zásadným nedostatkom sú tiež merateľné ukazovatele, ktoré nepokrývajú alebo nedokážu merať úspech jednotlivých častí projektu vzhľadom na ciele projektu. Nákladové položky na vývoj softvéru sú neoveriteľné, bez uvedenia zdroja alebo metodiky a naopak prínosy považujeme za nadhodnotené či v niektorých prípadoch úplne neexistujúce.

Stanovisko Slovensko.Digital: Odporúčame pre jednotlivé časti projektu samostatne uviesť vhodné merateľné ukazovatele a skutočné alternatívy. Tiež žiadame uviesť uveriteľný a overiteľný spôsob výpočtu nákladov na vývoj jednotlivých častí projektu.

:triangular_flag_on_post: HODNOTENIE RED FLAGS

I. Prípravná fáza


Reforma VS :star::grey_star::grey_star::grey_star:

Popísaná reforma je skôr pokračovaním rozvoja ústredného portálu verejnej správy www.slovensko.sk, ktorý má zabezpečiť jeho kvalitatívne zlepšenie z pohľadu občana. Z veľkej časti nejde o žiadnu optimalizáciu procesov, hlavným novým prvkom je vytvorenie portfólia klienta, ktorý je v súlade so schválenými strategickými prioritami štátu.


Merateľné ciele (KPI) :star::grey_star::grey_star::grey_star:

Merateľné ukazovatele považujeme za nedostatočné. Projekt má niekoľko úplne nezávislých častí, pričom niektoré z nich nie sú vôbec pokryté releventnými merateľnými ukazovateľmi. Niektoré merateľné ukazovatele nijako nehovoria o dosahovaní cieľov (napr. podiel spracovanej spätnej väzby) či môžu byť dokonca kontraproduktívne (napr. zvyšovanie priemerého počtu zobrazení stránok za deň). Odporúčame výrazne rozšíriť a zlepšiť merateľné ukazovatele pre každú samostatnú časť projektu zvlášť.


Postup dosiahnutia cieľov :star::star::star::grey_star:

Z uvedeného plánu je zrejmé, že ide o klasický vodopádový model, čo pri častiach projektu, kde bude nutné prototypovanie a kontinuálne testovanie s používateľmi považujeme za nevhodné.


Súlad s KRIS (nie je zatiaľ vyhodnotený)


Biznis prínos :star::star::grey_star::grey_star:

Biznis prínosy niektorých častí projektu sú veľmi otázne (napr. nový editor formulárov alebo správa webového obsahu) alebo veľmi riskantné (napr. chatbot).


Príspevok v informatizácii :star::star::star::star:

Projekt ide rámcovo v súlade so schválenými strategickými prioritami štátu. Za časti, ktoré môžu najzásadnejšie prispieť k informatizácii považujeme časť Open API, optimalizáciu navigácie a obsahu pre životné situácie a responzívny dizajn.


Štúdia uskutočniteľnosti :star::star::star::grey_star:

Štúdia uskutočniteľnosti obsahom smeruje k vytýčeným cieľom a pre väčšinu častí projektu sú zrejmé dôvody na ich implementáciu. Z praxe je zrejmé, že plánované UX testovanie a prototypovanie potrebné pre niektoré časti projektu má zásadný vplyv na ďalší vývoj a rozsah prác, preto nákladové v indikatívnom rozpočte považujeme za neoveriteľné čísla. Nie je zrejmé akou metodikou boli určené a ako je vôbec možné odhadnúť náklady na vývoj softvéru bez informácie o tom, akú funkcionalitu má poskytovať koncovým používateľom.


Alternatívy :star::grey_star::grey_star::grey_star:

Zvolené alternatívy v štúdii uskutočniteľnosti pôsobia umelo, kedže vybraná alternatíva bola zrejmá zo schválených strategických dokumentov. Naopak štúdia nedáva odpoveď na otázky, kde by bolo možné využiť nákup softvéru ako služba (napr. chat) a absentujú skutočné alternatívy (napr. pri novom editore formulárov). Alternatívy je potrebné uvažovať nie pre celý projekt, ale pre jednotlivé nesúvisiace časti oddelene.


Kalkulácia efektívnosti :star::grey_star::grey_star::grey_star:

Prínosy projektu sú z nášho pohľadu značne nadhodnotené a predpoklady nepôsobia uveriteľne. Pri niektorých použitých konštantách (napr. interakcie vedúce k podaniu, skrátenie času) sú nedohladateľné zdroje. Niektoré uvedené úspory (napr. úspora na mzde počas času čakania úradníka) považujeme za fiktívne. Taktiež nákladové položky na vývoj potrebného softvéru vôbec nemajú uvedené zdroje ani metodiku, ktorou k nim bolo možné dospieť. Vzhľadom na to, že niektoré časti nemajú vôbec jasnú špecifikáciu a majú až experimentálny charakter, považujeme tieto odhady v tejto fáze takmer neurčiteľné.


Participácia na príprave projektu :star::star::grey_star::grey_star:

K zapojeniu sa do prípravy projektu nemožno mať veľké výhrady, prebehlo verejné pripomienkovanie, boli zverejňované pracovné verzie štúdii uskutočniteľnosti. Zásadnejšie zmeny štúdie uskutočniteľnosti, ktoré považujeme za nutné neboli zapracované.

Diskusie k projektu na platforme:


:file_folder: Dokumenty


:clock2: Aktivity

V tomto projekte už prebehli nasledovné dôležité aktivity / míľniky:

  • 28.11.2017 Reformný zámer predložený na verejné pripomienkovanie a prípadné schválenie komisiou 18.12.2017

  • 13.3.2018 Verejné prerokovanie štúdie uskutočniteľnosti.

  • 19.4.2018 Schválenie zámeru národného projektu.

  • 22.6.2018 Vyhlásenie výzvy na predkladanie Žiadostí o NFP

  • 21.9.2018 Dátum uzavretia výzvy

1 Like

Z precitaneho RF zatial nasledovne work-in-progress pripomienky.

Základným cieľom reformného zámeru je zamerať sa na rozvoj aktivít vedúcich k dosiahnutiu cieľov definovaných v NKIVS, to je (1) posun k službám zameraným na zvyšovanie kvality života občanov a (2) posun k službám zameraným na nárast konkurencieschopnosti podnikateľov prostredníctvom zabezpečenia jednoduchého vybavenia ich ŽS, ako aj (3) Umožnenie modernizácie a racionalizácie verejnej správy IKT prostriedkami, a to s prihliadnutím práve na oblasti analyzované v rámci pracovnej skupiny Lepšie služby.

TL;DR - Problem - portal je zly, lebo slaby benchmark 2016.

Pripomienky

Pre aktivity nie je dostatocne popisana motivacia resp. realistickost problemu.

Aktivitu “riešenia pre inteligentné formuláre podporujúce princíp jedenkrát a dosť, vďadka ktorým bude môcť byť správnosť a úplnosť údajov o používateľoch kontrolovaná už počas prípravy podania;” ziadame vypustit. Podla schvalenej NKIVS a strategickych priorit je preferovany decentralizovany model tvorby podani a “vyplnacia cast” formularov bola zo standardov uplne vypustena. Jej rozvoj pokladame za krok spat a uplnom rozpore s myslienkou 1x a dost. Jej podstata je v NEvyplnani udajov, ktore uz stat eviduje inde, nie ich inteligentnejsie vyplnanie.

KPI na strane 12 - “počet podaní vykonaných prostredníctvom ÚPVS” odhad je nevhodny, kedze by siel proti preferovanemu decentralizovanemu modelu.

Strana 12

Planovany projekt zahrna velmi heterogenne aktivity, ktore spolu nijakym sposobom nesuvisia a musia byt realizovane uplne samostatne, kedze by slo o umele spojenie predmetov pripadneho obstaravania. Online chat dnes bezne poskytuju stovky firiem na svete ako SaaS sluzbu, naopak rozvoj IAM si tazko predstavit bez silneho zapojenia sucasneho dodavatela. Nova osobna zona, evidencie opravneni tretich stran mozu vznikat pomerne oddelene od sucasnych rieseni ako male projekty. Navrhujeme rozdelit na mensie jednotlive projektove celky.

Strana 21
“Počet optimalizovaných procesov, ktoré sú realizované navzájom
medzi orgánmi verejnej moci na úseku Koordinácie plnenia úloh v oblasti informatizácie spoločnosti” DVA do roku 2021?

“Počet aplikácií umožňujúcich prístup ku konsolidovaným
informáciám a k inovatívnym a personalizovaným
možnostiam riešenia životných situácií” - jeden? Toto sa bude priebezne kontrolovat len velmi tazko.

“Podiel získanej a vyhodnotenej spätnej väzby od používateľov
portfólia klienta (vrátane spätnej väzby získanej v rámci štátneho
messenger-a)” - KPI by mohlo byt aj opacne, ak ludia musia pouzivat call centrum/chatbot tak je nieco zle. Preco len portfolio klienta? Navrhujeme to rozsirit na cely web slovensko.sk

Strana 47 - Finančná alokácia pre aktivity OP II
Ziadame odhady pre indikativne alokacie pre jednotlive vystupy, nielen celkovu alokaciu.

Sumarne zhodnotenie:

Reformny zamer ide relativne s cielmi v strategickych dokumentoch, ziadame vsak jeden 25m projekt rozdelit na mensie podprojekty, ktore mozu byt realizovane roznym sposobom (SaaS vs vyvoj vs interny vyvoj). Ide o velmi heterogenne a nesuvisiace vystupy, ktore by sa nemali umelo spajat. Rozvoj inteligentnych formularov ziadame uplne vypustit, ide proti schvalenym dokumentom a decentralizovanemu konceptu vytvarania podani. Automaticke predvyplnanie formularov povazujeme za krok nespravnym smerom k naplneniu skutocnej podstaty principu 1x a dost. KPI povazujeme za slabsie, nie sme presvedceni o tom, ze budu stacit na priebezne sledovanie vystupov projektu. Niektore KPI (napr. pocet podani cez UPVS) mozu byt zavadzajuce (ak bude dobre fungovat 1x a dost, mal by sa celkovy pocet podani znizovat) alebo uplne mylne (zvysovat pocet podani cez UPVS nedava zmysel v decentralizovanom modeli tvorby podani).

S kym by si tam mal moznost obcan pokecat?

RZ 48 - pripomienky S.D.docx (13.3 KB)

Trosku som to upratal a dal do doku co tam @Lubor posle. Z mojho pohladu je toto strasna skoda tento RZ. Lebo do velkej miery je to uplne v sulade s cielmi zo strategickych dokumentov, ale su tam hlavne nestastne dva momenty:

  1. je to cele plesknute do jedneho projektu za 25M. pritom su tam uplne nesuvisiace veci (chat a rozvoj IAM atd)
  2. nastavene KPI podla mna nemozu ani omylom pokryt vsetky ciele ktore tam su.

Podla mna tomu fakt nechybalo vela. Stacilo to nasekat na logicke celky (to tam vlastne je), kazdy z nich spravit ako separe projekt (mozno aj nabalickovat spolu) a pre kazdy projektik urobit poriadne KPI. Toto su veci co sa daju dodat uplne samostatne a este by sa mohli chvalit, ze im to dodali male firmy. Take pridelovanie opravneni tretim stranam je bud change request na IAM alebo takmer uplne separe nova vecicka co fakt nemoze byt problem spravit aj bez globaltelu. Toto je asi granularita, ktoru by som cakal od modularneho systemu, ktory nezabije obstaravatela pri buducich integraciach a zaroven nebude velky vendor lock, kedze je to cele male a mozu to vyhodit z okna ked sa im to znepaci.


Samozrejme si odmyslime rozvoj inteligentnych formularov, ale to je uz taky evergreen co sa sem tam vyskytne vsade.

1 Like

Je tu studia. https://metais.finance.gov.sk/studia/detail/d812c162-93ea-1e5f-b635-a7e5fb7b2c6d?tab=documents

Mirror: SU_NASES_Zvysovanie hodnoty sluzieb_Prilohy.pdf (1.2 MB) OPII CBA_Agendove IS_v190118.xlsx (106.7 KB) SU_NASES_Zvysovanie hodnoty sluzieb_MD.pdf (2.3 MB)

Vitam pripomienky tu, konsolidovat ich budem sem. Pripomienky k štúdii: Zvyšovanie úžitkovej hodnoty digitálnych služieb pre občanov, podnikateľov a inštitúcie verejnej správy - Google Docs

ciste technicka poznamka, RZ nehovori o tom ako sa projeky rozdelia do VO. A dokonca ani to ako sa vypise vyzva, Postup je Reformny zamer, z neho vznika jedna alebo viac studii realizovatelnosti a na ich zaklade sa vypise výzva. Na nu sa podava ziadost o NFP, ktora uz uvadza aspon ramcovo ako bude vyzerat VO. Nic ale nebrani realizovat jedno VO pre viac vyziev alebo naopak v ramci vyzvy realizovat viacero obstaravani.

A mam taky pocit ze dnes je nazor ze spravny postup na takyto predmet je realizovat jedno VO s castami, pricom uchadzac moze podat ponuku na cely predmet alebo na cast a vyhodnocuje sa to po castiach.

pripomienky ze treba rozdelit RZ su teda nepochopenim procesu,

Netreba rozdelit RZ, ale rozdelit to na separe projekty v ramci jedneho RZ, tak ako to spravila napriklad aj socialna poistovna.

architetonicke rozdelenie by mala spravit aź studia realizovatelnosti. Povodny zamer ze reformny zamer sa ma venovat uvodnemu zdovodneniu zmyslu sa takto postupne meni na to ze RZ sa meni na mackopsa kde je potrebne mat uz hotovu studiu inak sa neda na taketo otazky odpovedat. Co je inak aj pripad SP, tak dopredu vie ake systemy chce robit a spatne k tomu dorobila RZ.
Takto povodne dobre myslena uvaha ze najprv treba vediet co ideme menit aby projekty EVS skutocne podporili projekty OPII a na to staci jednoduchy material, sa meni na zlozite mosntrum ktore uz nedokazu spravit urady ale musia to obstarat u konzultacnych firiem. Ak aj boli na uradoch nositelia predstavy reformy tak sa to presuva do konzultaciek s vysledkom ze sa draho robia dve formy studie realizovatelnosti a zo vsetkymi neduhmi ake to prinieslo.

Zaujimava uvaha, ako potom do tohto celeho zapadaju krasne togafove obrazky zo strategickych priorit a nasekanie na projekty, ktore tam uz davno je?

to je ukazka ako sa dobra myslienka meni v prostredi byrokracie. A potvrdzuje Parkinsonove pravidla. Ak uradnik dostane za ulohu zjednodusit proces tak vysledok je dalsi formular k existujucim.
Zrejme predstava ze RZ ktory je schvalovan tak cca 30 ludmi, je verejne diskutovany atd by mohol nemat 50 stran, obrazky ktore nikto nechape, tabulky ktore nie su presne na centy a neodpovedat na vsetky otazky k prevadzke je nepredstavitelna. Ved by potom tych 30 ludi nemuselo nic robit.

Skutocne na pociatku bola poziadavka aby bola podporena reforma VS, a teda aby soft projekty ktore platia ludi a hard projekty IT boli pod jednym riadicim organom. Slovensko to nechcelo a ako kompromis bolo dohoduty koordinacny mechanizmus medzi EVS a OPII, ktory mal zabezpecit aby sa nestalo ze bude podporena reforma z jedneho ale uz nie z druheho. Dnes uz je povodny zmysel zabudnuty a zije to vlastnym zivotom. A tak ziadas aby uz reformny zaver detailne popisoval ako to bude rozdelene do projektov a ako to bude sutazene. Cim podporujes tu zmenu ktrora sa postupne udiala ze RZ ma byt detailnym zavazkom toho co sa udeje. A dalsie dokumenty su potom uz len de facto formalne prepisanie obsahu RZ.

Skusim konkretny priklad, problemy RZ su tu mimo temu (aj ked zaujimave isto).

Riesi sa tam napriklad “statny messanger” - tym ze to fukli pod jeden projekt, ktory ma nejake tri alternativy (nerobme nic, centralizovana verzia, decentralizovana verzia, kde bude portfolio na agendovych systemoch) tak sa straca podstata - niektore podprojekty - totiz mozu mat zmysel tak, ine onak.

A navyse - messanger je dnes takmer komoditny softver, existuju asi aj FOSS verzie - uvazuje sa o opensource/zakupeni sluzby/custom vyvoji? Odpoveda studia na toto? Nie. Otazky, ze ci vobec niekto chce takyto messanger? Nie. Podla mna je to v rozpore aj s dokumentom SP z ktoreho to vychadza - lebo tam sa explicitne pise, ze poziadavky na toto musia byt jasne dolozene potrebami ludi. Kedy to chcu dolozit, ked bude hotove obstarko, vitaz a hotova DFS?

K RZ ako takym - moj nazor na to je takyto - neverim na fazovanie projektov podla specializacii - vid toto. Trend v komercii je presne opacny, robia sa uzke timy, kde je zastupena kazda potrebna rola (od policy cloveka, dizajnera, itckara…). Cize v principe suhlasim aj s tym co pises.

to priamo suvisi s RZ, ten by mal popisat co sa chce dosiahnut, ako sa to dosiahnutie da merat a povedat aka je hranica sumy za ktoru to este ma zmysel robit. Nie riesit technicke alternativy a rozdelenie na projkety. Ak takyto zamer dava zmysel tak az potom sa k tomu zacnu navrhovat sposoby ako to robit. Prave spojenim do jedneho dokumentu sa cela uvaha zneprehladni, fixnu sa veci ktore by sa nemali fixovat v takomto stadiu a potom to uz dopadne ako sa da cakat.
A tu este potom doslo k dalsiemu nie najlepsiemu posunu, IT projeky sa nerobia len na to aby naplnili potreby ludi, aspon teda nie vzdy priamociaro.

A poznamka k fazovaniu atd. V skutocnosti chybaju dobre data, chybaju take tie smiesne projekty non IT projkety ktore zistuju co ludia naozaj robia, co naozaj potrebuju atd. Nerobia ich minsiterstva, nerobia ich skoly, nerobi to SAV. Projkety sa robia na zaklade predstavy co by tak asi ludia mali chciet. V lepsom pripade, v horsom na zaklade napadu co tak asi chce niekto robit.

V komercii by RF zodpovedal ideovy zamer, ktory schvaluje vrcholovy manazment a posuva ho do dalsieho rozpracovania formou studie uskutocnitelnosti. A tomu by mal zodpovedat aj jazyk, ziadne technicke detaily ktorym nerozumeju, hovori o biznis cieloch a prilezitostiach. ked je idea spravit elektromobil, tak sa neriesi aka bude bateria a ci sa bude vyvijat alebo kupovat.

Ok, uz asi rozumiem. Vidim, ze projekt OPII je vlastne len studia, cize tam mi nevadi, ze studia odpovie na vsetky otazky aj nesuvisiacich veci. Aj ked vidim potom riziko, ze je to prilis binarne - proste bud ideme analyzovat vsetko alebo nic.

To rozdelenie by som cakal teda v studii a hlavne, ze studia odpovie na otazky co su napisane v RZ. Zatial to tam nevidim, ale len zacinam citat.

Svet nie je idealny, kedze od napadu cez schvalenie RZ,schvalenie Studie, schvalenie NFP, samotneho VO prejdu tak 3-4 roky, tak dosledok je ze uz na zaciatok sa tam napcha vsetko co sa da.
A este politicke dosledky, dnes sa cyklus od napadu po realizaciu pretiahol cez dlzku volebneho obdobia. To vyznamne znizilo sancu ze dnesne projekty budu mat silnu politicku podporu. Projekty ktorych uspech zavisi od podpory tak zrejme nebudu realizovane, ostanu len viac menej ciste IT, kde ich dopad na procesy nebude velky. taky mesenger nikoho nenastve, podobne dalsia centralna databaza sice nepomoze ale ked sa nasadi tak nebudu plosne protesty. Naopak zasiahnut do stavebnehio konania je politicke riziko a tak lepsie bude venovat sa niecomu inemu, napriklad stavbe ciest, tam sa kazda nova cesta stretne s pozitivnym prijatim

…vie mi niekto povedat, ze aka je teda odhadovana cena tohto projektu?

  • v Studiu v manazerskom zhrnuti je uvedene, ze cena je 18,7M
  • v komente @jsuchal pise, ze to je 25M
  • v CBA, tabulka Indikativny rozpocet hovori o cca 18,7M
  • su to sumy bez DPH, ci s DPH?

…ak som to spravne pochopil, tak SW a HW mimo vladneho cloudu je za 8,6M…co sa za to ide kupovat konkretne? Tie dlhe zoznamy Oracle a Microsoft a IBM ptroduktov v prilohach Studie?

…a ak som spravne pochopil studiu, tak je postavena na tom, ze dostanu vo vladnom cloude, citujem:
Predpokladá sa využitie najmä nasledujúcich služieb typu IaaS:

  • virtuálny server,
  • diskový priestor,
  • sieťové pripojenie,
  • HSM.
    Predpokladá sa využitie najmä nasledujúcich služieb typu PaaS (ak budú v nevyhnutnom čase dostupné):
  • služby aplikačnej vrstvy,
  • služby prezentačnej vrstvy,
  • služby databázovej vrstvy,
  • služby Integračnej a orchestračnej vrstvy,
  • služby bezpečnosti,
  • služby monitoringu a manažmentu.
    Predpokladá sa využitie nasledujúcich služieb typu SaaS (ak budú v nevyhnutnom čase dostupné):
  • aplikácia pre správu webového obsahu,
  • aplikácie chat asistenta (Chatbot).

Teda ak to nedostanu, tak ta cena bude asi ina, vyssia. Vladny cloud im vieme splnit tie poziadavky?

…ak od 18,7M odpocitam sumu cca 9,8M (co predstavuje sumu za SW a HW mimo cloudu, riadenie kvality, riadenie projektu, skolenia, publicitu a informovanost), tak na realizaciu samotneho produktu zostava cca 8,9M…ktore maju byt minute za menej ako 24 mesiacov…cize pri rate 800,- EUR bez DPH za MD, to je 11 125 MD, co znamena, ze kazdy mesiac by muselo byt v priemere 23 ludi na projekte…z hladiska projektoveho cyklu to bude na zaciatku menej a pride peak, kde bude podla mna cca 50 ludi naraz a potom to bude Kolesar…davat robotu 50 ludom tak, aby boli vytazeni a robili zmysluplne je dost, ale ze dost problematicke…zakaznik musi dobre poznat co chce…

…proof of concept je fajn…zaujimalo by ma, ze na co konkretne/ake funkcionality proof of concept pokryje?..lebo napr. pri funkcionalitach ako massenger, rozpracovane podania, spolocne moduly, opravnenia tretich stran ho nevidim…cize tam sa proof of concept robit nebude?..proof of concept by mal byt pouzivany aj na cisto technologicke casti a nielen na take, ktore maju UI…

…keby sa chcelo, tak sa ten projekt da rozsekat na mensie nezavisle celky…a urcit aj ich prioritu a postuponost…napr ten massenger nemusi byt asi hned ak vobec, lebo su tam urcite dolezitejsie veci a vie sa robit nezavisle od inych modulov/casti…

1 Like

…plus su tam identifikovane zavislosti na externe moduly/IS…napr. platforma datovej integracie, API GW…zaujimavy by bol pohlad, ze ktora cast tohto projektu je a v akon rozsahu zavisla od tychto externych modulov/IS a aj pohlad, ze aky prinos pre koncoveho pouzivatela budu mat jednotlive casti tohto projektu, ked nebudu zimplememtovane externe moduly/IS…toto tiez moze dat pohlad na to , co je dolezite a co ma vyznam a v akom poradi implementovat…ale toto je taky pohlad, by mal platit pre cele OPII…

…a ako vsade, chyba mi tu porovnanie voci FOSS verzii, pripadne prechodu na FOSS…TCO napr v 10 rokoch…

1 Like

Tak dokument s pripomienkami som upravil, snad som tam zachytil vsetko. Diky za komenty @peter_k.

TL;DR - napriek niektorym nepriznivym veciam (pripomienky su z povahy vzdy negativne) - musim pochvalit to, ze vlastne to skoro cele ide v duchu schvalenych strategickych priorit a nie su tam uplne haluze (s vynimkou formularov) ako pozname z inych studii. Kiez by sa SP takto riadili aj ostatni.

XLS: pripomienok tu. https://docs.google.com/spreadsheets/d/1SsUZGEirQgKMIaLXfLrHShRx0-P4ZSpQLiMU5Sauevc/edit#gid=711432393

Dosla odpoved na pripomienky. Slovensko.Digitalpripomienky (1).xlsx (20.6 KB)