Sdílený informační systém TA ČR - etapa 3

Krátký popis

Předmětem plnění nadlimitní veřejné zakázky je pokračování projektu SISTA formou rámcové dohody s názvem: „Sdílený informační systém TA ČR - etapa 3”.
TA ČR ve spolupráci s účastníky rámcové dohody buduje SISTA jako cloud native informační systém. TA ČR přijala DevOps přístup mezi interním ICT týmem/jednotlivými dodavateli a vytvořila další potřebné prerekvizity (GCP, CI/CD, pravidla vývoje, vedení dokumentace, design systém, knihovnu UI komponent a katalog služeb) pro řešení druhé etapy projektu SISTA.
TA ČR přistoupil k obnovení rámcového vztahu (jako etapy 3) s ohledem na dosažené výsledky projektu, které umožňují podpořit směr řešení od hledání způsobu jak, přes ověření k jeho funkčním dílčím realizacím v rutinním provozu nebo poloprovozu.
Cílem etapy 3 je obnovit a zvýšit výkon na straně programátorských kapacit a podporu rutinního provozu u stávajících modulů či funkčních částí (produktů) projektu SISTA.
Stále však nejde o zcela rutinní programování podle dokumentace, neboť s přibývajícím náročností výměny informací a jejcih synchronizace, je nutné tyto výměny informací (dat) optimalizovat. Ruku v ruce s tím jde také o kvalitní dokumentaci pro rutinní provoz, nasazení i budoucí rozvoj.
To vše lze zajistit větším počtem účastníků rámcové smlouvy, kteří se zaměří na vývoj dílčích částí zvoleného způsobu řešení SISTA dle pravidel a způsobů nalezených v předchozích rámcových smlouvách. Proto je účelné uzavřít novou rámcovou dohodu, kde hlavním cílem je rozšířit portfolio potencionálních vývojářů ochotných a schopných nad stanovenými principy, pravidly, zásadami či hotovými řešeními v tomto projektu vzniklými, pokračovat plynule dále.
TA ČR předpokládá, že dosavadní výsledky projektu umožňují jeho dílčí a z pohledu autorských či licenčních plateb bezplatné využití i u jiných veřejných zadavatelů. Za tím účelem je do rámcového vztahu přesunuta licenční politika, která byla uplatňována v jednotlivých minitendrech dle jejich účelu.

Popis veřejné zakázky

Předmětem plnění nadlimitní veřejné zakázky je pokračování projektu SISTA formou rámcové dohody s názvem: „Sdílený informační systém TA ČR - etapa 3”.
TA ČR ve spolupráci s účastníky rámcové dohody buduje SISTA jako cloud native informační systém. TA ČR přijala DevOps přístup mezi interním ICT týmem/jednotlivými dodavateli a vytvořila další potřebné prerekvizity (GCP, CI/CD, pravidla vývoje, vedení dokumentace, design systém, knihovnu UI komponent a katalog služeb) pro řešení druhé etapy projektu SISTA.
TA ČR přistoupil k obnovení rámcového vztahu (jako etapy 3) s ohledem na dosažené výsledky projektu, které umožňují podpořit směr řešení od hledání způsobu jak, přes ověření k jeho funkčním dílčím realizacím v rutinním provozu nebo poloprovozu.
Cílem etapy 3 je obnovit a zvýšit výkon na straně programátorských kapacit a podporu rutinního provozu u stávajících modulů či funkčních částí (produktů) projektu SISTA.
Stále však nejde o zcela rutinní programování podle dokumentace, neboť s přibývajícím náročností výměny informací a jejcih synchronizace, je nutné tyto výměny informací (dat) optimalizovat. Ruku v ruce s tím jde také o kvalitní dokumentaci pro rutinní provoz, nasazení i budoucí rozvoj.
To vše lze zajistit větším počtem účastníků rámcové smlouvy, kteří se zaměří na vývoj dílčích částí zvoleného způsobu řešení SISTA dle pravidel a způsobů nalezených v předchozích rámcových smlouvách. Proto je účelné uzavřít novou rámcovou dohodu, kde hlavním cílem je rozšířit portfolio potencionálních vývojářů ochotných a schopných nad stanovenými principy, pravidly, zásadami či hotovými řešeními v tomto projektu vzniklými, pokračovat plynule dále.
TA ČR předpokládá, že dosavadní výsledky projektu umožňují jeho dílčí a z pohledu autorských či licenčních plateb bezplatné využití i u jiných veřejných zadavatelů. Za tím účelem je do rámcového vztahu přesunuta licenční politika, která byla uplatňována v jednotlivých minitendrech dle jejich účelu.

