# Business Requirements Document (BRD)
# Dashboard dopadu digitalizace veřejné správy („e-government dashboard“)

| | |
|---|---|
| **Verze** | 0.1 – pracovní návrh |
| **Datum** | 24. 7. 2026 |
| **Autor** | Jakub Bareš (AFCEA ČR, kGovernment / Mapa státu) |
| **Status** | Návrh k připomínkování – vstup pro pilotní verzi slíbenou Bohdanu Urbanovi (DIA) |
| **Primární zdroj požadavků** | Jednání „24. schůzka – Mapa státu další kroky“, 17. 7. 2026, 14:00–15:23 (Fireflies ID `01KX6ANKPFXHGHZZ85VR7KSBYH`); navazuje na „21. schůzka – Mapa státu další kroky“ (26. 6. 2026), „20. schůzka – Mapa státu s Bohdanem Urbanem“ (19. 6. 2026) a „DIA & AFCEA MapaStátu.cz“ (16. 6. 2026) |
| **Sponzor za DIA** | Bohdan Urban, Digitální a informační agentura (DIA), `bohdan.urban@dia.gov.cz` |
| **Sponzor/nositel za AFCEA** | Jakub Bareš, ve spolupráci s Petrem Kučerou (PowerPatterns), Jaroslavem Pejčochem, Martinem Vlastou, Tomášem Vejlupkem |

> **Poznámka k metodě zpracování:** Tento dokument vychází z doslovného přepisu (STT) živého pracovního jednání. Citované formulace Bohdana Urbana jsou parafrázované, ale věcně zachovávají jeho myšlenkový postup. Číselné příklady, které v jednání zazněly, jsou explicitně označeny jako **ilustrativní odhady „na ubrousek“** (Urbanovými slovy „green table úvaha“, „bivokov odhad“) – před jakoukoli veřejnou prezentací je nutné je přepočítat a podložit tvrdými daty (viz kap. 11).

---

## 1. Executive Summary

DIA (Digitální a informační agentura) a tým AFCEA/Mapa státu se shodly na potřebě nástroje, který by **datově a metodicky podložil dopad digitalizace veřejné správy** – nikoli jako technický seznam „co už je online“, ale jako ekonomický a organizační příběh: kolik času, peněz a byrokratické zátěže digitalizace reálně ušetřila (nebo může ušetřit) občanům, firmám a samotnému státu.

Bohdan Urban (DIA) formuloval tento požadavek explicitně jako **chybějící „elementární nástroj pro sledování impactu jednotlivých agend“** – DIA dnes nemá strukturovaný, metodicky podložený způsob, jak tento dopad měřit a komunikovat směrem k politickému vedení (premiér, vláda, Grémium eGovernmentu).

Navrhovaný dashboard je rozšířením platformy **Mapa státu** (mapastatu.cz) o novou vrstvu – pracovně nazvanou **„e-government dashboard“** / „digitální krevní oběh státu“ (Urbanova metafora, viz kap. 3.2) – která:

1. měří a vizualizuje **stupeň digitalizace** jednotlivých agend/služeb státu,
2. počítá a prezentuje **ekonomický dopad** (ušetřený čas × mzda × četnost) na úrovni jednotlivé služby i celých řetězených agend,
3. identifikuje **„tlustá místa“** – úseky, kde digitální proces naráží na papírový krok,
4. v pozdější fázi nabízí **prediktivní kapacitní monitoring** digitální infrastruktury státu,
5. využívá **veřejnou vizualizaci výkonu** (zelená/červená mapa úřadů/obcí) jako motivační nástroj – mechanismus, který DIA již úspěšně ověřila u onboardingu obcí do systému CAIS.

Tým AFCEA se zavázal připravit **první pracovní verzi dashboardu do pátku 24. 7. 2026** (den vydání tohoto BRD) k demonstraci Bohdanu Urbanovi. DIA se zavázala poskytnout tvrdá data z prezentace pro Grémium eGovernmentu a zapojit kolegyni odpovědnou za interní „nástroj pro měření digitalizace“ na DIA.

---

## 2. Kontext a zdůvodnění (Business Case)

### 2.1 Kde tento požadavek vznikl

Spolupráce AFCEA a DIA na projektu Mapa státu probíhá od poloviny června 2026 (viz „DIA & AFCEA MapaStátu.cz“, 16. 6. 2026, a navazující týdenní schůzky). Původní zaměření Mapy státu bylo na **krizovou připravenost a závislosti digitální infrastruktury** (viz související dokument „Krizové řízení microsite“ a dashboard dopady.mapastatu.cz). Na schůzce 17. 7. 2026 Bohdan Urban explicitně přerámoval smysl projektu:

> *„Mě ta mapa státu jako vždycky evokovala spíš v uvozovkách nějaké statické siločáry na krizovou nebo faktickou připravenost, ale podle mě tohleto je digitální krevní oběh státu.“*

Tím otevřel nové, byznysově samostatné téma – měření **ekonomického a organizačního dopadu digitalizace** – které si zaslouží vlastní BRD a vlastní modul/aplikaci v rámci rodiny nástrojů Mapa státu.

### 2.2 Problém, který má dashboard řešit

- DIA i vláda ČR **nemají dnes systematický, metodicky podložený nástroj**, který by ukázal, kolik hodnoty digitalizace jednotlivých agend skutečně přináší (nebo nepřináší).
- Argumentace směrem k politickému vedení dnes probíhá **anekdoticky** („vyplatili jsme x dávek“, „čeká se na tolik žádostí“) bez tvrdých dat o skutečné době trvání, míře automatizace a dopadu na občana/úředníka.
- Investice do digitalizace formulářů je pro DIA **čistý cash-out** (Urbanova formulace) – přínos se neprojevuje v rozpočtu DIA, ale difuzně u občanů a firem. Bez nástroje, který tento přínos kvantifikuje, je obtížné investici obhájit a prioritizovat.
- Řada digitalizovaných formulářů je **digitalizovaná naslepo** – pouze „předvyplní jméno a příjmení“, aniž by reálně zkrátila proces – takové kroky nelze od skutečně přínosných odlišit bez měření.
- Chybí **motivační mechanismus** pro úřady a obce, které za digitalizací zaostávají – DIA má ale již ověřenou zkušenost, že **veřejné zveřejnění stavu** (zelená/červená mapa) funguje jako samoregulační motivace bez nutnosti individuálního tlaku.

