SMLOUVA O DÍLO
Číslo smlouvy objednatele:
Číslo smlouvy zhotovitele: 2018/2/023
SMLOUVA O DÍLO
kterou uzavřely podle občanského zákoníku (zák. č. 89/2012 Sb. ve znění pozdějších předpisů) dále uvedeného dne, měsíce a roku, níže uvedené smluvní strany:
Liberecká IS, a.s.
se sídlem: Mrštíkova 3, 461 71 Liberec III
zastoupená: Ing. Xxxxxxxxxx Xxxxxxx, MBA, statutárním ředitelem
IČO: 254 50 131
DIČ: CZ25450131
Bankovní spojení: ČSOB, a.s., č. ú. 267710810/0300
zapsaná v OR vedeným Krajským soudem v Ústí nad Labem, oddíl B, vložka 1429 jako objednatel na straně jedné
a
DATRON a.s.
se sídlem: Vachkova 3008, 470 01 Česká Lípa
zastoupené: Ing. Xxxxxxx Xxxxxxxx, místopředsedou představenstva
Xxx. Xxxxxxxxx, Látalem místopředsedou představenstva
IČO: 43227520
DIČ: CZ43227520
Bankovní spojení: MONETA Money Bank, číslo účtu: 215718976/0600
zapsaný v obchodním rejstříku vedeném rejstříkovým soudem v Ústí nad Labem, oddíl B, vložka 1680
jako Zhotovitel na straně druhé
1. PŘEDMĚT SMLOUVY
1.1 Zhotovitel pro Objednatele vytvoří a předá následující dílo spojené s dodávkou a implementací rozšíření stávajícího SW CHD o nové funkcionality a moduly v tomto rozsahu:
I. Analýza nových požadavků
- návrh souběhu stávající a nové funkcionality
- Návrh nových workflow
II. Programování a konfigurace
1 kategorizace požadavků
- nový katalog služeb
2 SLA požadavek
- nové wkf pro SLA požadavky
- úprava obrazovek pro SLA požadavky
3 Změnový požadavek
- nové wkf pro změnové požadavky obecně
- úprava obrazovek pro změnové požadavky
- Nákup hardware a software
3.1 Nákup hardware/software
- úprava wkf změnový požadavek
- úprava obrazovek a práv pro požadovanou funkčnost
3.2 Nástup/přestup/výstup uživatele
- nové tabulky v DB DAS
- el. formulář návrh a realizace
- nové číselníky a obrazovky
- úprava wkf a obrazovek
3.3 Žádost o přidělení práv v SW
- úprava wkf a obrazovek
3.4 Vývojový požadavek
- úprava wkf a obrazovek
4 Systém hodnocení
- nové tabulky v DB DAS
- el. formulář návrh a realizace
- nová obrazovka pro vyjádření řešitele
- zařazení hodnocení do přehledu - fronty
5 Nová podpora reportu z Helpdesk (týdenního)
- nová obrazovka reportu
6 Všeobecné požadavky na chování systému
- úprava obrazovek a stávajících wkf
III. Implementace řešení v prostředí LIS
1 Kategorizace požadavků
2 SLA požadavek
3 Změnový požadavek
4 Nákup hardware/software
5 Nástup/přestup/výstup uživatele
6 Žádost o přidělení práv v SW
7 Vývojový požadavek
8 Systém hodnocení
9 Nová podpora reportu z Helpdesk (týdenního)
10 Všeobecné požadavky na chování systému
Detailně jsou položky předmětu smlouvy zpracovány v příloze čísloslo 2, této smlouvy.
1.2 Objednatel se zavazuje k přímé součinnosti v plnění předmětu smlouvy a to v bodech:
✓ Zpracování nového katalogu služeb - KAP. 1
✓ Systém hodnocení - KAP. 4 el. Formuláře návrh
✓ Implementace řešení v prostředí LIS - KAP. 1, 2, 3, 3.1, 3.3, 3.4, 4 a5
▪ Kategorizace požadavků
▪ SLA požadavek
▪ Změnový požadavek
▪ Nákup hardware/software
▪ Žádost o přidělení práv v SW
▪ Vývojový požadavek
▪ Systém hodnocení
▪ Nová podpora reportu z Helpdesk (týdenního)
1.3 Zhotovitel garantuje úplnost a formální správnost předaného díla a jeho soulad s platnou legislativou.
2. CENA DÍLA, TERMÍNY, PLATEBNÍ PODMÍNKY
2.1 Objednatel se zavazuje dílo převzít a zaplatit za ně dohodnutou odměnu.
2.2 Za dílo specifikované v článku 1.1 této Smlouvy se Objednatel zavazuje Zhotoviteli zaplatit jednorázovou odměnu ve výši bez DPH (slovy dvěstěčtyřicettisíckorunčeských).
2.3 Termín pro splnění předmětu díla je stanoven nejpozději do 31. 10. 2018 se zvýšeným dohledem do 31. 12. 2018.
2.4 Faktura za dílo bude vystavena po předání a akceptaci kompletního díla Objednatelem. Dnem zdanitelného plnění je den podpisu akceptačního protokolu.
2.5 Cena díla zahrnuje veškeré náklady Xxxxxxxxxxx nezbytné k řádnému, úplnému a kvalitnímu provedení díla dle čl. 1.1 smlouvy.
2.6 K cenám uvedeným v čl. 2.2 smlouvy bude připočtena sazba DPH odpovídající platné legislativě České republiky.
2.7 Splatnost faktury je 30 dnů ode dne jejich doručení Objednateli.
2.8 Nedodrží-li Objednatel termín splatnosti, je Zhotovitel oprávněn požadovat smluvní úrok z prodlení ve výši 0,01% za každý kalendářní den.
2.9 Nedodrží-li Zhotovitel termín splnění předmětu díla, je Objednatel oprávněn požadovat smluvní úrok z prodlení ve výši 0,01% za každý kalendářní den.
2.10 V ceně díla jsou veškeré náklady zhotovitele související s dílem, dle této smlouvy.
3. LICENČNÍ UJEDNÁNÍ
3.1 Zhotovitel na základě této smlouvy uděluje objednateli oprávnění k výkonu práva užívat jednotlivé moduly dle čl. 1, dost 1.1 na dobu neurčitou za cenu a podmínek dále v této smlouvě stanovených. Udělené právo ze strany zhotovitele vůči objednateli je nevýhradní.
3.2 Právo na užití a šíření předmětu této smlouvy se bude nadále řídit v souladu s ustanovením zák. č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským (autorský zákon).
3.3 Objednatel je oprávněn na základě této smlouvy užívat licenci předmětu smlouvy dle podmínek uvedených ve smlouvě číslo LIS/2012/2/020, DATRON/LIS07/72012. Pokud objednatel tyto podmínky poruší, vzniká zhotoviteli nárok na odpovídající náhradu škody.
4. Odpovědnost za škodu
4.1 Zhotovitel a objednatel odpovídají za škodu, vzniklou druhé straně porušením povinností stanovených smlouvou či obecně závaznými právními předpisy.
4.2 Zhotovitel neodpovídá za škody, které byly způsobeny nesprávným užitím nebo nedbalostí objednatele ani za škody vzniklé hardware, operačním systémem nebo jiným softwarovým produktem, který není předmětem této smlouvy.
4.3 Odpovědnost za škodu se řídí ustanoveními zákona č. 89/2012 Sb., v platném znění.
4.4 Zhotovitel se zavazuje dodržovat po celou dobu plnění zakázky platné právní předpisy a provádět veškerá plnění veřejné zakázky v souladu s platným právním řádem.
5. ZÁRUKA
5.1 Zhotovitel prohlašuje, že předané dílo bude celou dobu užívání způsobilé pro použití ke smluvenému, jinak obvyklému účelu nebo že si zachová smluvené, jinak obvyklé vlastnosti.
5.2 Sjednaná záruční lhůta na dodávku a implementaci díla činí 24 měsíců od data podpisu akceptačního protokolu. Místem pro uplatnění reklamace je adresa zhotovitele.
5.3 Objednatel je oprávněn reklamovat závady plnění po dobu trvání záruční lhůty. V době sjednané záruční lhůty budou oprávněně reklamované závady odstraněny na náklady zhotovitele.
5.4 Veškerá požadovaná písemná komunikace zástupců smluvních stran bude realizována prostřednictvím HelpDesk vyjma případů, kdy HelpDesk je prokazatelně nefunkční. V takovém případě bude komunikace realizována jinou písemnou formou nebo náhradním telefonickým spojením a do HelpDesk bude vše zapsáno po jeho zprovoznění.
5.5 Zhotovitel se zavazuje k odezvě na objednatelem reklamovanou závadu plnění neprodleně, nejdéle však do 2 hodin od jejího nahlášení.
5.6 Smluvní strany výslovně sjednávají, že zhotovitel je povinen dodržet výše uvedené termíny pro zahájení prací na odstranění závad pouze za předpokladu funkčního dálkového přístupu
zhotovitele do IS města pro dálkovou diagnostiku problémů a jejich odstraňování za současného zajištění bezpečnosti dat a informací objednatele.
5.7 Zhotovitel neručí za kvalitu a správnost dat a číselníků předaných objednatelem k případné migraci.
5.8 Zhotovitel neručí za případné vady, které na díle vzniknou v důsledku nepřesně nebo nesprávně formulovaných požadavků na funkcionalitu ze strany objednatele nebo třetí strany.
6. ZÁVĚREČNÁ UJEDNÁNÍ A DOLOŽKY
6.1 Tato Smlouva a vztahy z ní vyplývající se řídí právem České republiky.
6.2 Smluvní strany jsou povinny vzájemně spolupracovat při plnění předmětu této smlouvy a jsou povinny poskytnout si vzájemně dostupnou součinnost nezbytnou k tomu, aby mohl být naplněn předmět této smlouvy – tj. vytvoření plně funkčního díla pro Objednatele dle podmínek této smlouvy, bez vad a nedodělků. Tyto případy budou řešeny dodatkem smlouvy.
6.3 Smluvní strany jsou povinny neprodleně si vzájemně sdělovat informace, které mohou mít vliv na plnění závazků vyplývajících z této smlouvy.
6.4 Smluvní strany jsou oprávněny zveřejnit veškerý obsah této smlouvy, budou-li o to požádány dle zákona č. 106 / 99 Sb.
6.5 Měnit či doplňovat tuto Smlouvu je možné pouze formou písemných dodatků.
6.6 Tato Smlouva je vyhotovena ve dvou (2) stejnopisech s platností originálu, přičemž každá ze Smluvních stran obdrží po jednom (1) vyhotovení.
6.7 Smluvní strany prohlašují, že si tuto Smlouvu přečetly, s jejím zněním souhlasí a na důkaz pravé a svobodné vůle připojují níže své podpisy.
6.8 Smluvní strany berou na vědomí, že tato smlouva bude zveřejněna v registru smluv podle zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv (zákon o registru smluv).
6.9 Smluvní strany berou na vědomí, že jsou povinny označit údaje ve smlouvě, které jsou chráněny zvláštními zákony (obchodní, bankovní tajemství, osobní údaje, …) a nemohou být poskytnuty, a to šedou barvou zvýraznění textu. Smluvní strana, která smlouvu zveřejní, za zveřejnění neoznačených údajů podle předešlé věty nenese žádnou odpovědnost.
6.10 Smlouva nabývá účinnosti nejdříve dnem uveřejnění v registru smluv v souladu s § 6 odst. 1 zákona č. 340/2015 Sb., o zvláštních podmínkách účinnosti některých smluv, uveřejňování těchto smluv a o registru smluv (zákon o registru smluv).
6.11 Smluvní strany berou na vědomí, že plnění podle této smlouvy poskytnutá před její účinností jsou plnění bez právního důvodu a strana, která by plnila před účinností této smlouvy, nese veškerou odpovědnost za případné škody takového plnění bez právního důvodu, a to i v případě, že druhá strana takové plnění přijme a potvrdí jeho přijetí.
6.12 Smluvní strany shodně prohlašují, že cena určená ve smlouvě je cenou obvyklou ve smyslu
§ 2999 zákona č. 89/2012 Sb., občanský zákoník.
Přílohy smlouvy: Příloha číslo 1 - Akceptační protokol s definovanými akceptačními kritérii Příloha číslo 2 -Detailně definované položky předmětu smlouvy
V Liberci dne: 26. 6. 2018 V České Xxxx dne:
……………………………………………………. …………………………………………………….
Za Libereckou IS, a.s. Za Datron a.s.
Xxx. Xxxxxxxx Xxxxx, MBA Xxx. Xxxxxx Xxxxxxx, Ing. Xxxxxxx, Xxxxx
PŘÍLOHA ČÍSLO 1 SMLOUVY
AKCEPTAČNÍ PROTOKOL
ke smlouvě či objednávce číslo: PŘESNÝ NÁZEV SMLOUVY ze dne . .
Adresa odběratele (akceptanta): | Předmět akceptace: | ||
Liberecká IS, a.s. Mrštíkova 3, Liberec III – Jeřáb, 461 71 | Dodávka a implementací rozšíření stávajícího SW CHD o nové funkcionality a moduly | ||
IČO: 25450131 | |||
Kontaktní osoby: | Tel.: 000000000 | ||
Xxxx Xxxxxxxxxx | |||
Manažerka úseku IT | |||
Přesný popis výstupů, které jsou předmětem akceptace: | |||
Viz. příloha AP. | |||
Výzva k převzetí předmětu akceptace byla učiněna dne: | |||
Výzva k převzetí předmětu akceptace byla zaslána (komu a jakou cestou): | |||
Datum předání díla: DD.MM.YYYY | |||
Xxxxxxxx: Za DODAVATELE | Jméno: JMÉNO AKCEPTUJÍCÍHO | Podpis: | |
Akceptační protokol převzal: Za ODBĚRATELE Liberecká IS, a.s. | Jméno: Xxxxx Xxxxxxxx Xxxx Xxxxxxxxxx | Podpis: |
Oprávněný zástupce Objednavatele potvrzuje, že Předmět akceptace splňuje podmínky převzetí:
splňuje v plném rozsahu bez vad
nesplňuje splňuje s těmito výhradami:
Seznam činností | Akceptační kriterium |
Vypracování a návrh nových workflow, návrh souběhu stávající a nové funkcionality | Shoda na vydefinovaných workflow a pracovních činnostech |
Konfigurace a Programování | |
Kategorizace požadavků | Vypracovaný nový katalog služeb a otestování funkčnosti |
SLA požadavek | Vznik nového workflow, úprava obrazovek pro SLA workflow a otestování funkčnosti |
Změnový požadavek | Vznik nového workflow Změnový požadavek a otestování funkčnosti |
Nákup hardware/software | Vznik nového workflow Nákup HW/SW a otestování funkčnosti |
Nástup/přestup/výstup uživatele | Vznik nového workflow Nástup/přestup/výstup uživatele s vypracovaným formulářem, číselníky s úpravou obrazovky a otestováním funkčnosti |
Žádost o přidělení práv v SW | Vznik nového workflow Žádost o přidělení práv v SW včetně otestování funkčnosti |
Vývojový požadavek | Vznik nového workflow Vývojový požadavek a otestování funkčnosti |
Systém hodnocení | Vznik workflow systému hodnocení s formulářem a jeho navázanost na Helpdesk včetně otestování funkčnosti |
Nová podpora reportu z Helpdesk (týdenního) | Vypracování nové podoby reportu a otestování funkčnosti |
Všeobecné požadavky na chování systému | Splnění všech bodů týkající se změn ve funkčnosti systému a jejich otestování |
Nasazení do testovacího režimu | Otestování aplikace v testovacím prostředí |
Nasazení do provozního režimu | Plně funkční aplikace |
V Liberci dne: 26. 6. 2018 V České Xxxx dne:
……………………………………………………. …………………………………………………….
Za Libereckou IS, a.s. Za Datron a.s.
Xxx. Xxxxxxxx Xxxxx, MBA Xxx. Xxxxxx Xxxxxxx, Ing. Xxxxxxx, Xxxxx
PŘÍLOHA ČÍSLO 2
Helpdesk - popis změn
Nový požadavek
Požadavek se nachází v tomto stavu, je-li nově založený. Při založení dojde na emailovou adresu notifikační e- mail obsahující veškeré informace o zadaném požadavku.
Základní rozdělení:
1. Zakázky typu "oprava"= Požadavek pod SLA - zde je podstatné, že u požadavku nejsou požadovány jakékoli změny či úpravy funkcionalit. Jedná se čistě o nápravu stavu, který z nějakého důvodu není v současnosti funkční. V těchto případech je aktivováno počítání SLA
2. Xxxxxxx typu "změnový" - je požadována změna funkcionality. Týká se úpravy postupu, jiný nebo nový výpočet, grafická podoba, nový modul, jakékoli legislativní úpravy schvalovací, zajištění hardware/ software, nástup/výstup zaměstnance…..
V těchto případech není aktivováno počítání SLA, nicméně požadavek je evidován včetně předpokládaného termínu dokončení. Tyto druhy požadavků nebudou ve výpisu všech požadavků a budou mít samostatnou kategorii v Helpdesku. U rozvojových požadavků bude možné nastavit
„priority“ od 1 do 3 kdy tyto priority budou od nejnižší (1) po (3) nejvyšší z hlediska důležitosti
– nová funkcionalita, nové procesy - komentář a dotazy viz níže.
Kategorizace požadavků -
Požadavky se budou zařazovat do těchto kategorií:
Hardware SLA
Správa koncových zařízení
Projekce Změnový požadavek
Zajištění projekcí Zastupitelstvo a Rada města
Systémová podpora SLA
Systémová vrstva (Správa sítě, prvků a serverů)
Přepážkové pracoviště / Prioritní požadavky SLA
Prioritní požadavek
Nástup / výstup / přestup Změnový požadavek
Nástup nového zaměstnance Přestup stávajícího zaměstnance Výstup zaměstnance
Nákup Hardware / Software Změnový požadavek
Nákup Hardware Nákup Software
Žádost o přidělení práv v SW Změnový požadavek
Software SLA
Agendy odboru sociální péče ASPE
ATTIS AUDIT PRO
City Dashboard CROSEUS
D-learning Docházkový systém DORIAN (Opuscard)
EHS - evidemce hrobové správy EVPE (vodoprávní evidence)
E-Zak Ginis
Geografický informační systém Heletax - půdní mapy
IBM zálohovací zařízení (Tivoli storage Manager) iDES (správa bytového fondu)
i-Point
IS MP - MP manager
IS RŽP vs. eSpis (registr živnostenského podnikání) KerioMail Server (administrace)
Kompetenční centrum Konsiliář
KROS
Marbes PROXIO Matrika
Microsoft SQL Server (databázový server) MTB - Kadel Suite - serie M/…
Mzdová a personální agenda - FluxPam
Nastavení práv na T: + sdílení disky SML(nastavení specifických práv) OKSystém
Oracle (databázový server) Ovzduší Kvasar
Parkovací systém Právní systém - Codexis QI
Redakční systém
RŽP (registr živnostenského podnikání) JRF ( jednotný registr firem) Signer
Spisová služba e-lite Spisová služba - Geovap Spisová služba ICZ
Telestěna - Městská policie Tiskové služby - Kasro
VDI - správa,administrace VEMA
VITA VoIP
Volby
Vyvolávací systém Yamaco
Vývojový požadavek Změnový požadavek
Požadavek na vývoj
Způ sob zadávánı́ požadavku uživatelem:
Pro zadání nového požadavku slouží tlačítko „vložení požadavku:
Název (povinné)
Popis požadavku (povinné)
Připojení příloh např. obrázky nebo dokumenty, které mohou napomoci jeho vyřešení (nepovinné)
Vznikne nový Katalog služeb s tím, že po dokončení bude den D kdy se budou požadavky zadávat nově a případně otevřené požadavky se převedou na Helpdesku nového.Nová funkcionalita aplikace bude zprovozněna vedle stávajícího helpdesku v jednom prostředí s tím, že od určitého dne budou požadavky zařazovat operátoři do nového Katalogu služeb a s tím budou viditelné nové obrazovky respektující požadovanou novou funkcionalitu. Stávající helpdesk bude v udržovacím stavu do doby kdy bude vše dočištěné
SLA požadavek
Stavy požadavků:
Nutně předcházejí stavy Čeká na zařazení a Čeká na přijetí řešitelem
V řešení = běží SLA
Dotaz na zadavatele = zastavuje se SLA
Hibernace = zastavuje se se SLA vždy po dohodě se zadavatelem se zapsáním poznámky (zde bude možné
Návrh na uzavření = zastavuje se SLA Uzavřen
V ŘEŠENÍ
V tomto stavu se Xxx požadavek řeší přiděleným řešitelem. Při přechodu do tohoto stavu bude zaslán notifikační e-mail. Tímto začíná běžet SLA termín pro vyřešení požadavku. Možné interakce zadavatele:
- Uzavření / Zrušení požadavku
Možné interakce řešitele:
- Návrh na uzavření požadavku (ukončí se počítání SLA termínu)
- Převedení požadavku do stavu Dotaz (zastavuje se počítání SLA termínu)
- Převedení požadavku do stavu Hibernace – po dohodě se zadavatelem (informace bude notifikační email) – zde musí být vydefinován termín probuzení požadavku, který po uplynutí této doby se vrátí do stavu v řešení zpět k řešiteli
- V detailu požadavku bude možnost kdykoliv označit „ problém“ ANO/NE = to je druh požadavku u kterého se očekává problém a bude ho nutné eskalovat (možnost popisu)
Dotaz - nový stav
Do tohoto stavu se požadavek dostane v případě, že řešitel potřebuje upřesnit popis problému nebo potřebuje vyjádření k navrhovanému řešení a v tomto okamžiku se zastavuje SLA termín pro vyřešení. Na e-mail bude odeslána zpráva o změně stavu.
Možné interakce uživatele:
- Reaguje na dotaz a požadavek změní do stavu řešení a po 30 minutách začne běžet SLA termín
- Uzavřít požadavek
- Odmítnutí návrhu na uzavření požadavku – požadavek se vrátí zpět k řešiteli a opětovně se zapíná SLA termín)
Možné interakce řešitele:
- Návrh na uzavření požadavku (ukončí se počítání SLA termínu)
- Převedení požadavku opět do stavu Dotaz (zastavuje se počítání SLA termínu)
- Převedení požadavku do stavu Hibernace – po dohodě se zadavatelem (informace bude notifikační email) – zde musí být vydefinován termín probuzení požadavku, který po uplynutí této doby se vrátí do stavu v řešení zpět k řešiteli
- Označení požadavku interní volbou ( červené zaškrtávátko s popisem od řešitele ) = bude sloužit k projednání na operativní poradě
Systém:
- Automatické uzavření po 14 dnech po nereagování zadavatele
Hibernace – stop SLA
Po dohodě a odsouhlasení s uživatelem bude tento požadavek převeden do stavu hibernace. Při nastavení tohoto stavu se odešle notifikační email.
Možné interakce uživatele:
- Převést ho do stavu řešení a SLA termín je opětovně aktivován
Možné interakce řešitele:
- Nutnost zadat termín probuzení požadavku (max. 90 dní) – v termínu probuzení bude požadavek automaticky převeden do stavu V řešení - platí pro všechny požadavky automaticky pokud není probuzen řešitelem nebo operátorem
- Převést ho do stavu řešení a SLA termín je opětovně aktivován
- Vybrat si v detailu požadavků jméno subdodavatele
- V detailu požadavku bude možnost kdykoliv označit „ problém“ ANO/NE = to je druh požadavku u kterého se očekává problém a bude ho nutné eskalovat
Systém:
- Systém Helpdesk bude notifikovat o požadavku zadavatele i řešitele každých 14 dní
Uzavřen
V tomto stavu je požadavek uzavřen a brán jako vyřešený. Po uzavření požadavku uživateli přijde notifikace s možností vyhodnocení požadavku.
Změnový požadavek
Změnový požadavek je ten, u kterého je požadována změna funkcionality. Týká se úpravy postupu, jiný nebo nový výpočet, grafická podoba, nový modul, jakékoli legislativní úpravy schvalovací, zajištění HW, nástup/výstup zaměstnance…..
V těchto případech není aktivováno počítání SLA, nicméně požadavek je evidován včetně předpokládaného termínu dokončení.
Řešitel zadá předpokládaný termín vyřešení, v případě potřeby se dotazuje zadavatele. Po vyřešení dá podnět k uzavření a zadavatel má možnost požadavek ihned uzavřít. Pokud ho neuzavře do 14 dnů je následně ze stavu Podnět k uzavření požadavek uzavřen automaticky.
- Ve stavu Termín vyřešení se požadavek každý měsíc připomene jak řešiteli, tak zadavateli emailem
- Ve stavu Termín vyřešení je možné změnit/posunout datum vždy a pouze po dohodě se zadavatelem - dohoda o změně termínu bude zapsaná v poznámce a viditelná v kartě Historie požadavku.
- Změnu tohoto stavu může provést jak zadavatel, tak i řešitel - řešitel může dát Podnět na uzavření nebo ho zadavatel může rovnou uzavřít - podnět bude dán stavem Vyřešen. V tomto stavu bude mít Zadavatel možnost požadavek Vrátit k dořešení nebo jej Uzavřít. A požadavek, který je ve stavu vyřešen a nebude k němu žádná reakce bude automaticky uzavřen po 14 dnech ( toto budeme definovat pracovními dny )
Stavy požadavků:
V řešení = kontroluje se termín vyřešení Dotaz na zadavatele
Termín vyřešení = předpokládaný termín vyřešení Návrh na uzavření
Uzavřen
Nákup hardware/software
Pro tyto požadavky bude vydefinována skupina „obchodník“, která uvidí všechny tyto požadavky z důvodu přehledu nad jednotlivými úkoly
Proces :
Zadavatel - operátor - schvalovatel - nákupčí (řešitel 1) - řešitel 2
- řešitel 1 stanový termín
- Schvalovatel – Formulář pro schválení musí být jednoduchý - zaškrtnout schvaluji/neschvaluji + důvod)
Možné interakce uživatele:
- Zrušit žádost nákupu
- Uzavřít požadavek
Možné interakce schvalovatele:
- Povolení žádosti
- Zamítnutí žádosti
Možné interakce řešitele:
- Návrh na uzavření požadavku
- Převedení požadavku opět do stavu Dotaz
- Převedení požadavku do stavu Hibernace – po dohodě se zadavatelem (informace bude notifikační email) se zadáním termínu probuzení
- Označení požadavku interní volbou (červené zaškrtávátko s popisem od řešitele) = bude sloužit k projednání na operativní poradě
Systém:
Automatické uzavření po 14 dnech po nereagování zadavatele při stavu návrh k uzavření
Nástup/ přestup / výstup uživatele
U těchto požadavků je třeba vymyslet jednodušší řešení – nyní to funguje takto
Zadavatel předá vyplněný identifikační list na Helpdesk. Operátor ho předá prvnímu řešiteli a ten pak druhému, třetímu atd. Problém může nastat pokud operátor/koordinátor neuhlídá všechny aktivity tak se může stát, že ne všechny úkoly jsou splněné. Po splnění všech akcí na požadavku je vytištěn předávací list s aplikacemi a rovněž je zasílán email o přístupech a základních postupech, fyzické zprovoznění IT a jako poslední případné předání Odboru Informatiky. Zde se dostáváme kolikrát do problému, kdy my máme vše hotovo a předáme na OI a ten ho uzavře po termínu vydefinovaném v ID listu.
ID list
Příjmení, jméno, titul Iniciály
Název pracovního místa Název pracovního místa
Osobní číslo Osobní číslo zaměstnance
Odbor zde bude předvyplněný seznam odborů
Oddělení zde bude předvyplněný seznam oddělení
Kód pracovního místa Číselný kód pracovního místa
Datum nástupu datum nástupu zaměstnance
Umístění pracovníka zde budou předvyplněné budovy
Pevná linka číslo telefonní linky
Požadavky na Hardware zde bude vydefinováno PC nebo Notebook
Požadavky na Software :
Uživateli se zobrazí seznam všech aplikací a ty standardní budou zaškrtnuté automaticky případně dle odboru budou vydefinované jimi využívané aplikace, které budou zaškrtnuté
Přístup do složek a aplikací IS SML: Vydefinování speciálních přístupových oprávnění
Vydefinování oprávnění do globálního sdíleného kalendáře - předvyplněný seznam sdílených kalendářů s oprávněním čtení
Přístup do sdíleného kalendáře Sdílet kalendář komu
/ editor
Napsat jméno pracovníka s vydefinováním oprávnění čtení / editor
Přístup do složek a aplikací IS SML: Proces :
Zadavatel - operátor - řešitel
- Zadavatel vyplní formulář ID List
- Požadavek je předáván jednotlivým řešitelů dle agend - ideálně, aby zadavatel/operátor zaškrtli agendy a ty se přidali jako úkol v požadavku jednotlivým řešitelům a ty potvrdí zápisem/zaškrtnutím, že úkol splnili (v zápisu můžou být i vygenerované přihlašovací údaje)
- řešitel určí termín dle nástupu/výstupu/přestupu zaměstnance na konkrétní den
Možné interakce uživatele:
- Předání vyplněného ID listu
- Doplnění ID listu
- Otevřít požadavek v termínu vyřešení (Převést ho do stavu řešení a SLA termín je opětovně aktivován)
- Uzavřít požadavek
- Odmítnutí návrhu na uzavření požadavku – požadavek se vrátí zpět k řešiteli a opětovně se zapíná SLA termín)
Možné interakce řešitele:
- Návrh na uzavření požadavku (v tomto případě se jedná o termín dne nikoliv přesných hodin)
- Převedení požadavku opět do stavu Dotaz
- Převedení požadavku do stavu Termín vyřešení – po dohodě se zadavatelem (informace bude notifikační email) se zadáním termínu probuzení (zde se předpokládá termín nástupu uživatele tj. den nikoliv hodiny)
- Označení požadavku interní volbou (červené zaškrtávátko s popisem od řešitele) = bude sloužit k projednání na operativní poradě
Systém:
Automatické uzavření po 14 dnech po nereagování zadavatele při stavu návrh k uzavření Žádost o přidělení práv v SW
Proces :
Zadavatel - operátor - schvalovatel - řešitel
Možné interakce uživatele:
- Upřesnit agendy
- Uzavřít požadavek
Možné interakce schvalovatele:
- Povolit / zamítnout oprávnění
- Uzavřít požadavek
Možné interakce řešitele:
- Návrh na uzavření požadavku
- Označení požadavku interní volbou (červené zaškrtávátko s popisem od řešitele) = bude sloužit k projednání na operativní poradě
Systém:
Automatické uzavření po 14 dnech po nereagování zadavatele při stavu návrh k uzavření
Vývojový požadavek Proces :
Zadavatel - operátor - řešitel
řešitel zadá předběžný termín ( den ) vyřešení vývojového požadavku
Řešitel má možnost v požadavku označit problém, který neumí vyřešit bez zásahu nadřízeného a tento požadavek bude možné jednoznačně idenfikovat ( týdenní report )
Možné interakce uživatele:
- Otevřít požadavek v Termín vyřešení
- Reaguje na dotaz a požadavek změní do stavu řešení
- Uzavřít požadavek
Možné interakce řešitele:
- Návrh na uzavření požadavku
- Převedení požadavku opět do stavu Dotaz
- Převedení požadavku do stavu Termín vyřešení – po dohodě se zadavatelem (informace bude notifikační email) se zadáním termínu probuzení
- Označení požadavku interní volbou ( červené zaškrtávátko s popisem od řešitele ) = bude sloužit k projednání na operativní poradě
Systém:
Automatické uzavření po 14 dnech po nereagování zadavatele při stavu návrh k uzavření
Systém hodnocenı́
Návrh systému hodnocení uživatelem :
Uživatelé budou moci vyhodnocovat tato kritéria :
Byl/a jste spokojen/a s vyřešením požadavku? (zde se jedná o posouzení rychlosti, kvality, ….) Komentáře zadavatele (více než 4 povinné):
Komentáře řešitele (více než 4 povinné):
Byl/a jste spokojen/a s komunikací řešitele? (úroveň komunikace, empatie, slušnost….) Komentáře zadavatele (více než 4 povinné):
Komentáře řešitele (více než 4 povinné):
- V případě kdy bude hodnocení větší, než 3 bude uživatel nucen zadat důvod.
- Automaticky uzavřený požadavek bude mít vyplněné automaticky pole známkou 3 s odlišením, že se jedná o automatické vyhodnocení
Výsledkem těchto hodnocení bude možno vytvářet výstupy. Budou stanoveny konkrétní typy těchto výstupů, jejichž cílem je pro vedoucí pracovníky přenášet v pravidelných intervalech (jednou za 3, 4, 6, … měsíců)informaci o funkčnosti systému dle stanovených
Typy hodnocení :
1 – Velmi spokojen - naprosto spokojený s vyřešením požadavku, řešitel velmi aktivně komunikoval 2 – Spokojen – spokojený s vyřešením požadavku
3 – Standard ( tento stav by defaultně byl i u automaticky hodnocených požadavků ) – standardně vyřešený požadavek, nebylo k němu co hodnotit
4 – Nespokojen/a s vyřešením požadavku – uživatel nebyl spokojen s vyřešením požadavku – nutnost vyplnit důvod nespokojenosti
5 – Zcela nespokojen/a s vyřešením požadavku – uživatel byl zcela nespokojen s vyřešením požadavku – nutnost vyplnit důvod nespokojenosti
Takto je možné vyhodnotit LIS dle známek, které všichni znají a dokáží si pod tím představit reálnou spokojenost/ nespokojenost.
U požadavků hodnocených 4 a 5 je nutné i vyjádření řešitele, aby se udělal ucelený pohled na nespokojenost zákazníka.
Hodnocení by probíhalo při uzavírání zadavatelem.Odpovědi se budou zapisovat do databáze dle jednotlivých organizací do jednoho souboru
Nová podoba reportu z Helpdesku ( týdennıho )
Report požadavků bude obsahovat tato pole :
- Organizace – Název požadavku – Popis – datum zadání – zákazník – řešitel – datum poslední aktivity – počet aktivit na požadavku – přepokládaný termín řešení (pokud není v termínu SLA ) – subdodavatel – problém ANO-NE
Ze seznamu budou vykomunikovány požadavky, kde jsou vyznačeny problémy k dalšímu řešení ( eskalaci )
- k prvnímu dni měsíce přehled všech požadavků zadaných na helpdesk z minulého měsíce
Všeobecné požadavky na chovánı́ systému
- Odstranit funkci blokování/odblokování požadavků kdy chceme vynechat následující kroky : Kliknu na stav čekání a pak ho znovu musím potvrzovat – stejně tak je to pokud stisknu tlačítko přijmout požadavek tak ho pak ještě jednou musím potvrzovat
- Zpřehlednit poznámky, které si vyměňují zákazník – řešitel – posuvník zde nefunguje po řádcích - Tam, kde jsou poznámky krátké problém se čtením nenastává a dá se posouvat po řádcích. Poznámka by se měla použít jen pro kratší informaci. V upgrade aplikace, který je možné u vás provést je možnost přidání přílohy k poznámce. Informace o příloze je viditelná v Historii požadavku a přílohu je možné otevřít přímo z řádku zapsaného v Historii.
- Možnost jednoduchého ukládání příloh (více příloh najednou) – v požadavku, možnost jednoduchého uložení přílohy jedním kliknutím
- Možnost přidání sloupce v celkovém přehledu – datum a čas poslední reakce
- U požadavku bude číselně uveden počet aktivit
- Zvýraznění požadavku, na který potřebuje řešitel upozornit své nadřízené
- Zjednodušit formulář schvalovatele (Schváleno/neschváleno + důvod/poznámka)
- Zpřístupnit identifikaci IP adres virtuálních stanic přímo v požadavku
- Zohlednit změnu telefonu u uživatele a nastavit jí jako primární ( nyní se nám zobrazuje více telefonů )
Toto se děje vždy při změně umístění uživatele
Úprava stávajícího Helpdesku
– kapitola bude realizována v rámci systémové podpory
pokud uživatel píše požadavek a neuloží ho, minimalizuje si obrazovku tak se na helpdesku objeví jako nový ačkoliv ho uživatel neukládal
Umožnění zapsání v požadavku počet hodin strávených na zakázce:
V případě potřeby vyhodnocování zakázky potřebujeme mít možnost zjištění, zdali práce, které jsou prováděny jsou prováděny v rámci smlouvy ( příklad : požadavky strávené na zakázkách od jednoho zákazníka jsou zapsány po vyřešení a jsou ihned uzavřeny, tj. není možné u nich sledovat časovou náročnost) V případě potřeby bychom potřebovali mít
- Nastavení dnů pracovního klidu v Helpdesku
V Liberci dne: 26. 6. 2018 V České Xxxx dne:
……………………………………………………. …………………………………………………….
Za Libereckou IS, a.s. Za Datron a.s.
Xxx. Xxxxxxxx Xxxxx, MBA Xxx. Xxxxxx Xxxxxxx, Ing. Xxxxxxx, Xxxxx