Popis možností

Inflační doložka - účastník je oprávněn, a to nejdříve po dvou letech účinnosti rámcové dohody, na každý rok ze zbývajících dvou let jednostranně zvyšovat cenu za služby poskytované na základě výběru v minitendru vyhlášeného na základě této rámcové dohody (pro potřeby tohoto odstavce jako “služby”), a to v případě, že procentuálně vyjádřená meziroční inflace oproti předchozímu roku převýší 2 %. V případě, že vznikne právo na zvýšení cen za poskytnuté služby dle této inflační doložky v prvním roce ze zbývajících dvou let, platí, že maximální nabídková cena uvedená v příloze č. 1 rámcové dohody se zvyšuje o míru inflace za předchozí rok. V případě, že vznikne právo na zvýšení cen za poskytnuté služby dle této inflační doložky v druhém roce ze zbývajících dvou let, platí, že maximální nabídková cena uvedená v příloze č. 1 rámcové dohody se zvyšuje o rozdíl meziroční inflace mezi prvním a druhým zbývajícím rokem, je-li takový číselně vyjádřený rozdíl vyšší než 0. Účastník je povinen při zvyšování cen za služby vycházet z oficiálních informací poskytovaných ČNB či Českým statistickým úřadem nebo jinou k tomu oprávněnou či pověřenou institucí. Navýšení musí přesně odpovídat procentuální hodnotě míry inflace stanovené institucí uvedenou výše, případně může být nižší. O zvýšení maximální nabídkové ceny je účastník povinen zadavatele informovat.

Seznam a stručný popis podmínek

Dodavatel prokazuje splnění profesní způsobilosti ve vztahu k České republice předložením výpisu z obchodního rejstříku nebo jiné obdobné evidence, pokud jiný právní předpis zápis do takové evidence vyžaduje.
Dodavatel současně předloží doklad, že je oprávněn podnikat v rozsahu odpovídajícímu předmětu veřejné zakázky, pokud jiné právní předpisy takové oprávnění vyžadují, a to oprávnění k podnikání v oblasti „Poskytování software, poradenství v oblasti informačních technologií, zpracování dat, hostingové a související činnosti a webové portály”
Doklady k prokázání profesní způsobilosti dodavatel nemusí předložit, pokud právní předpisy v zemi jeho sídla obdobnou profesní způsobilost nevyžadují.

Seznam a stručný popis výběrových kritérií

