Smlouva o poskytování služeb Portálového systému SZIF a Portálové aplikace pro Monitoring Approach (Portálový systém SZIF)

















Smlouva o poskytování služeb Portálového systému SZIF a Portálové aplikace pro Monitoring Approach (Portálový systém SZIF)

PŘÍLOHA Č. 3



Závazné požadavky na poskytování Služeb

1Předmět Služeb

Předmětem služeb poskytovaných Objednateli je zejména zajištění Služeb provozu Systému  v cloudové infrastruktuře (prostředí) Poskytovatele či třetí strany ze strany Poskytovatele tak, aby bylo možné prostřednictvím Systému zajistit výkon administrace Společné zemědělské politiky (SZP) v systému IS XXXX, pro který Systém představuje uživatelské rozhraní, a bylo možné vykonávat ostatní agendy Objednatele, pro jejichž obsluhu budou v Systému v budoucnu implementovány další portálové aplikace. Služby provozu kontinuálně zabezpečují chod Systému v definovaných parametrech. Cloudovým prostředím je v tomto smyslu zamýšleno infrastrukturní a aplikační prostředí Poskytovatele či třetí strany poskytující cloudové služby. Systém je možné provozovat ve veřejném cloudu, privátním cloudu či infrastruktuře Poskytovatele poskytující cloudové služby. Pro provoz Systému musí být využity pouze takové cloudové služby, jejichž obdobu je možné čerpat i u jiných poskytovatelů cloudových služeb či služeb provozu a rozvoje Systému tak, aby byla zajištěna maximální přenositelnost Systému k jinému poskytovateli služeb provozu a rozvoje, včetně případného nasazení do prostředí hlavních veřejných cloudů.

Poskytování těchto Služeb provozu Systému bude zahájeno na základě Ukončení pilotní části služeb a dokončení finální akceptace Díla, tedy nejpozději od 1. 4. 2023.

Předmětem služeb poskytovaných Objednateli ze strany Poskytovatele je dále zajištění Maintenance licencí využitého programového vybavení, bude-li takové programové vybavení pro výstavbu a provoz Systému nezbytné (Dodaného SW), a Maintenance licencí Vlastního Díla.

Předmětem služeb poskytovaných Objednateli ze strany Poskytovatele je dále zajištění Služeb rozvoje, kdy prostřednictvím těchto služeb je garantována implementace změn Systému v závislosti na definovaných požadavcích Objednatele. Jedním z typů očekávaných změn je úprava existujících portálových aplikací či implementace zcela nových portálových aplikací vytvořených využitím nástrojů a zdrojů Portálového systému SZIF a v tomto Portálovém systému SZIF zároveň provozovaných.

Služby rozvoje budou zahájeny ve dvou postupných termínech:

Poskytování Služeb rozvoje prostřednictvím požadavku na změnu bude zahájeno ihned po dokončení vlastní Implementace, tedy nejpozději k termínu 1. 4. 2022. V období od zahájení poskytování těchto Služeb rozvoje po dobu do Ukončení pilotní části Pilotního a akceptačního provozu a dokončení finální akceptace Díla v rámci Pilotního a akceptačního provozu (12 měsíců) dle Přílohy č. 1 Smlouvy budou předmětem těchto služeb veškeré požadavky na další úpravy a rozvoj Systému, které nebudou zahrnuty do vlastní Implementace Díla. Po ukončení Pilotního a akceptačního provozu – nejdéle do 31. 3. 2023 – budou již předmětem Služeb rozvoje prostřednictvím požadavku na změnu pouze změny, které svým charakterem nebudou splňovat podmínky na realizaci Služeb rozvoje prostřednictvím projektu.

Poskytování Služeb rozvoje prostřednictvím projektu bude zahájeno stejně jako poskytování Služeb provozu dle této Přílohy č. 3 smlouvy – po ukončení Pilotního a akceptačního provozu, tedy nejpozději k termínu 1. 4. 2023.

V rámci služeb je rovněž možné realizovat jednorázové služby ukončení poskytování služeb (Exit):

  • Na základě výpovědi části služeb – formou projektu Ukončení poskytování dílčí služby (Dílčí Exit), dle odpovídajících ustanovení Smlouvy a kapitoly č. 3.5.1. této Přílohy č. 3 Smlouvy – ze strany Objednatele (případně dohodou smluvních stran) může dojít k Ukončení poskytování dílčích služeb poskytovaných ze strany Poskytovatele, nebo,

  • formou projektu Ukončení poskytování Služeb (Úplný Exit) dle odpovídajících ustanovení Smlouvy a kapitoly č. 3.5.2. této Přílohy č. 3 Smlouvy, při úplném ukončení Smlouvy (Smlouva může být ukončena dohodou smluvních stran, výpovědí či odstoupením kterékoliv ze smluvních stran, avšak o realizaci služby Ukončování poskytování služeb rozhoduje výlučně Objednatel).

Služby provozu, Maintenance licencí, Služby rozvoje a Exit jsou v této Příloze č. 3 označeny jako „Služby“ nebo „služby“).

2Organizační zajištění poskytování služeb

Pro organizaci služeb je využito standardů programového a projektového řízení tak, aby byla zajištěna kontinuita poskytovaných služeb, byla garantována auditovatelnost a prokazatelnost způsobu poskytování služeb.

Programové/projektové řízení je pro účely poskytování služeb myšleno jako dlouhodobý princip realizace služeb, kdy jsou v rámci definovaného Programu/projektu stanoveny řídící a eskalační mechanismy nezbytné pro samotný výkon Objednatele a Poskytovatele při realizaci služeb.

2.1Uplatňované projektové principy

Následující kapitola stanovuje projektové principy, které bude Poskytovatel i Objednatel uplatňovat u kompletního poskytování Služeb definovaných v této Příloze č. 3 Smlouvy, a to odpovídajícím způsobem, aby realizace služeb a činností na jednotlivých úrovních řízení Programu/projektu byla poskytována profesionálně a dle nejlepší praxe (Best Practice).

2.1.1Specifika programových/projektových principů v prostředí SZIF

Informační systém Platební agentury SZIF, jehož součástí je i Systém a v Systému vytvořené funkcionality (funkčnosti) a portálové aplikace, musí velmi pružně reagovat na dynamicky a intenzivně se měnící podmínky administrace Společné zemědělské politiky v ČR. Z tohoto důvodu mají projektové činnosti v SZIF charakter kontinuálně se opakujících dílčích aktivit, které je nezbytné podporovat prostřednictvím informačních technologií. Standardní projektové týmy, definované a na roční bázi schválené programové struktury prostřednictvím Řídícího výboru tak mají charakter spíše pracovních skupin. Tyto projektové týmy tak vykonávají svou činnost opakovaně, kdy se schází pravidelně v definovaných intervalech (viz kapitola 2.2. Organizace programu). Veškeré činnosti zahrnující právě toto kontinuální fungování projektových týmů zohlední Poskytovatel v rámci stanoveného způsobu poskytování služeb, kdy v rámci ceny jednotlivých služeb jsou kalkulovány rovněž náklady na fungování těchto projektových týmů.

Charakter dílčích projektů skutečně realizovaných prostřednictvím standardních projektových principů (řízení zdrojů, kapacit, limitně definovaný čas a předání výstupů projektu) pak mají Služby rozvoje realizované prostřednictvím Požadavků na změnu (rozsah do 100 MD a změna nemá dopad na architekturu Systému), nebo prostřednictvím Projektů (rozsah nad 100 MD, nebo má změna dopad na architekturu Systému).

Detailní nastavení principů projektového řízení pro poskytování Služeb bude realizováno v době Implementace Systému a koordinováno s principy řídícího integračního Programu/projektu IS XXXX realizovaného veřejnou zakázkou „Implementace a provoz informačního systému SZIF pro Monitoring Approach“ (dále jen „VZ IS XXXX“) na základě oboustranně odsouhlasených charakteristik řízení Programu. Programové a projektové principy musí být nastaveny v souladu s ustanoveními této Přílohy č. 3 Smlouvy a využívaných Best Practice pro řízení projektových týmů a projektů v rámci Programu.

2.1.2Plánování

V rámci projektových aktivit probíhá plánování (primárně rozvoje) prostřednictvím střednědobých plánů (obvykle na 12 kalendářních měsíců). Tyto plány jsou aktualizované na úrovni jednotlivých projektových týmů a schvalované na úrovni HTPG.

Plánování jednotlivých Služeb (tj. zejména stanovení termínů jejich realizace) a samotná realizace Služeb budou probíhat v úzké součinnosti Poskytovatele a Objednatele tak, že musí být splněny následující podmínky:

  • Plánování a realizace Služeb musí být v souladu s počtem disponibilních pracovníků projektového týmu Poskytovatele.

  • Rozvojové aktivity musí být identifikovány a zadány včas, aby bylo možné zajistit jejich realizaci v požadovaných termínech.

  • Plánované aktivity musí být v souladu s předpokládaným rozsahem rozvojových prací schváleným na úrovni Řídícího výboru.

Za plánování na úrovni projektových týmů odpovídají vždy Vedoucí projektových týmů (provozního týmu).

2.1.3Jednání

Jednání probíhají odpovídající formou, a to buď prostřednictvím elektronického nástroje pro videokonference, nebo osobně v sídle Objednatele. Jednání od organizační úrovně Projektového týmu výše jsou formalizovaná, z každého jednání tak musí být pořízen zápis/záznam. V rámci zápisu musí být jednoznačně a dostatečně konkrétně stanovené úkoly a aktivity projektového týmu a harmonogram jejich splnění musí být odsouhlasen pracovníky v odpovídajících projektových rolích jak za stranu Objednatele, tak za stranu Poskytovatele. V případě neodsouhlasení oběma projektovými stranami je neschválená problematika vždy eskalována o úroveň výše. Pozvánku na jednání zasílá zpravidla zástupce Objednatele, pokud není dohodnuto jinak, a to prostřednictvím elektronické pošty.

V rámci jednání jsou na jednotlivých úrovních organizace programu řešeny zejména následující oblasti:

  • Souhrn za minulé období – ukončené/prováděné činnosti,

  • Hlavní plánované aktivity na další období,

  • Harmonogram,

  • Identifikovaná rizika,

  • Požadavky na součinnost,

  • Změny,

  • Úkoly,

  • Sporné otázky /problémy/témata,

  • Projektové aktivity k eskalaci.

2.1.4Komunikace

Komunikace v rámci projektových týmů může mít formální i neformální charakter, podle projektové úrovně, na které se odehrává. Formální komunikace prostřednictvím elektronických nástrojů (Service Desk, zápisy z jednání, email na úrovni vedoucích projektových týmů a výše, případně další komunikační platformy včetně videokonference) má pro obě projektové strany závazný charakter. Tedy závěry, na nichž se projektové strany prostřednictvím formální komunikace usnesou, jsou závazné. Primárním formálním nástrojem projektové dokumentace jsou Zápisy/záznamy z jednání, zbývající formální komunikace má zejména podpůrný charakter.

Neformální komunikace realizovaná na úrovni řadových členů projektových týmů nemá závazný charakter, jako formální ji lze používat ve specifických případech, kdy není možné například zajistit jiný formální způsob komunikace.

2.1.5Vedení projektové dokumentace

Za projektovou dokumentaci v rámci poskytování služeb je považována veškerá dokumentace, která vzniká v průběhu realizace Služeb, ať se jedná o dokumentaci s charakterem projektové/provozní/analytické/architektonické/jiné. Projektová dokumentace je vždy dle charakteru dokumentace ukládána na úložiště spravované(á) Objednatelem a Objednatel rovněž zajišťuje řízení k projektové dokumentaci.

Závazné principy vedení projektové dokumentace jsou stanoveny v rámci Služby IS01.

2.1.6Řízení rizik

Princip řízení rizik bude uplatňován na všech úrovních programového/projektového řízení. Formální evidenci rizik bude zajišťovat vždy zástupce Objednatele tak, aby bylo možné identifikovaná rizika řídit v souladu s interními principy řízení rizik a rizika následně evidovat v nástroji pro řízení rizik dle metodických postupů Objednatele. Principy řízení rizik budou zahrnovat standardní nástroje:

  • Hodnocení rizik na základě dopadů a pravděpodobnosti výskytu

  • Kategorizace a formální evidence rizik

  • Řízení rizik a včetně přijetí odpovídajícího opatření k identifikovaným rizikům:

    • Přenesení odpovědnosti

    • Akceptace

    • Snížení míry rizika

    • Eliminace rizika

    • Sdílení rizika

2.2Organizace programu

Detailní nastavení principů projektového řízení pro poskytování Služeb v době Implementace Systému bude koordinováno s principy řídícího integračního Programu/projektu IS XXXX realizovaného VZ IS XXXX.

Program je organizován v níže definovaných úrovních řízení.

2.2.1Řídící výbor programu

Nejvyšším orgánem Programu je Řídící výbor programu (ŘVPG), který má stálé zástupce ze strany Objednatele i Poskytovatele.

  • Jedná se o oprávněné osoby v následujících rolích:

    • Oprávněná osoba za oblast smluvní (Objednatel)

    • Oprávněná osoba za oblast smluvní (Poskytovatel)

    • Oprávněná osoba za oblast obchodní (Objednatel)

    • Oprávněná osoba za oblast obchodní (Poskytovatel)

  • Dále jsou stálými zástupci Řídícího výboru pracovníci v následujících projektových rolích, pokud se jedná o pracovníky odlišné od oprávněných osob:

    • Sponzor programu (Objednatel)

    • Sponzor projektu (Poskytovatel)

    • Vedoucí programu (Objednatel)

Operativně mohou být dle potřeby přizýváni další členové projektových týmů (např. Projektového týmu Systému), kteří jsou primárně zodpovědní za realizaci prací na různých projektových úrovních, a to jak za stranu Objednatele, tak za stranu Poskytovatele.

Řídící výbor programu se schází:

  • Alespoň jednou ročně na konci kalendářního roku, aby formálně schválil:

    • Detailní organizační strukturu Programu

    • Nominace jednotlivých pracovníků Objednatele i Poskytovatele do projektových rolí

    • Předpokládaný rozsah rozvojových prací na následující kalendářní rok

    • Předpokládaný rozpočet na realizaci změn Systému pro následující kalendářní rok

    • Případné změny v procesních postupech týkající se realizace projektových prací, které nemají dopad na smluvní ustanovení (např. změna úložiště projektové dokumentace, změna dílčích formulářů projektových dokumentů)

  • Dle potřeby operativně na základě potřeby, kterou iniciuje Oprávněná osoba za oblast smluvní ze strany Objednatele i Poskytovatele nebo Sponzor Projektu ze strany Objednatele i Poskytovatele.



Řídící výbor:

  • Činí veškerá požadovaná rozhodnutí přesahující kompetence nižších programových struktur, potvrzuje personální změny projektových týmů na úrovni vedoucích projektových týmů vztahujících se k této Smlouvě.

  • Odsouhlasuje strategické, koncepční a závazné projektové dokumenty mající vliv na způsob a formu poskytování služeb.

  • Je nejvyšším smluvně-projektovým eskalačním orgánem v rámci poskytování Služeb.

ŘVPG předsedá sponzor Programu Objednatele, ze všech jednání ŘVPG se pořizuje písemný zápis.

2.2.2Hlavní tým programu

Hlavní tým programu (HTPG) zajišťuje primární koncepční i operativní řízení na úrovni Programu a projektových struktur.

Personální obsazení Hlavního týmu programu stanovuje a odsouhlasuje Řídící výbor programu, kterému je podřízený, vždy s výhledem na následující kalendářní rok. Minimální stálí členové HTPG v rámci Smlouvy jsou:

    • Sponzor programu (Objednatel)

    • Sponzor projektu (Poskytovatel)

    • Vedoucí programu (Objednatel)

    • Vedoucí projektu (Poskytovatel)

Členové HTPG se schází zpravidla jednou za měsíc, aby průběžně plánovali a kontrolovali stav provozu i prací na úrovni jednotlivých Projektových týmů, rozhodovali o návrzích provozu nebo projektů. Na jednání HTPG jsou standardně přizýváni zástupci jednotlivých Projektových týmů, kdy se může jednat o zástupce projektových týmů stanovených jak v rámci této Smlouvy, tak projektových týmů, v jejichž odpovědnosti jsou další technologie využívané Objednatelem pro komplexní zajištění provozu systémové podpory agend Programu XXXX, typicky:

  • IS XXXX

  • Služby Portálového systému SZIF

  • Služby SAMAS

  • Služby Geotagovaných fotografií

  • Služby IS SAP

O přizvání zástupců projektových týmu rozhodují společně Vedoucí programu Objednatele a Vedoucí projektu Poskytovatele, v případě, že nedojde ke shodě, rozhoduje Sponzor programu Objednatele.

Hlavní tým programu dále:

  • Koordinuje práci jednotlivých Projektových týmů, včetně projektových týmů, které nezajišťují přímo realizaci služeb souvisejících s technologiemi provozovanými na základě této Smlouvy.

  • Přijímá rozhodnutí přesahující kompetence těchto projektových týmů.

  • Úkolem Hlavního týmu programu je definovat a udržovat dlouhodobou schválenou koncepci a strategii Programu a zajišťovat integritu celého řešení, a to nejen z vnitřního pohledu, ale i ve vazbě na externí prostředí.

  • Zajišťuje, aby nově implementované funkce Systému byly v souladu s definovanými standardy, a zajišťuje jejich hladký náběh do produktivního provozu bez ohrožení stávajících funkcí.

  • Připravuje zprávu o stavu programu pro jednání Řídícího výboru programu.

Na operativní úrovni vede Hlavní tým programu Vedoucí programu za stranu Objednatele. Ze všech jednání HTPG se pořizuje písemný zápis.

2.2.3Projektový tým

Projektový tým Systému (PT) je výkonným orgánem programové struktury. Na úrovni projektového týmu dochází k pravidelnému plánování činností spadajících do odpovědnosti daného projektového týmu, a to jak na úrovni operativní, průběžné, tak na úrovni projektové, řízené harmonogramem. Struktura projektových týmů není fixní, množství a odpovědnosti projektových týmů jsou stanovené na základě rozhodnutí a schválení Řídícího výboru programu, zpravidla na roční bázi. Činnosti řešení v projektových týmech, do kterých budou nominováni zástupci Objednatele a Poskytovatele musí zastřešovat oblasti a technologie dodávané a provozované v souladu s uzavřenou Smlouvou.

Minimální počet projektových týmů je stanoven na dva, kdy odpovědnosti projektových týmů musejí být striktně oddělené. Vždy právě jeden projektový tým bude zastřešovat oblasti provozu, informační a kybernetické bezpečnosti provozu a minimálně jeden projektový tým bude zastřešovat oblasti rozvoje.

Členové PT za oblast provozu se schází pravidelně jednou za 14 dní, pokud není dohodnuto jinak, aby průběžně plánovali a kontrolovali provozní stav Systému a koordinovali činnosti provozu Systému.

Členové PT za oblast(i) rozvoje se schází dle potřeby, aby koordinovali, řídili a rozhodovali o rozvojových pracích na operativní úrovni, připravovali návrhy nových činností a funkcionalit a zajišťovali rozvoj Systému v souladu s požadavky Objednatele při respektování smluvních a rozpočtových omezení pro realizaci Služeb rozvoje.

Na jednání PT jsou standardně přizýváni zástupci ze strany Objednatele i Poskytovatele.

  • Pro PT zajišťující oblasti provozu, informační a kybernetické bezpečnosti provozu jsou pro řízení PT stanoveny minimálně následující role:

    • Sponzor projektového týmu provozu (Objednatel)

    • Garant projektového týmu provozu (Objednatel)

    • Vedoucí projektového týmu provozu – projektový manager (Objednatel)

    • Vedoucí (projektového) týmu provozu (Poskytovatel)

Dále v rámci fungování PT za oblast provozu figurují (nemusejí být pravidelnými členy jednání PT):

    • Bezpečnostní manažer (Objednatel)

    • Vedoucí provozu (Objednatel)

    • Analytik bezpečnosti – informační/kybernetické (Poskytovatel)

    • Analytik integrace (Poskytovatel)

    • Databázový specialista (Poskytovatel)



  • Pro PT zajišťující oblasti rozvoje jsou pro řízení PT stanoveny minimálně následující role:

    • Sponzor projektového týmu rozvoje (Objednatel)

    • Garant projektového týmu rozvoje (Objednatel)

    • Vedoucí projektového týmu rozvoje – projektový manager (Objednatel)

    • Vedoucí projektového týmu rozvoje – Projekt manager (Poskytovatel)



Dále v rámci fungování PT za oblast rozvoje figurují (nemusejí být pravidelnými členy jednání PT):

    • Metodický garant (Objednatel)

    • Solution architekt řešení (Poskytovatel)

    • Business/procesní architekt (Poskytovatel)

    • Analytik integrace (Poskytovatel)

    • Senior vývojář/vedoucí týmu (Poskytovatel)



PT dále:

  • Zajišťuje vlastní výkon daného PT – operativní a rozvojové činnosti nezbytné k zajištění chodu Systému dle stanovených a odsouhlasených parametrů.

  • Navrhuje opatření a oblasti přesahující kompetence PT.

  • Připravuje zprávu o stavu činností PT pro jednání HTPG.

Na operativní úrovni zodpovídají za řízení projektového týmu Vedoucí projektového týmu za stranu Objednatele i Poskytovatele. Ze všech formálních jednání PT se pořizuje písemný zápis.

2.3Projektové role

Níže uvedené projektové role s definovanými odpovědnostmi nezahrnují konečný výčet projektových rolí, které strana Objednatele i strana Poskytovatele využívá v rámci realizace Služeb. Jedná se o výčet rolí a odpovědností, jejichž odpovědnosti jsou z hlediska poskytování služeb v rámci fungování Programu formální a je tedy nezbytné je zajistit. Další projektové role v rámci Programu jsou využívány dle potřeby tak, aby bylo možné plně garantovat zajištění Služeb v odpovídající kvalitě a rozsahu. Při realizaci rozvojových aktivit v podobě rozvojových Projektů jsou pro každý Projekt definovány role zvlášť v odpovídající projektové dokumentaci (Dokumentace nastavení projektu).

2.3.1Sponzor programu (za) Objednatele

Sponzorem programu za Objednatele je člen Porady vedení na pozici Ředitele sekce (ve výjimečném případě lze tuto roli delegovat na ředitele odboru). Na vrcholové úrovni Programové struktury se stává zastřešující rolí pro realizaci projektů, která v případě eskalace rozhoduje o realizaci/nerealizaci rozvojových oblastí a podporuje zavádění výsledků projektů do standardního užívání v informačním prostředí Objednatele. Napomáhá rychlému řešení eskalovaných záležitostí Vedoucími programu. Schvaluje spolu s Vedoucím programu (za Objednatele) realizaci rozvojových aktivit v podobě rozvojových projektů.

2.3.2Sponzor projektu (za) Poskytovatele

Zajišťuje pro vedoucího programu Poskytovatele požadovanou podporu nutnou pro splnění cílů programu, aby tak zajistil plnou spokojenost Objednatele. To zahrnuje účast na schůzích řídícího výboru programu nebo hlavního týmu programu a poskytování pomoci při řešení vyhrocených problémů, pokud se vyskytnou.

2.3.3Vedoucí programu (za) Objednatele

Vedoucím programu za Objednatele je určený zaměstnanec Objednatele na úrovni ředitele odboru. Zodpovídá za koordinaci provozu a všech probíhajících projektů, operativní plánování a řízení všech dohodnutých aktivit pracovníků Objednatele. Postupuje v úzké součinnosti s Vedoucím projektu Poskytovatele tak, aby byly v plánovaných termínech a kvalitě provedeny všechny plánované projektové aktivity, a to jak v oblasti provozu, tak v oblasti rozvoje. V případě potřeby eskaluje příslušné projektové záležitosti, které již nemůže v rámci své kompetence rozhodnout (změna rozsahu, rozpočtu, časového plánu projektu), na úroveň ŘVPG k rozhodnutí. Vedoucí programu Objednatele předsedá hlavnímu týmu programu, který rovněž svolává. Zodpovídá za vytváření zápisů z ŘVPG a HTPG. Schvaluje spolu se Sponzorem programu (za Objednatele) realizaci rozvojových aktivit v podobě rozvojových Projektů.

2.3.4Vedoucí projektu (za) PoskytovatelE

Zodpovídá za koordinaci provozu a všech probíhajících projektů, operativní plánování a řízení všech dohodnutých aktivit pracovníků Poskytovatele. Postupuje v úzké součinnosti s Vedoucím programu Objednatele tak, aby byly v plánovaných termínech a kvalitě provedeny všechny plánované projektové aktivity, a to jak v oblasti provozu, tak v oblasti rozvoje. V případě potřeby eskaluje příslušné projektové záležitosti, které již nemůže v rámci své kompetence rozhodnout (změna rozsahu, rozpočtu, časového plánu projektu), na úroveň ŘVPG k rozhodnutí.

Schvaluje společně se zástupci Objednatele realizaci rozvojových aktivit v podobě rozvojových Projektů.

2.3.5Sponzor projektového týmu (Za) Objednatele

Sponzorem projektového týmu je zpravidla člen Porady vedení SZIF na úrovni ředitele sekce (ve výjimečném případě lze tuto roli delegovat na ředitele odboru). Jeho odpovědností, jako zástupce struktur řídících organizačních struktur SZIF, je prosazovat projekt v rámci struktur Objednatele. Je nejvyšší autoritou v daném projektu (projektovém týmu) a majitel projektu, mající vrcholnou rozhodovací pravomoc pro vykonávání primárních odpovědností. Má tedy pravomoc pro určení priorit, schválení rozsahu a urovnání otevřených problémů. Jestliže vznikají konflikty při realizaci těchto odpovědností, přenáší řešení na úroveň HTPG, případně ŘVPG.

2.3.6Garant projektového týmu (Za) Objednatele

Zodpovídá za věcnou správnost řešení všech dohodnutých projektových aktivit. Stanovuje priority v rámci projektových aktivit dle příslušného projektového týmu. Je první eskalační úrovní zodpovídající za řešení věcné problematiky v projektovém týmu. V případě potřeby vystupuje jako eskalační orgán, a to jak směrem do projektového týmu, tak vůči nadřízeným programovým strukturám (Sponzor projektového týmu, HTPG, ŘVPG), kam případně předkládá k řešení projektové záležitosti, které již nemůže v rámci své kompetence rozhodnout (změna rozsahu, rozpočtu, časového plánu projektu). Zodpovídá za věcné plánování aktivit v Projektovém týmu. Schvaluje společně s Vedoucím projektového týmu (za Objednatele) realizaci rozvojových aktivit v podobě Požadavků na změnu. Předkládá společně se Sponzorem projektového týmu požadavky na realizaci rozvojových aktivit v podobě rozvojových Projektů na úroveň HTPG.

2.3.7Vedoucí projektového týmu – projektový manager (za) Objednatele

Zodpovídá za operativní řízení projektových aktivit pracovníků Objednatele v rámci daného projektového týmu. Postupuje v úzké součinnosti s Vedoucím projektu Objednatele tak, aby byly v plánovaných termínech a kvalitě provedeny všechny odsouhlasené plánované projektové aktivity v daném projektovém týmu. V případě potřeby eskaluje příslušné projektové záležitosti, které již nemůže v rámci své kompetence rozhodnout (změna rozsahu, rozpočtu, časového plánu projektu), na úroveň Garanta projektového týmu. Schvaluje společně s Garantem projektového týmu (za Objednatele) realizaci rozvojových aktivit v podobě Požadavků na změnu. Kontroluje čerpání služeb v rámci svěřeného projektového týmu. Připravuje Garantovi projektového týmu (za Objednatele) požadavky na realizaci rozvojových aktivit v podobě rozvojových Projektů na úroveň HTPG.

2.3.8Vedoucí týmu provozu/ Vedoucí projektového týmu rozvoje – Projekt manager (za) Poskytovatele

Zodpovídá za operativní řízení projektových aktivit pracovníků Poskytovatele v rámci daného projektového týmu. Postupuje v úzké součinnosti s Vedoucím projektu Objednatele tak, aby byly v plánovaných termínech a kvalitě provedeny všechny odsouhlasené plánované projektové aktivity v daném projektovém týmu. V případě potřeby eskaluje příslušné projektové záležitosti, které již nemůže v rámci své kompetence rozhodnout (změna rozsahu, rozpočtu, časového plánu projektu), na úroveň Vedoucího programu (za Poskytovatele). Schvaluje společně se zástupci Objednatele realizaci rozvojových aktivit v podobě Požadavků na změnu. Předkládá společně se zástupci Objednatele požadavky na realizaci rozvojových aktivit v podobě rozvojových Projektů na úroveň HTPG.

2.3.9Bezpečnostní manažer (za) Objednatele

