IT zakázka pod lupou. Systém rozhodnutí NS SR

Při přípravě nabídky na IS Rozhodnutia NS SR potřebujete počítat s přenosem starých rozhodnutí i s tím, jak zabránit zveřejnění interního dokumentu. Veřejný portál je jen část dodávky. Za ním mají fungovat dvě oddělená prostředí, každé s vlastním úložištěm a vyhledáváním.

Zakázku jsme vybrali z tipů, které nám po konzultaci se svým datovým týmem poskytl Tender.sk. Přispíváme tak technickým pohledem k plánovanému společnému tématu IT tender pod lupou.

Vycházíme z veřejných podkladů, především z revidované přílohy 1A a katalogu požadavků. Rise.sk systém nedodal. Podle EVO byla soutěž při kontrole 19. října 2026 aktivní a termín podání nabídek byl 19. listopadu 2026 v 10:00.

Před nabídkou si ověřte, co už váš produkt umí a jaké úpravy potřebuje. Budete potřebovat také vzorek dat a přístupy k navazujícím systémům. Samotné podklady neprokazují, že konkrétní tým stihne termín.

Přenesený dokument musí jít také najít

Představte si rozhodnutí, které se po migraci otevře bez chyby, ale při převodu ztratilo údaj o soudním kolegiu. Uživatel zadá filtr a dokument nenajde. Počet přenesených souborů přitom sedí. Je to modelový příklad, proč při převzetí kontrolovat i údaje uložené u dokumentu a vazby mezi rozhodnutími.

Migraci historických i aktuálních rozhodnutí z NUXEO požaduje katalog v FR_038. Řízení kvality dat doplňuje část 2.4.5 přílohy 1A.

Začali bychom inventurou a vzorkem exportu. U každého údaje se pak dá určit, kam se přenese a zda potřebuje úpravu. Pravidla oprav musí schválit člověk, který datům rozumí. Chybějící hodnotu nelze při převodu prostě domyslet.

Teprve potom má smysl zkušební import mimo ostrý provoz. Doporučujeme ho připravit tak, aby šel bezpečně opakovat bez duplicit a aby u odmítnutého záznamu zůstal důvod chyby. Protokol propojí původní dokument s novým a umožní ověřit vzorek i nevyřešené rozdíly. Zbývá dohodnout, jak se doplní rozhodnutí změněná mezi zkouškou a konečným přechodem.

Přesné hledání a podobná rozhodnutí se zkoušejí jinak

Uživatel zná spisovou značku a očekává konkrétní rozhodnutí. Jiný hledá podobný právní problém a přesná slova nezná. Každý způsob hledání potřebuje jiný test. Katalog požaduje fulltext i filtry a vedle nich související rozhodnutí, částečné shody a textovou podobnost. Z tohoto zadání samo o sobě neplyne, že má systém generovat právní odpovědi.

Fulltext bychom ověřovali na dokumentech se známým obsahem. Modelový dotaz "náhrada škody" lze omezit datem nebo kolegiem a porovnat s předem určenými výsledky. Totéž platí pro spisovou značku a identifikátor ECLI. Po opravě dokumentu je potřeba zkontrolovat, kdy se změna projeví ve vyhledávání.

U sémantického hledání, tedy hledání podle významu, přesná shoda nestačí. Dotaz "odpovědnost státu za průtahy v řízení" může najít vhodný dokument s jiným slovníkem. Sadu správných i nepřijatelných výsledků proto musí potvrdit odborník na obsah rozhodnutí. Vývojář změří rychlost, ale právní souvislost sám neověří.

Před naceněním je navíc potřeba vyjasnit označení Public a Private v katalogu. FR_008 kombinuje kategorii pro veřejnost s modulem Private. U veřejných funkcí ve FR_004 a FR_028 se objevují stavy zpracování nebo neanonymizovaná data. Zadavatel musí upřesnit, jak tyto zápisy odpovídají požadovanému oddělení veřejné a interní části. Nelze z nich odvodit souhlas se zveřejněním údajů.

