No title

Příloha č. 1: Podrobná specifikace Díla

I.

ÚVODNÍ USTANOVENÍ

Zhotovitel se zavazuje dodat, implementovat v cílovém prostředí určeném Objednatelem, nastavit a zprovoznit IS tak, aby splňoval následující požadavky, vykazoval následující vlastnosti a disponoval uvedenými funkcemi. II.

POŽADAVKY NA VSTUPNÍ DATA IS

IS umožní ručně pořídit, spravovat a zálohovat níže uvedené konkrétní typy dat a provádět nad nimi operace uvedené dále v článku III. IS bude disponovat vhodně strukturovanými formuláři, které umožní co nejjednodušší pořízení a správu uvedených dat s co nejnižší náročnosti na pracnost uživatelů IS. Pro přehlednost jsou požadavky na vstupní data IS členěny do následujících kategorií: 

Evidence relevantního technického majetku;



Odběry a dodávky paliv, komodit a energií;



Skladové hospodářství.

2.1 Evidence relevantního technického majetku Do IS bude, vztažně k jednotlivým zařízením, možné vkládat a dále v něm spravovat minimálně tato evidenční data technických zařízení provozovaných objednatelem: 

Standardní údaje o nabytí, převodu, předání k obsluze či pronájmu majetku provozovaném Objednatelem, minimálně v rozsahu: o Vztah k majetku z pohledu vlastnictví daného majetku; o Odkaz na doklad o nabytí, převodu či pronájmu majetku nebo možnost vložení elektronické kopie dokladu; o Datum nabytí, převodu či pronájmu majetku; o Datum uvedení do provozu; o Relevantní údaje o hodnotě technického zařízení (například hodnota při pořízení, zůstatková hodnota atp.); o Odkaz na doklad o kolaudačním rozhodnutí nebo možnost vložení elektronické kopie dokladu;



Standardní technické údaje o teplárenských a vodohospodářských technologiích a zařízeních provozovaných Objednatelem, které budou upřesněny v rámci Fáze 1., rámcově v rozsahu: o Informace o příslušném nákladovém středisku, příslušnosti k inventárnímu úseku a umístění a evidenci správce technického zařízení; o Relevantní, souhrnné technické údaje související s typem zařízení například: 

Umístění, účinnost, počet tlakových nádob stabilních (TNS), počet napojených předávacích stanic (PS) atp. 1

o Relevantní technické údaje o součástech technických zařízení: 

Údaje o měřících zařízeních (například typ, pořizovací náklady atp.);



Údaje o kotlích (například typ, rok výroby, výkon atp.);



Údaje o rozvodech zařízení dle typu rozvodu (například číslo zakázky připojené k rozvodu, popis, délka atp.);



IS umožní vytvoření nové šablony, dle typu zařízení.



ID, číslo zakázky, typ, umístění, instalovaný výkon, topné médium.

o PS: o TNS: 

ID, název, typ, umístění, použití.

o Relevantní informace o obsluze technických zařízení, minimálně v rozsahu: 

Frekvence obsluhy (trvalá, občasná);



Skupina obsluh;



Oprávnění;



Odkaz na dokumenty obsahující havarijní řád, provozní řád a požární řád nebo možnost vložení elektronické kopie dokumentu;



Odkaz na dokument obsahující smlouvu o dodávce nebo možnost vložení elektronické kopie;



Potřebná kapacita obsluhy spravující technické zařízení;



Identifikační údaje o dodavatelích a organizacích poskytujících servisní služby včetně dat o souvisejících technologiích využitých při poskytování servisní služby;

o Relevantní informace o příslušenství technických zařízení (například název, pořizovací cena atp.). 

Standardní data provozní knihy technických zařízení se zápisy o provozních zkouškách, revizích a pravidelných kontrolách, minimálně v rozsahu: o Datum poslední vykonané revize, provozní zkoušky a pravidelné kontroly; o Datum plánované budoucí revize, provozní zkoušky a pravidelné kontroly; o Odkaz na dokument obsahující záznam z poslední vykonané revize, provozní zkoušky a pravidelné kontroly; o Systém dále umožní vytvoření provozního deníku ke každému technickému zařízení.



Standardní záznamy o předpokládaných a provedených opravách technických zařízení, minimálně v rozsahu: o Datum opravy; o Popis charakteru opravy; o Cena opravy v Kč.



Standardní záznamy o kalibracích měřících zařízení, minimálně v rozsahu: o Datum poslední provedené kalibrace; o Datum plánované kalibrace;

2

o Odkaz na dokument obsahující informace o poslední provedené kalibraci nebo možnost vložení elektronické kopie dokumentu. 

Standardní záznamy o provedených měřeních parametrů technických zařízení, minimálně v rozsahu: o Datum provedení měření; o Naměřená data o technickém zařízení; o Cena provedeného měření; o Odkaz na cílové umístění posledního protokolu o provedeném měření v elektronickém formátu.



Standardní data o plánovaných měřeních parametrů technických zařízení, minimálně v rozsahu: o Datum plánovaného měření; o Předpokládaná cena měření;



Data o dalších uživatelem definovaných periodických činnostech vztažených k technickým zařízením;



Standardní data pasportů technických zařízení;



Data o záruční době jednotlivých technických zařízení;



Data o polohách jednotlivých technických zařízení;



Odkaz na zobrazení umístění jednotlivých technických zařízení na mapě ČR.

2.2 Odběry a dodávky paliv, komodit a energií Do IS bude možné vkládat a dále v něm spravovat minimálně tato data týkající se odběrů a dodávek paliv, komodit a energií: 

Standardní evidenční data o uzavřených smluvních vztazích a odběrných místech s dodavateli komodit, rozdělení na primární paliva: elektřina, plynná, kapalná a pevná s rozdělením druhu a typu, a dále pomocné komodity: elektřina, vodné, stočné;



Standardní data o měsíčních odběrech energií a vody (například počáteční a koncový stav, cena za jednotku atp.);



Standardní data potřebná pro určení budoucí spotřeby a odběrového diagramu tepla jednotlivých odběratelů (například nasmlouvaný výkon, vytápěná plocha, denní spotřeba, topné médium atp.);



Data o měsíčních dodávkách plynu, tepla a teplé vody pro VUSS (Vojenská ubytovací a stavební správa);



Standardní data o spotřebě paliva jednotlivých kotelen;



Standardní data o odběru energií v členění dle odběrných míst v závislosti na druhu energie;



Standardní data o dodávkách tepelné energie v členění dle odběrných míst pro vytápění, provoz technologií a pro přípravu teplé vody;



Samostatně data o měsíčních dodávkách ubytovnám a bytům (pro potřeby vnitropodnikového účetnictví);



Standardní data pro tvorbu plánu spotřeby paliv na finanční rok; 3



Standardní data pro tvorbu plánu dodávek tepla na finanční rok;



Standardní data pro tvorbu plánu režijních nákladů na finanční rok;



Standardní data o cenách pro nákup a prodej elektrické energie;



Standardní data pro tvorbu dohadných položek na náklady v měsíčním rozlišení, minimálně v rozsahu: o Náklady na nákup paliva, o Náklady na nákup vody, o Náklady na nákup elektrické energie, o Náklady na zajištění obsluhy technických zařízení, o Náklady na zajištění oprav, o Uvedení informace o tom, zda je Objednatel v pozici maloodběratele či velkoodběratele;



Data o neoprávněných nákladech1 vztažených k jednotlivým zakázkám;



Data pro měsíční kalkulaci odvodů DPH za bezplatné odběry;



Data pro měsíční vyúčtování bezplatných odběrů podle odběratele (VUSS a CE);



Standardní data o klientech, minimálně v rozsahu: o Typ klienta (komerční sektor, VUSS, interní klient v rámci organizace Objednatele), o Kontaktní údaje.



Standardní data pro fakturaci či jinou formu doložení nákladů poskytnutého plnění a související ceny, minimálně v rozsahu: o Přijaté zálohy, o Provedená vyúčtování, o Rozpočtová opatření.

2.3 Stav a pohyb zásob souvisejících s energetickým managementem Do IS bude možné vkládat a dále v něm spravovat standardní data související se stavem a pohybem zásob, minimálně v tomto rozsahu: 

Záznamy o příjmu zásob;



Záznamy o výdeji zásob;



Údaje o současném stavu zásob;



Odkaz na záznam o převzetí zásob nebo možnost vložení elektronické kopie dokumentu. III.

POŽADAVKY NA VÝSTUPNÍ DATA IS

IS umožní vytvořit a vytisknout či exportovat do formátů standardních nástrojů MS Office či formátu PDF dále uvedené konkrétní typy datových výstupů. IS bude disponovat vhodně strukturovanými formuláři, které zajistí co nejvyšší přehlednost a informační hodnotu datových výstupů. 1

Neoprávněné náklady jsou náklady, které je možné zahrnout do ceny pouze předem určeným klientům, není možné je například započítat zákazníkům ze soukromého sektoru, naopak je nutné je zahrnout do výkazů pro zřizovatele.

4

Pro přehlednost jsou požadavky na výstupní data IS členěny do následujících kategorií: 

Pravidelné reporty;



Uživatelské sestavy;



Povinné výkazy.

3.1 Pravidelné reporty IS umožní automatické generování a následné rozeslání minimálně pěti standardních reportů na určené emailové adresy, přičemž přesná podoba těchto reportů se upřesní v rámci Fáze 1. Finální podoba reportů se bude odvíjet od jejich účelu. Rámcově se bude jednat o následující reporty: 

Souhrnný report pro potřeby managementu Objednatele;



Report obsahující informace o celkových hodnotách dodaného tepla a nákladech na jeho výrobu a v obdobné struktuře i pro ostatní dodávané komodity a energie;



Report obsahující informace o celkových finančních objemech fakturovaných jednotlivým klientům;



Další reporty, dle potřeb Objednatele;



IS dále umožní jednoduché nastavení vlastních uživatelských reportů pracovníkům Objednatele s příslušným oprávněním.

3.2 Uživatelské sestavy IS umožní uživateli generovat standardní sestavy, jejichž přesná podoba bude upřesněna v rámci Fáze 1., minimálně v rozsahu: 

Vyúčtování nákladů za dodávku tepla pro vytápění a ohřev teplé užitkové vody a dodávku studené vody (například informace o dodavateli a odběrateli, druh a období spotřeby, počáteční a konečný stav měřidla, celkovou cenu s DPH i bez DPH);



Přehled dodávek tepla VUSS obsahující relevantní údaje (například účetní období, lokalitu kotelny, částku za dodané teplo s DPH i bez DPH atp.);



Podklad pro fakturaci za spotřebu zemního plynu obsahující relevantní údaje (např. číslo zdroje, místo odběru, sledované období, číslo plynoměru, přepočtový koeficient určený dodavatelem plynu, informace o odběrateli atp.) a obdobně pro další využívaná paliva.

IS dále umožní uživateli nastavit vytvoření ad hoc sestavy s následujícími vlastnostmi: 

Volitelnou délkou sledovaného období;



Členěním dle: o jednotlivých energetických komodit, o zákazníků, o předávacích míst, o případně hierarchické kombinace výše uvedeného.

5

3.3 Povinné výkazy IS umožní generovat povinné výkazy (minimálně 30) v předem určené struktuře a grafické úpravě dané příslušným zákonem, vyhláškou, předpisem či závazným požadavkem ze strany příjemce výkazu: 

Všechny zákonem, vyhláškou, předpisem či závazným požadavkem určené výkazy určené pro instituce či orgány minimálně v rozsahu: o Hlášení v oblasti ekologie: 

Vypouštění odp. vod 38-4,



Poplatkové hlášení – odpadní vody,



Poplatkové přiznání – odpadní vody,



Poplatkové hlášení – jímání podzemních vod,



Poplatkové přiznání – jímání podzemních vod,



Ohlašování údajů pro vodní bilanci,



Oznámení o výpočtu poplatku a ohlášení SPE,



Roční hlášení o produkci odpadu po jednotlivých provozovnách Objednatele.

o Hlášení v oblasti energie 

Výkaz 31, 32-CP: Výkaz cen a technických parametrů,



Výkaz 31, 32-DK a) Technický výkaz tepelné energie (část a),



Výkaz 31, 32-DK a) Technický výkaz tepelné energie (část b),



Roční výkaz o výrobě a rozvodu elektrické a tepelné energie (ČSÚ) EP10-01,



Roční výkaz o spotřebě paliv a energie a zásobách paliv (ČSÚ) EP501(c),



Roční výkaz o dodávkách elektřiny, tepla, energetických plynů a o palivech užitých na produkci elektřiny a tepla (MPO) Eng(MPO)5-01,



Čtvrtletní výkaz o spotřebě paliv a energie a spotřebitelských zásobách paliva,

 

Přiznání k uplatnění nároku na vrácení spotřební daně.

Další výkazy dle požadavků Objednatele, například: o Souhrnné výkazy pro výběrová řízení na dodavatele komodit. IV.

POŽADAVKY NA FUNKCE IS

IS musí disponovat minimálně dále uvedenými funkcemi. Pro přehlednost jsou požadavky na funkce IS členěny do následujících kategorií: 

Kalkulace a automatické výpočty,



Plánování a modelování,



Monitorování,



Uživatelské nastavení,



Uživatelská oprávnění a správa přístupů. 6

4.1 Kalkulace a automatické výpočty IS umožní následující operace nad spravovanými daty: 

Automatické generování standardního diagramu provozních hodin energetického zařízení, tj. počtu dní zařízení v provozu mezi jednotlivými evidencemi;



Automatické vytváření předem předdefinovaných odběrových diagramů pro jednotlivé zdroje obsahující minimálně: o Informace o dodavateli a odběrateli; o Informace o odběrném místě; o Relevantní údaje o technickém zařízení; o Přehled o sjednaném teplu po jednotlivých měsících; o Roční množství sjednaného tepla.



Kalkulace standardních ukazatelů plnění plánu výroby tepla, minimálně v rozsahu: o Kalkulace množství vyrobeného tepla podle jednotlivých zdrojů a srovnání s nasmlouvaným množstvím; o Kalkulace jednotlivých nákladových položek na výrobu tepla a srovnání s plánem; o Kalkulace celkového množství tepla vyrobeného Objednatelem a srovnání s plánem; o Srovnání všech relevantních nákladů na výrobu tepla s plánem.



Kalkulace standardních ukazatelů čerpání finančních prostředků v průběhu finančního roku;



Kalkulace jednotkových cen tepla, členěných podle jednotlivých lokalit;



Kalkulace nákladů na vodné a stočné;



Kalkulace celkových částek za vyrobené teplo;



Kalkulace cla u komodit určených k vykazování celnímu úřadu;



Kalkulace spotřební daně u jednotlivých komodit;



Kalkulace dohadných položek z odebraného množství komodity a platné ceníkové ceny z ceníku a postupné snižování těchto položek vedených pod číslem zakázky podle schválených faktur;



Rozpouštění souhrnně vyjádřených nákladů na předem definované klienty podle předem definovaného vzorce s možností tento vzorec upravovat;



Automatické vypočítání celkového výkonu zařízení na základě výkonu jednotlivých kotlů.

4.2 Plánování a modelování IS umožní následující operace související s modelováním a vytvářením plánů: 

Modelování budoucí spotřeby paliv a souvisejícího ekonomického vývoje při změně vstupních ekonomických a technických parametrů;



Odhad budoucí potřeby paliv dle odběrových diagramů;



Plánování spotřeby paliv na finanční rok a vyhodnocení plánu k aktuálnímu datu; 7



Plánování výroby tepla na finanční rok a vyhodnocení plánu k aktuálnímu datu;



Plánování režijních nákladů na finanční rok a vyhodnocení plánu k aktuálnímu datu;



Vytvoření plánu provozních nákladů na jednotlivá odběrná místa a rozdělení režií (podle předem stanoveného klíče na začátku účetního období);



Identifikace priorit a cílů ve zvyšování energetické účinnosti (např. budou identifikovány budovy s významným potenciálem ke snížení spotřeby energie);



Vytváření plánu oprav, včetně jejich ocenění na základě jednotkových cen;



Automatické ukládání změněných hodnot pasportních údajů do historie včetně časových razítek.

4.3 Monitorování IS umožní následující operace související s monitorováním: 

Stálé sledování skutečné výroby a dodávek tepelné energie oproti plánovaným hodnotám;



Automatické sledování termínů pro zajištění periodických činností a odesílání interních systémových upozornění a e-mailových avíz správcům objektů;



Automatické nastavení budoucích termínů provedení periodických činností dle zadaného klíče;



Hromadné i individuální potvrzování provedených periodických činností, s provedením automatického zápisu do provozní knihy;



Kontrola správnosti fakturovaných spotřeb;



Kontrola fakturovaných položek za spotřebu energií importovaných z ekonomického informačního systému s údaji o spotřebě a plánovaných hodnotách v IS;



Kontrola spotřeby adresných měření provedených dodavatelem energie vůči spotřebě zjištěné vlastním kontrolním měřením;



Eskalace poruchových stavů či nedodržených termínů dle eskalačního procesu;



Sledování záruční doby technických zařízení;



Schopnost v každém okamžiku zjistit stav průběhu vyřizování jednotlivých činností;



Možnost sledování vývoje hodnoty pasportního údaje;



Možnost monitoringu vyřizování nastavených činností se záznamy historie skutečného průběhu procesu pro účely vyhodnocování;

4.4 Uživatelská nastavení IS umožní standardní uživatelská nastavení minimálně v následujícím rozsahu: 

IS musí umožnit nastavení pravidel náležitosti pasportních údajů k typům technických zařízení (např. jiná množina pasportních údajů ke kotli, jiná množina k výměníkové stanici);



IS umožní přidání či odebrání datové položky pasportních údajů;



IS musí umožnit přizpůsobení vzhledu uživatelského rozhraní, minimálně v rozsahu: o Nastavení viditelnosti sloupců ve formulářích; o Pořadí sloupců a řádků ve formulářích; 8

o Nastavení a pojmenování uložených výběrových a třídících kritérií nad daty formuláře; 

IS musí koncovým uživatelům s více uživatelskými rolemi umožnit jednoduché přepínání mezi jednotlivými rolemi v průběhu práce se systémem.

4.5 Uživatelská oprávnění a správa přístupů IS umožní řízení uživatelských oprávnění a správu přístupů v následujícím rozsahu: 

IS musí umožnit správu uživatelských rolí;



IS musí umožnit správu individuálních uživatelských profilů;



IS musí umožnit snadnou správu přístupových práv uživatelů založenou na členění uživatelů dle jejich rolí v IS, přidělování přístupových práv v rámci rolí a datových kompetencí s možnostmi nastavení různých úrovní přístupu přes vykonávanou funkci nebo organizační strukturu;



IS musí umožnit uživateli časově omezit přístup k IS, dočasně odebrat roli při zachování všech nastavení;



IS musí mít možnost přiřadit jednotlivým činnostem uživatelské role, aby definice nemusela být měněna vždy se změnou pracovníka. V.

TECHNICKÉ POŽADAVKY NA IS

IS musí naplňovat následující požadavky na technické řešení a kompatibilitu s cílovým prostředím: 

Řešení musí umožňovat Single sign on (SSO) přihlášení s využitím autentizačních údajů operačního systému;



Systém musí podporovat ověřování uživatelů za pomoci stávající adresářové služby MS Active Directory;



IS bude internetovou aplikací, přístup uživatelů i správců IS bude možné realizovat on-line z jakékoliv pracovní stanice připojené k síti Internet za předpokladu, že bude pracovní stanice vybavena následujícími SW prostředky: o Webový prohlížeč Internet Explorer ve verzi 9 a vyšší.



IS bude navržen a realizován tak, aby umožnil snadné změny standardních i uživatelských sestav, pravidelných reportů a povinných výkazů při relevantní změně požadavků legislativy či zákazníka Objednatele;



IS musí být řešen prostřednictvím třívrstvé architektury (prezentační vrstva, aplikační (business) vrstva, datová vrstva);



IS bude naimplementován ve třech oddělených prostředích: o provozní prostředí – prostředí pro běžné užívání IS s ostrými daty; o testovací prostředí – prostředí pro otestování všech provedených změn v IS před jejich nasazením v provozním prostředí. Toto prostředí bude rovněž sloužit pro modelování situací, které budou vyžadovat zásadní přenastavení klíčových parametrů spravovaných dat. IS proto musí umožnit tzv.

9

„občerstvení testovacího prostředí“ spočívající v migraci aktuálních ostrých dat z provozního prostředí do testovacího. o vývojové prostředí – prostředí, ve kterém vyvíjí a rozvíjí IS jeho Zhotovitel. 

Systém musí umožnit bezpečnou komunikaci mezi klientskou stranou a serverem pomocí protokolu HTTPS či jiným obdobným způsobem;



Objednatel v současnosti disponuje příslušnými licencemi pro užití databázové platformy MS SQL 2008 R2 resp. Oracle 9i Standard Edition I (pro max 2 CPU), na které je v současnosti a nadále bude provozován ekonomický informační systém ABRA. V případě, že bude nutné pro běh systému stávající licenční oprávnění Objednatele k databázovým platformám doplnit či rozšířit, začlení tuto aktivitu Zhotovitel do své nabídky a veškeré s tím spojené náklady zahrne do nabídkové ceny;



Serverová část nabízeného řešení musí být spustitelná a schopná provozu na platformě Windows Server 2008R2x64, serverová část nabízeného řešení musí být spustitelná a schopná provozu ve virtuálním prostředí (VMWARE, HYPER-V);



IS bude komunikovat s uživateli výhradně v českém jazyce;



Požadavky na sizing: o

Požadavky na sizing jsou uvedeny ve vazbě na potřeby IS pro provozní prostředí. Pro výsledný sizing daného prvku je třeba zahrnout i požadavky ostatních programů či ostatních IS (OS, Office, atd.), které jsou na daném prvku provozovány:

