Příloha č. 6 zadávací dokumentace ve veřejné zakázce „Metropolnet – dodávka AIS“

Příloha č. 6 zadávací dokumentace ve veřejné zakázce „Metropolnet – dodávka AIS“



Návrh řešení – technická specifikace







Tento dokument popisuje rozsah díla, dodávky a služby, které objednatel poptává jako předmět ve veřejné zakázce s názvem „Metropolnet – dodávka AIS“.



  1. SOUČASNÝ STAV ICT

    1. Globální architektura ICT

Metropolnet, a.s. (dále také MNET) byl založen za účelem poskytování služeb Statutárnímu městu Ústí nad Labem, tj. úřadu Magistrátu Statutárního města Ústí nad Labem a jeho městským obvodům (dále také společně jako „město“) a městským organizacím.

MNET zajišťuje obměnu zařízení, období na obměnu technického zázemí je stanoveno na 5 let (v současné době není dodržováno, některá technika je i 7 let stará). Pro PC a notebooky je v drtivé většině poskytována řada firemních počítačů HP SFF (Small Form Factor) z důvodu poskytovaného rychlého a efektivního servisu. Díky dodržování produktové jednotnosti se snižují i náklady na servis, protože lze většinu vadných dílů vyměnit okamžitě na místě.

To stejné platí i pro černobílé osobní tiskárny (především Samsung). U velkých multifunkčních zařízení je také snaha držet podobnou či stejnou produktovou řadu, nicméně vzhledem k menšímu počtu kusů a velkou časovou trvanlivostí strojů jsou výrobci různí. Vždy však HP, či Canon.

    1. Funkční a procesní architektura ICT

MNET poskytuje městu služby na základě provozní smlouvy. Tato smlouva určuje úroveň spolupráce, definuje poskytované služby a provozované informační systémy. Zároveň stanovuje reakční dobu MNET na jednotlivé incidenty a poruchy.

Provozní požadavky a požadavky na rozvoj předává město prostřednictvím pravidelných schůzek se zástupci MNET. Zde se řeší i provozní problémy a požadavky na služby Metropolnet.

Při užívání ICT jsou všichni uživatelé povinni dodržovat vnitřní předpisy zveřejněné na intranetu města. Zde jsou k naleznutí rozhodnutí tajemníka, primátora a směrnice Rady města.

Procesy na Magistrátu jsou vykonávány na základě odpovědností pracovních pozic. Celkové workflow a toky všech dokumentů nejsou oficiálně (elektronicky) popsány.

    1. Softwarová architektura

Personalistika (Datacentrum) a identitní systém (EOS od Marbesu + Active Directory) jsou prvním vstupním prvkem pro zaměstnance. Poté má uživatel možnost přihlášení do spisové služby Xxxxx, MS Dynamics Navision, systému Agendio (vedení přestupkových agend, vymáhání, …) a Docházkový systém Xxxx.

Dále zde existuje mnoho serverových aplikací používaných malým množstvím uživatelů, většinou omezené na několik určených zaměstnanců odboru nebo aplikací bez dalšího provázání na jiné klíčové aplikace města. Mezi nejdůležitější patří:

  • Zákony, právní předpisy, … (Xxxxxxx Kluwer)

  • Dopravní agendy a správa majetku (CDSw)

  • Stavební úřad (VITA software)

  • Projektové ceny, ceny v místě a čase obvyklé dle ÚOHS (EuroCalc)

  • Evidence xxxxx (OM) – Odbor sociální věcí (Solař)

  • Evidence odpadů, evidence správních řízení (Inisoft)

  • Rozpočty pro příspěvkové organizace (Helios – Fénix)



Schéma č. 1 − Aplikační (SW) architektura

Všechny stanice mají definovanou základní softwarovou výbavu v provozní smlouvě. Další nadstavbová výbava se odvíjí dle jednotlivců a pracovních pozic na základě změnového požadavku, či formuláře s novým nástupem. Stejně tak se řeší i oprávnění v rámci serverových aplikací.

    1. Řízení ICT ve vztahu k Metropolnet

Model správy ICT města formou specializované dceřiné společnosti je v ČR ojedinělý, ale určitě ne výjimečný. V době vzniku Metropolnetu byl podobný model uplatňován i v dalších městech: Ostrava, Plzeň, Liberec. Později na podobný model přistoupila například i Česká Lípa. V omezené míře tento model využívá například i hlavní město Praha.

Trend vzniku podobných společností byl v letech 2008–2012 pozastaven (vliv dotací z EU, které předpokládaly přímé zapojení města, celkový odliv trhu od tzv. outsourcingu apod.). V poslední době se tento trend opět rozvíjí a přecházejí na něj některá ministerstva. Podobný model je zaváděn i v zahraničí (například Spolková země Sasko).

Model správy ICT ve své podstatě jen kopíruje osvědčený model z komerčních organizací, kde je centralizace správy ICT i dalších podpůrných oblastí (např. facility management, bezpečnostní a úklidové služby apod.) jeden z hlavních nástrojů pro kontrolu nákladů na tuto oblast a zefektivnění přínosů, které ICT přináší.

    1. „Green ICT“

Dlouhodobým strategickým cílem Metropolnetu je budování ICT v souladu se standardy IFG tzv. „Green ICT“.

Při provozu a rozvoji Informačního systému města bude zohledňována aktivní environmentální politika a budou realizována taková řešení, která podporují environmentální přístup od procesu výroby po proces likvidace a zároveň sama o sobě omezují negativní dopady na životní prostředí nebo přispívají k dopadům pozitivním (např. efektivnější využívání zdrojů). Takovým pozitivním dopadem budou úspory energie a omezení emisí CO2 např. centralizací a optimalizací využívání serverů a datových center, implementací cloudových řešení, elektronizací výkonu agend, ale i optimalizací využití koncových zařízení (např. efektivní využívání tiskových řešení) tak, aby se minimalizoval vliv na okolí a na životní prostředí.

Standardy IFG a Green ICT budou zohledňovány jako jeden z parametrů při rozhodování o realizaci investičních akcí v oblasti Informačního systému města tak, aby investice zajistily jak efektivnost v ekonomické oblasti, tak i větší šetrnost k životnímu prostředí.

    1. Shrnutí výchozího stavu

Žadatel plánuje řídit oblast ICT strategicky a koncepčně prostřednictvím Informační strategie, resp. Informační koncepce (dokument strategického charakteru vytvářený v souladu s požadavky zákona č. 365/2000 Sb. o informačních systémech veřejné správy). Žadatel také reflektuje požadavky zákona č. 181/2014, o kybernetické bezpečnosti a související podzákonné normy i best practice.



  1. ZÁKLADNÍ POŽADAVKY NA ŘEŠENÍ

    1. Předmět realizace veřejné zakázky

Předmětem plnění veřejné zakázky je dodávka komponent a aplikačních řešení vybraných agend a procesů města a zajištění technické podpory nových komponent.

Předmětem zadávacího řízení je tak dodávka a implementace nových komponent informačního systému nebo nových aplikačních řešení a jejich integrace na vybrané současné aplikační komponenty IS úřadu.

Záměr zadavatele z pohledu současných aplikačních komponent je uveden v následující tabulce:



Aplikační komponenta IS úřadu

Dodavatel (název komponenty)

Záměr zadavatele

IDM /správa uživatelů a oprávnění k výkonu agend/

MARBES CONSULTING s.r.o. (PROXIO-EOS)

Integrovat + rozšíření nebo nahrazení stávající komponenty

Vazba na ISZR (rozhraní přístupu k XZR)

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Základní registry (“Hledáček”), vč. Vazby na USEP, AISEO, …

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Přestupky a správní delikty

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Vyhodnocování přestupků z MKS (Camea)

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Místní poplatky ze psů a VHP

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Dopravní agendy

MARBES CONSULTING s.r.o. (PROXIO)

Nahradit

Správa pohledávek a vymáhání

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Volby

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Matrika, vidimace, legalizace

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Evidence subjektů

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Lokální registr obyvatel (Ohlašovna)

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Evidence rodin

Xxxxx (OM)

Nahradit

Personalistika a mzdy

Datacentrum DC2

Integrovat – stávající komponenta

Spisová služba

CNS a.s. (ELISA)

Integrovat – stávající komponenta

Ekonomický systém

Microsoft Dynamics Navision (NAV)

Integrovat – stávající komponenta

Docházkový systém

XXXX Xxxxxxxxx (XXXX)

Integrovat – stávající komponenta

Správní řízení – STÚ

VITA software s.r.o. (VITA STÚ)

Integrovat – stávající komponenta

Silniční správní úřad, vč. Speciálního stavebního úřadu

VITA software s.r.o.

(VITA STÚ)

Integrovat – stávající komponenta

Vodoprávní úřad, vč. Speciálního stavebního úřadu

VITA software s.r.o. (VITA STÚ)

Integrovat – stávající komponenta

Správní řízení – Životní prostředí

YAMACO (EMA – Evidence myslivosti, Rybářské a myslivecké lístky)

Nahradit

Správní řízení – Životní prostředí

INISOFT (EVI, ESPI – pro průběžnou evidenci odpadů)

Nahradit

GIS

GeoCortex (Lattitude Geographics) pro pořízení ÚAP, Prezentace dat v prostředí Geoportálu

Integrovat – stávající komponenta



Přesná specifikace předmětu plnění v rozsahu požadovaném zadavatelem je obsažena v tomto dokumentu, předmětem plnění jsou zejména tyto komponenty:

  1. Dodávka licencí, resp. multilicencí v definovaném rozsahu a počtu, implementace aplikační a databázové části systému (včetně vytvoření testovací instance), testovací provoz a předání do řádného užívání informačních systémů pro tyto hlavní aktivity:

  • Centralizace správy organizační struktury a přístupových práv pro interní i externí uživatele.

  • Řešení tzv. „dvou-faktorové“ autentifikace koncových uživatelů (přihlášení přes čipovou kartu / token a PIN), zavedení souladu s nařízením eIDAS.

  • Správa čipových karet

  • Portál občana jako aplikační rozhraní pro styk občana s městem vč. zajištění úplného elektronického podání občana a s tím souvisejících inteligentních formulářů.

  • Formulářové řešení a redakční systém pro Portál občana a Portál úředníka.

  • Portál úředníka jako aplikační rozhraní pro práci úředníka (zaměstnance města) vč. integrace dodaného pracovního prostoru na vybrané AIS města.

  • Řízení dokumentace (DMS) a dlouhodobý digitální archiv

  • Elektronizace jednání Rady a Zastupitelstva města

  • Service Desk

  • Vedení žádostí dle zákona 106/1999 Sb.

  • Digitalizace agend, které zatím nejsou plně elektronizovány (OSV)

  • Koordinované stanovisko

  • Dopravní agendy

  • Životní prostředí

  1. Dále je předmětem plnění

  • provedení integrací na další systémy v prostředí zadavatele,

  • migrace dat z jednotlivých zdrojových systémů do dodávaného řešení,

  • zaškolení uživatelů – odborného personálu města (klíčový uživatelé),

  • zaškolení uživatelů – personálu města (zaměstnanci),

  • zaškolení personálu (správci a administrátoři zadavatele – Metropolnet, a.s.),

  • dodávka dokumentace k dodaným informačním systémům v požadovaném rozsahu.

  1. Součástí plnění je i:

  • provozní podpora a servis dodaného řešení po dobu 60 měsíců,

  • rozvoj a úpravy dodaného díla.



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

Součástí předmětu plnění jsou i další dodávky a služby, které jsou nezbytné pro dosažení zadavatelem požadovaného cíle a o kterých dodavatel s ohledem na svoji odbornost a erudovanost měl nebo mohl vědět.

    1. Společné vlastnosti nového řešení

Pol.

Obecné principy a technologické vlastnosti

Návrh řešení splňuje (ANO x NE)

1

Kompletní lokalizace aplikační části v českém jazyce.


2

Soulad všech agend s aktuální legislativou platnou pro subjekty veřejné správy, včetně dopadů z Nařízení Evropské unie o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu (eIDAS) a Nařízení Evropské unie o ochraně osobních údajů, tzv. General Data Protection Regulation (GDPR).


3

Plně elektronizované řešení, odbourávající v implementovaných oblastech papírový oběh dokumentů v rámci města a výhledově příspěvkových organizacích.


4

Logování operací – všechny kroky a operace prováděné v systému jsou ukládány, a je možné je zpětně dohledat / vyhledat a za konkrétního uživatele v daném období, tak za danou oblast / modul v daném období a další požadavky dle obecného nařízení (EU) 2016/679 (GDPR).


5

Vícevrstvá systémová architektura s možným dalším členěním do více vrstev (klient – server, možnost dedikovaných serverů pro databázi, aplikaci).


6

Řešení musí umožňovat transakční zpracování dat (zpracování dat v jednotlivých krocích, které je možné opakovat nebo vracet zpět včetně jejich logu).


7

Integrace mezi jednotlivými součástmi řešení bude realizována na bázi webových služeb.


8

Identita uživatelů pracujících v jednotlivých komponentách systému a jejich uživatelská oprávnění budou spravovány centrálně prostřednictvím stávající aplikace PROXIO-EOS v integraci s AD.


9

Všechny dodávané komponenty systému budou využívat ověření údajů ze základních registrů pro data, která lze v ZR ověřit. Ověření údajů je možné realizovat prostřednictvím stávající aplikace PROXIO-XZR. Tato aplikace v integraci s IDM PROXIO-EOS zprostředkuje komunikaci, zajistí logování údajů o přístupu k základním registrům, ověří též oprávnění přístupu uživatele pod danou agendou a činnostní rolí a zabezpečí, že volání služeb ISZR bude jen s agendami a rolemi přidělenými danému uživateli v systému centrální správy identit NEBO samostatným logováním a přístupem k základním registrům.


10

Administrace a konfigurace všech parametrů IS, včetně definice šablon dokumentů bez nutnosti zásahu dodavatele.


11

Přístupný administrátorský nástroj ke všem dodávaným agendám v počtu min. 2 licencí pro současně pracující uživatele pro správu systému.


12

Popsané a zdokumentované otevřené aplikační rozhraní jednotlivých komponent pro obousměrnou komunikaci s dalšími aplikacemi jiných dodavatelů na bázi Web Services (technologie SOAP), které umožní připojení a výměnu dat (poskytování open dat prostřednictvím API – např. REST).

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í, dokoupení dokumentace apod.).


13

Integrace nabízeného řešení se spisovou službou úřadu bude realizována v souladu s platným Národním standardem pro elektronické systémy spisové služby (Oznámení Ministerstva vnitra, kterým se zveřejňuje národní standard pro elektronické systémy spisové služby - viz věstník MV ČR –VMV čá. 57/2017).


14

Integrace nabízeného řešení na agendový systém PROXIO a MS Navision v minimálním rozsahu popsaném v dalších kapitolách (požadavcích).



  1. POŽADAVKY NA FUNKCIONALITU JEDNOTLIVÝCH ČÁSTÍ ŘEŠENÍ

    1. Rozšíření systému centrální správy identit

Správu identit pracovníků úřadu zajišťuje stávající IDM systém PROXIO-EOS. Jeho součástí je evidence všech pracovníků, kteří mají přístup do informačního systému úřadu, jsou zařazení v organizační struktuře ve svých pracovních pozicích, a dále zaměstnanců příspěvkových organizací města. Uživatelé mají založenu svoji jednoznačnou identitu, ověřovanou prostřednictvím PROXIO-EOS nebo AD. Uživatelé mají zároveň možnost přístupu k ISZR na základě jejich pracovního zařazení.

