Specifikace předmětu plnění veřejné zakázky

Příloha zadávací dokumentace pro druhou fázi zadávacího řízení č. 5: Specifikace předmětu plnění veřejné zakázky

Specifikace předmětu plnění veřejné zakázky

1. Obecná specifikace předmětu plnění

   1. Úvod

Předmětem této veřejné zakázky (dále též „VZ“) je zřízení a poskytování škálovatelných služeb analýzy a zpracování satelitních a dalších dat, dále zajištění doprovodných plnění služeb průběžného provozu, údržby a rozvoje služby dle specifikace a za podmínek uvedených v zadávací dokumentaci včetně veškerých příloh (dále též „služba SAMAS“).

SAMAS - Satellite Monitoring and Analysis Service

Obsahem a náplní služby SAMAS je:

1. Vytvoření a poskytování služeb analýzy a zpracování satelitních dat pro zajištění plošného monitoringu vybraných zemědělských aktivit a jejich stavů na AP pomocí automatizovaných algoritmů nad daty Sentinel-1 a Sentinel-2, případně dalších. Konkrétně se jedná o služby:

   1. Analýza velikosti a tvaru AP (vhodnost pro vyhodnocení nad daty Sentinel)

   2. Ověření kultury a plodiny

   3. Monitoring sečí a pastvy

   4. Monitoring sklizně hlavní plodiny

   5. Monitoring EFA prvků (úhor, PVN, meziplodina)

   6. Kontrola zachování TTP v oblastech definovaných v rámci ekoplatby nebo ECP

2. Komunikace služby SAMAS s IS Zadavatele prostřednictvím komunikačního a integračního rozhraní zajištěného na straně Zadavatele integrační platformou IS XXXX Zadavatele.

3. Expertní vyhodnocení stavu plnění podmínky na daných AP (Expertní vyhodnocení AP)

4. Mapová služba(y) nad daty Sentinel-2 (NDVI, pravé a nepravé barvy)

5. Pravidelné hodnocení kvality poskytovaných služeb a zvyšování kvality služeb na základě výsledků vyhodnocení jejich kvality

6. Tvorba a údržba dokumentace služby SAMAS a vyhodnocovacích algoritmů a její aktualizace.

7. Poskytování služeb podpory a rozvoje

   1. Poskytování služeb podpory pro dodavatele softwarových aplikací komunikujících se službou SAMAS

   2. Poskytování druhé úrovně podpory řešení problémů koncových uživatelů

   3. Poskytování služeb rozvoje

   4. Poskytování konzultačních služeb a součinnosti

   5. Provádění školení uživatelů a administrátorů Zadavatele.

Tento dokument stanovuje požadavky na předmět plnění veřejné zakázky. Detailní požadavky na plnění jsou dále uvedeny v Příloze č.1 „Závazný návrh smlouvy“ (dále též jen „Smlouva“) této zadávací dokumentace a jejích přílohách č.1 „Závazné implementační, funkční a technické požadavky“ a č.3. „Závazné požadavky na poskytování Služeb“.

V Příloze č. 6 „Technická dokumentace – NDA“ této ZD je detailní specifikace kontextu nezbytného pro zpracování nabídky, kdy informace zde uvedené jsou klasifikovány jako interní, jelikož obsahují informace o interním prostředí a procesech Zadavatele, týkajících se administrace zemědělských dotací.

Zjednodušený pohled na strukturu předpokládaného řešení služby SAMAS včetně nezbytného kontextu okolních systémů je uveden na následujícím obrázku.

Obrázek 1 Zjednodušený pohled na strukturu předmětu plnění

Plnění jako celek musí splňovat všechny požadavky uvedené v zadávací dokumentaci včetně veškerých jejích příloh.

Nabídka dodavatele a parametry nabízeného řešení informačního systému musí rovněž splňovat Minimální technické požadavky, které jsou součástí Přílohy č. 1 Smlouvy jako kapitola č. 2. V rámci této Přílohy č. 1 Smlouvy dodavatel doplní způsob naplnění uvedeného požadavku odkazem na konkrétní ustanovení nabízeného Technického řešení v rámci Přílohy č. 2 a 2a Smlouvy, které bude prokazatelně a bez pochyby dokládat naplnění uvedeného požadavku. Odkaz bude doplněn dodavatelem ve sloupci s názvem „Splnění požadavku“ ke každému z definovaných požadavků identifikovaných sloupci „Reference“ a definovaných sloupci „Znění požadavku“ v celé kapitole č. 2. Přílohy č. 1 Návrhu Smlouvy.

Věcná specifikace a vlastní vymezení požadavků na předmět této veřejné zakázky (SAMAS) v kontextu celého řešení XXXX, tj. souvisejících modulů a služeb včetně souvisejících vazeb na stávající IS Zadavatele, jsou definovány v kapitole č. 6 tohoto dokumentu a detailně popsány v Příloze č. 6 „Technická dokumentace – NDA” této ZD.

2. Milníky harmonogramu předmětu plnění

Detailní způsob a postup poskytování předmětu plnění bude řízen formou projektu. Detailní harmonogram postupného poskytování služeb dle předmětu plnění této VZ bude vytvořen ve spolupráci Poskytovatele a Zadavatele v rámci úvodní fáze realizace projektu implementace SAMAS a v průběhu projektu bude průběžně aktualizován.

Detailní harmonogram plnění musí bezpodmínečně zohledňovat následující nastavené milníky, které jsou dány potřebami Zadavatele pro zajištění výkonu jeho primárních činností (zajištění administrace dotací).

• Dokončení implementace Kritických služeb a jejich podmínečná akceptace umožňující přechod do Pilotního a akceptačního provozu.

• Ukončení Pilotního a akceptačního provozu včetně zajištění implementace plného rozsahu služeb dle této VZ a plná akceptace plnění dle této VZ do 12 měsíců ode dne přechodu do Pilotního a akceptačního provozu.

Do Kritických služeb patří:

1. Analýza velikosti a tvaru AP (vhodnost pro vyhodnocení nad daty Sentinel)

2. Ověření kultury a plodiny

3. Monitoring sečí a pastvy

4. Monitoring sklizně hlavní plodiny

5. Monitoring EFA prvků (úhor, PVN, meziplodina)

6. Kontrola zachování TTP v oblastech definovaných v rámci ekoplatby nebo ECP

7. Komunikace služby SAMAS s IS Zadavatele prostřednictvím komunikačního a integračního rozhraní zajištěného na straně Zadavatele integrační platformou IS XXXX Zadavatele.

8. Mapová/é služba(y) nad daty Sentinel-2 (NDVI, pravé a nepravé barvy)

9. Tvorba a údržba dokumentace služby SAMAS a vyhodnocovacích algoritmů a její aktualizace. Dodání integrační, bezpečnostní dokumentace a její kontinuální aktualizace.

Do Požadovaných služeb patří:

1. Expertní vyhodnocení AP

2. Pravidelné hodnocení kvality poskytovaných služeb a zapracování výsledků vyhodnocení kvality

Rozsah Kritických služeb a funkcí bude zpřesněn a více detailizován v rámci Analytické a Přípravné fáze projektu.

Funkčnost uvedená v Kritických službách je také označovaná jako „Kritická“, ostatní funkčnosti definované zadávací dokumentací této ZD jsou označovány též jako „Požadované“. Rozsah obou kategorií může být změněn v rámci jednacího řízení nebo Analytické a Přípravné fáze.

3. Vytvoření služby

   1. Implementace

Implementace je pro potřeby této ZD definována jako proces, kterým je vytvořena služba dle požadavků stanovených touto ZD. Jedná se o proces, kterým je na základě popisu požadavků a architektonické, analytické a další dokumentace vytvořeno funkční řešení splňující požadavky, které jsou na službu SAMAS v této ZD kladené.

Realizace plnění bude řízena formou implementačního projektu (ten ve standardu Zadavatele zahrnuje i přípravné a analytické práce a kontrolu kvality).

Součástí nabídky bude proto detailní návrh řízení implementačního projektu včetně uvedení projektové metodiky, která bude pro realizaci plnění využita.

1. Požadavky na projektovou metodiku

Metodika, která bude pro řízení projektu využita, musí být v souladu s některým z mezinárodně uznávaných standardů projektového řízení. Návrh detailní metodiky a parametry řízení implementačního projektu definuje Poskytovatel v Příloze č. 2 Smlouvy. Součástí metodiky řízení projektu budou minimálně následující oblasti:

• Nastavení projektu, definice projektových struktur, projektových procesů, kompletní výčet projektové dokumentace, v rámci Projektové struktury bude nejvyšším projektovým orgánem Projektový (Řídící) výbor, který bude vrcholným projektovým a eskalačním orgánem. Projektový výbor bude mít lichý počet členů, kdy počet zástupců ze strany Zadavatele bude vyšší než počet zástupců ze strany Uchazeče.

• Definice a nastavení projektových rolí – Definice všech projektových rolí na straně Poskytovatele, stanovení požadovaných projektových rolí na straně Zadavatele, definice odpovědností projektových rolí.

• Řízení harmonogramu projektu, plánování a kontrola plnění harmonogramů a termínů.

• Řízení kapacit projektu.

• Řízení požadavků na součinnost ze strany Zadavatele, kdy součástí bude formalizovaný postup pro zajištění součinnosti nad rámec projektového plánu. Minimální doba na zajištění požadované součinnosti bude 3. pracovní den po vznesení konkrétního požadavku na součinnost ze strany Poskytovatele. Zadavatel výslovně stanovuje, že pro každý vznesený Požadavek na poskytnutí součinnosti musí být jednoznačně identifikován účel požadované součinnosti, způsob poskytnutí součinnosti (např. jednání, dokument, mimořádné testování atd.), odkaz na řešenou oblast/část/systém (v případě požadavku na součinnost u analytických prací bude odkazem konkrétní část/kapitola/odstavec analytického dokumentu), rizika při neposkytnutí součinnosti.

• Řízení projektové a implementační dokumentace, šablony projektových dokumentů, jejich ukládání a řízení – verzování a schvalování projektových dokumentů. Veškeré projektové dokumenty budou řízené takovým způsobem, aby bylo prokazatelně doloženo, kdy jaký dokument vznikl, kdo je jeho autorem, kdy byl dokument upravován, schválen a akceptován.

• Formy a způsob komunikace v rámci projektu – formální komunikace.

• Řízení rizik, projektu, řízení problémů projektu, eskalační mechanismy projektu.

• Detailní popis způsobů akceptace dílčích částí projektu, jednotlivých etap projektu i celku projektu. Zadavatel výslovně uvádí, že v rámci akceptačního řízení je nezbytné definovat procesy pro průběžnou akceptaci, která bude formalizovaná.

• Řízení kvality projektu – součástí projektové metodiky musí být řízení kvality projektu, které umožní přezkoumání způsobu realizace projektu nezávislým auditním subjektem. Zadavatel výslovně uvádí, že řízení projektu a samotná implementace plnění musí být v souladu s požadavky na řízení vývoje a implementace Významného informačního systému – dle klasifikace zákona č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů, ve znění pozdějších předpisů (dále jen „ZoKB“) a navazujících předpisů a v souladu s požadavky na řízení poskytovatelů dle řady norem ISO/IEC 27000.

2. Průběh implementace

Implementace bude zahrnovat dvě základní implementační fáze:

• Zajištění poskytování Kritických služeb a

• Zajištění poskytování plného rozsahu služeb dle této VZ.

Obě implementační fáze budou projektově oddělené a budou podléhat samostatnému akceptačnímu řízení. Před zahájením každé z fází proběhne revize nastavení projektu včetně projektových týmů a bude formálně odsouhlasen způsob realizace dané fáze. Dodavatel ve své nabídce strukturovaně definuje průběh realizace jednotlivých fází, činnosti realizované v uvedených fázích na své straně a obecné požadované činnosti pro realizaci těchto fází na straně Zadavatele (což zahrnuje i součinnost poskytovatelů dalších částí nebo služeb realizovaného celého řešení XXXX). Dodavatel rovněž definuje předpokládaný harmonogram realizace těchto fází.

1. Analytická a přípravná fáze

V rámci této fáze bude realizováno detailní nastavení vlastního projektu (obou fází), bude realizována detailní analýza a zpracován detailní návrh řešení služby SAMAS.

• Přípravná etapa

  • Detailizace projektových struktur a projektových rolí, nastavení projektu, příprava a odsouhlasení základní projektové dokumentace, konkretizace harmonogramu,

  • Bude limitována časem na max. 10 pracovních dní, kdy budou za stranu Zadavatele stanovena maximálně 3 týmová jednání, kdy poslední jednání bude formálním úvodním jednáním projektu – Kick-off, na kterém též dojde k formálnímu zahájení projektu a odsouhlasení odpovídající projektové dokumentace.

• Předimplementační analýza

  • Bude provedena komplexní analýza prostředí, detailizace požadavků a příprava dokumentů nezbytných pro implementaci,

  • Bude realizována v souladu s principy projektového řízení nastavenými v přípravné fázi a v souladu se schváleným harmonogramem (milníky),

  • Výstupy budou formálně schvalované.

2. Vlastní Implementace – fáze 1

V rámci této fáze bude, v souladu se schválenou implementační dokumentací a stanoveným projektovým harmonogramem, probíhat vlastní implementace služby SAMAS v rozsahu poskytování Kritických služeb. Vlastní implementace začíná schválením výstupů analytické a přípravné fáze projektu a končí podmínečnou akceptací a předáním plnění do Pilotního a akceptačního provozu.

Zadavatel zároveň stanovuje, že v rámci této fáze bude provedena podmínečná akceptace plnění, v jejímž průběhu bude ověřen rozsah a kvalita realizovaných funkcí a Kritických služeb. Úspěšná podmínečná akceptace plnění v rozsahu Kritických služeb je podmínkou zahájení Pilotního a akceptačního provozu.

Zadavatel požaduje, aby dodavatel v rámci své nabídky detailně specifikoval způsob implementace plnění dle této VZ včetně harmonogramu uvolňování jednotlivých služeb do provozu tak, aby k předání docházelo v souladu se stanovenými milníky a byla zajištěna realizace služeb Pilotního a akceptačního provozu dle kapitoly 3.2 a následně Navazujících služeb dle požadavků kapitoly 4 této Přílohy č. 5 Zadávací dokumentace a v souladu s ustanoveními Smlouvy, která tvoří Přílohu č. 1 Zadávací dokumentace.

2. Pilotní a akceptační provoz

Pilotní a akceptační provoz bude zahájen na základě splnění dvou podmínek:

1. Podmíněná akceptace služby SAMAS v rozsahu Kritických služeb Zadavatelem a

2. Zahájení Pilotního a akceptačního provozu projektu SAMAS Zadavatelem.

V rámci pilotního a akceptačního provozu budou Poskytovatelem zajištěny následující služby, které budou mít charakter kontinuálně poskytovaných služeb v průběhu období Pilotního a akceptačního provozu:

• Provoz Kritických služeb:

  • Zajištění poskytování služby SAMAS v rozsahu Kritických služeb v souladu s požadovanými SLA.

  • Dohled a monitoring poskytovaných služeb včetně logování dohodnutého rozsahu transakcí.

  • Integrační a uživatelská podpora služby SAMAS.

• Rozvoj Kritických služeb:

  • Vývoj/customizace dílčích funkčností, jejichž realizace nebyla dokončena/provedena v průběhu fáze Vlastní implementace popsané v kap. 3.1.2.2.

  • Testování poskytovaných a nově zřizovaných služeb/dílčích služeb ve spolupráci s ostatními poskytovateli, kteří se podílejí na vytvoření řešení XXXX.

  • Implementace dalších služeb a funkcí tak, aby bylo realizováno plnění dle této VZ v plném rozsahu, tj. zajištění funkčnosti označované jako „Požadovaná“.

  • Testování „Požadovaných“ služeb a jejich funkcí a jejich uvolňování do produkce.

  • Dílčí akceptační testy implementovaných nebo změněných funkčností nebo služeb.

  • Součinnost při funkčním a integračním testování služeb a funkcí dodávaných třetími stranami, které se službami SAMAS interagují a poskytování další součinnosti Zadavateli v rámci služeb rozvoje v souladu s kap. 4.2.

• Školení:

• Školení spolupracujících poskytovatelů na změny a nové funkce SW rozhraní služby SAMAS

• Školení zaměstnanců Zadavatele na změny a nové funkce služby SAMAS ve stejném rozsahu jako v případě vlastní Implementace

• Update školicích materiálů

Součástí Pilotního a akceptačního provozu bude rovněž jednorázová služba Finální akceptace služby SAMAS, která bude zahrnovat akceptační testy kompletního plnění dodávaného v rámci této VZ i součinnost při akceptačních testech celého řešení XXXX, přípravu celého řešení XXXX k uvedení do rutinního provozu a zahájení poskytování Navazujících služeb v souladu s Přílohou č. 3 Smlouvy.

Detailní specifikace uvedených služeb je definována v Příloze č. 1 Smlouvy, která je nedílnou součástí této Zadávací dokumentace jako její Příloha č. 1.

1. Průběh Pilotního a akceptačního provozu

V průběhu Pilotního a akceptačního provozu bude zajištěn provoz služby SAMAS s produkčními (ostrými) daty a bude zajištěna podpora procesů administrace žádostí vykonávaných pracovníky Zadavatele i souvisejících procesů na straně Žadatele tak, aby bylo možné ověřit plnohodnotnou funkčnost služby SAMAS a její integraci s okolními systémy. V období Pilotního a akceptačního provozu dojde k detailnímu ověření požadovaných vlastností služby SAMAS, definovaných v kompletní analytické a projektové dokumentaci pro implementaci jako nezbytné pro předání do Pilotního a akceptačního provozu („Kritické služby“). V případě zjištění odchylek ve funkčnosti oproti definované dokumentaci a zadání služeb SAMAS bude toto řešeno jako vada plnění postupem dle stanovené klasifikace vady.

Zároveň v průběhu Pilotního a akceptačního provozu bude docházet k uvolňování funkčností definovaných jako „Požadované“ pro zajištění finální akceptace plného rozsahu služby SAMAS, tj. všech ostatních funkcí a služeb, které jsou předmětem plnění Poskytovatele a nebyly dodány v rámci Vlastní implementace, a to v souladu se stanoveným projektovým harmonogramem (bude se jednat o veškeré funkce a služby kategorie „Požadovaná“). V případě identifikace potřeby úpravy/změny služby SAMAS oproti funkčnostem definovaných v rámci předimplementační analýzy (jak funkčnost „Kritická“, tak funkčnost „Požadovaná“) a funkcím definovaným touto ZD, bude toto klasifikováno jako požadavek na dílčí změnu systému, jehož realizace bude probíhat jako změnové řízení dle kapitoly č. 4.2. této Přílohy Zadávací dokumentace.

3. Doba poskytování služeb

