Piloni

143

2022 T1

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.

Prezentarea raportului de realizare, cu evaluările și recomandările aferente

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.

MCID, ADR si instituțiile responsabile in domeniu