Zadávací dokumentace – Příloha č. 1

Zadávací dokumentace – Příloha č. 1

k nadlimitní veřejné zakázce na dodávky

„Rozšíření funkcí portálu občana města Český Brod“

Obsah

1. Zkratky a pojmy 3

2. Místo plnění 3

3. Doba plnění 3

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

5. Požadavky na řešení rozšíření portálu občana 4

5.1 Požadavky na společné vlastnosti řešení 5

5.2 Realizační část – Rozšíření funkcí portálu elektronických služeb s platební branou 6

5.2.1 Současný stav 6

5.2.2 Realizační část 8

5.3 Realizační část – Rozšíření funkcí agendy místních poplatků 9

5.3.1 Současný stav: 9

5.3.2 Realizační část 14

5.4 Realizační část – Rozšíření funkcí podpory rozhodovacích procesů 15

5.4.1 Současný stav: 15

5.4.2 Realizační část 16

5.5 Realizační část – Rozšíření funkcí robotizace správy přestupků 17

5.5.1 Současný stav: 17

5.5.2 Realizačních část 19

6. Fáze A – Implementace řešení 22

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

6.2 Dodávka licencí 22

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

6.4 Produkční provoz s podporou 23

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

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

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

6.5.3 Migrace dat 26

6.5.4 Technologické prostředí 26

6.5.5 Školení 27

6.5.6 EXIT plán 27

7. Fáze B – Servisní podpora řešení, SLA 28

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

1. Zkratky a pojmy

1. Zkratky a pojmy užité v ZD jsou uvedeny v Příloze 3.a ZD, specifické zkratky a pojmy poplatné zejména této části VZ jsou v následující tabulce.

2. Jedná se o podpůrnou informaci, kterou Zadavatel poskytuje pro zachování jednoznačného výkladu textu dokumentu.

Zkratka / pojem	Význam
DCK	Detailní cílový koncept
Části projektu	Popis rozsahu řešení je rozdělen do realizačních částí projektu specifikovaných v kapitolách 5.2 až 5.5
Portál občana	Dílo realizované v předchozím projektu, na který bude projekt Rozšíření portálu občana navazovat
SLA	Service Level Agreement
Fáze A	Implementace technologií v souladu se Smlouvou
Fáze B	Servisní (technická) podpora technologií v souladu se Smlouvou
Smlouva	V rámci tohoto dokumentu je pojmem Xxxxxxx myšlena Příloha č. 3 ZD

2. Místo plnění

Místem plnění je budova MÚ na adrese specifikované v Zadávací dokumentaci.

3. Doba plnění

1. Dodávka jednotlivých částí projektu bude zahájena po podpisu smlouvy VZ a bude řízena milníky uvedenými v Tabulce níže

2. Milníky Fáze A dané části VZ (implementace) dle Smlouvy.

Id	Činnosti		Termín
01	Nabytí účinnosti Smlouvy		bude upřesněno dle ukončení zadávacího řízení
Fáze A – Implementace Portálu občana
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 4 týdnů od nabytí účinnosti smlouvy
03	Instalace SW Předání dílčího plnění		do 4 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 Testování funkčnosti na testovacím prostředí (1 měsíc) Akceptace Testovacího provozu a školení	do 8 týdnů po Id 03
05		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 Ukončení Fáze A	do 4 týdnů po Id 04

3. Fáze B – Servisní (technická) podpora implementovaného řešení dle Smlouvy o podpoře bude zahájena ukončením Fáze A (ukončení projektu akceptací produktivního provozu s podporou).

4. 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.

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

1. 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ě.

2. 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 řešení, kterou bude možné ověřit již v testovacím provozu (Testovací provoz, např. v rámci školení uživatelů a administrátorů).

3. Nesplnění kteréhokoli ze stanovených minimálních požadavků bude znamenat vyloučení účastníka ze zadávacího řízení.

4. Zadavatel požaduje, aby Dodavatel, kromě vyplnění tabulek v kapitole 5, podrobně popsal návrh nabízeného řešení v samostatné kapitole.

5. Tato kapitola 4 platí pro následující kapitoly 5 až 7.

5. Požadavky na řešení rozšíření portálu občana

Poptávané řešení bude navazovat na předchozí projekt Portál občana, který řešil nové funkčnosti v dílčích oblastech:

1. Statické stránky webu;

2. Portál elektronických služeb s platební branou;

3. Místní poplatky;

4. Podporu rozhodovacích procesů;

5. Robotizaci správy přestupků;

6. Participaci na řízeném rozvoji města.

Projekt byl úspěšně ukončený v červenci 2024.

Poptávané rozšíření bude rozšiřovat funkčnosti Portálu občana v oblastech:

2. Portál elektronických služeb s platební branou;

3. Místní poplatky;

4. Podpora rozhodovacích procesů;

5. Robotizace správy přestupků;

jejichž požadovaná rozšíření funkčností jsou podrobně popsána v kapitolách 5.2 až 5.5.

Je požadována realizace v rozsahu:

• dodávky potřebných licencí;

• navázání na již instalovanou aplikační a databázové části Portálu občana včetně napojení na stávající testovací instanci;

• implementace služeb:

• provedení integrací na současné systémy v prostředí IS zadavatele;

• úpravy dodaného řešení dle potřeb a požadavků dle pokynů zadavatele;

• zaškolení uživatelů a administrátorů;

• testování;

• zvýšené podpory v předproduktivním provozu;

• dokumentace:

• k dodaným částem informačního systému v požadovaném rozsahu;

• k dodaným integračním rozhraním.

1. Požadavky na společ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 dodaných čá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	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
7	Administrace a konfigurace bez nutnosti zásahu zhotovitele.
8	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).
9	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.
10	Součástí licencí pro poptávané řešení 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.).
11	Nastavení všech parametrů řešení bez nutnosti zásahu dodavatele.

2. Realizační část – Rozšíření funkcí portálu elektronických služeb s platební branou

   1. Současný stav

Portál elektronických služeb s platební branou slouží ke správě a úhradě poplatků z poplatkových vyhlášek. Součástí řešení je systém plateb za pokuty a platby za parkování. Všechny platební agendy se obejdou bez formulářů, protože portál umožňuje správu poplatkových dat přímo uživateli.

Pro přístup ke zvoleným funkcím má uživatel možnost zvolit způsob ověření prostřednictvím NIA, bankovní identity nebo Mobilní klíč eGovernmentu.

Vlastnosti řešení pro Portál elektronických služeb s platební branou jsou uvedeny v následující tabulce:

Základní vlastnosti
1	Lokalizace v českém jazyce s možností dalších jazykových mutací.
2	Služba portálu je rozdělena na veřejně dostupnou část a interní část označovanou jako portálový backoffice.
3	Služba portálu je kompatibilní s aktuálními verzemi webových prohlížečů (Chrome, Firefox, Edge a Safari, Opera).
4	Dostupnost veřejné části portálu občana je zajištěna v režimu 24x7.
5	Portál splňuje pravidla přístupného webu dle normy EN 301 549 V2 1.2 standardu WCAG 2.1.
6	Portál splňuje pravidla pro uchovávání cookies dle normy opt-in, tzn. před jakýmkoliv shromažďováním cookies je nutný vyslovený a informovaný souhlas uživatele.
Bezpečnostní vlastnosti
1	Portál běží na zabezpečené URL.
2	Komunikace veřejné části a interní části probíhají zabezpečeně, pomocí komunikační mezivrstvy.
3	Předávání dat z interní části do portálu probíhá periodicky pomocí dávek v definovatelných intervalech.
4	Přenos dat je šifrován a je anonymní pro znemožnění sestavení dat v případě jejich odchycení.
5	On-line načtení dat probíhá v případě prvního přihlášení.
6	Pro provoz portálu není vyžadován žádný prostup do vnitřní sítě úřadu (pro potřeby komunikace s portálovým backoffice).
7	Veškerá osobní data k subjektu jsou uchovávána v portálovém backoffice, v portálu mohou být pouze údaje nutné pro přihlášení.
Technické parametry
1	Portál je instalován v DMZ a portálový backoffice je instalován ve vnitřní síti úřadu.
2	Portál je implementován s využitím kontejnerových technologií.
Registrace a autentizace
1	Registrace a přihlašování je možné pomocí služeb NIA. bankovní identity nebo Mobilní klíč eGovernmentu.
3	Registrace je možná i off-line na přepážce úřadu pomocí průvodce v portálovém backoffice.
4	Na přepážce je také možné vyřešit přiřazení FO, FOP nebo PO. To samé je možné i po přihlášení v profilu občana.
Konto občana
1	Po přihlášení má občan k dispozici správu svého profilu, ve které může měnit kontaktní údaje (telefon, e-mail).
2	Uživatel má ve svém profilu náhled informací o svém přihlášení a nastavení k zastupování.
Procesní vlastnosti
1	Portál obsahuje hlavičku, hlavní nabídku, obsahovou část, patičku a pozadí s editovatelnou fotografií.
2	Při pohybu v portálu je ve všech podkategoriích zobrazována drobečková navigace.
3	Hlavní nabídka je konfigurovatelná v portálovém backoffice.
4	Nepřihlášenému uživateli je při první návštěvě zobrazena úvodní stránka s rozcestníkem, výzvou k přihlášení, odkazem na nápovědu a cookies.
5	Nepřihlášenému uživateli jsou k dispozici veřejné informace, které jsou zveřejněny v jednotlivých částech portálu (sekce: životní situace, formuláře, a jakékoliv textové stránky editovatelné v portálovém backoffice a zveřejněné v portálu občana).
7	Přihlášenému uživateli je na úvodní stránce dostupné saldo jeho závazků v přehledném dashboardu.
8	Obsahové stránky portálu jsou viditelné a indexovatelné pro vyhledávače (google, seznam) a splňují základní požadavky na SEO (sémanticky psaný kód, meta klíčová slova a meta popisky).
Jak si vyřídit
1	Sekce „Jako si vyřídit“ je vytvořena jako uživatelsky editovatelná, zobrazující textové stránky ve stromové struktuře (editovatelné z portálového backoffice).
2	Řešení obsahuje základní set životních situací, jejich textů a grafiky.
4	Textová stránka je editovatelná za pomoci wysiwyg editoru.
6	V rámci celé části životní situací je možné využití fulltextového vyhledávání.
Elektronické platby
1	Po přihlášení jsou uživateli zobrazeny jeho závazky v přehledném dashboardu dle jednotlivých typů závazků.
2	Každý typ závazku je možné rozkliknout a zobrazit jeho detail, který obsahuje saldo, přehled předpisů a provedených plateb.
3	V rámci detailu závazku je možné: provést platbu pomocí QR kódu; zobrazit údaje k platbě; provést platbu přes platební bránu.
4	Platba kartou je uživaateli zobrazena jako nezaúčtovaná operace, která ponižuje saldo konkrétního typu závazku a je odstraněna v případě reálného zaúčtování v ekonomickém systému.
Integrační vazby
1	Agendový IS místní poplatky, viz popis integračních vazeb v kap. 5.3
2	Integrace na IS Podpora rozhodovacích procesů, viz popis v kap. 5.4
3	ISZR prostřednictvím XZR PROXIO MARBES registrace na ISZR
4	Integrace na NIA
5	Integrace na Přestupky, viz popis integračních vazeb v kap. 5.5

2. Realizační část

Část Portál elektronických služeb s platební branou v dokončeném projektu bude rozšířená o další funkce dále popsané.

Uvedené požadované vlastnosti rozšíření řešení pro Portál elektronických služeb s platební branou jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na rozšíření funkčnosti Portálu elektronických služeb s platební branou	Splněno
Integrace s IS GINIS
1	Je požadováno rozšíření stávajícího rozhraní GINIS DDP a GINIS KOF, které vznikají mimo aktuálně implementované agendové systémy.
2	Je požadováno rozšíření integrace s ES GINIS pro on-line odesílání plateb. Platby budou online předávány přímo z portálu po potvrzení jejich realizace prostřednictvím platební brány a informace o provedené úhradě se následně projeví jak v účetním, tak v agendovém systému města bez ohledu na to, kdy dojde k reálnému převodu peněz od poskytovatele platební brány. Nová integrace umožní na portálu využít hromadnou platbu, kdy jednou platbou občan uhradí více typů závazků případně i více subjektů (např. platba za rodinu).
Správa záborů
1	V řešení záborů budou připraveny formuláře pro elektronické podání záboru včetně všech jeho příloh. Přílohy mohou být i mapové podklady.
2	Součástí řešení záborů bude možné zobrazit přehledovou mapu všech aktuálních záborů.
3	Je požadována možnost založení nového řízení na základě podané žádosti zaevidované ve spisové službě úřadu, příp. založení nového řízení z moci úřední bez prvotní vazby na spisovou službu úřadu s následným vytvořením vazby při prvním odeslání dokumentu do spisové služby úřadu. Uživatelé získají přehledné informace o přidělených doručených dokumentech na základní obrazovce aplikace. Rozhraní na spisovou službu musí být připraveno na nové konektory v souladu s NSESSS.
4	V aplikaci budou evidovány kompletní údaje o subjektech na případu vč. evidence zástupce a oprávněné osoby subjektu, bude možné ověření subjektů ze základních registrů vč. notifikace o změnách údajů evidovaných subjektů.
5	V případě žádosti zadané přes Portál občana budou do případu dotaženy žadatelem vyplněné základní údaje o subjektech.
6	Zábory bude možné zakreslovat pomocí textového zadání adresy či standardním zákresem bodu, linie, polygonu do mapy. V mapě bude možné lokalitu vyhledávat textovým zadáním adresy. Složité zákresy (např. DIO) bude možné vkládat jako samostatné soubory, které bude možné následně i zveřejnit v rámci publikace záborů pro veřejnost.
7	Řešení umožní zobrazení mapových podkladů ve formátech WMS a WMTS pro rastrové vrstvy pro vektorové vrstvy.
8	Jednotlivá správní řízení budou přehledně zobrazována v mapových podkladech, což napomáhá snadné identifikaci kolizí jednotlivých řízení, vyhledávání rozpracovaných i schválených akcí dle lokality, období (předdefinovaná období či vlastní období) a typu lokality.
9	U jednotlivých případů bude možná evidence stavů řízení. Případy s různými stavy řízení (evidováno, projednáváno, přerušeno, rozhodnuto apod.), budou přehledně označeny na základní obrazovce uživatele.
10	Publikace údajů o záborech pro veřejnost bude probíhat ve vazbě na stav řízení (např. stav řízení rozhodnuto). Publikace mapového podkladu se všemi aktuálními zábory bude probíhat prostřednictvím stávajícího Portálu občana.
11	U jednotlivých řízení bude možné sledovat lhůtu pro vydání rozhodnutí a nabytí právní moci.
12	Dokumenty v řízení budou vytvářeny buď ze šablony s využitím datových položek (datové položky doplní do dokumentu základní údaje případu, subjekty a speciální údaje silničního hospodářství vyplněné na případu) nebo z dokumentu na disku, v obou případech s možností úprav ve vygenerovaném dokumentu, možnost využití knihovny textů – součástí nabídky je dodání 10 vzorových šablon. Šablony bude možné vytvářet a upravovat uživatelsky přímo z prostředí agendového systému.
13	Aplikace umožní elektronické podepisování vytvořených dokumentů včetně podpory předání k podpisu pověřené osobě, konverze dokumentu a připojení časového razítka bez nutnosti odskoku do spisové služby.
14	Aplikace umožní nastavení režimu zástupů na případech (v případě nepřítomnosti vlastníka případu) - přehledné zobrazení koho referent zastupuje a kým je zastupován.
15	Oprávnění uživatelů pro aplikaci budou spravována v IDM. Budou podporovány tři základní role uživatelů: referent, vedoucí a náhled.
16	Aplikace bude disponovat také pracovním prostředím pro vedoucí pracovníky, ve kterém bude možné kromě podepisování dokumentů, získat přehledně základní informace o stavu případů (souhrn případů dle typu případu a stavu řízení) a o práci jednotlivých podřízených pracovníků (souhrn případů jednotlivých pracovníků dle stavů řízení).

