Analýza aktuálního stavu vnitřního chodu úřadu

Studie proveditelnosti VIÚ Rychnov nad Kněžnou – Příloha 2

Příloha 2 – Analýza současného stavu

Analýza aktuálního stavu vnitřního chodu úřadu Město Rychnov nad Kněžnou

součást projektu Studie proveditelnosti

Vypracoval:

Ing. Josef Mrkus

Datum vytvoření:

24. 5. 2010

Vnitřní integrace úřadu města Rychnov nad Kněžnou – Příloha 2 Strana 1 (celkem 24)




Obsah 1

Úvod .............................................................................................................................................................. 5

2

Současný stav systému v jednotlivých oblastech .......................................................................................... 6 2.1

Modul – Systém řízení organizace (organizační struktury) .................................................................. 6

2.2

Modul – Systém řízení zdrojů............................................................................................................... 6

2.3

Modul – Systém řízení služeb............................................................................................................... 7

2.4

Modul – Vnější integrace systému ....................................................................................................... 8

2.5

Modul – Datové podklady.................................................................................................................... 9

2.5.1

IS ve správě MěÚ....................................................................................................... 9

2.5.2

Agendy nepodpořené IS.......................................................................................... 10

2.5.3

Záměry na pořízení nebo vytvoření nových IS ........................................................ 10

2.6

Architektura SW ................................................................................................................................. 10

2.7

Architektura HW ................................................................................................................................ 10

3

Definice problému systému a hodnocení závažnosti systému.................................................................... 10

4

Návrh variant řešení .................................................................................................................................... 11 4.1

5

6

Technologické varianty ...................................................................................................................... 12

4.1.1

Funkční a procesní pohled ...................................................................................... 12

4.1.2

Datová část.............................................................................................................. 12

4.1.3

SW architektura ...................................................................................................... 13

4.1.4

HW architektura...................................................................................................... 13

4.2

Finanční varianty................................................................................................................................ 13

4.3

Personální varianty ............................................................................................................................ 13

4.4

Organizační varianty .......................................................................................................................... 13

Celkové hodnocení a výběr doporučené varianty řešení ............................................................................ 14 5.1

Materiálové vstupy ............................................................................................................................ 14

5.2

Lokalita řešení .................................................................................................................................... 14

5.3

Technické řešení ................................................................................................................................ 14

5.4

Organizace a režijní náklady............................................................................................................... 15

5.5

Lidské zdroje, vlastníci a zaměstnanci................................................................................................ 15

Závěr ............................................................................................................................................................ 16

Příloha 1 ‐ Seznam zkratek .................................................................................................................................... 17 Příloha 2 ‐ otázky k analýze současného stavu ..................................................................................................... 18





1 Úvod Dokument „Analýza aktuálního stavu vnitřního chodu úřadu“ popisuje stav chodu a řízení úřadu v jednotlivých oblastech a navrhuje optimální řešení spočívající v úpravě stávajících procesů, systémů nebo zavedení nových. Toto řešení je základem pro zpracování Studie proveditelnosti k Výzvě číslo 06 na rozvoj služeb eGovernmentu v obcích. Analýza aktuálního stavu chodu úřadu je zpracována ve struktuře a rozsahu daném dokumentem “Vnitřní integrace úřadu – Typizovaný projekt“rámci řešení části III výzvy – Vnitřní integrace úřadu obce s rozšířenou působností. Aby byl projekt, resp. jeho cíl považován za naplněný, je nutné splnit cílovou hodnotu indikátorů. Příloha č. 2 – Indikátory prioritní osy 2 Výzvy č. 06 na rozvoj služeb eGovernmentu v obcích definuje jediný monitorovací indikátor jako „Počet úřadů s provedenou integrací“. Cílovou hodnotou je tedy číslo 1.



2 Současný stav systému v jednotlivých oblastech Systém chodu úřadu a jeho řízení bude analyzován ve funkčních oblastech (modulech), které jsou definovány v kapitole 3 a 6 příručky “Vnitřní integrace úřadu – Typizovaný projekt“: • řízení organizace (organizační struktury); • řízení zdrojů; • řízení služeb; • vnější integrace systému; • datové podklady (klíčové databáze systému).

2.1 Modul – Systém řízení organizace (organizační struktury) Modul řízení organizace 1.1.Modelování Prvek umožní připravit změny v organizační struktuře, katalogizaci agend, modely činností v agendách, vazbu na legislativní organizační struktury předpisy, organizační strukturu ve variantách. Umožní předat budoucí stav řídícímu modulu. Příprava na změny se provádí pouze "ručně" v kanceláři tajemníka. Změny jsou různého charakteru a obtížnosti. Některé změny legislativy mohou být velmi rozsáhlé (např. včetně stavebních úprav).Prvek je důležitý při složitějších organizačních změnách, je to modelovací nástroj. Doporučujeme problematiku řešit ‐ s nižší prioritou! Může být nasazen v dalších etapách rozvoje ICT města. 1.2. Referenční Řídící modul pro evidenci (okamžitý stav) stromové organizační struktury úřadu umožní vytvoření stromové struktury odborů, Organizační struktura oddělení, rolí (pozic) a pracovní náplně organizačních celků (přiřazení zaměstnanců ‐ se děje vazbou na referenční evidenci zaměstnanců, nebo ručně). Může nabídnout tvorbu pracovních náplní podle katalogu prací MPSV. Město nemá v systému referenční evidenci organizační struktury v použitelné databázové formě. Jednotlivé systémy si zpravidla udržují svoji organizační strukturu. Lze doplnit samostatně stojícím modulem. Udržuje organizační strukturu na webových stránkách, používá se Powerpoint, prezentuje dále i životní situace a kontakty. Pracovní náplně se vytvářejí ručně prostřednictvím katalogu MPSV a vlastní textyv MS Wordu. 1.3. Zaměstnanci Evidence zaměstnanců existuje v různých komponentách systému ‐ mzdový systém, web, LDAP atd.. V personalistice a mzdách je zpravidla udržována nejpřesnější evidence, mohla by být pro systém referenční. Mzdová evidence je dominantní, je implementována personální agenda ale jen okrajově, tuto lze využít jako referenční. Nutno doplnit rozhraní (vazbu) pro využití ostatními systémy. Personální agendu doporučujeme dále rozvinout. 1.4. Personalistika Často nebývá využívána do důsledku ani v oblasti organizační struktury, i pokud je dodána. Dosavadní řešení vyhovuje, doporučujeme dále rozvinout jeho využívání jako referenčního zdroje dat o uživatelích pro systém správy organizační struktury. 1.5. Adresářové služby Řízení přístupových oprávnění k diskovému prostoru, datům a aplikacím. Jedna ze základních komponent (AD, LDAP) V součastné době není implementován. V rámci výstavby TC je plánovaná implementace Microsoft AD. 1.6. Katalog agend, včetně práv

Evidence agend (procesů, služeb), rodný list agendy, kroky, které agenda vyžaduje a za něž je možno (nutno) mít odpovědnou osobu. V současných strukturách nebývá realizován, agendy se definují až na úrovni oddělení. Důležitá je identifikace aplikace, která agendu podporuje. Základní funkcí prvku je přiřazení práva k agendě a dílčímu úkonu agendy. Tak vzniká přehled práv a povinností na úrovni ORP. Existuje pouze „ruční“ evidence dosud systémově neřešeno.Doporučujeme prvek doplnit do systému ve vazbě na katalog agend. 1.7. Katalog aplikací, Evidence aplikací (procesů, služeb), které agenda vyžaduje a za něž je možno (nutno) mít odpovědnou osobu. V současných včetně práv strukturách nebývá realizován. Vhodné je vybudovat úplný přehled použitých aplikací ve vztahu k agendě. Pokud je daná aplikace je způsobilá, bude možno přiřazovat práva k aplikaci v různých krocích. Minimální je právo spuštění aplikace. V součastné době něřešeno, úřad pouze které aplikace provozuje 1.8. Groupware Zajišťuje komunikaci jednotlivců a skupin, kalendáře, e‐mail, práce týmů… V součastné době nepoužívají. V budoucnu doporučujeme řešit mimo výzvu 06.