(1

Prvek

Výkon

RAM

WWW klient

1 x PIV a vyšší

256 MB

Sdílená Disková Síťové disková kapacita rozhraní kapacita

Rozlišení

10 MB

0 MB

1 Mbps 1024x768, High Color

Aplikační a integrační služby

Intel / AMD 2-4 jádra max. 8 GB 2 – 3 GHz

50 GB

-

1 Gbps 1024x768, High Color

Databázové služby

Intel / AMD 2-4 jádra max. 8 GB 2 – 3 GHz

50 GB

150 GB(1

1 Gbps 1024x768, High Color

Pro uložení záloh databáze

VI.

BEZPEČNOSTNÍ POŽADAVKY NA IS

IS musí naplňovat následující bezpečnostní požadavky:  Registrace všech uživatelů v IS probíhá centrálně, kde jsou stanovena pravidla pro procesy registrace, schvalování, generování identit, přidělování přístupů, odebírání přístupů, deaktivace identit a monitorování činnosti uživatelů; 

IS umožní logování prováděných činností v IS a související změny dat; 10



IS musí umožnit logování ve vztahu k uživateli, který logovanou událost provedl;



IS musí umožnit přístup k funkcím a datům pouze oprávněným uživatelům;



IS bude koncipován s funkcionalitou replikace dat do záložního datového pracoviště;



V záložní lokalitě budou kromě provozních dat dále uloženy backupy všech případných podpůrných aplikací tak, aby v případě úplné ztráty primární lokality bylo možno celý systém zrekonstruovat v nově vytvořené lokalitě v co nejkratším čase; Toto se týká jak provozní instance IS, tak testovacího / školícího prostředí;



Replikace dat do záložní lokality musí maximálně využít dostupné technologie z pohledu zabezpečení dat proti poškození nebo zneužití a dále technologie minimalizující datové přenosy. VII.

KOMUNIKACE S EKONOMICKÝM INFORMAČNÍM SYSTÉMEM ABRA

Součástí řešení bude dodávka integračních vazeb mezi dodávaným IS a ekonomickým informačním systémem ABRA provozovaným u Objednatele. Pro přehlednost jsou požadavky na integrační vazby s ekonomickým informačním systémem ABRA členěny do následujících kategorií: 

Transfer dat z ekonomického informačního systému ABRA do IS;



Transfer dat z IS do ekonomického informačního systému ABRA.

7.1 Transfer dat z ekonomického informačního systému ABRA do IS IS bude přijímat z ekonomického informačního systému ABRA dále uvedená data a jejich typy. 

Požadavky na import dat: o Je vyžadováno, aby při přesunu dat z ekonomického informačního systému ABRA proběhla kontrola jejich správnosti a konzistence. Kontrola bude probíhat na těchto úrovních: • Kontrola vstupního datového typu (tj. nemožnost importu datového pole, které obsahuje data jiného než předepsaného typu, například v případě, že je datové pole typu integer, neumožní IS importovat data jiného typu); • Kontrola oproti historickým datům (kontrola odchylky od historického průměru a upozornění / dotaz na uživatele). o IS umožní využívat komunikačního rozhraní XML; o IS bude schopen přijímat data o jednotlivých zařízeních vycházející ze stávajícího systému čísel zakázek v ekonomickém informačním systému ABRA.



Řešení umožní přijímat z ekonomického informačního systému ABRA minimálně následující data: o Data z oblasti evidence majetku (například pořizovací cena majetku, aktuální hodnota majetku atp.);

11

o Data z oblasti provozních nákladů (například provozní náklady dle čísel zakázek, informace o revizích, ceny oprav atp.); o Data o fakturaci spotřeby evidovaných komodit (například číslo faktury, fakturovaná částka atp.) a odkaz na příslušnou fakturu; o Data z oblasti skladového hospodářství například (například název, počáteční množství a jednotkový náklad atp.); o Data z oblasti evidence majetku (pořizovací cena majetku, snížení hodnoty majetku nebo navýšení hodnoty majetku atp.). 7.2 Transfer dat z IS do ekonomického informačního systému ABRA IS bude poskytovat ekonomickému informačnímu systému ABRA dále uvedená data a jejich typy. 

Požadavky na transfer dat: o IS umožní využívat komunikačního rozhraní XML.



Řešení umožní odesílat z IS do ekonomického informačního systému minimálně následující data: o Data z oblasti skladového hospodářství: • Údaje o spotřebovaném množství komodity (ABRA bude dopočítávat změnu stavu zásob); • Kalkulace a evidence spotřební daně u LTO. o Podklady pro odvody DPH; o Podklady pro vyúčtování poskytnutého plnění v členění dle jednotlivých zakázek; o Dohadné položky: • Výše dohadné položky – náklady; • Výše dohadné položky – výnosy. VIII.

KOMUNIKACE S IS DODAVATELŮ ENERGIE

Systém bude navržen tak, aby v budoucnu umožňoval import standardních dat z IS dodavatelů energie a komodit (tepelná energie, zemní plyn, elektrická energie), minimálně v následujícím rozsahu: 

Cena energií a komodit. IX.

WORKFLOW

Řešení umožní nastavení standardního workflow, minimálně v následujícím rozsahu: 

Automatické sledování termínů periodických činností (revize, měření, kontrola…) a plánovaných oprav a odesílání upozornění relevantním osobám pomocí emailu nebo SMS na blížící se či prošlý termín;



Upozorňování, pomocí emailu nebo SMS, vybraných účastníků procesu o jejich aktuálních úkolech;

12



Automatické zasílání reportů na nastavené skupiny uživatelů;



Eskalace nedodržení termínů dle eskalačního postupu;



Automatické zasílání výkazů jejich příjemcům emailem;



Možnost definování a aktivování emailové notifikace a upozornění v průběhu procesu s možností připojit k emailu uživatelské sestavy nebo dokumenty;



IS bude koncipován tak, aby v budoucnu umožnil propojení se stávajícími systémy SMS výstrahy o havarijních stavech a umožnil SMS odečty z měřících zařízení. X.

POŽADAVKY NA DOKUMENTACI

Součástí dodávky IS bude standardní dokumentace, minimálně v následujícím rozsahu: 

Bezpečnostní dokumentace obsahující: o Pravidla a principy administrace přístupových oprávnění a datových kompetencí.



Systémová dokumentace obsahující: o Globální architekturu celého IS; o Dílčí architekturu jednotlivých částí/služeb v rozsahu schéma, popis, specifikace prvků, specifické informace, atd.; o Integrační vazby na okolí.



Administrátorská dokumentace obsahující: o Zálohovací plán, o Havarijní plán a plán kontinuity služeb, o Administrační procesy.



Uživatelskou dokumentaci obsahující: o o o o XI.

Kontextovou nápovědu při práci v grafickém rozhraní; Kontextově řešený systém chybových hlášek; Online uživatelskou příručku v aktuální verzi; Systém helpů. PŘIPRAVENOST ŘEŠENÍ PRO BUDOUCÍ ROZŠÍŘENÍ FUNKCIONALIT IS

IS bude koncipován tak, aby byl připraven na budoucí rozšíření (tj. umožnil dále uvedená rozšíření bez nutnosti zásadních zásahů do funkčnosti dodané na základě požadavků uvedených v této Smlouvě a jejích přílohách a tedy s minimálními náklady na úpravu dodaných modulů IS a jejich nové nastavení) minimálně v následujícím rozsahu: 

Měření vnější teploty: o Vzhledem k plánovanému měření vnějších teplot, je požadováno, aby IS umožňoval zadávat a následně zpracovávat data ohledně venkovních teplot a umožnil korekci a srovnání skutečnosti s plány s ohledem na změnu venkovní teploty;



Dálkový sběr odečtů z měřících zařízení: o Vzhledem k předpokladu výhledového osazení měřidly s automatickými odečty a dálkovým přenosem, je požadováno, aby IS v budoucnu umožňoval automatické zadávání dat z měření na bázi komunikačního protokolu M-BUS; 13

o IS v budoucnu umožní zajištění přímé komunikace měřidel s centrálním pracovištěm pro sběr naměřených spotřeb nebo komunikace měřidel prostřednictvím komunikačních modulů; o IS v budoucnu umožní využití bezdrátové komunikace Wi-fi nebo rádiové frekvence pro přenos mezi měřidly a komunikačními moduly; o IS v budoucnu umožní nastavení pravidelných libovolně krátkých intervalů přenosů spotřeby z měřidel; o IS

v budoucnu

umožní

odesílání

dat

o

naměřených

hodnotách

prostřednictvím sítě GSM/GPRS nebo TCP/IP protokolů po pevné síti z komunikačního modulu softwarovému vybavení, které zajistí ukládání naměřených hodnot do IS. o IS v budoucnu umožní provádění správy odběrných míst, komunikačních modulů, měřičů instalovaných na odběrných místech.

14

Příloha č. 2: Věcný popis návrhu řešení předmětu Smlouvy

Formulář věcného popisu návrhu řešení předmětu Veřejné zakázky I.

POŽADAVKY NA KVALITU PLNĚNÍ

Zhotovitel se zavazuje poskytnout Plnění dle článku 3.1 Smlouvy v kvalitě, jejíž úroveň je detailně specifikována v následující tabulce, resp. za podmínek v následující tabulce uvedených.

1. NAVRŽENÝ ZPŮSOB PLNĚNÍ PŘEDMĚTU VEŘEJNÉ ZAKÁZKY Zhotovitel se zavazuje provádět procesy projektového řízení realizace Veřejné zakázky dle metodiky, plně v souladu s popisem její implementace a užití a při dodržení organizačního a kompetenčního uspořádání, které jsou uvedené v této tabulce v bodě 1.a) Metodika projektového řízení a organizace projektu. Zhotovitel se dále zavazuje při realizaci Veřejné zakázky řídit rizika a aplikovat opatření na jejich eliminaci či snížení jejich dopadů v rozsahu a způsobem, které jsou uvedené v této tabulce v bodě 1.b) Klíčová rizika plnění Veřejné zakázky a konkrétní návrh na jejich eliminaci či snížení jejich dopadů.

1.a Metodika projektového řízení a organizace projektu Použitá metodika projektového řízení Uchazeč bude při řízení realizace této Veřejné zakázky ve všech jejích fázích využívat metodiku PRINCE2. Uchazeč považuje tuto metodiku za nejvíce odpovídající konkrétním podmínkám a potřebám této veřejné zakázky, jelikož metodika PRINCE2 zahrnuje mj. osvědčené postupy z praxe, požaduje definované uspořádání odpovědností a pravomocí, je orientovaná na výsledek a je aplikovatelná na jakýkoli typ projektu. Východisky pro volbu této metodiky byly zejména poměrná složitost implementační struktury Zadavatele, velký rozsah a komplexnost předmětu plnění a omezený a konečný čas pro realizaci projektu požadovaný Zadavatelem. Procesy zvolené metodiky implementované Uchazečem Metodologie PRINCE2 definuje 7 procesů popisujících časový sled realizovaných aktivit projektu (Zahájení projektu, Směrování projektu, Nastavení projektu, Řízení etapy, Řízení dodávky produktu, Řízení přechodu mezi etapami a Ukončení projektu). Metodika připouští možnost upravit procesy a přizpůsobit je potřebám projektu. Pro zajištění co nejhladšího průběhu realizace Veřejné zakázky a zavedení co nejúčinnějších mechanismů kontrol a

1

opatření k naplnění jejího předmětu ve stanoveném časovém, věcném a finančním rámci budou aplikovány následující procesy: 

Zahájení projektu;



Nastavení projektu;



Řízení etapy a dodávky produktu;



Řízení přechodu mezi etapami;



Ukončení projektu.

Proces Zahájení projektu Jedná se o inicializační proces projektu, který proběhl před zveřejněním Zadávací dokumentace na Implementaci informačního systému na technologické hospodářství a energetický management. Zahájení projektu proběhlo interně na straně Zadavatele. Činnosti procesu Byl definován konkrétní záměr projektu, bylo ověřeno, že projekt má smysl a je proveditelný. Pravděpodobně byl navržen a jmenován Sponzor projektu a Projektový vedoucí Zadavatele. Výstupní produkty Výstupem tohoto procesu bylo zveřejnění rozsahu předmětu plnění - Zadávací dokumentace veřejné zakázky. Proces Nastavení projektu V tomto procesu dochází k zahájení činnosti projektového týmu Uchazeče. Proces slouží k odpovídajícímu naplánování projektu (resp. jeho fáze či etapy). Je třeba definovat kontrolní mechanizmy zajišťující, že projekt bude postupovat v souladu s odsouhlasenými požadavky. Jsou realizovány aktivity podrobného plánování, vytvoření strategií a kontrolních mechanismů projektu. Bude zpřesněna součinnost a mechanismy řízení projektu mezi stranami Zadavatele a Dodavatele. Činnosti procesu  Zahájení komunikace zástupců Zadavatele se zástupci Uchazeče; 

Zpracování hlavních směrnic projektu (strategie řízení rizik, řízení kvality, řízení komunikace);



Plánování projektu;



Určení organizační struktury;



Určení a nastavení kontrolních mechanismů;



Sestavení dokumentace Nastavení projektu.

Výstupní produkty Vedoucí projektu Uchazeče implementací tohoto procesu zajistí vytvoření výstupního produktu: 

Dokumentace Nastavení projektu (PID);



Projektový plán. 2

Proces Řízení etapy a dodávky produktu V průběhu tohoto procesu Vedoucí projektu Uchazeče řídí a přiděluje (formou balíků práce) realizačním týmům práci, která se má v dané etapě provést (ve Fázi 1 provést analýzu a vytvořit návrh IS, ve Fázi 2 dodat a implementovat IS do prostředí Zadavatele), monitoruje tuto práci, řeší otevřené body (problémy), podává zprávy o postupu projektu Projektovému výboru a provádí nápravná opatření. Ke konci každé etapy projektu projektový vedoucí Uchazeče dodá výstupní produkty etapy k akceptaci a poskytne Řídícímu výboru projektu informace potřebné pro vyhodnocení realizované části projektu a přijetí rozhodnutí o autorizaci další etapy. Činnosti procesu 

Zajišťování, aby práce definované v rámci realizace výstupních produktů jednotlivých fází etap byly přidělovány včas Realizačním týmům;



Zajištění, aby Vedoucí Realizačních projektových týmů jasně rozuměli, co má být vytvořené a jaké je očekávané úsilí, náklady a čas;



Zajištění dodávky požadovaných výstupních produktů v souladu s očekáváními;



Zajištění, aby Projektoví vedoucí dostali v dohodnutých intervalech přesné informace o postupu pro kontrolu, že nastavená očekávání jsou řízena.

Výstupní produkty Pro etapu Analýza a komplexní návrh IS: 

Dokument Analýza a komplexní návrh IS obsahující návrh funkcionality řešených procesů, návrh dat, jejich obsahu a přístupu k datům dle specifikovaných rolí, stanovení rozsahu migrace a návrh integračních vazeb na IS ABRA.

Pro etapu Dodávka a implementace IS: 

IS implementovaný do prostředí Zadavatele dle akceptované Analýzy a komplexního návrhu IS;



Bezpečnostní dokumentace obsahující pravidla a principy administrace přístupových oprávnění a datových kompetencí;



Systémová dokumentace obsahující globální architekturu celého IS, dílčí architekturu jednotlivých částí/služeb, Integrační vazby na okolí;



Administrátorská dokumentace obsahující Zálohovací plán, Havarijní plán a plán kontinuity služeb, Administrační procesy;



Uživatelskou dokumentaci obsahující kontextovou nápovědu při práci v grafickém rozhraní, Kontextově řešený systém chybových hlášek, Online uživatelskou příručku v aktuální verzi, Systém helpů;



Akceptační kritéria dodávky;



Testovací scénáře prováděné Zadavatelem.

3

Proces Řízení přechodu mezi etapami Tento proces vytváří potřebné informace tak, aby Řídící výbor projektu mohl posuzovat úspěšnost probíhající etapy, schvalovat následující etapu a posuzovat aktualizovaný Projektový plán. Činnosti procesu 

Dokončení stávající Etapy;



Plánování následující Etapy;



Aktualizace Projektového plánu;



Zpracování zprávy pro Řídící výbor projektu;



Schválení další etapy.

Výstupní produkty Projektový vedoucí Uchazeče v rámci kontroly a monitorování postupu projektu udržuje soubor interních záznamů projektu: 

Zpráva o ukončení etapy;



Schválená etapa – souhlas pokračovat;



Aktualizovaný Projektový plán;



Aktualizovaný Dokument Nastavení projektu (PID).

Proces Ukončení projektu Během tohoto procesu dojde k řízenému uzavření projektu. Dojde k posouzení, zda všechny cíle projektu byly splněny, zda byly dodány a akceptovány všechny produkty. Je uspořádána a archivována Projektová dokumentace, jsou stanoveny následné akce a jsou uvolněny zdroje přidělené na projekt. Činnosti procesu V rámci tohoto procesu budou realizovány tyto činnosti: 

Uzavření plánu projektu a jeho vyhodnocení;



Přezkoumání splnění cílů projektu;



Identifikace zbylých otevřených problémů;



Získání finální akceptace projektu;



Uzavření finančních procedur;



Archivace projektové dokumentace.

Výstupní produkty 

Archivovaný projekt;



Zpráva o ukončení projektu.

Organizační struktura projektového týmu na straně Uchazeče i Zadavatele Základními jednotkami organizační struktury projektu jsou:  Řídící výbor projektu; 

Tým vedení projektu;



Realizační týmy. 4

Řídící výbor projektu Kompetence Řídícího výboru projektu Řídící výbor projektu odpovídá za úspěch projektu a má oprávnění řídit projekt v rámci pravomoci určené vedením společnosti. Rozhoduje o základních aspektech projektu na strategické úrovni, stanovuje jeho priority, akceptuje klíčové výstupní produkty projektu a řeší problémy zásadního charakteru vzniklé v průběhu projektu, jejichž řešení přesahuje kompetence vedení projektu. Řídící výbor projektu schvaluje změny smluvních ustanovení, především schvaluje změny v projektu, které mají dopad na časový (dílčí fáze etapy), finanční anebo věcný rozsah plnění dle smlouvy. Přijímá opatření a definuje další postup v případě krizových stavů projektu. Řídící výbor se schází v pravidelných intervalech dle stanoveného harmonogramu nebo mimořádně dle potřeby v případě eskalace na vyžádání Týmu vedení projektu. Podklady pro řídící výbor připravují společně Projektový vedoucí Zadavatele a Projektový vedoucí Uchazeče. Z každého jednání řídícího výboru je pořízen zápis s vyhodnocením stavu prací, se závěry a případně i úkoly; zápisy pořizuje zvolený zástupce Zadavatele. Aktivity Řídícího výboru projektu Řídící výbor v rámci projektových aktivit bude vykonávat zejména následující činnosti: Během přípravy a nastavení: 

Autorizovat nastavení projektu;



Určovat hlavní priority projektu.

V době trvání projektu: 

Schvalovat rozsah a harmonogram projektu na vrcholové úrovni;



Verifikovat organizační strukturu projektu a v případě potřeby navrhovat změny;



Řídit klíčové změny projektu mající vliv na stanovené zdroje, harmonogram a věcné plnění;



Sledovat postup projektu na vrcholové úrovni (plnění ke klíčovým milníkům projektu);



Řešit problémy eskalované z úrovně Týmu vedení projektu;



Kontrolovat řízení významných rizik projektu. Zabezpečovat, aby rizika byla sledována a řízena co nejefektivněji;



Schvalovat změny;



Schvalovat dokončené produkty.

Na konci projektu: 

Potvrzovat akceptaci výstupních produktů projektu;



Schvalovat závěrečnou zprávu projektu a potvrzovat, že všechny problémy, úkoly a rizika byly dokumentovány a postoupeny k řešení;



Autorizovat ukončení projektu.

5

Tabulka 1 – Členové řídícího výboru projektu

Role v projektu

Obsazení

Účast

Ředitel projektu Uchazeče

Uchazeč

Pravidelná

Projektový vedoucí Uchazeče

Uchazeč

Pravidelná

Projektový vedoucí Zadavatele

Zadavatel

Pravidelná

Vrcholoví zástupce Zadavatele např. Sponzor projektu

Zadavatel

Na pozvání

Tým vedení projektu Kompetence Týmu vedení projektu Tým vedení projektu je hlavní platformou pro řídící činnosti v rámci projektu. Zodpovídá za úspěch projektu a má oprávnění řídit projekt v rámci pravomocí určených Řídícím výborem projektu. Je odpovědný za dosažení cílů projektu realizací předmětu smlouvy a za řízení projektu. Disponuje pro projekt přidělenými zdroji, ze kterých ustavuje Realizační týmy odpovědné v průběhu projektu za realizaci výstupních produktů jednotlivých fází etap ve svěřené oblasti. Vedení projektu zajišťuje vazbu mezi Řídícím výborem projektu a Realizačními týmy. Odpovídá za průběžnou informovanost Řídícího výboru projektu o stavu projektu a o vzniklých problémech, které by mohly ohrozit termíny nebo rozpočet projektu. Tým vedení projektu se schází v pravidelných intervalech dle stanoveného harmonogramu ke kontrolám a projednávání dalšího postupu a součinnosti. Kompetence Projektového vedoucího Uchazeče 

Taktické řízení projektu ze strany Uchazeče;



Sestavování Realizačních týmů Uchazeče;



Definování cílů a sestavování plánu prací projektového týmu, koordinování členů projektového týmu a přidělování úkolů (balíků práce);



Zajišťování administrativy (pozvánky, zápisy, distribuce podkladů,…) kontrolování a vyhodnocování plnění činností projektového týmu, koordinování aktivit s ostatními projektovými týmy, provádění analýzy rizik;



Zajistit řízení, aby projekt produkoval požadované výstupní produkty se stanovenými tolerancemi času, nákladů, kvality, rozsahu, rizika a přínosů.

Zástupce Projektového vedoucího Uchazeče je organizačně podřízen Projektovému vedoucímu Uchazeče a rozsah náplně jeho činnosti je analogický k Projektovému vedoucímu Uchazeče. Tato role je zřízena k zajištění zastupitelnosti Projektového vedoucího Uchazeče, případně pro možnost delegování určitých pravomocí Projektového vedoucího Uchazeče na tohoto pověřeného zástupce. Aktivity Týmu vedení projektu Tým vedení projektu v rámci projektových aktivit bude vykonávat zejména následující činnosti: 

Definovat standardy projektu;



Sestavovat a průběžně aktualizovat plnění harmonogramu projektu; 6



Stanovovat Realizační týmy a jejich personální obsazení;



Zadávat a koordinovat práce Realizačních týmů;



Sledovat postup prací, kontrolovat dosažené výsledky, zejména plnění cílů, kvality, harmonogramu a rozpočtu projektu na operativní úrovni a řízení rizik projektu;



Kontrolovat vedení projektové dokumentace;



Kontrolovat dodržování dohodnuté metodologie a standardů;



Evidovat otevřené otázky a problémy vzniklé v průběhu projektu a jejich řešení;



Připravovat podklady pro jednání Řídícího výboru projektu;



Eskalovat problémy přesahující kompetence Týmu vedení projektu na úroveň Řídícího výboru projektu;



Řešit eskalované požadavky z úrovně Realizačního týmu.

Tabulka 2 - Členové Týmu vedení projektu

Role v projektu

Obsazení

Účast

Projektový vedoucí Zadavatele

Zadavatel

Pravidelná

Projektový vedoucí Uchazeče

Uchazeč

Pravidelná

Zástupce projektového vedoucího Uchazeče

Uchazeč

Pravidelná

Zástupce projektového vedoucího Zadavatele

Zadavatel

Pravidelná

Hlavní architekt Uchazeče

Uchazeč

Na pozvání

Realizační týmy Kompetence realizačních týmů Realizační týmy budou zajišťovat provádění činností, vedoucích ke splnění definovaných požadavků projektu. Realizační týmy budou řízeny/koordinovány týmem vedení projektu. Kompetence Vedoucího Realizačních týmů Uchazeče 

Zajištění výroby/tvorby výstupních produktů definovaných z úrovně Projektového vedoucího Uchazeče, a to v odpovídající kvalitě, čase a s náklady akceptovatelnými ze strany Týmu vedení projektu.

Kompetence členů Realizačních týmů Uchazeče 

Realizaci vlastní činnosti, výrobu/tvorbu výstupních produktů příslušného Realizačního týmu;



Provádějí realizaci balíčků práce, a to v odpovídající kvalitě, v odpovídajícím čase a s náklady akceptovatelnými ze strany Týmu vedení projektu;



Práce jsou prováděny dle odsouhlaseného plánu Realizačního týmu Uchazeče z úrovně Vedoucího realizačního týmu Uchazeče a nadřízené úrovně Projektového vedoucího Uchazeče.

Aktivity Realizačních týmů Realizační týmy v rámci projektových aktivit budou vykonávat zejména následující: 

Naplňovat cíle a priority projektu v dané definované oblasti; 7



Řešit úkoly stanovené příslušným Vedoucím pracovní skupiny;



Spolupracovat s ostatními Realizačními týmy;



Zpracovávat výstupy projektu ve své oblasti ve stanoveném termínu a kvalitě;



Předávat pravidelné zprávy o postupu realizace své oblasti a zpracovávat doporučení týmu vedení projektu;



Analyzovat rizika projektu ve své oblasti a navrhovat opatření k jejich minimalizaci;



Eskalovat problémy přesahujících kompetence vedoucího Realizačního týmu na úroveň Týmu vedení projektu;



Vytvářet projektovou dokumentaci k náplni skupin;



Vytvářet akceptační dokumentaci;



Vytvářet školící dokumentaci.

Složení Realizačních týmů Realizační tým je dočasná struktura projektu s jasně přiděleným rozsahem časového působení, stanoveným rozsahem úkolů nebo řešením vymezené věcné oblasti. Složení pracovních Realizačních týmů se může v různých fázích projektu dle potřeby obměňovat. O změně složení pracovního Realizačního týmu rozhoduje zpravidla Tým vedení projektu. Členové Realizačních týmů Uchazeče jsou takoví spolupracovníci, kteří budou mít patřičné kompetence, dovednosti a znalosti, budou používat náležité techniky a budou se podílet svým dílem na plnění činností přidělených týmu. Předpokládané časové vytížení jednotlivých pozic v organizační struktuře V přiložené tabulce jsou uvedeny předpokládané nároky na časové vytížení jednotlivých pozic v organizační struktuře Zadavatele (v člověkodnech – MD) v rámci organizační struktury projektu pro realizaci Fází 1 a 2. Tabulka 3 – Předpokládané časové vytížení jednotlivých pozic v organizační struktuře projektu Zadavatele

Role v projektu

Kapacitní nároky

Vrcholový zástupce Zadavatele

3 MD

Projektový vedoucí Zadavatele

20 MD

Zástupce projektového vedoucího Zadavatele

15 MD

Realizační tým Zadavatele

50 MD

8

1.b Klíčová rizika plnění veřejné zakázky a konkrétní návrh na jejich eliminaci či snížení jejich dopadů V následující tabulce je uveden požadovaný výčet rizik souvisejících s realizací Veřejné zakázky, která z pohledu Uchazeče ohrožují naplnění předmětu Veřejné zakázky. Rizika jsou uvedena podle oblastí stanovených v zadávací dokumentaci. V prvních dvou sloupcích tabulky jsou uvedena očekávaná rizika včetně dopadu jejich materializace. Ke každému riziku je ve třetím sloupci navržen způsob eliminace či snížení jeho dopadu. V posledním sloupci jsou ke každému riziku identifikovány vazby na rizika související s dopadem jeho materializace a rizika, která mohou vzniknout v souvislosti s realizací opatření souvisejících s eliminací rizika. Tabulka 4 – Klíčová rizika plnění veřejné zakázky a konkrétní návrh na jejich eliminaci či snížení jejich dopadů

Riziko

Dopad materializace rizika

Způsob eliminace či snížení jeho dopadu

Vazba na ostatní rizika

Přesně definovat požadované přínosy předmětu veřejné zakázky v úvodní fázi projektu. Zaměřit plnění veřejné zakázky na přínosy podporující strategické cíle Zadavatele, místo na jednotlivé splnění dílčích požadavků

a) Následkem dopadu materializace: 3.1. Překročení nákladů projektu; b) Následkem způsobu eliminace: Vazba nebyla identifikována

Zadavatel provede seznámení uživatelů se strategickými cíli předmětu veřejné zakázky, s důvody změny a bude využívat vhodné přímé a nepřímé manažerské nástroje k ovlivňování uživatelů

