Zadávací dokumentace – Příloha č. 3.b

Pojem	Význam
AIS, IS AIS	Agendová část informačního systému města
IS AIS ŽP	Agendová část informačního systému města – agendy životního prostředí
IS AIS SSUV	Agendová část informačního systému města – agendy speciálního stavebního úřadu vodoprávního
IS AIS SH	Agendová část informačního systému města – agendy silničního hospodářství
IS AIS SCP	Agendová část informačního systému města – agendy centrální správy požadavků
IS PO	Portál občana – stávající část informačního systému jako komunikační rozhraní pro komunikaci občanů s úřadem
SSL	Elektronická spisová služba nebo také ICZ e-spis®
Fáze A	Implementace SYSTÉMU (nebo také dílo, nebo také projekt) v souladu se Smlouvou o dílo
Fáze B	Servisní (technická) podpora SYSTÉMU v souladu se Smlouvou o podpoře
Smlouva o dílo	V rámci tohoto dokumentu je pojmem Xxxxxxx o dílo myšlena Příloha č. 4.a ZD
SYSTÉM	V rámci tohoto dokumentu je pojmem SYSTÉM myšlen Informační systém Centralizace správy uživatelů; Elektronizace vybraných agend IS; Centrální správa přestupků; Nástroj pro centrální evidence úřadu; Formulářová komunikace, dále také pojmenovaný zkratkou AIS
NSESSS	Národní standard pro spisové služby (viz. xxx.xxxx.xx)

2Místo plnění

Je sídlo MÚ města Beroun – specifikované v Zadávací dokumentaci

3Doba plnění

Dodávka jednotlivých částí bude zahájena po podpisu smlouvy příslušné části VZ a bude řízena milníky uvedenými v Tabulce níže
Milníky Fáze A dané části VZ (implementace) dle Smlouvy.

Id	Činnosti		Termín
01	Podpis a nabytí účinnosti Xxxxxxx o dílo		Zadavatel předpokládá červenec 2019
Fáze A – Implementace SYSTÉMU
02	Zpracování a akceptace Detailního cílového konceptu Výstupem bude dokument Detailní cílový koncept Předání dílčího plnění a Akceptace dílčího plnění		do 8 týdnů od nabytí účinnosti smlouvy
03	Instalace SW Předání dílčího plnění		do 3 týdnů po Id 02
04	Zkušební prostředí a produkční provoz s podporou	Implementace zkušebního (testovacího) prostředí Vytvoření testovací prostředí (vč. požadovaných rozhraní) Školení uživatelů, konzultace Akceptace Testovacího provozu a školení	do 6 týdnů po Id 03
05	Zkušební prostředí a produkční provoz s podporou	Produkční provoz s podporou Vytvoření produkčního prostředí (vč. požadovaných rozhraní), metodické a konzultační služby Akceptace produkčního provozu, akceptace Fáze A Dodání licencí SW Ukončení Fáze A	do 5 týdnů po Id 04

Fáze B – Servisní (technická) podpora SYSTÉMU dle Smlouvy o podpoře bude zahájena ukončením Fáze A (ukončení projektu akceptací produktivního provozu s podporou).
Termín ukončení se může změnit z objektivních příčin, způsobených třetími stranami nebo jinými okolnostmi, nezávislými na vůli smluvních stran.

4Způsob prokázání splnění požadavků minimálního plnění

Zadavatel požaduje, aby Dodavatelem nabízená dodávka splňovala veškeré dále uvedené požadavky (funkcionality a parametry) a tyto byly zahrnuty v nabídce Dodavatele a v celkové nabídkové ceně.
Dodavatel ve své nabídce jednoznačně deklaruje splnění, popřípadě absenci každého níže uvedených požadavků v tabulkách označených jako „Minimální požadavky …“, a to vyplněním příslušného pole „Splněno“ jedno ze dvou nabízených možností:

„ANO“ v případě že dodávka Dodavatele (Nabídka) minimální požadavek splňuje

nebo „NE“ v případě že dodávka Dodavatele (Nabídka) minimální požadavek nesplňuje

Zadavatel požaduje po Dodavatelích, aby uvedli informaci o skutečné funkcionalitě nabízeného systému, kterou bude možné ověřit v nasazeném systému již v testovacím provozu (Testovací provoz, např. v rámci školení uživatelů a administrátorů).

Nesplnění kteréhokoli ze stanovených minimálních požadavků bude znamenat vyloučení účastníka ze zadávacího řízení.
Zadavatel požaduje, aby Dodavatel, kromě vyplnění tabulek v kapitole 5, podrobně popsal návrh nabízeného řešení v samostatné kapitole.
Tato kapitola 4 platí pro následující kapitoly 5 až 7.

5Požadavky na SYSTÉM

Dodávkou SYSTÉMU dojde k elektronizaci a integraci do stávajícího IS města všech popisované funkcí a budou naplněny všechny požadované související legislativní povinnosti.
Popis požadovaného rozsahu řešení je rozdělen do aktivit 1 až 6 specifikovaných v kapitolách 5.2 až 5.7

Aktivita 1 - Centralizace správy uživatelů;

Aktivita 2 - Elektronizace vybraných agend IS;

Aktivita 3 - Centrální správa přestupků;

Aktivita 4 - Nástroj pro centrální evidence úřadu;

Aktivita 5 - Formulářová komunikace.

v rozsahu:

dodávky licencí;
instalace aplikační a databázové části systému včetně vytvoření testovací instance;
implementačních služeb:

provedení integrací na nové i současné systémy v prostředí IS zadavatele;
migrace dat z jednotlivých nahrazovaných systémů do dodávaného řešení;
úpravy dodaného řešení dle potřeb a požadavků dle pokynů zadavatele;
tvorba šablon/vzorů pro nově pořizované produkty;
zaškolení uživatelů a administrátorů;
testování;
zvýšené podpory v předproduktivním provozu;
zvýšené podpory ve vybraném úseku produktivního provozu.

dokumentace:

k dodaným informačním systémům v požadovaném rozsahu;
k dodaným integračním rozhraním;
eLearningové kurzy k dodaným informačním systémům (v technologii html).

Zadavatel požaduje vytvoření a provoz dvou prostředí – produkčního a testovacího (školícího) po celou dobu nasazení u zadavatele.

Zadavatel požaduje udržení testovacího prostředí po celou dobu udržitelnosti projektu (5 let od akceptace předmětu plnění).

5.1Společné vlastnosti řešení

Uvedené parametry a vlastnosti řešení v níže uvedené tabulce znamenají minimální míru plnění dle této ZD.

ID	Obecné principy a technologické vlastnosti	Splněno
1	Kompletní lokalizace aplikační části (tj. všech produktů z pohledu licencí) v českém jazyce, vč. dokumentace k předmětným licencím.
2	Soulad všech agend a částí systému s platnou legislativou na území ČR platnou pro subjekty veřejné správy (orgány veřejné moci).
3	Plně elektronizované řešení, nahrazující v implementovaných oblastech papírový oběh dokumentů.
4	V rámci systému zadávání dat pouze jednou, se sdílením dat v dalších oblastech / modulech systému, okamžitý přístup k těmto datům ve všech oblastech / modulech.
5	Pohledy nad daty (základní pohledy, výsledky hledání - filtrování atd.) lze třídit dle různých kritérií vybraných uživatelem, následně vygenerovat výstupní sestavu, kterou bude možno zobrazit na obrazovce, tisknout na tiskárně nebo exportovat do běžných formátů (XLS, XML, DOC, HTML, PDF).
6	Garance přímého tisku ze všech oblastí / agend.
7	V rámci systému garance tvorby uživatelských výstupních sestav na úrovni administrátora systému.
8	Logování operací – všechny kroky a operace prováděné v systému jsou ukládány, a je možné je zpětně dohledat / vyhledat a za konkrétního uživatele v daném období, tak za danou oblast / modul v daném období.
9	Administrace a konfigurace IS bez nutnosti zásahu zhotovitele a rozšíření licenčního modelu, a to na principu vzniku nové agendy či nového procesu v rámci systému.
10	Řešení bude provozováno na principu tenkého klienta, tj. bez nutnosti instalace aplikace či podpůrného SW na lokálních stanicích uživatelů.
11	Součástí nabídky budou zahrnuty veškeré náklady spojené se součinností stávajících dodavatelů systémů (tj. pořízení licence, součinnosti při implementaci a provozní náklady).
12	Dodavatel v nabídce podrobně popíše způsob integrace jím nabízených software komponent se systémy, se kterými je požadována integrace, v dostatečném detailu, který umožní posoudit praktickou možnost realizace navrhovaného technického řešení ve stanoveném harmonogramu.
13	Součástí licencí SYSTÉMU jsou i licence konektorů pro integraci vůči externím systémům, tzn. z pohledu licencí nebude zadavatel pro účely další integrace nucen pořizovat žádné další licence rozhraní. Aplikační rozhraní bude poskytnuté jako součást plnění a jeho využití nebude vyžadovat žádné další náklady pro zadavatele (např. dokupování licencí, navyšování servisní podpory, apod.).
14	Nastavení všech parametrů SYSTÉMU bez nutnosti zásahu dodavatele.

5.2Aktivita 1 - Centralizace správy uživatelů

Centralizace správy uživatelů bude řešit potřebu evidování organizační struktury, rolí, funkčních míst a přiřazení zaměstnanců a bude propojený na další komponenty informačního systému města.

Současný životní cyklus identit je řešen téměř výhradně jen procesně, relativně složitě a s poměrně velkým počtem aplikací. Takový systém je náchylný k chybám a obtížně se audituje.

Implementace Centrální správy uživatelů – dále v textu jako Identity management nebo IDM umožní centralizovanou správu organizační struktury a přístupových práv v prostředí Windows nebo vlastních aplikací provozovaných v prostředí úřadu. IDM bude primárně napojen na personální aplikaci IS města, jako na nositele zdrojových informací o uživatelích a bude dále přenášet a aktualizovat adresářovou službu (LDAP, AD).

IDM bude udržovat evidenci uživatelů, jejich zařazení v organizační struktuře, bude přiřazovat jednotlivé organizační role, definovat činnosti, spravovat profily a řídit přístupová oprávnění do aplikací. Tento způsob správy identit počítá s jednotným administrativním místem pro aktivaci a deaktivaci účtů a také k řízení životních cyklů účtů, rolí a profilů. Výstupem bude tak kompletní přehled o přístupových právech uživatelů a tím také zvýšená bezpečnost informačního systému jako celku. Prostřednictvím IDM se budou automatizovat procesy související se synchronizováním uživatelských informací, přičemž se striktně prosazuje dodržování politiky, kdo smí sledovat anebo měnit data, a které autoritativní zdroje by měly být určeny pro jaké typy dat. Automatizace se také týká rutinních postupů aktivace či deaktivace, snižování provozních nákladů a snižování výskytu chyb (například uživatelům, kteří z různých důvodů nemají mít přístup ke zdrojům, bude tento přístup deaktivován ve všech systémech a to okamžitě). Tím se eliminují bezpečnostní rizika způsobená zneužitím zapomenutých, nepoužívaných, ale nadále aktivních účtů. Identity Management bude obsahovat Workflow pro modelování procesů vedoucích k vytvoření požadovaného účtu či nastavení atributů při zachování všech formálních požadavků na takový proces. IDM bude implementován v serverovém prostředí technologického centra města, bude provozován na virtuálních serverech v režimu vysoké dostupnosti a přístup na portál IDM bude probíhat zabezpečené v zabezpečeném přístupu (HTTPS). IDM bude dále využívat již provozovaný databázový server (MS SQL).

IDM bude obsahovat nástroj pro centrální přístup IS města k službám a datům eGovernmentu.

Uvedené požadované vlastnosti IDM a vlastnosti řešení v níže uvedené tabulce znamenají minimální míru plnění dle této ZD.

