Introducere

Transformarea digitală a administrației publice necesită o abordare sistematică de transpunere a cadrului legal în procese și cerințe tehnice clare. Legile, ordonanțele și alte norme stabilesc proceduri administrative – pași, roluri, condiții și rezultate – care trebuie implementate în sisteme informatice și fluxuri de lucru digitale. Provocarea majoră este cum identificăm elementele esențiale ale unui text legislativ și cum le modelăm în termeni tehnici (diagrame de proces, specificații de sistem), asigurând totodată respectarea strictă a intenției legiuitorului. Acest articol propune o abordare conceptuală și metodologică integrată (juridico-tehnică) pentru a conecta limbajul legal cu limbajul tehnic în cadrul Public Framework – un demers necesar pentru digitalizarea coerentă și „by design” a serviciilor publice.

Vom răspunde pe rând la întrebările-cheie: Cum înțelegem legea și extragem componente relevante pentru arhitectura proceselor? Ce principii juridice și de design instituțional ne ghidează? Cum legăm limbajul normativ (norme, roluri, condiții, excepții, sancțiuni) de modele tehnice (BPMN, use-case, ArchiMate)? Cum transformăm practic un text de lege într-un model de proces sau într-o specificație tehnică? Care este rolul actorilor instituționali în interpretare și validare? Și, în final, ce metodologie integratoare putem propune ca parte a Public Framework pentru formalizarea acestei transpuneri a legislației în cerințe tehnice. În susținerea afirmațiilor, vom include referințe academice din domeniile Legal Engineering, eGovernment și transformare digitală, precum și exemple de bune practici internaționale și locale.

Context și importanța transpunerii legii în procese digitale

În administrația publică, procesele operaționale sunt puternic influențate (deseori chiar determinate) de cadrul legal. O lege privind un anumit serviciu public de facto descrie pașii birocratici, documentele, condițiile și actorii implicați. Astfel, orice reglementare legală care stabilește proceduri reprezintă în esență un sistem de informații de business, putând fi reflectată într-un model de proces formalizat (researchgate.netresearchgate.net). Biernacki (2024) observă în studiul său de caz pe reforma achizițiilor publice că regulile procedurale din lege pot fi transpuse ca diagrame BPMN, unde fiecare instituție devine un participant (pool) în diagrame, iar pașii legali devin activități și fluxuri între acești participanți (researchgate.netresearchgate.net). Această abordare are beneficii semnificative: modelarea precisă în BPMN conferă univocitate reglementării și permite evaluarea efectelor înainte de implementare (researchgate.netresearchgate.net). Cu alte cuvinte, putem simula și analiza digital o procedură legală pentru a identifica ambiguități sau blocaje, înainte ca sistemul informatic să fie dezvoltat efectiv.

Importanța transpunerii corecte a legii în termeni tehnici este subliniată și la nivel internațional prin inițiative de tip “digital-ready legislation”. Danemarca, de exemplu, a introdus principii pentru legislație pregătită pentru era digitală, cerând ca noile legi să fie concepute astfel încât să permită administrare complet sau parțial automată și servicii digitale implicite (en.digst.dken.digst.dk). Unul din aceste principii stipulează că, pentru ca o lege să poată fi implementată ușor în sisteme IT, regulile sale trebuie formulate clar, cu criterii obiective și concepte univoce, minimizând situațiile ce necesită interpretare discreționară umană (en.digst.dken.digst.dk). Acolo unde legea impune totuși un grad de judecată subiectivă (ex. apreciere de oportunitate), autoritățile sunt îndemnate fie să păstreze doar acea etapă ca intervenție umană, fie chiar să revizuiască legislația pentru a o adapta mai bine la procesarea automată (en.digst.dk). Acest exemplu evidențiază legătura directă dintre designul normativ și implementarea tehnologică: dacă legile sunt bine structurate și clare, ele pot fi traduse mai ușor în cerințe tehnice. În schimb, o lege formulată vag sau cu excepții multiple complică semnificativ modelarea proceselor digitale (en.digst.dken.digst.dk).

De asemenea, cadrul european promovează conceptul de „Reguli ca software” (Rules as Code), care presupune ca regulile juridice să fie publicate simultan în format uman și mașin-readable (interoperable-europe.ec.europa.eu). Susținătorii acestei abordări argumentează că scrierea legilor într-un mod direct interpretabil de computere aduce transparență sporită, analiză legislativă mai ușoară și automatizare îmbunătățită a conformității (interoperable-europe.ec.europa.eu). Un raport recent din Australia a evidențiat, de pildă, beneficii cuantificabile: investițiile în transpunerea ca și cod a unor reguli (de exemplu, simplificarea verificării eligibilității pentru reduceri la transportul studențesc, sau automatizarea regulilor de biosecuritate) pot aduce un raport cost/beneficiu de peste 1:2, economisind timp și resurse administrative (interoperable-europe.ec.europa.euinteroperable-europe.ec.europa.eu ). Astfel de rezultate demonstrează că alinierea legislației cu reprezentări tehnice formale nu este doar un exercițiu academic, ci are impact practic în eficientizarea serviciilor publice.

În continuare, vom detalia metodologia propusă – de la analiza textului de lege, la modelarea proceselor BPMN și a cerințelor de sistem – integrând principii juridice și de design instituțional, și vom oferi exemple concrete din România și alte țări.

Interpretarea legii și identificarea componentelor relevante pentru arhitectura de proces

Primul pas în transpunerea oricărei reglementări într-un design digital este studiul aprofundat al textului legal. Scopul este de a extrage conceptele cheie, regulile și principiile ce caracterizează procesele vizate de lege (scispace.comscispace.com). Cherouana și Mahdaoui descriu această etapă ca o „studiere meticuloasă a textelor legale”, necesară pentru a identifica „părțile stabile” ale proceselor, adică elementele impuse clar de lege, care nu pot fi deviate în implementare (scispace.comscispace.com). În această fază, echipa de proiect trebuie să extragă din lege următoarele componente esențiale:

  • Obligațiile și regulile de fond (business rules) – de exemplu condițiile în care un cetățean este eligibil pentru un serviciu, termene legale, formule de calcul ale unor beneficii, sancțiuni aplicabile la nerespectare etc. (scispace.comscispace.com). Aceste norme juridice devin ulterior reguli de business ce trebuie programate sau configurate în software.
  • Rolurile și actorii instituționali – legea definește deseori cine face o acțiune: instituții responsabile, funcționari cu anumite competențe, părți terțe implicate (ex: notar, expert, cetățean, companie). Aceste roluri legale vor fi mapate la actori de proces (swimlane-uri în BPMN, actori în use-case) și eventual la utilizatori ai sistemului cu drepturi specifice.
  • Secvența procedurală și interacțiunile – multe acte normative descriu pașii (explicit sau implicit). De exemplu, „persoana depune o cerere la autoritatea X, care verifică îndeplinirea condițiilor Y, apoi emite un aviz sau solicită completări; în caz de aprobare, se emite documentul final, altfel se poate formula contestație”. Acest fir logic se traduce aproape direct într-un flux BPMN cu activități (depune cerere, verifică, emitere, etc.), decizii (condiții îndeplinite sau nu) și evenimente (primirea cererii, emiterea avizului). Identificarea succesiunii logice din textul legislativ este esențială pentru arhitectura procesului.
  • Excepțiile și cazurile speciale – prevederile care introduc derogări, exceptări sau tratamente diferite („dacă… atunci… altfel dacă…”) trebuie notate ca ramificații în proces. Acestea corespund în modelul tehnic de regulă unor gateway-uri decizionale (în BPMN) sau unor reguli de decizie (pot fi capturate și în tabele de decizie DMN – Decision Model and Notation – dacă se optează pentru separarea logicii decizionale de fluxul principal).
  • Sancțiuni și remedieri – acolo unde legea prevede consecințe (amenzi, suspendări, notificări) în cazul nerespectării unor pași, acestea se traduc în cerințe de monitorizare și alertare în sistem. De exemplu, dacă termenul legal de soluționare este depășit, sistemul poate declanșa notificări către superiori sau poate aplica automat suspendarea cazului, conform legii.