2.2 Modul – Systém řízení zdrojů Modul Back Office 5.1. Integrace Back Office

Základní komponenty jsou ‐ ERP ‐ Spisová služba ‐ agendové systémy by měly být propojeny tak, aby umožnily evidovat případy v celém jejich životním cyklu, a ve všech datových aspektech – číselná data, finanční údaje, dokumenty, eventuálně potřebné mapové a multimediální podklady. Z diskuse vyplývá, že systém je postaven na kombinaci produktů VEMA, VERA, Fénix, které nejsou nijak integrovány prostřednictvím automatizovaných vazeb. Žádný ze systémů nemá dominantní, nebo standardní evidence organizační struktury, partnerů, nebo objektů. Není zřetelné, zda je možno případy sledovat včetně detailního saldokonta partnerů města – tedy propojení na účetnictví. Účtování pohledávek a závazků se zřejmě děje tzv. „na hromady“.Základní vazby BO jsou řešeny, saldokonto je vedeno centrálně za všechny agendy, blokace rozpočtu je, není využívána. Doporučujeme celkové propracování vazeb mezi agendovými systémy a účetnictvím. Bude případně řešeno v rámci finančních prostředků z vhodného operačního



programu. 5.2. Agendy pokryté současným SW

Systémy typu VERA, Ginis pokrývají velkou část agend do různé hloubky, zejména v jejich finančních aspektech. Ne všechny agendy však pokrývají procesně a evidenčně. Ve spojení se spisovou službou jsou základem evidence "případů", nebývají však integrovány a implementovány důsledně. Agendy jsou nyní pokryté z velké části současnými systémy 5.3. Agendy vnější nepokryté SW

Existuje nezanedbatelná oblast agend nabízených veřejnosti, které nejsou plně evidenčně a procesně pokryty základním agendovým "balíkem". Je možno doporučit jejich pokrytí nějakým obecným produktem s příslušnou evidenční a procesní funkcionalitou. Řešeno v rámci SSL a interních formulářů v MS Wordu. 5.4. Agendy vnitřní Vnitřní agendy jsou procesy vyřízení nejrůznějších žádanek a požadavků, rezervací, námětů ‐ služeb nezbytných pro vnitřní nepokryté SW chod úřadu. Bývají pokryty částečně a nesystematicky různými aplikacemi. Možno doporučit celkovou integraci, jejich pokrytí nějakým produktem. Takové agendy existují (viz analýza souč. stavu). Doporučujeme řešit dodávkou konfigurovatelného nástroje a následným postupným rozvojem řešení. Některé agendy doporučujeme řešit nákupem SW k napojení na IS města. 5.5. Správa saldokonta Systém tvorby pohledávek a závazků, propojení plateb a příjmů peněz, informování potřebných úředníků, vymáhání pohledávek, zaúčtování pohledávek, prezentace saldokonta partnera. Systém by měl pracovat detailně ‐ slučováním položek se ztrácí schopnost řídit. Saldokonto závazků a pohledávek je řešeno v rámci Vera, umožňuje další rozvoj. Doporučujeme dále analyzovat a řešit integraci. Nelze řešit v rámci finančních prostředků výzvy 06. 5.6. Referenční Evidence, která umožňuje postupné a průběžné čištění (kultivaci) údajů o partnerech města, je referenčním zdrojem pro evidence partnerů ostatní systémy, které k ní mohou přistupovat formou webových služeb. Není referenční evidence 5.7. Evidence majetku Nemovitý majetek je hodnota, která musí být důsledně evidována přesně identifikována ve vazbě na základní registry s pečlivým monitorováním aktivit probíhajících na majetku, nebo v jeho okolí. Systém T‐Mapy. Doporučujeme další rozvoj mimo Výzvu č. 06 (v rámci finančních prostředků z jiného vhodného operačního programu). 5.8. Evidence případů Ve spojení se spisovou službou by měly implementované systémy umožnit evidovat "případy" a kdykoliv informovat žadatele o stavu jejich vyřízení, s poskytnutím veškerých záznamů, které jsou s případem spojeny, včetně finančních údajů o stavu pohledávky. Systémy nebývají integrovány a implementovány tak důsledně, aby celý problém řešily. Problematika je řešena pouze dílčím způsobem.Doporučujeme dále řešit, naplnění cíle však nelze dosáhnout s finančními prostředky EU ‐ 06. V rámci předkládaného projektu je navržena řada úprav směřujících k tomuto cíli. 5.9.Evidence práv a Agendy zakládající práva a povinnosti stran, nebývají systematicky zpracovány ve všech aspektech ‐ administrativní , povinností, výnosů, dokumentační, finanční. Tvoří důležitý prvek ve vztahu k budoucímu registru práv a povinností. Vnitřní chod úřadu je smluv a rozhodnutí důmyslným komunikačním a koordinačním systémem. Smluvní vztahy s externími subjekty, příprava jednání orgánů města (volených i nevolených) a evidence usnesení a úkolů z těchto jednání vyplývajících je vlastně obrovským procesem správy vnitřních projektů. Aplikační podpora bývá řešena specializovanými agendami, často napojenými na spisovou službu. Lze sem zařadit i problematiku správy přístupových certifikátů. Doporučujeme důsledně řešit mimo rámec výzvy 06 6. Evidence certifikátů Evidence platnosti certifikátů Takovou evidenci město dosud vede pouze ručně. Město požaduje řešení v rámci Výzvy č. 06.

2.3 Modul – Systém řízení služeb Modul spisová služba 2.1. Spisová služba ‐ celková funkce

Funkce evidence došlých a odeslaných dokumentů, sdružování do spisů. Ovládání čísel jednacích. Na ORP zpravidla mají, spravuje organizační strukturu, může být referenční organizační strukturou, nebo by měla umět organizační strukturu přijmout z jiného systému, musí dodávat čísla jednací, vyžaduje evidenci zaměstnanců. Město má systém Vera, je plně funkční a plní všechny standardní funkce dané zákonem o archivnictví a spisové službě a souvisejícími zákony. 2.2. Dokumenty SpS Podpora práce s dokumenty v elektronické podobě v oblasti spisové služby. Město používá úložiště Vera. Lze realizovat doplnění systému a převedení správy dokumentů pod jiné standardní DMS, s využitím konektorů Vera 2.3 Dokumenty mimo V současném systému vždy existuje nezanedbatelné množství dokumentů, které neprojdou spisovou službou, je třeba je uložit SpS v elektronické podobě v rámci DMS systému, včetně jejich popisných dat. Práce s těmito dokumenty nebývá řešena ‐ funkce DMS tedy nebývá řešena jako systém. Pro agendy mimo VERA nemají DMS, dokumenty lze vytvořit ve spisové službě – a přiřadit jim č.j. Následně prostřednictvím spisové služby je dokument přístupný a uložen v DMS spisové služby. Systém však nemá všechny rysy DMS. Doporučujeme řešit v rámci Výzvy č. 06 VIÚ. 2.4. Workflow SpS Řeší dodání záznamu o dokumentu nebo celého dokumentu úředníkovi, který jej má vyřídit. Město používá WF Vera, je funkční v rozsahu procesů spisové služby. Žádná zásadní opatření se nepředpokládají. 2.5. Workflow mimo Komponenta je nezbytná k řešení problematiky informování o stavu případu. Po předání dokumentu k vyřízení na stůl SpS úředníka se odehrává proces řešení případu, který může být ze zákona řešen sadou povinných kroků, nebo je prostě vyžaduje. Stav řešení případu je další stupeň WF, který řeší agendový systém, nebo není řešen vůbec. Úřad tak zpravidla také nemá schopnost monitorovat detailně stav řešení případu a poskytnout žadateli podrobnější informace elektronickou cestou. Taková potřeba existuje, včetně sledování podrobného stavu podání a není podpořena SW. Doporučujeme doplnění systému o funkce podporující možnost správy WF mimo rámec spisové služby a podporu sledování podrobného stavu podání. 2.6. Konektory SpS Spisová služba (SpS) je důležitým prvkem systému a je nutno rozvíjet využití rozhraní ‐ konektorů ‐ na okolní komponenty ICT. Je možné doplnit konektory spisové služby, pokud budou dostupné od dodavatelů SW.



