Document management systém

STÁTNÍ TISKÁRNA CENIN, státní podnik (dále také jen „STC“ nebo „Podnik“) chce zavést Document management systém (dále také jen DMS). 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 schvalovaní uvnitř Podniku, 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. DMS je určen pro celý Podnik, pro nejčastější procesy, které se průřezově týkají podpůrných činností, které Podnik musí zajistit pro své fungování.

Podnik je organizačně rozdělen na šest základních částí – Výrobní, Obchodní, Provozně technickou, Bezpečnostní, Finanční a Bezpečnostní. Využití DMS je plánováno zejména pro nevýrobní části Podniku. 400 zaměstnanců celého Podniku se podílí na všech procesech, které zajišťují produkci pro jeho klienty. Do DMS bude zapojeny cca 200 zaměstnanců, kteří mají přístup k pracovním PC stanicím a podílí se na procesech, pro které je primárně DMS určeno. Vysoký důraz je kladen na minimalizaci fyzické administrace úkonů, které jsou každodenní součástí běhu Podniku.

Součástí dodávky DMS je Dodavatel povinen dodat rovněž systém Spisové služby.

2Funkční požadavky DMS (a spisovou službu)

V této části zadávací dokumentace jsou uvedeny Agendy, které je povinen Dodavatel implementovat v rámci dodávky DMS (agendy definované v kapitolách 2.1 – 2.10). Agendu uvedenou v kapitole 2.8, 2.9 a 2.10 implementuje Dodavatel v rámci školení se Zadavatelem (rámcová podpora jako zaškolení zaměstnanců Zadavatele).

Zadavatel bude v rámci implementačního projektu pořizovat skenovací pracoviště, prostřednictvím kterého bude pořizovat digitální dokumenty došlé ve fyzické podobě na adresy Zadavatele.

2.1Spisová služba

Výkon spisové služby – zajištění odborné správy všech dokumentů vzniklých z činnosti původce; za dokument vzniklý z činnosti původce se považuje rovněž dokument, který byl původci doručen nebo jinak předán.

Zadavatel v součastnosti provozuje Spisovou službu v režimu listinných dokumentů. V brzké budoucnosti ale plánuje přechod na Digitální režim. Proto požaduje, aby Systém DMS splňoval nároky eIDAS (zák. č. 297/2016 Sb.).

Funkce agendy Spisová služba minimálně zahrnuje:

řádný příjem dokumentů v podatelně, včetně jejich označování otiskem podacího razítka a jednoznačným identifikátorem;
evidenci dokumentů v základní evidenční pomůcce a samostatné evidenční pomůcce, včetně označování číslem jednacím nebo evidenčním číslem ze samostatné evidence dokumentů;
rozdělování a oběh dokumentů;
vyřizování dokumentů, včetně přidělení spisového znaku, skartačního znaku a zákonné / definované lhůty;
vyhotovování dokumentů;
podepisování dokumentů a užívání úředního razítka;
odesílání dokumentů;
ukládání dokumentů ve spisovně, včetně kontroly dokumentů a spisů;
vyřazování dokumentů ve skartačním řízení, postup a podrobnosti;
Kontrola výše uvedených činností.

STC je veřejnoprávní původce podle § 3, ODSTAVEC 1 ZÁKONA Č. 499/2004 Sb. a musí dodržovat zákony a vyhlášky spojené s výkonem spisové služby:

Zákon č. 499/2004 Sb., o archivnictví a spisové službě a o změně některých zákonů, ve znění pozdějších předpisů
Vyhláška č. 259/2012 Sb., o podrobnostech výkonu spisové služby, ve znění pozdějších předpisů
Národní standard pro elektronické systémy spisové služby, účinný od 4.7.2017,
Zákon č. 300/2008 Sb., o elektronických úkonech a autorizované konverzi dokumentů, ve znění pozdějších předpisů
Vyhláška č. 193/2009 Sb., o stanovení podrobností provádění autorizované konverze dokumentů
Vyhláška č. 194/2009 Sb., o stanovení podrobností užívání a provozování informačního systému datových schránek, ve znění pozdějších předpisů

Veřejnoprávní původci uvedení v zákoně č. 499/2004 Sb. § 3 odst. 1 písm. e), g), h), j) a l) a obce vykonávají spisovou službu v elektronické podobě v elektronických systémech spisové služby nebo v listinné podobě. Všechny systémy pro správu dokumentů (ISSD) provozované původcem musí plnit požadavky Národního standardu, avšak mohou je plnit i tak, že jsou integrovány s centrálním (z hlediska původce) provozovaným eSSL. V tom případě musí vzájemné integrační rozhraní plně podporovat požadavky a funkce podle kapitoly č. 9 Národního standardu pro elektronické systémy spisové služby.

2.2Žádanka

Žádanka je interní dokument, který zahajuje proces zejména objednávání, tedy je to vystavení a schválení žádanky na pořízení služby, materiálu, investice apod. Ukázka aktuálně využívaného formuláře žádanky je uvedena v příloze 01.

Žádanka (pro objednání) má následující klíčové vlastnosti / informace:

Datum vystavení;
Xxxxx Xxxxxxxx, včetně informace o jeho nákladovém středisku, tedy kdo žádá, ale také zejména pro jaké nákladové středisko v Podniku žádá (musí být schváleno správcem nákladového střediska);
K jakému účelu je Žádanka vystavena (včetně základního popisu Žadatele);
Datum zařazení Žádanky do procesu schvalování;
Typ materiálu či služby – množství, typ materiálu / služby (kód), popis, cena za jednotku, cena celkem (při exportu z DMS zpracovatelné v MS Excel);
Zdůvodnění potřeby nákupu / pořízení;
Termín dodání;
Účel použití;
Další dokumenty související s objednáním (přílohy), MS Office / PDF;
Dodací podmínky (místo dodání, čas, popř. další poznámky);
Xxx Xxxxxxx vystavil (jméno, datum, autorizace - podpis);
Kdo schvaluje Žádanku (jméno, datum, autorizace - podpis).

Požadované minimální vlastnosti Žádanky jsou:

Schvalovací proces dle nastavení ve vnitropodnikové dokumentaci; resp. dle definovaného workflow, dle finančních limitů;
Zajištění verzování Žádanky (zajištění historie Žádanky);
Bezpečné uložení Žádanky (včetně interně zrušeného, zamítnuté Žádanky);
Propojení na číselníky výrobního programu Cicero v oblasti skladového hospodářství;
Možnost vytištění schvalovacího procesu Žádanky do PDF formátu;
Sledování plnění Žádanky, tzn. uzavření objednávky po dodání materiálu / služby;
Zajištění emailového alertu při prodlení schvalování v rámci Podniku, resp. informace o nevypořádaných Žádankách;
Eskalace schvalovacího procesu Žádanky, tzn. na organizační úroveň n+1;
Přiřazení jednoznačného identifikátoru pro Žádanku (číselná řada), nesmí se číslo opakovat;
Možnost zasílat Žádanku pouze elektronicky (emailem);
Fultextové vyhledávání a filtrování dle kategorií Žádanky a dalších atributů Žádanky;
Zastupování, resp. eskalace Žádanky v rámci organizačního řádu;
Schvalování Žádanky dle vnitřního předpisu Řádu oběhu a schvalování dokladů;
Možnost přiložení příloh v podobě dodatečných souborů ve formátu MS Office, PDF;
Sledování celkového procesu Žádanky – založení, schválení, plnění (i postupné), dodání/vypořádání;
Žádanka se po schválení mění na oficiální objednávku, viz dále v textu.

Schvalovací proces dle limitů odpovědnosti a dle přiřazených rolí. Potřeba nastavení standardního procesu schvalování dle řídící dokumentace (Řád oběhu schvalování dokladů, resp. ukázka úrovně zpracování, viz přílohu 02).

Počet žádanek v Podniku je cca 5 000 ks /rok.

2.3Objednávka

Objednávka je pokračováním Žádanky po interním schválení, kdy oddělení Nákupu (dále také UNL) připraví oficiální objednávku za STC vůči Dodavateli (nový nebo stávající smluvní partner) a zašle Objednávku externímu subjektu (Dodavateli).

Objednávka musí plnit následující minimální klíčové vlastnosti / informace (bez uvedených informací není možné Objednávku vystavit, finalizovat a zaslat Dodavateli):

Dodavatel (název, adresa, provozovna, IČO, DIČ, kontaktní údaje – tel. email);
Předmět objednávky – kód materiálu / služby, popis, množství, částka za jednotku, cena celkem;
Doprovodný text;
Dodací podmínky;
Kontaktní údaje na straně Podniku, tzn., kdo vystavil objednávku – jméno, email, telefon;
Přílohy, např. výkresová dokumentace v MS Office, PDF formátu.

Požadované minimální vlastnosti agendy Objednávka tedy jsou:

Objednávka vychází ze schválené Žádanky, tzn., dochází k překlopení informací ze Žádanky do Objednávky;
Schvalovací proces dle nastavení ve vnitropodnikové dokumentaci; resp. dle definovaného workflow, dle finančních limitů;
Zajištění verzování Objednávky (zajištění historie dokumentu);
Propojenost účetního systému (RIS) v oblasti číselníku společností;
Bezpečné uložení Objednávky;
Možnost vytištění schvalovacího procesu, vč. do PDF formátu;
Sledování plnění Objednávky, tzn. uzavření objednávky po dodání materiálu / služby;
Zajištění emailového alertu při prodlení dodacího termínu na odpovědnou osobu v nákupním oddělení, resp. informace o nevypořádaných Objednávkách;
Přiřazení jednoznačného identifikátoru pro Objednávky (číselná řada);
Možnost zasílat Objednávky poštou, emailem, datovou schránkou;
Fultextové vyhledávání a filtrování dle kategorií Objednávky a dalších atributů Objednávky;
Zastupování v rámci oddělení Nákupu (UNL);
Eskalace schvalovacího procesu, tzn. na organizační úroveň n+1;
Možnost přiložení příloh v podobě dodatečných souborů ve formátu MS Office, PDF.
Sledování celkového procesu Objednávky – založení, schválení, plnění (i postupné), dodání/vypořádání.

Propojení do výrobního systému (viz technický popis v kapitole 3) z důvodu evidence Objednávky a dalších podkladů k výrobě v jediném systému (přenos informací) na konci schvalovacího procesu.

Popis procesu napojení agendy Žádanky a Objednávky na výrobní proces je popsán, viz ukázku v příloze 3 a 4.

Počet objednávek v Podniku je cca 3 200 ks /rok.

2.4Faktura

DMS musí zajišťovat a uchovávat evidenci dodavatelských faktur. Do DMS se dostanou faktury dostat pomocí skenováním, elektronickou poštou (MS Outlook), datovou schránkou po přidělení evidenčního čísla na Podatelně Podniku. Díky variabilitě schvalování došlých dodavatelských faktur je nutné zajistit vysokou variabilitu schvalovacího procesu. Na došlé dodavatelské faktury bude aplikován čárový kód (Podatelna) kvůli interním účelům (zároveň dělící prvek pro tvorbu digitálních dávek při skenování podkladů).

