Byla soutěž na úpravu NENu v souladu se zákonem?

14.09.2016 22:36

Úřad pro ochranu hospodářské soutěže na základně podnětu firmy QCM, s.r.o. zkoumá, zdali zakázka na aktualizaci NENu, která byla přidělena napřímo firmě DEZADATA Group za cenu bezmála 50 mil Kč byla provedena v souladu se zákonem. UOHS ustanovil soudního znalce, který má najít odpověď na 11 otázek, což by mělo pomoci UOHS vynést verdikt o zastavení plnění smlouvy. Protože jsme přesvědčení, že máme k tématu co říci, nabízíme publiku naše odpovědi na položené otázky:

 

 

  1. Jsou v popisu stávajícího stavu uvedeného v zadávacích podmínkách informace, na základě kterých si uchazeči mohou učinit představu o požadavcích na předmět plnění v detailu nezbytném pro jeho nacenění?

Vzhledem k tomu, že Ministerstvo pro místní rozvoj poptává modifikaci stávajícího systému, zadávací dokumentace neposkytuje dostatek informací pro nacenění náročnosti úprav. V zadávací dokumentaci se nevyskytuje například:

  1. Technická specifikace NEN v 3.2, kterou zadavatel požaduje aktualizovat
  2. Není jasné, co z požadovaných funkcí popsaných v kapitole 3.2 Přílohy č. 1 smlouvy již ve stávajícím NENu existuje a v jakém rozsahu
  3. V kapitolách 3.3.1 až 3.3.5.9 jsou požadavky na architekturu díla, ale není jasné, co z těchto požadavků již plní stávající řešení a co bude muset udělat dodavatel zakázky
  4. V článku 3.3.5.5 požaduje zadavatel vypracování dokumentace a pravidla řízení kontinuity činnosti systému. Není však jasné v jaké stavu je tato dokumentace zpracována pro stávající systém a kolik práce bude její aktualizace na modifikovaný systém.
  5. Zadavatel v článku 3.3.5.8 Přílohy č. 1 smlouvy požaduje realizovat integraci na dohledové nástroje, ale zadavatel neposkytl specifikaci dohledových nástrojů (není tedy jasné s čím bude integrace probíhat a zdali je vůbec možná), není rovněž jasné jaký rozsah integrace zadavatel požaduje
  6. Zadavatel požaduje v článku 3.5.1 použití služeb Identity a Access Managementu, nicméně chybí specifikace těchto služeb
  7. Zadavatel požaduje v odstavci 3.8.9.3 Přílohy č. 1 smlouvy Bezpečnostní dokumentaci a Systémovou příručku. Aby mohl zadavatel navázat na stávající dokumentaci, musí ji zná.
  8. Zadavatel požaduje zpracování služeb EXITu dle kapitoly 4.2 Přílohy č. 1 Návrhu smlouvy, ale vzhledem k tomu, že úprava systému navazuje na stávající systém, bude i práce na službě EXITu pouze rozšířením stávající dokumentace
  9. V části 5, Přílohy č. 1 smlouvy zadavatel deklaruje zpřístupnění technické specifikace NENu pouze vítěznému uchazeči. Vzhledem k tomu, že zadavatel předpokládá, že veřejná zakázka je na rozšíření původního systému (viz otázka č. 4) je znemožněno jakémukoliv uchazeči, mimo původního zhotovitele, znát specifikace stávajícího systému a tím si udělat představu o náročnosti požadovaných úprav.

Kapitola  “3 Požadavky na Systém” přílohy č. 1 smlouvy “POŽADAVKY OBJEDATELE NA SYSTÉM A SLUŽBY” popisuje, jak by měl vypadat již upravený systém, nicméně uchazeč nemá možnost si udělat představu, které z požadovaných funkcionalit již stávající systém realizuje a které nikoli.

Uvádíme následující příklad: článek  “3.2.1.10 Validace formuláře” definuje požadavky na validaci formulářů. Stávající systém jistě obsahuje validaci dat vkládaných do formulářů. Jak moc bude zapotřebí tuto validaci rozšířit oproti stávajícímu stavu? Jak vypadá stávající stav? Jaké formuláře (nebo alespoň jejich počet) stávající systém obsahuje? Kolik na tuto úpravu bude zapotřebí člověkohodin? Uchazeč nemá možnost získat na takové otázky odpověď. Informace nejsou uvedeny ani v kapitole “2 Popis stávajícího stavu” tyto informace. Tento problém nastává obdobně pro většinu požadavků z kapitoly “3 Požadavky na Systém”.

 

  1. Jsou technické informace o zdrojových kódech, vývojovém prostředí, šablonách a technickém prostředí stávajícího systému nezbytné pro získání reálného přehledu o náročnosti poptávaného plnění?

 

