¶ 1. Jak tuto metodiku používat
¶ 1.1 Účel kapitoly
Účelem kapitoly je stanovit závazný způsob, jak orgán veřejné moci používá metodiku Digital First při přípravě, realizaci a provozu digitální služby tak, aby rozhodnutí vznikala včas, existovaly prokazatelné důkazy (artefakty), bylo jasně odděleno řízení digitální služby od řízení ICT projektu a metodika byla použitelná v reálné praxi (včetně dodavatelského režimu).
¶ 1.1.1 Kdy je metodika povinná (praktická pravidla)
- Vzniká nová digitální služba nebo vzniká nový právní účinek / nové rozhodnutí.
- Dochází k nové nebo zásadní integraci (základní registry, platební brána, identita, notifikace) nebo se mění kritická integrace.
- Zpracovávají se citlivé údaje, mění se bezpečnostní klasifikace, role a oprávnění nebo se výrazně rozšiřuje útoková plocha.
- Mění se právní rámec služby, právně významné informace nebo podmínky poskytování služby (vyžaduje právní schválení).
- Změna vyžaduje migraci/cutover, nový provozní model, nové SLA/OLA nebo dopad na dostupnost kritických procesů.
- Rozsah je velký (více týmů/dodavatelů, více iterací) nebo nelze rychle prokázat přístupnost a kritické scénáře.
¶ 1.1.2 Kontext: Co znamená Digital First a hlavní přínosy
Digital First (digital by default) znamená, že digitální kanál je výchozí způsob poskytování nové nebo měněné služby; zároveň se zachovává alternativa pro uživatele, kteří digitální kanál využít nemohou.
- Rychlejší a efektivnější vyřízení (méně kroků, méně přepisů, méně papíru).
- Dostupnost 24/7 a lepší dosažitelnost služby pro občany a firmy.
- „Only once“: údaje, které stát má, se znovu nevyžadují – sdílí se kontrolovaně mezi OVM.
- Měřitelnost kvality: digitální službu lze průběžně monitorovat a zlepšovat na základě dat.
- Úspora nákladů a snížení chyb díky standardizaci a automatizaci.
¶ 1.2 Jaké rozhodnutí kapitola vynucuje
Orgán veřejné moci MUSÍ nejpozději před schválením projektového záměru formálně rozhodnout a doložit, že:
- MUSÍ – metodika Digital First je závazným rámcem pro rozhodování a kontrolu (nikoliv doporučení),
- MUSÍ – je zřízen a průběžně udržován evidence pack (složka důkazů) a decision log (rozhodovací stopa),
- MUSÍ – jsou nastaveny kontrolní brány a pravidla STOP/GO (zastavení a pokračování),
- MUSÍ – je určena odpovědnost za digitální službu (řízení služby) a současně je řízení dodávky vedeno dle Metodiky řízení ICT projektů (řízení projektu).
|
POZOR Pokud úřad nerozhodne podle této kapitoly, typicky vznikne projekt bez rozhodovací disciplíny: dodávky běží, ale nevznikají důkazy o zákonnosti, bezpečnosti, přístupnosti a provozní připravenosti. Důsledkem bývá stopka těsně před spuštěním nebo provozní incidenty po spuštění. |
¶ 1.3 Povinné výstupy / důkazy
TABULKA 1 – Povinné výstupy
| Název výstupu | Minimální obsah | Kdo odpovídá za existenci | Kdy MUSÍ existovat | Kde se vede |
| Rozhodnutí o závazném použití metodiky Digital First | Záznam rozhodnutí, rozsah (na jakou službu), datum, schvalovatel | Nositel projektu / Řídicí výbor projektu | Nejpozději při přípravě podkladů ke schválení projektového záměru | Repository projektu + spisová služba (pokud relevantní) |
| Plán aplikace metodiky (1–2 strany) | Seznam kontrolních bran, povinných artefaktů, harmonogram na úroveň fází, způsob správy rozhodnutí | Projektový manažer (PM) | Nejpozději před zahájením projektu (kick-off) | Repository projektu |
| Evidence pack – index | Index důkazů, odpovědné osoby za obsah, pravidla verzování, odkaz na umístění | PM (vedení) + přispěvatelé dle odpovědností | Nejpozději k první kontrolní bráně | Repository projektu |
| Decision log (log rozhodnutí) | ID rozhodnutí, popis, varianty, kritéria, kdo rozhodl, datum, dopad, odkazy na důkazy | PM (správa), Nositel (schvaluje klíčová rozhodnutí) | Průběžně od prvního rozhodnutí | Repository projektu |
| Mapa "řízení služby vs. řízení projektu" | Rozhraní: co je řízení služby (odpovědnost po spuštění) a co je řízení projektu (dodávka změny) | Nositel + PM | Nejpozději před zahájením projektu | Repository projektu |
| Kalendář kontrolních bran a účastníků | Termíny, účastníci, vstupy/výstupy, pravidlo STOP/GO, vazba na Řídicí výbor projektu | PM | Nejpozději po schválení projektového záměru a před detailním plánováním | Repository projektu |
|
ČASTÁ CHYBA Evidence pack se „slíbí“, ale není nikde fyzicky založený (chybí index a jednotné místo). Ve chvíli auditu nebo incidentu se pak dohledává „v e-mailech“ nebo „u dodavatele“. |
||||
¶ 1.4 Typická selhání z praxe
- Metodika se použije až na konci („udělejme checklist před spuštěním“), kdy už nejde levně změnit zásadní rozhodnutí.
- Záměna „řízení služby“ a „řízení projektu“: po ukončení projektu není určen vlastník provozních rozhodnutí, metrik a změn.
- Kontrolní brány jsou jen status meetingy bez práva STOP/GO.
- Dodavatel fakticky řídí rozhodnutí (úřad pouze „přebírá“), což vede k neobhajitelnosti a slabé odpovědnosti.
- Artefakty existují, ale nejsou prokazatelně schválené a navázané na rozhodnutí (chybí rozhodovací stopa).
- Projekt je řízen jen časem a rozpočtem, bez akceptačních kritérií, řízení rizik a eskalací.
|
DŮSLEDEK Selhání se typicky projeví jako zpoždění v závěru, právní blokace, bezpečnostní stopka, nepřístupnost, nárůst změn a dodatků nebo provozní incidenty po spuštění. V projektovém řízení se to projeví eskalacemi nad tolerance a krizovým rozhodováním. |
¶ 1.5 Hlavní obsah kapitoly
¶ 1.5.1 Jak s metodikou pracovat v každodenní praxi (pravidla používání)
Checklist – základní pravidla (MUSÍ / NESMÍ / MĚLO BY):
- MUSÍ – existovat jeden „zdroj pravdy“ pro dokumenty projektu a služby (repository) a musí být známý všem účastníkům.
- MUSÍ – existovat decision log a musí se aktualizovat při každém rozhodnutí s dopadem na rozsah, termín, rozpočet, právo, bezpečnost, provoz nebo UX.
- MUSÍ – být jasné, který dokument je podklad pro rozhodnutí a který je pouze pracovní.
- MUSÍ – být zavedena kontrola verzí (minimálně: datum, autor, stav, schválil).
- NESMÍ – se schvalovat prezentace bez podkladových artefaktů v evidence packu.
- NESMÍ – se považovat dodávka dodavatele za důkaz splnění povinnosti úřadu (úřad vždy odpovídá za rozhodnutí a jejich obhajitelnost).
- MĚLO BY – se používat jednotné šablony a jednotná pojmenování dokumentů napříč projekty (auditní stopa a předatelnost).
|
TIP Zaveďte pravidlo: „Žádné rozhodnutí bez odkazu na důkaz.“ V decision logu musí být u každého zásadního rozhodnutí minimálně jeden odkaz do evidence packu. |
¶ 1.5.2 Rozhraní "řízení digitální služby" a "řízení ICT projektu"
Rozhraní je závazné: metodika Digital First řídí obsah a kvalitu digitální služby; Metodika řízení ICT projektů řídí dodání změny jako projekt (role, odpovědnosti, fáze, eskalace, akceptace).
| Oblast | Kdo řídí (logika) | Kde se formálně rozhoduje | Co MUSÍ vzniknout jako důkaz |
| Smysl služby, uživatelé, výsledky a metriky | Řízení digitální služby | Rozhodnutí Nositele / Řídicího výboru projektu v rámci schvalování klíčových podkladů | Decision log + definice cíle a metrik (v evidence packu) |
| Dodání řešení (čas / rozpočet / rozsah) | Řízení ICT projektu | Řídicí výbor projektu, PM, eskalace dle tolerancí | Projektový plán / Plán řízení projektu + reporting |
| Rizika, eskalace, změnové řízení | Řízení ICT projektu | PM / Řídicí výbor, eskalace při překročení tolerancí | Registr rizik + záznam eskalací a rozhodnutí |
| Provoz po spuštění, udržitelnost přínosů | Řízení digitální služby (navazuje na předání) | Předání do následné podpory a udržitelného rozvoje | Vlastník výstupů + předávací protokol + plán provozu |
|
POZOR V rámci projektu NESMÍ vzniknout paralelní „řídicí struktura služby“, která by obcházela Řídicí výbor projektu nebo Projektovou komisi. Řízení služby je věcná odpovědnost za obsah a provoz, nikoliv nové projektové orgány. |
|||
¶ 1.5.3 Kontrolní brány – minimální pravidla STOP/GO
Kontrolní brána je formální bod, kdy se rozhoduje, zda je možné pokračovat do další části prací. Kontrolní brány MUSÍ být navázány na rozhodovací orgány projektu (zejména Řídicí výbor projektu).
| Kontrolní brána | [NÁZEV BRÁNY] |
| Evidence pack – MUSÍ | ☐ Seznam dokumentů (minimální sada): … ☐ Odkaz na evidence pack: … |
| Rozhodnutí – MUSÍ | STOP / GO Podmínky (pokud GO): … Termíny pro splnění podmínek: … |
| Role – MUSÍ | Vlastník přípravy podkladů (typicky PM): … Přispěvatelé dle odpovědností týmů: … |
| Zápis – MUSÍ obsahovat | Rozhodnutí (STOP/GO) Podmínky Termíny Odpovědné osoby Odkazy do evidence packu |
| NESMÍ | Informativní status bez možnosti změnit plán/rozsah nebo práce zastavit. |
| MĚLO BY | Jasná vazba do plánování: nesplněné vstupní podmínky ⇒ standardní reakce je přeplánování. |
|
ČASTÁ CHYBA Brána proběhne bez předem distribuovaných podkladů. Účastníci pak rozhodují bez možnosti ověřit důkazy. |
¶ 1.5.4 Evidence pack – povinná struktura (minimální standard)
Orgán veřejné moci MUSÍ vést evidence pack jako strukturované úložiště důkazů. Minimální struktura složek MUSÍ být:
- 00_Rozhodnutí_a_schválení (decision log, zápisy, schválení)
- 01_Definice_služby (definice, scope, metriky)
- 02_Právo_a_compliance (analýzy, stanoviska, výklady)
- 03_Procesy_a_data (mapy procesu, datové modely, evidenční vazby)
- 04_UX_obsah_přístupnost (výzkum, testy, výstupy přístupnosti)
- 05_Architektura_bezpečnost (architektura, klasifikace, bezpečnostní výstupy)
- 06_Provoz_a_podpora (provozní model, SLA/OLA, incidenty, monitoring)
- 07_Go-live_a_předání (go-live checklist, předávací protokoly, zvýšená podpora)
Minimální standard metadat pro každý dokument/důkaz v Evidence packu:
- Název dokumentu (co je obsahem) + ID/odkaz na službu/projekt.
- Verze a datum (kdy je dokument platný).
- Autor / vlastník (kdo odpovídá za obsah).
- Schválil (kdo dal go) + odkaz na rozhodnutí v Decision logu.
- Odkaz/umístění (repo/IS) – aby bylo dohledatelné při auditu.
|
DŮSLEDEK Bez jednotné struktury evidence packu nelze projekt předat, auditovat ani opakovat v jiné službě. V praxi to vede k ručnímu dohledávání, ztrátě znalostí a nárůstu závislosti na dodavateli. |
¶ 1.5.5 Pravidla práce s dodavatelem (aby nevznikl „dodavatelský stát“)
Checklist – minimální pravidla:
- MUSÍ – být stanoveno, které artefakty dodavatel povinně dodá jako podklady pro rozhodnutí (nejen jako výstupy implementace).
- MUSÍ – být stanoveno, které artefakty úřad vždy schvaluje a za které nese odpovědnost (zejména s právním, bezpečnostním a provozním dopadem).
- NESMÍ – být akceptace „díla“ zaměněna za akceptaci připravenosti služby k provozu (jsou to dvě různé věci).
- MĚLO BY – být vynuceno průběžné předávání znalostí (ne až na konci), aby předání do následné podpory bylo reálné.
¶ 1.5.6 Obrázky a schémata
Obrázek: "Dvojkolejné řízení: digitální služba x ICT projekt"
¶ 1.6 Vazba na řízení ICT projektu
Tato kapitola je závazně kompatibilní s Metodikou řízení ICT projektů:
- MUSÍ – respektovat existující projektové role a rozhodovací orgány (nevytváří nové paralelní procesy).
- MUSÍ – navazovat na životní cyklus projektu (předprojektové – projektové – poprojektové fáze).
- MUSÍ – používat stejné principy řízení: akceptační kritéria, řízení rizik a problémů, eskalace přes tolerance, formální akceptace a předání.
TABULKA 3 – Minimální napojení metodiky Digital First na fáze ICT projektu
| Fáze dle Metodiky řízení ICT projektů | Co MUSÍ zajistit použití Digital First (z pohledu této kapitoly) | Formální rozhodnutí / výstup |
| Předprojektové fáze (projektový záměr a příprava, schvalování projektového záměru) | Závazné nastavení metodiky, evidence pack, plán bran, rozhodovací stopa | Schválení rámce Řídicím výborem / podklady pro Projektovou komisi |
| Příprava projektu | Upřesnění kalendáře bran, doplnění indexu důkazů podle zvolené varianty realizace | Aktualizovaný plán aplikace metodiky uložen v repository |
| Zahájení projektu | Seznámení týmu s pravidly evidence packu a decision logu, potvrzení procedur reportingu a akceptace | Schválený plán řízení projektu + potvrzené procedury |
| Realizace projektu | Průběžná aktualizace decision logu, používání bran jako řídicího nástroje | Řídicí výbor rozhoduje, PM řídí a eskaluje dle pravidel |
| Vyhodnocení a ukončení projektu | Uzavření dokumentace, předání výstupů a vlastnictví, zajištění pokračování provozu | Akceptační protokol + předávací protokol + závěrečná zpráva |
| Následná podpora a udržitelný rozvoj | Řízení služby po spuštění (užívání, měření přínosů, odpovědi na dotazy a kontroly) | Předávací protokol potvrzen, vlastník výstupů vykonává odpovědnost |
¶ 2. Co je digitální služba
¶ 2.1 Účel kapitoly
Účelem kapitoly je závazně vymezit, co se v praxi orgánů veřejné moci považuje za digitální službu, jak se digitální služba odlišuje od ICT systému/projektu a jak se určuje její hranice, uživatelé a cíle. Kapitola zajišťuje, že úřad řídí „službu“ (uživatelskou cestu a výsledky), nikoliv pouze „systém“ (technickou dodávku).
¶ 2.2 Jaké rozhodnutí kapitola vynucuje
Orgán veřejné moci MUSÍ před zahájením detailních prací rozhodnout a doložit:
- MUSÍ – zda je iniciativa digitální službou, změnou existující digitální služby, nebo pouze podpůrným ICT projektem (bez přímé služby uživateli).
- MUSÍ – k jaké konkrétní službě (službám) se iniciativa vztahuje a jaký je očekávaný uživatelský výsledek (co se uživateli reálně zlepší).
- MUSÍ – hranici služby end-to-end: od spouštěcí situace (trigger) po doručení výsledku (včetně nedigitálních kroků, které ovlivňují zkušenost a lhůty).
- MUSÍ – kdo v organizaci nese věcnou odpovědnost za službu a kdo ponese odpovědnost za provoz a udržitelný rozvoj po spuštění (v návaznosti na vlastníka výstupů projektu).
- MUSÍ – minimální měření výsledku služby (metriky) a způsob, jak se data o službě budou získávat a vyhodnocovat.
|
POZOR Digitální služba není synonymum ICT systému. Za digitální službu se považuje uživatelská cesta a výsledek, který úřad uživateli poskytuje, bez ohledu na to, kolik systémů ji tvoří a zda část kroků probíhá nedigitálně. |
¶ 2.3 Povinné výstupy / důkazy
TABULKA 1 – Povinné výstupy pro vymezení digitální služby
| Výstup / důkaz | Minimální obsah | Kdo odpovídá za existenci | Kdy MUSÍ existovat | Použití (k čemu slouží) | Kde se vede |
| Karta digitální služby (Service card) | Název služby, poskytovatel, cíloví uživatelé, spouštěč, výsledek, kanály, základní proces, klíčové registry/data, klíčové závislosti, metriky, věcný vlastník | Nositel projektu ve spolupráci s věcným gestorem služby; správa v projektu: PM | Nejpozději před první kontrolní bránou v předprojektové fázi | Jasné vymezení „co je služba“ pro řízení rozsahu a rozhodování | Repository projektu (evidence pack) |
| Mapa hranice služby (End-to-end scope) | Začátek/konec služby, zahrnuté a vyloučené kroky, hranice odpovědnosti úřadu vs. externích subjektů, výjimky a alternativní scénáře | Věcný gestor služby; správa v projektu: PM | Nejpozději před zahájením analýz a návrhů řešení | Zabraňuje tomu, aby projekt řešil jen „UI“ a ignoroval zbytek služby | Repository projektu |
| Seznam uživatelských skupin a situací (User segments & scenarios) | Minimálně 3–5 typických situací uživatele, včetně okrajových (výjimky), a jejich očekávání | Věcný gestor služby; zapojení: UX/obsah | Nejpozději před návrhem řešení a zadáním dodavateli | Podklad pro rozsah, obsah, přístupnost a provozní scénáře | Repository projektu |
| Základní metriky a měření služby (KPI/Metrics) | Definice metrik, zdroj dat, periodicita, odpovědnost, výchozí stav (pokud existuje) | Věcný vlastník služby; technické zajištění: projektový tým | Nejpozději před schválením projektového záměru / před vstupem do realizace | Podklad pro přínosy, udržitelnost a řízení po spuštění | Repository projektu + reportingové místo organizace |
| Vazba na katalog služeb / evidenci služeb (pokud existuje v organizaci) | Jednoznačný identifikátor služby, verze, datum změny, vazba na agendu / právní titul (v základní úrovni) | Věcný vlastník služby; správa: určený správce katalogu | Nejpozději před go-live | Zajišťuje dohledatelnost a řízení životního cyklu služby | Katalog služeb / vnitřní evidence |
| Rozhraní „služba vs. projekt“ (RACI/odpovědnosti) | Kdo rozhoduje o obsahu služby, kdo rozhoduje o dodávce, kdo schvaluje změny, kdo nese odpovědnost po spuštění | Nositel projektu + PM (v návaznosti na metodiku ICT projektů) | Nejpozději při zahájení projektu | Zabraňuje paralelním strukturám a sporům o odpovědnost | Repository projektu |
¶ 2.4 Typická selhání z praxe
- Projekt je definován jako „vyvinout aplikaci“ nebo „pořídit systém“ bez popisu služby a uživatelského výsledku.
- Řeší se jen digitální formulář/portál, ale nikoliv end-to-end služba (např. navazující interní kroky, lhůty, komunikace, výjimky).
- Není určena věcná odpovědnost za službu; po ukončení projektu nikdo neřídí metriky, změny a provozní rozhodnutí.
- Služba se směšuje s interním systémem – pak se do rozsahu zahrnují technické položky, ale neřeší se kvalita služby pro uživatele.
- „Jedna služba“ se ve skutečnosti skládá z více služeb (nebo naopak) – bez rozhodnutí o hranici vzniká nekontrolovatelný rozsah a dodatky.
- Katalog/evidence služeb se nevede; stejné rozhodnutí se opakuje v každém projektu znovu a ztrácí se kontinuita po spuštění.
|
ČASTÁ CHYBA Hranice služby se stanoví jako „co se vejde do rozpočtu projektu“. Hranice služby se MUSÍ stanovovat podle toho, co uživatel považuje za dokončení své záležitosti a za co úřad nese odpovědnost, nikoliv podle toho, co je zrovna technicky pohodlné. |
¶ 2.5 Hlavní obsah kapitoly
¶ 2.5.1 Závazná definice digitální služby (praktická)
Digitální služba je taková služba orgánu veřejné moci, která splňuje současně:
- MUSÍ – mít identifikovatelného uživatele (občan, podnikatel, jiný OVM, interní pracovník v roli uživatele služby) a jeho spouštěcí situaci.
- MUSÍ – poskytovat uživateli konkrétní výsledek (rozhodnutí, potvrzení, zápis, vydání dokladu, provedení změny, informaci s právním dopadem apod.).
- MUSÍ – mít definované kanály a pravidla jejich kombinace (digitální kanál je primární, ale služba může mít i nedigitální kroky).
- MUSÍ – mít end-to-end proces, který je řízen jako jeden celek (i když je realizován více systémy a útvary).
- MUSÍ – mít určenu věcnou odpovědnost za kvalitu služby a odpovědnost za provozní rozhodnutí po spuštění.
Za digitální službu se naopak NESMÍ považovat pouze:
- NESMÍ – samostatný ICT systém bez přímé uživatelské cesty (např. čistě interní technická infrastruktura).
- NESMÍ – jednotlivá technická komponenta (API, integrace, datová migrace) bez vymezení služby, kterou podporuje.
- NESMÍ – pouhá digitalizace dokumentu (PDF) bez možnosti dokončit záležitost end-to-end nebo bez jasného uživatelského výsledku.
|
DŮSLEDEK Pokud je iniciativa chybně definována jako „systém“, projekt typicky splní dodávku, ale selže v provozu: uživatel nedokončí záležitost, úřad nezvládne výjimky, chybí odpovědnost za změny a měření přínosů. |
¶ 2.5.2 Rozlišovací tabulka: služba vs. podpůrný ICT projekt
TABULKA 2 – Rozlišení iniciativ (používat pro rozhodnutí v předprojektové fázi)
| Položka | Digitální služba | Změna existující služby | Podpůrný ICT projekt | Poznámka (praktické pravidlo) |
| Má uživatele a spouštěcí situaci? | ANO (povinné) | ANO (povinné) | Ne nutně | Bez uživatele nejde řídit službu – musí se navázat na konkrétní službu |
| Je definován uživatelský výsledek? | ANO (povinné) | ANO (povinné, včetně rozdílu proti stavu dnes) | Nepřímo (podpora výsledku jiné služby) | U podpůrného projektu musí být uvedeno, kterou službu a jak zlepšuje. |
| Měří se přínos pro uživatele? | ANO (povinné) | ANO (povinné) | Pouze technické metriky + dopad na službu | Bez metrik se z projektu stává „technická aktivita bez přínosu“. |
| Je nutné řešit kanály a výjimky? | ANO (povinné) | ANO (povinné) | Jen pokud dopadá na provoz služby | Výjimky (neúspěšné podání, nedoložení, chybná data) jsou součástí služby. |
| Kdo nese odpovědnost po spuštění? | Věcný vlastník služby + vlastník výstupů projektu (pro provoz) | Stejně | Vlastník výstupů projektu (pro provoz) + určený správce systému | Odpovědnost po projektu MUSÍ být určena předem, jinak vzniká provozní dluh. |
¶ 2.5.3 Jak správně vymezit hranici služby (end-to-end scope)
Checklist – vymezení hranice služby:
- MUSÍ – být popsán spouštěcí okamžik: co uživatel řeší a proč (např. změna stavu, povinnost, žádost, oznámení).
- MUSÍ – být popsán konec služby: kdy je uživatel „hotový“ (výsledek doručen, změna provedena, povinnost splněna).
- MUSÍ – být uvedeny všechny kanály a jejich role (digitální, přepážka, pošta, datová schránka, telefon, zastoupení).
- MUSÍ – být popsány interní kroky, které ovlivňují lhůty a výsledek (předání, kontrola, posouzení, schválení, archivace).
- MUSÍ – být uvedeny klíčové výjimky a alternativní průchody (neúplné podání, opravy, odvolání, nedoložení, zástupce).
- MUSÍ – být popsány závislosti na registrech a externích subjektech (kdo dodává data, kdo je spotřebovává, kdo rozhoduje).
- NESMÍ – být hranice vymezena jen „tím, co dodá dodavatel“ (hranice je věcná, ne dodavatelská).
|
TIP Vymezení hranice služby začínejte na papíře: 1) spouštěč, 2) výsledek, 3) kroky, 4) výjimky. Teprve potom rozhodujte o systému, integracích a UX. |
¶ 2.5.4 Minimální obsah karty digitální služby (povinné položky)
TABULKA 3 – Povinná pole karty digitální služby (vyplnit vždy)
| Položka | Povinnost | Jak to úřad reálně doloží | Typická chyba |
| Název služby a identifikátor | MUSÍ | Název + interní ID / ID v katalogu | Stejná služba má v různých projektech jiný název; ztrácí se kontinuita. |
| Uživatelé a situace (scénáře) | MUSÍ | Seznam segmentů + 3–5 scénářů včetně výjimek | Scénáře chybí; řeší se jen „standardní“ uživatel. |
| Spouštěč a výsledek | MUSÍ | Jednověté vyjádření spouštěče a výsledku + příklady výstupů | Výsledek je popsán jako „odeslání formuláře“ místo skutečného dokončení záležitosti. |
| End-to-end hranice | MUSÍ | Mapa kroků + vymezení začátku a konce + zahrnuto/vyloučeno | Hranice je jen frontend; interní kroky se neřeší. |
| Kanály a pravidla kombinace | MUSÍ | Seznam kanálů + kdy a proč se použijí + co je primární | Neřeší se přechody mezi kanály (např. digitál → přepážka). |
| Závislosti na datech a systémech | MUSÍ | Seznam registrů/systémů + vlastník + typ integrace (na úrovni „co potřebujeme“) | Závislosti se objeví až v realizaci → dodatky a skluz. |
| Metriky a měření | MUSÍ | Definice metrik + zdroj dat + periodicita + odpovědnost | Metriky jsou „přání“ bez zdrojů dat a bez odpovědnosti. |
| Odpovědnost po spuštění | MUSÍ | Určený věcný vlastník služby + vazba na vlastníka výstupů projektu a podporu | Po ukončení projektu není kdo rozhoduje o změnách a provozu |
¶ 2.5.5 Minimální sada metrik služby (bez ohledu na velikost projektu)
Orgán veřejné moci MUSÍ definovat minimálně následující typy metrik a způsob jejich měření:
- MUSÍ – objem a dokončenost: počet zahájených a dokončených případů/podání; míra nedokončení (drop-off).
- MUSÍ – čas: doba od zahájení služby po výsledek (včetně čekání na uživatele, pokud je relevantní).
- MUSÍ – kvalita: chybovost (vrácení, opravy, neúplnost), počet kontaktů na podporu k jedné záležitosti.
- MUSÍ – dostupnost a stabilita: základní provozní metriky (výpadky, degradace), pokud je služba digitálně poskytována.
- MUSÍ – přístupnost a obsah: prokazatelné ověření splnění požadavků přístupnosti a srozumitelnosti pro klíčové scénáře (důkaz, ne deklarace).
|
POZOR Metrika bez zdroje dat není metrika. U každé metriky MUSÍ být určeno: odkud data vezmeme, jak často je vyhodnotíme a kdo za to odpovídá. |
¶ 2.6 Vazba na řízení ICT projektu
Vymezení digitální služby je věcný podklad pro řízení ICT projektu a MUSÍ být dokončeno v předprojektové fázi tak, aby bylo možné schválit projektový záměr s jasným rozsahem a přínosy. Kapitola neustanovuje nové projektové role ani paralelní procesy.
TABULKA 4 – Jak se artefakty digitální služby promítají do řízení ICT projektu
| Artefakt služby | Použití v projektu (Metodika řízení ICT projektů) | Kdo s tím pracuje v projektu | Kontrolní bod / brána |
| Karta digitální služby | Vstup do projektového záměru a do definice rozsahu; základ pro akceptační kritéria přínosů | Nositel projektu, PM, Řídicí výbor projektu | Schválení projektového záměru (předprojektová fáze) |
| Mapa hranice služby (end-to-end scope) | Podklad pro plánování, řízení rozsahu a změnové řízení; snižuje riziko dodatků | PM, věcný gestor, dodavatel (jako vstup) | Brána před zahájením realizace / před závazným zadáním |
| User segments & scenarios | Podklad pro akceptační kritéria, testování a převzetí; rizika a výjimky | PM, řešitelské týmy, dodavatel, Řídicí výbor (při sporech o rozsah) | Brána před převzetím a před go-live |
| Metriky a měření služby | Podklad pro závěrečnou zprávu, vyhodnocení projektu a udržitelnost; předání do podpory a udržitelného rozvoje | Nositel projektu, vlastník výstupů projektu, PM | Ukončení projektu a předání do následné podpory a udržitelného rozvoje |
| Rozhraní služba vs. projekt (odpovědnosti) | Zajišťuje správné eskalace a rozhodnutí (Řídicí výbor, případně Projektová komise dle pravidel) | Nositel projektu, PM, Řídicí výbor projektu | Při zahájení projektu a při každé významné změně rozsahu |
|
POZOR Projekt MUSÍ být řízen podle Metodiky řízení ICT projektů (životní cyklus, role, brány, eskalace). Digital First doplňuje obsahové požadavky na službu a stanoví, jaké věcné důkazy musí být k rozhodnutím předloženy. |
|||
¶ 3. Rozhodnutí před zahájením
¶ 3.1 Účel kapitoly
Účelem kapitoly je vynutit minimální, formálně doložená rozhodnutí před zahájením realizace digitální služby (zejména před zadáním dodavateli, zahájením vývoje nebo podpisem smluvních závazků). Kapitola zajišťuje, že úřad vstupuje do realizace s jasně vymezenou službou, právní a procesní proveditelností, zajištěnými daty a odpovědnostmi, připraveným provozem a měřením přínosů. Kapitola je navržena pro reálnou praxi veřejné správy, kde se běžně kombinuje interní kapacita, dodavatelský režim, více dotčených útvarů a povinnosti vůči občanům a kontrolním orgánům.
¶ 3.2 Jaké rozhodnutí kapitola vynucuje
Orgán veřejné moci MUSÍ před zahájením realizace (nejpozději před vyhlášením/výběrem dodavatele na implementaci) rozhodnout a doložit:
- MUSÍ – vymezení digitální služby a její hranice end-to-end (co přesně je předmětem změny a co ne).
- MUSÍ – cílový uživatelský výsledek a minimální metriky (jak poznáme, že služba funguje a zlepšila se).
- MUSÍ – právní proveditelnost: zda lze službu provozovat v cílovém režimu bez změny práva, nebo jaké změny jsou nezbytné a kdo je zajistí.
- MUSÍ – procesní a datovou proveditelnost: jak bude úřad rozhodovat, z jakých dat/registrů čerpá a kdo je vlastníkem zdrojových dat.
- MUSÍ – architektonické a bezpečnostní mantinely: klasifikaci dopadů, požadovanou úroveň ochrany a klíčové integrace.
- MUSÍ – provozní model: kdo službu vlastní po spuštění, jak bude zajištěna podpora, monitoring, incident management a udržitelný rozvoj.
- MUSÍ – dodavatelský a smluvní přístup: co bude předmětem zakázky, jaká jsou akceptační kritéria, jak se bude přebírat a jak se zabrání vendor lock-inu.
- MUSÍ – způsob řízení změn, rizik a tolerancí (kdy a jak se eskaluje, kdo může zastavit práce).
- NESMÍ – začít implementace bez kompletního rozhodovacího balíčku (Start pack) definovaného v této kapitole.
|
POZOR Rozhodnutí „zahájit realizaci“ je závazek úřadu, nikoliv jen projektový milník. Bez splnění minimálních rozhodnutí vzniká typicky dodavatelsky řízený projekt s dodatky, skluzy a neobhajitelnými rozhodnutími. |
¶ 3.3 Povinné výstupy / důkazy
TABULKA 1 – Start pack (povinné důkazy před zahájením realizace)
| Výstup / důkaz | Minimální obsah | Kdo odpovídá za existenci | Kdy MUSÍ existovat | Použití (k čemu slouží) | Kontrolní bod (brána) |
| Karta digitální služby (Service card) | Název, uživatelé, spouštěč, výsledek, kanály, hranice, klíčová data/registry, metriky, věcný vlastník | Nositel projektu + věcný gestor služby; správa: PM | Před schválením zahájení realizace | Definuje, co se skutečně realizuje a proč | Předprojektová brána – rozhodnutí o zahájení realizace |
| Mapa end-to-end hranice služby | Zahrnuto/vyloučeno, výjimky, interní kroky, závislosti, předání mezi útvary | Věcný gestor služby; správa: PM | Před zadáním implementace | Zabraňuje tomu, aby se řešil jen frontend | Před zadáním implementace / před zahájením vývoje |
| Rozhodovací memorandum „Start realizace“ | Shrnutí rozhodnutí, varianty a důvody, dopady na rozsah/čas/rozpočet, seznam podmínek, rozhodl | Nositel projektu; formální schválení: Řídicí výbor projektu | Bezprostředně před zahájením realizace | Jasná odpovědnost a auditní stopa | Rozhodnutí Řídicího výboru projektu |
| Právní proveditelnost (minimální právní stanovisko) | Právní titul/agenda, povinnosti, lhůty, omezení, potřeba legislativní změny (ANO/NE) + plán zajištění | Gestor práva / právní útvar; vlastníkem je úřad | Před zahájením realizace a před výběrem technického řešení s právním dopadem | Zabraňuje realizaci neprovozovatelné služby | Předprojektová brána |
| Procesní a datová proveditelnost (L0/L1) | Mapa procesu (min. L0), rozhodovací body, vstupy/výstupy, datové zdroje, vlastník dat, kvalita a dostupnost | Věcný gestor služby + datoví vlastníci; koordinace: PM | Před zadáním implementace | Zajišťuje reálnou proveditelnost a předchází dodatkům | Brána před realizací |
| UX a přístupnost – minimální plán a kritéria | Klíčové scénáře, obsahové zásady, přístupnostní kritéria pro převzetí, plán testování s uživateli | Věcný gestor služby + UX/obsah; koordinace: PM | Před zadáním implementace | Umožní převzít službu podle jasných kritérií | Brána před realizací a brána před převzetím |
| Bezpečnostní a provozní rámec (minimální) | Klasifikace dopadů, požadavky na ochranu, základní provozní scénáře, monitoring, incidenty, role podpory, přístupová politika | Bezpečnostní role/útvar + provoz; koordinace: PM | Před zahájením realizace | Zabraňuje „provozu na poslední chvíli“ | Brána před realizací |
| Dodavatelská a smluvní strategie (implementace) | Co se soutěží, jak se přebírá, akceptační kritéria, evidence povinností dodavatele, podmínky předání znalostí, práva k výstupům | PM + nákup/veřejné zakázky; schvaluje Řídicí výbor projektu dle pravidel | Před zahájením zadávacího řízení / před podpisem | Zabraňuje smlouvám bez převzetí a bez provozních záruk | Brána před zahájením realizace |
| Počáteční registr rizik a tolerancí | Top rizika, vlastníci, mitigace, eskalační pravidla, tolerance času/rozpočtu/rozsahu | PM; schvaluje Řídicí výbor projektu | Před zahájením realizace | Řízení podle tolerancí, ne podle „pocitu“ | Rozhodnutí Řídicího výboru projektu |
¶ 3.4 Typická selhání z praxe
- Zahájení výběru dodavatele na implementaci bez vymezení služby a bez dohodnuté hranice end-to-end.
- Právní posouzení se dělá až po návrhu řešení; následně se zjistí, že cílový režim není legální nebo vyžaduje změnu práva.
- Procesní analýza je nahrazena „workshopem se systémovým integrátorem“; vnitřní kroky a výjimky se objeví až v provozu.
- Data nemají vlastníka (nikdo neručí za kvalitu a dostupnost); integrace se plánují bez dohody s poskytovateli dat.
- Provozní model neexistuje; těsně před spuštěním se narychlo shání podpora, monitoring a odpovědnosti.
- Smlouva je nastavena na dodání funkcionalit, ale neobsahuje akceptační kritéria služby, přístupnost, předání znalostí a provozní scénáře.
- Rozsah se vymezí podle rozpočtu nebo podle nabídky dodavatele; výsledkem je nedokončená služba a tlak na dodatky.
- Nejsou nastavené tolerance a eskalace; projekt se řídí až krizově při skluzu nebo problému.
|
ČASTÁ CHYBA „Start realizace“ se zamění za interní kick-off. V praxi pak rozhodnutí o zahájení nikdo formálně neudělal a v případě kontroly nelze prokázat, proč se postupovalo daným způsobem a kdo to schválil. |
|
DŮSLEDEK Uvedená selhání vedou typicky k dodatkování, skluzu na konci, bezpečnostní nebo právní stopce před spuštěním, a k provoznímu dluhu (služba je spuštěna, ale bez vlastníka a bez řízení změn). |
¶ 3.5 Hlavní obsah kapitoly
¶ 3.5.1 Checklist připravenosti před zahájením realizace (STOP/GO)
Následující checklist MUSÍ být splněn a doložen.
Jakákoliv položka „NESPLNĚNO“ znamená STOP (zahájení realizace se neodsouhlasí).
- MUSÍ – existovat Karta digitální služby a mapa hranice služby schválená věcným gestorem a odsouhlasená v řízení projektu.
- MUSÍ – existovat právní stanovisko potvrzující proveditelnost cílového režimu (nebo formálně schválený plán legislativních kroků s odpovědností a termíny).
- MUSÍ – existovat procesní a datová mapa (min. L0) včetně vlastníků dat a potvrzení dostupnosti zdrojů dat pro realizaci.
- MUSÍ – být definována minimální sada metrik a způsob sběru dat (zdroj, periodicita, odpovědnost).
- MUSÍ – být definována akceptační kritéria služby (včetně přístupnosti a klíčových scénářů) pro převzetí a go-live.
- MUSÍ – být stanovena bezpečnostní a provozní minimální pravidla (klasifikace dopadů, přístupy, monitoring, incidenty, podpora).
- MUSÍ – existovat dodavatelská a smluvní strategie včetně toho, jak se přebírají výstupy a znalosti a jak se řeší změny.
- MUSÍ – existovat počáteční registr rizik a nastavené tolerance a eskalační pravidla pro Řídicí výbor projektu.
- NESMÍ – být zahájena implementace, pokud je otevřený spor o hranici služby, vlastníka služby nebo o datové zdroje.
¶ 3.5.2 Rozhodovací mapa před zahájením (co musí být rozhodnuto a kým)
TABULKA 2 – Rozhodovací oblasti a minimální otázky
| Oblast | Minimální otázka, na kterou musí být odpověď | Varianty (typicky) | Kdo rozhoduje (v rámci řízení projektu) | Důkaz (artefakt) | Co se stane, když chybí |
| Vymezení služby | Co je přesně služba a kde začíná/končí? | Jeden end-to-end proces / sada dílčích služeb / pouze podpůrný projekt | Nositel + Řídicí výbor projektu (na návrh věcného gestora) | Karta služby + mapa hranice + Decision log | Rozsah se rozpadá a realizace se řídí dodavatelem. |
| Právo a compliance | Je cílový režim legální a provozovatelný? | Bez změny práva / s legislativní změnou / nelze provozovat | Nositel + Řídicí výbor projektu (podklad právního útvaru) | Právní stanovisko + seznam povinností | Právní stopka před spuštěním nebo provoz mimo zákon. |
| Proces a data | Kdo rozhoduje v procesu a z jakých dat? | Využití registrů / vlastní evidence / kombinace / sdílení s jiným OVM | Nositel + Řídicí výbor projektu (podklad věcného gestora a datových vlastníků) | Procesní mapa + datová mapa + potvrzení vlastníků | Změny a integrace se objeví až v realizaci → dodatky. |
| UX, obsah, přístupnost | Jaké scénáře musí fungovat a podle čeho službu převezmeme? | Minimální scénáře + výjimky / postupné rozšiřování v iteracích | Řídicí výbor projektu (akceptační kritéria); zpracování: věcný gestor + UX/obsah | Akceptační kritéria + plán testování | Nelze převzít; vzniká spor „splnili jsme / nesplnili“. |
| Architektura a bezpečnost | Jaké jsou mantinely a povinnosti ochrany? | Centrální platformy / vlastní řešení / integrace / refaktor stávajícího | Řídicí výbor projektu (na základě architektury a bezpečnosti) | Bezpečnostní rámec + architektonické rozhodnutí | Bezpečnostní stopka nebo nákladné předělávky. |
| Provoz a podpora | Kdo službu provozuje a jak se bude řešit incident? | Interní provoz / externí / hybrid + jasné rozhraní | Nositel + Řídicí výbor projektu | Provozní koncept + předávací model | Služba je spuštěna bez podpory; incidenty eskalují mimo řízení. |
| Dodavatelský přístup | Co přesně soutěžíme a jak přebíráme? | Implementace na klíč / postupné dodávky / integrátor + dílčí dodávky | Řídicí výbor projektu dle pravidel organizace | Soutěžní dokumentace + akceptační kritéria + pravidla změn | Dodatkování a vendor lock-in. |
|
POZOR Rozhodnutí před zahájením MUSÍ být rozhodnutelná: pokud není dohoda s datovými vlastníky nebo s provozem, nejde zahájit realizaci a projekt se musí vrátit do přípravy. |
|||||
¶ 3.5.3 Dodavatelské a smluvní minimum (co MUSÍ být ve smlouvě / zadání)
Checklist – minimální povinné prvky v zadání a smlouvě na implementaci digitální služby:
- MUSÍ – být definován předmět plnění jako služba a její scénáře (ne pouze seznam funkcionalit).
- MUSÍ – být definována akceptační kritéria: funkční scénáře, výjimky, výkonové a provozní scénáře, přístupnostní kritéria, bezpečnostní požadavky.
- MUSÍ – být definováno, co je „hotovo“ (Definition of Done) včetně dokumentace, předání znalostí, konfigurací a provozních postupů.
- MUSÍ – být definována pravidla změn (change requests), včetně toho, kdo schvaluje změnu a jak se oceňuje a plánuje.
- MUSÍ – být zajištěna práva k výstupům a možnost pokračovat s jiným dodavatelem (předání zdrojů, dokumentace, prostředí, přístupů).
- MUSÍ – být definován režim součinnosti úřadu (včetně dostupnosti věcného gestora, datových vlastníků a bezpečnosti).
- NESMÍ – být akceptace plnění založena pouze na formálním předání bez prokázání splnění scénářů a kritérií.
|
ČASTÁ CHYBA Smlouva neobsahuje akceptační kritéria pro přístupnost a provozní scénáře. Pak je služba „dodána“, ale nelze ji bezpečně převzít do provozu. |
¶ 3.5.4 Tolerance a eskalace – minimální nastavení před startem
TABULKA 3 – Minimální tolerance, které MUSÍ být stanoveny před zahájením realizace (používají se pro eskalaci v řízení projektu)
| Oblast tolerance | Co se sleduje | Kdo sleduje | Kdy se eskaluje (pravidlo) | Kdo rozhodne (typicky) |
| Čas | Odchylka od harmonogramu na klíčových milnících | PM | Překročení nastavené tolerance nebo ohrožení go-live | Řídicí výbor projektu (případně Projektová komise dle pravidel) |
| Rozpočet | Odchylka čerpání, dopady změn, náklady na provoz | PM + ekonomika | Překročení tolerance nebo nutnost dodatku | Řídicí výbor projektu |
| Rozsah služby | Změny scénářů, hranice služby, povinné výstupy | PM + věcný gestor | Jakákoliv změna hranice služby nebo povinných scénářů | Řídicí výbor projektu |
| Právo / compliance | Nové právní riziko nebo změna interpretace | Právní útvar + PM | Vznik rizika neprovozovatelnosti cílového režimu | Nositel + Řídicí výbor projektu |
| Bezpečnost / provoz | Změna bezpečnostních požadavků, zjištěná neprovozuschopnost | Bezpečnost + provoz + PM | Zjištění, že nelze splnit požadovanou úroveň ochrany nebo provozní připravenost | Řídicí výbor projektu (STOP/GO) |
|
TIP Tolerance se nastavují tak, aby se eskalovalo včas. Pokud se eskaluje až „na konci“, jde o krizové řízení, ne o řízení projektu. |
||||
¶ 3.5.5 Pravidla „NESMÍ SE ZAČÍT“ (No-go pravidla)
Následující situace znamenají, že realizace NESMÍ být zahájena, dokud nejsou odstraněny:
- NESMÍ – chybět věcný vlastník služby nebo dohoda o odpovědnosti po spuštění (včetně podpory).
- NESMÍ – existovat nevyřešený spor o hranici služby nebo o povinné scénáře (včetně výjimek).
- NESMÍ – chybět právní stanovisko nebo je-li závěr „nelze provozovat“ bez schváleného plánu změny práva.
- NESMÍ – být neznámý nebo nepotvrzený vlastník klíčových dat/registrů, na kterých služba závisí.
- NESMÍ – být zadání/smlouva bez akceptačních kritérií a bez pravidel změnového řízení.
- NESMÍ – být nejasné, kdo bude službu provozovat a jak se bude řešit incident (včetně kontaktů a odpovědností).
¶ 3.6 Vazba na řízení ICT projektu
Rozhodnutí této kapitoly jsou součástí předprojektových fází a slouží jako závazné vstupy pro schválení projektového záměru a pro zahájení projektu/realizace dle Metodiky řízení ICT projektů. Kapitola nevytváří nové projektové role ani paralelní procesy; vyžaduje pouze, aby Řídicí výbor projektu (a případně Projektová komise dle interních pravidel) rozhodoval na základě prokazatelných věcných důkazů.
TABULKA 4 – Mapování Start packu na fáze a formální rozhodnutí projektu
| Fáze dle Metodiky řízení ICT projektů | Co se má rozhodnout | Jaký důkaz musí být předložen | Kdo formálně rozhoduje |
| Předprojektová fáze – příprava projektového záměru | Je to digitální služba (a jak je vymezena) a je proveditelná? | Karta služby + mapa hranice + právní minimum + proces/data minimum | Nositel + Řídicí výbor projektu |
| Předprojektová fáze – schválení projektového záměru | Schválení přínosů, metrik a základních mantinelů; rozhodnutí o pokračování | Rozhodovací memorandum + metriky + počáteční rizika/tolerance | Řídicí výbor projektu (případně Projektová komise dle pravidel) |
| Příprava projektu / zahájení projektu | Nastavení dodavatelského přístupu, akceptace, změn a eskalací | Dodavatelská strategie + akceptační kritéria + pravidla změn | Řídicí výbor projektu |
| Zahájení realizace (start implementace) | STOP/GO: je kompletní Start pack a jsou odstraněny no-go podmínky? | Uzavřený Start pack v evidence packu + Decision log | Řídicí výbor projektu (STOP/GO) |
|
POZOR Pokud Řídicí výbor projektu odsouhlasí zahájení realizace bez Start packu, přebírá úřad riziko neobhajitelného postupu. V takovém případě MUSÍ být v Decision logu výslovně uvedeno, co chybí, proč se pokračuje a jak se riziko mitigovalo. |
|||
¶ 4. Právo jako konstrukční prvek
¶ 4.1 Účel kapitoly
Účelem kapitoly je vynutit, aby právo nebylo pouze „kontrola na konci“, ale aby bylo používáno jako konstrukční prvek digitální služby: tj. aby právní povinnosti, lhůty, oprávnění, důkazní standardy, doručování, zastupování, poplatky, archivace a ochrana údajů byly přeloženy do konkrétních požadavků na službu, proces, data, UX a provoz. Kapitola zajišťuje, že úřad nevstoupí do realizace bez doložené právní proveditelnosti cílového režimu a bez rozhodnutí o legislativních krocích, pokud jsou nutné.
¶ 4.2 Jaké rozhodnutí kapitola vynucuje
Orgán veřejné moci MUSÍ před zahájením realizace rozhodnout a doložit zejména:
- MUSÍ – jaký je právní titul poskytování služby (agenda / právní předpis / oprávnění úřadu) a jaký je právní účinek digitálního úkonu (co se právně stane).
- MUSÍ – zda cílový digitální režim lze provozovat bez změny práva; pokud ne, MUSÍ být schválen plán legislativních změn (co, kdo, kdy, jaké riziko).
- MUSÍ – jak se prokazuje identita a oprávnění jednající osoby (identifikace, autentizace, zastoupení, role) a jak se vede důkazní stopa.
- MUSÍ – jak se řeší doručování, lhůty a právní fikce (včetně alternativních kanálů a výjimek).
- MUSÍ – jaké údaje se zpracovávají a na jakém právním základě (včetně minimalizace, účelu, doby uchování, předávání a zveřejnění).
- MUSÍ – jaké dokumenty/výstupy jsou úřední záznamy a jak se archivují (spisová služba, skartační režim, auditní stopa).
- MUSÍ – jaké právní požadavky se promítají do akceptačních kritérií (právní účinek úkonu, doručení, validita podpisu, vedení spisu, evidence)
- NESMÍ – zahájit realizaci, pokud právní posouzení identifikuje nepřeklenutelnou překážku cílového režimu nebo chybí rozhodnutí o její nápravě.
|
POZOR Právo se v digitální službě „implementuje“. Pokud není právní účinek úkonu a důkazní stopa navržena předem, nelze službu bezpečně převzít do provozu a nelze ji obhájit v řízení (např. při sporu, odvolání, kontrole). |
¶ 4.3 Povinné výstupy / důkazy
TABULKA 1 – Legal pack (povinné právní důkazy pro digitální službu)
| Výstup / důkaz | Minimální obsah | Kdo odpovídá za existenci | Kdy MUSÍ existovat | Použití (k čemu slouží) | Kontrolní bod (brána) | Kde se vede |
| Právní inventura služby (Legal inventory) | Seznam relevantních právních předpisů, povinností a právních účinků; role a oprávnění; lhůty; poplatky; doručování; opravné prostředky | Právní útvar / gestor práva; vlastníkem je úřad | V předprojektových fázích, před schválením projektového záměru | Základní „mapa práva“ pro návrh služby a rozsah | Schvalování projektového záměru | Evidence pack – Právo a compliance |
| Rozhodnutí o právní proveditelnosti cílového režimu | Závěr: lze / lze s podmínkami / nelze; identifikované překážky; podmínky a rizika; schválil | Nositel projektu (rozhodnutí), podklad: právní útvar | Nejpozději před zahájením realizace (Start realizace) | STOP/GO rozhodnutí pro zahájení realizace | Rozhodnutí Řídicího výboru projektu | Decision log + zápis |
| Plán legislativních kroků (pokud relevantní) | Co se mění, důvod, odpovědný gestor, termíny, závislosti, dopady na projekt, rizika a mitigace | Nositel projektu + gestor legislativy; koordinace: PM | Před zahájením realizace, pokud je potřeba změna práva | Zajištění, že projekt nevyvíjí neprovozovatelný režim | Schválení projektového záměru / Start realizace | Evidence pack – Právo a compliance + registr rizik |
| Matice právních povinností → požadavky (Legal traceability) | Každá povinnost má: popis, dopad na proces/UX/data/provoz, požadavek, test/ověření, odpovědnost | Právní útvar + věcný gestor; správa: PM | Před zadáním implementace; u změn průběžně | Zabraňuje „právu v PDF“ bez implementace | Brána před realizací a před převzetím | Evidence pack – Právo + Testy/akceptace |
| Rozhodnutí o identitě, oprávnění a zastoupení | Jak se ověřuje identita; jak se ověřuje oprávnění (role); jak se řeší zastoupení; logování; výjimky | Věcný gestor + bezpečnost + právní útvar; schvaluje Řídicí výbor projektu | Před návrhem detailního řešení a před implementací přihlášení/rolí | Zajišťuje právní platnost úkonů a obranu proti zneužití | Brána před realizací | Evidence pack – Právo + Bezpečnost + UX |
| Režim doručování a lhůt (včetně fikcí) | Kanály, pravidla doručení, okamžiky účinku, výjimky, evidence o doručení, návazné úkony | Právní útvar + věcný gestor; koordinace: PM | Před návrhem komunikace a UX; před implementací notifikací | Zajišťuje právní účinnost komunikace | Brána před realizací a před go-live | Evidence pack – Právo + Provoz |
| DPIA / posouzení ochrany osobních údajů (je-li vyžadováno) | Rozsah, rizika, opatření, zbytkové riziko, schválení, návaznost na bezpečnostní opatření | Pověřenec/odpovědný útvar ochrany údajů; spolupráce: bezpečnost + projekt | Před zahájením realizace v relevantních případech | Prokazuje řízení rizik zpracování | Brána před realizací / před go-live (dle povahy) | Evidence pack – Právo a compliance + Bezpečnost |
| Pravidla uchování a evidence (spisová služba, auditní stopa) | Co je dokument/úřední záznam, kde vzniká, jak se ukládá, doba uchování, skartace, přístupová práva, audit | Spisová služba/archiv + věcný gestor + právní; koordinace: PM | Před implementací a před převzetím | Zajišťuje dohledatelnost a zákonnou evidenci | Brána před převzetím a go-live | Evidence pack – Provoz + Právo |
| Texty pro uživatele s právním významem (notices) | Poučení, prohlášení, souhlasy (pouze pokud jsou legální), informace o zpracování údajů, podmínky, práva uživatele | Věcný gestor + právní + obsah/UX | Před testováním a před go-live | Zajišťuje srozumitelnost a právní účinek informací | Brána před go-live | Evidence pack – UX/obsah + Právo |
|
TIP Legal pack MUSÍ být řízen jako „živý“: každá legislativní nebo výkladová změna se promítne do traceability matice a do Decision logu (co se změnilo, dopad, rozhodnutí). |
||||||
¶ 4.4 Typická selhání z praxe
- Právní posouzení se dělá až po návrhu řešení nebo těsně před spuštěním („ať to právní teď zkontroluje“).
- Služba se navrhne podle technických možností a teprve pak se hledá „jak to právně obhájit“.
- Uživatelský výsledek je zaměněn za odeslání formuláře, ale právní účinek (zahájení řízení, doručení, běh lhůt) není navržen.
- Zastoupení a oprávnění nejsou řešeny (rodinní příslušníci, statutáři, zmocněnci) – následně vznikají obcházení a spory.
- Doručování a právní fikce se ignorují: systém nemá důkaz o doručení nebo neví, kdy nastal účinek.
- Ochrana osobních údajů je řešena „souhlasem“, i když pro veřejnou moc typicky není vhodným právním základem pro hlavní zpracování.
- Spisová služba a archivace se neřeší: dokumenty zůstávají v aplikaci bez vazby na spis; auditní stopa je nedostatečná.
- Smlouva s dodavatelem neobsahuje povinnost dodat právně relevantní důkazy (logy, exporty, dokumentaci).
|
ČASTÁ CHYBA Úřad zamění „právní analýzu“ za seznam paragrafů. Analýza MUSÍ končit konkrétními implementačními požadavky a ověřovacími scénáři (co se musí v systému prokázat). |
|
DŮSLEDEK Právní selhání se projeví nejdražší možné chvíli: těsně před go-live (stopka), nebo po spuštění (spor, námitka, odvolání, incident). Náklady pak typicky nesouvisí s úpravou obrazovek, ale s předěláním procesu, evidence a provozních postupů. |
¶ 4.5 Hlavní obsah kapitoly
¶ 4.5.1 Postup: přeložení práva do návrhu služby (Legal-to-Design workflow)
Postup je závazný minimálně v následujících krocích:
- MUSÍ – vzniknout právní inventura (povinnosti, účinky, lhůty, doručování, role, opravné prostředky).
- MUSÍ – každá právní povinnost být přiřazena ke konkrétnímu kroku end-to-end procesu (kde se uplatní).
- MUSÍ – z právní povinnosti vzniknout implementační požadavek (na UX, data, logování, provoz) a ověřovací scénář (test).
- MUSÍ – existovat rozhodnutí, zda a jak se řeší výjimky (neúplné podání, zastoupení, odmítnutí, doplnění).
- MUSÍ – být stanoveno, co je „právně relevantní důkaz“ (logy, časové razítko, doručení, podpis, vazba na spis).
- MĚLO BY – být proveden minimálně jeden společný workshop: právní + věcný gestor + UX/obsah + bezpečnost + provoz (z důvodu provázanosti).
|
POZOR „Právně relevantní důkaz“ není screenshot. Úřad MUSÍ být schopen doložit: kdo jednal, kdy, s jakým oprávněním, co bylo podáno/doručeno, jaký nastal účinek a kde je to uloženo ve spisu/evidenci. |
¶ 4.5.2 Typy právních požadavků a jejich dopady (praktická mapa)
TABULKA 2 – Typy právních požadavků → co to znamená pro službu
| Typ právního požadavku | Typický dopad na proces | Typický dopad na data a evidenci | Typický dopad na UX/obsah | Typický dopad na provoz |
| Právní účinek úkonu (zahájení, změna, rozhodnutí) | Definice okamžiku účinku; navazující kroky a lhůty | Evidence o úkonu, čas, identita, obsah, vazba na spis | Srozumitelné potvrzení, poučení, stav řízení | Auditní stopa, export důkazů, incidenty se stopou |
| Doručování a fikce | Kanály doručení, pravidla doručení, opakování, výjimky | Důkaz o doručení, časové značky, identifikace adresáta | Texty o doručení, upozornění, stav doručení | Monitoring doručování, opakování, eskalace |
| Zastoupení a oprávnění | Role, delegace, kontrola oprávnění před úkonem | Evidence oprávnění, vazby na registr/zdroj, log přístupu | Výběr role, informace o oprávnění, odmítnutí s důvodem | Správa rolí, revize oprávnění, incidenty zneužití |
| Lhůty a procesní úkony (doplnění, odvolání) | Běh lhůt, přerušení, doplnění, rozhodnutí o odmítnutí | Evidence lhůt, stavů, úkonů a rozhodnutí | Zobrazení termínů, poučení, výzvy k doplnění | SLA/OLA na vyřízení, eskalace kapacit |
| Poplatky a platby (pokud relevantní) | Vznik povinnosti, vrácení, výjimky, potvrzení | Evidence platby, vazba na případ, doklad | Jasné informace, potvrzení, stav platby | Napojení na ekonomiku, reconciliation, výpadky |
| Ochrana údajů (účel, minimalizace, uchování) | Zpracování jen nezbytných údajů, sdílení a přístup | Katalog údajů, doby uchování, přístupové politiky | Informování uživatele, práva subjektu údajů (pokud relevantní) | Řízení přístupů, logování, reakce na incidenty |
| Spisová služba a archivace | Zařazení do spisu, úřední záznamy, uzavírání spisu | Ukládání dokumentů, metadata, skartace | Uživateli se neprezentují interní evidenční detaily; jen relevantní potvrzení | Exporty, integrace se spisovou službou, audit |
¶ 4.5.3 Minimální standard Legal traceability (povinné pole matice)
Matice právních povinností → požadavky MUSÍ obsahovat minimálně následující pole:
- MUSÍ – identifikátor povinnosti (vnitřní ID) a odkaz na zdroj (předpis, výklad, interní akt).
- MUSÍ – popis povinnosti a její právní účinek (co musí být splněno).
- MUSÍ – kde v procesu se uplatní (krok end-to-end).
- MUSÍ – implementační požadavek (co musí systém/proces/UX udělat).
- MUSÍ – důkaz a ověřovací scénář (jak prokážeme splnění – test / log / dokument).
- MUSÍ – odpovědnost za splnění (věcná, právní, technická, provozní).
- MUSÍ – stav (navrženo / schváleno / implementováno / ověřeno) a datum poslední změny.
|
TIP Legal traceability používejte i pro smluvní akceptaci: každý právní požadavek musí mít ověřovací scénář, který se provede před převzetím. |
¶ 4.5.4 Checklist „právní no-go“ (kdy je povinné STOP)
Následující situace znamenají STOP, dokud nejsou odstraněny nebo formálně rozhodnuty s mitigací:
- NESMÍ – chybět vyjasnění právního účinku digitálního úkonu (není jasné, co se právně děje).
- NESMÍ – být nevyřešeno doručování a okamžik účinku (není důkaz o doručení nebo není jasná fikce).
- NESMÍ – být nevyřešeno zastoupení/opravení jednající osoby, pokud je pro agendu běžné.
- NESMÍ – být plánováno hlavní zpracování osobních údajů na základě „souhlasu“, pokud pro veřejnou moc není vhodný a není právně zdůvodněn.
- NESMÍ – být nevyřešena evidence a vazba na spis (není jasné, kde bude dokument a kdo ho dohledá).
- NESMÍ – být identifikována nutná legislativní změna bez schváleného plánu a bez dopadu na harmonogram projektu.
¶ 4.5.5 Co MUSÍ být smluvně vynuceno kvůli právní obhajitelnosti
Checklist – povinné smluvní body (bez ohledu na typ dodavatele):
- MUSÍ – být povinnost dodavatele dodat a udržovat dokumentaci k právně relevantním funkcím (doručení, podpis, logování, export důkazů).
- MUSÍ – být povinnost dodavatele umožnit export právně relevantních důkazů (logy, auditní záznamy, dokumenty) v definovaném formátu.
- MUSÍ – být povinnost dodavatele dodržet akceptační kritéria včetně právních scénářů (zastoupení, výjimky, lhůty).
- MUSÍ – být povinnost řešit změny práva/výkladu jako řízené změny (dopad, plán, cena, termín, rozhodnutí).
- NESMÍ – být právně kritické části služby neověřitelné (bez testu, bez logu, bez důkazu).
|
ČASTÁ CHYBA Úřad koupí „funkcionalitu“ bez definice důkazů a auditní stopy. Pak má obrazovku, ale nemá obhajitelný úkon. |
¶ 4.6 Vazba na řízení ICT projektu
Právní rozhodnutí této kapitoly jsou závaznými vstupy do předprojektových fází a do schvalování projektového záměru dle Metodiky řízení ICT projektů. Kapitola nevytváří nové projektové role ani paralelní procesy; stanoví, jaké právní podklady MUSÍ existovat, aby rozhodovací orgány projektu (zejména Řídicí výbor projektu a případně Projektová komise dle interních pravidel) mohly rozhodnout o pokračování a zahájení realizace.
TABULKA 3 – Mapování Legal packu na fáze řízení ICT projektu (minimální vazba)
| Fáze dle Metodiky řízení ICT projektů | Co se má právně rozhodnout | Jaký důkaz musí být předložen | Kdo formálně rozhoduje (v rámci projektu) |
| Projektový záměr a příprava | Identifikace právního titulu, základních povinností a právních účinků; prvotní rizika proveditelnosti | Právní inventura služby + prvotní závěr proveditelnosti (pracovní) | Nositel projektu (příprava), Řídicí výbor projektu (směr) |
| Schvalování projektového záměru | Je cílový režim právně proveditelný? Je potřeba legislativa? Jaké jsou podmínky a rizika? | Závěr proveditelnosti + plán legislativních kroků (pokud relevantní) + rizika | Řídicí výbor projektu; případně Projektová komise dle interních pravidel |
| Příprava projektu | Překlad povinností do požadavků a do akceptačních kritérií; nastavení doručování, identit, evidence a spisu | Legal traceability matice + rozhodnutí o identitě/zastoupení + režim doručení + pravidla evidence | Řídicí výbor projektu (schválení klíčových nastavení) |
| Plánování a zahájení projektu | Smluvní vynucení právních požadavků a důkazů; nastavení změn při změně práva | Smluvní minimum + akceptační kritéria právních scénářů + pravidla změnového řízení | Řídicí výbor projektu |
| Realizace projektu | Řízení změn při právních změnách/výkladech; průběžná aktualizace traceability | Aktualizovaný Decision log + traceability matice + evidence změn | Řídicí výbor projektu při překročení tolerancí nebo při STOP/GO rozhodnutí |
| Ukončení projektu a udržitelný rozvoj | Předání právně relevantních důkazů a postupů do provozu; ověření schopnosti doložit úkon | Předávací protokol + exportní postupy důkazů + provozní postupy doručení/spisu | Řídicí výbor projektu (akceptace), vlastník výstupů projektu (přebírá provoz) |
|
POZOR Právní výstupy MUSÍ být součástí akceptace. Pokud projekt přebírá výstup bez doložení právního účinku a důkazní stopy, vzniká provozní a právní dluh, který se typicky projeví až při prvním sporu nebo kontrole. |
|||
¶ 5. Proces a data
¶ 5.1 Účel kapitoly
Účelem kapitoly je vynutit, aby digitální služba byla navržena jako řízený end-to-end proces opřený o konkrétní data a jejich vlastníky. Kapitola stanoví povinné rozhodnutí a minimální důkazy pro: mapování procesu včetně výjimek, vymezení odpovědností v procesu, identifikaci a kvalitu datových zdrojů (registry, evidenční systémy, dokumenty), interoperabilitu a integrace, a řízení datových změn (migrace, záznamy, auditní stopa). Kapitola je navržena pro reálnou praxi veřejné správy: více útvarů, více systémů, kombinace digitálních a nedigitálních kroků a tlak na dodržení lhůt a obhajitelnost rozhodnutí.
¶ 5.2 Jaké rozhodnutí kapitola vynucuje
Orgán veřejné moci MUSÍ před zahájením realizace (nejpozději před zadáním implementace) rozhodnout a doložit:
- MUSÍ – end-to-end proces služby včetně výjimek a návratových stavů (nejde jen o „happy path“).
- MUSÍ – kde vzniká rozhodnutí (úkon úřadu) a kde vzniká důkaz o úkonu (záznamy, dokumenty, logy, vazba na spis/evidenci).
- MUSÍ – jaká data jsou potřeba pro každý krok procesu, odkud pocházejí, kdo je vlastníkem a za jakých podmínek jsou dostupná.
- MUSÍ – která data jsou referenční (autorita), která jsou odvozená a která jsou pouze dočasná (pracovní).
- MUSÍ – integrace a interoperabilitu: jaké systémy/registry se dotýkají služby a jaké rozhraní se použije (na úrovni rozhodnutí, ne detailního technického návrhu).
- MUSÍ – pravidla kvality dat (minimální standard) a postup při nekvalitních/konfliktních datech (včetně dopadu na UX a provoz).
- MUSÍ – pokud se migrují data: zda je migrace nutná, jaký je rozsah, odpovědnosti, kritéria úspěchu a plán ověření.
- NESMÍ – zahájit realizaci, pokud nejsou potvrzeni vlastníci klíčových datových zdrojů a není rozhodnuto, jak se získají data pro kritické scénáře.
|
POZOR „Proces“ není BPMN diagram pro archiv. Proces MUSÍ být použitelný pro zadání, testování a provoz: musí obsahovat výjimky, lhůty, odpovědnosti a datové zdroje. „Data“ nejsou „tabulky v databázi“. Data jsou evidenční fakta a dokumenty, které musí být dohledatelné a obhajitelné. |
¶ 5.3 Povinné výstupy / důkazy
TABULKA 1 – Process & Data pack (povinné důkazy)
| Výstup / důkaz | Minimální obsah | Kdo odpovídá za existenci | Kdy MUSÍ existovat | Použití (k čemu slouží) | Kontrolní bod (brána) | Kde se vede |
| Mapa end-to-end procesu (L0) | Kroky od spouštěče po výsledek, hlavní větve, odpovědnosti (útvar/role), vstupy/výstupy, kanály | Věcný gestor služby; koordinace: PM | Před zadáním implementace | Základ pro rozsah, testy, provozní scénáře | Brána před realizací | Evidence pack – Procesy a data |
| Detailní proces pro kritické scénáře (L1) | Pro každý kritický scénář: kroky, výjimky, lhůty, rozhodovací body, požadované dokumenty/údaje | Věcný gestor + dotčené útvary; koordinace: PM | Před návrhem detailního řešení a testů | Podklad pro akceptační kritéria a testování | Brána před realizací a brána před převzetím | Evidence pack – Procesy a data |
| Datová inventura (Data inventory) | Seznam datových prvků a dokumentů, zdroj (registr/systém), vlastník, právní titul přístupu, kvalita, frekvence aktualizace | Datoví vlastníci + věcný gestor; koordinace: PM | Před zadáním integrací a před realizací | Zabraňuje překvapení v integracích a v kvalitě dat | Brána před realizací | Evidence pack – Procesy a data |
| Rozhodnutí o referenčních datech (Authority) | Co je autoritní zdroj pro klíčové údaje; pravidla při konfliktu; kdo rozhoduje o opravě | Nositel (vynucuje) + věcný gestor + datoví vlastníci | Před realizací a před nastavením validací | Zabraňuje sporům o „pravdu“ a chybným rozhodnutím | Brána před realizací | Evidence pack – Procesy a data + Decision log |
| Koncept integrací (Integration concept – L0) | Seznam integrací: kdo s kým, proč, jaký typ rozhraní (API/ISDS/ruční), režim (online/batch), kritičnost | Architektura + věcný gestor; koordinace: PM | Před zadáním implementace | Podklad pro zadání, plánování a rizika | Brána před realizací | Evidence pack – Procesy a data + Architektura |
| Pravidla kvality dat a validací (Data quality rules) | Minimální standardy (povinné/volitelné, formáty, rozsahy, konzistence), reakce na nekvalitu, odpovědnost | Věcný gestor + datoví vlastníci; UX (dopad na uživatele) | Před implementací formulářů/validací | Zabraňuje provozu na nekvalitních datech | Brána před převzetím | Evidence pack – Procesy a data + UX/obsah |
| Plán migrace a ověření (pokud relevantní) | Rozsah migrace, mapování, kritéria úspěchu, ověřovací postup, rollback, odpovědnosti | Architektura/technické role v projektu; schvaluje Řídicí výbor projektu dle pravidel | Před realizací migrace a před převzetím | Snižuje riziko ztráty dat a incidentu po go-live | Brána před převzetím a go-live | Evidence pack – Procesy a data + Řízení projektu |
| Důkaz provozní dohledatelnosti (audit trail) | Co se loguje, kde, jak se dohledá konkrétní případ; vazba na spis/evidenci; export | Provoz + bezpečnost + věcný gestor; koordinace: PM | Před go-live | Obhajitelnost, kontroly, incidenty, stížnosti | Brána před go-live | Evidence pack – Provoz + Bezpečnost + Procesy a data |
|
TIP Udržujte proces a data v přímé vazbě na kritické scénáře z kapitoly „Co je digitální služba“ a na akceptační kritéria. Proces bez testu a data bez vlastníka nejsou použitelné důkazy. |
||||||
¶ 5.4 Typická selhání z praxe
- Proces je popsán jen jako interní kroky úřadu, ale chybí uživatelská část a přechody mezi kanály.
- Nejsou popsány výjimky (doplnění, odmítnutí, oprava) a následně je služba v provozu neprůchozí pro reálné případy.
- Datové zdroje nejsou dohodnuté s vlastníky; integrace se objeví až v realizaci → dodatky, skluz, nebo ruční obcházení.
- Není rozhodnut autoritní zdroj dat; různé systémy mají různé hodnoty a služba rozhoduje nesprávně.
- Kvalita dat se ignoruje; formulář validuje „tvrdě“ a blokuje uživatele, nebo naopak propouští nekonzistentní údaje → chyby v řízení.
- Migrační riziko se podcení; po go-live se zjistí chybějící vazby, duplicity nebo ztracené dokumenty.
- Auditní stopa je nedostatečná: nelze prokázat, co bylo podáno, kdy a jak bylo rozhodnuto; v praxi se dohledává ručně.
|
ČASTÁ CHYBA „Data“ se delegují na dodavatele jako čistě technický problém. Úřad pak neumí obhájit, odkud data pocházejí, kdo je vlastní a proč se podle nich rozhodovalo. |
|
DŮSLEDEK Selhání procesu a dat se typicky projeví jako: neprovozovatelná služba pro výjimky, nárůst ruční práce, provozní incidenty, spory o správnost rozhodnutí a vysoké náklady na dodatečné úpravy integrací. |
¶ 5.5 Hlavní obsah kapitoly
¶ 5.5.1 Minimální standard mapování procesu (L0/L1)
Checklist – mapa procesu MUSÍ splnit:
- MUSÍ – být end-to-end (od spouštěče po výsledek) a zahrnout i nedigitální kroky, které ovlivňují lhůty a výsledek.
- MUSÍ – mít jasně vyznačené rozhodovací body (kde úřad rozhoduje / posuzuje) a kdo je odpovědný.
- MUSÍ – obsahovat minimálně: standardní průchod, doplnění/oprava, odmítnutí/nezahájení, a uzavření případu.
- MUSÍ – uvést vstupy/výstupy v každém kroku: data, dokumenty, notifikace, stav.
- MUSÍ – uvést časové požadavky: lhůty, čekání na uživatele, interní SLA/OLA (pokud existují).
- NESMÍ – ignorovat přechody mezi kanály (digitál → přepážka → zpět do digitálu).
|
POZOR Pokud proces neobsahuje výjimky, bude se v provozu řešit ručně mimo systém. To je provozní dluh, ne „řešení“. |
¶ 5.5.2 Datová inventura a vlastnictví dat (minimální rozhodnutí)
TABULKA 2 – Šablona datové inventury (minimální pole pro klíčové datové prvky)
| Datový prvek / dokument | Kde se používá (krok procesu) | Zdroj (registr/systém/uživatel) | Vlastník zdroje (OVM/útvar) | Autorita (ANO/NE) | Právní titul přístupu / sdílení | Kvalita a známá rizika | Fallback (když data nejsou) |
|
TIP U každého klíčového datového prvku uveďte fallback: co se stane, když údaj není dostupný, je konfliktní nebo zastaralý. Fallback MUSÍ mít dopad na proces i UX (co uvidí uživatel a co udělá úřad). |
|||||||
¶ 5.5.3 Rozhodnutí o „pravdě“ (autoritě) a řešení konfliktů dat
Checklist – pravidla autority dat MUSÍ být stanovena pro klíčové údaje:
- MUSÍ – být určeno, který zdroj je autoritní (registr/systém) a kdy se použije.
- MUSÍ – být určeno, co se stane při konfliktu (které údaje mají přednost, kdo rozhodne a jak se provede oprava).
- MUSÍ – být určeno, kdo může údaj opravit (v jakém systému) a jak se oprava promítne do služby.
- MUSÍ – být určeno, jak se konflikt projeví uživateli (transparentní informace + další krok).
- NESMÍ – se rozhodování o konfliktu přenést na uživatele bez právního a procesního zdůvodnění
|
ČASTÁ CHYBA Služba zobrazí konflikt dat a žádá uživatele „vyberte správnou hodnotu“. Bez procesního pravidla je to neobhajitelné a často vede k nesprávným údajům a sporům. |
¶ 5.5.4 Interoperabilita a integrace (koncept – minimum pro zadání)
TABULKA 3 – Koncept integrací (L0) – minimum pro rozhodnutí a zadání
| Integrace | Účel v procesu | Zdroj → cíl | Režim (online/batch/ručně) | Kritičnost (kritická/nekritická) | Vlastník rozhraní | Fallback / degradace |
hecklist – integrace MUSÍ mít před startem realizace rozhodnuté:
- MUSÍ – účel (k čemu slouží v konkrétním kroku procesu) a dopad při výpadku.
- MUSÍ – vlastníka rozhraní a potvrzenou součinnost (kontaktní bod, okna, SLA/OLA pokud relevantní).
- MUSÍ – degradační režim: co se stane, když integrace nefunguje (uživatel, úřad, lhůty).
- NESMÍ – být kritické scénáře závislé na integraci bez fallbacku a bez rozhodnutí o dopadu na lhůty a provoz.
|
POZOR Interoperabilita je řízené riziko. Kritická integrace bez potvrzeného vlastníka a bez fallbacku je důvodem pro STOP na bráně před realizací. |
¶ 5.5.5 Kvalita dat a validace (minimální standard pro provoz)
Checklist – pravidla kvality dat MUSÍ obsahovat minimálně:
- MUSÍ – pravidla úplnosti (co je povinné), formátu (např. datum, identifikátory) a konzistence (např. vazby mezi údaji).
- MUSÍ – pravidla pro historizaci a časovou platnost (kdy je údaj „aktuální“).
- MUSÍ – pravidla pro manuální doplnění/opravu (kdo, kde, kdy) a jak se změna eviduje.
- MUSÍ – pravidla pro práci s chybami: uživatelská chyba vs. chyba zdroje vs. technická chyba.
- MUSÍ – dopad na UX: jak uživatel dostane srozumitelnou informaci a jaký je další krok.
- NESMÍ – být validace nastaveny tak, že blokují službu kvůli známé nekvalitě zdroje bez alternativního postupu.
|
TIP Když zdroj dat občas vrací nekonzistenci, řešení není „validaci vypnout“. Řešení je: řízený fallback + evidence + proces opravy. |
¶ 5.5.6 Migrace dat a přechod (cutover) – povinné minimum, pokud se migruje
Checklist – pokud je součástí změny migrace, MUSÍ být splněno:
- MUSÍ – být rozhodnuto, co se migruje (rozsah), co se nemigruje a proč.
- MUSÍ – být definována mapování (zdroj → cíl) a pravidla pro duplicity a konflikty.
- MUSÍ – být definována kritéria úspěchu migrace (měřitelná) a ověřovací postup (sampling + plný kontrolní průchod pro kritické položky).
- MUSÍ – být definován rollback / návratový postup a kdo rozhoduje o spuštění/vrácení.
- MUSÍ – být rozhodnuta dočasná paralelní evidence (pokud je nutná) a jak dlouho potrvá.
|
ČASTÁ CHYBA Migrace se nechá „na konec“ a řeší se jako technický sprint. Následně se zjistí chybějící vazby na případy, dokumenty nebo historii. |
¶ 5.5.7 Dohledatelnost a důkazy (audit trail) – minimum pro obhajitelnost
Checklist – služba MUSÍ umožnit dohledat alespoň:
- MUSÍ – identifikaci případu (jednoznačný identifikátor) a jeho stav v čase.
- MUSÍ – kdo jednal (uživatel/úředník/systém), kdy a s jakým oprávněním (odkaz na mechanismus identity/role).
- MUSÍ – co bylo podáno nebo přijato (obsah, dokumenty) a jak bylo doručeno/potvrzeno.
- MUSÍ – jaké rozhodnutí bylo učiněno a na základě jakých dat (minimálně odkazy na zdroje/údaje).
- MUSÍ – kde je dokumentace případu vedena (vazba na evidenci/spis) a jak se exportuje pro kontrolu.
|
POZOR Audit trail je provozní požadavek. Pokud neexistuje dohledatelnost, nelze službu bezpečně provozovat ani obhájit. |
¶ 5.6 Vazba na řízení ICT projektu
Tato kapitola stanoví věcné rozhodnutí a důkazy pro proces a data, které MUSÍ být používány jako vstupy do řízení ICT projektu dle Metodiky řízení ICT projektů (životní cyklus, role, odpovědnosti, brány, eskalace). Kapitola nevytváří paralelní procesy; vyžaduje pouze, aby rozhodovací orgány projektu (zejména Řídicí výbor projektu) měly pro rozhodnutí STOP/GO prokazatelné podklady.
TABULKA 4 – Napojení Process & Data packu na fáze a brány projektu
| Fáze dle Metodiky řízení ICT projektů | Co MUSÍ být hotové (z této kapitoly) | Formální použití v řízení projektu | Typické rozhodnutí (STOP/GO) |
| Předprojektové fáze / příprava záměru | L0 proces + prvotní datové zdroje a rizika; identifikace integrací a vlastníků | Vstup do vymezení rozsahu a přínosů; registr rizik | Je služba proveditelná s dostupnými daty a vlastníky? |
| Schvalování projektového záměru | Rozhodnutí o hranici procesu, klíčových datech a autoritě; základní integrační koncept | Podklad pro schválení záměru a rozpočtu; rozhodnutí o pokračování | Je možné schválit realizaci bez neobhajitelných datových rizik? |
| Příprava projektu / zadání dodavateli | L1 proces pro kritické scénáře; datová inventura; pravidla kvality; L0 integrační koncept | Součást zadání a akceptačních kritérií; plán testování a převzetí | Je zadání kompletní a testovatelné? Jsou potvrzeni vlastníci integrací? |
| Realizace projektu | Průběžná aktualizace procesu a dat při změnách; řízení integrací a datových rizik | Řízení změn a rizik dle tolerancí; eskalace na Řídicí výbor | Je dopad změny na proces/data přijatelný, nebo je nutná změna rozsahu? |
| Převzetí a go-live | Důkaz kvality dat a validací; migrační ověření (pokud relevantní); audit trail a dohledatelnost | Podklad pro akceptaci a go-live checklist | Lze službu obhájit a provozovat? Je dohledatelnost prokazatelná? |
| Ukončení projektu a udržitelný rozvoj | Předání procesní a datové dokumentace + vlastnictví; pravidla úprav dat/validací po spuštění | Předávací protokol; nastavení provozních postupů | Je jasné, kdo řídí změny procesu a dat po spuštění? |
|
POZOR Jakákoliv významná změna procesu nebo datových zdrojů v realizaci je změna s dopadem na rozsah, rizika a akceptaci. Musí být řízena změnovým řízením projektu a zaznamenána v Decision logu. |
|||
¶ 6. UX, obsah a přístupnost
¶ 6.1 Účel kapitoly
Účelem kapitoly je vynutit, aby digitální služba byla navržena tak, že ji uživatel reálně dokončí (včetně výjimek), porozumí tomu, co se děje a co bude následovat, a aby byla prokazatelně přístupná. Kapitola stanoví minimální povinné rozhodnutí a důkazy pro UX návrh, obsah a přístupnost tak, aby mohly být použity jako závazné vstupy do zadání, akceptace a go-live, a aby úřad udržel kontrolu nad službou i po spuštění (změny textů, scénářů, formulářů). Kapitola je navržena pro praxi veřejné správy: kombinace kanálů, povinnost vysvětlovat právní účinky, časté výjimky, a nutnost obhájit rozhodnutí i v případě stížnosti nebo kontroly.
¶ 6.2 Jaké rozhodnutí kapitola vynucuje
Orgán veřejné moci MUSÍ před zadáním implementace a před převzetím rozhodnout a doložit:
- MUSÍ – které uživatelské scénáře jsou závazné pro převzetí (kritické scénáře) a které výjimky musí být obslouženy digitálně, včetně návratových stavů.
- MUSÍ – jaké jsou akceptační podmínky UX, obsahu a přístupnosti (Definition of Done pro službu, nikoliv jen pro UI prvky).
- MUSÍ – jaké texty mají právní význam (poučení, prohlášení, informace o zpracování údajů, rozhodné informace pro lhůty) a kdo je schvaluje.
- MUSÍ – jak je řešena komunikace se službou: potvrzení, stavové obrazovky, notifikace, chyby a kontakt/eskalace (uživatelsky i provozně).
- MUSÍ – na jakých datech se ve službě rozhoduje a jak se to projeví v UX (co uživateli předvyplňujeme, co ověřujeme, co požadujeme).
- MUSÍ – minimální standard přístupnosti: co se testuje, jakými metodami, na jakých scénářích, a jak se dokládá splnění.
- NESMÍ – předat dodavateli implementaci UI bez schválené informační architektury/flow pro kritické scénáře a bez schválených akceptačních kritérií.
|
POZOR UX/obsah/přístupnost nejsou estetika. Jsou to převzatelná a auditovatelná kritéria služby. Pokud úřad nemá akceptační kritéria a důkazy, nemá reálně možnost službu převzít nebo odmítnout a vzniká vendor lock-in. |
¶ 6.3 Povinné výstupy / důkazy
TABULKA 1 – UX/Obsah/Přístupnost pack (povinné důkazy pro FULL)
| Výstup / důkaz | Minimální obsah | Kdo odpovídá za existenci | Kdy MUSÍ existovat | Použití (k čemu slouží) | Kontrolní bod (brána) | Kde se vede (evidence pack) |
| Seznam kritických scénářů a výjimek | Pro každý scénář: spouštěč, kroky, výsledek, výjimky, potvrzení/stavy, data a dokumenty, akceptační podmínky | Věcný gestor služby; koordinace: Projektový manažer | Před zadáním implementace; průběžně aktualizovat při změnách | Závazná definice toho, co je „služba“ a co se testuje | Brána před realizací; brána před převzetím | UX/obsah/přístupnost + Řízení projektu |
| Mapa uživatelské cesty (service journey) | End-to-end cesta včetně kanálových přechodů, stavů, notifikací, podpory a „co se děje v úřadu“ | Věcný gestor + UX/obsah | Před uzavřením rozsahu a zadáním implementace | Zabraňuje „jen formuláři“; dává podklad pro provoz | Brána před realizací | UX/obsah/přístupnost |
| Informační architektura + flow (IA/flow) | Seznam obrazovek a kroků, navigace, návratové cesty, stavové obrazovky, chybové stavy | UX/obsah + věcný gestor; koordinace: PM | Před implementací UI | Základ pro zadání, testy a akceptaci | Brána před realizací | UX/obsah/přístupnost |
| Wireframy / prototyp pro kritické scénáře | Minimálně: rozložení, hierarchy, formuláře, potvrzení, chyby, stavy, notifikace; varianty pro výjimky | UX; schvaluje věcný gestor | Před implementací UI; před začátkem vývoje klíčových obrazovek | Redukce změn v realizaci; podklad pro testování | Brána před realizací | UX/obsah/přístupnost |
| Content pack (schválené texty) | Názvy kroků, instrukce, popisky, chybové hlášky, potvrzení, notifikace, poučení a právně významné informace; verze a schválení | Věcný gestor + obsah; právní schvaluje právně významné texty | Pracovní verze před testováním; schválená verze před go-live | Jeden zdroj pravdy pro texty; přejímka a provozní změny | Brána před převzetím; brána před go-live | UX/obsah/přístupnost + Právo |
| Katalog chyb a stavů (Error & State catalogue) | Seznam chybových stavů a stavových informací: spouštěč, text, další krok, logování, dopad na proces a lhůty | UX/obsah + věcný gestor; provoz pro eskalace | Před testováním a před převzetím | Zajišťuje, že výjimky nejsou řešeny ručně mimo systém | Brána před převzetím | UX/obsah/přístupnost + Provoz |
| Plán a protokoly uživatelského testování | Metoda, vzorek, scénáře, zjištění, nápravná opatření, rozhodnutí o zbytkových problémech | UX + věcný gestor; koordinace: PM | Minimálně jednou před převzetím; u zásadních změn opakovat | Důkaz použitelnosti pro kritické scénáře | Brána před převzetím | UX/obsah/přístupnost + Decision log |
| Přístupnostní plán a důkaz splnění | Požadavky, metody testů (klávesnice, asistivní technologie, automatizované), výstupy, nápravy, zbytková rizika | UX/obsah (požadavky) + dodavatel (implementace) + úřad (ověření) | Plán před realizací; důkaz před převzetím a go-live | Prokazuje splnění přístupnosti a eliminuje právní/komunikační riziko | Brána před převzetím; brána před go-live | UX/obsah/přístupnost |
| Návrh informací pro podporu a zpětnou vazbu | Kontakty, kanály, SLA očekávání, formulář pro hlášení problému, postup eskalace | Provoz + věcný gestor; koordinace: PM | Před go-live | Zajišťuje, že uživatel má jasnou cestu při problému | Brána před go-live | Provoz + UX/obsah/přístupnost |
|
TIP Vedení evidence: každý artefakt má vlastníka, verzi, datum schválení a vazbu na Decision log (co bylo rozhodnuto a proč). Bez řízení verzí vzniká v zadání a akceptaci konflikt „co platí“. |
||||||
¶ 6.4 Typická selhání z praxe
- Služba se zamění za webový formulář; chybí stavové obrazovky, potvrzení a informace o dalším postupu.
- Projekt řeší pouze „happy path“; výjimky se v provozu řeší ručně (telefon, e-mail, přepážka) bez evidence.
- Chybové hlášky jsou technické nebo neurčité („neplatné“, „chyba systému“) a uživatel neví, co opravit.
- Texty s právním významem nejsou schválené, jsou nekonzistentní a mění se ad hoc; vzniká právní riziko a stížnosti.
- Přístupnost je vyhodnocena pouze automatickým nástrojem; neproběhne klávesnicový průchod ani scénářový test.
- Dodavatel implementuje UI bez závazných akceptačních kritérií; úřad pak nemá oporu pro převzetí/odmítnutí.
- Obsah je „v kódu“ bez governance; po spuštění nelze texty upravovat řízeně a rychle.
- Notifikace (e-mail/SMS/datová schránka) jsou přidány na konci bez vazby na proces a lhůty; vznikají rozpory v informování.
|
ČASTÁ CHYBA Přístupnost se zamění za kontrast a velikost písma. Nejčastěji selhávají formuláře (popisky, chyby), fokus/klávesnice a stavové zprávy při odeslání. |
|
DŮSLEDEK Selhání UX/obsahu/přístupnosti vede typicky k: nedokončení podání, nárůstu návštěv přepážek, vysokým nákladům na podporu, incidentům v lhůtách a reputačnímu i právnímu riziku z nevyhovění přístupnosti. |
¶ 6.5 Hlavní obsah kapitoly
¶ 6.5.1 Mapa uživatelské cesty (service journey) – povinný standard
Checklist – mapa uživatelské cesty MUSÍ obsahovat:
- MUSÍ – spouštěč služby (proč uživatel přichází) a očekávaný výsledek v uživatelských slovech.
- MUSÍ – kroky uživatele, kroky úřadu (backstage) a mezistavy (čekání, doplnění, odmítnutí).
- MUSÍ – kanálové přechody (web/mobil/přepážka/telefon/datová schránka) a co se v přechodu ztrácí/nesmí ztratit.
- MUSÍ – informování uživatele: potvrzení, stav, notifikace a kde je „jeden zdroj pravdy“ o stavu.
- MUSÍ – místa, kde vznikají důkazy (podání, doručení, rozhodnutí) a jak je uživatel informován.
- MUSÍ – kontaktní bod a postup při problému (podpora) pro kritické kroky.
TABULKA 2 – Šablona service journey (minimální pole)
| Fáze cesty | Cíl uživatele | Krok uživatele | Co dělá úřad (backstage) | Data/dokumenty | Stav a notifikace | Rizika / výjimky |
|
POZOR Pokud v journey chybí backstage kroky úřadu, vzniká „digitální front-end“ bez návaznosti na skutečné vyřízení a lhůty. |
||||||
¶ 6.5.2 Kritické scénáře a akceptační podmínky (Definition of Done)
Checklist – akceptační podmínky MUSÍ být definovány pro každý kritický scénář:
- MUSÍ – dokončení scénáře bez asistence úřadu (uživatel ví, co dělat a co bude následovat).
- MUSÍ – funkční a srozumitelné chybové stavy (co je špatně, kde a jak opravit) a zachování vyplněných dat.
- MUSÍ – stavové obrazovky: potvrzení o přijetí, identifikátor případu (pokud existuje), další kroky a očekávané lhůty (pokud relevantní).
- MUSÍ – přístupnost scénáře: klávesnice, fokus, popisky, stavové zprávy, kontrast (ověřeno).
- MUSÍ – důkazní stopa: co se loguje a kde je dohledatelné (vazba na evidenci/spis)
TABULKA 3 – Akceptační kritéria pro scénář (šablona)
| Scénář | Podmínka UX | Podmínka obsahu | Podmínka přístupnosti | Důkaz (test/artefakt) | Rozhodl (schválil) |
|
TIP Akceptační kritéria patří do zadání a smluvních akceptačních mechanismů. Bez nich bude převzetí sporem o interpretaci, nikoliv ověřením. |
|||||
¶ 6.5.3 Informační architektura a navigace (IA/flow) – minimální požadavky
Checklist – IA/flow MUSÍ:
- MUSÍ – obsahovat seznam obrazovek/kroků včetně stavových obrazovek (přijato, doplnit, odmítnuto, zpracovává se, dokončeno).
- MUSÍ – definovat návratové cesty a možnosti opravy před odesláním (rekapitulace).
- MUSÍ – zahrnout přerušení a návrat (uživatel se může vrátit později), včetně toho, co se uloží a na jak dlouho.
- MUSÍ – oddělit instrukce pro uživatele od interních kroků úřadu (uživatel nesmí řešit interní strukturu).
- NESMÍ – obsahovat slepé uličky bez dalšího kroku (uživatel vždy ví, co dál).
|
ČASTÁ CHYBA Flow končí odesláním. Chybí potvrzení, stav a cesta pro doplnění. Uživatel pak volá/chodí na úřad, protože neví, co se stalo. |
¶ 6.5.4 Obsah a microcopy – standard pro veřejnou službu (FULL)
Checklist – obsah MUSÍ být:
- MUSÍ – srozumitelný pro běžného uživatele (úřední pojmy vysvětlit; nepoužívat interní zkratky a systémové názvy).
- MUSÍ – jednoznačný v instrukci (co udělat), v důvodu (proč to potřebujeme) a v důsledku (co se stane).
- MUSÍ – konzistentní napříč kanály (web, e-mail, notifikace, PDF výstupy, datová schránka, přepážka).
- MUSÍ – oddělit právně závazné poučení od uživatelské instrukce (poučení může být delší, instrukce musí být krátká a akční).
- MUSÍ – mít definované schvalování textů s právním významem (kdo, kdy, jak evidováno).
- NESMÍ – přenášet odpovědnost za interní proces na uživatele (např. „kontaktujte útvar X“ bez jasného postupu).
TABULKA 4 – Povinné typy textů ve službě a jejich schvalování
| Typ textu | Kde se vyskytuje | Co MUSÍ obsahovat | Kdo schvaluje | Důkaz |
| Instrukce u kroku/obrazovky | Každý krok kritického scénáře | Co udělat + co budete potřebovat + jak dlouho to trvá (pokud relevantní) | Věcný gestor + obsah/UX | Content pack (verze) |
| Popisky a nápovědy polí | Formuláře | Formát, příklad, povinné/nepovinné, proč (u citlivých údajů) | Věcný gestor + obsah/UX | Content pack + test protokol chyb |
| Chybové hlášky | Validace a systémové chyby | Co je špatně + kde + jak opravit; alternativní postup při technické chybě | Věcný gestor + obsah/UX; provoz pro eskalaci | Katalog chyb a stavů |
| Potvrzení a stavové informace | Po odeslání, detail případu | Co bylo přijato + identifikátor + co bude dál + kdy očekávat výsledek + kde sledovat stav | Věcný gestor + obsah/UX; právní pokud má právní účinek | Test protokol scénářů |
| Poučení/právně významné informace | Kde vzniká právní účinek, lhůty, opravné prostředky | Právně správný text + srozumitelné shrnutí; odkazy na další postup | Právní útvar + věcný gestor | Schválení v evidence packu |
| Notifikace | E-mail/SMS/ISDS/portál | Důvod notifikace, stav, další krok; bezpečnostní zásady (bez citlivých údajů) | Věcný gestor + provoz; bezpečnost (obsah notifikací) | Schválená šablona notifikací |
|
POZOR Obsah musí být říditelný po spuštění. Pokud jsou texty hardcoded bez procesu, úřad ztrácí schopnost rychle reagovat na změny práva, výkladů a provozních zjištění. |
||||
¶ 6.5.5 Chyby, stavy, potvrzení a notifikace – povinné minimum pro provoz
Checklist – katalog chyb a stavů MUSÍ zahrnout minimálně:
- MUSÍ – uživatelské chyby (nevyplněno, špatný formát, neplatná kombinace) – vždy s opravnou instrukcí.
- MUSÍ – výjimky procesu (nutnost doplnění, překročená lhůta, nepříslušnost, odmítnutí) – včetně dalšího kroku.
- MUSÍ – technické chyby (výpadek integrace, nedostupnost služby) – včetně degradačního režimu a kontaktu.
- MUSÍ – stavové zprávy (přijato, zpracovává se, čeká na doplnění, rozhodnuto) a pravidla jejich změny.
- NESMÍ – být notifikace bez vazby na skutečný stav případu (uživatel nesmí dostat zavádějící informaci).
TABULKA 5 – Katalog chyb a stavů (šablona)
| Kód/ID | Typ (uživatel/proces/technika) | Spouštěč | Text pro uživatele (schválený) | Další krok uživatele | Co udělá úřad/provoz | Logování / důkaz |
|
TIP U technických chyb rozlišujte: (1) problém uživatele (např. špatný soubor), (2) problém zdroje dat/integrace, (3) interní systémovou chybu. Každý typ vyžaduje jiný text i jiný provozní postup |
||||||
¶ 6.5.6 Přístupnost – povinný standard a důkazy
Checklist – přístupnost MUSÍ být řešena jako součást návrhu, implementace i akceptace:
- MUSÍ – být definován rozsah přístupnosti: které kanály a části služby se posuzují (web, mobil, dokumenty, vložené prvky).
- MUSÍ – být provedeno testování na kritických scénářích: klávesnice, fokus, formuláře, stavové zprávy, kontrast a struktura.
- MUSÍ – být proveden alespoň jeden scénářový spot-check s asistivní technologií (např. čtečka obrazovky) na klíčových obrazovkách.
- MUSÍ – být opraveny zjištěné chyby, nebo musí existovat rozhodnutí o zbytkových odchylkách (s dopadem a plánem nápravy) v Decision logu.
- MUSÍ – být zajištěna přístupnost dokumentů poskytovaných službou (pokud služba generuje nebo vyžaduje dokumenty).
- NESMÍ – být přístupnost posouzena pouze automatizovaným nástrojem bez scénářového a klávesnicového testu.
TABULKA 6 – Matice testů přístupnosti (minimum)
| Test | Co se ověřuje | Na čem (scénáře/stránky) | Kdo provádí | Důkaz (co se ukládá) | Akceptační pravidlo |
| Klávesnicový průchod | Ovládání bez myši, fokus, pořadí, pasti | Všechny kritické scénáře | Úřad + dodavatel | Protokol + seznam vad + nápravy | Bez vad blokujících průchod scénářem |
| Formuláře a chyby | Popisky, asociace chyb k polím, srozumitelnost, rekapitulace | Formuláře v kritických scénářích | Úřad + dodavatel | Protokol + screenshoty/odkazy + opravy | Chyby musí být opravitelně sdělené |
| Kontrast a čitelnost | Čitelnost textu, informace ne pouze barvou | Klíčové obrazovky a komponenty | Dodavatel; kontrola: úřad | Výstup kontroly + nápravy | Bez vad znemožňujících čitelnost |
| Struktura a názvy prvků | Nadpisy, landmarky, názvy tlačítek a odkazů | Klíčové obrazovky | Dodavatel; kontrola: úřad | Výstup + nápravy | Ovládací prvky jsou jednoznačně identifikované |
| Stavové zprávy | Potvrzení odeslání, změny stavu, live regiony | Odeslání a stavové obrazovky | Úřad + dodavatel | Protokol + nápravy | Uživatel je informován i bez vizuálních signálů |
| Spot-check s asistivní technologií | Průchod scénářem se čtečkou obrazovky (min. 1–2 scénáře) | Nejdůležitější scénáře | Úřad (ověření) | Krátký protokol + zjištění + nápravy | Bez vad blokujících dokončení scénáře |
|
POZOR Přístupnost se prokazuje důkazem: protokoly testů, seznam vad, rozhodnutí o zbytkových odchylkách a jejich plán. Bez toho nelze přístupnost obhájit ani řídit. |
|||||
¶ 6.5.7 Testování použitelnosti a řízení změn UX/obsahu
Checklist – testování a změny MUSÍ být řízeny:
- MUSÍ – proběhnout uživatelské testování kritických scénářů (minimálně 1 kolo před převzetím; u zásadních změn opakovat).
- MUSÍ – být evidovány nálezy a rozhodnutí (opravit / odložit / akceptovat riziko) v Decision logu a v backlogu projektu.
- MUSÍ – být změny textů, formulářů a flow řízeny změnovým řízením projektu, pokud mění akceptační kritéria, právní význam nebo provozní chování.
- MUSÍ – být definováno, kdo je oprávněn schválit změnu (věcný gestor, právní, bezpečnost, provoz) a kdy jde změna na Řídicí výbor projektu (dle tolerancí).
|
TIP Změna microcopy může být „malá“, ale dopad může být zásadní (právní poučení, lhůty, očekávání uživatele). Změny textů s právním významem se NESMÍ dělat bez schválení. |
¶ 6.6 Vazba na řízení ICT projektu
Tato kapitola stanoví věcné požadavky a důkazy, které MUSÍ být použity v řízení ICT projektu dle Metodiky řízení ICT projektů (životní cyklus, role, odpovědnosti, brány, akceptace). Kapitola nepředefinuje projektové role ani nevytváří paralelní procesy. Artefakty UX/obsahu/přístupnosti jsou vstupy do dokumentů a rozhodnutí projektu (zejména do zadání, akceptačních kritérií, testů, předávacích protokolů a do Decision logu).
TABULKA 7 – Napojení UX/Obsah/Přístupnost packu na fáze a brány projektu (kompatibilita s Metodikou řízení ICT projektů)
| Fáze dle Metodiky řízení ICT projektů | Co MUSÍ být hotové (z této kapitoly) | Formální použití v řízení projektu | Typické rozhodnutí (STOP/GO) |
| Příprava projektového záměru | Předběžné scénáře a základní journey (L0) + identifikace právně významných textů | Vstup do vymezení služby, rozsahu a rizik | Je služba navržitelná tak, aby ji uživatel dokončil a aby byla přístupná? |
| Schvalování projektového záměru | Rozhodnutí o kritických scénářích, minimální akceptaci a přístupnostním rozsahu | Podklad pro schválení záměru a tolerancí; zaznamenat do Decision logu | Je akceptace definovaná tak, že lze službu převzít a obhájit? |
| Příprava projektu | IA/flow + prototyp pro kritické scénáře; návrh content packu; plán testů přístupnosti a použitelnosti | Vstup do zadání/smluv a plánu testování; vazba na akceptační kritéria projektu | Je zadání kompletní a testovatelné? |
| Plánování a zahájení projektu | Akceptační kritéria (DoD) + katalog chyb a stavů + pravidla schvalování textů | Součást Plánu řízení projektu (akceptace, změny) a smluvních mechanismů | Lze zahájit realizaci bez rizika „UI bez služby“? |
| Vývoj řešení / Zavedení řešení | Průběžné ověřování scénářů a přístupnosti; evidence nálezů a náprav; řízené změny | Řízení změn dle tolerancí; průběžná akceptace iterací | Je dopad změn na scénáře/obsah/přístupnost přijatelný? |
| Příprava produktivního provozu | Schválený content pack pro go-live; dokončené protokoly testů; nastavené podpůrné informace a kontakty | Podklad pro předávací protokol a go-live checklist | Jsou splněny důkazy přístupnosti a použitelnosti? |
| Zvýšená podpora provozu | Mechanismus sběru zpětné vazby, sledování dokončenosti scénářů, opravy textů a chyb podle procesu | Řízení incidentů a změn; vyhodnocení metrik | Je nutné upravit scénáře/flow/texty? Eskalace dle dopadu. |
| Vyhodnocení a uzavření projektu / Následná podpora a udržitelný rozvoj | Předání governance obsahu a UX; pravidla změn; archivace důkazů testů | Předání do provozu a udržitelného rozvoje; zajištění kontinuity | Je zajištěno, že úřad udrží kontrolu nad službou po spuštění? |
|
POZOR Změna kritického scénáře, IA/flow nebo textů s právním významem je změna s dopadem na akceptaci a často i na právo a provoz. Musí být řízena změnovým řízením projektu a zaznamenána v Decision logu; při překročení tolerancí se eskaluje na Řídicí výbor projektu. |
|||
¶ 7. Architektura, bezpečnost, provoz
¶ 7.1 Účel kapitoly
Účelem kapitoly je vynutit, aby digitální služba byla navržena tak, že je provozovatelná, bezpečná a udržitelná v prostředí veřejné správy. Kapitola stanoví povinná rozhodnutí a důkazy pro architektonické vymezení, kybernetickou bezpečnost, ochranu dat, provozní model, monitoring, řízení incidentů a kontinuitu. Kapitola je orientována na reálnou praxi: více systémů, integrace na registry, závislosti na externích rozhraních, omezené kapacity provozu, auditovatelnost a požadavky na dostupnost a obnovu.
¶ 7.2 Jaké rozhodnutí kapitola vynucuje
Orgán veřejné moci MUSÍ před zahájením realizace a před go-live rozhodnout a doložit zejména:
- MUSÍ – základní architektonické vymezení služby (kontext, hranice, hlavní komponenty, integrace, datové toky).
- MUSÍ – bezpečnostní klasifikaci služby a dat (dopad na opatření, audit, logging, přístupová práva).
- MUSÍ – model identity a řízení přístupů (uživatelé, role, zastoupení; administrace; revize oprávnění).
- MUSÍ – minimální bezpečnostní opatření (řízení zranitelností, šifrování, segmentace, zálohování, hardening, logování).
- MUSÍ – provozní model: kdo službu provozuje, jaké jsou SLA/OLA, jak se řeší incidenty, změny a dostupnost.
- MUSÍ – monitoring a observabilitu (co měříme, jak detekujeme incident, kdo reaguje) a postup při výpadku integrací (degradace).
- MUSÍ – předávací a přejímací podmínky do provozu (důkazy bezpečnosti a provozuschopnosti).
- NESMÍ – jít do go-live bez schváleného provozního modelu, bez ověřeného zálohování/obnovy a bez schopnosti dohledat incidenty a právně relevantní události.
|
POZOR Architektura není výkres pro dodavatele. Architektura je rozhodnutí o hranicích a odpovědnostech: co je součástí služby, na čem služba závisí a kdo nese rizika. Bez provozního modelu a bezpečnostních důkazů je go-live neobhajitelný a vzniká provozní i právní dluh. |
¶ 7.3 Povinné výstupy / důkazy
TABULKA – Architecture/Security/Operations pack (povinné důkazy)
| Výstup / důkaz | Minimální obsah | Kdo odpovídá za existenci | Kdy MUSÍ existovat | Použití (k čemu slouží) | Kontrolní bod (brána) | Kde se vede (evidence pack) |
| Architektonický kontext a hranice služby (L0) | Kontext (systémy/registry/aktéři), hranice služby, hlavní komponenty, integrace, datové toky (L0) | Architektura; spolupráce: věcný gestor, bezpečnost, provoz; koordinace: PM | Před zadáním realizace (před zahájením implementace) | Podklad pro zadání, rizika, odpovědnosti, náklady na provoz | Brána před realizací | Architektura + Řízení projektu |
| Bezpečnostní klasifikace služby a dat | Klasifikace (citlivost, dopady), požadavky na opatření, logování, uchování, audit | Bezpečnost (CISO/odpovědný útvar) + věcný gestor; PM koordinuje | Před návrhem bezpečnostních opatření a před realizací | Základ pro rozsah opatření a ověření | Brána před realizací | Bezpečnost + Právo a compliance |
| Model identity a přístupů (IAM) | Role, oprávnění, administrace, zastoupení, revize oprávnění, logování přístupů | Bezpečnost + věcný gestor; architektura; provoz | Před implementací přihlášení/rolí | Zabraňuje zneužití a sporům o oprávnění | Brána před realizací | Bezpečnost + UX/obsah |
| Bezpečnostní požadavky a opatření (security baseline) | Šifrování, hardening, segmentace, správa tajemství, zranitelnosti, patching, logging, WAF/ochrany (dle prostředí) | Bezpečnost + architektura; dodavatel implementuje; úřad ověřuje | Před realizací; průběžně | Podklad pro implementaci a akceptaci bezpečnosti | Brána před převzetím; brána před go-live | Bezpečnost + Architektura |
| Plán testování bezpečnosti a výsledky (minimální) | Typy testů (zranitelnosti, konfigurace, penetrační test dle rizika), nálezy, nápravy, rozhodnutí o zbytkových rizicích | Bezpečnost; dodavatel poskytuje součinnost; PM koordinuje | Plán před testy; výsledky před převzetím/go-live | Důkaz bezpečnosti pro převzetí | Brána před převzetím; brána před go-live | Bezpečnost + Decision log |
| Provozní model služby (Operating model) | Provozní role a odpovědnosti, SLA/OLA, incident management, změny, release, údržba, okna, eskalace | Provozní útvar; věcný gestor; PM koordinuje | Před go-live (pracovní) a schválený před go-live | Zajišťuje provozuschopnost a kontinuitu | Brána před go-live | Provoz + Řízení služby |
| Monitoring a alerting (observabilita) | Co se měří (dostupnost, výkon, chybovost, integrace), prahy, alarmy, kdo reaguje, runbook | Provoz + bezpečnost; dodavatel implementuje dle zadání | Před go-live | Detekce incidentů a degradací | Brána před go-live | Provoz + Bezpečnost |
| Plán zálohování a obnovy (Backup & Restore) | Co se zálohuje, frekvence, RPO/RTO, test obnovy, odpovědnosti | Provoz + architektura; dodavatel dle prostředí | Před go-live; test obnovy před go-live | Kontinuita a prevence ztráty dat | Brána před go-live | Provoz + Bezpečnost |
| Degradační režimy (výpadek integrací) | Pro kritické integrace: co se stane při výpadku, jaký je fallback, informace uživateli, dopad na lhůty | Architektura + provoz + věcný gestor; UX/obsah pro komunikaci | Před go-live (a před testováním) | Zabraňuje chaosu při výpadcích a sporům | Brána před go-live | Provoz + Procesy a data + UX/obsah |
| Předávací protokol do provozu (handover) | Seznam předaných artefaktů, přístupy, dokumentace, runbooky, kontakty, školení, backlog známých problémů | PM + provoz; dodavatel poskytuje; věcný gestor potvrzuje | Před go-live | Formální převzetí a odpovědnost | Brána go-live | Řízení projektu + Provoz |
|
TIP Ověření obnovy (restore) MUSÍ být provedeno jako reálný test. „Máme zálohy“ bez testu obnovy není důkaz. |
||||||
¶ 7.4 Typická selhání z praxe
- Architektura se řeší až po výběru dodavatele; hranice služby a integrace nejsou jasné → dodatky, skluz, spory.
- Provozní útvar je přizván až na konci; služba se předává bez runbooků, bez monitoringu a bez přístupů.
- Bezpečnostní opatření jsou deklarativní; chybí evidence testů, náprav a rozhodnutí o zbytkových rizicích.
- Logování je nedostatečné nebo nepoužitelné (nelze dohledat incident ani právně relevantní událost).
- Integrace nemají degradační režim; při výpadku se provoz přesune do e-mailů/telefonů bez evidence.
- IAM a role se podcení: chybí revize oprávnění, zastoupení, administrace a audit přístupů.
- Zálohování se testuje až po incidentu; obnova trvá dny, data jsou ztracena nebo nekonzistentní.
|
ČASTÁ CHYBA Projekt považuje „splněno“ za nasazení. Bez monitoringu, runbooku, přístupů a testu obnovy není služba provozuschopná. |
|
DŮSLEDEK Selhání architektury, bezpečnosti a provozu vede typicky k: výpadkům, incidentům se ztrátou dat, nemožnosti obhájit rozhodnutí (chybí logy), vendor lock-in, a vysokým nákladům na dodatečné doplnění provozních schopností. |
¶ 7.5 Hlavní obsah kapitoly
¶ 7.5.1 Architektura služby (L0) – povinný obsah a rozhodnutí
Checklist – architektonické vymezení MUSÍ obsahovat:
- MUSÍ – kontext: aktéři (uživatel, úředník, systémy/registry), hranice služby a dotčené externí služby.
- MUSÍ – hlavní komponenty (front-end, back-end, integrační vrstva, evidence/spisové vazby) a jejich odpovědnosti.
- MUSÍ – datové toky: odkud kam se přenáší klíčová data, kde se ukládají a kde vzniká důkaz/auditní stopa.
- MUSÍ – integrace: seznam a kritičnost; odkazy na degradační režimy.
- MUSÍ – provozní vymezení: kdo co provozuje (úřad vs dodavatel), kde běží prostředí, kdo má přístup.
- NESMÍ – být architektura neurčitá v hranicích odpovědnosti (kdo nese riziko a kdo řeší incident).
TABULKA 2 – Architektonické rozhodnutí (decision list) – minimum
| Rozhodnutí | Varianty | Zvolená varianta + odůvodnění | Dopady (bezpečnost, provoz, náklady) | Schválil / datum |
| Hranice služby (co je součástí) | A) pouze portál/formulář, B) portál + procesní back-end, C) end-to-end včetně spisové vazby | |||
| Režim integrací | A) online, B) batch, C) kombinace, D) ruční fallback | |||
| Umístění a provoz prostředí | A) interní infrastruktura, B) cloud dle pravidel, C) externí hosting s odpovědností dodavatele | |||
| Evidence a auditní stopa | A) jen v aplikaci, B) aplikace + centrální log, C) aplikace + spis/evidence + centrální log | |||
|
POZOR Architektonická rozhodnutí musí být zaznamenána v Decision logu a použita v zadání. Pokud nejsou závazná, dodavatel dodá vlastní řešení, které nemusí být provozovatelné v podmínkách úřadu. |
||||
¶ 7.5.2 Bezpečnostní baseline – povinné minimum (bez ohledu na dodavatele)
Checklist – bezpečnostní opatření MUSÍ zahrnout minimálně:
- MUSÍ – řízení identity a přístupů (IAM): autentizace, autorizace, správa rolí, revize oprávnění, audit přístupů.
- MUSÍ – logování a auditní stopu: bezpečnostní události, administrace, přístupy k citlivým datům, integrace, chyby.
- MUSÍ – šifrování dat v přenosu a dle klasifikace i v úložišti; správa klíčů/tajemství.
- MUSÍ – hardening a bezpečnou konfiguraci prostředí (minimální služby, aktualizace, segmentace, ochrany).
- MUSÍ – řízení zranitelností: pravidelné skeny, evidence nálezů, nápravy a rozhodnutí o zbytkovém riziku.
- MUSÍ – bezpečné zacházení s dokumenty a přílohami (typy, antivirová kontrola, limity, ukládání).
- MUSÍ – ochranu proti zneužití (rate limiting, ochrana formulářů, detekce anomálií) dle rizika.
- NESMÍ – být přístup do produkce sdílený, neauditovaný nebo bez revize oprávnění.
|
ČASTÁ CHYBA Logování se implementuje, ale nikdo ho nečte a neexistuje postup reakce. Log bez runbooku je jen úložiště dat. |
¶ 7.5.3 Identity a řízení přístupů (IAM) – minimum pro veřejnou službu
Checklist – IAM MUSÍ řešit:
- MUSÍ – uživatelskou identitu a oprávnění (včetně zastoupení, pokud je relevantní pro agendu).
- MUSÍ – administrátorské účty a jejich ochranu (oddělené účty, MFA, audit).
- MUSÍ – životní cyklus oprávnění: přidělení, změna, odebrání, periodická revize.
- MUSÍ – princip nejmenších oprávnění a oddělení rolí (minimálně pro kritické operace).
- MUSÍ – logování přístupů k citlivým údajům a administrátorských akcí.
TABULKA 3 – Matice rolí a oprávnění (minimum)
| Role | Co může dělat | Na jakých datech | Kritické akce (vyžadují audit) | Kdo přiděluje/odebírá | Revize (jak často) |
|
POZOR Role a oprávnění jsou provozní schopnost. Pokud chybí revize a audit, vzniká bezpečnostní incident „na časové ose“. |
|||||
¶ 7.5.4 Provozní model a runbooky – povinné minimum pro go-live
Checklist – provozní model MUSÍ obsahovat:
- MUSÍ – provozní role a odpovědnosti (kdo je L1/L2/L3), kontakty a eskalační cesta.
- MUSÍ – SLA/OLA pro dostupnost a reakci na incident (minimálně interní očekávání).
- MUSÍ – incident management: klasifikace incidentů, reakce, komunikace, evidence, post-mortem.
- MUSÍ – change management: jak se nasazují změny, kdo schvaluje, jak se testuje a rollbackuje.
- MUSÍ – release management: plán nasazení, okna, verze, evidence změn a známé problémy.
- MUSÍ – runbooky pro typické situace (výpadek integrace, nedostupnost, nárůst chybovosti, bezpečnostní incident).
TABULKA 4 – Runbook (šablona)
| Situace / trigger | Detekce (monitoring/alert) | Okamžitý postup (L1) | Eskalace (L2/L3) | Komunikace (uživatel/úřad) | Důkaz / evidence |
|
TIP Runbook musí být cvičen. Minimálně jednou před go-live proveďte „tabletop exercise“ pro výpadek kritické integrace a pro bezpečnostní incident. |
|||||
¶ 7.5.5 Monitoring, SLO a degradace – minimální standard
Checklist – monitoring MUSÍ pokrýt minimálně:
- MUSÍ – dostupnost služby (syntetické testy) a klíčové transakce (kritické scénáře).
- MUSÍ – výkon a kapacitu (odezva, fronty, využití) s prahy pro alerting.
- MUSÍ – chybovost (HTTP chyby, aplikační chyby, validační chyby) a trendy.
- MUSÍ – integrace: dostupnost, latence, chybovost, počet fallbacků.
- MUSÍ – bezpečnostní události: neúspěšná přihlášení, anomálie, administrátorské akce.
- MUSÍ – logování s možností dohledat konkrétní případ a incident (korelační ID).
TABULKA 5 – Monitoring a alerting (minimum)
| Oblast | Metrika | Prahová hodnota / SLO | Alert (kdo dostane) | Reakce (runbook) | Důkaz |
| Dostupnost | Úspěšnost syntetického průchodu kritickým scénářem | ||||
| Integrace | Chybovost kritické integrace / počet fallbacků | ||||
| Výkon | 95. percentil odezvy pro klíčové endpointy | ||||
| Bezpečnost | Neobvyklá aktivita administrátora / počet neúspěšných přihlášení | ||||
|
POZOR SLO bez reakce je jen číslo. Každý alert musí mít vlastníka a runbook. Pokud úřad nemá kapacitu na 24/7, MUSÍ být rozhodnuto, co to znamená pro SLO a komunikaci. |
|||||
¶ 7.5.6 Zálohování, obnova a kontinuita (RPO/RTO) – povinné minimum
Checklist – zálohování a obnova MUSÍ:
- MUSÍ – definovat RPO a RTO pro klíčová data a komponenty (v návaznosti na právní a procesní potřeby).
- MUSÍ – definovat, co se zálohuje (databáze, soubory, konfigurace, klíče dle pravidel) a kdo za to odpovídá.
- MUSÍ – obsahovat reálný test obnovy a záznam výsledku (restore test).
- MUSÍ – řešit integritu a konzistenci po obnově (kontrola vazeb a kritických scénářů).
- NESMÍ – spoléhat na „zálohy dodavatele“ bez doloženého testu obnovy a bez přístupu úřadu k důkazům.
|
ČASTÁ CHYBA RPO/RTO nejsou rozhodnuté. Po incidentu pak vznikne spor, co je „přijatelné“ a kdo nese dopady na lhůty a data. |
¶ 7.5.7 Degradační režimy při výpadku integrací – povinné rozhodnutí
Checklist – pro každou kritickou integraci MUSÍ být rozhodnuto:
- MUSÍ – kdy je integrace považována za „nedostupnou“ (prahy a detekce).
- MUSÍ – co je fallback: ruční ověření, odložené zpracování, dočasné přijetí podání bez ověření, nebo stop služby.
- MUSÍ – jak se uživatel informuje (text, stav, očekávání) a jak se vede evidence případu v degradaci.
- MUSÍ – dopad na lhůty a proces (kdo rozhoduje o přerušení/odkladu, kde se eviduje).
- MUSÍ – kdo má pravomoc přepnout režim (provoz) a kdo schvaluje pravidla (věcný gestor, bezpečnost, právní dle dopadu).
TABULKA 6 – Degradační režim integrace (šablona)
| Integrace | Kritické scénáře | Detekce výpadku | Fallback / degradace | Text pro uživatele | Dopad na proces/lhůty | Kdo rozhoduje o přepnutí |
|
DŮSLEDEK Bez definovaných degradačních režimů se výpadek integrace změní v improvizaci (telefon, e-mail, přepážka) bez evidence. To zvyšuje riziko chyb, sporů a ztráty důkazů. |
||||||
¶ 7.5.8 Bezpečnostní testy a akceptace – minimální standard důkazů
Checklist – před převzetím a go-live MUSÍ existovat:
- MUSÍ – výsledky skenu zranitelností (nebo ekvivalent) a evidence náprav pro kritické nálezy.
- MUSÍ – ověření konfigurace (hardening) a přístupů (IAM) v produkčně podobném prostředí.
- MUSÍ – penetrační test nebo cílený bezpečnostní test, pokud riziko služby vyžaduje (dle klasifikace).
- MUSÍ – rozhodnutí o zbytkových rizicích (co zůstává, proč, do kdy se opraví) v Decision logu.
- NESMÍ – existovat kritické nálezy bez opravy nebo bez formálního rozhodnutí o akceptaci rizika schváleného dle pravidel úřadu.
|
POZOR Akceptace bezpečnosti je rozhodnutí. Pokud nejsou nálezy a nápravy evidovány, nelze rozhodnutí obhájit. |
¶ 7.6 Vazba na řízení ICT projektu
Tato kapitola stanoví věcné požadavky a důkazy pro architekturu, bezpečnost a provoz, které MUSÍ být využity v řízení ICT projektu dle Metodiky řízení ICT projektů (životní cyklus, role, brány, akceptace, eskalace). Kapitola nevytváří nové projektové role ani paralelní procesy. Bezpečnostní a provozní rozhodnutí se promítají do zadání, akceptačních kritérií, registru rizik a do předávacích protokolů.
TABULKA 7 – Napojení Architecture/Security/Operations packu na fáze a brány projektu
| Fáze dle Metodiky řízení ICT projektů | Co MUSÍ být hotové (z této kapitoly) | Formální použití v řízení projektu | Typické rozhodnutí (STOP/GO) |
| Předprojektové fáze / příprava záměru | Architektonické vymezení (L0) + předběžná bezpečnostní klasifikace + identifikace provozních dopadů | Vstup do vymezení rozsahu, rozpočtu a rizik | Je služba realizovatelná s ohledem na bezpečnost a provozní kapacity? |
| Schvalování projektového záměru | Rozhodnutí o hranicích služby, integracích a provozním modelu; požadavky na bezpečnostní baseline | Podklad pro schválení záměru a tolerancí; zaznamenat do Decision logu | Jsou rizika bezpečnosti a provozu akceptovatelná a řízená? |
| Příprava projektu / zadání dodavateli | Security baseline + IAM model + monitoring požadavky + degradační režimy; požadavky na důkazy testů | Součást zadání/smlouvy a akceptačních kritérií | Je zadání testovatelné a lze službu převzít do provozu? |
| Realizace projektu | Průběžné bezpečnostní kontroly, evidence nálezů a náprav; příprava runbooků a monitoringu | Řízení změn a rizik; eskalace při překročení tolerancí | Nevzniká bezpečnostní/provozní dluh? Je nutné změnit rozsah? |
| Převzetí / go-live | Výsledky bezpečnostních testů, monitoring v provozním režimu, test obnovy, runbooky, přístupy, předávací protokol | Podklad pro akceptaci a go-live checklist | Lze službu bezpečně provozovat a reagovat na incidenty? |
| Zvýšená podpora provozu | Provozní metriky, incidenty, post-mortem, backlog náprav; řízené změny a releasy | Řízení incidentů, změn a udržitelného rozvoje | Je nutné upravit SLO, degradační režimy nebo provozní kapacity? |
| Udržitelný rozvoj služby | Zavedený proces řízení zranitelností, revize oprávnění, pravidelné testy obnovy a aktualizace runbooků | Kontinuální řízení bezpečnosti a provozu | Je služba dlouhodobě udržitelná a auditovatelná? |
|
POZOR Předávka do provozu MUSÍ obsahovat přístupy, runbooky, monitoring a důkazy bezpečnosti. Pokud se předá „jen kód“, nejde o převzetí provozovatelné služby, ale o předání neřízeného rizika. |
|||
¶ 8. Kontrolní brány a rozhodování
¶ 8.1 Účel kapitoly
Účelem kapitoly je nastavit závazný systém kontrolních bran (STOP/GO) a rozhodování tak, aby digitální služba nevstoupila do realizace ani do provozu bez splněných minimálních podmínek práva, procesu a dat, UX/přístupnosti, architektury/bezpečnosti a provozu. Kapitola definuje, jaké rozhodnutí se v jednotlivých branách přijímá, jaké důkazy musí existovat, jak se řídí výjimky a jak se eskalují sporná rozhodnutí v rámci řízení ICT projektu. Kapitola je kompatibilní s Metodikou řízení ICT projektů: brány jsou nadstavbou rozhodovacích „gate“ v projektu, nikoliv paralelním procesem.
¶ 8.2 Jaké rozhodnutí kapitola vynucuje
Orgán veřejné moci MUSÍ zavést a používat minimálně tyto rozhodovací brány Digital First (DF):
- MUSÍ – DF-1: Brána před zahájením realizace – rozhodnutí, že zadání je úplné a služba je realizovatelná bez neobhajitelných rizik.
- MUSÍ – DF-2: Brána před převzetím – rozhodnutí, že služba je převzatelná a splňuje minimální důkazy (testy, bezpečnost, přístupnost, dohledatelnost).
- MUSÍ – DF-3: Brána go-live – rozhodnutí, že službu lze spustit do produkce bez kritických otevřených vad a s provozním modelem.
- MUSÍ – DF-4: Brána po stabilizaci – rozhodnutí o ukončení zvýšené podpory a přechodu do standardního řízení služby.
- NESMÍ – proběhnout go-live bez formálního rozhodnutí DF-3 a bez kompletního Evidence packu pro brány DF-1 až DF-3.
- MĚLO BY – být stanoveno, kdy je rozhodnutí vráceno k přepracování (STOP), a kdy je povolena podmíněná akceptace (GO s podmínkami).
|
POZOR Brána není prezentace. Brána je formální rozhodnutí založené na důkazech. Pokud brána není schopna odůvodnit GO/STOP, nejde o bránu, ale o informativní schůzku. |
¶ 8.3 Povinné výstupy / důkazy
TABULKA 1 – Povinné důkazy pro řízení bran a rozhodování (Evidence & Decision pack)
| Výstup / důkaz | Minimální obsah | Kdo odpovídá za existenci | Kdy MUSÍ existovat | Použití (k čemu slouží) | Kontrolní bod (brána) | Kde se vede |
| Decision log (záznam rozhodnutí) | Datum, rozhodnutí, varianty, odůvodnění, vstupní artefakty, akceptovaná rizika, schválil | Projektový manažer; schvalují rozhodovací orgány dle Metodiky řízení ICT projektů | Od DF-1 průběžně; uzavřený před DF-3 | Auditovatelnost a řízení změn | DF-1 až DF-4 | Řízení projektu – Decision log |
| Gate checklisty (DF-1 až DF-4) | Seznam povinných bodů (MUSÍ/NESMÍ/MĚLO BY), stav splnění, odkaz na důkazy | PM + věcný gestor; validuje dotčený útvar (právní/bezpečnost/provoz/UX) | Před každou branou | Standardizace rozhodnutí, zabránění selektivnímu „vynechávání“ | DF-1 až DF-4 | Řízení projektu – Gate pack |
| Evidence pack index (rejstřík důkazů) | Seznam všech povinných artefaktů s verzí a umístěním; vazba na kapitoly 1–6 | PM | Před DF-1 (verze 1); aktualizace před DF-2 a DF-3 | Zajišťuje, že důkazy jsou dohledatelné | DF-1 až DF-3 | Evidence pack – rejstřík |
| Registr rizik a rozhodnutí o riziku | Rizika, hodnocení, opatření, vlastník, termíny; záznam akceptace rizika a kdo ji schválil | PM; vlastníci rizik dle projektu | Před DF-1; aktualizace před DF-2, DF-3 | Řízení tolerancí a eskalace | DF-1 až DF-3 | Řízení projektu – rizika |
| Seznam otevřených vad a dluhů (open issues / known limitations) | Seznam vad, závažnost, dopad, workaround, termín nápravy, rozhodnutí o akceptaci | PM + dodavatel; schvaluje dle pravidel projektu | Před DF-2 a DF-3; uzavřený před DF-4 | Podmíněná akceptace a kontrola dluhů | DF-2 až DF-4 | Řízení projektu – issues |
| Go-live readiness report | Souhrn splnění DF-3, otevřené vady, provozní připravenost, komunikační plán, rollback, kontakty | PM + provoz; přispívají bezpečnost, UX, architektura, právní | Před DF-3 | Jednotný podklad pro GO/STOP | DF-3 | Řízení projektu + Provoz |
|
TIP Evidence pack musí být založen tak, aby přežil personální změny. Dokumenty a protokoly se NESMÍ držet „u lidí“ v e-mailu; musí být v evidenci projektu se stabilním odkazem. |
||||||
¶ 8.4 Typická selhání z praxe
- Brány jsou formální, ale bez kritérií; rozhoduje se podle dojmu nebo tlaku na termín.
- Řídicí orgány projektu nevidí důkazy, pouze prezentaci; chybí odkazy na artefakty a protokoly.
- GO se dává s neznámými riziky: chybí registr rizik nebo rozhodnutí o akceptaci rizika.
- Podmínky GO nejsou měřitelné ani termínované; po go-live se „zapomenou“ a dluh roste.
- Kritické výjimky (integrace, lhůty, bezpečnostní nálezy) se řeší mimo projekt, bez Decision logu.
- Testy a protokoly existují, ale nejsou navázané na kritické scénáře; výsledek je neprokazatelný.
- Brána DF-2 se přeskočí a „přejímka“ je jen podpis; provoz přebírá nedokončené řešení bez runbooků a monitoringu.
|
ČASTÁ CHYBA „GO s podmínkami“ bez jasného vlastníka, termínu a měřitelného důkazu. Takové GO je ve skutečnosti STOP odložený do provozu. |
|
DŮSLEDEK Selhání bran vede typicky k: vendor lock-in, eskalaci incidentů v provozu, právně neobhajitelným stavům, ztrátě důkazů a neřízenému růstu provozního dluhu. |
¶ 8.5 Hlavní obsah kapitoly
¶ 8.5.1 Model bran Digital First (DF-1 až DF-4)
TABULKA 2 – Přehled bran a minimálních rozhodnutí
| Brána | Kdy (typicky) | Rozhodnutí (co vynucuje) | Minimální důkazy (souhrn) | Výsledek | Možné varianty | Stop triggery (typické) | Poznámka k řízení |
| DF-1: Před zahájením realizace | Před zadáním implementace / před zahájením vývoje | Zadání je úplné a testovatelné; klíčová rozhodnutí kapitol 1–6 jsou uzavřená | Service definice + právní konstrukce + proces/data + UX/obsah/přístupnost + architektura/bezpečnost/provoz (min. L0) | STOP/GO | GO / GO s podmínkami / STOP | Chybí vlastníci dat/integrací; neuzavřená právní konstrukce; nejsou akceptační kritéria; chybí arch. hranice | GO s podmínkami jen s termínem a vlastníkem |
| DF-2: Před převzetím | Před akceptací a předávkou do provozu | Služba je převzatelná: testy, přístupnost, bezpečnost, dohledatelnost, provozní připravenost | Protokoly testů (funkční, scénářové) + přístupnost + bezpečnostní testy + monitoring/runbooky + evidence | STOP/GO | GO / GO s omezením / STOP | Kritické vady; chybí důkaz přístupnosti; bezpečnostní kritické nálezy; není test obnovy | GO s omezením = omezení funkce s jasnou komunikací |
| DF-3: Go-live | Bezprostředně před spuštěním do produkce | Lze bezpečně spustit: provozní model je aktivní, rollback je připraven, komunikace je hotová | Go-live readiness report + go-live checklist + rollback plan + kontakty + stav integrací | GO/STOP | GO / STOP | Neexistuje rollback; monitoring není v provozu; nejasné odpovědnosti; neuzavřené kritické dluhy | Rozhodnutí musí být zaznamenáno v Decision logu |
| DF-4: Po stabilizaci | Po domluvené době zvýšené podpory | Zvýšená podpora končí; přechod do standardního řízení služby; dluhy jsou řízené | Stabilizační report + incidenty a nápravy + předání backlogu + aktualizace runbooků | GO/STOP | GO / STOP (pokračovat ve zvýšené podpoře) | Opakované incidenty; chybí nápravy; monitoring/alerting nefunkční; backlog bez vlastníka | Vazba na kapitolu 9 (řízení služby) |
|
POZOR „GO s omezením“ je přípustné pouze tehdy, pokud omezení: (1) je jasně definované, (2) je komunikované uživateli a interně, (3) má workaround a (4) má termín odstranění. Jinak je to skrytý STOP. |
|||||||
¶ 8.5.2 DF-1 – Brána před zahájením realizace (minimální checklist)
Checklist DF-1 (vyplňuje se s odkazy na důkazy):
- MUSÍ – být uzavřena definice digitální služby a hranice rozsahu (kritické scénáře + co není součástí).
- MUSÍ – existovat právní konstrukce služby a rozhodnutí o právně významných informacích (kap. 3).
- MUSÍ – existovat mapa procesu (L0) a pro kritické scénáře detail (L1) včetně výjimek (kap. 4).
- MUSÍ – existovat datová inventura pro klíčové údaje/dokumenty včetně vlastníků a autority (kap. 4).
- MUSÍ – existovat IA/flow a akceptační kritéria pro kritické scénáře (kap. 5).
- MUSÍ – existovat přístupnostní plán a rozsah ověřování (kap. 5).
- MUSÍ – existovat architektonické vymezení (L0) a seznam kritických integrací + degradační princip (kap. 6).
- MUSÍ – existovat bezpečnostní klasifikace a požadavky na security baseline (kap. 6).
- MUSÍ – být definována minimální provozní odpovědnost (kdo přebírá do provozu, jak) – alespoň pracovní verze (kap. 6).
- NESMÍ – chybět vlastníci klíčových datových zdrojů a rozhraní (jinak STOP).
- NESMÍ – být akceptace postavena na neurčitých tvrzeních („splněno“, „bude“) bez důkazů.
- MĚLO BY – být rozhodnuto, které požadavky jsou hard stop (STOP triggers) a jaké jsou tolerované odchylky (s eskalací).
|
ČASTÁ CHYBA DF-1 je použita jako „kick-off vývoje“. Správně je DF-1 poslední kontrola před tím, než se začne platit za implementaci. |
¶ 8.5.3 DF-2 – Brána před převzetím (minimální checklist)
Checklist DF-2:
- MUSÍ – být otestovány kritické scénáře včetně výjimek a existovat protokoly testů (funkční + scénářové).
- MUSÍ – existovat důkaz přístupnosti (minimálně klávesnice + scénáře + protokoly vad a náprav).
- MUSÍ – být uzavřeny bezpečnostní testy dle klasifikace a existovat evidence náprav a zbytkových rizik.
- MUSÍ – existovat dohledatelnost: audit trail pro případy, vazba na evidenci/spis, možnost dohledání incidentu.
- MUSÍ – fungovat monitoring v produkčně podobném režimu a existovat runbooky pro typické situace.
- MUSÍ – být proveden test obnovy (restore) a existovat protokol s výsledkem.
- MUSÍ – být připraven předávací protokol do provozu (přístupy, kontakty, dokumentace, školení).
- NESMÍ – existovat kritické vady blokující dokončení kritického scénáře nebo právně relevantní chyby.
- NESMÍ – být bezpečnostní kritické nálezy bez opravy nebo bez formální akceptace rizika dle pravidel úřadu.
- MĚLO BY – být provedeno alespoň jedno uživatelské ověření (smoke) na reálných uživatelských rolích a datech (v souladu s pravidly).
|
POZOR DF-2 není „akceptace dokumentace“. DF-2 je rozhodnutí, zda služba může být převzata do provozu se všemi provozními důsledky. |
¶ 8.5.4 DF-3 – Brána go-live (minimální checklist)
Checklist DF-3:
- MUSÍ – existovat Go-live readiness report (souhrn) a jeho schválení dle pravidel projektu.
- MUSÍ – být aktivní provozní model: kontakty, L1/L2/L3, eskalace, incident postup, okna.
- MUSÍ – být připraven a otestován rollback postup (co se vrací, kdo rozhoduje, jak se komunikuje).
- MUSÍ – být připraven komunikační plán (uživatelé, interně, podpora) a obsahové texty ve službě jsou schválené.
- MUSÍ – být ověřena připravenost integrací (dostupnost, prahy, degradační režimy) a monitoring/alerting je v provozu.
- MUSÍ – být zajištěna dostupnost evidence: identifikátory případů, logy, dohledatelnost, archivace důkazů.
- NESMÍ – proběhnout go-live bez rozhodnutí GO/STOP zapsaného v Decision logu a bez seznamu otevřených vad (včetně akceptace).
- MĚLO BY – být připraven plán zvýšené podpory (hypercare) včetně metrik a frekvence vyhodnocení.
|
DŮSLEDEK Pokud DF-3 proběhne bez rollbacku a bez aktivního monitoringu, první incident po spuštění se řeší improvizací. To obvykle vede k delšímu výpadku a ke ztrátě důvěry uživatelů. |
¶ 8.5.5 STOP triggery a pravidla pro „GO s podmínkami“
TABULKA 3 – Typické STOP triggery (nekompromisní)
| Oblast | STOP trigger (příklad) | Dopad | Kde se řeší (v řízení projektu) |
| Právo | Neuzavřená právní konstrukce; nejasné právní účinky; chybí schválení právně významných textů | Neobhajitelná služba, stížnosti, rušení rozhodnutí | Eskalace dle Metodiky řízení ICT projektů; rozhodnutí orgánu projektu |
| Proces a data | Chybí vlastník klíčového datového zdroje/integrace; neexistuje fallback pro kritické scénáře | Neprovozovatelnost, ruční obcházení, skluz | Změnové řízení projektu + risk/issue management |
| UX a přístupnost | Kritický scénář nelze dokončit; chybí důkaz přístupnosti pro kritické scénáře | Nedokončení podání, diskriminace, reputační riziko | Akceptační řízení projektu; nápravný plán |
| Bezpečnost | Kritické bezpečnostní nálezy bez opravy/akceptace rizika; neauditované přístupy do produkce | Incident, únik dat, sankce, ztráta důvěry | Bezpečnostní řízení + rozhodnutí dle pravidel úřadu |
| Provoz | Neexistuje test obnovy; chybí monitoring/alerting; nejsou runbooky a kontakty | Neřízený provoz, dlouhé výpadky, chaos při incidentech | Provozní připravenost – STOP do go-live |
Checklist – pravidla pro „GO s podmínkami“:
- MUSÍ – být jasně definována podmínka (co přesně bude splněno) a její důkaz (co se doloží).
- MUSÍ – být určen vlastník podmínky a termín splnění (nejpozději k další bráně / před určeným milníkem).
- MUSÍ – být popsán dopad, pokud podmínka nebude splněna (automatický STOP, omezení služby, eskalace).
- MUSÍ – být rozhodnutí zapsáno v Decision logu a být dohledatelné, kdo podmínku schválil.
- NESMÍ – jít o podmínku v oblasti STOP triggerů (právo, kritické scénáře, přístupnost, kritické bezpečnostní nálezy, test obnovy).
|
TIP U podmíněné akceptace vždy uveďte, zda jde o: (1) odloženou nápravu, (2) omezení funkce, nebo (3) dočasný workaround. Každý typ má jiný dopad na provoz a komunikaci. |
¶ 8.5.6 Příprava gate balíčku (jak vypadá „důkaz“)
TABULKA 4 – Struktura gate balíčku (minimální)
| Část balíčku | Co obsahuje | Odkud se bere | Kdo připraví | Kdo potvrzuje (dle projektu) |
| Souhrn (1–2 strany) | Co se rozhoduje, hlavní rizika, doporučení GO/STOP, seznam otevřených bodů | Go-live readiness / gate report | PM | Rozhodovací orgán projektu |
| Checklist brány | Povinné body + stav + odkazy na důkazy | Gate checklisty + evidence pack | PM + věcný gestor | Dotčené útvary (právo, bezpečnost, provoz, UX) |
| Důkazy (odkazy) | Protokoly, schválení, testy, dokumentace, runbooky, konfigurace dle potřeby | Evidence pack | Vlastníci artefaktů | PM kontrola úplnosti |
| Rizika a otevřené vady | Seznam, závažnost, plán nápravy, rozhodnutí o akceptaci | Risk register + issue list | PM | Rozhodovací orgán projektu |
| Rozhodnutí a podmínky | Zápis GO/STOP, případné podmínky, termíny, vlastníci | Decision log | PM | Rozhodovací orgán projektu |
|
POZOR Prezentace může doplnit, ale NESMÍ nahradit důkazy. Jediné autoritní podklady pro rozhodnutí jsou artefakty a protokoly v Evidence packu. |
||||
¶ 8.6 Vazba na řízení ICT projektu
Kontrolní brány Digital First jsou používány jako závazné kontrolní body v rámci řízení ICT projektu dle Metodiky řízení ICT projektů. Kapitola nepředefinuje projektové role ani nevytváří paralelní procesy: opírá se o existující rozhodovací strukturu projektu (např. Řídicí výbor projektu a odpovědnosti v projektu) a pouze standardizuje, jaké důkazy musí být pro rozhodnutí dostupné. Rozhodnutí DF-1 až DF-4 musí být řízena přes standardní mechanismy projektu: řízení změn, řízení rizik, akceptace a eskalace dle tolerancí.
TABULKA 5 – Mapování DF bran na typické fáze a brány ICT projektu
| DF brána | Typická vazba na fázi/rozhodnutí v ICT projektu | Jaký výstup projektu se tím uzavírá | Kde se eviduje rozhodnutí |
| DF-1 | Schválení zadání a zahájení realizace (před vývojem/implementací) | Zadání je úplné a testovatelné; základní rozhodnutí kap. 1–6 uzavřena | Decision log + Gate pack |
| DF-2 | Akceptace a převzetí dodávky / připravenost na provoz | Testy, přístupnost, bezpečnost, provozní schopnosti a důkazy | Předávací protokol + Decision log |
| DF-3 | Go-live rozhodnutí v projektu | Go-live readiness a aktivní provozní model + rollback | Go-live zápis + Decision log |
| DF-4 | Ukončení zvýšené podpory / stabilizace a přechod do standardního řízení služby | Vyhodnocení incidentů a náprav; uzavření dluhů nebo jejich převedení do řízení služby | Stabilizační report + předání backlogu |
|
POZOR Pokud v projektu chybí autoritní rozhodovací orgán pro GO/STOP, je nutné ho použít dle Metodiky řízení ICT projektů. Digital First brány nesmí vytvářet nový paralelní orgán; musí využít existující governance projektu. |
|||
¶ 9. Go-live
¶ 9.1 Účel kapitoly
Účelem kapitoly je vynutit, aby spuštění digitální služby do produkce (go-live) proběhlo kontrolovaně, auditovatelně a s provozní odpovědností. Kapitola stanoví povinná rozhodnutí a důkazy pro go-live (cutover, rollback, komunikace, provozní připravenost, monitoring, bezpečnost, přístupnost, stabilizační režim). Kapitola vychází z praxe veřejné správy: závislosti na integracích, omezené provozní kapacity, nutnost dohledatelnosti, kanálové souběhy (digitál + přepážka) a vysoké reputační riziko prvních dní.
¶ 9.2 Jaké rozhodnutí kapitola vynucuje
Orgán veřejné moci MUSÍ před spuštěním rozhodnout a doložit zejména:
- MUSÍ – zda služba je připravena ke spuštění (DF-3: GO/STOP) na základě důkazů, nikoliv pouze prohlášení.
- MUSÍ – jaký je způsob spuštění (např. postupné spuštění, omezené spuštění, plné spuštění) a jak se komunikuje uživatelům.
- MUSÍ – cutover plán: co se kdy nasazuje/migruje/aktivuje, kdo to provádí, jak se ověřuje úspěch a kdo schvaluje další krok.
- MUSÍ – rollback plán: kdy a jak se vrací zpět, co to znamená pro data, jak se komunikuje a kdo rozhoduje.
- MUSÍ – provozní režim prvních týdnů (zvýšená podpora/hypercare): kdo je dostupný, jak se sbírá zpětná vazba a jak se nasazují opravy.
- MUSÍ – způsob prokazování a uchování důkazů o spuštění (logy, konfigurace, protokoly, schválení, verze).
- NESMÍ – spustit službu bez aktivního monitoringu/alertingu, bez funkčních kontaktních a eskalačních cest a bez ověřeného rollbacku.
|
POZOR Go-live není jen „nasazení verze“. Go-live je převzetí rizika do provozu. Pokud nejsou připraveny provozní schopnosti, dojde k eskalaci incidentů hned v prvních dnech. |
¶ 9.3 Povinné výstupy / důkazy
TABULKA 1 – Go-live pack (povinné důkazy pro DF-3)
| Výstup / důkaz | Minimální obsah | Kdy MUSÍ existovat | Použití (k čemu slouží) | Kontrolní bod (brána) | Kde se vede (evidence pack) | |
| Go-live readiness report | Souhrn připravenosti: splnění DF-2, otevřené vady, provozní model aktivní, integrace, rizika, doporučení GO/STOP | Projektový manažer + provoz; příspěvky: věcný gestor, bezpečnost, architektura, UX, právní | Před DF-3 | Jednotný podklad pro rozhodnutí | DF-3 | Řízení projektu + Provoz |
| Cutover plán (nasazení + aktivace) | Časová osa kroků, odpovědnosti, kontrolní body, kritéria úspěchu, plán komunikace a omezení, evidence provedení | PM + dodavatel + provoz; schvaluje provoz a věcný gestor | Před DF-3; finální verze před spuštěním | Řízené provedení a dohledatelnost | DF-3 | Provoz + Řízení projektu |
| Rollback plán | Spouštěče rollbacku, kroky návratu, dopad na data a uživatele, časová okna, rozhodovací pravomoc, komunikace | PM + provoz + dodavatel; bezpečnost dle dopadů | Před DF-3; ověřený postup (min. tabletop nebo test) před spuštěním | Zabránění dlouhým výpadkům a improvizaci | DF-3 | Provoz + Bezpečnost |
| Go-live checklist (protokol) | Seznam povinných bodů před/po spuštění, včetně evidence provedení, podpis/odsouhlasení | PM + provoz | Vyplněný v den go-live | Prokazuje, co se skutečně stalo | DF-3 | Evidence pack – Go-live |
| Plán zvýšené podpory (hypercare) | Doba trvání, dostupnost rolí, metriky, denní rytmus, incident postupy, rychlé opravy, komunikační kanály | Provoz + PM; věcný gestor | Před go-live | Stabilizace a řízení očekávání | DF-3; DF-4 | Provoz + Řízení služby |
| Komunikační plán go-live | Cílové skupiny, zprávy, kanály, termíny, odpovědnosti; texty ve službě a mimo službu | Věcný gestor + obsah/UX; PM koordinuje | Před go-live | Minimalizace dotazů a chyb uživatelů | DF-3 | UX/obsah + Provoz |
| Provozní nastavení monitoringu/alertingu | Aktivní monitoring, alarmy, kontakty, runbooky, korelační ID a dohledatelnost; ověření funkcí | Provoz + bezpečnost; dodavatel poskytuje součinnost | Před go-live a aktivní při go-live | Detekce problémů v reálném čase | DF-3 | Provoz + Bezpečnost |
| Záznam o „release“ a konfiguraci produkce | Verze, commit/release ID, konfigurace, parametry, aktivované feature toggles, seznam změn | Dodavatel + provoz; PM eviduje | Při go-live; aktualizace při hotfixech | Audit a dohledatelnost | DF-3 | Evidence pack – release |
| Předávka přístupů a provozních kontaktů | Seznam účtů, přístupů, klíčů dle pravidel, kontakty L1/L2/L3, escrow/uložení tajemství dle interních pravidel | Provoz + bezpečnost; dodavatel poskytuje | Před go-live | Zajištění reakce na incidenty | DF-3 | Provoz + Bezpečnost |
|
TIP V rámci go-live packu udržujte „jeden zdroj pravdy“: index artefaktů, verze, datum schválení a vazbu na Decision log. |
||||||
¶ 9.4 Typická selhání z praxe
- Go-live je tlačen termínem; DF-3 se „odhlasuje“ bez readiness reportu a bez důkazů.
- Neexistuje rollback plán nebo je jen deklarativní; při incidentu se improvizuje a výpadek se prodlužuje.
- Monitoring existuje, ale není aktivní alerting a není jasné, kdo reaguje a jak (chybí runbook).
- Cutover kroky nejsou evidované; po problému není jasné, co bylo provedeno a v jaké verzi.
- Integrace se ověřují až po spuštění; výpadek registru/integrace paralyzuje službu bez degradačního režimu.
- Komunikace je opomenuta: uživatel neví, co dělat, podpora je zahlcena, přepážky nemají instrukce.
- Hypercare není nastavený; incidenty a opravy se řeší ad hoc bez priorit a bez evidence.
- Hotfixe se nasazují bez řízení změn; vzniká neauditovatelný stav a bezpečnostní rizika.
|
ČASTÁ CHYBA „První den to nějak zvládneme.“ Ve veřejné správě je první den rozhodující pro důvěru. Pokud služba první týden selhává, uživatel se vrací k papíru a obtížně se vrací zpět. |
|
DŮSLEDEK Neřízený go-live vede typicky k: nárůstu návštěv přepážek, přetížení podpory, eskalaci incidentů, reputačnímu riziku a rychlému vzniku provozního dluhu. |
¶ 9.5 Hlavní obsah kapitoly
¶ 9.5.1 Strategie spuštění (rollout) – povinné volby
Checklist – orgán veřejné moci MUSÍ zvolit a zdůvodnit strategii spuštění:
- MUSÍ – zvolit režim: plné spuštění / postupné spuštění / omezené spuštění (např. vybraná skupina, omezený čas, omezené funkce).
- MUSÍ – uvést, jak se režim projeví v komunikaci (texty ve službě, na webu, na přepážce, podpora).
- MUSÍ – uvést, jak se řeší souběh kanálů (digitál + papír/přepážka) a jak se zabrání duplicitám a sporům.
- MUSÍ – uvést, jak se bude rozhodovat o rozšíření (přechod z omezeného na plné) – na základě jakých metrik a incidentů.
- NESMÍ – být omezené spuštění bez jasných pravidel, koho se týká a jak se to kontroluje.
TABULKA 2 – Volba režimu spuštění (šablona)
| Režim spuštění | Pro koho/na co se vztahuje | Omezení (funkce/čas/region) | Kritéria rozšíření/ukončení | Rizika a mitigace | Schválil / datum |
|
POZOR Postupné spuštění nesmí znamenat „test v produkci“ bez podpory. Musí mít stejné požadavky na evidence, monitoring a bezpečnost jako plné spuštění. |
|||||
¶ 9.5.2 Cutover plán – řízení nasazení a aktivace
Checklist – cutover plán MUSÍ obsahovat:
- MUSÍ – časový harmonogram kroků (minutový nebo hodinový) včetně odpovědností a kontrolních bodů.
- MUSÍ – kritéria úspěchu pro každý krok (co se ověřuje) a kdo potvrzuje pokračování.
- MUSÍ – plán změnového okna a omezení služby (pokud je plánovaná odstávka nebo omezení funkce).
- MUSÍ – ověření integrací před a po spuštění (kritické integrace) a připravenost degradačních režimů.
- MUSÍ – evidenci provedení (čas, kdo, výsledek) a uložení do Evidence packu.
- NESMÍ – obsahovat kroky, které nejsou prověřené (minimálně tabletop); neověřený krok je zdroj incidentu.
TABULKA 3 – Cutover plan (šablona)
| Krok | Čas (plán) | Kdo provádí | Popis akce | Kritéria úspěchu (ověření) | Kdo potvrzuje | Výsledek (skutečnost) | Poznámka / incident |
|
TIP U každého cutover kroku uveďte „nejhorší dopad“ a „čas do rollbacku“. To zjednoduší rozhodování, když se něco pokazí. |
|||||||
¶ 9.5.3 Rollback plán – povinný obsah a spouštěče
Checklist – rollback plán MUSÍ řešit:
- MUSÍ – spouštěče rollbacku (např. nedostupnost kritických scénářů, kritická chybovost, selhání integrace bez fallbacku, bezpečnostní incident).
- MUSÍ – kdo rozhoduje (rozhodovací pravomoc) a jak rychle (časové limity).
- MUSÍ – technický postup návratu a dopad na data (co se stane s rozpracovanými případy a vzniklými podáními).
- MUSÍ – komunikaci: co sdělit uživatelům, přepážkám a podpoře; jak se zachová evidence.
- MUSÍ – postup obnovení po rollbacku (kdy se zkusí znovu, co musí být opraveno).
- NESMÍ – být rollback „nemáme“ – pokud není rollback možný, MUSÍ být formálně rozhodnuto, jak se řeší incident a jak se minimalizuje dopad.
TABULKA 4 – Rollback plan (šablona)
| Spouštěč | Jak se detekuje (monitoring) | Rozhoduje (kdo) | Limit pro rozhodnutí | Postup rollbacku | Dopad na data a případy | Komunikace |
|
POZOR Rollback není ostuda. Neřízený výpadek bez návratu je ostuda. Před go-live MUSÍ být jasné, kdy je rollback menší škoda než pokračování. |
||||||
¶ 9.5.4 Go-live checklist – minimum před/po spuštění
Checklist – body před spuštěním (MUSÍ):
- MUSÍ – být schválen GO (DF-3) a zapsán v Decision logu (včetně seznamu otevřených vad).
- MUSÍ – být ověřena dostupnost kritických integrací a funkčnost degradačních režimů (alespoň smoke).
- MUSÍ – být aktivní monitoring a alerting; kontakty L1/L2/L3 jsou dostupné.
- MUSÍ – být připraven komunikační obsah: stavové hlášení ve službě, web, instrukce pro přepážky a podporu.
- MUSÍ – být připraven rollback postup a rozhodovací režim (kdo a jak rychle).
- MUSÍ – být uzamčená verze release (release ID) a evidována konfigurace (včetně feature toggles).
Checklist – body po spuštění (MUSÍ):
- MUSÍ – proběhnout ověření kritických scénářů v produkci (smoke test) a záznam výsledku.
- MUSÍ – proběhnout ověření logování a dohledatelnosti (korelační ID; dohledání testovacího případu).
- MUSÍ – proběhnout ověření notifikací a stavových obrazovek (pokud jsou součástí služby).
- MUSÍ – běžet monitoring a být vyhodnoceny první metriky (dostupnost, chybovost, výkon).
- MUSÍ – být založen režim hypercare (denní rytmus, evidence incidentů, triage).
TABULKA 5 – Go-live protokol (šablona)
| Bod | Stav (splněno/nesplněno) | Důkaz (odkaz) | Čas | Kdo potvrdil | Poznámka / odchylka |
|
ČASTÁ CHYBA Po spuštění se ověří jen „že jde homepage“. Správně se ověřují kritické scénáře a dohledatelnost. |
|||||
¶ 9.5.5 Zvýšená podpora (hypercare) – režim prvních týdnů
Checklist – hypercare MUSÍ stanovit:
- MUSÍ – délku trvání a podmínky ukončení (vazba na DF-4).
- MUSÍ – denní rytmus: triage incidentů, vyhodnocení metrik, rozhodnutí o hotfix/release.
- MUSÍ – metriky: dostupnost, chybovost, výkon, dokončenost kritických scénářů, objem kontaktů na podporu.
- MUSÍ – pravidla pro rychlé opravy: kdo schvaluje, jak se testuje, jak se eviduje a nasazuje.
- MUSÍ – komunikační režim: jak informovat uživatele při problémech, jak informovat přepážky a call centrum.
- NESMÍ – být hypercare bez evidence – každý incident a oprava musí mít záznam a post-mortem u významných incidentů.
TABULKA 6 – Denní triage (šablona)
| Datum | Top incidenty (ID) | Dopad (uživatel/proces/právo) | Rozhodnutí (opravit/omezit/rollback) | Vlastník | Termín |
¶ 9.5.6 Komunikace a připravenost kanálů (včetně přepážek)
Checklist – komunikační a kanálová připravenost MUSÍ zahrnout:
- MUSÍ – instrukce pro uživatele: co služba umožňuje, co potřebují připravit, jaké jsou kroky a jak sledovat stav.
- MUSÍ – instrukce pro přepážky a podporu: jak uživatele navést, jak ověřit stav případu, jak eskalovat incident.
- MUSÍ – texty pro výpadek a degradaci (stavová stránka / hlášení ve službě) – schválené a připravené k aktivaci.
- MUSÍ – kontaktní bod pro hlášení problému (uživatelský) a interní kanál pro eskalace.
- NESMÍ – být komunikační sdělení v rozporu s reálným stavem služby nebo s právně významnými informacemi.
TABULKA 7 – Komunikační plán (šablona)
| Cílová skupina | Zpráva (co sdělit) | Kanál | Kdy | Vlastník | Příloha / text | Poznámka |
|
TIP Přepážky a call centrum musí mít krátký „script“: 5 vět, co říct a kam uživatele poslat. Bez toho se digitální služba znehodnotí v prvních dnech. |
||||||
¶ 9.5.7 Evidence go-live a dohledatelnost (audit)
Checklist – pro dohledatelnost go-live MUSÍ být uloženo:
- MUSÍ – rozhodnutí DF-3 (GO/STOP) v Decision logu + seznam otevřených vad a akceptací.
- MUSÍ – go-live protokol (vyplněný) včetně času, kdo co potvrdil a odkazy na důkazy.
- MUSÍ – release ID/verze a konfigurace produkce (včetně aktivovaných feature toggles).
- MUSÍ – logy a monitoring pro první dny: schopnost dohledat incidenty a konkrétní případy.
- MUSÍ – záznam o aktivaci komunikačních textů (pokud byly použity degradační hlášky).
- NESMÍ – být důkazní stopa pouze v e-mailu; musí být v Evidence packu.
|
POZOR Ve veřejné správě musí být dohledatelné: co bylo spuštěno, kdo to schválil, kdy, s jakými omezeními a proč. Bez evidence nelze obhájit postup při stížnosti, kontrole ani incidentu. |
¶ 9.6 Vazba na řízení ICT projektu
Go-live je rozhodovací bod a milník v životním cyklu ICT projektu dle Metodiky řízení ICT projektů. Tato kapitola nepředefinuje projektové role ani nevytváří paralelní procesy: go-live se řídí standardními mechanismy projektu (akceptace, změnové řízení, řízení rizik, eskalace dle tolerancí). Rozhodnutí DF-3 (GO/STOP) musí být učiněno v rámci governance projektu a zapsáno v Decision logu. Cutover, rollback a hypercare jsou provozně-orientované balíčky, které se připravují v projektu a předávají se do provozu jako součást předávacího protokolu.
TABULKA 8 – Mapování go-live aktivit na fáze a brány ICT projektu
| Aktivita (z této kapitoly) | Kdy v projektu | Jaký projektový mechanismus se použije | Důkaz (kam se ukládá) |
| Go-live readiness report + DF-3 rozhodnutí | Před spuštěním | Rozhodnutí dle governance projektu (např. Řídicí výbor) | Decision log + readiness report |
| Cutover plán | Příprava produkčního provozu / před go-live | Změnové řízení + plán nasazení | Cutover plán + vyplněný protokol |
| Rollback plán | Před go-live | Rizikové řízení + provozní připravenost + bezpečnostní schválení dle dopadů | Rollback plán + záznam ověření |
| Go-live checklist a protokol | V den go-live | Akceptační řízení a formální evidence | Go-live protokol v Evidence packu |
| Hypercare režim | Po go-live | Řízení incidentů a změn + stabilizační reporting | Triage tabulka + incidenty + release záznamy |
|
POZOR Hotfix po spuštění je změna s rizikem. Musí být řízena změnovým řízením projektu/provozu a musí mít evidenci: co se změnilo, proč, kdo schválil, jak bylo ověřeno a kdy bylo nasazeno. |
|||
¶ 10. Řízení služby po spuštění
¶ 10.1 Účel kapitoly
Účelem kapitoly je vynutit, aby digitální služba byla po spuštění řízena jako živá služba: se stabilním vlastníkem, provozní odpovědností, řízením změn, incidentů a bezpečnosti, pravidelným vyhodnocováním kvality (včetně přístupnosti), a s kontrolou provozního dluhu. Kapitola stanoví minimální governance a rytmus řízení služby v prostředí veřejné správy, kde dochází ke změnám legislativy, datových zdrojů, integrací a organizačních kompetencí.
¶ 10.2 Jaké rozhodnutí kapitola vynucuje
Orgán veřejné moci MUSÍ po go-live rozhodnout a doložit zejména:
- MUSÍ – kdo je věcný vlastník služby (business owner) a kdo je provozní vlastník (service/operations owner) – bez zavádění nových rolí mimo rámec řízení ICT projektů a řízení služby.
- MUSÍ – jaký je provozní režim (SLA/OLA, incident management, eskalace) a jak se udržuje provozní dokumentace (runbooky).
- MUSÍ – jak se řídí změny po spuštění (prioritizace, schvalování, release, evidence) a jak se rozhoduje o rozšiřování služby.
- MUSÍ – jak se řídí bezpečnost a zranitelnosti (pravidelné kontroly, patching, revize oprávnění, audit logů).
- MUSÍ – jak se vyhodnocuje kvalita služby: dostupnost, výkon, dokončenost kritických scénářů, podpora, a přístupnost.
- MUSÍ – jak se řídí právní změny a dopady na procesy a data (legislativa jako konstrukční prvek i po spuštění).
- NESMÍ – být služba „ponechána dodavateli“ bez dohledatelné odpovědnosti úřadu za rozhodnutí, změny a provozní rizika.
|
POZOR V provozu se neřeší, kdo co měl udělat v projektu. V provozu se řeší incident, dopad na uživatele a odpovědnost za rozhodnutí. Proto musí být governance služby nastavena a evidována. |
¶ 10.3 Povinné výstupy / důkazy
TABULKA 1 – Minimální Service Management pack (povinné důkazy po spuštění)
| Výstup / důkaz | Minimální obsah | Kdo odpovídá za existenci | Kdy MUSÍ existovat | Použití (k čemu slouží) | Kontrolní bod | Kde se vede |
| Service charter (základní popis služby) | Účel služby, kritické scénáře, okruh uživatelů, kanály, hranice služby, hlavní integrace, kontakty | Věcný vlastník služby + provoz; správa v evidenci služby | Do ukončení hypercare; aktualizace při změnách | Jednotný „zdroj pravdy“ pro řízení služby | DF-4 / pravidelná kontrola | Evidence služby |
| Provozní dokumentace (runbooky) | Incident postupy, degradace integrací, restart/obnova, kontakty, eskalace, okna údržby | Provozní vlastník; technická část dle prostředí | Před DF-4; průběžně | Reakce na incidenty a snížení MTTR | Měsíčně/po incidentech | Provozní evidence |
| Katalog změn / backlog (change backlog) | Požadavky, vady, priority, dopady, schválení, termíny, vlastníci | Věcný vlastník + PM/řízení změn dle režimu organizace | Od go-live; průběžně | Kontrola rozsahu a priorit | Týdenně/měsíčně | Řízení služby |
| Release plán a evidence release | Frekvence release, verze, obsah změn, testování, rollback, schválení | Provoz + dodavatel; schvaluje vlastník služby | Od stabilizace; průběžně | Zabránění „ad hoc“ změnám | Před každým releasem | Provoz + Evidence release |
| Incident registry + post-mortem | Incidenty, dopady, doby, nápravná opatření, post-mortem pro významné incidenty | Provoz | Od go-live; průběžně | Řízení dostupnosti a poučení | Týdenně/měsíčně | Provozní evidence |
| Bezpečnostní režim po spuštění | Plán patching/aktualizací, zranitelnosti, revize oprávnění, audit logů, evidence nálezů a náprav | Bezpečnost + provoz | Od go-live; průběžně | Kontrola kyber rizik | Měsíčně/kvartálně | Bezpečnostní evidence |
| KPI/SLO dashboard (minimální) | Dostupnost, chybovost, výkon, integrace, dokončenost kritických scénářů, podpora | Provoz + vlastník služby | Od DF-4; průběžně | Řízení kvality a priorit | Měsíčně | Monitoring/Reporting |
| Pravidelný review přístupnosti | Výsledky kontrol přístupnosti po změnách, evidence vad a náprav, opakovaná validace kritických scénářů | Vlastník služby + UX/obsah; dodavatel poskytuje nápravy | Po významných změnách; minimálně periodicky | Zajištění kontinuální přístupnosti | Po release / kvartálně | UX/obsah evidence |
| Evidence právních změn a dopadů | Záznam změny, dopad na proces, data, texty, UX, termíny, schválení | Věcný vlastník + právní; PM/řízení změn koordinuje | Průběžně | Zajištění souladu a auditovatelnosti | Při změně legislativy | Právo + Decision log změn |
|
TIP Service charter a Evidence služby musí být čitelné i pro nového člověka. Pokud službu nelze převzít při personální změně, governance není dostatečná. |
||||||
¶ 10.4 Typická selhání z praxe
- Po hypercare služba „spadne do šuplíku“: žádný pravidelný review, backlog se nehýbe a dluh roste.
- Změny se nasazují ad hoc bez evidence a bez schválení; vzniká neauditovatelný stav a bezpečnostní rizika.
- Incidenty se řeší operativně, ale bez post-mortem; stejné incidenty se opakují.
- Bezpečnost se považuje za jednorázovou; chybí patching, revize oprávnění a evidence zranitelností.
- Právní změny se promítají pozdě; služba je dočasně v nesouladu nebo uživatele vede k chybnému postupu.
- Monitoring existuje, ale není používán k řízení priorit; rozhoduje se podle hluku (kdo si stěžuje nejvíc).
- Dodavatel drží znalost; úřad nemá přehled o konfiguraci a není schopen kontrolovat změny a rizika.
- Přístupnost se po spuštění nehlídá; po několika releasích přestanou fungovat kritické scénáře pro část uživatelů.
|
ČASTÁ CHYBA „Je to spuštěné, hotovo.“ Ve skutečnosti je spuštění začátek nejdražší fáze: stabilní provoz a řízení změn. |
|
DŮSLEDEK Bez řízení služby po spuštění vzniká provozní dluh: náklady na údržbu rostou, bezpečnostní rizika narůstají, uživatelé se vrací k papíru a úřad ztrácí kontrolu nad dodávkou. |
¶ 10.5 Hlavní obsah kapitoly
¶ 10.5.1 Governance služby a rytmus řízení (minimum)
Checklist – minimální governance MUSÍ obsahovat:
- MUSÍ – vlastníka služby (věcný gestor) a provozního vlastníka s jasnými odpovědnostmi (kdo rozhoduje o změnách, kdo řeší incidenty).
- MUSÍ – pravidelný rytmus řízení: operativní (týdně) a strategický (měsíčně/kvartálně).
- MUSÍ – evidenci rozhodnutí o změnách a rizicích (Decision log změn / change log).
- MUSÍ – proces eskalace: kdy jde rozhodnutí mimo tým služby (např. bezpečnostní incident, právní riziko, rozpočtový dopad).
- NESMÍ – být governance závislá na konkrétní osobě bez předání – musí být přenositelná (zastupitelnost)
TABULKA 2 – Rytmus řízení služby (šablona)
| Rytmus | Cíl | Vstupy | Výstupy | Účastníci (min.) | Evidence |
| Týdenní operativní review | Incidenty, backlog, rychlé opravy, integrace | Incident registry, monitoring, backlog | Prioritizace, rozhodnutí o hotfix/release, úkoly | Vlastník služby, provoz, dodavatel (dle smlouvy) | Zápis + change log |
| Měsíční service review | Kvalita služby a trend, kapacita, dluh, plán změn | KPI/SLO dashboard, incidenty, backlog, bezpečnostní report | Plán release, rozhodnutí o prioritách, risk decisions | Vlastník služby, provoz, bezpečnost, UX | Service review report |
| Kvartální compliance a rizika | Bezpečnost, právo, přístupnost, auditovatelnost | Bezpečnostní evidence, právní změny, přístupnostní review | Nápravný plán, rozhodnutí o investicích do dluhu | Vlastník služby, bezpečnost, právní, provoz | Decision log + risk register |
|
POZOR Service review musí vyústit v rozhodnutí. Pokud je to jen „prezentace metrik“, nic se nezmění a dluh roste. |
|||||
¶ 10.5.2 Řízení incidentů a problémů (incident/problem management)
Checklist – řízení incidentů MUSÍ zajistit:
- MUSÍ – jednotnou evidenci incidentů (ID, čas, dopad, stav, vlastník, rozhodnutí).
- MUSÍ – klasifikaci incidentů (závažnost) a cílové časy reakce/obnovy dle provozního režimu.
- MUSÍ – komunikační režim při incidentech (uživatelé, přepážky, interně).
- MUSÍ – post-mortem pro významné incidenty: příčina, poučení, opatření, termíny a vlastníci.
- MUSÍ – napojení na backlog a release – incidenty se nesmí ztrácet v e-mailech.
- NESMÍ – být incident uzavřen bez rozhodnutí o nápravě nebo akceptaci zbytkového rizika.
TABULKA 3 – Incident registry (šablona)
| Incident ID | Datum/čas | Závažnost | Dopad (uživatel/proces/právo) | Detekce (monitoring/hlášení) | Stav | Vlastník | Nápravné opatření / release |
|
TIP U významných incidentů vždy zaznamenejte: kdy byly aktivovány degradační režimy, kdy byla spuštěna komunikace a kdo rozhodl. |
|||||||
¶ 10.5.3 Řízení změn po spuštění (change management)
Checklist – změnové řízení MUSÍ vynutit:
- MUSÍ – jeden backlog pro požadavky a vady s prioritou, dopadem a vlastníkem.
- MUSÍ – pravidla schvalování změn (kdo schvaluje funkční změnu, kdo schvaluje bezpečnostní dopady, kdo schvaluje komunikaci).
- MUSÍ – evidenci release: co se nasadilo, kdy, kdo schválil, jak bylo ověřeno, jaký byl rollback.
- MUSÍ – řízení konfigurace a přístupů (IAM) jako součást změnového řízení.
- MUSÍ – kontrolu dopadů na: právo, procesy, data, UX/přístupnost, bezpečnost, provoz.
- NESMÍ – být nasazena změna do produkce bez evidence a bez možnosti dohledání důkazů o testování.
TABULKA 4 – Záznam změny (šablona)
| Change ID | Popis změny | Dopad (právo/proces/data/UX/bezp./provoz) | Priorita | Schválení (kdo) | Testy / důkazy | Release / datum | Rollback |
|
ČASTÁ CHYBA Bez změnového řízení se do produkce dostanou „rychlé opravy“, které rozbijí přístupnost nebo auditní stopu. |
|||||||
¶ 10.5.4 Bezpečnost v provozu (security operations) – minimální standard
Checklist – bezpečnostní režim po spuštění MUSÍ zahrnout:
- MUSÍ – pravidelné patchování a aktualizace (plán + evidence) pro všechny komponenty v rozsahu služby.
- MUSÍ – řízení zranitelností: skeny, evidence nálezů, náprav a rozhodnutí o zbytkových rizicích.
- MUSÍ – revize oprávnění (IAM) v definované periodě a při personálních změnách; evidence revize.
- MUSÍ – pravidelný audit logů a detekci anomálií dle rizika služby.
- MUSÍ – správu tajemství/klíčů dle pravidel; omezení přístupů do produkce; audit administrátorských akcí.
- MUSÍ – cvičení incidentů: alespoň tabletop pro bezpečnostní incident a výpadek kritické integrace (periodicky).
- NESMÍ – být kritická zranitelnost „odložena“ bez formálního rozhodnutí a termínu nápravy.
TABULKA 5 – Bezpečnostní režim (šablona)
| Aktivita | Frekvence | Vstup | Výstup (důkaz) | Vlastník | Eskalace | Poznámka |
| Patching/aktualizace | ||||||
| Sken zranitelností | ||||||
| Revize oprávnění | ||||||
| Audit logů / anomálie | ||||||
|
POZOR Bezpečnostní opatření v provozu jsou „proces“: pokud není evidence, nelze prokázat, že byla opatření provedena. |
||||||
¶ 10.5.5 Řízení kvality služby (KPI/SLO) – minimální dashboard
Checklist – minimální řízení kvality MUSÍ zahrnout:
- MUSÍ – sledovat dostupnost a chybovost kritických scénářů (ne jen uptime).
- MUSÍ – sledovat výkon (odezva) pro klíčové kroky a integrace; vyhodnocovat trendy.
- MUSÍ – sledovat dokončenost kritických scénářů (drop-off) a důvody selhání (včetně validací).
- MUSÍ – sledovat zatížení podpory (objem, typy dotazů) a používat ho pro prioritizaci.
- MUSÍ – mít definované prahy pro eskalaci a rozhodnutí o omezení/rollbacku funkce při degradaci.
- NESMÍ – být metriky jen sbírané; musí být rozhodovací (navázané na backlog a opatření).
TABULKA 6 – Minimální KPI/SLO dashboard (šablona)
| Oblast | Metrika | Cíl/SLO | Aktuální stav | Trend | Rozhodnutí (opatření) | Vlastník |
| Kritické scénáře | Úspěšnost dokončení kritického scénáře | |||||
| Dostupnost | Dostupnost syntetických testů kritických scénářů | |||||
| Integrace | Chybovost kritických integrací / fallbacky | |||||
| Výkon | 95. percentil odezvy pro klíčové kroky | |||||
| Podpora | Počet kontaktů na podporu / top důvody | |||||
|
TIP Pro veřejnou službu je často nejdůležitější metrika: „kolik lidí dokončilo kritický scénář bez zásahu úřadu“. |
||||||
¶ 10.5.6 Udržení přístupnosti po spuštění (kontinuální)
Checklist – přístupnost po spuštění MUSÍ být řízena takto:
- MUSÍ – být přístupnost součástí akceptace každé významné změny (release) – minimálně na kritických scénářích.
- MUSÍ – existovat evidence vad přístupnosti a jejich náprav v backlogu (ne odděleně).
- MUSÍ – být u změn, které mění UI/flow, provedena kontrola klávesnice a screen reader scénářů (dle pravidel organizace).
- MUSÍ – být periodický review přístupnosti i bez změn (minimálně dle interního režimu), aby se zachytil degradující stav.
- NESMÍ – být přístupnost řešena až na základě stížnosti – to znamená, že kontrolní mechanismus selhal.
|
POZOR Přístupnost se nejčastěji rozbije drobnými UI změnami nebo změnou validací. Proto musí být přístupnost v change procesu. |
¶ 10.5.7 Řízení právních a policy změn po spuštění
Checklist – právní změny MUSÍ být řízeny jako změny služby:
- MUSÍ – existovat evidence právních změn a jejich dopadů (na proces, data, texty, rozhodnutí, integrace).
- MUSÍ – být rozhodnuto, zda změna vyžaduje úpravu služby, změnu provozních pravidel nebo pouze obsahovou změnu.
- MUSÍ – být změna promítnuta do právně významných textů a komunikace (včetně verzování).
- MUSÍ – být změna evidována v Decision logu změn a napojena na release/operativní opatření.
- NESMÍ – být právní změna „zapracována bez evidence“ – hrozí neobhajitelnost postupu.
TABULKA 7 – Evidence právní změny (šablona)
| ID změny | Popis změny (právní/policy) | Dopad na proces | Dopad na data/integrace | Dopad na texty/UX | Rozhodnutí + termín | Schválil / datum |
|
ČASTÁ CHYBA Změna legislativy se řeší pouze metodickým pokynem. Pokud služba zůstane v původním flow, vzniká rozpor a uživatel je penalizován. |
||||||
¶ 10.5.8 Kontrola dodavatelské závislosti a znalostní udržitelnost
Checklist – úřad MUSÍ zajistit:
- MUSÍ – dohledatelnost konfigurace, verzí, přístupů a dokumentace nezávisle na konkrétním dodavateli.
- MUSÍ – předávání znalostí: pravidelné předávky, aktualizace dokumentace, přenos odpovědnosti.
- MUSÍ – smluvně a procesně ošetřené reakční doby a podporu (včetně bezpečnostních incidentů).
- MUSÍ – minimální schopnost úřadu ověřit změnu a rozhodnout o prioritě (ne jen přijímat návrhy dodavatele).
- NESMÍ – být jediný člověk/dodavatel, který „ví, jak to běží“ – to je provozní a bezpečnostní riziko.
TABULKA 8 – Knowledge transfer a vendor control (šablona)
| Oblast | Co musí být předáno | Frekvence aktualizace | Kdo vlastní | Důkaz | Riziko, když chybí |
| Konfigurace a prostředí | |||||
| Runbooky a provozní postupy | |||||
| Release a změny | |||||
| Integrace a degradační režimy | |||||
|
DŮSLEDEK Pokud úřad nekontroluje znalosti a konfiguraci, vzniká vendor lock-in a služba je neřiditelná při změně dodavatele nebo lidí. |
|||||
¶ 10.6 Vazba na řízení ICT projektu
Po spuštění se řízení přesouvá z režimu „řízení ICT projektu“ do režimu „řízení služby“. Tato kapitola jasně odděluje: ICT projekt končí předáním a stabilizací (DF-4), zatímco služba pokračuje a vyžaduje pravidelné řízení incidentů, změn, bezpečnosti, přístupnosti a právních dopadů. Změny po spuštění mohou být řízeny buď jako změny služby, nebo – pokud svou složitostí překročí běžný režim změn – mohou vyústit v nový ICT projekt. Rozhodnutí o tom MUSÍ být evidováno a použito standardní řízení dle Metodiky řízení ICT projektů (záměr, governance, brány, rizika).
TABULKA 9 – Kdy je změna „změna služby“ a kdy „nový ICT projekt“ (rozhodovací minimum)
| Kritérium | Změna služby (běžný režim) | Nový ICT projekt | Rozhodnutí a evidence | Typické riziko |
| Rozsah změny | Úprava dílčí funkce bez zásahu do architektury | Nová služba / zásadní rozšíření / změna architektury | Rozhodnutí v service review / řídicí orgán | Skryté náklady |
| Integrace | Bez nových kritických integrací | Nové registry/integrace nebo změna kritické integrace | Decision log změn / projektový záměr | Výpadky, závislosti |
| Bezpečnost a data | Bez změny klasifikace nebo dopadu | Změna klasifikace, nové citlivé údaje, nové role, nový threat model | Bezpečnostní schválení + governance projektu | Incident / sankce |
| UX a přístupnost | Dílčí UI změny s kontrolou kritických scénářů | Nové flow, nové kanály, zásadní přepracování | Akceptační režim / projekt | Nedokončenost scénářů |
| Rozpočet a termín | V rámci provozních kapacit a běžného release rytmu | Vyžaduje samostatný rozpočet, veřejnou zakázku nebo dlouhý harmonogram | Záměr a schválení projektu dle metodiky | Neschválené čerpání |
|
POZOR Pokud změna překročí běžný režim a přesto se řídí jako „běžná změna“, vzniká skrytý projekt bez governance a bez bran. To je nejčastější způsob, jak se do provozu dostanou neřízené zásadní změny. |
||||
¶ 11. Nejčastější selhání digitalizace
¶ 11.1 Účel kapitoly
Účelem kapitoly je vynutit, aby orgán veřejné moci systematicky rozpoznal, zastavil a neopakoval typická selhání digitalizace ještě před tím, než se promítnou do chyb v provozu, stížností, právní neobhajitelnosti nebo do vendor lock-in. Kapitola poskytuje katalog selhání (antipatterns) z praxe veřejné správy, jejich signály, dopady, minimální preventivní kontroly a požadované důkazy. Kapitola je rozhodovací: každé selhání musí mít „STOP triggery“ a konkrétní kontrolní opatření navázané na brány DF a na řízení ICT projektu.
¶ 11.2 Jaké rozhodnutí kapitola vynucuje
Orgán veřejné moci MUSÍ rozhodnout a doložit, že:
- MUSÍ – používá jednotný katalog selhání a kontroluje ho v branách DF (minimálně DF-1 až DF-3).
- MUSÍ – má definované STOP triggery a eskalační cestu: kdy se rozhodnutí vrací (STOP) a kdo rozhoduje o výjimce (pokud je přípustná).
- MUSÍ – vede evidenci zjištěných selhání, jejich nápravy a rozhodnutí o zbytkovém riziku (Decision log + Risk/Issue registry).
- MUSÍ – vyžaduje důkazy (artefakty) k prevenci selhání – neakceptuje deklarace bez evidence.
- NESMÍ – spustit službu (go-live), pokud existuje selhání typu „hard stop“ uvedené v této kapitole bez nápravy nebo bez formálního rozhodnutí o akceptaci (pokud je přípustné).
|
POZOR „Selhání“ není obecná stížnost na projekt. Selhání je opakovatelný vzor, který má rozpoznatelné signály a preventivní kontrolu. Pokud nejsou signály a kontrola jasné, nelze selhání řídit ani zastavit. |
¶ 11.3 Povinné výstupy / důkazy
TABULKA 1 – Povinné důkazy pro práci se selháními (Anti-failure pack)
| Výstup / důkaz | Minimální obsah | Kdo odpovídá za existenci | Kdy MUSÍ existovat | Použití (k čemu slouží) | Kontrolní bod (brána) | Kde se vede |
| Katalog selhání (tato kapitola) jako checklist | Seznam selhání, hard stop/soft stop, signály, požadované důkazy, odkazy na relevantní kapitoly metodiky | PM + věcný gestor; útvary přispívají dle tématu | Před DF-1; aktualizace před DF-2 a DF-3 | Jednotný standard kontroly | DF-1 až DF-3 | Gate pack / Evidence pack |
| Evidence pack index (rejstřík důkazů) | Odkazy na artefakty pro prevenci selhání (právo, proces/data, UX/přístupnost, bezpečnost, provoz) | PM | Před DF-1; aktualizace průběžně | Dohledatelnost a audit | DF-1 až DF-3 | Evidence pack |
| Decision log (rozhodnutí + výjimky) | GO/STOP, podmínky, akceptace rizika, odůvodnění, vlastníci a termíny | PM; schvaluje governance projektu | Od DF-1 průběžně; uzavřený před DF-3 | Obhajitelnost rozhodnutí | DF-1 až DF-4 | Řízení projektu – Decision log |
| Risk/Issue registry (selhání jako rizika a issues) | Záznam selhání, dopad, vlastník, nápravný plán, termín, eskalace | PM + vlastníci dle oblasti | Od DF-1 průběžně | Řízení tolerancí a eskalace | DF-1 až DF-3 | Řízení projektu – rizika/issues |
| Post-mortem a lessons learned (po incidentech a významných odchylkách) | Příčina, rozhodnutí, opatření, termíny, změny v checklistech a standardech | Provoz (incidenty) / PM (projektové odchylky) | Po významných incidentech / po DF-4 | Zabránění opakování selhání | DF-4 / řízení služby | Provozní evidence + Řízení služby |
|
TIP Selhání se MUSÍ zapisovat jako rizika/issues s vlastníkem a termínem. „Ví se o tom“ bez evidence znamená, že se to nestane prioritou a problém se vrátí v provozu. |
||||||
¶ 11.4 Typická selhání z praxe
- Zaměnění digitalizace za „webový formulář“ bez end-to-end procesu a odpovědností.
- Právo a právní účinky se řeší až po vývoji; právně významné texty nejsou schválené a verzované.
- Chybí vlastnictví dat a integrací; integrace se „předpokládají“ bez dohody a fallbacku.
- UX a přístupnost jsou „design“, ne rozhodnutí; kritické scénáře nejsou testovatelné.
- Bezpečnost je deklarace bez důkazů; logy existují, ale nejsou použitelné a nejsou napojené na reakci.
- Provoz je přizván pozdě; chybí monitoring, runbooky a test obnovy.
- Go-live se provede pod tlakem termínu bez rollbacku a hypercare; první týdny selžou.
- Změny po spuštění jsou ad hoc; vzniká neauditovatelný stav, dluh a vendor lock-in.
|
ČASTÁ CHYBA Projekt se hodnotí podle „dodání“ (vývoj hotov), ne podle schopnosti služby být používána a obhajitelně provozována. |
Pozn.: Prakticky se selhání dají seskupit do čtyř oblastí (pomáhá při rychlé diagnostice a při definování důkazů do Evidence packu):
Technologická selhání
- legacy a nejasné integrace, chybějící fallback/rollback
- nedořešená bezpečnost jako evidence (logy, testy, monitoring)
- technický dluh a vendor lock-in vznikající už během dodávky
Organizační selhání
- nejasné role a odpovědnosti (vlastník služby vs. řízení ICT projektu)
- nedostatek kapacit a know-how, závislost na dodavateli
- provoz a podpora přizvány pozdě, chybí runbooky a rytmus řízení
Legislativní selhání
- právní účinky a právně významné texty řešené až po vývoji
- nejasná právní opora pro zpracování dat / sdílení dat
- absence verze, schválení a auditní stopy pro právní část služby
Společenská/uživatelská selhání
- služba není navržená podle kritických scénářů uživatele
- nízká přístupnost, nejasné instrukce, chybové stavy bez řešení
- nízká důvěra – uživatelé nevěří, že podání „prošlo“ (chybí potvrzení, status, dohledatelnost)
¶ 11.5 Hlavní obsah kapitoly
¶ 11.5.1 Katalog selhání (antipatterns) – signály, dopady, prevence
TABULKA 2 – Katalog selhání (používat jako kontrolní seznam v DF branách)
| ID | Selhání (vzor) | Hard stop? | Typické signály | Dopad | Minimální prevence (kontrola) | Požadovaný důkaz | Kdy se odhaluje | Vazba na kapitolu |
| F-01 | Nejasná hranice služby a kritické scénáře | ANO | Rozsah se mění; „to se dořeší“; různé definice u útvarů/dodavatele | Skluz, dodatky, neobhajitelné rozhodnutí o rozsahu | Definice služby + seznam kritických scénářů + co není součástí | Service definice (kap. 1–2) + akceptační kritéria (kap. 5) | DF-1 | 1,2,5,7 |
| F-02 | Právo řešené až po vývoji | ANO | Právní útvar není v Decision logu; texty nejsou schválené; chybí verzování | Neplatné postupy, stížnosti, rušení rozhodnutí | Právní konstrukce + schválení právně významných informací | Právní konstrukce, seznam právně významných textů (kap. 3) | DF-1, DF-3 | 3,7,8 |
| F-03 | Proces existuje jen „na papíře“, ne v provozu | ANO | Nejsou výjimky; není napojení na evidenci/spis; ruční obcházení | Chaos v provozu, ztráta důkazů, růst papíru | Proces L0/L1 + výjimky + odpovědnosti + evidence | Mapa procesu + výjimky + evidence (kap. 4) | DF-1, DF-2 | 4,7 |
| F-04 | Data bez vlastníka a autority (data ownership) | ANO | Spory o „správná data“; integrace bez odpovědného útvaru; nejasné zdroje pravdy | Nekonzistence, chyby, právní spory | Datová inventura + vlastníci + pravidla oprav | Datová inventura + pravidla oprav (kap. 4) | DF-1 | 4,7 |
| F-05 | Integrace bez degradačních režimů | ANO | „Když registr nejede, tak to nejde“; fallback není definován; výpadky paralyzují službu | Výpadky, improvizace mimo evidence, dotazy/stížnosti | Pro kritické integrace fallback a texty pro uživatele | Šablona degradačních režimů + runbook (kap. 6,8) | DF-3 | 6,8 |
| F-06 | UX jako estetika, ne jako dokončení kritického scénáře | ANO | Vysoké drop-off; nejasné texty; uživatel neví, co dělat; chybí IA/flow | Nedokončení podání, přepážka přebírá práci | IA/flow + texty + testy kritických scénářů | IA/flow + protokoly testů (kap. 5) | DF-2 | 5,7 |
| F-07 | Přístupnost řešená až po stížnosti | ANO | Neexistuje důkaz přístupnosti; „dodělá se“; po releasu se zhoršuje | Diskriminace, reputace, právní riziko | Přístupnostní plán + ověřování kritických scénářů | Protokoly přístupnosti + backlog vad (kap. 5,9) | DF-2, po release | 5,9 |
| F-08 | Bezpečnost deklarativní bez důkazů | ANO | Chybí výsledky testů; neexistuje evidence náprav; sdílené účty | Incident, únik dat, sankce | Security baseline + testy + rozhodnutí o zbytkovém riziku | Bezpečnostní protokoly + decision o riziku (kap. 6,7) | DF-2, DF-3 | 6,7 |
| F-09 | Logy existují, ale nejsou použitelné | ANO | Nelze dohledat konkrétní případ; chybí korelace; logy bez runbooku | Neobhajitelnost, dlouhé incidenty | Logování + korelační ID + postup reakce | Monitoring & logging požadavky + runbook (kap. 6) | DF-3 | 6,8 |
| F-10 | Provoz přizvaný na konci (předávka = „kód“) | ANO | Chybí runbook, přístupy, monitoring; test obnovy není; provoz odmítá převzetí | Neřízený provoz, dlouhé výpadky | Operating model + handover pack + restore test | Provozní model + předávací protokol (kap. 6,8) | DF-2, DF-3 | 6,8,7 |
| F-11 | Go-live bez rollbacku a hypercare | ANO | Neexistuje cutover/rollback; žádná zvýšená podpora; incidenty bez triage | Chaos, reputační škoda, návrat k papíru | Cutover + rollback + hypercare režim | Go-live pack (kap. 8) | DF-3 | 8,7 |
| F-12 | Změny po spuštění ad hoc, bez evidence | ANO | Hotfix bez schválení; nejasné verze; nárůst vad; „nevíme, co je v produkci“ | Neauditovatelný stav, dluh, bezpečnostní riziko | Change backlog + release evidence + governance služby | Change log + release evidence (kap. 9) | Po DF-4 | 9 |
| F-13 | Dodavatelská závislost a ztráta znalostí | ANO | Znalost drží jednotlivec; dokumentace chybí; úřad neumí rozhodovat | Vendor lock-in, neschopnost změny | Evidence konfigurace, know-how předávky, kontrola přístupů | Knowledge transfer evidence (kap. 9) | DF-4 a provoz | 9 |
| F-14 | Metriky nejsou rozhodovací (sbírá se, ale neřídí) | NE (soft stop) | Dashboard bez akce; backlog neroste podle dopadu; rozhoduje „kdo křičí“ | Zhoršující se kvalita, nárůst dotazů | KPI/SLO navázané na rozhodnutí a backlog | Service review report (kap. 9) | Po DF-4 | 9 |
|
POZOR Hard stop znamená: bez nápravy nelze pokračovat do další brány. Soft stop znamená: lze pokračovat pouze s formální podmínkou (vlastník, termín, důkaz) a s řízeným rizikem. |
||||||||
¶ 11.5.2 Kontrola selhání v branách DF (minimální checklist)
Checklist DF-1 (před realizací) – nejčastější STOP body:
- MUSÍ – být uzavřen rozsah a kritické scénáře (F-01).
- MUSÍ – být uzavřena právní konstrukce a schváleny právně významné texty (F-02).
- MUSÍ – být uzavřeny procesy (L0/L1) včetně výjimek a evidence (F-03).
- MUSÍ – být uzavřeno vlastnictví dat a integrací (F-04).
- MUSÍ – být uzavřeno architektonické vymezení a bezpečnostní klasifikace (F-08).
- NESMÍ – být rozhodnutí „odložena na dodavatele“ bez evidence v Decision logu.
Checklist DF-2 (před převzetím) – nejčastější STOP body:
- MUSÍ – existovat protokoly testů kritických scénářů (F-06).
- MUSÍ – existovat důkaz přístupnosti pro kritické scénáře a evidence vad (F-07).
- MUSÍ – existovat bezpečnostní důkazy a evidence náprav (F-08).
- MUSÍ – existovat handover pack: runbooky, monitoring, přístupy, restore test (F-10).
- NESMÍ – existovat kritické vady blokující kritický scénář.
Checklist DF-3 (go-live) – nejčastější STOP body:
- MUSÍ – existovat cutover a rollback plán a ověření (F-11).
- MUSÍ – být aktivní monitoring/alerting a provozní eskalace (F-09, F-10).
- MUSÍ – mít definované degradační režimy integrací a komunikaci pro výpadky (F-05).
- MUSÍ – mít nastaven hypercare a denní triage režim (F-11).
- NESMÍ – proběhnout go-live bez GO/STOP rozhodnutí a evidence v Decision logu.
|
TIP Do gate checklistu vždy uveďte odkaz na konkrétní důkaz. „Splněno“ bez odkazu je považováno za nesplněno. |
¶ 11.5.3 Včasné signály selhání (early warning) – co sledovat
Checklist – včasné signály, které MĚLY BY vyvolat eskalaci nebo STOP:
- MĚLO BY – přibývání změn rozsahu bez aktualizace kritických scénářů a bez dopadové analýzy (F-01).
- MĚLO BY – vznik nových „právních výjimek“ bez rozhodnutí v Decision logu (F-02).
- MĚLO BY – nejasné odpovědnosti za integrace nebo odmítání poskytnout rozhraní (F-04, F-05).
- MĚLO BY – přesun řešení problémů do e-mailu/telefonu bez evidence v issues (F-03, F-12).
- MĚLO BY – odkládání přístupnosti, testů obnovy, monitoringu na „později“ (F-07, F-10).
- MĚLO BY – časté hotfixe bez release evidence a bez změnového řízení (F-12).
- MĚLO BY – závislost na jednotlivci (dodavatel/úředník), který jediný „ví jak“ (F-13).
|
DŮSLEDEK Ignorování včasných signálů vede k tomu, že se selhání projeví až při DF-3 nebo v provozu, kdy je oprava nejdražší. |
¶ 11.5.4 Minimální zásahy (co udělat, když se selhání objeví)
TABULKA 3 – Rychlá nápravná opatření (minimální)
| Selhání | Okamžité rozhodnutí | Minimální náprava (co doplnit) | Kdo zajišťuje (útvar) | Důkaz | Do kdy | Eskalace |
| F-01 Nejasný rozsah | STOP do DF-1 / změnové řízení | Uzavřít kritické scénáře + akceptační kritéria + co není součástí | Věcný gestor + PM + UX | Aktualizovaný seznam scénářů + Decision log | Před zahájením realizace | Governance projektu |
| F-02 Neuzavřené právo | STOP do DF-1 | Schválit právní konstrukci a právně významné texty + verzování | Právní + věcný gestor | Schválení + seznam textů + verze | Před DF-1 | Governance projektu |
| F-05 Bez fallbacku integrací | STOP do DF-3 | Doplnit degradační režimy + runbook + texty pro uživatele | Architektura + provoz + UX/obsah | Tabulka degradačních režimů + runbook | Před DF-3 | Governance projektu |
| F-10 Provozní nepřipravenost | STOP do DF-2/DF-3 | Doplnit monitoring, runbooky, přístupy, restore test a předávku | Provoz + bezpečnost + dodavatel | Předávací protokol + protokol obnovy | Před DF-3 | Řídicí orgán projektu |
| F-12 Ad hoc změny v provozu | Zastavit ad hoc nasazování | Zavést change backlog + release evidence + pravidla schvalování | Vlastník služby + provoz | Change log + release evidence | Do 2 týdnů od zjištění | Vedoucí provozu / governance služby |
|
POZOR Rychlá náprava nesmí být „rychlý patch“ bez evidence. Náprava musí posílit kontrolní mechanismus (důkaz + pravidlo), jinak se selhání vrátí. |
||||||
¶ 11.5.5 Nejčastější „dokumentové“ a governance selhání (co NESMÍ projít)
Checklist – následující stavy NESMÍ být akceptovány jako důkazy:
- NESMÍ – „Seznam požadavků“ bez akceptačních kritérií a bez kritických scénářů (F-01, F-06).
- NESMÍ – právní stanovisko bez navázání na konkrétní texty ve službě a bez verzování (F-02).
- NESMÍ – procesní diagram bez výjimek a bez vymezení odpovědností a evidence (F-03).
- NESMÍ – bezpečnostní prohlášení bez výsledků testů a bez evidence náprav (F-08).
- NESMÍ – „máme zálohy“ bez testu obnovy (F-10).
- NESMÍ – „monitoring je nastaven“ bez alertingu, vlastníků a runbooku (F-09).
- NESMÍ – GO s podmínkami bez vlastníka, termínu a důkazu (kap. 7).
|
ČASTÁ CHYBA Za „důkaz“ se považuje dokument vytvořený dodavatelem bez schválení a bez vazby na rozhodnutí a provozní dopady. |
¶ 11.6 Vazba na řízení ICT projektu
Katalog selhání je používán jako kontrolní mechanismus v rámci řízení ICT projektu dle Metodiky řízení ICT projektů. Kapitola nevytváří nové projektové role ani paralelní procesy: selhání se zapisují do standardních evidencí projektu (risk/issue registry, change log, decision log) a řeší se prostřednictvím standardních projektových mechanismů (řízení změn, řízení rizik, akceptace, eskalace dle tolerancí). Brány DF (kap. 7) jsou použity jako formální body, kde se selhání musí prokazatelně uzavřít (STOP/GO).
TABULKA 4 – Mapování selhání na projektové mechanismy (jak se to řídí v projektu)
| Typ selhání | Primární mechanismus v ICT projektu | Kdy eskalovat | Co je výstup (důkaz) | Kde se eviduje | Vazba na DF bránu |
| Rozsah, scénáře, akceptační kritéria (F-01, F-06) | Řízení rozsahu + akceptační řízení | Při změně kritických scénářů / skluzech / sporu o „co se dodává“ | Aktualizované scénáře + akceptační kritéria + rozhodnutí | Decision log + backlog | DF-1, DF-2 |
| Právní konstrukce a texty (F-02) | Schvalování a compliance v projektu | Při nejasných právních účincích nebo změně legislativy | Schválení právně významných textů + verzování | Evidence pack + decision log | DF-1, DF-3 |
| Proces, data, integrace (F-03, F-04, F-05) | Řízení závislostí + řízení rizik | Při odmítnutí integrace / výpadcích / nejasném vlastnictví | Datová inventura + degradační režimy + runbook | Risk/issue registry + evidence pack | DF-1, DF-3 |
| Bezpečnost, logování, provozní připravenost (F-08, F-09, F-10) | Akceptace + řízení rizik + provozní předávka | Při kritických nálezech, neauditovaných přístupech, chybějících důkazech obnovy | Testy + nápravy + provozní artefakty | Evidence pack + risk/issue registry | DF-2, DF-3 |
| Go-live režim (F-11) | Go-live řízení jako milník projektu | Při absenci rollbacku/hypercare nebo při nejistotě integrací | Cutover/rollback/hypercare pack | Go-live pack + decision log | DF-3 |
| Změny po spuštění (F-12 až F-14) | Přechod do řízení služby; pokud rozsah velký, nový projekt | Při ad hoc změnách nebo při překročení kapacit/rozpočtu | Change log + release evidence + service review rozhodnutí | Řízení služby + (případně) nový projektový záměr | DF-4 / řízení služby |
|
POZOR Pokud selhání není zachyceno v risk/issue registry a v Decision logu, neexistuje formální odpovědnost a nelze ho řídit. To odporuje principům řízení ICT projektu a vede k opakování stejné chyby. |
|||||
¶ 12. Přílohy metodického balíčku (A–E)
Přílohy jsou součástí metodického balíčku Digital First a jsou vydávány jako samostatné dokumenty. Při odkazování uvádějte vždy označení přílohy (A–E) a název dokumentu. Použití příloh se doporučuje evidovat v rozhodovací evidenci (např. Decision log / evidence pack), pokud je to relevantní pro auditovatelnost.
- Příloha A – Kontrolní seznamy Digital First (A1…): kontrolní otázky a minimální důkazy.
- Příloha B – Šablony a formuláře: vyplnitelné šablony pro evidenci rozhodnutí, rolí a řízení změn.
- Příloha C – Slovník pojmů: sjednocení terminologie napříč týmy a dokumenty.
- Příloha D – Legislativa a zdroje: orientační přehled právních a metodických zdrojů (doporučeno ověřovat aktuálnost).
- Příloha E – Přehled zkratek: jednotné zkratky používané v metodice a přílohách.
Poznámka: Ilustrativní obrázky, schémata a příklady zahraniční praxe mohou být používány jako podpůrné materiály, nejsou však normativní součástí příloh A–E ani povinným důkazem samy o sobě.
¶ 12.1 Doplňkové materiály – zahraniční praxe a příklady z ČR
¶ 12.1.1 Zahraniční praxe – co převzít a jak to použít
Zahraniční standardy fungují zejména díky tomu, že kombinují: (1) jasná kritéria, (2) panelové brány/assessment, (3) povinné důkazy, (4) rytmus měření po spuštění. Tyto prvky jsou přenositelné i do české praxe.
|
TIP Zahraniční příklady uvádějte jako inspirační zdroje. Převzaté prvky musí být mapovány na české role, důkazy a brány ICT projektového řízení. |
¶ 12.1.2 Mapovací tabulka (inspirace → konkrétní doplnění)
| Země / praxe | Podstata | Konkrétní prvek k převzetí | Kam vložit (metodika) | Poznámka |
| UK | Service Standard + service assessments | Service assessment panel s výstupem PASS/CONDITIONAL/FAIL a povinnými důkazy | FULL Kap. 7; LIGHT Kap. 7 (spouštěče) | Model bran a hodnocení |
| USA | Digital Services Playbook (13 plays) | Kontrolní otázky při zahájení a go-live (uživatelé, iterace, tým, měření) | FULL Kap. 2 a 8; LIGHT Kap. 2–6 | Použitelné jako pre-mortem |
| Austrálie | Digital Service Standard | Checkpointy: inkluze, důvěra, monitoring služby | FULL Kap. 5/6/9; LIGHT Kap. 4/5/6 | Silné na měření služby |
| Nový Zéland | Digital Service Design Standard | Princip „design pro celý životní cyklus služby“ | FULL Kap. 0/9; LIGHT Kap. 6 | Důraz na provoz a zlepšování |
| Kanada | Digital Standards + Guideline on Service and Digital | Standardy jako základ + důraz na důvěryhodnost, bezpečnost, otevřenost | FULL Kap. 6/9; LIGHT Kap. 5/6 | Dobré pro governance po go-live |
| NHS (UK) | Sektorová adaptace Service Standardu | Společný standard + sektorové body (specifika domény) | Příloha (sektorové přílohy) | Vzor pro resortní dodatky |
| Ontario (Kanada) | Digital Service Standard + assessment | 1stránkový „poster“ pro vedení + assessment proces | Úvod + FULL Kap. 7 | Užitečné pro prosazení standardu |
| Dánsko | Digital-ready legislation | Checklist digital-ready prvků legislativy | FULL Kap. 3 | Vhodné pro legislativní změny |
| Estonsko/EU | Once-only + bezpečná výměna dat | Once-only kontrolní otázky + zdůvodnění, proč se data sbírají znovu | FULL Kap. 4/6; LIGHT Kap. 1/4 | Vždy s právním titulem a interoperabilitou |
¶ 12.1.3 Příklad z praxe v ČR: eRecept (přenositelné principy)
Příklad z praxe v ČR: eRecept je ilustrace úspěšné digitalizace konkrétní agendy, kde byl nastaven jasný právní rámec, centrální governance a jednotný provozní model.
Poučení pro Digital First není „kopírovat řešení“, ale převzít principy: jasné rozhodnutí o odpovědnosti, integrace jako dohoda (ne předpoklad), bezpečnost jako evidence a průběžné měření kvality po spuštění.
Co je přenositelné do jiných služeb:
- Jasná odpovědnost (vlastník služby) a jednotný provozní režim (kdo reaguje na incidenty, kdo měří kvalitu).
- Integrační disciplína: definované rozhraní, fallback, auditní stopa.
- Důvěra uživatelů: potvrzení, dohledatelnost stavu, srozumitelné informace.
- Průběžné zlepšování po spuštění (release discipline + health report).
¶ 12.2 Zdroje (zahraniční standardy – odkazy)
TABULKA 5 – Odkazové zdroje použité jako inspirace
| Zdroj | URL | Využití v metodice |
| UK – Service Standard (GOV.UK) | https://www.gov.uk/service-manual/service-standard | Kritéria služby + inspirace pro panelové brány |
| UK – Service assessments (GOV.UK) | https://www.gov.uk/service-manual/service-assessments | Model assessment panelu |
| USA – Digital Services Playbook (USDS) | https://playbook.usds.gov/ | Kontrolní otázky (13 plays) pro zahájení a go-live |
| Austrálie – Digital Service Standard (digital.gov.au) | https://www.digital.gov.au/policy/digital-experience/digital-service-standard | Checkpointy inkluze, měření a provozu |
| Nový Zéland – Digital Service Design Standard | https://www.digital.govt.nz/standards-and-guidance/digital-service-design-standard | Principy designu pro celý životní cyklus |
| Kanada – Digital Standards | https://www.canada.ca/en/government/system/digital-government/government-canada-digital-standards.html | Standardy pro důvěryhodné služby |
| Kanada – Guideline on Service and Digital | https://www.canada.ca/en/government/system/digital-government/guideline-service-digital.html | Doporučení pro implementaci standardů |
| NHS – NHS service standard | https://service-manual.nhs.uk/standards-and-technology/service-standard | Sektorová adaptace standardu |
| Ontario – Digital Service Standard | https://www.ontario.ca/page/digital-service-standard | 13 bodů + inspirace pro interní „poster“ |
| Dánsko – Guidance on digital-ready legislation | https://en.digst.dk/digital-transformation/digital-ready-legislation/guidances-and-tools/guidance-on-digital-ready-legislation/ | Checklist pro digital-ready legislativu |
| Estonsko – X-Road (e-Estonia) | https://e-estonia.com/solutions/interoperability-services/x-road/ | Příklad bezpečné výměny dat (princip) |
| X-Road (projekt) | https://x-road.global/ | Referenční zdroj pro koncept datové výměny |
| EU – Once-Only Principle (TOOP/ISA²) | https://ec.europa.eu/isa2/isa2conf18/once-only-principle-project-toop_en | Princip once-only pro kontrolní otázky v datech |