Kutatás · A teljes javaslat

A teljes javaslat: a román kormány dizájnrendszere (SDGR)

Ez a teljes javaslatom a digitális közszolgáltatások közös dizájnrendszerére, a 2026. október 20-i 3.0-s változatban. Az SDGR munkanév, a román elnevezés (Sistemul de Design al Guvernului României) rövidítése. Ez nem a Kormány vagy a Román Digitalizálási Hatóság (ADR) hivatalos dokumentuma. Itt megtalálod, mit építenék, ki döntene, a 36 hónapos ütemtervet, a becsült költségvetést és azokat a feltételeket, amelyek alapján a program folytatódna vagy leállna. A költségek, az ütemterv és a jogi megoldások feltevések, amelyeket még igazolni kell.

0. A javasolt döntés

Azt javaslom, hogy az SDGR-t szakaszos programként hagyják jóvá, 36 hónapos nyilvános időtávval és eredményeken alapuló ellenőrzési szakaszokkal:

• Az első részlet (0–9. hónap): feltárás, minimális életképes termék (MVP, a legkisebb változat, amely valós szolgáltatásokban tesztelhető) és az első két kísérleti szolgáltatás. A mag finanszírozását legalább 18–24 hónapra megerősítenék.
• A bővítést valós szolgáltatásokból származó bizonyítékok alapján hagynák jóvá, nem a közzétett komponensek száma szerint.
• Az intézmények kötelezettségei csak akkor nőnének, amikor a termék már stabil és értékelt.

A hét indítási feltétel:

1. Világos megbízatás: tudni lehet, kié a termék, ki hagyja jóvá, és ki támogatja a pilotprojekteket.
2. Igazolt finanszírozás: a mag költségvetése 18–24 hónapra biztosított, jóváhagyott forrással.
3. Valódi partnerek: a pilotintézményeknek vannak kiinduló adataik, csapataik és kijelölt felelőseik.
4. Korlátozott termék: az MVP elkülönül a fizetési, a személyazonosítási és az interoperabilitási platformoktól.
5. Ellenőrizhetőség: a kód, a dokumentáció, a döntések, a tesztek eredményei és a költségek nyilvánosak.
6. Ellenőrzött kilépés: a program leállítható vagy újratervezhető.
7. Folytonosság: a Kormány által jóváhagyott memorandum, több kódfelelős, terv a vezetőváltásra, hogy a program ne egyetlen csapattól függjön.

1. A megoldandó közügy és a célok

1.1 A probléma

A közszolgáltatások felületei intézményenként eltérnek (űrlapok, hibaüzenetek, navigáció, akadálymentesség). Így az emberek minden szolgáltatást újra megtanulnak, az állam pedig többször fizet ugyanazért. Az akadálymentességet rendszerint csak az indítás után ellenőrzik, pedig a 112/2018-as sürgősségi kormányrendelet (OUG) kötelezettségeket ír elő. Aki nem beszél jól románul, nehezen érti meg, mit kell tennie. 2025-ben a romániai internetezőknek csak 25,4%-a használta valamelyik hatóság honlapját vagy alkalmazását, ez a legalacsonyabb arány az EU-ban (Eurostat). A Gazdasági Együttműködési és Fejlesztési Szervezet (OECD) 2025-ös digitáliskormányzati indexében Románia kapta a legalacsonyabb pontszámot a 42 értékelt ország közül: 0,24-et az 1-ből.

1.2 A probléma határai

Az egymással nem kommunikáló nyilvántartásokat, a fölösleges folyamatokat vagy az elavult rendszereket közös felületek nem oldják meg. Az SDGR kifejezetten dokumentálná, mely más programoktól függ: az interoperabilitástól, a ROeID-tól (a nemzeti elektronikus személyazonosítástól) és a Ghișeul.ro-tól.

1.3 A polgár számára elérni kívánt eredmény

Az ember megtalálja a megfelelő szolgáltatást, és érti a lépéseket és a költségeket; gyakrabban fejezi be a kérelmet segítség nélkül; billentyűzettel, kisegítő technológiákkal, mobilon és lassú kapcsolaton is használni tudja a szolgáltatást; a saját nyelvén kap tájékoztatást; érti, milyen adatokat gyűjtenek, és mi következik.

1.4 A program három ellenőrizhető eredménye

2. Az elképzelés: termék a polgárnak

Az SDGR nem szabályzat és nem is grafikai készlet lenne, hanem folyamatosan karbantartott digitális termék, amelynek végső ügyfele az adófizető. Rendelkezne:

• végfelhasználókkal (az emberek) és közvetítő felhasználókkal (az intézmények és a beszállítók csapatai), akik számára ennek kellene a legegyszerűbb és a legolcsóbb megoldásnak lennie;
• termékfelelőssel és állandó csapattal;
• nyilvános ütemtervvel, verziókkal és kiadási jegyzetekkel;
• az eredmények mérésével és visszajelzési csatornával.

Gazda nélkül egy dizájnrendszert nem tartanak tovább karban. Ezt mutatja az Egyesült Államok kormányának dizájnrendszere (USWDS) 2025–2026-ban (Az amerikai rendszer (USWDS)).

3. Alapelvek

Tizenkét alapelv: az emberek valós igényei, felhasználókkal tesztelve, fogyatékossággal élő emberekkel is; a hasznosság az egységesség előtt; akadálymentesség és közérthető nyelv az első naptól, elfogadási feltételként; több nyelv ugyanarra a szolgáltatásra; bizonyított haladás, a leállítás lehetőségével; következetes, nem egyforma; a legkönnyebb megoldás legyen a helyes; nyitott és beszállítósemleges; minden leszállítandó elemnek egy gazdája; működési minimalizmus; „előbb bizonyítunk, aztán kérünk”; a politikai változásoktól védett folytonosság.

4. Mi az SDGR, és mi nem

4.1 Három terület, három gazda

Az intézmény felelne a végső szolgáltatásért és annak megfeleléséért.

4.2 Mi nem az SDGR

Nem lenne egységes portál, iratkezelő rendszer, fizetési platform, személynyilvántartás, személyazonosítási szolgáltató vagy honlapokat tanúsító hatóság. A felületeket és az integrációs szabályokat kínálná, anélkül hogy átvenné ezeknek a szolgáltatásoknak az üzemeltetését.

5. Mit vennék át Európából és az Egyesült Államokból

A többi 26 uniós tagállam (Az uniós tagállamok törvényei, Európai dizájnrendszerek) és az amerikai rendszer (Az amerikai rendszer (USWDS)) elemzéséből indultam ki. Átvenném:

• a kutatásra épülő szolgáltatási mintákat (GOV.UK, Egyesült Királyság) → §6.5;
• az intézményenkénti témákkal működő föderatív modellt és a komponensek érési folyamatát (NL Design System, Hollandia; Designsystemet, Norvégia) → §6.4, §6.8;
• az akadálymentességet első helyre tevő webkomponenseket (KoliBri/KERN, Németország; gov.cz, Csehország; DÁP, Magyarország), tesztelendő feltevésként → §6.6;
• a tudásportált (Aksel, Norvégia) → §6.7;
• a megfelelés független ellenőrzése utáni kifizetést (Olaszország, a nemzeti helyreállítási és rezilienciaterv, PNRR 1.4.1-es intézkedése, mintegy 6.000 hozzáigazított önkormányzat) → §13, §14.4;
• a kezdeti leltárt és a nyilvános ütemezést (Portugália, 49/2024-es törvényerejű rendelet), valamint a megfelelés ellenőrzését az informatikai beruházások jóváhagyásakor (Portugália, Csehország) → 0. szakasz, §13;
• a mellékletben rögzített minimumkövetelményeket, az új komponensekre vonatkozó 10+10 munkanapos eljárást, a visszajelzési sávot, a felhasználói élményért (UX) felelős munkatársat (ID-SK, Szlovákia) → §6.8, §8, §13;
• a kiemelt szolgáltatásokat és az új főverzióra adott 24 hónapot (DSFR, Franciaország) → §10.5;
• az akadálymentességi bejelentések 2 héten belüli megválaszolását (Finnország, 306/2019-es törvény) → §8;
• az építő és az ellenőrző csapat szétválasztását (Magyarország) → §10;
• a hivatalos bannert, a kalibrált színfokozatokat, a tesztoldalakat, az érettségi modellt, a bevezetettség automatikus felmérését (USWDS, USA) → §6.3, §6.4, §8, §15.

Kerülném: a jogi előírást a termék előtt; a puszta ajánlásokat, eszközök nélkül (az USA-ban a bevezetettség 2025-ben, 10 év után is 20% alatt volt); az egyetlen, védett költségvetés nélküli csapatot (USA, 2025–2026); azt, hogy a szabványt olyan fórum hagyja jóvá, amelynek cégek is tagjai; a finanszírozás nélküli helyi kötelezettségeket; a megfelelés önértékelését független mérés nélkül.

6. A termék felépítése

6.1 Rétegek és területek

