Red Flags: Efektívne služby Sociálnej poisťovne

Red Flags Projekty
,
1

Názov: Efektívne služby Sociálnej poisťovne

Garant: Sociálna poisťovňa

Stručný opis: Cieľom projektu je redizajn služieb a optimalizácia procesov SP tak, aby sa dosiahla optimalizácia a integrácia procesov v kontexte celej životnej situácie klienta, zavedenie proaktívnych služieb voči klientom a aplikácia zásady „1x a dosť“, zvýšenie efektívnosti prostredníctvom elektronizácie a automatizácie procesov, pro-klientska orientácia služieb a podpory klientov, multikanálový prístup, zvýšenie efektívnosti administratívnych (podporných) služieb a procesov, zavedenie monitoringu, merania a kontinuálneho zlepšovanie procesov a podpora rozvoja vlastných analytických kapacít SP.

Náklady na projekt: Štúdia uskutočniteľnosti 33m EUR

  • Efektívny manažment údajov v prostredí SP (MÚSP) - 4,5m EUR
  • Modernizácia dávkových agend SP - 17,5m EUR
  • Zavedenie proklientsky orientovaných procesov a služieb pre podporu klientov SP - 8,35m EUR
  • Budovanie analytických služieb pre podporu kontroly a rozhodovania v SP - 2,5m EUR

Zhrnutie hodnotenia Red Flags: Projekt sa snaží o dôležitú, potrebnú a dlho zanedbávanú konsolidáciu údajov sociálnej poisťovne. Vítame rozhodnutie postupovať po častiach, nie jedným veľkým projektom ako tomu bolo v minulosti. Prvý projekt konsolidácie údajov sa zameriava na konsolidáciu údajov a konsolidáciu integračných prepojení rôznych informačných systémov sociálnej poisťovne. V štúdii podľa nášho názoru chýba jeden variant, ktorý by neuvažoval vytvorenie centrálneho úložiska a silne odporúčame sa vyhnúť pri integrácii orchestrácii na centrálnom bode. Zvyšuje sa tým riziko vendor lock a udržateľnosti projektu do budúcna. Riziko neefektívnosti taktiež vidíme v nejasných prínosoch konsolidácie voči iným referenčným registrom, ktoré môžu mať len malé biznis prínosy.

Stanovisko Slovensko.Digital: Navrhujeme štúdiu doplniť o spomenuté varianty a vyhodnotiť ich CBA. V úvode realizácie projektu odporúčame klásť veľký dôraz aj na netechnické charakteristiky proof-of-concept, ako: zníženie rizika vendor locku, jednoduchosť integrácie konzumentov aj producentov údajov ako aj integráciu samotnú.

Aktuálny stav projektu: Obstarávanie/Nákup

Čo sa práve deje:

  • vyhodnocovanie verejného obstarávania "Manažment údajov Sociálnej poisťovne

:triangular_flag_on_post: HODNOTENIE RED FLAGS

I. Prípravná fáza

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

Reforma VS je momentálne popísaná len na úrovni Reformného zámeru. Tento popisuje reformu veľmi technicky, bez zámerov, ktoré by poukazovali na snahu zásadne reformovať procesy. Projekt obsahuje zavedenie princípov ako “jedenkrát a dosť (dáta)”, ale z RZ nie je vôbec jasné, ktoré súčasné procesy SP sa majú reformovať a akým smerom. Plnenie cieľov OP EVS je podľa reformného zámeru nulové.

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

Reformný zámer uvádza nasledovné KPI pre projekt:

image
image622×503 51.9 KB

KPI projektu sú navrhnuté nevhodne - orientujú sa na výstupy (napr. počet poskytovaných koncových služieb) a nie výsledky pre používateľa. Jediné KPI, ktoré ako tak spĺňa túto definíciu je “Zníženie počtu povinností klienta dokladovať SP údaje alebo preukázať skutočnosti, na účely konania”. Pritom v časti RZ, ktorý popisuje pridanú hodnotu reformy, sú formulácie jasnejšie. Nie sú však vyjadrené cez KPIs.

Projekt manažmentu údajov: KPI sa sústreďujú primárne na data governance a sprístupnenie údajov ako referenčných, KPI ako také sú vhodné, nie je však zrejmá ich súčasná hodnota. Úplne absentuje KPI pre využívanie nových referenčných dát ako v rámci Sociálnej poisťovne tak aj mimo nej. Považujeme tento indikátor za kľúčový pre sledovanie napĺňania cieľa 1x a dosť.

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

