1. ÚČEL A ROZSAH PLATNOSTI

Účelem tohoto dokumentu je upřesnit pravidla a postupy stanovené v dokumentu Realizace resortních potřeb.

Dokument slouží jako podpůrný materiál pro realizaci a administraci resortních výzkumných potřeb. Informace obsažené v něm slouží také jako nápovědný systém v Informačním systému realizace BETA3 (ISRB3) a Sdíleném informačním systému Technologické agentury ČR (SISTA).

2. OBECNÉ

Přístup uživatelů do ISRB3 je na adrese https://isrb3.tacr.cz nebo odkazem z hlavní stránky SISTA. Oprávnění přístupu do ISRB3 jsou centrálně ověřována v SISTA. Proto se pro přihlášení uživatelů do ISRB3 uživateli zobrazí přihlašovací obrazovka SISTA a po úspěšném přihlášení je uživatel přesměrován do prostředí ISRB3. Uživatel k přihlášení může využívat jednu ze tří metod:

  • kombinaci jméno/heslo,

  • Google identit,

  • identitu NIA (např. přes bankovní identitu uživatele).

2.1. Správa uživatelů a role v IS

Všechny základní informace jsou uvedené v dokumentu Realizace resortních potřeb. Tento dokument neobsahuje další podrobnosti ke správě uživatelů a rolí v IS. Podrobnosti jsou uvedeny v dokumentu Role v BETA3.

2.2. Řízení procesu

TVORBA ID: Každá potřeba má v průběhu administrace daný jedinečný identifikátor. Rozlišujeme 3 druhy ID:

  • ID Potřeby: Vzor ID vypadá následovně – TTMZP0021, kdy TT = kód programu BETA3; MZP = zkratka resortu; 0021 = pořadové číslo potřeby na resortu.

  • ID Projektové Přípravy: Vzor ID vypadá následovně – TTXMZP428, kdy TT = kód programu BETA3; X = PP (ještě není určený druh VZ); MZP = zkratka resortu; 4 = rok, ve kterém PP vznikla (2024); 28 = pořadové číslo PP v daném roce (28. PP v roce 2024).

  • ID Veřejné Zakázky a PRojektu: Vzor ID vypadá následovně – TTSMZP428, kdy TT = kód programu BETA3; S = druh VZ (zde soutěžní dialog); MZP = zkratka resortu; 428 = trojčíslí zůstává stejné jako PP.

WORKFLOW: Pro lepší přehlednost je další text tohoto dokumentu dělený dle jednotlivých procesů a podprocesů (workflow) s konkrétními kroky. Grafická zpracování jednotlivých workflow jsou uvedena na začátku každé kapitoly, která obsahuje popis procesu. Ve workflow má každá skupina rolí (profil) jedinečný piktogam.

  • role za resort - jsou označeny zeleně

  • role za TA ČR - jsou označeny červeně

  • Odborný Konzultant - je označen modře

  • role za příjemce podpory - jsou označeny žlutě

KROKY WORKFLOW: Každý krok má své jedinečné označení. Označení jednotlivých kroků se skládá obvykle z těchto komponent:

  • kód kroku - např. 1.0, 3.2, 17.23, K5.0 apod.

  • název kroku - např. Úprava potřeby, Schvalování, Jednání PřTA apod.

  • zkratka role - např. (KU), (PM), (OK)

ÚKOLY: S jednotlivými kroky workflow jsou spojené úkoly. Při posunu workflow do jiného kroku, je dané roli přidělen úkol. Až daná role vypořádá přidělený úkol, posune workflow do dalšího relevantního kroku. Součástí úkolu je podrobný popis toho, co má daná role v daném kroku udělat.

