TECHNICKÉ PODMÍNKY pro zpracování nabídky v rámci Veřejné zakázky „Realizace a zajištění provozu informačního systému pro správu finanční podpory Středočeského kraje“ dle zákona č. 134/2016, o zadávání veřejných zakázek (dále též „zákon“ nebo „ZZVZ“)...

TECHNICKÉ PODMÍNKY

pro zpracování nabídky v rámci Veřejné zakázky

„Realizace a zajištění provozu informačního systému pro správu finanční podpory Středočeského kraje“

dle zákona č. 134/2016, o zadávání veřejných zakázek (dále též „zákon“ nebo „ZZVZ“) v platném znění v otevřeném řízení v nadlimitním režimu.

Zadavatel

Středočeský kraj
Zborovská 11, 000 00 Xxxxx 0
XXX: 70891095

Obsah

1 Úvod 3

2 Okolnosti Veřejné zakázky 4

3 Stávající řešení správy finanční podpory SčK 5

4 Cílový stav – požadované služby a dodávky 8

5 Technická specifikace systému 9

6 Požadavky na dodávaný systém 21

7 Související ujednání 28

8 Přílohy 29

1Úvod

Na zpracování tohoto dokumentu spolupracovala společnost KPMG Česká republika, s. r. o., Xxxxxxxx 000/0X, 000 00 Xxxxx, IČ 00553115 na základě objednávky Zadavatele.

1.1Účel dokumentu

Účelem dokumentu je doplnění Zadávací dokumentace veřejné zakázky „Realizace a zajištění provozu informačního systému pro správu finanční podpory Středočeského kraje“ o části, kterými specifikuje především technické podmínky veřejné zakázky.

1.2Terminologie a zkratky

Název pojmu / zkratka	Popis / definice
Administrátor (entity)	Administrátor dat (v dané datové entitě) spravující (zadávající) data do IS za danou entitu.
AD	Access directory
API	Application Programming Interface
ARES	Administrativní registr ekonomických subjektů; informační systém provozovaný Ministerstvem financí, který obsahuje všechny ekonomické subjekty, kterým bylo v ČR přiděleno identifikační číslo osoby (IČO).
CSV	Comma-separated values
DPH	Daň z přidané hodnoty
GDPR	General Data Protection Regulation
HSOÚ	Hospodářsky a sociálně ohrožená území
HTML	Hypertext Markup Language
IDM	Identity management
Integrace	Rozhraní (Interface) na primární informační systémy sloužící k opakovanému naplňování daty.
IS	Informační systém.
ISDS	Informační systém datových schránek
ISM	Integrovaný systém management
ISZR	Informační systém základních rejstříků (RUIAN, ROB, ROS, RPP).
IT	Informační technologie
KB	Kybernetická bezpečnost
KÚ	Krajský úřad
MD	Man-day
Migrace dat	Iniciační naplnění daty z primárního informačního systému.
ORP	Obec s rozšířenou působností
PDF	Portable Document Format
Právní vztah	Právní vztah mezi dvěma a více subjekty k předmětu vztahu
Provozovatel infrastruktury	KÚSK zajišťující provoz a správu ISM a metodiky naplňování dat a jejich vyhodnocování.
ROS	Registr osob.
SčK, SK	Středočeský kraj
SLA	Service-level agreement
Subjekt	Státní instituce, kraj, obec, jiná právnická či fyzická osoba
SW	Software
TOGAF	The Open Group Architecture Framework
TZ	Tematické zadání
Uživatel systému	Označuje osobu, která používá počítačový systém. Pro účely bezpečnosti, záznamu prováděných akcí nebo správy zdrojů je vyžadována identifikace uživatele.
VZ	Veřejná zakázka
XLSX	XLSX je přípona souboru nejrozšířenějšího programu tabulky aplikace Excel.
XML	Extensible Markup Language
ZD	Zadávací dokumentace
ZoISVS	Zákon o informačních systémech veřejné správy
ZoKB	Zákon o kybernetické bezpečnosti
ZVA	Závěrečné vyúčtování
ZZVZ	Zákon o zadávání veřejných zakázek

2Okolnosti Xxxxxxx xxxxxxx

2.1Důvody vyhlášení Xxxxxxx xxxxxxx

Současná aplikace eDotace (systém přidělování dotací z dotačních titulů) již nesplňuje požadavky na funkcionality a zejména na digitalizaci služeb. Aplikace nepodporuje integrace do veřejných registrů pro automatické ověřování subjektů ani další možnosti registrace žadatelů (NIA ID, Datové schránky).

Grafické rozhraní již nevyhovuje aktuálním standardům a neposkytuje uživateli dostatečnou zpětnou vazbu ani pomoc při řešení základních úkonů, které aplikace podporuje.

U aplikace chybí podpora vlastní tvorby jednoduchých formulářů a případných drobných změn, které by mohly být vykonávány na straně uživatelů, kde dnes je třeba všechny změny řešit cestou helpdesku dodavatele. Celkové řešení aplikace vede k závislosti na daném dodavateli, který tuto aplikaci spravuje.

Veškeré změny, které by vedly k řešení těchto požadavků jsou za současného stavu aplikace neřešitelné anebo řešitelné jen velmi obtížně.

2.2Cíle projektu

Cílem Veřejné zakázky je vytvoření nové aplikace (též IS, nástroj, aplikační SW), která bude splňovat aktuální požadavky na daný systém a jeho podporu. Bude splňovat požadavky na digitalizaci a bude obsahovat i integrační rozhraní, které bude možné využít, jak ke splnění aktuálních požadavků, tak i případných budoucích.

Zároveň je důležité snížit závislost na dodavateli a umožnit uživatelům na straně Středočeského kraje dělat drobné úpravy a tvorbu šablon, číselníků, formulářů atd. na jejich straně bez potřeby zásahu dodavatele.

Důležitým cílem je též usnadnit práci všem stranám za pomocí ověřování údajů pomocí registrů a dalších kontrolních mechanismů, což povede ke zjednodušení a zrychlení procesu registrace, tvorby a schvalování žádosti.

3Stávající řešení správy finanční podpory SčK

Pro správu finanční podpory SčK využívá aplikaci eDotace, kterou provozuje cca od roku 2009 a která prošla nesčetnými úpravami a v současné době již nevyhovuje požadavkům.

3.1Popis řešení

Systém je implementován v klasické 3 vrstvé architektuře. Je naprogramován s využitím frameworku Grails v jazyce Groovy a Java. Data jsou ukládána do relační databáze MySQL a do souborového systému.

Základními funkcemi systému jsou:

• Registrace žadatele – dle funkčních požadavků ID 08-10

• Podání žádosti – s automatickým doplňováním vybraných identifikačních údajů z profilu žadatele do každého formuláře žádosti, po prvním uložení žádosti IS vygeneruje evidenční číslo žádosti, žádost je možno sledovat uživateli backendu, elektronický podpis formuláře žádosti je přímo v aplikaci

• Zpracování žádosti – kontrola žádosti pracovníkem KÚ, v případě nutnosti vrácení žádosti k doplnění

• Hodnocení žádosti – hodnocení dle v Programu schválených hodnotících kritérií

• Uzavření smlouvy – generování, kontrola a úprava smlouvy v backendu pracovníkem KÚ, zaslání k podpisu příjemci finanční podpory a následně zástupci poskytovatele

• Zpracování dokumentace závěrečného vyúčtování žadatelem – automatické doplňování identifikačních údajů z profilu žadatele, případně dalších vybraných údajů ze žádosti 

• Export žádosti – druhy exportů dle funkčního požadavku ID18 (viz kapitola 6)

a nadále i budou součástí nově dodaného řešení.

Jednotliví uživatelé jsou mapováni do následujících rolí v systému:

3.1.1Business architektura

3.1.2Aplikační architektura

3.1.3Systémová architektura

4Cílový stav – požadované služby a dodávky

Předmětem veřejné zakázky je poskytnutí níže stanovených služeb a předání jejich výstupů Xxxxxxxxxx ve stanovené lhůtě a kvalitě.

Zadavatel požaduje, aby Dodavatel v rámci Veřejné zakázky dodal Zadavateli funkční aplikaci pro kterou následně zajistí servis, podporu a rozvoj.

Vývoj aplikace, její otestování, spuštění do provozu a následná podpora bude provedena v dílčích krocích.

1. Podrobný návrh cílového konceptu řešení – bude zahrnovat analýzu a rozsah migrovaných dat, vytvoření testovacího prostředí a nasazení aplikace.

2. Implementace aplikace (SW) včetně licencí a nasazení dle cílového konceptu, otestování řešení, přechod do produkčního prostředí a dodávka kompletní dokumentace.