Informace o stavu systému NEN a způsobu jeho vývoje jsou základní informace, které každý dodavatel potřebuje vědět. Neboť způsob vývoje a rozsah dokumentace výrazně ovlivňuje cenu za realizaci řešení.

 

Zakázka, ve které se soutěžilo zhotovení NENu (dodavatel Datasys,) obsahuje kalkulaci, kde cena vývojového prostředí (licence SW) překračuje 6 mil Kč a nezbytný HW je naceněn na bezmála 4mil Kč. Pokud by práce na NENu byly podmíněny investicí přesahující 10 mil Kč musí být tento fakt jasně v zadávací dokumentaci deklarován.

 

Není rovněž známa úroveň dokumentace zdrojových kódů což má vliv nejen na pracnost, ale i časovou náročnost studia zdrojových kódů.

 

Podrobná znalost vývojového prostředí a zdrojových kódů je pro uchazeče klíčová i z hlediska personálního zabezpečení zakázky. Uchazeč musí být schopen posoudit, zdali má dostatek lidských zdrojů s příslušnými znalostmi technologií, případně kalkulovat kolik by zabezpečení takového týmu stálo.

 

 

 

  1. Zadavatel v zadávacích podmínkách požaduje realizaci třívrstvé architektury. Odpovídá takový požadavek poptávanému předmětu plnění? Proč?

 

Požadavek na třívrstvou architekturu zůstal patrně v zadávací dokumentaci omylem z původní zadávací dokumentace na zhotovení NENu. Vzhledem k tomu, že MMR patrně požaduje úpravu stávajícího systému, musí se úpravy podřídit jeho architektuře.

 

4) Posuďte technické podmínky uvedené zadavatelem v zadávací dokumentaci veřejné zakázky a stanovte, zdali jejich souhrn směřuje k požadavku na rozšíření původního systému, nebo k požadavku na vytvoření systému nového.

 

Zadávací dokumentace v Příloze č. 1 návrhu smlouvy hovoří o předmětu zakázky takto:

Ministerstvo pro místní rozvoj (dále též jen „MMR“) poptává analýzu, aktualizaci technické specifikace NEN a implementace zákona o zadávání veřejných zakázek do IS NEN (dále jen „NEN I.“ nebo „Systém“), poskytnutí služeb podpory provozu a rozvoj Systému.“

Již z této definice je zřejmé, že MMR zamýšlí rozšiřovat stávající systém, nikoliv vytvářet a podporovat systém nový, který bude jen se stávajícím systémem komunikovat.

Dále kapitola 3, Přílohy č. 1 návrhu smlouvy hovoří o změnách vůči stávajícímu systému NEN.

Avšak v kapitole 3.1, Přílohy č. 1 návrhu smlouvy najdeme text „Nově dodaný Systém musí odpovídat požadavkům uvedených v následujících kapitolách…“

Při odpovědi na dodatečný dotaz č. 23 zadavatel vysvětluje, že předmětem díla je rozšíření stávajícího systému.

Ačkoliv zadávací dokumentace neposkytuje jednoznačné stanovisko, zdali předmětem zakázky je nový systém nebo rozšíření/úprava stávajícího, z logiky lze předpokládat, že splnění zakázky lze realizovat pouze úpravou stávajícího systému.

 

 

5) Součástí předmětu plnění je i poskytnutí služeb podpory provozu Systému a služeb rozvoje Systému. Lze ze zadávacích podmínek zjistit, jaké služby podpory a provozu budou s předmětným Systémem spojeny? Je pro zpracování nabídky nezbytná znalost rozsahu a obsahu služeb S1 – S12?

 

Vzhledem k tomu, že MMR předpokládá, že dílo bude realizováno jako rozšíření stávajícího systému NEN je naprosto nezbytné znát služby podpory a provozu. Modifikované dílo bude mít jiné parametry, takže bude potřeba definovat nově služby S1 – S12. Vybraný zhotovitel se bude muset podělit o provoz a podporu modifikovaného NENu

Je zřejmé, že služba S13, která je součástí předmětu plnění předmětné veřejné zakázky má neprázdný průnik se službami S1-S12 definovanými ve smlouvě na zajištění provozu NEN (tzn. je již řešeno v jiné veřejné zakázce). Pro příklad uvádíme:

  • změna funkcionalit nebo vlastností systému
  • záloha dat
  • reporting provozu
  • zajištění dostupnosti
  •  

 

