Poradna: Jaká poučení si máme jako správci informačního systému vzít z rozsudků a ÚOHS k digitálnímu stavebnímu řízení

Do poradny nám z jednoho úřadu, který si důrazně nepřál být jmenován, dorazil zajímavý dotaz s odkazem na článek udávající pár závěrů z rozsudku týkajícího se sporu ÚOHS a MMR ke spackané zakázce na dodávku informačních systémů k digitalizaci stavebních řízení.

Článek najdete zde: Podrobnosti z rozsudku Krajského soudu v Brně ve věci „Zajištění digitalizace stavebního řízení“ - ITBiz.cz

Tazatel se ptá na to, co má on jako velký úřad řešící dodávky informačních systémů udělat pro to, aby se mu nestalo to samé, jako se stalo Ministerstvu pro místní rozvoj?

První a hlavní odpovědí je, aby úřad dodržoval zákony a povinnosti k eGovernmentu. MMR u této zakázky porušilo a pokazilo co mohlo. Nebudeme se zabývat vůbec věcnou stránkou, pouze připomenem povinnosti plynoucí ze zákona 365/2000 Sb. (zákon o ISVS) a nové vyhlášky 360/2023 Sb. (vyhláška o dlouhodobém řízení). Kdyby se totiž MMR jako Správce ISVS řídilo těmito předpisy, vůbec by k něčemu takovému nedošlo.

Nicméně tazatel se ptal na konkrétní rozhodnutí ÚOHS a soudu a na to, co z toho plyne jako poučení pro ostatní. Nechceme zbytečně opisovat zdůvodnění soudu ani článek na ITbizu, doporučujeme si jej před dalším textem přečíst.

1. poučení: Dobře si rozmyslete, co chcete dodat a podle čeho. Není to poprvé, co se ve sporech kolem DSČ zmiňuje, že MMR jednalo zmatečně, nepředvídatelně a chaoticky. To má pochopitelně celkem jasnou příčinu a tou je chybějící věcné zadání. Na MMR teprve za běhu zjišťovali, co to vlastně má umět a především, jak to má umět. S takovým zadáním z kávové sedliny se pak něco dost špatně definuje jako požadavek do dodávky. . Základem je dobrý věcný záměr, dobrá analýza, studie proveditelnosti a hlavně dobře zpracované požadavky. A pokud to poslední nejde, tak alespoň dobrý proces jejich posouzení a sledování realizace. - Shodou okolností dotaz přišel v době, kdy (asi také díky fiasku MMR) dost úřadů volá po podrobnějších metodikách, jak to dělat. I my jsme byli požádáni, a tak kupříkladu zpracováváme postupně dle diskusí s úřady třeba Pokus o rozpad fází životního cyklu IS/ICT řešení, kde ukazujeme, co vše se má stát právě v prvních dvou nejvíce zranitelných fázích. V době publikace odpovědi (konec října 2024) je tento podklad ve stádiu připomínek a dopracování. Odkaz ale vede na jeho aktuální a vždy platnou verzi.
2. poučení: Standardní software a nebo vlastní řešení je třeba dobře vyvážit. Médii i odborníky trochu opomíjený aspekt nejen této veřejné zakázky je tzv. standardní software versus zcela nové řešení. Kromě technologické platformy se tím rozumí defacto míra vlastního přizpůsobení nějakého existujícího řešení. A tady z obou stran můžeme překvapivě tvrdě narazit. Samotná vyhláška 360/2023 Sb. (vyhláška o dlouhodobém řízení), ale i závazný rámec Informační koncepce České republiky a Národní architektonický plán dávají za povinnost využívat otevřených řešení a hlavně publikovat jakýkoliv vlastní výsledek úprav a programování jako open-source. Dost zarážející tedy na "pirátském" ministerstvu je to, že se s tím odborníci v MMR jaksi nevypořádali. - Závěr z tohoto poučení není jednoduchý. Ale určitě se musí myslet na situace, kdy dodávka bude tvořena standardními softwarovými komponentami a technologiemi (ať už půjde o open-source produkty, nebo ne), ale především bude jasně vymezen vztah samotného SW řešení k jeho nezbytným úpravám a k tomu, jakým způsobem se splní příslušné povinnosti k publikaci zdrojového kódu a k principu znovupoužitelnosti a otevřenosti.
3. poučení: Dobře nastavit harmonogram a nezapomínat taky na to, že se má testovat, akceptovat, opravovat a upravovat. Je to sice zmíněno až jako poslední žalobní bod, ale nejen za nás je to naprosto klíčové. Harmonogram, kde se fáze testování, akceptací a nápravy chyb a vad dodávky jaksi neřeší, nebo se udělá natolik volně, že z toho není vůbec jasné, jestli a kdy se bude posuzovat kvalita samotné dodávky, to je prostě naprosto špatně. Není to špatně jen z pohledu samotného úřadu jako správce budoucího systému, ale také s ohledem na potřebu testování a případných oprav různých integrací a to zejména na cizí informační systémy, jako jsou základní registry a další. Jen samotné testování služeb ISZR a EGSB trvá nejméně měsíc, spíš ale tak dva až tři. A bez těchto služeb informační systém nesmí fungovat. - Zde je nutné správně nadefinovat celý harmonogram. Ať už začínáte správně od jeho začátku, nebo jak je to bohužel obvyklé od konce, nesmíte na nic zapomenout. A testování a akceptace a opravy jsou jednou z nejdůležitějších fází každého budování či změny ICT řešení. - - Mimochodem, všimli jste si té repliky o tom, že sice MMR trpělo časovou tísní, ale že je to jejich problém, protože si ji způsobilo samo? Na tohle si dávejte opravdu pozor, protože se ukazuje, že výmluvy na časovou tíseň neprojdou a je celkem jedno, jestli jste malý úřad, nebo obří ministerstvo, které řeší zakázku na vlastní vymyšlený systém ke vlastnímu vymyšlenému zákonu.