Michal Bláha

(Této události předcházel můj článek a Pane Babiši, zklamal jste mě. Nevěřím vám! a má následná schůzka s Andrejem Babišem)

Dnes (12.4.2016) jsem byl na schůzce na Ministerstvu financí ohledně EET a výběrového řízení na něj. Byla to schůzka, kde jsme šli poměrně hodně do detailů. Pro obecný přehled o důležitých událostech kolem EET a MF doporučuji tyto zdroje:

• Stručná historie dodávky systému EET od anonymoos
• Proč Babiš odvolal šéfa státního IT podniku podílejícího se na EET
• Novinky o Elektronické evidenci tržeb: jak má vypadat zabezpečení
• Schváleno, zakázku na systém pro EET dostane bez výběrového řízení IBM
• Systém pro EET s podmínkou: závislost na IBM musí skončit do roku 2021

Já zde uvedu detaily, které nebyly dosud (příliš) známy, které jsem se dnes dozvěděl, a které občas proložím svým komentářem.

EET je skládá (ve vnímání MF a GFŘ) ze 4 částí:

1. ADIS
2. portál finanční správy
3. certifikační autorita
4. transakční rozhraní

Kritizované a hojně citované JRBU (vybraný dodavatel bez výběrového řízení) se týka pouze bodu 1. a částečně bodu 2. Neboli – 50milionů pro IBM pokryje pouze práce v bodu 1 a část prací v bodu 2. Neboli se dá s úspěchem předpokládat, že cena implementace EET bude vyšší než 50mil. Kč. (MF sice tvrdí, že 50mil je max.částka schválená vládou a že může být nižší, představu o nákladech na zbývajících části systému nemá anebo odmítá sdělit).

Body 3. a 4. nemají zadání, není jasné kdy a zda vůbec se budou soutěžit a jakým způsobem a i plánovaný časový plán vzbuzuje (mé) obavy.

Pojďme si to rozebrat podrobněji.

1. ADIS (Automatizovaný Daňový Informační Systém)

Černá IT díra, jejichž vstup je v kapsách daňových poplatníků a výstup v kapse firmy IBM. Včera uveřejnilo GFŘ dokument, kde přiznává složitou pozici MF, resp. GFŘ vůči IBM a neochotě IBM na změnu smlouvy.

Kompletní technologický a právní vendor lock-in IBM

Technologický vendor lock-in je realizován rozsahem systému jako takového a zejména pak dominancí prostředí 4GL a proprietárních komponent 4GL,v kombinaci s jejich propojením na ostatní minoritní technologie bez odpovídající dokumentace (procesní model, dokumentace kódu) Nový vývoj ve 4GL ve světě ani v ČR neprobíhá, a toto vývojové prostředí je ve vegetativním stádiu.
Na otázku „Zkoumalo GFŘ právní možnost předání kódu IS ADIS vytvořeného 4GL třetímu subjektu, který by provedl jeho konverzi/ re-engeneering a odladění např. v jazyku JAVA? Je to možné vzhledem k právům IBM s.r.o.? Musí GFŘ disponovat souhlasem IBM s.r.o.?“ Odpovědělo GFŘ: „Ano“. V roce 2015 zkoumáno a prověřováno. Závěr je, že GFŘ může mít kód pouze pro vlastní použití a IBM nechce udělit právo disponovat s kódem 3. osobě / jinému subjektu.“
IBM s.r.o. na otázku „Jaká konkrétní opatření udělalo, dělá a plánuje udělat vedení projektu ADIS, aby zamezilo vzniku vendor lock-in?“ odpověděla „Toto je otázka na objednavatele systému ADIS“.

MF tvrdí, že cenu a smluvní podmínky implementace změn ADIS kvůli EET zatím nezná, zatím s IBM vyjednává, ale že smlouva bude veřejná. Dále, že by náklady na provoz, support a infolinku ADIS neměly vzrůst. Finální smlouva s IBM ukáže, zde tomu tak skutečně bude.

Popis změn, které má IBM provádět, a zadání JŘBU přislíbil p. Fridrich z GFŘ poslat na můj email obratem. Pak se rád podělím.

Můj názor v této věci je, že JŘBU není možné v tomto případě využít, protože se jedná o doplnění nové funkčnosti k ADISu a nikoliv údržbu či obvyklou úpravu stávající funkčnosti, a tudíž mělo GFŘ postupovat cestou otevřeného VŘ. Uvidíme zda a jak se k tomu vyjádří ÚOHS. Na schůzce jsme tuto právní otázku neřešili.

