Jak si nechat vyvinout software. Návod od A do Z.

Prodražení není smůla, ale pravidlo

McKinsey s Oxfordskou univerzitou sbírali data o více než 5 400 IT projektech. U velkých projektů s počátečním rozpočtem nad 15 mil. USD byly průměrné náklady o 45 % vyšší, doba realizace o 7 % delší a přínosy o 56 % nižší, než slibovala investiční studie. Každý rok trvání navíc zvyšuje překročení nákladů o dalších 15 %. Za průměrem se navíc skrývají extrémní případy: 17 % IT projektů dopadne tak špatně, že ohrozí samotnou existenci firmy. Za „černou labuť“ autoři považují překročení rozpočtu o víc než 200 % McKinsey a Oxford, 2012.

Pro plánování z toho plyne nepříjemný, ale užitečný závěr: počítejte s tím, že váš projekt výjimkou nebude. Do schvalování patří odhad v rozpětí a rezerva, ne jedno číslo. Projekt na čtyři roky je přitom rizikovější než čtyři roční etapy, po nichž se vždy rozhodnete, zda pokračovat.

Proč může být první odhad až čtyřikrát vedle

Ve fázi nápadu („potřebujeme systém na…“) může skutečná cena skončit kdekoli mezi čtvrtinou a čtyřnásobkem prvního odhadu. Horní hranice je tedy šestnáctkrát vyšší než dolní. Po dokončení požadavků je to ještě 0,67× až 1,5× a na zhruba ±10 % se dostanete až po detailním návrhu McConnell, 2006 a 2010. A to platí pro zkušené odhadce. Kužel níže ukazuje nejlepší dosažitelnou přesnost. Skutečný odhad může být i méně přesný.

Představte si, že po telefonu chcete pevnou cenu za rekonstrukci domu, který nikdo neviděl. Dostanete buď podhodnocenou nabídku, po níž přijdou dodatky, nebo cenu s velkou rezervou. Se softwarem je to stejné. Pevnou cenu má smysl chtít až po analýze a prototypu (kapitola 10).

Čtyři pasti, které si zákazník připraví sám

Většinu problémů nezpůsobí programátoři. V průzkumu PMI z roku 2014 označilo 37 % organizací za hlavní příčinu selhání projektů nepřesné požadavky PMI, 2014. NKÚ u českých projektů píše, že společným jmenovatelem neúspěšných projektů eGovernmentu je podcenění business analýzy NKÚ, 2026. Hlídejte si hlavně tyto čtyři pasti:

• Podstřelený odhad. Rozpočet se přizpůsobí tomu, co projde schválením, místo aby vycházel z odhadu práce. Test: sedí interní odhad přesně na peníze, které máte k dispozici? Pak je to přání, ne odhad.
• Nepřítomné vedení a uživatelé. Zadání napíše IT samo a vedení se objeví až na předávce. Test: kdo z byznysu zadání podepíše a bude chodit na ukázky?
• Ignorovaná varování. Architekt nebo uživatelé upozorní na termín či složitost a varování z reportu zmizí. Test: víte, kdo varoval a kdo mu odpověděl?
• Neznalost vlastních procesů a dat. Migrace počítá s čistými daty, která nikdo neviděl. Test: máte procesy popsané a viděli jste vzorek dat?

Dobrá zpráva: všem čtyřem pastem můžete předcházet sami. Začněte tím, že si včas položíte uvedené otázky.

Jak kužel zúžit dřív, než podepíšete

• Začněte placenou úvodní analýzou (discovery): malou zakázkou, která ujasní cíle, rozsah a rizika a zpřesní odhad (kapitola 14).
• Nechte postavit klikací prototyp a vyzkoušejte ho s budoucími uživateli.
• Před poptávkou si připravte vzorek dat, která se mají převádět, a podívejte se na ně.
• Odhad chtějte v rozpětí, například „nejspíš 6 mil. Kč, s 80% jistotou do 9 mil. Kč“, a rezervu nechte schválit zvlášť.
• Porovnejte odhad s dokončenými podobnými projekty. Otázka „jak dopadli ostatní?“ je poctivější než „u nás to bude jinak“.
• Velký projekt rozdělte na etapy. Po každé se rozhodne: pokračovat, upravit, nebo zastavit.

Evidenci kupte, odlišnost stavte

Gartner dělí podnikové systémy do vrstev podle toho, jak rychle se mění a jak moc firmu odlišují Gartner, 2012. Pro rozhodnutí stačí tři:

• Evidence: účetnictví, mzdy, HR, sklad, spisová služba. Jde o běžné agendy, pro které zpravidla stačí hotový produkt.
• Odlišující procesy: vaše know-how, oborové portály, specifické postupy. Často vyjde nejlépe hotové jádro a nadstavby.
• Inovace: nové služby, které nikdo jiný nemá. Tady se staví.

Stejný typ systému může být u dvou firem v jiné vrstvě. Plánování směn je pro kancelář s dvaceti lidmi evidence: stačí hotová aplikace. Rozvozová firma ale vydělává právě na tom, že směny a trasy naplánuje lépe než konkurence. Pro ni je to odlišující proces a vlastní řešení se může vyplatit.

Proč vlastní CRM nebývá levnější

Typická úvaha zní: licence za pět let stojí víc než jednorázový vývoj. Jenže u hotového softwaru zajišťuje údržbu, legislativní změny a bezpečnostní záplaty výrobce. Náklady na ně rozděluje mezi tisíce zákazníků. U vlastního systému je platíte každý rok sami. Je to jako stavět si vlastní auto, protože leasing je drahý. Srovnávejte proto celkové náklady za 5 let, ne pouze cenu licencí s cenou vývoje (kapitola 4).

A když už kupujete hotové, převezměte většinu jeho postupů. Každá úprava prodražuje aktualizace i údržbu. Před každým požadavkem na úpravu se zeptejte: je tohle naše výhoda, nebo jen zvyk?

Low-code: rychlý start, drahé stáří

Platformy jako Power Apps, OutSystems nebo Mendix umožňují rychle vytvořit interní formuláře a schvalovací postupy s desítkami až nižšími stovkami uživatelů. Pro tisíce externích uživatelů a hlavní systém na deset a více let se ale obvykle nevyplatí. Technicky to platformy zvládnou, rozhoduje cena a závislost na výrobci.

Platíte totiž průběžně, za každého uživatele, a ceník určuje výrobce. Power Apps Premium stojí 20 USD za uživatele a měsíc Microsoft, ceník 2026, od 1. 1. 2027 to bude 22 USD pro nové nákupy i obnovy Microsoft, zdražení 2027. Pro 500 uživatelů to dělá 2,5–2,8 mil. Kč ročně jen za licence (orientační přepočet při kurzu 21 Kč/USD). Mendix zveřejňuje jen výchozí ceny varianty Standard, Premium i OutSystems se oceňují na poptávku.

Kód aplikace přitom zůstává na platformě výrobce. Data Act od 12. 1. 2027 zakazuje poplatky za přechod mezi cloudovými službami Data Act, čl. 29, aplikaci postavenou na platformě vám ale nepřenese. Odchod znamená aplikaci přepsat. Smluvně si proto zajistěte export dat a mějte plán odchodu.

Low-code navíc potřebuje pravidla: oddělené prostředí pro zkoušení a ostrý provoz, vlastníka u každé aplikace a přehled, kolik aplikací ve firmě běží. Bez těchto pravidel můžete za dva roky zjistit, že na desítkách malých aplikací závisí část provozu a nikdo neví, kdo je spravuje.

Hotové jádro: úpravy vedle, ne uvnitř

Pro odlišující procesy bývá nejlepší koupit robustní jádro a vlastní funkce stavět vedle něj přes rozhraní (API). Funguje to, jen když úpravy zůstanou oddělené. Hluboce přepsané jádro se špatně aktualizuje a váže vás na jednoho integrátora. Státní zemědělský intervenční fond takhle platil v letech 2016–2019 průměrně 514 mil. Kč ročně jedinému dodavateli platformy SAP a NKÚ ho označil za silně závislého NKÚ, KZ 20/07.

Kdy dává zakázka smysl

Vývoj na míru se vyplatí, pokud splňujete všechny následující podmínky:

• proces je vaše konkurenční výhoda nebo unikátní agenda,
• nic hotového neexistuje, nebo by jeho úpravy stály víc než vývoj na míru,
• potřebujete plnou kontrolu nad daty, napojením a změnami,
• máte na své straně vlastníka produktu a rozpočet na roky provozu.

Bez posledního bodu zestárne i dobře postavený systém. Když nevíte, co hotového na trhu je, udělejte si průzkum trhu dřív, než začnete s vývojem (kapitola 8).

Co AI opravdu zrychlí a co ne

Výsledky studií se liší podle typu úlohy a zkušeností vývojářů. V laboratorním experimentu s jedinou jednoduchou úlohou byli programátoři s GitHub Copilotem hotovi o 55,8 % rychleji Peng a kol., 2023. Ve třech experimentech v pracovním prostředí dokončilo 4 867 vývojářů s AI o 26 % více úloh. Větší přínos zaznamenali méně zkušení vývojáři Cui a kol., 2025.

Randomizovaná studie METR z roku 2025 ale ukázala opak u zkušených vývojářů v open-source projektech, které dobře znali: s AI byli o 19 % pomalejší, přitom sami věřili, že byli o 20 % rychlejší METR, 2025. Pocit zrychlení nemusí odpovídat skutečnosti.

DORA popisuje AI jako zesilovač: posílí silné i slabé stránky organizace DORA, 2025. Bez testů, revizí a pravidel tak může zrychlit i vznik chyb.

Schopnosti modelů a AI agentů rychle rostou. Tuto část píšeme v říjnu 2026 a za pár měsíců může vypadat jinak. Jedno ale platí dál: jakmile aplikace pracuje s citlivými daty nebo přihlašuje uživatele, má na ni dohlížet odborník.

Napsat kód je ta menší část

Významnou část nákladů za celou dobu životnosti softwaru tvoří údržba: opravy, aktualizace a úpravy. Klasická souhrnná publikace uvádí podíl 40–80 % všech nákladů Glass, 2002 (kapitola 4). Aplikace „zadarmo za víkend“ má před sebou roky práce, o kterých se zatím nemluví.

Navíc chybu v kódu od AI laik nepozná. Ani profesionálové výstupům slepě nevěří: 46 % vývojářů nedůvěřuje jejich přesnosti, o rok dřív to bylo 31 % Stack Overflow, 2025.

Stínové IT a díry v zabezpečení

Zaměstnanci si staví nástroje bez vědomí IT. Vznikají neevidované aplikace s osobními údaji, bez člověka, který by autora zastoupil, a s nejasnou odpovědností za GDPR a kybernetickou bezpečnost. Odpovědnost nese firma, ne kolega.

IBM v roce 2025 zjistil, že 97 % organizací, které měly bezpečnostní incident spojený s AI, nemělo řádně řízený přístup k AI. Pětina organizací zažila incident kvůli AI nástroji, o kterém IT nevědělo, a škoda pak byla vyšší až o 670 tis. USD, zhruba o 14 mil. Kč při kurzu 21 Kč/USD IBM, 2025.

Rychle psaným aplikacím typicky chybí řízení přístupů, spolehlivé přihlašování a záznamy o událostech. U aplikací s AI se přidává podvržení instrukcí (prompt injection), příliš velká oprávnění AI agenta a únik citlivých dat OWASP, 2025. I jediný sdílený účet s přístupem do ostré databáze může způsobit vážný problém.

AI model na vlastním hardwaru

Jazykový model nemusí běžet u poskytovatele v cloudu. Otevřený model (open-weight, se zveřejněnými vahami) může firma provozovat na vlastním serveru nebo v privátním cloudu. Dokumenty pak neopouštějí firmu a nad daty i modelem má plnou kontrolu. Potřebuje k tomu ale výkonný hardware a odborníky EDPB SPE, 2025.

Kde se hodí:

• anonymizace nebo pseudonymizace dokumentu dřív, než ho pošlete do komerční AI: místní model nahradí jména, adresy nebo čísla smluv zástupnými údaji,
• shrnutí a třídění citlivých dokumentů, třeba smluv nebo personálních spisů,
• vyhledávání a odpovědi nad interními dokumenty.

Výhody:

• data zůstávají uvnitř firmy, snáz splníte GDPR i smlouvy o mlčenlivosti,
• nezávisíte na podmínkách a cenách poskytovatele,
• při velkém objemu práce jsou náklady předvídatelnější.

Nevýhody:

• i nejlepší otevřené modely zaostávají za špičkovými komerčními o několik měsíců Epoch AI, 2026, na vlastním serveru navíc obvykle poběží menší a slabší model,
• pořízení serveru s grafickými kartami (GPU) a jeho provoz,
• aktualizace, zabezpečení a dohled jsou na vás, ne na poskytovateli,
• anonymizace modelem není stoprocentní, výsledek proto před odesláním zkontroluje člověk.

A ještě jedna past: výtvor AI podle Městského soudu v Praze není autorské dílo, autorem může být jen člověk MS Praha, 10 C 13/2023. Soud řešil obrázek, ne kód, ale čistě vygenerovaný kód nemusí být chráněný. Jak to ošetřit u dodavatele, najdete v kapitole 11.

Nejlepší použití: prototyp jako zadání

Vlastník produktu nebo analytik během pár dní postaví klikací prototyp, vyzkouší ho s kolegy a předá dodavateli. Prototyp zúží kužel nejistoty ještě před poptávkou (kapitola 1). Je to ale zadání, ne základ ostrého systému. Přidejte k němu krátký popis: kdo aplikaci používá, co v ní dělá, s jakými daty pracuje a co prototyp záměrně neřeší. Dodavatel pak nemusí hádat a vy dostanete přesnější nabídku (kapitola 6).