Celková doba poskytování služeb Pilotního a akceptačního provozu je stanovena na dobu určitou – 12 kalendářních měsíců, a to od prvního dne následujícího po dni, ve kterém dojde k podmíněné akceptaci, zahájení Pilotního a akceptačního provozu ze strany Zadavatele a předání služby SAMAS do Pilotního a akceptačního provozu. Finální formální akceptace implementace služby SAMAS proběhne v průběhu posledních tří měsíců Pilotního a akceptačního provozu. Vyhodnocovací období pro průběžně dodávané služby je stanoveno na jeden kalendářní měsíc. Vyhodnocování a akceptace průběžně poskytovaných služeb Pilotního a akceptačního provozu bude probíhat v periodě Vyhodnocovacího období a následně pak jejich fakturace a úhrada.

4. Řešení požadavku na změnu ve fázi Pilotního a akceptačního provozu

Jedná se o nástroj, který bude využíván v případě, že bude poptávaná jakákoliv úprava, dílčí změna, rozšíření požadované funkcionality, funkčnosti i aplikace nebo poskytované služby. Požadavek na změnu ve fázi Pilotního a akceptačního provozu zahrnuje veškeré činnosti nezbytné pro úpravy plnění, které nebyly součástí definovaného zadání, a to zejména, nikoliv však výhradně, s ohledem na měnící se legislativu, která bude mít dopad na celkové nastavení cílového řešení služby SAMAS i jeho rozvoj. Požadavky na změnu mohou mít vliv na původně definovanou celkovou aplikační, technickou, funkční architekturu plnění. Realizace požadavků na změnu bude považována za rozvoj systému. Schválené požadavky na změnu tedy budou hrazeny stejně jako služby rozvoje dle kapitoly č. 4.2 této Přílohy Zadávací dokumentace.

4. Navazující služby

   1. Služby provozu

V rámci služeb provozu poptává Zadavatel poskytování služeb v rozsahu definovaném touto VZ včetně jejich změn provedených v průběhu obou fází implementace plnění dle této VZ. Služby provozu budou zahrnovat průběžné kontinuální činnosti, které budou realizovány tak, aby byly splněny detailní požadavky na poskytování služeb dle jednotlivých katalogových listů definovaných v Příloze č. 3 Smlouvy, která je nedílnou součástí této Zadávací dokumentace jako její Příloha č. 1.

Doba poskytování služeb provozu je stanovena na dobu neurčitou, kdy prvním dnem poskytování služeb bude den následující po finální akceptaci Implementace služby SAMAS. Vyhodnocovací období pro průběžně dodávané služby je stanoveno na jeden kalendářní měsíc nebo pro některé metriky kvality 12 měsíců. Pro ostatní dílčí služby je uvedeno v jejich popisu v Příloze č. 3 Smlouvy, která je nedílnou součástí této Zadávací dokumentace jako její Příloha č. 1. Na základě kontrolních reportů uvedených v Příloze č. 3 Smlouvy, bude každé vyhodnocovací období probíhat akceptace služeb provozu, jejich fakturace a úhrada.

Předmětem služeb provozu budou zejména následující dílčí služby:

• Poskytování služeb na integračních rozhraních s dalšími komponentami IS Zadavatele (včetně dalších komponent celkového řešení XXXX)

• Poskytování webových služeb vytvořených na základě této VZ

• Údržba a rozvoj výše uvedených služeb

• Dohled a monitoring provozu poskytovaných služeb

• Poskytování služeb podpory pro dodavatele softwarových aplikací komunikujících se službou SAMAS

• Poskytování druhé úrovně podpory řešení problémů koncových uživatelů a uživatelů služeb rozhraní

• Poskytování služeb rozvoje

• Poskytování konzultačních služeb a součinnosti

• Provádění školení klíčových uživatelů a administrátorů Zadavatele.

2. Služby rozvoje

V rámci služeb rozvoje Zadavatel poptává realizaci změn, úprav, customizací, vývoje, vytváření nových funkcionalit, aplikací plnění dle této VZ. Nejedná se o paušální služby, ale o služby na objednání, které budou zadávány prostřednictvím dvou nástrojů:

• Řešení požadavku na změnu a

• Realizace rozvojového projektu.

1. Řešení požadavku na změnu

Jedná se o zjednodušenou formu realizace projektové změny, kdy není nezbytné zpracovávat kompletní projektovou dokumentaci a realizovat samostatný projekt zahrnující veškeré projektové fáze i projektové nástroje a procesy. Detailní definice služby a procesů řešení požadavku na změnu je předmětem Přílohy č. 3 Smlouvy, která je nedílnou součástí této Zadávací dokumentace jako její Příloha č. 1.

Požadavek na změnu je nástroj, který bude využíván v případě, že bude požadována úprava, dílčí změna, rozšíření stávající funkcionality, funkčnosti, aplikace, customizace dodávaného nebo poskytovaného plnění. Požadavek na změnu tedy zahrnuje činnosti úpravy plnění, které nemají vliv na celkovou aplikační, technickou, funkční architekturu dodávaného nebo podporovaného plnění nebo některého z návazných systémů. Prostřednictvím požadavku na změnu dochází primárně ke změně/úpravě, rozšíření stávajících business procesů Zadavatele. Realizace prostřednictvím Požadavku na změnu bude limitována do náročnosti 100 MD/požadavek. V případě, že bude požadována úprava s vyšší kapacitní náročností na straně Poskytovatele, bude změna realizována prostřednictvím rozvojového projektu.

2. Realizace rozvojového projektu

Jedná se o standardizovanou formu realizace nové funkcionality/aplikace, která má vliv na aplikační, technickou, nebo funkční architekturu dodávaného nebo podporovaného plnění nebo některého z návazných systémů. Realizace projektu bude probíhat prostřednictvím standardizované metodologie Zadavatele, která je specifikovaná v Příloze č. 3 Smlouvy, která je nedílnou součástí této Zadávací dokumentace jako její Příloha č. 1.

3. Jednorázové služby

Definované jednorázové služby Zadavatel nebude čerpat automaticky, jedná se o služby, které Zadavatel může v průběhu trvání Smlouvy u Poskytovatele poptávat, a to z jakýchkoliv důvodů na straně Zadavatele. Detailní specifikace jednorázových služeb je specifikovaná v Příloze č. 3 Smlouvy, která je nedílnou součástí této Zadávací dokumentace jako její Příloha č. 1

1. Služba JS01 Ukončení poskytování dílčí služby

Ří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í jedné konkrétní služby, nebo skupiny služeb, provedení předání konkrétní služby, nebo skupiny služeb Zadavateli nebo jím určenému subjektu a ukončení poskytování dílčí služby nebo skupiny služeb poskytovatelem služeb na základě této veřejné zakázky.

Zadavatel stanovuje, že cena za dílčí jednorázovou službu Ukončení poskytování dílčí služby nepřesáhne paušální cenu Služeb provozu za tři Vyhodnocovací období. Tedy v případě vznesení požadavku na realizaci jednorázové služby Ukončení poskytování dílčí služby bude fakturace po akceptaci této služby ve výši maximálně trojnásobku paušální ceny Služeb provozu.

Požadavky na scénář Ukončení poskytování dílčí služby jsou uvedeny v kapitole 5.3.1 této Přílohy č. 5 ZD a požadavky na provedení služby JS01 jsou uvedeny v Příloze č. 3 Smlouvy, která je nedílnou součástí této Zadávací dokumentace jako její Příloha č. 1.

2. Služba JS02 Ukončení poskytování Služeb

Řízené ukončení poskytování všech Služeb poskytovaných na základě Smlouvy, která je nedílnou součástí této Zadávací dokumentace jako její Příloha č. 1, se stanovuje za účelem zpracování a následného provedení koordinovaného a procesně vymezeného postupu při ukončení poskytování služeb, předání plnění a dat Zadavateli nebo jím určenému subjektu a ukončení smluvního vztahu s Poskytovatelem služeb.

Požadavky na scénář Ukončení poskytování Služeb jsou uvedeny v kapitole 5.3.2 této Přílohy č. 5 Zadávací dokumentace a požadavky na provedení služby JS01 jsou uvedeny v Příloze č. 3 Smlouvy, která je nedílnou součástí této Zadávací dokumentace jako její Příloha č. 1.

Zadavatel stanovuje, že cena za dílčí jednorázovou službu Ukončení poskytování Služeb nepřesáhne paušální cenu Služeb provozu za šest Vyhodnocovacích období. Tedy v případě vznesení požadavku na realizaci jednorázové služby Ukončení poskytování Služeb bude fakturace po akceptaci této služby ve výši maximálně šestinásobku paušální ceny Služeb provozu.

5. Požadavky na dokumentaci

   1. Projektová dokumentace

Zadavatel požaduje v rámci nabídky předložení minimálně následujících šablon projektové dokumentace:

• Nastavení projektu, projektová metodika

• Záznam/zápis z jednání projektových/realizačních týmů

• Záznam/zápis z jednání eskalační úrovně projektu – Projektový výbor

• Požadavek na poskytnutí součinnosti

• Akceptační protokol/dokument

Tato projektová dokumentace v návrhu dle dodavatele bude využita výhradně pro implementační projekt.

2. Analytická, architektonická, implementační dokumentace

Zadavatel dále stanovuje následující požadavky na řízení a zpracování implementační a další dokumentace. Tyto požadavky zahrne dodavatel ve své nabídce a zohlední v definici realizace navazujících služeb.

Vzhledem k tomu, že Zadavatel poptává řešení jako službu, dokumentace procesů na straně Dodavatele popisující jak jsou technologicky vyhodnocovány podmínky opatření na AP, bude obsahovat minimálně high-level pohled na vnitřní architekturu. Komunikační rozhraní SAMAS a jeho služby musí být dokumentovány velmi podrobně, a to jak pro vývoj, tak pro nevývojářské uživatele.

Oblast požadavku	Definice požadavku
Enterprise Architect	Architektonické a analytické modely budou modelovány nástrojem Sparx Systems Enterprise Architect. Licenci EA (minimálně corporate edici) si musí zajistit Poskytovatel.
Projektová dokumentace	V rámci dodávky plnění dle VZ bude vedena minimálně následující projektová dokumentace: Plány projektu a dokumentace jejich plnění v čase. Organizace projektového týmu a obsazení hlavních rolí jak na straně Zadavatele, tak Poskytovatele. Metodika vedení projektu včetně popisu řízení rizik a eskalačních mechanismů. Zápisy z jednání a projektových schůzek. Plány testů. Testovací případy. Testovací protokoly. Akceptační a předávací protokoly. Metriky a popis způsobu jejich měření. Výstupy měření a sledování metrik.
Dokumentace služeb	Poskytovatel dodá dokumentaci služeb minimálně v tomto rozsahu: Uživatelský manuál ve formátu Word a jeho interaktivní verze, která bude zveřejněna na Portálovém systému SZIF. Dokumentace popisuje, jakým způsobem je vyhodnocen zkoumaný jev/aktivita na AP tak, aby byl způsob vyhodnocení zřejmý pro odbornou veřejnost z oblasti DPZ.
Rozsah požadovaných dokumentů	Poskytovatelem bude v rámci plnění dodána dokumentace následujících typů: Projektová dokumentace. Analytická dokumentace. Dokumentace služeb. Integrační dokumentace/dokumentace rozhraní. Dokumentace chybových stavů. Testovací dokumentace. Bezpečnostní dokumentace v souladu s požadavky ZoKB, ISO/IEC 27000. Uživatelská dokumentace. Školicí dokumentace. Dokumentace zpracování osobních údajů, bude-li třeba.
Analytická dokumentace	Poskytovatel dodá analytickou dokumentaci, která bude rozdělena do několika dokumentů a bude obsahovat: Katalog požadavků HL (High Level) úroveň popisu v EA/UML, HL i detailní úroveň popisu v separátní příloze návrhu řešení. Definici pravidel a omezení pro import a export dat. Přehled číselníků (interních a sdílených). Přehled datových toků vyměňovaných s okolními systémy. Popis každého vystaveného rozhraní (WS) - popis bude mít charakter zadání pro vývoj (zejména definice povinných/nepovinných polí, datových typů, oborů hodnot / validačních schémat) - ideálně OpenAPI formát. Model rozhraní (UML). Model stavů (UML). Popis autentizace (všech požadovaných metod) a autorizace.
Testovací dokumentace	Poskytovatel předá v rámci implementace testovací scénáře a skripty pro jednotlivé druhy testů včetně postupu na přípravu nebo vyhledání testovacích dat. Testovací dokumentace bude průběžně aktualizována s ohledem na vývoj systému.
Bezpečnostní dokumentace	Poskytovatel dodá bezpečnostní dokumentaci prokazující splnění požadavků Zadavatele na bezpečnost v souladu s požadavky ISO 27 000 a ZoKB. Bezpečnostní dokumentace obsahuje metody, postupy a schémata, ze kterých je patrné, jak Systém spravovat z hlediska bezpečnosti a které jsou nezbytné pro bezpečný provoz Systému. Součástí dokumentace jsou zejména: Popis hlavních komponent a funkcí, které poskytují zabezpečení včetně vazeb na jiné služby či jiné aplikační komponenty zajišťující bezpečnost systému. Popis způsobu zajištění vysoké dostupnosti a zotavení systému po poruše. Definici periodických činností jako jsou sledování vydávání bezpečnostních a funkčních updatů a opravných balíčků výrobci použitých technologií a software a implementace upgradů a opravných balíčků, penetrační testy, analýza rizik, sledování a vyhodnocování provozu a procedury reakce na incidenty a nežádoucí stavy. Popis a metody nakládání s bezpečnostními a provozními logy (vyhodnocování, skartační lhůty, způsob uchovávání) a způsob a doba jejich archivace. Popis procesů řešení bezpečnostních incidentů, resp. popis procesu hlášení a obsluhy bezpečnostních incidentů ve vazbě na stávající procesy Zadavatele. Správa certifikátů a nakládání s nimi.
Scénáře ukončení služeb	Poskytovatel zpracuje komplexní scénáře realizace jednorázových služeb (viz Příloha č. 3 Smlouvy): JS01 – Ukončení poskytování dílčí služby – ukončení poskytování cloudových infrastrukturních služeb (všech cloudových infrastrukturních služeb), tj. postup ukončení řešení tak, aby mohlo být provozováno u jiného provozovatele cloudových infrastrukturních služeb, případně ukončení pouze některé dílčí služby. JS02 – Ukončení poskytování Služeb, tj. postup ukončení poskytování kompletního řešení služby SAMAS a předání veškeré aktualizované dokumentace a zpracovávaných dat Zadavateli nebo jinému provozovateli. Scénáře na ukončení jednotlivých dílčích služeb odlišné od scénářů JS01 a JS02 jsou zpracovávány na výzvu Zadavatele.

Tabulka 1 Požadavky na dokumentaci

Dokumentace bude v průběhu plnění VZ udržována Poskytovatelem aktuální.

Dokumentace s výjimkou dokumentace vedené v nástroji Enterprise Architect bude předávána, rozvíjena a udržována v platformě Microsoft Teams (Sharepoint) Zadavatele, kde Zadavatel pro tento projekt založí Team, kanály a projektovou strukturu včetně složek pro ukládání a výměnu dokumentů.

Dohodnuté formáty:

1. Textové dokumenty – formáty MS Office, v Zadavatelem editovatelné formě. Důležité dokumenty budou předány jak ve formátu MS OFFICE, tak v .PDF/A, za účelem zachycení předávaného stavu bez možnosti obsah dokumentu změnit.

2. Obrázky – jpg, png, tiff, vsdx.

3. Projektové řízení – mpp, xlsx.

4. Zadavatel používá Sparx Systems Enterprise Architect, proto požaduje vedení architektonické a analytické dokumentace v tomto nástroji. Poskytovatel popíše pouze relevantní část architektury odpovídající rozsahu jeho plnění.

3. Scénáře ukončení služeb

Poskytovatel zpracuje komplexní scénáře realizace jednorázových služeb JS01 a JS02 (viz Příloha č. 3 Smlouvy):

• JS01 – Ukončení poskytování dílčí služby – ukončení poskytování cloudových infrastrukturních služeb (všech cloudových infrastrukturních služeb), tj. postup ukončení řešení tak, aby mohlo být provozováno u jiného provozovatele cloudových infrastrukturních služeb, případně ukončení pouze některé dílčí služby.

• JS02 – Ukončení poskytování Služeb, tj. postup ukončení poskytování kompletního řešení služby SAMAS a předání veškeré aktualizované dokumentace a zpracovávaných dat Zadavateli nebo jinému provozovateli.

Tyto scénáře mohou být ověřovány na výzvu Zadavatele nebo v rámci auditu informačního systému realizovaného nezávislým auditorem.

1. Scénář služby JS01 Ukončení poskytování dílčí služby

Scénář Ukončení poskytování dílčí služby – ukončení poskytování cloudových infrastrukturních služeb (všech cloudových infrastrukturních služeb) (dále v této kapitole „Scénář“), bude obsahovat postup a harmonogram ukončení poskytování cloudových infrastrukturních služeb a postup a harmonogram migrace služby SAMAS k jinému poskytovateli cloudových infrastrukturních služeb. Přesné vymezení subjektu, ke kterému bude služba SAMAS migrována, stanoví Zadavatel před zahájením realizace scénáře dle této služby a v rámci této realizace bude Scénář aktualizován dle konkrétních informací o prostředí a možnostech nového poskytovatele cloudových infrastrukturních služeb.

Scénář musí být navržen a dokumentován tak, aby pokrýval veškeré kroky potřebné pro ukončení provozu služby SAMAS v prostředí stávajícího poskytovatele cloudových infrastrukturních služeb a migraci a zprovoznění služby SAMAS do prostředí Zadavatele či nového poskytovatele cloudových infrastrukturních služeb při zachování poskytování služby SAMAS v souladu s parametry stanovenými Smlouvou.

Scénář bude vytvořen tak, aby veškerá data a informace vzniklé v průběhu poskytování služby SAMAS dle této Smlouvy jejichž předání bude předmětem této jednorázové služby, byla předána, je-li to možné a účelné, v elektronické podobě a strukturovaná tak, jak byla ukládána při provozu, podpoře a rozvoji služby SAMAS.

Scénář bude zejména obsahovat:

• Seznam služeb, jejichž poskytování bude ukončováno,

• seznam všech komponent/částí IT řešení včetně dat služby SAMAS, které budou přenášeny do prostředí jiného poskytovatele cloudových infrastrukturních služeb,

• seznam architektonické, projektové, bezpečnostní a další dokumentace vztahující se k ukončovaným službám i ukončením těchto služeb dotčeným komponentám/aktivitám/službám provozu služby SAMAS,

• seznam typů záznamů, které je třeba v rámci Ukončení dílčí služby předat Zadavateli (reporty, provozní deníky, auditní záznamy, znalostní báze, vytvořené v průběhu poskytování služeb) tak, aby po Ukončení poskytování dílčí služby bylo zajištěno, že Zadavatel disponuje kompletními a správnými informacemi a know-how pro zajištění dílčí služby v prostředí jiného poskytovatele cloudových infrastrukturních služeb.

Součástí Scénáře 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 Objednateli/novému poskytovateli a zprovoznění služby SAMAS ve změněném prostředí,

• návrh postupu zprovoznění služby SAMAS v prostředí nového poskytovatele cloudových infrastrukturních služeb,