a) Následkem dopadu materializace: 5.3. Narušení provozu organizace modifikací dat vlivem nezkušenosti či nedostatečné odpovědnosti administrátorů nebo uživatelů; b) Následkem způsobu eliminace: Vazba nebyla identifikována

1. Rizika ohrožující naplnění účelu Veřejné zakázky

1.1. Nedosažení strategických cílů Veřejné zakázky

1.2. Vysoká míra změn v dosavadní práci uživatelů Zadavatele zavedením nového systému

Odklon od zásadních cílů veřejné zakázky. Modifikace účelu a ztráta klíčových funkcí systému oproti zadání

Neochota zapojit se do používání systému, destruktivní přístup, redukce používaných funkcí ze strany uživatelů

9

Riziko

Dopad materializace

Způsob eliminace či snížení jeho dopadu

Vazba na ostatní rizika

Náležité plánování postupu projektu, vhodná alokace zdrojů, integrované řízení projektu, pravidelná evaluace postupu prací, včasná eskalace problémů na nejvyšší úroveň řízení projektu

a) Následkem dopadu materializace: 3.1. Překročení nákladů projektu; 2.5. Nedostatečná časová a kapacitní disponibilita členů realizačního týmu Zadavatele; b) Následkem způsobu eliminace Vazba nebyla identifikována

Legislativní ošetření podmínek poskytování součinnosti třetích stran mezi Zadavatelem a zúčastněnými třetími stranami

a) Následkem dopadu materializace: 2.1. Nedodržení smluvních termínů; 3.1. Překročení nákladů projektu b) Následkem způsobu eliminace: Vazba nebyla identifikována

Přesná definice zdrojů pro migraci dat a zajištění sjednocení jejich struktury, jejich vyčištění a nezbytné úpravy na straně Zadavatele

a) Následkem dopadu materializace: 2.1. Nedodržení smluvních termínů; 2.4. Nepoměr mezi pracností implementace a krátkou dobou jejího trvání; b) Následkem způsobu

2. Rizika ohrožující včasné dodání díla

2.1. Nedodržení smluvních termínů

2.2. Nedostatečné poskytnutí nutné součinnosti třetích stran při realizaci integračních vazeb

2.3. Nedostatečné znalosti rozsahu a množství zdrojových dat uživatelů potřebných pro převod (migraci) do cílového prostředí, množství zdrojů dat s nejednotnou metodikou jejich

Prodloužení realizace celého díla s dopadem na prodloužení účasti členů realizačních týmů obou stran na projektu. Finanční ztráta. Ztráta dobrého jména Uchazeče

Narušení časového plánu realizace předmětu veřejné zakázky, omezení nebo úplné přerušení některých funkcí systému

Prodloužení termínů migrace dat, narušení časového plánu realizace předmětu veřejné zakázky, zpoždění zahájení ověřování některých funkcí systému

10

obsahu

Riziko

eliminace: 2.5. Nedostatečná časová a kapacitní disponibilita členů realizačního týmu Zadavatele a uživatelů IS; Dopad materializace

Způsob eliminace či snížení jeho dopadu

Vazba na ostatní rizika a) Následkem dopadu materializace: 2.5. Nedostatečná časová a kapacitní disponibilita členů realizačního týmu Zadavatele a uživatelů IS; b) Následkem způsobu eliminace: 4.2 Nedostatečný čas na zpracování oponentury členy realizačního týmu Zadavatele

2.4. Nepoměr mezi pracností implementace a krátkou dobou jejího trvání

Časový tlak na rychlost implementace realizačního týmu Uchazeče a nezbytnost rychlé reakce při poskytování nutné součinnosti členů realizačního týmu Zadavatele

Zkrácení akceptačního řízení první fáze, vhodná alokace zdrojů, pravidelná evaluace postupu prací, včasná eskalace problémů na vyšší úroveň řízení projektu

2.5. Nedostatečná časová a kapacitní disponibilita členů realizačního týmu Zadavatele a uživatelů IS.

Omezené poskytováni součinnosti realizačnímu týmu Uchazeče ze strany realizačního týmu Zadavatele. Zatížení uživatelů Zadavatele a nevůle spolupracovat. Dopad na kvalitu aplikování poznatků ze zaškolení, nesprávné užívání systému, nedostatečný čas pro ověření funkčnosti

Poskytnutí dostatečné časové kapacity členům realizačního týmu Zadavatele po celou dobu realizace projektu, poskytnutí dostatečné časové kapacity uživatelům po dobu předávání systému do provozu, stimulace uživatelů, jasné kompetence

11

a) Následkem dopadu materializace: 2.1. Nedodržení smluvních termínů; 4.2 Nedostatečný čas na zpracování oponentury členy realizačního týmu; b) Následkem způsobu eliminace: Vazba nebyla identifikována

Riziko

Způsob eliminace či snížení jeho dopadu

Dopad materializace

Vazba na ostatní rizika

3. Rizika ohrožující dodržení finančního rámce

3.1. Překročení nákladů projektu

3.2. Změny původního zadání

Nutnost vynaložení finančních prostředků nad rámec rozpočtu projektu s dopadem na ekonomickou efektivitu a prodloužení doby návratnosti vložených prostředků

Eliminace chyb v odhadování, zvýšení produktivity práce, eliminace změn

Odchylky od původního zadání mohou vyžadovat více práce na straně Uchazeče s dopadem na finanční rámec veřejné zakázky a termíny její realizace

Kvalitně zpracovaný výstup z první fáze plnění „Analýza a komplexní návrh IS“ s jasně vymezeným a akceptovaným rozsahem řešení. Do řešení zahrnout pouze takové změny, které zásadním způsobem napomáhají dosažení strategických cílů veřejné zakázky

a) Následkem dopadu materializace; Vazba nebyla identifikována b) Následkem způsobu eliminace: Vazba nebyla identifikována a) Následkem dopadu materializace: 2.1. Nedodržení smluvních termínů; 3.1. Překročení nákladů projektu; b) Následkem způsobu eliminace: 4.2. Nedostatečný čas na zpracování oponentury členy realizačního týmu Zadavatele

4. Rizika ohrožující naplnění požadavků Objednatele na Dílo, uvedených v příloze č. 1 Smlouvy Navržena funkcionalita systému, která zcela neodpovídá 4.1. Nedostatečně definované požadavky procesům zavedeným v Zadavatele organizaci. Dopad na naplnění účelu veřejné zakázky. 4.2. Nedostatečný

čas

na Nekvalitní

či

Zapojení klíčových uživatelů s dostatečnými odbornými znalostmi, kvalitně zpracovaný výstup z první fáze plnění „Analýza a komplexní návrh IS“

povrchní Předávání výstupů k oponentuře 12

a) Následkem dopadu materializace: 1.1. Nedosažení strategických cílů Veřejné zakázky; b) Následkem způsobu eliminace: Vazba nebyla identifikována a) Následkem dopadu

zpracování oponentury posouzení výstupů členy realizačního týmu předložených Uchazečem Zadavatele k oponentuře či akceptaci Zadavateli s dopadem na další fáze projektu

s dostatečným předstihem. Navrhnout vhodnou formu prezentace návrhu IS za strany Zadavatele

materializace: 1.1. Nedosažení strategických cílů Veřejné zakázky; 4.1. Nedostatečně definované požadavky Zadavatele; b) Následkem způsobu eliminace: Vazba nebyla identifikována

Riziko

Dopad materializace

Způsob eliminace či snížení jeho dopadu

Zpracování testovacích scénářů a Snížení funkcionality a výkonu 4.3. Vnesené vady v SW, důsledné otestování IS interně u systému. Nutnost opakovaných nevalidní funkcionalita Zadavatele, důkladné akceptační zásahů do algoritmů za účelem IS na straně Uchazeče testování IS na straně uživatelů nápravy vnesených vad Zadavatele

Vazba na ostatní rizika a) Následkem dopadu materializace: 3.1. Překročení nákladů projektu; b) Následkem způsobu eliminace: Vazba nebyla identifikována

5. Rizika ohrožující poskytování Služeb v parametrech vymezených přílohou č. 5 Smlouvy 5.1. Opožděná nebo nedostatečná reakce na incident ze strany pracovníků podpory Uchazeče

Prodloužení vyřešení incidentu. Nedodržení reakční lhůty ze strany Uchazeče. Dopad na průběh procesů u Zadavatele, finanční postih Uchazeče

Personální zajištění podpory první a druhé úrovně na straně Uchazeče v rozsahu a odpovídajícím uzavřeným SLA podmínkám

5.2. Vyšší zatížení systémových Prodloužení doby obsluhy Škálovatelnost výkonu systému. prostředků s dopadem systému s dopadem na Pravidelná optimalizace a údržba na vyšší odezvu efektivnost práce uživatelů systému systému

13

a) Následkem dopadu materializace; Vazba nebyla identifikována b) Následkem způsobu eliminace: Vazba nebyla identifikována a) Následkem dopadu materializace: Vazba nebyla identifikována; b) Následkem způsobu eliminace: Vazba nebyla identifikována

Riziko 5.3. Narušení provozu organizace modifikací dat vlivem nezkušenosti či nedostatečné odpovědnosti uživatelů nebo administrátorů

Dopad materializace

Způsob eliminace či snížení jeho dopadu

Snížení výkonu systému, narušení informací o provedených operací s dopadem na provoz organizace

Průběžné školení administrátorů, udělovat administrátorská oprávnění až po dosažení určité míry zkušeností. Dodržování instrukcí uvedených v předané dokumentaci Uchazeče

14

Vazba na ostatní rizika a) Následkem dopadu materializace: Vazba nebyla identifikována; b) Následkem způsobu eliminace: Vazba nebyla identifikována

2. UŽIVATELSKÉ VLASTNOSTI IS Zhotovitel se zavazuje dodat při realizaci Veřejné zakázky takové Dílo, které disponuje uživatelskými vlastnostmi a umožňuje reálné využití IS způsobem, které jsou uvedené v této tabulce v bodech 2.a), 2.b), 2.c) a 2.d). Nabízené řešení se vyznačuje jednotným a uživatelsky komfortním komunikačním rozhraním na bázi internetové aplikace, otevřené ve vztahu k změnám a s potenciálem dalšího vývoje. Řešení je jednoduše administrovatelné a flexibilní z hlediska splnění cílů organizace v poptávané oblasti. Nabízí široké možnosti přizpůsobení produktu specifickým požadavkům zákazníka a jeho uživatelům.

2.a Náročnost obsluhy řešení Modelový proces: Zavedení nové kotelny do evidence IS Součástí nabízeného řešení je modul Technologický pasport, který je určen pro centrální a aktuální evidenci vyhrazených a jiných technických zařízení a který poskytuje přesný přehled o rozsahu a skladbě technických zařízení organizace, zpřístupňuje komplexní informace o technických zařízeních na jednom místě a poskytuje rychlou dostupnost dokumentace vztahující se k bezpečnému používání technických zařízení a podporuje dokladování prováděných činností se zařízením. V následující tabulce je uveden seznam a pracnost úkonů, které je třeba provést pro komplexní zavedení nového zařízení (kotelny) do IS. Povinný je pouze Úkon č. 1, ostatní úkony jsou volitelné a nezáleží na pořadí jejich provedení. Tabulka 5 – Seznam a pracnost úkonů komplexního zavedení nového zařízení (kotelny)

Pořadí a název úkonu

Počet kliků

Povinný úkon 1. Zavedení základních informací o kotelně Volitelné úkony 2. Vyplnění jedné hodnoty parametru kotelny 3. Přiřazení jedné komponenty ke kotelně 4. Připojení jednoho dokumentu

Počet zadaných polí

Odhad trvání

2

cca 10-15

2 min

2

2

0,5 min

4 3

1 2

1 min 1 min

Dále uvádíme přesný popis sledu jednotlivých úkonů. Úkon1 – Zavedení základních informací o kotelně Základní evidenční údaje k objektům (kotelnám) a také k samotnému technickému vybavení a příslušenství kotelen se zadávají na formuláři Technologická zařízení (viz Obrázek 1) zpřístupněném uživatelům příslušné role v navigačním stromu aplikace. Mezi základní evidenční údaje patří např. identifikační údaje (kód-zakázka, název, inventární číslo, 15

umístění), organizační údaje (NS, správce zařízení), technické údaje (typ a údaje související s typem), provozní údaje (uvedení do provozu, záruka, servisní organizace), dokumentace atd. 

Otevřeme formulář Technologická zařízení z navigačního stromu aplikace;



Založíme nový záznam pomocí tlačítka



Vyplníme povinné údaje uvedené na formuláři (seznam povinných údajů lze

(„Nový“);

uživatelsky nastavit); 

Uložíme vytvořený záznam pomocí tlačítka

(„Uložit“).

Pozn.: Pokud budou kotelny zakládány s vybranými údaji z IS ABRA pomocí integrační vazby na majetek, využije uživatel stejný formulář k doplnění požadovaných údajů, které nejsou evidovány v IS ABRA. V tomto případě bude místo tlačítka „Nový“ používat tlačítko („Editovat“). Další postup je shodný.

Obrázek 1 – Editace základních údajů o technologických zařízeních

Úkon2 – Vyplnění jedné hodnoty parametru kotelny K danému technickému zařízení je možné prostřednictvím parametrů zadat další údaje upřesňující jeho technologické vlastnosti. Parametry je možno definovat uživatelsky, přičemž ke každému typu kotelny je možno určit jinou množinu parametrů. 

Po uložení nové kotelny přejdeme na záložku Parametry;

16



Systém při uložení nového záznamu na pozadí na základě definovaných pravidel vygeneroval seznam parametrů kotelny v závislosti na jejím typu s prázdnými hodnotami;



Postupně doplníme všechny hodnoty parametrů podle skutečnosti. Nastavíme se na konkrétní záznam a tlačítkem

(„Editovat“) umístěným na liště nástrojů záložky

doplníme hodnotu parametru a datum její platnosti. Uložíme pomocí tlačítka („Uložit“) a přejdeme kurzorem na další záznam; 

Seznam vyplněných hodnot technických parametrů je uveden na dalším obrázku.

Obrázek 2 - Seznam vyplněných parametrů vybrané kotelny

Úkon3 – Přiřazení jedné komponenty ke kotelně Nabízené řešení dále umožňuje definovat komponenty (příslušenství) k technickým zařízením. Těmito komponentami mohou být např. jednotlivé kotle v dané kotelně. Komponenty ke kotelně jsou evidovány na formulářích technických zařízení na záložce komponenty (viz Obrázek 3). Jejich založení probíhá opět na formuláři Technických zařízení. 

Pro vybranou kotelnu otevřeme záložku Komponenty na formuláři Technologická zařízení,



Otevřeme formulář Přiřazení komponenty z lišty nástrojů záložky;



Založíme nový záznam přiřazení pomocí tlačítka

17

(„Nový“);



Vybereme požadovanou komponentu ze seznamu nepřiřazených komponent. Jako komponenty lze přiřadit pouze objekty, které mají atribut „Komponenta“ nastaven na hodnotu True;



Uložíme záznam pomocí tlačítka



Pokud chceme přiřadit další komponenty, pokračujeme stisknutím tlačítka

(„Uložit“);

(„Nový“); 

Přiřazená komponenta se objeví v seznamu přiřazených komponent na záložce.

Obrázek 3 - Seznam komponent vybrané kotelny

Úkon4 – Připojení jednoho dokumentu Na formuláři Technologická zařízení lze dále k záznamu konkrétní kotelny připojit veškeré relevantní dokumenty. 

Otevřeme formulář Připojené dokumenty z lišty nástrojů formuláře Technologická zařízení;



Založíme nový záznamu přiřazení pomocí tlačítka



Přiřadíme dokument k vybrané kotelně výběrem ze seznamu dokumentů. Pokud

(„Nový“);

požadovaný dokument není v seznamu, lze z formuláře vytvořit odkaz na přiřazovaný dokument a ten přiřadit ke kotelně; 

Uložíme záznam připojeného dokumentu pomocí tlačítka



Připojený dokument se objeví v seznamu připojených dokumentů kotelny;



Pokud chceme přiřadit další dokumenty, pokračujeme stisknutím tlačítka

(„Uložit“);

Na obrázku je zobrazen seznam přiřazených dokumentů ke kotelně.

18

(„Nový“).

Obrázek 4 – Připojené dokumentace ke kotelně

Modelový proces: Naplánování následující revize technických zařízení kotelny Správu procesů (např. revizí či prohlídek) pro technická zařízení a jejich skupiny zajišťuje v IS funkcionalita modulu Opakované činnosti. Modul Opakované činnosti podporuje efektivní plánování a sledování periodických činností a revizí, poskytuje možnosti dokladování provedených opakovaných činností a centrální úložiště pro revizní zprávy a výsledky kontrol. V následující tabulce je uvedena pracnost úkonu naplánování následující revize jednoho technického zařízení kotelny při zadání povinných údajů. 19

Tabulka 6 – Naplánování následující revize jednoho zařízení

Pořadí a název úkonu 1.

Počet kliků

Naplánování následující revize jednoho zařízení

Počet zadaných polí

2

Odhad trvání

6

1,5 min

Dále uvádíme přesný popis úkonu naplánování následující revize jednoho zařízení. Úkon1 - Naplánování následující revize jednoho zařízení 

Otevřeme záložku Opakované činnosti na formuláři Technologická zařízení;



Na záložce je zobrazen seznam předdefinovaných neaktivních a nenaplánovaných revizí, které předdefinoval systém v závislosti na typu zařízení při založení nového záznamu kotelny;



Poklepáním na vybraný záznam se otevře formulář Opakovaná činnost – detail pro doplnění plánu revize (viz Obrázek 5);



Vyplníme povinná pole a popř. další potřebné údaje. Některá pole jsou needitovatelná, jsou plněna automaticky systémem; o

Nastavíme časový cyklus provádění revizí pomocí výběru příslušné Intervalové jednotky a zadáním Počtu intervalových jednotek;

o

Vyplníme Datum příští realizace revize;

o

Nastavíme počet dní pro upozorňování na lhůty provedení revizí;

o

Nastavíme metodu výpočtu Data příští realizace, která bude systémem použita v okamžiku potvrzení o provedení opakované činnosti následovně: 

Má-li systém vypočítávat Datum příští realizace na základě data, které bylo naplánováno pro realizaci (tedy bez ohledu na skutečné datum revize), vybereme volbu Dle plánovaného data;



Má-li systém vypočítávat Datum příští realizace na základě data, kdy byla revize skutečně provedena, vybereme volbu Dle skutečného data.

o

Dále lze volitelně nastavit: 

Naplánování revize na konkrétní den v týdnu 1= pondělí,… , 7 = neděle;



Naplánování revize na konkrétní datum v měsíci (např. vždy pátého daného měsíce);



Počet dnů před plánovaným datem revize, kdy má systém správci zaslat upozornění na blížící se datum revize SMS nebo email.



Aktivujeme naplánovaný záznam vyplněním pole Aktivní;



Uložíme naplánovaný záznam pomocí tlačítka

(„Uložit“).

Po naplánování a aktivaci je revize zařazena do systému a systém bude automaticky hlídat lhůty této revize a předem upozorní správce na nutnost provedení revize. Po provedení revize uživatel na speciálním formuláři potvrdí datum provedení včetně možnosti zápisu nákladů, připojení revizní zprávy atd.). Systém potom automaticky nastaví datum příští revize podle zadaného intervalu a cyklus se opakuje. 20

Obrázek 5 – Formulář pro naplánování revize

Modelový proces: Pořízení standardních dat o odběru energií v členění dle odběrných míst v závislosti na druhu energie Tento modelový proces je součástí modulu Energetický management nabízeného řešení, který umožňuje komplexně řídit energetické hospodaření organizace. V následující tabulce je uvedena pracnost úkonu Pořízení standardních dat o odběru energie. Tabulka 7 - Pracnost úkonu pořízení standardních dat o odběru energie

Pořadí a název úkonu 1.

Pořízení standardních dat o odběru energie

Počet kliků 4

Počet zadaných polí 2

Odhad trvání 1 min

Dále uvádíme přesný popis úkonu pořízení standardních dat o odběru energie. Úkon1 - Pořízení standardních dat o odběru energie Na formuláři Přehled měřidel na odběrných místech vyhledáme měřidlo daného druhu energie. Pro vyhledané měřidlo otevřeme formulář Vlastní odečty na fakturačním měřidle (viz Obrázek 6);

21



Tlačítkem

(„Nový“) umístěném na liště nástrojů formuláře otevřeme nový záznam

pro doplnění odečtu. Systém předvyplní počáteční stav spotřeby z koncového stavu posledního odečtu a nastaví datum počátku odečtu z data posledního provedeného odečtu; 

Zadáme datum a čas odečtu a Koncový stav měřidla. Systém automaticky dopočítá spotřebu za období odečtu a celkovou spotřebu;



Pozn.: Systém umožňuje provádět odečty i na dvoutarifových měřidlech;



Uložíme doplněný záznam pomocí tlačítka

(„Uložit“).

Pozn.: Odečty na poměrových měřidlech lze také pořizovat bezkontaktním způsobem pomocí tzv. dálkových odečtů, kdy jsou měřidla napojena tzv. komunikačními moduly, které mohou automatizovaně přenášet naměřená data do aplikace.

Obrázek 6 - Zápis vlastních odečtů na fakturačním měřidle

Modelový proces: Tvorba a export výkazu dohadných položek Pro tvorbu dohadných položek budou připraveny reporty predikující výpočet dohadných položek. Výpočet dohadné položky bude možný dvojím způsobem: -

nahrazením: použitím dat za stejné období jiného roku;

-

výpočtem (predikcí) chybějících hodnot na základě algoritmu dopočtu, který bude specifikován v první fázi realizace – Analýza a komplexní návrh IS. 22

V následující tabulce je uvedena pracnost úkonu Tvorba a export výkazu dohadných položek. Tabulka 8 - Pracnost úkonu Tvorba a export výkazu dohadných položek

Pořadí a název úkonu 1.

Tvorba a export výkazu dohadných položek

Počet kliků 2

Počet zadaných polí 5

Odhad trvání 1 min

Dále uvádíme přesný popis úkonu Tvorba a export výkazu dohadných položek. Úkon1 - Postup tvorby a exportu výkazu dohadných položek 

Otevření dialogového okna reportu;



Zadání vstupních parametrů reportu (časové rozlišení, typ dohadné položky, způsob výpočtu, formát výstupu);



Spuštění reportu.

Modelový proces: Vytvoření nového uživatelského účtu a přiřazení uživatele do příslušné skupiny oprávnění Nabízené řešení obsahuje komplexní a propracovanou funkcionalitu pro provádění administrace přístupových práv uživatelů do systému, definování skupin uživatelů (Rolí) s totožnou nebo podobnou pracovní náplní a oprávnění skupin uživatelů přistupovat k povoleným datům prostřednictvím obrazovek, funkcí nebo sestav. V následující tabulce je uveden seznam a pracnost úkonů, které je třeba provést pro vytvoření nového uživatelského účtu a přiřazení uživatele do příslušné skupiny oprávnění. Tabulka 9- Seznam pracnosti úkonů pro vytvoření nového uživatelského účtu

Pořadí a název úkonu 1. 2. 3.

Vytvoření uživatelského účtu Přiřazení role uživateli Přiřazení kompetenčních okruhů uživateli v dané roli

Počet kliků 2 4 5

Počet zadaných polí 5 3

Odhad trvání 1 min 1 min

0

1 min

Dále uvádíme přesný popis sledu jednotlivých úkonů. Úkon1 - Vytvoření uživatelského účtu Pokud není osoba registrována a identifikována v nabízeném řešení jako Uživatel, nemá povolen přístup do aplikace. Proces registrování a identifikace zabezpečuje nezbytné úkony, díky nimž jsou budoucí uživatelé registrováni do systému a jsou jim přidělovány odpovídající pravomoci. Postup vytvoření nového uživatelského účtu 

Otevřeme formulář Uživatelé (viz Obrázek 7) z navigačního stromu aplikace; 23



Pomocí tlačítka

(„Nový“) umístěném na liště nástrojů formuláře vytvoříme prázdný

záznam; 

Vyplníme: o

Uživatelské jméno je v rámci aplikace jedinečné a je zároveň užito ve smyslu databázového účtu;

o

Heslo, které slouží pro vložení počátečního přístupového hesla při zakládání nového uživatele. Po vytvoření uživatele již není toto heslo nikde prezentováno. Je na každém uživateli, aby si počáteční hodnotu hesla přepsal na novou, svou vlastní hodnotu;

o

Případně další potřebné informace o uživateli jako například kontakt, email, platnost atd;



Uložíme vyplněný záznam pomocí tlačítka

(„Uložit“).

Na následujícím obrázku je snímek obrazovky pro založení nového uživatele.

Obrázek 7 - Formulář pro založení nových uživatelů

Úkon2 - Přiřazení role uživateli Součástí vytvoření uživatelského účtu je i definice rolí, které budou budoucímu uživateli přiřazeny (například energetik, správce zařízení, finanční manažer, a podobně). Role slouží ke stanovení skupin uživatelů, kteří z pohledu aplikace mají totožnou nebo podobnou pracovní náplň. Na formuláři Uživatelé nastavíme kurzor na záznam konkrétního uživatele:

24



Otevřeme záložku Role uživatele a z lišty nástrojů na záložce zvolíme tlačítko „Nový“;



Otevře se formulář Role uživatele, na kterém vybereme ze seznamu existujících předem připravených rolí;



Volitelně zadáme platnosti přiřazení;



Uložíme záznam pomocí tlačítka



Přiřazená role se objeví na seznamu záložky.

(„Uložit“);

Na následujícím obrázku je uveden seznam rolí přiřazených vybranému uživateli.

Obrázek 8 - Záložka pro přiřazení rolí uživatele

Úkon3 - Přiřazení kompetenčních okruhů uživateli v dané roli Další systémová součást nazvaná kompetence umožňuje navíc definovat pravidla pro výběrový přístup k jednotlivým záznamům v databázi aplikace na základě přihlášeného uživatele a jeho rolí. Posledním krokem je tedy přiřazení seznamu kompetenčních okruhů jednotlivým uživatelům v dané roli, neboli přiřazení oprávnění přístupu k datům. Příklad: Dva uživatelé budou mít roli Správce zařízení. Každý z nich ovšem spravuje pouze zařízení ve své lokalitě, a proto musí vidět pouze zařízení, která jsou provozována v dané lokalitě. 

Na formuláři Uživatelé nastavíme kurzor na záznam konkrétního uživatele;



Otevřeme formulář Role uživatele a nastavíme kurzor na požadovanou roli;



Z nástrojové lišty formuláře spustíme akci Přidělení okruhů kompetence;

25



Ze seznamu okruhů kompetencí zobrazených v seznamovém okně vybereme požadované kompetenční okruhy.



Tlačítkem „Spustit“ aktivujeme automatické připojení vybraných kompetenčních okruhů vybranému uživateli ve vybrané roli.

Na následujícím obrázku je snímek přiřazení kompetenčních okruhů uživateli v dané roli.

Obrázek 9 - Formulář pro přiřazení okruhu kompetencí uživateli v roli Správce zařízení

2.b

Přívětivost uživatelského prostředí

Modelová úprava: Přizpůsobení pořadí sloupců v uživatelském prostředí Každý formulář má z výroby defaultně nastavené pořadí sloupců. V průběhu implementace může implementační konzultant toto nastavení upravit podle analýzy cílového stavu. Dodávané řešení navíc umožňuje i koncovým uživatelům provádět přizpůsobení pořadí sloupců během rutinního provozu. Přizpůsobení pořadí lze provést dvěma způsoby, jednak pomocí operace Drag and Drop přímo na formuláři, jednak pomocí nástroje Konfigurace sloupců určeného pro komplexní správu sloupců, který je možno aktivovat na každém formuláři. V následující tabulce jsou uvedeny možné způsoby přizpůsobení pořadí jednoho sloupce a jejich pracnosti. Tabulka 10 – Pracnost přizpůsobení jednoho sloupce

Počet kliků 1 3

Použitý způsob Použití operace Drag and Drop Pomocí nástroje Konfigurace sloupců

26

Počet zadaných polí 0 0

Odhad trvání 5 sec 10 sec

Dále uvádíme přesný popis sledu jednotlivých úkonů každého způsobu Způsob1: Přesun sloupců provedený z formuláře uživatelem operací Drag and Drop Umístěním kurzoru v záhlaví sloupce, který chceme přesunout, dojde k jeho obarvení. Za použití levého tlačítka myši je možné sloupec uchopit a přesunout jej na požadované místo. Vodorovný šedý pruh vyznačuje aktuální pozici přesouvaného sloupce. Ke snadnější orientaci umísťování přesouvaného sloupce slouží černá svislá lišta (viz Obrázek 10).

Obrázek 10 - Zobrazení přesunu sloupců v aplikaci

Způsob2: Přesun sloupců provedený pomocí nástroje Konfigurace sloupců Aktivujeme nástroj Konfigurace sloupců z lišty nástrojů formuláře, na kterém potřebujeme upravit pořadí sloupců. V okně tohoto nástroje je zobrazen seznam všech sloupců formuláře (viz Obrázek 11). Pomocí tohoto nástroje nastavíme požadované pořadí sloupců (volitelně jejich viditelnost, šířku a další přístupná nastavení). K nastavení pořadí slouží šipky v pravé části okna nástroje. Po opuštění a zavření okna stisknutím tlačítka OK se požadovaná nastavení sloupců ihned promítnou na formuláři.

Obrázek 11 - Formulář pro konfiguraci sloupců

Modelová úprava: Nastavení nového filtru nad uživatelským prostředím Filtrování, tj. výběr záznamů splňujících definované podmínky a jejich zobrazení na formuláři lze v nabízeném řešení provádět dvěma způsoby. První způsob je vhodný pro

27

zadání jednodušších podmínek a je prováděn přímo na formuláři, druhý způsob lze použít pro zadání komplexního filtrování pomocí nástroje Rozšířený filtr. V následující tabulce jsou uvedeny možné způsoby nastavení nového filtru a jejich pracnosti. Tabulka 11 – Pracnost nastavení nového filtru

Počet kliků 2 2

Použitý způsob Filtrování přímo na formuláři Filtrování pomocí nástroje Rozšířený filtr

Počet zadaných polí 1 1

Odhad trvání 10 sec 15 sec

Dále uvádíme přesný popis sledu jednotlivých úkonů každého způsobu. Způsob1: Filtrování přímo na formulářích K nastavení filtru na formulářích slouží lišta pro zápis podmínek filtrování, která je umístěna pod seznamem sloupců a má zelenou barvu. Podmínky se zadávají umístěním kurzoru do zeleného pole a zápisem podmínek výběru hodnot pod příslušným sloupcem, jehož hodnoty budou řídit výběr záznamů. Na následujícím obrázku je zobrazen řádek pro vložení filtru.

Obrázek 12 - Řádek pro vložení filtru

Do polí filtrovací lišty je možno napsat textové nebo číselné řetězce (výrazy), podle kterých má být proveden výběr. Pro potvrzení filtru se stiskne klávesa „enter“, která filtr aktivuje. Ve výrazech je možno použít tzv. hvězdičkovou konvenci, kdy hvězdička * nahrazuje libovolný text před nebo za hodnotou, podle které se filtruje. Je možné také filtrovat najednou více sloupců, je-li třeba, aby záznamy vyhovovaly více podmínkám. Postup zadání je analogický s postupem filtrování jednoho sloupce. Je tedy možné kombinovat několik sloupcových filtrů dohromady – zobrazují se pak ty záznamy, které vyhovují všem zadaným sloupcovým filtrům současně (viz Obrázek 13). Na následujícím obrázku je uveden příklad vybraných odběrných míst Elektrické energie nízkého napětí.

28

Obrázek 13 - Filtrování podle více sloupců

Chceme-li použít více než jednu filtrovací podmínku v rámci jednoho sloupce, postupujeme tak, že příslušné podmínky oddělíme znakem „|“ zastupujícím logický operátor OR (lze zapsat pomocí klávesové zkratky pravý Alt + W). Příklad: Pokud bychom chtěli vybrat odběrná místa Elektrické energie vysokého a nízkého napětí, zapsali bychom do sloupce Upřesnění elektro např. podmínku „Níz|Vys“. Na následujícím obrázku je uveden příklad vybraných odběrných míst Elektrické energie pro vysoké i nízké napětí.

Obrázek 14 - Filtrování podle více podmínek v jednom sloupci

Do filtru jednoho nebo více sloupců lze zadat i složitější podmínky jako například operátory a zástupné znaky (např.: =, <>, <=, <, >, atd.). Způsob2: Komplexní filtrování pomocí nástroje Rozšířený filtr Součástí aplikace je i nástroj „Rozšířený filtr“ pro definice komplexního a složitějšího filtrování, ve kterém lze podmínky výběru hodnot psát pomocí editoru nebo přímo v definované syntaxi. Následující obrázek přináší ukázku editoru nástroje „Rozšířený filtr“.

29

Obrázek 15 – Editor nástroje Rozšířený filtr

Tento nástroj je určen hlavně administrátorům a zkušenějším uživatelům. Nabízené řešení proto umožňuje vytvářet složitější filtry na požádání běžného uživatele administrátorem a rozesílat je přímo jednotlivým koncovým uživatelům nebo celým skupinám. Modelová úprava: Nastavení nových pravidel třídění nad uživatelským prostředím Každý formulář je dodáván s defaultním tříděním jeho záznamů. Nabízené řešení obsahuje nástroje, poskytující uživateli možnosti změnit defaultní třídění nebo vytvořit další třídění záznamů. Třídit záznamy na formuláři lze podle libovolného počtu sloupců. Nastavená třídění lze pojmenovat a uložit pro opakované použití. V následující tabulce jsou uvedeny možné způsoby třídění a jejich pracnosti. Tabulka 12 – Pracnost třídění

Počet kliků 1 3

Použitý způsob Třídění podle jednoho sloupce Třídění podle tří sloupců

Počet zadaných polí 0 0

Odhad trvání 5 sec 10 sec

Dále uvádíme přesný popis sledu jednotlivých úkonů každého způsobu. Způsob1: Třídění podle jednoho sloupce Po kliknutí myší na záhlaví vybraného sloupce se záznamy na formuláři ihned setřídí dle hodnot daného sloupce vzestupně a v pravé části záhlaví sloupce se zobrazí šipka indikující způsob třídění. Opětovným kliknutím na stejný sloupec se změní směr třídění. Návrat na defaultní třídění se provede aktivací příslušné volby kontextového menu (kliknutím pravým tlačítkem myši ve formuláři a zvolením položky „Vypnout třídění“.)

30

Obrázek 16 – Třídění podle jednoho sloupce

Způsob2: Třídění podle více sloupců Nejprve nastavíme třídění podle prvního sloupce způsobem uvedeným v předcházejícím textu. Třídění podle dalšího sloupce nastavíme Shift + poklepání myší na další sloupec. Při třídění záznamů podle více sloupců záleží na nastaveném pořadí sloupců na formuláři. Hodnoty ve sloupci vybraném pro třídění, který je umístěn nejvíce vlevo, představují nejvyšší úroveň třídění, atd. Na uvedeném příkladu jsou záznamy setříděny podle upřesnění odběrných míst elektrické energie a v rámci jednoho upřesnění podle názvu odběrných míst.

Obrázek 17 – Třídění podle více sloupců

Modelová úprava: Uložení nastavení výše uvedených změn uživatelského prostředí pro daného uživatele Veškeré provedené modifikace formulářů, které byly popsány v předchozích modelových úpravách (výběr a seřazení sloupců, třídění a filtrování záznamů včetně jejich kombinací) lze pojmenovat a uchovat pro opakované použití. K provedení této činnosti slouží nástroj Uložení konfigurace formuláře, který je přístupný v kontextovém menu všech formulářů. Tento nástroj lze využít dvěma způsoby. Můžeme přidávat modifikované formuláře jednak do menu formuláře, jednak do navigačního stromu aplikace. V následující tabulce jsou uvedeny možné způsoby uložení nastavení změn uživatelského prostředí a jejich pracnosti.

31

Tabulka 13 – Pracnost uložení nastavení změn uživatelského prostředí

Počet kliků 2 3

Použitý způsob Uložení nastavení do menu formuláře Uložení nastavení do navigačního stromu aplikace

Počet zadaných polí 1 1

Odhad trvání 5 sec 10 sec

Dále uvádíme popis sledu jednotlivých úkonů lišících se pouze způsobem zadání. Aktivujeme nástroj Uložení konfigurace formuláře. Zobrazí se dialogové okno pro zadání uživatelského jména modifikovaného formuláře.

Obrázek 18 - Uložení konfigurace formuláře

Pokud ponecháme checkboxy Defaultní a Zobrazit v navigačním stromu prázdné, objeví se tato pojmenovaná modifikace v menu formuláře. Pokud zaškrtneme volbu Zobrazit v navigačním stromu, zobrazí se tato modifikace v navigačním stromu aplikace. Následující obrázky ilustrují zobrazení modifikace v menu formuláře a v navigačním stromu aplikace.

Obrázek 19 – Uložení modifikovaných formulářů v menu formuláře

32

Obrázek 20 – Uložení modifikovaných formulářů v navigačním stromu aplikace

Modelová úprava: Nastavení nového workflow procesu pro informování odpovědného pracovníka emailem o vypršení lhůty pro revizi technického zařízení Nabízené řešení disponuje rozsáhlým komplexním systémovým průřezovým modulem pro podporu workflow procesů (dále také jen WF), který umožňuje dynamicky definovat ruční i automatické řízení objektů či správu životních cyklů objektů jakými je např. technické zařízení, revize, faktura (dále také jen Objekt WF), který mimo řešení stavového diagramu nabízí definici notifikací, procesních toků, kontrol, časových upozornění atd., a to vše pomocí integrovaného prostředí doplněného grafickým editorem. Celý aparát workflow obsahuje dvě hlavní části: 

definiční část pro nastavení procesů workflow (dále také jen WF Editor);



uživatelskou část (dále jen WF Engine).

Následující obrázek uvádí zjednodušený pohled na modul pro podporu workflow procesů:

Obrázek 21 – Zjednodušený pohled na modul pro podporu workflow procesů

33

Definiční část WorkFlow V následující tabulce jsou uvedeny úkony nutné pro nastavení procesu pro informování pracovníka o vypršení lhůty pro revizi a jejich pracnosti. Tabulka 14 – Úkony pro nastavení procesu

Počet kliků 8 3

Úkon Grafická definice procesu Editace akce Odeslání emailu

Počet zadaných polí 3 6

Odhad trvání 1 min 2 min

Dále uvádíme přesný popis sledu jednotlivých úkonů. Úkon1 – Grafická definice procesu Na následujícím obrázku je zobrazen Workflow editor (WF Editor), grafický nástroj, který slouží k vytváření takzvaných Šablon workflow, které jsou graficky znázorňovány pomocí diagramu. Je součástí nabízeného řešení a je možné jej zpřístupnit vybraným uživatelům dle nastavení rolí a práv. Na obrázku je jednoduchá šablona pro nastavení odesílání informací odpovědnému pracovníkovi o lhůtách revizí.

Obrázek 22 – Šablona k odesílání emailových informací správci zařízení

Úkon2 – Editace akce Odeslání emailu V pravé části editoru jsou umístěny nástroje (editory) pro definici dalších vlastností workflow. Na dalším obrázku je ukázka editoru Akcí.

34

Obrázek 23 - Editor akcí Workflow - odesílání emailu

V definici odeslání emailové informace je nutné nastavit tyto parametry: 

Volba – forma notifikace (email / SMS);



Typ adresy – Zde se nabízí několik možností typů adresátů. Například lze zadat přímo emailovou adresu, nebo také zvolit vybraný okruh rolí či kompetencí, kterým bude daná zpráva doručena;



Podmínka – lze nastavit omezující podmínku pro odesílání emailu/sms dle standardní syntaxe pro vytváření podmínek;



Předmět emailu - vhodné použití je s vloženým identifikátorem dokladu;



Šablona sestavy – identifikátor připojené sestavy k emailové zprávě zasílané WF systémem;



Text – tělo emailu. Je možné vkládat hodnoty atributu přes #atribut, hypertextové odkazy na doklady apod.;



Sumární email – funkce, která umožňuje zařazení tohoto emailu do fronty pro odeslání v hromadném sumárním emailu;



Odložené odesílání – možnost odeslat zprávu s přesně definovaným zpožděním;



Formát – možnost volby formátu emailové zprávy (text, html).

Uživatelská část WorkFlow Uživatelská část workflow neboli workflow engine (WF Engine), poskytuje uživateli dostupnost aktivit pracovního postupu tak, jak bylo definováno v šabloně, náhled na aktuální stav workflow, náhled na historii průchodem workflow apod. Dostupnost aktivit daného procesu je řízená právy a rolemi. Aktivity, které jsou spouštěny uživatelem, jsou nabízeny formou akcí umístěných pod ikonou Workflow v nástrojové liště formuláře.

35

Obrázek 24 – Uživatelská část Workflow – odeslání emailu správci zařízení

36

Požadované snímky obrazovek: Snímek zobrazení evidence technických údajů jednoho technického zařízení:

Obrázek 25 - Zobrazení evidenčních údajů na kartě technologického zařízení

37

Snímek odběrového diagramu pro jednoho klienta:

Obrázek 26 – Odběrový diagram

Snímek uživatelské sestavy vyúčtování nákladů za dodávku tepla pro vytápění a ohřev TUV a dodávku studené vody:

Obrázek 27 - Sestava vyúčtování nákladů

38