Jedná se o roli v rámci nastaveného Systému řízení informační bezpečnosti (ISMS) na straně Objednatele. Zodpovídá za kontrolu, revizi i definování bezpečnostních požadavků v rámci realizace Služeb, a to jak v oblasti provozu, tak v oblasti rozvoje. Společně s Analytikem bezpečnosti (za Poskytovatele, zodpovídá za splnění veškerých požadavků na informační a kybernetickou bezpečnost vyplývající z ISO/IEC 27001 v aktuální verzi, dále pak za soulad poskytování služeb s požadavky ZoKB včetně prováděcích předpisů. Je kontaktní osobou za stranu Objednatele při realizaci interních i externích auditů a kontrol týkajících se informační a kybernetické bezpečnosti a související s poskytováním služeb ze strany Poskytovatele. Společně s Analytikem bezpečnosti (za Poskytovatele) zodpovídá za plánování, realizaci a dokumentaci veškerých aktivit souvisejících s informační a kybernetickou bezpečností.

2.3.10Analytik bezpečnosti – informační/kybernetické (Za) Poskytovatele

Plně zodpovídá za splnění veškerých požadavků na zajištění informační a kybernetické bezpečnosti za stranu Poskytovatele včetně požadavků vyplývajících z určení Poskytovatele jakožto Významného dodavatele dle prováděcích předpisů k ZoKB. Je kontaktní osobou za stranu Poskytovatele při realizaci auditů a kontrol v oblasti informační a kybernetické bezpečnosti, které jsou realizovány na straně Objednatele a souvisejí s poskytováním služeb ze strany Poskytovatele. Společně s bezpečnostním manažerem (za Objednatele) zodpovídá za plánování, realizaci a dokumentaci veškerých aktivit souvisejících s informační a kybernetickou bezpečností.

3Katalog služeb

3.1Definice Katalogu služeb

V této kapitole stanovený katalog služeb určuje technické, procesní a další podmínky jednotlivých služeb, které jsou realizovány ze strany Poskytovatele. Tyto podmínky jsou pro poskytování služeb závazné.

3.2Struktura katalogu služeb a vymezení pojmů

Katalog služeb obsahuje pro každou kategorii služeb níže uvedené položky/parametry. Samotné poskytování služeb je tak výsledkem kombinace několika faktorů při splnění nezbytných parametrů. Pojmy vymezené v této kapitole se uplatní na všechny kapitoly tohoto dokumentu.

  • Název služby

Jedná se o písemné označení služby obecně charakterizující aktivity poskytované v rámci dané služby.

  • Označení (identifikátor) služby ve formátu „IS0N“, kdy N je definuje číslo služby.

Identifikátor je jednoznačně přiřazený ke každé službě, každá služba má identifikátor jedinečný. V kombinaci s dalšími stanovenými identifikátory umožňuje jednoznačné určení plnění služby (viz označení modulu), kdy toto označení bude využito při vykazování plnění dané služby.

  • Vymezení služby/aktivity

Skupina parametrů a podmínek celkově definujících charakteristiku dané služby/aktivity. Obsahuje jednotlivé klíčové aktivity/činnosti poskytované v rámci služeb/aktivit, rozsah služby/aktivity a další vlastnosti služby/aktivity.

  • Lokalita

Definice, zda tato služba bude poskytována primárně v prostředí (sídle) Objednatele – Lokalita A, nebo zda se jedná o činnosti, které Poskytovatel zajistí vzdáleně ze svých prostor – Lokalita B, a to jak vůči Sídlu Objednatele, tak vůči implementovanému informačnímu prostředí v aktuálně využívaném Datovém centru, kdy vzdálený přístup zajistí Objednatel v souladu se svými bezpečnostními standardy.

  • Prostředí

Určuje, k jaké kategorii prostředí je služba vztažena, tedy pro jaké prostředí bude služba poskytována. V případě, že některé aktivity v rámci dané služby jsou vztaženy i k jiné kategorii prostředí, je toto explicitně uvedeno vždy u konkrétní aktivity. Kategorie prostředí jsou následující:

    • PROD (produktivní systémy) prostředí obsahující komplexní produktivní data, v této kategorii prostředí je realizován výkon činností Objednatele, tedy probíhá zde vlastní administrace Společné zemědělské politiky.

    • TEST (testovací systémy) prostředí obsahující plnohodnotná data pro přípravu a nasazení jednotlivých funkčností do produktivních systémů (PROD), s ohledem na komplexnost nezbytného testování a integraci Systému, mohou testovací systémy obsahovat produktivní data. V tomto prostředí NEPROBÍHÁ vývoj a úpravy systémů!

    • DEV (vývojové systémy) prostředí obsahující pouze data nezbytná pro přípravu a vývoj jednotlivých funkčností. Do této kategorie systémů nemají standardní přístup zaměstnanci Objednatele. V tomto prostředí je realizován samotný vývoj a příprava úprav systémů.

  • Aktivita (seznam aktivit)

Jedná se o konkrétní aktivitu/činnost a soupis aktivit, které jsou poskytovány v rámci plnění definované služby. Výčet aktivit je stanoven jako minimální, tyto aktivity jsou předmětem vykazování. Poskytovatel je v rámci poskytování konkrétní služby povinen zajistit realizaci dalších aktivit, v případě, že jsou nezbytné pro samotné naplnění charakteristiky dané služby.

  • Označení (identifikátor) aktivity ve formátu „ANN“, kdy NN je definuje číslo aktivity

Identifikátor je jednoznačně přiřazený ke každé aktivitě, každá aktivita má identifikátor jedinečný. V kombinaci s dalšími stanovenými identifikátory umožňuje jednoznačné určení plnění služby (viz označení (identifikátor) modulu).

  • Obecný rozsah aktivity/Rozsah aktivity

Definuje způsob vlastního poskytování služeb v rámci dané aktivity. Obecný rozsah aktivity uvádí stručnou charakteristiku činností. Rozsah aktivity v rámci definice aktivity dále uvádí konkrétní specifikaci realizovaných činností dané aktivity. Dané činnosti jsou stanoveny jako minimální. Poskytovatel je povinen v rámci poskytování konkrétní služby zajistit realizaci dalších činností v rámci aktivity, v případě, že jsou nezbytné pro samotné naplnění charakteristiky dané služby.

  • Komponenta/modul (seznam komponent)

Jedná se o vymezení konkrétních technologických komponent, jejichž dodání a implementace včetně odpovídajících funkčností byly předmětem dodání Díla. Poskytování služeb pro jednotlivé komponenty/moduly je realizováno tak, aby bylo v případě rozhodnutí Objednatele možné vypovědět poskytování služeb vztažené ke konkrétní komponentě/modulu bez dopadu na poskytování služeb ke zbývajícím komponentám/modulům, pokud Objednatel zajistí plnohodnotné poskytování služeb k dané komponentě/modulu jiným způsobem. (Příklad: v případě výpovědi všech služeb ke komponentě Portálové aplikace XXXX pro žadatele a při zajištění kompletních služeb provozu i rozvoje k této komponentě ze strany Objednatele, nebude dotčeno poskytování služeb ze strany Poskytovatele ke zbývajícím komponentám).

Výčet technologických komponent:

  • Portálový systém SZIF

  • Notifikační komponenta (Notifikátor)

  • Formulářový server klientů veřejné správy

  • Formulářový server úřední osoby

  • Portálová aplikace XXXX pro žadatele

  • Portálová aplikace XXXX pro SZIF

  • BUDE DÁLE DOPLNĚNO PŘED PODPISEM SMLOUVY NA ZÁKLADĚ VÍTĚZNÉ NABÍDKY V SOULADU S PŘÍLOHOU Č. 7 SMLOUVY

  • Označení (identifikátor) komponenty/modulu ve formátu „KNN“

V rámci identifikátoru je NN číslo technologické komponenty modulu definované tak, aby bylo možné, v kombinaci s dalšími stanovenými identifikátory, jednoznačné určení plnění služby. Identifikace jednotlivých komponent je následující:

  • K01 – Portálový systém SZIF

  • K02 – Notifikační komponenta (Notifikátor)

  • K03 – Formulářový server klientů veřejné správy

  • K04 – Formulářový server úřední osoby

  • K05 – Portálová aplikace XXXX pro žadatele

  • K06 – Portálová aplikace XXXX pro SZIF

    • BUDE DÁLE DOPLNĚNO PŘED PODPISEM SMLOUVY NA ZÁKLADĚ VÍTĚZNÉ NABÍDKY V SOULADU S PŘÍLOHOU Č. 7 SMLOUVY

Díky stanoveným identifikátorům (služba, aktivita, komponenta) bude tedy možné jednoznačně určit konkrétní předmět služby. Takto nastavená identifikace bude využita při vykazování aktivit jednotlivých pracovníků Poskytovatele v rámci Výkazů plnění nezbytných pro akceptaci poskytované služby ve Vyhodnocovacím období (Příklad: uvedený identifikátor S01A05K01 bude u konkrétního pracovníka Poskytovatele znamenat, že se např. daný pracovník podílel na realizaci interního auditu ISMS, který se vztahoval k nastavení Portálového systému SZIF).

  • Incident

Zpravidla jednorázová událost při využívání služby, která neprobíhá očekávaným způsobem a způsobuje snížení kvality služby nebo její nedostupnost. Obvykle lze odstranit v rámci operativního provozu.

  • Vada

Incident, který není vyřešen v požadované lhůtě odpovídajícím způsobem, se stává Vadou systému. Výskyt Vady systému a počet Vad během vyhodnocovacího období ovlivňuje kvalitu poskytovaných služeb a splnění SLA parametrů.

  • Problém (problem)

Zpravidla dlouhodobá, nebo systémová událost při využívání služby, která prokazatelně způsobuje snížení kvality služby nebo její nedostupnost a vyžaduje dlouhodobější systémové řešení.

  • Ticket (incident ticket/problem ticket)

Žádost o zabezpečení podpory při využívání služby předaná z kontaktního místa/Sevice Desku Objednatele na konkrétní kontaktní místo/Service Desk Poskytovatele, která má zřejmě příčinu v chybovém stavu služby.

  • Požadavek (request)

Žádost ze strany Objednatele i Poskytovatele o zabezpečení podpory/součinnosti/služby předaná na konkrétní odpovědnou osobu/kontaktní místo/Service Desk Poskytovatele/Objednatele. Požadavek nemá příčinu v chybovém stavu služby, tj. není incidentem (např. Požadavek na změnu, Požadavek na součinnost, Požadavek na realizaci kopie, atd.).

  • Service Desk

Service Desk je jednotný systém pro evidenci a řízení všech záznamů (Incidentů, Problémů Požadavků, pokud není stanoveno konkrétní metodikou jinak, …) souvisejících s provozem Systému a poskytovanými službami. Řízení záznamů je založeno na standardních procesech řízení IT služeb. Systém Service Desk je zajišťován Objednatelem, kdy Objednatel zajistí Poskytovateli přidělení uživatelských rolí a práv k Service Desku, na jejichž základě bude pracovníkům Poskytovatele umožněno provádět Služby zejména v rozsahu stanoveném Službou IS04.

    • 1. úroveň podpory

Jedná se o pracoviště Service Desk Objednatele, které zabezpečuje příjem resp. vstupní zpracování všech incidentů, požadavků od autorizovaných uživatelů a dodavatelů, jejich prvotní kontrolu, klasifikaci a předání řešitelům na základě stanovených eskalačních procedur.

    • 2. úroveň podpory

Označuje první vrstvu řešitelů přijatého požadavku nebo incidentu. Typicky se jedná o pracovníky Poskytovatele.

    • 3. úroveň podpory

Označuje druhou vrstvu řešitelů, kteří provádějí vysoce specializované činnosti, např. metodicko-technické analýzy složitých problémů. Na straně Poskytovatele a dalších dodavatelů služeb ve smluvním vztahu s Objednatelem se jedná zejména o výrobce/dodavatele SW, případně jejich specializované servisní partnery.

Všechny záznamy procházející 1. až 3. úrovní podpory budou vedeny v systému Service Desk. Způsob řešení na 3. úrovni podpory je povinen do Service Desku zaznamenat řešitel 2. úrovně podpory, který 3. úroveň aktivoval.

  • Definice lhůt

    • Lhůta pro potvrzení přijetí

Je chápána jako doba od přijetí události od uživatele systému po odeslání potvrzení o jejím přijetí pracovníky zajišťujícími službu Service Desku tomuto uživateli (žadateli). Potvrzení o přijetí musí být odesláno systémem pro zasílání zpráv v rámci Service Desku.

    • Lhůta pro informování o způsobu a odhadu délky řešení

Je doba, jejímž začátkem je čas zaslání potvrzení o přijetí události žadateli a koncem je vlastní zaslání informací o způsobu řešení a odhadu délky vyřešení/vyřízení události zpět žadateli. V této době musí být od odpovědných pracovníků provozu nebo odpovědného subjektu získána základní informace o způsobu vyřešení/vyřízení události a rámcovém odhadu délky řešení.

    • Garantovaná doba zahájení řešení

Je doba od informování o způsobu a odhadu délky řešení po vlastní zahájení prací na řešení požadavku žadatele.

    • Lhůty pro vyřešení/uzavření požadavku/incidentu

Max. doba, která uplyne od okamžiku nahlášení incidentu na Service Desk 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/požadavku na změnu 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 funkčnosti.

    • Vyhodnocovací období (služby)

Vyhodnocovací období je doba, v rámci které se počítají stanovené SLA parametry a vyhodnocuje se jejich plnění. Standardní nastavení vyhodnocovacího období pro poskytování a vykazování služby je 1 kalendářní měsíc.

    • Doba obnovy (RTO=Recovery Time Objective)

Je kritérium, kterým se rozumí doba obnovy systémů v hodinách do časového bodu v minulosti. Dělí se na:

  • RTO/S je časové kritérium v hodinách, kterým se rozumí dosažená doba obnovy individuálního systému. Limitující podmínkou pro měření je skutečnost, že paralelně nesmí probíhat více než 3 další obnovy jiných systémů.

  • RTO/P je časové kritérium v hodinách, kterým se rozumí doba obnovy celého prostředí.

    • Návrat v čase (RPO=Recovery Point Objective) se rozlišuje následovně:

  • RPO/S je kritérium v hodinách definující maximální tolerovanou ztrátu dat, která nebudou obnovena při obnově individuálního systému.

  • RPO/P je kritérium v hodinách definující maximální tolerovanou ztrátu dat, která nebudou obnovena k určenému času v minulosti při obnově celého prostředí.

    • Retence záloh

Je kritérium ve dnech definující maximální dobu, po kterou je nutné udržovat operativní zálohy systémů. Definuje tak nejstarší bod v minulosti, ke kterému je možné systém z operativní zálohy obnovit.

    • Retence archívu

Je kritérium ve dnech definující maximální dobu, po kterou je nutné udržovat kvartální archívy systémů. Definuje tak nejstarší bod v minulosti, ke kterému je možné systém z archívu obnovit.

  • Definice dob

    • Pracovní doba Objednatele je doba od 07:00 do 19:00 hod.

Každý pracovní den v roce, po který je primárně Systém využíván zaměstnanci Objednatele.

    • Provozní doba (požadovaná/garantovaná provozní doba)

Je doba, ve které Objednatel nezbytně požaduje plnou funkční a využitelnou dostupnost všech funkčností a modulů. Provozní doba Systému je 7x24, která znamená zajištění služeb v pracovní i nepracovní dny 24 hodin denně.

    • Servisní okno

Je čas vymezený pro provádění servisních činností, údržby, profylaxe, zálohování a dalších činností, které neumožňují běžný provoz Systému. Využití tohoto času je podmíněno souhlasem Objednatele a uveřejněním oznámení na veřejné uživatelské části IS SZIF.

    • Plánovaná odstávka

Je doba, kdy bude Systém uveden na základě předchozí dohody Poskytovatele a Objednatele do stavu mimo provoz. Pokud se jedná o servisní odstávku mimo odstranění chyby nebo implementace provozní, či bezpečnostní aktualizace, je Poskytovatel povinen žádost o odstávku doručit Objednateli nejméně 14 kalendářních dní před požadovaným termínem plánované odstávky. Provedení odstávky je podmíněno souhlasem Objednatele. Poskytovatel se zároveň zavazuje, že jeho snahou bude tyto mimořádné odstávky směřovat do doby servisního okna. Plánované odstávky se nezapočítávají do celkové nedostupnosti systému a tedy do výsledného plnění SLA.

Do plánovaných odstávek nebo servisních oken se nepočítají:

  • časy výpadků infrastruktury, která není součástí služeb poskytovaných anebo zprostředkovaných Poskytovatelem,

  • časy výpadků navazujících aplikačních a jiných služeb, které nezajišťuje Poskytovatel,

  • výpadků dalších služeb, které jsou způsobené chybou pracovníků Poskytovatele,

  • časy incidentů nebo havárií.

3.3Služby provozu

V této kapitole definované katalogové listy stanovují, jaké konkrétní Služby provozu a v rámci těchto služeb realizované aktivity vyžaduje Objednatel jako součást plnění poskytování Služeb. Katalogové listy primárně nespecifikují konkrétní způsob realizace jednotlivých dílčích činností, které poskytování uvedených služeb zajišťují. Konkrétní způsob realizace aktivit a souvisejících činností bude upravovat provozní dokumentace, jejíž vytvoření je součástí implementačního projektu pro Implementaci Systému, kdy tato dokumentace bude rovněž předmětem Akceptačního řízení v rámci Implementace. Provozní dokumentace bude zahrnovat kompletní rozsah potřebných informací pro realizaci zejména Služeb provozu. Provozní dokumentace bude vytvořena v souladu s požadavky na dokumentaci stanovenými v rámci Zadávacího řízení a bude rovněž v souladu s Best Practice pro tvorbu a údržbu tohoto typu Dokumentace (tedy dokumentů i dokumentovaných informací). Kompletní provozní dokumentace bude klasifikována jako diskrétní a přístup k této dokumentaci bude mít zajištěn pouze projektově určený okruh pracovníků Poskytovatele i Objednatele.

Poskytovatel bere na vědomí, že plnění dle Xxxxxxx bude poskytovat v rámci Významného informačního systému – Informační systém platební agentury (ISPA), jehož správcem a provozovatelem je Objednatel a Poskytovatel je v tomto ohledu významným dodavatelem dle § 2 písm. n) VKB. S ohledem na uvedené je zapotřebí postupovat při plnění Služeb provozu zejm. v souladu se ZoKB, a v souladu s VKB, resp. tak, aby se Poskytovatel a Objednatel vyvarovali jakékoliv činnosti, jež by mohla být označena za porušení uvedených právních předpisů jimi samotnými nebo druhou smluvní stranou.

3.3.1IS01 – Provoz Systému

Označení

Název služby

IS01

Provoz Systému

Vymezení služby

Lokalita

Oddělené lokality Poskytovatele

Prostředí

PROD/TEST/DEV

Zkrácený popis služby

Veškeré provozní aktivity nezbytné pro zajištění korektního chodu Systému

Seznam komponent

  • K01 – Portálový systém

  • K02 – Notifikační komponenta (Notifikátor)

  • K03 – Formulářový server klientů veřejné správy

  • K04 – Formulářový server úřední osoby

  • K05 – Portálová aplikace XXXX pro žadatele

  • K06 – Portálová aplikace XXXX pro SZIF

BUDE DÁLE DOPLNĚNO PŘED PODPISEM SMLOUVY NA ZÁKLADĚ VÍTĚZNÉ NABÍDKY V SOULADU S PŘÍLOHOU Č. 7 SMLOUVY


Seznam aktivit

Aktivita

Obecný rozsah aktivity

Periodicita činnosti

A01 - Vlastní provoz a správa Systému

Zajištění standardního chodu Systému během provozní doby v režimu 7x24, kdy bude garantována kompletní funkčnost informačního systému.

Vyhodnocovací období

A02 - Aktualizace dat/kopie

Zajištění aktualizace dat v testovacím prostředí tak, aby bylo možné realizovat testování služeb rozvoje v souladu s dalšími částmi informačního systém SZIF. Předpoklad maximálně 6krát během kalendářního roku.

A03 - Pravidelné testování Systému

Pravidelné testy obnovy, dále zátěžové, integrační, bezpečnostní a další nezbytné testování Systému, aby byly naplněny požadavky na provoz Významného informačního systému Objednatele.

A04 - Poskytování součinnosti

Poskytování součinnosti při nezbytných interních i externích auditech a kontrolách realizovaných v prostředí Objednatele.

A05 - Programové/projektové řízení

Zajištění činností souvisejících s výkonem Programového a projektového řízení, v rámci něhož jsou veškeré služby poskytovány.

A06 - Správa dokumentace

Správa veškeré projektové a provozní dokumentace související s poskytováním služeb.

A07- Další administrativní činnosti

Ostatní administrativní činnosti nezbytné k zajištění výkonu služeb – zejména výkaznictví/reporting.

SLA parametry služby

Vyhodnocovací období

1 kalendářní měsíc



Označení

Název Aktivity

A01

Vlastní provoz a správa Systému

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel služby bude zajišťovat stálý provoz všech jednotlivých modulů a komponent Systému, jejichž Implementace byla předmětem Dodání Díla. Předmětem provozu je zajištění komplexního chodu Systému včetně zajištění anebo zprostředkování zajištění provozu všech využitých cloudových služeb v prostředí veřejného nebo privátního cloudu či obdobného prostředí Poskytovatele. Provoz bude zajištěn pro veškeré komponenty umístěné v prostředích:

- PROD

- TEST

- DEV


Předmětem služby je zajištění korektní funkcionality veškerých uvedených funkčností Systému pro uživatele Systému, a to v rozsahu akceptované specifikace vytvořené v rámci Implementace Díla a dílčích specifikací, jež jsou výstupem Služeb rozvoje Systému.

Předmětem služby je rovněž zajištění všech náležitostí pro korektní průběh integračních vazeb na jiné systémy v rozsahu akceptované specifikace.

Poskytovatel bude vykonávat všechny činnosti vedoucí k bezproblémovému chodu produktivního, testovacího a vývojového prostředí Systému.


Funkčnost prostředí musí odpovídat požadované dostupnosti (viz dále) a odezvám jednotlivých funkčností v souladu s akceptační a provozní dokumentací Systému. Díky sezonnímu charakteru některých prací v rámci administrace SZP může nárazově docházet k vyšším nárokům na provoz Systému.

Celkově bude systém zajišťovat funkčnost pro řádově 1000 interních uživatelů ze strany Objednatele (jmenných interních uživatelů) a řádově 30.000 externích uživatelů (jmenných externích uživatelů) přistupujících s využitím Portálové aplikace XXXX pro žadatele. Do budoucna je očekáván nárůst počtu uživatelů v souvislosti s implementací dalších portálových aplikací až na hodnotu 100.000 – 200.000 externích uživatelů (jmenných externích uživatelů), přičemž se předpokládá současný přístup maximálně 20.000 – 40.000 externích uživatelů (současných externích uživatelů).


Součástí provozu jsou komplexní expertní služby Poskytovatele nezbytné pro vlastní korektní fungování implementovaných funkčností dostupných v jednotlivých prostředích a modulech. Z hlediska provozu Systému je tedy za korektně provozované prostředí považováno takové prostředí, které je nejen dostupné a funkční, ale rovněž veškeré funkčnosti jsou dostupné určeným koncovým uživatelům/případně integrovaným aplikacím a systémům.

Doba zajištění aktivity

7x24 – provozní doba znamená zajištění služeb v pracovní i nepracovní dny 24 hodin denně.

Do provozní doby není započítávána doba pro Servisní okno. Servisní okno je definováno od soboty 00:00 do neděle 24:00 každý 1. víkend v měsíci, využití tohoto času je podmíněno souhlasem Objednatele (Vedoucí, nebo Garant Projektového týmu provozu).




SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Dostupnost – TEST/DEV

Za dostupné se považuje testovací/vývojové prostředí Systému, které poskytuje korektní fungování implementovaných a akceptovaných funkčností koncovému uživateli/systému.

95,2 % provozní doby

Do doby dostupnosti v rámci vyhodnocovacího období není započítávána doba, během které se vyskytne Vada Systému kategorie A, B, nebo X.

Xxxxxxxxx je definována v kapitole č. 4.

Dostupnost – PROD

Za dostupné se považuje produktivní prostředí Systému, které poskytuje korektní fungování implementovaných a akceptovaných funkčností koncovému uživateli/systému.

99,5 % provozní doby

Do doby dostupnosti v rámci vyhodnocovacího období není započítávána doba, během které se vyskytne Vada Systému kategorie A, B, nebo X.

Xxxxxxxxx je definována v kapitole č. 4.

Odezva – TEST/DEV

50 % provozní doby zobrazení stránky do 5 sekund (načtení viditelného obsahu stránky)

Do doby odezvy v rámci vyhodnocovacího období není započítávána doba, během které se vyskytne Vada Systému kategorie A, B, nebo X.

Xxxxxxxxx je definována v kapitole č. 4.

Odezva – PROD

90 % provozní doby zobrazení stránky do 5 sekund (načtení viditelného obsahu stránky)

Do doby odezvy v rámci vyhodnocovacího období není započítávána doba, během které se vyskytne Vada Systému kategorie A, B, nebo X.

Xxxxxxxxx je definována v kapitole č. 4.

Vada Systému Kategorie „A“ – Vysoká významnost

Popis vady:

Implementovanou Funkčnost není možné produktivně používat, neexistuje, nebo nebylo poskytnuto náhradní řešení. Chyba funkčnosti nebyla odstraněna do 2 hodin (kalkulováno v rámci Doby zajištění aktivity) od okamžiku nahlášení incidentu prostřednictvím Service Desku, rovněž v této lhůtě nebylo poskytnuto náhradní řešení.

Maximální počet Vad/vyhodnocovací období:


v PROD prostředí: 2

V TEST prostředí: N/A

Kreditace je definována v kapitole č. 4.

Vada Kategorie „B“ – Střední významnost

Popis vady:

Implementovanou Funkčnost není možné produktivně používat v plném rozsahu, Poskytovatel zajistil náhradní řešení. Chyba funkčnosti nebyla odstraněna do 16 hodin od nahlášení incidentu prostřednictvím Service Desku.

Maximální počet Vad/vyhodnocovací období:


v PROD prostředí: 3

V TEST prostředí: N/A

Kreditace je definována v kapitole č. 4.

Vada Kategorie „C“ – Nízká významnost

Popis vady:

Implementovanou Funkčnost je možné produktivně používat s dílčím omezením, které nemá vliv na samotné chování systému. Chyba funkčnosti nebyla odstraněna do 40 hodin od nahlášení Incidentu prostřednictvím Service Desku.

Maximální počet Vad/vyhodnocovací období:


v PROD prostředí: 5

V TEST prostředí: N/A

Kreditace je definována v kapitole č. 4.

Výpočet celkové dostupnosti Systému v průběhu vyhodnocovacího období:


Reálná doba dostupnosti (hod) = Požadovaná doba dostupnosti – Celková doba nedostupnosti v rámci Požadované doby dostupnosti


Kde Celková doba nedostupnosti v rámci Požadované doby dostupnosti se vypočte takto:

  • Budou vybrány všechny časové intervaly, v nichž se služba Systému nalézala ve stavu vady kategorie A, B a provede se sjednocení těchto intervalů. Tím dostaneme množinu časových intervalů, v nichž byla služba Systému nedostupná z důvodu vady.

  • Od této množiny odečteme průnik této množiny s množinou intervalů, po které trvaly plánované odstávky (v době plánované odstávky služba být dostupná nemusí).

  • Součet délek intervalů ve výsledné množině je Celková doba nedostupnosti v rámci Požadované doby dostupnosti.


Skutečná dostupnost (%) = Reálná doba dostupnosti (hod) / Požadovaná doba dostupnosti (hod)* 100


Výpočet odezvy Systému v průběhu vyhodnocovacího období:


Požadovaná doba v limitu odezvy (hod) = (počet dní v kalendářním měsíci*24 hodin) – Celková doba plánovaných odstávek v daném kalendářním měsíci (hod)


Reálná doba v limitu odezvy (hod) = Požadovaná doba v limitu odezvy – (Celková doba trvání Vad A (hod) + Celková doba trvání Vad B (hod) + Celková doba trvání Vad C (hod))


Skutečná odezva (%) = Reálná doba v limitu odezvy (hod) / Požadovaná doba v limitu odezvy (hod)

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění služby IS01

Pro akceptaci poskytování služeb v rámci vyhodnocovacího období bude zpracována souhrnná Zpráva o plnění služby IS01, která bude vycházet primárně z dat provozního monitoringu a dat Service Desku. Předmětem Zprávy o stavu plnění služby IS01 bude i soupis všech dob incidentů s vyznačením, který incident svojí dobou řešení a dopadem byl klasifikován jako Vada s vyznačením kategorie a doby trvání Vady dle stanovených SLA parametrů.

Tato Zpráva o plnění služby IS01 (pokrývající i další aktivity služby IS01) bude součástí souhrnné Zprávy o stavu provozu Systému zpracovávané v rámci služby IS03.

Pro akceptaci Zprávy o stavu provozu Systému se uplatní postup stanovený v rámci aktivity A15 služby IS03.

Způsob stanovení celkové ceny aktivity a fakturace

Měsíční paušální cena/komponenta

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) je stanovena jako součet paušálních jednotkových cen dané aktivity pro každou komponentu Systému.

V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, bude, po realizaci jednorázové služby, celková cena aktivity upravena (snížena) o jednotkovou cenu dané aktivity. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).





Označení

Název Aktivity

A02

Aktualizace dat/kopie

Rozsah aktivity

Popis (obsah) aktivity

Provozní aktivita na vyžádání


V rámci této aktivity zajistí Poskytovatel na vyzvání Objednatelem kopii produktivních dat do testovacího prostředí (TEST), aby bylo možné v testovacím prostředí zajistit kompletní simulaci interních business procesů Objednatele. Objednatel v rámci požadavku na provedení kopie specifikuje rozsah kopírovaných dat i dotčenou komponentu/komponenty tak, aby bylo možné kopii realizovat. Požadavek prostřednictvím Service Desku zašle Garant projektového týmu provozu, nebo Vedoucí projektového týmu provozu (za Objednatele) prostřednictvím Service Desku. Tito jediní pracovníci Objednatele jsou oprávněni autorizovat provedení Aktualizace/kopie dat.

Kopie dat musí být realizována takovým způsobem, aby nezpůsobila nekonzistence v aplikační logice připraveného testovacího prostředí. Kopie funkcionalit, ve které dojde k nahrazení aplikační logiky testovacího prostředí je možná pouze na výslovné schválení či požadavek Objednatele. V případě, že se Poskytovatel a provozovatel infrastruktury dohodnou, že existuje vhodnější způsob přípravy kopie dat (například klon systému), je toto možné realizovat pouze v případě schválení navrhovaného řešení uvedenými kontaktními osobami.

Doba zajištění aktivity