În practică, abordarea combinată a juriștilor și analiștilor de business în această etapă este crucială. Juriștii asigură interpretarea corectă a sensului legal (de ex., ce înseamnă exact „depune o cerere în format scris” – poate include electronic sau nu?), în timp ce analiștii de business sau arhitecții de proces transpun acel sens în termenii obiectului de business și pașilor procesuali. Un principiu util este interpretarea teleologică a legii – înțelegerea scopului urmărit – pentru a decide ce elemente sunt esențiale în arhitectură. De exemplu, dacă scopul legii este reducerea birocrației într-un domeniu, atunci la modelare vom căuta să implementăm „once-only” (să nu cerem aceeași informație de două ori) și să eliminăm punctele de fricțiune, atâta timp cât legea nu le impune în mod expres.

Cherouana & Mahdaoui propun ca rezultatul acestei analize juridice să fie un set de concepte și cerințe extrase care devin fundația procesului digital – aspecte ce nu vor mai fi rediscutate în fazele ulterioare de design (scispace.comscispace.com). Cu alte cuvinte, tot ceea ce „legea cere” devine dat de intrare fix în proiect: rolurile legale, regulile obligatorii, pașii procedurali imperativi se vor reflecta invariabil în diagrama de proces și în specificațiile sistemului. Această fidelitate față de textul legal asigură principiul legalității în designul sistemului – nicio funcționalitate a viitorului software nu va încălca sau omite cerințe legale în vigoare.

Principii juridice și de design instituțional combinate în proiectarea proceselor

Pentru a realiza o digitalizare conformă și eficientă, trebuie să îmbinăm principiile de interpretare juridică cu principiile de design organizațional/instituțional. În această secțiune discutăm câteva astfel de principii combinate, care pot ghida deciziile de arhitectură:

  • Principiul clarității și univocității legii. Din perspectivă juridică, interpretarea literală și sistematică cere ca termenii legii să fie clari și utilizați consecvent. Din perspectivă tehnică, claritatea se traduce prin reguli de decizie bine definite și cazuri distincte de proces. Dacă legea folosește un concept precum „venit al gospodăriei”, trebuie ca definirea lui (cine e inclus în gospodărie, ce se include ca venit) să fie precisă în textul legal – altfel, sistemele diferite ar putea implementa diferit. Danemarca subliniază că „noțiunile trebuie definite clar, neechivoc și în mod uniform” în tot aparatul administrativ (en.digst.dken.digst.dk). Așadar, consistența terminologică impusă juridic (ex: același înțeles al „minor” în toate bazele de date) facilitează interoperabilitatea și reutilizarea datelor între instituții. În proiectare, vom căuta deci glosare comune și vom utiliza aceiași identificatori de date pentru același concept legal în diferite sisteme.
  • Principiul legalității și competenței instituționale. Fiecare act administrativ se bazează pe o competență legală – cine are dreptul să facă acel act. Acest principiu juridic (nimic fără bază legală) se combină cu designul procesului prin maparea corectă a activităților la actorii instituționali corespunzători. În modelul BPMN al procesului, fiecare lane/pool trebuie asociat exact instituției sau funcționarului prevăzut de lege. De exemplu, dacă legea spune că Autoritatea X emite avizul, atunci în procesul modelat doar swimlane-ul Autorității X va conține task-ul „Emitere aviz”, și nu alt actor. Orice flux de aprobare, control sau semnătură electronică din sistem trebuie să reflecte această repartizare a competențelor. Astfel asigurăm că aplicația nu permite, de pildă, ca o altă entitate să emită actul, încălcând legea. Totodată, respectarea competențelor legale implică și design instituțional: dacă un proces digital cere ca mai multe instituții să coopereze (ex: interoperabilitate), trebuie stabilit prin acorduri inter-instituționale cine deține responsabilitatea fiecărui pas și cum se validează datele partajate.
  • Principiul proporționalității și al orientării spre cetățean. Interpretarea teleologică a normelor ne amintește că legile au scopuri (protecția drepturilor, eficiența administrativă etc.), iar designul de proces ar trebui să le împlinească fără a crea sarcini inutile. Un exemplu este principiul once-only promovat la nivelul UE: dacă legea cere anumite informații de la cetățean, instituțiile ar trebui să le obțină, pe cât posibil, din surse existente, nu să le solicite repetat. În practică, asta se traduce prin arhitectură de interoperabilitate (registre partajate) și prin design instituțional colaborativ – ministerele și agențiile trebuie să se coordoneze pentru a reutiliza date conform legii interoperabilității (în România, Legea nr. 242/2022 impune exact această cooperare pentru schimb de date). De asemenea, principiul centrării pe utilizator (user-centric design), deși vine din zona eGovernment, completează cerințele legal-administrative: dacă legea permite flexibilitate în modul de depunere a unei cereri, designul procesului ar trebui să opteze pentru varianta cea mai simplă pentru cetățean (ideal digital 100%). Dacă legea încă mai prevede opțiuni tradiționale (hârtie, ghișeu), un design instituțional inovator poate propune modificări legislative ulterioare pentru a elimina aceste bariere – așa cum arată principiile daneze, unde se recomandă revizuirea legislației cu prea multe excepții sau proceduri complexe, în favoarea unor reguli mai simple și automatizabileen.digst.dken.digst.dk.
  • Principiul explicabilității și al transparenței. Legal, administrația are obligația să-și motiveze deciziile și să fie transparentă. Într-un sistem digital, acest principiu se traduce prin „audit trail” și reguli de decizie explicite. Orice decizie automată pe baza legii (de ex. eligibil/neeligibil) trebuie să poată fi explicată în termeni de reguli aplicate (de ex.: „Respins deoarece venitul depășește plafonul legal de X lei”). Astfel, conectăm normele legale direct cu logica sistemului – fiecare articol de lege relevant trebuie trasabil în codul aplicației sau în configurarea sa (ex: regula din lege corespondentă unei reguli DMN din sistem). Din perspectivă instituțională, transparența implică și definirea clară a responsabilităților: cine validează că regulile codificate corespund legii? Aici de obicei departamentele juridice și de policy ale instituției furnizoare de serviciu public trebuie implicate în revizuirea modelelor create de IT, înainte de implementare.

În sinteză, combinarea principiilor se reflectă astfel: interpretăm legea cu acuratețe și îi respectăm litera și spiritul (principii juridice), iar simultan ne asigurăm că designul rezultat este implementabil digital și suportă obiective de bună guvernanță (principii de design instituțional – eficiență, interoperabilitate, user-centric, transparență). O bună practică este ca echipa de proiect să elaboreze un set de cerințe derivat din principii, de exemplu: „Sistemul va aplica automat criteriile legale obiective, orice evaluare subiectivă fiind rezervată operatorului uman conform legii (principiul automatizării cu respectarea drepturilor) (en.digst.dken.digst.dk); Sistemul va reutiliza date existente din registrele publice (principiul interoperabilității) (en.digst.dken.digst.dk); Sistemul va oferi cetățeanului acces la propriile date și stadiul cererii (principiul transparenței administrative ș.a.)”. Aceste cerințe devin parte integrantă a specificației tehnice și provin direct din aplicarea combinată a regulilor legale și a bunelor practici de design.