2.c Jednotnost uživatelského prostředí Uchazeč pokládá za účelné uvést nejprve základní obecné charakteristiky uživatelského prostředí, z nichž bude patrná jeho jednotnost. Zadavatelem požadované snímky obrazovek demonstrující popsanou jednotnost prostředí jsou uvedeny od str. 37. Obecné charakteristiky uživatelského prostředí Dodávané řešení se vyznačuje striktní jednotností uživatelského prostředí tj. každý formulář aplikace má podobnou logiku ovládání a grafickou interpretaci údajů na pracovní ploše. Základní okno aplikace Základní okno aplikace je rozděleno do dvou funkčních částí (podoken), a to na navigační (na obrázku červeně zvýrazněné a pracovní podokno (zvýrazněné modře).

Obrázek 28 – Základní okno aplikace

Navigační podokno Navigační podokno obsahuje tři záložky: 

Záložka FamaPlus obsahující navigační strom představující menu se stromovou strukturou, které umožňuje přístup k těm částem aplikace (modulům, formulářům, reportům), které odpovídají uživatelské roli přihlášeného uživatele;



Záložka Vyhledat formulář, pro aktivaci nástroje pro vyhledání formulářů, které ve svém názvu obsahují text zadaný uživatelem v dialogovém okně tohoto nástroje;



Záložka Oblíbené slouží uživateli pro uložení nejčastěji používaných formulářů z navigačního stromu. 39

Pracovní podokno V pracovním okně se zobrazuje kompletní formulář, který byl uživatelem otevřen z navigačního stromu. Podle účelu a obsahu formuláře může být pracovní podokno strukturováno na další podokna, přičemž alespoň jedno podokno je vždy k dispozici. Jedná se o Strom (na obrázku zvýrazněn zeleně), Seznam (červeně) a Detail (modře).

Obrázek 29 – Struktura pracovního podokna

Podokno Strom se využívá v případě, kdy detailní záznamy mají logickou hierarchizovanou strukturu. V seznamu v podokně Strom se zobrazují uzly definované hierarchie. Nastavením kurzoru na záznam uzlu se v seznamovém okně zobrazí skupina záznamů přiřazených danému uzlu. Podokno Seznam slouží pro zobrazení dat formuláře ve formě tabulky, jejíž řádky obsahují záznamy a sloupce jednotlivé položky těchto záznamů. Podokno Detail pro detailní a uspořádané zobrazení údajů záznamu, na kterém je nastaven kurzor v seznamové části. Slouží k zadávání nových a k editaci existujících záznamů. Povinné údaje jsou obarveny žlutě, pokud je za polem umístěno tlačítko znamená to, že hodnota v poli se vybírá z definovaného seznamu hodnot, tlačítko u datumových polí vyjadřuje, že časové údaje lze zadávat pomocí kalendáře. Podokno Detail může obsahovat záložky, které slouží pro práci s dalšími záznamy vztahujícími se k záznamu vybranému v podokně Seznam. Většinou mají seznamovou strukturu, existují však i záložky, obsahující uspořádané zobrazení dalších údajů z označeného záznamu na seznamu.

40

Pozn.: Specifickými případy pracovního podokna jsou např. kalendáře, grafy, prezentace výkresové dokumentace, které mají odlišnou strukturu. Tyto komponenty představují vhodnou formu prezentace specifických dat (výkresy, mapy) jednak údajů pro monitoring a vyhodnocování – viz dále v této kapitole. Lišta nástrojů pracovního podokna a záložek V horní části pracovního podokna je umístěna lišta nástrojů, která obsahuje tlačítka sloužící k aktivaci funkcí a nástrojů popsaných v další části této kapitoly. Lišta nástrojů je k dispozici i na vybraných záložkách. Na záložkách je lišta umístěná svisle v levé části podokna.

Obrázek 30 – Lišta nástrojů pracovního podokna

Obrázek 31 – Lišta nástrojů na záložce

Množina tlačítek obsažená v liště nástrojů je závislá na kontextu formuláře resp. záložky, tj. nemusí obsahovat všechna tlačítka. Např. formulář určený pouze pro přehled záznamů neobsahuje funkce založení nového záznamu, editace a zrušení atd. Význam tlačítek je následující:

Tlačítko Aktualizace slouží pro refresh tj. opětovné načtení zobrazovaného seznamu záznamů. Tlačítko Nový složí k vložení nového záznamu pro editaci. Tlačítko Kopie záznamu slouží pro vložení nového záznamu obsahujícího kopii hodnotznamu, na kterém byl nastaven kurzor. Tlačítko Editovat slouží pro aktivaci provádění úprav údajů na aktuálním záznamu. Tlačítko Uložit slouží k uložení záznamu nového nebo upraveného záznamu.

41

Tlačítko Zrušit změny slouží k potlačení aktuálně provedených změn hodnot na editovaném záznamu. Tlačítko Smazat slouží k trvalému smazání záznamu (dojde k upozornění formou dialogového okna, které zabraňuje nechtěnému smazání záznamu). Tlačítko Funkce slouží k zobrazení kontextového seznamu pro aktivaci povolených funkcí, které jsou k dispozici na formuláři (např. připojení dokumentu, generování parametrů, atd.).

Obrázek 32 – Seznam povolených funkcí na formuláři

Tlačítko Formuláře slouží k zobrazení seznamu pro aktivaci kontextově příbuzných navazujících formulářů.

Obrázek 33 – Seznam kontextově příbuzných navazujících formulářů

Tlačítko Sestavy slouží k zobrazení seznamu pro aktivaci tiskových sestav. Tlačítko Exporty slouží k zobrazení seznamu pro aktivaci možností exportu dat. Tlačítko Nástroje – slouží k zobrazení seznamu pro aktivaci nástrojů pro správu formuláře.

42

Obrázek 34 – Seznam nástrojů pro správu formuláře

Kontextové menu Vedle lišty nástrojů obsahuje uživatelské prostředí ještě možnost vyvolání kontextového menu obsahující další vybrané funkce. Kontextové menu lze aktivovat stisknutím pravého tlačítka myši na seznamové části podokna Seznam každého formuláře nebo na všech seznamových záložkách.

Obrázek 35 – Kontextové menu formuláře

Stručný popis položek menu: Konfigurace sloupců – aktivuje nástroj pro konfiguraci vzhledu formuláře nebo záložky. Nástroj je podrobně popsán v rámci hodnotícího subkritéria Přívětivost uživatelského prostředí v části Přizpůsobení pořadí sloupců v uživatelském prostředí. Rozšířený filtr – aktivuje nástroj pro konstrukci složitých podmínek výběru záznamů na formuláři nebo na záložce. Nástroj je popsán v rámci hodnotícího subkritéria Přívětivost uživatelského prostředí v části Nastavení nového filtru nad uživatelským prostředím. Vypnout třídění – deaktivuje třídící podmínky záznamů na formuláři nebo na záložce.

43

Graf – aktivuje nástroj pro konstrukci grafů. Nástroj je podrobně popsán v rámci hodnotícího subkritéria Možnost uživatelského nastavení reportů, sestav a výkazů. Počet záznamů – poskytuje celkový počet záznamů datové třídy formuláře nebo záložky a počet záznamů vyhovujících výběrovým podmínkám, pokud byly aplikovány. Údaj o vzniku / změně záznamu – poskytuje informace o původci a čase založení záznamu a o původci a čase poslední aktualizace záznamu. Hodnotová analýza – aktivuje přehled agregovaných ukazatelů definovaných na třídě formuláře nebo záložky. Podrobnější popis je uveden dále v rámci popisu požadavků tohoto subkritéria. Obrazovky demonstrující jednotnost uživatelského prostředí pro požadované části řešení V této kapitole jsou uvedeny požadované obrazovky sloužící pro demonstraci jednotnosti uživatelského prostředí přes různorodost věcných oblastí, které pokrývají. Pro snazší orientaci a přehlednost obsahují snímky pouze Pracovní podokna, Navigační podokna byla na snímcích potlačena. Obrazovka: Evidence technického majetku Na níže uvedeném obrázku je zobrazen snímek formuláře karty technologického zařízení, který je navržen ve struktuře podoken Strom – Seznam – Detail. Jedná se o formulář zahrnující poměrně rozsáhlou funkčnost. Lišta nástrojů formuláře obsahuje všechna standardní tlačítka, v podokně Detail je možnost práce s větším počtem záložek.

44

Obrázek 36 - Formulář Technologická zařízení

Obrazovka: Odběry a dodávky paliv, komodit a energií Pro uvedenou část řešení jsme vybrali ukázku dvou přehledových formulářů odebraných energií jednotlivých odběratelů. Pracovní podokno formuláře Přehled účetních odečtů za energie, který je uveden jako první, obsahuje podokna Strom a Seznam. Jde o přehledový formulář bez podokna Detail s redukovaným počtem tlačítek v liště nástrojů, protože na formuláři nelze zadávat nové položky, slouží pouze pro prohlížení údajů.

45

Obrázek 37 - Přehledový formulář odběrů uspořádaných dle druhu energie

Formulář Přehled účetních odečtů za vodu je rovněž přehledový, tj. slouží pouze pro prohlížení údajů bez možnosti zadávání nových záznamů, proto má rovněž redukovanou lištu nástrojů. Jelikož se jedná o odečty jednoho druhu energie, obsahuje kromě podokna Seznam i podokno Detail, umožňující přehledným způsobem zobrazit všechny údaje zadané na aktivním záznamu odečtu.

Obrázek 38 - Přehled účetních odečtů za vodu dle odběrných míst

46

Obrazovka: Stav a pohyb zásob souvisejících s energetickým managementem Uvedený formulář Skladové pohyby – přehled je přehledový, bez podoken Strom a Detail.

Obrázek 39 - Přehled skladových pohybů

Formulář Katalog materiálu slouží pro správu materiálu, skládá se z podoken Seznam a Detail, obsahuje komplexní lištu nástrojů a umožňuje práci na několika záložkách.

Obrázek 40 – Katalog materiálu

47

Obrazovka: Kalkulace a automatické výpočty Nad vybranými daty v systému lze nastavit sledování libovolných číselných ukazatelů za definovaná období v reálném čase, a to pomocí aktivace a nastavení tzv. hodnotové analýzy, která umožňuje provádět kalkulace a automatické výpočty na uživatelské nebo implementační bázi, tj. bez nutnosti analyticko-programátorských vývojových prací. Definiční část hodnotové analýzy je založena na skupinách předpisů – šablonách, které definují způsoby získání parametrů k vlastnímu provedení algoritmů zpracování hodnot definovaných ukazatelů ze zdrojových dokladů. Každá skupina šablon odpovídá určitému procesu v reálných aplikacích, který metody hodnotové analýzy využívá (načítání jednotlivých druhů nákladů, sledování hodin na mzdových výčetkách pracovníků apod.). Definiční část realizuje dodavatel na základě požadavků Zadavatele. Aktuální hodnoty nadefinovaných ukazatelů hodnotové analýzy lze jednotným způsobem zobrazit nad daty formuláře z kontextového menu aktivací volby Hodnotová analýza. Pomocí hodnotové analýzy lze kteroukoliv sledovanou hodnotu rozložit na elementární hodnotové složky s vazbou na původní zdroje – doklady, kde vznikly (zpětná vazba, když potřebujeme zmapovat, z jakých dílčích hodnot aktuální hodnota ukazatele vznikla). Formulář pro prohlížení výsledků kalkulací a výpočtů má opět jednotné uživatelské prostředí viz následující obrázek.

Obrázek 41 – Přehled ukazatelů hodnotové analýzy

48

Obrazovka: Plánování a modelování Plánování Dodávané řešení disponuje oblastí pro plánování budoucích scénářů odběrů paliv, komodit a energií. Řešení spočívá v přípravě podkladů o spotřebě, které vychází z minulého období. Součástí řešení je vytvoření předpisu rozpadu nákladů a spotřeby, včetně možnosti verzování předpisů a provedení rozpočítání a kumulace spotřeby a nákladů po střediscích za jednotlivé energie. Řešení je koncipováno tak, aby bylo možné plánovat samostatně jednotlivé energie a aby bylo možno vytvářet scénáře rozdělení (viz Obrázek 42). Uživatelské prostředí této specifické oblasti se vyznačuje opět jednotným uživatelským rozhraním.

Obrázek 42 - Formulář s přehledem dílčích plánů energií na jednotlivé roky

Modelování Jako příklad pro modelování lze uvést modelování vývoje specifických energetických ukazatelů, V rámci modelování jsou vydefinovány základní přepočítací energetické ukazatele: 

Průměrná denní spotřeba;



Průměrné denní náklady;



Průměrná cena dané energie;



Přepočítaná měsíční spotřeba dané energie;

49



Přepočítané měsíční náklady;



Kumulovaná spotřeba dané energie od začátku roku;



Kumulované náklady od začátku roku;



Kumulovaná cena dané energie od začátku roku.

Pro prohlížení výsledků modelování slouží souhrnný formulář Časový vývoj hlavních ukazatelů, v jednotném uživatelském prostředí (Podokno Seznam, lišta standardních nástrojů) – viz následující obrázek.

Obrázek 43 - Časový vývoj hlavních ukazatelů

Obrazovka: Monitorování Jako příklady monitorování lze uvést např. monitoring správy a provozu technologií a monitoring odběrů a spotřeb komodit a energií. Pro snadnější přehled o termínech realizace revizí a kontrol lze využívat formu Kalendáře, který je zobrazen na následujícím obrázku. Kalendář lze zobrazit v denním, týdenním nebo měsíčním rozlišení. Přestože se kalendářová komponenta liší od uživatelského prostředí prezentovaného v této kapitole, představuje vhodnou formu pro sledování vybraných údajů v časových souvislostech. Uživatelé se již s touto komponentou setkali v jiných aplikacích a práce s ní jim nebude činit potíže.

50

Obrázek 44 - Kalendářové zobrazení revizí a kontrol

Pro monitorování odběrů a spotřeb komodit a energií lze s výhodou použít uložené dynamické grafy, které se automaticky aktualizují podle zadaných dat do systému. Ukázka dynamického grafu (načítání automatických odečtů z elektroměru po hodinových intervalech) je na Obrázek 45.

Obrázek 45 - Graf průběhu spotřeby na Elektroměru

51

Stejně tak jako kalendářová komponenta se i grafy liší od uživatelského prostředí prezentovaného v této kapitole a stejně tak i práce s grafy jim nebude činit potíže.

2.d

Možnost uživatelského nastavení reportů, sestav a výkazů

Modelová úprava: Vytvoření nové šablony uživatelské sestavy a její uložení Nabízené řešení umožňuje pro účely prezentace a zobrazení aktuálních údajů generovat na libovolném formuláři jednoduché uživatelské reporty operativní evidence, které reflektují použitá výběrová kritéria, třídění a zobrazené sloupce. Každý takto generovaný seznam lze následně vytisknout nebo exportovat do celé řady formátů např. CSV, XLS, PDF. DOC. V následující tabulce je uveden seznam a pracnost úkonů, které je třeba provést pro vytvoření nové šablony uživatelské sestavy a její uložení. Tabulka 15- Pracnost vytvoření nové šablony

Pořadí a název úkonu 1. 2. 3. 4. *

Volba zdrojových dat pro uživatelskou sestavu Výběr údajů a nastavení podmínek filtrování a třídění Uložení nastavení do navigačního stromu Zpracování sestavy

Počet kliků 1

Počet zadaných polí 0

Odhad trvání 5 sec

3

1

15 sec

3 1

1 0

10 sec 15 sec

pro filtrování a třídění jednoho pole

Dále uvádíme přesný popis sledu jednotlivých úkonů. Úkon1 – Volba zdrojových dat pro uživatelskou sestavu V závislosti na požadovaném obsahu reportu zvolíme příslušný formulář a aktivujeme jej z navigačního stromu. Úkon2 – Výběr údajů a nastavení podmínek filtrování a třídění V závislosti na požadovaném rozsahu a uspořádání reportu aplikujeme nástroje pro přizpůsobení pořadí sloupců, nastavení filtru a pravidel třídění. Tyto činnosti jsou podrobně popsány v rámci hodnotícího subkritéria Přívětivost uživatelského prostředí – v částech Přizpůsobení pořadí sloupců, Nastavení nového filtru, Nastavení nových pravidel třídění. Pokud chceme opakovaně zpracovat vytvořenou sestavu, pokračujeme krokem3, pokud chceme data rovnou vytisknout, pokračujeme krokem4. Úkon3 – Uložení nastavení do navigačního stromu Veškeré modifikace provedené v předchozím kroku lze pojmenovat a uchovat pro opakované použití. K provedení této činnosti slouží nástroj Uložení konfigurace formuláře, 52

který je přístupný v kontextovém menu všech formulářů. Tato činnost je podrobně popsána v rámci hodnotícího subkritéria Přívětivost uživatelského prostředí v části Nastavení změn uživatelského prostředí pro daného uživatele. Na následujícím obrázku jsou zobrazeny tři uživatelsky vytvořené sestavy přehledů účetních odečtů (podle lokalit a za všechny lokality) uložené v navigačním stromu.

Obrázek 46 – Uživatelské sestavy v navigačním stromu aplikace

Úkon4 – Zpracování sestavy 

Pokud jsme provedli Úkon3, aktivujeme požadovanou sestavu z navigačního menu.



V nástrojové liště tlačítkem Viz následující obrázek.

Sestavy aktivujeme menu a vybereme volbu Tisk seznamu.

Obrázek 47 – Zpracování uživatelské sestavy



Systém automaticky vygeneruje tiskovou sestavu – viz následující obrázek. V řešení je možno nastavit, do jakého formátu bude sestava pořízena.

53

Obrázek 48 – Vygenerovaná uživatelská sestava



Na závěr provedeme uložení sestavy do požadovaného úložiště.

Modelová úprava: Nastavení četnosti automatického generování reportů a pravidel jeho distribuce koncovým příjemcům formou emailu V následující tabulce je uveden seznam a pracnost úkonů, které je třeba provést pro nastavení četnosti automatického generování reportů a pravidel jeho distribuce koncovým příjemcům formou emailů. Tabulka 16 - Pracnost úkonů pro nastavení generování reportů a jeho odeslání emailem

Počet kliků

Pořadí a název úkonu 1. 2. 3.

4.

Definice a nastavení pravidel pro generování reportu Nastavení příjemců reportu Nastavení Workflow pro odesílání reportu příjemcům

Nastavení automatického generování reportu

Počet zadaných polí

Odhad trvání

2

10

20 sec

2

2

10 sec

11

9

180 sec

2

4

20 sec

Dále uvádíme přesný popis sledu jednotlivých úkonů. Úkon1 – Definice a nastavení pravidel pro generování reportu Pro každý report, který se má pravidelně generovat, musí být vytvořeno pravidlo generování se zadanými specifikacemi opakování a výběru dat. Ke každému pravidlu musí být připojen seznam příjemců reportu. 

Otevřeme formulář Generování sestav, který je umístěn v uzlu Systémová nastavení navigačním stromu nabízeného řešení. Na tomto formuláři zadáme nové pravidlo generování sestavy.

54

Obrázek 49 – Formulář Generování sestav



Tlačítkem

(„Nový“) umístěném na liště nástrojů formuláře otevřeme nový záznam

pro vložení nového pravidla generování; 

Zadáme požadované údaje: o

Kód - Slouží pouze k internímu rozlišení pravidel;

o

Název – Název pravidla, pod tímto názvem je při generování vytvářen soubor, do něhož se ukládá vygenerovaná sestava. Tento soubor je po vygenerování přesunut do společného úložiště souborů a připraven pro další zpracování;

o

ReportName – Název generátoru reportu;

o

Třída – třída parametrické sestavy;

o

Formát souboru – formát (přípona) souboru, do něhož bude uložena vygenerovaná sestava;

o

Aktivní - příznak aktivnosti šablony. Je-li pravidlo aktivní, potom je z ní v zadaných časových intervalech automaticky generována sestava;

o

Periodická - příznak, zda se jedná o periodickou sestavu opakovaně spouštěnou timerem nebo o běžnou sestavu;

o

Způsob opakování – definuje, jak často se má sestava generovat (denně, týdně, atd.);

o

Délka intervalu – násobek údaje Způsob opakování;

o

Datum generování – Datum příštího generování sestavy. Timer prochází aktivní šablony a z těch, které mají datum menší rovno SYSDATE generuje sestavu a následně přepočítá datum příštího generování;

o

Začátek – definuje název atributu třídy parametrického objektu, jehož hodnota indikuje začátek platnosti dat vstupujících do reportu. Jeho hodnota je přepočítávána současně s hodnotou atributu Datum generování; 55

o

Datum začátek – nastavení začátku platnosti dat sestavy, nastavuje se pouze před prvním generování, dále se již při každém generování posouvá automaticky;

o

Konec – název atributu pro omezení konce platnosti dat;

o

Datum konec – nastavení konce platnosti dat sestavy, platí stejná pravidla jako pole Datum začátek. Při vyplnění pole Konec je toto pole povinné;



Uložíme doplněný záznam pomocí tlačítka

(„Uložit“).

Úkon 2 – Nastavení příjemců reportu 

Na formuláři Generování sestav otevřeme záložku Seznam příjemců;

Obrázek 50 – Seznam příjemců automaticky generovaných reportů



Tlačítkem

(„Nový“) umístěném na liště nástrojů záložky otevřeme nový záznam pro

vložení nového příjemce; 

Zadáme Název a Emailovou adresu příjemce;



Uložíme doplněný záznam pomocí tlačítka



Popsanou činnost opakujeme pro nastavení dalšího příjemce.

(„Uložit“);

Úkon3 – Nastavení Workflow pro odesílání reportů příjemcům Na datové třídě záznamu pravidla musí být nastaveno WorkFlow, které zajistí, aby po události vygenerování sestavy, došlo k odeslání emailu s vygenerovanou sestavou příjemcům definovaným na pravidle. Tato činnost je podobná činnosti popsané v rámci hodnotícího subkritéria Přívětivost uživatelského prostředí v části Nastavení workflow procesu informování odpovědného pracovníka emailem o vypršení lhůty pro revizi technického zařízení.

56

Úkon4 - Nastavení automatického generování reportu Nabízené řešení

obsahuje

funkci, jejíž

pravidelná aktivace

musí

být nastavena

prostřednictvím tzv. timeru neboli časovače. Aktivovaná funkce prochází platná pravidla generování reportů a u každého pravidla vyhodnocuje splnění podmínky pro generování reportu. Pokud je podmínka splněna, funkce spustí generátor reportu, který vygeneruje a uloží report do definovaného úložiště a zároveň na záznam pravidla indikuje událost vygenerování sestavy. Nastavené WorkFlow potom zajistí odeslání emailu s vygenerovanou sestavou definovaným příjemcům. 

Otevřeme formulář Timer spouštěče, který je umístěn v uzlu Systémová nastavení navigačním stromu nabízeného řešení. Na tomto formuláři zadáme nové pravidlo spouštění procedury Generuj_sestavy, která zajišťuje automatické generování reportů na základě nastavených pravidel generování jednotlivých reportů.

Obrázek 51 – Nastavení timeru pro automatické generování reportů



Tlačítkem

(„Nový“) umístěném na liště nástrojů formuláře otevřeme nový záznam

pro vložení časovače; 



Zadáme: o

Název a Příznak aktivnosti;

o

Název spuštěné funkce;

o

Periodicitu pravidelné aktivace zadané funkce – zde každý den v týdnu v 8:00.

Uložíme doplněný záznam pomocí tlačítka

57

(„Uložit“).

Po provedení Kroku4 je nastavení provedeno. Systém zahájí po splnění nejbližší podmínky spuštění časovače generování reportů a jejich distribuci formou emailu definovaným koncovým příjemcům. Modelová úprava: Vytvoření maticového pohledu na vybraná data Nabízené řešení umožňuje generovat nad libovolnými daty maticové pohledy s možností definice agregačních funkci. Maticové pohledy lze podobně jako grafy ukládat jako položky dynamického menu aplikace a kdykoliv opětovně vyvolat s aktualizovanými daty. Modelová úprava vyžaduje pouze jeden úkon, jehož pracnost je uvedena v následující tabulce. Tabulka 17 – Vytvoření maticového pohledu na vybraná data

Pořadí a název úkonu 1.

Vytvoření maticového pohledu na vybraná data

Počet kliků 7

Počet zadaných polí 0

Odhad trvání 15 sec

Dále uvádíme přesný popis úkonu. Úkon1 - Vytvoření maticového pohledu na vybraná data 

V nástrojové liště tlačítkem Viz následující obrázek;

Sestavy aktivujeme menu a vybereme volbu Tisk matice.

Obrázek 52 – Výběr tisku matice



Otevře se pracovní okno nástroje pro tvorbu maticových pohledů – viz obrázek.

58

Obrázek 53 – Pracovní okno nástroje pro definici maticové sestavy



Zvolíme, dle jakého atributu požadujeme agregovat maticovou sestavu. Následně zvolíme agregační funkci a zadáme, dle jakých atributů se mají sledovat hodnoty ve sloupcích a řádcích. Vpravo nahoře zobrazuje aplikace výslednou strukturu maticové sestavy;



Zvolíme požadovaný formát výstupu (v nabídce jsou PDF, XPS, Excel, MHTML, Word, Word2007, Text, OpenOffice);



Zobrazení sestavy provedeme pomocí tlačítka OK. Ukázku výsledné sestavy uvádíme na následujícím obrázku.

Obrázek 54 - Ukázka maticové sestavy

Modelová úprava: Vytvoření grafu nad vybranými daty a jeho uložení Nabízené řešení disponuje funkcionalitou, kdy lze nad zobrazenými daty (získanými na základě zadaných výběrových kritérií) vygenerovat grafy (sloupcový, koláčový, …) 59

s využitím agregačních funkcí (např. počet výskytů, suma, průměr, maximum, minimum, apod.). Vytvořené grafy lze pojmenovat, uložit do dynamického menu aplikace a opakovaně spouštět vždy nad aktuálními daty, která odpovídají výběrovému kritériu. Modelová úprava vyžaduje pouze jeden úkon, jehož pracnost je uvedena v následující tabulce. Tabulka 18 – Vytvoření grafu nad vybranými daty

Počet kliků 5

Pořadí a název úkonu 1.

Vytvoření grafu nad vybranými daty

Počet zadaných polí 3

Odhad trvání 20 sec

Dále uvádíme přesný popis úkonu. Úkon1 - Vytvoření grafu nad vybranými daty 

V kontextovém menu formuláře, které získáme stiskem pravého tlačítka myši, aktivujeme nástroj pro tvorbu grafů. Viz následující obrázek:

Obrázek 55 – Aktivace nástroje pro tvorbu grafů v kontextovém menu



Otevře se pracovní okno nástroje pro tvorbu grafů – viz následující obrázek;

Obrázek 56 - Pracovní okno nástroje pro definici grafu

60



Na tomto formuláři zvolíme požadovaný typ grafu, zobrazené hodnoty na ose X a Y, název os. Můžeme také zvolit časový interval, agregační funkce atd. Zvolený graf lze také dále kategorizovat dle vybraných atributů;



Po nadefinování grafu zvolíme tlačítko OK.;



Nastavený graf se ihned zobrazí;

Obrázek 57 – Ukázka uživatelsky vytvořeného grafu



Pokud je zapotřebí, můžeme přímo na grafu změnit typ grafu nebo barvu nebo se vrátit do definičního prostředí stisknutím tlačítka



(„Editovat“) a v něm graf doladit;

Následně můžeme graf uložit přímo do navigačního stromu aplikace pro opakované použití. Tato činnost je podrobně popsána v rámci hodnotícího subkritéria Přívětivost uživatelského prostředí v části Nastavení změn uživatelského prostředí pro daného uživatele.

61

3. ZABEZPEČENÍ IS A INFRASTRUKTURNÍ POŽADAVKY Zhotovitel se zavazuje při realizaci Veřejné zakázky implementovat bezpečnostní principy uvedené v této tabulce v bodě 3.a). Zhotovitel prohlašuje, že technické parametry cílové infrastruktury na úrovni uvedené v této tabulce v bodě 3.b) jsou plně dostačující pro rozsah a funkce IS definované v Příloze č.1 Smlouvy. Zhotovitel prohlašuje, že technické parametry cílové infrastruktury na úrovni uvedené v této tabulce v bodě 3.b) jsou plně dostačující pro plnění SLA parametrů definovaných v Příloze č. 5 Smlouvy.

3.a Míra bezpečnosti IS Společnost Uchazeče je středně velkou společností s adekvátním investičním majetkem, rozsáhlým know how v oblasti poskytování ICT služeb, včetně poskytování outsourcingu. Vzhledem k této skutečnosti je pro nás standardem odpovědnost za ochranu aktiv společnosti, včetně zákaznických a utajovaných informací, které jsou nám svěřeny. Společnost Uchazeče má zavedenu (kromě normy ISO 9001 – řízení kvality, ISO 14001 – řízení environmentu, ISO 20000-1 – řízení služeb IT a ISO 10006 – řízení kvality projektů) normu ČSN ISO/IEC 27001 - systém řízení bezpečnosti informací. Procesy řízení dle všech těchto norem jsou integrovanou součástí systému řízení, což je již mnoho let pravidelně potvrzováno při externích auditech akreditovanou certifikační společností BUREAU VERITAS CZECH REPUBLIC, spol. s r.o. Bezpečnostní principy v průběhu tvorby, dodávky a implementace Prostřednictvím specifických metod a procesů lze dosáhnout již při samotném průběhu tvorby, dodávky a implementace nabízeného řešení omezení zranitelností a hrozeb, které by mohly vést k potencionálnímu porušení bezpečnosti. Fáze specifikace bezpečnostních požadavků Vývojový tým nejprve specifikuje bezpečnostní požadavky ze Zadávací dokumentace, bezpečnostních politik projektu a osvědčené praxe. Na základě analýzy výše zmíněných vstupních informací jsou definovány bezpečnostní požadavky v následujících oblastech: 

Personální požadavky: kvalifikace, bezúhonnost, délka praxe;



Kategorizace důvěrnosti a stanovení politiky zpracování informací;



Definice projektových rolí a s nimi spojených přístupových práv v projektech;



Autentizace a autorizace;



Zabezpečení dat (zdrojové kódy, analýzy) a síťové komunikace;



Integrita kódu a testování.

62

Fáze analýzy V rámci analýzy nemohou být nasazeny např. automatizované nástroje pro kontrolu kódu, avšak v rámci analýzy rizik mohou být identifikovány potencionální hrozby a zranitelnosti již v prvotní fázi návrhu řešení. Fáze vývoje V rámci vývoje aplikace je zavedeno užití následujících praktik: 

Omezení užití známých nespolehlivých funkcí v závislosti na vývojovém prostředí;



Manuální revize kódu (definice bezp. checklistů dle použité technologie);



Používání aktuální verze kompilátorů;



Použití statických a dynamických analytických nástrojů;



Omezení užití dynamického SQL.

Vždy při vývoji je implementována následující funkcionalita: 

Autentizace / Autorizace;



Validace vstupních hodnot (typ, délka, hodnota/rozsah, ...);



Error handling (potlačení citlivých informací ve výpisu chyb, užití generických chybových hlášek, korektní uvolnění paměti, ...);



Logování (výjimky systému, chybná přihlášení, administrativní úkony, ...);



Databázovou bezpečnost (parametrizovaná query, ochrana proti metaznakům, užití principu nejnižšího privilegia, granty, role).

Fáze testování Ochrana proti selhání SW je řešena důsledným naplánováním a dodržováním procesního schématu testování při výrobě a dodávce aktualizací SW. Aktualizace SW lze rozdělit na: 

Patch – cílem je oprava chybné funkčnosti SW či náprava poškozených dat na základě reklamace. Patch může rovněž sloužit k provedení drobné změny či vylepšení funkčnosti na základě požadavku uživatele;



Upgrade – výrazná změna či vylepšení funkčnosti na základě objednávky.

Patche i upgrade budou dodávány formou číslovaných instalačních balíků. Instalační balík může být kumulativní. Může tedy obsahovat více patchů najednou. Pořadí instalací je pevně stanoveno pořadovým číslem a nelze zaměňovat. V každé instalaci bude přiložen plán instalace. Dále budou provedeny akceptační testy obsahující: 

Testy funkčnosti – správné chování funkcí systému, jak je definováno funkční specifikací;



Testy použitelnosti – zda vůbec a jak lze dosáhnout požadovaného cíle, zda je systém uživatelsky přívětivý, zda se s ním dobře pracuje;

63



Testy spolehlivosti – zda se chová stejně za všech okolností, zvláště po přetížení, po výpadku či chybě, zda tyto stavy umí detekovat a hlásit;



Testy výkonu – zda systém není pomalý a zvládne větší množství současně pracujících uživatelů, anebo naopak zda si i při naplnění všech požadavků na obsluhu uživatelů nebere příliš systémových zdrojů.

Fáze Deployment Do fáze deploymentu zahrnujeme ty činnosti, které slouží k uvedení systému do používání. Mezi tyto činnosti patří především. Příprava instalace: 

Výroba instalačního balíku – balík zahrnuje kompletní instalační soubory všech dotčených modulů aplikací vč. databázových scriptů. Součástí přípravy je i vytvoření plánu instalace;



Testování instalačního balíku – provedení pokusné instalace balíku na produkční verzi prostředí u Uchazeče. Účelem je ověření kompletnosti a konzistence instalačního balíku a ověření plánu instalace;



Odeslání Zadavateli – teprve po úspěšném otestování následuje odeslání do testovacího prostředí Zadavatele. Uchazeč smí zasílat instalační balíčky výhradně do testovacího prostředí Zadavatele. Tím je zamezen přímý přístup Uchazeče k produkčnímu prostředí.