Hét réteg: (1) alapelvek, tartalom, akadálymentesség, kutatás; (2) alapok (design tokenek) és témák; (3) a bizalmi réteg; (4) komponensek; (5) romániai szolgáltatási minták; (6) oldalsablonok; (7) honlapmodellek polgármesteri hivatal, iskola, kórház és minisztérium számára. Az 1–4. réteg alkotja a magot, az 5–6. a szolgáltatási mintákat, a 7. réteg pedig a halasztott munkák listájára kerül, az igazolás utánra.

6.2 Az MVP és a halasztott munkák

Az MVP magja a 9. hónapig: tartalmi alapelvek és útmutató a hibákhoz és az űrlapokhoz; háromszintű design tokenek, valamint témák, ellenőrzött kontraszttal; a hivatalos banner és az intézményi azonosító; mintegy 12 alapkomponens, valamint a bizalmi réteg elemei (a lista a B. mellékletben); az első minták (személyes adatok, CNP, cím, „Mielőtt elkezdi”, ellenőrzés, visszaigazolás); dokumentáció, forráscsomag, Figma-könyvtár, kiadási jegyzetek; többnyelvű felépítés (külön tárolt szövegek, a választott nyelv a folyamat végéig megmarad, ékezetes és cirill betűket is tartalmazó betűtípusok).

Halasztott munkák (backlog), amelyekről a valós igény és a teljes költség alapján döntenének: csomagok tartalomkezelő rendszerekhez (CMS), elsőként a leltárból kiválasztott egyhez, például a WordPresshez; React-, Angular- és Vue-csomagok, csak ha a pilotprojektek használják őket; teljes honlapmodellek; beszélgető asszisztens, integráció az európai digitális személyazonosító tárcával, háttérirodai automatizálás. Ezek nem elvetett, hanem az első bevezetések utánra halasztott munkák.

6.3 A bizalmi réteg: az első látható eredmény

A hivatalos banner minden állami honlapon megjelenne, a javasolt „Un site oficial al statului român. Cum verificați?” („A román állam hivatalos honlapja. Hogyan ellenőrizheti?”) szöveggel; lenyitva elmagyarázná a .gov.ro domaint és a HTTPS-t. A felület nyelvein is lennének változatai, a helyi hatóságok domainjeire vonatkozó szabályt pedig a 0. szakaszban tisztáznák. Az intézményi azonosító (a szabványos lábléc) tartalmazná az intézmény nevét és a törvény által előírt hivatkozásokat: akadálymentesség, adatvédelem, közérdekű információk, kapcsolat, petíciók. A banner tájékoztató jelzés, nem hitelesítési mechanizmus: egy hamis oldal lemásolhatja. Az értéke abból fakad, hogy együtt jár a .gov.ro-val, a HTTPS-sel és a tájékoztató kampányokkal, a megléte pedig automatikusan ellenőrizhető.

6.4 Design tokenek és témák

A hierarchia ez lenne: alap → szemantikus → komponensszintű → az intézmény témája, és egy téma csak a design tokenek egy kifejezetten meghatározott körét módosíthatná. A színeknek 0-tól (fehér) 100-ig (fekete) terjedő fokozatai lennének, pontos luminanciatartományokra kalibrálva, ahogy az USWDS-ben. Csak így garantálja a fokozatok közötti különbség a kontrasztot. Például az 50 vagy nagyobb különbség teljesíti a WCAG (a webes tartalmak akadálymentességi irányelvei) AA szintjét. A betűtípusok nyíltak lennének, vesszős ș-sel és ț-vel, ő-vel és ű-vel, valamint cirill betűkkel. A rács 8 px-es egységet használna, és elsőként az olcsó telefonokra terveznének; a Figmában és a kódban szereplő értékek egy az egyben megfelelnének egymásnak.

6.5 Romániai minták

Az MVP-ben: név (több keresztnév, ékezetes betűk, más írásrendszerek), CNP (személyi szám; egyértelmű ellenőrzés, amely nem helyettesíti a szerveroldali ellenőrzést), romániai cím (megye → település SIRUTA-kóddal, ez a települések hivatalos nyilvántartásának kódja → utca, tömbház, lépcsőház, lakás; külföldi cím), „Mielőtt elkezdi” (mire van szükséged, költség, időtartam, a válasz nyelvei, összhangban az egységes digitális kapuról szóló (EU) 2018/1724 rendelettel), a válaszok ellenőrzése és a visszaigazolás.