ID	Požadované principy a technologické vlastnosti IDM	Splněno
1	IDM bude udržovat identity a organizační strukturu organizace ve své vnitřní databázi, identity ve vnitřní databázi budou sloužit jako referenční identity pro ostatní vnitřní i vnější informační systémy.
2	IDM bude obsahovat samostatný server (Portál IDM) pro přístup koncových uživatelů a samostatný server pro správu a výkon jednotlivých integračních a provozních úloh.
3	IDM bude obsahovat registraci aplikací a jejich rolí, import rolí přes webové služby do IDM.
4	IDM bude obsahovat správu uživatelských rolí, včetně zařazení uživatele do odpovídající role v dané aplikaci nebo modulu IS.
5	v IDM bude správce moci dynamicky konfigurovat pravidla pro automatické začleňování uživatelů do skupin a přiřazování aplikačních rolí uživatelům na základě atributů identity a přidružených referenčních objektů (organizační jednotka, aplikační role, systematizované místo atd.); pravidla budou spravována v grafickém editoru prostřednictvím webového prohlížeče.
6	IDM umožní implementaci procesů a rozhraní, která jsou vyžadována v Nařízení Evropského parlamentu a Rady (EU) č. 910/2014 ze dne 23. července 2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu a o zrušení směrnice 1999/93/ES.
7	IDM umožní notifikovat emailovou zprávou: vytvoření a změny identity, vytvoření a změny referenčních objektů, konflikt, problém při jednotlivých synchronizacích probíhajících se systémy, na které je IDM napojeno.
8	IDM bude obsahovat workflow pro řízení životního cyklu změn identit a schvalování změn s těmito vlastnostmi: možnost vložit pro nadřízené pracovníky požadavky na změny v přiřazení rolí, skupin pro podřízené pracovníky a sledovat stav vyřizování jejich žádostí, možnost schválení či zamítnutí požadavků, možnost odeslání schvalovateli upozornění ve formě emailové notifikace, možnost schválit či zamítnout požadavek včetně uvedení zdůvodnění.
9	IDM musí obsahovat funkcionalitu pro export auditního reportu z údajů o identitě uložené v IDM a to i historické, auditní reporty budou minimálně ve formátu XML a CSV a budou obsahovat souhrnné zobrazení daného uživatele a jeho rolí v IS napojených na IDM, agendových rolí, přiřazených skupin ve vybraném časovém okamžiku od aktuálního času do minulosti.
10	IDM autentizační server bude umožňovat zprostředkovávat systémům autentizační úlohy přes následující protokoly/standardy: LDAP (Active Directory), Windows autentizaci, Radius protokol, Ověření pomocí certifikátu, OpenID, OAuth2.0, SAML 2.0. (v rámci SAML protokolu bude IDM naplňovat roli identity providera), podpora vícefaktorové autentizace.

Portál IDM bude řešen jako webová aplikace přístupná přes webový prohlížeč. Uvedené požadované vlastnosti Portálu IDM v níže uvedené tabulce znamenají minimální míru plnění dle této ZD.

ID	Požadované principy a technologické vlastnosti Portálu IDM	Splněno
1	Portál IDM bude obsahovat přehlednou a oddělenou správu samostatných identifikovatelných objektů – referenčních objektů, na které se identita odkazuje: systematizované místo, organizační jednotka, skupina, agenda, agendová činnostní role, aplikace, skupina aplikací, aplikační role, certifikát atd.,
2	Portál IDM bude zajišťovat možnost nastavení samostatného administrátorského oprávnění v portálu IDM pro správu v modulu správy referenční údajů.
3	Portál IDM bude obsahovat funkcionalitu pro dodatečné rozšiřování identit a referenčních objektů o další atributy a publikaci těchto nových atributů externím aplikacím.
4	Portál IDM bude obsahovat grafické zobrazení identit (uživatelských účtů) ve stromové organizační struktuře.
5	Portál IDM bude obsahovat správu uživatelů a údajů o jejich certifikátech, data o certifikátech uživatelů bude možné nahrávat do IDM přes webové služby.
6	Portál IDM bude obsahovat funkcionalitu pro přesun identity mezi jednotlivými organizačními útvary, kopírovaní aplikačních rolí, agendových činnostních rolí mezi jednotlivými systematizovanými místy.
7	Portál IDM bude obsahovat správu nastavení, které zabrání hromadným změnám z důvodu případných chybných dat na vstupu (například z personálního systému), tak aby nedošlo k hromadným nežádoucím změnám (například smazání objektů v Active Directory).
8	Portál IDM bude obsahovat správu parametrů, konfigurace systému IDM.
9	Portál IDM bude obsahovat funkcionalitu pro sjednocení více osob do jedné a sjednocení jejich účtů.
10	Portál IDM bude obsahovat funkcionalitu pro export zobrazených seznamů do souborů CSV.
11	Portál IDM bude obsahovat editor filtrů pro vyhledávání identit v systému IDM a dle fulltextu.
12	Portál IDM bude obsahovat funkci pro správu rolí / přístupů k osobním údajům uchovávaných v rámci systémů organizace.
13	Portál IDM bude obsahovat modul samoobsluhy pro reset hesla pro jednotlivé účty daného uživatele, IDM bude možné napojit na SMS bránu pro generování a zasílání kódů přes zprávy SMS na daného uživatele pro potvrzení resetu hesla.
14	IDM umožní správu a ověření předmětných služeb při ověření vybraných identit v rámci NIA, Portál bude disponovat potřebnými ověřovacími principy při přímé komunikaci občana s úřadem.
15	Správa synchronizací v IDM portálu umožní: sledovat jednotlivé stavy v průběhu synchronizace v grafické podobě, plnou synchronizaci – prochází všechny objekty v IDM a synchronizuje je s objekty daného systému, změnovou synchronizaci – synchronizuje vždy jen změny od poslední spuštěné synchronizace, okamžitou synchronizaci konkrétní identity na vyžádání – synchronizuje okamžitě pouze vybranou identitu, rekonciliační synchronizaci – synchronizace vytvoří rekonciliační report pro porovnání změn mezi nastavením identit a jejich oprávnění pro daný systém v IDM vs. nastavení identit a oprávnění přímo v připojeném systému, simulační synchronizaci – synchronizace vytvoří report očekávaných změn v napojeném systému pro provedení ostré synchronizace, report změn bude evidován jako pohled nebo přehledná souhrnná tabulka přímo v Portálu IDM.
16	Portál IDM bude obsahovat funkci generování reportů: pro proces ohlašování působnosti v Registru práv a povinností, obsahující uživatele, kteří mají delegované aplikační role od jiných uživatelů, uživatelů přiřazených aplikačním rolím, možnost nastavení pravidel pro automatické zasílání reportu emailem.

Popis požadovaných integračních vazeb IDM je uveden v následující tabulce.

ID	Popis požadavku	Popis řešení	Splněno
1	Napojení IDM na AD, windows autentizace	IDM provádí synchronizaci účtů (username, password) včetně zařazení uživatelů do NT skupin do AD.
2	Integrace na IS silniční hospodářství	IDM poskytuje autentizační a autorizační služby pro IS AIS SH, včetně SSO. IDM poskytuje referenční údaje o zařazení, nadřízených a podřízených vazbách a kontaktní údaje uživatelů.
3	Integrace na IS speciální stavební úřad vodoprávní	IDM poskytuje autentizační a autorizační služby pro IS AIS SH, včetně SSO. IDM poskytuje referenční údaje o zařazení, nadřízených a podřízených vazbách a kontaktní údaje uživatelů.
4	Integrace na IS Životní prostředí	IDM poskytuje autentizační a autorizační služby pro IS AIS SH, včetně SSO. IDM poskytuje referenční údaje o zařazení, nadřízených a podřízených vazbách a kontaktní údaje uživatelů.
5	IDM bude napojeno na personální systém pro získávání organizační struktury, hierarchie systematizovaných míst a osob	IDM musí disponovat rozhraním pro načítání organizační struktury, zařazení pracovníků, nadřízenost a podřízenost organizačních rolí a pracovníků.
6	IDM bude spravovat identity a oprávnění systému IS Radnice VERA	IDM poskytuje autentizační a autorizační služby pro IS Radnice VERA. IDM poskytuje referenční údaje o zařazení, nadřízených a podřízených vazbách a kontaktní údaje uživatelů.
7	IDM bude spravovat identity a oprávnění systému VITA	IDM poskytuje autentizační a autorizační služby pro IS VITA, včetně SSO. IDM poskytuje referenční údaje o zařazení, nadřízených a podřízených vazbách a kontaktní údaje uživatelů.
8	IDM bude napojeno na elektronickou spisovou službu ICZ e-spis ®	IDM poskytuje autentizační a autorizační služby pro ESS.
9	Napojení na centrální správu přestupků	IDM poskytuje autentizační a autorizační služby pro IS CSP, včetně SSO. IDM poskytuje referenční údaje o zařazení, nadřízených a podřízených vazbách a kontaktní údaje uživatelů.
10	Napojení na agendový systém městské policie	IDM poskytuje autentizační a autorizační služby pro IS POLIXIS, včetně SSO. IDM poskytuje referenční údaje o zařazení, nadřízených a podřízených vazbách a kontaktní údaje uživatelů. IDM musí pokrýt stávající autorizační služby EOS.
11	Registrace a autorizace uživatelů portálu	IDM poskytne IS PO služby pro registraci: služby pro registraci prostřednictvím NIA, pro autorizaci: služby pro zjištění přístupových oprávnění včetně zástupů.

5.3Aktivita 2 - Elektronizace vybraných agend IS

Realizací této aktivity budou elektronizovány agendy v oblasti správního řízení, jmenovitě agendy:

životního prostředí,
speciálního stavebního úřadu vodoprávního,
silničního hospodářství.

Požadavky na společné vlastnosti řešení pro oblast správních řízení

Uvedené požadované společné vlastnosti řešení pro oblast správních řízení jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky obecné pro agendy správních řízení	Splněno
1	Pracovní prostředí uživatele bude v rámci projektu sjednocené.
2	Informace z jednotlivých modulů a aplikací budou uživateli dodávány prostřednictvím rozhraní, uživatelům tak budou k dispozici již jednou pořízená data nejen z jeho aplikace, ale též z aplikací okolních (v případě, že bude v rámci jednotlivých speciálních požadavků stanoveno), jednotlivé součásti řešení budou poskytovat uživateli moderní uživatelské rozhraní, jehož ovládání je obdobné s ovládáním kancelářských (např. MS Office, Adobe Acrobat Reader) či webových aplikací.
3	Identita uživatelů a jejich uživatelská oprávnění budou spravovány centrálně, veškeré části budou spravovány z jednoho místa, viz popis požadavků v kapitole 5.2 Aktivita 1 – Centralizace správy uživatelů.
4	Centrálně přidělována oprávnění k interním aplikacím a přístupu k systému základních registrů.
5	On line komunikace a předávání dat mezi jednotlivými součástmi řešení.
6	Vícevrstvá architektura řešení a jeho jednotlivých součástí bude využívat databázi, aplikační server a klientskou část jako tenký klient bez nutnosti instalace, aplikace běží v internetovém prohlížeči nebo jako win32 aplikace.
7	Řešení bude technologicky postaveno na obecně uznávaných standardech a technologiích – JAVA, .NET, webové služby (např. SOAP), Apache Tomcat a dalších.
8	Datové úložiště bude umožňovat ukládání dokumentů včetně definovaných popisných metadat, s možností verzování ukládaných dokumentů; v každém uzlu (adresáři) bude možné nastavit uživatelská oprávnění a dokumentový typ.
9	Konfigurace podle nově vzniklých požadavků úřadu – možnost přidávání dalších obecných agend administrátorem úřadu (max. v řádu dnů), řešení bude umožňovat specifické nastavení v závislosti na konkrétní agendě.
10	Přidělování diferencovaných přístupových práv k záznamům v závislosti na organizační struktuře, tzn. pro každého uživatele bude přesně definováno, které záznamy může prohlížet, měnit a přidávat.
11	Nástroje pro sledování úkolů a lhůt zadaných uživatelům jednotlivých agend, včetně nastavitelného upozornění (neprovedený úkon, prekluze).
12	Možnost komunikace s MS Outlook – funkce Kalendáře.
13	Možnost vedení záznamů o veškerých změnách provedených uživateli v datech.
14	Řešení bude obsahovat popis aplikačního rozhraním na bázi Web Services (preferovaná, nikoliv jediná možná je technologie SOAP).