Dodavatelská zkušenost s vývojem jakéhokoliv IT produktu, který je dostatečně specifikován, využívá open source technologie a pracuje s nejméně 50 uživateli. Produkt musí být v síťovém produkčním provozu (on-premise či prostřednictvím cloudových služeb s garantovanou úrovní poskytovaných služeb SLA nebo jinými účelnými prostředky). Produkt dodavatel popíše a do produkčního provozu musí být uveden v posledních 3 letech, přičemž hodnota jeho pořízení byla min 500.000,- Kč bez DPH. Jednotlivé projekty k prokázání technické kvalifikace dle §79 budou vyplněny a podepsány jako samostatné přílohy s využitím formuláře připojeného v příloze č. 3 Referenční list - popis IT produktu k prokázání technické kvalifikace dle §79.
Současně předloží čestné prohlášení o připravenosti provádět vývojové práce zejména pro platformu definovanou zadavatelem tj. principy služeb a platformy Kubernetes (Příloha č. 2 - Čestné prohlášení k prokázání technických kvalifikačních požadavků k VZ - Rámcová dohoda „Sdílený informační systém TA ČR - etapa 3”).
Odborná zkušenost v týmu, kdy dodavatel musí mít k dispozici min. 3 osoby pokrývající celkem 5 požadovaných činností v rámcové dohodě jako odborné garanty. Osoby musí mít praxi v dané garantované činnosti min 3 roky. V případě, že by došlo ke změně osob v týmu pověřeným k realizaci této zakázky, je nutné, aby osoby, jež je nahradí, taktéž splňovaly uvedené kvalifikační požadavky.
V případě, že bude prokázáno, že dodavatel má protichůdné zájmy, které by mohly negativně ovlivnit plnění této veřejné zakázky, zadavatel může ve smyslu ust. § 79 odst. 1 ZZVZ považovat technickou kvalifikaci za neprokázanou.

Hlavní podmínky financování a platební ujednání a/nebo odkaz na příslušné předpisy, které je upravují

Platby budou vždy prováděny bezhotovostně, a to buď po akceptaci návrhu řešení, zálohově či v odůvodněných případech předem. Bližší informace budou vždy stanoveny ve Výzvě k podání návrhu řešení v jednotlivých minitendrech a dílčí smlouvě.

Přesné informace o lhůtě (lhůtách) pro přezkumné řízení

Podmínkou pro podání návrhu k ÚOHS je podání námitek k Zadavateli, které je nutné doručit do 15 dnů ode dne, kdy se stěžovatel dozvěděl o domnělém porušení zákona Zadavatelem, nejpozději však do uzavření smlouvy nebo do chvíle, kdy se soutěž o návrh považuje po výběru návrhu za ukončenou.

Námitky proti úkonům oznamovaným v dokumentech, které je Zadavatel povinen podle zákona uveřejnit či odeslat stěžovateli, musí být doručeny Zadavateli do 15 dnů od jejich uveřejnění či doručení stěžovateli.
Pokud je v zadávacím řízení stanovena lhůta pro podání žádostí o účast, musí být námitky proti podmínkám vztahujícím se ke kvalifikaci dodavatele doručeny Zadavateli nejpozději do skončení této lhůty.
Pokud je v zadávacím řízení stanovena lhůta pro podání nabídek, musí být námitky proti zadávacím podmínkám doručeny Zadavateli nejpozději do skončení této lhůty. Námitky proti obsahu výzvy k podání nabídek v dynamickém nákupním systému nebo při zadávání veřejné zakázky na základě rámcové dohody musí být zadavateli doručeny nejpozději do konce lhůty pro podání nabídek. V soutěži o návrh musí být námitky proti soutěžním podmínkám doručeny nejpozději do konce lhůty pro podání návrhů. Zadavatel může v zadávací dokumentaci nebo soutěžních podmínkách stanovit, že námitky podle § 242 odst. 3 nebo 4 zákona lze podat nejpozději 72 hodin před skončením lhůt podle § 242 odst. 3 nebo 4 zákona.

Námitky proti dobrovolnému oznámení o záměru uzavřít smlouvu podle § 212 odst. 2 zákona musí být doručeny Zadavateli do 30 dnů od uveřejnění tohoto oznámení.

Zadavatel je povinen námitky vyřídit do 15 dnů. Návrh je nutné doručit ÚOHS i Zadavateli do 10 dnů ode dne, v němž stěžovatel obdržel rozhodnutí, kterým Zadavatel námitky odmítnul nebo do 25 dnů od odeslání námitek, pokud Zadavatel o námitkách nerozhodl.