• seznam testovacích scénářů a akceptačních protokolů, na jejichž základě bude Zadavatel ověřovat úplnost a správnou funkčnost služby SAMAS po realizaci ukončení poskytování dílčí služby a její náhrady službou jiného poskytovatele,

• informace pro nového poskytovatele za účelem detailního seznámení s požadavky na poskytování nové služby nahrazující ukončenou dílčí službu,

• 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í se bude jednat o hrubý odhad kapacit a dob trvání aktivit a o zřetelné vyznačení těchto aktivit ve scénáři).

V případě potřeby vytvoření scénáře ukončení jen jedné nebo několika dílčích služeb, bude scénář vytvořen pro konkrétní zadání Objednatele a na jeho výzvu. Pro jeho vytvoření a/nebo případnou realizaci bude uplatněn postup dle kap. 4.2.2 Realizace rozvojového projektu uvedené v této Příloze č. 5 ZD za uplatnění podmínek definovaných v katalogovém listu služby JS01 uvedeném v Příloze č. 3 Smlouvy.

2. Scénář služby JS02 Ukončení poskytování Služeb

Scénář Ukončení poskytování Služeb (dále v této kapitole „Scénář“), bude obsahovat postup a harmonogram ukončení poskytování služby SAMAS a předání aktualizované dokumentace a veškerých dat Zadavateli nebo jím určenému poskytovateli. Přesné vymezení subjektu, ke kterému budou podklady služby SAMAS předávány, stanoví Zadavatel před zahájením této služby a v rámci jejího provedení bude Scénář aktualizován dle konkrétních informací o cílovém prostředí a možnostech nového poskytovatele.

Scénář musí být navržen a dokumentován tak, aby pokrýval veškeré kroky potřebné pro ukončení provozu služby SAMAS, předání veškeré dokumentace a dat, aby bylo možné veškeré informace, dokumentaci a data potřebné pro zprovoznění služby SAMAS předat novému poskytovateli a ten mohl službu SAMAS provozovat v prostředí Zadavatele či nového poskytovatele při zachování poskytování služby SAMAS v souladu s parametry stanovenými Smlouvou.

Scénář bude vytvořen tak, aby veškerá data a informace vzniklé v průběhu poskytování Služby SAMAS dle této Smlouvy, jejichž předání bude předmětem této jednorázové služby, byla předána, je-li to možné a účelné, v podobě, v jaké byla vytvářena a ukládána při provozu, podpoře a rozvoji SAMAS (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).

Celková doba realizace Scénáře: Maximálně 60 kalendářních dní od Xxxxxxxx realizace Scénáře.

Scénář Ukončení poskytování Služeb bude obsahovat zejména:

• Seznam služeb, jejichž poskytování bude ukončováno,

• seznam všech komponent/částí IT řešení včetně dat služby SAMAS,

• seznam architektonické, projektové, organizační, bezpečnostní a další dokumentace vztahující se ke službě SAMAS a jejímu poskytování,

• seznam typů záznamů, které je třeba v rámci Ukončení Služeb předat Zadavateli (reporty, provozní deníky, auditní záznamy, znalostní báze, vytvořené v průběhu poskytování služeb) tak, aby po ukončení poskytování Služeb bylo zajištěno, že Zadavatel/nový poskytovatel disponuje kompletními a správnými informacemi a know-how pro zajištění poskytování služby SAMAS.

Součástí Scénáře 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žby SAMAS novému poskytovateli a zprovoznění služby SAMAS ve změněném prostředí,

• návrh postupu zprovoznění služby SAMAS v prostředí nového poskytovatele cloudových infrastrukturních služeb,

• seznam testovacích scénářů a akceptačních protokolů, na jejichž základě bude Zadavatel ověřovat úplnost a správnou funkčnost služby SAMAS po realizaci Ukončení poskytování služby provozu a rozvoje a jejím zajištění jiným provozovatelem,

• informace pro nového poskytovatele a potřebné zaškolení pracovníků nového poskytovatele za účelem detailního seznámení s provozem služby SAMAS a její dokumentací,

• odhad kapacit a dob potřebných pro provedení jednotlivých aktivit Scénáře 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í se bude jednat alespoň o hrubé odhady kapacit a dob trvání aktivit a o zřetelné vyznačení těchto aktivit ve scénáři).

6. Specifikace plnění

   1. Splnění minimálních požadavků

Poskytovatel je povinen zajistit, aby poskytovaná služba po celou dobu poskytování vždy bezvýhradně splňovala minimální požadavky uvedené ve Smlouvě, která je Přílohou č. 1 této ZD a v její Příloze č. 1 „Závazné implementační, funkční a technické požadavky“.

2. Základní pojmy a kontext požadovaných služeb

   1. Role SAMAS v procesu administrace žádosti

Výsledek vyhodnocení plnění dotačních podmínek poskytovaný službami SAMAS je v procesu administrace žádosti důkazním prostředkem, který slouží k prokázání plnění/neplnění podmínky pro výplatu na základě daného dotačního opatření/podmínky.

Služba SAMAS poskytuje jako výstup pro jednotlivé monitorované podmínky hodnoty stavů:

• splněno,

• nesplněno,

• nerozhodnuto.

Primárním cílem služby SAMAS je kontrolovat, automaticky, co největší plochu (počet AP), na kterou jsou žádány dotace nad daty Sentinel-1 a Sentinel-2, případně dalšími.

2. Předpokládaná architektura celkového řešení XXXX

Níže uvedený obrázek zachycuje hrubý pohled na to, jak má celkové řešení XXXX pracovat. Část orámovaná červeným rámečkem je předmětem plnění dle této VZ SAMAS.

Z obrázku je patrné, že všechny procesy sdílejí data uložená v DB XXXX.

Ve fázi kontroly plnění podmínek dotačních programů běží několik cyklických procesů současně a jsou propojeny společnou databází „DB XXXX“, ve které jsou uloženy údaje o jednotlivých podmínkách monitorovaných opatření a jejich vazbách na žádosti a na pozemky, ke kterým se vztahují. Databáze udržuje aktuální stav vyhodnocení plnění těchto podmínek včetně výsledků všech provedených kontrol, které se k parcele nebo podmínce vážou, a drží také historii změn.

„Načtení žádostí ke kontrole“- načítá údaje žádostí z IS SAP a LPIS. Do požadovaných stavů budou procesem Načtení a aplikace výjimek promítnuty i žadatelům poskytnuté výjimky.

Kontrolu pomocí satelitního monitoringu zajišťuje externí služba SAMAS. Pro tuto službu IS XXXX poskytuje zadání (co má kontrolovat) a přebírá do dalšího zpracování její výstupy. Toto zajišťuje proces „Komunikace se SAMAS“. Tento proces aktualizuje stav plnění monitorovaných podmínek po každém příjmu nových dat ze satelitu a také po každé změně sledovaných podmínek v důsledku změny žádosti nebo podání žádosti nové, či jejího zpětvzetí/storna aktualizuje službě SAMAS podmínky, které mají být sledovány.

Blok „Kontrolní aktivity“ v sobě skrývá všechny další kontrolní aktivity, s výjimkou satelitního monitoringu. Ty zahrnují jak zpracování výstupů monitoringu, tak kontroly, které zpřesňují, doplňují nebo kontrolují výstupy satelitního monitoringu a další kontrolní aktivity včetně jejich plánování (kontrolu pomocí ortofota, Follow-up aktivity, kontroly v terénu – PN, KNM, KNP - a kontrolu s použitím geotagovaných fotografií). Část těchto aktivit je sice v IS XXXX naplánována, ale další zpracování se uskutečňuje v IS SAP (KNM, KNP) nebo také s podporou mobilní aplikace GT FOTO, kterou budou používat inspektoři Zadavatele v terénu.

Služba SAMAS poskytuje i jiné výstupy než stavy monitorovaných podmínek – např. mapové služby nad daty Sentinel nebo specializované mapové podklady.

Obrázek 2 Základní pohled na celkové řešení XXXX

Jsou-li v IS XXXX vyhodnoceny všechny podmínky daného opatření vázané na danou AP, kterými je podmíněn nárok na danou dotaci, je jejich zpracování v tomto procesu ukončeno a proces přechází do zpracování stávajícími procesy – Softwarovou kontrolou II - „SWK II“ a na něj navazujícím procesem „Výplata“, jejichž podpora je realizována stávajícím IS SAP.

V průběhu zpracování je třeba průběžně komunikovat s žadatelem. Tuto funkčnost zajišťuje proces „Komunikace se žadatelem“, který má přístup k aktuálním údajům, které chce Zadavatel se žadatelem sdílet. Tento modul bude integrován s novým Portálovým systémem SZIF, které díky responzivnímu designu umožní přístup i z mobilních zařízení.

Pro splnění požadavku kontinuální komunikace se žadatelem je třeba mít neustále aktuální údaje a umět je žadateli poskytnout, případně jej upozornit, že se mu blíží termín splnění nějakého úkolu, nebo podmínky dotace, a Zadavatel ji splněnou nevidí. Přitom je třeba reagovat na to, jak se žadatel zachová. Jestli doloží plnění geotagovanou fotografií nebo změní žádost, případně neudělá nic.

K tomu, aby se s dostupnými údaji dobře pracovalo, je vhodná vizualizace výsledků nad mapovými podklady.  Pro komunikaci se žadatelem i poskytnutí přehledové informace pracovníkovi Zadavatele je použit tzv. scoreboard, který přehledně informuje o stavu plnění podmínek opatření a úkolů.

Obrázek obsahuje i dva bloky, které zachycují podpůrné procesy. „Načtení a aplikace výjimek“, které zpřístupňují výjimky načtené z registru OOP, který je součástí LPIS, ostatním procesům a výjimky na základě ohlášení vyšší moci, načítané z registru OVM, které jsou realizovány v IS SAP.

Dále obsahuje externí službu Správa GT FOTO „Správa geotagovaných fotografií“, zajišťující pořizování, ukládání a správu geotagovaných fotografií, které jsou v rámci Kontrolních aktivit pořizovány a používány.

Pro pořizování geotagovaných fotografií a práci s úkoly bude vytvořena specializovaná mobilní aplikace, která bude sloužit k pořizování geotagovaných fotografií i k přenosu informací mezi Zadavatelem a žadatelem nebo komunikaci s terénními inspektory Xxxxxxxxxx.

Pohled na architekturu informačního systému, do kterého bude řešení dle této VZ integrováno, zachycuje následující obrázek.

Jak je patrné z obrázku níže, projekt IS XXXX dodává integrační platformu a logiku celého systému, zatímco uživatelské rozhraní je tvořeno Portálovými aplikacemi XXXX, webovými aplikacemi služby GT FOTO a také mobilní aplikací poskytovanou službou GT FOTO. Portálové aplikace XXXX budou dodávány v rámci VZ na zajištění služeb Portálového systému SZIF. Mobilní aplikace a práce s fotografiemi a mobilními zařízeními bude dodávána v rámci VZ GT FOTO a služby zpracování satelitních snímků bude dodávat projekt SAMAS. Celé řešení je třeba integrovat se stávajícím IS Zadavatele a informačními systémy pracujícími na MZe. V průběhu řešení budou muset všichni poskytovatelé jednotlivých nově vytvářených částí cílového řešení XXXX velice úzce spolupracovat, jejich práce poběží současně.

Obrázek 3 Architektura cílového systému XXXX

3. SAMAS

   1. Popis funkčnosti

Jedná se o externí službu provozovanou mimo systém IS XXXX, která zajišťuje plošný monitoring vybraných zemědělských aktivit a stavů pomocí automatizovaných algoritmů nad daty Sentinel-1 a Sentinel-2, případně dalších. Tato služba přijímá data a povely z IS XXXX a vrací požadované výstupy. Zpracování výstupů ze SAMAS i řízení této služby provádí IS XXXX.

Součástí služby je zpracování snímků a vytěžení požadovaných informací pomocí algoritmů klasifikace a detekce aktivity nebo stavu pomocí definovaných markerů. IS XXXX předává do SAMAS data pro sledování ze systému XXXX automatizovaně pomocí rozhraní. Výsledky zasílá služba SAMAS ukládá do systému XXXX také pomocí rozhraní.

Dodavatel bude dále poskytovat mapovou službu pro zobrazení série snímků Sentinel-2. V případě, že budou využity i další datové zdroje (např. v rámci expertní analýzy další optická družicová data), které budou použity pro účely SAMAS, i ty se stanou předmětem služby a musí být v rámci vyhodnocení podmínek reportovány do IS XXXX.

Výsledky musí být konzistentní pro všechny AP, proto jednotlivé kroky vyhodnocení budou na sebe navazovat tak, že výsledky jednoho kroku se uplatní jako vstup do jiného. Určité algoritmy nejsou spouštěny pro množiny AP jen dle deklarace, ale dle výsledků předcházejících algoritmů. Tato posloupnost je zde naznačena formou schématu.

Obrázek 4 Závislost vyhodnocovacích algoritmů

2. Předpokládaná základní architektura systému a požadované funkce

Níže definované služby budou fungovat následujícím způsobem:

Do IS Zadavatele přicházejí GSAA (jednotné žádosti) z Předtiskové aplikace MZe. V rámci IS Zadavatele se stará o přípravu podkladů, zpracování informací z jednotných žádostí pro SAMAS a vyhodnocení výsledků ze SAMAS systém IS XXXX.

Jak budou přicházet žádosti do IS Zadavatele, tak jsou z žádostí službami IS XXXX extrahovány informace potřebné pro vyhodnocení na straně SAMAS (jedná se primárně o jednoznačný identifikátor AP, geometrii (polygon) a dotační opatření/podmínky, které je potřeba vyhodnotit – opatření má vazbu na číselník opatření, který obsahuje i podmínky, hlavně datum, do kdy má být opatření splněno – tedy vyhodnocována podmínka). Tyto informace jsou předávány přes Integrační platformu XXXX na rozhraní SAMAS.

Do SAMAS mohou vstoupit i jiné polygony, než AP a to sice tzv. ECP (environmentálně cenné plochy). ECP plochy nevstupují do SAMAS jako plocha pro vyhodnocení, ale jako pomocná vrstva.

Jedná se o plochy, které se nachází / jsou:

· v oblasti Natura 2000

· v 1. zóně CHKO a NP

· národní přírodní památka, národní přírodní rezervace, přírodní rezervace a přírodní památka

· ve vzdálenosti do 12 m od vodního útvaru

· silně erozně ohrožené

· podmáčené a rašelinné louky

· v III. aplikačním pásmu nitrátově zranitelných oblastí

Veškeré ECP, případně plochy krajinných prvků plochy budou předávány do SAMAS.

Při zahájení provozu systému budou do SAMAS nahrány hromadně všechny dostupné AP pro daný rok, kde je podaná žádost (resp. byla podána žádost v přechozím roce – s ohledem na harmonogram projektu), dále už nebudou posílány AP dávkově, ale po jednotlivých změnách. Jak budou podávány žádosti, budou na SAMAS odesílány informace o sledovaných podmínkách a případných změnách AP.

SAMAS určí proveditelnost vyhodnocení AP podle velikosti a tvaru AP, zda je AP pokryta dostatečným počtem pixelů dat Sentinel pro vyhodnocení. Pokud není možné využít dat Sentinel pro vyhodnocení AP, vrátí SAMAS zpět do IS XXXX příznak nemonitorovatelnosti dané AP.

SAMAS provede ověření AP podle dotačního opatření/podmínek, které mají být na dané AP plněny, a na základě stanovených funkcí vrací v nejkratší možné době výsledky. Toto ověření probíhá pokaždé, když jsou získána nová data Sentinel tak, aby byl průběžně vidět nový stav. AP s atributy jsou uložené v DB XXXX a zároveň u Poskytovatele služeb SAMAS. V případě změny (geometrie nebo dotačního opatření) nebo výmazu AP v DB XXXX systém IS XXXX pošle změnu do SAMAS a ten, na základě analýzy obdržené změny, vrací nové vyhodnocení podmínek. Pokud došlo ke změně, pošle služba SAMAS výsledek do IS XXXX včetně času ověření.

Pokud došlo ke změně opatření sledovaného na daném AP – změní se i způsob kontroly na straně SAMAS – je potřeba zpětně vyhodnotit vývoj na AP, je-li to třeba i pohledem do historie v daném roce (např. pro dotační opatření SAPS a kontrolu sečí), kdy změna mohla přijít např. v červnu, ale seč už mohla proběhnout dříve. IS XXXX považuje poslední obdržený stav za aktuální. SAMAS posílá výsledky na základě definovaných lhůt pro provádění kontrol konkrétních opatření/podmínek. SAMAS musí změnu vyhodnotit podle posledních dat, která má k dispozici.

Parametry jako např. hraniční hodnoty algoritmů, které rozhodují o splnění, či nesplnění vyhodnocované podmínky nesmí být hardkodované a musí být možno ve spolupráci Dodavatele SAMAS a Zadavatele tyto parametry upravovat.

V případě, že je na AP objevena nehomogenita – ve smyslu např. je deklarován trvalý travní porost na celé ploše AP a na polovině této AP SAMAS objeví např. rozoranou půdu, SAMAS vrátí do IS XXXX mimo standardních výstupů vázaných na danou AP polygon(y) nehomogenity, včetně odhadu, o jakou se jedná kulturu/plodinu. IS XXXX polygony uloží tak, aby je bylo možno následně publikovat mapovou službou, která bude poskytnuta okolním systémům pro snadnější úpravu deklarované plochy – provedení změny tvaru AP. Polygony nehomogenit musí mít jednoznačnou identifikaci, ke které původně deklarované AP náleží.

Rozhraní SAMAS musí počítat s výraznou zátěží hlavně ke konci období pro podání jednotné žádosti, (květen) a naopak jen velmi malou aktivitou během období, kdy dochází k vyhodnocování malého množství opatření – typicky v zimním období. Data do SAMAS budou rozhraním zasílána opakovaně, v důsledku aktualizace dat v IS XXXX na základě podaných nových nebo změnových žádostí. Rozhraním služeb SAMAS budou předávána jak atributová, tak prostorová data (geometrie jednotlivých AP). Zároveň budou přes rozhraní směrem do IS XXXX předávána data pro vykreslení hodnot, které byly použity při rozhodování, do grafu (vývoj sledované hodnoty/markeru v čase). Výsledky budou rozhraním zasílány opakovaně – při dalším průletu a následném vyhodnocení dat ze satelitů Sentinel.

Poskytovatel je povinen ke všem funkcím uchovávat podklady pro výpočty, a to hlavně nastavení, případně zdrojové kódy pipeline, které zpracovaly v daném čase požadovaný výpočet nad AP tak, aby byl schopen doložit a replikovat provedené výpočty zpětně po dobu tří let v případě, že dojde k napadení výsledku kontroly ze strany Žadatele. Pipeline je myšleno jako sled kroků, které provedly vyhodnocení.

Poskytovatel se zavazuje k předání detailní dokumentace toho, jak budou jednotlivé služby SAMAS data vyhodnocovat tak, aby byla tato dokumentace použitelná v případě sporů, kdy se uživatel odvolá proti vyhodnocení ze služby SAMAS.