O dificultate frecventă în proiectele de e-guvernare este “traducerea” limbajului juridic în termeni tehnici. Limbajul legal este narativ, uneori ambiguu, lăsând loc interpretării umane, pe când sistemele informatice cer definiții stricte, fără ambiguitate. Să analizăm cum fiecare element din limbajul normativ se conectează cu elemente din analiza tehnică:

  • Normele (regulile juridice) devin reguli de business. În termeni tehnici, acestea pot fi exprimate ca if-then-else sau ca decizii într-un model DMN. De exemplu, norma “Pentru a beneficia de ajutor social, solicitantul trebuie să aibă venituri sub X lei” se traduce printr-o regulă implementată: IF venit_net > X THEN respinge cererea. Standardul Decision Model and Notation (DMN) oferă un mod de a scrie formal asemenea reguli, lizibil atât pentru experți de business cât și executabil direct de motoare de reguli(trisotech.comtrisotech.com). Folosind DMN sau chiar pseudocod într-un document de specificații, legăm direct condițiile și efectele din lege (venit sub plafon => drept acordat) cu condițiile și acțiunile sistemului software. Astfel, norma generală devine logică algoritmică concretă. Această practică este uneori numită și „inginerie a regulilor juridice”, parte din Legal Engineering, și ajută la evitarea interpretărilor diferite: regula e scrisă o singură dată, verificată de juriști și apoi utilizată uniform de toate componentele sistemului.
  • Rolurile juridice devin actori și drepturi de acces. Limbajul legal definește adesea roluri precum „autoritatea competentă”, „solicitantul”, „terț avizat”, etc. În limbaj tehnic, aceste roluri sunt mapate la utilizatori sau componente: de exemplu, „solicitantul” corespunde unui user extern (cetățean) care inițiază procesul prin portal, „autoritatea X” devine un grup de utilizatori interni (funcționarii autorității X) cu acces în modulul intern al sistemului, „sistemul Y” (dacă legea implică un alt sistem informatic) devine o integrare via API cu un serviciu extern ce acționează ca actor automat. Toate aceste roluri trebuie reprezentate în diagrame: în BPMN prin lane-uri separate, în use-case diagram prin actori care relaționează cu cazurile de utilizare. De asemenea, rolurile legale se reflectă în modul de autorizare din aplicație – un principiu de securitate este role-based access control, ceea ce se pliază natural pe rolurile definite legal (ex.: doar utilizatorii cu rol „Inspector” pot valida documentul, conform prevederilor legale privind competența inspectorilor). Astfel, harta rolurilor din lege devine schema de utilizatori în sistem și structura de organizații în arhitectura de procese.
  • Condițiile și excepțiile din lege devin logica de decizie și fluxurile alternative. Tehnic, acestea apar sub formă de gateway-uri în diagramele BPMN (diamante care separă fluxul în funcție de o condiție booleană sau multi-criterială). Fiecare condiție legală importantă (“dacă <condiție> atunci <acțiune> altfel <altă acțiune>”) trebuie transpusă într-un astfel de punct de decizie în modelul procesului. Excepțiile notabile (de ex. „sunt exceptate de la obligație persoanele care...”) pot fi reprezentate fie ca ramuri alternative în proces (dacă exceptat, sare direct la pasul final), fie ca procese separate dacă modul de tratare e foarte diferit. Important este ca niciun scenariu prevăzut de lege să nu fie omis din modelul tehnic. Uneori, limbajul legal ascunde condiții în propoziții complexe sau în multiple articole – de aceea, e utilă elaborarea unui “arbore decizional” care să vizualizeze toate condițiile în ordine logică. Metodologia Better Rules din Noua Zeelandă exact asta face: folosește diagramă decizională (decision tree) pentru a conecta conceptele și regulile într-o secvență logică ușor de urmărit (digital.govt.nzdigital.govt.nz). Aceste diagrame devin podul dintre frazele normative și codul executabil, permițând echipei să verifice că fiecare condiție din lege are un corespondent.
  • Sancțiunile și măsurile corrective devin funcționalități de notificare sau blocare în sistem. De exemplu, dacă legea prevede că „nerespectarea termenelor atrage aplicarea automată a unei penalități de X lei pe zi de întârziere”, sistemul trebuie să fie capabil: (a) să detecteze depășirea termenelor (prin cron job-uri, comparând data curentă cu data limită stocată), (b) să genereze o înregistrare de penalitate în contul contribuabilului și eventual (c) să emită o notificare oficială. Toate acestea se vor specifica drept cerințe tehnice derivate din acea sancțiune legală. Dacă sancțiunea este de natură neautomatizabilă (ex: „amendă contravențională aplicată de organul de control”), atunci sistemul poate cel mult să sprijine procesul permițând introducerea amenzii și legarea ei de caz, dar aplicarea efectivă rămâne la latitudinea unui actor uman (design-ul trebuie să prevadă o interfață pentru asta). Un alt tip de sancțiune – nulitatea unui act emis nelegal – ridică probleme interesante: sistemul ar trebui să prevină emiterea actului dacă nu sunt îndeplinite condițiile? Ideal da, prin validări de business rule înainte de emitere (ex: nu poți genera licența dacă nu sunt încărcate toate documentele cerute de lege). Astfel, transformăm sancțiunea post-faptum într-o regulă preventivă în software, acolo unde e posibil, pentru a asigura compliance by design.
  • Termenii și definițiile legale devin structuri de date și constrângeri. De pildă, dacă legea definește noțiunea de „ședință publică” și enumeră câmpurile unui proces-verbal, aceste elemente se vor reflecta în modelul de date al aplicației (entități și atribute). Obiectele cheie (dosar, cerere, aviz, raport) devin entități în baza de date sau clase în cod, iar relațiile dintre ele (un dosar conține cereri, fiecare cerere are un solicitant etc.) se construiesc conform definițiilor legale. În plus, orice constrângere din lege (ex: „cererea trebuie soluționată în 30 zile”) devine fie o regulă de validare (nu permiți ca un caz să rămână deschis >30 zile fără escaladare), fie o metadată în sistem (un cronometru asociat cazului). Limbajul tehnic permite aici formalizarea strictă a ceea ce în limbaj juridic poate apărea vag. Un truc folosit de unele metodologii de legal requirement engineering este translatarea propozițiilor normative în pseudo-cod sau OCL (Object Constraint Language, în UML) – practic se scrie o restricție invariabilă pe model: context Dosar inv: Dosar.status = „soluționat” sau current_date - Dosar.dataÎnregistrare <= 30 zile, care reprezintă exact cerința legală de termen. Astfel de legături între definițiile legale și modelul informațional asigură că orice dezvoltator va vedea direct în schema de date ceea ce prevede legea.

Odată realizată conexiunea dintre elementele de limbaj legal și reprezentările tehnice, documentația proiectului ar trebui să includă tabel de trasabilitate: articolul X din lege -> diagrama Y (pas/decizie) și regula de business Z. În acest fel, la orice modificare legislativă viitoare, se poate regăsi rapid ce componente ale sistemului trebuie ajustate. Abordarea „Rules as Code” sugerează chiar să menținem codul și textul sincronizate. Publicarea codului sursă ce implementează legea, alături de text, este o viziune de viitor menționată în Noua Zeelandă: la fel cum guvernul publică legea pe site-ul oficial, ar putea publica și “legislația ca și cod executabil” într-un format deschis, permițând oricui să folosească direct regulile în aplicații proprii (digital.govt.nz). Deși acest ideal necesită eforturi considerabile, el subliniază importanța aliniamentului complet între normă și algoritm.

În concluzie, legarea limbajului juridic de limbajul tehnic presupune formalizare și structurare: punem gramaticii juridice echivalentul său algoritmic. Metodele vizuale precum BPMN ajută la această punte, fiind dovedit că “diagramele BPMN facilitează transmiterea informației legale fără a induce în eroare persoanele neavizate, păstrând principiul normativității” (ceur-ws.org). Cu alte cuvinte, un model grafic bine făcut poate comunica atât echipei IT cât și părților interesate din instituții ce spune legea în termeni operaționali, constituind un limbaj comun.

Transpunerea unui text de lege în modele BPMN, use-case și ArchiMate

Odată identificate componentele normative esențiale, putem trece la modelarea efectivă în diferite formate care servesc scopuri complementare: BPMN pentru procese, cazuri de utilizare pentru cerințe funcționale și ArchiMate pentru arhitectura de ansamblu.

Modelarea procesului în BPMN. Business Process Model and Notation este standardul de facto pentru descrierea proceselor, inclusiv în sectorul public. Transpunerea legii în BPMN începe prin delimitarea granițelor procesului și a actorilor (pools/lanes) conform rolurilor legale. Apoi se așază activitățile în secvența logică definită de procedura legală. Un bun exemplu vine din domeniul electoral: cercetări arată că “modelarea legislației electorale cu BPMN poate face legea mai ușor de înțeles pentru părțile interesate”, dezambiguizând pașii de la parlament la secția de vot (liebertpub.com ). Practic, BPMN obligă la precizie – fiecare săgeată trebuie să ducă undeva – eliminând eventualele zone gri din text.

Un studiu aplicat pe reforma achizițiilor publice (Biernacki, 2024) a demonstrat că orice procedură definită de lege poate fi reflectată ca diagramă de colaborare BPMN, în care „reglementarea” însăși este figurată ca un participant ce face schimb de informații cu ceilalți actori implicați (researchgate.net). Acest mod de a include legea ca actor este interesant: se trasează interacțiunea dintre ceea ce prevede norma și cei care o pun în practică. În diagrama BPMN rezultată, cazul de utilizare legal devine vizibil: legea „transmite” cerințe (de ex. trimite notificări de conformitate) către instituții, iar instituțiile „raportează” înapoi starea implementării. Biernacki notează că o reprezentare BPMN riguroasă asigură neechivocitatea reglementării și permite evaluarea impactului înainte de aplicare (researchgate.netresearchgate.net). Mai mult, modelele BPMN dezvoltate în faza de analiză se pot transforma ulterior în modele executabile (workflow-uri automate) supravegheate de sistemele IT, menținând coerența deplină între lege și implementare (researchgate.netresearchgate.net). Într-adevăr, s-a propus ca modelele BPMN să fie atașate ca anexe la proiectele de lege, sporind înțelegerea și eliminând interpretările divergente (researchgate.net). De asemenea, competența de a citi și verifica diagrame BPMN devine tot mai importantă nu doar pentru analiști și programatori, ci și pentru juriștii și funcționarii care trebuie să asigure implementarea corectă a legii (researchgate.net).

