Podrobná´ specifikáce Dí´lá á specifikáce vybrány´ch Provozní´ch sluzˇeb
Podrobná´ specifikáce Dí´lá á specifikáce vybrány´ch Provozní´ch sluzˇeb
1. Společné definice a zkratky
Pojmy uvedené v ZD nebo Smlouvě počínající velkým písmenem mají dále vymezený význam (pojmy s počátečními velkými písmeny, které zde nejsou definovány, jsou definovány právě Smlouvou či ZD):
Akceptace Díla – celkové/finální ověření shody Díla oproti všem požadavkům Smlouvy a potvrzení
souladu s těmito požadavky (bezvýhradné splnění všech Fází /0-4/ Zhotovení Díla).
EAP (EAP platforma) – Environmentální analytická platforma, platforma pro ukládání, katalogizaci a zpřístupnění datových sad poskytovaných rezortními a dalšími organizacemi. Datové sady jsou opatřeny metadatovými popisy včetně údajů o původci a časové platnosti. EAP je výstupem samostatného podprojektu STaR a bude nejvýznamnějším zdrojem dat pro BI platformu.
EEA – Evropská agentura pro životní prostředí.
EU – Evropská Unie.
Síťová infrastruktura - standardizované síťové produkty/prvky, prostřednictvím nichž je BI platforma provozována a jež jsou ve vlastnictví MŽP jako správce či MŽP je zajistí jiným způsobem (např. cloudové služby). Síťová infrastruktura je součástí Technologické platformy.
Incident – událost, která není součástí standardní operace a která působí nebo může způsobit výpadek služeb nebo snížení kvality poskytování Provozních služeb. Je to stav Díla či jeho komponent, který neumožňuje provádět předepsané funkce, či nejsou splněny parametry stanovené v Dokumentaci. V daném kontextu nezahrnuje události. Týká se Etapy 2.
ISPOP - Integrovaný systém plnění ohlašovacích povinnosti v oblasti životního prostředí.
Průměrný počet pracovních dnů v roce (dle plánovacího kalendáře) – 251 pracovních dnů.
KL – katalogový list, viz tabelární přehledy služeb B1 až BI_10 v kap. 3.2 až 3.4 tohoto dokumentu.
KÚ - Krajský úřad.
Měřící období – interval od času 0:00:00 hod. 1. dne daného kalendářního měsíce do 23:59:59 hod. posledního dne daného kalendářního měsíce včetně, a to pro každý kalendářní měsíc v daném kalendářním roce.
Objednatel - Objednatel BI platformy (tj. Díla), kterým je Ministerstvo životního prostředí.
Obnovení Provozní služby (fix time) – je časová lhůta, ve které je Dodavatel povinen obnovit parametry dané Provozní služby na sjednanou úroveň (zpravidla obnovení řádného bezporuchového fungování BI platformy a dostupnosti funkcionalit uživatelům) s tím, že doba obnovení parametrů dané Provozní služby je počítána od vzniku/zadání původního požadavku Objednatelem bez ohledu na změnu klasifikace priority požadavku. Tato časová lhůta se počítá v návaznosti na příslušný kalendář uvedený u konkrétní Provozní služby dále.
Lhůta pro odpověď (response time) – je časová lhůta, ve které je Xxxxxxxxx povinen odpovědět na požadavek Objednatele, a to buď odmítnutím, nebo přijetím požadavku. Tato časová lhůta se počítá v návaznosti na příslušný kalendář uvedený u konkrétní Provozní služby dále.
Pracovní den, business day („BD“) – každý den mimo sobot, nedělí a státních svátků a ostatních svátků v České republice dle zákona č. 245/2000 Sb., o státních svátcích, o významných dnech a o dnech pracovního klidu, ve znění pozdějších předpisů.
Provozní deník – on-line, přes URL přístupný, strukturovaný a průběžně naplňovaný přehled (tabelární přehled nebo dynamický prohledávatelný report) vedený Dodavatelem a obsahující zejména informace o úkonech na serverových komponentech (instalace, odstávky, rekonfigurace apod.). Provozní deník může být součástí nebo službou Service desku.
Dodavatel je povinen do Provozního deníku prostřednictvím záznamu zaznamenat minimálně následující úkony a události:
• Provedení (instalace/implementace) Update/Upgrade/nové verze SW částí Díla včetně
komponent SW platformy;
• Instalace patche, hotfixu, servispacku, apod.;
• Havarijní stavy, opravy, výměny komponent;
• Anomálie a nestandardní stavy systémů, které mají dopad na plnění SLA;
• Zprovoznění nového nebo dočasně odstaveného výstupu BI platformy a/nebo odstavení BI platformy;
• Spuštění, vypnutí a restart komponent BI platformy;
• Reinstalace/migrace/přesun BI platformy anebo jejích komponent;
• Obnovení ze zálohy.
• Bezpečnostní incidenty
Záznam do Provozního deníku musí být Dodavatelem proveden nejpozději do konce následujícího BD (23:59) po provedení příslušného úkonu.
Každý záznam bude obsahovat minimálně následující informace:
• Datum a čas pořízení záznamu;
• Identifikace kontaktní osoby Dodavatele pořizující záznam;
• Identifikace dotčené/ých aplikací/modulů/databází/komponenty SW BI platformy;
• V případě událostí trvajících více než 1 hodinu také čas začátku a konce události (např. doba
servisního okna) – minimálně s přesností na 0,5 hodiny;
• Stručný-heslovitý popis události/komentář;
• Základní kategorizaci úkonů vycházející z popisu výše;
• Časové určení (min. s přesností na hodiny), kdy událost (úkon/aktivita) byla realizována.
U činností prováděných na žádost Objednatele nebo vyplývajících z této Smlouvy zdůvodnění,
na základě jakého požadavku byla činnost vykonána (např. ID záznamu v Servisdesku a příslušný KL).
2. Východiska veřejné zakázky
2.1. Vymezení pojmu BUSINESS INTELLIGENCE
Pojmem Business Intelligence platforma (dále „BI platforma“ nebo „řešení“) se pro účely tohoto zadávacího řízení rozumí integrované prostředí tvořené sadou SW komponent, nástrojů a služeb, které slouží pro analytické a reportovací účely. Umožňuje ucelenou a efektivní práci s daty z transakčních (agendových) informačních systémů či datových souborů získávanými buď prostřednictvím EAP platformy nebo přímo prostřednictvím dohodnutého rozhraní (API, databázový konektor). Řešení bude sloužit, jak pro nezbytnou transformaci a konsolidaci různorodých dat, tak pro jejich uchování, automatizovanou aktualizaci, zpracovávání statistických výstupů, publikaci ukazatelů tj. zejména indikátorů životního prostředí. Předpokládá se také budoucí využití BI platformy pro předpovědi či simulace vývoje (tj. prediktivní analýzy) a konsolidaci rezortních reportingových povinností, přičemž BI platforma musí tyto funkce již v okamžiku dodávky obsahovat nebo musí být o tyto funkce rozšiřitelná, aniž by docházelo ke zmaření předchozích investic.
2.2. Stávající informační podpora pro statistiku a reporting MŽP
Ministerstvo životního prostředí je ústředním orgánem státní správy v oblasti životního prostředí. Jeho činnost se řídí právními předpisy a mezinárodními úmluvami a dalšími systematickými i ad hoc potřebami.
Tyto vykonávané činnosti (procesy) zpravidla data konzumují i produkují. Správní procesy jsou závislé na datech odborné podpory státní správy, tedy na meziprocesní komunikaci, a samy jsou zdrojem dalších datových produktů. Reportingové procesy obdobným způsobem předávají výstupy národních procesů návazným procesům na úrovni Evropských a mezinárodních institucí.
Zásadním elementem celého systému je důkazní břemeno. Jak při vnitrostátní, tak při mezinárodní meziprocesní komunikaci dochází k předání závazného dokumentu (stanovisko, reporting), jenž může být daty doprovozeno.
Speciálním případem je reporting vůči veřejnosti podle zákona č. 123/1998 Sb., o právu na informace o životním prostředí, ve znění pozdějších předpisů. Zpráva o životním prostředí se svou publikací stává oficiálním autorizovaným (a tudíž z právního hlediska závazným a vymahatelným) zdrojem informací.
Právní závaznost publikovaných statistických agregátů rezortu MŽP se řídí statistickým zákonem, a to bez ohledu na to, zda daná datová sada je či není statistickým zákonem přímo řízena či se jedná o rezortní statistické zjišťování a monitoring.
Zejména následující dvě Evropské směrnice mají průřezový dopad na nakládání s rezortními daty:
- SMĚRNICE EVROPSKÉHO PARLAMENTU A RADY 2007/2/ES ze dne 14. března 2007 o zřízení Infrastruktury pro prostorové informace v Evropském společenství (INSPIRE) přímo ošetřuje veškerá prostorová data rezortu, vyžaduje jejich publikaci, publikaci mapových služeb i příslušných metadat;
- SMĚRNICE EVROPSKÉHO PARLAMENTU A RADY 2003/98/ES ze dne 17. listopadu 2003
o opakovaném použití informací veřejného sektoru ukládá publikaci rezortních dat pomocí otevřených standardů.
V současnosti disponuje rezort životního prostředí zhruba padesáti významnými informačními systémy, které produkují více než 1500 datových sad. Většina těchto dat vzniká v monitorovacích sítích rezortu, terénním sběrem dat, statistickým zjišťováním, měřením a modelováním a jako výstupy dílčích správních procesů.
Tyto datové sady většinou nemají neměnné struktury. Metodika pro jejich tvorbu se v čase neustále mění v závislosti na mezinárodní i národní legislativě.
Na úrovni mezinárodního reportingu valná většina dat povinně předávaných v rámci předpisů EU je poskytována přímo Evropské agentuře pro životní prostředí (dále jen „EEA“). EEA vybudovala reportingovou síť EIONET/ReportNet s řadou významných technických nástrojů pro organizaci a předávání dat z členských zemí. Zde dominantní roli hraje Reporting Obligation Database (ROD) evidující veškeré mezinárodní reportingové povinnosti všech členských zemí. Na ROD navazuje systém Content Registry fungující jako knihovna archivující a zpřístupňující veškerá data a doprovodné dokumenty poskytnuté členskými zeměmi za celou dobu existence EEA. Pro každý reportingový proces existují přesné popisy postupů, standardů a šablon, jak mají vypadat a být předána příslušná data.
Nad těmito daty vytváří EEA „bezešvé“ celoevropské databáze, jejich agregace, generalizace a mezidoménová srovnání, jež jsou základem pro tvorbu indikátorů stavu a dynamiky životního prostředí v Evropě a tvorbu jednotlivých zpráv.
MŽP disponuje od roku 2006 systémem ISSaR vybudovaném na obdobném principu. Cílem systému je evidovat veškeré povinnosti MŽP pro tvorbu právně závazných statistických výstupů včetně reportingu, monitorovat průběh naplňování Státní politiky životního prostředí a podporovat tvorbu závazných publikací. Pro tuto potřebu ISSaR obsahuje více než 150 statistických agregátů z rezortních i mimorezortních databází i jednotlivé indikátory stavu a dynamiky životního prostředí. Systém byl vybudován, rozvíjen a udržován pracovníky CENIA a v průběhu let byla jeho architektura postavena tak, aby co nejvíce vyhovovala splnění povinností digitalizace datových vstupů předávaných rezortními organizacemi ve formě excelových tabulek a potřebám tvorby přehledových výstupů, které jsou publikovány na webu ISSaR (xxxxx://xxxxx.xxxxx.xx).
MŽP je podle kompetenčního zákona povinno sbírat informace o stavu životního prostředí a naplňování politik v životním prostředí včetně financování, a podávat o tomto zprávy vládě, EU a veřejnosti. Typově lze hovořit o následujících kategoriích:
1. Zpráva o životním prostředí, zpráva o vodě, statistické ročenky a podobné – souhrnné shrnutí stavu životního prostředí obecně či doménově založené na statistických agregátech, indikátorech a slovním hodnocení. Vstupem jsou agregovaná data, která v současné době zasílají na MŽP/CENII již v agregované podobě věcně příslušné odbory MŽP či rezortní organizace MŽP a další externí subjekty (nejčastěji ve formě excelových tabulek emailem)1. A také tyto organizace za správnost/validnost poskytnutých dat ručí. Konečnou formou Zpráv o životním prostředí je PDF dokument.
2. Publikování dat – jednotlivé informační systémy disponují svým rozhraním umožňujícím dálkový přístup, ať ve formě surových či agregovaných dat, map a grafů.
3. Plnění reportingových povinnosti vůči EU, což je zastřešováno Evropskou agenturou pro životní prostředí (EEA). Požadovaná agregovaná data jsou předávána prostřednictvím sítě EIONET/ReportNet a ukládána do systému „Content Registry“. Musí se jednat o data zaručená, zkontrolovaná a potvrzená odpovědnými subjekty (původci dat), opatřená metadaty včetně data vzniku a platnosti údajů. V cca 25 % se jedná o data ve strojově čitelných formátech (.XML v definované struktuře, případně .CSV), v ostatních případech se jedná o textové dokumenty s definovanou šablonou.
4. Poskytování dat ve formátu Open Dat. Tato data jsou určena pro širokou veřejnost k jakémukoliv použití. Je třeba připravovat datové sady v některém z formátů Open Dat opatřená metadaty a zveřejňovat je na portálu otevřených dat.
5. Textové zprávy využívající reference na výše zmíněné zdroje včetně ad hoc informací.
Hodnocení stavu životního prostředí je vysoce komplexní úloha, jejímž cílem je hodnověrně zachytit jak vývoj v konkrétních složkách ochrany životního prostředí, tak vztahy mezi složkami a interakce s ekonomickou a sociální situací. Složitost je umocněna jak nejednoznačností monitoringu životního prostředí (např. ovzduší je monitorováno v 200 bodech v ČR a situace v území je modelována prostřednictvím modelů, mapy rozšíření druhů jsou odhadem skutečného rozšíření podle jednotlivých pozorování, data o odpadech vycházejí ze statistického modelu, kolik ekonomických subjektů se pravděpodobně zapojuje do reportingu a s jakou věrohodností jimi ohlášených dat lze počítat atp.), tak obtížemi při statistické agregaci (měřítka mapy, kumulace statistické nejistoty zapojením dalších datových zdrojů, nutnost snížení počtu proměnných a hledání reprezentativních zástupců) i problémy s finální prezentací.
Věrohodnost, robustnost a nezpochybnitelnost podávání zpráv o životním prostředí je proto elementární potřebou rezortu. MŽP ve spolupráci s CENIA mezi lety 2005 a 2008 vybudovala původní systém ISSaR, jehož cílem bylo zajištění procesního a znalostního zázemí pro vybudování důvěryhodného referenčního systému rezortní statistiky a podávání zpráv. Stávající ISSaR využívá jako zdroj dat - soubory .XLS(X). Pokud se požadavky na vstupní i výstupní data změní na základě změn v právních předpisech, aktuálních potřeb a požadavků státní správy, Evropské Komise, Statistického úřadu apod., jsou předpřipravené tabulky aktualizovány a v požadované nové struktuře s vysvětlivkami rozeslány kontaktním osobám správních úřadů i kontaktním osobám agendových informačních systémů MŽP, rezortních a statistických systémů atd. Tento sběr dat a i následné zpracování je ze své podstaty velmi složitý, časově náročný a pro jakékoliv změny málo pružný.
1 Snahou MŽP je postupný přechod na automatizované předávání dat ve stanoveném formátu (např. XML) prostřednictvím využití webových služeb. Postup předávání dat od jejich původců bude formalizován (vč. stanovení požadovaných termínů a standardů pro předávání dat) v rámci projektu NERP, který realizuje CENIA.
Stávající ISSaR tedy obsahuje statistické agregáty od cca 60 organizací, detailní metadatový popis, který je schopný postihnout i změnu metodiky výpočtu (např. časté změny ve výpočtu komunálních odpadů, změny ve vykazování, atd.) a nabídnout přepočet na souvislou časovou řadu (příkladem z obecné statistiky je přepočet na stálé ceny). Tyto agregáty jsou následně poskytovány ve formě statistické ročenky.
Dalším modulem ISSaR jsou jednotlivé indikátory včetně příslušných metadat, které jsou vypočítávány a vizualizovány zpravidla automaticky. ISSaR neobsahuje prostorová data přímo, pouze s nepřímou referencí na specifické územní číselníky (vazba na NUTS, hranice CHKO/NP, geomorfologické oblasti apod.).
ISSaR se historicky skládal z datového skladu (dále též „DS“), webových aplikací (prezentace na základě redakčního systému a prohlížeč obsahu DS) a aplikace (tlustého klienta) pro vkládání dat do databáze, který byl v průběhu vývoje datové části ISSaR rozšířen např. o možnost hromadného načtení dat. DS používá DB server MySQL verze 5.1.60. V datovém skladu je uloženo cca 400 000 záznamů o velikosti zhruba 70 MB. S přihlédnutím k nákladům nutným na případnou modernizaci a zabezpečení ISSaR se vedení MŽP rozhodlo systém ISSaR dále nerozvíjet a pořídit jeho generační náhradu postavenou na moderní otevřené architektuře, která bude mít i výrazně širší a dnešnímu stavu technologií více odpovídající strukturu a funkcionality.
Prohlížeč obsahu DS i redakční systém jsou naprogramovány v PHP5. Vše je provozováno na serveru s OS Fedora 14, Apache HTTP Server 2.2.17 a PHP 5.3.8. Server je fyzicky umístěn v server housingu mimo lokalitu MŽP. Uživatelé z LAN i WAN sítě přistupují k serveru stejným způsobem - přes veřejnou síť internet. Rozdíl v přístupu je pouze v kontrole IP adresy na cílovém serveru. Pokud uživatel přistupuje z IP adresy, která je mimo veřejný rozsah CENIA, je dotázán na heslo k přístupu ke stránce.
Služba či samostatný IS nebo portál, přes který by mohla veřejnost žádat informace o životním prostředí, není k dispozici, ale na webu ISSaRu – xxxxx.xxxxx.xx provozovaném rezortní organizací CENIA je uveden kontaktní email, na který se může veřejnost obrátit písemně v případě, že nenalezla požadované informace na webových stránkách CENIA. Případně je možné se obrátit na environmentální helpdesk EnviHELP. EnviHELP je informační systém sloužící pro poskytování informací z vybraných oblastí životního prostředí. V systému je možné vyhledat odpověď na dotaz ve znalostní bázi, případně zadat nový dotaz. Systém přiřadí dotaz k řešení příslušnému expertovi z dané oblasti ochrany životního prostředí, který odpověď vypracuje.
V současnosti odborná a laická veřejnost může na webu prohlížet řadu sestav/dashboardů vytvořených v nástroji Tableau (xxxxx://xxxxx.xxxxx.xx), výstupy v něm CENIA připravuje a publikuje od roku 2017. Zdrojem dat jsou digitalizovaná data ze zmíněných excelových tabulek transformovaná do struktur DS ISSaR (MySQL) a následně jsou načítána do Tableau, kde jsou vytvářeny a následně publikovány grafické dashboardy. Zavedení tohoto nástroje přineslo značný posun v možnostech vytváření a publikace informací o stavu a vývoji ŽP v ČR.
Zpráva o stavu ŽP v ČR, krajské ročenky, syntézy a další tak jsou tvořeny slovním hodnocením a buď vložením příslušného indikátoru (obrázek) anebo přímým webovým odkazem (URL) na portál ISSaR, kde je daný indikátor prezentován včetně zdrojových dat a výpočtů, vazeb na dílčí indikátory apod. Dílčí indikátory odkazují na podrobnější data, data odkazují na rezortní i mimorezortní zdroje dat.
Stávající stav je charakterizován zejména následujícími skutečnostmi. Data, která MŽP/CENIA získává (nejčastěji zasíláno emailem) od rezortních organizací, jsou data agregovaná, ve formě nejčastěji excelových tabulek, ale ty jsou často již ve tvaru výstupu (reportu). Obsahují vývoj poskytovaných indikátorů v letech, každý další rok jsou přidány nové hodnoty indikátorů a též je možné, že hodnoty za předchozí roky (období) jsou rozdílné od podkladu předaného v některém z minulých let. Nejedná se o data přímo strojově zpracovatelná (na jednom listu jsou nadpisy, komentáře, data, prázdné řádky a sloupce, několik tabulek pod sebou v jiné struktuře sloupců, střídají se číselné hodnoty s textovými apod.). Transformace takto poskytnutých dat do dále zpracovatelné podoby je poměrně náročná. CENIA za dobu existence ISSaR vytvořila řadu automatizovaných pomůcek, jak z těchto vstupů získat data pro analytické a reportovací účely. Přesto je nutné tento stav změnit a zajistit, aby původci dat předávali data v definovaných strojově dále zpracovatelných strukturách a formátech s jednoznačným metadatovým popisem a ručili za jejich obsah (zejména stanovením závazné struktury dat pro předávání v právních předpisech – např. ve vyhláškách).
Jelikož se jedná o data agregovaná, která neobsahují detailní informace (např. o osobách), tak nelze propojit data z různých agend/organizací například pro účely křížových kontrol (znečišťovatel ovzduší je zároveň znečišťovatelem vod apod.).
Kromě toho agendové informační systémy (AIS) rezortu životního prostředí často obsahují vlastní moduly pro reporting a tvorbu datových výstupů. Tyto systémy mají různou úroveň zpracování této problematiky a naprosto roztříštěná uživatelská prostředí. Výhledovým cílem implementace BI platformy (v rámci Etapy 2 předmětu plnění) je, spolu s obnovou jednotlivých agendových systémů, přenášet i tvorbu datových výstupů z těchto systémů do jednotného prostředí STaR – pro STaR se bude jednat o vstupy. BI platforma, resp. IS STAR jako takový, bude základem pro jednotný datový fond rezortu ŽP a jeho sdílení.
Se stávajícím stavem informační podpory pro statistiku a reporting MŽP jsou spojeny zejména následující nedostatky:
▪ Proces předávání zdrojových dat od povinných útvarů/osob je administrativně náročný
a nedostatečně formalizovaný;
▪ Stávající architektura ISSaR je na hraně svých možností (např. pracné aktualizace při změnách
v právních předpisech), jakož i technický stav XXXxX ztěžuje jeho další efektivní vývoj a provoz;
▪ Existuje významný architektonický a technologický dluh u stávajícího ISSaR;
▪ Stávající ISSaR nedokáže zajistit řadu požadavků klíčových uživatelů (např. možnost provádět křížové kontroly napříč agendami MŽP);
▪ Nejsou plně využívány možnosti analytických a statistických výstupů z dat MŽP (např. na úrovni predikcí atp.), a to zejména v důsledku využití agregovaného charakteru dat v ISSaR (je jich v časové řadě málo a jsou agregovaná);
▪ Plnění reportingových povinností MŽP podle evropských právních předpisů je administrativně náročné;
▪ Nejsou využívány všechny možnosti pro efektivní výkon kontrolních kompetencí;
▪ Stávající architektura a procesy získávání dat neumožňují významněji snížit administrativní zátěž spojenou se získáváním, zpracováním a vytěžováním dat;
▪ Nedostatky v zabezpečení dat a v zajištění ochrany osobních údajů dle GDPR.
2.3. Cíle spojené s vytvořením nového nástroje Business Intelligence
Z posouzení stávajícího stavu ISSaR (a šířeji stávajícího stavu informační podpory pro statistiku a reporting MŽP) a dále z analýzy potřeb MŽP vyplývá jednoznačný závěr, že pro MŽP není perspektivní dále rozvíjet stávající řešení informační podpory pro plnění povinností statistiky a reportingu.
Odstranit výše uvedená zjištění lze s ohledem na jejich rozsah a závažnost cestou organizačních opatření a cestou náhrady stávajícího řešení ISSaR a souvisejících aplikací novým řešením, jež bude budováno a provozováno při dodržení všech zásad daných příslušnými mezinárodně uznávanými standardy.
Stávající řešení ISSaR bude nahrazeno výstupy z projektu STaR (informační systém pro Statistiku a Reporting v rezortu MŽP). Obsahem projektu STaR je implementace navazujících aplikací a řešení, které v souhrnu vytvoří jeden informační systém STaR, který se skládá se z:
▪ Environmentální analytické platformy, tzv. „EAP platformy“ sloužící k ukládání dat a metainformací použitelných dále pro analytické účely. EAP obsahuje katalog dat (CKAN), vč. metodiky pro napojení IS a metodiky datových prvků – vstupních a výstupních datasetů a sekundárních ETL procesů do úložiště nástroje Elasticsearch (již realizováno);
▪ Organizačních opatření směřujících k pořizování dat (sběr dat definovaným způsobem,
v definovaném čase a formátu; návazný projekt NERP);
▪ Implementace Business Inteligence (BI) platformy (také označováno jako „BI platforma“, viz tato veřejná zakázka);
▪ Vytvoření portálové prezentační vrstvy publikující jednotlivé výstupy (také označováno jako
„Portál STaR“; běžící paralelní veřejná zakázka).
Na následujícím schématu jsou vymezeny problémové domény projektu STaR, a to na úrovni výčtu všech komponent, které budou v budoucnu spolupracovat a tvořit společně funkční prostředí. Na schématu je zároveň jednoznačně ohraničena BI platforma a její vazby na další funkční celky projektu STaR (tj. platformu EAP a Portál STaR). Tento výčet věcně vymezuje oblasti funkcionalit, které má BI platforma a BI nástroje splňovat pro zajištění budoucí efektivní tvorby statistických výstupů, reportingu a datových analýz.
Předmětem plnění Etapy 1 této Smlouvy je pouze dodávka BI platformy, napojení na platformu EAP, další vyjmenované okolní informační systémy a Portál STaR a zajištění určených Provozních služeb. Podrobný popis části schématu vztahující se k BI platformě následuje za schématem č. 1.
BI platforma, jejíž dodání je předmětem této VZ
Schéma 1: Cílový stav systému STaR MŽP (po realizaci všech zadávacích řízení a nasazení jednotlivých komponent) – orientační rámcový model – bude upřesněno v rámci Zpracování IT analýzy Fáze 1 plnění smlouvy.
BI platforma bude zpočátku (od data svého spuštění) načítat, čistit a transformovat datové sady primárně z EAP – Platformy pro ukládání a transformaci. BI platforma musí být ale rovněž schopna načítat data z ostatních datových zdrojů (AIS) prostřednictvím datového rozhraní (API) na agendové systémy v rámci resortu MŽP nebo z různých databází v rámci resortu MŽP (napojení bude pilotně ověřeno v rámci typových úloh (viz Fáze 2) při realizaci Díla. Napojení dalších informačních systémů bude předmětem Etapy 2 plnění Smlouvy). ETL komponenta BI platformy musí umožňovat, kromě základní ETL funkce převodu strukturovaných dat z EAP a databázových zdrojů do sémantické datové vrstvy BI platformy, také:
• Provádění a automatizaci transformace nestrukturovaných zdrojů (.XLSX) do strukturované podoby s možností ukládání dat jednak do sémantické datové vrstvy BI a jednak předávat přes API do EAP (tyto možnosti budou pilotně ověřeny v rámci realizace typových úloh ve Fázi 2 plnění Smlouvy);
• Vyřešení dodatečné úlohy, nad rámec běžných (GUI) konfiguračních možností ETL, tedy naprogramování ukládání přes API do EAP (tj. CKAN a ElasticSearch). Funkčnost těchto ETL procedur bude ověřena funkčními testy. Nejedná se o nativní konfigurační úlohu ETL, ale možnost naprogramování specifické úlohy nesouvisející s BI funkcionalitou (vložení nezávislého programového kód/skriptu v jazyce Python, R atp.). Primárně se předpokládá, že bude-li potřebné programování procedur v rámci ETL nástroje BI platformy, toto programování bude zajišťovat pro Objednatele CENIA, případně je je možné je požadovat po Dodavateli v rámci služby BI_08 „Služby vývoje (datových transformací, reportovacích modelů, sestav, dashboardů) na objednávku“2. ETL komponenta BI platformy musí umožňovat nastavování automatizovaného spuštění vytvořených ETL procedur včetně jejich jednoduché správy a logování.
Cílový stav využívání EAP je znázorněn na následujícím schématu.
2 Jde tedy o zrealizování specifické ETL úlohy realizované prostřednictvím ETL nástroje BI platformy tak, aby se CENIA mohla rozhodnout, zda v budoucnu bude využívat dále stávající SW KNIME nebo ETL nástroj BI platformy pro čištění dat, jejich transformace do .CSV souboru a jejich ukládání do CKAN.
BI platforma
Struktura CKAN katalogu má nastaveno hierarchické členění spočívající v ukládání informací, dat a metadat do propojených složek. V době vypsání veřejné zakázky dochází k naplňování CKAN datovými sadami a jejich metadaty potřebnými pro tvorbu Zprávy o životním prostředí. Druhou nejvyšší úroveň CKAN (pracovně L1) tvoří složky cca 46+13 indikátorů s přímou vazbou (shora; "využito v") na Zprávu o životním prostředí, která je na nejvyšší úrovni (L0) katalogu. Na úroveň L1 jsou (zdola; "zdrojová data datasetu") navázány složky pracovní úrovně L2 obsahující očištěné strukturovaného datového zdroje ve formě datových (CSV) souborů a ve většině případů jejich datové slovníky (JSON schema). Na jednu složku indikátoru (L1) zpravidla navazuje (zdola) 2 až 5 datových složek L2. Na úroveň L2 navazuje (zdola) zpravidla úroveň L3 obsahující, buď a) výpočtový algoritmus, tzv. InETL složku, s výpočtovým knime skriptem (.zip, včetně svg obrázku workflow), který popisuje očištění/transformaci nestrukturovaných dat (XLSX) anebo, zpravidla pokud L2 vrstva neobsahuje vlastní datový slovník (schema), tak z úrovně L2 b) je odkazováno na šablonu dat popisující související číselníky nebo strukturu (CSV). Na úroveň L3 (nebo také L2) navazují zdola složky obsahující nestrukturovaná zdrojová data - pracovní úroveň L4. Složky úrovně L4 obsahují jako resource zpravidla
.XLSX soubory (zpravidla 1 soubor za daný rok) od primárních původců - poskytovatelů dat (aktuální přehled viz obrázek níže; zpravidla se jedná o organizace mimo MŽP).
Princip hierarchické struktury s příklady jednotlivých vrstev uvádí soubory Přílohy č. 5 „Ukázka CKAN“ tohoto dokumentu. Datový obsah CSV souborů obsažených v CKAN je velmi různorodý (časově, územně, obsahově/atributově, počtem záznamů) a často také v čase atributově proměnlivý. Perioda aktualizace je v případě dat pro Zprávu o životním prostředí zpravidla 1x ročně, nicméně v různé termíny. CKAN obsahuje také funkcionalitu, která každý CSV soubor s jeho metadaty automatizovaně nahrává do noSQL datového jezera Elasticsearch. Prostřednictvím RESTfull API Elasticsearch (filtrovací, vyhledávací, čtecí aj.) funkce je pak možné pracovat s celou množinou strukturovaných dat obsažených CKAN nezávisle na vlastním CKAN.
V rámci plnění Fáze 2 - při naplnění sémantické datové vrstvy BI platformy, bude Dodavatel pracovat pouze s úrovní L2/L3 (cca 200 CSV) vyjma 2 typových úloh (viz Příloha č. 2 a 4 tohoto dokumentu), kdy je požadováno také otestování schopnosti BI platformy realizovat samotné očištění nestrukturovaných sad (L4) včetně validačního schématu (transformaci a její automatizaci XLSX->CSV, XLSX->sémantická datová vrstva). Tato funkcionalita BI platformy může být šířeji používána Objednatelem v rámci Etapy 2 plnění smlouvy, rozhodne-li se Objednatel tuto funkci využívat.
Stávající řešení EAP bude pro realizaci Etapy 1 plnění smlouvy primárním zdrojem datového obsahu pro BI platformu. V rámci transformace a uložení datových sad v BI platformě bude docházet ke skládání dat z datasetů (CSV) načtených z EAP do historizovaných datových struktur tvořených vzájemně provázanými daty ve formě významových a numerických dat (faktů) a dat popisných (dimenzí/číselníků) (např. více let dohromady) pro plnění tzv. „reportovacích modelů“ (datamartů) a k případnému čištění dat. Vyčištěná a transformovaná data budou ukládána do sémantické datové vrstvy, a to v rámci centrální datové vrstvy. Centrální datová vrstva tak představuje úložiště vyčištěných historizovaných datových záznamů (fakta a dimenze /číselníky, úhly pohledu na fakta) ve formě, která je dále zpracovatelná jednotlivými komponentami BI platformy v rámci opakovatelného použití. Datové záznamy budou v centrální datové vrstvě opatřeny časovými značkami (datum vzniku, platnost od, platnost do, zdroj dat, původce dat, fáze zpracování dat).
Nad centrální datovou vrstvou bude možno vytvářet jeden a více reportovacích modelů (tj. datamartů pro jednotlivé oblasti/agendy či indikátory MŽP). Reportovací modely představují sémantické dimenzionální datové modely (společné dimenze napříč fakty a indikátory z různých agend), včetně dopočtených ukazatelů a metrik. S touto vrstvou budou pracovat primárně Tvůrci sestav. Rovněž bude docházet k Analýze dat, hledání závislostí, přičemž výstupem mohou být zejména požadavky na úpravy dat, kvality dat či rozšíření modelů (dat v datamartech) atp.
Nad reportovacími modely fungují:
▪ Nástroje pro vizualizaci dat (self-service BI) – jde primárně o reportovací nástroje pro tvorbu
zejména
o Vizualizací dat ze sémantického reportovacího datového modelu a grafických výstupů;
o Tabulkových fixních výstupů (tzv. pixel perfect reporty) atp.
Doplňkovou komponentou BI platformy je zde nástroj (či add-on) pro tvorbu textových dokumentů pro plnění reportingových povinností MŽP dle platných právních předpisů (viz seznam reportingových povinností uvedený v příloze č. 2 tohoto dokumentu). Tento doplněk (nástroj) využívá vizualizační prvky BI platformy a vkládá je do míst určených oprávněným uživatelem v rámci dokumentů sady MS Office (tj. BI výstupy jsou „embedovány“ na příslušná místa do dokumentů sady MS Office). Výsledné dokumenty následně MŽP odesílá příslušným orgánům v EU a do budoucna je bude ukládat a vést v rámci EAP (v části CKAN), kde je opatří potřebnými metadaty.
▪ Nástroje pro pokročilou analýzu dat - jde primárně o služby/nástroje pro vyhledávání dat (datamining), pokročilé statistické analytické metody (tzv. Advaced analysis), možnost využití programovacího jazyka R, Python knihoven či případně spouštění speciálních dataminingových služeb.
▪ Nástroje pro publikování BI výstupů (tj. jejich embedování) do Portálu STaR.
Všechny výše uvedené funkce musí BI platforma obsahovat/nabízet již v rámci akceptace Fáze 1.
Koncoví uživatelé BI platformy (logovaní i nelogovaní/veřejnost) budou k BI výstupům přistupovat primárně přes IS Portál STaR (Portál STaR řídí přístupová oprávnění k BI výstupům pro koncové uživatele BI výstupů). Oprávnění uživatelé Portálu STaR mohou zpřístupňovat BI výstupy v rámci Portálu STaR (pro koncové uživatele) např. v rámci konkrétního micro situ.
Interní (vnitrorezortní) uživatelé s vyšší úrovní oprávnění se zpravidla budou přihlašovat a pracovat s BI platformou prostřednictvím interního (nativního) portálu BI platformy.
Podrobné požadavky na BI platformu jsou uvedeny v příloze č. 1 tohoto dokumentu „Katalog požadavků na BI platformu“.
Nové komplexní integrované prostředí BI platformy je pro účely tohoto zadávacího řízení rovněž označováno jako „BI platforma“ a MŽP ho buduje s následující vizí cílového stavu:
▪ Funguje nové komplexní prostředí pro řešení BI úloh napříč agendami a datovou základnou MŽP, které je postaveno na základě moderní solution architektury a na perspektivních
technologiích, jež je možno do budoucna efektivně rozvíjet a škálovat bez nutnosti nahrazovat dílčí či všechny komponenty BI platformy (minimalizace rizik zmaření investic MŽP);
▪ MŽP je vlastníkem zdrojových kódu ETL procesů, databázových procedur, výpočtu ukazatelů a metrik a případných pro účely plnění této Veřejné zakázky vyvíjených aplikací a všechna obchodní a licenční ujednání vylučují, aby nastala situace „vendor lock-in“;
▪ MŽP disponuje efektivními nástroji pro naplňování požadavků legislativy pro statistiky a reporting;
▪ BI platformu je možno snadno integrovat na okolní informační systémy;
▪ Vyvíjené vrstvy řešení (ETL, struktury v datových vrstvách, vizuální i tabulkové výstupy) je možné pružně upravovat s ohledem na změny v právních předpisech regulujících reportingové povinnosti MŽP;
▪ MŽP dokáže rychle (s ohledem na srovnatelná řešení) vyhodnocovat a operativně poskytovat relevantní a aktuální informace o agendách, které spadají do gesce MŽP dle kompetenčního zákona,3 a to napříč celou datovou základnou MŽP bez nutnosti hradit dodavatelům jednotlivých zdrojových informačních systémů za ad-hoc služby typu přípravy dat, zpracování složitějších dotazů (selectů), zpracování datových sestav atp.;
▪ Struktura a formát přijímaných dat do BI platformy odpovídají schváleným datovým standardům v oblasti agend MŽP.4
Nástroje BI platformy implementované v rámci projektu STaR plnohodnotně funkčně nahradí stávající datový sklad ISSaR a přidají nové funkcionality dle požadavků klíčových uživatelů. Specifické potřeby jednotlivých skupin klíčových uživatelů, jsou popsány v Katalogu požadavků (viz příloha č. 1 tohoto dokumentu). Data z ISSaR do datové vrstvy BI platformy v rámci dodávky BI platformy migrována nebudou (do BI platformy budou přebírána data z EAP a příp. z dalších okolních zdrojů dat – viz zadání typových úloh ve Fázi 2).
Rezort MŽP aktuálně realizuje řadu úloh zpracování dat a datových výstupů, které vyplývají z platných právních předpisů (ČR a EU) a dalších povinností daných mezinárodními smlouvami. Vedle toho musí BI platforma nabízet funkcionalitu pro analyzování dat za účelem nacházení souvislostí a případně predikování budoucího stavu či vývoje (více viz bod - BI-3-2 - Příloha č. 1: „Katalog požadavků na BI platformu“).
Úlohy zpracování dat a datových výstupů MŽP lze rozdělit do několika skupin:
1. Přehledy (tabulky, grafy) pro účely tvorby
1a. Zprávy o stavu životního prostředí ČR;
1b. Zprávy o stavu ŽP v krajích;
3 Zákon č. 2/1969 Sb., o zřízení ministerstev a jiných ústředních orgánů státní správy České republiky, ve znění pozdějších předpisů.
4 Např. viz datový standard dle zákona č. 25/2008 Sb., o integrovaném registru znečišťování životního prostředí a integrovaném systému plnění ohlašovacích povinností v oblasti životního prostředí a o změně některých zákonů, ve znění pozdějších předpisů.
1c. Statistické ročenky;
1d. Další skupiny specifických indikátorových sad.
Datové vstupy pro tvorbu těchto přehledů jsou již agregovaná data – tzv. indikátory, která v současné době počítají a zasílají na MŽP/CENIA již v agregované podobě rezortní organizace a další externí subjekty (ve formě excelových tabulek e-mailem).5 A také za správnost těchto dat ručí. Pro tvorbu výstupů není zpravidla potřeba dodatečných přepočtů, kombinací, obohacovaní či slučování dat.
CENIA v rámci projektu NERP zajišťuje, aby organizace v resortu MŽP dodávaly vstupní data do EAP ve strojově zpracovatelném formátu (např. .CSV souborech) a aby proces předávání dat byl formalizován (a existovala tak smluvní vynutitelnost stanovených pravidel). Pro potřeby plnění Fáze 2 bude v EAP dostupných 200 .CSV včetně jejich metadatového popisu.
2. Data ke zveřejnění ve formátu Open Dat
Jsou určená pro širokou veřejnost k jakémukoliv použití. Datové sady v některém z formátů Open Datové sady a metadata zveřejněné na portálu otevřených dat - buď vlastní portál MŽP (dnes CKAN) nebo je využit portál xxxxx://xxxxxxxx.xxx.xx/ a doporučená metodika xxxxx://xxxx.xxx.xx/xxxxxxxxx/xxxxxx%X0%X0-xx%X0%0Xxxxxx-xxx-xxxxxxxx-x- pod%C5%99%C3%ADzen%C3%BDmi-organizacemi/.
3. Data pro splnění reportingových povinností vůči EU
Zastřešováno Evropskou agenturou pro životní prostředí (EEA). Data jsou předávána prostřednictvím sítě EIONET/ReportNet a ukládána do systému „Content Registry“ (knihovna archivující a zpřístupňující veškerá data a doprovodné dokumenty poskytnuté členskými zeměmi za celou dobu existence EEA). Evidence veškerých mezinárodních reportingových povinností všech členských zemí je v „Reporting Obligations Database“ (ROD) (viz xxxxx://xxx.xxxxxx.xxxxxx.xx/).
Musí jít o data zaručená, zkontrolovaná a potvrzená odpovědnými subjekty (původci dat) opatřená metadaty včetně data vzniku a platností dat. Jedná se též o data agregovaná. Tato oblast je řešena nezávisle na BI platformě. BI platforma v rámci implementační Etapy 1 tuto oblast nerozpracovává, nicméně snahou do budoucna výpočty, transformace a případně publikaci řešit min. částečně za pomocí nástrojů BI platformy.
4. Digitalizovaná data agregovaná
Jejich zdrojem jsou data uvedená v bodě 1. Slouží pro tvorbu agregovaných výstupů pro účely zveřejnění na webu (v současné době portál ISSaR a realizace v Tableau) - jako doplněk ke statistické ročence (odkazy na portál, kde jsou výstupy zveřejněny).6
5 Pozn.: Velkou a nezanedbatelnou skupinou vstupních agregovaných dat jsou také data, která si pracovníci CENIA stahují manuálně z ročenek, přehledů apod., jež příslušné subjekty (původci dat) vystaví na svých stránkách pro veřejnost.
6 Viz xxxxx://xxxxx.xxxxx.xx.
5. Data pro účely realizace analytických úloh napříč agendami ŽP
Pro tyto úlohy budou využívána data neagregovaná, na co nejvyšší úrovni podrobnosti (vyčištěná primární data nebo faktová data a data dimenzionální) opatřená vazbami na dimenze (číselníky), přes která je možné data propojovat a analyzovat souvislosti. Zdrojem těchto dat budou postupně, ve chvíli kdy bude legislativně podloženo, jednotlivé agendové informační systémy MŽP napojené ETL komponentou BI platformy (postupné napojování bude předmětem rozvoje BI platformy anebo Objednatel či jím pověřený subjekt bude moci napojení provádět na základě vyškolení vlastními silami).
Tento typ analýz je prováděn nyní ad hoc dle potřeb jednotlivých věcně příslušných útvarů či vedoucích pracovníků MŽP a není informačně podpořen ze strany ISSaR.
BI platforma bude primárně využita pro úlohy pod body 1, 3, 4 a 5 (úlohy pod bodem 5 představující výhledové využití BI platformy, tj. budou realizovány v Etapě 2). Pro úlohu pod bodem 2 je využívána platforma EAP (Environmentální analytická platforma).
Vznik BI platformy je v souladu a naplňuje následující strategické dokumenty vlády ČR:
▪ Strategický rámec rozvoje veřejné správy České republiky pro období 2014-20207;
▪ Strategie mezinárodní konkurenceschopnosti ČR 2012-2020;
▪ Národní program reforem České republiky 2014;
▪ Další strategické dokumenty ČR v oblasti eGovernmentu.
2.4. Základní přehled legislativy pro oblast statistiky a reportingu MŽP
BI platformu je Dodavatel povinen dodat a implementovat (vč. stanovených typových úloh stanovených ve Fázi 2) tak, aby umožňovala analyticky vyhodnocovat data v agendách MŽP a aby její nasazení bylo ve shodě s platnými právními předpisy ČR a EU upravujícími statistické a reportingové povinnosti MŽP a s právními předpisy ČR a EU v oblasti eGovernmentu. Základní přehled právních předpisů, které ilustrují rozsahy dat v agendách MŽP, je uveden v následujících kapitolách.8
2.4.1. Právní předpisy pro oblast odpadů
▪ Zákon č. 185/2001 Sb., o odpadech a o změně některých dalších zákonů, ve znění pozdějších předpisů;
▪ Nařízení vlády č. 352/2014 Sb., o Plánu odpadového hospodářství České republiky pro období
2015-2024, ve znění pozdějších předpisů;
▪ Vyhláška č. 170/2010 Sb., o bateriích a akumulátorech a o změně vyhlášky č. 383/2001 Sb.,
o podrobnostech nakládání s odpady, ve znění pozdějších předpisů;
▪ Vyhláška č. 237/2002 Sb., o podrobnostech způsobu provedení zpětného odběru některých výrobků, ve znění pozdějších předpisů;
7 Strategický rámec rozvoje veřejné správy České republiky pro období 2014–2020 je jediným národním koncepčním dokumentem v ČR, který stanovuje rozvoj veřejné správy na vymezené období. Tento dokument má v gesci Ministerstvo vnitra ČR a navazují na něj podrobné implementační plány.
8 Nejde o taxativní výčet, ale pouze výčet demonstrativní.
▪ Vyhláška č. 248/2015 Sb., o podrobnostech provádění zpětného odběru pneumatik, ve znění pozdějších předpisů;
▪ Vyhláška č. 352/2005 Sb., o podrobnostech nakládání s elektrozařízeními a elektroodpady a o bližších podmínkách financování nakládání s nimi (vyhláška o nakládání s elektrozařízeními a elektroodpady), ve znění pozdějších předpisů;
▪ Vyhláška č. 352/2008 Sb., o podrobnostech nakládání s odpady z autovraků, vybraných autovraků, o způsobu vedení jejich evidence a evidence odpadů vznikajících v zařízeních ke sběru a zpracování autovraků a o informačním systému sledování toků vybraných autovraků (o podrobnostech nakládání s autovraky), ve znění pozdějších předpisů;
▪ Vyhláška č. 93/2016 Sb., o Katalogu odpadů, ve znění pozdějších předpisů;
▪ Vyhláška č. 383/2001 Sb., o podrobnostech nakládání s odpady, ve znění pozdějších předpisů;
▪ Vyhláška č. 384/2001 Sb., o nakládání s polychlorovanými bifenyly, polychlorovanými terfenyly, monometyltetrachlordifenylmetanem, monometyldichlordifenylmetanem, monometyldibromdifenylmetanem a veškerými směsmi obsahujícími kteroukoliv z těchto látek v koncentraci větší než 50 mg/kg (o nakládání s PCB), ve znění pozdějších předpisů;
2.4.2. Právní předpisy pro oblast obalů
▪ Zákon č. 477/2001 Sb., o obalech a o změně některých zákonů (zákon o obalech), ve znění pozdějších předpisů;
▪ Vyhláška č. 641/2004 Sb., o rozsahu a způsobu vedení evidence obalů a ohlašování údajů z této evidence, ve znění pozdějších předpisů;
▪ Vyhláška č. 116/2002 Sb., o způsobu označování vratných zálohovaných obalů, ve znění pozdějších předpisů;
▪ Nařízení vlády č. 111/2002 Sb., kterým se stanoví výše zálohy pro vybrané druhy vratných zálohovaných obalů, ve znění pozdějších předpisů.
2.4.3. Právní předpisy pro oblast ochrany vod
▪ Zákon č. 254/2001 Sb., o vodách a o změně některých zákonů (vodní zákon);
▪ Vyhláška č. 431/2001 Sb., o obsahu vodní bilance, způsobu jejího sestavení a o údajích
pro vodní bilanci;
▪ Vyhláška č. 125/2004 Sb., kterou se stanoví vzor poplatkového hlášení a vzor poplatkového přiznání pro účely výpočtu poplatku za odebrané množství podzemní vody;
▪ Vyhláška č. 328/2018 Sb., o postupu pro určování znečištění odpadních vod, provádění odečtů množství znečištění a měření objemu vypouštěných odpadních vod do vod povrchových.
2.4.4. Právní předpisy pro oblast ochrany ovzduší
▪ Zákon č. 201/2012 Sb., o ochraně ovzduší;
▪ Zákon č. 73/2012 Sb., o látkách, které poškozují ozonovou vrstvu, a o fluorovaných skleníkových plynech;
▪ Vyhláška č. 257/2012 Sb., o předcházení emisím látek, které poškozují ozonovou vrstvu,
a fluorovaných skleníkových plynů.
2.4.5. Právní předpisy pro oblast ochrany přírody a krajiny (včetně ochrany lesa a nerostného bohatství)
▪ Zákon č. 114/1992 Sb., o ochraně přírody a krajiny, ve znění pozdějších předpisů;
▪ Vyhláška č. 189/2013 Sb., o ochraně dřevin a povolování jejich kácení, ve znění pozdějších předpisů;
▪ Vyhláška č. 142/2018 Sb., o náležitostech posouzení vlivu záměru a koncepce na evropsky významné lokality a ptačí oblasti a o náležitostech hodnocení vlivu závažného zásahu na zájmy ochrany přírody a krajiny, ve znění pozdějších předpisů;
▪ Vyhláška č. 45/2018 Sb., o plánech péče, zásadách péče a podkladech k vyhlašování, evidenci a označování chráněných území, ve znění pozdějších předpisů;
▪ Vyhláška č. 166/2005 Sb., kterou se provádějí některá ustanovení zákona č. 114/1992 Sb.,
o ochraně přírody a krajiny, ve znění pozdějších předpisů, v souvislosti s vytvářením soustavy NATURA 2000, ve znění pozdějších předpisů;
▪ Nařízení vlády č. 318/2013 Sb., o stanovení národního seznamu evropsky významných lokalit, ve znění pozdějších předpisů;
▪ Vyhláška č. 468/2004 Sb., o autorizovaných osobách podle zákona o ochraně přírody a krajiny,
ve znění pozdějších předpisů;
▪ Vyhláška č. 395/1992 Sb., kterou se provádějí některá ustanovení zákona České národní rady č. 114/1992 Sb., o ochraně přírody a krajiny, ve znění pozdějších předpisů;
▪ Zákon č. 289/1995 Sb., o lesích a o změně a doplnění některých zákonů (lesní zákon), ve znění pozdějších předpisů;
▪ Zákon č. 334/1992 Sb., o ochraně zemědělského půdního fondu, ve znění pozdějších předpisů;
▪ Zákon č. 449/2001 Sb., o myslivosti, ve znění pozdějších předpisů;
▪ Zákon č. 44/1988 Sb., o ochraně a využití nerostného bohatství (horní zákon), ve znění pozdějších předpisů;
▪ Vyhláška č. 369/2004 Sb., o projektování, provádění a vyhodnocování geologických prací, oznamování rizikových geofaktorů a o postupu při výpočtu zásob výhradních ložisek, ve znění pozdějších předpisů;
▪ Vyhláška č. 172/1992 Sb., o dobývacích prostorech, ve znění pozdějších předpisů;
▪ Vyhláška č. 364/1992 Sb., o chráněných ložiskových územích, ve znění pozdějších předpisů;
▪ Zákon č. 62/1988 Sb., o geologických pracích, ve znění pozdějších předpisů;
▪ Vyhláška č. 282/2001 Sb., o evidenci geologických prací, ve znění pozdějších předpisů.
2.4.6. Právní předpisy pro oblast ochrany klimatu
▪ Zákon č. 73/2012 Sb., o látkách, které poškozují ozonovou vrstvu, a o fluorovaných skleníkových plynech, ve znění pozdějších předpisů;
▪ Vyhláška č. 257/2012 Sb., o předcházení emisím látek, které poškozují ozonovou vrstvu, a fluorovaných skleníkových plynů, ve znění pozdějších předpisů;
▪ Zákon č. 383/2012 Sb., o podmínkách obchodování s povolenkami na emise skleníkových plynů, ve znění pozdějších předpisů;
▪ Zákon č. 695/2004 Sb., o podmínkách obchodování s povolenkami na emise skleníkových plynů a o změně některých zákonů, ve znění pozdějších předpisů;
▪ Zákon č. 85/2012 Sb., o ukládání oxidu uhličitého do přírodních horninových struktur
a o změně některých zákonů, ve znění pozdějších předpisů.
2.4.7. Právní předpisy pro oblast integrovaného registru znečištění a procesy EIA/SEA
▪ Zákon č. 76/2002 Sb., o integrované prevenci a omezování znečištění, o integrovaném registru znečišťování a o změně některých zákonů (zákon o integrované prevenci), ve znění pozdějších předpisů;
▪ Vyhláška č 288/2013 Sb., o provedení některých ustanovení zákona o integrované prevenci,
ve znění pozdějších předpisů;
▪ Zákon č. 25/2008 Sb., o integrovaném registru znečišťování životního prostředí a integrovaném systému plnění ohlašovacích povinností v oblasti životního prostředí a o změně některých zákonů, ve znění pozdějších předpisů;
▪ Nařízení vlády č. 145/2008 Sb., kterým se stanoví seznam znečišťujících látek a prahových hodnot a údaje požadované pro ohlašování do integrovaného registru znečišťování životního prostředí, ve znění pozdějších předpisů;
▪ Zákon č. 100/2001 Sb., o posuzování vlivů na životní prostředí a o změně některých souvisejících zákonů (zákon o posuzování vlivů na životní prostředí), ve znění pozdějších předpisů;
▪ Vyhláška č. 453/2017 Sb., o odborné způsobilosti a o úpravě některých dalších otázek souvisejících s posuzováním vlivů na životní prostředí, ve znění pozdějších předpisů.
2.4.8. Právní předpisy pro oblast finanční podpory z „Evropských fondů“
▪ NAŘÍZENÍ EVROPSKÉHO PARLAMENTU A RADY (EU) č. 1303/2013 ze dne 17. prosince 2013,
o společných ustanoveních o Evropském fondu pro regionální rozvoj, Evropském sociálním fondu, Fondu soudržnosti, Evropském zemědělském fondu pro rozvoj venkova a Evropském námořním a rybářském fondu, o obecných ustanoveních o Evropském fondu pro regionální rozvoj, Evropském sociálním fondu, Fondu soudržnosti a Evropském námořním a rybářském fondu a o zrušení nařízení Rady (ES) č. 1083/2006.
2.4.9. Právní předpisy z oblasti eGovernmentu ČR
Na návrh výběr a dodávku nástrojů BI platformy mají dopad zejména následující právní předpisy:
▪ Zákon č. 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ů;
▪ Vyhláška č. 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ů;
▪ Vyhláška č. 317/2014 Sb., o významných informačních systémech a jejich určujících kritériích, ve znění pozdějších předpisů;
▪ Nařízení Evropského Parlamentu a Rady (EU) č. 2016/679 ze dne 27. dubna 2016, o ochraně fyzických osob v souvislosti se zpracováním osobních ú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ů);
▪ Zákon č. 110/2019 Sb., o zpracování osobních údajů, ve znění pozdějších předpisů;
▪ Nařízení Evropského Parlamentu a Rady (EU) č. 910/2014 ze dne 23. července 2014
o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce
na vnitřním trhu a o zrušení směrnice 1999/93/ES;
▪ Zákon č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce, ve znění pozdějších předpisů;
▪ Zákon č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů;
▪ Vyhláška č. 529/2006 Sb., o požadavcích na strukturu a obsah informační koncepce a provozní dokumentace a o požadavcích na řízení bezpečnosti a kvality informačních systémů veřejné správy (vyhláška o dlouhodobém řízení informačních systémů veřejné správy), ve znění pozdějších předpisů.
2.4.10. Základní právní předpisy pro výkon státní správy
▪ zákon č. 500/2004 Sb., správní řád, ve znění pozdějších předpisů;
▪ zákon č. 234/2014 Sb., o státní službě, ve znění pozdějších předpisů.
2.4.11. Základní právní předpisy pro oblast statistiky
▪ Zákon č. 89/1995 Sb., o státní statistické službě.
3. Předmět veřejné zakázky
Předmětem Veřejné zakázky je především:
1. Dodávka a nasazení BI platformy a realizace definovaných typových úloh (tj. dodávka
a nasazení Díla) – Etapa 1;
2. Zajištění vybraných Provozních služeb - Etapa 2,
BI_01 | Řízení dostupnosti BI platformy a provozní monitoring (paušál / 1 rok) |
BI_02 | Servisdesk, hot-line pro Objednatele – (paušál / 1 rok) |
BI_03 | Paušální správa aktiv, konfigurací a maintenance – ( paušál / 1 rok) |
BI_04 | Řízení incidentů – (paušál / 1 rok)) |
BI_05 | Konzultace (v počtu 15 MD / 1 rok) |
BI_06 | Řízené ukončení provozních služeb (Exit strategie) |
BI_07 | Školení na objednávku (v počtu 3 školení / 1 rok) |
BI_08 | Služby vývoje (datových transformací, reportovacích modelů, sestav, dashbordů) na objednávku (v počtu 50 MD / 1 rok) |
BI_09 | Rozvoj Díla, správa releasů a nasazení (velké Upgrady) (v počtu 30 MD / 1 rok) |
BI_10 | Zajištění jednoho Přesunu Díla, tzn. změna místa instalace Díla, včetně všech souvisejících náležitostí (na základě požadavku Objednatele, a to i opakovaně) |
Plnění předmětu Xxxxxxx bude probíhat dle následujícího Harmonogramu.
# | Hlavní etapa/dílčí etapa | Zahájení | Ukončení Hlavní/dílčí milník |
Etapa 1 | Zhotovení Díla | T1 | T1+190 dnů |
A.0 | FÁZE 0 – Zahájení projektu | T1 | T1+35 dnů |
A.1 | FÁZE 1 – Vytvoření a dílčí ověření parametrů řešení BI platformy | T1 | T1+90 dnů |
A.1.1 | Zpracování IT analýzy | T1 | T1+45 dnů |
A.1.2 | Vytvoření BI platformy | T1+45 dnů9 | T1+75 dnů |
A.1.3 | Testování a akceptace BI platformy | T1+75 dnů | T1+90 dnů |
A.2 | FÁZE 2 – Integrace BI platformy, naplnění sémantické datové vrstvy BI platformy daty z katalogu EAP a realizace definovaných typových úloh, | T1+90 dnů10 | T1+150 dnů |
A.3 | FÁZE 3 – Školení koncových uživatelů a administrátorů | T1+140 dnů | T1+170 dnů |
A.4 | FÁZE 4 – Pilotní provoz - úplné ověření parametrů řešení a předání Díla včetně licencí do řádného provozu | T1+150 dnů | T1+190 dnů |
A.4.1 | Pilotní provoz | T1+150 dnů | T1+185 dnů |
A.4.2 | Akceptační řízení (celková Akceptace Díla) | T1+185 dnů | T1+190 dnů |
9 Resp. v termínu Zpracování IT analýzy upřesněném v prováděcím projektu v rámci Fáze 0.
10 Resp. termínu Akceptace Fáze 1. Realizace naplnění sémantické datové vrstvy BI daty z katalogu EAP je možné započít na vývojovém prostředí Dodavatele již od akceptace dílčího milníku Vytvoření BI platformy (A.1.2).
Etapa 2 | Etapa 2 (Provoz Díla) - Fáze zajištění vybraných Provozních služeb | T1+190 dnů | Po dobu trvání Smlouvy (dle typu Provozní služby průběžně/jednorázově/na objednávku) |
T1 = Účinnost Smlouvy
Jednotlivé aktivity plnění předmětu Veřejné zakázky jsou popsány v následujících kapitolách.
3.1. Zhotovení Díla
Zhotovení Díla zajistí Dodavatel v následujících fázích.
3.1.1. Fáze 0 – Zahájení projektu
Dodavatel je povinen před zahájením dodávek, konfiguračních, vývojových a implementačních prací provést následující aktivity zahájení projektu, jejichž předmětem je:
• Vytvoření a představení projektové a vývojové metodiky (dále „Prováděcí projekt“) do 14 kalendářních dnů od účinnosti Smlouvy. Do 7 kalendářních dnů od předání Prováděcího projektu přednese Objednatel (tj. MŽP) své připomínky. Po jejich zapracování bude moci proběhnout akceptace Fáze 0 (Prováděcího projektu). V případě opakovaných připomínek bude opakováno i jejich zapracování a následné schvalování;
• Prováděcí projekt bude obsahovat zejména:
o Představení členů realizačního týmu a organizační struktury realizačního týmu
a nastavení komunikačních pravidel;
o Nastavení mechanismů pro sdílení informací;
o Nastavení mechanismů spojených s implementací projektové a vývojové metodiky.
o Nastavení eskalačních mechanismů;
o Nastavení risk managementu;
o Zpřesnění Harmonogramu realizace Díla (termíny realizace dílčích plnění Díla a jejich předávání Objednateli), který nesmí být v rozporu s rámcovým Harmonogramem dle Smlouvy. Harmonogram musí obsahovat alespoň:
▪ Detailní vymezení rozsahu a naplánování termínů předávání jednotlivých
komponent BI platformy;
▪ Detailní vymezení rozsahu a naplánování termínů předávání jednotlivých komponent/vrstev BI platformy a řešení požadovaných (definovaných) typových úloh (viz dále);
▪ Zpracování plánu akceptačních testů (akceptací dílčích plnění a akceptace celého Díla);
▪ Zpřesnění požadavků na součinnost ze strany Objednatele.
• Závazná osnova Prováděcího projektu je součástí Přílohy č. 3 Smlouvy.
Další pokračování v realizaci Veřejné zakázky, vyjma realizace Zpracování IT analýzy, která je součástí Fáze 1, je podmíněno řádným provedením této Fáze 0, tj. akceptací všech jejích závěrů, resp. Prováděcího projektu.
V rámci celého plnění dle Smlouvy bude postupováno podle nastavených metodik. V případě nutnosti jejich korekce bude změna projednána a po oboustranném odsouhlasení zapracována do platného znění příslušného Prováděcího projektu.
3.1.2. Fáze 1 – Vytvoření a dílčí ověření parametrů řešení BI platformy
V rámci této fáze Dodavatel zajistí:
1. Zpracování IT analýzy pro SW architekturu a požadavků na Technologickou platformu11
1.1. Zpracování IT analýzy dle přílohy č. 1 této Specifikace - „Katalog požadavků na BI platformu“ a zpřesnění SW architektury12 a požadavků na Technologickou platformu navržených Dodavatelem v Nabídce. IT analýza musí obsahovat specifikaci nástrojů a komponent a jejich funkcionalit (více viz požadavky na dokumentaci uvedené v Příloze č. 3 Smlouvy);
1.2. Zpracování návrhu ergonomie ovládání a vzhledu uživatelského rozhraní BI platformy (zejména barevné schéma, typy písma, rozložení vizuálních prvků v sestavách a dashboardech atp.).
1.3. Zpracování akceptačních scénářů (testů) v návaznosti na přílohu č. 1 této Specifikace:
„Katalog požadavků na BI platformu“.
1.4. Zpracování Exit plánu.
2. Vytvoření BI platformy – Dodavatel v souladu s požadavky Smlouvy a přílohy č. 1 této Specifikace: „Katalog požadavků na BI platformu“ provede dodávku všech potřebných SW technologií a komponent Díla, jejich konfiguraci a potřebné integrace.
Pokud některý požadavek stanoví minimální úroveň naplnění, může Dodavatel zajistit naplnění požadavku na pokročilejší (vyšší) úrovni, nikdy však na úrovni méně pokročilé (nižší).
Dodavatel si může postup implementace vytvoření systému rozdělit do několika milníků. V takovém případě je naplánování obsahu a rozsahu milníků plně úlohou Dodavatele a musí respektovat jím navržené projektové a vývojové metodiky. Tyto milníky jsou čistě postupovými kroky při implementaci a nebudou fakturačními milníky.
Vývojovým a implementačním pracím musí předcházet důkladná IT analýza předmětné oblasti (viz Zpracování IT analýzy). Technická specifikace obsahuje všechny požadavky Objednatele na poptávaný systém či jeho komponenty (moduly/služby) v přiměřené míře podrobnosti, z nichž je však patrný přístup Dodavatele a je možnost ověřit shodu se zadáním BI platformy (viz 1.3 akceptační scénáře výše). K jejich naplnění však může být potřebné zodpovězení některých dílčích, zadáním neupravených otázek. V případě, že zadání neupravuje zcela jednoznačně určitou oblast, a ta umožňuje variantní řešení, musí být volba varianty řešena
11 Pro vyloučení všech pochybností Objednatel konstatuje, že nedílnou součástí dodávky a nasazení Díla je zajištění dodání potřebných licencí a zprovoznění SW platformy Díla, kdy SW platformou Díla se rozumí soubor software Dodavatelem nevyvíjeného výhradně pro účely BI platformy STaR (tj. tohoto zadávacího řízení), který je nezbytný pro řádné nasazení a provoz Díla (ETL/BI SW, operační sytém, databáze, pluginy aj.). Zajištění a správa hardware, síťové konektivity a virtualizačního software (včetně jejich konfigurace), na kterých bude Dílo, včetně SW platformy Díla, provozováno, není součástí smluvního plnění a zajišťuje je Objednatel v návaznosti na obdrženou specifikaci Dodavatele, resp. Dodání Dokumentace.
12 Objednatel nabízí pro potřeby plnění Veřejné zakázky možnost bezplatného využití licencí operačních systémů (OS) Windows (WinSvrDCCore 2019 – bez Software Assurance) nebo Linux (SUSE Linux Enterprise Server, x86 & x86-64, 1-2 Sockets with Unlimited Virtual Machines, Standard Subscription, 5 Year) za účelem jejich zakomponování do architektury BI platfromy. Správa a údržba operačních systémů je zajišťována Dodavatelem. Objednatel však neomezuje volbou operačních systémů (OS); návrh řešení za použití jakýchkoliv jiných, než výše uvedených operačních systémů je na volbě Dodavatele. Finanční náklady spojené s dodávkou (licencí) jiných OS (než výše uvedených) či jiných komponent SW platformy zohlednil Dodavatel v ceně BI platformy v rámci STaR.
s Objednatelem. V opačném případě může Objednatel řešení odmítnout a vrátit jej Dodavateli k přepracování.
V případě, že Dodavatel v průběhu implementace narazí na vzájemně protichůdné požadavky, bude tato situace řešena ve spolupráci s Objednatelem. V opačném případě může Objednatel řešení odmítnout a vrátit jej Dodavateli k přepracování.
Vytvoření BI platformy se bude skládat zejména z níže uvedených aktivit:
2.1. Instalace SW platformy Díla na Technologické platformě Objednatele pro všechna provozovaná prostředí (tj. pro zajištění vývoje, testování a provozu ve všech požadovaných prostředích) na HW prostředcích zajištěných Objednatelem, kdy SW platformou Díla se rozumí soubor software Dodavatelem nevyvíjeného výhradně pro účely STaR (tzv. standardizovaného SW), který je však plnohodnotnou BI platformou schopnou realizovat požadavky definované v příloze č. 1 této Specifikace: „Katalog požadavků na BI platformu“ spolu s dalším SW nezbytným pro řádné nasazení a provoz Díla (tj. operační systém, pluginy, SW frameworky aj.). BI a SW platformu Díla zprovozňuje Dodavatel od virtualizačního SW (WM Ware) výše. Provoz HW a síťové infrastruktury a virtualizačního SW zajišťuje Objednatel.
Licence všech SW produktů (vč. zakoupených produktů podpory) musí být registrovány na Objednatele (viz dále) (s výjimkou open source, kde musí být na Objednatele registrována zakoupená komerční podpora). Za účelem zprovoznění a další správy SW platformy Díla zajistí Objednatel Dodavateli vzdálené přístupy přes Objednatelem poskytnutého VPN klienta (veškeré přístupy musí být realizovány přes firewall a VPN klienta, jež jsou spravovány ze strany Objednatele). K OS a serverům musí Dodavatel udělit Objednateli tzv. rootový přístup; V případě, že zprovoznění jsou nezbytné licence SW, Dodavatel zajistí tyto licence pro potřeby testování Objednatele s tím, že formálně se jejich vlastníkem Objednatel stává až Akceptací Díla.
2.2. Konfigurace SW platformy Díla, resp. jednotlivých komponent BI platformy.
2.3. Zpracování a předání testovací dokumentace13 a akceptačních scénářů pro akceptaci BI platformy.
2.4. Dodání licencí ke všem prvkům BI platformy. V rámci předání licencí Dodavatel doloží, že licence jsou u vendora standardního SW registrovány na Objednatele, a že údržba a podpora je registrována na Objednatele u poskytovatele podpory (k jednotlivým SW produktům). Totéž platí pro opensource SW, kdy je požadována zakoupená komerční (enterprise) podpora nasazeného SW produktu. Licence budou předány pro potřeby testování; do vlastnictví Objednatele přechází Akceptací Díla. Termínem pro začátek běhu maintenance k předaným licencím je den následující po Akceptaci Díla.
3. Testování a akceptace BI platformy
Ukončení Fáze 1 je podmíněno úspěšným testováním, které konstatuje, že v rovině funkčností není aktuálně známa žádná závažná vada (tj. Vada Kategorie A) znemožňující užívání všech součástí řešení a zahájení navazující Fáze 2.
13 Tzn. zpracování a předání dokumentace BI platformy v souladu s požadavky stanovenými zadavatelem na BI platformu vyjma kompletního předání bezpečnostní dokumentace, u které bude předána, s ohledem na objektivní skutečnosti, její rozpracovaná verze.
Úspěšná realizace této Fáze 1 je podmínkou pro zahájení Fáze 2.
3.1.3. Fáze 2 – Integrace BI platformy, naplnění sémantické datové vrstvy BI platformy daty z katalogu EAP a realizace typových úloh
V rámci této Fáze Dodavatel zajistí:
1. Realizaci integrací BI platformy prostřednictvím nativního API či vyvinutých konektorů
Dodavatelem BI platformy s:
a. EAP (Elasticsearch a CKAN);
b. LDAP MŽP, LDAP CENIA;
c. Portál STaR – API pro publikaci;
d. Případně další integrace dle Katalogu požadavků a požadavků níže uvedených typových úloh (např. databáze, externí API).
2. Realizaci ETL procedur pro naplnění sémantické datové vrstvy BI platformy iniciálními sadami dat z platformy EAP – jedná se o ETL procedury pro data z EAP /realizovaný v CKAN/ pro definované vyčištěné datové sady připravené a zpracované Objednatelem/CENIA (cca 200
.CSV14 /a jejich metadata a datové slovníky/šablony/ souborů dostupných přes neveřejné URL linky/složky z katalogu CKAN). Soubory .CSV budou všechny načteny do sémantické datové vrstvy BI platformy tak, jak jsou uloženy v CKAN. ETL procedury musí být nastaveny tak, aby je bylo možné spouštět opakovaně a automatizovaně v případě přírůstku obsahu v URL složce CKAN.
a. Iniciální nastavení (parametrizace) řešení v souladu s požadavky zadání, tj. např. nastavení správy/katalogu ETL procedur z datových sad z katalogu EAP, nastavení oprávnění, nastavení možností automatizované aktualizace, evidence, zdokumentování atp.
b. Výsledkem bude konsolidovaná sémantická datová vrstva umožňující prohledávání
a tvorbu nezbytných vizualizací.
c. Požadavkem na ETL procedur je jejich univerzální použití tedy opakovatelné spuštění a ukládání do datové vrstvy v případě požadavku na aktualizaci – tj. připravenost na to, že se změní stav datových sad v úložišti EAP – nový soubor v datové složce EAP nebo nová verze souboru – rozšířený datový obsah.
d. V Etapě 2 plnění Smlouvy, budou vznikat v CKAN nové datové sady a přibývat jiné datové zdroje s unikátní strukturou a obsahem. Jejich zpracování – konfiguraci ETL bude provádět Objednatel anebo Dodavatel v souladu s provozní službou BI_08 - Služby vývoje (datových transformací, reportovacích modelů, sestav, dashbordů) na objednávku.
3. Po (anebo souběžně s) naplnění sémantické datové vrstvy realizuje Dodavatel typové úlohy
v rozsahu stanoveném v příloze č. 5 této Specifikace, tj. zajistí realizaci:
1. Typové úlohy č. 1 - Indikátor z tématu Voda;
2. Typové úlohy č. 2 – Indikátory z tématu Lesy;
3. Typové úlohy č. 3 – Zpracování, vizualizace dat a automatizace z RDMS (Relational
Database Management System) MA ISOH (Úloha autovraky);
14 Jejich „off-line“ vzorek viz Příloha č. 5 této Specifikace.
4. Typové úlohy č. 4 – Zpracování, obohacení, vizualizace dat a automatizována aktualizace primárních dat z (Integrovaný registr znečišťování /IRZ/ + Informační systém integrované prevence /IPPC/), Elasticsearch a SOAP služeb.
4. Úspěšná realizace této Fáze 2 bude potvrzena testováním na straně Objednatele. Pro tyto účely musí být řešení z funkčního hlediska kompletní, tj. musí být dokončena Fáze 1 a k dispozici musí být úplné a konzistentní datové sady v EAP v rozsahu dle naplněnosti EAP min. však tak, aby bylo možné prostřednictví řešení vytvořit všechny výstupy pro Zprávu 2018. Po celou dobu testování bude Objednateli k dispozici pracovník Dodavatele, mající kompetence a oprávnění poskytovat Objednateli informace týkající se uložených dat. Tento pracovník bude neprodleně zajišťovat Objednatelem požadované informace týkající se dat i nad rámec funkcionalit obsažených v řešení (např. různé kontrolní součty a agregované informace o uložených datech, prezentaci pravidel datové kvality atd.). V případě identifikace jakýchkoliv nesouladů v datech nebo nastavení nástroje musí být tyto odstraněny a předloženy k opakovanému testování Objednatelem.
Úspěšná realizace této Fáze je podmínkou pro zahájení Fáze 4.
3.1.4. Fáze 3 – Školení koncových uživatelů a administrátorů
Účelem této Fáze, která je částečně časově souběžná s Fázemi 2 a 4, je zejména zaškolení vybraných pracovníků Objednatele a zabezpečení školícího procesu jednotlivých úrovní uživatelů systému v jednotlivých rolích. Dodavatel zajistí níže stanovený počet školení v prostorách Objednatele případně dalších prostorách určených Objednatelem.
Potvrzení Objednatele o provedení školení uživatelů je nezbytnou podmínkou k Akceptaci Díla.
V rámci této fáze Dodavatel zajistí pro nástroje BI platformy:
1. Školení pro min. 5 vybraných Koncových uživatelů a alespoň 5 pokročilých uživatelů (též
„Datový analytik/Power user“, „Tvůrce sestav“ a „Redaktor vnitřního portálu BI platformy“) pro potřebu zahájením Fáze 4 - pilotního provozu (musí být realizováno před zahájením pilotního provozu).
2. Školení pro 20 Koncových uživatelů - ovládání a užití sestav a dashboardů;
3. Školení pro 3 Správce systému (též „superuser/root“);
4. Školení pro 20 pokročilých uživatelů - zpracovatelů výstupů/sestav a dashboardů, kteří zajišťují rovněž publikaci výstupů/sestav;
Potvrzení Objednatele o provedení školení uživatelů je nezbytnou podmínkou k Akceptaci Díla. Stanovení výsledného počtu a jmenovité obsazení účastníků školení je přípustné Objednatelem pozměnit.
Dále následují požadavky na proškolení jednotlivých kategorií uživatelů. Objednatel je oprávněn pozměnit obsah školení dle aktuálních potřeb před zahájením jednotlivých běhů školení.
Ad1) Školení Koncových a pokročilých uživatelů pro potřebu pilotního provozu
Pro potřeby pilotního provozu zajistí Dodavatel proškolení uživatelů MŽP/CENIA.
Obsah školení:
Školení pro potřebu pilotního provozu bude zaměřeno na používání sémantické datové vrstvy, reportovacího modelu, vizualizačních nástrojů a nástrojů pro tvorbu BI výstupů.
Školení musí dále obsahovat:
- způsob používání (ovládání) BI platformy,
- vyhledávání a statisticko-analytické funkce v BI platformě,
- integrace BI platformy na zdroje dat případně okolní informační systémy,
- možnosti customizovatelnosti funkcionalit BI platformy (uživatelský pohled),
- pravidla pro realizaci změnových požadavků,
- rozsah a způsob používání uživatelské podpory,
- specifickou část školení zaměřenou na přípravu dat a tvorbu sestav a dashboardů pracovníky MŽP/CENIA.
Časový rozsah a místo školení:
Časová dotace: 8 hodin výuky pro Koncové uživatele, 8 hodin pro pokročilé uživatele Školení proběhne v sídle MŽP, proškoleno bude celkem 10 osob.
Všichni Koncoví uživatelé BI platformy (pro potřeby pilotního ověření), musí být proškoleni nejpozději do spuštění pilotního provozu.
Technické zajištění školení:
Dodavatel zajistí pro každý běh školení vlastní dataprojektor; Objednatel zajistí PC a případně další technické prostředky nezbytné pro praktickou ukázku práce s nástroji BI platformy dle předchozí specifikace Dodavatele. Dodavatel dále poskytne všem proškolovaným osobám elektronické, případně i tištěné materiály školení (prezentaci).
Ad 2) Školení Koncových uživatelů
Dodavatel zajistí úvodní proškolení Koncových uživatelů. Formát školení
Výuka s využitím PC. Každé školení bude vždy obsahovat:
- Základní teoretickou část (seznámení s architekturou a funkcionalitou BI platformy, formou prezentace);
- praktickou část (účastníci školení budou mít možnost vyzkoušet jednotlivé funkcionality BI platformy prezentační vrstvy na PC).
Obsah školení
Po obsahové stránce bude školení členěno na základní a specifickou část.
Základní teoretická část školení bude zaměřena na představení systému, popis základní práce se systémem a představení základních průřezových funkcionalit, jako např. vyhledání příslušné sestavy, ovládání sestav, filtrování, práce s tabulkami, dril-down apod.).
Obsah specifické části školení se bude dále odvíjet od typových úkonů/operací Koncových uživatelů
v BI platformě.
Školení Koncových uživatelů bude Dodavatelem poskytováno ve 2 částech:
- Úvodní část školení (začátečník);
- Specializační část školení.
Časový rozsah a místo školení:
Časová dotace: 12 hodin výuky
Úvodní část školení (tj. úroveň začátečník, v rozsahu 4 hodin výuky s přestávkou na občerstvení/oběd) seznámí uživatele se základy práce s BI výstupy a s vizualizačními nástroji BI platformy.
Specializační část školení (v rozsahu 8 hodin výuky s přestávkou na oběd a občerstvení) je určena pro uživatele, kteří již absolvovali úvodní část školení a jejím cílem je seznámit tyto uživatele s pokročilými funkcemi BI platformy, tvorbou vlastních sestav a výstupů a s jejich využitím v průběhu tvorby textových výstupů (reportů/zpráv).
Technické zajištění školení
Dodavatel zajistí pro každý běh školení vlastní dataprojektor, PC pro školitele a případně další technické prostředky nezbytné pro praktickou ukázku práce s nástroji BI platformy. PC pro účastníky školení zajistí Objednatel (SW vybavení musí Dodavatel písemně sdělit Objednateli minimálně 10 pracovních dnů před konáním školení). Dodavatel dále poskytne všem proškolovaným osobám elektronické, případně i tištěné materiály školení (prezentaci).
Počet účastníků pro jeden běh školení
Maximální počet účastníků 1 školení je 20 osob, maximální počet osob využívajících 1 PC
s instalovaným SW pro praktickou část školení, jsou 2 osoby.
Harmonogram školení
Dodavatel navrhne Objednateli termíny, místo a počet proškolovaných osob pro zajištění úvodního proškolení Koncových uživatelů (harmonogram školení). Harmonogram školení musí být ze strany Objednatele nejprve odsouhlasen a poté může být zahájena organizace jednotlivých školení. Prostory a infrastrukturu pro jednotlivá školení s možností připojení k internetu budou poskytnuty MŽP bezplatně. Součinnost při rezervaci zasedacích místností zajistí Objednatel, zastoupený odborem informatiky MŽP.
Dodavatel musí zajistit proškolení Koncových uživatelů nejpozději 20 dnů před zahájením ostrého
provozu.
Ad 3) Školení Správců systému a pokročilých uživatelů
Před nasazením Díla do ostrého provozu zajistí Dodavatel proškolení Správců systému MŽP/CENIA, a to ve dvou úrovních – školení technologických administrátorů (správce systému/superuser/root) a power userů (obsahových administrátorů).
I. Školení Správců systému (též označovaných jako superuser nebo root)
Obsah školení
Školení musí obsahovat minimálně:
- charakteristiku SW a HW architektury BI platformy,
- možnosti customizace funkcionalit nástrojů BI platformy (administrátorský pohled),
- rozsah a způsob používání údržby a uživatelské a technické podpory (úrovně technické podpory, role a součinnost jednotlivých subjektů při poskytování technické podpory),
- metodiku řízení údržby a technické podpory obsahující zejména postupy pro přijetí, zpracování, analytiku, rozpoznávání chyb a předání (eskalace) k řešení u požadavků na technickou podporu (tzv. trouble tickets),
- integrace nástrojů BI platformy na okolní informační systémy (technologický aspekt),
- způsob provádění monitoringu nástrojů BI platformy,
- pravidla pro předávání/přebírání realizovaných změnových požadavků do provozu (release
management),
- zálohování a obnova vybraných částí BI platformy;
- podporu bezpečnosti a report incidentů, logy apod.
Časový rozsah a místo školení:
Časová dotace: 12 hodin výuky Počet účastníků školení:
Školení proběhne v sídle MŽP, budou proškoleny celkem 3 osoby.
Všichni Správci systému BI platformy musí být proškoleni nejpozději do 30 dní před zahájením ostrého
provozu.
Technické zajištění školení:
Dodavatel zajistí pro každý běh školení vlastní dataprojektor, bude specifikovat potřebná PC a případně další technické prostředky nezbytné pro praktickou ukázku práce s BI platformou, které zajistí Objednatel, a to vždy dle počtu proškolovaných osob a kapacity zasedací místnosti. Dodavatel dále poskytne všem proškolovaným osobám elektronické, případně i tištěné materiály školení (prezentaci).
II. Školení Power userů (též označovaných jako obsahoví administrátoři v rolích „Datový analytik/Power user“, „Tvůrce sestav“, „Redaktor vnitřního portálu BI platformy“)
Školení musí obsahovat minimálně:
- Základní charakteristiku SW a Technologické platformy Díla,
- možnosti customizace funkcionalit BI platformy (administrátorský pohled);
- přidělování přístupových oprávnění;
- konfigurace funkcí pro jednotlivé skupiny uživatelů;
- nahlížení nad daty v rámci jednotlivých agend;
- typové BI úlohy.
Časový rozsah a místo školení:
Časová dotace: 16 hodin výuky Počet účastníků školení:
Školení proběhne v sídle MŽP, bude proškoleno celkem 20 osob.
Uživatelé úrovně Power user BI platformy musí být proškoleni nejpozději do 20 dní před spuštěním ostrého provozu.
Technické zajištění školení:
Dodavatel zajistí pro každý běh školení vlastní dataprojektor, bude specifikovat potřebná PC a případně další technické prostředky nezbytné pro praktickou ukázku práce s BI platformy, které zajistí Objednatel, a to vždy dle počtu proškolovaných osob a kapacity zasedací místnosti. Dodavatel dále poskytne všem proškolovaným osobám elektronické, případně i tištěné materiály školení (prezentaci).
3.1.5. Fáze 4 – Pilotní provoz - úplné ověření parametrů řešení a předání Díla včetně licencí do řádného provozu
V rámci této Fáze Dodavatel zajistí pilotní provoz BI platformy (obohacené o výstupy, data a integrace z Fáze 2) včetně opakovaného použití předpřipravených typových úloh a podporu Objednateli při realizaci jeho vlastních úloh. Pilotní provoz bude realizován pro okruh osob a subjektů stanovených Objednatelem. V rámci pilotního provozu budou moci uživatelé plně využívat BI platformu a v ní uložená data, skripty a integrace vytvořené ve Fázi 2, které budou nasazeny v testovacím prostředí. Ve Fázi pilotního provozu zajistí Dodavatel provozní zajištění odpovídající parametrům řádného provozu (viz požadavky na zajištění vybraných Provozních služeb).
Účelem pilotního provozu je zejména:
▪ Uživatelské odladění služeb a nastavení metodiky správce platformy a nástrojů BI platformy;
▪ Odstranění drobných vad identifikovaných v předešlých Fázích a vad identifikovaných v rámci akceptačních testů realizovaných v rámci pilotního provozu;
V rámci této Fáze proběhne také:
▪ Realizace akceptačních testů, tj. ověření souladu celého řešení s požadavky zadání v cílovém provozním prostředí pro provoz. Ve Fázi pilotního provozu budou provedeny funkční, integrační, bezpečnostní a zátěžové testy;
▪ Předání Díla a všech jeho součástí Objednateli a příprava na zahájení ostrého provozu, tj:
o Předání kompletních Zdrojových kódů a konfiguračních souborů ke všem součástem Díla vyvinutým Dodavatelem (nikoliv ke standardním SW produktům, které jsou
využity pro realizace Díla dle Smlouvy), včetně autorských práv (licence) v rozsahu umožňujícím Objednateli provádět libovolné změny v tomto kódu a konfiguračních souborech tak, aby Dílo mohlo být řádně používáno bez závislosti na Dodavateli. Dodavatel je povinen udělit Objednateli výhradní licenci k typovým úlohám, což představuje například kódy ETL procedur, definice výpočtů ukazatelů a indikátorů a jakýmkoliv dalším částem vyvinutým na zakázku (tj. nikoliv ke standardizovaným SW, na kterých je BI platforma založena), příp. udělit další nezbytné licence. Zdrojové kódy a konfigurační soubory předá Dodavatel Objednateli při předání kompletního Díla (před tímto předáním se přístup Objednatele ke Zdrojovým kódům řídí požadavkem na vlastnosti „BI-16-2 Přístup k aktuálním zdrojovým kódům“ – viz Katalog požadavků v příloze č. 1 této Specifikace).
Pilotní provoz potrvá alespoň 1 měsíc. V případě, že bude v rámci pilotního provozu odhalena závažná vada (tj. Vada Kategorie „Havárie“ – viz dále), bude pilotní provoz přerušen až do jejího odstranění a následně prodloužen o takový časový úsek, který umožňuje opakované ověření všech parametrů řešení, které mohly být opravou Vady zasaženy.
Závěr Fáze 4 je vyhrazen pro akceptační testování celého Díla, v rámci něhož Objednatel ověří shodu nástroje BI platformy oproti všem požadavkům Smlouvy a potvrdí akceptaci Díla jako celku, a to dle pravidel uvedených ve Smlouvě a dohodnutých akceptačních scénářů. Dodavatel připraví finální verzi akceptačních scénářů ověřujících požadavky Katalogu požadavků, jejich upřesnění z Fáze Zpracování IT analýzy v dostatečném předstihu tak, aby akceptační scénáře byly schváleny nejpozději 10 dní před koncem Fáze 4. V případě souhlasu či na žádost Objednatele Dodavatel může akceptační scénáře upravit, zejména v souvislosti se zkušenostmi z pilotního provozu. Finální verze akceptačních scénářů musí být Objednateli předána k akceptaci nejpozději 15 kalendářních dní před zahájením akceptačního testování Díla.
Bezprostředně po Akceptaci Díla připraví Dodavatel Dílo pro zahájení ostrého provozu, tj. ke dni
následujícím po akceptaci Díla.
K danému datu bude pokynem Objednatele zahájen ostrý provoz. Ke dnu následujícím po Akceptaci
Díla dojde k zahájení poskytování všech dalších Provozních služeb.
3.2. Zajištění vybraných provozních služeb
Dodavatel bude poskytovat Objednateli níže určené Provozní služby v souladu s pravidly ITIL nebo adekvátním metodologickým rámcem, a to jak ve vztahu k Dílu jako celku, tak ke každému jednotlivému dodanému dílčímu plnění a Verzi Díla. Provozní služby budou poskytovány průběžně po dobu trvání Smlouvy, která se ve vztahu k zajištění Provozních služeb uzavírá na dobu neurčitou. Počátkem poskytování Provozních služeb je den následující po Akceptaci Díla.
Dodavatel bude zajišťovat vybrané Provozní služby nad BI platformou a jeho SW infrastrukturou. V případě SW platformy Díla zajišťuje Dodavatel Provozní služby od virtualizačního SW (WM Ware) výše. Provoz Technologické platformy (HW, síťové infrastruktury a virtualizačního SW) zajišťuje Objednatel, a to i v případě Přesunu Díla.
Objednatel bude:
• Spravovat HW infrastrukturu - Provozní služby nad HW infrastrukturou a síťovými prvky;
• Spravovat virtualizační prostředí (WMVare), zajišťovat jeho licence a řešit incidenty
na virtualizační platformě;
• Po dohodě a ve spolupráci s Dodavatelem zajišťovat aktualizace/patchování OS;
• Po dohodě a ve spolupráci s Dodavatelem řešit potřebné rekonfigurace/nastavení operačního systému;
• Provádět, na úrovni operačního systému, zálohování Serverů (aplikačního, databázového)
a databází, dle Dodavatelem dodané Dokumentace - zálohovacího plánu.
Aplikační správu dodaného řešení (tj. Díla), resp. jeho standardní údržbu na úrovni „nad virtualizačním prostředím“, bude provádět Dodavatel.
Struktura celého dodaného řešení musí být taková, aby byly odděleny jednotlivé serverové instance a vlastní data tak, aby bylo možné zálohovat s rozdílnou četností jednotlivé serverové instance a s jinou vlastní data.
V případě havárie a potřebné obnovy provozu (serverů, nastavení, databází, dat) musí být tato obnova realizovatelná Objednatelem, bez nutné přímé spolupráce s Dodavatelem, a to na základě Dodavatelem dodaného dokumentu "Postup při obnově provozu". V případě nekompletní nebo neaktualizované verze tohoto dokumentu a nemožnosti, ze strany Objednatele, obnovení provozu, jdou veškeré náklady Dodavatele, spojené s touto obnovou, na vrub Dodavatele.
Dodavatel bude zajišťovat následující Provozní služby:
1. Provozní služby hrazené paušálními ročními platbami:15
a. Řízení dostupnosti BI platformy a provozní monitoring;
b. Zajištění služeb servisdesku a hot-line pro Objednatele;
c. Paušální správa aktiv, konfigurací a maintenance;
d. Řízení incidentů;
2. Provozní služby hrazené za odvedené výkony:
a. Konzultace;
b. Řízené ukončení provozních služeb (Exit strategie);
c. Školení na objednávku;
d. Služby vývoje (datových transformací, reportovacích modelů, sestav, dashbordů)
na objednávku.
Zbylé Provozní služby zajišťuje Objednatel a odpovídá za dodržení takové úrovně Provozních služeb,
aby Dodavatel byl schopen dodržet v Katalogových listech Provozních služeb stanovená SLA.
Objednatel je oprávněn pověřit provozem (obsluhou/administrací) Díla třetí osobu (např. CENIA). Dodavatel je povinen v takovém případě této osobě poskytovat všechny Provozní služby a související
15 S pololetní fakturací ve výši poloviny paušálu (vis Smlouva).
dodávky dle Smlouvy. V souvislosti s tím vzniknou interní pravidla Objednatele rozdělující kompetence, smluvní práva a povinnosti mezi Objednavatele, pověřenou osobu a Dodavatele.
3.2.1. Provozní Služby hrazené paušálními platbami
Následují Katalogové listy pro Provozní služby (dále jen “Služba” či “Služby”), které bude Dodavatel
zajišťovat.
3.2.1.1. BI_01 - Řízení dostupnosti BI platformy a provozní monitoring
Katalogový list Služby | |
Identifikace (ID) | BI_01 |
Název Služby | „Řízení dostupnosti BI platformy a provozní monitoring“ |
Popis Služby | Tato Služba zahrnuje především, nikoliv však výlučně, následující činnosti: • garance dostupnosti BI platformy dle KPI_01. Dodavatel negarantuje dostupnost Technologické platformy, tj. odpovídá za dostupnost BI platformy za předpokladu, že Dodavatel neprokáže, že nedostupnost BI platformy je způsobena nedostupností služeb Technologické platformy, kterou ve stanoveném SLA zajišťuje Objednatel nebo že nedostupnost je způsobena vadou v integrovaného SW třetí strany, jejíž odstranění není v moci Dodavatele. Součástí garance Dodavatele je i garance za standardizovaný SW, resp. funkčnost SW platformy Díla. • monitoring (ne)dostupnosti BI platformy. |
Parametry | |
Kalendář Služby | KPI_01: 24x7 |
KPI | KPI_01: Dostupnost BI platformy je v Garantovaném pásmu 95 % a negarantovaném pásmu 80 %. Doba nedostupnosti BI platformy způsobená nedostupností služeb infrastruktury, kterou ve stanoveném SLA zajišťuje Objednatel, se do KPI_01 nezapočítává. 5x9 95 % v pracovních dnech 8:00 – 16:59 pro načítání dat ze zdrojových systémů (ETL), tvorbu a publikaci modelů, sestav a dashboardů. |
Měřící bod | Pololetní Výkaz KL BI_01. |
Sankce | KPI_01: Pro Garantované pásmo: Dostupnost BI platformy >=95 %: • Byla-li dostupnost v intervalu >=95 % v Garantovaném pásmu 9x5 v daném Měřícím období, na nedostupnost se nevztahuje žádná sankce. Dostupnost BI platformy 94,99–90 %: • Byla-li dostupnost v intervalu 94,99–90 % v Garantovaném pásmu 9x5 v daném Měřícím |
období, je pro dané Měřící období vyměřena Dodavateli jednorázová sankce ve výši 5.000 Kč. Dostupnost BI platformy <90 %: • Byla-li dostupnost <90 % v Garantovaném pásmu 9x5 v daném Měřícím období, je pro dané Měřící období vyměřena Dodavateli jednorázová sankce ve výši 10.000 Kč. Pro negarantované pásmo: Dostupnost BI platformy <80 %: Byla-li nedostupnost vyšší než 20 % v negarantovaném pásmu v daném Měřícím období, je pro dané Měřící období vyměřena Dodavateli jednorázová sankce ve výši 10.000 Kč. V případě trvajícího porušení KPI_01 přesahujícího 180 minut v kuse v rámci Garantovaného pásma se tento stav zároveň považuje za 1 souvislý Incident s prioritou – Havárie a zároveň je automatizovaně/bezodkladně nahlášen do Servisdesku. Pro výpočet sankcí se nezapočítávají všechny časy ve stanoveném Měřícím období, které byly vyhrazeny pro plánovanou (tj. dohodnutou) servisní odstávku BI platformy (tedy Servisní okno), byly způsobeny zásahem nebo na straně Objednatele (např. síťová konektivita a nastavení, výpadek HW infrastruktury zajišťované Objednatelem atp.) nebo vyšší mocí. Stejně tak se nezapočítává čas pro provedení Služby „Přesun Díla“ (viz KL BI_10), a to v rámci schváleného závazného harmonogramu pro Přesun Díla (doba nad rámec závazného harmonogramu se již započítává). Zdůvodnění nezahrnutí nedostupnosti do výpočtu sankcí v těchto případech zdůvodňuje Dodavatel a uvádí jej v Pololetním Výkazu Služby „Řízení dostupnosti aplikace a provozní monitoring“. | |
Způsob dokladování | Provozní deník. Pololetní Výkaz KL BI_01 se základní informací o provozu a dostupnosti BI platformy dle KPI_01 (graf z monitoringu, resp. statistika dostupnosti BI platformy z monitorovací (testovací) aplikace Dodavatele). |
Poznámky | Sledování (ne)dostupnosti BI platformy bude prováděno prostřednictvím monitorovací (testovací) aplikace Dodavatele. Dodavatel umožní Objednateli bezplatně průběžný monitoring Díla v reálném čase prostřednictvím dálkového přístupu a monitorovací (testovací) aplikace Objednatele nebo třetí strany. Monitorovací aplikace Dodavatele vykonává end-to-end testovací scénář ověřující dostupnosti webových aplikací/služeb BI platformy v intervalech jednou za 10 min. Monitorovací aplikaci Dodavatel nasadí ke dni zahájení pilotního provozu (Fáze 4). Pokud kterýkoliv z dílčích úloh (kroků) testovacího scénáře nevrátí korektní výsledek anebo překročí-li doba odezvy kteréhokoliv kroku 2 min., a to ve dvou po sobě jdoucích průchodech testovacím scénářem, je stav vyhodnocen jako nedostupnost Díla po dobu od zahájení prvního testovacího scénáře do doby ukončení druhého testovacího scénáře prokazujícího nedostupnost BI platformy. Ukončení nedostupnosti je dáno časem prvního nechybového průchodu testovacího scénáře. Monitorovací aplikace kromě výše uvedeného musí být schopna také monitorovat cloudovou |
platformu, a to minimálně tyto výkonové parametry: • objem datového toku do/z Aplikace, • vytížení CPU, • vytížení RAM, • odezva a kapacita HDD, • Up-Time. V případě nutnosti umožní (tj. zajistí nezbytnou součinnost třetích stran) Objednatel Dodavateli (nebo třetí straně poskytující služby monitoringu) instalaci monitorovacího zařízení či aplikace v prostředí cloudu. Dodavatel je povinen mít zpracovány scénáře obnovy v souladu se službou Service Continuity Management dle ITILv3 či jiné srovnatelné mezinárodně uznávané normy a provádět pravidelné testy (alespoň 1x ročně) dle takto zpracovaných scénářů obnovy. Objednatel může požadovat po Dodavateli předložení dokladů o provedeném testování. | |
Platební podmínky | Součást paušální roční sazby dle odst. 10.1 Smlouvy. |
3.2.1.2. BI_02 - Servisdesk, hot-line pro Objednatele
Katalogový list Služby | |
Identifikace (ID) | BI_02 |
Název Služby | „Servisdesk, hot-line pro Objednatele“ |
Popis Služby | Provoz webové aplikace pro zadávání Incidentů a požadavků v prostředí sítě Internet a hot-line telefonní linky. Servisdesk není součástí Díla. Služba hot-line je zajišťována výhradně pro až 5 kontaktních osob Objednatele (tj. pro účely kontaktování Dodavatele Objednatelem za účelem řešení událostí). Koncoví uživatelé nemají do Servisdesk přímý přístup, ale mohou generovat ticket do Servisdesk přímo z BI platformy (viz požadavek „BI-16-4 Generování ticketu do Servisdesku přímo z BI platformy (vazba na Servisdesk dodavatele)“) či zaslat svůj požadavek e-mailem na Dodavatelem určenou adresu a požadavek vloží do Servisdesk Dodavatel. Tato Služba zahrnuje: • Zabezpečení bezvýpadkového provozu servisdeskové aplikace pro sběr a vyhodnocování uživatelských tiketů (dostupnost 95 % měsíčně); • Technické zajištění funkčnosti min. 1 garantované telefonní linky [x000 000 000 000] v režimu 9x5. |
Parametry | |
Kalendář Služby | Technická dostupnost Servisdesk: 24x7 Lhůta pro odpověď: 9x5 |
KPI | KPI_03: Dostupnost Servisdesku (webové aplikace) s akceptovatelným výpadkem nepřesahujícím 60 po sobě jdoucích minut v Garantovaném pásmu anebo KPI_04: Kumulovaná nedostupnost Servisdesku během měsíčního období menší než 5 % (čili |
dostupnost 95 %). | |
Měřící bod | Servisdesk, výpis z monitoringu dostupnosti Služby „Servisdesk, hot-line pro Objednatele“. |
Sankce | Při porušení KPI_03 a/nebo KPI_04 je uplatněna jednorázová sankce ve výši 1.000 Kč za každý takový případ. |
Způsob dokladování | Pololetní Výkaz KL BI_02 se základní informací o provozu a dostupnosti Služby „Servisdesk, hot- line pro Objednatele“ dle KPI_03 a KPI_04 (graf z monitoringu, resp. statistika dostupnosti Servisdesku z monitorovacího nástroje Dodavatele). Zpracování výkazů je součástí paušální roční sazby dle odst. 10.1 Smlouvy BI_03). |
Poznámky | Služba „Servisdesk, hot-line pro Objednatele“ je sdílenou službou pro ostatní služby Zajištění vybraných provozních služeb. |
Platební podmínky | Součást paušální roční sazby dle odst. 10.1 Smlouvy. |
3.2.1.3. BI_03 – Paušální správa aktiv, konfigurací A MAINTENANCE
Katalogový list Služby | |
Identifikace (ID) | BI_03 |
Název Služby | „Paušální správa aktiv, konfigurací a maintenance“ |
Popis Služby | Tato Služba zahrnuje především, nikoliv však výlučně, následující činnosti: • správa, dohled a podpora BI platformy; • zajištění technické podpory spočívající v zajištění podpory a údržby licencí standardních SW produktů použitých při realizaci (a následném užití) Díla a poskytnutí podpory Objednateli při smluvních jednáních o podpoře a údržbě licencí SW produktů s jejich původcem, tj. nákup a zajištění veškerých služeb, technologií, licencí, maintenance a SW nezbytných k provozu Díla v místě instalace; • sledování znalostní báze výrobců jednotlivých SW komponent, vyhledávání a implementace vhodných oprav, konfigurace SW, údržba, podpora a aktualizace SW (minoritní i majoritní aktualizace); • aktivní vyhledání a identifikace oprav, bezpečnostních záplat, patchů, hotfixů, nebo servicepacků včetně jejich vývoje/stažení, uložení a instalace; • profylaxi všech SW infrastrukturních prvků v souladu s pokyny dodavatelů jednotlivých prvků SW infrastruktury; • uchovávání, verzování a zpřístupnění dokumentace ve správě Dodavatele, včetně dokumentace jím vytvořené. Dodavatel zpřístupní dokumentaci dle pokynů Objednatele; • uchovávání, verzování a zpřístupnění informací o konfiguračních jednotkách ve správě Dodavatele a jejich konfiguracích. Dodavatel zpřístupní informace dle pokynů Objednatele; |
• plánovaní, načasovaní a řízení sestavení, testování a nasazení releasů tak, aby byla maximálně chráněna integrita stávajících služeb; • nasazení veškerých nových verzí datových modelů, statistických a analytických výstupů, sestav a dashboardů implementovaných Dodavatelem, nebo nových verzí, patchů, hotfixů, service packů a dalších opravných balíků výrobců SW nebo HW. Nasazení releasu může být různě robustní a Dodavatel musí robustnost nastaveného přístupu uzpůsobit v závislosti na předmětu nasazení (od parametrické změny, po novou verzi některé z realizovaných úloh); • instalace, aktualizace či rekonfigurace SW i na vyžádání Objednatelem; • garance dodávky a provádění instalace nových verzí SW BI platformy (po vydání jejich autorem/komunitou); • exporty dat a metadat vedených v SW, které nebudou dostupné Objednateli (nebo administrovatelné Objednatelem) přes aplikační prostředí BI platformy na jeho vyžádání ve strojově čitelném formátu (např. .CSV, .JSON atp.); • vedení on-line Provozního deníku s dálkovým přístupem Objednateli; • provedení profylaxe (1x ročně); • zpracování plánů aktualizace (1x ročně) - Dodavatel je povinen pravidelně, nejméně 1x ročně, pokud nebude dohodnuto jinak, předkládat Objednateli návrh plánu aktualizace (Upgrade/Update) Díla k odsouhlasení. Neurčí-li Objednatel jinak, či ze schváleného plánu aktualizace nevyplyne, zavazuje se Dodavatel zajišťovat průběžnou aktualizaci Díla tak, aby Dílo řádně fungovalo i po případné změně jakékoli části SW platformy Díla či Technologické platformy objednatele, na které je Dílo provozováno. • Zpracování výkazů k fakturaci pro ostatní Provozní služby. Dodavatel je povinen hlásit Objednateli všechny plánované zásahy do Díla nebo odstávky Díla související s jeho údržbou nebo nasazováním Upgradů a Updatů do provozu, přičemž k zásahu do Díla nebo odstávce Díla je nutný souhlas Objednatele. Dodavatel informuje kontaktní osoby Objednatele zejména o odstavení a opětovném zprovoznění Díla, a to v souladu s plánem aktualizace, v případě neplánovaného odstavení Díla informuje bezodkladně, a to těsně před jeho odstavením a znovu zprovozněním. Veškeré zásahy do Díla v rámci provozní podpory Díla budou prováděny pomocí zvláště k tomuto účelu přiděleného účtu. Dodavatel nesmí používat administrátorské účty Objednatele pro ladění a zkoušení funkčnosti Díla. Pro účely ladění a zkoušení funkčnosti Díla budou vyhrazeny speciální účty (plán). Testování musí být prováděno v testovacím prostředí odděleném od produkčního prostředí. Dodavatel ani poddodavatel Dodavatele nesmí zasahovat do obsahu dat zpracovávaných za pomoci Díla, jakýchkoliv dat Objednatele ani provést zásah, který by ovlivnil či mohl ovlivnit funkcionalitu hardware či jiného software (odlišného od Díla) provozovaného v místě instalace nebo pracovních stanic uživatelů systému připojených k Dílu prostřednictvím Internetu. | |
Parametry | |
Kalendář Služby | KPI_05: 9x5 |
KPI | KPI_05: Záznamy v Provozním deníku související se Službou BI_03 - Paušální správa aktiv, konfigurací a maintenance (zejména datování konfiguračních, implementačních úkonů |
a jejich stručný popis) do konce následujícího BD. | |
Měřící bod | Provozní deník. Pololetní Výkaz KL BI_03. |
Sankce | KPI_05: Porušení řádného a průběžného vedení Provozního deníku neodpovídajícího skutečnosti vede k uplatnění sankce ve výši 2.000 Kč za každý takový případ pro dané Měřící období. Porušení povinnosti aktualizovat SW platformu vede k uplatnění sankce ve výši 20.000 Kč za každý takový případ pro dané Měřící období. Nepředložení plánu aktualizace (Upgrade/Update) BI platformy do 30.06. daného kalendářního roku (nebo nedodržení jiného termínu dle dohody s Objednatelem) či neprovedení profylaxe minimálně jeden krát ročně (nejpozději 31. 12. daného kalendářního roku) vede k uplatnění sankce ve výši 20.000 Kč za každý takový případ. |
Způsob dokladování | Provozní deník. Pololetní Výkaz KL BI_03 se základní statistikou (počet) úkonů v Provozním deníku a informacemi o úspěšném vyřešení požadavků (na vyžádání) Objednatele. Zpracování výkazů je součástí paušální roční sazby dle odst. 10.1 Smlouvy BI_03. Plán aktualizace. Zpráva z provedení profylaxe. |
Poznámky | Dodavatel je povinen pravidelně, nejméně jedenkrát ročně (vždy k 30. 06. daného kalendářního roku, nebude-li dohodnuto s Objednatelem jinak), předkládat Objednateli návrh plánu aktualizace SW platformy k odsouhlasení. Povinností Dodavatele je dále aktualizovat SW platformu (tj. standardizované SW/SW 3. stran v rámci BI platformy), pokud Objednatel bude mít aktivní smlouvu o maintenance. To musí být uskutečněno nejpozději do 6 měsíců od okamžiku, kdy výrobce SW platformy vydá příslušnou změnu (Update) SW platformy ve finální (stabilní) verzi, nebude-li s Oprávněnou osobou Objednatele v technických záležitostech dohodnuto jinak. Dodavatel nejdříve svůj záměr provést Update SW platformy konzultuje s Oprávněnou osobou Objednatele v technických záležitostech. Změnou SW platformy se rozumí libovolné formy oprav programového vybavení, vydávané výrobcem/ci SW platformy zpravidla za účelem odstranění chyb této SW platformy nebo zlepšení její funkce. Povinností Dodavatele je tyto změny sledovat a průběžně o těchto změnách informovat oprávněnou osobu Objednatele v technických záležitostech. Instalaci bezpečnostního patche/hotfixu/servispacku SW platformy provádí Dodavatel v návaznosti na objevenou kritickou bezpečnostní hrozbu komponenty SW platformy bezodkladně po vydání tohoto patche/hotfixu/servispacku výrobcem SW platformy. Tuto instalaci provede Dodavatel nejpozději do konce následujícího BD, pokud nebude s oprávněnou osobou Objednatele v technických záležitostech dohodnuto jinak. Před aktualizací SW platformy musí vždy proběhnout ověření kompatibility aktualizovaného prvku SW platformy s ostatními prvky a s vlastními programovými komponentami BI platformy na testovacím prostředí BI platformy. Pokud se v tomto ověření vyskytnou chyby způsobené nekompatibilitou mezi SW platformou a moduly BI platformy, aktualizace SW BI platformy na produkčním prostředí nemůže být provedena a Dodavatel musí provést v přiměřené době úpravy v BI platformě tak, aby BI platforma mohla být provozována na aktuální verzi SW platformy, |
nebude-li z objektivního důvodu Objednatelem tato aktualizace SW platformy zamítnuta či odložena. Aktualizace SW platformy nesmí negativně ovlivnit dostupnost BI výstupů. Testování kompatibility musí být prováděno v testovacím prostředí odděleném od produkčního prostředí. Povinností Dodavatele je udržovat BI platformu na aktuálních verzích SW platformy a BI nástrojů a eliminovat tak bezpečnostní rizika. Náklady spojené s nutnými úpravami BI platformy, resp. eliminací případné nekompatibility v rámci SW komponent BI platformy, např. z důvodu nasazení nových verzí komponent různých výrobců SW platformy, jsou zohledněny v paušální roční sazbě za Službu „BI_03 – Paušální správa aktiv, konfigurací a maintenance“. Úpravy BI platformy, jejichž předmětem je zajištění kompatibility, jsou považovány za Update BI platformy. Provoz BI platformy na neaktuálních verzích SW platformy nesmí přesáhnout více než 6 měsíců od vydání finální verze příslušné komponenty SW platformy, nebude-li s Objednatelem dohodnuto jinak. Součástí Služby „BI_03 – Paušální správa aktiv, konfigurací a maintenance “ je také provádění profylaxe (pravidelná roční prohlídka BI platformy) v termínech dohodnutých s Objednatelem s cílem optimalizovat technické možnosti HW i SW BI platformy. Součástí této dílčí Služby jsou i doporučení ohledně preventivního odstraňování úzkých míst nebo změn parametrů, eventuálně doporučení použití nových verzí SW platformy nebo řešení s ohledem na vývoj nových SW produktů - zejména třetích stran). Objednatel si vyhrazuje právo provádět (max. 1 ročně) nezávislé penetrační testy. Dodavatel má povinnost bezodkladně napravit případné výhrady po předání výsledků penetračních testů Objednatelem, a to minimálně u bodů s kritickou mírou nebezpečí. Náklady s tímto spojené jsou zohledněny v paušální roční sazbě za „BI_03 – Paušální správa aktiv, konfigurací a maintenance“. | |
Platební podmínky | Součást paušální roční sazby dle odst. 10.1 Smlouvy. |
3.2.1.4. BI_04 - Řízení incidentů
Katalogový list Služby | |
Identifikace (ID) | BI_04 |
Název Služby | „Řízení incidentů“ |
Popis Služby | Odstranění 3 kategorií Incidentů (Vad jednotlivých Kategorií (viz definice pojmů16, závad, výpadků a havárií) vzniklých v BI platformě a v prvcích její softwarové architektury s cílem udržování BI platformy v řádném provozním stavu tak, aby byla dodržována její dostupnost a bylo minimalizováno riziko ohrožení dodávky služeb BI platformy, její funkcionality a dat v ní. Služba “Řízení incidentů” zahrnuje především, nikoliv však výlučně, následující činnosti: • Přebírání Incidentů od Objednatele - zajištění reakce ve Lhůtách na odpověď na Objednatelem nahlášený Incident; |
16 Pozáruční odstraňování vad Díla nebo části Díla, které vznikly činností Dodavatele při realizaci Díla. Odstraňování bude probíhat v úrovni níže stanovených parametrů SLA ve vazbě na KategorieVad a reakční doby na Lhůty pro jejich odstranění.
• Řešení Incidentů - identifikaci, lokalizaci, vyhodnocování příčin a náprava Incidentů; • Odstranění Incidentů – instalace a implementace softwarových korekcí (zejména opravných balíků) nebo jiným způsobem a obnovení řádného fungování BI platformy (znovuuvedení do provozu, resp. uvedení do stavu těsně před mimořádnou událostí), včetně odstranění chyb v datech, které prokazatelně nastaly v důsledku vzniku či odstraňování příslušného Incidentu; • Poskytování informací o stavu odstraňování Incidentů. | |
Parametry | |
Kalendář Služby | 9x5 |
Seznam KPI | KPI_06: Obnovení služby (eliminace Incidentu): • Havárie – stav BI platformy, který neumožňuje plnění základních funkcí; • Výpadek – stav BI platformy 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í (např. provizorní provoz s vynaložením většího úsilí či se zvýšenými náklady); • Závada – stav BI platformy umožňující plnění základních funkcí, 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 BI platformy. KPI_07: Lhůta pro odpověď na zadaný incident. |
Způsob výpočtu a měření Služby | Incident může mít jednu ze 3 kategorií odpovídající prvním třem prioritám pro odstranění Incidentů: |
Priorita | Popis | Lhůty | |||
Priorita 1 Kritická - Havárie | Činnost BI platformy je zcela nebo podstatně omezena, všechny nebo důležité části selhaly nebo jsou nedostupné, selhaly a/nebo jsou zcela nefunkční nebo je jejich funkčnost omezena tak, že je kritickým nebo zásadním způsobem ovlivněna činnost BI platformy. O havárii jde rovněž v situaci, kdy je odezva služeb BI platformy delší než 10 min. (s výjimkou ETL procesů, kde doba odezvy není předmětem měření). | Lhůta pro odpověď (9x5): 4 hod. Obnovení Služby (24x7): do 48 hodin od zadání. (nebude-li lhůta Objednatelem doložitelně prodloužena) | |||
Odpovídá stavu Incidentu Havárie (viz KPI_06 výše), tj. jedná se o stav BI platformy, který neumožňuje plnění základních funkcí. | |||||
Priorita 2 Vysoká - Výpadek | BI platforma je funkční pouze částečně, BI platforma je ovlivněna selháním nebo omezením některé ze systémových funkcí podporujících důležité činnosti BI platformy. Některá z webových služeb vykazuje funkční vady, pouze některé funkce nejsou plně funkční anebo poskytují výrazně (více než 1 min., ale méně než 10 min. včetně) zhoršenou odezvu. Odpovídá kategorii Incidentu Výpadek (viz KPI_06 výše), tj. stav BI platformy, který umožňuje plnění základních funkcí, avšak s omezením rychlosti zpracování nebo za mimořádných provozních opatření (např. provizorní provoz s vynaložením většího úsilí či se zvýšenými náklady). | Lhůta pro odpověď (9x5): 4 hod. Obnovení Služby (9x5): do 16:59 3. BD následujícího po dni zadání. (nebude-li lhůta Objednatelem doložitelně prodloužena) | |||
Priorita 3 Střední - Závada | BI platforma je funkční, závada nemá vliv na činnost BI platformy. Vyskytují se nedostatky nepodstatné povahy, které způsobují například nekomfort obsluhy nebo zvyšující se pracnost činností nad rámec pracnosti obvyklé v běžném provozu. Priorita zároveň zahrnuje situace, kdy některé funkce selhaly, ale nejsou v daný moment využívány nebo nemají žádný vliv na řádný chod BI platformy nebo je mírně zvýšena odezva BI platformy (5-19 sekund). | Lhůta pro odpověď (9x5): 16 hod. Obnovení Služby (9x5): do vydání nové dílčí verze výrobce SW (min. 1 ročně) anebo do 90 dní, jde-li o komponentu autorsky vytvořenou/zajištěnou přímo Dodavatelem. (nebude-li lhůta Objednatelem doložitelně prodloužena) | |||
Odpovídá kategorii Incidentu Závada (viz KPI_06 výše), tj. stav BI platformy, který umožňuje plnění základních funkcí, 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 BI platformy. | |||||
Dodavatel musí automatickou službou měřit v nastavených intervalech odezvu (viz požadavky uvedené na monitorovací aplikaci v KL „BI_01 - Řízení dostupnosti aplikace a provozní monitoring“) a identifikované Incidenty automatizovaně a prokazatelně ihned hlásit prostřednictvím Servisdesk Objednateli. Určení priority je prováděno na základě posouzení, jak Incident ovlivní procesy Objednatele a koncových uživatelů a funkčnost BI platformy. Ve všech případech posunutí (nedodržení) termínů FixTime platí, že Dodavatel je povinen oznámit tuto skutečnost Objednateli. Klasifikaci Incidentů uvádí KPI_06 výše. | |||||
Měřící bod | Servisdesk | ||||
Sankce | Porušení KPI_06: • Havárie – Sankce 200 Kč za každou započatou hodinu po uplynutí lhůty na Obnovení Služby; • Výpadek – Sankce 2.000 Kč za každých započatých 24 hodin po uplynutí lhůty na Obnovení Služby; • Závada – Sankce 2.000 Kč za každých započatých 5 Pracovních dní po uplynutí lhůty na Obnovení Služby. Porušení KPI_07: • Sankce 100 Kč za každou započatou hodinu po překročení Lhůty pro odpověď pro Incident kategorie Havárie; • Sankce 200 Kč za každý případ překročení Lhůty pro odpověď u Incidentu kategorie Výpadek a Závada. | ||||
Způsob dokladování | Pololetní Výkaz KL BI_04 se základní statistikou (počet) Incidentů a informací o (ne)plnění KPI_06 a KPI_07 v členění za jednotlivé kalendářní měsíce. Statistika o všech Incidentech bude obsahovat zejména následující údaje: • Počet Incidentů; • Jednotlivé Incidenty dle kategorie uvádějící jednoznačný identifikátor Incidentu; • Limitní a skutečnou Lhůty pro odpověď k danému Incidentu; • Limitní a skutečnou Lhůtu pro odstranění Služby k danému Incidentu. Zpracování výkazů je součástí paušální roční sazby dle odst. 10.1 Smlouvy BI_03. | ||||
Poznámky | Realizace této Služby bude probíhat primárně dálkovým přístupem Dodavatele na Technologickou platformu Objednatele. V případě, že příčina Incidentu bude prokazatelně na straně BI platformy a nebude možné řešení této Služby vzdáleným způsobem (např. z důvodu bezpečnostní politiky Objednatele) je Dodavatel oprávněn provést havarijní výjezd a zajistit obnovu BI platformy v místě sídla Objednatele. Objednatel je v této situaci povinen poskytnout maximální součinnost. Incidenty, u nichž bude prokazatelně identifikována příčina na straně Objednatele (HW, síťová konektivita/konfigurace apod.) anebo třetích stran (např. výpadek | ||||
napojených externích systémů/služeb) budou Dodavatelem vypořádány s příslušnou poznámkou (zdůvodněním). Na takovéto Incidenty se nevztahuje sankce z nedodržení KPI_06. Incidenty jsou hlášeny a zaznamenávány oprávněnými osobami Objednatele do Servisdesku Dodavatele. Závažnost Incidentu sdělí Objednatel Xxxxxxxxxx formou zápisu v Servisdesku. Dodavatel je oprávněn v rámci stanovených lhůt reagovat na zařazení Incidentu ze strany Objednatele a případně zařazení rozporovat, vždy s uvedením konkrétní argumentace. Výsledná přiřazená kategorie Incidentu vznikne po dohodě obou Smluvních stran. V případě nedosažení shody ohledně kategorizace Incidentu odstraní Dodavatel závadu dle kategorie určené Objednatelem. | |
Platební podmínky | Součást paušální roční sazby dle odst. 10.1 Smlouvy. |
3.2.2. Provozní služby hrazené za odvedené výkony
3.2.2.1. BI_05 – KONZULTACE
Katalogový list Služby | |
Identifikace (ID) | BI_05 |
Název Služby | „Konzultace“ |
Popis Služby | Konzultace je Služba prováděná za účelem poskytnutí odborné pomoci a rady při řešení konkrétního odborného nebo technického problému souvisejícího s daty a procesy v BI platformě. Jedná se například o poskytnutí odborné podpory Objednateli při specifikaci Incidentu nebo požadavku na optimalizaci, poskytování základních technických i odborných rad a doporučení. Služba „Konzultace“ se zabývá problémem Objednatele, uživatelů BI platformy a pomáhá jim daný problém vyřešit. |
Parametry | |
Kalendář Služby | Na vyžádání Objednatelem. |
KPI | KPI_08: Uspokojivě zodpovězený dotaz, řádně zpracované stanovisko, řádně zpracovaný výstup atp. Měřeným parametrem je včasnost poskytnutí této Služby dle lhůt k variantám této Služby stanovených níže. Kvalita této Služby je posuzována na základě záznamů Servisdesku s ohledem na požadovaný výstup vzneseného dotazu a dle níže uvedených lhůt. Telefonické a e-mailové dotazy nejsou primárně hodnoceny z hlediska KPI. V případě opakované nespokojenosti musí oprávněná osoba Objednatele zadat záznam, resp. provést reklamaci v Servisdesku. |
Způsob výpočtu a měření Služby | Realizace Služby „Konzultace“ bude probíhat: |
• Telefonicky; • V Servisdesku; • E-mailově; • Prezenčně – návštěva Objednatele. Služba „Konzultace“ je poskytována formou: • Odpověď na dotaz – U tohoto typu dotazu jde o poskytnutí informace na základě dotazu Objednatele. Tento dotaz může být vznesen Objednatelem prostřednictvím Servisdesku, telefonicky na operátora hot-line, e-mailem na oprávněnou osobu Dodavatele nebo ústně při návštěvě Dodavatele. Objednatel požaduje zodpovězení dotazu následujícího BD (17:00) od vznesení dotazu. • Konzultační výjezd – řešení dotazu si vyžaduje osobní účast zástupce Dodavatele u Objednatele. Dodavatel zajistí účast svého pracovníka a zodpovězení dotazů či zajištění konzultace Objednateli do 3 BD od obdržení požadavku Objednatele, nebude-li po vzájemné dohodě stanoveno jinak. • Závazné vyjádření – U tohoto typu dotazu je Dodavatelem vypracován písemný dokument, který bere v úvahu i možné jiné dopady vztahující se k problematice BI platformy. Charakter dotazu – objednávky Konzultace – je závazného charakteru. Vyžádání této služby může být provedeno pouze písemnou formou (e-mailem) nebo záznamem v Servisdesku. Zpracování vyjádření Dodavatelem proběhne v dohodnutém termínu s Objednatelem. • Nacenění požadavku na změnové řízení: odpověď na dotaz, jehož předmětem je žádost na nacenění požadavku na rozvoj BI platformy. | |
Měřící bod | Servisdesk |
Sankce | Při porušení KPI_08 je uplatněna jednorázová sankce ve výši 500 Kč za každý takový případ. |
Způsob dokladování | Pololetní Výkaz KL BI_05 se základní statistikou (počet, typ, strávený čas aj.) realizace této Služby s přehledem plnění KPI_08. Předmětem statistiky není evidence jednotlivých telefonátů či přehled e-mailů. Zpracování výkazů je součástí ceny dle odst. 10.1 Smlouvy BI_03. |
Poznámky | Předpokládané využití Dodavatelem je průměrně 0,5 hodiny v BD. |
Platební podmínky | Disponibilní člověkohodiny (ČH) mají charakter nepovinného, volně čerpatelného kreditu. V rámci tohoto KL_BI_05 budou hrazeny pouze reálně čerpané člověkohodiny (ČH) až do maximálního ročního objemu (120xsazba za 1 ČH), resp. jeho navýšení způsobeného převodem ČH za tento KL podle smluvní sazby za člověkohodinu. Cena za 1 ČH je uvedena v odst. 10.7 Smlouvy. Nevyčerpané ČH se budou automaticky převádět do následujícího kalendářního roku. Převod nevyčerpaných ČH je možný pouze do následujícího kalendářního roku. V rámci fakturačního období se ovšem vždy fakturují pouze odsouhlasené a reálně provedené práce (čerpané ČH). |
3.2.2.2. BI_06 – Řízené ukončení provozních služeb (Exit strategie)
Katalogový list Služby | |
Identifikace (ID) | BI_06 |
Název Služby | „Řízené ukončení provozních služeb (Exit strategie)“ |
Popis Služby | Služby řízeného ukončení provozních služeb jsou předpokladem ukončení zajištění vybraných Služeb a budou zahájeny na základě pokynu Objednatele bez nutnosti objednávky ze strany Objednatele. Realizace Exit strategie nastává zároveň automaticky, v případě podání výpovědi Smlouvy ze strany Dodavatele. Dokument popisující plán řízeného ukončeni poskytování služeb (tj. Exit strategii) je povinen Dodavatel zpracovat v rámci Fáze 1 – části Zpracování IT analýzy a průběžně jej v případě změny zásadních předpokladů aktualizovat. Aktualizace podléhá schválení Objednatele. Tento dokument (Exit plán) musí obsahovat níže uvedené náležitosti a zohledňovat uvedené principy. Řízené ukončení Služeb (realizace Exit plánu) může Objednatel zahájit kdykoliv, a to bez ohledu na důvod ukončení Smlouvy. Služba řízeného ukončení poskytování služeb se stanovuje za účelem provedení koordinovaného a procesně vymezeného postupu při ukončení smluvního vztahu s Dodavatelem a řádného převedení činností/služeb na Objednatele, nebo jím stanovený subjekt. V rámci služeb řízeného ukončení Služeb musí Dodavatel: • Připravit detailní plán řízeného ukončeni poskytování služeb a jejich převedení na Objednatele nebo jím stanovený subjekt (dále jen „Plán řízeného ukončení“). Plán řízeného ukončení musí být zpracován tak, aby bylo možné převést zajišťování provozu BI platformy s minimálními provozními dopady na dostupnost BI platformy. Plán bude zahrnovat předání: ▪ Veškeré dokumentace BI platformy, vč. Zdrojového kódu v aktuálním znění (Zdrojový kód musí zahrnovat obvyklé součásti, jakými jsou zejména zdokumentovaná API rozhraní u použitého frameworku, DLL knihovny, kompletní projekt/solution pro části BI platformy vyvinuté na zakázku pro zkompilování a rozvoj aplikace, skripty pro vytvoření databází a jejich prvotní naplnění daty a číselníky, dokumentace HW a SW požadavků u vytvořeného řešení (např. minimální verze SQL Serveru 2008 R2 s SP1 atp.), instalační příručka (např. nastavení portů na firewallu atp.) a dokumentace pro nasazení změnových balíků, instalační a provozní manuály, administrátorská a uživatelská příručka a další dokumenty dle využité vývojové metodiky Dodavatele); ▪ Provozního know-how spočívajícího v zaškolení pracovníků, kteří budou zajišťovat následné poskytování Služeb; ▪ Veškerých dat, která vznikla v souvislosti s provozem Díla a s poskytováním služeb dle Xxxxxxx a která jsou ve správě Dodavatele. Strukturovaná data předá Dodavatel Objednateli (v sídle Objednatele, nebude-li dohodnuto jinak) v XML struktuře/formátu (syntaxi) stanovené ze strany Objednatele. Veškerá data a informace vzniklé v souvislosti s poskytováním Služeb dle jednotlivých katalogových listů, včetně záznamových souborů (logů) (dále jen „Data") jsou ve výlučném vlastnictví Objednatele. Před nebo v okamžiku ukončení Smlouvy |
jakýmkoli způsobem je Dodavatel povinen na výzvu Objednatele předat Objednateli nebo jím určené třetí osobě veškerá Data získaná za celou dobu účinnosti Smlouvy, a to bez nároku na dodatečné finanční plnění či náhradu vynaložených nákladů ze strany Objednatele; ▪ Poskytovat veškerou součinnost potřebnou k realizaci Exit plánu (tj. mimo jiné i poskytování informací, účast na jednáních Objednatele nebo třetích stran určených Objednatelem apod.). • Provést řízené ukončení Služeb dle Objednatelem schváleného Plánu řízeného ukončení a jejich převedení na Objednatele nebo jím stanovený subjekt. Plán řízeného ukončení a převedení na Objednatele nebo jím stanovený subjekt (rozpracování Exit plánu) bude vypracován do 30 pracovních dnů od obdržení požadavku Objednatele k provedení této služby Dodavatelem, nestanoví-li Objednatel jinak. Vypracováním Plánu řízeného ukončení se rozumí jeho schválení Objednatelem. Vyhotovený Plán řízeného ukončení nesmí předpokládat dobu realizace řízeného ukončení Služeb delší než 2 měsíce, pokud Objednatel nestanoví jinak. Export Dat může Objednatel požadovat opakovaně (např. v ročních intervalech), a to i v případě, kdy není Smlouva ukončována. V takovém případě se aplikuje na prokazatelnou pracnost denní sazba ze služby „BI_09 - Rozvoj Díla platformy, správa releasů a nasazení (velké Upgrady)“. Cena za služby řízeného ukončení je uvedena ve Smlouvě. | |
Parametry | |
Kalendář Služby | Na vyžádání Objednatelem |
KPI | KPI_09: Řádné provedení jednotlivých úkonů dle Plánu řízeného ukončení ve stanovených termínech. Měřeným parametrem je včasnost poskytnutí této Služby dle lhůt odsouhlasených Objednatelem. |
Způsob výpočtu a měření Služby | Služba je měřena oproti termínům stanoveným v Plánu řízeného ukončení. |
Měřící bod | Servisdesk |
Sankce | Při porušení KPI_09 je uplatněna jednorázová sankce ve výši 2.000 Kč za každý den prodlení s řádným ukončením služeb řízeného ukončení provozních služeb oproti finálnímu termínu stanovenému v Plánu řízeného ukončení. Bude-li požadována součinnost ze strany Objednatele nebo jím určené třetí osoby, zavazuje se Dodavatel reagovat na požadavek Objednatele nebo jím určené třetí osoby a zahájit poskytování součinnosti nejpozději do pěti (5) pracovních dnů ode dne doručení takovéhoto požadavku. Bude-li Dodavatel v prodlení se splněním této povinnosti poskytnout součinnost, je povinen zaplatit Objednateli smluvní pokutu ve výši 2.000 Kč za každý i započatý den prodlení. |
Způsob dokladování | O provedení Služby bude připraven Dodavatelem Protokol o řízeném ukončení provozních služeb, který bude obsahovat detailní Plán řízeného ukončení a protokol o provedení jednotlivých úkonů dle Plánu řízeného ukončení. Zpracování Protokolu je součástí ceny dle odst. 10.1 Smlouvy – |
BI_06). | |
Poznámky | N/A. |
Platební podmínky | Služba má charakter jednorázové platby. V rámci řízeného ukončení Služeb bude uhrazena cena za řádně provedení a akceptaci služby řízeného ukončení v částce uvedené ve Smlouvě - odst. 10.1 Smlouvy – BI_06. |
3.2.2.3. BI_07 – Školení na objednávku
Katalogový list Služby | |
Identifikace (ID) | BI_07 |
Název Služby | „Školení na objednávku“ |
Popis Služby | Školení na objednávku je Služba prováděná za účelem zabezpečení školícího procesu jednotlivých úrovní/kategorií uživatelů systému, a to zejména u nových pracovníků či při nasazení nových funkcionalit systému atp. Časová dotace školícího dne činí 6 školících hodin po 60 minutách a obsah školení bude stanoven v okamžiku objednání služby. Hlavním cílem služby „Školení na objednávku“ je zajištění proškolení uživatelů, kteří neabsolvovali školení před nasazením BI platformy či neabsolvovali specializační školení a Objednatel vyhodnotil potřebu jejich proškolení jako nezbytnou. |
Parametry | |
Kalendář Služby | Na vyžádání Objednatelem |
KPI | KPI_10: Zajištění proškolení koncových uživatelů nebo administrátorů v rozsahu dle typu školení stanoveného Objednatelem. Měřeným parametrem je poskytnutí této Služby v rozsahu a parametrech stanovených pro jednotlivé varianty této Služby stanovených níže. Kvalita této Služby je posuzována na základě: Zpětná vazba účastníků školení, která neobsahuje kritické výhrady ze strany více účastníků k podobě či způsobu zajištění příslušného běhu školení, které Objednatel uznal jako objektivní pochybení spočívající na straně Dodavatele. |
Způsob výpočtu a měření Služby | Realizace Služby bude probíhat: • Formou prezenčního školení se zajištěním PC a další techniky nezbytné pro praktickou ukázku práce s BI platformou v místě Objednatele Realizace Služby bude poskytnuta v rozsahu dle typu školení zvoleného Objednatelem: • Úvodní školení koncových uživatelů - začátečník; • Školení pro pokročilé uživatele; • Školení technologických administrátorů; • Školení power userů (obsahových administrátorů). |
Měřící bod | N/A |
Sankce | Při porušení KPI_10 je uplatněna jednorázová sankce ve výši 5.000 Kč za každý takový případ. |
Způsob dokladování | Provedení Služby bude dokladováno podepsanou prezenční listinou obsahující údaje min. v tomto rozsahu: typ školení, obsah školení, místo a datum školení, délka školení (počet hodin) a podpisy proškolených osob. |
Poznámky | Předpokládaná frekvence školení na objednávku jsou 3 běhy školení v průběhu roku. Dodavatel zajistí pro každý běh školení vlastní dataprojektor; Objednatel zajistí PC a případně další technické prostředky specifikované Dodavatelem, které jsou nezbytné pro praktickou ukázku práce s BI platformou, a to vždy dle počtu proškolovaných osob a kapacity zasedací místnosti. Dodavatel dále poskytne všem proškolovaným osobám elektronické, případně i tištěné materiály školení (prezentaci). Maximální počet účastníků 1 školení je 15 osob, maximální počet osob využívajících 1 PC s instalovaným SW pro praktickou část školení, jsou 2 osoby. |
Platební podmínky | Služba má charakter nepovinného, volně čerpatelného paušálu. V rámci Služby bude uhrazena pouze cena za řádně provedená a akceptovaná školení v částce rovnající se součinu ceny za školící den (běh) uvedené ve Smlouvě a počtů realizovaných běhů školení na objednávku v rámci daného fakturačního období. Maximální počet je 3 běhy školení ročně, případně více v souvislosti s přesunem nevyčerpaných běhů do následujícího kalendářního roku. |
3.2.2.4. BI_08 – Služby vývoje (datových transformací, reportovacích modelů, sestav, dashbordů) na
OBJEDNÁVKU
Katalogový list Služby | |
Identifikace (ID) | BI_08 |
Název Služby | „Služby vývoje (datových transformací, reportovacích modelů, sestav, dashbordů) na objednávku“ |
Popis Služby | Jedná se o služby realizace funkčních požadavků Objednatele Dodavatelem dle zadání definovaného v objednávkách a na základě nabídky Dodavatele. Služby vývoje (datových transformací, reportovacích modelů, sestav, dashbordů) na objednávku zahrnují dodávku odborných služeb Dodavatele spočívajících ve využití skriptovacích jazyků/programátorských zásahů podporovaných BI platformou, a to zejména pro možnost: • Doplňovat integrace na aplikace/API nových konzumentů/Dodavatelů dat, tj. doplňovat (programovat) úlohy datové integrace (nastavením zdrojů dat, procesů čištění dat, cílového místa uložení v sémantické datové vrstvě, ošetření chybových stavů, časů a frekvencí spouštění (na základě události či v daném čase), předávání dat do systémů konzumentů dat atp.; • Skládat data z datasetů načtených z EAP (či jiných datových zdrojů) a vytvářet fakta a dimenze (např. více let dohromady) pro plnění datamartů; • Vytvářet (programovat) definice dalších vypočtených ukazatelů/indikátorů a metrik (např. možnost „doprogramovat“ další indikátory); • Vytvářet (programovat) další reportovací modely nad centrální datovou vrstvou; |
• Provádět „uživatelskou“ transformaci a čištění dat i na úrovni nástrojů pro vizualizaci dat, kterou je možné využít při přípravě pracovních verzí reportů a výstupů; • Vytvářet (programovat) další vizuální prvky pro BI výstupy a vytvářet další sestavy a vizualizace dat v grafickém rozhraní (tj. možnost doprogramovat další BI výstupy); • Realizovat adhoc API integraci pro přístup k datům v datové vrstvě; • Realizovat exporty dat z datové vrstvy dle potřeb MŽP/CENIA. Možnost vytvářet uvedená výše zahrnuje rovněž úpravy či odstranění stávajících nasazených entit. MŽP bude tyto odborné služby čerpat primárně v okamžiku, když bude potřebovat dočasně posílit své pokročilé uživatele (power usery) o kapacity Dodavatele, příp. když bude potřeba předat pokročilým uživatelům specifické know-how spojené s parametrizací či možnostmi doprogramovávání BI platformy. | |
Parametry | |
Kalendář Služby | Na vyžádání Objednatelem |
KPI | KPI_11: Nasazená nová datová transformace, reportovací model, sestava či dashboard (tj. výstup vývoje). Měřeným parametrem při poskytnutí této Služby je dodržení závazného harmonogramu pro nasazení nové datové transformace, reportovacího modelu, sestavy či dashboardu v harmonogramu schváleném Objednatelem. Kvalita této Služby je posuzována na základě akceptačního testování výstupu vývoje. |
Způsob výpočtu a měření Služby | Realizace Služby „Služby vývoje (datových transformací, reportovacích modelů, sestav, dashbordů) na objednávku“ bude probíhat v úzké součinnosti mezi Objednatelem a Dodavatelem dle závazného harmonogramu pro nasazení výstupu vývoje do BI platformy či předání výstupu vývoje Objednateli. |
Rozsah služby | Pro potřeby realizace této Služby činí maximální objem prací Dodavatele dle tohoto KL_BI_08 maximálně 400 člověkodin (ČH) na jeden rok. Skutečný objem čerpaných ČH potřebných pro realizaci této Služby může být i nižší podle aktuálních potřeb Objednatele. O nevyčerpané ČH v daném roce se navyšuje rozsah ČH pro rok následující. Nacenění pracnosti je zaznamenáváno v Servisdesku v rámci Služby BI_02. |
Měřící bod | Servisdesk. |
Sankce | Při porušení KPI_11 je uplatněna sankce ve výši 1 000 Kč za každý započatý den následující po dni, ke kterému měl být výstup vývoje dle závazného harmonogramu nasazen či odevzdán Objednateli. |
Způsob dokladování | Protokol o nasazení či odevzdání výstupu vývoje Objednateli. Zpracování protokolu je součástí paušální roční sazby dle odst. 10.1 BI_03 Smlouvy. Provedení Služby bude dokladováno označením záznamu o požadavku (objednávce) jako „akceptováno“ v ServisDesku. Implementační práce jsou zaznamenávány do Provozního deníku. |
Poznámky | Rozvoj Díla není předmětem této služby, ale je realizován v rámci služby BI_09 Rozvoj Díla. |
Platební podmínky | Disponibilní člověkodny mají charakter nepovinného, volně čerpatelného paušálu. V rámci tohoto KL budou hrazeny pouze reálně čerpané člověkodny až do maximálního ročního objemu (400xsazba za 1 ČH), resp. jeho navýšení způsobeného převodem ČH za tento KL podle smluvní sazby za člověkoden. Cena za 1 ČH je uvedena v odst. 10.10 Smlouvy. Nevyčerpané ČD se budou automaticky převádět do následujícího kalendářního roku. Převod nevyčerpaných ČH je možný pouze do následujícího kalendářního roku. V rámci fakturačního období se ovšem vždy fakturují pouze odsouhlasené a reálně provedené práce (čerpané ČH). Předmětem fakturace jsou všechny analytické, vývojové, testovací, implementační a dokumentační práce, spojené s realizací předmětu vývoje za příslušné fakturační období. |
3.3. Zajištění rozvoje Díla
Objednatel je oprávněn kdykoliv v období od Akceptace Díla do okamžiku ukončení zajištění vybraných Provozních služeb písemně požádat, a to i opakovaně, Dodavatele o poskytnutí dalších dodávek nebo služeb týkajících se Díla, které nejsou součástí dodávky a nasazení Díla a zajištění vybraných Provozních služeb a spočívají především ve vývoji a úpravě Díla či služeb souvisejících se změnou, vývojem – rozvojem Díla.
Maximální rozsah Rozvoje Díla je stanoven na 30 MD ročně (kalendářní rok). Objednatel není povinen k čerpání Rozvoje Díla v tomto sjednaném rozsahu, avšak Xxxxxxxxx se zavazuje k jeho poskytnutí, pokud je Objednatel vyžádá.
Objednatel je oprávněn Dodavateli doručit písemnou žádost obsahující zejména podrobný věcný popis Rozvoje Díla, požadovaný termín plnění (dále jen „Objednávka“). Dodavatel je povinen předložit Objednateli do 5 pracovních dnů ode dne obdržení Objednávky časový harmonogram poskytování příslušných dodávek nebo služeb, včetně závazného maximálního počtu hodin pracovníků Dodavatele potřebných k poskytnutí požadovaných dodávek nebo služeb a včetně nezbytné součinnosti Objednatele.
V případě, že Objednatel bude souhlasit s navrženým rozsahem prací (včetně závazného maximálního počtu hodin pracovníků Dodavatele), písemně potvrdí rozsah dodávek Dodavateli, jinak Xxxxxxxxxx vyzve k jeho projednání. Poté, co Objednatel potvrdí Dodavateli rozsah dodávek nebo služeb, je Xxxxxxxxx povinen poskytnout Objednateli dodávky nebo služby dle Objednávky. Pokud provedené dodávky nebo služby ovlivní či doplní Dílo, považují se za součást Díla se všemi právy a povinnostmi z toho vyplývajícími, pokud se podstatným způsobem nezmění rozsah nebo nasazení Díla.
V případě nedodržení dohodnutého termínu poskytnutí dodávek nebo služeb dle Objednávky při plném poskytnutí součinnosti Objednatelem je Objednatel oprávněn požadovat po Dodavateli smluvní pokutu ve výši 10 % ceny příslušné Objednávky. Za každých dalších 10 pracovních dnů prodlení Dodavatele je Objednatel oprávněn požadovat po Dodavateli vždy smluvní pokutu ve výši 10 % ceny příslušné Objednávky (tj. nad rámec již nárokované smluvní pokuty dle předchozí věty). Zaplacením smluvní pokuty není dotčen nárok na náhradu škody.
Dodavatel se zavazuje, že zajistí poskytování Rozvoje Díla takovými pracovníky, jejichž zkušenosti, odborné znalosti a vzdělání zaručují maximální možnou efektivitu jejich poskytování.
Ustanovení Smlouvy o dodávce a nasazení Díla a zajištění vybraných Provozních služeb
se při poskytování Rozvoje Díla použijí v závislosti na jejich povaze obdobně.
3.3.1. BI_09 – Rozvoj Díla, správa releasů a nasazení (velké Upgrady)
Katalogový list Služby | |
Identifikace (ID) | BI_09 |
Název Služby | „Rozvoj Díla, správa releasů a nasazení (velké Upgrady)“ |
Popis Služby | Úpravy a adaptace BI platformy s cílem zajištění jeho efektivnějšího, plnohodnotného a právně nezávadného využívání (tj. přidávání nových komponent a funkcionalit BI platformy, úpravy v celkové konfiguraci BI platformy). Cílem je zajistit hladkou a nákladově efektivní implementaci pouze schválených změn (oběma Smluvními stranami) a minimalizovat vznik Incidentů způsobených provedením změn podporované BI platformy. V rámci této Služby jsou vykonávány zejména, nikoliv však výlučně, následující činnosti: • analytické práce v rámci realizace schválených změnových požadavků na rekonfiguraci, databázové, programátorské, případně další úpravy BI platformy; • Upgrady BI platformy - optimalizace stávajících, rozšiřování a konfigurace nových funkcionalit BI platformy; • vývojové a programátorské práce, jejichž cílem je efektivnější, bezpečnější a komplexnější využívání úloh a výstupů BI platformy; • provádění testování ve vývojovém prostředí včetně ověření zachování funkčnosti celého řešení BI platformy; • provádění instalace Upgrade na testovací prostředí po ověření funkčnosti ve vývojovém prostředí; • součinnost při testování instalovaného Upgrade na testovacím prostředí Objednatele; • zajištění nebo provedení nezbytné zálohy před a po upgrade BI platformy nebo jeho části před nasazením na produkční prostředí; • provádění implementace vybraných Upgrade na produkční prostředí; • aktualizace Dokumentace v návaznosti na úpravy jeho funkčnosti (Upgrady) - aktualizace Dokumentace a Zdrojových kódů BI platformy v návaznosti na úpravy jeho funkčnosti tak, aby Objednatel měl vždy k dispozici úplnou dokumentaci k verzím SW, jež v danou dobu užívá; • projektové a administrativní práce související s realizací změnových požadavků a změnových řízení (stanovení harmonogramu realizace, tvorba akceptačních scénářů, tvorba zápisů z testování, účast na akceptačním řízení, prezentace výsledků apod.). |
Parametry | |
Kalendář Služby | Na vyžádání Objednatelem |
KPI | KPI_12: Provedení změny ve funkcionalitě, úlohách, anebo výstupech BI platformy na základě uživatelského požadavku nebo požadavku vyvolaného legislativní změnou, při dodržení termínů |
dle dohodnutého harmonogramu, viz níže. | |
Způsob výpočtu a měření Služby | Služba „Rozvoj Díla, správa releasů a nasazení (velké Upgrady)“ bude poskytována podle požadavků Objednatele. Dodavatel je povinen sdělit Objednateli nejpozději do 17:00 5. BD od obdržení požadavku Objednatele akceptaci požadavku nebo relevantní důvody pro jeho odmítnutí. Zadání požadavku na změnové řízení zpravidla předchází jeho nacenění a vstupní analýza. Tato Služba je poskytována ve třech základních variantách, a to v závislosti na možném dopadu na Objednatele a povolené (akceptovatelné) délce odstávky BI platformy: • Nízký dopad – U tohoto typu jsou prováděny optimalizace a změny BI platformy, které nejsou zásadního charakteru. Harmonogram: o Provedení změn BI platformy v dohodnutém termínu s Objednatelem. • Střední dopad – U tohoto typu jsou prováděny uživatelské optimalizace a změny zásadnějšího charakteru s větším rizikem funkčního dopadu na úlohy a výstupy BI platformy a zpravidla delší dobou realizace. Je zde zapotřebí součinnosti Objednatele a může být nutná odstávka BI platformy. Postup realizace změnového požadavku je následující: Objednatel nejdříve v Servisdesku v rámci Služby BI_02 zadává záznam, kde specifikuje možný budoucí požadavek na změnové řízení a požádá Dodavatele o jeho nacenění. Na základě požadavku vzneseného Objednatelem provede Dodavatel (opět v rámci Služby BI_02) popis požadavku, a to včetně stanovení dopadu na BI platformu, délky případné odstávky BI platformy, způsobu a odhadované doby realizace a pracnosti provedení. Popis požadavku Dodavatel předá Objednateli k odsouhlasení. Objednatel, teprve až akceptuje popis a rozsah řešení požadavku, zadává požadavek na změnové řízení do Servisdesku, a to již jako položku Služby BI_09. Vyžádá-li si Objednatel vytvoření testovacích/akceptačních scénářů, Dodavatel je povinen tyto scénáře vytvořit, a to v dohodnutém termínu, vždy však minimálně 1 Pracovní den před prováděním akceptačních testů. Harmonogram: o Provedení změn BI platformy v dohodnutém termínu s Objednatelem. • Vysoký dopad – U tohoto typu jsou prováděny optimalizace a změny zásadního charakteru s vysokým rizikem dopadu, např. změna legislativy, na BI platformu. Je zde zapotřebí velké součinnosti Objednatele a je nutná dlouhodobější odstávka BI platformy. Postup realizace změnového požadavku je následující: Objednatel nejdříve v Servisdesku v rámci Služby BI_02 zadává záznam, kde specifikuje možný budoucí požadavek na změnové řízení a požádá Dodavatele o jeho nacenění. Na základě požadavku vzneseného Objednatelem provede Dodavatel (opět v rámci Služby dle KL BI_02) popis požadavku, a to včetně stanovení dopadu na BI platformu, délky odstávky BI platformy, způsobu a odhadované doby realizace a pracnosti provedení. Popis požadavku Dodavatel předá Objednateli k odsouhlasení. Objednatel, teprve až akceptuje popis a rozsah řešení požadavku, zadává požadavek na změnové řízení do Servisdesku, a to již jako položku Služby BI_09. Minimálně v týdenním předstihu nebude- li dohodnuto jinak, před dohodnutým termínem implementace na testovací prostředí Dodavatel předá písemný popis testovacích/akceptačních scénářů k odsouhlasení. Harmonogram: o Provedení změn BI platformy v dohodnutém termínu s Objednatelem. |
Rozsah Služby | Pro potřeby realizace této Služby činí maximální objem prací Dodavatele dle tohoto KL_BI_09 maximálně 240 člověkohodin (ČH) na jeden rok. Skutečný objem čerpaných ČH potřebných pro realizaci této Služby může být i nižší podle aktuálních potřeb Objednatele. O nevyčerpané ČH v daném roce se navyšuje rozsah ČH pro rok následující. Nacenění pracnosti zaznamenáváno |
v Servisdesku v rámci výkaznictví Služby BI_05 „Konzultace“. | |
Měřící bod | Servisdesk. |
Sankce | KPI_12: Neprovedení této Služby dle harmonogramu (viz výše) bude sankcionováno částkou ve výši 1.000 Kč za každý započatý BD nad rámec dohodnutého termínu dodání/implementace. |
Způsob dokladování | Veškerá komunikace ve věci realizace odsouhlasených požadavků na změnové řízení včetně tvorby akceptačních scénářů je zaznamenáváno v Servisdesku v rámci služby dle BI_02 a Dodavatel není oprávněn si je dodatečně účtovat denní sazbou, čili je zohledněna v ceně za provedení změnového řízení. Půlroční Výkaz KL BI_09 se základní statistikou realizace Služby „Rozvoj BI, správa releasů a nasazení (velké Upgrady)“, počtem čerpaných/nečerpaných/převáděných ČD, s přehledem plnění KPI_12 s rozpadem pracnosti dle jednotlivých objednávek. Zpracování výkazů je součástí paušální roční sazby dle odst. 10.1 Smlouvy BI_03. Implementační práce jsou zaznamenávány do Provozního deníku. Odsouhlasení provedení této Služby provede kontaktní osoba Objednatele, a to prostřednictvím Servisdesku. |
Poznámky | Objednateli je garantována kvalita provedení této Služby, přesně stanovena doba potřebné odstávky s klasifikací změny a časovým odhadem k provedení této změny. U každé změny BI platformy je Objednateli garantována možnost, způsob a doba návratu do původního stavu. Výsledkem této Služby je dodání, instalace a implementace nových verzí BI platformy. Je požadováno, aby nové verze BI platformy splňovaly relevantní požadavky funkční požadavky a požadavky na vlastnosti BI platformy. Před instalací do produkčního prostředí je Dodavatel povinen ověřit stabilitu a funkčnost nově vytvořených verzí BI platformy v testovacím prostředí. Pokud Dodavatel písemně oznámí a prokáže Objednateli, že taková instalace a implementace by vedla k chybovému stavu BI platformy zapříčiněnému rozdílností verzí softwarových komponent třetích stran (SW platformy) z důvodů různého režimu podpory těchto komponent, může Objednatel pozastavit implementaci takového plnění. Pozastavení plnění nezbavuje Dodavatele povinnosti provozovat BI platformu bezchybně. |
Platební podmínky | Disponibilní člověkodny mají charakter nepovinného, volně čerpatelného paušálu. V rámci tohoto KL budou hrazeny pouze reálně čerpané člověkodny až do maximálního ročního objemu (240xsazba za 1 ČH), resp. jeho navýšení způsobeného převodem ČH za tento KL podle smluvní sazby za člověkoden. Cena za 1 ČH je uvedena v odst. 10.10 Smlouvy. Nevyčerpané ČH se budou automaticky převádět do následujícího kalendářního roku. Převod nevyčerpaných ČH je možný pouze do následujícího kalendářního roku. V rámci fakturačního období se ovšem vždy fakturují pouze odsouhlasené a reálně provedené práce (čerpané ČH). Předmětem fakturace jsou všechny analytické, vývojové, testovací, implementační a dokumentační práce, spojené s realizací změnových řízení za příslušné fakturační období. |
3.4. Přesun Díla
Objednatel je oprávněn kdykoliv v období od Akceptace Díla do okamžiku ukončení poskytování vybraných Provozních služeb písemně požádat, a to i opakovaně, Dodavatele o poskytnutí plnění
„Přesun Díla“. Objednatel se zavazuje v cílovém místě Přesunu Díla vytvořit adekvátní podmínky pro realizaci Přesunu Díla a následné pokračování v plnění předmětu Smlouvy, a to zajištění vybraných Provozních služeb a zajištění Rozvoje Díla. Požadavky Smlouvy na dodávku a nasazení Díla a zajištění vybraných Provozních služeb se přiměřeně aplikují na Přesun Díla.
Dodavatel zajistí poskytování Přesunu Díla takovými pracovníky, jejichž zkušenosti, odborné znalosti a vzdělání zaručují maximální možnou efektivitu jejich poskytování. Součástí Přesunu Díla je znovuzprovoznění Díla v místě přesunu včetně obnovení poskytování všech plnění dle Smlouvy.
Objednatel stanoví, na základě návrhu Dodavatele a po dohodě s ním, závazný harmonogram
pro Přesun Díla.
3.4.1. BI_10 – PŘESUN DÍLA
Katalogový list Služby | |
Identifikace (ID) | BI_10 |
Název Služby | „Přesun Díla“ |
Popis Služby | Přesun BI platformy k provozu v jiném prostředí a/nebo na jiné infrastruktuře (např. přesun Díla z datových center MŽP do eGovernment Cloudu (eGC)). Služba zahrnuje zprovoznění SW platformy Díla v cílovém prostředí a nasazení Díla do připraveného SW a HW prostředí (v rozsahu funkčnosti před zahájením přesunu, vč. všech vytvořených skriptů atp.) a znovuobnovení běžného provozu BI platformy. Obecný dokument popisující plán přesunu Díla (Plán přesunu Díla) je povinen Dodavatel zpracovat nejpozději v době Akceptace Díla. Tento dokument musí obsahovat postup a další náležitosti spojené s přesunem Díla a následně bude v případě pokynu/požadavku Objednatele na přesun Díla v daném čase aktualizován anebo vytvořen zcela nový reflektující aktuální reálie zejména konkrétní prostředí, kam bude dílo přesouváno. Plán přesunu Díla musí být koncipován tak, aby jej bylo možné provést do 1 měsíce od obdržení objednávky Objednatele. |
Parametry | |
Kalendář Služby | Na vyžádání Objednatelem |
KPI | KPI_13: Znovuzprovozněné Dílo v cílovém provozním prostředí/na cílové infrastruktuře. Měřeným parametrem je dodržení závazného harmonogramu pro přesun Díla, tj. zajištění řádné funkčnosti BI platformy v cílovém prostředí v čase vymezeném pro přesun Díla, která bude obsahovat veškerý datový, aplikační a konfigurační obsah jako verze provozovaná na Technologické platformě Objednatele. |
Způsob výpočtu | Realizace Služby „Přesun Díla“ bude probíhat v úzké součinnosti mezi Objednatelem |
a měření Služby | a Dodavatelem dle závazného harmonogramu pro přesun Díla. |
Měřící bod | Servisdesk. |
Sankce | Při porušení KPI_13 je uplatněna jednorázová sankce ve výši 2.000 Kč za každý započatý den následující po dni, ke kterému mělo být Dílo dle závazného harmonogramu nejpozději přesunuto. |
Způsob dokladování | Protokol o provedeném přesunu Díla. Zpracování protokolu je součástí jednorázové ceny za provedení Služby dle odst. 10.11 Smlouvy. |
Poznámky | Xxxxxxxxx je s ohledem na princip poskytování služeb s odbornou péčí povinen upozornit Objednatele na skutečnosti související s cílovým prostředím, které mohou po přesunu Díla ohrozit řádný provoz Díla. |
Platební podmínky | Služba má charakter jednorázové platby na částku uvedenou ve Smlouvě, viz odst. 10.11. |
4. Přílohy
Příloha č. 1: „Katalog požadavků na BI platformu“ – následuje
Příloha č. 2: „Zadání typových úloh“ – následuje
Příloha č. 3: „Zpráva o životním prostředí 2018“ – dostupná na adrese: xxxxx://xxx.xxxxx.xx/xx-xxxxxxx/xxxxxxx/0000/00/Xxxxxx_x_XX_XX_0000.xxx xxxxx://xxx.xxxxx.xx/Xxxxxx.xxxx?xxx000000000&xxxx.xxx&xxxxxxxxx000000000X
Příloha č. 4: „Podkladové soubory pro ,Zadání typových úloh‘“ – dostupná na adrese:
xxxxx://xxx.xxxxx.xx/Xxxxxx.xxxx?xxx000000000&xxxx.xxx&xxxxxxxxx000000000X
Příloha č. 5: „Ukázka CKAN‘“ – dostupná na adrese:
xxxxx://xxx.xxxxx.xx/Xxxxxx.xxxx?xxx000000000&xxxx.xxx&xxxxxxxxx000000000X
KATALOG POŽADAVKŮ NA BI PLATFORMU
1. Struktura katalogu požadavků na BI platformu
Katalog požadavků obsahuje přehled všech požadavků identifikovaných/zjištěných v provedené analytické fázi (tj. fázi analýzy potřeb MŽP a sběru uživatelských požadavků pro oblast statistik a reportingu). Každý požadavek je zde reprezentován identifikátorem, názvem a samotným popisem požadavku.
Požadavky na řešení jsou v katalogu požadavků dekomponovány do následujících kategorií:
▪ Požadavky na funkcionality – vymezení množiny funkcionalit, které bude technické řešení
platformy BI nabízet uživatelům.
▪ Požadavky na vlastnosti – vymezení množiny kvalitativních parametrů BI platformy
zahrnujících požadavky na:
o Architekturu;
o Použitelnost řešení – jedná se o požadavky zaměřené na hodnocení systému
z pohledu uživatele;
o Spolehlivost – jedná se o požadavky zaměřené na úroveň kvality provozu systému;
o Výkon – jedná se o požadavky zaměřené zejména na rychlost odezev systému, rychlost zpracování klíčových byznys aktivit atp. Předpokládaný počet oprávněných uživatelů platformy BI, počet současně pracujících uživatelů a nutnost garantovaných vlastností platformy BI, např. garantovaná doba odezvy systému na dotaz je promítnuta jak do konceptu architektury, tak v rámci realizace do požadovaných parametrů na konkrétní implementaci platformy BI včetně příp. sizingu HW prostředků. Zároveň je nutno zdůraznit, že povinnost garantovat potřebný výkon a související parametry musí být zakotveny do smluvního vztahu MŽP s vybraným Dodavatelem SW řešení BI platformy a rovněž s vybraným provozovatelem (ve formě Service Level Agreementu – SLA);
o Rozšiřitelnost – jedná se o požadavky zaměřené zejména na stanovení možností pro rozšiřitelnost řešení. Vzhledem k tomu, že lze předpokládat rozšiřování platformy BI v budoucnosti jak co do funkcionality, tak co do množství uživatelských subjektů, musí návrh řešení splňovat podmínku rozšiřitelnosti. To se týká splnění podmínky nutné ochrany již vynaložených investic MŽP. Dalším důležitým faktorem je hledisko času nutného pro realizaci změn implementované BI platformy a případný rozvoj v podobě doplňování dalších služeb a funkcionalit BI platformy, který se realizací architektury založené na službách výrazným způsobem zkracuje a zlevňuje;
o Bezpečnost – jedná se o požadavky na použití jednotlivých bezpečnostních prvků, zálohování a archivaci dat a standardů při vývoji, rozvoji a provozu systému. Nezbytnou součástí realizace platformy BI musí být napojení BI platformy na provozní a bezpečnostní monitoring Poskytovatele či MŽP, který je přístupný pověřeným pracovníkům MŽP. To dá MŽP dostatečně silný nástroj na proaktivní sledování a řízení provozu BI platformy a zároveň nástroj na kontrolu činností Dodavatele, provozovatele BI platformy a případně dalších subjektů podílejících se na službách poskytovaných v souvislosti s platformou BI;
o Ochranu osobních údajů dle GDPR – jedná se o požadavky vyplývající z nařízení Evropského Parlamentu a Rady (EU) č. 2016/679 ze dne 27. dubna 2016, o ochraně fyzických osob v souvislosti se zpracováním osobních ú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ů) a ze
zákona č. 110/2019 Sb., o zpracování osobních údajů;
o Podporovatelnost - jedná se o požadavky na dostupnost podpory od výrobce nebo třetí strany, zaručený upgrade, opravy bugů, plán rozvoje. Tyto požadavky rovněž řeší, zda se systém dobře instaluje, nemá problémy s cílovými hardwarovými a softwarovými konfiguracemi a další vlastnosti související s údržbou systému a upgradovatelností BI platformy;
o Ostatní.
V rámci požadavků na vlastnosti jsou uvedena i návrhová omezení, tj. požadavky zaměřené na specifikaci omezení, která musí Dodavatel SW řešení respektovat při implementaci, rozvoji a provozu Díla. Tyto požadavky jsou zaměřeny především na implementaci vývojových a provozních standardů, politik datové integrity, omezení při volbě technologií (především s ohledem na jejich budoucí podporu) a provozního prostředí systému. Již z dnešního pohledu je zřejmé, že případná omezení se budou odvíjet z již existujícího ICT prostředí MŽP a existujícího informačního okolí BI platformy, v jehož čele stojí Environmentální analytická platforma (EAP) jako zdroj dat a úložiště výstupních zpráv a dokumentů s katalogem dat a Portál STaR MŽP, jako místo pro publikaci BI a analytických výstupů pro veřejnost (tj. produkty dalších 2 projektových úloh projektu STaR).
Pro jednoznačné vymezení závaznosti požadavků je při popisu požadavků využita notace1 pro
stanovení závaznosti využívající termíny:
▪ Termíny „MUSÍ“ nebo „NESMÍ“ vyjadřují závaznost příslušného ustanovení;
▪ Termíny „MĚL BY“, „DOPORUČENO“, „NEMĚL BY“ a „NEDOPORUČENO“ vyjadřují doporučení, ne však závaznost;
▪ Termíny „MŮŽE“ a „VOLITELNÉ“ vyjadřují směr činnosti v rámci přípustných limitů definovaných technickou specifikací.
Požadavky jsou zpracovány jako technologicky neutrální, tj. umožní využití různých infrastrukturních a technologických platforem a nepředurčují, zdali půjde o implementaci standardního („balíkového“) SW, Opensource nebo o vývoj na zakázku.
1 Výše uvedené termíny mohou být při popisu požadavků použity v kterémkoli z gramatických tvarů. Výše uvedená pravidla budou platná pouze pro slova uvedená VELKÝMI PÍSMENY. Tyto termíny jsou interpretovány v souladu s anglickými originály termínů, uvedenými v IETF
„Request For Comments“ č. 2119.
2. Funkční požadavky a požadavky na vlastnosti BI platformy
BI platforma (BI platforma je dále označována rovněž jako „systém“) bude poskytovat následující služby a splňovat uvedené požadavky Objednatele:
Schéma č. 1 - Struktura katalogu požadavků BI platformy
2.1. Funkční požadavky na BI platformu
2.1.1. Požadavky na nástroje pro ETL (transformaci a uložení datových sad)
ID požadavku | Požadavek |
BI-1-1 Podpora řízení datové integrace | BI platforma MUSÍ disponovat grafickým rozhraním (GUI) pro definování jednotlivých pracovních postupů a procesů pro získání, transformaci a uložení potřebných dat pro analýzu a další zpracování (ETL – Extract, Transform and Load): - MUSÍ umět nastavit synchronizační pravidla, tj. plánovat a spouštět jednotlivé úlohy ETL ze zdrojových dat – MUSÍ být možno nastavit minimálně zdroj dat, proces čištění dat, cílové místo uložení, ošetření chybových stavů, čas a frekvenci spouštění (na základě události či v daném čase) o ETL procesy budou spouštěny automaticky v rámci zaplánovaných (zpravidla nočních procesů), současně je však bude i možné spouštět častěji (i opakovaně) např. dílčí úlohy během dne (BI |
ID požadavku | Požadavek |
platforma musí být schopna nastavit periodu „jobu“ alespoň 4x za hodinu či vyšší). Toto spouštění MUSÍ být možné ovládat uživatelsky přímo z portálu anebo externí aplikací; - V rámci transformace a uložení datových sad v datové vrstvě BI platformy MUSÍ být možné skládat data z datasetů načtených z EAP (či jiných datových zdrojů), přičemž MUSÍ být možno tvořit fakta a dimenze (např. více let dohromady) pro plnění datamartů; - MUSÍ umožnit monitoring, logování a automatický reporting stavů zpracování zdrojových dat (job úspěšně prošel, chyba ve zpracování) - správce bude mít možnost libovolný task (včetně jeho následovníků) spustit a sledovat jeho průběh; - MUSÍ umožnit vizualizaci kroků zpracování zdrojových dat - načítání, transformace a uložení dat -> Možnost spojování jednotlivých ETL rutin do jednoho či více procesů a definování závislostí jednotlivých rutin (workflow), tj. možnost deklarativního návrhu a vývoje ETL rutin pro zajištění snadné správy a údržby. S tím souvisí mj.: o Možnost restartovatelnosti ETL procesů (optimálně inteligentní restart z bodu, kdy došlo k pádu ETL procesu); o Možnost logování průběhu a chyb ETL procesů (runtime metadata); o Kontroly konzistence dat (například logickými kontrolami jsou hlídány počty záznamů, sumy z jednotlivé metriky atd.); o Notifikace o výsledcích datových přenosů a kontrol; o Možnost vysledování toku dat ze zdroje; o Možnost definic pravidel datové kvality či korekčních mechanismů pro datovou kvalitu (parametrizace); - MUSÍ umožnit přes GUI řízení/nastavení přístupů a oprávnění ke zdrojovým datům (login na file share, login do databází, login do on-line služeb); - Možnost využití ETL procesů pro získání dat z externích aplikací nebo předání externím aplikacím (např. prostřednictvím webových služeb – REST a SOAP). | |
BI-1-2 Podpora řízení metadat | BI platforma MUSÍ podporovat tvorbu a správu metadat a disponuje rozhraním pro práci s metadaty. |
BI-1-3 Export ETL logu | BI platforma MUSÍ umožnit export ETL logu anebo jeho zpřístupnění uživateli pro další zpracování/archivaci za účelem auditovatelnosti původu dat v BI výstupech (tj. zdroj dat, proces čištění dat, provedené transformace, cílové místo uložení). Nad logem MUSÍ být možno vytvořit report.. |
BI-1-4 Zdroj dat z EAP | Hlavním zdrojem dat pro BI platformu bude EAP (Platforma pro ukládání a transformaci dat MŽP) realizovaná v prostředí CKAN (bude obsahovat vyčištěné zkontrolované garantované a dále strojově zpracovatelné datové sady z jednotlivých agend resortu ŽP. |
ID požadavku | Požadavek |
BI platforma MUSÍ umožňovat napojení pomocí ETL na úložiště datových sad v EAP, s použitím technologií RESTfull API, viz: - xxxxx://xxxx.xxxx.xxx/xx/0.0/xxx/ a - xxxxx://xxx.xxxxxxx.xx/xxxxx/xx/xxxxxxxxxxxxx/xxxxxxxxx/xxxxxxx/xxxx- apis.html. Datové sady v EAP, jejich počet, rozsah, struktura dat i způsob realizace rozhraní na EAP MŮŽE být v Etapě 2 plnění měněn, a to zejména ve vazbě na požadavky Objednatele připojovat nové datové zdroje z AIS nebo strategické směřování agend v resortu MŽP. Tyto změny budou řešeny rozvojem či rekonfigurací systému (tj. formou čerpání provozních služeb BI_08 a BI_09), MUSÍ být však funkčními možnostmi řešení BI platformy umožněny a zohledněny již v návrhu řešení. | |
BI-1-5 Zdroje dat z dalších IS resortu MŽP | Platforma BI MUSÍ umožňovat následující vstupní kanály: 1. Relační databáze dostupné přes aplikační rozhraní ODBC/JDBC (zejména Microsoft SQL Server, Oracle Database, a další). BI platforma MUSÍ zajišťovat JDBC připojení na libovolný datový zdroj a UMOŽŇUJE automatizovaně načítat data přes JDBC rozhraní. 2. Konektory minimálně na všechny typy RDMBS (PostgreSQL, MySQL5.1+, Oracle 10g+, MS SQL Server 2005+, Firebird) a nerelační databázi MONGO DB využívané IS MŽP. 3. File system – podporuje standardní napojení TCP transfer protokoly (FTPS, SCP, SFTP, HTTPS aj.) pro získání nerelačních datových zdrojů (min. Objednatel požaduje Microsoft Excel, strukturované soubory formátu txt, CSV, JSON, XML, html, zip). MUSÍ umožňovat hromadné načítání (a indexaci) ze síťových/webových složek. 4. Komunikace s webovými službami a protokoly: min. Objednatel požaduje REST, SOAP, ke kterým existuje standardizované rozhraní (API) s důrazem na spolehlivost a aplikační rozšiřitelnost. 5. Vstupní rozhraní v rámci BI vrstvy – manuální zadávání vstupních dat na úrovni BI vrstvy a jejich zpracování a ukládání do datové základny. BI platforma MUSÍ umožnit propojení s jinými resortními a mimorezortními IS a databázemi výše uvedených typů a poskytujících výše uvedená API. |
BI-1-6 Ostatní zdroje dat | BI platforma MUSÍ umožnit zpracování i datových zdrojů, které nejsou zcela vyčištěné a nejsou strukturované. Tj. MUSÍ poskytovat nástroje pro kontrolu a úpravu, vstupních datových zdrojů do struktury vhodné pro zpracování a reportování. |
BI-1-7 Záznamy o načítání dat | Systém MUSÍ uchovávat informace o načítání, zpracování a kvalitě dat. |
ID požadavku | Požadavek |
BI-1-8 Ukládání do externích úložišť | BI platforma MUSÍ umožnit zápisy i do externích úložišť a okolních systémů přes API či jiným způsobem. Pro zápis je možné použít vložení skriptu v rámci GUI rozhraní. |
2.1.2. Požadavky na nástroje pro sémantickou datovou vrstvu
ID požadavku | Požadavek |
BI-2-1 Centrální datová vrstva | Systém MUSÍ disponovat centrálním datovým úložištěm, ve kterém budou ukládána transformovaná, vyčištěná a konsolidovaná data potřebná a vhodná pro reportovací povinnosti MŽP. Centrální datová vrstva MUSÍ umožnit uložení: - Strukturovaných dat; - Vyčištěných historizovaných datových záznamů (fakta a dimenze /číselníky), ve formě, která je dále zpracovatelná jednotlivými komponentami BI platformy v rámci opakovatelného použití; - Datové záznamy MUSÍ být v centrální datové vrstvě opatřeny časovými značkami (datum vzniku, platnost od, platnost do, zdroj dat, fáze zpracování dat); - Musí umožňovat přírůstkové plnění a plnění na vyžádání. |
BI-2-2 Historizace dat | Systém MUSÍ pomocí historizace dat umět poskytovat data (a tedy i reporty) v časových řezech (tj. schopnost vrátit se k verzi dat/reportu ve stavu k určitému časovému okamžiku). Jedná se o požadavek na automatické řešení problematiky historizace dat v datovém modelu, kdy se obvykle řeší jedna nebo dvě časové osy. První je časová osa „technická“ spojená s historizací záznamu (s časem jeho uložení, změny nebo zneplatnění v datovém skladu). Druhá časová osa je navázána na business čas vzniku, aktualizace nebo zániku záznamu. Doba historizace není omezená. Systém MUSÍ umožnit export vybraných historizovaných dat do souboru ve formátu .CSV nebo .XML, který následně pověřený uživatel uloží do CKAN (příp. stanoveného archivu), a to včetně příslušného opatření metadaty. |
BI-2-3 Reportovací modely | Nad centrální datovou vrstvou MUSÍ být možno vytvářet jeden a více „reportovacích“ modelů (tj. datamartů pro jednotlivé oblasti/agendy MŽP). Reportovací modely představují sémantické dimenzionální datové modely (dimenze, fakta a indikátory z různých agend), včetně dopočtených ukazatelů a metrik. Systém MUSÍ disponovat nástroji pro vytváření datových vrstev připravených pro reportování a tvorbu BI výstupů s daty ve formě faktů |
ID požadavku | Požadavek |
a dimenzí s možností definice vypočtených ukazatelů tak, aby uživatelé, Tvůrci sestav, se základní znalostí struktury reportovacího modelu (tj. bez znalosti struktury zdrojových/původních dat) mohli pomocí vizualizačních nástrojů vytvářet grafy a tabulky bez nutnosti programování s možností nastavení automatizovaného ukládání jednotlivých verzí (zajištění verzování) anebo logů verzí. Nad rámec výše uvedeného MUSÍ BI platforma nabídnout pro pokročilé uživatele (Datové analytiky/Power usery či Tvůrce sestav) možnost využití skriptovacích jazyků/programátorských zásahů pro vytváření vlastních definic vypočtených ukazatelů/indikátorů (tj. možnost si indikátory „doprogramovat“). MUSÍ být možno vytvářet separátní reportovací modely pro jednotlivé agendy MŽP atp. Uživatelům MUSÍ být přístupný nástroj pro tvorbu popisů jednotlivých prvků reportovacího modelu pro účely vytváření BI výstupů. Vytvořené popisy MUSÍ být přístupné Tvůrcům sestav. |
2.1.3. Požadavky na nástroje pro analýzy dat
ID požadavku | Požadavek |
BI-3-1 Rozsah analytických úloh | Systém MUSÍ umožňovat vytěžit všechna data importovaná z EAP či jiných zdrojů do BI platformy v různých kombinacích a podmínkách (při dodržení ustanovení právních předpisů o ochraně osobních údajů), a to s využitím dále popsaných nástrojů pro analýzy dat. |
BI-3-2 Pokročilejší datové analýzy a předpokládaný rozvoj BI platformy do budoucna | BI platforma MUSÍ nabízet od okamžiku svého spuštění možnosti pokročilejších datových analýz (zejména korelační analýzy, analýzy scénářů, forecasting časových řad, rozhodovací stromy) prostřednictvím vlastních konfiguračních nástrojů s možností vládání skriptů v jazyku |
R/Python. | |
BI platforma MUSÍ dále umožňovat budoucí rozšiřitelnost, a to zejména | |
o: | |
- Linkové analýzy; | |
- Scoringový engine; | |
- Machine learning. | |
Rozvoj BI platformy MUSÍ být možný formou dokoupení (dolicencování) | |
dalších modulů/funkcí, tj. bez nutnosti nahrazovat dříve nasazené | |
komponenty či bez rizik zmaření předchozích investic MŽP do licencí či | |
produktů původně nasazené BI platformy atp. |
ID požadavku | Požadavek |
BI-3-3 Statistické analýzy | BI platforma MUSÍ disponovat sadou základních statistických procedur a funkcí, které lze realizovat a automatizovat/periodicky opakovat nad vybranými datovými sadami a výstupy těchto procedur lze přidávat do vytvářených grafů. Statistické metody MUSÍ zahrnovat zejména rozdíl a relativizaci hodnot, násobení koeficienty, přepočet dle vzorců, automaticky kalkulovanou trendovou křivku, modus, medián, průměr, rozptyl, směrodatnou odchylku, průměrnou odchylku (popisující disperzi hodnot), rozdělení a testování hypotéz. BI platforma MUSÍ pro statistické a pokročilé analýzy podporovat využití jazyka R a/nebo Python (zejména při tvorbě vzorců). Výstupy (dopočtené hodnoty) statistického zpracování MUSÍ být možno následně napojit/zahrnout (v tabelární či grafické podobě) do nástěnek (dashboardů), mapových podkladů či vytvářených reportů. |
BI-3-4 Tvorba ad-hoc analýz | BI platforma MUSÍ umožnit vytvořit ad-hoc datové analýzy pomocí intuitivního grafického uživatelského prostředí. Takto vytvořené analýzy MUSÍ být možno uložit a publikovat na interním portálu BI platformy pro použití dalšími uživateli. |
2.1.4. Požadavky na funkční vlastnosti nástrojů pro vizualizaci dat
ID požadavku | Požadavek |
BI-4-1 Vizualizace pomocí grafů | Nástroje pro vizualizaci BI platformy MUSÍ disponovat širokou paletou vizualizačních prvků, typů grafů, které bude možné spolu spojovat a libovolně kombinovat. Mezi typy vizualizací, které nástroj pro vizualizaci MUSÍ umožňovat v rámci vestavěných funkcí, patří: - Pruhové a sloupcové grafy; - Spojnicové grafy; - Kombinované grafy (kombinace sloupcového a spojnicového grafu); - Plošné grafy; - Dlaždice/karty s jednou nebo více hodnotami; - Koláčové (výsečové) grafy; - Zobrazení statistik v mapách (pro zobrazení kategorických a kvantitativní hodnot v umístění na mapě formou kartogramu nebo kartodiagramu) – požadavky na mapové podklady jsou uvedeny v rámci požadavku BI-7-11 BI Rozhraní pro mapové služby - Podpora vizualizace informací v mapách; V rámci vestavěných funkcí BY nástroje dále MĚLY umožňovat tvorbu následujících typů vizualizací: |
ID požadavku | Xxxxxxxxx |
- Xxxxxxxxxx grafy; - Vodopádové grafy; - Měřidla / semafory; - Trychtýřové grafy; - „Tree“ mapy. - Klíčové ukazatele výkonu (KPI – vizuální upozornění pokroku k měřitelnému cíli). | |
BI-4-2 Vizualizace pomocí tabulek | Nástroje pro vizualizaci BI platformy MUSÍ disponovat vizualizačními prvky typu fixních tabulek a matic, jejichž vzhled lze formátovat, a to minimálně následovně: - Tabulky: o S možností zapínat/vypínat řádkové a sloupcové součty; o S možnostmi nastavování barev písma, pozadí anebo datových pruhů buněk dle dosažení definovaných hodnot; o Zobrazení „tooltipu“ s detailem po najetí/označení hodnoty – včetně nastavení rozsahu informací. - Matice / kontingenční tabulka (navíc k výše uvedeným vlastnostem tabulek): o S možností hierarchického rozpadu řádků (procházení k podrobnostem) buď rozbalením do dalších sloupců anebo stupňovitě; o S možností hierarchického rozpadu sloupců; o S možností zapínat/vypínat mezisoučty úrovní; o S možností formátovat; o S možností zapínat/vypínat možnost modifikace finálních grafů či tabulek externími uživateli; o Možnost aliasů – přejmenovávání textových kategorií proměnných; o Možnost zapnout/ vypnout názvy sloupců/řádku a jejich formátování, přepisování; o Zobrazení „tooltipu“ s detailem po najetí/označení hodnoty – včetně nastavení rozsahu informací. |
BI-4-3 Formátování | Systém MUSÍ umožnit uživatelské formátování (tj. přes grafické rozhraní) vizualizačních prvků (tj. formátování písma, barev prvků, popisků, rozměrů). |
BI-4-4 Drill down/up | BI platforma MUSÍ disponovat možnostmi interaktivní vizualizace dat (drill down/up přes vizualizační prvky analytických sestav a výstupů, tj. zacílení na detail určité části grafu/matice (drill-down) a agregace dat do menšího detailu s vyšší komplexitou (drill-up)). |
BI-4-5 Filtrování, průřezy | Vizualizační nástroje BI platformy MUSÍ umožnit filtrování dat dle parametrů/dimenzí (různé filtry musí být možné nastavit na jednotlivé prvky sestavy). |
ID požadavku | Požadavek |
BI-4-5 Filtrování přes vizualizační prvky | Vizualizační nástroje BI platformy MUSÍ umožnit vzájemné profiltrovaní vizualizačních prvků - provázání více tabulek grafů – závislostní interaktivita. A zároveň MUSÍ BI platforma umožnit tuto vlastnost uživatelům v případě potřeby vypnout. |
BI-4-6 Rozšiřitelnost vizuálních prvků | BI platforma MUSÍ disponovat možnostmi rozšíření základních vizuálních prvků o další „uživatelské“ prvky (vlastní (doprogramované) nebo vytvořené třetími stranami – např. JS knihovny, D3.js). Uživatelé si tak mohou vytvářet vlastní vizuální prvky. |
BI-4-7 Podpora tvorby dashboardů | BI platforma MUSÍ podporovat vytváření vlastních dashbordů výběrem vizualizačních prvků v sestavách. Tyto komponenty umožní drill down na vybraný detail a přechod do příslušné sestavy s podrobnějšími analytickými nebo statistickými výstupy. MUSÍ být možné získat EMBED kódy sestav a dashboardů. MUSÍ být možné nastavit selektivně synchronizaci zobrazení mezi částmi sestavy tak, aby označené prvky v jednom pohledu (např. kartodiagram) představovaly filtr, který mění i rozsah zobrazených hodnot v jiné částí (pohledech) sestavy (graf, tabulka). Pokročilým uživatelům (Datovým analytikům, Tvůrcům sestav či Redaktorům) MUSÍ BI platforma umožnit sestavy/dashboardy sdílet pro další autorizované uživatele případně pro veřejnost (oprávněný uživatel sestavu/dashboard buď přímo opublikuje na portálu MŽP, nebo předá EMBED kód nebo URL odkaz pro začlenění tohoto výstupu do příslušného webu). |
BI-4-8 Možnosti exportu vytvořených sestav a grafických výstupů | BI platforma MUSÍ umožnit vyexportovat zvolené sestavy a grafické výstupy minimálně do formátů PDF, PNG. Data všech vizuálních prvků sestav (tabulek, grafů) MUSÍ umožnit exportovat minimálně do formátu CSV, XLSX. |
BI-4-9 Dokumentace k řešení | K nástrojům pro vizualizaci dat MUSÍ být dostupná uživatelská dokumentace alespoň v českém jazyce. Administrátorská dokumentace MŮŽE být v češtině nebo v angličtině. |
2.1.5. Požadavky na výstupní kanály/rozhraní (publikování výstupů)
ID požadavku | Požadavek |
BI-5-1 Výstupní kanály | Systém MUSÍ nabízet minimálně následující výstupní kanály: 1. Možnost definovat pohledy na data v datové vrstvě (např. SQL views) dle požadavků na přístup aplikací mimo platformu BI k datům z datové vrstvy BI. Neomezené poskytnutí dat z platformy BI aplikacím jiného Dodavatele je součástí poskytnuté/zakoupené licence. 2. E-mail – napojení na SMTP server pro automatické zasílání notifikací a reportů. 3. WEB – poskytování nástrojů pro vizualizaci výstupů formou tenkého klienta s možností exportu výstupních dat / sestav na lokální i sdílený file system (mimo mobilních zařízení) vč. exportu výstupů do souborů (min. CSV, XLSX, PPTX, PDF, PNG, , XML, HTML-JS pro embeding). Pozn.: Objednatel si dle svých metodických postupů vyžaduje vytváření kopií/verzí BI výstupů ke konkrétnímu datu a tyto kopie si bude ukládat ve formě dokumentu do EAP (CKAN), přičemž dokumenty budou opatřeny metadatovým popisem, a to za účelem auditovatelnosti původu a stavu dat v BI výstupech. 4. Mobilní zařízení – platforma BI MUSÍ být připravena na zobrazení výstupů ve zjednodušené formě v mobilním zařízení optimalizované pro všechny druhy přenosných zařízení, jako jsou mobily, tablety, notebooky s dotykovým displejem atp., a pro ovládání pomocí dotykového displeje včetně jednoduchých filtrů umožňujících uživateli rychlé a intuitivní filtrování hodnot. V rozsahu realizace projektu do jeho akceptace NEMUSÍ BÝT dodávka vlastní komponenty pro Mobilní zařízení, ale pouze garance výstupního rozhraní bez dalších omezení, které implementaci usnadní v rámci rozvoje řešení. 5. Připojení aplikací mimo platformu BI k aplikačnímu rozhraní ODBC/JDBC (Microsoft SQL Server, Oracle Database, IBM DB2 aj.) a API (min. REST). Některé Datamarty2 tedy slouží jako datový zdroj (konsolidovaná základna) pro další aplikace mimo platformu BI. |
BI-5-2 Standardizované extrakty dat | Systém MUSÍ být schopný poskytovat standardizované extrakty dat jako vstupy do nadstavbových analytických, resp. modelovacích nástrojů (tyto nástroje mohou být i třetích stran). |
2 Datové tržiště (Datamart) obsahuje podmnožinu dat celého datového skladu. Datové tržiště slouží pro analytické účely určité části BI platformy. MŽP bude vytvářet více datových tržišť např. pro jednotlivé agendy MŽP apod. Datové tržiště je postaveno na dimenzionálním modelu dat. Dimenzionální struktury pracují na relačním modelu dat, kde jedna tabulka, označovaná jako tabulka faktů, reprezentuje sledované numerické ukazatele. Další tabulky potom reprezentují jednotlivé dimenze.
2.1.6. Požadavky na Zpřístupnění dat pro Portál STaR MŽP (publikování výstupů)
ID požadavku | Požadavek |
BI-6-1 Propojení na Portál STaR MŽP | Systém MUSÍ zajistit jednoduchý způsob integrace (embedování) na připravovaný publikační intranetový a extranetový Portál STaR MŽP, přes který budou oprávnění uživatelé spravovat obsah webu tak, aby mohli do připravovaného obsahu vkládat vytvořené sestavy anebo dashboardy. Pozn.: Pro řízení přístupu k externímu obsahu (např. přístup odborné veřejnosti k vybraným publikacím STaR BI, nebo přístup vybraných interních uživatelů k publikovanému obsahu některých DB v rámci intranet webů) bude Portál STaR podporovat minimálně dva různé modely bezpečného předání identity autentizovaného uživatele a autorizace přístupu ke chráněnému externímu obsahu. Konkrétní modely předávání autentizačních a autorizačních informací budou definovány v detailním návrhu Portálu STaR a mohou obsahovat následující mechanismy: - Vytváření jednorázových tokenů obsahujících nebo odkazujících na autentizační a autorizační informace s využitím kryptografických postupů; - Předávání tokenů v HTTP cookies nebo v parametrech URL vložených do web stránek; - Back-end web service zpřístupňující poskytovatelům externího obsahu informace z autorizační databáze Portálu STaR; - Součástí autorizační databáze portálu bude udržování oprávnění redaktorů vkládat odkazy na autorizovaný externí obsah jednotlivých zdrojů externího obsahu. |
BI-6-2 Zpřístupnění BI výstupů (dat) pro uživatele na Portálu STaR | Systém MUSÍ umožnit uživatelům pracovat s BI výstupy formou využívání publikovaných (tj. generováním Embeded kódu) BI výstupů (dashboardů, sestav) v rámci zpřístupněné části Portálu STaR (pro logované nebo nelogované uživatele). Systém MUSÍ umožnit privilegovaným uživatelům rozhodnout, kdy a jaké sestavy či dashboardy budou publikovány do veřejné části Portálu STaR, a to bez závislosti na Dodavateli BI platformy či Portálu STaR. Pro veřejné uživatele NESMÍ existovat licenční omezení k přístupu k datům, sestavám a funkcím veřejně publikovaných sestav. |
BI-6-3 Veřejný obsah zpřístupněný na Portálu STaR | Veřejná část Portálu STaR bude k dispozici pro veřejnost bez registrace a přihlášení uživatele. Publikovaný veřejný obsah z BI platformy (tj. příslušné BI výstupy) tak NESMÍ vyžadovat autentizaci a autorizaci uživatele vyžadovanou BI platformou, a tedy musí obsahovat jen veřejně přístupná data. |
ID požadavku | Požadavek |
BI-6-4 Údaje o platnosti výstupů BI | Publikované výstupy BI MUSÍ vždy obsahovat informaci, za jaké období jsou publikovaná data ve veřejné i v neveřejné části zpřístupněna (např. kdy byl BI výstup vytvořen a nad jakými daty - za jaké poslední ohlašovací období jsou data publikována atp.). |
2.2. Průřezové funkční požadavky
ID požadavku | Požadavek |
BI-7-1 Self-service BI | BI platforma MUSÍ podporovat tzv. self-service BI – intuitivní a uživatelsky přívětivé prostředí s minimální potřebou pokročilého programování a skriptování pro koncové uživatele, grafické rozhraní drag&drop pro tvorbu výstupních sestav (reportů) a vizuálních výstupů s možnostmi: - Analýzy dat; - Filtrování dat; - Definování databázových dotazů; - Transformace dat; - Aplikování podmínek formátování dat; - Vytváření interaktivní přehledů a pohledů na data. |
BI-7-2 Nástroje pro pokročilé uživatele | Nad rámec prostředí self-service BI MUSÍ BI platforma nabídnout pro pokročilé uživatele (Datové analytiky/Power usery či Tvůrce sestav) možnost využití skriptovacích jazyků/programátorských zásahů zejména pro: - „Uživatelskou“ transformaci a čištění dat i na úrovni nástrojů pro vizualizaci dat, kterou je možné využít při přípravě pracovních verzí reportů a výstupů; - Definici (programování) vypočtených ukazatelů a metrik; - Vytvoření vlastních vizuálních prvků; - Realizaci standardizovaného API pro přístup k datům v datové vrstvě; - Realizaci exportů dat z datové vrstvy. |
BI-7-3 BI Zpřístupnění dat | Systém MUSÍ umožnit v rámci BI platformy ověřeným/přihlášeným uživatelům pracovat s daty a funkcemi formou: - Vyhledáváním dat – požadována je možnost pokročilého vyhledávání v rámci fulltextu čili části hledaného textového řetězce, např. při zadání 1. 3 znaků textového řetězce.; - Možnosti exportu veřejných dat; - Využívání přednastavených nebo tvorbou (oprávněnými uživateli) vlastních nástěnek (dashboardů), vč. možnosti vybrat |
ID požadavku | Požadavek |
z dashboardů vizuální prvky, které uživatel umístí na jiný dashboard (např. svůj vlastní dashboard); - Využívání přednastavených nebo tvorbou (oprávněnými uživateli) vlastních sestav, vč. možnosti vybrat ze sestav vizuální prvky, které uživatel umístí do sestavy (např. své vlastní sestavy). | |
BI-7-4 Webový BI portál, který je součástí BI platformy | Systém MUSÍ disponovat BI webovým portálem pro publikaci BI výstupů přístupný z interního IT prostředí MŽP/CENIA (dále též „interní portál BI platformy“). Systém MUSÍ umožňovat filtrovat zobrazená data a umožnit diferencovaný přístup uživatelů k datům pod uživatelskými identitami řízenými pomocí IDM (viz zejména požadavek BI-12-1). Cílem je vysoká bezpečnost BI vzhledem ke kybernetickému napadení, přístupu nepovolených uživatelů, úniku informací apod. Systém MUSÍ umožňovat řízení přístupu uživatelů a jejich oprávnění na úrovni jednotlivých samostatných komponent BI platformy. Publikační rozhraní MUSÍ být schopno vyhovět požadavkům více uživatelů ve stejném čase (cca 20 uživatelů pracujících současně) s přiměřenou dobou odezvy (viz požadavky na výkon). |
BI-7-5 BI Vyhledávání dat | Systém MUSÍ umožnit uživatelům vyhledávání nad všemi datovými entitami sémantické datové vrstvy a zobrazení detailu dané entity. Vyhledávání MUSÍ být možné napříč všemi atributy evidovanými pro jednotlivé entity v sémantickém modelu. Detail vyhledané entity MUSÍ obsahovat veškerá data uchovávaná v systému, která jsou uživateli přístupná. Systém MUSÍ umožnit MŽP/CENIA vizuální modifikaci detailu, jež bude k entitě zobrazován. |
BI-7-6 BI Sestavy, dashboardy a vizualizace dat | Systém MUSÍ umožnit vytvoření sestav a/nebo dashboardů (nástěnek) jako prvků pro vizualizaci dat (tabulek, grafů, zobrazení v mapovém podkladu atp. - viz zejména požadavky BI-4-1 a BI-4-2), a to nad všemi datovými sadami a jejich entitami v sémantické datové vrstvě BI platformy. Systém MUSÍ umožňovat vytěžit všechna data ze sémantické datové vrstvy BI platformy v různých kombinacích a podmínkách (při dodržení ustanovení právních předpisů o ochraně osobních údajů). Systém MUSÍ umožnit oprávněným uživatelům: - Zobrazení předpřipravených sestav/dashbordů; - Tvorbu vlastních sestav/dashboardů. |
ID požadavku | Požadavek |
Systém MUSÍ umožnit uživatelům tvorbu reportů nad všemi dostupnými daty v sémantické datové vrstvě, pokud tak budou označena, a to dle výběru uživatele: - Průběžnými daty (tj. nad daty v průběhu jejich zpracování, které ještě není uzavřeno); - Finálními daty (tj. verifikovanými daty); - Přepočítanými daty (např. daty upravenými dle metodik pro výpočet indikátorů). Systém MUSÍ umožnit vytváření sestav a vizualizaci dat v grafickém rozhraní bez nutnosti použít programovací či skriptovací jazyk. Systém MUSÍ umožnit vytváření prezentací složených z jednotlivých vizualizací dat. Nad rámec výše uvedeného MUSÍ BI platforma nabídnout pro pokročilé uživatele (Datové analytiky/Power usery či Tvůrce sestav) možnost využití skriptovacích jazyků/programátorských zásahů pro vytváření sestav a vizualizaci dat v grafickém rozhraní (tj. možnost si BI výstupy doprogramovat). | |
BI-7-7 Aktualizace obsahu BI výstupů | Obsah BI výstupů MUSÍ být možné aktualizovat: - Na základě definované události (např. existence nových/aktualizovaných dat atp.); - Pravidelně ke stanovenému času; - Manuálně. |
BI-7-8 Využití BI výstupů | BI výstupy MUSÍ být možné: - Publikovat na Portál STaR (veřejně přístupnou část i část vyžadující přihlášení uživatele – přístupová oprávnění řídí Portál STaR); - Zpřístupnit vymezené skupině uživatelů s příslušnými přístupovými oprávněními v rámci BI platformy; - Distribuovat prostřednictvím elektronické pošty; - Vložit do uživatelských dokumentů (viz požadavek „Embedování sestav a dashboardů do dokumentů sady Office“); - Exportovat do obvyklých formátů: XLSX, DOCX, PDF, XML. |
BI-7-9 BI jednotný metamodel | Systém MUSÍ uživatelům umožnit tvorbu BI výstupů (sestav, dashboardů) pouze se znalostí sémantické datové (reportovací/prezentační) vrstvy a uživatelsky srozumitelného datového modelu, který bude jednotný pro celý systém a bude vytvořen již ve fázi přípravy dat. |
ID požadavku | Požadavek |
Jednotný datový model včetně dokumentace MUSÍ být přístupný vymezeným uživatelům systému (Datovým analytikům/Power userům a Tvůrcům sestav). Datový model MUSÍ být možné tvořit, měnit, doplňovat a spravovat vizuálně prostřednictvím grafického uživatelského rozhraní. | |
BI-7-10 BI Vizuální práce s daty | Veškerá práce s daty (tj. jak vyhledávání a prohlížení, tak i tvorba sestav a dashboardů) MUSÍ probíhat vizuálně, bez nutnosti vývojářských zásahů. Prvky na sestavách / dashboardech se mohou vzájemně ovlivňovat, tj. např. volbou filtru na jednom prvku musí být možné ovlivnit i ostatní prvky na nástěnce nebo reportu. |
BI-7-11 BI Rozhraní pro mapové služby - Podpora vizualizace informací v mapách3 | BI platforma MUSÍ umožnit vizualizaci vybraných metrik na interaktivních mapových pokladech bez nutnosti zakoupení dodatečných licencí (BI platforma MUSÍ umět napojit a zobrazit Web Map Service (WMS), např. (viz např. xxxxx://xxxxxxxxx.xxx.xx/xxx/xxxxx/xxx/)). Řešení MUSÍ umožnit „zoom-in/out“ na vybraný mapový detail, posouvat mapu, vycentrovat na základě filtru územní jednotky, označovat datové jednotky na základě výběru (min. obdélníkového). Tento výběr pak plní funkci filtru dat. Zobrazení „tooltipu“ s detailem po najetí/označení objektů – včetně nastavení rozsahu informací. Systém MUSÍ disponovat prostředky pro uložení geografických dat a rozhraním pro jejich zpřístupnění pro specializované nástroje založené na standardech definované evropskou iniciativou INSPIRE - OGC WFS 1.3 a OGC WFS 2.0, tj. BI platforma MUSÍ být schopna poskytnout data pro mapové aplikace/služby založené na výše uvedených standardech. Statistické/agregované údaje MUSÍ být opatřeny geografickými dimenzemi, pokud tyto dimenze obsahují vstupní data (datové sady z EAP a dalších datových zdrojů). Vlastní vytváření detailních výstupů v mapových podkladech (co bude v jaké úrovni map zobrazováno, jaké piktogramy v mapě budou využívány atp.) budou provádět specializovaní uživatelé CENIA mimo platformu BI v již existujících nástrojích (není tedy součástí zadání/dodávky BI platformy). |
3 Pozn.: Tímto požadavkem je myšleno zobrazování statistických údajů v mapě, například na úrovni krajů nebo dle uvedených souřadnic v datech jednotlivých agend vztažených k určitému geografickému bodu, resp. oblasti. MŽP/CENIA disponuje licencemi specializovaných geografických aplikací včetně mnohavrstevných datových podkladů pro prezentaci.
ID požadavku | Požadavek |
BI-7-12 Alerting (událostní notifikace) | Systém MUSÍ poskytovat funkcionalitu alertů a notifikací včetně jejich správy - automatické notifikace při naplnění datových podmínek a dle definice uživatelsky definovaných pravidel. Systém MUSÍ umožnit: - Vytvoření nového alertu definicí podmínek; - Editaci pravidel alertu; - Smazání alertu; - Editaci možností zobrazování alertů (treshold). Systém MUSÍ umožňovat distribuci BI výstupů na základě rozhodnutí uživatele anebo dle uživatelsky definovaných pravidel (načasování zveřejnění aktualizovaných výstupů). |
BI-7-13 Embedování sestav a dashboardů do dokumentů sady Office (tvorba uživatelských dokumentů/reportů) | Součástí řešení MUSÍ být nástroje pro uživatelsky jednoduché začlenění vytvořených BI výstupů (sestav, dashboardů, jednotlivých vizuálních prvků) do připravovaných dokumentů vytvářených v aplikacích MS Office (MS Word, MS Excel) (dále též „uživatelské reporty“) - možno i jako produkt třetí strany formou add-onu. Tj. BI výstupy budou sloužit jako informační vstupy do ročenek, indikátorů, reportů, celorepublikových zpráv atp. Klíčovými dokumenty jsou zejména „Zprávy a životním prostředí ČR“ a Zprávy o životním prostředí v jednotlivých krajích ČR“, „Statistická ročenka ŽP ČR“ a dále indikátory, resp. indikátorové sady/zprávy hodnotící nejen stav ŽP, ale i další aspekty, např. udržitelný rozvoj, adaptaci na změnu klimatu apod. Pro tyto dokumenty, resp. indikátory budou existovat předpřipravené makety (šablony), které kombinují textové popisy s vkládanými informačními vstupy ve formě tabulek, grafů či map. Tyto informační vstupy budou zcela či částečně připravovány v BI platformě (sestavy a jejich části). Je požadováno, aby umístění jednotlivých BI výstupů bylo možné definovat přímo v dokumentu a v průběhu vytváření konkrétní zprávy (reportu) byly on-line vloženy do příslušného dokumentu. Systém MUSÍ nabízet uživatelsky přívětivé prostředí, ve kterém budou oprávnění uživatelé vytvářet, modifikovat a rušit pravidla pro začlenění BI výstupů do dokumentů (uživatelských reportů). Designer pravidel MŮŽE být produktem třetích stran. MUSÍ umožnit: - Vytvoření nového pravidla; - Editace stávajícího pravidla. Některé dokumenty budou mít standardizovaný text a definované BI výstupy se po otevření dokumentu zaktualizují automatizovaně, |
ID požadavku | Požadavek |
některé dokumenty budou pouze částečně předvyplněny a zbylá pole následně manuálně vyplní pracovníci MŽP/CENIA. Konkrétní způsob u každého jednotlivého dokumentu bude stanoven uživatelem v okamžiku přípravy dokumentu/reportu (tj. při začlenění vytvořených BI výstupů (sestav, dashboardů, jednotlivých vizuálních prvků) do připravovaných dokumentů vytvářených v aplikacích MS Office). Rozhraní pro dokumentové výstupy MUSÍ být schopno vyhovět požadavkům více uživatelů ve stejném čase (cca 20 uživatelů pracujících současně) s přiměřenou dobou odezvy (viz požadavky na výkon). | |
BI-7-14 Příprava výstupů ve formátu XML | Pro zajištění řady reportovacích povinností MŽP směrem do EU jsou definovány povinné struktury ve formátu XML, resp. odvozených formátech GML apod. včetně šablon XSD. Je požadováno, aby systém UMOŽNIL uživatelům/tvůrcům těchto výstupů vytvářet výstupy XML i bez pomoci skriptování (tj. přes uživatelské GUI) v definované struktuře. |
3. Požadavky na vlastnosti BI platformy
3.1. Požadavky na architekturu
ID požadavku | Požadavek |
BI-8-1 Architektura systému | Architektura BI Platformy MUSÍ vycházet ze zásad a principů servisně orientované architektury. Systém MUSÍ být navržen na předpokládanou dobu životnosti 10 let a více let. Architektura musí být připravena na pravidelné i nepravidelné modifikace, doplňování a úpravy služeb, datových struktur a dalších prvků dle potřeb MŽP/CENIA a dle změn v právních předpisech. Z důvodu pravidelné komunikace s okolními informačními systémy se systém MUSÍ umět napojit na zabezpečená API. Přístup k BI vizualizační komponentě MUSÍ být možný přes webové rozhraní (analýza dat, vizualizace reportů). Pro ostatní komponenty (resp. jejich GUI) je preferován také webový přístup (tenkým klientem) nicméně jsou přípustné i desktopové instance (těžký klient). Další požadavky na architekturu zahrnují: - Modulární, rozšiřitelná a škálovatelná architektura SW i HW řešení. Stejná základní architektura pro všechny fáze životního cyklu BI platformy, liší se jen škálováním výkonu a kapacit; |
ID požadavku | Požadavek |
- Architektura a provozní postupy MUSÍ umožnit zajištění vysoké dostupnosti (HA), i když při spuštění nebude BI platforma provozována jako HA aplikace. Možnost využití HA funkcí na úrovni virtualizace pro ochranu proti výpadku HW. Objednatel doporučuje využití architektury s redundantními aplikačními a databázovými servery pro ochranu proti chybě administrátora nebo SW. Dodavatel MUSÍ v nabídce důvěryhodně vysvětlit mechanismy umožňující dodržení požadovaného SLA vyřešení kritického incidentu pro případy výpadku HW jednoho serveru a pro případy chyby administrátora nebo SW (smazání části systému nebo DB, poškození DB atd.). | |
BI-8-2 On premise vs. cloud | BI platforma MUSÍ být cloud ready. Tedy jednotlivé komponenty a služby MUSÍ být možno provozovat v cloudu včetně možnosti kontejnerizace. BI platforma musí být provozovatelná v prostředí nejvýznamnějších poskytovatelů cloudových služeb dostupných v ČR a musí být snadno migrovatelná do těchto prostředí. Je přípustné využití kontejnerové virtualizace či obdobné formy virtualizace. |
Objednatel | |
BI-8-4 Technologie přípustné pro tvorbu, údržbu a rozvoj BI platformy | Systém NESMÍ být postaven na proprietárních SW řešeních a technologiích. Systém MUSÍ být vybudován pouze za pomoci standardizovaného SW (vč. standardizovaného Opensource) doplněného o části, které jsou vyvinuty v rámci plnění předmětu této veřejné zakázky. Standardizované SW produkty jsou softwarové produkty autora/Dodavatele BI platformy nebo třetích stran, na kterých je BI platforma vytvořena a provozována a které nebyly vyvinuty autorem specificky pro účely BI platformy MŽP. Standardizované SW produkty nebo též SW platforma je souborné označení pro softwarové komponenty BI platformy, např. pro serverový operační systém, databáze, databázový ovládač/nadstavba, aplikační server, webový server, frameworky, pluginy, extenze, SW knihovny apod., bez nichž nemůže být BI platforma provozována a bez kterých nemůže řádně fungovat. Pro standardizovaný SW, který je součástí navrhovaného řešení, musí v ČR existovat alespoň 3 subjekty/případy, pro které byl tento standardizovaný SW implementován v rozsahu obdobném jako v případě BI platformy MŽP. MŽP MŮŽE požadovat po Dodavateli doložení partnerského programu či přehledu implementací. Ke každému standardizovanému SW bude Objednateli předána dokumentace (zahrnující alespoň popis funkcionalit a dokumentaci API) platná ke dni předání systému a v případě, že dojde k její aktualizaci v |
ID požadavku | Požadavek |
průběhu smluvního vztahu s Dodavatelem, bude Objednateli předána nová verze dokumentace, nebo mu bude k ní předán přístup. Dokumentace ke standardizovanému SW SMÍ být v českém nebo anglickém jazyce a může být odkazem na veřejně dostupné zdroje. Systém MUSÍ být provozovatelný na obvyklých virtualizačních platformách, jakými jsou např. VMWare, KVM a Hyper-V. Pro potřeby Zhotovení Díla MUSÍ být systém instalován do Technologické platformy Objednatele využívající virtualizační SW VMWare. Systém NESMÍ být postaven na proprietárních HW řešeních a technologiích, tj. systém NESMÍ vyžadovat pro svoji funkčnost provoz na konkrétních proprietárních HW technologiích. | |
BI-8-5 Prostředí systému - instance | V průběhu implementace systému MUSÍ Dodavatel zajistit alespoň následující prostředí (instance)systému: - Vývojové prostředí – instance vývojových nástrojů a prostředí BI platformy pro vývoj (vyvíjet budou pracovníci Dodavatele s možností zapojení proškolených zaměstnanců CENIA/MŽP); - Testovací prostředí – instance určené pro ověřování funkcionalit a vlastností systému ze strany MŽP/CENIA. V průběhu pilotního a běžného provozu systému MUSÍ Dodavatel zajistit alespoň následující oddělené instance systému: - Produkční prostředí – instance určená k produkčnímu provozu, přístupné uživatelům BI platformy. Dodavatel MUSÍ být připraven obnovit provoz dle definovaných požadavků i v případě havárie a delší nedostupnosti produkční instance; - Testovací prostředí – instance pro ověřování funkcionalit a vlastností nových verzí BI platformy ze strany MŽP/CENIA. Testovací instance MUSÍ být v průběhu provádění testů konfiguračně shodná s produkční instancí a musí obsahovat testovací data v objemu umožňujícím ověření mezních výkonových hodnot. - Vývojové prostředí – instance určená pro vývoj nových částí/komponent BI platformy a jejích výstupů (ve všech vrstvách BI platformy) obsahující jak vývojářské nástroje, tak celou BI platformu v konfiguraci potřebné pro vývojářské práce. Testovací prostředí MUSÍ umožňovat vytváření image pro jeho rychlé obnovení nebo klonování. Počet a konfigurace instancí MUSÍ umožňovat naplnění požadavků kladených na systém a služby spojené s jeho provozem a rozvojem. |
ID požadavku | Požadavek |
BI-8-6 Škálovatelnost | Jednotlivé komponenty BI platformy MUSÍ být škálovatelné rozšiřováním infrastruktury a komponent BI platformy bez potřeby reinstalace již existujícího řešení. |
BI-8-7 Redundance HW a SW komponent | Produkční prostředí MUSÍ umožnit redundanci HW a SW komponent (zejména s ohledem na provozování BI platformy ve více lokalitách, pokud to bude MŽP požadovat). Výpadek jednoho HW prostředku (serveru, síťového prvku, SAN infrastruktury) nesmí znamenat výpadek systému. V případě výpadku jedné komponenty výkon z pohledu uživatelů nesmí být významně omezen (dodržení stanovených SLA v provozní smlouvě). |
3.2. Požadavky na použitelnost
ID požadavku | Požadavek |
BI-9-1 Podpora operačního systému klientských stanic | Platforma BI MUSÍ podporovat operační systémy klientských stanic Windows 10 64bit verzi (MUSÍ být v rámci podpory, aby byla zajištěna kompatibilita s vyššími verzemi). |
BI-9-2 Podpora prohlížečů | Platforma BI MUSÍ podporovat minimálně následující webové prohlížeče v posledních dvou dostupných verzích: - Chrome; - Edge; - Safari; - Firefox. |
BI-9-3 Podpora mobilního zobrazení | Sestavy a dashboardy MUSÍ být možné přizpůsobit i pro zobrazení na mobilních zařízeních (prostřednictvím dostupné mobilní aplikace nebo alespoň responzivní design). |
BI-9-4 Ergonomie uživatelského rozhraní | Uživatelské rozhraní systému MUSÍ s ohledem na ergonomii, snadnost a intuitivnost ovládání splňovat zejména následujících parametry pro koncové uživatele BI aplikací (sestav a dashboardů): - Dodržení běžných zvyklostí – uživatelské rozhraní musí být v souladu s aktuálními trendy a standardy a jeho struktura i jednotlivé prvky musí odpovídat běžným zvyklostem obdobných řešení BI nástrojů platforem; - Orientace v BI nástrojích – uživateli musí být vždy jasně prezentováno, v které části nástroje se nachází; - Dostupnost funkcí s ohledem na četnost jejich používání – nejčastěji používané funkce musí být nejsnadněji dostupné; - Dostupnost nápovědy – nápověda musí být dostupná z každého místa BI platformy např. formou našeptávačů; |
- Konzistentnost uživatelského rozhraní – stejné či podobné funkcionality se napříč nástrojem musí chovat a jejich ovládací prvky mají být umístěny stejně či podobně. Uživatelské rozhraní MUSÍ v maximální možné míře logicky seskupovat ovládací prvky na základě jejich určení. | |
BI-9-5 Jazykové mutace BI platformy | Uživatelské rozhraní výstupů publikovaných do veřejné části Portálu STaR (tj. části nepodléhající přihlášení uživatele) MUSÍ být v české jazykové mutaci, pokud uživatel využívá webový prohlížeč v češtině. |
BI-9-6 Dostupnost BI platformy (použitelnost webových klientů pro systém) | Přístup k funkcionalitám systému MUSÍ být zajištěn pro různé platformy (Windows, Android, iOS), ať už desktopové či mobilní verze jednotlivých platforem, pro které jsou vytvořeny. |
BI-9-7 Uživatelská nápověda | Uživatelská nápověda MUSÍ dostupná min. v podobě off-line uživatelské příručky a obsahovat: - Popis způsobu použití jednotlivých funkcionalit systému; - Popis doporučeného způsobu použití systému. Uživatelská nápověda MŮŽE mít formu online kontextové nápovědy či nápovědy formou wiki stránek atp. Tvůrci BI sestav MŮŽOU být schopni vytvářet nápovědu k vytvořeným BI sestavám (k prvkům sestav). |
3.3. Požadavky na spolehlivost
ID požadavku | Požadavek |
BI-10-1 Zaznamenávání systémového stavu | BI platforma MUSÍ umožnit automatické pravidelné kontroly a zaznamenávaní systémového stavu ve dvou režimech: - Automatické zaznamenávání systémového stavu – automatická kontrola musí probíhat v intervalu nejméně 10 minut a spočívá v ověření, zda je možné přihlášení do systému a zda je dostupná úvodní stránka systému; - Manuální zaznamenání systémového stavu správcem systému na základě ověřeného hlášení uživatele (tj. správce systému ověří, že se jedná o chybu způsobenou na straně systému). Systémovým stavem je stav, ve kterém se v daném okamžiku nebo časovém intervalu systém nachází a který odpovídá jedné ze tří následujících hodnot: - V provozu – systém je v provozu v případě, že se uživatelé mohou do systému přihlásit a využívat veškeré funkcionality, které jsou |
předmětem této technické specifikace, nebo je pro nedostupné funkcionality (např. z důvodu jejich chyby) nabídnuto náhradní řešení umožňující dosažení shodného výsledku jako v případě, kdy by uživatel mohl tyto funkcionality využít; - Mimo provoz – systém je mimo provoz v případě, že se uživatelé nemohou do systému přihlásit; - Omezení funkcionality - systém se nachází v stavu „omezení funkcionality“, když nejsou splněny podmínky ani pro jeden z předešlých stavů. Systém nabývá "omezení funkcionality" či stavu "mimo provoz" v případě, kdy alespoň jeden uživatel nebo automatická pravidelná kontrola systému identifikuje nedostupnost funkcionality systému nebo systému jako celku a zároveň tento stav není způsoben uživatelem (tj. uživatel splňuje veškeré náležitosti pro přístup a práci s BI platformou). Součástí záznamu o systémových stavech musí být také informace o tom, v jakém prostředí systém běžel, tj. zda byl dostupný z primárního produkčního prostředí nebo záložního produkčního prostředí (případně dalších produkčních prostředí, budou-li na základě rozhodnutí MŽP použita). Záznamy o systémových stavech musí vznikat minimálně v intervalu určeném automatickou kontrolou dostupnosti systému, tedy v intervalu nejméně 10 minut. | |
BI-10-2 Synchronizace systémového času | Serverový čas MUSÍ být navázán na zdroj reprodukující světový koordinovaný čas UTC (např. prostřednictvím NTP protokolu). |
BI-10-3 Dostupnost systému | Systém MUSÍ být, včetně infrastruktury a provozních postupů, navržen tak, aby umožnil zajištění následujících parametrů dostupnosti (bez ohledu na to, že MŽP může v katalogu služeb stanovit požadavky a SLA parametry na dostupnost nižší): - Dostupnost produkčního prostředí MUSÍ být možná v režimu 9x5x251 alespoň 95%, tj. v pracovní dny od 8:00 do 16:59 (Garantované pásmo). Systém bude považován za nedostupný v době trvání systémového stavu "mimo provoz" od okamžiku: - Oprávněné identifikace nedostupnosti pomocí automatické kontroly dostupnosti systému až do okamžiku odstranění vady; - Oprávněného nahlášení nedostupnosti uživatelem systému až do okamžiku obnovení provozu; - Výskytu vady, která znemožňuje plnění zákonné povinnosti či ekonomické činnosti uživatelů prostřednictvím systému a neexistuje ani náhradní cesta. |
BI-10-4 Servisní okno | Servisní zásahy, které snesou odklad (tj. nejedná se o odstranění nedostupnosti systému nebo závažné chyby) MUSÍ Dodavatel provádět výhradně mimo obvyklou pracovní dobu, tj. od 17:00 do 7:59 či dny pracovního volna. Každý servisní zásah SMÍ být realizován až po schválení ze strany MŽP, které si smí s ohledem na povahu zásahu vyžádat podrobnější informace o zásahu (harmonogram, postup atd.). Výsledky zásahu MUSÍ být dokumentovány. |
BI-10-5 Nové verze BI platformy | Nově nasazované verze MUSÍ být přístupny uživatelům na testovacím prostředí dle plánu verzí v definovaný počet dní před jejich nasazením na produkční prostředí (pokud nebude specifikováno jinak pro jednotlivé případy na základě rozhodnutí MŽP, nejméně 14 kalendářních dnů) (pokud nejde o opravu vady, jejíž oprava se řídí stanovenými SLA). |
BI-10-6 Log systému | MUSÍ být zaznamenávány veškeré operace: - Prováděné uživateli prostřednictvím GUI systému (spouštění sestav nebo dashboardů uživateli); - Související s komunikací s okolními informačními systémy (ETL procesy); - Prováděné následně při zajišťování provozu systému – systém NESMÍ umožnit jakoukoli modifikaci dat, aniž by došlo k zaznamenání data a času modifikace dat, identifikace subjektu (osoba/proces/sw úloha), který změnu dat provedl, původní hodnoty dat, nové hodnoty dat. Systém NESMÍ umožnit žádné jiné, než výše uvedené, způsoby pro přístup a manipulaci s daty. Ke každé provedené operaci MUSÍ systém zaznamenat alespoň následující informace: - Identifikace iniciátora operace; - Identifikace vyvolané operace; - Datum a čas spuštění operace na serveru (s přesností na sekundy); - Datum a čas ukončení operace na serveru (s přesností na sekundy); - Výsledek operace (identifikace chybového stavu nebo informace o korektním ukončení operace). Součástí systému MUSÍ být uživatelsky ovladatelný nástroj na zobrazení a analýzu logů. Veškeré vytvářené logy MUSÍ být chráněny proti manipulaci. Systém MUSÍ umožnit předávání logů do SIEM MŽP. Struktura, způsob a intervaly předávání logů budou předmětem implementační analýzy. |
Systém MUSÍ umožnit export logů do PDF/A. Takto exportované logy MUSÍ být možno předat k archivaci prostřednictvím ESSS MŽP (spisové služby). | |
BI-10-7 Zálohování systému | Bude probíhat výhradně na Technologické platformě Objednatele nedojde-li k Přesunu Díla. |
Data BI platformy MUSÍ být pravidelně zálohovaná takovým způsobem, aby i v případě havárie nedošlo po obnovení provozu BI platformy ke ztrátě dat importovaných do BI platformy déle než 1 den před havárií. | |
BI platforma MUSÍ být zálohovatelná běžnými zálohovacími SW a Dodavatel MUSÍ MŽP dodat požadavky na to, co a jak a jak často zálohovat, aby byl Dodavatel schopen garantovat, že po výpadku obnoví 1 den stará data, jak je požadováno výše. | |
Systém MUSÍ umožnit oddělené zálohování virtuálních serverů a dat DB a struktura celého dodaného řešení MUSÍ být taková, aby byly odděleny jednotlivé serverové instance a vlastní (například databázová, aplikační) data tak, aby bylo možné zálohovat s rozdílnou četností jednotlivé serverové instance a s jinou vlastní (například databázová, aplikační) data. | |
Aplikační instalace, data a logy musí být oddělené tak, aby je bylo možné zálohovat s rozdílnou četností | |
Plné zálohování MUSÍ být možné provádět bez nutnosti provozní odstávky řešení. | |
O pohybu zálohovaných dat (např. přesun do jiné lokality datového centra) MUSÍ být veden záznam. | |
V případě havárie a potřebné obnovy provozu (serverů, nastavení, databází, dat) tuto obnovu provede Dodavatel. Zálohy budou automaticky Dodavateli k dispozici v rámci zálohovacího systému Objednatele (Veeam Backup & Replication), do kterého bude mít Dodavatel dedikovaný přístup (prostřednictvím VPN). Obnova řešení bude možná v Dodavateli přiděleném prostoru v rámci virtualizační platformy VMware Objednatele. | |
V případě havárie a potřebné obnovy provozu (serverů, nastavení, databází, dat) MUSÍ být tato obnova také realizovatelná Objednatelem, bez nutné přímé spolupráce se Dodavatelem, a to na základě Dodavatelem dodaného dokumentu "Postup při obnově provozu". V případě nekompletní nebo neaktualizované verze tohoto dokumentu a nemožnosti, ze strany Objednatele, obnovení provozu, jdou veškeré náklady Dodavatele, spojené s touto obnovou, na vrub Dodavatele. |
3.4. Požadavky na výkon
ID požadavku | Požadavek |
BI-11-1 Výkon systému | Platforma BI MUSÍ být navržena tak, aby respektovala následující očekávané provozní parametry (v cílovém stavu): - Počet registrovaných uživatelů – nižší stovky paralelně pracujících uživatelů; - Počet neregistrovaných uživatelů – vyšší tisíce paralelně pracujících uživatelů; - Datový objem – jednotky miliónů záznamů/rok s možností inkrementálního nárůstu formou škálování (výhledově se může jednat i o desítky milionů záznamů, při napojení dalších zdrojových dat z okolních informačních systémů); - Přírůstky nových dat jsou v řádu vyšších desítek až nižších stovek GB ročně. Délka doby odezvy systému MUSÍ při uvedeném zatížení odpovídat běžným zvyklostem reportingu (odezva odpovídá náročnosti sestavovaného reportu), i složité DB dotazy nebo zobrazení mapy, resp. podkladové externí vrstvy, které mají z definice delší odezvu, MUSÍ opět odpovídat srovnatelným řešením. Měření odezev systému bude probíhat v průběhu řádného provozu. Výkon systému NESMÍ klesat v průběhu provozu systému, tj. nesmí se prodlužovat doby odezev na jednotlivé funkcionality systému. |
BI-11-2 Škálovatelnost | Systém a jeho HW infrastruktura MUSÍ být navržen a vytvořen tak, že |
systému | zvýšení výkonu a kapacity systému může být realizováno výhradně |
přidáním kompatibilních komponent, nikoli prostou výměnou | |
stávajících. | |
BI-11-3 Monitoring | Systém musí umožnit monitoring výkonových a objemových parametrů rozhodných pro vyhodnocování SLA. Tyto parametry musí být přístupné pro externí monitoring. Monitoring bude provádět Xxxxxxxxx, který bude MŽP předkládat výstupní reporty z monitoringu. MŽP bude provádět kontrolu výstupů z monitoringu. |
3.5. Požadavky na bezpečnost
ID požadavku | Požadavek |
BI-12-1 Identifikace a autorizace přístupů | BI platforma MUSÍ umožňovat nastavovat a řídit oprávnění pro jednotlivé role a oblasti přístupu. |
BI platforma MUSÍ umožňovat napojení na uživatelské skupiny definované v LDAP (eDirectory)/ Active Directory. MŽP aktuálně nedisponuje MS Active Directory. BI platforma MUSÍ umožňovat napojení na NIA a JIP/XXXX dle specifikací příslušných rozhraní publikovaných ze strany správce NIA a JIP/XXXX. BI platforma MUSÍ umožňovat logování přístupů a činnosti (využívání systému) uživateli (více viz požadavek BI-10-6). | |
BI-12-2 Důvěrnost a integrita | BI Platforma MUSÍ zajistit, že: - Uchovávaná data nesmí být zpřístupněna neautorizovaným osobám. Přístup a veškerá manipulace s daty MUSÍ být zaznamenávaná; - Data nemohou být během komunikace odposlouchávána či pozměněna neautorizovanou stranou. Pro komunikaci mezi uživatelem a systémem musí být použit pouze zabezpečený komunikační protokol; - Uchovávaná data nesmí být možné změnit nebo poškodit neautorizovanou stranou, či administrátory MŽP nebo Dodavatele. |
BI-12-3 Bezpečnostní monitoring | Systém MUSÍ aplikaci zajištěné MŽP umožnit plný bezpečnostní monitoring dodaných komponent, infrastruktury i všech činností souvisejících se zajištěním provozu, servisu a rozvoje systému. |
BI-12-4 Shoda se ZoKB | Systém MUSÍ být ve shodě se zákonem č. 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ů. |
BI-12-5 Antivirová ochrana | Servery a infrastruktura provozovaná MŽP má zajištěnu antivirovou ochranu. |
3.6. Požadavky na ochranu osobních údajů dle GDPR
ID požadavku | Požadavek |
BI-13-1 Soulad s GDPR | Platforma BI MUSÍ zpracovávat osobní údaje (dále též „OÚ“) v souladu s nařízením EU 2016/679, na ochranu osobních údajů tzv. General Data Protection Regulation ("GDPR") a související národní legislativou. Systém MUSÍ splňovat požadavky na zabezpečení OÚ s ohledem na principy „DATA PROTECTION BY DESIGN“. Dodavatel MUSÍ řešení, které bude sám implementovat s využitím BI platformy, navrhnout tak, aby osobní údaje, které jsou přebírány z EAP či jiných externích zdrojů dat byly zabezpečeny v souladu s obecným nařízením GDPR. Pokud budou řešení implementovat pracovníci |
MŽP/CENIA, jsou za návrh zabezpečení odpovědni oni (z pozice správce či zpracovatele osobních údajů). S přihlédnutím ke stavu techniky, nákladům na provedení, povaze, rozsahu a kontextu zpracování osobních údajů MUSÍ Dodavatel navrhnout a následně implementovat vhodná technická opatření před neoprávněným či protiprávním zpracováním a před náhodnou ztrátou, zničením nebo poškozením OÚ, tj. účinným způsobem začlenit do platformy BI nezbytné záruky ochrany osobních údajů, tak aby zpracování osobních údajů prostřednictvím platformy BI bylo ve shodě s obecným nařízením GDPR (minimální požadavky na návrh opatření pro ochranu OÚ jsou uvedeny dále). Komplex navržených technických opatření MUSÍ být navržen tak, aby MŽP/CENIA byly schopni unést důkazní břemeno (např. z pohledu právní průkaznosti logů systému). K navrženému rozsahu zpracování OÚ, době uložení a k jejich dostupnosti se v rámci své metodické a kontrolní činnosti se před dalším pokračováním povinně vyjádří Pověřenec pro ochranu osobních údajů MŽP. | |
BI-13-2 Požadavky na datový model a rozšíření datové věty | V dokumentaci datového modelu MUSÍ být označeny datové prvky, které byly klasifikovány jako OÚ. Takto označeny datové prvky MUSÍ být vhodným způsobem zabezpečeny. Ani administrátoři systému NESMÍ mít volný (tj. nelogovaný) přístup k těmto OÚ. Do vývojového, testovacího (referenčního) prostředí NESMÍ být přenášeny OÚ z produkčního prostředí. |
BI-13-3 Požadavky na vytváření záznamových souborů (logů) při operacích s OÚ | V záznamových souborech (logy) MUSÍ být zaznamenána jakákoliv operace nebo soubor operací s osobními údaji nebo soubory osobních údajů, který je prováděn pomocí či bez pomoci automatizovaných postupů, jako je shromáždění, zaznamenání, uspořádání, strukturování, uložení, přizpůsobení nebo pozměnění, vyhledání, nahlédnutí, použití, zpřístupnění přenosem, šíření nebo jakékoliv jiné zpřístupnění, seřazení či zkombinování, omezení, výmaz nebo zničení. Operace MUSÍ být zaznamenány (logovány) v souladu s GDPR. Logy MUSÍ umožňovat chronologickou rekonstrukci událostí při jednotlivých operacích s osobními údaji. Logovány MUSÍ být i přístupy administrátorů platformy BI. Systém MUSÍ zaznamenávat rizikové operace s OÚ zahrnující zejména hromadný export OÚ, přístup uživatele k těm OÚ, ke kterým obvykle |
s ohledem na své nařízení nepřistupuje a předávat tyto logy do SIEM MŽP pro jejich další vyhodnocování. Je DOPORUČENO, aby pro prokázání existence logů v čase, byla používána časová razítka dle eIDAS. | |
BI-13-4 Podpora pro zajištění práv subjektů údajů | Subjekt údajů má právo požadovat: - Přístup k osobním údajům; - Opravu osobních údajů; - Výmaz osobních údajů - tzv. „právo být zapomenut“; - Přenositelnost osobních údajů k jinému správci ve strukturované podobě a v běžně čitelném formátu; - Omezení zpracování osobních údajů; - Odvolat souhlas se zpracováváním osobních údajů, přičemž odvolání musí být stejně snadné, jako bylo poskytnutí souhlasu (pokud zpracování některých OÚ v platformy BI podléhá udělení informovaného souhlasu ze strany subjektu údajů). Součástí implementace platformy BI MUSÍ být popsány funkcionality/nástroje, které umožní správci (MŽP, CENIA) vyhledávání, kategorizaci osobních údajů a v návaznosti na to výkon práv subjektů údajů (např. výmaz vybraných osobních údajů zpracovávaných k určitému účelu nebo export osobních údajů v rámci práva na přenositelnost – to vše ve lhůtách stanovených obecným nařízením GDPR). Funkcionality platformy BI související s realizací práv subjektů MUSÍ zahrnovat alespoň: - Vyhledání subjektu údajů dle více vyhledávacích kritérií, jež lze spojovat do podmínek; - Vytvoření přehledu o osobních údajích zpracovávaných o příslušném subjektu údajů v platformy BI, účelech jejich zpracování, době uložení, způsobu jejich skartace po uplynutí lhůty; - Funkcionality pro dokumentovaný výkon práv subjektů údajů o Výmaz vybraných osobních údajů zpracovávaných k určitému účelu (zatímco u jiné skupiny osobních údajů téže osoby může účel zpracování i nadále trvat). Výmaz dat MUSÍ proběhnout i ze záloh; o Opravu osobních údajů tam, kde jsou osobní údaje pořizovány ze strany MŽP/CENIA a nikoliv přebírány ze základních registrů; o Export osobních údajů v rámci práva na přenositelnost ve strukturované podobě (XLM, XLS atp.); o Odvolání souhlasu se zpracováváním osobních údajů (pokud zpracování některých OÚ v platformy BI podléhá udělení informovaného souhlasu ze strany subjektu údajů). |
BI-13-5 Požadavky na skartaci strukturovaných | Funkcionality platformy BI MUSÍ obsahovat vytvoření přehledu OÚ, u kterých již pominul účel jejich zpracování. Po potvrzení oprávněného uživatele musí dojít k trvalému výmazu osobních údajů nebo k jejich |
dat a dokumentů v elektronické podobě | anonymizaci. Tj. platformy BI musí MŽP nabídnout jednoduchý přehled doby uložení a možnost skartace strukturovaných dat i dokumentů obsahujících OÚ v souladu s pravidly MŽP, které má stanoveny ve spisovém a skartačním plánu (zpravidla 10 let). |
BI-13-6 Požadavky na přenos dat do jiných IS či 3. stranám (např. prostřednictvím webových služeb) | Přenos dat/dokumentů obsahujících osobní údaje MUSÍ být vždy šifrován. Minimální požadavky na kryptografické algoritmy MUSÍ být ve shodě s vyhláškou č. 316/2014 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních a o stanovení náležitostí podání v oblasti kybernetické bezpečnosti (vyhláška o kybernetické bezpečnosti). |
BI-13-7 Požadavky na dokumentaci technických a organizačních opatření | Dodavatel MUSÍ doložit dodržení souladu s povinnostmi stanovenými v obecném nařízení GDPR. V dokumentaci musí být z pohledu GDPR upraveno alespoň: - Popis rozsahu zpracování osobních údajů v platformy BI, účely zpracování OÚ, doby uložení OÚ a dostupnost OÚ; - Popis implementovaných technických opatření (nástrojů) pro zajištění neustálé důvěrnosti, integrity, dostupnosti a odolnosti systému platformy BI a služeb zpracování OÚ v platformy BI; - Contingency plan – popis způsobu obnovy dostupnosti osobních údajů a přístupu k nim včas v případě fyzických či technických incidentů; - Proces pravidelného testování, posuzování a hodnocení účinnosti zavedených technických opatření na ochranu osobních údajů implementovaných v platformě BI. |
BI-13-8 Požadavky při využití cookies či nástrojů typu Google Analytics atp. | Nástroje, jakými jsou cookies či nástroje typu Google Analytics, MOHOU být využity pouze pro jasně definované účely, které nelze zajistit jinak. Dodavatel MUSÍ minimalizovat sběr osobních údajů uživatelů a pracovat primárně s anonymizovanými daty. Dodavatel MUSÍ využití těchto nástrojů předem oznámit MŽP, spolu s uvedením rozsahu sbíraných osobních údajů a účelů jejich zpracování. Nasazení těchto nástrojů podléhá předchozímu stanovisku pověřence pro ochranu OÚ MŽP. |
3.7. Požadavky na podporovatelnost
ID požadavku | Požadavek |
BI-14-1 Dokumentace Systému | Součástí dodávky Platformy BI MUSÍ být alespoň dokumentace uvedená v příloze č. 3 Smlouvy. |
3.8. Licence a kategorie uživatelů
Na následujícím schématu jsou uvedeny jednotlivé kategorie uživatelů BI platformy a jejich základní pravomoci a odpovědnosti související s využíváním, správou a provozem BI platformy. Všechny níže uvedené počty licencovaných uživatelů musí být možno navyšovat dle aktuálních potřeb MŽP/CENIA (v budoucnu resortu MŽP).
Schéma č. 2 – Kategorie uživatelů BI platformy a jejich základní pravomoci a odpovědnosti
ID požadavku | Požadavek |
BI-15-1 Licence pro Správce systému (též označován jako superuser nebo root) | BI nástroje MUSÍ být licencovány pro minimálně 3 Správce systému. Správce systému je pověřený pracovník CENIA nebo zaměstnanec odboru informatiky MŽP. Má oprávnění provádět správu celého systému, je odpovědný za výkon, integritu a bezpečnost celého systému. Nastavuje uživatelská oprávnění – celkovou správu uživatelů, příp. skupin uživatelů. Řídí a spravuje komunikaci s HelpDeskem Dodavatele u a veškerou dokumentaci k systému. Nastavuje komunikaci s okolními IS, spravuje databáze, nástroje pro tvorbu reportů, analytické nástroje a rozhraní na webový portál (tj. spravuje data v centrální datové vrstvě, spravuje schéma v centrální datové vrstvě, importuje data do centrální datové vrstvy (ze CKANu či z dalších zdrojových IS). |
Licence současně obsahuje všechny oprávnění všech ostatních licencí | |
BI-15-2 Licence pro Datové analytiky/Power usery | BI nástroje MUSÍ být licencovány pro minimálně 5 Datových analytiků/Power userů. Datový analytik/Power user je proškolený zaměstnanec MŽP nebo CENIA, příp. jiné resortní organizace MŽP odpovědný za analýzu a sémantickou a syntaktickou kontrolu dat, spravuje reportovací modely, , připravuje šablony pro jednotný vzhled reportů, odpovídá za modelování a výpočet ukazatelů (indikátorů), publikuje vizualizace, schvaluje přístupy k datovým sadám (tj. přístup k reportovacímu modelu), schvaluje automatizované importy z EAP a nastavuje jejich periodicitu, případně ručně nahrává vybraná data do sémantické vrstvy BI nástroje. |
Datoví analytici/Power useři v rámci své odpovědnosti kontrolují kvalitu a faktickou správnost analytických výstupů a reportů.Licence současně obsahuje všechny oprávnění Licence pro Tvůrce sestav a Licence pro koncové uživatele BI platformy | |
BI-15-3 Licence pro Tvůrce sestav | BI nástroje MUSÍ být licencovány pro minimálně 25 Tvůrců výstupů/sestav. |
Tvůrcem výstupů/sestav se rozumí proškolený odborný zaměstnanec MŽP nebo CENIA, příp. jiné resortní organizace MŽP. Využívá nástroje pro statistickou analýzu a pro tvorbu reportů. Vyhledává informace v datech, vytváří statistické modely. Je odpovědný za správný výběr zdrojů a vytváření analytických sestav (BI výstupů) nad reportovacím modelem, výpočet ukazatelů (indikátorů). Vytváří a spravuje vizualizaci dat, dashboardy. Rozhoduje o publikaci sestav – nastavení oprávnění k sestavám/dashboardům (BI výstupů) podle typů uživatelů, a to v rámci |
interního portálu BI platformy nebo v rámci Portálu STaR (např. veřejnost má právo na úroveň agregace kraj, ale interní uživatelé s licencí koncového uživatele mají právo až na nejpodrobnější neagregovanou úroveň rozpadu. Veřejnost rovněž bude mít speciální výstupy jen pro sebe nekombinované z důvodu bezpečnosti s výstupy pro registrované uživatele). Licence současně obsahuje všechny oprávnění Licence pro koncové uživatele BI platformy | |
BI-15-4 Licence pro Redaktory vnitřního portálu BI platformy | BI nástroje MUSÍ být licencovány pro minimálně 10 Redaktorů vnitřního portálu BI platformy. Redaktorem vnitřního portálu BI platformy je správce textů a schvalovatel dat pro veřejnou část BI platformy. Jde o proškoleného odborného zaměstnance MŽP nebo CENIA, příp. jiných resortních organizací MŽP. Posuzuje finální výstupy pro jednotlivé agendy, doplňuje statistické a analytické výstupy o odborné komentáře a vysvětlení, kontroluje, že výstupy dávají věcný smysl a odpovídají komunikačním standardům MŽP. Rozhoduje, v jakém rozsahu a do jaké hloubky budou výsledná data publikována. Je odpovědný za konečnou interpretaci všech BI výstupů. |
BI-15-5 Licence pro Koncové uživatele BI platformy | BI výstupy z BI platformy budou primárně zpřístupňovány uživatelům (tj. konzumovány) prostřednictvím Portálu STaR (Portál Star bude odpovídat za řízení přístupových oprávnění uživatelů k vypublikovaným BI výstupům). Nicméně i BI platforma bude umožňovat přístup Koncových uživatelů prostřednictvím interního portálu BI platformy (pro logované i nelogované uživatele). |
BI platforma MUSÍ být licencována pro minimálně 50 přihlášených (logovaných) Koncových uživatelů BI platformy (tj. konzumentů BI výstupů). | |
Koncový uživatel BI platformy má přístup ke všem údajům, ke čtení. Přihlášený Koncový uživatel BI platformy je odborný zaměstnanec MŽP/CENIA (v budoucnu i resortních organizací MŽP). Shrnuje a posuzuje výsledek a všechny kroky procesu tvorby výstupů jednotlivých agend, a to z obsahové stránky. Plní funkci zpětné vazby procesů kontrolou výsledků činností vedoucích k požadovaným BI výstupům. | |
BI platforma MUSÍ být licencována pro neomezený počet nelogovaných uživatelů řešení (konzumentů výstupů a reportů). Xxxx uživatelé MUSÍ mít základní možnost filtrování, tedy nejen statických výstupů. | |
Nepřihlášený (nelogovaný) Koncový uživatel BI platformy je kdokoliv, komu byl nasdílen odkaz (link) na příslušný veřejně dostupný BI výstup |
(tj. výstup, který byl oprávněným uživatelem označen jako veřejně přístupný). |
3.9. Ostatní požadavky
ID požadavku | Požadavek |
BI-16-1 Práva k systému | Dodavatel předá Objednateli SW licenci/práva na část Díla, která vznikne |
a jeho předání | při realizaci Díla (část SW řešení, která nebude řešena standardními SW |
produkty a která vznikne činností Poskytovatele (vývojem SW) při | |
realizaci Díla s použitím mezinárodně uznávané metodiky pro vývoj | |
software a která podléhá ustanovením zákona č. 121/2000 Sb., o právu | |
autorském). | |
Dodavatel předá MŽP kompletní zdrojové kódy SW částí Díla | |
a konfigurační soubory ke všem součástem Díla vyvinutým Dodavatelem | |
(nikoliv ke standardním SW produktům, které jsou využity pro realizaci | |
Díla), včetně autorských práv v rozsahu umožňujícím Objednateli | |
provádět libovolné změny v tomto kódu a konfiguračních souborech tak, | |
aby Dílo mohlo být řádně používáno bez závislosti na Dodavateli. | |
Předávané zdrojové kódy MUSÍ zahrnovat obvyklé součásti, jakými jsou | |
zejména zdokumentovaná API rozhraní u použitého frameworku, DLL | |
knihovny, kompletní projekt/solution pro části Díla vyvinuté na zakázku | |
pro zkompilování a rozvoj aplikace, skripty pro vytvoření databází | |
a jejich prvotní naplnění daty a číselníky, dokumentace HW a SW | |
požadavků u vytvořeného řešení (např. minimální verze SQL Serveru | |
2008 R2 s SP1 atp.), instalační příručka (např. nastavení portů na | |
firewallu atp.) a dokumentace pro nasazení změnových balíků, instalační | |
a provozní manuály, administrátorská a uživatelská příručka. | |
Dále předá Dodavatel Objednateli prohlášení o postoupení autorských | |
práv, a to bez jakéhokoliv budoucího možného autorskoprávního | |
omezení. | |
BI-16-2 Přístup k aktuálním zdrojovým kódům | Systém MUSÍ být vyvíjen, udržován a rozvíjen pouze způsobem, kdy jsou veškeré aktuální zdrojové kódy dostupné MŽP i Dodavateli na kolaborativním nástroji (typu GitHub) určeném Objednatelem. |
BI-16-3 Provozní | Vnitřní portálová část BI platformy MUSÍ umožňovat oprávněným |
informace | uživatelům zveřejňovat provozní informace pro koncové uživatele, |
přehled chystaných novinek a provozních událostí, informace | |
o nasazených nových verzích systému, přehled uživatelských příruček | |
atp. | |
BI-16-4 Generování ticketu do Servisdesku přímo z BI platformy | Systém MUSÍ umožnit generovat ticket do Servisdesku přímo z prostředí BI platformy. Koncoví uživatelé nemají do Servisdesk přímý přístup, ale MUSÍ mít možnost generovat ticket do Servisdesk přímo z BI platformy |
(vazba na Servisdesk dodavatele) | či zaslat svůj požadavek e-mailem na Dodavatelem určenou adresu a požadavek vloží do Servisdesk Dodavatel. Systém MUSÍ umožnit předat do Servisdesk výpis chyby a určení místa v systému, kde se uživatel aktuálně nachází. Servisdesk není součástí dodávky BI platformy. Servisdesk provozuje Dodavatel v rámci provozní služby „BI_02 Servisdesk, hot-line pro Objednatele“. |
ZADÁNÍ TYPOVÝCH ÚLOH
Průvodní dokument k typovým úlohám
• Smyslem demonstračních úloh je otestovat funkcionalitu BI platformy z pohledu nejčastěji využívaných potřeb Objednatele;
• Celkem je v rámci Fáze 2 plnění požadováno provést ukázku realizace následujících 4 úloh (2 mají přesně specifikované zadání a podklady, další 2 budou upřesněny Objednatelem v rámci úvodní Fáze 0 a 1 plnění);
• Úlohy mají ověřit řešení z hlediska práce
o S vybranými vstupy
▪ Z flat formátu .csv s umístěním jako webové zdroje v metadatovém katalogu
Objednatele (technologie opensource CKAN);
▪ Z relační databáze (na příkladu Firebird) přes konektor;
▪ Z noSQL databáze/platformy Elasticsearch (přes nativní konektor nebo REST API);
o Se skripty (např. Python);
o S ukládáním
▪ Do sémantické datové vrstvy (databáze/datového skladu BI);
▪ Do CKAN (přes API);
o Zpracování vizualizací
▪ Např. konsolidací/přepočtem datového obsahu sémantické datové vrstvy pro přepočty (relativizace, součty, KPI) potřebné pro tvorbu grafové prezentace dat;
▪ Možnosti z hlediska konfigurace grafického výstupu;
o Nastavení přístupu k datům;
o Nastavení automatizace spuštění úloh;
o Nastavení exportu – embedování pro externí weby.
Pozn.: Některé níže uvedené odkazy jsou neveřejné, nicméně pro vítězného Dodavatele bude existovat povinnost pracovat s těmito linky na složky a zde umístěnými soubory (tj. Dodavatel obdrží příslušná přístupová oprávnění). Pro potřeby podání nabídky jsou účastníkům postoupena odkazovaná .CSV lokálně. Navržený ETL proces musí být vždy nastaven pro potřeby automatizace aktualizací tak, že dokáže zpracovávat nové soubory umístěné v těchto webových složkách CKAN s danou jmennou syntaxí, či-li ne pouze s absolutním URL odkazy na konkrétní dokumenty. Musí také obsahovat validační mechanismus pro případ změny struktury vstupních dat s možností konkrétní identifikace chyby ve zpracování. Tato schopnost bude demonstrována dvěma stavy CKAN, kdy v jeden okamžik bude složka obsahovat pouze 1 soubor a v druhý více souborů (modelově 2 až 3). Procedura musí načíst – provést nahrání vždy nejnovějšího souboru.
Případné nejasnosti v zadání úloh budou se Objednatelem vyjasněny v průběhu IT analýzy BI
platformy.
Úloha 1 – Indikátor z tématu Voda
Název úlohy | Úloha voda |
Účel | Otestování funkčních možností řešení v oblasti: - Transformace / očištění dat (vstupní formát - .xls, .xlsx) - Exportu dat (alternativní výstup ETL nebo jiný způsob uložení dat mimo platformu BI – vytvoření .csv souboru a jeho uložení do CKAN) - Vizualizace - Automatizace opakované spouštění |
Cíl | Cílem úlohy je vytvořit graf na základě dat od poskytovatele. Graf je součástí Zprávy 2018, Indikátor 10 - Čištění odpadních vod. xxxxx://xxx.xxxxx.xx/xx-xxxxxxx/xxxxxxx/0000/00/Xxxxxx_x_XX_XX_0000.xxx |
Výstupy | a) Viz na screenshot grafu pdf zpravy 2018 (./Úloha č. 1_Voda/uloha_BI_popis.docx – kapitola 1) b) Viz dále "Vizuální zobrazení výstupu (HTML)” |
Přehled podkladů | - Graf 1 indikátoru 10 Zprávy 2018, strana 72. - Příloha č. 4 Smlouvy – složka „uloha voda“ Vstupní data jsou pro nahlédnutí k dispozici ve složce: a) ./Úloha č. 1_Voda/ETL Obyvatelé napojení na kanalizaci a ČOV/ - xls./.xlsx soubory b) ./Úloha č. 1_Voda/ETL Pohyb obyvatel za ČR, kraje, okresy, SO ORP a obce/ - .csv soubory Pozn.: Paralelní umístění souborů s příslušnými URL linky (operativní zdroj pro vytvoření) jsou umístěny v katalogu CKAN (blíže viz ./Úloha č. 1_Voda/Uloha_1_Voda_popis.docx) Výstup je reprezentován souborem ve formátu .svg: ETL workflow (inspirace) ./Úloha č. 1_Voda/ETL konsolidační/knime_graf.svg c) Hierarchická struktura CKAN: viz png soubory ve složce ./Úloha č. 1_Voda/CKAN |
Podrobný popis | Viz soubor [./Úloha č. 1_Voda/Uloha_1_Voda_popis.docx] |
Požadované mezikroky | Blíže viz soubor [./Úloha č. 1_Voda/Uloha_1_Voda_popis.docx (kap. 3)] |
Vstupní data - období | a) Obyvatelé napojení na kanalizaci a ČOV – 2014-2018 b) Pohyb obyvatel za ČR, kraje, okresy, SO ORP a obce – 2014-2018 c) Data za část časové řady od roku 1991 do roku 2013 – .csv. viz soubory ./Úloha č. 1_Voda/ETL Obyvatelé napojení na kanalizaci a ČOV/data do r. 2013/kanalizace_issar.csv a stredni_stav_obyvatel_issar.csv d) Číselník kategorií z tématu Voda – pozn.: Bude poskytnuto Objednatelem v průběhu realizace |
Metodika výpočtu | Metodika (postup) transformace a výpočtu (tvorby) výstupního indikátoru ze sémantické datové vrstvy (výběr dimenzí, hierarchií): Bude poskytnuto Objednatelem v průběhu realizace. |
XXX embeding | Doc šablona není požadována. |
Vizuální zobrazení výstupu (HTML) | Vzor viz: xxxxx://xxxxx.xxxxx.xx/xxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxxx-xxxxxxxx-xxxxx/00- vodni-hospodarstvi-a-jakost-vody/03-cisteni-odpadnich-vod/ - viz příslušná „záložka“. |
Úloha 2 - Indikátory z tématu Lesy
Název úlohy | Úloha Lesy |
Účel | Otestování funkčních možností řešení v oblasti - Načtení strukturovaných dat do sémantické vrstvy - Vizualizace |
Cíl | Cílem úlohy je vytvořit grafy pro 3 indikátory z tématu lesů Graf je součástí Zprávy 2018 (str. 125-135), Indikátor 19 – Těžba dřeva, 20. Druhová a věková skladba lesů a 21 - Odpovědné lesní hospodaření xxxxx://xxx.xxxxx.xx/xx-xxxxxxx/xxxxxxx/0000/00/Xxxxxx_x_XX_XX_0000.xxx 19. Tě žba dřeva [ str. 125] Pozn.: Níže uvedené odkazy jsou neveřejné, nicméně pro vítězného Dodavatele bude existovat povinnost pracovat s těmito linky na složky a zde umístěnými soubory. Pro potřeby podání nabídky jsou účastníkům postoupena odkazovaná .CSV lokálně (viz přílohy). Navržený ETL proces musí být vždy nastaven pro potřeby automatizace aktualizací tak, že dokáže zpracovávat nové soubory umístěné v těchto webových složkách CKAN s danou jmennou syntaxí, či-li ne pouze s absolutním URL odkazy na konkrétní dokumenty. Musí také obsahovat validační mechanismus pro případ změny struktury vstupních dat s možností konkrétní identifikace chyby ve zpracování. Tato schopnost bude demonstrována dvěma stavy CKAN, kdy v jeden okamžik bude složka obsahovat pouze 1 soubor a v druhý více souborů (modelově 2 až 3). Procedura musí načíst – provést nahrání vždy nejnovějšího souboru. V sémantické databázi by pak mělo dojít pouze k inkrementálnímu přírůstku pouze nových dat. • Např.: ◦ data_cenia_cpp_dreva_2018.csv (časová řada RRRR-2018) ◦ data_cenia_cpp_dreva_2019.csv (časová řada RRRR-2019) = přírůstek 1 rok Graf 1: Porovnání realizovaných těžeb dřeva s celkovým průměrným přírůstem (CPP) v ČR [mil. m3bez kůry] • data_cenia_cpp_dreva_2018.csv xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxx-xxxxx-0000 • data_cenia_tezba_2018.csv xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxxxx-0000 • data_cenia_nahodila_tezba_2018.csv xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxxxxxxx-xxxxx-0000 Graf 2: Nahodilá těžba podle příčin vzniku v ČR [mil. m3bez kůry] • data_cenia_nahodila_tezba_2018.csv xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxxxxxxx-xxxxx-0000 Graf 3: Vývoj celkové porostní zásoby dřeva v ČR [mil. m3bez kůry] • data_cenia_porostni_zasoby_lesa_2018.csv xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxxxxxxx-xxxxxx-xxxx-0000 |
20.Druhová a vě ková skladba lesů [ str. 128] Graf 1: Vývoj podílu jehličnatých a listnatých porostů na celkové ploše lesů ČR, rekonstruovaná přirozená a doporučená skladba [%] • data_cenia_skladba_lesu_2018.csv xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxxxxxx-xxxx-0000 • data_cenia_skladba_lesu_2017.csv xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxxxxxx-xxxx-0000 • data_cenia_skladba_lesu_2016.csv xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxxxxxx-xxxx-0000 Graf 2: Vývoj druhové skladby jehličnatých porostů v ČR, rekonstruovaná přirozená a doporučená skladba [%] • data_cenia_skladba_lesu_2018.csv xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxxxxxx-xxxx-0000 Graf 3: Vývoj druhové skladby listnatých porostů v ČR, rekonstruovaná přirozená a doporučená skladba [%] • data_cenia_skladba_lesu_2018.csv xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxxxxxx-xxxx-0000 Graf 4: Vývoj věkové struktury lesních porostů v ČR [%] • data_cenia_vekova_struktura_2018.csv xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxxxxx-xxxxxxxxx-0000 21. Odpově dné lesní hospodaření [ str. 132] Graf 1: Podíl jednotlivých kategorií lesů na celkové ploše lesů v ČR [%] Graf 2: Podíl plochy lesů certifikovaných podle zásad PEFC a FSC na celkové ploše lesů v ČR [%] • data_cenia_pefc_2018.csv xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxxx-0000 • data_cenia_fsc_2018.csv xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxx-0000 Graf 3: Obnova lesa v ČR [tis. ha] • data_cenia_obnova_lesa_2018.csv |
xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxxxxx-xxxx-0000 Graf 4: Jarní kmenové stavy vybraných druhů zvěře v ČR [index, 1990 = 100] • data_CENIA_stav_zvere_2018.csv xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxxx-xxxxx-0000. | |
Výstupy | Výstupy: a) Grafy principiálně stejné jako jsou ve Zprávě o ŽP ČR, ale interaktivní a s kreativními možnostmi zobrazení různých typů grafů, filtrování, zoom, konverzi na percentuální zobrazení, export, freeze, slučování kategorií apod. b) Přehledné tabulky s absolutními a relativními hodnotami (%), případně jiné různé způsoby zobrazení dat (filtrování, konverze na jinou jednotku, percentuální porovnání jen filtrovaných kategorií apod.) |
Přehled podkladů | - Výstupy: grafy indikátorů 19, 20, 21 Zprávy 2018, strany 125-135. - Vstupní data jsou: ./Úloha č. 2_Lesy/CSV/ - obsažená .csv ve složce Pozn.: Objednatel v průběhu realizace doplní k jednotlivým .csv jejich schémata, v rámci ZD je uveden pouze modelový příklad JSON schéma pro .csv < NÁ ZEV> - Výstup: grafy viz Zpráva o životním prostředí 2018 (výše). - Hierarchická struktura CKAN: viz png soubory ve složce ./Úloha č. 2_Lesy/CKAN |
Podrobný popis | Není uveden. Poznámky: Některé datové sady nemají kompletní výčet let, ale jsou jenom za jeden rok. Tyto datové sady dostává CENIA každý rok jen pro daný rok a časová řada ve Zprávě se vytváří z kombinace historických dat. Pro BI toto znamená, že pro každý rok si musí načíst soubor (co rok, to soubor). Pro příklad je uveden u indikátoru 20. graf 1 i dataset za rok 2017 a 2016. Na druhou stranu některá .csv však budou s celou časovou řadou a v průběhu času se budou rozšiřovat o nové hodnoty. Procedury ETL musí počítat s obojím principem výskytu těchto 2 hlavních typů obsahu v CKAN. Objednatel není v době zveřejnění Výzvy na podání nabídek v tom, jestli soubory .csv budou pod jedním datasetem (webové složce CKAN) nebo každý bude ve zvláštním datasetu. Tento fakt/princip by však neměl být pro účastníky limitující. Jmenná konvence pro soubory zůstane stejná, bude se tedy lišit jen v roku, eventuelně jiném časové určení, na konci názvu (např.: Data_CENIA_skladba_lesu_2018.csv, Data_CENIA_skladba_lesu_2017.csv atd.) Účastníci musí počítat také s tím, že ještě není finální podoba URL CKAN katalogu a je možné, že všechny URL budou mít stejnou podobu jako teď, ale budou bez roku na konci; tj. Nynější URL xxxx://xxxx.xxx.xx/xxxxxxx/xxxxx-xxx-xxxxx-0000 se v příštích měsících možná změní na podobu xxxxx://xxxx.xxx.xx/xxxxxxx/xxxxx- cpp-dreva a toto bude platit pro všechny tady míněné datasety. Uvedené odkazy jsou proto orientační, a to i s ohledem na fakt, že v době podávání nabídek účastníků nebudou veřejné. Pro potřeby podání nabídky je ovšem klíčový datový obsah a struktura .csv souborů, které jsou nedílnou součástí ZD. Vítězný účastník dostane v příslušné etapě plnění závazné instrukce a podklady/vstupy včetně konkrétní podoby URL odkazů a přístupu k nim tak, aby byl schopen požadované výstupy |
řádně realizovat. | |
Požadované mezikroky | Nejsou |
Vstupní data - období | Různé dle vstupních CSV. |
Metodika výpočtu | Metodika (postup) transformace a výpočtu (tvorby) výstupního indikátoru ze sémantické datové vrstvy (výběr dimenzí, hierarchií): Informace o principech tvorby budou poskytnuty Objednatelem v průběhu realizace. |
XXX embeding | Doc šablona není požadována |
Vizuální zobrazení výstupu (HTML) | xxxxx://xxxxx.xxxxx.xx/xxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxxx-xxxxxxxx-xxxxx/00- lesy/02-druhova-a-vekova-skladba-lesu/ xxxxx://xxxxx.xxxxx.xx/xxxxxxx-xxxxxxxxx-xxxxxxxxxx-xxxxx-xxxxxxxx-xxxxx/00- lesy/03-odpovedne-lesni-hospodareni/ |
Úloha 3 – Zpracování, vizualizace dat a automatizace z RDMS (Relational Database Management System) MA ISOH (Modul Autovraky Informačního systému odpadového hospodářství)
Název úlohy | Úloha autovraky |
Účel | Nabídnout interním uživatelům MŽP statistiku a aktuální údaje o počtu zpracovaných autovraků - Ověření schopnosti načítání dat z RDMS – Firebird; - Ověření provázání s externím číselníkem (PSČ) - Zpracování dat pro potřeby vizualizace; - Periodické zobrazení statistiky a s tím spojené načítání dat z RDMS - Vizualizace v několika pohledech včetně zobrazení kartogramu. |
Cíl | Cílem úlohy je vytvořit vizuální výstupy - Kartogram s počtem zpracovaných autovraků na úrovni obcí; - Kontingenční tabulky s možností ◦ Dril-down po letech (min. v granularitě kvartál, měsíc, den); ◦ Dril-down územním výběrem krajů, ORP, obcí, PSČ; ◦ Dril-down výběrem firem a provozoven; ◦ Filtrem pro výběr autoznaček autovraků, krajů, rokem; ◦ Vyhledáním podle názvu firmy dle části názvu * ; ◦ Možností řazení nad sloupci; - Přehledu (tabulky/grafu) zobrazujícího kumulativní počet autovraků zpracovaných danou provozovnou a podle značky daný den ve frekvenci min. 15 min. + uvedení statistiky přírůstku autovraků v daný den za kraj (případně bude dodefinováno Objednatelem). Pozn.: - Data není potřeba přepočítávat ve smyslu relativizace či kombinací (vyjma sdružených součtů pro drill-down up zobrazení); - Z dat v rámci tabulky vůz je možné definovat síťovou analýzu závislosti mezi místem předání a adresou předávajícího – např. jak silná je závislost |
v porovnání mezi kraji – tato oblast je však spíše otázkou GIS či pokročilých analytických nástrojů než požadavku na základního funkcionalitu BI platformy. | |
Výstupy | - Viz print screeny (.png) ve složce ./Úloha č. 3/MA ISOH/dashboard |
Přehled podkladů | - Klíčové tabulky databáze, vstupní data jsou: a) interní LAN firebird:// 10.0.1.**:3050/data/firebird/****/maisoh.fdb DB obsahuje cca 40 tabulek – pro potřeby nastínění složitosti úlohy je 6 klíčových tabulek (území, uživatel_clean_vzorek, vuz_clean_vzorek, zar_firma_vzorek, zarizeni_vzorek, znacka) z databáze, na nichž má být úloha postavena, převedeno do .CSV (u některých v podobě pseudoanonymizovaného vzorku) a jsou k dispozici v adresáři Úloha č. 3/MA ISOH/), hlavní tabulka „vuz“ má nyní cca 1,4 mil. záznamů (autovraků) / / denní inkrement je cca 500 autovraků, tabulka zar_firma cca 2 tis. záznamů, tabulka zar_firma cca 4 tis. záznamů, tabulka uživatel_clean cca 2,4 tis. záznamů; • Pomocná .csv tabulka s číselníkem PSČ - neobsahuje uvedení zeměpisné šířky a zeměpisné délky obcí (Dodavatel může využít např. wms služby) • Mapová podkladová vrstva obcí (.geojson) – buď součást BI řešení, eventuálně možnost připojení WMS služby (Objednatel neposkytuje). |
Podrobný popis | Není |
Požadované mezikroky | Nejsou |
Vstupní data - období | 2009–2017 |
Výstupní data - dimenze | Dle uvážení Dodavatele (konzultace s Objednatelem) |
Metodika výpočtu | Odvoditelná od výstupu. Kombinace dat z databáze a pomocného číselníku |
XXX embeding | Doc šablona není požadována |
Vizuální zobrazení výstupu (HTML) | Výstup je: Viz print screeny (.png) ve složce ./Úloha č. 3/MA ISOH/dashboard, příp. Bude poskytnuto Objednatelem v průběhu realizace |
Úloha 4 – Zpracování, obohacení, vizualizace dat a automatizována aktualizace primárních dat z (Integrovaný registr znečišťování /IRZ/ + Informační systém integrované prevence /IPPC/) ElasticSearch a SOAP služeb
Název úlohy | Úloha Primární data IRZ + IPPC |
Účel | Ověření schopnosti BI platformy z pohledu práce s NOSQL datovým vstupem, SOAP službou a přípravy dat pro analytické zpracování sestavy založené na primárních datech IS z oblasti IRZ a IPPC a .GML reportu EEA. IRZ=integrovaný registr znečišťování (xxxxx://xxx.xxx.xx) |
IPPC=Integrovaná prevence a omezování znečištění (xxxxx://xxx.xxx.xx/xxxx/xxxx0.xxx/xxxxx.xxx) EEA= Evropská agentura pro životní prostředí (xxxxx://xxx.xxx.xxxxxx.xx/xx) | |
Cíl | Cílem úlohy je: - Načíst data z Elasticsearch vzniklá jako samostatné indexy na základě jejich nahrání prostřednictvím CKAN do Elasticsearch (cca 14 .csv souborů); - Vytvořit proceduru pro nahrávání dat ze systému ISPOP (SOAP) za oblast IRZ pro daný rok; - Provést spojení historických dat IRZ z Elasticsearch a transformovaných dat IRZ (XML z ISPOP) v datové vrstvě a vytvořit integrované datové entity v reportovací vrstvě; - Obohatit konsolidovanou sadu dat IRZ o vybraná data z IS IPPC dostupná přes SOAP vztahující se k položkám dané provozovny IRZ (provozovny IPPC jsou podmnožinou provozoven IRZ) – bude upřesněno Objednatelem v rámci realizace (např. informace o provedených kontrolách nebo povolovacích řízeních /změnách/ na zařízení - xxxxx://xxx.xxx.xx/xxxx/xxxx0.xxx/%00%00XxxxXxxxxxXxxxxxxx.xxx?xxxx mentId=70236&action=openDocument); - Vytvořit interaktivní sestavu/dashboard s možností prohledávání a filtrace nad zájmovými daty (druh znečišťující látky, vyhledání provozovny), top producenti přes územní jednotky (provozovny mají mj. jednoznačně definované adresu včetně PSČ (viz číselník PSČ v úloze 4) a roky, možnost vyhledávání přes položky názvu firmy, provozovny, dril-down/up; - Nastavit synchronizaci (periodicitu extrakce) vstupních dat z rozdílných vstupů (= >nastavení procedur tak, aby byly opakovatelné bez nutného zásahu do jejich nastavení, v případě změny vstupních dat). Periodicita bude upřesněna Objednatelem v rámci realizace - cca 1x týdně. |
Výstupy | - Sestava/dashboard obsahující přehledy založené na datech vzniklých kombinací dat IRZ (historických získaných Elasticsearch a ISPOP získaných ze SOAP), IPPC (SOAP) vztahujících se k provozovnám IRZ/IPPC; - Přesná podoba sestavy/dashboardu bude dopřesněna v rámci realizace a. Bude obsahovat mapovou bodovou vrstvu s tooltipem po přejetí na bod a provázání s grafem vývoje za vybrané látky pro danou provozovnu – snadná orientace pro veřejnost b. Kontingenční tabulky s pohledem na data i. Přes časovou hierachii; ii. Přes územní hierarchii; iii. Přes NACE hierarchii; iv. Klasifikaci látek (látky vázané na přenosy ovzduší, vodu, odpady anebo charakterem dopadu na lidské zdraví – možnost doplňkově klasifikovat číselník látek viz klasifikace arnika - xxxxx://xxxxxx.xxx/xxxxxxxxx-xxxxx-x-xxx; v. případně další – viz analýza. c. Grafy – jejich specifikace bude upřesněna Objednatelem v rámci realizace – možné vzory viz Vizuální zobrazení výstupu (HTML) (min. 5) d. Možnost vyhledávání v číselnících (přes fulltext včetně možnosti jen části textového řetězce od 3 počátečních znaků) a filtrování (různé typy bulletů, seznamy) |