S L E Z S K Á U N I V E R Z I T A V O P A V Ě

Tento dokument je nedílnou součástí, resp. přílohou zadávací dokumentace (dále jen „ZD“) veřejné zakázky nazvané Implementace a provoz informačního studijního systému a spisové služby – Nový informační systém (NIS) (dále jen

„veřejná zakázka“), jejímž zadavatelem je Slezská univerzita v Opavě (dále jen „SU“ nebo „zadavatel“) a jejímž účelem zajištění služeb provozu centrálního informačního systému univerzity (dále jen „NIS“ nebo „Systém“) včetně jeho přizpůsobení, to vše v rozsahu a v souladu se specifikací, resp. bližším určením plnění předmětu veřejné zakázky uvedeném v tomto dokumentu.

Obsah tohoto dokumentu je členěn na následující části:

1) součásti plnění a výstupy projektu – členění součástí předmětu plnění veřejné zakázky na jednotlivé výstupy projektu, které mají být výstupem realizace projektu implementace Systému, jejich rozsah a další parametry,

2) specifikace nefunkčních požadavků na Systém – technických, provozních a dalších nefunkčních požadavků na Systém a jeho provoz podle kapitoly 2.8,

3) specifikace funkčních požadavků na Systém – celková koncepce a specifikace požadavků na funkčnost požadovaného řešení.

1.1 Použité pojmy a zkratky

Zkratka/pojem	Význam
SU, zadavatel	Slezská univerzita v Opavě
NIS, Systém	informační studijní systém a spisová služba, tzn. výsledná (přizpůsobená potřebám SU) a provozovaná podoba software vybraného dodavatele vč. příslušných datových struktur a dat
zákon o vysokých školách	zákon č. 111/1998 Sb. o vysokých školách, zejména § 69a (doručování písemností studentům a uchazečům o studium)
IS	informační systém
ICT	informační a komunikační technologie
eSSL	elektronický systém spisové služby
OS	operační systém
DB	databáze
MS	Microsoft
CRO	Centrální Registr Osob, informační systém SU pro správu identit
Magion	ekonomický IS
GDPR	Nařízení Evropského parlamentu a Rady (EU) 2016/679 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů
Statut	statut SU
ISDS	informační systém datových schránek
ID DS	identifikátor datové schránky
DZ	datová zpráva
analogový dokument	dokument v analogové podobě
elektronický dokument	dokument v elektronické podobě vzniklý editací (vytvořením), digitalizací (naskenováním), nebo dokument přijatý elektronickou cestou, avšak bez náležitostí podle zákona č. 297/2016 Sb. o službách vytvářejících důvěru pro elektronické transakce; obvykle je zdrojem pro dokument digitální
digitální dokument	dokument v digitální podobě podepsaný kvalifikovaným elektronickým podpisem nebo pečetí (podle zákona č. 297/2016 Sb. o službách vytvářejících důvěru pro elektronické transakce)
sken	naskenovaný obraz, resp. elektronická kopie dokumentu (elektronický dokument)
č.j.	číslo jednací
VŠKP	vysokoškolská kvalifikační práce
CŽV	celoživotní vzdělávání
U3V	univerzita třetího věku
ZD	zadávací dokumentace

1.2 CÍL ZAVEDENÍ NIS

Cílem zavedení NIS je implementovat nový informační systém (dále jen „IS“) a elektronický systém spisové služby (dále jen „eSSL“) tak, aby NIS byl v souladu s platnou legislativou a zároveň aby v plném rozsahu nahradil funkcionalitu stávajících systémů.

Vzhledem k ostatním systémům provozovaným na SU je bezpodmínečně nutné, aby byly vytvořeny vazby mezi NIS a ostatními systémy SU v co možná nejširším rozsahu.

1.3 MANDATORNOST A MINIMÁLNÍ ÚROVEŇ POŽADAVKŮ

Požadavky uvedené v tomto dokumentu jsou považovány za minimální požadavky na plnění veřejné zakázky. Zadavatel připouští, aby účastník zadávacího řízení této veřejné zakázky (dále jen jako „účastník“) ve svém návrhu řešení splnil některé jednotlivé požadavky na Systém jiným i neúplným způsobem, než je požadováno, přičemž takový způsob musí být adekvátní pro splnění cílů sledovaných daným požadavek a výsledná odchylka od specifikace daného požadavku může být pouze v některém z detailních dílčích parametrů nebo dílčího chování Systému v daném požadavku, aniž by současně došlo k významnému omezení smyslu daného požadavku jako celku.

2 SOUČÁSTI PŘEDMĚTU PLNĚNÍ A JEHO VÝSTUPY

Předmět plnění veřejné zakázky se sestává ze tří základních součástí – poskytovaných služeb:

1) Inicializace a analýza – inicializace realizace zakázky a analýza detailních požadavků.

2) Implementace Systému – přizpůsobení software dodavatele pro potřeby SU, a to na základě analýzy detailních požadavků, resp. detailní specifikace Systému.

3) Provoz Systému – průběžná paušální služba provozu Systému.

4) Poskytnutí práv k užití Systému.

Části ad. 1) a 2) budou dodány formou realizačního projektu vhodného pro implementaci Systému (dále jen

„projekt“). Realizace projektu je členěna do několika fází, jejichž výstupy označujeme jako výstupy projektu. Uvedené fáze, resp. jejich výstupy nemusí být nutně realizovány chronologicky tak, jak jsou níže postupně popsány. Detailní popis náplně dílčích plnění, tzn. jednotlivých fází projektu a obsah příslušných dodávek projektu, resp. jejich výstupy jsou uvedeny v následujících podkapitolách.

Část ad. 1) obsahuje inicializační procedury realizace veřejné zakázky, zejména nastavení řídících orgánů projektu a komunikace v projektu, bližší definici požadované součinnosti a také definici rizik realizace projektu. Další položkou této součásti plnění je analýza detailních požadavků na funkčnost, logiku chování, vzhled a datovou základu Systému, resp. dodání dokumentu Detailní specifikace řešení, který výstupy takové analýzy zachytí.

Část ad. 2) obsahuje rámcově:

a) přizpůsobení základního (stávajícího) software dodavatele a příslušných datových struktur na základě

Detailní specifikace řešení (někdy také označované jako „implementační studie“, „cílový koncept“ či

„specifikace projektu“),

b) integrace základního, resp. přizpůsobeného software do prostředí SU a propojení s definovanými systémy zadavatele za účelem výměny dat specifikované v Detailní specifikaci řešení,

c) dokumentace Systému a školení obsluhy Systému,

d) testování a akceptace Systému,

e) migrace dat ze stávajícího IS do Systému.

Část ad. 3) bude dodána formou poskytování software jako služby (pronájem) a její náplní je rámcově:

a) pronájem a provoz Systému v infrastruktuře dodavatele,

b) zkušební provoz Systému,

c) běžný provoz Systému,

d) údržba Systému a infrastruktury dodavatele, ve které běží,

e) podpora uživatelů a správců Systému,

f) průběžný rozvoj Systému, zejména jeho funkčnosti na základě změn legislativy a dále podle požadavků zadavatele, a to na základě ad-hoc objednávek zadavatele.

Účastník ve své nabídce pro realizaci jím navrženého řešení uvede výčet a náplň dodávek projektu nejméně v rozsahu určeném touto kapitolou a jejími podkapitolami.

Část ad. 4) je blíže pospána v kapitole 6).

2.1 ANALÝZA DETAILNÍCH POŽADAVKŮ A DETAILNÍ SPECIFIKACE

Toto dílčí plnění zahrnuje provedení analýzy detailních procesních, funkčních a nefunkčních požadavků zadavatele na výsledné, resp. cílové řešení NIS jako celku. Analýza bude vycházet z funkčních a nefunkčních požadavků uvedených v kapitolách 3 a 4 a jejím předmětem je zvýšit míru detailu požadovaných vlastností Systému zkoumáním do větší hloubky a šíře tak, aby mohlo dojít k přizpůsobení software použitých v řešení za účelem splnění požadavků uvedených v tomto dokumentu.

Výstupem této dílčí části plnění bude dokument Detailní specifikace řešení. Kromě shora uvedeného, tzn. kromě funkční specifikace vlastního software NIS, musí být v dokumentu Detailní specifikace řešení obsaženo také následující:

2.2 INSTALACE, KONFIGURACE, PŘIZPŮSOBENÍ, ÚPRAVA A ROZŠÍŘENÍ ZÁKLADNÍHO SOFTWARE NIS

Toto dílčí plnění zahrnuje instalaci základního software NIS a všech komponent potřebných pro jeho provoz do produkčního prostředí podle kapitoly 3.5. Vývojové prostředí ponecháváme v režii dodavatele.

Dále toto dílčí plnění zahrnuje konfiguraci a nastavení základního software NIS a jeho přizpůsobení, tzn. úpravy a rozšíření za účelem splnění požadavků zadavatele obsažených v Detailní specifikaci řešení podle kapitoly 2.1.

Výsledný software NIS definujeme jako dílčí plnění vzniklé jako výsledek následujících činností v projektu a jejich výstupů:

▪ instalace a konfigurace základního software NIS,

▪ přizpůsobení, úpravy a rozšíření software NIS na základě Detailní specifikace řešení,

▪ opravy vad software na základě testování za účelem akceptace a ve zkušebním provozu.

Účastník ve své nabídce uvede jím nabízený rozsah a obsah nabízených komponent, oblastí konfigurace, parametrizace, přizpůsobení, úprav a rozšíření základního software NIS.

2.3 DOKUMENTACE

Toto dílčí plnění zahrnuje vytvoření dokumentace (elektronické) sestávající se z následujícího minimálního výčtu a rozsahu:

▪ dokumentace k obsluze a pro potřebu jejího vzdělávání:

🢭 dokumentace pro obsluhu Systému uživateli ve všech rolích – Uživatelská příručka,

🢭 dokumentace pro obsluhu Systému správcem (manažerem) – Příručka správce aplikace,

🢭 dokumentace a školící materiály pro školení uživatelů, správců, resp. administrátorů;

▪ dokumentace analytická, projektová a realizační:

🢭 dokumentace výstupů analýzy detailní specifikace – Detailní specifikaci řešení,

🢭 dokumentace skutečného provedení díla (realizace Systému) provedená v podobě aktualizace Detailní specifikace řešení (s revizemi i bez), vč. uvedení (zdokumentování) zdrojů změn (např. formou odkazu na zápisy z jednání),

🢭 dokumentace pro akceptační testování obsahující předem stanovený výčet testovaných funkčností Systému a odpovídajících očekáváných výsledků, a to takových, aby zajistily otestování celého Systému a všech jeho částí v souladu s Detailní specifikací řešení – Akceptační scénáře,

