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). Do března 2025 dodal tento tým základní business zadání, které tři roky chybělo - 50+ procesů, přes 200 základních business požadavků, procesní mapy a mapu stavebního řádu.
- KLIENT
- MMR ČR · MPSV (horizontální spolupráce)
- OBDOBÍ
- září 2024 - březen 2025
- FÁZE
- Posouzení projektu · 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 vývoje bez zadání ověřeného u lidí, kteří systém používají.
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ání“).
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 podkladů - případy užití, manuály, nasazení, integrace - byla hodnocena jako nedostatečná nebo v době nasazení vůbec neexistovala.
Závislost na jednom dodavateli: 250 000 řádků vlastní knihovny bez dokumentace.
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. Změna dodavatele by z aplikace udělala prakticky neudržitelný systém (vyšší desítky milionů v kontraktech na pronájem vývojářů). Cena za migraci k jinému dodavateli byla nevyčíslená, přestože bylo deklarováno, že „to může dodělat kdokoliv“.
Kontext. Na vývoji standardně pracovaly jednotky vývojářů. To neodpovídalo rozsahu agendy (50+ procesů, 200+ požadavků, 25+ typů dotčených orgánů).
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 - Nové řešení na zelené louce (36+ měsíců). *
* 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.“
Zadání jsme předali. O realizaci rozhoduje nová vláda.
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 na podzim 2026 rozhoduje o dalším postupu, mimo jiné o novele zákona a vytvoření centrálního stavebního úřadu, v souladu s doporučeními.
Ne všechno je k zahození.
Tato sekce je pro nás povinná - chrání před politickým výkladem zprávy jako odsudku 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, ale v řešení se neodrazily. 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?
Nezávislé posouzení, zadání, prototyp nebo převzetí řízení.
Začneme tím, co skutečně potřebujete - ne tím, co bychom vám mohli prodat.