Tato příloha obsahuje ověřitelné kontrolní seznamy (Definition of Done) pro jednotlivé kroky metodiky. Použití je doporučené; OVM může checklisty přizpůsobit rozsahu a rizikovosti služby.
| # | OVĚŘOVACÍ BOD | STAV (☐/☒) | POZNÁMKA / ODKAZ |
| 1 | Je definován problém, cílový stav a očekávaný přínos pro uživatele služby. | ☐ | |
| 2 | Je vymezen rozsah (co je / není součástí) a vazby na související iniciativy. | ☐ | |
| 3 | Jsou identifikováni klíčoví aktéři (věcný gestor, IT gestor, právník, bezpečnost, UX, provoz). | ☐ | |
| 4 | Je zvolen model řízení (RACI) a způsob schvalování (např. per rollam) včetně artefaktů ke schválení. | ☐ | |
| 5 | Je určeno úložiště oficiální verze a přístupová pravidla (např. SharePoint DIA, portál kompetenčních center). | ☐ | |
| 6 | Je nastaven pracovní rytmus (milníky, reporting, eskalační cesta). | ☐ | |
| 7 | Je definováno, jak bude řízeno riziko „digitalizace formuláře místo zlepšení služby“ (kritéria úspěchu). | ☐ | |
| 8 | Je stanovena komunikační linka a kontaktní místo (např. funkční e-mail OVM / služební kontaktní schránka). | ☐ | |
| 9 | Existuje seznam předpokladů a omezení (včetně kapacit a závislostí). | ☐ | |
| 10 | Je založen registr rozhodnutí a registr rizik. | ☐ |
| # | OVĚŘOVACÍ BOD | STAV (☐/☒) | POZNÁMKA / ODKAZ |
| 1 | Je sestaven seznam relevantních předpisů a interních pravidel pro danou agendu. | ☐ | |
| 2 | Jsou popsány právní požadavky na úkon/službu (kdo, co, kdy, jak) a požadované důkazy/stopa. | ☐ | |
| 3 | Je vyhodnoceno zpracování osobních údajů (DPIA/posouzení dopadů, pokud je potřeba). | ☐ | |
| 4 | Je vyhodnocena kybernetická bezpečnost / klasifikace systému dle povinností organizace. | ☐ | |
| 5 | Jsou identifikovány konflikty/mezery mezi právem a IT (a je určen postup jejich řešení). | ☐ | |
| 6 | Je definováno, které údaje se přebírají z registrů a jaké jsou právní tituly přístupu. | ☐ | |
| 7 | Jsou definovány požadavky na přístupnost (zákonné minimum) a způsob ověření. | ☐ | |
| 8 | Je vyjasněno archivování a skartační režim u elektronických dokumentů (je-li relevantní). | ☐ | |
| 9 | Je zajištěna konzultace s právníkem a je evidován výsledek. | ☐ | |
| 10 | Existuje compliance matice (požadavek → návrh řešení → artefakt). | ☐ |
| # | OVĚŘOVACÍ BOD | STAV (☐/☒) | POZNÁMKA / ODKAZ |
| 1 | Je popsán současný proces (AS-IS) včetně aktérů a rozhodovacích bodů. | ☐ | |
| 2 | Jsou identifikovány pain points a jejich příčiny (ne pouze symptomy). | ☐ | |
| 3 | Je navržen cílový proces (TO-BE) se zjednodušením kroků a snížením administrativy. | ☐ | |
| 4 | Je definována datová potřeba (vstupy/výstupy), datové entity a datové zdroje. | ☐ | |
| 5 | Je popsána integrační mapa (zdroj → transformace → cílový systém). | ☐ | |
| 6 | Jsou stanoveny měřitelné ukazatele úspěchu (čas, chybovost, spokojenost, dokončení úkonu). | ☐ | |
| 7 | Je ověřena proveditelnost změn s věcným i IT gestorem. | ☐ | |
| 8 | Je popsán dopad na interní provoz a pracovní role (včetně školení). | ☐ | |
| 9 | Je založen backlog zlepšení a prioritizace (MVP vs. další iterace). | ☐ | |
| 10 | Je doložen soulad návrhu procesu s právními požadavky. | ☐ |
| # | OVĚŘOVACÍ BOD | STAV (☐/☒) | POZNÁMKA / ODKAZ |
| 1 | Jsou definovány cílové skupiny a scénáře použití (persony / segmenty). | ☐ | |
| 2 | Je vytvořena uživatelská cesta end-to-end (včetně offline kroků). | ☐ | |
| 3 | Je navržen obsah (jazyk, struktura, formulace) a ověřen s cílovou skupinou. | ☐ | |
| 4 | Je vytvořen prototyp a proběhlo uživatelské testování (záznam, závěry, úpravy). | ☐ | |
| 5 | Je řešena přístupnost (kontrast, klávesnice, popisky, chyby, validace). | ☐ | |
| 6 | Je zajištěna konzistence s design systémem (pokud organizace používá). | ☐ | |
| 7 | Jsou definována pravidla chybových hlášek a nápovědy (srozumitelnost). | ☐ | |
| 8 | Je vyhodnocena kognitivní zátěž a minimální počet kroků pro dokončení úkonu. | ☐ | |
| 9 | Je definováno měření chování (analytika) a ochrana soukromí. | ☐ | |
| 10 | Je připraven obsah pro komunikaci změny (návody, FAQ). | ☐ |
| # | OVĚŘOVACÍ BOD | STAV (☐/☒) | POZNÁMKA / ODKAZ |
| 1 | Je zpracována cílová architektura a rozhraní (API/specifikace). | ☐ | |
| 2 | Jsou definovány nefunkční požadavky (výkon, dostupnost, škálování, logování). | ☐ | |
| 3 | Je vyhodnocen threat model / bezpečnostní rizika a navržena mitigace. | ☐ | |
| 4 | Jsou zpracovány požadavky na auditní stopu a dohledatelnost rozhodnutí. | ☐ | |
| 5 | Je definována správa identit a přístupů (role, oprávnění). | ☐ | |
| 6 | Je definováno zálohování, obnova a plán kontinuity. | ☐ | |
| 7 | Je připraven plán testů bezpečnosti (SAST/DAST, penetrační test dle potřeby). | ☐ | |
| 8 | Je popsáno monitorování (metriky, alerty, logy) a incident management. | ☐ | |
| 9 | Je zajištěna kompatibilita s provozním prostředím organizace. | ☐ | |
| 10 | Jsou odsouhlaseny integrační závislosti a termíny. | ☐ |
| # | OVĚŘOVACÍ BOD | STAV (☐/☒) | POZNÁMKA / ODKAZ |
| 1 | Je zpracován backlog s akceptačními kritérii pro každou položku. | ☐ | |
| 2 | Je nastaven způsob řízení změn (Change Request) a verzování. | ☐ | |
| 3 | Probíhá peer review / kontrola kvality kódu (dle praxe organizace). | ☐ | |
| 4 | Existuje testovací strategie (unit/integration/system/UAT) a evidence výsledků. | ☐ | |
| 5 | Je otestována přístupnost (automat + manuál) a zapsány nálezy a opravy. | ☐ | |
| 6 | Je otestováno logování a auditní stopa (co, kdo, kdy). | ☐ | |
| 7 | Je připravena technická i uživatelská dokumentace. | ☐ | |
| 8 | Je provedena migrace dat / synchronizace (pokud relevantní) a ověřena konzistence. | ☐ | |
| 9 | Je připraven rollback / fallback plán. | ☐ | |
| 10 | Je splněno Go/No-Go kritérium pro nasazení. | ☐ |
| # | OVĚŘOVACÍ BOD | STAV (☐/☒) | POZNÁMKA / ODKAZ |
| 1 | Je schválen nasazovací plán a okno nasazení. | ☐ | |
| 2 | Je připraven runbook pro provoz a podporu (L1–L3) a kontakty. | ☐ | |
| 3 | Je provedeno školení podpory a interních uživatelů (je-li relevantní). | ☐ | |
| 4 | Je připraven komunikační plán pro uživatele (oznámení, návody, FAQ). | ☐ | |
| 5 | Je nastaven monitoring a alerting; ověřen příjem notifikací. | ☐ | |
| 6 | Je ověřena kapacita infrastruktury a škálování. | ☐ | |
| 7 | Je nastaven proces pro incidenty a eskalace. | ☐ | |
| 8 | Je provedeno pilotní ověření / soft launch (pokud je zvoleno). | ☐ | |
| 9 | Je dokončeno formální převzetí do provozu (akceptace). | ☐ | |
| 10 | Je založen plán Service Review (periodicita, metriky). | ☐ |
| # | OVĚŘOVACÍ BOD | STAV (☐/☒) | POZNÁMKA / ODKAZ |
| 1 | Jsou sledovány metriky (dokončení úkonu, doba, chybovost, spokojenost). | ☐ | |
| 2 | Je sbírán uživatelský feedback a je zpracován do backlogu zlepšení. | ☐ | |
| 3 | Je vyhodnocována dostupnost a výkon (SLA/SLI/SLO, pokud organizace používá). | ☐ | |
| 4 | Je provedena revize incidentů a kořenových příčin (RCA). | ☐ | |
| 5 | Je ověřována průběžná shoda s legislativou a interními pravidly (compliance). | ☐ | |
| 6 | Jsou pravidelně aktualizovány návody a obsah (content maintenance). | ☐ | |
| 7 | Je řízena životnost integrací (verze API, změny systémů). | ☐ | |
| 8 | Je veden registr změn a komunikace změn uživatelům. | ☐ | |
| 9 | Je vyhodnocen přínos vůči původním cílům a návrh další iterace. | ☐ | |
| 10 | Je aktualizována roadmapa a kapacitní plán. | ☐ |
| # | OVĚŘOVACÍ BOD | STAV (☐/☒) | POZNÁMKA / ODKAZ |
| 1 | Je provedeno vyhodnocení přínosů (benefits) vůči cílovým metrikám. | ☐ | |
| 2 | Je zpracováno shrnutí poučení (lessons learned) a doporučení. | ☐ | |
| 3 | Je aktualizována dokumentace a uložena do oficiálního úložiště. | ☐ | |
| 4 | Je uzavřen registr rizik a rozhodnutí; zůstávají pouze otevřené položky. | ☐ | |
| 5 | Je zajištěn přechod do běžného režimu řízení služby (ownership). | ☐ | |
| 6 | Je dohodnuta periodicita další revize služby. | ☐ | |
| 7 | Je ověřeno, že jsou splněny požadavky na archivaci a uchování záznamů. | ☐ | |
| 8 | Je vyhodnocen dopad na zaměstnance a potřeba dalšího školení. | ☐ | |
| 9 | Je vyhodnocen dopad na rozpočet a provozní náklady (pokud sledováno). | ☐ | |
| 10 | Je formálně uzavřen projekt / iniciativa (schválení uzavření). | ☐ |