IDM systém PROXIO-EOS načítá z RPP seznam agend a činnostních rolí, které jsou pro organizaci (úřad) zaregistrovány. Tyto agendy pak následně pověřená osoba přiřazuje jednotlivým pracovníkům či jejich pracovním pozicím, aby mohli v rámci své působnosti přistupovat k ISZR a ověřovat v něm referenční údaje.

IDM systém PROXIO-EOS je napojen na Microsoft Active Directory (AD), který provádí autentizaci přihlašovaných uživatelů. Autorizaci zajistí PROXIO-EOS, který přiděluje těmto oprávněným osobám příslušná oprávnění v informačním systému úřadu.

Záměrem projektu je rozšíření stávajícího IDM systému PROXIO-EOS o následující funkce:

Pol.

Centrální správa identit

Návrh řešení splňuje (ANO x NE)

1

Synchronizace s personálním systémem úřadu (Datacentrum – DC2), který je prvotním zdrojem dat pracovníků úřadu do IDM. Po počátečním importu je nutné, aby byla synchronizace mezi oběma systémy ve směru z personálního systému do IDM nastavena periodicky, například každou noc.


2

IDM systém bude evidovat i občany přihlašující se na Portál občana. Tyto osoby nebudou synchronizovány ani s personálním systémem, ani do AD. V tomto případě se stane IDM nejen autorizačním nástrojem, ale i autentizační autoritou. Občané registrovaní pro přístup k portálu budou evidováni samostatně, odděleně od pracovníků úřadu.


3

Registrace občana – vznik identity v IDM systému – musí být umožněn několika různými způsoby:

  • Registrací na přepážce úřadu.

  • Elektronickým podáním s vícefaktorovým potvrzením.

  • Převzetím identity z MojeID – podle stupně ověření.

  • Pomocí občanského průkazu s elektronickým čipem.

  • Dalšími způsoby dle specifikace Portálu občana.


4

Registrací na přepážce úřadu je zamýšlen takový postup, kdy občan přijde na úřad a na přepážce předloží průkaz totožnosti. Pracovník úřadu ověří totožnost občana a vznikne „Smlouva o elektronickém poskytování informací“. Zároveň s tím občan stvrdí souhlas s uchováním osobních údajů. Po obdržení přihlašovacích údajů se může přihlásit na Portál občana prostřednictvím uživatelského jména a hesla.


5

Registrací občana elektronicky s vícefaktorovým potvrzením je zamýšlen takový postup, kdy občan vyplní svoje nezbytné osobní identifikační údaje, úředník ověří zadané údaje a na doručovací adresu odešle výhradně do vlastních rukou dopis s údaji pro dokončení registrace a souhlasem s uchováním osobních údajů, a občan tímto dopisem obdrží přihlašovací údaje.


6

Registrace občana prostřednictvím již vytvořené identity MojeID: úřad bude důvěřovat této vytvořené identitě MojeID, občan se může zaregistrovat elektronicky na portálu úřadu. Zde se převezmou identifikační údaje občana z MojeID, v IDM se založí jeho identita, občan potvrdí souhlas s uchováním osobních údajů a následně se může připojit k portálu úřadu pod identitou z MojeID. Úroveň oprávnění v portálu bude dána úrovní registrace na MojeID.


7

Připravenost IDM na registraci občana prostřednictvím občanského průkazu s elektronickým čipem: občan se přihlásí k registraci na Portálu občana, bude ověřen prostřednictvím NIA (Národní identitní autorita), uchová se identita občana v IDM a souhlas s uchováním osobních údajů a občan může využívat služby Portálu občana.


8

Možnost sloučení více identit k jedné osobě.


9

Integrace s agendovými systémy města – IDM řídí oprávnění agendovým informačním systémům a předává informace o organizační struktuře a pracovnících.


10

Integrace se spisovou službou v oblasti organizační struktury, uživatelů a řízení oprávnění – IDM řídí oprávnění ke spisové službě a předává informace o organizační struktuře a pracovnících.


11

IDM systém bude evidovat i zaměstnance PO města, kteří budou přistupovat do IS města, a to shodným způsobem jako zaměstnanci úřadů. Zaevidování proběhne v tomto případě „ručně“ v IDM s následnou synchronizací do AD.


12

IDM musí podporovat 2FA (two-factor authentication) např. odesláním části hesla na e-mail a další části či potvrzení prostřednictvím SMS brány na mobil, zadání karty a jejího PIN.


13

Centrální bod k evidenci, auditu a logování oprávnění konkrétních zaměstnanců, umožňující tvorbu oprávnění jak na generická funkční místa, tak možnosti přidělování oprávnění jednotlivě.


14

Integrace a nastavování oprávnění v rámci IDM pro nenahrazované systémy z tabulky z bodu č. 2.1, včetně všech nově pořizovaných funkcionalit a modulů. Konkrétně se jedná o systémy PROXIO vč. všech modulů, MS NAV Dynamics, Spisová služba CNS, VITA software, Datacentrum DC2, IVAR docházkový systém, GIS server GEOCORTEX.


15

Přiřazení a integrace se systémem autentizačních (USB) tokenů, vedení jejich evidence.


16

Evidence a přiřazení NFC čipů (docházkový systém, tiskový systém).


17

Otevřené integrační rozhraní vč. jeho popisu (WS, API rozhraní SOAP/REST).


18

Možnost správy neomezeného počtu organizací, možnost rozdělení správců pro konkrétní organizace.


19

Možnost „vedoucích“ rolí v přidělování oprávnění a činnostních rolí pro své pracovníky ve dvou variantách 1. přímé zadání vedoucím, 2. požádání vedoucím a schválení v IT.




    1. Dvoufaktorová autentizace

Řešení tzv. „dvou-faktorové“ autentifikace koncových uživatelů (přihlášení přes heslo a čipovou kartu / USB token), zavedení souladu s nařízením eIDAS. Popis používaných tokenů viz dále v textu.

Pol.

Centrální správa identit

Návrh řešení splňuje (ANO x NE)

1

Řešení tzv. „dvou-faktorové“ autentifikace koncových uživatelů (přihlášení přes heslo a čipovou kartu / USB token).


2

Plná kompatibilita s tokeny / čipovými kartami Starcos 3.5 plug-in


    1. Správa autentizačních (USB) tokenů

Zadavatel využívá pro vydávání kvalifikovaných certifikátů aplikaci X.XX SecureStore a jako tokeny využívá čipové karty Starcos 3.5 plug-in (čip vhodný pro vložení do USB tokenu miniLector-S EVO). Vylamovací karty obsahující čip s operačním systémem Starcos 3.0/3.2/3.5 (výrobce Xxxxxxxx & Devrient GmbH). Karty jsou vkládány do malé, příruční USB čtečky karet.

Název

Starcos 3.5

Chip

Infineon M7820

EEPROM

do 128 kB

Maximální délka klíče

4096 bitů/RSA, 521 bitů/ECC

Certifikace čipové karty

Common Criteria EAL 5+, ALC_DVS.2, AVA_VAN.5

Certifikace OS

Bezpečnostní funkce Common Criteria EAL 4+, AVA_VAN.5, Secure Signature Creation Devices (SSCDs)



Správa autentizačních (USB) tokenů je aplikační komponenta zajišťující podporu řízení celého životního cyklu tokenu.

Pol.

Správa čipových tokenů

Návrh řešení splňuje (ANO x NE)

1

Podpora řízení celého životního cyklu tokenu (inicializace, …).


2

Při ztrátě, nebo zapomenutí tokenu možnost vydání nového tokenu a zablokování starého. Možnost nouzového přihlášení k účtu v případě zapomenutého tokenu.


3

Vedoucí odboru – možnost řízení oprávnění pro podřízené zaměstnance (vytvoření dočasného hesla, ohlášení ztráty tokenu, návrh na zablokování tokenu apod.).


4

Integrace do AD (vlastní certifikační autorita pro přístup do domény, "zákaz" využití hesla k přihlášení do domény).


5

Integrace do IDM (evidence tokenu v IDM, přiřazení konkrétní osobě).


6

Integrace na certifikační autoritu (zadavatel využívá Windows aplikaci SecureStore od X.XX) – vydávání a import certifikátů do úložiště tokenu. Podpora standardy ISO 7816.


7

Plná podpora tokenů (čipové karty Starcos 3.5 plug-in vkládaných do USB tokenů miniLector-S EVO).


8

Obnova páru klíčů při nalezení ztraceného tokenu.


9

Nepovinný požadavek: Podpora pro vytváření a správu softwarových / virtuálních tokenů např. pro kontraktory (bez distribuce tokenů), tj. podpora OTP (One-Time Password).


10

Nepovinný požadavek: Možnost vzdáleného zákazu tokenu po zrušení ve Správě autentizačních (USB) tokenů (a/nebo IDM) – výmaz tokenu po připojení zakázaného tokenu do počítače.




    1. Portál občana

Portál občana musí zprostředkovat elektronickou komunikaci mezi občanem a městem. Elektronická komunikace musí probíhat přes webovou aplikaci, prostřednictvím které veřejnost bude vzdáleně přistupovat ke službám města a řešit s ním životní situace ve vybraných oblastech občanských a podnikatelských činností (realizovaných prostřednictvím magistrátu nebo úřadů městských obvodů).

Cílem Portálu občana je vytvořit jednoduchou a intuitivní platformu pro komunikaci občana s veřejnou správou a s její pomocí tak přesunout e-Government z prostředí podatelen úřadů do domácího prostředí občanů. Pro tuto komunikaci budou vybrány životní situace, které jsou poskytovány městem a budou přeneseny do Portálu Občana a elektronizovány.

Portál Občana musí obsahovat kombinaci vlastností, funkcí a informací, jež umožňují městu přijímat a zpracovávat podání od občanů a občanům pomoci sestavit a správně adresovat podání. Dále musí občanům poskytovat zpětnou vazbu o jejich podání s informacemi o stavech řešení s uvedením data a času změny. Případně umožnit úředníkům vložit komentáře ke každé podané žádosti a občanovi umožnit na tento komentář odpovědět.

Portál občana bude rozdělen na veřejnou a neveřejnou část.

Pol.

Portál občana – veřejná část

Návrh řešení splňuje (ANO x NE)

1

Je k dispozici všem návštěvníkům portálu (vč. anonymních).


2

Přes tuto část bude možné vyřídit životní situace, kde komunikace s úřadem proběhne e-mailem + elektronickým podpisem nebo formulář životních situací bude vytištěn a doručen na podatelnu města.


3

Je možné integrovat telefonní seznam + generovat a načítat z organizační struktury úřadu kontaktní údaje o úřednících.




Pol.

Portál občana – neveřejná část

Návrh řešení splňuje (ANO x NE)

1

Předpokládá registraci občana a jeho přihlašování unikátním jménem a heslem.


2

K přihlášení bude možné využít autority mojeID / ISDS.


3

Portál Občana musí umožnit se přihlásit přes jiné autority (řešení eIDAS) a zároveň musí být portál připraven k využívání elektronického občanského průkazu.


V neveřejné části budou poskytovány registrovaným občanům tyto minimální služby:

4

Předvyplnění formuláře (žádosti) osobními údaji.


5

Dostupnost formulářů životních situací s přenesenou působností (Doprava, Stavební úřad, Životní prostředí) a samosprávní (Žádost o informaci, Psy, Odpady, …).

Pozn.: Seznam všech formulářů je specifikován v technických podmínkách níže.


6

Zasílání notifikací (e-mail, SMS) o zveřejněných informací/upozornění, které budou směřovány na konkrétní občany či skupiny občanů.


7

V rámci přehledu vlastních podání občan uvidí historii rozdělenou na Odeslané, Vyřešené, Rozpracované.


8

V detailu podání budou zobrazeny tyto informace:

  • Název podání

  • Datum podání

  • Číslo jednací

  • Náhled podání (zobrazení zaslaného podání)

  • Stavy podání (od podání, stažení, předělení, až vyřízení) s uvedeným datem a časem změny

  • Úřad příslušný k vyřízení podání

  • Zobrazení komentáře úředníka k podání s uvedením kontaktních údajů na zmíněného úředníka


9

Upozornit občana o stavu jeho žádostí, smluvních vztahů, poplatků, platbách apod.


10

Platební historii „Mé platby“ kde jsou zobrazený všechny platby, které občan provedl/zaplatil nebo které má provést/zaplatit.

Pozn.: Nabízené platby budou směřovány na platební bránu úřadu.


11

Portál Občana musí umožňovat integraci na další části informací z používaných řešení na úřadě:

  • Integrace objednání občanů na přepážku (předpokládaná funkčnost)

  • Integrace úřední desky do grafiky Portálu Občana (předpokládaná funkčnost)

  • Integrace s Evidencí smluv (předpokládaná funkčnost)

  • Integrace s Evidencí veřejných zakázek (předpokládaná funkčnost)

  • Umožnění zveřejňovat materiály pro radu a zastupitelstvo




Součástí portálu Občana musí být redakční systém, který bude plnit úlohu zveřejňování informací, upozornění a dalších (Anket, diskuzí, …). Redakční systém též musí obsahovat dokumentovou knihovnu, pro zveřejňování povinných údajů.

Pol.

Redakční systém (CMS)

Návrh řešení splňuje (ANO x NE)

1

Redakční systém obslouží minimálně 500 současně přistupujících uživatelů.


2

Obsah portálu je automaticky generován na základě zadávaných dat uživateli bez potřeby znalosti HTML či jiného programovacího jazyka.


3

Veškeré ovládání a Zadávání dat se provádí přes webové rozhraní bez potřeby dalších klientů.


4

Kvalitní a originální vzhled, s možností automaticky generovaného obsahu.


5

Možnost Zpracování zpráv, dokumentů. xxxxxx, fotografií, fotoalb, anket, diskuzí apod.


6

Systém přesně definovaných práv redaktorů, skupin a rubrik, do kterých mohou úředníci přispívat.


7

Jednoduché a intuitivní webové rozhraní pro zadávání informací.


8

Definice a kontrola libovolných diskusních fór.


9

Možnost využití pro jakoukoliv oblast prezentace informací.


10

Možnost tvorby a rozesílání newsletterů.


11

Vytváření libovolných diskusních fór a správa jejich příspěvků.


12

Ve správcovské konzoli správa neomezeného množství webů.


13

Dynamická generace menu administrace přístupových skupin.


14

Vytváření anket a možnost jejich vyhodnocování.


15

Práce se šablonami dokumentů.


16

Administrace uživatelů newsletterů.


17

Fulltextové prohledávání.


18

Vytváření rubrik článků.


19

Zařazování článků do rubrik.


20

Vytváření, mazání, přesouvání, kopírování článků.


21

Filtrování článků.


22

Třídění článků.


23

Rozdělení článku na anotaci a tělo.


24

Definice zobrazování podle data zviditelnění a expirace.


25

Zobrazení článků jako seznamu či detailu.


26

Vkládání formulářů.


27

Práce se styly.


28

Přikládání souborů.


29

Definice zakončení článku (anketa / fórum / odpověď autorovi).


30

Tematické třídění článků.


31

Definice menu: možnost uživatelské konfigurace položek menu, včetně odkazů a struktury.