Implementačná jednotka zodpovedajúca za realizáciu reformy (Odbor strategického rozvoja SP) má len 5 pracovnkov, čo sa dá považovať za riziko. Plánuje sa navýšiť na 12. Tento počet by viac zodpovedal rozsahu reformy.
Plán aktivít je v RZ popísaný. Reforma procesov sa javí úplne oddelená od ostatných streamov a celý plán tak neberá charakter “povinnej jazdy”, len aby sa dali realizovať IT projekty. Riziko takéhoto postupu je vysoké.

Projekt manažmentu údajov: Projekt obsahuje v úvode plánu Proof-of-concept pre vertikálny rez funkcionalitou, čo hodnotíme pozitívne. Taktiež plán spostupovať po rôznych segmentoch postupne hodnotíme pozitívne.

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

Pre aktualizované KRIS nebol zatiaľ zhodnotený súlad.

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

Biznis prínosy (resp. napĺňanie cieľov OP EVS) sú v rozpracovanom RZ nejasné a často absentujúce. Je to vo veľkom kontraste k IT prínosom, čo len posilňuje vnímanie, akoby išlo len o realizáciu IT projektu, bez širšieho uvažovania nad reformou v SP.

Projekt manažment údajov: Z uvedených biznis prínosov je zrejmé, že bez konsolidácie údajov a zavedenia zdieľania údajov medzi agendami a centrálnou úrovňou, môže pre SP spôsobiť problémy s výkonom jej zákonných povinností.

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

Reformný zámer deklaruje plnenie špecifických cieľov OPII- Súlad projektu s princípmi NKIVS je momentálne ťažké hodnotiť. Najväčie riziká vidíme v absencii elementov ako je napr. proof of concept, pri tak veľkej investícii

Projekt manažment údajov: Ciele projektu sú v súlade s cieľmi NKIVS a informatizáciou, bez konsolidácie údajov a publikovania referenčných údajov vidíme veľké riziko nezavedenia princípu 1x a dosť do praxe.

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

Štúdia bola vypracovaná, bola predstavená na verejnom hearingu a bolo umožnené aj jej pripomienkovanie. Z obsahového hľadiska vítame koncept postupného budovania cez Proof-of-concept. Zo štúdie nie je úplne zrejmé, aké úlohy bude plniť centrálny komponent. Výstupy projektu sú definované najmä k vzťahu k zlepšeniu dátovej kvality, vidíme však potenciálne riziko v prípadnej efektívnosti prepájania a čistenia dát. Dátová integrácia na iné registre (napr. register adres) môže by veľmi náročná s malými prínosmi v reálnej prevádzke. Bolo by vhodné do štúdie doplniť aké konkrétne problémy dnes vznikajú v kontexte ako dátovej integrácie, tak integrácie systémov. Chýba porovnanie efektívnosti pre rôzne (aspoň uskutočniteľné) alternatívy.

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

Reformný zámer neobsahuje hodnotenie alternatívnych postupov. Štúdia obsahuje alternatívy. Spracovanie alternatív však neuvažuje alternatívu s decentralizovaným úložiskom údajov a čistením údajov priamo pri “zdrojovej agende”, ako je to bežné pri referenčných registroch (napríklad aj pomocou centrálnej služby). Orchestráciu samotných služieb na centrálnom bode považujeme ako nevhodnú alternatívu, ktorá je akceptovateľná len ako prechodné riešenie a dnes je už prekonaná SOA 2.0 prístupom riadeným udalostami. Odporúčame pre integráciu zvážiť namiesto centralizácie alternatívu silnou štandardizáciou a “ľahkým” event-busom.

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

Predložená CBA pre štúdiu uskutočniteľnosti má viaceré nedostatky, ktoré je potrebné odstrániť. Ide napríklad o nesprávne uvedené vstupné hodnoty (chýba počet zamestnancov vybavujúcich agendu) a doplnenie prevádzkových nákladov.

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

K projektu sa zatiaľ neviedla širšia verejná diskusia ani aktívnejšie zapojenie verejnosti do jeho prípravy.

Diskusie k projektu na platforme:

II. Obstarávanie / nákup

Stratégia obstarávania :star::star::star::grey_star:

Problém fragmentácie údajov bázy Sociálnej poisťovne je dlhodobo známy, konsolidácia a manažment údajov je z dlhodobého hladiska veľmi potrebná. Tento zámer je nevyhnutný z pohľadu ďalšieho rozvoja služieb. Z pohľadu nákupu však nedáva veľký zmysel oddelovať údajovú vrstvu od poskytovaných služieb, kedže spolu veľmi úzko súvisia a koordinácia viacerých projektov, ktoré sú takto tesne integrované bude riziková.