AI ve firmě nezakazujte plošně. Zákaz může vést k tomu, že ji zaměstnanci budou používat tajně. Povinnost AI gramotnosti platí podle AI Actu od 2. 2. 2025, od 27. 7. 2026 ji nařízení 2026/1744 zmírnilo Nařízení (EU) 2026/1744. Stačí pravidla na jednu stranu:

• povolené nástroje a nástroje, které používat nesmíte,
• co se do AI nevkládá: osobní údaje, obchodní tajemství, hesla a přístupové klíče,
• semafor: zelená sami, oranžová nahlásit IT, červená projekt,
• kde se aplikace evidují a kdo je jejich vlastník a zástupce,
• školení a kontakt na IT a bezpečnost.

Špička ledovce: co v nabídce není vidět

Cena díla je to, co vidíte. Pod hladinou bývají položky, které v nabídce chybějí, protože je platíte jinde nebo až později:

• migrace a čištění dat ze starého systému,
• napojení na další systémy, licence třetích stran, cloud a hosting,
• bezpečnostní testy a školení uživatelů,
• čas vlastníka produktu a klíčových uživatelů,
• souběh starého a nového systému,
• provoz, údržba a rozvoj po spuštění,
• předání systému jinému dodavateli, až jednou přijde čas.

Po spuštění utratíte víc než za vývoj

Údržba spotřebuje 40–80 % všech nákladů na software a zhruba 60 % z ní tvoří vylepšení, ne opravy chyb Glass, 2002. Rozpočet, který končí dnem spuštění, tak pokrývá jen část skutečných výdajů.

Pro první odhad provozu a údržby počítejte s 10–20 % pořizovací ceny ročně. Orientační oporu nabízejí české státní systémy: základní registry stály v pořízení téměř 1,8 mld. Kč a jejich provoz vychází průměrně na 220 mil. Kč ročně, tedy asi 12 %, s rozvojem a obnovou kolem 17 % NKÚ, KZ 23/05. Nový systém cestovních dokladů MZV má podporu asi za 8 % ceny ročně NKÚ, KZ 24/26. Často citované rozpětí 15–25 % ročně pochází jen z blogů dodavatelů. Rozhoduje ale obsah, ne samotné procento: nabídka podpory výrazně pod 10 %, která nepopisuje, co zahrnuje, nejspíš něco vynechává, třeba zálohy, aktualizace nebo testy obnovy.

Peníze po spuštění rozdělte do tří obálek:

1. provoz a podpora: hosting, monitoring, řešení incidentů,
2. údržba: aktualizace knihoven a platforem, bezpečnostní záplaty, splácení technického dluhu,
3. rozvoj: nové funkce a změny kvůli byznysu nebo legislativě.

Když je sloučíte, mohou nové funkce vyčerpat peníze na údržbu a systém začne stárnout (kapitola 22).

Sazba za MD není cena projektu

Cena vývoje softwaru se počítá v MD, tedy v člověkodnech: jeden MD je den práce jednoho člověka (8 hodin). Komerční trh nemá veřejný ceník. Jako orientační vodítko poslouží data státu: Ministerstvo vnitra dvakrát ročně vydává přehled cen, které úřady za IT práci skutečně platí.

Mediány se pohybují kolem 9–14 tis. Kč za MD MV, Přehled cen ICT, 7/2026. Hodinová sazba programátora tak v mediánu vychází zhruba na 1 250 Kč bez DPH (10 000 Kč za MD děleno 8 hodinami). Rozdíly mezi resorty jsou ale obrovské: programátor stál na MZe v mediánu 5 900 Kč, na MZV 18 000 Kč. Často však jde jen o jednotky smluv MV, benchmarking resortů, 7/2026. Nižší denní sazba může při větším počtu MD znamenat dražší projekt. Srovnávejte celkovou cenu za dodávku, rozpad podle rolí a senioritu lidí.

Do kalkulačky zadávejte rozpětí, ne jedno číslo: spočítejte variantu s údržbou 10 % i 20 %. Stejným způsobem spočítejte i existující software, za který platíte licence: implementace, licence za všechny uživatele na 5 let s ohlášeným zdražením, úpravy od partnera a interní správa. U existujícího softwaru ke kódu práva nemáte. U zakázky můžete mít kód i licenci k němu, ale jen se správnou smlouvou (kapitola 11).

Čas vašich lidí stojí peníze

Vlastník produktu potřebuje během vývoje 50–100 % úvazku, klíčoví uživatelé 5–10 % a při testování 30–50 % (orientační hodnoty, podrobně v kapitole 16). U projektu na osm měsíců jde o statisíce korun interních nákladů. Započítejte je do rozpočtu a lidi uvolněte z jiné práce. Projekt, na který mají klíčoví lidé čas „po večerech“, je jako stavba, na kterou stavbyvedoucí jezdí jednou za měsíc.

Počítejte také s růstem cen. Ceny licencí se během životnosti systému mění (Power Apps Premium zdražuje od roku 2027 z 20 na 22 USD Microsoft, zdražení 2027), u zakázky rostou sazby. Kalkulace s nulovým růstem je optimistická.

Přínosy se přeceňují víc než náklady

Náklady velkých IT projektů přetáhnou plán v průměru o 45 %, přínosy zaostanou o 56 % McKinsey a Oxford, 2012. Největší slabinou business casu tak mohou být právě přínosy, které mají investici obhájit. U každého přínosu proto napište, kdo ho změří, jak a kdy. Do výpočtu patří celkové náklady za 5 let z kapitoly 4, ne cena díla. Jinak vám doba návratnosti vyjde o roky kratší, než bude ve skutečnosti.

Cíl, který nejde změřit, není cíl

„Modernizovat a zefektivnit agendu“ zní dobře, ale nikdy nezjistíte, jestli se to povedlo. „Zkrátit vyřízení žádosti z 12 na 5 dní do konce roku 2027“ změříte. Stanovte 3–5 metrik a u každé uveďte:

• výchozí hodnotu dnes (změřte ji ještě před vývojem),
• cílovou hodnotu a datum,
• kdo ji měří a odkud se bere údaj.

Úspěch posuzujte podle hodnot metrik po 6 a 12 měsících provozu, nejen podle toho, zda jste systém spustili v termínu.

Pět druhů přínosů a jak je spočítat

• Ušetřený čas: počet lidí × ušetřené hodiny týdně × počet pracovních týdnů × hodinový náklad. Do přínosů započítejte jen část výsledku. Ne každá ušetřená hodina se promění v další užitečnou práci.
• Méně chyb: počet chyb ročně × náklad na jednu chybu (oprava, reklamace, pokuta) × očekávané snížení.
• Vyšší výnosy: přírůstek tržeb × marže, ne celé tržby.
• Nižší riziko: pravděpodobnost události × její dopad × o kolik ji systém sníží.
• Legislativa: náklad nejlevnějšího jiného způsobu, jak povinnost splnit. Ne výše pokuty.

Příklad: 20 lidí ušetří každý 2 hodiny týdně. Při hrubé mzdě 80 000 Kč stojí hodina práce firmu asi 670 Kč (mzda × 1,338 za odvody, děleno 160 hodinami). Za 46 pracovních týdnů to dělá 1,23 mil. Kč, a pokud se podaří využít jen polovinu ušetřeného času, zhruba 615 tis. Kč ročně. To už je číslo, se kterým se dá jít za finančním ředitelem.

Přidejte úsporu starého řešení: licence, podporu a provoz, které opravdu odpadnou. Pak si položte hlavní otázku: vyplatí se projekt, i když přínosy budou poloviční a náklady o čtvrtinu vyšší? Pokud ano, máte silný business case.

Vždy srovnávejte s variantou „nic neděláme“

I zachování současného stavu stojí peníze. Starý systém stárne, jeho podpora zdražuje a hrozí výpadky. Na MZV například vzrostly náklady na podporu starého systému z 1,2 na 15,3 mil. Kč ročně NKÚ, KZ 24/26 (kapitola 4). Bez vyčíslení nulové varianty nedokážete posoudit, zda se změna vyplatí. Porovnejte proto tři varianty: zachovat současný stav, koupit či upravit hotové řešení a vyvinout systém na míru (kapitola 2).

Business case není jednorázový papír. Po úvodní analýze a po první etapě budete vědět víc. V obou chvílích ho přepočítejte. Každé zmenšení rozsahu předložte znovu ke schválení spolu s dopadem na přínosy. Jinak může projekt dodržet rozpočet, ale nenaplnit svůj účel.

Kdo za přínosy odpovídá

Za přínosy má odpovídat jeden sponzor z byznysu, a to i po spuštění. Tuto odpovědnost nepřenášejte na vedoucího IT ani na dodavatele. Přínosy odhaduje a podepisuje vlastník procesu na vaší straně.

O pokračování by neměl rozhodovat jen ten, kdo projekt prosadil. Klasický experiment ukázal, že nejvíc peněz do neúspěšné volby přidávají lidé, kteří za původní rozhodnutí osobně odpovídají Staw, 1976. Oddělte proto toho, kdo projekt vede, od toho, kdo hodnotí jeho stav, a kritéria zastavení dohodněte předem.

BUSINESS CASE NA JEDNU STRANU
Projekt: …
Datum a verze: …

1. PROBLÉM
Co dnes nefunguje, komu to komplikuje práci a jak to víme (data, ne dojmy):
…

2. CÍL A METRIKY (3–5)
Metrika | Dnes | Cíl | Do kdy | Kdo měří | Odkud se bere údaj
Příklad: Doba vyřízení žádosti | 12 dní | 5 dní | 12/2027 | vedoucí odboru | časová razítka v systému
…

3. VARIANTY
A) Nic neděláme: co nás stojí udržet dnešní stav (podpora, licence, rizika, výpadky)
B) Koupit nebo upravit hotové řešení
C) Postavit na zakázku

4. PŘÍNOSY V KČ ROČNĚ
Ušetřený čas: …
Méně chyb: …
Vyšší výnosy: …
Nižší riziko: …
Splnění legislativy (nejlevnější jiný způsob splnění): …

5. NÁKLADY
Celkové náklady na 5 let (pořízení, provoz, údržba, rozvoj, interní čas): …

6. NÁVRATNOST
Doba návratnosti: …
Vyplatí se i při polovičních přínosech? ano / ne

7. RIZIKA A PŘEDPOKLADY
Co musí platit, aby přínosy nastaly (lidé se naučí, proces se změní, data jsou kvalitní):
…

8. KDO ODPOVÍDÁ
Sponzor (odpovídá za přínosy i po spuštění): …
Vlastník produktu (rozhoduje o rozsahu): …
Kdo nezávisle hodnotí stav projektu: …

9. KRITÉRIA ZASTAVENÍ (dohodnutá předem)
Např.: když po úvodní analýze vyjdou náklady o víc než 50 % nad schválený rámec, vracíme se ke schválení.
…

10. KDY PŘEPOČÍTÁME
Po úvodní analýze · po první etapě · 6 a 12 měsíců po spuštění

PRO ÚŘADY DOPLNIT
Vazba na informační koncepci · 3E (řádné finanční řízení) · analýza nákladů a přínosů (CBA) · zdroj financování · stanovisko OHA ano/ne

Zadání pro výběr popisuje problém, ne řešení

Nepřesné požadavky uvedlo v průzkumu PMI 37 % organizací jako hlavní příčinu selhání projektů PMI, 2014. NKÚ u státních projektů mluví o podcenění business analýzy jako o společném jmenovateli neúspěchů NKÚ, 2026. Čas strávený na zadání tedy není zdržení. Je to nejlevnější pojistka, jakou máte.

Pro výběr dodavatele ale nepotřebujete stovky stran dokumentace. Stačí 3–6 stran, které odpoví na tyto otázky:

• Jaký problém řešíme a kolik nás dnes stojí?
• Podle jakých 2–4 měřitelných cílů poznáme úspěch?
• Kdo bude systém používat, kolik bude mít uživatelů a jaké úkoly v něm budou nejčastěji řešit?
• Jaká data máme, kde leží a na co se systém musí napojit?
• Jaká máme omezení (bezpečnost, přístupnost, hosting, legislativa), termín a rozpočtový rámec?

Návrh obrazovek a volba technologie do zadání jako závazné řešení nepatří. Uveďte jen technická omezení, která plynou ze stávajícího prostředí, třeba nutná napojení na účetní nebo skladový systém. Když předepíšete řešení místo popisu problému, omezíte prostor pro lepší nápady a můžete dostat obtížně porovnatelné nabídky. Podrobná specifikace s akceptačními kritérii vznikne až v analýze s vybraným dodavatelem (kapitola 14).

Kdo na vaší straně bude rozhodovat?

Vlastník produktu má být váš zaměstnanec, ne externista dodavatele Česko.Digital, 2022. Rozhoduje o prioritách, odpovídá na dotazy a přebírá hotové části. Nejčastější brzda projektu je zákazník, který na něj nemá čas.

Orientačně počítejte s tím, že v analýze potřebuje vlastník produktu 50–100 % úvazku, při vývoji s týmem 5–9 lidí prakticky celý úvazek. K tomu potřebujete 3–8 klíčových uživatelů, kteří analýze věnují 20–30 % svého času. Jmenujte je ještě před poptávkou a jejich zapojení a vyhrazený čas potvrďte písemně. Vlastník produktu, který je jen jménem v dokumentu, ale nad projektem aktivně netráví čas, je jako kapitán, který na loď nenastoupil.

Znejte svá data dřív než dodavatel

Převod dat ze starého systému je nejčastěji podceněná část projektu. Dodavatel, který data neviděl, riziko buď zahrne do ceny jako rezervu, nebo ho podcení a později si vyžádá dodatky. Při soutěži na digitalizaci stavebního řízení sedm dodavatelů napsalo ÚOHS, že migraci bez dalších informací nelze spolehlivě ocenit ÚOHS, S0321/2023 (víc v kapitole 12).

K poptávce proto přiložte anonymizovaný vzorek dat, popis zdrojových systémů, počty záznamů a známé problémy s kvalitou (duplicity, chybějící údaje).