Požadavky na řešení pro oblast agend životního prostředí

Elektronizace agend životního prostředí bude řešit:

centralizaci stávajících agend a aplikací pod jedno aplikační prostředí garantující nové trendy a principy ve veřejné správě (GDPR, eIDAS, ÚEP),
vytvoření centrální vyhodnocovací platformy pro reporting vedených řízení,
vymodelování specifických aplikačních prostředí v souladu s organizační strukturou odboru životního prostředí,
možnost exportu dat z portálové části (žádosti) pro vytěžení zadaných dat,
vytvoření individuální sady šablon pro zefektivnění činnosti referentů,
propojení systému vůči centrálním evidencím a registrům státu.

Řešení poskytne prezentační vrstvy v mapových podkladech, a to jak z pohledu interních uživatelů (zaměstnanci odboru ŽP), tak z pohledu občanů.

Bude vytvořen mapový informativní portál s informacemi o činnostech na úsecích agend životního prostředí pro souhrnné posuzování zájmů.

Z pohledu produktů je problematika životního prostředí reprezentována následnými oblastmi:

vodní hospodářství,
odpady,
ochrana ovzduší,
ochrana přírody a krajiny,
lesy, myslivost a rybářství,
zemědělský půdní fond (ZPF),
veterinární péče, rostlinolékařské péče a ochrany zvířat,
lovecké a rybářské lístky,
poskytování informací o životním prostředí, EIA a IPPC,
přestupky na úseku životního prostředí.

Komplexní elektronizací oblasti agend životního prostředí dojde k vytvoření agendového prostoru, v rámci kterého budou vzájemně propojeny jednotlivé datové zdroje, tj. dojde k eliminaci duplicitních činností a úkonů.

Uvedené požadované společné vlastnosti řešení pro oblast správních řízení jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkční vlastnosti řešení agend životního prostředí	Splněno
1	Řešení bude obsahovat centrální evidence všech vedených řízení, průběh každého řízení bude podrobně zaznamenáván prostřednictvím jednotlivých úkonů.
2	Pokud z povahy právního úkonu vyplývá, že se činí písemně, pak řešení umožní vytvořit a připojit příslušný dokument; do šablony pro výsledný dokument se doplní data shromážděná v řízení nebo zapsaná v evidenčním formuláři právního úkonu.
3	Možnost vytváření vlastních šablon dokumentů, sestav, statistik i upomínek.
4	V každém typu řízení budou evidovány všechny potřebné subjekty i jejich zástupce vč. procesního postavení subjektu, jejich adres pro doručování a další kontaktní údaje, údaje o subjektech budou ověřovány a průběžně aktualizovány vůči základním registrům.
5	Možnost společně provázat řízení, která spolu procesně souvisí a možnost kopírování evidovaných údajů z jednoho řízení do druhého.
6	Řešení bude obsahovat vlastní mapový portál prezentující oddělená data pro úředníky a občany, příslušné mapové vrstvy budou přímo integrovány do aplikačního prostředí.
7	Možnost automatického sledování lhůt vyplývajících z legislativy a automatické generování upozornění uživatelů na blížící se expiraci termínů.
8	Všechna řízení budou mít předem nakonfigurované podklady vycházející z legislativy, ze kterých si uživatel může vybrat, případně si zaeviduje jakékoli vlastní.
9	Možnost automatické tvorby ročního výkazu o odnětí a o odvodech za odnětí půdy ze ZPF, ročního výkazu o odnětí a o poplatcích za odnětí PUPFL a automatický přenos údajů vodoprávní evidence do CRVE.
10	Možnost vyhledávání správních řízení i vedených údajů se zobrazením základních statistických údajů, např. o počtu jednotlivých typů řízení za odbor/oddělení/pracovníka.
11	Možnost zobrazení historie řízení, kde jsou zaznamenány všechny změny, které se v čase procesu řízení udály.
12	Možnost likvidace osobních údajů po uplynutí zákonné lhůty pro archivaci či skartaci spisu správního řízení v souladu s nařízením GDPR.
13	Možnost prediktivního zadávání textu.
14	Možnost filtrování údajů pomocí stromové struktury v rámci aplikačního prostředí.
15	Podpora koordinovaných či souhrnných stanovisek napříč jednotlivými odděleními.
16	Funkcionalita pro prezentaci vydaných stanovisek (vyjádření) pro potřeby prvoinstančního stavebního úřadu s dostupností dokumentů dle organizační struktury úřadu a výběru dle kritérií: region, pověřené území (stanovitelné dle katastrálního území či obce), typ dokumentu (případu), dle pracovníka.

Popis požadovaných integračních vazeb agend životního prostředí je uveden v následující tabulce.

ID	Požadavek	Popis	Splněno
1	Propojení lokálního AIS a s centrální systémem registrům státu (ISZR)	On-line ověřování údajů proti referenčním informacím v ISZR. Aktualizace lokální kopie dat RUIAN pro ověřování adres, katastrálních území a parcel.
2	Propojení lokální AIS s centrálním, resortním systémem Centrální registr vodoprávní evidence MŽP (CRVE)	Načítání číselníku vodních toků Zápis rozhodnutí do CRVE
3	Integrace vůči ICZ e-spis ® - elektronické spisové službě, zadavatel zajistí součinnost třetích stran	Správa dokumentů mezi AIS ŽP a spisovou službou, dle podmínek NSESSS III.
4	Integrace vůči ES – ekonomickému systému IS Radnice VERA	Příprava platebního předpisu za přestupek vč. prezentace informací o zaplacení (párování pohledávek)
5	Integrace vůči IS IDM, viz popis požadavků v kapitole 5.2 Aktivita 1 - Centralizace správy uživatelů	IDM je referenčním zdrojem organizační struktury (ORS), pracovníků, zařazení v organizačních rolích a kontaktech IDM řídí přístupová oprávnění pro uživatele a role IS AIS ŽP, autentizuje uživatele IS AIS ŽP. IS AIS ŽP poskytuje profily oprávnění a načítá referenční data z IDM (ORS, kontakty)
6	Integrace IS AIS ŽP vůči IS městské policie POLIXIS	POLIXIS poskytuje informace o přestupcích a jejich postoupení správnímu orgánu
7	Zpracování elektronického podání z portálu a poskytování informací zpět portálu o průběhu jeho zpracování	IS AIS ŽP musí být připraven: nalézt elektronicky podaný formulář ve spisové službě, načíst popisná data v přiloženém XML souboru k elektronicky podanému formuláři (elektronické podání v SSL) a zobrazit v IS AIS ŽP, poskytovat API na bázi WSDL pro IS PO pro předávání informací o stavech řízení, která navazují na korespondující elektronické podání podaná prostřednictvím IS PO

Požadavky na řešení pro speciální stavební úřad vodoprávní

Průběh řízení dle specifické legislativy bude podpořen úkony vyplývajícími ze speciálních právních předpisů, které budou v případě potřeby doplněny subsidiárně úkony ze správního řádu. Dle konfigurace bude možné k jednotlivým úkonům generovat výsledné dokumenty dle předdefinovaných šablon, do kterých se budou automaticky vyplňovat údaje z daného řízení, příp. ze souvisejících řízení. Výsledné dokumenty budou následně prostřednictvím rozhraní odesílány do spisové služby včetně adresátů a způsobů vypravení.