Na vyžádání max. 12 krát během 1 kalendářního roku.




SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Požadovaná kopie dat do testovacího prostředí. Součástí kopie bude provedení odpovídajících systémových testů deklarujících úspěšné provedení kopie dat.

Potvrzená realizace kopie dat.

Písemné potvrzení ze strany Poskytovatele o provedení kopie dat potvrzené zástupcem provozovatele.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění služby IS01

Potvrzení o realizované kopii dat včetně doložení výsledků odpovídajících systémových testů bude součástí Zprávy o plnění služby IS01 dle charakteristiky v aktivitě A01. Zpráva o plnění služby IS01 je součástí Zprávy o stavu provozu Systému.

Pro akceptaci Zprávy o stavu provozu Systému se uplatní postup stanovený v rámci aktivity A15 služby IS03.

Způsob stanovení celkové ceny aktivity

Celková cena aktivity/rok = Jednorázová paušální cena*12

Celková Cena aktivity (stanovená pro kalendářní rok) je stanovena jako násobek jednorázových paušálních cen dané aktivity a maximálního počtu výskytů aktivity v kalendářním roce. Jednorázová cena je stanovena jako neměnná. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, zůstane, po realizaci jednorázové služby, jednorázová paušální cena konstantní. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace bude vždy realizována k období, ve kterém byla aktivita čerpána.



Označení

Název Aktivity

A03

Pravidelné testování Systému

Rozsah aktivity

Popis (obsah) aktivity

Provozní aktivita na vyžádání


Tato aktivita bude primárně realizována v rámci ověřování nastavení služeb, nastavení funkčnosti provozní a architektonické dokumentace. Aktivita Pravidelného testování primárně nezahrnuje testování, které bude realizované v rámci poskytování Služeb rozvoje. Předmětem pravidelného testování je:


  1. Realizace kompletního testu obnovy Systému


V souladu s povinnostmi definovanými ISO 27001 má Objednatel povinnost realizovat testy obnovy systémů, jejichž provoz spadá do rozsahu ISMS. Vzhledem k tomu, že Služby poskytované Poskytovatelem dále spadají do kategorie Služeb Významného dodavatele z hlediska ZoKB, požaduje Objednatel provedení Kompletního testu obnovy Systému. Předmětem Kompletního testu obnovy je: Postavení a obnova systémů na základě definované dokumentace a ze zdrojových kódů a konfigurací, jejichž kontinuální aktualizace musí Poskytovatel zajišťovat. V rámci Kompletního testu obnovy bude realizováno kompletní postavení Systému a provedena kontrola:

  • Kompletnosti funkcionality Systému

  • Úplnosti Aplikace obsahující všechny požadované funkčnosti

  • Aktuálnosti všech verzí jednotlivých komponent v souladu s provozní dokumentací a předchozím stavem


Test obnovy bude proveden do zvlášť připravené infrastruktury v prostředí Poskytovatele.

V době testu obnovy budou zablokována veškerá přístupová práva do vytvářené instance tak, aby nemohlo dojít ke zneužití dat ani pouhým zobrazením nepovolané osobě. Po otestování funkcionalit obnoveného Systému budou všechna data z této instance prokazatelně vymazána.

Všechny kroky testu obnovy budou podrobně zapisovány (kdo, co a jak prováděl). Souběžně bude provedena kontrola popisu postupů v příslušné dokumentaci, zda rozsahem a úplností vyhovují. Všechny tyto informace budou přehledně, čitelně a srozumitelně uvedeny v protokolu a kompletnost protokolu bude podmínkou jeho převzetí Objednatelem.

Kompletní test obnovy se provádí jednou ročně, a to výslovně na vyžádání Objednatelem (prostřednictvím Service Desku) v termínu, který Objednatel stanoví minimálně 14 kalendářních dní předem. Kompletní test obnovy může podléhat dohledu auditu ISMS, a to jak internímu, tak certifikačnímu. Poskytovatel v takovém případě umožní dohled auditorů na provádění testů obnovy.


  1. Pravidelné testování Systému

V rámci poskytovaných provozních služeb zajistí Poskytovatel na vyžádání Objednatelem (prostřednictvím Service Desku) realizaci testování Systému. Toto testování bude realizováno zpravidla jednou ročně mimo Kompletní testy obnovy. V případě potřeby jej lze realizovat dle dohody vícekrát, rovněž aktivita nemusí být v kalendářním roce poptána. Účelem tohoto testování je, mimo testů v rámci rozvojových služeb, potvrdit nastavení Systému, zda je služba Systému dostatečně výkonově dimenzována, zda je celková architektura systému nastavena v souladu s Best Practice i požadavky na bezpečnost informačních systémů veřejné správy.

Předmětem testů bude realizace následující množiny testů (případně podmnožiny dle výběru Objednatele):

  • Funkční testy

  • Uživatelské testy

  • Integrační testy

  • Testy interní integrity dat

  • Bezpečnostní testy

  • Zátěžové testy

Doba zajištění aktivity

1krát ročně v termínu stanoveném Objednatelem – kompletní test obnovy

1krát ročně v termínu stanoveném Objednatelem – pravidelné testování Systému

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Ověření funkčnosti provozních postupů pro provedení obnovy Systému.

Test obnovy potvrdí, že definované postupy obnovy jsou validní.

Akceptace provedení testu obnovy.

Kreditace je definována v kapitole č. 4.

Ověření aktuálnosti zdrojových kódů, modelů Systému.

Test obnovy potvrdí, že veškerá dokumentace Systému (včetně zdrojových kódů) je aktuální a validní.

Akceptace ověřené dokumentace.

Kreditace je definována v kapitole č. 4.

Ověření nastavení Systému. Za součinnosti Objednatele i Poskytovatele budou definovány konkrétní testovací scénáře a procedury k ověření stanovených scénářů. Na základě realizovaných testů dojde k vyhodnocení stavu Systému.

Realizovaná množina testů ověří, že Systém je implementován, rozvíjen a provozován v souladu s odpovídajícími požadavky dle Best Practice.

Na základě vyhodnocení bude zpracována finální zpráva o provedení Pravidelného testování Systému, která bude zahrnovat výsledky prováděných testů a případná doporučení pro Objednatele i Poskytovatele pro další období.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Protokoly testů obnovy

V rámci realizovaného testování budou zpracovávány Protokoly testů o provedení testů, jejichž předmětem je potvrdit korektnost definovaných provozních postupů pro obnovu Systému i aktuálnost odpovídající dokumentace Systému. Finálním dokumentem bude Akceptační protokol o provedení Kompletního testu obnovy a Zpráva o provedení Pravidelného testování. Veškeré dokumenty, které budou vznikat v rámci této aktivity, budou předmětem souhrnné Zprávy o stavu provozu Systému předávané v rámci Vyhodnocovacího období, ve kterém byla Aktivita akceptována.

Pro akceptaci Akceptačního protokolu o provedení Kompletního testu obnovy a Zprávy o provedení pravidelného testování se uplatní obecná akceptační kritéria pro předávání dokumentace dle Smlouvy.

Celková cena aktivity/rok = jednorázová cena kompletního testu obnovy + jednorázová cena pravidelného testu obnovy

Celková Cena aktivity (stanovená pro kalendářní rok) je stanovena jako součet jednorázové ceny kompletního testu obnovy a jednorázové ceny pravidelného testu obnovy dané aktivity a maximálního počtu výskytů aktivity v kalendářním roce. Jednorázová cena kompletního testu obnovy i jednorázová cena pravidelného testu obnovy jsou stanoveny jako neměnné. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, zůstanou, po realizaci jednorázové služby, jednorázové ceny testu obnovy konstantní. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace bude vždy realizována k období, ve kterém byla aktivita skutečně čerpána.





Označení

Název Aktivity

A04

Poskytování součinnosti

Rozsah aktivity

Popis (obsah) aktivity

Provozní aktivita na vyžádání


Vzhledem k tomu, že Systém je součástí informačního prostředí IS SZIF, v rámci něhož je realizována administrace Společné zemědělské politiky, mohou postupy realizované prostřednictvím Systému podléhat auditnímu, kontrolnímu, či jinému šetření ze strany nadřízených orgánů SZIF. Zároveň s ohledem na skutečnost, že Poskytovatel je Významným dodavatelem dle § 2 písm. n) vyhlášky o kybernetické bezpečnosti (VKB), je Systém předmětem auditních šetření z hlediska kybernetické bezpečnosti. Pro zajištění odpovídajících průběhů šetření požaduje Objednatel, aby Poskytovatel zajistil odpovídající součinnost, která bude spočívat zejména v předložení dokumentace, ukázce aplikačního prostředí Systému, případně v jiné podobě.

Poskytovatel je povinen umožnit Objednateli bez zbytečného odkladu provedení kontrolního auditu plnění povinností Poskytovatele dle této Smlouvy v oblasti kybernetické bezpečnosti ve smyslu ZoKB, a jeho prováděcích právních předpisů, zejména VKB (dále jen „kontrolní audit“). Objednatel je oprávněn kontrolní audit provádět v případech dle VKB a dále v případech vzniku potřeby provedení takového kontrolního auditu:

- na základě výsledků provedení interního nebo externího auditu u

Objednatele nebo

- z důvodu zajištění provedení interního nebo externího auditu u Objednatele

- na základě interních právních předpisů Objednatele nebo obecně závazných právních předpisů.

Objednatel je oprávněn kontrolní audit provádět v místě plnění Služeb dle této Smlouvy, tedy i v Sídle Poskytovatele. Kontrolní audit bude vždy proveden na základě předem Poskytovateli doručeného písemného oznámení obsahujícího mj. vymezení předmětu a důvodu provedení kontrolního auditu a za přítomnosti zaměstnance Poskytovatele. Je-li to objektivně možné, Objednatel

doručí písemné oznámení Poskytovateli alespoň 10 pracovních dnů před plánovaným dnem zahájení kontrolního auditu. Poskytovatel je povinen poskytnout Objednateli pro provedení kontrolního auditu veškerou potřebnou

součinnost, kterou po něm lze rozumně požadovat. Kontrolní audit může být proveden přímo zaměstnanci Objednatele nebo prostřednictvím třetí osoby, která bude vázána povinností mlčenlivosti a která bude k auditu vybrána osobou, která audit nařídila, nebo která byla k výběru takovéto osoby pověřena osobou, která audit nařídila. Na veškeré informace, které Objednatel na základě kontrolního auditu získá, se vztahuje režim ochrany informací a Objednatel je povinen zajistit jeho plnění všemi osobami, které ke kontrolnímu auditu užije.

Maximální objem požadované součinnosti nepřekročí 18 MD ročně.

Požadavek na součinnost zašle kontaktní osoba Objednatele za tuto oblast – Vedoucí programu (za Objednatele) prostřednictvím Service Desku s definicí konkrétních požadovaných oblastí, pro které je součinnost požadována, na Vedoucího programu (za Poskytovatele)

Doba zajištění aktivity

Dle potřeby v Pracovní době Objednatele.

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Na základě definovaného Požadavku na součinnost je tato poskytnuta odpovídajícími pracovníky Poskytovatele v odpovídajících projektových rolích.

Součinnost je poskytnuta.

Potvrzení že byla součinnost Poskytnuta v rámci Zprávy o plnění služby IS01.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění služby IS01

Potvrzení o poskytnutí požadované součinnosti bude předmětem Zprávy o plnění služby IS01 za odpovídající Vyhodnocovací období včetně uvedení ve Výkazu činností. Zpráva o plnění služby IS01 je součástí Zprávy o stavu provozu Systému.

Pro akceptaci Zprávy o stavu provozu Systému se uplatní postup stanovený v rámci aktivity A15 služby IS03.

Celková cena aktivity/rok = paušální cena za MD*18

Celková Cena aktivity (stanovená pro kalendářní rok) je stanovena jako násobek paušálních jednotkových cen za MD a maximálního počtu poptávaných MD součinnosti v kalendářním roce. Paušální jednotková cena za MD je stanovena jako neměnná. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, zůstane, po realizaci jednorázové služby, paušální jednotková cena konstantní. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace bude vždy realizována k období, ve kterém byla aktivita čerpána.



Označení

Název Aktivity

A05

Programové/projektové řízení

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Předmětem uvedené aktivity je zajištění odpovídajícího výkonu činností jednotlivých členů provozního týmu Poskytovatele, aby bylo možné poskytování služeb realizovat v souladu s principy Programového a projektového řízení dle kapitoly č. 2 tohoto dokumentu. V rámci činností Programového a projektového řízení se jedná primárně o:

  • Fungování v rámci projektových týmů.

  • Definice cílů a sestavení plánu prací projektového týmu.

  • Koordinace členů projektového týmu Objednatele i Poskytovatele.

  • Veškerá nezbytná Projektová administrativa (projektové pozvánky, zpracování zápisu, dokumentace, atd.).

  • Vyhodnocení plnění činností projektového týmu.

  • Koordinace aktivit s ostatními projektovými týmy.

  • Průběžná analýza rizik.

Projektové principy budou realizovány ve stanovené Programové struktuře a obsahují formální náležitosti (např. pravidelná jednání projektových týmů). Detailní nastavení principů Programového/projektového řízení pro poskytování Služeb bude realizováno v době implementace Systému na základě oboustranně odsouhlasených charakteristik řízení Programu a v souladu s požadavky a harmonogramem hlavního integračního projektu IS XXXX. Programové a projektové principy musí být nastaveny v souladu s ustanoveními této přílohy č. 3 Smlouvy a využívaných Best Practice pro řízení projektových týmů a projektů v rámci Programu.

Doba zajištění aktivity

Dle potřeby v Pracovní době Objednatele.

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Veškeré činnosti související s poskytováním Služeb budou realizovány prostřednictvím odpovídajících Programových a projektových principů.

Veškeré činnosti související s poskytováním Služeb budou realizovány prostřednictvím odpovídajících Programových a projektových principů.

Veškeré činnosti pracovníků Poskytovatele budou formálně vykazovány v rámci v rámci Výkazů plnění služby IS01.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Výkazy činností ve Zprávě o stavu provozu Systému

V rámci Výkazů činností zpracovávaných jako součást Zprávy o stavu provozu Systému za odpovídající Vyhodnocovací období budou uvedeny veškeré činnosti pracovníků Poskytovatele vykonávajících tyto aktivity.

Pro akceptaci Zprávy o stavu provozu Systému se uplatní postup stanovený v rámci aktivity A15 služby IS03.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena/komponenta

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) je stanovena jako součet paušálních jednotkových cen dané aktivity pro každou komponentu Systému. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, bude, po realizaci jednorázové služby, celková cena aktivity upravena (snížena) o jednotkovou cenu dané aktivity. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).



Označení

Název Aktivity

A06

Správa dokumentace

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Prostřednictvím této aktivity je zajištěna komplexní správa provozní i projektové dokumentace. Detailní postupy správy dokumentace budou nastaveny v rámci realizace Implementačního projektu. Níže stanovené principy jsou pro údržbu dokumentace stanovené jako závazné:

  • Provozní a projektová dokumentace je primárně ukládána v prostředí Objednatele, který poskytne pracovníkům Poskytovatele odpovídající přístupy.

  • Jazyk dokumentace vytvářené v rámci poskytování služeb je čeština. Detailní rozsah projektové a provozní dokumentace bude odpovídat definovaným požadavkům a bude v souladu s mezinárodně uznávanými Best Practice. Kde je to vhodné, bude využit princip dokumentované informace v elektronické podobě, který bude preferován před standardním dokumentem v papírové podobě.

  • Analytická a implementační dokumentace obsahuje i architektonické modely a komentované zdrojové kódy. Tato dokumentace je pravidelně aktualizována a předávána Objednateli.

  • Poskytovatel má povinnost zpracovávat odpovídající bezpečnostní dokumentaci v takovém rozsahu, aby bylo možno plnit požadavky ISO/IEC 27 001 a ZoKB v aktuálním znění včetně prováděcích předpisů.

  • Poskytovatel má povinnost udržovat aktuální dokumentaci zpracování OÚ v takovém rozsahu, aby bylo možno plnit požadavky GDPR a ZZOÚ v aktuálním znění včetně prováděcích předpisů.

  • Dokumentace API rozhraní je dodávána ve formě WSDL/XSD či specifikace dle standardu OpenAPI, Podpora publikace WSDL či OpenAPI (JSON).

  • Veškerá projektová i provozní dokumentace je verzována a jsou nastavené principy proti její neautorizované modifikaci.

  • Dokumentace výrobců je uchovávána v originální podobě a není modifikována. Při jejím využití případně vzniká nová dokumentace Poskytovatele.

  • Dokumentace je maximálně standardizovaná. Závazné šablony Projektové dokumentace jsou stanoveny v kapitole č. 5. Tyto šablony je možné modifikovat pouze na základě odsouhlasení ŘVPG.

  • Poskytovatel předá s každou novou verzí Systému zdrojové kódy a související konfigurační soubory k veškerému softwarovému vybavení, které vytvořil v rámci plnění. Pro předání zdrojových kódů bude definován mechanismus, který zabezpečí ochranu proti manipulaci médií se zdrojovými kódy. Mimo to budou zdrojové kódy spravovány a řízeny v systému pro správu zdrojových kódů, který je součástí poskytovaných služeb. Tento systém bude zároveň využit jako zdroj pro překlad a nasazení verzí Systému do všech prostředí.

  • Poskytovatel aktualizuje provozní dokumentaci popisující z pohledu správce (administrátora) činnosti nezbytné pro zajištění chodu Systému. Součástí provozní dokumentace jsou procedury, které zahrnují provozní postupy údržby Systému, plány obnovy Systému, zálohovací plány a postupy archivace. Dokumentace popisuje stav systému v jednotlivých prostředích. Provozní dokumentace se skládá z Provozní příručky a Příručky správce aplikace.

  • Poskytovatel použije pro popis řešení v dokumentaci pouze standardizované modelovací jazyky (ArchiMate 3, UML 2.5, BPMN 2). Všechny vytvořené modely bude Poskytovatel ukládat do EA repository na straně SZIF.

  • Poskytovatel použije standardizovanou strukturu EA repository a bude udržovat repository modelů v aktuálním stavu.

  • Poskytovatel bude při tvorbě modelů využívat v maximální možné míře dostupné sdílené prvky (jsou-li na straně Objednatele k dispozici) ze sdíleného repository SZIF v souladu s modelovacím standardem.

  • Poskytovatel provede aktualizaci EA modelu ve sdíleném repository SZIF před každým plánovaným releasem realizovaným v návaznosti na změnu Systému s dopadem do architektury.

  • Pro modelování budou definované zásady a pravidla. Jde zejména o dodržování jmenných konvencí, obecných zásad pro čitelnost a srozumitelnost a také dodržování pravidelného verzování modelů.

  • V případě implementace změny, která má dopad na architekturu systému, provede Poskytovatel revizi analytické dokumentace, která je předmětem implementace Systému.

  • Poskytovatel udržuje vývojářskou dokumentaci neustále aktuální.

  • Poskytovatel udržuje instalační dokumentaci neustále aktuální.

  • Poskytovatel udržuje dokumentaci pro obnovu Systému neustále aktuální.


Forma i obsah projektové a provozní dokumentace budou pravidelně přezkoumávány prostřednictvím auditu ISMS.

Doba zajištění aktivity

Kontinuálně po celou dobu plnění Smlouvy

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Dokumentace Systému musí být neustále aktuální a spravována v souladu se stanovenými pravidly i Best Practice.

Audit ISMS potvrdí, že Provozní a projektová dokumentace Systému je aktuální a spravována v souladu se stanovenými pravidly i Best Practice.

Výrok auditora ISMS k dokumentaci Systému musí být z hlediska Poskytovatele „bez zjištění“, nebo „nebyla zjištěna neshoda“. Může být „doporučení“, nebo „Námět ke zlepšení“.

Kreditace je definována v kapitole č. 4.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Provozní a projektová dokumentace

Veškerá dokumentace je aktuální, platná a v odpovídající podobě.

Pro akceptaci dokumentace se uplatní obecná akceptační kritéria pro předávání dokumentace dle Smlouvy.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena/komponenta

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) je stanovena jako součet paušálních jednotkových cen dané aktivity pro každou komponentu Systému. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, bude, po realizaci jednorázové služby, celková cena aktivity upravena (snížena) o jednotkovou cenu dané aktivity. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).



Označení

Název Aktivity

A07

Další administrativní činnosti

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel v rámci realizace služeb zajistí na své straně veškeré další administrativní činnosti nezbytné k zajištění korektního poskytování Služeb. Tyto administrativní činnosti nejsou přímo spojené s vlastním poskytováním Služeb provozu Systému, ale vztahují se ke kompletnímu poskytování Služeb v rámci uzavřené Smlouvy. Administrativní činnosti budou v rámci Výkazů činností ve Zprávě o plnění služby IS01 označeny odpovídající identifikací S01A08 bez identifikace konkrétního modulu/ technologie, ke které se vztahují. Objednatel požaduje vykazování i těchto aktivit zejména s ohledem na zajištění informační bezpečnosti, jelikož v rámci realizace Služeb bude docházet k výměně dokumentace klasifikované jako „Diskrétní“.

Doba zajištění aktivity

Dle potřeby Poskytovatele

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Bez vyhodnocení

Bez vyhodnocení

Bez vyhodnocení

Požadované výstupy aktivity




Výkazy činností ve Zprávě o stavu provozu Systému

V rámci Výkazů činností zpracovávaných jako součást Zprávy o stavu provozu Systému za odpovídající Vyhodnocovací období budou uvedeny veškeré činnosti pracovníků Poskytovatele vykonávajících tyto aktivity.

Pro akceptaci Zprávy o stavu provozu Systému se uplatní postup stanovený v rámci aktivity A15 služby IS03.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) je stanovena jako paušální cena dané aktivity pro celý Systém, kdy tato cena je neměnná. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, zůstává paušální cena aktivity konstantní. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).



3.3.2IS02 – Údržba Systému

Označení

Název služby

IS02

Údržba Systému

Vymezení služby

Lokalita

Oddělené lokality Poskytovatele

Prostředí

PROD/TEST/DEV

Zkrácený popis služby

Technické zajištění činností nezbytných pro chod Systému

Seznam komponent

  • K01 – Portálový systém

  • K02 – Notifikační komponenta (Notifikátor)

  • K03 – Formulářový server klientů veřejné správy

  • K04 – Formulářový server úřední osoby

  • K05 – Portálová aplikace XXXX pro žadatele

  • K06 – Portálová aplikace XXXX pro SZIF

BUDE DÁLE DOPLNĚNO PŘED PODPISEM SMLOUVY NA ZÁKLADĚ VÍTĚZNÉ NABÍDKY V SOULADU S PŘÍLOHOU Č. 7 SMLOUVY

Seznam aktivit

Aktivita

Obecný rozsah aktivity

Periodicita činnosti

A08 - Bezpečnostní aktualizace Systému

Realizace testování a instalace bezpečnostních záplat/patchů/aktualizací a dalších operací nezbytných pro zajištění informační a kybernetické bezpečnosti Systému – primárně mimo Pracovní dobu Objednatele.

Vyhodnocovací období

A09 - Provozní aktualizace Systému

Realizace testování a instalace provozních záplat/patchů/aktualizací a dalších operací nezbytných pro zajištění informační a kybernetické bezpečnosti Systému – mimo Pracovní dobu Objednatele.

A10 - Správa maintenance licencí Systému

Na základě pověření Objednatele - zajištění komunikace s výrobci SW technologií ohledně maintenance daných technologií, budou-li pro realizaci Díla vyžadovány.

A11 - Optimalizace chodu Systému

Na základě monitoringu provozu Systému optimalizace systémových nastavení pro zajištění provozu Systému.

A12 - Opravy chyb

Na základě monitoringu provozu Systému a identifikovaných chyb/vad Systému zajištění a koordinace nezbytné pro standardní chod Systému.

SLA parametry služby

Vyhodnocovací období

1 kalendářní měsíc



Označení

Název Aktivity

A08

Bezpečnostní aktualizace Systému

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel je povinen zajistit odpovídající stav Systému tak, aby byla zajištěna adekvátní úroveň kybernetické a informační bezpečnosti. Na základě této povinnosti bude Poskytovatel provádět realizaci bezpečnostních aktualizací Systému, kdy předmětem aktualizací bude instalace, implementace, nastavení maximálně možných opatření pro zajištění ochrany dat Objednatele i ochrany samotného Systému.

Na základě aktivity bezpečnostního monitoringu, doporučení a požadavků jednotlivých výrobců technologických komponent a využitých služeb zajistí Poskytovatel implementaci bezpečnostních částí kódu, patchů, záplat a dalších programových částí v souladu s doporučením výrobce či poskytovatelem využitých služeb. Pokud se nejedná o aktualizaci kritickou, bez které by byla zásadním způsobem ohrožena bezpečnost Systému, bude realizace bezpečnostních aktualizací primárně probíhat dvou-krokově:

  1. Aktualizace DEV a TEST prostředí včetně nezbytného otestování stavu Systému a následné ověření při standardním užívání testovacího prostředí.

  2. Aktualizace PROD prostředí včetně nezbytného otestování stavu Systému. Aktualizace PROD prostředí bude realizována minimálně s odstupem 14 kalendářních dnů, pokud je to možné a vhodné.

Provozovatel před aktualizací komponent zajistí mimořádnou zálohu Systému.

Poskytovatel zašle požadavek na realizaci bezpečnostní aktualizace na Bezpečnostního manažera (za Objednatele) s uvedením navrhovaného harmonogramu provedení aktualizací a identifikací předpokládaných dopadů realizace bezpečnostních aktualizací. Bezpečnostní manažer neprodleně požadavek posoudí, ověří v rámci projektových struktur Objednatele vhodnost termínu a rozhodne o realizaci požadavku, případně ve spolupráci s Analytikem bezpečnosti (za Poskytovatele) navrhne náhradní termín.

Po realizaci bezpečnostní aktualizace bude provedena aktualizace příslušné provozní a projektové dokumentace. Toto bude uvedeno ve Zprávě o plnění služby IS02.

Doba zajištění aktivity

V případě, že se nejedná o kritickou bezpečnostní záplatu, bude aktivita realizována mimo Pracovní dobu Objednatele.

V případě, že se jedná o kritickou bezpečnostní záplatu, může být aktivita realizována po schválení Objednatelem v Pracovní době. V takovém případě, pokud bude po dobu aktivity přerušen provoz Systému, se jedná o Plánovanou odstávku.

V případě bezvýpadkové bezpečnostní záplaty cloudových služeb je možné aplikovat záplatu kdykoliv v průběhu Provozní doby systému.

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Zajištění odpovídajícího stavu bezpečnosti aplikačního prostředí Systému.

Plná bezpečnost používaných technologií v souladu s doporučeními výrobce či poskytovatele využitých služeb.

Jedná se o plnou odpovědnost Poskytovatele, v případě nezajištění, bude toto řešeno v souladu s ustanoveními ZoKB a Smlouvy.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění služby IS02

V rámci Zprávy o plnění služby IS02 bude identifikováno, jaké bezpečnostní aktualizace byly realizovány ve vyhodnocovacím období. Tato Zpráva o plnění služby IS02 (pokrývající i další aktivity služby IS02) bude součástí souhrnné Zprávy o stavu provozu Systému zpracovávané v rámci služby IS03.

Pro akceptaci Zprávy o stavu provozu Systému se uplatní postup stanovený v rámci aktivity A15 služby IS03.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena/komponenta

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) je stanovena jako součet paušálních jednotkových cen dané aktivity pro každou komponentu Systému. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, bude, po realizaci jednorázové služby, celková cena aktivity upravena (snížena) o jednotkovou cenu dané aktivity. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).



Označení

Název Aktivity

A09

Provozní aktualizace Systému

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel je povinen zajistit odpovídající stav Systému tak, aby byla zajištěna adekvátní úroveň provozního prostředí Systému. Na základě této povinnosti bude Poskytovatel provádět realizaci provozních aktualizací Systému, kdy požadovaným stavem je zajištění plně aktuálního aplikačního prostředí Systému, využité infrastruktury a služeb v souladu s doporučeními výrobce či poskytovatele využitých služeb. Předmětem aktualizací tak bude instalace, implementace, nastavení provozních částí kódu, patchů, záplat a dalších programových částí v souladu s doporučením výrobce či poskytovatele služeb.

Tyto aktualizace budou realizovány zejména na základě výstupů provozního monitoringu, doporučení a požadavků jednotlivých výrobců technologických komponent a poskytovatelů služeb. Pokud se nejedná o aktualizaci kritickou, která by mohla zásadním způsobem ohrozit stabilitu provozního prostředí Systému, bude realizace provozních aktualizací primárně probíhat dvou-krokově:

  1. Aktualizace DEV a TEST prostředí včetně nezbytného otestování stavu Systému a následné ověření při standardním užívání testovacího prostředí.

  2. Aktualizace PROD prostředí včetně nezbytného otestování stavu Systému. Aktualizace PROD prostředí bude realizována minimálně s odstupem 28 kalendářních dnů, pokud je to možné a vhodné.


Provozovatel před aktualizací zajistí mimořádnou zálohu Systému.

V případě cloudového prostředí se předpokládá průběžná aktualizace všech využitých cloudových služeb v DEV, TEST i PROD prostředí bez dopadu na dostupnost hostovaných aplikačních částí Systému.

Poskytovatel zašle požadavek na realizaci bezpečnostní aktualizace na Vedoucího projektového týmu provozu (za Objednatele) s uvedením navrhovaného harmonogramu provedení aktualizací a identifikací předpokládaných dopadů realizace provozních aktualizací. Vedoucí projektového týmu provozu neprodleně požadavek posoudí, ověří v rámci projektových struktur Objednatele vhodnost termínu a rozhodne o realizaci požadavku, případně ve spolupráci s Vedoucím týmu provozu (za Poskytovatele) navrhne náhradní termín.