Textové zadání může ještě lépe přiblížit klikací prototyp. Váš analytik nebo vlastník produktu ho s AI nástrojem nebo v low-code zvládne za pár dní a vyzkouší s kolegy (kapitola 3). Kužel nejistoty (kapitola 1) se tím zúží ještě před výběrovým řízením. Prototyp je ale ilustrace potřeby pro dodavatele, ne předepsané řešení ani produkční systém.

Co se škrtne, když dojdou peníze?

U každého požadavku uveďte prioritu podle MoSCoW:

• Must: bez toho systém nemá smysl,
• Should: důležité, ale dá se to chvíli obejít,
• Could: přidáme, když zbude čas a peníze,
• Won't: tentokrát ne.

Must má být menšina. Když je „nutné“ všechno, nebudete při komplikacích vědět, co můžete odložit. Podobně dělí požadavky i karty hodnocení DIA: povinné jsou podmínkou, volitelné se bodují DIA, karta Fakultativní požadavky.

Jste připravení oslovit trh? Než pošlete první poptávku, odpovězte si ano, nebo ne:

• Umíme problém popsat jednou větou a vyčíslit, kolik nás stojí?
• Máme 2–4 měřitelné cíle s výchozí hodnotou?
• Je jmenovaný vlastník produktu s mandátem a uvolněným časem?
• Víme, kdo jsou uživatelé, kolik jich je a jaké jsou klíčové scénáře?
• Známe zdroje dat, objemy a kvalitu a máme anonymizovaný vzorek?
• Máme seznam systémů k napojení a priority MoSCoW?
• Máme rozpočtový rámec včetně provozu na 5 let (kapitola 4) a ověřili jsme, že hotové řešení nestačí (kapitola 2)?

Pro první orientaci: pokud odpovíte na všechno ano, můžete začít poptávat. Chybějí-li vám dvě nebo tři odpovědi, nejprve je doplňte, případně si objednejte úvodní analýzu. Při více nezodpovězených otázkách začněte analýzou nebo interním prototypem.

ZADÁNÍ PRO VÝBĚR DODAVATELE
Projekt: …
Vlastník produktu: …
Datum a verze: …

1. PROBLÉM
Co dnes nefunguje a kolik to stojí (čas, chyby, peníze). Nepište řešení.
Příklad: Objednávky přepisujeme ručně ze 3 systémů, 2 lidé na plný úvazek, 4 % chyb.
…

2. CÍLE A METRIKY (2–4)
Cíl | Dnes | Cílová hodnota | Do kdy
Příklad: Doba vyřízení objednávky | 2 dny | 4 hodiny | 6 měsíců po spuštění
…

3. UŽIVATELÉ
Skupina | Počet | Interní / externí | Zařízení
Příklad: obchodníci | 40 | interní | desktop i mobil
…

4. KLÍČOVÉ SCÉNÁŘE (5–15, jedna věta = jeden scénář)
Příklad: Obchodník založí nabídku z šablony a pošle ji ke schválení.
…

5. DATA
Zdroje, objemy, kvalita, co se bude převádět ze starého systému.
Příklad: 120 000 zákazníků v CRM, odhadem 10 % duplicit.
Anonymizovaný vzorek dat: v příloze / poskytneme po podpisu NDA
…

6. NAPOJENÍ NA DALŠÍ SYSTÉMY
Systém | Způsob (API, soubor, jiné)
Příklad: ERP (API), účetnictví (CSV), přihlášení přes Microsoft 365
…

7. OMEZENÍ
Bezpečnost (regulovaná služba podle ZoKB, GDPR), přístupnost, hosting, technologie, legislativa.
Příklad: data jen v EU, přístupnost podle WCAG 2.1 AA.
…

8. PRIORITY (MoSCoW)
Must (musí být, menšina požadavků): …
Should (mělo by být): …
Could (může být, když zbude čas a peníze): …
Won't (tentokrát ne): …

9. TERMÍN
Pevné termíny a proč (legislativa, sezóna): …

10. ROZPOČTOVÝ RÁMEC
Vývoj od–do Kč bez DPH: …
Provoz a rozvoj ročně: …

11. LIDÉ NA NAŠÍ STRANĚ
Vlastník produktu (dny týdně): …
Klíčoví uživatelé (kdo, hodiny týdně): …
IT, bezpečnost, právník: …

12. VLASTNICTVÍ A NEZÁVISLOST
Licence s právem úprav třetí stranou, zdrojový kód průběžně v našem repozitáři, dokumentace, export dat, plán odchodu.

13. CO JE MIMO ROZSAH
Příklad: Nenahrazujeme účetnictví.
…

PŘÍLOHY
Vzorek dat · prototyp · popis procesů · seznam systémů

Nejdřív rozhodněte, kdo odpovídá za výsledek

Můžete si objednat dílo: dodavatel slíbí výsledek a odpovídá za něj. Nebo si pronajmete kapacity: platíte za člověkodny a za výsledek odpovídáte vy. Obě varianty mohou fungovat, musíte však vědět, kterou si objednáváte.

U pronájmu lidí (body shop) i u vzdáleného týmu potřebujete vlastníka produktu na své straně a architekta. Řízení, návrh a testování zůstávají na vás. Pokud je nemáte, objednejte si dílo. Smlouva musí odpovídat tomu, co kupujete (kapitola 10). Pronajmout si čtyři vývojáře a čekat hotový systém je jako najmout zedníky bez stavbyvedoucího a divit se, že dům nestojí podle plánu.

Velikost dodavatele má odpovídat velikosti projektu

Pro první orientaci: malé studio (do zhruba 20 lidí) se hodí na webové a mobilní aplikace a projekty do jednotek milionů Kč. Střední firma (zhruba 20–250 lidí) se hodí na podnikové aplikace a integrace za jednotky až desítky milionů. Velký integrátor má zázemí pro rozsáhlé a kritické systémy.

Obě krajnosti mají svou past. Malému dodavateli mohou chybět kapacity nebo zázemí pro podporu 24/7. U velkého můžete být malým klientem a hrozí známé „A-tým v nabídce, B-tým v realizaci“: na prezentaci senioři, na projektu junioři nebo subdodavatelé. Proto se ptejte, jaký podíl tržeb dodavatele váš projekt bude tvořit a kdo konkrétně na něm bude pracovat. Klíčové osoby patří jmenovitě do smlouvy a jejich výměna má být možná jen s vaším souhlasem.

Seniorní tým s vyšší sazbou bývá v součtu levnější než juniorní tým s nízkou sazbou, protože potřebuje méně člověkodnů a nadělá méně chyb, které pak platíte v údržbě. A tvrzení o velikosti si ověřte: studio, které slibuje „tým 15 lidí“, ale v rejstříku a na LinkedInu má tři, vám tým teprve shání (prověrka firmy v kapitole 9).

Mediány sazeb pro jednotlivé role najdete v kapitole 4 MV, Přehled cen ICT, 7/2026.

Vhodný typ dodavatele vyberete snáz pomocí tří otázek:

• Máte na své straně vlastníka produktu s vyhrazeným časem? Pokud ne, vyřaďte pronájem lidí i vzdálený tým.
• Máte vlastního architekta nebo technicky zdatného člověka? Pokud ne, objednejte dílo na klíč, ne kapacity.
• Potřebujete podporu 24/7 a vysokou dostupnost? Pak freelancer ani malé studio nemají být jediným dodavatelem.

Kde se skrývá riziko u malých a u vzdálených

U freelancera a malého studia může projekt záviset na jediném člověku. Nemoc nebo odchod klíčové osoby zastaví projekt. Dohodněte zastupitelnost, každodenní ukládání kódu do vašeho repozitáře a průběžnou dokumentaci, která nevzniká až „na konci“.

Offshore a nearshore mohou nabídnout nižší sazbu, celkové náklady ale klesnout nemusejí. Platíte víc za řízení, komunikaci přes časová pásma a předávání znalostí. Vždy chtějte vědět, kde fyzicky leží data a kód, a u osobních údajů mějte smlouvu o zpracování (čl. 28 GDPR).

Subdodavatele chtějte znát jmenovitě už v nabídce, včetně jejich podílu na plnění a země, ze které budou pracovat. Pokud poskytujete regulovanou službu podle zákona o kybernetické bezpečnosti, musíte bezpečnostní požadavky promítnout do smluv s dodavateli Zákon č. 264/2025 Sb.. Povinné náležitosti smlouvy s významným dodavatelem stanoví vyhláška Vyhláška č. 409/2025 Sb.. Řetězení subdodavatelů bez vašeho souhlasu smluvně zakažte.

Vlastní vývojový tým dává smysl u systému, který je jádrem podnikání a bude se rozvíjet léta. Nejčastější a rozumná kombinace: vlastník produktu a architekt uvnitř organizace, vývoj externě. Znalost systému tak zůstane u vás, i když dodavatel odejde.

Nejdřív se ptejte, teprve pak poptávejte

Žádost o informace (RFI) je nezávazná otázka trhu: jak byste náš problém řešili, existuje hotové řešení a kolik by to zhruba stálo? Zjistíte, jestli je harmonogram reálný, které hotové nebo open source komponenty lze použít a kde jsou rizika, třeba u převodu dat. Teprve poptávka (RFP) žádá závaznou nabídku.

Orientační doporučení pro firmy:

• RFI pošlete 6–10 firmám, stačí 1–2 strany a schůzka na 60–90 minut.
• Poptávku pošlete jen 3–5 firmám, které z RFI vyšly jako relevantní. Víc nabídek kvalitně nevyhodnotíte a dobré firmy odradí malá šance na úspěch.
• Lhůta pro nabídku u projektu za miliony Kč je 3–4 týdny. Kratší lhůta znamená přirážku za riziko, nebo odmítnutí.
• Dotazy přijímejte do stanoveného data a odpověď pošlete všem najednou.

Dotazy dodavatelů berte jako včasné varování, ne jako obtěžování. Kdo se na nic nezeptá, zadání nejspíš pořádně nečetl. Když se na totéž ptá více firem, zadání v daném místě není dostatečně jasné. Doplňte je pro všechny ještě před podáním nabídek.

Placená úvodní analýza se vyplatí

Když je zadání nejasné, objednejte nejdřív úvodní analýzu (discovery) jako samostatnou malou zakázku. Trvá typicky 2–8 týdnů a jejím výstupem je zadání, odhad a prototyp. Smluvně si zajistěte práva k výstupům, včetně práva předat je dalším dodavatelům. Samotnou realizaci pak můžete poptat na základě přesnějšího zadání.

Analýza zdarma vypadá jako úspora, ale dodavatel počítá s tím, že na ni naváže zakázka na realizaci. Je to jako nechat si zdarma udělat projekt domu od firmy, která ho pak chce stavět: plán sedí hlavně na ni.

Počítejte i s časem. Celý výběr dodavatele u firmy trvá orientačně 2,5–6 měsíců:

Kdo potřebuje začít vývoj v září, musí začít s výběrem dodavatele nejpozději v červnu, s rezervou už na jaře.

Co patří do poptávky

Popište problém, ne řešení. Uveďte také rozpočet, alespoň rámcově nebo řádově. Dodavatelé tak mohou včas říct, zda projekt za dané peníze zvládnou, a navrhnout rozsah, který se do rozpočtu vejde. Dobrá poptávka obsahuje:

• problém, cíle s metrikami, uživatele a klíčové scénáře (ze zadání z kapitoly 6),
• data, napojení a nefunkční požadavky: bezpečnost, přístupnost, výkon, dostupnost,
• rozpočtový rámec a termín,
• požadavky na licenci, předávání zdrojového kódu a dokumentace,
• hodnoticí kritéria s vahami (kapitola 9),
• předepsanou strukturu nabídky včetně rozpadu pracnosti podle rolí a seznamu předpokladů,
• návrh smlouvy, nebo aspoň klíčové smluvní principy.

Licenci a kód řešte už v poptávce. Po výběru dodavatele už máte slabší vyjednávací pozici (kapitola 11).

Jak srovnat nesrovnatelné nabídky

Předepsaná struktura má jediný účel: aby šly nabídky porovnat. Chtějte rozpad pracnosti podle rolí a etap (analýza, návrh, vývoj, testování, bezpečnost, řízení, nasazení, převod dat) a seznam předpokladů a položek, které nabídka nezahrnuje. Pevná cena bez nich je varovný signál, protože každá nejasnost se pak stane víceprací. Proč nerozhoduje samotná sazba, vysvětluje kapitola 4. Postup bodování nabídek najdete v kapitole 9.

Kvalita má převážit nad cenou

Ministerstvo kultury u zakázky Kreativní Česko podle asociace dodavatelů hodnotilo cenu váhou 30 %, kvalitu řešení 50 % a technické zajištění vývoje 20 % Lupa.cz, 2026 (kapitola 8). Metoda Best Value dává ceně 30 % a kvalitě 70 %, z toho pohovor s klíčovými členy týmu může mít 20–30 % AIR, Best Value. Orientačně platí, že při váze ceny 80 % a více má kvalita na výsledek malý vliv a vyhrává podstřelená nabídka, kterou pak doženou vícepráce (kapitola 10).

Vyšší váha kvality neznamená dražší zakázku. V jednom z případů, které asociace popsala, vyšla nejlépe hodnocená nabídka zároveň jako nejlevnější Lupa.cz, 2026. Cenu hodnoťte celkovou, včetně provozu a podpory na 5 let (kapitola 4), ne pouze podle denní sazby.

Bodujte podle popsaných úrovní, ne od oka

Kritérium „návrh řešení: 0–40 bodů“ bez dalšího popisu nechává příliš velký prostor pro subjektivní hodnocení. U každého kritéria kvality proto předem napište, co znamená 0, 1, 3 a 5 bodů. Například u návrhu řešení: 0 = obecný text, 1 = opisuje zadání, 3 = konkrétní návrh a některá rizika, 5 = pojmenovaná rizika s řešením a realistické etapy.

