SMLOUVA
SMLOUVA
o poskytnutí, implementaci a podpoře SW řešení DMS pro správu a oběh digitálních dokumentů v České národní bance
uzavřená podle § 1746 odst. 2 zákona č. 89/2012 Sb., občanský zákoník a zákona
č. 120/2001 Sb., autorský zákon, ve znění pozdějších předpisů (dále jen “smlouva“) mezi:
Českou národní bankou
Na Příkopě 28
115 03 Praha 1
zastoupenou: Ing. Xxxxxxxxxx Xxxxxxxxx, ředitelem sekce informatiky
a
Ing. Xxxxxxx Xxxxxxxx, ředitelem sekce správní IČO: 48136450
DIČ: CZ48136450
(dále jen „objednatel“)
a
AutoCont CZ a.s.
zapsaná v obchodním rejstříku vedeném Krajským soudem v Ostravě, oddíl B, vložka 814 Hornopolní 3322/34
702 00 Ostrava
zastoupená: Xxx. Xxxxx Xxxxxxxx, obchodním ředitelem EBS IČO: 47676795
DIČ: CZ47676795
Bankovní spojení: 6563752/0800
(dále jen „poskytovatel“)
Článek I. Předmět smlouvy
1. Předmětem této smlouvy je závazek poskytovatele dodat a implementovat softwarové řešení pro správu a oběh digitálních dokumentů (Document Management System), které bude splňovat:
a) požadavky objednatele uvedené v příloze č. 1a Věcné zadání a příloze č.1b Funkční požadavky;
b) požadavky objednatele uvedené v příloze č.2a Technické zadání a příloze č.2b Specifické požadavky;
c) vítané požadavky, k jejichž implementaci se poskytovatel zavázal tím, že v přílohách č. 1b a 2b u nich vyplnit „Ano“;
d) specifikaci uvedenou poskytovatelem v příloze č. 10 Návrh realizace řešení,
e) SW řešení bude pro minimálně 1500 koncových uživatelů, z nichž alespoň 150
uživatelů může pracovat současně.
(dále jen „dílo“ nebo „SW řešení DMS“ nebo „DMS“ nebo „systém“).
2. Dodávka a implementace SW řešení DMS bude provedena ve třech etapách a organizována a řízena způsobem uvedeným v příloze č. 3 smlouvy. Rozsah jednotlivých etap plnění je uveden v článku II.
3. Předmětem této smlouvy je dále závazek poskytovatele na písemnou výzvu objednatele dodat a implementovat modul mobilní aplikace DMS, popř. mobilní řešení DMS, které disponuje verzemi webových formulářů optimalizovaných pro zobrazovací a ovládací možnosti mobilních telefonů, pro 150 koncových uživatelů. Uvedený závazek poskytovatele zaniká, nebude-li výzva objednatele k jeho splnění doručena poskytovateli do ukončení třetí etapy plnění podle čl. III. odst. 2c).
4. Předmětem této smlouvy je dále závazek poskytovatele poskytovat provozní podporu SW řešení DMS, případně i modulu dle odst. 3, v rutinním provozu v rozsahu podle přílohy č. 7 smlouvy.
5. Předmětem plnění podle této smlouvy je rovněž povinnost poskytovatele provádět úpravy nebo rozvoj SW řešení DMS (obojí dále též jako „vyžádaný rozvoj“). Vyžádaný rozvoj bude prováděn na základě výzvy objednatele a nabídky poskytovatele. Součástí výzvy objednatele bude věcné zadání a navrhovaná lhůta provedení. Součástí nabídky poskytovatele bude také předpokládaná pracnost požadovaných úprav. V případě, že pověřená osoba objednatele nabídku akceptuje, oznámí to e-mailem pověřené osobě poskytovatele. S prováděním úprav může poskytovatel začít až po doručení objednávky objednatele. Objednatel objednávku doručí na kontaktní adresu poskytovatele uvedenou v záhlaví této smlouvy nebo zašle na e-mailovou adresu pověřené osoby poskytovatele. Poskytovatel provede požadované úpravy v dohodnuté lhůtě. Úpravy objednatel převezme po provedení zkoušky funkčnosti, předání a převzetí upravené dokumentace a zdrojových kódů, a to na základě podpisu předávacího protokolu podle vzoru uvedeného v příloze č. 5 smlouvy, který podepíší pověřené osoby obou smluvních stran.
6. Předmětem této smlouvy je dále závazek objednatele převzít řádně provedené dílo a
zaplatit dohodnutou cenu podle článku V. této smlouvy.
Článek II.
Popis etap plnění
Dílo čl. I odst. 1 bude realizováno v následujících etapách, které budou předmětem akceptace podle článku IV a zahrnují:
1. První etapa - realizační studie ve struktuře a rozsahu podle přílohy č. 4.
2. Druhá etapa - implementace SW řešení DMS podle akceptované realizační studie zahrnující:
a) instalaci a implementaci SW řešení DMS v testovacím systémovém prostředí objednatele v souladu s podmínkami zvolené varianty implementace v příloze č. 12 smlouvy,
b) poskytnutí součinnosti a konzultací objednateli pro napojení interních informačních systémů objednatele s dodaným SW řešením DMS v souladu s podmínkami zvolené varianty implementace v příloze č.12 smlouvy,
c) zajištění školení:
• „Znalosti nutné k testování“ (cca 7 osob) spočívající v seznámení s funkcionalitou dodaného SW řešení DMS potřebnou k ověření testovacích scénářů, vypracování a poskytnutí školících materiálů a testovacích scénářů. Školení proběhne před akceptačními testy, které se budou konat v termínech podle harmonogramu schváleného v realizační studii.
• školení „Administrace a konfigurace SW řešení DMS“, včetně školících materiálů (cca 2 zaměstnanci),
• školení „Školení klíčových uživatelů“ - hlavních metodiků (cca 16 zaměstnanců),
d) vytvoření dokumentace v elektronické podobě ve formátu MS Office 2010 a vyšší nebo HTML obsahující:
• administrátorskou příručku,
• příručku technického správce,
• uživatelskou příručku,
e) vypracování a ověření migračních skriptů pro migraci souborů a metadat ze
současného systému IS Obelisk do DMS v testovacím prostředí.
3. Třetí etapa - ověřovací provoz v délce trvání 8 týdnů a migrace dat zahrnující:
a) dodávku a instalaci SW řešení DMS v souladu s podmínkami zvolené varianty implementace v příloze č. 12 smlouvy v provozním prostředí objednatele,
b) provedení migrace určených dat (souborů a metadat) včetně provedení post- migračních kroků vedoucích ke konzistenci metadat a souladu s funkcionalitou dodaného SW řešení DMS,
c) vytvoření a předání podkladů k provoznímu řádu a havarijnímu plánu,
d) předání kompletní aktuální dokumentace a zdrojových kódů doprogramovaných částí SW řešení DMS včetně migračních skriptů, namapování dat pro migraci ze stávajícího systému DMS do dodávaného DMS, importní skripty pro tuto migraci a exportní skripty pro případný export dat z dodávaného SW řešení DMS do následného systému.
4. Dále poskytovatel na výzvu objednatele dodá a implementuje mobilní aplikaci DMS, popř. mobilní řešení DMS, které disponuje verzemi webových formulářů optimalizovaných pro zobrazovací a ovládací možnosti mobilních telefonů (cca 5 palcové obrazovky), podle čl.I. odst.3 zahrnující:
a) dodávku a instalaci mobilní aplikace DMS (nebo mobilní řešení DMS) v testovacím prostředí objednatele,
b) zajištění školení:
• školení „Školení klíčových uživatelů pro mobilní aplikaci“ - hlavních metodiků
(cca 8 zaměstnanců),
• školení technických správců na instalování mobilní aplikace DMS na mobilní zařízení ČNB (cca 2 zaměstnanci),
c) dodávku a instalaci mobilní aplikace (nebo mobilního řešení DMS) v provozním prostředí objednatele po akceptaci řešení na testovacím prostředí,
d) předání kompletní technické a uživatelské dokumentace a zdrojových kódů doprogramovaných částí mobilní aplikace DMS (nebo mobilního řešení DMS).
Podrobné informace k jednotlivým činnostem jsou uvedeny v příslušných přílohách smlouvy.
Článek III. Lhůty a místo plnění
1. Místem plnění předmětu smlouvy je sídlo objednatele na adrese Xx Xxxxxxx 00, Xxxxx 0, xxxxxxxxxx-li se smluvní strany jinak.
2. Poskytovatel se zavazuje předat k akceptaci dle článku IV jednotlivé etapy takto:
a) první etapu nejpozději do 20 týdnů od účinnosti smlouvy s tím, že lhůta pro akceptaci je 8 týdnů od předložení studie k akceptaci,
b) druhou etapu nejpozději do 35 týdnů od podpisu akceptačního protokolu první
etapy, s tím, že lhůta pro akceptaci je 4 týdny od předání etapy k akceptaci.
c) třetí etapu nejpozději do 12 týdnů od podpisu akceptačního protokolu druhé etapy s tím, že nejpozději do 5 pracovních dnů od podpisu akceptačního protokolu druhé etapy budou zahájeny práce na dodávce a instalaci SW řešení DMS v provozním prostředí objednatele, včetně provedení migrace určených dat ze současného systému IS Obelisk tak, aby po dokončení těchto činností probíhal ověřovací provoz v délce 8 týdnů s tím, že lhůta pro akceptaci je 2 týdny od předání etapy k akceptaci.
3. Mobilní aplikaci DMS předá objednateli k akceptaci nejpozději do 16 týdnů od doručení výzvy objednatele. Lhůta pro akceptaci je 4 týdny od předání plnění k akceptaci.
Podrobný harmonogram bude uveden v realizační studii.
4. Poskytování provozní podpory zahájí poskytovatel pracovní den následující po podpisu předávacího protokolu díla podle čl. I odst. 1 objednatelem.
5. V případě provozní podpory modulu mobilní aplikace DMS zahájí poskytovatel její poskytování po podpisu předávacího protokolu modulu mobilní aplikace DMS podle čl. I odst. 3.
6. Poskytovatel provede školení podle schváleného harmonogramu uvedeného v realizační
studii. Veškerá školení zaměstnanců objednatele se budou konat v sídle objednatele.
7. Lhůty plnění dle této smlouvy mohou být měněny pouze formou dodatku ke smlouvě podepsaného oběma smluvními stranami.
Článek IV.
Akceptace, předání a převzetí díla, garance
1. Poskytovatel umožní objednateli kontrolovat průběh provádění díla a za tím účelem poskytne objednateli potřebnou součinnost.
2. V rámci všech etap provádění díla se poskytovatel zavazuje zajistit podporu na místě při akceptačním řízení a následně ověřovacím provozu v provozním prostředí objednatele. Při akceptačních řízeních budou vady odstraňovány neprodleně tak, aby akceptační řízení skončila po maximálně třetím opakování. Vady, které se vyskytnou při ověřovacím provozu, budou odstraňovány ve lhůtách dle kapitoly 5. 2 přílohy č. 7 smlouvy.
3. Akceptační řízení bude prováděno pro každou etapu uvedenou ve čl. II nebo pro modul dle
čl. I odst. 3, a to podle přílohy č. 5 smlouvy.
4. Poskytovatel je oprávněn zahájit další etapu až poté, co objednatel akceptoval předchozí
etapu.
5. Plnění dle čl. I odst. 1 nebo odst. 3 této smlouvy bude předáno a převzato na základě předávacího protokolu, který podepíší vedoucí projektu obou smluvních stran pokud:
a) byl podepsán akceptační protokol (v případě plnění podle čl. I odst. 1 akceptační
protokol třetí etapy),
b) poskytovatel dodal aktualizovanou dokumentaci,
c) poskytovatel poskytl veškeré potřebné licence pro správný a bezproblémový provoz SW řešení v souladu s podmínkami zvolené varianty implementace v příloze č. 12 smlouvy, které odpovídají licenčním ujednáním dle čl. VII,
d) poskytovatel předal v elektronické podobě na sjednaném datovém médiu (např. CD, DVD) elektronicky čitelné a kompletní zdrojové kódy oddělitelných, na základě požadavků objednatele vytvořených doprogramovaných částí SW řešení DMS a další podklady (např. datový model, programové knihovny) potřebné ke správě, údržbě a úpravám doprogramovaných částí včetně dokumentace.
6. Poskytovatel garantuje, že:
a) dodané, instalované a zavedené SW řešení DMS neobsahuje škodlivý software nebo známé zranitelnosti (dle seznamu OWASP TOP10 a CWE/SANS TOP 25) a je vyvíjeno v souladu se standardy SSDLC (Secure Software Development LifeCycle),
b) dodané, instalované a zavedené SW řešení DMS v souladu s podmínkami zvolené varianty implementace v příloze č. 12 smlouvy je schopno rutinního provozu ve standardním systémovém prostředí objednatele (viz příloha č. 2a) s daty objednatele, a to i za pravidelného nasazování aktualizací (update/upgrade/patch/hotfix) komponent systémového prostředí objednatele. Pokud bude nezbytné k užívání SW řešení DMS využít SW produkty a služby nad rámec standardního systémového prostředí objednatele, poskytovatel musí zajistit na své náklady potřebné licence a jejich provozní podporu tak, aby je bylo možné provozovat bez nutnosti zásahů a speciálních znalostí technické správy objednatele (viz podmínky zvolené varianty implementace v příloze č. 12). Tyto licence se zavazuje poskytovatel poskytnout objednateli v rámci plnění dle této smlouvy a zajistit plnou podporu těchto SW produktů v rámci podpory SW řešení DMS, přičemž ceny plnění dle čl. V zahrnují i tyto náklady,
c) dodané, instalované a zavedené SW řešení DMS v souladu s podmínkami zvolené
varianty implementace v příloze č. 12 smlouvy je funkční dle předané dokumentace,
d) v případě negativního dopadu do stávajících provozovaných systémů ČNB upraví řešení takovým způsobem, aby tyto dopady vyloučil,
e) poskytuje dostatečný počet licencí pro bezproblémové fungování díla tak, aby nebyla narušena práce všech uživatelů SW řešení. Pokud nedostatečný počet licencí způsobí problémy při provádění díla, během akceptačního řízení, ověřovacího provozu nebo při jeho provozování v průběhu 6 měsíců od jeho převzetí, rozšíří poskytovatel na vlastní náklady jejich počet na množství nezbytné pro plynulý provoz,
f) SW řešení DMS je vytvořeno v souladu se všemi příslušnými právními předpisy.
7. Xxxxxxx podle tohoto odstavce se vztahují i na plnění podle čl. I odst. 3, bude-li realizováno.
1. Cena plnění podle:
Článek V.
Cena a platební podmínky
a) čl. I odst. 1 činí celkem 10 618 195 Kč. Podrobný rozpis ceny je obsažen
v příloze č. 11 smlouvy.
b) čl. I odst. 3 činí celkem 200 612 Kč. Podrobný rozpis ceny je obsažen v příloze č. 11 smlouvy.
2. Na cenu díla podle čl. I odst.1 poskytne objednatel poskytovateli první zálohu ve výši ceny realizační studie uvedené v příloze č. 11, a to na základě zálohové faktury, kterou je poskytovatel oprávněn vystavit nejdříve v den podpisu akceptačního protokolu o ukončení první etapy (tvorba realizační studie) objednatelem. Výše zálohy nepřesáhne 10 % celkové ceny díla podle čl. I odst. 1.
3. Na cenu díla podle čl. I odst.1 poskytne objednatel poskytovateli druhou zálohu ve výši ceny druhé etapy plnění uvedené v příloze č. 11, a to na základě zálohové faktury, kterou je poskytovatel oprávněn vystavit nejdříve v den podpisu akceptačního protokolu o ukončení druhé etapy objednatelem. Výše zálohy nepřesáhne 30 % z celkové ceny díla podle čl. I odst. 1.
4. Cena díla podle čl. I odst.1 bude uhrazena na základě daňového dokladu, ve kterém budou odečteny poskytnuté zálohy a který je poskytovatel oprávněn vystavit nejdříve v den podpisu předávacího protokolu po ukončení třetí etapy objednatelem.
5. Cena díla dle čl. I odst. 3 bude v případě, že bude realizována na základě výzvy objednatele, uhrazena na základě daňového dokladu, který je poskytovatel oprávněn vystavit nejdříve v den podpisu předávacího protokolu k tomuto plnění.
6. Xxxx za provozní podporu díla podle čl. I odst.1 činí 8 600 Kč měsíčně. V případě úprav na základě vyžádaného rozvoje SW řešení DMS může být cena za provozní podporu navýšena nejvýše o 10 % z ceny provedené úpravy SW řešení DMS. Zvýšení ceny podpory bude provedeno dodatkem ke smlouvě.
7. Xxxx za provozní podporu díla podle čl. I odst. 3 mobilní aplikace/mobilního řešení DMS činí 100 Kč měsíčně. V případě úprav na základě vyžádaného rozvoje mobilní aplikace/mobilního řešení DMS může být cena za provozní podporu navýšena nejvýše o 10
% z ceny provedené úpravy. Zvýšení ceny podpory bude provedeno dodatkem ke smlouvě.
8. Cena za budoucí vyžádaný rozvoj dle čl. I odst. 4 bude stanovena dohodou na základě cenové nabídky poskytovatele. Cenová nabídka bude kalkulována podle předpokládané pracnosti a hodinové sazby ve výši 1 300 Kč. V ceně je zahrnuta i odměna za licenci k dané úpravě. Cena provedené úpravy bude uhrazena na základě daňového dokladu, který je poskytovatel oprávněn vystavit nejdříve v den podpisu předávacího protokolu.
9. Paušální cena za provozní podporu bude hrazena měsíčně na základě daňového dokladu, který je poskytovatel oprávněn vystavit nejdříve poslední den kalendářního měsíce, za který se platí. Výše paušální ceny za období kratší než kalendářní měsíc se vypočte jako alikvotní část sjednané ceny.
10. Cena za budoucí rozvoj bude uhrazena na základě daňového dokladu, který je
poskytovatel oprávněn vystavit po podpisu protokolu o převzetí provedených prací.
11. Všechny ceny jsou uvedeny bez DPH; daň z přidané hodnoty bude účtována v sazbě platné ke dni vzniku daňové povinnosti. Ceny zahrnují veškeré náklady poskytovatele spojené s plněním podle této smlouvy.
12. Doklady k úhradě musí obsahovat údaje dle § 435 občanského zákoníku a evidenční číslo smlouvy objednatele. Daňový doklad musí nadto obsahovat náležitosti stanovené zákonem o DPH. Nebude-li doklad obsahovat uvedené náležitosti nebo bude-li obsahovat nesprávné údaje, je objednatel oprávněn doklad poskytovateli vrátit, a to až do konce lhůty splatnosti. Nová lhůta splatnosti začne běžet dnem doručení bezvadného dokladu objednateli.
13. Doklady bude poskytovatel zasílat elektronicky na adresu xxxxxxx@xxx.xx, přičemž doklad musí být vložen jako příloha mailové zprávy ve formátu PDF. V jedné mailové zprávě smí být pouze jeden doklad. Mimo vlastní doklad může být přílohou mailové zprávy jedna až tři přílohy k dokladu ve formátech PDF, DOC, DOCX, XLS, XLSX. Nebude-li možné zaslat doklad k úhradě elektronicky, zašle poskytovatel doklad na adresu:
Česká národní banka
sekce rozpočtu a účetnictví
odbor účetnictví Na Příkopě 28
115 03 Praha 1
13. Splatnost dokladů je 14 dnů ode dne jejich doručení objednateli. Povinnost zaplatit je splněna odepsáním příslušné částky z účtu objednatele ve prospěch účtu poskytovatele.
14. Xxxxxxxxxx ze smluvních stran je oprávněna navrhnout změnu hodinové sazby dle odst. 8 a paušální ceny dle odst. 6 a 7 v návaznosti na vývoj indexu cen tržních služeb, stejné období předchozího roku = 100, konkrétně index J6201 Programování, sloupec „Průměr od počátku roku“, a to průměr za předchozí kalendářní rok, který vyhlašuje Český statistický úřad. Ceny mohou být upraveny maximálně o částku odpovídající předmětné roční inflaci pouze za bezprostředně předcházející kalendářní rok. Úprava ceny bude provedena formou dodatku ke smlouvě a nabude účinnosti nejdříve dnem účinnosti dodatku. První úpravu cen může poskytovatel navrhnout v roce 2019.
15. Smluvní strany se dohodly, že objednatel je oprávněn započíst jakoukoli svou peněžitou pohledávku za poskytovatelem, ať splatnou či nesplatnou, oproti jakékoli peněžité pohledávce poskytovatele za objednatelem, ať splatné či nesplatné.
Článek VI.
Práva a povinnosti smluvních stran
1. Poskytovatel se zavazuje zajistit, že osoby, které se budou podílet na plnění podle této smlouvy, budou splňovat kvalifikační předpoklady, které objednatel požadoval v kvalifikačních požadavcích zadávacího řízení na předmět této smlouvy. Poskytovatel je po dobu účinnosti této smlouvy povinen na požádání kvalifikaci jednotlivých osob objednateli doložit předložením životopisu či certifikátů podepsaných jednotlivými osobami, a to do 5 pracovních dnů ode dne doručení požadavku objednatele.
2. Poskytovatel se zavazuje zajistit, že v případě poskytování služeb prostřednictvím poddodavatele platí všechna ustanovení tohoto článku také pro poddodavatele a jeho pracovníky, kteří se budou na plnění smlouvy podílet. V případě, že poskytovatel splnil některý z požadavků stanovených objednavatelem v zadávací dokumentaci zadávacího řízení na předmět této smlouvy prostřednictvím poddodavatele, je povinen v případě změny tohoto poddodavatele na požádání objednatele prokázat, že nový poddodavatel tento požadavek splňuje, a to do 5 pracovních dnů ode dne doručení požadavku objednatele.
3. Objednatel si vyhrazuje právo ověřit si skutečnosti dle odst. 1 a 2 tohoto článku. Nesplnění kteréhokoliv požadavku objednatele uvedeného v odst. 1 a 2 tohoto článku je považováno za porušení smlouvy podstatným způsobem.
4. Poskytovatel je povinen mít po dobu účinnosti této smlouvy uzavřeno pojištění pro případ vzniku odpovědnosti za škodu způsobenou třetí osobě v souvislosti s plněním této smlouvy, a to s pojistným plněním ve výši nejméně 5 000 000 Kč (slovy: pět milionů korun českých) s tím, že jeho spoluúčast nepřevyšuje 5 %.
5. Poskytovatel se zavazuje, že pojištění v uvedené výši a rozsahu zůstane účinné po celou dobu účinnosti této smlouvy, a do 5 pracovních dnů od výzvy objednatele je poskytovatel povinen toto objednateli prokázat.
6. Poskytovatel se zavazuje, že práva a závazky vyplývající z této smlouvy nepřevede na třetí
osoby bez souhlasu objednatele.
7. Dále se poskytovatel zavazuje objednateli oznámit výskyt jakýchkoli okolností, které by mohly mít vliv na plnění dle této smlouvy a na základě výzvy objednatele jej bez zbytečného odkladu informovat o aktuálním stavu provádění plnění.
8. Poskytovatel bere na vědomí, že mu nebude umožněn vzdálený přístup k serverům
objednatele.
Článek VII. Licenční ujednání
1. Poskytovatel poskytuje objednateli nevýhradní a časově a teritoriálně neomezené oprávnění užívat SW řešení DMS. Objednatel je oprávněn:
a) spojit SW řešení DMS nebo kteroukoli jeho část s jiným autorským dílem, zařadit do jiného díla, zařadit do díla souborného, a takto jej užít způsoby dle této smlouvy,
b) upravovat doprogramované části SW řešení DMS (včetně zdrojových kódů doprogramovaných částí a knihoven) nebo je měnit dle potřeby jeho užití, a to i prostřednictvím třetí osoby a užívat je jako součást informačního systému nebo samostatně, a to po ukončení poskytování podpory poskytovatelem,
c) rozmnožovat SW řešení DMS nebo jeho části za účelem užití dle této smlouvy.
2. Objednatel se stane vlastníkem médií se SW řešení DMS a dokumentací dnem podpisu předávacího protokolu. Objednatel si vyhrazuje právo zapůjčit dodanou dokumentaci třetí straně za účelem zajištění provozu nebo rozvoje SW řešení DMS po ukončení poskytování podpory poskytovatelem.
3. Objednatel není povinen využít poskytnutou licenci ani zčásti.
4. Poskytovatel prohlašuje, že práva, která touto smlouvou poskytuje, mu náleží bez jakéhokoliv omezení a odpovídá za škodu, která by objednateli vznikla, pokud by se kdykoli později zjistilo, že toto prohlášení bylo nepravdivé.
5. Licenční ujednání poskytnuté dle této smlouvy se vztahují i na veškeré poskytnuté
aktualizace (tj. update/upgrade/patch/hotfix atd.).
6. Poskytovatel umožní objednateli užívání programových prostředků dle této smlouvy již v průběhu třetí etapy s tím, že licence podle tohoto článku objednatel nabývá dnem podpisu předávacího protokolu.
7. Licenční ujednání podle tohoto článku se vztahují i na úpravy SW řešení DMS provedené poskytovatelem v rámci vyžádaného rozvoje, nebude-li v konkrétním případě dohodnuto jinak.
8. Stejné licenční podmínky platí i v případě poskytnutí mobilního SW řešení DMS.
Článek VIII.
Mlčenlivost, bezpečnostní požadavky objednatele
1. Poskytovatel se zavazuje zajistit, že jeho pracovníci, kteří se budou na plnění podle této smlouvy podílet, zachovají mlčenlivost o všech skutečnostech, se kterými se u objednatele seznámí, a které nejsou veřejně dostupné. Povinnost mlčenlivosti není časově omezena.
2. Poskytovatel, jeho pracovníci či poddodavatelé poskytovatele a jejich pracovníci se zavazují v plném rozsahu dodržovat bezpečnostní požadavky objednatele, které jsou uvedeny v příloze č. 8 této smlouvy.
Článek IX.
Smluvní pokuty, úrok z prodlení
1. Pokud poskytovatel nedodrží kteroukoliv lhůtu stanovenou v článku III odst. 2 nebo v případě realizace mobilní aplikace DMS kteroukoliv lhůtu stanovenou v článku III odst. 3, uhradí objednateli za každý pracovní den prodlení smluvní pokutu ve výši 5 000 Kč.
2. V případě prodlení poskytovatele ve lhůtě pro odstranění vady uvedené v akceptačním protokolu je objednatel oprávněn požadovat smluvní pokutu ve výši 5 000 Kč za každý pracovní den prodlení u vady kategorie B nebo C.
3. V případě prodlení poskytovatele ve lhůtě pro provedení školení dle čl. III odst. 6 je objednatel oprávněn požadovat smluvní pokutu ve výši 5 000 Kč za každý pracovní den prodlení.
4. V případě prodlení poskytovatele ve lhůtách dle přílohy č. 7:
a) pro potvrzení příjmu požadavku je objednatel oprávněn požadovat smluvní pokutu ve výši 1 000 Kč za každou pracovní hodinu prodlení,
b) pro zajištění a implementaci dočasného opatření vedoucího k odstranění vady kategorie A je objednatel oprávněn požadovat smluvní pokutu ve výši 2 000 Kč za každou pracovní hodinu prodlení,
c) pro zajištění a implementaci dočasného opatření vedoucího k odstranění vady kategorie B je objednatel oprávněn požadovat smluvní pokutu ve výši 2 000 Kč za každý pracovní den prodlení,
d) pro odstranění vady je objednatel oprávněn požadovat smluvní pokutu ve výši:
• 5 000 Kč za každou pracovní hodinu prodlení pro vady kategorie A,
• 3 000 Kč za každý pracovní den prodlení pro vady kategorie B,
• 1 000 Kč za každý pracovní den prodlení pro vady kategorie C.
5. V případě prodlení poskytovatele ve lhůtě pro předání plnění v rámci budoucího vyžádaného rozvoje je objednatel oprávněn požadovat smluvní pokutu ve výši 2 000 Kč za každý pracovní den prodlení.
6. V případě, že se prohlášení poskytovatele dle čl. VII odst. 4 ukáže jako nepravdivé, vzniká objednateli nárok na smluvní pokutu ve výši 100 000 Kč.
7. Výše uvedené smluvní pokuty se neuplatní, pokud prodlení poskytovatele bylo způsobeno neposkytnutím součinnosti ze strany objednatele.
8. V případě prodlení objednatele s uhrazením daňového dokladu je poskytovatel oprávněn požadovat úrok z prodlení podle předpisů občanského práva.
9. Smluvní pokuta a úrok z prodlení jsou splatné do 14 dnů od doručení dokladu k úhradě povinné smluvní straně. Povinnost zaplatit je splněna odepsáním příslušné částky z účtu povinného ve prospěch účtu oprávněného.
10. Strany se dohodly, že jejich vzájemná odpovědnost za škodu není smluvní pokutou vyloučena.
Článek X.
Trvání smlouvy, výpověď smlouvy, odstoupení, zrušení smlouvy zaplacením odstupného
1. Tato smlouva v části týkající se provozní podpory a budoucího vyžádaného rozvoje je uzavřena na dobu neurčitou s šestiměsíční výpovědní dobou, která počne běžet prvním dnem kalendářního měsíce následujícího po doručení písemné výpovědi druhé smluvní straně.
2. Smluvní strany se dohodly, že objednatel je oprávněn kdykoliv v průběhu insolvenčního řízení zahájeného na majetek poskytovatele vypovědět tuto smlouvu v části týkající se provozní podpory a vyžádaného rozvoje, a to ve 14denní výpovědní lhůtě, která počíná běžet dnem následujícím po doručení písemné výpovědi poskytovateli.
3. Poruší-li kterákoliv strana podstatným způsobem závazky vyplývající z této smlouvy, má druhá strana právo odstoupit od smlouvy, a to písemným oznámením o odstoupení. Takové odstoupení je účinné dnem doručení oznámení druhé smluvní straně. Odstoupit lze i od části smlouvy. Smluvní strany se dohodly, že objednatel je oprávněn odstoupit od smlouvy i v případě, že převzal etapu plnění.
4. Za porušení smlouvy podstatným způsobem strany považují zejména tyto případy:
a) SW řešení DMS nesplňuje požadavky objednatele specifikované v přílohách č. 1a a 1b a přílohách 2a a 2b,
b) poskytovatel je v prodlení ve kterékoliv lhůtě dle čl. III odst. 2 delším než 30 dnů,
c) objednatel je v prodlení s úhradou kterékoliv platby dle této smlouvy delším než 30 dnů.
5. Smluvní strany si v souladu s ustanovením § 1992 zákona č. 89/2012 Sb., občanský zákoník, sjednávají, že objednatel je oprávněn zrušit tuto smlouvu zaplacením odstupného ve výši odpovídající 30 % ceny první etapy plnění, nejvýše však 100 000 Kč, na účet poskytovatele, a to kdykoli před akceptací realizační studie. Zrušení smlouvy je účinné zaplacením sjednaného odstupného na bankovní účet poskytovatele, č.ú: 6563752/0800. Zaplacením odstupného zanikají všechna práva a povinnosti obou smluvních stran vyplývající ze zrušené smlouvy s výjimkou závazku mlčenlivosti poskytovatele.
Článek XI.
Uveřejnění smlouvy a skutečně uhrazené ceny
1. Poskytovatel si je vědom zákonné povinnosti objednatele uveřejnit na svém profilu tuto smlouvu včetně všech jejích případných změn a dodatků a výši skutečně uhrazené ceny za plnění této smlouvy.
2. Profilem objednatele je elektronický nástroj, prostřednictvím kterého objednatel, jako
veřejný zadavatel dle zákona č. 134/2016 Sb., o zadávání veřejných zakázek (dále jen
„ZZVZ“) uveřejňuje informace a dokumenty ke svým veřejným zakázkám způsobem, který umožňuje neomezený a přímý dálkový přístup, přičemž profilem kupujícího v době uzavření této smlouvy je xxxxx://xxxx.xxx.xx/.
3. Povinnost uveřejňování dle tohoto článku je objednateli uložena § 219 ZZVZ.
4. Uveřejňování bude prováděno dle ZZVZ a příslušného prováděcího předpisu k ZZVZ.
Článek XII. Pověřené osoby
1. Osoby pověřené smluvními stranami k jednáním v rámci jednotlivých činností jsou uvedeny v přílohách č. 3, 5 a 7.
2. Případná změna pověřených osob nebo jejich kontaktních údajů bude neprodleně provedena písemným oznámením doručeným elektronicky na e-mailové adresy pověřených osob druhé smluvní strany.
Článek XIII. Závěrečná ustanovení
1. Tuto smlouvu lze měnit pouze dohodou smluvních stran písemným dodatkem, není-li ve
smlouvě stanoveno jinak.
2. Smluvní strany se dohodly, že případný spor, který vznikne z této smlouvy nebo v souvislosti s ní bude rozhodován výlučně podle českého práva obecnými soudy v České republice.
3. Tato smlouva je sepsána v českém jazyce. Veškerá komunikace mezi smluvními stranami vztahující se k této smlouvě bude probíhat v českém nebo slovenském jazyce, nebude-li smluvními stranami v konkrétním případě dohodnuto jinak.
4. Práva a povinnosti vzniklé z této smlouvy mohou být postoupena pouze po předchozím písemném souhlasu druhé smluvní strany. Za písemnou formu se nepovažuje e-mail či jiné elektronické zprávy.
5. Odpověď stran této smlouvy podle § 1740 odst. 3 občanského zákoníku s dodatkem nebo
odchylkou není přijetím nabídky, ani když podstatně nemění podmínky nabídky.
6. Uplatnění domněnky doby dojití dle § 573 občanského zákoníku se vylučuje.
7. Tato smlouva a právní vztahy s ní související se řídí zákonem č. 89/2012 Sb., občanský zákoník a dále rovněž příslušnými ustanoveními zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon) a ostatními souvisejícími platnými právními předpisy.
8. Nedílnou součástí smlouvy jsou všechny její přílohy. V případě rozporu mezi některými ustanoveními smlouvy a jejími přílohami se smluvní strany dohodly na tom, že přednost má smlouva.
9. Tato smlouva je vyhotovena ve čtyřech stejnopisech, z nichž objednatel obdrží tři a
poskytovatel jedno vyhotovení.
10. Smlouva nabývá platnosti a účinnosti dnem podpisu oběma smluvními stranami.
VĚCNÉ ZADÁNÍ
9. Vzorový popis procesu ČNB procesu ČNB
1 Současný stav
V současné době neexistuje v rámci České národní banky (ČNB) jednotný informační systém, který by umožňoval zpracovávat a ukládat vybrané digitální dokumenty, efektivně je vyhledávat, sdílet a později s nimi dále pracovat tak, aby pro ně byl z části nebo plně nahrazen jejich papírový oběh uvnitř ČNB a redukována interní distribuce těchto digitálních dokumentů prostřednictvím elektronické pošty. Využití elektronické pošty jako primárního kanálu pro oběh těchto dokumentů v současnosti a ukládání dokumentů také na osobní a sdílené disky vede ke vzniku duplicit a multiplicit, což klade další nároky na datové kapacity uložišť. Uvedená praxe přitom ztěžuje sledování verzí dokumentů, prodlužuje jejich vyhledávání a způsobuje zbytečné časové prodlevy.
Některé funkcionality týkající se ukládání a sdílení vybraných druhů digitálních dokumentů v ČNB doposud zastává technologicky i funkčně zastaralá a dosluhující databáze IS Obelisk (vzniknuvší v roce 1999, v provozu od roku 2000), která však již s ohledem na dobu svého vzniku nesplňuje současné nároky na práci s digitálními dokumenty a jejich metadaty. Z důvodu ukončení jeho dalšího technologického rozvoje a omezené provozní podpory bylo, mj. z důvodů bezpečnostních požadavků, rozhodnuto o ukončení používání IS Obelisk a o jeho náhradě.
Z výše uvedených důvodů bylo proto rozhodnuto o pořízení nového informačního systému pro správu dokumentů (DMS), který by nahradil IS Obxxxxx x poskytl ČNB moderní SW nástroj pro práci a správu vybraných digitálních dokumentů.
2 Cíle projektu
Hlavním cílem projektu je vytvoření efektivního systému pro správu a sdílení vybraných digitálních dokumentů, který usnadní jejich oběh a schvalování uvnitř ČNB (workflow), zajistí platformu pro přehledné ukládání a umožní bezproblémové vyhledávání dokumentů, a to vše v uživatelsky maximálně přívětivém, komfortním a jednoduchém grafickém rozhraní při splnění všech platných bezpečnostních pravidel. Systém je určen pro celou ČNB, a to primárně pro agendy, procesy a dokumenty, které se svojí průřezovou povahou dotýkají všech organizačních útvarů ČNB. V rámci projektu by také mělo dojít k postupné migraci všech souborů a metadat z IS Obelisk a k jeho nahrazení.
Centralizované úložiště s efektivním systémem vyhledávání dokumentů a graficky přehledná navigace mezi jednotlivými složkami a soubory by měly významně usnadnit práci s dokumenty a zajistit náležitou informovanost všech relevantních útvarů ČNB bez zbytečných časových prodlev a zároveň také eliminovat možnost, že by se některá informace ztratila nebo nedostala včas příslušnému adresátu. K tomu by měla rovněž sloužit možnost individuálního nastavení automatických avíz (e- mailových notifikací do emailových schránek zaměstnanců ČNB) podle preferencí jednotlivých uživatelů, např. o nově vloženém dokumentu, o novém jednání určité pracovní skupiny atd., a to např.
na základě příslušnosti daného dokumentu či jednání k určité věcné agendě či jiné charakteristiky (pomocí metadat). Systém DMS by měl rovněž podporovat možnost řetězení avíz, tj. zaslání souhrnné notifikace v jednom emailu za určitý časový interval (např. jedna hodina, 1 den apod.). Díky intuitivnímu systému schvalování vybraných typů dokumentů přímo v DMS, včetně uchování záznamu o schválené verzi, bude snadné v případě potřeby zpětně dohledat, která verze dokumentu, kdy a kým byla schválena. Schvalování určitých druhů dokumentů (jako např. stanoviska pro jednání orgánů a institucí EU/ESCB) bude v praxi také usnadněno možností nastavení lhůty (tzv. tichá procedura), po jejímž uplynutí, aniž by byla porušena uplatněním připomínky, bude daný dokument automaticky označen za schválený.
DMS musí splňovat vysoké nároky na grafickou přehlednost, uživatelskou přívětivost, ergonomičnost a jednoduchost jeho obsluhy pro běžného zaměstnance ČNB tak, aby používání DMS skutečně usnadnilo a zefektivnilo jeho práci. Systém musí být možno upravit tak, aby jeho grafické uživatelské rozhraní odpovídalo potřebám ČNB (nastavení úvodní obrazovky, volba a rozmístění nejvíce používaných tlačítek a funkčních prvků, zobrazení posledních přidaných dokumentů ve sledovaných agendách, zobrazení aktuálních či nesplněných úkolů, dokumentů čekajících na schválení apod.).1 Naopak méně používané funkcionality a tlačítka by mělo být možné skrýt, aby zbytečně neznepřehledňovaly pracovní prostředí běžného uživatele. Důraz musí být kladen na to, aby požadovaná operace byla proveditelná na co nejmenší počet dílčích úkonů pracovníka.
Výše uvedený hlavní cíl projektu v sobě zahrnuje jednotlivé dílčí cíle, které byly specifikovány následovně:
- komplexní a přitom snadný, rychlý a uživatelsky přívětivý proces správy a oběhu vybraných digitálních dokumentů, včetně dokumentů chráněných šifrováním a dokumentů obsahujících klasifikované informace ve smyslu vnitřního předpisu ČNB2, při zachování všech vnitřních, národních i mezinárodních (EU/ESCB) bezpečnostních požadavků;
- propojení se systémem spisové služby ČNB (IS e-Spis), s novým intranetem ČNB (IS IBIS) a dalšími interními informačními systémy ČNB; systém DMS nenahrazuje stávající systém pro spisovou službu, nýbrž bude sloužit jako pracovní nástroj pro práci s vybranými dokumenty (zpracování, editace, oběh, sdílení, schvalování a ukládání), zatímco evidence a dlouhodobé ukládání dokumentů v elektronické formě ve smyslu legislativních požadavků bude nadále zajišťovat IS e-Spis;
- minimalizace papírového oběhu vybraných druhů dokumentů uvnitř ČNB díky digitalizaci;
- zefektivnění a zrychlení oběhu vybraných druhů dokumentů jeho elektronizací, včetně individuálně nastavitelných e-mailových notifikací/avíz o dokumentu, termínu, úkolu apod.;
- snadný a efektivní systém workflow pro elektronické schvalování vybraných dokumentů (např. stanoviska pro zástupce ČNB na jednání v orgánech a institucích EU/ESCB a vybraných mezinárodních organizací; interní dokumenty ČNB – pokyny, metodické listy apod.), s možností jejich automatického schválení v tiché proceduře;
- centralizace, sjednocení a kvalitativní zlepšení způsobu ukládání vybraných dokumentů napříč ČNB, snížení duplicitního ukládání dat, jejich neaktuálnosti a ztrát (dostatečně kapacitní centrální datové úložiště, které nahradí IS Obelisk, přístupné ze všech pracovišť ČNB i externě prostřednictvím vzdáleného přístupu a z mobilních zařízení všem zaměstnancům ČNB na základě systému přístupových práv);
- pokročilá a snadná správa uživatelských práv včetně řízení přístupu k jednotlivým dokumentům, zaznamenávání přístupů zaměstnanců do systému a k jednotlivým chráněným dokumentům (logy) pro potřeby interních a externích auditů a pro předejití bezpečnostních incidentů;
- zlepšení informovanosti zaměstnanců ČNB, včetně snadného přístupu ke všem dokumentům
i pro členy bankovní rady jakožto vrcholného řídícího orgánu ČNB;
1 Viz též část 11, která obsahuje příklady a vzory možné podoby grafického uživatelského rozhraní
2 Pokyny ČNB č. 38/2015 o ochraně klasifikovaných informací v ČNB.
- rychlé, snadné a efektivní vyhledávání dokumentů (vyhledávacím nástrojem integrovaným do prostředí Windows a/nebo nástrojem integrovaným v DMS a přístupným přes jeho grafické rozhraní) fulltextové i parametrické (s využitím metadat);
- usnadnění práce s vybranými dokumenty (editace dokumentů voláním aplikace MS Office přímo z DMS, propojení s e-mailovým klientem a prostředím Windows, MS Office), včetně definice a správy metadat těchto dokumentů, a paralelní práce s dokumenty, na nichž se současně podílí více zaměstnanců, a to i mezi jednotlivými útvary ČNB (tzv. coauthoring);
- modularita DMS – vnitřní otevřenost systému pro snadné doplňování přímo pověřenými uživateli (bez nutnosti znalosti fungování celého systému či programování) nových sad metadat, číselníků, fór, jednání, událostí, úkolů, oběhových míst, nastavení nových schvalovacích postupů, přednastavení a vkládání šablon dokumentů atd.;
- modularita workflow DMS – možnost intuitivně a jednoduše sestavit individuální workflow v konkrétním případě nad konkrétním dokumentem, dokumenty či úkolem z jednotlivých stavebních kamenů/akcí jednotlivými uživateli (opět bez nutnosti znalosti programování);
- správa (vč. ukládání, oběhu, tvorby metadat) dokumentů obsahujících klasifikované informace chráněných pomocí šifrování; samotné šifrování a dešifrování bude probíhat prostřednictvím samostatného specializovaného systému ČNB (v současnosti IRM příp. jeho budoucí nástupce) integrovaného s DMS;
- úspora času, energie a ve výsledku i nákladů zaměstnanců, a tím zvýšení jejich výkonnosti.
Na základě výše uvedených požadovaných cílů projektu byly identifikovány jednotlivé podrobnější požadavky kladené na systém DMS, které jsou popsány dále v kapitole 10 - Funkční požadavky (příloha č. 1b smlouvy).
3 Omezení a předpoklady
Součástí projektu DMS je migrace souborů včetně metadat uložených nyní v IS Obelisk do úložiště DMS v plném rozsahu (s výjimkou souborů, o nichž bude v ČNB rozhodnuto, že je není třeba migrovat). Proces migrace dat z IS Obelisk by v rámci projektu měl být vzhledem objemu uložených souborů probíhat v několika fázích, přičemž v první fázi budou migrovány soubory vztahující se k agendám v působnosti sekce kancelář a sekce regulace a mezinárodní spolupráce na finančním trhu ČNB. Přehled těchto agend je uveden v kapitole 7 Struktura úložiště. Detailní určení počtu migrovaných souborů bude provedeno v rámci realizační studie.
Vlastní implementaci systému a projekt mohou ovlivnit případné změny organizační struktury ČNB či vnější změny včetně změn relevantních právních předpisů.
4 Požadavky na bezpečnost
Systém DMS je určen k ukládání souborů, které mohou obsahovat citlivé nebo důvěrné informace, a to zejména:
1) klasifikované informace ČNB ve smyslu vnitřního předpisu ČNB,3
2) klasifikované informace EU/ESCB a dalších mezinárodních organizací (např. MMF),
3) informace obsahující osobní údaje podle zákona č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů.4 DMS však nebude primárně sloužit ke zpracování osobních údajů.
V systému DMS naopak nebudou ukládány soubory obsahující utajované informace ve smyslu zákona č. 412/2005 Sb., o ochraně utajovaných informací a o bezpečnostní způsobilosti, ve znění pozdějších předpisů.
3 Pokyny ČNB č. 38/2015 o ochraně klasifikovaných informací v ČNB.
4 Viz též Pokyny ČNB č. 71/2006 k zajištění ochrany osobních údajů zpracovávaných organizačními útvary ČNB, ve znění pozdějších změn.
Z výše uvedených důvodů proto DMS musí splňovat veškeré legislativní požadavky na ochranu osobních údajů ve smyslu zákona č. 101/2000 Sb. a obecného nařízení o ochraně osobních údajů (nařízení (EU) 2016/679), být plně v souladu s platnou legislativou v této oblasti, jakož i splňovat veškeré bezpečnostní požadavky stanovené v příslušných předpisech a normativních dokumentech EU/ESCB,5 zejm. jednotná pravidla a minimální standardy pro nakládání s citlivými informacemi ESCB,6 a požadavky vyplývající ze zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů.
Rovněž musí DMS umožňovat auditovatelnost a logování přístupů a nakládání se soubory a informacemi v DMS (viz požadavky uvedené v Katalogu specifických požadavků v příloze č.2b smlouvy). U jednotlivých záznamů klíčových metadat musí být zcela jasně evidováno, kdo a kdy daný záznam založil, měnil nebo mazal. Tyto údaje nebudou zjistitelné pouze z logu, ale též uživatelsky přímo v aplikaci systému. Není nutné v logu uchovávat všechny údaje o původních hodnotách a nových změněných hodnotách, pokud by tyto informace logy příliš zatěžovaly, ale musí být možné zvolit, které informace budou logovány a které ne.
Log bude kromě standardizovaných akcí zaznamenávat sledování některých specifických a jednoznačně identifikovatelných činností, např. provádění exportů citlivých dokumentů. Logy musí umožnit vyhledávání a filtrování, tisk a export. Kromě změn dat musí být zaznamenávány i prováděné aktualizace a upgrade systému.
Komunikace mezi databází a uživatelskou částí systému by měla probíhat zabezpečeným způsobem. Je požadována také jednoznačná prokazatelnost, autentizace a autorizace uživatele zasahujícího do systému. Systém musí být možno využívat plnohodnotně pro vzdálený přístup do DMS z mobilních zařízení (notebooky, tablety a mobilní telefony s operačními systémy iOS nebo Android).
ČNB připojuje tablety do sítě prostřednictvím vzdálené plochy realizované pomocí mobilní aplikace Citrix Receiver. Alternativně je možné k přístupu do DMS z mobilních zařízení (tabletů a chytrých mobilních telefonů) využít řešení CheckPoint IPSec VPN nebo alternativní VPN technologii. ČNB požaduje vzdálený přístup z mobilních zařízení včetně „chytrých“ mobilních telefonů k souborům a workflow v DMS, a to buď formou dedikované mobilní aplikace nebo skrze webový prohlížeč formou formulářů s podporou responsivního designu. Tento mobilní vzdálený přístup musí umožnit alespoň přístup a zobrazení dokumentů uložených v DMS, provedení schvalovacích procesů ve workflow (např. schválení či odmítnutí dokumentu nebo úkolu) a ve zjednodušené podobě navigaci a vyhledávání souborů uložených v DMS, včetně nejnovějších dokumentů (latest documents) relevantních pro konkrétního uživatele. V případě nezvolení varianty mobilní aplikace je proto nezbytné, aby DMS disponovalo verzemi webových formulářů zajišťujících tyto funkce optimalizovanými pro zobrazovací a ovládací možnosti mobilních telefonů (cca 5ti palcové obrazovky). Konkrétní rozsah a podoba aplikace a formulářů budou finalizovány v dohodě s vybraným uchazečem v realizační studii.
Systém musí umožnit nadefinovat přístupová oprávnění (vytvoření, uložení, čtení, editace, mazání) jednotlivých uživatelů nebo jejich skupin k souborům, složkám a dalším objektům DMS (např. metadatům) podle řady kritérií a jejich kombinací. Tato kritéria zahrnují:
1) roli uživatele v rámci DMS (např. koordinátor určitého fóra), roli uživatele v rámci konkrétního workflow v DMS a roli uživatele z hlediska jeho zařazení v organizační struktuře ČNB,
2) oprávnění uživatele/skupiny uživatelů přistupovat k určitým složkám ve struktuře úložiště DMS (oprávnění se dědí z vyšších složek do nižších s možností vyloučit dědění v individuálním případě nad konkrétní složkou),
5 Přehled aktuálních dokumentů ESCB s bezpečnostními požadavky použitelnými pro systémy k ukládání a zpracování citlivých informací ESCB obsahuje dokument „Current list of ESCB IT security documents and requirements applicable to systems used to store or process sensitive ESCB information“ (ITC/12/289.rev-1).
6 SEC/GovC/X/14/571a – SEC/GenC/X/14/130a nebo dokument novější, který jej nahradí.
3) oprávnění uživatele/skupiny uživatelů přistupovat ke klasifikovaným informacím (podle atributu souboru, který určuje stupeň klasifikace informací (viz požadavek ODI05 v příloze č.2b smlouvy – Specifické požadavky)).
Kombinacemi výše uvedených oprávnění disponují uživatelé v jednotlivých rolích - viz kapitola 6
5 Popis procesů
Jeden z klíčových prvků systému DMS představuje řízení oběhu dokumentů, včetně řízení přístupu uživatelů, a vytváření a spouštění pracovních procesů či úkolů (workflow) umožňujících uživatelům strukturovaně vytvářet, editovat či připomínkovat dokumenty a schvalovat jejich verze. Procesy musí být možné spouštět jak nad konkrétním souborem nebo více soubory, tak bez předem existujícího souboru, který může být např. výstupem určitého úkolu či procesu. Procesy musí být možné flexibilně modulárně sestavovat z jednotlivých dílčích akcí či typizovaných stavebních kamenů intuitivně samotnými koncovými uživateli podle konkrétních potřeb a úkolů bez nutnosti znalosti programování a bez nutnosti mít dopředu napevno nadefinované všechny kroky všech procesů bez možnosti jejich úprav v průběhu jednoho procesu (např. přidání konkrétního připomínkového místa, schvalovatele, řešitele úkolu, zvýšení či snížení jejich počtu, vynechání některého kroku apod.). Jednotlivé stavební kameny procesů musí být možné upravovat, přidávat či doprogramovat přímo vybranými administrátory ČNB. Workflow tvorby připomínek k dokumentům musí podporovat jak sekvenční, tak paralelní připomínkování dokumentů ze strany uživatelů systému.
Workflow by např. mělo podporovat situaci, kdy v rámci jednoho procesu (úkolu) uživatel vypracuje zadání úkolu, které pošle ke schválení svému nadřízenému, jenž má možnost jej schválit, upravit či zamítnout a vrátit s pokynem zpět k úpravě, a to i opakovaně. Poté, co je zadání úkolu schváleno, je úkol rozeslán dotčeným uživatelům, kteří jej vypracují. Při vypracování musejí mít tito uživatelé možnost požádat v rámci sub-workflow jiné uživatele o pomoc s vypracováním, např. ve formě subdodávky nebo předání dokumentu k připomínkám. Výstupy zpracovatelů následně podléhají schválení jejich vedoucími pracovníky v souladu s interními schvalovacími pravidly, přičemž tito nadřízení opět mají možnost vypracovaný úkol schválit, upravit či vrátit k dopracování. Schválený vypracovaný úkol se následně vrací k jeho zadavateli, který jej rovněž může v případě potřeby vrátit zpět k dalšímu dopracování.
Workflow procesy systému DMS budou typově zahrnovat např.:
1) vložení souboru do DMS, vyplnění metadat, včetně ad hoc přístupových oprávnění,
a nastavení emailové notifikace ostatním uživatelům dle výběru uživatele,
2) vytvoření či editaci profilu konkrétního fóra/složky/agendy v rámci DMS úložiště včetně nastavení příslušných metadat, přístupových oprávnění uživatelů, termínu jednání, bodů programu apod. a nastavení emailové notifikace ostatním vybraným uživatelům na základě výběru provedeného uživatelem,
3) žádost o vypracování nového dokumentu (vytvoření nového souboru),
4) žádost o vypracování stanoviska k dokumentu,
5) žádost o editaci existujícího dokumentu (např. neschváleného stanoviska),
6) žádost o vypracování připomínek k dokumentu formou vytvoření nového dokumentu (připomínkový list) nebo formou revizí přímo do zdrojového dokumentu (režim změn, komentáře), paralelně či sekvenčně,
7) žádost o schválení dokumentu, úpravy.
V kapitole Chyba! Nenalezen zdroj odkazů.9 Vzorový popis procesu ČNB je uveden detailní popis vzorového procesu (workflow), který by měl DMS podporovat. Ten představuje agregovaný typový příklad procesů a postupů, které ČNB používá v rámci svých agend ke zpracování vybraných dokumentů a k nimž bude využíván DMS. Proto je předmětné schéma poměrně robustní, neboť
v koncentrované podobě zachycuje všechny možnosti větvení a průběhu procesu, který může být pro jednotlivé činnosti v praxi příp. rozdělen do více dílčích jednodušších procesů. V praxi může postup spuštění procesu vypadat např. také tak, že uživatel vybere určitý dokument uložený v úložišti DMS a nad ním zadá spuštění konkrétního úkolu, v příslušném formuláři vyplní požadované údaje a proces spustí. Vzorový proces je orientační a bude podrobněji rozveden v analytické a realizační fázi projektu (realizační studii).
6 Uživatelské role
Systém DMS musí řídit přístupová práva uživatelů k souborům a složkám pomocí uživatelských rolí. Systém musí obsahovat přinejmenším následující kategorie uživatelských rolí:
1) Technický správce (TS) – uživatel s právem:
a. konfigurovat systém, včetně nastavování auditovatelnosti
b. spravovat auditní logy
c. spravovat číselníky systému
d. konfigurovat workflow procesy
e. konfigurovat notifikace v systému
f. spravovat úložiště dokumentů (včetně vytváření, editace a odstraňování složek a podsložek)
g. spravovat šablony dokumentů, včetně jejich metadat
h. spravovat přidělování uživatelských rolí
2) Hlavní věcný správce (HVS) – uživatel s právem:
a. spravovat úložiště dokumentů (včetně vytváření, editace a odstraňování složek
a podsložek)
b. spravovat číselníky systému
c. spravovat šablony dokumentů, včetně jejich metadat
d. spravovat přidělování uživatelských rolí a řídit přístupová práva uživatelů k souborům a složkám
3) Dílčí věcný správce na úrovni sekce (DVS) – uživatel s právem:
a. spravovat úložiště dokumentů na úrovni sekce (včetně vytváření, editace
a odstraňování složek a podsložek)
b. spravovat šablony dokumentů na úrovni sekce, včetně jejich metadat
c. řídit přístupová práva uživatelů na úrovni sekce k souborům a složkám příslušné sekce
4) Vedoucí pracovník útvaru ČNB (VED) – vedoucí referátu, ředitel odboru, ředitel SAO, ředitel pobočky, ředitel sekce a jixx xxxxxxxx xástupce – uživatel s právem:
a. xřistupovat do složek a číst dokumenty, k nimž má přístup na základě členství
v aplikační nebo organizační skupině, včetně složek jím vedeného útvaru ČNB
b. vytvářet, editovat a odstraňovat podsložky ve složkách, k nimž má přístup na základě členství v aplikační nebo organizační skupině, včetně složek jím vedeného útvaru ČNB
c. vytvářet, editovat a odstraňovat dokumenty (soubory) ve složce/složkách, k nimž má přístup na základě členství v aplikační nebo organizační skupině, včetně složek jím vedeného útvaru ČNB
d. vkládat dokumenty (soubory) ve složce/složkách, k nimž má přístup na základě členství v aplikační nebo organizační skupině, včetně složek jím vedeného útvaru ČNB
e. editovat metadata k výše uvedeným dokumentům7
7 Součást editace metadat souboru je také nastavení úrovně klasifikace informací. Postup určení klasifikace stanoví Pokyny ČNB č. 38/2015.
f. xxxxxxx x administrovat workflow proces (založit úkol)
g. být součástí workflow procesu (schvalovat zadání úkolu, včetně jeho obsahu, přijmout či odmítnout úkol, schvalovat dokument)
5) Koordinátor (COO) – kontaktní osoba gestora fóra – uživatel s právem:
a. xřistupovat do složek a číst dokumenty, k nimž má přístup na základě členství
v aplikační nebo organizační skupině, včetně složek fór, jichž je koordinátorem
b. vytvářet, editovat a odstraňovat podsložky ve složkách, k nimž má přístup na základě členství v aplikační nebo organizační skupině, včetně složek fór, jichž je koordinátorem
c. vytvářet, editovat a odstraňovat dokumenty (soubory) ve složce/složkách, k nimž má přístup na základě členství v aplikační nebo organizační skupině, včetně složek fór, jichž je koordinátorem
d. vkládat dokumenty (soubory) ve složce/složkách, k nimž má přístup na základě členství v aplikační nebo organizační skupině, včetně složek fór, jichž je koordinátorem
e. editovat metadata k výše uvedeným dokumentům
f. spravovat metadata k fórům, jichž je koordinátorem
g. xxxxxxx x administrovat workflow proces související s dokumenty či fóry, jichž je koordinátorem
6) Zpracovatel úkolu (ZPR) – každý koncový uživatel může být zpracovatelem úkolu – uživatel
s právem:
a. xřistupovat do složek a číst dokumenty, k nimž má přístup na základě členství
v aplikační nebo organizační skupině
b. vytvářet, editovat a odstraňovat dokumenty (soubory) ve složce/složkách, k nimž má přístup na základě členství v aplikační nebo organizační skupině
c. vkládat dokumenty (soubory) ve složce/složkách, k nimž má přístup na základě členství v aplikační nebo organizační skupině
d. editovat metadata k výše uvedeným dokumentům
e. být součástí workflow procesu (číst relevantní informace o procesu, editovat relevantní metadata procesu, činit relevantní úkony v rámci workflow procesu)
7) Koncový uživatel (UZIV) – všichni pracovníci ČNB, kteří mají aktivní účet – uživatel
s právem:
a. xřistupovat do složek a číst dokumenty, k nimž má přístup na základě členství
v aplikační nebo organizační skupině
b. vytvářet, editovat a odstraňovat podsložky ve své osobní složce
c. vytvářet, editovat a odstraňovat dokumenty (soubory) ve své osobní složce
d. vkládat dokumenty (soubory) do své osobní složky
e. editovat metadata dokumentů ve své osobní složce
f. založit workflow proces a stát se součástí workflow procesu (tím koncový uživatel získá roli podle svého postavení v příslušném procesu, např. zpracovatele úkolu).
7 Struktura úložiště
DMS bude sloužit jako náhrada současného IS Obelisk, a tedy úložiště vybraných digitálních dokumentů pro všechny organizační útvary ČNB, čemuž musí odpovídat i adresářová struktura úložiště DMS. Přesné a podrobné vymezení adresářové struktury úložiště bude provedeno v realizační studii, změna a úpravy struktury musí být proveditelné přímo oprávněnými uživateli v rámci ČNB. Musí být možné rovněž využití tzv. virtuálních složek.
V rámci jednotného úložiště bude vymezen prostor pro osobní složky každého uživatele, dále pro organizační útvary ČNB a jejich organizační jednotky, přičemž konkrétní podadresářová struktura adresáře každého organizačního útvaru bude z velké části ponechána na rozhodnutí ředitele
příslušného organizačního útvaru s tím, že některé adresáře mohou být stejné a povinné pro všechny organizační útvary (např. adresář vnitřní předpisy, s podadresáři pokyny ČNB, metodické listy, rozhodnutí, adresář předpisy ČNB s podadresáři předpisy publikované ve sbírce zákonů, předpisy publikované ve Zpravodaji ČNB, předpisy publikované ve Věstníku ČNB, adresář oznámení ČNB, adresář opatření ČNB apod.). Další skupinu adresářů budou tvořit adresáře pro jednotlivé zajišťované agendy průřezového charakteru (např. bankovní rada, EU, vnitřní připomínkové řízení, vnější připomínkové řízení, materiály do vlády, parlamentní agenda, compliance, krizový plán atd.).
V zájmu urychlení vyhledávání v DMS bude úložiště DMS rozděleno do dvou částí se shodnou adresářovou strukturou: a) hlavní úložiště DMS a b) Archiv DMS. Archiv DMS bude sloužit k dlouhodobému uložení dokumentů, u nichž je předpoklad, že se s nimi již nebude aktivně pracovat. Přesto budou uživatelům přístupné stejným způsobem a se stejnými funkcionalitami jako dokumenty uložené v hlavním úložišti DMS. Po uplynutí stanovené doby bude v závislosti na atributu Skartační a archivační znak dokument z Archivu DMS trvale smazán, příp. oprávněný uživatel/administrátor rozhodne o jeho dalším osudu. Archiv DMS nebude sloužit k evidenci a archivaci dokumentů ve smyslu požadavků zákona č. 499/2004 Sb., o archivnictví a spisové službě. Dokumenty, které je třeba evidovat a archivovat budou z DMS předávány do IS e-Spis; jejich kopie zůstanou rovněž v DMS. Lhůta pro automatickou archivaci bude jedním z atributů dokumentu v DMS, jeho hodnota bude standardně děděna z nadřazené složky, avšak uživatel bude schopný ji měnit individuálně pro jednotlivé složky v rámci editace složky. Výchozí hodnota pro celý systém bude nastavena na hodnotu 3 roky s možností její následné úpravy.
Pro bližší představu uvádíme jako příklad činnosti a agendy v působnosti sekce regulace a mezinárodní spolupráce na finančním trhu a sekce kancelář, pro jejichž výkon může být systém DMS používán:
1) kompletní zajištění jednání mezinárodních organizací v působnosti sekce regulace a mezinárodní spolupráce na finančním trhu (včetně vybraných orgánů, výborů a pracovních skupin EU, ESCB, MMF, EBRD, OECD aj.), jichž se účastní zástupce ČNB, a dalších mezinárodních jednání, k nimž ČNB zasílá připomínky pro zástupce ČR na jednání v systému vládní koordinace (sledování programu jednání a zařazených materiálů, příprava a schvalování stanovisek pro zástupce ČNB a připomínek k materiálům),
2) kompletní příprava pro jednání Výboru pro Evropskou unii na vládní i pracovní úrovni (sledování programu jednání a zařazených materiálů, příprava a schvalování stanovisek pro zástupce ČNB a připomínek k materiálům),
3) administrace jednání vlády ČR (sledování programu jednání vlády a zařazených materiálů, příprava a schvalování stanovisek pro účast zástupce ČNB),
4) administrace meziresortních připomínkových řízení (sledování materiálů v meziresortním připomínkovém řízení, příprava a schvalování stanovisek a připomínek ČNB),
5) administrace vnitrobankovního připomínkového řízení k interním předpisům, popř. dalším materiálům ČNB,
6) příprava jednání bankovní rady,
7) zpracování příchozí a odchozí pošty, včetně korespondence členů bankovní rady.
Jako konkrétní příklad uvádíme dále náčrt možné struktury úložiště pro sekci regulace a mezinárodní spolupráce na finančním trhu a podrobněji pro odbor EU a mezinárodních organizací (EUMO). Jednotlivé úrovně označují hloubku adresářové struktury, které v zásadě kopíruje organizační strukturu jednotlivých mezinárodních fór, jejichž jednání se účastní zástupci ČNB. Každá mezinárodní organizace má zpravidla vrcholné fórum, kde se scházejí představitelé na vysoké úrovni, a dále pracovní orgány – výbory, případně podvýbory a pracovní skupiny. Jednotlivá fóra jsou rovněž seskupována do vyšších celků. V DMS bude mít každé takové fórum přiřazeno vlastní adresář a podadresáře odpovídající jeho jednotlivým jednáním a jednotlivým bodům programu těchto jednání. Pro celkový velký počet fór (řádově stovky fór) však neuvádíme jejich úplný výčet, nýbrž pouze neúplný příklad základního rozdělení agend odboru EUMO. V rámci I. úrovně lze agendu tohoto
odboru rozdělit na následující složky: EU, ECB/ESCB, ESFS, MMF, OECD, EBRD, BIS, koordinace
EU na národní úrovni, ratingové agentury.
Pod adresář EU v rámci II. úrovně spadají podadresáře Rada EU, Evropská rada a Evropská komise, pod adresář ECB/ESCB podadresáře Generální rada ECB, písemné procedury a výbory ECB. Pod adresář ESFS spadají v rámci II. úrovně podadresáře ESRB, EBA, EIOPA a ESMA. V adresáři koordinace EU na národní úrovni bude na úrovni II. zařazen adresář Výbor pro EU. Agenda ratingových agentur bude v rámci úrovně II. obsahovat výčet ratingových agentur, tedy podadresáře Moody´s, Standard & Poor´s, Fitch, JCRA a R&I.
V rámci III. úrovně do adresáře Rada EU spadají agendy Rada ECOFIN, Rada GAC, Rada EPSCO a pracovní skupiny Rady. Pod agendu Evropské komise spadá složka výbory Evropské komise. Pod výbory ECB v rámci agendy ECB budou zařazeny složky s výčtem jednotlivých výborů, mezi které patří AMICO, BANCO, FSC, ECCO, HRC, IAC, IRC, ITC, LEGCO, MIPC, MOC, MPC, STC,
HoR. Pod položkou ESRB budou podadresáře Generální rada ESRB, písemné procedury a výbory ESRB, pod položkami EBA, EIOPA a ESMA podadresáře Rada orgánů dohledu, výbory EBA/EIOPA/ESMA, pracovní orgány EBA/EIOPA/ESMA. V rámci adresáře koordinace EU na národní úrovni bude v rámci III. úrovně provedeno rozdělení složky Výbor pro EU na Výbor pro EU na vládní úrovni a Výbor pro EU na pracovní úrovni.
Do IV. úrovně spadají v rámci adresáře Rada ECOFIN podadresář EFC, do V. úrovně do adresáře EFC podadresáře SCIMF, EFC-A, ESDM atd.
8 Výstupy ze systému
Systém umožnuje uživateli vyexportovat v elektronicky čitelné a tisknutelné podobě:
a) seznamy výsledků hledání dokumentů do csv, rtf nebo xls souborů,
b) informace (metadata) o určitém souboru v DMS,
c) auditní log vybrané složky/dokumentu v systému,
d) seznam oprávněných uživatelů k dané složce,
e) seznam oprávnění, kterými disponuje určitý uživatel nebo skupina uživatelů,
f) přehledy vybraných informací z konkrétních workflow.
9 Popis vzorového procesu ČNB
DMS - (BPMN 1.1 diagram)
Upravený proces DMS II_170529.jpg
Název | Popis | Typ |
Koordinátor žádajícího útvaru | Lane | |
Název | Popis | Typ |
01. START | Uživatel analyzuje situaci. Proces startuje rozhodnutím o tom, zda je nebo není k dispozici dokument, který bude vložen do DMS. | StartEvent |
02. Chci pouze vložit dokument do DMS? | Rozhodovací krok 02 Pokud ANO: proces pokračuje rozhodovacím krokem 07. Je dokument | Gateway |
evidován v jiném IS? Pokud NE: proces pokračuje činností 03. | ||
Založení úkolu. |
03. Založit/upravit úkol | Oprávněný uživatel (koordinátor) založí nový úkol v systému DMS. Úkol může být typu: - žádost o vypracování nového dokumentu/ů - žádost o stanovisko/a k dokumentu/ům nebo úpravu neschváleného stanoviska - žádost o připomínky k dokumentu/ům nebo úpravu neschválených připomínek - žádost o schválení dokumentu/ů V úkolu se zadává: - zpracovatel (hlavní zpracovatel-gestor, spoluzpracovatelé) - požadavky na vypracování (obsahové a formální, včetně příp. závazné či doporučené šablony) - schvalovatel úkolu - termín pro přijetí/odmítnutí úkolu - termín pro vypracování požadovaného xxxxx. Xx tohoto kroku se vrací proces v případě: - když založení úkolu není schváleno nadřízeným (rozhodovací krok 15) - když se koordinátorovi vrátí odmítnutý úkol od uživatele (rozhodovací krok 20) a je třeba přidělit úkol jinému útvaru (rozhodovací krok 21). Koordinátor musí nastavit nového zpracovatele úkolu - když se vypracovaný úkol koordinátorovi vrátí jako neschválený od nadřízeného schvalovatele (rozhodovací krok 37). Koordinátor musí přidělit úkol: - žádost o úpravu neschváleného stanoviska - žádost o úpravu neschválených připomínek | Activity |
04. Jedná se o změnu přidělení úkolu jiné osobě/útvaru? | Rozhodovací krok 04 Pokud ANO: proces pokračuje rozhodovacím krokem 13, zdali je třeba, aby byl úkol zkontrolován nadřízeným Pokud NE: proces pokračuje dalším rozhodovacím krokem 05. | Gateway |
05. Je založený úkol vázán k již existujícímu dokumentu? | Rozhodovací krok 05 Pokud ANO: proces pokračuje dalším rozhodovacím krokem 06 Pokud NE: proces pokračuje rozhodovacím krokem 13, zdali je třeba, aby byl úkol, resp. jeho zadání, zkontrolován nadřízeným. | Gateway |
06. Je dokument již vložen do DMS? | Rozhodovací krok 06 Pokud ANO: proces pokračuje rozhodovacím krokem 13, zdali je třeba, aby byl úkol zkontrolován nadřízeným Pokud NE: proces pokračuje rozhodovacím krokem 07. | Gateway |
07. Je dokument evidován v jiném IS? | Rozhodovací krok 07 Pokud ANO: proces pokračuje činností 08. Přenos dokumentu z jiného IS do DMS Integrace s jinými IS bude popsána v Realizační studii ve spolupráci s vybraným poskytovatelem. Pokud NE: proces pokračuje činností 09.Vložení/vytvoření dokumentu v/do DMS | Gateway |
08. Přenést dokument z jiného IS do DMS | V tomto kroku bude proveden import obsahu a atributů dokumentu do DMS z informačního systému, ve kterém dokument vznikl (např. e- KLEP) nebo je tam evidován (e-Spis). Uživateli vykonávajícímu tuto činnost v DMS musí být přidělena oprávnění k dokumentu. | Activity |
09. Vložit/vytvořit dokument do/v DMS | Jakýkoliv oprávněný uživatel systému DMS vloží do příslušné složky v DMS již existující dokument, vytvoří nový dokument a uloží jej do příslušné složky v DMS nebo uloží dokument, který se přenáší z jiného IS (viz činnost 08. Přenést dokument z jiného IS do DMS). Parametry uložení dokumentu do DMS: - použití příslušné šablony dle fóra/agendy - vyplnění metadat, minimálně povinných atributů - nastavení přístupových práv k dokumentu, pokud je třeba jiných, než která jsou definována v příslušné složce, kam je dokument ukládán - určení klasifikace informací obsažených v dokumentu O vložení nového dokumentu jsou informováni příslušní uživatelé - Notifikace A. | Activity |
10. Existuje příslušná složka pro vložení dokumentu? | Rozhodovací krok 10 Pokud ANO: dokument je do složky uložen a proces pokračuje dalším rozhodovacím krokem 12 Pokud NE: proces pokračuje činností 11. Založení složky v DMS podle atributu Fórum/Agenda (složku může založit stejný uživatel, který vkládá nový dokument). | Gateway |
11. Založit složku v DMS | Založení nové složky pro uložení dokumentu v DMS, zakládá ji oprávněný uživatel DMS podle metodiky. Složka může být založena i mimo vlastní proces WF oprávněným uživatelem, který spravuje strukturu složek úložiště v DMS. O založení nové složky je informována notifikačním e-mailem příslušná skupina uživatelů - Notifikace B. Pokud je u nové složky vyplněn atribut Termín, propisuje se tento termín příslušné skupině uživatelů do kalendáře v MS Outlook. Notifikace C je rozeslána stejné skupině uživatelů jako notifikace o nové složce. | Activity |
12. Xxxxxxxxx s úkolem? | Rozhodovací krok 12 Pokud ANO: proces pokračuje rozhodovacím krokem 13 Pokud NE: proces je ukončen. | Gateway |
13. Je třeba kontroly úkolu u nadřízeného? | Rozhodovací krok 13 Pokud ANO: proces pokračuje činností 14. Posouzení úkolu nadřízeným Pokud NE: proces pokračuje rozhodovacím krokem 16. | Gateway |
16. Potřebuji pouze schválit dokument? | Rozhodovací krok 16 Pokud ANO: proces pokračuje rozhodovacím krokem 35 Pokud NE: proces pokračuje rozhodovacím krokem 17. Potřebuji poslat úkol sekvenčně? | Gateway |
17. Potřebuji úkol poslat sekvenčně? | Rozhodovací krok 17 Pokud ANO: je zahájeno WF pro sekvenční postup zpracování úkolu Pokud NE: proces pokračuje činností 18. Odeslání úkolu. | Gateway |
17.1 Zahájit sekvenční WF | V tomto kroku začíná subproces WF pro sekvenční postup zpracování úkolu. V sekvenčním WF jsou jednotlivé úkoly zasílány postupně na určené uživatele vždy po dokončení úkolu předchozím uživatelem. Oproti WF, které se spouští v činnosti 18. Odeslat úkol nebo při činnosti 29. Spolupracovat na vypracování úkolu. | Activity |
18. Odeslat úkol | Úkol může být rozesílán na více míst paralelně (multiinstanční aktivita). Koordinátor odesílá připravený úkol na určené zpracovatele dožádané sekce/sekcí nebo jiných organizačních jednotek podle povahy posuzovaného dokumentu a podle metodiky . Úkol typu: - žádost o vypracování nového dokumentu/ů - žádost o stanovisko/a k dokumentu/ům nebo úpravu neschváleného stanoviska - žádost o připomínky k dokumentu/ům nebo úpravu neschválených připomínek V DMS se nastavují dva termíny: Termín 1 - akceptace/odmítnutí úkolu Termín 2 - vypracování úkolu V DMS je rozesílána notifikace zpracovatelům o typu přiděleného úkolu, o termínu akceptace úkolu a o termínu vypracování úkolu (notifikace D). . | Activity |
21. Přidělit jinému útvaru? | Rozhodovací krok 21 pokud ANO: úkol je třeba přidělit jinému vybranému uživateli, proces se vrací do činnosti 03. Založení úkolu pokud NE: proces pokračuje provedením záznamu o odmítnutí úkolu v činnosti 22. Záznam o nepřidělení úkolu. | Gateway |
23. Zaznamenat nepřidělení úkolu | Koordinátor zaznamená důvod nepřidělení úkolu jinému zpracovateli do formuláře o vypořádání úkolů k dokumentu: a) úkol je odmítnut z důvodu nepříslušnosti dožadovaného útvaru k dané tématice b) úkol je odmítnut z důvodu nepotřebnosti zpracování samostatného výstupu c) popř. další důvod. | Activity |
34. Předložit dokument/y koordinátorovi | Koordinátor shromažďuje všechny úkoly - dokumenty (stanoviska) od oslovených uživatelů do formuláře o vypořádání úkolu a připraví výsledný dokument/složku ke schválení. | Activity |
35. Je třeba schválit nadřízeným? | Rozhodovací krok 35 Pokud ANO: celá úloha odchází ke schválení nadřízenému, následuje činnost 36. Schválení dokumentu/ů nadřízeným Pokud NE: dokument/stanovisko koordinátor uloží do DMS (činnost 41. Uložení finálního dokumentu do DMS). | Gateway |
39. Schválit dokument v dalším stupni | Pokud je nadřízeným koordinátora rozhodnuto, dokument je koordinátorem postoupen k dalšímu stupni schvalování. Tato činnost se může opakovat vícenásobně. Záleží na výsledku rozhodovacího kroku 38. | Activity |
40. Zpracovat překlad nebo jazykovou korekturu | Pokud je nadřízeným koordinátora rozhodnuto, daný dokument je postoupen k překladu nebo jazykové korektuře. | Activity |
41. Uložit finální dokument v DMS | Výsledný dokument je uložen do příslušné složky v úložišti XXX. Xx určené uživatele odchází notifikace o uloženém dokumentu. | Activity |
42. Bude dokument předán do jiného IS? | Rozhodovací krok 42 Pokud ANO: pokračuje činnost 43. Předat dokument do dalšího IS Pokud NE: proces je ukončen. | Gateway |
43. Předat dokument do dalšího IS | Dokument je postoupen: 1) do IS – e-Spis: a) vrácení dokumentu, který byl již v e-Spisu b) založení dokumentu do e-Spisu, přidělení čísla jednacího, označení skartačním znakem a dále k zajištění oficiálního odeslání dokumentu Datovou zprávou, popř. fyzicky poštou 2) do dalších systémů např. Xxxxxx, e-KLEP. | Activity |
KONEC | Ukončení celého procesu. | EndEvent |
A- Notifikace o novém dokumentu v DMS | Notifikace A upozorňuje na nově vložený dokument do příslušné složky určenou skupinu uživatelů. Notifikace obsahuje název dokumentu, autora… | IntermediateEv ent |
B- Notifikace o nové složce v DMS | Notifikace B o založení nové složky, kterou je informována příslušná skupina uživatelů. Zpráva obsahuje název složky, autora… | IntermediateEv ent |
C- Notifikace o termínu | Notifikace C o termínu jednání, ke kterému se budou vztahovat dokumenty do složky vkládané. Termín se propisuje do kalendáře MS Outlook nebo jiného určeného kalendáře (pokud to systém umožní). | IntermediateEv ent |
D- Notifikace o přidělení úkolu | Notifikace D je odeslána vybranému uživateli/lům, obsahuje popis přiděleného úkolu. | IntermediateEv ent |
F- Notifikace o uložení finálního dokumentu | Notifikace F o uložení výsledného dokumentu určeným uživatelům. | IntermediateEv ent |
Termín 1 - akceptace úkolu | Do tohoto termínu musí oslovený zpracovatel úlohu přijmout nebo odmítnout. | IntermediateEv ent |
Termín 2 - vypracování úkolu | Do tohoto termínu musí oslovený zpracovatel vypracovat požadovaný úkol. | IntermediateEv ent |
Název | Popis | Typ |
Nadřízený koordinátora | Lane | |
Název | Popis | Typ |
14. Posoudit úkol nadřízeným | Kontrola založeného úkolu (znění úkolu, termíny, oslovení zpracovatelé, apod.) nadřízeným koordinátora. | Activity |
15. Je založený úkol v pořádku? | Rozhodovací krok 15: Pokud ANO: proces pokračuje dál rozhodovacím krokem 16 Pokud NE: úkol se vrací do činnosti 03. Založení úkolu koordinátorovi s komentářem, kde je uvedeno, co je třeba upravit. | Gateway |
36. Schválit dokument/y nadřízeným | Nadřízený posuzuje předložený dokument (stanovisko). Při této činnosti má uživatel oprávnění číst dokument. | Activity |
37. Je stanovisko/dokument schválen? | Rozhodovací krok 37 Pokud ANO: proces pokračuje rozhodovacím krokem 38. Je třeba další schválení/zpracování? a schválený dokument je v systému předáván dále k - k dalšímu stupni schválení (popř. překladu/jazykové korektuře apod.) Pokud NE: dokument se vrací ke koordinátorovi, aby zajistil zapracování připomínek od příslušného zpracovatele, k jehož dokumentu dal schvalovatel komentář/připomínky - aktivita 18. Odeslání úkolu typu žádost o úpravu neschváleného dokumentu/neschváleného stanoviska. | Gateway |
38. Je třeba další schválení/ zpracování? | Rozhodovací krok 38 Pokud ANO: Dokument je postoupen koordinátorovi, aby podle potřeby zajistil: 1) schválení na vyšší úrovni podle metodiky (činnost 39) 2) překlad do angličtiny nebo jiného jazyka nebo jazykovou korekturu v češtině (činnost 40) Tato aktivita se může opakovat podle metodiky až do získání finálního stavu. Pokud NE: proces pokračuje činností 41. Uložení finálního dokumentu v DMS. | Gateway |
Název | Popis | Typ |
Ředitel dožádané sekce | Lane | |
Název | Popis | Typ |
19. Rozhodnout o vypracování úkolu | Oslovený uživatel na základě obdržených informací rozhodne o přijetí nebo odmítnutí úkolu (zpracování stanoviska/substanoviska, vypracování připomínek,…). Tato činnost je vázána na Termín 1 - akceptace úkolu, pokud úkol není odmítnut v nastaveném termínu, má se za to, že je úkol přijat. | Activity |
20. Přijmout úkol? | Rozhodovací krok 20 Pokud ANO: proces pokračuje aktivitou 24. Přidělení vypracování úkolu v rámci sekce Pokud NE: odmítnutí úkolu je třeba vysvětlit v komentáři, proces pokračuje dalším rozhodovacím krokem 21. Přidělit úkol jinému útvaru. | Gateway |
24. Přidělit vypracování úkolu v rámci sekce | Uživatel přijímá úkol a určuje hlavního zpracovatele, pokud jím není on sám. K tomuto kroku se váže Termín 3 - vypracování úkolu v rámci sekce. | Activity |
28. Potřebuji spolupráci další org. jednotky? | Rozhodovací krok 28 Pokud ANO: start subprocesu 29. Spolupráce na vypracování úkolu Pokud NE: přesun na aktivitu 27. Předložení vypracovaného úkolu/dokumentu ke schválení. | Gateway |
29. Spolupracovat na vypracování úkolu | Subproces je složen z aktivit totožných s aktivitami v hlavním procesu. Může být spuštěno více subprocesů paralelně najednou. Další uživatelé spolupracující na splnění úkolu jsou stanovováni (ředitelé odborů, vedoucí referátů či referenti). Pokud je osloveno více uživatelů zároveň, je určen gestor za celý úkol. Všem nadefinovaným uživatelům musí systém pro příslušnou činnost vypracování úkolu přidělit oprávnění a po vypracování úkolu opět odebrat oprávnění k editaci souvisejícího dokumentu/ů. | Activity |
27. Předložit vypracovaný úkol/dokument ke schválení | Vypracovaný dokument je předložen k posouzení zadavateli. | Activity |
30. Schváleno? | Rozhodovací krok 30 Pokud ANO: zadavatel dokument schválí, následuje krok 31. Je třeba další schválení? Pokud NE: zadavatel odmítá schválit předložený dokument, napíše do komentáře své připomínky, následuje činnost 31. Zapracování připomínek. | Gateway |
32. Je třeba další schválení? | Rozhodovací krok 32 Pokud ANO: pokračuje činnost 33. Další stupeň schválení Pokud NE: pokračuje činnost 34. Předložení dokumentu/ů koordinátorovi. | Gateway |
Název | Popis | Typ |
Zpracovatel úkolu | Lane | |
Název | Popis | Typ |
25. Navrhuji nadřízenému další útvar/jednotlivce ke spolupráci na úkolu? | Rozhodovací krok 25 Pokud ANO: uživatel napíše do komentáře k úkolu svůj návrh na dalšího spoluzpracovatele. Pokud NE: proces pokračuje činností 25. Vypracování úkolu. | Gateway |
26. Vypracovat úkolu | Uživatel zpracuje požadovaný úkol, tj. vytvoří nový dokument nebo novou verzi k dokumentu v DMS. Všem nadefinovaným uživatelům musí systém pro činnost vypracování úkolu přidělit oprávnění a po vypracování úkolu opět odebrat oprávnění k editaci souvisejícího dokumentu/ů. | Activity |
31. Zapracovat připomínky | Uživatel zapracovává doručené připomínky. | Activity |
BPMN 29. Spolupracov at na v ypracov ání úkolu
Termín 1.1 - Termín 2.1 - vypracování
akceptace úkolu úkolu
START subprocesu
Termín 2.1 - vypracování úkolu
29.1. Založit 29.2 Odeslat úkol 29.6 Zaznamenat 29.14 Předložit
úkol spolupracujícímu nepřidělelní schválený
útvaru úkolu úkol/dokument
KONEC subprocesu
29.5 Přidělit
Ano jinému útvaru?
Ne
Termín 1.1 - akceptace úkolu
Komentář k
odmítnutí
29.4
Přijetí úkolu?
Ne
Termín 3.1 - vypracování úkolu v rámci odboru
29.7 Přidělit vypracování úkolu v
rámci odboru
29.10 Spolupracovat
na vypracování úkolu
Ano
29.3 Rozhodnout o
přijetí úkolu
Ano
29.9 Potřebuji spolupráci další
org.jednotky?
D.1 Notifikace o
přidělení úkolu
Ne
Ano
29.11 Předložit vypracovaný
úkol/dokument ke schválení
29.12
Schváleno ?
Ne
E.1- Notifikace o nesplnění úkolu v termínu
Komentář k
odmítnutí
29.8 Vypracovat
úkol
29.13 Zapracovat
připomínky
«Lane» Zpracovatel substanoviska «Lane» Koordinátor dožádaného odboru
«Lane» Ředitel dožádaného odboru
Subproces: 29. Spolupracovat na vypracování úkolu
BPMN 29.10. Odeslat žádost o další substanov isko
Termín 1.1 - akceptace úkolu
Termín 2.1 - vypracování úkolu
START
subprocesu
29.1.
Založit úkol
29.2 Odeslat úkol spolupracujícímu útvaru
29.6 Zaznamenat
nepřidělelní úkolu
29.14 Předložit schválený
úkol/dokument
KONEC subprocesu
Ano
29.5 Přidělit jinému útvaru?
Ne
Termín 1.1 -
akceptace úkolu 29.4
Přijetí
Komentář k
odmítnutí
Termín 3.1 - vypracování úkolu v rámci odboru
Ne
Ano
29.10 Spolupracovat
na vypracování úkolu
29.3 Rozhodnout o
přijetí úkolu
úkolu?
Ano
29.7 Přidělit vypracování úkolu v
rámci odboru
29.9 Potřebuji spolupráci další
org.jednotky?
D.1 Notifikace o
přidělení úkolu
Ne
29.11 Předložit vypracovaný
úkol/dokument ke schválení
Ano
29.12
Schváleno ?
Ne Komentář k
odmítnutí
29.8 Vypracovat
úkol
29.13 Zapracovat
připomínky
«Lane» Zpracovatel substanoviska «Lane» Koordinátor dožádaného odboru
«Lane» Ředitel dožádaného odboru
Subproces: 29. 10 Odeslat žádost o další substanovisko
Pozn. proces se může větvit dle potřeby zadavatele.
10 Funkční požadavky
Tabulka funkčních požadavků je uvedena v příloze č. 1b smlouvy.
V tabulce vyplňte žlutě označené sloupce.
11 Příklady podoby grafického uživatelského rozhraní
Níže uvádíme pro podrobnější představu možnou podobu vybraných částí grafického uživatelského rozhraní DMS s demonstrativní ukázkou realizace požadovaných funkcí, jak jsou obsaženy v jednotlivých přílohách zadávací dokumentace. Zobrazené vzory mají sloužit pouze pro inspiraci, tzn. že nabízené řešení nemusí být 100% identické.
1. Kalendář jednotlivých jednání fór (denní zobrazení)
2. Kalendář jednotlivých jednání fór (týdenní zobrazení)
3. Kalendář (detail vybraného jednání fóra)
4. Kalendář (zobrazení jednání fór v kalendáři dle jednotlivých fór)
5. Vyhledávání dokumentů dle jejich vazby na jednání (sledovaných fór) nebo dle data vložení
6. Navigace mezi jednotlivými fóry (zobrazení dle času)
7. Navigace mezi jednotlivými fóry (zobrazení dle typu orgánu)
8. Vytvoření nového jednání konkrétního fóra
9. Dialogové okno vložení jednoho či více souborů (s možností nastavení tiché procedury)
10. Zobrazení konkrétního bodu jednání určitého fóra
11. Navigace dle určité věcné agendy
12. Vytvoření nové agendy
13. Vytvoření nové agendy (pokračování)
14. Nastavení avíza (emailové notifikace)
Funkční požadavky
Správa souborů a složek (SSS) | ||
ID | Název | Popis požadavku |
SSS01 | Základní operace se soubory a složkami souborů se zachováním přístupových práv | Systém obsahuje funkce pro snadné a intuitivní vytváření, ukládání, přesouvání, kopírování, mazání souborů a složek souborů (jednotlivých souborů a složek nebo skupiny souborů a složek, tzn. hromadně), včetně jejich podstruktury v úložišti systému DMS, které je přístupné z desktopových aplikací (MS Office, prohlížeč PDF) a internetového prohlížeče standardního systémového prostředí ČNB, a to s ohledem na přístupová práva koncového uživatele. |
SSS02 | Importování/ vkládání souborů/složek do úložiště DMS | Systém obsahuje funkce importu jednotlivého souboru, množiny souborů, složky či složek souborů včetně jejich podstruktury vytvořené mimo systém DMS: a) z grafického uživatelského prostředí DMS – pomocí funkcionality "vložit soubor/y" do příslušné složky (od toho se budou odvíjet relevantní metadata dle šablony) nebo přetažením souboru, souborů (včetně emailových zpráv) pomocí funkce "drag and drop" do příslušné složky v úložišti DMS b) z prostředí MS Office – pomocí příslušného plug-inu “uložit do DMS”; následně bude nutné zvolit cílovou složku v úložišti DMS c) z prostředí MS Windows průzkumníka – funkcionalita “odeslat do DMS” integrovaná do panelu možností po kliknutí pravým tlačítkem myši na soubor či složku d) z prostředí MS Outlook – pomocí příslušného plug-inu “uložit do DMS” e) z prostředí prohlížečů PDF souborů (Adobe Reader) nebo aplikace Software 602 Signer – pomocí funkcionality soubor – uložit do DMS f) z prostředí internetového prohlížeče (alespoň MS Internet Explorer ) – pomocí funkcionality soubor – uložit do DMS Při ukládání souboru jinak než z prostředí DMS (sub písm. a) systém vyvolá příslušné dialogové okno (průvodce vložením) umožňující vyplnit příslušná metada. Další požadavky na import: g) Při importu se automaticky zapisují základní systémové atributy souboru (datum uložení, autor atd.) a zároveň systém vyzve k doplnění povinných atributů, bez kterých nelze provést finální uložení do DMS. h) Při hromadném vkládání souborů musí být zajištěno postupné vkládání jednotlivých souborů s doplňováním atributů (systémových, povinných i nepovinných). V takovém případě nejsou generovány emailové notifikace (viz požadavek NOT01) po každém vložení a vyplnění metadat jednotlivého souboru, nýbrž systém musí podporovat automatické odeslání jedné souhrnné emailové notifikace po vložení a vyplnění metadat posledního vkládaného souboru v rámci hromadného importu, která bude obsahovat odkazy na všechny nově vložené soubory. |
SSS03 | Export souborů/složek | Systém obsahuje funkce exportu jednotlivého souboru, množiny souborů, složky či složek souborů se zachováním jejich podstruktury mimo systém DMS. Export souboru musí být možný oprávněným uživatelem bez ohledu na formát exportovaného souboru. Společně s exportovaným souborem, soubory, složkou či více složkami musí být možné zvolit i export jejich metadat. |
SSS04 | Kopírování/přesouvání souborů/složek | Systém obsahuje funkce kopírování či přesouvání zvolených souborů, množiny souborů, složky či složek souborů včetně jejich podstruktury v rámci systému DMS s ohledem na oprávnění jednotlivých uživatelů, včetně všech metadat souboru a vazeb na ostatní objekty v DMS, při zachování nezměněného obsahu všech souborů. Při kopírování lze určit, zda v novém umístění bude vytvořena kopie souborů/složek nebo zda bude v novém umístění vytvořen zástupce souborů/složek ve smyslu přímého odkazu na cílový soubor/složku souborů. |
SSS05 | Mazání souborů/složek | Oprávněný uživatel a administrátor má právo v rámci systému DMS mazat jím zvolené soubory nebo složky souborů včetně jejich podstruktury a včetně všech jeho metadat, vazeb a oprávnění, a to i hromadně. Systém DMS automaticky kontroluje, zda odkazy/reference v DMS odkazující na objekt v DMS odkazují na existující objekt. V případě, že odakzovaný objekt (soubor/složka) byl smazán, smaže systém i neplatný odkaz na něj. |
SSS06 | Obnova smazaných dokumentů/složek (funkce „koš“) | Oprávněný uživatel má právo obnovit smazaný soubor či soubory/složku souborů včetně všech jeho metadat a vazeb (individuálně či hromadně), pokud má příslušná oprávnění a nevypršel časový limit pro trvalé smazání (časový limit může nastavovat administrátor systému DMS). Trvale smazané dokumenty/složky lze obnovit pouze z provedené systémové zálohy. |
SSS07 | Externí odkazy na soubory | Systém obsahuje funkci automatického vytvoření srozumitelných externích odkazů (URL adresy) na soubory/složky souborů jako jednoho ze základních (systémových) atributů souboru/složky. Uživatel s takovým atributem běžně pracuje - vkládá do emailových zpráv, do jiných dokumentů, apod. Při kliknutí na odkaz se uživateli otevře odkazovaný soubor/složka souborů v novém okně/záložce, tuto funkci musí systém podporovat pro přístupy v rámci vnitřního prostředí ČNB (např. intranet ČNB, MS Outlook apod.) |
SSS08 | Individuální úložiště (složka) | Systém každému uživateli automaticky vytvoří vlastní úložiště souborů (ve struktuře úložiště označenou jako Osobní složku/My Site apod.), které je přístupné jenom příslušnému uživateli a administrátorovi a u nějž lze nastavit jeho maximální velikost. |
SSS09 | Sdílená úložiště | Každý oprávněný uživatel má právo vytvářet ad-hoc sdílené složky a podsložky v dostatečném počtu úrovní zanoření složek, které garantuje vygenerování korektního externího odkazu (tj. s ohledem na max. délku URL adresy = 256 znaků). Tyto složky mohou obsahovat neomezený počet souborů, ke kterým se dědí oprávnění dle složky, ve které jsou vytvořeny; přístup k těmto složkám a souborům v nich obsaženým je řízen dle oprávnění uživatelů. Rovněž je možno definovat přístupy pro jednotlivé zaměstnance ČNB či jejich skupiny, popř. výběrem z již nadefinovaných skupin uživatelů z ŘDB/AD, ad hoc pro jednotlivou složku a její podsložky. |
SSS10 | Nezávislost na formátu souboru | Systém umožňuje ukládání souborů a další operace uvedené v požadavcích SSS01–SSS07 nezávisle na jejich formátu. Zejména musí podporovat soubory v následujících formátech nebo ve formátech používaných v následujících aplikacích: (1) MS Office 2010 a vyšší, (2) Adobe Acrobat, (3) komprimované soubory typu zip, rar apod. (4) obrazové formáty jpg, tiff, bmp, png, gif (5) šifrované soubory. |
SSS11 | Základní přístupová oprávnění | Každý oprávněný uživatel musí mít možnost definovat následující oprávnění k objektům (soubor, složka souborů, agenda, metadata určitého objektu, šablona dokumentu/souboru a šablona fóra, uložené dotazy): (1) vytvoření, (2) zobrazení/čtení, (3) aktualizace/editace, (4) kopírování/přesouvání, (5) mazání. |
SSS12 | Archivace v systému DMS | Systém musí umožnit archivaci označených souborů a složek, vč. souvisejících metadat, a dle předepsaných podmínek (skartační a spisový znak) je automaticky uložit do archivační složky systému DMS (Archiv DMS) po stanovené době. Podmínky archivace jsou editovatelné oprávněným uživatelem pro jednotlivé soubory/složky či definované skupiny souborů/složek. Archiv DMS bude mít stejnou strukturu složek jako úložiště aktivních dokumentů. Pozn. archivací se zde rozumí přesun objektu z aktivního úložiště DMS do Archivu DMS. O přesunutí určitého souboru, souborů či jejich složek do Archivu DMS musí mít možnost rozhodnout i ad hoc individuálně oprávněný uživatel (mimo automatické procesy běžící dle nastavených lhůt). |
SSS13 | Skartace/mazání souborů z Archivu DMS | Systém po uplynutí nastavené skartační lhůty archivační složky pošle notifikaci oprávněnému uživateli (gestorovi archivační složky), který odsouhlasí její skartaci nebo export do externího úložiště nebo export do IS e-Spis nebo rozhodne o změně příslušného atributu (skartačního znaku). Vlastní skartaci (nenávratné smazání) provede administrátor DMS. |
Správa metadat (SME) | ||
ID | Název | Popis požadavku |
SME01 | Definice metadat | Systém musí umožnit přiřadit každému souboru/složce/fóru/agendě určitá metadata. Každý oprávněný uživatel může definovat další atributy (metadata) k jednotlivým kategoriím souborů/složek a dalším objektům a editovat je. |
SME02 | Datové typy metadat | Podporovaná metadata musí být různých datových typů: numerické, alfanumerické, logické, datum a čas, vazba na seznam povolených hodnot, vazba na jiný objekt (fórum, agenda, soubor/složku souborů, na uživatele (např. koordinátora urč. fóra)), vazba na jiná metadata, vazba typu soubor je přílohou, soubor má přílohu apod. Systém s nimi musí umět pracovat jako s příslušným datovým typem. |
SME02a | Složená metadata/atributy | Hodnoty některých metadat jsou definovány ve složených číselnících, tj. základní hodnota nabývá ještě dalších možných hodnot. Např. atribut typu agenda obsahuje metadata jako vazba na nadřízenou agendu, vazba na podřízenou agendu, název agendy, gestor agendy, spolugestor agendy, vazba na fórum, vazba na soubor apod. |
SME03 | Podpora kontroly vkládaných metadat | Systém kontroluje metadata při jejich vkládání uživatelem nebo při importu metadat: (1) kontrola formátu, (2) kontrola logického obsahu hodnot (např. nelze zadat do položky datum hodnotu 32.13.2010), (3) kontrola podle seznamu/číselníku hodnot, které udržuje administrátor DMS, (4) kontrola platnosti odkazu na související objekt v DMS (tj. kontrola zda objekt, na nějž je odkazováno, v DMS existuje). |
SME04 | Atributy časové platnosti souboru nebo informací obsažených v souboru | Systém musí umožnit v rámci metadat vložit také atribut časová platnost souboru nebo platnost informací obsažených v souboru, např. „Platnost od“/“Platnost do“/“Účinnost od“/"Účinnost do". Tyto atributy lze později doplnit či upravit. |
SME05 | Automatické přiřazení systémových auditních atributů | Systém automaticky přiřadí každému souboru a složce souborů, který je vkládán/upravován (obsah i metadata), systémové auditní atributy, např.: autor (tvůrce/původce), datum vytvoření, autor změny, datum poslední změny, velikost (pro dokumenty), formát, umístění. |
SME06 | Nastavení auditovatelnosti složek/souborů/ atributů | Systém musí oprávněnému uživateli umožnit definovat, zda složka souborů, formát/typ souboru nebo soubor, popř. i jeho jednotlivé jeho atributy jsou auditovatelné. V případě nastavení auditovatelnosti na složku souborů jsou automaticky auditovatelné všechny podřízené složky souborů a soubory v nich uložené. |
SME07 | Historie auditovaných atributů | Pokud je soubor nebo složka souborů označena jako auditovatelná, systém zaznamenává historii provedených změn auditovaných atributů. |
SME08 | Šablony metadat | Systém pro každou kategorii dokumentů umožňuje vytvořit specifickou šablonu/y pro soubory dané kategorie, které budou obsahovat předdefinovaná povinná i nepovinná metadata, včetně nastavení přednastavených (defaultních) hodnot a nastavení oprávnění k souboru/složce souborů dané kategorie. |
SME09 | Sdílení šablon metadat | Jednotlivé šablony metadat jsou s ohledem na příslušné oprávnění sdíleny napříč systémem bez nutnosti vytvářet kopie těchto šablon. |
SME10 | Správa šablon metadat a příslušných číselníků | Oprávněný uživatel má právo spravovat šablony metadat k příslušným kategoriím dokumentů na základě rozsahu svých oprávnění, a to včetně číselníků, tj. množin možných hodnot, a datových typů jednotlivých metadat. |
SME11 | Přidělení šablony metadat | Systém umožňuje šablony metadat přidělit souborům na základě: (1) explicitního určení uživatelem ke konkrétnímu souboru, (2) cílové složky, ve které je soubor umístěn, (3) na základě kategorie dokumentu (např. stanovisko, pokyny, rozhodnutí ve správním řízení) |
SME12 | Více šablon metadat k jedné složce | Systém umožňuje k jedné složce souborů přiřadit více šablon metadat pro soubory do ní vkládané, tj. šablona metadat není závislá na uložení souboru do složky. |
SME13 | Kategorie dokumentů | Systém umožňuje oprávněnému uživateli definovat různé kategorie dokumentů (např. stanovisko, pokyny, rozhodnutí ve správním řízení) společné pro celý systém a přiřadit jim příslušné šablony metadat. |
SME14 | Povinné atributy | Při tvorbě, vkládání nebo importu souboru/složky souborů určité kategorie doplní systém automaticky k souboru systémové atributy specifické pro danou kategorii dokumentu z příslušné šablony a vyzve koncového uživatele k vyplnění povinných metadat. Atributy se také přebírají na základě složky, do níž je soubor vkládán, ledaže oprávněný uživatel v konkrétním případě vybere jinou sadu metadat (viz požadavek SME12). |
SME15 | Jednoduché vytváření vazeb mezi objekty | Směrové vazby (speciální typ metadat) vytvořené mezi dvěma souvisejícími soubory/složkami souborů jsou tvořeny implicitně nebo explicitně. Tyto vazby lze metodicky pojmenovat, přičemž čtení vazby je závislé na orientaci vazby, např. 1. je přílohou, 2. má přílohu (vazby mohou být typu 1:n, popř. n:1). Správa speciálního typu metadat je společná pro všechny soubory v systému, tzn. administrátor spravuje všechny číselníky metadat (tj. včetně typů vazeb) a uživatel je následně používá. Při zobrazení vazeb dokumentu lze provádět navigaci (otevření) těchto souvisejících souborů. |
SME16 | Počet položek metadat | Systém podporuje prakticky neomezený počet (s přihlédnutím k limitům operačního systému a systému souborů) položek metadat povolených pro každou položku (např. dokument). |
SME17 | Oprávnění k metadatům | Systém umožňuje definovat, která metadata jsou zamčená a která jsou editovatelná oprávněným uživatelem. Oprávnění ke změně obsahu vybraných metadat souboru/složky nastavuje pouze oprávněný uživatel. |
SME18 | Zvýraznění ukončení platnosti souboru | Při zobrazení odkazu na soubor lze zjistit, zdali je platný či nikoli, např. podle příslušného atributu nebo uložení ve složce nebo podle stavu životního cyklu souboru. |
SME19 | Tisk informací/ metadat o souboru | Systém musí umožnit vytisknout informace (metadata) o určitém objektu (souboru či složce) v DMS. |
SME20 | Vytváření přehledu vybraných informací | Systém musí oprávněnému uživateli umožnit vygenerovat přehledné reporty o jednotlivých workflow v DMS s možností vybrat pouze určitá workflow podle metadat, která jsou vedena u souboru/ů, nad nímž/nimiž je/jsou WF spuštěna, příp. metadat vztahujících se k těmto workflow, např.: - hodnota atributu agenda - číslo jednací - název workflow - stav workflow (otevřené/uzavřené) - časový interval, kdy bylo workflow spuštěno/skončeno. Report spuštěný uživatelem u jím takto zvolených workflow by měl obsahovat následující informace/údaje z metadat: - název workflow - stav workflow (otevřené/uzavřené) - u otevřeného workflow i název kroku, ve kterém se workflow nachází - seznam připomínkujících, včetně data, kdy dokončili své úkoly pro vypracování připomínek - seznam schvalovatelů, včetně data, kdy dokončili své úkoly schvalování dokumentů a výsledek schvalování (např. Schváleno/Neschváleno nebo Ano/Ne). |
Notifikace (NOT) | ||
ID | Název | Popis požadavku |
NOT01 | Odesílání notifikací uživatelům v DMS | Systém obsahuje funkci automatického odeslání notifikace uživatelům formou e-mailové zprávy (formát Text či HTML) o: a) změně objektu, vlastností souboru/složky s přímým odkazem na daný objekt (URL), tj. např. vytvoření/změna obsahu souboru/složky, vložení/odstranění souboru do/ze složky, změna metadat, nová verze souboru, archivace apod. b) přiděleném kroku ve workflow, vč. např. blížícího se termínu pro splnění úkolu c) tom, zda v určité složce došlo za určité časové období ke změně. Systém dále podporuje automatické zaslání jedné notifikace: d) při vložení skupiny souborů - bude odeslána jen jedna emailová notifikace po vložení všech souborů- viz také požadavek SSS02 pro hromadné vkládání dokumentů e) o akcích (a-c) dle nastavení preference uživatele (viz požadavek NOT02) za určité časové období, které musí být nastavitelné oprávněným uživatelem (např. za období 1 hodiny, 1 dne apod.). |
NOT02 | Správa notifikací uživatelem | Systém umožňuje uživateli systému DMS, aby si nastavil osobní pravidla odběru jednotlivých notifikací včetně volitelného nastavení/filtru na notifikované operace (např. pouze smazání, ukončení platnosti souboru, vytvoření složky) nebo jejich kombinace. |
NOT03 | Konfigurace obsahu notifikace | Systém umožňuje oprávněnému uživateli modifikovat obsah (text) notifikačního e-mailu, včetně obsahu pole předmět emailu. |
NOT04 | Hromadné notifikace skupinám uživatelů | Oprávněnému uživateli musí systém umožnit konfigurovat nastavení hromadných notifikací více uživatelům současně, včetně nastavení pravidel pro tyto notifikace na základě definovaných podmínek nad metadaty, např. dle složky souborů, agendy či specifické hodnoty metadat (např. platnost dokumentu s parametrem T-N, kde N je počet dnů a T je daná datová hodnota, např. 14 dnů před vypršením platnosti). |
NOT05 | Nastavení odeslání jednorázové notifikace | Systém umožňuje uživateli odeslat o konkrétní provedené operaci (např. vytvoření jednání fóra, vložení souboru/souborů atd.) jednorázovou e-mailovou notifikaci jím individuálně určenému uživateli či skupině uživatelů. |
Správa verzí (SVE) | ||
ID | Název | Popis požadavku |
SVE01 | Verzování souborů | Systém musí umožnit verzování souborů, včetně jejich názorného označení. |
SVE02 | Vznik nové verze | Nová verze souboru vzniká vždy při vytvoření souboru v jednotném úložišti systému a explicitním určením uživatele. |
SVE03 | Označování verzí | Každá verze je opatřena pořadovým číslem a popisem verze. Informace o verzi a existujících verzích souboru je součástí metadat souboru. |
SVE04 | Prohlížení verzí | Oprávněný uživatel má právo prohlížet všechny verze dokumentu. |
SVE05 | Návrat k vybrané verzi | Systém musí umožnit oprávněnému uživateli vybrat z historie verzí takovou verzi, kterou označí za aktuální, tedy poslední platnou verzi. |
Vyhledávání (VYH) | ||
ID | Název | Popis požadavku |
VYH01 | Jednoduché fulltextové vyhledání | Systém musí umožnit při zadání řetězce znaků do jednoho pole provedení vyhledání fulltextově v celém úložišti kromě archivních složek. Vyhledávání rovněž nebude prováděno v souborech, které jsou uloženy v zašifrované formě. Zobrazení výsledků vyhledávání je vždy závislé na přístupových oprávněních (viz požadavek BEZ08 a BEZ09). |
VYH02 | Pokročilé fulltextové vyhledávání | Systém musí umožnit vyhledávat fulltextově pro jeden až N výrazů v celém úložišti nebo ve vybrané části úložiště DMS. Zadání více výrazů může být zadáno pomocí jednoho vstupního řetězce. Pro chápání několika slov jako jednoho výrazu je možné tento text uzavřít mezi definované oddělovače. Vyhledávání nebude primárně prováděno v archivních složkách, pouze při explicitním zadání uživatelem. Vyhledávání nebude prováděno v souborech, které jsou uloženy v zašifrované formě. |
VYH03 | Vyhledávání dle kritérií | Systém obsahuje vyhledávání podle kritérií, která jsou sestavována koncovým uživatelem jako kombinace všech přiřazených metadat k souboru a/nebo obsahu souboru (včetně kategorie dokumentu) v celém úložišti nebo ve vybrané části úložiště DMS. Vyhledávání nebude primárně prováděno v archivních složkách, pouze při explicitním zadání. Vyhledávání podle obsahu nebude prováděno v souborech, které jsou uloženy v zašifrované formě. |
VYH04 | Vyhledání dle přiřazení metadat | Systém umožňuje vytvořit kritérium, podle kterého lze vyhledat všechny dokumenty obsahující stejný atribut, ale ne podle jeho hodnoty. Tím lze vyhledat všechny soubory/složky souborů, které nemají některý atribut vyplněný. Vyhledávání nebude primárně prováděno v archivních složkách, pouze při explicitním zadání. |
VYH05 | Operátory a tvorba kritérií | Uživatel musí mít možnost definovat vyhledání s více kritérii, kde vyhledávací kritéria mají různé operátory (např. =, <, >, etc.) vztažené k datovému typu vyhledávacího pole/metadata. Systém umožňuje při vyhledávání definovat vztahy také mezi jednotlivými kritérii za použití logických operátorů (např. AND, OR, NOT). Systém tak bude například umožňovat pro textové vyhledávací pole zadat operátory: obsahuje; začíná atd. a pro datumové položky: konkrétní datum, rozmezí mezi dvěma daty, minulý týden, letos, apod. Vyhledávání nebude primárně prováděno v archivních složkách, pouze při explicitním zadání. Vyhledávání nebude prováděno v obsahu souborů, které jsou uloženy v zašifrované formě. |
VYH06 | Zpřesnění vyhledávání | Systém umožňuje uživateli po použitém vyhledávání dodatečně zpřesnit výběrová kritéria a opakovat dotaz, příp. vyhledávat již v množině výsledků předchozího dotazu. |
VYH07 | Kombinované vyhledávání | Systém umožní kombinovat podle potřeb uživatele fulltextové vyhledávání s vyhledáváním podle kritérií/metadat. |
VYH08 | Vyhledávání v konkrétních složkách | Systém umožní uživateli omezit prohledávaný prostor na definované složky (včetně omezení na složky archivu DMS) nebo virtuální adresáře (resp. uložené dotazy) a následně spustit fulltextové vyhledání nebo vyhledání dle kritérií (viz VYH03 až VYH05). |
VYH09 | Prohledávané formáty souborů | Systém musí umožnit fulltextově vyhledávat alespoň v následujících formátech souborů: PDF, PDF-A/1, formátech používaných aplikacemi MS Office (např. Word, Excel, Powerpoint), rtf/txt, HTML, HTM. |
VYH10 | Podpora české gramatiky při vyhledávání | Systém umožňuje vyhledat skloňovaná/ohýbaná slova v českém jazyce a s českou diakritikou. |
VYH11 | Necitlivost na velká a malá písmena | Systém musí umožnit nastavit a provést vyhledávání bez ohledu na rozlišení velkých a malých písmen. |
VYH13 | Citlivost na velká a malá písmena | Systém musí umožnit nastavit a provést vyhledávání včetně rozlišení velkých a malých písmen. |
VYH14 | Synonyma, zkratky | Systém umožňuje spravovat synonyma a zkratky a také podle nich vyhledávat např.: „pok.“ znamená pokyn, „č.“ číslo, “Org. řád“ Organizační řád apod. |
VYH15 | Použití zástupných znaků při vyhledávání ne zcela známých řetězců | Systém musí umožnit vyhledávání pomocí zástupných znaků (např. % nebo *), a to jak v obsahu souboru (kromě šifrovaných souborů), tak i metadatech.. |
VYH16 | Uložení uživatelského dotazu | Systém umožňuje uložit uživatelský dotaz, sestavený z vyhledávacích podmínek, do struktury složek jako speciální soubor, který vždy po otevření zobrazí výsledek dle obsaženého definovaného vyhledávání. |
VYH17 | Odkazování na uživatelský dotaz | Uživatel si může vytvořit a uložit vlastní uživatelský dotaz. Na takto uložený uživatelský dotaz se lze odkazovat např. pomocí interního nebo externího odkazu. |
VYH18 | Sdílení uložených uživatelských dotazů | Systém umožňuje sdílet uložené uživatelské dotazy mezi uživateli systému na základě rozhodnutí uživatele, který dotaz uložil. |
VYH19 | Zpracování výsledků po vyhledávání | Systém umožňuje zobrazit uživateli všechny úspěšné výsledky vyhovující zadaným vyhledávacím kritériím s možností přímého provedení jednotlivých a hromadných operací nad vyhledanými dokumenty (např.: otevření, smazání, kopírování apod.). |
VYH20 | Náhled obsahu vyhledaného souboru | Systém umožňuje prohlédnout náhled na obsah vyhledaného souboru (např. v novém malém okně - preferovaně v HTML) před plným otevřením tohoto souboru v novém okně. |
VYH21 | Zvýraznění vyhledávaných slov v náhledu souboru | Systém umožňuje zvýraznění (podbarvení, podtržení apod.) vyhledávaných slov v náhledu cílového souboru (tj. zobrazení celého cílového souboru v zjednodušeném formátovaní v plain textu nebo preferovaně v HTML) pro všechny formáty fulltextově prohledávaných souborů. |
VYH22 | Zpřístupnění souboru/ složky po vyhledávání v novém okně nebo záložce | Systém musí umožnit, aby soubory a další objekty uvedené v seznamu výsledků vyhledávání mohly být následně zvoleny a otevřeny v novém okně nebo nové záložce (po kontrole přístupových práv) jediným kliknutím nebo stisknutím klávesy. |
VYH23 | Definice zobrazení výsledků po vyhledávání | Systém umožňuje uživateli upravit zobrazení výsledků vyhledávání následujícím způsobem: (1) vybrat řazení sloupců, ve kterém budou výsledky vyhledání zobrazovány, (2) stanovit počet výsledků zobrazených na obrazovce monitoru (stránkování), (3) stanovit maximální počet výsledků, (4) zvolit, která pole metadat se zobrazí v seznamu výsledků vyhledávání, (5) provést navigaci (přechod) do složky daného souboru, (6) provést otevření nalezeného souboru, (7) uložit vyhledávací dotaz. |
VYH24 | Tisk výsledků vyhledávání | Systém umožnuje uživateli vytisknout seznam výsledků z provedeného vyhledávání. |
VYH25 | Export výsledků vyhledávání | Systém umožnuje uživateli vyexportovat seznam výsledků hledání do nejméně těchto formátů souborů: csv, rtf nebo xls. |
Pracovní procesy s dokumenty (PPD) | ||
ID | Název | Popis požadavku |
PPD01 | Připomínkové řízení | Systém musí umožnit nastavení procesů pro připomínkování souborů jak paralelní, tak sekvenční, včetně určení povinných připomínkových míst (viz popis procesu v příloze č.1a Věcné zadání – kapitola 9 Popis vzorového procesu ČNB, která je nedílnou součástí smlouvy ). Paralelním připomínkováním dokumentu/ů se přitom rozumí možnost více uživatelů připomínkovat ve stejném čase jeden nebo více dokumentů. Nad jedním souborem je možné spustit více samostatných workflow ve stejném čase. |
PPD02 | Schvalovací řízení | Systém musí umožnit nastavení procesu pro schvalování souborů (sekvenční), včetně určení povinných schvalovacích míst (viz popis procesu v příloze č.1a Věcné zadání – kapitola 9 Popis vzorového procesu ČNB, která je nedílnou součástí smlouvy). Schvalování musí být možné provádět i hromadně (ve více souběžných workflow), tj. systém podporuje možnost označení více běžících procesů, které má v určitém okamžiku jeden uživatel ke schválení, a jejich hromadné schválení či zamítnutí. |
PPD03 | Týmová práce a co- authoring | Systém DMS umožňuje více uživatelům společnou práci v jednom časovém okamžiku nad jedním a tímže souborem, tzv. co-authoring. Jednotliví editující uživatelé tak v reálném čase mohou vidět změny prováděné ostatními editujícími uživateli. Výsledkem společné práce více uživatelů nad jedním souborem musí být automatizovaně zkompilovaná verze souboru, která zachycuje všechny změny všech uživatelů a která umožní oprávněnému uživateli (pověřenému v konkrétním případě vytvořením konsolidované verze) přijmout či odmítnout změny navržené uživateli-připomínkovými místy. |
PPD04 | Poslat odkaz namísto dokumentu | Systém musí umožnit zaslat v notifikaci/emailu externí odkaz (URL) na soubor do úložiště systému. Tato činnost je vyvolána z kontextového menu příslušného souboru. |
PPD05 | Automatické přiřazení oprávnění | V případě odeslání odkazu na soubor z jednotného úložiště (v rámci plnění úkolů ve workfklow) dostanou oslovené osoby nebo skupiny automaticky přístupová práva na čtení, (dynamické přidělování oprávnění k příslušnému souboru/složce). |
PPD05a | Automatické přiřazení oprávnění na související dokumenty | V případě odeslání odkazu na soubor z jednotného úložiště dostanou oslovené osoby nebo skupiny automaticky přístupová práva také na čtení příloh či souvisejících souborů dle metadat k souboru, na nějž bylo odkazováno v rámci plnění úkolů ve workfklow (dynamické přidělování oprávnění k příslušnému souboru/složce). |
PPD06 | Podpora vypořádání připomínek k dokumentům | Systém musí umožnit zpracování připomínek k souboru zaslanému do připomínkového řízení. Připomínky k souboru je v rámci DMS možné vytvořit: (1) do zvláštního souboru propojeného s připomínkovaným souborem (šablona „připomínkový list“), (2) přímo do připomínkovaného souboru (při zachování jeho originálu jako jiné verze), a to formou komentářů či revizí do textu v režimu změn, v závislosti na typu souboru, a to v souladu s požadavkem PPD03. |
PPD07 | Workflow | Systém musí umožnit nastavit kompletní workflow v rozsahu a komplexnosti odpovídající popisu vzorového procesu uvedeného v příloze č.1a Věcné zadání – kapitola 9 Popis vzorového procesu ČNB, která je nedílnou součástí smlouvy. |
PPD08 | Sestavování workflow | Systém musí umožnit sestavovat workflow modulárně z jednotlivých akcí tak, že se uživatel může operativně rozhodovat o dalším postupu ve workflow a volí další akci podle potřeby a kategorie dokumentu. (tj. uživatel není limitován na konečný počet předdefinovaných workflow, nýbrž operativně vytváří individuální a individualizovaná ad hoc workflow dle potřeb konkrétního připomínkového řízení či úkolu). |
PPD09 | Automatické ukončení úkolu | Systém musí umožnit nastavit automatickou reakci (ukončení úkolu) v případě uplynutí lhůty pro reakci. V závislosti na konkrétní situaci (workflow) to je buď automatické vrácení zpět zadavateli úkolu s upozorněním, že na výzvu, úkol či žádost nebylo nijak reagováno (např. že nebylo potvrzeno přijetí úkolu), nebo postoupení dále bez reakce jako tacitní souhlas-tichá procedura (tj. schválení souboru nebo automatického označení, že je ze strany uživatele-připomínkového místa příslušný dokument, který je předmětem úkolu, bez připomínek). |
PPD10 | Nastavení zastoupení uživatele po dobu jeho nepřítomnosti | Systém musí umožnit uživateli nastavit po dobu jeho nepřítomnosti svého zástupce. Úkoly ve workflow budou v této době přesměrovány na náhradního uživatele v roli schvalovatele/připomínkujícího. |
PPD11 | Automatické přesměrování po dobu nepřítomnosti uživatele | Systém musí na základě informací o nepřítomnosti uživatele (ze systému HRIS – viz příloha č. 2a Technické zadání - kapitola 3.8. Integrace s IS HRIS, která je nedílnou součástí smlouvy) přesměrovávat úkoly ve workflow na náhradního uživatele v roli schvalovatele /připomínkujícího. |
Export souborů a složek (ESS) | ||
ID | Název | Popis požadavku |
ESS01 | Povolené formáty pro export | Systém umožňuje provést export souboru ve formátu používaném ve standardně dostupných aplikacích, a to nejméně ve formátech aplikací: (1) MS Office 2010 a vyšší, (2) Adobe Acrobat, (3) komprimované soubory typu zip, rar apod. (4) obrazové formáty: jpg, tiff, bmp, png, gif apod. |
ESS02 | Automatický export | Systém musí umožnit jednotlivým správcům nastavit čas, ve kterém se budou exporty jednotlivých souborů/složek opakovat a výsledné úložiště, kam budou exportované soubory/složky ukládány. |
ESS03 | Opakovatelnost exportů | Systém musí umožnit, aby soubory byly převedeny nebo exportovány více než jednou. |
ESS04 | Zachování integrity při exportu složky/souboru | Systém musí umožnit export souboru nebo složky v jedné posloupnosti operací tak, aby se: (1) všechny soubory a složky exportovaly jako integrální jednotka, (2) zachovaly všechny vazby mezi soubory a jeho metadaty, (3) zachovaly všechny vazby mezi soubory a složkami. |
ESS05 | Export /přesun jednotlivých verzí | Systém umožňuje přesouvat jednotlivé verze souborů včetně metadat za účelem archivace do Archivu DMS. |
ESS06 | Kritéria exportu | Systém musí umožnit na základě definovaných kritérií (oprávnění, obsah souboru, metadata) exportovat soubory a složky. |
Uživatelské prostředí (UPR) | ||
ID | Název | Popis požadavku |
UPR01 | Uživatelské nastavení vstupní obrazovky systému - pracovní plocha uživatele | Systém obsahuje přehledné, srozumitelné, ergonomické a uživatelsky přívětivé grafické rozhraní, které slouží mj. pro práci se soubory a složkami, přehledu a administraci workflow procesů a plnění úkolů, vyhledávání a navigaci a obsahuje pracovní plochu uživatele včetně úvodní obrazovky. Systém musí umožnit nastavení úvodní obrazovky uživatele při přihlášení do systému tak, aby vstoupil do prostředí jím spravovaných složek/souborů (pracovní plocha uživatele). Základní vstupní obrazovka bude pro všechny uživatele shodná a bude obsahovat minimálně: (1) seznam aktuálních úkolů daného uživatele k vyřízení, (2) seznam posledních dokumentů vložených či změněných v DMS systému ve sledovaných oblastech, (3) rychlý vstup do vyhledávání, (4) oblíbené složky struktury úložiště daného uživatele, (5) kalendář nadcházejících jednání sledovaných fór, úkolů apod. Další obrazovky bude možné přizpůsobit dle preferencí uživatele (nejčastěji používaných funkcí, přistupovaných složek apod.) Systém musí být možno upravit tak, aby jeho grafické uživatelské rozhraní odpovídalo potřebám ČNB (nastavení úvodní obrazovky, volba a rozmístění nejvíce používaných tlačítek a funkčních prvků, zobrazení posledních přidaných dokumentů ve sledovaných agendách, zobrazení aktuálních či nesplněných úkolů, dokumentů čekajících na schválení apod.). Naopak méně používané funkcionality a tlačítka by mělo být možné skrýt, aby zbytečně neznepřehledňovaly pracovní prostředí běžného uživatele. Důraz musí být kladen na to, aby požadovaná operace byla proveditelná na co nejmenší počet dílčích úkonů pracovníka. |
UPR02 | Rychlý přístup na často používané složky (oblíbené) | Systém musí umožnit nastavení rychlého přístupu do často užívané složky bez nutnosti proklikávání složité struktury aplikace a umožnění přístupu dalším uživatelům. |
UPR03 | Možnost tvorby zástupců souborů/složek souborů | Systém musí umožnit vytvářet zástupce souborů/složek. |
UPR04 | "Drobečková" navigace | Systém umožňuje zobrazovat necyklickou drobečkovou navigaci generovanou na základě hierarchie struktury v úložišti dokumentů. |
UPR05 | Zobrazení nově přidaných dokumentů | Systém podporuje zobrazení nejnověji přidaných dokumentů (latest documents) relevantních pro uživatele (tj. např. dokumentů ve složkách označených uživatelem k zasílání notifikací – viz NOT01) |
UPR06 | On-line nápověda | Systém musí zajistit on-line nápovědu použití systému. Tato on-line pomoc v systému musí být konstruována kontextuálně a být v českém jazyce. |
UPR07 | Kvalita chybových hlášení | Chybová hlášení systému při neoprávněném kroku, nedodržení formátů atributů, apod. musí být smysluplná a srozumitelná koncovým uživatelům, (uváděná v českém nebo anglickém jazyce). |
UPR08 | Lokalizace | Aplikace musí být lokalizována do českého prostředí. |
UPR09 | Uživatelská nápověda a dokumentace | K systému musí existovat kompletní elektronická uživatelská příručka (nápověda v rámci systému/ dokumentace) popisující způsob použití aplikace v českém jazyce. |
UPR10 | Nápověda vstupních polí | Systém zprostředkovává nápovědu k jednotlivým vstupním polím ve formě hintů (tool tipů), které se zobrazí po najetí kurzoru na dané pole. |
UPR11 | Povinná pole | Pokud budou ve formulářích nějaká povinná pole (bez ohledu na to, zda se jedná o zadávací pole, rozbalovací seznam či jiný prvek), bude tato skutečnost uživateli jasně prezentována. |
UPR12 | Kalendář | Systém DMS obsahuje kalendář, který s využitím údajů vkládaných uživateli jako metadata u jednotlivých jednání jednotlivých fór automaticky uživateli zobrazuje nadcházející i uplynulá jednání uživatelem sledovaných fór (nastavitelné dle konkrétních fór či fór spjatých s konkrétní agendou, viz též požadavek UPR14), ve formátu název fóra a datum a čas jednání. Kliknutím na příslušné jednání fóra v kalendáři, které slouží jako odkaz, bude uživatel přesměrován na odpovídající složku daného jednání daného fóra, kde budou přístupná související metadata a soubory (v závislosti na přístupových oprávněních uživatele). |
UPR13 | Kalendář (vícedenní jednání) | Systémový kalendář podporuje i záznam a zobrazení vícedenního jednání téhož fóra s rozdílnými časy začátku a konce jednání v jednotlivých dnech. |
UPR14 | Uživatelská správa nastavení sledovaných fór a agend | Systém DMS umožňuje uživateli, aby si v rámci uživatelských nastavení systému nastavil: (1) fóra (2) agendy, které chce sledovat. Na základě tohoto nastavení se mu budou zobrazovat poslední dokumenty vložené či změněné v DMS v příslušných složkách (viz též požadavek UPR01) a budou se mu zobrazovat v kalendáři nadcházející i uplynulá jednání jednotlivých fór (viz též požadavek UPR12). Dále mu sí být uživateli umožněno spravovat nastavení (3) emailových notifikací (viz též požadavek NOT02). |
*popis kompletnosti splnění funkčního požadavku v nabízeném řešení DMS: Kompletně vyřešeno
Částečně vyřešeno (to znamená, že dodavatel dovyvine v rámci dodávky funkcionalitu tak, aby byl požadavek kompletně vyřešen) Musí být kompletně nově vyvinuto
** vítané požadavky se v případě volby Ano stanou pro dodavatele závaznými
Příloha č.1b smlouvy
Důležitost | Nabízený systém požadavek splňuje (výběr z hodnot)* | Požadavek bude realizován? (jen pro vítané)** |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Důležitost | Nabízený systém požadavek splňuje (Ano/Ne) | Požadavek bude realizován? (jen pro vítané) |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Musí být nově vyvinuto |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Důležitost | Nabízený systém požadavek splňuje (Ano/Ne) | Požadavek bude realizován? (jen pro vítané) |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Musí být nově vyvinuto | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Důležitost | Nabízený systém požadavek splňuje (Ano/Ne) | Požadavek bude realizován? (jen pro vítané) |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Důležitost | Nabízený systém požadavek splňuje (Ano/Ne) | Požadavek bude realizován? (jen pro vítané) |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Vítaný | Částečně vyřešeno v nabízeném SW řešení DMS | Ano |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Vítaný | Kompletně vyřešeno v nabízeném SW řešení DMS | Ano |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Vítaný | Kompletně vyřešeno v nabízeném SW řešení DMS | Ano |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Vítaný | Musí být nově vyvinuto | Ne |
Vítaný | Kompletně vyřešeno v nabízeném SW řešení DMS | Ano |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Vítaný | Musí být nově vyvinuto | Ne |
Vítaný | Kompletně vyřešeno v nabízeném SW řešení DMS | Ano |
Vítaný | Částečně vyřešeno v nabízeném SW řešení DMS | Ano |
Vítaný | Musí být nově vyvinuto | Ano |
Vítaný | Kompletně vyřešeno v nabízeném SW řešení DMS | Ano |
Vítaný | Kompletně vyřešeno v nabízeném SW řešení DMS | Ano |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Vítaný | Částečně vyřešeno v nabízeném SW řešení DMS | Ano |
Vítaný | Musí být nově vyvinuto | Ano |
Vítaný | Musí být nově vyvinuto | Ano |
Důležitost | Nabízený systém požadavek splňuje (Ano/Ne) | Požadavek bude realizován? (jen pro vítané) |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Vítaný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Vítaný | Musí být nově vyvinuto | Ano |
Důležitost | Nabízený systém požadavek splňuje (Ano/Ne) | Požadavek bude realizován? (jen pro vítané) |
Závazný | Musí být nově vyvinuto | |
Závazný | Musí být nově vyvinuto | |
Závazný | Musí být nově vyvinuto | |
Závazný | Musí být nově vyvinuto | |
Vítaný | Částečně vyřešeno v nabízeném SW řešení DMS | Ano |
Závazný | Musí být nově vyvinuto | |
Důležitost | Nabízený systém požadavek splňuje (Ano/Ne) | Požadavek bude realizován? (jen pro vítané) |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Vítaný | Musí být nově vyvinuto | Ano |
Vítaný | Kompletně vyřešeno v nabízeném SW řešení DMS | Ano |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Vítaný | Kompletně vyřešeno v nabízeném SW řešení DMS | Ano |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS | |
Závazný | Částečně vyřešeno v nabízeném SW řešení DMS | |
Vítaný | Musí být nově vyvinuto | Ano |
Závazný | Kompletně vyřešeno v nabízeném SW řešení DMS |
Kompletně vyřešeno v nabízeném SW řešení DMS | Ano |
Částečně vyřešeno v nabízeném SW řešení DMS | Ne |
Musí být nově vyvinuto |
TECHNICKÉ ZADÁNÍ
3. Vazby na interní/externí IS
DMS musí být realizován jako webová aplikace přístupná minimálně z prostředí
Microsoft Internet Explorer 11.
1 Systémové prostředí ČNB
SW řešení DMS musí akceptovat standardní systémové prostředí ČNB a musí být snadno do tohoto prostředí implementovatelné.
1.1. Prostředí datové sítě
• Klientské stanice připojeny rychlostí 1000 Mbps
• Servery připojeny typicky rychlostí 1 až 10 Gb
• Adresace dle RFC 1918 (10.x.y.z, 172.16-31.x.y, 192.168.x.y)
1.2. Serverová část
Serverové prostředí (databázový či aplikační server):
• Platforma architektury x86 - MS Windows Server 2008R2 Server, cp 1250
• Platforma Red Hat Linux ver. 6 nebo 7
• Platforma VMware vSphere ver 5 a vyšší
• Platforma Oracle VM 3.4 a vyšší
1.3. Databázové servery
Data standardních IS jsou uložena v databázích Oracle:
• Oracle RDBMS 12c EE provozovaný na dvou Oracle Exadata Quatter Rack X6-2, v primární a záložní budově, každý vybavený licencemi pro 40 jader (Intel Core), 1,5 TB RAM, 85 TB HDD, technologií RAC, Partitioning, Diagnostic a Tunning Pack.
• Protokol Oracle SQL Net
Databázová platforma ČNB je postavena na databázi ORACLE, pro jejíž správu má ČNB vyškolené specialisty a je možné využít Oracle nadstavbu Oracle Business Intelligence 12c Enterprise Edition pro tvorbu sestav.
V případě, že řešení bude využívat jinou databázi, poskytne objednatel pro DB prostředí následující konfiguraci virtuálních serverů na platformě VMware:
A) Primární DB server
a. 2 až 4 VCPU (virtuálních CPU)
b. 8 až 16 GB RAM
c. vzdálené úložiště prostřednictvím sítě SAN – 500 GB
d. konektivita min. 1 Gbps
e. operační systém RedHat nebo Windows Server (viz. odst. 1.2)
B) Záložní DB server
a. stejná konfigurace
b. data se synchronizují na úrovni diskového pole
Poskytovatel je povinen zahrnout do nabídky veškeré náklady na pořízení a provoz SW licencí.
1.4. Aplikační a WWW servery
• Oracle Web Logic Server 12c,
• Microsoft IIS v roli MS Server 2008R2
Objednatel poskytne následující konfiguraci pro provoz virtuálních aplikačních a WWW serverů na platformě Oracle VM (v případě Oracle Web Logic) nebo VMware:
A) Primární aplikační server
• 2 VCPU (virtuálních CPU)
• 8 GB RAM
• vzdálené úložiště prostřednictvím sítě SAN – 250 GB
• konektivita min. 1 Gbps
• operační systém RedHat nebo Windows Server (viz. odst. 1.2)
B) Záložní aplikační server
• stejná konfigurace
• data se synchronizují na úrovni diskového pole
C) Primární WWW server
• 2 VCPU (virtuálních CPU)
• 8 GB RAM
• vzdálené úložiště prostřednictvím sítě SAN – 100 GB
• konektivita min. 1 Gbps
• operační systém RedHat nebo Windows Server (viz. odst. 1.2)
D) Záložní WWW server
• stejná konfigurace
• data se synchronizují na úrovni diskového pole
Účastník je povinen zahrnout do nabídky veškeré náklady na pořízení a provoz SW licencí.
1.5.Monitoring systémů
• System Center Operations Manager 2012 R2 – centrální sběr logů
• QUALYS Guard – monitoring zranitelností
• SIEM HP ArcSight– sběr bezpečnostních logů
• Oracle Enterprise Manager (sledování provozu databázového prostředí a aplikačních serverů)
• Oracle Diagnostic Pack, Tunning Pack, Partitioning
Z důvodu koncepční konsolidace datové základny v prostředí DB Oracle preferujeme řešení realizované nad touto platformou. Potřebné licence Oracle RDBMS 12c EE zajistí objednatel. Pro tuto platformu jsou zajištěny návazné procesy zálohování dat a replikace do záložního střediska, monitoring zranitelností a pravidelné aktualizace SW.
Pokud je SW řešení DMS dodáno s využitím výše uvedených platforem, může dle možností zajistit licence ČNB. Je-li dodáno SW řešení s využitím jiných platforem, je poskytovatel zavázán dodat i potřebné licence. V každém případě cena SW řešení obsahuje všechny potřebné licence k provozu SW řešení.
Podle technologické platformy SW řešení DMS bude implementace do systémového prostředí objednatele a následný provoz probíhat za podmínek uvedených ve variantě 2 v příloze č.12 smlouvy.
1.6.Klientské stanice
Osobní počítače typu IBM-PC kompatibilní (x86) nebo virtuální desktop
OS:
• MS Windows 7 Professional 64bitCZ, cp 1250, Service Pack 1 (8GB RAM). Nutno
počítat i s budoucím upgradem na MS Windows 10.
• Notebooky s MS Windows 10 Pro 64bit CZ
• Citrix XenApp 6.5 na MS Windows 2008 Server R2 (virtuální desktop využívající MS terminálové služby).
Další SW na klientské části je:
• TCP/IP síťové služby (DHCP klient, SNMP klient),
• MS Office 2010 Professional Plus CZ + SP 2, nutno počítat i budoucím upgradem na
MS Office 2016.
• MS Internet Explorer 11 CZ (aktuální SP),
• Adobe Acrobat Reader 10 CZ nebo vyšší.
• Symantec EndPoint Protection v aktuální verzi.
Instalace další provozní platformy na klientskou stanici není preferována.
Instalace programového vybavení na klientskou stanici je prováděna především prostřednictvím vzdálené automatické instalace. Instalace musí být kompatibilní se službou MS Installer (standardní služba operačního systému). Instalace programového vybavení na vDesktop je prováděna centrálně pomocí tzv. image z provisioning serverů.
Není přípustné ukládat na klientskou stanici/vDesktop data trvalé hodnoty, taková data je nutno ukládat na centrální diskové kapacity. Na klientské stanici nesmí být prováděno dávkové zpracování dat IS.
Dávkové zpracování centrálně uložených dat je přípustné spouštět a provádět pouze na databázovém serveru nebo případně na aplikačním serveru.
Uživatel nebo aplikace mohou ukládat na klientskou stanici dočasná data a programové komponenty, které jsou odvozeny z centrálně uložených dat, mohou také provádět lokální zpracování dat. Pro případné vytváření dočasných souborů a ukládání dat při činnosti komponent je třeba využívat předdefinované adresáře dostupné přes proměnné prostředí (USERPROFILE, TEMP, TMP, APPDATA). V případě vDesktop jsou data na lokálním disku po restartu serveru smazána.
Přístupová práva na klientských stanicích a vDesktop odpovídají defaultnímu nastavení od firmy Microsoft po instalaci MS Windows 7 Professional (v případě vDesktop se jedná o MS Windows 2008R2). Výjimky pro potřeby aplikací je v nezbytných případech možné povolit po přesném definování potřebných změn v adresářích a v registrech a po náležitém zdůvodnění požadovaných změn. Výjimky jsou centrálně řízeny a aplikovány na klientské stanice a vDesktop prostřednictvím GPO (politiky v Active Directory). Obdobné požadavky platí i pro registrování knihoven a vytváření nebo změny hodnot klíčů v registrech.
Na klientské stanici a vDesktop pracuje uživatel standardně pod právy přidělené skupině
„Users“.
Při realizaci SW řešení DMS je nutné zajistit, aby programové komponenty realizovaného IS nebyly v rozporu s komponentami dalších provozovaných IS. Realizovaný IS tedy musí být provozovatelný v systémovém prostředí ČNB a současně nesmí narušovat funkčnost ostatních IS.
1.7.Systémové služby
1.7.1. Single Sign-On
U informačních systémů ČNB je realizována funkce Single Sign-On s využitím služby Microsoft Active Directory (autentizační protokol Kerberos) a OID Oracle Internet Directory. Uživatel se autentizuje pouze jednou do domény CNB (typicky s využitím certifikátu na čipové kartě), při vyvolání libovolné aplikace již pak není zadávání jména/hesla nutné, ani žádná další autentizace uživatele není požadována.
Další podmínky jsou uvedeny v kapitole 2 Bezpečnost IT.
1.7.2. Zálohování IS a dat
Zálohování SW řešení DMS a jeho dat je v ČNB řešeno centrálně, pokud bude databáze DMS typu Oracle. Zálohována jsou pouze data uložená na centrálních kapacitách ve správě sekce informatiky. Zálohování databázového prostředí probíhá pomocí nástroje Oracle RMAN. Pro zálohování je určen zálohovací systém HP Data Protector 9.07.
SW řešení DMS bude instalováno a provozováno v prostředí Microsoft Cluster Server (Windows 2008). Mimo jiné musí být schopno automatického zotavení po havárii serveru a zároveň po zotavení musí mít zajištěnu konzistenci dat. Instalaci do prostředí Microsoft Cluster Server zajišťuje poskytovatel.
Integraci do prostředí geografického clusteru (tj. start DMS na druhém node clusteru v jiné lokalitě) zajišťuje objednatel.
Pokud využívá SW řešení DMS jiný typ databáze, pak poskytovatel musí dodat současně s dodávkou systému DMS skripty (sadu příkazů), které uvedou DMS (jeho data) do konzistentního stavu vhodného k zálohování a ČNB zajistí zálohu určených souborů.
Poskytovatel dodá skript, který na konci zálohy opět vrátí IS do provozního stavu a stejně tak umožní jeho obnovu z těchto záloh v případě havárie.
1.7.3. SIEM (Sběr bezpečnostních logů)
Sběr a vyhodnocování bezpečnostních logů je v ČNB řešen centrálně systémem SIEM
ArcSight od firmy HP.
SW řešení DMS musí podporovat některý z následujících způsobů logování a sběru logů:
• zaznamenávat logy ve strojově čitelné a zpracovatelné podobě, tzn. logy musí mít jednotnou strukturu, do souboru v operačním systému a tento v realtime sdílet pro systém SIEM. Soubor může rotovat, ale musí být zachováno jeho jméno
• zaznamenávat logy ve strojově čitelné podobě do DB a umožnit realtime přístup systému SIEM k daným tabulkám,
• odesílat logy ve strojově čitelné podobě na vzdálený server např. syslogem.
1.7.4. Pro správnou interpretaci a syntaktickou analýzu (parsing) je nutný popis
struktury logu. Elektronická pošta
• Server elektronické pošty - MS Exchange 2010
• Klient elektronické pošty - MS Outlook 2010
1.7.5. Tisková zařízení
• Síťová tisková zařízení,
• Komunikační protokol – TCP/IP,
• Podporované síťové služby – SNMP, DHCP, DNS.
1.7.6. Centrální diskové kapacity
K dispozici jsou „fault“ tolerantní disková pole pro ukládání dat spravovaných databázovými systémy, pro sdílení programového vybavení a dat organizačních útvarů ČNB. Zálohování dat centrálních diskových kapacit je zajištěno.
1.7.7. Internet (DMZ)
• E-mail je povolen všem uživatelům prostřednictvím poštovny Exchange a MTA serverů. Maximální velikost zprávy je však omezena na 30 MB a může být zablokována antivirovým systémem.
• Neaktivní spojení jsou po jedné hodině přerušena.
• Služby provozované v rámci aplikací nebo IS jsou registrovány a povolovány zvlášť v souladu se systémovou bezpečnostní politikou DMZ na základě schválené žádosti.
• Přístup z Internetu je omezen pouze na dedikované servery v určené části DMZ.
1.7.8. Synchronizace času
Čas na všech komponentách sítě ČNB mimo stanic uživatelů je synchronizován se zdrojem přesného času (pro zajištění správného vyhodnocení auditních záznamů) protokolem NTP.
1.8.Řízení přístupu k IT
Ke všem funkcím, programovému vybavení či službám systémového prostředí, a obvykle i DB rolím, je řízen přístup prostřednictvím interně vyvinuté aplikace „ŘDB – Řídicí databáze“ (aplikace nad DB Oracle), která uchovává seznam uživatelů a jejich skupin. Tyto informace jsou pak propagovány např. do Microsoft Active Directory nebo zpřístupněny přes LDAP z Active Directory či z tabulek aplikace ŘDB prostřednictvím views do jiných systémů a aplikací dle jejich potřeb. Ke každému aktivu (aplikace, zdroj, funkce, privilegium atd.) je vytvořena tzv. aplikační skupina, do které jsou pak zařazovány uživatelské účty či účty klientských stanic a tím jsou jim dané komponenty, služby či funkce systémového prostředí ČNB, zpřístupněny.
2 Bezpečnost IT
V souladu s bezpečnostní politikou České národní banky v oblasti informačních technologií je informační systém DMS zabezpečen proti hrozbám ohrožujícím jeho dostupnost, důvěrnost, integritu a auditovatelnost.
2.1 Zajištění bezpečnosti v ČNB:
Dostupnost | Dostupnost je zajišťována také prostřednictvím 2 geograficky vzdálených středisek v lokalitě Praha v režimu „split-site“. |
Důvěrnost | Řízený přístup (práva přístupu dle rolí). |
Integrita | Použití https protokolu a databázové transakce |
Autentizace | Primárně užitím čipové karty, pouze ve výjimečných a řádně zdůvodněných případech jménem a heslem OS Windows (SSO ve spolupráci s Active Directory). |
Prokazatelnost | Záznam v auditním logu. |
Servery a na nich instalované SW produkty jsou pravidelně monitorovány a skenovány produktem QUALYS (xxxx://xxx.xxxxxx.xxx/). Pokud jsou nalezeny zranitelnosti u instalovaných produktů hodnoty 4 a vyšší (hodnoty výstupu ze systému Qualys), jsou neprodleně odstraněny a to formou aplikací patchů či jiným doporučeným postupem.
Součástí akceptace systému je provedení penetračního testu a skenu známých zranitelností. Testována jsou rozhraní dostupná z internetu, interním uživatelům i případná další (propojení s jinými systémy).
Všechna datová média (především pevné disky) použitá v informačním systému jsou před přemístěním mimo prostory ČNB bezpečně smazána nebo zničena.
K funkcím pro správu, změny, diagnostiku apod. systému je přístup pouze ze sítě ČNB (příp.
prostřednictvím běžného vzdáleného přístupu zaměstnance ČNB do této sítě.)
Poskytovatel nemá ze svých sítí jiný přístup k systému.
2.2 Zabezpečení dokumentů v systému
Vzhledem k nutnosti býti v souladu s požadavky ESCB, které jsou stanoveny v dokumentu
„Jednotná pravidla a minimální standardy pro nakládání s citlivými informacemi ESCB a SSM“, musí být data v DMS zabezpečena dle požadavků uvedených níže:
a) Statická data
(míněno data ukládaná na servery, pracovní stanice, vyjímatelná media a mobilní zařízení)
Použití šifrovací metody | ||||
Klasifikace ESCB | Klasifikace ČNB (dle Pokynů ČNB č. 38/2015) | Servery | Pracovní stanice | Vyjímatelné disky a mobilní zařízení |
ECB-SECRET | Přísně chráněno | M | M | M |
Použití šifrovací metody | ||||
Klasifikace ESCB | Klasifikace ČNB (dle Pokynů ČNB č. 38/2015) | Servery | Pracovní stanice | Vyjímatelné disky a mobilní zařízení |
ECB- CONFIDENTIAL | Chráněno | R | M | M |
ECB- RESTRICTED | Omezený přístup | NA | NA | M |
b) Dynamická data:
(míněno data putující mezi klientskými stanicemi, servery a ostatními zařízeními, stejně jako elektronické transakce přes telekomunikační sítě operátorů)
Použití šifrovací metody | |||||
Klasifikace ESCB | Klasifikace ČNB (dle Pokynů ČNB č. 38/2015) | Interní | Externí | Interní přenosy1 | Externí přenosy2 |
ECB-SECRET | Přísně chráněno | M | M | M | M |
ECB- CONFIDENTIAL | Chráněno | R* | M | R* | M |
ECB- RESTRICTED | Omezený přístup | NA | R | NA | R |
Vysvětlivky k hodnotám v tabulce:
M - musí být šifrováno nebo použity kompenzační zabezpečovací prvky pro zmírnění příslušných rizik
R - šifrování je doporučeno
R*- šifrování je velmi důrazně doporučeno
NA - není třeba šifrovat
2.3 Vzdálený přístup k dokumentům v systému
ČNB připojuje uživatele do sítě prostřednictvím vzdálené plochy realizované pomocí klientského SW Citrix Receiver.
1 Interní komunikace – data jsou přenášena pouze důvěryhodnými sítěmi, VPN apod.
2 Externí komunikace – data jsou přenášena přes veřejné nebo nezabezpečené sítě (např. Internet)
3 Vazby na interní IS
3.1. Seznam vazeb – základní přehled
Systém | Popis využití | |||||
DMS - MS Office plug-in | Předpokládaný plug-in do aplikace MS Office zajišťující integraci mezi MS Office (včetně plug-in do MS Outlook) a DMS. | |||||
Microsoft AD RMS | Microsoft AD Rights Management System systém pro zabezpečení informací v elektronických dokumentech před neautorizovaným přístupem. Umožňuje zašifrovat jednotlivé dokumenty již u původce a zpřístupnit informace v dokumentu pak jen předem definovaným uživatelům. Systém DMS musí umožnit standardní správu dokumentů obsahujících klasifikované informace, které jsou chráněny šifrováním. | |||||
MS Exchange | Microsoft Exchange Server je SW produkt společnosti Microsoft, který bude využit pro zasílání e-mailových notifikací generovaných v systému DMS z úložiště dokumentů nebo z workflow na určené uživatele v rámci ČNB. | |||||
ŘDB | Informační systém pro správu řízení přístupu uživatelů a skupin uživatelů domény xx.xxx.xx k IS ČNB a pro správu nastavení zařízení zapojených do LAN sítě ČNB. Nový systém DMS bude denně aktualizovat z ŘDB/Active Directory uživatele a uživatelské a organizační skupiny. | |||||
IS e-Spis | Systém elektronické spisové služby, ve kterém jsou evidovány dokumenty v podatelně/výpravně ČNB a spisových uzlech jednotlivých sekcí. Systém splňuje všechny náležitosti spisové služby v souladu s Národním standardem (tvorba spisu, ukládání spisu, skartační řízení atd.) a zajišťuje také archivaci spisů v souladu se zákonem č. 499/2004 Sb. o archivnictví a spisové službě. | |||||
IS HRIS | Informační systém HRIS pro řízení lidských zdrojů, který bude pro systém DMS poskytovat údaje o nepřítomnosti zaměstnance (dovolená, volno, nemoc, služební cesta). | |||||
IBIS | Intranet ČNB (IBIS) | |||||
SIEM | Systém pro centrální sběr bezpečnostních logů (Security Information and Event Management), kde jsou ukládány detailní záznamy o přístupech uživatelů do systémů, popř. jejich dalších aktivitách v systému. | |||||
DMS web services | Webové služby systému DMS zajišťující možnost napojení a využití služeb DMS pro okolní systémy a systému DMS umožňující napojení se na služby externích systémů. | |||||
Klientská stanice, domácí klientská stanice, notebook, iPad | Uživatelská zařízení pro přístup do systému. | |||||
Firewall | Síťové zařízení, které slouží k řízení a zabezpečování síťového provozu mezi externími sítěmi a interní sítí ČNB. Zabezpečuje komunikaci pro domácí klientské stanice, mobilní zařízení uživatelů (zaměstnanců ČNB) přes VPN. | |||||
IS Obelisk | Stávající úložiště dokumentů, relevantních dokumentů do DMS | ze | kterého | bude | provedena | migrace |
Software 602 Signer | Aplikace zajišťuje převody dokumentů do formátu PDF a PDF/A, možnost podepsání dokumentu elektronickým certifikátem, včetně vložení časového razítka. Je implementována jako plug-in do MS Office. |
Detailní popis některých vazeb
3.2. Integrace s MS Office – Word, Excel, Powerpoint, Outlook aj.
Plug-in do MS Office umožní využít základní operace vytvoření/úpravy dokumentu a
připomínkování.
Uživatel vytvoří v MS Office nový dokument a pomocí funkcionality „Uložit“ vybere cílové úložiště v adresáři systému DMS, poté potvrdí uložení nového dokumentu. Systém DMS ověří přístupová oprávnění a přidělí automaticky hodnoty přednastavených metadat a v případě, kdy identifikuje potřebu vložení uživatelských metadat vyzve uživatele k jejich doplnění. Pokud uživatel nevyplní povinná metadata, systém neumožní uložení souboru. Stejný postup bude v případě otevření existujícího souboru (uloženého mimo úložiště DMS) v MS Office, pokud jej bude uživatel chtít uložit do DMS.
Při otevírání již vytvořeného dokumentu uloženého v DMS uživatel vybere soubor z cílového úložiště systému DMS a potvrdí jeho otevření. Systém DMS vyhodnotí přístupová oprávnění a provede otevření souboru v příslušné aplikaci.
Při odesílání odkazu na uložený dokument v DMS jiným uživatelům e-mailovou zprávou se oprávněnému koncovému uživateli otevře odkazovaný soubor/složka souborů v novém okně/záložce. Adresátem může být osoba, organizační struktura nebo aplikační skupina nebo jejich kombinace.
Rozšíření MS Office plně podporuje procesy uvedené v příloze č.1 Věcné zadání – kapitola 9 Popis vzorového procesu ČNB, která je nedílnou součástí smlouvy.
Integrace s MS Outlook zajišťuje příjem notifikací generovaných systémem DMS v rámci workflow, tj. při přidělení úkolu, při upomínce termínu zpracování úkolu, nebo příjem avíz/notifikací o vložení nového dokumentu do úložiště DMS a/nebo o jeho změnách.
Z prostředí MS Outlook je možné uložit přílohy z doručené zprávy do úložiště DMS. Systém vybídne uživatele k volbě umístění v systému a v případě potřeby doplnění metadat. Uživatel vyplní povinná i nepovinná metadata a potvrzením tyto přílohy uloží. Pokud uživatel nevyplní povinná metadata, systém neumožní uložení přílohy.
3.3.Integrace s Microsoft AD RMS
V současné době je používán pro šifrování dokumentů Microsoft AD RMS - Active Directory Rights Management.
Systém DMS umožní uložení těchto dokumentů do příslušné složky ve struktuře úložiště DMS, včetně možnosti spuštění workflow nad těmito dokumenty. Samotný systém DMS nedisponuje funkcionalitou šifrování dokumentů.
S ohledem na šifrování je počítáno s omezenou funkcionalitou systému v oblasti fulltextového vyhledávání.
3.4.Integrace s MS Exchange
Integrace s MS Exchange je na úrovni odesílání e-mailů zaměstnancům ČNB na základě avíz/notifikací generovaných ze systému DMS.
3.5.Integrace s ŘDB
Integrace s ŘDB zajišťuje aktualizaci uživatelů a skupin z domény xx.xxx.xx. Na základě existence uživatele v aplikačních a organizačních skupinách vedených v ŘDB je uživatel autorizován pro vstup do systému DMS.
V současném systému pro správu dokumentů IS Obelisk dochází k synchronizaci uživatelů a uživatelských skupin s databází personálních údajů zaměstnanců ČNB prostřednictvím ŘDB. Využívá přitom tabulek ŘDB „ZAMEST“ (obsahuje informace o zaměstnancích – jméno, titul, příjmení, status, příslušnost k org. útvaru apod.), „ORG2“ (údaje o základních organizačních jednotkách) a „ORG3“ (členění organizačních jednotek). Aktualizovaná data z ŘDB jsou poskytnuta 1x denně prostřednictvím synchronizační procedury. O provedení synchronizace je proveden zápis v databázi systému.
Tento princip se přebírá pro základní nastavení oprávnění v SW řešení DMS.
ŘDB poskytuje aktuální interní e-mailové adresy zaměstnanců ve vazbě na osobní číslo ve formátu xxxxx.xxxxxxxx@xxx.xx.
3.6.Integrace s e-Spis
Pro integraci DMS a e-Spis se využijí webové služby, jejichž popis nabízí dodavatel IS e-Spis společnost ICZ, a.s. stránkách xxxxx://xxx-xxxxxxx.x.xx nebo jej poskytne na vyžádání objednatel. Základní komunikace mezi oběma systémy se řídí standardy popisovanými v dokumentu „Obecné rozhraní pro komunikaci mezi elektronickými systémy spisových služeb a agentovými informačními systémy (Best-practises)“, který vydalo Ministerstvo vnitra ČR (pokud jím poskytovatel nedisponuje, objednatel dokument poskytne na vyžádání).
3.6.1. Předání dokumentu z IS e-Spis do DMS
Do systému DMS IS e-Spis předá celý dokument včetně atributů (zejména atribut číslo jednací dokumentu v e-Spis a číslo jednací spisu v e-Spis), a ten je dále zpracováván v DMS (přiřazení UID, uložení do příslušné složky, spuštění workflow).
Předání dokumentu do DMS je asynchronní událostí. Akci vyvolává uživatel IS e-Spis, a to tak, že dokumentu přidělí požadovaný typ dokumentu (typ spárovaný v administraci s externí aplikací) a provede předání dokumentu externí aplikaci předem definovanou webovou službouu DMS. Systém e-Spis v tuto chvíli připravuje dávku událostí
„DokumentPostoupení“. Dokument je postoupen příslušnému uživateli do DMS, neurčují se však žádná další specifická kritéria agendy, kam, např. do jaké „složky“ má být postoupeno, to již rozhodne přebírající uživatel DMS. DMS zašle uživateli emailovou notifikaci o vložení dokumentu z e-Spisu do příslušné složky v DMS. Přebírající DMS zpracuje události s postoupením dokumentů z e-Spisu a dále řídí jejich zpracování na základě vlastních workflow. Podrobnosti budou obsaženy v realizační studii.
3.6.2. Předání dokumentu z DMS do IS e-Spis
Pokud na základě procesů v DMS vznikne potřeba založení nového dokumentu do IS e-Spis, pak tento systém vyvolá synchronní událost API WS (BP) rozhraní, a to DokumentZalozeni. Založení dokumentu z DMS vyžaduje splnění některých povinných podmínek, a to zejména naplnění minimálních povinných elementů pro založení dokumentu (např. Nazev = věc
dokumentu, Identifikátor = UID dokumentu ve tvaru ZdrojId a HodnotaId, TypDokumentu a SpisovyZnak, pokud nejsou součástí tzv. defaultních hodnot nastavení integračního můstku). Dokument musí být zároveň založen pod existujícím autentizovaným uživatelem IS e-spis, na jehož funkčním místě má vzniknout.
Proces vzniku dokumentu v externím DMS je zpravidla složen z více událostí, zvláště pokud součástí vzniklého záznamu o dokumentu (metadatech) má být i elektronický obsah (soubor). Sled volaných událostí vypadá následovně:
• DokumentZalozeni – založení záznamu o dokumentu (záznam o ČJ)
• SouborZalozeni – založení el. přílohy (souboru), tedy obsahu dokumentu
• SouborVlozitKDokumentu – provázání uložené el. přílohy (souboru) s evidenčním záznamem o dokumentu v systému
Vložení dokumentu do IS e-Spis nastává zpravidla v okamžiku, kdy je již k dispozici finální verze dokumentu, který má být vložen a evidován v IS e-Spis, např. po ukončení workflow, ve kterém vznikne upravený dokument nebo dokument nový. Vložení dokumentu do IS e- Spis bude prováděno jednak automaticky na základě nastavení hodnoty příslušného atributu dokumentu, jednak manuálně na základě úkonu oprávněného uživatele. Do IS e-Spis se vkládá dokument:
a) s přidělením nového čísla jednacího a uložením do již existujícího spisu (např. původního, ze kterého byl dokument předán do DMS):
a. Synchronní událost: DokumentZalozeni
b. Asynchronní událost:
i. SouborZalozeni,
ii. SouborVlozitKDokumentu,
iii. DokumentVlozeniDoSpisu – vložení dokumentu s obsahem do existujícího spisu, ERMS musí znát Identifikátor (ZdrojId a HodnotaId) spisu, do něhož má být dokument vložení
b) s přidělením nového čísla jednacího a založením spisu nad tímto dokumentem
a. Synchronní událost: DokumentZalozeni
b. Asynchronní událost:
i. SouborZalozeni
ii. SouborVlozitKDokumentu
iii. SpisZalozeni – odkaz na existující dokument prostřednictvím
elementu DokumentIdVlozeny
3.7.Integrace s IS HRIS
Informační systém HRIS pro řízení lidských zdrojů poskytuje pro systém DMS údaje o nepřítomnosti zaměstnance v tomto rozsahu:
- plánovaná a předpokládaná dovolená
- regenerace pracovní síly
- nemoc
- služební cesta
- státní svátek
Údaje jsou poskytovány prostřednictvím datového view ODY_PLANIS_NEPRIT, které přenáší údaje v intervalu: dnešek minus 2 měsíce, dnešek plus 6 měsíců. Data se budou synchronizovat 1x denně (nejlépe v ranních hodinách mezi 05:00-06:00).
Na základě těchto údajů přesměruje systém DMS úkoly ve workflow na nastavené zástupce uživatele po dobu jeho nepřítomnosti. Pokud nebude mít uživatel svého zástupce po dobu nepřítomnosti nastaveného, bude jeho úkol uzavřen po uplynutí termínu k vyřízení úkolu. Při zadání úkolu může v závislosti na jeho povaze a obsahu uživatel nastavit, zda bude vyžadovat od zpracovatele či připomínkového místa aktivní reakci nebo postačí pasivní neporušení tiché procedury, tedy např. v případě schvalovacího řízení to bude uzavření úkolu s výsledkem – dokument schválen, dokument neschválen či adresát se nevyjádřil.
3.8.Integrace s IBIS
Pro intranet ČNB slouží DMS jako úložiště dokumentů, popř. jiných souborů s informacemi, které mají být publikovány na intranetu ČNB (IBIS). IBIS v současné době používá vlastní úložiště nebo jsou v něm uvedeny odkazy na dosud provozovaný systém IS Obelisk. Po provedení migrace dokumentů z Obelisku do nového DMS musí být odkazy na dokumenty z IBISu přesměrovány do DMS.
3.9. Integrace s IS SIEM
Viz kapitola 1.7.4. SIEM (Sběr bezpečnostních logů).
3.10. IS Obelisk
Informační systém Obelisk je databázový systém využívaný v ČNB ke správě dokumentů a jejich publikování na intranetu. IS Obelisk je interní aplikace provozovaná nad Oracle DB Serverem (verze 10.2.0.5.0). Do úložiště jsou uploadovány dokumenty formátu MS Office 2010 (a v některých případech i starších verzích MS Office). Uživatelé pracují v několika rolích s oprávněním na čtení nebo vkládání a úpravy dokumentů.
Dokumenty uložené v tomto systému budou předmětem migrace.
3.11.Podpisová kniha
Systém musí umožnit napojení na interní aplikaci ČNB Podpisová kniha, který zajištuje podpis dokumentu kvalifikovaným elektronickým certifikátem.
3.12.Aplikace Software 602 Signer
Pro práci s dokumenty v pdf formátu využívá ČNB aplikaci Signer (dodavatel Software 602), verze 3.0.5. Pro manipulaci se soubory (otevření, editace a ukládání) mohou být využity nástroje aplikace Signer. Aplikace zajišťuje převody dokumentů word do formátu PDF a PDF/A, možnost podepsání dokumentu elektronickým certifikátem, včetně vložení časového razítka. Je implementována také jako plug-in do MS Office.
4 Migrace dat
Pod pojmem „migrace dat“ jsou zahrnuty tyto akce a procesy:
a) analýza zdrojové struktury IS Obelisk, cílové struktury DMS a transformační mapování mezi oběma strukturami,
b) export objednatelem určených dat z IS Obelisk pro DMS na základě namapování dat,
c) import vyexportovaných dat z IS Obelisk do DMS.
ad a)
Analýzu a přípravu procesu uvedeného v bodu a) musí zajišťovat objednatel ve spolupráci s poskytovatelem DMS. Poskytovatel SW řešení DMS musí poskytnout datové struktury nového systému a ve spolupráci s objednatelem navrhne namapování dat z IS Obelisk a dat DMS. Popis namapování a následné migrace bude zdokumentován v realizační studii.
ad c)
Poskytovatel DMS musí připravit datové struktury a nástroje pro import vyexportovaných dat z IS Obelisk. Po importu musí být provedeno otestování komplexnosti dat (dokumenty včetně metadat), jejich správnosti a přidělení přístupových oprávnění z hlediska metodiky nového DMS.
Objednatel předpokládá, že procesy b) a c) mohou být opakovány několikrát podle specifikace objednatele, vzhledem k typu dat uložených v současném IS Obelisk. Detailní rozsah bude popsán v realizační studii.
5 Specifické požadavky
Tabulka technických specifických požadavků je uvedena v příloze č. 2b smlouvy.
Specifické požadavky Příloha č. 2b smlouvy
Základní (ZAK) | |||||
ID | Název | Popis požadavku | Důležitost | Nabízený systém požadavek splňuje (výběr z hodnot)* | Požadavek bude realizován? (jen pro vítané)** |
ZAK01 | Typ aplikace | Systém musí být realizován jako webová aplikace přístupná z prostředí Microsoft Internet Explorer 11. | Závazný | Kompletně vyřešeno |
Administrace (ADM) | |||||
ID | Název | Popis požadavku | Důležitost | Nabízený systém požadavek splňuje (výběr z hodnot)* | Požadavek bude realizován? (jen pro vítané)** |
ADM01 | Administrátorská dokumentace | K systému musí existovat kompletní elektronická administrátorská příručka popisující způsob administrace aplikace a dále funkční a technická specifikace v českém nebo anglickém jazyce. | Závazný | Kompletně vyřešeno | |
ADM02 | Neplatné reference | Systém musí obsahovat administrátorské nástroje na kontrolu neplatných odkazů/referencí, resp. vazeb mezi soubory/dokumenty (např. administrátor má k dispozici seznam neplatných odkazů popsaných v požadavku SME15). | Závazný | Částečně vyřešeno | |
ADM03 | Statistiky přístupu | S ohledem na přístupová práva uživatele a jeho kompetence systém umožňuje zobrazit statistické přehledy využití aplikace: (1) počet aktuálně přihlášených uživatelů, (2) nejpopulárnější dokumenty, (3) odstraněné dokumenty, (4) duplicitní dokumenty, (5) prázdné dokumenty, (6) množství přírůstků v úložišti za časový interval (den/týden/měsíc), (7) množství přístupů k souborům obsahujícím klasifikované informace (ve smyslu vnitřního předpisu ČNB). | Vítaný | Kompletně vyřešeno | Ano |
ADM04 | Definice kvót úložného prostoru | Systém umožňuje definovat pro jednotlivé složky maximální kapacitu úložného prostoru. | Vítaný | Musí být kompletně nově vyvinuto | Ano |
ADM05 | Komprese | Systém umožňuje komprimovat dokumenty v DB úložišti nebo souborovém (file) systému na základě zvolených pravidel, např. pokud dokument nebyl otevřen/přečten déle jak N dnů. | Vítaný | Musí být kompletně nově vyvinuto | Ne |
ADM06 | Konfigurovatelnost systému | Systém administrátorovi umožní, aby řízeným způsobem vyhledával, zobrazoval a rekonfiguroval parametry systému. | Vítaný | Musí být kompletně nově vyvinuto | Ne |
ADM07 | Evidence aktualizací a verzí | Systém musí evidovat vlastní verze a provedené aktualizace a tyto informace musí být dohledatelné technickým správcem aplikace. | Závazný | Kompletně vyřešeno | |
ADM08 | Zpráva o stavu systému | Systém musí umožnit správci získat zprávy o stavu a aktuální výkonnosti systému. Zprávy musí obsahovat pro dokumenty, složky, metadata, prvky hierarchie webové struktury alespoň následující: (1) počet, (2) transakční statistika, (3) výpis činností podle uživatelů. | Závazný | Částečně vyřešeno |
Bezpečnost (BEZ) | |||||
ID | Název | Popis požadavku | Důležitost | Nabízený systém požadavek splňuje (výběr z hodnot)* | Požadavek bude realizován? (jen pro vítané)** |
BEZ01 | Autentizace | K přihlášení uživatele do DMS je využita identita z přihlášení k desktopu/vDesktopu pomocí jeho doménového účtu v AD technologií SSO (Single Sign On). Identita uživatele je převzata z jeho přihlášení do operačního systému Windows. | Závazný | Kompletně vyřešeno | |
BEZ02 | Autorizace | Systém přebírá uživatele z ŘDB / AD, kde je zajištěna jejich aktualizace včetně jejich zařazení do organizační / aplikační skupiny ČNB (aplikační skupiny jsou dvě - 1. users, 2. admins). Na základě existence v těchto skupinách je uživatel autorizován pro práci v systému. | Závazný | Musí být kompletně nově vyvinuto | |
BEZ03 | Oprávnění | Systém musí umožnit nadefinovat přístupová oprávnění (vytvoření, uložení, čtení, editace, mazání) jednotlivých uživatelů nebo jejich skupin k souborům, složkám a dalším objektům DMS (např. metadatům) podle řady kritérií a jejich kombinací. Tato kritéria zahrnují: 1) roli uživatele v rámci DMS (např. koordinátor určitého fóra), roli uživatele v rámci konkrétního workflow v DMS a roli uživatele z hlediska jeho zařazení v organizační struktuře ČNB 2) oprávnění uživatele/skupiny uživatelů přistupovat k určitým složkám ve struktuře úložiště DMS (oprávnění se dědí z vyšších složek do nižších) 3) oprávnění uživatele/skupiny uživatelů přistupovat ke klasifikovaným informacím (podle atributu souboru, který určuje stupeň klasifikace informací -viz požadavek ODI05). | Závazný | Kompletně vyřešeno | |
BEZ04 | Uživatel má více rolí | Uživatel musí mít možnost mít přiděleno více uživatelských rolí pro práci ve workflow (viz kapitola 6 Uživatelské role přílohy č. 1a Věcné zadání). | Závazný | Kompletně vyřešeno |
BEZ05 | Omezení/přiřazení přístupových oprávnění uživatelům | Oprávněný uživatel má právo přidělit/omezit/odebrat konkrétním uživatelům nebo uživatelským skupinám přístupová oprávnění k souborům/složkám a operacím nad nimi. | Závazný | Kompletně vyřešeno | |
BEZ06 | Jednoduché ad hoc řízení přístupových oprávnění k uloženému souboru/složce s nastavením expirace. | Oprávněný uživatel musí mít možnost přidělit dočasná přístupová oprávnění k souboru/složce nebo jejich skupině (tj. hromadně), k nimž má přidělena oprávnění, jakož i k souborům/složkám ve svém osobním úložišti, napříč bankou pro jednotlivce, skupinu či organizační strukturu bez ohledu na již systémem přidělená oprávnění (viz také PPD05). Tato oprávnění zaniknou automaticky po vypršení termínu nastavitelného oprávněným uživatelem. Při vytváření podsložek budou defaultně přebírána oprávnění z rodičovské úrovně s možností individuální úpravy oprávnění na vytvářené složce. | Závazný | Částečně vyřešeno | |
BEZ07 | Evidence a správa oprávnění | Systém musí obsahovat interní nástroj/modul pro správu, řízení a evidenci přidělených oprávnění (viz BEZ03). | Závazný | Kompletně vyřešeno | |
BEZ08 | Omezení při vyhledávání | Zobrazení výsledků vyhledávání je závislé na přístupových oprávněních hledajícího uživatele a kategorii klasifikace vyhledávaných údajů. Jestliže uživatel vyhledává dokument, ke kterému nemá přístupové oprávnění a nejedná se o dokument, který obsahuje klasifikované informace (viz požadavek BEZ09) systém ve výsledcích vyhledávání zobrazí pouze informaci o existenci dokumentu a jeho název, neumožní však čtení obsahu dokumentu ani ostatních metadat a rovněž nezobrazí výsledky vyhledávání v obsahu dokumentu. | Závazný | Částečně vyřešeno | |
BEZ09 | Omezení vyhledávání klasifikovaných informací | V případě vyhledávání dokumentů, které obsahují klasifikované informace se uživateli bez příslušného oprávnění ve výsledcích vyhledávání nezobrazí žádný záznam o takovém dokumentu/složce (pozn. tento požadavek platí pro všechna vyhledávání). | Závazný | Kompletně vyřešeno | |
BEZ10 | Dlouhodobý zámek (uživatelsky nastavený) | Pokud má uživatel oprávnění, může uzamknout dokument proti úpravám dalšími uživateli. Pokud je dlouhodobý zámek aktivován, daný soubor a jeho vlastnosti lze pouze prohlížet. Upravovat a odemknout (zrušit dlouhodobý zámek) dokument může jen uživatel, který dlouhodobý zámek zapnul nebo administrátor. | Závazný | Kompletně vyřešeno | |
BEZ11 | Hosting/Outsourcing | Řešení nesmí využívat žádné outsourcing a hosting služby mimo infrastrukturu ČNB. | Závazný | Kompletně vyřešeno | |
BEZ12 | Zpracování informací mimo ČNB | Systém nesmí zpracovávat data, informace ani jejich části mimo systémové prostředí ČNB. | Závazný | Kompletně vyřešeno | |
BEZ13 | Penetrační testy | Systém neobsahuje žádné zranitelnosti obsažené v seznamech OWASP top 10 (2013, xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxx_00_0000-Xxx_00) a CWE/SANS top 25 most dangerous software errors (2011, xxxx://xxx.xxxxx.xxx/xxx00/). Systém musí být dodavatelem podroben penetračním testům na vlastním neupraveném prostředí a na vlastní náklady. Výsledky budou předloženy a uvedeny v rámci přípravy realizační studie. Následně proběhnou penetrační testy v rámci akceptačních testů v prostředí objednatele a po každém upgradu/updatu bude provedeno ověření bezpečnosti formou penetračního testu nebo automatizovaného skenu na výskyt zranitelností. Objednatel provádí penetrační testy na své náklady a dodavatel odstraňuje na své náklady nalezené vady. | Závazný | Kompletně vyřešeno | |
BEZ14 | Existence vzdálené podpory | Při návrhu systému a jeho provozní podpory není z bezpečnostního důvodu povolen vzdálený přístup externím subjektům (právních ani fyzických) k testovacím ani provozním serverům. | Závazný | Kompletně vyřešeno | |
BEZ15 | Oddělená prostředí | Řešení zahrnuje testovací a provozní prostředí. Přenos změn (kódu) mezi prostředími je řízen. Přístupová práva k datům, funkcím i správě systému jsou v oddělených prostředích spravována samostatně. Testovací prostředí má nastaveno shodné nebo vyšší zabezpečení jako provozní prostředí. | Závazný | Kompletně vyřešeno | |
BEZ16 | Time - out | Systém musí umožnit nastavení automatického odhlášení při nečinnosti uživatele na PC (uživatelské stanici) po určité době, která je nastavitelná (např. 30 min), tj.vypršení tzv. session, kdy je nutno se znovu přihlásit. | Závazný | Kompletně vyřešeno | |
BEZ17 | Bezpečná komunikace | Komunikace a přenosy dat mezi stanicemi uživatelů a správců a dalšími částmi systému (servery) v síti ČNB i mimo ni jsou chráněny kryptografickými technikami proti odposlechu (důvěrnost) a modifikaci (integrita), například použitím TLS. Pro přenos/uložení dat musí být použity algoritmy dle § 25 odst. 2b + příloha 3 vyhlášky 316/2014 Sb. | Závazný | Kompletně vyřešeno | |
BEZ018 | Druhý stupeň autentizace | Systém podporuje druhý stupeň autentizace, který je využíván pro přístup k souborům obsahujícím klasifikované informace (viz ODI05). Uživatel prokazuje svoji identitu certifikátem, který je generován a uložen na čipové kartě zaměstnance ČNB. | Závazný | Částečně vyřešeno | |
BEZ19 | Údaj o předchozím přihlášení uživatele do systému | Systém umožňuje zobrazit uživateli údaj o posledním přihlášení do systému (datum, hodina). | Vítaný | Musí být kompletně nově vyvinuto | Ne |
BEZ20 | Ukládání dokumentů mimo systém | Systém smí umožnit ukládání dokumentů mimo úložiště systému pouze s vygenerováním příslušného upozornění na tuto akci. | Vítaný | Musí být kompletně nově vyvinuto | Ne |
BEZ21 | Ukládání změn při automatickém odhlášení | V případě automatického odhlášení při nečinnosti systém uchová provedené, avšak uživatelem dosud neuložené změny pro příští přihlášení uživatele nebo vyzve k jejich uložení. | Vítaný | Musí být kompletně nově vyvinuto | Ne |
BEZ22 | Administrátorské účty | Pokud budou administrátorské účty k systému typu user/password musí hesla k těmto účtům umožňovat nastavení délky, komplexity a časového omezení (expiraci) a musí být zajištěno jejich bezpečné uložení (např. hash nebo salted hash s využitím dostatečně silného algoritmu). | Závazný | Kompletně vyřešeno | |
BEZ23 | Vývoj systému | Vývoj systému je prováděn pomocí bezpečných programovacích praktik | Závazný | Kompletně vyřešeno | |
BEZ24 | Patch management | Výrobce systému má zajištěn proces odstraňování zranitelností systému (patch management) minimálně na ¼-letní bázi | Závazný | Kompletně vyřešeno | |
Auditovatelnost systému (AUD) | |||||
ID | Název | Popis požadavku | Důležitost | Nabízený systém požadavek splňuje (výběr z hodnot)* | Požadavek bude realizován? (jen pro vítané)** |
AUD01 | Auditní log | Systém zaznamenává úspěšné i neúspěšné pokusy o přístupech k dokumentům/složkám. | Závazný | Částečně vyřešeno | |
AUD02 | Obsah auditního logu | Systém musí udržovat nezměnitelný auditní log, schopný automaticky zachytit a uložit údaje o: (1) všech operacích provedených s prvkem systému např. dokument, složka; (2) uživateli, který operaci iniciuje nebo provádí; včetně činností administrátora, (3) datu a času této události s přesností na sekundy. | Závazný | Kompletně vyřešeno | |
AUD03 | Délka životnosti auditního logu | Systém musí udržovat auditní log minimálně po dobu 13 měsíců, popř. bez časového omezení. | Závazný | Kompletně vyřešeno | |
AUD04 | Čitelnost auditního logu | Systém musí zajistit, aby údaje z auditního logu byly na požádání dostupné ve srozumitelné formě pro kontrolu uživateli, kteří se systémem nejsou obeznámeni vůbec nebo jen málo. | Závazný | Částečně vyřešeno | |
AUD05 | Záznam změn | Systém musí zajistit auditní log o všech změnách provedených na auditovatelných položkách. Auditovatelnou položkou se myslí soubor, složka, virtuální složka (filtr), metadata, která jsou povinně auditovaná (viz správa metadat) a ta, u kterých oprávněný uživatel nastavil příznak pro auditování. | Závazný | Musí být kompletně nově vyvinuto | |
AUD06 | Auditní události (přiřazení přístupu) | Systém musí zaznamenávat auditní události přiřazení přístupu: (1) Přidání oprávnění uživateli (2) Odebrání oprávnění uživateli | Závazný | Kompletně vyřešeno | |
AUD07 | Auditní události (řízení přístupu) | Systém musí zaznamenávat auditní události související s řízením přístupu: (1) Logování přístupu ke složkám / jednotlivým dokumentům, včetně generování reportů pro následný monitoring, (2) Povolení přístupu k dokumentům/souborům (včetně toho, jaká akce byla provedena nad daným objektem), (3) Zamítnutí přístupu k dokumentům/souborům (včetně toho, jaká akce byla zamítnuta nad daným objektem a z jakého důvodu), (4) Změna ACL (Access Control List), (5) Přihlášení a odhlášení uživatelů/administrátorů do systému, (6) Činnosti provedené administrátory systému (mj. změnu rozsahu zaznamenávání, pokud je možná), (7) Přístupy k auditním záznamům. | Závazný | Kompletně vyřešeno | |
AUD08 | Automatický export auditních logů | Systém musí navíc umožnit automatický export strojově čitelných auditních logů v konfigurovatelný čas a do konfigurovatelného výstupního adresáře. | Závazný | Musí být kompletně nově vyvinuto | |
AUD09 | Audit hromadných operací | V případě provedení hromadných operací musí být v auditním logu navíc uchována informace i o této hromadné operaci s vazbou na jednotlivé dílčí akce, např. při smazání složky budou provedeny záznamy o smazání jednotlivých souborů/dokumentů uložených v této složce. | Závazný | Musí být kompletně nově vyvinuto | |
AUD10 | Tisk auditních logů | Systém musí administrátorovi umožnit vytištění auditního logu složky/dokumentu/systému v lidsky srozumitelné podobě. | Vítaný | Kompletně vyřešeno | Ano |
AUD11 | Export auditních logů | Systém musí administrátorovi umožnit export auditního logu vybrané složky/dokumentu v systému v čitelné podobě. | Závazný | Kompletně vyřešeno | |
AUD12 | Modifikace auditních logů | Záznamy a auditní logy jsou chráněny proti jakékoliv modifikaci a smazání. | Závazný | Kompletně vyřešeno | |
AUD13 | Detekce smazání části záznamů auditních logů. | Systém umožňuje detekovat smazání části záznamů auditních logů. | Vítaný | Musí být kompletně nově vyvinuto | Ne |
Integrace (INT) | |||||
ID | Název | Popis požadavku | Důležitost | Nabízený systém požadavek splňuje (výběr z hodnot)* | Požadavek bude realizován? (jen pro vítané)** |
INT01 | Web services | Pro účely integrace systému DMS se systémy třetích stran musí systém pomocí web services umožňovat provést alespoň následující operace: (1) vytvoření souboru/složky, (2) odstranění souboru/složky, (3) získání / nastavení / vložení hodnoty nebo vlastnosti objektu a provedení vlastní metody (akce) nad nejméně těmito objekty: soubor, složka (adresář), metadata, uživatel, přístupové oprávnění, filtr, (4) vyhledávání | Závazný | Kompletně vyřešeno |
INT03 | Dokumentace web services | Dokumentace pro web services obsahuje: (1) výstižný popis hlavního smyslu služeb, (2) pro vlastnosti povinně popis významu hodnot, kterých mohou nabývat (konstanty, rozsahy), (3) podrobný popis užití a příklady implementace pro jednotlivé služby. | Závazný | Kompletně vyřešeno | |
INT04 | Integrace s Microsoft Office | Manipulace se soubory podporovaných formátů (otevření, editace a ukládání) je možná přímo z nástrojů MS Office (verze 2010 a vyšší). | Závazný | Kompletně vyřešeno | |
INT05 | Integrace s Microsoft Outlook | Metadata formátu „Datum“ budou přenesena u definovaných složek do kalendáře MS Outlook, včetně názvu složky. Z prostředí MS Outlook bude možné uložit přílohy z doručené zprávy. | Vítaný | Musí být kompletně nově vyvinuto | Ne |
INT06 | Integrace se Spisovou službou | Systém musí obsahovat propojení s IS spisové služby e-Spis (dodavatel ICZ, a.s.). Do systému DMS bude e-Spis poskytovat buď celé dokumenty včetně atributů (zejména atribut číslo jednací dokumentu v e-Spis, číslo spisu, popř. jedinečné UID, dokumentu v IS e-Spis), které budou dále zpracovávány v DMS, nebo bude umožňovat vložení dokumentu zpracovaného v DMS do příslušného spisu/podsložky spisu v IS e-Spis, dále přidělení čísla jednacího v e-Spis a následné další zpracování podle příslušné metodiky práce v IS e-Spis. Popis je uveden Technickém zadání v příloze č. 2a smlouvy. | Závazný | Musí být kompletně nově vyvinuto | |
INT07 | Integrace MS Exchange | Integrace s MS Exchange Server 2010 na úrovni: (1) odesílání/příjem notifikací s odkazy na dokumenty v systému, (2) využití distribučních seznamů. | Závazný | Kompletně vyřešeno | |
INT08 | ŘDB/Active directory | Integrace s ŘDB/AD pro aktualizaci uživatelů, uživatelských skupin a organizační struktury ČNB. | Závazný | Částečně vyřešeno | |
INT09 | Úložiště využitelné pro ostatní aplikace | Úložiště systému musí být využitelné i pro ostatní aplikace jako standardní úložiště dokumentů. | Závazný | Kompletně vyřešeno | |
INT10 | Integrace s IS HRIS | Systém musí umožnit integraci se systémem pro evidenci lidských zdrojů ČNB (IS HRIS - dodavatel DataCentrum), který bude systému DMS poskytovat údaje o nepřítomnosti zaměstnance (plánovaná a předpokládaná dovolená, regenerace pracovní síly, nemoc, služební cesta, státní svátek) na základě poskytnutého view do databáze systému pro evidenci lidských zdrojů. | Vítaný | Musí být kompletně nově vyvinuto | Ano |
INT11 | Migrační rozhraní | Systém musí umožnit (např. za použití web services) hromadný import dat za účelem migrace vybraných dat ze stávajícího systému (IS Obelisk), tj. složek, souborů, jejich verzí, uživatelů, skupin uživatelů, oprávnění, metadat, relací, zástupců souborů, virtuálních složek. | Závazný | Kompletně vyřešeno | |
INT12 | Kooperace s MS AD RMS | Systém musí umožnit standardní správu dokumentů obsahujících klasifikované informace, které jsou chráněny šifrováním. Samotné šifrování a dešifrování dokumentů bude probíhat mimo systém DMS prostřednictvím samostatného specializovaného systému ČNB (Microsoft AD RMS). | Závazný | Částečně vyřešeno | |
INT13 | Napojení na SIEM | Napojení na systém pro centrální sběr bezpečnostních logů. Systém musí umožnit realtime přístup čtení auditních logů externímu systému (SIEM). Logy musí být být strojově zpracovatelné, tzn. musí být strojově čitelné a mít jednotnou datovou strukturu. | Závazný | Musí být kompletně nově vyvinuto | |
INT14 | Podpis dokumentu elektronickým certifikátem | Systém musí umožnit napojení na interní aplikaci Podpisová kniha, který zajištuje podpis dokumentu kvalifikovaným elektronickým certifikátem nebo musí umožnit podepisovat dokumenty elektronickým certifikátem přímo v systému. | Závazný | Částečně vyřešeno | |
INT15 | Integrace IBIS - Intranet ČNB | Pro intranet ČNB slouží DMS jako úložiště dokumentů, popř. jiných souborů s informacemi, které mají být publikovány na intranetu ČNB (IBIS). IBIS v současné době používá vlastní úložiště nebo jsou v něm uvedeny odkazy na dosud provozovaný systém IS Obelisk. Po provedení migrace dokumentů z Obelisku do nového DMS musí být odkazy na dokumenty z IBISu přesměrovány do DMS. | Závazný | Musí být kompletně nově vyvinuto | |
INT16 | Integrace Software 602 Signer | Aplikace Signer se používá pro práci s dokumenty v PDF formátu (obdoba Adobe Professional). Manipulace se soubory (otevření, editace a ukládání) je možná přímo z nástrojů aplikace Signer ( verze 3.0.5). Aplikace umožňuje podpis dokumentů kvalifikovaným elektronickým certifikátem. | Vítaný | Musí být kompletně nově vyvinuto | |
Technická omezení (TOM) | |||||
ID | Název | Popis požadavku | Důležitost | Nabízený systém požadavek splňuje (výběr z hodnot)* | Požadavek bude realizován? (jen pro vítané)** |
TOM01 | Dostupnost | Dostupnost je zajištěna prostřednictvím dvou geograficky vzdálených středisek v lokalitě Praha. | Závazný | Kompletně vyřešeno | |
TOM02 | Dostupnost 24x7 | Systém musí být koncipován pro nepřetržitý provoz 24 hodin x 7 dní v týdnu, vyjma času na nezbytné provozní odstávky, které budou popsány v provozním řádu systému. Dokumenty musí být přístupné s ohledem na jeho používání v různých časových zónách. | Závazný | Kompletně vyřešeno | |
TOM03 | Aktualizace klientských stanic | Pokud bude třeba aktualizovat klientské stanice, musí aktualizace probíhat pouze s využitím vzdálených, automatických operací. | Závazný | Kompletně vyřešeno |
TOM04 | Přístup k systému z mobilních zařízení | Systém musí být možno využívat na mobilních zařízeních. Mobilními zařízeními se pro tento účel rozumí notebooky, tablety a mobilní telefony (operační systémy iOS nebo Android). ČNB připojuje mobilní zařízení typu notebook a částečně i typu tablet do sítě prostřednictvím vzdálené plochy realizované pomocí mobilní aplikace Citrix Receiver.ČNB požaduje vzdálený přístup z mobilních zařízení včetně „chytrých“ mobilních telefonů k souborům a workflow v DMS, a to buď formou dedikované mobilní aplikace nebo skrze webový prohlížeč přes formuláře s podporou responsivního designu. Tento mobilní vzdálený přístup, který musí umožnit alespoň přístup a zobrazení dokumentů uložených v DMS, otevření souboru skrze URL odkaz uvedený v emailové zprávě na mobilním zařízení propojeném s úložištěm DMS, provedení schvalovacích procesů ve workflow (např. schválení či odmítnutí dokumentu nebo úkolu) a ve zjednodušené podobě navigaci a vyhledávání souborů uložených v DMS, včetně nejnovějších dokumentů (latest documents) relevantních pro konkrétního uživatele, z těchto zařízení. V případě nezvolení varianty mobilní aplikace je proto nezbytné, aby DMS disponovalo verzemi webových formulářů zajišťujících tyto funkce optimalizovanými pro zobrazovací a ovládací možnosti mobilních telefonů (cca 5ti palcové obrazovky). Konkrétní rozsah a podoba aplikace a formulářů budou finalizovány v dohodě s vybraným účastníkem v realizační studii. | Závazný | Částečně vyřešeno | |
TOM05 | Použití v rámci standardního systémového prostředí | Systém umožní koncovému uživateli manipulaci (vytvoření, úpravu, smazání, zobrazení, vyhledávání) se soubory/složkami souborů a jejich metadaty v rámci desktopových aplikací jeho standardního systémového prostředí, např. namapovat si složku jako disk, otevřít dokument, kopírovat, editovat. | Vítaný | Kompletně vyřešeno | Ano |
TOM06 | Velikost souboru | Systém musí umožnit uložit soubor i o velikosti přesahující 500MB. | Závazný | Kompletně vyřešeno | |
TOM07 | Celkový objem souborů a počet / rok | Systém musí být schopen spravovat i více než 150 tisíc souborů, kde každý ze souborů má alespoň 3 verze. Systém musí být připraven alespoň na roční přírůstek 25 tisíc souborů. | Závazný | Kompletně vyřešeno | |
TOM08 | Relační databáze | Systém musí využívat relační databázi vyhovující normě SQL ISO/IEC 075, Informační technologie. | Závazný | Kompletně vyřešeno | |
TOM09 | Kódování souborů | Systém musí spravovat soubory bez ohledu na jejich strojové kódování (UTF8, WIN1250.,…). | Závazný | Kompletně vyřešeno | |
TOM10 | Virtualizace | Všechny části systému musí být možné nasadit a provozovat ve virtualizovaném prostředí. | Závazný | Kompletně vyřešeno | |
TOM11 | Standardní systémové prostředí ČNB | Systém bude provozován na standardním systémovém prostředí ČNB. Popis prostředí je uveden v příloze č. 2a Technické zadání v návrhu smlouvy. | Závazný | Kompletně vyřešeno | |
Obnova systému (OBN) | |||||
ID | Název | Popis požadavku | Důležitost | Nabízený systém požadavek splňuje (výběr z hodnot)* | Požadavek bude realizován? (jen pro vítané)** |
OBN01 | Doba obnovení systému | V případě jakékoliv poruchy softwaru nebo hardwaru, včetně aktualizací SW řešení nebo systémového prostředí, musí být možné obnovit systém do původního stavu (ne staršího než záloha z předešlého dne) v době kratší než 24 hodin po obnovení funkčnosti hardwaru. | Závazný | Kompletně vyřešeno | |
OBN02 | Obnovitelnost | Systém musí zajistit zálohovací nástroje k obnově ze záloh a transakčních protokolů při zachování integrity systému v době kratší než 24 hodin. | Závazný | Kompletně vyřešeno | |
OBN03 | Obnovitelnost systému při jeho aktualizaci | Systém musí zajistit obnovu programu v době kratší než 24 hodin v případě poruchy nebo chyb při aktualizaci a informovat správce o výsledku. | Závazný | Kompletně vyřešeno | |
OBN04 | Plánování záloh | Systém musí správci umožnit naplánování programů zálohování stanovením frekvence zálohování a výběrem věcných skupin, souborů nebo dokumentů k zálohování. | Závazný | Kompletně vyřešeno | |
OBN05 | Obnova ze zálohy | Systém musí umožnit správci provést obnovu ze zálohy při zachování stejného OS nezávisle na HW. | Závazný | Kompletně vyřešeno | |
OBN06 | Automatizované zálohování | Systém musí zajistit automatické postupy zálohování a obnovy, které umožní pravidelné zálohování všech nebo vybraných věcných skupin, souborů, dokumentů a metadat. | Závazný | Kompletně vyřešeno | |
Výkon (VYK) | |||||
ID | Název | Popis požadavku | Důležitost | Nabízený systém požadavek splňuje (výběr z hodnot)* | Požadavek bude realizován? (jen pro vítané)** |
VYK01 | Rychlost ukládání dokumentu (upload) | Systém musí umožnit uložení dokumentu o velikost 1MB do úložiště IS nejpozději do 3 sekund ze všech pracovišť ČNB. Měřeno vždy z pohledu uživatele Výsledek je závislý na průchodnosti sítě objednatele, může být měřeno na serveru. | Závazný | Kompletně vyřešeno | |
VYK02 | Rychlost stahování dokumentu (download) | Systém musí umožnit stažení dokumentu o velikost 1MB z úložiště IS nejpozději do 3 sekund ze všech pracovišť ČNB. Měřeno vždy z pohledu uživatele. Výsledek je závislý na průchodnosti sítě objednatele, může být měřeno na serveru. | Závazný | Kompletně vyřešeno |
VYK03 | Rychlost zobrazení webového obsahu | Systém musí umožnit zobrazit webový obsah o velikost 0,5 MB do 3 sekund ze všech pracovišť ČNB. Měřeno vždy z pohledu uživatele. Výsledek je závislý na průchodnosti sítě objednatele. | Závazný | Kompletně vyřešeno | |
VYK04 | Odezva vyhledávání | Systém musí umožnit provedení jednoduchého vyhledání do 3 sekund a složitého vyhledání (kombinace čtyř libovolných podmínek včetně fultextového vyhledání) do 10 sekund při počtu 100 000 souborů o celkové velikosti 100GB. Čas je měřen na klientské stanici. Výsledek je závislý na průchodnosti sítě objednatele. | Závazný | Kompletně vyřešeno | |
VYK05 | Množství uchovávaných dat | Systém musí umožnit uchovat data o celkové velikosti alespoň 500 GB s další možností rozšíření úložiště. | Závazný | Kompletně vyřešeno | |
VYK06 | Spolehlivost ukládání a stahování dat | Systém musí zajistit spolehlivé uložení (nahrání/upload) a stažení (download) dokumentu v jedné transakci se zachováním názvu dokumentu, pod kterým je uložen v úložišti DMS. | Závazný | Kompletně vyřešeno | |
Licenční politika (LIC) | |||||
ID | Název | Popis požadavku | Důležitost | Nabízený systém požadavek splňuje (výběr z hodnot)* | Požadavek bude realizován? (jen pro vítané)** |
LIC01 | Počet uživatelů | Celkový počet uživatelů pracujících přes webové rozhraní IS je 1500 a počet současně pracujících se předpokládá alespoň 150 uživatelů. | Závazný | Kompletně vyřešeno | |
LIC02 | Rozšiřitelnost počtu uživatelů | Systém musí být možné kontrolovaným způsobem rozšířit na 2000 uživatelů (z toho nejvýše 300 současně pracujících) při pokračující efektivní dostupnosti služby a to bez navýšení ceny výsledného SW řešení. Cena jednotlivých SW licencí nad rámec počátečního množství je garantována po dobu 4 let s ohledem na inflaci. | Závazný | Kompletně vyřešeno | |
LIC03 | Rozšiřitelnost počtu rolí | Systém musí mít zajištěny licence bez vlivu na změnu počtu rolí, například počtu administrátorů. | Závazný | Kompletně vyřešeno | |
LIC04 | Licenční podmínky | Dodavatel popíše licenční politiku a podmínky licencování celého řešení, včetně požadavků na zajištění licencí (např. databázových licencí apod.) ze strany objednatele. | Závazný | Kompletně vyřešeno | |
Školení (SKO) | |||||
ID | Název | Popis požadavku | Důležitost | Nabízený systém požadavek splňuje (výběr z hodnot)* | Požadavek bude realizován? (jen pro vítané)** |
SKO01 | Školení znalostí nutných k testování | Školení před akceptačními testy (cca 7 osob) spočívající v seznámení s funkcionalitou dodaného řešení DMS potřebnou k ověření testovacích scénářů. | Závazný | Kompletně vyřešeno | |
SKO02 | Školení administrace a konfigurace řešení DMS | Školení technických správců k administraci a konfiguraci dodaného řešení DMS (cca 2 zaměstnanci). | Závazný | Kompletně vyřešeno | |
SKO03 | Školení klíčových uživatelů | Školení klíčových uživatelů k detailní znalosti funkcionalit DMS - hlavních metodiků DMS (cca 16 zaměstnanců). | Závazný | Kompletně vyřešeno | |
SKO03 | Uživatelská příručka | Dodavatel dodá uživatelskou příručku pro všechny uživatelské role v systému v elektronickém formátu (MS Word/PDF) na CD nebo DVD. | Závazný | Kompletně vyřešeno | |
Ochrana důvěrných informací (ODI) | |||||
ID | Název | Popis požadavku | Důležitost | Nabízený systém požadavek splňuje (výběr z hodnot)* | Požadavek bude realizován? (jen pro vítané)** |
ODI01 | Uložení šifrovaných dokumentů | Systém musí umožnit uložení dokumentů, které jsou šifrovány v šifrovacím systému objednatele (viz příloha č.2a Technické zadání – kapitola 3.3. Integrace s MS AD RMS), včetně přiřazení všech metadat vázajících se k danému typu/kategorii dokumentu. | Závazný | Kompletně vyřešeno | |
ODI02 | Uložení dokumentů chráněných heslem | Systém musí umožnit uložení dokumentů, které jsou chráněny heslem, včetně přiřazení všech metadat vázajících se k danému typu/kategorii dokumentu. | Závazný | Kompletně vyřešeno | |
ODI03 | Spuštění workflow nad zašifrovanými dokumenty | Systém musí umět spustit workflow nad dokumenty, které jsou zašifrované nebo chráněny heslem. | Závazný | Kompletně vyřešeno | |
ODI04 | Ochrana osobních údajů | Systém bude obsahovat soubory/objekty obsahující osobní údaje a osobní údaje přebírané z ŘDB. Systém DMS proto musí splňovat veškeré legislativní požadavky na ochranu osobních údajů ve smyslu zákona č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů a být plně v souladu s platnou legislativou v této oblasti. | Závazný | Kompletně vyřešeno | |
ODI05 | Atribut pro klasifikaci informací obsažených v dokumentu | Každá šablona metadat k souboru/dokumentu musí obsahovat atribut „stupeň klasifikace“, který nabývá hodnot v souladu s vnitřním předpisem ČNB. Shoda klasifikace a oprávnění je kontrolována u každého přístupu bez ohledu na přístupová práva k dokumentu nastavená podle BEZ03 [bod (1) a (2)]. | Závazný | Kompletně vyřešeno | |
Ostatní (OST) | |||||
ID | Název | Popis požadavku | Důležitost | Nabízený systém požadavek splňuje (výběr z hodnot)* | Požadavek bude realizován? (jen pro vítané)** |
OST01 | Zobrazení průběhu práce na pozadí | Systém obsahuje grafický prvek, který uživateli znázorňuje průběh práce na pozadí při zpracování úlohy systémem (typicky ukládání dat nebo spouštění úlohy ve workflow apod.). | Závazný | Kompletně vyřešeno |
OST02 | Zajištění synchronizace času | Systém synchronizuje čas pomocí NTP. | Závazný | Kompletně vyřešeno |
*popis kompletnosti splnění funkčního požadavku v nabízeném řešení DMS: Kompletně vyřešeno
Částečně vyřešeno (to znamená, že dodavatel dovyvine v rámci dodávky funkcionalitu tak, aby byl požadavek kompletně vyřešen) Musí být kompletně nově vyvinuto
** vítané požadavky se v případě volby Ano stanou pro dodavatele závaznými
Kompletně vyřešeno | Ano |
Částečně vyřešeno | Ne |
Musí být kompletně nově vyvinuto |
ORGANIZACE A ŘÍZENÍ PROJEKTU
1.4. Personální složení projekčního týmu
1.5. Práva a odpovědnosti objednatele
1.6. Odpovědnosti poskytovatele
2.6. Akceptace dodávek projektu
1 Organizace projektu
Pro realizaci SW řešení DMS ustanoví smluvní strany společný Projekční tým, jehož členové mají níže definované kompetence při realizaci implementace SW řešení DMS v souladu s podmínkami uvedenými ve smlouvě.
Objednatel a poskytovatel se zavazují, že složení projekčního týmu se po celou dobu realizace projektu nebude měnit bez závažného důvodu a vzájemného odsouhlasení.
Projekční tým jedná pravidelně, v termínech stanovených vedoucím projektu objednatele, případně dle potřeby, na základě výzvy vedoucího projektu objednatele nebo poskytovatele. Jednání se musí zúčastnit za každou smluvní stranu alespoň vedoucí projektu nebo dva další členové projekčního týmu.
1.1 Řídicí komise
Řídicí pracovníci projektu a vedoucí projektu obou smluvních stran jsou jmenováni do společného orgánu s názvem Řídicí komise. Za stranu objednatele je navíc v Řídicí komisi zastoupen věcný zadavatel systému (dále „členové Řídicí komise“).
Řídící pracovníci projektu jsou osoby s rozhodovací pravomocí.
Předsedou Řídicí komise je řídící pracovník za stranu objednatele, který má následující povinnosti:
a) svolávat zasedání Řídicí komise ze své vůle nebo na základě návrhu člena Řídicí komise,
b) řídit jednání Řídicí komise,
c) rozhodovat na základě doporučení členů Řídicí komise v otázkách týkajících se projektu.
Každý člen Řídicí komise je oprávněn účastnit se jednání Řídicí komise osobně, případně pověřit účastí na jednání Řídicí komise svého zástupce.
Řídicí komise nemá žádný další nadřízený orgán projektu; přímými nadřízenými tomuto orgánu jsou statutární zástupci obou smluvních stran.
Řídicí komise je založena za účelem kontroly průběhu projektu a má následující kompetence:
a) kontrolovat průběh realizace plnění, zejména s ohledem na dodržování stanoveného harmonogramu a plnění jednotlivých fází vývoje,
b) projednávat připomínky každé ze smluvních stran k dodržování povinností druhé smluvní strany podle uzavřené smlouvy,
c) řešit případné spory vznikající v souvislosti s uzavřenou smlouvou,
d) řešit problémy eskalované z projekčního týmu,
e) schvalovat personální obsazení a změny personálního obsazení projekčního týmu,
1.2 Vedoucí projektu
Vedoucí projektu plní výkonnou roli Řídící komise ve vztahu k projekčnímu týmu. Vedoucí projektu mají následující práva a povinnosti:
a) zajišťují řízení, sledování a plánování úloh při realizaci projektu,
b) nastavují a dohlížejí na dodržování pravidel komunikace,
c) zastřešují povinnosti vyplývající ze vzájemné součinnosti obou stran na realizaci projektu
d) zajišťují svolání zasedání Řídicí komise v případě řešení sporů nebo problémů eskalovaných
z jednání projekčního týmu,
e) vykonávají rozhodnutí Řídicí komise učiněná v otázkách projektu.
1.3 Členové projekčního týmu
Členové projekčního týmu plní uložené úlohy související s realizací projektu ve stanovených termínech a v požadované kvalitě
1.4 Personální složení projekčního týmu
Za poskytovatele | AutoCont CZ a.s. | |
Řídící pracovník projektu | Xxxxxxx Xxxxxxxx | |
Vedoucí projektu | Xxxxxx Xxxxx | |
Členové projekčního týmu | Xxx Xxxxxxx | |
(Garanti SW řešení DMS) | Xxxxx Xxxxxxxx | |
architekt řešení/systémový | Xxxxxx Xxx | |
inženýr analytik/programátor odborný specialista/technik | Xxxxxx Xxx Xxxxx Xxxxxxxxx | |
... | ||
Za objednatele | Česká národní banka | |
Řídící pracovník projektu | Ing. Xxxxxxxx Mojžíšek | |
Vedoucí projektu | Xxx. Xxxxxxxxx Xxxxxxxxxxxx | |
Zástupce vedoucího projektu | Xxx. Xxxxx Xxxx | |
Věcný zadavatel | Xxx. Xxx Xxxxxx | |
Dílčí zadavatelé | XXXx. Xxx. Xxxxx Xxxxxxx Ph.D. Xxx. Xxx. Xxxxxx Xxxxx | |
Řídící pracovníci ze strany dílčího zadavatele | Xxx. Xxxx Xxxxxx, CIA Xxx. Xxxxx Xxxxxxxx MBA | |
Členové projekčního týmu | Xxx. Xxxxx Xxxxxxxx | |
(Garanti zadání) | Xxx. Xxxx Xxxxxx | |
XXXx. Xxxx Xxxxxxx | ||
další pracovníci objednatele dle | ||
povahy úloh v projektu |
1.5 Práva a odpovědnosti objednatele
Vedoucí projektu a členové projekčního týmu objednatele jsou odborní pracovníci s metodickými znalostmi týkajícími se nakládání s dokumenty v ČNB a souvisejícími znalostmi IT/IS, kteří garantují, že zadání DMS vyhovuje interním pokynům ČNB a dále požadavkům na nakládání s dokumenty orgánů a institucí EU/ESCB, popř. dalších vybraných mezinárodních organizací, v jejichž pracovních skupinách pracují zaměstnanci objednatele.
Členové týmu objednatele odpovídají za:
• formulaci požadavků na funkčnost a za správnost analytických zadání a stvrzují shodnost dodaného řešení (s případným výčtem chyb a návrhů) s analytickým zadáním/specifikací,
• poskytnutí veškerých dostupných podkladů nezbytných pro realizaci DMS, včetně údajů o standardním systémovém a databázovém prostředí objednatele, dokumentů a směrnic nebo jejich částí, které jsou klíčové pro realizaci DMS,
• technickou podporu realizace projektu, tzn. přípravu systémového prostředí pro instalaci SW řešení DMS,
• včasné a úplné odevzdání všech dohodnutých podkladů v dohodnutých termínech,
• vytvoření nezbytných pracovních podmínek v místě objednatele.
Vedoucí projektu objednatele má právo:
• kontrolovat postup všech prací prováděných poskytovatelem,
• rozhodovat při formulaci specifikací/analytických zadání dílčích úloh SW řešení směrem
k poskytovateli, v souladu s podmínkami uzavřené smlouvy.
1.6 Odpovědnosti poskytovatele
Členové projekčního týmu poskytovatele jsou odborní pracovníci se znalostmi dodávaného SW řešení, kteří garantují, že jsou schopni zajistit plnění zakázky v souladu se zadáním a splňují kvalifikační kritéria, která objednatel požadoval v kvalifikačních požadavcích zadávacího řízení.
Členové týmu poskytovatele odpovídají za:
• za správnou implementaci uživatelských požadavků na funkčnost DMS,
• v průběhu celého projektu za včasné a úplné odevzdání všech dohodnutých prací v dohodnutých termínech vedoucímu projektu objednatele.
Vedoucí projektu poskytovatele je odpovědný:
• za koordinaci činností související s projektem tak, aby výsledkem bylo včas realizované SW
řešení DMS, které bude obsahovat veškeré požadované vlastnosti.
Poskytovatel zajistí kompletní plnění dle smlouvy a související dokumenty v českém jazyce
v následujícím rozsahu:
Název dokumentace | Xxxxx | Xxxxxxxxxx osoba |
Školící materiály | Školící materiály pro školení znalostí nutných k testování, pro školení administrátorů a klíčových uživatelů. | Poskytovatel |
Uživatelská příručka | Uživatelská dokumentace popisující SW řešení DMS z pohledu všech existujících uživatelských rolí a funkcionality systému | Poskytovatel ve spolupráci s věcným zadavatelem ze strany objednatele |
Testovací scénáře | Testovací scénáře podle jednotlivých | Poskytovatel ve spolupráci |
uživatelských rolí v systému dle šablony v kapitole 8 v příloze č. 5. | s věcným zadavatelem ze strany objednatele | |
Administrátorská příručka | Administrátorská dokumentace obsahující: - popis web services, datových rozhraní, postupy konfigurace SW řešení DMS, technický popis a konfigurační soubory komponent systémového prostředí atd. | Poskytovatel ve spolupráci s objednatelem |
Příručka technického správce | Technická dokumentace obsahující popis: - instalace, správu bezpečnostních funkcí (účty, role, zálohování, audit logy) a seznam chybových zpráv s postupem dalšího řešení problému, pokud tyto činnosti nejsou součástí administrátorské příručky, - principů obnovy funkčnosti SW řešení DMS v případě havárií, apod. | Poskytovatel ve spolupráci s objednatelem |
2.1 Plánování projektu
2.2 Řízení projektu
Řízení projektu zahrnuje vlastní realizaci projektu, tj. koordinaci postupu prací na projektu, sledování, kontrolování, monitorování a dokumentování činností projektu a řízení změn. Hlavními aktivitami jsou: zadávání úloh zdrojům, vedení a řízení postupu práce, kooperace s členy týmů, kooperace s vedením, koordinace postupu prací na projektu, přijímání rozhodnutí při vzniku problémů atd.
Průběh projektu je řízen podle harmonogramu realizace projektu. Průběh projektu je pravidelně sledován a kontrolován.
Dokumentace průběhu projektu a projektových výstupů je vedena v souladu s postupem, který bude upřesněn a vzájemně odsouhlasen mezi poskytovatelem a objednatelem na prvních jednáních projekčního týmu.
Na prvním jednání projekčního týmu budou stanovena pravidla vzájemné komunikace. Veškerá komunikace bude probíhat tak, aby byli projektoví vedoucí informováni o všech probíhajících úlohách v projektu a jejich stavu. Každý měsíc bude souhrnný stav projektu prezentován řídícím pracovníkům projektu.
2.5 Přejímky
Přejímky dokumentů, výstupů, předmětů plnění zakázky budou probíhat v předem stanovených termínech podle harmonogramu projektu nebo v termínech písemně dohodnutých u vstupů, podkladů, dílčích výsledků.
• Předmět plnění (dílčí plnění) přebírá vedoucí projektu nebo jeho zástupce.
• Při předání bude zkontrolována kompletnost, případně fyzická neporušenost plnění zakázky (např. u dokumentů).
• Při akceptaci/předání bude sepsán akceptační/předávací protokol podepsaný oprávněnými zástupci obou stran.
• Předávací protokoly budou archivovány v písemné i elektronické podobě a budou uloženy jak
u objednatele, tak u poskytovatele.
2.6 Změnové řízení
I po podpisu smlouvy a vytvoření realizační studie může dojít k potřebě změn (přehodnocení priority stávajících požadavků, kvalitativní změna dohodnutého rozsahu prací). V takovém případě je nutno vypracovat žádost o změnu a zahájit změnové řízení. Poskytovatel zhodnotí důsledky těchto změn na projekt podle pravidel popsaných v následujících odstavcích.
Změnové řízení se týká zejména:
• změn termínů dodávek prací bez dopadu na konečný termín dodávky uvedený ve smlouvě,
• kvalitativních a kvantitativních změn dohodnutého rozsahu prací.
Posouzení závažnosti změn provádí vedoucí projektu na základě podkladů vypracovaných projekčním týmem.
Změnové řízení může být iniciováno jak objednatelem, tak poskytovatelem a realizováno jedině na základě společného písemného rozhodnutí smluvních stran.
Pro řešení realizovaná v rámci změnového řízení platí všechna ustanovení uzavřených smluv mezi
objednatelem a poskytovatelem.
2.7 Žádost o změnu
Žádost o změnu může předložit kterýkoliv člen projekčního týmu. Každá žádost o změnu se stává součástí projektové dokumentace. Žádost bude předána vedoucímu projektu. Všechny žádosti o změnu jsou archivovány v elektronické i písemné podobě.
2.8 Vyhodnocení žádosti o změnu
Vedoucí projektu poskytovatele ve spolupráci s vedoucím projektu objednatele přehodnotí, a je-li to
nezbytné, revidují potřebu žádosti o změnu, a určí její prioritu a cílové datum řešení.
Během vyhodnocení bude zkoumán dopad změny a úlohy nezbytné k jejímu provedení. Bude určeno, jak změna ovlivní projekt z hlediska rozsahu a výstupů a budou definovány požadované zdroje na její realizaci na straně poskytovatele a na straně objednatele, termín realizace změny včetně změn termínů souvisejících nebo návazných úloh. Rovněž bude posouzen dopad případného neprovedení změny.
2.9 Vyřešení žádosti o změnu
Vedoucí projektu vypracují doporučení ke každé žádosti o změnu. Pokud změna neovlivní zásadním způsobem rozsah projektu a smluvní termíny/lhůty, rozhodnou vedoucí projektu na základě společné dohody o provedení nebo zamítnutí změny.
V případě, že se jedná o zásadní změnu, připraví vedoucí projektů podrobný odhad skutečných dopadů
a se svým doporučením předají žádost k rozhodnutí řídícímu pracovníkovi projektu objednatele.
Po schválení zásadní změny bude zahájeno projednání změny smlouvy formou dodatku ke smlouvě. Změna bude účinná účinností dodatku.
Po realizaci změny bude objednateli předána upravená dokumentace a nová verze DMS v elektronické podobě na dohodnutém médiu.
2.10 Akceptace dodávek projektu
K akceptaci jednotlivých etap provádění díla dojde po akceptačním řízení dle článku IV smlouvy a přílohy č. 5 smlouvy podpisem akceptačního protokolu/předávacího protokolu, který podepíše na straně objednatele vedoucí projektu a věcný zadavatel a na straně poskytovatele vedoucí projektu, pokud smluvní strana nepověří písemně jinou osobu.
Šablona realizační studie
Projekt 7010/2016
„SW řešení DMS“
Realizační studie
Verze | |
Datum verze | |
Autor | |
Vedoucí projektu poskytovatele | |
Vedoucí projektu objednatele |
Tento dokument obsahuje informace důvěrného charakteru a informace v něm obsažené jsou vlastnictvím České národní banky. Žádná část dokumentu nesmí být kopírována, uchovávána v dokumentovém systému nebo přenášena jakýmkoliv způsobem včetně elektronického, mechanického, fotografického či jiného záznamu a uveřejněna či poskytnuta třetí straně bez předchozí dohody a písemného souhlasu vlastníků.
Některé názvy použité v tomto dokumentu mohou být registrovanými ochrannými známkami nebo obchodními značkami, které jsou majetkem svých vlastníků.
Historie změn
Verze | Datum | Autor | Popis změny |
Obsah
1.3 Přehled použitých symbolů 4
2.2 Mapování uživatelského rozhraní na klíčové procesy 5
2.4 Analýza vybraných požadavků 5
2.5 Celkový přehled funkcionalit SW řešení DMS 5
3 Technická realizace SW řešení DMS 6
3.1 Výchozí situace a cílový stav 6
3.2 Návrh architektury technického řešení 6
3.5 Požadavky na systémové prostředí 6
3.6.2 Autentizace a autorizace 7
3.8 Instalace, podpora a údržba 7
4 Návrh projektové realizace 7
4.2 Detailní harmonogram realizace 8
4.4 Akceptační testovací scénáře 8
1.1 Účel dokumentu
1.2 Seznam pojmů a zkratek
[Výčet klíčových zkratek a pojmů s jejich vysvětlením - možno použít tabulku v příloze 9 smlouvy]
Termín/Zkratka | Popis/Význam |
[Popis použitých grafických symbolů v dokumentu]
Grafický symbol | Význam |
2.1 Analýza procesů
[Kapitola obsahuje analýzu procesů uvedených v kapitole 5 přílohy č.1a smlouvy, pro jejich grafické znázornění lze použít buď UML Activity diagram, nebo BPMN (Business Process Model and Notation)].
2.2 Mapování uživatelského rozhraní na klíčové procesy
[Kapitola obsahuje mapování grafického uživatelského rozhraní SW řešení DMS na procesy uvedené v kapitole 5 přílohy č.1a smlouvy tak, aby šlo ověřit pracovní postup koncových uživatelů v rámci zadaného pracovního procesu resp. postupu a to pro všechny uživatelské role a oprávnění.
Zobrazení jednotlivých formulářů a grafických obrazovek musí být doplněno o popis jednotlivých
vstupně/výstupních polí a funkčních tlačítek (může být řešeno odkazem na existující dokumentaci)].
Název prvku | Význam | Příznak | Formát | Poznámka |
Legenda:
Název: Zobrazený název I/O atributu (vstupně/výstupní pole, tlačítko) Význam: Slovní popis významu atributu
Příznak: RO - pouze pro čtení, P - povinná editovatelná, N - nepovinná editovatelná Formát: popis zobrazeného formátu (např. dd.mm.yyyy)
Poznámka: popis upřesňující informace (např. odkaz na validace]
[Kapitola obsahuje mapování požadavků objednatele na cílové SW řešení DMS. Popis tak ve stručné formě představuje způsob realizace jednotlivých funkčních a specifických požadavků uvedených v přílohách č. 1b a 2b smlouvy]
ID1 | Popis požadavku | Název funkcionality | Poznámka |
2.4 Analýza vybraných požadavků
[V této kapitole je detailně popsána analýza požadavků objednatele, které jsou částečně v dodávaném řešení realizovány nebo je nutné je v dodávaném řešení teprve vyvinout (viz přílohy č. 1a, 1b, 2a a 2b smlouvy), například formou případů užití (Use Case) nebo návrhu grafického rozhraní, a to takovým stylem, aby byla jednoznačně prokázána realizovatelnost požadavků.]
2.5 Celkový přehled funkcionalit SW řešení DMS
[Kapitola obsahuje přehled všech funkcionalit dodávaného řešení nebo odkaz na příslušnou uživatelskou dokumentaci. Jednotlivé funkcionality jsou rozděleny do kapitol dle logických oblastí například: správa oprávnění/rolí, definice šablon, konfigurace WF, atd.]
1 ID požadavku objednatele použité v příloze 1b nebo 2b smlouvy
[Kapitola obsahuje základní popis dodávaného řešení mobilní aplikace DMS.]
3 Technická realizace SW řešení DMS
3.1 Výchozí situace a cílový stav
[Kapitola stručně popisuje výchozí a cílový stav navrhované architektury řešení popsaný v následujících kapitolách.]
3.2 Návrh architektury technického řešení
[Kapitola popisuje globální architekturu IS a fyzickou architekturu nasazení aplikace v infrastruktuře objednatele s ohledem na provoz, monitoring, zálohování a archivaci aplikace vzhledem k vybrané variantě implementace do systémového prostředí ČNB]
[Kapitola obsahuje:
- popis možností integrace SW řešení DMS s jednotlivými stávajícími a budoucími aplikacemi
ČNB
- kompletní aplikační programové rozhraní (API), použité web services, metody a příklady použití SW řešení
- detailní popis rozhraní pro pravidelné, automatizované předávání a přebírání dat z/do SW řešení DMS do/z IS ČNB.]
[Kapitola obsahuje analýzu a namapování datových struktur obou systémů (IS Obelisk a IS DMS) z hlediska jejich převoditelnosti a datové migrace (tj. jednoznačné srovnání dat – dokumentů a jejich metadat, které budou využívány při migraci dat mezi oběma systémy) a popis vlastní migrace.
Na analýze se podílejí jak zadavatel ze strany objednatele a techničtí a věcní správci dotčených
systémů, tak poskytovatel.]
3.5 Požadavky na systémové prostředí
[Kapitola obsahuje SW specifikaci pro nasazení v prostředí ČNB. Součástí je i sizing HW prostředků pro účely implementace systému, který je shodný s popisem uvedeným v nabídce SW řešení. Pokud se architektura prostředí liší pro test a pro provoz, jsou tato prostředí popsána zvlášť]
Tabulka 1: HW specifikace
Prvek | Typ | Výkon | RAM | Disková kapacita | Síťové rozhraní | Poznámka |
Např.:APP1 | Virtuální server | 2 – 4 virtuální CPU, | 4 – 8 GB | 15 GB | 100 Mbps | |
2 – 3 | ||||||
GHz | ||||||
Tabulka 2: SW specifikace
Prvek | OS | Databázové služby | Aplikační služby | Poznámka |
Např.:APP1 | Windows Server 2008 R2 ENG x64 | Oracle client 12c | MS IIS 7.5 XXX.XXX 3.5 SP1 | |
[Kapitola obsahuje popis aplikace z hlediska její bezpečnosti, integrity a důvěrnosti dat v souladu s
metodikou ČNB – šablona bezpečnostního profilu bude poskytovateli předána objednatelem]
3.6.1 Analýza rizik
[Podkapitola obsahuje analýzu rizik bezpečnosti informací včetně posouzení rizik podle § 13 odst. 3 zákona č. 101/2000 Sb., o ochraně osobních údajů.]
3.6.2 Autentizace a autorizace
3.6.3 Logování
[V podkapitole je popsán způsob logování a monitorování logů]
[Kapitola shrnuje identifikované standardy a normy používané při realizaci SW řešení DMS.]
3.8 Instalace, podpora a údržba
[Kapitola obsahuje:
- postup nasazení SW řešení DMS do cílového prostředí s ohledem na stanovení příslušné součinnosti ze strany ČNB,
- popis podpory a údržby SW řešení ze strany poskytovatele.]
4.1 Výstupy projektu
[Tabulka obsahuje seznam vytvářených klíčových výstupů s plánovaným termínem jejich odevzdání, termíny musí být v souladu s hlavními termíny definovanými ve smlouvě a harmonogramem uváděným v kapitole 4.2]
Název | Popis | Plánovaný termín dodání |
Legenda
Název: Název dokumentu např. Realizační studie Popis: Stručný popis obsahu dokumentu
Plánovaný termín dodání: termín dodání
4.2 Detailní harmonogram realizace
[Harmonogram realizace uvádí rozpad realizace projektu do jednotlivých etap a činností tak, aby mohly být dodrženy smlouvou stanovené lhůty. Harmonogram musí obsahovat milníky pro předání etap k akceptačnímu řízení]
[V kapitole je uveden rozsah kapacit požadovaných poskytovatelem po objednateli]
ID | Popis součinnosti | Rozsah | Čerpání |
Legenda:
ID: Jedinečný identifikátor požadované součinnosti
Popis součinnosti: popis aktivit, požadovaných poskytovatelem po objednateli
Rozsah: odhadovaný rozsah požadovaných kapacit v čld
Čerpání: četnost, způsob čerpání kapacit např. 1x týdně; 2hod v Pá
4.4 Akceptační testovací scénáře
[V kapitole je popsán seznam všech připravovaných akceptačních testovacích scénářů, které kompletně ověří požadovanou funkcionalitu systému]
ID scénáře | Testovaná oblast | Testovací scénář | ID požadavku |
Legenda
ID scénáře: Jedinečný identifikátor testovacího scénáře
Testovaná oblast: Oblast testování např.: Workflow pro připomínkování, Vyhledávání, … Testovací scénář: Popis testovacího scénáře
ID požadavku: Jedinečné identifikátory požadavků objednatele použité v příloze 1b nebo 2b smlouvy, které jsou
daným testovacím scénářem ověřovány.
[Kapitola detailněji popisuje způsob zajištění školení a proškolení příslušných pracovníků]
AKCEPTAČNÍ ŘÍZENÍ
6. Šablona akceptačního protokolu
7. Šablona předávacího protokolu
8. Šablona testovacích scénářů
1 Úvod
Akceptační řízení v rámci projektu bude probíhat pro jednotlivé etapy takto:
a) etapa 1, tj. realizační studie - podle metody popsané v článku 2.1 této přílohy
b) etapa 2 a 3 nebo v případě realizace mobilní aplikace/mobilní řešení DMS podle čl. I odst. 3 - podle metody popsané v článku 2.2 této přílohy
Akceptační řízení prověří, zda dodané řešení splňuje všechny příslušné požadavky uvedené v přílohách č. 1b a 2b smlouvy, ke kterým se poskytovatel zavázal, tj. všechny závazné požadavky a vítané požadavky, které poskytovatel potvrdil realizovat a popsal jejich řešení v dokumentu
„Realizační studie“. Dále bude ověřeno, zda byly splněny i ostatní požadavky uvedené v této smlouvě a systém DMS je možné převzít objednatelem do ověřovacího provozu. Akceptační řízení také zahrnuje formální prověření předávané technické a provozní dokumentace, tzn. uživatelské příručky, administrátorské příručky, příručky technického správce, popisu web services, popř. API, dále podkladů k provoznímu řádu a havarijnímu plánu a dokumentace k akceptačním testům.
Za přípravu testovací scénářů zodpovídá poskytovatel a potřebnou kontrolu a součinnost poskytne
objednatel.
2 Metoda
Při akceptačním řízení se bude postupovat následovně:
2.1
2.2
Akceptace etapy 1 – realizační studie
a) Objednatel je oprávněn vždy max do 10 pracovních dnů od předložení studie uplatnit připomínky písemně (v analogové formě nebo elektronicky) zasláním na kontaktní osobu poskytovatele.
b) Poskytovatel je povinen zapracovat vznesené připomínky do 5 pracovních dnů od jejich obdržení.
c) Připomínkové řízení k akceptační studii může být zopakováno max 3x.
d) Realizační studie může být akceptována pouze s výsledkem „Akceptováno“ – viz kapitola 6 – Šablona akceptačního protokolu.
Akceptace etapy 2, 3 nebo dodání mobilní aplikace/mobilní řešení DMS
a) Testování se bude provádět pod účty jednotlivých procesních/uživatelských rolí a nikoliv pod účtem systémového administrátora, aby se projevily případné nekonzistence z hlediska přístupových práv apod.
b) Testovací scénáře u opakovaných testů, u kterých objednatel potvrdí, že jsou v pořádku, se
nemusí, např. kvůli časové náročnosti, provádět.
c) Testy budou klasifikovány buď „bez vad“ nebo „s vadou typu A/B/C“ (viz. kapitola č. 4
této přílohy).
d) Pokud dojde při testování k závadě, která zabrání pokračování dokončení testů, budou akceptační testy ukončeny, a po odstranění vady zopakovány.
e) Vady zjištěné v průběhu akceptačního řízení (pro testovací i provozní prostředí) bude objednatel sdělovat poskytovateli průběžně. Poskytovatel bude tyto vady odstraňovat neprodleně tak, aby akceptační řízení mohlo být ukončeno ve stanovené lhůtě.
f) Součástí akceptačního řízení je provedení penetračních testů v provozním prostředí DMS, jejichž náklady hradí objednatel. Nalezené vady odstraňuje poskytovatel na vlastní náklady.
g) Při výskytu vad typu B a C, u kterých došlo k dohodě mezi poskytovatelem a
objednatelem, že budou odstraněny později, je možné v akceptačních testech pokračovat.
3 Předpoklady
3.1 Akceptace etapy 2
Akceptační testy etapy 2 lze provádět pouze tehdy, budou-li splněny následující předpoklady.
• Bude k dispozici testovací prostředí s kompletně dokončeným nastavením SW řešení DMS
pro akceptační testy.
• Budou předány následující dokumenty:
o Akceptovaná realizační studie.
o Uživatelská příručka.
o Testovací scénáře (viz kap. 8 této přílohy).
o Administrátorská příručka.
o Příručka technického správce.
• Budou připraveny školící materiály a bude provedeno školení uživatelů a administrátorů
v rozsahu požadovaném pro akceptaci.
3.2 Akceptace etapy 3
Akceptační testy etapy 3 lze provádět pouze tehdy, budou-li splněny následující předpoklady.
• Bude k dispozici provozní prostředí s kompletně dokončeným nastavením SW řešení DMS.
• Budou zcela odstraněné vady uvedené v akceptačním protokolu etapy 2.
• Bude dokončena migrace určených dat (souborů a metadat) včetně provedení post-migračních kroků vedoucích ke konzistenci metadat a souladu s funkcionalitou dodaného SW řešení DMS.
• Bude předána aktualizovaná dokumentace z etapy 2.
• Budou vytvořeny a předány podklady k provoznímu řádu a havarijnímu plánu.
3.3 Akceptace mobilní aplikace/mobilní řešení DMS
Akceptační testy mobilní aplikace/mobilní řešení DMS lze provádět pouze tehdy, budou-li splněny následující předpoklady.
• Bude k dispozici provozní prostředí s kompletně dokončeným nastavením mobilní aplikace řešení DMS pro akceptační testy.
• Budou předány následující dokumenty:
o Uživatelská příručka pro mobilní aplikaci
o Testovací scénáře pro mobilní aplikaci (viz kap. 8 této přílohy).
o Administrátorská příručka pro mobilní aplikaci.
o Příručka technického správce mobilní aplikace.
4 Kategorizace vad
Kategorizaci vad provádí objednatel. Pokud poskytovatel nebude souhlasit se zařazením vady do určité kategorie a vznese námitku proti jejímu zařazení, rozhoduje o námitce s konečnou platností objednatel.
Jsou stanoveny tyto kategorie vad:
A – Kritická vada - velmi vážná vada, která znemožňuje práci se systémem nebo nesplňuje funkční zadání, tzn., že splňuje alespoň jednu z níže uvedených charakteristik:
a) vada v požadovaném dokumentu:
• chybějící textová část vyplývající z definované struktury,
• textová část neodpovídá skutečnosti popisované entity (např. systému, procesu, chybové zprávě),
b) vada SW řešení:
• způsobuje tak závažné problémy, že další vývoj ani dodržení dohodnutého časového plánu nejsou možné,
• nedodržení či neprokázání realizace nebo jen částečná realizace požadavku uvedeného ve smlouvě a jejích přílohách,
• znemožňuje používání dodaného řešení jako celku nebo znemožňuje používání základních funkcí dodaného řešení podle jeho dokumentace,
• zapříčiňuje nemožnost používání nebo ovládání dodaného řešení
• zapříčiní ztrátu dat nebo úplně znemožní užití dodaného řešení,
• způsobuje, že použití dodaného řešení by nebylo bezpečné nebo by plně neodpovídalo zásadám bezpečnostní politiky objednatele,
• ohrožuje provoz nebo dostupnost ostatních aplikací i samotného dodaného řešení v provozním prostředí objednatele,
• způsobuje, že dodané řešení není schopno pracovat při běžné provozní zátěži, tj. při současném přístupu alespoň 150 uživatelů,
• za provozních podmínek vede k omezení funkcionality systému s dopadem na významný počet uživatelů, projevuje se stále, občas nebo náhodně a splňuje některou z výše popsaných charakteristik.
B – Podstatná vada - vada, kterou je možno dočasně vyřešit organizačním či jiným opatřením, tzn.,
že splňuje alespoň jednu z níže uvedených charakteristik:
a) vada v požadovaném dokumentu:
• nejednoznačnost textové části,
b) rozpor s některým z povinných požadavků na systém (příloha č. 1b Funkční požadavky a
příloha č. 2b Specifické požadavky) - vada SW řešení:
• je možné pro její překonání nalézt odpovídající alternativu, která je akceptovatelná
objednatelem,
• způsobuje, že dodané řešení není schopno zpracovat maximální provozní zátěž, tj. při současném přístupu alespoň 150 uživatelů,
• projevuje se stále, občas nebo náhodně a splňuje některou z výše popsaných charakteristik.
C – Nepodstatná vada - drobná vada, která nemá vliv na provoz systému, tzn. že splňuje alespoň
jednu z níže uvedených charakteristik:
a) vada v požadovaném dokumentu:
• je způsobena gramatickou chybou, nevhodným formátováním, překlepy apod.,
b) vada SW:
• je způsobená drobnými konstrukčními nedostatky,
• je pouze „kosmetického“ charakteru,
• projevuje se stále, občas nebo náhodně a splňuje některou z výše popsaných charakteristik.
5 Akceptační testy
O zahájení akceptačního řízení požádá poskytovatel objednatele písemně minimálně 5 pracovních dnů před termínem započetí akceptačního řízení. Akceptační řízení započne předložením potřebných podkladů k předmětu akceptace.
5.1 Hodnocení
Výsledky jednotlivých testů budou hodnoceny:
• Bez vad
• S vadou
Vady v rámci hodnocení „S vadou“ budou klasifikovány dle kapitoly č. 4 této přílohy, tzn.:
• A – Kritická
• B – Podstatná
• C – Nepodstatná
V případě výskytu stejné vady v různých místech SW řešení DMS budou tyto vady posuzovány jako jedna a táž vada.
Vady způsobené neodborným zásahem uživatele objednatele nemohou být klasifikovány jako závady. Kromě toho je možné oznámit/připomínkovat poskytovateli případné vedlejší efekty SW řešení DMS
a nedostatky zjištěné mimo akce popsané v akceptačních testech. Tyto nedostatky je objednatel
oprávněn klasifikovat podle kategorie vad.
5.2 Akceptace
Akceptační řízení bude považováno za ukončené pouze tehdy, pokud nebude obsahovat žádnou vadu,
nebo nerozhodne-li se objednatel přijmout předmět akceptace s výhradami.
Akceptaci s výhradami nelze provést, pokud existuje více jak 5 vad kategorie B nebo více jak 10 vad kategorie C. V případě akceptace s výhradami bude přílohou akceptačního protokolu seznam vad včetně lhůty k odstranění každé jednotlivé vady.
5.3 Náležitosti akceptačního protokolu
Po ukončení akceptačního řízení bude vytvořen akceptační protokol, který vystaví objednatel. Akceptační protokol musí obsahovat:
• Předmět akceptace
• Seznam akceptačních scénářů (pokud v rámci dané etapy/dílčího plnění existují).
• Výsledky jednotlivých testů včetně dílčích hodnocení.
• Závěr s celkovým hodnocením.
K akceptačnímu protokolu vyhotovenému objednatelem vyjádří poskytovatel své stanovisko nejpozději do 3 pracovních dnů od jeho obdržení. Pokud tak neučiní, má se za to, že s uvedeným závěrem souhlasí.
6 Šablona akceptačního protokolu
Akceptační protokol
Poskytovatel | Objednatel |
Česká národní banka | |
Na Příkopě 28 | |
115 03 Praha 1 | |
IČO: | IČO: 48136450 |
DIČ: | DIČ: CZ48136450 |
Evidenční číslo smlouvy v ČNB: | |
Název smlouvy: | |
Předmět akceptace: |
Závěr akceptačního řízení
Shrnutí obsahu akceptačního řízení.
Z výše uvedených důvodů bylo akceptační řízení uzavřeno s výsledkem:
Neakceptováno/Akceptováno s výhradami/Akceptováno
Následné kroky, např.: Poskytovatel akceptoval uvedené vady s tím, že odstraní vady uvedené v příloze č.1 akceptačního protokolu do ........
Poskytovatel prohlašuje, že poskytl veškeré potřebné licence pro …. … ( SW řešení DMS
/mobilní aplikaci DMS).
V Praze dne .....................
Za poskytovatele:
...................................., vedoucí projektu
…………………………………
Podpis
Za objednatele:
...................................., věcný zadavatel
…………………………………
Podpis
...................................., vedoucí projektu
…………………………………
Podpis
Akceptační protokol – Příloha č.1
Seznam vad
ID | Kategorie | Popis vady |
7 Šablona předávacího protokolu
Předávací protokol
Poskytovatel | Objednatel |
Česká národní banka | |
Na Příkopě 28 | |
115 03 Praha 1 | |
IČO: | IČO: 48136450 |
DIČ: | DIČ: CZ48136450 |
Evidenční číslo smlouvy v ČNB: | |
Název smlouvy: | |
Důvod předání: |
Předmět předání
Dnešního dne poskytovatel předal a objednatel převzal dílo podle čl. I odst. … smlouvy
včetně následující dokumentace:
•
•
•
V Praze dne .......................................
Za poskytovatele:
...................................., vedoucí projektu
…………………………………
Podpis
Za objednatele:
...................................., věcný zadavatel
…………………………………
Podpis
...................................., vedoucí projektu
…………………………………
Podpis
8 Šablona testovacích scénářů
Projekt 7010/2016 “SW ŘEŠENÍ DMS“
Testovací scénáře
Verze | |
Datum poslední modifikace | |
Autor | |
Vedoucí projektu poskytovatele | |
Vedoucí projektu objednatele |
Tento dokument obsahuje informace důvěrného charakteru a informace v něm obsažené jsou vlastnictvím České národní banky. Žádná část dokumentu nesmí být kopírována, uchovávána v dokumentovém systému nebo přenášena jakýmkoliv způsobem včetně elektronického, mechanického, fotografického či jiného záznamu a uveřejněna či poskytnuta třetí straně bez předchozí dohody a písemného souhlasu vlastníků.
Některé názvy použité v tomto dokumentu mohou být registrovanými ochrannými známkami nebo obchodními značkami, které jsou majetkem svých vlastníků.
Historie změn
Verze | Datum | Autor | Popis změny |