🢭 dokumentace integrace s okolními systémy zadavatele, vč. všech mechanismů výměny dat, jejich logiky a technických předpokladů a nastavení na straně integrovaných systémů (protokoly, autentizace, synchronizace komunikace, struktura vyměňovaných dat, šifrování, logování apod.) – Integrační příručka;

Účastník ve své nabídce uvede jím nabízený rozsah a obsah nabízené dokumentace.

2.4 ŠKOLENÍ

Předmětem tohoto dílčího plnění je vyškolení obsluhy NIS v následujícím minimálním rozsahu:

1) školení pro max. 5 klíčových uživatelů – administrativních pracovníků, v prostorách zajištěných zadavatelem, 1 běh, v délce nejméně 4 hodiny,

2) školení pro max. 5 klíčových uživatelů – akademických pracovníků, v prostorách zajištěných zadavatelem, 1 běh, v délce nejméně 4 hodiny,

3) školení pro max. 5 uživatelů stanovených pro tvorbu rozvrhu, 1 běh, v délce nejméně 4 hodiny,

4) školení správce, resp. administrátora Systému, 1 běh před akceptačním testováním, 2 účastníci.

Výčet klíčových uživatelů může zahrnovat i osoby, které zadavatel vybere jako vhodné zástupce pro školení ostatních běžných uživatelů. Klíčoví uživatelé se budou účastnit zejména akceptačního testování.

Účastník ve své nabídce uvede jím nabízený rozsah, obsah a způsob realizace a hodnocení nabízených školení.

2.5 TESTOVÁNÍ A AKCEPTACE

Toto dílčí plnění nemůže být poskytnuto (proběhnout) dříve, než dojde k vytvoření a schválení příslušné dokumentace podle kap. 2.3 a ke kompletnímu proškolení klíčových uživatelů a správců v příslušných rolích 2.4., a zahrnuje:

1) akceptační testování zadavatelem za podpory dodavatele,

2) odstranění případných vad dodavatelem zjištěných při testování zadavatelem nebo dodavatelem,

3) další případné kolo akceptačního testování zadavatelem za podpory dodavatele,

4) další případné odstranění případných vad zjištěných při dalším kole testování,

5) poslední případné kolo akceptačního testování,

6) akceptace Systému v případě úspěšného akceptačního testování v produkčním prostředí podle kapitoly 3.5.

Akceptace Systému je nutnou podmínkou pro zahájení migrace dat ze stávajícího IS zadavatele do NIS podle kap. 2.6.

2.6 MIGRACE

Toto dílčí plnění nemůže být poskytnuto (proběhnout) dříve, než dojde k úspěšnému dokončení testování a akceptace Systému podle kap. 2.5, a zahrnuje prvotní naplnění Systému údaji předanými Objednatelem ve strojově zpracovatelné podobě, a to nejméně následujícími:

a) údaji o studentech v objemu poskytovaném celostátní matrice studentů (SIMS),

b) personálními údaji zaměstnanců,

c) strukturou pracoviší,

d) studovanými programy,

e) harmonogramem akademického roku,

f) katalogem předmětů a

g) údaji o zápisech předmětů a hodnoceních studentů podle údajů dodaných Objednatelem.

Minimální počet iterací migrace, než dojde k jejímu úspěšnému dokončení, jsou dvě. První s omezeným rozsahem dat a druhá pak s kompletním rozsahem dat po úspěšném otestování migračních algoritmů.

Migrace dat do Systému je nutnou podmínkou pro zahájení zkušebního provozu podle kap. 2.7.

2.7 Zkušební provoz

Toto dílčí plnění nemůže být poskytnuto (proběhnout) dříve, než dojde k úspěšnému dokončení migrace dat do Systému podle kap. 2.6, a zahrnuje následující:

1) předání a převzetí Systému do zkušebního provozu,

2) zahájení zkušebního provozu Systému za podmínek a současně s dodávkami a součástmi běžného provozu Systému podle kap. 2.8,

3) odstranění případných vad zjištěných ve zkušebním provozu Systému,

4) předání a převzetí Systému do běžného provozu a zahájení běžného provozu.

Zkušební provoz je definován jako provoz Systému časově omezený po dobu 2 (dvou) měsíců a jeho účelem je odhalení případných skrytých vad Systému, které nebylo možné odhalit v průběhu akceptačního testování ani při vynaložení maximálního úsilí, protože projevy a výskyt takových vad jsou podmíněny okolnostmi konkrétního použití Systému, zejména zapojením všech běžných (reálných) uživatelů, zadáváním skutečných provozních dat, zátěží Systémů apod.

Zkušební provoz bude zahájen nejdříve po odstranění všech vad Systému, které vedly na výsledek akceptačního testování typu „akceptováno s výhradami“, tzn. až po odstranění všech výhrad akceptačního testování a jejich příčin.

Zkušební provoz bude prováděn za následujících podmínek:

1) Zkušební provoz bude probíhat v produkčním prostředí Systému podle kapitoly 3.5.

2) Zkušební provoz bude probíhat při zapojení všech běžných uživatelů Systémů.

3) Pro zkušební provoz budou použita reálná data, která byla do Systému namigrována nebo jsou zadávaná do Systému uživateli při jeho provozu.

4) Na vady Systému zjištěné ve zkušebním provozu bude nahlíženo jako na vady záruční.

2.8 PROVOZ SYSTÉMU

Toto průběžné plnění zahrnuje:

1) pronájem a nepřetržitý provoz Systému v produkčním prostředí podle kapitoly 3.5,

2) služby údržby Systému a jeho součástí, zejména aplikování aktualizací software typu upgrade, update, maintenance a patche, z funkčních, technických a legislativních důvodů,

3) služby podpory uživatelů při provozu Systému v třetí úrovni technické podpory,

4) služby rozvoje Systému, zejména vynucené aplikací legislativních změn a požadavků zadavatele.

První úroveň (klíčový uživatelé, správci produktu) a druhou úroveň (centrum IT) technické podpory zajišíuje zadavatel.

Zvláštní částí této etapy je pak úvodní část, ve které bude probíhat zkušební provoz podle kapitoly 2.7. Až po jeho úspěšném ukončení bude následovat provoz běžný.

2.8.1 SLUŽBA PROVOZU SYSTÉMU A JEJÍ PARAMETRY

Předmětem této dílčí poimplementační služby je běžný a pokud možno bezporuchový provoz Systému za součinnosti se zadavatelem coby provozovatelem podřízené infrastruktury, kdy dodavatel je správcem Systému s privilegovaným přístupem, a to za splnění následujících provozních parametrů (dále jen „provozní parametry“):

1) garantovaná provozní doba Systému je stanovena na pracovní dny v době od 7:00 do 17:00 (dále jen

„provozní doba“),

2) parametr dostupnosti Systému v provozní době (dále jen „dostupnost“) je stanoven na 95 %, přičemž je vyhodnocován vždy za kalendářní měsíc a doba předem stanovených, nahlášených a odsouhlasených odstávek Systému se do vyhodnocení dostupnosti nezapočítává, a za projev porušení dostupnosti se počítá jakýkoliv výpadek Systému jako celku, tzn. vada závažnosti A, jak je definována v kapitole 2.8.4 (dále jen „výpadek“) v provozní době,

3) lhůta pro obnovu chodu Systému a dat po havárii Systému je stanovena na maximálně 24 hodin, přičemž havárií se rozumí takový výpadek, kdy dojde k poškození integrity Systému nebo jeho dat a je nutné Systém znovu nasadit (zprovoznit) nebo obnovit jeho data ze zálohy (dále jen „havárie“).

Zadavatel požaduje pro zajištění plnění provozních parametrů a pro jejich vyhodnocování činnosti definované v následující podkapitole.

Součástí služeb provozu Systému je také pravidelné zálohování dat spravovaných Systémem nejméně 1x za 24 hodin. Dodavatel zajistí zálohování odolné proti destrukci budovy (např. požárem), ve které se Systém nalézá.

2.8.2 VYHODNOCENÍ PARAMETRŮ PROVOZU SYSTÉMU

Pro vyhodnocování plnění parametrů stanovených pro provoz Systému budou použity záznamy v systému Helpdesk tak, jak budou zadavatelem a dodavatelem zadávána.

2.8.3 HELPDESK

Hlášení incidentů ve smyslu kapitoly 2.8.4 a požadavků zadavatele na podporu a rozvoj systému a jejich řešení bude probíhat prostřednictvím a bude zaznamenáváno v systému pro hlášení požadavků a incidentů (dále také jen jako „systém helpdesk“), který je provozován zadavatelem a není předmětem této veřejné zakázky. Dodavateli bude umožněn a zřízen dálkový přístup do systému helpdesk v počtu nejméně 2 (dvou) uživatelských účtů. Veškerá komunikace mezi zadavatelem a dodavatelem ve věcech poimplementačních služeb bude probíhat prostřednictvím systému helpdesk, který bude uživatele notifikovat emailem o zadaných požadavcích.

Předmětem plnění této dílčí poimplementační služby je zejména následující:

1) připravenost reagovat na incidenty a požadavky vystavované v systému helpdesk oprávněnými zástupci zadavatele zajišíujícími první úroveň technické podpory uživatelům (dále jen „uživatelé helpdesk“), a to způsobem a za podmínek dále uvedených,

2) přijímání incidentů a požadavků hlášených uživateli helpdesk v provozní době,

3) zajištění náhradního elektronického prostředku pro případ a po celou dobu výpadku systému helpdesk, a zajištění doplnění záznamů do systému helpdesk vzniklých po dobu takového výpadku,

4) vedení záznamů o incidentech a požadavcích v systému helpdesk a o způsobu a postupu jejich řešení.

2.8.4 ÚDRŽBA SYSTÉMU

Předmětem plnění této dílčí poimplementační služby je zejména následující:

1) řešení incidentů a požadavků na odstraňování vad software NIS (dále společně jen jako „incident“) nahlášených v systému helpdesk za následujících podmínek a pravidel:

i) každému incidentu uživatel helpdesk stanoví závažnost, resp. prioritu z následujících možností:

Závažnost	Míra a charakter dopadu na systém
A	Kritická chyba Systému, tzn. výskyt stavu Systému, kdy je splněna alespoň jedna z následujících podmínek: a) Systém, nebo jeho některá funkčnost, je buď zcela, nebo částečně nedostupná, obvykle nejčastěji z důvodů výpadku či havárie, b) zadavatel prostřednictvím systému nemůže vůbec plnit úkoly, pro které byl Systém pořízen.
B	Běžná chyba Systému, tzn. výskyt stavu Systému, kdy je splněna alespoň jedna z následujících podmínek: a) zadavatel prostřednictvím Systému nemůže v plném rozsahu plnit úkoly, pro které byl Systém pořízen, nebo je funkčnost Sytému výrazně omezena tak, že doba potřebná pro provádění jednotlivých operací je násobně delší než v běžném provozu Systému, b) některé části Systému, nebo jeho některá funkčnost, je nefunkční nebo částečně nefunkční, nicméně je možné takové omezení nahradit dočasně organizačním opatřením.
C	Nedostatek Systému spočívající v rozdílu vůči specifikovanému, resp. dokumentovanému chování a vlastnostem Systému, které však nebrání použití Systému jako celku i jeho jednotlivých částí a funkčností v plném rozsahu.

ii) Xxxxxxxxx je povinen potvrdit nahlášení incidentu, zahájit činnosti vedoucí k odhalení vady a její příčiny, oznámit příčinu vady a odstranit vadu i okolnosti, které ji způsobily tak, aby nedošlo k jejímu opakovanému výskytu, nejpozději v následujících lhůtách podle priority incidentu:

Činnost

Lhůta pro provedení činnosti

Závažnost A

Závažnost B

Závažnost C

zahájit činnosti vedoucí

k odhalení vady a její příčiny

2 hodiny

4 hodiny

1 pracovní den

odstranit vadu i příčiny a

okolnosti, které ji způsobily

8 hodin

2 pracovní dny

5 pracovních dní

2) zajištění dostupnosti a plynulého provozu Systému v provozní době,

3) pravidelné monitorování stavu Systému a jeho parametrů klíčových pro předcházení nedostupnosti nebo nekompletní funkčnosti Systému v provozní době a informování zadavatele o případných problémech,

4) operativní řešení problémů bránících plynulému provozu Systému neprodleně po jejich zjištění a protokolární zaznamenávání takové činnosti a informování zadavatele vč. příčin, které odhalené problémy způsobily,

5) pravidelné poskytování a nasazování opravných, menších (minoritních) a větších (majoritních) aktualizací (update) softwarových komponent NIS, a to buď dle potřeby na základě hlášených incidentů, nebo preventivně na základě jejich dostupnosti; dodavatel je povinen informovat zadavatele

o takových aktualizacích nejpozději 15 (patnáct) dní před jejich plánovaným nasazením.

2.8.5 PODPORA SYSTÉMU

Předmětem plnění této dílčí poimplementační služby je zejména následující:

1) spolupráce při zkušebním provozu Systému v místě užívání systému klíčovými uživateli zadavatele zajišíující operativní řešení problémů bránících plynulému provozu systému,

2) zvýšená podpora uživatelů při zkušebním provozu Systému v provozní době,

3) poskytování průběžné poradenské služby, tj. bezprostřední rady, konzultace a asistence uživatelům v běžném provozu Systému prostřednictvím uživatelů helpdesk v provozní době.

Dodavatel bude reagovat na požadavky na podporu ne později než ve lhůtě 3 (tří) pracovních dní od nahlášení požadavků v systému helpdesk.

2.8.6 ROZVOJ SYSTÉMU NA ZÁKLADĚ LEGISLATIVNÍCH ZMĚN

1) pravidelné sledování legislativních změn s dopadem na funkčnost Systému a písemné informování zadavatele o takových změnách,

2) úpravy a doplnění funkčnosti Systému a jeho parametrů s cílem dosáhnout souladu funkčnosti Systému se specifikací požadovanou aktuální legislativou, a to s vynaložením přiměřeného úsilí nejpozději 30 (třicet) dní před datem účinnosti takové legislativní změny, pokud je to s ohledem dobu zveřejnění příslušné legislativy možné, a písemné zaznamenávání takových činností a informování zadavatele

o nich,

3) vyzývání zadavatele k akceptaci provedených úprav Systému a podpora zadavatele při akceptaci,

4) zajištění promítnutí dopadu změn aplikovaných v Systému do příslušné dokumentace k užívání, správě a provozu systému a předání takto upravené dokumentace zadavateli nejpozději 10 (deset) dní po provedení takových změn,

5) zajištění nasazení zadavatelem akceptovaných změn do provozního prostředí Systému.

2.9 Služby rozvoje Systému na základě požadavků zadavatele

Předmětem plnění této dílčí poimplementační služby je zejména následující:

6) připravenost reagovat na požadavky zadavatele na úpravy a doplnění funkčnosti Systému,

7) poskytování nabídek na realizaci požadavků zadavatele na rozvoj Systému zahrnujících všechny činnosti nezbytné k detailnímu návrhu, implementaci, otestování, nasazení a dokumentace takových změn postupem a za podmínek analogických pro implementaci NIS výše popsanou, a to za použití ceny označené jako Sazba za rozvoj,

8) realizaci zadavatelem vybraných požadavků na základě nabídek podle předchozího odstavce.

2.10 POŽADAVKY NA ZPŮSOB POSKYTNUTÍ PRÁV K UŽITÍ SOFTWARE

Součástí návrhu řešení v nabídce účastníka zadavatel požaduje popis použitého způsobu poskytnutí práv k užití software NIS (licenční model) s uvedením rozsahu a vazby poskytnuté licence na počet uživatelů, popř. výpočetní výkon či jiné měřitelné parametry určující rozsah platnosti licence, a to minimálně v rozsahu umožňujícímu zadavateli:

▪ užívání Systému v rozsahu minimálně podle kapitoly 3.2.2 (počty a typy uživatelů, objem dat, prostředí, architektura),

▪ v rámci nejméně České republiky,

▪ po dobu účinnosti příslušné smlouvy.

Budou-li součástí návrhu řešení Systému v nabídce účastníka také další podsystémy, jiné nástroje, komponenty a technické pomůcky, které jsou předmětem požívání ochrany autorského díla podle zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon), ve znění pozdějších předpisů, nebo jiných adekvátních právních předpisů vč. norem jiných států, (dále jen

„autorské dílo“) a nebude-li se jednat o autorské dílo, které je výstupem služeb nebo výsledkem činnosti dodavatele (dále jen „Komponenty třetích stran“), uveden účastník ve své nabídce, jakým způsobem má zajištěno oprávnění vykonávat svým jménem a na svůj účet majetková práva autorů ke Komponentám třetích stran a jak zajistí nabytí práva užívat Komponenty třetích stran zadavatelem, a to v rozsahu a za podmínek umožňujících výkon práv k užití software Systému jako celku podle této kapitoly (viz výše v této kapitole).

Skutečnost dokládající splnění uvedené podmínky výkonu práv k užití Komponent třetích stran musí být dodavatelem splněny po dobu nejméně 5 (pěti) let od zahájení plnění této veřejné zakázky podle příslušné smlouvy.

Účastník ve své nabídce uvede jím nabízený rozsah a obsah licencí nabízených komponent Systému tvořících software NIS, a to vč. komponent třetích stran.

2.11 PŘEDPOKLÁDANÝ HARMONOGRAM PLNĚNÍ

Harmonogram plnění se předpokládá v následujícím postupném členění a obsahu dodávek:

▪ Etapa I. – Inicializace a analýza – obsahuje výstupy:

🢭 Inicializace podle kapitoly 1.2, část ad. 1),

🢭 Analýza podle kapitoly 2.1,

▪ Etapa II. – Implementace – obsahuje výstupy:

🢭 Instalace, konfigurace, přizpůsobení atd. podle kapitoly 2.2,

🢭 Dokumentace podle kapitoly 2.3,

🢭 Školení podle kapitoly 2.4;

🢭 Testování a akceptace podle kapitoly 2.5,

🢭 Migrace dat podle kapitoly 2.6,

▪ Etapa III. – Outsourcing – obsahuje výstupy:

🢭 Zkušební provoz systému podle kapitoly 2.7,

🢭 Provoz Systému podle kapitoly 2.8,

🢭 Rozvoj systému na základě požadavků zadavatele podle kapitoly 2.9.

Bližší určení postupu a podmínek poskytování předmětných služeb, zejména výkonu autorských práv a způsobu akceptace a převzetí Systému do zkušebního a běžného provozu, je uvedeno v Návrhu smlouvy.

3 NEFUNKČNÍ POŽADAVKY

V této kapitole jsou uvedeny nefunkční, resp. technické požadavky na Systém, které představují podmínky plnění zakázky ve smyslu zadávací dokumentace.

3.1 VÝPOČETNÍ PROSTŘEDÍ ZADAVATELE

NIS bude provozován kompletně na infrastruktuře dodavatele. Na klientské straně bude Systém kompatibilní s následujícími komponentami stávající infrastruktury zadavatele:

1) OS pracovních stanic: MS Windows 7 a vyšší;

2) kancelářský balík MS Office verze 2010 a vyšší;

3) prohlížeče webu: MS Internet Explorer, MS Edge, Google Chrome, Mozilla Firefox a Apple Safari v aktuálních verzích.

Dodavatel musí garantovat bezvadnou funkčnost Systému minimálně na prohlížečích internetu Microsoft Edge a Google Chrome.

3.2 INTEGRACE DO PROSTŘEDÍ ZADAVATELE

Popis požadavků na propojení systémů SU na NIS jsou následující:

3.2.1 TRANSPORTNÍ DATABÁZE SYNC.DB

Pro zajištění vazby mezi NIS a ostatními systémy SU bude zadavatelem vytvořena vazební (transportní) databáze označovaná dále SYNC.DB, a to ve stávající infrastruktuře zadavatele na DB stroji Oracle. Data, která nyní vznikají primárně v systémech SU, budou přenášena do NIS prostřednictvím SYNC.DB, a naopak, v SYNC.DB budou data vznikající v NIS poskytována systémům SU.

Pro každý typ dat spravovaných v SYNC.DB bude stanoveno, v jakém systému primárně vznikají, a bude tedy stanoven směr přenosu dat mezi NIS a ostatními systémy SU.

V rámci SYNC.DB budou zadavatelem vytvořeny databázové pohledy, které budou sloužit pro přenos dat mezi NIS a ostatními systém SU.

Zadavatel požaduje vytvoření synchronizačního modulu v rámci NIS (dále jen „SyncApp“), který bude synchronizovat data NIS se SYNC.DB. Datové struktury potřebné pro synchronizaci dat, resp. vytvoření SyncApp budou blíže určeny v rámci etapy 2.1 Analýza detailních požadavků a detailní specifikace.

