Foto: iStockphoto.com

Jak se rodí zakázka na státní e-shop za 400 milionů? A proč je hackathon zlý pán?

Stát chytřekomentář 7 a více min čtení

Zakázka pro systém dálničních známek za 401 milionů korun přes týden hýbala mediálním prostředím. Skoro se zdá, že problém rychle a elegantně vyřešil hackathon obsazený partou nadšených specialistů. Jenže to tak není. Proč vlastně?

Líbí se vám článek? Sdílejte ho:

Zakázka pro systém dálničních známek za 401 milionů korun přes týden hýbala mediálním prostředím. Skoro se zdá, že problém rychle a elegantně vyřešil hackathon obsazený partou nadšených specialistů. Jenže to tak není. Proč vlastně?

Související článek

Dvanáct nejzajímavějších rozhovorů Světa chytře v roce 2019

V roce 2019 jsme vám přinesli přes šedesát původních rozhovorů s vědeckými, průmyslovými i politickými špičkami Česka i zahraničí. Věnovali jsme se v nich digitalizaci společnosti, nastupující síti 5G, umělé inteligenci, životu v chytrých městech, projektům spojených s vesmírem, ekologií, robotice nebo 3D tisku. Nechybělo ani téma vznik a šíření fake news. Připomínáme rozhovory, které by byla škoda minout.

Než se dostanu k populární IT zakázce na realizaci systému Elektronických dálničních známek (EDAZ), podělím se s vámi o jeden svůj sen. V tom snu vystupuje stát, který si nemyslí, že snědl veškerou moudrost světa. Otevřeně konzultuje s širokou odbornou veřejností své záměry hned, jak se záměr objeví. Výsledkem jeho činnosti je, že své IT systémy tvoří s lehkostí, sebevědomím, ale i pokorou. Pojďme k tomu, proč je IT ve státní správě nemocné (ano, v ojedinělých případech má jen rýmičku), přičemž právě na EDAZ je možné pár takových příznaků dlouhodobé nemoci demonstrovat.

Kdo a proč to vymyslel?

Aby to bylo lépe pochopitelné, ukážu přístup státu na příkladu, který je hypotetický, lehce extrémní, ale o to víc vám bude bližší.

Představte si následující situaci. Stát identifikuje potřebu: „Potřebujeme v obydlených částech měst, zejména v okolí škol, snížit rychlost aut.“ Stát je zvyklý, že se to musí řešit standardní cestou. Takže rozjede mašinerii a zadá přípravu projektu nějakým expertům, ať už interním, nebo najatým z úzkého okruhu. Kde se berou tihle experti, nechme teď stranou.

Experti dají hlavy dohromady a notně posilněni (či omezeni?) tím, že musí dodržet 116 různých norem a nařízení, vymyslí následující způsob řešení:

  • Každý řidič si povinně nechá namontovat GPS modul a jednotku, která dokáže omezit rychlost vozidla na základě jeho polohy.
  • Do ministerské mapy se zanesou souřadnice míst, kde se bude jezdit pomalu.
  • Řidiči, kteří si to nenechají namontovat, budou platit vyšší silniční daň.

Problém vyřešen. Jde se na oslovení dodavatelů. Cena vyjde na lidových 80 miliard korun. A aby byla jistota, potvrdí ji znalec.

Kde je problém? Mo(u)dří již vědí. Jenže mašina už jede, musí se plnit volební programy, takže se zakázka realizuje. Zpomalování aut ve městech naštěstí není IT zakázka, takže si každý dokáže představit, že to lze řešit i mnohem jednodušeji: Zpomalovacími příčnými pruhy za pár korun! Bohužel v IT to tak přímočaré není. Platí to i v případě zakázky na EDAZ s cenou 401 milionů Kč bez DPH.

Související článek

Operátor ICT otevřel svůj kód. Pražská firma chce inspirovat další města (nejen) v Česku

Údaje o pohybu vozidel, chodců i cyklistů. Data o hromadné dopravě, spotřebě energie veřejného osvětlení nebo kvalitě vzduchu. Zjistit velmi detailní data o Praze, jejích obyvatelích i návštěvnících už dávno není problém. Metropolitní společnost Operátor ICT, která to má v popisu práce, ovšem donedávna svazoval fakt, že při zpracování dat musela používat externí software. To práci jejích lidí komplikovalo a zdražovalo. Přišlo proto rozhodnutí vyvinout systém vlastní. A maximálně otevřený.

Problém první: rychlé soudy

„E-shop za 401 milionů? Předražený! To je zase tunel.“ To je snad nejcitovanější věta za poslední dva týdny. Většina lidí vyřkla tento soud prakticky okamžitě. Bez znalosti zadání. Je to i pochopitelné. Zkuste poručit vlastní intuici, která se v IT pohybuje dvacet a více let. To jde těžko. Navíc zkratky jsou příjemnější, na klávesnici se rychleji píšou, tak proč se nepřidat. Námaha nulová, efekt veliký.