Kvalitu hodnoťte dřív, než otevřete ceny (dvouobálková metoda). Neodměňujte samotnou délku nabídky. U ceny pozor na prostý lineární přepočet: podle DIA vede k tomu, že se vybírají extrémní nabídky DIA, ISSS 2025. Mimořádně nízkou cenu si nechte vysvětlit.

Než začnete bodovat, zkontrolujte v každé nabídce tři věci. První je rozpad pracnosti: jsou v něm zvlášť analýza, testování, bezpečnost a řízení, nebo jen „vývoj“? Druhou jsou předpoklady: co dodavatel považuje za dané, například že data jsou čistá nebo že dodáte rozhraní do jiných systémů. Třetí je seznam toho, co v ceně chybí: licence, provoz, převod dat nebo školení. Dvě nabídky se stejnou cenou můžou mít úplně jiný rozsah.

Tým, reference a zkušební sprint

Hodnoťte lidi, kteří budou na projektu skutečně pracovat, nejen vystoupení obchodníků. Pozvěte architekta a vedoucího týmu na pohovor nebo workshop. Když na prezentaci sedí jiní lidé než v nabídce, máte první varovný signál.

Reference ověřte sami, ne přes dodavatele. Zavolejte kontaktní osobě u klienta a zeptejte se:

• Dodali v termínu a rozpočtu? Pokud ne, o kolik a proč?
• Pracoval na projektu stejný tým, jaký nabízí nám?
• Jak řešili změny a problémy?
• Dostali jste zdrojový kód a dokumentaci?
• Vybrali byste si je znovu?

Chtějte kontakt i na dva klienty, kteří s dodavatelem skončili. Loga na webu nejsou reference.

Nejvíce vám ukáže placený zkušební sprint. Orientačně počítejte s 1–2 týdny práce s 2–3 finalisty na reálném zadání a s předem známými kritérii. Uvidíte, jak tým komunikuje, ptá se a dodává. Podle citovaného článku asociace dodavatelů chtělo město Žďár nad Sázavou u informačního systému za 15 mil. Kč před podpisem smlouvy předvést demoverzi na klíčových procesech Lupa.cz, 2026.

Prověrka firmy zabere dvacet minut

Veřejné rejstříky odhalí nejhorší rizika dřív, než podepíšete. Účetní závěrky kontrolujte aspoň za 3 roky.

Evidence skutečných majitelů je od 17. 12. 2025 veřejnosti nepřístupná BusinessInfo.cz, 2025. Výpis si proto vyžádejte přímo od dodavatele. Certifikát ISO berte jako signál, ne záruku, a vždy ověřte jeho rozsah: certifikát „pro obchodní činnost v sídle firmy“ o vývoji neříká nic. Malá studia ho často nemají.

U projektu na několik let je stabilita dodavatele stejně důležitá jako jeho technické schopnosti. U velké zakázky přiložte výsledek prověrky k hodnoticí zprávě, ať je jasné, že ji někdo udělal.

Riziko nejistoty nezmizí, jen se přesune

Ve fázi nápadu může být odhad 0,25× až 4× skutečnosti, na zhruba ±10 % se dostanete až po detailním návrhu McConnell, 2006 a 2010 (kapitola 1).

Kdo chce pevnou cenu za celý systém podle dvoustránkového zadání, dostane jednu ze dvou nabídek. Buď bude obsahovat vysokou přirážku za riziko, nebo bude podhodnocená a dodavatel ji později dorovná vícepracemi. Ani jedno není dobrý obchod.

Každý model jen rozděluje riziko jinak. U fixní ceny ho formálně nese dodavatel, reálně ho ale zaplatíte v přirážce. U time & material ho nesete vy, zato platíte jen skutečně odvedenou práci. Kombinované modely riziko sdílejí: dodavatel odpovídá za etapu, vy rozhodujete, co bude dál.

Čas jde proti vám: každý rok trvání navíc zvyšuje překročení nákladů o 15 % McKinsey a Oxford, 2012. Rozdělte proto projekt na menší etapy, orientačně do 3 měsíců. Po každé rozhodněte, zda pokračovat.

Hybrid: pevný rámec, pružný obsah

Pro většinu firem i úřadů dává smysl kombinovaný model: pevný strop rozpočtu, etapy zakončené rozhodnutím o dalším postupu a v jejich rámci agilní vývoj s backlogem. O obsahu etapy rozhodují priority (MoSCoW, kapitola 6), cena zůstává pod kontrolou. Česká adaptace příručky 18F doporučuje „průběžné platby za čas a náklady (se stropem pro celkové výdaje)“ Česko.Digital, 2022.

Funguje to jako rekonstrukce bytu s pevným rozpočtem: víte, kolik můžete utratit, a po každé místnosti se rozhodnete, jestli pokračovat stejně, nebo jinak.

Time & material bez pravidel je ale otevřený rozpočet. Hlídejte čtyři věci:

• strop, který dodavatel bez vašeho souhlasu nepřekročí,
• měsíční přehled čerpání rozpočtu ve vztahu k tomu, co bylo dodáno a převzato,
• právo kdykoli přestat objednávat,
• vlastníka produktu, který má čas rozhodovat o prioritách.

Kde máte jasnou definici hotového, můžete platit za převzatý přírůstek: dodavatel fakturuje jen části, které jste otestovali a převzali. Funguje to, jen když převzetí na vaší straně nevázne. Jinak zdržujete platby a narušujete spolupráci.

Kolik stojí člověkoden a celý tým

Medián sazby za člověkoden se ve státních smlouvách v 1. pololetí 2026 pohyboval od 9 220 Kč u testera po 13 600 Kč u architekta, bez DPH MV, Přehled cen ICT, 7/2026. Tabulku podle rolí najdete v kapitole 4. Pracujte s kvartily, ne s průměrem, a hlídejte, jestli srovnáváte ceny s DPH, nebo bez.

Tým o 5–9 lidech stojí podle Česko.Digital zhruba 12–20 mil. Kč ročně a jedna zakázka nemá přesáhnout 40 mil. Kč ročně a 3 roky Česko.Digital, 2022. Orientační kontrolní výpočet: 5 lidí × 20 MD × 10 500 Kč × 12 měsíců = 12,6 mil. Kč ročně.

Plaťte až za převzatou práci

Převzetí (akceptace) je poslední chvíle, kdy máte páku. Sjednejte proto platby až po převzetí etapy a zádržné do konce záruky, orientačně 5–10 % ceny. Smluvní pokuty za prodlení s milníky se v praxi pohybují kolem 0,05–0,2 % z ceny etapy denně, vždy se stropem (pravidlo palce). Jak převzetí provést, popisuje kapitola 20. Změnám během etapy se věnuje kapitola 18.

Autorem je vždy člověk, vy dostanete licenci

Autorem programu může být jen fyzická osoba a svá autorská práva nemůže převést Zákon č. 121/2000 Sb.. Firma i objednatel mohou vykonávat majetková práva nebo získat licenci k užití díla. Do smlouvy proto nepište „převod vlastnictví“, ale licenci a její rozsah. Anglo-americké vzory typu „work made for hire“ v českém právu fungovat nemusí.

Chráněný je kód, ne myšlenka, algoritmus ani funkce (§ 65 autorského zákona). Rozhoduje tedy, co smíte s konkrétním kódem dělat.

Past § 58 odst. 7: freelancer ano, firma ne

Zákon říká, že program vytvořený na objednávku se považuje za zaměstnanecké dílo a objednatel za zaměstnavatele. Zní to, jako by práva vykonával automaticky objednatel. Podle převažujícího výkladu odborné literatury to ale platí jen tehdy, když smlouvu uzavíráte přímo s autorem, tedy s fyzickou osobou epravo.cz, 2009. Když dodává firma, práva vykonává ona a vy potřebujete licenci nebo postoupení výkonu majetkových práv.

Judikatura Nejvyššího soudu, která by otázku rozhodla, dohledaná není. Na výklad se proto nespoléhejte ani u freelancera a licenci sjednejte vždy.

Vývoj na zakázku se obvykle sjednává smlouvou o dílo. Sama o sobě vám ale práva k úpravám nedá: bez výslovné licence se má za to, že vám dodavatel dílo poskytl k účelu vyplývajícímu ze smlouvy § 2634 OZ. Systém tedy smíte používat, ale ne nechat upravit jinou firmou. Tady začíná většina závislostí na dodavateli (kapitola 24).

Jak široká má licence být

Licence má být:

• výhradní, územně a časově neomezená, ke všem způsobům užití, i po skončení smlouvy,
• s právem upravovat a spojovat s jinými díly, i prostřednictvím jiné firmy,
• s právem podlicence a postoupení, třeba dalšímu dodavateli rozvoje,
• zaplacená v ceně díla, s prohlášením dodavatele, že si potřebná práva zajistil od všech autorů i subdodavatelů.

Výhradní licence se obvykle týká jen částí vytvořených pro vás. K dřívějším komponentám dodavatele a k součástem třetích stran dostanete nevýhradní licenci, rozsah obou nechte vymezit advokátem. Varovný signál: „licence se řídí našimi obchodními podmínkami“ nebo „licenci vyřešíme později“. Celý výčet najdete v kontrolním seznamu na konci kapitoly.

Kód, dokumentace a data průběžně, ne na konci

Kód s build skripty a dokumentací chtějte po každém sprintu ve vašem repozitáři. Test je jednoduchý: dokáže jiná firma z dodaných podkladů systém sestavit, nasadit a změnit? Dokumentaci zahrňte do podmínek převzetí. Bez ní dodávka není připravená k fakturaci.

Úschova kódu (escrow) se hodí pro části, ke kterým kód přímo nedostanete, typicky pro vlastní komponenty dodavatele. Kód se vydá při smluvně určených událostech, třeba při úpadku, ukončení činnosti nebo dlouhodobém neplnění. Uložený kód bez licence k úpravám a bez dokumentace bývá zastaralý a nepoužitelný.

K datům chtějte bezplatný přístup kdykoli, v otevřeném a strojově čitelném formátu. Důsledky opačného přístupu ukázal NKÚ: ministerstvo by za vlastní data ze svého systému muselo zaplatit dodavateli NKÚ, KZ 17/24 (více v kapitole 24). Evropský Data Act vás u systému na míru neochrání: pravidla pro změnu poskytovatele míří na cloudové služby a u služeb vyvinutých na míru jednomu zákazníkovi se část povinností neuplatní (čl. 31).

Exit plán, převzetí a sankce sjednejte při podpisu

O rozchodu se jedná nejlíp ve chvíli, kdy jste ještě zamilovaní. Exit plán určuje, jak dodavatel pomůže s předáním systému nástupci, jak dlouho potrvá souběh, jak se převedou data a jaké budou cena a lhůty. Regulované subjekty podle zákona o kybernetické bezpečnosti mají exit strategii ve smlouvě s významným dodavatelem povinně Vyhláška č. 409/2025 Sb..

Sjednejte převzetí po etapách, pevné lhůty pro obě strany a klasifikaci vad. Pokuty nastavte přiměřeně a se stropem; nepřiměřenou pokutu může soud snížit (§ 2051 občanského zákoníku). Vymezte také své povinnosti při spolupráci. Pokud je nesplníte včas, může se posunout i termín dodavatele. Jednostranná smlouva se nevyplatí: soutěž na digitalizaci stavebního řízení ÚOHS zrušil mimo jiné kvůli chybějícím lhůtám převzetí ÚOHS, S0321/2023 (kapitola 12).

Kód od AI a open source komponenty

Městský soud v Praze uvedl, že obrázek vytvořený AI není autorské dílo, protože nejde o výsledek tvůrčí činnosti člověka MS Praha, 10 C 13/2023. Šlo o grafiku a o úvahu soudu prvního stupně. Podobná argumentace se ale může týkat i kódu: čistě vygenerovaný kód nemusí být chráněný a výlučnost k němu nemáte. Kód, který člověk tvůrčím způsobem upraví, chráněný být může.

Do smlouvy proto patří pravidla pro AI a soupis všech komponent a jejich licencí (SBOM). Prověřte zejména „virální“ licence, které by vás mohly zavazovat ke zveřejnění i vašeho kódu.

Stanovisko OHA si řekněte před soutěží

Při pořízení nebo architektonické změně určeného informačního systému nesmí úřad projekt uskutečnit bez souhlasného stanoviska DIA, případně rozhodnutí vlády. Povinnost „již není vázána na žádný finanční limit“ DIA, Schvalování OHA. Určený je systém, který využívá základní registry nebo jim poskytuje služby, má na takový systém vazbu, nebo slouží aspoň 5 000 uživatelům ročně se zaručenou identitou Zákon č. 365/2000 Sb..

Ústřední správní úřady navíc informují OHA o výdajích na ICT nad 20 mil. Kč podle usnesení vlády č. 86/2020 DIA, Schvalování OHA. Stanovisko přijde zpravidla do 30 dnů, u složitých žádostí do 60 dnů, a žádost musíte od jejího založení v ISDŘ dokončit a podat do 90 dnů DIA, ISSS 2026. Nejčastější chyba: žádost až po vypsání zakázky.

Díl státní skládačky, ne samostatný dům

OHA posuzuje soulad s Informační koncepcí ČR a národní architekturou. V praxi to znamená, že váš systém musí zapadat mezi ostatní systémy státu. Má využívat sdílené služby, například registry a elektronickou identitu, místo aby si vytvářel vlastní kopie. Právě to NKÚ vytkl: 2 923 z 5 118 agendových systémů si vytváří lokální kopie údajů ze základních registrů NKÚ, KZ 23/05. Architekta úřadu přizvěte k zadání od prvního dne.

Rozpočet plánujte na celou dobu životnosti systému včetně provozu. Vyžaduje to zásada 3E, od 1. 1. 2027 v zákoně č. 231/2025 Sb. Zákon č. 231/2025 Sb. (kapitola 5).

Druh řízení podle limitu a jasnosti zadání