Obecně se bude jednat o libovolná data z DB NIS, která bude zadavatel potřebovat k dalším činnostem. Pro integraci NIS do systémů SU musí SyncApp co nejdříve (již v rámci implementace) zajišíovat synchronizaci dat o osobách, která primárně vznikají v NIS (uchazeči, studenti, účastníci kurzů, externí uživatelé NIS) nebo která primárně vznikají v systémech SU(zaměstnanci).

3.2.2 PROPOJENÍ DAT CRO S NIS

Systém Centrální Registr Osob (dále jen „CRO“) je systém elektronických identit uživatelů systémů SU, který:

▪ vytváří a spravuje unikátní a trvalou elektronickou identitu uživatelů SU v systémech a službách informačních a komunikačních technologií (dále jen „ICT“) zadavatele;

▪ synchronizuje a konsoliduje údaje v systémech a službách ICT zadavatele, které je potřeba mezi nimi sdílet, zejména profily uživatelů (zejména jméno, příjmení, datum a místo narození, bydliště, kontakty, role, pracoviště atp.);

▪ zajišíuje (poskytuje všem aplikacím) autentizační mechanismus, tzn. umožňuje jednotné přihlašování k napojeným ICT systémů a služeb zadavatele pomocí jednoho uživatelského jména a hesla.

Za účelem integrace CRO s NIS prostřednictvím SYNC.DB zadavatel požaduje po dodavateli implementovat do SyncApp následující mechanismus pro synchronizaci identit uživatelů nově vzniklých v NIS:

1) Nový uživatel je zaveden v NIS, zatím jako neaktivní, a to včetně profilových informací.

2) SyncApp při nejbližší synchronizaci přenese záznam o tomto novém uživateli do SYNC.DB.

3) NIS v tuto chvíli čeká na aktivaci uživatele ze strany CRO.

4) CRO provede aktivaci daného uživatele a přenese tuto novou informaci o aktivaci do SYNC.DB. Pro každého uživatele vygeneruje CRO nový jednoznačný identifikátor CRO-ID, který je vazebním prvkem pro NIS (ostatně i pro všechny jiné systémy SU aplikace).

5) SyncApp při nejbližší synchronizace přenese záznam o aktivovaném uživateli do NIS, a to včetně případně aktualizovaných profilových dat.

Postup synchronizace v situaci, kdy uživatel vznikne (z pohledu NIS) v CRO:

1) CRO zaznamená nového již aktivovaného uživatele do SYNC.DB včetně profilových informací.

2) SyncApp při nejbližší synchronizace přenese záznam o aktivovaném uživateli do NIS. A to buď jako nový, nebo jej ztotožní se svým záznamem, pokud jde podle profilových informací o stejného uživatele.

Při obousměrné synchronizaci osob může dojít ke kolizi, přesněji k současnému vytvoření nového záznamu v obou systémech o uživateli reprezentujícího stejnou osobu. Tyto kolize musí řešit CRO i NIS snahou

o ztotožnění obou uživatelských účtů, popř. ručním zásahem.

Příkladem je situace, kdy bude osoba zavedena zároveň jako zaměstnanec (systémy SU, CRO) a zároveň jako student (NIS).

Analogicky k zavádění osob bude řešena také aktualizace údajů, o již existujících osobách. Například pokud dojde ke změně příjmení studenta ve studijní agendě (NIS), XxxxXxx zajistí přenos takto aktualizovaného údaje do SYNC.DB.

3.2.3 AUTENTIZACE UŽIVATELŮ NIS VŮČI LDAP KOMPATIBILNÍ AD

Pro autentizaci uživatelů všech systémů SU slouží LDAP cluster. Tzn. že nebude k dispozici funkce pro nastavení hesla přímo v NIS. Při přihlášení, které bude realizováno výhradně přes webový server na webové HTTPS adrese NIS, pošle NIS dotaz na ověření dvojice CRO-ID a hesla prostřednictvím protokolu LDAP do LDAP clusteru.

3.2.4 INTEGRACE SE SERVEREM ELEKTRONICKÉ POŠTY

Zadavatel disponuje vlastním serverem elektronické pošty (dále také jako „email server“). Email server disponuje rozhraním pro obsluhu protokolů elektronické pošty SMTP, POP3 a IMAP.

Zadavatel požaduje v rámci NIS modul, který zajišíuje funkce běžného klienta elektronické pošty, který bude napojen na email server.

Současně bude možné odesílat emaily, resp. nahlížet do vybrané podmnožiny přijatých emailů v jiných modulech NIS v závislosti na kontextu, např. odeslání emailů všem studentům přihlášeným k předmětu daného pedagoga (viz požadavky na funkcionalitu v kapitole 4).

3.3 KVANTITATIVNÍ POŽADAVKY

3.3.1 ROZSAH UŽITÍ SOFTWARE

Systém svou funkčností a výkonem (za předpokladu, že jsou splněny požadavky na výpočetní výkon použité infrastruktury) obslouží hladce požadavky uživatelů v rozsahu:

1) aktuálně maximálně 6.000 studentů studujících v akademickém roce, přičemž zadavatel garantuje nepřekročení tohoto počtu, tzn. nepředpokládá se rostoucí tendence;

2) celkový počet uživatelů obecně přistupujících do systému je cca 10.000, přičemž může narůstat, takže lze obecně hovořit o neomezeném počtu;

3) z toho:

i. cca 100 uživatelů v roli vedoucího (popř. analogické, např. správce uzlu, nadřízený manažer),

ii. aktuálně 3 správci definic a procesů (v roli metodika NIS, popř. analogické, např. 1. úroveň podpory);

iii. aktuálně 2 administrátoři Systému (IT odborník).

3.3.2 ROZSAH ZPRACOVÁVANÝCH INFORMACÍ

Systém svou funkčností a výkonem (za předpokladu, že jsou splněny požadavky na výpočetní výkon použité infrastruktury) obslouží hladce požadavky uživatelů při zpracování dat v objemu odpovídajícím počtu studentů čítajícího řádově cca desítky miliónů datových transakcí ročně (zadavatel odhaduje, že v případě studijní agendy se jedná o více než 110 miliónů transakcí ročně).

3.4 VÝKON A ODEZVA

Systém splní dlouhodobě odezvu na požadavek klienta (uživatele) průměrně do 3 (tří) vteřin a maximálně do 7 (sedmi) vteřin.

3.5 PROSTŘEDÍ PRO PROVOZ A PŘÍSTUP K SYSTÉMU

Nasazení Systému v prostředí dodavatele bude v rámci implementačních prací realizováno do produkčního prostředí, jehož přípravu zajistí dodavatel, tzn. kompletní outsourcing.

3.6 BEZPEČNOST

Systém splní následující charakteristiky, vlastnosti a parametry bezpečnosti:

1) K systému budou uživatelé zadavatele přistupovat prostřednictvím počítačů připojených k internetu s nainstalovaným webovým prohlížečem. Systém si vyžádá připojení zabezpečeným protokolem typu HTTPS, jiný typ spojení Systém odmítne.

2) Systém přístupových práv s možností delegování na osoby, role či organizační jednotky a řešení zastupitelnosti, plánované i neplánované.

3) Zakódování názvu souborů, popř. náhodně distribuované uložení obsahu, které znemožní bez rozhraní NIS přímo přistupovat k obsahu (souborů) na úrovni OS (privilegovaným přístupem administrátora).

4) Správnost a úplnost informací uložených v Systému ve smyslu validace zadávaných hodnot (např. kontrola typu, rozsahu apod.) a jejich mandatornosti (povinná pole).

3.7 OSTATNÍ POŽADAVKY

1) Centrální správa všech konfigurací Systému v jednom uživatelském prostředí.

2) Všechna chybová hlášení produkovaná Systémem musí být srozumitelná tak, aby se uživatelé mohli rozhodnout, jak dále postupovat, jestli kroky opakovat, nebo operaci zrušit, popř. nahlásit vadu.

3) Pravidla a chování uživatelského rozhraní Systému jsou konzistentní v celém Systému (např. rozmístění panelů nástrojů v oknech či příkazů v menu, ovládání formulářů apod.).

4) Často prováděné operace (např. otevření dokumentu) musí být navrženy tak, aby mohly být provedeny malým počtem interakcí.

4 FUNKČNÍ POŽADAVKY NA ZADÁVANÉ ŘEŠENÍ

Tato kapitola popisuje minimální požadavky na funkčnost zadávaného řešení a ve svých podkapitolách současně funkční požadavky kladené na jednotlivé komponenty, resp. moduly Systému.

Požadavky na funkčnost NIS se sestávají ze souborů dílčích požadavků rozdělených mezi požadavky na funkčnost NIS dané příslušnou legislativou a bližší požadavky na konfiguraci NIS v prostředí zadavatele. Těmi jsou myšleny zejména požadavky na bohatší funkčnost, než stanovuje legislativa, nebo ještě bližší určení funkčnosti (specifika zadavatele, parametry funkčnosti apod.), ve větší míře detailu. Pro účely zakázky jsou všechny uvedené požadavky chápány jako celek mandatorních požadavků na NIS.

4.1 RÁMEC POŽADAVKŮ NA FUNKČNOST DANÝ LEGISLATIVOU

Požadavky na NIS dané legislativou jsou dány výčtem norem, které je zadavatel povinen dodržovat, a v těchto normách pak vybranými ustanoveními aplikovatelnými na zadavatele podle jeho specifické situace.

Dotčená legislativa podle předchozího odstavce je následující:

1) zákon č. 111/1998 Sb. o vysokých školách (dále jen „zákon o vysokých školách“ nebo „VŠkZ“);

2) zákon č. 499/2004 Sb. o archivnictví a spisové službě a o změně některých zákonů, dále jen „zákon o archivnictví“;

3) vyhláška č. 259/2012 Sb. o podrobnostech výkonu spisové služby, dále jen „vyhláška ke spisové službě“;

4) Národní standard pro elektronické systémy spisové služby (dále jen „Národní standard“ nebo

„NSESSS“);

5) zákon č. 297/2016 Sb. o službách vytvářejících důvěru pro elektronické transakce;

6) zákon č. 300/2008 Sb. o elektronických úkonech a autorizované konverzi dokumentů;

7) vyhláška č. 193/2009 Sb. o stanovení podrobností provádění autorizované konverze dokumentů;

8) vyhláška č. 194/2009 Sb. o užívání a provozování informačního systému datových schránek. vše ve znění pozdějších předpisů a s ohledem na ustanovení souvisejících norem.

Současně zadavatel požaduje, aby navržené řešení respektovalo související dále uvedené normy a v nich požadovaná technická opatření kladená na IS typu NIS v kontextu charakteru daného zadavatele, zejména aby umožnovalo budoucí přizpůsobení NIS na základě opatření přijatých zadavatelem za účelem splnění požadavků těchto norem:

a) Nařízení Evropského parlamentu a Rady (EU) 2016/679 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů (obecné nařízení o ochraně osobních údajů, dále jen „GDPR“) a s ohledem na pravděpodobný časový průnik platnosti GDPR pro ČR, resp. účinnosti nového zákona o zpracování osobních údajů s dobou implementace projektu také tento nový zákon;

b) vyhlášky a metodiky navazující na GDPR, zejména metodický pokyn MV ČR „Ochrana osobních údajů při výkonu spisové služby, zejména v informačních systémech spravujících dokumenty u veřejnoprávních původců“ (viz xxxx://xxx.xxxx.xx/xxxxxx/xxxxxxxx-xxxx-xxxxxxx-xxxxxxxx- udaju-pri-vykonu-spisove-sluzby-zejmena-v-informacnich-systemech-spravujicich-dokumenty-u- verejnopravnich-puvodcu.aspx).

4.2 OBLASTI FUNKCIONALITY SYSTÉMU

Funkcionalita Systému je sestavena z požadavků dále uvedených v jednotlivých podkapitolách. Funkčnost NIS je členěna do základních agend, které se dále dělí do jednotlivých funkcí, operací či procesů. Členění požadavků na funkčnost NIS nemusí odpovídat členění jednotlivých nabídek uživatelského prostředí Systému.

4.2.1 PŘIJÍMACÍ ŘÍZENÍ

4.2.1.1 Uchazeč o studium

Požadovaná funkcionalita je následující:

▪ podání přihlášky, zadání identifikačních údajů osoby uchazeče a příslušného studijního programu/studijního oboru;

▪ podání více přihlášek najednou;

▪ kontrola úplnosti povinných údajů v přihlášce;

▪ jazyková mutace přihlášky pro studium v cizím jazyce (angličtina);

▪ sledování celého procesu přijímacího řízení;

▪ úhrada poplatku platební kartou anebo získání platebních podmínek pro realizaci platby převodem;

▪ zobrazení informace o přijetí úhrady na straně školy;

▪ dostupnost údajů uchazeči o termínu a místu přijímací zkoušky;

▪ volba doručení dokumentů prostřednictvím NIS (soulad s VŠkZ a Statutem).

4.2.1.2 Administrace přijímacího řízení – studijní oddělení

Požadovaná funkcionalita je následující:

▪ nastavení akreditovaných studijních programů/oborů pro zveřejnění podmínek přijímacího řízení příslušného akademického roku;

▪ nastavení zahájení správního řízení na úkon – podání elektronické přihlášky;

▪ zasílání hromadného e-mailu uchazečům z kontextu administrace příjímacího řízení;

▪ tisk složky pro příjímací komisi;

▪ vytváření a realizace testů přijímacího řízení na PC;

▪ sběr a export dat pro nadřízená ministerstva a další ústřední orgány;

▪ import výsledků ze SCIO testů (testy jsou realizovány mimo SU);

▪ evidence všech dokumentů (výzva, pozvánka, rozhodnutí o ne/přijetí, odvolání) souvisejících s jednou přihláškou v jednom spise (funkce eSSL);

▪ možnost nastavení data doručení, nabytí právní moci a dalších údajů v eSSL, a to s ohledem na způsob doručení a příslušnou odvolací lhůtu;

▪ možnost doručování rozhodnutí a dalších dokumentů prostřednictvím IS (soulad s VŠkZ a vnitřními předpisy SU).

4.2.1.3 Elektronická přihláška k dalším formám vzdělávání

Požadovaná funkcionalita je následující:

▪ výběr kurzů, akreditovaných kurzů, CŽV, U3V;

▪ přihlášení k vybrané aktivitě a on-line úhrady poplatku.

4.2.2 STUDIJNÍ AGENDA – „STUDENT“

4.2.2.1 Zahájení studia – zápis do studia

Požadovaná funkcionalita je následující:

▪ přístup do všech potřebných agend studijní agendy;

▪ aktualizace osobních údajů, především kontaktních údajů (adresa určená k doručování a adresa datové schránky) a bankovního spojení;

▪ podání žádosti o ubytování na koleji;

▪ podání žádosti o ubytovací či sociální stipendium s kontrolou na splnění nutných podmínek (součást obecné funkčnosti „žádosti studentů“).

4.2.2.2 Průběh studia

Požadovaná funkcionalita je následující:

▪ podávání žádostí v průběhu studia (náhradní termín zápisu, zanechání studia, zrušení registrace, změna zařazení do skupiny studia, uznávání zápočtů a zkoušek, přerušení studia apod.):

🢭 zaevidování žádosti do eSSL v souladu s typem žádosti;

🢭 možnost podání žádosti ve formě analogového dokumentu, digitálního dokumentu nebo prostřednictvím elektronické žádosti v Systému;

▪ výběr tématu seminární práce či referátu;

▪ odeslání e-mailu vyučujícímu předmětu (mimo eSSL) z kontextu předmětu;

▪ odevzdávání úkolů (např. seminární práce, prezentace, projektu) elektronicky;

▪ zobrazení odevzdaných úkolů za aktuální akademický rok či semestr;

▪ přehled splněných studijních povinností;

▪ evaluace studia – anonymní vyjádření ke kvalitě výuky;

▪ nastavení a odesílání automatických informačních e-mailů dle různých událostí týkajících se studia;

▪ přehled o všech dokumentech a spisech souvisejících se studiem podléhajících evidenci v eSSL, zejména způsobu a době vyřízení;

▪ možnost podání odvolání a žádostí prostřednictvím NIS.

4.2.2.3 Zahájení semestru

Požadovaná funkcionalita je následující:

▪ registrace předmětu pro následující semestr;

▪ kontrola splnění podmínek – povinné předměty, povinně volitelné předměty, množství kreditů;

▪ žádost studenta o registraci předmětu – výjimky (nesplňuje-li student prerekvizity);

▪ zobrazení či tisk rozvrhu;

▪ vyhledávání předmětů dle různých kritérií.

4.2.2.4 Konec semestru

Požadovaná funkcionalita je následující:

▪ přihlášení se na termín zápočtu, zkoušky – řádný či opravný (popř. druhý opravný);

▪ informace o výsledku zkoušky, splnění podmínek pro udělení zápočtu

🢭 přístup ke skenu opraveného písemného testu;

🢭 přístup k přehledu o odpovědích v případě elektronického testu;

▪ kontrola splnění studijních povinností pro zápis do dalšího semestru/akademického roku.

4.2.3 STUDIJNÍ AGENDA – „PEDAGOG“

4.2.3.1 Obecná funkčnost

Požadovaná funkcionalita je následující:

▪ vytváření hromadných e-mailů studentům z kontextu předmětů, seminárních skupin apod.;

▪ tisk seznamů studentů a prezenčních listin podle různých kritérií;

▪ přístup k výsledkům evaluace;

▪ nastavení (komu, kdy) a odesílání automatických informačních e-mailů dle různých událostí souvisejících se studiem;

▪ možnost průběžného hodnocení studenta.

4.2.3.2 Příprava akademického roku

Požadovaná funkcionalita je následující:

▪ vytvoření a správa harmonogram akademického roku, semestru;

▪ vypsání programu k předmětům (požadavky na studenta, podmínky pro udělení zápočtu/zkoušky, seznam literatury ke studiu);

▪ tvorba studijního plánu (vyučující, garanti, rozvrh, seminární skupiny, prerekvizity, typy předmětů, minimální zisky ve skupinách předmětů);

▪ založení seminární skupiny a nastavení kapacity skupiny;

▪ tisk studijních plánů; export údajů ve formátu pro sazbu tištěného katalogu;

▪ tvorba a zveřejnění rozvrhu.

4.2.3.3 Výuka během semestru

Požadovaná funkcionalita je následující:

▪ realizace zápočtových a zkouškových testů v elektronické formě;

▪ zveřejnění nejrůznějších typů studijních materiálů s přístupem pro studenty zapsané do předmětu;

▪ zadávání témat seminárních prací;

▪ přehled o odevzdaných úkolech studentů v rámci předmětu;

▪ kontrola odevzdaných prací na plagiátorství;

▪ sestavy: průzkumy/dotazníky a zjišíovat zpětnou vazbu od studentů;

▪ elektronické záznamy o presenci studentů na rozvrhových akcích.

4.2.3.4 Zkouškové období

Požadovaná funkcionalita je následující:

▪ vypsání zkušebních termínů a přihlášení/odhlášení studenta k/ze zkušebního termínu bez kontroly;

▪ hodnocení studentů a evidence údajů o výsledku hodnocení studia;

▪ elektronická forma ověřování výsledků studia (zápočtové a zkušební testy);

▪ kontrola limitu počtu opravných termínů studenta na předmětu.

4.2.4 STUDIJNÍ AGENDA – ABSOLVENTSKÉ ŘÍZENÍ (UKONČENÍ STUDIA)

Požadovaná funkcionalita je následující:

▪ zadání tématu VŠKP; evidence témat;

▪ výběr a navržení tématu VŠKP studentem;

▪ odevzdání VŠKP s kontrolou na plagiátorství;

▪ evidence posudků VŠKP v elektronické podobě;

▪ zveřejnění VŠKP, posudků a záznamu o průběhu obhajoby v souladu s vnitřními předpisy SU;

▪ zpřístupnění průběhu absolventského řízení v NIS studentovi/absolventovi (xxxxxxx, návrhy na složení zkušebních komisí);

▪ závěrečná zkouška:

🢭 elektronická přihláška k závěrečné zkoušce (složení komise, termín, místo) a možnost generování tištěného výstupu;

🢭 evidence všech požadovaných dokumentů.

4.2.5 STUDIJNÍ AGENDA – ADMINISTRACE – „STUDIJNÍ REFERENTKA“

Xxxxxx realizuje obvykle studijní oddělení, některé okruhy činností se mohou realizovat i na jiných pracovištích (věda a výzkum, zahraniční styky atp.) dle popisu příslušného pracovního místa.

Požadovaná funkcionalita je následující:

▪ hromadné zasílání e-mailu skupinám studentů/uchazečů s propojením na eSSL;

▪ evidence přijímacího řízení od podání přihlášky po zaslání rozhodnutí (možnost doručování prostřednictvím NIS);

▪ evidence studia v rozsahu, který vyžaduje legislativa (vysokoškolský zákon, SIMS, vnitřní předpisy SU);

▪ evidence VŠKP a průběhu a výsledku závěrečné zkoušky;

▪ nástroje pro hromadné výběry studentů/uchazečů dle různých kritérií a generování příslušných výstupů (PDF, tisk);

▪ evidence stáží a studijních pobytů/mobilit v průběhu studia;

▪ podpora kontroly plnění studijních povinností na konci semestru/ročníku;

▪ vytváření statistik dle požadavků nadřízených orgánů a vedení fakult a SU (manažerské výstupy);

▪ evidence stipendií od okamžiku podání žádosti (písemně/elektronicky) přes proces posouzení podmínek pro přiznání stipendia, vystavení rozhodnutí s využitím volitelné šablony, zveřejnění/doručení rozhodnutí o přiznání prostřednictvím NIS a propojení evidence v eSSL;

▪ vyměřování poplatků za studium (určení předpokládaného data povinnosti hradit poplatek za studium zpřístupněný studentovi, vyměření poplatku, vystavení rozhodnutí s využitím volitelné šablony, propojení s evidencí v eSSL);

▪ tisk potvrzení o studiu;

▪ evidence trvalého bydliště a adresy určené k doručování (včetně ID DS);

▪ tisk vysokoškolského diplomu, dodatku k diplomu, zápisu o státní závěrečné zkoušce a dalších dokladů podle § 57 VŠkZ (doklad o vykonaných zkouškách, výkaz o studiu);

▪ nástroje pro tvorbu rozvrhu se zohledněním kolizí.

4.2.6 Administrace studijních programů, oborů, předmětů a kurzů

Požadovaná funkcionalita je následující:

▪ evidence všech součástí studijního programu v souladu s § 44 VŠkZ – název a profil, profil absolventa, charakteristika studijních předmětů, pravidla a podmínky pro vytváření studijních plánů popř. údaje o praxi, splnění podmínek v průběhu a na závěr studia, udělovaný akademický titul, určení oblasti vzdělávání;

▪ evidence státní rigorózní zkoušky, která není součástí studia;

▪ správa akreditací studijních programů.

4.2.7 SPISOVÁ SLUŽBA

Zadavatel vyžaduje soulad agendy spisové služby s platnou legislativou (viz kapitola 4.1), včetně podzákonných norem. Dále je vyžadována plná integrace agendy do NIS. Proto se funkce uvedené v této části mohou nacházet i v jiných agendách, na které funkcionality eSSL v určitém místě navazují. Především v agendách pro studijní oddělení a další pracoviště, která komunikují se studenty. Níže uvedené funkce mohou také fungovat na pozadí jiných funkcí, především u funkcí vytvářejících různé typy rozhodnutí, která musí být evidována a zpracována v souladu se správním řádem.

Za kalendářní rok 2017 bylo v aktuálním eSSL zadavatele zaevidováno 50 tisíc dokumentů, z toho necelých 30 tisíc na studijních odděleních.

4.2.8 FUNKCIONALITA UPŘESŇUJÍCÍ NEBO ROZŠIŘUJÍCÍ POŽADAVKY NA ESSL

4.2.8.1 Organizační struktura a spisové uzly

Distribuce dokumentů v eSSL bude probíhat mezi spisovými uzly. Spisové uzly tvoří hierarchickou stromovou strukturu, která přibližně kopíruje organizační uspořádání zadavatele s ohledem na umístění uživatelů – referentů eSSL. Ke dni 1. 6. 2018 obsahovaly číselníky aktuálního eSSL následující počty aktivních objektů:

▪ spisové uzly: 113 ;

▪ funkční místa: 179 ;

▪ uživatelé eSSL: 161 .

4.2.8.2 Spisový řád, spisový a skartační plán

Spisový řád je vydán formou směrnice rektora číslo 03/2018 a je uveden v příloze č. 5 ZD.

4.2.8.3 Podatelny a výpravny

Zadavatel provozuje dvě podatelny, které zajišíují příjem i vypravení všech písemností. Jedna podatelna je provozována v Opavě (dále jen „ústřední podatelna“) a druhá v Karviné.

Elektronická podatelna pro elektronická podání, tj. zejména příjem datových zpráv ze systému ISDS a zpracování elektronických podání na e-podatelně, bude obsluhována uživateli na ústřední podatelně.

4.2.8.4 Příjem doručených analogových dokumentů

Přijatý analogový dokument je na podatelně referentkou podatelny zpracováván následujícím postupem (originál analogového dokumentu má k tomu k dispozici):

1) označení analogového dokumentu čárovým kódem (viz níže);