Tehnic, cum procedăm la modelarea BPMN după un text de lege? Un pattern util este să identificăm stările cheie și tranzițiile. Exemplu: Legea serviciilor electronice prevede pașii: înregistrare, verificare, aprobare/respingere, emitere certificat, contestație (opțional). Aceștia devin pași BPMN legați prin gateway-uri („cerere completă?” „solicitant eligibil?” etc.). Se vor adăuga evenimente de start (cine inițiază procesul – ex. cetățeanul depune cererea) și evenimente finale (ex. serviciu furnizat, sau notificare de respingere trimisă). Orice interacțiune între două entități devine un flux de mesaj BPMN (de la un pool la altul), evidențiind punctele de integrare sau de comunicare oficială (ex: trimitere aviz de la autoritate la solicitant). Regula generală este că modelul BPMN trebuie să acopere 100% din logica procedurală a legii: dacă după modelare ne dăm seama că un articol nu apare nicăieri, înseamnă fie că l-am omis, fie că este un business rule transversal (caz în care îl punem ca adnotare de constrângere). De aceea, revizuirea modelului BPMN de către experții juridici este esențială pentru a confirma că „diagrama reflectă întocmai textul”. Adesea apar întrebări revelatoare: „Dar în lege scrie că trebuie și avizul de la ministerul Y – unde e în diagramă?” Dacă l-am omis, trebuie adăugat pool/lanț nou; dacă legea era neclară unde se include acel aviz, acum devine clar că procesul ar avea o sincopă – descoperire ce poate conduce chiar la propuneri de îmbunătățire legislativă. Așadar, BPMN nu doar transpune, ci și verifică coerența internă a legii (un beneficiu secundar valoros). Cazul Digital Services Act (DSA) în UE este edificator: cercetători au folosit BPMN pentru a remodela obligațiile impuse intermediarilor online, ajutând companiile să înțeleagă cum să se conformeze noilor reguli (ceur-ws.orgceur-ws.org). Ei subliniază că modelul grafic, dacă e fidel normelor (principiul normativității păstrat), ajută la transmiterea eficientă a informației juridice și prevenirea interpretărilor greșite de către neexperți (ceur-ws.org).

Modelarea cerințelor prin use-case (cazuri de utilizare). Diagramele de proces BPMN descriu cum decurge fluxul între actori, dar din perspectiva dezvoltării software este nevoie și de identificarea cerințelor funcționale concrete – ce trebuie să facă sistemul informatic. Aici intervine modelul de cazuri de utilizare (use-case model). Practic, derivăm din proces o listă de interacțiuni pe care utilizatorii (actori) le vor avea cu sistemul. Fiecare pas manual din BPMN poate corespunde unuia sau mai multor cazuri de utilizare. De exemplu, în BPMN avem o activitate „Verificare eligibilitate de către inspector”. Pentru sistem, aceasta implică un use-case „Inspectează dosar eligibilitate” în care actorul „Inspector” accesează aplicația, vede detaliile dosarului și eventual primește un rezultat calculat automat al eligibilității sau introduce el însuși verdictul. Dacă procesul BPMN e complex, un use-case diagram rezumă relațiile: actor Cetățean are use-case „Depune cerere online”, actor Inspector are use-case „Procesează cerere” etc., actorul Șef de serviciu are „Aprobă cerere” etc. Toate acestea derivă din obligațiile legale (cine face ce).

Scenariile de use-case trebuie descrise textual, evidențiind pașii sistem-utilizator. În aceste descrieri vom incorpora regulile de business extrase din lege: ex. Pas 4: Sistemul validează că solicitantul are >18 ani (conform art. X din lege). Astfel, fiecare use-case devine containerul implementării unei părți din cerința legală. Use-case-urile servesc și la evidențierea excepțiilor de flux din perspectiva utilizatorului. De pildă, scenariul alternativ „date introduse invalide” sau „solicitant neeligibil – sistemul afișează mesaj și oprește procesul”. Aceste scenarii alternative corespund ramurilor de excepție din BPMN și normelor de excepție din lege.

Un alt aspect este definirea use-case-urilor nefuncționale impuse de lege – precum cerințe de securitate, audit, confidențialitate. De exemplu, dacă legislația prevede protecția datelor personale, un use-case implicit este „Criptare și jurnalizare acces date personale”, cu actor Autoritate de supraveghere (ipotetic, dacă vine un auditor). Acestea asigură că obligațiile de conformitate (ex GDPR, legea arhivării) sunt și ele reflectate în planul de dezvoltare, nu doar procedurile de bază.

Pe scurt, diagrama BPMN ne spune ce pași existenți se automatizează sau asista – iar use-case-urile ne spun ce funcționalități concrete trebuie implementate pentru a realiza acei pași digital. Matricea de trasabilitate poate lega: Pas BPMN -> Use-case corespunzător -> Articol de lege sursă.

Integrarea în modelul de arhitectură ArchiMate. ArchiMate este un limbaj de modelare la nivel de enterprise architecture, ce permite reprezentarea coerentă a straturilor de business, aplicații și tehnologie și a relațiilor dintre ele. În contextul Public Framework, utilizarea ArchiMate ar oferi o vedere de ansamblu: cum se aliniază procesul digital (business) cu sistemele software implicate (aplicații) și cu infrastructura sau datele partajate (tehnologie).

Un model ArchiMate pentru cazul nostru ar include: procese de business (elemente Business Process care pot fi legate de diagramele BPMN detaliate), funcții de business (ex. funcția de emitere avize, funcția de gestionare cereri – corespondente domeniului instituțional), actori de business (instituțiile, departamentele – de ex. Ministerul X, Agenția Y, Cetățeanul, fiecare cu rolul său), apoi servicii de aplicație (ex. serviciul online de depunere cereri, serviciul de verificare date din registre) și componente de aplicație (ex. portalul front-end, baza de date, modulul de management de caz). ArchiMate permite și conectarea cu obiective și cerințe – de exemplu, în stratul de motivație putem reprezenta principiile de care am vorbit (principiul interoperabilității, al automatizării) ca Requirements sau Principles, legate de componentele de arhitectură care le satisfac. În modelul ArchiMate al interoperabilității europene (EIRA), se subliniază importanța adresării tuturor perspectivelor – legal, organizațional, semantic, tehnic – într-un mod holistic (linkedin.com). ArchiMate ne permite exact asta: putem lega cerința legală (modelată ca Requirement) de procesul de business care o realizează, apoi de serviciul aplicativ care suportă procesul, și mai departe de modulul tehnologic care implementează serviciul. Aceste relații ne arată trasabilitatea end-to-end de la lege la infrastructură.

Ca exemplu, să spunem că legea impune autentificare cu nivel ridicat de încredere pentru accesarea serviciului. În ArchiMate vom avea un requirement „Autentificare cu eID nivel substanțial (conform Regulament eIDAS)” legat de un serviciu de aplicație „Autentificare utilizator” care este realizat de componenta „Sistem Autentificare (ex. Autentificare.gov.ro)” și folosește un element de tehnologie „Serviciu identitate (ex. MitID/NemID în Danemarca, sistemul național de identitate)”. Astfel, modelul arată cum cerința legală de identitate digitală se propagă în arhitectura sistemului. ArchiMate excelează în a oferi această imagine de ansamblu integrată, utilă mai ales în proiecte mari cu multiple sisteme implicate sau unde se dorește conformitate arhitecturală cu cadre de interoperabilitate. De altfel, guvernele care adoptă enterprise architecture (ex. Olanda, Danemarca) folosesc ArchiMate pentru a standardiza modul în care sunt proiectate serviciile digitale astfel încât să respecte atât cerințe legale cât și standarde tehnice. Un beneficiu al modelării EA este identificarea blocurilor comune reutilizabile: de exemplu, dacă mai multe legi cer un modul de plăți online sau un registru al persoanelor, ArchiMate va evidenția că acel Application Service este reutilizat în arhitectura mai multor procese – ceea ce indică oportunitatea unui infrastructură comună (practic, orientarea spre public infrastructure reuse, cum prevede și unul dintre principiile daneze (en.digst.dken.digst.dk)). În model apar relații de compunere/agregare care arată că procese diferite folosesc același serviciu de autentificare sau plăți, ceea ce sprijină decizii informate la nivel de arhitectură guvernamentală (ex: investiții într-o platformă unică de plăți în loc de sisteme disparate).