3. Realizační část – Rozšíření funkcí agendy místních poplatků

   1. Současný stav:

Řešení Místní poplatky je spustitelné na mobilních zařízeních a obsahuje kontrolní přehledy dat. Správci poplatků mají předdefinované pohledy na důležitá data.

Vlastnosti řešení Místní poplatky jsou uvedeny v následující tabulce:

Obecné vlastnosti
1	Řešení umožňuje evidovat místní poplatek za komunální odpad, místní poplatek ze psů, místní poplatek za užívání veřejného prostranství, místní poplatek z pobytu a místní poplatek ze vstupného.
2	Je možné filtrování pohledů na finanční data v rámci jednotlivých roků s možností přepínání jednotlivých roků dle požadavku.
3	Je možné vyhledání poplatků určených k archivaci (poplatky bez aktivních dat, vyrovnaný finanční stav) a nástroj na jejich archivaci, tedy trvalé odstranění všech evidovaných osobních údajů dle platné legislativy.
4	Řešen umožňuje nastavit datum automatického předepsání poplatků, automatické upomínání neuhrazených pohledávek, automatické vyměření poplatků, automatické vyrozumění o neuhrazených exekučních titulech a automatické předávání neuhrazených exekučních titulech do vymáhání, a to jednotlivě pro všechny typy místních poplatků.
Bezpečnostní vlastnosti
1	Veřejná část aplikace je provozována odděleně od interních aplikací určených pro práci úředníka.
2	Veřejná část aplikace nevyžaduje přímý prostup do interních aplikací.
3	Pokud jsou ve veřejné části aplikace trvale ukládat vlastní data, jsou tato data chráněna proti zcizení.
Technické vlastnosti
1	Veřejná část aplikace je vyvinuta v kontejnerové technologii.
2	Veřejná část aplikace je funkční i v případě odstávky či nedostupnosti interní aplikace pro úředníky, a to v minimálním rozsahu přihlášení občana a zobrazení dat o poplatcích a platba kartou.
3	Veškerá data musí být bezpečně uložena v databázi/souborovém úložišti interních aplikací.
4	Veřejná část aplikace kromě vlastní konfigurace trvale ukládá pouze data, která se dají v případě ztráty obnovit z dat interní aplikace.
5	Aplikace obsahuje endpoint určený pro uptime monitoring.
Vyhledávací vlastnosti
1	Pro snadné vyhledávání dat aplikace obsahuj inteligentní našeptávač hledaných dat na základě identifikačních údajů poplatku (příjmení, jméno, datum narození, název právnické osoby, IČO, adresa, variabilní symbol).
2	Aplikace disponuje rychlým vyhledáváním dat i v případě, že v aplikaci je evidována kompletní historie poplatků se všemi údajů (statisíce poplatků).
Kontrolní mechanismy
1	Za účelem nadstavbových analytických činností aplikace umí zobrazit údaje o jednotlivých místních poplatcích v datových přehledech Microsoft Power BI.
2	Aplikace je schopna prezentovat zvolená data z agendových systémů.
3	Aplikace umožňuje prezentovat anonymizovaná a agregovaná data občanům, úředním osobám i managementu úřadu.
4	Aplikace je schopna napojení prezentace dat na jakýkoliv systém, který má uložená data v DB.
Reportování
1	Aplikace obsahuje funkce pro zobrazování sumarizačních údajů jednotlivých místních poplatků v jednoduchém formátu infografiky za účelem rychlého zjištění aktuálních informací o jednotlivých místních poplatcích.
Kvalita dat
1	Aplikace provádí automatickou datovou profylaxi dat u jednotlivých místních poplatků za účelem identifikace dat pro další zpracování a za účelem nápravy dat. Typicky se jedná o profylaxe: - změny ze Základních registrů; - duplicitní poplatníci; - nepřevedené dluhy nezletilců k zákonným zástupcům; - senioři s chybnou sazbou; - nepodaná hlášení k provozovnám; - adresáti bez doručení; - poplatníci v insolvenci; - poplatky, kterým hrozí prekluze; - poplatky, které se mohou archivovat; - neztotožněné subjekty oproti Základním registrům.
Pracovní přizpůsobení
1	Řešení umožňuje přepínání (odskoky) do potřebné legislativy týkající se jednotlivého místního poplatku (zákon o místních poplatcích, daňový řád, správní řád, vyhláška).
2	Je možné vkládání vlastních poznámek za účelem dalšího zpracování dat na poplatku.
3	Je možné evidovat vlastní seznam poplatků uživatele, které má ve zpracování a na kterých bude následně pracovat.
Poplatek za odpad
1	Aplikace umožňuje zaevidování a odhlášení poplatníka pro všechny životní situace.
2	Aplikace umožňuje zaevidovat osvobození nebo úlevy poplatníka (všech zákonných typů).
3	Aplikace umožňuje pravidelné načítání dat změn ze Základních registrů (přistěhování, odstěhování, narození, úmrtí) a tyto změny kompletně zpracovává (automatizovaně zpracuje data, zaeviduje, doplní případná osvobození a úlevy a dle všech údajů vypočte správnou výši místního poplatku).
4	Aplikace umožňuje pravidelné načítání dat z katastru nemovitostí a vyhodnocuje podezřelé adresy.
5	Aplikace automatizovaně kontroluje, zdali není jeden poplatník přihlášen na základě trvalého bydliště a zároveň na základě vlastnictví nemovitosti.
6	Aplikace automatizovaně kontroluje, zda nezletilí poplatníci nemají dluh, aplikace příp. automatizovaně převádí dluh k zákonnému zástupci v den splatnosti předpisu pohledávky.
Evidence dat k místnímu poplatku za odpad
1	Aplikace eviduje všechna místa svozu komunálního odpadu.
2	Aplikace eviduje jednotlivé typy nádob komunálního odpadu a jejich počty.
3	Aplikace eviduje četnost svozu nádob komunálního odpadu.
4	Aplikace eviduje osvobození a úlevy z poplatku za komunální odpad.
5	Aplikace eviduje tzv. přísypy a nahlášení o nepovoleném přísypu.
Místní poplatek – pes
1	Aplikace umožňuj přihlásit nebo odhlásit jednoho či více psů a automaticky vypočítává výši místního poplatku odpovídající všem zadaným hodnotám (očipování, sleva za útulek, sleva za čip, osvobození poplatníka, úlevy poplatníka).
2	Aplikace musí umožnit úpravu evidenčních údajů psa a zaevidování všech zákonných typů osvobození a úlev psa, zobrazuje historii platností všech sazeb na poplatku, evidenci očipování,
3	Aplikace je připravena na možnost ověření očipovaného psa v připravovaném celonárodním registru psů.
4	Aplikace disponuje nástrojem na vyhledávání údajů o psu a o majiteli psa městskou policií.
Místní poplatek - Vstupné
1	Aplikace umožňuje zaevidování kulturní, sportovní, prodejní či reklamní akce za účelem vyměření místního poplatku. Aplikace dle platného sazebníku automaticky vypočítá výši místního poplatku.
Platby za zábor veřejného prostranství
1	Aplikace umožňuje zaevidování užívání veřejného prostranství s možností výběru dané sazby, s možností výběru dnů, ve kterých bude veřejné prostranství užíváno a musí automaticky vypočítat výši místního poplatku.
2	Aplikace umožňuje jednoduché prodloužení / opakování užívání veřejného prostranství, např. vyhrazené parkovací stání.
3	Aplikace umožňuje zaevidování užívání veřejného prostranství z externího systému, např. z IS na evidenci zvláštního užívání komunikace.
Pobytové poplatky
1	Aplikace umožňuje evidenci nové provozovny, úpravu jejích údajů a případné ukončení takové provozovny.
2	Aplikace umožňuje zaevidování hlášení k dané provozovně a na základě zadaných údajů automatický výpočet místního poplatku dle platného sazebníku.
3	Aplikace umožňuje zobrazení všech historických hlášení k dané provozovně
4	Aplikace umožňuje automaticky provést kontrolu provozovny, u které chybí podané hlášení za účelem kontaktování dané provozovny a vyměření místního poplatku.
Evidence a správa
1	Aplikace umožňuje evidenci poplatníka typu fyzická osoba, fyzická osoba podnikající či právnická osoba a všech typů dokladů a kontaktů.
2	Aplikace komunikuje se Základními registry za účelem aktualizace údajů poplatníků.
3	Aplikace umožňuje evidenci zákonných zástupců nezletilých poplatníků s automatickým odstraněním zákonných zástupců v den zplnoletnění nezletilce.
4	Aplikace umožňuje označení poplatníka jako neplatiče (subjekt, který většinově své místní poplatky neplatí). Aplikace musí automaticky vyhodnocovat bonitu poplatníka a případně označit poplatníky jako neplatiče. Xxxx neplatiči musí být následně vyloučeni z hromadných akcí typu vyměření poplatku a nebude jim zasílán dokument platebního výměru (vyměřují se hromadným předpisným seznamem).
5	Aplikace disponuje kontrolou ztotožnění adres poplatníků a kontrolou zákonných zástupců nezletilých poplatníků.
Kompletní správa místních poplatků
1	Aplikace vytváří jednotlivé i hromadné upomenutí neuhrazených pohledávek.
2	Aplikace vytváří jednotlivé i hromadné vyměření neuhrazených pohledávek, a to jak platebním výměrem, tak i hromadným předpisným seznamem.
3	Aplikace vytváří jednotlivé i hromadné vyrozumění neuhrazených exekučních titulů a předání neuhrazených exekučních titulů do vymáhání.
4	Aplikace umožňuje zaslání žádosti o vrácení přeplatku na email konkrétního uživatele (typicky uživatel účtárny).
5	Aplikace podporuje režim splátkování (evidence žádostí o splátky, zpětvzetí žádostí o splátky, rozhodnutí o povolení žádosti o splátky, rozhodnutí o zamítnutí žádosti o splátky, kontrola splácení, zrušení rozhodnutí o povolení splátek, posečkání splácení).
Práce s dokumenty
1	Aplikace obsahuje dokumenty Přihlášení k místnímu poplatku, Upomenutí neuhrazené pohledávky, Platební výměr, Hromadný předpisný seznam, Vyrozumění o neuhrazeném exekučním titulu.
2	Aplikace umožňuje v případě tzv. nepovinných dokumentů (Upomínka, Vyrozumění) odeslání SMS a emailu poplatníkovi.
3	Aplikace je propojena se spisovou službou standardem NSESSS a umožňuje automatické vypravení dokumentu dle platné legislativy.
4	Aplikace umožňuje tvorbu a ukládání pouze validních souborů formátu PDF a PDF/A.
5	Aplikace disponuje funkcí podepisování dokumentů samotným uživatelem i možností předání k podpisu (typicky jeho nadřízeným).
6	Aplikace automaticky notifikuje uživatele, na jehož podpis se čeká při tvorbě dokumentů.
Napojení na informační systém Insolvenční rejstřík
1	Aplikace umožňuje aktualizaci dat napojením na Insolvenční rejstřík a poskytuje aktuální údaje o tom, zdali je daný poplatník součástí nějakého insolvenčního spisu či nikoliv.
Integrace s Portálem občana
1	Na portálu občana je k dispozici seznam jeho místních poplatků. Pro každý místní poplatek zobrazena data o financích (předpisy pohledávek, platby), data o proběhlé komunikaci (odeslané emaily, SMS, dokumenty) a agendová data (údaje z jednotlivých místních poplatků - psi, provozovny, hlášení, užívání veřejného prostranství, data k odpadům, akce ze vstupného).
2	Psi - na portálu je uživateli umožněno online přihlásit a odhlásit psa, zaevidovat očipování psa. Uživateli je umožněno online upravit sazbu (přidat osvobození či úlevu).
3	Veřejné prostranství - Na portálu je uživateli umožněno online prodloužit užívání veřejného prostranství.
4	Vstupné - na portálu je uživateli umožněno online zadat novou kulturní, sportovní, reklamní nebo prodejní akci.
5	Vstupné - na portálu je uživateli umožněno online upravit údaje kulturní, sportovní, reklamní nebo prodejní akce.
6	Pobyt - na portálu je uživateli umožněno online zadat novou provozovnu a údaje o provozovně nebo hlášení provozovny, zobrazit seznam všech podaných hlášení.
7	Odpady - na portálu je uživateli umožněno online požádat žádost o úlevu nebo osvobození, požádat o svoz komunálního odpadu nebo požádat o zrušení svozu komunálního odpadu.
8	Na portálu jsou k dispozici údaje k platbě místního poplatku (částka, VS, účet, QR).
9	Na portálu je uživateli umožněno uhrazení místního poplatku platební kartou.
10	Na portálu obce je uživateli umožněno online požádat o splácení dluhu.
Integrace
1	Aplikace disponuje integračním rozhraním na PROXIO XZR v oblasti vazby na Základní registry.
2	Aplikace disponuje integračním rozhraním pro komunikaci s ekonomickým systémem GINIS v oblasti subjektů a pohledávek.
3	Aplikace disponuje integračním rozhraním na spisovou službu GORDIC.
4	Aplikace disponuje integračním rozhraním na IS PROXIO PRX v oblasti aktualizace údajů z insolvenčního rejstříku.
5	Aplikace disponuje integračním rozhraním na IS PROXIO Katastr v oblasti aktualizace údajů o nemovitostech na území obce.
6	Aplikace umožňuje export dat do Microsoft Power BI za účelem nadstavbových analytických činností.
7	Aplikace umožňuje export dat pro svozové společnosti za účelem nastavení správného harmonogramu svozu komunálního odpadu.
8	Aplikace je připravena na možnost ověření očipovaného psa v připravovaném celonárodním registru psů.
Elektronické podání
1	Aplikace umí zobrazovat podání uskutečněná prostřednictvím portálu.
2	U podání jsou zobrazeny základní údaje a je možné si vytvořené podání zobrazit/stáhnout v PDF formátu.
3	V rámci integrace se spisovou službou je možné u jednotlivých podání zobrazit přidělenou spisovou značku a stav řešení.
4	V rámci integrace se spisovou službou je možné zobrazit i podání, která byla uskutečněna jinou cestou než přes portál občana.
Správa portálu
1	Aplikace umožňuje konfiguraci pro jednotlivé části portálu: vzhled, správu účtů, redakční systém a notifikace.
2	Přístup do portálového backoffice je řízen na základě přidělených práv jednotlivým úředníkům.
3	Portálový backoffice je schopen řešit přístup úředníků za pomoci JIP/XXXX.
4	Po přihlášení má úředník základní přehled statistik, které eviduje portál (výčet uveden v sekci statistiky).
5	V rámci správy účtů občanů je možné založit nový účet, editovat, přiřadit zastupování nebo smazat celý portálový účet.
6	V redakčním systému je možné upravovat: hlavní nabídku, kategorie, textové stránky.
7	Obsah z redakčního systému je možné exportovat a také nahrát za pomoci exportního souboru (například pro potřeby přenosu z TST prostředí na PRO prostředí).
8	V rámci notifikací je možné nastavit a zapnout typy notifikací (e-mail, sms), vložit prefix do předmětu a definovat podpis. Tyto hodnoty jsou automaticky přenášeny do všech typů notifikací.
Integrační vazby
1	Proxio XZR - vazba na základní registry
2	Ginis DDP - pohledávky
3	Proxio PRX - insolvenční rejstřík
4	IS Proxio Katastr - katastr nemovitostí
5	Microsoft Power BI - za účelem nadstavbových analytických činností.