2) naskenování analogového dokumentu (viz níže);

3) zaevidování dokumentu v eSSL; při evidenci jsou vyplněny nejméně následující údaje v metadatech dokumentu:

▪ čárový kód označující analogový dokument;

▪ odesílatel;

▪ datum přijetí;

▪ název;

▪ počet listů;

▪ podací číslo atd.

4) načtení skenu analogového dokumentu do eSSL k danému záznamu prostřednictvím automatické funkce, kdy je sken dokumentu nahrán k metadatům dokumentu v eSSL;

5) předání dokumentu prostřednictvím eSSL adresátovi/zpracovateli, který po přijetí dokumentu potvrdí v eSSL jeho převzetí.

4.2.8.5 Použití čárového kódu

4.2.8.5.1 Označování analogových dokumentů čárovým kódem

Nedílnou a významnou součástí procesu evidence analogových dokumentů je také propojení analogového dokumentu (originálu) s odpovídající položkou v evidenci eSSL a s jeho naskenovanou podobou (konceptem, dokumentem v úložišti dokumentů), a to pomocí označení čárovým kódem (nalepením předtištěného štítku) jako jednoznačného identifikátoru, který nelze použít v systému nikdy vícekrát (souvislá a systematická řada jednoznačných identifikátorů bez duplicit).

Struktura čárového kódu bude obsahovat označení zkratkou původce, rok, podatelnu (lokalitu) a pořadové číslo, např. SUNI18Opv012345 (např. „Opv“ jako pracoviště „Opava“). Předpokládá se použití nejrozšířenějších typů používaných kódování čárových kódů (typicky Code 128 nebo Code 39). Grafická podoba čárového kódu bude obsahovat samotný čárový kód a pod ním jeho textovou interpretaci, to vše vytištěno na samolepících štítcích vhodného rozměru, tzn. co nejmenší při zachování dobré vizuální i strojové čitelnosti. Použité typy čárových kódů budou zajišíovat takřka 100 % strojovou čitelnost a rozpoznání použitým skenovacím subsystémem a současně s použitím kódování co nejvíce zamezující záměnu s případnými jinými čárovými kódy na dokumentu již přítomnými.

Zadavatel požaduje dodání předtištěných samolepících štítků s čárovým kódem vyhovujícím uvedeným parametrům, které budou upřesněny výstupy z analýzy detailních požadavků. Počet takových předtištěných štítků musí být nejméně 10 tisíc pro každou podatelnu ve smyslu podacího místa (fyzická lokalita) za rok.

4.2.8.5.2 Skenování analogových dokumentů a jejich strojové čtení

Zadavatel má vytvořen skenovací subsystém, který umožňuje skenovat analogové dokumenty opatřené čárovým kódem. Skenování analogových dokumentů je zajištěno prostřednictvím dokumentových skenerů Fujitsu využívajících software Kofax (především podatelny a studijní oddělení) a prostřednictvím multifunkčních tiskových center Konica Minolta (dále jen „MFP“) (ostatní spisové uzly).

Výstupem ze skenovacího subsystému je sken analogového dokumentu ve formátu prohledávatelného PDF. Název PDF souboru obsahuje čárový kód (jeho textovou interpretaci). Takto digitalizované dokumenty jsou umístěny na dočasné sdílené úložiště (dále jen „dočasné úložiště“). Jak v případě skenování na dokumentovém skeneru s použitím software Kofax, tak i v případě skenování na MFP, je výstup stejný. Strojové čtení textu (OCR) za účelem vytvoření prohledávatelného PDF zajišíuje napojení na ABBYY Recognition Server.

Pro zajištění výše uvedeného procesu zadavatel vyžaduje tuto minimální funkčnost Systému (NIS):

▪ zajištění skenů dokumentů z obou digitalizačních zařízení a nahrání do eSSL;

▪ zajištění převodu do prohledávatelného PDF;

▪ evidence jednoznačného identifikátoru ztvárněného v čárovém kódu, kterým byl původní analogový dokument označen, v metadatech dokumentu v eSSL.

4.2.8.5.3 Generování čárových kódů na vytvářených dokumentech

V případě vytvářených dokumentů požaduje zadavatel, aby Systém zajistil generování čárového kódu s jednoznačným identifikátorem dokumentu na dokument samotný v cílovém formátu před dalším zpracováním, například s použitím příslušně upravené a připravené šablony dokumentu typu Microsoft Word. Šablona dokumentu v takovém případě obvykle obsahuje prostor (zástupný rámec, pole či symbol), do kterého bude čárový kód generován s použitím identifikátoru z eSSL před převodem do cílového formátu. eSSL musí zajistit vygenerování takového jednoznačného identifikátoru samostatnou řadou.

4.2.8.6 Příjem obvykle neotevíraných obálek

Zadavatel zajistí organizačním opatřením, že v případě obálek označených na prvním místě adresáta názvem zadavatele a současně označením „do vlastních rukou“ bude podatelna oprávněna tyto otevřít a zpracovat standardním způsobem, neboí toto označení podle zákona č. 500/2004 Sb., správní řád a jeho § 21, odst. (2) znamená oprávnění převzít orgány a osobami uvedenými v § 30 (osoby oprávněné činit úkony jménem právnické osoby) nebo jinými osobami, které byly pověřeny písemnosti přijímat, tedy obvykle zaměstnanci podatelny.

Pro případ písemností, kdy před jménem zadavatele je uvedeno jméno osoby, a má se tedy za to, že jde

o soukromou korespondenci dané osobě, zadavatel zajistí organizačním opatřením, že zaměstnanci podatelny takové obálky neotevírané předají bez záznamu v eSSL adresátu (dané osobě). Pokud adresát následně zjistí (po rozbalení zásilky), že jde o věc úřední, tak danou písemnost dodatečně řádně zaeviduje na podatelně.

V případě písemností, které otevírány být nesmí z důvodů splnění některé zákonné povinnosti, typicky nabídky ve veřejných zakázkách označené nápisem „NEOTEVÍRAT!“, bude samolepícím štítkem s čárovým kódem označena a jednoznačně identifikována už obálka, která se tak stane první stranou přijatého dokumentu. Zadavatel po rozbalení zajistí dodatečné doplnění obsahu dokumentu do eSSL.

4.2.8.7 Elektronická podatelna