2. portál finanční správy

Portál veřejné správy je částečně spravován a vyvíjen IBM (EPO) a inhouse v GFŘ ve spolupráci s firmou Internet Projekt.  Součástí portálu jsou daňové informační schránky, přes které mohou koukat firmy na části daň.spisu. Data z EET jako přehledový report zde skončí také.

3.  Certifikační autorita

Bude mít na starosti vydávání, rušení a ověřování certifikátů, nad kterými bude postavena autorizace a autentizace pokladních systémů a plátců daní.

4. Transakční rozhraní

V podstatě veřejné API, se kterým budou pokladní systémy komunikovat a na které jsou kladeny nároky na rychlost odezvy.

 

A kolem bodu 3. a 4. se to taky pěkně zamotává.

• Body 3. a 4. bude GFŘ poptávat po SPCSS (přes původní, opakované tvrzení, že budou soutěženy otevřenou soutěží). Existuje smlouva mezi GFŘ a SPCSS s popisy procesů a požadovanými parametry na systém, které bych měl také dostat.
• Definici transakčního rozhraní (API) má dodat IBM a to po uzavření JŘBU a podepsání smlouvy (očekáváno k 1.5.2016). Současně chce MF uveřejnit popis API do 30 dnů po uveřejnění zákona o EET ve sbírce (tzn. k 12.5.2016). Takže IBM bude mít 12 dní na dodání (draft již existuje, víceméně se čeká na validaci ze strany IBM)
• K 1.7. by GFŘ rádo uveřejnilo testovací API pro třetí strany. To nebude postaveno nad kódem od IBM a nebude mít plnou funkčnost finálního API (třeba ukládání vložených testovacích účtenek)
•  Teprve po 12.5. může SPCSS vypsat VŘ na dodavatele API a certifikační autority. Obvyklá doba otevřeného VŘ na MF je 3-4 měsíce (pokud ho nikdo nenapadne), takže dodavatel bude vybrán k +- 1.9.2016.
• EET má být spuštěno 1.12.2016, takže dodavatelé API a CA budou mít na vývoj, testování a nasazení 3 měsíce.
• Na schůzce nebyl nikdo z SPCSS  a tak nikdo nechtěl říci ani naznačit, zda se body 3. a 4. budou dělat v SPCSS inhouse (“samozřejmě” s podporou nevysoutěženého subdodavatele – můj komentář) či se budou soutěžit. (vsadíme se, po výše uvedeném, jak to dopadne? 😉 ). Byla mi přislíbena schůzka s lidma z SPCSS, tak snad se dozvím více podrobností,

 

Celá diskuze ohledně časového plánu byla velmi zmatečná a termíny a postupy se během diskuze různě měnily, takže nemohu vyloučit, že finální plán GFŘ bude jiný, ale tohle je poslední a nejsrozumitelnější verze, kterou jsme na schůzce diskutovali a která byla opatrně potvrzena.

Michal Špaček se mimojiné ptal, zda MF či GFŘ zvažuje část či celý systém EET uveřejnit jako open source. Otázku nikdo nečekal, ale pánové z GFŘ to nevyloučili (což by bylo skvělé). Pánové Sagl a Janáček z MF byli striktně proti (s obvyklým postojem security through obscurity). Bohužel už nebyl čas otázku diskutovat do větší hloubky, ale ostrý nesouhlas IT lidí z MF byl zřetelně cítit. Změna tohoto postoje je velký mentální kotrmelec a trochu se bojím, že nastane až s generační změnou v IT ve státní správě.

 

PS: Schůzky se zůčastnili (po celou nebo část doby) tyto osoby:

Ministr Andrej Babiš (uvedl schůzku a asi za 20 min musel odejít)
Michal Špaček – bezpečnost
Já 😉
Ing. Jiří Fridrich – ředitel sekce informatiky GFŘ
Ing. Martin Janeček – generální ředitel GFŘ
Dipl.-Ing. Miroslav Hejna – náměstek sekce informační a komunikační technologie MF (odešel asi po 20 min)
Karel Sagl – zaměstnanec odd. Kybernetická bezpečnost a strategické řízení ICT resortu (MF)
Viktor Janáček – ředitel odboru Provoz ICT a uživatelská podpora
následně dorazil Ing. Jan Áčko – vedoucí odd. Státní pokladna, kvůli zmanipulovanému VŘ.