SAMAS poskytuje pro IS XXXX mapové služby nad daty Sentinel-2 a to (NDVI index, pravé a nepravé barvy) takovým způsobem, aby bylo možné v klientovi (v mapovém okně) implementovat prohlížení snímků v čase. Poskytovaná služba musí splňovat OGC standardy (WMS TIME). Mapová služba bude poskytovat data Sentinel 2 roky zpětně.

SAMAS poskytuje pro IS XXXX také službu tzv. „expertní vyhodnocení“, kdy může pracovník Zadavatele (vybrané role) požádat prostřednictvím IS XXXX o posouzení a doplnění informací ke konkrétnímu AP. Expertní vyhodnocení proběhne tak, že ze strany SAMAS do procesu „expertního vyhodnocení“ vstoupí kvalifikovaná osoba, která může pro vyhodnocení využít i jiné interpretace dat Sentinel nad rámec běžně využívaných algoritmů nebo jiné zdroje než Sentinel dle svého uvážení. Žádost o „expertní vyhodnocení“ bude zaslána z IS XXXX přes rozhraní SAMAS, navíc bude obsahovat příznak „expertního vyhodnocení“, případně doplňující komentář. Výsledek expertního vyhodnocení může obsahovat soubory, které popisují proces expertního vyhodnocení a použité poklady, včetně mapových a je potřeba počítat s přenosem souborů typu MS Office, JSON, CSV, PDF, PNG, TIFF apod. směrem ze SAMAS do IS XXXX.

Poskytovatel je povinen každý rok převzít výsledky z hodnocení kvality poskytovaných služeb zajištěné Zadavatelem a průběžně přejímat informace Zadavatele o zpětné vazbě k výsledkům vyhodnocení podmínek a na základě těchto informací optimalizovat nastavení algoritmů pro vyhodnocení podmínek. Množství monitorovaných zemědělských aktivit se může rozšiřovat v závislosti na zadání Zadavatele. Množina monitorovaných podmínek bude každý rok stanovena Zadavatelem.

Obrázek 5 Procesy a služby SAMAS

3. Požadavky na funkcionalitu služby SAMAS

   1. Řešení pro analýzu a zpracování satelitních dat

      1. Analýza velikosti a tvaru AP

Předmětem analýzy je zjištění, zda je AP pokryta dostatečným počtem pixelů družic Sentinel-1 a Sentinel-2, aby jí bylo možné vyhodnotit v rámci jednotlivých služeb (funkce 6.3.3.1.2–6.3.3.1.6).

Bude se spouštět pro každou novou AP nebo pro AP, kde dojde ke změně geometrie nebo vyhodnocované podmínky.

Pokud není možné z důvodu tvaru nebo velikosti AP (AP má malou plochu nebo je sice velká plochou, ale je to třeba úzký pás) využít data Sentinel pro vyhodnocení podmínek na AP, služba vrátí přes rozhraní zpět do IS XXXX informaci o tom, že AP a konkrétní podmínka(y) na ní kontrolovaná(né) je/jsou nemonitorovatelná(né), IS XXXX už nadále nebude posílat požadavky na vyhodnocení takových AP a konkrétních podmínek.

AP, na kterých je vyhodnocována táž podmínka a mají tvar nebo velikost nevhodnou pro využití dat Sentinel, lze pro účely vyhodnocení podmínky slučovat – vznikne tak větší plocha, která může být vhodná pro vyhodnocení nad daty Sentinel. V případě, že dochází k vyhodnocení podmínky na sloučených AP, nesmí na sloučené AP být nehomogenity nebo skutečnosti, které by negativně ovlivnily výsledek na vyhodnocované AP. V případě, že byla pro vyhodnocení využita AP vzniklá sloučením, výsledek je zpátky do IS XXXX poslán pro původní nesloučené identifikátory AP.

V případě, že velikost a tvar AP umožňují využití dat Sentinel pro vyhodnocení dané podmínky na daném AP, pokračuje se zpracováním na straně SAMAS.

Vstupy:

• Data AP, případně dalších polygonů (aktuálně jen plocha průniku AP a ECP plochy) pro vyhodnocení (geometrie, atributy, sledovaná opatření + podmínky) z IS XXXX.

Výstupy:

• Identifikátor AP s jednotlivými podmínkami, které nelze monitorovat. Příznak nemonitorovatelnosti se uloží v IS XXXX jako atribut AP. Příznak, že bylo při vyhodnocení užito spojení AP.

2. Ověření kultury a plodiny

Průběžné zpracování a vyhodnocování satelitních dat Sentinel-1 a Sentinel-2. Ověření deklarované kultury, případně hlavní plodiny na orné půdě. V rámci zpracování bude provedena detekce nehomogenních AP dle stanovených hraničních hodnot. Pro takové AP bude uplatněn postup automatické detekce hranic, který povede k vytvoření ploch nehomogenit a ověření deklarované kultury bude provedeno pro tyto nově vzniklé plochy. Efektivní postupy automatizované, poloautomatizované a expertní analýzy navrhne Poskytovatel. Případné rozpoznané nehomogenity budou v informačním systému XXXX ukládány do nové vektorové vrstvy jako pomocné zákresy nových AP.

V případě určení kultury je potřeba mimo zemědělsky obhospodařované plochy určit i plochy, které nejsou zemědělsky obhospodařované (zpevněné povrchy, zarostlé pozemky s nálety atp.).

Služba bude poskytovat výsledky v období určeném parametry dané vyhodnocované podmínky. Výsledek je předáván ve formě Identifikátoru AP s kódem identifikované plodiny, respektive kultury a s hodnotami pravděpodobnosti určenými na základě klasifikace. Pokud u podmínky na rozpoznání plodiny nelze jednoznačně určit plodinu, předávají se kódy první a druhé nejpravděpodobněji identifikované plodiny s hodnotami pravděpodobnosti (v tomto případě spadá vyhodnocení do kategorie nerozhodnutých podle SLA parametrů).

Pokud vznikly při vyhodnocení plochy nehomogenity, vrací SAMAS plochy nehomogenit s identifikátorem nehomogenity, vazbou na identifikátor AP a kódem první a druhé nejpravděpodobněji identifikované plodiny, respektive kultury a s hodnotami pravděpodobnosti určenými na základě klasifikace.

Vstupy:

• Data AP pro vyhodnocení (geometrie, atributy, sledovaná opatření + podmínky) z IS XXXX

• Data Sentinel (Poskytovatel)

Výstupy:

• Identifikátor AP, případně polygony nehomogenit s kódem identifikované plodiny, respektive kultury a s hodnotami pravděpodobnosti určenými na základě klasifikace. Pokud u podmínky na rozpoznání plodiny nelze jednoznačně určit plodinu, předávají se kódy první a druhé nejpravděpodobněji identifikované plodiny s hodnotami pravděpodobnosti. V případě polygonů nehomogenit musí být jasná vazba na identifikátor AP, ke kterému nehomogenita patří.

3. Monitoring sečí a pastvy

Průběžné zpracování a vyhodnocování satelitních dat Sentinel-1 a Sentinel-2 vzhledem k relevantním AP a detekce provedení sečí a pastvy. Detekce sečí a pastvy je prováděna na AP, na kterých byl deklarován nebo algoritmem pro ověření kultury a plodiny detekován travní porost. Neomezuje se tedy jen na AP, kde byl travní porost deklarován.

Služba bude poskytovat výsledky po každém přeletu satelitu přes území ČR v období od poloviny dubna do poloviny listopadu daného kalendářního roku.

Výsledek je předáván ve formě datumů od kdy do kdy došlo k posečení/spasení a s jakou spolehlivostí byla seč/pastva určena. Dále je předávána informace o tom, jakou metodou – např. optika/radar bylo vyhodnocení provedeno. V závislosti na metodě vyhodnocení budou předávána relevantní data, která byla pro vyhodnocení využita – např. hodnoty NDVI indexu, koherence atp. tak, aby na straně IS XXXX mohlo dojít k vykreslení těchto hodnot do grafu a srozumitelné prezentaci.

Během roku může na monitorované AP docházet k opakovanému sečení/pasení a je potřeba postihnout všechny seče/pastvy na AP během sledovaného období.

V případě sečí/pastvy může docházet k částečnému sečení/pastvě, kdy je posekána část AP v jednom období a v jiném období zbylá část. V případě, že SAMAS narazí na takovou situaci, vygeneruje nehomogenity podle posečených a neposečených částí AP a přidá příznak, že se jedná o částečnou seč/pastvu na AP a s jakou pravděpodobností byla zjištěna. Stejně tak v případě posečení zbylé části AP. IS XXXX na základě sloučení ploch nehomogenit vyhodnotí, zda byl pozemek posekán celý do požadovaného termínu.

Vstupy:

• Data AP pro vyhodnocení (geometrie, atributy, sledovaná opatření + podmínky) z IS XXXX

• Data Sentinel (Poskytovatel)

Výstupy:

• Identifikátor AP s daty od kdy do kdy došlo k potenciálnímu posečení/pastvě a s jakou spolehlivostí byla seč/pastva určena a metoda – např. optika/radar, kterou bylo vyhodnocení provedeno. V závislosti na metodě vyhodnocení budou výstupem relevantní data, která byla pro vyhodnocení využita – např. hodnoty NDVI indexu, koherence atp. Případně příznak částečné seče.

4. Monitoring sklizně hlavní plodiny

Průběžné zpracování a vyhodnocování satelitních dat Sentinel-1 a Sentinel-2 vzhledem k relevantním AP. Detekce sklizně je prováděna na AP, na kterých jsou deklarovány vybrané typy EFA prvků (monitorované EFA prvky viz funkce Monitoring EFA prvků). Detekovaný týden sklizně hlavní plodiny je jedním z významných markerů pro algoritmus monitoringu EFA prvků.

Služba bude poskytovat výsledky po každém přeletu satelitu přes území ČR v období, které bude specifikováno číselníkem Zadavatele.

Výsledek je předáván ve formě identifikátoru AP s daty od - do, kdy byla detekována sklizeň hlavní plodiny a pravděpodobnost s jakou jí automatický algoritmus určil.

Dále je předávána informace o tom, jakou metodou – např. optika/radar bylo vyhodnocení provedeno. V závislosti na metodě vyhodnocení budou předávána relevantní data, která byla pro vyhodnocení využita – např. hodnoty NDVI indexu, koherence atp. tak, aby na straně IS XXXX mohlo dojít k vykreslení těchto hodnot do grafu a srozumitelné prezentaci.

Vstupy:

• Data AP pro vyhodnocení (geometrie, atributy, sledovaná opatření + podmínky) z IS XXXX

• Data Sentinel (Poskytovatel)

Výstupy:

• Identifikátor AP, s daty od kdy do kdy došlo ke sklizni hlavní plodiny a s jakou spolehlivostí byla sklizeň určena a metoda – např. optika/radar, kterou bylo vyhodnocení provedeno. V závislosti na metodě vyhodnocení budou výstupem relevantní data, která byla pro vyhodnocení využita – např. hodnoty NDVI indexu, koherence atp. Případně příznak částečné sklizně.

5. Monitoring EFA prvků

Zpracování a vyhodnocování časové řady satelitních dat Sentinel-1 a Sentinel-2 vzhledem k relevantním AP ze žádostí a detekce určitých zemědělských aktivit na těchto plochách. Pro jednotlivé typy EFA prvků budou definovány sady markerů, na základě kterých bude rozhodnuto o způsobilosti a nezpůsobilosti daného EFA prvku. Markery budou vypovídat o růstu vegetace ve sledovaném období, o existenci meziplodiny (typ plodiny), o změnách svědčících o odstranění vegetace a o sklizni hlavní plodiny – souvisí s funkcí pro monitoring sklizně hlavní plodiny. Specifikace markerů bude předmětem implementační analýzy a Zadavatel očekává, že vhodné markery Poskytovatel navrhne. Limitní hodnoty markerů, které ovlivňují výsledek vyhodnocení, bude možné konfiguračně měnit na straně služby SAMAS po dohodě mezi Zadavatelem a Poskytovatelem.

Vyhodnocované EFA prvky budou následující:

• Úhor – existence úhoru

• PVN (plodiny vázající dusík) – typ plodiny

• Meziplodina (letní i zimní) – existence meziplodiny

Služba bude poskytovat výsledky pravidelně v období, které definuje číselník opatření/podmínek. Může docházet k případům, kdy není možné po prvních přeletech satelitů na začátku monitorovaného období podmínky určit, zda se např. jedná o úhor, ale po dalších průletech bude možné tuto informaci získat.

Výsledek je předáván ve formě identifikátoru AP a podmínky s daty od – do, kdy byla daná informace platná (existence úhoru, typ PVN nebo existence meziplodiny) a pravděpodobnost s jakou automatický algoritmus určil vyhodnocení.

Dále je předávána informace o tom, jakou metodou – např. optika/radar bylo vyhodnocení provedeno. V závislosti na metodě vyhodnocení budou předávána relevantní data, která byla pro vyhodnocení využita – např. hodnoty NDVI indexu, koherence atp. tak, aby na straně IS XXXX mohlo dojít k vykreslení těchto hodnot do grafu a srozumitelné prezentaci.

Obrázek 6 Příklad vizualizace EFA prvků

Vstupy:

• Data AP pro vyhodnocení (geometrie, atributy, sledovaná opatření + podmínky) z IS XXXX

• Data Sentinel (Poskytovatel)

Výstupy:

• Identifikátor AP a podmínky, s daty od kdy do kdy byl detekován úhor, meziplodina nebo určena PVN a s jakou spolehlivostí byl výsledek určen a metoda – např. optika/radar, kterou bylo vyhodnocení provedeno. V závislosti na metodě vyhodnocení budou výstupem relevantní data, která byla pro vyhodnocení využita – např. hodnoty NDVI indexu, koherence atp.

6. Kontrola zachování trvalých travních porostů (TTP) v oblastech definovaných v rámci ekoplatby nebo v environmentálně citlivých oblastech

Průběžné zpracování a vyhodnocování satelitních dat Sentinel-1 a Sentinel-2. Monitoring relevantních AP ze žádostí – travní porosty v oblastech definovaných v rámci ekoplatby nebo environmentálně citlivých oblastech. Až na výjimky není možné TTP změnit na jinou kulturu. Jedná se o obdobu služby detekce zemědělské kultury s rozšířenými podmínkami.

Služba vrací obdobné výsledky jako služba detekce kultury a plodiny. V tomto případě pouze kulturu.

Pokud na AP dojde ke změně kultury, IS XXXX ověří, jestli AP není překryto nějakou z ECP ploch. Pokud ano, IS XXXX (nebo po dohodě mezi dodavateli IS XXXX a SAMAS může řešit SAMAS, který může mít k dispozici ECP plochy) pošle do SAMAS polygon průniku AP a ECP plochy a SAMAS detekuje kulturu na této ploše. TTP se nesmí změnit v rámci ECP plochy, ale na zbytku AP může ke změně dojít (ECP nemusí pokrývat celé AP). Pokud je tvarem nebo velikostí AP (resp. průnik AP a ECP) nevhodná pro vyhodnocení nad daty Sentinel, pošle se zpět do IS XXXX, že podmínka (zachování TTP na ECP plochách) na dané AP je nemonitorovatelná.

IS XXXX vyhodnocuje, jestli došlo/nedošlo ke změně kultury. Existuje výjimka, kdy se může TTP rozorat, ale musí se do podání žádosti zatravnit. Toto není podstatné z pohledu SAMAS, ale pro vyhodnocení na straně IS XXXX. SAMAS by měl pouze detekovat změnu kultury v čase.

Vstupy:

• Data průniku AP a ECP pro vyhodnocení (geometrie, atributy, sledovaná opatření + podmínky) z IS XXXX.

• Data Sentinel (Poskytovatel).

Výstupy:

• Identifikátor AP/podmínky s informací o kultuře na ECP ploše a metoda – např. optika/radar, kterou bylo vyhodnocení provedeno. V závislosti na metodě vyhodnocení budou výstupem relevantní data, která byla pro vyhodnocení využita – např. hodnoty NDVI indexu, koherence atp.

2. Komunikační rozhraní

Pro předávání dat ze žádostí ze systému IS XXXX k Poskytovateli a výsledků služeb SAMAS od Poskytovatele do systému IS XXXX bude zřízeno komunikační rozhraní, které umožní automatizovaný přenos dat. Rozhraní musí být uzpůsobeno tak, aby dokázalo pokrýt opakovaný přenos při změně dat ze žádostí, a stejně tak opakovaný přenos nových výsledků služeb SAMAS a aktualizaci stavu podmínek v DB XXXX.

Předpokládaný objem vyhodnocovaných dat žádosti:

• Pro první rok kontraktu: cca 33 000 AP u 4 500 žadatelů

• Pro další roky kontraktu: cca 607 000 AP u 31 000 žadatelů

První rok kontraktu (do monitoringu budou vstupovat pouze žadatelé, kteří žádají pouze o opatření SAPS, Mladý Zemědělec, Greening).

Rozhraní musí počítat s největší zátěží kolem data, kdy končí příjem jednotných žádostí.

Rozhraní musí být zabezpečeno, a to pro komunikaci server – server. SAMAS obdrží uživatelské jméno pouze v případě žádosti o expertní vyhodnocení, v ostatních případech se jedná pouze o komunikaci na úrovni integračních rozhraní a o autorizaci uživatelů se stará Portálový systém IS SZIF, který poskytuje uživatelům systému XXXX uživatelské rozhraní. Vlastnosti integračního rozhraní IS XXXX jsou popsány v kapitole 7.1 Vlastnosti integrační platformy této Přílohy č. 5 Zadávací dokumentace Vlastnosti.

Mimo automatického příjmu AP k vyhodnocení musí SAMAS počítat i s manuálním zadáním AP k vyhodnocení a vytvořením žádosti o expertní vyhodnocení.

Přenášená data budou komprimovaná, aby docházelo k přenosu co nejmenšího objemu předávaných dat.

Rozhraní bude podporovat operaci pro získání stavu výpočtu pro konkrétní AP a podmínku – stavy budou stanoveny v rámci implementace. Např.

• Čeká ve frontě na zpracování

• Zpracovává se

• Zpracováno – není monitorovatelné

• Zpracováno - čeká se na nová data Sentinel

• Zpracováno - skončilo období pro zpracování

• Chyba při zpracování + popis chyby a možné řešení

Rozhraní umožňuje synchronizaci – je napojeno na číselníky v IS XXXX, a to hlavně číselníky s dotačními opatřeními a vyhodnocovanými podmínkami, které budou základem (katalogem) pro SAMAS a určují, která opatření a jejich podmínky má vyhodnocovat. Počítá se s tím, že v průběhu času a s vývojem nových detekčních algoritmů, bude monitorováno víc a víc podmínek a bude docházet ke změnám opatření. Každý rok bude s Poskytovatelem dohodnuto, jaká opatření budou pro daný rok sledována.