Které z těchto činností bude zadavatel objednávat u provozovatele NENu a které u dodavatele předmětu plnění předmětné veřejné zakázky? Bez odpovědi na předchozí otázku není možné nacenit službu S13.

 

6) Jsou informace uvedené v zadávacích podmínkách dostatečné pro vypracování požadovaného prototypu?

 

Zadávací dokumentace definuje, jaké funkcionality prototypu bude chtít zadavatel demonstrovat, nicméně neumožňuje prototyp dostatečně odladit předem v testovacím prostředí. Rovněž hodnotící kritéria jsou volena velmi vágně a subjektivně.

 

7) Lze požadovaný prototyp vytvořit a následně zprovoznit v systému zadavatele bez znalosti hardwarového prostředí, na kterém bude následně pro účely hodnocení nabídek spuštěn?

Existuje velké riziko, že připravený prototyp nebude možné bez přípravy a ladění spustit v prostředí, které je popsáno v zadávací dokumentaci.

Bez znalosti prostředí, na kterém bude pro účely hodnocení nabídek prototyp spuštěn nemůže uchazeč například predikovat dobu odezvy jeho prototypu, kterou zadavatel stanovil absolutně v hodnotě maximálně 5 / 30 sekund (viz čl. 1.3 přílohy č. 6 zadávací dokumentace – „Specifikace nabídkového prototypu a způsob jeho hodnocení”). Zadavatel by mohl po obdržení nabídek stanovit výkon hardwarového prostředí tak, aby limit splnil pouze preferovaný uchazeč.  

 

8) Jsou požadavky na prototyp nastaveny takovým způsobem, že vytvořením prototypu dojde k vytvoření samostatně fungujícího SW?

Požadavky B1 až B13 na nabídkový prototyp naplňuji v podstatě celý proces otevřeného řízení. Vzhledem k tomu že v bodech B12 a B13 chce zadavatel hodnotit úroveň dokumentace a nápovědy a intuitivnost prototypu, dá se očekávat, že zadavatel požaduje ucelené a samostatně fungující  softwarové dílo.

 

9) Je nutné pro zpracování prototypu znát technickou specifikaci NEN – tedy původního systému? Je možné vytvořit prototyp bez NENu nebo je nutné jako základ pro prototyp si vytvořit vlastní „NEN“, aby mohl být uchazečem zpracován prototyp v rozsahu, jaký požaduje zadavatel a který bude předmětem hodnocení?

 

Vlastnosti nabídkového prototypu specifikuje příloha č. 6 zadávací dokumentace, ve které se píše:

 

  1. Shoda a podoba nabídkového prototypu a výsledného řešení předmětu plnění veřejné zakázky

Logika, architektura, design Systému, užívání jednotlivých modulů a jednotlivé postupy zpracování procesů prototypu budou vycházet z požadavků Závazného návrhu smlouvy, zejm. z její přílohy č. 1 a budou shodné, či příp. dle operativních pokynů zadavatele v průběhu samotné realizace plnění veřejné zakázky upravené, aniž by došlo k podstatné změně vzájemných práv a povinností ve smyslu ust. § 82 odst. 7 ZVZ, s logikou, architekturou, designem Systému, užíváním jednotlivých modulů a jednotlivých postupů zpracování procesů, které budou plněny vybraným uchazečem v roli zhotovitele předmětu plnění veřejné zakázky.

 

Z této specifikace tedy plyne, že nabídkový prototyp musí odpovídat Příloze č. 1 smlouvy, což je „specifikace požadavků Objednatele na systém a služby“.  V konečném důsledku tedy chce zadavatel vytvořit prototyp, který bude odpovídat výslednému soutěženému řešení.

 

10) Jaká je cena obvyklá v daném místě a čase (vzhledem k době zadávání předmětné veřejné zakázky) za vytvoření takového prototypu?

 

Vytvoření fungujícího prototypu, který bude mít vyřešené i takové marginality (zadavatelem však hodnocené) jako je nápověda a uživatelská přívětivost lze odhadovat na cca 120 vývojových man-day, což odpovídá ceně přes 1mil Kč.

 

 

11) Je některá součást použitého SW chráněna právy původního dodavatele tak, že bez jeho součinnosti není možné veřejnou zakázku splnit?

 

Ano, pro realizaci díla požaduje zadavatel užití proprietárního software firmy Tesco SW a to FAMA+ a CryptoID. Náklady na využití těchto technologií nebyl zadavatel schopen určit.