Snažme se na tyto myšlenkové zkratky nenaskakovat. Mysleme na to, že když SFDI řešil zakázku, dával si určitě velký pozor na to, aby tu částku byl schopen vyargumentovat. Ideálně s podporou znalce. Vypadá to spíš na problém IT komunity než SFDI.

Problém druhý: Co je a co není zadání

SFDI pár dnů po vypuknutí aféry „E-shop za 400“ začal zveřejňovat dokumenty k této zakázce. Kromě smluv (se začerněnými přílohami) se k odborné veřejnosti nakonec dostal i materiál z pera Centra dopravních informačních systémů Ministerstva dopravy ČR (CENDIS), který má název: Požadavky objednatele – zadání na IS EDAZ (252 stránek). K čemu tento dokument slouží?

Když to zjednoduším a polidštím, tak každý informační systém by měl být postupně popsán v několika fázích:

  1. Ideový návrh – popis toho, čeho chci systémem dosáhnout, jak si představuju, že by to mohlo fungovat, proč ho chci.
  2. Věcný rámcový záměr – tohle už je konkrétnější popis, jaké všechny funkce by systém měl mít (např. nákup známek, kontrola aut kamerami, administrace obsahu portálu) a co vše celé řešení bude zahrnovat (nákup hardwaru, servis, dohled, call-centrum apod.).
  3. Požadavky na systém – podrobný a strukturovaný popis jednotlivých funkcí, procesů, uživatelských rolí, požadavků na propojení a tuny dalších informací; je často psán takovou řečí, které rozumí jak zadavatel, tak už i budoucí dodavatel a naznačuje už celkem solidně celkový rozsah.
  4. Zadávací dokumentace – každý jednotlivý požadavek z předchozího bodu vstupuje jednak do kontextu celé aplikace (drátové modely, závislosti, omezení, procesy, dema apod.) a jednak se k nim definují technické parametry.
  5. Technická analýza – čistě technický podklad pro programátory a vývojáře. Datový model, metody, popis rozhraní (API), testovací scénáře, řešení výkonu a rozkládání zátěže...
  6. Servisní podpora a rozvoj – toto je řešeno v předchozích bodech, ale je to natolik důležité, že tomu přiděluji vlastní bod; co se bude s aplikací dít po spuštění, jak se bude rozvíjet, udržovat, zálohovat a jak to všechno musí pokrýt dodavatel.

Všimněte si, že od prvního bodu dál se jde víc a víc do detailu, roste komplexita, ale zároveň klesá srozumitelnost pro běžného smrtelníka. Co z toho plyne? Většina lidí reagovala na přemrštěnou cenu již ve fázi, kdy byl dostupný pouze věcný záměr (v podobě smlouvy mezi EDAZ a dodavatelem). V této fázi může odhadovaná cena lítat od - 90 % do + 1000 %. „Chtějí kolo, nebo Jumbo Jet? Záměr splní oboje, ale za Jumbo dostaneme víc.“

Související článek

Soukromí s aplikacemi v mobilu je iluze. Nejsme anonymní tečky na mapě, ukázal projekt New York Times

Kde bydlíte? Kde pracujete? V kolik a kam vodíte svoje děti do školy, na kroužky? Kde jste byli minulý víkend v restauraci? Jak dlouho? A kdo tam byl s vámi? Otázky pro Velkého Bratra? Ale vůbec ne. Pro téměř libovolnou firmu stojící za vámi používanou aplikací otázky, na které snadno dokáže získat odpověď. Platí to pro vás i Arnolda Schwarzeneggera. Jak je to jednoduché, ukázal investigativní seriál deníku New York Times.

Chce-li zadavatel získat alespoň trochu relevantní cenu za výrobu, musí předložit dodavatelům úplné a podrobné požadavky (bod 3). V ideálním případě plnohodnotnou zadávací dokumentaci (bod 4). Zadávací dokumentace je často projekt sám o sobě, který mnohdy realizuje někdo jiný než ten, kdo pak systém vyrábí. Zde se z dostupných zdrojů můžeme domnívat, že v případě EDAZ dodavatelé naceňovali dílo na základě bodu 3. Což není vyloženě chyba, ale nutí to dodavatele nechávat si velkou rezervu (klidně i 50 %), protože moc dobře ví, že ďábel je ukryt v detailu. A detaily se řeší až v tzv. zadávačce.

Ještě poznámka k Požadavkům objednatele na EDAZ. Pokud vezmu za bernou minci to, že ty požadavky přesně, úplně a beze zbytku (!) pokrývají reálné požadavky objednatele, lze prohlásit, že jsou zpracovány docela dobře. Poskytnou ucelený obrázek o tom, s jakým rozsahem a s čím vším se bude muset dodavatel při realizaci poprat. Detaily nehledejte, jsou to požadavky, nikoliv zadání.