Testování SW Zadavatelem: 

Instalace balíku – provedení dle plánu instalace (pro testovací prostředí), o instalaci bude zpracován záznam;



Akceptační testování (Acceptance testing) - prováděné Zadavatelem dle testů specifikovaných Uchazečem. Zadavatel si sám ověří, zda jím zadaný úkol byl splněn podle jeho představ. Samotný proces akceptace však končí až po instalaci do produkčního prostředí a formálním převzetí SW úprav Zadavatelem.

Instalace SW do produkčního prostředí 

Instalace do produkčního prostředí proběhne na pokyn Zadavatele SW. Instalace může proběhnout: o

On-line – za provozu;

o

Off-line – s dočasnou odstávkou.

V případě, že je požadována Uchazečem potřeba instalace metodou off-line, bude provedena v rámci definovaného servisního okna pro provedení instalace. K instalaci budou použity výhradně otestované instalace a akceptované instalace z archivu Zadavatele. O instalaci bude zpracován záznam.

64

Bezpečnostní principy k zajištění ochrany dat v průběhu provozu Uchazeč bude provádět v rámci služeb podpory činnosti Pravidelného zálohování dat nabízeného řešení a Obnovu IS po pádu. Pravidelné zálohování Zálohování bude zahrnovat tvorbu zálohovacího plánu s identifikací datových aktiv (data i SW), stanovení maximální doby ztráty dat a definice zálohovacích postupů. Samotné provádění pravidelných záloh bude prováděno v intervalu dle oboustranně schváleného zálohovacího plánu. Dále bude prováděna kontrola zálohy a test obnovitelnosti dat ze zálohy. Kontrola zálohy a test obnovitelnosti dat ze zálohy bude proveden minimálně 1x ročně s tím, že první kontrola a test budou provedeny nejpozději do 1 měsíce po zahájení poskytování služby resp. po akceptaci IS jako celku na konci Fáze 2. Obnova IS po pádu Obnova IS po pádu bude zahrnovat provádění testu obnovy IS po pádu ze zálohy a v případě skutečné havárie a následného pádu IS provedení jeho obnovy. Provádění všech výše definovaných činností bude v takovém rozsahu, aby byla plně garantována integrita záloh dat i SW komponent IS a jejich využitelnost v případě potřeby s povolenou ztrátou dat pouze v rozsahu stanoveném zálohovacím plánem. Obě činnosti budou poskytovány v režimu 5x12 (v pracovní dny mimo státní svátky a dny pracovního volna od 06:00 do 18:00). Pouze činnosti vyžadující odstávku IS budou provedeny v rámci definovaných servisních oken. Reakční lhůta pro Obnovu IS po pádu: Tabulka 19 – Reakční lhůty

Typ požadavků

Doba odezvy

Doba vyřešení

Obnova IS po pádu v případě nezavinění

Do 4 hodin od

Do 48 hodin od

havárie, která byla příčinou pádu IS,

vyhlášení

ukončení trvání

Uchazečem

havarijního stavu

příčin havarijního

Zadavatelem

stavu

Do 2 hodin od

Do 24 hodin od

pádu IS

pádu IS

Obnova IS po pádu v případě zavinění havárie, která byla příčinou pádu IS, Uchazečem, nebo v případě pádu IS v důsledku vad IS.

Reakční lhůta běží v provozní dobu poskytování služby a začíná od okamžiku vyhlášení havarijního stavu, resp. od pádu IS.

65

Bezpečnostní principy z hlediska přístupu k datům Ochrana přístupu k datům Přístup k datům je v nabízeném řešení chráněn proti nahodilému či neoprávněnému přístupu následujícími bezpečnostními mechanismy: 

Autentizace – totožnost každého uživatele nabízeného řešení je nejprve jednoznačně identifikována, teprve potom je umožněn vstup do systému;



Autorizace – veškeré operace s daty v nabízeném řešení jsou povoleny prostřednictvím aplikačních rolí. Aplikační role definuje uživateli právo na přístup k datům prostřednictvím formulářů, funkcí a sestav;



Kompetence – uživatel nezískává automaticky právo pro přístup k datům evidovaných v nabízeném řešení, ale přistupuje jen k těm, které odpovídají jeho kompetenčnímu okruhu (např. data o spotřebě vody, elektřiny apod.).

Auditní mechanismy V nabízeném řešení jsou obsaženy auditní mechanismy, které lze aktivovat za účelem trasování bezpečnostních a provozních operací, ze kterého lze zpětně provádět analýzu provedených činností. Auditní mechanismy rozdělujeme dle funkce na: 

Chybový audit pro sledování chyb z úrovně aplikační logiky resp. z úrovně příslušného programu;



Uživatelský audit pro sledování přihlašování a odhlašování koncových uživatelů, přidělování a odebírání uživatelských rolí;



Datový audit pro sledování vkládání změn a rušení záznamů ve vybraných datových objektech;



Procesní audit pro sledování informací o prováděných procesních transakcích nad vybranými datovými tabulkami.

Auditní mechanismy vytvářejí tzv. logovací záznamy, které jsou ukládány do databáze nabízeného řešení. K dispozici je uživatelské rozhraní pro sledování a vyhodnocování výsledků jednotlivých typů auditovaných činností s možností automatického či uživatelského mazání již nepotřebných záznamů. Bezpečnostní principy zajišťující maximální ochrany osobních údajů Ochrana osobních údajů v nabízeném řešení splňuje požadavky zákona o ochraně osobních údajů č. 101/2000 Sb. (dále jen zákon) a vychází mimo jiné z následujících legislativních předpokladů: 

Dle zákona, §5 odst. 1 písm. h), nesmí docházet ke sdružování osobních údajů pořízených k různým účelům;



Dle zákona, §5 odst. 1 písm. c), je správce povinen zpracovávat pouze přesné osobní údaje a tyto údaje aktualizovat;

66



Dle zákona, §20 je správce povinen provést likvidaci osobních údajů, jakmile pomine účel, pro který byly osobní údaje zpracovány, nebo na základě žádosti subjektu údajů podle §21. Likvidací osobních údajů se dle zákona, §5 odst. 4 písm. i), rozumí fyzické zničení jejich nosiče, jejich fyzické vymazání nebo jejich trvalé vyloučení z dalších zpracování;



Dle zákona, §5 odst. 1 písm. e), lze uchovávat osobní údaje pouze po dobu, která je nezbytná k účelu jejich zpracování. Po uplynutí této doby mohou být osobní údaje uchovávány pouze pro účely státní statistické služby, pro účely vědecké a pro účely archivnictví.;



Správce je povinen zabránit neoprávněnému nebo nahodilému přístupu k osobním údajům dle zákona, §13 odst. 1.

Pro potřeby nabízeného řešení není relevantní potřeba implementace procesů: 

Anonymizace – Aplikace neuchovává data dle zákona, §5 odst. 1 písm. e), pro účely státní statistické služby, pro účely vědecké a pro účely archivnictví. Aplikace tedy nevyužívá anonymizovaná data ani neposkytuje anonymizované výstupy;



Sdružování dat – Systém tedy již z podstaty neobsahuje informace pořízené k různým účelům a ke sdružování tedy nemůže dojít. Aplikace dále neuchovává ani rodná čísla. Pro identifikaci osob využívá vlastní identifikátory;



Souhlas se zpracováním – pro zpracování osobních údajů není třeba souhlasu se zpracováním údajů. Dle zákona, §5 odst. 2 písm. a), není třeba souhlasu, jestliže správce provádí zpracování nezbytné pro dodržení právní povinnosti správce.

Osobní údaje v nabízeném řešení Nabízené řešení uchovává osobní údaje uživatelů registrujících se pro užívání nabízeného řešení: 

jméno;



příjmení;



interní identifikátor uživatele v organizaci;



e-mailová adresa;



mobilní telefon.

Uvedené bezpečnostní principy umožňují splnění bezpečnostních požadavků na IS, které jsou uvedeny v kapitole VI. přílohy č. 1 smlouvy – Podrobná specifikace díla.

3.b Nároky na technické parametry cílové infrastruktury V této kapitole jsou uvedeny konkrétní požadavky na technické parametry, které jsou nezbytné pro plnou funkčnost nabízeného řešení a splnění všech SLA parametrů služeb definovaných v příloze č. 5 smlouvy – Podmínky plnění služeb. Technické parametry jsou rozděleny do dvou níže uvedených skupin.

67

Technické parametry systémového SW Parametry systémového SW jsou uvedeny v minimálních verzích, vyšší verze uvedeného systémového SW jsou ze strany nabízeného řešení rovněž podporovány. Tabulka 20 – Technické parametry systémového SW

Prvek

WWW klient

OS

Ostatní systémový SW

Windows XP

Windows

integrační

Server 2003 a

služby

vyšší

Bude zajištěno ze strany

MS Silverlight 5

SP2(1

Aplikační a

Způsob zajištění

Zadavatele

IIS 6.0 (dáno verzí OS)

Bude zajištěno ze strany

.NET 4.0

Zadavatele Bude zajištěno ze strany Zadavatele

Databázové Dle platformy MS SQL 2005 a vyšší nebo služby

DB

Oracle 10g a vyšší

Budou využity stávající DB služby

(1

Alternativně lze použít i jiné OS, které jsou podporovány pro běh MS Silverlight (viz

www.microsoft.com/getsilverlight) Technické parametry HW HW parametry jsou uvedeny jako minimální ve vazbě na potřeby nabízeného řešení. Pro výslednou HW definici daného prvku je třeba zahrnout i požadavky ostatních programů či ostatních IS (OS, Office, atd.), které jsou na daném prvku provozovány: Tabulka 21 – Technické parametry HW

Prvek

Výkon

WWW klient 1 x PIV a vyšší

RAM 256 MB

Aplikační a Intel / AMD 24 jádra integrační max. 8 GB služby Databázové služby (1

Disková kapacita

Sdílená disková kapacita

Síťové rozhraní

Rozlišení

10 MB

0 MB

1 Mbps

1024x768, High Color

50 GB

-

1 Gbps

1024x768, High Color

50 GB

150 GB(1

1 Gbps

1024x768, High Color

2 – 3 GHz Intel / AMD 24 jádra

max. 8 GB

2 – 3 GHz

Pro uložení záloh databáze

Serverová strana IS může být provozována ve virtuálním prostředí (Hyper-V, VMWare, apod.) 68

Serverová strana nabízeného řešení je spustitelná a schopná provozu ve virtuálním prostředí (Hyper-V, VMWare, apod.). Uvedené technické parametry umožňují splnění technických požadavků na IS, které jsou uvedeny v kapitole V. přílohy č. 1 smlouvy – Podrobná specifikace díla.

69

4. ADAPTABILITA IS NA NOVÉ PODMÍNKY A NÁROČNOST ROZŠÍŘENÍ IS V BUDOUCNU Zhotovitel bere na vědomí, že při realizaci níže uvedených rozšíření IS či jejich dílčích částí v rámci Služeb rozvoje dle článku 3.3.2 Smlouvy, bude při kalkulaci jejich pracnosti přihlédnuto k odhadům uvedeným v této tabulce v bodech 4.a) a 4.b) a Objednatel nebude případnou neúměrně vyšší kalkulaci pracnosti rozšíření oproti zde uvedeným odhadům akceptovat.

4.a Náročnost budoucích technických údajů

úprav

číselníků

a

formulářů

evidence

Modelová situace: Odhad pracnosti úpravy řešení spočívající v přidání nového technického údaje do formuláře Evidence technických zařízení, kdy přidané datové pole nebude figurovat v žádných datových operacích s výjimkou zobrazení, editace a výmazu jeho hodnoty (tj. údaj v datovém poli bude sloužit pouze v rámci měněného formuláře). 1.

Pokud bude mít nově zařazovaný technický údaj povahu technického parametru zařízení, bude jeho přidání provedeno na uživatelské úrovni bez nutnosti programování. Správci zařízení budou vyškoleni pro řešení těchto situací.

Pracnost Uchazeče je v takovýchto případech 0 minut. 2.

Pokud nově zařazovaný technický údaje nebude možno z důvodu jeho povahy zařadit do technických parametrů výše popsaným způsobem, přidání nového údaje zajistí Uchazeč. Kalkulace pracnosti tohoto modelového případu je v následující tabulce.

Tabulka 22 – Odhad pracnosti úpravy řešen přidáním nového technického údaje nefigurujícího v datových operacích

Poř. Činnost Pracnost Rozšíření datové struktury příslušné datové třídy o nový atribut 1. 5 min v analytickém CASE nástroji. Úprava uživatelského rozhraní formuláře v designerském 2 5 min nástroji (umístění nového údaje do podoken Seznam a Detail). Export modelu obsahujícího metadata pro transformace 3. 5 min uživatelského rozhraní a předefinování databázových struktur. Pracnost celkem 15 min Pracnost Uchazeče je v takovýchto případech 15 minut. Modelová situace: Odhad pracnosti úpravy řešení spočívající v přidání nového údaje do příslušného formuláře, kdy přidané datové pole bude figurovat v dalších datových operacích a bude jej nutno zohlednit při operacích třídění, filtrování a generování výstupů IS. Odhad pracnosti v této modelové situaci je složitější než v předcházejícím případě, jelikož není známa složitost a počet datových operací, ve kterých má nový údaj figurovat.

70

Například odhad pracnosti jednoho zadaného změnového řízení na úpravu řešení spočívající v přidání jednoho nového údaje, který bude figurovat ve třech průměrně složitých datových operacích, vypadá takto:

Tabulka 23 – Odhad pracnosti úpravy řešení přidáním nového údaje figurujícího ve třech datových operacích

Poř. Činnost

1.

2

3 4.

5.

Rozšíření datové struktury příslušné datové třídy o nový atribut v analytickém CASE nástroji. Úprava uživatelského rozhraní formuláře v designerském nástroji (umístění nového údaje do podoken Seznam a Detail). Analýza datové operace, tvorba analytického zadání datové operace a programování na základě zadání. Příprava dat a provedení testů.

Jednotka odhadu

Prac / JedOdh

Počet Pracnost JedOdh celkem

nový údaj

5 min

1

5 min

nový údaj

5 min

1

5 min

datová operace

15 min

3

45 min

datová operace

10 min

3

30 min

5 min

1

5 min

Export modelu obsahujícího metadata pro transformace uživatelského změnové rozhraní, předefinování databázových řízení struktur a aktualizace aplikačního programového kódu. Pracnost celkem

90 min

Pozn.: Operace zahrnutí nového atributu do třídění, filtrování, uživatelských reportů nevyžadují ze strany Uchazeče žádnou pracnost, jelikož uživatelské prostředí nabízeného řešení obsahuje nástroje pro nastavení těchto operací koncovými uživateli případně administrátory. Používání těchto nástrojů je podrobně popsáno v rámci hodnotícího subkritéria Přívětivost uživatelského prostředí v částech Přizpůsobení pořadí sloupců, Nastavení nového filtru a Nastavení nových pravidel třídění nad uživatelským prostředím a v rámci subkritéria Možnost uživatelského nastavení reportů, sestav a výkazů v části Vytvoření nové šablony uživatelské sestavy. Z uvedeného příkladu odhadu pracnosti vyplývá, že:  Odhad pracnosti činností č. 1. a 2. je závislý na počtu nových atributů; 

Odhad pracnosti činností č. 3. a 4 je závislý na počtu datových operací s těmito atributy;



Odhad pracnosti činnosti č. 5 je závislý na počtu separátně zadaných výběrových řízeních.

Obecné vyjádření odhadu pracnosti požadavků na změny dle této modelové situace je uvedeno v následující tabulce.

71

Tabulka 24 - Obecné vyjádření odhadu pracnosti jednoho změnového řízení

Poř. Činnost

1.

2

3 4.

5.

Rozšíření datové struktury příslušné datové třídy o nový atribut v analytickém CASE nástroji. Úprava uživatelského rozhraní formuláře v designerském nástroji (umístění nového údaje do podoken Seznam a Detail). Analýza datové operace, tvorba analytického zadání datové operace a programování na základě zadání. Příprava dat a provedení testů.

Jednotka odhadu

Prac / JedOdh

Počet Pracnost JedOdh celkem

nový údaj

5 min

m

m*5 min

nový údaj

5 min

m

m*5 min

datová operace

15 min

n

n*15 min

datová operace

10 min

n

n*10 min

5 min

1

5 min

Export modelu obsahujícího metadata pro transformace uživatelského změnové rozhraní, předefinování databázových řízení struktur a aktualizace aplikačního programového kódu.

kde: m = celkový počet nových údajů n= celkový počet datových operací s těmito údaji Celková odhadovaná pracnost spočívající v přidání jednoho údaje (m = 1) v závislosti na počtu středně složitých operací je uvedena v následující tabulce: Tabulka 25 – Celková odhadovaná pracnost úprav dle počtu datových operací

Počet datových operací 1 2 3 … 5

Pracnost celkem 40 min 65 min 90 min … 140 min

4.b Náročnost budoucích úprav IS při jeho automatického sběru dat z měřicích zařízení

rozšíření

v oblasti

Funkcionalita automatického sběru dat z měřicích zařízení součástí nabízeného IS je připravena pro budoucí nasazení. Očekáváme pouze úpravy menšího rozsahu. Pracnost Uchazeče je v tomto případě odhadována na 10 člověkodnů.

72

Příloha č. 3: Seznam subdodavatelů Plnění této smlouvy je poskytováno výlučně Zhotovitelem bez využití subdodavatelů.

1

Příloha č. 4: Realizační tým

Jméno

Funkce Vedoucí realizačního týmu, hlavní architekt systému Zástupce vedoucího realizačního týmu, člen realizačního týmu – implementační konzultant Člen realizačního týmu – implementační konzultant, držitel certifikátu ITIL Člen realizačního týmu – implementační konzultant Člen realizačního týmu - analytik

RNDr. Petr Zeman, MBA Ing. Oto Petr Karel Zítek Ing. Miroslav Marek Ing. Miroslav Kábrt

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

Příloha č. 5: Podmínky plnění Služeb I. 1.1

ÚVODNÍ USTANOVENÍ

Tato příloha Smlouvy stanoví detailní podmínky plnění služeb dle článku 3.3 Smlouvy. II.

2.1

DEFINICE POJMŮ

Následující pojmy uvedené v této příloze, budou mít pro účely Smlouvy vždy následující význam:

Pojem Incident

Vada Požadavek (request)

Dostupnost

Definice pojmu pro účely Smlouvy Událost při využívání služby, která neprobíhá očekávaným způsobem a způsobuje, či může způsobit snížení kvality služby nebo její nedostupnost (např. SW chyby na IS, vzniklá nedostupnost dat, atp.). Vada je z pohledu této přílohy totožná s pojmem incident. Žádost ze strany uživatele služby o zabezpečení podpory při využívání služby předaná na ServiceDesk Zhotovitele, která nemá příčinu v chybovém stavu služby, tj. není incidentem (např. žádost o práce, materiál nebo informace poskytované Zhotovitelem ke službě) Skutečnost, že IS je přístupný a použitelný ve sjednanou dobu a požadovaným způsobem – udává se jako procento skutečného času běhu IS z celkové požadované doby běhu IS. IS je označen jako nedostupný v případě nedostupnosti IS jako celku nebo nejsou dostupné podstatné dílčí části IS. Za nedostupný se IS považuje od okamžiku nahlášení Objednatelem nebo zjištění Zhotovitele do okamžiku obnovení plné dostupnosti. Dostupnost je vztažena ke kalendářnímu čtvrtletí. Pro výpočet doby nedostupnosti jsou časy zaokrouhleny na celé minuty. Do doby nedostupnosti se započítávají všechny doby incidentů a odstávek.

Doba provozu

Nedostupnost způsobená prokazatelně třetí stranou se nezapočítává. Doba, v rámci které je poskytována daná služba. Doba provozu je 1

Doba reakce na incident

Doba vyřešení incidentu

dále členěna na:  Provozní doba poskytování služby – Označuje dny v týdnu a hodiny ve dni, kdy je služba poskytována. Např. 7x24 znamená pracovní i nepracovní dny 24 hodin denně; 5x12 znamená pracovní dny 12 hodin denně (např. 8:00-18:00)  Servisní okno údržby – Doba, kdy je Zhotovitel oprávněn provádět plánované servisní zásahy na IS. Maximální doba, která uplyne od okamžiku nahlášení incidentu uživatelem na ServiceDesk a okamžikem zahájení jeho řešení. Incidenty, které nebudou řešeny řešitelem první úrovně (operátor ServiceDesku), musí být v této době předány skupině řešitelů vyšší úrovně. Sjednaná hodnota parametru se definuje v popisu služby v celých hodinách. Maximální doba, která uplyne od okamžiku nahlášení incidentu na ServiceDesk do okamžiku nastavení požadovaného stavu řešitelem a oznámení ukončení řešení uživateli. V případě, že uživatel není s řešením spokojen, znovu se otevírá incident k novému řešení. Doba řešení nemusí být dodržena v případě:  že se jedná o známé chyby a nedodělky, které byly známy při předání projektu a dosud nebyly vyřešeny.  chyby, které mají příčinu v chybné činnosti uživatele (např. spouštění výpočtů v nesprávných termínech) pokud tato příčina není způsobena chybou v IS.

Čtvrtletní výkaz kvality plnění

MD

Úroveň podpory (L1, L2,L3)

Sjednaná hodnota parametru se definuje v popisu služby v celých hodinách. Výkaz sestavený Zhotovitelem v ServiceDesku. Výkaz je předložen Objednateli k odsouhlasení a podepsán oběma smluvními stranami. Podepsaný výkaz slouží jakou souhlas Zhotovitele k uplatnění srážky z ceny Služeb. Výkaz je předkládán jako příloha k faktuře. Jedná se o jednotku kapacity, která definuje vynaloženou práci jednoho pracovníka za jeden pracovní den, který je tvořen 8 hodinami. L1 úroveň podpory = pracoviště ServiceDesk Zhotovitele zabezpečuje příjem resp. vstupní zpracování všech incidentů, požadavků, jejich prvotní kontrolu a předání řešitelům od autorizovaných interních uživatelů (tj. pracovníků Objednatele, řídících orgánů a dodavatelů souvisejících IT služeb).

2

L2 úroveň podpory = označuje první vrstvu řešitelů přijatého požadavku, incidentu. L3 úroveň podpory = označuje druhou vrstvu řešitelů, kteří provádějí vysoce specializované činnosti, např. metodickotechnické analýzy složitých problémů. Všechny záznamy procházející úrovněmi L1 až L3 budou vedeny v systému Service Desk.

Workflow (dále jen „WF“)

Řešitelé mohou být jak na straně Zhotovitele, tak na straně dodavatelů souvisejících IT služeb příp. řešitelských týmů Objednatele. Workflow označuje pracovní postup, který je definován jednotlivými aktivitami a stavy. III.

DEFINICE SLUŽEB

3.1

Níže uvedený katalog služeb obsahuje základní minimální parametry jednotlivých služeb. Předpokládá se, že katalog služeb bude při zachování rozsahu poskytovaných služeb dále detailněji rozpracován v rámci Fáze 2, kde budou rovněž detailně specifikovány související procesy řízení a poskytování služeb.

3.2

Rozsah služeb je dán výčtem činností definovaných v rámci jednotlivých Služeb.

3.3

Vymezení konkrétních Služeb upravených touto Smlouvou:

Označení SS SS01 SS02 SS03 SS04 SS05 SR SR01 SŠ SŠ01 3.4

Název Služby Servisní služby (dle bodu 3.3.1 písm. a) a b) Smlouvy) Technická podpora a údržba IS Zálohování IS Podpora správy uživatelů ServiceDesk Proškolení změn v IS Služby rozvoje (dle bodu 3.3.2 Smlouvy) Rozvoj IS Služby školení (dle bodu 3.3.3 Smlouvy) Školení uživatelů IS

Detailní specifikace obsahu Servisních služeb: 3.4.1

Označení SS01

Služba „SS01_Technická podpora a údržba IS“ Název služby Technická podpora a údržba IS

3

Seznam činností Opravy chyb

Monitoring dostupnosti Optimalizace chodu

Součinnost

Technologický upgrade