Limit určí, jak přísný postup musíte použít. Podle jasnosti zadání pak vyberete vhodný postup z těch, které zákon umožňuje:

• jasné zadání: otevřené řízení, u menších zakázek zjednodušené podlimitní,
• nejasné řešení: jednací řízení s uveřejněním nebo soutěžní dialog,
• velký modulární systém: rámcová dohoda s více dodavateli a minitendry (kapitola 10).

Úvodní analýzu můžete zadat zvlášť jako malou zakázku a výsledky použít v další soutěži. Pozor ale na zákaz dělení zakázky (§ 35 ZZVZ).

Částky podle zákona o zadávání veřejných zakázek a nařízení vlády č. 541/2025 Sb. ZZVZ a NV č. 541/2025 Sb..

JŘBU nezachrání, když jste si závislost způsobili sami

Jednací řízení bez uveřejnění kvůli výhradním právům obstojí jen tehdy, když výlučnost objektivně existuje a zadavatel ji sám nezpůsobil NSS, 5 Afs 42/2012. Soudní dvůr EU v roce 2025 dodal, že za výlučnost odpovídá zadavatel i tehdy, když měl „skutečné a z finančního hlediska přiměřené prostředky“ ji ukončit SDEU, C-578/23. Šlo o daňový systém ADIS, za který ÚOHS v květnu 2026 pravomocně uložil pokutu (kapitola 24).

Stejně neobstojí krajní naléhavost, kterou si zadavatel způsobil sám. Jak tomu předejít? Zajistěte si práva a kód už v první smlouvě (kapitola 11). U starého systému dokumentujte kroky k ukončení závislosti a soutěž připravte včas.

Zadávací podmínky musí obstát před námitkami

Nejasné nebo nesplnitelné podmínky mohou vést k námitkám a následně k řízení před ÚOHS. Proti zadávacím podmínkám může dodavatel podat námitky až do konce lhůty pro nabídky (§ 242 ZZVZ) a dokud o nich nerozhodnete, nesmíte uzavřít smlouvu (§ 246). Po odmítnutí námitek má 10 dnů na návrh k ÚOHS (§ 251).

Nejlépe tomu předejdete důkladnou přípravou: předběžná tržní konzultace (kapitola 8), věcné odpovědi na dotazy všem uchazečům a kvalita v hodnocení podle karet DIA (kapitola 9).

Dvanáct chyb, které se opakují

Kapitola shrnuje první dvě části návodu. U každé chyby se dozvíte, jak ji poznat a jak ji napravit. Podrobnosti jsou v kapitole, na kterou odkazuje poslední sloupec.

Chyby nejsou stejně drahé. Ty ve smlouvě se nejhůř opravují, protože po podpisu máte slabší vyjednávací pozici. Chyby v rozhodnutí a rozpočtu se zase nejdéle skrývají: projekt postupuje podle plánu, ale samotný plán vychází z chybných předpokladů. Je to jako jet podle navigace se špatně zadaným cílem. Jedete plynule a podle plánu, a že jste jinde, než jste chtěli, zjistíte až na konci cesty.

Kterou chybu opravit jako první?

Když jste v sebetestu zaškrtli víc bodů, nepostupujte jen podle jejich pořadí. Začněte těmi, které se po podpisu smlouvy napravují nejobtížněji:

• Smlouva (chyby 10–12). Licenci, předávání kódu, přístup k datům a exit plán si zajistěte před podpisem. Potom máte slabší pozici a každá změna stojí peníze.
• Vlastník produktu (chyba 2). Bez člověka, který rozhoduje, se zastaví i projekt s výborným dodavatelem.
• Cenový model a data (chyby 4 a 6). Obojí určuje, zda vůbec půjde nabídky porovnat.

Chyby ve výběru (7–9) se dají zmírnit ještě v průběhu, třeba placeným zkušebním sprintem nebo výměnou klíčových osob. A pokud vám vyšlo, že stavíte běžnou agendu (chyba 1), zastavte se úplně: nejlevnější projekt je ten, který nemusíte dělat.

Stejné chyby dělají i ministerstva

Firmy své nepovedené projekty nezveřejňují, u státu jsou dostupné výsledky kontrol. Kontrolní závěry NKÚ a rozhodnutí ÚOHS jsou proto nejlepší veřejná učebnice: chyby z tabulky může udělat i instituce s právním oddělením a stamilionovým rozpočtem. Tabulka vychází hlavně z kontrolních závěrů a rozhodnutí. Dva dobré příklady stojí na sekundárních zdrojích (článek asociace dodavatelů a právní rozbor). Podrobně případy rozebírají kapitoly v posledním sloupci.

Nejdřív problém a uživatelé, potom funkce

Zadání pro výběr dodavatele (kapitola 6) popisuje, co potřebujete a proč. Analýza s vybraným dodavatelem z něj udělá specifikaci: kdo bude systém používat, v jakých situacích a podle čeho poznáte, že funguje. Britská i australská státní správa tomu říkají discovery a vláda Nového Jižního Walesu pro ni obvykle vyhrazuje 4–8 týdnů NSW Government, 2026. U menšího a jasnějšího systému stačí kratší úvodní analýza, proto kapitola 8 uvádí rozpětí 2–8 týdnů. Výsledkem může být i rozhodnutí, že vývoj nového systému nemá smysl.

Nejčastější chyba je převést papírový formulář na obrazovku 1:1. NKÚ státu vytýká „digitalizaci na úrovni formulářů“: po investicích přes 50 mld. Kč v letech 2020–2024 bylo plně digitálních jen 18 % služeb NKÚ, 2026. Nejdřív zjednodušte proces, pak ho digitalizujte.

Mluvte s lidmi, kteří budou systém denně používat, ne jen s vedením. U digitalizace stavebního řízení vznikly požadavky podle technického auditu bez zapojení klíčových budoucích uživatelů Audit DSŘ, technická část, 2025 (jak dopadlo spuštění, popisuje kapitola 20).

Nejlevnější test je klikací prototyp. Pro první ověření ho vyzkoušejte s 5–8 lidmi z provozu. Většinu chyb v procesu tak můžete najít dřív, než vznikne první řádek kódu. Přepsat obrazovku v prototypu stojí hodiny, v hotovém systému týdny.

Každý požadavek musí jít ověřit

Podle průzkumu PMI z roku 2014 nesplnilo 47 % neúspěšných projektů své cíle kvůli špatnému řízení požadavků PMI, 2014. Jde o podíl projektů, ne organizací jako u 37 % v kapitole 6. Základní jednotkou specifikace je proto uživatelský scénář: Jako [role] chci [co], abych [proč]. K němu patří akceptační kritéria ve tvaru Dáno / Když / Pak. Dodavatel podle nich připraví testy. Při převzetí pak místo sporu o dojmy ověříte, zda systém kritéria splňuje. Scénář bez kritérií do vývoje nepouštějte.

Čísla v ukázkách jsou ilustrační, vlastní hodnoty stanovte podle počtu uživatelů a dopadu výpadku. ASVS je katalog ověřitelných bezpečnostních požadavků OWASP ASVS 5.0, 2025, lhůty hlášení incidentů stanoví zákon o kybernetické bezpečnosti Zákon č. 264/2025 Sb.. Obojí rozebírá kapitola 15.

UŽIVATELSKÝ SCÉNÁŘ
Název: [krátký název]
Jako [role uživatele]
chci [co potřebuji udělat],
abych [jaký to má přínos].

AKCEPTAČNÍ KRITÉRIA (aspoň 2)
1. Dáno [výchozí stav], když [akce], pak [očekávaný výsledek].
2. Dáno …, když …, pak …

Příklad:
Jako referent chci vidět seznam nových žádostí seřazený podle data podání,
abych je vyřídil v zákonné lhůtě.
1. Dáno: 3 nové žádosti z různých dní. Když: otevřu přehled.
   Pak: vidím je od nejstarší a u každé počet dní do konce lhůty.
2. Dáno: žádost po lhůtě. Když: otevřu přehled. Pak: je označená textem „Po lhůtě“ a červeně.

Vazba na nefunkční požadavky: [výkon, bezpečnost, přístupnost…]
Priorita (MoSCoW): Must / Should / Could / Won't
Mimo rozsah tohoto scénáře: […]
Schválil: [vlastník produktu], datum, verze

PŘIPRAVENO K VÝVOJI, KDYŽ
[ ] má roli a přínos
[ ] má aspoň 2 akceptační kritéria Dáno / Když / Pak
[ ] má uvedenou vazbu na nefunkční požadavky
[ ] má prioritu
[ ] schválil ho vlastník produktu

„Rychlý a bezpečný“ se přepíše na čísla

Nefunkční požadavky říkají, jak dobře má systém fungovat. Splnění obecných slov jako „rychlý“ nebo „spolehlivý“ těžko ověříte a vymůžete. Konkrétní hodnoty a normy vám to umožní. Do specifikace patří aspoň tyto oblasti:

MVP je nejmenší užitečná verze, ne polovina všeho

MVP je nejmenší verze, kterou skuteční uživatelé opravdu použijí. Do MVP patří jen požadavky s prioritou Must (kapitola 6). Etapy plánujte podle toho, kdy přinesou užitek: pilot na jednom pracovišti, rozšíření, plné nasazení. Krátké etapy jsou nejlepší pojistka proti prodražení, protože s každým rokem trvání překročení nákladů roste (kapitola 10).

Stejně důležité je napsat, co dodáno nebude. Seznam „mimo rozsah“ je samostatná část specifikace a podepisuje se s ní. Třeba takto:

• migrace dat starších než rok 2015,
• napojení na docházkový systém,
• mobilní aplikace (stačí web, který funguje i v telefonu),
• anglická verze.

Specifikace funguje jako objednávka ve stavebninách: co na ní není, nepřivezou, a co připíšete u pokladny, zaplatíte zvlášť. Všechno nevyjasněné se později změní ve spor o vícepráce (kapitola 18).

Kdo specifikaci schvaluje?

Za specifikaci odpovídá váš vlastník produktu. Dodavatel mu ji pomáhá formulovat a ověřit. Každý schvaluje svou část:

• scénáře, priority a MVP: vlastník produktu,
• bezpečnost, provoz a architekturu: IT, architekt a manažer kybernetické bezpečnosti,
• osobní údaje: pověřenec pro ochranu osobních údajů,
• změnu cílů, rozpočtu nebo termínu: řídicí výbor.

Schválení doložte číslem verze nebo zápisem.

Pět věcí, které musíte pohlídat

1. Převoditelnost. Kód, postup sestavení, dokumentace a práva k úpravám jsou průběžně u vás, ne „při ukončení spolupráce“ (kapitola 11).
2. Rozšířená technologie s dobou podpory. Běžný jazyk a framework, u každé klíčové součásti datum konce podpory.
3. Jednoduchá architektura z modulů. Moduly s popsanými rozhraními (API) a otevřené formáty dat.
4. Hosting s cestou ven. Účty, domény a cloud vedené na vás, plán odchodu s odhadem ceny.
5. Měřitelná bezpečnost a přístupnost. Konkrétní normy, nezávislý test a u AI zařazení podle AI Actu.

Převoditelnost řeší hlavně smlouva, další části kapitoly se věnují bodům 2–5.

Nudná technologie je výhoda

V nabídkách nejčastěji uvidíte tyto rozšířené technologie: jazyky Java (se Spring Boot), C# (.NET), Python, PHP a JavaScript nebo TypeScript s frameworky React či Next.js, databázi PostgreSQL, kontejnery Docker a Kubernetes a veřejné cloudy Azure, AWS nebo Google Cloud. Neberte to jako doporučení, jen jako orientaci. Rozšířenost je výhoda: snáze najdete vývojáře, technologie mají dlouhou podporu a systém na nich mohou převzít stovky firem. Exotická technologie, kterou u dodavatele ovládá jeden člověk, vás k němu připoutá. Data o počtu vývojářů podle jazyků v Česku neexistují, ptejte se proto dodavatele, které další české firmy technologii používají.

U každé součásti chtějte verzi a datum konce podpory. Po něm výrobce přestane vydávat opravy a čeká vás drahý přechod (kapitola 23).

Architektura: dům s pokoji, ne sídliště

Mikroslužby jsou módní, ale pro běžný firemní systém s jedním týmem spíš přítěž. Část složitosti přesouvají z vývoje do provozu a zdražují převzetí jiným dodavatelem. Poradenská firma Thoughtworks dávala „závist mikroslužeb“ v letech 2015–2018 do kategorie Hold, tedy nepoužívat Thoughtworks, 2018, a doporučuje začít dobře rozčleněným monolitem Thoughtworks, 2023.

Chtějte architektonický dokument s popisem modulů, rozhraní popsaná ve standardu OpenAPI a krátké záznamy technických rozhodnutí (ADR). Podle nich se nový dodavatel zorientuje za týdny, ne za měsíce.

U mobilní aplikace se nejdřív zeptejte, jestli ji vůbec potřebujete:

Účty v App Store a Google Play a podpisové klíče aplikace mají být vedené na vás.

Hosting: rozhoduje cesta ven, ne značka cloudu

Nezávislé srovnání cen cloudu a vlastních serverů v korunách neexistuje. Orientačně platí, že cloud se vyplatí při kolísající zátěži a malém IT týmu, vlastní provoz pak při stabilní zátěži a se stávajícím týmem. Důležitější než volba je cesta ven: aplikace v kontejnerech, standardní databáze, proprietární služby cloudu jen po zvážení důsledků, účty a domény na vás a plán odchodu s cenou.

Bezpečnost a přístupnost podle norem

Bezpečnost se dá zadat stejně přesně jako rozměry kuchyňské linky. Standard OWASP ASVS 5.0 má 345 ověřitelných požadavků ve třech úrovních OWASP ASVS 5.0, 2025. Pro běžný firemní systém se obvykle žádá úroveň 2. Shodu s ní nechte nezávisle ověřit, samotný penetrační test ji neprokáže. Penetrační test ale požadujte také, jako podmínku převzetí, spolu se seznamem všech součástí (SBOM) ke každému vydání. Selhání dodavatelského řetězce, například zranitelnost v cizí knihovně, je v žebříčku OWASP Top 10:2025 na 3. místě OWASP Top 10:2025.

