Příloha č. 2: Funkční a technická specifikace předmětu zakázky
Příloha č. 2:
Funkční a technická specifikace předmětu zakázky
Pozn.) Tato funkční a technická specifikace bude po doplnění účastníkem ustanovena přílohou Smlouvy
1Obecné požadavky na úroveň kvality nabízeného řešení
ID |
Požadavek na funkcionality |
Splněno (Ano / Ne) |
1 |
Nabízené řešení musí být schváleno či jinak evaluováno z hlediska garance bezpečnosti (posouzení NÚKIB, Ministerstvo vnitra ČR) v katalogu eGovernment služeb na úrovni 3. |
|
2 |
Navržené řešení pro Asset management musí být certifikováno v oblasti procesu Správy aktiv (IT Asset Management) dle ITIL 4 nebo PinkVerify. V rámci nabídky musí být přiložen certifikát vydaný způsobilou certifikační autoritou, potvrzující tento rozsah certifikací. |
|
3 |
Nabízené řešení pro Service desk musí být certifikováno v oblasti podpory procesů IT service managementu dle ITIL 4 nebo PinkVerify minimálně v rozsahu následujících procesů:
V rámci nabídky musí být přiložen certifikát vydaný způsobilou certifikační autoritou, potvrzující tento rozsah certifikací. |
|
2Informační systém pro správu a technickou evidenci majetku (Asset Management)
Základní technické požadavky |
|
|
ID |
Požadavek na funkcionality |
Splněno (Ano / Ne) |
1 |
Provoz systému ve vnitřní infrastruktuře zadavatele. Veškeré požadavky na infrastrukturu budou uvedeny v nabídce. |
|
2 |
Integrace se stávající centrální správou uživatelů zadavatele v prostředí Microsoft Active Directory (Windows Server 2019 a vyšší) a ověřování uživatelů vůči doménovým identitám včetně řízení oprávnění přístupu k informacím pomocí uživatelských skupin. |
|
3 |
Možnost přístupu SSO s použitím identity uživatele přihlášeného v MS Windows. |
|
4 |
Možnost mapování libovolného atributu z Active Directory. |
|
5 |
Automatické načítání organizační struktury a příslušnosti zaměstnanců k organizačním jednotkám z Active Directory včetně automatického načítání vztahu zaměstnance a jeho nadřízeného a automatického načítaní informací o PC. |
|
6 |
Integrace s nástroji pro správu pracovních stanic (RemoteDesktop, Teamviewer apod.). |
|
7 |
Webové rozhraní minimálně pro rutinní činnosti (změna umístění objektu, změna vlastností objektu, zobrazení majetku přiděleného uživatelům v organizaci). Systém bude možné obsluhovat z prostředí standardního webového prohlížeče (Google Chrome, MS Edge). |
|
8 |
Webová část musí být realizována ve standardu HTML5 s responzivním designem. |
|
9 |
Celé řešení z důvodu bezpečnosti musí být v třívrstvé architektuře bez přímého přístupu klienta do databáze. |
|
10 |
Import a export dat z Microsoft Excel. |
|
Funkční specifikace |
|
|
ID |
Požadavek na funkcionality |
Splněno (Ano / Ne) |
11 |
Zadavatel požaduje dodání software s trvalou licencí pro evidence a automatickou detekci hardware a software pro 150 počítačů na platformě MS Windows. V rámci této licence musí být umožněno bezplatně evidovat další objekty (telefony, tiskárny, licence, kompetence, apod.) alespoň v počtu padesátinásobku počtu objektů vystavené licence. |
|
12 |
Podpora evidence libovolného majetku i mimo IT – možnost vytváření vlastních objektů a vlastností k těmto objektům bez nutnosti rozšiřování licence za účelem technické evidence jakéhokoliv majetku (auta, nábytek, budovy, licence apod.) |
|
13 |
Podpora evidence uživatelských přístupů a kompetencí. |
|
14 |
Požadujeme z důvodu zabezpečení informací možnost nastavit práva na zobrazení jednotlivých vlastností objektů. Například některým uživatelům se nebudou zobrazovat údaje o cenách nebo jiné citlivé údaje na objektu. |
|
15 |
Zadavatel požaduje možnost definovat konkrétní vlastnost na konkrétním druhu objektu jako povinnou. |
|
16 |
Zadavatel požaduje pro vedoucí zaměstnance možnost zobrazení evidovaných objektů svých podřízených pracovníků. |
|
17 |
Zadavatel požaduje bezpečný přístup k datům, kdy klient aplikace nevyžaduje přímý přístup do databáze. |
|
18 |
Zadavatel požaduje provoz klienta aplikace z prostředí webového prohlížeče. |
|
19 |
Software musí podporovat rychlou orientaci v umístění majetku. Z tohoto důvodu požaduje zadavatel, aby veškerá struktura umístění majetku byla organizována v přehledné graficky zobrazené stromové struktuře. Stromová struktura musí být volně modifikovatelná správcem systému. |
|
20 |
Zadavatel požaduje možnost multiselect výběru ve stromové struktuře. |
|
21 |
Zadavatel požaduje možnost přesunu majetku nebo i části stromu výše uvedené struktury přesunem myší (metoda drag & drop). |
|
22 |
Systém musí obsahovat webový portál pro zaměstnance, manažery a IT tým, kde každý zaměstnanec může sledovat svůj svěřený majetek bez nutnosti instalace klientů na koncové počítače uživatelů. |
|
23 |
Uživatelské rozhraní je lokalizováno do češtiny. |
|
24 |
Zadavatel požaduje, aby šablony tiskových sestav byly uloženy v databázi produktu, aby bylo zajištěno jednotné používání výstupů. |
|
25 |
Řešení disponuje pro detekci SW na stanicích vlastní knihovnou s rozsahem min. 50.000 softwarových vzorů. |
|
26 |
Řešení musí obsahovat znalostní databázi o software, automaticky udržovanou a publikovanou výrobcem a poskytovanou formou služby. Řešení musí obsahovat automatický mechanizmus pro odesílání hlaviček nerozpoznaného software bez nutnosti ručního zásahu a následný automatický upgrade aktualizované softwarové knihovny. Celý proces musí být plně automatický bez nutnosti jakéhokoliv zásahu nebo podpory na straně uživatele. |
|
27 |
Zadavatel požaduje plný přístup k databázi pouze pro správce aplikace pro volnou možnost tvorby reportů od předpřipravených výstupů, přes možnost exportu do Excelu až po možnost přímého SQL dotazu do databáze. |
|
28 |
Zadavatel požaduje možnost využít pro reporting Power BI a z tohoto důvodu jsou požadovány předpřipravené Query pohledy pro jednoduchou tvorbu reportů nad Power BI. |
|
29 |
Pro počítače umístěné mimo vlastní LAN požadujeme odesílání dat z počítačů prostřednictvím internetu (stačí, když je počítač připojen k internetu a nemusí být navázána VPN do LAN) pomocí zabezpečeného protokolu. |
|
30 |
Řešení obsahuje možnost tisku a elektronické evidence předávacích protokolů. |
|
31 |
Řešení podporuje využití čárových kódů při operativní práci spojené s pořizováním, zaváděním a inventarizací majetku. |
|
32 |
Možnost nastavení automatických e-mailových upozornění (končící licence, certifikát, plánovaná technická kontrola apod.). |
|
33 |
Požadujeme report umožňující analyzovat poruchovost majetku, např. zobrazit zařízení s největším počtem incidentů, či uživatelů majetku (ICT assetů) s nejčastějšími případy poškození či ztrátami majetku. |
|
Požadavky na integraci se Service Desk |
|
|
ID |
Požadavek na funkcionality |
Splněno (Ano / Ne) |
34 |
Z důvodu zvýšení přehlednosti a jednoznačnosti požadujeme, aby požadavek ze Service Desk bylo možno navázat přímo ze Service Desk na objekt (konfigurační položku) v Asset Management. |
|
35 |
Pro rychlou orientaci v systému požadujeme, aby z požadavku v Service Desk, který založil uživatel byl přímý proklik na majetek v Asset Management, který má tento uživatel přidělený. |
|
36 |
Pro zvýšení rychlosti a jednoznačnosti při zadávání požadavků požadujeme, aby bylo možno založit požadavek týkající se konkrétního objektu přímo z Asset Management a zároveň aby byla přednastavena výchozí služba a SLA požadavku. |
|
37 |
Požadujeme, aby u každého objektu v Asset Managementu byl přímo zobrazován seznam požadavků, které souvisí s tímto objektem (konfigurační položkou). Možnost zobrazit z AM požadavky související s konkrétním objektem. |
|
38 |
Požadujeme funkcionalitu, která zajistí zobrazení zařízení související s požadavkem z Asset Management přímo v Service Desk. |
|
39 |
Požadujeme možnost definovat opakované činnosti (revize / profylaxe) týkající se konkrétních zařízení včetně zasílání e-mailových notifikací. |
|
40 |
Požadujeme, aby uživatelé mohli založit požadavek přímo z konkrétního jim svěřeného majetku, a to pouze do relevantních služeb a aby tento požadavek byl na daný majetek navázán. |
|
41 |
Požadujeme, aby konkrétní formuláře pro nový požadavek z katalogu služeb nabízely pouze objekty relevantních typů (např. u incidentu „Nahlásit nefunkční mobilní telefon“ se zobrazují jen mobilní telefony a nikoliv ostatní typy zařízení). |
|
42 |
Při procesu odchodu zaměstnance musí Service Desk na základě evidovaných objektů v Asset Management automaticky vygenerovat požadavky na vrácení techniky, odebrání přístupů a kompetencí. |
|
Požadavky na funkcionality dostupné správcům systému |
|
|
ID |
Požadavek na funkcionality |
Splněno (Ano / Ne) |
43 |
Přidávání a odebírání uživatelů a jejich zařazování do skupin. |
|
44 |
Přidávání a odebírání skupin, přidávání uživatelských rolí. |
|
45 |
Nastavení přístupových práv k jednotlivým objektům a částem používané struktury umístění majetku. |
|
46 |
Nastavení posílání notifikací a úprava jejich obsahu. |
|
3Informační systém pro správu požadavků (Service Desk)
Základní technické požadavky |
|
|
ID |
Požadavek na funkcionality |
Splněno (Ano / Ne) |
1 |
Provoz systému ve vnitřní infrastruktuře zadavatele. Veškeré požadavky na infrastrukturu budou uvedeny v nabídce. |
|
2 |
Integrace se stávající centrální správou uživatelů zadavatele v prostředí Microsoft Active Directory (Windows Server 2019 a vyšší) a ověřování uživatelů vůči doménovým identitám. |
|
3 |
Možnost přístupu SSO s použitím identity uživatele přihlášeného v MS Windows. |
|
4 |
Možnost mapování libovolného atributu z Active Directory. |
|
5 |
Automatické načítání vztahu zaměstnance a jeho nadřízeného z Active Directory. |
|
6 |
Webové rozhraní (portál) pro zadávání i řešení požadavků a správu systému – systém bude možné obsluhovat z prostředí standardního webového prohlížeče (Google Chrome, MS Edge). |
|
7 |
Portál musí být realizován ve standardu HTML5 s responzivním designem. |
|
8 |
Integrace s poštovním on-premise serverem MS Exchange automatické vytěžování komunikační e-mailové schránky pro zakládání nových požadavků či nových záznamů k stávajícím požadavkům. |
|
9 |
Export dat do Microsoft Excel. |
|
Funkční specifikace |
|
|
ID |
Požadavek na funkcionality |
Splněno (Ano / Ne) |
10 |
Jednotný systém pro komplexní správu požadavků organizace (jednotné kontaktní místo). |
|
11 |
Možnost vlastní správy katalogu služeb (přidávat nové a konfigurovat stávající služby) na úrovni správce systému. |
|
12 |
Systém musí nabízet možnost zadávání požadavků minimálně na webovém portálu, e-mailem a telefonicky (řešitel nebo operátor může zadat do systému požadavek za žadatele). |
|
13 |
Žadatel musí být systémem automaticky informován o průběhu řešení jeho požadavku. |
|
14 |
Systém musí umožnit vytvářet vazby mezi požadavky v systému. Minimální funkcionalita vazeb jsou podřízené a nadřízené požadavky a sledování plnění podřízených požadavků v rámci nadřízeného požadavku. |
|
15 |
Systém musí být schopen automaticky rozpadat jeden požadavek na několik podřízených s automatickým vytvořením vzájemných vazeb na základě interaktivního vstupního formuláře u dané služby. |
|
16 |
Systém musí být schopen automaticky zakládat periodické požadavky (pravidelné revize, periodické opravy, periodické technické prohlídky apod.). |
|
17 |
Systém musí umožnit řešiteli jednoduše předat požadavek ke schválení schvalovateli. |
|
18 |
Systém musí umožnit řešiteli přesunout nesprávně zadaný požadavek do jiné sekce (k jiné službě). |
|
19 |
Systém musí podporovat automatické řízení procesu nástupu a výstupu zaměstnance minimálně v rozsahu automatického rozpadu požadavku na nástup/výstup zaměstnance na několik podřízených požadavků, které budou vyřizovat různí řešitelé jako je např. zajištění počítače, telefonu, vybavení pracoviště, zajištění vizitek, zajištění zdravotní prohlídky, zajištění různých vstupních školení apod. Systém musí být schopen sledovat plnění podřízených požadavků v rámci nadřízeného požadavku. |
|
20 |
Volbou služby musí být automaticky bez dalšího zadávání přidělena skupina řešitelů a parametry SLA (Service Level Agreement). |
|
21 |
Pro každou službu musí být možno plně definovat vstupní zadávací formulář včetně vlastních uživatelských položek. |
|
22 |
K požadavku musí být možno ve všech fázích jeho zpracování připojit přílohy. |
|
23 |
Pro každou službu musí být možno na úrovni správce systému plně definovat workflow. |
|
24 |
Komplexní schvalovací workflow definovatelné na úrovni správce systému. Možnost vynutit schválení podle určitého pravidla v libovolný okamžik řešení. Napojení na Active Directory. |
|
25 |
Možnost definovat šablony libovolných úkolů a plánovat jejich pravidelné automatické zakládání. |
|
26 |
Požadujeme možnost nastavování eskalačních procesů na úrovni správce systému. |
|
27 |
Požadujeme možnost automatické archivace zadaných požadavků ve vybraných službách po nastavitelné době, přičemž archivované požadavky musí být možné zpětně dohledat. |
|
28 |
Požadujeme možnost vytváření přehledů a statistik odbavených požadavků podle časového období, jednotlivých služeb, řešitelů, řešitelských týmů, zadavatelů a jejich pracovišť. |
|
Požadavky na uživatelské rozhraní |
|
|
ID |
Požadavek na funkcionality |
Splněno (Ano / Ne) |
29 |
Z pohledu žadatele musí systém podporovat katalog služeb. Katalog musí vycházet ze stromové struktury členěné dle jednotlivých oblastí – samostatný strom pro požadavky směřující na každou oblast (IT, správa budov apod.). |
|
30 |
Celý katalog služeb musí být uživatelům přístupný na webovém portálu a pro každou službu musí být připravena na portálu samostatná ikona nebo dlaždice s názorným a přehledným piktogramem pro maximální zpřehlednění katalogu. Před vlastním spuštěním akce (kliknutí na ikonu nebo dlaždici dané služby) se musí automaticky zobrazit nápověda podrobně popisující tuto službu. |
|
31 |
Systém musí být vybaven znalostní databází, kterou je možno provázat s katalogem služeb s možností uživatelského vytváření a publikování článků. Články musí být možno členit a napojit na odpovídající služby v katalogu. Přístup k článkům a jejich zobrazování musí být řízeno dle uživatelských rolí jednotlivých uživatelů. |
|
32 |
Systém musí být vybaven výchozí šablonou služby s definicí polí vstupního formuláře. |
|
33 |
Systém musí umožnit sestavení vlastní šablony zprávy pro schvalovatele. |
|
34 |
Musí být umožněno přizpůsobit grafický vzhled systému podnikovému vizuálu zadavatele min. v rozsahu přidání loga a přizpůsobení barevného schématu. |
|
35 |
Uživateli se musí zobrazit pouze ty služby, ve kterých má přidělenou nějakou roli. |
|
36 |
Požadavky vygenerované či doplněné z e-mailové komunikace musí umožnit zobrazení v podobě plně odpovídající originálu e-mailu včetně obrázků a příloh z důvodu jednoznačné a nezkreslené komunikace mezi uživateli systému. |
|
37 |
Systém musí obsahovat na portálu funkcionalitu pro vytváření a zveřejňování zpráv a aktualit např. plánované odstávky. |
|
38 |
Každý uživatel si může definovat vlastní pohledy a filtry nad požadavky. |
|
39 |
Systém musí umožnit fulltextové vyhledávání nad všemi informacemi. |
|
Požadavky na funkcionality dostupné správcům systému |
|
|
ID |
Požadavek na funkcionality |
Splněno (Ano / Ne) |
40 |
Přidávání a odebírání uživatelů a jejich zařazování do skupin. |
|
41 |
Přidávání a odebírání skupin, přidávání uživatelských rolí. |
|
42 |
Nastavení přístupových práv k jednotlivým objektům. |
|
43 |
Nastavení posílání notifikací a úprava jejich obsahu. |
|
44 |
Přidávání vlastních položek do formulářů. |
|
45 |
Definovat vlastní workflow nad požadavky. |
|
46 |
Definice vlastního katalogu služeb. |
|
47 |
Definice úrovně kvality služeb (SLA). |
|
48 |
Nastavení oprávnění přístupů k jednotlivým službám. |
|
49 |
Vytváření vlastních schvalovacích procesů, srozumitelný popis předmětu schvalování. |
|
Strana 8 / 8