Po uzavření smlouvy na veřejnou zakázku či rámcové dohody lze podat pouze návrh na uložení zákazu plnění smlouvy, a to i bez předchozího podání námitek. Návrh na uložení zákazu plnění smlouvy doručí navrhovatel ÚOHS a ve stejnopisu Zadavateli do 30 dnů ode dne, kdy Zadavatel uveřejnil oznámení o uzavření smlouvy způsobem podle § 212 odst. 2 zákona s uvedením důvodu pro zadání veřejné zakázky bez uveřejnění oznámení o zahájení zadávacího řízení, předběžného oznámení nebo výzvy k podání nabídek ve zjednodušeném podlimitním řízení, nejpozději však do 6 měsíců od uzavření této smlouvy. Návrh na uložení zákazu plnění smlouvy podle § 254 odstavce 1 písm. d) zákona doručí navrhovatel ÚOHS a ve stejnopisu Zadavateli do 30 dnů ode dne, kdy Zadavatel uveřejnil oznámení o uzavření smlouvy na základě rámcové dohody podle § 137 zákona nebo oznámení o uzavření smlouvy v dynamickém nákupním systému podle § 142 zákona, nejpozději však do 6 měsíců od uzavření této smlouvy.

Ve lhůtě pro doručení návrhu je navrhovatel povinen složit na účet ÚOHS kauci ve výši 1 % z nabídkové ceny navrhovatele za celou dobu plnění veřejné zakázky nebo za dobu prvních čtyř let plnění v případě smluv na dobu neurčitou, nejméně však ve výši 50 000 Kč, nejvýše ve výši 10 000 000 Kč. V případě, že navrhovatel nemůže stanovit celkovou nabídkovou cenu, je povinen složit kauci ve výši 100 000 Kč. V případě návrhu na uložení zákazu plnění smlouvy je navrhovatel povinen složit kauci ve výši 200 000 Kč. Jde-li o řízení o přezkoumání postupu pro zadávání koncesí, je navrhovatel povinen ve lhůtě pro doručení návrhu složit na účet ÚOHS kauci ve výši 1 % z předpokládané hodnoty koncese uveřejněné ve Věstníku veřejných zakázek nebo na profilu Zadavatele, nejméně však ve výši 50 000 Kč, nejvýše ve výši 10 000 000 Kč. V případě, že Zadavatel neuveřejní ve Věstníku veřejných zakázek nebo na profilu Zadavatele předpokládanou hodnotu koncese, je navrhovatel povinen složit kauci ve výši 100 000 Kč. V případě návrhu na uložení zákazu plnění koncesní smlouvy je navrhovatel povinen složit kauci ve výši 200 000 Kč.

Popis veřejné zakázky