În concluzie, transformarea legii în BPMN, use-case și ArchiMate oferă trei perspective complementare: (1) Procesuală – cum curge procedura legală între actori (BPMN); (2) Funcțională – ce trebuie să facă sistemul concret pentru a susține fiecare pas (use-case, plus modelul de date și reguli asociate); (3) Arhitecturală – cum se încadrează soluția în ecosistemul mai larg de sisteme și infrastructuri (ArchiMate EA). Prin toate aceste modele, terminologia juridică trebuie păstrată recognoscibilă (ex: numele procesului să reflecte denumirea din lege a procedurii, numele use-case-urilor să indice acțiuni legale – „Validare Dosar conform Legii X”, etc.), pentru ca trasabilitatea și comunicarea între juriști și IT să fie fluentă. Modelele devin astfel o documentație vie a modului în care legea este implementată, documentație ce poate fi inclusă în repository-ul Public Framework și reutilizată sau actualizată când apar modificări legislative.

Rolul actorilor instituționali: interpretare și validare

Procesul de transpunere juridico-tehnică nu este unul solitar, ci un efort colaborativ ce implică diverși actori instituționali, fiecare cu un rol specific în interpretarea și validarea rezultatului. Identificăm câteva roluri-cheie și responsabilitățile lor în acest demers:

1. Legiuitorul / Emitentul politicii publice. Deși poate părea distant de implementarea tehnică, actorul care creează norma (Parlamentul, Guvernul prin ministere) joacă un rol important prin deschiderea către digitalizare by design. Ideal, încă din faza de elaborare a legii ar trebui consultate echipe tehnice pentru a evalua implementabilitatea. În Danemarca, ministerele au chestionare de evaluare a impactului digital al proiectelor de lege, bazate pe principiile discutate (ex: “Pot fi aceste reguli automatizate? Folosesc date reutilizabile?”) (en.digst.dken.digst.dk). Acolo se încearcă validarea prealabilă că legea nu va crea obstacole tehnice. În România, o inițiativă notabilă în 2021 a fost propunerea ca fiecare proiect de act normativ să fie însoțit de o diagramă de proces (ex. BPMN) care să explice fluxul procedural instituit, ca parte a instrumentului de prezentare și motivare. Aceasta ar fi forțat o claritate sporită și ar fi dat echipelor IT un avans în înțelegerea cerințelor. Legiuitorul stabilește cadrul general, dar poate sprijini implementarea prin legislație “digital-friendly” și prin colaborare inter-instituțională (ex: protocoale de interoperabilitate impuse prin lege).

2. Instituția implementatoare (deținătoare de proces). Aici ne referim la ministerul sau agenția responsabilă să pună efectiv în practică legea printr-un serviciu public. Aceasta este clientul principal al proiectului de digitalizare și de obicei inițiatorul lui. Rolul instituției este să interpreteze corect legea în contextul propriu (uneori legea e cadru general și trebuie detaliată în metodologii). De regulă, departamentul juridic al instituției împreună cu departamentul de specialitate (policy/program) furnizează echipei de analiză informațiile de fond: ce a intenționat legiuitorul, cum se aplică acum (dacă procesul există și pe hârtie), unde sunt problemele. Ei traduc limbajul legal în limbaj organizațional, pe care apoi analiștii îl duc spre cel tehnic. Instituția are și rolul de validare finală a produsului: reprezentanții săi trebuie să confirme că modelul BPMN corespunde legii și practicii dorite, că regulile de business implementate reflectă corect normele și că nimic esențial nu lipsește. În mod ideal, instituția ar trebui să desemneze un grup de lucru mixt (juriști, experți domeniu, IT interne) care să lucreze cot la cot cu echipa de digitalizare externă sau a furnizorului.

3. Autoritatea centrală de digitalizare / standardizare (ex: ADR în România, sau echivalente în alte țări). O astfel de entitate (Autoritatea pentru Digitalizarea României, de exemplu) are rolul de consultant metodologic și de armonizare. În cadrul Public Framework, o metodologie integrată juridico-tehnică ar putea fi promovată de această autoritate, asigurând că toate proiectele o urmează. Practic, actorul central poate oferi template-uri, instrumente și training pentru modelarea proceselor din acte normative. Poate chiar stabili obligația ca, înainte de finanțarea unui proiect major de e-guvernare, să existe o mapare a cerințelor legale făcută conform metodologiei standard. Acest actor ar putea interpreta meta-legea – adică asigură respectarea cadrului general (ex: standarde de interoperabilitate, cerințe de accesibilitate, protecția datelor) în fiecare proiect, lucruri pe care echipa locală le-ar putea neglija concentrându-se pe conținutul specific al legii domeniale. De asemenea, fiind la curent cu toate inițiativele, autoritatea centrală poate valida că modelele propuse se aliniază cu arhitectura generală guvernamentală (de exemplu, dacă un proces are nevoie de autentificare, să folosească soluția centrală – scenariu de tipul Principiul 6 danez: folosirea infrastructurii publice existente (en.digst.dken.digst.dk)). Astfel, validarea nu e doar față de litera legii de domeniu, ci și față de ansamblul legal și tehnic mai larg.

4. Echipa de analiză și dezvoltare IT. Aceștia sunt cei care efectuează efectiv transpunerea în modele și cod. Rolul lor nu este doar tehnic, ci și de interpret intermediar: trebuie să înțeleagă suficient limbajul juridic pentru a-l codifica. Din acest motiv, multe guverne pun accent pe formarea de „ingineri juridici” – persoane cu dubla competență law + IT. În absența unor astfel de specialiști, echipa IT trebuie să colaboreze strâns cu juriștii instituției pentru clarificări. Ei au responsabilitatea de a alege instrumentele potrivite de modelare (ex: un tool BPMN sau o platformă de gestionare a cerințelor) și de a documenta trasabilitatea. Echipa IT, după ce produce modelele, le predă spre validare experților de conținut (juridic/policy) și trebuie să fie receptivă la corecții. În faza de dezvoltare, dacă apar impedimente (ex: o regulă nu poate fi automată 100% din cauza unui caz ambiguu), echipa IT semnalează instituției, care poate decide soluția (uneori se ajunge la propuneri de amendare a legii însăși sau emitere de norme suplimentare clarificatoare).

5. Actori de control și audit (ex: Curtea de Conturi, Autoritate Protecția Datelor, societate civilă). Aceștia pot părea externi, dar într-o strategie Public Framework bine pusă la punct, și acești actori ar trebui considerați. De exemplu, dacă sistemul digital ia decizii automat pe baza legii, este posibil ca la un moment dat o instanță sau un auditor să întrebe: arată-mi că decizia a fost conform legii. Pentru asta, modelul formal (BPMN, regulile) devin o piesă de audit. Auditorii pot valida că procesul digitalizat nu iese din parametrii legali. Implicarea lor timpurie (în consultare) ar putea preîntâmpina situații problematice. De pildă, Autoritatea de protecție a datelor ar putea spune din faza de proiectare dacă o anumită prelucrare de date prevăzută în flux contravine GDPR, permițând ajustarea în design și eventual inițiative legislative de corelare. Societatea civilă (ex: ONG-uri specializate) poate valida și ea dacă transpunerea digitală respectă drepturile cetățeanului așa cum intenționează legea (ex: accesibilitate, nediscriminare).

În rezumat, interpretarea legii într-un proiect digital este un efort de co-creație între experți juridici și tehnici. Cine interpretează inițial sunt juriștii de la instituția de domeniu (asistați de analiști), iar cine validează final include atât instituția de domeniu (asigurând conformitatea cu scopul legii), autoritatea centrală de digitalizare (asigurând conformitatea cu cadrul general și bunele practici), cât și eventual entități de control. Metodologia ar trebui să prevadă etape formale de validare: de exemplu, un „legal walkthrough” al modelului BPMN – în care juriștii parcurg diagrama pas cu pas comparând cu textul legal; sau un „tech assessment” realizat de arhitecții guvernamentali – în care se validează că soluția propusă respectă standardele Public Framework (interoperabilitate, securitate etc.). Doar prin această colaborare interdisciplinară strânsă se poate obține un rezultat final corect și acceptat de toți.

