Formulář žádosti o stanovisko Hlavního architekta eGovernmentu k architektuře funkčního celku pokrývaného smlouvou na provoz, podporu, údržbu, rozvoj a další k existujícímu ICT řešení – typ B3 Odbor Hlavního architekta eGovernmentu MV Praha, leden...
Formulář žádosti
o
stanovisko Hlavního architekta eGovernmentu
k architektuře
funkčního celku pokrývaného
smlouvou na provoz, podporu,
údržbu, rozvoj a další
k existujícímu ICT řešení –
typ B3
Odbor Hlavního architekta eGovernmentu MV
Praha, leden 2019
verze 6.0.1
UPOZORNĚNÍ: Přestože je formulář zveřejněn ve formátu umožňujícím změny, žadatel není oprávněn měnit strukturu vybraných otázek, či předepsaných odpovědí. Pokud se tak stane, Xxxxx Hlavního architekta eGovernmentu vyhodnotí takovou změnu jako porušení pravidel při schvalování a formulář bude vrácen bez vydání stanoviska.
Tabulka 1: Úvodní informace o žadateli funkčního celku: |
||||
Organizace žadatele |
Úřad pro zastupování státu ve věcech majetkových |
Rašínovo nábř. 390/42, 128 00 Nové Město Praha |
69767111 |
|
Ředitel pro informatiku nebo Statutární zástupce |
Xxxxxx Xxxxx |
ředitel odboru Projektového řízení a spisové a archivní služby |
xxxxxx.xxxxx@xxxxx.xx |
225 776 994 |
Kontaktní osoba funkčního celku |
PhDr. Xxxxx Xxxxxx, Ph.D. |
referent oddělení Spisové a archivační služby |
xxxxx.xxxxxx@xxxxx.xx |
225 776 194 |
Architekt funkčního celku |
Ing. et. Xxx. Xxxxxx Xxxxxxxxx |
ředitelka odboru Projektového řízení a centrálních aplikací |
xxxxxx.xxxxxxxxx@xxxxx.xx |
225 776 729 |
Datum vypracování žádosti: 24. 7. 2019 |
|
|||
Tabulka 2: Druh žádosti (žádost o stanovisko dle): |
|
Usnesení vlády č. 889, ze dne 2. listopadu 2015, ve znění pozdějších předpisů |
Ano |
Zákona č. 365/2000 Sb., o informačních systémech veřejné správy, ve znění pozdějších předpisů |
Ano |
Shrnutí charakteristik cílové charakteristiky funkčního celku
Popis, potřebnost a výstupy funkčního celku
Popis funkčního celku: |
ÚZSVM v rámci veřejné zakázky poptával zajištění provozní podpory systému, řešení provozních incidentů, poradenství, technickou a metodickou podporu, pravidelnou profylaxi vykonávané na roční bázi, drobné úpravy systému v rozsahu 25 v rámci jednoho čtvrtletí nebo dobou 3 po sobě následujících měsíců plnění smlouvy. Nevyčerpané člověkodny (MD) budou převedeny k dočerpání do dalšího období. Maximální rozsah poskytnutý dodavatelem za jedno období je omezen na 75člověkodnů (MD) . Dále v rámci veřejné zakázky byl poptáván rozvoj systému, pracovně nazvaný ze strany ÚZSVM „Žádost o posouzení projektu dle usnesení vlády č. 889 ze dne 2. listopadu 2015“. Garantem projektu se stal Xxxxxx Xxxxx, ředitel odboru Informatiky a spisové služby. Jeho součástmi byly: - Vytvoření modulu registru smluv v ISSSL a dále v souladu se zákonem č. 340/2015 Sb., o Registru smluv zajistit plynulý proces vypravení povinně registrovaných smluv a objednávek do Registru smluv MV. - Splnění požadavků na bezpečnost ISSSL, jakožto významného informačního systému, která je stanovena na základě zákona č. 181/2014 Sb., o kybernetické bezpečnosti. - Implementace podmínek eIDAS v souladu s Nařízením EP č. 910/2014 Sb., o službách vytvářejících důvěru a zákonem č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu.
V oblasti rozvoje jsme dosud nezahájili práce v oblasti kybernetické bezpečnosti a registru smluv. V oblasti eIDAS byly nasazeny certifikáty v souladu s nařízením, realizace byla čerpána z prostředků servisní smlouvy (bezplatné MD.
Výše zmíněná zakázka byla konzultována s Ministerstvem vnitra ČR. Stanovisko odboru Hlavního architekta eGovernmentu k projektu: „Podpora a rozvoj Informačního systému spisového služby Úřadu pro zastupování státu ve věcech majetkových k č.j. UZSVM/A/16675/2017-PRIP pod označením: MV-47786-9/OHA-2017. |
Architektonické informace k funkčnímu celku
Dodržení architektonických principů NA VS ČR
Odbor Hlavního architekta eGovernmentu MV předpokládá soulad funkčního celku s principy Národní architektury veřejné správy ČR tak, jak jsou popsány v metodickém pokynu k formuláři. Případný nesoulad v návrhu je možný výhradně, pokud je k němu vyplněna žádost o výjimku, jejíž schválení bude rovněž předmětem posouzení. Otázky na doložení souladu s architektonickými principy jsou obsaženy průběžně v celém formuláři.
Enterprise architektura funkčního celku a její kontext
Tabulka 5: Architektonický model:
V rámci Enterprise Architektury projektu přiložte jako přílohu model exportovaný ve standardizovaném výměnném formátu The Open Group ArchiMate Model Exchange File Format
Ne, model nemohl být z objektivních důvodů přiložen
Případně vysvětlete, proč není model přiložen ve standardizovaném formátu či není přiložen vůbec.
Pokud MV stačí pouze obrázky, můžeme je dodat. Pokud chce funkční model, kde se spouštějí jednotlivé procesy, pak prosíme o případné zaškolení některého z našich pracovníků. Peníze na to, abychom si školení uhradili sami, nemáme.
Motivační architektura - strategie a směrování
Tabulka 6: Vysvětlete, proč projekt realizujete v této podobě a čeho jím chcete dosáhnout. Pro vysvětlení motivace použijte zejména pojmy z odpovídajícího modelu motivační architektury (motivátory, zainteresované, cíle, principy, podmínky, architektonické požadavky): |
Dotazník je zpracováván na základě zákona č. 499/2004 Sb., O archivnictví a spisové službě. ÚZSVM je jako veřejnoprávní původce povinen vést spisovou službu v elektronickém systému spisové služby. V podmínkách ÚZSVM je tímto systémem ISSSL s vlastnostmi plnohodnotného Document management systému. Náš elektronický systém spisové služby je vyroben na míru firmou Atos. V současné době je ISSSL připravován na nutné změny související s nově připravovanou legislativou. (Jedná se o překotně prosazovaný zákon o právu na digitální službu, často také velmi nesprávně označovaný jako „digitální ústava“. |
Efektivita funkčního celku – výkonnostní architektura
Tabulka 7: Vysvětlete dopad funkčního celku na hospodárnost, účelnost, účinnost, časovou a kvalifikační náročnost a na kvalitu služeb v organizaci (viz metodika TCO zveřejněná zde): |
Stávající podoba funkčního celku je hospodárná, plní účel legislativy (s výjimkou posledních změn a je účinný. Míra užitečnosti stávajícího systému bude dostačující do té doby, dokud jeho provozování, úpravy a údržba budou levnější. K náhradě by mělo dojít v okamžiku, kdy náklady na údržbu budou již neúnosné a nahrazení novým ISSSL bude úspornější. |
Tabulka 8: Přehled požadovaných cílových parametrů SLA nových nebo měněných služeb: |
|||
Název v rámci funkčního celku nově zřizované nebo měněné služby |
Specifikace SLA parametru služby |
Sjednaná mezní hodnota SLA parametru |
Sjednaný způsob měření hodnoty SLA |
nerelevantní |
Máme pouze smlouvu o poskytování podpory a rozvoje, kde v příloze č. 2 se stanovuje způsob zajištění provozní úrovně systému. Tím se rozumí provozní analýza. |
- |
- |
Tabulka 9: Popis klíčových měřitelných ukazatelů výkonnosti (KPI): |
|||||
Název v rámci funkčního celku nově zřizované nebo měněné služby vůči koncovému klientovi |
Předpokládaný počet transakcí za rok |
Kolik stojí každá ukončená transakce bez DPH? [Kč] |
Jaké % uživatelů je spokojeno s poskytovanou službou? |
Jaké % transakcí je úspěšně dokončeno? |
Jaké % uživatelů si zvolí raději elektronickou formu služby než ne-elektronickou? |
Nerelevantní (týká se služeb poskytovaných ven) |
- |
- |
- |
- |
- |
Byznys architektura - poskytování veřejných služeb
Tabulka 10: Katalog organizačních jednotek, aktérů a rolí: |
||
Název objektu |
Počet uživatelů služby / IS |
Vysvětlení významu objektu |
Aktér (organizace, organizační jednotky / úředníci, klienti veřejné správy) |
||
Zaměstnanec úřadu (1756) |
1756 |
Běžný uživatel systému |
Dodavatel (3) |
4 |
Programátoři, analytik, project manager |
Role aktérů při výkonu a příjmu služby |
||
Administrátor Generální ředitel 1. náměstek náměstek |
|
|
Ředitel ÚP Ředitel odboru Vedoucí oddělení Sekretariát Referent Právní zástupce Podatelna Spisovna Manipulant spisovny Hlavní účetní Správce rozpočtu Dispečer autodopravy Vyhledání – obecné Vyhledání – majetkové Vyhledání právní Vyhledání – provozní Vyhledání ÚP |
|
|
Tabulka 11: Katalog funkcí a procesů veřejné správy a ve veřejné správě: |
||
Název objektu |
Vysvětlení významu objektu |
|
Agendové funkce (agendy dle RPP, a dále neregistrované, podpůrné a provozní agendy nebo funkční oblasti) |
||
Archivace
|
Evidence příchozích a odchozích dokumentů, fakturace. |
|
Dovolenky |
|
|
Evidence smluv |
|
|
Evidence interních dokumentů |
|
|
Skartační řízení |
|
|
Tvorba dokumentů |
|
|
Tvorba spisů |
|
|
Procesy v agendách nebo funkčních oblastech |
||
|
|
|
|
|
|
Funkce (činnosti) zařazené v procesu nebo samostatně existující na podporu agend / funkčních oblastí (NEPOVINNÉ) |
||
Kompletní workflow |
|
|
|
|
|
Tabulka 12: Katalog (interních a externích) služeb: |
|||
Název služby |
Kdo poskytuje službu |
Kdo je konzumentem služby |
Výčet použitých obslužných rozhraní služby |
Interní služby veřejné správy (dovnitř úřadu či subjektu VS) |
|||
Interní služby poskytuje úřad sám sobě. |
Odbor Informatiky a spisové služby |
Zaměstnanci úřadu |
Tlustý klient / tenký klient, který je deaktivován. |
Spisová služba |
|
|
|
Externí služby veřejné správy (vně úřadu či subjektu VS) |
|||
Neposkytujeme. |
|
|
|
|
|
|
|
Tabulka 13: Využití front-office rozhraní předmětem funkčního celku: |
||
Rozhraní |
Využití |
Popis využití rozhraní funkčního celku |
Asistovaná přepážka |
Nerelevantní |
|
Webový portál |
Nerelevantní |
Úřad má možnost využít tenkého klienta pro interní potřeby, zatím ho nepoužívá |
Datová zpráva (ISDS) |
Ano |
|
Elektronicky podepsaný dokument do e-Podatelny |
Ano |
|
Listinnou cestou do podatelny |
Ano |
|
Tabulka 14: Využití propojeného datového fondu: |
||||
Služba |
Použito |
Č. žádosti o výjimku |
Vysvětlení |
Zákonné zmocnění k přístupu |
Čtení referenčních údajů FO (ROB) |
Nerelevantní |
|
|
|
Zápis nových FO (ROB) |
Nerelevantní |
|
|
|
Editace referenčních údajů FO (ROB) |
Nerelevantní |
|
|
|
Čtení referenčních údajů PO (ROS) |
Nerelevantní |
|
|
|
Zápis nových organizací (ROS) |
Nerelevantní |
|
|
|
Editace referenčních údajů PO (ROS) |
Nerelevantní |
|
|
|
Čtení referenčních údajů míst a adres (RÚIAN) |
Nerelevantní |
|
|
|
Zápis nových územních id. (RÚIAN) |
Nerelevantní |
|
|
|
Editace referenčních údajů míst a adres (RÚIAN) |
Nerelevantní |
|
|
|
Zápis a využití práv a povinností při využívání údajů agend (RPP) |
Nerelevantní |
|
|
|
Zápis rozhodnutí o změnách údajů agend dle § 52 zák. 111/2009 Sb. (RPP) |
Nerelevantní |
|
|
|
Čerpání informací z agend jiných úřadů (Integrační platformy, eGSB) |
Nerelevantní |
|
|
|
Poskytování informací agendám jiných úřadů (Integrační platformy, eGSB) |
Nerelevantní |
|
|
|
Tabulka 15: Využití dalších klíčových prvků eGovernmentu v byznys architektuře funkčního celku: |
|||
Název |
Popis |
Použito |
Č. žádosti o výjimku |
Identifikace, autentizace úředníka |
Identifikace osob vstupujících do procesu je řešena v souladu s JIP/XXXX |
Nerelevantní |
|
Identifikace, autentizace klienta |
Identifikace osob vstupujících do procesu je řešena v souladu se zákonem č. 250/2017 Sb., o elektronické identifikaci |
Ano, použito |
|
Doručování |
Využití Datových schránek pro účely doručování od OVM soukromoprávním subjektům a mezi OVM navzájem |
Ano, použito |
|
Dodávání |
Využití datových schránek pro účely dodávání mezi soukromoprávními subjekty navzájem |
Nerelevantní |
|
Provádění úkonů |
Využití Informačního systému datových schránek pro účely příjmu úkonů učiněných soukromoprávním subjektem vůči OVM (např. podání) |
Ano, použito |
|
Tabulka 16: Identifikace, autentizace a autorizace subjektů/uživatelů v jejich rolích: |
||
Služba využívající identifikaci, autentizaci a autorizaci |
Vysvětlení způsobů identifikace, autentizace a autorizace |
Použitý prostředek a druh autentizace |
Využívá služeb Active Directory. |
Elektronický podpis. Certifikát na čipové kartě |
Elektronický podpis. |
Model byznys architektury (výkonu veřejné správy) – pohled služeb veřejné správy
Tabulka 17: Dodržení architektonických principů byznys vrstvy: |
||||
Princip |
Požadavek |
Dodrženo |
Č. žádosti o výjimku |
Způsob a míra naplnění |
Dostupnost
|
Řešíte obecně přístupnost a použitelnost pro klienty se zdravotním postižením? |
Nerelevantní |
|
|
Řešíte přístupnost u webových stránek a rozhraní pro komunikaci s klientem? |
Nerelevantní |
|
|
|
Bude každá nová nebo zásadně měněná služba či proces vnitřně plně elektronická? |
Ano |
|
|
|
Bude možné učinit podání v plně elektronické podobě kdekoli (bez nutnosti následného dokládání papírových dokumentů) a kdykoliv (kromě okamžiků nezbytné údržby systémů)? |
Ano |
|
|
|
Použitelnost
|
Budou všechny formuláře služeb funkčního celku předvyplněny všemi úřadu/státu známými údaji klienta (vlastními či z PPDF)? |
Nerelevantní |
|
|
Bude klientům dostupná plná historie vzájemné komunikace s úřadem tak, aby byla využitelná pro opakované použití? |
Ano |
|
Poskytování informací, které vedeme o subjektu, na žádost účastníka řízení. Už je v současnosti řešeno v rámci modulu, nového jmenného rejstříku, typového spisu a elektronického skartačního systému. |
|
Důvěryhodnost
|
Bude zajištěno oboustranné garantované doručení a platnost elektronických dokumentů? |
Ano |
|
|
Bude zajištěno průkazné doložení úkonů z minulosti? |
Ano |
|
|
|
Transparentnost
|
Byl veřejnosti představen záměr a cíle funkčního celku? |
Ano |
|
|
Bude zajištěn přístup klientů ke všem svým řízením všemi dostupnými kanály eGovernmentu? |
Nerelevantní |
|
|
|
Spolupráce a sdílení |
Byly (budou) do návrhu služeb funkčního celku zapojeny ve vzájemné spolupráci odborné týmy napříč veřejnou správou? |
Ne |
|
|
Udržitelnost |
Představuje-li projekt nové nebo zásadně pozměněné IT řešení, bude realizováno nad procesně aktualizovanými byznys službami úřadu? |
Ano |
|
|
Tabulka 18: Vysvětlení v kontextu byznys architektury úřadu, tedy: |
|
Ne, nevznikají duplicity. |
|
Žádné. |
Vysvětlení byznys architektury funkčního celku: |
Navíc dovolenky, virtuální týmy, rekonstrukce spisů |
Aplikační architektura (aplikací a dat)
Aplikační architektura – část: Architektura informačních systémů
Tabulka 19: Katalog všech aplikačních komponent řešení a klíčových aplikačních funkcí: |
||
Typ prvku |
Název prvku |
Vysvětlení významu aplikačních komponent, funkcí a služeb |
Komponenty, funkce a aplikační služby vytvářené nebo významně měněné v rámci záměru (žádosti) |
||
služba |
spisová služba |
Viz uživatelská dokumentace |
služba |
fulltext |
Viz uživatelská dokumentace |
Ostatní komponenty, funkce a aplikační služby integrované na výše uvedené nebo jinak podstatné pro žádost |
||
služba |
|
|
služba |
|
|
Tabulka 20: Katalog aplikačních rozhraní (mezi dvěma různými komponentami A, B): |
|||
Název aplikačního rozhraní |
Komponenta A |
Komponenta B |
Vysvětlení obsahu a významu rozhraní aplikačních komponent |
Interní rozhraní (aplikací řešení mezi sebou, na aplikace uvnitř úřadu, případně resortu, krajské korporace, apod.) |
|||
CRS |
|
|
|
API |
|
|
|
ISMS |
|
|
|
Externí rozhraní (na aplikace eGovernmentu a jiných úřadů, případně jiná rozhraní) |
|||
Czechpoint, ISDS. |
|
|
|
Časová razítka |
|
|
|
Vzdálené pečetění |
|
|
|
Tabulka 21: Katalog aplikacemi podporovaných agend (vazební tabulka aplikací na katalog agendových funkcí v kapitole 2.2.3 - Byznys architektura): |
|
Realizovaný systém |
Agenda |
Spisová služba |
A 334 – agenda spisové služby |
|
|
Model aplikační architektury – pohled struktury aplikací
Model aplikační architektury – pohled komunikace aplikací
Tabulka 22: Katalog komunikačních (obslužných) rozhraní, kanálů koncových klientů: |
||||
Rozhraní |
Využití |
Počet uživatelských přístupů ročně |
Č. žádosti o výjimku |
Popis využití rozhraní funkčního celku |
Asistovaná přepážka |
||||
Přepážka úřadu |
Ano |
|
|
|
CzechPOINT (přepážka) |
Nerelevantní |
|
|
|
Call-centrum |
Ano |
Jde toliko o jednoduchou informační linku (7:30 – 16:00) |
|
|
Webový portál |
||||
Aplikace v portálu úřadu s autentizovaným klientem |
Ne |
|
|
|
Aplikace v Portálu občana jako střechovém portálu VS |
Nerelevantní |
|
|
|
Tlustý aplikační klient |
Ano |
|
|
|
Mobilní aplikace |
Ne |
|
|
|
CzechPOINT@office |
Ano |
|
|
|
Datová zpráva (ISDS) |
||||
Formulář v DS |
Ano |
|
|
|
Elektronicky podepsaný dokument do e-Podatelny |
||||
E-mail s elektronicky podepsaným formulářem |
Ano |
|
|
|
Webová aplikace pro zaslání elektronicky podepsaného dokumentu do e-Podatelny |
Ne |
|
|
|
Listinnou cestou do podatelny |
||||
Formulář listinou poštou |
Ano |
|
|
|
Formulář na listinnou podatelnu (osobně) |
Ano |
|
|
|
Jiné |
||||
E-mail s formulářem bez elektronického podpisu |
Ano |
|
|
|
Aplikace v portálu úřadu s neautentizovaným klientem |
Ne |
|
|
|
Aplikační rozhraní pro externí systémy |
Ano |
|
|
|
Tabulka 23: Dodržení architektonických principů aplikační vrstvy: |
||||
Princip |
Požadavek |
Dodrženo |
Č. žádosti o výjimku |
Způsob a míra naplnění |
Použitelnost |
Umožní design služeb i systému, v případě spolupráce úřadů na řešení životní situace/události klienta, řazení (orchestrování) do komplexního automatizovaného řešení? |
Nerelevantní |
|
|
Transparentnost |
Počítá projekt s prostředky pro zveřejňování měření a auditů výkonnosti poskytovaných služeb? |
Nerelevantní |
|
|
Bezpečnost |
Počítá projekt s auditovatelností a průkazností služeb veřejné správy a vytvářením auditní stopy (provozních logů) pro tento účel? |
Nerelevantní |
|
|
Udržitelnost
|
Byl upřednostněn nákup a implementace standardní služby před vývojem vlastního řešení? |
Nerelevantní |
|
Aplikace na klíč pro potřeby úřadu |
Umožní otevřená modulární architektura funkčního celku vyměňovat jednotlivé prvky řešení bez nutnosti měnit jejich okolí? |
Ano |
|
Pouze parametrizace systému |
|
Technologická neutralita |
Budou elektronické služby veřejné správy funkčního celku dostupné na všech běžně používaných klientských platformách? |
Nerelevantní |
|
|
Tabulka 24: Vysvětlení v kontextu aplikační architektury úřadu, tedy: |
|
Ne. |
|
Nejsou. |
Vysvětlení aplikační architektury funkčního celku: |
Doplnit vysvětlení rozdílů mezi naší verzí a std. |
Komunikace mezi systémy
Aplikační architektura – část: Datová architektura
Tabulka 25: Katalog základních datových entit funkčního celku: |
||
Objekt reálného světa, který je předmětem evidence |
Vysvětlení objektu |
Je objekt čerpán nebo poskytován jiným subjektům? |
Dokument (analogový, digitální). |
Jedná se o archivní pramen. |
Je poskytován uživatelům našich služeb ve formě rozhodnutí a výstupů. |
|
|
Zvolte položku. |
|
|
Zvolte položku. |
Tabulka 26: Využití datového fondu základních registrů a dalších agend: |
|||
Název |
Použito |
Vysvětlení |
|
Základní registry |
|||
Způsob vedení datového kmene |
Nerelevantní |
Není veden žádný. |
|
Evidujeme subjekty práva, které nejsou vedeny v ZR (např. zahraniční) |
Ne |
|
|
Evidujeme fyzické osoby, které nejsou vedeny v XXX |
Xx |
|
|
Využití údajů publikovaných prostřednictvím kompozitních služeb editorů Základních registrů |
|||
Evidence obyvatel (ISEO) |
Nerelevantní |
|
|
Č. žádosti o výjimku: |
|
||
Cizinecký informační systém (CIS) |
Nerelevantní |
|
|
Č. žádosti o výjimku: |
|
||
eGon Service Bus |
|||
Čerpání dat přes eGSB |
Nerelevantní |
|
|
Č. žádosti o výjimku: |
|
||
Publikování vlastních dat přes eGSB |
Nerelevantní |
|
|
Č. žádosti o výjimku: |
|
||
Tabulka 27: Způsob zajištění vedení dat s ohledem na otevřená data veřejné správy: |
|||
Požadavek |
Použito |
Vysvětlení |
|
Zajištění přístupu k datům |
|||
Budete mít zajištěn přístup k veškerým datům vedeným v databázích dotčených předmětem funkčního celku ve strojově čitelném a otevřeném formátu? |
Ano |
|
|
Č. žádosti o výjimku: |
|
||
Budete mít výše popsaný přístup k datům zajištěn bez dodatečných finančních nákladů? |
Ano |
|
|
Č. žádosti o výjimku: |
|
||
Budete moci se zpřístupněnými daty libovolně nakládat? |
Ano |
|
|
Č. žádosti o výjimku: |
|
||
Publikace výstupů ve formátu otevřených dat |
|||
Budou data vedená v databázích dotčených předmětem funkčního celku zveřejňována jako otevřená data? |
Nerelevantní |
|
|
Č. žádosti o výjimku: |
|
||
Jaké datové oblasti plánujete zveřejňovat jako otevřená data, kdy a na jakém stupni otevřenosti? |
Nemáme otevřená data. |
||
Tabulka 28: Nakládání s osobními a citlivými údaji |
|
Způsoby identifikace subjektů (FO, PO) v informačním systému (AIFO, IČO, rodné číslo nebo jiný identifikátor) |
|
Prostřednictvím CRS |
|
Způsoby zavedení základních principů práce s osobními a citlivými údaji dle GDPR: |
|
Zabezpečení zpracování: |
<vysvětlete využití: pseudonymizace, šifrování, integrity, důvěryhodnosti, apod. dle článku 32 GDPR>Osobní údaje jsou primárně uloženy v ext systému CRS. V ISSSL mohou být obsahem příloh zpracovávaných dokumentů, a zároveň obsahem metadat, které jsou nutné pro další zpracování. Tyto údaje jsou přístupné pouze prostřednictvím ISSSL. Pseudonymizace se neprovádí. V případě uložení příloh – jsou přílohy uloženy pod bezvýznamovým identifikátorem, a v rámci úložiště jsou šifrovány. |
Právo na přístup: |
<vysvětlete připravenost na umožnění přístupu ke všem údajů vedených o subjektu dle článku 15 GDPR> V současnosti není implementována funkcionalita pro vygenerování přehledu z ISSSL, který tyto informace poskytuje. Částečné informace je možné získat pouze ručním zpracováním.
|
Právo na opravu: |
<vysvětlete připravenost na umožnění opravy údajů vedených o subjektu dle článku 16 GDPR> Nejsou specifické nástroje na opravu dat. V rámci agendy spisové služby se jedná o obraz stupních dat tak, jak byly pořízeny/přijaty. Opravy na rovni CRS nejsou součástí ISSSL. |
Právo na výmaz: |
<vysvětlete připravenost na umožnění výmazu údajů vedených o subjektu dle článku 17 GDPR> Výmaz v rámci ISSSL je možný pouze v rámci skartačního řízení. Osobní údaje v CRS jsou mimo ISSSL. |
Právo na omezení zpracování: |
<vysvětlete připravenost na umožnění omezení zpracování údajů o subjektu dle článku 18 GDPR> Nelze omezit v ISSSl zpracování OU, pouze lze omezit přístup k přílohám a metadatům. |
Právo na oznamovací povinnost: |
<vysvětlete připravenost na umožnění oznamovací povinnosti ohledně opravy nebo výmazu osobních údajů nebo omezení zpracování dle článku 19 GDPR> Není součástí ISSSL. |
Právo na přenositelnost: |
<vysvětlete připravenost na umožnění přenosu všech údajů vedených o subjektu dle článku 20 GDPR> Je možné v rámci ISSSl dohledat, kde všude byly údaje použity, včetně příloh (fulltext). Jedná se ale o ruční zpracování. ISSSL nedisponuje specifickou funkcí k tomuto účelu. |
Tabulka 29: Dodržení architektonických principů datové vrstvy: |
||||
Princip |
Požadavek |
Dodrženo |
Č. žádosti o výjimku |
Způsob a míra naplnění |
Důvěryhodnost |
Jakým způsobem zajistíte, aby vzájemně vyměňované informace byly spolehlivé, přesné, relevantní a aktuální a aby klienti elektronické komunikaci důvěřovali? |
Ano |
|
Ano. Systém v definovaných případech umožňuje použití elektronického podpisu a elektronického časového razítka. |
Bezpečnost |
Jakým způsobem zajistíte, aby funkčnímu celku byla zajištěna adekvátní ochrana osobních údajů a utajovaných informací? |
Ano |
|
Ochranu osobních údajů a utajovaných skutečností zajistíme zavedením jmenného rejstříku a jeho důsledným oddělením od eSSSL, dodržováním norem eIDAS a GDPR a prováděním řádných skartací v souladu se skartačním plánem. |
Tabulka 30: Vysvětlení v kontextu datové architektury úřadu, tedy: |
|
Ne, nevznikají. |
|
Nejsou žádné další souvislosti. |
Vysvětlení aplikační architektury funkčního celku: |
|
Technologická architektura – vrstva IT technologie (HW a SW)
Tabulka 31: Katalog uzlů a klíčových funkcí nebo služeb: |
||
Typ prvku |
Název prvku |
Vysvětlení významu uzlu, funkce nebo služby |
Technologická funkce |
|
|
|
|
|
Model technologické architektury – pohled struktury IT technologické architektury
Tabulka 32: Využití sdílených IT technologických a platformových služeb: |
||
Název |
Popis |
Použito |
PaaS |
Pronájem technologií v datovém centru externího subjektu |
Od třetí strany Státní pokladna centrum sdílených služeb (SPCSS) dohlíží do úrovně operačního systému. Na databázový zdroj dohlíží externí firma. Hardware, který užíváme, není náš. Je nám poskytován jako vnější služba, smlouvu máme do konce roku 2019. |
DC eGOV |
Využití centrálních prvků provozního a bezpečnostního monitoringu Dohledového centra eGOV (MV) |
Ne |
Technologická architektura – vrstva komunikační infrastruktury
Tabulka 34: Katalog infrastrukturních komunikačních funkcí, sítí, cest a klíčových služeb: |
||
Typ prvku |
Název prvku |
Vysvětlení významu infrastrukturních funkcí, sítí, cest a služeb |
Komunikační síť |
Síť MPLS |
LAN, VAN. |
Housing |
Užíváme Datové centrum SPCSS |
|
Model technologické architektury – pohled struktury komunikační infrastruktury
Tabulka 35: Využití sdílených služeb komunikační infrastruktury: |
|||
Název |
Popis |
Použito |
Č. žádosti o výjimku |
CMS |
Pro publikaci a přístup k vytvářeným službám je využito Centrální místo služeb – aplikace jsou publikovány prostřednictvím CMS |
Nerelevantní |
|
KIVS |
Využití komunikační infrastruktury veřejné správy, tj. fyzického propojení infrastruktury úřadů nebo VPN připojení k CMS |
Nerelevantní |
|
NDC |
Umístění technologií do Národních datových center v perimetru CMS |
Ano |
|
Housing (IaaS) |
Využití umístění vlastní HW infrastruktury do prostor datového centra třetí strany |
Ne |
|
Tabulka 36: Vysvětlení v kontextu architektury komunikační infrastruktury úřadu, tedy: |
|
Ne, nevznikají žádné duplicity. |
|
Žádné. |
Vysvětlení architektury komunikační infrastruktury funkčního celku: |
|
Bezpečnostní architektura
Tabulka 37: Katalog bezpečnostní architektury funkčního celku: |
||
Dotčený nebo bezpečnostní prvek |
Hrozba / riziko |
Vysvětlení způsobu zmírnění hrozby / rizika prvkem architektury |
Server, síť |
průnik |
|
Firewall, Antivir, Antispam. |
|
|
Tabulka 38: Dodržení architektonických principů bezpečnostní architektury: |
||||
Princip |
Požadavek |
Dodrženo |
Č. žádosti o výjimku |
Způsob a míra naplnění |
Bezpečnost |
Ochrání projekt prostředky poskytování elektronických služeb veřejné správy před poškozením a zneužitím? |
Ano |
|
|
Tabulka 39: Vysvětlení bezpečnostní architektury funkčního celku: |
Spisová služba respektuje globální bezpečnostní architekturu úřadu. |
Shoda s pravidly, standardizace a dlouhodobá udržitelnost
Tabulka 40: Uveďte, které licence standardizovaných SW produktů budete pořizovat formou centrálních rámcových smluv zajištěných Ministerstvem vnitra. Pokud tento instrument nevyužijete, vysvětlete proč: |
Operační systém (OS), databáze. MSQL. Využijeme licence firmy Microsoft. |
Tabulka 41: Shoda se strategickými dokumenty: |
||||||||||||||
Požadavek |
Odpověď |
Č. žádosti o výjimku |
Vysvětlení |
|||||||||||
Je řešení v souladu s Informační koncepcí úřadu? |
Ano |
|
|
|||||||||||
Je řešení v souladu s Informační koncepcí ČR a cíli či principy Digitálního Česka? |
Ano |
|
Který z následujících podcílů IKČR projekt naplňuje?
|
|||||||||||
Je řešení v souladu s NAP? |
NEPOVINNÉ |
Ano. |
|
|||||||||||
1.4
Rozvoj on-line „front-office“ služeb jednotlivých
rezortů
Tabulka 42: Dodržení architektonických principů architektury shody s pravidly: |
||||
Princip |
Požadavek |
Dodrženo |
Č. žádosti o výjimku |
Způsob a míra naplnění |
Udržitelnost |
Je řešení navrženo pro efektivní údržbu a rozvoj, tj. jako standardizované, rozšiřitelné, integrovatelné, upgradovatelné a podporovatelné i vlastními silami úřadu? |
Ano |
|
|
Spolupráce a sdílení |
Jsou nové služby (nebo jejich součásti) koncipovány jako opakovatelné a komplementární ke sdíleným službám eGovernmentu? |
Ano |
|
|
Udržitelnost |
Je zajištěno, že je návrh byznys i IT řešení natolik robustní, modulární, škálovatelný, flexibilní a parametrizovatelný, aby se přizpůsobil očekávaným změnám za dobu jeho životnosti? |
Ano |
|
|
Tabulka 43: Vysvětlení standardizace a udržitelnosti architektury funkčního celku: |
Nepovinné |
|
Přehled služeb čtyřvrstvé architektury
Model služeb v čtyřvrstvé vizi architektury veřejné správy nebo jednotlivé modely využití každé vrstvy vrstvou vyšší
Tabulka 44: Dodržení architektonických principů 4 vrstvé architektury: |
||||
Princip |
Požadavek |
Dodrženo |
Č. žádosti o výjimku |
Způsob a míra naplnění |
Technologická neutralita
|
Jsou odděleny jednotlivé vrstvy architektury řešení systémem služeb poskytovaných navzájem mezi vrstvami? |
Ano |
|
Vlastní ISSSL se reálně skládá ze 4 vrstev: APPServeru, LDS (Lokálních dokumentových serverů), Klientů ISSSL (pevny/www), Parametrizace – Funkčnost/procesy (parametrizované agendy) ISSSL |
Je zajištěna separátní správa, dohled a provoz služeb na jednotlivých vrstvách? |
Ano |
|
|
|
Tabulka 45: Vysvětlení čtyřvrstvé architektury služeb funkčního celku: |
|
Kontrola shody architektury řešení funkčního celku se vzory sdílených služeb eGovernmentu
Tabulka 46: Kontrola shody architektury řešení funkčního celku se vzory sdílených služeb eGovernmentu:
Název architektonického vzoru eGovernmentu
Byl dodržen vzor?
Č. žádosti o výjimku
Podrobný popis způsobu a míry dodržení vzorů návrhem řešení funkčního celku
Centrální místo služeb
Publikujete aplikační služby řešené tímto projektem do CMS druhé generace?
Nerelevantní
Přistupujete ke službám Propojeného datového fondu prostřednictvím CMS druhé generace?
Nerelevantní
Jakým způsobem přistupujete do CMS druhé generace?
Nerelevantní
Univerzální kontaktní místo
Publikujete na CzechPOINT všechny své samoobslužné služby tak, aby mohly být přístupné i asistovaně?
Nerelevantní
ÚZSVM nemá funkci tzv. czechpointu, neslouží tedy k vidimaci dokumentů, ověřování platnosti podpisů, zpracovávání žádostí o výpisy z rejstříku trestů a ke zpracováváním podobných požadavků veřejnosti. ÚZSVM je rozhodujícím orgánem státní správy ve věcech majetkových, který podléhá Ministerstvu financí ČR. Veřejnost se na něj může obracet pouze s dotazy a žádostmi, které spadají do jeho výlučných pravomocí.
Jste na centrálu CzechPOINT připojeni skrze systém CMS?
Ano
Rozšířený backoffice úředníka
Máte služby CzechPOINT@office integrovány do svých systémů?
Ano
Budou všechny interní aplikace dostupné z intranetu úřadu/resortu?
Nerelevantní
Bude využito principu Single Sign-On?
Ano
Systém je technicky připraven, úřad zatím nevyužívá
ÚEP včetně eFakturace
Máte zajištěno předvyplňování formulářů ÚEP všemi státu známými údaji subjektu?
Nerelevantní
Máte zajištěn příjem a zpracování el. faktur?
Ano
Elektronický systém spisové služby
Je realizace propojení systému se spisovou službou vytvořena dle rozhraní definovaného v kapitole 9 Národního standardu?
Ano
Informační systém datových schránek
Je prováděno automatické vytěžování přijatých formulářů do informačního systému?
Ano
Propojený datový fond
Jste ke službám PPDF připojeni skrze CMS?
Nerelevantní
Data z ISZR do ISSL jsou přenášena z Centrálního rejstříku subjektů, který je součástí ISMS.
Využíváte pro překlad identity mezi agendami služby ISZR?
Nerelevantní
Předpokládáme tuto funkcionalitu prostřednictvím ISMS.
Využíváte pouze údaje, které máte explicitně uvedeny v daném zákoně?
Nerelevantní
Předpokládáme tuto funkcionalitu prostřednictvím ISMS.
Odebíráte na údaje PPDF notifikace skrze služby ISZR?
Nerelevantní
Předpokládáme tuto funkcionalitu prostřednictvím ISMS.
Elektronická identita
Využíváte služeb Národního bodu pro identifikaci a autentizaci?
Ano
Používáte pro překlad identifikátoru identity do své agendy (BSI na AIFO) služeb ISZR?
Nerelevantní
Předpokládáme tuto funkcionalitu prostřednictvím ISMS.
Využíváte při obsazení identifikované a autentizované osoby do role úředníka systém JIP/XXXX?
Nerelevantní
Předpokládáme tuto funkcionalitu prostřednictvím ISMS.
Plán funkčního celku (jeho historie)
Tabulka 47: Hrubý harmonogram předloženého funkčního celku: |
||||
Fáze / milník |
Začátek |
Konec |
Základní náplň |
Navazuje na |
2006 |
uvedení do provozu |
|
|
|
2020 |
eFaktury |
|
|
|
Tabulka 48: Projektový kontext předkládaného funkčního celku (v rozvojovém programu, portfoliu úřadu): |
|
Předchozí projekty |
Popis návaznosti na předchozí projekty |
ano |
Předchozí verze DMS1 |
|
|
Souběžné projekty |
Popis návaznosti na souběžné projekty |
nejsou |
|
|
|
Navazující projekty |
Popis návaznosti na budoucí projekty |
nejsou |
|
|
|
Tabulka 49: Katalog rozvojových etap (přechodových architektur) – roadmapa: |
||
Etapa/ přechodová architektura |
Milník |
Přírůstky a změny v přechodových architekturách oblastí zahrnutých do funkčního celku |
Vyplývající z vlastního funkčního celku (např. komplexního IS) |
||
rozvojová činnost: jmenný rejstřík, typový spis, elektronická skartace |
Datum zatím neznáme. |
|
|
|
|
Vyplývající z kontextu úřadu (roadmapy úřadu) |
||
|
|
|
|
|
|
Tabulka 50: Vysvětlení plánu funkčního celku: |
|
Další údaje funkčního celku
Připravenost k rozvoji
Majetkoprávní vztahy
Tabulka 51: Majetkoprávní vztahy: |
||
Podmínka |
Odpověď |
Poznámka (důvod) |
Budou vám udělena výhradní práva k užívání k dodávanému produktu? |
Ne |
|
Budou vám udělena nevýhradní práva k užívání k dodávanému produktu? |
Ano |
|
Budou práva k autorskému dílu nějak omezena (XXX, konkrétní uživatel, převoditelnost a další šíření, úpravy produktu, parametry…)? |
Ne |
|
Budete mít přístup ke zdrojovému kódu pro čtení? |
Ne |
Pouze k zákaznické parametrizaci |
Bude vám či třetímu subjektu umožněno provádět údržbu, měnit produkt, upravovat jej či rozšiřovat bez souhlasu dodavatele? |
Ano |
|
Budete mít přístup k aktuální technické dokumentaci produktu? |
Ano |
Ano, k technické dokumentaci máme již nyní přístup. Veškeré detailní dotazy nad rámec námi běžně užívané technické dokumentace je nám náš dodavatel a správce eSSSL schopen zodpovědět. |
Obsahuje budoucí smlouva ujednání o vyloučení odpovědnosti za výpadky fungování? |
Ne |
|
Budou externí nákupy veřejně soutěženy? |
Ano |
|
Ekonomické parametry funkčního celku
Hodnota výdajů a ekonomická náročnost funkčního celku
Hrubý odhad hodnoty záměru nákupu služeb či investic (externích výdajů), souvisejících s informačními a komunikačními technologiemi (funkčního celku).
Plán předpokládané ekonomické náročnosti funkčního celku založené na metodologii 5 letých celkových nákladů vlastnictví (tzv. Total Costs of Ownership) - účelové členění nákladů funkčního celku.
Tabulka 52: TCO:
|
||
Souhrnná položka modelu TCO [Kč] bez DPH |
③ TCO 5
|
Vysvětlení k položce |
Počet měsíců trvání fáze |
60 |
Předpokládá se, že nový systém po zahrnutí typového spisu a jmenných rejstříků bude fungovat v nové podobě nejméně po dobu pěti let, ovšem v případě požadavku ze strany MV ČR jakožto nejvyššího nadřízeného orgánu ve věci spisové služby může dojít ke změnám a úpravám i v kratším časovém horizontu. |
A. Předběžné analýzy (vč. rizik), tvorba zadání, výběr řešení, výběr dodavatele – náklady nákupního procesu |
60 000 |
5 let podpory spisové služby
|
B. Nákup SW a HW pro projekt (bez SaaS či PaaS) |
0Ne. |
<uveďte do tabulky 53 nebo samostatné přílohy rozpad výdajů, pokud výdaj přesahuje 10% celkové ceny projektu a současně přesahuje 1 mil. Kč> |
C. Analýza, finální projekt, vývoj, implementace, školení uživatelů, zkušební provoz a testy, případně i migrace dat a akceptační audit |
475 000 Kč |
<při jakékoliv částce uveďte do tabulky 53 nebo samostatné přílohy seznam rolí s počtem člověkodnů a cenu za člověkoden> |
D. Provoz a podpora řešení HW a SW (bez SaaS či PaaS) |
7 701 000 Kč (je třeba uvést rozklad jednotlivých položek) |
<uveďte do tabulky 53 nebo samostatné přílohy rozpad výdajů, pokud roční provoz a podpora přesahuje 20% celkové ceny řešení> |
E. Hardware/Software údržba a průběžné úpravy (bez SaaS či PaaS) |
500 000 Kč |
<uveďte do tabulky 53 nebo samostatné přílohy rozpad výdajů, pokud roční údržba a průběžné úpravy přesahuje 20% celkové ceny řešení> |
F. Projekty postupné inovace a zlepšování (plánované) |
100 000 Kč |
|
G. Projekty upgrade (pokud jsou plánovány) |
0 |
|
H. Zvýšené náklady užívání řešení vč. nákladů na přechod z předchozího řešení (pokud se vyskytnou) |
2 200 000 Kč |
Migrace dat. |
I. Útlum, konzervace a ukončení řešení |
0 |
<uveďte do tabulky 53 nebo samostatné přílohy rozpad výdajů, pokud útlum, konzervace a ukončení řešení přesahuje 10% celkové ceny řešení> |
X. Licence, HW, provoz, podpora, údržba, průběžný rozvoj - vše v subskripci (pouze SaaS a PaaS) |
0 |
<uveďte do tabulky 53 nebo samostatné přílohy rozpad výdajů, pokud výdaj na SaaP a PaaS přesahuje 1 mil. Kč> |
Z. Ostatní nerozlišené režijní náklady |
0 |
<uveďte do tabulky 53 nebo samostatné přílohy rozpad výdajů, pokud výdaj na nerozlišenou režii přesahuje 0,5 mil. Kč> |
Celkem |
11 036 000 Kč |
|
Tabulka 53: Vysvětlení a komentář k souhrnu výdajů a ekonomické náročnosti funkčního celku: |
|
Plán zavedení, údržby, dlouhodobá udržitelnost výstupů funkčního celku
Tabulka 54: Plánovaný ověřovací provoz (před akceptací) jednotlivých výstupů funkčního celku: |
|
Označení výstupu funkčního celku |
Plánovaná doba ověřovacího provozu výstupu [týden] |
Výstupy spisové služby |
8 týdnů |
|
ISSSL se bude ověřovat jako celek. |
Tabulka 55: Plánovaná životnost jednotlivých výstupů funkčního celku: |
||
Označení výstupu funkčního celku |
Plánovaná životnost výstupu [rok] |
Popište plánované změny |
Výstupy spisové služby. |
5 let. |
Podle Archivního zákona. |
|
|
|
Tabulka 56: Legislativní update: |
|
Bude podpora zahrnovat rovněž udržování řešení v souladu s novými právními předpisy (tzv. legislativní update)? Vysvětlete v jakém rozsahu: |
Jakým způsobem bude legislativní update hrazen? |
Ne, je poskytnut jednotlivými objednávkami |
Součást smlouvy o provozu a podpoře |
Tabulka 57: Jak je zajištěn další budoucí rozvoj předmětné oblasti a její ICT podpory: |
Po dobu 5 let. |
Tabulka 58: Jak je zajištěno řízené ukončení životnosti jednotlivých výstupů funkčního celku a případný přechod na další řešení, či případná výměna dodavatele nad stejným řešením (tzv. Exit strategie)? |
Na základě zákona o archivnictví. Technologicky je věc zajištěna. Bude hrazeno formou smlouvy. Jsme vlastníky dat, nejsme vázáni na dodavatele. |
Vyjádření k bezpečnostním aspektům
Tabulka 59: Předkladatel prohlašuje, že předkládaný projekt bude realizován plně v souladu s níže uvedeným prohlášením:
Text vyplňujte až na případnou výzvu OHA.
Upozornění a doporučení
Tabulka 60:Upozornění a doporučení:
Žadatel se zavazuje při podání další (tj. nové) žádosti (k provozu, rozvoji, obnově, nebo nákupu nové spisové služby) na OHA MV zapracovat (buď jako přílohou nebo jako součástí žádosti) variantní odbornou analýzu cílového stavu, za účelem optimalizace nákladů životního cyklu spisové služby.
Přílohy
Tabulka 61: Přílohy: |
||
Typ |
Číslo a název přílohy |
Upřesnění žádostí o výjimky/přílohy |
Zvolte položku. |
|
|
Zvolte položku. |
|
|
Zvolte položku. |
|
|
Zvolte položku. |
|
|
Celkový počet příloh: |
|
|
Toto
dílo podléhá licenci Creative
Commons Uveďte původ 4.0 Mezinárodní Licence