Zákon o kybernetické bezpečnosti (č. 264/2025 Sb.) platí od 1. 11. 2025. Regulované subjekty musí bezpečnostní požadavky přenést do smluv s dodavateli. Systém musí zaznamenávat události tak, abyste stihli zákonné lhůty hlášení incidentů: prvotní hlášení do 24 h, oznámení do 72 h a závěrečná zpráva do 30 dnů Zákon č. 264/2025 Sb.. Které incidenty a v jakém režimu hlásíte, si ověřte s manažerem kybernetické bezpečnosti. Do února 2026 ohlásilo poskytování regulované služby 4 825 organizací NÚKIB, 2026. Ověřte, zda se povinnosti týkají i vaší organizace.

Evropské nařízení o kybernetické odolnosti (CRA) software na zakázku výslovně nevylučuje. Zda se na váš projekt vztahuje, záleží mimo jiné na tom, jestli se software „dodává na trh“ Nařízení (EU) 2024/2847. Závěr pro konkrétní projekt nechte na právníkovi (kapitola 11).

U přístupnosti platí tři vrstvy:

• Úřady ji mají povinnou podle zákona č. 99/2019 Sb. Zákon č. 99/2019 Sb.. Právní referencí je dnes norma EN 301 549 V3.2.1, tedy WCAG 2.1 AA DIA, pokyn k přístupnosti.
• Firmy ji od 28. 6. 2025 musí splnit u vyjmenovaných služeb pro spotřebitele, jako jsou e-shopy, bankovnictví nebo doprava (zákon č. 424/2023 Sb.) Zákon č. 424/2023 Sb..
• Nová norma EN 301 549 V4.1.1 přebírá WCAG 2.2 a vyšla 2. 9. 2026. Na zveřejnění v Úředním věstníku EU zatím čeká EN 301 549 V4.1.1, 2026.

Do zadání proto pište WCAG 2.2 AA W3C, WCAG 2.2, splníte současný i očekávaný stav. Plugin, který slibuje „100% přístupnost“ jedním skriptem, nestačí. Podmínkou převzetí má být audit včetně ručního testování se čtečkou obrazovky.

AI v aplikaci: zařazení a vyměnitelnost

Když má systém obsahovat umělou inteligenci, rozhodněte v zadání tři věci:

• kde přesně AI je a do jaké kategorie rizika podle AI Actu spadá,
• jak vyměníte poskytovatele modelu (vlastní mezivrstva a sada testů pro srovnání),
• že poskytovatel nesmí na vašich datech trénovat.

Podle stavu k říjnu 2026, po změně nařízením 2026/1744, platí povinnosti transparentnosti pro nové systémy od 2. 8. 2026. Patří k nim například informování lidí o tom, že mluví se strojem. AI, která rozhoduje o lidech v náboru, hodnocení nebo přístupu ke službám a úvěrům, je vysoce riziková a povinnosti pro ni platí od 2. 12. 2027 Nařízení (EU) 2026/1744. Termíny se už jednou posunuly, před podpisem smlouvy je ověřte.

Rozdíl je v tom, kdy se dozvíte špatnou zprávu

Při vodopádovém přístupu se nejdřív celý systém popíše, pak vyvine a nakonec předá. Nejvíce se zapojujete na začátku a na konci a problém se často ukáže až při převzetí. Britská vládní příručka varuje, že takhle můžete 18 měsíců stavět službu, která už neodpovídá politice, technologii ani potřebám uživatelů GDS, agilní vývoj.

Při agilním vývoji vidíte kus fungujícího softwaru po každém krátkém cyklu, orientačně každé 1–4 týdny. Rizika odhalíte brzy, musíte však průběžně rozhodovat a software zkoušet.

Pozor na agilní nálepku na vodopádu

Nejčastější past je „agilní vývoj“ s pevným dvousetstránkovým zadáním a fixní cenou. Nebo agilní smlouva bez vlastníka produktu na straně zákazníka. Česká adaptace příručky 18F říká, že když se dodavatel hlásí k agilnímu přístupu, ale každou změnu řeší dodatečnou objednávkou, „mělo by se vám v hlavě rozsvítit červené světlo“ Česko.Digital, 2022.

Agilní vývoj lze s pevným smluvním rámcem sladit čtyřmi způsoby:

1. pevný rozpočet a termín, proměnlivý rozsah,
2. platba za odpracovaný čas se stropem,
3. fixní cena za MVP, další etapy jako opce,
4. platba za převzatý přírůstek, který splní Definition of Done.

Který způsob se hodí pro váš projekt a jak nastavit cenu, rozebírá kapitola 10.

Kolik času to bude stát vás

Vlastník produktu má být váš zaměstnanec, ne člověk dodavatele Česko.Digital, 2022. Rozhoduje o prioritách, odpovídá na dotazy a přebírá hotové části. Je jako stavebník, který na stavbu chodí každý den: když chybí, zedníci buď čekají, nebo staví podle sebe. Rozhodování výborem a vlastník produktu „na 10 % vedle své práce“ jsou typické brzdy. Pevná cena vlastní řízení nenahradí: u digitalizace stavebního řízení měla smlouva pevnou cenu i termín, a přesto projekty podle právní části auditu neměly obsazené některé role předepsané metodikou ministerstva Audit DSŘ, právní část, 2025 (víc v kapitole 20).

Jmenujte vlastníka produktu ještě před podpisem smlouvy, písemně potvrďte, kolik času mu na projekt uvolníte z jiné práce, a dejte mu mandát: o čem rozhoduje sám a co musí předložit řídicímu výboru. Klíčové uživatele vyberte z lidí, kteří práci opravdu dělají, ne z těch, kteří mají zrovna volno.

Uvedené hodiny jsou orientační odhady přepočtené na 40hodinový týden, nikoli výsledky měření. U klíčových uživatelů jsou na osobu, celková zátěž je tedy několikanásobná.

Součinnost je povinnost, ne dobrá vůle. Role, hodiny a lhůty pro vaše odpovědi zapište do smlouvy a chtějte, aby dodavatel evidoval, na co od vás čeká. Hlídejte i stabilitu priorit: když se mění každý týden, klesá produktivita týmu a zvyšuje se riziko vyhoření DORA, 2024.

Od prvního dne potřebujete přístup k backlogu, repozitáři kódu a testovacímu prostředí. Jen tak vidíte skutečný stav (kapitola 17).

Co od vás tým potřebuje v každém sprintu

Agilní projekt je spíš série malých rozhodnutí než jedno velké. V každém sprintu se od vás čeká:

• seřazený backlog: co je na řadě a proč,
• rychlé odpovědi na dotazy, aby tým nečekal,
• účast vlastníka produktu a klíčových uživatelů na ukázce,
• převzetí hotové práce, nebo jasné „takhle ne“ s důvodem,
• data, přístupy a lidé z jiných útvarů, když je tým potřebuje.

Větší projekty se navíc dělí na fáze. Britská vláda jim říká discovery, alpha, beta a live: zkoumání problému, ověření řešení na prototypech, vývoj pro omezenou a později širší skupinu uživatelů a nakonec ostrý provoz GDS, agilní vývoj. Na konci každé fáze se rozhoduje, jestli pokračovat. Přesně to jsou brány hybridního modelu.

Rytmus schůzek dohodněte při podpisu

Kalendář schůzek patří do smlouvy nebo do plánu projektu, který podepisujete. Orientační plán pro dvoutýdenní sprinty:

Samotné pořádání schůzek nestačí. Jejich účastníci musí pracovat s daty a přijímat rozhodnutí. U digitalizace stavebního řízení řídicí výbory zasedaly, ale na varování technického dozoru podle auditu nikdo účinně nereagoval a pravidelný statusový reporting chyběl Audit DSŘ, technická část, 2025 (víc v kapitole 20).

Ukázka znamená běžící software, ne prezentaci

Ukázka běží ve vašem testovacím prostředí, ne na notebooku vývojáře ani v PowerPointu. Chodí na ni vlastník produktu, klíčoví uživatelé a IT, ne jen projektoví manažeři. Zrušená nebo „lokální“ ukázka je varovný signál.

Připravte si vlastní plán kontroly. Příručka 18F doporučuje kontrolovat ukazatele kvality na každé ukázce, obvykle každé dva týdny, jako součást převzetí práce 18F, 2024. Stačí jedna strana:

Co chtít vidět každý sprint:

• běžící software ve vašem testovacím prostředí,
• které scénáře jsou hotové podle Definition of Done a které ne,
• výsledky automatických testů a bezpečnostního skenu,
• otevřené vady podle závažnosti a jejich vývoj,
• aktualizovaný backlog s odhady,
• jaké podklady nebo rozhodnutí od vás dodavatel potřebuje.

Co chtít vidět každý měsíc na řídicím výboru:

• kolik procent rozpočtu je utraceno a kolik procent MVP převzato,
• odhad termínu dokončení MVP podle skutečné rychlosti týmu, ne pouze podle původního plánu,
• registr rizik a stav opatření k jejich řešení,
• změnové požadavky: schválené, zamítnuté, čekající a jejich dopad na cenu.

Přístupy od prvního dne, zapsané ve smlouvě

Bez přístupu kontrolujete jen to, co vám dodavatel sám ukáže. Chtějte:

• repozitář kódu, ideálně pod správou vaší organizace,
• nástroj na úkoly s backlogem,
• automatické sestavení a výsledky testů a skenů,
• testovací a předprodukční prostředí,
• dokumentaci a záznamy technických rozhodnutí,
• cloudové účty vedené na vás.

Česká adaptace 18F to říká přímo: všechny výstupy, od softwaru po grafické návrhy, patří zadavateli a odevzdávají se na konci každého sprintu Česko.Digital, 2022. Odpověď „přístup ke kódu nemáte z bezpečnostních důvodů“ znamená, že nemáte kontrolu.

Pár čísel, kterým rozumí každý manažer

• Hodnota: kolik scénářů jste převzali ve srovnání s plánem. Graf, kde čára hotové práce stoupá k čáře rozsahu, se jmenuje burn-up.
• Peníze: utraceno X % rozpočtu proti převzatým Y % MVP. Pokud podíl vyčerpaného rozpočtu převyšuje podíl převzatého rozsahu o 15–20 procentních bodů, je čas zasáhnout. Jde o orientační hranici.
• Kvalita: otevřené vady podle závažnosti a jejich trend.
• Prognóza: datum MVP spočítané ze skutečné rychlosti týmu.

Technický tým může sledovat i pět metrik DORA: jak často tým nasazuje, jak dlouho trvá cesta změny do provozu, jak často nasazení selže, jak rychle tým obnoví provoz a jaký podíl nasazení tvoří neplánované opravy DORA, metriky. Do detailu jim rozumět nemusíte, stačí chtít je vidět a sledovat, jestli se zlepšují.

Syndrom „z 90 % hotovo“

Když dodavatel hlásí 90 % několik měsíců po sobě, je to varovný signál, nikoli doklad pokroku. Posledních 10 % obvykle obsahuje integrace, převod dat, výkon a bezpečnost, tedy nejtěžší část. Připomíná to malíře, který má hotové všechny stěny, chybí jen strop, okna a úklid. Měřte proto převzatý rozsah, ne procenta odhadnutá dodavatelem. Orientační hranice pro eskalaci: 4–6 týdnů bez nového výsledku, který by šlo nasadit (kapitola 19).

Rozsah roste, i když to nikdo nechce

Plíživé rozrůstání rozsahu (scope creep) má obvykle obyčejné příčiny:

• nedotažená analýza a nejasné hranice rozsahu,
• více lidí s rozdílnými požadavky na straně zákazníka a chybějící vlastník produktu,
• změna legislativy během projektu,
• měnící se priority vedení. Výzkum DORA ukázal, že nestabilní priority snižují produktivitu týmu a zvyšují riziko vyhoření DORA, 2024.

Změny samy o sobě nejsou chyba. Během vývoje se vždy ukáže něco nového. Chybou jsou změny neřízené: domluvené na chodbě, neoceněné a nikde nezapsané. Každá zvlášť je drobnost, dohromady z nich vznikne etapa, kterou nikdo neobjednal. Většině příčin předejdete analýzou se seznamem toho, co v rozsahu není (kapitola 14), a jedním vlastníkem produktu (kapitola 16).

Změnové řízení: pět kroků místo „to tam ještě dejte“

Změnové řízení zní byrokraticky, ale jde jen o předem dohodnutý postup. Platí pro firmu i úřad a vejde se na jednu stranu smlouvy.

Dodržujte ještě dvě pravidla. Zaprvé, oprava vady není změna: vadu dodavatel opravuje zdarma v záruce, změnu si nechá zaplatit a smlouva má obojí jasně oddělit (kapitola 11). Zadruhé, vícepráce bez podepsaného změnového listu se neplatí. Sjednejte to ve smlouvě, pak souhlas e-mailem nebo „ústně na demu“ nestačí.

Proces se vyplatí u každého cenového modelu (kapitola 10). U fixní ceny chrání rozpočet před vícepracemi. U placení podle odpracovaného času se změna sice nefakturuje zvlášť, ale čerpá dohodnutý rozpočtový strop a posouvá termín, takže o ní má rozhodnout stejný člověk se stejnými podklady. Zpozorněte, když:

• změnových listů je hodně a každý je malý,
• vícepráce se odsouhlasují e-mailem nebo telefonem,
• nikdo neumí říct, kolik z rezervy zbývá.

ZMĚNOVÝ POŽADAVEK č.: ZP-___        Datum: ____
Kdo žádá (jméno, útvar): ____
Popis změny (co má systém dělat jinak): ____
Důvod (proč, co se stane, když to neuděláme): ____
Typ: [ ] nová funkce  [ ] úprava funkce  [ ] změna legislativy  [ ] oprava vady (není změna!)
Priorita (MoSCoW): ____