3. Údržba, podpora – po dobu 60 měsíců.

4. Následný rozvoj – po dobu 60 měsíců v rozsahu 120MD/rok.

5. Znalostní podpora a provedení nezbytných úkonů při ukončení Smlouvy a předání služeb na jiného dodavatele.

4.1Místo a termín plnění

4.1.1Místo

Místem realizace projektu je sídlo Krajského úřadu Středočeského kraje (dále také Zadavatele), tj. krajský úřad na xxxxx Xxxxxxxxx 00/00, 000 00 Xxxxx 0.

4.1.2Termín plnění, harmonogram

Předmět plnění této Veřejné zakázky bude vybraným Dodavatelem realizován na základě budoucí Xxxxxxx, která vychází ze Závazného návrhu smlouvy, jež je Přílohou č. 1 Zadávací dokumentace. Termín plnění veřejné zakázky je podmíněn ukončením zadávacího řízení, uzavřením Xxxxxxx s vybraným Dodavatelem a nabytím její účinnosti.

Předpokládaný harmonogram realizace jednotlivých činností a dodávek této Veřejné zakázky předpokládaný Zadavatelem, zahrnuje:

1. Uzavření smlouvy T0 (začátek projektu).

2. Podrobný návrh cílového konceptu řešení T0 + 1 měsíc.

3. Revize a akceptace cílového konceptu objednatelem T0 + 6 týdnů.

4. Implementace SW včetně licencí a nasazení konfigurace dle cílového konceptu, otestování řešení a dodávka kompletní dokumentace T0 + 3 měsíce + 3 měsíce předprodukční testování.

5. Spuštění produkčního provozu T0 + 6 měsíců.

6. Údržba a podpora provozu – po nasazení do produkce + 60 měsíců.

7. Následný rozvoj aplikace – po nasazení do produkce + 60 měsíců.

8. Znalostní podpora a provedení nezbytných úkonů při ukončení Xxxxxxx a předání služeb na jiného dodavatele – na výzvu Zadavatele (nejpozději 2 měsíce před koncem podpory).

Dodavatel je povinen v rámci své nabídky předložit reálný Harmonogram plnění Veřejné zakázky, který bude následně tvořit Přílohu č. 3 Smlouvy a který bude respektovat termíny plnění veřejné zakázky uvedené v čl. III Závazného návrhu smlouvy.

4.1.3Předpokládaná hodnota – Kalkulační model

Zadavatel po Dodavateli požaduje vyplnění Kalkulačního modelu, tj. Přílohy č. 4 Zadávací dokumentace – rozpad hodnoty zakázky podle poptávaných činností, který se následně stane Přílohou č. 2 Smlouvy.

5Technická specifikace systému

Tato kapitola podrobně popisuje technické požadavky Zadavatele na dodávky dílčích služeb.

5.1Návrh cílového konceptu řešení

Tento návrh aplikační architektury pouze ilustruje možnou podobu výsledného systému. Přesný detail a provedení je na návrhu Dodavatele. Systém musí obsahovat všechny klíčové komponenty a služby, které jsou specifikovány v požadavcích na řešení. Samotný skutečný návrh a provedení je součástí dodávky a podléhá akceptaci ze strany Zadavatele.

5.2Implementace řešení

5.2.1Funkční a nefunkční požadavky na řešení

Funkční a nefunkční požadavky na aplikaci pro správu finanční podpory SčK jsou popsány v kapitole 6 tohoto dokumentu.

5.2.2Dodávka potřebných licencí k produktu

Vzhledem k tomu, že dílo vytvořené Dodavatelem pro Zadavatele dle tohoto dokumentu je plnění, které naplňuje, resp. bude naplňovat znaky autorského díla ve smyslu § 2 zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (dále jen „Autorský zákon“), ve znění pozdějších předpisů, je povinností Dodavatele poskytnout Zadavateli oprávnění k výkonu práva autorské dílo užít za podmínek a v rozsahu dále uvedeném.

Dodavatel postoupí Zadavateli právo výkonu majetkových práv k Autorskému dílu a pro případ, že by postoupení nebylo možné, poskytuje Dodavatel Zadavateli (jako nabyvateli) oprávnění k výkonu práva Autorské dílo užít (dále též „Licence“) v původní nebo zpracované podobě nebo jinak změněné podobě, a to všemi způsoby užití, v neomezeném rozsahu územním, množstevním, v neomezeném počtu prostředí, samostatně nebo v souboru anebo ve spojení s jiným dílem. Zadavatel není povinen Licenci ve smyslu § 2372 odst. 2 Občanského zákoníku využít. Licence je poskytována jako nevýhradní, není-li ve Smlouvě výslovně uvedeno jinak, a to na dobu dle § 27 Autorského zákona. Dodavatel prohlašuje, že je oprávněn vykonávat majetková autorská práva k Autorskému dílu svým jménem a na svůj účet.

Pro vyhnutí se jakýmkoliv pochybnostem do budoucna, součástí Licence je neomezené oprávnění Zadavatele provádět jakékoliv modifikace, úpravy, změny Autorského díla, dle svého uvážení do něj zasahovat, zapracovávat ho do dalších děl nebo ho s jinými díly funkčně propojovat apod., a to i prostřednictvím třetích osob. V případě počítačových programů se Licence ve stejném rozsahu vztahuje na zdrojový a strojový kód (jako podobu vyjádření počítačového programu), na koncepční materiály, dokumentaci, a i na případné další verze počítačových programů upravené na základě smlouvy. Dodavatel je povinen předat a uložit zdrojový kód do softwaru na správu zdrojového kódu ke každé jednotlivé části Autorského díla nejpozději v den Závěrečné akceptace Díla, přičemž tato povinnost Dodavatele se vztahuje i na jakékoliv opravy, změny, doplnění (upgrade, update) zdrojového kódu každé jednotlivé části Autorského díla. Zadavatel je oprávněn stanovit i jiný způsob předání zdrojového kódu nežli prostřednictvím software na správu zdrojového kódu. Zadavatel je rovněž oprávněn ke všem způsobům užití veškeré dokumentace včetně výstupů vytvořených nebo získaných během plnění předmětu tohoto dokumentu, včetně práva tyto výstupy měnit.

Licence zahrnuje dále právo Zadavatele (I) zhotovit ze zdrojového kódu dočasné i trvalé provozní rozmnoženiny, (II) provozovat systém v libovolném počtu prostředí, (III) zhotovit ze zdrojového kódu rozmnoženiny (kopie) systému pro účely zálohování, (IV) funkčně propojit systém s jakýmikoliv jinými informačními systémy či komponentami využívanými ze strany Zadavatele (a to i externími) a (V) veškerá práva uvedená v ustanovení § 66 Autorského zákona (VI) i nad rámec § 66 Autorského zákona – Zadavatel je oprávněn libovolně měnit, upravovat a dále vyvíjet Autorské dílo, a to samostatně či prostřednictvím jím určených třetích osob.

Zadavatel je oprávněn bez potřeby dalšího souhlasu Dodavatele udělit podlicence třetí osobě, oprávnění tvořící součást Licence může tedy zcela nebo zčásti poskytnou třetí osobě. Zadavatel je dále oprávněn bez potřeby dalšího souhlasu Dodavatele postoupit Licenci třetí osobě. Zadavatel je oprávněn užívat systém pro provozní účely spřízněných osob a osoby plnící dle předpisů Zadavatele funkce osob, jimž jsou funkcionality systému určeny. Všechny výše zmíněné požadavky na licencování jsou omezeny na území České republiky.

5.2.3Testovací provoz – vytvoření testovacího prostředí

Dodavatel uvede systém do testovacího provozu (testovací instance) do 14 dnů od schválení cílového konceptu. Účelem testovacího provozu je ověření funkčních vlastností implementovaného systému. Uvedení systému do testovacího provozu zahrnuje následující aktivity:

1. Vytvoření testovacího prostředí (testovací instance) v Technologickém centru KÚSK. Požadavky na infrastrukturu budou upřesněny ve vzájemné kooperaci Zadavatele a Dodavatele.