U rozhraní rozhoduje i to, co dokument znamená

Rozhodnutí může obsahovat odkaz na právní předpis. Při exportu se musí zachovat jeho význam i vazba na správné znění předpisu, jinak dostane další systém sice čitelné XML, ale neúplný právní dokument.

Pro tyto přenosy zadání používá CEN MetaLex. Odpověď 13 ve vysvětlení č. 2 rozlišuje schéma pro prototyp a cílové řešení. Prototyp se ověřuje vůči schématu používanému v IS Slov-Lex. Pro rozhodnutí a stanoviska v cílovém systému má dodavatel navrhnout vlastní schéma, které z něj a z pravidel CEN MetaLex vychází. Odpověď 14 vztahuje tento formát na právní dokumenty s jejich údaji a vazbami. Formát ostatní interní komunikace navrhuje uchazeč.

Doporučujeme projít s jedním vzorovým rozhodnutím celou cestu. Nejprve popsat jeho části a odkazy, převést je do XML a ověřit výsledek vůči schématu. Pak vyzkoušet export přes API a zkontrolovat vazby na Slov-Lex. Povinnou kontrolu platnosti XML obsahuje katalog ve FR_081.

Část 2.2 přílohy 1A předepisuje REST API s JSON/XML a napojení na Registr NS SR i systémy rozhodnutí jiných soudů. U IS CSSR jde o přípravu na budoucí integraci. Vysvětlení v odpovědi 15 identifikuje také RESS a odkazuje na otevřená data Ministerstva spravedlnosti SR. Jiný rozsah práce má napojení na dostupný zdroj a jiný příprava na systém, který zatím připojit nelze. Pro každé rozhraní potřebujete vědět, kdo dodá popis a testovací přístup. API má podle katalogu používat OAuth 2.0 a oprávnění podle rolí, samotná veřejná dokumentace tedy přístup nezajišťuje.

Oprava rozhodnutí musí dorazit i ke starému odkazu

Dokument se opraví, ale přes původní adresu lze stále stáhnout jeho starou verzi. Takovou modelovou situaci doporučujeme zahrnout do testů publikování. Kontrola stránky nestačí, změna se musí ověřit také v API a ve vyhledávání. Podle návrhu řešení může být potřeba vyčistit i dočasně uložené kopie.

Části 2.2 a 2.4.1 přílohy 1A vyžadují fyzicky oddělenou veřejnou a privátní část. Každá má mít vlastní správu dokumentů, označovanou jako DMS, i fulltextové komponenty. Přenos do veřejné zóny je jednosměrný. Následující obrázek je naše ilustrační zpracování této hranice.

Náš návrh je přenášet jen schválenou verzi s povolenými údaji a zaznamenat výsledek každého kroku. Když přenos selže, systém nesmí hlásit úspěšné zveřejnění. Stejnou pozornost potřebuje stažení dokumentu z veřejné části.

Interní přihlášení se podle katalogu napojuje na LDAP/Active Directory KNS SR. Příloha požaduje vícefaktorové ověřování a jen oprávnění potřebná k práci. Při technické konzultaci zadání bychom proto dohodli i zkoušku odebrání přístupu. API musí dokument odmítnout vydat člověku bez oprávnění, nestačí skrýt tlačítko na stránce.

Dodávka končí až tehdy, když ji převezme provoz

Systém se při ukázce spustí, ale nový správce ho bez původního vývojáře nedokáže obnovit ze zálohy. To je další modelový případ, který má smysl vyřešit už při plánování nabídky. Předání potřebuje vlastní čas a člověka, který ho převezme.

Mikroservisy a kontejnery předepisuje část 2.4.1 přílohy 1A. Doporučujeme k nim opakovatelné nasazení a praktickou zkoušku obnovy podle dokumentace. Katalog počítá také s napojením na EDR, tedy ochranu koncových zařízení, na zálohování a plánovaný centrální monitoring.