Az MVP után: IBAN, telefonszám, e-mail-cím; dokumentumok feltöltése; fizetési felület (a fizetést a Ghișeul.ro biztosítja); bejelentkezési felület (ROeID, majd az európai tárca); „A kérelmem állása”; az állam által már ismert adatok, az „egyszeri adatszolgáltatás” elve szerint (a 242/2022-es törvény); időpontfoglalás az ügyfélszolgálatra; visszajelzés a végén; nyelvválasztás.

6.6 Műszaki döntések: tesztelés a szabványosítás előtt

A javasolt irány HTML és CSS, valamint webkomponensek, keretrendszer-csomagokkal. Ezt három próbával ellenőriznék: egy statikus honlappal, egy űrlapkezelő alkalmazással és egy pilotintézmény CMS-ével. A kötelező tesztek kiterjednének az akadálymentességre (a JavaScript nélküli működést is beleértve), a kompatibilitásra, a karbantartásra és a lassú kapcsolatokon nyújtott teljesítményre. Kiterjednének a dizájn és a kód megfelelésére, valamint a biztonságra is (a szoftverösszetevők nyilvános listája, SBOM, aláírt csomagok). Az eredményeket a 2. szakasz előtt nyilvánosan dokumentált architekturális döntésekben rögzítenék.

6.7 Közzététel, biztonság és adatvédelem

Nyilvános kód, aláírt verziókkal, valamint automatikus akadálymentességi és regressziós ellenőrzésekkel. A design.gov.ro honlap tudásportál is lenne: minden komponenshez a használat, a kerülendő hibák, példák, a tesztek eredményei és az ismert korlátok. Lenne eljárás a sérülékenységek kezelésére és az előző verzióhoz való visszatérésre. A komponensek alapértelmezés szerint nem gyűjtenének analitikai vagy személyes adatokat, a példák pedig kitalált adatokat használnának.

6.8 A komponensek érettségi szintjei

7. Többnyelvűség: felépítés az első naptól, fordítások szakaszosan

A cél: aki Romániában él, értse, mit kell tennie, egy általa értett nyelven. A felépítés az első naptól többnyelvű lenne; a fordítások szakaszosan készülnének el, a jogi kötelezettségek, a felhasználók száma és a karbantartási kapacitás szerint.

7.1 Kiket szolgálna

Minden felhasználót, közérthető románul; a nemzeti kisebbségeket, elsősorban magyarul, aztán németül, ukránul, romani nyelven, szerbül, törökül és más nyelveken, az igények és a törvényi küszöb szerint; az uniós polgárokat és a külföldi lakosokat angolul; az ideiglenes védelem alatt álló személyeket ukránul; a siket embereket román jelnyelven, a legfontosabb információk esetében; a gyengébb olvasási készségű embereket könnyen érthető szöveggel.

7.2 A fordítások, szakaszosan

A komponensek 30–40%-kal hosszabb szövegeket is elbírnának, lenne hivatalos szójegyzék, a joghatással járó szövegeket emberek ellenőriznék, és a román maradna a jogilag irányadó változat. A jogalapot (a közigazgatási törvénykönyvben szereplő küszöböt, a jelnyelvet, az egységes digitális kaput, az ideiglenes védelmet) a 0. szakaszban ellenőriznék.

8. Akadálymentesség és használhatóság mindenkinek, kivétel nélkül

A műszaki cél a WCAG 2.2 AA szintje lenne, önkéntesen vállalva. A jogi hivatkozási alap továbbra is az EN 301 549 európai szabvány és a 112/2018-as sürgősségi kormányrendelet; a WCAG új változatai nem válnak automatikusan kötelezővé. Az ellenőrzés három szinten történne: a komponens szintjén (az SDGR-csapat, nyilvános tesztoldallal és minden főverziónál megfelelőségi jelentéssel), a teljes folyamat szintjén (az intézmény, felhasználókkal) és a közzétett szolgáltatás szintjén (a gazdája, akadálymentességi nyilatkozattal és javítási tervvel).

Egy komponens csak akkor válna „stabillá”, ha átment az automatikus teszteken, a kézi teszteken (billentyűzet, 200–400%-os nagyítás, kontraszt), az NVDA, JAWS, VoiceOver és TalkBack képernyőolvasókkal, román hanggal végzett teszteken, valamint fogyatékossággal élő emberekkel tartott, fizetett üléseken. Az intézmény legfeljebb 10 munkanapon belül válaszolna az akadálymentességi bejelentésekre (javasolt cél). Az akadálymentes komponensek nem garantálják az akadálymentes szolgáltatást; a felelősség az intézménynél marad.

9. Az együttműködési modell: négy pillér