2. Provedení migrace historických dat ze současného systému „eDotace“ (Dotační tituly - Krajský úřad středočeského kraje (xx-xxxxxxxxxxx.xx) na základě provedené analýzy a dle rozhodnutí Zadavatele do testovací instance.

3. Aktualizace dodavatelem zpracované dokumentace, školení uživatelů a řízení změn.

4. Ukončení testovacího provozu.

5.2.4Produkční provoz – vytvoření produkčního prostředí

Dodavatel uvede systém do produkčního provozu. Uvedení systému do produkčního provozu zahrnuje následující aktivity:

1. Uvedení do produkčního provozu postupným roll-outem na jednotlivá uživatelská pracoviště počínaje garanty a jejich zástupci, následně hodnotiteli a dalšími administrátory, včetně poskytování zvýšeného dohledu.

2. Provedení migrace dat ze současného systému „eDotace“ či testovací instance.

3. Finální akceptace – předání díla.

5.3Údržba systému

Úkony údržby jsou plánované, prováděné a vykazované na měsíční bázi. Provádění údržby zahrnuje níže popsané základní služby a činnosti.

5.3.1Popis činností

Profylaxe – Dodavatel provádí pravidelnou kontrolu a vyhodnocení stavu systému. Dodavatel na základě vyhodnocení stavu systému upozorňuje Zadavatele na nepravidelnosti v provozu systému a provádí změny konfigurací a další úkony potřebné k zajištění spolehlivého běhu systému. Dodavatel dále na základě vyhodnocení stavu systému doporučuje opatření k zajištění zdrojů pro udržení výkonu systému. Součástí dodávky je také pravidelný přenos kopie produkčních dat do testovacího prostředí včetně nastavování prostředí systému a integračních vazeb na testovací instance jiných informačních systémů).

• Minimální četnost: 4x ročně

• Způsob měření a vykazování: výčet provedených úkonů

• Předpokládané časy údržby: podle dohody se Zadavatelem

Dodávka a aplikace záplat a aktualizací – Dodavatel průběžně sleduje bezpečnostní upozornění, bezpečnostní a funkční záplaty a aktualizace systému včetně doporučení k jejich nasazení vydané výrobcem. Dodavatel vydané záplaty a aktualizace otestuje a doporučí Zadavateli termín a způsob jejich nasazení. Zadavatel rozhodne o doporučení. Dodavatel následně provádí úkony podle rozhodnutí Zadavatele.

• Četnost: průběžně

• Způsob měření a vykazování: výčet aplikovaných záplat

• Předpokládané časy údržby: podle dohody se Zadavatelem

Průběžná aktualizace provozní a technické dokumentace – Dodavatel pravidelně provádí aktualizace provozní a technické dokumentace systému na základě změn do skutečného provedení systému provedených Dodavatelem nebo Zadavatelem, včetně popisu skutečného provedení systému pro testovací i ostré prostředí (architektonické modely v otevřeném formátu jazyka Archimate, popis technologií a konfigurací); popisu změn jednotlivých modulů při aktualizacích; popisu nasazovaných záplat a aktualizací včetně podmínek jejich nasazení; požadavků na koncové stanice, servery a infrastrukturu; uživatelských a systémových příruček s popisem provozních postupů; popisu pravidel, rozsahu a podmínek zálohování systému v různých prostředích.

• Minimální četnost: 2x ročně, nebo při aktualizaci systému

• Způsob měření a vykazování: výčet změn podle dokumentů

• Předpokládané časy údržby: podle dohody se Zadavatelem

Kontrola čitelnosti záloh – Dodavatel pravidelně provádí obnovu zálohovaných dat v testovacím prostředí a ověření, zda jsou zálohy čitelné, správné a úplné.

• Minimální četnost kontroly integrity záloh: 2x měsíčně

• Minimální četnost kompletní obnovy záloh s testováním plného naběhnutí aplikace, měřením času obnovy a akceptací: 4x ročně

• Způsob měření a vykazování: výčet testovaných záloh s výsledky testů

• Předpokládané časy údržby: podle dohody se Zadavatelem

5.3.2Součinnost, způsob plnění, akceptace

Zadavatel poskytne Dodavateli součinnost v následujícím rozsahu:

• Zadavatel poskytne Dodavateli technický popis systému eDotace, a zpracuje základní dokument „požadavky na infrastrukturu“ ve vzájemné součinnosti

• Zadavatel umožní odborným pracovníkům Dodavatele provádět fyzické prohlídky provozního prostředí Středočeského kraje, ve kterém je provozován systém

• Zadavatel zajistí a poskytne Dodavateli přístup do úložiště dokumentů a repozitářů, které budou sloužit ke sdílení veškerých elektronických dokumentů, architektonických návrhů a balíčků zdrojových kódu vytvořených Dodavatelem v rámci plnění této veřejné zakázky

• Zadavatel posoudí doporučení Dodavatele a rozhodne o nasazení záplat a aktualizací

Způsob plnění, termíny, akceptace:

• Aktivity údržby jsou vykazovány do předem definovaných šablon dle výše popsaných požadavků

• Dodavatel bude při svých dodávkách koordinovat svoje činnosti s pracovníky odboru informatiky Zadavatele tak, aby provoz systému odpovídal kontextu prostředí Zadavatele, tj. respektoval omezení datových toků infrastruktury a využití zdrojů platforem a korektně využíval centrální služby IT (např. zdroj přesného času, služby zálohování, jmenné a autentizační služby apod.). Odpovědnost za koordinaci činností Dodavatele s provozovateli infrastruktury IT, platforem a integrovaných informačních systémů na sebe bere Zadavatel.

• Plnění služby je zahájeno dnem akceptace výstupů služby „Uvedení systému do produkčního provozu“

• Dodavatel je povinen provádět údržbu systému do doby ukončení Smlouvy

5.4Podpora systému

5.4.1Úrovně podpory

Zadavatel definuje 3 požadované úrovně podpory – L1, L2, L3:

• L1: HelpDesk Zadavatele – pro každodenní drobnou podporu všech uživatelů systému, zajišťuje Zadavatel svými silami

• L2: ServiceDesk Dodavatele – pro běžně náročné úkony podpory, pouze pro oprávněné pracovníky Kraje, provádí Dodavatel

• L3: Odborníci Dodavatele – pro náročné úkony podpory vyžadující expertní znalost, pouze pro oprávněné pracovníky Kraje, provádí Dodavatel

5.4.2Charakter podpory

Pro účely poskytování podpory definuje Zadavatel:

• SLA: jedná se o domluvenou úroveň kvality služeb, kterou Xxxxxxxxx garantuje Zadavateli

• Uživatelský požadavek: jedná se o Ticket popisující požadavek uživatele systému na podporu Dodavatelem, a to pří úkonech zahrnutých do rozsahu podpory. Obsahuje popis požadavku, čas vytvoření, kontaktní osobu, kategorii požadavku, analýzu požadavku a návrh řešení, analýzu dopadů řešení, popis úkonů provedených k vyřešení požadavku, historii změn stavů Ticketu a další informace vztahující se k řešení požadavku

• Závada: znamená nesoulad skutečné funkčnosti systému s funkčností, jež je popsána technickou dokumentací

• Kybernetický incident: jde o narušení bezpečnosti informací v informačních systémech nebo narušení bezpečnosti služeb anebo bezpečnosti a integrity sítí elektronických komunikací v důsledku kybernetické bezpečnostní události

• Hlášení závady: jedná se o Ticket popisující výskyt závady. Obsahuje popis závady, čas hlášení, kontaktní osobu, kategorii závady, vyhodnocení dopadů a příčin závady, popis úkonů provedených k odstranění závady, historii změn stavů Ticketu a další informace vztahující se k řešení závady

• Response time: jedná se o dobu od okamžiku zadání uživatelského požadavku (příp. hlášení závady) do okamžiku, kdy je Xxxxxxxxxx sděleno, že Xxxxxx s jeho požadavkem (resp. hlášením) je přijat a bylo zahájeno jeho zpracování

• Fix time: jedná se o dobu počínající okamžikem nahlášení závady (příp. zadání požadavku), do okamžiku, kdy je, a to buď dočasným, nebo kompletním řešením, závada odstraněna (resp. požadavek vyřešen)

5.4.3Cyklus zpracování požadavků

Životní cyklus hlášení závady a uživatelského požadavku je definován skrze následující stavy, viz následující diagram:

• Zadáno – Ticket byl korektně nahlášen, začíná měření Response a Fix time

• Přiděleno – Dodavatel přidělil Ticket k řešení odpovědnému řešiteli

• Čekající – Řešení Ticketu čeká na aktivitu Zadavatele, Fix time je pozastaven

• Vyřešen – Ticket je Dodavatelem vyřešen

5.4.4Další součásti podpory

Poskytování podpory zahrnuje:

• Hot-line prostřednictvím HelpDesku (s integrací na ServiceDesk Zadavatele), telefonu či e-mailu pro vyjmenované pracovníky Zadavatele (tj. odpovědi na otázky k užívání a fungování systému, příjem požadavků, hlášení závad, stav Ticketů)