Uvedené požadované vlastnosti řešení pro oblast speciálních stavebních úřadů jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkční vlastnosti řešení pro speciální stavební úřad vodoprávní	Splněno
1	Možnost založení nového řízení na základě podané žádosti (návrhu, oznámení) zaevidované ve spisové službě, příp. založení nového řízení z moci úřední bez prvotní vazby na spisovou službu s následným vytvořením vazby při prvním odeslání dokumentu do spisové služby.
2	Možnost evidence kompletních informací o účastnících řízení a dotčených orgánech (identifikační údaje, adresa trvalého pobytu, příp. sídla firmy, adresa pro doručování, evidence ostatních kontaktních údajů – telefon, fax, email, datová schránka, evidence zástupců, příp. evidence společného zástupce).
3	Možnost evidence speciálních údajů dle typu případu (informace o stavbě, apod.).
4	Možnost evidence průběhu správního řízení formou jednotlivých úkonů dle konfigurace s možností hlídání zákonných lhůt plynoucích z jednotlivých úkonů vč. upozornění na uplynutí lhůty.
5	Možnost evidence námitek, stanovisek a závazných stanovisek jednotlivých subjektů k danému řízení.
6	Možnost evidence (ne)doložených podkladů, příp. evidence libovolných příloh k danému řízení.
7	Možnost vystavování dokumentů na základě zaevidovaných údajů podle předdefinovaných šablon.
8	Možnost generování podkladů pro statistiky Českého statistického úřadu.
9	Plnohodnotné rozhraní na spisovou službu.
10	Přímý tisk adresních štítků, příp. obálek.
11	Možnost vytvoření návazného řízení s možností okopírování údajů z předchozího řízení.
12	Tiskové výstupy (kontrolní prohlídky).
13	Knihovna textů – připravené fragmenty textů (často se opakující texty), které se jednoduše vkládají do jednotlivých polí.
14	Přenos speciálních údajů z úkonu charakteru schůzky do kalendáře uživatele v MS Outlook.
15	Hlídání existence aktivní datové schránky, příp. doručovací adresy nahlášené na ohlašovně úřadu při odesílání dokumentů do spisové služby.
16	Součástí řešení bude vlastní mapový nástroj pro prezentaci vybraných dat z agendy.
17	Možnost aktualizace dat z Registru nemovitostí.
18	Možnost zobrazení informací o pozemku, vlastnících a právních vztahů na webových stránkách ČÚZK.
19	Podpora procesů: Opatření obecné povahy, Předběžné opatření, Předběžná otázka, Obnova řízení, Nové řízení, Přezkumné řízení, Odvolací řízení, Veřejnoprávní smlouvy, Exekuční řízení na nepeněžitá plnění, Řízení o určení právního vztahu, Řízení na místě, Uspokojení účastníka po podání žaloby ve správním soudnictví, Stížnosti.
20	Koordinovaná stanoviska, závazná stanoviska, stanoviska a vyjádření zpracovávaná více odděleními jsou řešena pouze v jednom systému.
21	Nástroj pro tvorbu vlastních šablon (dokumenty, sestavy, statistiky, upomínky).
22	Podrobná centrální procesní evidence jednotlivých správních řízení dle odpovídající právní kategorie.
23	Řešení umožní, aby případ mohl být zahájen jak na základě příchozího dokumentu, tak z moci úřední, resp. bez inicializačního dokumentu.
24	Je-li řízení zahájeno na základě příchozího dokumentu, pak systém zajistí dotažení údajů o čísle jednacím přijatého dokumentu, odesílateli dokumentu a popisu věci dokumentu ze spisové služby.
25	Plná procesní podpora vyplývající ze zákona č. 500/2004 Sb., správní řád.
26	Jednotlivé procesní kroky budou podrobně zaznamenány a jejich sled bude respektovat přesný procesní průběh celého správního řízení.
27	Při záznamu právního úkonu bude možné pomocí evidenčního formuláře právního úkonu uložit určitá data, jejich struktura bude specifická a bude se vázat ke konkrétnímu právnímu úkonu.
28	Evidence všech subjektů vystupujících v řízení (účastníci řízení, dotčené orgány, ostatní) s jejich ověřením v základních registrech a průběžnou aktualizací ze základních registrů.
29	Ke každému subjektu bude možné zaevidovat zástupce s jejich procesním postavením, včetně společného zástupce.
30	Ke každému subjektu bude možné zaevidovat doručovací adresu dle § 19 odst. 3 zákona č. 500/2004 Sb., správní řád, a doručovací adresu dle § 10b zákona č. 133/2000 Sb., o evidenci obyvatel a rodných číslech, a další kontaktní údaje.
31	Pokud některé ze správních řízení předpokládá stejný či podobný okruh dotčených orgánů, umožní řešení jejich předvyplnění v systému a opakované automatické dotažení do daného typu správního řízení včetně ověření proti základním registrům.
32	Možnost evidence oprávněných úředních osob ke každému řízení s možností tiskového výstupu pro založení do spisu.
33	Evidence aktuálního stavu řízení (odloženo, postoupeno, přerušeno, zastaveno, rozhodnuto, apod.) dle fáze procesu řízení.
34	Pokud z povahy právního úkonu vyplývá, že se činí písemně, pak řešení umožní vytvořit a připojit příslušný dokument; do šablony pro výsledný dokument se doplní data shromážděná v řízení nebo zapsaná v evidenčním formuláři právního úkonu.
35	Možnost tisku dokumentů s uživatelským nástrojem pro tvorbu vlastních šablon.
36	U textových evidenčních polí bude k dispozici zásobník textů – pro připravené fragmenty textů (často se opakující texty), které uživatel ukládá, vybírá a vkládá do jednotlivých polí s následným tiskem do dokumentů.
37	Možnost provázání řízení, která spolu procesně souvisí a možnost kopírování evidovaných údajů z jednoho řízení do druhého.
38	V rámci správních řízení, kde je to vhodné, komunikace s GIS formou otevřeného rozhraní, jehož účelem bude grafické zobrazení umístění objektů.
39	Možnost evidence libovolných úkolů souvisejících s vedeným řízením jak uživateli, tak případně i dalším oprávněným úředním osobám, s možností zadávat termíny pro jejich splnění i notifikaci.
40	Evidence (ne)doložených podkladů a příloh k danému řízení.
41	Automatická tvorba povinných celostátních statistik.
42	Možnost vyhledávání jednotlivých správních řízení i údajů vedených v řízení pomocí uživatelsky nastavitelných filtrů s možností zobrazení základních statistických údajů, např. o počtu jednotlivých typů řízení za odbor/oddělení, či za pracovníka.
43	V rámci správního řízení předání pokuty, nákladů řízení a správních poplatků do příslušné agendy.
44	Xxxxxx s ustanovením zákona č 101/2000 Sb., o ochraně osobních údajů, Nařízením GDPR, včetně možnosti likvidace osobních údajů po uplynutí zákonné lhůty pro archivaci či skartaci spisu správního řízení, evidované správní řízení zůstane zachováno s příznakem likvidačního stavu bez veškerých osobních údajů pro sledování dlouhodobých trendů a nadále se nebude vyskytovat v seznamech aktivně vedených či uzavřených správních řízení.
45	U textových evidenčních polí bude k dispozici zásobník textů – pro připravené fragmenty textů (často se opakující texty), které uživatel ukládá, vybírá a vkládá do jednotlivých polí s následným tiskem do dokumentů.
46	Možnost provázání řízení, která spolu procesně souvisí a možnost kopírování evidovaných údajů z jednoho řízení do druhého.
47	V rámci správních řízení, kde je to vhodné, komunikace s GIS formou otevřeného rozhraní, jehož účelem bude grafické zobrazení umístění objektů.
48	Možnost evidence libovolných úkolů souvisejících s vedeným řízením jak uživateli, tak případně i dalším oprávněným úředním osobám, s možností zadávat termíny pro jejich splnění i notifikace.
49	Evidence (ne)doložených podkladů a příloh k danému řízení.
50	Automatická tvorba povinných celostátních statistik.
51	Možnost přenosu speciálních údajů z úkonu (charakteru ústního jednání) do kalendáře uživatele v MS Outlook.
52	Možnost zpětného náhledu na správní řízení v čase, zobrazení historie řízení, záznam všech změn, které se v procesu řízení udály – datum, čas a informace o tom, který uživatel změny provedl.
53	Možnost prediktivního zadávaní textu.
54	Možnost filtrování údajů pomocí stromové struktury v rámci aplikačního prostředí.

Popis požadovaných integračních vazeb je uveden v následující tabulce.

ID	Požadavek	Popis	Splněno
1	Integrace na ISDS	Systém bude obsahovat hlídání existence aktivní datové schránky, příp. doručovací adresy nahlášené na ohlašovně úřadu při odesílání dokumentů do spisové služby.
2	Propojení lokálního AIS s centrální systémem základních registrů státu (ISZR)	On-line ověřování údajů proti referenčním informacím v ISZR.
3	Propojení na Registr nemovitostí (REN). Funkce pro ověření proti lokálnímu REN a on-line službám ČUZK.	Vedení a aktualizace lokální kopie dat RUIAN. Poskytování vnitřních, integračních služeb řešení pro ověřování adres, katastrálních území a parcel. Řešení musí disponovat službami pro On-line ověřování informací o pozemcích, vlastnictví a právních vztazích na rozhraní ČÚZK
4	Integrace vůči ES – ekonomickému systému IS Radnice VERA	Příprava platebního předpisu za přestupek vč. prezentace informací o zaplacení (párování pohledávek)
5	Přenos dat do CRVE	Automatizovaný přenos dat do centrálního registru vodoprávní evidence
6	Integrace vůči ICZ e-spis® - elektronické spisové službě, zadavatel zajistí součinnost třetích stran	Správa dokumentů mezi AIS a spisovou službou, dle podmínek NSESSS III.
7	Integrace vůči řešení pro centralizaci správy uživatelů, viz popis požadavků v kapitole 5.2 Aktivita 1 – Centralizace správy uživatelů	IDM je referenčním zdrojem organizační struktury (ORS), pracovníků, zařazení v organizačních rolích a kontaktech IDM řídí přístupová oprávnění pro uživatele a role IS AIS SSUV, autentizuje uživatele IS AIS SSUV. IS AIS SSUV poskytuje profily oprávnění a načítá referenční data z IDM (ORS, kontakty)
8	Vytěžení dat z formulářů a jejich zpracování – Automatické zpracování vstupních dat z inteligentních formulářů v agendovém systému, viz popis požadavků v kapitole 5.6 Aktivita 5 – Formulářová komunikace	IS AIS SSUV musí být připraven: nalézt elektronicky podaný formulář ve spisové službě, načíst popisná data v přiloženém XML souboru k elektronicky podanému formuláři (elektronické podání v SSL) a zobrazit v IS AIS SSUV, poskytovat API na bázi WSDL pro IS PO pro předávání informací o stavech řízení, která navazují na korespondující elektronické podání podaná prostřednictvím IS PO

Požadavky na řešení pro oblast agendy silničního hospodářství

Samoobslužný systém pro řešení elektronizace a centralizace vybraných procesů na úseku silničního hospodářství bude podpořen vlastním mapovým serverem, v rámci kterého bude umožněno vytvořit mapovou přílohu podání, tj. zakreslení zájmové oblasti a stanovení rozsahu žádosti.

Součástí řešení bude i vlastní portálový nástroj, disponující kontextovou nápovědou pro žadatele.

Řešení umožní v rámci řízení dle specifické legislativy pracovat s množinou jednotlivých úkonů vyplývajících ze speciálních právních předpisů, které budou v případě potřeby doplněny subsidiárně úkony ze správního řádu. Dle konfigurace bude možné k jednotlivým úkonům generovat výsledné dokumenty dle předdefinovaných šablon, do kterých se budou vyplňovat údaje z daného řízení, příp. ze souvisejících řízení. Výsledné dokumenty budou následně prostřednictvím rozhraní odesílány do spisové služby vč. adresátů a způsobů vypravení.