A négy pillér az ADR, az állandó műszaki csapat, az egyetemek és a magánszféra lenne; körülöttük dolgoznának az intézmények, a fogyatékossággal élő emberek szervezetei, a civil technológiai szervezetek és a polgárok. Az egyetemek és a cégek kapacitást és minőséget hoznak, de nem helyettesítik a fizetett csapatot, és nem felelnek az éles szolgáltatásokért.

9.1 ADR: intézményi felelősség, finanszírozás, irányítás, folytonosság

A termék az ADR-é lenne; az ADR legalább 3 éves megbízatással termékfelelőst nevezne ki, és elnökölne az Irányító Bizottságban. Biztosítaná a többéves költségvetési sort, az irányítást és a folytonosságot, és nyilvánosan beszámolna a bevezetési műszerfalon és az éves jelentésben. Nem döntene a műszaki részletekről, és nem szankcionálná az intézményeket egy nem stabil termék miatt. Az ADR pontos jogi hatáskörét a 0. szakaszban egy jogi feljegyzés erősítené meg.

9.2 Az állandó műszaki csapat: architektúra, karbantartás, biztonság, verziók, támogatás

A fizetett csapat (§14) felelne az architektúráért, a karbantartásért, a biztonságért, a verziókért, a támogatásért, a minőségi kapukért és a külső hozzájárulások beépítéséért. Minden stabil komponensnek lenne felelőse és helyettese, legalább két adminisztrátor tudna verziót kiadni, a csapat pedig nem üzemeltetné az intézmények belső rendszereit.

9.3 Az egyetemek és a hallgatók: fejlesztés, UX-kutatás, tesztelés, akadálymentesség, dokumentáció

Javasolt formák: 3–5 egyetemi SDGR-labor különböző regionális központokban, éves támogatással; ECTS-kredittel (az európai kreditátviteli rendszer) járó féléves projektek; szakdolgozatok és mesterdolgozatok; 3–6 hónapos fizetett szakmai gyakorlatok; felhasználói tesztelés, vidéken is; akadálymentességi auditok; dokumentáció és fordítások; évente egy hackathon.

Egyetemek például: a bukaresti Műszaki Egyetem (Politehnica), a Babeș–Bolyai Tudományegyetem, az „Alexandru Ioan Cuza” Egyetem, a Temesvári Nyugati Egyetem, a Bukaresti Nemzeti Művészeti Egyetem (UNArte), az „Ion Mincu” Építészeti és Urbanisztikai Egyetem (UAUIM), a Közgazdaságtudományi Akadémia (ASE), a kolozsvári Művészeti és Design Egyetem (UAD). A példák nem jelentenek vállalást. A hallgatók nem dolgoznának közvetlenül éles rendszeren. A hozzájárulások az EUPL-1.2 (az EU nyilvános licence, a kódhoz) vagy a CC BY 4.0 (a dokumentációhoz) alatt történnének, DCO-val (a hozzájárulás eredetéről szóló tanúsítvánnyal).

9.4 A magánszféra: szakértelem, kódátnézés, mentorálás, éles környezetben igazolt gyakorlatok

Kirendelt szakemberek, a munkáltató által felajánlott munkaórákkal („SDGR Fellows”), külső kódátnézők, mentorok a laborok számára, valamint az SDGR-t használó és a problémákat jelentő beszállítók. Garanciák: a cégeknek nincs szavazati joguk a szabványról; a hozzájárulások nyilvánosak; a szakértők érdekeltségi nyilatkozatot tesznek; a részvétel nem jár előnnyel a közbeszerzésekben; a tanácsadói szerepeket rotációval töltik be; a partnereknek nincs hozzáférésük az éles rendszerekhez vagy az adatokhoz; a megfelelés ellenőrzése független az átállást végző cégtől.

9.5 A többi résztvevő

A felhasználó intézmények, fokozatosan kinevezett UX-felelőssel, és anélkül, hogy egyedül módosíthatnák a magot; a fogyatékossággal élő emberek szervezetei, állandó hellyel a Tanácsadó Testületben; a helyi közigazgatás érdekképviseleti szervezetei (a municípiumok, városok és községek szövetségei, valamint a Megyei Tanácsok Országos Szövetsége); a civil technológiai szervezetek, például a Code for Romania; a polgárok, visszajelzésekkel és tesztekkel.

10. Irányítás

10.1 Struktúrák, megbízatások és korlátok