Požadované minimální vlastnosti agendy Faktura tedy jsou:

Možnost zaevidování dodavatelských faktur následujícími možnými způsoby, tzn. poštou – skenováním, příjmem z emailové schránky (MS Outlook) – přeposlání na podatelnu, příjmem z datové schránky Podniku;
Centrální registr došlých Dodavatelských Faktur;
Faktura musí umět obsahovat potřebné doprovodné dokumenty, jako jsou dodavatelské listy, servisní listy a další.
Vyhledávání, včetně fulltextového a filtrování dle jednotlivých kategorií Dodavatelských faktur (dle IČO, DIČ Dodavatele, kategorie – materiál, služba, apod.)
Definice typů dodavatelských Faktur, pro každý typ mohou existovat různé režimy zpracování (např. jiný schvalovatel);
Možnost upravit workflow dle potřeb Podniku;
Vytištění schvalovacího workflow do PDF;
Historie zpracování (schvalování) Faktury;
Eskalace schvalovacího procesu, tzn. na organizační úroveň n+1;
Možnost propojeni s OCR software, který doplní textovou vrstvu;
Možnost propojení souvisejících dokumentů – smlouva, objednávka, žádanka.

Počet dodavatelských faktur je cca 5 000 ks/rok

2.5Směrnice, předpisy a dokumentace

DMS musí evidovat, uchovávat (ukládat) interní předpisy Podniku, včetně zajištění procesu návrhu, připomínkování, tvorba verzí dokumentu, schvalování (celý životní cyklus dokumentu). Prezentace podkladů v této kategorii Směrnice, předpisy a dokumentace bude zajištěna rovněž pomocí Intranetu v Podniku (po řádném schvalovacím procesu v PDF formátu). S ohledem na variabilitu dokumentů v této kategorii je nutné zajistit možnosti variabilního workflow pro zajištění klíčových vlastností (viz dále v textu).

Požadované minimální vlastnosti agendy Směrnice, předpisy a dokumentace tedy jsou:

Vícestupňový proces přípravy příslušného dokumentu, možnost paralelní práce připomínkujících nebo oponentů;
Bezpečné uložiště informací, řízení přístupových práv k jednotlivým Směrnicím, předpisům a dokumentům;
Možnost oddělit role odpovědné za přípravu Směrnice, předpisu nebo dokumentu (garant) od role odpovědné za publikaci a aktuálnost příslušných spravovaných dokumentů (správce);
Informování odpovědných osob emailem, kontrola seznámení se s předpisem formou úkolů;
Možnost přidávání připomínek uživateli, které se následně mohou zapracovat v příštích verzích;
Možnost schválení elektronickým podpisem;
Hlídání platnosti a upozornění na blížící se datum příští revize, vytváření revizí nebo nových verzí (pomocí emailových upomínek v MS Outlook);
Eskalace schvalovacího procesu, tzn. na organizační úroveň n+1;
Využití Workflow nástroje na řízení procesu přípravy i během účinnosti předpisu;
Záznam historie změn a schvalování na několika úrovních (historie položky, historie workflow a zjednodušený přehled na kartě předpisu);
Možnost tisku schvalovacího procesu do PDF dokumentu (včetně exportu do PDF);
Jednoduché a rychlé vyhledání, včetně fulltextového vyhledávání;
Doložitelnost historie pro interní i externí audity - kompletní evidence historie přípravy směrnice, předpisu nebo dokumentu včetně seznamování se s nimi.

Počet Xxxxxxx, předpisů a dokumentací je v Podniku cca 350 ks/rok.

2.6Smlouva

DMS musí umět evidovat smlouvy, které mohou být zpracovány ve formátu PDF, MS Office a dalších textových editorech, včetně přiložených souborů (variabilní množství v počtu příloh). DMS musí zajistit a evidovat životní cyklus Smlouvy:

Návrh Smlouvy;
Připomínkovací řízení, zajištění uchování jednotlivých verzí smlouvy včetně finální (čisté bez připomínek v editovatelné podobě);
Schvalovací řízení Smlouvy;
Publikace Smlouvy;
Zajištění včasně obnovy v případě blížící se exspirace Smlouvy (nutnost variabilního nastavení termínu upozornění garanta Smlouvy (navázáno na funkci / pozici v organizační struktuře) s ohledem na nutnost organizace možné veřejné zakázky.

Požadované minimální vlastnosti agendy Smlouva tedy jsou:

Centrální evidence Smluv;
Jednoduché a rychlé vyhledání, včetně fulltextového vyhledávání;
Filtry pro práci se Smlouvami (včetně fultextového vyhledávání, kategorií, času, předmětu apod.);
Evidence specifických atributů Smluv (smluvní strana, platnost od, schvalovatel apod.)
Řízení přístupů ke smlouvám, jednotlivci i skupiny, s různou úrovní práva nahlížet;
Předdefinované Workflow s připomínkováním, odsouhlasením a schválením v rámci připomínkovacího řízení;
Informování odpovědných uživatelů emailem (email alert na pověřené pracovníky jejich nadřízeného, nebo dle vydefinovaného klíče);
Automatizované nastavení a řízení práv podle stavu smlouvy a odpovědných osob (práva pro jednotlivce i skupiny);
Historie zpracování (historie Workflow pro auditní účely);
Možnost vytisknout schvalovací protokol (včetně exportu do PDF);
Upozornění na končící platnost Smlouvy (variabilní hlídání časových limitů, informování pomocí emailu (přímé propojení i na zastupující v případě dovolených, nepřítomnosti na pracovišti apod.));
Možnost definovat různé typy / kategorie Smluv;
Zastupování, či změna odpovědných osob;
Možnost upravit Workflow dle potřeb organizace;
Evidence a zpracování dodatků ke Smlouvám.

Počet Smluv je v Podniku cca 200 ks/rok.

2.7Zápis z porady

DMS musí umět evidovat Zápisy z porad jednotlivých řídících úrovní Podniku, včetně probíhajících projektů. Tyto Zápisy z porady jsou zpracovány v běžných textových nebo tabulkových editorech. DMS v této části musí umět evidovat jak zápis, tak i přílohu Zápisu z porady, která tvoří jeho nedílnou součást. Tyto přílohy mohou tvořit další textové dokumenty, tabulky, obrazový materiál, stavební plány a další soubory ve formátu např. PDF.

Funkce DMS musí umět zpracovat celý životní cyklus Zápisu z porady – vytvoření zápisu, připomínkování, schvalování a archivaci Zápisu z porady vč. příloh.

Požadované minimální vlastnosti agendy Zápis z porady jsou:

Centrální evidence Zápisů z porady;
Variabilní schvalovací Workflow nastavitelné vedoucím oddělení, projektu, nebo nominovanou osobou;
Jednoduché a rychlé vyhledání, včetně fulltextového vyhledávání;
Filtry pro práci se Zápisy z porady (včetně fultextového vyhledávání, kategorií, času, předmětu, oddělení; odpovědných osob, projektů apod.);
Evidence specifických atributů Zápisu;
Řízení přístupů k Zápisům z důvodu utajovaných informací, jednotlivci i skupiny, s různou úrovní práva nahlížet;
Předdefinované Workflow s připomínkováním, odsouhlasením a schválením;
Informování odpovědných uživatelů emailem (email alert na pověřené pracovníky jejich nadřízeného, nebo dle vydefinovaného klíče);
Automatizované nastavení a řízení práv podle stavu Zápisu a odpovědných osob (práva pro jednotlivce i skupiny);
Historie zpracování Zápisu z porady (historie Workflow pro auditní účely);
Možnost vytisknout schvalovací protokol (včetně exportu do PDF);
Možnost definovat různé typy / kategorie Zápisu;
Zastupování, či změna odpovědných osob;
Eskalace schvalovacího procesu, tzn. na organizační úroveň n+1;
Možnost upravit Workflow dle potřeb organizace.

Počet Zápisů z porady je v Podniku cca 500 ks / rok.

2.8Řízení úkolů (implementace s podporou Dodavatele)

DMS musí umět evidovat Úkoly z porad a jinak přidělených povinností, např. i z běžících projektů v Podniku. Řízení úkolů musí být provázáno s Xxxxxxxxxx emailovým klientem tedy s MS Outlook.

Požadované minimální vlastnosti agendy Řízení úkolů jsou:

Centrální evidence Úkolů;
Variabilní schvalovací Workflow nastavitelné vedoucím oddělení, projektu, nebo nominovanou osobou;
Jednoduché a rychlé vyhledání, včetně fulltextového vyhledávání;
Filtry pro práci s Úkoly (včetně fulltextového vyhledávání, kategorií, času, předmětu, oddělení; odpovědných osob, projektů apod.);
Evidence specifických atributů Úkolů (platnost od-do, schvalovatel apod.)
Řízení přístupů k Úkolům z důvodu utajovaných informací, přístupy pro jednotlivce i skupiny;
Informování odpovědných uživatelů emailem (email alert na pověřené pracovníky jejich nadřízeného, nebo dle vydefinovaného klíče);
Automatizované nastavení a řízení práv podle stavu Úkolu a odpovědných osob (práva pro jednotlivce i skupiny);
Historie zpracování Úkolu (historie Workflow pro auditní účely);
Možnost definovat různé typy / kategorie Úkolů;
Zastupování, či změna odpovědných osob;
Eskalace schvalovacího procesu, tzn. na úroveň n+1;
Možnost upravit Workflow dle potřeb organizace.

2.9Obchodní případ / nabídka (implementace s podporou Dodavatele)

V rámci zaškolení pověřených pracovníků Zadavatele bude Dodavatel povinen v rámci interního školení zajistit konzultační podporu při implementace agendy Obchodní případ / Nabídka. Tato školení je nutné chápat jako nutnou součinnost Dodavatele v rámci implementace agendy Zadavatelem. V rámci tohoto úkolu zajistí Dodavatel veškerou potřebnou součinnost.

DMS musí zajistit prokazatelnou evidenci obchodních případů, resp. zpracovaných nabídek. Tyto Obchodní případy / Nabídky musí být archivovány a zpětně dohledatelné. DMS musí zajistit a evidovat životní cyklus Obchodního případu / nabídky:

Návrh Obchodního případu / Nabídky;
Připomínkovací řízení, zajištění uchování jednotlivých verzí Obchodního případu / Nabídky včetně finální (čisté bez připomínek v editovatelné podobě);
Schvalovací řízení Obchodního případu / Nabídky, včetně možných příloh v podobě obchodních podmínek a zejména kalkulace finální podoby produktu.

Požadované minimální vlastnosti agendy Obchodní případ / Nabídka tedy jsou:

Centrální evidence Obchodního případu / Nabídky;
Jednoduché a rychlé vyhledání, včetně fulltextového vyhledávání;
Filtry pro práci s Obchodním případem / Nabídkou (včetně fultextového vyhledávání, kategorií, času, předmětu, klienta apod.);
Evidence specifických atributů Obchodního případu / Nabídky (klienta, platnost od, schvalovatel apod.)
Řízení přístupů k Obchodním případům / Nabídkám z důvodu utajovaných informací, jednotlivci i skupiny, s různou úrovní práva nahlížet;
Předdefinované Workflow s připomínkováním, odsouhlasením a schválením;
Informování odpovědných uživatelů emailem (email alert na pověřené pracovníky jejich nadřízeného, nebo dle vydefinovaného klíče);
Automatizované nastavení a řízení práv podle stavu Obchodního případu / Nabídky a odpovědných osob (práva pro jednotlivce i skupiny);
Historie zpracování (historie Workflow pro auditní účely);
Možnost vytisknout schvalovací protokol;
Upozornění na končící platnost Obchodního případu / Nabídky (variabilní hlídání časových limitů, informování pomocí emailu (přímé propojení i na zastupování v případě dovolených, nepřítomnosti na pracovišti apod.));
Možnost definovat různé typy / kategorie Obchodního případu / Nabídky;
Zastupování, či změna odpovědných osob;
Eskalace schvalovacího procesu, tzn. na organizační úroveň n+1;
Možnost upravit Workflow dle potřeb organizace;
Evidence a zpracování dodatků k Nabídkám.

Počet Obchodních případů / Nabídek je v Podniku cca 500 ks / ročně.

2.10Přístupová práva (implementace s podporou Dodavatele)

V rámci zaškolení pověřených pracovníků Zadavatele bude Dodavatel povinen v rámci interního školení zajistit konzultační podporu při implementace agendy Přístupová práva. V rámci tohoto úkolu zajistí veškerou potřebnou součinnost.

Požadované minimální vlastnosti agendy Přístupová práva jsou:

Centrální evidence podkladů Přístupových práv;
Jednoduché a rychlé vyhledávání, včetně fulltextového vyhledávání;
Filtry pro práci s Přístupovými právy (včetně fultextového vyhledávání, kategorií, času, předmětu, filtrování dle přístupu do systému apod.);
Evidence specifických atributů Přístupových práv (zaměstnanci, systém, datum od - do, schvalovatel, apod.)
Předdefinované Workflow s připomínkováním, odsouhlasením a schválením;
Informování odpovědných uživatelů emailem (email alert na pověřené pracovníky jejich nadřízeného, nebo dle vydefinovaného klíče);
Historie zpracování (historie Workflow pro auditní účely);
Možnost vytisknout schvalovací protokol (vč. exportu do PDF);
Upozornění na končící platnost oprávnění Přístupových práv;
Zastupování, či změna odpovědných osob;
Eskalace schvalovacího procesu, tzn. na organizační úroveň n+1;
Možnost upravit Workflow dle potřeb organizace;
Evidence a zpracování dodatků k Přístupovým právům.

Počet žádostí Přístupová práva je v Podniku cca 100 ks / ročně.

Zadavatel disponuje pro rychlou orientaci a zkrácení analytických prací popisem interních procesů (viz přílohu č. 5) a další dokumentací v podobě řady interních směrnic.

3Technické požadavky

3.1Požadavky na řešení

Systém DMS bude mít dále následující funkcionality:

Funkce workflow
Plnohodnotný přístup z webového prohlížeče
Centralizované uložení dat
Snadné a rychlé vyhledávání
Vytěžování dokumentů
Elektronické podpisy a časová razítka
Řízení přístupu na základě ověření uživatele, skupiny uživatelů
Správa verzí dokumentu
Možnost uzamknout dokument při úpravě
Možnost kooperace při úpravách dokumentů
Přístup k systému z mobilních zařízení
Bezpečnost systému
Logování událostí
Transakční protokol
Obnova ze zálohy
Jazyková podpora

3.1.1Funkce workflow

Workflow je schéma provádění nějaké komplexnější činnosti (procesu), rozepsané na jednodušší činnosti a jejich vazby. Obvykle se tímto pojmem popisuje zpracování dokumentů, vnitropodnikových procesů a dalších podnikových agend.

Workflow v rámci systému DMS pokryje následující funkce:

centrální správa workflow;
sledování událostí a aktuálního stavu daného workflow;
tisk aktuálního stavu daného workflow;
export aktuálního stavu daného workflow do PDF formátu;
operace s objekty (prohlížení, editování, komentář a tisk);
termínování jednotlivých úkolů;
odesílání e-mailových notifikací s aktuálním stavem dílčího úkolu workflow (např. při jeho prodlení);
nastavitelná priorita úloh workflow;
připojení dokumentů k workflow;
delegování dílčích úkolů v rámci workflow;
řízení zastupitelnosti jednotlivých osob;
změna přístupových práv v běhu workflow;
historie zpracování (historie workflow pro auditní účely);
vytváření workflow šablon.

Systém DMS musí dále obsahovat prostředí, ve kterém bude možné vytvářet zcela nová workflow a stejně tak upravovat všechna dříve vytvořená workflow. Prostředí bude uživatelsky přívětivé a intuitivní (např. tvorba workflow pomocí stavového diagramu). Ovládání tohoto prostředí pokryje školení pro administrátory, které je požadováno v dokumentu s názvem Smlouva o poskytnutí, implementaci a podpoře SW řešení DMS (Document Management System).

3.1.2Plnohodnotný přístup z webového prohlížeče

Systém DMS musí být realizován jako webová aplikace přístupná minimálně z webového prohlížeče Microsoft Internet Explorer nebo Google Chrome. Systém DMS musí být plnohodnotně použitelný z výše uvedených webových prohlížečů a to jak v desktopových, tak i v mobilních verzích.

3.1.3Centralizované uložení dat

Systém DMS bude nainstalován na virtuálních serverech Zadavatele v prostředí VMware. Uživatelé se budou k systému DMS připojovat po lokální síti pomocí webového prohlížeče. Ke vzdálenému přístupu bude sloužit zabezpečené šifrované připojení VPN (Virtual Private Network).

3.1.4Snadné a rychlé vyhledávání

Systém DMS bude podporovat vyhledávání dokumentů a to včetně fulltextové varianty vyhledávání.

Vyhledávání v systému DMS bude možné i prostřednictvím metadat, která budou každý dokument popisovat. Systém DMS bude podporovat vyhledávání dle kritérií, která jsou sestavována koncovým uživatelem jako kombinace všech přiřazených metadat k souboru.

Zobrazení výsledků vyhledávání bude závislé na přístupových oprávněních hledajícího uživatele a kategorii klasifikace vyhledávaných údajů. Uživatel ve výsledcích vyhledávání uvidí vždy jen takové dokumenty, ke kterým má potřebná oprávnění.

3.1.5Vytěžování dokumentů

Zadavatel předpokládá vytěžování dokumentů, které bude požadovat prostřednictvím specifického softwaru. Vstupy pro vytěžování budou pořízeny digitalizačním zařízením (scaner) s využitím OCR.

Zadavatel předpokládá vytěžování došlých formulářů, zejména dodavatelských faktur, cca 6000 ks/rok (různé vzory od cca 200 dodavatelů). Vytěžování dokumentů se bude provádět zejména do účetního programu RIS2000.

3.1.6Elektronické podpisy a časová razítka

Systém DMS musí umožnit podepisovat dokumenty elektronickým certifikátem přímo v systému. Systém DMS musí také umožňovat použití časových razítek.

Zadavtel v součastnosti provozuje Spisovou službu v režimu listinných dokumentů. V brzké budoucnosti ale plánuje přechod na Digitální režim. Proto požaduje, aby Systém DMS splňoval nároky eIDAS (zák. č. 297/2016 Sb.).

3.1.7Řízení přístupu na základě ověření uživatele, skupiny uživatelů

K přihlášení uživatele do systému DMS je využita identita z doménového účtu v Microsoft Active Directory a technologií SSO (Single Sign On). Identita uživatele je převzata z jeho přihlášení do operačního systému Windows.

Systém DMS musí nabízet také alternativní způsob ověření uživatelů, kteří nejsou v doméně. Stejně tak musí být možné se do systému DMS přihlásit z mobilních platforem (minimálně pomocí kombinace uživatelského jména a hesla).

Systém DMS 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 systému DMS (např. metadatům) podle řady kritérií a jejich kombinací. Tato kritéria zahrnují:

roli uživatele v rámci systému DMS, roli uživatele v rámci konkrétního workflow v systému DMS a roli uživatele z hlediska jeho zařazení v organizační struktuře Zadavatele
oprávnění uživatele/skupiny uživatelů přistupovat k určitým složkám ve struktuře úložiště systému DMS (oprávnění se dědí z vyšších složek do nižších)

3.1.8Správa verzí dokumentu

Systém DMS musí umožnit verzování dokumentů, včetně jejich názorného označení.

Každá verze dokumentu musí být opatřena pořadovým číslem a popisem verze. Informace o verzi a existujících verzích dokumentu musí být součástí metadat dokumentu.

Systém DMS musí umožnit oprávněnému uživateli vybrat z historie verzí takovou verzi, kterou označí za aktuální, tedy poslední platnou verzi a to se zachováním všech dalších verzí.

3.1.9Možnost uzamknout dokument při úpravě

Systém DMS musí umožňovat uzamčení dokumentu pro jednoho uživatele tak, aby dokument nemohl být dočasně upravován nikým jiným.

3.1.10Možnost kooperace při úpravách dokumentů

Systém DMS musí v případě potřeby umožňovat úpravu dokumentů několika uživateli najednou.

3.1.11Přístup k systému z mobilních zařízení

Systém DMS musí být možno využívat i na mobilních zařízeních. Mobilními zařízeními se pro tento účel rozumí tablety a mobilní telefony (operační systémy iOS nebo Android). Zadavatel požaduje vzdálený přístup z mobilních zařízení včetně „chytrých“ mobilních telefonů k dokumentům a workflow v systému 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 systému DMS, otevření souboru skrze URL odkaz uvedený v emailové zprávě na mobilním zařízení propojeném s úložištěm systému 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 systému DMS.

3.1.12Bezpečnost systému

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. Zadavatel souhlasí s tím, že systém DMS může být podroben penetračním testům Zadavatele.

3.1.13Logování událostí

Systém DMS musí logovat veškeré události související s dokumenty, jako např. změny provedené v dokumentu, smazání dokumentu nebo nahrazení dokumentu.

3.1.14Transakční protokol

Systém DMS musí automaticky generovat transakční protokol v předem definovaných intervalech a poté jej automaticky archivovat.

3.1.15Obnova ze zálohy

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.

3.1.16Jazyková podpora

Systém DMS musí být pro uživatele plně lokalizován v českém jazyce.

K systému DMS musí dále 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.

3.2Systémové prostředí

Systém DMS musí akceptovat standardní systémové prostředí Zadavatele a musí být do tohoto prostředí snadno implementovatelné.

3.2.1Prostředí datové sítě

V prostředí Zadavatele existují dvě vzájemně oddělené datové sítě. Síť administrativní, která umožňuje připojení k Internetu a síť výrobní, která připojení do Internetu neumožňuje.

Klientské stanice připojeny rychlostí minimálně 100 Mbit/s
Servery připojeny rychlostí minimálně 1 Gbit/s
Adresace dle RFC 1918 (10.x.y.z, 172.16-31.y.z, 192.168.y.z)

3.2.2Serverová část

Serverové prostředí je kompletně virtualizované s následujícími parametry:

Virtualizační platforma VMware vSphere verze 6 nebo novější
Operační systémy Microsoft Windows Server 2016 DataCenter

3.2.3Databázové servery

Data standardních IS jsou uložena v databázích Microsoft SQL:

Databázová platforma Microsoft SQL Server 2016 Standard

Databázová platforma Zadavatele je postavena na technologii Microsoft SQL Server, pro jejíž správu má Zadavatel vyškolené zaměstnance.

V případě, že řešení bude využívat jinou databázi, poskytne Zadavatel pro DB prostředí následující konfiguraci virtuálních serverů na platformě VMware:

Databázový server

až 4 vCPU (virtuální CPU)
až 32 GB RAM
vzdálené úložiště prostřednictvím sítě SAN – až 1 TB
konektivita min. 1 Gbit/s
operační systém Windows Server 2016 DataCenter

Účastník je povinen zahrnout do nabídky veškeré náklady na pořízení a provoz dalších SW licencí po celou dobu trvání provozní podpory systému DMS.

3.2.4WWW servery

Webové aplikace jsou standardně provozovány na platformě Microsoft SharePoint:

Platforma pro webové aplikace Microsoft SharePoint Server 2016

V případě, že řešení bude využívat jinou platformu, Zadavatel poskytne následující konfiguraci virtuálních serverů na platformě VMware:

Webový server

až 4 vCPU (virtuální CPU)
až 32 GB RAM
vzdálené úložiště prostřednictvím sítě SAN – až 200 GB
konektivita min. 1 Gbit/s
operační systém Windows Server 2016 DataCenter

Účastník je povinen zahrnout do nabídky veškeré náklady na pořízení a provoz dalších SW licencí po celou dobu trvání provozní podpory systému DMS.

3.2.5Aplikační servery

Zadavatel poskytne následující konfiguraci pro provoz virtuálních aplikačních serverů na platformě VMware:

Aplikační server

až 4 VCPU (virtuální CPU),
až 32 GB RAM,
vzdálené úložiště prostřednictvím sítě SAN – až 200 GB,
konektivita min. 1 Gbit/s,
operační systém Windows Server 2016 DataCenter.

Účastník je povinen zahrnout do nabídky veškeré náklady na pořízení a provoz dalších SW licencí po celou dobu trvání provozní podpory systému DMS.

3.2.6Testovací prostředí

Zadavatel poskytne následující prostředky pro provoz virtuálního testovacího prostředí na platformě VMware:

Testovací prostředí

až 8VCPU (virtuální CPU);
až 2 x 32 GB RAM;
vzdálené úložiště prostřednictvím sítě SAN – až 500 GB;
konektivita min. 1 Gbit/s;
operační systém Windows Server 2016 DataCenter.

Účastník je povinen zahrnout do nabídky veškeré náklady na pořízení a provoz dalších SW licencí po celou dobu trvání provozní podpory systému DMS.

3.2.7Monitoring systémů

Monitorovací platforma Zabbix.

3.2.8Klientské stanice

Stolní počítače typu HP ProDesk 600 G3 SFF PC a notebooky typu HP EliteBook 840r G4.

Operační systém

Microsoft Windows 7 Professional a vyšší (Zadavatel předpokládá postupný přechod na Windows 10 Pro nebo Windows 10 Enterprise)

Softwarové vybavení

Microsoft Office 2010 Pro Plus CZ a vyšší (probíhá přechod k Microsoft Office 365)
Microsoft Internet Explorer 11
Adobe Acrobat Reader 10 CZ nebo vyšší
Symantec EndPoint Protection v aktuální verzi

Instalace další provozní platformy na klientskou stanici není preferována.

Licenční vybavení

Všichni budoucí uživatelé systému DMS jsou držiteli licence Microsoft 365 úrovně E3 nebo E5. Licenční model v sobě dále pro všechny uživatele zahrnuje CAL licence k produktu Microsoft SharePoint (Online i On-Premise varianty), CAL licence k produktu Microsoft Windows Server 2016 a pokrývá také serverové licence pro Microsoft SharePoint v neomezeném množství On-Premise instancí.

Na klientské stanici pracuje uživatel standardně bez administrátorských oprávnění.

3.2.9Klientská mobilní zařízení

Chytré telefony s operačním systémem Android 7.0 a novější, případně iOS verze 11.0 a novější.

3.3Systémové služby

Systém DMS musí akceptovat standardní systémové služby v prostředí Zadavatele a musí být do tohoto prostředí snadno implementovatelný.

3.3.1Single Sign-On

U informačních systémů Zadavatele je realizována funkce Single Sign-On s využitím služby Microsoft Active Directory (autentizační protokol Kerberos). Uživatel se autentizuje pouze jednou do domény Zadavatele, 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.

3.3.2SIEM (sběr bezpečnostních logů)

Sběr a vyhodnocování bezpečnostních logů bude v prostředí Zadavatele řešen centrálně systémem SIEM.

Systém 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ě;
zaznamenávat logy ve strojově čitelné podobě do DB a umožnit realtime přístup systému SIEM;
odesílat logy ve strojově čitelné podobě na vzdálený server např. syslogem.

3.3.3Elektronická pošta

Server elektronické pošty – Microsoft Exchange 2010 (do budoucna přechod k Microsoft Exchange 2016)
Klient elektronické pošty – Microsoft Outlook 2010 a vyšší (do budoucna přechod k Microsoft Office 365)

3.3.4Tisková zařízení

Síťová tisková zařízení;
Komunikační protokol – TCP/IP.

3.3.5Synchronizace času

Čas na všech komponentách sítě Zadavatele mimo stanic uživatelů je synchronizován se zdrojem přesného času protokolem NTP.

3.4Vazby na interní IS

Systém DMS musí reflektovat potřeby komunikace s ostatními informačními systémy v prostředí Zadavatele:

Systém	Popis využití
Microsoft Office	Předpokládáme použití plug-inu do aplikací Microsoft Office zajišťující integraci mezi Microsoft Office 365 a systémem DMS. Manipulace se soubory podporovaných formátů (otevření, editace a ukládání) musí být možná přímo z nástrojů Microsoft Office (verze 2010 a vyšší). Dále předpokládáme těsnou integraci dokumentů Microsoft Office (např. možnost správy atributů dokumentů přímo z aplikací Microsoft Office a funkce pro porovnání jednotlivých verzí dokumentů uložených v systému DMS).
Microsoft 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 prostředí Zadavatele. Nutná je podpora integrace s Exchange Server 2010 a novějším, včetně varianty Microsoft Exchange Online. Integrace s MS Exchange je na úrovni odesílání e-mailů zaměstnancům STC na základě notifikací generovaných ze systému DMS.
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.
ERP systém Xxxxxx	Výrobní systém Xxxxxx je hlavní výrobní systém v prostředí Zadavatele, který je momentálně ve fázi implementace. Pro integraci systému DMS a Xxxxxx musí systém DMS podporovat oboustranné propojení s výrobním systémem Cicero. Pro tento účel bude systém DMS poskytovat webové služby, které umožní přenos dat přes HTTPS protokol oběma směry, a to ve formátu JSON nebo XML. Pokud nebude řečeno jinak, dodání certifikátu zajistí dodavatel systému DMS. V rámci oboustranné komunikace pomocí webové služby budou vyměňována data pro oblasti: 1) Cenotvorba – schvalování výše cenové nabídky Před vlastním odesláním cenové nabídky zákazníkovi bude na straně DMS probíhat schvalovací proces nabídkové ceny. Po finálních schválení bude přenesen do MIS XXXXXX příznak schválení a následně bude možné odeslat dokument cenové nabídky zákazníkovi. 2) Schválení materiálových žádanek Na základě zpracované technologie v MIS XXXXXX bude vygenerován materiálový požadavek na jednicový materiál, který bude přenesen do DMS, tak aby mohlo dojít k jeho schválení oprávněnou osobou a následné tvorbě a schválení objednávky na daný materiál. Stejný princip bude použit pro materiál pod minimálním množstvím. 3) Objednávky – přenos vystavené objednávky Po vystavení objednávky v rámci DMS bude uzavřená (dokončená) objednávka přenesena do MIS CICERO, kde bude následně sloužit jako podklad pro materiálový sklad při přijetí daného materiálu na sklad. 4) Objednávky – změna stavu objednávky Po přijetí materiálu na sklad dojde ke změně stavu objednávky na stav „Přijato“ nebo „Částečně přijato“. Tento stav bude přenesen do DMS, kde bude zaktualizován stav dané objednávky. 5) Fakturace Po vystavení faktury z RIS2000 proběhne v DMS schvalovací worflow a příprava faktury k odeslání (v elektronické nebo listinné podobě).
RIS2000	Propojení programů RIS2000 (účetní program) a DMS bude z důvodu vytěžování zadavatelem digitalizovaných dokumentů (faktur) formou OCR a přenosu takto vytěžených základních údajů z faktur do účetního programu sloužit ke zvýšení efektivity administrativní práce a komfortnějšímu schvalování podkladů v souladu s povinnými náležitostmi účetního dokladu. Zadavatel předpokládá vytěžování v oblasti identifikačních údajů dodavatelských faktur a náležitostí daňových dokladů. Pro propojení RISu s externím DMS systémem navrhujeme využít webových služeb. Nebráníme se ani variantě přímého přístupu do databáze RIS za podmínek jasného vymezení rolí a oprávnění přistupujících uživatelů k jednotlivých tabulkám.

3.5Vazby na externí IS

Systém	Popis využití
Datové stránky	Systém DMS musí obsahovat konektor pro příjem a odeslání z datových schránek.
Propojení na registr plátců DPH

4Přílohy

Příloha 1, Žádanka (formulář);
Příloha 2, Řád oběhu dokladů;
Příloha 3, Propojení DMS a výrobního programu 1;
Příloha 4, Propojení DMS a výrobního programu 2;
Příloha 5, Popis interních proces (ukázka).

Document Metadata

Table of Contents

Document management systém

Document Metadata