2. Realizační část

Část Místní poplatky v dokončeném projektu bude rozšířená o další funkce dále popsané.

Uvedené požadované vlastnosti řešení pro rozšíření funkcí oblasti Místní poplatky jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na rozšíření funkčnosti Místní poplatky	Splněno
Migrace dat
1	Je požadováno převedení dat ze stávající agendové aplikace GINIS pro správu místních poplatků do aplikace vytvořené v předchozím projektu, jehož součástí bylo řešení pro místní poplatky.
2	Migrace bude probíhat naplněním předdefinovaných struktur dodavatele.
3	Chybějící data v původním systému budou ručně doplněna do mezi tabulek, které budou zahrnuty do migrovaných dat.
Dohledávání cizinců v AISEC
1	Řešení pro místní poplatky bude rozšířeno o integraci na registr cizinců AISEC.
2	Dohledávání bude probíhat automaticky v rámci aplikace místních poplatků.
Nové funkce pro městskou policii
1	Budou vytvořeny pohledy do aplikace místních poplatků pro potřeby strážníků městské policie.
2	Přehledy poskytnou základní údaje po oblast veřejného prostranství pro potřeby kontrolní činnosti městské policie.

4. Realizační část – Rozšíření funkcí podpory rozhodovacích procesů

   1. Současný stav:

Realizačních část Podpora rozhodovacích procesů je propojena s portálem elektronických služeb.

Jsou k dispozici usnesení (Rady, Zastupitelstva, výborů apod.). Součástí řešení je jak samotná agenda přípravy jednání a jeho správa, tak také finalizované dokumenty z jednání a zobrazení výsledků hlasování, vedoucích k rozhodnutí.

Vlastnosti řešení pro podporu rozhodovacích procesů jsou uvedeny v následující tabulce:

Funkční vlastnosti řešení
1	Aplikace umožňuje základní funkční rozdělení evidence do záložek Jednání, Porady, Podklady, Usnesení a Úkoly.
2	Veřejná část pro náhled na zveřejněná anonymizovaná data veřejnosti je přístupná bez nutnosti přihlášení s podporou fulltextového vyhledávání.
3	Aplikace je integrovaná s identitním systémem EOS. Řízení oprávnění a rolí uživatelů probíhá v EOS.
4	Aplikace umožňuje anonymizaci vybraných částí dokumentace.
5	Aplikace je navázaná do workflow s možností výběru konkrétního schvalovatele.
6	Aplikace umožňuje tvorbu a rozeslání tzv. distribučního balíčku, který umožní členům orgánů města studium podkladů offline.
7	Aplikace umožňuje tisk dokumentů Sbírka návrhů usnesení a Záznam z jednání na základě předdefinovaných šablon odděleně pro různé orgány města.
8	Aplikace umožňuje generování dokumentů Zápis z jednání a sbírka finálních usnesení na základě předdefinovaných šablon odděleně pro různé orgány města.
9	Aplikace je integrované do veřejné části usnesení na webových stránkách úřadu.
10	Základní funkce pro oprávnění přístupu: - referent - právo založit a zpracovat návrh usnesení; - organizátor - má právo založit a spravovat jednání; - administrátor jednání - provádí administraci jednání; . předkladatel - předkládá návrh na jednání; - podepisující - elektronicky podepisuje výstupní dokumenty; - aktivní editace - má právo editovat všechny návrhy za vybraný odbor ; - obecný náhled - má právo náhledu na všechny návrhy za vybraný odbor; - revize - má možnost číst a evidovat komentáře k návrhům; - správce úkolů - spravuje evidenci úkolů; - zodpovídá za úkol - zodpovídá za úkol; - auditor úkolů - má právo náhledu na všechny úkoly; - zařazení bodu - má právo zařadit bod na jednáním; - pozorovatel - má právo náhledu na celý obsah každého jednání vybraného orgánu; - tajné dokumenty - má právo náhledu na obsah utajených příloh.
11	Je možné elektronicky podepsat výstupní dokumenty: Pozvánka na jednání; Zápis z jednání; Finální usnesení; Sbírka finálních usnesení; a konfiguračně určit: - pro jaký orgán bude elektronické podepisování užíváno; - jaké dokumenty, z výčtu výše, budou elektronicky podepisovány - v kontextu orgánu; - zda bude mít elektronický podpis viditelnou podobu v tisku podepsaného dokumentu - v kontextu orgánu a vybraného dokumentu.
12	Je možné rozesílání e-mailové notifikace v případech: - pozvánka na jednání; - přidělení úkolu; - upozornění na blížící se termín úkolu; - upozornění elektronického schvalování (o vzniku požadavku, o schválení / zamítnutí); - upozornění elektronického podepisování (o vzniku požadavku, o podepsání).
13	Je možné generovat identifikátory v rozsahu: - pořadové číslo jednání; - číslo návrhu usnesení; - číslo usnesení - číslo úkolu.
14	Aplikace je propojena na elektronickou podpisovou knihu s možností opatřit elektronickým podpisem následující typy dokumentů: pozvánka na jednání; zápis z jednání; sbírka finálních usnesení; jednotlivá usnesení.
Integrační vazby
1		Integrace na LOTUS NOTES aplikaci Projekty umožňuje načíst identifikace a název projektu, částku, subjekt, číslo usnesení.
2		Integrace na POWER BI.
3		Integrace na Portál občana pro možnost zobrazení: časové osa rady a zastupitelstva jednání výborů vyhledávání výběr orgánu, předkladatele, data jednání, čísla usnesení

