Možné způsoby veřejného zadávání informačních systémů

Veřejný zadavatel je povinen se při pořízení ( vývoji, rozvoji, dodávce …) informačního systému řídit mimo jiné Zákonem o zadávání veřejných zakázek číslo 134/2016 Sb. v platném znění (dále jen „ZZVZ“)

Samotná aplikace zákona je často přísně formální. Zástupci veřejných zadavatelů se drží osvědčených zadávacích postupů, nehledají inovace třeba proto, že pro své finanční prostředky využívají poskytovatele, kteří metodickými doporučeními dále tuto oblast regulují. Samotný ZZVZ , vychází z evropské směrnice¹⁾, která v důvodech zdůrazňuje potřebu inovativních postupů i volání po dodržení zásad efektivity.

Tedy shrnuto

• Přestože ze strany EU je politický a metodický tlak na inovativní způsoby zadávání, prakticky zatím převažuje v praxi spíše formalismus = máme to procesně zdokumentováno, podle metodiky či osvědčených postupů, máme to tedy správně
• Dotační politika má často pravidla, tvořená na úrovni poskytovatele dotace, která často doplňují, až zpřísňují zadávací postupy
• Zkušenosti „zakázkářů“ spíše podporují trend formalisticky jednoduššího a procesně dobře doložitelného zadávacího postupu ( tj. předpoklad, že pokud je správný postup, musí být správný i výsledek plnění)

Přitom legálních metod či způsobů jak dosáhnou cíle efektivně je více. Na základě řady realizovaných zadávacích řízení si je pro naše potřeby kategorizujeme třeba takto:

Metoda vše na klíč. Nejčastěji užívaný (a pohodlný) zadávací způsob. Pokud je zadavatel schopen vytvořit dobrou zadávací dokumentaci s požadavky na informační systém tak, aby v rámci hodnotících kriterií byl schopen vybrat nejlepší řešení dodané generálním dodavatelem, může mít vyhráno. S tím souvisí také kvalitní smluvní ošetření práv k výslednému dodanému informačnímu systému (dílu). Bohužel s ohledem na obecnou „složitost“ předmětu informatiky a předpokládaný rozsah plnění nemohou nabídky často obsahovat a postihnout úplně vše, tedy nelze se vyhnout příslibům typu bude, vyřešíme, zajistíme apod. Celkově je však metoda výhodné pro zadavatele z důvodu přenesení odpovědnosti a nelze ji zatracovat jen proto, že jde o plnění jedním dodavatelem (jehož kvality se reálně ukážou až v průběhu plnění).

Metoda postupně (tj. uvidíme) spočívá v tom, že přípravnou a zkušební fázi budoucího produktu zkoumám, připravuji a ověřuji na konzultacích, demo vzorcích , funkčních vzorcích na jednotlivých menších zadávacích řízení, často v rámci limitu zakázek malého rozsahu. Pokud tato fáze výrazně pokročí nad rámec přípravy zadávací dokumentace, tj. jako zadavatel jsem schopen řídit nebo spoluřídit vývoj , je vyřešeno testovací prostředí a produkční, ukládání a správa zdrojových kódu, pravidla pro dokumentaci a současně nechci jednoho generálního dodavatele, je na místě zavést dynamický nákupní systém pro dodání jednotlivých komponent systému nebo formou nákupu služeb dle § 138 odst. 1 ZZVZ – dynamický nákupní systém. Zde mohu průběžně a bezlimitně nakupovat IT služby. Do dynamického nákupního systému (DNS) lze zařadit postupně nové dodavatele. Výběr nabídek lze provádět automatizovaně, nevýhodou oproti jiným metodám mohou být lhůty.

Metoda může narazit na problém srozumitelnosti dosavadního plnění při vývoji informačního produktu ( řeší pravidla dokumentace a pravidla vývoje) a ochoty dodavatelů navazovat na jednotlivá plnění (prakticky nemožné, částečně řeší zvolená tj. otevřená architektura informačního systému)