Prípravné trhové konzultácie :grey_star::grey_star::grey_star::grey_star:

PTK neprebehli, vzhľadom na veľký počet otázok záujemcov je zrejmé, že táto fáza projektu bola výrazne podcenená, špeciálne v prípade, že ide už o druhé vyhlásenie obstarávania (prvé bolo zrušené UVO) a zadanie nie je zrejmé.

Druh postupu :star::star::star::star:

Súťažným postupom je v predmetnom nákupe verejná súťaž, čo sa považuje za najsúťažnejší postup vo vzťahu k hospodárnosti a súťaživosti subjektov na trhu. Predchádzajúca užšia súťaž bola zrušená UVO.

Predmet zákazky :grey_star::grey_star::grey_star::grey_star:

Opis predmetu zákazky je pomerne abstraktný a nekonkrétny, o čom svedčí aj minimálne 40 otázok na verejného obstarávateľa. Dá sa predpokladať, že uchádzači nie sú schopní si vytvoriť predstavu o požadovanom plnení bez zodpovedania otázok. Tento projekt je jedným z viacerých projektov, ktoré Sociálna poisťovňa plánuje obstarávať. Z tohto pohľadu už ide o akési delenie zákazy. Toto delenie (na dátovú časť a službovú časť) považujeme za veľmi rizikové, jednak kvôli koordinácii a neprirodzenému deleniu, kde bude vznikať veľká závislosť tvorby služieb od predmetu zákazky tohto projektu. Predmet zákazky je rozdelený na tri fázy, nemožno však hovoriť o čiastkových plneniach v zmysle zákona o ITVS, kedže sa nepredpokladá, že by nejakú časť už nebolo potrebné dodať. Predmet zákazky je silne naviazaný na špecifickú Talend MDM technológiu, pričom absentuje spomenutie ekvivalentu, ktorý by mohol zabezpečiť rovnakú funkcionalitu/hodnotu za rovnaké náklady. Toto je považujeme za nevhodné a napadnuteľné.

Rozdelenie na časti (nie je zatiaľ vyhodnotené)

Podmienky účasti :star::star::star::grey_star:

Podmienky účasti umožňujú súťaž širšiemu okruhu dodávateľov, bránia však v účasti SME, ktorí nemusia byť schopní dokladovať požadovaný obrat za posledné tri hospodárske roky (4 milióny eur) a taktiež zákazky podobného charakteru (1 milión eur - dátová integrácia, 500 tisíc eur - dátová kvalita…). Požiadavky na úrovni požadovaných expertov nie sú nijako neštandardné.

Kritériá hodnotenia :star::star::star::star:

Jediným kritériom na vyhodnocovanie ponúk je cena. Verejný obstarávateľ detailne popísal ako bude dané kritérium vyhodnocovať. V prípade, že sa bude vedieť vysporiadať s podozrivo nízkou cenovou ponukou, je možné považovať toto kritérium za splnenie ekonomickej výhodnosti dodaného predmetu zákazky.

Vendor Lock-in a Autorské práva :star::star::star::star:

Zmluva o dielo explicitne uvádza, že objedávateľ bude mať všetky potrebné bezvýhradné licencie na predmet zákazky, taktiež zdrojový kód bude licencovaný pod EUPL.

Lehoty (nie je zatiaľ vyhodnotené)

Obchodné podmienky (nie je zatiaľ vyhodnotené)

Vyhodnotenie obstarávania (nie je zatiaľ vyhodnotené)

Hospodárska súťaž (nie je zatiaľ vyhodnotené)

Cena (nie je zatiaľ vyhodnotené)

Subdodávatelia :star::star::star::grey_star:

Povinnosť oznamovať a zverejnovať subdodávateľov je zachytená v obchodných podmienkach. Objednávateľ však nemá explictne uvedené právo namietať výmenu subdodávateľa.

:file_folder: Dokumenty