--- vyplní dodavatel (do 5 pracovních dnů) ---
Odhad pracnosti (MD) a cena (Kč bez DPH): ____
Dopad na termín (etapa, milník): ____
Dopad na jiné funkce a rizika: ____
Návrh, co z backlogu vyřadit nebo odložit: ____

--- rozhodnutí ---
[ ] schváleno  [ ] zamítnuto  [ ] odloženo do backlogu
Rozhodl (vlastník produktu / řídicí výbor), podpis, datum: ____
Čerpání rezervy po této změně (Kč a %): ____

--- jen úřad ---
Zatřídění podle § 222 odst. __ ZZVZ, odůvodnění: ____
Uveřejnění (registr smluv / profil zadavatele), datum: ____

Něco dovnitř, něco ven

Při pevném rozpočtu je hlavním nástrojem výměna požadavků. U každého změnového požadavku se ptejte, co z backlogu vypadne, aby se nová věc vešla. Funguje to jako kufr do letadla: když přibalíte boty, něco jiného zůstane doma.

Jak říct ne? Vlastník produktu potřebuje mandát a kritérium, podle kterého rozhoduje: cíl projektu a rozsah MVP. Co do MVP nepatří, neodmítá napořád, ale odkládá do backlogu na další etapu. Zpozorněte, když na rozšiřování rozsahu tlačí sám dodavatel ještě před dokončením MVP. Více práce pro dodavatele nemusí znamenat větší přínos pro vás.

Rezerva je nutná, krátké etapy jsou silnější

Rezerva není přiznání neschopnosti, ale pojistka. Orientačně počítejte s těmito hodnotami:

• dobře připravený projekt: 10–15 % rozpočtu a 15–20 % času,
• nový systém s nejasnými napojeními na jiné systémy: 20–30 % rozpočtu.

Rezervu drží zákazník, ne dodavatel, a o každém čerpání rozhoduje stejně jako o změně. U víceletého projektu nemusí stačit ani velká rezerva. Velké IT projekty překračují rozpočet v průměru o 45 % a každý rok trvání navíc zvyšuje překročení nákladů o 15 % McKinsey a Oxford, 2012. Silnější pojistkou jsou proto krátké etapy, po kterých můžete upravit plán nebo projekt ukončit. Úřad musí myslet i na smluvní možnost rezervu využít: musí ji vyhradit jako opci nebo změnu v zadávací dokumentaci.

Varovné signály přečtete i bez znalosti kódu

Signály se dají rozdělit do čtyř oblastí: čas, rozpočet, kvalita a tým. Jeden oranžový signál ještě neznamená krizi, ale je důvodem k otázce pro dodavatele. Červený už vyžaduje zásah. Nejdražší následky mívají čtyři signály: dodavatel odmítá přístup ke kódu nebo audit, „90 % hotovo“ slyšíte opakovaně, 4–6 týdnů nevidíte nic nového k nasazení a podíl vyčerpaného rozpočtu převyšuje podíl převzatého rozsahu o víc než 15–20 procentních bodů (orientační hranice).

Proč nečekat? Překročení nákladů roste s každým rokem trvání projektu (kapitola 18). Na červený signál proto reagujte do 2 týdnů (pravidlo palce), ne „až se uvidí“. Je to jako kontrolka oleje v autě: jet dál můžete, ale oprava je s každým kilometrem dražší.

Eskalační žebříček: od brzdy po výměnu dodavatele

Na problém reagujte podle jeho závažnosti. Každý další stupeň zásahu je nákladnější, proto začněte od prvního, pokud situace nevyžaduje razantnější krok.

Přeplánování neznamená jen nový termín. Je to nový plán postavený na skutečné rychlosti týmu, s menším rozsahem, kontrolními body a podpisem obou stran. Pokud tým nesplní ani další kontrolní bod, neposouvejte plán znovu. Přejděte k dalšímu stupni zásahu.

Nezávislý audit je levná pojistka proti drahému rozhodnutí naslepo. Zadejte ho někomu bez vazby na dodavatele a výsledek předložte řídicímu výboru s jasnou volbou: pokračovat s menším rozsahem, nebo zastavit. U digitalizace stavebního řízení vláda v říjnu 2024 rozhodla dosavadní systémy dál nevyvíjet a připravit novou soutěž Vláda, 16. 10. 2024. Forenzní audit přišel až potom, právní část v dubnu 2025 Audit DSŘ, právní část, 2025 a technická v srpnu 2025 Audit DSŘ, technická část, 2025, a posloužil k vyvození odpovědnosti. Lepší pořadí je opačné: nejdřív audit, pak rozhodnutí. Jak dopadlo samotné spuštění, popisuje kapitola 20.

Kdy projekt zastavit

Zastavit projekt je legitimní rozhodnutí, ne selhání. Prezident NKÚ Miloslav Kala k digitalizaci stavebního řízení v lednu 2025 v televizi řekl: „Se znalostí toho, jak to skončilo, bylo asi lepší to zastavit. Ale v ten okamžik, kdy se rozhodovalo, to tak jednoduché nebylo.“ Aktuálně.cz (ČTK), 2025

Ta druhá věta je podstatná. V krizi se rozhoduje těžko: každý den už něco stál, termín tlačí a nikdo nechce přiznat, že peníze propadly. Kritéria pro zastavení proto dohodněte předem, při startu projektu, a zapište je do plánu nebo smlouvy. V krizi pak ověříte, zda se některé z nich naplnilo.

KRITÉRIA PRO ZASTAVENÍ PROJEKTU (dohodnuto při startu)
Projekt: ____        Schválil (sponzor, řídicí výbor), datum: ____

Projekt zastavíme, nebo zásadně přeplánujeme, pokud nastane aspoň jedno:
1. ___ týdnů bez nasaditelného přírůstku (výchozí návrh: 6).
2. Čerpání rozpočtu předbíhá převzatý rozsah o víc než ___ procentních bodů (výchozí návrh: 20).
3. Odhad nákladů do dokončení přesáhne ___ % schváleného rozpočtu (doplňte sami).
4. Dodavatel odmítne nezávislý audit nebo přístup ke kódu.
5. Přestane platit business case (cíl, přínos, legislativa, priorita vedení).

Kdo kritéria vyhodnocuje a jak často: ____
Kdo rozhoduje o zastavení: ____
Co se stane při zastavení (předání kódu, dokumentace, přístupů; platby): ____

Výchozí hodnoty jsou orientační. Upravte je podle velikosti projektu.

Výměna dodavatele uprostřed projektu

Bez kódu ve vašem repozitáři, dokumentace, přístupů a licence k úpravám musí nový dodavatel začít od nuly, nebo nemůže práci vůbec převzít. Do smlouvy proto patří etapy s možností neobjednat další, exit plán a povinná součinnost při předání (kapitola 11). Předání systému podrobně popisuje kapitola 24.

Nezapomeňte ani na sankce. Smluvní pokuta, kterou nikdy neuplatníte, přestane fungovat: dodavatel ji začne brát jako formalitu. Uplatněte ji, nebo písemně zdůvodněte, proč ne. Přemrštěná pokuta zase nepomůže: nepřiměřeně vysokou smluvní pokutu může soud snížit (§ 2051 občanského zákoníku), takže ji sjednejte přiměřenou a se stropem. Evidujte i vlastní prodlení se součinností, protože posouvá termín dodavatele.

Testů je víc druhů a vy osobně děláte jen jeden

Každý druh testu hlídá něco jiného. Většinu provádí dodavatel nebo specialista. Vy si vyžádejte jejich výsledky. Uživatelské akceptační testy ale děláte vy: s klíčovými uživateli, na reálných scénářích a anonymizovaných reálných datech. Vymyšlená data neodhalí všechny problémy skutečného provozu.

Penetrační test zadejte třetí straně, ne dodavateli softwaru. Nikdo nemá zkoušet zámky, které sám montoval. Opravené nálezy z testu patří mezi podmínky převzetí.

Akceptace má tři možné výsledky

Dodavatel předá etapu s protokolem vlastních testů. Vy testujete ve sjednané lhůtě. Orientačně počítejte s 10–15 pracovními dny pro etapu a 3–5 dny pro sprint. Každou nalezenou vadu zapíšete a zařadíte do kategorie. Výsledek je jeden ze tří:

• akceptováno,
• akceptováno s výhradou: zbývají jen drobné vady, případně omezený počet závažných s termínem opravy,
• neakceptováno: dodavatel opraví a akceptace se opakuje.

Podpis akceptace má zásadní důsledky. Dodavatel může fakturovat, začne běžet záruka za jakost (pravidlo palce 12–24 měsíců) a vady se od té chvíle řeší jako reklamace, ne jako nedodělek. Část ceny, orientačně 5–10 %, si proto ponechte jako zádržné do konce záruky nebo hypercare.

Kategorie vad a jejich limity dejte do smlouvy předem. Jinak se o tom, jestli je vada „kritická“, budete přít ve chvíli, kdy dodavatel tlačí na podpis a vy na termín.

Spouštějte podle připravenosti, ne podle data

Go/no-go je rozhodnutí krátce před spuštěním: je systém připravený? Spuštění schvalte jen tehdy, když platí všechny následující podmínky:

• žádná otevřená vada A a vady B pod sjednaným limitem,
• úspěšná zkušební migrace dat,
• splněný výkonový test,
• penetrační test bez kritických nálezů,
• vyškolení uživatelé,
• připravený a vyzkoušený návrat zpět,
• schválená bezpečnost a u úřadu splněné zákonné povinnosti.

Rozhodnutí zapište i s tím, kdo ho udělal. Spouštějte postupně: nejdřív pilot s jedním útvarem nebo pobočkou, pak rozšíření. Britská vládní služba GDS pouští nové služby nejdřív omezenému okruhu uživatelů, pak všem v režimu beta a naostro až po hodnocení GDS, fáze beta. Postupným spuštěním omezíte rizika, která by se jinak dotkla všech uživatelů naráz.

Převod dat ze starého systému je samostatná část dodávky s vlastní akceptací: zkušební migrace na kopii produkčních dat, odsouhlasené počty a kontrolní součty a vyzkoušený návrat zpět (viz checklist).

Po spuštění: lidé a období zvýšené podpory

Systém je hotový, až když v něm lidé umí pracovat. Školení podle rolí dělejte krátce před spuštěním, ne tři měsíce předem, kdy lidé řadu věcí do spuštění zapomenou. Na pracovištích pomůžou superuživatelé, cvičné prostředí a krátké návody. Počítejte s dočasným poklesem produktivity a s tím, že starý postup musí opravdu skončit. NKÚ v roce 2026 upozornil, že digitalizace formulářů práci zaměstnanců úřadů zatím neurychlila, protože procesy uvnitř zůstaly ruční NKÚ, 2026.

Prvních 4–12 týdnů po spuštění (pravidlo palce) potřebujete hypercare: posílený tým dodavatele, kratší reakční doby a denní krátkou poradu nad problémy. Konec hypercare určují předem daná kritéria, třeba 2 týdny bez vady A, ne datum. Hypercare patří do smlouvy o vývoji, běžný provoz pak do smlouvy o podpoře (kapitola 21).

Reakce není vyřešení

Nejčastější trik je SLA jen na dobu reakce. Dodavatel „zareaguje“ do 15 minut, potvrdí, že hlášení přijal, samotnou chybu ale řeší týden. Smlouvu přitom neporušil. Proto chtějte u každé priority tři oddělené lhůty:

• reakce: dodavatel hlášení potvrdí a začne na něm pracovat,
• obnovení: systém zase funguje, klidně s dočasným náhradním řešením,
• vyřešení: chyba je opravená natrvalo.

Prioritu neurčuje dodavatel podle svého aktuálního vytížení. Rozhodují dopad a naléhavost podle definic v příloze smlouvy. Případný spor řeší předem domluvený eskalační postup. Rozlišujte také incident, při kterém je třeba obnovit provoz, problém, kdy hledáte příčinu opakovaných incidentů, a požadavek na změnu. Každý z nich se řeší jinak. Nové funkce do paušálu podpory nepatří, jdou přes změnové řízení a rozpočet na rozvoj (kapitola 22).

Lhůty běží jen v provozní době

Režim 8×5 pokrývá 40 hodin týdně, nonstop 24×7 celých 168 hodin, tedy 4,2× víc času. Pokud incident nahlásíte v pátek v 16:00, lhůta 4 hodin v režimu 8×5 s pracovní dobou 9–17 h skončí v pondělí ve 12:00. Víkend se nepočítá.

Častý kompromis je 24×7 jen pro P1, zbytek v 8×5. Režim odvoďte od toho, kdy systém lidé skutečně používají, a do smlouvy zahrňte možnost jeho pozdějšího zpřísnění. Potřeby se mění: základní registry vznikly pro pracovní dobu úřadů, s digitalizací služeb pro občany je potřeba nonstop provoz, a ten se ani víc než 4 roky po termínu z konce roku 2019 nepodařilo zajistit NKÚ, KZ 23/05 (kapitola 23).

Procenta dostupnosti si přepočítejte na hodiny

99 % zní skvěle, ale dovoluje až 87,6 hodiny výpadku ročně. Při 99,9 % je to asi 8 hodin a 46 minut. Vyzkoušejte si to:

Stejné procento může znamenat úplně jiný slib. Ptejte se:

• Co je výpadek? Jen úplné nefungování, nebo i odezva delší než pár sekund?
• Kdy se měří? Když se dostupnost počítá jen v provozní době 8×5, noční výpadek libovolné délky smlouvu neporuší.
• Jak často? Měsíční vyhodnocení klade na dodavatele přísnější nároky než roční. Jeden dlouhý výpadek se tak „nerozpustí“ v celoročním průměru.
• Co se z měření vyjímá? Plánované odstávky, výpadky subdodavatelů nebo sítě.
• Kdo měří? Chtějte metodiku ve smlouvě a přístup k datům monitoringu.