• Řešení požadavků kraje, například příprava/úprava sestav/výkazů, změny/migrace dat, změna/definice uživatelských rolí, vytvoření nového uživatele, optimalizace konfigurace, doplnění číselníku apod.

• Podpora při vytváření plánů obnovy, provádění testů obnovy a dostupnosti systému

• Řešení problémových stavů v datech vzniklých činností uživatelů

• Řešení závad a nepravidelností v provozu systému

• Osobní asistence při administraci systému

• Metodická pomoc, účast a asistence na metodických jednáních

• Konzultace otázek spojených s užíváním systému či integrací systému na jiné IS

V případě, že Zadavatel kontaktuje Xxxxxxxxxx s požadavkem na podporu ohledně úkonů, které nejsou součástí podpory, zasílá Dodavatel tento požadavek zpět na Zadavatele s odůvodněním (bez povinnosti předávat tento požadavek k řešení). Mezi takové požadavky jsou zařazeny zejména:

• Závady v IT infrastruktuře

• Požadavky na přizpůsobení nebo změny funkcí systému

• Správa instalací na stanicích uživatelů

Zadávání požadavků v rámci podpory a údržby a s tím související komunikace úkonů podpory Dodavatele bude realizována primárně pomocí ServiceDesku Dodavatele.

Podpora bude Dodavatelem poskytována ve dvou úrovních SLA - standardní a nadstandardní. Nadstandardní SLA je v platnosti pouze na vyžádání zadavatele, který předpokládá vyšší vytížení systému (zavedení nových dotačních programů, …) a je potřeba na tuto okolnost upozornit alespoň týden (5 pracovních dní) před začátkem čerpání nadstandardní podpory. Požadavek na zahájení nadstandardní podpory bude zaslán pomocí ServiceDesku Dodavatele a bude v něm uveden začátek i konec plnění, aby mohl na tuto změnu dodavatel alokovat dostatek prostředků. Celkové plnění nadstandardní podpory bude maximálně 90 kalendářních dní za rok. Tyto dny lze čerpat po libovolných částech během celého roku. Souvislá doba jednoho nadstandardního plnění podpory nemůže být kratší než 7 kalendářních dní a delší než 90 kalendářních dní.

Zadavatel komunikuje své požadavky pomocí webu nebo e-mailu a to i v době mimo časy, které jsou vymezeny SLA a Dodavatel tyto požadavky řeší přednostně při nejbližším termínu běžné pracovní doby poskytování podpory. Zadavatel může využít telefonické podpory v pracovní době v časech stanovených dle SLA a ta slouží zejména pro operativní vyřizování dotazů oprávněných pracovníků Zadavatele. V případě potřeby změnit prioritu řešení nebo v případě potřeby koordinace řešení s dalšími dodavateli, eskaluje Dodavatel tyto informace bezodkladně na Zadavatele skrze ServiceDesk popř. odpovědné pracovníky odboru informatiky Zadavatele.

Zadavatel bude realizovat měření dostupnosti IS s pomocí monitorovacího nástroje, který ověřuje dostupnost aplikací pravidelnými automatizovanými dotazy.

5.4.5Specifikace služeb SLA

Podrobná specifikace služeb - Standardní SLA se vypočítává dle času technologické podpory a je vymezena následovně:

Dostupnost (v provozním čase)	99% Dostupnost = ((požadovaná doba dostupnosti – suma (doby nedostupnosti podle měření) / (doba dostupnosti)) * 100
Technologická podpora	5x8 Po-Pá 8:00 – 16:00
Zadávání požadavků ServiceDesk (email, web)	7x16 Po-Ne 6:00 – 22:00
Odezva (Response time)	Dle detailu priorit v následující tabulce
Řešení (Fix time)	Dle detailu priorit v následující tabulce
Plánovaná údržba	Mimo provozní čas, souvislá délka odstávky max. 4 hodiny - servisní okno

Podrobná specifikace služeb - Nadstandardní SLA se vypočítává dle času technologické podpory a je vymezena následovně:

Dostupnost (v provozním čase)	99% Dostupnost = ((požadovaná doba dostupnosti – suma (doby nedostupnosti podle měření) / (doba dostupnosti)) * 100
Technologická podpora	7x12 Po-Ne 7:00 – 19:00
Zadávání požadavků ServiceDesk (email, web)	7x16 Po-Ne 6:00 – 22:00
Odezva (Response time)	Dle detailu priorit v následující tabulce
Řešení (Fix time)	Dle detailu priorit v následující tabulce
Plánovaná údržba	Mimo provozní čas, souvislá délka odstávky max. 4 hodiny - servisní okno

Kategorie priorit – řešení jednotlivých požadavků:

Priorita/kategorie vady	Popis	Odezva (Response time)	Řešení do (Fix time)
1 – kritická Kategorie vady A	Systém nefunguje vůbec nebo jeho nefunkčnost je omezena tak, že tento stav má významný dopad na klíčové procesy Zadavatele Aplikaci nebo některou její klíčovou funkci není možné používat Dochází k narušení uživatelských dat závažným způsobem Dochází ke zhroucení systému jednou nebo několikrát za den	1 hod.	4 hod.
2 – vysoká Kategorie vady B	Funkce systému je narušena tak, že dochází k významnému zpomalení výkonu klíčových procesů Zadavatele.	4 hod.	8 hod.
3 – střední Kategorie vady C	Funkce systému je omezena, ale toto omezení má minimální vliv na zpracování klíčových procesů Zadavatele Závada narušuje, avšak neznemožňuje využití systému Blokuje dokončení určitých úkolů, které nejsou časově kritické působí dílčí závadu nebo nepohodlí uživatele procesní závada (vyřeší se změnou procesu) Tuto závadu lze jiným náhradním dočasným způsobem (např. ruční úpravou dat) nebo dočasnou změnou pracovního postupu obejít (workround). Uživatel však musí vykonat vícepráce na obejití závady.	8 hod.	3 pracovní dny
4 – nízká Kategorie vady D	Systém je funkční. Závada způsobuje jen minimální obtíže při jeho používání. Jde o situace, kdy: vznikne malý problém nebo nepohodlí obsluhy kosmetická chyba ve vizuálním rozhraní (chybné popisy, řazení dat, překreslování) Uživatel nemusí vykonat vícepráce na obejití závady. Způsobuje mu nepohodlí při práci (např. pohyb myší navíc, klik myší navíc, stisk několika kláves navíc atp.).	24 hod.	10 pracovních dnů

Lhůty se ve věcech reakčních dob (Response time) pro řešení incidentů počítají v rámci pracovní doby Zadavatele, tedy běh lhůty se pozastavuje na konci každého pracovního dne a obnovuje na počátku pracovní doby následujícího pracovního dne. Pracovní doba se definuje dle aktivního typu SLA. Pozastavení počítání lhůty s koncem pracovní doby neplatí pro řešení chyby kategorie A. Není-li vzájemně dohodnuto jinak, lhůta pro měření doby reakce a doby odstranění incidentu započne běžet časem předání incidentu Dodavateli a bude ukončena v čase předání vyřešeného incidentu zpět Zadavateli. Celková doba odstranění je pak součet všech časových dob, po které byl incident v řešení na straně Dodavatele. Z celkové doby odstranění incidentu jsou vyloučeny časové doby, kdy Dodavatel prokazatelně nemohl pokračovat v řešení incidentu z důvodů, které nebyly jim způsobené.

Pro výpočet lhůt jsou určující časové záznamy v systému HelpDesk k danému incidentu. Podrobný popis způsobu předávání incidentů bude ukotven v detailním dokumentu popisující proces incident management, který předloží Dodavatel k akceptaci Zadavateli v rámci návrhu cílového konceptu (1 měsíc od data účinnosti Smlouvy).

5.4.6Součinnost, způsob plnění, akceptace

Zadavatel poskytne Dodavateli součinnost v následujícím rozsahu:

• Zadavatel umožní odborným pracovníkům Dodavatele provádět fyzické prohlídky provozního prostředí Středočeského kraje, ve kterém bude provozován dotační systém

• Zadavatel zajistí a poskytne Dodavateli přístup do úložiště dokumentů a repositářů, které budou sloužit ke sdílení veškerých elektronických dokumentů, architektonických návrhů a balíčků zdrojových kódu vytvořených Dodavatelem v rámci plnění této veřejné zakázky.

• Plnění služby je zahájeno dnem akceptace výstupů služby „Uvedení systému do produkčního provozu“ a její plnění Dodavatel vykazuje do protokolu na měsíční bázi. Protokol vyhodnotí stav plnění všech parametrů SLA (Response time, Fix time) dle kategorie Ticketu, dále udává statistické informace jako průměrné splněné SLA hodnoty, průměrné nesplněné SLA hodnoty, celkový počet Ticketů dle stavu a kategorie, a jiné relevantní údaje podle dohody se Zadavatelem. Čas podpory se měří pomocí HelpDesku Zadavatele.

5.5Rozvoj systému

5.5.1Vymezení rozsahu

Provádění rozvojových aktivit zahrnuje:

• Rozvoj systému, vyžadující služby přesahující standardní podporu a údržbu do maximálního rozsahu 600 MD v rámci 5 let podpory (120MD/rok)

• Ostatní služby v rámci aktuálních potřeb a poptávky SčK (např. migrace dat dle zadání SčK, tvorba nadstandardních sestav apod.)

• Realizaci nových integračních vazeb, rozšíření funkcí

• Účelová a zakázková školení na poptávku, workshopy

• Podpora Zadavatele na jeho výzvu pro účely případné migraci systému do nového prostředí (např. kontrola integrity dat, konzultace migračních postupů apod.)

• Podpora při vytváření nových podkladů (formulářů, …) při zavádění či úpravě dotačních titulů

Zadavatel vytvoří přesné zadání požadavku na rozvoj systému. Dodavatel připraví odhad pracnosti (maximální limit) v hodinách jednotlivých rolí a související cenu úkonu dle nasmlouvaných sazeb. Zadavatel akceptuje odhad pracnosti Dodavatele. Dodavatel realizuje plnění rozvoje systému dle akceptovaných podmínek. Dodavatel odevzdá příslušnou dokumentaci změny, vzniklé zdrojové kódy a konfigurační předpisy.

V případě potřeby na změnu požadavku, zastavení práce na požadavku, nebo v případě potřeby koordinace řešení s dalšími dodavateli, eskaluje Dodavatel tyto informace bezodkladně na Zadavatele.

5.5.2Součinnost

Zadavatel poskytne Dodavateli součinnost v následujícím rozsahu:

• Zadavatel umožní odborným pracovníkům Dodavatele provádět fyzické prohlídky provozního prostředí Zadavatele

• Zadavatel zajistí a poskytne Dodavateli přístup do úložiště dokumentů a repozitářů, které budou sloužit ke sdílení veškerých elektronických dokumentů, architektonických návrhů vytvořených Dodavatelem v rámci plnění této veřejné zakázky.

• Zadavatel poskytne Dodavateli podporu při koordinaci činností s jinými dodavateli integrovanými nebo integrujícími své IS do prostředí Zadavatele. IT oddělení Zadavatele musí být informováno o veškeré písemné komunikaci mezi dodavateli

Výstupy jsou vykazovány do výkazu práce na měsíční bázi, dle odpracovaných půlhodin (0,5 hod.) za dané období. Výkaz dále obsahuje přehled všech požadavků na provedení dalších aktivit, které Xxxxxxxxx obdržel od Zadavatele, a jejich aktuální stav.

Způsob plnění, termíny, akceptace:

• Plnění služby je zahájeno dnem akceptace výstupů služby „Uvedení systému do produkčního provozu – vytvoření produkčního prostředí“

• Dodavatel je povinen udržovat službu dostupnou Zadavateli až do ukončení Smlouvy.

• Dodavatel bude fakturovat Zadavateli vždy jen skutečně provedené služby, odsouhlasené v akceptačním protokolu nebo výkazu práce, a to dle ceny odpovídající Smlouvě

• Fakturace bude provedena až po dokončení příslušného požadavku na rozvoj systému

5.6Znalostní podpora, nezbytné úkony při ukončení Smlouvy

Podpora a provedení nezbytných úkonů při ukončení smlouvy a předání služeb na jiného dodavatele zahrnuje následující požadavky na Dodavatele:

• Vypracování plánu exitu a podpory předávání znalostí novému dodavateli

• Předání veškeré zpracované technické a provozní dokumentace systému podle plánu

Zadavatel poskytne Dodavateli součinnost v následujícím rozsahu:

• Zadavatel umožní odborným pracovníkům Dodavatele provádět fyzické prohlídky provozního prostředí Zadavatele

• Zadavatel zajistí a poskytne Dodavateli přístup do úložiště dokumentů a repozitářů, které budou sloužit ke sdílení veškerých elektronických dokumentů, architektonických návrhů a balíčků zdrojových kódu vytvořených Dodavatelem v rámci plnění této veřejné zakázky

Zadavatel akceptuje od Dodavatele výstupy dle výše popsaných náležitostí.

Dodavatel je povinen poskytnout službu na výzvu Zadavatele, nejpozději však 2 měsíce před vypršením smlouvy.

Odměna za službu je zahrnuta v ceně poskytování podpory.

Vady rozvojových aktivit, respektive rozpory zjištěné a oznámené Zadavatelem Dodavateli během doby aktivní podpory a údržby je Dodavatel povinen na vlastní náklady odstranit bez zbytečného odkladu po jejich oznámení. Nejpozději však ve smluvně stanovených lhůtách. Dodavatel se zavazuje odstranit vady systému, které se na systému vyskytnou v průběhu záruční doby.

Dodavatel se zprostí odpovědnosti za vady v případě, prokáže-li, že vada byla způsobena poskytnutím nesprávných informací i ze strany Zadavatele či jeho nevhodnými pokyny, na kterých trval.

Zadavatel je povinen informovat Dodavatele o jakékoliv vadě systému, na niž se vztahuje záruka, bez zbytečného odkladu po jejím vzniku. Vady musí být již při jejich uplatnění srozumitelně a přesně popsány. Poté, co Zadavatel řádně nahlásí vadu prokazatelným způsobem, Dodavatel odstraní závady ve stanovených lhůtách dle jejich charakteru a závažnosti.

Za vady systému se nepovažují poruchy funkčnosti nebo odchylky od zadávací dokumentace, které jsou důsledkem:

• Použití systému či jeho části pro jiné účely, než pro jaké je určen dle dokumentace a použití systému či jeho části v rozporu s příslušnou dokumentací, která se váže k systému či jeho části

• Provedení změny systému či jeho části anebo jiný neoprávněný zásah Zadavatele nebo třetí strany bez vědomí a souhlasu Dodavatel

• Změny v SW nebo HW, na kterých systém pracuje nebo je s nimi propojen, nebo na kterých je jinak závislý, pokud tyto změny provedl Zadavatel nebo třetí strana bez vědomí a souhlasu Dodavatele

• Vada nebo porucha SW nebo HW, které nebyly předmětem dodávky, a na kterých systém pracuje nebo je s nimi propojen, nebo na kterých je systém závislý

6Požadavky na dodávaný systém

Funkční požadavky popisují, jaké chování, funkce a operace uživatelů musí systém nabízet a podporovat s ohledem na sledované cíle, prostředí, efektivnost a vhodnost řešení. Jedná se o detailně definované požadavky, které objasňují a identifikují nutné proveditelné, měřitelné a testovatelné úkony, aktivity a akce v rámci celého dotačního procesu.

6.1Funkční požadavky

Následující tabulka popisuje význam požadovaných funkčních požadavků systému.

		FUNKČNÍ POŽADAVKY
ID	Název požadavku	Popis požadavku
01	Filtrování vyhledávání v žádostech	Možnost nastavení aktivních filtrů pro vyhledávání napříč všemi žádostmi registrovanými v IS dle zadaných kritérií (fond, tematické zadání, rok, typ registrovaného žadatele, konkrétní žadatel, okres, ORP, stav atd., evidenční číslo, obec, stav, ...).
02	Nastavení termínů	Možnost nastavení termínů pro podávání různých typů žádostí, pro kontrolu žádostí pracovníky SčK (garant fondu, administrátor dotací) a pro hodnocení žádostí hodnotiteli a hlavním hodnotitelem.
03	Podání žádosti za dvě období	Možnost podávání žádostí ve dvou obdobích najednou (identifikace žádostí podle roků, ve kterých jsou rozpočtované peněžní prostředky pro daný program).
04	Role pracovníku KÚ	Prostředí backend pro role pracovníků KÚ (rozdělení rolí na prohlížení bez možnosti editace a role s možností editace přiřazených tematických zadání), např. Garanta fondu, administrátora dotací, uživatele a správce na základě registrace a přidělené úrovně oprávnění (napojení na AD/IDM), registrace může provádět i pracovník v roli správce. V jednom účtu by mělo také jít rozdělit role hodnotitele a hlavního hodnotitele.
05	Role hodnotitelů	Prostředí backend pro roli hodnotitel s možností prohlížení a hodnocení žádostí, generování protokolů hodnocení, a pro roli hlavní hodnotitel s možností kontroly stavu všech hodnocených žádostí v daném tematickém zadání (v rámci hodnotící komise), registrace může provádět pracovník v roli správce nebo garanti dotací. Jeden uživatel může zastupovat zároveň obě role ale pro různá TZ.
06	Design webové části	Webová část určená pro žadatele (frontend) dostupná z portálu SK v designu, který bude v souladu s vizuálním stylem webových stránek SK, tedy využití šablony pro weby státní správy Design systém GOV v3.4.0 a novější.
07	Informativní obsah úvodní stránky	V IS budou na úvodní stránce zveřejněny informace o vyhlášených programech včetně termínů pro podávání žádostí, v sekci „dokumenty“ budou zveřejněny programy, návody, manuály atd., a v sekci „kontakty“ budou zveřejněny kontakty na garanty jednotlivých programů (fondů, tematických zadání) a kontakty na technickou podporu IS. Aktualizace bude možná ze strany SK. Tyto kontakty se budou aktualizovat automaticky podle informací uživatelů, kteří tuto roli aktuálně zastávají.
08	Registrace žadatelů (integrace registrů)	Registrace dle typu žadatele. Pro právnické osoby vytvoření „profilu“ žadatele po vyplnění IČ a následném ověření v základních registrech (automatické vyplnění údajů - název žádajícího subjektu, adresa sídla, statutární zástupce, datová schránka, příp. další relevantní údaje) nebo případně v ISDS. Pro fyzické osoby vytvoření profilu na základě kombinace údajů jedné ze tří možností: a) jméno, příjemní a OP; b) jméno, příjmení, ID cestovního dokladu; c) jméno, příjmení, datum narození a bydliště a pro všechny tyto varianty ověření v základních registrech. V případě pokusu o opakovanou registraci hlásí nemožnost této registrace včetně důvodu (již existující registrace).
09	Registrace žadatelů (NIA ID / ISDS)	Registrace fyzické nebo právnické osoby na základě NIA ID nebo identifikátoru datové schránky jako jedinečného údaje. IS kontroluje jedinečnost právnické nebo fyzické osoby, zda již dříve neproběhla její registrace. V případě pokusu o opakovanou registraci hlásí nemožnost této registrace včetně důvodu (již existující registrace).
10	Typy registrovaných žadatelů	Typy registrovaných žadatelů – bude možnost editovat typy registrovaného žadatele fyzická osoba; fyzická osoba podnikající (OSVČ); školská právnická osoba dle zákona č. 561/2004 Sb., školský zákon; právnická osoba – obec; právnická osoba – dobrovolný svazek obcí; právnická osoba – spolek nebo pobočný spolek; příspěvková organizace (mimo příspěvkových organizací SK), která není školskou právnickou osobou; právnická osoba – dle zákona č. 90/2012 Sb., zákon o obchodních korporacích (obchodní společnosti a družstva); právnická osoba – ostatní (nadace, nadační fond, ústav, obecně prospěšná společnost); právnická osoba – dle zákona č. 3/2002 Sb., zákon o církvích a náboženských společnostech (registrovaná církev nebo náboženská společnost).
11	Založené žádosti žadatele	Registrovaný subjekt bude mít v rámci svého profilu k dispozici sekci zobrazující všechny jeho založené žádosti, podané i rozpracované ve všech fázích dotačního procesu.
12	Integrace databází a číselníků zadavatele	Možnost napojení IS na vlastní vložené seznamy a číselníky Zadavatele (přehledy počtu obyvatel obcí, seznam obcí HSOÚ, výše daňových příjmů obcí apod.), editaci těchto souborů bude moci provádět pracovník v roli správce nebo garanta.
13	Vkládání vlastních rolovacích seznamů	Možnost vložení výběrových rolovacích seznamů (seznamy okresů, ORP atd.) Zadavatelem.
14	Kalkulačka výpočtu výše dotací	Do IS bude zapojena stávající kalkulačka pro výpočet výše dotace.
15	Automatické doplnění identifikačních údajů žadatele do formuláře	Automatické doplňování identifikačních, případně dalších vybraných údajů z profilu žadatele do každého formuláře žádosti a formuláře závěrečného vyúčtování (ZVA) šablony protokolu, dopisu, smlouvy a dalších generovaných dokumentů.
16	Evidence	IS musí obsahovat evidence žadatelů a žádostí.
17	Exporty dat	Možnosti různých druhů exportů dat ve formátu xlsx/csv (xml, html, …) pro další zpracování, dle specifikací zadavatele.
18	Typy exportů	základní export – nastavení evidence zadavatelem vybraných dat; „big“ export – export všech údajů evidovaných v IS u každé žádosti; export „na přání“ – uživatelem backendu je definováno, která datová pole bude soubor obsahovat.
19	Podpora zpracování statistik	Zpracování statistik hodnocení žádostí dle roků, fondů, tematických zadání, hodnotitelů - přehledně, graficky přívětivě za použití editovatelného dashboardu.
20	Automatické zasílání notifikací	IS zasílá automatické textové notifikace pracovníkům KÚ na registrovaný e-mail, například upozornění na předpokládaný termín ukončení realizace projektu; IS zasílá automatické textové notifikace hodnotitelům na registrovaný e-mail, například upozornění na termín ukončení možnosti hodnocení vybraných žádostí; IS zasílá automatické textové notifikace žadatelům do registrované datové schránky, například informace o termínech pro odevzdání ZVA dle data uzavření smlouvy apod.
21	Hromadné textové zprávy žadatelům	IS umožní zaslat individuální i hromadné textové informace žadatelům do registrovaných datových schránek (u fyzických osob s možností i do registrovaných e-mailů, pokud nemají dat. schránku), které zpracuje a odešle administrátor dotací nebo garant. Výběr příjemců je určen seznamem s možností filtrace dle funkčního požadavku 01.
22	Automatické odhlášení uživatele	Automatické odhlášení z IS po 30 minutách nečinnosti.
23	Obsah formuláře žádosti	Základní data, která bude obsahovat formulář žádosti (jedná se o automatický obsah šablony pro vytváření formulářů, která bude dále upravována): název programu a tematického zadání, případně oblasti podpory; unikátní evidenční číslo žádosti, obsahující kód fondu nebo programu, tematického zadání a rok; údaje generované z profilu žadatele (název žadatele, právní forma žadatele, IČ/datum narození, DIČ, adresa sídla/bydliště, okres, ORP, korespondenční adresa, všechny kontaktní údaje, statutární zástupce, osoby zastupující právnickou osobu, bankovní spojení atd.); údaje o kontaktní osobě; počty obyvatel obce; zda se projekt týká veřejné správy nebo ekonomické činnosti; zda je žadatel plátce DPH a zda uplatní odpočet DPH; název projektu; místo realizace projektu; popis a způsob realizace projektu; termíny zahájení a ukončení realizace projektu; stav přípravy projektu; celkové náklady projektu; u spolufinancovaných projektů výše finanční podpory poskytnutá prvoposkytovatelem, případně z jiných veřejných zdrojů; požadovaná výše podpory (možnost rozdělení na investice a neinvestice); výše finanční spoluúčasti; % spoluúčasti (počítá IS); seznam povinných (případně nepovinných) příloh; povinná prohlášení žadatele.
24	Editace formulářů	Možnost pružně přidávat zatím blíže neurčená datová pole a upravovat formuláře pro proškolené uživatele backendu s příslušným oprávněním dle tematického rozdělení formulářů, včetně možnosti editace popisků jednotlivých datových polí. Garanti fondů budou moci při vytváření formuláře přidávat validační kritéria jak v očekávaném datové typu daného pole (číslo, datum, email, volný text, …), tak také min/max kritéria (maximální velikost čísla, maximální počet znaků, …), také bude možné u každého pole určit, zda je povinné či volitelné.
25	Validace vyplnění datových polí	IS zajišťuje základní kontrolu správnosti vyplnění datových polí (požadovaného formátu vkládaných hodnot, formátování data a času, stanovení minimální a maximální délky textu vkládání speciálních znaků atd.), pokyny pro požadované formáty budou uvedeny v popiscích u jednotlivých datových polí.
26	Průběžné ukládání informací doplněných do formuláře	Možnost průběžného doplňování a ukládání formulářů registrovaným žádajícím subjektem.
27	Evidenční číslo žádosti	Po prvním uložení formuláře žádosti IS vygeneruje evidenční číslo žádosti, a žádost bude možno sledovat uživateli backendu (bez možnosti editace).
28	Identifikace chybně vyplněných polí	IS označuje chybně vyplněná pole, a zobrazuje vysvětlující chybové hlášky s uvedením možností nápravy chyb.
29	Automatická selekce fondů a tematických zadání	Registrovanému žadateli IS zpřístupní pouze možnost žádostí z fondů a tematických zadání, ve kterých je žadatel dle typu své registrace oprávněn podávat žádost.
30	Přílohy k žádostem	Možnost připojování různých typů elektronických příloh (doc, xlsx, pdf, zip) k žádostem.
31	Tisk žádosti	Možnost generování (tisku) žádosti do formátu pdf. Šablona pro tisk je pro každý fond a tematické zadání vlastní a odpovídá obsahově webovému formuláři.
32	Elektronický podpis	Možnost elektronického podpisu formuláře žádosti přímo v aplikaci a jeho odeslání (podání) (datové schránky, certifikovaný elektronický podpis).
33	Nastavení oprávnění v IS	Přístup do backendu pouze po registraci oprávněných osob (pracovníků KÚ) v různých úrovních oprávnění dle požadavků (uživatel s možností nahlížení, uživatel s možností editace stanovených dat, hodnotitel, hlavní hodnotitel).
34	Napojení registrů pro ověření	Napojení backendu na další registry (Registr plátců DPH, Živnostenský rejstřík, Ústřední seznam kulturních památek, Evidence skutečných majitelů (ISSM), Registr de minimis, Katastr nemovitostí, Rejstřík spolků, Rejstřík obecně prospěšných společností, Rejstřík sportu NSA apod.) pro provádění dílčích odvětvových kontrol, pokud je to technicky proveditelné (registry to podporují).
35	Integrace na IS GINIS	Napojení na IS GINIS, (elektronická spisová služba včetně archivace dokumentů, SML, POU), postupně napojení i na další ekonomické moduly dle potřeb Zadavatele.
36	Zaslání žádosti k doplnění	Možnost vrácení žádosti oprávněným pracovníkem KÚ pouze k doplnění formuláře žádosti, nebo pouze k doplnění povinných příloh, nebo k doplnění žádosti i příloh – zaslání informace žadateli a zaznamenání v historii žádosti.
37	Změny stavů žádosti	IS umožní provádět změny stavů žádostí pracovníky KÚ s oprávněním editace určitých tematických zadání, vybrané změny stavů provádí IS automaticky, všechny změny stavů jsou zaznamenány v historii žádosti.
38	Datum uzavření smlouvy	Při uzavření smlouvy bude automaticky vyplněno a logováno datum uzavření.
39	Číselník stavů	Vytvoření editovatelného číselníku stavů a detailní specifikace stavů bude upřesněna v rámci analýzy dodavatele: příprava – po založení žádosti žadatelem – žádosti lze editovat; podáno – automatická změna – žádost už nelze editovat; zkontrolováno – ruční změna pracovníkem KÚ; vráceno k doplnění příloh – ruční změna pracovníkem KÚ – neotevírá IS k úpravě samotné žádosti; vráceno k doplnění žádosti – ruční změna pracovníkem KÚ – neotevírá IS k úpravě příloh; vráceno k doplnění žádosti a příloh – ruční změna pracovníkem KÚ; doplněno – automatická změna po odeslání doplněné žádosti žadatelem zpět; nedoplněno – ruční změna pracovníkem KÚ; nepodáno řádně – ruční změna pracovníkem KÚ; zrušeno – ruční změna pracovníkem KÚ; vyřazeno – ruční změna pracovníkem KÚ; zpracováno – ruční změna pracovníkem KÚ; hodnoceno – automatická změna při ohodnocení žádosti hodnotitelem; schváleno – ruční změna pracovníkem KÚ – hromadné změny; neschváleno – ruční změna pracovníkem KÚ – hromadné změny; příprava smlouvy – ruční změna pracovníkem KÚ – hromadné změny; zpracování smlouvy – automatická změna po odeslání přípravy smlouvy žadatelem zpět; smlouva – ruční změna pracovníkem KÚ (případně při napojení na GINIS možnost automatické změny); k proplacení – ruční změna (případně při napojení na GINIS možnost automatické změny); proplaceno – ruční změna (případně při napojení na GINIS možnost automatické změny); ukončeno – ruční změna (případně při napojení na GINIS možnost automatické změny).
40	Hromadná změna stavů	Možnost hromadných změn stavů u zvolených žádostí (lze filtrovat) s hromadným zasláním textových notifikací.
41	Sledování stavu žádosti	Možnost sledování stavu žádosti oprávněným žadatelem v průběhu celého dotačního procesu s automatickým zasláním notifikace při změně stavu.
42	Sledování změn stavu	Možnost sledování změn stavů žádostí pro uživatele backendu v průběhu celého dotačního procesu.
43	Generování protokolů	Možnost generování protokolů formální kontroly, dopisů, popisných štítků apod. dle zadaných šablon.
44	Zpřístupnění el. formuláře	Zpřístupnění elektronického formuláře pro hodnocení v backendu.
45	Prohlížení žádostí	Možnost prohlížení žádostí včetně přiložených příloh.
46	Hodnotící kritéria	Hodnocení podle hodnotících kritérií jednotlivých tématických zadání.
47	Automatické generování seznamu žádostí	IS automaticky vyfiltruje hodnotitelům seznam žádostí v určených stavech (zkontrolováno a doplněno) a hodnotitelé mohou hodnotit pouze žádosti v těchto stavech.
48	Počet žádostí	IS zobrazuje informace o počtu ohodnocených žádostí.
49	Body hodnocení u žádosti	Zobrazení přidělených celkových bodů u jednotlivých ohodnocených žádostí.
50	Protokoly hodnocení	IS bude umět generovat protokoly hodnocení.
51	Náhled hodnocení pro hlavního hodnotitele	Možnost náhledu na stav všech hodnocených žádostí pro hlavního hodnotitele dle jednotlivých tématických zadání, možnost generování hromadného protokolu za hodnotící komisi.
52	El. formulář pro přípravu smlouvy	Zpřístupnění elektronického formuláře pro přípravu smlouvy ve frontendu. Jedná se o základní údaje, které budou doplněny do finální smlouvy s možností editace vybraných prvků (číslo účtu, …).
53	El. formulář pro zpracování smlouvy	Zpřístupnění elektronického formuláře pro zpracování smlouvy v backendu.
54	Generování smluv dle šablon	Generování smluv dle zadaných šablon, při generování smluv IS bude spolupracovat s GINIS SML.
55	Vložení uzavřené smlouvy	Možnost vložení uzavřené smlouvy do IS tak, že smlouva bude po přihlášení k dispozici i žadateli (příjemci podpory).
56	Vytvoření platebního poukazu	Pro vytvoření platebního poukazu bude IS spolupracovat s GINIS POU.
57	Zpřístupnění elektronického formuláře ZVA	Uživatel má možnost vyplnění a editování datových polí formuláře ZVA a zároveň může přikládat povinné přílohy (skeny účetních dokladů, dokladů o provedení úhrady, fotografie apod.).
58	Automatické vyplnění el. formuláře ZVA	Automatické vyplnění některých dat do formuláře ZVA ze žádosti dle zadané logiky a kontrola přiložení všech povinných příloh.
59	Změna projektu	IS umožní podat žádost o změnu projektu (změna závazných minimálních parametrů, prodloužení termínu realizace projektu, změna charakteru podpory – investice/neinvestice atd.), v rámci IS musí být přednastavena šablona žádosti o změnu, po schválení bude IS generovat dodatek ke smlouvě dle nastavené šablony.
60	Kybernetická bezpečnost	Implementace a provoz IS musí být v souladu s požadavky na kybernetickou a informatickou bezpečnost dle aktuálně platného Zákona o KB a dalších opatření a povinností dle příslušných vyhlášek o KB.
61	Role garanta v rámci hodnocení	Garanti mají možnost vytvářet a editovat hodnotící formulář pro svá tématická zadání pomocí předpřipravené šablony. Dále mohou k svým tématickým zadáním přiřazovat uživatele v roli hodnotitele a hlavního hodnotitele (na základě rozhodnutí výboru/rady kraje).
62	Integrace systému do Nagios	IS musí být napojen na sledovací systém Nagios, aby bylo možné sledovat stav a parametry běhu systému. Dodavatel poskytne součinnost při napojení na sledovací systém.
63	Checklist	Při tvorbě nového tématického zadání (TZ) se bude pro dané TZ tvořit zároveň checklist dokumentu pro uživatele backendu, kteří budou kontrolovat, zda jsou splněny veškeré záležitosti. Tento checklist se bude vytvářet z předpřipravených modulů požadavků, které bude možné přidávat či odebírat, pevně daných modulů, které jsou společné pro všechny TZ (kontrola finančních hodnot, kontrola shody názvu projektu, ...) a automaticky doplněných částí, které vychází z požadavků daného TZ. Tento checklist se následně zobrazí uživateli backendu při kontrole žádosti a zároveň se bude průběžně ukládat stav (počet splněných bodů).
64	Výběr příloh	Při tvorbě TZ bude možné krom vytvoření formuláře přidat požadavek na povinné přílohy pro dané TZ. Tento seznam povinných příloh bude možné vybrat z konečného předem definovaného seznamu příloh. Systém bude následně vyžadovat, aby pro každou požadovanou přílohu byl nahrán soubor, než bude moct žadatel zaslat žádost ke kontrole. Tento seznam zvolených příloh bude následně propsán do checklistu z požadavku 62, aby mohl uživatel backendu kontrolující náležitosti žádosti ověřit správnost příloh.
65	Přihlášení uživatelů	Pro přihlášení žadatelů lze využít všech způsobů, které jsou podporovány při registraci (e-mail + heslo, datovou schránku, NIA ID, …), uživatelé backendu budou identifikování pomocí kombinace uživatelského jména a hesla s budoucím napojením na IDM a podporou dvoufázového ověřování.
66	Heslo	Uživatel má možnost provést změnu či obnovu hesla. Heslo musí být v databázi zašifrováno včetně využití kryptografické soli.
67	Stav fondu/TZ	Stav fondu je buď aktivní, kdy lze podávat nové žádosti, nebo neaktivní, kdy je podávání žádostí zastaveno. Stav se automaticky mění po uplynutí nastaveného termínu nebo ho lze změnit manuálně. Toto oprávnění má garant fondu pro své fondy/ZD nebo správce systému pro všechny fondy/ZD.
68	Přístupnost	Systém musí splňovat požadavky na přístupnost dle zákona 99/2019 Sb. "Zákon o přístupnosti internetových stránek a mobilních aplikací a o změně zákona č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů".
69	Editace žádosti	Aplikace umožňuje úpravu žádosti v průběhu její přípravy. Editace není možná po podání žádosti. Oprávněný pracovník úřadu může ale žádost vrátit žadateli k doplnění. V takovém případě je úprava možná.
70	Prohlížení žádosti	Pracovník úřadu s potřebnými právy si může prohlédnou žádosti a to včetně rozpracovaných. Může tak případně reagovat na dotazy žadatelů i v průběhu přípravy žádosti. Pracovník úřadu si může též vygenerovat žádost v PDF.