### 2.3 Proč AFCEA a proč teď

AFCEA/tým Mapa státu má připravenou datovou a vizualizační platformu (RPP Explorer, mapastatu.cz, dopady.mapastatu.cz), designový systém pro dashboardy (`kgov-dashboard`) a přístup k otevřeným datům RPP. DIA má naopak autoritativní data (RPP, interní analýzy, data z Grémia eGovernmentu) a mandát věc řešit, ale dosud nemá hotový nástroj. Urban navrhl, že **DIA by měla být „příjemcem“ (vlastníkem) této služby** – AFCEA v roli dodavatele konceptu, prototypu a metodiky.

---

## 3. Cíle projektu

### 3.1 Cíle na úrovni byznysu

| Kód | Cíl | Měřítko úspěchu |
|---|---|---|
| G1 | Dát DIA a vládě nástroj pro **argumentaci hodnotou digitalizace** vůči politickému vedení (premiér, Grémium eGovernmentu) | Dashboard použit alespoň v 1 prezentaci na úrovni Grémia/vlády do konce roku 2026 |
| G2 | Umožnit DIA **prioritizovat** digitalizační investice podle reálného dopadu, nikoli jen podle politické naléhavosti | Alespoň 10 agend s dopočítaným indexem dopadu do konce Fáze 1 |
| G3 | Vytvořit **motivační tlak** na úřady/obce zaostávající v digitalizaci pomocí veřejné vizualizace | Měřitelný nárůst „zelených“ úřadů po zveřejnění (analogie k CAIS onboardingu, viz kap. 8.5) |
| G4 | Odlišit **skutečně přínosnou** digitalizaci od kosmetické („naslepo“ digitalizovaný formulář) | Metodika a klasifikace zavedena a aplikována na první sadu agend |
| G5 | Etablovat AFCEA/Mapa státu jako **dlouhodobého partnera DIA** pro datovou analytiku e-governmentu | DIA formálně přijme dashboard jako vlastní službu (Urbanův příslib) |

### 3.2 Vize (pracovní pojmenování konceptu)

Urban navrhl vlastní metaforu, kterou doporučujeme použít jako komunikační rámec celého produktu:

> **„Digitální krevní oběh státu“** – vizualizace toho, kde digitální proces plynule „proudí“ a kde naráží na papírový/manuální článek („zub“ v oběhu), který stojí čas a peníze. Cílem není strašit (jak už je zvykem u „mapy státu“ v krizovém pojetí), ale ukazovat **postupné vítězství**, ne dílčí neúspěch.

---

## 4. Zainteresované strany (Stakeholders)

| Role | Jméno / organizace | Zájem a vztah k projektu |
|---|---|---|
| Byznys sponzor / vlastník dat | **Bohdan Urban**, DIA | Formuloval zadání, definuje datové zdroje a metodiku DIA, rozhoduje o interní adopci na DIA |
| Interní expert DIA na měření digitalizace | Kolegyně Bohdana Urbana (jméno k doplnění) | Odpovědná za interní projekt „nástroj pro měření digitalizace“ na DIU/DIA – Urban ji přislíbil zapojit do dalšího jednání |
| Kontaktní osoba DIA pro prezentace/distribuci | **Lukáš** (DIA, příjmení k doplnění) | Domlouvá s Urbanem rozeslání prezentací, organizuje brainstorming na DIA |
| Zástupce DIU zmíněný v dřívějším jednání | **Tomáš Kroupa** | Zastupoval Urbana na „úterní platformě“ (setkání šéfů státních podniků) |
| Cílové publikum / konečný adresát | **Premiér, vláda ČR, Grémium eGovernmentu** | Adresát argumentace o hodnotě digitalizace; potřebuje jednoduché, tvrdými daty podložené metriky |
| Datový a doménový partner (legislativa, bezpečnost) | **Petr Kučera**, PowerPatterns | Podpora v interpretaci dat, bezpečnostní a legislativní aspekty, návrh měření automatizace přes dobu vyřízení |
| Koncept a komunikační rámování | **Martin Vlasta** | Navrhl rámec „dvou typů peněz“ (peníze občana vs. peníze/FTE státu) a vizuální přesvědčivost mapy |
| Koordinace a proces | **Jaroslav Pejčoch (jape)**, Tomáš Vejlupek | Organizace navazujících jednání, kulatých stolů, konference |
| Provozovatel/vlastník cílové služby | **DIA** (dle dohody Urban–Lukáš) | DIA by měla dashboard po dokončení konceptu převzít jako vlastní produkční službu |
| Sekundární uživatelé | Správci agend na jednotlivých úřadech, obce | Cílová skupina motivační veřejné mapy (modul E) |
| Veřejnost / novináři (nepřímo) | – | Případný sekundární konzument zjednodušené veřejné verze (k rozhodnutí v Fázi 2+) |

---

## 5. Rozsah (Scope)

### 5.1 V rozsahu (In-Scope) – Fáze 0–1

- Koncepční a datový model pro měření **dopadu digitalizace na úrovni jednotlivé služby/agendy** (modul B – jádro produktu).
- Napojení na **otevřená data RPP** (Registr práv a povinností) jako primární zdroj seznamu agend/služeb a jejich metadat.
- Prototyp kalkulačky dopadu s **manuálně zadanými/odhadnutými vstupy** (do doby, než budou k dispozici tvrdá UX/ČSÚ data).
- Vizualizace v rámci existující platformy **mapastatu.cz** / designového systému `kgov-dashboard`.
- Prezentovatelná pilotní verze pro schůzku s Bohdanem Urbanem (týden 24.–25. 7. 2026) a pro plánovaný cca 30min follow-up hovor koncem týdne 27.–31. 7. 2026.

### 5.2 V rozsahu – Fáze 2+ (podmíněno daty a rozhodnutím DIA)