Un exemplu de succes al implicării actorilor multipli este metodologia Better Rules din Noua Zeelandă menționată anterior. Acolo s-a instituit explicit utilizarea unei echipe multidisciplinare care include experți în politici publice, juriști, specialiști în business rules, programatori și designeri de servicii, lucrând iterativ împreună (digital.govt.nzdigital.govt.nz). Ei dezvoltă împreună modele conceptuale, apoi rule statements și cod, verificând continuu atât de către partea legală cât și de cea tehnică validitatea soluției (digital.govt.nzdigital.govt.nz). Acest mod de lucru s-ar plia foarte bine și pe Public Framework, creând punți directe între instituțiile care dețin procesul și echipele care îl digitalizează.

Propunere de metodologie integratoare în Public Framework

Bazându-ne pe considerațiile de mai sus, propunem o metodologie integrată juridico-tehnică ce poate fi adoptată drept parte a Public Framework, pentru a formaliza transpunerea legislației în cerințe și soluții digitale. Pașii principali ai metodologiei sunt următorii:

1. Analiza preliminară a cadrului legal și instituțional. În această etapă se identifică actele normative aplicabile (legi, HG-uri, regulamente europene, norme metodologice) care reglementează procesul ce urmează a fi digitalizat. Se elaborează o hartă a obligațiilor legale: ce trebuie să facă administrația (prestări, verificări), ce drepturi și obligații au cetățenii sau companiile, ce termene și condiții există. Tot aici se identifică actorii instituționali relevanți (ministere, agenții, autorități locale, etc.) și relațiile de competență dintre ei. Rezultatul este un raport de analiză juridică ce devine baza pentru design – practic un document de cerințe brute scrise în limbaj natural, structurate pe elemente (ex: capitole pentru flux procedural, reguli decizionale, roluri, documente necesare, sancțiuni, indicatori de performanță dacă prevede legea evaluări etc.). Acest raport va fi revizuit de juriști și agreat înainte de a trece la modelare.

2. Formarea echipei mixte și stabilirea glosarului comun. Public Framework ar trebui să recomande ca pentru fiecare proiect să existe atât un expert juridic de domeniu (sau un grup) cât și analiști de business și arhitecți IT. În această etapă, echipa se asigură că toată lumea înțelege la fel conceptele de bază. Se realizează un glosar comun al termenilor, care include atât definiții din lege cât și corespondența lor în termeni tehnici. De exemplu: “Beneficiar” – conform Legii X art. 2 lit. a) = persoană care primește serviciul; în sistem acest concept corespunde entității User și va avea atribute: nume, CNP, etc.*. Acest glosar previne confuzii terminologice pe parcurs și este un artefact valoros al metodologiei.

3. Modelarea conceptuală a domeniului (Concept Model). Similar practicii Better Rules, înainte de a plonja în diagrame de proces, e util să avem o diagramă conceptuală (tip UML class diagram sau model semantic) care arată entitățile și relațiile din domeniu. De exemplu, pentru un proces de autorizare: concepte precum Cerere, Solicitant, Aviz, Autorizație, Organism emitent, etc. și legăturile dintre ele. Acest model conceptual derivă direct din definițiile legii și oferă o vedere statică, complementară cu procesul (care e dinamic). E o unealtă foarte utilă pentru a descoperi inconsistențe sau neclarități în înțelegere – dacă un concept e înțeles diferit de membrii echipei, aici va ieși la iveală. Concept modelul devine ulterior baza pentru modelul de date al sistemului.

4. Modelarea procesului legal în BPMN (și/sau CMMN dacă e cazul). Se creează diagrama BPMN principală care reprezintă “happy flow” (scenariul principal al procedurii) și ramificațiile majore. Dacă procesul e foarte complex sau include multe scenarii opționale, se pot folosi subprocese și chiar diagrama de Case Management (CMMN) pentru părți mai puțin stricte (de exemplu, procese decizionale cu multă discreție se pretează la CMMN, dar aceste cazuri sunt rare; BPMN rămâne central). Modelul BPMN se lucrează iterativ: versiunea 0 se bazează pe textul legii; se discută cu experții de domeniu și juriști, se ajustează; versiunea 1 se validează iarăși și tot așa. Scopul este să ajungem la un consens că “așa funcționează (sau va funcționa) procesul conform legii”. Un aspect metodologic: includem în diagrame anotări legislative – ex: sub fiecare task relevant, o adnotare cu articolul de lege sursă. Astfel, diagrama devine nu doar un tool tehnic, ci și o hartă de conformitate.

5. Extracția și formalizarea regulilor de decizie. Paralel cu BPMN (sau după ce fluxul principal e stabilit) se compilează toate regulile de business identificate (condiții de eligibilitate, formule, excepții, etc.). Acestea se documentează fie sub formă de listă de reguli (ex: R1, R2, ...) cu referințe la lege, fie ideal se modelează într-un diagramă DMN (tabel de decizie, arbore decizional formalizat). Avantajul DMN este că clarifică intrările necesare pentru fiecare decizie și rezultatele posibile, într-un format ușor de discutat cu experții (tabelele decizionale pot fi înțelese de non-IT după puțină pregătire). Toate regulile se validează cu juriștii. Ei trebuie să confirme că, de exemplu, “da, formula de calcul implementată corespunde exact metodologiei legale de calcul” sau “da, criteriile din tabelul de decizie acoperă toate cazurile prevăzute de lege”. Acest pas asigură că logica deciziilor automatizate e corectă și acceptată înainte de codificare.

6. Maparea pe cerințe funcționale (use-case) și non-funcționale. Folosind procesul și regulile, se elaborează lista detaliată de cerințe. Pentru fiecare interacțiune actor-sistem din BPMN, definim un use-case. Se scriu scenariile principale și alternative. Se includ și cerințele de sistem: interfețe, rapoarte, audit, securitate, performanță. Toate acestea sunt trasate înapoi la elemente din modelul legal (ex: “UC7 – Emitere autorizație” corespunde Task “Emitere autorizație” din BPMN și art. 10 din lege; Cerința NF3 – logare acces date personale corespunde obligației din art. 5 GDPR etc.). Acolo unde cerințele depășesc cadrul legii (ex: cerințe pur tehnice), le marcăm ca atare dar având în minte principiile generale (ex: logare acces - principiu transparență și răspundere).

7. Modelarea arhitecturală și alinierea la Public Framework. Odată stabilit ce trebuie să facă sistemul, se proiectează cum se va încadra în ecosistem. Se identifică dacă există blocuri reutilizabile din Public Framework: de exemplu, dacă Public Framework are un modul de autentificare central, îl vom folosi, deci nu-l cerem ca nou. Dacă există API-uri guvernamentale (ex: verificare CNP la Evidența Populației), le vom integra. Modelul ArchiMate poate fi aici instrumentul principal: se creează un viewpoint al arhitecturii soluției, arătând relațiile dintre proces, aplicații și infrastructură. În această etapă se consultă și echipele tehnice ale altor instituții dacă integrarea e necesară. Scopul metodologiei la acest pas este să se asigure că transpunerea legii nu produce un siloz izolat, ci se conectează la ecosistemul digital guvernamental. Public Framework ar trebui să includă ghiduri și standarde de interoperabilitate, securitate, UI/UX, pe care proiectul trebuie să le aplice.

8. Validare multidisciplinară și iterare. Înainte de implementarea efectivă (cod), se organizează sesiuni formale de revizuire:

  • Review juridic: juriștii instituției + eventual Ministerul Justiției sau alți avizatori verifică că niciun element din model nu contravine legii sau nu omite ceva. Se verifică și textele care vor apărea în interfață (ex: conținutul notificărilor juridice).
  • Review tehnic: arhitecții IT guvernamentali (sau experți independenți) validează arhitectura propusă vs. cerințele de scalabilitate, securitate, aliniere cu strategiile (cloud guvernamental etc.).
  • Simulări de proces: se poate organiza o simulare “pe hârtie” sau cu prototip a fluxului digital, cu participanții reali, pentru a vedea dacă toți pașii au sens și dacă utilizatorii (ex. funcționarii) se pot adapta la noul flux. Aceasta funcționează și ca validare de design instituțional – confirmă că rolurile și competențele au fost atribuite corect și acceptabil.