Nevýhodou metody je v počáteční fázi možné riziko zákazu dělení zakázek dle § 35 ZZVZ.

Jde o podobnou metodu jako v případě B, ovšem v rámci uzavřeného okruhu (minitrhu) dodavatelů, kam není možné v době jeho trvání (např. 4 roky) přidat další dodavatele (rozdíl oproti DNS). Minitrh je tvořen skupinou dodavatelů , kteří akceptují jeho pravidla a v rámci nich soutěží o jednotlivé zakázky. I nad tímto minitrhem má pravomoc orgán dohledu (UOHS).

Minitrh ovšem řeší problém rizika dělení zakázek i problém metodicko-technické (ne)připravenosti veřejného zadavatele k pořízení/obnově/rozvoji informačního systému. Tuto metodu více popíšeme v následují části.

Metoda je velmi vhodná k vývoji IT produktu/řešení, který se může stát různou formou sdíleným (open source , sdílení v rámci veřejné správy apod.)

Metoda má tyto výchozí předpoklady:

1. mám IT řešení, uvažuji o změně nebo chci pořídit nové řešení, případně maximálně zužitkovat to stávajících a nebojím se použít inovativnější a legální zadávací metodu a
2. dokážu si představit nové, lepší vlastnosti řešení (funkční a nefunkční požadavky), ale netroufnu si vytvořit zadávací dokumentaci pro generálního dodavatele nebo
3. chci sdílené řešení minimálně v tom, aby se v něm vyznalo více dodavatelů nebo aby bylo otevřenější a současně
4. mám IT tým, který je připraven (a ochoten) absorbovat nové zkušenosti a znalosti, mám projektového managera připraveného učit se novým věcem.

Jako veřejný zadavatel jsme realizovali tuto metodu pro vývoj IS s počtem partnerů od 7 do 15 . Počet partnerů lze legálně omezit pouze maximálním počtem účastníků (minimem jsou ze zákona 2, ovšem to je nedostatečný počet). Jejich faktický počet se liší ochotou dodavatele se projektu účastnit a současně splněním zadávacích podmínek (zejména kvalifikace a maximální ceny) pro vytvoření minitrhu.

Zásadním předpokladem pro použití minitrhu je vyjádření jeho účelu – tj. co mám být výsledkem plnění na minitrhu jako konečný produkt. V našem případě to je řešení/produkt, ke kterému máme výchozí vstupní parametry – například nevíme jak má přesně vypadat, neznáme přesné funkční a nefunkční požadavky, nevím jak jej provozovat, nevíme zda jej vůbec lze postavit na open source řešení. Tuto nejistotu by měl zadavatel transparentně uvést v rámci pravidel minitrhu (do preambule rámcové dohody).

Je však možné, že úvodní etapa řešení ukáže, že podmínky pro vyřešení potřeb jsou např. natolik komplikované, že touto cestou produktu/řešení nelze dosáhnout. V tom případě je samozřejmě možné v zadávání na minitrhu nepokračovat. Tyto předpoklady by měly být součástí informací v pravidlech minitrhu (v rámcové dohodě).

Zkušenosti s tímto typem zadávání v této oblasti dnes povětšinou nejsou a dodavatelé se mohou inspirovat pouze předpokládanou hodnotou zakázek na minitrhu, kterou vidí ve věstníku veřejných zakázek. Mohou získat dojem, že je to částka, které připadne vítězi, což je motivuje k účasti Ve skutečnosti je to částka, která se musí efektivně rozdělit mezi vícero dodavatelů tak, aby bylo výsledku účelně dosaženo. A nemusí se vyčerpat.

V zásadě se od dodavatele na minitrhu očekává:

1. Trpělivost se zástupci veřejného zadavatele a některými procesy. Veřejná správa funguje jinak než soukromý sektor. Je zatížena formalismem a často alibismem projevující se ve společné neodpovědnosti. Některé procesy přes snahu IT týmu mohou být nepružné.
2. Ochotu předat zkušenosti v oblasti vedení projektové dokumentace, komentování zdrojového kódu, používání opensource knihoven a volně dostupných řešení, best practise apod.
3. Otevřenost ve smyslu přijímání často kritických pohledů na nabízené/realizované řešení (postup, metody..) tj. vítá revize a doporučení, nevadí mu sdílení výstupů napříč dodavateli
4. Poctivost ve smyslu principu hodnoty za peníze, nikoliv přeprodeje za marže. Dodavatel chce dodávat službu prostřednictvím svých zaměstnanců nebo poddodavatelů férově, s dohodnutými parametry, kvalitně a ve sjednaných standardech.

Před vytvořením minitrhu je nutné rozmyslet podmínky jeho fungování a tyto prokonzultovat s možnými dodavateli v rámci předběžné tržní konzultace.

„Pravidla minitrhu jsou tvořena většinově smluvně“.

Minitrh je tedy vytvořen smluvně a to na základě uzavření rámcové dohody v souladu se ZZVZ v otevřeném řízení. Vyhlášením otevřeného řízení ( lhůta min 30 dnů) sděluje zadavatel předem určenému max. počtu dodavatelů, že by s nimi uzavřel navrženou rámcovou dohodu (dle §131 ZZVZ) na období 4 let (lze důvodně i více) a tím vytvořil minitrh a to typově:

• soutěžního typu (o dílčí zakázky se bude soutěžit na vytvořeném minitrhu),
• nesoutěžního typu (zakázky budeme přidělovat podle určeného klíče).

Aby rámcová dohoda byla uzavřena (a tím byl minitrh vytvořen), je nutné ,aby se v případě soutěžního typu, zúčastnili nejméně dva dodavatelé dle ZZVZ. Ovšem pro naše potřeby je zpravidla vhodné , aby jich bylo daleko více. Zadavatel určí maximum dodavatelů se kterými mu plnění v rámci minitrhu dává smysl (např. 30) . Uzavřením rámcové dohody nezíská dodavatel jistotu plnění, ale pouze příležitost zakázku na minitrhu získat.

S dodavatelem bude uzavřena v rámci otevřeného řízení rámcová dohoda pokud

• splní kvalifikaci
• nabídne svou hodinovou sazbu nižší než je maximální sazba uvedená zadavatelem
• a současně se v rámci své nabídky vejde do stanoveného pořadí (v našem příkladě 30 dodavatelů, tj. bereme prvních 30 dodavatelů s nejlepší hodinovou sazbou)

Dodavatel musí vyjádřit akceptaci pravidel minitrhu a to tím, že rámcovou dohodu se zadavatelem uzavře.

V popisovaném příkladu jde o službu, která bude zadávána opakovaně specifikovanou takto

Výše uvedené činnosti jsou jednotně nabízeny za shodnou hodinovou sazbu určenou rámcovou dohodou s možností tuto sazbu při nabídce na minitrhu snížit.

Důležitým prvkem výše uvedených činností je, že je zadavatel bude poptávat opakovaně podle toho, jak dalece bude se svým řešením postupovat tj, od analýz, tvorby pravidel, přes funkční či demo vzorky, až k programování modulů/služeb.

Zadavatel postupuje v souladu se zákonem a smluvními podmínkami stanovenými rámcovou dohodou. Proto je důležité věnovat pozornost přípravě minitrhu před jeho zavedením. Pozdější změny (byť odsouhlaseny všemi účastníky) nejsou možné.

Způsobem zadání mohou být typově tyto druhy zakázek (jde o příklady)

Nanotendr – pouze ve vyjmenovaných konkrétních případech. Například pro úpravu zdrojového kódu již existující aplikace. Pokud je tato úprava vyvolaná potřebou jiné části aplikace (služby) lze zadat plnění napřímo tomu dodavateli, který danou aplikaci naprogramoval (a je tedy důvodný předpoklad, že tuto úpravu provede efektivně). Hranice zadání může být nastavena např. na max. 200 000 Kč. Jde o tzv. „zadání z ruky“