- Modul A – nástroj pro měření **stupně digitalizace** agendy v celém životním cyklu (na základě metodiky, kterou DIA teprve vytváří).
- Modul C – **nástroj pro měření využití dat** / prediktivní kapacitní plánování (sběr → analýza → predikce).
- Modul E – **veřejná motivační mapa** (zelená/červená dle úřadu/obce), analogie k CAIS onboardingu.
- Napojení na tvrdá data z prezentace DIA pro Grémium eGovernmentu (počty úkonů, četnost podání dle S-služeb).
- Napojení na ČSÚ statistiky průměrných mezd dle sektoru pro přesnější přepočet ušetřeného času na peníze.

### 5.3 Mimo rozsah (Out-of-Scope) – explicitně odloženo

- **Modul D – technologicko-organizační monitoring digitální infrastruktury státu.** Urban toto téma sám označil za nedozrálé:
  > *„Tohle je fakt za mě ještě pořád složitý a neúplně uchopený… já tady nechci stavit žádný hvězdné války ve chvíli, kdy vozíme dříví na kolečku.“*
  Zahrnuto v tomto BRD pouze jako **budoucí vize** (kap. 9.4), nikoliv jako požadavek k realizaci.
- Nasazení automatizovaných „agentů“ (softwarových sond) do dílčích informačních systémů úřadů pro sběr dat – Urban zmínil, že DIA toto právně prověřuje jako možnou sdílenou službu, ale není to součástí zadání pro tento dashboard.
- Tvrzení o úsporách **na straně státu** (FTE, snížení počtu úředníků) – Urban explicitně varoval, že pro tento typ tvrzení **DIA nemá data** a dashboard by je neměl prezentovat jako fakt (viz kap. 11.3).
- Plnohodnotný veřejný portál pro širokou veřejnost / novináře – v této fázi cílíme na interní/poloveřejné publikum (Grémium, DIA, případně úřady).
- Legislativní a organizační změny (např. rušení „zralých ke zrušení“ agend) – dashboard pouze **identifikuje kandidáty**, rozhodnutí je mimo rozsah nástroje.

---

## 6. Uživatelské role a persony

| Persona | Popis | Co od dashboardu potřebuje |
|---|---|---|
| **Sponzor DIA** (Bohdan Urban a obdobné role) | Vedoucí pracovník DIA zodpovědný za digitalizaci a datovou strategii | Tvrdá, obhajitelná čísla pro jednání s vedením; možnost napojit vlastní data DIA; důvěryhodnou metodiku |
| **Analytik/správce agendy** | Úředník odpovědný za konkrétní agendu/formulář | Pohled na to, kde jeho agenda „ztrácí“ čas, argument pro prioritizaci vlastní digitalizace |
| **Politické vedení (premiér, vláda, Grémium eGovernmentu)** | Konečný adresát argumentace | Jednoduchý, srozumitelný souhrn (2 klíčová sdělení, viz kap. 11.4), ne technický detail |
| **Analytik AFCEA/Mapa státu** | Tým, který dashboard vyvíjí a spravuje metodiku | Datový model umožňující snadné doplňování nových agend a přepočet metodiky |
| **Úřad / obec** (u veřejné mapy, modul E) | Subjekt, jehož výkon je vizualizován | Motivaci zlepšit se vlastní aktivitou, bez nutnosti centrálního nátlaku |
| **Široká veřejnost** (nepřímo, budoucnost) | Občan, novinář | Srozumitelný příběh „kolik nám digitalizace šetří“ |

---

## 7. Přehled funkčních modulů

Dashboard je navržen jako **rozšiřitelná sada modulů**, odpovídající přesně třem (respektive čtyřem) okruhům, které Bohdan Urban na jednání sám rámcově vytyčil:

| Modul | Pracovní název | Urbanovo vlastní pojmenování | Fáze | Priorita |
|---|---|---|---|---|
| **A** | Zralost digitalizace agendy | „Nástroj pro měření digitalizace“ | 2 | Vysoká |
| **B** | Kalkulačka dopadu digitalizace | „Sledování impactu jednotlivých agend“ | 0–1 | **Nejvyšší (jádro)** |
| **C** | Analytika využití a kapacitní predikce | „Nástroj pro měření dat“ (sběr → analýza → predikce) | 2 | Střední |
| **D** | Monitoring infrastruktury (vize) | „Technologicko-organizační monitoring digitální infrastruktury státu“ | 3 (mimo rozsah) | Nízká / budoucí |
| **E** | Veřejná motivační mapa výkonu | Analogie k CAIS onboardingu / COVID mapě | 2 | Vysoká |

---

## 8. Detailní funkční požadavky

### 8.1 Modul A – Zralost digitalizace agendy

**Účel:** Ukázat, do jaké míry je konkrétní agenda/služba digitalizovaná v celém svém životním cyklu – ne jen binárně „ano/ne existuje elektronický formulář“.

| ID | Požadavek |
|---|---|
| FR-A-1 | Systém načte seznam agend/služeb z **RPP** (Registr práv a povinností) včetně metadat o zveřejněných formulářích (vstup/výstup). |
| FR-A-2 | Systém umožní evidovat **stav digitalizace** agendy dle metodiky, kterou navrhne DIA (Urban: „to bych nechal na vás jako návrh na vstupní datasety“) – minimálně rozlišení: nedigitalizováno / digitalizováno „naslepo“ (bez reálné úspory) / digitalizováno s reálným přínosem (např. předvyplnění na základě identifikace žadatele). |
| FR-A-3 | Systém umožní filtrovat a řadit agendy dle stupně digitalizace, počtu úkonů/rok a odhadovaného dopadu (návaznost na modul B). |
| FR-A-4 | Systém zohlední, že RPP dnes obsahuje **jen jednoduché údaje** (záznam publikování formuláře, vstup/výstup) – architektura musí počítat s postupným obohacováním o další datové sady od DIA. |
| FR-A-5 | Napojení na interní projekt DIA „nástroj pro měření digitalizace“ (jakmile bude specifikován kolegyní Bohdana Urbana) – rozhraní/import dat, ne duplicitní vývoj. |

### 8.2 Modul B – Kalkulačka dopadu digitalizace (jádro produktu)

**Účel:** Pro každou agendu/formulář vypočítat a vizualizovat **hodnotu digitalizace** v penězích a čase, s možností rozpadu na jednotlivé kroky procesu.