Feedback-ul din aceste verificări se incorporează și modelelele/cerințele se ajustează. Metodologia prevede poate 2-3 cicluri de revizuire până la “freezing scope”. Faptul că toate modificările se fac în modele formale garantează că atunci când trecem la cod, specificațiile sunt clare și stabilite de comun acord.

9. Implementare, testare și realimentare a cadrului. Când dezvoltatorii scriu codul conform cerințelor, asigurarea calității trebuie să includă testare de conformitate cu legea. Se pot scrie teste pe baza scenariilor legislative (ex: date de intrare care corespund unui caz din lege – se verifică că sistemul dă rezultatul prevăzut de lege). Un aspect inovator, dacă s-a adoptat conceptul de Rules as Code, este că același set de reguli formale folosit de sistem poate fi rulat independent ca să valideze rezultate (dublă implementare ca măsură de siguranță). După lansare, este esențială monitorizarea: se colectează metrici, inclusiv dacă implementarea digitală relevă neclarități sau probleme în lege. Aceste informații trebuie transmise înapoi legiuitorului sau instituției, contribuind la îmbunătățirea politicii publice. De exemplu, dacă constatăm că 5% din cazuri nu se potrivesc în niciun branch al deciziei (deși teoretic legea acoperă tot), e semn de interpretare neunitară – poate fi nevoie de un ghid sau amendament legal. Public Framework ar trebui să instituționalizeze acest feedback loop: digitalizarea nu e un proces pasiv, ci oferă date pentru optimizarea legilor și procedurilor.

Metodologia de mai sus, formalizată și standardizată, ar deveni parte integrantă din Public Framework. Ar exista șabloane de documente (pentru analiza juridică, pentru modelul de proces, pentru trasabilitate), ghiduri pas-cu-pas și poate un catalog central de procese și reguli (astfel încât, dacă o lege similară se digitalizează, să se reusească ce s-a învățat). Un asemenea cadru integrator ar poziționa Public Framework în linia bunelor practici internaționale, unde deja se vorbește tot mai mult despre “legislation to digital workflow” ca disciplină de sine stătătoare. Beneficiul pe termen lung este crearea unei biblioteci guvernamentale de modele: un Government Process Architecture Repository, unde fiecare serviciu public are asociat diagrama BPMN, regula DMN și specificațiile – actualizate ori de câte ori se schimbă legea, asigurând sincronizarea continuă între statutory law și digital law (legea codificată în software).

Studii de caz și bune practici internaționale

Pentru a ilustra aplicarea practică a principiilor și metodologiei discutate, prezentăm în continuare câteva exemple relevante din țară și străinătate:

  • Digitalizarea achizițiilor publice (România, Moldova, Polonia). Domeniul achizițiilor publice este unul extrem de normat legislativ, dar și unul unde digitalizarea a adus beneficii imediate. Platforma românească SEAP și sistemul similar MTender din Republica Moldova au transpus integral procedurile de licitație publică în fluxuri de lucru electronice. Studiul lui Biernacki (2024) menționat anterior, care a implicat proiecte de reformă a legislației achizițiilor sprijinite de BERD, arată că noile reglementări privind procedurile de achiziție au fost dezvoltate împreună cu modele BPMN, apoi implementate în software, obținându-se astfel un sistem coerent în care legea și aplicația informatică se potrivesc perfect( researchgate.netresearchgate.net). Un efect măsurat în Moldova a fost transparența sporită și economii substanțiale: MTender a introdus open data și monitorizare în timp real, reușind economii de ~14% la buget prin prevenirea fraudei și eficientizarea proceselor (conform datelor publice din 2024). Un factor critic de succes a fost includerea diagramelor de proces ca instrument de training și comunicare: funcționarii au primit diagramele BPMN ale noilor proceduri ca ghid vizual, facilitând adoptarea. Acest exemplu evidențiază importanța implicării instituționale: Agențiile de achiziții, ministerele de finanțe și experții juridici au lucrat cot la cot cu analiști BPMN și dezvoltatori. Rezultatul – un sistem în care “regulamentul este reflectat 1:1 în BPMN”, asigurând univocitate și permițând evaluarea impactului înainte de adoptare (researchgate.netresearchgate.net).
  • Inițiativa “Better Rules” – Noua Zeelandă. Menționată de mai multe ori, această inițiativă guvernamentală este un exemplu de bună practică în combinarea expertizei juridice cu cea tehnică. În 2018, în cadrul Service Innovation Lab, Noua Zeelandă a pilotat transpunerea Legii privind subvențiile la taxe locale (Rates Rebate Act) într-un format de reguli executabile. Au format o echipă multidisciplinară care a parcurs pașii descriși: concept modeling, diagramare decizională, scriere de rule statements, apoi codificare simultană (digital.govt.nzdigital.govt.nz). Unul din principalele lor constatări a fost că scrierea legii în cod a acționat ca “oglindă dură” care a scos la iveală presupuneri tacite și inconsecvențe în textul legal (digital.govt.nz ). De exemplu, au descoperit că definiția “venit anual” din lege nu specifica clar dacă include anumite beneficii – lucru care a trebuit clarificat pe loc. Echipa a putut simula diverse scenarii cu date reale (simulations) pentru a vedea impactul regulilor (digital.govt.nz). Această abordare a dus la recomandări de modificare a legii pentru a fi mai clară și mai ușor automatizabilă. Totodată, codul produs (legislația-cod) a fost reutilizat pentru a alimenta un serviciu web numit SmartStart, care ghidează cetățenii în baza regulilor legale publicate (digital.govt.nz). Better Rules a devenit un model urmat și de alte țări, iar accentul pus pe multidisciplinaritate și iterație continuă între limbaj natural și cod este pe deplin aliniat cu filosofia Public Framework. Practic, Noua Zeelandă ne arată cum poate arăta viitorul: legi scrise colaborativ de juriști și programatori, verificate automat prin testări, și puse la dispoziție atât sub formă de text uman, cât și API public pentru dezvoltatori terți (digital.govt.nz).
  • Legislație pregătită pentru era digitală – Danemarca. Guvernul danez, prin Agenția pentru Digitalizare, a integrat în procesul lor legislativ obligația ca noile legi să fie însoțite de o evaluare a celor 7 principii pentru legislație digital-ready. Am detaliat deja unele principii (claritate, automatizare, reutilizare date, infrastructură comună). Ca studiu de caz, Danemarca a reușit prin aceste principii să elimine bariere legislative care împiedicau soluții digitale. De exemplu, o reglementare care cerea ca un cetățean să prezinte un anumit document fizic a fost modificată pentru a permite obținerea electronică a datelor, aplicând Principiul 4 (reutilizarea datelor în locul solicitării de noi documente) (en.digst.dken.digst.dk). Un alt exemplu: în domeniul prestațiilor sociale, s-a identificat că definiții diferite ale “venitului” în legi diferite creau dificultăți de interoperare, contravenind principiului consecvenței. Ca urmare, s-a inițiat un program de aliniere a definițiilor legale și crearea unui dicționar comun pentru termenii-cheie în toate bazele de date guvernamentale. Acest efort, de natură mai degrabă semantică, a avut efecte tehnice imediate – integrările între agenții au devenit mai simple când toți au convenit ce înseamnă “household income” și din ce surse se calculează (en.digst.dken.digst.dk). Danemarca oferă și ghidaj practic: un set de întrebări de control pentru fiecare principiu, la care ministerele trebuie să răspundă în faza de draft de lege(en.digst.dken.digst.dk). Acest lucru instituționalizează gândirea design-to-implement. Ca bună practică, România ar putea prelua o astfel de listă de verificare în avizele interministeriale, asigurând că încă din faza de politică publică se pregătește terenul pentru transpunere digitală.
  • Estonia – servicii de e-guvernare bazate pe lege. Estonia este adesea citată ca lider al e-guvernării. Un factor cheie al succesului eston a fost că digitalizarea a fost însoțită de un cadru legal care a favorizat procesele digitale: încă din anii 2000 au adoptat Legea semnăturii digitale care a dat echivalență juridică semnăturii electronice, Legea i-Voting pentru votul online, Legea „once-only” care interzice instituțiilor să ceară date pe care statul deja le are etc. Ca atare, multe servicii digitale estone au la bază “digital era governance laws”. Un exemplu de transpunere explicită este sistemul de evidență a sănătății: legislația estonă a prevăzut de la început un dosar medical electronic unificat, cu acces controlat de pacient. Implementarea tehnică (E-Tervis) a urmat îndeaproape aceste prevederi, iar ArchiMate a fost folosit de arhitecții estoni pentru a planifica integrarea tuturor actorilor (spitale, medici de familie, pacienți) într-o platformă centrală de date de sănătate. Ei au publicat chiar și modele de arhitectură deschise pentru consultare. Rezultatul – 95% dintre rețete sunt digitale, toți cetățenii au un portal de sănătate, iar legea obligă medicii să emită datele în sistemul central. Estonia exemplifică deci situația ideală: legislație modernă concepută cu gândul la digital, plus utilizarea de standarde arhitecturale la implementare (ei au propriul framework, compatibil TOGAF/ArchiMate, pentru e-guvernare).
  • România – servicii digitale recente și lecții învățate. În ultimii ani, și în România au fost transpuse unele procese administrative în digital integral: de exemplu, eliberarea cazierului judiciar online, depunerea declarațiilor fiscale în Spațiul Privat Virtual (SPV), sau înmatricularea auto online (portalul DRMIV). Aceste proiecte au scos la iveală importanța interpretării flexibile a cadrului legal. De pildă, pentru cazier online a trebuit emis un act normativ secundar care să permită identificarea electronică și eliminarea cererii pe hârtie – semn că legea originală nu prevăzuse digitalul. După implementare, s-a constatat un lucru pozitiv: cererea digitală de cazier are mai puține erori și e mult mai rapidă, ceea ce a dus la scăderea fluxului la ghișee. Astfel, Polția Română împreună cu Ministerul Digitalizării au evidențiat cum simplificarea procedurii în software poate sugera modificări legislative de debirocratizare (ex: au propus ca persoanele să nu mai trebuiască să ceară deloc cazierul, ci instituțiile să-l obțină direct – idee de once-only). Acest exemplu arată necesitatea feedback-ului de care vorbeam: proiectele pilot de digitalizare pot evidenția unde legea ar putea fi îmbunătățită. O altă lecție locală a fost cu sistemul de depunere online a cererilor pentru indemnizații COVID-19 (șomaj tehnic) în 2020: cadrul legal inițial avea formulări interpretabile privind eligibilitatea, ceea ce în software s-a manifestat prin numeroase erori de validare. După primul val de implementare, Ministerul Muncii a clarificat condițiile prin norme suplimentare și comunicare către beneficiari. Dacă ar fi existat o modelare formală inițială, aceste ambiguități ar fi fost probabil identificate ex ante. Cu aceste experiențe, România se îndreaptă spre a recunoaște valoarea Legal Engineering-ului: de exemplu, Planul Național de Redresare și Reziliență (PNRR) finanțează dezvoltarea unui Cadru național de interoperabilitate și a unui Hub de date, ceea ce impune ca noile legi să specifice clar schimbul de date. Se conturează astfel necesitatea unei metodologii ca cea propusă de noi, pentru a gestiona într-un mod unitar aceste transformări.