2. Realizační část

Část Podpora rozhodovacích procesů v dokončeném projektu bude rozšířená o další funkce dále popsané.

Uvedené požadované vlastnosti řešení pro rozšíření funkcí oblasti rozhodovacích procesů jsou uvedeny v následující tabulce a znamenají minimální míru plnění dle této ZD.

ID	Požadavky na rozšíření funkčnosti podpory rozhodovacích procesů	Splněno
Oblast připomínkování
1	Aplikace nově umožní, aby se ke každému návrhu mohli (nepovinně) vyjádřit všichni radní, nebo předem definovaný seznam osob. Vyjádření není povinné, ale aplikace umožní možnost vyjádření všech dotčených osob. Požadavek na vyjádření bude možné opakovat.
2	Aplikace umožní, aby v rámci připomínkování bylo možné doplnit do seznamu osob dávajících připomínky další uživatele.
3	Aplikace umožní e-mailovou notifikaci připomínkujících osob o požadavku k připomínkování.
4	Aplikace umožní e-mailovou notifikaci odesilateli, o vložených připomínkách.
Návrh usnesení
1	Aplikace umožní novou funkci změny navrhovaného materiálu z návrhu usnesení na informativní zprávu.
2	Aplikace umožní novou funkci změny navrhovaného materiálu z informativní zprávy na návrh usnesení.
Změna typu dokumentu
1	Aplikace umožní novou funkci změny navrhovaného materiálu z návrhu usnesení na informativní zprávu.
2	Aplikace umožní novou funkci změny navrhovaného materiálu z informativní zprávy na návrh usnesení.
Integrace
1	Aplikace bude rozšířena o integraci na IS Lotus Notes pro možnost zobrazení daných bodů na základě URL odkazu, který bude obsahovat identifikaci projektu z aplikace Lotus Notes.

5. Realizační část – Rozšíření funkcí robotizace správy přestupků

   1. Současný stav:

Realizačních část Robotizace správy přestupků je propojená do portálu elektronických služeb, koncentruje všechny přestupky a robotizuje proces výzev k úhradě pro všechny oblasti přestupků.

Vlastnosti řešení pro robotizaci správy přestupků jsou uvedeny v následující tabulce:

Funkční vlastnosti řešení
1	Provoz v kontejnerových technologiích a podpor vzdálené instalace. Webové intuitivní uživatelské rozhraní. Autentizace pomocí Active Directory. Podpora protokolu HTTPS pro aplikační server, API rozhraní a webového klienta.
2	Řešení umožňuje zobrazení dat v datových přehledech Microsoft Power BI.
3	Řešení poskytuje podporu procesů zpracování přestupků z hromadných detekčních prostředků a generování oznámení přestupku, např. v rámci procesů obecní policie: - ověření přestupků předaných z hromadných detekčních prostředků; - výběr přestupků pro generování oznámení přestupku; - hromadné generování oznámení přestupku; - hromadné předání oznámení přestupku do řešení výzev provozovateli vozidla nebo odeslání dokumentů oznámení přestupku do spisové služby.
4	Je funkční automatické a hromadné zpracování níže uvedených procesů: - ověření vlastníků a provozovatelů vozidel; - ověření údajů provozovatelů a vlastníků na základní registry; - přiřazení přestupků ke zpracování jednotlivým referentům s možností rozdělení dle MPZ RZ; - generování výzev provozovateli vozidla v požadovaných jazykových mutacích dle typu přestupku včetně generování předpisu výzvy; - vypravení výzev v kontextu typu (fyzická, právnická osoba) a státní příslušnosti provozovatele včetně vypravení hromadnou konverzní poštou; - načtení doručenek vypravení výzev, nastavení skutečného data splatnosti výzvy; - kontrola úhrady výzev v kontextu data splatnosti; - odložení po uhrazení výzvy; - předání do přestupkového řízení po neuhrazení výzvy; - generování přehledů vratek.
5	Je funkční možnost kontroly oznámeného přestupku referentem s podporou: - výběru fotografií pro výzvu; - ověření provozovatele vozidla na základní registry včetně úpravy údajů provozovatele; - pře ověření provozovatele vozidla na registr vozidel; - určení dalšího procesu zpracování oznámení" k odložení, k předání věci, k výzvě, k předání do přestupkového řízení.
6	Je zavedena evidence a zpracování obecných i dopravních přestupků včetně strukturovaných údajů například o dopravním přestupku a fotodokumentace.
7	Řešení obsahuje přehledný dashboard pro zpracovatele přestupků a vedoucí pracovníky: - přehledová statistika zpracovávaných přestupků; - přehled událostí vycházejících ze spisů pro jednotlivé referenty; - upozornění na procesní lhůty a stavy zpracování jednotlivých řízení s podporou minimálně: - vydání Rozhodnutí; - dokument Bez Podpisu; - dokument S Odmítnutým Podpisem; - dokument Bez Výsledku Doručení; - dokument Nedoručený; - dokument Podepsaný, Neodeslaný Do Sps; - dokumenty Bez Vyznačení Npm; - lhůta Pro Předání Odvolání Nso; - “Rozpracované” Dokumenty; - nevyžádán Opis Z Isep; - nezapsáno Do Isep; - nezapsáno Do Karty Řidiče; - souhlas Přímo Postižené Osoby; - skartace Spisu; - podmínečné Upuštění Od Trestu.
8	Aplikace obsahuje funkce generování dokumentů na základě předpřipravených šablon.
9	Aplikace obsahuje funkce podepsání dokumentu elektronickým podpisem přímo v aplikaci: - podpora podepsání přímo referentem; - odeslání dokumentu k podpisu jiným pracovníkem; - jednotné rozhraní pro požadavky na podpis, například vedoucí má zobrazenu "frontu(y)" požadavků na podpis od všech referentů všech typů dokumentů.
10	Aplikace obsahuje funkce podpory průvodce pro společné řízení: - dohledání spisů a přestupků dle legislativních pravidel pro společné řízení; - výběr přestupků pro společné řízení; - výběr cílového spisu pro společné řízení; - automatické vyloučení / sloučení přestupků včetně generování příslušných dokumentů o tomto a předání/převzetí spisů od jiných referentů v případě potřeby.
11	Aplikace obsahuje funkce podpory automatické před kvalifikace dopravního přestupku na přestupek provozovatele v případě marného uplynutí výzvy provozovatele vozidla.
12	Aplikace obsahuje funkce podpory evidence událostí ve spisu: - události vycházející ze lhůt a termínů jednání; - individuálně zadané události.
13	Aplikace obsahuje funkce referenčního nastavení legislativy: - využívané zákony a paragrafy; - definice skutkových podstat a porušených povinností ve vazbě; - definice sankcí; - definice parametrů skutkových podstat (např. recidiva, možnost využití výzvy provozovatele vozidla, nutný zápis do ISEP, nutný souhlas přímo postižené osoby).
Integrační vazby
1	Integrace na ekonomický systém GINIS - evidence odběratelů, generování jednoznačného identifikátoru odběratele, jejich zápis do ES - generování VS/SS a čísel dokladů předpisů pohledávek (faktur) - zápis předpisů pohledávek do VS - načtení úhrad předpisů pohledávek automatické vyhodnocení úhrad předpisů výzev a pohledávek.
2	Integrace na spisovou službu GINIS: - načtení doručených/postoupených dokumentů a spisů - založení a úprava dokumentu a spisu - vypravení dokumentu adresátům včetně podpory vypravení pomocí hromadné konverzní pošty a kontroly validity adresních údajů - načtení výsledku vypravení / doručení adresátům - vyřízení a uzavření dokumentů a spisů
3	Integrace na náběr požadavků z radarů MPK MARBES pro příjem záznamů z radarů
4	Integrace s hybridní poštu
5	Integrace na ISZR - Ověření údajů subjektů v registrech ROB a ROS - Možnost automatické notifikace a aktualizace změn údajů subjektů ověřených na registry ROB a ROS - Načtení údajů o svéprávnosti fyzické osoby - Načtení údajů o rodičích mladistvých a dětí mladších 15-ti let z agendového systému ISEO -načítání informací o datových schránkách (vlastnictví datové schránky)
6	Integrace na ISRV pro načtení informací o vozidle, vlastníka a provozovatele vozidla dle RZ
7	Integrace na ISEP - Opis z ISEP - Zápis do ISEP - Změna zápisu do ISEP
8	Integrace na registr řidičů – informace o spáchaných přestupcích a uložených zákazech řízení, o rozsahu řidičských oprávnění, zdravotní omezení.

2. Realizačních část

Část Robotizace správy přestupků v dokončeném projektu bude rozšířená o další funkce dále popsané.

Uvedené požadované vlastnosti řešení pro rozšíření funkcí robotizace správy 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 rozšíření funkcí robotizace správy přestupků	Splněno
Radar Rostoklaty
1	Do modulu agendy městské policie bude převedeno zpracování a oznámení přestupků z úsekového měření rychlosti radarem AŽD v obci Rostoklaty. Přestupky z tohoto radaru budou automaticky načítány.
2	Ze vstupního adresáře budou načítány nové přestupky. Adresář bude mít podadresáře strukturované dle data zpracování přestupků rok/měsíc/den/hodina a v nich jsou teprve vlastní data.
3	Přestupek bude identifikován PDF souborem.
4	Aplikace bude obsahovat údaje o zpracovaných přestupcích a datech jejich zpracování.
5	Zpracování PDF: z názvu PDF bude převzata identifikace přestupku, následně z DB v konfiguraci aplikace načte informace o přestupku dle identifikátoru, aplikace založí informace o přestupku, fotografie přestupku se vyextrahují z PDF.
6	Součástí aplikace bude nový konektor, který umožní zpracování přístupových údajů k DB na MS SQL odkud budou načítána detailní data k přestupkům.
Měření RAMET mimo obec
1	Aplikace bude obsahovat: číselník zařízení, v rámci číselníku zařízení bude možné konfigurovat s časovou platností, číselník stanovišť, v rámci číselníku stanovišť bude možné konfigurovat s časovou platností, rozšíření přestupku o vazbu na číselník zařízení a stanovišť.
2	Každý oznámený přestupek musí obsahovat i údaje z číselníku stanovišť a zařízení (certifikace, školení, veřejnoprávní smlouva, povolení PČR, zveřejnění místa): v oznámení budou přílohou dané dokumenty + DZ do vlastního textu oznámení, oznámení může být individuální nebo hromadné.
Přeskočení kontroly
1	V aplikaci pro městskou policii bude možné přeskočit kontrolu přestupků načtených z radarů RAMET a AŽD a rovnou přestupky přesunout do fronty pro generovat oznámení.
API MP manager
1	V řešení přestupků bude vytvořeno nové API rozhraní pro vstup oznámení o spáchání přestupku. Prostřednictvím tohoto API rozhraní bude možné do přestupků automaticky oznamovat zjištěné přestupky z jiných aplikací, v prostředí Českého Brodu Městská policie prostřednictvím aplikace MP Manager
2	Předávané oznámení bude obsahovat vlastní dokument oznámení, strukturované údaje o přestupku a podklady k přestupku (fotodokumentace, jiné dokumenty/soubory související s přestupkem).
3	V okamžiku, kdy oznamovatel, pomocí API rozhraní zapíše nové oznámení do řešení přestupků, bude dokument oznámení automaticky zapsán do spisové služby jako nový doručený dokument a přestupek bude zapsán do evidence včetně předaných dokumentů strukturovaných dat.
4	Přestupek bude automaticky přiřazen zpracovateli, referentovi přestupků, dle konfigurace aplikace (přímé určení jednoho zpracovatele, rovnoměrné rozdělení mezi existující zpracovatele).
5	Zpracovatel bude mít v řešení přestupků dostupné oznámení o přijatých nových oznámeních.
Ostatní správní řízení
1	Do aplikace Přestupky budou implementovány základní evidence/správní řízení: řízení o zadržení ŘP - agenda ŘP v rámci AA (opilý řidič), námitkové řízení (po dosažení 12 bodů), řízení o vrácení ŘO, řízení o upuštění od ZŘMV, řízení o zdravotní způsobilosti, řízení o přestupcích dle zákona č. 13/1997 Sb. (pozemní komunikace), výzva ohledně nalezení vraku, řízení o registraci autoškol.