6.2Nefunkční požadavky

Následující tabulka popisuje význam nefunkčních požadavků.

Nefunkční požadavky specifikují vlastnosti nebo omezující podmínky IS (kvalita, technologická a metodická podpora, dokumentace atd.). Jedná se o požadavky na vyvinutí kvalitního a stabilního systému, který bude výkonný, spolehlivý, škálovatelný, rozšiřitelný, udržitelný, spravovatelný a bezpečný.

Následující tabulka popisuje význam nefunkčních požadavků.

		NEFUNKČNÍ POŽADAVKY
ID	Název požadavku	Popis požadavku
01	Testovací prostředí	Vytvoření testovacího prostředí frontend i backend části nového IS. Koordinace pilotního testování IS.
02	Migrace dat	Zajištění migrace základních dat (určených zadavatelem) ze stávajícího IS (50 000 žádostí, 11 000 uživatelů, 400MB dat v DB a 80GB dat ve FS).
03	Koordinace doplnění vstupů	Koordinace doplnění dalších vstupů pro potřeby vytvoření architektury IS (struktura dat, struktura šablon, reportů atp.).
04	Podpora	Technologická a metodická podpora na 60 měsíců.
05	Uživatelská příručka pro žadatele	Vytvoření uživatelské příručky pro žadatele a zpracování videopříručky pro vyplnění žádosti o dotaci.
06	Uživatelské příručky pro pracovníky KÚ	Vytvoření uživatelské příručky pro pracovníky KÚ, uživatele backendu.
07	Uživatelské příručky pro hodnotitele	Vytvoření uživatelské příručky pro role hodnotitelů a hlavních hodnotitelů.
08	Uživatelská příručka pro správce	Vytvoření uživatelské příručky pro správce systému.
09	Školení uživatelů backendu	Proškolení všech rolí uživatelů backendu a správce v rozsahu: administrátora dotací 1x4 hodiny; garanta fondu 2x 4 hodiny; správce 4x4 hodiny; hodnotitelů a hlavních hodnotitelů 1x4 hodiny.
10	El. dokumentace	Technická a uživatelská dokumentace v elektronické formě.
11	Neomezený počet fondů	Nový IS bude připraven pro neomezený počet fondů a tematických zadání včetně formuláře pro individuální finanční podporu.
12	Počet uživatelů	Systém musí být schopen udržovat alespoň 1000 v různých rolích aktivních uživatelů backendu a 50 000 aktivních uživatelů frontendu (žadatelů).
13	Počet současně přistupujících uživatelů	Systém musí podporovat současnou práci alespoň 1000 uživatelů v různých rolích (frontendu i backendu).
14	Odezva systému	Rychlost odezvy při vyplňování žádosti – odeslání požadavku z prohlížeče a vrácení odpovědi musí proběhnout do 2 sec.
15	Rychlost generování	Systém musí být schopen generovat dokumenty ve zvoleném formátu do 5 sec.
16	Počet žádostí v systému	Systém musí být schopen udržovat alespoň 100 000 nových žádostí + migrovaná data (cca 50 000 žádostí).
17	Požadavky na otevřený formát	Systém musí zadavateli umožnit bezúplatné poskytnutí licence nebo podlicence dalším subjektům veřejné správy na území ČR s možností zajistit servis, podporu a rozvoj systému prostřednictvím třetí strany nezávislé na dodavateli.