Concluzii

Digitalizarea administrației nu înseamnă doar implementarea de software, ci și transpunerea cunoașterii normative în forme executabile. Articolul de față a argumentat că, în cadrul Public Framework, este esențială o abordare metodologică integrată care să unească domeniul juridic și cel tehnic încă din fazele incipiente ale proiectelor de e-guvernare. Am arătat cum înțelegerea legii și identificarea componentelor relevante (roluri, reguli, condiții, excepții, sancțiuni) reprezintă fundația oricărei arhitecturi de proces – legea oferă cerințele, iar modelele de proces și sistem le materializează. Prin combinarea principiilor de interpretare juridică (legalitate, claritate, teleologie) cu principii de design instituțional (eficiență, interoperabilitate, user-centric, transparență), putem asigura că soluțiile digitale nu doar respectă litera legii, ci și optimizează implementarea ei în spiritul bunei guvernări.

Cazurile practice discutate, de la reforme ale achizițiilor publice transpuse în BPMN, la inițiative de tip Rules as Code sau la standarde de digital-ready legislation, converg spre aceeași idee: nevoia de a crea un limbaj comun între juriști și IT. Fie că este o diagramă BPMN anexată la o lege, fie o echipă multidisciplinară care codează împreună regulile, experiența internațională arată că beneficiile sunt reale – crește claritatea, scade timpul de implementare, se anticipează problemele și, nu în ultimul rând, cetățeanul primește servicii mai accesibile și mai predictibile.

Public Framework, ca inițiativă de standardizare în sectorul public, are oportunitatea de a adopta și promova o astfel de metodologie integratoare. Recomandăm crearea unui ghid oficial care să includă pașii descriși (analiză juridică, modelare proces, formalizare reguli, trasabilitate, validare etc.), însoțit de toolkit-uri (exemplu: șabloane de diagrame, biblioteci de elemente comune cum ar fi simboluri BPMN pentru “Verificare conform lege X” etc.). De asemenea, formarea personalului public în utilizarea acestor instrumente este crucială – de la juriști familiarizați cu logica BPMN, la analiști pregătiți să citească și interpreteze un text legal.

Nu în ultimul rând, implementarea metodologiei trebuie văzută ca un proces iterativ și evolutiv. Pe măsură ce tot mai multe legi vor fi transpuse, Public Framework ar trebui să actualizeze constant bunele practici. În viitor, am putea vedea inclusiv instrumente de inteligență artificială asistând în această sarcină – de exemplu, algoritmi NLP care sugerează automat părți din lege ce corespund unor elemente de proces. Dar indiferent de instrument, esența rămâne colaborarea strânsă între domeniul legal și tehnic.

Încheiem subliniind importanța rigurosului argument științific și a surselor oficiale în fundamentarea acestei abordări. Așa cum am citat lucrări și inițiative din Legal Engineering și eGovernment, continuarea cercetării aplicate în acest domeniu în context românesc va aduce cu siguranță noi perspective. Public Framework poate deveni un hub al acestor cunoștințe, unind comunitatea într-un demers de modernizare a administrației pe baza cunoașterii și a metodologiilor dovedite. Legea și tehnologia pot coexista armonios, iar prin metodele adecvate, tehnologia devine un instrument fidel de aplicare a legii, nu un tărâm al improvizațiilor. Acest articol speră să fi contribuit la conturarea unei astfel de metode și să inspire pași concreți către implementarea ei.

Bibliografie selectivă:

  • Cherouana, A. & Mahdaoui, L. “Legal Requirements for Public Process Modeling – A BPMN Meta-model Extension.” (2012) – propune integrarea cerințelor legale în modelarea proceselor publice (scispace.comscispace.com).
  • Biernacki, P. “BPMN in Legislation on Example of Public Procurement Law – Case Study.” Decision Making in Manufacturing and Services (2024) – demonstrează folosirea BPMN pentru a asigura coerența între legea achizițiilor și implementarea IT (researchgate.netresearchgate.net).
  • Hagan, M. “Legal Design” – definit ca abordare centrată pe utilizator pentru a crea sisteme legale accesibile (2017) – susține utilizarea vizualizărilor (ex. diagrame) pentru a facilita înțelegerea normelor (ceur-ws.orgceur-ws.org).
  • Guvernul Danemarcei – Principiile pentru legislație pregătită digital (2018) – document oficial ce enunță cele 7 principii (simplitate, criterii obiective pentru automatizare, reutilizare date, securitate etc.) (en.digst.dken.digst.dk).
  • OECD & Observatorul OPSI – “Cracking the Code: Rulemaking for humans and machines” (2020) – raport care introduce conceptul Rules as Code și beneficiile potențiale pentru administrații (interoperable-europe.ec.europa.euinteroperable-europe.ec.europa.eu).
  • NZ Govt – “Better Rules – Better Outcomes” (2019) – raport de descoperire asupra metodologiei Better Rules, evidențiind rolul echipelor multidisciplinare și al iterării reguli-cod (digital.govt.nzdigital.govt.nz).
  • Interoperable Europe – “Digital-ready policymaking” (2023) – inițiativă UE pentru a alinia procesul legislativ cu implementarea digitală; include cursuri și evenimente pe tema legiferării “digital by default” (interoperable-europe.ec.europa.eu).

(Notă: Referințele au fost integrate în text sub formă de citări directe pentru acuratețe și pot fi accesate pentru detalii suplimentare.)