32

Redakční systém musí být plně použitelný i pro Portál úředníka (viz požadavky uvedené dále).




      1. Formulářový server / Inteligentní formuláře

Součástí dodávky je dodání a zavedení systému inteligentních formulářových aplikací, které umožní elektronizaci komunikace a procesů. Aplikace budou řešit interní procesy uvnitř úřadu i žádosti a procesy vně úřadu, směrem k občanům města a správního obvodu ORP Ústí nad Labem.

Formulářový server bude umožňovat integraci na bázi formulářového systému – je charakterizován zavedením jednotného centrálně spravovaného systému formulářů koexistujících se stávajícími aplikacemi. Formuláře procesně doplní a podpoří vybrané činnosti vykonávané mimo stávající informační systémy Zadavatele, případně bude provedena podle analýzy také účelová integrace dílčích formulářů s aplikacemi, které budou k integraci připraveny.

Pol.

Formulářový server

Návrh řešení splňuje (ANO x NE)

1

Formulářový systém umožní zavedení formulářového serveru, který je schopen řešit vnější a interní procesy elektronickými formuláři.


2

V návaznosti na formulářové procesy musí být umožněno sledování koloběhu daného procesu od počátku do konce a veškeré stavy procesu bude možné dohledat i zpětně pro možnou kontrolu.


3

Formulářový server umožní spravování vlastních uživatelských účtů, práv uživatelů, skupin uživatelů a rolí cestou synchronizace s IDM.


4

Mezi jeho další funkční vlastnosti budou patřit e-mailová notifikace, fulltextové vyhledávání a přístup přes webové rozhraní.


5