7Související ujednání

Tato kapitola shrnuje doporučení na smluvní ujednání, která doplňují požadavky Zadavatele na dodávky dílčích služeb.

7.1Úložiště, repozitáře, zdrojové kódy

Zadavatel zajistí a poskytne Dodavateli přístup do úložiště dokumentů a repositářů, které budou sloužit ke sdílení/ukládání veškerých elektronických dokumentů, architektonických návrhů a balíčků zdrojových kódu vytvořených Dodavatelem v rámci plnění této veřejné zakázky.

7.2Další povinnosti Dodavatele

Dodavatel bere na vědomí požadavky vyplývající ze ZZVZ, GDPR, ZoKB, ZoISVS a souvisejících předpisů. Zejména se jedná o:

• Povinnost řídit se těmi právními předpisy a souvisejícími vnitřními předpisy Středočeského kraje

• Povinnost poučit a zaškolit všechny svoje pracovníky přidělené na projekt v rozsahu odpovídajícím interním školením Středočeského kraje v oblastech – bezpečnost práce, kybernetická bezpečnost, ochrana osobních údajů a jiné relevantní

• Povinnost hlásit případné zjištěné události a incidenty, bezpečnostní incidenty a porušení ochrany osobních údajů v provozu Informačního systému pro správu finanční podpory Středočeského kraje, včetně neprodlené přípravy podkladů k incidentům a povinnosti spolupracovat na vyšetření a vyřešení těchto incidentů