Uvedené požadované vlastnosti řešení pro oblast agendy silničního hospodářství jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkční vlastnosti řešení pro agendy silničního hospodářství	Splněno
1	Individuální samoobslužný systém pro úplné elektronické podání na portálu města.
2	Komplexní přehled např. o povolených záborech pomocí mapového portálu.
3	Poskytování „aktivních“ informací občanům o událostech (zábory, uzavírky apod.).
4	Poskytování informací o stavu řízení pro občany.
5	Manažerský nástroj pro podporu činností vedoucích pracovníků formou dashboardových či jiných interaktivních funkcí pro prezentaci vybraných množin dat pro lepší kontrolu činností pracovníků.
6	Možnost kontroly kauz: dle termínu, dle typu kauzy, dle žadatele.
7	Sledování vytěžitelnosti úředníka.
8	Schvalovací workflow.
9	Efektivní předávání „spisů“ případů mezi pracovníky.
10	Monitoring „akcí“ v rámci mapových nástrojů (eliminace kolizí).
11	Automatické načtení a vytěžení dat z žádosti do agendy (úspora času referentů.
12	Plná integrovatelnost vůči externím systémům (např. Centrální evidence uzavírek).
13	Adaptabilní s externím právním systémem pro efektivní práci při tvorbě dokumentů.
14	Centrální evidence správních řízení umožňující vést i případně další řízení, které může být potřeba s ohledem na změnu v rámci organizační struktury.
15	Založení nového řízení na základě podané žádosti (návrhu, oznámení, apod.) zaevidované ve spisové službě, příp. založení nového řízení z moci úřední bez prvotní vazby na spisovou službu s následným vytvořením vazby při prvním odeslání dokumentu do spisové služby.
16	Evidence kompletních informací o účastnících řízení a dotčených orgánech (identifikační údaje, adresa trvalého pobytu, příp. sídla firmy, adresa pro doručování, evidence ostatních kontaktních údajů – telefon, fax, email, datová schránka, evidence zástupců, příp. evidence společného zástupce).
17	Evidence speciálních údajů dle typu případu (informace o skutku, stavbě, pozemcích, dráze apod.).
18	Evidence průběhu správního řízení formou jednotlivých úkonů dle konfigurace s možností hlídání zákonných lhůt plynoucích z jednotlivých úkonů vč. upozornění na uplynutí lhůty.
19	Evidence námitek, stanovisek a závazných stanovisek jednotlivých subjektů k danému případu.
20	Evidence (ne)doložených podkladů, příp. evidence libovolných příloh k danému řízení.
21	Vystavování dokumentů na základě zaevidovaných údajů podle předdefinovaných šablon.
22	Možnost vytvoření návazného řízení s možností okopírování údajů z předchozího řízení.
23	Knihovna textů – připravené fragmenty textů (často se opakující texty), které se jednoduše vkládají do jednotlivých polí.
24	Možnost přenosu speciálních údajů z úkonu charakteru schůzky do kalendáře uživatele v MS Outlook.
25	Hlídání existence aktivní datové schránky, příp. doručovací adresy nahlášené na ohlašovně úřadu při odesílání dokumentů do spisové služby.
26	Vazba na geografický informační systém GIS a Registr nemovitostí včetně možnosti přenosu parcel i vlastníků (pouze u některých typů případů).
27	Možnost aktualizace dat z Registru nemovitostí (pouze u některých typů případů).
28	Možnost zobrazení informací o pozemku, vlastnících a právních vztahů na webových stránkách ČÚZK.
29	Statistické výstupy (roční statistika a statistika domácího násilí).
30	Možnost prediktivního zadávání textu.
31	Možnost filtrování údajů pomocí stromové struktury v rámci aplikačního prostředí.

Popis požadovaných integračních vazeb je uveden v následující tabulce.

ID	Požadavek	Popis	Splněno
1	Propojení lokálního AIS s centrální systémem základních registrů státu (ISZR)	On-line ověřování údajů proti referenčním informacím v ISZR.
2	IS AIS SH bude obsahovat vazbu na geografický informační systém.	Integrovaný nástroj IS AIS SH pro zobrazení mapy a zákres situace do mapy musí umožnit: načtení, výběr a zobrazení vrstev (mapových podkladů) z GIS ve standardním GIS formátu WMS, WMTS, REST služby); uložení do GIS případně synchronizaci lokálně uložených geo dat situací do GIS. IS AIS SH v backoffice i portálové části zobrazuje objekty v mapě vlastním mapovým nástrojem.
3	Vedení lokální kopie dat a nástroje pro aktualizaci dat z Registru nemovitostí (REN). Funkce pro ověření proti lokálnímu REN a on-line službám ČUZK.	Vedení a aktualizace lokální kopie dat RUIAN. Poskytování vnitřních, integračních služeb řešení pro ověřování adres, katastrálních území a parcel. Řešení musí disponovat službami pro On-line ověřování informací o pozemcích, vlastnictví a právních vztazích na rozhraní ČÚZK
4	Integrace vůči ICZ e-spis ® - elektronická spisová služba, zadavatel zajistí součinnost třetích stran	Správa dokumentů mezi AIS SH a spisovou službou, dle podmínek NSESSSIII.
5	Integrace vůči řešení pro centralizaci správy uživatelů, viz popis požadavků v kapitole 5.2 Aktivita 1 – Centralizace správy uživatelů	Pro referentskou část AIS SH je IDM referenčním zdrojem organizační struktury (ORS), pracovníků, zařazení v organizačních rolích a kontaktech IDM řídí přístupová oprávnění pro uživatele a role IS AIS SH, autentizuje uživatele IS AIS ŽP. IS AIS SH poskytuje profily oprávnění a načítá referenční data z IDM (ORS, kontakty. Pro portálovou část bude IS AIS SH u IDM: využívat registrační část IDM pro přepážku, evidovat uživatele portálové části, využívat autentizační služby;
6	Systém bude připraven jako individuální samoobslužný systém pro úplné elektronické podání na portálu města	IS AIS SH v části portálu pro žadatele umožní zaintegrování do IS PO formou odkazu.
7	Vytěžení dat z formulářů a jejich zpracování – Automatické zpracování vstupních dat z inteligentních formulářů v agendovém systému	IS AIS SH musí být připraven: nalézt elektronicky podaný formulář ve spisové službě, načíst popisná data v přiloženém XML souboru k elektronicky podanému formuláři (elektronické podání v SSL) a zobrazit v IS AIS SH, poskytovat API na bázi WSDL pro IS PO pro předávání informací o stavech řízení, která navazují na korespondující elektronické podání podaná prostřednictvím IS PO

5.4Aktivita 3 - Centrální správa přestupků

Cílem realizace nové funkcionality je centralizace všech organizačních jednotek z pohledu aplikační technologie a dále aplikace tohoto řešení do stávajícího programového vybavení úřadu.

Z pohledu individuálních potřeb napříč organizační strukturou bude předmětné řešení nakonfigurováno dle potřeb uživatelů, tzn. vznikne unikátní řešení specifické pro každou organizační jednotku úřadu se společným datovým a Identitním fondem.

Uvedené požadované vlastnosti řešení pro centrální správu přestupků jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkční vlastnosti řešení pro centrální správu přestupků	Splněno
1	Centrální evidence správních řízení.
2	Založení nového řízení na základě podané žádosti (návrhu, oznámení, …) zaevidované ve spisové službě, příp. založení nového řízení z moci úřední bez prvotní vazby na spisovou službu s následným vytvořením vazby při prvním odeslání dokumentu do spisové služby.
3	Evidence kompletních informací o účastnících řízení a dotčených orgánech (identifikační údaje, adresa trvalého pobytu, příp. sídla firmy, adresa pro doručování, evidence ostatních kontaktních údajů – telefon, fax, email, datová schránka, …, evidence zástupců, příp. evidence společného zástupce).
4	Evidence speciálních údajů dle typu případu (informace o skutku, stavbě, pozemcích, dráze atd.).
5	Evidence průběhu správního řízení formou jednotlivých úkonů dle konfigurace s možností hlídání zákonných lhůt plynoucích z jednotlivých úkonů vč. upozornění na uplynutí lhůty.
6	Evidence námitek, stanovisek a závazných stanovisek jednotlivých subjektů k danému případu.
7	Evidence (ne)doložených podkladů, příp. evidence libovolných příloh k danému řízení.
8	Vystavování dokumentů na základě zaevidovaných údajů podle předdefinovaných šablon.
9	Možnost vytvoření návazného řízení s možností okopírování údajů z předchozího řízení.
10	Knihovna textů – připravené fragmenty textů (často se opakující texty), které se jednoduše vkládají do jednotlivých polí.
11	Možnost přenosu speciálních údajů z úkonu charakteru schůzky do kalendáře uživatele v MS Outlook.
12	Hlídání existence aktivní datové schránky, příp. doručovací adresy nahlášené na ohlašovně úřadu při odesílání dokumentů do spisové služby.
13	Vazba na geografický informační systém GIS a Registr nemovitostí včetně možnosti přenosu parcel i vlastníků (pouze u některých typů případů).
14	Možnost aktualizace dat z Registru nemovitostí (pouze u některých typů případů).
15	Možnost zobrazení informací o pozemku, vlastnících a právních vztahů na webových stránkách ČÚZK.
16	Statistické výstupy (roční statistika a statistika domácího násilí).
17	Možnost prediktivního zadávání textu.
18	Možnost filtrování údajů pomocí stromové struktury v rámci aplikačního prostředí.

Popis požadovaných integračních vazeb je uveden v následující tabulce.

ID	Požadavek	Popis	Splněno
1	Integrace vůči ICZ e-spis ® - elektronické spisové službě, zadavatel zajistí součinnost třetích stran	Správa dokumentů mezi AIS CSP a spisovou službou, dle podmínek NSESSS.
2	Integrace vůči ES – ekonomickému systému IS Radnice VERA, zadavatel zajistí součinnost dodavatele ekonomického systému	Příprava platebního předpisu za přestupek vč. prezentace informací o zaplacení (párování pohledávek)
3	Integrace na ISZR prostřednictvím XZR.	On-line ověřování údajů proti referenčním informacím v ISZR musí být technicky realizována prostřednictvím aplikace XZR, která poskytuje lokálně zrcadlené služby ISZR a zajišťuje logování přístupů.
4	Bude obsahovat správu uživatelů a oprávnění, viz popis požadavků v kapitole 5.2 Aktivita 1 – Centralizace správy uživatelů	IDM je referenčním zdrojem organizační struktury (ORS), pracovníků, zařazení v organizačních rolích a kontaktech IDM řídí přístupová oprávnění pro uživatele a role AIS, autentizuje uživatele AIS. AIS poskytuje profily oprávnění a načítá referenční data z IDM (ORS, kontakty)
5	Integrace vůči centrálnímu registru vozidel	ověřování údajů proti referenčním informacím v CRV
6	Integrace vůči informačnímu systému evidence přestupků	AIS CSP musí disponovat službami ISEP pro: lustraci – načtení informace k přestupci z ISEP; zápis – poskytnutí údajů o přestupku do ISEP.
7	Integrace vůči systému městské policie (POLIXIS)	AIS CPS musí umožnit načíst údaje k postoupeným přestupkům z rozhraní POLIXIS

5.5Aktivita 4 - Nástroj pro centrální evidence úřadu

V současné době je v rámci organizační struktury města evidováno mnoho jednoduchých evidencí na platformě MS EXCEL či WORD, resp. formou sešitů. Předmětné evidence nejsou vedeny centrálně, a ve většině případů i duplicitně.

Cílem implementace nové funkcionality IS města je centralizace těchto evidencí do jednoho centrálního nástroje, který umožní:

centrálně spravované uživatelské přístupy,
logování přístupů dle organizačního zařazení,
individuální konfigurovatelnost,
umožnění importu/exportu dat z jednotlivých agend a modulů IS města,
možnost vytváření nových evidencí pomocí uživatelského nastavení konfigurace.

Uvedené požadované vlastnosti řešení pro centrální evidence úřadu jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkční vlastnosti řešení pro centrální evidence úřadu	Splněno
1	Pořízení aplikace pro realizaci požadovaných evidencí (resp. pro vznik budoucích evidencí).
2	Vytvoření individuálních evidencí, a to jmenovitě: evidence pro Městskou policii (evidence akcí/kampaní, evidence psů), evidence drobného majetku.
3	Požadované integrační vazby: integrace vůči řešení pro centralizaci správy uživatelů, viz popis požadavků v kapitole 5.2 Aktivita 1 – Centralizace správy uživatelů).

5.6Aktivita 5 - Formulářová komunikace

Cílem implementace nové funkcionality je vytvoření vybraných sad plně elektronizovaných žádostí, které budou dostupné ve stávajícím portálu občana (IS PO) a které umožní úplné elektronické podání a zároveň umožní export dat do příslušných agend IS AIS města.

Rozsah a detail jednotlivých formulářů bude vycházet z požadavků zaměstnanců Zadavatele.

Uvedené požadované vlastnosti řešení pro formulářovou komunikaci jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na funkční vlastnosti řešení pro formulářovou komunikaci	Splněno
1	Formuláře umožní připojit libovolný počet příloh v libovolném formátu.
2	Formuláře umožní vytvoření a vypravení datové zprávy podle z. č. 300/2008 Sb. ve znění pozdějších předpisů s umístěním vyplněného formuláře jako přílohy k této datové zprávě.
3	Formuláře umožní odeslání dat (žádosti) prostřednictvím ISDS přímo z formuláře.
4	Formuláře zajistí kontrolu dat již při vyplňování a pomoc při vyplňování s kontextovou nápovědou.
5	Formuláře umožní vyplňování dat výběrem z číselníků, automatické doplňování hodnot polí, otevírání nových kolonek v závislosti na vyplněných hodnotách apod.
6	Formuláře kontrolním mechanizmem zajistí, že budou odeslána pouze zkontrolovaná data.
7	Formuláře zajistí automatické výpočty a kontroly pravopisu v češtině.
8	Formuláře umožní přidávání opakovacích sekcí a dynamickou změnu podle vyplňovaných hodnot.
9	Možnost převodu formulářů do PDF/A formátu.
10	Formuláře umožní formou tiskové sestavy výstup na tiskárnu.
11	Základní funkcionalitou formuláře bude, aby každý takto vyplněný formulář/žádost bylo možné elektronicky podepsat kvalifikovaným certifikátem/elektronickým podpisem.
12	Rozpracovaný formulář bude možné kdykoliv uložit na lokální disk uživatele a zpětně vyplněná data načíst.
13	Řešení umožní, aby formuláře mohly být zpracovány i off-line.
14	Formuláře budou automaticky napojeny na ISDS (Informační systém datových schránek) nebo na e-podatelnu úřadu.
15	Součástí formuláře bude i vygenerovaný čárový kód, který umožní z vytištěného formuláře znovu vytěžit obsažená data a automatizovaně přenést do informačního sytému úřadu.
16	Formuláře pro oblast stavebního úřadu budou přímo integrovány do produktu Stavební úřad VITA.
17	Formuláře pro oblast životního prostředí budou přímo integrovány do nově pořizovaného produktu (agendy životního prostředí).
18	Práce s formuláři bude možná i off-line – zpracování probíhá pomocí produktu Software602 FormFiller.
19	Přímo na formulářích budou integrována tlačítka, které spouštějí na pozadí řadu automatizovaných procesů, takže uživatel/občan má výrazně usnadněnu práci s formulářem.
20	Formuláře budou automaticky před vyplňovány daty, které má k zvolenému typu žádosti a žadatel státní správa k dispozici.
21	Veškeré formuláře budou v souladu s legislativou (vyhláškou k danému zákonu) a pokud budou dostupné formuláře centrálních institucí (např. pro řešení přenesené působnosti), tak se využijí, nebo se vytvoří vlastní s identickým obsahem a vzhledem. Cílem je, aby data z formulářů byla automaticky vytěžitelná navazujícími aplikacemi IS města.
22	Požadované integrační vazby: integrace vůči systému Městské policie – IS POLIXIS integrace vůči systému VITA integrace vůči systému VERA integrace vůči řešení pro centralizaci správy uživatelů, viz popis požadavků v kapitole 5.2 Aktivita 1 – Centralizace správy uživatelů).