Po realizaci provozní aktualizace bude provedena aktualizace příslušné provozní a projektové dokumentace. Toto bude uvedeno ve Zprávě o plnění služby IS02.

Doba zajištění aktivity

V případě, že se nejedná o kritickou provozní aktualizaci, bude aktivita realizována mimo Pracovní dobu Objednatele.

V případě, že se jedná o kritickou provozní aktualizaci, může být aktivita realizována po schválení Objednatelem v Pracovní době. V takovém případě, pokud bude po dobu aktivity přerušen provoz Systému, se jedná o Plánovanou odstávku.

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Zajištění odpovídajícího stavu provozního aplikačního prostředí Systému.

Plně stabilní provozní prostředí Systému nastavené a provozované dle doporučení výrobců.

Jedná se o plnou odpovědnost Poskytovatele, v případě nezajištění, bude toto řešeno v souladu s ustanoveními ZoKB a Smlouvy.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění služby IS02

V rámci zprávy o plnění služby IS02 bude identifikováno, jaké provozní aktualizace byly realizovány ve vyhodnocovacím období. Zpráva o plnění služby IS02 je součástí Zprávy o stavu provozu Systému.

Pro akceptaci Zprávy o stavu provozu Systému se uplatní postup stanovený v rámci aktivity A15 služby IS03.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena/komponenta

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) je stanovena jako součet paušálních jednotkových cen dané aktivity pro každou komponentu Systému. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, bude, po realizaci jednorázové služby, celková cena aktivity upravena (snížena) o jednotkovou cenu dané aktivity. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).



Označení

Název Aktivity

A10

Správa maintenance licencí Systému

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel na základě pověření Objednatelem bude zajišťovat správu maintenance jednotlivých SW produktů využitých v rámci provozu Systému, budou-li pro výstavbu systému vyžadovány. Vzhledem k expertním znalostem Poskytovatele bude Poskytovat podpůrné a poradenské služby z hlediska maintenance a sledování využití licencí jednotlivých SW produktů. V rámci zprávy o plnění služby IS02 bude Poskytovatel uvádět, jaké je současné využití SW licencí dodávaných produktů a provádět analytické predikce s výhledem stavu licencí na následujících 6 kalendářních měsíců. V případě, že Poskytovatel identifikuje riziko porušení licenčních podmínek či vyčerpání množství disponibilních licencí, uvede v rámci zprávy o plnění služby variantní návrh možných řešení a pokud je to možné i finanční dopad uvedených variant.


Poskytovatel bude rovněž, v rámci správy maintenance, vyhodnocovat dobu podpory SW produktů ze strany výrobce. V případě, že bude identifikováno riziko ukončení podpory výrobce během budoucích 24 kalendářních měsíců, bude toto prostřednictvím Vedoucího programu (za Poskytovatele) eskalovat jako významné riziko na úroveň Hlavního týmu programu.


Objednatel, pokud toto umožní licenční podmínky jednotlivých výrobců SW produktů, zajistí odpovídající úroveň přístupu do prostředí výrobců SW na úrovni sekundární kontaktní osoby Objednatele (na straně Objednatele musí být vždy jedna kontaktní osoba zachována).


Samotná platba maintenance licencí je předmětem licenčních podmínek jednotlivých výrobců a bude hrazena nezávisle na Službách provozu. Maintenance licencí zahrnuje i cenu případné subskripce.

Doba zajištění aktivity

Kontinuálně po dobu plnění Smlouvy, pokud to umožní licenční podmínky výrobců SW.

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Známý stav licencí a maintenance licencí jednotlivých výrobců SW produktů.

Konkrétní hodnota využití licencí.

Identifikované riziko v případě končící podpory výrobce SW v nadcházejících 24 měsících.

Všechna rizika týkající se využití licencí SW produktů výrobců budou identifikována včas.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění služby IS02

Součástí Zprávy o plnění služby IS02 bude část vztahující se k využití licencí a maintenance licencí. Zpráva o plnění služby IS02 je součástí Zprávy o stavu provozu Systému.

Pro akceptaci Zprávy o stavu provozu Systému se uplatní postup stanovený v rámci aktivity A15 služby IS03.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena/komponenta

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) je stanovena jako součet paušálních jednotkových cen dané aktivity pro každou komponentu Systému. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, bude, po realizaci jednorázové služby, celková cena aktivity upravena (snížena) o jednotkovou cenu dané aktivity. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).



Označení

Název Aktivity

A11

Optimalizace chodu Systému

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Na základě vyhodnocení dat provozního monitoringu aplikační vrstvy Systému bude Poskytovatel analyzovat chování Systému a přijímat opatření k zajištění optimálního provozního prostředí Systému, případně identifikovat oblasti a definovat náměty na zlepšení.


Poskytovatel tak bude v rámci zajištění Služeb provozu včas vyhodnocovat stav informačního prostředí Systému a všechna zjištění bude identifikovat jako možná rizika (pozitivní i negativní). V rámci řízení rizik budou na úrovni jednotlivých projektových týmů přijímána opatření k zajištění optimálního chodu Systému. V případě, že přijetí opatření nebude možné zajistit v souladu s odpovědnostmi daného projektového týmu, případně bude identifikované navržené optimalizační řešení mimo rozsah Systému, bude toto daný projektový tým eskalovat prostřednictvím Vedoucího programu (za Poskytovatele) na úroveň HTPG.

Doba zajištění aktivity

Kontinuálně po dobu plnění Smlouvy, vždy na úrovni daného projektového týmu.

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

V rámci fungování jednotlivých projektových týmů jsou identifikována a přijímána opatření k zajištění optimálního chodu Systému, případně jsou předkládána na HTPG k dalšímu řešení.

Součástí pravidelných Projektových reportů je průběžné řízení rizik.

Jedná se o projektovou odpovědnost na straně Poskytovatele i Objednatele.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění služby IS02

Součástí Zprávy o plnění služby IS02 bude část obsahující navrhované, či realizované aktivity vedoucí k optimalizaci provozního prostředí Systému. Zpráva o plnění služby IS02 je součástí Zprávy o stavu provozu Systému.

Pro akceptaci Zprávy o stavu provozu Systému se uplatní postup stanovený v rámci aktivity A15 služby IS03.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena/komponenta

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) je stanovena jako součet paušálních jednotkových cen dané aktivity pro každou komponentu Systému. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, bude, po realizaci jednorázové služby, celková cena aktivity upravena (snížena) o jednotkovou cenu dané aktivity. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).



Označení

Název Aktivity

A12

Opravy chyb

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Aktivita „Opravy chyb“ se vztahuje na realizaci všech dílčích činností, které jsou nezbytné pro odstranění identifikované nebo hlášené 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í prostředí, atd. Opravy chyb se vztahují na všechny technologické části Systému. Aktivita se vztahuje i na prostředí třetích stran, pokud je chyba identifikována na úrovni aplikačního prostředí Systému. V takovém případě je identifikovaná chyba evidována pracovníky Poskytovatele v Service Desku jako incident.

V rámci dané aktivity poskytuje Poskytovatel odborné aplikační, systémové i konzultační služby, aby odstranil všechny identifikované chyby plnění.

Veškeré Opravy chyb musí být autorizovány příslušným odpovědným pracovníkem Objednatele, a to buď na úrovni projektového týmu, pokud se jedná o drobnou chybu, která byla v projektovém týmu identifikována (zde stačí odsouhlasení emailem, jestliže se nejedná o opravu vyžadující kompletní release), případně na úrovni Service Desku, pokud se jedná o chybu, která je většího významnějšího charakteru.

V případě, že je pracovníkem Poskytovatele identifikována chyba, je nezbytné opravdu chyby vždy odsouhlasit pracovníkem Objednatele, a to i v případě, že může pracovník poskytovatele chybu opravit sám. Pokud by byl realizován zásah v Systému, který bude následně odlogován jako neautorizovaný, jedná se o porušení integrity Systému. V případě identifikované chyby s možností opravy, kterou není možné z jakýchkoliv důvodů schválit na úrovni projektového týmu, zakládá pracovník Poskytovatele prostřednictvím Service Desku s tím, že do textu incidentu již navrhuje způsob řešení.

Evidenci chyb identifikovaných a opravených na úrovni Projektového týmu předkládá Vedoucí příslušného projektového (provozního) týmu souhrnně jako součást Zprávy o plnění služby IS02.

Doba zajištění aktivity


Dle potřeby v Provozní době, pokud se nejedná o opravu prostřednictvím releasu a oprava nemá dopad na provoz Systému.


V případě, že má realizace Opravy chyby dopad na provoz Systému, musí být vždy autorizována pracovníkem Service Desku Objednatele. V případě, že je oprava chyby autorizována pracovníkem Service Desku Objednatele i v Provozní době, přestože má oprava dopad na provoz Systému, jedná se o Plánovanou odstávku.

SLA parametry / Vyhodnocení

Definice

Požadovaná hodnota

Vyhodnocení

Autorizovaná oprava chyb

Veškeré identifikované chyby jsou opravovány řízeným postupem tak, aby nebyla narušena integrita Systému.

Na základě předkládaných reportů systémových zásahů pracovníků Poskytovatele bude ověřeno, zda se jednalo o autorizované zásahy do prostředí Systému. V případě, že nebude zásah autorizován, uplatní se kreditace definována v kapitole č. 4.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění služby IS02.


Reporty systémových zásahů v Systému.

V rámci Zprávy budou identifikované veškeré Opravy autorizované na úrovni daných projektových týmů.


Budou ověřovány reporty systémových zásahů v Systému.

Pro akceptaci uvedených dokumentů se uplatní obecná akceptační kritéria pro předávání dokumentace dle Smlouvy v rámci souhrnné Zprávy o stavu provozu Systému.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena/komponenta

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) je stanovena jako součet paušálních jednotkových cen dané aktivity pro každou komponentu Systému. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, bude, po realizaci jednorázové služby, celková cena aktivity upravena (snížena) o jednotkovou cenu dané aktivity. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).



3.3.3IS03 – Dohled a monitoring Systému

Označení

Název služby

IS03

Dohled a monitoring Systému

Vymezení služby

Lokalita

Oddělené lokality Provozovatele

Prostředí

PROD/TEST/DEV

Zkrácený popis služby

Zajištění služeb dohledu a monitoringu Systému

Seznam komponent

  • K01 – Portálový systém

  • K02 – Notifikační komponenta (Notifikátor)

  • K03 – Formulářový server klientů veřejné správy

  • K04 – Formulářový server úřední osoby

  • K05 – Portálová aplikace XXXX pro žadatele

  • K06 – Portálová aplikace XXXX pro SZIF

BUDE DÁLE DOPLNĚNO PŘED PODPISEM SMLOUVY NA ZÁKLADĚ VÍTĚZNÉ NABÍDKY V SOULADU S PŘÍLOHOU Č. 7 SMLOUVY

Seznam aktivit

Aktivita

Obecný rozsah aktivity

Periodicita činnosti

A13 - Bezpečnostní monitoring provozu Systému

Realizace bezpečnostního dohledu provozu a rozvoje Systému během provozní doby v režimu 7x24 pro naplnění veškerých zákonných požadavků na zajištění informační a kybernetické bezpečnosti aplikační vrstvy Významného informačního systému.

Vyhodnocovací období

A14 - Provozní monitoring provozu Systému

Realizace provozního dohledu provozu a rozvoje Systému během provozní doby v režimu 7x24 pro naplnění veškerých smluvních požadavků na zajištění informační a kybernetické bezpečnosti aplikační vrstvy Významného informačního systému.

A15 - Vyhodnocení SLA parametrů provozu

Pravidelné vyhodnocování provozu a příprava podkladů pro vyhodnocení SLA parametrů za stranu Poskytovatele a vyhodnocovací období

SLA parametry služby

Vyhodnocovací období

1 kalendářní měsíc



Označení

Název Aktivity

A13

Bezpečnostní monitoring provozu Systému

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel je povinen v rámci služby IS03 zajistit komplexní aktivity bezpečnostního monitoringu implementovaného Systému. Předmětem bezpečnostního monitoringu je tak sledování stavu Systému, průběžné vyhodnocování informací týkajících se bezpečnosti systému, a to všech jeho součástí a využitých služeb. Monitoring musí zahrnovat automatizovaný dohled i činností pracovníků Poskytovatele souvisejících zejména s vyhodnocováním nestandardních stavů, bezpečnostních událostí a incidentů a jejich hlášení nestandardních stavů na stranu Objednatele.

Aktivity bezpečnostního monitoringu budou primárně zaměřeny na následující oblasti:

  • Chování uživatelů Systému (zajištění logování aktivit s dopadem na bezpečnost dle požadavků ZoKB).

  • Bezpečnost osobních dat v Systému.

  • Obecná bezpečnost dat.

  • Provoz aplikační vrstvy s ohledem na kybernetickou a informační bezpečnost.

  • Další oblasti v souladu s požadavky na implementaci GDPR a závaznými legislativními požadavky zejména ZoKB a prováděcích předpisů a Zákona č. 365/2000 Sb.

Aktivity bezpečnostního monitoringu musí splňovat následující rozsah:

  • Monitoring a provádění kontroly stavů všech bezpečnostně relevantních mechanismů implementovaných v rámci prostředí.

  • Monitoring bezpečnosti Systému s ohledem na ICT prostředí, které ovlivňuje provoz Systému, typicky:

    • Cloudové služby využité Systémem, infrastruktura Poskytovatele či třetí strany,

    • Informační systémy Poskytovatele integrované na Systém:

      • IS XXXX.

      • IS SZIF na platformě SAP.

      • IDM SZIF.

      • Systémy pro správu přístupů.

      • LPIS a případně další integrované registry a systémy.

    • Aplikační služby nezbytné pro fungování komplexní systémové podpory agend XXXX:

      • Služby SAMAS.

      • Služby Geotagovaných fotografií.

V případě podezření na vznik bezpečnostní události/incidentu ve vnějším prostředí, kdy toto může mít dopad na chod Systému, zajištění notifikace Bezpečnostního manažera Objednatele nejpozději do 15 minut od zjištění nežádoucího stavu.

  • Kontrola bezpečnostních logů (na denní bázi).

  • Monitoring nových verzí bezpečnostních aktualizací/záplat/patchů pro zajištění bezpečnostních aktualizací Systému v rámci služby IS02.

  • Notifikace Service Desku Objednatele (alerting) při výskytu nežádoucích situací do 15 minut od vzniku/zjištění. Vyhodnocování těchto stavů a identifikaci příčin. Analýza řešených problémových situací a návrh opatření pro jejich eliminaci. Prozkoumání vhodnosti přijatých opatření.

  • Poskytovatel v případě zjištění bezpečnostní události/incidentu bezprostředně informuje Bezpečnostního manažera Objednatele a zajistí identifikaci dotčených modulů/funkčností včetně předání této informace na 1. úroveň Service Desk SZIF.

  • Poskytovatel v případě nalezení příčiny bezpečnostní události/incidentu a též řešení bezpečnostní události/incidentu, bezprostředně informuje Bezpečnostního manažera Objednatele a 1. úroveň Service Desk SZIF.

  • Poskytovatel zajistí dohled nad neoprávněnými pokusy o přihlášení do aplikačního prostředí Systému a předání této informace na Bezpečnostního manažera Objednatele i Service Desk SZIF. Za neoprávněný pokus se považuje opakovaný pokus o využití jiného než odsouhlaseného mechanismu přihlašování, případně identifikovaný pokus o prolomení standardního způsobu přihlašování.

  • Pro realizaci aktivit bezpečnostního monitoringu musí být v prostředí Systému implementovány odpovídající monitorovací a logovací nástroje dle schválené architektury Systému.

  • Součástí aktivit bude správa záznamů a logů zahrnující sběr, ukládání, zpracování a vyhodnocování bezpečnostních záznamů jednotlivých modulů Systému. Záznamy se musí archivovat v souladu s požadavky ZoKB pro Významný informační systém dle vyhlášky příslušného prováděcího předpisu ZoKB.

  • Bezpečnostní monitoring musí splňovat požadavky dle ISO 27001:2013.

Doba zajištění aktivity

Automatizovaný dohled a sběr dat - 7x24 – provozní doba znamená zajištění služeb v pracovní i nepracovní dny 24 hodin denně;

Interakce pracovníků Poskytovatele vůči pracovníkům Objednatele – v případě zjištění bezpečnostní události/incidentu neprodleně.

SLA parametry / Vyhodnocení




Předmětem vyhodnocení aktivity Bezpečnostního monitoringu bude samostatná zpráva přikládaná na měsíční bázi jako součást podkladů předkládaných v rámci vyhodnocovacího období. Zpráva bude předkládaná bezpečnostnímu manažeru SZIF a bude obsahovat minimálně:

  • Měsíční přehled o zaznamenaných incidentech a nežádoucích situacích

  • Měsíční přehled pokusů o narušení bezpečnosti Systému

  • Záznamy o privilegovaných přihlášeních do jednotlivých modulů Systému

  • Záznamy o používání vzdáleného přístupu do Systému mimo privilegovaná přihlášení

  • Identifikovaná bezpečnostní rizika

  • Opatření realizovaná v průběhu vyhodnocovacího období a navrhovaná pro období následující

  • Veškeré další podklady dokládající realizaci Bezpečnostního monitoringu Systému Provozovatelem v souladu s Best Practice a požadavky ZoKB, případně ISO 27001.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva měsíčního vyhodnocení bezpečnostního monitoringu Systému.

Bude se jednat o dokument, který bude klasifikován jako diskrétní. Dokument nebude kromě Garanta projektového týmu (Provozní tým) a Bezpečnostního manažera SZIF zpřístupněn dalším pracovníkům Objednatele. Tento dokument nebude standardní součástí Zprávy o stavu provozu Systému. Ve Zprávě o stavu provozu Systému bude uveden odkaz s termíny předání Zprávy měsíčního vyhodnocení bezpečnostního monitoringu Systému.

Pro akceptaci Zprávy měsíčního vyhodnocení bezpečnostního monitoringu Systému se uplatní obecná akceptační kritéria pro předávání dokumentace dle Smlouvy.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) je stanovena jako paušální cena dané aktivity pro celý Systém, kdy tato cena je neměnná. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, zůstává paušální cena aktivity konstantní. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).



Označení

Název Aktivity

A14

Provozní monitoring provozu Systému

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel je povinen v rámci služby IS03 zajistit komplexní aktivity provozního monitoringu implementovaného Systému. Předmětem provozního monitoringu je tak sledování stavu Systému, průběžné vyhodnocování informací týkajících se provozu Systému, a to všech jeho aplikačních součástí a využitých infrastrukturních a jiných služeb.

Monitoring musí zahrnovat automatizovaný dohled i činnosti pracovníků Poskytovatele související zejména s vyhodnocováním nestandardních stavů, provozních událostí a incidentů a hlášení nestandardních stavů na stranu Objednatele.

Aktivity provozního monitoringu budou primárně zaměřeny na následující oblasti:

  • Chování uživatelů Systému (zajištění logování chování uživatelů dle požadavků ZoKB).

  • Provozní stabilita jednotlivých modulů/systémů v Systému.

  • Provozní monitoring Systému – výkon, dostupnost, stabilita, provozní události/incidenty.

  • Provozní monitoring rozhraní Systému – výkon, dostupnost, stabilita, provozní události/incidenty.

  • Monitoring konzistence dat v Systému.

  • Administrace systému a implementace změn v Systému.

  • Další nezbytné činnosti, garantující stabilní a funkční prostředí Systému odpovídající provozním Best Practice standardům (ITIL, ISO/IEC 20000).

Aktivity provozního monitoringu musí splňovat následující rozsah:

  • Monitoring a provádění kontroly stavů všech provozně relevantních mechanismů implementovaných v rámci prostředí.

  • Monitoring chování Systému s ohledem na okolní ICT prostředí, které ovlivňuje provoz Systému, typicky:

    • CloudInfrastruktura Poskytovatele, třetí strany či cloudová infrastruktura hostující Systém

    • Informační systémy Poskytovatele integrované na Systém:

      • IS XXXX.

      • IS SZIF na platformě SAP.

      • IDM SZIF.

      • Systémy pro správu přístupů.

      • LPIS a případně další integrované registry a systémy.

    • Aplikační služby nezbytné pro fungování komplexní systémové podpory agend XXXX:

      • Služby SAMAS.

      • Služby Geotagovaných fotografií.

V případě identifikace provozní události/incidentu ve vnějším prostředí, kdy toto může mít dopad na chod Systému, zajištění notifikace Service Desku Objednatele nejpozději do 15 minut od zjištění nežádoucího stavu.

  • Kontrola provozních logů (na denní bázi).

  • Monitoring nových verzí systému, provozních aktualizací/záplat/patchů pro zajištění provozních aktualizací Systému v rámci služby IS02.

  • Notifikace Service Desku Objednatele (alerting) při výskytu nežádoucích situací do 15 minut od vzniku/zjištění. Vyhodnocování těchto stavů a identifikaci příčin. Analýza řešených problémových situací a návrh opatření pro jejich eliminaci. Prozkoumání vhodnosti přijatých opatření.

  • Poskytovatel v případě zjištění provozní události/incidentu bezprostředně informuje 1. úroveň Service Desk SZIF.

  • Poskytovatel v případě nalezení příčiny provozní události/incidentu a též řešení provozní události/incidentu, bezprostředně informuje 1. úroveň Service Desk SZIF.

  • Součástí aktivit bude správa záznamů a logů zahrnující sběr, ukládání, zpracování a vyhodnocování bezpečnostních záznamů jednotlivých modulů Systému. Záznamy se musí archivovat v souladu s požadavky ZoKB pro Významný informační systém dle vyhlášky příslušného prováděcího předpisu ZoKB.

  • Provozní monitoring Systému musí být nastaven a prováděn v souladu s ISO/IEC 27001 v aktuální platné verzi.

Doba zajištění aktivity

Automatizovaný dohled a sběr dat - 7x24 – provozní doba znamená zajištění služeb v pracovní i nepracovní dny 24 hodin denně;

Interakce pracovníků Poskytovatele vůči pracovníkům Objednatele - 5x12 – garantovaná provozní doba znamená zajištění služeb pracovní dny 12 hodin denně (7:00 – 19:00).

SLA parametry / Vyhodnocení




Předmětem vyhodnocení aktivity Provozního monitoringu bude samostatná Zpráva měsíčního vyhodnocení provozního monitoringu Systému. Zpráva bude obsahovat minimálně:

  • Měsíční přehled o zaznamenaných incidentech a nežádoucích situacích

  • Měsíční přehled realizovaných administrátorských operací na úrovni pracovníků Poskytovatele

  • Měsíční přehled provozních činností realizovaných ze strany Poskytovatele

  • Identifikovaná provozní rizika

  • Opatření realizovaná v průběhu vyhodnocovacího období a navrhovaná pro období následující

Veškeré další podklady dokládající realizaci Provozního monitoringu Systému Provozovatelem v souladu s Best Practice a požadavky odpovídající legislativy vztahující se na provoz Významných informačních systémů veřejné správy.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva měsíčního vyhodnocení provozního monitoringu Systému.

Zpráva měsíčního vyhodnocení provozního monitoringu Systému bude součástí souhrnné Zprávy o stavu provozu Systému.

Pro akceptaci Zprávy o stavu provozu Systému se uplatní postup stanovený v rámci aktivity A15 služby IS03.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) je stanovena jako paušální cena dané aktivity pro celý Systém, kdy tato cena je neměnná. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, zůstává paušální cena aktivity konstantní. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).





Označení

Název Aktivity

A15

Vyhodnocení SLA parametrů provozu

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel je povinen v rámci služby IS03 zajistit kompletní vyhodnocení veškerých provozních aktivit, stavu Systému i činností realizovaných jednotlivými pracovníky Poskytovatele v rámci služeb IS01 – IS04. Vyhodnocení bude spočívat v prověření a doložení podkladů parametrů provozu Systému v podobě souhrnné Zprávy o stavu provozu Systému, kdy jednotlivé dílčí oblasti a zprávy realizované v rámci Služeb IS01-04 budou součástí této souhrnné Zprávy o stavu provozu Systému (vyjma Zprávy měsíčního vyhodnocení bezpečnostního monitoringu Systému). Souhrnná Zpráva o stavu provozu Systému tak bude zahrnovat následující části:

  • Zpráva o plnění služby IS01,

  • Zpráva o plnění služby IS02,

  • Odkaz a termíny předání Zprávy měsíčního vyhodnocení bezpečnostního monitoringu Systému,

  • Zpráva měsíčního vyhodnocení provozního monitoringu Systému,

  • Zpráva o plnění služby IS04,

  • Výkaz činností - za vyhodnocovací období pro služby IS01 – IS04.


Obsahy dílčích zpráv jsou definovány v rámci jednotlivých aktivit a služeb. Tyto zprávy popisují zejména věcnou oblast poskytovaných služeb v takovém detailu, který dostatečně dokládá samotný průběh realizace služeb a naplnění podmínek jednotlivých aktivit. Zároveň zprávy obsahují jednoznačné potvrzení stanovených parametrů služeb a dokládají splnění či porušení jednotlivých SLA s případným vyčíslením kreditace za jednotlivé služby.

Předmětem Výkazu činností za vyhodnocovací období je pak soupis veškerých činností realizovaných konkrétními pracovníky Poskytovatele v rámci poskytování služeb IS01 – IS04. V rámci Výkazu činností bude jednoznačně doloženo, který pracovník zajišťoval a realizoval konkrétní činnost v rámci aktivit v příslušném dni.

Doba zajištění aktivity

1krát měsíčně na počátku každého vyhodnocovacího období (kalendářní měsíc) za uplynulé vyhodnocovací období.

SLA parametry / Vyhodnocení




Celková Zpráva o stavu provozu Systému bude zpracována a předána nejpozději během 5. (pátého) pracovního dne vyhodnocovacího období následujícího po ukončení předchozího vyhodnocovacího období.

Zpráva bude předána v elektronické podobě umožňující počítačové zpracování. Dílčí zprávy budou primárně ve formátu .pdf v generované (případně skenované, se zachováním strojové čitelnosti) podobě. Ty části zpráv, které budou obsahovat taková data, jejichž zobrazení ve standardním dokumentu (.pdf) znamená zhoršenou orientaci v datech, budou předány ve formátu .xlsx.

Dokumenty budou standardně chráněny proti změně dat; čtení, systémové kopírování a elektronický podpis akceptační doložky ze strany kontaktní osoby Objednatele budou umožněny. Tam, kde je to možné (primárně formát .pdf), budou dokumenty v části akceptační doložky podepsané elektronickým podpisem kontaktní osoby Poskytovatele.

Kontaktní osoby budou stanoveny a případně aktualizovány na úrovni Řídícího výboru, zejména s ohledem na možné personální změny jak na straně Objednatele, tak na straně Poskytovatele.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o stavu provozu Systému

Předaná a akceptovaná úplná Zpráva o stavu provozu Systému.

Pro akceptaci ze strany kontaktní osoby Objednatele je stanovena lhůta 5 pracovních dní od předání Zprávy o stavu provozu Systému ze strany Poskytovatele. V případě, že nebude ze strany kontaktní osoby Objednatele vznesena výhrada

nejpozději 5. (pátého) pracovního dne od předání Zprávy o stavu provozu Systému, má se za to, že je Zpráva akceptována. V případě, že budou ze strany kontaktní osoby Objednatele vzneseny výhrady, je Poskytovatel povinen Zprávu o stavu provozu Systému aktualizovat a předat nejpozději během 3. (třetího) pracovního dne od obdržení výhrad. Následná lhůta pro akceptaci upravené Zprávy o stavu provozu Systému je stanovena na 3 pracovní dny.

Poskytovatel je oprávněn fakturovat plnění Služeb IS01-04 na základě akceptované Zprávy o stavu provozu Systému.


Způsob stanovení celkové ceny aktivity

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) je stanovena jako paušální cena dané aktivity pro celý Systém, kdy tato cena je neměnná. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, zůstává paušální cena aktivity konstantní. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).



3.3.4IS04 – Uživatelská podpora Systému

Označení

Název služby

IS04

Uživatelská podpora Systému

Vymezení služby

Lokalita

Oddělené lokality Poskytovatele

Prostředí

PROD/TEST/DEV

Zkrácený popis služby

Zajištění služeb podpory pro koncové uživatele Systému

Seznam komponent

  • K01 – Portálový systém

  • K02 – Notifikační komponenta (Notifikátor)

  • K03 – Formulářový server klientů veřejné správy

  • K04 – Formulářový server úřední osoby

  • K05 – Portálová aplikace XXXX pro žadatele

  • K06 – Portálová aplikace XXXX pro SZIF

BUDE DÁLE DOPLNĚNO PŘED PODPISEM SMLOUVY NA ZÁKLADĚ VÍTĚZNÉ NABÍDKY V SOULADU S PŘÍLOHOU Č. 7 SMLOUVY

Seznam aktivit

Aktivita

Obecný rozsah aktivity

Periodicita činnosti

A16 - Zajištění 2. a 3. úrovně podpory Service Desku

Zajištění uživatelské a další podpory prostřednictvím Service Desku Objednatele, administrace jednotlivých typů hlášení realizovaných Service Deskem v definovaných lhůtách.

Vyhodnocovací období

A17 - Školení uživatelů

Zajištění školení uživatelů na základě požadavku Objednatele. Jedná se o mimořádné školení realizované mimo Služby rozvoje.

SLA parametry služby

Vyhodnocovací období

1 kalendářní měsíc



Označení

Název Aktivity

A16

Zajištění 2. a 3. úrovně podpory Service Desku

Rozsah aktivity

Popis (obsah) aktivity

Kontinuální provozní aktivita


Poskytovatel bude, ve vztahu k Systému, zajišťovat kompletní službu podpory pro zajištění poskytování služeb IS01-IS05, JS01 a JS02. Tato podpora bude poskytována v rozsahu odpovědností definovaných následujícím schématem primárně prostřednictvím Service Desku, jakožto standardizovaného nástroje pro poskytování podpory v prostředí SZIF. Komplexní zajištění podpory Systému bude zajišťováno součinností různých subjektů.