| ID | Požadavek |
|---|---|
| FR-B-1 | Systém rozloží proces vyřízení agendy na **elementární kroky digitalizace** (dle Urbanova a Jakubova návrhu): existence formuláře v digitální podobě → předvyplnění údajů na základě identifikace žadatele → elektronické odeslání efektivní cestou → zpracování na straně úřadu. Každý krok má vlastní potenciál úspory. |
| FR-B-2 | Pro každý krok/agendu systém počítá **vzorec dopadu**: `ušetřený čas na úkon (min)` × `hodinová mzda v relevantním sektoru (ČSÚ)` × `počet podání za rok` = **odhadovaná hodnota digitalizace za rok**. |
| FR-B-3 | Systém umožní zadat/importovat tři typy vstupních dat pro vzorec: (a) počet úkonů/podání v dané agendě za rok, (b) naměřenou nebo odhadnutou dobu trvání úkonu před a po digitalizaci (ideálně UX měřením), (c) průměrnou mzdu v relevantním sektoru dle ČSÚ. |
| FR-B-4 | Systém explicitně rozlišuje a **odděleně vizualizuje** dva typy přínosu (Urban/Vlasta rámec, viz kap. 11.4): **(1) peníze/čas vrácené občanovi** (odatovatelné) vs. **(2) potenciální úspora na straně státu/úředníků** (dnes bez tvrdých dat – nutno označit jako neověřené/nepodložené, nikoli prezentovat jako fakt). |
| FR-B-5 | Systém umí zobrazit **řetězenou (složenou) agendu** – workflow, kde na sebe navazuje více úřadů/kroků (princip „jeden krok občana vůči státu“, OPDESEL) – a v tomto řetězci vizuálně označit **„tlusté místo“**, tedy krok, kde digitální proces naráží na papírový/manuální mezikrok. |
| FR-B-6 | Systém umožní alternativní metriku dopadu nezávislou na explicitním měření času: **detekci míry automatizace podle rychlosti vyřízení** (Petr Kučera: vyřízení do 1 dne ≈ pravděpodobně automatizované; řádově týdny/měsíce ≈ manuální/blokované). |
| FR-B-7 | Systém umí spočítat a vizualizovat **sekundární ekonomické efekty** typu „dřívější zahájení = úspora z vyhnuté inflace“ na modelovém příkladu stavebního řízení (zkrácení z roku na měsíc) – jako ukázkovou šablonu metodiky, kterou lze aplikovat i na jiné agendy s časovou hodnotou peněz. |
| FR-B-8 | Všechny výstupy kalkulačky musí být **transparentně dohledatelné** – uživatel vidí, ze kterých vstupních čísel a jakým vzorcem byla hodnota dopočítána (žádná „černá skříňka“), a odhady bez tvrdých dat musí být vizuálně odlišeny (např. pilulka „odhad“ / „simulace“ dle existujícího designového standardu `kgov-dashboard`). |
| FR-B-9 | Modul obsahuje připravený **worked example** „ohláška porážky kůzlat mladších 72 měsíců“ jako referenční/ukázkový case-study (viz kap. 11.1) pro demonstraci metodiky Bohdanu Urbanovi a Grémiu. |

### 8.3 Modul C – Analytika využití a kapacitní predikce

**Účel:** Zmapovat využití digitální infrastruktury státu ve třech krocích, jak je definoval Urban: **sběr dat → analýza → prediktivní plánování kapacit**.

| ID | Požadavek |
|---|---|
| FR-C-1 | Krok 1 – Sběr: systém agreguje datové sady mapující, které procesy jsou digitalizované a jak jsou využívané (např. kolik se vyplatilo dávek a jak jsou dimenzované procesy pro jejich zpracování). |
| FR-C-2 | Krok 2 – Analýza: systém umožní analytický pohled na trendy využití napříč agendami/službami a časem. |
| FR-C-3 | Krok 3 – Predikce: systém (v pozdější fázi) umožní projekci budoucí zátěže na základě historických trendů a plánovaných událostí (např. volby → nárůst ověřování e-dokladů) – **explicitně jako budoucí rozšíření**, nikoli požadavek Fáze 0–1. |
| FR-C-4 | Modul musí být navržen tak, aby mohl čerpat z tvrdých dat, která Urban přislíbil poskytnout z prezentace pro Grémium eGovernmentu (počty úkonů dle S-služeb, četnost podání). |

### 8.4 Modul D – Monitoring infrastruktury (vize, mimo rozsah realizace)

Zahrnuto pouze pro úplnost a jako **připravenost architektury na budoucí rozšíření** – nerealizovat ve Fázi 0–2 bez explicitního zadání DIA.

| ID | Požadavek (vize) |
|---|---|
| FR-D-1 (vize) | Sledování technické kapacity vs. reálné/predikované zátěže digitálních služeb (příklad Martina Vlasty: dimenzování systému e-dokladů před volbami, který v minulosti spadl kvůli nepředvídané zátěži). |
| FR-D-2 (vize) | Propojení technického monitoringu s **organizačním doporučením** – ne jen „infrastruktura je na 80 % kapacity“, ale konkrétní doporučený krok (veřejná zakázka na navýšení / optimalizace / přesun dat / nasazení Kubernetes) s časovým rámcem proveditelnosti. |

### 8.5 Modul E – Veřejná motivační mapa výkonu

**Účel:** Využít psychologický efekt veřejného zveřejnění výkonu (analogie Y2K připravenost okresů, COVID dashboard, a zejména **ověřený precedent DIA** – onboarding obcí do systému CAIS) jako motivační nástroj bez nutnosti centrálního vymáhání.