Popis požadovaných integračních vazeb je uveden v následující tabulce.

ID	Požadavek	Popis	Splněno
1	IS PO musí pro ztotožnění při registraci také využívat ověření údajů ze Základních registrů, prostřednictvím stávající aplikace XZR.	IS PO při registrace na přepážce musí zajistit ověření údajů ZR v ISZR prostřednictvím napojení na aplikaci XZR, poskytující lokálně, zrcadlené služby ISZR a zajišťuje logování přístupů.
2	Integrace IS PO na NIA.	Od IS PO je požadována integrace s NIA při: registraci na portále při přihlášení při odeslání elektronického podání
3	Integrace IS PO s e-Podatelnou	Vyplněné formuláře budou předávány prostřednictvím IS PO na e-podatelnu úřadu. IS PO: řídí odesílání vyplněných formulářů a eviduje údaje o jejich předání do e-podatelny (e-podatelna předává do ESS)
4	Formuláře pro oblast stavebního úřadu budou přímo integrovány do produktu Stavební úřad VITA,	IS PO zajistí předání vyplněného formuláře IS VITA prostřednictvím e-podatelna. IS VITA poskytuje data stavech řízení a subjektech do IS PO. IS PO zobrazuje údaje o stavu řízení z IS VITA.
5	Integrace IS PO s IS AIS	Vyplněné formuláře budou předávány prostřednictvím IS PO na e-podatelnu úřadu. IS PO bude informovat IS AIS o založení podání v e-podatelně.
6	Integrace vůči řešení pro centralizaci správy uživatelů, viz popis požadavků v kapitole 5.2 Aktivita 1 – Centralizace správy uživatelů	IS PO bude ověřovat uživatele a jejich oprávnění vůči IDM. IS IDM je pro IS PO referenčním zdrojem dat pro uživatele a oprávnění. IS PO musí zajistit registraci a aktualizaci registračních údajů uživatele portálu v IS IDM

Webové formuláře budou obsahovat pole pro údaje v souladu s legislativními požadavky. Formuláře určené pro účely výkonu místní samosprávy budou navrženy ve spolupráci se zadavatelem v rámci návrhu a zpracování detailního cílového konceptu.

Uvedené požadované typy elektronických formulářů jsou uvedeny v následující tabulce:

ID	Požadavky na funkční vlastnosti řešení pro formulářovou komunikaci	Splněno
Oblast stavební
1	Žádost o vydání rozhodnutí o umístění stavby
2	Žádost o vydání rozhodnutí o změně využití území
3	Žádost o vydání rozhodnutí o změně vlivu užívání stavby
4	Žádost o vydání rozhodnutí o dělení nebo scelování pozemků
5	Žádost o vydání rozhodnutí o ochranném pásmu
6	Žádost o vydání společného územního rozhodnutí a stavebního povolení
7	Žádost o územní souhlas
8	Ohlášení stavby
9	Žádost o stavební povolení
10	Oznámení stavebního záměru s certifikátem autorizovaného inspektora
11	Oznámení o užívání stavby
12	Žádost o vydání kolaudačního souhlasu
13	Žádost o povolení předčasného užívání stavby
14	Oznámení změny v užívání stavby
15	Ohlášení odstranění stavby
Oblast životního prostředí
16	Žádost o povolení k nakládání s povrchovými nebo podzemními vodami nebo
17	Žádost o povolení k odběru podzemních vod pro potřeby jednotlivých občanů (domácností) nebo o jeho změnu
18	Žádost o povolení k vypouštění odpadních vod do vod povrchových nebo o jeho změnu
19	Žádost o povolení k vypouštění odpadních vod do vod podzemních z jednotlivých bytových domů a z jednotlivých staveb
20	Žádost o povolení k vypouštění odpadních vod do vod povrchových pro potřeby jednotlivých občanů (domácností) nebo o jeho změnu
21	Žádost o povolení k vypouštění odpadních vod do vod podzemních pro potřeby jednotlivých občanů nebo (domácností) o jeho změnu
22	Žádost o povolení k některým činnostem nebo o jeho změnu
23	Žádost o stavební povolení k vodním dílům
24	Žádost o stavební povolení k domovní čistírně odpadních vod, studni nebo jinému vodnímu dílu potřebnému k odběru podzemních vod pro potřeby jednotlivých občanů (domácností)
25	Žádost o povolení k užívání vodních děl
26	Žádost o povolení k vypouštění odpadních vod s obsahem zvlášť nebezpečné závadné látky do kanalizace nebo jeho změnu
27	Žádost o udělení souhlasu
28	Žádost o vyjádření
29	Žádost o vydání kolaudačního souhlasu k užívání vodního díla
30	Oznámení o užívání stavby vodního díla
31	Ohlášení
32	Žádost o povolení k odběru podzemních vod pro potřeby jednotlivých občanů (domácností) a o stavební povolení ke studni nebo jinému vodnímu dílu potřebnému k takovému odběru
33	Žádost o povolení k vypouštění odpadních vod do vod povrchových pro potřeby jednotlivých občanů (domácností) a o stavební povolení k domovní čistírně odpadních vod potřebné k takovému vypouštění
34	Žádost o povolení k vypouštění odpadních vod do vod podzemních pro potřeby jednotlivých občanů (domácností) a o stavební povolení k domovní čistírně odpadních vod potřebné k takovému vypouštění
35	Ohlášení vodních děl určených pro čištění odpadních vod do kapacity 50 ekvivalentních obyvatel
36	Žádost o stanovení ochranného pásma vodního zdroje nebo jeho změnu
37	Žádost o stanovení ochranného pásma vodního díla nebo jeho změnu
38	Žádost o stanovení způsobu a podmínek pro vypouštění důlních vod do vod povrchových nebo podzemních nebo jeho změnu
39	Žádost o stanovení podmínek pro použití závadných látek nebo o povolení výjimky při použití závadných látek nebo jeho změnu
40	Žádost o schválení manipulačního řádu vodního díla
41	Žádost o vydání loveckého lístku
42	Žádost o vydání rybářského lístku
Ostatní formulářové žádosti
43	Přihláška k místnímu poplatku za komunální odpad – trvalý pobyt, dospělý, zástupná osoba
44	Žádost o změnu v evidenci komunální odpad
45	Přiznání místního poplatku za psa
46	Odhlášení poplatku za psa
47	Žádost o poskytnutí dotace pro oblast kultury, TV a sportu, sociální oblast
48	Žádost o poskytnutí daru pro oblast kultury, TV a sportu, sociální oblast
49	Hlášení o vzniklých škodách na majetku města včetně pořízení fotodokumentace
50	Žádost o informace dle zákona číslo 106/1999 Sb.

6Fáze A – Implementace SYSTÉMU

Implementace SYSTÉMU bude provedena v jednotlivých požadovaných krocích a termínech uvedených v kapitole 3.

Minimální požadavky na Implementaci SYSTÉMU služby jsou uvedeny v následující tabulce.

Id	Plnění požadavku	Splněno
1	Zpracování Detailního cílového konceptu
2	Dodávka licencí
3	Implementace Zkušebního (Testovacího) prostředí, včetně požadovaných vazeb
4	Školení uživatelů a administrátorů jednotlivých aktivit informačního systému
5	Implementace Produkčního prostředí, včetně požadovaných vazeb a realizace Produkčního provoz s podporou

6.1Zpracování a akceptace Detailního cílového konceptu

Dokument Detailní cílový koncept bude obsahovat minimálně:

analýzu současného stavu a bude vycházet z popisu současného stavu, viz Příloha 3.a. ZD;
definici cílového stavu, která bude vycházet z požadavků na budoucí stav, viz tento dokument a bude doplněna Dodavatelem o analýzu současného stavu prováděnou pracovníky Dodavatele v aktuálních podmínkách Zadavatele;
Předmětná analýza a tvorba cílového konceptu bude probíhat v prostorách Zadavatele, tj. není přípustné zpracování formou dotazníku či korespondenční komunikace, a to v potřebném počtu specialistů za dodavatele dle jednotlivých částí systému.
návrh řešení instalace aplikační a databázové části systému (architektura technického řešení) detailní popis nastavení – konfigurace a parametrizace jednotlivých oblastí (společné registry, role a přístupová oprávnění, číselníky, reporty atd.);
návrh technického řešení integračních vazeb (vazby mezi agendami, vazby s vybranými aplikacemi zadavatele, vazby se spolupracujícími centrálními systémy;

návrh řešení postupu a pořadí při nasazování jednotlivých agend – upřesnění harmonogramu projektu, který bude vycházet z milníků uvedených v kapitole 3 a z Dodavatelem navrženého Harmonogramu projektu;

popis případných organizačních opatření nutných pro implementaci;
rozsah součinnosti ze strany zadavatele;
akceptační kritéria cílového stavu, pro ověření plnění Dodavatele v rámci Smlouvy o dílo jsou uvedena v tomto dokumentu, a to v tabulkách označených „Minimální požadavky …“, kde Dodavatel bude deklarovat svoji připravenost poskytovat bezvadné plnění již v rámci Zkušebního (testovacího) provozu.
Realizační (prováděcí) projekt – podrobný popis realizace dané části VZ, který bude zpracován Dodavatelem na základě návrhu Dodavatelem dodané Xxxxxxxx řízení projektu;

Formálně bude tato oblast Fáze A završena dohodnutým a vzájemně odsouhlaseným Předávacím protokolem dílčího plnění (Dodavatel předává dokument Detailní cílový koncept) a Akceptačním protokolem dílčího plnění, kterým Zadavatel akceptuje splnění podmínek této části Fáze A ve Smlouvě o dílo.
Dokumentace skutečného nasazení bude připomínkována Zadavatelem a připomínky budou ze strany Dodavatele vypořádány (tj. zapracovány, případně s jasným a konkrétním písemným zdůvodněním odmítnuty jako nevalidní). Ze strany zadavatele nebude v rámci připomínkování v případě nepravdivých, nepřesných nebo věcně nejasných informací v této dokumentaci požadováno její opravování na správné znění, bude se pouze jednat o vyznačení výše uvedených nedokonalostí a je na zadavateli jejich vypořádání.

6.2Dodávka licencí

Zadavatel požaduje v rámci plnění dodávku takového počtu uživatelských licencí, který zajistí legální provoz a využití SYSTÉMU ze strany uživatelů, a to jejich dále uvedeném počtu a skladbě.

Aktivita	Dodávka licence minimálně pro počet uživatelů	Max. počet současně pracujících uživatelů
Aktivita 1 – Centralizace správy uživatelů
	Multilicence	Multilicence
Aktivita 2 – Elektronizace vybraných agend IS
	Multilicence	Multilicence
Aktivita 3 - Centrální správa přestupků
	Multilicence	Multilicence
Aktivita 4 – Nástroj pro centrální evidence úřadu
	Multilicence	Multilicence
Aktivita 5 – Formulářová komunikace
	Multilicence	Multilicence

Z pohledu licencování bude dodavatel respektovat požadavek, že v případě potřeby či nutnosti využití podpůrných licencí potřebných k provozu předmětu plnění (např. run-time licence), budou takové licence v poměru 1:1 s licencemi samotných produktů.
Dodavatel nesmí v průběhu realizace zakázky či v době podpory, nebo v případě podepsání nové smlouvy navazující na předmět plnění dle této smlouvy, vůči zadavateli změnit licenční podmínky tak, že by došlo k navýšení či generaci finančního závazku vůči zadavateli.
Bude-li součástí licenčního modelu i „run-time“ (běhové prostředí), pak Zadavatel očekává takovou licenční politiku, která bude splňovat minimální požadavky Zadavatele na licenci SYSTÉMU.
Zadavatel vyžaduje splnění licenční politiky u „run-time“ (běhového prostředí) dle bodu 4) potvrzením, prohlášením či jiným osvědčením od autora (vlastníka) těchto licencí v případě, že je vlastník těchto licencí odlišný od Dodavatele.
Formálně bude tato oblast Fáze A završena dohodnutým a vzájemně odsouhlaseným Předávacím protokolem dílčího plnění (Dodavatel předává SW licence SYSTÉMU).