Mikrotendry – návrhy funkčních vzorků , prototypy do stovek tisíc Kč, ale s souladu s účelem minitrhu a cíle projektu. Takto mohu plnění opakovat při dodržení účelnosti postupu vícekrát či mohu zadávat řešení souběžně (paralelně) . Mohu postupně zlepšovat a opakovat zadání zakázky, podle principu co nedokáže jeden dodavatel, může zlepšit druhý. To vše do doby nalezení vyhovujícího řešení. Tyto mikrotendry jsou zásadně soutěžního typu.

Minitendry – ve stovkách tisíc či milionech, jako programové práce z vybraných (nalezených) řešení. Finančním limitem Kč je pouze celkový budget dle rámcové dohody a samozřejmě dodržení zásad účelného a efektivního postupu

Přestože základní pravidla jsou stanovena ZZVZ a dohled nad jejich dodržováním má v kompetenci ÚOHS, lze pro minitrh stanovit řadu konkrétních a účelných postupů, sledující dosažení cíle minitrhu (rámcové dohody). Předně je nutno zdůraznit, že zadávání zakázek musí být opakované (podobně jako by byly realizovány nákupy nějakých produktů). Jde tedy o opakující se nákup IT služeb druhově (věcně) rozlišeno dle účelu plnění (předmětu zakázky tj. od analýza, pracovní postup, způsob nějakého řešení, demonstrační vzorek, ověření demonstračního vzorku až po naprogramování konkrétní aplikace/modulu/služby )

Zásadní výhodou je možnost stanovit operativní lhůty a to jak pro nabídku, tak pro plnění. V kombinaci s používáním formulářů lze nabídky obdržet např. i do týdne. Způsob akceptace formuláře pak umožňuje nabídku akceptovat jako smlouvu do několika dnů po vyhodnocení (námitky nemusí mít odkladný účinek). Plnění tak může být zahájeno ve velmi krátkém čase.

Další výhodou je možnost zadat plnění při hledání řešení v samostatných plněních – typicky demonstativní vzorek – souběžně více dodavatelům. Tyto rozvíjet nebo na ně navazovat i nechávat je revidovat. Tato interakce a postupy však musí být účelné. Otázka hospodárnosti je citlivá při vynakládání veřejných prostředků.

Poslední výhodou je transparentnost řešení. Za situace, kdy skupina dodavatelů sdílí know-how, nepůsobí jako kartel, ale jako kooperující subjekty, lze očekávat, že výsledný produkt nebo jeho části budou dále využitelné.

Velkou nevýhodou minitrhu je jeho omezení na časový rámec a nemožnost přibrat další účastníky ( lze však měnit poddodavatele)

ELZA

Software pro tvorbu archivních pomůcek podle Základních pravidel pro zpracování archiválií z roku 2015. Software ELZA je šířen pod otevřenou licencí Apache 2.0

https://www.mvcr.cz/clanek/software-elza.aspx

9 dodavatelů – 2 klíčoví / 1 koordinátor

Sdílený Informační Systém TAČR (příklad smlouvy https://smlouvy.gov.cz/smlouva/19229531)

7 dodavatelů 1.etapa,

15 dodavatelů nyní v běžící etapě 2, žádný koordinátor.

Technologicky inspirace Portálem občana - mikroslužbové řešení, API komunikace.

Aktuálně k dispozici pro veřejnou správu k dalšímu užití jako vedlejší produkt IDM modul se správou osob s možným napojením na NIA.

Pro pořízení komplikovanějších řešení v oblasti IT lze s použít i ryze inovativní zadávací metody jimiž jsou soutěžní dialog a inovační partnerství. Této problematice se věnujeme i na stránce https://www.tacr.cz/inovace-v-zadavani-verejnych-zakazek/