Poskytovatel zajistí formou služby výkon činnosti 2. úrovně podpory pro oblast prostředí Systému v rozsahu dodávaných a provozovaných SW technologií od vrstvy operačního systému výše. Dále Poskytovatel zajistí poskytování 3. úrovně podpory dodavatelů a výrobců SW, které jsou součástí Dodávky a implementace Systému, kdy bude rovněž koordinovat případné poskytování 3. úrovně podpory jednotlivých výrobců tak, aby bylo zajištěno korektní poskytování služeb IS01-03 i služby rozvoje Systému. Součástí poskytování služeb podpory není podpora výrobců HW a SW, které nejsou součástí Dodávky a implementace Systému.


Shape1

1. úroveň podpory zajišťuje Objednatel. V rámci 1. úrovně podpory je zajišťována komunikace s koncovými uživateli. Na této úrovni dochází ke klasifikaci jednotlivých hlášení, kategorizaci a předávání na řešitelské týmy 2. úrovně podpory.

Z hlediska 1. úrovně podpory jsou rozlišovány primárně 3 typy hlášení:

  • Incident (na tento typ hlášení se vztahují SLA na administraci hlášení – reakční doba)

  • Problém (na tento typ hlášení se vztahují SLA na administraci hlášení – reakční doba)

  • Požadavek (na tento typ hlášení se nevztahují SLA na administraci hlášení, v případě nerealizace požadavku se uplatní sankční mechanismy dle příslušné aktivity)

Každé hlášení (incidentu/problému) je zadáváno prostřednictvím ticketu.

V případě, že je ticket postoupen Poskytovateli, stává se Poskytovatel řešitelem konkrétního ticketu a musí na tento ticket reagovat, resp. zahájit jeho řešení dle stanovených lhůt.

Z hlediska významnosti ticketů jsou stanoveny tři kategorie.

  • Vysoká významnost – funkčnost není možné produktivně používat, neexistuje náhradní řešení, tento stav ohrožuje realizaci procesů SZIF.

  • Střední významnost – funkčnost není možné produktivně používat v plném rozsahu, resp. existuje náhradní řešení, které umožní realizaci procesů SZIF mimo Systém.

  • Nízká významnost – funkčnost je možně produktivně používat s dílčím omezením, které nemá vliv na realizaci procesů SZIF.



V rámci 2. úrovně podpory zajistí Poskytovatel zejména následující činnosti:

  • Provádění servisních služeb:

    • Řešení nestandardních stavů/incidentů a požadavků v denním provozu předaných z 1. úrovně podpory. Odstraňování incidentů na úrovni provozu Systému (chyby funkčností, nedostupnosti funkčností, modulů, incidenty na úrovni chyb v datech).

    • Komunikace s 1. úrovní podpory prostřednictvím Service Desku SZIF. (Jedná se o formální komunikaci, která je předmětem standardní archivace v Service Desk nástroji Objednatele).

    • Komunikace s 3. úrovní podpory prostřednictvím interních postupů Poskytovatele.

  • Zadávání požadavků na 1. úroveň podpory – jedná se zejména o požadavky na poskytnutí součinnosti, realizaci služby a další odborné činnosti ze strany pracovníků Objednatele i ostatních dodavatelů Objednatele, kteří zajišťují provoz dalších částí informačního prostředí SZIF (typicky například provozovatel infrastruktury), kdy realizace těchto požadavků je nezbytná pro zajištění služeb poskytovaných Poskytovatelem v odpovídajícím rozsahu (např. pro realizaci kopie dat).

  • Provádění dalších odborných činností 2. úrovně podpory v rámci eskalačních postupů a procesů podpory SZIF (podpora a analýzy stavu Systému při řešení bezpečnostních incidentů, incidentů a poruchových stavů na aplikační úrovni) a poskytnutí odborné podpory Objednateli při komunikaci s dalšími externími subjekty (dodavateli).


Služba 2. úrovně podpory musí být schopna:

  • na základě výstupů aktivit provozního a bezpečnostního monitoringu musí být na 2. úrovni podpory umožněna:

    • verifikace funkčnosti nebo dostupnosti služeb z pohledu Objednatele.

    • detekce degradace funkčnosti než se projeví u koncových uživatelů Objednatele (pokud je toto možné).

    • prvotní analýza pro rychlé a jednoznačné určení a předání odpovědnému týmu/pracovníkovi zodpovědnému za řešení provozní/bezpečnostní situace.



V rámci služeb 3. úrovně podpory zajistí Poskytovatel zejména následující činnosti:

  • Vyvolání/zajištění maintenance jednotlivých výrobců jednotlivých komponent Systému (samotný výkon maintenance je součástí Aktivity A10) v rozsahu smluvně zajištěné maintenance.

  • Interní řešení ticketů v prostředí Poskytovatele a komunikace s 2. úrovní podpory.


Pro výkon činností v rámci služeb 2. úrovně podpory bude Poskytovatel využívat prostředí Service Desku SZIF; podpora procesů řízení ICT služeb v souladu s mezinárodním standardem ITIL,

  • Incident a Request Management – zpracování incidentů, požadavků, dotazů na provoz Systému.

  • Release Management – prostřednictvím Service Desku SZIF bude zajištěna evidence všech požadovaných releasů nových/změněných funkčností Systému realizovaných prostřednictvím služeb rozvoje.

  • Problem Management – identifikace, kategorizace, diagnostika a řešení problémů v Systému.

  • Nastavení workflow a eskalačních procedur.

Doba zajištění aktivity

  • 7x24 – provozní doba znamená zajištění služeb v pracovní i nepracovní dny 24 hodin denně

SLA parametry

Parametr

Požadovaná hodnota

Vyhodnocení

Následující parametry stanovují požadavky na zajištění úrovně služeb Service Desku ze strany Poskytovatele. Komunikace a realizace procesů mezi 2. a 3. úrovní na straně Poskytovatele není předmětem vyhodnocení. Poskytovatel musí tyto procesy nastavit interně tak, aby splnil níže uvedené požadavky. Veškeré níže uvedené lhůty jsou vztaženy k Době zajištění aktivity, tedy rovněž lhůty jsou kalkulovány podle této Doby. Čas mimo tuto Dobu se nezapočítává do vyhodnocení

Doba reakce na přidělení ticketu

(Lhůta, do jejíhož uplynutí musí 2. úroveň Service Desku potvrdit přijetí ticketu a zahájení řešení prostřednictvím Service Desk nástroje)

30 minut

Porovnání systémového času mezi nahlášením (doba odeslání) ticketu z 1. úrovně a potvrzením zahájení řešení ze strany Poskytovatele.

Maximální doba řešení ticketu

Vysoké významnosti


Lhůta, do jejíhož uplynutí musí být ticket vyřešen, nebo nalezeno náhradní řešení, které umožní snížit významnost na Střední, či Nízkou – při snížení významnosti se doba řešení vysoké významnosti započítává do doby řešení nižší významnosti, tedy Doba měření lhůty není znovu zahájena, ale pokračuje.


(V případě, že bude požadována součinnost jiného dodavatele nebo Objednatele, lhůta je pozastavena do doby poskytnutí součinnosti. Pokud je požadavek na součinnost požadován neoprávněně, lhůta stále běží, toto platí i pro následující významnosti.)

120 minut (2 hodiny)

Porovnání systémového času mezi nahlášením (doba odeslání) ticketu z 1. úrovně a potvrzením zahájení řešení ze strany Poskytovatele.

V případě nezajištění řešení do požadované doby řešení je ticket klasifikován jako Vada Systému Kategorie „A“ a dojde k uplatnění kreditace v souladu s definicí Služby IS01.

Maximální doba řešení ticketu

Střední významnosti


Lhůta, do jejíhož uplynutí musí být ticket vyřešen nebo nalezeno náhradní řešení, které umožní snížit významnost na Nízkou – při snížení významnosti se doba řešení vysoké významnosti započítává do doby řešení nižší významnosti, tedy Doba měření lhůty není znovu zahájena, ale pokračuje.

8 hodin

Porovnání systémového času mezi nahlášením (doba odeslání) ticketu z 1. úrovně a potvrzením zahájení řešení ze strany Poskytovatele.

V případě nezajištění řešení do požadované doby řešení je ticket klasifikován jako Vada Systému Kategorie „B“ a dojde k uplatnění kreditace v souladu s definicí Služby IS01.

Maximální doba řešení ticketu

Nízké významnosti


Lhůta, do jejíhož uplynutí musí být ticket vyřešen.

40 hodin

Porovnání systémového času mezi nahlášením (doba odeslání) ticketu z 1. úrovně a potvrzením zahájení řešení ze strany Poskytovatele.

V případě nezajištění řešení do požadované doby řešení je ticket klasifikován jako Vada Systému Kategorie „C“ a dojde k uplatnění kreditace v souladu s definicí Služby IS01.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Zpráva o plnění služby IS04

Součástí Zprávy o plnění služby IS04 bude strukturovaný přehled všech ticketů, jejichž Maximální doba řešení časově spadá do vyhodnocovacího období s uvedením ID ticketu, doby předání, doby reakce, požadované Maximální doby řešení a reálné doby řešení. Zpráva o plnění služby IS04 je součástí Zprávy o stavu provozu Systému.

Pro akceptaci Zprávy o stavu provozu Systému se uplatní postup stanovený v rámci aktivity A15 služby IS03.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) je stanovena jako paušální cena dané aktivity pro celý Systém, kdy tato cena je neměnná. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, zůstává paušální cena aktivity konstantní. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).



Označení

Název Aktivity

A17

Školení uživatelů

Rozsah aktivity

Popis (obsah) aktivity

Vzhledem k předpokládanému průběžnému vývoji Systému požaduje Objednatel zajištění kapacit Poskytovatele na přípravu a realizaci aktivity spojených se školením uživatelů Systému. Bude se jednat o jednorázové aktivity v průběhu kalendářního roku, které nebudou primárně řešené v rámci poskytování Služeb rozvoje, tedy nebudou výhradně součástí příprav nových funkčností nebo změn Systému.

Předmětem aktivit mohou být následující činnosti:

  • Realizace školení v učebně (prostory Objednatele)

  • Realizace školení prostřednictvím videokonference

  • Příprava interaktivních školicích materiálů (např. webinář, video)

  • Příprava školicích dokumentů (prezentace, uživatelská příručka)

Obsahem školicích aktivit bude především vlastní obsluha Systému, v případě dohody a potvrzení mezi Objednatelem a Poskytovatelem mohou být obsahem i jiné části Systému Objednatele, pokud k tomu má Poskytovatel disponibilní zdroje.

Rozsah prací souvisejících s aktivitami školení stanovuje Objednatel na 12 MD v průběhu kalendářního roku. Tyto aktivity nebudou realizovány pravidelně, ale na vyžádání Objednatelem.

Požadavek na realizaci školicí aktivity zadává vždy Garant (rozvojového) projektového týmu Objednatele prostřednictvím Service Desku, a to vždy minimálně 14 kalendářních dní před termínem požadované aktivity.

Doba zajištění aktivity

Dle požadavku Objednatele v Pracovní době Objednatele.

SLA parametry / Vyhodnocení

Parametr

Požadovaná hodnota

Vyhodnocení

Požadavek na realizaci školící aktivity

Realizovaná aktivita v požadovaném rozsahu a termínu.

Školící aktivita bude u konkrétních pracovníků Poskytovatele evidována ve Výkazu činností.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Výkazy činností ve Zprávě o stavu provozu Systému

V rámci Výkazů činností zpracovávaných jako součást Zprávy o stavu provozu Systému za odpovídající Vyhodnocovací období budou uvedeny veškeré činnosti pracovníků Poskytovatele vykonávajících tyto aktivity.

Pro akceptaci Zprávy o stavu provozu Systému se uplatní postup stanovený v rámci aktivity A15 služby IS03.

Způsob stanovení celkové ceny aktivity

Celková cena aktivity/rok = paušální cena za MD*12

Celková Cena aktivity (stanovená pro kalendářní rok) je stanovena jako násobek paušálních jednotkových cen za MD a maximálního počtu poptávaných MD součinnosti v kalendářním roce. Paušální jednotková cena za MD je stanovena jako neměnná. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené ke konkrétní komponentě, zůstane, po realizaci jednorázové služby, paušální jednotková cena konstantní. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována.


Fakturace bude vždy realizována k období, ve kterém byla aktivita čerpána.

3.3.5IS07 – Poskytování cloudových služeb

Označení

Název služby

IS07

Poskytování cloudových služeb

Vymezení služby

Lokalita

Oddělené lokality Provozovatele

Prostředí

PROD/TEST/DEV

Zkrácený popis služby

Poskytování cloudových služeb využitých pro provoz a rozvoj Systému

Seznam cloudových služeb

BUDE DÁLE DOPLNĚNO PŘED PODPISEM SMLOUVY NA ZÁKLADĚ VÍTĚZNÉ NABÍDKY V SOULADU S PŘÍLOHOU Č. 7 SMLOUVY

Seznam aktivit

Aktivita

Obecný rozsah aktivity

Periodicita činnosti

A18 – Poskytování cloudových služeb pro provoz a rozvoj Systému

Zajištění poskytování cloudových služeb využitých pro provoz a rozvoj Systému během provozní doby v režimu 7x24, kdy bude garantována kompletní funkčnost Systému.

Vyhodnocovací období

A19 – Správa cloudových služeb pro provoz a rozvoj Systému a reporting čerpání cloudových služeb

Všechny činnosti související s poskytováním cloudových služeb, které nejsou součástí aktivity Report čerpání všech cloudových služeb využitých pro provoz a rozvoj Systému dostupný anebo předaný na závěr vyhodnocovacího období anebo na žádost Objednatele.

Vyhodnocovací období

SLA parametry služby

Vyhodnocovací období

1 kalendářní měsíc



Označení

Název Aktivity

A18

Poskytování cloudových služeb využitých pro provoz a rozvoj Systému

Rozsah aktivity

Popis (obsah) aktivity

Předmětem služby je poskytování cloudových služeb využitých pro provoz a rozvoj Systému. Cloudové služby využité pro provoz a rozvoj Systému musí být poskytovány v kvalitě a s parametry odpovídajícími výkonovým požadavkům na provoz Systému a smluvním parametrům služby IS01. Služby musí být zároveň škálovatelné tak, aby umožnily dočasné navýšení kapacit a výkonových parametrů cloudových služeb tak, aby Systém byl schopen i v případě špiček intenzity užití představujících současnou práci všech jmenných uživatelů na úvodní hodnotě 30.000 jmenných uživatelů a v budoucnu až 100.000-200.000 jmenných uživatelů, poskytovat služby při naplnění požadovaných parametrů dostupnosti a odezvy služby IS01. Zároveň budou cloudové služby škálovány ve směru ke snížení využitých zdrojů v případě nižší zátěže Systému a menší intenzity využití Systému uživateli anebo integrovanými systémy.


Cloudové služby poskytované před zahájením Pilotního a akceptačního provozu jsou součástí Implementace Systému. Cloudové služby poskytované po dobu Pilotního a akceptačního provozu se považují za součást Díla, ale řídí se pravidly dle této Přílohy č. 3 Smlouvy, a to včetně pravidel kreditace při porušení povinností při jejich poskytování. Cloudové služby poskytované po ukončení Pilotního a akceptačního provozu jsou součástí Služeb provozu.

Doba zajištění aktivity

7x24 – provozní doba znamená zajištění služeb v pracovní i nepracovní dny 24 hodin denně tak, aby byly poskytovány služby celého Systému v souladu se smluvními parametry.

SLA parametry / Vyhodnocení




Služba IS07 Poskytování cloudových služeb musí být poskytována s parametry umožňujícími naplnění smluvních parametrů služeb provozu a rozvoje Systému, zejména služeb IS01, IS03, IS05 a IS07. Pro službu IS07 nejsou definovány samostatné SLA parametry. Kvalita služeb je monitorována a vyhodnocována prostřednictvím služeb provozu a rozvoje Systému IS01, IS03, IS05 a IS07.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Poskytované cloudové služby

Poskytované cloudové služby umožňující bezproblémový provoz a rozvoj Systému. Služby zahrnují jak samotné služby konzumované Systémem, tak všechny podpůrné služby konzumované v průběhu provozu a rozvoje Systému (např. služby DEV-OPS či repositáře zdrojových kódů).

Služby nejsou samostatně akceptovány. Kvalita služeb je akceptována jako součást služeb provozu a rozvoje Systému IS01, IS03, IS05 a IS07.

Způsob stanovení celkové ceny aktivity

Měsíční variabilní cena

Cena cloudových služeb potřebných po dobu Implementace (tj. před zahájením Pilotního a akceptačního provozu) je zahrnuta do ceny Díla. Cena cloudových služeb od zahájení Pilotního a akceptačního provozu bude účtována dle skutečného čerpání v souladu s pravidly této Přílohy č. 3 a s pravidly dle Přílohy č. 7 Smlouvy. Cena cloudových služeb je závislá na jejich skutečném čerpání. Cena služby je kalkulována dle skutečného čerpání cloudových služeb za vyhodnocovací období. Cena je dovozena na základě postupů a cen uvedených v tabulce Ceny cloudových služeb v Příloze č. 7 Smlouvy. Skutečné čerpání xxxxxxxxxx služeb bude doloženo Reportem čerpání cloudových služeb poskytovaným v rámci aktivity A19.

Objednateli nesmí být nad rámec stanoveného způsobu kalkulace ceny cloudových služeb účtovány další variabilní náklady za konzumaci cloudových služeb překračující nabídkovou cenu. Zejména se toto týká využití síťových linek, virtuálních sítí, síťových a bezpečnostních prvků, datových úložišť atd.

V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dílčí cloudové službě, nebude nadále variabilní měsíční cena zahrnovat položku dílčí ukončené cloudové služby. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována, tedy nebude účtována celá variabilní měsíční cena za poskytované cloudové služby.


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).



Označení

Název Aktivity

A19

Správa cloudových služeb pro provoz a rozvoj Systému a reporting čerpání cloudových služeb

Rozsah aktivity

Popis (obsah) aktivity

Předmětem aktivy jsou všechny další činnosti související s využíváním cloudových služeb pro provoz a rozvoj Systému, které nejsou součástí aktivity A18 a dále reporting čerpání cloudových služeb.

Doba zajištění aktivity

7x24 – provozní doba znamená zajištění služeb v pracovní i nepracovní dny 24 hodin denně tak, aby byly poskytovány služby celého Systému v souladu se smluvními parametry.

SLA parametry / Vyhodnocení




Služba IS07 Poskytování cloudových služeb musí být poskytována s parametry umožňujícími naplnění smluvních parametrů služeb provozu a rozvoje Systému, zejména služeb IS01, IS03, IS05 a IS07. Pro službu IS07 nejsou definovány samostatné SLA parametry. Kvalita služeb je monitorována a vyhodnocována prostřednictvím služeb provozu a rozvoje Systému IS01, IS03, IS05 a IS07.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Report čerpání cloudových služeb využitých pro provoz a rozvoj Systému.

Report bude poskytován anebo jinak publikován Poskytovatelem Objednateli za každé vyhodnocovací období anebo jednorázově v podobě přehledu aktuálního čerpání cloudových služeb v průběhu vyhodnocovacího období. Průběžný report, pokud není pro Objednatele poskytován samoobslužně, bude poskytnut na vyžádání Objednatele.

Report čerpání cloudových služeb za vyhodnocovací období bude obsahovat uvedení jednotky služby, jednotkové ceny služby, počtu odebraných jednotek, celkové ceny za službu a celkové ceny všech využitých Cloudových služeb za vyhodnocovací období anebo popis jiného postupu využitého pro stanovení ceny služby, pokud není možné anebo vhodné využít kalkulaci založenou na jednotkové ceně. Report bude sestaven a strukturován v souladu s Přílohou č. 7 Smlouvy.

Pro akceptaci Reportu čerpání cloudových služeb pro provoz Systému bude využit postup stanovený v rámci aktivity A15 služby IS03, nebude-li dohodnuto jinak.

Způsob stanovení celkové ceny aktivity

Měsíční paušální cena

Celková cena aktivity za vyhodnocovací období (kalendářní měsíc) je stanovena jako paušální cena dané aktivity pro celý Systém, kdy tato cena je neměnná. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dílčí cloudové službě, zůstává paušální cena aktivity konstantní. V případě realizace jednorázové služby „Ukončení poskytování dílčí služby“ vztažené k dané aktivitě, nebude, po realizaci jednorázové služby, nadále tato aktivita vykazována a fakturována. (Po dobu Pilotního a akceptačního provozu je cena aktivity zahrnuta v měsíční paušální ceně Pilotního a akceptačního provozu.)


Fakturace je realizována za každé vyhodnocovací období (kalendářní měsíc).



3.4Služby rozvoje

3.4.1Obecné principy rozvoje

Následující definované principy stanovují zásady poskytování Služeb rozvoje, které musí být respektovány při realizaci rozvoje jak prostřednictvím požadavku na změnu, tak prostřednictvím projektu. Na rozdíl od detailních metodik a procesů realizace, které mohou být v rámci poskytování služeb IS05 a IS06 průběžně upravovány (pokud toto nemá dopad na smluvní ujednání včetně ceny), jsou tyto principy neměnné po celou dobu trvání Smlouvy.

3.4.1.1Průběžné řízení rozvoje

Řízení rozvoje je realizováno na úrovni jednotlivých projektových týmů. Každý projektový tým udržuje harmonogramy prací realizovaných v rámci daného projektového týmu. Za údržbu harmonogramů jsou odpovědní Vedoucí projektového týmu (Objednatele i Poskytovatele). Součástí harmonogramu je komplexní harmonogram činností jednotlivých členů týmu s identifikací oblastí, na kterých členové týmu pracují (požadavky na změnu i realizované projekty). V harmonogramu je rovněž kompletní evidence jednotlivých probíhajících PZ i projektů a jejich detailní harmonogram. Vedoucí projektových týmů jsou povinni průběžně s tímto harmonogramem pracovat a v případě zjištěné nekonzistence nebo identifikace jakéhokoliv rizika jsou povinni toto řešit v souladu se standardními projektovými postupy.

3.4.1.2Oprávněnost požadavku na rozvoj

Vzhledem ke složitosti informačního prostředí Objednatele i struktur činností Objednatele, kdy se některé oblasti administrace mohou překrývat napříč jednotlivými organizačními jednotkami Objednatele, se mohou průběžně objevovat požadavky na úpravu Systému. Poskytovatel není povinen vyhodnocovat požadavky na rozvoj, které mu budou předloženy nad rámec oblastí definovaných na ŘVPG, pokud toto není autorizováno odpovědnými řídícími strukturami Programu. Zároveň v případě, že by realizace požadavku s jistotou znamenala překročení předpokládaného rozpočtu na realizaci změn Systému pro daný kalendářní rok, není Poskytovatel oprávněn realizaci změny zahájit, pokud toto nebude odsouhlaseno na úrovni zástupců Řídícího výboru.

3.4.1.3Analýza a posouzení požadavku na rozvoj

Poskytovatel u každého požadavku rozvoje konzultuje s Objednatelem, zda má být daný požadavek realizován prostřednictvím požadavku na změnu (PZ), nebo prostřednictvím projektu. Pro zvolení odpovídající formy realizace jsou principy stanoveny v kapitole 2.1.1. tohoto dokumentu. V případě zvolení formy realizace, pokud v průběhu realizace bude zjištěno, že forma realizace požadavku na rozvoj není odpovídající, nebude již tato forma měněna. Pokud tedy primárně v průběhu realizace rozvoje prostřednictvím PZ bude zjištěno, že rozsah změny reálně odpovídá standardnímu rozvoji prostřednictvím projektu, musí být v rámci administrace a realizace PZ zajištěna i aktualizace odpovídající dokumentace (typicky architektura Systému). Náklady na posouzení požadavku na rozvoj nejsou fakturovány zvlášť, tedy v případě neschválení realizace, jak formou PZ, tak formou projektu, ze strany Objednatele, není možné vůči Objednateli uplatňovat nároky na úhradu prací souvisejících s administrací požadavku na rozvoj ze strany Poskytovatele.

3.4.1.4Vyhodnocení dopadů rozvoje

Každý požadavek na rozvoj musí být v rámci analýzy a posouzení rovněž vyhodnocen z hlediska:

  • Dopadů na informační a kybernetickou bezpečnost, tedy, zda a jakým způsobem ovlivní realizace požadavku nastavení informační a kybernetické bezpečnosti Systému, zejména s ohledem na důvěrnost, dostupnost a integritu dat i aplikační vrstvy.

  • Dopadů na provozní podmínky informačního prostředí SZIF, tedy např. zda a jakou bude znamenat implementace požadavku na rozvoj zátěž na infrastrukturní prostředí SZIF, zda jsou implementací ovlivněny integrované systémy, a to jak z hlediska jejich architektury, či objemu zpracovávaných dat, aj.

  • Dopadů na procesy Objednatele – primární odpovědnost za identifikaci dopadů má Objednatel, ale v případě, že požadavek na rozvoj váže na jinou funkcionalitu a může mít dopady i na jiné činnosti Objednatele, je Poskytovatel povinen toto zohlednit.

  • Dalších potenciálních dopadů identifikovaných Poskytovatelem.

3.4.1.5Komunikace v rámci rozvoje

V rámci administrace i realizace požadavku na rozvoj budou strany Objednatele i Poskytovatele průběžně komunikovat a případně ověřovat nezbytné informace tak, aby požadavky na rozvoj zadávané ze strany Objednatele byly realizovány v odpovídající kvalitě, stanoveném čase i definovaném rozpočtu. Každá identifikovaná nejasnost, případně problém, musí být komunikována, aby při předání požadavku na rozvoj k testování nedocházelo k zásadním rozporům ohledně připravené funkčnosti.

3.4.1.6Dokumentace

Vzhledem k tomu, že realizace požadavků na rozvoj má vždy dopad do informačního prostředí Objednatele, musí být každý takový požadavek dokumentován. Rozsah dokumentace musí adekvátním způsobem odpovídat obsahu požadavku, tedy předmětem realizace požadavku musí být rovněž předání/aktualizace provozní, systémové, projektové, uživatelské či jiné dokumentace. Bez předání/aktualizace odpovídající dokumentace není možné provést akceptaci PZ nebo projektu.

3.4.1.7Testování

Každý realizovaný požadavek na rozvoj musí být testován. Rozsah testování musí adekvátním způsobem odpovídat obsahu požadavku, tedy předmětem realizace požadavku musí být rovněž příprava odpovídajících testovacích scénářů s uvedením požadovaného výsledku testování. Na straně Poskytovatele musí být realizována taková sada testů, aby bylo prokazatelně doloženo, že případné nasazení realizovaného požadavku na rozvoj v produktivním prostředí je bezpečné jak z hlediska provozu informačního prostředí SZIF, tak z hlediska informační a kybernetické bezpečnosti. Na straně Objednatele musí být realizována taková sada testů, aby bylo prokazatelně doloženo, že případné nasazení realizovaného požadavku na rozvoj v produktivním prostředí odpovídá plně věcnému zadání Objednatele. Testování musí vždy probíhat v testovacím prostředí. Není možné požadavek na rozvoj uvolnit do produktivního prostředí s tím, že dotestování proběhne zde. Při realizaci testování pracují zaměstnanci Objednatele i Poskytovatele v součinnosti tak, aby testování bylo umožněno a odpovídalo nezbytnému rozsahu. Bez doložení odpovídajícího testování není možné požadavek na rozvoj schválit.

3.4.1.8Uvolňování do produkce a akceptace

Uvolňování realizovaných požadavků na rozvoj do produktivního prostředí (release) probíhá formálním a řízeným způsobem, a to standardně jednou týdně. Uvolnění do produkce realizuje a schvaluje provozní projektový tým, včetně stanoveného oprávněného pracovníka Objednatele, na základě předložení veškeré požadované dokumentace k realizovanému požadavku na rozvoj ze strany rozvojového projektového týmu. Detailní postup i určení konkrétního termínu pro release je předmětem provozní dokumentace, která je schvalována na úrovni provozního projektového týmu. Release mimo standardní stanovený proces je možný výhradně s výslovným odsouhlasením ze strany Garanta provozního projektového týmu (za Objednatele) a Vedoucího týmu provozu (za Poskytovatele).

Finální akceptace a potvrzení akceptace ze strany Objednatele je vždy možná až po uplynutí 14 kalendářních dní od releasu požadavku na rozvoj do produktivního prostředí, kdy bude potvrzeno korektní chování funkčnosti ve standardních provozních podmínkách Objednatele. V případě, že oprávněná osoba ze strany Objednatele nevznese námitky vůči funkčnosti uvolněné do produktivního prostředí v termínu 14 dní, je funkčnost považována za akceptovanou.

3.4.2Předpokládaný rozsah a nacenění služeb rozvoje

Objednatel předpokládá rozsah realizovaných služeb v objemu 670 MD (5.360 hodin) v průběhu Pilotního a akceptačního provozu a 500 MD (4.000 hodin) v průběhu každého z následujících kalendářních roků.

Skutečný objem Služeb rozvoje závisí zejména na legislativních a dalších změnách, které mohou zásadním způsobem skutečně požadované čerpání Služeb rozvoje ovlivnit, a to oběma směry. Reálná cena služeb rozvoje je pak dána vždy skutečným objemem oboustranně odsouhlasených a čerpaných služeb při stanovené sazbě za MD, a to jak při realizaci rozvoje prostřednictvím požadavku na změnu, tak prostřednictvím projektu.

Součástí ocenění každého požadavku na rozvoj bude rovněž „uvedení do provozu“. Poskytovatel zajistí uvolnění funkčnosti do produktivního prostředí, kdy tato funkčnost bude součástí provozovaného prostředí Systému bez dalších nákladů na navýšení cen služeb provozu.