Komunikační rozhraní zpřístupní logy komunikace tak, aby bylo možné sledovat využívání rozhraní, případně vytvářet statistiky nad logem nebo využít logy v případě řešení problémů při komunikaci mezi rozhraními nebo k výpočtu parametrů SLA nebo KPI.

Vstupy:

• Data AP, případně dalších polygonů (aktuálně jen plocha průniku AP a ECP plochy) pro vyhodnocení (geometrie, atributy, sledovaná opatření + podmínky) z IS XXXX

• Číselníky

Výstupy:

• Výsledky služeb SAMAS

• Stavy zpracování podmínek na AP

• Logy

3. Expertní vyhodnocení plnění podmínky

SAMAS poskytuje pro IS XXXX také službu tzv. „expertní vyhodnocení“, kdy může pracovník vybrané role Zadavatele požádat prostřednictvím IS XXXX o posouzení a doplnění informací ke konkrétnímu AP a podmínce nebo seznamu podmínek na daném AP. Expertní vyhodnocení proběhne tak, že ze strany SAMAS do procesu „expertního vyhodnocení“ vstoupí kvalifikovaná osoba, která může dle svého uvážení využít pro vyhodnocení i jiné interpretace dat Sentinel nad rámec běžně využívaných algoritmů nebo jiné zdroje než Sentinel. Žádost o „expertní vyhodnocení“ bude zaslána stejně jako manuální zaslání AP k vyhodnocení, navíc bude obsahovat příznak „expertního vyhodnocení“ a případně doplňující komentář pracovníka Zadavatele.

Expertní vyhodnocení bude pro účely fakturace rozděleno pracovníkem Dodavatele podle náročnosti vyhodnocení do 3 kategorií:

• S – jednoduché; operátor je schopen vyhodnotit bez větších obtíží ve velmi krátkém čase (v řádech jednotek minut až menších desítek minut), zda je podmínka na daném AP splněna, či nikoliv.

• M – náročnější; operátor je schopen vyhodnotit v krátkém čase (do 1 hodiny) zda AP splňuje, či nikoliv vybranou podmínku/opatření, přičemž musel například použít speciální algoritmy vyhodnocení, které nejsou standardně Dodavatelem využívané.

• L – náročné; operátor je schopen vyhodnotit v čase větším, než 1 hodina, zda AP splňuje, či nikoliv vybranou podmínku/opatření, přičemž musel například použít speciální algoritmy vyhodnocení, které nejsou standardně Dodavatelem využívané a využít jiné zdroje než data Sentinel.

K expertnímu vyhodnocení se budou posílat pouze vybrané AP.

Vyhodnocení, které spadne do kategorie L, musí být před zpracováním vždy schváleno odpovědným pracovníkem Zadavatele. Dodavatel určí obtížnost, Zadavatel schválí realizaci, Dodavatel zpracuje a dodá výsledek.

Předpokládaný počet expertním režimem vyhodnocovaných podmínek je 3000/rok

Vstupy:

• Data AP pro vyhodnocení (geometrie, atributy, sledovaná opatření + podmínky) z IS XXXX – co chci vyhodnotit

• Poznámka pracovníka Zadavatele

• Data Sentinel nebo jiná (Poskytovatel)

Výstupy:

• Identifikátor AP a vyhodnocení podmínky – struktura výstupu by měla odpovídat struktuře při automatickém vyhodnocení tak, aby nebylo nutné upravovat rozhraní na straně IS XXXX, s příznakem expertního vyhodnocení.

• Dokument s popisem způsobu vyhodnocení a použitými podklady včetně mapových, je-li to relevantní, vytvořený pracovníkem Dodavatele tak, aby bylo možné způsob vyhodnocení podmínky v případě stížnosti opakovat.

• Náročnost vyhodnocení S/M/L.

4. Mapová služba

SAMAS bude poskytovat mapovou službu pro zobrazení série snímků Sentinel-2 pro území ČR až 2 roky zpětně, která bude schopna "on the fly" vracet ze satelitních dat zobrazení NDVI indexu a snímek ve dvou barevných kompozicích (true color, color infrared). Mapová služba případně zahrnuje i další použitá obrazová data, která Poskytovatel využije. Zároveň musí mapová služba poskytovat data v definovaných termínech tak, aby mapový klient mohl implementovat prohlížení snímků v zadaném časovém rozsahu. Mapová služba musí splňovat standardy OGC (WMS TIME).

Kromě poskytovaných mapových služeb budou vektorové zákresy detekovaných nehomogenit (viz 6.3.3.1.2) zasílány jako zvláštní datová sada a následně ukládány v IS XXXX jako nová mapová vrstva, aby s nimi bylo možné dále pracovat.

Podklady, které bude služba poskytovat, si bude moci zobrazit jak žadatel v Portálovém řešení SZIF, tak pracovník Zadavatele v administrativním modulu. Vrstvu detekovaných nehomogenit bude možné z IS XXXX publikovat také do Předtiskové aplikace LPIS.

Bude k dispozici nepřetržitě.

Vstupy:

• Data Sentinel-2, případně další použitá obrazová data.

Výstupy:

• Mapová/é služba(y) dle standardu OGC.

5. Zapracování výsledků vyhodnocení kvality

Dodavatel bude dostávat výsledky vyhodnocení kvality služeb SAMAS od Zadavatele. Formát předávání bude upřesněn během implementace.

Poskytovatel zapracuje tyto výsledky a získanou skutečnost z terénu do svých výpočtů za účelem zpřesnění algoritmů pro nadcházející období.

Předpokládá se, že s přibývajícím množstvím referenčním dat se výsledky vyhodnocení budou meziročně zlepšovat.

Vstup:

• Výsledky validace ze strany SZIF

Výstupy:

• Rozšíření datové základny na straně Poskytovatele a vylepšení algoritmů

6. Tvorba a údržba dokumentace

Viz kapitola 5 Požadavky na dokumentaci.

7. Poskytování služeb podpory a rozvoje

Viz kapitola 4 Navazující služby.

4. Zajištění bezpečnosti a dostupnosti služeb

Součástí předmětu veřejné zakázky je zajištění bezpečnosti a dostupnosti služeb poskytovaných Poskytovatelem služby SAMAS v souladu s předmětem plnění popsaným výše. Požadované provozní parametry těchto služeb jsou spolu s metrikami měření jejich kvality uvedeny v přílohách Smlouvy, která je Přílohou č. 1 této zadávací dokumentace.

Součástí zajištění bezpečnosti je i zajištění důvěrnosti dat. Služba SAMAS zpracovává data obsahující neveřejné údaje vztahující se k dotacím a jejich kontrole.

Součástí plnění je i součinnost při provádění penetračních testů, jejichž provedení zajistí Zadavatel.

1. Požadavky na kryptografické operace a šifrování

Pro zabezpečení komunikace a kryptografické operace v řešení XXXX je požadováno:

• Komunikace s klientem je realizována výhradně kanálem zabezpečeným TLS v poslední známé verzi anebo verzi podporované klientem, minimálně však verzí TLS 1.2 nebo TLS 1.3.

• Zabezpečená TLS komunikace pro přístup ke všem dalším zdrojům načítaným do portálových stránek (není kombinován zabezpečený a nezabezpečený obsah).

• Využití cipher suites s minimálně 128-bitovým šifrováním anebo silnějším, využití AES cipher.

• Podpora perfect forward secrecy (PFS) ve formě Elliptic Curve Diffie-Hellman (EDCHE) nebo Ephemeral Diffie-Hellman protokolů pro výměnu klíčů;

• Podpora obnovení relace TLS - TLS Session Resumption, minimalizace potřeb opakovaného sestavování zabezpečené relace a vyjednávání o využitých klíčích.

• Volitelná podpora poskytování informací o revokovaných certifikátech přímo klientovi (OCSP stapling), minimalizace komunikace klienta s OCSP serverem.

• V případě využití cookies využití secure cookies s nastaveným secure příznakem (secure flag), zároveň bude zohledněna možnost přistupovat ke cookies pouze HTTPS (flag HttpOnly) a možnost zamezení cross-site využití cookies nastavením příznaku (SameSite).

• Podpora využití serverového TLS certifikátu vydaného komerční certifikační autoritou využívanou Zadavatelem.

• Uložení certifikátů (zejména privátních klíčů) v zabezpečeném úložišti.

5. Správa číselníků a pravidel

Některé číselníky a pravidla nebo scénáře řídící algoritmy vyhodnocování budou sdílené v rámci celkového řešení XXXX, proto Zadavatel poskytuje informaci o požadavcích na práci s číselníky a pravidly.

Od Poskytovatele je požadována realizace relevantních požadavků tak, aby mohl potřebné číselníky a jejich aktualizace přebírat z IS XXXX.

Požadavky na synchronizaci číselníků jsou následující (výčet nemusí být kompletní):

Ref.	Text
	Číselník plodin a kultur
	Číselník dotačních podmínek a opatření

Tabulka 2 Požadavky na správu číselníků

6. Legislativa a standardy, které musí plnění splňovat

   1. Legislativní požadavky a strategické dokumenty

Níže uvedená tabulka informuje o legislativních dokumentech, kterými se dodávané plnění řídí.

Ref.	Dokument
	Nařízení Evropského parlamentu a Rady (EU) 2019/881 ze dne 17.4. 2019 o agentuře ENISA („Agentuře EU pro kybernetickou bezpečnost“) o certifikaci kybernetické bezpečnosti ICT a o zrušení nařízení (EU) č. 526/2013 („akt o kybernetické bezpečnosti“)
	Nařízení Evropského parlamentu a Rady (EU) 910/2014 v platném znění (EIDAS)
	Zákon č. 297/2016 Sb., o službách vytvářející důvěru pro elektronické transakce, ve znění pozdějších předpisů.
	Zákon č. 250/2017 Sb., o elektronické identifikaci, ve znění pozdějších předpisů
	Zákon č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů, ve znění pozdějších předpisů (ZoKB)
	Zákon č. 12/2020 Sb., o právu na digitální služby a o změně některých zákonů, ve znění pozdějších předpisů
	Vyhláška č. 82/2018 Sb., o bezpečnostních opatřeních, kybernetických bezpečnostních incidentech, reaktivních opatřeních, náležitostech podání v oblasti kybernetické bezpečnosti a likvidaci dat (VoKB)
	Vyhláška č. 317/2014 Sb., o významných informačních systémech a jejich určujících kritériích, ve znění pozdějších předpisů
	Program Digitální Česko; Informační koncepce ČR (dále IK ČR)
	Zákon č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací a o změně zákona č. 365/2000 Sb., o informačních systémech veřejné správy a o změně některých dalších zákonů, ve znění pozdějších předpisů (zákon o přístupnosti)
	SMĚRNICE EVROPSKÉHO PARLAMENTU A RADY (EU) 2016/2102 ze dne 26. října 2016 o přístupnosti internetových stránek a mobilních aplikací subjektů veřejného sektoru
	Vyhláška č. 316/2021 Sb., o některých požadavcích pro zápis do katalogu cloud computingu
LEG_13	Vyhláška č. 315/2021 Sb., o bezpečnostních úrovních pro využívání cloud computingu orgány veřejné moci

Tabulka 3 Legislativa, kterou musí plnění splňovat

2. Standardy

Zadavatel je certifikován dle ISO/IEC 27001:2013 včetně certifikace pro všechny oblasti ISMS i působnost Fondu (Zadavatel) jako platební agentury (s uplatněním norem ISO 27017 pro bezpečnostní opatření u cloudových služeb a ISO 27018 o ochraně osobních údajů v cloudu).

Provozovaný informační systém je Významným systémem dle ZoKB, a tedy každé řešení, které pořizuje, musí umožnit dodržení těchto standardů.

Ref.	Standard
	ISO/IEC 27001:2013
	ISO 27017 pro bezpečnostní opatření u cloudových služeb
	Bezpečnostní standard WS-Security.
	OGC standardy
	Souhrn odpovědí EK k výkladu nařízení 809/2014 v dokumentu DS/CDP/2019/01
	Guidance CTS - Technical Guidance for the On-The-Spot Checks (OTSC) and area measurement according to Art. 24, 25, 26, 27, 30, 31, 34, 35, 36, 37, 38, 39, 40, 41 of Regulation (EU) No 809/2014 as amended by Regulation (EU) 2015/233
	Harmonizovaná evropská norma EN 301 549  V2.1.2 (2018-08)

Tabulka 4 Standardy, kterým musí plnění vyhovět

7. Informace o technologiích Zadavatele, se kterými bude služba interagovat

V této kapitole uvedeme informace o technologiích, které ovlivní požadavky nebo možnosti vytváření rozhraní na IS Zadavatele. Jedná se i o vlastnosti Integrační platformy IS XXXX.

1. Vlastnosti integrační platformy

Poskytovatel může předpokládat tyto vlastnosti Integrační platformy IS XXXX, na kterou se bude jím poskytovaná služba integrovat. Integrační platformu uchazeč na základě této VZ nedodává.

Integrační platforma zastává v architektuře celkového řešení XXXX roli zprostředkovatele komunikace. Platforma v rámci celkového řešení XXXX zajišťuje:

• interní komunikaci komponent/modulů IS XXXX a výměnu zpráv mezi těmito moduly,

• přístup uživatelských rozhraní (portálových a případně jiných aplikací) k datům a funkcionalitám IS XXXX a zprostředkování komunikace mezi Portálovými aplikacemi XXXX a back-endem tvořeným IS XXXX,

• zprostředkování komunikace mezi systémy IS XXXX a externími službami SAMAS a službou GT FOTO,

• komunikaci s externími systémy, přičemž platforma je za tímto účelem integrována s existující integrační sběrnicí Zadavatele – SAP PO včetně SAP AAE.

Integrační platforma může být v budoucnu využita i pro integrační úlohy mimo celkové řešení XXXX.

Základní logické schéma integrační platformy je znázorněno na obrázku Obrázek 3 Logické schéma integrační platformy (sběrnice) XXXX. Logický model řešení obsahuje grafické znázornění funkčních komponent řešení a jejich vzájemné spolupráce. Jednotlivé funkční komponenty mohou být v rámci poskytovaného řešení implementovány jedním, či více nabízenými systémy.

Integrační platforma musí naplňovat níže uvedené požadavky a poskytovat zmíněné funkcionality rozdělené do několika oblastí uvedených v následujících kapitolách.

Obrázek 3 Logické schéma integrační platformy (sběrnice) XXXX

1. Architektura

Integrační platforma XXXX musí v oblasti architektury umožňovat:

• nasazení a běh v prostředí s vysokou dostupností tvořeném více uzly v několika geografických lokalitách zapojených do geografického clusteru,

• balancování provozu na samostatné uzly v několika geografických lokalitách a podpora režimu active-active,

• řízeně odstavit jeden uzel v clusteru bez dopadu na rozpracované transakce,

• automatické přepnutí provozu na dostupné uzly v clusteru v případě výpadku jednoho z uzlů tvořících cluster.

2. Využité technologie

Pro výstavbu integrační platformy musí být využity standardní technologie Zadavatele popsané v Příloze č. 6 této ZD – Technická dokumentace – NDA.

Součástí integrační platformy je i ETL nástroj.

3. Integrační funkcionality

Platforma musí poskytovat následující funkcionality a služby:

• Integrace a zajištění vzájemné komunikace mikroslužeb zahrnující:

  • integraci s kontejnerizační platformou,

  • zajištění komunikace mezi mikroslužbami.

• Integrace a zajištění komunikace systémů využitím standardů SOAP a REST (ESB - Enterprise Service Bus) zahrnující,

  • podporu návrhu, nasazení a provozu integračních služeb v souladu s EIP (Enterprise Integration Patterns) - xxxx://xxx.xxxxxxxxxxx.xxx/xxx.xxxx

  • podporu těchto typů služeb:

    • proxy služby - pouze zrcadlení služeb vždy z jednoho zdrojového systému,

    • kompozitní služby - integrující jeden, či více systémů provádějící zároveň manipulace a transformace datových zpráv,

    • asynchronní služby - služby, kde je datový tok rozdělen do samostatných volání pro požadavek a odpověď, přičemž odpověď je konzumentskému systému navrácena asynchronně (tedy ne okamžitě),

  • integraci systémů na bázi webových služeb, umožňujících implementaci SOA,

  • integraci koncových bodů využívajících různé komunikační protokoly (např. jeden koncový bod vyžaduje JMS a druhý koncový bod podporuje pouze webové služby),

  • podporu transportů minimálně HTTP/S, JMS, web services (SOAP 1.2, SOAP 1.1, JAX-RPC, JAX-WS, REST, GraphQL),

  • podporu orchestrace služeb (řízení workflow služeb modelované v BPEL)

    • synchronní a asynchronní orchestrace,

    • řetězení služeb,

    • paralelní volání služeb,

    • validaci zpráv,

  • Zprostředkování a řízení přístupu k API dle standardů REST a GraphQL (API gateway) zahrnující:

    • zabezpečení a řízení volání,

    • validace volání,

    • poskytování definic API (např. Swagger),

  • Doručování zpráv (messaging) zahrnující:

    • podporu synchronního a asynchronního zasílání zpráv,

    • frontování zpráv a práci s frontami,

    • řízení priority zpráv, nastavení timeout volání (QoS - Quality of service),

    • zaručené doručení zpráv, doručení právě jednou,

    • omezení datového toku zpráv pro konkrétní systémy,

    • xxxxxxx zpracování zpráv,

  • Směrování zpráv zahrnující:

    • virtualizaci koncových bodů, využití logických názvů koncových bodů zdrojových služeb,

    • možnost změny koncového bodu zařazeného do virtuálního bodu za běhu,

    • směrování zpráv dle obsahu zpráv, hlaviček zpráv, QoS kritérií, politik a definovaných pravidel,

  • Mediace a transformace zpráv zahrnující:

    • podporu standardizovaných adaptérů a konektorů,

    • transformace zpráv mezi různými datovými formáty,

    • obohacování zpráv o dodatečné informace,

  • Přenos souborů umožňující:

    • přenos objemných souborů v řádu 100 MB i více mezi různými systémy a platformami bez dopadu na kvalitu ostatních komunikačních toků,

    • přenos mimo tělo zprávy,

  • Real-time a dávkové proudové (stream) přenosy objemných dat, podpora ETL zahrnující:

    • vlastní implementaci ETL anebo integraci na externí ETL systém,

    • podporu řízení ETL úloh prostřednictvím volání webových služeb konzumentskými a zdrojovými systémy pro synchronizaci velkých objemů dat mezi systémy,

  • Datové integrace, napojení na zdroje dat a publikace dat ve formě webových služeb zahrnující:

    • podporu konektorů pro běžné databáze, minimálně Oracle, MS SQL, MySQL, PostgreSQL,

    • publikaci dat ve formátu JSON či XML,

    • publikaci dat prostřednictvím SOAP anebo REST webových služeb,

    • podporu pokročilých dotazů na publikovaná data,

  • Transakční zpracování a obsluha chyb zahrnující:

    • podporu volání v rámci transakce,

    • podporu potvrzení (commit), či odvolání transakce (roll-back),

    • podporu vykonání kompenzačních akcí v případě selhání transakce,

    • možnost opakovaného volání (definovatelné) zdrojového systému či služby v případě selhání volání,

    • definovatelné politiky pro obsluhu chyb,

    • zajištění proti duplicitě transakcí ve zdrojových systémech,

    • podporu uložení rozpracovaných transakcí (pro případ restartu)