Od začátku února 2025 probíhalo v souvislosti s vyhlašováním veřejných soutěží postupné nasazování dílčích
TRSů účastníků rámcové dohody na produkční prostředí a k faktické zátěži externími uživateli. SISTA se
potýkala s výpadky, jejichž příčiny byly analyzovány a diskutovány na jednání Architektonické rady.
Jednotlivé TRSy prošly samostatným testováním a prokázaly vysokou míru funkčnosti za podmínek
simulované předpokládané zátěže. Nicméně, kritické problémy se objevily až v momentě, kdy byly TRSy
vystaveny reálnému provoznímu zatížení. V systému SISTA se projevila kombinace několika faktorů:
● Neefektivní komunikace mezi mikroslužbami - místo volného propojení se objevilo těsné svázání, které
vedlo ke kaskádovým selháním.
● Problémy s automatickým škálováním - systém nereaguje na zvýšenou zátěž tak, jak by měl, což vede
k přetížení a nestabilitě.
● Konfigurace prostředí - analýza potvrdila, že na selhání se podílela i komplexní konfigurace systému, jejíž
nastavení se v kritický moment neukázalo jako plně optimální pro danou zátěž a specifické provozní
podmínky.
Dodavatelé se shodli na níže uvedeném okruhu témat, která by bylo vhodné v postupných krocích vyřešit:
● Sjednocení autentizace - postupné vyřazování APIGov a nahrazení mTLS a Dapr pro interní služby, APIGov
zůstane jen pro externí služby. Nové služby budou používat middleware Dapr.
● Provoz služeb ve více replikách - „mission critical” služby budou umožňovat horizontální škálovatelnost
řízenou v deploymentu.
● Dapr komunikace - sjednocení komunikace mezi službami pomocí Dapr: čtení synchronně, zápis
asynchronně, vždy s využitím middleware Dapr. Vynucené duplikování synchronních i asynchronních Dapr
zpráv pro troubleshooting.
● Sjednocení tracingu - investigace a sjednocení tracingu pod standard open telemetry, včetně scheduled
jobů a asynchronního tracingu.
● Renovatebot - sjednocení použití a konfigurace Renovatebot pro upgrade knihoven a fixování verzí,
nasazení do TRSů.
● Narovnání logování - sjednocení formátu logování do JSON, revize severity záznamů.
● Izolace FE komponent - změna struktury načítání FE pro izolaci komponent, upgrade sdílených knihoven.
● Statické stránky - servírování statických stránek platformním nginx.
● Sjednocení přístupu k permissions - sjednocení přístupu všech TRSů k permissions.
● Odchytávání chyb FE - zavedení odchytávání chyb javascriptu na FE pomocí sentry pro reporting.
● Jednotný přístup k souborům - zavedení jednotného přístupu pro práci se soubory.
● Sandboxing konfigurací - zavedení mechanismů odstínění konfiguračních chyb.
● Související konzultace - při zavádění úprav mechanismů implementovaných všemi dodavateli
TA ČR využije možnosti článku 6, odst. 2 písm. a) rámcové dohody a minitendr bude vyhlášen bez obnovení
soutěže, neboť půjde o návrh řešení se zachováním stávající technologie (částí ISTA, IS BETA nebo SISTA)
dodané účastníkem, která je v provozu a hodnota plnění nepřesahuje 2 mil. Kč ročně bez DPH vůči účastníkovi
rámcové dohody.

Popis veřejné zakázky

Projektový tým s postupným nasazením byznysových TRSů ze staging na produkční prostředí zaznamenával
nutné drobné požadavky na úpravy DISTA komponent, které byly dodány prostřednictvím MT065 Vytvoření
UI sdílených komponent v knihovně React. Jedná se o soubor níže vymezených okruhů d pracností vždy v řádu jednotek hodin:
● Povýšení Storybooku na aktuální verzi;
● Úpravy velikostí komponent pro výběr data a času;
● Omezení rozměrů komponenty DistaInfoListBlock;
● Vizuální úpravy horní lišty;
● Zvětšení šířky vyhledávacího pole v horní liště SISTA;
● Snížení horní lišty v Page Layout;
● Úprava chování PageLayout se sidebarOpen=false;
● Korektní načítání fontů a jejich sdílení mezi službam;i
● Sjednocení chování DistaHelpBox a MarkdownViewer;
● Přidání názvu profilu uživatele do komponenty User Menu;
● Sdílená šablona index.html pro byznysové služby;
● Deaktivace automatických překladů stránek SISTA;
● Dynamické nastavení jazyka stránky v HTML tagu.
Některé z výše uvedených požadavků reagovaly na bezprostřední potřeby dodavatelů okolních TRSů..
S ohledem na celkový objem odhadované pracnosti úprav a dále s přihlédnutím na zachování stávající
technologie využije TA ČR možnosti článku 6, odst. 2 písm. a) rámcové dohody a minitendr bude vyhlášen bez obnovení soutěže.

Popis veřejné zakázky

