Măsură
Nume:
Dezvoltarea unui cadru unitar pentru definirea arhitecturii unui sistem de tip cloud guvernamental
ID:
C7 – R1
Componenta:
Transformare digitală
Pilon:
Transformarea digitală
Buget:
11.89 milioane euro
Jaloane/Ținte
Numar secvențial:
142
Termen:
2021 T4
Jaloane:
Intrarea în vigoare a Ordinului ministerial de instituire a grupului operativ
Ținte:
Unitate Măsură:
Referință:
Obiectiv:
Descriere:
Operaționalizarea unei unități temporare de management al programelor de transformare digitală, care va angaja, în perioada de punere în aplicare a Planului de redresare și reziliență, 17 agenți contractuali cu înaltă specializare în domeniul tehnologiilor digitale și al managementului de proiect de specialitate. Atribuțiile principale ale acestei unități sunt:
-elaborarea și punerea în aplicare a componentelor sectoriale ale Planului național de redresare și reziliență;
-monitorizarea punerii în aplicare a reformelor și a investițiilor din cadrul Planului național de redresare și reziliență legate de domeniul digital, cu accent pe proiectele-cheie, și propunerea de măsuri imediate de remediere pentru elementele critice, în strânsă colaborare cu celelalte instituții implicate;
-elaborarea de sisteme de management al performanței proiectelor în corelare cu
obiective specifice ale pilonului digital;
-elaborarea și reglementarea cadrului normativ, metodologic și a procedurilor
funcționale, operaționale și financiare în domeniul său de activitate;
-dezvoltarea instrumentelor pentru punerea în aplicare a politicilor legate de domeniul digital;
-managementul proiectelor și raportările stadiilor de îndeplinire a obiectivelor stabilite în cadrul măsurilor digitale din Planul național de redresare și reziliență;
-îndeplinirea oricăror atribuții necesare pentru asigurarea implementării investițiilor și reformelor din Planul național de redresare și reziliență legate de domeniul digital.
Unitatea va fi coordonată de un director subordonat ministrului care deține portofoliul digitalizării.
Observații:
Jalon îndeplinit ulterior termenului din PNRR
***
Analiza noastră: Investiția în cloud-ul guvernamental este una dintre cele mai importante dar și mai dificile din tot PNRR. Ideea de bază a deciziei noastre de a include cloud-ul în PNRR a fost de a sparge cercul vicios al investițiilor în digitalizarea statului care nu fac decât să aducă la zi insulele digitale: fiecare instituție și-a făcut de capul său propriile sisteme informatice. Acesta este motivul real pentru care încă mai cărăm informația pe hârtie între diverse instituții ale statului. Până nu vom avea acest cloud guvernamental, toată vorbăria politică despre birocratizare este apă de ploaie. A face însă un cloud este complicat și e un proiect major, care a pus probleme unor state mai avansate. Deși intenția noastră politică a fost clară, am întâmpinat problema uriașă a lipsei unui proiect tehnic. Nimeni nu a lucrat în ultimii ani să livreze un proiect care să spună clar: unde, cine, cum se leagă actualele baze de date. Am obținut din partea Comisiei Europene, prin negocieri politice, o uriașă concesie: să includem cloudul în PNRR și să dezvoltăm proiectul în cadrul PNRR.În ce a constat concesia: în primele șase luni se constituie o echipă tehnică (finanțată din PNRR – aceasta este asistență tehnică acceptată de Comisie tot ca excepție, este ceea ce PSD și diverși manipulatori numesc ”consultanță)”. Acest task force face tot proiectul și opțiunile în primele șase luni.Task force-ul a fost constituit printr-un HG propus de Ministerul Cercetării, Inovării și Digitalizării, trimis în circuitul de avizare în 27 decembrie și aprobat de Guvern în 30 decembrie 2021. Dat fiind că jalonul vorbește și despre operationalizarea task force-ului nu poate fi considerat îndeplinit prin simpla adoptare a HG-ului. Guvernul are însă timp să operaționalizeze efectiv acest task force până la scrierea cererii de plată viitoare. Acesta este motivul pentru care am notat cu portocaliu. Problema de fond este că actuala întârziere poate duce la întârzierea livrabilului major și urgent: analiza de opțiuni și proiectul pentru cloud. O întârziere duce la alta și constituirea în sine a echipei este de facto doar un jalon intermediar și ajutător pentru cel mai important: proiectul (jalonul 143 care trebuie făcut până în martie 2022). ESTE URGENT.
Stare:
Îndeplinit
Achiziții:
Beneficiar:
Responsabil:
MCID
Numar secvențial:
143
Termen:
2022 T1
Jaloane:
Prezentarea raportului de realizare, cu evaluările și recomandările aferente
Ținte:
Unitate Măsură:
Referință:
Obiectiv:
Descriere:
Analiza va prezenta:
-opțiunile strategice și tehnologice și pachetul legislativ și de reglementare pentru stabilirea realizării cloud-ului guvernamental, cu includerea normelor de interoperabilitate și modelului de guvernanță a datelor guvernamentale;
-posibilitățile de construcție, livrare, instalare și funcționare a infrastructurilor civile și tehnologice conform termenelor prevăzute în plan;
-inventarierea aplicațiilor/serviciilor digitale publice oferite în prezent de autoritățile publice, designul proceselor și procedurilor implementate în producție și/sau aflate în stadii de implementare;
planul de dezvoltare/migrare în cloud a aplicațiilor inventariate.
Observații:
Jalon îndeplinit ulterior termenului din PNRR
***
Cloud-ul guvernamental este unul dintre cele mai mari și complexe proiecte pentru administrația românească. Este un proiect de o anvergură fără precedent pentru statul român, care a pus probleme și altor state.
Faptul că avem Cloud-ul guvernamental în PNRR este un succes politic pe care l-am obținut în timpul negocierilor cu Comisia Europeană. Un succes comparabil cu alocarea uriașă pe care am obținut-o pentru transport și în special pentru transportul rutier, adică pentru autostrăzi.
În PNRR, Comisia a cerut statelor membre să propună proiecte mature, adică proiecte care sunt măcar într-o fază incipientă de pregătire. În aceste condiții, cloud-ul guvernamental era greu de acceptat la acel moment pentru că, deși absolut necesar, nu aveam niciun proiect tehnic pentru că nu se lucrase anterior pentru acest obiectiv în guvern. Am reușit totuși să obținem acordul Comisiei pentru a-l finanța – peste 550 de milioane de euro – cu concesia de a ne da 6 luni pentru a pregăti proiectul. Pentru a pregăti șantierul, așa cum spunem noi.
A fost o concesie obținută pentru că eram o echipă credibilă.
Pe scurt: ce ar fi trebuit să urmeze?
a. o echipă funcțională care să facă proiectul (jalon 31 decembrie 2021)
b. analiza de opțiuni care să clarifice proiectul – cum arată exact, ce încorporează din IT-ul existent la stat, cine îl face? (jalon 31 martie 2022)
c. contractarea proiectului de cloud (jalon trimestrul 2 2022)
Etapele a și b sunt acum ratate.
A trebuit să explicăm foarte detaliat oficialilor de la Bruxelles despre nevoia de a sparge cercul vicios al investițiilor în digitalizarea statului de până acum, care nu a făcut decât să creeze insule digitale în administrație, fiecare zonă de administrație cu sistemul său care nu comunică cu celelalte. Despre nevoia românilor de a scăpa de povara căratului de hârtii între instituții impotente să folosească digitalizarea în favoarea noastră și a ei.
Pentru a pregăti proiectul, aveam însă nevoie de specialiști de top. Este aproape imposibil să îi găsim în administrația centrală și este explicabil că este așa: 1) nu avem cloud și deci nici experiență în domeniu și 2) salariile oferite în sistemul public sunt net necompetitive față de cele de pe piața privată.
Această problemă trebuia să o rezolvăm cu Jalonul 142 care avea termen T4 2021: să formăm o echipă de specialiști. Guvernul a aprobat un HG propus de Ministerul Cercetării, Inovării și Digitalizării, pentru înființarea task force-ului responsabil cu cloud-ul guvernamental. Am atras atunci atenția că scopul japonului era ca echipă să fie operațională, nu doar să existe decizia oficială ca ea să existe.
MCID a decis ulterior să includă cele 17 posturi ale echipei în structura ministerului și nu să creeze o unitate temporară în afara acestuia. Acest lucru însemna că acești 17 specialiști trebuiau plătiți conform grilei de salarizare din administrația publică, motiv pentru care s-au întors la problema pe care încercau să o rezolve: nu s-au găsit specialiști pentru că posturile erau plătite sub valoarea de piață a unor specialiști atât de nișați. Doar câteva posturi au fost ocupate, iar în luna martie a fost pregătit un OUG care să dea libertatea MCID să le ofere acestora salarii mai mari. La sfârșitul lunii martie, din cele 17 posturi ale task force-ului doar 10 erau ocupate.
Această echipă avea misiunea de a îndeplini cel de-al doilea jalon legat de Cloud-ul guvernamental, 144, care presupunea prezentarea unei analize a opțiunilor privind arhitectura cloud-ului guvernamental, mai pe scurt planul și opțiunile pe care le avem pentru a construi cloud-ul guvernamental. Mai exact, să facă proiectul de cloud.
MCID, prin Autoritatea pentru Digitalizarea României (ADR) a lucrat din timp la anumite componente ale analizei – de exemplu la realizarea unei inventarieri a tuturor soluțiilor digitale și software folosite de instituții ale administrației publice, cerință expresă în jalonul 143. Ulterior, ADR trebuie să integreze această parte și să prezinte planul complet (și mult mai complex) de dezvoltare/migrare în cloud a aplicațiilor inventariate.
Fără un proiect, MCID s-a grăbit să împartă cloud-ul cu STS și SRI prin OUG
În schimb, MCID a pus, la data de 16 martie, în dezbatere publică, o ”Ordonanță de Urgență privind unele măsuri pentru sistemul de guvernanță al Cloud-ului Guvernamental[4]”. Acest OUG (nu în forma prezentată de MCID) este unul necesar, cerut de următorul jalon aferent cloud-ului (T2 2022), dar lipsit de logică în contextul în care acesta ar fi trebuit construit pe concluziile analizei de la jalonul 143.
Ordonanța de Urgență pusă în dezbatere ridică o serie de probleme privind guvernanța și a stârnit foarte multe reacții negative din partea specialiștilor și a mediului privat. OUG-ul împarte practic între trei instituții – Autoritatea pentru Digitalizarea României (ADR), aflată în subordinea MCID, Serviciul de Telecomunicații Speciale (STS) și Serviciul Român de Informații (SRI) – domeniile de dezvoltare și management al Cloud-ului guvernamental.
Dacă în ceea ce privește securitatea și mentenanța sistemelor informatice și de infrastructură, rolul STS și al SRI este în concordanță cu statutul acestora și poate fi justificat, ordonanța ridică numeroase probleme:
Piața privată (și competitivă), distorsionată de stat. Potrivit formei puse în dezbatere, ADR “primește” controlul pe partea de SaaS (Software as a Service) din componența Cloud-ului. ADR ar trebui inclusiv să dezvolte software pentru cloud-ul guvernamental (sau să rescrie software pentru a-l face compatibil cu soluții de tip cloud – partea de migrare în Cloud). Centralizarea tuturor achizițiilor de software la nivelul ADR ridică numeroase semne de întrebare, pe care ordonanța nu le clarifică: ADR capătă practic o putere discreționară prin care poate influența piața de IT. În lipsa unor reguli clare în ceea ce privește specificațiile tehnice, de securitate etc și accesul aplicațiilor în cloud-ul guvernamental, dezvoltatorii privați se tem că accesul va fi controlat, în mod discreționar, de către ADR. Asta înseamnă că, de exemplu, dacă există două aplicații de conferințe video cu specificații tehnice, de securitate și performanță identice, am putea ajunge în situația ca ADR-ul să autorizeze folosirea doar a uneia dintre acestea și să impună astfel instituțiilor să o folosească doar pe aceasta.
Statul vrea să fie proprietar pe soft. O altă prevedere care ridică semne de întrebare se referă la faptul că OUG prevede ca toate aplicaţiile integrate în cloud să fie în proprietatea publică a statului. Asta înseamnă să sari din loc în puț. Statul român are o tradiție proastă în a intra în contracte IT închise, adică unde instituția nu are niciun drept pe soft și depinde complet de contractor. Faptul că firmele erau multe ale lui Sebastian Ghiță, om important în PSD și aflat sub protecția SRI pe care îl controla din Parlament, e un factor agravant dar care explică slăbiciunea sistemică a statului. Am interzis în 2016 prin OUG contractele IT unde instituțiile să nu aibă acces la codul sursă. Dar acolo vorbim despre softuri folosite de către instituții. Cloud-ul este doar o platformă pe care se poate urca o aplicație pe care instituția Y o poate folosi (sau nu, poate alege un concurent).
Să fii atât de restrictiv cu cei care vor să urce pe platformă e prea mult.
Statul crede că poate concura cu privații specializați în soluții de tip cloud. Același stat, care nu a fost capabil să dezvolte digitalizarea administrației pe bucăți, își asumă acum să dezvolte cel mai amplu proiect de digitalizare. STS (care nu are asemenea atribuții), în ciuda rezultatelor bune în unele proiecte, nu are specialiști și experiența pentru a dezvolta și administra infrastructura de bază a Cloud-ului și mai ales nu are experiența dezvoltării unor soluții de tipul PaaS (Platformă ca serviciu) necesare procesării datelor din cloud. State mult mai dezvoltate decât România au avut probleme în implementarea unor proiecte asemănătoare. În loc să încercăm să reinventăm noi roata, statul ar trebui să caute soluții în piața privată internațională, singura care are experiență în dezvoltarea unor proiecte asemănătoare.
Nu sunt clarificate aspecte esentiale asumate în jalonul 143, ceea ce pune sub semnul întrebării întreaga foaie de parcurs a acestui proiect: lipsesc normele de interconectare, lipsește modul de guvernanta al datelor guvernamentale, lipsește planul de migrare în cloud a aplicațiilor inventariate.
Marcel Boloș, ministrul cercetării, inovării și digitalizării din guvernul Ciucă, încerca să explice situația în care ne aflăm[5] cu dezvoltarea cloud-ului guvernamental.
„Guvernul este proprietarul terenului și beneficiarul construcției contractate prin PNRR în care vor locui atât cetățeanul, cât și funcționarul public. Funcționalitatea camerelor este asigurată de ADR care reflectă nevoile și dorințele beneficiarilor, pentru că fiecare cameră din casa Cloud-ului guvernamental reprezintă câte o instituție a administrației publice centrale – ministere, autorități. Construcția și instalațiile, practic tot ce nu se vede, dar este esențial pentru calitatea și durata de viață a construcției, poate fi asigurat de o instituție cu expertiză națională în administrarea echipamentelor hardware, iar siguranța și protecția anti-efracție de o instituție cu înaltă calificare în securitatea cibernetică. Dar partea care transformă cu adevărat o casă în acasă, deci ce însuflețește o construcție prin design și prin furnizarea de bunuri și servicii, trebuie să revină mediului privat. Ca reprezentant al Guvernului României, deci proprietar al casei, nu vreau să creez premisele prin care să se poată cumpăra doar cele mai scumpe soluții, ci pe cele mai funcționale din zona privată”.
O metaforă interesantă, dar inexactă. Construcția de care vorbește Boloș nu este o simplă clădire ca atâtea altele, ci este un tip de castel, așa cum nimeni de pe la noi din ținut nu a mai construit vreodată. Nu am mai construit un asemenea castel până acum și am avea nevoie de cineva care a mai construit să ne ajute să facem planul construcției. Ministerul condus de Boloș tocmai asta nu a făcut, planul castelului, dar s-a apucat deja să împartă camerele. Nu știm ce fel de materiale ne vor trebui, unde punem ușa și ferestrele, ce instrumente și scule sunt necesare, nici măcar cine va dormi în castel și ce poate să facă pe acolo, dar știm, prin OUG, că STS și SRI sunt diriginți de șantier. Până acum, STS, prin consultarea organizată, nu a făcut decât să întrebe la meșterii din sat care au cărămizi, care au ciment, care au scule. N-o să ne iasă castel.
Concluzie
Cloud-ul guvernamental a fost cel mai discutat subiect în guvern (și în coaliție) în zilele de dinainte de termenul limită al T1 2022. Pe 30 martie, într-o conferință de presă la sediul guvernului, ministrul Vîlceanu (reamintim, MIPE este coordonator pe PNRR) anunța că vor fi două jaloane care vor fi întârziate: acesta și jalonul 189 (vezi mai jos, tot la MCID). A doua zi, chiar pe 31 martie, la ora 10 seara, MCID anunță că și-a rezolvat jalonul, inclusiv acesta pe cloud.
Există un comunicat oficial care anunță finalizarea analizei, dar ea nu este prezentată. Din informațiile noastre, analiza nu a ajuns în termen la MIPE, nici până la ora redactării acestui raport.
Există o analiză realizată de STS în urma unei licitații publice (lansată în SEAP la începutul lunii) care prezintă soluțiile tehnice de implementare a infrastructurii TIC și de securitate ale Cloud-ului Guvernamental, realizate în urma unei consultări a pieței. “Această consultare a pieței precede procedurile de achiziție având ca scop implementarea infrastructurii TIC și de securitate ale Cloud-ului Guvernamental la nivel IaaS și PaaS și nu se substituie procesului de selecție”, se precizează în document, cu referire la următorul jalon din PNRR legat de cloud, 173 C7 I1 Semnarea contractului de implementare a investiției pe baza procedurii de ofertare pentru implementarea investiției, dar nu se poate substitui analizei cerute de jalonul 143.
Considerăm jalonul cel puțin întârziat. Cei de la minister trebuie să înțeleagă faptul că analiza cerută este esențială, în forma cerută de Comisie. A fost dificil să îi convingem să finanțăm acest proiect prin PNRR și vor să vadă că știm ce vrem să facem.
La toamnă trebuie ca achiziția pentru cloud să fie finalizată. Șantierul este prost organizat.
Faptul că avem Cloud-ul guvernamental în PNRR este un succes politic pe care l-am obținut în timpul negocierilor cu Comisia Europeană. Un succes comparabil cu alocarea uriașă pe care am obținut-o pentru transport și în special pentru transportul rutier, adică pentru autostrăzi.
În PNRR, Comisia a cerut statelor membre să propună proiecte mature, adică proiecte care sunt măcar într-o fază incipientă de pregătire. În aceste condiții, cloud-ul guvernamental era greu de acceptat la acel moment pentru că, deși absolut necesar, nu aveam niciun proiect tehnic pentru că nu se lucrase anterior pentru acest obiectiv în guvern. Am reușit totuși să obținem acordul Comisiei pentru a-l finanța – peste 550 de milioane de euro – cu concesia de a ne da 6 luni pentru a pregăti proiectul. Pentru a pregăti șantierul, așa cum spunem noi.
A fost o concesie obținută pentru că eram o echipă credibilă.
Pe scurt: ce ar fi trebuit să urmeze?
a. o echipă funcțională care să facă proiectul (jalon 31 decembrie 2021)
b. analiza de opțiuni care să clarifice proiectul – cum arată exact, ce încorporează din IT-ul existent la stat, cine îl face? (jalon 31 martie 2022)
<
c.contractarea proiectului de cloud (jalon trimestrul 2 2022)
Etapele a și b sunt acum ratate.
A trebuit să explicăm foarte detaliat oficialilor de la Bruxelles despre nevoia de a sparge cercul vicios al investițiilor în digitalizarea statului de până acum, care nu a făcut decât să creeze insule digitale în administrație, fiecare zonă de administrație cu sistemul său care nu comunică cu celelalte. Despre nevoia românilor de a scăpa de povara căratului de hârtii între instituții impotente să folosească digitalizarea în favoarea noastră și a ei.
Pentru a pregăti proiectul, aveam însă nevoie de specialiști de top. Este aproape imposibil să îi găsim în administrația centrală și este explicabil că este așa: 1) nu avem cloud și deci nici experiență în domeniu și 2) salariile oferite în sistemul public sunt net necompetitive față de cele de pe piața privată.
Această problemă trebuia să o rezolvăm cu Jalonul 142 care avea termen T4 2021: să formăm o echipă de specialiști. Guvernul a aprobat un HG propus de Ministerul Cercetării, Inovării și Digitalizării, pentru înființarea task force-ului responsabil cu cloud-ul guvernamental. Am atras atunci atenția că scopul japonului era ca echipă să fie operațională, nu doar să existe decizia oficială ca ea să existe.
MCID a decis ulterior să includă cele 17 posturi ale echipei în structura ministerului și nu să creeze o unitate temporară în afara acestuia. Acest lucru însemna că acești 17 specialiști trebuiau plătiți conform grilei de salarizare din administrația publică, motiv pentru care s-au întors la problema pe care încercau să o rezolve: nu s-au găsit specialiști pentru că posturile erau plătite sub valoarea de piață a unor specialiști atât de nișați. Doar câteva posturi au fost ocupate, iar în luna martie a fost pregătit un OUG care să dea libertatea MCID să le ofere acestora salarii mai mari. La sfârșitul lunii martie, din cele 17 posturi ale task force-ului doar 10 erau ocupate.
Această echipă avea misiunea de a îndeplini cel de-al doilea jalon legat de Cloud-ul guvernamental, 144, care presupunea prezentarea unei analize a opțiunilor privind arhitectura cloud-ului guvernamental, mai pe scurt planul și opțiunile pe care le avem pentru a construi cloud-ul guvernamental. Mai exact, să facă proiectul de cloud.
MCID, prin Autoritatea pentru Digitalizarea României (ADR) a lucrat din timp la anumite componente ale analizei – de exemplu la realizarea unei inventarieri a tuturor soluțiilor digitale și software folosite de instituții ale administrației publice, cerință expresă în jalonul 143. Ulterior, ADR trebuie să integreze această parte și să prezinte planul complet (și mult mai complex) de dezvoltare/migrare în cloud a aplicațiilor inventariate.
Fără un proiect, MCID s-a grăbit să împartă cloud-ul cu STS și SRI prin OUG
În schimb, MCID a pus, la data de 16 martie, în dezbatere publică, o ”Ordonanță de Urgență privind unele măsuri pentru sistemul de guvernanță al Cloud-ului Guvernamental[4]”. Acest OUG (nu în forma prezentată de MCID) este unul necesar, cerut de următorul jalon aferent cloud-ului (T2 2022), dar lipsit de logică în contextul în care acesta ar fi trebuit construit pe concluziile analizei de la jalonul 143.
Ordonanța de Urgență pusă în dezbatere ridică o serie de probleme privind guvernanța și a stârnit foarte multe reacții negative din partea specialiștilor și a mediului privat. OUG-ul împarte practic între trei instituții – Autoritatea pentru Digitalizarea României (ADR), aflată în subordinea MCID, Serviciul de Telecomunicații Speciale (STS) și Serviciul Român de Informații (SRI) – domeniile de dezvoltare și management al Cloud-ului guvernamental.
Dacă în ceea ce privește securitatea și mentenanța sistemelor informatice și de infrastructură, rolul STS și al SRI este în concordanță cu statutul acestora și poate fi justificat, ordonanța ridică numeroase probleme:
Piața privată (și competitivă), distorsionată de stat. Potrivit formei puse în dezbatere, ADR “primește” controlul pe partea de SaaS (Software as a Service) din componența Cloud-ului. ADR ar trebui inclusiv să dezvolte software pentru cloud-ul guvernamental (sau să rescrie software pentru a-l face compatibil cu soluții de tip cloud – partea de migrare în Cloud). Centralizarea tuturor achizițiilor de software la nivelul ADR ridică numeroase semne de întrebare, pe care ordonanța nu le clarifică: ADR capătă practic o putere discreționară prin care poate influența piața de IT. În lipsa unor reguli clare în ceea ce privește specificațiile tehnice, de securitate etc și accesul aplicațiilor în cloud-ul guvernamental, dezvoltatorii privați se tem că accesul va fi controlat, în mod discreționar, de către ADR. Asta înseamnă că, de exemplu, dacă există două aplicații de conferințe video cu specificații tehnice, de securitate și performanță identice, am putea ajunge în situația ca ADR-ul să autorizeze folosirea doar a uneia dintre acestea și să impună astfel instituțiilor să o folosească doar pe aceasta.
Statul vrea să fie proprietar pe soft. O altă prevedere care ridică semne de întrebare se referă la faptul că OUG prevede ca toate aplicaţiile integrate în cloud să fie în proprietatea publică a statului. Asta înseamnă să sari din loc în puț. Statul român are o tradiție proastă în a intra în contracte IT închise, adică unde instituția nu are niciun drept pe soft și depinde complet de contractor. Faptul că firmele erau multe ale lui Sebastian Ghiță, om important în PSD și aflat sub protecția SRI pe care îl controla din Parlament, e un factor agravant dar care explică slăbiciunea sistemică a statului. Am interzis în 2016 prin OUG contractele IT unde instituțiile să nu aibă acces la codul sursă. Dar acolo vorbim despre softuri folosite de către instituții. Cloud-ul este doar o platformă pe care se poate urca o aplicație pe care instituția Y o poate folosi (sau nu, poate alege un concurent).
Să fii atât de restrictiv cu cei care vor să urce pe platformă e prea mult.
Statul crede că poate concura cu privații specializați în soluții de tip cloud. Același stat, care nu a fost capabil să dezvolte digitalizarea administrației pe bucăți, își asumă acum să dezvolte cel mai amplu proiect de digitalizare. STS (care nu are asemenea atribuții), în ciuda rezultatelor bune în unele proiecte, nu are specialiști și experiența pentru a dezvolta și administra infrastructura de bază a Cloud-ului și mai ales nu are experiența dezvoltării unor soluții de tipul PaaS (Platformă ca serviciu) necesare procesării datelor din cloud. State mult mai dezvoltate decât România au avut probleme în implementarea unor proiecte asemănătoare. În loc să încercăm să reinventăm noi roata, statul ar trebui să caute soluții în piața privată internațională, singura care are experiență în dezvoltarea unor proiecte asemănătoare.
Nu sunt clarificate aspecte esentiale asumate în jalonul 143, ceea ce pune sub semnul întrebării întreaga foaie de parcurs a acestui proiect: lipsesc normele de interconectare, lipsește modul de guvernanta al datelor guvernamentale, lipsește planul de migrare în cloud a aplicațiilor inventariate.
Marcel Boloș, ministrul cercetării, inovării și digitalizării din guvernul Ciucă, încerca să explice situația în care ne aflăm[5] cu dezvoltarea cloud-ului guvernamental.
„Guvernul este proprietarul terenului și beneficiarul construcției contractate prin PNRR în care vor locui atât cetățeanul, cât și funcționarul public. Funcționalitatea camerelor este asigurată de ADR care reflectă nevoile și dorințele beneficiarilor, pentru că fiecare cameră din casa Cloud-ului guvernamental reprezintă câte o instituție a administrației publice centrale – ministere, autorități. Construcția și instalațiile, practic tot ce nu se vede, dar este esențial pentru calitatea și durata de viață a construcției, poate fi asigurat de o instituție cu expertiză națională în administrarea echipamentelor hardware, iar siguranța și protecția anti-efracție de o instituție cu înaltă calificare în securitatea cibernetică. Dar partea care transformă cu adevărat o casă în acasă, deci ce însuflețește o construcție prin design și prin furnizarea de bunuri și servicii, trebuie să revină mediului privat. Ca reprezentant al Guvernului României, deci proprietar al casei, nu vreau să creez premisele prin care să se poată cumpăra doar cele mai scumpe soluții, ci pe cele mai funcționale din zona privată”.
O metaforă interesantă, dar inexactă. Construcția de care vorbește Boloș nu este o simplă clădire ca atâtea altele, ci este un tip de castel, așa cum nimeni de pe la noi din ținut nu a mai construit vreodată. Nu am mai construit un asemenea castel până acum și am avea nevoie de cineva care a mai construit să ne ajute să facem planul construcției. Ministerul condus de Boloș tocmai asta nu a făcut, planul castelului, dar s-a apucat deja să împartă camerele. Nu știm ce fel de materiale ne vor trebui, unde punem ușa și ferestrele, ce instrumente și scule sunt necesare, nici măcar cine va dormi în castel și ce poate să facă pe acolo, dar știm, prin OUG, că STS și SRI sunt diriginți de șantier. Până acum, STS, prin consultarea organizată, nu a făcut decât să întrebe la meșterii din sat care au cărămizi, care au ciment, care au scule. N-o să ne iasă castel.
Concluzie
Cloud-ul guvernamental a fost cel mai discutat subiect în guvern (și în coaliție) în zilele de dinainte de termenul limită al T1 2022. Pe 30 martie, într-o conferință de presă la sediul guvernului, ministrul Vîlceanu (reamintim, MIPE este coordonator pe PNRR) anunța că vor fi două jaloane care vor fi întârziate: acesta și jalonul 189 (vezi mai jos, tot la MCID). A doua zi, chiar pe 31 martie, la ora 10 seara, MCID anunță că și-a rezolvat jalonul, inclusiv acesta pe cloud.
Există un comunicat oficial care anunță finalizarea analizei, dar ea nu este prezentată. Din informațiile noastre, analiza nu a ajuns în termen la MIPE, nici până la ora redactării acestui raport.
Există o analiză realizată de STS în urma unei licitații publice (lansată în SEAP la începutul lunii) care prezintă soluțiile tehnice de implementare a infrastructurii TIC și de securitate ale Cloud-ului Guvernamental, realizate în urma unei consultări a pieței. “Această consultare a pieței precede procedurile de achiziție având ca scop implementarea infrastructurii TIC și de securitate ale Cloud-ului Guvernamental la nivel IaaS și PaaS și nu se substituie procesului de selecție”, se precizează în document, cu referire la următorul jalon din PNRR legat de cloud, 173 C7 I1 Semnarea contractului de implementare a investiției pe baza procedurii de ofertare pentru implementarea investiției, dar nu se poate substitui analizei cerute de jalonul 143.
Considerăm jalonul cel puțin întârziat. Cei de la minister trebuie să înțeleagă faptul că analiza cerută este esențială, în forma cerută de Comisie. A fost dificil să îi convingem să finanțăm acest proiect prin PNRR și vor să vadă că știm ce vrem să facem.
La toamnă trebuie ca achiziția pentru cloud să fie finalizată. Șantierul este prost organizat.
Stare:
Îndeplinit
Achiziții:
Beneficiar:
Responsabil:
MCID, ADR si instituțiile responsabile in domeniu
Numar secvențial:
144
Termen:
2022 T2
Jaloane:
Dispoziție legală care indică intrarea în vigoare a Legii privind guvernanța serviciilor de cloud
Ținte:
Unitate Măsură:
Referință:
Obiectiv:
Descriere:
Noua lege va stabili cadrul general pentru dezvoltarea și gestionarea unei infrastructuri de cloud constând într-un set de resurse și servicii din domeniul tehnologiei informației, comunicațiilor și securității cibernetice, partajate de sectorul public în conformitate cu Strategia europeană privind cloud computingul și aliniată la Cadrul național de interoperabilitate.
Observații:
Noul ministru al Cercetării, Inovării și Digitaizării, Sebastian Burduja, și-a început mandatul, acum două luni, plângându-se de termenele strânse din PNRR. Oarecum haotic la început – un alt exemplu de ministru care citește prima dată documentele din PNRR, nu înțelege și apoi se plânge că nu e bun – Burduja și ministerul său au reușit să țină în dezbatere publică și să și modifice proiectul ordonanței de urgență[2] privind guvernanța Cloudului Guvernamental.
Concluzie
Considerăm jalonul îndeplinit. Există îngrijorări legitime legate de accesul serviciilor secrete la datele personale stocale în cloud și noua ordonanță nu le-a rezolvat, dimpotrivă, le-a accentuat. Nu este menționat acest aspect în PNRR, dar Comisia Europeană se va afla în fața unei dileme interesante: jalonul este îndeplinit pe ce scrie în el propriu zis, dar implementarea poate afecta alte acte normative europene și rămâne de decis dacă va lua în considerare acest aspect în evaluarea viitoare a acestui jalon.
Cloud-ul guvernamental este proietul major din PNRR care a avut cele mai mari probleme, încurajăm recuperarea timpilor pierduți. În final, în iunie, a fost în sfârșit operaționalizat task force-ul pentru Transformare Digitală de la minister – era un jalon pe roșu încă din 2021.
Concluzie
Considerăm jalonul îndeplinit. Există îngrijorări legitime legate de accesul serviciilor secrete la datele personale stocale în cloud și noua ordonanță nu le-a rezolvat, dimpotrivă, le-a accentuat. Nu este menționat acest aspect în PNRR, dar Comisia Europeană se va afla în fața unei dileme interesante: jalonul este îndeplinit pe ce scrie în el propriu zis, dar implementarea poate afecta alte acte normative europene și rămâne de decis dacă va lua în considerare acest aspect în evaluarea viitoare a acestui jalon.
Cloud-ul guvernamental este proietul major din PNRR care a avut cele mai mari probleme, încurajăm recuperarea timpilor pierduți. În final, în iunie, a fost în sfârșit operaționalizat task force-ul pentru Transformare Digitală de la minister – era un jalon pe roșu încă din 2021.
Stare:
Îndeplinit
Achiziții:
Beneficiar:
Responsabil:
MCID
Numar secvențial:
145
Termen:
2022 T2
Jaloane:
Dispoziție legală care indică intrarea în vigoare a Legii privind interoperabilitatea
Ținte:
Unitate Măsură:
Referință:
Obiectiv:
Descriere:
Noua lege:
-va fi aliniată la dispozițiile Cadrului european de interoperabilitate[ https://ec.europa.eu/isa2/sites/default/files/eif_brochure_final.pdf];
-va institui un cadru/o guvernanță pentru sprijinirea alegerii standardelor și normelor relevante pentru dezvoltarea aplicațiilor și serviciilor de către sectorul public într-un mediu sigur și durabil;
-va operaționaliza migrarea și integrarea în structurile de date existente, asigurând în același timp interoperabilitatea;
-va asigura faptul că punerea în aplicare a funcționalităților implică alinierea infrastructurilor naționale de identificare și autorizare la cele ale statelor membre ale UE în cadrul unui sistem transnațional, în conformitate cu normele europene prevăzute în Regulamentul (UE) 2014/910 privind identificarea electronică și serviciile de încredere pentru tranzacțiile electronice pe piața internă (eIDAS);
va lua în considerare principiul „doar o singură dată” încorporat în Regulamentul (UE) 2018/1724 privind portalul digital unic.
Observații:
Legea interoperabilității a fost aprobată în Parlament cu o zi înainte de termenul limită.
O altă lege din proiectul Cloud-ului Guvernamental care va mai fi probabil modificată în urma discuțiilor cu Comisia. Considerăm din acest motiv jalonul îndeplinit.
O altă lege din proiectul Cloud-ului Guvernamental care va mai fi probabil modificată în urma discuțiilor cu Comisia. Considerăm din acest motiv jalonul îndeplinit.
Stare:
Îndeplinit
Achiziții:
Beneficiar:
Responsabil:
MCID