4. Logování, auditování a archivace dat

V oblasti logování, auditování a archivace dat musí platforma umožňovat:

• Logovat záznamy o realizovaných voláních,

• opatřit volání korelačním identifikátorem (klienta, integrační platformy a zdroje),

• webové zobrazení a vyhledání informací o realizovaných voláních zejména pro 1. úroveň podpory provozu řešení.

5. Provoz integrační platformy

Pro řádné zabezpečení provozu musí integrační platforma umožňovat:

• Začlenění do dohledových systémů (monitoring událostí, výkonnosti, bezpečnosti a E2E),

• monitoring metrik a poskytování dat pro vyhodnocení plnění SLA,

• zobrazit přehledový dashboard (monitoring stránky či více stránek) pro prezentaci souhrnného stavu řešení a jednotlivých implementovaných služeb zejména pro 1. úroveň podpory,

• začlenění do systémů zálohování dat a testování použitelnosti záloh.

6. Zabezpečení integrační paltformy

Integrační platforma, resp. tam, kde je to relevantní a v rámci detailní analýzy schválené, i další moduly řešení XXXX, musí v oblasti zabezpečení podporovat:

• Bezpečnostní standard WS-Security,

• autentizaci a autorizaci pro volání integračních služeb pro zajištění komunikace mezi systémy využitím klientského certifikátu,

• logování aktivit administrátorů nebo uživatelů obslužných aplikací, a to alespoň pomocí jedné z následujících metod:

• Syslog zabezpečený TLS,

• SNMP TRAP v3,

• Textový soubor,

• JDBC,

• Systémový log (žurnál operačního systému),

• autentizaci a autorizaci pro přístup k obslužným aplikacím využitím identitního systému Zadavatele (LDAP, SAML),

• bezpečný přístup z nedůvěryhodných sítí (možnost využití WAF),

• běh služeb pod neprivilegovanými účty,

• ochrana příchozích a odchozích požadavků prostřednictvím XML firewall s možností nastavit parser limity a rate control,

• podpora TLS 1.2/1.3,

• zapnutí anebo vypnutí kontroly revokace prostřednictvím CRL i OCSP,

• podpora bezpečných kryptografických algoritmů (cipher suites) se zabezpečením komunikace využitím Perfect Forward Secrecy (PFS),

• důvěryhodné předání informací o klientském certifikátu, IP atd. z load balanceru nebo reverse proxy, pokud bude terminace komunikačního kanálu řešena mimo samotnou integrační platformu,

• provoz v IPv6 prostředí, schopnost v překlenovacím období obsluhovat IPv6 i IPv4 jak na listenerech, tak na službách poskytovaných externě,

• plný provoz pouze na IPv6 nebo IPv4 nejen u serverů ale i síťových prvků,

• zabezpečení komunikace mezi Konzumentem a Poskytovatelem služeb prostřednictvím TLS, (volitelně možnost zakončení TLS zabezpečení na TLS akcelerátoru),

• možnost omezit počet zpracovávaných požadavků, ochrana systému před zahlcením.

7. Obslužné aplikace

Řešení musí obsahovat následující obslužné aplikace:

• Katalog služeb zahrnující funkcionality:

• poskytující informace o publikovaných službách,

• umožňující konfigurovat základní parametry služeb,

• poskytující základní konfigurační informace pro běh služeb.

• Grafický designér integrací a datových toků umožňující vizuálně editovat tok služeb (workflow) obsluhy příchozích volání.

8. Kontext plnění

Stávající informační systém Zadavatele nepodporuje efektivní práci s geografickými informacemi, satelitními snímky, geotagovanými fotografiemi a nepodporuje a ani nemůže podporovat nově navrhované procesy vznikající za účelem splnění požadavků EU na provádění plošných kontrol s využitím satelitního monitoringu. Část procesů, kterých se změna netýká, bude i nadále podporována stávajícím IS Zadavatele. Některé procesy budou pozměněny a jen jejich část bude prováděna mimo stávající IS Zadavatele. Zbylá část procesů bude podporována stávajícím systémem a samozřejmě nově navržené procesy budou podporovány novým informačním systémem XXXX.

Požadavky, které musí informační systém XXXX splnit, jsou uvedeny v Příloze č. 6 – Technická dokumentace - NDA této ZD, která je neveřejným dokumentem Zadávací dokumentace.

Řešení IS XXXX má oddělený back-end (BACK-XXXX) realizovaný v rámci dodávky IS XXXX a front-end realizovaný Portálovou aplikací XXXX (dále v diagramech architektury PORMACH) vytvořenou v prostředí nově budovaného portálu (dále Portálový systém SZIF).

Specifikaci níže vytvářeli ze značné části budoucí uživatelé systému a je psána tak, že popisuje požadované funkce systému jako celku vyhovujícímu nově navrhovaným procesům. Přitom se nelze vyhnout situacím, kdy část procesu je podporována aplikací třetí strany: část procesu je podpořena IS XXXX, případně dochází ke komunikaci s novými externími službami SAMAS (Satellite Monitoring and Analysis Service) a službami GT FOTO (služba pro pořizování a správu geotagovaných fotografií) nebo s registry OOP a OVM. Z tohoto důvodu, a také proto, aby si Poskytovatel mohl dělat ucelenou představu o celkovém řešení XXXX, jsou ve specifikaci popsány i funkce a služby, které Poskytovatel na základě této VZ nedodává, ale dodávané řešení je s nimi integrováno a službu pro koncového uživatele spoluvytváří; vyměňuje si se službami a funkcemi třetích stran data a generuje události rozpoznávané těmito službami nebo přijímá události jimi generované.

1. Definice projektu XXXX

   1. Cíle projektu XXXX

Hlavním cílem celkového řešení XXXX je implementace řešení pro splnění povinností obsažených v novele nařízení EK č. 809/2014. 

Dílčími cíli celkového řešení XXXX jsou:

1. Nastavení partnerského vztahu s klienty

Kontroly pomocí monitoringu umožní změnit dosavadní praxi, která je mnohdy vnímána jako represivní, na model partnerský, kdy obě strany (platební agentura a žadatel) mají společný zájem. Kontinuální a proaktivní komunikace s žadateli umožní minimalizaci počtu situací, kdy skutečný stav je v nesouladu s deklarací v žádostech.

2. Snížení nevyčerpaných finančních prostředků z EU v příslušném roce díky snížení chybovosti žádostí

Proaktivní upozorňování na plnění, či neplnění podmínek dotačních programů a úkony, které v reakci na upozornění učiní žadatelé, povedou k minimalizaci chybovosti (odchylek deklarací uvedených v žádostech oproti skutečnému stavu).

3. Sjednocení kontrolní zátěže pro všechny žadatele na plošná opatření

Zavedením kontrol pomocí monitoringu dojde u monitorovaných podmínek k narovnání stavu, který je založen na výběru vzorků žadatelů. Všichni žadatelé na plošná opatření budou kontrolováni stejně.

4. Snížení rizika vůči fondům

Ze strany Evropské komise jsou kontroly realizované pomocí monitoringu, tzn. systém, kdy dochází k 100% prověření plochy prostřednictvím automatického vyhodnocení družicových dat, vnímány jako méně rizikové vůči fondům. Monitoring celého území zvyšuje pravděpodobnost, že budou odhaleny nezpůsobilé plochy s významnou výměrou.

5. Snížení kontrolní zátěže

Zavedením kontrol pomocí monitoringu dojde u vybraných podpor k nahrazení standardních Kontrol na místě (KNM). Terénními návštěvami budou řešeny pouze případy, kdy nebude možné rozhodnout o plnění monitorovaných podmínek jiným způsobem. Kontroly nemonitorovaných podmínek budou prováděny i nadále na základě výběru vzorku žádostí, ale v rámci těchto kontrol nebude prováděno měření způsobilé plochy. Proto lze předpokládat snížení časové náročnosti kontrolních procesů Zadavatele, zkrácení času provádění kontrol u žadatelů i snížení celkové kontrolní zátěže žadatele.

6. Vytvoření základní GIS platformy (nejen pro potřeby kontrol pomocí monitoringu)

Již stávající procesy IACS generují prostorová data, ale Zadavatel aktuálně nedisponuje odpovídajícími nástroji pro to, aby s nimi mohl efektivně pracovat a tato data spravovat. Implementace kontrol pomocí monitoringu nutně vyžaduje vybudování GIS platformy, která umožní efektivně zpracovávat získaná a nově vytvářená prostorová data, umožní s nimi efektivně nakládat a zároveň umožní prostřednictvím jednotlivých GIS nástrojů maximální výtěžnost a efektivní a názornou prezentaci získaných výsledků, a to jak v interním prostředí Zadavatele, tak v komunikaci s externími partnery (žadatelé, kontrolní orgány).

7. Zefektivnění administrace JŽ a zkvalitnění služeb žadatelům a příjemcům dotací.

1. Základní principy implementace požadavků novely nařízení EK č. 809/2014

1. Princip kontrol pomocí monitoringu je založen na kontinuálním sledování zemědělských pozemků a kontinuálním vyhodnocování zemědělských aktivit pomocí dat dálkového průzkumu Země, zejména dat družic Sentinel, přičemž platí:

1. Monitoring ověřuje plnění zadaných monitorovaných podmínek Zadavatelem zvolených opatření, a to plošně pro všechny žádosti.

2. Výjimkou mohou být parcely, které pro jejich tvar a malou rozlohu nedokáže algoritmus monitoringu vyhodnotit, ale je možno tyto parcely pro účely monitoringu spojovat, pokud je na nich monitorována shodná podmínka. Rozhodnutí o splnění podmínky pro takto vytvořenou virtuální parcelu je pak aplikováno na dílčí parcely, ze kterých byla spojená parcela vytvořena.

3. Vzhledem k tomu, že satelit přelétá nad naším územím v určitých intervalech, není možno stanovit přesné datum, kdy nastala změna, která byla zaznamenána.

4. Vzhledem k tomu, že je území ČR snímáno ve více pásech, nebudou výsledky monitoringu k dispozici pro celé území ČR k jednomu datu.

5. Satelitní monitoring nemusí být schopen u všech monitorovaných parcel rozhodnout, zda je daná podmínka v daném čase na dané parcele splněna nebo nesplněna. Toto je zejména závislé na velikosti a tvaru parcely.

6. Sběr satelitních dat probíhá kontinuálně před podáním žádostí, v průběhu plnění podmínek žádostí i po rozhodnutí o výplatě prostředků. 

7. Pro zpřesnění výsledků monitoringu lze využít další datové zdroje – ortofoto, snímky z jiných satelitů než Sentinel nebo geotagované fotografie pořizované jak žadateli, tak inspektory Zadavatele v rámci terénních šetření.

8. Opatření mohou obsahovat současně monitorované i nemonitorované podmínky. Na kontrolu nemonitorovaných podmínek opatření, která obsahují zároveň monitorované podmínky (KNP), se vztahují jiná (jednodušší) pravidla kontroly, než jsou pravidla standardních kontrol na místě.

9. Existují opatření, která neobsahují žádnou monitorovanou podmínku. Tato opatření budou kontrolována a administrována stávajícími procesy.

2. Terénní šetření se zaměřuje na:

1. Kontrolu pozemků, u nichž služba monitoringu nerozhodla o splnění/nesplnění podmínky.  

2. Kontrolu podmínek, které satelitním monitoringem vyhodnotitelné nejsou.

3. Princip kontinuální komunikace s žadatelem

1. Žadatel je průběžně informován o tom, jaký stav plnění podmínek Zadavatel eviduje.

2. Žadatel může dostávat upozornění na blížící se termíny, kdy má mít splněnou nějakou podmínku nebo provést očekávaný úkon, pokud tato podmínka není v určitém časovém intervalu před termínem dle informací získaných Zadavatelem splněna, nebo úkon nebyl proveden.

3. Zadavatel žadateli průběžně poskytuje další informace s cílem zajistit jeho informovanost o případných změnách nebo s cílem zajistit minimalizaci chyb (upozorní na opakující se chyby) nebo o chystaných opatřeních atd.

4. Žadatel se na základě poskytnutých informací může sám rozhodnout, že informace o plnění podmínek opatření zpřesní nebo doloží.

4. Žadatel může plnění podmínky doložit geotagovanými fotografiemi nebo jiným dokladem v závislosti na typu podmínky

1. Doložení může provést na výzvu Zadavatele nebo kdykoli na základě vlastního rozhodnutí (třeba na základě upozornění, že Zadavatel danou podmínku považuje za nesplněnou nebo na základě průběžně poskytované informace, kde vidí, že daná podmínka je zatím nerozhodnutá, nebo je rozhodnutá chybně).  

2. Doložení některých dokladů je třeba provést do zadaného termínu.

5. Žadatel má možnost průběžně (do rozhodnutí o dotaci nebo do termínu uvedeného v dotačním programu) měnit žádost

1. Žádost není možno měnit po datu rozhodnutí nebo po termínu uvedeném v textu, jímž se vyhlašuje dané opatření.  

2. Žádost není dovoleno změnit na základě nálezu porušení nemonitorovatelné podmínky ani v případě ohlášení kontroly na místě.

6. Maximální objem komunikace zajistit elektronicky

1. Pro zjednodušení procesů a zajištění vyšší míry automatizace procesů bude zlepšována a rozšiřována podpora elektronické komunikace.  

2. Preferována bude komunikace strukturovanými daty (formuláře s kontrolami a nápovědou), která lze následně snadno zpracovat.

7. Zvyšování míry automatizace a optimalizace interních procesů Zadavatele  

1. Návrh procesů by měl být vytvářen s ohledem na možnosti automatizace procesu. Vstupní data co nejvíce strukturovat, a tak umožnit jejich snadné počítačové zpracování.  

2. I pro rozhodování, které musí udělat člověk, připravit podklady tak, aby bylo rozhodování co nejvíce usnadněno.  

3. Pro optimalizaci využít toho, že nové moduly budou pracovat s geoprostorovou informací – např. optimalizace kontrol v terénu, kdy lze seskupovat kontroly podle geografické vzdálenosti a optimalizovat trasu inspektora.  

8. Auditovatelnost

1. Proces musí vytvářet auditní stopu tak, aby bylo jasné kdo, kdy a na základě jakých podkladů učinil dané rozhodnutí nebo provedl danou aktivitu. Musí být možno trasovat od výsledku po jeho zdroje.

9. Důvěrnost

1. Přístup k dokumentům a datům musí být řízen tak, aby k nim mohli přistupovat jen oprávnění uživatelé.

10. Flexibilita řešení

1. Procesy a jejich ICT podporu navrhovat a realizovat tak, aby jejich provádění bylo řízeno pravidly a daty, která lze uživatelsky měnit, aniž bude třeba měnit algoritmy zabudované v software.

2. Výchozí stav a principy řešení

   1. Výchozí stav 

Zadavatel zprostředkovává zemědělcům, lesníkům a potravinářům finanční podporu z EU a národních zdrojů a zajišťuje následnou kontrolu oprávněnosti užívání dotací a kontrolu výsledků jejich užití. Část poskytovaných podpor, konkrétně přímé platby a plošná environmentální opatření v rámci programu rozvoje venkova, je povinně administrována a kontrolována systémem IACS.

Dle nařízení (EU) č. 1306/2013 čl. 68 až čl. 73 je IACS (Integrated Administration and Control System) složen z níže uvedených prvků (A-F).

1. počítačová databáze;

2. systém identifikace zemědělských pozemků; 

3. systém identifikace a evidence platebních nároků (pozn. v ČR neaplikováno);

4. žádosti o podporu a žádosti o platbu;

5. (integrovaný) kontrolní systém; 

6. systém pro identifikaci příjemců intervencí a opatření uvedených v čl. 67 odst. 2. 

V rámci stávajícího nastavení IACS probíhají dva typy kontrol – administrativní kontroly a kontroly na místě (KNM).

Administrativní kontroly spočívají v křížových kontrolách dat deklarovaných v žádosti na dostupná data registrů, přičemž všechny žádosti jsou administrativní kontrolou zkontrolovány.

Kontrola na místě spočívá v kontrole plnění podmínek opatření a přeměření způsobilé plochy přímo v terénu. Pro kontrolu na místě se vybírá předem stanovený vzorek žádostí (nejčastěji 5 %).

Kontroly jsou navíc doplněny sankčním systémem, který je nastaven výrazně restriktivně, aby odrazoval žadatele od chybné deklarace. Taktéž platí, že po nalezení nesouladu nemůže žadatel chybnou deklaraci opravit. Nevýhodou stávajícího nastavení IACS je jeho relativní nízká efektivnost, kdy časově a na lidské zdroje náročné kontroly na místě zkontrolují pouze malý vzorek žadatelů a detekují tak jen omezený počet porušení.

Od roku 2015 se rozvíjí nová technologie umožňující plošné sledování (monitoring) celého území pomocí metod dálkového průzkumu Země. Výstupy z výzkumných projektů prokázaly, že při využití dat družic Sentinel je možné úspěšně realizovat sledování zemědělských aktivit na zemědělských pozemcích pomocí automatizovaných algoritmů. Tato družicová data jsou navíc dostupná zdarma a jejich pořízení není zpoplatněno, jak tomu bylo doposud v případně tradičně využívaných družicových dat vysokého a velmi vysokého rozlišení (např. QuickBird, Rapid Eye a další). 

Zvyšující se dostupnost ICT technologií (chytré telefony, internetové připojení, GNSS technologie) dále v sobě skrývá potenciál rozšířit a změnit způsob komunikace s žadatelem a to tak, aby žadatel získával průběžné informace o výstupech z monitoringu a o postupu administrace své žádosti. V případě nesrovnalosti pak žadatel může sám poskytnout validní důkaz o plnění podmínek, případně online opravit deklaraci.

Evropská komise v reakci na výše uvedené skutečnosti a výstupy z výzkumných projektů novelizovala prováděcí nařízení č. 809/2014 a v rámci IACS zavedla nový způsob kontroly, tzv. kontroly pomocí systému sledování plochy, nebo také kontroly pomocí monitoringu, kterými členské státy mohou nahradit kontroly na místě.

2. Principy kontrol s využitím satelitního monitoringu

Princip kontrol pomocí monitoringu je založen na rozdělení podmínek dotace do dvou skupin na monitorovatelné a nemonitorovatelné podmínky.

Příkladem monitorovatelných podmínek jsou: identifikace zemědělské kultury, plodinových skupin, identifikace seče, orby a založení a sklizení plodiny. Příkladem nemonitorovatelné podmínky je počet hospodářských zvířat, nebo identifikace druhu dřeviny.

Zadavatel pro dané období určí, které monitorovatelné podmínky budou v daném období kontrolovány pomocí satelitního monitoringu – určí monitorované podmínky.