| ID | Požadavek |
|---|---|
| FR-E-1 | Systém zobrazí mapu ČR s barevným kódováním (zelená/červená, případně škála) dle zvolené metriky výkonu (např. stupeň digitalizace agendy, rychlost vyřízení, aktivita úřadu/obce). |
| FR-E-2 | Granularita mapy musí být volitelná (kraj → ORP → obec), s vědomím kompromisu mezi přesností a čitelnostní vizualizace (Urban: „to už potom je na úkor té vizualizace“, když DIA šla až na úroveň nejmenších obcí u CAIS). |
| FR-E-3 | Referenční precedent k prostudování a případné inspiraci designu: portál DIA „Onboarding systému CAIS“, veřejně dostupný na `https://portal.dia.gov.cz/prostorova-data/mapa-caais/?layer=orp&tabv=layers&tab=layers&dataMode=caais` (zmíněno přímo Urbanem, ověřeno v poznámkách z jednání). |
| FR-E-4 | Mapa musí fungovat jako **automatická zpětná vazba** – zveřejnění samo o sobě má motivovat subjekty ke zlepšení bez nutnosti individuálního oslovování (dle zkušenosti DIA: po zveřejnění mapy CAIS se samovolně „donaklikalo“ cca 2000 z 6500 obcí, zbylo cca 400 obcí vyžadujících individuální péči). |
| FR-E-5 | Vizuální styl modulu musí být konzistentní s existujícím designovým systémem `kgov-dashboard` (tmavé téma, stylizovaná mapa ČR, KPI dlaždice) používaným napříč rodinou dashboardů Mapa státu / PS07 / AFCEA. |

---

## 9. Klíčový worked example (jádro pro demo Bohdanu Urbanovi)

### 9.1 Case study: „Ohláška porážky kůzlat mladších 72 měsíců“

Toto je **referenční příklad**, který Bohdan Urban sám použil k vysvětlení principu, a doporučujeme jej použít jako první naplněný use-case v modulu B (je nekontroverzní, konkrétní a srozumitelně demonstruje metodiku).

| Parametr | Hodnota (dle jednání, ilustrativní) |
|---|---|
| Počet podání ročně | ~8 000 |
| Stav bez digitalizace | Papírové podání, cca 7 800 z 8 000 nahrazeno |
| Digitalizace „naslepo“ (jen předvyplnění jména) | Úspora ≈ 0 (jen hlavičkový papír + způsob odeslání) |
| Digitalizace s reálným přínosem (předvyplnění na základě identifikace žadatele) | Úspora ≈ 10 minut/podání |
| Hodinová sazba (ilustrativní) | 500 Kč/hod |
| Úspora na jedno podání | ≈ 50 Kč |
| **Celkový roční potenciál** | **≈ 500 000 Kč** hodnoty vytvořené pro občany (Urbanův odhad „500 tisíc hrubého domácího produktu“) |

> ⚠️ **Metodická poznámka:** Čísla výše jsou přímo z živého ústního odhadu Bohdana Urbana („bivokov odhad“) a obsahují drobné zaokrouhlovací nesrovnalosti (přesný přepočet 10 min při 500 Kč/hod je ≈ 83 Kč, ne 50 Kč) – Urban i Jakub Bareš na jednání sami uznali, že jde o orientační odhad, ne přesný výpočet. **Kalkulačka v modulu B musí umožnit dosadit přesná čísla** a tento příklad používat jen jako didaktickou ilustraci principu, ne jako publikovatelné tvrzení.

### 9.2 Case study: Stavební řízení (sekundární efekt časové hodnoty peněz)

Ilustrace principu FR-B-7: zkrácení stavebního řízení z 1 roku na 1 měsíc umožní stavebníkovi zahájit stavbu o 11 měsíců dříve; při uvažované míře inflace (~2 % ročně) se stavebník vyhne části znehodnocení svého rozpočtu inflací → Urban odhaduje úsporu řádově ~1,8 % nákladů stavby. I zde platí stejná výhrada – jde o Urbanovu vlastní „green table úvahu“, kterou je třeba před publikací přepočítat a ověřit.

### 9.3 Obecná metodika (shrnutí)

```
Hodnota digitalizace agendy/rok =
    Σ (kroky procesu)
        [ušetřený čas na úkon (v hodinách)]
      × [průměrná hodinová mzda v relevantním sektoru – zdroj ČSÚ]
      × [počet úkonů/podání za rok – zdroj RPP / interní data DIA]
```

Doplňkové dimenze k zohlednění:
- **Řetězení agend** – pokud proces prochází více úřady/kroky, sčítat dopad napříč celým řetězcem a vizuálně zvýraznit nejslabší (nejpomalejší/nejméně digitalizovaný) článek.
- **Sekundární efekty** – časová hodnota peněz, vyhnuté náklady z prodlení (viz stavební řízení).
- **Kandidát na zrušení agendy** – pokud analýza ukáže, že podání „leží“ bez reálného zpracování (Urbanův příklad: hlášení jde do spisovny a čeká na skartaci), dashboard by měl takové agendy označit jako kandidáty k revizi/zrušení (bez rozhodovací pravomoci – jen upozornění).

---

## 10. Datové požadavky a zdroje

| Zdroj dat | Vlastník | Obsah | Dostupnost k datu BRD | Poznámka |
|---|---|---|---|---|
| **RPP** (Registr práv a povinností) | DIA / MV | Seznam agend a služeb, metadata o zveřejněných formulářích (vstup/výstup) | Otevřená data, dnes využívaná v RPP Exploreru | Urban: „my máme nějaké jednoduché údaje v RPP… ten formulář je v podstatě jenom vstup a výstup“ |
| **Tvrdá data z prezentace pro Grémium eGovernmentu** | DIA (Bohdan Urban) | Počty úkonů v dané agendě/S-službě, četnost podání | **Přislíbeno** Urbanem k předání | Klíčový vstup pro naplnění modulu B reálnými čísly namísto odhadů |
| **Interní projekt DIA „nástroj pro měření digitalizace“** | DIA (kolegyně Bohdana Urbana) | Metodika a data o stupni digitalizace agend | V přípravě na DIA, Urban přislíbil zapojit kolegyni do dalšího jednání | Vstup pro modul A |
| **ČSÚ – průměrné mzdy dle sektoru** | Český statistický úřad | Referenční hodinové/měsíční mzdy pro přepočet ušetřeného času na peníze | Veřejně dostupné | Nutné párovat s klasifikací sektoru dané agendy |
| **UX měření doby vyplnění/vyřízení** | K vybudování (AFCEA/DIA) | Reálně naměřená doba trvání úkonu před/po digitalizaci | **Neexistuje** – identifikováno jako mezera (Urban: „nikdy jsme nezkusili podniknout elementární krok, který by skutečně na základě UX-a změřil…“) | Doporučeno jako součást Fáze 1–2: minimální UX studie na pilotní sadě agend |
| **Data o době vyřízení dle elektronických výstupů** | Jednotlivé úřady / DIA | Doba mezi podáním a vydáním výstupu u služeb s elektronickým výstupem | Částečně dostupné (Petr Kučera: „diáta tam má z techlogů“) | Použitelné jako proxy metrika automatizace (FR-B-6) |
| **Případná data ze softwarových sond v informačních systémech úřadů** | DIA (v právním prověřování) | Přímé měření vstup/výstup digitalizace v dílčích IS | Není k dispozici, DIA teprve prověřuje jako sdílenou službu | Mimo rozsah Fáze 0–1, sledovat jako budoucí zdroj |
| **Designový systém `kgov-dashboard`** | AFCEA/Mapa státu (interní skill) | Vizuální komponenty, styl, mapa ČR | K dispozici | Použít pro konzistentní vzhled napříč rodinou dashboardů |