Co potvrdit před odhadem

Při odhadu provozu narazíte na rozdíly v podkladech. Katalog uvádí v NFR_013 alespoň 320 souběžných uživatelů, zatímco NFR_025 rozlišuje 320 uživatelů a 100 současných přístupů. Nejprve je potřeba potvrdit očekávaný provoz, včetně velikosti dokumentů a činností uživatelů. Z něj pak vznikne zátěžový test.

Podobně katalog v NFR_014 a NFR_028 uvádí dostupnost 99 %, ale kapitola 6 přílohy 1A požaduje 99,5 % mimo plánovaná servisní okna. Článek XIX návrhu smlouvy pracuje s 99,5 % za kalendářní měsíc. Bez sjednocení měření a výjimek nelze spolehlivě navrhnout podporu.

Možnost stihnout prototyp závisí hlavně na tom, co už dostupné řešení umí a kolik úprav potřebuje. Odpověď 16 ve vysvětlení č. 2 stanovuje 30 dní od doručení výzvy k plnění, článek VII návrhu smlouvy uvádí jeden měsíc. Závazný výklad je potřeba potvrdit společně s harmonogramem projektu. Prototyp může podle vysvětlení běžet u dodavatele, ovšem jen s veřejnými nebo anonymizovanými daty.

Co bude potřebovat budoucí správce

U licencí je nutné oddělit dva náklady. Článek IX návrhu smlouvy požaduje pětiletou podporu výrobce u použitého softwaru třetích stran v ceně díla. Dvanáctiměsíční paušál služeb je naproti tomu volitelný a začne až po objednávce. Článek VIII stejného návrhu řeší převzetí díla včetně zkoušky obnovy. Počítá také s předáním kódu vytvořeného na míru a datového modelu. Pro standardní software, open-source a další licencované části platí výjimky.

Při odhadu vývoje softwaru na míru bychom práci rozdělili takto. Je to naše pomůcka k sestavení nabídky, nikoli předepsané složení týmu.

U každého balíku určete, kdo výstup převezme. Pro společné testy potřebujete také člověka, který převezme řešení chyby, když se na její příčině týmy neshodnou. Podobné otázky pokrývá náš kontrolní seznam pro prověření dodavatele softwaru.

Ještě před technickým odhadem stojí otázka, zda firma splňuje podmínky účasti a má smysl nabídku připravovat. Na tu se zaměřuje analýza zakázek Tender.sk. Jejich veřejná nabídka zahrnuje posouzení podmínek účasti, AI odpovědi s odkazy na dokumenty i pomoc odborníka na veřejné zadávání. Náš rozbor pomáhá s navazujícím rozhodnutím, zda máte kapacity řešení dodat a co zahrnout do ceny.

Pět otázek, které potřebujete uzavřít před nabídkou

1. V jakém stavu jsou data v NUXEO? Vyžádejte si inventuru a vzorek exportu. Dohodněte, jak bude vypadat protokol zaznamenávající rozdíly při migraci.
2. Co má vyhledávání vracet a komu? Potřebujete schválené dotazy s očekávanými výsledky a vysvětlení přiřazení Public/Private.
3. Je jasné, jak předáte právní dokument dalším systémům? Pro prototyp si ověřte XML vůči požadovanému schématu a určete, kdo schválí schéma cílového řešení.
4. Co přesně se stane po opravě nebo stažení rozhodnutí? Nechte potvrdit publikační pravidla i test, který prověří stránku, vyhledávání, dočasné kopie a API.
5. Na čem stojí termín a cena provozu? Potřebujete potvrzený termín prototypu a popis očekávané zátěže. S budoucím provozovatelem dohodněte také důkaz obnovy při převzetí a se zadavatelem závazné parametry dostupnosti i podpory.

Titulní ilustrační fotografii pořídil Mikhail Nilov pro Pexels.