Problém třetí: Hackathon je dobrý sluha, ale zlý pán

Druhou nejčastěji zmiňovanou větou posledních dní bylo: „E-shop, který stát vysoutěžil za 401 milionů, naprogramovalo šedesát lidí za víkend. Zadarmo!“ Řekněme si na rovinu, že to byl husarský kousek. Úžasná akce, skvělá atmosféra a tolik entuziasmu, že by se dal krájet. Dobře. Co ale ve skutečnosti vzniklo? Vznikl plus minus funkční produkt (ferznamka.cz), který pokrývá věcný rámcový záměr zadavatele (bod 2 výše). Můžeme tomu též říkat Proof of Concept (PoC). Funkční řešení, které ukáže cestu k finálnímu a robustnímu řešení. Upřímně opakuji, je to na potlesk na otevřené scéně. Zorganizovat tolik programátorských hlav je kumšt. Něco o tom vím.

Související článek

Video: Piloti v roli diváků. Airbus do vzduchu poslal letadlo, které odstartovalo zcela samo

Autonomní auta bez řidičů dnes už nepřekvapí. Výrobce letadel Airbus ale vyvinul systém, který dokáže do vzduchu bez zásahu pilota poslat i obří dopravní letadlo. Francouzská firma ve vývoji hodlá dál pokračovat. Cílem je, aby její letoun mohl také autonomně přistávat a pohybovat se letové ploše.

Jenže, musíme si nalít čistého vína. Mezi oběma břehy, tedy mezi PoC a finálním produktem, může protékat potůček, který hravě překročíte, nebo taky rozbouřená řeka, která vám dá ještě pěkně zabrat. Závěr je jednoduchý: E-shop z hackathonu není totéž, co poptával stát. E-shop z hackathonu je PoC odpovídající věcnému záměru zadavatele.

Poučení z krizového vývoje místo závěru

Buďme rádi, že to proběhlo tak, jak to proběhlo. Zachránilo se (zatím) 401 milionů. Zakázka je navíc teď tak pěkně nasvícena, že si nikdo z úředníků ani budoucích dodavatelů nedovolí udělat cokoliv špatně. Takže co bychom si měli z této lapálie odnést?

  1. Stát udělal chybu hned na začátku. Není zvyklý každý svůj záměr konzultovat s širší odbornou veřejností. Stát na takový postup není stavěný. Proč? Kromě jiného proto, protože jakmile by to začal dělat, komunita (tedy v tom případě už se nebavíme o komunitě, ale o jednotlivých dodavatelích) by za to chtěla zaplatit. Nic mu ale nebrání se o to alespoň pokusit.
  2. Hackathon rozsvítil světlo na čelovce a významně s ní ukazuje směr, kudy by se měly ubírat státní IT zakázky. Ne, nebudou se od teď dělat systémy zadarmo přes víkend. Hackathon ale velmi dobře ukázal způsob, jak nad nimi přemýšlet.
  3. Zatím zůstává nejasné, jestli požadavky státu na EDAZ jsou adekvátní, či „trochu přehnané“, a zda jeho původní záměr bylo nutné řešit právě takto.

Posledním bodem se dostáváme zpět k úvodu a k našim zpomalovacím pruhům. Lze řešit problém jednodušeji? Je dost dobře možné, že hackathon ukázal, že to jde. Naznačil, co vše lze ze systému osekat, vypustit, zjednodušit a jak to celé postavit za zlomek ceny. Možná ukázal, že stát s požadavky přestřelil. Jenže kdo si to vezme na triko, dodělá to a bude čtyři roky provozovat?

Související článek

Na začínající podnikatele čeká přes tři miliony korun. Startuje 10. ročník soutěže T-Mobile Rozjezdy

Už podesáté přijímá T-Mobile přihlášky začínajících podnikatelů do soutěže T-Mobile Rozjezdy. Odborná porota rozdělí mezi až čtyřicet dva podnikatelských nápadů ceny v celkové hodnotě více než 3,25 milionu Kč. Nově vyhlásí T-Mobile speciální Cenu za technologické řešení a Cenu za odpovědné podnikání. Přihlašovat se lze do 24. února.

Jediným subjektem, který to dokáže posoudit, je zadavatel. Tedy stát. To on se pak bude zodpovídat svým občanům. Nezbývá teď tedy nic jiného, než se vrátit k původnímu věcnému záměru a požadavkům a podrobit je revizi. Teď už je jasné, že by se do toho stát měl pustit ve spolupráci s širší komunitou. Sice to bude stát nemálo energie, ale jenom tak je možné se přiblížit k cíli. A tím je dobře fungující, nepřeplácaný a férově vytvořený systém, postavený na otevřených technologiích.

Líbí se vám článek? Sdílejte ho:
link odkaz
Reklama