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
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
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í |
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.
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.
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.
Údržba, podpora – po dobu 60 měsíců.
Následný rozvoj – po dobu 60 měsíců v rozsahu 120MD/rok.
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:
Uzavření smlouvy T0 (začátek projektu).
Podrobný návrh cílového konceptu řešení T0 + 1 měsíc.
Revize a akceptace cílového konceptu objednatelem T0 + 6 týdnů.
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í.
Spuštění produkčního provozu T0 + 6 měsíců.
Údržba a podpora provozu – po nasazení do produkce + 60 měsíců.
Následný rozvoj aplikace – po nasazení do produkce + 60 měsíců.
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:
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.
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.
Aktualizace dodavatelem zpracované dokumentace, školení uživatelů a řízení změn.
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:
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.
Provedení migrace dat ze současného systému „eDotace“ či testovací instance.
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 |
Řešení do |
1 – kritická Kategorie vady A |
|
1 hod. |
4 hod. |
2 – vysoká Kategorie vady B |
|
4 hod. |
8 hod. |
3 – střední Kategorie vady C |
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 |
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
|
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 kalkulačka pro výpočet výše dotace se stejnou funkcionalitou jako kalkulačka stávající viz xxxxx://xxxxxx.xx-xxxxxxxxxxx.xx/xx-xxxxxx-xxxxxxxxxxx/xxxxxxxxxx/xxxxx. Kalkulačka funguje pouze pro žadatele registrované jako „právnická osoba – obec“ a bližší popis je v poznámce pod tabulkou funkčních požadavků.
Poznámka k funkčnímu požadavku
Kalkulačka vypočítá maximální možnou výši dotace v Kč |
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ů |
|
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í |
|
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):
|
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 |
Pro potřeby automatizace zpracovávání ekonomických údajů předpokládá Zadavatel, že v budoucnu vyzve dodavatele k návrhu na vytvoření vazeb na ekonomický systém GINIS (moduly SML, POU, SSL, … tj. smlouvy, poukazy, spisová služba, …). Dodavatel bude osloven s konkrétním zadáním a popisem a bude to řešeno v rámci rozvoje aplikace. |
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:
|
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. |
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 |
Tento funkční požadavek se zcela vypouští. |
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:
|
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 / 1 strana A4. |
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, revize k 14.11.2023 Strana 1