Poziție în cadrul consultării publice - HUB de Servicii MMPS - SII MMPS

Conceptul de MVP (minimum viable product) nu trebuie asociat niciodată cu ideea de ”măcar există”, mai ales dacă ne referim la sisteme critice pentru cetățean. Când vorbim de servicii publice digitale este important ca acestea nu doar să răspundă unei nevoi, ci să țină cont de un set de standarde obligatorii și de bune practici pentru a deservi întreaga populație. Așadar, atunci când construim un sistem informatic în spațiul public trebuie să ne asigurăm că acesta rezolvă problema, că ține cont de restul peisajului software din cadrul statului român contribuind la îmbunătățirea lui, că este accesibil și incluziv și că nu prezintă vulnerabilități imediat evitabile.

În cele ce urmează, Code for Romania supune atenției o abordare strategică diferită pentru construirea HUB-ul de servicii MMPS - SII MMPS și propune o serie de îmbunătățiri ale caietului de sarcini. Aceste sugestii sunt conturate pornind de la experiența noastră de peste 5 ani în care am proiectat și construit soluții digitale în serviciul cetățeanului român.

A. O ABORDARE STRATEGICĂ ÎN DIGITALIZARE:

CODUL SURSĂ ȘI DOCUMENTAȚIA SERVICIILOR PUBLICE CRITICE TREBUIE SĂ FIE DEȚINUTE DE STAT

Conform caietului de sarcini prezentat în consultare publică de către Ministerul Muncii și Protecției Sociale, soluțiile software care alcătuiesc HUB-ul de servicii MMPS - SII MMPS ar fi contractate sub forma de COTS (Commercial Off the Shelf software). Un sistem COTS presupune existența unor produse software deja dezvoltate care sunt configurate într-o arhitectură care răspunde nevoilor instituției solicitante. Însă, o astfel de soluție înseamnă că instituția nu va deține produsele software componente și nu poate să le reutilizeze sau să le modifice independent de furnizor. Caietul de sarcini face explicită o perioadă determinată în care instituția contractantă poate cere modificări. Dincolo de această perioadă, instituția contractantă trebuie să reînnoiască contractul, altfel pierzând posibilitatea de a cere suport, mentenanță și modificări pentru produsul contractat.

Contractarea COTS are avantajul de a reduce timpul destinat implementării serviciilor software, însă garantează cheltuieli mult mai mari pe termen lung și aduce cu sine o serie de vulnerabilități.

A.1. CONTRACTAREA COTS ÎMPIEDICĂ AUDITAREA INDEPENDENTĂ

Auditarea unui serviciu software este un proces prin care codul sursă, arhitectura sa de sistem și modul de funcționare sunt analizate și evaluate pentru a determina dacă sunt sigure și dacă soluția software răspunde întocmai nevoilor identificate în proiect.

Auditul nu poate fi făcut de către aceeași entitate care a construit serviciul software. Mai mult, pe unele arii, entitatea care a construit un serviciu software nu are întotdeauna contextul să evalueze vulnerabilitățile la atacuri software pe care le-ar putea prezenta sistemul construit. Cunoștințele de protecție a sistemelor sunt diferite de cunoștințele de utilizare ale acestora. Un audit independent ajută și sprijină efortul continuu de menținere și de îmbunătățire a oricărui serviciu software, mai ales atunci când vorbim de sisteme publice critice.

Unele tipuri de audit pot fi realizate fără a cunoaște codul sursă al serviciilor software, însă accesul la acesta oferă auditorilor întreg contextul arhitecturii, permițându-le să identifice vulnerabilități care încă nu s-au manifestat. Un sistem poate să își reducă drastic performanța, sau să nu mai funcționeze, abia după ce anumite condiții au fost atinse, fapt ce nu ar putea să fie detectat fără o inspectare a codului sursă.

Un sistem care nu doar deservește cetățenii, ci ține evidența serviciilor sociale și a ajutorului social pe care statul român le pune la dispoziție este, din punctul de vedere al Code for Romania, un sistem critic. Acest sistem trebuie să ofere posibilitatea unei auditări independente

A.2. SISTEMELE COTS NU POT FI REUTILIZATE ÎN AFARA UNUI CONTRACT PUNCTUAL

Orice efort coerent de digitalizare a serviciilor publice, oriunde în lume, se bazează pe principiul reutilizării. Soluțiile software care deservesc cetățenii trebuie proiectate strategic, astfel încât, o dată construite, ele să poată fi operaționalizate în cât mai multe puncte cheie.

Reutilizarea se manifestă în două moduri:

Un serviciu software, o dată dezvoltat, poate fi operaționalizat în toate instituțiile publice care au nevoie de același set de funcționalități. Spre exemplu, o soluție de management a parcărilor într-un oraș, poate fi construită o singură dată și reutilizată în orice oraș. Astfel, serviciul este unul coerent și pentru cetățean și pentru instituția locală, iar costul dezvoltării va fi achitat o singură dată.
Componente întregi care alcătuiesc un serviciu software pot fi reutilizate pentru a construi alte servicii, care garantează alte seturi de funcționalități, scăzând, astfel, costul lor de producție. Spre exemplu, un modul de construcție și publicare de formulare online poate fi integrat atât într-un website al unei primării, cât și în software-ul serviciului de ambulanță.

Marele avantaj al reutilizării este faptul că, pe termen mediu și lung, diminuează costurile digitalizării (o soluție care deservește toate UAT-urile din România este o investiție mai eficientă decât multiple investiții făcute de fiecare UAT în parte). Pe scurt, nu trebuie să plătim, din bani publici, aceeași soluție de mai multe ori.

Mai mult, Uniunea Europeană a dezvoltat un cadru de recomandări și măsuri sub numele Sharing and Reuse Framework for IT Solutions, al cărui scop este ajutarea și ghidarea administrațiilor publice către o refolosire și redistribuire a soluțiilor software.

Unul din punctele principale ale acestui cadru face referire la a redistribui și a refolosi soluțiile software ca practică de bază și comună, în procesul de digitalizare. Decizia de a nu redistribui și reutiliza trebuie argumentată - această decizie trebuie să devină o excepție de la regulă. Uniunea Europeană încearcă tot mai mult să impună acest principiu țărilor membre, inclusiv prin includerea principiului ca criteriu de finanțare.

Caietul de sarcini detaliază module care au un potențial fantastic de reutilizare. Spre exemplu, componenta de management de documente este utilă oricărei instituții publice centrale sau locale. Această componentă, o dată construită, poate fi reutilizată pentru a fi integrată într-o soluție de management de documente pentru
școli, servicii pentru situații de urgență, biblioteci sau orice altă instituție care operează în mod constant cu documente. Numeroase fluxuri birocratice includ pași de semnare și oficializare a unor acte fizice, tipărite pe hârtie. Un modul de scanare și trecere printr-un proces de OCR și indexare este necesar și util unei instituții care operează cu documente tipărite.

A.3. CONTRACTAREA COTS DUCE LA VENDOR-LOCK

Conceptul de vendor-lock descrie situația în care un cumpărător achiziționează un serviciu software, iar orice intervenție de a repara probleme, de a menține buna sa funcționare sau de a extinde serviciul poate fi prestată doar de acel vânzător. Practic, o instituție publică vendor-locked nu poate apela decât la serviciile unui singur și anume comerciant pentru buna funcționare a unei aplicații, a unui website, a unei componente. Dacă acel comerciant își crește prețurile, își încetează activitatea sau devine indisponibil, instituția este vulnerabilă și lipsită de alternative. De obicei, soluția este aceea de a reface sistemul sau de a cumpăra din nou respectivul sistem de la un alt comerciant disponibil, dacă acesta există.

În absența predării dreptului de proprietate asupra codului sursă, și a unei documentații exhaustive către autoritatea contractantă, serviciul software care face subiectul prezentului caiet de sarcini nu poate fi modificat sau îmbunătățit de către niciun alt furnizor de servicii în afară de cel contractat. Serviciile de mentenanță, într-un astfel de caz, pot fi oferite doar de furnizorul contractat sau de subcontractori ai acestuia. Istoric, aceste practici pot duce la situații de dependență. Mai mult, în astfel de situații, este aproape imposibil pentru orice alt actor privat să își pună serviciile de dezvoltare și mentenanță la dispoziția instituțiilor, ceea ce dezechilibrează foarte mult plaja de opțiuni disponibile, situație care contravine principiilor unei piețe libere. Ajungem astfel, în repetate rânduri, în contexte în care sisteme critice sunt indisponibile pentru cetățeni atunci când aceștia au nevoie de ele, iar instituțiile să fie nevoite să o ia de la început și să cheltuiască alte fonduri pentru dezvoltarea unui sistem identic.

Code for Romania propune ca în urma serviciilor contractate să se facă atât transferul codului sursă, cât și al unei documentații exhaustive ale serviciilor software către instituția contractantă în întregime. Astfel, instituția va dispune de libertatea de a audita, reutiliza și modifica componentele individuale, pentru care o muncă de proiectare și de dezvoltare a fost deja făcută, chiar dacă acest lucru presupune un cost mai mare și o perioadă de implementare mai lungă. Acest transfer asigură pe termen lung o economisire a banului public și o reducere semnificativă a plajei de vulnerabilități.

B. SUGESTII

B.1 OPEN DATA ȘI STANDARDE DE DATE

Caietul de sarcini al HUB-ului de servicii MMPS - SII MMPS face o descriere insuficientă a componentei de date deschise.

Code for Romania propune includerea următoarelor specificații în caietul de sarcini:

Planificarea și bugetarea unei perioade de standardizare a seturilor de date colectate de la toate instituțiile ale căror baze de date vor fi interconectate și/sau preluate.
Standardele de date să fie făcute publice și supuse unei consultări publice.
Menționarea formatelor în care se vor publica datele în portalul de date deschise al HUB-ului de servicii MMPS - SII MMPS. Este foarte important ca aceste seturi de date să poată fi descărcate individual într-unul din formatele de largă circulație (.xlsx, .csv, .json), cât și să poată fi descărcate și filtrate în mod automat și printr un API.
Menționarea frecvenței actualizării seturilor de date și a modului în care acestea vor fi actualizate. În etapa de analiză și proiectare, trebuie clarificat scenariul momentului în care seturile de date vor trebui arhivate, sau dacă se va prefera adăugarea unui spațiu de stocare adițional atunci când spațiul inițial va fi umplut. Dacă seturile de date vor fi arhivate, ele trebuie să fie în continuare accesibile pentru a fi descărcate.
Includerea în caietul de sarcini a unei etape de verificare a datelor și a criteriilor GDPR așa cum ele se aplică acestor date. Datele publice trebuie anonimizate.
Inter-conectarea portalului de date deschise al HUB-ului de servicii MMPS - SII MMPS cu data.gov.ro este un pas necesar, lucru care ar fi extrem de util mediului de date deschise din instituțiile publice din România.

B.2 ACCESIBILIZARE

Directiva EU 2016/2102, transpusă în legislația română prin OUG 112/2018, aprobată prin Legea nr. 90/2019 reglementează standarde obligatorii de accesibilizare a site urilor web şi a aplicaţiilor mobile ale organismelor din sectorul public. Conform art. 5(f)19 al HG 89/2020 controlul respectării acestor standarde cade în obligația Autorității pentru Digitalizarea României.

Mai mult, Articolul 9 din Convenția Europeană a Drepturilor Omului, cere ca accesul persoanelor cu dizabilități la tehnologiile de comunicare și informare, precum este cazul Internetului, să fie garantat și facilitat.

Caietul de sarcini care descrie HUB-ul de servicii MMPS - SII MMPS nu face nicio mențiune asupra criteriilor concrete de accesibilizare pe care trebuie să le asigure toate serviciile din cadrul acestui proiect. Code for Romania recomandă următoarele funcționalități care, o dată adăugate în caietul de sarcini, trebuie să se aplice atât componentelor publice, cât și componentelor interne ale HUB-ului de servicii MMPS - SII MMPS:

Orice componentă trebuie să permită navigarea și utilizarea folosind exclusiv tastatura. Acest lucru permite persoanelor cu abilități locomotorii limitate să acceseze și să folosească componenta cu hardware modificat pentru a se adapta nevoilor sale.
Orice componentă trebuie să permită navigarea și utilizarea folosind un screen reader și comenzi vocale. Acest lucru permite persoanelor cu deficiențe de vedere să acceseze și să folosească soluția.
Orice material video încărcat într-o componentă a HUB-ului, material care este menit să fie urmărit de către utilizator, trebuie să ofere subtitrări complete, astfel încât persoanele cu deficit de auz să poată urmări și înțelege conținutul acestora.

Respectarea acestor standarde este cu atât mai importantă cu cât o parte din beneficiarii HUB-ului de servicii MMPS - SII MMPS sunt persoane cu dizabilități.

B.3 INTERNAȚIONALIZARE

Legea nr. 215 din 25 aprilie 2001, Capitolul I, Secțiunea 1, Articolul 19 susține:

În unitățile administrativ-teritoriale în care cetățenii aparținând minorităților naționale au o pondere de peste 20% din numărul locuitorilor, autoritățile administrației publice locale, instituțiile publice aflate în subordinea acestora, precum și serviciile publice deconcentrate asigură folosirea, în raporturile cu aceștia, și a limbii materne, în conformitate cu prevederile Constituției, ale prezentei legi și ale tratatelor internaționale la care România este parte.

Caietul de sarcini prevede faptul că HUB-ul de servicii MMPS - SII MMPS va fi integral disponibil în limba română, cu diacritice, însă nu menționează traducerea și punerea la dispoziție integrală a HUB-ulul în nici una dintre limbile minorităților naționale.

Caietul de sarcini prevede, de asemenea, integrarea datelor din HUB cu instituții din Uniunea Europeană a căror activitate include aria serviciilor sociale. Această integrare aduce cu sine necesitatea ca seturile de date pe care le publică HUB-ul de servicii MMPS - SII MMPS să fie disponibile și în limbi de înaltă circulație în Uniunea Europeană.

Code for Romania consideră că este absolut necesar ca HUB-ul de servicii MMPS - SII MMPS să fie internaționalizabil, din punct de vedere tehnic. Atât componentele publice, vizibile beneficiarilor, cât și componentele interne, vizibile angajaților instituțiilor publice trebuie să poată fi traduse în întregime.