Modul „vazby“ 4.1. Vazba Zaměstnanci ‐ Organizace

Cílem vazby je propojení referenční evidence zaměstnanců s organizační strukturou, nebo přenesení struktury zaměstnanců do organizační struktury. Je možno řešit vybavením personálního systému příslušným rozhraním. Cílovou komponentou, kde dojde k vlastnímu vytvoření vazby, může být SW spisové služby, pokud tyto komponenty mají příslušné funkce rozvinuty, nebo jiná, speciální komponenta, která zajistí evidenci vazeb. Vera – Fenix, účtování se provádí ručně – doklady se předají do účtárny, určitě možno zlepšit systém saldokonta …. Rozpočet je připraven systémem 3. strany . Existuje automatický přenos FENIX – FISO na bázi exportu a importu dat. Kontrola objednávek proti rozpočtu – osobní odpovědností, automatizovaně zřejmě ne. 4.2. Vazba organizační Prostředky adresářových služeb nebývají vhodné pro správu stromové organizační struktury. Data o organizační struktuře struktura ‐ LDAP vytvořená v referenčním systému lze do nich přenést prostřednictvím rozhraní, referenční zdroj organizační struktury musí být takovým rozhraním vybaven, cílový SW musí umět takovou službu přijmout. V současném systému řešena referenční evidence organizační struktury – bude řešena v rámci 1.2., včetně vazby na LDAP. 4.3. Vazba ‐ výdej Č.J. Doplnění čísel jednacích (č.j.) do agendy, která stojí mimo spisovou službu je nutno na spisové službě požadovat, aby vznikla agendě konzistentní evidence č.j. pro všechny agendy. Je ovšem možno pracovat i mimo č.j., potom je nutno č.j. nahradit jiným identifikátorem. Současná spisová služba má příslušné rozhraní, využívá se v rámci vazby na SW VERA.Doporučujeme rozšíření využití připraveného rozhraní. Může být řešeno v rámci výzvy 06. 4.4. Vazba ‐ výdej Referenční evidence organizační struktury ‐ pokud existuje – musí mít rozhraní pro dodávku organizační struktury do ostatních organizační struktury komponent, které ji potřebují. V současném systému neřešeno. Velmi důležitá vazba ‐ zavedením referenční evidence organizační struktury (viz výše) je možno postupně řešit rozvoj rozhraní důležitých komponent ‐ SpS, , ostatní agendové systémy. Doporučujeme řešit v rámci Výzvy č. 06 4.5. Vazba ‐ přiřazení Záznam, že aplikaci nebo detailně některou její dílčí funkci, má právo provádět určitý zaměstnanec. Bývá řízeno zpravidla práva k aplikaci detailně v rámci funkcí řízení oprávnění ve vlastní aplikaci. Řešeno nesystémově ‐ samostatně v rámci jednotlivých agendových systémů ‐ ne v rámci celého systému. Je nezbytné tuto funkcionalitu integrovat jako prioritní požadavek v rámci Výzvy č. 06, pro nově doplňované aplikace řešit systémově. 4.6. Vazba ‐ přiřazení Záznam, že agendu nebo detailně některý její krok má právo provádět určitý zaměstnanec. Bývá běžně zpracováno pouze práva k agendě ručně, zpravidla na úrovni vedoucího oddělení ‐ vůči "svým" zaměstnancům. Řešeno "ručně". Je nezbytné tuto funkcionalitu integrovat jako prioritní požadavek v rámci Výzvy č. 06, pro nově doplňované agendy řešit systémově ‐ v rámci zavedení katalogu agend ‐ viz výše. 4.7. ePUSA plnění dat Vyžaduje plnění daty organizační struktury a zaměstnanců. Bývá zajištěno "ručním" přepisem. Data plní "ručně" v základní úrovni, zejména v oblasti krizového řízení. Plnění dat systému ePusa zajistí využitím příslušných rozhraní referenční zdroj organizační struktury, zaměstnanců, a další komponenty. 4.8. Vazba agenda ‐ Registr je referenční evidence dané entity (subjektu, nebo objektu). Vazba bývá řešena pouze částečně. Agendové systémy ISZR ‐ čtení, převzetí nepožadují důsledně verifikaci údajů. To přináší jeden z největších problémů současných systémů a taky je důvodem řešení základních registrů veřejné správy. Neřešeno. Do budoucna bude řešeno prostřednictvím ISZR, vazby ani rozhraní však není dosud známo, nebude se tedy řešit ani v rámci Výzvy č. 06. Tento základní požadavek vnitřní integrace doporučujeme řešit doplněním katalogu agend s evidencí práv a povinnosti pracovat se základními registry ‐ agendy budou mít v katalogu příznak těchto služeb. Dořešení proběhne mimo rámec Výzvy č. 06. 4.9. Vazba agenda ‐ Vyšší úroveň vazby umožní agendě zapsat změnu do registru (referenčního zdroje) práv a povinností. ISZR ‐ zápis práva Neřešeno. Do budoucna bude řešeno prostřednictvím IZSR, vazby ani rozhraní však není dosud známo, nelze tedy řešit ani v rámci Výzvy č. 06. Tento základní požadavek vnitřní integrace doporučujeme řešit doplněním katalogu agend s evidencí práv a povinnosti pracovat se základními registry ‐ agendy budou mít v katalogu příznak těchto služeb. Dořešení proběhne mimo rámec Výzvy č. 06.

2.4 Modul – Vnější integrace systému Modul „portály“ 3.1. Prezentace města

Je realizována zpravidla prostřednictvím dodaného redakčního systému. Obsahuje zpravidla kontakty na úředníky a organizační strukturu, někdy s popisem náplní jednotlivých organizačních celků. Nebývá propojena na referenční datové zdroje ‐ data se pořizují ručním záznamem ‐ přepisem v redakčním systému. Je možné napojit je na referenční data a nepořizovat tak údaje duplicitně. Město vytváří svou prezentaci prostřednictvím redakčního systému, bez vazby na databáze kontaktů a zaměstnanců. Je možno dále rozvinout. Problematiku nehodnotíme jako nezbytnou, doporučujeme řešit mimo rámec Výzvy č. 06. 3.1.1. Prezentace Jeden z definovaných požadavků v dokumentu „Vnitřní organizace úřadu“ služeb a organizační struktury Tuto část město pořizuje odděleně od datových zdrojů. Po vytvoření referenční organizační struktury (včetně katalogu agend, aplikací, práv a oprávnění), bude datově připravena pro prezentaci na internetu. 3.2. Portál občana Portál občana chápeme jako součást prezentace města na internetu zaměřenou na prezentaci portfolia agend (služeb) veřejnosti. Město má rozvinuty dílčí části takového portálu, jako celek problematiku neřeší.Z klíčových funkcí portálu občana doporučujeme rozvinout pouze dílčí části ve smyslu níže popsaných funkcí, což nedoporučujeme řešit v rámci Výzvy č. 06. 3.2.1. Životní situace Pomůcka usnadňující komunikaci občana s úřadem ‐ popis postupu podle standardní osnovy, nebo dále propracovaný popis služby. Navazuje na náplně odborů, legislativu, práva a povinnosti úředníků v jednotlivých agendách. Problematika souvisí s PVS, kde jsou typové životní situace popsány. Město má umístěno v rámci prezentace města.Doporučujeme dále rozvíjet mimo rámec Výzvy č. 06.



