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. https://docs.google.com/document/d/1DqgdBWncF1YD6bDnRec4T_Bn4-oEAYeFuZn_mWXB6os/edit?usp=sharing
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?
…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:
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…
…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…
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
13.3.2018 Verejne prerokovanie studie.
nemam slov …
Inak nezacal sa tento projekt pripravovat este pokial ste sefovali NASESu Vy?
samozrejme zacal, RZ sa pripravoval davnejsie