Formulářový systém musí podporovat otevřené standardy:

  • podporovat otevřený formát XML (xxxx://xxx.x0.xxx/XXX/), v němž budou datové výstupy v budoucnu dostupné, tak i stávající formát CSV/ DTA.

  • grafická podoba zpracovávaných dokumentů musí vycházet z otevřeného formátu standardu XSL:FO (xxxx://xxx.x0.xxx/XX/xxx/) s podporou stránkového formátování dokumentů, včetně podpory uživatelsky definovaných rozměrů stránek (obálek, formátů větších formátů např. A3 apod.). Souborový formát zpracovávaných dokumentů by měl umožňovat uložení v komprimovaném formátu.


6

SW musí podporovat možnost podepsání dokumentu kvalifikovaným elektronickým podpisem podle standardu XML Signature (xxxx://xxx.x0.xxx/Xxxxxxxxx/). To znamená, že schvalování u vnitřních procesů bude řešeno pomocí elektronického podpisu, tak aby byly dodrženy všechny zákonné požadavky.


7

Vnější procesy budou zaměřeny na oblast přenesené i samostatné působnosti a zajistí komunikaci s úřadem prostřednictvím e-mailu, informačního systému datových schránek a papírové podoby daného procesu včetně 2D nebo QR čárového kódu generovaného z vyplněných evidenčních dat ve formuláři.


8

Elektronické formuláře zaměřené na vnitřní procesy budou nasazeny tak, aby umožnily efektivní nahrazení papírové podoby vybraných současných agend bez nutnosti změn vnitřních směrnic a organizačních opatření, vyjma možnosti schvalování procesů pomocí elektronických nástrojů.


9

U vnitřní procesů založených na elektronických formulářích bude umožněno sledování veškerých úkonů probíhajícího procesu a zajištění kontroly jeho průběhu od počátku až do konce. Dále systém umožní zpětnou kontrolu každého procesu i po jeho ukončení.


10

SW musí umožnit online i offline vyplňování těchto formulářů s možností průběžného ukládání souboru a odeslání dat až po připojení k síti.


11

SW musí mít kontrolu dat již při vyplňování formulářů a pomoc při vyplňování s kontextovou nápovědou (automatické výpočty, kontrola pravopisu v češtině, kontrola formátu apod.).


12

SW musí poskytovat možnost převodu formulářů do PDF formátu, tisk formulářů na tiskárnu, dynamické číselníky a skripty, WYSIWYG návrh šablon a rychlé nasazení, upozorňování uživatelů na novou verzi formuláře v případě změny formuláře, zálohování a evidenci formulářů, možnost dalšího použití SW k elektronickému zpracování formulářů v resortních IS.


13

SW musí dále poskytovat bezplatný nástroj pro WYSIWYG návrh šablon ve formě formulářů a vytváření vlastních formulářů pro rychlé nasazení a shromažďování.


14

SW musí umožnit odeslání vyplněného formuláře na webový server (HTTP/HTTPS, SOAP a GovTalk), dále jako příloha e-mailu a musí umožnit vytvoření datové zprávy podle zákona č. 300/2008 Sb. ve znění pozdějších předpisů s umístěním vyplněného formuláře jako přílohy k této datové zprávě.


15

SW musí podporovat dynamické číselníky a skripty.


16

K SW musí existovat SDK nástroj pro ovládání z třetích aplikací.


17

Nabízené SW řešení musí mít možnost upozornění uživatele na novou verzi formuláře v případě změny formuláře.


18

Formuláře musí být přizpůsobeny designu zadavatele.


19

SW musí podporovat vyplnění formuláře a jeho digitální podepsání z webového prohlížeče, a současně i z tlustého klienta.


20

Provozní platforma nového informačního systému může být provozovaná ve fyzickém nebo virtualizovaném prostředí na platformě MS Windows Server.


21

SW musí mít možnost ve formuláři vybrat z číselníku konečného příjemce, a nahradit tím funkci natvrdo vybraného konečného příjemce (dynamický výběr konečného příjemce z předem definované množiny konečných příjemců).


22

SW musí mít možnost definovat pro každý formulářový proces samostatnou mailovou notifikaci, možnost vložení dynamických maker, která se doplní z DB nebo funkcí.


23

SW umožní zpracovávat formuláře nezávisle na použité platformě, musí podporovat standardní počítače (PC, notebook) i mobilní zařízení (tablet, smartphone).


24

SW umožní práci s formuláři minimálně na zařízeních s těmito operačními systémy – iOS, Android, Windows a Windows Phone.


25

SW musí splňovat minimálně tyto požadavky na hesla

  • vynucení změny hesla v případě prvního přihlášení

  • unikátnost hesla – kolik hesel musím rotovat

  • trvanlivost hesla – za jak dlouho mě vyzve systém ke změně


26

SW musí podporovat jednoduchou formou změny, které se týkají hromadných operací, minimálně v tomto rozsahu:

  • předání agendy – možnost vybrat, komu předat jaký formulář nebo proces, kdy automaticky dojde k nahrazení člověka ve formulářích nebo procesech (nový člověk dostane kompletní agendu po předchozím člověku).


27

Rozhraní:

  • Klíčové funkce aplikací budou dostupné formou otevřeného a rozhraní, které v případě potřeby bude snadno a bez dodatečných úprav dostupné prostřednictvím Webových služeb (http, SOAP).

  • Případná integrace mezi jednotlivými systémy, bude provedena prostřednictvím Webových služeb (http, SOAP, pro binární data s optimalizací MTOM).


28

Součástí dodávky bude následující dokumentace:

  • Funkční dokumentace

  • Schválený funkční popis jednotlivých systémů


29

Technická dokumentace:

  • Schválený technický popis architektury navrženého řešení

  • Detailní technický popis jednotlivých vrstev řešení a jejích částí


30

Uživatelská dokumentace:

  • Uživatelský manuál (bude dostupný také z menu aplikace).


31

Administrátorská (provozní) dokumentace.


32

Testovací dokumentace:

  • Seznam testovacích scénářů, včetně popisu jednotlivých kroků a způsobu vyhodnocení.




Pol.

Formuláře – specifikace

Návrh řešení splňuje (ANO x NE)

1

Musí být zcela v souladu s platnou legislativou.


2

Musí být plně kompatibilní s prostředím zadavatele.


3

Musí umožňovat použití v prostředí různých webových prohlížečů.


4

Musí umožňovat natažení osobních údajů z datové schránky žadatele.


5

Musí umožňovat odeslání prostřednictvím datové schránky přímo z prostředí formuláře.


6

Musí umožňovat podání prostřednictvím elektronické adresy e-podatelny zadavatele přímo z prostředí formuláře.


7

Musí umožňovat podepsání kvalifikovaným certifikátem.


8

Musí generovat 2D čárový kód se základními identifikačními údaji pro načtení a evidenci do elektronické spisové služby zadavatele. Musí podporovat QR kódy.


9

Musí umožňovat vytištění v podobě použitelné pro následné podání v listinné podobě.


10

Musí mít jednotnou grafickou podobu zejména fontů a tlačítek pro snazší použitelnost.


11

Musí umožňovat změnou konfigurace nastavit, zda mají v záhlaví zobrazovat hlavičku zadavatele.


12

El. formulářové aplikace zaměřené na vnitřní i na vnější procesy budou nasazeny tak, aby umožnily efektivní nahrazení papírové podoby vybraných současných agend.


13

Grafická podoba zpracovávaných dokumentů musí vycházet z otevřeného formátu standardu XSL:FO (xxxx://xxx.x0.xxx/XX/xxx/) s podporou stránkového formátování dokumentů, včetně podpory uživatelsky definovaných rozměrů stránek (obálek, formátů větších formátů např. A3 apod.). Souborový formát zpracovávaných dokumentů by měl umožňovat uložení v komprimovaném formátu.


14

Možnost integrace formulářů se stávajícími systémy úřadu – zejména DMS a elektronickou spisovou službou.


15

Schvalování u vnitřních procesů bude řešeno pomocí el. podpisu, tak aby byly dodrženy všechny zákonné požadavky podle zákona 297/2016 o službách vytvářejících důvěru pro elektronické transakce. Aplikace kvalifikovaného elektronického podpisu bude umožněna i parciálně, tak aby bylo možné data (formuláře) podepisovat po částech a tím zaručit odpovídající procesní požadavky konkrétní agendy.


16

SW musí umožnit offline vyplňování těchto formulářů s možností průběžného ukládání souboru a odeslání dat až po připojení k síti. Klient pro práci offline musí být k dispozici bezplatně.


17

SW musí mít kontrolu dat již při vyplňování formulářů a pomoc při vyplňování s kontextovou nápovědou (automatické výpočty, kontrola pravopisu v češtině).


18

SW musí poskytovat možnost převodu formulářů do PDF formátu, tisk formulářů na tiskárnu, dynamické číselníky a skripty.


19

SW řešení umožní zobrazování procesů (formulářů) ve webové podobě.


20

SW řešení umožní práci s formuláři i na mobilních zařízeních a dostupných platformách (Windows, iOS, Android).


21

SW řešení umožní aplikaci elektronického podpisu na webově zobrazovaném formuláři, a to minimálně na platformách Windows, iOS, Android.




Pol.

Inteligentní formuláře

Návrh řešení splňuje (ANO x NE)

Agendy v přenesené působnosti

1

Agenda Stavební úřad

  • Žádost o vydání rozhodnutí o umístění stavby

  • Žádost o vydání rozhodnutí o změně využití stavby

  • Žádost o vydání rozhodnutí o změně vlivu užívání stavby

  • Žádost o vydání rozhodnutí o dělení nebo zcelování pozemku

  • Žádost o vydání rozhodnutí o ochranném pásmu

  • Žádost o vydání společného územního rozhodnutí a stavebního povolení

  • Žádost o územní souhlas

  • Ohlášení stavby

  • Žádost o stavební povolení

  • Oznámení stavebního záměru s certifikátem autorizovaného inspektora

  • Oznámení o užívání stavby

  • Žádost o vydání kolaudačního souhlasu

  • Žádost o povolení předčasného užívání stavby

  • Oznámení změny v užívání stavby

  • Ohlášení odstranění


2

Agenda řidičů a vozidel

  • Žádost o vydání mezinárodního řidičského průkazu

  • Potvrzení o odevzdání řidičského průkazu nebo mezinárodního řidičského průkazu

  • Evidenční karta řidiče

  • Žádost o schválení technické způsobilosti

  • Žádost o povolení výroby jednotlivého vozidla, o povolení přestavby vozidla

  • Žádost o uznání testování silničního vozidla

  • Žádost o výdej dat z registru silničních vozidel

  • Žádost o vyřazení vozidla z registru vozidel

  • Žádost o zápis změn údajů z registru silničních vozidel

  • Žádost o zapsání vymazání zástavního práva k vozidlu v registru vozidel

  • Přihláška k registraci vozidla do registru SV

  • Žádost o vydání tabulky s registrační značkou

  • Žádost o vydání tabulky s registrační značkou na vývoz

  • Oznámení o ztrátě, zničení nebo odcizení tabulky s registrační značkou

  • Žádost o vyřazení silničního vozidla z provozu a zápis zániku silničního vozidla

  • Žádost o zápis změny vlastníka nebo provozovatele silničního vozidla

  • Žádost o zápis silničního vozidla do registru silničních vozidel

  • Žádost o zápis změn údajů v registru silničních vozidel

  • Žádost o poskytnutí údajů z registru silničních vozidel

  • Žádost o poskytnutí údajů z registru silničních vozidel


3

Agenda životního prostředí

  • Žádost o povolení k nakládání s povrchovými nebo podzemními vodami nebo jeho změnu

  • Žádost o povolení k odběru podzemních vod pro potřeby jednotlivých občanů (domácností) nebo o jeho změnu

  • Žádost o povolení k vypouštění odpadních vod do vod povrchních nebo o jeho změnu

  • Žádost o povolení k vypouštění odpadních vod do vod podzemních z jednotlivých bytových domů a z jednotlivých staveb poskytujících služby nebo o jeho změnu

  • Žádost o povolení k vypouštění odpadních vod do vod povrchových pro potřeby jednotlivých občanů (domácností) nebo o jeho změnu

  • Žádost o povolení k vypouštění odpadních vod do vod podzemních pro potřeby jednotlivých občanů (domácností) nebo o jeho změnu

  • Žádost o povolení k některým činnostem nebo o jeho změnu

  • Žádost o stavební povolení k vodním dílům

  • Žádost o stavební povolení k domovní čistírně odpadních vod, studni nebo jinému vodnímu dílu potřebnému k odběru podzemních vod pro potřeby jednotlivých občanů (domácností)

  • Žádost o povolení k užívání vodních děl

  • Žádost o povolení k vypouštění odpadních vod s obsahem zvlášť nebezpečné závadné látky do kanalizace nebo o jeho změnu

  • Žádost o udělení souhlasu

  • Žádost o vyjádření

  • Žádost o vydání kolaudačního souhlasu k užívání vodního díla

  • Oznámení o užívání stavby vodního díla

  • Ohlášení

  • Žádost o povolení k odběru podzemních vod pro potřeby jednotlivých občanů (domácností) a o stavební povolení ke studni nebo jinému vodnímu dílu potřebnému k takovému odběru

  • Žádost o povolení k vypouštění odpadních vod do vod povrchových pro potřeby jednotlivých občanů (domácností) a o stavební povolení k domovní čistírně odpadních vod potřebné k takovému vypouštění

  • Žádost o povolení k vypouštění odpadních vod do vod podzemních pro potřeby jednotlivých občanů (domácností) a o stavební povolení k domovní čistírně odpadních vod potřebné k takovému vypouštění

  • Ohlášení vodních děl určených pro čištění odpadních vod do kapacity 50 ekvivalentních obyvatel


4

Ostatní agendy

  • Rezervace lokality pro svatební obřad

  • Žádost o povolení uzavřít manželství na stanoveném místě mimo stanovenou dobu

  • Žádost o povolení uzavřít manželství na kterémkoli vhodném místě

  • Žádost snoubenců o povolení uzavřít manželství

  • Žádost o vysvědčení o právní způsobilosti k uzavření manželství

  • Žádost o vydání osvědčení – církevní sňatek

  • Žádost o povolení změny příjmení rodiny za trvání manželství

  • Prohlášení o volbě druhého jména

  • Prohlášení o změně užívání příjmení

  • Žádost o zápis příjmení v mužském tvaru

  • Žádost o povolení změny jména – příjmení dítěte

  • Žádost o povolení změny jména – příjmení dospělí

  • Žádost o vydání matričního dokladu

  • Žádost o vydání opisu matričního dokladu

  • Žádost o doslovný výpis z matriční knihy narození, manželství, úmrtí


Agendy v samostatné působnosti

5

Agendy v samostatné působnosti:

  • Přihláška k místnímu poplatku za komunální odpad – trvalý pobyt, dospělý, společný zástupce

  • Přihláška k místnímu poplatku za komunální odpad – chataři

  • Žádost o změnu v evidenci komunální odpad

  • Žádost o snížení výše poplatku

  • Přiznání místního poplatku za psa

  • Odhlášení poplatku za psa

  • Přiznání místního poplatku za užívání veřejného prostranství

  • Registrace k místnímu poplatku z ubytovací kapacity

  • Hlášení k místnímu poplatku z ubytovací kapacity

  • Žádost o poskytnutí dotace pro oblast kultury, sportu a sociální oblast

  • Žádost o poskytnutí daru pro oblast kultury, sportu a sociální oblast

  • Vyúčtování poskytnuté dotace, daru

  • Formuláře ke správě bytové agendy

  • Přihláška ke směně bytů

  • Oznámení o změně počtu osob, které společně s nájemcem užívají byt

  • Žádost o nájem obecního bytu

  • Žádost o potvrzení přechodu užívacího práva k bytu

  • Žádost o odstranění závady v obecním bytě

  • Dotazník ke zjištění státního občanství České republiky


Interní aplikace a procesy

6

Žádost o služební mobilní telefon (SIM kartu)


7

Návrhy na mimořádné odměny, na úpravu platu a dalších min. 5 formulářů dle konkrétního zadání


8

Cestovní příkaz s vazbou na rezervaci vozidel

  • Žádost o povolení služební cesty, následného vyúčtování cesty, včetně schvalovacích procesů


9

Cestovní příkaz do zahraničí

  • Žádost o povolení zahraniční služební cesty, následného vyúčtování cesty, včetně schvalovacích procesů


10

Evidence smluv s vazbou na ISRS

  • Nástroj na evidenci smluvních dokumentů včetně automatizovaného odesílání požadovaných smluv na Centrální registr smluv

  • Integrace na MS NAV Navision (uživatel nesmí být nucen zadávat data dvakrát)


11

Aplikace pro elektronizaci jednání rady a zastupitelstva města

  • Řešení pro elektronizaci materiálů pro jednání, včetně jejich schvalování, tvorba programu, zápisu a usnesení, vazba na úkoly




Pol.

Nástroj pro práci s pdf dokumenty

Návrh řešení splňuje (ANO x NE)

1

Systém musí splňovat legislativní požadavky v rámci eIDAS.


2

Konverze dokumentů do archivního formátu PDF/A, včetně archivního formátu PDF/A-3


3

Práce s dokumenty podle standardů PAdES, XAdES, CAdES a ASiC dle požadavků Evropského nařízení 910/2014 (eIDAS).


4

Autorizace dokumentů PDF, MS Office, OpenOffice pomocí el. podpisu a časového razítka v prostředí aplikace.


5

Ověření validity autorizovaných PDF dokumentů přímo vůči certifikačním autoritám minimálně z celé EU, s možností vytvoření validační doložky.


6

Přidání / odebrání stránek v PDF dokumentu.


7

Otáčení stránek v PDF souboru.


8

Možnost opatření obrazových PDF souborů strojově čitelnou vrstvou (OCR).


9

Anonymizace dat v PDF dokumentech.


10

Archivní snímek webových stránek.


11

Možnost editace metadat.


12

Zprostředkování výše uvedených služeb i pro jiné AIS používané na úřadu pomocí webových služeb.




    1. Portál úředníka

Portál úředníka bude navržen jako prostor pro úředníky (případně v budoucnu pro zřizované organizace) pro interní využití, s důrazem na jednoduchost a modulárnost (portál bude připraven tak, aby bylo možné v budoucnu připojovat další moduly). Jako základ jsou využity moduly typu sdílené úložiště dokumentů a pracovní prostory, nativní provázanost na elektronické workflow (formuláře a schvalovací procesy nad nimi), inteligentní telefonní seznam, detail uživatele a komunikační prostředí pro týmovou práci. Dále bude sloužit jako sjednocující prostředí pro interní zaměstnance úřadu.

Pol.

Portál úředníka

Návrh řešení splňuje (ANO x NE)

1

Portál úředníka zajistí přístup k informacím a agendám dle přesně definovaných rolí.


2

Rozcestník na všechny hlavní agendy úřadu s řešením automatickým přihlášením do aplikace (aplikační menu).


3

Aplikační menu umožňuje uvést odkazy na webové a exe aplikace, MS Office.


4

Aplikace budou integrovány do Portálu úředníka dle následujícího schématu:

  • Navison

  • Inteligentní formuláře

  • Spisová služba ELIS

  • Agendio

  • VITA SW

  • Docházka


5

Aplikace budou přiřazovány uživatelům dynamicky dle loginu do Portálu. Současně k některým z nich bude uživatel Portálu přistupovat s využitím Singl Sign ON. Uživatel se tak již nebude muset hlásit k uvedeným agendám a aplikacím:

  • Xxxxxxx

  • Xxxxxxx služba ELIS (CNS)

  • Inteligentní formuláře

  • Navision

  • VITA SW


6

Dostupnost vzorů dokumentů a směrnic s historii verzování.


7

Detailní výstup z hlavních agend úřadu.


8

Detailní zobrazení individuálních informací u přihlášeného úředníka (výstup dat z hlavních agend úřadu: docházka, personální systém, ekonomický systém).


9

Integrace s inteligentními formuláři s automatickým přihlášením.


10

Organizační struktura / Chytrý telefonní seznam:

  • Organizační struktura bude online získávána ze zdroje identit. Jednotlivé odkazy budou fungovat jako funkční odkazy do nižších úrovní. Konečnou úrovní bude „karta úředníka“, jejíž obsah bude dynamicky plněn dle skutečného stavu a informace budou zobrazovány dle úrovně přístupových práv.

  • Zobrazení on-line dat z docházkového systému u každého uživatele.


11

Karta úředníka – jedná se o detailní pohled na zaměstnance v rámci organizační struktury úřady. Identita úředníka je vedena v IDM (EOS). Karta bude obsahovat minimálně tyto údaje:

  • Jméno, Příjmení, Tituly

  • Přihlašovací údaje

  • Zařazení v organizaci

  • Umístění (budova, kancelář)

  • Telefon

  • Mobil

  • Funkce

  • Informace z docházkového systému

  • Výpis majetku na konkrétního úředníka a u vedoucích pracovníků rozpad na jeho podřízené

  • A další – dle analýzy a definovaných požadavků


Požadavky na bezpečnost


Zabezpečení systému je dáno integrovaným auditním systémem portálu (identity musí být vedeny v IDM). Uvedený auditní systém musí zajišťovat:


12

Zabezpečený přístup do aplikace – musí být řízen prostřednictvím IDM.


13

Možnost definice neomezeného množství uživatelů.


14

Jednoduchá definice uživatelských práv k rubrikám a ke složkám dokumentů.


15

Auditování přístupů k jednotlivým článkům webu.


16

Existence akcí uživatele.


17

Skryté a zaheslované rubriky.


18

Pokročilá statistika přístupů.


Požadavky na redakční systém

19

Splňuje všechny požadavky jako redakční systém pro Portál občana


20

Definice menu: Možnost aplikačního menu a rychlého přehledu s napojením na hlavní agendy


Další požadavky

21

Dodavatel zajistí migraci dat ve struktuře podobné současnému Intranetu (stávající řešení vystavěno na MS Sharepoint 2003)


22

Portál úředníka zajistí minimálně integrace ze stávajících systémů na úrovni notifikací o úkolech s možností přímého otevření daného systému




    1. Řízení dokumentace (DMS) a dlouhodobý digitální archiv

DMS je nástroj pokrývající celý životní cyklus dokumentu, od vzniku přes elektronický oběh a schvalování až po archivaci a dlouhodobou archivaci vč. skartace zabezpečující řízený vznik dokumentů úřadu, jejich připomínkování, schválení a řízenou distribuci.

Pol.

Document Management System (DMS)

Návrh řešení splňuje (ANO x NE)

1

Základní požadavky na DMS:

  • zabezpečení dokumentů proti ztrátě

  • zabezpečení dokumentů proti jejich pozměňování

  • zabezpečení proti neoprávněnému přístupu

  • poskytnutí přístupu pouze oprávněnému

  • zajištění dlouhodobé digitální kontinuity dokumentů (LTV – long term validation)

  • zajištění dlouhodobé čitelnosti dokumentů (LTA – long term archiving)

  • legislativní soulad podle ETSI norem a ostatními právními předpisy ohledně archivace dokumentů

  • zajištění evidence dokumentu (evidence archivačních metadat + samotného dokumentu)

  • zajištění existence dokumentu i mimo samotný archiv (bez závislosti na archivu)

  • integrace na aplikace třetích stran – formou webových služeb

  • přístup k dokumentům pro aplikace třetích stran (formou odkazu, popř. pomocí webových služeb)

  • zajištění neměnné archivace dokumentů s auditním logováním operací

  • zajištění skartace dokumentů

  • snadné vyhledávání dat a dokumentů, včetně fulltextového

  • rozšiřující vlastnosti dlouhodobého digitálního archivu

  • možnost integrace dlouhodobého digitálního archivu s jinými IS prostřednictvím webových služeb


2

Evidence dokumentu musí zahrnovat minimálně:

  • Název dokumentu

  • Popis dokumentu

  • Opatření jednoznačnými identifikátory dokumentu

  • Opatření spisovými metadaty (spisový znak, skartační znak, skartační lhůta)

  • Opatření archivními metadaty dle Dublin Core Metadata Initiative

  • Uložení do struktury archivu


3

Automatizovaný vstup musí pokrýt:

  • příjem a zpracování dokumentů z jiných systémů s možností zapojení do evidenčního procesu s řízeným workflow nebo uložení do archivu

  • přenos ze skenovací linky s automatizovaným opatřením metadaty (např. dle typu dokumentů)


4

Distribuce dokumentu:

  • systém umožní nastavení a automatický průběh distribuce dokumentu mezi uživateli

  • systém umožní prokazatelné seznámení uživatelů s dokumentem

  • systém umožní řízení workflow / uživatelských oprávnění na základě přenosu z organizační struktury (Microsoft AD nebo PROXIO-EOS)

  • systém umožní distribuci dokumentu na nižší organizační složky

  • systém zajistí hlídání / evidenci celkového přehledu o distribuci dokumentu


5

Skartace

  • každý evidovaný dokument musí být opatřen metadaty, která mimo jiné říkají, jakou dobu je nutné dokument uchovávat a jaký je skartační znak

  • systém (archiv) hlídá dobu určenou u dokumentu a na pokyn oprávněného uživatele spouští skartační proces

  • skartační proces zahrnuje: rozřazení dokumentů dle skartačních znaků (A, V, S), rozhodnutí o dokumentech, u dokumentů označených „A“ nabídnutí Národnímu archivu (NA) a následné provedení exportu dokumentů do SIP balíčku určeného pro automatizovanou výměnu dokumentů, u dokumentů „A“ – odstranění z archivu se záznamem o postoupení NA, u dokumentů „S“ provedení skartace dokumentů, o skartačním řízení je proveden záznam, který se nadále uchovává


6

Dodaná aplikace musí minimálně umožnit / zajistit:

  • správu uživatelů, skupin a rolí – možnost jejich synchronizace s IDM (vč. AD) a organizační strukturou

  • řízení přístupových oprávnění – každý uživatel vidí pouze ta data, která odpovídají jeho přístupovým právům

  • workflow – definovatelné elektronické workflow dokumentů a dat v rámci organizace (možnost nastavení paralelního i sériového schvalování v jednom procesu)

  • možnost sdružování dokumentů do jednoho workflow

  • nastavení pravidel workflow

  • možnost (uživatelského) přednastavení scénářů workflow

  • hlídání lhůt – dokumentu je nastavena lhůta pro jeho vyřízení, systém upozorňuje na konec lhůty, v případě nedodržení lhůty systém problém eskaluje (e-mailové avízo)

  • zástup – v případě nepřítomnosti vyřizujícího pracovníka je možné automatické přidělení dokumentu zastupujícímu pracovníkovi

  • práce v týmech – umožňuje tvořit týmy pro zpracování příchozích dokumentů bez ohledu na jejich konkrétní přidělení (uživatel si dokument převezme a ostatní členové týmu vidí, že dokument je již zpracováván jiným členem týmu)

  • poskytování statistik

  • administrační činnosti, např. výměna pracovníků, nastavení schvalovacích pravidel daného procesu apod.


Bezpečnost

7

Systém musí umožnit přidělovat a řídit uživatelské přístupy a oprávnění:

  • rozhodnutí o přidělení a změně jsou schvalována připojením elektronického podpisu

  • pokud je to vhodné (například z hlediska závažnosti dokumentu) bude k podpisu připojeno také časové razítko;

  • identity uživatelů budou přebírány z IDM, případně pomocí protokolu LDAP z jiných systémů


8

Přístup anonymního uživatele:

  • systém umožní přístup k formulářům a jejich odesílání i těm uživatelům, kteří nemají uživatelský účet v systému

  • právo zpřístupnit některé formuláře anonymním uživatelům musí mít pouze administrátor systému


9

Přístup registrovaného uživatele

  • systém umožní vytvořit účet pro konkrétního uživatele a nastavit mu uživatelská oprávnění

  • přístup se může dít pomocí jména a hesla, může být zabezpečen elektronickým certifikátem, případně může být systém provázán se systémem pro správu identit


10

Administrátor musí mít možnost vidět seznam všech registrovaných uživatelů a vytvořit skupiny, přidělit uživatele do skupin a některým uživatelům přidělit roli správců skupin. To umožňuje zařadit do schvalovacího procesu nejen konkrétního uživatele, ale celou skupinu s tím, že schválit může kterýkoliv člen. Přístupová práva mohou být předělována nejen uživatelům, ale celým skupinám.


11

Vytváření skupin musí být možné automatizovat propojením s personálním informačním systémem, v němž je zanesena organizační struktura úřadu, nebo s IDM.

Systém musí administrátorovi umožnit vidět:

  • Stromovou strukturu složek

  • Název složky, a zda je ke složce umožněn přístup anonymním uživatelům

  • Vlastnosti složky

  • Práva uživatelů ke složce

  • Celkový přehled o momentálně přidělených právech


12

Administrátor může každému uživateli přidělit různé typy uživatelských oprávnění a procesní role.

Jeden a tentýž uživatel může mít různé role, podle konkrétního procesu.


13

Systém poskytne pro uživatele rozhraní formou webové aplikace. Přístup do webového rozhraní aplikace musí být chráněn:

  • přihlašovacím jménem a heslem,

  • přihlášením pomocí certifikátu,

  • přihlášením pomocí certifikátu, s použitím jména a hesla.

Každý přihlášený uživatel musí mít specifikovaný omezený rozsah práv a možností v rámci aplikace.


14

Na základě přihlášení do systému jsou na základě předem definovaných práv uživatele, či skupiny zpřístupněny odpovídající oblasti a možnosti nastavení aplikace DDA. Bez odpovídajících oprávnění není umožněn přístup do administračního prostředí systému.


15

Uživatel bez odpovídajícího oprávnění nesmí mít možnost jakkoliv ovlivnit, nahlédnout či změnit nastavení aplikace.


16

Veškerá komunikace může volitelně být zabezpečena pomocí protokolu HTTPS.


17

Systém musí disponovat vlastním zaznamenáváním a uchováváním aplikačních logů. Aplikační logy umožní minimálně kontrolovat činnost, kterou daný uživatel v prostředí systému provedl (nebo se pokoušel provést).


18

Systém musí disponovat vlastním zaznamenáváním a uchováváním auditních logů pro zaznamenání operací se záznamy.


19

Systém musí disponovat vlastním zaznamenáváním a uchováváním auditních logů pro zaznamenání operací v nastavení systému.


Využití elektronického podpisu a časového razítka

20

Systém musí pokrývat všechny funkce potřebné pro korektní vytváření elektronických originálů dokumentů a práci s nimi. To zahrnuje mimo jiné:

  • převod do PDF/A a dalších verzí formátu PDF

  • automatické a dávkové konverze dokumentů

  • úpravy dokumentů (spojování více dokumentů do jednoho, přidávání stránek apod.)

  • připojování elektronického podpisu a kvalifikovaného časového razítka (včetně snadného získání razítek)

  • ověřování platnosti elektronických podpisů a časových razítek


Soulad s legislativou

21

Systém musí být v souladu s legislativními požadavky na archivaci elektronických dokumentů (zákon 499/2004 Sb., zákon o archivnictví a spisové službě; vyhláška č. 259/2012 o podrobnostech výkonu spisové služby).


22

Systém musí být v souladu s Rozhodnutím Komise EU č. 2011/130/EU ze dne 25. 2. 2011, které navazuje na Směrnici 2006/123/ES o službách na vnitřním trhu


Další požadavky

23

Systém musí zajistit evidenci a zveřejnění smluv a objednávek města (viz požadavek na formulářové řešení) vč. zajištění integrace na MS NAV


24

Volitelný požadavek: Povinné vyplnění metadat před vložením dokumentu do DMS. Možnost hromadného nastavení metadat pro více dokumentů (např. pro smlouvy a jejich přílohy)


25

Součástí dodávky musí být podrobná nápověda (jako součást aplikace nebo jako samostatný dokument)




    1. Elektronizace jednání Rady a Zastupitelstva města

Součástí dodávky je aplikace pro úplnou elektronizaci jednání Rady a Zastupitelstva města. Cílem je implementace komplexní aplikace.

Pol.

Elektronizace jednání Rady a Zastupitelstva

Návrh řešení splňuje (ANO x NE)

1

Příprava materiálů pro jednotlivé typy jednání (Rada města / Zastupitelstvo města) včetně jejich schvalovacího procesu, schvalování možno variabilně nastavit -> buď pevně dané schvalovací kroky, nebo výběr lidí, kteří materiál musí schválit.


2

Příprava speciálních materiálů, tzv. hromadných materiálů (např. pronájem či prodej městského majetku, rozpočtová opatření) včetně schvalovacích procesů.


3

Možnost využívat šablony materiálů, materiál z předchozího již hotového materiálu a podobné možnosti pro ulehčení práce při tvorbě materiálů pro jednání.


4

Automatizované vytváření programu jednání, načítání materiálů pro jednání jedním tlačítkem.


5

Uvolňování programu pro jednání ve stanovené lhůtě přes jedno tlačítko. Automatické avízo mailem na všechny zúčastněné, že toto proběhlo a program jednání včetně materiálů a příloh je dostupný.


6

Mimořádné body/materiály k jednání je možno přidávat, jsou zvýrazněny barevně, jako mimořádné materiály. Jsou vidět v přehledu po dalším uvolnění programu jednání. Opětovná notifikace e-mailem na zúčastněné.


7

Automatizované vytváření zápisu z jednání se zachováním struktury z uvolněného programu jednání.


8

Automatizovaný vznik usnesení z daného jednání. Usnesení obsahuje pouze schválená / zamítnutá usnesení ve finálním znění.


9

Přímá vazba na přehled úkolů – úkoly z jednání RM/ZM pro jednotlivce či odbory, s jejich zpětnou kontrolou v přehledu plnění úkolů.


10

Možnost publikovat usnesení z jednání v pdf formátu přímo na webové stránky města.


11

Servisní funkce jako např. hromadný podpis / schválení materiálů, hromadný tisk materiálů včetně příloh, hromadné ukládání do off-line souborů, hlídání funkčních období.


12

Jako součást řešení i speciální archivní úložiště dokumentů z jednání RM/ZM -> poskytuje speciální přístupová práva k těmto dokumentům, která mohou být zcela jiné než v procesu vzniku dokumentů (např. hlídání funkčních období, fultextové vyhledávání v materiálech, programech a usneseních a další).


13

Řešení je možno variantně v budoucnu rozšířit i o jednání v komisích a výborech, porady vedení města apod.


14

Součástí dodávky musí být podrobná nápověda (jako součást aplikace nebo jako samostatný dokument) a instruktážní videa použití aplikace




    1. Service Desk

Součástí dodávky bude řešení Service Desk – jednotného systému pro komplexní správu servisních požadavků, a to zejména v oblastech IT, vnitřní chod úřadu (např. správa budov / majetku, správa vozového parku, personální problematika, jednotné kontaktní místo pro práci s občanem apod.).

Pol.

Service Desk

Návrh řešení splňuje (ANO x NE)

1

Licencování řešení neomezí přiřazení libovolného počtu uživatelů / zaměstnanců města do jakékoli role (např. zadavatel, řešitel, schvalovatel, manažer, operátor, administrátor, čtenář apod.).


2

Obecný nástroj pro sběr, řešení, správu a vyhodnocování problémů a požadavků.


3

Zadavatel požaduje možnost zapojení externích dodavatelů služeb do systému – systém musí obsahovat vlastní databázi uživatelů, kde bude možno zadávat přístupová práva do aplikace pro tyto externí dodavatele služeb, aby mohli v systému plnohodnotně pracovat NEBO bude systém provázán s IDM (Proxio-EOS), který bude plně využívat a identitu uživatelů povede v IDM.

Volitelný požadavek: Ověření identity z více zdrojů (lokální databáze, IDM, LDAP apod.).


4

Licencování řešení neomezí řešení požadavků od anonymních žadatelů, které přichází od uživatelů (zaměstnanců PO, občanů města apod.) neregistrovaných v systému.


5

Zadávání požadavků se strukturovanými údaji (definovatelné formuláře).


6

V případě, že anonymní uživatel na tento e-mail odpoví nebo pošle doplňující zprávu jako odpověď na e-mail dle předchozího bodu, musí být tato zpráva přiřazena k již existujícímu založenému požadavku.


7

Chování požadavku řízeno workflow.


8

Z uživatelského pohledu se musí vycházet ze stromové organizační struktury členěné dle jednotlivých oblastí – samostatný strom pro požadavky směřující na každou oblast (např. IT, Správa budov, Správa vozového parku, Personální problematika, Chod úřadu, Správa silnic, komunikací a obecní infrastruktury, Komunikace s občany apod.).


9

Celý katalog služeb musí být uživatelům přístupný na portálu a pro každou službu musí být připravena na portálu samostatná ikona nebo dlaždice s názorným a přehledným piktogramem pro maximální zpřehlednění katalogu. Před vlastním spuštěním akce (kliknutí na ikonu nebo dlaždici dané služby) se musí automaticky zobrazit nápověda podrobně popisující tuto službu.


10

Zadavatel požaduje možnost uživatelsky definovat, rozšiřovat a modifikovat portál minimálně na úrovni kategorií požadavků a jejich popisů, báze znalostí a publikování zpráv.


11

Integrace s externími systémy pomocí webových služeb.


12

Uživateli se musí zobrazit pouze ty požadavky, které má řešit.


13

Systém musí umožnit / podporovat kategorizaci požadavků.


14

Systém musí umožnit administrátorské nastavování procesů – workflow.


15

Požadována možnost nastavení pracovní doby řešitelů systému tak, aby se od této pracovní doby odvozovaly reakční doby.


16

Zadavatel požaduje možnost zobrazení workflow jednotlivých stavů a přechodů mezi stavy.


17

Počet použitých služeb a kategorií katalogu služeb a jeho úpravy není nijak omezen zakoupenou licencí.


18

Systém musí umožnit rezervaci objektů (zasedací místnosti, vozidla, technika).


19

Systém musí umožnit přidávání komentářů k požadavku.


20

Pro každou službu musí být možno plně definovat vstupní zadávací formulář včetně vlastních uživatelských položek.


21

Je požadováno, aby k požadavku bylo možno přímo ze vstupního formuláře připojit přílohu.


22

Pro každou službu musí být možno plně definovat workflow.


23

Každý uživatel si může definovat vlastní pohledy a filtry nad požadavky.


24

Systém musí obsahovat možnost fulltextového vyhledávání nad všemi informacemi.


25

Administrátorsky definovatelné schvalovací workflow. Napojení na IDM pro načtení skupin či uživatelů.


26

Evidence hardware a software.


27

Integrované přihlašování a ověřování do Service Desku pomocí AD nebo IDM Proxio-EOS.


28

Automatické načítání organizační struktury a oprávněných uživatelů z IDM.


29

Zobrazení kompletní historie procesu.


30

Hlídání časových limitů, informování při překročení času.




    1. Vedení žádostí dle zákona č. 106/1999 Sb.

Pol.


Návrh řešení splňuje (ANO x NE)

1

Evidovat informace o žádostech o poskytování informací a stížnostech, včetně subjektů.


2

Na základě žádosti evidované v SPPI založit nový případ.


3

Evidovat procesní průběh řešení případu, včetně úkonů, lhůt, jejich hlídání, upozornění na lhůty z úkonů vyplývajících.


4

Dle typu případu k němu evidovat speciální údaje.


5

Možnost konfigurace jednotlivých úkonů, které nejsou dané legislativou, ale interními předpisy.


6

Automatické generování výroční zprávy v souladu s požadavky zákona č. 106/1999 Sb.


7

Formuláře / šablony dle potřeb města s automatickým předvyplněním údajů a metadat


8

Automatické přednabízení možných navazujících kroků dle typu úkonu


9

Automatické zveřejňování poskytnutých informací na webových stránkách města




    1. OBLAST SPRÁVNÍCH AGEND

      1. Obecné požadavky

Pol.

Obecné požadavky na oblast správních řízení

Návrh řešení splňuje (ANO x NE)

1

Vazba na centrální Evidenci subjektů.

Všechny subjekty vystupujících v řízeních (účastníci řízení, dotčené orgány, ostatní) budou vedeni v centrální Evidenci subjektů v roli odpovídající zpracovávané agendě. Při pořízení subjektu do řízení bude možné ověřit subjekt v Evidenci subjektů a v Základních registrech.

Integrace bude realizována formou volání rozhraní, které je realizované technologií webových služeb (SOAP).




      1. Sociální oblast

Podpora agend v oblasti evidence klientů sociálního pracovníka včetně klientů s pečovatelskou službou poskytovanou u nich v domácnosti, opatrovnictví fyzické osoby, zvláštního příjemce dávky důchodového pojištění, stanovení úhrad za stravu a péči, vydání parkovacích průkazů ZPO, žádosti o byt, evidence osob ve VV a VTOS, dále vedení agendy sociálně právní ochrany dětí (SPOD) v souladu se zákonem č. 359/1999 Sb. v platném znění (dále jako Zákon), včetně následných změn, a dále v souladu se směrnicí MPSV čj. 2013/26780-21 (dále jako Instrukce) a v souladu se zákonem č. 218/2003 Sb., o soudnictví ve věcech mládeže a dalšími souvisejícími právními předpisy.



Oblast SPOD:

Pol.

Požadavky na Sociální oblast - SPOD

Návrh řešení splňuje (ANO x NE)

1

Kompletní evidence agend Rejstřík Om, Nom, A, P, EV, PPD, OP a Podnětů.


2

Automatické generování značky Om, Nom, A, P, EV, PPD, OP a Podnětů.


3

Centralizovaná evidence dětí, jejich rodičů a dalších subjektů, se kterými je v souvislosti s agendou SPOD jednáno (např. škola, lékař, …), zajišťující jednotný přístup k subjektům a elektronické vedení spisové dokumentace. Možnost evidovat neznámý subjekt (např. nenarozené dítě těhotné mladistvé matky)


4

Evidence adresy faktického pobytu dítěte, kromě adresy trvalého pobytu a doručovací adresy zákonných zástupců


5

V Rejstříku Om vedení pomocných rejstříků k jednotlivým dětem, evidence dětí žijících/nežijících ve společné domácnosti


6

Vazba mezi souvisejícími případy, jak v rámci jednoho rejstříku, zejména Om, tak i mezi ostatními případy.


7

Vedení úkonů – jednotlivých kroků péče o dítě, jejich evidence, vedení informací a tvorba dokumentů k těmto krokům.


8

Plánování a evidování úkolů v péči o dítě a jeho rodinu.


9

Evidence stanoviska komise k SPOD.


10

Evidence umístění rodiče s dítětem do ubytovny, azylového zařízení a evidence smlouvy.


11

Vedení správních řízení, která jsou řešena v souladu se zákonem (dohled, napomenutí, omezení, …).


12

Nabídka šablon typů dokumentů k jednotlivým úkonům péče o dítě (např. návrhy na předběžné opatření, plánování, vyhodnocování apod.).


13

Využití filtrů a vyhledávacích kritérií, přehledů nad evidencí. Možnost exportu dat mimo systém, např. do formátu XLS.


14

Tvorba dokumentů na základě zaevidovaných údajů podle předdefinovaných šablon, s možností úprav přímo ve vygenerovaném dokumentu


Tiskové sestavy

15

Záznam o vyhodnocení situace dítěte a jeho rodiny


16

Individuální plán ochrany dítěte


17

Přehledy Rejstřík Om, NOM, A, P, EV, PPD, OP, pomocné evidence


18

Jmenná kartotéka, Spisový obal, Spisový přehled atd.


Další požadavky

19

Vyhledávání – základní nabídka – klienti jednotlivých pracovníků + složka s odkazem na vyhledávání ze všech klientů SPOD (dle jména a data narození – vyhledání z Om, Nom, podnětů i archivu).


20

Vkládání různých dokumentů k případu (skeny, kopie, dokumenty, fotky…) a možnost soubory z programu stáhnout, či otevřít.


21

Generování čísla Om, Nom a podnětu programem; zabezpečení rizika duplicity spisů + propojování spisů (př. ukončený podnět do Om, vyřazené Om do nového Om).


22

Úprava a obsah v souladu se zákonem SPOD a Směrnicí MPSV (evidenční štítek Om, rejstříky, spisová dokumentace Om a nom) + evidence podnětů (jednorázovky, které po prošetření nejsou zhodnoceny jako SPOD).


23

Archivace spisů – vyhledávání archivovaných spisů, možnost opětovného vstupu + připojení po spojení s novým spisem, přístup k historii ve vedení spisu a v historii vstupů do spisu při převodu na jiného pracovníka.


24

Přetažení aktivních spisů Om ze stávajícího programu, sloučení se založenými spisy v SSL, možnost připojení vlastních v elektronické podobě dosud vytvořených podkladů k spisům Om, které budou převedeny.


25

Centralizovaná evidence agendy sociálně-právní ochrany dětí a souvisejících podnětů, jednotná evidenční a spisová oblast.


26

Kompletní evidence spisů Om, Nom a Podnětů a propojování těchto spisů.


27

Kompletní vedení rejstříků.


28

Evidence údajů, dokumentace jednotlivých subjektů (vytvořená v programu a vytvořená mimo program – ne v PDF) a úkonů.


29

Tvorba dokumentů a editovatelných šablon.


30

Uživatelsky přívětivé prostředí, které zajistí zpracování velkého množství dat v různých oblastech a v jednotlivých kritériích jejich třídění.


31

Propojení programu se SSL.


32

Propojení programu se základními registry (ztotožnění dítěte, jeho zákonných zástupců).


33

Automatické hlídání všech zákonných lhůt dle jednotlivých kroků v řízení, upozornění uživateli před koncem lhůty.


34

Zákonem stanovené šablony, možnost tvorby a editace vlastních šablon s náplní dat z programu přímo do dokumentu.


35

Evidence dokumentů vytvořených aplikací i mimo aplikaci (možnost vložení dokumentů souvisejících s daným případem/klientem).


36

Evidence úkolů pracovníka (upozornění na splnění úkolu přímo aplikací nebo zasláním upozorňujícího e-mailu).


37

Možnost archivace dat a následné skartace (výmazu).


38

Uživatelské přístupy do aplikace (aby bylo zaznamenáno, kdo jaké informace zadal, editoval) ošetření zastupování, druhy oprávnění – prohlížení, editace, včetně historie těchto jednotlivých přístupů.


39

Možnost nastavovat a editovat šablony pro tisk pomocí práce s datovými větami, respektive „propojů do databáze“, mít možnost zařadit je do seznamu (výběru) v aplikaci.


40

Nastavení a tisk adres na obálky.


41

Možnost nastavení filtrů dle jednotlivých údajů (vstupních dat) a export do Excelové tabulky ve struktuře, která umožní další práci s daty.


42

Statistika, výkaznictví, automatická hlášení (úkoly, nutné úkony, varování), export do Excelové tabulky ve struktuře, která umožní další práci s daty.




Ostatní sociální agendy mimo SPOD:

Pol.

Požadavky na Sociální oblast (kromě SPOD)

Návrh řešení splňuje (ANO x NE)

Evidence osob ve výkonu vazby a výkonu trestu odnětí svobody

1

Centrální evidence osob ve výkonu vazby a výkonu trestu, evidence údajů o osobách a dalších subjektech v případu (zařízení atp.)


2

Evidence údajů o výkonu vazby/trestu


3

Vedení úkonů – jednotlivých kroků v práci s klientem, jejich evidence, a tvorba dokumentů k těmto krokům


Zajištění důstojného pohřbení dle vyhlášky Ministerstva pro místní rozvoj č. 277/2017 Sb., o postupu obce při zajištění slušného pohřbení

4

Evidence a průběh procesu zajištění slušného pohřbení


5

Evidence údajů o sociálním pohřbu, o procesu slušného pohřbení


6

Evidence všech nákladů pohřbu, včetně vymáhání na dědicích nebo uplatněním u Ministerstva pro místní rozvoj ČR (MMR)


7

Vedení úkonů – jednotlivých kroků v práci s klientem, jejich evidence, a tvorba dokumentů k těmto krokům


Evidence klientů sociálního pracovníka

8

Centrální evidence klientů sociálního pracovníka, evidence údajů o osobách a dalších subjektech (poskytovatel sociální služby atp.)


9

Evidence informací o poskytnuté pomoci jednotlivým klientu, o rozdělení klientů do cílových skupin a o pomoci poskytované sociálními pracovníky


10

Vedení úkonů – jednotlivých kroků v práci s klientem, jejich evidence, a tvorba dokumentů k těmto krokům


Opatrovnictví fyzické osoby

11

Centrální evidence osob, kterým je úřad ustanoven opatrovníkem, evidence dalších subjektů (plátce, příjemce, zdravotnické zařízení atp.)


12

Evidence dalších údajů o opatrovaných osobách, o poskytované pomoci sociálními pracovníky


13

Schvalování výdeje a evidence peněz opatrované osoby, včetně zajišťování úhrady nezbytných životních nákladů


14

Vedení úkonů – jednotlivých kroků v práci s klientem, jejich evidence, a tvorba dokumentů k těmto krokům


Zvláštní příjemce dávky důchodového pojištění

15

Centrální evidence žádostí o ustanovení zvláštního příjemce dávky ve správním řízení.


16

Nástroje pro kontroly chování zvláštního příjemce a v případě zjištění závažných pochybení nástroje pro odejmutí dávek.


17

Nástroje pro komunikace s ČSSZ, kdy úřad o svém rozhodnutí informuje ČSSZ.


18

Vedení úkonů – jednotlivých kroků v procesu zpracování žádosti a tvorba dokumentů k těmto krokům


Stanovení úhrad za stravu a péči

19

Centrální evidence žádostí o stanovení výše úhrady za stravu a péči, v případě, že je dítě umístěno do domova pro osoby se zdravotním postižením na základě rozhodnutí soudu o nařízené ústavní výchově, výchovném opatření nebo předběžném opatření ve správním řízení


20

Přehled o žádostech o stanovení výše úhrady za stravu a za péči, k dispozici jsou potřebné úkony dle správního řádu.


Vydání parkovacích průkazů zdravotně postiženým osobám (ZPO)

21

Centrální evidence žádostí o vydání parkovacího průkazu ZPO, evidenci platnosti průkazu ZTP nebo ZTP/P a evidenci vydávaných parkovacích průkazů. Musí se jednat i o vydání označníku O2 pro osoby se sluchovým postižením.


Tiskové sestavy

22

Tvorba dokumentů na základě zaevidovaných údajů podle předdefinovaných šablon, s možností úprav přímo ve vygenerovaném dokumentu


23

Podklady pro předepsanou statistiku (Roční výkaz sociálního pracovníka), přehledy a statistiky.


24

Parkovací průkaz pro zdravotně postiženou osobu


25

Sestava finančních prostředků za opatrovance úřadu


Další požadavky

26

Migrace dat ze stávajícího programu OM (Solař), migrace polostrukturované databáze Excelu.


27

Stahování datových zpráv ze SSL.


28

Možnost anti-datovat založení karty dítěte a spisu, zakládání spisů do předchozích let.


29

Automatické hlídání všech zákonných lhůt dle jednotlivých kroků v řízení, upozornění uživateli před koncem lhůty.


30

Při řízení spisu mít možnost upravit datum provedení šetření, návštěvy DD, provedení pohovoru atd. I zpětně. Současně možnost návratu k hotovému případu, aby při dodatečném zjištění podstatných informací bylo možné spis doplnit.


31

Možnost nastavit oprávnění tak, aby na konkrétním jednom případu mohlo pracovat více pracovníků najednou, i z jiných oddělení OSPOD ve stejnou dobu.


32

U všech jednotlivých modulů zajistit možnost napojení na ZR (ROB, XXXXX, …), a rejstříky MPSV pod konkrétními agendami a rolemi.


33

Možnost generování a tisku statistických sestav a údajů (vč. ročních a měsíčních) statistik, možnost konfigurace a tisku variabilních šablon.


    1. Koordinované stanovisko

Komplexní podpora činností dotčeného orgánu při vydávání koordinovaného závazného stanoviska, koordinovaného stanoviska a společného vyjádření při ochraně veřejných zájmů na úseku ochrany přírody a krajiny, ochrany ovzduší, odpadového hospodářství, ochrany lesa, ochrany zemědělského půdního fondu, ochrany vod, dopravy na pozemních komunikacích, památkové péče, civilní ochrany a územního plánování.

Podstatné je, aby proces vydávání koordinovaných závazných stanovisek a tvorba jednotlivých dokumentů souvisejících s koordinovanými stanovisky byl v souladu se zákonem č. 183/2006 Sb., o územním plánování a stavebním řádu, ve znění pozdějších předpisů, a zákonem č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů (dále jen „správní řád“). Např. vyhotovit výzvu k předložení dokladů, usnesení o prodloužení lhůty k předložení dokladů apod. v souladu se správním řádem).

Pol.


Návrh řešení splňuje (ANO x NE)

1

Komplexní podpora činností dotčeného orgánu při vydávání koordinovaného závazného stanoviska, koordinovaného stanoviska a společného vyjádření při ochraně veřejných zájmů.


2

Centrální evidence žádostí o vydání koordinovaného stanoviska.


3

Vedení úkonů – evidence vyjádření (závazných stanovisek) za jednotlivé útvary.


4

Tvorba dokumentů na základě zaevidovaných údajů podle předdefinovaných šablon, s možností úprav přímo ve vygenerovaném dokumentu, sestavení jednotlivých stanovisek do jednoho dokumentu.


5

Účinnost na úseku ochrany přírody a krajiny, ochrany ovzduší, odpadového hospodářství, ochrany lesa, ochrany zemědělského půdního fondu, ochrany vod, dopravy na pozemních komunikacích, památkové péče, civilní ochrany a územního plánování.




    1. Dopravní agendy

Podpora agend a činností podle zákona o silniční dopravě (taxislužba, veřejná autobusová doprava), zákona o drahách, zákona o získávání a zdokonalování odborné způsobilosti k řízení motorových vozidel (autoškoly) a zákona o podmínkách provozu vozidel na pozemních komunikacích (stanice měření emisí, schvalování silničních vozidel) a přestupkového zákona.

Pol.

Požadavky na Dopravní agendy

Návrh řešení splňuje (ANO x NE)

1

Veškeré případy spadající do dopravních agend (dále také "DA") jsou vedeny dle zákona č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů, pokud speciální právní předpis nestanoví jinak.


2

V agendě DA budou k dispozici sestavy a tiskové výstupy týkající se řízení (statistiky činností apod.).


3

U subjektu bude možná veškerá evidence kontaktních adres a jiných doplňujících údajů. Aplikace umožní dotažení souvisejících údajů k objektu, tzn. údaje o sousedních objektech, vlastnících objektu a vlastnících sousedních objektů.


4

U řízení bude možné evidovat konkrétní údaje o pozemní komunikaci, trasy, vozidle, evidenčních číslech, dopravním značení, období a případně další.


5

Agenda umožní evidenci jednotlivých procesních úkonů a vytváření dokumentů s dotažením evidovaných dat v agendě na základě konfigurovatelné šablony. Mimo generované dokumenty bude možné k řízení evidovat i další dokumentaci včetně fotodokumentace. Takto vytvořené nebo jen vložené dokumenty bude možné elektronicky podepsat a odesílat k vypravení do spisové služby. Vazba (integrace) na spisovou službu bude společná pro celý IS.


6

Bude zde možné konfigurovat kontrolu lhůt a termínů dle platné legislativy či metodiky úřadu. Bude možné například sledovat lhůty a termíny pro vydání rozhodnutí. Lhůty a termíny bude možné uživateli oznamovat formou aplikačního hlášení nebo emailového upozornění.


7

V agendě bude možné provázat související případy, např. osvědčení k provozování stanice měření emisí a změna osvědčení k provozování stanice měření emisí z centrálního informačního systému, tzv. CIS.


8

Evidenci řízení bude možné prohledávat a filtrovat dle volitelných kritérií uživatele, a to na základě evidovaných údajů, např. dle názvu typu komunikace, názvu typu kategorie atd. Dohledaná řízení bude možné zobrazit v seznamu či v detailním pohledu dle jednotlivých případů. Na základě dohledaných dat bude možné generovat tiskové sestavy včetně výběru položek k zobrazení a následně tisku.


9

Změny v údajích evidence řízení budou automaticky zaznamenány spolu s časem a uživatelem, který změnu provedl. Systém umožní provést archivaci řízení… Každý případ má evidován svůj stav (evidováno, odloženo, postoupeno, projednáváno, přerušeno, zamítnuto, zastaveno, rozhodnuto, vyřízeno apod.) včetně informace o „vyřízení“, případně konečné archivace případu.


10

Podpora řízení dle zákona o kontrole (kontrolní řád 255/2012 Sb. – výkon státního dozoru), a Zákona o odpovědnosti za přestupky a řízení o nich 250/2016 Sb. (Přestupky provozovatelů autoškol).


11

Napojení na ISZR a možnost lustrování provozovatelů autoškol (osoby právnické, a fyzické podnikající), možnost dotahování informací z ROS.


12

Nastavení možnosti tisku potvrzení a přednastavené standardizované šablony (např. Registrační listina k provozování autoškoly, Podmínky provozování autoškoly, …).


13

Řešená přestupková řízení v odborných agendách mimo zákon o provozu na pozemních komunikacích bude možné transformovat do účetního programu pro evidence pohledávek.


    1. Životní prostředí

Agendový systém musí Odboru životního prostředí umožňovat minimálně následující dle platné legislativy:

  • Napojení na současný Agendový systém, propojení s dalšími informačními systémy úřadu (a to především s návazností na Portál úředníka a Portál občana)

  • Ověření dat a subjektů vazbou na základní registry

Agenda ŽP zahrne následující oblasti, dle platné legislativy:

  • Odpady (Zákon č. 185/2001 Sb., o odpadech, zákon č. 477/2001 Sb., o obalech)

  • Ochrana ovzduší (Zákon č. 201/2012 Sb., o ochraně ovzduší)

  • Ochrana vod (Zákon č. 254/2001 Sb., o vodách)

  • Zákon č. 183/2006 Sb. (stavební zákon)

  • Zákon č. 274/2001 Sb. (zákon o vodovodech a kanalizacích)

  • Ochrana přírody a krajiny (Zákon č. 114/1992 Sb., o ochraně přírody a krajiny)

  • Xxxx, myslivost a rybářství (Zákon č. 99/2004 Sb., o rybníkářství, výkonu rybářského práva, rybářské stráži, ochraně mořských rybolovných zdrojů a o změně některých zákonů (zákon o rybářství), zákon č. 449/2001 Sb., o myslivosti, zákon č. 289/1995 Sb., o lesích)

  • Zemědělský půdní fond (Zákon č. 334/1992 Sb., o ochraně zemědělského půdního fondu)

  • Veterinární péče, rostlinolékařské péče a ochrany zvířat (Zákon č. 166/1999 Sb., o veterinární péči,

  • zákon č. 246/1992 Sb., na ochranu zvířat proti týrání, zákon č. 115/2000 Sb., o poskytování náhrad škod způsobených vybranými zvláště chráněnými živočichy, zákon č. 326/2004 Sb., o rostlinolékařské péči)

  • Lovecké a rybářské lístky (Zákon č. 99/2004 Sb., o rybníkářství, výkonu rybářského práva, rybářské stráži, ochraně mořských rybolovných zdrojů a o změně některých zákonů (zákon o rybářství), zákon č. 449/2001 Sb., o myslivosti)

  • Poskytování informací o životním prostředí, EIA, IPPC (Zákon č. 100/2001 Sb., o posuzování vlivů na životní prostředí, zákon č. 76/2002 Sb., o integrované prevenci)

  • Zákon č. 123/1998 Sb., Zákon o právu na informace o životním prostředí

  • Zákon č. 252/1997 Sb., o zemědělství (agenda zemědělských živností)

Pol.

Požadavky na Životní prostředí

Návrh řešení splňuje (ANO x NE)

1

V řízení, kde toto vyplývá z povahy věci, bude umožněno evidovat speciální údaje. Např. informace o kácení a výsadbě, rybářských a loveckých lístcích, odpadech, odnětí pozemků, průkazech a licencích apod.).


2

K dispozici jsou typy případů, které umožňují vkládat prostřednictvím úkonů vyjádření jednotlivých oddělení na úseku ŽP a poté tato vyjádření automaticky vkládat do souhrnného vyjádření (sdělení, stanoviska).


3

Oblast Odpady umožňuje evidenci řízení dle zákona č. 185/2001 Sb., o odpadech. (vyjádření, stanoviska, závazná stanoviska, souhlasy, zákazy činnosti, uložení povinnosti a další).


4

Oblast Ochrana ovzduší umožňuje evidenci řízení dle zákona č. 201/2012 Sb., o ochraně ovzduší (vyjádření, opatření k nápravě, závazná stanoviska, povinnosti provozovatele stacionárního zdroje a další).


5

Oblast Ochrana přírody a krajiny umožňuje evidenci řízení dle zákona č. 114/1992 Sb., o ochraně přírody a krajiny. K dispozici jsou zde speciální evidence, které umožňují zaevidovat data např. o kácení a výsadbě dřevin, dotčených a sousedních pozemcích a také přehled dřevin uvedených v jednotlivých řízeních. V přehledných evidencích je možné si zobrazit např. přehled všech dřevin (výsadba i kácení) uvedených v jednotlivých řízeních.


6

Oblast Lesy, myslivost a rybářství umožňuje evidenci řízení dle zákona č. 99/2004 Sb., o rybníkářství, výkonu rybářského práva, rybářské stráži, ochraně mořských rybolovných zdrojů a o změně některých zákonů (zákon o rybářství), zákona č. 449/2001 Sb., o myslivosti a zákon č. 289/1995 Sb., o lesích. K dispozici jsou speciální evidence, které umožňují zaevidovat data např. o průkazech rybářské a myslivecké stráže, mysliveckého hospodáře, o honitbách apod. Tyto údaje pak lze jednoduše zobrazit v přehledných evidencích.


7

Oblast Zemědělský půdní fond umožňuje evidenci řízení dle zákona č. 334/1992 Sb., o ochraně zemědělského půdního fondu. Zde je možné zaevidovat i speciální údaje např. o pozemcích určených k funkci lesa, zemědělském půdním fondu, pozemcích apod.


8

Součástí agendy Zemědělský půdní fond je automatické generování ročních výkazů:

  • odnětí a o poplatcích za odnětí pozemků určených k plnění funkcí lesů podle lesního zákona,

  • odnětí a o odvodech za odnětí půdy ze zemědělského půdního fondu podle zákona o ochraně zemědělského půdního fondu.


9

Oblast Veterinární péče, rostlinolékařské péče a ochrany zvířat umožňuje evidenci řízení dle zákona č. 166/1999 Sb., o veterinární péči, zákona č. 246/1992 Sb., na ochranu zvířat proti týrání, zákona č. 115/2000 Sb., o poskytování náhrad škod způsobených vybranými zvláště chráněnými živočichy a zákona č. 326/2004 Sb., o rostlinolékařské péči).

Pozn.: Jedná se např. o řízení ohledně povolení konání trhů a svodů zvířat, péče o týraná zvířata, náhradu škody způsobené zvířetem, ohlášení, zajištění a omezení výskytu škodlivých organismů.


10

Oblast Lovecké a rybářské lístky umožňuje evidenci řízení dle § 13 zákona č. 99/2004 Sb., zákon o rybníkářství, výkonu rybářského práva, rybářské stráži, ochraně mořských rybolovných zdrojů a o změně některých zákonů (zákon o rybářství) a § 47 zákona č. 449/2001 Sb., o myslivosti. Umožňuje z evidovaných údajů vydat a vytisknout rybářský a lovecký lístek dle zákona a ve standardizované šabloně.


11

Agenda umožňuje evidenci údajů o rybářských a loveckých lístcích, zobrazení přehledu o rybářských a loveckých lístcích, tisk lístků a formuláře žádosti o jejich vydání.


12

Oblast Poskytování informací o životním prostředí, EIA, IPPC umožňuje evidenci řízení dle zákona č. 100/2001 Sb., o posuzování vlivů na životní prostředí, zákon č. 76/2002 Sb., o integrované prevenci a zákona č. 123/1998 Sb., o právu na informace o životním prostředí. Jedná se zejména o vyjádření, stanoviska, výjimky z udělení emisních limitů a BAT a poskytování informací.


13

Oblast ochrany vod a speciálního stavebního úřadu pro vodní díla: umožňuje evidenci řízení dle zákona č. 254/2001 Sb. a zák. č. 183/2006 Sb., vkládání dat do Centrálního registru vodoprávní evidence (SW MZe), vkládání dat týkajících se rozpočtových nákladů povolených vodních děl do statistických výkazů (SW ČSÚ), přístup do systému ISPOP (kontrola a ověřování dat týkajících se nakládání s vodami – SW MŽP), přístup do systému RÚIAN (vkládání, rušení, kontrola zápisů vodních děl – SW katastrální úřad), komunikace se systémem VITA (modul Speciální stavební úřad vodoprávní).


14

Agenda veřejných vodovodů a kanalizací dle zákona č. 274/2001 Sb.: umožňuje přístup do systému VUME-VUPE (majetková a provozní evidence vodovodů a kanalizací – SW MZe), evidenci procesního průběhu řízení.


15

Evidence zákonem požadovaných údajů k řízením podle zákonů č. 254/2001 Sb., 183/2006 Sb. a 274/2001 Sb.


16

Možnost evidence doplňujících údajů/poznámek v souvisejícím případu.


17

U všech jednotlivých modulů zajistit možnost napojení na ZR (ROB, XXXXX, …) pod konkrétními agendami a rolemi.


18

Možnost generování a tisku statistických sestav a údajů, možnost konfigurace a tisku variabilních šablon.




  1. HARMONOGRAM

Objednatel požaduje realizaci předmětu plnění dle následujícího harmonogramu. Započetí každého milníku je možné pouze za předpokladu, že bude provedena akceptace všech milníků předcházejících. Akceptace milníků může být s výhradami a u výhrad musí být stanoven způsob a termín vypořádání.



Aktivita projektu

Termín nejpozději do:

Zpracování dokumentace skutečného nasazení (cílový koncept), připomínkování ze strany objednatele, vypořádání připomínek, finalizace dokumentu

8 týdnů

Milník číslo 1 – Předání dokumentace skutečného nasazení

T + 8 týdnů

Instalace aplikační a databázové části systému

16 týdnů

Konfigurace dodaného řešení pro potřeby zadavatele – v souladu s dokumentací skutečného nasazení – nastavení / konfigurace / parametrizace jednotlivých oblastí, provedení integrací na spolupracující systémy, nastavení přístupových oprávnění.

Zpracování a dodávka dokumentace (uživatelská, administrátorská).

Dodávka licencí (listinné potvrzení dodaných licencí co do jejich počtu a rozsahu).

8 týdnů

Milník číslo 2 – Připravené prostředí pro školení a testovací provoz

T + 24 týdnů

Prezenční zaškolení administrátorů a klíčových uživatelů

4 týdny

Milník číslo 3 – Předání do testovací provozu

T + 28 týdnů

Testovací provoz s dohledem a podporou zhotovitele

Oprava chyb a neshod, případná definice změnových požadavků

Provedení migrace dat ze zdrojových systémů do dodávaného řešení

Aktualizace dokumentace skutečného nasazení

6 týdnů

Akceptační řízení – porovnání skutečných vlastností s požadavky uvedenými ve smlouvě

2 týdny

Milník číslo 4 – Akceptace projektu, předání systému do rutinního provozu

T + 36 týdnů

(předpoklad do 30. 06. 2019)

Poznámka:

Ve sloupci „Termín nejpozději do:“ znak „T“ vyjadřuje datum uzavření smlouvy



  1. IMPLEMENTACE ŘEŠENÍ

    1. DOKUMENTACE SKUTEČNÉHO NASAZENÍ

Zadavatel požaduje v rámci plnění zpracování tzv. Dokumentace skutečného nasazení (někdy také analogicky nazýváno jako Cílový koncept nebo Implementační analýza).

Dodavatel zpracuje komplexní a detailní návrh nasazení informačního systému, a to ve vazbě na požadavky uvedené v zadávací dokumentaci. Cílem je zpracování dokumentu v takové míře detailu kroků a prací včetně konkrétního postupu zasazení do prostředí a jeho nastavení, která umožní dosažení zavedení systému do rutinního provozu řízenou formou.

Dokument proto bude jednoznačně a jasně konkretizovat jednotlivé kroky prací a to min. v rozsahu, které kroky a jakým způsobem budou řešeny, kým budou řešeny, za jaké součinnosti zadavatele a v jakém čase. Taková konkretizace bude dále dodržovat časovou, věcnou a logickou souslednost a bude z ní tedy možné v každém okamžiku realizace díla určit co je právě realizováno a v jakém stavu a co bude následovat. Zadavatel bude moci na základě takových podkladů alokovat své potřebné kapacity na součinnost a průběžnou kontrolu plnění díla. Dokument bude dále konkretizovat minimálně tyto oblasti

  1. Návrh řešení instalace aplikační a databázové části systému (architektura technického řešení)

  2. Detailní popis nastavení / konfigurace / parametrizace jednotlivých oblastí (společné registry, role a přístupová oprávnění, číselníky, reporty atd.)

  3. Návrh technického řešení integračních vazeb (vazby mezi agendami, vazby s vybranými aplikacemi objednatele, vazby se spolupracujícími centrálními systémy – typicky např. ISZR, ISKN)

  4. Návrh řešení postupu a pořadí při nasazování jednotlivých agend – upřesnění harmonogramu projektu

  5. Návrh řešení migrace dat (oblasti / agendy k migraci, výčet jednotlivých atributů, mapování na cílovou tabulku, časový rozsah migrovaných dat)

  6. Popis případných organizačních opatření nutných pro implementaci (např. pracovní schůzky)

  7. Upřesnění časového harmonogramu projektu

  8. Rozsah součinnosti ze strany zadavatele / městského úřadu

  9. Návrh průběhu testovacího provozu (návrh testovacích scénářů)

  10. Návrh akceptační procedury

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 dodavateli jejich vypořádání.



    1. Instalace aplikační a databázové části

Instalace systému a jeho nastavení dle zadavatelem odsouhlasené dokumentace skutečného nasazení bude provedena na hardware a software zadavatele. Pro potřebu nasazení a provozu dodávaného řešení jsou k dispozici tyto licence a systémové prostředky:



Konfigurace serveru:

Serverové prostředky a platforma

RAM

384 GB

CPU

10x Intel Xeon (≥3 GHz)

HDD

4 TB – diskové pole s 15k RPM disky

LAN

1Gbit

OS

JAVA podporovaný operační systém – Windows Server 2008/2008R2/2012/2012 R2 a vyšší (Datacenter licence – neomezený počet VM OS)

Virtualizace

Platforma VMware 6.0 Standard (bez omezení počtu VM)

Databáze

Serverová farma NENÍ licencována na SQL Enterprise (per core), ale per VM server (standard), a je tedy potřeba počítat s cenou za licence k databázím (SQL, Oracle, …)

Objednatel požaduje v rámci plnění také instalaci a nastavení testovací (školící) instanci, která bude obsahovat iniciální naplnění 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ů.



    1. Integrační vazby

      1. Integrační vazby

Objednatel požaduje v rámci plnění realizaci integračních vazeb na okolní prostředí a to min. v níže uvedeném rozsahu. Vlastní detailní popis integračních vazeb bude zpracován dodavatelem v rámci Dokumentace skutečného nasazení, a to včetně návrhu na doplnění případných dalších neuvedených vazeb, bude-li to nutné s ohledem na funkčnost jednotlivých agend nebo celého systému.

Zhotovitel musí při sestavování nabídky počítat s náklady vynaloženými na přípravu nebo úpravu rozhraní na straně stávajících systémů, které budou integrovány a případně také nutnou součinnost jejich aktuálních dodavatelů.



Aplikační komponenta IS úřadu

Dodavatel (název komponenty)

Záměr zadavatele

IDM /správa uživatelů a oprávnění k výkonu agend/

MARBES CONSULTING s.r.o. (PROXIO-EOS)

Integrovat + rozšíření nebo nahrazení stávající komponenty

Vazba na ISZR (rozhraní přístupu k XZR)

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Základní registry (“Hledáček”), vč. Vazby na USEP, AISEO, …

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Přestupky a správní delikty

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Vyhodnocování přestupků z MKS (Camea)

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Místní poplatky ze psů a VHP

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Dopravní agendy

MARBES CONSULTING s.r.o. (PROXIO)

Nahradit

Správa pohledávek a vymáhání

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Volby

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Matrika, vidimace, legalizace

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Evidence subjektů

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Lokální registr obyvatel (Ohlašovna)

MARBES CONSULTING s.r.o. (PROXIO)

Integrovat – stávající komponenta

Evidence rodin

Xxxxx (OM)

Nahradit

Personalistika a mzdy

Datacentrum DC2

Integrovat – stávající komponenta

Spisová služba

CNS a.s. (ELISA)

Integrovat – stávající komponenta

Ekonomický systém

Microsoft Dynamics Navision (NAV)

Integrovat – stávající komponenta

Docházkový systém

XXXX Xxxxxxxxx (XXXX)

Integrovat – stávající komponenta

Správní řízení – STÚ

VITA software s.r.o. (VITA STÚ)

Integrovat – stávající komponenta

Silniční správní úřad, vč. Speciálního stavebního úřadu

VITA software s.r.o.

(VITA STÚ)

Integrovat – stávající komponenta

Vodoprávní úřad, vč. Speciálního stavebního úřadu

VITA software s.r.o. (VITA STÚ)

Integrovat – stávající komponenta

Správní řízení – Životní prostředí

YAMACO (EMA – Evidence myslivosti, Rybářské a myslivecké lístky)

Nahradit

Správní řízení – Životní prostředí

INISOFT (EVI, ESPI – pro průběžnou evidenci odpadů)

Nahradit

GIS

GeoCortex (Lattitude Geographics) pro pořízení ÚAP, Prezentace dat v prostředí Geoportálu

Integrovat – stávající komponenta



Rozsah jednotlivých rozhraní a jejich prostřednictvím na sebe navazujících funkcionalit jednotlivých systémů budou ve své konkretizaci obsahem Dokumentace skutečného provedení.



      1. Otevřená rozhraní

Všechna externí rozhraní dodaných aplikačních řešení musejí být vystavěna nad standardizovanými a dokumentovanými službami, které umožní změnu systému na jedné nebo druhé straně rozhraní pouhou změnou konfigurace na systémové úrovni takového rozhraní (nový certifikát a adresa stroje, portu); i v případě datových pump a předávání dat formou strukturovaných dokumentů požaduje zadavatel zajištění dokumentace takové výměny dat a její standardizaci (dodržení např. XML nebo standardních databázových řešení); u samotného systému je vhodné za tímto účelem vybudovat samostatnou komponentu pro výměnu dat a navázání na další systémy (obdobně jako ESB sběrnice), tzn. konfigurace nastavení a vazeb na další systémy provádět z jednoho místa a v jednom místě také sdružovat vstupní/výstupní okruh a strukturu dat; místem v tomto případě není myšlený fyzický nebo jinak lokálně umístění prostředek, ale aplikačně sjednocené, byť i distribuované řešení.

Součástí dodávaných aplikačních řešení budou i otevřená, co do popisu a způsobu fungování, a dostatečně zabezpečená rozhraní, která umožní přístup a výměnu informací s dalšími informačními systémy (třetích stran).

Prostřednictvím takových rozhraní bude možné přistupovat k celému rozsahu dat zpracovávaných zadavatelem jeho prostřednictvím.

Samotná rozhraní budou zdokumentovaná na úroveň výměny jednotlivých informací, jejich podoby a rozsahu.

Rozhraní bude v rámci konkrétního informačního systému snadno administrovatelné správcem informačního systému zadavatele tak, aby na základě dodané dokumentace mohl povolit a nastavit přístup třetí straně samostatně bez součinnosti dodavatele.

V rámci administrace rozhraní bude mít dále správce informačního systému zadavatele jednoduchým způsobem možnost volit individuálně podle každého konkrétního napojeného systému třetí strany, ke kterým datovým sadám a v jakém konkrétním rozsahu bude mít systém třetí strany přístup.

Součástí dodávky bude i dokumentace tohoto rozhraní, kterou bude zadavatel oprávněn předat neomezenému okruhu dalších subjektů, za účelem možnosti napojení na dodávaný informační systém. Dokumentace rozhraní bude natolik podrobná, aby umožnila napojení systému třetí strany administrátorem zadavatele a programovými úpravami výhradně v informačním systému třetí strany bez jakékoliv potřeby součinnosti dodavatele tohoto informačního systému. Popis jednotlivých rozhraní bude muset být zpracován tak detailně, aby umožňoval zadavateli jeho předání třetí straně, která na základě popisu bude schopna vytvořit bez jakékoliv součinnosti dodavatele odpovídající protikus rozhraní v plném rozsahu a jeho spuštění bude odvislé pouze na povolení komunikace ze strany informačního systému. Takový popis rozhraní bude muset obsahovat minimálně technologii, kterou je rozhraní realizováno, popis jednotlivých datových typů a struktur, se kterými rozhraní pracuje, a způsob, kterým má být prostřednictvím rozhraní komunikováno.

Dokumentaci rozhraní bude povinen dodavatel udržovat aktuální a v rámci ní udržovat platný popis veškerých rozhraní informačního systému a databází, se kterými je provázán. Taková dokumentace bude vedena až na úroveň popisu konkrétního způsobu práce rozhraní s daty a uvedení všech jednotlivých datových typů a jednotlivých položek, se kterými pracuje.



    1. Migrace dat

Zadavatel požaduje v rámci plnění převedení všech relevantních (relevantnost určuje výhradně zadavatel) existujících (pořízených) dat ze stávajících aplikací a to min. v níže uvedeném rozsahu. Pro tuto migraci zadavatel poskytne popis současné struktury migrovaných dat a společně s tím součinnost ze strany současných dodavatelů s exportem nebo jinou formou zpřístupnění, které umožní automatizované provedení migrace dat.

Vlastní detailní popis migrace dat co do jejího skutečného rozsahu (věcného, časového) bude zpracována dodavatelem v rámci Dokumentace skutečného nasazení, a to včetně návrhu formy opravy chybných dat (vyčištění), duplicitních dat (deduplikace), doplnění chybějících dat a kontroly převedených (namigrovaných) dat.



Oblast informačního systému

Požadavek na migraci dat

IDM

Databáze uživatelů a jejich oprávnění (v případě náhrady IDM)

Evidence rodin OM

Databázi dětí, opatrovníků a vedení jejich evidence (vč. textových poznámek), agenda SPOD a Opatrovnictví



  1. ZAŠKOLENÍ ADMINISTRÁTORŮ A KLÍČOVÝCH UŽIVATELŮ

Dodavatel realizuje v sídle zadavatele prezenční zaškolení pro administrátory systému a klíčové uživatele zadavatele tak, aby tyto osoby byly schopny systém řádně užívat, nastavovat jej na administrátorské úrovni a školit uživatele systému.

Zadavatel pro účely zaškolení zajistí lektorské pracoviště, vybavené prezentační technikou (ve smyslu projektor, tabule pro psaní/kreslení) a dále zajistí konektivitu do vnitřní sítě zadavatele (s ohledem na možnost práce s produkční a testovací databází během školení). Veškeré školení bude probíhat v testovacím (školícím) prostředí.

Uvedený rozsah je považován za minimální s tím, že dodavatel navrhne ve své nabídce časový rozsah školení nutný pro zvládnutí samostatné práce se systémem. Uživatel musí zvládat minimálně dovednosti: ovládání aplikace (nabídka a použití funkcí programu), zadávání a editace dat, tiskové sestavy a přehledy, fungování vazeb na ostatní části systému. Ze strany zadavatele není požadavek na dodávku e-learningového systému.

Komponenta

Administrátoři

Klíčový uživatelé

Uživatelé

Ostatní

IDM

1

-

-

-

Správa identit / autentifikace

1

-

-

-

Portál občana, Portál úředníka, formulářové řešení

1

2

35

-

Řízená dokumentace (DMS) a dlouhodobý digitální archiv

1

2

35

-

Elektronizace jednání Rady a Zastupitelstva města

-

2

5

6

Service Desk

1

2

1

-

Vedení žádostí dle zákona 106/1999 Sb.

1,5

1

3

-

Odbor sociálních věcí (SPOD)

2

5

-

Odbor sociálních věcí (Opatrovnictví)

-

2

-

Koordinované stanovisko

-

1

-

Dopravní agendy

-

1

-

Životní prostředí

-

1

-

CELKEM

6,5

11

89

6

  1. TESTOVACÍ PROVOZ

Testovací provoz proběhne po dobu nejméně 6 týdnů, a to se zvýšeným dohledem a podporou ze strany dodavatele.

Zadavatel požaduje, aby v rámci testovacího provozu zajistil dodavatel zvýšený dohled a podporu uživatelů, a to formou fyzické přítomnosti v místě plnění, v celkovém rozsahu 10 člověkodnů, ze strany osob v následujících klíčových projektových rolích:

  • Konzultant – garant řešení v oblasti Portálu občana a úředníka vč. formulářového řešení

  • Konzultant – garant řešení v oblasti DMS a dlouhodobého digitálního archivu

  • Konzultant – garant řešení v oblasti integrací a napojení na centrální systémy

  • Analytik

Cílem testovacího provozu je poskytnout metodické vedení a prostor uživatelům pro ověření funkcionalit a vlastní funkčnosti dodaného řešení, pro cvičnou práci se systémem a prostor pro dodavatele pro identifikaci a opravu případných chyb a neshod. Dalším cílem testovacího provozu je možnost případné definice změnových požadavků ze strany zadavatele.

V době testovacího provozu bude možné ze strany dodavatele provedení případné nutné doplňující migrace dat (např. počáteční stavy) s ohledem na zahájení rutinního provozu.

Ze strany zadavatele budou během testovacího provozu připraveny (tj. navrženy a zpracovány) jednotlivé detailní akceptační scénáře – ty budou zahrnovat jednotlivé případy užití jednotlivých oblastí / modulů dodaného řešení.



  1. AKCEPTAČNÍ ŘÍZENÍ

    1. Dílčí akceptační řízení

Dílčí akceptační řízení bude provedeno pro milník 1, 2 a 3 vyznačený v harmonogramu projektu v kapitole 4 tohoto dokumentu. Dílčí akceptační řízení bude zahrnovat porovnání skutečného stavu vůči požadavkům zadávací dokumentace (milník číslo 1, 2 a 3) a požadavků daných dokumentací skutečného nasazení (milník 2 a 3).

Výsledkem dílčího akceptačního řízení je akceptační protokol s výsledkem Splněno nebo Nesplněno, podepsaný oprávněnými osobami smluvních stran.

Započetí dalších prací spadajících pod milník následující je možné pouze za předpokladu, že bude provedena akceptace všech milníků předcházejících.

    1. Souhrnné akceptační řízení – akceptace díla

Souhrnné akceptační řízení bude zahrnovat:

  • Provedení akceptačních testů podle specifikace vytvořené v rámci testovacího provozu. Akceptační testy budou zahrnovat konkrétní případy užití systému, popis realizace těchto případů a požadovaný výstup. Zadavatel požaduje provedení akceptačních testů nad produkčním prostředím.

  • Porovnání skutečného stavu vůči požadavkům smlouvy o dílo a této technické dokumentace, nefunkčního charakteru – licence, počty a specifikaci koncových zařízení.

Výsledkem souhrnného akceptačního řízení je akceptační protokol s výsledkem Splněno / Splněno s výhradou / Nesplněno, podepsaný oprávněnými osobami smluvních stran. Klasifikace Splněno s výhradou umožní pokračování v realizaci díla v případě vad drobných, pro které může být opakování akceptačního řízení zbytečně nákladné.

    1. Opakované akceptační řízení

Jestliže plnění nesplňuje stanovená akceptační kritéria kteréhokoliv akceptačního testu, bude výsledek akceptačního testu Nesplněno spolu s popisem závad a uvedením termínů pro jejich nápravu uveden ve vyhodnocení akceptačního protokolu. Zhotovitel napraví tyto nedostatky a příslušné akceptační testy budou provedeny znovu. 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 zhotovitel nesplní požadovaná akceptační kritéria pro příslušný akceptační test, nejvýše však 2× (dvakrát). V situaci, kdy by bylo nutné opakovat akceptační testy více jak 2× (dvakrát) pro konkrétní milník projektu nebo celé plnění, bude takové opakování považováno za podstatné porušení smlouvy ze strany dodavatele a zadavatel bude oprávněn odstoupit od smlouvy. Prodlení vzniklé v souvislosti s potřebou opakování akceptačních řízení bude považováno vždy za prodlení vzniklé na straně dodavatele se zachováním důsledků takového prodlení, tedy zejména smluvních pokut na základě uvařené smlouvy.

    1. Akceptační testy

Nedohodnou-li se smluvní strany jinak, vypracuje specifikaci akceptačních testů dodavatel a předá ji zadavateli k odsouhlasení v termínu min. 10 pracovních dnů před zahájením akceptační procedury dle harmonogramu. Odsouhlasení bude provedeno písemnou formou v termínu min. 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, písemně sdělí dodavateli v této lhůtě připomínky k dodavatelem předložené specifikaci akceptačních testů a poskytne dodavateli nezbytnou součinnost k dokončení a odsouhlasení specifikace akceptačních testů.

    1. Akceptační kritéria

Jako akceptační kritéria vstupující do akceptačních testů budou sloužit požadavky na řešení uvedené v tomto dokumentu.



  1. DALŠÍ POŽADAVKY A SLUŽBY

    1. Dokumentace

Zadavatel požaduje v rámci plnění zpracování a dodání konečné a úplné dokumentace k dodanému řešení v následující skladbě:

  • Uživatelská dokumentace – v rozsahu konkrétních nasazených funkcionalit u zadavatele (kuchařka – včetně use case).

  • Administrátorská dokumentace – správa a konfigurace IS v rozsahu konkrétního (nasazeného) řešení. Dokumentace musí být zpracována v takovém rozsahu, který umožní odborným IT pracovníkům zadavatele systémy spravovat a udržovat bez jakékoliv součinnosti dodavatele (s výjimkou mimořádných událostí programových chyb).

  • Bezpečnostní dokumentace – příručka bezpečnostního správce informačních systémů.

  • Dokumentace všech nasazených a dodaných rozhraní k informačním systémům.

    1. Projektové řízení

S ohledem na rozsah projektu a dopad jeho zavedení do produkčního provozu na výkon agend veřejné správy je požadováno aplikování základních principů projektového řízení ze strany dodavatele. Jedná se o následující aktivity:

  • řízení projektových prací v souladu s uzavřenou smlouvu s ohledem na:

    • věcné plnění dané smlouvou zadavatele – řízení postupu prací s ohledem na závazný harmonogram projektu – dodržování termínů a milníků harmonogramu;

  • zpracování pravdivých, úplných a věcně jasných a vypovídajících zápisů z konzultačních schůzek a pracovních jednání;

  • prezenční účast odpovědné osoby dodavatele na kontrolních dnech v sídle zadavatele, případně se souhlasem obou smluvních stran formou videokonference nebo telekonference;

  • reporting projektu na úrovni pravidelných dvoutýdenních písemných zpráv směrem k odpovědné osobě zadavatele;

  • řízení rizik projektu;

  • řízení změn na projektu – v případě odsouhlasení změn spolupráce při implementaci změn do projektu, komunikace s realizačním týmem.

  1. Popisy procesů k realizovaným agendám

Popis relevantních procesů je součástí přílohy č. 8 zadávací dokumentace – dokumentu „Procesní analýza MMÚL“.



  1. SEZNAM ZKRATEK

Typ služby

Význam

AIFO

Agendový identifikátor fyzické osoby (neveřejný identifikátor, který je jednoznačně přiřazen záznamu o fyzické osobě v příslušném agendovém informačním systému nebo základním registru)

AISC

Agendový informační systém cizinců

AISEO

Agendový informační systém evidence obyvatel

AIS (také AS)

Agendový informační systém

AÚ

Analytický účet

CSÚIS

Centrální systém účetních informací státu

CZCPA

Klasifikace produkce dle Českého statistického úřadu (ČSÚ)

DMZ

Demilitarizovaná zóna – speciální typ počítačové sítě ke zvýšení bezpečnosti komunikace s vnějším prostředím (Internetem) plnící roli firewallu. Servery v demilitarizované zóně nemají povolený přístup do lokální sítě.

DPH

Daň z přidané hodnoty

IČ

Identifikační číslo

IS

Informační systém

ISEO

Informační systém evidence obyvatel

ISEP

Informační systém evidence přestupků

ISKN

Informační systém katastru nemovitostí

ISVS

Informační systém veřejné správy

ISRS

Informační systém registru smluv

ISZR

Informační systém základních registrů

KDF

Kniha došlých faktur

KVF

Kniha vydaných faktur

OP

Občanský průkaz

ORG

Organizace

ORJ

Organizační jednotka

OS

Operační systém

PAP

Pomocný analytický přehled

ROB

Registr obyvatel

RÚIAN

Registr územní identifikace adres a nemovitostí

SIPO

Soustředěné inkaso plateb obyvatelstva

SPOD

Sociálně-právní ochrana dětí

SS

Specifický symbol

SÚ

Syntetický účet

SW

Software



YQ8OKn3NvFh.doc 5 / 57

Document Metadata

Filed: October 4th, 2024