Agenda změnových řízení projektů patří mezi komplexnější procesní agendy TA ČR. Při řešení podpořených
projektů dochází ke změnám, které příjemci musí poskytovateli oznamovat nebo musí poskytovatele požádat
o schválení zamýšlené změny.
V posledních třech letech se počet podaných žádostí o změnu projektu stabilně pohyboval okolo 1200 ročně,
což svědčí o potřebě úprav v průběhu realizace projektů. Běžně se v průběhu kalendářního roku podává
průměrně 50 až 100 žádostí o změnu, nicméně v období měsíců října a listopadu dochází k výraznému
nárůstu, kdy toto číslo stoupá až na přibližně 200 žádostí měsíčně. Tento skokový nárůst je obvykle způsoben
nutností zpracovat přesuny rozpočtových prostředků mezi jednotlivými roky financování projektů, a to vše
před podáním monitorovací zprávy.
Byznysový TRS bude pro účely zpracování změnového požadavku spolupracovat zejména s těmito TRSy:
● Vyhlášení veřejné soutěže - poskytuje parametry Veřejné soutěže, které ovlivňují změny (např. určují, jaké
typy organizací jsou povolené pro účastníky/příjemce).
● Podání návrhu programového projektu - poskytuje data podaných návrhů programových projektů spolu s UI
pro jejich editaci pro potřeby změnového řízení (načtení formuláře přihlášky do UI změnového řízení).
● Uzavření smlouvy o poskytnutí podpory - změnové řízení může probíhat už v období uzavírání smlouvy
o poskytnutí podpory, většina změn však probíhá po uzavření smlouvy. Tento TRS také poskytuje šablony
a procesní zpracování aktualizací smluvní dokumentace a kontroly organizací, které do projektu přistupují po
uzavření smlouvy o poskytnutí podpory.
● Správa expertů - na vyžádání poskytne vhodného experta a zajistí jeho zasmluvnění na vybranou činnost -
hodnocení žádosti o změnu.
● Správa projektů - služba poskytuje data projektů a přejímá schválené změny dat projektů.
● Správa projektů - služba poskytuje data projektů a přejímá schválené změny dat projektů.

Text

V části Informace pro statistické účely byla chybně uvedena Celková předpokládaná hodnota v Kč bez DPH. Chybně byla uvedena částka pouze za část veřejné zakázky, nikoliv celková hodnota. Opraveno na hodnotu celé veřejné zakázky.

Popis veřejné zakázky

TA ČR od zahájení řešení projektu SISTA kladla důraz na jednotný přístup všech účastníků rámcové dohody
k tvorbě uživatelského rozhraní SISTA. Projektový tým (interní UX a garanti TRSů) si průběžně osvojoval
aktivity související s prototypováním obrazovek byznysových TRSů. V této souvislosti jsme realizovali
MT036 Design systém a pravidla UX, v průběhu kterého vznikla pravidla spolu se základní knihovnou DISTA
komponent. Projektový tým si postupně budoval odbornou kapacitu a s postupnou implementací byznysových
či průřezových TRSů sbíral podněty na další rozvoj tématu UX/UI.
Garant tématu ve spolupráci s dodavateli vytipovali níže uvedené okruhy, na kterých je nutné prostřednictvím
rozvoje dále pracovat:
● Aktualizace tokenizační knihovny - nová knihovna je nasazena, otestována a plně nahrazuje původní;
všechny závislosti jsou aktualizovány.
● Validace obrazovek a responzivity - všechny dosud vytvořené prototypy prošly kontrolou 1:1 podle návrhu;
fungují správně na všech cílových zařízeních.
● Zajištění souladu Dev a Figma (Storybook) - knihovna UI komponent vedená ve Storybooku a Figma jsou ve
shodě 1:1; nesrovnalosti jsou vyřešeny nebo nahlášeny.
● Nastavení efektivnějšího procesu nahlašování chyb a kontrola designu - všechny identifikované chyby jsou
zadány do systému; návrhy odpovídají schválenému designu.
● Napojení design tokenů na frontend - design tokeny (typografie, barvy, spacing) jsou připojeny a správně se
propisují do kódu (např. přes style-dictionary).
● Doplnění chybějících komponent - nové komponenty jsou navrženy, schváleny, přidány do knihovny
a dostupné v návrhovém systému i Storybooku.
● Pracovní prostor SISTA projektu ve Figmě (DesignOps) - Figma soubory jsou přehledně strukturované,
pojmenování sjednoceno, neaktivní prvky odstraněny.
● Zavedení knihovny komponent „Duplo“ - knihovna „Duplo“ je vytvořena, obsahuje základní, resp. jednotné,
prvky (building blocks) a je používána v nových návrzích. Duplo komponenty odpovídají aktuální funkčnosti
průřezových služeb (např. Správa úkolů).
● Aktualizace UX/UI pravidel - existující pravidla z dokumentace jsou aktualizována/zapracována do procesu
návrhu.
● Doplnění popisu komponent - jednotlivé komponenty obsahují popisy pro Dev.
● Doplnění statusů - statusy a velikosti např. ikon jsou řádně popsány.