Pozemky s monitorovanými podmínkami jsou kontinuálně sledovány a dochází u nich k průběžnému vyhodnocování zemědělských aktivit pomocí dat dálkového průzkumu Země, zejména dat družic Sentinel (konkrétně Sentinel-1 a Sentinel-2). Výsledkem kontroly je buď konstatování splnění podmínky, nebo nesplnění podmínky, případně vyhodnocení satelitních dat o splnění nebo nesplnění podmínky nedokáže rozhodnout. Díky frekvenci pořizování dat Sentinel se natolik rozšířila datová základna, nad kterou lze ověřit definované parametry jednotlivých dotačních titulů, že je možné ve valné většině případů vyhodnotit splnění/nesplnění podmínky pouze na základě dat Sentinel bez nutnosti šetření v terénu. 

V případech, kdy vyhodnocení časové řady dat Sentinel není schopno dát jednoznačný výsledek, je nutné realizovat navazující aktivity tzv. Follow-up. Navazující aktivitou je požádání o dodání důkazů přímo farmářem (systém geotagovaných fotografií), dále vyhodnocení podmínky nad dalšími datovými zdroji (např. aktuální letecké snímky), nebo realizování polní návštěvy pracovníkem Zadavatele (terénním inspektorem). Je-li to možné, o volbě konkrétní navazující aktivity pro daný pozemek a podmínku v některých případech rozhoduje IT systém automaticky. Jinak rozhoduje pracovník Zadavatele v roli, která realizuje navazující aktivity. Výsledkem navazujících Follow-up aktivit musí být konstatování splnění/nesplnění podmínky pro účely výplaty dotace. 

Dílčí výsledky kontroly pomocí monitoringu jsou průběžně sdělovány farmáři vizualizací prostřednictvím Portálového systému SZIF (tzv. scoreboard). Díky průběžnému vyhodnocení dílčích podmínek a pozemků je scoreboard průběžně aktualizován. Dále systém generuje notifikace „Alerty“, tj. upozornění na blížící termín splnění podmínky u pozemků, kde ještě daná podmínka splněna nebyla. V okamžiku finálního rozhodnutí o splnění/nesplnění podmínky u všech deklarovaných pozemků daného žadatele a opatření, na která žádal, je vyhotoven dokument s „předběžnými výsledky“, který je zaslán žadateli. 

Žadatel může na stav výsledků, který mu Zadavatel průběžně prezentuje, nebo na obdržené předběžné výsledky reagovat změnou žádosti, nebo zasláním důkazů rozporující vyhodnocení. Zaslané změny systém opětovně vyhodnotí a případně provede úpravu výsledků. Pokud důkazy z jejich podstaty nelze vyhodnotit systémem, budou vyhodnoceny pracovníkem Zadavatele.

U nemonitorovaných podmínek zůstává zachován princip výběru vzorku žádostí a ověření plnění podmínek přímo v terénu. Výsledky této kontroly se žadatel dozví v rámci protokolu o kontrole. Na nálezy porušení nemonitorovaných podmínek žadatel nemůže reagovat úpravou žádosti.

Oproti stávajícím kontrolám na místě se kontroly pomocí monitoringu odlišují v těchto bodech:

1. Kontroly pomocí monitoringu ověřují způsobilost všech žádostí o dotaci zvoleného opatření/platby (tj. 100 % pozemků), nejen vybraného vzorku (např. KNM ověřují obvykle min. 5 % žádostí).

2. Kontrola pomocí monitoringu je založena na průběžném vyhodnocování zemědělských aktivit, tj. na kontrole podmínek způsobilosti. Kontrola výměry vychází z údajů v LPIS a předpokladu, že kvalita LPIS zajišťuje maximální chybovost ve výměře v toleranci ± 2 %. Při kontrole pomocí monitoringu nedochází k přeměřování zemědělských pozemků, což je povinnou složkou kontrol na místě.

3. Vyhodnocení zemědělských aktivit probíhá průběžně (využívá průběžně dodávaná data Sentinel), přičemž je možné analyzovat data, která časově předcházejí podání žádosti a taktéž i data, která byla pořízena po výplatě dotace (v závislosti na podmínkách opatření/platby). Případné nesrovnalosti identifikované po výplatě finančních prostředků jsou řešeny systémem vratek.

4. Terénní šetření je omezeno pouze na nejasné pozemky, u kterých následné kontroly doplňují informace z geotagovaných fotografií, administrativních údajů, případně jiných datových zdrojů.

5. Farmáři je umožněno na základě zjištěných výsledků, které mu Zadavatel průběžně sděluje, opravit původní žádost bez rizika udělení administrativní sankce. Díky stoprocentnímu monitoringu může být sankční mechanismus, který měl odrazovat žadatele od chybné deklarace nebo neplnění podmínek, minimalizován.

6. Proces kontroly pomocí monitoringu předpokládá průběžnou komunikaci s farmářem ve formě sdílení průběžných výsledků administrace, umožnění proaktivního zasílání důkazů ze strany farmáře (typicky geotagované fotografie), nebo preventivní upozorňování farmáře na blížící se termíny nebo možná porušení ze strany platební agentury (tzv. Alerty).

3. Proces administrace žádostí – celkový pohled

V této kapitole je popsán souhrnný pohled na proces zpracování žádostí s využitím satelitního monitoringu. Tento pohled poskytuje uchazeči přehledovou informaci o celkovém řešení MACH, do něhož je jím dodávaná služba integrována.

1. Základní pojmy a jejich vztahy

Platí, že dotační program se skládá z jednotlivých opatření, některá opatření se dále dělí na podopatření a dále na tituly (např. opatření Agroenvironmentálně-klimatické opatření, podopatření Ošetřování travních porostů a titul Druhově bohaté pastviny).

Žadatel pro jednotlivá opatření/podopatření/tituly podává žádost o poskytnutí dotace. Pro většinu plošných opatření se žádost o poskytnutí dotace sdružuje do tzv. Jednotné žádosti (JŽ). Jednotná žádost agreguje žádosti o poskytnutí dotace na jednotlivá plošná opatření (nezahrnuje všechna plošná opatření, např. lesnická opatření), na podporu chovu vybraných zvířat a zlepšení životních podmínek zvířat. Využití plošného monitoringu se prozatím předpokládá pouze u vybraných plošných opatření z Jednotné žádosti. Jinými slovy v rámci Jednotné žádosti budou některá opatření kontrolována novým systémem kontrol pomocí monitoringu a některá budou kontrolována „po staru“ pomocí kontrol na místě.

Seznam plošně kontrolovaných podmínek opatření pro daný rok vydává Zadavatel.

Podáním Jednotné žádosti se žadatel zavazuje plnit podmínky pro poskytnutí dotace. Pro všechna opatření/podopatření/tituly jsou předem vydefinované podmínky, které musí žadatel splnit k získání nároku na dotaci. Některé podmínky mohou být shodné pro více opatření, jiné jsou specifické pro daná opatření/podopatření/tituly.

Podmínka může být nastavena tak, že v daném čase má k jejímu splnění dojít, nebo tak, že porušení dané podmínky (např. rozorání travního porostu) způsobí, že nárok na dotaci zanikne. Jednotlivá opatření mohou mít různou délku tzv. kontrolního období, po kterou musí plnit podmínky k poskytnutí dotace. Vyhodnocení plnění podmínky se nemusí vázat pouze na konkrétní pozemek, ale může být vázáno na více pozemků (např. na všechny trvalé travní porosty daného žadatele). V rámci kontroly plnění podmínky mohou probíhat i netriviální výpočty nad obhospodařovanými plochami, např. travní porosty nebo určitý typ plodiny musí být na určitém procentu obhospodařované půdy atd.

Základní jednotkou deklarace v Jednotné žádosti, ke které se vztahuje plnění podmínek a u které se provádí kontroly, je zemědělský pozemek. Dále v textu je pro takový pozemek použit termín agricultural parcel (AP). Platí, že agricultural parcel se musí vždy kompletně nacházet v hranicích referenčního pozemku LPIS, tj. musí být v hranicích dílu půdního bloku (DPB). Při identifikaci AP tak lze použít vazbu na DPB. Velmi často také nastává situace, kdy deklarovaný pozemek (AP) je shodný s referenčním pozemkem (DPB), nicméně při nastavování systému je třeba počítat se situacemi, kdy je deklarována jiná plocha AP, než která je evidována v LPIS jako DPB.

Vyhodnocení kontrolního nálezu (konkrétní podmínky pro konkrétní opatření) se může vztahovat pouze ke kontrolované AP nebo k žadateli.

Podmínky pro účely Veřejné zakázky a specifikace předmětu plnění jsou rozděleny na ty, jejichž plnění je monitorováno satelitními daty (tj. jedná se o podmínky uvedené na seznamu monitorovaných podmínek – zkráceně Podmínka MACH), nebo plnění podmínky monitorované není – Podmínka NEMACH.

V případech, kdy satelitní monitoring nebude schopen rozhodnout o splnění podmínky MACH na AP, musí být podmínka zkontrolována jinou formou, např. formou místního šetření, pomocí ortofota nebo na základě geotagovaných fotografií.

Geotagované fotografie může pořídit jak sám žadatel, tak terénní inspektor Zadavatele (TI). Uživatel je může pořídit na výzvu Zadavatele nebo na základě svého vlastního rozhodnutí.

Nemonitorované podmínky pak lze kontrolovat administrativně proti registrům či jiným evidencím, na základě předložených listinných důkazů, nebo kontrolou v terénu kontrola nemonitorovaných podmínek (KNP).

Nález porušení monitorované i nemonitorované podmínky může být učiněn i náhodně při kontrole opatření kontrolovaných „po staru“ pomocí kontrol na místě. I v takovém případě musí být nález zaznamenán a zohledněn při administraci, nebo musí být udělena vratka (v případě, že pro dané opatření již byla vyplacena dotace).

2. Jednotná žádost – Podání a administrace

   1. Jednotná žádost – formulář žádosti a podání žádosti

Žadatel podává Jednotnou žádost v termínu do 15. 5. (do 9. 6. se sankcí za pozdní podání).

Součástí Jednotné žádosti jsou identifikační údaje o žadateli, které jsou shodné pro všechna deklarovaná opatření. Dále Jednotná žádost obsahuje deklarace pro jednotlivá opatření, kde je uveden seznam AP/DPB, jejich výměra, kultura, případně plodiny a další informace dle druhu opatření/podopatření. Součástí jsou i geoprostorová data (zákresy AP).

Žadatel má povinnost podat žádost prostřednictvím geoprostorového formuláře (GSAA – Geo Spatial Aid Application). Pro vyplnění formuláře GSAA je možné využít (používají skoro všichni) tzv. předtiskovou aplikaci, která vygeneruje prostřednictvím datové sady v LPIS tzv. předtiskový formulář na Portálu farmáře (PF). K vytvoření datových sad a následně pro vytvoření předtiskového formuláře jsou využita data z IS Zadavatele a data z LPIS. Předtisková aplikace umožňuje geoprostorově vymezit plochy, ke kterým se vážou jednotlivé podmínky – zakreslit AP.

Po přípravě předtisku podá žadatel žádost Zadavateli, a to buď prostřednictvím Portálu farmáře, datovou schránkou, emailem s elektronickým podpisem, poštou nebo osobně. 

Pro žádosti, které nejsou vytvořeny v předtiskové aplikaci a nenesou prostorové vymezení, se vytvoří ex-post dotisk žádosti. Způsob podání je shodný jako při vytvoření předtisku. 

2. Následná administrace 

Po přijetí je žádost založena do IS Zadavatele a následně zkontrolována tzv. SW (softwarovou) kontrolou I (SWK I). Jedná se kontrolu úplnosti a správnosti podané žádosti a jejích příloh. Žadatel může být vyzván k doplnění či opravě údajů v žádosti. Doplnění a opravy žádosti provedené na základě kontroly SWK I nemají dopad na deklarované atributy argicultural parcel (AP). Po provedení této kontroly se Jednotná žádost v systému rozpadne na dílčí žádosti pro jednotlivá opatření a každé opatření je již administrováno samostatně. Termíny pro provádění následných kroků administrace se liší dle opatření. Každé opatření má definovanou svou délku kontrolního období, svůj termín vydávání rozhodnutí atd.

Před výpočtem dotace a vydáním rozhodnutí pro každé opatření probíhá SW kontrola II (SWK II), která je podporována funkcemi IS SAP. Tato kontrola kontroluje finální plnění podmínek způsobilosti a podmíněnosti – křížově (administrativní kontrola) proti registrům a LPIS a přebírá i výsledky z kontrol na místě (v terénu). K vyhodnocení všech kontrol dojde v jednom okamžiku tak, aby bylo možné vyhodnotit výsledné splnění, či nesplnění podmínek na daném AP/DPB i v případě souběhu více nálezů na stejném pozemku. 

Po provedení SWK II se provádí automaticky výpočet dotace, kde se agregují všechny nálezy a uplatňují příslušné sankce. Sankce mohou být vztažené k jednotlivým AP/DPB nebo i případně k větším celkům (např. všechny travní porosty) či k „papírovým“ dokladům (evidence, míchací protokoly apod.).

Poté se vydává pro každé opatření rozhodnutí. Všechny tyto procesy budou zachovány v prostředí IS SAP jako doposud. Do SWK II nově přibude další zdroj pochybení zjištěných kontrolou pomocí monitoringu včetně nálezů z Follow-up aktivit a nálezy z KNP. 

3. Výjimky pro plnění opatření 

V některých případech (stanoveno legislativou) nemusí být obecně platná podmínka pro danou AP/DPB směrodatná, platí pro ni tzv. výjimka.  Tyto výjimky jsou evidovány v Registru souhlasu OOP (Orgán ochrany přírody). Některé výjimky jsou známy již po podání Jednotné žádosti, resp. po jejím založení do IS Zadavatele. Většinou se jedná o souběh více opatření na jednom AP/DPB, přičemž podmínka jednoho opatření má prioritu před ostatními opatřeními. Např. žadatel žádající o dotaci na podopatření Ošetřování travních porostů má u některých titulů posunuté nejzazší termíny sečí (info je v LPIS). Tento posun seče platí následně i pro SAPS. Tento typ výjimek je součástí pravidel poskytování dotací.

Výjimky mohou být také ohlášeny žadatelem a následně ze strany Orgánu ochrany přírody povoleny. Toto povolení výjimky bude nově od 2021 vedeno v LPIS.

4.  Ohlášení vyšší moci 

V případě, kdy žadatel nedodržel podmínku z důvodu vyšší moci, může podat ohlášení vyšší moci. Tato ohlášení jsou součástí registru ohlášení vyšších mocí. Vyšší moc je následně uznána, či neuznána. V případě, kdy je vyšší moc uznána, nepočítá se nesplnění podmínky za důvod pro neposkytnutí dotace, či udělení sankce, respektive podmínka se považuje za splněnou.

5. Stažení a změna žádosti 

V období, kdy jsou žádosti kontrolovány, může dojít ke stažení žádosti, případně ke změnám žádostí. K provedení změny musí žadatel podat tzv. změnovou žádost. Změnová žádost se vytváří v LPIS – předtiskové aplikaci, kde si žadatel vytvoří datovou sadu s požadovanými změnami včetně geoprostorových informací. Pak žadatel vytvoří předtisk a žádost o změnu zašle Zadavateli, stejným způsobem jako při podání Jednotné žádosti. V případě, kdy žadatel nevyužije vytvoření předtisku v předtiskové aplikaci a vytvoří změnovou žádost jiným způsobem, pracovník Zadavatele vytvoří tzv. ex-post předtisk. 

Ke změnám žádostí může dojít kdykoliv v průběhu kontrolního období. Je předem vydefinováno, které změny, a do jakého termínu podané je možné provést (akceptovat). Po zadání změnové žádosti do IS Zadavatele pracovník Zadavatele přijme, či zamítne změnu dle stanovených kritérií. V případě přijetí změny se změna propíše do IS Zadavatele do původní deklarace žádosti a do vrstvy GSAA v LPIS. Při všech následných kontrolách včetně kontroly pomocí monitoringu je nutné vždy pracovat s aktuálními údaji, tedy údaji po provedené změně.

6.   Kontrola podmínek v terénu 

   1. Typy kontrol

Nařízení komise č. 809/2014 definuje dva rozdílné přístupy, jak ověřit plnění podmínek pro poskytnutí dotace v terénu. Jedná se:  

• Systém kontrol na místě (KNM) založený na fyzické kontrole na místě (FKNM). KNM se provádí na vzorku 5 % žádostí. Součástí FKNM je i měření plochy. KNM se provádí u opatření, kde nelze provádět kontrolu monitoringem.

• Systém sledování plochy (dále kontrola pomocí monitoringu) založený primárně na využívání automatického vyhodnocení družicových dat Sentinel.  Provádí se u opatření, kde je alespoň jedna podmínka kontrolována vyhodnocením družicových dat (SAMAS).  Množina kontrolovaných podmínek se může v průběhu let měnit, stejně tak se mohou upravovat používané algoritmy.

V systému sledování plochy se podmínky pro poskytnutí dotace dále dělí do dvou skupin:

• Podmínky monitorované – podmínky, jejichž plnění je v daném období ověřováno na základě dat družicových snímků, jsou kontrolované na úrovni jednotlivých AP pomocí dat z družice Sentinel (kontrola službou SAMAS). V případě, kdy je podmínka monitorovaná, ale z nějakého důvodu ji u dané AP nelze vyhodnotit, provádí se Follow-up aktivita, a to prostřednictvím doložených geotagovaných fotografií, ortofota, nebo místním šetřením – polní návštěva (PN). Součástí dokumentace kontrol založených na fyzické kontrole na místě je pořízení geotagovaných fotografií terénním inspektorem.

• Podmínky nemonitorované – podmínky, jejichž plnění není ověřováno na základě dat družicových snímků – kontrola nemonitorovaných podmínek (KNP). Jedná se o obdobu již dříve používaných kontrol na místě (KNM), nicméně se neměří plocha.

2. Výběr ke kontrole

KNM – princip bude shodný jako doposud – výběr vzorku 5 % příjemců kontrolovaného opatření/platby. Výběr je prováděn hromadně na základě náhodného výběru i na základě definovaných kritérií (rizikových faktorů). Nad rámec 5% vzorku jsou žadatelé vybíráni také manuálně cíleným výběrem.  Některé kontroly podmínek jsou předmětem delegování na jiné rezortní organizace. Pro tyto účely Zadavatel využívá v rámci KNM mezisklad zpráv o kontrole na MZe, kam zasílá po výběru ke kontrole plán kontrol a jehož prostřednictvím se vrací i výsledky kontrol (Zprávy o delegované kontrole – ZoDK) zadané příslušnou delegovanou organizací.  Výběr pro KNM probíhá a bude probíhat v IS SAP.

KNP – proces výběru ke kontrole nemonitorovaných podmínek (KNP) bude do značné míry shodný s výběrem ke kontrole na místě.  Bude se vybírat 5 % příjemců monitorovaného opatření/platby, a to na základě náhodného výběru i na základě definovaných kritérii (rizikových faktorů). Nad rámec 5% vzorku budou žadatelé vybíráni také manuálně cíleným výběrem. Kontroly některých podmínek budou také delegovány na jiné resortní organizace. Výběr pro KNP bude probíhat také ve stávajícím informačním systému Zadavatele na platformě SAP.