„Oprava chyb“ se vztahuje na realizaci všech dílčích činností, které jsou nezbytné pro odstranění dané chyby. Jedná se například, nikoliv však výlučně, o činnosti související s analýzou chyby, úpravou analytických modelů, programování zdrojového kódu, testování, instalace na testovací a produkčních prostředí a implementace. Opravy chyb se vztahují na všechny technologické části (grafické uživatelské rozhraní (dále jen „GUI“), aplikační logika, data) dané logické části IS. Opravy chyb se vztahují i na SW třetích stran, který je nedílnou součástí dané aplikační části (jedná se např. o komponenty ovládacích prvků, reportovací nástroje apod.) a nemá povahu standardního systémového SW. Sledování a vyhodnocování kritických parametrů IS s cílem minimalizovat výpadky IS z důvodu chyb systémové infrastruktury. “Optimalizace chodu” zahrnuje dílčí činností související s úpravami IS (změny programového kódu, indexace, změny datového modelu, změny konfigurací, apod.) s cílem udržet požadované výkonnostní parametry dané logické části IS. Optimalizace chodu se vztahuje na všechny technologické části (GUI, aplikační logika, data) dané logické části IS. V rámci poskytování „součinnosti“ zajistí Zhotovitel vzájemnou spolupráci (komunikaci, poskytování informací, účast na jednáních, atd.) s dodavatelem a provozovatelem cílové infrastruktury k dosažení a udržení vzájemné vnitřní kompatibility celého IS a dále „vnější“ kompatibility s programovým vybavením koncových uživatelských stanic. Realizace technologických opatření (upgrade na vyšší verzi, případně nižší verzi) vyplývající z monitoringu a poskytované součinnosti. Technologický upgrade se vztahuje na realizaci všech dílčích činností, které jsou nezbytné pro odstranění technologické nekonzistentnosti. Jedná se například, nikoliv však výlučně, o činnosti související s analýzou, úpravou analytických modelů, programování zdrojového kódu, testování, instalace na testovací a produkčních prostředí a implementace. Technologický upgrade se vztahuje na všechny technologické části (GUI, aplikační logika, data) dané logické části IS. Technologický upgrade se vztahuje také na SW třetích stran, který je nedílnou součástí dané aplikační části (jedná se např. o komponenty ovládacích prvků, reportovací nástroje apod.) a nemá povahu standardního systémového SW. Činnost zahrnuje také koordinaci technologického upgrade dodavatelů externích informačních systémů napojených na IS Zhotovitele (tj. například vytvoření specifikací resp. požadavků při řešení integračních vazeb na ekonomický informační systém).

4

Legislativní upgrade

Zhotovitel je povinen v rámci legislativního upgrade realizovat změny systému vyplývající ze změn relevantních právních aktů, které se vážou k použitým informačním a komunikačním technologiím (dále jen „ICT“) a externím rozhraním. Legislativní upgrade se nevztahuje na změny, které vyplynou ze změny metodiky nebo, které souvisí se změnou business procesů na straně Objednatele nebo, které souvisí se zavedením zcela nové legislativní úpravy. Sledováním relevantních změn legislativy je pověřen Objednatel, který je povinen na potřebu realizace legislativního upgrade Zhotovitele upozornit a to formou zadání požadavku v ServiceDesku. Změny „Změny konfigurace“ zahrnují dílčí činnosti související se změnou konfigurace parametrů IS, které nemají povahu změny programového kódu a které si nebude Objednatel vykonávat sám prostřednictvím vlastních pracovníků. Jedná se například o činnosti související se změnou WF, povinností naplněnosti a viditelností polí formulářů či změnou filtrů. Změny konfigurace budou realizovány vždy, pokud nestanoví Objednatel jinak, nejdříve na testovacím a následně na produkčním prostředí IS. Součástí dílčích činností je i aktualizace testovacího prostředí v takovém rozsahu, aby bylo možné efektivním způsobem ověřit správnost prováděných změn konfigurace. Dokumentace „Dokumentace” zahrnuje aktualizaci bezpečnostní, systémové, administrátorské a uživatelské dokumentace tak, aby tato dokumentace vždy odrážela s minimálním zpožděním aktuální rozsah a nastavení IS. Podmínky provádění činností Objednatel požaduje provádění všech výše definovaných činností v takovém rozsahu, aby byla zachována požadovaná dostupnost IS. V případě, že provádění činností vyžaduje odstávku IS, je Zhotovitel oprávněn provádět dané činností pouze v předem stanoveném servisním okně. Toto servisní okno je v pracovních dnech v čase 18:00 – 06:00 a o víkendech po celý den. Další, mimořádná servisní okna jsou možná pouze na základě předchozího souhlasu Objednatele. Zhotovitel bude vykonávat dohledové činnosti nad provozem celého IS. Zhotovitel bude mít pasivní práva k monitoringu vybraných částí cílové infrastruktury k zajištění tohoto požadavku. V případě zjištění jakékoliv závady / problému v průběhu monitoringu bude Zhotovitel automaticky generovat tickety do ServiceDesku, včetně správného rozřazení dle kompetencí (tzn. incident „nedostupnost serveru“ bude automaticky přidělen k řešení provozovateli cílové infrastruktury.) Rozsah monitorovaných dat navrhne Zhotovitel a pro potřeby rutinního provozu bude odsouhlasen Objednatelem. V průběhu účinnosti této Smlouvy může být rozsah upravován po odsouhlasení obou smluvních stran. Objednatel požaduje vedení podrobné provozní dokumentace o rozsahu pravidelných i nepravidelných prací s uvedením jména nebo kódu pracovníka, který činnosti prováděl a časovým razítkem. Provozní dokumentace bude vedena ve formě záznamů do ServiceDesku v dostatečném rozsahu pro potřeby vyhodnocení kvality služby a dokumentace systému.

5

Zhotovitel je povinen zaznamenat příslušnou informaci do ServiceDesku nejpozději do 1 dne od jejího výskytu a průběžně aktualizovat její stav vzhledem k jejímu vývoji. Realizaci technologického upgradu dané logické části IS bude co do rozsahu, tak i termínu (aby nedošlo ke kolizi například s účetní závěrkou) schvalovat odpovědný pracovník Objednatele. Kontrolu prováděných akcí bude provádět Objednatel nebo jím určená třetí osoba. Objednatel požaduje provedení aktualizace dokumentace IS tak, aby odpovídala aktuálnímu stavu IS po provedení jeho úpravy nejpozději do 14 kalendářních dnů od provedení této úpravy. Obsah plnění Rozsah plnění ze strany Zhotovitele bude zahrnovat: a) Veškeré licenční poplatky spojené s údržbou technologií a komponent, které byly použity pro realizaci nabízeného řešení dle licenční politiky příslušných výrobců/dodavatelů; b) Náklady na pracovníky Zhotovitele, kteří budou zajišťovat požadované činnosti; c) Ostatní náklady související se zajištěním definovaných činností; Rozsah činností Objednatel požaduje následující rozsah činností: Opravy chyb Opravy chyb jsou dány aktuální potřebou IS a budou realizovány bez časového, věcného a množstevního omezení. Monitoring Objednatel požaduje zajistit monitorování dostupnosti kritických dostupnosti parametrů v takovém rozsahu, který umožní identifikovat výpadek služeb nejpozději do 30 minut od jeho výskytu. Zhotovitel je povinen předat vyhodnocený incident (tzn. incident prověřený pracovníkem Zhotovitele) příslušnému řešiteli nejpozději do 120 minut od jeho výskytu. Optimalizace Úpravy IS jsou dány aktuální potřebou IS a budou realizovány bez chodu časového, věcného a množstevního omezení. Součinnost Objednatel předpokládá poskytnutí součinnosti v minimálním rozsahu 2 MD za jeden kalendářní rok. Technologický Objednatel předpokládá min. 1 technologický upgrade za jeden upgrade kalendářní rok. Opravné balíčky typu update budou aplikovány v rozsahu definovaném technologickou politikou daného výrobce. Legislativní Rozsah legislativního upgradu bude dán aktuálními potřebami upgrade vyplývajícími z platné legislativy. Změny Změny nastavení IS (parametrizace WF, nastavení podmínek, apod.) konfigurace dle potřeb Objednatele v min. rozsahu 10 změn za každé kalendářní čtvrtletí. Dokumentace Objem pracnosti aktualizace dokumentace je dán objemem provedených úprav v IS a aktualizace dokumentace bude realizována bez časového, věcného a množstevního omezení. „Technická podpora a údržba IS“ bude Zhotovitelem zajišťována jako paušální plnění, což znamená, že Zhotovitel bude zajišťovat potřebné činnosti v takovém rozsahu, který bude nezbytný pro dosažení všech kvalitativních parametrů příslušné služby. 6

Provozní doba poskytování služby Služba “Technická podpora a údržba IS” bude poskytována v režimu 5x12 (v pracovní dny mimo státní svátky a dny pracovního volna od 06:00 do 18:00). Pouze činnosti vyžadující odstávku IS budou provedeny v rámci definovaných servisních oken. Reakční lhůty pro poskytování služby Reakce na Typ požadavků Doba Doba vyřešení požadavky odezvy Standard (předem definovaný Do 12 hod. Bude stanovena požadavek se standardizovaným individuálně postupem řešení) Nestandard (unikátní požadavek bez Do 24 hod. Bude stanovena standardizovaného postupu řešení) individuálně Reakční lhůta běží v provozní dobu poskytování služby a začíná od okamžiku zapsání požadavků oprávněnou osobou do ServiceDesku. Reakční lhůty na vyřešení požadavku se vztahují na všechny činnosti nutné pro vyřešení požadavku v produkčním prostředí, pokud Objednatel v daném případě nestanovil jinak. 3.4.2

Služba „SS02_Zálohování IS“

Označení Název služby SS02 Zálohování IS Seznam činností Zálohování „Zálohování” zahrnuje tvorbu zálohovacího plánu s identifikací datových aktiv (data i SW), stanovením maximální doby ztráty dat a definicí zálohovacích postupů a dále samotné provádění pravidelných záloh dle zálohovacího plánu. Dále bude prováděna kontrola zálohy a test obnovitelnosti dat ze zálohy. Obnova IS po „Obnova IS po pádu“ zahrnuje provádění testu obnovy IS po pádu ze pádu zálohy a v případě skutečné havárie a následného pádu IS provedení jeho obnovy. Podmínky provádění činností Objednatel požaduje provádění všech výše definovaných činností v takovém rozsahu, aby byla plně garantována integrita záloh dat i SW komponent IS a jejich využitelnost v případě potřeby s povolenou ztrátou dat pouze v rozsahu stanoveném zálohovacím plánem. Zhotovitel bude provádět kontroly záloh, testy obnovy dat ze záloh a testy obnovy IS po pádu minimálně v požadovaném rozsahu stanoveném níže, avšak je oprávněn je provádět i častěji k zajištění zde požadované garance. V případě, že provádění činností vyžaduje odstávku IS, je Zhotovitel oprávněn provádět dané činnosti pouze v předem stanoveném servisním okně. Toto servisní okno je v pracovních dnech v čase 18:00 – 06:00 a o víkendech po celý den. Další, mimořádná servisní okna jsou možná pouze na základě předchozího souhlasu Objednatele.

7

Obsah plnění Rozsah plnění ze strany Zhotovitele bude zahrnovat: a) Veškeré licenční poplatky spojené s údržbou technologií a komponent, které byly použity pro realizaci nabízeného řešení dle licenční politiky příslušných výrobců/dodavatelů; b) Náklady na pracovníky Zhotovitele, kteří budou zajišťovat požadované činnosti; c) Ostatní náklady související se zajištěním definovaných činností; Rozsah činností Objednatel požaduje následující rozsah činností: Zálohování Záloha bude prováděna v intervalu dle oboustranně schváleného zálohovacího plánu. Kontrola zálohy a test obnovitelnosti dat ze zálohy bude proveden minimálně 1x ročně s tím, že první kontrola a test budou provedeny nejpozději do 1 měsíce po zahájení poskytování služby resp. po akceptaci IS jako celku na konci Fáze 2. Obnova IS po Test obnovy IS po pádu ze zálohy bude proveden minimálně 1x ročně pádu s tím, že první kontrola a test budou provedeny nejpozději do 1 měsíce po zahájení poskytování služby resp. po akceptaci IS jako celku na konci Fáze 2. Obnova IS po pádu v případě skutečné havárie bude provedena v reakčních lhůtách uvedených níže. „Zálohování IS“ bude Zhotovitelem zajišťováno jako paušální plnění, což znamená, že Zhotovitel bude zajišťovat potřebné činnosti v takovém rozsahu, který bude nezbytný pro dosažení všech kvalitativních parametrů příslušné služby. Provozní doba poskytování služby Služba “Zálohování IS” bude poskytována v režimu 5x12 (v pracovní dny mimo státní svátky a dny pracovního volna od 06:00 do 18:00). Pouze činnosti vyžadující odstávku IS budou provedeny v rámci definovaných servisních oken. Reakční lhůty pro poskytování služby Obnova Typ požadavků Doba odezvy Doba vyřešení IS po Obnova IS po pádu v případě nezavinění Do 4 hod. od Do 48 hod. od pádu havárie, která byla příčinou pádu IS, vyhlášení ukončení trvání Zhotovitelem havarijního příčin havarijního stavu stavu Objednatelem Obnova IS po pádu v případě zavinění Do 2 hod. od Do 24 hod. od havárie, která byla příčinou pádu IS, pádu IS pádu IS Zhotovitelem, nebo v případě pádu IS v důsledku vad IS. Reakční lhůta běží v provozní dobu poskytování služby a začíná od okamžiku vyhlášení havarijního stavu Objednatelem, resp. od pádu IS. 3.4.3 Označení SS03

Služba „SS03_Podpora správy uživatelů“ Název služby Podpora správy uživatelů

8

Seznam činností Správa uživatelů a jejich identit

V rámci „správy uživatelů a jejich identit“ zajistí Zhotovitel minimálně tyto činnosti:  Registrace uživatelů  Kontrola požadavků žadatelů a administrace registrací v souladu s postupy pracovníků Objednatele, kteří provádí schvalování.  Zřízení uživatele a vytvoření uživatelského účtu  Administrace oprávnění  Reset hesla Vedení seznamu V rámci „Vedení seznamu administrátorů“ zajistí Zhotovitel zřízení a administrátorů průběžnou aktualizaci seznamu administrátorů v prostředí ServiceDesku. Podmínky provádění činností Objednatel požaduje, aby Zhotovitel vedl jmenovitý seznam všech pracovníků s právy na úrovni administrátorských práv k IS. Personálně se jedná zejména o administrátory Zhotovitele a administrátory Objednatele. U každé osoby bude přesně popsán rozsah práv a typ práv (čtení, zápis, konfigurace, změna parametrů a podobně). U každé osoby bude uvedeno jméno, příslušnost k Zhotoviteli či Objednateli a společnost, jejímž je zaměstnancem. Objednatel požaduje, aby seznam administrátorů byl veden v rámci řešení ServiceDesk, byl přehledný a srozumitelný a měl dostatečnou informační hodnotu. Objednatel požaduje, aby požadavky na řízení uživatelských účtů a správy identit byly realizovány skrze procesy řízení incidentů/požadavků, které budou realizovány v rámci řešení ServiceDesk. Administrátor IS na straně Objednatele bude primárně provádět činnosti spojené s vytvořením běžného uživatelského účtu a přiřazením příslušné skupiny oprávnění novému uživateli (bez možnosti přidělení administrátorských oprávnění). Zhotovitel bude primárně provádět činnosti spojené s vytvořením účtů se specifickým oprávněním (například pro administrátory IS) a bude vytvářet nové skupiny oprávnění dle požadavků Objednatele. Objednatel však výše uvedeným zamýšleným rozdělením kompetencí nepřichází o právo požadovat i provedení činností přiřazených jeho administrátorům po Zhotoviteli, který je povinen takový požadavek splnit dle podmínek stanovených touto Smlouvou. Obsah plnění Rozsah plnění ze strany Zhotovitele bude zahrnovat: a) Náklady na technické a materiální vybavení nezbytné pro činnost pracoviště ServiceDesk b) Náklady na licenční poplatky související s využitím autorským práv k dílům, které jsou nutné pro činnost pracoviště ServiceDesk c) Personální náklady na pracovníky Zhotovitele, kteří budou zajišťovat požadované činnosti

9

Rozsah činností Objednatel požaduje následující rozsah činností: Správa uživatelů a jejich identit Objednatel požaduje odbornou kapacitu pro řízení správy uživatelů a jejich identit v minimálním rozsahu 50 aktivních uživatelů z řad Objednatele. Vedení seznamu Objednatel požaduje pro činnosti související s vedením administrátorů seznamu administrátorů odbornou kapacitu v minimálním rozsahu 1MD za jedno kalendářní čtvrtletí za celý IS. Služba „Podpora správy uživatelů“ bude Zhotovitelem zajišťována jako paušální plnění, což znamená, že Zhotovitel bude zajišťovat potřebné činnosti v takovém rozsahu, který bude nezbytný pro dosažení všech kvalitativních parametrů příslušné služby. Provozní doba poskytování služby Služba „Podpora správy uživatelů“ bude poskytována v režimu 5x8 (v pracovní dny mimo státní svátky a dny pracovního volna od 08:00 do 16:00). Reakční lhůty pro poskytování služby Reakce na Typ požadavků Doba Doba vyřešení požadavky odezvy Registrace uživatelů, zřízení uživatele Do 2 hod. Do 8 hod. a vytvoření uživatelského účtu, administrace oprávnění, reset hesla Aktualizace seznamu administrátorů Do 16 hod. Do 32 hod. Reakční lhůta běží v provozní dobu poskytování služby a začíná od okamžiku zapsání požadavků oprávněnou osobou do ServiceDesku. Reakční lhůty na vyřešení požadavku se vztahují na všechny činnosti nutné pro vyřešení požadavku v produkčním prostředí, pokud Objednatel v daném případě nestanovil jinak. 3.4.4

Služba „SS04_ServiceDesk“

Označení SS04 Seznam činností Řízení incidentů a požadavků

Název služby ServiceDesk V souladu s doporučením standardu ITIL zajistí Zhotovitel řízení incidentů a požadavků minimálně v tomto rozsahu:  Příjem incidentů a požadavků (requestů) a změnových požadavků.  Koordinace schvalovacího procesu,  Přidělení požadavku řešiteli nebo schvalovateli podle definovaného WF.  Sledování a koordinace řešení incidentů, požadavků (requestů) a změnových požadavků.  Ověřování úspěšného vyřešení incidentů a požadavků (request).  Uzavírání incidentů, požadavků (requestů) a změnových požadavků.

10

Řízení problémů

V souladu s doporučením standardu ITIL zajistí Zhotovitel řízení problémů minimálně v tomto rozsahu:  Vytvoření problému z opakujících se incidentů nebo na základě požadavku.  Dekompozice problému na dílčí úkoly.  Přiřazení úkolů řešiteli nebo skupině řešitelů.  Uzavření problému a jeho následná archivace. Odhad pracnosti Jedná se o zpracování jednoduché kalkulace pracnosti rámcové rámcové analýzy analýzy a stanovení závazného termínu dodání rámcové analýzy pro realizaci změn IS v rámci služby Rozvoj IS. Odhad pracnosti rámcové analýzy podléhá schválení Objednatelem, který v případě souhlasu s výsledky odhadu zadá nový požadavek na zpracování rámcové analýzy. Výkaznictví Předmětem výkaznictví je realizace výstupů pro efektivní řízení servisních služeb definovaných v rámci tohoto katalogu, zejména podklady pro pravidelnou fakturaci. Výkon role Zajištění výkonu role ServiceDesk pro realizaci výše uvedených ServiceDesk činností. Podmínky provádění činností Příjem incidentů a požadavků (requestů) a změnových požadavků umožní Zhotovitel prostřednictvím definovaných kanálů. Každý incident a požadavek bude zaznamenán do aplikace ServiceDesk v souladu se stanoveným postupem a náležitostmi. Zhotovitel zajistí přidělení požadavku (request) nebo změnového požadavku správnému schvalovateli. O založení nového požadavku čekajícího na schválení bude schvalovatel notifikován (např. SMS, email, apod.). Přiřazení incidentů, požadavků (requestů) a změnových požadavků správnému řešiteli bude realizováno na základě daného typu požadavku a příslušné sady WF. O založení nového požadavku čekajícího na řešení bude řešitel notifikován (např. SMS, email, apod.). Zhotovitel zajistí příslušnou informovanost původce požadavků, změnových požadavků a incidentů o stavu řešení a to prostřednictvím dohodnutého komunikačního kanálu, preferovaně přímo pomocí aplikace ServiceDesk. Obsah plnění Rozsah plnění ze strany Zhotovitele bude zahrnovat: a) Náklady na technické a materiální vybavení nezbytné pro činnost pracoviště ServiceDesk b) Náklady na licenční poplatky související s využitím autorským práv k dílům, které jsou nutné pro činnost pracoviště ServiceDesk c) Personální náklady na pracovníky Zhotovitele, kteří budou zajišťovat požadované činnosti Rozsah činností Objednatel požaduje následující rozsah činností:

11

Řízení incidentů a požadavků

Objednatel požaduje odbornou kapacitu pro řízení incidentů a požadavků v minimálním rozsahu 100 požadavků za jedno kalendářní čtvrtletí za celý IS. Řízení problémů Objednatel požaduje odbornou kapacitu pro řízení problémů v minimálním rozsahu 10 problémů za jedno kalendářní čtvrtletí za celý IS. Odhad pracnosti rámcové Objednatel předpokládá provedení jednotek odhadů za analýzy kalendářní čtvrtletí. Výkaznictví Objednatel požaduje pro činnosti související s výkaznictvím odbornou kapacitu v minimálním rozsahu 3MD za jedno kalendářní čtvrtletí za celý IS. Výkon role ServiceDesk Objednatel požaduje pro činnosti související s výkonem role ServiceDesk odbornou kapacitu v minimálním rozsahu 90MD za jedno kalendářní čtvrtletí za celý IS. Služba „ServiceDesk“ bude Zhotovitelem zajišťována jako paušální plnění, což znamená, že Zhotovitel bude zajišťovat potřebné činnosti v takovém rozsahu, který bude nezbytný pro dosažení všech kvalitativních parametrů příslušné služby. Provozní doba poskytování služby Služba „ServiceDesk“ bude poskytována v režimu 5x12 (v pracovní dny mimo státní svátky a dny pracovního volna od 06:00 do 18:00). Reakční lhůty pro poskytování služby Reakce na Typ požadavků Doba Doba vyřešení požadavky odezvy Standard (předem definovaný Viz typy požadavků definované požadavek se standardizovaným u jednotlivých služeb postupem řešení, který je uveden v katalogu služeb) Universal (předem definovaný Do 12 hod. Bude stanovena požadavek se standardizovaným individuálně postupem řešení, který není uveden v katalogu služeb) Nestandard (unikátní požadavek bez Do 24 hod. Bude stanovena standardizovaného postupu řešení) individuálně Požadavek na odhad pracnosti Do 12 hod. Do 36 hod. rámcové analýzy Reakce na Kategorie A – Incident má kritický Do 2 hod. Do 12 hod. incidenty dopad do funkčnosti IS či jeho části, nebo znemožňuje užívání IS či jeho části Objednatelem nebo způsobuje vážné provozní problémy IS. Kategorie B – Incident způsobující Do 6 hod. Do 36 hod. zhoršení výkonnosti a funkčnosti IS nebo jeho části, IS nebo jeho část má omezení nebo je částečně nefunkční. Incident nespadá do kategorie A.

12

Kategorie C – Incident s minimálním Do 12 hod. Bude stanovena dopadem na funkcionality či celkovou individuálně funkčnost IS nebo jeho části. Incident nespadá do kategorie A nebo B. Reakční lhůta běží v provozní dobu poskytování služby a začíná od okamžiku zapsání požadavků oprávněnou osobou do ServiceDesku. Reakční lhůty se vztahují na všechny činnosti nutné ke správnému zajištění procesů, do kterých je ServiceDesk zapojen. 3.4.5

Služba „SS06_Proškolení změn v IS“

Označení SS06 Seznam činností Proškolení změn v IS

Název služby Proškolení změn v IS

V návaznosti na provedené změny v IS v rámci služby „Technická podpora a údržba IS“, zejména v rámci činností „Technologický upgrade“ a „Legislativní upgrade“ zajistí Zhotovitel jednorázové proškolení Objednatelem určené skupiny uživatelů s cílem představit dopady provedených změn v IS na jeho obsluhu a využití. Podmínky provádění činností Zhotovitel zajistí dostatečnou disponibilní kapacitu odborníků, kteří provedou proškolení. Pokud provedené změny v IS nemají dopad na způsob obsluhy a využití IS, není nutné proškolení provádět. Změny v IS provedené v rámci služby Rozvoj IS budou školeny v rámci služby Školení uživatelů IS na základě objednávky Objednatele. Obsah plnění Rozsah plnění ze strany Zhotovitele bude zahrnovat: a) Náklady na technické a materiální vybavení nezbytné pro činnost Proškolení změn v IS b) Náklady na licenční poplatky související s využitím autorským práv k dílům, které jsou nutné pro činnost Proškolení změn v IS c) Personální náklady na pracovníky Zhotovitele, kteří budou zajišťovat požadované činnosti Rozsah činností Objednatel požaduje následující rozsah činností: Proškolení změn v IS Zhotovitel zajistí školící činnosti v rozsahu odpovídajícím provedeným změnám v IS. Služba „Proškolení změn v IS“ bude Zhotovitelem zajišťována jako paušální plnění, což znamená, že Zhotovitel bude zajišťovat potřebné činnosti v takovém rozsahu, který bude nezbytný pro dosažení všech kvalitativních parametrů příslušné služby. Provozní doba poskytování služby Služba „Proškolení změn v IS“ bude poskytována v režimu 5x8 (v pracovní dny mimo státní svátky a dny pracovního volna od 08:00 do 16:00).

13