3.2.2. Formulářový systém

Zpravidla formuláře žádostí navazující na agendy nebo životní situace. Po jejich vyplnění jsou postoupeny přenosovými prostředky k úředníkovi, který případ vyřizuje. Stupeň rozvinutí může být ‐ formulář bez možnosti vyplnění, s možností vyplnění, on line formuláře agendového systému, formulářový systém různých dodavatelů s propadem dat do příslušného agendového systému, s kontrolovanou identitou subjektu nebo objektu s logickými a syntaktickými kontrolami. Město nepoužívá žádný takový systém a nyní neuvažuje o jeho zavedení 3.2.3. Rezervace času Funkce umožňující pracovat na portále s kalendářem úředníka a objednat schůzku. Tak doplňuje funkce používaných úředníka vyvolávacích systémů. Neřešeno, doporučujeme řešit mimo rámec Výzvy č. 06. 3.2.4. Externí identita Systém umožňující ověřené přihlášení občana na portál a důvěrnou komunikaci s úřadem prostřednictvím registrace uživatele. Neřešeno, doporučujeme řešit mimo rámec Výzvy č. 06. 3.3. Portál úředníka Sjednocuje uživatelské pracovní prostředí úředníka na jeho stanici, integruje ovládání jím používaných aplikací a agend z různých systémů na různém stupni, podle hloubky propracování systému uživatelských oprávnění. Neřešeno, doporučujeme řešit. Město zahájí implementaci v omezeném rozsahu ‐ v rámci problematiky správy právních aktů, smluv a dotací a následného postupného rozšiřování užití systému mimo rámec Výzvy č. 06. Portál vytvoří jiné prostředí pro řešení agend a WF mimo rámec spisové služby.

2.5 Modul – Datové podklady 2.5.1 IS ve správě MěÚ V této části jsou identifikovány používané IS. Pro analýzu integrace vnitřního chodu úřadu jsou uvažovány ISVS, provozní informační systémy s vazbou na ISVS ostatní provozní informační systémy bez vazby na ISVS, např.: Název Poznámka Personalistika

Okrajově řešeno VEMA

Mzdy

VEMA

Účetnictví

Fenix

Majetek

T – Mapy, movitý – soukromá firma

Spisová služba

VERA

Modelování organizační struktury

‐

Evidence organizační struktury

‐

LDAP/ AD

‐

IDM

‐

DMS

„náhrada“ VERA

GIS

T‐Mapy, Gramis

Agendové systémy

VERA, …. Prosím dopsat

Smlouvy

‐

Objednávky

‐

Přestupky, delikty, pokuty

VERA (zřejmě ne všechny)

Příjmy a poplatky

VERA a další různě

Stavební řízení

VERA

Matrika

VERA

Ohlašovna

VERA

Groupware

Zatím nevidí potřebu .. možná po volbách

Workflow

Spisovka, jinak ne

Formuláře

CzP, vlastního nic

Evidence partnerů

‐

Evidence adres, parcel, obcí

VERA

Evidence majetku

T‐Mapy,



2.5.2 Agendy nepodpořené IS Agenda

Způsob podpory

HelpDesk

Papír

Rezervace zdrojů

Papír

Žádanky o schválení

Papír

Dovolená

Papír

Infodeska

Papír, Word

Evidence certifikátů

Papír, tabulkový procesor

Evidence psů

Papír

Vidimace a legalizace

Papír

Dopravní stavební úřad

Pomocné evidence

2.5.3 Záměry na pořízení nebo vytvoření nových IS Agenda

Poznámka

Rozšíření portálu úředníka

Identity management

Doplnění vazeb spisové služby

Agendy rozšiřující stávající IS

2.6 Architektura SW Posouzení existujících SW komponent, návrh jejich úprav nebo náhrady je základní aktivitou projektu. Posouzení zahrnuje potenciální využití integrační platformy a nástrojů pro podporu toku pracovních činností. Typ SW Poznámka Využívané OS MS Server 2003 Windows, Využívané DB systémy MS SQL 2005, Firebird, MySQL Workflow ‐ Formuláře ‐ Integrační platforma ‐ Groupware ‐

2.7 Architektura HW Současná HW architektura není v rámci analýzy vnitřního chodu úřadu popisována. Návrh TC je plně řešen ve Studii proveditelnosti a předpokládá se s převedením provozovaných aplikací a systémů do TC.

3 Definice problému systému a hodnocení závažnosti systému Problémy současného nastavení systému vnitřního chodu úřadu jsou definovány a hodnoceny v rovině kriterií kvality uvedených v úvodu této analýzy, která jsou pro potřeby hodnocení podrobněji rozepsána Funkce Popis problému – závažnost



Evidence organizační struktury Evidence zaměstnanců

Evidence není systematicky řešena Evidence mzdového systému není využita jako referenční

Evidence objektů

Evidence objektů není využita jako referenční

Správa systému

Řešeno uspokojivě

Evidence stavu případu

Neřešeno systémově, velmi obtížné

Katalogizace agend

Katalog agend není veden

Katalog aplikací

Katalog aplikací není veden

Pohledávky a závazky

Řešeno do značné míry

Evidence práv povinností


Identifikátory a čísel. řady


Práce s dokumenty

Řešeno prostřednictvím spisové služby

Adaptibilita systému

Řešeno částečně

Oprávnění k agendě

Neřešeno

Formulářový systém

Neřešen

Agendy nepokryté SW

Existují vnější i vnitřní, nutno dále analyzovat a řešit

Groupware

Neřešeno

Integrační komponenty

Řešeno částečně, možno doplnit

Portál úředníka

Neřešeno

Portál občana

Řešeno uspokojivě, rozvinutí není v této fázi vhodné

Integrační platforma

Neřešeno, v současném stavu není vhodné

4 Návrh variant řešení Návrh možných variant integrace chodu úřadu je proveden s ohledem na zadání Výzvy číslo 06, ve vztahu k analýze provedené v kapitole 2 tohoto dokumentu, ve vztahu k definovaným problémům a nedostatkům popsaným v kapitole 3 a v neposlední řadě ve vztahu k vizi chodu úřadu. Varianty pro integraci jsou uvedeny a kategorizovány v následujících podkapitolách. Následně si zadavatel vybere ty, které chce skutečně realizovat, a to tak, aby celková koncepce úprav naplňovala cílovou hodnotu monitorovacího indikátoru uvedeného v kapitole 1. Funkce VIÚ dle typového projektu 1. Modul systém řízení organizace 1. 1. Modelování organizační struktury 1.2. Referenční Organizační struktura 1.3. Zaměstnanci 1.4. Personalistika 1.5. Adresářové služby

Řešit výzvou 06 ano ne x x x x x

1.6. Katalog agend, práv a povinností

x

1.7. Katalog aplikací a oprávnění

x

1.8. Groupware 2. Spisová služba a dokumenty 1. Spisová služba 2. Správa dokumentů SpS 3. Dokumenty mimo SpS 4. Workflow SpS 5. Workflow mimo SpS 6. Integrace spisové služby a okolí 6.1 Konektor Vera na standardní DMS 3. Portály

x x

Poznámka Dodat rozhraní HR na ostatní systémy Řešeno v rámci TC

Způsob dodávky Produkt/technologie IDM IDM

Dodat

IDM

Dodat

IDM

x x x x x x

Migrovat do standardního úložiště Dodat standardní úložiště Dodat vhodný software Dle možností rozšíření

DMS POR POR, SpS SpS