Kontrola SAMAS – neprovádí se výběr ke kontrole, ani plánování kontroly. Kontrola probíhá u 100 % příjemců, s výjimkou AP, které satelitem nelze kontrolovat pro jejich velikost nebo tvar.

Follow-up aktivita – probíhá u těch AP, pro které kontrola monitoringem nedala jednoznačný závěr a zároveň je AP finančně významná. Proto procesu výběru u tohoto typu kontroly předchází výpočet finančního dopadu možného porušení podmínky při označení dané AP výsledkem žlutý.  Stanovení finančního dopadu se počítá na úrovni AP a zároveň se sčítá na úrovni žadatele, tedy počítá se všemi monitorovanými dotačními tituly na všech AP daného žadatele. Stanovení intervalů EUR pro určení významnosti finančního dopadu může EK ještě upravit.

V případě, že je vypočten významný dopad (více než 250 EUR), bude se vybírat 100 % k Follow-up aktivitě. S vypočteným středním dopadem (více než 50 EUR) se bude vybírat automaticky 5 % AP k Follow-up aktivitě, a to jak náhodně, tak i na základě definovaných kritérií (rizikových faktorů). V případě nevýznamného dopadu (méně než 50 EUR) a nevybraných AP se středním dopadem bude Follow-up aktivita prováděna prostřednictvím kontroly existujících geotagovaných fotografií. Pokud nepůjde z pořízené GEOTAGOVANÉ FOTOGRAFIE podmínka vyhodnotit, nemusí se v případě nevýznamného dopadu provádět žádné další aktivity k potvrzení konečného výsledku splnění, či nesplnění podmínky. V tomto případě může také zůstat kontrola podmínky bez konečného výsledku.

Pro KNP i KNM je klíčem výběru žadatel, který je vybrán ke kontrole, se kterým je kontrola zahájena a kterému bude následně předán protokol o kontrole. Pro Follow-up aktivity je jednotkou výběru AP.

3. Plánování kontrol

Proces plánování kontroly lze rozdělit na 4 kroky:

1. Plánování v Zásobníku I – Zásobník I je prostředí, ve kterém se zobrazují všechny založené kontroly (KNM, KNP, aktivity Follow-up), které jsou připravené k naplánování. Tato tabulka obsahuje celou řadu atributů, které je možné filtrovat. U KNM a KNP se budou data dotahovat z IS Zadavatele. U Follow-up aktivit budou údaje již v IS MACH. S tabulkou budou dynamicky propojené mapy (mapové okno).  Vybírat kontroly pro další práci půjde buď zaškrtnutím v tabulce Zásobníku I nebo výběrem více řádků najednou nebo v mapě geoprostorovými výběry. V druhé fázi projektu rámci zefektivnění plánovacího procesu, který dnes probíhá ručně, požaduje Zadavatel, aby poskytovatel navrhl algoritmy, které dle zadaných pravidel (která bude možno uživatelsky měnit) vygenerují návrh seznamu kontrol k realizaci včetně přiřazení inspektorů. 

2. Plánování v Zásobníku II – Zásobník II je prostředí se seznamem kontrol vybraných v Zásobníku I. Slouží k naplánování kontrol. Ke kontrole se přiřadí inspektoři a stanoví se termín plánovaného zahájení kontroly. Struktura tabulky je shodná jako u Zásobníku I, navíc jsou pouze údaje o přiřazených inspektorech a o termínech kontroly. Po naplánování proběhne systémová kontrola naplánování, která prověří všechna pravidla pro plánování (např. kontrola rotace inspektorů, souběh více kontrol atd.). Dále se odešle naplánování ke schválení vedoucímu oddělení, případně se žádá o schválení výjimek z pravidel plánování na centrálním pracovišti.  Dynamická vazba na mapové okno bude existovat i u Zásobníku II, tj. bude možno dělat výběry jak v tabulce, tak geoprostorové v mapě, pro samotné plánování kontrol. 

3. Schvalování výjimek na centrálním pracovišti – schválení nebo neschválení výjimek z pravidel plánování kontrol bude prováděno pracovníkem centrálního pracoviště. Sloupce tabulky budou shodné se Zásobníkem II. Navíc zde budou sloupce Druh výjimky a Zdůvodnění výjimky. Mapové okno není nutné. 

4. Schvalování naplánování vedoucím oddělení – na závěr se naplánované kontroly odešlou ke schválení naplánování vedoucímu oddělení. Vedoucí oddělení bude mít možnost provést systémovou kontrolu plánu. Dynamické mapové okno bude přítomno i zde. Sloupce tabulky budou shodné se schvalováním výjimek na centrálním pracovišti včetně upozorňujících hlášení. 

4. Provádění kontrol

Proces kontrol se skládá z přípravy kontroly, realizace kontroly, zadání výsledků a jejich schválení KI (kontrolní inspektor) a VOIS (vedoucí oddělení inspekční služby). Dále v případě KNM a KNP může nastat ještě řízení o námitkách, kdy se kontroly v IS vrací zpět k řešení příslušnému pracovníkovi Zadavatele. V rámci těchto procesů je nutné pracovat s aktuálními daty. Je tedy nezbytné mít nastavenou komunikaci se: základními registry, s Business Partnerem, s údaji v žádosti, s údaji v LPIS a jinými registry, využívání meziskladu MZe a napojení na podatelnu.

U KNM je již tato komunikace nastavena. Ze stejných principů bude vycházet i KNP.  Provedení kontrol KNM (kontrola na místě) a KNP (kontrola nemonitorovaných podmínek) a zpracování výstupů bude využívat stávající implementaci KNM v IS SAP a v LPIS. U Follow-up aktivit bude vytvořeno nové prostředí.

KNM – bude probíhat dle stávajících principů. Jsou vytvořeny kontrolní listy, které slouží pro přípravu, realizaci a zadání výsledku z kontroly na místě a řízení o námitkách.

KNP – ověření plnění nemonitorovaných podmínek je shodné s ověřováním prováděným v rámci kontrol na místě. Rozdíl je pouze v tom, že se v rámci kontroly nemonitorovaných podmínek neprovádí ověřování způsobilé plochy. Pokud při KNP inspektor zjistí nezpůsobilou plochu, musí ji v rámci KNP změřit; dále musí zaznamenat i porušení monitorované podmínky, pokud porušení nebylo zjištěno MACH a je zároveň období, kdy podmínka má být plněna či splněna.

Follow-up aktivity – tyto aktivity se mohou provádět buď v terénu – tzv. Polní návštěva (PN) nebo prostřednictvím ověřování geotagovaných fotografií, kdy bude žadatel vyzván k dodání nebo se ověří již existující geotagované fotografie. Nové prostředí umožňuje uživateli zobrazení přidělených Follow-up aktivit, jejich naplánování, zpracování, přípravu podkladů na výjezd do terénu.  Zároveň poskytuje uživateli nástroje pro zaznamenání výsledků Follow-up aktivit, zejména nastavení hodnoty semaforu pro AP a danou podmínku. Dále bude možné propojení s mobilní aplikací pro pořizování geotagovaných fotografií.  Kromě seznamu bude součástí interaktivní mapa.

Kontrola SAMAS – principy kontroly jsou popsány níže (kontroly pomocí satelitu).

3. Komunikace se žadatelem při kontrole monitorováním 

Komunikace mezi žadatelem a Zadavatelem je vícekanálová a kontinuální – Portálový systém SZIF, mobilní aplikace služby GT FOTO, datové schránky, osobní komunikace s regionálními pracovišti nebo s inspektory Zadavatele.  Uživatel je průběžně informován o postupu vyřizování svých žádostí a o stavu kontroly plnění podmínek opatření, na která žádal.

Hlavním nástrojem kontinuální komunikace se žadatelem je Portálový systém SZIF, který čerpá aktuální data z databáze IS MACH. Žadatel je v průběhu celého období, kdy probíhá monitoring, informován o stavu plnění monitorovaných podmínek na daných AP, na které žádal dotace. Žadatel má informaci, jaký je stav plnění podmínky k určitému datu. Žadatel může dodat vlastní podklady, které přispějí ke konečnému vyhodnocení plnění podmínek na AP. Také může změnit žádost nebo ji vzít zpět. 

Žadatel může také sám iniciovat komunikaci se Zadavatelem zasláním dokumentů prostřednictvím Portálového systému SZIF nebo zasláním geotagovaných fotografií prostřednictvím služby GT FOTO. 

1. Scoreboard

Informace se stavy podmínek k jednotlivým AP (hodnoty semaforu) budou zobrazeny v rozsahu oprávnění přihlášeného žadatele na Portálovém systému SZIF v přehledné tabulce tzv. scoreboardu. U každé AP bude zaznamenán stav plnění podmínek. Stav plnění bude zároveň agregován na úrovni DPB a na úrovni jednotlivých dotačních titulů. U monitorovaných podmínek, u kterých je to relevantní, bude možné vyvolat graf (časovou řadu) vyhodnocovaných hodnot ze satelitních dat.

Scoreboard se vytvoří hned po načtení žádosti do IS MACH a bude se aktualizovat hned po každé změně AP v rámci GSAA, včetně informace o zapracované změně. Bude možné zobrazit historii změn stavů. Scoreboard bude obsahovat proklik na vytvoření změnové žádosti v předtiskové aplikaci či žádosti o zpětvzetí.

Scoreboard se také aktualizuje, jakmile dojde ke změně výsledků kontrol pro danou AP, nebo když k ní bude zadaný požadavek na geotagované fotografie, případně pořízená geotagovaná fotografie nebo bude Zadavatelem akceptována výjimka či vyšší moc.

Informace na Scoreboardu budou zobrazovány jak na úrovní celé žádosti, tak i pro jednotlivé AP:

• Informace celá žádost – číslo žádosti, datum podání žádosti, přijetí změnové žádosti, přijetí ohlášení vyšší moci, stav semaforu na úrovni jednotlivých dotačních titulů. Informace o blížících se důležitých termínech.

• Informace k AP – jednoznačný identifikátor AP, výměra AP, plodina, opatření/podopatření (SAPS, EZ atd.), monitorovaný scénář, stav semaforu u jednotlivých podmínek, datum, kdy se hodnota semaforu změnila, přijetí ohlášení vyšší moci nebo výjimky, informace o změně žádosti. Dále kód dílu půdního bloku (DPB) (popř. zbytková plocha – kód), výměra způsobilé plochy, kultura DPB.

Scoreboard vhodným způsobem integruje mapové okno tak, aby bylo možné z úrovně AP zazoomovat a zvýraznit dané AP v mapovém okně, kde bude AP zobrazena v kontextu s dalšími daty, která poskytuje Ministerstvo zemědělství z LPIS (MZe), Ortofoto (ČÚZK) atd.  Zároveň bude k dispozici služba, která dodá data pro mapovou službu, zobrazující, kde byly identifikovány nehomogenní plochy, které způsobily nesplnění podmínky (stejná služba popsána v kapitole Přenos dat ze SAMAS do LPIS).

Další informací u jednotlivých AP bude informace týkající se geotagovaných fotografií: existuje pro AP požadavek na dodání geotagovaných fotografií od žadatele, případně, že je k dané AP geotagovaná fotografie již pořízena. Geotagované fotografie půjde zobrazit v mapovém okně v kontextu AP. Více ke geotagovaným fotografiím uvádí samostatná kapitola dále.

Současně bude možné k jednotlivým AP nahrát různé dokumenty a doplňující informace.  Ke každé AP si bude moci žadatel přidat místní název a poznámku.

Na scoreboardu u každého DPB (AP) bude odkaz do předtiskové aplikace, kde si žadatel bude moci vytvořit změnovou žádost, či provést zpětvzetí.  Možnost podat změnu bude umožněna pouze do konečného termínu pro podání změny.

Současně bude možné přímo ze scoreboardu proklikem podat stažení DPB ze žádosti (je součástí změnové žádosti) nebo celé žádosti.  Stažení musí být umožněno i po konečném termínu pro změnu, resp. až do vydání rozhodnutí o poskytnutí/zamítnutí dotace.

2. Zasílání alertu (upozornění) žadateli

V některých případech (dle typu podmínky plnění) se budou žadateli zasílat tzv. alerty (upozornění). Cílem těchto alertů je upozornit žadatele, že se pro danou podmínku blíží termín plnění, a zároveň ho informovat, co má provést, aby podmínka byla splněna. Alert se bude zobrazovat automaticky v Portálovém systému SZIF a zároveň bude zasílán žadateli emailem. Kritéria pro zasílání alertu budou založena na stavu semaforu vůči blížícímu se datu plnění podmínky relevantní k dané AP.  Jedná se o upozornění, od žadatele není očekávána žádná odpověď. Alerty se budou zasílat buď hromadně anebo pro jednotlivé AP. Některé alerty bude moci uživatel filtrovat nebo si ve svém profilu nastavit předstih před termínem, ve kterém mu má být alert zaslán, ale bude existovat skupina alertů, které nebude možné potlačit ze strany uživatele.

3. Zaslání žádosti o spolupráci

V případě, kdy u dané AP vyšla kontrola monitoringu (semafor) žlutě a po výpočtu finančního dopadu byl u dané AP založen objekt Follow-up aktivity, pracovník Zadavatele rozhodne, zda bude žadateli zaslána žádost o spolupráci, či nikoliv.

Součástí žádosti je automaticky dotažený text stanovený dle konkrétní podmínky. Ve výzvě je žadatel požádán o konkrétní spolupráci s cílem jasně určit konečný stav plnění podmínky. Výzva bude zobrazena na scoreboardu, objeví se provazba v aplikaci na geotagované fotografie a zároveň bude zaslána žadateli emailem.

4. Dokument s předběžnými výsledky

Po ukončení kontrol monitoringem se bude automaticky generovat pro jednotlivé dotační opatření/tituly dokument s předběžnými výsledky. Pravidla, kdy je kontrola ukončena, stanoví každoročně metodik Zadavatele.

V dokumentu bude přehled DPB (popř. AP) a informace o výsledku monitoringu pro daný dotační titul/tituly. Součástí dokumentu bude informace, že Zadavatel dokončil kontrolu pomocí monitoringu. V dokumentu bude poučení, jak a do kdy může žadatel reagovat na nesplnění podmínky (červené semafory). Dokument bude opatřen časovým razítkem a kvalifikovanou elektronickou pečetí, bude mu přiděleno číslo jednací a bude založen do spisu žádosti v rámci spisové služby Zadavatele.

Žadateli bude odeslán dokument s předběžnými výsledky dle pravidel doručování dokumentů Zadavateli, tzn. buď prostřednictvím datové schránky, nebo prostřednictvím Portálového systému SZIF, a zároveň daný žadatel obdrží notifikaci do emailu. Tuto notifikaci nebude možné vypnout.

4. Geotagované fotografie

   1. Pořízení a odeslání geotagovaných fotografií

Pořízení geotagované fotografie probíhá prostřednictvím mobilní aplikace služby GT FOTO. Uživatel může pořizovat geotagované fotografie buď na základě založeného úkolu ze strany Zadavatele, nebo může pořizovat geotagované fotografie ve „volném režimu“ bez vazby na úkol. Pro každou fotografii bude možné zadat parametry úkolu (např. poloha, směr, typ). Úkoly budou zadávány ze strany Zadavatele prostřednictvím webového klienta. Pro žadatele budou viditelné v mobilní aplikaci a na Portálovém systému SZIF.

2. Ukládání geotagovaných fotografií

Pořízenou geotagovanou fotografii nebude možné editovat ani měnit.  Geotagované fotografie budou uloženy včetně všech metadat (časové razítko, souřadnice, azimut, uživatelský účet, zařízení, informace o kalibraci zařízení, přesnost polohy, počet satelitů, popř. další zdroje polohy, …). Fotografie nepůjde z mobilu exportovat, jediný přístup k němu bude mít mobilní aplikace pro prohlížení a synchronizační služba, která foto bude odesílat na úložiště služby GT FOTO.  Fotografie, které vedly ke změně semaforu (fotografie označené pracovníkem Zadavatele) budou uloženy včetně metadat v IS Zadavatele a archivovány po dobu 10 let. 

Mobilní aplikace – hlavní funkce jsou:

• Pořízení geotagovaných fotografií, při kterém bude hlídána kvalita správnost pořizované fotografie. Pořizovat fotografie bude možné i mimo „režim úkolu“ na základě vlastního rozhodnutí uživatele. K fotografii bude možné uložit komentář.

• Mapová prohlížečka zobrazující podkladová data s vyobrazením jednotlivých úloh. 

• Přehled úkolů s vazbou na již pořízené fotografie.

• Navigace na bod výběrem bodu v rámci úkolu. Kolem každého bodu bude zvolen vhodný buffer, do kterého se musí žadatel dostat, jinak mu aplikace neumožní splnit konkrétní úlohu.

3. Vyhodnocení geotagovaných fotografií a jejich správa v IS Zadavatele

Automatické vyhodnocení kvality – bude v základní verzi probíhat již v mobilní aplikaci. Po odeslání geotagované fotografie se znovu automaticky zkontroluje v úložišti služby GT FOTO její kvalita. Pokud bude nevyhovující, otevře se znovu úloha a žadatel bude požádán o pořízení nové fotky.

Automatické vyhodnocení obsahu – bude nastaven mechanismus, který zajistí automatické vyhodnocení obsahu fotografie. Pakliže automat bude schopen stanovit, zda se na snímku nachází konkrétní plodiny, lze na něm rozpoznat provedenou zemědělskou operaci a podobně, nebude již nutné fotografii manuálně prohlížet, a ta bude automaticky uložena v úložišti služby GT FOTO. Zároveň bude v jejích atributech označeno, že prošla automatickým vyhodnocením a bude zaznamenán výsledek tohoto vyhodnocení.

Manuální vyhodnocení obsahu fotografie – manuální vyhodnocení provádí pracovník Zadavatele, který bude mít k dispozici všechny fotografie, které již předtím prošly automatickým vyhodnocením kvality i obsahu službou GT FOTO. Pracovník Zadavatele na základě fotografií může změnit semafor pro danou AP a kontrolovanou podmínku.  V případě, že fotografie nebudou průkazné, musí pracovník Zadavatele zajistit nové důkazy – opět požádá žadatele o novou fotografii nebo bude provedeno místní šetření.

4. Vyhodnocení přesnosti automatického vyhodnocení geotagované fotografie

Pro prověření správného nastavení automatického vyhodnocení obsahu fotografií službou GT FOTO musí probíhat validace výsledků algoritmů.  Ve speciálním uložišti bude uloženo určité procento vyhodnocených snímků s různými výsledky vyhodnocení. Tyto fotografie pak bude nutné manuálně posoudit a vyhodnotit úspěšnost daného algoritmu.

9. Pojmy a zkratky

Pojmy a zkratky použité v tomto dokumentu jsou definované v Příloze č. 9 Smlouvy, která je nedílnou součástí Zadávací dokumentace jako její Příloha č. 1.