FORMULÁŘE: V IS zaznamenáváme všechny informace do tzv. formulářů. Uživatel v rámci své práce vyplňuje informace a data do různých polí. Jednotlivá pole jsou nastavena tak, aby vedla uživatele ke správnému záznamu (např. pole se seznamem dat, číselná pole – možnost zadat jenom číslo apod. U každého pole je uvedena konkrétní nápověda s pokyny, návodem nebo dalšími podpůrnými informacemi pro vyplnění daného pole.

3. PŘISTOUPENÍ DO PROGRAMU

Všechny informace jsou uvedené v dokumentu Realizace resortních potřeb. Tento dokument neobsahuje další podrobnosti.

4. POTŘEBA

1000

Formulář návrhu výzkumné potřeby, který slouží jako podklad pro interní práci s návrhem potřeby uvnitř resortu. Data musí být následně vyplněna v ISRB3.

START: Potřebu zakládá Zástupce Odborného Gestora. Rozlišujeme 2 druhy potřeb:

  • “Nová potřeba” - pro všechny potřeby vyjma tzv. minitendrů,

  • “Nový minitender” pro potřeby v rámci aktivní rámcové dohody.

Osoba zakládající novou potřebu vyplní minimálně Konečného Uživatele a „Název potřeby krátký“. Poté systém vygeneruje záložku „Nástěnka a akce“, kde má ZOG aktivní tlačítko „Spustit workflow“. Po jeho stisknutí se nastartuje workflow do kroku 0.0. Kontrola před iniciací (ZOG).

0.0 Kontrola před iniciací (ZOG): Zástupce Odborného Gestora může definovat potřebu, nebo tuto aktivitu předá na Konečného Uživatele. Následně zkontroluje, případně upraví informace o potřebě. Zkontroluje, případně upraví přiřazení konkrétních osob v rolích za resortní uživatele. Potřebu může vrátit Konečnému Uživateli k přepracování/doplnění. Když je potřeba definovaná, odešle ji do Zásobníku potřeb.

0.1 Úprava potřeby (KU): Konečný Uživatel definuje, případně upravuje potřebu.

ZÁSOBNÍK: Definované potřeby jsou jednotlivými resorty předkládány na TA ČR předáním potřeby do Zásobníku. Potřeby resortu jsou v “Zásobníku” řazeny dle priorit resortu. Prioritu, tedy pořadí, dle kterého budou potřeby ze Zásobníku vybírány, určuje Zástupce Odborného Gestora. Ten má možnost změnit prioritu potřebě po celou dobu, kdy je potřeba v Zásobníku.

Od tohoto okamžiku je možné zahájit na potřebě STORNO (viz 7, STORNO).

1.0 Kontrola (PM): Projektový Manažer se seznámí s potřebou a zahájí komunikaci.

2.0 Přiřazení Odborného Konzultanta (ORLP): Odborného Konzultanta, jako externího zástupce TA ČR, přiřazuje k potřebě pracovník Oddělení Rozvoje Lidského Potenciálu (ORLP). Při výběru vhodného Odborného Konzultanta spolupracuje s Projektovým Manažerem, který může toto konzultovat s resortem. K potřebě může být přiřazen jeden nebo více Odborných Konzultantů, z nichž jeden je určen jako hlavní. Odborného Konzultanta je možné v průběhu řešení výzkumné potřeby měnit dle potřeb ve všech částech procesu.

3.0 Koordinace (PM): Projektový Manažer koordinuje vyhodnocení potřeby. Nejprve svolá schůzku projektového týmu (PM+KU+OK), na které se tento domluví na dalším postupu v přípravě potřeby. Předává potřebu k úpravám a vyjádřením. Upravit potřebu může Konečný Uživatel, Odborný Konzultant i Projektový Manažer. Ten upravuje potřebu pouze v případě, že obdrží jasný požadavek od Konečného Uživatele nebo Odborného Konzultanta. Potřebu vyhodnocuje výhradně Odborný Konzultant.

3.1 Úprava potřeby (KU): Konečný Uživatel má možnost potřebu upravit, zkontrolovat ji a vyjádřit se k ní.

3.2 Vyhodnocení potřeby (OK): Odborný Konzultant má možnost potřebu upravit. Nakonec potřebu vyhodnotí a navrhne další postup. Rozlišujeme tyto možnosti:

  • ANO: potřeba bude dále řešena samostatně

  • ANO+: potřeba bude sloučena s jinou potřebou, tato potřeba bude hlavní

  • ANO-: potřeba bude sloučena s jinou potřebou, tato potřeba bude vedlejší

  • STORNO: potřeba není vhodná k realizaci, bude zrušena

  • JINAK: potřeba bude řešena jiným způsobem

4.0 Schválení resort (ZOG): Zástupce Odborného Gestora se zásadně vyjadřuje k návrhu potřeby. Má možnost:

  • souhlasit s návrhem potřeby a předat ji Vedoucímu Beta ke schválení,

  • vrátit potřebu k přepracování,

  • požádat o pozastavení procesu a vrácení potřeby do Zásobníku,

  • zahájit na potřebě STORNO (viz 7, STORNO).

5.0 Schválení TA ČR (VB): Vedoucí Beta rozhoduje o dalším postupu a uzavírá část procesu Potřeba. V nejasných případech může konzultovat svůj postoj s Předsednictvem TA ČR. Má možnost:

  • souhlasit s návrhem potřeby, finálně ji schválit a vytvořit projektovoupřípravu,

  • vrátit potřebu k přepracování,

  • vrátit potřebu do Zásobníku, poté, co o toto požádal Zástupce odborného Gestora,

  • zahájit na potřebě STORNO (viz 7, STORNO).

KONEC: Návrh potřeby je dokončen. Potřeba je uzavřena.

5. PROJEKTOVÁ PŘÍPRAVA

1000

START: Projektovou přípravu zakládá Vedoucí Beta poté, co uzavřel část Potřeba.

6.0 Koordinace (PM): Projektový Manažer koordinuje stavbu projektu. Účastní se schůzek projektového týmu ke “stavbě projektu”. Předává projektovou přípravu k úpravám a vyjádřením. Tvořit a upravovat projektovou přípravu může Konečný Uživatel, Odborný Konzultant i Projektový Manažer. Ten upravuje projektovou přípravu pouze v případě, že obdrží jasný požadavek od Konečného Uživatele nebo Odborného Konzultanta.

6.1 Stavba projektu (OK): Odborný Konzultant se účastní schůzek projektového týmu ke “stavbě projektu”. Navrhuje možnosti řešení. Podílí se na definování těch částí projektové přípravy, které mají souvislost s budoucím projektem z projektového hlediska. Zaměřuje se zejména na definici výsledků, harmonogramu, činností, ostatních přímých nákladů, popisu výzkumných činností apod.

6.2 Stavba projektu (KU): Konečný uživatel se účastní schůzek projektového týmu ke “stavbě projektu”. Navrhuje možnosti řešení. Podílí se na definování těch částí projektové přípravy, které mají souvislost s budoucím projektem z obecného hlediska a částí souvisejících s budoucími aktivitami resortu. Zaměřuje se zejména na definici cílů projektu, vypořádání podobností, vazby, uživatele výsledků a implementaci apod.

6.3 Parametry VZ (PVZ): Poté, co je budoucí projekt připraven, definuje Právník VZ parametry a kvalifikační podmínky veřejné zakázky. Projektový tým se může k těmto podmínkám vyjádřit a navrhnout úpravy.

6.4 Konzultace (VB): Projektový Manažer konzultuje s Vedoucím Beta rozpracovanou projektovou přípravu. Vedoucí Beta dává doporučení k úpravám a navrhuje druh zadávacího řízení.

7.0 Schválení resort (ZOG): Zástupce Odborného Gestora se zásadně vyjadřuje k přípravě projektu. Má možnost:

  • souhlasit s přípravou projektu a předat ji Vedoucímu Beta k vyjádření,

  • vrátit projektovou přípravu k přepracování,

  • zahájit STORNO (viz 7, STORNO).

8.0 Schválení TA ČR (VB): Vedoucí Beta se zásadně vyjadřuje k přípravě projektu. Má možnost:

  • souhlasit s přípravou projektu a předat ji k rozhodnutí Předsednictvu TA ČR,

  • vrátit potřebu k přepracování,

  • zahájit STORNO (viz 7, STORNO).

9.0 Materiál pro PřTA (PM): Projektový Manažer připraví materiál na jednání Předsednictva TA ČR. Zajistí zařazení materiálu na nejbližší jednání Předsednictva TA ČR.

10.0 Jednání PřTA (VB): Vedoucí Beta představí připravený projekt předsednictvu TA ČR. Předsednictvo TA ČR poté rozhodne. Má tyto možnosti:

  • schválit připravený projekt k vyhlášení veřejné zakázky,

  • vrátit projektovou přípravu k přepracování s doporučením,

  • zamítnout vyhlášení veřejné zakázky a nařídit STORNO (viz 7, STORNO).

11.0 Příprava na vyhlášení VZ (PVZ): Poté, co Předsednictvo TA ČR schválí připravený projekt k vyhlášení veřejné zakázky, Právník VZ uzavírá část procesu Projektová příprava.

KONEC: Projektová příprava je dokončena.

6. VEŘEJNÁ ZAKÁZKA

6.1. Veřejná zakázka

1000

START: Veřejnou zakázku zakládá Právník VZ poté, co uzavřel část Projektová příprava.

TVORBA DOKUMENTACE: Ve veřejné zakázce může docházet k tvorbě dokumentace i opakovaně v závislosti na druhu zadávacího řízení. Kroky 12.0–13.0 jsou určeny pro vznik dokumentace související s prvotním vyhlášením zadávacího řízení. Kroky 19.0–21.0 jsou určeny pro navazující výzvy u specifických (jednacích) druhů zadávacích řízení. Do těchto kroků se dostává veřejná zakázka po jednání komise.

12.0 Příprava ZD (PVZ): Právník VZ připraví prvotní zadávací dokumentaci v návaznosti na druhu vyhlašovaného zadávacího řízení, a předá ji Vedoucímu Beta ke kontrole. V případě, že je vyhlašovaným zadávacím řízením tzv. přímé zadání, dříve, než připraví zadávací dokumentaci, zpracuje informaci o záměru takovou zakázku vyhlásit, a předá ji Projektovému Manažerovi. Zadávací řízení je pak vyhlášeno až po uplynutí doby pro zveřejnění záměru.

12.1 Kontrola ZD (VB): Vedoucí Beta zkontroluje obdržené dokumenty a schválí je, případně je vrátí Právníkovi VZ k přepracování.

12.2 Konzultace (PM): Projektový Manažer zajistí zveřejnění informace o záměru vyhlásit zakázku tzv. přímým zadáním na webu TA ČR, případně jinak asistuje Právníkovi VZ při tvorbě zadávací dokumentace.

13.0 Podpis ZD (U): Schválenou zadávací dokumentaci zpracuje Uploader ve spisové službě a zajistí podpis Vedoucího Beta. Toto je zároveň poslední krok, kdy je možné potřebu stornovat (viz 7, STORNO)

19.0 Projektová příprava v kole (PM): Po jednání komise s účastníkem/účastníky koordinuje Projektový Manažer úpravu projektové přípravy v návaznosti na druhu a fázi, ve které se zadávací řízení nachází. Předává projektovou přípravu k úpravám a vyjádřením. Tvořit a upravovat projektovou přípravu může Konečný Uživatel, Odborný Konzultant i Projektový Manažer.

19.1 Konzultace (KU): Projektový Manažer může požádat o úpravu projektové přípravy Konečného Uživatele, a ten úpravu provede.

19.2 Konzultace (OK): Projektový Manažer může požádat o úpravu projektové přípravy Odborného Konzultanta, a ten úpravu provede.

20.0 Příprava výzvy (PVZ): Právník VZ připraví výzvu účastníkovi/účastníkům v závislosti na druhu a fázi, ve které se zadávací řízení nachází. Může požádat o součinnost Projektového Manažera. Připravenou výzvu předá Vedoucímu Beta ke kontrole. Schválený/é dokument/y předá Uploaderovi k zajištění podpisu.

20.1 Kontrola výzvy (VB): Vedoucí Beta zkontroluje obdrženou výzvu a schválí ji, případně ji vrátí Právníkovi VZ k přepracování.

21.0 Podpis výzvy (U): Schválenou výzvu zpracuje Uploader ve spisové službě a zajistí podpis Vedoucího Beta.

VYHLÁŠENÍ/ZVEŘEJNĚNÍ: Ve veřejné zakázce může docházet k vyhlášení/zveřejnění i opakovaně v závislosti na druhu zadávacího řízení. Zároveň zde obvykle probíhají i podprocesy 15.1 Ustavení komise a 15.2 Dotazy k VZ.

14.0 Zveřejnění VZ (PVZ): Právník VZ zveřejní veřejnou zakázku v závislosti na druhu a fázi, ve které se zadávací řízení nachází na Profilu zadavatele, případně ve Věstníku VZ, otevře Průvodce a o provedených úkonech učiní záznam.

15.0 Čekání na import podání: Pokud je proces v tomto kroku, běží u veřejné zakázky lhůta pro doručení podání do Průvodce.

16.0 Import podání (U): Poté, co uplynula lhůta pro doručení podání, zajistí Uploader import doručených podání z Průvodce. V návaznosti na druh a fázi zadávacího řízení provede případně další související činnosti. V případě, že:

  • je doručeno alespoň jedno podání, předá workflow na Projektového Manažera k jednání komise,

  • TA ČR neobdrží ve lhůtě pro podání žádné podání, předá workflow Vedoucímu Beta k rozhodnutí.

JEDNÁNÍ/HODNOCENÍ: Ve veřejné zakázce může docházet k jednání/hodnocení i opakovaně v závislosti na druhu zadávacího řízení. Jestliže bylo předmětem jednání komise hodnocení nabídek, proces pokračuje dále k “ROZHODNUTÍ/OZNÁMENÍ”. Jestliže bude zadávací řízení dále pokračovat, vrací se proces do kroku 19.0 Projektová příprava v kole (PM). V tomto bloku probíhá zejména podproces 18.0 Jednání komise. Dále zde rozhoduje Vedoucí Beta o zrušení zadávacího řízení, pokud není žádný účastník.

17.0 Rozhodnutí o zrušení VZ (VB): V případě, že TA ČR neobdrží ve lhůtě pro podání žádné podání, případně ve veřejné zakázce zůstal nedostatečný počet nebo žádný účastník zadávacího řízení, rozhodne Vedoucí Beta o zrušení veřejné zakázky a předá workflow do kroku 24.0 Příprava oznámení o výsledku (PVZ). V ostatních případech rozhoduje o zrušení veřejné zakázky Předsednictvo TA ČR a Vedoucí Beta iniciuje potřebné kroky.

18.0 Komise jedná (PM): Jednání komisí jsou řízena samostatným podprocesem 18.0 Jednání komise. Projektový Manažer posouvá proces dále dle výsledků jednání komise.

ROZHODNUTÍ/OZNÁMENÍ: K rozhodnutí a oznámení o výsledku VZ dochází v závěru zadávacího řízení. O výsledku zadávacího řízení rozhoduje Předsednictvo TA ČR.

22.0 Materiál pro PřTA (PM): Projektový Manažer připraví materiál na jednání Předsednictva TA ČR. Zajistí zařazení materiálu na nejbližší jednání Předsednictva TAČR.

23.0 Jednání PřTA (VB): Vedoucí Beta seznámí Předsednictvo TA ČR s průběhem zadávacího řízení a doporučením/i komise. Předsednictvo TA ČR poté rozhodne, přičemž může přihlédnout k doporučení komise. Má tyto možnosti:

  • rozhodnout o výběru nejvhodnější/vhodné nabídky/nabídek,

  • nařídit opakované hodnocení,

  • zrušit zadávací řízení.

24.0 Příprava oznámení o výsledku (PVZ): Právník VZ připraví oznámení o výsledku a další související dokumenty v závislosti na druhu zadávacího řízení a počtu účastníků. Může požádat o součinnost Projektového Manažera. Připravené dokumenty předá Vedoucímu Beta ke kontrole. Schválený/é dokument/y předá Uploaderovi k zajištění podpisu.

24.1 Konzultace (PM): Právník VZ může požádat o součinnost Projektového Manažera, a ten součinnost poskytne.

24.2 Kontrola oznámení (VB): Vedoucí Beta zkontroluje obdržené dokumenty a schválí je, případně je vrátí Právníkovi VZ k přepracování.

25.0 Podpis oznámení (U): Schválené dokumenty zpracuje Uploader ve spisové službě, zajistí podpis Vedoucího Beta a vyplní potřebné údaje.

26.0 Lhůta pro námitky: Pokud je proces v tomto kroku, běží u veřejné zakázky lhůta pro podání námitek. V tomto kroku probíhá podproces 26.0 Námitka. Proces pokračuje až po vypořádání všech námitek.

27.0 Rozhodnutí o ukončení VZ (VB): Vedoucí Beta rozhoduje o tom, jakým způsobem bude veřejná zakázka ukončena. V případě, že je dodavatel / příjemce podpory vybrán, spustí podproces 29. 1 Smlouva, čímž zároveň vytvoří část Projekt. V případě, že je zadávací řízení zrušeno, rozhoduje, vždy po konzultaci s resortem, o tom, jestli bude zadávací řízení vyhlášeno znovu (bude vytvořena nová projektová příprava) nebo opětovně vyhlášena nebude (potřeba resortu bude stornována – viz 7, STORNO).

SMLOUVA: Zde probíhá podproces 27.1 Smlouva.

UZAVŘENÍ VZ: V závěru zadávacího řízení probíhají kroky vedoucí k jeho uzavření. Zároveň zde probíhá podproces 29.0 Kompletace spisu VZ.

28.0 Uzavření VZ (PVZ): Právník VZ připraví “Písemnou zprávu zadavatele”. Tu předá Vedoucímu Beta ke kontrole a schválený/é dokument/y předá Uploaderovi k zajištění podpisu. Následně Právník VZ uzavře veřejnou zakázku v závislosti na druhu zadávacího řízení na Profilu zadavatele, případně ve Věstníku VZ.

28.1 Kontrola dokumentu (VB): Vedoucí Beta zkontroluje obdrženou zprávu a schválí ji, případně ji vrátí Právníkovi VZ k přepracování.

28.2 Podpis dokumentu (U): Schválenou zprávu zpracuje Uploader ve spisové službě a zajistí podpis Vedoucího Beta.

29.0 Kompletace spisu VZ: Zde probíhá podproces 29.0 Kompletace spisu VZ.

KONEC: Zadávací řízení je ukončeno.

6.2. Ustavení komise

1000

START: Podproces se nastartuje automaticky poté, co je v části Veřejná zakázka spuštěn krok 15.0 Čekání na import podání. V případě, že dojde v průběhu zadávacího řízení ke změně/změnám ve složení členů komise, spustí Projektový Manažer podproces opětovně.

15.11 Základní údaje (PM): Projektový Manažer vyplní všechny základní údaje o komisi.

15.12 Nominace členů resort (ZOG): Zástupce Odborného Gestora vybere z řad uživatelů resortu členy komise za resort. Vybraným členům je automaticky odeslána výzva k potvrzení členství v komisi. Podproces je možné posunout dále až v okamžiku, kdy všichni nominovaní členové potvrdili svůj souhlas s členstvím v komisi.

15.13 Nominace členů TA ČR (PM): Projektový Manažer vybere z řad uživatelů TA ČR členy komise za TA ČR. Vybraným členům je automaticky odeslána výzva k potvrzení členství v komisi. Podproces je možné posunout dále až v okamžiku, kdy všichni nominovaní členové potvrdili svůj souhlas s členstvím v komisi. Projektový Manažer nakonec vygeneruje samotný dokument k ustavení komise, a předá jej Uploaderovi k zajištění podpisu.

15.14 Podpis dokumentu (U): Připravený dokument zpracuje Uploader ve spisové službě a zajistí podpis ředitele kanceláře.

KONEC: Komise je ustavena.

6.3. Dotazy k VZ

1000

V průběhu veřejné zakázky mohou potencionální účastníci nebo účastníci zadávacího řízení vznášet dotazy. Rozlišujeme 2 druhy dotazů:

  • dotazy k ZD (žádost o vysvětlení zadávací dokumentace), které TA ČR vyřizuje v souladu se ZZVZ,

  • ostatní dotazy.

START: Podproces se startuje automaticky po obdržení zprávy ke konkrétní veřejné zakázce na e-mailovou adresu dodatecne.informace.beta@tacr.cz. V případě potřeby může dotaz založit také Právník VZ.

15.21 Editace dotazu (PVZ): Právník VZ vyplní k dotazu potřebné údaje a připraví návrh odpovědi na dotaz. Má možnost konzultovat odbornou část odpovědi s Projektovým Manažerem. V případě, že výsledkem vypořádání dotazu bude i změna zadávací dokumentace nebo jiný dokument, připraví jej. Připravený návrh předá Vedoucímu Beta ke kontrole. Následně předá schválený/é dokument/y Uploaderovi k zajištění podpisu.

15.211 Konzultace (PM): Právník VZ může požádat o součinnost Projektového Manažera, a ten ji poskytne.

15.22 Kontrola (VB): Vedoucí Beta zkontroluje návrh odpovědi včetně obdrženého/obdržených dokumentu/ú a schválí je, případně je vrátí Právníkovi VZ k přepracování.

15.23 Publikace dotazu (PVZ): Právník VZ zkontrolujte všechna zadaná data a publikuje dotaz:

  • V případě ostatních dotazů, je automaticky odeslána e-mailová zpráva s odpovědí tazateli.

  • V případě dotazů k ZD bez změny zadávací dokumentace, je automaticky odeslána e-mailová zpráva s odpovědí tazateli a odpověď je také automaticky zveřejněna v Průvodci.

  • V případě dotazu k ZD se změnou zadávací dokumentace, odešle Právník VZ dokument/y Uploaderovi k zajištění podpisu.

15.24 Podpis změny ZD (U): Schválený/é dokument/y zpracuje Uploader ve spisové službě a zajistí podpis Vedoucího Beta.

15.25 Zveřejnění změny ZD (PVZ): Právník VZ zveřejní aktualizované znění zadávací dokumentace v návaznosti na druhu zadávacího řízení na Profilu zadavatele, případně ve Věstníku VZ. Zároveň je automaticky odeslána e-mailová zpráva s odpovědí tazateli a odpověď je také automaticky zveřejněna v Průvodci.

KONEC: Dotaz je vypořádán.

6.4. Jednání komise

1000

START: Podproces spouští Projektový Manažer.

18.11 Vyplnění údajů a odeslání pozvánek (PM): Projektový manažer vykomunikuje se členy komise termín a místo jednání komise. Odsouhlasená data zadá do systému. V tomto kroku se odešlou automaticky pozvánky na jednání všem členům, kteří potvrdili svou účast na jednání. Členům, kteří potvrdili svou účast na jednání se automaticky zpřístupní podklady pro jednání v okamžiku, kdy jsou doručená podání z Průvodce naimportována (krok 16.0 Import podání (U)). Projektový Manažer informuje členy o zpřístupnění podkladů s výzvou, aby se členové s podklady podrobně seznámili a na jednání se připravili.

18.12 Zápis a další výstupy jednání (PM): Na samotném jednání zaznamená Projektový Manažer skutečnou účast všech zúčastněných osob. Zajistí podepsání čestných prohlášení, případně ověří čestná prohlášení podepsána na dřívějším jednání. V průběhu jednání zaznamenává důležité informace o jednání. Všechny osoby účastníci se jednání v jeho závěru odsouhlasí znění zprávy/protokolu, a dokument podepíší. Projektový Manažer zajistí uložení zápisu/protokolu, případně dalších dokumentů.

18.13 Schválení zápisu (VB): Vedoucí Beta se seznámí se zápisem ne/potvrdí souhlas s jeho zněním, případně s komisí navrhovanými úkony. V případě nesouhlasu nařídí zpracovat Úřední zápis k nesouhlasnému stanovisku.

18.14 Zpracování dokumentu (PVZ): V případě, že z jednání komise nebo nesouhlasu Vedoucího Beta vzejde požadavek na vypracování dokumentu (dožádání, vyloučení účastníka, úřední záznam…), učiní tak. Může požádat Projektového Manažera o konzultaci. Připravený/é dokument/y vždy předá Vedoucímu Beta ke schválení. Schválený/é dokument/y předá Uploaderovi k zajištění podpisu. V případě, že není požadavek na zpracování dokumentu, uzavře podproces.

18.141 Konzultace (PM): Právník VZ může požádat o součinnost Projektového Manažera, a ten ji poskytne.

18.142 Kontrola (VB): Vedoucí Beta zkontroluje obdržený/é dokument/y a schválí jej/je, případně jej/je vrátí Právníkovi VZ k přepracování. Vyloučení účastníka vždy konzultuje s ředitelem kanceláře.

18.15 Podpis dokumentu (U): Připravený/é dokument/y zpracuje Uploader ve spisové službě a zajistí podpis osoby oprávněné dokument/y podepsat.

KONEC: Jednání komise je uzavřeno.

6.5. Námitka

1000

V rámci řešení námitek rozlišujeme:

  • prvotní námitky k zadávacímu řízení,

  • žádost o přezkum rozhodnutí u Úřadu na ochranu osobních údajů (ÚOHS),

  • komunikace s ÚOHS a další navazující kroky.

START: Podproces spouští Uploader v případě, že TA ČR obdržela námitky. Námitku zakládá ke každému účastníkovi zvlášť.

26.11 Námitka doručena (U): Uploader nahraje všechny obdržené dokumenty a vyplní potřebné údaje.

26.12 Návrh odpovědi (PVZ): Právník VZ připraví rozhodnutí o námitkách. Připravený návrh předá Vedoucímu Beta ke kontrole. Následně předá schválený/é dokument/y Uploaderovi k zajištění podpisu.

28.121 Kontrola (VB): Vedoucí Beta zkontroluje obdržený/é dokument/y a schválí jej/je, případně jej/je vrátí Právníkovi VZ k přepracování. Výsledný/é dokument/y vždy konzultuje s ředitelem kanceláře.

28.13 Podpis odpovědi (U): Připravený/é dokument/y zpracuje Uploader ve spisové službě, zajistí podpis ředitele kanceláře a vyplní potřebné údaje.

KONEC: Námitka je uzavřena.

6.6. Smlouva

1000

Rozlišujeme tyto druhy smluv:

  • Smlouva o poskytnutí podpory,

  • Rámcová dohoda,

  • Smlouva o poskytnutí podpory na základě rámcové dohody.

START: Proces se nastartuje automaticky po vypořádání kroku 27.0 Rozhodnutí o ukončení VZ (VB).

27.11 Aktualizace dat (PM): Projektový Manažer vypořádá zejména případné požadavky předsednictva TA ČR a nastaví začátek projektu.

27.12 Data příjemce (ARES): Administrátor příjemce doplní data, která nebyla povinně udávaná v průběhu zadávacího řízení a vloží originály, ověřené nebo prosté kopie požadovaných dokumentů před podpisem smlouvy v návaznosti na druh zadávacího řízení. Všechna data související se Smlouvou a Parametry zkontroluje.

27.13 Finalizace smlouvy (PM): Projektový Manažer zkontrolujte data zadaná Administrátorem příjemce, případně zajistí jejich opravu a nastaví monitorování projektu. V tomto kroku řeší i případný posun začátku projektu. Připravenou Smlouvu a Parametry předá ke kontrole nejprve Právníkovi VZ a poté Vedoucímu Beta. Odsouhlasenou Smlouvu předá Administrátorovi příjemce (ARES) k podpisu.

27.131 Kontrola (PVZ): Právník VZ zkontrolujte všechna data související se Smlouvou a Parametry. Případné nesrovnalosti nebo nejasnosti řeší s Projektovým Manažerem.

27.132 Kontrola (VB): Jako poslední zkontrolujte všechna data související se Smlouvou a Parametry i Vedoucí Beta. Případné nesrovnalosti nebo nejasnosti řeší s Projektovým Manažerem.

27.14 Podpis příjemce (ARES): Administrátor příjemce (ARES) vygeneruje odsouhlasenou Smlouvu, zajistí její podpis za hlavního příjemce a její doručení do TA ČR.

27.15 Podpis TA ČR (U): Uploader zajistí podpis předsedy předsednictva ve spisové službě a vyplní potřebné údaje.

27.16 Spuštění projektu (PM): V tomto okamžiku odchází automaticky odesílaný e-mail o zahájení projektu vybraným adresátům. Dále v tomto kroku odchází automaticky úkol na zaměstnance Oddělení monitoringu a administrace (OMA) s žádostí o odeslání hlášení do Centrální evidence projektů (CEP). Projektový Manažer organizuje první schůzku projektového týmu s řešiteli (tzv. Iniciační schůzka).

27.17 Export do CEP (U): Uploader zajistí společně se zaměstnancem Oddělení monitoringu a administrace (OMA) odeslání hlášení do Centrální evidence projektů (CEP).

KONEC: Smlouva je uzavřena a projekt spuštěn. Veřejná zakázka automaticky dále pokračuje v kroku 28.0 Uzavření VZ (PVZ).

6.7. Kompletace spisu

1000

START: Podproces se spouští automaticky poté, co Právník VZ uzavře veřejnou zakázku. Ke každému zadávacímu řízení vzniká samostatný spis. Spis obsahuje všechny dokumenty k průběhu zadávacího řízení. Originály dokumentů mohou být vedeny v elektronické nebo písemné podobě. Kopie dokumentů evidovaných v písemné podobě jsou evidovány také elektronicky. Všechny dokumenty jsou vedeny ve spisové službě i v IS. IS je certifikovaným elektronickým nástrojem a TA ČR musí umožnit ÚOHS přístup k veřejné zakázce přímo v elektronickém nástroji, který obsahuje veškeré informace a data související s veřejnou zakázkou.

29.11 Kompletace spisu (U): Uploader zajistí, aby všechny dokumenty byly řádně a správně uloženy v IS. Zajistí, aby byly všechny relevantní dokumenty řádně a správně uloženy ve spisové službě příp. ve fyzickém spisu k zadávacímu řízení. Ke konkrétní zakázce zaznamená relevantní údaje do “Seznamu dokumentů k veřejné zakázce” (checklist). Každý druh zadávacího řízení má vlastní seznam.

29.12 Kontrola spisu (PVZ): Právník VZ zkontroluje, zda je spis kompletní, zda dokumenty obsahují všechny relevantní údaje, případně zajistí nápravu, pokud je to možné. Má možnost vrátit checklist zpátky Uploaderovi k doplnění. Zkontrolovaný checklist předá Vedoucímu Beta k rozhodnutí o uzavření spisu.

29.13 Revize spisu (VB): Vedoucí Beta provede revizi spisu a vydá pokyn k zajištění archivace spisu. Má možnost vrátit checklist Právníkovi VZ zpátky k doplnění nebo přepracování.

29.14 Archivace spisu (U): U zrušených zakázek Uploader uzavře spis a zajistí jeho archivaci. Ve veřejných zakázkách, u kterých je realizován projekt, zůstává spis otevřený, a Uploader zajistí archivaci fyzických dokumentů (část spisu).

KONEC: Spis je kompletní a archivován.

7. STORNO

1000

Zástupce Odborného Gestora má možnost zrušit připravovanou potřebu do doby, než ji umístí do Zásobníku jednoduše smazáním potřeby za použití tlačítka k tomu určenému.

START: Podproces může zahájit Zástupce Odborného Gestora nebo Vedoucí Beta s využitím tlačítka k tomu určenému.

S1.0 Vyjádření resort (ZOG): Zástupce Odborného Gestora uvede důvod stornování za resort. Může jej konzultovat s Konečným Uživatelem.

S1.1 Konzultace (KU): Konečný Uživatel upřesní, doplní nebo zpracuje důvod stornování za resort.

S2.0 Vyjádření TA ČR (VB): Vedoucí Beta uvede důvod stornování za TA ČR. Může jej konzultovat s Projektovým Manažerem.

S2.1 Konzultace (PM): Projektový Manažer upřesní, doplní nebo zpracuje důvod stornování za TA ČR.

KONEC: Potřeba je zrušena ve všech relevantních částech.

8. PROJEKT

8.1. Realizace projektu

Příjemce v průběhu kvartálu vykazuje údaje o odpracovaných hodinách každého člena řešitelského týmu na jednotlivých výsledcích. Po skončení kvartálu zorganizuje TA ČR tzv. Kontrolní Den (KD). Řešitelé na něm představí postup prací na projektu včetně předložení rozpracovaných nebo finálních výsledků. Po uzavření KD dochází k formálnímu hodnocení stavu předložených výsledků projektovým týmem. Toto má zásadní vliv na možnost proplatit příjemci podpory náklady spojené s daným výsledkem v daném kvartále.

Poté, co proběhne posouzení výsledků, může Administrátor příjemce (ARES) podat Žádost O Platbu (ŽOP). Po schválení ŽOP, uznatelné náklady v ní uvedené příjemci podpory TA ČR proplatí.

8.1.1. Kontrola stavu výsledku

1000

START: Podproces se spouští automaticky po skončení 1.měsíce daného kvartálu.

VÝKAZ HODIN: Sledování, zda práce na projektu probíhají a v jakém rozsahu, probíhá na měsíční bázi. Administrátor příjemce (ARES) vyplňuje informace o odpracovaných hodinách všech řešitelů i všech rolí (další osoby podílející se na projektu) v daném měsíci.

M1.0 Výkaz hodin 1M (ARES): Administrátor příjemce (ARES) vyplní údaj o odpracovaných hodinách včetně popisu činnosti na daném výsledku za 1. měsíc daného kvartálu (1M) u každé osoby (řešitel/role), pokud osoba na daném výsledku v daném měsíci skutečně pracovala. Administrátor příjemce má na vyplnění měsíc. Po uplynutí 30 dní dojde automaticky k uzavření možnosti editace a workflow se automaticky posune do dalšího kroku. Administrátor příjemce (ARES) bude mít možnost editace za tento měsíc znovu v kroku M3.0 Výkaz a potvrzení hodin 1-3M (ARES).

M2.0 Výkaz hodin 2M (ARES): Pro tento krok platí stejné informace jako v kroku M1.0 Výkaz hodin 1M (ARES) s tím, že zadává údaje za 2. měsíc (2M) daného kvartálu.

M3.0 Výkaz a potvrzení hodin 3M (ARES): Pro tento krok platí stejné informace jako v kroku M1.0 Výkaz hodin 1M (ARES) s tím, že zde má ARES možnost editace údajů kromě 3. měsíce daného kvartálu (3M), také 1M a 2M.

M4.0 ČEKÁNÍ NA KD: V období čekání na KD probíhá samostatný podproces 8.1.2 Kontrolní den. Pokud je část procesu v tomto kroku, KD ještě neproběhl nebo není uzavřen. Proces bude posunut dále automaticky, po uzavření KD.

SPOKOJENOST S VÝSLEDKY: Součástí monitoringu projektu je i vyjádření spokojenosti s výsledky, tedy formální posouzení souladu stavu předložených výsledků se smluvním stavem výsledků daných v Parametrech v kapitole “Harmonogram řešení projektu a kvalitativní parametry výsledků v čase”. Posouzení v konkrétním kvartále probíhá u těch výsledků, u kterých je na daný kvartál plánovaná realizace výsledku. Posouzení probíhá poté, co proběhl KD k danému kvartálu. Projektový tým má možnost vyjádřit:

  • plnou spokojenost se stavem výsledku (100 %) s tím, že výsledek bude schválen a příjemci mohou být proplaceny uznatelné náklady s ním spojené,

  • částečnou spokojenost se stavem výsledku (méně než 100 %) s tím, že výsledek bude příjemci vrácen k dopracování a proplatit uznatelné náklady s ním spojené bude možné až poté, co dosáhne 100% spokojenosti.

M5.0 Vložení výsledku po KD (ARES): Administrátor příjemce (ARES) vloží rozpracovaný nebo finální výsledek do „Diskuse k výsledkům“ ke každému výsledku zvlášť. Následně vložené přílohy připojí ke konkrétnímu Monitorování projektu a popíše, jak dle jeho názoru tento naplňuje smluvní stav výsledku v daném kvartále.

M6.0 Kontrola (PM): Projektový Manažer zkontroluje informace a přílohy zadané Administrátorem Příjemce (ARES), případně jej požádá o doplnění nebo úpravu. Dále koordinuje samotné posouzení Konečným Uživatelem a Odborným Konzultantem. Může požádat o doplnění nebo úpravu vyjádření. Vyplní také vlastní vyjádření ke stavu výsledku.

M6.1 Posouzení výsledku (KU): Konečný Uživatel posoudí stav výsledku za dané období. Vyjadřuje se zejména k obsahu přiložených příloh. Spokojenost se stavem výsledku vyjádří také číselně v procentech.

M6.2 Posouzení výsledku (OP): Odborný Konzultant posoudí stav výsledku za dané období. Vyjadřuje se zejména k obsahu přiložených příloh. Spokojenost se stavem výsledku vyjádří také číselně v procentech.

M7.0 Potvrzení stavu výsledku (VB): Vedoucí Beta potvrzuje stav výsledku za daný kvartál. Vychází přitom z posouzení Konečného Uživatele, Odborného Konzultanta a z vyjádření Projektového Manažera. Výsledek může schválit nebo vrátit k dopracování Administrátorovi příjemce.

KONEC: Výsledek dosáhl plné spokojenosti a je uzavřen.

8.1.2. Kontrolní den

1000

START: Podproces se spouští automaticky v návaznosti na naplánovaný Řádný KD v Monitorování projektu 30 dní před termínem konání. U Mimořádných KD startuje proces Projektový Manažer ručně tlačítkem k tomu určeném. Zároveň odchází pozvánka na KD všem pozvaným.

K1.0 ČEKÁNÍ NA TERMÍN PŘÍPRAVY KD: Pokud je podproces v tomto kroku, ještě nenastala doba pro vložení podkladů ke KD.

K2.0 Vložení podkladů (ARES): Možnost vložit podklady pro KD je automaticky spuštěna 14 dní před termínem KD. Administrátor příjemce má 10 dní na vložení podkladů ke KD. Vkládá je do „Diskuse k výsledkům“ ke každému výsledku zvlášť. Následně vložené přílohy připojí ke konkrétnímu KD. Pokud nestihne vložit podklady ke KD včas, tedy v době, kdy je proces v tomto kroku, ztratí možnost připojit vložené podklady ke KD. Možnost vložit podklady do „Diskuse k výsledkům“ mu však zůstává.

K3.0 KD probíhá (PM): V tomto kroku probíhá příprava na KD a samotné jednání. KD je automaticky spuštěn 5 dní před termínem KD. Projektovému týmu a dalším účastníkům, kteří potvrdili svou účast na konkrétním KD, se automaticky zpřístupní podklady připojené ke KD. Zároveň se jim automaticky otevře možnost psát připomínky k výsledkům. Projektový Manažer řídí KD. Na začátku jednání zaznamená skutečnou účast osob účastnících se KD. Administrátor Příjemce (ARES) nebo řešitelé projektu prezentují dosažené výsledky za uplynulé období (obvykle kvartál). Účastníci KD mohou zaznamenat své připomínky nebo další vyjádření do zápisu z jednání. Společně formulují závěry z jednání.

K4.0 Uzavření zápisu (PM): Projektový Manažer uzavře zápis a tím i celé jednání KD.

KONEC: KD je uzavřen.

8.1.3. Žádost o platbu

1000

ŽOP je členěna v souladu s Parametry na:

Přímé náklady

  • osobní náklady členů řešitelského týmu za každou osobu zvlášť

  • osobní náklady na role za každou roli a osobu zvlášť

  • ostatní přímé náklady za každý náklad určený v Parametrech zvlášť

Režijní náklady spojené s přímými náklady daného kvartálu

V ŽOP jsou evidovány náklady za každého příjemce podpory (hlavní i vedlejší) zvlášť.

ŽOP schvaluje TA ČR jako celek, za všechny výsledky souhrnně. V návaznosti na to, zda výsledek dosáhl plné nebo jenom částečné spokojenosti, proplatí příjemci podpory všechny náklady, nebo jenom náklady spojené s výsledky, u kterých již byla dosažena plná spokojenost (100 %). Náklady spojené se zbylými výsledky proplatí až poté, co výsledek/y dosáhne/dosáhnou plné spokojenosti.

START: Podproces se spouští automaticky po skončení 1. měsíce daného kvartálu. Administrátor Příjemce (ARES) nebo Finanční Asistent mají od této chvíle možnost průběžně vyplňovat ŽOP za daný kvartál.

Ž1.0 Vyplnění ŽOP (ARES): ŽOP vyplňuje Administrátor Příjemce (ARES) nebo Finanční Asistent. Vyplní všechny náklady spojené s projektem za dané období. ŽOP může vyplňovat průběžně např. po skončení každého měsíce nebo souhrnně za celý kvartál dohromady v závazném členění. ŽOP odesílá ke kontrole vždy pouze Administrátor příjemce (ARES). Ten odpovídá za to, že žádost obsahuje:

  • všechny náklady, které požaduje proplatit; po schválení již není možné činit úpravy,

  • jenom skutečně vynaložené a již proplacené náklady v daném období,

  • jenom náklady související s projektem, vedené v účetnictví odděleně a jsou podloženy prvotními účetními doklady.

Administrátor příjemce (ARES) stvrzuje výše uvedené před odesláním žádosti o platbu ke kontrole.

Ž2.0 Kontrola (PM): Projektový manažer zkontroluje všechny předložené položky. Má možnost konzultovat jednotlivé položky s Administrátorem příjemce (ARES), případně jej může požádat o doplnění, upřesnění nebo vysvětlení. Řádně a správně vyplněnou ŽOP předá Vedoucímu Beta ke schválení.

Ž3.0 Schválení (VB): Vedoucí Beta projde celou ŽOP. Má možnost také konzultovat jednotlivé položky s Administrátorem příjemce (ARES), případně jej může požádat o doplnění, upřesnění nebo vysvětlení. Neuznatelné náklady (např. náklady neodpovídající danému období, v rozporu s všeobecnými podmínkami nebo Parametry apod.) zamítne. ŽOP schválí posunem workflow. V tomto okamžiku se ŽOP uzavře a již není možné v ní dělat jakékoliv úpravy.

Ž4.0 Vytvoření platebního příkazu (ARES): Administrátor příjemce (ARES) určuje okamžik vytvoření platebního příkazu v návaznosti na dosaženou míru spokojenosti s výsledky v daném kvartále:

  • V případě, že jsou všechny výsledky posouzeny na 100 %, vygeneruje příkaz k úhradě na celou schválenou částku.

  • V případě, že jsou některé výsledky posouzeny na méně než 100 %, může vygenerovat příkaz k částečné úhradě pouze na poměrnou část nákladů související s výsledky posouzenými na 100 %. Další příkaz k úhradě bude možné vygenerovat až poté, co budou zbylé výsledky posouzeny na 100 %. Nebo může s vygenerováním příkazu počkat až do okamžiku, kdy budou všechny výsledky posouzeny na 100 %.

KONEC: ŽOP je uzavřena.

8.1.4. Příkaz k úhradě

1000

START: Proces se spouští vygenerováním platebního příkazu Administrátorem příjemce (ARES) v kroku Ž4.0 Vytvoření platebního příkazu (ARES).

Ž5.0 Kontrola (PM): Projektový Manažer zkontroluje vygenerovaný příkaz k úhradě po formální stránce.

Ž6.0 Schválení (VB): Vedoucí Beta zkontroluje vygenerovaný příkaz k úhradě po věcné stránce zejména u příkazů k úhradě s částečným plněním. Má možnost nesprávně vygenerovaný příkaz stornovat (např. duplicitně vygenerovaný příkaz).

Ž7.0 Proplacení (EKO): Referent Ekonomického Oddělení zajistí proplacení příkazu. Zaznamená informace o provedené transakci.

Ž8.0 Potvrzení došlé platby (ARES): Nakonec Administrátor příjemce (ARES) zjistí zda, kdy a v jaké výši dorazila platba na účet příjemce. Zaznamená informace o provedené transakci.

KONEC: ŽOP je proplacena a platební příkaz uzavřen.

8.2. Ukončení projektu

8.2.1. Ukončení výsledků

1000

START: Podproces se spouští automaticky poté, co uplynula doba řešení výsledku.

ČEKÁNÍ NA DOKONČENÍ: K samotnému hodnocení může dojít až poté, co je vypořádaný monitoring výsledku. Výsledek je možné zhodnotit i v případě, že výsledek ještě není zaevidován v Rejstříku informací o výsledcích (RIV).

U1.0 Vyjádření k výsledku (PM): Projektový Manažer nejprve zkontroluje, zda je výsledek, který je předmětem hodnocení, kompletní, zda splňuje všechny náležitosti zasmluvněného druhu výsledku dle podmínek Metodiky 2017+ a MET-12 Specifikace požadavků poskytovatele na výsledky VaV. V případě, že tomu tak není, požádá Administrátora příjemce (ARES) o doložení kompletního finálního výsledku se všemi požadovanými náležitostmi. Poté, co je k dispozici finální výsledek a vyjádření Administrátora příjemce (ARES), požádá o hodnocení nejprve Odborného Konzultanta a poté Konečného Uživatele. Má možnost vrátit vyjádření a hodnocení k přepracování nebo doplnění. Nakonec zhodnotí výsledek sám a zaznamená své odůvodnění.

U1.1 Vyjádření k výsledku (ARES): Administrátor příjemce (ARES), pokud je to potřeba, nahraje kompletní finální výsledek se všemi požadovanými náležitostmi. Zaznamená popis výsledku a uvede kód RIV. V případě, že výsledek nemá přidělený kód v okamžiku hodnocení výsledku, doplní jej později.

U1.2 Vyjádření k výsledku (OK): Odborný Konzultant zhodnotí výsledek, odůvodní své hodnocení a zaznamená svá doporučení k implementaci výsledku.

U1.3 Vyjádření k výsledku (KU): Konečný Uživatel zhodnotí výsledek, odůvodní své hodnocení a zaznamená závazný způsob implementace výsledku. Může se inspirovat doporučeními Odborného Konzultanta. Dále aktualizuje úroveň inovace a předpokládanou úroveň dopadu aplikace výsledku. Nakonec určí způsob převzetí výsledku.

U2.0 Uzavření výsledku (VB): Vedoucí Beta zkontroluje všechny informace o ukončovaném výsledku. Má možnost vrátit vyjádření a hodnocení k doplnění/přepracování nebo výsledek uzavře.

KONEC: Výsledek je uzavřen.

8.2.2. Ukončení projektu

1000

START: Podproces se spouští automaticky zároveň se spuštěním podprocesu “Ukončení výsledku” u prvního uzavíraného výsledku.

ČEKÁNÍ NA VYHODNOCENÍ VÝSLEDKŮ: K samotnému hodnocení může dojít až poté, co jsou uzavřeny všechny výsledky.

U3.0 Posouzení projektu (PM): Projektový Manažer požádá o hodnocení nejprve Odborného Konzultanta a poté Konečného Uživatele. Má možnost vrátit vyjádření a hodnocení k přepracování nebo doplnění. Nakonec zhodnotí výsledek sám a zaznamená své odůvodnění.

U3.1 Posouzení projektu (OK): Odborný Konzultant zhodnotí projekt a zaznamená své odůvodnění.

U3.2 Posouzení projektu (KU): Konečný Uživatel zhodnotí projekt a zaznamená své odůvodnění.

U4.0 Proklamativní vyjádření (ZOG): Následně Zástupce Odborného Gestora potvrdí připravenost resortu převzít výsledky projektu k jejich implementaci a zaznamená své odůvodnění.

U5.0 Kontrola (VB): Vedoucí Beta zkontroluje všechny informace o ukončovaném projektu. Má možnost vrátit vyjádření a hodnocení k doplnění/přepracování nebo posune proces k předání výsledků.

U6.0 PROTOKOLÁRNÍ PŘEDÁNÍ VÝSLEDKŮ: V tomto kroku probíhá samostatný podproces 8.3.2 Předání výsledků.

U7.0 Materiál pro PřTA (PM): Projektový Manažer připraví materiál na jednání Předsednictva TA ČR. Zajistí zařazení materiálu na jeho nejbližší jednání Předsednictva TA ČR.

U8.0 Jednání PřTA (VB): Vedoucí Beta podá zprávu o ukončovaném projektu. Předsednictvo TA ČR poté rozhodne.

U9.0 Uzavření projektu (PM): Projektový Manažer znovu zkontrolujte, zda je u projektu opravdu vše uzavřené. Jestliže projekt obsahuje výsledek/k druhu NmetS, zajistí zveřejnění metodiky na webu TA ČR. Ve spolupráci s referentem Oddělení monitoringu a administrace zajistí vypořádání případných nedostatků v Rejstříku informací o výsledcích.

KONEC: Projekt je ukončen.

8.2.3. Předání výsledků

1000

START: Podproces spouští Vedoucí Beta vypořádáním kroku U5.0 Kontrola (VB).

U6.11 Zajištění podpisu příjemce (ARES): Administrátor příjemce (ARES) vygeneruje protokol/souhlas, zajistí elektronický podpis statutárního zástupce a podepsaný dokument vloží do ISRB3.

U6.12 Kontrola protokolu příjemce (PM): Projektový Manažer zkontroluje doručený protokol/souhlas. Má možnost vrátit jej k přepracování, nebo doplnění. Pokud je vše v pořádku, předá protokol/souhlas k podpisu za TA ČR.

U6.13 Zajištění podpisu TA ČR (U): Uploader zajistí elektronický podpis ředitele kanceláře TA ČR. Oboustranně podepsaný protokol/souhlas nahraje do ISRB3 a odešle jej datovou schránkou příjemci podpory.

U6.14 Zajištění podpisu resort (ZOG): Zástupce Odborného Gestora vygeneruje protokol/zápis, elektronicky jej podepíše a podepsaný dokument vloží do ISRB3.

U6.15 Kontrola protokolu resort (PM): Projektový Manažer zkontroluje doručený protokol/zápis. Má možnost vrátit jej k přepracování, nebo doplnění. Pokud je vše v pořádku, předá protokol/zápis k podpisu za TA ČR.

U6.16 Zajištění podpisu TA ČR (U): Uploader zajistí elektronický podpis ředitele kanceláře TA ČR. Oboustranně podepsaný protokol/zápis nahraje do ISRB3 a odešle jej datovou schránkou resortu.

KONEC: Výsledky jsou předány.

8.3. Změny projektu

8.3.1. Kategorie změn

Změny v projektech dělíme do několika kategorií v návaznosti na proces schvalování žádosti a v návaznosti na to, zda u schválené změny vznikne/nevznikne dodatek ke smlouvě.

Kategorie A Kategorie B Kategorie C Kategorie D

Administrátor příjemce (ARES) podá žádost v ISRB3 včetně zaslání případných příloh

Administrátor příjemce (ARES) podá žádost v ISRB3 včetně zaslání případných příloh

Administrátor příjemce (ARES) podá žádost v ISRB3 včetně zaslání případných příloh

Statutární zástupce podá žádost v ISRB3 včetně zaslání případných příloh

Projektový Manažer zkontroluje úplnost žádosti

Projektový Manažer zkontroluje úplnost žádosti

Projektový Manažer zkontroluje úplnost žádosti

Projektový Manažer zkontroluje úplnost žádosti

Projektový Manažer zajistí provedení změny

Projektový tým se k žádosti vyjádří (dá doporučení)

Projektový tým se k žádosti vyjádří (dá doporučení)

Projektový Manažer zajistí provedení změny

Vedoucí Beta schvaluje

Vedoucí Beta schvaluje

nevzniká dodatek

vzniká dodatek

nevzniká dodatek

nevzniká dodatek

8.3.2. Indikativní výčet změn

Vzhledem k tomu, že každá žádost o změnu je TA ČR posuzována individuálně není možné přesně stanovit přesný a konkrétní přístup ke změnám. Níže uvedené popisy změn odráží obecné principy přístupu TA ČR k žádostem o změny. Příjemce podpory proto nemůže očekávat, že pokud podá žádost o změnu, která je zde uvedena jako možná, bude mu automaticky schválena.

Některé změny v projektech:

  • jsou možné

  • nejsou možné

  • nejsou relevantní (není nutné žádat o změnu)

Příklady změn, které JSOU možné

Popis změny Kategorie

Změna identifikačních údajů hlavního příjemce včetně změn statutárního zástupce a bankovního účtu

A

Změna Administrátora příjemce (ARES)

D

Změna identifikačních údajů vedlejšího příjemce včetně změn statutárního zástupce a bankovního účtu

A

Změna podmínek realizace projektu

B

Prodloužení doby realizace projektu včetně změny počtu realizačních kvartálů a harmonogramu projektu

B

Změna harmonogramu projektu

B

Výměna člena řešitelského týmu 1:1

C

Výměna člena řešitelského týmu mezi příjemci 1:1

B

Změna vnitřních podparametrů u člena řešitelského týmu (počet hodin / osobní náklady na 1 hod. práce)

C

Výměna role mezi příjemci 1:1

B

Změna vnitřních podparametrů u role (počet hodin / osobní náklady na 1 hod. práce)

C

Přesun ostatního přímého nákladu na jiného příjemce

B

Přesun ostatního přímého nákladu na jiného příjemce

B

Příklady změn, které NEJSOU možné

Popis změny Důvod

Změna hlavního příjemce

jedná se o podstatnou změnu dle ZZVZ

Změna vedlejšího příjemce

jedná se o podstatnou změnu dle ZZVZ

Přidání dalšího vedlejšího příjemce

jedná se o podstatnou změnu dle ZZVZ

Navýšení celkové částky:

  • na člena řešitelského týmu

  • role

došlo by ke změně ceny zakázky

Změna člena řešitelského týmu za roli

mohlo by dojít k nedodržení kvalifikací; mohlo by ke změně ceny zakázky

Přesuny alokací mezi:

  • členy řešitelského týmu

  • členem řešitelského týmu a rolí

  • rolemi

došlo by ke změně nasmlouvané závazné alokace;

mohlo by dojít ke změně ceny zakázky

Navýšení počtu:

  • členů řešitelského týmu

  • rolí

neprošlo hodnocením VZ

Rozdělení alokace člena mezi:

  • členy řešitelského týmu

  • člena řešitelského týmu a role

  • rolemi

mohlo by dojít k nedodržení kvalifikací; mohlo by dojít ke změně ceny zakázky

Výměna role za jinou

neprošlo hodnocením VZ

Přidání nového ostatního nákladu

mohlo/došlo by ke změně ceny zakázky

Přesun financí mezi položkami ostatních přímých nákladů

V rámci VZ byl nasmlouván rozsah; výsledná cena zakázky bude nižší o nespotřebované náklady

Změna popisu ostatního nákladu (rozsahu)

mohlo by dojít ke změně závazně nasmlouvaného

Navýšení částky ostatního nákladu

došlo by ke změně ceny zakázky

Navýšení režie

došlo by ke změně ceny zakázky

Příklady změn, které nejsou relevantní (není nutné žádat o změnu)

Popis změny Důvod

Zkrácení délky realizace projektu

příjemce může dodat výsledky před uplynutím doby realizace;

není důvod ke změně

Změna pracovněprávního vztahu

jedná se o orientační údaj

Změna činností

jedná se o orientační údaj

Snížení částek:

  • na člena řešitelského týmu

  • roli

  • ostatní přímý náklad

  • režii

příjemce může spotřebovat (a tím i vykázat a požadovat k proplacení) nižší než maximální částku;

o to bude výsledná cena zakázky nižší

8.4. Porušení podmínek hlavním příjemcem

8.4.1. Výzva k poskytnutí součinnosti

Při zjištění porušení, TA ČR oznámí tuto skutečnost hlavnímu příjemci a vyzve jej k poskytnutí součinnosti nebo nápravě, pokud to je možné. Může tak učinit i opakovaně. Činí tak odesláním “Výzvy k poskytnutí součinnosti” (Výzva), která obsahuje minimálně:

  • popis skutkového stavu s konkrétním popisem porušení,

  • odůvodnění s odkazem na konkrétní porušení (podmínku podpory, specifickou podmínku),

  • závěr s konkrétní výzvou a termínem splnění.

Pokud hlavní příjemce požadavky Výzvy splní řádně a včas, považuje TA ČR záležitost za uzavřenou.

8.4.2. Oznámení o udělení smluvní pokuty

Pokud hlavní příjemce požadavky stanovené ve Výzvě nedodrží řádně a včas, udělí TA ČR hlavnímu příjemci smluvní pokutu v souladu se Všeobecnými podmínkami. Činí tak odesláním “Oznámení o udělení smluvní pokuty” (Oznámení), které obsahuje minimálně:

  • popis skutkového stavu s konkrétním popisem porušení,

  • rozsah nesplněných požadavků s vyčíslením smluvní pokuty,

  • závěr s konkrétní výší smluvní pokuty, informace o způsobu platby a termínem splacení.

Zaplacením smluvní pokuty nezaniká hlavnímu příjemci povinnost splnit požadavky stanovené ve Výzvě.

Pokud hlavní příjemce požadavky Výzvy splní a smluvní pokutu zaplatí včas, považuje TA ČR záležitost za uzavřenou.

8.4.3. Opakovaná výzva k poskytnutí součinnosti

Pokud hlavní příjemce zaplatí smluvní pokutu, a požadavky výzvy nesplní, vyzve jej k tomu TA ČR “Opakovanou výzvou k poskytnutí součinnosti”, která je obsahově shodná s Výzvou.

8.4.4. Oznámení o podezření k rozpočtové kázni

Pokud hlavní příjemce smluvní pokutu nezaplatí včas, oznámí TA ČR tuto skutečnost příslušnému finančnímu úřadu. Činí tak odesláním “Oznámení o vzniku podezření na porušení rozpočtové kázně”, které obsahuje minimálně:

  • popis skutkového stavu s konkrétním popisem porušení,

  • informace o neuhrazené smluvní pokutě,

  • žádost o přistoupení k zahájení daňového řízení za účelem prověření zjištěného podezření z porušení rozpočtové kázně a případného předepsání odvodu za porušení rozpočtové kázně a příslušného penále,

  • žádost o zaslání informace o výsledku Poskytovateli.

9. IMPLEMENTACE VÝSLEDKŮ

1000

START: Podproces se spouští automaticky jednou za rok, dohromady 3x vždy 1. den následujícího měsíce po měsíci, ve kterém byl podepsán protokol o předání výsledků / zápis o postoupení práv a povinností.

I1.0 Záznam o implementaci výsledku (ZOG): Zástupce Odborného Gestora popíše ve strukturované formě, jaké konkrétní kroky a aktivity resort vyvinul pro plné zavedení výsledku do každodenní praxe. Součástí zprávy jsou i informace o případném ne/dosažení deklarovaného druhu výsledku. Má možnost požádat Konečného Uživatele o vyplnění nebo doplnění.

I2.0 Doplnění (KU): Konečný Uživatel vyplní nebo doplní potřebné údaje.

I3.0 Kontrola (PM): Projektový Manažer zkontrolujte zadané informace. Má možnost vrátit vyjádření Zástupci Odborného Gestora k přepracování nebo doplnění. Napíše vyjádření za TA ČR. V případě, že resort dosáhl změny druhu výsledku, zahájí komunikaci s Administrátorem příjemce (ARES) o možnosti změnit tuto informaci v Rejstříku informací o výsledcích.

I2.0 Schválení (VB): Vedoucí Beta zkontrolujte všechna vyjádření. Má možnost vrátit vyjádření Projektovému Manažerovi k přepracování nebo doplnění, případně může vyjádření přepracovat nebo doplnit.

KONEC: Implementační zpráva k výsledku za daný rok je uzavřena.

Poté, co jsou vypořádané “Implementační zprávy” za všechny výsledky a za všechny roky, je možné finálně uzavřít elektronický spis projektu a veřejné zakázky.

10. Druhy veřejných zakázek

Administrace a realizace jednotlivých druhů zadávacích řízení se řídí ZZVZ. Podrobnější informace k inovacím v zadávání veřejných zakázek ZDE.

11. SOUVISEJÍCÍ PŘEDPISY A PROCESY

Název předpisu/procesu, na které se směrnice odkazuje Relevantní část předpisu

SME-35 Realizace resortních potřeb