1. Prezentace města 1.1 Prezentace služeb a org. struktury 2. Portál občana 2.1. Životní situace 2.2. Formulářový systém 2.3. Rezervace času 2.4. Externí identita 3. Portál úředníka 3.1. HelpDesk 3.2. Rezervace zdrojů 3.3. Žádanky o schválení 3.4. Dovolená 3.5. Infodeska 3.6 Evidence certifikátů 4. Vazby 1. Vazba zaměst. ‐ organizace (výdej) 2. Vazba organizační struktura ‐ LDAP 3. Vazba ‐ výdej Č.J. (SpS) agendě 4. Vazba ‐ příjem organizační struktury 5. Vazba ‐ přiřazení práva k aplikaci 6. Vazba ‐ přiřazení práva k agendě 7. pusa ‐ plnění dat 8. Vazba agenda ‐ ISZR ‐ čtení, převzetí 9. Vazba agenda ‐ ISZR 5. Back Office 1. Integrace Back Office 2. Agendy pokryté současným SW 3. Agendy vnější nepokryté SW 4. Agendy vnitřní, nepokryté SW 4.1. Evidence psů 4.2. Vidimace a legalizace 4.3. Dopravní stavební úřad 4.3. Konektory CzP 5. Správa saldokonta 6. Evidence majetku 7. Evidence případů 8. Evidence v oblasti práv, povinností

x x x x x x x x x x x x x x x x x

x x x x x x x x x x x x x x x x x x

Dodat základní komponentu Řešeno již v rámci bodu 1.3 Vytvořit předpoklady Vytvořit předpoklady

IDM POR POR POR POR POR POR POR IDM IDM IDM IDM Agendy Agendy Agendy Agendy Agendy

•

Pokud je komponenta pro zadavatele subjektivně prioritní, je označena ve sloupci priorita zadavatele „x“

4.1 Technologické varianty Možností řešit podstatné komponenty systému je celá řada. Výběr konkrétní varianty řešení je určen prioritou z hlediska systému, zadavatele projektu a zejména finančních omezení dotace.

4.1.1 Funkční a procesní pohled Základní požadavek je řešit oblast modulu řízení tak, aby byl vytvořen základ pro zajištění vazeb na ISZR – vytvořit předpoklady naplnění 4 integračních bodů (viz příloha výzvy 06 – Vnitřní integrace úřadu, typizovaný projekt).

4.1.2 Datová část Požadavek existence referenčních datových struktur – evidencí, které budou zajišťovat kvalitní identifikaci a lokalizaci evidovaných entit. Referenční evidence lze doplnit jako samostatné komponenty nebo je vytvořit z některých, již provozovaných dominantních systémů. Je však potřeba mít na mysli celé portfolio agend úřadu, tedy i ty agendy, které v současném systému nemají žádnou nebo minimální SW podporu.



4.1.3 SW architektura Vyžaduje orientaci na skupinu kompatibilních produktů.

4.1.4 HW architektura Infrastruktura je dána současným vybavením, a záměrem budovat technologické centrum ORP. Zvolená varianta musí těmto skutečnostem odpovídat a musí tedy být konzultována v rámci příslušných proutků.

4.2 Finanční varianty Finanční horizont plně integrovaného systému ve smyslu vize eGovernment realizovaného řadou centrálních projektů je naprosto mimo rozsah projektu řešitelného v rámci Výzvy č. 06 IOP. Proto finanční rámec dostupné dotační částky (1.529.412.‐ Kč, včetně 15% spoluúčasti obce a DPH) je základním omezením prostoru řešení.

4.3 Personální varianty Z provedené analýzy nevyplývají žádné návrhy na provedení úprav v personální oblasti kromě zajištění znalosti práce s novými komponentami systému a jejich významu v organizaci. Ve fázi realizace projektu je nezbytné kvalitní personální zajištění práce všech týmů projektu.

4.4 Organizační varianty Organizační rámec projektu nemá vliv na jeho realizaci. Je třeba uvažovat založení a fungování projektového řízení ve fázi realizace. Jednotlivé celky, které bude třeba implementovat, mohou být relativně nezávislé. Projekt po své implementaci zvýší nárok na vnitřní komunikaci jeho uživatelů (například mezi oddělením personalistiky a informatiky) z důvodů zajištění fungování systémových vazeb.



5 Celkové hodnocení a výběr doporučené varianty řešení Na závěr analýzy je proveden výběr vhodných variant celkového řešení a zpracováno celkové hodnocení. Celková požadovaná funkcionalita doporučené varianty bude Management identit 1.2. Referenční Organizační struktura ‐ Řídící modul pro evidenci (okamžitý stav) stromové organizační struktury úřadu umožní vytvoření stromové struktury odborů, oddělení, rolí (pozic) a pracovní náplně organizačních celků (přiřazení zaměstnanců se děje vazbou na referenční evidenci zaměstnanců nebo ručně). 1.3. Zaměstnanci – rozhraní ‐ Evidence zaměstnanců existuje ve mzdovém systému. Navržený systém zajistí její využití jako referenční evidence. 1.6. Katalog agend, práv a povinností ‐ Evidence agend (procesů, služeb), rodný list agendy, kroky, které agenda vyžaduje a za něž je možno (nutno) mít odpovědnou osobu. V současných strukturách nebývá realizován, agendy se definují až na úrovni oddělení. Důležitá je identifikace aplikace, která agendu podporuje. Základní funkcí je přiřazení práva k agendě a dílčímu úkonu agendy. Tak vzniká přehled práv a povinností na úrovni ORP. 1.7. Katalog aplikací a oprávnění ‐ Evidence aplikací (procesů, služeb), které agenda vyžaduje a za něž je možno (nutno) mít odpovědnou osobu. V současných strukturách nebývá realizován. Vhodné je vybudovat úplný přehled použitých aplikací ve vztahu k agendě. Pokud je daná aplikace je způsobilá, bude možno přiřazovat práva k aplikaci v různých krocích. Minimální je právo spuštění aplikace. 3.1.1 Prezentace služeb a org. struktury ‐ Požadavek definovaný v dokumentu „Vnitřní organizace úřadu“, je základem komunikace občana s úřadem. Je výsledkem implementace identitního systému (IDM).

4.2. Vazba organizační struktura –adresářové služby 4.5. Vazba ‐ přiřazení práva k aplikaci 4.6. Vazba ‐ přiřazení práva k agendě 4.7. ePUSA plnění dat 5.8.3. Evidence certifikátů

Portál úředníka ‐ Sjednocuje uživatelské pracovní prostředí úředníka na jeho stanici, integruje ovládání jím používaných aplikací a agend z různých systémů na různém stupni, podle hloubky propracování systému uživatelských oprávnění.

1.1 Prezentace služeb a org. struktury 5. Workflow mimo SpS 3. Dokumenty mimo SpS 3. Portál úředníka 3.1. HelpDesk 3.2. Rezervace zdrojů 3.3. Žádanky o schválení 3.4. Dovolená 3.5. Infodeska 3.6 Evidence certifikátů 4.1. Evidence certifikátů Spisová služba ‐ rozhraní 2.6.5. Integrace spisové služby a okolí Back Office 4. Agendy vnitřní, nepokryté SW 4.1. Evidence psů 4.2. Vidimace a legalizace 4.3. Dopravní stavební úřad 4.3. Konektory CzP

5.1

Materiálové vstupy

V rámci projektu nebudou žádné materiálové vstupy

5.2

Lokalita řešení

Lokalitou řešení části III. Vnitřní integrace úřadu obce s rozšířenou působností je Městský úřad Rychnov nad kněžnou.

5.3 Technické řešení Vnitřní integrace úřadu města Rychnov nad Kněžnou – Příloha 2 Strana 14 (celkem 24)


Technické řešení bude konkretizováno dodavatelem řešení.

5.4

Organizace a režijní náklady

Režijní náklady budou tvořeny ročními poplatky ve výši cca 17% z ceny licencí.