---

## 11. Metodika a principy měření dopadu

### 11.1 Referenční case study
Viz kap. 9.1 – „ohláška porážky kůzlat“ jako standardní demonstrační příklad.

### 11.2 Rozlišení „digitalizace naslepo“ vs. „digitalizace s přínosem“
Urban explicitně upozornil, že mnoho digitalizace probíhá bez reálného přínosu – formulář se jen přesune do PDF/online formy, ale nešetří žádný čas, protože stále vyžaduje ruční vyplnění všech údajů. **Dashboard musí umět tento rozdíl ukázat**, jinak riskuje zavádějící prezentaci „digitalizováno = přínosné“.

### 11.3 Zásada opatrnosti u tvrzení o úsporách na straně státu
Toto je **jedna z nejdůležitějších podmínek** vznesených přímo Urbanem a musí být závazně zapracována do produktu:

> *„Tam by bylo opatrné, protože pro ten statement číslo dvě [úspora na straně státu/úředníků] data mít nebudeme, ale pro ten statement číslo jedna [peníze vrácené občanovi], ten jsme schopni opravdu odatovat.“*

**Požadavek na produkt:** Jakékoli tvrzení o úspoře FTE/nákladů na straně státu musí být v UI jasně odlišeno jako **nepodložený odhad / hypotéza**, nikdy prezentováno se stejnou váhou jako odatovaná čísla o přínosu pro občany.

### 11.4 Dvojí komunikační rámec (Martin Vlasta)
Pro finální prezentaci politickému vedení doporučen rámec dvou oddělených sdělení:
1. *„Tolik peněz/času jsme vám (občanům) vrátili, protože už to nemusíte dělat postaru.“* – **odatovatelné, prioritní sdělení**.
2. *„Tolik jsme ušetřili na straně státu (méně úředníků / kratší lhůty)“* – **zatím bez dat, prezentovat jen jako budoucí ambici, ne fakt** (viz 11.3).

### 11.5 Princip řetězené agendy / OPDESEL
Kde na sebe navazuje více úřadů/kroků, měl by občan dle principu OPDESEL učinit **jediný krok vůči státu** a dostat zpět vyřízenou složenou agendu. Dashboard by měl u řetězených agend vždy vizualizovat celý řetězec a zvýraznit nejslabší článek – to je přesně bod, kde je ekonomický dopad měření nejvyšší (Urban: „pak už je tam konkrétní impact… a tím se dostávám ke koncovce… tady už potom dopočítáváme těch úspor v řádu milionů a možná ve svém výsledku stovek milionů“).

---

## 12. Nefunkční požadavky

| ID | Kategorie | Požadavek |
|---|---|---|
| NFR-1 | Transparentnost metodiky | Každé zobrazené číslo musí být dohledatelné k výchozím datům a vzorci (žádná „černá skříňka“) – zásadní pro důvěryhodnost vůči politickému vedení. |
| NFR-2 | Vizuální konzistence | Dashboard musí využívat existující designový systém `kgov-dashboard` (tmavé téma, styl karet, SVG mapa ČR, KPI dlaždice) pro konzistenci napříč rodinou nástrojů Mapa státu. |
| NFR-3 | Odlišení odhadu od tvrdých dat | Čísla bez ověřených tvrdých dat musí být vizuálně označena (pilulka „odhad“/„simulace“) – navazuje na existující standard z projektu dopady.mapastatu.cz. |
| NFR-4 | Bezpečnost a ochrana dat | Žádná osobní data občanů nesmí být v dashboardu agregována na úrovni umožňující identifikaci jednotlivce; data o úřadech/obcích musí respektovat případná omezení DIA na sdílení interních dat. |
| NFR-5 | Dostupnost (accessibility) | Vzhledem k potenciálnímu poloveřejnému/veřejnému charakteru (modul E) dodržet základní principy přístupnosti (kontrast, popisky, možnost čtení bez barvy jako jediného nositele informace – důležité u zelená/červená mapy). |
| NFR-6 | Výkon a škálovatelnost | Modul A/C musí zvládnout objem dat RPP (stovky až tisíce agend/služeb) bez degradace výkonu vizualizace. |
| NFR-7 | Auditovatelnost | Historie změn metodiky a vstupních dat musí být sledovatelná (verze metodiky, datum poslední aktualizace zdrojových dat). |
| NFR-8 | Nasaditelnost | Konzistentní s existující infrastrukturou Mapa státu (AWS S3 + CloudFront, doména `*.mapastatu.cz`) – viz kap. 13. |
| NFR-9 | Jazyk | Veškerý obsah a UI v češtině, srozumitelné i pro publikum mimo IT (politické vedení, úředníci) – bez zbytečného technického žargonu. |

---

## 13. Vztah k existující architektuře Mapa státu

Tento dashboard **není samostatný produkt od nuly**, ale nový modul v rodině nástrojů kolem projektu Mapa státu:

- **mapastatu.cz** – hlavní platforma; e-government dashboard by měl být přístupný jako navazující sekce/subdoména (analogicky k `dopady.mapastatu.cz` a plánované `simulace.mapastatu.cz`).
- **`dopady.mapastatu.cz`** – existující dashboard závislostí a dopadů krizové infrastruktury (mapa ČR ↔ graf návazností). Tematicky příbuzný, ale odlišný účel (krizová odolnost vs. ekonomický dopad digitalizace) – doporučeno **nesměšovat obsah**, ale sdílet vizuální jazyk.
- **Designový skill `kgov-dashboard`** (`~/claude-playground/.claude/skills/kgov-dashboard/`) – závazný designový systém pro všechny dashboardy rodiny PS07/AFCEA/Mapa státu; nový dashboard jej musí použít, aby zůstala vizuální konzistence napříč portfoliem.
- **RPP Explorer** – zdroj dat a existující zkušenost s prací s daty RPP; datová vrstva modulu A/B by měla znovupoužít již existující ETL/parsing logiku, ne ji duplikovat.
- **Krizové řízení microsite** – sesterský projekt, ne přímá závislost.

---

## 14. Fázování a harmonogram

Harmonogram je odvozen přímo z dohodnutých dalších kroků na jednání 17. 7. 2026.

| Fáze | Obsah | Termín | Odpovědnost |
|---|---|---|---|
| **Fáze 0 – Pilotní verze** | Prototyp modulu B (kalkulačka dopadu) s worked example „kůzlata“, napojený na dostupná RPP data, prezentovatelný jako demo | **do pátku 24. 7. 2026** (příslib Jakuba Bareše na jednání) | AFCEA (Jakub Bareš) |
| **Fáze 0.5 – Předání tvrdých dat** | Bohdan Urban předá prezentaci/tvrdá data z Grémia eGovernmentu (počty úkonů dle S-služeb, četnost) | Průběžně, ihned po jednání | Bohdan Urban / DIA |
| **Fáze 0.5 – Follow-up hovor** | ~30min videokonference k ověření pokroku na nápadech z jednání 17. 7. | Konec týdne 27.–31. 7. 2026 | Bohdan Urban iniciuje |
| **Fáze 1 – Zpřesnění metodiky a rozšíření dat** | Zapojení kolegyně DIA (nástroj pro měření digitalizace), doplnění ČSÚ dat, rozšíření na více agend | Srpen 2026 (návaznost na plánovaný interní brainstorming DIA a AFCEA workshop v srpnu, viz „Battle Plan“) | AFCEA + DIA společně |
| **Fáze 1.5 – Interní brainstorming DIA** | Urban zorganizuje obdobný brainstorming pro klíčové lidi DIA (analogicky k brainstormingu s Lukášem, Adamem a šéfy státních podniků), aby DIA jako budoucí vlastník služby definovala vlastní potřeby | Srpen 2026 | Bohdan Urban / DIA |
| **Fáze 2 – Rozšíření o moduly A, C, E** | Zralost digitalizace (A), analytika využití/kapacit (C), veřejná motivační mapa (E) | Podzim 2026 (orientačně) | AFCEA + DIA |
| **Fáze 2.5 – Prezentace politickému vedení** | Nasazení jako argumentační nástroj pro Grémium eGovernmentu / vládu | Podzim/zima 2026 (vazba na cíl G1) | DIA (jako vlastník služby), AFCEA jako podpora |
| **Fáze 3 – Vize monitoringu infrastruktury (modul D)** | Mimo rozsah tohoto BRD – k otevření až po vyjasnění DIA | Nespecifikováno, samotný Urban téma označil jako nedozrálé | DIA |

> Poznámka: Harmonogram Fáze 1–3 je orientační a odvozený z tónu jednání, nikoliv z formálně odsouhlaseného projektového plánu – doporučeno potvrdit s DIA při follow-up hovoru koncem července.

---

## 15. Rizika a jejich mitigace

| ID | Riziko | Dopad | Pravděpodobnost | Mitigace |
|---|---|---|---|---|
| R1 | Chybí tvrdá UX data o době trvání úkonů před/po digitalizaci – kalkulačka staví na odhadech | Ztráta důvěryhodnosti u politického vedení | Vysoká (dnes fakticky neexistují) | Jasné vizuální odlišení odhadu od tvrdých dat (NFR-3); v Fázi 1 iniciovat minimální UX studii na pilotní sadě agend |
| R2 | Přeceňování/nesprávná interpretace odhadů typu „500 tis. Kč“ jako přesných čísel při prezentaci navenek | Reputační riziko pro DIA i AFCEA | Střední | Metodická poznámka a „disclaimer“ přímo v UI kalkulačky; interní review před jakoukoli externí prezentací |
| R3 | Tvrzení o úsporách na straně státu (FTE) bez datové opory | Politicky citlivé, může být napadeno | Vysoká, pokud nebude dodrženo NFR/11.3 | Striktně nezahrnovat do „tvrdých“ výstupů; označit jako neověřenou hypotézu (viz kap. 11.3) |
| R4 | RPP data mají nekonzistence a nízké pokrytí (dle zkušenosti z projektu RPP Explorer, viz [[petr-kucera-rpp-reviewer]]) | Nepřesné vstupy do kalkulačky dopadu | Vysoká (známá z předchozích projektů) | Znovupoužít existující validační/QA procesy z RPP Exploreru |
| R5 | DIA nezíská interní kapacitu/mandát na dodání dat (Grémium, kolegyně) v plánovaném čase | Zpoždění Fáze 1 | Střední | Follow-up hovor koncem července jako kontrolní bod; eskalace přes Bohdana Urbana |
| R6 | Právní/bezpečnostní omezení na sdílení interních dat DIA (např. nasazení „agentů“ do IS úřadů) | Blokace modulu C v plné podobě | Střední | Modul C navržen tak, aby fungoval i s částečnými/agregovanými daty; agenti v IS explicitně mimo rozsah |
| R7 | Veřejná motivační mapa (modul E) může být vnímána jako „shaming“ úřadů/obcí místo motivace | Politický odpor, negativní PR | Nízká–střední (DIA má pozitivní precedent u CAIS) | Komunikační rámec „postupné vítězství“, ne „dílčí neúspěch“ (viz kap. 3.2); inspirace přesně precedentem CAIS |
| R8 | Duplicita s jiným interním nástrojem DIA („nástroj pro měření digitalizace“) | Plýtvání zdroji, konflikt vlastnictví | Střední | Aktivně koordinovat s kolegyní Bohdana Urbana od Fáze 1, ne stavět paralelní řešení |

