TECHNICKÁ SPECIFIKACE - Provozní informační portál DPKV
TECHNICKÁ SPECIFIKACE - Provozní informační portál DPKV
Vymezení předmětu plnění
1. Předmět plnění
(1) Předmětem plnění veřejné zakázky jsou dodávky včetně služeb (dále také jen „řešení“) – realizace informačního systému pro dispečink veřejné dopravy, tzn. provozního informačního portálu (dále také jen „MIS“ nebo „systém“).
2. Popis současného stavu
Tato část Zadávací dokumentace obsahuje informace důvěrné povahy. Zadavatel poskytne dodavateli tyto informace na základě žádosti a po uzavření Dohody o ochraně informací důvěrné povahy mezi dodavatelem a zadavatelem. Podmínky žádosti jsou stanoveny v kapitole 15 části 2 Zadávací dokumentace a v části 5 Zadávací dokumentace.
3. Povinné parametry technického řešení
3.1. Obecné požadavky
(1) Zadavatel při výstavbě, správě a provozu technologií striktně dodržuje hledisko technologické neutrálnosti, tj. využití technologií takovým způsobem, který neomezuje implementaci technologií různých výrobců – tuto strategii musí splňovat i řešení dodané v rámci této veřejné zakázky.
(2) Pokud uchazeč vyžaduje využití konkrétních softwarových produktů a jím zvolený přístup k řešení zadání je na takových konkrétních řešeních závislý, musí jejich pořízení zahrnout ve své nabídce v potřebném rozsahu a v rámci nabídnuté ceny.
(3) Za předpokladu, že uchazečem navržené řešení vyžaduje fyzickou infrastrukturu (např. servery, úložiště, komunikační prvky atd.) neobsaženou v popisu předmětu plnění, zahrne uchazeč do své ceny všechny náklady na její pořízení, instalaci, konfiguraci a další služby potřebné pro uvedení do provozu.
(4) Pro každý softwarový produkt, který uchazeč nabídne v rámci svého řešení, budou v nabídce výslovně uvedeny všechny licenční nebo výkonové požadavky spojené s instalací a provozem řešení, včetně uvedení konkrétní infrastruktury, na které bude řešení provozováno.
(5) Uchazeč ve své nabídce detailně popíše vazby na stávající systémy Zadavatele, které jsou nezbytné pro správné fungování řešení nabízeného Uchazečem.
(6) Zadavatel z důvodů co nejjednodušší a jednotné správy a minimalizace provozních nákladů vyžaduje využití stávajících prostředků a používaných technologií. V případě, že uchazeč vyžaduje ve svém řešení stejné nebo podobné funkce, jaké poskytují stávající prostředky a technologie, je povinen využít nebo vhodným způsobem rozšířit stávající prostředky – není přípustné implementovat např. další serverovou virtualizační platformu, adresářovou službu apod.
(7) Dodavatel prokáže, že všechny dodávky, které dodá Zadavateli:
(a) jsou nové, byly oprávněně uvedeny na trh v EU nebo pochází z autorizovaného prodejního kanálu výrobce,
(b) mají plnou záruku od výrobce,
TECHNICKÁ SPECIFIKACE - Provozní informační portál DPKV
(c) mohou být podporovány výrobcem a mohou být součástí servisního a podpůrného programu výrobce,
(d) obsahuji licenci na používání příslušného softwaru,
(e) jsou určeny pro provoz v České republice,
(f) z databází výrobce, distributora či prodejce bude možné výše uvedené skutečnosti doložit.
Tyto skutečnosti dodavatel doloží čestným prohlášením distributora, popř. uchazečem samotným, nelze-li prohlášení distributora získat. Zadavatel si vyhrazuje právo na zjištění původu výrobku při jejich převzetí, a to dle příslušných sériových čísel a právo podpisu akceptačního protokolu, osvědčujícího převzetí dodávky, až po ověření původu výrobku.
3.2. Specifické požadavky – katalog funkčních požadavků
(1) Zadavatel připravil popis funkčních požadavků na obsah provozního informačního portálu, ty jsou uvedeny v části 3b Katalog požadavků. Požadavky jsou uvedeny pro ekonomický útvar, personální útvar, technický útvar, dopravní útvar.
(2) Katalog požadavků stručně popisuje stávající stav včetně interních procesů zadavatele a definuje případy užití (nebo také „use case“ nebo „UC“) tzn. jednotlivé scénáře pro zobrazení vybraných informací.
(3) Zadavatel zpracoval katalog požadavků v detailu potřebném pro zpracování řádné nabídky a v detailu, který dostatečně definuje předmět plnění. Součástí předmětu plnění je zároveň provedení předimplementační analýzy a zpracování prováděcí dokumentace (viz kapitola 4 Implementační služby), která bude sloužit jako závazná definice cílového stavu, přičemž část 3b Katalog požadavků bude sloužit jako závazný podklad pro zpracování prováděcí dokumentace.
(4) Katalog požadavků pro každý útvar obsahuje především následující kapitoly:
(a) Popis agendy – rámcově uvádí hlavní činnosti daného útvaru;
(b) Aktuální stav – stručný popis stávajícího stavu z pohledu UC, nejedná se o úplný a kompletní popis procesů, jen o výtažek z činností podstatných pro daný UC;
(c) Role – stručný popis rolí podle kterých bude během realizace nastaven přístup k jednotlivým částem MIS. Konkrétní rozsah přístupu role k informacím bude definován v rámci prováděcí dokumentace;
(d) Případy užití – obsahují stručný popis stávajícího procesu s uvedením relevantních částí procesu, systémy a aplikace, které v agendě používány a do nichž jsou ukládána data, frekvence aktualizace dat. Dále jsou uvedeny konkrétní UC ve smyslu požadavků na potřebné výstupy MIS s uvedením faktických informací, které mají být zobrazovány včetně rozdělení do jednotlivých úrovní, tak jak mají být informace zobrazeny.
(e) Datové zdroje a data – obsahují informace ohledně aplikačních systémů případně dalších datových zdrojů, které mohou poskytovat zdrojová data, návrh architektury, popis možností připojení k datům. Dále požadavky na zabezpečení dat, informace o objemu uložených dat a odhad frekvence přírůstků dat,
(f) Dále jsou uvedeny možnosti exportu, jazykové mutace reportů a další informace, které zadavatel považuje za relevantní pro přípravu nabídky a realizaci předmětu plnění.
(5) Uchazeč je povinen implementovat všechny parametry uvedené v případech užití, pokud se během předimplementační analýzy neprokáže technická nemožnost napojení na potřebné zdroje dat. Zadavatel v rámci přípravy zadávací dokumentace prověřil možnosti napojení na zdroje dat u všech případů užití a do zadávací dokumentace zahrnul jen ty případy užití u kterých má informace, že připojení na zdroje dat je technicky proveditelné.
TECHNICKÁ SPECIFIKACE - Provozní informační portál DPKV
3.3. Specifické požadavky – parametry řešení
(1) V dále uvedených tabulkách jsou uvedeny minimální požadované parametry dodávaného řešení. Účastník doplní informaci o splnění požadovaného kritéria a uvede odkaz na konkrétní část nabídky, kterou splnění požadavku dokládá – tyto údaje ve struktuře a rozsahu dle této kapitoly musí být součástí nabídky.
(2) 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í, jedná se o tzv. povinný parametr, účastník musí všechny povinné parametry splnit, v případě nesplnění je jeho nabídka vyloučena;
▪ 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í.
(3) Seznam požadavků obsahuje strukturovaný přehled požadavků, každý požadavek je zde reprezentován identifikátorem, názvem a popisem. Požadavky na řešení jsou v seznamech požadavků dekomponovány do následujících kategorií:
▪ Požadavky na funkcionality – vymezení množiny funkcionalit, které bude technické řešení MIS nabízet uživatelům.
▪ Požadavky na vlastnosti – vymezení množiny kvalitativních parametrů MIS 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ů MIS, počet současně pracujících uživatelů a nutnost garantovaných vlastností MIS, 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 MIS včetně příp. sizingu HW prostředků.
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.
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í MIS 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 Zadavatele. Dalším důležitým faktorem je hledisko času nutného pro realizaci změn implementované MIS a případný rozvoj v podobě doplňování dalších služeb a funkcionalit MIS, 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 MIS musí být napojení MIS na provozní a bezpečnostní monitoring Poskytovatele či Zadavatele, který je přístupný pověřeným pracovníkům Zadavatele. To dá Zadavatele dostatečně silný nástroj na proaktivní sledování a řízení provozu MIS a zároveň nástroj na kontrolu činností Dodavatele, provozovatele MIS a případně dalších subjektů podílejících se na službách poskytovaných v souvislosti s MIS;
o Podporovatelnost – jedná se o požadavky na dostupnost podpory od výrobce nebo třetí strany, zaručený upgrade, opravy chyb, 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í MIS;
o Ostatní.
(4) 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í Zadavatele a existujícího informačního okolí MIS, viz popis stávajícího stavu.
(5) 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 atp.
(6) Požadavky na nástroje pro ETL (transformaci a uložení datových sad):
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
MIS-1-1 Podpora řízení datové integrace | MIS MUSÍ disponovat nástroji pro definování 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, |
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
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 naplá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 (MIS musí být schopna nastavit periodu „jobu“ alespoň 4x za den či vyšší). - V rámci transformace a uložení datových sad v datové vrstvě MIS MUSÍ být možné skládat data z různý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í) - MUSÍ umožnit zajištění snadné správy a údržby. S tím souvisí mj.: o Možnost restartovatelnosti ETL procesů 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); 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 ří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). | |||
MIS-1-2 Podpora řízení metadat | MIS MUSÍ podporovat tvorbu a správu metadat a disponuje rozhraním pro práci s metadaty. |
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
MIS-1-3 Export ETL logu | MIS 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 MIS výstupech (tj. zdroj dat, proces čištění dat, provedené transformace, cílové místo uložení). | ||
MIS-1-4 Zdroje dat z dalších IS resortu Zadavatele | MIS 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, Ingres, a další). MIS 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 vybrané typy RDMBS (PostgreSQL, MySQL5.1+, Oracle 10g+, MS SQL Server 2008+, Ingres, FireBird2.5) a nerelační databázi MONGO DB využívané IS Zadavatele. 3. File system – podporuje standardní napojení TCP transfer protokoly (minimálně FTPS, SCP, SFTP, HTTPS) pro získání nerelačních datových zdrojů (minimálně Microsoft Excel, strukturované soubory formátu CSV, JSON, XML). 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. | ||
MIS-1-5 Záznamy o načítání dat | Systém MUSÍ uchovávat informace o načítání, zpracování a kvalitě dat. |
(7) Požadavky na nástroje pro dimenzionální datovou vrstvu:
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
MIS-2-1 Datový sklad | Systém MUSÍ disponovat centrálním datovým úložištěm (datovým skladem), ve kterém budou ukládána transformovaná, vyčištěná a konsolidovaná data. Datový sklad MUSÍ umožnit uložení: |
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru | |
- 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 MIS v rámci opakovatelného použití; - Datové záznamy MUSÍ být v datovém skladu opatřeny časovými značkami (datum vzniku, platnost od, platnost do, zdroj dat, fáze zpracování dat); | ||||
MIS-2-2 modely | Reportovací | Nad datovým skladem MUSÍ být možno vytvářet jeden a více „reportovacích“ modelů (tj. datamartů pro jednotlivé byznys oblasti Zadavatele). Reportovací modely představují dimenzionální datové modely (dimenze, fakta z různých byznys oblastí), včetně dopočtených ukazatelů /metrik. | ||
Systém MUSÍ disponovat nástroji pro vytváření datových vrstev připravených pro reportování a tvorbu výstupů s daty ve formě faktů a dimenzí s možností definice vypočtených ukazatelů tak, aby pokročilí uživatelé, 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í (self-service BI). | ||||
(8) Požadavky na nástroje pro analýzy dat:
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
MIS-3-1 Rozsah analytických úloh | Systém MUSÍ umožňovat využít všechna data z MIS 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. | ||
MIS-3-2 Tvorba ad-hoc analýz | MIS 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 MIS pro použití dalšími uživateli. |
(9) Požadavky na funkční vlastnosti nástrojů pro vizualizaci dat:
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
MIS-4-1 Grafická vizualizace | Nástroje pro vizualizaci MUSÍ disponovat 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; V rámci vestavěných funkcí BY nástroje dále MĚLY umožňovat tvorbu následujících typů vizualizací: - Prstencové 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). | ||
MIS-4-2 Vizualizace pomocí tabulek | Nástroje pro vizualizaci MIS 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): |
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
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í zapínat/vypínat možnost modifikace finálních grafů či tabulek externími uživateli; o Možnost zapnout/ vypnout názvy sloupců/řádku a jejich přejmenování; o Zobrazení „tooltipu“ s detailem po najetí/označení hodnoty – včetně nastavení rozsahu informací. | |||
MIS-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ů). | ||
MIS-4-4 Drill down/up | MIS 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)). | ||
MIS-4-5 Filtrování, průřezy | Vizualizační nástroje MIS MUSÍ umožnit filtrování dat dle parametrů/dimenzí (různé filtry musí být možné nastavit na jednotlivé prvky sestavy). | ||
MIS-4-5 Filtrování přes vizualizační prvky | Vizualizační nástroje MIS MUSÍ umožnit vzájemné profiltrovaní vizualizačních prvků - provázání více tabulek grafů – závislostní interaktivita. A zároveň MUSÍ MIS umožnit tuto vlastnost uživatelům v případě potřeby vypnout. | ||
MIS-4-6 Podpora tvorby dashboardů | MIS MUSÍ podporovat vytváření vlastních dashboardů 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ř. sloupec v grafu) představovaly filtr, který mění i rozsah zobrazených hodnot v jiné částí (pohledech) sestavy (graf, tabulka). |
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
Pokročilým uživatelům MUSÍ MIS umožnit sestavy/dashboardy sdílet pro další autorizované uživatele zadavatele případně pro veřejnost (oprávněný uživatel sestavu/dashboard buď přímo opublikuje na portálu poskytovatele technologie, nebo předá EMBED kód nebo URL odkaz pro začlenění tohoto výstupu do příslušného webu). | |||
MIS-4-7 Možnosti exportu vytvořených sestav a grafických výstupů | MIS MUSÍ umožnit vyexportovat zvolené sestavy a grafické výstupy minimálně do formátů PDF. Data všech vizuálních prvků sestav (tabulek, grafů) MUSÍ umožnit exportovat minimálně do formátu CSV, XLS. | ||
MIS-4-8 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ě. |
(10) Požadavky na výstupní kanály/rozhraní (publikování výstupů):
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru | |
MIS-5-1 kanály | Výstupní | Systém MUSÍ nabízet minimálně následující výstupní kanály: 1. Možnost definovat pohledy na data v datovém skladu (např. SQL views) dle | ||
požadavků na přístup aplikací mimo MIS k datům z datové vrstvy MIS. | ||||
Neomezené poskytnutí dat z MIS 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 | ||||
Mobilní zařízení – MIS 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. | ||||
(11) Požadavky na funkční vlastnosti MIS:
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
MIS-7-1 Self- service MIS | MIS MUSÍ podporovat tzv. self-service MIS – 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. |
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
MIS-7-2 Nástroje pro pokročilé uživatele | Nad rámec prostředí self-service MIS, MUSÍ MIS nabídnout pro pokročilé uživatele 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; | ||
MIS-7-3 MIS Zpřístupnění dat | Systém MUSÍ umožnit v rámci MIS 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ř. už při zadání jen několika znaků z hledaného textového řetězce; - Možnosti exportu 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 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). | ||
MIS-7-4 Webový MIS portál, který je součástí MIS | Systém MUSÍ disponovat MIS webovým portálem pro publikaci MIS výstupů přístupný odkudkoliv tzn. i mimo síť zadavatele. 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, cílem je vysoká bezpečnost MIS 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 MIS. |
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
Publikační rozhraní MUSÍ být schopno vyhovět požadavkům více uživatelů ve stejném čase (cca 10 uživatelů pracujících současně) s přiměřenou dobou odezvy (viz požadavky na výkon). | |||
MIS-7-5 MIS Vyhledávání dat | Systém MUSÍ umožnit uživatelům vyhledávání nad všemi datovými entitami dimenzionálního modelu a zobrazení detailu dané entity. Vyhledávání MUSÍ být možné napříč všemi atributy evidovanými pro jednotlivé entity v dimenzionálního 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 Zadavateli vizuální modifikaci detailu, jež bude k entitě zobrazován. | ||
MIS-7-6 MIS Sestavy, dashboardy a vizualizace dat | Systém MUSÍ umožnit vytvoření sestav a/nebo dashboardů (nástěnek) jako prvků pro vizualizaci dat (viz MIS-4-1, MIS-4-2), a to nad všemi datovými sadami/datamarty a jejich entitami v dimenzionální datové vrstvě MIS. Systém MUSÍ umožňovat vytěžit všechna data ze sémantické datové vrstvy MIS 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ů). | ||
MIS-7-7 Aktualizace obsahu MIS výstupů | Obsah MIS výstupů MUSÍ být možné aktualizovat: - Pravidelně ke stanovenému času; - Manuálně. | ||
MIS-7-8 Využití MIS výstupů | MIS výstupy MUSÍ být možné: - Zpřístupnit vymezené skupině uživatelů s příslušnými přístupovými oprávněními v rámci MIS ; - Exportovat do obvyklých formátů: PDF, PPTX. | ||
MIS-7-9 MIS jednotný metamodel | Systém MUSÍ uživatelům umožnit tvorbu výstupů (sestav, dashboardů) pouze se znalostí dimenzionální datové (reportovací/prezentační) vrstvy a uživatelsky srozumitelného |
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
datového modelu, který bude jednotný pro celý systém a bude vytvořen již ve fázi přípravy dat. Jednotný datový model včetně dokumentace MUSÍ být přístupný vymezeným uživatelům systému. Datový model MUSÍ být možné tvořit, měnit, doplňovat a spravovat i vizuálně prostřednictvím grafického uživatelského rozhraní. | |||
MIS-7-10 MIS 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. | ||
MIS-7-11 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; Systém MUSÍ umožňovat distribuci 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ů). |
(12) Požadavky na architekturu:
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
MIS-8-1 Architektura systému | Systém MUSÍ být navržen tak, aby architektura systému umožňovala pravidelné i nepravidelné modifikace, doplňování a úpravy služeb, datových struktur a dalších prvků dle potřeb Zadavatele 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 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). | ||
MIS-8-2 On premise vs. cloud | MIS MUSÍ být cloud ready. Tedy jednotlivé komponenty a služby MUSÍ být možno provozovat v cloudu. MIS 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. | ||
MIS-8-3 Technologie přípustné pro tvorbu, údržbu a rozvoj MIS | 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), případně 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 MIS nebo třetích stran, na kterých je MIS vytvořena a provozována a které nebyly vyvinuty autorem specificky pro účely MIS Zadavatele. Standardizované SW produkty nebo též SW je souborné označení pro softwarové komponenty MIS, 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 MIS 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 |
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
v případě MIS Zadavatele. Zadavatel 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 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 stávající virtualizační platformy Objednatele využívající virtualizační SW Hyper-V. 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. | |||
MIS-8-4 Škálovatelnost | Jednotlivé komponenty MIS MUSÍ být škálovatelné rozšiřováním infrastruktury a komponent MIS bez potřeby reinstalace již existujícího řešení. |
(13) Požadavky na uživatelské rozhraní:
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
MIS-9-1 Podpora | MIS MUSÍ podporovat operační systémy klientských stanic Windows 10 včetně kompatibility s vyššími verzemi. |
operačního systému klientských stanic | |||
MIS-9-2 Podpora prohlížečů | MIS MUSÍ podporovat minimálně následující webové prohlížeče v posledních dvou dostupných verzích: - Chrome; - Edge; - Safari; - Firefox. | ||
MIS-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 min. na zařízeních s operačním systémem Android a IOS, ve verzích operačního systému z roku 2010 a vyšší (prostřednictvím dostupné mobilní aplikace nebo alespoň responzivní design). | ||
MIS-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 MIS 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í MIS nástrojů platforem; - Orientace ve výstupech – uživateli musí být vždy jasné, ve které části sestavy/reportu 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 MIS např. formou našeptávačů; - Konzistentnost uživatelského rozhraní – stejné či podobné funkcionality se napříč nástrojem musí chovat stejně a jejich ovládací prvky mají být umístěny stejně či podobně. | ||
MIS-9-5 Jazykové mutace MIS | Uživatelské rozhraní výstupů MUSÍ být v české jazykové mutaci, pokud uživatel využívá webový prohlížeč v češtině. | ||
MIS-9-6 Uživatelská nápověda | V rámci MIS MUSÍ být možno vytvářet a spravovat uživatelskou nápovědu (nad rámec uživatelských příruček). Uživatelská nápověda MUSÍ 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 MUSÍ mít formu online kontextové nápovědy či nápovědy formou wiki stránek atp. a musí být dostupná z těch míst systému, ke kterým se vztahuje. Tvůrci MIS sestav MUSÍ být schopni vytvářet nápovědu k vytvořeným MIS sestavám (k prvkům sestav). |
(14) Požadavky na spolehlivost:
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
MIS-10-1 Zálohování systému | Data MIS MUSÍ umožnit být pravidelně zálohovaná takovým způsobem, aby i v případě havárie nedošlo po obnovení provozu MIS ke ztrátě dat importovaných do MIS déle než 1 den před havárií, pokud nelze data obnovit znovu nahráním z primárních datových zdrojů. MIS MUSÍ umožnit provádění zálohování běžnými zálohovacími SW a Dodavatel MUSÍ Zadavateli 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. Aplikační instalace, data a logy MUSÍ být oddělené tak, aby je bylo možné zálohovat je samostatně a s rozdílnou četností. V případě havárie a potřebné obnovy provozu MIS MUSÍ být tato obnova realizovatelná Zadavatelem, bez nutné přímé spolupráce s Dodavatelem, a to na základě Dodavatelem dodaného dokumentu "Postup při obnově provozu". Zálohování dat bude probíhat výhradně na technologické platformě zadavatele, samotná služba zálohování dat není předmětem plnění, zálohování dat zajistí zadavatel. |
(15) Požadavky na výkon:
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je |
možné ověřit naplnění parametru | |||||
MIS-11-1 systému | Výkon | MIS 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ů – alespoň 10 souběžně 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í; - Přírůstky nových dat jsou v řádu desítek 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, 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 zkušební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. | |||
MIS-11-2 | Systém musí umožnit monitoring výkonových a objemových parametrů | rozhodných | pro | ||
Monitoring | vyhodnocování SLA. Tyto parametry musí být přístupné pro externí monitoring. | ||||
Monitoring samotný není předmětem plnění, bude jej provádět zadavatel. | |||||
(16) Požadavky na bezpečnost:
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
MIS-12-1 Identifikace a autorizace přístupů | MIS MUSÍ umožňovat nastavovat a řídit oprávnění pro jednotlivé role a oblasti přístupu. MIS MUSÍ umožňovat napojení na uživatelské skupiny definované v Active Directory zadavatele | ||
MIS-12-2 Důvěrnost a integrita | MIS 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 Zadavatele nebo Dodavatele. |
(17) Ostatní požadavky:
ID požadavku | Požadavek | Naplněn (ANO/NE) | Účastník uvede odkaz na přiloženou část nabídky, kde je možné ověřit naplnění parametru |
MIS-16-1 Práva k systému a jeho předání | Dodavatel předá Objednateli SW licenci/práva na část Díla, která vznikne 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á Zadavatele 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), 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. | ||
MIS-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é Zadavatele i Dodavateli na kolaborativním nástroji (typu GitHub) určeném Objednatelem. |
TECHNICKÁ SPECIFIKACE - Provozní informační portál DPKV
4. Implementační služby
4.1. Obecné požadavky
(1) Zadavatel požaduje provést minimálně následující implementační práce na dodaných komponentech a případně dalších zařízeních. Uchazeč je dále povinen zahrnout do nabídky veškeré další činnosti a prostředky, které jsou nezbytné pro provedení díla v rozsahu doporučeném výrobci a dle tzv. nejlepších praktik, i v případě, pokud nejsou explicitně uvedeny, ale jsou pro realizaci předmětu plnění podstatné. Implementační služby budou minimálně v následujícím rozsahu:
(a) Zajištění projektového vedení realizace předmětu plnění.
(b) Zpracování prováděcí dokumentace, která představuje projektovou dokumentaci, podle které se projekt bude realizovat. Součástí zpracování prováděcí dokumentace je mj. provedení předimplementační analýzy a zpracování finálního návrhu cílového stavu.
(c) Dodávku nabízených prvků a kompletní implementaci řešení splňující povinné parametry technického řešení,
(d) Provedení školení,
(e) Zajištění zkušebního provozu,
(f) Provedení akceptačních testů,
(g) Zpracování provozní dokumentace v rozsahu detailního popisu skutečného provedení a popisu činností běžné údržby a administrace systémů a činností pro spolehlivé zajištění provozu.
(h) Předání do ostrého provozu,
(2) Náklady na provedení implementačních služeb musí být zahrnuty v nabídkové ceně k položce, ke které se vztahují a nelze je vyčíslit zvlášť.
(3) Uchazeč dle svého uvážení může doplnit v nabídce další služby, které jsou dle jeho názoru potřebné pro úspěšnou realizaci zakázky.
(4) Veškerá dokumentace musí být zhotovena výhradně v českém jazyce, bude dodána v elektronické formě ve standartních formátech (např. MS Office) používaných zadavatelem.
4.2. Požadavky na zpracování prováděcí dokumentace
(1) Uchazeč před zahájením implementačních prací zpracuje prováděcí dokumentaci, která bude důsledně vycházet z předimplementační analýzy a bude zahrnovat všechny aktivity potřebné pro řádné zajištění implementace předmětu plnění.
(2) Jako podklad pro zpracování prováděcí dokumentace tedy uchazeč provede předimplementační analýzu, která bude zohledňovat stávající prostředí zadavatele ve vztahu ke konkrétnímu nabízenému plnění uchazeče, zejména pak s ohledem na uchazečem použité technické řešení, minimálně pro následující oblasti:
(a) Analýza možností napojení zdrojových aplikačních systémů, resp. možností získávání jejich dat.
(b) Analýza nároků datového skladu (DWH) na ukládání a zálohování dat, toky a objemy dat, nároky na výpočetní kapacity s ohledem na implementaci systému MIS.
(c) Aktualizace požadavků na uživatelské prostředí a požadované funkce – uchazeč provede aktualizaci katalogu požadavků zadavatele tak, aby výsledné řešení odpovídalo ZD a aktuálnímu stavu informačních systémů zadavatele v době zpracování předimplementační analýzy.
(d) Požadavky na rekonfiguraci stávajících systémů ve vztahu k plánovanému využití jejich dat.
(e) Dopady implementace na dostupnost a funkčnost stávajících služeb.
(f) Požadované součinnosti Zadavatele.
(g) Návrh opatření k odstranění neshod zjištěných v průběhu analýzy.
(3) Prováděcí dokumentace musí zohlednit podmínky stávajícího stavu, požadavky cílového stavu dle zadávací dokumentace a konkrétního technického řešení nabízeného uchazečem a musí obsahovat minimálně tyto části:
(a) Detailní popis cílového stavu včetně funkcionalit jednotlivých částí systému,
(b) Způsob zajištění dodávek a služeb,
(c) Způsob zajištění koordinace realizace předmětu plnění s běžným provozem,
(d) Detailní návrh a popis postupu implementace předmětu plnění,
(e) Detailní popis zajištění bezpečnosti informací,
(f) Detailní harmonogram projektu včetně uvedení kritických milníků,
(g) Vazby na stávající systémy a jejich konfigurace,
(h) Návrh akceptačních kritérií a akceptačních testů,
(i) Detailní popis navrhovaných školení.
(j) Obsah a rozsah provozní dokumentace.
(4) Prováděcí dokumentace musí být před zahájením realizace dalších etap plnění výslovně schválena zadavatelem.
(5) Prováděcí dokumentace bude před ukončením zkušebního provozu aktualizována dle skutečného stavu a následně bude součástí provozní dokumentace.
4.3. Harmonogram realizace
(1) Uchazeč zajistí projektové vedení po celou dobu realizace zakázky osobou odpovědnou za realizaci předmětu plnění, která bude hlavní kontaktní osobou a která bude přítomna při všech jednáních týkajících se projektu.
(2) Zadavatel vyžaduje dodržení následujícího harmonogramu plnění – zde jsou uvedeny maximální možné lhůty pro jednotlivé kritické milníky. Údaj D značí datum účinnosti smlouvy o dílo, čísla značí počet kalendářních dnů. Údaj A značí datum předání díla, čísla značí počet kalendářních měsíců.
Poř. č. | Aktivita projektu | Termín pro dokončení aktivity |
Etapa 1 - dodání a implementace provozního informačního portálu | ||
E1.1 | Předimplementační analýza a zhotovení Prováděcí dokumentace | D+30 |
E1.2 | Předání Prováděcí dokumentace Zadavateli, připomínkové řízení | D+30 |
E1.3 | Zapracování připomínek a předání finální verze Prováděcí dokumentace – akceptace Zadavatelem | D+35 |
E1.4 | Dodávky a implementace | D+90 |
E1.5 | Školení uživatelů a administrátorů | D+90 |
E1.6 | Akceptační testy | D+90 |
Etapa 2 - podpora provozu | ||
E2.1 | Zkušební provoz | D+180 |
E2.2 | Produkční provoz | A+48 (měs) |
(3) Uchazeč může dle svého uvážení výše uvedené maximální lhůty trvání v rámci Etapy 1 zkrátit při dodržení všech částí předmětu plnění a bez snížení kvality dodávaných služeb.
(4) Maximální lhůty trvání nesmí uchazeč při tvorbě detailního harmonogramu prodloužit.
(5) Uchazeč uvede závazný harmonogram plnění ve své nabídce a zároveň v návrhu smlouvy o dílo.
(6) Uchazeč uvede potřebnou součinnost zadavatele pro splnění harmonogramu plnění ve své nabídce.
4.4. Požadavky na školení
(1) Uchazeč zajistí školení pracovníků Zadavatele – administrátorů a uživatelů – na zařízení a systémy, dodávané v rámci této veřejné zakázky, a to minimálně v rozsahu předávané provozní dokumentace.
(2) Školení zajistí seznámení pracovníků Zadavatele se všemi podstatnými částmi díla v rozsahu potřebném pro provoz, údržbu a identifikaci nestandardních stavů systému a jejich příčin a pracovníkům bude vystaveno osvědčení o školení s uvedením rozsahu školení. Budou provedena tato školení:
(a) Školení administrátorů – minimální rozsah školení je 6 hodin, předpokládá se účast max. 10 účastníků, školení bude probíhat v sídle Zadavatele.
(b) Školení uživatelů – minimální rozsah školení je 6 hodin, předpokládá se účast max. 10 účastníků, školení bude probíhat v sídle Zadavatele.
(3) Náklady na školení musí být zahrnuty v nabídkové ceně k položce, ke které se vztahují a nelze je vyčíslit zvlášť.
(4) S ohledem na pandemii COVID-19 musí být formát školení připraven jak pro prezenční výuku, tak pro možnost provedení školení elektronicky (vzdálenou formou) např. pomocí MS Teams nebo jiných elektronických prostředí pro výuku. Formát školení bude zvolen zadavatelem nejpozději týden před realizací školení, a to podle aktuálního stavu pandemie a dle doporučení relevantních orgánů (Ministerstvo zdravotnictví ČR, Hygienická stanice atp.).
4.5. Požadavky na provedení akceptačních testů a přechod do zkušebního provozu
(1) Uchazeč navrhne způsob a provedení akceptačních testů.
(2) Součástí akceptačních testů musí být minimálně:
(a) Ověření (otestování) veškerých požadovaných funkcí a parametrů všech komponent a služeb
(3) O provedení akceptace a jejím výsledku musí být vyhotoven písemný protokol.
(4) Přechodem do zkušebního provozu se rozumí okamžik úspěšné akceptace díla včetně vypořádání všech vad a nedodělků bránících užití systému.
4.6. Požadavky na provozní dokumentaci
(1) Uchazeč zpracuje provozní dokumentaci, která bude detailně popisovat konfiguraci zhotoveného díla a jeho vazby na stávající systémy.
(2) Provozní dokumentace bude vycházet z prováděcí dokumentace, která bude před předáním do provozu aktualizovaná dle skutečného stavu.
(3) Součástí provozní dokumentace bude popis úkonů doporučené údržby a specifikace intervalů jejích provádění a další dokumentaci v rozsahu stanoveném v prováděcí dokumentaci.
(4) Uchazeč uvede do nabídky kompletní podmínky pro zajištění provozu dodaných prvků, včetně požadavků na aktualizace software (maintenance).
5. Požadavky na záruky
(1) Zadavatel požaduje záruku na veškeré dodané technologie v délce trvání minimálně 24 měsíců od okamžiku předání do zkušebního provozu, není-li u konkrétního zařízení či komponenty uvedeno jinak jejím výrobcem.
(2) Veškeré opravy po dobu záruky budou provedeny bez dalších nákladů pro zadavatele. Veškeré komponenty, náhradní díly a práce, poskytnuté v rámci záruky budou poskytnuty bezplatně.
(3) Uchazeč ve své nabídce výslovně uvede všechny podmínky záruk.
6. Požadavky na podporu provozu
6.1. Obecná pravidla provozu
(1) Zadavatel požaduje detailní návrh podmínek podpory provozu, zajišťující plnohodnotný provoz předmětu plnění od doby předání do provozu. Uchazeč podle svého uvážení může provést úpravu parametrů, pokud takové úpravy nepovedou ke zhoršení podmínek zajištění podpory provozu.
(2) Pro hlášení servisní požadavků zajistí Xxxxxxx Xxxxxxxxxxx přístup ke svému helpdeskovému systému s on-line přístupem pro kompletní správu požadavků včetně uchování historie požadavků a jejich řešení. Detailní popis helpdeskového systému a jeho obsluhy musí být součástí předané dokumentace.
(3) Provozní doba helpdeskového systému musí být minimálně 8-17 hod. v pracovních dnech.
(4) Běžná pracovní doba zadavatele je období mezi 8:00 a 17:00 v pracovní dny.
(5) Provozem se rozumí chod a udržování jednotlivých částí řešení, včetně aktuální provozní dokumentace.
(6) Pravidla vzdáleného přístupu budou vítěznému uchazeči předána při podpisu smlouvy.
(7) Zásahy jsou přednostně prováděny mimo provozní dobu zadavatele tzn. pondělí až pátek, od 8h do 17h. O nutnosti zásahů v provozní době služby rozhoduje projektový manažer uchazeče a 48 hodin předem o nich informuje uživatele. Pokud je nevyhnutelně nutné provést zásah
okamžitě, operátor Helpdesku a oprávněná osoba zadavatele jsou o této skutečnosti neprodleně informováni.
(8) Neplánované zásahy do systému, které mohou ovlivnit uživatelské prostředí, jsou uživatelům oznámeny minimálně 1 hodinu před zahájením poskytování služby nebo činnosti.
(9) Plánované zásahy do systému, které mohou ovlivnit uživatelské prostředí, jsou uživatelům oznámeny minimálně 24 hodin před zahájením poskytování služby nebo činnosti
6.2. Požadavky na podporu zkušebního provozu
(1) Uchazeč zajistí podporu zkušebního provozu včetně technické podpory na dodané řešení s odezvou maximálně do 4 hodin od nahlášení požadavku v pracovní den v době od 8 h do 17 h.
(2) V případě incidentu kategorie A nebo B musí uchazeč zajistit odstranění závady do dvou pracovních dní.
(3) Po uplynutí lhůty pro zkušební provoz bude dílo předáno do provozu.
6.3. Požadavky na podporu provozu
(1) Rozsah základní servisní podpory:
(a) Řešení Incidentů kategorie A, B nebo C v rozsahu maximálně 12 hodin měsíčně. Pokud se během řešení Incidentu ukáže, že se jedná o vadu, která spadá pod záruky systému, nebude se čas potřebný pro řešení incidentu započítávat do rozsahu měsíčního plnění.
(b) Helpdeskový systém s on-line přístupem (web, e-mail) pro kompletní správu požadavků včetně uchování historie požadavků a jejich řešení.
(2) Rozsah rozšířené servisní podpory:
(a) Řešení Incidentů kategorie A, B nebo C nad rozsah základní servisní podpory (tzn. nad 12 hodin měsíčně). Pokud se během řešení Incidentu ukáže, že se jedná o vadu, která spadá pod záruky systému, nebude se čas potřebný pro řešení incidentu započítávat do rozsahu plnění.
(b) Řešení Incidentů kategorie D na vyžádání objednatelem.
(c) Odborná podpora – vzdálené konzultace pro podporované služby/produkty
(3) Pro případ, že bude zadavatel požadovat služby rozšířené servisní podpory podle odst. (2) jako např. konzultace, servisní zásahy, instalace, konfigurace, řešení problémů atp., budou tyto služby vyúčtovány na konci měsíce v hodinové sazbě uvedené v odst. 4.3 písm. b) servisní smlouvy (část 4b zadávací dokumentace) dle skutečně realizovaných hodin rozšířené servisní podpory. Předpokládaný rozsah služeb rozšířené servisní podpory pro účely přípravy nabídky je 1 hodina měsíčně.
6.4. Způsob poskytování servisní podpory
(1) Servisní podpora je poskytována zejména následujícím způsobem:
(a) Prostřednictvím pracovníka Uchazeče Vzdálenou správou
(b) Prostřednictvím pracovníka Uchazeče přímo na pracovišti Zadavatele
(c) Prostřednictvím pracovníka Uchazeče formou vzdálené konzultace
(2) Uchazeč provede záznam o provedení servisní podpory, v záznamu uveden relevantní informace včetně doby poskytování servisní podpory a záznam zašle elektronicky zadavateli. Servisní služby, které jsou poskytovány vzdálenou formou, mohou být evidovány v elektronickém seznamu provedených úkonů.
(3) Zadavatel je povinen zabezpečit Uchazeči podmínky pro řádné plnění, zejména
(a) zajistit a udržovat podmínky pro Vzdálený přístup Uchazeče, (b) zajistit dostupnost nebo odpovídající zástup Odpovědné osoby Zadavatele, vyhrazení odpovídajících časových kapacit Odpovědné osoby Zadavatele a zajištění efektivní součinnosti odborných pracovníků Zadavatele, (c) zabezpečit přítomnost kvalifikované osoby, která poskytne pracovníku Uchazeče veškeré informace či přístupy potřebné k podpoře předmětného systému, resp. informace o zařízeních a programovém vybavení souvisejícím s předmětným systémem, (d) umožnit Uchazeči v případě nutnosti a po předchozím oznámení odstavení technických prostředků z běžného provozu, (e) zajistit součinnost třetí strany, jestliže je to pro provedení služby potřebné. (4) V případě, že nebudou uvedené podmínky Zadavatelem prokazatelně zabezpečeny, lhůta pro vyřešení případného Incidentu se zastaví a počítat se bude až po obnovení zabezpečení uvedených podmínek. (5) Uchazeč je v případě potřeby též z vlastní iniciativy oprávněn požádat Zadavatele o dodatečné údaje o Incidentu a o nezbytnou součinnost Zadavatele na řešení Incidentu, bez které nelze zahájit či pokračovat v řešení Incidentu. Tím se zastavuje započítávání času, což je rozhodující pro určení čistého času řešení Incidentu. (6) Zadavatel je povinen (a) elektronicky potvrdit Uchazeči provedení služby, (b) zajistit zálohování dat i programů a výměnu zálohovacích médií dle zálohovacího plánu, jejich dostupnost v případě potřeba a jejich uložení na bezpečných místech tak, aby bylo nešlo k jejich ztrátě nebo poškození, (c) poskytovat potřebné nebo vyžádané informace a podklady včetně dokumentace k předmětnému systému nebo zařízení a programovému vybavení, které s ním souvisí. 6.5. Postup při řešení incidentů (1) Zadavatel bude incident oznamovat Uchazeči bez zbytečného odkladu jedním ze způsobů a na kontaktních místech uvedených ve Smlouvě o zabezpečení provozu, kam budou mít zajištěny přístup pověřené osoby Zadavatele. (2) Součástí nahlášení požadavku Zadavatelem musí být: (a) navrhovaná kategorizace a závažnost, (b) popis Incidentu nebo Požadavku, (c) jiné relevantní upřesňující informace, včetně případných textových či obrazových příloh nezbytných pro replikaci incidentu, (d) kontaktní osoba. (3) Uchazečem používaný systém pro HelpDesk musí pokrýt uvedené informace pro nahlášení požadavku. (4) Incidenty musí být před jejich nahlášením začleněny do skupin, viz dále a dle těchto skupin bude Uchazeč přistupovat k jejich řešení: |
Incident/vada kategorie A |
Předmět plnění není použitelný ve svých základních funkcích nebo se vyskytuje funkční závada znemožňující jeho používání. Tento stav může ohrozit běžný provoz, případně může způsobit větší finanční nebo jiné škody. |
Incident/vada kategorie B |
Předmět plnění je ve svých funkcích degradován tak, že tento stav omezuje běžný provoz. |
Incident/vada kategorie C |
Ostatní - drobné incidenty/vady, které nespadají do kategorií A a/nebo B a které nejsou způsobeny software třetích stran. |
Incident/vada kategorie D |
Incidenty/vady, které jsou způsobeny software třetích stran. |
(5) Uchazeč neprodleně potvrdí obdržení požadavku v systému HelpDesk a poskytne Zadavateli informace o předpokládaném způsobu řešení požadavku, požadavcích na součinnost Zadavatele a předpokládaný termín vyřešení požadavku.
(6) Uchazeč má právo změnit kategorii incidentu v případě, že Zadavatelem uvedená kategorie neodpovídá závažnosti incidentu. Změnu musí v HelpDesku zdůvodnit a Zadavatel ji musí v HelpDesku potvrdit.
(7) Uchazeč v průběhu řešení požadavku, pokud mu to charakter požadavku a způsob řešení umožňuje, průběžně informuje Zadavatele o aktuálním stavu a případných změnách v předpokládaném způsobu, požadované součinnosti a termínů vyřešení. V případě že Xxxxxxx v průběhu řešení požadavku zjistí, že se jedná o Incident, jehož zdroj je prvek třetích stran, informuje Zadavatele o této skutečnosti, předpokládaném způsobu, požadované součinnosti a termínů vyřešení – zároveň přeřadí Incident do kategorie D a pokračuje v řešení v režimu BE (Best Effort) tzn. Uchazeč vyvine maximální možné úsilí na provedení požadavku a zejména na zajištění požadovaných parametrů předmětu plnění v nejkratší možné době.
(8) Zjistí-li Uchazeč v průběhu řešení Incidentu, že Incident je neodstranitelný, je v rámci Běžné pracovní doby povinen nepřetržitě pracovat na náhradním řešení a informovat o tomto stavu Zadavatele. Výskyt neodstranitelného Incidentu může být ze strany Zadavatele považován za podstatné porušení této smlouvy v případech, že Incident byl způsoben předchozím přímým jednáním Uchazeče, pokud o nich mohl mít s vynaložením veškeré odborné péče povědomost.
(9) Zjistí-li Uchazeč v průběhu řešení Incidentu, že Incident má přímou souvislost s neodborným či neoprávněným jednáním osob Zadavatele případně byl Incident vyvolán produkty či službami třetí osoby, je Uchazeč povinen bezodkladně informovat o tomto stavu Zadavatele. Zadavatel se zavazuje bezodkladně uhradit v plné výši náklady nad rámec této smlouvy Uchazečem prokazatelně vynaložené k řešení Incidentu, přičemž samotná identifikace Incidentu je součástí plnění této smlouvy.
(10) Zadavatel je oprávněn dořešení Incidentu kdykoliv zastavit či pozastavit, přičemž nárok Uchazeče na úhradu již vynaložených prostředků zůstává nedotčen. Incident je v tomto případě považován za vyřešený.
(11) V případě úspěšného vyřešení požadavku, je řešitel před ukončením požadavku povinen provést ověření funkčnosti služby (pokud je to možné). Iniciátora Incidentu informuje o:
(a) čase vyřešení požadavku,
(b) v případě Incidentu specifikuje příčinu (pokud je známa),
(c) vyzve iniciátora k ověření funkčnosti služby.
(12) Po ověření funkčnosti ze strany Zadavatele se Požadavek považuje za vyřešený.
(13) Po vyřešení požadavku Uchazeč požadavek uzavře v systému HelpDesk a informuje Xxxxxxxxxx. V případě Incidentu kategorie A zasílá návrh opatření pro snížení nebo eliminaci možnosti opakování stejného Incidentu.
(14) Zadavatel má právo ve lhůtě 10 dnů od uzavření požadavku vznést výhrady nebo připomínky ke způsobu řešení nebo k výslednému stavu; v takovém případě se požadavek nepovažuje za uzavřený a Strany se zavazují zahájit společné jednání za účelem odstranění veškerých vzájemných rozporů a nalezení shody nad způsobem řešení nebo výsledném stavu, a to nejpozději do pěti (5) pracovních dnů od výzvy kterékoliv Strany.
6.6. Záruky na servisní služby
(1) Zadavatel požaduje záruku na veškeré servisní služby provedené v rámci podpory provozu v délce trvání minimálně 3 měsíců (není-li u konkrétní služby uvedeno jinak) od okamžiku realizace. Veškeré opravy po dobu záruky budou bez dalších nákladů pro provozovatele.