Az Irányító Bizottság (az ADR, a termékfelelős, a műszaki architekt, a Kormány és a helyi közigazgatás képviselői) döntene a stratégiáról, a költségvetésről és az ütemtervről, a szokásos műszaki döntések nélkül. A termékfelelős határozná meg a prioritásokat, és tenné közzé a mutatókat. A műszaki csapat felelne az architektúráért, a tesztelésért és a kiadásokért. A Tanácsadó Testület nyilvános ajánlásokat tenne, vétójog és közbeszerzési előnyök nélkül. A pilotintézmények felelnének a végső szolgáltatásért. A nyitott munkacsoportok (akadálymentesség; tartalom és nyelvek; komponensek; integráció) a nyilvános javaslattételi eljárásban dolgoznának.

10.2 Ki miről dönt (RACI)

R = végrehajtja, A = felel a döntésért, C = kikérik a véleményét, I = tájékoztatják

10.3 Döntési szabályok

Minden architekturális változásról nyilvánosan dokumentált döntés születne. A külső hozzájárulások licencellenőrzésen, kódátnézésen és minőségi auditon mennének át. A joghatással járó tartalomról az illetékes hatóság döntene, nem a nyílt forráskódú közösség. Az intézményi kivételek nyilvánosak, indokoltak és határidősek lennének.

10.4 Folytonosság

Legalább 3–5 kódfelelős különböző szervezetekből, közös hozzáférés a közzétételi infrastruktúrához, és terv arra az esetre, ha a támogató vagy a beszállító megváltozik.

10.5 Verziókezelési szabályok

Szigorú szemantikus verziókezelés, évente legfeljebb egy főverzió és 24 hónap az átállásra, amely alatt az előző verzió biztonsági javításokat kap.

11. A kísérleti szolgáltatások

11.1 Hogyan választanák ki őket

Nyilvános feltételekkel meghirdetett felhívással, a bizonyítékok előállításának képessége alapján, nem a presztízs szerint. Az első kör: két szolgáltatás, plusz egy választható harmadik. Feltételek: ismétlődő ügyletek és kimutatható lemorzsolódás; a beavatkozás előtt legalább 8 hétnyi összehasonlítható adat; támogató és csapat az intézményen belül; a belső rendszer újraépítése nélkül megvalósítható integráció; egy egyszerű és egy közepes bonyolultságú folyamat, különböző méretű intézményekből; eltérő igényű résztvevők; lehetőleg egy pilot magyarul vagy más nyelven beszélőkkel.

11.2 A pilotok típusai

Az A pilot: dokumentumokkal járó kérelem (személyes adatok, CNP, cím, fájlfeltöltés, visszaigazolás). A B pilot: időpontfoglalás vagy egyszerű kérés. A C pilot (választható): fizetős szolgáltatás, csak ha a fizetési integráció működik, és az üzemeltető együttműködik.

11.3 Az egyes pilotok adatlapja (legfeljebb 5 oldal)

A probléma, a felhasználók, a jelenlegi folyamat, ami kimarad a pilotból, a kapcsolódó rendszerek, a felelősségi körök, a becsült költség, a kiinduló adatok, a sikerkritériumok és a visszaállási terv. Az intézmény megtartaná a felelősséget a valós ügyletekért.

12. Szakaszos ütemterv, kötelező ellenőrzési szakaszokkal

36 hónap az intézményesítésről szóló döntésig, öt ellenőrzési szakasszal (G0–G4). Az időtartamok tájékoztató jellegűek; egy szakasz nem kezdődne el, ha az előző nem teljesítette a feltételeit. A 4. szakasz után az állandó működés következne. A táblázatokban az L a hónapot jelöli (L3 = a 3. hónap).

12.1 Mikor állna le vagy kapna új tervet a program

• Legalább két kísérleti szolgáltatásnak nincs operatív gazdája.
• Egy súlyos akadálymentességi vagy biztonsági hiba a stabilizáláskor is megoldatlan marad.
• Az integráció költsége jelentősen meghaladja a becslést, és nincs kilátás az újrafelhasználásra.
• Nem gyűjthetők összehasonlítható adatok a szolgáltatások befejezéséről.
• A csapat nem tudja karbantartani a közzétett verziókat, vagy nem tudja nyújtani a megígért támogatást.

13. Bevezetés, közbeszerzés és jogi keret

13.1 Bevezetés a hasznosság révén, nem idő előtti bírságokkal

13.2 Közbeszerzési garanciák

A követelményeket szabványokkal írnák le, nem előnyben részesített beszállítókkal; az önkéntes hozzájárulók nem kapnának eltérő bánásmódot; a megfelelés ellenőrzése független lenne az átállást végző cégtől; a helyi közigazgatásra rótt bármely kötelezettség hatásvizsgálattal és finanszírozási forrással járna. A javaslat nem állítja, hogy az ADR egyedül előírhat jóváhagyási vagy közbeszerzési feltételeket: ehhez feljegyzés kell az ADR hatásköreiről, a PL-x 300/2026-os törvényjavaslat elemzése és összehangolás a terület jogszabályaival.