6.3Implementace Testovacího a Produkčního prostředí

Dodavatel vytvoří dvě prostředí:

Testovací prostředí

v rozsahu dle DCK,
které na infrastruktuře Zadavatele připraví Dodavatel,
s využitím testovacích dat a rozhraní.

Testovací prostředí bude sloužit zejména pro testování nastavení, migrací, rozhraní apod. a dále proškolení uživatelů a administrátorů a získávání praxe uživatelů a administrátorů na testovacím prostředí.

Produkční prostředí

v rozsahu dle DCK,
které na infrastruktuře Zadavatele připraví Dodavatel,
s využitím produkčních dat a rozhraní.

Produkční prostředí bude sloužit jednak k Testování a Akceptaci a dále k produkčnímu provozu.

Formálně bude tato oblast Fáze A završena dohodnutým a vzájemně odsouhlaseným Předávacím protokolem dílčího plnění (Dodavatel předává Testovací prostředí a Produkční prostředí) a Akceptačním protokolem dílčího plnění, kterým Zadavatel akceptuje splnění podmínek této oblasti ve Smlouvě o dílo.

6.4Produkční provoz s podporou

Implementace Produkčního provozu s podporou bude v rozsahu dle DCK.
Produkční provoz s podporou bude probíhat na produkčním prostředí.
Jeho účelem je zjistit, zda jsou splněny akceptační podmínky uvedené v tomto dokumentu a v DCK, včetně ověření funkčnosti veškerých vazeb se všemi provázanými subsystémy a ověření relevantnosti migrovaných dat v reálném provozu.
V průběhu Produkčního provozu s podporou může docházet k dílčím úpravám řešení tak, aby nedocházelo k omezení dané funkcionality.
Pokud dojde v průběhu Produkčního provozu s podporou k závadám, které omezí funkcionality plnění, prodlužuje se doba Produkčního provozu s podporou o stejnou dobu, po kterou nebylo plnění funkční (bez vad).
Formálně bude Fáze A završena dohodnutým a vzájemně odsouhlaseným Předávacím protokolem (Dodavatel předává plnění dle Smlouvy o dílo) a Akceptačním protokolem, kterým Zadavatel akceptuje splnění podmínek Fáze A ve Smlouvě o dílo.

6.5Předání a převzetí plnění

Předání a převzetí dokumentů

Dokumenty, které mají být vypracovány Dodavatelem a které se poskytují Zadavateli jako součást poskytování díla (zejména Detailní cílový koncept), budou nejdříve předloženy Xxxxxxxxxx ve formě návrhu k posouzení.
Dodavatel se zavazuje předat první verzi dokumentu Zadavateli k akceptaci ve lhůtě domluvené mezi Dodavatelem a Zadavatelem na základě Xxxxxxx o dílo, nebo jinak stanovené v souladu se Xxxxxxxx o dílo.
Zadavatel je oprávněn ve lhůtě pěti (5) pracovních dnů od doručení příslušného dokumentu písemně předložit Dodavateli své připomínky k návrhu.

Po diskusi o těchto připomínkách upraví Dodavatel příslušný návrh v souladu s dohodnutými změnami a se zapracováním těchto dohodnutých změn jej předá ve stejné lhůtě pěti (5) pracovních dnů Zadavateli.
V případě, že Zadavatel nemá k předaným dokumentům výhrady, považují se za převzaté k okamžiku doručení jejich konečné verze Zadavateli.
V případě, že Xxxxxxxxx připomínky ve lhůtě pěti (5) dnů nepředloží, má se za to, že s předloženým dokumentem souhlasí a dokument se považuje za řádně převzatý.

Dodaná dokumentace v rámci SYSTÉMU slouží k zachycení a vyhodnocování plánovaných činností a též k dokumentaci skutečného stavu.

Minimální požadavky na dokumentaci SYSTÉMU jsou v níže uvedené tabulce.

Id	Plnění požadavku	Splněno
1	Součástí prací bude vytvoření kompletní a detailní dokumentace dle standardů ISVS.
2	Dokumentace nebude chráněna dle autorského zákona, bude umožněno ji dále upravovat a předávat dalším subjektům, které se podílejí na chodu informačních systémů.
3	Dodavatel předloží plán tvorby dokumentace (jako součást Detailního realizačního projektu).
4	Dokumentace bude v elektronické formě, ve formátu PDF
Detailní cílový koncept
5	Úvodní seznámení s funkcionalitami dodávaného SYSTÉMU pro členy projektového týmu Zadavatele.
6	Kompletní analýza řešení problematiky SYSTÉMU a jeho implementace v prostředí Zadavatele, včetně stanovení rozsahu migrace a integračních vazeb na okolní AIS a eGovernment.
7	Grafické schéma a podrobný popis architektury řešení SYSTÉMU, obsahující přehled použitých serverů a jim přidělených zdrojů, včetně popisu funkčních vazeb.
8	Podrobný popis způsobu a rozsahu implementace SYSTÉMU včetně realizace odpovídajících integračních vazeb.
9	Návrh zátěžových, funkčních, integračních (akceptačních) testů SYSTÉMU.
10	Návrh monitoringu, zálohování a obnovy SYSTÉMU s využitím stávajících technologií Zadavatele.
11	Detailní harmonogram realizace zakázky SYSTÉMU vycházejícího z Milníků uvedených v ZD.
Realizační dokumentace SYSTÉMU
12	Bude zpracována kompletní implementační a provozní dokumentace v písemné i elektronické editovatelné podobě ve formátu MS Office, včetně popisu pravidelné údržby a dokumentace finálního provedení, zahrnující, krom jiného, i detailní popis rozhraní.
13	Bude zpracována dokumentace finálního vyhotovení SYSTÉMU včetně detailního popisu všech rozhraní. Součástí dokumentace bude i detailní popis API rozhraní testovacího i produktivního prostředí SYSTÉMU pro napojení aplikací třetích stran.
14	Pro podporu uživatelů a administrátorů budou zpracovány: uživatelské příručky metodické pokyny popisy procesů administrátorská příručka eLearningové kurzy (v technologii HTML)

Předání a převzetí ostatních plnění dle Xxxxxxx o dílo (vyjma služeb)

V případě, že součástí poskytování plnění Dodavatelem dle Xxxxxxx o dílo je plnění, které podléhá akceptaci Zadavatelem, musí dojít k podpisu Předávacích protokolů ohledně tohoto plnění v termínech uvedených v harmonogramu, není-li výslovně uvedeno jinak.

Detailní kritéria akceptace a vymezení plnění, která podléhají akceptaci Zadavatelem, jsou uvedena v tomto dokumentu, případně v Detailním realizačním projektu.
Jestliže plnění nebo jeho jednotlivé části splní kritéria akceptačního řízení, považují se za řádně ukončené a Zadavatel je povinen jej převzít.

Akceptační procedury zahrnují porovnání skutečných vlastností plnění se závaznou specifikací předmětu plnění dle Xxxxxxx o dílo.

Akceptační procedura bude zahrnovat akceptační testy, které budou probíhat na základě specifikace akceptačních testů obsahující popis testů, testovací data, příslušné prostředí, pořadí provádění testů a akceptační kritéria.

Nedohodnou-li se smluvní strany jinak, vypracuje specifikaci akceptačních testů Dodavatel a předá Zadavateli k odsouhlasení v termínu pěti (5) pracovních dnů před zahájením akceptační procedury dle harmonogramu.

Odsouhlasení bude provedeno písemnou formou v termínu pěti (5) pracovních dnů před zahájením akceptační procedury. Jestliže se Zadavatel v této lhůtě ke specifikaci akceptačních testů písemně nevyjádří, má se za to, že specifikaci akceptačních testů odsouhlasil.

Jestliže Zadavatel specifikaci akceptačních testů v uvedené lhůtě neodsouhlasil, je povinen Zadavatel v této lhůtě sdělit připomínky k Dodavatelem předložené specifikaci akceptačních testů a poskytnout Dodavateli veškerou potřebnou součinnost k dokončení a odsouhlasení specifikace akceptačních testů.

Lhůta pro provedení akceptačních testů a lhůta pro předání plnění nebo jeho části se prodlužuje o dobu, o kterou se prodloužilo písemné odsouhlasení specifikace akceptačních testů z důvodu připomínek na straně Zadavatele oproti lhůtě stanovené.

Dodavatel bude písemně informovat Xxxxxxxxxx, resp. jeho oprávněné osoby nejméně pět (5) dní předem o termínu zahájení akceptačních testů.

Zadavatel je oprávněn se těchto testů zúčastnit a osvědčit jejich konání, a to formou předávacího protokolu (nebo dílčích předávacích protokolů), podepsaného (podepsaných) oprávněnými osobami obou smluvních stran. Pokud se Zadavatel nedostaví v termínu určeném pro provedení akceptačních testů, ačkoli byl s tímto termínem řádně seznámen, je Dodavatel oprávněn provést příslušné akceptační testy bez jeho přítomnosti.

Takto provedené akceptační testy se považují za provedené v přítomnosti Zadavatele. Kopie veškerých dokumentů vypracovaných v souvislosti s provedením těchto akceptačních testů budou Zadavateli poskytnuty do pěti (5) dnů.

Základním předpokladem pro řádné předání plnění (nebo jeho části) Dodavatelem a převzetí tohoto plnění (nebo jeho části) Zadavatelem, a to formou předávacího protokolu podepsaného oprávněnými osobami obou smluvních stran je skutečnost, že plnění splní kritéria akceptačních testů uvedená v dohodnutých kontrolních specifikacích a bude provedeno v souladu se závaznou specifikací předmětu plnění dle Xxxxxxx o dílo.
Jestliže plnění nebo jeho část splní akceptační kritéria akceptačních testů, Dodavatel se zavazuje v den následující po ukončení akceptačních testů umožnit Zadavateli plnění nebo jeho část převzít a Zadavatel se zavazuje v tomto termínu plnění nebo jeho část převzít.

Pokud Zadavatel plnění nebo jeho část v tomto termínu nepřevezme, ačkoli převzetí plnění nebo jeho části bylo Dodavatelem řádně umožněno, má se za to, že plnění nebo jeho část bylo řádně předáno a Zadavatelem převzato právě v den následující po ukončení akceptačních testů.

Jestliže plnění nesplňuje stanovená akceptační kritéria kteréhokoliv akceptačního testu, budou výsledky akceptačního testu (splněno/nesplněno/s výhradami) spolu s uvedením termínů pro nápravu uvedeny ve vyhodnocení Akceptačního protokolu.

Dodavatel napraví tyto nedostatky a příslušné akceptační testy budou provedeny znovu.

Tento proces testování a následných oprav se bude opakovat, přičemž výše uvedená ustanovení se použijí obdobně.

Proces testování a následných oprav lze opakovat, dokud Dodavatel nesplní veškerá akceptační kritéria pro příslušný akceptační test, nejvýše však natřikrát (3x).

V situaci, kdy by bylo nutné opakovat akceptační testy více jak třikrát (3x) pro konkrétní fázi projektu, je v takovém případě nutný souhlas nadřízeného orgánu projektu – tzn. řídícího výboru nebo ředitelů projektu dle použité metodiky řízení projektu.