Pozor i na řetězení. U základních registrů mají jednotlivé části smluvně 99,9 % a víc, dohromady ale vychází garance jen 99,68 %, tedy až 28 hodin ročně, které smlouvy nepokrývají NKÚ, KZ 23/05. A dostupnost, kterou nikdo neměří, je jen přání: Ministerstvo financí si ji stanovilo jako parametr dvou projektů a pak ji neumělo vyhodnotit NKÚ, KZ 15/31.

Sankce, které bolí, a report, který čtete

Symbolické sankce a chybějící report patří k nejčastějším chybám. SLA bez nich je jako záruka na auto, kterou nikdo nevymáhá. Do smlouvy patří:

• smluvní pokuty nebo slevy z paušálu odstupňované podle priority a opakování, s právem vypovědět smlouvu při opakovaném porušení,
• měsíční report: incidenty podle priority, plnění lhůt, dostupnost, otevřené problémy, čerpané hodiny, a k tomu pravidelná schůzka,
• report jako podmínka fakturace paušálu,
• uzavření incidentu potvrzuje zákazník a opakované incidenty P1 vedou k analýze příčiny.

Ať servery provozuje dodavatel, vy, nebo veřejný cloud, administrátorské přístupy, monitoring a logy mají být dostupné vám. Bez vlastních přístupů a dat zůstáváte závislí na dodavateli (kapitola 24).

Údržba není jen oprava chyb

Software je jako auto v garáži: i když s ním nejezdíte, stárnou pneumatiky a propadá technická. Systém se nemění, ale svět kolem něj ano. Vycházejí nové verze prohlížečů a operačních systémů, objevují se zranitelnosti v knihovnách, mění se legislativa. U každé komponenty navíc sledujte konec podpory, po kterém už nedostává bezpečnostní záplaty.

Do údržby proto patří:

• opravy chyb a bezpečnostní záplaty,
• aktualizace knihoven, platforem a databází,
• přizpůsobení novým verzím prohlížečů, operačních systémů a legislativě,
• splácení technického dluhu (kapitola 23).

Aktualizujte v malých krocích, každý měsíc nebo čtvrtletí. Pokud aktualizace odkládáte roky, z drobných úprav se stane samostatný a drahý projekt. Chtějte seznam komponent a jejich verzí (SBOM) s daty konce podpory a ve smlouvě sjednejte povinnost udržovat systém na podporovaných verzích.

Záruka údržbu nenahradí. Kryje vady díla, ne přechod na novou verzi platformy. A většina peněz po spuštění nejde do oprav: údržba tvoří 40–80 % nákladů na software za celý jeho život a zhruba 60 % z ní jsou vylepšení Glass, 2002. Rozpočet „jen na opravy“ proto nestačí. Statistika počítá vylepšení do údržby, v rozpočtu níže je oddělujeme jako rozvoj.

Kolik ročně a jak to rozdělit

Výchozí odhad z kapitoly 4 platí: 10–20 % pořizovací ceny ročně na provoz a údržbu, bez nových funkcí. Jde o orientační odhad odvozený z několika kontrol NKÚ, nikoli z reprezentativního vzorku. Základní registry vycházejí na provoz asi 12 % pořizovací ceny ročně NKÚ, KZ 23/05, podpora nového systému cestovních dokladů MZV asi 8 % NKÚ, KZ 24/26. Rozvoj se procentem odhadnout nedá, spočítejte ho z roadmapy: počet člověkodnů krát sazba.

Peníze držte ve třech oddělených obálkách: provoz a podpora, údržba včetně technického dluhu, rozvoj. Když je všechno v jednom balíku, údržba vždycky prohraje s novými funkcemi. Samotné procento na technický dluh ale nestačí, vyhrazená kapacita musí směřovat k těm částem dluhu, které systém nejvíce brzdí McKinsey, 2023.

Jednou ročně projděte i licence a servery. Státní zemědělský intervenční fond zaplatil za licence SAP v letech 2016–2019 téměř 417 mil. Kč a jejich využití nesledoval NKÚ, KZ 20/07. Platit za nevyužité licence je jako platit nájem za sklad, do kterého nikdo nechodí.

Paušál, nebo objednávky?

Aby náklady na srovnatelné úpravy postupně nerostly:

• zafixujte nebo indexujte sazby podle rolí,
• chtějte u každé nabídky rozpad pracnosti podle činností a rolí,
• sledujte, kolik stojí srovnatelné změny v čase,
• trvejte na automatických testech, které zlevňují každou další změnu,
• srovnávejte s trhem celkovou cenu změny, ne jen sazbu za MD.

NKÚ u Státního zemědělského intervenčního fondu porovnáním jednotkových cen zjistil, že hlavnímu dodavateli platí násobně víc, než stojí srovnatelné služby jiných dodavatelů v resortu NKÚ, KZ 20/07. Rostoucí pracnost bez vysvětlení je měřitelný příznak technického dluhu nebo závislosti na dodavateli (kapitola 24).

Systém potřebuje vlastníka a roadmapu

Po spuštění projektový tým odchází a systém často zůstane bez jasného vlastníka. Určete na své straně vlastníka produktu, který rozhoduje o prioritách a za systém odpovídá. Vlastník udržuje roadmapu na 12–24 měsíců s prioritami podle přínosu, ne podle toho, kdo své požadavky prosazuje nejhlasitěji. Jednou ročně s dodavatelem projděte roadmapu, konce podpory komponent, licence a vytížení infrastruktury.

Myslete i na konec starého systému. Jak drahý je souběh, když starý systém nikdo nevypne, ukazuje kauza MZV v kapitole 4.

Dluh funguje jako úvěr

Technický dluh je jako nákup na kreditní kartu. Věc máte hned, ale dokud dluh nesplatíte, platíte úrok. V softwaru je zkratkou třeba chybějící test, kopírovaný kód nebo odložená aktualizace. Úrokem je dodatečný čas potřebný na každou další změnu.

Dluh sám o sobě není chyba. Vědomá zkratka kvůli termínu je legitimní rozhodnutí. Problém je dluh, o kterém nikdo neví a nikdo ho nesplácí. McKinsey úrok popisuje jako daň ze složitosti, kterou platí každý projekt. Šéfové IT velkých firem v průzkumu odhadli, že 10–20 % rozpočtu na nové produkty se místo toho spotřebuje na řešení dluhu, a 60 % z nich vnímá, že dluh za poslední 3 roky vzrostl McKinsey, 2020. Jde o odhady respondentů, nikoli přímé měření, přesto upozorňují na rozsah problému.

Jak ho poznat bez čtení kódu

Nejlepší měřítko máte ve fakturách: kolik stojí srovnatelná změna dnes a kolik před rokem. Další příznaky jsou chyby po nasazení v nesouvisejících částech, moduly, do kterých se nikdo nechce pustit, a nasazování „na víkend“. Od dodavatele chtějte v pravidelném reportu metriky DORA DORA, metriky (kapitola 17), výsledky statické analýzy kódu, pokrytí testy a stáří komponent. Nesledujte jen absolutní hodnoty, zaměřte se i na jejich vývoj v čase.

Jak dluh splácet

• Evidence: dodavatel eviduje dluh jako seznam úkolů s odhadem, kolik práce navíc jednotlivé nedostatky způsobují.
• Stálá kapacita: část každého sprintu věnujte splácení, místo jednorázové úklidové akce za několik let. Kapacitu soustřeďte tam, kde se systém nejvíce mění.
• Pravidlo skauta: kdo sahá do modulu, nechá ho o kus lepší, než ho našel.
• Smlouva: „hotovo“ znamená i testy a dokumentaci, převzetí zahrnuje kontrolu kvality kódu (kapitola 20).
• Rozpočet: splácení dluhu je položka ročního rozpočtu na údržbu (kapitola 22).

Refaktoring, přepis, nebo náhrada?

Systém se stává přežitkem, když jeho provoz a změny stojí neúměrně mnoho, technologie ztratila podporu nebo pro ni nenajdete odborníky a systém nezvládá nové požadavky, třeba nonstop provoz nebo napojení přes API. Věk sám nerozhoduje. Konec podpory platformy ale znamená povinnou a drahou migraci: Státní zemědělský intervenční fond má podporu své platformy zajištěnou jen do roku 2027 a NKÚ upozornil na riziko dalších vysokých výdajů NKÚ, KZ 20/07. U každé klíčové komponenty proto sledujte datum konce podpory a mějte plán dalšího postupu.

Náhrada po částech se odborně jmenuje strangler fig podle fíkovníku, který postupně obroste starý strom, až ho nahradí Fowler, 2004. Nový systém přebírá funkci po funkci, dokud nelze starý systém vypnout. Kroky jsou malé a vratné, přínosy vidíte průběžně a dodavatele můžete měnit po částech. Dočasně ale platíte dva systémy. Předpokladem je přístup ke starému systému, jeho rozhraní a datům (kapitola 24).

Velký přepis najednou láká, protože slibuje čistý stůl. U velkých systémů se ale ztrácí znalost uložená ve starém kódu, požadavky se mezitím mění a starý systém se musí rozvíjet souběžně. Rozsáhlá modernizace trvá roky: z 10 kritických federálních systémů, které americký kontrolní úřad označil v roce 2019, byla do února 2025 dokončena modernizace tří GAO, 2025. Plán vypnutí a rozpočet na souběh proto patří do projektu od začátku. Co se stane bez nich, ukazuje kauza MZV v kapitole 4.

Závislost na dodavateli je pravidlo, ne výjimka

Datlab Institut v českých veřejných zakázkách našel 910 vztahů úřadů a dodavatelů ve vendor lock-inu, zhruba za 8,5 mld. Kč ročně. To je asi 53 % analyzovaných výdajů státu na IT dodavatele a závislost se týká 13 z 15 ministerstev Datlab Institut, 2021. NKÚ k tomu píše, že závislost „významně zvyšuje náklady“ a vede k poklesu IT kompetencí na straně státu NKÚ, výroční zpráva 2021. Firmy mají stejný problém, jen ho nikdo neměří.

Lock-in připomíná auto, které smí servisovat jen jeden servis. Cenu si určuje on, a když chcete jinam, zjistíte, že klíče a servisní knížku má taky on. Poznáte ho podle toho, že:

• každá změna je dražší než minulá a nikdo neumí říct proč,
• soutěže na rozvoj končí jedinou nabídkou (v IT zakázkách státu na ně od roku 2017 připadá přes 20 % objemu Datlab Institut, 2021),
• dodavatel odmítá předat kód, přístupy nebo dokumentaci,
• neznáte strukturu vlastních dat,
• nikdo neví, kolik by stál přechod jinam.

Ven se jde po schodech, ne skokem

Úplná výměna dodavatele je poslední a nejdražší krok. Datlab i metodika Asociace pro veřejné zakázky doporučují začít tím nejlevnějším, co závislost zmenší AVZ, 2023:

1. dílčí převod práv nebo licence k úpravám,
2. předání kódu a dokumentace,
3. převod know-how,
4. otevření rozhraní,
5. rozdělení na moduly a jejich postupná náhrada,
6. teprve nakonec úplná výměna.

Kdy začít jednat? Podle Datlabu tehdy, když náklady natolik převyšují obdobné služby, že se ve střednědobém horizontu, třeba za 7 let, vyplatí přechod k jinému poskytovateli nebo nový systém Datlab Institut, 2021.

Exit plán sjednáte ve smlouvě (kapitola 11). V praxi ho pak udržujte aktuální: předávací balíček aktualizujte s každým vydáním a jednou ročně ho nechte vyzkoušet nezávislou stranou. Audit při předání ověřuje především to, zda lze z dodaných podkladů systém sestavit, nasadit a upravovat. Kontroluje také, zda předaný kód odpovídá verzi, která běží v provozu.

Úschova kódu je záchranná brzda, ne cesta ven

Escrow je trojstranná smlouva: dodavatel uloží kód u třetí strany a ta ho vydá při úpadku nebo dlouhodobém neplnění. Pomůže, když dodavatel zkrachuje. Když je jen drahý nebo pomalý a chcete jiného, podmínky vydání obvykle nesplníte. Ani vydaný kód nemusí být použitelný, pokud:

• se uložená verze roky neaktualizovala a neodpovídá produkci,
• nikdo neověřil, že jde sestavit,
• chybí licence k úpravám třetí osobou, dokumentace a data.

Počítejte i s tím, že dodavatelé si smluvně vyhrazují, že za části, do kterých zasáhne jiná firma, neručí. Předem proto sjednejte, že záruka zůstává v platnosti pro nedotčené části a změny jsou dohledatelné v Gitu. Hlavní pojistkou zůstává průběžné předávání kódu a práv.

Cloud: Data Act pomáhá jen napůl

Nařízení o datech se uplatňuje od 12. 9. 2025 a dává právo přejít k jinému poskytovateli cloudu v jasných lhůtách (čl. 25): výpovědní lhůta nejvýš 2 měsíce, přechod nejvýš 30 dní, při technické neproveditelnosti až 7 měsíců, a pak nejméně 30 dní na stažení dat. Do 12. 1. 2027 mohou poplatky za přechod pokrývat nejvýše přímé náklady. Poté mají odpadnout, včetně poplatků za odchozí data Data Act, čl. 29.

Platí však dvě důležitá omezení. U služeb z větší části vytvořených na míru jednomu zákazníkovi neplatí zákaz poplatků ani povinnost funkční rovnocennosti, lhůty ano (čl. 31). U systému na míru vás tak Data Act chrání jen částečně. Nejvíce pomáhá u standardních cloudových služeb, na kterých systém běží. A proprietární služby konkrétního cloudu se při odchodu stejně musí přepsat. Stavte proto z přenositelných dílů (kapitola 15) a velké přechody plánujte po 12. 1. 2027.