13.3 Kapcsolat a meglévő kezdeményezésekkel

A PL-x 300/2026-os törvényjavaslatot (lásd A törvényjavaslat elemzése) a Képviselőházban módosítani lehetne egy szakaszos folyamat kerettörvényévé, vagy a G4 után lehetne elfogadni, hogy egy már működő rendszert rögzítsen. Az eltérések a javaslatban szereplő rendszerhez képest: a termék a kötelezettség előtt; ellenőrzési szakaszok a 2028. január 1-jei rögzített határidő helyett; finanszírozási eszközök az intézmények közötti bírságok helyett; jog a visszajelzésre határidős válasszal; a cégek nem hagyják jóvá a szabványt. Az integrált digitális kormányzásról szóló törvény, amelyet a 2026. októberi kormányprogram jelentett be, „standardele unice de interfață” („egységes felületi szabványok”) létrehozását említi. Ezek lehetnének maga az SDGR, hogy ne legyen két párhuzamos szabvány. Az SDGR tiszteletben tartaná és könnyebben alkalmazhatóvá tenné a 112/2018-as sürgősségi kormányrendeletet, a 242/2022-es törvényt, a ROeID-t, az európai digitális személyazonosító tárcát és a mesterséges intelligenciáról szóló uniós rendelet 50. cikkét.

14. Csapat, erőforrások és költségvetés

Minden összeg tájékoztató becslés (saját számítás), amelyet a munkaerőpiac és a toborzási szabályok alapján igazolni kell. A számítás feltevése: évi 55.000–65.000 € egy teljes munkaidős egyenértékű (FTE) álláshelyre.

14.1 A csapat, szakaszonként

Az egyetemek és az önkéntesek többletkapacitást hoznak, nem helyettesítik a magot.

14.2 A központi költségvetés

Becslések (saját számítás), millió euróban.

14.3 Ami nem tartozik a központi költségvetésbe

Az egyes intézményekben történő bevezetés (átállás, integráció, tesztelés, tartalom, képzés) és a belső rendszerek módosítása az intézmények költségvetésében és projektjeiben marad. A helyi hatóságoknak szóló bevezetési alap uniós forrásokból származna, a §14.4 szerinti képlet alapján.

14.4 A bevezetési alap képlete

Alap = Σ (az i kategória jogosult intézményei × az i kategória igazolt standard költsége) + független ellenőrzés + kockázati tartalék

A standard költség csak a pilotokban igazolt tevékenységeket tartalmazná, átállástípusonként legalább három összehasonlítható becsléssel és utólagos ellenőrzéssel. A finanszírozott helyi hatóságok számát a számítás után határoznák meg, nem előtte, az ellenőrzés utáni kifizetés olasz modellje szerint.

14.5 Finanszírozási források

Az ADR költségvetése (többéves sor a mag számára); az EU technikai támogatási eszköze a 0–1. szakaszra, amely összekapcsolható az ADR 2026 júniusában indult projektjével; a PoCIDIF (Intelligens Növekedés, Digitalizáció és Pénzügyi Eszközök Program) és a 2028–2034-es pénzügyi keret; a Digitális Európa (Digital Europe) program; természetbeni hozzájárulások, amelyek nem helyettesítik a fizetett magot.

15. A hatás mérése és a gazdasági értékelés

15.1 Fő mutatók, az ellenőrzési pontokon használva

15.2 Másodlagos mutatók: bevezetés és lefedettség

Hivatalos bannert használó honlapok (automatikus felmérés), SDGR-rel épített szolgáltatások, a szolgáltatások fordítási szintek szerint, a bejelentésekre adott válaszidő, a közösség, a fenntarthatóság (teljes csapat, 3 évre szóló költségvetés). Ezek nem feltételei az ellenőrzési pontokon való továbblépésnek.

15.3 Az összehasonlítások szabályai

A kiinduló adatokat a beavatkozás előtt gyűjtenék, ideális esetben legalább 8 héten át, a mutatókat pedig a pilot előtt határoznák meg. Az összehasonlítások ugyanarra az időszakra és ugyanazokra a felhasználótípusokra vonatkoznának. A korlátokat is közzétennék, és a dizájnrendszer hatásait elkülönítenék más változások hatásaitól.

15.4 A költség-haszon elemzés minimális modellje

