Když vláda hledala, proč selhala digitalizace stavebního řízení.
Po neúspěšném startu 1. 7. 2024 jmenoval ministr expertní tým (který tvoří jádro Simbitu). Za pět měsíců dodal tento tým základní business zadání, které tři roky chybělo — 50+ procesů, přes 200 základních high-level business požadavků, komplexní procesní mapy a mapu stavebního řádu.
- KLIENT
- MMR ČR · MPSV (horizontální spolupráce)
- OBDOBÍ
- září 2024 — březen 2025
- FÁZE
- Zachraňujeme · Discovery + Design
- SEGMENT
- Státní správa
Politické zadání, ne tendr.
K 1. červenci 2024 mělo Česko spustit digitalizaci stavebního řízení — jeden z nejviditelnějších IT projektů státu, výsledek tří let práce. Spuštění selhalo.
V polovině září 2024 jmenoval ministr expertní tým s úkolem zjistit, proč nasazení selhalo, a dodat ucelené business zadání. Celou tuto Discovery fázi realizoval tým Simbitu ve 2 etapách — základní analýza selhání pro vládu, zadání a hrubý návrh řešení pro detailní analýzu a funkční design.
Co Discovery pokrylo a co ne.
- · Posouzení příčin selhání spuštění z 1. 7. 2024
- · Business zadání pro budoucí systém DSŘ
- · Konceptuální schéma agendy stavebního řádu
- · Procesní schéma stavebního řádu (~50 procesů, BPMN 2.0 zjednodušená)
- · Procesní standardy, standardy klientského přístupu, standardy obsluhy
- · Územní plánování (NGÚP) — pouze nezbytná vazba
- · Detailní reflexe stávajících systémů Portál stavebníka a ISSŘ — jen jako zdroj poučení
- · Technické řešení bypassu MMR/MPSV — druhý pilíř smlouvy
- · Prototyp / funkční MVP — tehdy nebyl požadavek (viz „Co bychom udělali jinak")
Rozhovory, právní analýza, procesní mapování — paralelně.
Tři vrstvy poznání paralelně. Rozhovory s aktéry: MMR (odbory legislativy a stavebního řádu), stavební úřady obecní úrovně i ORP (Praha 2, Praha 6, Praha 10, Rudná u Prahy), HZS, Dopravní a energetický stavební úřad, správci TDI, ČÚZK, NAKIT, vybraní developeři. Právní analýza — zákony č. 283/2021 Sb., č. 500/2004 Sb. a č. 284/2021 Sb. včetně prováděcích vyhlášek. Procesní mapování v MIRO (high-level) a Sparx Enterprise Architect (detail), notace BPMN 2.0 záměrně zjednodušená.
Rozsah mapy: 50+ hlavních procesů stavebního řízení (povolovací, kolaudace, opravné prostředky, kontrola, mimořádné postupy), ~25 dotčených orgánů v kompletním výčtu, 5 hlavních kategorií business požadavků, 5 sdílených business komponent.
Tři nálezy, které vysvětlují, proč to selhalo.
Tři roky práce, žádný rozhovor s úředníkem.
Stav. U klíčové cílové skupiny úředníků, kteří mají systém denně používat, nebyl proveden ani jeden strukturovaný sběr potřeb. Žádné stínování, žádné průběžné ověřování, žádný prototyp (k „osaháni“).
Následek. Systém po nasazení nepokrýval ani základní scénáře, které úředníci běžně realizují. Velká část problémů pramenila z nepokrytých základních uživatelských potřeb a očekávání.
Kontext. V projektu za vyšší desítky milionů korun, který má digitalizovat agendu s 50+ hlavními procesy, je absence uživatelského ověření strukturálně nepřijatelná — ne dílčí chyba, ale fundamentální mezera.
Chybějící business analýza a architektura — implementace běžela bez mapy.
Stav. Pouze implementační a technické podklady. Business analýzu a architekturu suplovala technická specifikace bez popisu E2E procesů.
Následek. Nebylo možné vůbec ověřit, jestli je aplikace z uživatelského pohledu funkční nebo co vůbec znamená funkční aplikace, jak se k ní dostat a jak ji testovat. Rozdrobená sada nástrojů (Portál stavebníka × ISSŘ × NGÚP × aplikace pro spisovou službu), kde každá část dělala nějaký kus agendy, ale dohromady to nefungovalo správně.
Kontext. Drtivá většina povinných artefaktů — use-cases, manuály, deployment, integrace — byla hodnocena jako nedostatečná nebo v době nasazení vůbec neexistovala.
Vendor lock-in zakrytý 250 000 řádky proprietárního frameworku.
Stav. Aplikace ISSŘ byla postavena nad proprietární knihovnou dodavatele (nad standardními frameworky), bez dokumentace, s nejasným využitím, bez testů.
Následek. Diskontinuita dodavatele by způsobila prakticky neudržitelnou aplikaci (vyšší desítky milionů v bodyshop kontraktech). Cena za migraci k jinému dodavateli byla nevyčíslená, přestože bylo deklarováno, že „to může dodělat kdokoliv“.
Kontext. Standardně na vývoji aplikace pracovaly jednotky vývojářů — naprosto neadekvátní vzhledem k rozsahu agendy (50+ procesů, 200+ požadavků, 25+ aktérů).
Čtyři klíčová doporučení a tři varianty realizace.
Jedna obslužná aplikace — Portál stavební správy
Sjednotit Portál stavebníka + ISSŘ pod jedno UI, modulární architektura, principy „one-time data“ a end-to-end digitalizace. Rozhodnutí má být politické, ne dodavatelské.
„Legalizace“ poradenství stavebního úřadu
Poradenství má být explicitně zakotvenou procesní fází s odměňovaným výkonem, ne šedou zónou. Bez něj vznikají nejasnosti a prodlevy — a celá digitalizace ztrácí smysl.
Hloubková integrace s VS — DTM, RÚIAN, RPP, evidence obyvatel
Včetně systémů technické a dopravní infrastruktury, dotčených orgánů (HZS, JES, kultura). „Z hlediska reálné digitalizace se napříč zájmovými skupinami shodně objevuje potřeba eliminace duplicit.“ (konsenzus z rozhovorů)
Tři varianty k politickému rozhodnutí
- A — Status quo+ (rychlé, levné, neřeší kořeny).
- B — Postupná modernizace s pilotem (řiditelné riziko, 18–24 měsíců).
- C — Greenfield (36+ měsíců, čistý štít). *
* Doporučovaná: stávající řešení nebylo opravitelné v rozsahu poptávaných funkčností a udržitelného rozvoje.
„Z hlediska reálné digitalizace se napříč jednotlivými zájmovými skupinami shodně objevuje potřeba eliminace duplicit, snížení administrativní zátěže a větší míra integrace mezi jejich informačními systémy.“
Discovery dodalo, politika rozhodla odložit.
K 15. březnu 2025 byla doručena verze 1.0 business zadání spolu s konceptuálním a procesním schématem. 6 hlavních doporučení, 8 funkčních zásahů, 3 varianty způsobu realizace připravené k politickému rozhodnutí.
Realizace byla odsunuta kvůli konci volebního období na novou vládu — ta se k tématu vrátila a aktuálně rozhoduje (novela zákona, vytvoření centrálního stavebního úřadu — v souladu s doporučeními, organizace).
Ne všechno je k zahození.
Tato sekce je pro nás povinná — chrání před politickou interpretací reportu jako odsudek celého projektu nebo jeho aktérů. V případě DSŘ stojí za zachování:
- Spisová služba — funkční, vhodná pro budoucí integraci, ne k nahrazení.
- Seznam požadavků dodaných správci infrastruktury — požadavky byly sebrány, resp. dodány, ale nebyly reflektovány. Jsou detailní a lze je využít.
- Uživatelé chtějí spolupracovat — i přes veškeré změny chtěli dotčení uživatelé (a to z různých fází celého procesu) spolupracovat na zadání, jen se s nimi spolupracovalo málo. Jejich zájem, entuziasmus a konkrétní návrhy byly a jsou zásadní součástí budoucího detailního zadání.
Reflexe vlastního přístupu.
V roce 2024 jsme dělali Discovery a Design — prototyp tehdy nebyl součástí zadání. Kdybychom začínali znovu, udělali bychom dvě věci jinak.
Postavili bychom prototyp. Ne jako důkaz toho, že umíme programovat, ale jako artefakt, který každému přispěvateli umožní vidět, jak se jeho připomínka zhmotní. Zadání na papíře přečte málokdo, klikatelný prototyp pochopí za pět minut.
Stínovali bychom víc. V daném časovém rámci jsme volili rozhovory namísto přímého pozorování. Dnes víme, že stínování ukáže, co rozhovor zatají: workaroundy, rytmus dne, drobné rozhodovací body. Příští DSŘ by začal 2 týdny v terénu, ne v zasedačce. V terénu jsme byli ale nepravidelně a málo.
Máte podobně rozjetý projekt?
Discovery, Design, prototyp nebo převzetí.
Začneme tím, co skutečně potřebujete — ne tím, co bychom vám mohli prodat.