Popis veřejné zakázky

V současné době není řízení účelové podpory systémově uchopeno, téma je fragmentováno mezi více rolí
napříč týmy a nefunguje efektivní proces předávání informací. Výstupy agendy jsou vytvářeny v prostředí
Google tabulek, které je náročné na obsluhu a jejich funkčnost se odvíjí od úspěšného exportu dat
ze stávajícího IS ISTA, který je na konci svého životního cyklu.
Cílem MT112 Řízení účelové podpory je uchopit proces plánování (včetně modelování) rozpočtu účelové
podpory tak, aby byl provázán s řízením a správou programů se současným zapojením vedoucích
programových týmů do celého procesu plánování rozpočtů veřejných soutěží. Je nutné nastavit workflow na
schvalování finančních částek (správce rozpočtu, příkazce operace, gestor agendy řízení účelové podpory) pro
dané veřejné soutěže.
Agenda nemá ve stávajícím softwarovém řešení ekvivalent a jde o vývoj nového TRSu. Chceme dosáhnout
vytvoření nového interního prostředí pro řízení účelové podpory v SISTA, který se bude inspirovat pozitivní
praxí řízení rozpočtu z Google tabulek, ale zároveň bude doplňovat nedostatky současného řízení a negativní
praxi nahrazovat novými funkcemi.
Řízení účelové podpory se zařadí mezi klíčové byznysové TRSy, neboť svými funkcionalitami podpoří jeden
z hlavních procesů agentury. Zároveň platí, že TRS nebude zabezpečovat vyplácení prostředků subjektům -
zprostředkuje pouze řízení finančního toku.
Byznysový TRS Řízení účelové podpory musí do ekosystému SISTA zapadat tak, aby nejen čerpal data
vybraných TRSů, ale také sám data poskytoval.
Úspěšná implementace služby zajistí automatizaci celého procesu, sníží riziko chybovosti, zvýší flexibilitu,
zjednodušší správu rozpočtů v reálném čase a především celý proces systémově podchytí a umožní sledovat
jednotlivé etapy přípravy rozpočtu, vč. jejich rychlé kontroly.

Popis veřejné zakázky

1. Existuje průřezový TRS SISTAtoESSL splňující funkční a nefunkční požadavky definované zadáním minitendru.
2. Průřezový TRS SISTAtoESSL spolupracuje s WF službou a dále splňuje požadavky kladené pravidly architektury SISTA
(především multitenantnost a škálovatelnost).
3. Stávající byznysové TRSy pro komunikaci s eSSL využívají TRSy Workflow a SISTAtoESSLL.
4. Připojení eSSL dalších poskytovatelů je otázkou konfigurace SISTAtoESSL a parametrizace Wofkflow.
5. Existuje GitLab repozitář se zdrojovými kódy a dokumentací průřezového TRSu SISTAtoESSL.
6. Ops tým TA ČR je schopen vlastními silami TRS dodaný v rámci MT124 nasadit do testovacího/produkčního prostředí GCP.