5.5

Lidské zdroje, vlastníci a zaměstnanci

Z provedené analýzy nevyplývají žádné návrhy na provedení úprav v personální oblasti kromě zajištění znalosti práce s novými komponentami systému a jejich významu v organizaci. Ve fázi realizace projektu je nezbytné kvalitní personální zajištění práce všech týmů projektu.



6 Závěr „Analýza aktuálního stavu vnitřního chodu úřadu“ tvoří povinný dokument pro zpracování části III. Výzvy č. 06 – „Vnitřní integrace úřadu obce s rozšířenou působností“ a detailně mapuje současný stav.



Příloha 1 ‐ Seznam zkratek Zkratka AD AIS EOS ePUSA eSpSl HW ICT ISZR MÚ PVS RPP SpSl SW TC WF ZR

Význam Active Directory Agendový informační systém Systémy pro evidenci organizační struktury Elektronický portál územních samospráv Elektronická spisová služba Hardware Informační a komunikační technologie Informační systém základních registrů Městský úřad Portál veřejné správy Registr práv a povinností Spisová služba Software Technologické centrum Workflow Základní registry



Příloha 2 ‐ otázky k analýze současného stavu Máte referenční organizační schéma (klasický „pavouk“)? Ano, je uveden na www 1. 2.

Kdo jej vytváří? Kancelář tajemníka, neudržují pro PO a ostatní …

Kancelář tajemníka, tajemník 3.

Kdo jej vydává? Kancelář tajemníka …

Kancelář tajemníka, tajemník 4.

Máte organizační řád s popisem náplně práce jednotlivých odborů, oddělení, organizací?

5.

Z jakého zdroje čerpáte pracovní náplně a činnosti? (katalog činností, katalog prací MPSV… vlastní popis)

ano Z katalogu prací MPSV – dáváme vlastní texty navíc ‐ z praxe 6.

Organizační schéma a organizační řád jsou aktuální a aktualizovány? – jak často? z jakých důvodů?

Aktualizují podle potřeby (např. odebrání činností). Nutno vždy schválit radou. Možnost zkrátit čas aktualizace. 7.

Je pro vás změna organizační struktury obtížným procesem?

Není vždy stejné, někdy jednoduché, někdy velký problém (stavební úpravy, noví lidé, příkladem byl CzP) 8.

Posuzujete varianty změn organizační struktury – modelujete dopady navrhovaných změn?

Děláme to tradičně, formou týmové spolupráce tajemníka a jeho kanceláře. Možnosti nutno dále prověřit, určitou SW podporu tohoto procesu by bylo možné uvažovat. 9.

Uchováváte nějak starší verze organizačního schématu a řádu? (např. jak úřad vypadal za určitého politika?) Pamatujete si, jak to bylo minulý rok – potřebujeme to?

Ano, máme „papírovou“ dokumentaci, kterou za tímto účelem můžeme použít. Určitě lze uvažovat o možnosti podpořit SW. 10. Využíváte nějaký SW na kreslení organizačních schémat, modelování procesů apod.? Nevyužíváme – maximálně PowerPoint, SW podpora není nezbytná. 11. Role (povolání, pozice ‐ funkce jako vedoucí, zástupce, referent, referent, právník) dle katalogu prací (469/2002 Sb., 137/2009 ) – kdo to navrhne a stanoví? Přílohou organizačního řádu jsou „malá schémata“, dvě varianty – funkce a jméno – v excelu, které vytváří pan tajemník. Eviduje např. třídění na úředníky a neúředníky a další údaje (plánuje profesní růst)! Spisová služba rovněž udržuje v tomto smyslu organizační strukturu. Je to ovšem jiný systém, nežli je systém pana tajemníka, nepropojený s ostatním SW. 12. Máte k organizačnímu řádu přiřazeny role (funkční místa, pozice) dle předchozího bodu?

Je ve více systémech – viz bod 11. 13. Je přiřazení rolí přístupné uživatelům uvnitř systému?

Je – prostřednictvím www – stejně jako pro veřejnost. 14. Je přiřazení rolí přístupné uživatelům vně systému?

Je – prostřednictvím www. Není aktualizováno s požadovanou periodou 1 den. Na www se dostane po doplnění v publikačním systému – to je tedy opět samostatná evidence. 15. Jak často připravujete změny v tomto uspořádání? Udržíte přehled aktuální se zpožděním 1 den?

Je to velmi časté, důvodů je mnoho, aktualizaci 1 den určitě nejsme schopni splnit. 16. Máte evidenci ve formě databázového systému?

Máme několik, neprovázaných – viz výše. 17. Máte přiřazení rolí (funkčních míst, pozic) evidováno v nějaké databázi (například v rámci personálního systému)?



V personální systému VEMA není rozvinuta implementace personalistiky. Role jsou evidovány v rámci tabulek pana tajemníka. … přesunout pod 11 18. Pokud ano, prosíme o stručnou charakteristiku produktu (Excel, koupený systém, značka)

Vema – nepoužívají personalistiku … excel, publikační systém… 19. Je tato evidence přístupná na internetu pro orientaci veřejnosti?

Publikují na WWW organizační strukturu, přijatý člověk je druhý den na WWW, není to přímo z databáze 20. Jak připravujete změny a evidujete stav přiřazení zaměstnanců na role, pracovní pozice?

Pan tajemník ve svém systému přiřadí zaměstnance na pozici, na návrh vedoucího odboru. 21. Máte zařazení zaměstnance na pozici evidováno v nějaké databázi (např. personální systém)? V tabulkách pana tajemníka. 22. Máte podchyceno zastupování v organizaci?