3.4.3IS05 – Rozvoj prostřednictvím požadavku na změnu (PZ)

Detailní metodika řízení změn prostřednictvím požadavků na změnu (PZ) je interním metodickým postupem Objednatele a jako taková podléhá změnám i v závislosti na možné organizační, procesní a technologické změny na straně Objednatele. Použití této metodiky v aktuálním znění bude předmětem schvalování projektové dokumentace na úrovni Řídícího výboru vždy pro následující kalendářní rok. Součástí metodiky je vždy rovněž aktuální podoba formuláře Požadavku na změnu, jejíž grafická struktura se může měnit. Níže definované postupy řízení rozvoje prostřednictvím požadavků na změnu tak stanovují závazné a neměnné principy, které detailní metodika rozpracovává do konkrétních postupů.

3.4.3.1Definice a obsah služby IS 05

Pomocí služby rozvoje prostřednictvím PZ se realizují a evidují veškeré změny Systému, kdy:

  • rozsah jednoho požadavku na změnu nepřesahuje na straně Poskytovatele kapacitní náročnost 100 MD,

  • požadovaná změna nemá dopad na architekturu Systému (aplikační, technologickou, datovou).

Pokud je zřejmé, že požadovaná změna nesplňuje obě dvě uvedená kritéria, musí být změna realizována prostřednictvím projektu.

Změny mohou být vyvolané:

  • požadavkem na základě identifikované změny v metodice procesů SZIF, a to zejména vlivem změn legislativy (EU a ČR),

  • požadavkem uživatele na racionalizaci nebo zlepšení prováděných činností a postupů v Systému,

  • požadavkem na změnu v Systému vlivem změny vnějšího ICT prostředí Objednatele mimo Systému,

  • dalšími významnými faktory.

Požadavky na změnu může navrhovat i Poskytovatel služby, zejména v případech, kdy dochází k systémovým změnám (nové verze infrastrukturních komponent a využitých služeb) anebo změnám v aplikačních službách a aplikační infrastruktuře.

Obsahem Služby je poskytování služeb Poskytovatele za účelem úprav, změn, rozvoje Systému tak, aby stav Systému odpovídal požadavkům Objednatele na zajištění daných funkčností systému. Předmětem služby je pak zajištění kompletního procesu administrace a implementace požadavků na rozvoj Systému a včetně evidence prováděných úprav Systému realizovaných na základě této služby.

3.4.3.2Procesní nastavení služby

Proces rozvoje prostřednictvím požadavku na změnu se sestává z následujících kroků:

  1. Vytvoření Požadavku na změnu – PZ

Předmětem tohoto kroku je vyplnění formuláře PZ, jehož součástí je kompletní zadání požadované funkčnosti. V případě, že předmětem plnění PZ je změna interních procesů Objednatele, bude součástí PZ i procesní schéma s jednoznačným určením změn procesů, které mají být promítnuty v Systému.

Součástí Zadávaného PZ bude minimálně:

  • Předmět: stručný název/popis požadavku,

  • Modul: název SW modulu/komponenty, které se požadavek dotýká,

  • Kategorie: Úprava/Rozšíření/Změna Funkcionality Systému, Jiná,

  • Priorita: dle důležitosti/naléhavosti - Nízká, Střední, Vysoká,

  • Žádající: Xxxxx, Příjmení,

  • Datum zadání,

  • Požadované datum předání k uživatelským testům na testovacím prostředí,

  • Požadované datum produktivního startu – zahájení užívání funkčností realizovaného PZ,

  • Podmínky Akceptace funkčnosti a PZ ze strany Objednatele,

  • Autorizace PZ – schválení zadání požadavku na změnu věcným metodickým garantem Objednatele, Vedoucím příslušného projektového týmu a Garantem projektového týmu.

Vytvoření PZ zajišťuje Objednatel

  1. Předání PZ Objednatelem k posouzení Poskytovatelem

Jedná se o formální krok, kdy oprávněná osoba Objednatele (typicky vedoucí daného projektového týmu Objednatele), předává vyplněný formulář PZ na Poskytovatele (dle formy předání buď na příslušného Vedoucího projektového týmu Poskytovatele, nebo prostřednictvím automatizovaného nástroje). Okamžikem prokazatelného předání je aktivována lhůta pro posouzení PZ Poskytovatelem.

  1. Posouzení PZ Poskytovatelem a předání posouzeného PZ k rozhodnutí Objednateli

Předmětem tohoto kroku je věcné, odborné (projektové) a finanční posouzení Požadavku na změnu a zároveň doplnění všech dalších nezbytných záležitostí PZ. Součástí posouzení PZ, které na své straně zajišťuje Poskytovatel, je rovněž věcné vyhodnocení a návrh řešení implementace daného PZ. Výstupem posouzení PZ bude upravený formulář obsahující následující údaje ze strany Poskytovatele:

  • Popis implementace a návrh řešení požadované úpravy/změny Systému.

  • Identifikované dopady na:

    • Celkovou architekturu Systému (pokud by byly identifikovány nezbytné změny v oblasti solution architektury na úrovni aplikační a technologické vrstvy, bude PZ vráceno Objednateli a rozvojový požadavek bude nezbytné realizovat prostřednictvím projektu) a ostatní komponenty Systému.

    • Bezpečnostní prostředí a vlastnosti Systému.

    • Provozní prostředí a infrastrukturu pro Systému.

    • Rozhraní Systému na další systémy a datovou vrstvu.

    • Aktuální dokumentaci Systému.

    • Okolní ICT prostředí Objednatele.

    • Nastavená přístupová oprávnění Systému.

    • Další provozně a bezpečnostně významné oblasti informačního prostředí Objednatele.

  • Definované testovací procedury, které budou realizovány ze strany Poskytovatele, aby byla plnohodnotně zajištěna stabilita a bezpečnost produktivního prostředí Systému.

  • Potvrzené požadované termíny realizace PZ, případně navržené nové termíny, pokud není možné původní požadované termíny splnit. V případě nově navržených termínů se tyto termíny musí maximálně blížit termínům požadovaným Objednatelem, zároveň Poskytovatel k navrženým termínům uvede zdůvodnění, proč není možné realizovat PZ v původních termínech požadovaných Objednatelem.

  • Požadavky na zdroje – s uvedením jednotlivých rolí Poskytovatele a předpokládanou čerpanou kapacitu (v hod).

  • Maximální kapacitní náročnost daného PZ (v hod a MD) a maximální cenu realizovaného PZ.

  • Autorizaci PZ ze strany oprávněných pracovníků Poskytovatele.

Výše uvedené údaje musí být ze strany Poskytovatele doplněny do formuláře PZ vždy. V případě, že nejsou identifikované dopady v jednotlivých oblastech, bude i v těchto částech minimálně doplněno vyjádření, že žádné dopady nebyly ze strany Poskytovatele identifikovány.

Maximální doba posouzení a odeslání posouzeného PZ je stanovena na 5 pracovních dnů. Nejpozději 5. pracovní den (do konce pracovní doby Objednatele) navazující po dni předání PZ k posouzení bude doplněné, posouzené a autorizované PZ předáno stanoveným způsobem na Objednatele.



  1. Rozhodnutí o realizaci PZ

Na základě posouzeného PZ určí Objednatel, zda bude PZ realizován dle zaslaného návrhu, kdy výsledkem mohou být následující stavy PZ:

  • Schválení PZ na základě posouzení ze strany Poskytovatele v plném rozsahu úprav provedených Poskytovatelem. V takovém případě bude schválený a autorizovaný PZ zaslán Poskytovateli, kdy se PZ stává závaznou objednávkou realizace rozvojového požadavku.

  • Neschválení PZ bez náhrady – v takovém případě informuje Objednatel Poskytovatele, že daný PZ nebude realizován.

  • Projednání PZ – PZ je nezbytné realizovat, ale jsou nezbytné úpravy – v takovém případě iniciuje Vedoucí projektového týmu Objednatele projednání návrhu daného PZ, kdy výstupem projednání musí být buď stavy: Schválení PZ, Neschválení PZ, Eskalace na vyšší úroveň řízení programu.

  • Eskalace PZ – v případě nedohody na úrovni Projektového týmu je stav PZ eskalován na vyšší úroveň řízení Programu – typicky HTPG, případně ŘV.

V případě rozhodnutí o Schválení PZ či Neschválení PZ zasílá Objednatel potvrzení o stavu PZ nejpozději 5. pracovní den (do konce pracovní doby Objednatele) navazující po dni předání posouzeného PZ ze strany Poskytovatele k Rozhodnutí na Objednatele. V případě požadavku na Projednání PZ či Eskalaci PZ bude lhůta pro rozhodnutí stanovena individuálně dohodou Objednatele a Poskytovatele.

  1. Zahájení realizace PZ

Na základě Schválení PZ zahájí Poskytovatel realizaci Požadavku na změnu. Vývoj Požadavku na změnu bude realizován na Vývojovém prostředí. Toto prostředí není dostupné pro pracovníky Objednatele a rovněž na tomto prostředí nejsou standardně uchovávána žádná data (produktivní/testovací) Systému. Předávání funkcionalit do testovacího prostředí, kde probíhá samotné testování (jak ze strany Poskytovatele, tak ze strany Objednatele) je plně v provozní režii Poskytovatele. Poskytovatel musí přenos funkcionalit do testovacího prostředí realizovat takovým způsobem, aby nedocházelo k nekonzistencím u dalších funkčností, které mohou být připravovány v rámci testovacího prostředí. Vývoj na straně Poskytovatele bude realizován takovým způsobem, aby bylo garantováno zachování principů bezpečného vývoje dle ISO 27001.

  1. Předání výstupů PZ k otestování

Předávání jednotlivých požadovaných částí funkčností dle PZ bude probíhat v souladu s definovaným a schváleným harmonogramem PZ. O možnosti zahájení testování vyrozumí vždy oprávněná osoba Poskytovatele zadavatele PZ ze strany Objednatele. Testování probíhá dle definovaných testovacích scénářů za účelem ověření požadovaných funkčností.

  1. Potvrzení otestování PZ

V případě, že je testování úspěšné, následuje potvrzení a akceptace provedených testů. Tato akceptace probíhá na úrovni zadavatel PZ a určený pracovník Poskytovatele. Akceptace testů je potvrzována vždy formálně elektronickou formou dle detailní odsouhlasené metodiky. Jakmile bude akceptováno otestování funkčnosti v testovacím prostředí, založí oprávněná osoba Poskytovatele Požadavek na uvolnění PZ do produktivního prostředí prostřednictvím Service Desku.

  1. Schválení releasu PZ do produktivního prostředí

Na základě definovaného Požadavku na uvolnění PZ do Produkce určí Vedoucí týmu provozu nejbližší možný termín releasu PZ do produktivního prostředí, a to v souladu s nastavenými lhůtami pro uvolňování do Produktivního prostředí a autorizuje Požadavek na release PZ, který je následně předán na zástupce provozního týmu ze strany Objednatele. Požadavek na release PZ musí být ze strany Poskytovatele autorizován nejpozději 1 pracovní den před požadovaným releasem PZ. Vedoucí týmu provozu rovněž v rámci autorizace potvrdí, že byla provedena aktualizace provozní dokumentace ze strany Poskytovatele, pokud byla tato aktualizace nezbytná. Zástupce provozního týmu ze strany Objednatele potvrdí realizaci releasu nejpozději do 11 hodin v den požadovaného releasu, pokud není do této doby realizace releasu ze strany Objednatele potvrzená, má se za to, že je release schválen. Zamítnutí releasu ze strany Objednatele bude možné pouze, pokud jsou identifikována taková rizika, že by mohla být ohrožena stabilita informačního prostředí na straně Objednatele.

  1. Akceptace PZ

Na základě releasu požadovaných funkčností PZ do produktivního prostředí následuje akceptační procedura daného PZ. Na straně Objednatele dojde k ověření, že veškeré uvolněné funkčnosti odpovídají požadovaným charakteristikám. Zároveň dojde k ověření, že byla provedena aktualizace veškeré nezbytné dokumentace. Po tomto ověření vystaví Vedoucí projektového týmu Objednatele Akceptační protokol k danému PZ, zajistí jeho potvrzení oprávněnými osobami na straně Objednatele a předá jej příslušnému Vedoucímu Projektového týmu na straně Poskytovatele. Vystavení a předání Akceptačního protokolu musí být realizováno nejpozději do konce pracovní doby 10. pracovního dne po releasu PZ do produktivního prostředí. V případě, že nedojde k předání Akceptačního protokolu v daném termínu, zašle příslušný Vedoucí projektového týmu Poskytovatele písemnou informaci na Vedoucí programu Objednatele i Poskytovatele, že daný PZ je považován za akceptovaný z důvodu nesoučinnosti ze strany Objednatele. V takovém případě potvrzuje na základě této informace Akceptaci PZ Vedoucí programu Poskytovatele.

3.4.4IS06 – Rozvoj prostřednictvím projektu