---

## 16. Předpoklady a závislosti

**Předpoklady:**
- DIA bude ochotná a schopná dodat přislíbená tvrdá data (Grémium eGovernmentu) v řádu týdnů.
- DIA formálně potvrdí zájem stát se dlouhodobým vlastníkem/provozovatelem služby (dle ústního příslibu Urbana).
- Designový systém `kgov-dashboard` zůstává platným standardem pro nové dashboardy v portfoliu Mapa státu.
- RPP zůstává dostupné jako otevřená data v současné podobě a rozsahu.

**Závislosti:**
- Fáze 1 je závislá na zapojení interního experta DIA (kolegyně Urbana) a jejího projektu měření digitalizace.
- Modul E (veřejná mapa) je závislý na rozhodnutí DIA o míře granularity a politické citlivosti zveřejnění výkonu jednotlivých úřadů/obcí.
- Modul C ve své plné podobě (predikce) je závislý na objemu historických dat, která dnes DIA/stát nemusí mít k dispozici v potřebné kvalitě.
- Nasazení a hosting navazuje na existující infrastrukturu Mapa státu (AWS S3 + CloudFront, správa DNS) – viz [[mapastatu-cz-deployment]].

---

## 17. Otevřené otázky k dořešení s DIA

1. Jaká přesná metodika stupně digitalizace (modul A) bude použita – převezme se metodika z interního projektu kolegyně Bohdana Urbana, nebo se navrhne společně?
2. Jaký je reálný harmonogram a rozsah dat, která DIA může sdílet z prezentace pro Grémium eGovernmentu (jen agregáty, nebo i data na úrovni jednotlivé S-služby)?
3. Do jaké míry je politicky přijatelné zveřejnit výkonovou mapu úřadů/obcí (modul E) mimo interní použití DIA?
4. Jaký je stav právního prověření nasazení „agentů“ do dílčích informačních systémů úřadů (zmíněno Urbanem jako potenciální budoucí zdroj dat)?
5. Kdo konkrétně (jméno, role) bude ze strany DIA formálním product ownerem po předání služby (Urban zmínil, že „DIA by měla být příjemcem“, ale konkrétní osoba/tým nebyl na jednání určen)?
6. Má DIA již k dispozici nebo v přípravě UX měření doby vyplnění formulářů, nebo je to mezera, kterou by měl vyplnit tento projekt?
7. Jaký je vztah tohoto dashboardu k plánované srpnové interní pracovní schůzce DIA (brainstorming pro klíčové lidi DIA) – má dashboard sloužit jako podklad pro tuto schůzku?

---

## 18. Glosář pojmů

| Pojem | Vysvětlení |
|---|---|
| **DIA** | Digitální a informační agentura – ústřední správní úřad ČR pro digitalizaci veřejné správy |
| **RPP** | Registr práv a povinností – centrální registr agend, služeb a formulářů veřejné správy |
| **S-služba** | Interní klasifikace služeb používaná DIA (referenční pro data o četnosti podání) |
| **Grémium eGovernmentu** | Koordinační platforma na úrovni vedení státu pro digitalizaci veřejné správy |
| **OPDESEL** | Princip „jednou a dost“ – občan poskytuje údaj státu jen jednou, stát si jej dále sdílí interně |
| **DIU** | Odbor/útvar hlavního architekta / digitalizace v rámci relevantní instituce (zmíněno v kontextu prezentace) |
| **CAIS** | Centrální adresní informační systém – příklad úspěšné motivační veřejné mapy DIA (onboarding obcí) |
| **„Digitální krevní oběh státu“** | Urbanova metafora – koncept vizualizace míst, kde digitální proces naráží na papírový/manuální krok |
| **„Tlusté místo“** | Pracovní označení pro úsek řetězené agendy, kde vzniká největší časová/nákladová ztráta |
| **Cash-out / cash-in** | Rozlišení, zda investice do digitalizace znamená pro danou instituci čistý náklad (DIA) nebo přínos (společnost/stát jako celek) |

---

## 19. Přílohy

### Příloha A – Přímé citace Bohdana Urbana (zdroj: přepis jednání 17. 7. 2026)

> „My v této chvíli nemáme vůbec žádný elementární nástroj pro sledování impactu jednotlivých agentů [agend].“

> „Pro DIA je to čistokrevný cash-out, který se nám nikdy nevrátí. Ale pro stát jako celek to může být cash-in.“

> „Bohužel tuto logiku impactu digitalizace do fungování veřejné správy nikdo nijak strukturovaněji a metodicky popsaně nesleduje.“

> „Mě ta mapa státu jako vždycky evokovala spíš statické siločáry na krizovou připravenost, ale podle mě tohle je digitální krevní oběh státu.“

> „Zveřejnění té vizualizace zvýšilo aktivitu těch obcí… natekly obce v počtu zhruba 2000, zůstává posledních 400, které budou vyžadovat individuální péči.“

### Příloha B – Referenční precedent DIA

Onboarding systému CAIS (mapa aktivity obcí ve zprávě voleb):
`https://portal.dia.gov.cz/prostorova-data/mapa-caais/?layer=orp&tabv=layers&tab=layers&dataMode=caais`

### Příloha C – Účastníci jednání 17. 7. 2026 („24. schůzka – Mapa státu další kroky“)

Tomáš Vejlupek, Jakub Bareš, Petr Kučera (PowerPatterns), Martin Vlasta, Jaroslav Pejčoch (jape), Bohdan Urban (DIA) a další účastníci pracovní skupiny PS07 kGovernment (AFCEA).

### Příloha D – Návaznost na osobní pracovní poznámky

Viz `Mapa statu - Battle plan.txt` (kořenový adresář kGovernment team) – autorovy pracovní poznámky z téhož jednání, obsahově potvrzují a doplňují tento BRD.

---

*Konec dokumentu. Verze 0.1 – k připomínkování týmem AFCEA a k validaci s Bohdanem Urbanem (DIA) na navazujícím jednání.*