Reakční lhůty pro poskytování služby Reakce na Typ požadavků Doba Doba vyřešení požadavky odezvy Realizace proškolení změn v IS Do 8 hod. Do 40 hod. Reakční lhůta běží v provozní dobu poskytování služby a začíná od okamžiku nasazení realizované změny v IS do provozního prostředí. 3.5

Detailní specifikace obsahu Služeb rozvoje: 3.5.1

Služba “SR01_Rozvoj IS“

Označení Název služby SR01 Rozvoj IS Seznam činností Zpracování Jedná se o činnosti související s vypracováním rámcové analýzy na rozvoj IS. rámcové Součástí rámcové analýzy bude sběr požadavků, jejich rámcová analýza, analýzy konceptuální návrh jejich řešení včetně možných alternativ, kalkulace pracnosti, předpokládaný harmonogram a hrubá analýza rizik spojená s realizací/zamítnutím dotčeného rozvoje IS. Realizace Realizace rozvoje IS dle schválených rozvojových požadavků. rozvoje IS Rozvoj IS se vztahuje na realizaci všech dílčích činností, které jsou nezbytné pro změnu či zavedení nové funkcionality. Jedná se například, nikoliv však výlučně, o činnosti související s analýzou, úpravou analytických modelů, programování zdrojového kódu, testování, instalace na testovací a produkčních prostředí a implementace. Rozvoj IS se vztahuje na všechny technologické části (GUI, aplikační logika, data) dané logické části IS. Rozvoj IS se vztahuje také na SW třetích stran, který je nedílnou součástí dané aplikační části (jedná se např. o komponenty ovládacích prvků, reportovací nástroje apod.) a nemá povahu standardního systémového SW. Podmínky provádění činností Veškerý základní vývoj a testování změny bude probíhat dvojúrovňově – na vývojovém pracovišti Zhotovitele a teprve následně na testovacím / školícím prostředí Objednatele. Po řádném otestování Objednatel schvaluje harmonogram nasazení do ostrého / provozního prostředí. Zhotovitel současně zaznamenává všechny změny do dokumentace. Objednatel i Zhotovitel jsou povinni zaznamenávat veškeré aktivity (události, incidenty, požadavky, komentáře, atd.) související se službou „Rozvoj IS“ do ServiceDesku tak, aby bylo možné na jedné straně vyhodnotit jednotlivé parametry hodnocení služeb, na straně druhé měl Objednatel veškerou provozní dokumentaci na jednom místě. Zhotovitel je povinen zaznamenat příslušnou informaci do ServiceDesku nejpozději do 8 hodin od jejího výskytu a průběžně aktualizovat její stav vzhledem k jejímu vývoji. Realizaci aktivit služby „Rozvoj IS“ dané logické části IS budou co do rozsahu, tak termínu schvalovat odpovědní pracovníci Objednatele. Kontrolu prováděných akcí bude provádět Objednatel nebo jím najatá konzultační firma.

14

Za rozvoj IS se považují požadavky, jejichž realizace není prováděna v rámci „Technologického upgrade“ či „Legislativního upgrade“. Obsah plnění Rozsah plnění ze strany Zhotovitele bude zahrnovat: a) Náklady na technické a materiální vybavení související s definovanými činnostmi b) Náklady na licenční a servisní poplatky třetím stranám, které vyplývají z nasazení a použití SW třetích stran v rámci IS. c) Personální náklady na pracovníky Zhotovitele, kteří budou zajišťovat požadované činnosti d) Dopravní a cestovní náklady související s přepravou pracovníků Zhotovitele do místa realizace, pokud se toto místo nachází na území ČR. Rozsah činností Objednatel požaduje následující rozsah činností: Zpracování Objednatel předpokládá zpracování rámcových analýz rozsahu 2 MD za rámcové jedno kalendářní čtvrtletí za všechny logické části IS. analýzy Realizace Objednatel předpokládá objem realizace rozvoje IS v rozsahu 20 MD za rozvoje IS jedno kalendářní čtvrtletí za všechny logické části IS. Služba „Rozvoj IS“ bude Zhotovitelem zajišťována jako plnění na objednávku, což znamená, že Zhotovitel bude zajišťovat potřebné činnosti v takovém rozsahu, ve kterém budou na základě požadavků Objednatele a provedené rámcové analýzy potřeba. Rozsah plnění v oblasti zpracování rámcových analýz i realizace rozvoje IS bude ze strany Objednatele omezen pouze celkovým rámcem pracnosti, který činí 100 MD za celou dobu účinnosti Smlouvy. Objednatel není povinen tento rámcový rozsah vyčerpat a Zhotoviteli nepřísluší finanční kompenzace za nevyčerpané MD z tohoto rámcového rozsahu. Provozní doba poskytování služby Služba „Rozvoj IS“ bude poskytována v režimu 5x8 (v pracovní dny mimo státní svátky a dny pracovního volna od 08:00 do 16:00) vždy na základě dílčích požadavků Objednatele na zpracování rámcových analýz a objednávek Objednatele na realizaci rozvoje IS. Reakční lhůty pro poskytování služby Reakce na Typ požadavků Doba odezvy Doba vyřešení požadavky Požadavek na zpracování rámcové analýzy Do 8 hod. Bude stanovena individuálně dle složitosti požadavku Objednávka na realizaci rozvoje IS Do 8 hod. Bude stanovena individuálně v rámci rámcové analýzy Reakční lhůta běží v provozní dobu poskytování služby a začíná od okamžiku zapsání požadavků oprávněnou osobou do ServiceDesku resp. obdržení objednávky na realizaci rozvoje IS Zhotovitelem.

15

3.6

Detailní specifikace Služeb školení 3.6.1

Služba “SŠ01_Školení uživatelů“

Označení SŠ01 Seznam činností Příprava školení

Název služby Školení uživatelů

Příprava školení zahrnuje činnosti související s přípravou podkladových materiálů, vytvoření plánu školení, obeslání účastníků, zajištění lektora apod. Realizace školení Realizace školení zahrnuje činnosti související se zajištěním účasti lektora a vlastního proškolení uživatelů. Vyhodnocení Vyhodnocení školení zahrnuje činnosti související s vypracováním školení dokumentu zpětné vazby. Podmínky provádění činností Objednatel požaduje průběžné doškolování nových pracovníků, případně přeškolování stávajících. Jedná se zejména o školení interních uživatelů, administrátorů, metodiků, manažerů a dalších určených osob Objednatelem. Obsahem bude především školení nových funkcí IS doplněných v rámci rozvoje IS a školeních nových uživatelů IS, ale může mít i jiný, předem dohodnutý obsah. Objednatel požaduje komplexní zajištění, tedy včetně zajištění tištěných metodických materiálů. Objednatel navrhuje / odsouhlasuje termíny školení a jejich věcnou náplň, přičemž nenaplnění ze strany cílové skupiny není zohledňováno. Objednatel požaduje vypracovat dokument zpětné vazby (na základě dotazníků) od účastníků školení s průměrným celkovým hodnocením. Každé školení musí mít hodnocení lepší než 2,5 na stupnici 1 = velmi spokojen až 5 = velmi nespokojen. Obsah plnění Rozsah plnění ze strany Zhotovitele bude zahrnovat: a) Náklady na technické a materiální vybavení nezbytné pro zajištění požadovaných činností b) Náklady na licenční poplatky za použití autorský děl, které jsou použity pro účely školení c) Personální náklady na pracovníky Zhotovitele, kteří budou zajišťovat požadované činnosti d) Dopravní a cestovní náklady související s přepravou pracovníků Zhotovitele do místa školení, pokud se toto místo nachází na území ČR. Rozsah činností Objednatel požaduje následující rozsah činností:

16

Příprava školení Realizace školení Objednatel předpokládá realizaci 2 školení za jedno kalendářní čtvrtletí. Vyhodnocení školení Služba „Školení uživatelů IS“ bude Zhotovitelem zajišťována jako plnění na objednávku, což znamená, že Zhotovitel bude zajišťovat potřebné činnosti v takovém rozsahu, ve kterém budou objednány od Objednatele. Rozsah plnění bude ze strany Objednatele omezen pouze celkovým rámcem pracnosti, který činí 10 MD za celou dobu účinnosti Smlouvy. Objednatel není povinen tento rámcový rozsah vyčerpat a Zhotoviteli nepřísluší finanční kompenzace za nevyčerpané MD z tohoto rámcového rozsahu. Provozní doba poskytování služby Služba „Školení“ bude poskytována v režimu 5x8 (v pracovní dny mimo státní svátky a dny pracovního volna od 08:00 do 16:00). Reakční lhůty pro poskytování služby Reakce na Typ požadavků Doba Doba vyřešení požadavky odezvy Standard (předem definovaný Do 8 hod. Do 80 hod. požadavek se standardizovaným postupem řešení) Nestandard (unikátní požadavek bez Do 8 hod. Bude stanovena standardizovaného postupu řešení) individuálně Reakční lhůta běží v provozní dobu poskytování služby a začíná od okamžiku zapsání požadavků oprávněnou osobou do ServiceDesku. Reakční lhůta na vyřešení požadavku se vztahuje na všechny činnosti nutné pro vyřešení požadavku, pokud Objednatel v daném případě nestanovil jinak. IV.

HODNOCENÍ SLUŽEB

4.1

Hodnocení služeb bude probíhat formou vypočtení hodnot parametrů služeb, které vypovídají o úrovni skutečné kvality jejich poskytování Zhotovitelem ve vztahu k úrovni stanovené touto přílohou (dále jen „SLA parametry“ z anglického Service Level Agreement).

4.2

SLA parametr „Dostupnost služby“ bude vypočten následujícím způsobem: 4.2.1

Dostupnost služby či její dílčí činnosti v provozní době služby p (například 8:00 – 16:00) se vypočte podle vzorce:

kde: DS Hp Hi

dostupnost služby v provozní době služby p celkový počet minut v provozní době služby p za čtvrtletí počet minut nedostupnosti služby v provozní době služby p během incidentu i 17

N

4.3

počet nedostupností (incidentů) v provozní době služby p

4.2.2

Výsledná hodnota SLA parametru DS „Dostupnost služby“ je uváděna jako číslo v procentech, zaokrouhlena na jedno desetinné místo.

4.2.3

Pro Služby rozvoje a Služby školení není parametr „Dostupnost služby“ počítán.

SLA parametr „Reakční doba na incident“ bude vypočten následujícím způsobem: 4.3.1

Reakční doba na incident se počítá pro každou kategorii incidentu A, B a C zvlášť vzorcem:

kde: Rx N Tp Ts

relativní plnění reakční doby incidentu v kategorii x (A, B, nebo C) celkový počet incidentů v dané kategorii x za čtvrtletí reakční doba požadovaná (tj. stanovená v článku III. u popisu služby SS04_ServiceDesk) reakční doba skutečná

4.3.2

V případech kdy vypočtený parametr Rx dosáhne hodnot nižších než 0, bude pro účely dalších výpočtů roven 0.

4.3.3

Parametr Rx představuje relativní plnění požadované reakční doby incidentů z pohledu prodloužení skutečné reakční doby oproti době požadované. V případě, kdy skutečná reakční doba u všech incidentů za čtvrtletí nepřesáhne reakční dobu stanovenou v článku III. u popisu služby SS04_ServiceDesk, bude mít parametr Rx hodnotu 100 %, tedy vyjadřující absolutní naplnění požadavků Objednatele. V případě, kdy průměrné překročení požadované reakční doby za čtvrtletí dosáhne výše rovné původní požadované reakční doby, bude mít parametr hodnotu 0%, tedy vyjadřující absolutní neplnění požadavků Objednatele.

4.3.4

Celkové plnění reakční doby incidentu za všechny kategorie incidentů společně se stanoví jako průměrná hodnota parametrů Rx za jednotlivé kategorie incidentů, které nastaly, tedy podle vzorce:

kde: RC Rx

celkové plnění reakční doby incidentů hodnoty parametrů za jednotlivé kategorie incidentů (A, B a C)

18

K

4.3.5

4.4

celkový počet kategorií incidentů, které nastaly (v daném čtvrtletí se nemusí vyskytnout vždy incidenty všech tří kategorií)

Výsledná hodnota SLA parametru RC „Reakční doba na incident“ je uváděna jako číslo v procentech, zaokrouhlena na jedno desetinné místo.

SLA parametr „Doba vyřešení incidentu“ bude vypočten následujícím způsobem: 4.4.1

Doba vyřešení incidentu se počítá pro každou kategorii incidentu A, B a C zvlášť vzorcem:

kde: Vx N Tp Ts

realativní plnění doby vyřešení incidentu v kategorii x (A, B, nebo C) celkový počet incidentů v dané kategorii x za čtvrtletí doba vyřešení požadovaná (tj. stanovená v článku III. u popisu služby SS04_ServiceDesk) doba vyřešení skutečná

4.4.2

V případech kdy vypočtený parametr Vx dosáhne hodnot nižších než 0, bude pro účely dalších výpočtů roven 0.

4.4.3

Parametr Vx představuje relativní plnění požadované doby vyřešení incidentů z pohledu prodloužení skutečné doby vyřešení oproti době požadované obdobně, jako tomu je v případě plnění reakční doby incidentu, popsaném výše.

4.4.4

Celkové plnění doby vyřešení incidentu za všechny kategorie incidentů společně se stanoví jako průměrná hodnota parametrů Vx za jednotlivé kategorie incidentů, tedy podle vzorce:

kde: VC Vx K

4.4.5

celkové plnění doby vyřešení incidentu za všechny kategorie hodnoty parametrů za jednotlivé kategorie incidentů (A, B a C) celkový počet kategorií incidentů, které nastaly (v daném čtvrtletí se nemusí vyskytnout vždy incidenty všech tří kategorií)

Výsledná hodnota SLA parametru VC „Doba vyřešení incidentu“ je uváděna jako číslo v procentech, zaokrouhlena na jedno desetinné místo.

19

4.5

SLA parametr „Reakční doba požadavku služby“ bude vypočten následujícím způsobem: 4.5.1

Reakční doba požadavku služby se počítá pro každou kategorii požadavku, uvedenou specificky u popisů služeb v článku III., a pro každou službu zvlášť vzorcem:

kde: RxS N Tp Ts 4.5.2

V případech kdy vypočtený parametr RxS dosáhne hodnot nižších než 0, bude pro účely dalších výpočtů roven 0.

4.5.3

Parametr RxS představuje relativní plnění požadované reakční doby požadavků z pohledu prodloužení skutečné reakční doby oproti době požadované obdobně, jako tomu je v případě plnění reakční doby incidentu, popsaném výše.

4.5.4

Celkové plnění reakční doby požadavku za všechny kategorie požadavků v rámci Služby S společně se stanoví jako průměrná hodnota parametrů RxS za jednotlivé kategorie požadavků, tedy podle vzorce:

kde: RCS RxS K

4.5.5

4.6

relativní plnění reakční doby požadavku v kategorii x v rámci služby S celkový počet požadavků v dané kategorii x a v rámci dané služby S za čtvrtletí reakční doba požadovaná (tj. stanovená v článku III. u popisu příslušné služby) reakční doba skutečná

celkové plnění reakční doby požadavků v rámci služby S relativní plnění reakční doby požadavku v kategorii x v rámci služby S celkový počet kategorií, v rámci kterých byly vzneseny požadavky týkající se služby S za čtvrtletí

Výsledná hodnota SLA parametru RCS „Reakční doba na požadavek služby“ je uváděna jako číslo v procentech, zaokrouhlena na jedno desetinné místo.

SLA parametr „Doba vyřešení požadavku služby“ bude vypočten následujícím způsobem:

20

4.6.1

Doba vyřešení požadavku služby se počítá pro každou kategorii požadavku, uvedenou specificky u popisů služeb v článku III., a pro každou službu zvlášť vzorcem:

kde: VxS N Tp Ts

relativní plnění doby vyřešení požadavku v kategorii x v rámci služby S celkový počet požadavků v dané kategorii x a v rámci dané služby S za čtvrtletí doba vyřešení požadovaná (tj. stanovená v článku III. u popisu příslušné služby) doba vyřešení skutečná

4.6.2

V případech kdy vypočtený parametr VxS dosáhne hodnot nižších než 0, bude pro účely dalších výpočtů roven 0.

4.6.3

Parametr VxS představuje relativní plnění požadované doby vyřešení požadavků z pohledu prodloužení skutečné doby vyřešení oproti době požadované obdobně, jako tomu je v případě plnění reakční doby incidentu, popsaném výše.

4.6.4

Celkové plnění doby vyřešení požadavku za všechny kategorie požadavků v rámci Služby S společně se stanoví jako průměrná hodnota parametrů VxS za jednotlivé kategorie požadavků, tedy podle vzorce:

kde: VCS VxS K

4.6.5

celkové plnění doby vyřešení požadavků v rámci služby S relativní plnění doby vyřešení požadavku v kategorii x v rámci služby S celkový počet kategorií, v rámci kterých byly vzneseny požadavky týkající se služby S za čtvrtletí

Výsledná hodnota SLA parametru VCS „Doba vyřešení požadavku služby“ je uváděna jako číslo v procentech, zaokrouhlena na jedno desetinné místo. V.

5.1

VYKAZOVÁNÍ PLNĚNÍ SLA PARAMETRŮ

Zhotovitel bude v rámci reportu o kvalitě provozované Služby dle článku 7.4 Smlouvy předkládat přehled plnění SLA parametrů v průběhu příslušného kalendářního

21

čtvrtletí ve formě výkazu plnění SLA parametrů (dále jen „Čtvrtletní výkaz plnění SLA parametrů“) 5.2

Čtvrtletní výkaz plnění SLA parametrů poskytnutých služeb bude obsahovat: a) b) c)

5.3

výkaz plnění parametrů „Dostupnost služby“ pro každou službu resp. její dílčí činnost, u které je stanoven požadavek na dostupnost, za uplynulé čtvrtletí; výkaz plnění parametrů „Reakční doba na incident“ a „Doba vyřešení incidentu“ za uplynulé čtvrtletí; výkaz plnění parametrů „Reakční doba na požadavek služby“ a „Doba vyřešení požadavku služby“ za všechny služby poskytnuté v uplynulém čtvrtletí.

Detailní podoba čtvrtletního výkazu bude stanovena v rámci plnění Fáze 1. VI.

6.1

POŽADOVANÁ ÚROVEŇ PLNĚNÍ SLA PARAMETRŮ

Objednatel požaduje plnění SLA parametrů u všech uvedených služeb a jejich dílčích částí minimálně na následující úrovni:

SLA parametr „Dostupnost služby“ „Reakční doba na incident“ „Doba vyřešení incidentu“ „Reakční doba na požadavek služby“ „Doba vyřešení požadavku služby“ VII. 7.1

PRIORITA SLUŽEB

Objednatel stanovuje pro účely odvození dopadů neplnění SLA parametrů Zhotovitelem následující prioritní váhy jednotlivých Servisních služeb:

Označení SS SS01 SS02 SS03 SS04 SS06

Název Služby Prioritní váha Služby Servisní služby (dle bodu 3.3.1 písm. a) a b) Smlouvy) Technická podpora a údržba IS 0,4 Zálohování IS 0,1 Podpora správy uživatelů 0,1 ServiceDesk 0,3 Proškolení změn v IS 0,1 VIII.

8.1

Požadovaná úroveň plnění SLA parametru 95% 90% 90% 80% 80%

SANKČNÍ UJEDNÁNÍ

V případě, že Zhotovitel dle výkazu čtvrtletního plnění SLA parametrů za uplynulé čtvrtletí nenaplnil u Servisních služeb požadavky Objednatele na úroveň plnění SLA parametrů uvedené v článku VI., snižuje se cena Servisních služeb za příslušné čtvrtletí následujícím způsobem:

22

8.1.1

V případě nenaplnění požadavku na úroveň plnění SLA parametru „Dostupnost služby“, snižuje se cena Servisních služeb za příslušné čtvrtletí o hodnotu P zaokrouhlenou dolů na celé číslo vypočtenou dle vzorce:

kde: P DS PS CSS 8.1.2

V případě nenaplnění požadavku na úroveň plnění SLA parametru „Reakční doba na incident“, snižuje se cena Servisních služeb za příslušné čtvrtletí o hodnotu P zaokrouhlenou dolů na celé číslo vypočtenou dle vzorce:

kde: P RC PS CSS 8.1.3

výše srážky z ceny za poskytování Servisních služeb dle bodu 5.1.2 Smlouvy v Kč bez DPH skutečné plnění parametru „Reakční doba na incident“ prioritní váha služby SS04_ServiceDesk dle článku VII. cena za poskytování Servisních služeb dle článku 5.1.2 Smlouvy

V případě nenaplnění požadavku na úroveň plnění SLA parametru „Doba vyřešení incidentu“, snižuje se cena Servisních služeb za příslušné čtvrtletí o hodnotu P zaokrouhlenou dolů na celé číslo vypočtenou dle vzorce:

kde: P VC PS CSS 8.1.4

výše srážky z ceny za poskytování Servisních služeb dle bodu 5.1.2 Smlouvy v Kč bez DPH skutečné plnění parametru „Dostupnost služby“ prioritní váha služby S dle článku VII. cena za poskytování Servisních služeb dle bodu 5.1.2 Smlouvy

výše srážky z ceny za poskytování Servisních služeb dle bodu 5.1.2 Smlouvy v Kč bez DPH skutečné plnění parametru „Doba vyřešení incidentu“ prioritní váha služby SS04_ServiceDesk dle článku VII. cena za poskytování Servisních služeb dle článku 5.1.2 Smlouvy

V případě nenaplnění požadavku na úroveň plnění SLA parametru „Reakční doba na požadavek služby“, snižuje se cena Servisních služeb za příslušné čtvrtletí o hodnotu P zaokrouhlenou dolů na celé číslo vypočtenou dle vzorce:

23

kde: P RCS PS CSS 8.1.5

V případě nenaplnění požadavku na úroveň plnění SLA parametru „Doba vyřešení požadavku služby“, snižuje se cena Servisních služeb za příslušné čtvrtletí o hodnotu P zaokrouhlenou dolů na celé číslo vypočtenou dle vzorce:

kde: P VCS PS CSS 8.1.6

8.2

výše srážky z ceny za poskytování Servisních služeb dle bodu 5.1.2 Smlouvy v Kč bez DPH skutečné plnění parametru „Reakční doba na požadavek služby“ prioritní váha služby S dle článku VII. cena za poskytování Servisních služeb dle článku 5.1.2 Smlouvy

výše srážky z ceny za poskytování Servisních služeb dle bodu 5.1.2 Smlouvy v Kč bez DPH skutečné plnění parametru „Reakční doba na požadavek služby“ prioritní váha služby S dle článku VII. cena za poskytování Servisních služeb dle článku 5.1.2 Smlouvy

Jednotlivé srážky z ceny za poskytování Servisních služeb dle bodu 5.1.2 Smlouvy, vyčíslené v rámci stejného čtvrtletí dle principů uvedených v článku 8.1, se sčítají, avšak jejich souhrnná výše nepřekročí celkovou výši ceny za poskytování Servisních služeb dle bodu 5.1.2 Smlouvy.

V případě, že Zhotovitel dle výkazu čtvrtletního plnění SLA parametrů za uplynulé čtvrtletí nenaplnil u Služeb rozvoje resp. Služeb školení požadavky Objednatele na úroveň plnění SLA parametrů uvedené v článku VI., snižuje se cena Servisních služeb za příslušné čtvrtletí následujícím způsobem: 8.2.1

V případě nenaplnění požadavku na úroveň plnění SLA parametru „Reakční doba na požadavek služby“, snižuje se cena Služeb rozvoje resp. Služeb školení za příslušné čtvrtletí o hodnotu P zaokrouhlenou dolů na celé číslo vypočtenou dle vzorce:

kde: P RCS CS

výše srážky z ceny za poskytování Služeb rozvoje resp. Služeb školení dle bodu 5.1.3 resp. 5.1.4 Smlouvy v Kč bez DPH skutečné plnění parametru „Reakční doba na požadavek služby“ cena za poskytování Služeb rozvoje resp. Služeb školení poskytnutých v uplynulém čtvrtletí

24

8.2.2

V případě nenaplnění požadavku na úroveň plnění SLA parametru „Doba vyřešení požadavku služby“, snižuje se cena Služeb rozvoje resp. Služeb školení za příslušné čtvrtletí o hodnotu P zaokrouhlenou dolů na celé číslo vypočtenou dle vzorce:

kde: P VCS CS

8.2.3

výše srážky z ceny za poskytování Služeb rozvoje resp. Služeb školení dle bodu 5.1.3 resp. 5.1.4 Smlouvy v Kč bez DPH skutečné plnění parametru „Reakční doba na požadavek služby“ cena za poskytování Služeb rozvoje resp. Služeb školení poskytnutých v uplynulém čtvrtletí

Jednotlivé srážky z ceny za poskytování Služeb rozvoje resp. Služeb školení dle bodu 5.1.3 resp. 5.1.4 Smlouvy, vyčíslené v rámci stejného čtvrtletí dle principů uvedených v článku 8.2, se sčítají, avšak jejich souhrnná výše nepřekročí celkovou výši ceny za poskytování Služeb rozvoje resp. Služeb školení dle bodu 5.1.3 resp. 5.1.4 Smlouvy.

25