6. Fáze A – Implementace řešení

1. Implementace řešení bude provedena v jednotlivých požadovaných krocích a termínech uvedených v kapitole 3.

2. Minimální požadavky na implementaci řešení 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 testovacího prostředí, včetně požadovaných vazeb
4	Školení uživatelů a administrátorů jednotlivých částí 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

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

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

1. analýzu výchozího stavu a bude vycházet z popisu současného stavu, viz Příloha 3.a. ZD;

2. 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;

3. 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.);

4. návrh technického řešení integračních vazeb; návrh řešení postupu a pořadí při nasazování jednotlivých částí řešení – 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;

5. popis případných organizačních opatření nutných pro implementaci;

6. rozsah součinnosti ze strany zadavatele;

7. 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.

8. 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;

2. 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.

3. 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í.

2. Dodávka licencí

1. 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í dodaného řešení ze strany uživatelů, a to jejich dále uvedeném počtu a skladbě.

2. Minimální požadavky na Licence SYSTÉMU jsou uvedeny v následující tabulce.

Id	Plnění požadavku	Splněno
1	Zadavatel nebude mít žádné omezení v počtu využívaných licencí (uživatelských přístupů) k jakékoliv části nabízeného řešení. Jedná se o časově neomezenou licenci opravňující k neomezenému počtu přístupů Zadavatele ke všem funkcionalitám dodaného řešení, provozovaného a spravovaného na zařízení Zadavatele.
2	Zadavatel požaduje poskytnutí veškerých nezbytných licencí k řádnému plnění předmětu, tj. k řádnému provozu díla na zařízení Zadavatele, zajišťující plnou funkcionalitu nabízeného řešení.
3	Dodavatel specifikuje název, počet, verzi a licenční podmínky ke všem nutným licencím v příloze smlouvy o dílo, a to včetně odůvodnění zvolené licenční nabídky, dále pak uvede licenční politiku, pravidla pro přidělení a případně změny v počtu licencí a verzí licencí.
4	Zadavatel požaduje dodání licence řešení pro produkční i testovací (školící) prostředí.
5	Zadavatel požaduje zajištění veškerých nutných licencí třetích stran, včetně licencí open source software a pod, potřebných pro provozování dodaného řešení.
6	Licence SYSTÉMU zahrnuje rozhraní pro konkrétní počet informačních systémů třetích stran (ISZR, ISDS, CzechPoint, apod.).

3. 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í.

3. Implementace Testovacího a Produkčního prostředí

1. Dodavatel vytvoří dvě prostředí:

Testovací prostředí

1. v rozsahu dle DCK,

2. které na infrastruktuře Zadavatele připraví Dodavatel,

3. 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í

1. v rozsahu dle DCK,

2. které na infrastruktuře Zadavatele připraví Dodavatel,

3. 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.

2. 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.

4. Produkční provoz s podporou

1. Implementace Produkčního provozu s podporou bude v rozsahu dle DCK.

2. Produkční provoz s podporou bude probíhat na produkčním prostředí.

3. 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.

4. 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.

5. 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).

6. 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.

5. Předání a převzetí plnění

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

1. 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í.

2. 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.

3. 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.

1. 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.

2. 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.

3. 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ý.

4. Dodaná dokumentace v rámci řešení slouží k zachycení a vyhodnocování plánovaných činností a též k dokumentaci skutečného stavu.

5. Minimální požadavky na dokumentaci řešení 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 řešení pro členy projektového týmu Zadavatele.
6	Kompletní analýza řešení problematiky řešení 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í, 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 řešení 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ů řešení.
10	Návrh monitoringu, zálohování a obnovy řešení s využitím stávajících technologií Zadavatele.
11	Detailní harmonogram realizace zakázky řešení vycházejícího z Milníků uvedených v ZD.
Realizační dokumentace řešení
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í řešení včetně detailního popisu všech rozhraní. Součástí dokumentace bude i detailní popis API rozhraní testovacího i produktivního prostředí řešení 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)

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

1. 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.

1. Detailní kritéria akceptace a vymezení plnění, která podléhají akceptaci Zadavatelem, jsou uvedena v tomto dokumentu, případně v Detailním cílovém konceptu.

2. 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.

2. 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.

1. 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é.

2. 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ů.

3. 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.

4. 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ů.

5. 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.

6. Žá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.

7. 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.

3. Migrace dat

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

4. Technologické prostředí

Instalace řešení 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 „Rozšíření techologie“. 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ů.

5. Školení

1. 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é řešení.

2. Dodavatel poskytne školení tak, aby pracovníci Zadavatele získali další znalosti praktického využívání řešení 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.

3. 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.

4. 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 cílového konceptu). 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 cílového konceptu).
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.

Zadavatel se pro tyto účely zavazuje zajistit:

• školící místnost s prezentační technikou,

• připojení na technologickou infrastrukturu.

6. 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 řešení podle pokynů Zadavatele novému poskytovateli.
4	Řádné předání všech dat zpracovávaných řešením, včetně dat doplňkových.
5	Poskytnutí veškeré relevantní Dokumentace a potřebných informací Zadavateli.

7. Fáze B – Servisní podpora řešení, SLA

1. Požadavky, které musí Dodavatel minimálně naplnit na Servisní podporu řešení 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í (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 částí řešení 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 řešení.
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 řešení.
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 5x8 (8 hodin v pracovní dny) v době od 08:00 do 16: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í.

2. V rámci zajištění podpory a servisu po dobu udržitelnosti projektu platí následující parametry SLA.

3. 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é řešení 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 řešení lze provozovat s omezením nebo po určitou dobu ve formě náhradního řešení.
C	Chyba	Nekritická chyba řešení – 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.

4. 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

5. Řešením se rozumí:

1. Odstranění chyby řešení. Opravy Chyb bude provádět Dodavatel do Aktualizované verze (kritické chyby ihned).

2. Poskytnutí přijatelného náhradního řešení problému ze strany Dodavatele.

3. Poskytnutí informace o akceptování/neakceptování námětu k zapracování do budoucích verzí.

6. 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č.

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

1. Specifikace předmětu plnění

1. 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 …“.

2. Technický popis řešení

   1. Grafické schéma a podrobný popis architektury řešení.

   2. Grafické schéma bude poskytovat ucelený přehled architektury řešení, zejména

- interní vazby jednotlivých částí – datový a logický model a

- externí vazby řešení na AIS Zadavatele.

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

2. Dále Dodavatel uvede detailní popis API rozhraní řešení pro napojení stávajících IS Zadavatele.

3. Počet a identifikace poddodavatelů.

4. Popis řešení „Jednotná správa řešení“ v rozsahu nejvýše 2 stránek formátu A4, dle podmínek uvedených v ZD.

5. Rozsah školení vč. uvedení počtu dní školení navrženého Dodavatelem

6. Xxxxx Xxxxxxxx řízení projektu a Harmonogramu projektu.

1 / 29