• Povinnost spolupracovat s kontrolními orgány Středočeského kraje a státní správy v případně jejich žádosti

• Změny  osob realizačního týmu, jimiž dodavatel prokazoval splnění požadavků na prokázání technické kvalifikace, jsou možné jen osobami se stejnou nebo vyšší kvalifikací, jako při vlastní kvalifikaci a podléhá schválení zadavatele

• Dodavatel zaručí dostatečnou kontinuitu projektového týmu v rámci celém průběhu projektu

Dodavatel je povinen nad rámec svých zákonných povinností se při výkonu činnosti pro Zadavatele řídit i platnými předpisy krajského úřadu, které budou validovány při podpisu smlouvy. Jedná se zejména o bezpečnostní řád, provozní řád parkovacích míst KÚ, směrnici č. 71 o BOZP, pokyn ředitele KÚ č. 5/2018 o zpracování osobních údajů, pokyn č. 6/2018 o informační a kybernetické bezpečnosti, č. 5/2017 k pravidlům vstupu, vjezdu a pobytu v budově sídla KÚ a dalšími relevantními dokumenty.

8Přílohy

Příloha č. 1: Kalkulační model (příloha č. 4 Zadávací dokumentace)

Technické podmínky – Příloha č. 3 Zadávací dokumentace Strana 1