Becsült éves nettó haszon = (az ügyletenkénti költség csökkenése × az éves forgalom) + elkerült fejlesztési költségek + csökkent támogatási költségek − többlet karbantartási és integrációs költségek

A kezdeti beruházást külön számolnák el. Addig nem tennék közzé számszerű megtérülést (ROI), amíg nincsenek kiinduló adatok, auditált költségek és bizonyítékok minden értékre.

16. Kockázatok és ellenőrzési mechanizmusok

17. Az első 90 nap

18. Az 1.0-s verzió elfogadási feltételei

Az 1.0-s verziót akkor fogadnák el, ha:

• legalább két valós szolgáltatás használja a mag egy stabil verzióját, kritikus elágazások nélkül;
• minden stabil komponensnek van specifikációja, vannak példái, automatikus és kézi tesztjei, és közzétett korlátai;
• a lényeges interakciók működnek billentyűzettel és kisegítő technológiákkal;
• van akadálymentességi megfelelőségi jelentés az 1.0-s verzióhoz;
• a többnyelvűség 1. szintje legalább 3 nyelven (román, magyar, angol) teljes, szójegyzékkel;
• a kód, a verziók, a sérülékenységkezelési eljárás és a támogatás elérhető;
• a kompatibilitás igazolt a leltárban szereplő platformokon;
• a pilotok összehasonlítható adatai nyilvánosak;
• van felelős, költségvetés és szolgáltatási szint a karbantartásra;
• van hozzájárulási és kivételkezelési eljárás;
• az értékelés elkülöníti a dizájnrendszer hatásait más változások hatásaitól.

19. A döntési lehetőségek

A konkrét javaslat: az A lehetőség, a 0–9. hónap költségvetése részletes költségterv alapján jóváhagyva, a mag finanszírozása 18–24 hónapra megerősítve, nyilvános ellenőrzési ponttal a 9. hónapban, és a bővítésről szóló döntéssel a 18. hónapi összehasonlító jelentés után.

Mellékletek

Anexa A. A jóváhagyás előtt szükséges dokumentumok

Jogi feljegyzés (az ADR hatáskörei, jóváhagyás, kapcsolat a PL-x 300/2026-os törvényjavaslattal és az integrált digitális kormányzásról szóló törvénnyel, többnyelvűség); a platformok és szolgáltatások leltára; az akadálymentesség és a használat kiinduló helyzete; a dokumentált architekturális döntések; a pilotok adatlapjai és a megállapodások; a többéves költségterv; a független értékelés terve, a költség-haszon módszerrel.

Anexa B. Komponensek: az MVP és a v1.0

Anexa C. Szójegyzék

• Dizájnrendszer: alapelvek, design tokenek, komponensek, minták, sablonok és útmutatók, valamint egy irányítási folyamat.
• Design tokenek: a dizájn alapértékei (színek, méretek, térközök), amelyeket egyszer határoznak meg, és mindenhol használnak.
• MVP (minimális életképes termék): a legkisebb változat, amely valós szolgáltatásokban tesztelhető.
• Ellenőrzési pont (gate): az a pillanat, amikor nyilvános feltételek alapján döntenek a következő szakaszba lépésről.
• Akadálymentességi megfelelőségi jelentés: megmutatja, mennyire felel meg egy termék az akadálymentességi szabványoknak.
• Dokumentált architekturális döntés: egy műszaki döntés és indokainak nyilvános rögzítése.
• EUPL-1.2: az Európai Unió nyilvános licence nyílt forráskódú szoftverekhez.
• DCO: a hozzájárulás eredetéről szóló tanúsítvány.

Anexa D. Háttérdokumentumok

• Európai szabályok: az akadálymentesség, a használhatóság és a dizájnrendszerek európai kerete.
• Európai dizájnrendszerek: Európa kormányzati dizájnrendszerei.
• A törvényjavaslat útja és A törvényjavaslat elemzése: a PL-x 300/2026-os törvényjavaslat útja és elemzése.
• Az uniós tagállamok törvényei: összehasonlítás a többi 26 uniós tagállam elfogadott jogszabályaival.
• Ami Romániában már létezik: a romániai szabályok, útmutatók és erőforrások, amelyekre a javaslat támaszkodik.
• Az amerikai rendszer (USWDS): az amerikai rendszer és tanulságai.

Források

• Eurostat: az online közszolgáltatások használata (isoc_ciegi_ac)
• OECD: Digital Government Outlook 2026, Románia országjelentése
• GOV.UK Service Standard
• USWDS: a színek használata
• Európai Bizottság: a webes akadálymentességi irányelvhez kapcsolódó szabványok

← Az összes kutatási dokumentum