:clock2: Aktivity

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

  • 20.7.2017 Reformný zámer schválený HK OP EVS
  • 23.11.2017 Verejné prerokovanie pripomienok štúdie uskutočnitelnosti
  • 12.12.2017 - schválená štúdia uskutočniteľnosti
  • 5.3.2018 - vyhlásená výzva na predkladanie žiadosti o NFP
  • 4.7.2018 - predložená žiadosť o NFP
  • 28.8.2018 - schválená žiadosť o NFP
  • 27.9.2018 - podpísaná zmluva o NFP (http://www.crz.gov.sk/index.php?ID=3684991&l=sk)
  • 2.7.2019 - vyhlásené verejné obstarávanie na “Manažment údajov Sociálnej poisťovne”
  • 1.5.2020 - začiatok realizácie EŠIF projektu (23 mesiacov, t.j. do 30.4.2022)
1 Like
2

Toto nam prave prislo.

Vážení kolegovia,

dovoľte, aby som vás informoval o pripravovanom verejnom pripomienkovaní Štúdie uskutočniteľnosti k projektu Efektívny manažment údajov v prostredí Sociálnej poisťovne.

Štúdia uskutočniteľnosti je dnešným dňom 14.11.2017 sprístupnená na verejné pripomienkovacie konanie. ŠU aj s prílohami sa nachádza na web stránke Sociálnej poisťovne v časti Programové obdobie 2014 – 2020/ Efektívny manažment údajov v prostredí Sociálnej poisťovne. Pripomienky je potrebné zaslať na adresu SU_MUSP_pripomienky@socpoist.sk do 22.11.2017 v zverejnenom vzorovom dokumente.

Verejné prerokovanie pripomienok ku Štúdii uskutočniteľnosti k projektu Efektívny manažment údajov v prostredí Sociálnej poisťovne sa uskutoční dňa 23.11. 2017 o 13.00 v zasadacej miestnosti č. 503, Sociálna poisťovňa - ústredie, , ul. 29.augusta č.10, Bratislava.

Štúdia uskutočniteľnosti aj s prílohami sa nachádza na web stránke Sociálnej poisťovne: http://www.socpoist.sk/efektivny-manazment-udajov-v-prostredi-socialnej-poistovne--musp-/65162s

3 Likes
3

Milí kolegovia,
prebehol som ten 58 stránkový dokument. Môj názor:

  1. Pre externistov je naplánovaných viac ako 6000ČD, to znamená, že 30 pracovníkov bude naplno pracovať 1 rok.
  2. Tento dokument je taký hrubý odhad, čo sa bude robiť a v akom objeme a koľko to bude stáť. Je to typ dokumentu pre top management, nie pre IT audit.
  3. IT audit môže len pokrčiť plecami a čakať na rozpracované dokumenty:
    A. Špecifikácia požiadaviek - konkrétny rozpis bod po bode, čo pokladá SP za problém alebo hrozbu a chce to riešiť. Tento dokument musí ísť na najspodnejší level rozlíšenia. K tomu už sa bude vedieť IT vyjadriť.
    B. Na základe dokumentu A vznikne Návrh riešenia. K tomu sa tiež vie IT vyjadriť.
    C. Na základe schváleného dok. B vznikne Plán projektu a Popis riešenia s odhadom časových nákladov. K tomu sa tiež vie IT vyjadriť.
  4. Jediné odporučenie, čo by som dal, nech najskôr urobia prípravnú fázu, kde by si zadefinovali podrobne (na úroveň 1čd), čo sa bude robiť. To nemôže byť viac ako 150čd. Predsa nejaké dokumenty už v SP existujú, nezačína sa od ústneho podania procesov.
    Až potom by som pristúpil k revízii objemu prác a schváleniu nákladov.
    Záver: Tento dokument je na úrovni schvaľovania zámeru top managementom, pre IT posudzovanie je irelevantný.
    Zdravím
    Braňo Balvan
1 Like
4

Studia Uskutocnitelnosti ma predpisanu presnu strukturu a je logicky dobre vymyslena. Problem je ze MF SR zacalo pred par rokmi zavadzat vaznu svetovu metodiku na riadenie enterprise architektury. Zial medzitym sa im ludia rozutekali a tak na nastavenie aspon rezortnej architektury nedohliada ziaden Enterprise Architekt, ale meniaci sa politicki nominanti. Takisto predpis/templejt pre ŠU je postavený na ArchiMate frameworku, ktory sa vyznacuje tym, ze plnu stranu hutneho textu s popismi vztahov vie zobrazit jeden diagram spravne nakresleny… Ale chcem vidiet kto z tych co to hodnotia dokazu archimate diagramy citat (obycajne ich ale ani autori nevedia nakreslit)… cize cele je to take nemastne neslane, ani ryba ani rak.
Napriek tomu si to idem pozriet.
Len skepsa je v tom ze uz pred 5 rokmi sa v IT firmach vedelo o sume nad 70 milionov, ktore niekto rozhodol ze pojdu na Soc Poist. Cize … dokument, ktory by mal naznacit smerovanie a skusit vycislit naklady sa podla mna bude snazit nejako strafit do toho ciisla … sorry ak to je inak, este som necital… tak drzte place :slight_smile:
Ta studia by napriklad mala povedat nieco ako malo by sa spravit 6 takychto a takychto projektov, v takomto poradi … ich vystupy a ucel, priblizny rozpocet a obmedzenia (suvislosti)… aby sa dalo obstraravat. Projektovy plan vypracuvava az vitazny riesitel a predklada riadiacemu vyboru (kde btw, za obstaravatela musia byt ale tiez certifikovani profici a nie politicki docasni nominanti…inac je zarobene na priekak)

5

toto je studia na konkretny projekt…otazky, ktore si tu polozil musis hladat v dokumente, ktory si hovori KRIS, kde by si sa mal dozvediet o koncepcii, teda o pocte planovanych projektov, na co maju byt zamerane, cca sumy a pod…pripadne tieto info by mali byt aj v reformnych zameroch ak si dobre pamatam

skus KRIS tu https://metais.finance.gov.sk/kr/detail/9f66e1ae-4fbb-4913-b08a-11b2deef446b?tab=basicForm
skus reformny zamer tu https://www.minv.sk/?schvalene-rz&subor=272630

6

…je som si to presiel…spisal som do dokumentu moje postrehy/otazky…nie je to vo forme, ktoru vyzaduje SP…su to komenty v ramci pdf… 14112017-MUSP-SU_OPII_MUSP_v0.17.pdf (3.2 MB)

…mne sa ten dokument cital o nieco lahsie, nakolko som pri zrode myslienky aj pri zrode studie MUSP bol ako externy konzultant a teda viem o co koncepcne ide…pri finalizacii studie som uz nebol a teda niektore veci su aj pre mna nove/prekvapive, ale to je mozne vidiet z mojich komentov k dokumentu…

…co vidim ako pozitiva:

  • cena do 5 mil. EUR,
  • planuje sa Proof of Concept

…co vidim ako negativa:

  • ramcove VO a nejasnosti okolo toho ramcoveho VO
  • podla mna tam je trocha gulas vo variantoch B a C, tie treba upratat a az potom urobit CBA
  • neviem, co si mam predstavit pod variantom C, ze co je to ta platforma datovej vymeny…ci je to CSRU, alebo iba Talend, alebo nieco ine
  • aplikovanie mulitikriterialnej analyzy…je tazke porovnovat varianty, ak neboli urobene detailne analyzy kazdej varianty

p.s. 1 rozhodol som sa…s konzultantstvom koncim, nema to vyznam som zistil
p.s. 2 napadlo ma…vladny cloud je pripraveny a umoznuje migrovat/budovat IS, ktore su postavene vylucne na OSS, napr. taka PostqreSQL?
p.s. 3 vsimol som si…ani jedna studia doposial, ktoru som ja cital, neobsahovala ocenenie riesenia postaveneho na OSS…UPVII ani jednu studiu zatial nevratil s tym, ze tam chce vidiet ocenenu alternativu postavenu na OSS
p.s. 4 napadlo ma…ak vladny cloud determinuje konkretne technologie, tak to znamena, ze v ramci VO na IS su uz urcite technologie definovane tym, ze IS ma byt vo vladnom cloude
p.s. 5 domnievam sa…ze OVM nerozumeju, co to znamena prevadzka v cloude
p.s. 6 myslim si…ze CBA by mala byt robena pre vsetky alternativy a nielen pre vybranu alternativu

1 Like
7

Mozno sme si nerozumeli. Ja som tam vravel o viacerych projektoch, ako o mozno chcenej alternative jednemu megaprojektu, a ktore su nasledkom jednej = tejto studie.
Ale ta studia ma nejaky nazov a ciel.
ma ukazat stav AS IS a navrhovany stav TO BE. Ten rozdiel medzi nimi a to na vsetkych architektonickych urovniach (biznisova, aplikacna, technologicka) ma byt znazorneny v casi Implementation and migration. Takyto diagram obsahuje zakladne elementy GAPs, WORK PACKAGES …medzi stavom AS IS a TO BE. Kludne mozu byt v tejto casti navrhnute aj viacere medzistavy (FAZY ?) projektu (pricom projekt moze byt aj PROGRAM co je sada navzajoim suvisiach projektov).
K tym diagramom su aj tabulky v Prilohe. NEVYPLNENE. Kapitola Implementacia a migracia mi pripada ako zosumarizovanie planov jednotlivych dodavtaelov na ocakavane CRs … a nie ako sada workapckages, navrhnutych z odhalenych GAPov, ktore vzisli z porovania a zanalyzovania stavov AS IS a TO BE na jednotlivych architektonickych urovniach.
Asi viete ze Templejt na SU bol navrhnuty tak aby bolo treba co najmenej textu. Dokonca su tam striktne obmedzenia na 1600 znakov pred diagramom a po diagrame. To bol vymyslene preto aby posudzovatelia sa neutapali v slohovych ulohach. Dobre vytvorene archimate diagramy vedia nahradit spusty textu - nato presne boli vymyslene.

2 Likes
8

…uz ti asi rozumiem, co chces povedat…ved je tu UPVII…template vydal UPVII…UPVII aj pripomienkuje/schvaluje jednotlive studie, maju architektonicku kancelariu a pod., takze uvidime ako sa k tomu postavi…pre mna osobne su studie zahada…je to kreativita, uroven detailu od studie k studii je rozna a pod…

9

Tento togaf template je tragedia. V zasade dokument je necitatelny pre prevaznu vacsinu ludi. My sme na skoleni TOGAF (nie gopas, ktory sa koncetruje len a len na testy) boli neustale konfrontovany s tym: nedavajte archimate obrazky do prezentacii, repozitar je pre vas, nie pre publikum. Publikum chce pochopit, nie ucit sa togaf/archimate. Preto by studie mali byt studie a ak tak archimate iba v prilohach.

Druha vec ze ako si spravne podotkol ani nikto to nevie poriadne nakreslit. Preto na to kaslem v tych studiach. Hlavne ze tam je myslienka, motivacia, nejaky popis obsahu, aky taky harmonogram, nejako odhanuta cena.

2 Likes
10

Tono preto som vobec nehodnotil diagramy. Ale ani v tabulkach v prilohe nemaju ani len vymenovane biznisove sluzby, biznisove interfejsy (vyberam tie dolezite veci), nemaju aplikacne sluzby, pripadne aplikacne funkcie, ktore je treba spravit, aplikacne interfejsy … cize v podstate to najdolezitejsie co studia ma zanalyzovat. A navrhnut z toho projekt(y). Cize identifikovat GAPy a navrhnut Work Packages. To tam proste nie je. Preto aj bez dagramov je ta studia iba pokusom o povinnu jazdu a je asi lepsie ju nerobit, ako robit takto.
Mozno je nieco viac v tom dlhom texte, co sa mi nechce citat …Este si to ale precitam :slight_smile: …

2 Likes
11

Jednoznacne treba zmenit informacny system v Socialnej poistovni ako je mozne ze maju stare data z roku 2016 ked sa pozeram na Individualny ucet poistenca (IUP) a data z roku 2017 nie su vobec

12

Pripomienky spisujem sem. Vecer ich poslem. https://docs.google.com/spreadsheets/d/13P41hWhyuCaz61rYmotXYu9vafgL_nBZDSQYQ4e6D7c/edit?usp=sharing

Komentare vitane.

TL;DR
Z mojho pohladu ide o akysi klon CSRU specialne len pre data socialnej poistovne a preto mam vyhrady uplne rovnake ako k CSRU.

Zaujimava je vsak polozka z CBA - integracia na MUK 266 tisic eur. Ak to takto pojde dalej, tak sa na integraciach na MUK vyleju miliony eur.

2 Likes
13

Pripomienky poslane, avsak diskusia nech smelo pokracuje dalej. Kopec veci bude este dlho otvorenych.

14

…pre mna osobne sa CSRU a jeho planovany dalsi rozvoj a komplementarita CSRU s inymi planovanymi IS VS zacina stavat dost neprehladna…sa v tom stracam…moze to byt tym, ze sa tomu nevenujem uplne detailne a teda neviem posudit…

15

Zapis z dnesneho pripomienkovania:

Vazny

  • vyska povodneho projektu bola prilis velka - teraz chcu byt niekde pri 35m dokopy (viac projektov)
  • prilis vela projektov maju teraz - nevedia to udrzat - je tam bordel

Simacek - sef IT

  • velky tresk zle - opis - vsetci vieme ake vysledky sme dosiahli (digitalizacia starych projektov)
  • mainframe - cobol - kriticka prevadzka + programatori, dochodkovy vek programatorov + novi utecu do nemecka
  • nepojde sa velkym treskom (velakrat prizvukovane PoC, “rapid development”, aj opensource technologie)
  • opensource - problem je SLA - 24/7 - Oracle - je na zvazenie

Dalibor maco + Nejaka pani (meno som si nestihol zapisat) Daniela Globanová

  • pripomienky upvii

    • nejednoznacny vyber variantu
    • nesulad harmonogramu a KPI
    • nesulad KPI a NKIVS
    • aktualizacia na platnu legislativu
    • nejasnosti migracie do g-cloudu (platforma este neexistuje v cloude - cize mitigovane riziko nahradnym riesenim)
    • nejasnosti v suvislostiach medzi MUSP a EESSI

  • externe pripomienky

    • existujuce vs nove - ja stare aj nove, nasledne
    • csru - cast bude vyuzita - neposkytuju vsekto (sprava centralnych ciselnikov, distribucia…)
    • rizika vendor locku - smeruje to k opensource zdrojakom projektu (!)

K veci

  • existujuce systemy sa na to tiez napoja => vyvolane naklady (nebude hradene z tohto)
  • open data budu neskor (uplne som nepochopil preco)
  • IaaS = cloud - bude sa vyuzivat
  • chcu sa vyhnut sa vendor locku, aby to bolo vymenitelne
  • zdrojaky a model a vsetko budu vlastnit
  • pre nejake systemy nevlastnia modely dat - reporty nevedia ani poriadne potom zadefinovat
  • dva tyzdne cakanie na selecty - tomu sa chcu vyhnut
  • jeden system na MDM
  • povodny plan: 36mesiacov ale potom 24mesiacov
  • bolo tam cca 30 ludi, jediny som sa pytal ja

Moje otazky a poznamky:

  • riesi sa tu v “malom” uplne rovnaky problem ako sa riesi na centralnej urovni - rovnake a vacsie problemy (tu to ma aspon jedneho pana), rovnake riesenia - treba riesit MDM na zdroji, nie centralne. Ale v klude aj centralnou sluzbou.

  • doraz jednotna zbernica (eventy, standardizacia, zjednodusenie integracie skor ako centralizacia)

  • centralizacia je velke riziko - indicia je priamo v CBA - napojenie na muk 266k eur

  • CSRU na MDM, co CSRU chyba aby sa to dalo pouzit?

    • toto bolo trosku zmatocne vysvetlene, ze csru ma sluzit len na ref. udaje. Z mojho pohladu je MDM uplne jedno ake data sa tam daju.

  • PoC - end-to-end pilot aj provider aj konzument

    • ano

  • point-to-point integracie

    • pocet integracii sa nezmensi pridanim centralneho uzlu

  • push vs pull integracia

    • upozornil som na to, ze nech idu eventami, akakolvek centralizacia distribucie udajov viaze logiku a zodpovednost na centralu a rozpadne sa to.

  • FOSS

    • co sa tyka skaly tak FOSS sa pouziva na radovo vacsich systemoch, SLA moze byt problematickejsia lebo je tam menej penazi.

Sumar: Sef IT na mna posobil rozumnym dojmom, chce sa vyhnut vendor locku a maju tam s tym teraz velke problemy. Chyba mi vsak variant riesenia, ktory by MDM riesil pri zdroji dat, ak niekde je centralny ciselnik tak tam, ak niekde je nieco ine tak tam, nasledne nech si agendove systemy robia referencovanie lokalne a zavedie sa jednotny standard pre API/datove prvky etc. V skrate - naozaj v malom riesia to iste ako sa riesi na statnej urovni pri referencnych registroch a open API. Riesenie je uplne rovnake.

Predstava, ze bude niekde jedno miesto kde budu master data je podla mna divna. Ak tam maju byt len kmenove data, teda take na ktore sa vacsina referencuje a ine systemy by ich museli zbierat po roznych integraciach (podobny pripad bol RPO), tak to dava uz trochu zmysel viac. Stale vsak niekde tieto data musia vznikat a tym padom maju jasneho vlastnika a spravcu - a to bude najskor nejaky agendovy system.

Vsetky pripomienky (nielen nase) s vysvetleniami som si vyziadal na publikaciu. Taktiez prezentaciu (tam vsak nebolo nic zasadne).

2 Likes
16

A este jedna vec. Navrhoval som, aby sa MDM robilo vzdy na zdrojovom registri. V klude aj jednym toolom. Asi sme sa nepochopili, lebo reakcia na to bola, ze predsa nechceme obstaravat MDM pre kazdy subsystem.

17

Po prečítaní uvedenej štúdie uskutočniteľnosti som vytipoval niekoľko jej problémových častí.

Časť dokument

Zdá sa že SP ráta pre tento účel s nevhodným variantom verejného obstarávania. Ak sa bude súťažiť rámec a nebude povinnosť uchádzača oceniť celý predmet plnenia, je možné že vyhrá firma, ktorá bude v priebehu trvania zmluvy drahšia ako iný uchádzač a projekt sa mnohonásobne predraží.
Štúdia aj dokument ráta so začiatkom projektu v roku 2017, čo je nereálne a má vplyv na výpočet CBA.
Chýba sprievodná dokumentácia, napr. KRIS SP 2017, DataSocpMapping.xlsx a iné.
Dokument ráta s prvotným napojením MUSP na existujúce systémy, avšak v CBA analýze chýba vyčíslenie dopadov MUSP na cenu za rozvoj a integráciu, migráciu a parametrizáciu týchto systémov.
SWOT analýza vychádza z predpokladov, ktoré z dokumentu nie je možné overiť, resp. sú evidentne nesprávne.
Sociálna poisťovňa neráta s implementáciou MUSP v cloude od počiatku projektu, naopak na viacerých miestach spomína zvyšovanie výdavkov na existujúcu infraštruktúru.
A na záver dokumentu skutočná perla v podobe rizík, ktoré celý projekt posielajú do neakceptovateľnej podoby:
R-9.1: Nepodarí sa dosiahnuť preukázateľné úspory podľa plánu.
R-9.2: Náklady na vybudovanie MÚSP sa vymknú kontrole.
R-9.3: Náklady na prevádzku MÚSP sa vymknú kontrole.

Chybná a neúplná CBA

V časti rozpočet na riadku 47 sa nachádza položka PJM, QA, ktorú interpretujeme ako Projektový manažment a Quality Assurance. To ráta s poskytnutím externého projektového manažmentu v rozsahu 824 človekodní a až 42 FTE – bunka O47. Nie je jasné, kde sa zobrala suma 824 človekodní na implementáciu 2 ročného projektu. Ide o 2 projektových manažérov, nonstop súbežne nasadených na projekte MÚSP od prvého až do posledného dňa vrátane doby na školenia. Táto suma je zjavne neprimeraná rozsahu a povahe zákazky.
CBA neráta v horizonte 10 rokov so žiadnymi nákladmi na support k licenciám a s upgrade SW produktu, ani poplatkami za udržanie funkčnosti a dostupnosti aplikácie, čo je nereálne a skresluje ROI a TCO parameter v prospech predkladanej MÚSP varianty.
V CBA nie sú zahrnuté náklady na migráciu do cloudu v štvrtom roku prevádzky MÚSP. Z toho vyplýva, že migrácia do cloudu bude najskôr v roku 2022 až 2023, čo je v rozpore s NKIVS.
CBA neporovnáva Varianty A-D tak, ako ich uvádza dokument.
CBA je neúplná, neprehľadná a nie je jasný zdroj dát ani pri súčasných dátach (napr. Parameter agendové systémy) ani pri očakávaných výdavkoch.

18

dolezite ale je, ze CSRU sa tomu venuju a poctivo si nahanaju novu agendu :wink:

1 Like
19
  1. urcite sa da SLA aj na opensource technologie vo forme 24/7
  2. zaujimalo by ma kolkorat doteraz vyuzili 24/7 na existujucom Oracle a ci to aj bolo realne nutne?

tak, co teda v tej variante C predstavuje ta platforma vymeny udajov a co to bude robit?

nerozumiem…

  1. bavime sa o SLA = podpora k technologiam?
  2. ak ano, tak vyssie sa spomina, ze sa zvazuje aj Oracle, kde SLA tiez nie je lacna…ale beriem, ze by to malo byt poriesene cloudom
  3. v studii sa spomina, ze riesenie bude v cloude…prezentovane pri cloude bolo, ze poplatky za licencie a support su v ramci cloudu vyriesene…cize znamena to, ze cloud nie je FOSS ready?
20

Takto zase chlapi tento vegánsko - puritánsky prístup “FOSS for all” nie je ani všeliekom, a v tomto prípade ani na mieste.
Oracle nezbohatol a neocitol sa na spici IT priemyslu preto, zeby predal svoje DB do SP na Slovensku. A obvinit pol sveta ze su blbi si dufam ani ti najskalnesi vegáni nedovolia…

Kedze SP uz vlastní EXADATA a EXALOGIC systémy, je len logicke ze pozaduju Oracle SLA. Aj tak v tych projektoch je predrazene vacsinou nieco ine, a nie licencne naklady.
Takze hladajme preco projekt nevznika tak ako by mal, to znamena ze sa zanalizuje CO (biznisovo, architektonicky, NKIVS compliant …) je potrebne urobit a nasledne rozbijanim na nizsie a nizsie vrstvy z toho vyjdu pracovne balicky, ktore sa mozu sutazit … A preco projekt (a jemu poplatna studia) vznika opacnym postupom, ze dodavatelia povedia co asi vedia v najblizsich mesiacoch - rokoch dodat (samozrejme istá inspirácia v ocakavaných legislat. zmenach tam je), ale motivácia je skor zabetonovat svoje pozicie, nez hladat efektivne zmeny architektury …
:slight_smile: Pekny zvysok dna