Elektronické dokumenty přijaté na adresu elektronické podatelny x-xxxxxxxxx@xxx.xx (tzv. „úřední“ emaily) bude evidovat ústřední podatelna v Opavě. Elektronické dokumenty dodané na adresy pracovníků SU, které tito budou považovat za úřední, budou jimi přeposlány na adresu elektronické podatelny.

Elektronická podatelna zpracuje zprávu elektronické pošty dodanou na elektronickou podatelnu tak, že vznikne dokument, jehož první komponentou bude tělo zprávy elektronické pošty a dalšími komponentami budou všechny přílohy (soubory) dané zprávy (nebo obdobným způsobem, který zpracuje tělo a přílohy, přičemž zachová nezaměnitelnou perzistentní vazbu mezi tělem a přílohami).

4.2.8.8 Komunikace prostřednictvím ISDS

Doručené datové zprávy (dále jen „DZ“) jsou u zpracovatele přijímány a zpracovávány výhradně na ústřední podatelně.

Pro zpracování odesílaných zpráv je požadována následující funkcionalita:

▪ v případě, že je u příjemce vyplněno (známo) ID datové schránky, pak NIS automaticky vytvoří elektronický dokument (obvykle konverzí do PDF), který se po podpisu autorizovanou osobou stane digitálním a v případě odeslání nasměřuje dokument do datové schránky příjemce;

▪ možnost elektronicky podepsat kvalifikovaným elektronický podpisem, připojit kvalifikované časové razítko – a to i hromadně (v případě studijní agendy);

▪ dohledání ID DS přes eSSL.

Přestože ZFO není definován ve výstupních formátech dle § 23 odst. 1 písm. c) vyhlášky ke spisové službě, tak u dodaných DZ požadujeme ukládat kromě obsahu podání i celé původní podání ve formátu ZFO, neboí v něm je obsaženo časové razítko zprávy, které lze vztáhnout na dokumenty v datové zprávě obsažené, i když bude razítko založeno na již expirovaném certifikátu.

Zároveň je požadována automatická kontrola autentizačních prvků (elektronický podpis, elektronická pečeí a elektronické časové razítko) i u datové zprávy a zaznamenání výsledku (§ 4 odst. 4 a násl. vyhlášky ke spisové službě).

Doručenka generovaná ISDS je dokument a pokud je v datovém formátu ZFO, je nutné ji při vyřízení dokumentu nebo uzavření spisu převést do výstupního datového formátu PDF/A.

4.2.8.9 Integrace eSSL se studijní agendou

Při zakládání dokumentů a spisů souvisejících se studiem se použijí údaje z NIS. Při tom vždy vzniká elektronický dokument, který je později elektronicky podepsán (digitální dokument). Při integraci je požadováno:

▪ dle typu dokumentu (viz NSESSS kap. 4.3) může být v průběhu zpracování vytvořen digitální nebo analogový dokument, a dále dle typu dokumentu se doplňují údaje pro ukládání (spisový znak a skartační znak a lhůta);

▪ nastavení jednotného způsobu vedení spisu (pomocí sběrného archu);

▪ možnost vytvořit a zobrazit přehled písemností za konkrétní studium;

▪ vstup akademických pracovníků do agendy spisové služby umožňuje verifikaci příslušných dokumentů (schvalování, hromadné podepisování, připomínkování).

4.2.8.10 Vytváření spisů

Primárně budou spisy vytvářeny pomocí sběrného archu, přičemž většina spisů vzniká na studijních odděleních. Při distribuci dokumentu z podatelny se u konkrétního zpracovatele dokument nejprve zobrazí jako nezařazený a následně z něho bude buď založen nový spis, nebo bude zařazen do spisu existujícího. Vložením do spisu bude dokumentu přiděleno číslo jednací. Základ čísla jednacího všech dokumentů ve spisu (tvořící označení samotného spisu – spisovou značku) se odvozuje od čísla jednacího iniciačního dokumentu. Dokumenty tak, jak jsou zapisovány do sběrného archu, dostávají k označení spisu pořadové číslo (přírůstkově vždy o jedno vyšší než předchozí v rámci spisu) a tak je tvořeno jejich číslo jednací.

V situaci, kdy není nutné pro dokument vytvářet spis, např. je použito vyřízení odpovědí, takže by bylo možné využít přiřazení dokumentu ne ke spisu, ale pouze k věcné skupině, zadavatel požaduje navrhnout řešení, jak v dodavatelem nabízeném eSSL tuto situaci řešit, zdali je vždy nutné zakládat spis apod.

Současně je požadováno splnění následujících elementárních funkčností nad rámec normativních požadavků:

▪ tvorba, znázornění a export spisů v XML a jiném uživatelsky srozumitelném formátu;

▪ vedení typových spisů;

▪ možnost nastavit mechanismus vytváření názvu spisu nebo typového spisu (student, zaměstnanec, projekt…);

▪ dohledání dokumentů/spisů za studium předaných do spisovny pomocí identifikace tohoto studia.

4.2.8.11 Vazba na systém E-ZAK (veřejné zakázky)

Požadovaná funkcionalita je následující:

▪ napojení eSSL na systém E-ZAK (např. evidence zadávacích řízení, dokumentů, zpráv vč. elektronických podání nabídek) zahrnující funkce pro:

a) záznam o zadání;

b) výzva k podání nabídek;

c) zadávací dokumentace příp. výzva vč. zadávací dokumentace;

d) vysvětlení zadávací dokumentace;

e) protokol o otevírání nabídek;

f) protokol o posouzení nabídek;

g) zpráva o hodnocení nabídek;

h) rozhodnutí (o výběru, o zrušení, o vyloučení apod.);

i) oznámení (o výběru, zrušení, vyloučení apod.);

j) námitky, rozhodnutí úřadu;

k) xxxxxxx;

l) písemná zpráva zadavatele.

Napojení na systém EZAK požadujeme minimálně následujícího obsahu a rozsahu:

i) Technické rozhraní pro integraci musí být realizováno pomocí webových služeb.

ii) V komunikaci mezi systémy musí být přenášena metadata i soubory.

iii) Rozhraní musí systému EZAK umožnit nejméně:

▪ založit a editovat spis;

▪ založit písemnost s případnou editací;

▪ zrušit spis a dokument;

▪ uzavřít spis.

4.2.8.12 Digitální a analogová forma dokumentu

Požadovaná funkcionalita je následující:

▪ Zaznamenat formu komponenty dokumentu „koncept“, „originál“, „originál ve výstupním datovém formátu".

▪ Pokud je dokument označen jako analogový, musí existovat jeho analogový originál, digitální komponenty (např. i pořízené prosté digitální reprodukce) není povinné převádět do výstupního datového formátu a v datovém balíčku SIP se označí jako „koncept“.

▪ Pokud je dokument označen jako digitální, nemusí existovat jeho analogová kopie nebo stejnopis. Jeho komponenty však musí být vždy převedeny v souladu s § 23 vyhlášky ke spisové službě do výstupního datového formátu, pokud je stanoven a v datovém balíčku SIP označeny jako „originál ve výstupním datovém formátu“. V případě doručených dokumentů, které ve výstupním datovém formátu nebyly, mohou být navíc do SIP vloženy původní doručené komponenty a označeny jako „originál“.

▪ V případě neschválených (zamítnutých) konceptů, tj. tam, kde nevznikl ani v digitální ani v analogové formě schválený dokument, je nezbytné poslední verzi konceptu deklarovat jako dokument, převést ji do výstupního datového formátu a nakládat s ní jako s digitálním dokumentem (požadavek 2.1.2 NSESSS).

4.2.8.13 Ponechání vyřizujícího dokumentu pro výkon spisové služby

Vyřizující dokument může být odesílán v digitální i v analogové podobě (podle jednotlivých adresátů). Zároveň musí být ponechán „pro výkon spisové služby prvopis vyhotoveného dokumentu, popřípadě jeden ze stejnopisů prvopisu vyhotoveného dokumentu“ (§ 16 odst. 3 vyhlášky ke spisové službě).

V případě, že prvopisem bude digitální dokument, není nutné ponechávat pro výkon spisové služby stejnopisy listině odesílaných dokumentů, které se tak vyhotoví pouze pro adresáta a odešlou se. V případě orgánů veřejné

moci dle zákona č. 300/2008 Sb. není navíc nutné vytvářet listinný stejnopis vedle digitálního prvopisu, ale postačí převedení digitálního prvopisu autorizovanou konverzí do listinné podoby, která se následně odešle.

4.2.8.14 Tvorba dokumentů

Pro tuto oblast funkcí požadujeme splnění následujících elementárních funkčností nad rámec normativních požadavků:

▪ tvorba dokumentů, resp. konceptů ve smyslu NSESSS;

▪ verzování dokumentů, resp. konceptů;

▪ vygenerování dokumentu ze šablony v eSSL, online (tzn. runtime) napojení editorů formátů Microsoft Office, zejména Word a Excel;

▪ uživatel v eSSL zadá příkaz např. k odpovědi a po zadání metadat a výběru šablony dojde k otevření textového editoru s novým dokumentem na základě zvolené šablony, ideálně s předvyplněnými položkami textu z metadat;

▪ autor dokumentu by měl jeho tvorbu ukončit v editoru (v tomto případě MS Word) a to buď včetně konverze do PDF, nebo následná konverze proběhne v eSSL;

▪ případné připojení elektronického podpisu by mělo být realizováno řízeně funkcí eSSL;

▪ ne každý dokument vytvořený v MS Word musí být konvertován;

▪ generování čárového kódu s jednoznačnou identifikací na dokumenty před převodem do výstupního datového formátu (PDF);

▪ automatické doplnění metadat ze spisu/dokumentu do těla dokumentu na místa určená metaznaky (pole);

▪ hromadné vytvoření a zpracování a vyřízení vlastních typově shodných dokumentů;

▪ nastavení a zajištění upozornění (nepřiložena příloha, nepodepsán dokument, nepřidělen spisový znak/skartační režim, chyba formátu, chyba na příjmu, chyba vypravení apod.);

▪ hromadné elektronické podepisování a připojení kvalifikovaného el. časového razítka připravených dokumentů ve formátu PDF/A;

▪ připojit k dokumentu libovolné množství příloh.

4.2.8.15 Vyřizování dokumentů

Pro tuto oblast funkcí požadujeme splnění následujících elementárních funkčností nad rámec normativních požadavků:

▪ zajištění automatizované urgence a eskalace termínu vyřízení dle nastavení a nastavitelné parametry (čas, způsob, tzn. adresáti dle rolí/uzlů);

▪ pohled na dokumenty dle termínu vyřízení (blízko termínu/lhůty, po termínu);

