Contract

2. PŘEDMĚT DOHODY

2.1 Poskytovatel je povinen Objednateli poskytovat služby spočívající v:

1) Zavedení plánování a vykazování napříč celou organizací MP HMP,

2) Plošné zavedení MSD pro všechny strážníky,

3) Analýza MIS a plánem přechodu s cílem sjednotit technologickou platformu,

4) Rozvoj platformy správy technologií,

2.2 Objednatel je povinen za řádně poskytnuté Služby zaplatit Poskytovateli cenu uvedenou níže na základě čl. 5 Rámcové dohody, a to způsobem dle čl. 5 Rámcové dohody.

3. PROHLÁŠENÍ POSKYTOVATELE, ZÁVAZNOST RÁMCOVÉ DOHODY

3.1 Poskytovatel potvrzuje, že se v plném rozsahu seznámil s rozsahem a povahou Služeb, že jsou mu známy veškeré technické, kvalitativní a jiné podmínky a že disponuje takovými kapacitami a odbornými znalostmi, které jsou k plnění této dílčí smlouvy nezbytné. Poskytovatel výslovně potvrzuje, že prověřil veškeré podklady a pokyny Objednatele, které obdržel do dne uzavření dílčí smlouvy, a dále i pokyny, které byly obsaženy ve výzvě k podání nabídky, že je shledal vhodnými a dostačujícími, že sjednaná cena a způsob plnění Dohody včetně doby trvání této Dohody a termínů plnění obsahuje a zohledňuje všechny výše uvedené podmínky a okolnosti, jakož i ty, které zkušený poskytovatel jako subjekt odborně způsobilý měl nebo mohl předvídat. Poskytovatel na základě výše uvedeného prohlašuje, že s použitím všech výše uvedených znalostí, podkladů a pokynů bude plnit závazky založené touto smlouvou včas, řádně a za sjednanou cenu, aniž by vyžadoval od Objednatele jinou než v této či v rámcové dohodě uvedenou součinnost.

3.2 Právní vztahy mezi Smluvními stranami touto dílčí smlouvou neupravené se řídí Xxxxxxxx dohodou specifikovanou v záhlaví této smlouvy.

4. CENA A PLATEBÍ PODMÍNKY

4.1 Cena za řádnou realizaci této dílčí smlouvy byla sjednána ve výši

bez DPH: 15 988 750,- Kč

DPH: 3 357 637,50 Kč

včetně DPH: 19 346 387,50 Kč

4.2 Podrobná specifikace ceny je uvedena v Příloze č. 2 této Dohody. Cena dle této dílčí smlouvy zahrnuje veškeré náklady Poskytovatele na poskytování Služeb dle této Dohody. Cena je stanovena úplná, závazná, konečná, nejvýše přípustná. Poskytovatel prohlašuje, že cena plně pokrývá veškeré jeho náklady spojené s plněním této dílčí smlouvy.

4.3 Objednatel uhradí cenu v souladu s platebními podmínkami uvedenými v Rámcové dohodě.

5. ZÁVĚREČNÁ USTANOVENÍ

5.1 Poskytovatel výslovně souhlasí s tím, aby tato Smlouva byla vedena v Centrální evidenci smluv vedené Objednatelem, která je veřejně přístupná a která obsahuje údaje zejména o smluvních stranách, předmětu smlouvy, číselné označení této Smlouvy a datum jejího podpisu. Poskytovatel dále výslovně souhlasí s tím, aby tato Smlouva byla v plném rozsahu uveřejněna na webových stránkách určených Objednatelem. Poskytovatel dále výslovně souhlasí s tím, aby tato Smlouva byla Objednatelem uveřejněna v registru smluv dle zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv, ve znění pozdějších předpisů (zákon o registru smluv). Smluvní strany prohlašují, že skutečnosti uvedené v této Xxxxxxx nepovažují za obchodní tajemství ve smyslu § 504 občanského zákoníku a udělují svolení k jejich užití a uveřejnění bez stanovení jakýchkoliv dalších podmínek.

5.2 Tato Smlouva nabývá platnosti dnem jejího podpisu oběma smluvními stranami a účinnosti dnem jejího uveřejnění v registru smluv dle § 6 odst. 1 zákona o registru smluv.

5.2 Tuto dílčí smlouvu je možno ukončit za podmínek stanovených v Rámcové dohodě. Změna dílčí smlouvy je možná jen za podmínek a způsobem sjednaným v Rámcové dohodě.

5.3 Přílohu této dílčí smlouvy tvoří:

č. 1 - Podrobná specifikace předmětu plnění a harmonogram plnění č. 2 – Podrobná specifikace ceny

5.4 Tato dílčí smlouva byla vyhotovena elektronicky. Smluvní strany prohlašují, že si tuto smlouvu přečetly, že s jejím obsahem souhlasí a na důkaz toho k ní připojují svoje elektronické podpisy.

V Praze dne dle data el. podpisu V Ostravě dne dle data el. podpisu Objednatel: Poskytovatel:

Hl. m. Praha KVADOS, a.s.

Podpis: Podpis:

Xxxxxxxx Xxxxxx

Digitálně podepsal Xxxxxxxx Xxxxxx Datum: 2024.05.31

13:07:03 +02'00'

Xxx. Xxxx Xxxxxx Xxxxxxxx Xxxxxx

ředitel Odboru informatických činností MHMP Předseda správní rady

Příloha č. 1

Podrobná specifikace předmětu plnění a harmonogram plnění

Podrobná specifikace předmětu plnění je uvedena ve formě níže uvedeného katalogu požadavků, který obsahuje i harmonogram realizace předmětu plnění

Katalog požadavků rozvoje ISMP-POVS

Obsah

OBSAH 4

PŘÍLOHY 4

VYUŽITÉ ZDROJE 5

ZÁKLADNÍ POJMY A ZKRATKY 5

1 ÚVOD 7

1.1 OBLAST 1: ZAVEDENÍ PLÁNOVÁNÍ A VYKAZOVÁNÍ NAPŘÍČ CELOU ORGANIZACÍ MP HMP 7

1.2 Oblast 2: Plošné zavedení MSD pro všechny strážníky 7

1.3 Oblast 3: Analýza MIS a plánem přechodu s cílem sjednotit technologickou platformu 7

1.4 Oblast 4: Rozvoj platformy správy technologií 8

1.5 OSTATNÍ OBLASTI 8

2 VÝCHOZÍ STAV 8

3 KATALOG POŽADAVKŮ 9

3.1 Požadavky na subsystém OŘ 9

3.2 POŽADAVKY NA SUBSYSTÉM MSD 15

3.3 POŽADAVKY NA SUBSYSTÉM MIS 16

3.4 POŽADAVKY NA LUSTRAČNÍ MODUL (LM) 17

3.5 POŽADAVKY NA SUBSYSTÉM GIS 17

3.6 POŽADAVKY NA SPRÁVA TECHNOLOGIÍ (ST) 18

4 HARMONOGRAM 20