Prostřednictvím dílčích projektů jsou řízeny rozsáhlé požadavky na rozvoj obsahující změnu/implementaci/rozvoj Systému, přesahující svými charakteristikami rozsah Požadavku na změnu. Každý požadavek na rozvoj identifikovaný na úrovni projektového týmu, který je potřeba realizovat prostřednictvím projektu, je předkládán na schválení Hlavnímu týmu programu, který rozhoduje o realizaci/nerealizaci daného projektu. Každý schválený projekt je přidělen do konkrétního stanoveného projektového týmu. V případě, že je pro určitý projekt nezbytné definovat novou řídící strukturu projektu (Sponzor projektového týmu (projektu), Garant projektového týmu (projektu) Objednatele a Vedoucí projektového týmu (Objednatele i Poskytovatele), která neodpovídá schválené struktuře programu, je svoláno jednání Řídícího výboru programu, na němž je provedena a odsouhlasena změna organizační struktury po dobu realizace konkrétního projektu.

3.4.4.1Základní metodologie projektu

  • Každý projekt schválený na úrovni ŘVPG je realizován v konkrétních daných termínech, s definovaným maximálním rozpočtem a danými lidskými zdroji na straně Objednatele i Poskytovatele.

  • Vlastní způsob konkrétní realizace projektu bude vždy definován v zastřešujícím konkrétním metodickém nastavení každého projektu, a to formou dokumentu – Dokumentace nastavení projektu (PID).

  • Dokumentace nastavení projektu a jeho schválení na úrovni HTPG pro konkrétní projekt je nezbytnou podmínkou pro zahájení realizace projektu.

  • V případě, že bude nezbytné odchýlit se od schválené Dokumentace nastavení projektu, je toto možné výhradně se souhlasem HTPG.

  • Projekt je vždy realizován v definovaných etapách.

  • Obsah projektu je definován prostřednictvím „Produktů projektu“, případně „Produktů etap“, kdy každý Produkt podléhá akceptaci. Tedy akceptace Produktu(ů) etapy je rovněž podmínkou pro akceptaci konkrétní etapy.

  • Součástí každého projektu je i specifický výstup (Produkt) – Aktualizace dokumentace Systému (provozní, architektonické, bezpečnostní, uživatelské a jiné). Předmětem tohoto Produktu je analýza, úprava a akceptace změn dokumentace Systému. Pokud aktualizace není v rámci realizace projektu nezbytná, bude toto výslovně uvedeno v konkrétní Kartě produktu.

3.4.4.2Projektová dokumentace

  • Projektová dokumentace každého projektu je kompletně standardizovaná. Její projektová část je definována v rámci PID každého projektu.

  • Pro základní projektovou dokumentaci jsou definovány šablony. Tyto šablony je možné v rámci Dokumentace nastavení projektu modifikovat, pokud by rozsah dokumentace neodpovídal rozsahu daného projektu.

  • Pro dokumentaci realizovanou v projektu platí obecná pravidla pro dokumentaci Systému.

3.4.4.3Akceptace a fakturace projektu

  • Konkrétní způsob akceptace v rámci každého projektu definuje rovněž Dokumentace nastavení konkrétního projektu.

  • Práce realizované v rámci projektu mohou být fakturovány výhradně na základě potvrzených akceptací, pro fakturaci projektu se uplatní principy stanovené ve Smlouvě a v kapitole č. 4.4. této Přílohy č. 3 Smlouvy.



3.5Jednorázové služby

Realizace jednorázových služeb je stanovena za účelem případného předání či ukončení poskytování části plnění Smlouvy, případně celého plnění Smlouvy, pokud by k tomu měl Objednatel na své straně objektivní důvody (EXIT). Jednorázové služby jsou realizovány prostřednictvím projektu, kdy je Poskytovatel povinen realizaci jednorázové služby zajistit. V případě neprovedení realizace jednorázové služby ze strany Poskytovatele, je Poskytovatel povinen Objednateli uhradit veškeré náklady, které prokazatelně Objednateli na základě nerealizované jednorázové služby vznikly.

3.5.1JS01 – Ukončení poskytování dílčí služby

Označení

Název Aktivity

JS01

Ukončení poskytování dílčí služby

Rozsah Služby JS01



Ukončení poskytování dílčí služby (všechny dílčí služby s výjimkou ukončení poskytování cloudových služeb)


Realizace ukončení poskytování dílčí služby probíhá vždy prostřednictvím projektu, jehož cena odpovídá jednorázové fixně určené ceně. Řízené ukončení poskytování dílčí služby se stanovuje za účelem zpracování a následného provedení koordinovaného a procesně vymezeného postupu při ukončení poskytování konkrétní(ch) aktivity/aktivit, nebo služby/služeb, nebo konkrétní(ch) jednoznačně vymezené/vymezených aplikační(ch) části/částí – komponent(y) Systému, provedení předání konkrétní aktivity/aktivit služby/služeb, nebo komponent(y) Systému Objednateli, nebo jím určenému subjektu a ukončení poskytování dílčí služby/aktivity pro dané komponenty Poskytovatelem. Cílem služby je v případě Ukončení poskytování dílčí služby zajistit plynulé a bezproblémové ukončení služby či předání služby jinému poskytovali tak, aby nedošlo k narušení smluvních provozních parametrů Systému.



Tato jednorázová Služba probíhá paralelně s poskytováním všech ostatních služeb dle Katalogu služeb (IS01-IS06).


Obsah služby:


Zpracování Scénáře a provedení Scénáře ukončení poskytování dílčí služby


V rámci řízeného ukončení poskytování dílčí služby musí Poskytovatel připravit na základě výzvy Objednatele detailní Scénář ukončení poskytování služby, který bude obsahovat postup a harmonogram předávání dané konkrétní aktivity/služby/komponenty Systému Objednateli nebo novému poskytovateli konkrétní části služeb za účasti Objednatele. Přesné vymezení subjektu, kterému bude dílčí část služeb Systému předávána, stanoví Objednatel při zahájení této služby, pokud je předmětem služby předání novému poskytovateli služeb. Scénář musí být navržen a dokumentován tak, aby pokrýval veškeré zdroje/artefakty, které je třeba předat Objednateli anebo určenému Poskytovateli tak, aby dílčí komponentu/aktivitu/službu bylo možné vykonávat v prostředí Objednatele či nového poskytovatele.



Scénář bude zejména obsahovat:

  • seznam objednatelem stanovených komponent/aktivit/služeb provozu Systému, které jsou součástí Díla a tedy majetku Objednatele a které Poskytovatel v průběhu účinnosti této Smlouvy provozoval, spravoval, rozvíjel a podporoval.

  • seznam všech zdrojových kódů, částí Systému, konfigurací a dalších artefaktů nezbytných pro poskytování dílčí komponenty/aktivity/služby včetně určení formátu a způsobu předání

  • architektonickou, projektovou, provozní, bezpečnostní a další dokumentaci převzatou, aktualizovanou a vytvářenou v průběhu poskytování služeb vztahující se k stanoveným komponentám/aktivitám/službám provozu Systému.

  • záznamy (reporty, provozní deníky, auditní záznamy, atd.) vytvořené v průběhu poskytování služeb;

  • znalostní báze, dat a záznamů, a to zejména na úrovni aplikace ServiceDesk tak, aby po ukončení poskytování dílčí služby bylo zajištěno, že Objednatel disponuje kompletními a správnými informacemi a know-how pro zajištění dílčí služby.

Součástí Scénáře Ukončení poskytování dílčí služby zároveň musí být řešení následujících oblastí:

  • rozsah, forma a obsah součinnosti Poskytovatele při předávání dílčí služby Systému novému provozovateli, případně při přesunu komponent Systému do prostor anebo cloudových služeb určených Objednatelem (pokud bude tento přesun požadován) a při instalaci nebo nasazení komponent Systému v těchto nových prostředích,

  • příprava detailních testovacích scénářů a akceptačních protokolů, na jejichž základě bude Objednatel (nebo nový provozovatel) ověřovat úplnost, správnost a funkcionalitu specifikovaných komponent Systému a jednotlivých funkčností konkrétními komponentami Systému zajišťovanými pro migraci do nového prostředí.

  • provedení školení pracovníků nového provozovatele za účelem detailního seznámení s předávaným prostředím, jeho parametry, vyvíjenými oblastmi, rozpracovaným rozvojem, atd.

Scénář Ukončení poskytování dílčí služby vytvořený v rámci služby JS01 může být ověřován na výzvu Objednatele nebo v rámci auditu Systému realizovaného nezávislým auditorem.


Zpracování Scénáře Ukončení poskytování dílčí služby Systému


Scénář Ukončení poskytování dílčí služby zpracovává Poskytovatel vždy, bez ohledu na důvod ukončení poskytování dílčí služby dle této Smlouvy.

Poskytovatel provede tuto činnost (přípravu Scénáře Ukončení poskytování dílčí služby) automaticky, na základě požadavku na realizaci projektu ze strany Objednatele tak, aby její plnění zahájil nejpozději 60 kalendářních dní před termínem požadovaného Ukončení poskytování dílčí služby dle této Smlouvy. Zpracovaný Scénář Ukončení poskytování dílčí služby je Poskytovatel povinen předat k připomínkám a akceptaci Objednateli. Připomínky je Objednatel povinen uplatnit nejpozději ve lhůtě 5 kalendářních dní tak, aby Poskytovatel měl dalších 5 kalendářních dní na jejich zapracování a nejpozději 40 kalendářních dní před termínem Ukončení poskytování dílčí služby dle této Smlouvy byl Scénář ukončení akceptován a mohla být zahájena činnost – Provedení Scénáře Ukončení poskytování dílčí služby (viz níže).


Provedení Scénáře Ukončení poskytování dílčí služby Systému


Poskytovatel provede v rámci této klíčové činnosti Scénář ukončení poskytování dílčí služby podle schváleného postupu a harmonogramu tak, aby nejpozději do 40 kalendářních dní od zahájení této činnosti došlo k protokolárnímu ukončení poskytování dílčí služby dle této Smlouvy.


Poskytovatel je povinen zajistit, že po předání dílčí služby Systému zpět Objednateli (nebo Objednatelem určenému subjektu) bude jak předávaná část Systému, tak po předání Poskytovatelem provozovaná část Systému, a jejich jednotlivé komponenty ve stavu umožňujícím další provoz Systému. Veškerá data a informace vzniklé v průběhu poskytování Služeb dle této Smlouvy a jejichž předání bude předmětem této jednorázové služby, budou předána v podobě, v jaké byla vytvářena a ukládána při provozu, podpoře a rozvoji Systému (jinými slovy: nebudou prováděny žádné exporty, konverze a převody dat a informací, předávají se funkční komponenty s plným datovým obsahem), stejně tak budou předány veškeré nově vyvinuté funkce/komponenty/služby, customizace či úpravy SW nástrojů sloužících pro zajištění provozu, skripty a další programové úpravy vzniklé při poskytování služeb.


Všechny tyto produkty vytvořené v rámci provozu, podpory a rozvoje Systému se stávají majetkem Objednatele okamžikem jejich vytvoření a akceptací ze strany Objednatele a Poskytovatel je povinen je náležitě předat při Ukončení poskytování dílčí služby.


Objednatel má právo s výše uvedenými nově vyvinutými funkcemi/komponentami/službami a customizacemi, úpravami SW nástrojů sloužících pro zajištění provozu, podpory a rozvoje, skripty a dalšími programovými úpravami vzniklými při poskytování služeb nakládat bez jakéhokoliv omezení včetně možnosti předání k využívání i úpravám třetím stranám.


Úspěšné provedení Scénáře Ukončení poskytování dílčí služby bude smluvními stranami písemně zdokumentováno formou Zprávy o poskytnuté službě. Dílčí části Systému jsou považovány za předané akceptací této Zprávy oběma smluvními stranami.

Popis Služby

Ukončení poskytování dílčí služby – ukončení poskytování cloudových služeb


Scénář Ukončení poskytování dílčí služby postihuje případ, kdy je Systém přenášen do jiného prostředí cloudových služeb, avšak Systém je nadále provozován a rozvíjen původním Poskytovatelem. Přípravu scénáře, přenesení Systému, nasazení Systému v novém cloudovém prostředí, jeho otestování a provoz provádí původní (stejný Poskytovatel). V případě Ukončení poskytování dílčí služby se současnou změnou Poskytovatele je využita služba JS02.

Realizace Ukončení poskytování dílčí služby – ukončení poskytování cloudových služeb probíhá vždy prostřednictvím projektu. Scénář pro Ukončení poskytování dílčích služeb – ukončení cloudových služeb zpracovává Poskytovatel v rámci realizace Díla (ve fázi vlastní Implementace) a cena za jeho zpracování je zahrnuta v ceně vlastní Implementace. Scénář obsahuje obecné informace a postupy Ukončení poskytování dílčí služby a migrace Systému. Detailní postupy závislé na podobě cílového cloudového prostředí, do něhož má být Systém migrován, budou doplněny v průběhu aktualizace scénáře, jak je uvedeno dále.


Pouze na výzvu Objednatele provede Poskytovatel aktualizaci Scénáře a realizaci Ukončení poskytování dílčí služby – ukončení cloudových služeb (provedení Scénáře Ukončení poskytování dílčí služby – ukončení cloudových služeb). Řízené Ukončení poskytování dílčí služby – ukončení cloudových služeb se stanovuje za účelem zpracování a následného provedení koordinovaného a procesně vymezeného postupu při ukončení poskytování cloudových služeb, provedení předání cloudových služeb Objednateli, nebo jím určenému subjektu a Ukončení poskytování dílčí služby Poskytovatelem. Cílem služby je v případě Ukončení poskytování dílčí služby zajistit plynulé a bezproblémové ukončení služby či předání služby jinému poskytovali tak, aby nedošlo k narušení smluvních provozních parametrů Systému.


Tato jednorázová Služba probíhá paralelně s poskytováním všech ostatních služeb dle Katalogu služeb (IS01-IS06).


Obsah služby:


Zpracování, aktualizace a provedení Scénáře Ukončení poskytování dílčí služby – ukončení cloudových služeb


Předmětem služby je zpracování a aktualizace detailního Scénáře Ukončení poskytování dílčí služby – ukončení cloudových služeb, který bude obsahovat postup a harmonogram ukončení poskytování cloudových služeb, plán využití obdobných cloudových služeb v novém cloudovém prostředí a obecně postup migrace (přenosu) Systému do nového cloudového prostředí. Přesné vymezení nového prostředí cloudových služeb, do kterého bude Systém migrován, předá Objednatel Poskytovateli při zahájení této služby.

Scénář musí být navržen a dokumentován tak, aby pokrýval veškeré cloudové služby a části Systému, které je třeba přenést do nového cloudového prostředí tak, aby v novém prostředí bylo možné provozovat Systém s požadovanými smluvními provozními parametry.


Scénář (a jeho následná aktualizace) bude zejména obsahovat:

část pro migraci cloudových služeb (resp. přípravy cloudových služeb v novém prostředí) zahrnující:

  • pro každou využitou cloudovou službu návrh využití obdobné cloudové služby v cílovém cloudovém prostředí, případně jiný způsob řešení zajištění funkcionality touto službou poskytované;

  • postup přenesení konfigurace či kódu pro každou cloudovou službu tak, aby služba poskytovala Systému všechny požadované funkcionality;

  • plán migrace dat každé služby, zahrnuje-li služba migrovatelná data;

  • návrh testů (testovacích scénářů) pro ověření korektního přenesení/nastavení/vytvoření cloudové služby v novém prostředí;

  • odhad kapacit a dob potřebných pro provedení jednotlivých aktivit včetně určení profesí, které je budou vykonávat (lze uvádět interval, u aktivit závislých na vlastnostech cílového prostředí, lze uvést hrubý odhad a zřetelné vyznačení těchto aktivit ve scénáři).



část migrace Systému do nově přípravného cloudového prostředí zahrnující:

  • seznam všech migrovaných částí Systému;

  • plán migrace a postup migrace jednotlivých částí Systému;

  • identifikace rizik souvisejících s migrací a návrh jejich eliminace;

  • plán migrace dat Systému, pokud jsou spravována mimo cloudové služby;

  • návrh testů (testovacích scénářů) pro ověření korektního přenesení Systému do nového cloudového prostředí a jeho bezchybné funkcionality

Scénář Ukončení poskytování dílčí služby – ukončení cloudových služeb může být ověřován na výzvu Objednatele nebo v rámci auditu informačního systému realizovaného nezávislým auditorem.

Aktualizace Scénáře:

Poskytovatel provede automaticky aktualizaci Scénáře, na základě požadavku ze strany Objednatele tak, aby aktualizovaný scénář byl k dispozici nejpozději 60 kalendářních dní před termínem požadovaného Ukončení poskytování dílčí služby dle této Smlouvy. Aktualizovaný Scénář Ukončení poskytování dílčí služby je Poskytovatel povinen předat k připomínkám a akceptaci Objednateli. Připomínky je Objednatel povinen uplatnit nejpozději ve lhůtě 5 kalendářních dní tak, aby Poskytovatel měl dalších 5 kalendářních dní na jejich zapracování a nejpozději 40 kalendářních dní před termínem Ukončení poskytování dílčí služby dle této Smlouvy byl Scénář ukončení akceptován a mohla být zahájena činnost – Provedení Scénáře Ukončení poskytování dílčí služby (viz níže).


Provedení Scénáře Ukončení poskytování dílčí služby Systému:


Poskytovatel provede v rámci této klíčové činnosti Scénář Ukončení poskytování dílčí služby podle schváleného postupu a harmonogramu tak, aby nejpozději do 40 kalendářních dní od zahájení této činnosti došlo k protokolárnímu Ukončení poskytování dílčí služby dle této Smlouvy.


Poskytovatel je povinen zajistit, že po přenesení Systému do nového cloudového prostředí budou cloudové služby poskytovat veškeré funkcionality umožňujícím bezproblémový provoz Systému a Systém bude plně funkční a provozuschopný v souladu se smluvními provozními parametry. Veškerá data a informace vzniklé v průběhu poskytování Služeb dle této Smlouvy a jejichž předání bude předmětem této jednorázové služby, budou předána v podobě, v jaké byla vytvářena a ukládána při provozu, podpoře a rozvoji Systému (jinými slovy: nebudou prováděny žádné exporty, konverze a převody dat a informací, předávají se funkční komponenty s plným datovým obsahem), stejně tak budou předány veškeré nově vyvinuté funkce/komponenty/služby, customizace či úpravy SW nástrojů sloužících pro zajištění provozu, skripty a další programové úpravy vzniklé při poskytování služeb.


Všechny tyto produkty vytvořené v rámci provozu, podpory a rozvoje Systému se stávají majetkem Objednatele okamžikem jejich vytvoření a akceptací ze strany Objednatele a Poskytovatel je povinen je náležitě předat při Ukončení poskytování dílčí služby.


Objednatel má právo s výše uvedenými nově vyvinutými funkcemi/komponentami/službami a customizacemi, úpravami SW nástrojů sloužících pro zajištění provozu, podpory a rozvoje, skripty a dalšími programovými úpravami vzniklými při poskytování služeb nakládat bez jakéhokoliv omezení včetně možnosti předání k využívání i úpravám třetím stranám.


Úspěšné provedení Scénáře Ukončení poskytování dílčí služby bude smluvními stranami písemně zdokumentováno formou Zprávy o poskytnuté službě. Dílčí části Systému jsou považovány za předané akceptací této Zprávy oběma smluvními stranami.

SLA parametry / Vyhodnocení




Dodržení termínů harmonogramu předání dílčí služby Systému, akceptovaná Zpráva o poskytnuté službě.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Scénáře Ukončení poskytování dílčí služby

Scénáře Ukončení poskytování dílčích služeb

Pro akceptaci se uplatní obecná akceptační kritéria pro předávání dokumentace dle Smlouvy.

Zpráva o poskytnuté službě

Na základě realizovaného projektu bude zpracovaná souhrnná zpráva obsahující, mimo jiné, tyto povinné náležitosti:

  • Schválený Scénář Ukončení poskytování dílčí služby.

  • Testovací scénáře a schválené akceptační protokoly z provedení Scénáře ukončení.

  • Předávací protokol k dílčí službě Systému.

Pro akceptaci uvedené Zprávy se uplatní obecná akceptační kritéria pro předávání dokumentace dle Smlouvy v rámci souhrnné Zprávy o stavu provozu Systému.

Způsob stanovení celkové ceny služby

Jednorázová cena

Cena Ukončení poskytování dílčí služby (všechny dílčí služby s výjimkou ukončení poskytování cloudových služeb) je stanovena jednorázovou, pevně danou cenou za zpracování Scénáře pro Ukončení poskytování dílčí služby a provedení (realizaci) Scénáře Ukončení poskytování dílčí služby, která bude uhrazena po akceptaci aktualizace a provedení Scénáře Ukončení poskytování dílčí služby.


Cena Ukončení poskytování dílčí služby – ukončení poskytování cloudových služeb je stanovena jednorázovou, pevně danou cenou za aktualizaci Scénáře pro Ukončení poskytování dílčí služby – ukončení poskytování cloudových služeb a provedení (realizaci) Scénáře Ukončení poskytování dílčí služby ukončení poskytování cloudových služeb, která bude uhrazena po akceptaci aktualizace a provedení Scénáře Ukončení poskytování dílčí služby. (Cena za zpracování Scénáře pro Ukončení poskytování dílčí služby – ukončení poskytování xxxxxxxxxx služeb je zahrnuta v ceně vlastní Implementace Díla).

3.5.2JS02 – Ukončení poskytování služeb

Označení

Název Aktivity

JS02

Ukončení poskytování Služeb

Rozsah aktivity

Popis (obsah) aktivity

Realizace Ukončení poskytování Služeb probíhá vždy prostřednictvím projektu. Scénář Ukončení poskytování Služeb zpracovává Poskytovatel v rámci realizace Díla (ve fázi vlastní Implementace) a cena za jeho zpracování je zahrnuta v ceně vlastní Implementace.

Pouze na výzvu Objednatele provede Poskytovatel aktualizaci Scénáře a realizaci Ukončení poskytování Služeb (provedení Scénáře Ukončení poskytování Služeb).

Řízené Ukončení poskytování Služeb se stanovuje za účelem zpracování a následného provedení koordinovaného a procesně vymezeného postupu při Ukončení poskytování veškerých služeb realizovaných Poskytovatelem, provedení předání Systému Objednateli nebo jím určenému subjektu a ukončení smluvního vztahu s Poskytovatelem. Cílem služby je v případě Ukončení poskytování Služeb zajistit plynulé a bezproblémové ukončení Služeb či předání Služeb jinému poskytovateli tak, aby nedošlo k narušení smluvních provozních parametrů Systému.


Tato jednorázová Služba obvykle probíhá paralelně s poskytováním všech ostatních služeb dle Katalogu služeb (IS01-IS06). Pokud by došlo k ukončení Smlouvy za specifických podmínek, kdy není poskytování služeb dle této Přílohy č. 3 Smlouvy možné, bude tato jednorázová služba Ukončení poskytování Služeb poskytnuta bez ohledu na poskytování služeb IS01-IS06 (typicky ukončení Smlouvy dohodou, výpovědí v průběhu Implementace, případně Odstoupení od Smlouvy).


Obsah služby:


Zpracování, aktualizace a provedení Scénáře Ukončení poskytování Služeb


Předmětem služby je zpracování a aktualizace detailního Scénáře Ukončení poskytování Služeb, který bude obsahovat postup a harmonogram předávání kompletního plnění souvisejícího s realizací Díla a poskytováním Služeb souvisejících se Systémem (majetku, odpovědností, povinností, dokumentace, atd.) Objednateli nebo novému provozovateli služeb za účasti Objednatele. Přesné vymezení subjektu, kterému bude Systém předáván, stanoví Objednatel při zahájení této služby.


Scénář (a jeho následná aktualizace) bude zejména obsahovat:

  • seznam veškerých komponent Systému, které jsou majetkem Objednatele a které Poskytovatel v průběhu účinnosti této Smlouvy provozoval, spravoval, rozvíjel a podporoval.

  • seznam všech zdrojových kódů, částí Systému, konfigurací a dalších artefaktů nezbytných pro poskytování dílčí komponenty/aktivity/služby včetně určení formátu a způsobu předání.

  • kompletní architektonickou, projektovou, provozní, bezpečnostní a další dokumentaci převzatou, aktualizovanou a vytvářenou v průběhu poskytování služeb vztahující se k Systému.

  • záznamy (reporty, provozní deníky, auditní záznamy, atd.) vytvořené v průběhu poskytování služeb;

  • znalostní báze, dat a záznamů, a to zejména na úrovni aplikace ServiceDesk tak, aby po Ukončení poskytování Služeb bylo zajištěno, že Objednatel, případně jím stanovený nový provozovatel disponuje kompletními a správnými informacemi a know-how pro zajištění dílčí služby.

Součástí Scénáře Ukončení poskytování Služeb zároveň musí být řešení následujících oblastí:

  • rozsah, forma a obsah součinnosti Poskytovatele při předávání Služeb Systému novému provozovateli, případně při přesunu Systému do prostor určených Objednatelem (pokud bude tento přesun požadován) a při instalaci Systému v těchto prostorách,

  • příprava detailních testovacích scénářů a akceptačních protokolů, na jejichž základě bude Objednatel (nebo nový provozovatel) ověřovat úplnost, správnost a funkcionalitu Systému a jednotlivých funkčností Systémem zajišťovaných.

  • provedení školení pracovníků nového provozovatele za účelem detailního seznámení s předávaným prostředím, jeho parametry, vyvíjenými oblastmi, rozpracovaným rozvojem, atd.

Aktualizace Scénáře:

Poskytovatel provede aktualizaci Scénáře, na základě požadavku ze strany Objednatele tak, aby aktualizovaný scénář byl k dispozici nejpozději 90 kalendářních dní před termínem požadovaného Ukončení poskytování Služeb dle této Smlouvy. Aktualizovaný Scénář Ukončení poskytování Služeb je Poskytovatel povinen předat k připomínkám a akceptaci Objednateli. Připomínky je Objednatel povinen uplatnit nejpozději ve lhůtě 5 kalendářních dní tak, aby Poskytovatel měl dalších 5 kalendářních dní na jejich zapracování a nejpozději 60 kalendářních dní před termínem Ukončení poskytování Služeb dle této Smlouvy byl Scénář Ukončení poskytování Služeb akceptován a mohla být zahájena činnost – Provedení Scénáře Ukončení poskytování Služeb (viz níže).


Provedení Scénáře Ukončení poskytování Služeb a předání Systému:


Poskytovatel provede v rámci této klíčové činnosti Scénář Ukončení poskytování Služeb podle schváleného postupu a harmonogramu tak, aby nejpozději do 60 kalendářních dní od zahájení této činnosti došlo k protokolárnímu Ukončení poskytování Služeb dle této Smlouvy.


Poskytovatel je povinen zajistit, že po předání Služeb zpět Objednateli (nebo Objednatelem určenému subjektu) bude Systém a jeho jednotlivé komponenty ve stavu umožňujícím další provoz Systému. Veškerá data a informace vzniklé v průběhu poskytování Služeb dle této Smlouvy budou předána v podobě, v jaké byla vytvářena a ukládána při provozu, podpoře a rozvoji Systému (jinými slovy: nebudou prováděny žádné exporty, konverze a převody dat a informací, předávají se funkční komponenty s plným datovým obsahem), stejně tak budou předány veškeré nově vyvinuté funkce/komponenty/služby, customizace či úpravy SW nástrojů sloužících pro zajištění provozu, skripty a další programové úpravy vzniklé při poskytování služeb.


Všechny tyto produkty vytvořené v rámci provozu, podpory a rozvoje Systému se stávají majetkem Objednatele okamžikem jejich vytvoření a akceptací ze strany Objednatele a Poskytovatel je povinen je náležitě předat při Ukončení poskytování Služeb.


Objednatel má právo s výše uvedenými nově vyvinutými funkcemi/komponentami/službami a customizacemi, úpravami SW nástrojů sloužících pro zajištění provozu, podpory a rozvoje, skripty a dalšími programovými úpravami vzniklými při poskytování Služeb nakládat bez jakéhokoliv omezení včetně možnosti předání k využívání i úpravám třetím stranám.


Úspěšné provedení Scénáře Ukončení poskytování Služeb bude smluvními stranami písemně zdokumentováno formou Zprávy o poskytnuté službě. Systém je považován za předaný akceptací této Zprávy oběma smluvními stranami.

Pokud dochází k Ukončení poskytování Služeb na základě jiné skutečnosti, než je předložení požadavku na realizaci projektu ze strany Objednatele (např. v případě výpovědi Smlouvy v průběhu Implementace, na základě odstoupení od Smlouvy, aj.), jsou lhůty pro realizaci této Služby stanoveny následovně:

Zahájení aktualizace Scénáře Ukončení poskytování Služeb: první pracovní den následující po skutečnosti, která vede k Ukončení poskytování Služeb.

Dokončení aktualizace Scénáře Ukončení poskytování Služeb a jeho předání Objednateli k akceptaci v plném a konečném znění: nejpozději 20. pracovní den od zahájení přípravy Scénáře Ukončení poskytování Služeb.

Zahájení realizace Scénáře Ukončení poskytování služeb: první pracovní den po akceptaci Scénáře Ukončení poskytování Služeb.

Celková doba realizace Scénáře Ukončení poskytování Služeb: Maximálně 60 kalendářních dní od Xxxxxxxx realizace Scénáře Ukončení poskytování Služeb.

Doba zajištění aktivity


SLA parametry / Vyhodnocení




Dodržení termínů harmonogramu předání Služeb Systému, akceptovaná Zpráva o poskytnuté službě.

Požadované výstupy aktivity

Název výstupu

Charakteristika

Způsob akceptace

Scénář Ukončení poskytování Služeb

Scénář Ukončení poskytování Služeb

Pro akceptaci se uplatní obecná akceptační kritéria pro předávání dokumentace dle Smlouvy.

Zpráva o poskytnuté službě

Na základě realizovaného projektu bude zpracovaná souhrnná zpráva obsahující, mimo jiné, tyto povinné náležitosti:

  • Schválený Scénář Ukončení poskytování Služeb.

  • Testovací scénáře a schválené akceptační protokoly z provedení Scénáře ukončení.

  • Předávací protokol k Systému.

Pro akceptaci uvedené Zprávy se uplatní obecná akceptační kritéria pro předávání dokumentace dle Smlouvy v rámci souhrnné Zprávy o stavu provozu Systému.

Způsob stanovení celkové ceny služby

Jednorázová cena

Cena je stanovena jednorázovou, pevně danou cenou za aktualizaci Scénáře pro Ukončení poskytování Služeb a provedení (realizaci) Scénáře Ukončení poskytování Služeb, která bude uhrazena po akceptaci aktualizace a provedení Scénáře Ukončení poskytování Služeb. (Cena za zpracování Scénáře pro Ukončení poskytování Služeb je zahrnuta v ceně vlastní Implementace Díla).


Je-li realizováno Ukončení poskytování Služeb (Úplný Exit), nehradí se vedle ceny aktivity JS02 žádná cena za ukončení poskytování dílčí služby (zejména se nehradí zvlášť cena na ukončení cloudových služeb).

4Vyhodnocení služeb

Poskytování Služeb rozvoje i Služeb provozu podléhá vyhodnocení, zda byly jednotlivé služby a jejich části poskytnuty v souladu s definovanými podmínkami a obsah poskytovaných služeb odpovídá požadavkům Objednatele vyplývajícím ze Smlouvy případně z definovaného zadání. Poskytovatel je povinen po konci vyhodnocovacího období vypracovat odpovídající projektovou dokumentaci, která dokládá čerpání služeb ve skončeném vyhodnocovacím období. Tato projektová dokumentace se sestává z odpovídajících výkazů/zpráv jednotlivých služeb tak, jak jsou definovány v katalogových listech a popisech služeb, případně obsah projektové dokumentace vyplývá z dalších dokumentů (např. PID u realizovaných projektů). Součástí výkazů musí být vždy čerpání kapacit v rámci dotčených projektových týmů. Součástí Výkazů musí být rovněž vyhodnocení kvality poskytovaných služeb dle definovaných požadavků a SLA parametrů.

Z hlediska výkazů (statistik, reportů a podkladů k SLA) za Vyhodnocovací období pro posouzení jednotlivých SLA parametrů platí za oblast provozu, že:

  • relevantní jsou pouze záznamy Poskytovatelem vyřešené a Objednatelem uzavřené, které byly přiřazeny Poskytovateli s tím, že byla prokázána příčinná souvislost mezi porušením smluvních povinností Poskytovatele a vznikem incidentu, resp. nebyla prokázána příčina vzniku incidentu u jiné Služby. V případě, že by vyhodnocení a následné uzavření incidentu přesáhlo do dalšího Vyhodnocovacího období, je Poskytovatel povinen zpětně přepočítat SLA po uzavření všech incidentů a stanovit výši neuplatněné kreditace, ke které došlo na základě doby trvání uzavření incidentu. Neuplatněná kreditace bude Poskytovatelem započtena do fakturace za dané Vyhodnocovací období.

  • záznamy odmítnuté Poskytovatelem s tím, že jejich příčina nebyla prokázána v rámci provozu příslušné Služby (např. nefunkčnost infrastruktury, nebo chyba integrity dat způsobená uživatelem systému, či okolním informačním prostředí), nejsou do statistik zahrnuty. Takovéto záznamy musí být Poskytovatelem doplněny řádným odůvodněním a Objednatelem na základě doplněného odůvodnění Poskytovatele uzavřeny jako neplatné.



Součástí výkazů musí být vyčíslená kreditace u služeb, které nebyly ve vyhodnocovacím období poskytnuty v souladu se stanovenými parametry. Kreditace jednotlivých služeb bude na základě akceptovaných výkazů rovněž uvedena na faktuře vztahující se k danému vyhodnocovacímu období a částka faktury za dané období bude o tuto kreditaci upravena.

V následujících kapitolách 4.1. – 4.3. jsou uvedeny jednotlivé parametry vyhodnocení a kreditace k nim vztažené. V případě, že není uvedeno jinak, je v rámci níže definovaných kapitol cenou, ze které je kreditace kalkulována, vždy myšlena cena bez DPH.  

4.1Parametry a kreditace Služeb provozu

Níže uvedené tabulky zobrazují výčet parametrů SLA s příslušnými kreditacemi a způsobem výpočtu pro jednotlivé Služby provozu.

4.1.1Parametry snížení ceny ve Vyhodnocovacím období pro službu IS01

P.č.

Aktivita

Název parametru

Kreditace

Způsob výpočtu

1.

A01

Dostupnost a odezva prostředí PROD

3,0 %

Z celkové ceny služby IS01 za příslušný kalendářní měsíc za každých započatých 0,1 % pod stanovenou hodnotu parametru.

2.

A01

Dostupnost a odezva prostředí TEST/DEV

2,0 %

Z celkové ceny služby IS01 za příslušný kalendářní měsíc za každých započatých 0,1 % pod stanovenou hodnotu parametru.

3.

A01

Výskyt Vady A

4,0 %

Z celkové ceny služby IS01 za příslušný kalendářní měsíc za každý další výskyt nad maximální počet vad ve vyhodnocovacím období.

4.

A01

Výskyt Vady B/C

2,0 %

Z celkové ceny služby IS01 za příslušný kalendářní měsíc za každý další výskyt nad maximální počet vad ve vyhodnocovacím období.

5.

A02

Nerealizovaná kopie v daném termínu

2,0 %

Z celkové ceny služby IS01 za příslušný kalendářní měsíc v případě nerealizace kopie v daném termínu z důvodů na straně Poskytovatele.

6.

A03

Nerealizovaný test obnovy Systému dle požadavku Objednatele

80.000,- Kč

Jednorázová kreditace služby IS01 – v případě nerealizace kompletního testu obnovy Systému ve stanoveném termínu z důvodů na straně Poskytovatele.

7.

A03

Nerealizované pravidelné testování dle požadavku Objednatele

50.000,- Kč

Jednorázová kreditace služby IS01 – v případě nerealizace testu Systému ve stanoveném termínu z důvodů na straně Poskytovatele.

8.

A03

Neakceptovaný test obnovy Systému

50.000,- Kč

Jednorázová kreditace služby IS01 – Test obnovy nepotvrdí, že definované provozní postupy jsou validní, nebo dokumentace Systému není aktuální.

9.

A03

Neakceptované pravidelné testování Systému

20.000,- Kč

Jednorázová kreditace služby IS01 – Testování nebylo akceptováno z důvodů vad na straně Poskytovatele.

10.

A04

Neposkytnutí požadované součinnosti

10.000,- Kč

Jednorázová kreditace služby IS01 – Porušení povinnosti poskytovatele poskytnout součinnost. Kreditace se uplatní pro každé jednotlivé neposkytnutí součinnosti.

11.

A07

Neodpovídající dokumentace Systému

80.000,- Kč

Na základě výroku auditora ISMS byla identifikována neshoda nebo zjištění ke stavu dokumentace Systému. Kreditace služby IS01 bude uplatněna za každé vyhodnocovací období, ve kterém neshoda nebo zjištění trvá.



4.1.2Parametry snížení ceny ve Vyhodnocovacím období pro službu IS02

P.č.

Aktivita

Název parametru

Kreditace

Způsob výpočtu

12.

A08

Zjištění nerealizované bezpečnostní aktualizace v prostředí PROD

5,0 %

Z celkové ceny služby IS02 za příslušný kalendářní měsíc za každé zjištění o neprovedení bezpečnostní aktualizace, pokud neprovedení nebylo výslovně schváleno Objednatelem.

13.

A08

Neprovedení otestování bezpečnostní aktualizace v prostředí DEV a TEST

2,0 %

Z celkové ceny služby IS02 za příslušný kalendářní měsíc za každé zjištěné neprovedení testování bezpečnostní aktualizace v prostředí DEV a TEST, pokud neprovedení nebylo výslovně schváleno Objednatelem.

14.

A09

Zjištění nerealizované provozní aktualizace v prostředí PROD

2,0 %

Z celkové ceny služby IS02 za příslušný kalendářní měsíc za každé zjištění o neprovedení bezpečnostní aktualizace, pokud neprovedení nebylo výslovně schváleno Objednatelem.

15.

A09

Neprovedení otestování provozní aktualizace v prostředí DEV a TEST

1,0 %

Z celkové ceny služby IS02 za příslušný kalendářní měsíc za každé zjištěné neprovedení testování bezpečnostní aktualizace v prostředí DEV a TEST, pokud neprovedení nebylo výslovně schváleno Objednatelem.

16.

A12

Zjištění neautorizovaného zásahu (opravy chyby) v Systému

0,5 %

Z celkové ceny služby IS02 za příslušný kalendářní měsíc za každý zjištěný případ neautorizovaného zásahu do Systému ze strany Poskytovatele.



4.1.3Parametry snížení ceny ve Vyhodnocovacím období pro službu IS03

P.č.

Aktivita

Název parametru

Kreditace

Způsob výpočtu

17.

A13

Nenahlášení podezření na vznik bezpečnostní události/incidentu včas

2,0 %

Z celkové ceny služby IS03 za příslušný kalendářní měsíc za každých 15 minut prodlení nahlášení podezření na vznik bezpečnostní události/incidentu bezpečnostnímu manažerovi SZIF.

18.

A14

Nenahlášení podezření na vznik provozní události/incidentu včas

1,0 %

Z celkové ceny služby IS03 za příslušný kalendářní měsíc za každých 15 minut prodlení nahlášení podezření na vznik provozní události/incidentu na 1. úroveň Service Desku SZIF.





4.1.4Parametry snížení ceny ve Vyhodnocovacím období pro službu IS04

P.č.

Aktivita

Název parametru

Kreditace

Způsob výpočtu

19.

A16

Nedodržení reakční doby na přidělení ticketu během provozní doby 5x12

1,0 %

Z celkové ceny služby IS04 za příslušný kalendářní měsíc za každých 30 minut prodlení (nad rámec stanovené reakční doby) potvrzení zahájení řešení ze strany Poskytovatele pro každý jednotlivý ticket.

20.

A16

Nedodržení reakční doby na přidělení ticketu během provozní doby 7x24

1,0 %

Z celkové ceny služby IS04 za příslušný kalendářní měsíc za každých 180 minut prodlení (nad rámec stanovené reakční doby) potvrzení zahájení řešení ze strany Poskytovatele pro každý jednotlivý ticket, pokud je ticket ze strany Objednatele zaslán mimo dobu 5x12.

21.

A17

Nezajištění požadovaného školení uživatelů

10.000,- Kč

Jednorázová kreditace služby IS04 – Porušení povinnosti poskytovatele realizovat školení na základě požadavku Objednatele. Kreditace se uplatní pro každý jednotlivý výskyt.

4.2Parametry a kreditace služeb rozvoje

Kreditace pro Služby rozvoje se stanovuje a zohledňuje po akceptaci konkrétního požadavku na rozvoj (PZ, projekt).

Níže uvedené tabulky zobrazují výčet parametrů SLA s příslušnými kreditacemi a způsobem výpočtu pro jednotlivé Služby rozvoje.



4.2.1Parametry snížení ceny ve Vyhodnocovacím období pro služby rozvoje

P.č.

Služba

Název parametru

Kreditace

Způsob výpočtu

1.

IS05 i IS06

Neprovedení vyhodnocení dopadů požadavku na rozvoj na informační a kybernetickou bezpečnost

10.000,- Kč

Jednorázová kreditace pro každý rozvojový požadavek – v případě, že bude požadavek schválen, bude kreditace uplatněna při akceptaci požadavku. V případě, že požadavek nebude schválen, bude kreditace uplatněna z celkové ceny služby IS01 za příslušný kalendářní měsíc1.

2.

IS05 i IS06

Neprovedení vyhodnocení dopadů požadavku na provozní podmínky informačního prostředí SZIF

10.000,- Kč

Jednorázová kreditace pro každý rozvojový požadavek – v případě, že bude požadavek schválen, bude kreditace uplatněna při akceptaci požadavku. V případě, že požadavek nebude schválen, bude kreditace uplatněna z celkové ceny služby IS01 za příslušný kalendářní měsíc.

3.

IS05

Nepředání posouzeného PZ na Objednatele v požadovaném termínu

8.000,- Kč

Jednorázová kreditace za každý den prodlení se zasláním ohodnoceného a posouzeného PZ ze strany Poskytovatele, pokud není posun termínu schválen Objednatelem.

V případě, že bude požadavek schválen, bude kreditace uplatněna při akceptaci požadavku. V případě, že požadavek nebude schválen, bude kreditace uplatněna z celkové ceny služby IS01.

4.

IS05

Neprovedení vyhodnocení dalších požadovaných dopadů PZ (architektura, rozhraní, dokumentace, přístupová oprávnění)

5.000,-

Jednorázová kumulativní kreditace pro každý PZ. Výše kreditace je konstantní, pokud nebude provedeno vyhodnocení jednoho, nebo všech uvedených dopadů.

V případě, že bude požadavek schválen, bude kreditace uplatněna při akceptaci požadavku. V případě, že požadavek nebude schválen, bude kreditace uplatněna z celkové ceny služby IS01 za příslušný kalendářní měsíc.

5.

IS05

Nesplnění schválených milníků PZ z důvodů na straně Poskytovatele

5 %

Jednorázová kreditace z ceny daného PZ pro každý rozvojový požadavek – kreditace bude uplatněna při akceptaci požadavku z ceny PZ v případě, že PZ nebude:

  • předáno k testování v odsouhlaseném termínu, nebo

  • nebude aktualizována dokumentace v odsouhlaseném termínu, nebo

  • nebude provedeno školení v odsouhlaseném termínu, nebo

  • nebude proveden release v odsouhlaseném termínu

za předpokladu, že nebyl posun termínů odsouhlasen na příslušné projektové úrovni.

6.

IS06

Nesplnění akceptačních milníků jednotlivých etap projektu z důvodů na straně Poskytovatele

5 %

Jednorázová kreditace z ceny daného projektu pro každý rozvojový požadavek – kreditace bude uplatněna při akceptaci projektu z ceny projektu.

7.

IS05 i S06

Neprovedení testování požadavku v testovacím prostředí před požadavkem na release.

10.000,- Kč

Jednorázová kreditace pro každý rozvojový požadavek – kreditace bude uplatněna při akceptaci požadavku z ceny požadavku na rozvoj (PZ i projektu).

8.

IS05 i S06

Neautorizovaný release

20 %

Jednorázová kreditace pro každý rozvojový požadavek (PZ i projekt) – kreditace bude uplatněna při akceptaci požadavku z ceny požadavku na rozvoj (PZ i projektu).



4.3PARAMETRY A KREDITACE JEDNORÁZOVÝCH SLUŽEB JS01 A JS02

Níže uvedená tabulka zobrazuje výčet parametrů SLA s příslušnými kreditacemi a způsobem výpočtu pro jednorázové služby.

P.č.

Služba

Název parametru

Smluvní pokuta

Způsob výpočtu

1.

JS01

Nedodržení lhůty zpracování Scénáře pro Ukončení poskytování dílčí služby nebo pro realizaci Ukončení poskytování dílčí služby (provedení Scénáře Ukončení poskytování dílčí služby)

10.000,- Kč

Výše smluvní pokuty je stanovena na 10.000,- Kč za každý den prodlení při zpracování Scénáře Ukončení poskytování dílčí služby nebo při realizaci Ukončení poskytování dílčí služby (provedení Scénáře Ukončení poskytování dílčí služby).

2.

JS01

Nedodržení lhůty pro aktualizaci Scénáře Ukončení poskytování dílčí služby – ukončení poskytování cloudových služeb nebo pro realizaci Ukončení poskytování dílčí služby – ukončení poskytování cloudových služeb (provedení Scénáře Ukončení poskytování dílčí služby)

10.000,- Kč

Výše smluvní pokuty je stanovena na 10.000,- Kč za každý den prodlení při aktualizaci Scénáře Ukončení poskytování dílčí služby - ukončení poskytování xxxxxxxxxx služeb nebo při realizaci Ukončení poskytování dílčí služby (provedení Scénáře Ukončení poskytování dílčí služby - ukončení poskytování cloudových služeb).

3.

JS02

Nedodržení lhůty pro aktualizaci Scénáře Ukončení poskytování Služeb nebo pro realizaci Ukončení poskytování Služeb (provedení Scénáře Ukončení poskytování Služeb)

20.000,- Kč

Výše smluvní pokuty je stanovena na 20.000,- Kč za každý den prodlení při aktualizaci Scénáře Ukončení poskytování Služeb nebo při realizaci Ukončení poskytování Služeb (provedení Scénáře Ukončení poskytování Služeb).

4.4Vyhodnocení a fakturace služeb

Nejpozději během 5. (pátého) pracovního dne vyhodnocovacího období následujícího po ukončení předchozího vyhodnocovacího období předkládá Vedoucí projektového týmu Poskytovatele Vedoucímu projektového týmu Objednatele soupis čerpání kapacit projektového týmu, jehož součástí je zvlášť vyčleněná samostatná část obsahující seznam PZ a projektů akceptovaných na úrovni jednotlivých projektových týmů v uplynulém kalendářním měsíci a reálné uvedení kapacit čerpaných v rámci daných PZ a projektů (reálné čerpání nesmí překročit maximální stanovenou a odsouhlasenou kapacitní náročnost jednotlivých PZ a projektů). Vedoucí projektového týmu Objednatele provede kontrolu soupisu čerpání kapacit a pokud je tento soupis v pořádku, akceptuje jej včetně zvlášť autorizovaného seznamu akceptovaných PZ a projektů.

Fakturace za vyhodnocovací období je tak realizována na základě akceptace služeb IS01-IS04 a na základě dílčích akceptací prací a potvrzeného seznamu akceptovaných PZ a projektů. Přílohou faktury za konkrétní vyhodnocovací období jsou všechny příslušné akceptační dokumenty za dané období včetně vyčíslení uplatněných kreditací k jednotlivým službám (IS01-IS04) a rozvojovým požadavkům (PZ i projektům).

5Projektová dokumentace – šablony

Následující šablony jsou definovány jako přípustné pro použití v rámci poskytování a vykazování jednotlivých služeb dle této Přílohy č. 3 Smlouvy. Od jednotlivých šablon je možné se odchýlit, pokud bude zachována informační hodnota těmito šablonami definovaná a budou dodrženy principy poskytování služeb dle Best Practice, zákonných požadavků i standardů, které jsou pro Objednatele závazné v rámci akreditačních a jiných podmínek (např. ISO 27001).

Všechny uvedené šablony budou umístěné na konkrétním sdíleném úložišti Objednatele v podobě jednotlivých dokumentů, kdy Objednatel zajistí určeným pracovníkům Poskytovatele přístup k těmto šablonám dle možností Objednatele (typicky do 3 pracovních dní od vznesení požadavku na umožnění přístupu).



5.1 Dokumentace nastavení projektu



Dokumentace nastavení projektu




Název projektu:


Datum:

Verze dokumentu:


Autor:


Vlastník:


Klient:


Autoři dokumentu:

Jméno

Objednatel/Poskytovatel






Revize dokumentu:

Verze

Popis Revize

Datum

Odpovědná osoba

















Schváleno:

Jméno

Objednatel/Poskytovatel

Datum

Podpis











Obsah



  1. Účel dokumentu

Tento dokument - Dokumentace nastavení projektu pro Projekt……., je základním dokumentem pro řízení projektu a obsahuje závazné principy řízení definovaného projektu. Postupy a princip v tomto dokumentu popsané jsou závazné pro všechny strany podílející se na realizaci projektu.

  1. Definice projektu

Projekt je realizován na základě schválení Hlavním týmem programu Portálového systému SZIF a Portálových aplikací XXXX dne: …………..:

Projekt je realizován na základě potřeby …………..

Účelem realizace projektu je ………...


V rámci realizace a řízení projektu budou využity principy a metodika definované v tomto dokumentu.

    1. Cíle projektu

Základním cílem projektu je:

  • …..

Dílčími cíli projektu jsou:

  • …..

  • …..



    1. Popis produktu projektu

Produktem projektu je ……..


Produkty jednotlivých etap jsou následující položky:

  • ……

  • ……

  • ……

Veškeré definované produkty etap podléhají akceptaci ze strany ……..

Produkt projektu bude akceptován, jakmile budou akceptovány všechny dílčí produkty etap.

      1. Definice produktů/produktu projektu

Specifikace jednotlivých produktů včetně produktu projektu jsou specifikovány ve zvláštním dokumentu – Karta produktu, jehož šablona je přílohou tohoto dokumentu. Karta produktu je schválena vždy před zahájením etapy projektu a obsahuje zadání pro danou etapu projektu. Kartu projektu schvaluje Garant projektu Objednatele a Vedoucí projektu Objednatele i Poskytovatele. Veškeré dokumenty předávané v průběhu projektu jako produkty budou zasílány v rámci připomínkování v editovatelné podobě s možností vyhledávat v dokumentu (formát .rtf, .doc, .docx, .xls, .xlsx, .pdf). Finální, oboustranně odsouhlasené verze dokumentů pak budou ve formátu .pdf bez možnosti zásahu do dokumentu.

      1. Akceptace produktu

V kartě produktu jsou definovány:

  • Způsob akceptace

  • Forma akceptačního řízení

  • Odpovědné osoby za akceptaci produktu

  • Požadované termíny předložení produktu k ověření

  • Finální termín akceptace produktu

    1. Kapacitní náročnost projektu a přípustné výjimky

Kapacitní náročnost projektu je stanovena na maximálně………. MD na straně Poskytovatele a pokrývá veškerý rozsah projektu.

Předem dané výjimky z rozsahu nejsou ze strany Objednatele přípustné. V případě Požadavku na výjimku bude tato výjimka definována Poskytovatelem v písemné podobě a akceptována Sponzorem projektu.

Pro její implementaci bude vyhotoven dokument Plán realizace výjimky, který bude zahrnut do aktualizovaného Plánu projektu a odsouhlasen Objednatelem. Po realizaci bude vyhotovena Zpráva o výjimce s akceptací Objednatele.

  1. Organizace projektu

Projekt je realizován v součinnosti jednotlivých členů projektového týmu. Projekt je rozčleněn na etapy s termínovým ohraničením jednotlivých etap i projektu. Termínování etap projektu a samotného projektu je obsaženo v projektovém plánu, který je nedílnou součástí tohoto dokumentu. Projektový plán je závazný pro všechny členy projektu jak na straně Objednatele, tak na straně Poskytovatele.

Za definici činností nezbytných pro realizaci jednotlivých etap a odpovídající akceptace produktů etapy a produktu projektu je odpovědný vedoucí projektu. Pro definici činností na straně Objednatele a požadované součinnosti Objednatele identifikované ze strany realizačního týmu Poskytovatele bude použit dokument – Definice balíku práce Objednatele (viz. Příloha). Definice činností na straně realizačního týmu Poskytovatele se řídí smluvními ujednáními mezi jednotlivými stranami na straně Poskytovatele a není předmětem tohoto dokumentu.

    1. Struktura projektového týmu

S ohledem na rozsah a předmět projektu je Projektový tým rozdělen na dvě části – část řídící (Projektový výbor) a část realizační (Realizační tým).

      1. Projektový výbor

Projektový výbor je hlavní řídící strukturou projektu. Nejvyšším představitelem Projektového výboru je Sponzor projektu, který má v rámci projektu absolutní rozhodovací pravomoc. Jednání projektového výboru nejsou pravidelná. Jednání Projektového výboru svolává Sponzor projektu a to na základě požadavku Garanta projektu, Vedoucího projektu (Objednatele) či Projektového dohledu. Projektový výbor neřeší operativní činnosti projektu, ale je eskalačním orgánem v případě, že projekt neprobíhá v souladu s definovaným projektovým plánem, či podle Dokumentace nastavení projektu. V případě, že nelze realizovat rozhodnutí na úrovni projektového výboru, je nezbytná eskalace na úroveň Hlavního týmu programu.

Složení Projektového výboru


Xxxxxxx projektu – zástupce managementu Objednatele.

(Jméno a Příjmení, funkce)


Rozhoduje o souladu realizace projektu se záměry Objednatele a podmínkami výběrového řízení, informuje vedení Objednatele o průběhu projektu. V případě eskalace projektového rizika nad rámec podmínek projektu (rozsah projektu, termíny projektu) řeší nastalou situaci s managementem Objednatele na úrovni Hlavního týmu programu.


Garant projektu – zástupce Objednatele.

(Jméno a Příjmení, funkce)


Kontroluje soulad navrhovaného řešení se záměry Objednatele v oblasti tvorby řízené dokumentace. Zodpovídá za kontrolu předložených výstupů projektu a akceptuje předložené výstupy po stránce obsahové za stranu Objednatele.


Vedoucí projektu Objednatele – zástupce Objednatele.

(Jméno a Příjmení, funkce)


Zodpovídá za průběh projektu, soulad projektu s definovaným projektovým plánem a Dokumentací nastavení projektu. Je zodpovědný za realizované výstupy v rámci projektu a odsouhlasuje plnění za stranu Objednatele. Řídí veškeré kapacity na straně Objednatele. Zodpovídá za udržování kompletní projektové dokumentace.


Projektový dohled – zástupce Objednatele.

(Jméno a Příjmení, funkce)


Kontroluje soulad průběhu projektu s definovanou projektovou metodikou (PID), kontroluje výkon projektového vedoucího a projektového týmu. Dohlíží na úplnost projektové dokumentace, jejíž správu a údržbu má na starosti vedoucí projektu.


Vedoucí projektu Poskytovatele – zástupce Poskytovatele.

(Jméno a Příjmení)


Zodpovídá za průběh projektu, soulad projektu s definovaným projektovým plánem a Dokumentací nastavení projektu. Je zodpovědný za předávané výstupy (a zároveň tyto předává zástupcům Objednatele) v rámci projektu a odsouhlasuje plnění za stranu Poskytovatele. Řídí veškeré kapacity na straně Poskytovatele. Zodpovídá za udržování kompletní projektové dokumentace.

      1. Realizační tým


Vedoucí týmu Objednatele

  • (Jméno a Příjmení, funkce)

Zodpovídá za tvorbu výstupů v souladu se ……… a v termínech stanovených plánem projektu. Konzultuje provozní a implementační aspekty realizace projektu. Předkládá návrhy výstupů projektu a výkazy činnosti v termínech stanovených plánem projektu k interní akceptaci vedoucímu projektu Objednatele/Poskytovatele.


Vedoucí týmu Poskytovatele

  • (Jméno a Příjmení)

Zodpovídá za tvorbu výstupů v souladu se ……… a v termínech stanovených plánem projektu. Konzultuje provozní a implementační aspekty realizace projektu. Předkládá návrhy výstupů projektu a výkazy činnosti v termínech stanovených plánem projektu k interní akceptaci vedoucímu projektu Objednatele/Poskytovatele.



Člen realizačního týmu:


  • Role v realizačním týmu: …………….

  • (Jméno a Příjmení, funkce)

Zodpovídá za tvorbu výstupů v souladu se ……… a v termínech stanovených plánem projektu. Konzultuje provozní a implementační aspekty realizace projektu. Předkládá návrhy výstupů projektu a výkazy činnosti v termínech stanovených plánem projektu k interní akceptaci vedoucímu týmu Objednatele/Poskytovatele.




  • Role v realizačním týmu: …………….

  • (Jméno a Příjmení, funkce)

Zodpovídá za tvorbu výstupů v souladu se ……. a v termínech stanovených plánem projektu. Konzultuje provozní a implementační aspekty realizace projektu. Předkládá návrhy výstupů projektu a výkazy činnosti v termínech stanovených plánem projektu k interní akceptaci vedoucímu týmu Objednatele/Poskytovatele.


Člen realizačního týmu:


  • Role v realizačním týmu: …………….

  • (Jméno a Příjmení, funkce)

Zodpovídá za tvorbu výstupů v souladu se ……… a v termínech stanovených plánem projektu. Konzultuje provozní a implementační aspekty realizace projektu. Předkládá návrhy výstupů projektu a výkazy činnosti v termínech stanovených plánem projektu k interní akceptaci vedoucímu týmu Objednatele/Poskytovatele.

Člen realizačního týmu:

  • Role v realizačním týmu: …………….

  • (Jméno a Příjmení, funkce)

Zodpovídá za tvorbu výstupů v souladu se ……. a v termínech stanovených plánem projektu. Konzultuje provozní a implementační aspekty realizace projektu. Předkládá návrhy výstupů projektu a výkazy činnosti v termínech stanovených plánem projektu k interní akceptaci vedoucímu týmu Objednatele/Poskytovatele.


    1. Strategie řízení kvality

Projekt bude řízen v souladu s požadavky ……. a Dokumentace nastavení projektu.

    1. Strategie řízení komunikace

      1. Organizace jednání


Schůzky realizačního týmu se zástupci Objednatele jsou vždy plánovány dopředu. Informování o plánované schůzce/jednání zajišťuje Vedoucí projektu Poskytovatele, případně jím pověřený člen realizačního týmu za stranu Poskytovatele. Pozvání na jednání/schůzku je zasíláno vždy minimálně ….. pracovní dny před termínem jednání/schůzky, pokud se členové projektového týmu nedohodnou jinak.


V emailové pozvánce budou vždy minimálně následující informace:

  • Předmět schůzky/jednání

  • Xxxxxx xxxxxxx/jednání (datum, čas)

  • Místo schůzky/jednání

  • Předpokládaná doba trvání

  • Požadovaný (předpokládaný) výstup z jednání

  • Nezbytné podklady na schůzku/jednání


Mimo konkrétní osoby k jednání/osobní schůzce bude informace o termínu, hodině, místě a účelu zaslána vždy v kopii těmto osobám:

  • Garant projektu

  • Projektový dohled

  • ……


Za organizaci a záznamy/zápisy z jednání zodpovídá vždy Vedoucí projektu poskytovatele, který může organizací a přípravou zápisu/záznamu z jednání pověřit jiného člena realizačního týmu za stranu Poskytovatele. Zápis/záznam je vytvořen z každé schůzky/jednání, a to ve strukturované podobě při použití definované šablony, která je Přílohou tohoto dokumentu. Každý záznam/zápis z jednání musí být odsouhlasen a to písemně podpisem Vedoucího projektu za stranu Poskytovatele a Vedoucím projektu za stranu Objednatele.


Jednání Projektového výboru svolává vždy Sponzor projektu, a to na základě potřeby identifikované některým z členů Řídícího výboru, nebo na základě svého uvážení. Jednání Projektového výboru se účastní zejména členové Projektového výboru, pokud je nezbytné, aby se jednání účastnil kterýkoliv člen realizačního týmu, bude o tomto informovat příslušný Vedoucí projektu předem.


Pro organizaci jednání Projektového výboru platí stejná pravidla jako pro organizaci Schůzky realizačního týmu s výjimkou termínu zaslání pozvánky. Ta je zaslána vždy minimálně ….. pracovních dnů předem, pokud se členové Projektového výboru nedohodnou jinak. Za tvorbu zápisu z Projektového výboru zodpovídá osoba pověřená Sponzorem projektu.

      1. Formální komunikace

Veškerá formální komunikace probíhá formou emailové korespondence. Veškerá emailová komunikace mezi kterýmkoliv zástupcem (zástupci) realizačního týmu či projektového výboru na straně Objednatele a zástupcem (zástupci) realizačního týmu či projektového výboru na straně Poskytovatele je považována za formální komunikaci!

      1. Neformální komunikace


Za neformální komunikaci je považována jakákoliv komunikace telefonická a zároveň komunikace, která probíhá buď výhradně na straně Objednatele, nebo výhradně na straně Poskytovatele. Řízení neformální komunikace není předmětem tohoto dokumentu.


    1. Strategie řízení rizik


Při identifikaci jakéhokoliv rizika v rámci projektu je pracovník, který riziko identifikoval, povinen neprodleně informovat o vzniku rizika příslušného Vedoucího projektu. Řízení rizik a případná eskalace je v plně odpovědnosti Vedoucích projektu. Všechna rizika v projektu budou řízena a evidována v registru rizik (viz. Příloha).

Každému riziku bude přiřazena váha rizika odpovídající součinu pravděpodobnosti výskytu rizika a dopadu rizika.


Pro stanovení pravděpodobnosti výskytu rizika je definována hodnota 0,1 – 1

Pro stanovení dopadu rizika je definována hodnota 0,1 – 1


Jednotlivé hodnoty jsou definovány následovně:


Pravděpodobnost:

0,1 – 0,3 nízká

0,4 – 0,6 střední

0,7 – 1 vysoká


Dopad rizika:

0,1 – 0,3 nízký

0,4 – 0,6 střední

0,7 – 1 vysoký


Stanovená hranice tolerance rizika je …... Všechna rizika s touto a vyšší váhou rizika jsou neprodleně eskalována Projektovému výboru projektu včetně návrhu řešení rizika.


    1. Plán projektu

Plán projektu obsahuje všechny aktivity nezbytné pro realizaci projektu a jejich rozdělení do jednotlivých etap. Etapizace projektu je definována s ohledem na požadované produkty a produkt projektu. Plán projektu schválený pro realizaci tohoto projektu je přílohou Dokumentace nastavení projektu. Za kontrolu činností a naplnění plánu projektu odpovídá Vedoucí projektu.


Jednotlivé etapy definované pro tento projekt jsou:


  1. ETAPA


-

-


  1. ETAPA

-

-


  • Finální předání produktu projektu – …….


    1. Projektová dokumentace

Projektovou dokumentací jsou v rámci projektu myšleny veškeré dokumenty a šablony využívané v rámci průběhu projektu. Projektovou dokumentací se tak rozumí Dokumenty nezbytné pro řízení projektu. Projektová dokumentace není dokumentace, která vzniká věcnou realizací projektu. Takovéto dokumenty jsou Produktem projektu a produkty etap a platí na ně pravidla definovaná v Kartách produktů.

      1. Pravidla pro projektovou dokumentaci

  • Veškerá Projektová dokumentace je řízená a standardizovaná.

  • Veškerá Projektová dokumentace je uložena na úložišti Objednatele, které je umístěno na úložišti Objednatele dostupném na:…….

  • Za úplnost Projektové dokumentace odpovídají Vedoucí projektu.

  • Při akceptaci Projektu je vytvořen souhrnný přehled veškeré Projektové dokumentace, který je předán Objednateli spolu s akceptačním protokolem Projektu.

  • Veškeré dokumenty předávané v průběhu projektu budou zasílány v rámci připomínkování v editovatelné podobě s možností vyhledávat v dokumentu (formát .rtf, .doc, .docx, .xls, .xlsx.). Finální, oboustranně odsouhlasené verze dokumentů pak budou ve formátu .pdf bez možnosti zásahu do dokumentu (v případě podepsaných dokumentů se bude jednat o scan/export s digitálním podpisem dokumentu s plnou čitelností dokumentu).



      1. Přehled Projektové dokumentace

Následující tabulka uvádí přehled všech dokumentů, které budou v rámci tohoto projektu využívány:


Název dokumentu

Umístění

Typ

Šablona

Záznam/zápis z jednání


Záznam

Ano

Zápis z  jednání Projektového výboru


Záznam

Ano

Protokol o předání/ akceptace


Záznam

Ano

Definice balíku práce Objednatele


Záznam

Ano

Karta Produktu Projektu


Baseline

Ano

Karta Produktu


Baseline

Ano

Registr rizik


Report

Ano

Plán Projektu


Baseline


Zpráva o Ukončení Etapy


Report


Požadavek na výjimku


Záznam


Plán Realizace Výjimky


Baseline


Výkaz činnosti


Záznam


Zpráva o Ukončení Projektu


Report


Akceptační Dokumentace Projektu


Report



Vysvětlivky k jednotlivým typům dokumentace:

  • Dokumenty typu Baseline definují aspekty projektu a poté, co jsou schváleny, podléhají změnovému řízení,

  • Záznamy obsahují informace o postupu projektu a musí být v průběhu realizace projektu dynamicky aktualizovány,

  • Reporty poskytují aktuální pohled na stav projektu a jeho vybraných aspektů.



  1. Přílohy:


Číslo přílohy:

Název přílohy:

Příloha:

1

Zápis z jednání - Šablona


2

Zápis z jednání Projektového výboru - Šablona


3

Protokol o předání/Akceptační protokol


4

Definice balíku práce Objednatele


5

Karta Produktu Projektu


6

Karta Produktu


7

Registr rizik


8

Plán projektu





5.2 Zápis – šablona



Zápis z jednání č.

Datum:

Čas:

Místo jednání:

Účastníci:

Objednatel:


Poskytovatel:


Další:


Pro:


Kopie pro:


Zapsal:


Datum:



Agenda

Číslo

Typ

Text

Xxxxxx

Xxxxxxxxx/vznesl

Stav

Předmět jednání:

Číslo aktivity/číslo jednání

I/U/R/A/O





Číslo aktivity/číslo jednání

I/U/R/A/O





Typ: I...Informace U.... Úkol R...Rozhodnutí A...Akceptace O…Otevřený bod
Stav: K...uKončeno P...Posunut T...Trvá Z...Zrušeno


Kontrola úkolů

Číslo

Stav

Text

Poznámka

Xxxxxx

Xxxxxxxxx







Stav: K...uKončeno P...Posunut T...Trvá Z...Zrušeno



Nové úkoly – hlavní plánované aktivity v příštím období

Číslo

Stav

Text

Poznámka

Xxxxxx

Xxxxxxxxx







Stav: K...uKončeno P...Posunut T...Trvá Z...Zrušeno


Identifikovaná rizika

ID rizika

Stav

Informaci podává

Znění rizika














Opatření k rizikům


ID rizika


Aktivita

Realizátor

Termín

původní

(nový)

Stav

1.






Přílohy:

číslo

Název dokumentu

Předkládá


Dokument

1.




2.




3.




4.






Akceptace

Objednatel:


Poskytovatel:


Xxxxx:


………………………….

Xxxxx:

………………………….

Podpis:

………………………….

Podpis:

………………………….

Datum podpisu:

…………………………

Datum podpisu:

………………………….






5.3 Obecný protokol o předání/akceptační protokol – šablona



Předmět akceptace:

Poskytovatel: Oprávněný zástupce:

Oprávněný zástupce Poskytovatele prohlašuje, že předaný Předmět akceptace splňuje dohodnuté Akceptační podmínky, uvedené v:

Předmět akceptace byl poskytnut k prostudování dne DD. MM. RRRR a forma jeho předání odpovídá podmínkám uvedeným v:

Akceptační kritéria pro akceptaci Předmětu akceptace byla stanovena:

Číslo kritéria:

Název kritéria:

Podmínka akceptace kritéria:






Dne: DD. MM. RRRR Místo: Podpis:


Objednatel: Oprávněný zástupce:

Oprávněný zástupce Objednatele potvrzuje na základě kontroly akceptačních kritérií rozhodnutí, že Předmět akceptace splňuje podmínky akceptace takto:

Číslo kritéria:

Název kritéria:

Ověření kritéria:



Akceptováno / Akceptováno s výhradou / Neakceptováno

Celkový předmět akceptace je: Akceptován / Akceptován s výhradou / Neakceptován

Dne: DD. MM. RRRR Místo: Podpis:

Přílohy:

Číslo

Příloha

Forma






5.4 Požadavek na zajištění součinnosti




Definice balíku práce SZIF

(Požadavek na zajištění součinnosti)


Kopie pro:


Zapsal:


Datum:


Požadavek na součinnost a informace

Číslo

Popis požadavku

Požadavek vznesl

Určeno komu

Xxxxxx













Vyjádření k požadavku na součinnost a informace

Číslo


Popis vyjádření

Zapsal

Xxxxxx dodání








Komentář


Odsouhlasení balíku práce



Vedoucí projektu Objednatele:


Vedoucí projektu Poskytovatele:


Xxxxx:


………………………….

Xxxxx:

………………………

Podpis:

………………………….

Podpis:

……………………...

Datum podpisu:

………………………….

Datum podpisu:

………………………














5.5 Karta produktu projektu



Karta produktu projektu


Vytvořil:


Datum:


Produkt:


Akceptační podmínky



Požadavek na produkt

Produkt projektu bude předložen v souladu se smluvními, projektovými podmínkami a splňující akceptační kritéria.

Akceptační kritéria

Věcná akceptace:

  • Budou akceptovány všechny produkty vytvořené v rámci jednotlivých etap projektu

  • Bude dále akceptováno…

Projektová akceptace:

  • Bude k dispozici kompletní projektová dokumentace (vytvořená do…..), a to v podobě naskenovaných podepsaných originálů ve formátu .PDF, nebo v digitální formě zaručující neměnnost a integritu dokumentace.

  • Bude k dispozici kompletní projektová dokumentace a to v podobě podepsaných originálů v listinné podobě.

  • Bude potvrzená realizace jednotlivých etap v termínech definovaných v Plánu projektu.

  • Bude předložen finální akceptační protokol Projektu

Způsob akceptačního řízení

Věcná akceptace:

Projektová akceptace:

  • Kontrola úplnosti projektové dokumentace

  • Kontrola věcné správnosti projektové dokumentace

Osoba odpovědná za předložení produktu k akceptaci

……… – Vedoucí projektu Poskytovatele

Osoba odpovědná za akceptaci produktu

……… – Garant projektu

……… – Projektový dohled

Požadovaný termín předložení produktu k ověření:


Finální termín akceptace produktu:







Odsouhlasení Karty produktu projektu




Vedoucí projektu Objednatele:



Vedoucí projektu Poskytovatele:


Xxxxx:


………………………….

Xxxxx:

………………………

Podpis:

………………………….

Podpis:

……………………...

Datum podpisu:


Datum podpisu:







5.6 Karta produktu




Karta produktu


Vytvořil:


Datum:


Produkt:


Akceptační podmínky



Požadavek na produkt


Akceptační kritéria


Způsob akceptačního řízení


Osoba odpovědná za předložení produktu k akceptaci


Osoba odpovědná za akceptaci produktu


Požadovaný termín předložení produktu k ověření:


Finální termín akceptace produktu:





Odsouhlasení Karty produktu




Vedoucí projektu Objednatele:



Vedoucí projektu Poskytovatele:


Xxxxx:


………………………….

Xxxxx:

………………………

Podpis:

………………………….

Podpis:

……………………...

Datum podpisu:

………………………….

Datum podpisu:

………………………






5.7 Registr rizik



JIČ RIZIKA

POPIS RIZIKA

KDO ZJISTIL

KDY

ČÍSLO ZÁPISU

Pravděpodobnost

Dopad

Váha rizika

Způsob řešení rizika

KDO ZABEZPEČÍ

DO KDY

STATUS

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 

 

 

 

 

 

 

 

0

 

 

 

 













Aktualizováno ke dni:



Vedoucí projektu:







DD. MM. RRRR



Podpis:












































5.8 Plán projektu

Plán_projektu



 

Počet dní

Etapa projektu

Aktivita projektu

Výstup

Termín

Tým 1

Tým 2

Tým 3

Tým 4

1.

ETAPA

 

 

 

 

 

 

 

01.I

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

01.II

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.

ETAPA

 

 

 

 

 

 

 

02.I

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

02.II

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

02.III

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



5.9 Zpráva o ukončení etapy projektu



Zpráva o ukončení ETAPY č.







Název projektu:


Datum:

Verze dokumentu:

.

Autor:


Vlastník:


Klient:


Autoři dokumentu:

Jméno

Objednatel/Poskytovatel







Revize dokumentu:

Verze

Popis Revize

Datum

Odpovědná osoba

















Schváleno:

Jméno

Objednatel/Poskytovatel

Datum

Podpis









Distribuce:

Jméno

Objednatel/Poskytovatel

Datum

Verze























Obsah

1. Manažerské shrnutí 121

2. Přezkoumání Produktu projektu 121

2.1 Produkt 121

2.2 Produkt 121

3. Přezkoumání cílů projektu 121

4. Přezkoumání cílů etapy projektu 121

5. Přezkoumání výkonu týmu 121

6. Lessons Learned 122

7. Xxxxxx a rizika 122

8. Výhled 122

9. Přezkoumání Produktů etapy 123

10. Shrnutí Follow-on akce a doporučení (je-li nutné) 123



  1. Manažerské shrnutí

V rámci … etapy projektu …. byly provedeny tyto základní činnosti:



V průběhu … etapy se nevyskytly/vyskytly žádné zásadní problémy.



  1. Přezkoumání Produktu projektu



    1. Produkt

Byl akceptován bez výhrad.

    1. Produkt

Byl akceptován bez výhrad.





  1. Přezkoumání cílů projektu

Cíle projektu zůstávají zachovány a odpovídají požadavkům projektu definovaným v rámci Dokumentace nastavení projektu a souvisejících projektových i smluvních dokumentů.

  1. Přezkoumání cílů etapy projektu

V rámci etapy byly splněny dílčí cíle projektu, a to:

-

-

-



Dílčích cílů etapy bylo dosaženo a tím byly vytvořeny předpoklady pro….

Dílčí cíle byly splněny v předpokládaných termínech dle Plánu projektu.

  1. Přezkoumání výkonu týmu



  1. Lessons Learned



  1. Xxxxxx a rizika

  2. Výhled











  1. Přezkoumání Produktů etapy



Název produktu

Kvalitativní ukazatele

Požadavky na schválení

Odchylky od specifikací produktu

Plánované

Ukončené




















  1. Shrnutí Follow-on akce a doporučení (je-li nutné)



5.10 Výkazy činností



[POSKYTOVATEL VLOŽÍ NÁVRHY UPRAVENÝCH STRUKTUROVANÝCH VÝKAZŮ ČINNOSTÍ, KTERÉ BUDOU PŘEDMĚTEM AKCEPTACE SLUŽEB, TAK ABY TYTO VÝKAZY ODPOVÍDALY POŽADAVKŮM DEFINOVANÝM V TOMTO DOKUMENTU.]





1 Příslušným kalendářním měsícem se pro účely p. č. 1 až 4 rozumí měsíc, v němž měla být splněna povinnost, jejíž nesplnění je sankcionováno kreditací (tj. např. připadl-li poslední den lhůty pro vyhodnocení dopadů požadavku na rozvoj na informační a kybernetickou bezpečnost na 2. 3., je příslušným kalendářním měsícem březen).

S tátní zemědělský intervenční fond

Ve Smečkách 33, 110 00 Praha 1 Strana 111/124

Document Metadata

Filed: March 19th, 2023