▪ nastavení a řízení schvalování (obecně oběhu) dokumentů (sériově, paralelně);

▪ podpora nastavitelných workflow spojených se zpracováním smluv (např. návrh, připomínkování, schvalování, zveřejnění);

▪ převod záznamů o dokumentech a dokumentů na nástupce (jinou roli) při změně pracovního poměru zaměstnance, zrušení role apod.;

▪ zajištění zastupitelnosti a jejího nastavení, a to nečekaně i plánovaně (nemoc, dovolená);

▪ funkce pro záznam ztráty nebo poškození dokumentu;

▪ funkce pro nastavení systému tak, aby spis a jednotlivé dokumenty v něm zařazené přijímaly skartační znak a lhůtu podle nejpřísnější z dokumentů ve spisu zařazených;

▪ automatické zasílání notifikace na e-mailové adresy příslušných uživatelů (autor, zpracovatel, nadřízený apod.) o předání dokumentu ke zpracování, vč. agregace takových notifikací do souhrnu, např. sloučit všechna avíza pro jednoho uživatele za posledních 24 hodin do jedné e-mailové zprávy.

4.2.8.16 Odesílání dokumentů

V případě vypravení listovních zásilek a balíků podatelny/výpravny přijímají od odesílatelů tyto zásilky zalepené/zabalené, označené adresátem, číslem jednacím a číslem zásilky. Zadavatel požaduje generování a evidenci těchto údajů v eSSL. Současně zadavatel požaduje vyznačení stavu odesílaného dokumentu (že je předán výpravně k odeslání) a informace, o jaký typ zásilky se jedná (způsob odeslání).

Pro tuto oblast funkcí požadujeme splnění následujících elementárních funkčností nad rámec normativních požadavků:

▪ funkce pro zaevidování odeslání dokumentu kurýrem, faxem, přes dedikovaný portál (např. portály grantových agentur, centrální databáze);

▪ funkce pro tisk údajů o adresátu na obálky a možnost konfigurace těchto údajů pro tisk na obálku, vč. jednoznačné identifikace dokumentu v obálce, nebude-li řešeno jinak;

▪ funkce pro hromadný tisk na obálky k vybraným zásilkám;

▪ funkce pro zadání, resp. výběr způsobu a parametrů vypravení podle požadavků České pošty, s.p., zejména:

🢭 doporučeně;

🢭 obyčejně;

🢭 na dobírku;

🢭 váha;

🢭 cena (výběrem, zadáním, nebo na základě váhy).

V případě, že je dokument k odeslání přímo připraven k vypravení (např. jde o odpověď na DZ a je známo ID DS příjemce), elektronická podatelna automatizovaně odešle (vypraví) písemnost bez zásahu obsluhy elektronické podatelny (daná uživatelské role).

4.2.8.17 Vypravení dokumentu

Navržené řešení musí zajistit vhodné a efektivní spojení identifikace odesílaného dokumentu podle předchozího odstavce s obálkou obsahující tento dokument připravenou k vypravení, aby obsluha podatelny byla schopná v eSSL pro daný dokument změnit po vypravení stav (např. K vypravení, Vypravený), nejméně číslem jednacím a číslem zásilky.

Pro tuto oblast funkcí zadavatel požaduje splnění následujících elementárních funkčností nad rámec normativních požadavků:

▪ funkce pro vrácení dokumentu k odeslání z výpravny zpět na spisový uzel (např. z důvodu opravy záznamu);

▪ funkce pro generování podacího archu, případně elektronického podacího archu (někdy také označován jako „ePA“) dle požadavků České pošty, s.p.;

▪ funkce pro generování poštovního podacího archu s položkami:

🢭 datum odeslání na poště;

🢭 podací znaky;

🢭 adresát;

🢭 dobírka;

🢭 cena;

🢭 č.j. z eSSL;

▪ zpracování doručenek, tj. zápis data doručení do metadat zásilky;

▪ napojení eSSL na frankovací stroj za účelem frankování obálek a balíků (ústřední podatelna):

🢭 možnost vyhledání zásilky a to prostřednictvím vyhledání zásilky načtením čárového kódu zásilky umístěného na obálce;

🢭 možnost vytvoření dávky zásilek ve výpravně;

🢭 z takto vytvořené dávky vygenerovat soupis zásilek ve formátu CSV, kde na jednom řádku budou umístěny údaje: číslo zásilky / jméno příjemce / ulice a číslo popisné či orientační / PSČ / místo;

🢭 další zpracování u zadavatele již probíhá v SW, který je propojen na frankovací stroj a funkčnost aplikace obsahuje veškeré funkce potřebné pro frankování a administrativu spojenou s vypravením dávky zásilek; včetně účetní evidence;

▪ vypravení zásilek bez napojení eSSL na frankovací stroj (podatelna Karviná)

🢭 možnost vyhledání zásilky a to prostřednictvím vyhledání zásilky načtením čárového kódu zásilky umístěného na obálce;

🢭 možnost vytvoření dávky zásilek ve výpravně;

🢭 měsíční vyúčtování nákladů na poštovné pro jednotlivé děkanáty, rektorát apod.

Výpravny zadavatele zpracovávají již úplně připravené zásilky (zalepené obálky, zabalené balíky se všemi údaji požadovanými pro vypravení). Vzhledem k tomu, že je v mnoha případech zapotřebí jeden analogový dokument zaslat více adresátům, zadavatel požaduje, aby se v eSSL vytvářely zásilky, které budou obsahovat vlastní řadu jednoznačných identifikátorů – čísel zásilek, tzn. řadu čárových kódů odesílaných poštovních zásilek (tiskem na obálky). Propojení čárového kódu čísla zásilky, adresy příjemce a příslušného dokumentu (č.j.) musí zajišíovat eSSL (vše je propojeno v metadatech dokumentu).

Systém musí umožňovat pomocí nastavitelných šablon MS Word vytisknout (i hromadně) na obálku adresu příjemce, jednoznačný identifikátor dokumentu nebo č.j. a čárový kód čísla zásilky.

V případě dokumentů odeslaných v listinné podobě prostřednictvím běžné doporučené pošty je požadováno, aby Systém sám kontroloval a vyznačoval fikci doručení, tzn. v případě, že u odeslaného dokumentu dojde k vypršení lhůty fikce doručení dříve, než je doručení potvrzeno explicitně, má systém minimálně navrhnout, lépe zcela automaticky uvést u daného podání, že bylo doručeno, a to fikcí.

4.2.8.18 Vyhledávání

Pro tuto oblast funkcí zadavatel požaduje splnění následujících elementárních funkčností:

▪ funkce pro vyhledání klíčové entity (spisy, dokumenty, jejich součásti, adresáty apod.) v systému podle atributů a jejich definovaných rozsahů, resp. omezujících kritérií, fulltextově nebo kombinací a atributy, to vše vždy respektujíc přístupová práva a schopnosti jednotlivých rolí;

▪ funkce pro vytváření souhrnné a statistické výstupní sestavy ze spisové služby pro vedení zadavatele, zejména počet vyřízených dokumentů, počet zpracovávaných dokumentů jednotlivými pracovníky v jednotlivých stavech, statistiku použití časových razítek apod.

4.2.8.19 Skartační řízení a výběr archiválií

Pro tuto oblast funkcí zadavatel požaduje splnění následujících požadavků:

▪ pro listinné dokumenty provozuje zadavatel vlastní akreditovaný archiv;

▪ vybrané archiválie z digitálních dokumentů budou předávány do Národního digitálního archivu (NDA);

▪ musí být dostupná funkce a nastavení pro export do NDA.

4.2.8.20 Administrace

Požadovaná funkcionalita je následující:

▪ administrace spisových uzlů, uživatelů, číselníků;

▪ kontrola a údržba jmenného rejstříku (dle § 25 vyhlášky ke spisové službě);

▪ protokoly transakcí, audit transakcí nad celou databází;

▪ nastavení řízené korespondence/nastavení oběhu písemností dle typu dokumentu.

4.2.9 FINANČNÍ AGENDA A E-SHOP

Pro všechny níže uvedené evidence či okruhy zadavatel vyžaduje, aby NIS v sobě obsahoval zejména následující funkce:

▪ evidenci dokumentů dle eSSL (faktury, smlouvy);

▪ vytváření požadavku na úhradu a elektronickou autorizaci požadavku;

▪ kontrolu úhrady (párování plateb a předpisů obsahujících všechny správné identifikační údaje, evidence neuhrazených plateb, kontrola nespárovaných plateb a vracení neoprávněných plateb);

▪ automatické vytvoření účetních dokladů a jejich předání ekonomickému oddělení.

Dalším neméně významným cílem je snížení administrativního zatížení na všech úrovních, zejména však automatizací v činnostech velkého rozsahu:

▪ evidence žádostí o stipendium a realizace jejich vyplácení (zejména ubytovací a sociální);

▪ evidence plateb u placené výuky (U3V, CŽV);

▪ evidence plateb vyměřených poplatků za studium.

Další požadavky na finanční agendu:

▪ funkcionalita platební brány;

▪ nákupy s možností platby kartou (kurzy CŽV, U3V, učebnice, služby, další materiály);

▪ přehled o aktivitách – objednávky, stipendia, poplatky;

▪ automatické účtování služeb s hromadným napojením na účetnictví.

4.2.10 VĚDECKÁ A TVŮRČÍ ČINNOST

Požadovaná funkcionalita je následující:

▪ evidence vlastních vědeckých a tvůrčích děl, publikačních záznamů, export a tisk seznamů;

▪ evidence životopisů autorů v dalších jazycích;

▪ evidence výukových děl;

▪ vykazování publikačních záznamů do RIV a provádění kontrol;

▪ zpřístupnění metadat a plných textů publikací v NIS;

▪ správa citačních záznamů;

▪ odkazování na publikační záznamy pomocí URL;

▪ přiřazování publikačních záznamů k interním projektům;

▪ vyhledávání podobnosti vůči závěrečným pracím a dalším studentským pracím jiných škol.

4.2.11 PODPORA VÝUKY – „E-LEARNING“

Požadovaná funkcionalita je následující:

• kompletní modul pro elektronické (on-line) vzdělávání typu e-learning;

• dostupnost podpory výuky pro studenty kombinovaných a distančních forem studia;

• podpora hromadných otevřených online kurzů (MOOC), tzn. vzdělávacích kurzů s neomezeným počtem účastníků, ke kterým se přistupuje pomocí webu (i mimo uživatele NIS).

Document Metadata

Table of Contents

S L E Z S K Á U N I V E R Z I T A V O P A V Ě

Document Metadata