Smlouva o realizaci veřejné zakázky s názvem
Smlouva o realizaci veřejné zakázky s názvem
„Dodávka ECM/DMS – IS pro správu elektronických dokumentů“
(dále jen „Smlouva“)
uzavřená níže uvedeného dne, měsíce a roku ve smyslu ust. § 1746 odst. 2 zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „Občanský zákoník“),
mezi těmito smluvními stranami:
Česká republika – Ministerstvo životního prostředí
Se sídlem: Vršovická 1442/65, 100 10 Praha 10
ID datové schránky: 9gsaax4
IČO: 00164801
Zastoupená: Ing. Xxxxx Xxxxxxxxxx, ředitelkou odboru informatiky
Zástupce pro věcná jednání: Xxx. Xxxxx Xxxxx (tel.: x000 000 000 000, email: xxxxx.xxxxx@xxx.xx) Bankovní spojení: ČNB Praha 1
Číslo účtu: 7628001/0710 (dále jen „Objednatel“)
a
TECHNISERV IT, spol. s r. o.
Se sídlem: Traťová 574/1, 619 00 Brno
ID datové schránky: cfg6j6v
IČO: 26298953
DIČ: CZ26298953 (Dodavatel je plátcem DPH.) Zapsaná v obchodním rejstříku vedeném Krajským soudem v Brně, sp. zn. C42557 Zastoupená: Ing. Luďkem Teleckým, jednatelem
Zástupce pro věcná jednání: Bankovní spojení: Komerční banka, a. s.
Číslo účtu: 27-7648580257/0100 (dále jen „Dodavatel“)
(Objednatel a Dodavatel dále jednotlivě také jako „Smluvní strana“ a společně jako „Smluvní strany“).
Preambule
Tato Smlouva je uzavírána mezi Objednatelem a Dodavatelem na základě výsledků zadávacího řízení na veřejnou zakázku s názvem „Dodávka ECM/DMS – informační systém pro správu elektronických dokumentů“, systémové číslo NEN (Národní elektronický nástroj): N006/18/V00021273, evidenční číslo ve Věstníku veřejných zakázek: Z2018-040760 (dále jen „Veřejná zakázka“), zadávanou v souladu se zákonem č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „Zákon o ZVZ“). Nabídka Dodavatele podaná v rámci zadávacího řízení na Veřejnou zakázku byla vyhodnocena jako nejvýhodnější (dále jen „Nabídka“).
Cílem této Smlouvy je tedy úprava dvoustranného právního vztahu mezi Smluvními stranami, jehož obsahem jsou práva a povinnosti související s realizací Veřejné zakázky v souladu s příslušnými platnými právními předpisy tak, aby Smluvní strany měly možnost při nejvyšší možné míře právní jistoty realizovat práva a plnit povinnosti
touto Smlouvou založené. Podrobnosti jsou upraveny v zadávacích podmínkách na Veřejnou zakázku a dále v této Smlouvě a jejích přílohách.
Článek I. Předmět a účel Smlouvy
1.1 Účelem této Smlouvy je zajištění realizace Xxxxxxx zakázky, tj. pořízení informačního systému pro správu elektronických dokumentů pro Objednatele spočívající v jeho implementaci do stávajícího prostředí Objednatele, a to včetně poskytnutí veškerých nezbytných licencí, technologií, dokumentů a služeb pro tuto implementaci.
1.2 Předmětem této Smlouvy je závazek Dodavatele na svůj náklad a nebezpečí dodat Objednateli a implementovat do stávajícího prostředí Objednatele „informační systém pro správu elektronických dokumentů včetně implementace procesů veřejných zakázek, smluv a projektových záměrů, který bude následně provozován v prostředí Objednatele“ (dále také jen „Předmět Smlouvy“ nebo také jen „ECM/DMS“ nebo také jen „Plnění“). Dodavatel je dále povinen poskytnout Objednateli SW licence (licenci nebo multilicence) k užívání ECM/DMS, jakož i veškeré licence a technologie nezbytné pro provoz ECM/DMS, které Objednatel nevlastní.
Předmět Xxxxxxx bude Dodavatelem realizován v souladu s touto Smlouvou a jejími v Čl. XII. odst. 12.9 této Smlouvy uvedenými přílohami obsahujícími potřeby a požadavky Objednatele a dále také v rozsahu Objednatelem akceptovaného Návrhu implementace, který vytvoří Dodavatel v rámci předimplementační analýzy, jak je uvedeno dále v této Smlouvě.
1.3 Dodavatel se zavazuje realizovat pro Objednatele Plnění za podmínek uvedených v zadávací dokumentaci k Veřejné zakázce a dále za podmínek stanovených v této Smlouvě a jejích jednotlivých přílohách.
1.4 Předmětem této Smlouvy je dále závazek Objednatele převzít Plnění od Dodavatele způsobem definovaným v Čl. V. této Smlouvy (Akceptace plnění) a zaplatit mu za Plnění poskytnuté v souladu s touto Smlouvu a jejími přílohami cenu dle Čl. VI. této Smlouvy.
Článek II. Harmonogram a místo Plnění
2.1 Dodavatel je povinen dodat Plnění Objednateli v termínech specifikovaných v následujícím harmonogramu (dále jen „Harmonogram“):
Etapa / Milníky | Akceptace | Fakturace | Termíny | |
Etapa I. – Předimplementační analýza a Návrh implementace ECM/DMS | ||||
a) | Podpis a účinnost Smlouvy – zahájení Plnění | ANO | - | čas „T“ |
Předimplementační analýza | - | - | do T + 11 týdny | |
b) | Akceptovaný dokument – Návrh implementace ECM/DMS a agend veřejných zakázek, smluv a projektových záměrů (NAIM) | ANO | ANO | do T + 13 týdnů |
Etapa II. – Implementace ECM/DMS | ||||
c) | Instalace ECM/DMS do testovacího (TEST) prostředí | ANO | - | do T + 15 týdnů |
d) | Školení klíčových uživatelů a administrátorů, dokumentace | ANO | - | do T + 26 týdnů |
Implementace, migrace a integrace na související systémy | - | - | do T + 27 týdnů |
e) | Akceptace testování dle Testovacích scénářů | ANO | ANO | do T + 30 týdnů |
Etapa III. – Ověření produkčního provozu a produkce ECM/DMS | ||||
f) | Instalace ECM/DMS do produkčního (PROD) prostředí a jeho spuštění | ANO | - | do T + 32 týdnů |
g) | Dodání SW Licencí, zdrojových kódů a dokumentace | ANO | ANO | do T + 32 týdnů |
Podpora ověření produkčního provozu | - | - | do T + 39 týdnů | |
h) | Akceptace – předání ECM/DMS do produkce dle Smlouvy a zahájení poskytování podpory | ANO | ANO | do T + 39 týdnů |
2.2 Harmonogram může být na základě dohody Objednatele a Dodavatele změněn či upraven dle časových potřeb realizace dílčích plnění s tím, že tato úprava nebude mít vliv na cenu, která je dle této Smlouvy konečná, pevná a nepřekročitelná a dále s tím, že Dodavatel je povinen vždy dodržet termín označený v Harmonogramu jako T + 30 týdnů, tj. milník e) Akceptace testování dle Testovacích scénářů – resp. termín ukončení Etapy II. Ověření produkčního provozu a produkce ECM/DMS poběží dle Harmonogramu nejméně po dobu 2 měsíců od jeho zahájení (tedy od T + 30 do T + 39), a to až do doby, než ověření produkčního prostředí a produkce bude ukončeno bezvýhradní akceptací ze strany Objednatele dle podmínek dále ujednaných.
2.3 Místem plnění je sídlo Objednatele uvedené v záhlaví této Smlouvy, není-li mezi Smluvními stranami ujednáno jinak.
Článek III. Specifikace Plnění
Plnění dle této Smlouvy sestává z následujících závazků Dodavatele, rozčleněných na tři hlavní oblasti – etapy:
a) vytvoření Návrhu implementace k ECM/DMS dle specifikací uvedených v odst. 3.1 tohoto článku a požadavků uvedených v Přílohách č. 1, 2 a 3 Smlouvy (dále jen „Předimplementační analýza a Návrh implementace“);
b) implementace ECM/DMS v prostředí Objednatele dle podmínek uvedených v odst. 3.2 tohoto článku a dále dle požadavků uvedených v Přílohách č. 1, 2 a 3 Smlouvy (dále jen „Implementace ECM/DMS“);
c) poskytnutí ověření produkčního provozu dle požadavků uvedených v odst. 3.3 tohoto článku a dále dle specifikací uvedených v Přílohách č. 1, 2 a 3 Smlouvy (dále jen „Ověření produkčního provozu a produkce“);
a jakákoliv další plnění, která jsou v této Smlouvě, jejích přílohách a NAIM dále uvedena.
3.1 Předimplementační analýza a Návrh implementace
3.1.1 Po podpisu této Smlouvy Dodavatel provede předimplementační analýzu, jejímž výstupem bude dokument nazvaný „Návrh implementace ECM/DMS a agend veřejných zakázek, smluv a projektových záměrů“ (dále jen „NAIM“).
3.1.2 NAIM bude obsahovat výsledky podrobné analýzy vlastností, procesů a integrace agend veřejných zakázek, smluv a projektových záměrů, a dále výsledky analýzy technického, provozního a komunikačního prostředí Objednatele. V NAIM bude dále stanoven podrobný návrh:
- implementace, konfigurace ECM/DMS;
- nasazení správy dokumentů pro veřejné zakázky (VZ) a smlouvy (SML);
- nasazení správy dokumentů pro projektové záměry (PZ);
- migrace dat stávající agendy – aplikace eSmlouvy do SML;
- integrace ECM/DMS a výše uvedených agend na související systémy; a
- procesních a organizačních zabezpečení potřebných pro implementaci ECM/DMS Objednateli.
3.1.3 NAIM bude dále definovat požadavky Dodavatele na poskytnutí součinnosti ze strany Objednatele včetně předpokládaných požadavků na zdroje. Minimální součinnost, kterou se Objednatel zavazuje Xxxxxxxxxx poskytnout, je uvedena v Příloze č. 1 – Věcné (manažerské) zadání, a to v kapitole
5. – Minimální požadavky na projektové řízení a kapitole 6. – Požadavky na řízení projektu.
3.1.4 NAIM bude zpracován v souladu s požadavky Objednatele a Dodavatel se zavazuje, že bude obsahovat obvyklé formální náležitosti, konkrétní informace z prostředí Objednatele a bude mít vypovídající obsahovou, technickou, informační a ekonomickou úroveň.
3.2 Implementace ECM/DMS
3.2.1 Dodavatel se dále zavazuje provést Implementaci ECM/DMS, která se sestává z:
- Instalace ECM/DMS do TEST prostředí;
- Školení, dokumentace;
- Implementace, migrace a integrace na související systém;
- Akceptace testování dle Testovacích scénářů.
3.2.2 Etapa II. – Implementace ECM/DMS bude zahájena po akceptaci NAIM Objednatelem postupem uvedeným v Čl. V. této Smlouvy a bude ukončena akceptací testování dle Testovacích scénářů.
3.3 Ověření produkčního provozu a produkce
3.3.1 Dodavatel se dále zavazuje provést Ověření produkčního provozu a produkce, které se sestává z:
- Instalace ECM/DMS do PROD prostředí;
- Dodání SW licencí, zdrojových kódů a dokumentace;
- Podpory ověření produkčního provozu;
- Akceptace – předání ECM/DMS do produkce dle Smlouvy.
3.3.2 Etapa III. – Ověření produkčního provozu a produkce bude zahájena po akceptaci Etapy
II. Objednatelem postupem uvedeným v Čl. V. této Smlouvy a bude ukončena finální akceptací
– předáním ECM/DMS do produkce dle Smlouvy a zahájením poskytování podpory.
Článek IV. Realizace Plnění
4.1 Dodavatel se zavazuje realizovat Plnění dle Harmonogramu uvedeného v Čl. II. odst. 2.1. této Smlouvy, popisujícího jednotlivé etapy realizace Plnění označované jako „Etapa projektu“ (dále jen „Etapy“ či jednotlivě „Etapa“); jednotlivé časové milníky v Harmonogramu označované jako „Milníky projektu“ (dále jen „Milníky“); výstupy požadované Objednatelem (dále jen „Výstupy“ či jednotlivě „Výstup“); formy akceptace Výstupů Objednatelem; platební kalendář (dále jen „Platební kalendář“).
4.2 Plnění bude Dodavatelem realizováno v jednotlivých Etapách podrobně upravených v Harmonogramu členěných dále do jednotlivých Milníků. Je-li v Harmonogramu pro jednotlivé Milníky sjednána
„AKCEPTACE“ rozumí se tím, že v termínu uvedeném v Harmonogramu u tohoto Milníku, dojde ze strany Objednatele k akceptaci tohoto Milníku (budou-li splněny podmínky stanovené touto Smlouvou pro jeho akceptaci) způsobem definovaným v Čl. V. této Smlouvy, čímž bude ze strany Objednatele osvědčeno
provedení a splnění Milníku, popř. souboru na sebe bezprostředně navazujících Milníků, které tvoří logický a funkční celek. Je-li v Harmonogramu u Milníku kromě akceptace sjednána i „FAKTURACE“, bude provedena po akceptaci takového Milníku platba ve výši uvedené pro daný Milník v Platebním kalendáři (viz Čl. VI. odst. 6.3. této Smlouvy).
4.3 S odkazem na Harmonogram je akceptace sjednána u následujících Milníků:
a) Podpis Smlouvy – zahájení plnění;
b) Akceptace NAIM;
c) Instalace ECM/DMS do testovacího (TEST) prostředí;
d) Školení, dokumentace;
e) Akceptace testování dle Testovacích scénářů;
f) Instalace ECM/DMS do produkčního (PROD) prostředí;
g) Dodání SW licencí, zdrojových kódů a dokumentace;
h) Akceptace – předání ECM/DMS do produkce dle Smlouvy.
4.4 Dodavatel je povinen průběžně informovat Objednatele o realizaci Plnění na pravidelných schůzkách a předkládat informace o stavu rozpracovanosti Plnění.
4.5 Objednatel je oprávněn kdykoliv během realizace Plnění požadovat od Dodavatele písemné zprávy o průběžném stavu Plnění. Dodavatel takové zprávy zpracuje bezodkladně, nejpozději však do 5 dnů po doručení výzvy Objednatele.
4.6 Objednatel je oprávněn kdykoliv a průběžně ověřovat shodu realizace Plnění se zadáním specifikovaným v zadávací dokumentaci k Veřejné zakázce, této Smlouvě a jejích přílohách. Dodavatel je povinen poskytnout k takovému ověřování bez prodlení veškerou potřebnou součinnost a podklady.
4.7 Testování
4.7.1 Dodavatel vypracuje detailní plán testů, který bude součástí NAIM, a bude obsahovat organizační zajištění testování, testovací scénáře, návrh protokolů, kritéria pro akceptování testů a případně další detailní informace vztažené k typu testu a příslušné části ECM/DMS.
4.7.2 Všechny typy testů budou probíhat v testovacím prostředí Objednatele. Objednatel má právo vyjadřovat se a požadovat zapracování svých odůvodněných připomínek ke specifikaci testů a dalším parametrům testování a finální verzi všech testovacích scénářů musí Objednatel vždy písemně odsouhlasit.
4.7.3 Objednatel provede, za pomoci Dodavatele, vlastní testování ECM/DMS v požadovaném rozsahu a struktuře podle schválených testovacích scénářů. O průběhu a výsledku jednotlivých testů vyhotoví Dodavatel příslušné protokoly včetně vykázání zjištěných chyb.
4.7.4 Všechny protokoly o provedených testech budou podepsány oprávněnými zástupci Smluvních stran a Objednatel zajistí archivaci všech originálů veškerých dokumentů vypracovaných v souvislosti s provedeným testováním.
4.8 Poskytnutí a dodání SW licence (nebo multilicence) ECM/DMS
4.8.1 Testovací SW licence (nebo multilicence) – Etapa II. (Implementace ECM/DMS)
Dodavatel se zavazuje poskytnout v rámci Etapy II., Milník c) (viz Harmonogram) testovací SW licence (nebo multilicence) ECM/DMS, včetně všech nezbytných licencí a technologií nutných pro ECM/DMS, při instalaci systému ECM/DMS do testovacího prostředí za účelem testování dle testovacích scénářů. O poskytnutí testovací SW licence (multilicence) ECM/DMS bude mezi Objednatelem
a Dodavatelem sepsán protokol (dále jen „Protokol o zápůjčce SW licencí“). Testovací SW licence (multilicence) bude rozepsána do položkového seznamu s přesným názvem licencí a jejich popisem. Testovací SW licence (multilicence) ECM/DMS je řádně poskytnuta a předána teprve k okamžiku podpisu Protokolu o zápůjčce SW licencí.
4.8.2 SW licence (nebo multilicence) – Etapa III. (Ověření produkčního provozu a produkce)
Dodavatel se zavazuje poskytnout v rámci Etapy III., Milník g) (viz Harmonogram) SW licence (nebo multilicence) ECM/DMS, včetně všech nezbytných licencí a technologií nutných pro provoz ECM/DMS v TEST i PROD prostředí. O poskytnutí SW licence (multilicence) ECM/DMS bude mezi Objednatelem a Dodavatelem sepsán předávací protokol (dále jen „Předávací protokol“). SW licence (multilicence) bude rozepsána do položkového seznamu s přesným názvem licencí a jejich popisem. SW licence (multilicence) ECM/DMS je řádně poskytnuta a předána spolu s licenčním ujednáním teprve k okamžiku podpisu Předávacího protokolu.
4.8.3 Dodané SW licence (multilicence) ECM/DMS bude užívat Objednatel a jeho rezortní organizace.
4.9 Projektové řízení, řídící výbor a projektový tým
4.9.1 Objednatel a Dodavatel zajistí vytvoření projektového týmu, řídícího výboru a delegaci vlastních vedoucích a odborných pracovníků, a to formou tzv. zrcadlového týmu, jehož součástí budou na každé straně minimálně:
a) Supervizor;
b) Vedoucí projektu;
c) Členové – odborníci pro interní agendy – veřejné zakázky, smlouvy, projektové záměry a jejich dokumenty a procesy;
pro implementaci a provoz ECM/DMS. Společně dále jen „Projektový tým“.
4.9.2 Projektový tým
Role | Příjmení Jméno | Telefon | |
Objednatel | |||
Supervizor (člen ŘV) | Xxx. Xxxx Xxxxxxxxx | x000 000 000 000 | |
Vedoucí projektu (člen ŘV) | Xxx. Xxxxx Xxxxx | x000 000 000 000 | |
Členové projektového týmu (role) | |||
Business – odborník č. 1 | Xxx. Xxxxxxxx Xxxxxxxxx | x000 000 000 000 | |
Business – odborník č. 2 | Xxx. Xxxxx Xxxxx | x000 000 000 000 | |
Business – odborník č. 3 | Xxx. Xxxxx Xxxxxxxx | x000 000 000 000 | |
Business – odborník č. 4 | Xxx. Xxxxxxxx Xxxxxxx | x000 000 000 000 | |
Business – odborník č. 5 | Ing. Xxxxx Xxxxxxxxxx | x000 000 000 000 | |
Business – odborník č. 6 | |||
ICT garant | Xxx Xxxxxx | x000 000 000 000 |
Dodavatel | |||
Supervizor (člen ŘV) | Xxx. Xxxxx Xxxxxxx | x000 000 000 000 | |
Vedoucí projektu (člen ŘV) | x000 000 000 000 | ||
Členové projektového týmu (role) | |||
Architekt | x000 000 000 000 | ||
Analytik/Konzultant | x000 000 000 000 | ||
Programátor | x000 000 000 000 | ||
Administrátor/Specialist a | |||
Lektor |
4.9.3 Projektové řízení a řízení projektu implementace je blíže specifikováno v Příloze č. 1 – Věcné (manažerské) zadání v kapitolách 5. a 6. Konkrétní složení Projektového týmu na straně Dodavatele a Objednatele bude upřesněno v NAIM.
Článek V. Akceptace Plnění
5.1 Je-li v Harmonogramu u Milníku uvedeno „AKCEPTACE“ rozumí se tím, že dílčí plnění odpovídající takovému Milníku, popř. souboru na sebe bezprostředně navazujících Milníků, které tvoří logický a funkční celek (dále také jen „dílčí Plnění“), bude Objednatelem akceptováno, budou-li splněny podmínky stanovené touto Smlouvou, na základě akceptační procedury popsané dále v Příloze č. 1, kapitola 6 – Věcné (manažerské) zadání (dále také jako „Akceptační procedura“).
5.2 Akceptační procedura zahrnuje ověření, zda Dodavatelem poskytnuté dílčí Plnění je výsledkem, ke kterému se Dodavatel zavázal, a to porovnáním skutečných vlastností jednotlivých dílčích Plnění Dodavatele s jejich závaznou specifikací uvedenou v zadávací dokumentaci a Nabídce k Veřejné zakázce, této Smlouvě, jejích přílohách a NAIM, a to za využití akceptačních kritérií Dodavatelem definovaných v NAIM, Objednatelem odsouhlasených a případně později doplněných.
5.3 Předání a převzetí Dodavatelem řádně provedeného Plnění bude probíhat postupně akceptací jednotlivých dílčích Plnění, a to v termínech stanovených v Harmonogramu na základě akceptačních protokolů (dále jen „Akceptační protokol“).
5.4 Dojde-li ze strany Akceptační komise bez dalšího k akceptování dílčího Plnění, tzn. akceptaci bez výhrad, vznikne Dodavateli právo na uhrazení dílčí ceny dle Čl. VI. odst. 6.3 této Smlouvy, je-li pro akceptaci dílčího Plnění dílčí cena sjednána.
5.5 Bude-li Akceptační komise akceptovat dílčí Plnění s výhradami, budou tyto popsány v Akceptačním protokolu včetně způsobu a termínu, ve kterém je Dodavatel povinen uplatněné výhrady odstranit, o čemž bude následně sepsán nový Akceptační protokol. Nebudou-li ve stanoveném termínu výhrady Dodavatelem odstraněny, vyhrazuje si Objednatel právo na úhradu smluvní pokuty dle Čl. X. odst.
10.3.4 této Smlouvy či na okamžité odstoupení od Xxxxxxx dle Čl. XI. odst. 11.6 této Smlouvy.
5.6 Nebude-li Akceptační komise akceptovat dílčí Plnění odpovídající Milníku b), e) nebo h) dle Čl. IV. odst.
4.3 této Smlouvy, je Objednatel oprávněn odstoupit od této Smlouvy dle Čl. XI. odst. 11.6 a Objednateli vzniká právo na uhrazení smluvní pokuty dle Čl. X. odst. 10.3.2 této Smlouvy.
5.7 Každé dílčí Plnění se považuje za řádně provedené a předané (akceptované) až podpisem Akceptačního protokolu Objednatelem a Dodavatelem o akceptaci dílčího Plnění bez výhrad.
5.8 Plnění jako celek se považuje za dokončené teprve v okamžiku, kdy bude řádně provedeno, a kdy ze strany Objednatele dojde k podpisu posledního Akceptačního protokolu, tj. „Akceptace – předání ECM/DMS do produkce dle Smlouvy a zahájení poskytování podpory“ bez výhrad. Na tento okamžik je rovněž vázána úhrada zbývající ceny za Plnění, jak bude uvedeno dále.
Článek VI.
Cena a platební podmínky
6.1 Celková cena za Plnění byla stanovena Nabídkou Dodavatele podanou v rámci zadávacího řízení na Veřejnou zakázku a činí 2.385.000,- Kč bez DPH. DPH činí v souladu s aktuálně platnou a účinnou právní úpravou 21 %, tedy 500.850,- Kč. Celková cena včetně DPH tedy činí 2.885.850,- Kč (dále jen „Cena“).
6.2 Jednotlivé dílčí ceny, z nichž je Xxxx složena a jsou uvedeny v následující tabulce, odpovídají nabídkové ceně Dodavatelem uvedené v rámci zadávacího řízení k Veřejné zakázce.
Tabulka č. 1 – Celková cena Plnění
Č.p. | Etapa | Milník | Položka | Cena bez DPH | Cena s DPH |
1. | I. | a) + b) | Předimplementační analýza a NAIM | 250.000,- Kč | 302.500,- Kč |
2. | II. | d) | Školení klíčových uživatelů a administrátorů | 100.000,- Kč | 121.000,- Kč |
3. | II. | e) | Implementace informačního systému | 1.250.000,- Kč | 1.512.500,- Kč |
4. | III. | f) + h) | Ověření produkčního provozu a produkce | 115.000,- Kč | 139.150,- Kč |
Cena Implementace (součet cen položek 1 – 4) | 1.715.000,- Kč | 2.075.150,- Kč | |||
5. | III. | g) | SW Licence ECM/DMS * | 0,- Kč | 0,- Kč |
6. | III. | g) | SW Licence Aplikací VZ, SML a PZ * | 335.000,- Kč | 405.350,- Kč |
7. | III. | g) | SW Licence ostatních IS ** | 335.000,- Kč | 405.350,- Kč |
Cena SW Licencí (součet cen položek 5 – 7) | 670.000,- Kč | 810.700,- Kč | |||
CENA CELKEM (Implementace + SW Licence) | 2.385.000,- Kč | 2.885.850,- Kč |
Poznámky:
* Veškeré SW Licence pro ECM/DMS (technologické), aplikační a ostatní pro podporu provozu budou dodané min. pro 700 uživatelů nebo jako Multilicence. Stejné platí následně i pro SW Maintenance všech SW Licencí.
** Ostatní IS jsou případné další informační systémy, které budou potřebné pro podporu provozu ECM/DMS nebo Aplikací.
6.3 Částky, které budou Dodavateli hrazeny při splnění dále uvedených Milníků a podmínek stanovených touto Smlouvou, jsou uvedeny v následující tabulce (dále jen „Dílčí ceny“).
Tabulka č. 2 – Dílčí ceny (výše fakturovaných částek):
Etapa | Milník | Platební podmínka | Cena bez DPH |
I. | b) | Akceptace NAIM 1) | 428.750,- Kč |
II. | e) | Akceptace testování dle Testovacích scénářů 2) | 771.750,- Kč |
III. | g) | Dodání SW licencí (+ zdrojových kódů a dokumentace) 3) | 670.000,- Kč |
III. | h) | Akceptace – předání ECM/DMS do produkce dle Smlouvy 4) | 514.500,- Kč |
CENA CELKEM | 2.385.000,- Kč |
Poznámky:
1) Maximálně 25 % z ceny implementace (viz Tabulka č. 1, body 1 ..4).
2) Maximálně 45 % z ceny implementace (viz Tabulka č. 1, body 1 ..4).
3) SW Licence (multilicence) pro ECM/DMS a ostatní systémy (viz Tabulka č. 1, body 5, 6 a 7).
4) Maximálně 30 % z ceny implementace (viz Tabulka č. 1, body 1 ..4).
6.4 Cena i Dílčí ceny jsou stanoveny pro celý rozsah Plnění dle této Smlouvy jako ceny konečné, pevné a nepřekročitelné. V Ceně i Dílčích cenách jsou zahrnuty veškeré činnosti včetně všech souvisejících výkonů
a poplatků a veškerých dalších případných nákladů, byť nebyly v Nabídce Dodavatele výslovně uvedeny, zejména veškeré práce, dodávky, služby, součinnost s třetími stranami, doprava do míst plnění a další činnosti nutné pro řádné splnění předmětu této Smlouvy.
6.5 Cenu i Dílčí ceny je možné překročit pouze v případě změny příslušných právních předpisů upravujících výši DPH. V takovém případě bude k Ceně i Dílčím cenám bez DPH účtována DPH ve výši platné k datu uskutečnění zdanitelného plnění.
6.6 Dílčí ceny uvedené v Čl. VI. odst. 6.3 této Smlouvy ( Tabulka č. 2) budou hrazeny Objednatelem na základě řádného daňového dokladu – faktury (dále jen „Faktura“ či „Faktury“), jehož součástí musí být soupis všech poskytnutých dodávek, služeb, prací, apod. a Akceptační protokol dle Čl. V. této Smlouvy. Dílčí ceny budou hrazeny bezhotovostním převodem v české měně na účet Dodavatele uvedený v každé jednotlivé Faktuře a v záhlaví této Smlouvy, a to dle podmínek ujednaných v následujících odstavcích tohoto článku.
6.7 Dodavatel je oprávněn vystavit Objednateli Fakturu vždy do 7 dnů po bezvýhradné akceptaci jednotlivých dílčích Plnění (Milníků) uvedených v Čl. IV. odst. 4.3. této Smlouvy pod písm. b), e), g) a h), a to na základě níže uvedených Akceptačních protokolů:
a) Akceptační protokol o převzetí NAIM Objednatelem;
b) Akceptační protokoly o ukončení testování dle Testovacích scénářů;
c) Akceptační protokoly o předání/převzetí SW licencí a zdrojových kódů a dokumentace;
d) Akceptační protokoly o předání/převzetí ECM/DMS do produkčního provozu.
6.8 Faktury musí obsahovat náležitosti daňového a účetního dokladu v souladu s příslušnými právními předpisy a musí být označeny evidenčním číslem této Smlouvy přiděleným z Centrální evidence smluv Objednatele 180166 (viz také úvodní strana této Smlouvy). Zejména musí obsahovat:
a) označení Faktury a její číslo;
b) identifikační údaje Dodavatele a Objednatele včetně platebních údajů;
c) předmět Xxxxxxx;
d) specifikaci dílčího Plnění dle této Smlouvy;
e) fakturovanou částku v členění bez DPH, včetně DPH a samostatně sazba a výše DPH;
f) den vystavení Faktury a lhůtu splatnosti;
g) jméno a vlastnoruční (elektronický) podpis osoby, jež Fakturu vystavila;
h) případně přílohy;
a musí mít dále náležitosti obchodní listiny dle § 435 Občanského zákoníku.
6.9 Faktura bude Objednateli vždy zaslána ve 1 vyhotovení na adresu Objednatele ve tvaru: Ministerstvo životního prostředí, Odbor Informatiky, Vršovická 1442/65, 100 10 Xxxxx 00, nebo v elektronickém vyhotovení do datové schránky Objednatele: 9gsaax4.
6.10 Lhůta splatnosti Dodavatelem vystavených Faktur činí 21 kalendářních dnů od jejich doručení Objednateli. Závazek úhrady je splněn dnem odepsání příslušné částky z účtu Objednatele.
6.11 V případě, že Faktura nebude mít odpovídající náležitosti či bude chybně vyúčtována cena či DPH, je Objednatel oprávněn vrátit ji ve lhůtě splatnosti Dodavateli s vytknutím nedostatků, aniž by se dostal do prodlení. Nová lhůta splatnosti počíná běžet od okamžiku doručení opravené či doplněné Faktury Objednateli.
6.12 Objednatel neposkytuje žádné zálohové platby.
Článek VII.
Práva a povinnosti Smluvních stran
7.1 Objednatel je povinen poskytovat Xxxxxxxxxx při plnění předmětu této Smlouvy nezbytně nutnou součinnost k úspěšné realizaci Plnění.
7.2 Obě Smluvní strany se zavazují při plnění této Smlouvy vzájemně spolupracovat a poskytovat si veškeré informace potřebné pro řádné plnění svých závazků plynoucích z této Smlouvy a vzájemně se informovat o skutečnostech, které jsou nebo mohou být významné pro plnění této Smlouvy. Dodavatel je povinen Objednateli neprodleně oznámit jakoukoliv skutečnost, která by mohla mít, byť i částečně, vliv na schopnost Dodavatele plnit jeho povinnosti vyplývající z této Smlouvy. Takovým oznámením však Xxxxxxxxx není zbaven povinnosti nadále plnit povinnosti plynoucí mu z této Smlouvy.
7.3 Objednatel se zavazuje předat Dodavateli v co nejkratším možném temínu po podpisu této Smlouvy Smluvními stranami interní pokyny, předpisy a další dokumentaci, která souvisí nebo může souviset s Plněním dle této Smlouvy.
7.4 Dodavatel má povinnost a zavazuje se řídit se při plnění této Smlouvy pokyny a příkazy Objednatele. Povinnost Dodavatele dle ustanovení § 2594 odst. 1 Občanského zákoníku upozornit Objednatele na nevhodnost pokynů není tímto ustanovením dotčena.
7.5 Objednatel se zavazuje poskytnout Dodavateli potřebnou součinnost, a to včetně zajištění součinnosti třetích stran, a to zejména v souvislosti s migrací Dat z nebo do jiného informačního systému nebo v případě integrace s jiným informačním systémem. Dodavatel se zavazuje poskytnout součinnost třetím stranám na pokyn Objednatele.
7.6 Dodavatel je povinen realizovat Plnění řádně a včas podle svých odborných znalostí, zkušeností, praxe, při jeho realizaci bude postupovat s náležitou odbornou péčí, v souladu s touto Smlouvou, jejími přílohami, v souladu se zadávacími podmínkami na Veřejnou zakázku, dle pokynů a požadavků Objednatele a dále v souladu se zákony a obecně závaznými právními předpisy.
7.7 Dodavatel je povinen Objednateli umožnit provést kontrolu Plnění dle této Smlouvy kdykoli po předchozí výzvě Objednatele, a to po celou dobu trvání této Smlouvy.
7.8 Dodavatel není oprávněn postoupit ani převést jakákoliv svá práva či povinnosti vyplývající z této Smlouvy bez předchozího písemného souhlasu Objednatele na třetí osoby.
7.9 Dodavatel se dále zavazuje, že se svým jednáním při plnění Xxxxxxx nedopustí nekalé soutěže a že při plnění této Smlouvy nebude zasahovat do práv třetích osob, ani výsledek činnosti Dodavatele nebude zasahovat nebo jakýmkoliv způsobem porušovat práva třetích osob.
7.10 Dodavatel se ve smyslu ustanovení § 2633 Občanského zákoníku zavazuje, že neužije žádný z výsledků jeho činnosti vzniklý při plnění této Smlouvy k jiným účelům, než ke splnění povinností vyplývajících z této Smlouvy, a žádný z těchto výsledků neposkytne k užití žádné třetí osobě bez předchozího písemného souhlasu Objednatele.
7.11 Dodavatel není oprávněn bez předchozího písemného souhlasu Objednatele provádět jakékoliv zápočty svých pohledávek vůči Objednateli proti jakýmkoliv pohledávkám Objednatele vůči Dodavateli, ani postupovat jakákoliv svoje práva a pohledávky vůči Objednateli na třetí osoby.
Článek VIII. Prohlášení smluvních stran
8.1 Dodavatel prohlašuje, že se v plném rozsahu seznámil s obsahem a povahou Plnění a že je způsobilý k řádnému a včasnému provedení Plnění dle této Smlouvy.
8.2 Dodavatel dále prohlašuje, že jsou mu známy veškeré technické, kvalitativní a jiné nezbytné podmínky potřebné k bezchybné realizaci Plnění, a že disponuje takovými kapacitami a odbornými znalostmi, které jsou třeba k řádné realizaci Plnění, a že rozsah předmětu této Smlouvy bude plnit pouze k tomu řádně proškolenými osobami s odpovídající kvalifikací, případně prostřednictvím poddodavatelů uvedených v Nabídce. Výměna některého či všech těchto poddodavatelů v průběhu plnění Smlouvy je možná pouze s předchozím souhlasem Objednatele. Pokud Dodavatel prokáže, že nový poddodavatel splňuje kvalifikační předpoklady v obdobném rozsahu, Objednatel neodepře bezdůvodně udělit svůj souhlas s výměnou poddodavatele. Pokud Dodavatel prokázal část kvalifikačních předpokladů prostřednictvím poddodavatele, je povinen zajistit, aby poddodavatel poskytoval i tomu odpovídající část Plnění.
8.3 Dodavatel se dále zavazuje k poskytnutí veškeré součinnosti při plnění povinností vyplývajících ze Zákona o ZVZ, zejména k poskytnutí informací, jejichž zveřejnění ukládá § 219 Zákon o ZVZ. Dodavatel se dále zavazuje k poskytnutí součinnosti při plnění povinností vyplývajících z příslušných právních předpisů týkajících se provádění finančních a jiných kontrol, a to zejména ze zákona č. 320/2001 Sb., o finanční kontrole ve veřejné zprávě a o změně některých zákonů (zákon o finanční kontrole), ve znění pozdějších předpisů, a ze zákona č. 255/2012 Sb., o kontrole (kontrolní řád), ve znění pozdějších předpisů, a to i po ukončení této Smlouvy. Dodavatel se zavazuje po dobu trvání Smlouvy postupovat a jednat v souladu se zák. č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), ve znění pozdějších předpisů, a v souladu s vyhláškou č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (vyhláška o kybernetické bezpečnosti), ve znění pozdějších předpisů.
8.4 Dodavatel je povinen dokumenty související s realizací Předmětu této Smlouvy uchovávat nejméně po dobu 10 let od finančního ukončení Plnění, a to zejména pro účely případné kontroly realizace Plnění, ověřování plnění povinností vyplývajících z podmínek daných právními předpisy k archivaci těchto dokumentů (např. zákon č. 563/1991 Sb., ve znění pozdějších předpisů a zákon č. 235/2004 Sb., ve znění pozdějších předpisů). Dodavatel je povinen poskytovat požadované informace a dokumentaci zaměstnancům nebo zmocněncům Objednatele a dále pověřených orgánů (Ministerstvo financí, Nejvyšší kontrolní úřad, příslušný finanční úřad a případně další oprávněné orgány státní správy). Dále je Dodavatel povinen vytvořit výše uvedeným osobám podmínky k provedení kontroly vztahující se k realizaci Plnění a poskytnout jim při provádění kontroly součinnost.
8.5 Dodavatel prohlašuje, že není předlužen a není mu známo, že by bylo vůči němu zahájeno insolvenční řízení. Dále prohlašuje, že vůči němu není vydáno žádné soudní rozhodnutí, či rozhodnutí správního, daňového či jiného orgánu nebo rozhodce na plnění, které by mohlo být důvodem soudní exekuce na majetek Dodavatele, nebo by mohlo mít jakýkoliv negativní vliv na schopnost Dodavatele splnit povinnosti vyplývající z této Smlouvy, a že takové řízení nebylo vůči němu zahájeno a že ani nehrozí zahájení takového řízení.
8.6 Dodavatel je dále povinen zajistit, aby povinnosti uvedené v tomto článku byly dodržovány rovněž jeho případnými poddodavateli.
8.7 Smluvní strany prohlašují, že Plnění dle této Smlouvy není plněním nemožným, a že Xxxxxxx uzavřely po pečlivém zvážení všech možných důsledků.
Článek IX.
Důvěrnost informací a ochrana osobních údajů
9.1 Smluvní strany jsou povinny zajistit utajení získaných důvěrných informací, jež získají nebo získaly na základě nebo v souvislosti s plněním dle této Smlouvy (dále jen „Důvěrné informace“), s výjimkou, pokud tak učiní
(i) s předchozím písemným souhlasem druhé Smluvní strany, (ii) v souladu s požadavky příslušných právních předpisů, platných účetních předpisů nebo rozhodnutí příslušných soudů, rozhodčích soudů či správních
orgánů, anebo (iii) za účelem plnění dle této Smlouvy. Tato povinnost platí bez ohledu na trvání této Smlouvy. Pro účely této Smlouvy se za Důvěrné informace nepokládají žádné informace, jež:
a) jsou nebo se stanou veřejně dostupnými (jinak než na základě neoprávněného sdělení nebo užití);
b) poskytne některé ze Smluvních stran třetí osoba, jež je oprávněna mít takové informace a je oprávněna takové informace zpřístupňovat nebo používat.
9.2 Právo užívat, poskytovat nebo zpřístupnit Důvěrné informace mají Smluvní strany pouze v rozsahu a za podmínek nezbytných pro řádné plnění práv a povinností vyplývajících z této Smlouvy či jiných právních předpisů. Každá ze Smluvních stran je zejména oprávněna sdělovat Důvěrné informace svým poddodavatelům, právním zástupcům, účetním a jiným poradcům, zaměstnancům, zástupcům a představitelům, avšak s tím, že taková Smluvní strana zajistí, aby ty osoby, jež budou mít přístup k Důvěrným informacím, nezpřístupňovaly Důvěrné informace třetím osobám.
9.3 Závazky obsažené v tomto článku týkající se zachovávání důvěrného charakteru informací zůstanou v plném rozsahu platné a účinné nehledě na jakékoli ukončení platnosti této Smlouvy po dobu 5 let od ukončení její účinnosti nebo splnění této Smlouvy.
9.4 Dodavatel uzavřením této Smlouvy výslovně souhlasí, aby tato Smlouva a/nebo její jakákoliv část byla Objednatelem zveřejněna způsobem umožňujícím neomezenému počtu třetích osob dálkový přístup prostřednictvím elektronických nástrojů E-ZAK a NEN, a dále v Informačním systému Registr smluv, popř. na dalších místech v souladu s příslušnými právními předpisy.
9.5 Dodavatel je povinen při plnění této Smlouvy postupovat v souladu se zákonem č. 110/2019 Sb., o zpracování osobních údajů, ve znění pozdějších předpisů. Dodavatel se zavazuje pro případ, že v rámci plnění Smlouvy bude zpracovávat osobní údaje, že je bude chránit a nakládat s nimi plně v souladu s příslušnými právními předpisy, a to i po ukončení plnění Smlouvy. Smluvní strany se v případě zpracování osobních údajů ve smyslu nařízení Evropského parlamentu a rady (EU) č. 2016/679, o ochraně fyzických osob v souvislosti se zpracováním údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (obecné nařízení o ochraně osobních údajů) (dále jen „GDPR“), popř. ve smyslu příslušných ustanovení zákona č. 110/2019 Sb., o zpracování osobních údajů, ve znění pozdějších předpisů, zavazují uzavřít smlouvu o zpracování osobních údajů podle tohoto nařízení, popř. zákona.
Článek X.
Záruka, odpovědnost za škodu, sankce
10.1 Záruka
10.1.1 Dodavatel poskytuje Objednateli záruku, že ECM/DMS bude mít vlastnosti stanovené zadávací dokumentací k Veřejné zakázce, jakož i v této Smlouvě, jejích přílohách a NAIM, a to po celou dobu trvání této Smlouvy, a také po celou dobu následného provozu ECM/DMS podle „Smlouvy o zajištění rozšířené servisní podpory a rozvoje IS – ECM/DMS“ (smlouva upravující následnou podporu provozu ECM/DMS, která byla Smluvními stranami uzavřena v souvislosti s touto Smlouvou téhož dne).
10.1.2 Záruční doba počíná běžet okamžikem ukončení realizace Plnění, tzn. dnem podpisu posledního Akceptačního protokolu (tj. „Akceptace – předání ECM/DMS do produkce dle Smlouvy a zahájení poskytování podpory“) Objednatelem a Dodavatelem bez Výhrad.
10.1.3 Záruční doba se nevztahuje na:
a) vady vzniklé použitím věcí a/nebo informací (příkazů) předaných Dodavateli Objednatelem, u nichž Dodavatel nemohl zjistit jejich nevhodnost ani při vynaložení veškeré odborné péče;
b) vady způsobené Objednatelem neodborným zacházením nebo údržbou.
10.1.4 V případě výskytu jakékoliv vady má Objednatel povinnost bez zbytečného odkladu písemně oznámit vadu Xxxxxxxxxx, který její odstranění provede na svůj náklad a bez zbytečného odkladu po obdržení takové informace s přihlédnutím k povaze vady. O předmětu a termínu odstranění vady bude Objednatelem a Dodavatelem sepsán písemný záznam.
10.1.5 Dodavatel je povinen v návaznosti na Objednatelem uplatněnou vadu zahájit práce na jejím odstranění, a to i v případě, že svoji odpovědnost neuznává. V případě, že bude prokázáno, že Dodavatel za takovou vadu neodpovídá, uhradí mu Objednatel náklady účelně vynaložené na odstranění vady. Úhrada bude provedena do 21 kalendářních dnů od odstranění vady, resp. doručení vyúčtování účelně vynaložených nákladů.
10.2 Odpovědnost za škodu
10.2.1 Každá Smluvní strana je odpovědná za škodu způsobenou druhé Smluvní straně porušením povinností stanovených touto Smlouvou dle příslušných ustanovení Občanského zákoníku.
10.2.2 Dodavatel se výslovně zavazuje na své náklady nahradit Objednateli veškerou škodu, která Objednateli vznikne v důsledku nebo v souvislosti s tím, že Objednatel poruší užíváním Plnění či jeho dílčích částí práva duševního vlastnictví třetích osob.
10.3 Sankce
10.3.1 V případě prodlení Objednatele s úhradou řádně vystavených a doručených Faktur, je Objednatel povinen uhradit Dodavateli úrok z prodlení z dlužné částky ve výši stanovené příslušnými právními předpisy.
10.3.2 Bude-li Dodavatel v prodlení se splněním Milníků označených v Harmonogramu písm. b), e) a h) (viz také Čl. IV. odst. 4.3. této Smlouvy), je povinen zaplatit Objednateli smluvní pokutu ve výši 0,1 % z Ceny za každý, byť i započatý den prodlení se splněním každého jednotlivého Milníku.
10.3.3 Bude-li Dodavatel v prodlení se splněním kteréhokoliv z ostatních Milníků uvedených v Harmonogramu a v Čl. IV. odst. 4.3. této Smlouvy (tedy vyjma Milníků uvedených v odst.
10.3.2. tohoto článku), je povinen zaplatit Objednateli smluvní pokutu ve výši 0,05 % z Ceny za každý, byť i započatý den prodlení se splněním každého jednotlivého Milníku.
10.3.4 Bude-li Dodavatel v prodlení s odstraněním Výhrad uvedených v jednotlivých Akceptačních protokolech (viz Čl. V. odst. 5.5 této Smlouvy), je Dodavatel povinen zaplatit Objednateli smluvní pokutu ve výši 1.000,- Kč za každý, byť i započatý den prodlení a každou jednotlivou Výhradu.
10.3.5 V případě, že Dodavatel poruší, popř. nesplní jakoukoliv svoji další povinnost upravenou touto Smlouvou, a neučiní tak ani v dodatečné lhůtě poskytnuté mu Objednatelem v písemné výzvě Objednatele ke splnění takové povinnosti, je Dodavatel povinen zaplatit Objednateli smluvní pokutu ve výši 5.000,- Kč za každý jednotlivý případ porušení smluvní povinnosti.
10.3.6 V případě, že Dodavatel poruší, popř. nesplní některou ze svých smluvních povinností, jejíž porušení, popř. nespnění zakládá dle této Smlouvy právo Objednatele okamžitě odstoupit od této Smlouvy, je Objednatel bez ohledu na skutečnost, zda využije svého práva na odstoupení od této Smlouvy, oprávněn účtovat Dodavateli smluvní pokutu ve výši 100.000,- Kč za každý jednotlivý případ porušení takové povinnosti.
10.3.7 Smluvní pokuta je splatná do 21 kalendářních dnů ode dne doručení písemné výzvy k její úhradě Dodavateli. Závazek úhrady se považuje za dodržený, je-li nejpozději v poslední den lhůty připsána předmětná částka na účet Objednatele.
10.3.8 Uplatněním práv z vad či uplatněním jakékoliv smluvní pokuty dle této Smlouvy není dotčena povinnost Dodavatele nahradit škodu vzniklou Objednateli porušením smluvní povinnosti, které se smluvní pokuta týká. Objednatel je oprávněn požadovat náhradu škody v plné výši bez ohledu na ujednanou smluvní pokutu, a to včetně škody v rozsahu veškerých účelně vynaložených nákladů na odstranění vad na realizovaném Plnění.
10.3.9 Právo Objednatele požadovat po Dodavateli zaplacení smluvní pokuty neplatí v případech, kdy plnění této Smlouvy bylo znemožněno zásahem vyšší moci. Tuto skutečnost je povinen Dodavatel Objednateli bezodkladně sdělit a je také povinen existenci takových okolností prokázat.
Článek XI.
Doba trvání Smlouvy, výpověď, odstoupení a další způsoby ukončení Smlouvy
11.1 Tato Smlouva se uzavírá na dobu určitou dle Čl. II. odst. 2.1 a 2.2 této Smlouvy, při splnění všech povinností Dodavatele vyplývajících z této Smlouvy.
11.2 Před uplynutím výše uvedené doby lze tuto Smlouvu ukončit na základě vzájemné dohody Objednatele a Dodavatele, výpovědí Smlouvy, nebo odstoupením od Smlouvy dle odst. 11.5 a následujících odstavců tohoto článku, a dále v souladu s příslušnými ustanoveními Občanského zákoníku.
11.3 Uvedené způsoby ukončení Smlouvy musí být Objednatelem a Dodavatelem provedeny vždy v písemné formě a příslušné dokumenty obsahující příslušné ukončení Smlouvy musí být druhé Smluvní straně řádně doručeny. V případě pochybností se má za to, že k doručení daného dokumentu došlo 3. den po jeho odeslání Objednateli či Xxxxxxxxxx.
11.4 Objednatel je oprávněn vypovědět tuto Smlouvu kdykoliv, a to i bez udání důvodu, přičemž výpovědní doba v délce 2 kalendářních měsíců počíná běžet dnem následujícím po dni doručení písemné výpovědi Dodavateli.
11.5 Dodavatel je oprávněn od této Smlouvy odstoupit v souladu s Občanským zákoníkem pouze pro podstatné porušení Smlouvy ze strany Objednatele, kterým se rozumí prodlení s úhradou Faktury po dobu delší než 60 kalendářních dnů. Dodavatel je oprávněn od této Smlouvy odstoupit nejdříve poté, kdy na neplnění závazků Objednatele písemně upozornil a poskytl mu odpovídající lhůtu k nápravě.
11.6 Objednatel je oprávněn od této Smlouvy odstoupit v případě, že:
a) Dodavatel bude v prodlení se splněním Milníků označených v Harmonogramu písm.
b), e) a h) (viz také Čl. IV. odst. 4.3. této Smlouvy) o dobu delší než 20 dnů;
b) Dodavatel bude v prodlení se splněním kteréhokoliv z ostatních Milníků uvedených v Harmonogramu a v Čl. IV. odst. 4.3. této Smlouvy (tedy vyjma Milníků uvedených v shora pod písm. a) tohoto článku) o dobu delší než 30 dnů;
c) Dodavatel bude v prodlení s odstraněním Výhrad uvedených v jednotlivýchu Akceptačních protokolech o dobu delší než 15 dnů;
d) Dodavatel bude poskytovat Plnění v rozporu s touto Smlouvou a jejími přílohami, zadávacími podmínkami na Veřejnou zakázku, Nabídkou Dodavatele, popř. v rozporu s platnými právními předpisy a normami, a Dodavatel nenapraví takové vadné plnění ani v dodatečné lhůtě stanovené mu Objednatelem v písemné výzvě k sjednání nápravy.
11.7 Objednatel je dále oprávněn odstoupit od této Smlouvy zejména v následujících případech:
a) zjistí-li, že Dodavatel nabízel, dával, přijímal nebo zprostředkovával nějaké hodnoty s cílem ovlivnit chování nebo jednání kohokoliv, ať již státního úředníka nebo někoho jiného, přímo nebo nepřímo,
v zadávacím řízení nebo při provádění Smlouvy; nebo
b) zjistí-li, že Dodavatel zkresloval skutečnosti za účelem ovlivnění zadávacího řízení nebo provádění Smlouvy ke škodě Objednatele, včetně užití podvodných praktik k potlačení a snížení výhod volné a otevřené soutěže.
11.8 Účinky odstoupení nastávají dnem doručení písemného oznámení o odstoupení Xxxxxxxxxx. V případě odstoupení se tato Smlouva od počátku ruší a Objednatel a Dodavatel jsou povinni vypořádat se podle zásad o vydání bezdůvodného obohacení podle Občanského zákoníku.
11.9 Odstoupení od Xxxxxxx se nedotýká práva na náhradu škody vzniklé z porušení smluvní povinnosti, práva na zaplacení smluvní pokuty a úroku z prodlení, pokud již dospěl, ani ujednání, které má vzhledem ke své povaze zavazovat Smluvní strany i po odstoupení od Smlouvy, tj. zejména ani ujednání o způsobu řešení sporů a volbě práva. Obdobné platí i pro předčasné ukončení Smlouvy jiným způsobem.
Článek XII. Závěrečná ustanovení
12.1 Za Objednatele jsou v záležitostech plnění této Smlouvy a poskytování Plnění oprávněni jednat:
- Xxx. Xxxx Xxxxxxxxx (email: xxxx.xxxxxxxxx@xxx.xx, tel.: x000 000 000 000);
- Xxx. Xxxxx Xxxxx (email: xxxxx.xxxxx@xxx.xx, tel.: x000 000 000 000).
Za Dodavatele jsou v záležitostech této Smlouvy a poskytování Plnění oprávněni jednat:
- Xxx. Xxxxx Xxxxxxx (email: XXxxxxxx@xxxxxxxxxx-xx.xx, tel.: x000 000 000 000);
tel.: x000 000 000 000).
-
-
12.2 Tato Smlouva, práva a povinnosti Smluvních stran z ní vyplývající se řídí právním řádem České republiky, zejména příslušnými ustanoveními Občanského zákoníku.
12.3 Případná neplatnost, neúčinnost, neúplnost či nejasnost některého ustanovení této Smlouvy nemá za následek neplatnost ostatních ustanovení této Smlouvy či Smlouvy jako celku, přičemž Smluvní strany bezodkladně takové ustanovení nahradí novým ustanovením, které nejlépe vystihne vůli Smluvních stran a bude se svým obsahem nejvíce blížit účelu původního ustanovení.
12.4 Tato Smlouva může být, s výjimkou odst. 12.1 tohoto článku, měněna nebo doplňována pouze formou písemných vzestupně číslovaných dodatků odsouhlasených a podepsaných oběma Smluvními stranami.
12.5 Veškeré případné spory vzniklé na základě této Smlouvy budou řešeny primárně dohodou Smluvních stran, v případě přetrvávající neshody pak před příslušnými obecnými soudy České republiky.
12.6 Smluvní strany na sebe přebírají nebezpečí změny okolností v souvislosti s právy a povinnostmi Smluvních stran vzniklými na základě této Smlouvy. Smluvní strany vylučují uplatnění ustanovení § 1765 odst. 1, § 1766 a § 2620 Občanského zákoníku na svůj smluvní vztah založený touto Smlouvou.
12.7 Tato Smlouva nabývá platnosti dnem jejího podpisu oběma Smluvními stranami a účinnosti dnem jejího uveřejnění v Informačním systému Registr smluv (dále jen „ISRS“) dle podmínek stanovených zákonem č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv (zákon o registru smluv), ve znění pozdějších předpisů. Dodavatel bezvýhradně souhlasí s uveřejněním celého znění této Smlouvy včetně cenových údajů a příslušných metadat v ISRS, v elektronických nástrojích E-ZAK a NEN, popř. na dalších místech, v souladu s příslušnými právními předpisy. Uveřejnění této Smlouvy provede Objednatel.
12.8 Tato Smlouva je vyhotovena ve 4 stejnopisech s platností originálu, přičemž každá Smluvní strana obdrží 2 vyhotovení.
12.9 Nedílnou součástí této Smlouvy jsou tyto přílohy:
a) Příloha č. 1 – Věcné (manažerské) zadání;
b) Příloha č. 2 – Funkční (business) požadavky;
c) Příloha č. 3 – Ne-Funkční (technické) požadavky;
d) Příloha č. 4 – Nabídka Xxxxxxxxxx;
e) Příloha č. 5 – Akceptační protokol.
Smluvní strany prohlašují, že tato Xxxxxxx vyjadřuje jejich svobodnou, vážnou, určitou a srozumitelnou vůli prostou omylu. Smluvní strany si Xxxxxxx přečetly, s jejím obsahem souhlasí, což stvrzují vlastnoručními podpisy.
Za Objednatele: Za Dodavatele:
V Praze, dne ………………………………… V Brně, dne …………………………………
Ing. Xxxxx Digitálně podepsal
Xxx. Xxxxx Xxxxxxx,
…………………………………………………
Xxx. Xxxx Xxxxxxxxx
Te…l…e……c……k……ý……, M…B……A…
Ing. Xxxxx TeleckýDatum: 2020.02.08
ředitelka odboru informatiky
MBA
jednatel
11:46:01 +01'00'
Česká republika – Ministerstvo životního prostředí
Digitálně
TECHNISERV IT, spol. s r. o.
Digitálně
Xxx. Xxxx
Xxxxxxx vá
podepsal Xxx. Xxxx Xxxxxxxxx Datum: 2020.02.10
15:09:28 +01'00'
Mgr. Xxxx xxxxxxxx Mgr. Xxxx
Datum:
Xxxxxxx
Xxxxxxx 2020.02.04
13:14:29 +01'00'
Příloha č. 1 – Věcné (manažerské) zadání
VĚCNÉ (MANAŽERSKÉ) ZADÁNÍ
Obsah
1. Současný stav 19
2. Cíle projektu 19
3. Předpoklady 20
4. Obecné požadavky (např. architektura, bezpečnost, …) 20
4.1. ICT architektura 20
4.1.1. Datové (LAN/WAN) sítě a komunikace 20
4.1.2. Servery (Serverové platformy a OS) 21
4.1.3. Databáze (dB Servery) 21
4.1.4. WWW nebo Aplikační servery 21
4.1.5. Klientské stanice (PC, notebooky, smart zařízení – telefony, tablety) 21
4.1.6. Systémové služby (SSO, SIEM, zálohování a archivace, …) 22
4.1.7. Monitoring (sběr logů a monitoring zranitelnosti) 22
4.1.8. Síťové prostředí 23
4.2. Bezpečnost 23
4.2.1. Vzdálený přístup uživatelů 23
4.3. Migrace dat z agendy eSmlouvy 23
4.4. Integrace na interní systémy 24
4.4.1. Seznam potenciálních integrací 24
4.4.2. Detailní popis vybraných integrací 24
5. Minimální požadavky na Projektové řízení 25
5.1. Organizace – projektový tým, jednání a zápisy 25
5.2. Řídící výbor (ŘV) 26
5.3. Vedoucí projektu (VP) 26
5.4. Členové projektového týmu 27
5.5. Projektový tým (PT) 27
5.6. Práva a povinnosti Objednatele 27
5.7. Práva a povinnosti Dodavatele 27
6. Požadavky na Řízení projektu 27
6.1. Plán (harmonogram) projektu 27
6.2. Řízení projektu 28
6.3. Dokumentace projektu 28
6.4. Komunikace v rámci projektu 28
6.5. Změnové řízení – žádost o změnu, její vyhodnocení a vyřešení 28
6.6. Akceptace projektu a dílčích plnění (milníků) dle plánu projektu 28
6.6.1. Akceptační procedura 28
6.6.2. Závěrečné stanovisko 29
6.6.3. Výhrady 29
6.6.4. Splnění akceptačních kritérií 29
6.6.5. Akceptace projektu 29
7. Minimální požadavky na Etapy projektu 30
7.1. Předpokládané etapy projektu 30
7.2. Předpokládaný harmonogram plnění 30
8. Dokumentace 30
9. Příklad designu formulářů 32
9.1. Evidenční list Xxxxxxx 32
9.2. Krycí list Smlouvy 33
9.3. Legenda k příkladům designu formulářů 35
10. Procesy 36
10.1. Vzorový business proces – Xxxxxxx xxxxxxx (VZ) 36
10.2. Vzorový dokumentový proces – Evidenčního listu VZ 38
10.3. Vzorový dokumentový proces – Krycího listu Smlouvy k VZ 40
10.4. Vzorový business proces – Projektové záměry (PZ) 42
11. Uživatelské role 44
12. Dokumentové typy a jejich vybraná metadata 45
12.1. Xxxxxx Xxxxxxxxx zakázek a Smluv 45
12.1.1. Xxxxxxx xxxxxxx (VZ) 45
12.1.2. Smlouvy 46
12.2. Agenda Projektových záměrů 48
13. Úložiště el. dokumentů 49
1. SOUČASNÝ STAV
V rámci Ministerstva životního prostředí (dále jen „MŽP“ nebo „Objednatel“) v současné chvíli neexistuje jednotné řešení, služba nebo produkt – obecně informační systém, který by umožňoval unifikovaně spravovat a procesně řídit interní elektronické (digitální) dokumenty a postupně tak přispěl k automatizaci, elektronizaci a nahrazení ručního – papírového zpracování, řízení, sdílení a uložení analogový dokumentů a zároveň redukoval potřebu distribuce a sdílení el. dokumentů pomocí systému elektronické pošty (IBM Notes/Domino) anebo osamocených – individuálních aplikací, v rámci kterých se historicky nějaká elektronická správa a řízení části dokumentů realizovat podařilo.
Využívání správy a řízení papírových dokumentů, elektronických dokumentů v rámci elektronické pošty, ukládání elektronických dokumentů na osobní a sdílené (síťové) disky vede k:
- nemožnosti rychlého dohledání dokumentů; anebo
- minimálně dlouhé odezvě při jejich hledání;
- nemožnosti snadného sdílení určitých typů dokumentů;
- tvorbě duplicit a multiplicit v dokumentech;
- nemožnosti sledování verzí jednotlivých dokumentů;
- nemožnosti řízení dokumentů pomocí předem stanovených nebo i ad-hoc procesů;
- zvýšenému riziku ztráty dokumentů a zneužití důvěrných informací;
- zvýšenému nároku na kapacitu osobních, ale hlavně síťových úložišť.
Jak už bylo výše zmíněno, některé typy elektronických dokumentů jsou evidovány a někdy i uloženy v technologicky, funkčně, a především morálně zastaralém groupware systému IBM Notes/Domino a nad ním vytvořených aplikacích. Tento systém nebyl společností IBM updatován nebo upgradován již od roku 2013 a v současné době již nesplňuje nároky, které jsou v současné době kladené na práci s elektronickými dokumenty, jejich metadaty a na procesní řízení.
Z těchto, ale především z výše uvedených důvodů hledá ministerstvo informační systém pro správu a řízení dokumentů (ECM/DMS), který by jeho požadavky pokryl a který je v současné chvíli technologicky a funkčně
„IN“ a má vyhlídky, že bude takový i v blízké budoucnosti – minimálně v horizontu dalších 5 … 10 let.
2. CÍLE PROJEKTU
Hlavní cíl, projektu výběru, implementace a provozu informačního systému pro správu a řízení vybraných elektronických dokumentů, je primárně usnadnění:
- tvorby (šablony, verzování, …);
- uložení;
- připomínkování a schvalování (tzv. procesní řízení – workflow);
- zabezpečení;
- bezpečného a rychlého sdílení;
- avizování;
- rychlého vyhledání;
- monitorování; a
- auditu, při správě elektronických dokumentů.
Vše výše uvedené by navíc mělo fungovat v uživatelsky přívětivém, jednoduchém a moderním grafickém prostředí pro různé typy koncových zařízení (PC/notebooky, tablety a chytré telefony) a různé typy klientů (Win, Android, iOS).
ECM/DMS by měl přispět ke zvýšení produktivity práce, ke zrychlení procesů – snížení potřebného času na vyřízení vybraných věcí – žádosti, vytvoření stanoviska, schválení a vypsání veřejné zakázky, schválení návrhu projektových záměrů, uzavření smlouvy, …. Tento systém by měl přispět ke snížení rizika, že se nějaký dokument ztratí, že někdo nepracuje s aktuální verzí dokumentu anebo, že se příslušný dokument – informace nedostala včas ke správnému adresátovi.
Informační systém ECM/DMS bude hned od své počáteční implementace sloužit pro celou organizaci (ministerstvo) a její dokumenty, procesy – agendy, které svojí povahou zasahují všechny sekce, odbory
a samostatná oddělení, a tedy většinu zaměstnanců a spolupracovníků ministerstva. Je velmi pravděpodobné, že bude tento informační systém v budoucnu sloužit i pro vybrané resortní organizace a jejich uživatele.
Informační systém by měl splňovat aktuální nároky na standardy nebo zvyklosti v oblasti grafické přehlednosti, uživatelské přívětivosti, jednoduchosti obsluhy a ergonomičnosti s ohledem na práci běžného zaměstnance (uživatele) organizace. ECM/DMS musí zabezpečit usnadnění, zpřehlednění a zefektivnění práce jednotlivých uživatelů, kteří se účastní řízení (procesů) a správy (uložení a sdílení) jednotlivých typů dokumentů.
Hlavní cíl(e) projektu v sobě zahrnují následující dílčí cíle:
- snadné a rychlé řízení a správu elektronických dokumentů;
- zefektivnění a zrychlení schvalovacích (obecně oběhu) procesů el. dokumentů;
- centralizace a sjednocení způsobu ukládání a sdílení el. dokumentů;
- minimalizace oběhu papírových dokumentů;
- uživatelsky přívětivé rozhraní;
- rychlé a snadné dohledání el. dokumentů (vlastní, k vyřízení, metadata, fulltext);
- integrace s ESSS (Elektronická spisová služba) AthenA;
- integrace na služby vytvářející důvěru – el. podpis, pečeť, časové razítko;
- integrace s emailovým systémem;
- integrace s MS Office;
- integrace na ekonomický systém JASU;
- migrace dat ze stávající agendy – aplikace eSmlouvy;
- snadná správa identifikace, autentizace a autorizace uživatelů pro práci s el. dokumenty;
- snadná rozšiřitelnost ECM/DMS – agendy (objekty), dokumentové typy, metadata, šablony, bez nutnosti programování, ale pouze na základě konfigurace zaškolenou osobou;
- snadná rozšiřitelnost procesů (workflow) – upravení stávajícího, vytvoření nového pomocí konfigurace zaškolenou osobou nebo sestavení ad-hoc procesu uživatelem ke konkrétnímu dokumentu;
- zvýšení bezpečnosti dle interních, národních a EU předpisů nebo nařízení.
Podrobné požadavky, k výše uvedeným hlavním a dílčím cílům, jsou rozepsané v Příloze č. 8 – Funkční (business) požadavky zadávací dokumentace.
3. PŘEDPOKLADY
Implementace ECM/DMS předpokládá migraci stávajících dat (metadat a dokumentů) z agendy – aplikace eSmlouvy. Implementace ECM/DMS dále předpokládá integraci na:
- Lightweight Directory Access Protokol (LDAP);
- MS Office;
- ESSS (Elektronická spisová služba – AthenA);
- EKIS (Ekonomický informační systém – JASU);
- Emailový systém (IBM Notes/Domino);
- Služby vytvářející důvěru (el. podpis/pečeť/razítko).
Detailní požadavky na tyto integrace a migraci dat budou definovány v rámci výstupu z předimplementační analýzy, což bude Návrh implementace.
4. OBECNÉ POŽADAVKY (NAPŘ. ARCHITEKTURA, BEZPEČNOST, …)
4.1. ICT architektura
Vybraný ECM/DMS musí akceptovat standardní systémové prostředí Objednatele a měl by být snadno implementovatelný a provozovatelný do tohoto prostředí.
4.1.1. Datové (LAN/WAN) sítě a komunikace
- Klientské stanice připojeny rychlostí 1 Gbps;
- Servery připojeny typicky rychlostí 1 až 10 Gbps;
- Adresace dle RFC 1918 (10.x.y.z, 172.16-31.x.y, 192.168.x.y).
4.1.2. Servery (Serverové platformy a OS)
- Platforma architektury x86 – MS Windows Server 2012 R2 DataCenter;
- Platforma SUSE Linux Enterprise Server;
- Platforma VMware vSphere 6.
4.1.3. Databáze (dB Servery)
Data standardních IS jsou uložena v databázích MS SQL. Objednatel aktuálně nedisponuje volnými licencemi, které je možné použít pro implementaci systému ECM/DMS. V případě, že řešení bude využívat jinou databázi (dB), poskytne Objednatel pro dB prostředí následující konfiguraci virtuálních serverů na platformě VMware:
- 2 až 4 VCPU (virtuální CPU);
- min. 16 GB RAM;
- vzdálené úložiště prostřednictvím sítě SAN – 500 GB;
- konektivita min. 1 Gbps;
- operační systém Linux nebo MS Windows Server (viz odst. 4.1.2).
4.1.4. WWW nebo Aplikační servery
Objednatel poskytne následující konfiguraci pro provoz virtuálních aplikačních a WWW serverů (v případě, že budou samostatně) na platformě VMware:
A. Primární aplikační server
- 2 VCPU (virtuální CPU);
- min. 16 GB RAM;
- vzdálené úložiště prostřednictvím sítě SAN – 200 GB;
- konektivita min. 1 Gbps;
- operační systém Linux nebo MS Windows Server (viz odst. 4.1.2).
B. Primární WWW server
- 2 VCPU (virtuálních CPU);
- min. 16 GB RAM;
- vzdálené úložiště prostřednictvím sítě SAN – 100 GB;
- konektivita min. 1 Gbps;
- operační systém Linux nebo MS Windows Server (viz odst. 4.1.2).
4.1.5. Klientské stanice (PC, notebooky, smart zařízení – telefony, tablety)
A. Osobní počítače typu IBM-PC kompatibilní (x86):
- MS Windows 7 a vyšší;
- Notebooky s MS Windows 7 a vyšší.
B. Další SW na klientské části je:
- TCP/IP síťové služby;
- MS Office 2013 a vyšší;
- Internetový prohlížeč MS Internet Explorer, Mozilla Firefox, Google Chrome;
- Adobe Acrobat Reader;
- Symantec EndPoint Protection.
Instalace další provozní platformy na klientskou stanici (např. typu IBM Notes) nutné pro fungování systému ECM/DMS není preferována.
Instalace programového vybavení (neboli tzv. „tlustého klienta“, v případě jeho dodání) na klientskou stanici je prováděna primárně 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í je prováděna centrálně pomocí Micro Focus ZENworks.
Není přípustné na klientskou stanici ukládat data trvalé hodnoty (tzn. finální verze dokumentů – souborů), taková data je nutno ukládat pouze na centrální disky – centrální úložiště.
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, případně na aplikačním serveru.
Na klientské stanici pracuje uživatel standardně pod právy přidělené skupině „Power Users“. Výjimky pro potřeby instalace 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. Obdobné požadavky platí i pro registrování knihoven a vytváření nebo změny hodnot klíčů v registrech.
Při realizaci řešení ECM/DMS je nutné zajistit, aby programové komponenty tohoto řešení nebyly v rozporu s komponentami dalších provozovaných IS (např. klient ekonomického systému, komponenty spisové služby, antivir apod.). Realizované řešení ECM/DMS musí být provozovatelné v systémovém prostředí Objednatele a současně nesmí narušovat funkčnost ostatních IS.
4.1.6. Systémové služby (SSO, SIEM, zálohování a archivace, …)
A. Zálohování IS a dat
Zálohování prostředí probíhá pomocí nástroje „Veeam Availability Suite Enterprise Plus for VMware“. Poskytovatel musí dodat současně s implementací ECM/DMS postupy a popis způsobu zálohování a obnovy SW řešení v prostředí Objednatele.
B. SIEM (sběr bezpečnostních logů)
Sběr a vyhodnocování bezpečnostních logů je u Objednatele řešeno centrálně systémem „SIEM QRadar“ od firmy IBM. SW řešení ECM/DMS musí podporovat zpracování logů ve strojově čitelné podobě na vzdálený server např. syslogem. Pro správnou interpretaci a syntaktickou analýzu (parsing) je nutný popis struktury logu.
C. Elektronická pošta
- Server – IBM Domino ve verzích 8.5.x a 9.x.x;
- Klient – IBM Notes ve verzích 8 a 9.
D. Centrální úložiště – centrální disky
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ů Objednatele. Zálohování dat centrálních diskových kapacit je zajištěno (viz odst. 0.0.0./X.).
E. Internet – DMZ
- Email je povolen všem uživatelům prostřednictvím systému IBM Domino/Notes a MTA serverů. Maximální velikost zprávy je však omezena pouze 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.
F. Synchronizace času
Čas na všech komponentách sítě Objednatele 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.
4.1.7. Monitoring (sběr logů a monitoring zranitelnosti)
- SIEM IBM QRadar – sběr bezpečnostních logů, monitoring zranitelností;
- Zabbix – dohledový systém.
Z důvodu koncepční konsolidace datové základny preferuje Objednatel řešení realizované nad výše uvedenými platformami. Je-li dodáno SW řešení s využitím jiných platforem, je Dodavatel povinen dodat i potřebné licence. V každém případě cena SW řešení musí obsahovat všechny potřebné licence k provozu implementovaného SW řešení.
4.1.8. Síťové prostředí
A. Síťový operační systém
Pro zajištění provozu základních síťových funkcí se využívá portfolio produktů Novell (Micro Focus), které představují zajištění sdílených síťových disků, tisku na síťových tiskárnách, adresářové služby a SW pro vzdálenou správu počítačů, včetně vzdálené instalace programů a aktualizací.
Každý uživatel má založen účet v adresářové službě eDicrectory, kde má nadefinována členství v jednotlivých skupinách, namapované síťové disky a práva k příslušným síťovým tiskárnám.
B. Systém pro spolupráci a komunikaci
Pro spolupráci a komunikaci mezi uživateli se využívá groupware systém IBM Domino/Notes. Na této platformě se kromě systémových služeb (doručování emailů, groupware plánování, úkolování a sdílení) využívá i velké množství menších, či větších aplikací (rezervace prostředků, systém žádanek, pomocné evidence a registry, …), ale i informačních systémů (redakční systém webových stránek, intranet, registr CITES apod.).
Dodavatel je povinen zahrnout do nabídky veškeré náklady na případné pořízení a provoz jiných SW a SW licencí, které bude muset dodat do ICT architektury Objednatele, pokud ta je vůbec nezahrnuje nebo nezahrnuje v dostatečném množství, počtu nebo pro poskytnutí dostatečného výkonu či licenčního pokrytí!
4.2. Bezpečnost
V souladu s vnitřními bezpečnostními předpisy (bezpečnostní politikou) Objednatele v oblasti informačních a komunikačních technologií bude informační systém ECM/DMS zabezpečen proti hrozbám ohrožujícím jeho dostupnost, přístupnost (autentizace a autorizace), důvěrnost, integritu a auditovatelnost následovně:
- Důvěrnost – řízený přístup – práva přístupu dle rolí.
- Integrita – použití https protokolu a databázové transakce.
- Dostupnost – řešení bude provozováno na privátním cloudu, který svými nástroji zajistí požadovanou dostupnost. Dodavatel toto musí zohlednit v případě licenční politiky dodávaného řešení.
- Identifikace/Autentizace – autentizace uživatelů je prováděna prostřednictvím systému eDirectory/LDAP.
- Autorizace – systém ECM/DMS poskytne nástroje pro řízení uživatelských přístupů a oprávnění. Role administrátor v základní konfiguraci nesmí mít přístup k uživatelským datům (dokumentům a metadatům), tj. přihlášený uživatel s rolí administrátor nemůže pracovat s dokumenty jiných uživatelů.
- Prokazatelnost – stopa (záznam) v auditním logu.
Vybrané zdroje a služby serverů jsou pravidelně monitorovány a skenovány produktem Zabbix.
Součástí akceptace SW řešení bude provedení penetračního testu a skenu známých zranitelností. ECM/DMS musí splnit požadavky dle metodiky OWASP týkající se odolnosti vůči definovaným zranitelnostem.
4.2.1. Vzdálený přístup uživatelů
Objednatel připojuje své uživatele ze sítě Internet do vnitřní sítě prostřednictvím „CheckPoint Web Portal“, který zajišťuje dvou-faktorovou autentizaci.
Podrobné požadavky na bezpečnost jsou definované dále v Příloze č. 9 – Ne-Funkční (technické) požadavky zadávací dokumentace.
4.3. Migrace dat z agendy eSmlouvy
Současná agenda eSmlouvy je řešena na platformě IBM Notes/Domino jako Notes aplikace, která v sobě ukládá metadata primárně definovaná Evidenčním listem Zakázky a Krycím listem Smlouvy a soubory – dokumenty smluv. Tato data (metadata a soubory – dokumenty) bude nutné migrovat do implementovaného ECM/DMS.
Současný dodavatel (společnost Sysnet) agendy eSmlouvy je připravena na podporu této migrace.
Detailní návrh migrace očekává Objednatel zpracovaný od Dodavatele v rámci předimplementační analýzy, tedy v dokumentu Návrh implementace (NAIM).
4.4. Integrace na interní systémy
4.4.1. Seznam potenciálních integrací
Systém | Popis integrace |
ECM/DMS – MS Office plug-in | Předpokládaný plug-in do aplikace MS Office zajišťující integraci mezi MS Office a ECM/DMS. |
IBM Domino/Notes | IBM Domino/Notes je groupware produkt, který je mimo jiné využit pro zasílání emailových notifikací generovaných v systému ECM/DMS z úložiště dokumentů nebo z workflow na určené uživatele v rámci MŽP. |
Micro Focus eDirectory | Jedná se o adresářovou službu použitou pro autentizaci uživatelů na základě protokolu LDAP. |
ESS AthenA | Elektronický systém spisové služby (ESSS), ve kterém jsou evidovány dokumenty v podatelně/výpravně MŽP a spisových uzlech jednotlivých organizačních útvarů. 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ě. |
EIS JASU | Ekonomický informační systém MŽP zajišťující mimo jiné rezervaci finančních zdrojů v Integrovaném informačním systému státní pokladny. |
ISDD | Informační systém Digitální důvěry na využití služeb pro: - validaci el. dokumentů a jejich el. bezpečnostních prvků (el. podpisu, pečetě, č. razítka apod.), - pečetění a označování dokumentů časovým razítkem, dle nařízení eIDAS. |
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 ECM/DMS zajišťující možnost napojení a využití jeho služeb okolními systémy, a naopak napojení systému ECM/DMS na služby externích systémů. |
Klientská stanice, notebook, tablet a mobilní telefon | Uživatelská koncová zařízení pro přístup do systému ECM/DMS. |
4.4.2. Detailní popis vybraných integrací
A. Integrace s MS Office
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 ECM/DMS, poté potvrdí uložení nového dokumentu. Systém ECM/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í dokumentu. Stejný postup bude v případě otevření existujícího dokumentu (uloženého mimo úložiště systému ECM/DMS) v MS Office, pokud jej bude uživatel chtít uložit do ECM/DMS.
Při otevírání již vytvořeného dokumentu uloženého v ECM/DMS uživatel vybere soubor z cílového úložiště systému ECM/DMS a potvrdí jeho otevření. Systém ECM/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 ECM/DMS jiným uživatelům emailovou zprávou se oprávněnému koncovému uživateli otevře odkazovaný dokument/složka v novém okně/záložce.
Adresátem emailové zprávy může být osoba, skupina osob dle organizační struktury anebo skupina osob dle zařazení do projektu nebo jejich kombinace.
B. Integrace s eMail klientem
Integrace s IBM Domino/Notes zajišťuje příjem notifikací generovaných systémem ECM/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ě ECM/DMS a/nebo o jeho změnách.
C. Integrace s ESS ATHENA
Pro integraci ECM/DMS a ESSS AthenA se využijí webové služby, které jsou popsány v dokumentaci k SOAP rozhraní AthenA, která bude Dodavateli poskytnuta v rámci realizace předimplementační analýzy a tvorby dokumentu – Návrh implementace.
D. Integrace s EIS JASU
Ekonomický informační systém JASU umožňuje komplexní zpracování ekonomických agend v organizaci. IS obsahuje moduly účetnictví, rozpočet, dodavatelská a odběratelská fakturace, dotace, skladové hospodářství, banka, pokladna, smlouvy, objednávky.
Výměna dat – položek platebního kalendáře – mezi EIS JASU a dokumenty evidenčního listu zakázky a krycího listu smlouvy řízenými v ECM/DMS se odehrává ve více krocích procesu jejich zpracování
– schvalování. Položky platebního kalendáře evidenčního listu zakázky je například nutné převést do EIS JASU při tvorbě stanoviska odboru rozpočtu. Krycí list smlouvy musí aktualizovat data platebního kalendáře buď při uzavření smlouvy s dodavatelem, nebo v případě neuzavření smlouvy. Tyto přenosy dat platebního kalendáře je možné realizovat prostřednictvím uživatelské akce nebo automatizovaně na základě splnění nějaké podmínky v daném kroku procesu. Detailní návrh integrace očekává Objednatel zpracovaný od Dodavatele v rámci předimplementační analýzy, tedy v dokumentu Návrh implementace (NAIM).
E. Integrace s ISDD
Informační systém Digitální důvěry (TS-ELDAx, spol. TechniServ IT) zajišťuje a poskytuje funkce na využití požadovaných služeb pro:
- validaci el. dokumentů a jejich el. bezpečnostních prvků – el. podpisu, pečetě, č. razítka apod.;
- pečetění a označování el. dokumentů časovým razítkem; dle nařízení eIDAS.
Veškeré funkcionality platformy jsou poskytovány pomocí jednotlivých aplikačních rozhraní (API) pro práci s elektronickými dokumenty (webová služba typu SOAP). Nezbytnou součástí veškerého volání je autentizace integrovaného systému při každém požadavku na funkcionalitu platformy. Volání jednotlivých metod a předávání informací pak probíhá pomocí zabezpečeného protokolu HTTPS.
F. Integrace s IS SIEM
Viz odst. 4.1.7/B. – SIEM (Sběr bezpečnostních logů).
5. MINIMÁLNÍ POŽADAVKY NA PROJEKTOVÉ ŘÍZENÍ
5.1. Organizace – projektový tým, jednání a zápisy
V souvislosti s implementací ECM/DMS systému ustanoví smluvní strany (Objednatel a Dodavatel) společný Projektový tým (PT). Personální složení bude definováno v následující tabulce personálního složení PT a členové tohoto týmu mají dále definované kompetence.
Objednatel a Dodavatel se zavazují, že složení PT se po celou dobu projektu nebude měnit bez závažného důvodu a pokud, pak pouze na základě vzájemného odsouhlasení této změny. Projektový tým bude jednat pravidelně, v termínech stanovených vedoucím projektu (a projektovým plánem – harmonogramem) Objednatele (nebo Dodavatele), popřípadě i ad-hoc, na základě potřeby a výzvy vedoucího projektu Objednatele anebo Dodavatele.
Každého jednání se musí zúčastnit minimálně Vedoucí projektu (nebo Supervizor) a dva další členové PT z každé smluvní strany.
Z každého jednání se bude pořizovat Zápis z jednání PT, který bude obsahovat minimálně tyto náležitosti:
- zhodnocení dosavadního postupu prací, zejména posouzení dodržování projektového plánu
– harmonogramu realizace, a jeho jednotlivých plnění – dílčích částí a zhodnocení plnění povinností obou smluvních stran, kontrola úkolů;
- aktualizaci nebo specifikaci dalších úkolů – vstupů a výstupů pro následující období;
- dohodnutí příštího jednání PT – Kdy, Kdo a Kde.
Zápis může obsahovat také připomínky, požadavky a komentáře členů PT obou smluvních stran. Písemný zápis z jednání PT zpravidla vypracuje zástupce Dodavatele, pokud nebude stanoveno jinak a bude platný po jeho odsouhlasení Objednatelem. Schválený zápis bude podepsán zástupci obou smluvních stran.
5.2. Řídící výbor (ŘV)
Supervizor a Vedoucí projektu obou smluvních stran budou jmenováni do společného orgánu, který se bude nazývat Řídící výbor (ŘV). Supervizoři projektu jsou osobami s rozhodovacími pravomocemi vůči projektu a Předsedou ŘV je Supervizor strany Objednatele s následujícími povinnostmi a kompetencemi:
x. xxxxxxx zasedání ŘV na základě plánu projektu – harmonogramu, ze své vůle nebo na základě návrhu jiného člena ŘV;
b. navrhuje program a řídí zasedání ŘV;
x. xxxxxxxxx v otázkách projektu na základě doporučení členů ŘV.
Zasedání ŘV je oprávněn se účastnit osobně každý člen ŘV, případně může pověřit účastí svého zástupce a zasedání se mohou, na vyzvání členů ŘV, zúčastnit i další členové projektového týmu obou smluvních stran. Přímými nadřízenými ŘV jsou statutární zástupci obou smluvních stran.
ŘV je založen za účelem kontroly průběhu projektu s následujícími povinnostmi a kompetencemi:
a. kontrolovat průběh realizace projektu s ohledem na dodržování stanoveného plánu – harmonogramu a plnění jeho jednotlivých etap;
b. projednávat případné připomínky jedné smluvní strany k dodržování povinností druhé smluvní strany dle uzavřené smlouvy;
c. předcházet potenciálním sporům anebo vzniklé spory související se smlouvou řešit;
d. řešit problémy, které eskalují Vedoucí projektu (VP) nebo projektový tým (PT);
e. navrhovat a schvalovat případné personální změny v PT.
5.3. Vedoucí projektu (VP)
Vedoucí projektu (neboli Projektový manažer (PM)) má v rámci projektu roli exekutivní. Řídí práci projektového týmu, a to na základě plánu projektu – harmonogramu a na základě požadavků, které na svých zasedáních definuje ŘV.
Práva a povinnosti VP jsou následující:
a. definují pravidla komunikace a výměny informací a dohlížejí na jejich dodržování;
b. jsou primárními styčnými body pro plnění povinností plynoucích ze vzájemné součinnosti obou smluvních stran;
c. zajišťují řízení, sledování plnění a případnou aktualizaci plánu úkolů, projektu v čase a požadované kvalitě;
d. zajišťují svolání zasedání ŘV v případě řešení problémů eskalovaných z průběhu realizace projektu anebo sporů eskalovaných z jednání PT;
e. jsou vykonavateli rozhodnutí ŘV přijatých na zasedání.
5.4. Členové projektového týmu
Jde primárně o odborné garanty na straně Objednatele a odborníky-specialisty na straně Dodavatele, kteří plní
– realizují konkrétní úkoly související s projektem, a to ve stanovených termínech (dle plánu projektu anebo dle požadavků VP) a v požadované kvalitě.
5.5. Projektový tým (PT)
Viz Čl. IV. odst. 4.9. pododst. 4.9.2 této Smlouvy.
5.6. Práva a povinnosti Objednatele
Projektový tým Objednatele je složen z pracovníků odborných útvarů s metodickými znalostmi souvisejícími s vyřizováním a zpracováním dokumentů v rámci jednotlivých agend ministerstva a se znalostmi z oblasti ICT – IS/Aplikací/služeb, kteří garantují, že zadání pro výběr, implementaci a provoz ECM/DMS vyhovuje interním požadavkům ministerstva a požadavkům, které jsou na správu takových dokumentů případně kladeny předpisy a nařízeními ČR nebo EU.
Vedoucí Projektu má právo:
- kontrolovat postup prací realizovaných dodavatelem;
- rozhodovat při formulaci požadavků (analytických zadání) dílčích úloh na ECM/DMS řešení směrem k dodavateli, a to v souladu s uzavřenou smlouvou.
Projektový tým (členové týmu) odpovídají za:
- formulaci požadavků na vlastnosti a za správnost analytických zadání pro ECM/DMS;
- stvrzují shodnost dodaného infomačního systému (s případným výčtem chyb a návrhů) s definovanými požadavky v zadání;
- poskytnutí veškerých dostupných podkladů nezbytných pro požadovanou implementaci ECM/DMS;
- technickou a organizační podporu realizace projektu;
- včasné (v dohodnutých termínech) a úplné odevzdání všech dohodnutých podkladů;
- vytvoření potřebných pracovních podmínek pro Dodavatele v místě Objednatele.
5.7. Práva a povinnosti Dodavatele
Projektový tým Dodavatele je složen z odborníků – specialistů se znalostmi dodávaného ECM/DMS informačního systému, kteří garantují, že jsou schopni zajistit plnění veřejné zakázky v plném rozsahu tak, jak je definováno smlouvou a zadáním, a že splňují všechna kvalifikační kritéria, která Objednatel v rámci zadání požadoval.
Vedoucí projektu odpovídá za:
- řízení projektu tak, aby výsledkem bylo nasazení ECM/DMS v požadovaném – smluveném čase, financích a kvalitě.
Projektový tým (členové týmu) odpovídají za:
- správnou implementaci ECM/DMS a požadavků na něj kladených (smluvených);
- včasné a úplné odevzdání všech dohodnutých prací Objednateli – Vedoucímu projektu Objednatele.
Dodavatel zajistí kompletní plnění dle smlouvy a souvisejících dokumentů – příloh.
6. POŽADAVKY NA ŘÍZENÍ PROJEKTU
6.1. Plán (harmonogram) projektu
Konkrétní Plán – harmonogram projektu bude Dodavatelem navržen v rámci předimplementační analýzy a Návrhu implementace. Tento Plán může být dále upřesňován, ale vždy pouze v takovém časovém rozsahu, aby byl v souladu s termíny smluvenými ve smlouvě. Jakékoli změny Plánu musí být akceptovány Objednatelem. Aktualizované a schválené verze Plánu se stávají závaznými dokumenty projektu jako aktualizace dohody smluvních stran.
6.2. Řízení projektu
Viz kapitola 5. Minimální požadavky na Projektové řízení.
6.3. Dokumentace projektu
Viz kapitola 8. Dokumentace.
6.4. Komunikace v rámci projektu
Na „Kick-Off“ mítinku projektového týmu budou stanovena pravidla vzájemné komunikace. Jejich základem bude, že veškerá komunikace – výměna informací bude probíhat tak, aby VP byli informováni o všech probíhajících aktivitách (úkolech) na projektu a jejich stavu. Minimálně jednou za kalendářní měsíc bude stav projektu prezentován na ŘV. Termíny zasedání ŘV by měli být stanoveny na „Kick-Off“ mítinku a zahrnuty do Plánu projektu.
6.5. Změnové řízení – žádost o změnu, její vyhodnocení a vyřešení
K potřebě nějaké změny (např. priorit jednotlivých aktivit-úkolů, dohodnutého rozsahu prací, kvality, …) může dojít i po podpisu smlouvy a vytvoření Realizační studie. V takovém případě je nutno vypracovat žádost o změnu a zahájit změnové řízení. Dodavatel zhodnotí důsledky takové změny nebo změn na projekt podle pravidel popsaných v následujících odstavcích.
Změnová řízení se obvykle týkají:
- změn dílčích termínů dodávek nebo prací bez dopadu na konečný (smluvní) termín projektu;
- kvantitativních nebo kvalitativních změn rozsahu dohodnutých prací nebo služeb v projektu.
S žádostí o změnu může přijít kterýkoli člen PT. Každá taková žádost o změnu se stane součástí projektové dokumentace a bude archivována v písemné podobě.
Žádost bude předána vedoucímu projektu a ten, ve spolupráci s VP druhé strany vyhodnotí tuto žádost. Během tohoto přezkoumání a hodnocení bude zkoumán dopad změny na rozsah, zdroje a termíny projektu a rovněž dopad na projekt, když se změna neprovede.
VP společně vypracují doporučení ke každé žádosti o změnu. Pokud změna neovlivní zásadním způsobem projekt (rozsah, zdroje a termíny), rozhodnou VP na základě společné dohody o provedení nebo zamítnutí této změny. V případě, že by se jednalo o zásadní změnu, připraví VP společně podrobný odhad dopadů na projekt a své zjištění s doporučením předají k rozhodnutí na ŘV a Supervizora Objednatele.
Rozhodnutí (o provedení nebo zamítnutí) jakékoli žádosti na změnu se stane součástí projektové dokumentace a bude archivována v písemné podobě.
Pokud by bylo schváleno přijetí zásadní změny s dopadem na podepsanou smlouvu, bude zahájeno projednání změny smlouvy formou dodatku ke smlouvě a změna bude účinná s účinností dodatku.
6.6. Akceptace projektu a dílčích plnění (milníků) dle plánu projektu
K akceptaci jednotlivých etap nebo dílčích plnění dle plánu projektu (harmonogramu) dojde po akceptační proceduře a podpisu Akceptačního/předávacího protokolu, který podepíše na straně Objednatele vedoucí projektu a Supervizor a na straně Dodavatele vedoucí projektu nebo Supervizor.
6.6.1. Akceptační procedura
Akceptační procedura bude probíhat minimálně dle následujících kroků:
a. Dodavatel písemně vyzve Objednatele k účasti na Akceptační proceduře a tuto písemnou výzvu doručí Objednateli nejméně pět (5) pracovních dnů před zahájením Akceptační procedury;
b. Objednatel vytvoří akceptační komisi složenou minimálně z 2 členů (doporučeno 3 členů) v zastoupení jedné až dvou osob Projektového týmu a Vedoucího projektu Objednatele (dále jen „Akceptační komise“);
c. Posouzení zpracovaného Výstupu (na obsah, úplnost, a realizace) Dodavatele Akceptační komisí, soupis případných výhrad (budou-li nějaké) Akceptační komise a jejich postoupení Dodavateli k novému zapracování ve lhůtě 2 pracovních dnů ode dne předání Výstupu Akceptační komisi Dodavatelem;
d. Zapracování výhrad Dodavatelem ve lhůtě 3 pracovních dnů od jejich postoupení Akceptační komisí;
e. Posouzení zapracování výhrad (budou-li nějaké) Akceptační komisí ve lhůtě 2 pracovních dnů ode dne postoupení aktualizovaného Výstupu Akceptační komisi Dodavatelem, včetně závěrečného stanoviska Akceptační komise: (i) akceptováno, (ii) akceptováno s výhradami,
(iii) neakceptováno.
6.6.2. Závěrečné stanovisko
Závěrečné stanovisko Akceptační komise bude uvedeno v akceptačním protokolu vyhotoveném Objednatelem a Dodavatelem, který bude obsahovat alespoň:
a. označení předmětného dílčího Plnění, označení a identifikační údaje Objednatele a Dodavatele, číslo Smlouvy a datum jejího uzavření;
b. soupis provedených činností, dodávek, služeb apod.;
c. stanovisko Objednatele, že dílčí Plnění akceptuje, akceptuje s výhradami či neakceptuje (dle stanoviska Akceptační komise);
x. xxxxxxx, budou-li nějaké;
e. datum a místo sepsání akceptačního protokolu, jména a podpisy zástupců Objednatele a Dodavatele.
Nesdělení některé výhrady při akceptaci nemá vliv na povinnost Dodavatele tuto výhradu odstranit, pokud o ní ví, dodatečně ji zjistí, či mu bude dodatečně oznámena.
6.6.3. Výhrady
Výhrady jsou klasifikovány následovně:
a. Výhrady kategorie A – stav specifikovaného systému (nebo Výstupu), který neumožňuje plnění základních funkcí;
b. Výhrady kategorie B – stav specifikovaného systému (nebo Výstupu) umožňující plnění základních funkcí, avšak s omezením rychlosti zpracování nebo za mimořádných provozních opatření;
c. Výhrady kategorie C – stav specifikovaného systému (nebo Výstupu) umožňující plnění základních funkcí Objednatele, avšak s vyskytujícími se drobnými chybami, které nebrání nebo mají zcela minimální vliv na řádné užívání a funkcionality systému;
(společně dále jen „Výhrady“).
6.6.4. Splnění akceptačních kritérií
Není-li stanoveno jinak, má se za to, že dílčí Plnění splňuje stanovená akceptační kritéria za předpokladu, že toto Plnění nemá žádnou Výhradu kategorie A, max. 1 Výhradu kategorie B a současně nemá více než 5 Výhrad kategorie C.
Objednatel je oprávněn dílčí Plnění převzít i v případech, kdy počet a/nebo druh Výhrad kategorie A, B, C překračuje maximální počet stanovený pro splnění akceptačních kritérií.
Nicméně se v takovém případě vždy jedná o akceptování s Výhradami a Dodavatel má povinnost tyto výhrady odstranit ve sjednaném čase.
6.6.5. Akceptace projektu
Každé dílčí Plnění je řádně poskytnuto a akceptováno až podpisem Akceptačního protokolu Objednatelem a Dodavatelem, je-li prosto jakýchkoli Výhrad.
Plnění projektu jako celku se považuje za dokončené teprve v okamžiku, kdy ze strany Objednatele dojde k bezvýhradné akceptaci posledního Akceptačního protokolu.
7. MINIMÁLNÍ POŽADAVKY NA ETAPY PROJEKTU
7.1. Předpokládané etapy projektu
Předpokládáme, že součástí projektu budou minimálně tyto etapy:
- Etapa I. – Analýza a vytvoření Návrhu implementace (NAIM), ta bude obsahovat návrh:
• Implementace, konfigurace a integrace ECM/DMS do prostředí ministerstva;
• Nasazení správy dokumentů pro Xxxxxxx xxxxxxx (VZ) a Xxxxxxx (SML);
• Migrace dat ze stávající agendy – aplikace eSmlouvy do SML;
• Nasazení správy dokumentů pro Projektové záměry (PZ).
- Etapa II. – Implementace ECM/DMS
• Instalace ECM/DMS do testovacího (TEST) prostředí;
• Implementace VZ/SML a PZ;
• Migrace dat z aplikace eSmlouvy do SML;
• Součinnost (a konzultace) pro integraci napojení na interní systémy (ESSS, …, viz kap. Integrace);
• Školení – klíčových uživatelů a administrátorů pro testování ECM/DMS;
• Dokumentace – školící materiály, testovací scénáře, uživatelská a admin. příručka.
- Etapa III. – Ověření produkčního provozu a produkce
• Dodávka a instalace ECM/DMS do produkčního (PROD) prostředí;
• Dodání SW licencí;
• Předání finálních zdrojových kódů a finální dokumentace;
• Podpora ověření produkčního provozu.
- Etapa IV. – Servisní podpora a rozvoj ECM/DMS
• Rozšířená servisní podpora provozu;
• Rozvoj dle nových a změnových požadavků Objednatele;
• Školení uživatelů;
• Poskytnutí SW Maintenance.
Pokud chcete tento návrh (minimální požadavky) nějak doplnit-rozšířit, prosím, proveďte tak do vaší nabídky.
7.2. Předpokládaný harmonogram plnění
Na základě námi realizované předprojektové analýzy očekáváme následující harmonogram od podpisu a nabytí účinnosti smlouvy:
- Etapa I. 13 týdnů
- Etapa II. 17 týdnů
- Etapa III. 9 týdnů
- Etapa IV. na dobu neurčitou (podmíněno akceptací Etapy III.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CELKEM 39 týdnů
Pokud chcete tento harmonogram doplnit – upřesnit, prosím proveďte tak do vaší nabídky.
8. DOKUMENTACE
Dodavatel předá v rámci realizace projektu Objednateli dokumentaci k ECM/DMS, a to v českém jazyce a následujícím rozsahu:
Název | Xxxxx | Xxxxxxxxx |
Implementační návrh | Návrh (analýza) implementace ECM/DMS do prostředí organizace, která se bude skládat minimálně z návrhu: - implementace, konfigurace a integrace do prostředí, | Dodavatel ve spolupráci s Objednatelem. |
- nasazení správy dokumentů pro VZ, SML a PZ | ||
Uživatelská příručka | Informace o DMS/ECM z pohledu uživatelské práce: - rozhraní, - použití, - vlastností (funkcí), nastavení atd. | Dodavatel ve spolupráci s Objednatelem. |
Administrátorská příručka | Informace o DMS/ECM z pohledu instalace, konfigurace, bezpečnosti, podpory provozu, zálohování, logování a monitoringu, obnovy, popisu datových rozhraní (WS, REST, …) a správy IS. | Dodavatel ve spolupráci s Objednatelem. |
Testovací scénáře | Testovací scénáře pro testování klíčovými uživateli a administrátory pro předání a převzetí požadovaných vlastností IS. | Dodavatel ve spolupráci s Objednatelem. |
Školící materiály (a prezentace) | Informace pro klíčové uživatele a administrátory, aby mohli informační systém testovat. | Dodavatel |
9. PŘÍKLAD DESIGNU FORMULÁŘŮ
9.1. Evidenční list Xxxxxxx
9.2. Krycí list Smlouvy
9.3. Legenda k příkladům designu formulářů
- černé nebo bílé texty jako názvy sekcí (např. Evidenční list XXXXXXX, Předmět, Odborná stanoviska, Xxxxxxxxxx příkazce apod.) nebo názvy polí (např. Odbor, Zpracovatel, Uzavření smlouvy, Částka s DPH, Xxxxx, Xxxxxxxxx apod.) jsou statické texty – názvy jednotlivých sekcí, podsekcí, položek a polí.
- šedé texty (např. „425/17“; „Xxxx Xxxxxx“; 1 200 000,00 Kč“ apod.) jsou příklady konkrétních hodnot anebo jejich možností, pokud jsou oddělené „ / “.
Formuláře by měly splňovat doporučení UX (User Experience), měly by se obsluhovat intuitivně a jednoduše.
10. PROCESY
V zadávací dokumentaci uvádíme následující tři příklady reálných procesů, aby si potenciální dodavatel byl schopen udělat detailní představu o složitosti současných (ale i budoucích) business a dokumentových procesů, které požadujeme v rámci implementace ECM/DMS aktuálně řešit
– nasadit.
10.1. Vzorový business proces – Xxxxxxx xxxxxxx (VZ)
Obrázek – Diagram business procesu – VZ
Krok č. | Název | Popis | Typ |
Odborný útvar (OÚ) | Xxxx | ||
START | Někdo chce nastartovat proces schválení a realizace budoucí Veřejné zakázky | Event | |
01 | PODNĚT | Nějaký uživatel – zpravidla Zpracovatel (referent, vedoucí odd.) nebo Příkazce (ředitel) OÚ, anebo zástupce rezortní organizace vloží do ECM/DMS dokument s podnětem (žádostí) na budoucí VZ. | Activity |
02 | PODKLAD TS | Pověřený uživatel(-é) – obvykle Zpracovatel provádí sběr technických požadavků k VZ a tyto informace – dokumenty (Produktové listy, …) vkládá k založené VZ jako podklady pro tvorbu Technické specifikace. | Activity |
03 | TECHNICKÁ SPECIFIKACE | Pověřený uživatel(-é) – obvykle Zpracovatel provádí vytvoření technické specifikace (požadavky funkční/nefunkční, bezpečnostní, omezení, …) a tento dokument nebo dokumenty vkládá k VZ. | Activity |
04 | PRŮZKUM TRHU | Pověřený uživatel – obvykle Zpracovatel připraví dokument – Průzkum trhu (RFI), který vloží k VZ, a kterým osloví vybrané potenciální dodavatele. | Activity |
05 | ODPOVĚĎ NA PRŮZKUM TRHU | Pověřený uživatel – obvykle Zpracovatel uloží došlé Odpovědi na průzkum trhu (dokumenty) od jednotlivých potenciálních dodavatelů a na jejich základě vytvoří VZ. | Activity |
06 | STANOVENÍ HODNOTY | Pověřený uživatel – obvykle Zpracovatel vypracuje s ohledem na odpovědi z průzkumu trhu stanovení předpokládané hodnoty budoucí VZ. | Activity |
07 | EVIDENČNÍ LIST | Pověřený uživatel – obvykle Zpracovatel založí Evidenční list budoucí VZ, který (dle další metadat) prochází vlastním schvalovacím workflow. Tento dokumentový (a business) proces je pospán v samostatné kapitole dále – viz proces EL. | Activity |
09 | HODNOTA VZ | Rozhodovací krok. Pokud je hodnota VZ do 200 tis. Kč (bez DPH) včetně, pak zpracování VZ pokračuje dál v rámci OÚ. Pokud je hodnota VZ vyšší než 200 tis. Kč (bez DPH), pak zpracování VZ pokračuje v rámci SOVZ a ve spolupráci s OÚ. | Gateway |
10 | NÁVRH ZADÁVACÍ DOKUMENTACE | Pověřený uživatel – obvykle Zpracovatel vytvoří návrh veškeré zadávací dokumentace (např. návrh smlouvy, technickou specifikaci, …) potřebné pro výběrové řízení a tuto dokumentaci založí k VZ. | Activity |
11 | OSLOVENÍ VYBRANÝCH DODAVATELŮ | Pověřený uživatel – obvykle Zpracovatel provede oslovení potenciálních (doporučených – vybraných) dodavatelů o nabídku, a to prostřednictvím různých komunikačních kanálů – eMailem, ISDS, … | Activity |
12 | DOKUMENTACE O VZ (HODNOCENÍ) | Pověření uživatelé (komise) vyhodnotí nabídky potenciálních dodavatelů a vyberou tu nejlepší – obvykle pouze z hlediska ceny, ale někdy i z hlediska naplnění jiných (např. technických) kritérií. Všechny dokumenty – nabídky, návrhy smluv a další dokumentaci uloží pověřený uživatel – obvykle Zpracovatel do ECM/DMS – VZ. | Activity |
13 | NÁVRH SMLOUVY K PODPISU – KRYCÍ LIST | Pověřený uživatel – obvykle Zpracovatel založí Krycí list ke smlouvě, která se bude podepisovat s vybraným dodavatelem. Krycí list smlouvy (neboli smlouva k podpisu) má vlastní definované schvalovací workflow – viz proces KL v samostatné kapitole. | Activity |
14 | SMLOUVA PODEPSANÁ | Pověřený uživatel – referent OÚ zabezpečí fyzický podpis smlouvy oběma smluvními stranami a její uložení. | Activity |
15 | REGISTR SMLUV | Rozhodovací krok. Pokud NE, pak se podepsaná smlouva nechá pouze v ECM/DMS, pokud ANO musí dojít k její anonymizaci a vložení do Registru smluv. | Gateway |
Samostatné oddělení VZ (SOVZ) | Lane | ||
09.1 | PŘIDĚLENÍ NA REFERENTA | Pokud je hodnota VZ vyšší než 200 tis. Kč (bez DPH), pak dojde k přidělení VZ k dalšímu zpracování referentovi z SOVZ, který koordinuje tvorbu a správu dalších dokumentu. | Activity |
10.1 | NÁVRH ZADÁVACÍ DOKUMENTACE | Pověřený uživatel – referent SOVZ vytvoří ve spolupráci s referenty OÚ návrh veškeré zadávací dokumentace (např. návrh smlouvy, technickou specifikaci, …) potřebné pro výběrové řízení a tuto dokumentaci založí k VZ. | Activity |
11.1 | VEŘEJNÉ OSLOVENÍ DODAVATELŮ | Referent SOVZ provede veřejné oslovení dodavatelů o nabídku, a to prostřednictvím eTržišť (např. Gemin), kam vystaví zadávací dokumentaci. | |
12.1 | DOKUMENTACE O VZ (HODNOCENÍ) | Pověření uživatelé (komise) vyhodnotí nabídky potenciálních dodavatelů a vyberou tu nejlepší – obvykle pouze z hlediska ceny, ale někdy i z hlediska naplnění jiných (např. technických) kritérií. Všechny dokumenty – nabídky, návrhy smluv a další dokumentaci uloží pověřený uživatel – v tomto případě referent SOVZ do ECM/DMS – VZ. | Activity |
13.1 | NÁVRH SMLOUVY K PODPISU – KRYCÍ LIST | Pověřený uživatel založí Krycí list ke smlouvě, která se bude podepisovat s vybraným dodavatelem. Krycí list smlouvy (neboli smlouva k podpisu) má vlastní definované schvalovací workflow – viz proces KL v samostatné kapitole. | Activity |
14.1 | SMLOUVA PODEPSANÁ | Pověřený uživatel – referent SOVZ zabezpečí fyzický podpis smlouvy oběma smluvními stranami a její uložení. | Activity |
16 | ANONYMIZACE A VLOŽENÍ DO REGISTRU SMLUV | Pověřený uživatel – referent SOVZ zabezpečí anonymizaci smlouvy a její uložení do registru smluv. | Activity |
Odbor rozpočtu (OR) | Lane | ||
08 | SCHVÁLENÍ BLOKACE STANOVENÉ HODNOTY VE SP | Pověřený rozpočtář (ředitel) provede schválení/neschválení stanovené hodnoty VZ ve Státní pokladně. | Activity |
17 | AKTIVACE | Pověřený uživatel – obvykle Rozpočtář uvolní možnost čerpání schválené blokace stanovené hodnoty VZ. | Activity |
KONEC | Ukončení celého business procesu. | Event |
10.2. Vzorový dokumentový proces – Evidenčního listu VZ
Obrázek – Diagram dokumentového procesu EL
Krok č. | Název | Popis | Typ |
Odborný útvar (OÚ) a nadřízený Náměstek ministra (NM) | Lane | ||
START | Začátek dokumentového procesu EL. Zpracovatel (referent) nastartuje workflow schválení Evidenčního listu VZ tím, že založí EL. | Event | |
01 | ROZPRACOVÁN | Zpracovatel založil a připravuje (vyplňuje) informace do EL. EL se může týkat následujících typů smluv: - SA = sml. do 200 tis. Kč; - SB = sml. od 200 tis. do 2 mil. Kč; - SC = sml. nad 2 mil. Kč (bez DPH); - SD = sml. na poradenské a mrkt služby do 2 mil. Kč; - SX = sml. EIA. Ceny jsou uvedené bez DPH. | Activity |
02 | ZASLÁN KE SCHVÁLENÍ | Zpracovatel zaslal EL ke schválení Příkazci (nadřízený Ředitel OÚ). | Activity |
03 | SCHVÁLENÍ / ZAMÍTNUTÍ | Rozhodovací krok. Pokud schváleno: ANO, a jedná se o sml. typu SB/SC/SD proces pokračuje automatickým krokem 04 Zaslán ke schválení (podpisu). Pokud schváleno: ANO, a jedná se o sml. typu SA/SX proces pokračuje automatickým krokem 09 Zaslán k posouzení (podpisu). Pokud schváleno: NE, vráceno zpět do 01 Rozpracován. Pokud schváleno: ZAMÍTNUTO, pokračuje do 16 Zamítnut. | Gateway |
04 | ZASLÁN KE SCHVÁLENÍ | Automatický krok realizovaný na základě schválení (ANO) Příkazcem operace a dokument jde ke schválení na nadřízeného Náměstka. V případě, že nadřízený Náměstek je zároveň Státní tajemník (ST), jde dokument ke schválení přímo na ST. | Activity |
05 | SCHVÁLENÍ / ZAMÍTNUTÍ | Rozhodovací krok. Pokud schváleno: ANO, proces pokračuje automatickým krokem 06 Zaslán ke schválení (podpisu). Pokud schváleno: NE, vráceno zpět do 01 Rozpracován. Pokud schváleno: ZAMÍTNUTO, pokračuje do 16 Zamítnut. | Gateway |
06 | ZASLÁN KE SCHVÁLENÍ | Automatický krok realizovaný na základě schválení (ANO) Náměstkem a dokument jde ke schválení na Státního tajemníka. | Activity |
09 | ZASLÁN K POSOUZENÍ | Automatický krok realizovaný na základě schválení (ANO) Příkazcem operace a dokument jde k posouzení na Odbor rozpočtu. | Activity |
16 | ZAMÍTNUTÍ | EL byl z nějakého důvodu na úrovni Příkazce, NM nebo ST zamítnut. | Activity |
17 | SMLOUVA NEUZAVŘENA | Příkazce uvede stanovisko neuzavření smlouvy. | Activity |
Státní tajemník (ST) | Lane | ||
07 | SCHVÁLENÍ / ZAMÍTNUTÍ | Rozhodovací krok. Pokud schváleno: ANO, proces pokračuje automatickým krokem 08 Zaslán ke schválení (podpisu). Pokud schváleno: NE, vráceno zpět do 01 Rozpracován. Pokud schváleno: ZAMÍTNUTO, pokračuje do 16 Zamítnut. | Gateway |
08 | ZASLÁN KE SCHVÁLENÍ | Automatický krok realizovaný na základě schválení (ANO) ST a dokument jde k posouzení – schválení na Odbor rozpočtu. | Activity |
Odbor rozpočtu (OR) | Lane | ||
10 | ČEKÁ VE FRONTĚ NA PŘEVZETÍ | Dokument zaslaný ke schválení (posouzení) na OR, čeká na převzetí Rozpočtářem. | Activity |
11 | PŘEVZETÍ ROZPOČTÁŘEM | Dokument byl převzat Rozpočtářem k dalšímu zpracování – schválení (posouzení). | Activity |
12 | SCHVÁLENÍ | Rozhodovací krok. Pokud schváleno: ANO, pokračuje do 13. Pokud schváleno: NE, pokračuje také do 13. | Gateway |
13 | ZASLÁN KE SCHVÁLENÍ | Automatický krok realizovaný na základě schválení (ANO/NE) Rozpočtářem a dokument jde ke schválení na Ředitele OR. | Activity |
14 | SCHVÁLENÍ | Rozhodovací krok. Pokud schváleno: ANO, EL je schválen. Pokud schváleno: NE, EL není schválen a vráceno zpět do 01 Rozpracován. | Gateway |
15 | ZAEVIDOVÁN | Evidenční list je zaevidován a VZ může pokračovat. | Activity |
KONEC | Ukončení dokumentového procesu EL. | Event |
10.3. Vzorový dokumentový proces – Krycího listu Smlouvy k VZ
Obrázek – Diagram dokumentového procesu KL
Krok č. | Název | Popis | Typ |
Odborný útvar (OÚ) a nadřízený Náměstek ministra (NM) | Lane | ||
START | Začátek dokumentového procesu Krycího listu. Zpracovatel (referent) nastartuje workflow schválení Krycího listu smlouvy tím, že založí KL. | Event | |
01 | ROZPRACOVÁN | Zpracovatel založil a připravuje (vyplňuje) informace do KL. Krycí list si načte část dat (metadat) z Evidenčního listu. KL se může týkat následujících typů smluv: SA, SB, SC, SD a SX, anebo jejich modifikací. | Activity |
02 | ZASLÁN KE SCHVÁLENÍ | Zpracovatel zaslal EL ke schválení Příkazci (nadřízený Ředitel OÚ). | Activity |
03 | SCHVÁLENÍ / ZAMÍTNUTÍ | Rozhodovací krok. Pokud schváleno: ANO, a jedná se o smlouvu proces pokračuje automatickým krokem 04 Zaslán ke schválení (podpisu). | Gateway |
Pokud schváleno: ANO, a jedná se o modifikaci sml. typu SB, SC nebo SD proces pokračuje automatickým krokem 05 Zaslán k posouzení (podpisu). Pokud schváleno: NE, vráceno zpět do 01 Rozpracován. Pokud schváleno: ZAMÍTNUTO, pokračuje do 21 Zamítnut. | |||
04 | ZASLÁN KE SCHVÁLENÍ | Automatický krok realizovaný na základě schválení (ANO, pro všechny smlouvy a modifikace SA/SX) Příkazcem operace a dokument jde ke schválení na Ředitele SOVZ. | Activity |
05 | ZASLÁN KE SCHVÁLENÍ (MODIFIKACE SB/SC/SD) | Automatický krok realizovaný na základě schválení (ANO, pouze v případě modifikací SB/SC/SD) Příkazcem operace a dokument jde ke schválení na nadřízeného NM. V případě, že nadřízený Náměstek je zároveň Státní tajemník (ST), jde dokument ke schválení přímo na ST. | Activity |
06 | SCHVÁLENÍ / ZAMÍTNUTÍ | Rozhodovací krok. Pokud schváleno: ANO, proces pokračuje automatickým krokem 07 Zaslán ke schválení (podpisu). Pokud schváleno: NE, vráceno zpět do 01 Rozpracován. Pokud schváleno: ZAMÍTNUTO, pokračuje do 21 Zamítnut. | Gateway |
07 | ZASLÁN KE SCHVÁLENÍ | Automatický krok realizovaný na základě schválení (ANO) NM a dokument jde ke schválení na ST. | Activity |
12 | ZAPRACOVÁNÍ PŘIPOMÍNEK | Zpracovatel dostane od Ředitele SOVZ schváleno s připomínkami a tyto připomínky musí zohlednit – zapracovat. | Activity |
13 | ZASLÁN KE SCHVÁLENÍ | Po zapracování připomínek posílá Zpracovatel KL k dalšímu zpracování na OR. | Activity |
21 | ZAMÍTNUT | KL byl z nějakého důvodu na úrovni Příkazce, NM, ST nebo Ředitele OR zamítnut. | Activity |
22 | SMLOUVA (MODIFIKACE) NEUZAVŘENA | Příkazce uvede stanovisko neuzavření smlouvy. Ředitel OR uvede stanovisko neuzavření smlouvy a uvolní vázané finanční prostředky. | Activity |
Státní tajemník (ST) | Lane | ||
08 | SCHVÁLENÍ / ZAMÍTNUTÍ | Rozhodovací krok. Pokud schváleno: ANO, proces pokračuje automatickým krokem 09 Zaslán ke schválení (podpisu). Pokud schváleno: NE, vráceno zpět do 01 Rozpracován. Pokud schváleno: ZAMÍTNUTO, pokračuje do 21 Zamítnut. | Gateway |
09 | ZASLÁN KE SCHVÁLENÍ | Automatický krok realizovaný na základě schválení (ANO) ST a dokument jde ke schválení na Ředitele SOVZ. | Activity |
Samostatné oddělení VZ (SOVZ) | Lane | ||
10 | SCHVÁLENÍ / ZAMÍTNUTÍ | Rozhodovací krok. Pokud schváleno: ANO, proces pokračuje automatickým krokem 11 Zaslán ke schválení (podpisu). Pokud schváleno: ANO s připomínkami, proces pokračuje do kroku 12 Zpracování připomínek. Pokud schváleno: NE, vráceno zpět do 01 Rozpracován. | Gateway |
11 | ZASLÁN KE SCHVÁLENÍ | Automatický krok realizovaný na základě schválení (ANO) Ředitelem SOVZ a dokument jde ke schválení na OR. | Activity |
Odbor rozpočtu (OR) | Lane | ||
14 | ČEKÁ VE FRONTĚ NA PŘEVZETÍ | Dokument zaslaný ke schválení na OR, čeká na převzetí Rozpočtářem. | Activity |
15 | PŘEVZETÍ ROZPOČTÁŘEM | Dokument byl převzat Rozpočtářem k dalšímu zpracování – schválení. | Activity |
16 | SCHVÁLENÍ / ZAMÍTNUTÍ | Rozhodovací krok (s doporučením pro nadřízeného). Pokud schváleno: ANO, NE nebo ZAMÍTNUTO, vždy pokračuje do 17. | Gateway |
17 | ZASLÁN KE SCHVÁLENÍ | Automatický krok realizovaný na základě schválení (ANO/NE/ZAMÍTNUTO) Rozpočtářem a dokument jde ke Schválení / Zamítnutí na Ředitele OR. | Activity |
18 | SCHVÁLENÍ / ZAMÍTNUTÍ | Rozhodovací krok. Pokud schváleno: ANO, pokračuje do 19. Pokud schváleno: NE, vrací se zpět do 01. Pokud schváleno: ZAMÍTNUTO, pokračuje do 21 Zamítnut. | Gateway |
19 | PODEPSÁN | Krycí list smlouvy je schválen a podepsán Ředitelem OR. | Activity |
20 | AKTIVACE | Rozpočtář provede aktivaci (možnost čerpání) rezervovaných finančních prostředků ve třetím systému. | Activity |
KONEC | Ukončení dokumentového procesu KL. | Event |
10.4. Vzorový business proces – Projektové záměry (PZ)
Obrázek – Diagram business procesu – PZ
Krok č. | Název | Popis | Typ |
Rezortní organizace (RO) MŽP | Lane | ||
START | Začátek business procesu Projektového záměru. Referent RO nastartuje workflow schválení PZ tím, že začne sbírat a připravovat podklady pro Žádost na PZ. | Event | |
01 | Příprava PZ | Referent(i) sbírá a připravuje podklady pro Žádost. | Activity |
02 | Interní schválení | Ředitel RO schválí podklady pro PZ. | Activity |
03 | Vyplnění Žádosti o schválení PZ | Pověřený referent vyplní formulář Žádosti o schválení PZ (*.XLSX). | Activity |
04 | Odeslání Žádosti | Pověřený referent převede dokument formátu *.XLSX do formátu *.PDF a odešle Žádost pomocí DS/ISDS na MŽP. Žádost má obvykle průvodní dopis podepsaný ředitelem RO a může mít také přílohy – např. Projektovou dokumentaci. | Activity |
Odbor ekonomiky životního prostředí (OEŽP) | Lane | ||
05 | Přijetí Žádosti | Na MŽP je Žádost obvykle přijata do DS nebo na ePodatelně, ale může přijít i v analogové (papírové) podobě. Dojde k založení dokumentu v ESSS a přidělení Ev. č. | Activity |
06 | Přijetí sekretariátem OEŽP | Referent sekretariátu OEŽP přijme žádost. | Activity |
07 | Formální kontrola | Rozhodovací krok. Provede se formální kontrola všech náležitostí Žádosti. Pokud schváleno: OK (ANO), přiděluje se na Odpovědného referenta (OR) k dalšímu zpracování v kroku 08. Pokud schváleno: ZAMÍTNUTO, pro formální nedostatky, vrací se Žádost zpět na RO do kroku 01. | Gateway |
08 | Přidělení na OR | Referent sekretariátu nebo Ředitel OEŽP přiděluje Žádost ke zpracování na odpovědného referenta. | Activity |
09 | Přidělení č. j. dokumentu (Založení Spisu, Šanonu ESSS) | Odpovědný referent OEŽP zabezpečí přidělení č. j. a dalších náležitostí v rámci ESSS. | Activity |
10 | Doplnění informací | Odpovědný referent realizuje věcnou kontrolu Žádosti a na jejím základě realizuje komunikaci (mail, telefon, …) s RO, aby provedl doplnění informací nebo provedl jejich opravu. | Activity |
11 | Založení referátníku | Odpovědný referent provede založení referátníku v ESSS, aby mohl Žádost postoupit na OÚ, které provedou další věcnou kontrolu obsahu a budou vypracovávat stanoviska. | Activity |
12 | Předání na SOÚ | Odpovědný referent OEŽP předává Žádost na jeden nebo více OÚ. | Activity |
17 | Vložení do Spisu | Odpovědný referent OEŽP vloží všechna stanoviska vypracovaná OÚ (odbornými referenty) do spisu. | Activity |
18 | Hodnocení stanovisek | Odpovědný referent OEŽP provede vyhodnocení jednotlivých stanovisek OÚ tak, aby mohl připravit Návrh stanoviska ST. | Activity |
19 | Soulad stanovisek | Rozhodovací krok. Pokud schváleno: ANO, pokračuje se na krok 21 Návrh stanoviska ST. Pokud schváleno: NE, pokračuje se krokem 20 Jednání OÚ a OEŽP, kde se musí dojít k souladu. | Gateway |
20 | Jednání OÚ a OEŽP | Odpovědný referent OEŽP svolává jednání OEŽP a OÚ k dojednání souladu stanovisek k Žádosti na PZ. | Activity |
21 | Návrh Stanovisko ST | Odpovědný referent OEŽP vytvoří – připraví Návrh stanoviska ST, který postoupí na Ředitele OEŽP ke schválení. | Activity |
22 | Schválení | Rozhodovací krok. Ředitel OEŽP schvaluje Návrh stanoviska ST. Pokud schváleno: ANO, pokračuje se na krok 23 Předložení návrh stanoviska ST. Pokud schváleno: NE, přepracovat, vrací se Návrh stanoviska ST na přepracování do kroku 21. | Gateway |
23 | Předložení návrhu Stanovisko ST | Ředitel OEŽP předkládá Návrh stanoviska ST ke schválení Státnímu tajemníkovi. | Activity |
25 | Příprava Stanoviska k podpisu | Odpovědný referent OEŽP připraví schválené Stanovisko k podpisu pro Ředitele OEŽP. | Activity |
26 | Podpis Stanovisko ST | Ředitel OEŽP podepíše v zastoupení Státního tajemníka Stanovisko ST. | Activity |
27 | Odeslání Stanovisko ST | Odpovědný referent OEŽP zabezpečí odeslání (ESSS, DS/ISDS) podepsaného Stanoviska ST na RO. | Activity |
Odborný útvar (OÚ) | Lane | ||
13 | Převzetí SOÚ | Referent sekretariátu OÚ převezme Žádost, aby ji dál přidělil na odborného referenta OÚ. | Activity |
14 | Přidělení vybranému OR | Referent sekretariátu nebo ředitel provede přidělení na odborného referenta. | Activity |
15 | Věcná kontrola (Vyžádání info od RO) | Odborný referent provede věcnou kontrolu a v případě potřeby si vyžádá doplňující informace (email, tel., …) od RO. | Activity |
16 | Vypracování a odeslání stanoviska | Xxxxxxx referent vypracuje a odešle stanovisko OÚ k Žádosti na PZ na odpovědného referenta OEŽP. | Activity |
Státní tajemník (ST) | Lane | ||
24 | Schválení | Rozhodovací krok. Státní tajemník schvaluje Návrh stanoviska ST. Pokud schváleno: ANO, pokračuje se na krok 25 Příprava stanoviska k podpisu. Pokud schváleno: NE, vrací se proces k novému hodnocení do kroku 18 Hodnocení stanovisek. | Gateway |
KONEC | Ukončení dokumentového procesu KL. | Event |
11. UŽIVATELSKÉ ROLE
Systém ECM/DMS musí řídit přístupová práva uživatelů pomocí rolí (například pomocí rolí organizační struktury a vzájemných vazeb podřízený/nadřízený anebo přeneseně z nějakého systému třetí strany – např. IDM) a měl by definovat – využívat minimálně následující role:
a. Administrátor, je uživatel s právy na konfiguraci a správu – údržbu systému:
• Správa číselníků;
• Konfigurace a správa workflow;
• Konfigurace a správa notifikací;
• Konfigurace a správa úložiště (architektura – struktura folderů/složek/…, metadat, …);
• Tvorba a správa šablon dokumentů a metadat;
• Konfigurace a správa rolí – přístupových práv, pokud jsou součástí systému;
• Správa monitoringu a logování systému.
b. Super uživatel, je uživatel s právy na konfiguraci a správu vybraných objektů systému:
• Správa číselníků;
• Konfigurace a správa workflow;
• Konfigurace a správa notifikací;
• Konfigurace a správa úložiště (architektura – struktura folderů/složek/…, metadat, …);
• Tvorba a správa šablon dokumentů a metadat.
c. Referent (Zpracovatel), je základní uživatel systému s právy:
• Tvorba, editace, uložení a případně odstranění dokumentu v osobní (vlastní) složce a jejích podsložkách;
• Tvorba, editace, uložení a odstranění metadat dokumentu v osobní (vlastní) složce a jejích podsložkách;
• Správa podsložek a jejích metadat v osobní (vlastní) složce;
• Tvorba, editace, uložení a případně odstranění dokumentu ve struktuře úložiště, dle svého agendového nebo organizačního zařazení;
• Tvorba, editace, uložení a odstranění metadat dokumentu ve struktuře úložiště, dle svého agendového nebo organizačního zařazení;
• Vyhledávání a čtení dokumentů a jejich metadat;
• Spuštění předdefinovaného workflow a stát se případně jeho součástí (připomínkování, schvalování, …);
• Vytvoření a spuštění ad-hoc workflow.
d. Vedoucí oddělení (Příkazce operace nebo Zpracovatel), je uživatel systému se stejnými právy jako jemu podřízené role plus s právy souvisejícími s jeho nadřízeností:
• Stává se jako aktér součástí workflow, v jehož rámci rozhoduje (schvaluje/neschvaluje) nebo připomínkuje a doplňuje informace – dokumenty, které jsou mu v takové aktivitě přidělené;
• Úkoluje své podřízené ve vztahu k workflow a spravovaným dokumentům.
e. Ředitel odboru (Příkazce operace), je uživatel systému se stejnými právy jako jemu podřízené role plus s právy souvisejícími s jeho nadřízeností.
f. Náměstek ministra, je uživatel systému se stejnými právy jako jemu podřízené role plus s právy souvisejícími s jeho nadřízeností.
g. Státní tajemník, je uživatel systému se stejnými právy jako jemu podřízené role plus s právy souvisejícími s jeho nadřízeností.
h. Ministr, je uživatel systému se stejnými právy jako jemu podřízené role plus s právy souvisejícími s jeho nadřízeností.
12. DOKUMENTOVÉ TYPY A JEJICH VYBRANÁ METADATA
12.1. Xxxxxx Xxxxxxxxx zakázek a Smluv
V rámci agend Veřejné zakázky a Smlouvy byly identifikovány následující dokumentové typy a metadata.
12.1.1. Xxxxxxx xxxxxxx (VZ)
Metadata | |||
Dokumentový typ [počet] | Základní | Sekundární | Systémové / Procesní |
PODNĚT [1] | - Identifikační číslo záměru (IČZ) - Číslo odboru [př. 210] - Zpracovatel [př. Xxxxx Xxxxx] - Příkazce [př. Xxxx Xxxxxxxxx] - Dokumentový typ [př. Podnět] - Dokumentový podtyp [př. Žádanka] - Předmět-věc [př. Implementace ITSM/ITIL] - Popis (stručný popis předmětu) | viz další analýza | - Kdo a Kdy vytvořil, změnil, smazal apod. - Popis stavů, - Kdo a Kdy připomínkoval, schválil apod., viz další analýza |
PODKLAD TECHNICKÉ SPECIFIKACE [1..N] | viz PODNĚT | ||
TECHNICKÁ SPECIFIKACE (TS) [1..N] | viz PODNĚT | ||
PRŮZKUM TRHU (RFI) [1] | viz PODNĚT | ||
ODPOVĚĎ NA PRŮZKUM TRHU (RRFI) [1..N] | viz PODNĚT |
VYHODNOCENÍ [1] | viz PODNĚT | ||
STANOVENÍ HODNOTY [1] | viz PODNĚT | ||
ODŮVODNĚNÍ ÚČELNOSTI [1] | viz PODNĚT | ||
EVIDENČNÍ LIST (EL) [1..N] | viz PODNĚT + - Druh VZ (př. VMZR, …) - Identifikační číslo EL | ||
ZADAVÁCÍ DOKUMENTACE1 (ZD) [1..N] | viz EVIDENČNÍ LIST | ||
DOKUMENTACE O VZ2 [1..N] | viz EVIDENČNÍ LIST | ||
SMLOUVA3 [1] | viz EVIDENČNÍ LIST + - Evidenční číslo Smlouvy (SML) | ||
ODŮVODNĚNÍ VÝBĚRU DODAVATELE [1] | viz EVIDENČNÍ LIST + - Evidenční číslo Smlouvy (SML) | ||
KRYCÍ LIST (KL) [1] | viz EVIDENČNÍ LIST + - Evidenční číslo Smlouvy (SML) | ||
OSTATNÍ DOKUMENTACE | viz PODNĚT |
Poznámky:
1 V Zadávací dokumentaci se mohou objevit dokumenty typu:
- Krycí list;
- Čestné prohlášení o:
• splnění podmínek základní způsobilosti;
• splnění technické kvalifikace;
• neexistenci střetu zájmů a pojištění odpovědnosti za škodu;
- Technická specifikace apod.
2 Smlouvy jsou vedené ve vlastní agendě, nicméně jsou typy smluv, které souvisí s VZ, a proto musí být s VZ minimálně logicky nebo jinak svázané.
3 Do Dokumentace o VZ patří například dokumenty:
- Seznam oslovených dodavatelů;
- Žádost o vysvětlení/změnu/doplnění zadávací dokumentace;
- Vysvětlení/změna/doplnění zadávací dokumentace;
- Námitky dodavatele proti zadávacím podmínkám;
- Rozhodnutí zadavatele o podaných námitkách;
- Protokol o otevírání nabídek;
- Zpráva o hodnocení nabídek;
- Rozhodnutí o výběru dodavatele;
- atd.
12.1.2. Smlouvy
Metadata | |||
Dokumentový typ [počet] | Základní | Sekundární | Systémové / Procesní |
SMLOUVA k VZ1 [1] | - Evidenční číslo z Centrální evidence smluv (EČCES) - Objednatel [př. ČR – Ministerstvo životního prostředí] - Jedná za Objednatele [př. Xxxx Xxxxxxxxx] - Zpracovatel [př. Xxxxx Xxxxx] - Číslo odboru [př. 210] - Dodavatel [př. Firma XZY] | - Odměna bez DPH - Odměna s DPH - V rámci plnění sml. jedná za Objednatele - V rámci plnění sml. jedná za Dodavatele viz další analýza | - Kdo a Kdy vytvořil, změnil, smazal apod. - Popis stavů, - Kdo a Kdy připomínkoval, schválil apod., viz další analýza |
- Jedná za Dodavatele [př. Jméno Příjmení] - Dokumentový typ [př. Smlouva k VZ] - Dokumentový podtyp [př. Kupní smlouva] - Název [př. Služba auditu procesu VZ a Smluv] - Popis (stručný popis předmětu) - Podepsal za Objednatele [př. Xxxx Xxxxxxxxx] - Podepsal za Poskytovatele [př. Jméno Příjmení] - Datum podpisu za Obj.[př. DD. MM. RRRR] - Datum podpisu za Poskyt. [př. DD. MM. RRRR] - Datum nabití platnosti [př. DD. MM. RRRR] - Datum nabití účinnosti [př. DD. MM. RRRR] - Datum ukončení smlouvy [př. DD. MM. RRRR] | |||
SMLOUVA mimo VZ2 [1] | Viz SMLOUVA k VZ | ||
RÁMCOVÁ DOHODA3 [1] | Viz SMLOUVA k VZ | ||
OSTATNÍ DOKUMENTACE4 [1..N] | Viz SMLOUVA k VZ |
Poznámky:
1 Ve Smlouvách k VZ se mohou objevit dokumenty typu:
- Kupní smlouva;
- Smlouva o dílo;
- Smlouva o poskytování služeb;
- Licenční smlouva;
- Pojistná smlouva atd.
2 Ve Smlouvách k VZ se mohou objevit dokumenty typu:
- Nájemní smlouva;
- Podnájemní smlouva;
- Darovací smlouva;
- Smlouva o centralizovaném zadávání;
- Partnerská dohoda atd.
3 V Rámcových dohodách se mohou objevit dokumenty typu:
- Rámcová dohoda s jedním dodavatelem bez obnovení soutěže;
- Rámcová dohoda s jedním dodavatelem s obnovením soutěže;
- a to samé s více dodavateli.
4 V Ostatní dokumentaci se mohou objevit dokumenty typu:
- Dodatek ke smlouvě;
- Dohoda o ukončení smlouvy;
- Výpověď smlouvy;
- Odstoupení od smlouvy atd.
12.2. Agenda Projektových záměrů
Metadata | |||
Dokumentový typ [počet] | Základní | Sekundární | Systémové / Procesní |
ŽÁDOST [1] | - Identifikační číslo projektového záměru (IČPZ) - Resortní organizace [př. AOPK] - Projektový manažer [př. Xxxxxxxxx Xxxxxx ] - Odborný gestor [př. Xxxxxxxx Xxxxx] - Dokumentový typ [př. Žádost] - Dokumentový podtyp [př. Projektový záměr] - Název záměru [př. Rekonstrukce elektroinstalace jídelny] - Popis záměru (stručný popis záměru) - Typ záměru (výběr z číselníku) - Dopad projektu (výběr z číselníku) - Zdroj financování (výběr z číselníku) - Termín předpokládaného zahájení [DD. MM. RRRR] - Termín předpokládaného ukončení [DD. MM. RRRR] - Celková cena v Kč (bez DPH) - Celková cena v Kč (vč. DPH) | Existence připojených (souvisejících) souborů [Ano/Ne]: - Rámcová studie proveditelnosti - Komplexní studie proveditelnosti - Ekonomický rozbor stávajícího a budoucího stavu - Seznam obnovovaných zařízen - Ekonomický rozbor efektivnosti realizace investice - Projektová dokumentace (vč. Položkového rozpisu) - Mapové podklady - Bližší specifikace projektového záměru a jeho zdůvodnění viz další analýza | - Kdo a Kdy vytvořil, změnil, smazal apod. - Popis stavů, - Podaná, - Vrácena k doplnění, - Odborné hodnocení - Hodnocení 252 - Čeká na stanovisko ST - Schválená / Zamítnutá - Kdo a Kdy připomínkoval, schválil apod., viz další analýza |
DOPLŇKOVÁ DOKUMENTACE [1..N] | - IČPZ - Resortní organizace - Projektový manažer - Odborný gestor - Dokumentový typ - Dokumentový podtyp - Název záměru - Zpracovatel [př. jméno zpracovatele – OR] - Příkazce [př. jméno ŘO] - Věc | viz další analýza | viz další analýza |
STANOVISKO OÚ [1..N] | Viz DOPLŇKOVÁ DOKUMENTACE | ||
ZÁPIS Z JEDNÁNÍ [1..N] | Viz DOPLŇKOVÁ DOKUMENTACE | ||
STANOVISKO ST [1] | Viz DOPLŇKOVÁ DOKUMENTACE | ||
OSTATNÍ DOKUMENTACE [1..N] | Viz DOPLŇKOVÁ DOKUMENTACE |
Detailní návrh na požadavky dokumentových typů a jejich metadat bude proveden v Implementačním návrhu (návrhu implementace).
13. ÚLOŽIŠTĚ EL. DOKUMENTŮ
ECM/DMS bude sloužit pro uložení vybraných elektronických (digitálních) dokumentů pro celou organizaci ministerstva – všech jejích organizačních jednotek (sekce, odbory, oddělení atd.) a v budoucnu by mohla sloužit, v rámci vybraných agend, i k uložení a sdílení vybraných dokumentů (např. žádostí) z resortních organizací ministerstva.
Výše uvedenému musí odpovídat navržená architektura – struktura úložiště ECM/DMS. Detailní návrh na požadavky a vymezení této struktury bude provedeno v Implementačním návrhu (návrhu implementace). Budoucí změny a úpravy této struktury musí být proveditelné oprávněnými uživateli (např. Administrátor, Super uživatel, …) ministerstva.
V rámci Realizační studie a implementace ECM/DMS musí být vytvořená struktura minimálně pro (již výše vyjmenované) agendy:
- Xxxxxxx xxxxxxx;
- Projektové záměry, a s nimi spojené typy dokumentů, metadat a procesů.
Nicméně je nutné počítat i s tím, že:
- ECM/DMS musí nabídnout v rámci jednotného úložiště i prostor pro osobní složky každého uživatele a jednotlivé organizační jednotky organizace. Vnořená struktura těchto složek (osobních nebo organizačních jednotek) pak bude ponechána na rozhodnutí jednotlivců v případě osobních složek, a na rozhodnutí vedoucích pracovníků v případě organizačních jednotek.
- Do budoucna se mohou objevit další „agendy“ s potřebou správy a řízení dokumentů – např. Management kvality; Směrnice a metodiky; Předpisy a nařízení; Žádanky; …) a ECM/DMS musí být schopné upravit, doplnit nastavení struktury úložiště, aby odpovídalo i těmto novým požadavkům spojeným s implementací nových typů dokumentů, metadat a s nimi spojených workflow – procesů.
Příloha č. 2 – Funkční (business) požadavky
(následuje)
Příloha č. 8: Funkční (business) požadavky (FPO)
Enterprise Contenet Management System - systém pro správa a řízení elektronických dokumentů | |||||
Číslo | Název | Popis | Důležitost | Je součástí | Plnění (vyberte hodnotu) |
Správa dokumentů a metadat (SD) | |||||
FPO_SD_01 | Základní operace | ECM/DMS obsahuje vlastnosti pro snadné, intuitivní vytváření, ukládání, přesouvání, kopírování, mazání dokumentů, složek a virtuálních složek (a v případě dokumentů i hromadné), které jsou přístupné z tentého klienta (např. MS IE, Google Chrome apod.), desktopových aplikací (např. File Explorer, MS Office/Outlook, IBM Notes, Adobe Acrobat/Reader apod.), ale také z mobilních aplikací chytrých zařízení (iOS a Android) , to vše samozřejmě s ohledem na autorizaci konkrétního uživatele. | Povinný | Ano | Vyřešeno |
FPO_SD_02 | Vkládání (upload) dokumentů | Systém musí umožnit vkládat (importovat) dokumenty do ECM/DMS z prostředí: - Desktop klienta (tlustý klient, pokud existuje), - File Exploreru, ECM/DMS systém musí být integrovaný s OS tak, aby se v prohlížeči ukazoval (a jeho struktura) jako virtuální disk, - MS Office, - MS Outlook/IBM Notes (volitelně jiného eMail kienta), - Adobe Acrobat / Reader, - WEB klienta (tenký klient - MS IE, Google Chrome, Mozila Firefox) - Smart App (aplikací pro chytrá zařízení iOS a Andriod, pokud existují) Ve všech výše uvedených případech musí být systém schopen nabídnout možnost, vyplnit k dokumentu i příslušná metadata s tím, že bez vyplnění těch povinných, není možné dokument do systému uložit. Při hromadném vkládání je nutné zabezpečit postupné ukládání společně s povinnými, nepovinnými i systémovými metadaty. Při vkládání dokumentu do systému se vždy, společně s dokumentem, ukládají i systémová metadata - např. kdo ukládá, datum a čas uložení apod. | Povinný | Ano | Částečně |
FPO_SD_03 | Ruční vložení eMailu | Možnost ručního uložení eMailu do složky (obecně struktury) ECM/DMS a to buď: - celého eMailu jako souboru (např. *.msg, *.eml), nebo - souboru/ů tvořících přílohu eMailu, | Povinný | Ano | Vyřešeno |
FPO_SD_04 | Automatické vložení eMailu | Možnost automatického uložení eMailu do struktury ECM/DMS přeposláním na definovanou e-mail adresu. | Povinný | Ano | Vyřešeno |
FPO_SD_05 | Stahování (download) dokumentů | Systém obsahuje vlastnosti pro stahování jednotlivých dokumentů, ale i možnost stáhnout dokumenty hromadně, mimo úložiště ECM/DMS. Společně s dokumentem nebo dokumenty je možné stáhnout i metadata. Stahování je umožněno pouze oprávněnému uživateli. | Povinný | Ano | Vyřešeno |
FPO_SD_06 | Omezení stahování dokumentů | Systém umožňuje omezit stahování dokumentů z definovaných složek na lokální úložiště (HDD, USB, SmartCard, …) uživatele. | Povinný | Ano | Částečně |
FPO_SD_07 | Kopírování (copy) dokumentů | Systém umožňuje kopírovat zvolený dokument nebo množinu dokumentů v rámci systému ECM/DMS a to včetně metadat a vazeb na ostatní dokumenty - objekty v systému. Při kopírování lze vybrat, zda v novém umístění bude vytvořena fyzická kopie nebo pouze odkaz (zástupce) na zdrojový dokument. | Povinný | Ano | Vyřešeno |
FPO_SD_08 | Přesouvání (move) dokumentů | Systém umožňuje přesouvat zvolený dokument nebo množinu dokumentů v rámci systému ECM/DMS a to včetně metadat a vazeb na ostatní dokumenty - objekty v systému. | Povinný | Ano | Vyřešeno |
FPO_SD_09 | Mazání (delete) dokumentů | Oprávněný uživatel nebo administrátor může v systému, dle přístupových práv, mazat jím zvolené dokumenty a strukturu, ve které jsou umístěné a to včetně jejich metadat a vazeb a to i hromadně. Systém automaticky kontroluje existenci/neexistenci objektů a v případě, že jsou odakzované objekty smazány, smaže i neplatné odkazy. | Povinný | Ano | Vyřešeno |
FPO_SD_10 | Obnova (restore) dokumentů | Oprávněný uživatel má právo obnovit smazaný dokument nebo dokumenty včetně metadat a vazeb (individuálně či hromadně), pokud má příslušná oprávnění a nedošlo k trvalému odstranění nebo skartaci (viz nastevní archivace/skartace). Trvale smazané dokumenty (a metadata) je možné obnovit pouze ze systémové zálohy. | Povinný | Ano | Vyřešeno |
FPO_SD_11 | Odkaz (URL link) | Systém obsahuje funkci pro vytvoření odkazů (URL linků) na dokumenty, složky nebo jiné objekty. Uživatel s linkem pracuje tak, že ho může vkládat do emailů, dokumentů atd. Při kliknutí na odkaz se uživateli otevře napojený dokument, tuto vlastnost musí ECM/DMS podporovat pro přístupy v rámci vnitřního prostředí ICT organizace. | Povinný | Ano | Vyřešeno |
FPO_SD_12 | Odkaz - verze dokumentu | Odkaz (URL link) vede vždy na aktuální (poslední) verzi dokumentu. | Povinný | Ano | Vyřešeno |
FPO_SD_13 | Vzájemný odkaz | Relevantní dokumenty je možné prolinkovat vzájemně. Prolinkování je možné i vícenásobné - více jak dva dokumenty. | Povinný | Ano | Vyřešeno |
FPO_SD_14 | Agendová správa dokumentů | Možnost spravovat a řídit jednotlivé dokumenty (dokumentové typy) po agendách. Příkladem takových agend nechť jsou agendy typu: - Veřejné zakázky, - Projektové záměry, - Smlouvy, - Předpisy a směrnice, - Žádanky, - ISO dokumentace apod. Je důležité čím dokument (obecně obsah) je nikoli, kde je uložen - zařazen. | Povinný | Ano | Vyřešeno |
FPO_SD_15 | Sdílené úložiště | Oprávněný uživatel může vytvářet sdílené složky/podsložky nebo virtuální složky/podsložky tak, že garantují možnost vygenerování korektního odkazu (URL linku). Tyto složky mohou teoreticky obsahovat neomezené množství dokumentů (viz limit OS), ke kterým se dědí oprávnění dle složky, ve které jsou vytvořeny. Oprávněný uživatel může definovat i ad-hoc přístupy pro konkrétního uživatele (zaměstnance organizace) či skupinu uživatelů. | Povinný | Ano | Vyřešeno |
FPO_SD_16 | Osobní úložiště | Systém umožní vytvořit pro každého uživatele osobní úložiště dokumentů (např. jako Moje, Osobní, Mé oblíbené apod.), které bude přístupné jenom danému uživateli a administrátorovi. | Povinný | Ano | Vyřešeno |
FPO_SD_17 | Agendová správa dokumentů | Možnost spravovat a řídit jednotlivé dokumenty (dokumentové typy) po agendách. Příkladem takových agend nechť jsou agendy typu: - Veřejné zakázky, - Projektové záměry, - Smlouvy, - Předpisy a směrnice, - Žádanky, - ISO dokumentace apod. | Povinný | Ano | Vyřešeno |
FPO_SD_18 | Náhled dokumentu | Nativní náhled dokumentů s využitím interních viewerů pro jejich snadné čtení - prohlížení obsahu dokumentů (a jejich případnou následnou editaci v asociovaném editačním nástroji). Systém musí podporovat minimálně násleující formáty pro nativní zobrazení: - MS Office (*.docx, *.xlsx, *.pptx), - Adobe Acrobat (*.pdf), - Text (*.rtf, *.txt, *.csv, *.xml, *.htm/html) - Obraz ( *.jpg, *.tiff, *.bmp, *.gif, *.png) | Povinný | Ano | Vyřešeno |
FPO_SD_19 | Editace (edit) dokumentů | Nativní editace dokumentů (souborů kompatibilních formátů) s využitím interních editorů nebo asociace desktopových anebo cloudových aplikací (např. MS Office, Adobe Acrobat, …) | Povinný | Ano | Vyřešeno |
FPO_SD_20 | Verzování | Systém provádí automatické (nativní vlastnost) verzování dokumentů i s jejich jasným (jednoznačným) označením. | Povinný | Ano | Vyřešeno |
FPO_SD_21 | Verzování - nová verze | Nová verze dokumentu vzniká vždy při jeho explicitním uložení v úložišti ECM/DMS. | Povinný | Ano | Vyřešeno |
FPO_SD_22 | Verzování - označování verzí | Každá verze je opatřena nejlépe (obvykle) pořadovým číslem a názvem. Informace o počtu verzí a jednotlivých existujících verzích dokumentu je součástí metadat. | Povinný | Ano | Vyřešeno |
FPO_SD_23 | Verzování - prohlížení verzí | Uživatel s potřebnými právy má možnost prohlížet všechny verze dokumentu. | Povinný | Ano | Vyřešeno |
FPO_SD_24 | Verzování - vyběr aktuální verze | Uživatel s potřebnými právy má možnost vybrat ze všech existujících verzí takovou verzi, kterou označí za aktuální - poslední platnou verzi. | Povinný | Ano | Vyřešeno |
FPO_SD_25 | Metadata | Systém musí umožnit přiřadit každému dokumentu, složce, agendě (obecně objektu obsahu ECM/DMS) určitá metadata. Oprávněný uživatel může definovat další metadata k jednotlivým objektům a editovat je. Ukládání metadat se reallizuje společně s jejich dokumenty - objekty. | Povinný | Ano | Vyřešeno |
FPO_SD_26 | Metadata - datové typy | Systém musí podporovat obvyklé datové typy: - numerické, - alfanumerické, - logické, - datum/čas, - vazbu na jinou hodnotu, na jiný objekt (dokument, složku, agendu apod.) - vazbu na uživatele, - vazba na jiná metadata, - apod. Systém s nimi musí umět pracovat jako s příslušným datovým typem. | Povinný | Ano | Vyřešeno |
FPO_SD_27 | Metadata - číselníky a složené číselníky | Metadata mohou být vybírána z číselníků - seznamů. Určité hodnoty metadat mohou být definovány v rámci složených číselníků. Tzn. že základní hodnota - např. číslo sekce organizace předurčuje další možné hodnoty čísla odboru apod. | Povinný | Ano | Vyřešeno |
FPO_SD_28 | Metadata - kontrola | Systém musí kontrolovat metadata: - formát, - logickyckou správnost (např. nelze zadat datum 33.16.2020), - obsahovou správnost (např. proti číselníku), - platnost odkazu na související objekt (zda existuje). při jejich vkládání, editaci nebo při jejich importu ze třetích systémů. | Povinný | Ano | Vyřešeno |
FPO_SD_29 | Metadata - systémová | Systém automaticky přiřazuje každému dokumentu (objektu obsahu), který je vkládán, editován i systémová metadata (za účelem monitoringu a auditu). Mezi tyto atributy patří např. autor, datum uložení, autor změny, datum změny, velikost a formát dokumentu apod.. | Povinný | Ano | Vyřešeno |
FPO_SD_30 | Metadata - šablony | Systém pro každý typ dokumentu (objekt) umožňuje vytvořit vlastní šablonu, která bude definovat povinná i nepovinná metadata, včetně nastavení základních hodnot. Tyto šablony je možné sdílet napříč systémeme a jeden dokument (objekt) může mít přiděleno více šablon. | Povinný | Ano | Vyřešeno |
FPO_SD_31 | Metadata - správa šablon | Oprávněný uživatel může spravovat šablony metadat k příslušným typům dokumentů (objektů) na základě svých oprávnění, a to včetně datových typů a číselníků metadat. | Povinný | Ano | Vyřešeno |
FPO_SD_32 | Metadata - dokumentové typy | Oprávněný uživatel může definovat dokumentový typ (např. Stanovisko, Smxxxxxx, Nařízení, Žádost, Rozhodnutí ve správním řízení apod.), který je společný pro celý ECM/DMS a přiřadit mu příslušnou šablonu metadat. | Povinný | Ano | Vyřešeno |
FPO_SD_33 | Metadata - omezení | Systém podporuje teoreticky neomezený počet (viz limit OS) položek metadat pro každý dokument (objekt). | Povinný | Ano | Vyřešeno |
FPO_SD_34 | Metadata - přístup | Systém umožňuje definovat přístup k metadatům - CO, KDY a KDO. Oprávnění ke změně obsahu vybraných metadat dokumentů nastavuje pouze oprávněný uživatel/administrátor. | Povinný | Ano | Částečně |
FPO_SD_35 | Metadata - tisk | Systém musí umožnit vytisknout informace - metadata - o určitém dokumentu (objektu) v ECM/DMS. | Povinný | Ano | Vyřešeno |
FPO_SD_36 | Zamknutí dokumentu | Možnost zamknutí dokumentu po jeho schválení. | Povinný | Ano | Vyřešeno |
FPO_SD_38 | Přístupová práva | Oprávněný uživatel musí mít možnost definovat minimálně následující oprávnění k objektům (dokument, složka, agenda atd., dle struktury ECM/DMS ): - vytvoř, - zobraz/čti, - edituj, - kopíruj/přesouň, - vymaž, | Povinný | Ano | Vyřešeno |
FPO_SD_39 | Zamknutí dokumentu | Možnost zamknutí dokumentu po jeho schválení. | Povinný | Ano | Vyřešeno |
FPO_SD_40 | Archivace - skartace | Systém musí umožnit protokolární archivaci nebo skartaci dokumentů a to buď: - ruční, nebo - automatickou, na základě nastavení skartačního znaku a data skartace (expirace). | Povinný | Ano | Vyřešeno |
Vyhledávání (VH) |
FPO_VH_01 | Fulltextové vyhledávání | Systém umožňuje vysoce výkoné fulltextové vyhledávání, které probíhá nad celým obsahem: - dokumenty, - metadaty, - připomínkami a komentáři, - procesy (aktivními i ukončenými). Systém musí umožnit vyhledávat fulltextově pro jeden až N výrazů. | Povinný | Ano | Vyřešeno |
FPO_VH_02 | Vyhledávání dle kritérií | Systém bude obsahovat možnost vyhledávání podle kritérií, která může sestavit uživatel jako kombinaci dostupných metadat k dokumentu (objektu) v celém úložišti nebo ve vybrané části úložiště. | Povinný | Ano | Vyřešeno |
FPO_VH_03 | Vyhledávací operátory | Uživatel musí mít možnost využít pro vyhledání, dle více kritérii, různé operátory (např. =, <, >, apod.) 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). | Povinný | Ano | Vyřešeno |
FPO_VH_04 | Zpřesnění vyhledávání | Systém umožňuje uživateli vyhledávání dodatečně zpřesnit - zpřesnit výběrová kritéria a opakovat dotaz anebo vyhledávat již v množině výsledků předchozího dotazu. | Povinný | Ano | Vyřešeno |
FPO_VH_05 | Kombinované vyhledávání | Systém umožní kombinovat uživateli fulltextové vyhledávání a vyhledáváním podle kritérií (metadat). | Povinný | Ano | Vyřešeno |
FPO_VH_06 | Vyhledávání ve složkách | Systém umožní uživateli omezit prohledávaný prostor na definované agendy, složky nebo virtuální složky a následně spustit fulltextové vyhledání nebo vyhledání dle kritérií anebo kombinaci. | Povinný | Ano | Vyřešeno |
FPO_VH_07 | Prohledávané formáty | Systém musí umožnit fulltextově vyhledávat minimálně v následujících formátech: - PDF, PDF-A/1, - MS Office (*.docx, *.xlsx, *.pptx ), - MS Outlook, (*.msg), IBM Notes (*.eml), - Text (*.rtf, *.txt, *.csv, *.xml, *.htm/html) | Povinný | Ano | Vyřešeno |
FPO_VH_08 | Velká a malá písmena | Systém musí umožnit provádět vyhledávání bez ohledu na rozlišení velkých a malých písmen. | Povinný | Ano | Vyřešeno |
FPO_VH_09 | Zástupné znaky | Systém musí umožnit vyhledávání pomocí zástupných znaků (např. *, ?, % apod.), a to jak v obsahu dokumentů (fulltext), tak i metadatech. | Povinný | Ano | Vyřešeno |
FPO_VH_10 | Uložení dotazu | Systém umožňuje uložit uživatelský dotaz k budoucímu znovupoužití. | Volitelný | Ano Ano Ano | Vyřešeno Vyřešeno Vyřešeno |
FPO_VH_11 | Zpracování výsledků po vyhledávání | Systém zobrazí uživateli všechny úspěšné výsledky vyhovující zadaným vyhledávacím podmínkám s možností přímého provedení jednotlivých nebo hromadných operací nad vyhledanými dokumenty (např.: otevření/editace, kopírování, zaslání notifikace apod.). | Volitelný | ||
FPO_VH_12 | Zvýraznění vyhledávaných slov | Systém umožňuje zvýraznění (např. podbarvení, podtržení apod.) vyhledaných slov v náhledu dokumentu pro všechny formáty fulltextově prohledávaných dokumentů. | Volitelný | ||
FPO_VH_13 | Zpřístupnění dokumentu | Systém musí umožnit, aby dokumenty (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, a poku jsou to dokumenty pak v nativním vieweru anebo v asociovaném programu/aplikaci. | Povinný | Ano | Vyřešeno |
FPO_VH_14 | Definice zobrazení výsledků | Systém umožňuje uživateli upravit zobrazení výsledků vyhledávání následujícím způsobem: - vybrat řazení sloupců v pohledu, - zvolit, která pole metadat (sloupce) se zobrazí v pohledu, - stanovit počet výsledků zobrazených na obrazovce (tzv. stránkování), - stanovit maximální počet výsledků, - provést otevření dokumentu. | Volitelný | Ano | Částečně |
FPO_VH_15 | Tisk zobrazených výsledků | Systém umožnuje uživateli vytisknout seznam výsledků z provedeného vyhledávání. | Povinný | Ano | Částečně |
FPO_VH_16 | Export zobrazených výsledků | Systém umožnuje uživateli vyexportovat seznam výsledků hledání do nejméně těchto formátů souborů: *.csv, *.rtf a *.xlsx. | Povinný | Ano | Bude vyvinuto |
Správa procesů (SP) | |||||
FPO_SP_01 | Řízení workflow (wf) | Systém musí umožnit řízení vícekrokových dokumentových wokflow (procesů) prímárně určených pro připomínkování a schvalování dokumentu Konkrétní příklady takových komplexních wf pro agendy Veřejné zakázky, Smlouvy a Projektové záměry a jejich dokumenty uvádíme v dokumentu "Příloha _01 - Věcné - manažerské zadání", který je nedílnou součástí smlouvy jako její příloha. | Povinný | Ano | Vyřešeno |
FPO_SP_02 | Správa wf | Systém musí umožnit správu - tvorbu, konfiguraci, zobrazení, změnu, smazání vícekrokových dokumentových procesů. Výhodou je, pokud bude schopen tyto aktivity realizovat oprávněný uživatel/administrátor systému - vyškolený zaměstnanec (nebo externista) organizace Objednatele. Systém musí umožnit vytvořit workflow jako "šablonu" a pak ji přiřadit určitýmu dokumentům. | Povinný | Ano | Vyřešeno |
FPO_SP_03 | Typy wf schémat | Systém musí podporovat následující typy procesních schémat: - sériové, - paralelní, a - kombinované (sériobvé a paralelní) v rámci jednoho procesu, a jejich možné větvení na základě všech existujících metadat (dokumentových, procesních, …, systémových atd.). Paralelním workflow (připomínkování, schvalování, ...) se přitom rozumí možnost více uživatelů aktivně působit vůči dokumentu/ům ve stejném čase. Jeden dokument může procházet přes více typů workflow a jedno workflow může řídit více typů dokumentů. | Povinný | Ano | Vyřešeno |
FPO_SP_04 | Spouštění wf | Systém musí umožnit spuštět proces: - ručně, - automaticky (svázané s nějakou událostí nebo stavem), | Povinný | Ano | Vyřešeno |
FPO_SP_05 | Typy automatického spuštění wf | Systém musí podporovat minimálně následující typy spuštění: - časové (jednotlivé, opakované), - nový dokument, - změna dokumentu, - na základě metadat (hodnoty nebo její změny), | Povinný | Ano | Vyřešeno |
FPO_SP_06 | Ad-hoc wf | Systém by měl umožnit uživateli vytvořit Ad-hoc workflow (nejlépe modulárně - z jednotlivých akcí) tak, že si uživatel může vybrat - konfigurovat, jak bude workflow dokumentu vypadat. Uživatel operativně vytváří individuální Ad-hoc workflow dle svých potřeb nebo zadaného úkolu ke konkrétnímu řízení (připomínkování, schvalování, ...). | Volitelný | Ano | Vyřešeno |
FPO_SP_07 | Týmová práce / Sdílení | Systém musí zabazpečit uživatelům možnost kooperace nad dokumentem nebo dokumenty a musí být schopen posílat pomocí notifikací - emailů odkazy (URL linky) na dokumenty (nebo i další objekty obsahu) tak, aby nad sdílenými informacemi (objekty) obsahu mohli jednotliví uživatelé kolaborovat. | Povinný | Ano | Vyřešeno |
FPO_SP_08 | Týmová práce / Oprávnění | V případě odeslání notifikace s odkazem na dokument (objekt) obsahu dostanou notifikovaní uživatelé automaticky k tomuto objektu přístupové právo pro čtení - tzv. dynamické přidělení přístupu pro čtení k dokumentu (objektu). | Povinný | Ano | Vyřešeno |
FPO_SP_09 | Týmová práce / Oprávnění na související | V případě odeslání notifikace s linkem na dokument (objekt) obsahu dostanou notifikovaní uživatelé automaticky přístupová práva také na čtení dokumentů a případně i souvisejících dokumentů dle metadat k odkazovanému dokumentu. | Volitelný | Ano | Vyřešeno |
FPO_SP_10 | Týmová práce / Připomínkování | Připomínky k dokumentu je možné v ECM/DMS vytvořit: - do zvláštního dokumentu (šablona „připomínky“), který se propojí na připomínkovaný dokument, anebo - přímo do dokumentu (vytvoření nové verze), a to formou komentářů nebo návrhů změn přímo do textu dokumentu, Systém pak musí umožnit oprávněnému uživateli zpracování takto vytvořených připomínek k dokumentu. | Povinný | Ano | |
FPO_SP_11 | Týmová práce / Co-authoring | ECM/DMS by měl umožnit více uživatelům společnou práci, v jednom časovém okamžiku, nad jedním dokumentem - tzv. co- authoring neboli spoluautorství. Jednotliví uživatelé (editoři) mohou vidět v reálném čase změny realizované ostatními editujícími uživateli v dokumentu. Výsledkem tohoto spoluautorství více uživatelů v jednom dokumentu musí být automatizovaně zkompilovaná verze dokumentu, která obsahuje všechny změny všech uživatelů, a která dovolí oprávněnému uživateli přijmout či odmítnout jednotlivé navržené změny uživateli a vytvořit konsolidovanou verzi dokumentu. | Volitelný | Ne | |
FPO_SP_12 | Týmová práce / Zastoupení | Systém musí umožnit uživateli nastavit po dobu jeho nedostupnosti svého zástupce. Aktivity (např. připomínkování, schvalování apod,) směřované v rámci workflow na uživatele pak budou v době jeho nedostupnosti přesměrovány na zástupce. | Povinný | Ano | Vyřešeno |
FPO_SP_13 | Grafický nástroj wf | Výhodou ECM/DMS je existence grafického nástroje pro tvorbu a správu workflow. | Volitelný | Ano Ne | Vyřešeno |
FPO_SP_14 | Samospráva wf | Výhodou ECM/DMS je možnost spravovat (navrhovat, implementovat, měnit, ...) workflow vlastními vyškolenými zdroji - oprávněný uživatel/administrátor. | Volitelný | ||
Uživatelské prostředí (UP) | |||||
FPO_UP_01 | Základní rozhrarní | ECM/DMS obsahuje jednoduché, přehledné, srozumitelné, ergonomické grafické rozhraní, které slouží uživateli pro práci s dokumenty a dalšími objekty systému, k obsluze workflow (procesů) a vyřízení přidělených úkolů, k prohledávání obsahu. Systém musí umožnit uživateli konfiguraci úvodní obrazovky tak, aby uživatel, při přihlášení do systému, vstoupil do prostředí, které mu bude nabízet primárně dokumenty (objekty) a služby, jemu přidělené ke zpracování. Základní vstupní obrazovka (dashboard) bude pro všechny uživatele stejná a bude obsahovat minimálně tyto možnosti - hledat dokumenty, - procházet základní a vytvořenou strukturu, - procházet nedávno otevřené anebo oblíbené dokumenty, - procházet vlastní úkoly, - procházet rezervované "Check Out" dokumenty, | Povinný | Ano | Vyřešeno |
FPO_UP_02 | Rychlý přístup na posledně použité dokumenty | Systém musí umožnit rychlý přístup k posledně otevřeným (editovaným) dokumentům bez nutnosti zdlohavého prohledávání složité struktury složek nebo virtuálních složek. | Povinný | Ano | Vyřešeno |
FPO_UP_03 | Rychlý přístup na často používané nebo oblíbené dokumenty | Systém musí umožnit rychlý přístup k často používaným nebo oblíbeným dokumentům bez nutnosti zdlohavého prohledávání složité struktury složek nebo virtuálních složek. | Povinný | Ano | Vyřešeno |
FPO_UP_04 | Rychlý přístup na nově přidané dokumenty | Systém podporuje zobrazení nejnověji přidaného dokumentu/ů pro relevantního uživatele. | Volitelný | Ano | Vyřešeno |
FPO_UP_05 | Disk/složka v prohlížeči klientského OS | Systém musí umožnit uživateli přidat úložiště ECM/DMS jako další disk (virtuální disk) do souborových prohlížečů klientského operačního systému. | Povinný | Ano | Vyřešeno |
FPO_UP_06 | Povinná pole | Pokud existuje ve formuláři nějaké povinné pole, musí být uživateli tato skutečnost jasně prezentována. | Povinný | Ano | Vyřešeno |
FPO_UP_07 | Chybová hlášení | Chybová hlášení pro koncového uživatele musí být logická, srozumitelná a v českém jazyce. | Povinný | Ano | Vyřešeno |
FPO_UP_08 | Lokalizace | Systém (aplikace pro jednotlivá prostředí) musí být lokalizována minimálně do českého a anglického jazyka. | Povinný | Ano | Vyřešeno |
FPO_UP_09 | Nápověda | Systém musí zajišťovat on-line nápovědu. Tato on-line nápověda musí být koncipována kontextuálně a musí být minimálně v českém a anglickém jazyce dle uživatelské konfigurace. | Povinný | Ano | Částečně |
FPO_UP_10 | Nápovědá polí | Systém realizuje nápovědu k jednotlivým polím při jejich úvodní editaci (ve formě tipů), které se zobrazuje buď implicitně nebo po najetí kurzoru na dané pole. | Povinný | Ano | Vyřešeno |
FPO_UP_11 | Dokumentace | K systému musí existovat kompletní elektronická uživatelská dokumentace (příručka) popisující způsoby použití a vlastnosti minimálně v českém jazyce. | Povinný | Ano | Částečně |
Uživatelská správa | Systém musí umožnit uživateli, aby si v rámci uživatelského rozhraní a oprávnění nastavil agendy, složky, virtuální složky, dokumenty, které chce sledovat. Na základě tohoto nastavení se mu budou zobrazovat poslední dokumenty vložené nebo změněné (verze) dle příslušných objkektů. Uživateli musí být umožněno spravovat nastavení e-mailových notifikací. | Povinný | Ano | Vyřešeno | |
Notifikace (NT) | |||||
FPO_NT_01 | Automatická | Automatické odesílání emailových notifikací (s vazbou na dokument nebo objekt) na základě: - vložení dokumentu, - změny dokumentu (nová verze), - změna metadat (např. nastavení nebo změna stavu), - procesu - procesního kroku, | Povinný | Ano | Vyřešeno |
FPO_NT_02 | Ruční | Možnost ručního odeslání emailové notifikace s vazbou na dokument (objekt) pro jednoho nebo více uživatelů - skupině. Např. zaslání skupinové notifikace na všechny nové zaměstnance s odkazem na BOZP dokumentaci k povinnému seznámení. | Povinný | Ano | Bude vyvinuto |
FPO_NT_03 | Správa uživatelem | Systém umožňuje uživateli, aby si nastavil osobní pravidla odběru vybraných notifikací na určité operace (např. vytvoření, verze, smazání, procesní krok apod. ) a jejich kombinace. | Povinný | Ano | Částečně |
FPO_NT_04 | Konfigurace obsahu | Systém umožňuje oprávněnému uživateli/administrátorovi modifikovat předmět a obsah notifikace - např. notifikačního e-mailu. | Povinný | Ano | Vyřešeno |
Export dokumentů (ED) | |||||
FPO_ED_01 | Povolené formáty | Systém musí umožňit provést export dokumentů minimálně následujících, standardně dostupných, formátů: - MS Office (*.docx, *.xlsx, *.pptx), - Adobe Acrobat (*.pdf), - Text (*.txt, *.rtf, *.csv, *.xml) - Obraz ( *.jpg, *.tiff, *.bmp, *.gif, *.png) - Komprimované soubory (*.zip, *.rar apod.), | Povinný | Ano | Vyřešeno |
FPO_ED_02 | Automatický export | Systém musí umožnit administrátorovi nastavit termín (datum/čas), ve kterém se budou dokumenty (objekty) ECM/DMS exportovat a další úložiště, kam se budou dokumenty (objekty) ukládát. | Povinný | Ano | Částečně |
FPO_ED_03 | Opakovatelnost exportu | Systém musí umožnit vícenásobnou opakovatelnost exportu dokumentů (objektů). | Povinný | Ano | Vyřešeno |
FPO_ED_04 | Zachování integrity | Systém musí umožnit export dokumentů (objektů) v jedné posloupnosti operací tak, aby se: - všechny dokumenty (objekty) exportovaly jako integrální jednotka, - zachovaly všechny vazby mezi dokumenty a jejich metadaty, - zachovaly všechny vazby dokumenty (objekty), | Povinný | Ano | Vyřešeno |
FPO_ED_05 | Export za účelem archivace | Systém musí umožnit přesouvat jednotlivé vybrané verze dokumentů (včetně jejich metadat) za účelem archivace.. | Povinný | Ano | Vyřešeno |
FPO_ED_06 | Konfigurace exportu | Systém musí umožnit na základě definovaných kritérií (metadat) exportovat dokumenty. | Povinný | Ano | Vyřešeno |
POKYNY PRO VYPLNĚNÍ TABULKY - upozornění Zadavatele:
1) Zadavatel upozorňuje účastníky zadávacího řízení (dále jen "účastník") na důkladnou kontrolu při jejich zadávání jednotlivých údajů
2) Účastníci smějí vyplňovat pouze ŽLUTÁ POLE, kde:
- ve sloupci Je součástí vyplní ANO nebo NE;
- ve sloupci Plnění (vyberte hodnotu) vyplní VYŘEŠENO nebo ČÁSTEČNĚ nebo BUDE VYVINUTO.
Pozn.: účastníkem vyplněné údaje se pro něj stávají závaznými
3) Účastníci mají výslovně zakázáno upravovat položky a hodnoty či jinak zasahovat do tabulky mimo výše uvedeného.
4) Účastník je povinen vyplnit všechny uvedené položky (žlutá pole). Nevyplnění jakékoliv položky (žluté pole) bude vyhodnoceno jako nesplnění zadávacích podmínek. Taková nabídka pak bude vyřazena a zadavatel může účastníka vyloučit z další účasti v zadávacím řízení.
5) Všechny POVINNÉ položky (označeny ve sloupci Důležitost) jsou pro účastníka a plnění veřejné zakázky POVINNÉ
6) Účastník musí akceptovat požadavky zadavatele dle konkrétních specifikací uvedených u jednotlivých položek, náhradní řešení není povoleno.
7) Bližší podrobnosti jsou uvedeny v zadávací dokumentaci pro tuto veřejnou zakázku.
Evidenční číslo přidělené z Centrální evidence smluv: 180166
Příloha č. 3 – Ne-Funkční (technick0) požadavky
(následuje)
str. 51 | 53
Příloha č. 9: Ne-Funkční (technické) požadavky (NFP)
Enterprise Contenet Management System - systém pro správa a řízení elektronických dokumentů | |||||
Číslo | Název | Popis | Důležitost | Je součástí | Plnění (vyberte hodnotu) |
Základní | |||||
NFP_ZAK_01 | Typ aplikace | Systém musí být realizován jako webová aplikace přístupná z prostředí Microsoft Internet Explorer, Mozilla Firefox a Google Chrome. | Povinný | Ano | Vyřešeno |
Bezpečnost | |||||
NFP_BEZ_01 | Autentizace | K přihlášení uživatele do ECM/DMS je využita identita z přihlášení k desktopu pomocí jeho účtu v adresářové službě prostřednictvím protokolu LDAP. | Povinný | Ano | Vyřešeno |
NFP_BEZ_02 | Autorizace | Systém přebírá uživatele ze systému Micro Focus eDirectory, kde je zajištěna jejich aktualizace včetně jejich zařazení do organizační jednotky MŽP. | Povinný | Ano | Bude vyvinuto |
NFP_BEZ_03 | 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 dokumentům, složkám a dalším objektům ECM/DMS (např. metadatům) podle řady kritérií a jejich kombinací. Tato kritéria zahrnují: 1) roli uživatele v rámci ECM/DMS (např. Administrátor), roli uživatele v rámci konkrétního workflow (např. Příkazce) v ECM/DMS a roli uživatele z hlediska jeho zařazení v organizační struktuře MŽP (např. vedoucí oddělení); 2) oprávnění uživatele/skupiny uživatelů přistupovat k určitým složkám ve struktuře úložiště ECM/DMS (oprávnění se dědí z vyšších složek do nižších). | Povinný | Ano | Vyřešeno |
NFP_BEZ_04 | 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 Příloha č. 7 ZD - Věcné (manažerské) zadání, kapitola 10. Uživatelské role). | Povinný | Ano | Vyřešeno |
NFP_BEZ_05 | Omezení/přiřazení přístupových oprávnění uživatelům | Oprávněný uživatel/administrátor 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 jednotlivým objektům (dokumentům/metadatům/složkám) úložiště a operacím s nimi souvisejícími. | Povinný | Ano | Vyřešeno |
NFP_BEZ_06 | Jednoduché ad hoc řízení přístupových oprávnění k uloženému dokumentu/složce s nastavením expirace | Oprávněný uživatel/administrátor musí mít možnost přidělit dočasná přístupová oprávnění k objektům (dokumentům/metadatům/složkám) úložiště nebo jejich skupině (tj. hromadně), k nimž má přidělena oprávnění, jakož i k objektům (dokumentům/metadatům/složkám) ve svém osobním úložišti, napříč ministerstvem pro jednotlivce, skupinu či organizační strukturu bez ohledu na již systémem přidělená oprávnění. Při vytváření pod-objkektů (např. podsložek) budou defaultně přebírána oprávnění z rodičovské úrovně s možností jejich individuální úpravy. | Volitelný | Ano | Vyřešeno |
NFP_BEZ_07 | 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 NFP_BEZ_03). | Povinný | Ano | Vyřešeno |
NFP_BEZ_08 | 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í, 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. | Povinný | Ano | Vyřešeno |
NFP_BEZ_09 | 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ý dokument 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. | Volitelný | Ano | Bude vyvinuto |
NFP_BEZ_10 | Hosting/Outsourcing | Poptávané řešení ECM/DMS musí nabízet implementaci: - Cloud (SaaS), - On Premise, anebo - mix výše uvedeného, Implementace řešení ECM/DMS nesmí využívat žádné outsourcing a hosting služby mimo infrastrukturu MŽP. To ovšem neznamená, že by řešení takové služby nebylo schopné zabaupečit. | Povinný | Ano | Vyřešeno |
NFP_BEZ_11 | Zpracování informací mimo MŽP | Systém nesmí zpracovávat data, informace ani jejich části mimo systémové prostředí MŽP. | Povinný | Ano | Vyřešeno |
NFP_BEZ_12 | Penetrační testy | Systém neobsahuje žádné zranitelnosti obsažené v seznamech OWASP top 10 (2017, xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxx_00_0000- Top_10) a CWE/SANS top 25 most dangerous software errors (2011, xxxx://xxx.xxxxx.xxx/xxx00/). V rámci akceptačních testů musí být dodavatelem doloženo, že systém neobsahuje zranitelnosti dle uvedených seznamů. | Povinný | Ano | Vyřešeno |
NFP_BEZ_13 | 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é zabezpečení jako provozní prostředí. | Povinný | Ano | Vyřešeno |
NFP_BEZ_14 | 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. | Povinný | Ano | Vyřešeno |
NFP_BEZ_15 | 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 MŽP i mimo ni jsou chráněny kryptografickými technikami proti odposlechu (důvěrnost) a modifikaci (integrita), například použitím SSL/TLS protokolů. | Povinný | Ano | Vyřešeno |
NFP_BEZ_16 | Druhý stupeň autentizace | Systém podporuje druhý stupeň autentizace prostřednictvím CheckPoint Web Portal, který je využíván pro přístup k systému z prostředí internetu. | Povinný | Ano | Bude vyvinuto |
NFP_BEZ_17 | Ú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). | Volitelný | Ano | Vyřešeno |
NFP_BEZ_18 | 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í. | Volitelný | Ne | |
NFP_BEZ_19 | 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). | Povinný | Ano | Částečně |
NFP_BEZ_20 | 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. | Povinný | Ano | Vyřešeno |
Auditovatelnost systému | |||||
NFP_AUD_01 | Auditní log | Systém zaznamenává úspěšné i neúspěšné pokusy o přístupech do systému a k jeho objektům (dokumenty/složky/…). | Povinný | Ano | Vyřešeno |
NFP_AUD_02 | 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 objektem systému (např. dokument, složka, ...); 2) uživateli, který operaci/aktivitu realizuje, včetně činností administrátora; 3) datu/čas (na sekundy) události. | Povinný | Ano | Vyřešeno |
NFP_AUD_03 | Délka životnosti auditního logu | Systém musí udržovat auditní log minimálně po dobu 12 měsíců, popř. bez časového omezení. | Povinný | Ano | Částečně |
NFP_AUD_04 | Čitelnost auditního logu | Systém musí zajistit, aby údaje z auditního logu byly na požádání dostupné ve srozumitelné (člověku čitelné) formě pro kontrolu uživatelům (např. při testování a kontrole chování systému), kteří se systémem nejsou obeznámeni vůbec nebo jen málo. | Povinný | Ano | Vyřešeno |
NFP_AUD_05 | 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í objekt - dokument, složka, virtuální složka, metadata, která jsou povinně auditovaná a ta, u kterých oprávněný uživatel nastavil příznak pro auditování. | Povinný | Ano | Vyřešeno |
NFP_AUD_06 | 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. | Povinný | Ano | Vyřešeno |
NFP_AUD_07 | 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 k dokumentům/složkám, včetně generování reportů pro následný monitoring; 2) povolení přístupu k dokumentům/složkám, včetně toho, jaká akce byla provedena nad daným objektem; 3) zamítnutí přístupu k dokumentům/složkám, včetně toho, jaká akce byla zamítnuta nad daným objektem a z jakého důvodu; 4) nastavením, změnou nebo zrušením přítupů - ACL (Access Control List); 5) přihlášení a odhlášení uživatelů/administrátorů v 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. | Povinný | Ano | Částečně |
NFP_AUD_08 | 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. | Povinný | Ano | Částečně |
NFP_AUD_09 | Modifikace auditních logů | Záznamy a auditní logy jsou chráněny proti jakékoliv modifikaci a smazání. | Povinný | Ano | Vyřešeno |
Integrace a Migrace | |||||
NFP_INT_01 | Web services | Pro účely integrace systému ECM/DMS se systémy třetích stran musí systém pomocí web services (např. SOAP, REST) umožňovat provést alespoň následující operace: 1) vytvoření dokumentu/složky; 2) odstranění dokumentu/složky; 3) získání/nastavení/vložení hodnoty nebo vlastnosti objektu a provedení vlastní metody (akce) nad nejméně těmito objekty: dokument, složka (adresář), metadata, uživatel, přístupové oprávnění, filtr; 4) vyhledávání. | Povinný | Ano | Vyřešeno |
NFP_INT_02 | 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. | Povinný | Ano | Vyřešeno |
NFP_INT_03 | Integrace s Microsoft Office | Manipulace s dokumenty podporovaných formátů (otevření, editace a ukládání) je možná přímo z nástrojů MS Office (verze 2013 a vyšší). | Povinný | Ano | Vyřešeno |
NFP_INT_04 | Integrace se Spisovou službou | Systém musí obsahovat propojení s IS spisovou službou AthenA (dodavatel PilsCom, s.r.o.). Do systému ECM/DMS bude AthenA poskytovat buď celé dokumenty včetně atributů (zejména atribut číslo jednací dokumentu v Atheně, číslo spisu, popř. jedinečné UID, dokumentu v ESS AthenA), které budou dále zpracovávány v ECM/DMS, nebo bude umožňovat vložení dokumentu zpracovaného v ECM/ECM/DMS do příslušného spisu/podsložky spisu v ESS AthenA, dále přidělení čísla jednacího v Atheně a následné další zpracování podle příslušné metodiky práce v ESS AthenA. | Povinný | Ano | Bude vyvinuto |
NFP_INT_05 | Integrace IBM Domino/Notes | Integrace s IBM Domino/Notes na úrovni odesílání/příjmu notifikací s odkazy na dokumenty v systému. | Povinný | Ano | Bude vyvinuto |
NFP_INT_06 | LDAP | Integrace s Micro Focus eDirectory pro aktualizaci uživatelů, uživatelských skupin a organizační struktury MŽP. | Povinný | Ano | Bude vyvinuto |
NFP_INT_07 | Ú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ů. | Povinný | Ano | Vyřešeno |
NFP_INT_08 | Integrace s EIS JASU | Systém musí umožnit integraci s ekonomickým informačním systémem JASU (dodavatel MÚZO Praha, s.r.o.), pro přenos informací o platebním kalendáři v rámci smluvních závazků. | Povinný | Ano | Bude vyvinuto |
NFP_INT_09 | 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. | Povinný | Ano | Částečně |
NFP_INT_10 | Podpis dokumentu elektronickým certifikátem | Systém musí umožnit podepisovat elektronické dokumenty (např. *.PDF): - el. pečetí a časovým razítkem interními nástroji, - el. pečetí a časovým razítkem prostřednictvím integrace s nástroji a programy třetí strany. | Povinný | Ano | Bude vyvinuto |
NFP_INT_11 | Napojení na IS DD | V případě potřeby opatření dokumentu pečetí a/nebo časovým razítkem musí systém ECM/DMS využívat službu Informačního systému Digitální důvěry (TS-ELDAx, spol. Techniserv IT). | Povinný | Ano | Vyřešeno |
NFP_INT_12 | Migrace | Systém musí umožnit (za použití WS nebo jiné technologie/služby) jednorázově importovat data - realizovat jednorázovou migraci vybraných nebo všech dat ze stávající agendy - aplikace eSmlouvy, tzn. import metadat (primárně dle Evidenčního listu a Krycího listu) a soborů (el. dokumentů) s nimi souvisejících. | Povinný | Ano | Vyřešeno |
Technická omezení | |||||
NFP_TOM_01 | 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é jsou popsány v provozním řádu. | Povinný | Ano | Vyřešeno |
NFP_TOM_02 | Aktualizace klientských stanic | Pokud bude třeba aktualizovat, popř. konfigurovat, klientské stanice, musí aktualizace probíhat pouze s využitím vzdálených, automatických operací. | Povinný | Ano | Vyřešeno |
NFP_TOM_03 | 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). MŽP požaduje vzdálený přístup z mobilních zařízení včetně „chytrých“ mobilních telefonů k dokumentům a workflow v ECM/DMS, a to buď formou dedikované mobilní aplikace nebo skrze webový prohlížeč přes formuláře s podporou responsivního designu. Tento vzdálený mobilní přístup, musí umožnit alespoň: - přístup a zobrazení dokumentů uložených v ECM/DMS, - otevření dokumentů skrze URL odkaz uvedený v emailové zprávě na mobilním zařízení propojeném s úložištěm ECM/DMS, - provedení ne/schválení v rámci workflow, a - ve zjednodušené podobě navigaci a vyhledávání dokumentů v ECM/DMS, včetně nejnovějších dokumentů. V případě nezvolení varianty mobilní aplikace je proto nezbytné, aby ECM/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 dokumentu Návrh implementace. | Povinný | Ano | Vyřešeno |
NFP_TOM_04 | 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í) s objekty - dokument/složka/metadata v rámci jeho standardního uživatelského - desktop prostředí (aplikace/web prohlížeč). Toto prostředí mu umožní např.: - namapovat si uložiště ECM/DMS nebo jeho složky jako další disk / virtuální disk, - otevřít a editovat dokument, - kopírovat dokument apod. | Volitelný | Ano | Vyřešeno |
NFP_TOM_05 | Velikost dokumentů | Systém musí umožnit uložit dokumenty o velikosti přesahující 500 MB. | Povinný | Ano | Vyřešeno |
NFP_TOM_06 | Celkový objem dokumentů a počet/rok | Systém musí být schopen spravovat více než 500 tisíc dokumentů, kde každý dokument může mít minimálně 3 verze. Systém musí být připraven alespoň na roční přírůstek 10 tisíc dokumentů. | Povinný | Ano | Vyřešeno |
NFP_TOM_07 | Kódování dokumentů | Systém musí spravovat dokumenty bez ohledu na jejich strojové kódování (UTF8, WIN1250.,…). | Povinný | Ano | Vyřešeno |
NFP_TOM_08 | Virtualizace | Všechny části systému musí být možné nasadit a provozovat ve virtualizovaném prostředí. | Povinný | Ano | Vyřešeno |
NFP_TOM_09 | Systémové prostředí | Systém bude provozován na standardním systémovém prostředí MŽP. | Povinný | Ano | Vyřešeno |
Obnova systému | |||||
NFP_OBN_01 | 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. | Povinný | Ano | Vyřešeno |
Výkon | |||||
NFP_VYK_01 | Rychlost ukládání dokumentu (upload) | Systém musí umožnit uložení dokumentu o velikost 1 MB do úložiště IS nejpozději do 3 sekund ze všech pracovišť MŽP. 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. | Povinný | Ano | Vyřešeno |
NFP_VYK_02 | Rychlost stahování dokumentu (download) | Systém musí umožnit stažení dokumentu o velikost 1 MB z úložiště IS nejpozději do 3 sekund ze všech pracovišť MŽP. 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. | Povinný | Ano | Vyřešeno |
NFP_VYK_03 | 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šť MŽP. Měřeno vždy z pohledu uživatele. Výsledek je závislý na průchodnosti sítě objednatele. | Povinný | Ano | Vyřešeno |
NFP_VYK_04 | 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 dokumentů o celkové velikosti 100 GB. Čas je měřen na klientské stanici. Výsledek je závislý na průchodnosti sítě objednatele. | Povinný | Ano | Vyřešeno |
NFP_VYK_05 | Množství uchovávaných dat | Systém musí umožnit uchovat data o celkové velikosti alespoň 1 TB s možností dalšího rozšíření úložiště. | Povinný | Ano | Vyřešeno |
NFP_VYK_06 | 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 ECM/DMS. | Povinný | Ano | Vyřešeno |
Licenční politika | |||||
NFP_LIC_01 | Počet uživatelů | Celkový počet uživatelů ECM/DMS bude 700 a počet současně pracujících se předpokládá alespoň 150 uživatelů. | Povinný | Ano | Vyřešeno |
NFP_LIC_02 | Rozšiřitelnost počtu uživatelů | Systém musí být možné kontrolovaným způsobem rozšířit na 1 000 uživatelů (z toho nejvýše 200 současně pracujících) při pokračující efektivní dostupnosti služby. 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. | Povinný | Ano | Vyřešeno |
NFP_LIC_03 | Rozšiřitelnost počtu rolí | Systém musí mít zajištěny SW licence bez vlivu na změnu počtu rolí, například počtu administrátorů. | Povinný | Ano | Vyřešeno |
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. | Povinný | Ano | Vyřešeno | |
Školení | |||||
NFP_SKO_01 | Š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í ECM/DMS potřebnou k ověření testovacích scénářů. | Povinný | Ano | Vyřešeno |
NFP_SKO_02 | Školení administrace a konfigurace řešení ECM/DMS | Školení technických správců k administraci a konfiguraci dodaného řešení ECM/DMS (cca 2 zaměstnanci). | Povinný | Ano | Vyřešeno |
NFP_SKO_03 | Školení klíčových uživatelů | Školení klíčových uživatelů k detailní znalosti funkcionalit ECM/DMS - hlavních metodiků ECM/DMS (cca 16 zaměstnanců). | Povinný | Ano | Vyřešeno |
NFP_SKO_04 | Uživatelská příručka | Dodavatel dodá uživatelskou příručku s informacemi o DMS/ECM z pohledu uživatelské práce: - rozhraní, - použití, - vlastností (funkcí), nastavení atd. | Povinný | Ano | Vyřešeno |
Ochrana důvěrných informací | |||||
NFP_ODI_01 | 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. | Povinný | Ano | Vyřešeno |
NFP_ODI_02 | 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ěné heslem. | Volitelný | Ano | Vyřešeno |
NFP_ODI_03 | Ochrana osobních údajů | Systém bude obsahovat objekty - dokumenty obsahující osobní údaje. Systém ECM/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 Nařízení EU 2016/679 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů. | Povinný | Ano | Vyřešeno |
Ostatní | |||||
NFP_OST_01 | 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.). | Volitelný | Ne | |
NFP_OST_02 | Zajištění synchronizace času | Systém synchronizuje čas pomocí NTP. | Povinný | Ano | Vyřešeno |
NFP_OST_03 | Harmonogram | Zvládnout Implementaci ECM/DMS (Etapy I., II. a III.) do 39 týdnů od účinnosti smlouvy na implementaci ECM/DMS. | Volitelný | Ano | Bude vyvinuto |
POKYNY PRO VYPLNĚNÍ TABULKY - upozornění Zadavatele:
1) Zadavatel upozorňuje účastníky zadávacího řízení (dále jen "účastník") na důkladnou kontrolu při jejich zadávání jednotlivých údajů
2) Účastníci smějí vyplňovat pouze ŽLUTÁ POLE, kde:
- ve sloupci Je součástí vyplní ANO nebo NE;
- ve sloupci Plnění (vyberte hodnotu) vyplní VYŘEŠENO nebo ČÁSTEČNĚ nebo BUDE VYVINUTO.
Pozn.: účastníkem vyplněné údaje se pro něj stávají závaznými
3) Účastníci mají výslovně zakázáno upravovat položky a hodnoty či jinak zasahovat do tabulky mimo výše uvedeného.
4) Účastník je povinen vyplnit všechny uvedené položky (žlutá pole). Nevyplnění jakékoliv položky (žluté pole) bude vyhodnoceno jako nesplnění zadávacích podmínek. Taková nabídka pak bude vyřazena a zadavatel může účastníka vyloučit z další účasti v zadávacím řízení.
5) Všechny POVINNÉ položky (označeny ve sloupci Důležitost) jsou pro účastníka a plnění veřejné zakázky POVINNÉ
6) Účastník musí akceptovat požadavky zadavatele dle konkrétních specifikací uvedených u jednotlivých položek, náhradní řešení není povoleno.
7) Bližší podrobnosti jsou uvedeny v zadávací dokumentaci pro tuto veřejnou zakázku.
Evidenční číslo přidělené z Centrální evidence smluv: 180166
Příloha č. 4 – Nabídka Dodavatele
(následuje)
Příloha č. 4 – Nabídka Dodavatele
Základní představení řešení – produktu
Pro realizaci této veřejné zakázky nabízíme využití kvalitní a rozšířené ECM/DMS platformy Alfresco. Konkrétně předpokládáme pro realizace požadavků Zadavatele využití Alfresco v její Community edici
5.2.0. Afresco je celosvětově uznávaná platforma pro dokumentové, agendové a procesní systémy. Je široce využívána zejména v zdravotnictví, finančním průmyslu a veřejném sektoru. Mezi její největší přednosti se řadí:
• Otevřený zdrojový kód
• Nulové náklady na licence
• Lehká rozšiřitelnost
• Vysoká úroveň bezpečnosti
• Uživatelská přívětivost
Platforma je postavena na nejmodernějších webových technologiích a je kompatibilní se všemi moderními webovými prohlížeči v jejich posledních aktualizovaných verzích. Uživatelské rozhraní Alfresco je responsivní a nezávislé na provozovaném operačním systému.
Platforma Alfresco se skládá z několika klíčových komponent:
• Alfresco Content Services (ECM)
• Alfresco Process Services (BPM)
• Alfresco Governance Services (RM)
• Alfresco Application Development Framework (ADF)
Z technologického hlediska platforma využívá tyto základní technologie:
• Programovací jazyk Java
• Databáze PostgreSQL
• Vyhledávací index Solr/Lucene
• Procesní engine Activity
• Otevřené integrační rozhrání REST, CMIS a WebDAV
Detailní popis řešení – produktu
V následujících kapitolách jsou popsány Zadávací dokumentací požadované aspekty produktu, a to ve struktuře definované v bodě 5.1 Zadávací dokumentace. V případě, kde je to aplikovatelné, jsou
uvedeny odkazy na funkční nebo nefunkční požadavky ze Zadávací dokumentace formou uvedení jejich identifikačního čísla. U ostatních případů, zejména které nejsou triviálně textově popsatelné nebo budou předmětem vývoje, deklarujeme jejich splnění vyplněním odpovídající položky
v tabulkách funkčních a nefunkčních požadavků.
.1 Požadavky na infrastrukturu
Předpokládáme vytvoření dvou provozních prostředí v ICT infrastruktuře Zadavatele:
• Testovací
• Produkční
Konfigurace jednotlivých prostředí předpokládáme na úrovni:
• Testovací
o Aplikační server: 2 vCPU, 8 GB RAM, minimálně 50 GB úložiště typu HDD
o Databázový server: 2 vCPU, 8 GB RAM, minimálně 100 GB úložiště typu HDD
• Produkční
o Aplikační server: 2 vCPU na frekvenci minimálně 2.0GHz, 24 GB RAM, minimálně 100 GB úložiště typu SSD
o Databázový server: 4 vCPU na frekvenci minimálně 2.0GHz, 24 GB RAM, škálovatelné úložiště dle možností ICT infrastruktury Zadavatele připravené na předpokládaný cílový objem dokumentů
Na všech prostředích preferujeme operační systém Linux v distribuci CentOS v nejnovější podporované verzi.
V ostatních parametrech je řešení kompatibilní s ICT prostředím Xxxxxxxxxx definovaném v kap. 4.1 přílohy č. 7 Zadávací dokumentace: Věcné (manažerské) zadání.
.2 Uživatelská rozhraní – aplikace, podporovaná koncová zařízení
Uživatelské rozhraní ECM/DMS Alfresco je provozováno plně v prostředí webového prohlížeče. Přístupový portál se nazývá Alfresco Share a zde přikládáme oficiální matici kompatibility pro jednotlivé prohlížeče a major a minor verze ECM/DMS Alfresco 4.2.
Na následujícím náhledu je zobrazena domovská stránka portálu Alfresco, je složena z tzv. dashletů, co jsou interaktivní pluginy zobrazující specifická data nebo poskytují uživatelů konkrétní
funkcionality (FPO_UP_01). Tyto domovské stránky lze na administrační úrovni předdefinovat a následně mají jednotlivý uživatelé možnost si tyto stránky individuálně upravit, a to jak z pohledu složení pluginů, tak jejich uspořádání (FPO_UP_12).
Mezi tyto pluginy patří i zobrazení posledních použitých dokumentů (FPO_UP_02), přístup k oblíbený dokumentům (FPO_UP_03) ale například i zobrazení agendy kalendáře nebo svých úkolů. K Alfresco je standardně k dispozici i mobilní aplikace pro platformy Android i iOS. Webové rozhraní je také do značné míry responsivní.
.3 Správa dokumentů a metadat
Úložiště dodávaného DMS nemá omezení na strukturu vkládaných dat (FPO_SD_01). Obecně se však nedoporučuje, aby cesta včetně názvu serveru byla delší než 256 znaků → toto omezení není na straně Alfresco, ale na straně MS Office, který neumí zpracovat delší cestu. V rámci úložiště jsou podporovány dokumenty typu DOC, DOCX, XLS, XLSX, PPT, PPTX, PDF, PDF/A a dále všechny obrazové dokumenty. Náhled adresářové struktury zle shlédnout na následujícím obrázku, kde je zobrazena sekce Mé soubory (FPO_SD_16):
Jednotlivé složky lze libovolně vytvářet, zanořovat a pojmenovat (FPO_SD_01). Jednotlivé soubory lze nahrát výběrem z lokálního úložiště, nahráním pomocí tzv. drag&drop (i multivýběrem), vytvořením dokumentu ze šablony (viz následující obrázek), nahráním z mobilní aplikace nebo umístněním do sdíleného diskového prostoru systému. V případě umístnění do sdíleného diskového prostoru je
uživatel přesměrován na obrazovku systému pro vyplnění metadat. V případě, že nedojde k vyplnění
(alespoň) povinných metadat v požadovaném časovém limitu, dojde k automatickému smazání
dokumentu. (FPO_SD_02)
S dokumenty je možné provádět standardní operace jako smazání(FPO_SD_09),
kopírování(FPO_SD_07) a přesun(FPO_SD_08). Alfresco samostatně nemaže žádné dokumenty.
Pokud uživatel smaže dokument je tento dokument umístěn do „koše“ a uživatel si ho může obnovit (FPO_SD_10). Administrátor může všechny dokumenty z koše všech uživatelů odstranit. Lze i nastavit, že dokumenty budou z koše odstraňovány v nastaveném intervalu.
Dokumenty lze stahovat jednotlivě i hromadně. Taktéž je možné stáhnou celou složku, resp. její celý podstrom složek a souborů. Pro hromadné stažení je doporučena aktivace hromadného stahování pomocí zabalení souborů a složek do ZIP archivu. (FPO_SD_05)
Oprávněný uživatel může řídit přístupové oprávnění na jednotlivé složky a dokumenty. Jednotlivé oprávnění se v rámci hierarchie dědí. Tímto způsobem lze libovolně vytvářet sdílené
dokumenty/složky udělením přístupových oprávnění požadovaným uživatelům nebo skupinám uživatelů. (FPO_SD_15). Pro upřesnění uvádíme, že každý dokument nebo složka má svůj unikátní URL link, pomocí kterého můžou oprávněný uživatelé přistupovat. Granularita oprávnění splňuje parametry požadavku (FPO_SD_38 a FPO_SD_06)
Jednotlivé agendy navrhujeme řešit v rámci ECM/DMS pomocí mechanismu tzv. Sites. Jedná se o ucelené prostory pro kolaboraci uživatelů. Jednotlivé prostory mají svůj vlastní oddělený
dokumentový repositář, vlastní aplikace a portálové stránky. Jednotlivé Sites můžou mít různé úrovně přístupu (soukromé, veřejné, na žádost) a oprávněný uživatelé spravují přístupy. (FPO_SD_17).
Stránka detailu dokumentu se skládá z dvou hlavních částí:
• Obsah dokumentu, kde se v případě standardních dokumentů (textové, všechny dokumenty Microsoft Office, PDF, obrazové dokumenty) zobrazí náhled obsahu. V obsahu lze dynamicky hledat, přibližovat a stránkovat (FPO_SD_18)
• Pravý ovládací panel zobrazující zejména metadata, štítky, běžící workflow nad dokumentem a seznam verzí (FPO_SD_20, FPO_SD_23).
Z detail dokumentu je možné dokument přepnout do editačního režimu dvěma způsoby:
• Offline – dokument se fyzicky stáhne a uzamkne se pro editaci ostatních uživatelů. Uživatel edituje dokument mimo systém a po ukončení práce ručně nahraje novou verzi (FPO_SD_21)
• Online (FPO_SD_19) – dokument se automaticky otevře v odpovídajícím programu Microsoft Office a uzamkne se pro editaci ostatních uživatelů. Uživatel může průběžně ukládat dokument a aktualizovat tím jeho obsah v Alfresco. Po ukončení práce se automaticky nahraje nová verze dokumentu. (FPO_SD_21)
Standardně jsou verze udržovány ve formátu X.Y, kde X je major verze dokumentu a Y je minor verze dokumentu. Standardně se povyšuje během editace jen minor verze dokumentu. Povýšení na major verzi doporučujeme vykonávat explicitním uživatelským zásahem (ale lze technicky taktéž
automatizovat). Formát major a minor verzování je konfigurovatelný, standardně jde o číselné označení, které je doplněno o název souboru. (FPO_SD_22). V seznamu verzí v pravém panelu detailu dokumentu má oprávněný uživatel možnost stáhnout libovolnou historickou verzi nebo ji obnovit na aktuální. (FPO_SD_24)
Obrazovka detailu dokumentu obsahuje možnost tisku dokumentu, a to jak samostatně, tak i
s přiřazenými metadaty. (FPO_SD_35)
V pravém ovládacím panelu se taktéž nachází oblast pro sdílení dokumentu. To je standardně řešeno publikování dokumentu na specifickém URL linku, který lze zkopírovat a sdílen s jinými uživateli.
Přístupem na link se po dobu prohlížení automaticky danému uživateli přidělí potřebná přístupová práva. (FPO_SD_11) Sdílení lze dále omezit jen na přihlášené uživatele. Odkaz vede vždy na detail dokumentu, kde je zobrazena aktuální verze (FPO_SD_12). V specifických případech lze linkovat i na konkrétní verze dokumentu.
Oblast pro metadata v pravém ovládacím panelu je strukturována ve formě přehledné tabulky atribut-hodnota. Metadata je možné evidovat pro libovolné entity v sytému, tedy jak pro dokumenty, tak i složky. (FPO_SD_25) Entity a jejich metadatový model je v Alfresco definován v rámci
komplexního tzv. Content Metamodelu. Metamodel podporuje všechny požadované typy metadat definované v FPO_SD_26 a FPO_SD_27. Vazba mezi dokumenty je realizována specifickým
metadatovým typem Entita, kde je takto možné realizovat vazbu na libovolnou entitu (jiný
dokument, nebo složku) a to v kardinalitě 1:N (FPO_SD_13). Alfresco standardně vynucuje kontrolu hodnot metadat dle jejich typu při jejich zadávání. (FPO_SD_28). Metamodel umí na základě specifických rozšíření řídit přístupová oprávnění na úroveň metadata, nebo i jejich logických skupin (tzv. Aspektů). (FPO_SD_34)
Další součástí ovládacího panelu je oblast systémových informací (nebo-li metadat), které odpovídají požadavku FPO_SD_29.
Jak již bylo řečeno výše, je možné vytvářet dokumenty na základě šablon. Šablona je v tomto případě komplexnější pojem a zahrnuje jak samotný obsah dokumentu, tak jeho sadu metadat. (FPO_SD_30) Může ale obsahovat například i přednastavení oprávnění a podobně. Vytvořit šablonu může libovolný oprávněný uživatel z předlohy ve formě dokumentu nebo šablony. (FPO_SD_31, FPO_SD_32)
.4 Formuláře
ECM/DMS Alfresco má nativní podporu pro formuláře v uživatelském rozhraní, přikládáme zde náhled ukázkového formuláře:
Povinné položky jsou dle legendy na začátku formuláře označeny hvězdičkou(*) (FPO_UP_06).
V rámci rozvoje platformy je možné technicky realizovat i napojení na komplexní formulářové servery a obdobné řešení. U jednotlivých formulářových polí se nachází i kontextová nápověda, která se
zobrazí po kliknutí na ikonu „otazníčku“ u daného atributu (FPO_UP_09). Dodatečnou nápovědu je možné zobrazovat i formou tipů, jak je možné shlédnout u datumových polí kde je touto formou uveden povinný formát vyplnění (FPO_UP_10). Chybové hlášení jsou prezentována uživatelsky
přívětivou formou spolu se zobrazením chybového hlášení (FPO_UP_07):
.5 Tvorba a správa procesů – dokumentového workflow
Oblast workflow je v ECM/DMS Alfresco řešena pomocí technologie Activiti. Jedná se o BPMN2.0 validní platformu pro implementaci a exekuci procesů. Standard BPMN2.0 neklade limity na počet kroků nebo komplexnost procesů, čímž je zajištěno splnění požadavků FPO_SP_01, FPO_SP_02 a FPO_SP_03. Proškolení uživatelé se znalostí tohoto standardu jsou schopny implementovat a odpovídající míre konfigurovat procesy. Předpisy workflow se teda tvoří v libovolném BPMN2.0 validním modeleru a implementují se do Alfresco. Nad workflow je následně upraven
Contentmetamodel a jednotlivé obrazovky procesu (formuláře). Jednotlivé workflow je následně možné spouštět nad libovolným množstvím dokumentů nebo i bez dokumentu. Workflow je následně možné skládat a řetězit do větších celků, jak je zobrazeno na následujících náhledech obrazovek:
Uživatelé můžou spouštět workflow z hlavního aplikačního menu Alfresco nebo můžou iniciovat zahájení workflow přímo z dokumentu, nad kterým ho požadují provést. Workflow je samozřejmě možné i automatizovat, například navázáním na nějakou časovou události (např. půlnoc) nebo systémovou/uživatelskou akci (např. vytvoření dokumentu v definované složce) (FPO_SP_04, FPO_SP_05). V případě, že dané workflow přidělí úkol uživateli s dokumentem, na který uživatel standardně nemá oprávnění, tak mu bude po dobu vyřízení úkolu přiděleno potřebné adhoc
oprávnění. (FPO_SP_08) Samozřejmostí je zasílání mailových notifikací uživatelům obsahující přístupové linky k úkolům a dokumentům (FPO_SP_07). Připomínkování dokumentů lze řešit
integrovanými diskusemi přímo na detailu dokumentu nebo formou zvláštního dokumentu (šablona
„připomínky“), který se propojí na připomínkovaný dokument (FPO_SP_10). Procesní platforma na vnitřní úrovni automaticky kontroluje zastupitelnost pracovníků. V případě, že je danému uživateli nastavena administrátorem nedostupnost, jsou jednotlivé na něj směřované úkoly automaticky
přesměrované na jeho zástup. (FPO_SP_12)
.6 Vyhledávání
Podkladovou technologií ECM/DMS Alfresco zajišťující komplexní služby vyhledávání a indexování je Solr ve své verzi 4., který podporuje fulltextové vyhledávání v dokumentech, metadatech, složkách, obsahu a ostatních systémových entitách (FPO_VH_01). Pro uživatele je k dispozici je tzv. quick search, nebo-li rychlé vyhledávání, které je dostupné přímo v horní aplikační liště uživatelského
rozhraní. Zde může uživatel zadat rychlý vyhledávací dotaz a Alfresco obratem kontextuálne
zobrazuje výsledy (viz náhled níže), případně se uživatel může přepnout na plný výsledek vyhledávání (viz náhledy níže). K dispozici je taktéž komplexní vyhledávání dle kritérií(FPO_VH_02) v kombinaci
s fulltextem(FPO_VH_05), které jsou administrátorský konfigurovatelné, mezi tyto kritéria patří i omezení na složky nebo oblasti platformy (FPO_VH_06).
Vyhledávací technologie podporuje běžné vyhledávací operátory(FPO_VH_03) pro tvorbu
komplexních dotazovacích výrazů. Po jejich zadání se zobrazí výsledky vyhledávání a následně může uživatel dotaz upřesnit/upravit a vyhledávání jednoduše opakovat (FPO_VH_04). Ve výsledcích vyhledávání se zobrazují přímo náhledy dokumentů a taktéž výňatek obsahu dokumentu
s vyznačením textu kde systém našel shodu(FPO_VH_12). Aplikační lišta nad výsledky vyhledávání umožňuje provádět hromadné akce nad výsledky (FPO_VH_11). Po kliku na výsledek vyhledávání se otevře jeho detail v samostatném okně (FPO_VH_13). Jednotlivé funkce je možné shlédnout na následujícím náhledu:
V pravé horní části aplikační lišty se nachází konfigurační kolečko, s kterým si uživatel může částečně přizpůsobit zobrazení výsledků. Nad rámec tohoto požadavku se v levé částí výsledků nachází tzv. facety, tzn. společné atributy vyhledaných záznamů i s uvedením počtu záznamů, které sdílejí tuto vlastnosti. Uživateli se po kliknutí na danou vlastnost(facet) upraví odpovídajícím způsobem
vyhledávání a zobrazí se dané soubory. Jednotlivé funkce je možné shlédnout na následujícím náhledu:
Stránkování je v ECM/DMS Alfesco řešeno moderním dynamickým způsobem, kdy se další stránky automaticky načítají při skrolování stránky směrem dolů.
.7 Podpora el. podepisování (by eIDAS);
Procesní platforma i uživatelského rozhraní ECM/DMS Alfresco je v budoucnu v rámci rozvoje
připravena pro integraci elektronického podepisování dle nařízení eIDAS. Zpravidla je aplikováno na individuální podepsání daného dokumentu nebo výzvě k podepsání v rámci workflow.
.8 Podpora skenování, vytěžování
Podpora pro skenování je zpravidla formou nakonfigurované sdílené složky, do které se (ručně nebo automaticky) umísťují naskenované dokumenty. Následně je nakonfigurované workflow, které dokumenty v pravidelných intervalech zpracuje, vykoná potřebné procesní úkony a umístí nové
dokumenty na potřebné místo v repositáři. V rámci toho zpracovacího workflow je následně možné začlenit i integraci na software zabezpečující vytěžování strojově čitelných dat.
.9 Integrace
ECM/DMS Alfresco obsahuje kompletně zdokumentované a otevřené integrační rozhraní na bázi
technologie REST. Pro integraci na úrovni dokumentů lze použít i standardní rozhrání dle protokolů
CMIS/WebDAV.
.10 Migrace
Migrace je zpravidla provedena implementací sady migračních skriptů, které komunikuje
s integračním rozhraním třetí strany a REST rozhraní platformy Alfresco. V případě, že není dostupné integrační rozhraní třetí strany je možné migraci provést nad exportními soubory obsahující potřebná data a metadata, která budou vygenerována aplikací třetí strany. Detailní návrh migrace očekává Objednatel zpracovaný od Dodavatele v rámci předimplementační analýzy, tedy v dokumentu Návrh implementace.
.11 Lokalizace
Jednotlivé textace platformy Alfresco jsou koncentrovány do lokalizačních souborů, v rámci kterých jsou definovány jednotlivé jazykové lokalizace. Alfresco je lokalizováno do řady světových jazyků mezi kterými je i angličtina. Česká jazyková lokalizace bude dodána v rámci plnění této veřejné zakázky.
.12 Zálohování a archivace
Zálohování je možné řešit na úrovni dokumentů, vybraných entit, skupin metadat nebo celého virtuálního stroje. Nejběžnějším je právě využití zálohovacích mechanismů na úrovni virtuálních
strojů (které jsou zpravidla odděleny minimálně na aplikační a databázové), co bude předpokládáme aplikováno i v prostředí Zadavatele využitím technologie „Veeam Availability Suite Enterprise Plus for VMware“. Archivaci lze v Alfresco řešit na několika úrovních, zřejmě nejkomplexnějším je integrace na elektronickou spisovou službu, která proces archivace dokumentů dále zabezpečuje.
Předpokládáme, že toto bude aplikováno i v prostředí Zadavatele, jelikož v popisu ESS AthenA se píše
„zajišťuje také archivaci spisů v souladu se zákonem č. 499/2004 Sb., o archivnictví a spisové službě“.
Mimo integraci na ESS lze archivaci v Alfresco zabezpečit i opatřením dokumentů metadaty archivačních lhůt a skartačních znaků a implementováním standardních mechanismů, které dle
těchto řídících mechanismů archivují dané dokumenty na externí úložiště dle požadavků Zadavatele, případně ručním zadáním pokynu k archivaci/skartaci (FPO_SD_40).
.13 Logování, reporting – statistiky
Platforma Alfresco obsahuje široké možností konfigurace logování. Ve většině implementací je
pravidlem, že jsou tyto logy strojově zpracovávány monitorovacími systémy třetích stran.
Předpokládáme, že toto bude aplikováno i v případě Zadavatele, kdy budou logy Alfresco připraveny pro zpracování SIEM systémem SIEM QRadar. V oblasti monitoringu poskytuje Alfresco také několik možností. Jednou je například monitorování pomocí JMX technologie. V případě Zadavatele ale uvažujeme dle podmínek Zadávací dokumentace integraci na monitorovací nástroj Zabbix. Komplexní statistiky lze z Alfresco získat pomocí auditovacích mechanismů, která je součástí platformy.
Konkrétní nastavení statistik je vždy otázkou konkrétních požadavků a samozřejmě i architektury, jelikož při masivních objemech dat můžou mít výpočty statistik nemalý výkonností dopad.
.14 Bezpečnost, zabezpečení, šifrování.
Alfresco je možné standardně provozovat v rámci šifrované komunikace pomocí HTTPS/SSL (NFP_BEZ_15). Samozřejmostí je šifrování hesel (v případě, že jsou ukládána v systému) nebo
integrace na externí autentizační mechanismy. V rámci rozvoje je možné aktivovat i automatické šifrování obsahu (nebo jeho částí). Aktuálně Alfresco neobsahuje žádné zranitelnosti z OWASP TOP 10 (NFP_BEZ_12).
Popis (ne)standardní implementace
Hlavní oblasti standardní implementace jsou:
• Konfigurace Content Metamodel -> definice jednotlivých entit a jejich metadat
• Konfigurace oprávnění -> definice/integrace bezpečnostních skupin, uživatelů a rolí
• Konfigurace procesů -> definice jednotlivých procesních diagramů, jejich deployment a následné customizace v integračních bodech
• Konfigurace formulářů -> definice jednotlivých atributů, omezujících kritérií a jejich navázání na potřebné kroky procesu
• Konfigurace uživatelského rozhraní -> definice vizuálních stylů, dashletů a uživatelských
obrazovek
• Konfigurace Sites -> definice jednotlivých oblastí(agend), přístupových oprávnění, dostupných aplikací a dalších pravidel
Ostatní úpravy nad rámec těchto oblastí jsou zpravidla označovány jako nestandardní implementace, tyto jsou ale řádně zdokumentované a v maximální možné míre implementovány tak, aby je bylo možné migrovat na nové verze platformy Alfresco. Tyto oblasti jsou zpravidla označeny v tabulkách funkčních a nefunkčních požadavků jako „Bude vyvinuto“, patří mezi ně zejména:
• Integrace
• Migrační práce
• Agendově specifické funkcionality
• Ostatní speciální funkce na míru Zadavateli
Licencování, maintenance a ceny
Pozn. Xxxxx: toto je kapitola kde bude hlavne tabulka ceny, z pohledu licencování zde třeba napsat ze jde o „open source licenci LGPLv3“ , je nevýhradní a časově místně a počtem uživatelů neomezená. Licence databázové technologie PostgreSQL je specifická, uvádíme zde její odkaz xxxx://xxx.xxxxxxxxxx.xxx/xxxxxxxx/xxxxxxxxxx, jde o liberální open source licenci obdobnou BSD nebo MIT licenci, je nevýhradní a časově místně a počtem uživatelů neomezená.
Popis provozu, správy – administrace a rozvoje řešení – produktu
Platforma Alfresco je jednoduše rozšiřitelná a modifikovatelná. Hlavní roli v této oblasti hraje fakt, že celý zdrojový kód platformy je otevřený a připravený k úpravám. Zároveň platí, že je v České
republice i zahraničí rada subjektů, které jsou schopny kompletně převzít správu a rozvoj řešení, nebo do něj částečně vstupovat a rozšiřovat funkcionality.
Velkou většinu administračních úkonů je možné realizovat v rámci tzv. administrační konzoly. Jde o součást uživatelského rozhrání Xxxxxxxx, která je přirozeně dostupná jen pro administrátory. Přes
konzolu jde pomocí komplexně zdokumentovaných skriptů a příkazů ovládát většinu oblastí Alfresco. Pro úplnost zde uvádíme odkaz na dokumentaci administrační konzole přímo od výrobce xxxxx://xxxx.xxxxxxxx.xxx/0.0/xxxxxxxx/xx-xxxxxxxxxxxx.xxxx.
Evidenční číslo přidělené z Centrální evidence smluv: 180166
Příloha č. 5 – Akceptační protokol
Můžete využít následující příklad nebo i vlastní protokol, pokud bude splňovat definici příkladu.
Objednatel: Česká republika – Ministerstvo životního prostředí Vršovická 1442/65, 100 10 Praha 10 | Poskytovatel: TECHNISERV IT, spol. s r. o. Traťová 574/1, 619 00 Brno | ||
Smlouva číslo: (číslo centrální evidence smluv) | 180166 | ||
Projekt / Objednávka číslo: | [●] | ||
Název projektu / objednávky: | [●] | ||
Akceptační protokol | |||
Popis činností: (Poskytovatel) | [●] | ||
[●] | |||
[●] | |||
[●] | |||
[●] | |||
Připomínky – výhrady: (Objednatele) | [●] | ||
[●] | |||
[●] | |||
[●] | |||
[●] | |||
Objednatel svým podpisem protokolu prohlašuje, že objednané služby byly Poskytovatelem realizovány a jsou Objednatelem akceptovány: ☐ BEZ VÝHRAD ☐ S VÝHRADOU ☐ NEAKCEPTOVÁNY | |||
Za Objednatele | Za Poskytovatele | ||
Jméno: | [●] | Jméno: | [●] |
Datum: | [●] | Datum: | [●] |
Podpis: | [●] | Podpis: | [●] |