KONEC ZÁKLADNÍ ČÁSTI DOKUMENTU CHYBA! ZÁLOŽKA NENÍ DEFINOVÁNA.

Přílohy

Nejsou

Využité zdroje

[1] Dokumentace k ISMP-POVS

Základní pojmy a zkratky

V této kapitole jsou uvedeny základní pojmy a zkratky:

Pojem / Zkratka	Popis
API	Integrační rozhraní
CCTV	Kamerový systém
DB	Databáze
DC	Datové centrum
DS	Dílčí smlouva
DVČ	Denní výkaz činnosti
GIS	Geografický informační systém – jeden z modulů ISMP-POVS
GPS	Systém pro sledování vozidel
GUI	Uživatelské rozhraní
HMP	Hlavní město Praha
HW	Hardware – počítačové vybavení, infrastruktura
ICT	Informační a komunikační technologie
ID	Identifikátor
IPR	Institut plánování a rozvoje hl. m. Prahy
IS	Informační systém
ISMP-POVS	Informační systém Městské policie – podpora organizace a výkonu služby
KU	Katastrální území
LM	Lustrační modul
MHMP	Magistrát hl. m. Prahy
MIS	Manažerský informační systém – jeden z modulů ISMP-POVS
MKS	Městský kamerový systém
MP	Městská policie Hlavního města Prahy
MSD	Mobilní sběr dat
myFABER	Aplikace OŘ sloužící pro příjem tísňové linky 156 a operační řízení MP
OŘ	Operační řízení – jeden z modulů ISMP-POVS
OŘ/OR	V jiném kontextu Obvodní ředitelství MP
PCO	Pult centrální ochrany
PČR	Policie České republiky

Pojem / Zkratka	Popis
RDST	Radiostanice
RS	Rámcová smlouva
ST	Správa technologií
SVO	Sloupy veřejného osvětlení
SW	Software, aplikace, část informačního systému

Tabulka 1: Základní pojmy a zkratky

Úvod

Tento dokument je katalogem požadavků na další rozvoj systému ISMP-POVS pro dílčí smlouvu č. 1 v rámci služeb spojených s rozvojem Informačního systému a přípravou jeho realizace dle Xxxxxxx, čl. 2, odst. 2.1.4.

V rámci rozvoje ISMP-POVS v této dílčí smlouvě jsou následující čtyři klíčové oblasti rozvoje:

1. Oblast 1: Zavedení plánování a vykazování napříč celou organizací MP HMP

2. Oblast 2: Plošné zavedení MSD pro všechny strážníky

3. Oblast 3: Analýza MIS a plánem přechodu s cílem sjednotit technologickou platformu

4. Oblast 4: Rozvoj platformy správy technologií

Popis záměru rozvoje v těchto oblastech je v následujícím textu tohoto dokumentu.

Oblast 1: Zavedení plánování a vykazování napříč celou organizací MP HMP

Cílem této oblasti je zavedení plánovaní a vykazování pro všechny pracovníky MP HMP. Doposud je tato agenda realizována pouze pro strážníky v terénu. Vizí je realizace:

1. „paper less“ prostředí pro celý proces plánování a přenesení dat do mzdového informačního systému, kdy je proces prováděn digitální formou, tj. bez nutnosti tisků plánů/výkazů, s digitálním WF apod. Řešení je zároveň v souladu s platnou legislativou, manažerské rozhraní poskytující přehled nad stavem procesu plánů a procesu přenesení dat do mzdového informačního systému (včetně kontroly datové a informační integrity)

2. sjednocení procesu plánování, evidence docházky a přenosu dat do mzdového informačního systému

3. časová úspora v procesu zpracování výkazu práce a jejich schvalování (pro všechny zapojené zdroje)

4. snížení chybovosti přenosu dat z jednotlivých informačních systémů

5. naplnění informatické strategie digitalizace Součástí plnění je integrace na mzdový systém MP HMP.

Oblast 2: Plošné zavedení MSD pro všechny strážníky

V současné době jsou mobilní zařízení využívána zkušebně v rámci dvou obvodů. Rada HMP schválila vítěze veřejné zakázky na dodávku mobilních zařízení pro všechny strážníky. Celkem bude dodána

1.300 kusů odolných zařízení. Cílem této oblasti je plošné zavedení MSD. To bude realizováno postupně po jednotlivých obvodech s týdenním až dvoutýdenním odstupem. Součástí budou školení a zvýšená podporu provozu, aby byl zajištěn hladký průběh plošného zavádění. Nezbytnou součástí realizace je dále přizpůsobení MSD aplikace, která je aktuálně ve verzi Androidu 9. Nově dodaná zařízení jsou ve verzi Android 11.

Oblast 3: Analýza MIS a plánem přechodu s cílem sjednotit technologickou platformu Modul MIS se stal za 13 let provozu ISMP-POVS klíčovým systém pro vykazování. K dnešnímu dni v systému celkem 134 sestav, z toho 84 je systémových a 50 je uživatelských. MIS čerpá data

z ostatních modulů ISMP-POVS (OŘ, LM, MSD), ale i z dalších agend MP (KEVIS, CEP). Cílem tohoto sub

projektu je:

1. analýza více než 130 sestav a jejich optimalizace po více než 13 letém používání (řada sestav je částečně duplicitních a některé se již nevyužívají

2. definovat plán přechodu na jinou platformu. V současné době je využívána technologie Oracle. A jedná se o jedinou Oracle aplikaci v rámci MP HMP, což prodražuje provoz a správu základní infrastruktury. Dalším důvodem přechodu je nutnost provést technologický upgrade serverové části (stávající již není podporována výrobcem) a je tedy vhodné provést migraci do nového prostředí

Oblast 4: Rozvoj platformy správy technologií

Čtvrtou rozvojovou oblastí je přizpůsobení stávajícího modulu PST dle potřeb a požadavků uživatelů. Tento modul je využíván pro sledování polohy vozidel MP a PCO.

Ostatní oblasti

Součástí plnění jsou dále dílčích úpravy, které se nashromáždily za dobu, kdy nebyla platná rozvojová smlouva ISMP-POVS v oblastech GIS a LM. Součástí realizace je dále optimalizace integrací na technologii zaznamenávaní hovorů a rozesílání SMS.

Výchozí stav

Výchozí stav ISMP-POVS je dán stavem dodávek z již realizovaných dílčích smluv a platné dokumentace

k systému. Na základě tohoto není výchozí stav opakovaně popisován.

Katalog požadavků

V této kapitole jsou uvedeny požadavky na řešení dle jednotlivých oblastí.

Požadavky na subsystém OŘ

V následující tabulce jsou požadavky na tuto část ISMP-POVS:

#	Požadavek
P.1	Rozšíření přenosů do MSD ke složení hlídky o typ Motohlídka a Cyklohlídka.
P.2	Rozšíření přenosů z MSD u Událostí o Název hlídky pro záložky Osob/Vozidla a dále Rodné číslo u osob.
P.3	Plánování a vykazování práce v IS OŘ s předáváním do mzdového informačního systému: Základní principy: 1. „paper less“ prostředí pro celý proces plánování a přenesení dat do mzdového informačního systému, kdy je proces prováděn digitální formou, tj. bez nutnosti tisků plánů/výkazů, s digitálním WF apod. Řešení je zároveň v souladu s platnou legislativou, manažerské rozhraní poskytující přehled nad stavem procesu plánů a procesu přenesení dat do mzdového informačního systému (včetně kontroly datové a informační integrity) 2. sjednocení procesu plánování, evidence docházky a přenosu dat do mzdového informačního systému 3. časová úspora v procesu zpracování výkazu práce a jejich schvalování (pro všechny zapojené zdroje) 4. snížení chybovosti přenosu dat z jednotlivých informačních systémů 5. naplnění informatické strategie digitalizace Proces, který bude podpořen ze strany ISMP: 1. Naplánování směn/docházky v subsystému OŘ u všech pracovníků MP napříč celou organizací - provádí vedoucí pracovník nebo samotný zaměstnanec – možnost definovat role a oprávnění a stanovení případné zastupitelnosti pro tuto činnost. 2. Vygenerování el. výkazu práce na základě naplánované měsíční docházky - dochází k nahrazení tištěného formuláře – definovat cílový prostor, kde bude el. výkaz zobrazen pro náhled a schválení. 3. Schválení elektronického výkazu samotným zaměstnancem a následně jeho nadřízeným pracovníkem a. Úprava GUI systému a funkcionalitu pro schválení (tlačítko) b. Podpora procesu kontroly schválení zaměstnancem před schválením vedoucím pracovníkem (notifikace, barevné odlišení). c. Podpora interního procesu schválení u MP. d. Využití formy digitálního podpisu pro splnění legislativních požadavků. 4. Po schválení přenos požadovaných dat pro výpočet mzdy z elektronického výkazu do mzdového systému – definovat množinu dat z el. výkazu nutných pro výpočet mzdy, definovat charakter exportu do mzdového systému, definovat technické řešení propojení ISMP-POVS a DC2 pro export dat.

#

Požadavek

5. Archivace el. výkazů – definovat digitální prostor archivace (umístění, velikost, zabezpečení), definovat dobu potřebnou pro archivaci (dle legislativy a interních potřeb MP), definovat role a přístupy pro náhled do archivu, role pro editaci apod. Technické požadavky na řešení: 1. Plnohodnotně lze provozovat na koncových zařízeních typu: desktop, notebook 2. Auditní stopa 3. Umožňuje ověřování uživatelů vůči AD 4. Archivace 5. Integrace na systém docházky Obecné funkční požadavky na řešení: 1. Manažerské rozhraní – přehled stavu plánování směn, výkazů, docházky 2. Eskalační proces 3. Parametrizace řešení – např. pro eskalační lhůty atd. 4. Umožňuje kvalifikovaný / nekvalifikovaný elektronický podpis, „časové razítko“. 5. Je v souladu s platnou legislativou a směrnicemi Zadavatele. 6. Řešení poskytuje proces pro všechny možné varianty/stavy ve WF. Uživatelé: 1. Plánování – cca 40 nových uživatelů. V rámci útvarů MP HMP by se přístupy rozšířily pro vedoucí a zástupce vedoucích, kteří budou plánovat ostatním pracovníkům a schvalovat docházku. 2. Uživatelé s evidencí docházky a. Výkonné útvary – 1800 i. Přímý výkon (strážníci, operační) ii. Nepřímý výkon (Analytici, ředitelé, …) Na základě šablon se vygeneruje plán i pro pracovníky nepřímého výkonu. Ředitelé si to můžou udělat xxxx xxx. Přestupkové oddělení, ORK, THP, Sekretářka, … b. Nevýkonné útvary – 400 i. Všechno kromě OŘ 1 – 15 ii. Přidání pracovníků Korunní 98 a kontrolní orgány (veškerý nepřímý výkon MPP) Požadované řešení 1. Role uživatelů systému a. Plánovač měsíčního výkazu (Vedoucí nebo zástupce vedoucích) – pracovník, který má práva na plánování směn přidělených pracovníků. i. Potřebuje náhled na plán a realitu aby mohl řešit nesrovnalosti ii. Skutečnost dosah je pohotovost se nemusí rovnat plánu. Platí pro strážníky i pro office pracovníky. Dosah = Pohotovost iii. Skutečně odpracovaný čas v rámci pohotovosti eviduje plánovač. iv. Pracovníky a úvazky získáváme s IDM. Ověřit zda jsou tyto informace kompletní pro potřebné zpracování

b. Schvalovatel měsíčního výkazu (vedoucí nebo zástupce) – pracovník, který má práva na schválení měsíčního výkazu přidělených pracovníků. Je nutné řešit zastupitelnost této role.

i. Pracovník, který nemá přístup k systému. Za korektnost jeho měsíčního výkazu zodpovídá plánovač, který v průběhu měsíce provádí veškeré aktualizace. Tento výkaz schvalovatel pouze schválí a výkaz uvolní k odeslání do mzdového systému.

ii. Schválení k odeslání do DC bude možné provádět multioznačováním vybraných pracovníků. Můžu schválit a následně odeslat jednoho pracovníka, případně libovolně označený počet pracovníků.

iii. Fáze schvalování - musí být digitální stopa (časové razítko nebo el. Podpis)

iv. Pokud do mzdového systému odejde chybný měsíční výkaz, pak proběhne oprava až na straně mzdového systému. Nepředpokládáme, že bude hodně chybných výkazů a proto nebudeme řešit možnost opravy na straně myFABER. Na straně myFABER umožnit změnu opravit a dále neodesílat

v. Při odeslání mít možnost generovat report, který se dá odeslat v PDF

formátu

c. Schvalovatel měsíčního výkazu – Mobilní – v případě, že mobilní systém MSD bude podporovat uzavření měsíčního výkazu v rámci mobilní aplikace, pak může mít konkrétní uživatel MSD práva na uzavřené svého měsíčního výkazu.

d. Pracovník evidující příchody a odchody do práce – pracovník, který má práva na evidence příchodů a odchodů do práce v režimu pružné pracovní doby

2. Vstupní informace pro evidenci docházky

a. Pravidla schvalování – vstupní požadavky na pravidla schvalování

i. Zohlednění směnové volnosti. U směn se porovnávají hodiny na konci měsíce, Někdy může mít opracováno méně než je v pracovním fondu

ii. Možnost hromadně schválit pro všechny vybrané pracovníky

iii. Připravit report docházky k předání pracovníkovi.

iv. Odeslání do mzdového systému asi na samostatné tlačítko

v. Ověřit zda je potřeba upravit funkčnost myFABER kvůli funkčnosti docházkového systému.

vi. Pro pracovníky, kteří budou mít PDA a budou schvalovat výkaz práce. Je to historická alternativa. Je nutné ověřit, zda bude řešeno.

vii. Žádanky o dovolenou se budou zpracovávat mimo systém. Do systému myFABER se budou dovolenky zapisovat ručně na základě papírové žádanky.

viii. U schváleného měsíčního výkazu potřebujeme digitální stopu, že byl výkaz

potvrzen

b. xxXXXXX Xxxxxx – zaznamenání přístupů u pracovníků s pružnou pracovní dobou (dnes se zapisují do knihy) Kiosek myFABER

c. Řešení chyb – zpětné chyby zjištěné ve mzdovém systému se ručně vyřeší v mzdovém systému a následně je mzdová účtárna předá zpět a v myFABER se jen opraví a už se znovu neodesílá

d. Mimo rozsah řešení – elektronické zadávání nepřítomností není požadováno. Zákazník to nechce dělat větší než je nutné nad rámec vykazování.

e. Export výkazu práce

i. Předání podkladů do mzdového systému bude probíhat:

1. nejdříve první den v následujícím měsíci

2. nejpozději 2 den v následujícím měsíci

ii. Výkaz práce se bude zasílat v podrobnosti zaměstnanec a měsíc

f. Číselník typů výkazu činností – viz samostatná tabulka v této kapitola.

Integrace na systém docházky (DC)

1. Technologické řešení – výměna dat mezi oběma systému bude probíhat přes transferovou DB, která bude uložena v DB MS SQL na DB serveru, který je využíván pro uložení dat systému myFABER. KVADOS zajistí nastavení přístupů, pro systémového uživatele DC, pod kterým se budou události zpracovávat (případně můžeme využít doménový účet). Struktura transferové DB je pro každou přenášenou událost definovaná v následujících kapitolách.

a. Přístup do DB myFABER pro DC2 bude pod doménovým uživatel

b. Nastavení prostupů by neměl být problém vše je v jedné síti

c. Pracovní režim (Plán směn)

d. Docházka

e. Schválené absence budeme předávat v rámci plánu směn a následně reality

f. Potvrzování přenosu událostí

2. Číselníky

a. Pracovníci budou identifikovaná jednotně dle systému IDM

b. Převodník druhu události na mzdové složky systému DC

c. DC2 poskytne view, která budou obsahovat informace o období budeme exportovat

3. myFABER do DC - Pracovní režim – transferová DB bude obsahovat tabulku DC_PRAC_REZIM, kde budou přenášeny všechny potřebné informace pro zpracování pracovního režimu v DC. Struktura tabulky bude řádková. To znamená, že pro každý pracovní den bude v tabulce minimálně jeden záznam.

a. Pracovní režim je na straně MPP pro všechny pracovníky a následující měsíc naplánovaný nejpozději do 15 dne v aktuálním měsíci.

b. Pracovní režimy není nutné exportovat pravidelně a proto možné export spustit uživatelem. Export pracovního plánu není nutné spouštět pravidelně (Vstupně předpokládáme s exportem pracovního plánu v denní frekvenci).

c. V ideálním případě by se do DC měl odesílat pracovní režim pracovníků za celý aktuální rok. Toto ale není možné na straně MPP zajistit a u jednotlivých rolí bude zpracování pracovního režimu probíhat následovně: U okrskářů MPP plánuje pouze měsíc dopředu. V tomto případě budeme do DC2 odesílat pracovní režim pouze jeden měsíc dopředu.

d. Pracovní režim musí obsahovat informaci o svátku - jestli patří, či nepatří do fondu

(v terminologii DC)

e. Nástup do pracovního poměru v průběhu měsíce i Ukončení pracovního poměru v průběhu měsíce. Na straně myFABER se zbývající část měsíce odplánuje (DC2 potřebuje vědět, jaké směny byly odplánovány. myFABER nebude poskytovat informace o směnách, které na počátku nebo konci pracovního poměru nebyly odpracovány, pak DC2 na straně vypočítá, kolik dní nebude odpracováno)

4. Řádkové načtení reprezentuje

a. Identifikace osoby (identifikační číslo z IDM)

b. Den docházky (YYYYMMDD)

c. Den (Pracovní, So,Ne, Noční)

d. Druh události (Práce, Dovolená, Nemocenská, …). Číselníková hodnota, která bude odesílána ve formátu evidovaném v DC.

e. Počet hodin (hodnota dne) Upřesnit formát v jakém se bude počet hodin exportovat

5. Docházka (Absence + Příplatky)

a. Absence a příplatky navrhujeme odesílat odděleně od pracovního režimu. Transferová DB bude obsahovat tabulku DC_DOCHAZKA, kde budou přenášeny všechny potřebné informace pro zpracování docházky v DC.

#	Požadavek
	b. využije se identifikace druhu události. Pak předpokládám, že bude ve výměníkové databázi existovat tabulka, která bude transformovat druh události na naše mzdové složky. c. Nevýhodou tohoto řešení je to, že musí ze strany DC2 dojít k sumaci těchto druhů událostí, bude-li to chtěné. (aby například přesčas šel do výpočtu mezd jednou složkou sumárně, nikoliv mnoha složkami k jednotlivým dnům) i. Po uzavření měsíce budou data vyexportována do přenosové tabulky DC_DOCHAZKA. Provedení reexportu nebude možné. Proces přeschvalování nebude implementován. ii. Na straně myFABER bude možné změnu provést i po provedení exportu ale tato úprava už nebude odeslána do systému DC. Zpětné úpravy budou uživatelé řešit ručně na straně DC. iii. Docházka - Za stranu DC není žádná změna do historie možná. Zpětné změny musí řešit ručně účetní, která se o zapracování v rámci DC postará. iv. KVADOS dodá všechny typy pracovního plánu (Přesčas25, Přesčas50, Nemoc,…) a DC2 nám doplní mzdové složky. Toto budeme muset na straně myFABER vyřešit. Po uzávěrce bude muset být zřejmé mzdové složky. Příplatky při směně na přelomu měsíce. v. Soboty a neděle se počítají na 2 způsoby. Ze soboty na neděli mají jako sobotu a z neděle na pondělí jako neděli. 6. Potvrzování předávaných událostí – transferová DB bude obsahovat tabulku DC_PREDANO s atributy, které budou plněny ze strany DC po zpracování docházky na straně systému DC. a. Identifikace osoby b. Období c. Datum uzavření d. Stav (K importu do DC. Naimportováno do DC, Vráceno k opravě v myFABER) 7. Zpracování dat docházky v systému DC2 – v systému DC2 bude mít oprávněný uživatel dvě tlačítka (další úlohy - speciální úlohy) a. Zpracování pracovních režimů (osobám, které nejsou obsahem view/tabulky ve výměníkové tabulky bude nastaven výchozí kalendář v DC2) b. Nahrání absencí do aktuálního období c. O zpracování bude existovat textový log s opisem událostí a mezních stavů. Spuštění těchto úloh bude řízeno oprávněním (ne každý může mít právo na spuštění) Nebude dovoleno spuštění v případě uzávěrky průběžné, v případě náhledu. 8. Dodávka všech nezbytných licencí.
P.4	V roce 2023 proběhl upgrade ReDat a navazujícího ReDat Experience. V rámci tohoto upgrade byla provedena i modernizace integračního rozhraní pro přenos fonogramů do IS OŘ, tj. předmětem požadavku jsou nezbytné úpravy na straně IS OŘ, aby byly reflektovány všechny požadované změny v přenosu dat z ReDat do IS OŘ. Modernizace a rozšíření importu fonogramů z REDAT: 1. Příjem signalizace z REDAT o hovorech - zahájení, změny účastníků, ukončení hovoru. 2. Vytěžování datové věty a uložení dat do IS OŘ 3. Identifikace účastníků a určení, případně změny útvaru, ke kterému hovor přísluší. 4. Návaznost na proces založení fonogramů, přiřazení organizačnímu útvaru a založení události nebo přidání ke stávající události. Přístup k integračnímu rozhraní ReDat bude zajištěn v rámci součinnosti.
P.5	Úprava importu fonogramů:

#	Požadavek
	1. Nově bude u příchozího fonogramu doplněn krok, ve kterém se vyhledá radiostanice podle hodnoty klapky daného fonogramu. Hledá se hodnota v atributu Id v seznamu konfiguračních položek typu RDST. V případě dohledání organizační jednotky přes hodnotu klapky systém MF najde jinou radiostanici než podle hodnoty RadiostationID. 2. Při ukončení hovoru nastavení ID radiostanice, které je při ukončení fonogramu již vyplněno. V tomto případě systém doplní do fonogramu nejdříve ID radiostanice a následně doplní doplňkové informace: a. Volací znak (Callsign) b. ID radiostanice c. Název hlídky x. Xxxxx fonogramu Navazuje na předchozí požadavek s náhradou importu fonogramů, který je nutnou podmínkou pro realizaci tohoto požadavku.
P.6	Úprava funkčnosti k zavedení typologie činností pracovního plánu: 1. Zavedení směny 11,5 hod + 1 hod přestávka 2. K typu činnosti pracovního plánu přidat za kolonku Výchozí trvání ještě položku Délka pauzy 3. Chování by bylo takové, že pokud by byla tato hodnota vyplněna, tak by měla přednost před automatickými pauzami a zobrazovala by se v Měsíčním plánu tak, jako by se ručně přidala délka pauzy (aby bylo možné generovat plány). Pokud by hodnota nebyla vyplněna, plán by se choval standardně s automatickými přestávkami. 4. Při editaci délky typu plánu v Měsíčním plánu by se musela pak ručně upravovat i délka pauzy v typu plánu v Měsíčním plánu, či ji zrušit a přepnout tak na automaticky nastavené pauzy
P.7	Příjem a odesílání SMS přes telefonní ústřednu, včetně ukládání přijatých SMS a příjmu doručenek a aktualizace stavu SMS v IS OŘ dle doručenek. Současně budou SMS zpřístupněny pro vyhodnocení v MIS. Jedná se o modernizaci rozhraní z důvodu postupné modernizace komunikačního prostředí MP HMP.

Tabulka 2: Požadavky na subsystém OŘ

Číselník typů výkazu činností

Aktuálně se v rámci vykazování zpracovávají primárně následující činnosti:

Kód	Název	Způsob zpracování
	Odpracované hodiny celkem	Počet hodin odpracovaný v konkrétní den. V případě směny přesahující 2 dny je nutné vypočítat počet hodin, které patří do konkrétních dní a hodiny mezi dny rozdělit.
111	Přesčas k proplacení 25 %	Počet přesčasových hodin odpracovaných v pracovním dni nad rámec standardní pracovní doby. Uvádí se příslušná část z odpracovaných hodin celkem.

112	Přesčas k proplacení 50 %	Počet přesčasových hodin odpracovaných v pracovním dni nad rámec standardní pracovní doby. Uvádí se příslušná část z odpracovaných hodin celkem.
270	Svátek k proplacení	Počet hodin odpracovaných ve svátek. Uvádí se příslušná část z odpracovaných hodin celkem.
	Přesčas svátek k neproplacení
	Přesčas do 150 hodin neplacený
	Směnové volno
479	Noční práce	Počet hodin odpracovaných v noci. Uvádí se příslušná část z odpracovaných hodin celkem.
495	Sobota, Neděle	Počet hodin odpracovaných v sobotu, neděli. Uvádí se příslušná část z odpracovaných hodin celkem.
501	Dovolená
511	Studijní volno
513, 514	Pracovní volno s náhradou platu
521	Nemoc
522	Ošetřování člena rodiny
532	Pracovní volno bez náhrady platu
533	Absence neomluvená
478	Pohotovost mimo pracovní dobu 15 %
477	Pohotovost mimo pracovní dobu 25 %
	Odvolání z pohotovosti k výkonu práce

Tabulka 3: Číselník typů výkazu činností

Požadavky na subsystém MSD

V následující tabulce jsou požadavky na tuto část ISMP-POVS:

#	Požadavek
P.8	Propojení parcely s katastrem v mapě V současné chvíli jsou zobrazovány pouze statické offline informace o parcelách - jejich číslu, typu využití. Je vhodné rozšířit modul Mapa u vrstvy zobrazující parcely o možnost stažení vlastnického listu v podobě souboru typu PDF prostřednictvím DP ČUZK. Služby DP ČUZK budou proxyovány prostřednictvím serverové části ISMP MSD.
P.9	Dokumenty pro plnění služby Dokumenty ukládat do sdíleného úložiště, kde bude vždy aktuální veze dokumentů s možností aktualizace dokumentů bez nutnosti vytvářet verzi aplikace MSD. Při zahájení směny bude provedena kontrola verzí mezi sdíleným úložištěm a dokumenty v mobilním zařízení, v případě neshody verzí aktualizace ze sdíleného úložiště.
P.10	Aplikace PDF/A

#	Požadavek
	Z důvodu problémů s otevíráním souborů typu PDF/A v rámci lustrací v ISEP je žádoucí implementovat v rámci aplikace MSD vlastní aplikaci schopnou bezproblémově otevírat soubory typu pdf včetně archivních, tzn. PDF/A.
P.11	Mapové podklady do MSD Možnost instalace a aktualizace mapových podkladů ze serveru MP – aktuálně nelze instalovat a aktualizovat mapové podklady z GIS, instaluje se přes Google. Cílem je umožnit jejich jednodušší instalaci/aktualizaci bez nutnosti aktualizace celé aplikace společně s mapami.
P.12	Napojení na centrální (republikovou) DB TAXI
P.13	Služby související s podporou zavedení MSD do provozu v rámci celé MP. Zavádění bude realizováno postupně po jednotlivých obvodech vždy s odstupem jednoho až dvou týdnů. Součástí budou služby školení pro vybrané uživatele na každém obvodu. A zvýšený dohled po dobu zavádění po dobu 2 týdnů. Aktuálně je MSD využíváno v rámci dvou obvodů. Celkový počet obvodů je 15.
P.14	Zobrazování dodatkových tabulek u dopravního značení v MSD.
P.15	Služby upgrade MSD v souvislosti s paralelním využíváním verze operačního systému Android 9 a 11. Nově dodávaná zařízení jsou vybavena operačním systém Android v. 11. 1. Upgrade back-end mobilní aplikace v souvislosti s přechodem na verzi operačního systému Android 11 včetně souvisejících služeb testování. 2. 2. Upgrade front-end mobilní aplikace v souvislosti s přechodem na verzi Android č. 11, včetně souvisejících služeb testování.
P.16	Úprava synchronizace účtů mezi IS OŘ a MSD v návaznosti na změny úvazků a zařazení strážníků (vyřešení problému s duplicitními účty v případě více různých úvazků strážníků).
P.17	Nastavení MPZ zpět na CZ: při opakovaných parkovačkách po dokončení zadání do mobilního zařízení nastavit MPZ zpět na CZ. Naprostá většina vozidel má MPZ CZ.
P.18	Nové vrstvy v GIS v MSD: Hranice - Prahy, Městských obvodů, Městských částí, Obvodních ředitelství MP, Okrsků MP, Správních obvodů, Služebny MP a PČR - KŘ, Obvody, Okrsky, Služebny". Mapy budou nahrávány do MSD offline, tj. zajištění kompletního mechanismu přípravy balíčku mapových podkladů pro MSD z GIS ISMP.

Tabulka 4: Požadavky na subsystém MSD

Požadavky na subsystém MIS

V následující tabulce jsou požadavky na tuto část ISMP-POVS:

#	Požadavek
P.19	Analýza stavu MIS a návrhem optimalizace sestav MIS: Analýza všech sestav z hlediska jejich využívání a možností optimalizace – jedn se o 84 systémových sestav a cca 50 uživatelských pro subsystémy IS OŘ, KEVIS, LM, MIS, MSD a napříč ISMP-POVS – výstupem bude seznam sestav pro převedení do nového MIS.
P.20	Návrh řešení nového MIS: 1. Návrh řešení sestav, které mají bych zachovány v novém MIS. 2. Požadavky na funkčnost nového MIS

#	Požadavek
	3. Požadavky na způsob sběru dat do nového MIS ze stávajících IS. 4. Požadavky na úpravy jiných subsystémů v návaznosti na změnu MIS. 5. Zpracování harmonogramu přechodu na nový MIS včetně souběžného provozu stávajícího i nového MIS. Výstupem bude dokument s požadavky na rozvoj do nové DS. Pozn.: vlastní migrace na novou technologii by proběhla v dalších DS.

Tabulka 5: Požadavky na subsystém MIS

Požadavky na Lustrační modul (LM)

V následující tabulce jsou požadavky na tuto část ISMP-POVS:

#	Požadavek
P.21	Napojení na centrální (republikovou) DB TAXI.
P.22	Úpravy lustračního modulu v rozsahu: 1. Implementace systémových skriptů pro přenos a správu konfigurace prostředí TEST / PARALELL / PRODUKCE. Jedná se o skripty, které umožňují přenos konfiguračních informací a dat: Agendy, Zákonné důvody, Agendové role, Katalogy, Parametry dotazů do registrů a Parametry odpovědí z registrů 2. Implementace nástroje pro dohledání lustračního logu a systémových volání rejstříků. Nástroj slouží pro dohledání lustračního logu a souvisejících systémových volání rejstříků v případě vyžádání informace o lustraci ze strany odpovědných pracovníků MP. V lustračním modulu jsou historicky implementovány moduly Kontrola a Inspekce, které umožňují oprávněným uživatelům dohledat základní informace o lustraci. V některých případech je však nutné dohledat podrobnosti o systémových voláních rejstříků, což stávající moduly neumožňují.
P.23	Služby konfigurace a testování rejstříku trestů v souvislosti se změnou termínu uvedení nového RT do provozu na úrovni LM a MSD.

Tabulka 6: Požadavky na lustrační modul (LM)

Požadavky na subsystém GIS

V následující tabulce jsou požadavky na tuto část ISMP-POVS:

#	Požadavek
P.24	Úpravy back-end GIS související se změnou v administraci objektů PCO v subsystému PST. Úprava zajistí správné načítání objektů a jejich grup včetně související kontaktech informací. GIS nebude zobrazovat již ostíněné anebo neplatné grupy objektů a případné kontaktní údaje k nim.
P.25	Úprava zobrazování vrstev pro přestupkové oddělení. Změna vykreslování vrstev pro zobrazování na ortofoto mapě. Nastavení bílého podbarvení u vrstev ulic, parcel a sloupů veřejného osvětlení.
P.26	Příprava mapových podkladů pro MSD – pro realizaci požadavku P.18 v rámci rozvoje MSD.

Tabulka 7: Požadavky na subsystém GIS

Požadavky na Správa technologií (ST)

V následující tabulce jsou požadavky na tuto část ISMP-POVS:

#

Požadavek

P.27

Lokalizace v mapové komponentě V mapě bude implementována funkcionalita pro lokalizaci objektů. V panelu akčních tlačítek bude funkční tlačítko (ikona) s názvem "Lokalizace", která zobrazí panel „lokalizace“ v sidebaru. Panel lokalizace umožní vyhledání a lokalizaci výsledků v mapě zadáním: 1. městské části 2. ulice 3. čísla popisného/orientačního 4. parcelního čísla 5. souřadnic x;y (SJTSK, WGS 84) 6. volacího znaku GPS hlídky 7. čísla sloupu SVO 8. železničního přejezdu 9. nebo aktivací tlačítka pro zadání bodu přímo v mapě kliknutím V panelu lokalizace bude pro efektivní vyhledání u následujících vstupních políček implementován autocomplete (našeptávač): 1. městská část (dle názvu) 2. ulice (dle názvu) (alespoň 2 znaky) 3. číslo orientační / číslo popisné (bez ohledu na pořadí) 4. parcela (dle čísla) (alespoň 2 čísla) 5. GPS modul hlídky MP (dle volacího znaku) 6. přejezd (dle P a čísla) 7. sloup veřejného osvětlení (SVO) (dle čísla) (alespoň 2 čísla) Našeptávač bude po zadání požadovaného počtu znaků zobrazovat nalezené shody, které bude zobrazovat pod vstupním políčkem a bude umožňovat jejich výběr kliknutím myší. Při úspěšné lokalizaci zadávané položky mapa zazoomuje na tuto položku, zobrazí ikonou její bodovou lokalizaci a v případě ulic zobrazí i osu ulice. Současně aplikace dokončí lokalizaci, tj. dohledá a do vstupních polí doplní: 1. maximálně 3 ulice v okruhu 100 m od hledaného objektu 2. maximálně 5 nejbližších adresních bodů v okruhu 100 m od hledaného objektu 3. příslušnou parcelu 4. maximálně 5 SVO v okruhu 100 m od hledaného objektu 5. nejbližší přejezd 6. maximálně 3 nejbližší GPS zařízení v okruhu 5 km od hledaného objektu. 7. obvod MP, okrsek MP, obvod PČR, okrsek PČR, katastrální území, číslo parcely a doplní je do needitovatelných polí 8. souřadnice hledaného objektu ve formátu WGS84 a S-JTSK (tzv. Křovákovo zobrazení). 9. maximálně 5 nejbližší kamery v okruhu 1500 m od hledaného objektu

#	Požadavek
	A současně zobrazí všechny nalezené údaje na mapě (ulice, adresní bod, sloup, přejezd, parcela, bod zadaný kliknutím, kamery, GPS hlídky). U políčka pro zadání GPS hlídky: 1. bude funkční tlačítko s názvem "zapnuti/vypnutí funkce zoomování na nejbližší hlídku“, 2. a tím, že pokud toto tlačítko je zapnuté, aplikace po úspěšné lokalizaci nakreslí spojnice rovnou čarou mezi nalezeným objektem a nejbližšími GPS hlídkami, jejichž ikony barevně zvýrazní (případně kolem nich nakreslí červený kroužek). Při kliknutí na nalezenou GPS hlídku aplikace zazoomuje a zobrazí popup GPS zařízení. Nalezené kamery budou zobrazeny jako čárkou oddělený seznam čísel kamer, při kliknutí na danou položku mapa zazoomuje a zobrazí popup kamery se snímkem z kamery. Pro vymazání formuláře bude k dispozici v jeho spodní části tlačítko "Vymazat" a pro vynucení hledání tlačítko "Hledej", které znovu provede lokalizaci. U položky "parcela" budou 2 tlačítka, která budou aktivní v kontextu vyhledané parcely: 1. zobrazení / stažení listu vlastnictví v PDF v samostatném okně prohlížeče (pomocí služby na straně serveru) 2. zobrazení Nahlížení do KN v samostatném okně (pomocí hypertextového odkazu na ČÚZaK)
P.28	Integrace dalších vrstev do mapové komponenty ST Do mapové komponenty pro Správu technologií doplnit skupiny a vrstvy. 1. pro relevantní vrstvy doplnit modální (popup) okna s informacemi dle zdroje dat 2. vrstvy zobrazovat v uvedeném rozsahu měřítek Název vrstvy - typ - zdroj - měřítko zobrazení Kamery – viditelnost polygon MKS od 20000 Parcely polygon IPR od 2000 Zájmové objekty POI bod-ikona CEDA CD od 5000 Poznámky ve vrstvě kamer: 1. Databáze kamer bude rozšířena o polygony viditelnosti a v legendě budou tyto polygony zobrazovány přímo u vrstvy kamer. 2. Při kliknutí na ikonku kamery bude zobrazen rovněž její polygon viditelnosti.
P.29	Pamatování stavu legendy – zapnutí a vypnutí vrstev legendy V mapové komponentě umožnit, aby pro přihlášeného uživatele se ukládal stav legendy – stiskem tlačítka "Uložit stav legendy", které bude v horním rohu panelu Xxxxxx (tam, kde je dnes tlačítko "Hledej"). Stavem legendy je myšlen stav stromečku v panelu Vrstvy (tj. stav jeho jednotlivých uzlů a checkboxů – zapnutí/vypnutí vrstev. Tlačítko uložení zajistí uložení stavu legendy: 1. zapnutých a vypnutých vrstev 2. zapnutých a vypnutých skupin vrstev 3. stav rozbalení skupin Tato funkce se netýká vrstev GPS, PCO a CCTV s dynamickými daty ve stromečku.

#	Požadavek
P.30	Možnost zobrazení panorama (xxxx.xx) 1. vytvořit funkční tlačítko v mapě (v panelu kde je dnes např. Prostorový dotaz) pro možnost zobrazení panorama view z xxxx.xx 2. při kliknutí na tlačítko se zobrazí view v novém okně – zobrazení z xxxx.xx panorama
P.31	Funkce pro získání výpisu z dálkového dohledu a PDF LV z ISKN CUZK V mapové komponentě ST bude implementována nová funkcionalita, která zajistí: 1. zobrazení informací o parcele z ISKN v novém okně aplikace 2. stažení souboru PDF z neveřejné části ISKN pro vybranou parcelu Implementace této nové funkcionality je požadována: 1. v mapě – nové funkční tlačítko (ikona) umístěné v pravém horním rohu mapy (vedle prostorového hledání), které umožní klinutí do mapy na zvolené místo a následné zobrazení výsledku v novém okně 2. v panelu výsledků lokalizace u čísla parcely
P.32	Vizualizace stavu PCO pro zařízení (smyčky) na stejné adrese (= souřadnici). Do popupu pro PCO smyčku bude připsána informace o stavu všech smyček na stejné souřadnici, aby nebylo nutné při zjišťování stavu PCO objektu složitě procházet všechny překrývající se ikony na stejné souřadnici.
P.33	Zobrazení historie více GPS na mapě současně. Umožnit zobrazení historie pohybu více (3) stanic nejednou. Historii pohybu stanic zobrazovat v mapě současně.

Tabulka 8: Požadavky na Správu technologií (ST)

Harmonogram

V následující tabulce je uveden požadovaný harmonogram dodávky (termín je od začátku realizace, jednotkou je kalendářní den):

▪ #	▪ Fáze	▪ Termín
▪ 1	▪ Zahájení realizace je dni účinnosti dílčí smlouvy	▪ 0
▪ 2	▪ Zpracování analýzy a návrhu řešení realizace požadavků	▪ 90
▪ M1	▪ Milník: úhrada 20% ceny za zpracování implementační analýzy	▪ 90
▪ 3	▪ Vývoj úprav ISMP a implementace na testovací prostředí	▪ 210
▪ M2	▪ Milník: úhrada 55% ceny za dokončení vývoje	▪ 210
▪ 4	▪ Ověření funkčnosti na testovacím prostředí, odstraňování vad a nedodělků	▪ 300
▪ 5	▪ Aktualizace dokumentace systému	▪ 300
▪ 6	▪ Zpracování analýzy a návrhu řešení MIS	▪ 300

▪ M3	▪ Milník: úhrada 15% ceny za dokončení realizace požadavků a jejich ověření, návrh řešení MIS	▪ 300
▪ 7	▪ Implementace na produkční prostředí	▪ 300
▪ 8	▪ Pilotní provoz	▪ 330
▪ 9	▪ Předání aktualizovaných zdrojových kódů do úschovy	▪ 330
▪ 10	▪ Podpora rozšíření MSD na další OŘ a útvary MP (průběžně od zahájení realizace).	▪ 330
▪ M4	▪ Milník: dokončení realizace dílčí smlouvy a úhrada zbývající ceny	▪ 330

Tabulka 9: Harmonogram

Realizace požadavků bude probíhat následovně:

1. Organizace projektu:

a. Sestavení projektového týmu za dodavatele, objednatele (MHMP) a uživatele (MP HMP) a stanovení odpovědných osob za jednotlivé oblasti a subsystémy v rámci realizace dodávky.

b. Stanovení složení Hlavního projektového týmu (HTP) a Řídícího výboru (ŘV).

c. Upřesnění a rozpracování detailního harmonogramu realizace požadavků z této výzvy.

d. Nastavení pravidelných jednání HTP (cyklus 2 týdny) ŘV (významné milníky realizace).

e. Zpracování dokumentu „Stanovení podmínek realizace“ (SPR) obsahujícího vše zde uvedené a další náležitosti projektového řízení (řízení rizik, řízení změn, akceptační proces apod.).

f. Organizace úvodního jednání HTP/ŘV k zahájení realizace. Projednání a odsouhlasení SPR.

2. Zpracování analýzy a návrhu řešení

a. Upřesnění podmínek relevantních pro realizaci požadavků.

b. Projednání a upřesnění způsobu realizace požadavků.

c. Zpracování výstupního dokumentu „Analýza a návrh řešení“.

d. Připomínkové a schvalovací řízení k předanému dokumentu 🡪 akceptace.

3. Realizace vývoje a implementace požadavků dle zadání a upřesnění schválených v analýze a návrhu řešení:

a. Vývoj úprav ISMP-POVS dle požadavků v každé oblasti dle harmonogramu.

b. Implementace na testovací prostředí.

c. Ověření funkčnosti na testovacím prostředí, odstraňování vad a nedodělků.

d. Akceptace úprav na testovacím prostředí.

4. Proškolení klíčových uživatelů v návaznosti na změny ISMP-POVS.

5. Aktualizace a předání dokumentace systému v návaznosti na změny ISMP-POVS.

6. Implementace na produkční prostředí

a. Naplánování odstávky a sestavení postupu implementace na produkční prostředí.

b. Provedení implementace změn ISMP-POVS na produkční prostředí.

7. Pilotní provoz

a. Trvání min. 30 kalendářních dnů.

b. Zvýšený dohled nad provozem ISMP-POVS.

c. Řešení zjištěných vad a nedodělků.

Souběžně proběhnou následující aktivity:

8. Plošné zavedení MSD pro všechny strážníky:

a. Podpora rozšíření MSD na další OŘ a útvary MP. Plošnému zavedení MSD bude předcházet upgrade MSD na Android ve verzi 11 v souvislosti s nově pořizovanými zařízeními

b. Podpora pro řešení problémů uživatelů v rámci zavádění (odhadem cca 2 týdny / OŘ nebo jiný útvar MP).

9. Analýza MIS a plánem přechodu s cílem sjednotit technologickou platformu.

a. Analýza potřeb, požadavků a (ne)využívaných statistik a sestav ve stávajícím MIS a provozního technologického prostředí MIS a MP HMP obecně.

b. Návrh řešení modernizace MIS dle požadavků a potřeb MP HMP.

c. Výstupem bude dokument s katalogem požadavků na modernizaci MIS. Dokončení realizace:

10. Předání aktualizovaných zdrojových kódů do úschovy.

11. Akceptace realizace rozvojových požadavků.

Příloha č. 2

Podrobná specifikace ceny

Definované čtyři klíčové oblasti rozvoje jsou velmi rozsáhlé, proto je struktura ceny uvedena ve větším detailu, aby pracnost po jednotlivých oblastech byla úžeji specifikována. Rozdělení je provedeno po logických funkčních celcích, a to v následující struktuře:

A. Souhrnná Implementační analýza a detailní návrh řešení

- Tak jak je požadováno v harmonogramu, budeme v kroku provedena souhrnná upřesňující implementační analýza včetně detailního návrhu řešení

B. Implementace dle jednotlivých oblastí popsaných v katalogu požadavků (3.1 až 3.6.) jsme dále rozdělili do těchto funkčních celků:

Subsystém Operační řízení (OŘ)

- Základní funkcionalita plánování a vykazování dle požadavků pro celou organizaci

- Integrace na docházkový systém

- Realizace služeb plánování a vykazování ve vazbě na docházkový systém

- Změna rozhraní na technologii ReDat včetně úpravy fonogramů

- Ostatní rozvojové požadavky souhrnně Subsystém Mobilní sběr dat (MSD)

- Upgrade MSD na Android ve verzi 11 v souvislosti s nově pořizovanými zařízeními

- Zvýšený dohled pří zavádění MSD po dobu 2 týdnů pro každý obvod

- Ostatní požadavky souhrnně

Subsystém Manažerský informační systém (MIS)

- Požadavky jsou kalkulovány souhrnně Subsystém Lustrační modul (LM)

- Požadavky jsou kalkulovány souhrnně Subsystém Geografický informační systém (GIS)

- Požadavky jsou kalkulovány souhrnně Subsystém Platforma správy technologií (PST)

- Lokalizace

- Pamatování stavy legendy

- Dálkový výpis LV z ISKN včetně související integrace

- Ostatní rozvojové požadavky souhrnně

Jednotlivé dílčí oblasti rozvoje a jeho části jsou dále rozpracovány do pracnosti do jednotlivých profesí, a to v členění programátor, analytik, konzultant a projektový manažer.

Podrobná specifikace ceny:

Oblast / položka	Programátor	Analytik	Konzultant	Projektový manažer
Souhrnná Implementační analýza a detailní návrh řešení
Analýza a detailní návrh řešení po jednotlivých oblastech plnění	30	49,5	69,5	19
Subsystém Operační řízení (OŘ)
Základní funkcionalita plánování a vykazování dle požadavků pro celou organizaci	172,5	31	56,5	13,5
Integrace na docházkový systém	16,5	4	7	2
Realizace služeb plánování a vykazování ve vazbě na docházkový systém	116	20,5	26	9
Změna rozhraní na technologii ReDat včetně úpravy fonogramů	45,5	9	10,5	3,5
Ostatní rozvojové požadavky souhrnně	25	6,5	12	3
Subsystém Mobilní sběr dat (MSD)
Upgrade MSD na Android ve verzi 11 v souvislosti s novými zařízeními	44,5	8,5	6,5	3
Zvýšený dohled pří zavádění MSD po dobu 2 týdnů pro každý obvod	0	12	72	16,5
Ostatní požadavky souhrnně	38,5	8	7,5	3,5
Subsystém Manažerský informační systém (MIS)
Požadavky souhrnně	10,5	17,5	22	3,5
Lustrační modul
Požadavky souhrnně	47	8,5	12,5	3
Subsystém Geografický informační systém (GIS)
Požadavky souhrnně	11,5	1,5	4,5	1,5
Subsystém Platforma správy technologií (PST)
Lokalizace	76,5	12,5	21	4,5
Pamatování stavy legendy	47	5	7,5	2
Dálkový výpis LV z ISKN včetně související integrace	16,5	3,5	4,5	3
Ostatní rozvojové požadavky souhrnně	28,5	6	5	2
Xxxxxx (MD)	726	203,5	344,5	92,5
Celkem (Kč bez DPH) / pozice	8 349 000 Kč	2 442 000 Kč	4 134 000 Kč	1 063 750 Kč
Celkem (Kč bez DPH) / celé plnění	15 988 750 Kč