Pan tajemník ve svém systému, je to v náplních práce, spisovka to neřeší. 23. Vytváříte automatizovaně popis pracovní náplně zaměstnanců dle katalogu prací? (nebo prostřednictvím rolí?) Nevytváříme (pracovní náplně máte tedy popsány nějakou šablonou, kterou vždy použijete. 24. Jak často připravujete změny zařazení zaměstnance – v úrovni odboru, oddělení, je vaše evidence aktuální?

Nelze vyjádřit. 25. Je přijetí nového zaměstnance podporováno automatickým přiřazením práv a povinností, vybavením atd.?

Není 26. Máte řešenu bezpečnostní směrnici (přiřazení oprávnění přístupu k datům a funkcím agendy (nejen pouze u automatizovaných funkcí)!?

Máme provedený bezpečnostní audit a vytvořenu směrnici, v současné době se ji snaží naplnit … Velmi důležitá by byl například evidence certifikátů! Agenda (služba, proces) Agenda (činnost, administrativní služba) je řešení podání, o kterém je nutné rozhodnout (různou formou jako rozhodnutí, smlouva, výnos). Jak tomu říkáte? Vyhovuje vám tento slovník? Jaký pojem použijeme? V rámci

veřejné správy lze rozeznat stovky agend. Povinnost jejich registrace agend vyplývá ze zákona 111/2009 sb. o základních registrech veřejné správy. Pro orientaci lze použít Katalog prací MPSV, nebo Katalog činností ORP MVČR. Agendy lze členit •

•

Vnější agendy – jsou iniciovány podáním občana, nebo organizace, nebo vnitřním impulsem (zavedení řízení) směřujícím vůči okolí – vnější služby, jsou jedinečné, např. následujících typů i. Smlouvy různého obsahu dle odborů ii. Právní spory v různých věcech (např. byty) iii. Správní řízení dle odborů iv. Příjmy a poplatky dle odborů v. Sociální agendy vi. Výběrová řízení dle odborů vii. Přestupky ‐ dle odborů Vnitřní agendy ‐ jsou například následující viii. Požadavky ‐ technické, administrativní, opravy … ix. Rezervace vnitřních zdrojů ‐ automobily, zasedačky, projektory …. x. Cestovní příkazy a žádosti o povolení xi. Požadavky (např. na školení, požadavek nákupu), xii. Objednávky (např. nákup spotřebního materiálu, služeb atd…) xiii. Rozpočet ‐ požadavek na zajištění financí, návrh rozpočtové změny …. xiv. Definice problému a jeho publikace xv. Požadavek (návrh) na svěření majetku xvi. Pořádání vnitřní akce ‐ školení atd … xvii. Žádosti o přístupové oprávnění k funkcím SW xviii. Vnitřní stížnosti, náměty, návrhy, iniciativy



xix. Komunikace projektů ‐ územní plán, výběrové řízení, příprava usnesení xx. Usnesení orgánů města xxi. Pracovní týmy, pracovní porady, úkoly z porad … Vnitřní agendy nejsou systematicky řešeny (pouze papírová žádanka), bylo by vhodné uvažovat o implementaci portálu úředníka. Řešení je možno doporučit. 27. Víte, jaké konáte činnosti (agendy)? Máte nějaký soupis agend ‐ katalog? Nemají, MV mělo dělat katalog … na základě toho budou přidělovány peníze, souhlasí s návrhem řešení 28. Máte katalog agend vedený v nějaké databázi? Ne, ‐ další dotazy (do č 50, kromě 43) na toto téma jsou bezpředmětné! 29. Jak často a z jakých důvodů tento katalog aktualizujete? 30. Máte provázán výkon agend s organizační strukturou? (vazbu agend (činností) a organizační struktury)? 31. Udržujete tento popis? Jak často? Je nyní aktuální? (eGovernment to bude chtít denně prostřednictvím Registru práv a povinností). 32. Máte popsáno, kdo, kde (kteří úředníci), jak a které vykonávají agendy? 33. Je tento popis evidován v počítačové databázi? Každá agenda má určitou posloupnost kroků (úkonů) – proces, každý krok má určitou důležitost

Vnější podnět přijde od občana, nebo organizace různými cestami ‐ např. datovými schránkami

Distribuce Kontrola Přidělení Zpracování Vyřízení

Vnitřní podnět přijde od jiného zaměstnance úřadu, např. mailem spisovou službou

Úřad ‐ prostředí

Žadatel zašle podání

Podnět (podání)

Podání je doručeno příslušnému odboru (oddělení) prostřednictvím spisové služby Odbor (oddělení) kontroluje základní údaje žádosti, ověří identity subjektů, objektů a lokalit Vedení odboru přidělí případ k vyřešení konkrétnímu zaměstnanci, nebo skupině Pověřený zaměstnanec zodpovídá za vyřešení a spolupráci dalších úředníků v rámci „kolečka „ Je zpracován výsledek ‐ smlouva, rozhodnutí, stanovisko … a jsou vyřízeny všechny aspekty komunikace úřadu a žadatele

Uzavření Případ musí být řádně zdokumentován v rámci spisu a zejména vyplývajících finančních transakcí.

34. Máte popsány kroky agend – žádných, některých (důležitých), všech? 35. Je tento popis veden v nějaké databázi? 36. Víte, jaké mají zaměstnanci v konkrétní agendě povinnosti a odpovědnost – v rámci jednotlivých kroků agendy? 37. Agenda vždy vyžaduje určité znalosti – máte evidenci kompetencí zaměstnanců k výkonu agendy? 38. Agenda má své nezbytné vybavení (tužky, papír, zařízení (kopírka, foto, kamera, GPS) – udržujete nějak přehled o tom, jaké vybavení kdo potřebuje? 39. Agenda může vyžadovat komunikaci s jinými úředníky, i externími organizacemi – kolečko, další písemnou komunikaci s žadatelem atd. – máte takový přehled o agendách 40. Máte detailnější přehled o průběhu agend? 41. SW pro řízení procesů (tzv. workflow) máte? Vazba na další SW? V rámci spisové služby ‐ VERA – ano, řídí oběh dokumentů, pouze některé agendy mají přímou návaznost, ostatní to připojí prostřednictvím rozhraní. 42. Modelujete procesy agend v rámci nějakého modelovacího systému? Aktualizujete tyto modely? 43. Vytváříte systematicky popisy životních situací a agend, které se k nim vztahují? 44. Evidujete pracovní pozice (role funkce) ve vazbě na katalog agend (služeb)



45. Máte přehled, které agendy jsou podporovány nějakým SW? 46. Máte přehled, které agendy nejsou podporovány žádným SW? 47. Máte evidován SW – jednotlivé aplikace, řídíte licenční politiku? 48. Víte, kdo jej smí užívat? 49. Máte stanovena pravidla přístupu k SW? Kdo má jaká přístupová práva k funkcím SW a s jakými daty pracuje?

Řešeno v každém systému samostatně. 50. Jak máte evidovaná uživatelská konta? AD nemají, IM také ne 51. Máte tyto evidence zpracovány v nějakém databázovém prostředí?

Máme VERA – Fénix, předpisy a pohledávky se účtují prostřednictvím papíru ,doklad pro účtování se předá do účtárny. 52. Máte detailní a úplný přehled pohledávek spojených s agendami? (popište situaci)

Určitě možno zlepšit! Systémy od r 97, registry a systémy s registry … 53. Máte detailně řešenu vazbu na ekonomický systém?

Nemáme 54. Jaké SW prostředky za tímto účelem používáte a jak jsou provázány v rámci celého procesu (včetně předpisů plateb, platby, vymáhání…)

Systém VERA včetně stavební – FENIX (vydané, došlé faktury) je relativně stabilní, živnostenský ICZ, OK systém Vymáhání věcí, které jsou ve VERA, otázka, jak je to (zřejmě duplicita pořízení dat). 55. Jak řešíte oblast závazků a tedy požadavků na rozpočet, jeho krytí, řízení cash flow …

Rozpočet je připraven systémem 3. Strany …. Zřejmě existuje automatický přenos s FENIX (prosím potvrdit) Kontrola objednávek proti rozpočtu – osobní odpovědností, automatizovaně zřejmě ne. 56. Máte řešenu detailní evidenci majetku (podle skupin) v celém jeho životním cyklu (včetně údržby)?

T‐Mapy – včetně smluv, pouze jako evidence – nikoliv platby! 57. Umíte zpracovat celkové detailní saldokonto za partnera konsolidované za oblast pohledávek i závazků?

Nějak to jde, ale zřejmě po částech – prosím prověřit

Každá agenda produkuje dokumenty a může používat pro jejich vytvoření navržené šablony, nebo elektronické formuláře 58. Používáte nějaký systém pro správu dokumentů v elektronické podobě?

Kdo používá agendu ve VERA, má VERA, každý dokument se archivuje, kdekoliv použiji spisovku, mám dokument v archivu … pokud je potřeba tajemník vyžádá dokumenty. Dokumenty dosud neskenujeme. 59. Komunikuje s tímto systémem vaše spisová služba?

Ano – je to v jejím rámci. 60. Komunikují s tímto systémem vaše agendové systémy?

Pro agendy mimo VERA nemají DMS (je toho dost), mohou to vytvořit ve spisovce – založit č.j., a potom je prostřednictvím spisovky přístupný a uložen v DMS spisovky. Systém však nemá všechny rysy DMS. 61. Je tato komunikace otevřena pro všechny agendy?

Asi ne zcela pro všechny

V rámci agendy řešíte jednotlivé případy.Případ se může týkat více organizačních útvarů. 62. Jste schopni žadateli zprostředkovat elektronicky informace o stavu případů, které řešíme na jeho podání?

Ze spisovky pouze kde to je. Není řešeno detailní WF – například tzv. kolečka, Spisovka to může řešit, životní prostředí to používá. 63. Jste schopni zpřístupnit žadateli dokumentaci a údaje o finančních transakcích, které jsou s případem spojeny?



Dokumentaci spíše ano – prostřednictvím spisové služby, finanční údaje Případy zpracovávají zaměstnanci, kteří jsou zařazeni na nějaké pozici –plní nějakou roli (např. referent). 64. Víte vždy přesně, který zaměstnanec v daném okamžiku řeší jaký případ?

Ano – prostřednictvím spisové služby. 65. Víte, kdo přidělil případ určitému zaměstnanci?

Ano – prostřednictvím spisové služby (spisové uzly) Agendy mohou konat externisté,nebo můžete služby pro výkon hlavní činnosti nakupovat (posudky). 66. Máte o takových vztazích přehled?

Např. stavební – adresář projektantů, obecně je to velmi obtížné, například obeslané subjekty 67. Kdo a jak jej udržuje?

Různě podle situace a konkrétní agendy – není nijak „centrálně“ upraveno. Životní cyklus případu je určen procesem agendypřípad může být řešen různými systémy na různých místech organizace, evidován různými SW systémy. Udržujete souvislost evidovaných případů? 68. Máte popsán systém základních číselných řad, které na případ mohou navázat? i. ČJ, identifikace v evidence agendy, V.S., ID subjektu, ID objektu, lokalizace …. Nutno promyslet vazbu vera – FENIX, v.s. si řeší to účtárna ve své kompetenci, interní dokument (směrnice) zřejmě není, 69. Žadatelé a objekty (parcely, domy …) v agendě musí být přesně identifikovány, máte nějaký systém ověření identity subjektu, objektu a adresy proti referenční evidenci?

Kde je ve VERA, je to prostřednictvím registrů – spisovka, Fénix si to eviduje samostatně! 70. Je možné zaručit, že identifikace subjektů, objektů a míst jsou v různých systémech stejné a lze rozpoznat všechny záznamy vedené úřadem za jednotlivce? Za hlavní systémy back office považujeme • Personalistika a mzdy • Ekonomický systém • Spisová služba • Velké agendy (např. poplatky ze psů, majetkové agendy, …) • Registr a Evidence stran (partnerů) • Registr a Evidence objektů • Registr a Evidence adres Není jeden dominantní ani referenční systém 71. Máte evidenci majetku propojenou s GIS?

Ano 72. Potřebujete informace o aktivitách na majetku? (např. zjistit správce, zda tam probíhají nějaké záměry)

Něco řeší T‐Mapy, viz otázka 58 (sloučit) 73. Máte zpracovánu směrnici o nakládání s majetkem?

Ne – řeší se případ od případu 74. Jak udržujete popis organizačních struktur a dalších, výše uvedených prvků u organizací MČ?

Neudržujeme jejich organizační strukturu. 75. Jaké nejdůležitější vnitřní směrnice máte, proč jsou pro vás důležité? Pracovní, spisový, podpisový řád … bezpečnostní směrnice. 76. Evidence aplikací a jejich instancí (s vazbou na agendy a databáze?) ‐ existuje, je udržována?

Víme, co máme, evidence není nijak formalizována. 77. SW pro řízení přístupových oprávnění k funkcím a datům, eventuálně úkonům procesů • Zda vůbec, kde a jak je to řízeno? • LDAP, AD, HR, jiné? • SW pro personalistiku?


Studie proveditelnosti VIÚ Rychnov nad Kněžnou – Příloha 2 •

Vazba mezi HR, AD, LDAP

Nemáme 78. Synchronizace dat s aplikacemi pro řízení uživatelských přístupů a správu identit • Existuje systém ovládání uživatelských oprávnění – řízení přístupu k funkcím a datům aplikací?

a. Jednoznačná identifikace uživatelských kont • •

FIM? Nebo každá aplikace řeší zvlášť? Řešení přístupu externích pracovníků, dodavatelů, k aplikacím, datům a funkcím

b. Propojení uživatele a pracovníka • •

Kde – v AD, LDAP. Vazba 1:1 nebo 1:N Řešení externích pracovníků, dodavatelů, …

c. Možnost nastavení odlišných oprávnění uživatele v každé instanci téže aplikace •

(ano / ne)

d. Sdružování oprávnění do profilů! •

sdružování rolí do profilů?

e. Hromadné řízení uživatelských přístupů a oprávnění •

f.

Nebo se vše dělá pracně ručně? Máte nějakou aplikaci?

Export dat (např. zveřejnění telefonního seznamu) • •

z aplikace pro evidenci organizační struktur/AD atd. publikace účelových seznamů

Nemáme 79. Práce s databází elektronických formulářů – příjem formulářů • Formuláře – umožní efektivně formalizovat procesy • Používáte nějaký systém elektronických formulářů? Nemáme 80. Významný SW pro řešení činností (agend) – použité agendové systémy, existují nepokryté činnosti? • Prosíme o soupis SW včetně stručné charakteristiky jejich funkcí VERA a další – prosíme doplnit (viz tabulka) 81. Popis funkcí použité spisové služby • Je to „otevřený“ systém? • Předání dat mezi spisovou službou – agendovým systémem – ISDS a naopak – je v pořádku? Spisová služba má všechny potřebné standardní funkce. 82. Integrace back office • Zahrnuje ERP, Agendy, HR, SpS, DMS, GIS • Jaké vzájemné vazby váš SW velmi kvalitně řeší? • Jaké vzájemné vazby váš SW naopak kvalitně, nebo vůbec neřeší? Z diskuse vyplývá, že systém je postaven na kombinaci produktů VEMA, VERA, Fénix, které nejsou nijak integrovány prostřednictvím automatizovaných vazeb. Žádný ze systémů nemá dominantní, nebo standardní evidence organizační struktury, partnerů, nebo objektů. Není zřetelné, zda je možno případy sledovat včetně detailního saldokonta partnerů města – tedy propojení na účetnictví. Účtování pohledávek a závazků se zřejmě děje tzv. „na hromady“. 83. Integrace agendových systémů • Datová integrace – strany (partneři), organizační struktura, objekty – správa kmenových dat agend – existuje vícenásobné evidování dat, žádná evidence není dominantní, nebo referenční. • Integrace datových forem DMS, GIS, Data) – ano v oblasti působnosti VERA – neposuzováno detailně • Evidence a identifikace případu včetně logování – ne zcela • Procesní integrace BO, integrační platforma – datová synchronizace systémů, regulace redundance – není použito


Studie proveditelnosti VIÚ Rychnov nad Kněžnou – Příloha 2 • •

Aplikační integrace – výměna komponent, vhodná kombinace komponent – prostředí je sourodé v oblasti VERA, není však řešeno vše není/je lepší mít ne vše od jednoho řešitele? – nediskutováno!

84. Měření výkonnosti, kvality a efektivity ‐ controlling vnitřních i vnějších služeb • Používané metriky a veličiny pro výkonnost, kvalitu a efektivitu? i. Sleduje se (jaké), nesleduje se? • Stanovení požadovaných, resp. prahových hodnot • Úkony procesu realizace činností (služby) jako poskytované výkony • Alokace nákladů na výkon • Zúčtování poskytnutých výkonů Neaplikují tyto metody. 85. ePUSA, nebo v budoucnu jiný systém pro plnění dat o ÚVS • Stav systému, je plněn, nebo ne? Vyplněny povinné věci. 86. Integrace s ostatními organizacemi územní veřejné správy • Je, není, částečně, ručně – jak Sociálka, úřad práce … 87. Integrace ORP – zřízené organizace • Je, není, částečně, ručně – jak PO rozpočtem, zřizovatelské funkce, Byty – správcovská firma – uzavírá smlouvy a výběr finančních prostředků (prosíme doplnit) Neprovozují žádný systém pro své organizace. 88. Integrace ORP – obce (jak na I. a II. tak i na sousední III.) • Je, není, částečně, ručně – jak? V oblasti spisové služby uvažují hostované řešení pro obce.


Analýza aktuálního stavu vnitřního chodu úřadu

Recommend Documents