Žádný akceptační test se však nebude považovat za nesplněný, jestliže daný nedostatek nebyl způsoben Dodavatelem, nebo byl zjištěn nebo měl být zjištěn Zadavatelem před nebo při předcházejícím akceptačním testu, ale nebyl v té době oznámen Xxxxxxxxxx, nebo byl nepodstatný, tzn., neměl vliv na řádné poskytování funkčnost díla nebo jeho části tak, jak jsou vymezeny ve Xxxxxxx o dílo.
Při převzetí plnění nebo kterékoliv jeho části v souladu s tímto článkem je Zadavatel povinen podepsat potvrzení o přijetí plnění nebo dané části a Zadavatel i Dodavatel se zavazují podepsat příslušný předávací případně akceptační protokol (dílčí předávací případně akceptační protokoly), tj. potvrzení o předání a přijetí (převzetí) plnění nebo jeho určité části.

Migrace dat SYSTÉMU

Zadavatel požaduje kompletní migraci dat ze stávajících systémů.

Technologické prostředí

Instalace SYSTÉMU a jeho nastavení dle zadavatelem odsouhlasené dokumentace skutečného nasazení bude provedena na hardware a software Zadavatele, který bude dodán a instalován v rámci samostatné části projektu dle zadávacího řízení s názvem „Nové funkce IS města Beroun –technologická část“. Z tohoto důvodu bude v rámci před implementační analýzy definován skutečný rozsah HW/SW podpůrných komponent, na které se bude předmět plnění dle tohoto dokumentu implementovat.

Zadavatel požaduje v rámci plnění také instalaci a nastavení testovací (školící) instance, která bude obsahovat iniciální naplnění anonymizovanými / testovacími daty, bude mít nastavena přístupová oprávnění pro uživatele a bude sloužit k ověření funkčnosti řešení a pro možnost školení a testování systému ze strany jeho uživatelů.

Školení

Dodavatel poskytne školení pro uživatele a administrátory IS tak, aby všichni pracovníci Zadavatele byli schopni řádně užívat, respektive administrovat, instalovaný SYSTÉM.
Dodavatel poskytne školení tak, aby pracovníci Zadavatele získali další znalosti praktického využívání SYSTÉMU jako efektivní podpory procesů u Zadavatele, znalosti související a aktuální legislativou a jejími připravovanými změnami, znalosti metodické, tj. aby došlo k významnému přenosu znalostí a zkušeností z Dodavatele na Zadavatele.
Systém školení uživatelů je velmi podstatnou součástí realizace projektu pro úspěšné zavedení podpůrných nástrojů ICT do procesů s cílem zlepšení fungování úřadu.
Minimální požadavky na školení jsou v níže uvedené tabulce.

Id	Plnění požadavku	Splněno
1	Dodavatel předloží plán školení (jako součást Detailního realizačního projektu). Součástí plánu školení bude i realizace testování (přezkušování) získaných znalostí uživatelů a jejich uplatnění v praxi.
2	Bude provedeno základní seznámení s funkčností dodávaného systému pro členy projektového týmu Zadavatele na začátku realizace díla (před zpracováním detailní analýzy a Detailního realizačního projektu).
3	Bude provedeno školení administrátorů systému v rozsahu minimálně 8 školících hodin pro max. 3 zaměstnance určených Zadavatelem, které bude zahrnovat kompletní správu systému. Jako podkladový materiál musí být dodána administrátorská příručka.
4	Bude provedeno školení uživatelů na seznámení s obsluhou modulů dodaného systému. Jako podkladový materiál musí být dodána uživatelská příručka.
5	Veškerá školení poskytovaná v průběhu implementace (realizační fázi), která jsou součástí jednotlivých častí díla, zajistí Dodavatel na své náklady a v místě realizace.
6	Součástí každého produktu bude eLearningový kurz (v technologii html), který bude mít Zadavatel k dispozici nejpozději do 14 dnů od akceptace Cílového konceptu projektu.

Zadavatel se pro tyto účely zavazuje zajistit:

školící místnost s prezentační technikou,
připojení na technologickou infrastrukturu.

EXIT plán

Součástí projektu je vypracování ve prospěch Xxxxxxxxxx dokumentace tzv. EXIT plánu, vč. garance případných služeb, a to dle níže uvedených kritérií.

ID	Požadavek
1	Vypracování „Exitového plánu“ v dostatečném předstihu a poskytnutí nezbytné součinnosti k jeho realizaci.
2	Příprava a předání “Exitového plánu“ novému poskytovateli nebo Zadavateli.
3	Poskytnutí požadovaných součinností v souvislosti s předáním podpory a provozu SYSTÉMU podle pokynů Zadavatele novému poskytovateli.
4	Řádné předání všech dat zpracovávaných v Systému, včetně dat doplňkových.
5	Poskytnutí veškeré relevantní Dokumentace a potřebných informací Zadavateli.

7Fáze B – Servisní podpora SYSTÉMU, SLA

Požadavky, které musí Dodavatel minimálně naplnit na Servisní podporu SYSTÉMU jsou v níže uvedené tabulce.

Id	Plnění požadavku	Splněno
1	Dodavatel zajistí, že veškeré vlastnosti díla, včetně jeho update, legislativního update, upgrade a legislativního upgrade budou po celou dobu účinnosti Smlouvy o podpoře odpovídat vždy aktuálním obecně platným právním předpisům ČR a platným standardům ISVS.
2	Úpravy programového vybavení SYSTÉMU (obecné, rozvoj, legislativa apod.) zajistí s dostatečným časovým předstihem před nabytím účinnosti konkrétního právního předpisu, minimálně 5 pracovních dní.
3	V rámci běžného rozvoje jednotlivých modulů SYSTÉMU Dodavatel zajistí poskytnutí aktualizovaných verzí nejpozději do 3 měsíců po uvolnění nové verze k distribuci.
4	Budou poskytovány informace o změnách a nových funkcích v aktualizovaných verzích SYSTÉMU.
5	Bude prováděna průběžná aktualizace dokumentace k programovému vybavení tak, aby u Zadavatele byla vždy aktuální dokumentace k provozovanému SYSTÉMU.
6	Bude poskytována součinnost při zásadním upgrade operačního systému a databázového systému na vyšší verze.
7	Bude zajištěna udržitelnost SW třetích stran, dodaných Dodavatelem v rámci veřejné zakázky.
8	Servisní (Technická) podpora a servis budou poskytovány po celou dobu smluvního vztahu (min 60 měsíců ode dne protokolárního ukončení projektu dle Smlouvy o dílo). Poskytování technické a servisní podpory bude odpovídat příkladům nejlepší praxe dle rámce ITIL/ITSM.
9	Technická podpora a servis zařízení SW budou realizovány Dodavatelem, případně prostřednictvím odpovídajícího servisního kanálu výrobce.
10	Technická podpora a servis budou realizovány v místě Zadavatele. Výjimku tvoří činnosti realizované vzdáleným připojením Dodavatele do prostředí Zadavatele.
11	Veškeré požadavky budou evidovány v systému servisní podpory Dodavatele (HelpDesk).
12	Kontaktní místo umožní příjem požadavku na servisní zásah v českém jazyce prostřednictvím služby HelpDesk, popř. služby Hot-line.
13	Služba Hot-Line umožní příjem požadavku na servisní zásah v českém jazyce na telefonním čísle v režimu 5x9 (8 hodin v pracovní dny) v době od 08:00 do 17:00 hod, příjem požadavku bude zajištěn lidskou obsluhou.
14	Služba HelpDesk umožní příjem požadavku na servisní zásah v českém jazyce prostřednictvím webového rozhraní v režimu 7x24 (nepřetržitě vyjma nahlášených servisních zásahů Dodavatele při správě systému HelpDesk).
15	Služba HelpDesk umožní Zadavateli upřesnit nebo doplnit požadavek.
16	Služba HelpDesk bude Zadavateli poskytovat přehled o aktuálně nahlášených požadavcích, jejich stavu a aktuálním způsobu jejich řešení. Služba HelpDesk bude Zadavateli zasílat notifikace o změně stavu jeho požadavku (např. zadaný, v řešení, uzavřený atd.) a musí Zadavateli umožnit schvalování uzavření nahlášeného požadavku.
17	Služba HelpDesk bude poskytovat Zadavateli přístup i k uzavřeným požadavkům a způsobu jejich řešení, bude poskytovat podrobné údaje o historii požadavků od jejich nahlášení, po jejich vyřešení.
18	Služba Projektového metodika v rozsahu 15 člověkodní za rok
19	48 člověkohodin práce (systémové, konzultační, metodické) za rok pro rozvoj systému

V rámci zajištění podpory a servisu po dobu udržitelnosti projektu platí následující parametry SLA.
Definice stupňů závažnosti incidentů:

Závažnost Závady nebo Chyby		Definice závažnosti Závad a Chyb
A	Kritická chyba	Chyba způsobí, že poskytovaný SYSTÉM nelze zcela provozovat nebo má kritický vliv na provozované aplikace či stav podporovaného systému – vyžaduje okamžité řešení.
B	Urgentní chyba	Chyba výrazně omezuje správnou funkcionalitu SYSTÉMU lze provozovat s omezením nebo po určitou dobu ve formě náhradního řešení.
C	Chyba	Nekritická Chyba SYSTÉMU – provoz je problémem ovlivněn, ale lze provozovat bez výrazného omezení.
D	Námět na vývoj	Námět na vývoj bude předán Dodavateli prostřednictvím nástroje HelpDesk. Dodavatel bude tyto náměty vyhodnocovat a dle plošného přínosu do následujícího sestavení. Dodavatel má právo předmětné náměty odmítnout.

Definice maximální doby nástupů k řešení incidentů podle závažnosti:

Závažnost Chyby	Doba zahájení činnosti (od nahlášení)	Doba odstranění chyby	Řešení
A	4 pracovní hodiny	8 pracovních hodin	a
B	8 pracovní hodiny	16 pracovních hodin	a, b
C	16 pracovních hodin	32 pracovních hodin	a, b
D	podle dohody	podle dohody	c

Řešením se rozumí:

Odstranění Chyby SYSTÉMU. Opravy Chyb bude provádět Dodavatel do Aktualizované verze (kritické chyby ihned).
Poskytnutí přijatelného náhradního řešení problému ze strany Dodavatele.
Poskytnutí informace o akceptování/neakceptování námětu k zapracování do budoucích verzí.

Sankce za nedodržení výše uvedených termínů:

Za každou započatou hodinu překročení mezních termínů chyb v kategoriích A, B, C má Zadavatel právo na smluvní pokutu 500 Kč.

8Požadavky na technický popis řešení v nabídce

Specifikace předmětu plnění

Přehled plnění požadovaných minimálních parametrů

Dodavatel vloží vyplněný tento dokument doplněný u jednotlivých položek označených jako „Minimální požadavky …“.

Technický popis SYSTÉMU
1. Grafické schéma a podrobný popis architektury SYSTÉMU.
2. Grafické schéma bude poskytovat ucelený přehled architektury SYSTÉMU, zejména

- interní vazby jednotlivých částí (modulů / agend) - datový a logický model a

- externí vazby SYSTÉMU na jiné (stávající) AIS Zadavatele.

Grafické schéma architektury SYSTÉMU bude doplněno přehledným popisem SYSTÉMU v souladu se strukturou požadavků definovaných v tomto dokumentu.

Dále Dodavatel uvede detailní popis API rozhraní SYSTÉMU pro napojení jiných (stávajících) IS Zadavatele.
Počet a identifikace poddodavatelů.
Popis řešení „Jednotná správa SYSTÉMU“ v rozsahu nejvýše 2 stránek formátu A4, dle podmínek uvedených v ZD.
Rozsah školení vč. uvedení počtu dní školení navrženého Dodavatelem
Xxxxx Xxxxxxxx řízení projektu a Harmonogramu projektu.

Strana 1

Document Metadata

Table of Contents

Zadávací dokumentace – Příloha č. 3.b

Document Metadata