CDESK 3.2.10 přináší významný posun v řízení požadavků a procesů. Klíčovou novinkou je přechod k systematickému managementu změn a incidentů – nové stavy požadavků, určení manažerů změn a lepší kontrola procesního toku.
Součástí verze je i slučování požadavků včetně diskuse, rozšířené možnosti projektového řízení, úpravy v CMDB a Evidenci majetku, vylepšené schvalování, notifikace a optimalizace mobilního rozhraní.
Obsah článku
- Přidání sloupců posledních reakcí řešitele a žadatel
- Datum poslední reakce žadatele
- Poslední reakce žadatele
- Datum poslední reakce řešitele
- Poslední reakce řešitele
- Výběr společnosti v Katalogu požadavků v Úvodním přehledu
- Rozlišování automatického a uživatelem provedeného hodnocení při akceptaci
- Přidání filtrování podle viditelnosti záznamů
- Přidání sloupce Kořenový záznam s nejvyšším nadřazeným záznamem požadavku
- Umožnění propojovat požadavky z odlišných společností
- Vytvoření řešitelské skupiny projektového týmu na projektové zakázce
- Zobrazení hierarchie projektových zakázek v detailu požadavku
- Dědění projektového manažera, priority a projektového týmu z nadřazené projektové zakázky
- Přidání prioritizace projektových zakázek, včetně nového sloupce Priorita
- Požadavky vytvořeno na projektové zakázce přebírají její termíny splnění od
- Požadavky vytvořeno na projektové zakázce dědí její režim plánování
Slučování více požadavků do primárního požadavku včetně diskuse
V praxi se stává, že při výskytu poruchy v systému je nahlášena více uživateli a vznikají duplicitní požadavky. CDESK 3.2.10 umožňuje duplicity odstranit formou slučování požadavků do jedné. Označením více požadavků, při kterých jsou splněna systémová omezení, zobrazíte možnost sloučit tyto záznamy do jednoho požadavku.
Po kliknutí na možnost Sloučit je třeba zvolit primární požadavek, který se stane základním nositelem nastavení, a pod kterou vybrané požadavky procházejí. Sloučit můžete také
- Popisy požadavků
- Přílohy požadavků – Diskusní příspěvky
- Příjemce diskuse (které je možné o procesu sloučení ihned notifikovat)
- Navázány konfigurační položky
Sloučené požadavky se ukončí a přesunou do archivu. Takto ukončené požadavky obsahují informaci o sloučení v hlavičce.
Zlepšení řízení změnových požadavků (nové stavy požadavků, určení manažera změn a efektivnější kontrola procesů)
Aplikovali jsme více změn, které posilují kontrolu a řízení rizik při změnách. Přidáním těchto funkcí děláme další krok k naplnění požadavků ZoKB pro naše klienty a snížení pravděpodobnosti nekonzistentních zásahů do provozu. Jasná odpovědnost a vyšší procesní disciplína.
- Manažer požadavku
- Roli vybíráte v šabloně požadavku
- Má plný přístup k požadavku (čtení, editace, mazání) včetně požadavků ve stavech K posouzení, K vyhodnocení. Manažer není v tomto případě ovlivněn omezením oprávnění v nastaveních uživatele.
- Manažer typu požadavku
- Konfigurovatelný pro typ požadavku
- Má plný přístup k požadavkům daného typu, bez ohledu na oprávnění a stavy těchto požadavků.
- Stav K posouzení
- Aktivuje se automaticky po zadání požadavku (je-li funkce zapnuta)
- Požadavek se uzamkne, před dalšími kroky musí proces povolit manažer požadavku (manažer typu požadavku)
- Stav může podléhat SLA
- Stav K doplnění
- Manažer může požadavek vrátit zadavateli k doplnění údajů
- Stav K vyhodnocení
- Používá se před ukončením požadavku
- Požadavek v tomto stavu upravuje výhradně manažer požadavku (manažer typu požadavku)
Pro potřeby change managementu a problem managementu rozšiřujeme notifikační model při posuzování požadavků.
Dosud při přechodu požadavku do stavu K posouzení neexistovala samostatná notifikační událost. Všechny oznámení v tomto bodě spadaly pod událost Nový požadavek, což neumožňovalo cíleně informovat manažery odpovědných za posuzování.
Nově přibývá samostatná událost Posuzování požadavku, v rámci, kterého je možné:
- notifikovat manažera požadavku a manažery podle typu požadavku (primární cíl)
- volitelně zapojit i další role, stejně jak při ostatních notifikačních událostech požadavků.
Zároveň se upravuje logika nové požadavky:
- požadavek se nepovažuje za nový v okamžiku vytvoření
- za nový je považován až od okamžiku, kdy přejde do řešení, tedy po posouzení nebo schválení.
Tato úprava umožňuje jasně oddělit fázi posuzování od samotného řešení a přesněji cílit oznámení na odpovědné osoby.
Obecné funkce
Centrální vyhledávání doplněno i o ukončené objekty za posledních 14 dnů
S verzí 3.2.10 zahrnuje centrální vyhledávání kromě otevřených objektů i ty, které byly ukončeny či uzavřeny za posledních 14 dní.
Jedná se o změnu pouze ve vyhledávacích podmínkách – bez dopadu na běžné filtry v seznamech a bez zbytečného zpomalování systému.
Požadavky
Přidání sloupců posledních reakcí řešitele a žadatele
Cílem je identifikovat požadavky, které vyžadují reakci. Standardně jde o situace, kdy je třeba, aby řešitel odpověděl na poslední reakci zákazníka nebo koncového uživatele – tedy aby v požadavcích nezůstávaly žádné zákaznické příspěvky typu nezodpovězeno. Zároveň je důležité mít možnost ověřit, zda zákazník nereagoval na odpověď řešitele. Na podporu tohoto způsobu práce byly do seznamu požadavků doplněno filtrovatelné a řaditelné sloupce, které tyto stavy jednoznačně vyjadřují a umožňují efektivnější organizaci podpory.
Do seznamu požadavků přibyly 4 nové sloupce:
- Datum poslední reakce žadatele
- Poslední reakce žadatele
- Datum poslední reakce řešitele
- Poslední reakce řešitele
Hodnoty sloupců jsou průběžně vyplňovány a mazány podle akcí popsaných níže. Z pohledu dodržení termínů se vždy zaměřujete na hlavní datování sloupce, jak Termín odezvy, Termín splnění a to zejména, jsou-li všechny 4 sloupce prázdné.
Datum poslední reakce žadatele
Zobrazuje datum a čas poslední akce ze strany zákazníka, která vyžaduje reakci řešitele. Jedná se o:
- vytvoření nového požadavku ve stavu přijato
- přidán diskusní příspěvek žadatele
- změnu stavu zpět na v řešení
Tento sloupec je viditelný pouze pro účty řešitelů a administrátorů. Datum a čas uvedený ve sloupci se maže, když na požadavku nastane reakce řešitele.
Sloupce Datum poslední reakce žadatele / řešitele zůstanou prázdné v případě, že stav požadavku je ve stavu čekání, testování zákazníkům, činnost nasazení, odloženo, pozastaveno nebo nabídka.
Poslední reakce žadatele
Ve sloupci je obsah poslední reakce zákazníka, například diskusní příspěvek nebo změna stavu. Při přejetí kurzorem se zobrazí i detail změny se jménem uživatele, který změnu provedl. Tento sloupec je viditelný pouze pro účty řešitelů a administrátorů.
Datum poslední reakce řešitele
Zobrazuje datum a čas poslední akce řešitele požadavku. Jedná se o:
- přidání příspěvku do diskuse se zákazníkem
- změnu stavu požadavku
Tento sloupec je viditelný pro všechny oprávněné uživatele bez ohledu na roli.
Poslední reakce řešitele
Informuje textově o reakci, kterou naposledy řešitel provedl (přidání diskusního příspěvku, změna stavu). Při přechodu kurzorem na text se zobrazí detail akce spolu se jménem řešitele provádějícího změnu. Tento sloupec je viditelný pro všechny uživatele bez ohledu na roli.
Výběr společnosti v Katalogu požadavků v Úvodním přehledu
Do widgetu Katalog požadavků v úvodním přehledu přibyla možnost přepínat společnost, za kterou se katalog zobrazuje.
Ve widgetu se ve výchozím nastavení zobrazují dlaždice pro společnost nastavenou v profilu uživatele (resp. první přiřazenou společnost). Tato společnost je zároveň předvyplněna ve výběrovém poli. Pokud má uživatel oprávnění zadávat požadavky za více společností, může společnost ručně změnit. Po změně se automaticky obnoví seznam dlaždic, aby odpovídal katalogu dostupnému pro zvolenou společnost.
Tato změna reflektuje způsob práce se šablonami požadavků, které mohou být zpřístupněny pouze pro vybrané společnosti.
Rozlišování automatického a uživatelem provedeného hodnocení při akceptaci
Do sloupce Známka hodnocení jsme doplnili rozlišení požadavků, které byly ukončeny automaticky po uplynutí nastavené lhůty.
V případě automatického ukončení požadavku:
- Ve sloupci Známka hodnocení se zapíše hodnota Automaticky
- Systém umožňuje použít i jinou hodnotu, pokud je definována pro automatické ukončení požadavku
Podle této hodnoty je možné požadavky filtrovat.
Přidání filtrování podle viditelnosti záznamů
Seznamy požadavků lze filtrovat podle parametru Viditelnost (interní a obyčejné požadavky).
Přidání sloupce Kořenový záznam s nejvyšším nadřazeným záznamem požadavku
Do seznamu požadavků přibyl sloupec Kořenový záznam. Pokud má požadavek nadřazený záznam, v tomto sloupci se zobrazí ten hierarchicky nejvyšší. Může jít o nadřazený požadavek, projektovou zakázku, nebo projekt.
Sloupec obsahuje kód a název nadřazeného záznamu, jakož i možnost prokliku přímo do detailu záznamu.
Umožnění propojovat požadavky z odlišných společností
V CDESK jsme upravili způsob práce s propojenými požadavky tak, aby lépe odpovídal reálným potřebám uživatelů a jejich oprávněním.
Uživatelé mohou nově vytvářet a propojovat související, nadřazené a podřazené požadavky bez omezení na společnost nastavenou na nadřazeném požadavku. Při vytváření nového propojeného požadavku se společnost ve výchozím nastavení zdědí, ale uživatel ji může podle potřeby změnit.
Konfigurační databáze
Zjednodušení managementu struktury a záznamů
Upravili jsme několik detailů, které usnadňují zakládání nových CI a jejich třídění do skupin a typů.
Na úrovni skupin, přímo po kliknutí na ikonu hamburger menu je dostupné:
- Vytvořit skupinu
- Vytvořit typ položky
- Smazat skupinu
- Upravit detail skupiny
Na úrovni typu položky
- Přidat položku
- Tyto akce jsou dostupné přímo z kontextového menu, bez nutnosti vcházet do detailů záznamů.
Přidání zobrazení aktivních položek
Klepnutím tlačítka filtrujete všechny neaktivní a nearchivované položky, takže seznam zobrazí pouze ty, které se aktivně používají. Touto funkcí můžete dosáhnout i vyšší rychlost při práci s položkami.
Plnění
Přidány 4 sloupce v seznamu schvalování plnění
Přidali jsme sloupce: Datum plnění, Fakturovaná částka, Reálně odpracovaný čas a
Kód zakázky. Uživatel může tyto sloupce přidávat a odebírat, stejně tak mohou být tyto sloupce součástí exportu a lze podle nich filtrovat.
Zobrazení interních plnění je v seznamu možné vypnout a zapnout
V Seznamu plnění a v seznamu Schvalování plnění jsme přidali checkbox, kterým vypínáte a zapínáte zobrazování interních plnění. Vypnutí zobrazení znemožní přidávat interní plnění do exportů.
Úprava reálně odpracovaného času ve fakturačním plnění
Pokud reálně odpracovaný čas na fakturačním plnění je právě z jednoho interního plnění, bude možné ho editovat přes formulář fakturačního plnění
Přenos reálně odpracovaného času do času fakturačního plnění
Při zadávání časového údaje v poli Reálně odpracovaný čas se automaticky synchronizuje i hodnota Fakturačního času plnění. Platí to při zjednodušeném zadávání, a také při označení časového úseku.
Evidence majetku
Přidání stromové struktury do Evidence majetku
Do Evidence majetku se s novou verzí přenáší také stromová struktura z CMDB. Tato struktura se nachází také u inventarizací, konkrétně při výběru majetku a lokality.
Přidání sloupce Stav předávacích protokolů
Do modulu seznamu předávacích protokolů doplňujeme indikátory stavu předávacích protokolů, aby bylo již ze seznamu jednoznačně viditelné, v jakém stavu se protokol nachází a zda byl podepsán.
Dosud se stav předávacího protokolu samostatně neevidoval, co ztěžovalo rychlou orientaci – zejména rozlišení mezi podepsanými a nepodepsanými protokoly.
Do seznamu předávacích protokolů přibyl nový sloupec Stav, který vychází z reálného průběhu podepisování:
- V přípravě – předávací protokol je vytvořen, podepisování přes CDESK není aktivováno
- K podepsání – podepisování přes CDESK je aktivováno, protokol zatím nepodepsala žádná strana
- Částečně podepsáno – protokol podepsala jedna ze stran
- Podepsáno – protokol podepsaly obě strany
Pro lepší přehlednost jsme doplnili i vizuální indikaci přímo v seznamu. Ve sloupcích Předávající a Přebírající se po podepsání zobrazí u jména uživatele zelený symbol, který označuje, že daná strana již předávací protokol podepsala.
Přidání sloupce s poslední změnou v assetu v seznamu majetku
Do seznamu majetku doplňujeme sloupec Poslední změna, který poskytne přehled o tom, co se na záznamu změnilo naposledy a kdy ke změně došlo.
Sloupec je koncepčně stejný jako v modulu Požadavky, nicméně je rozšířen o datovou informaci, aby bylo možné podle ní filtrovat a třídit záznamy. Cílem je rychle identifikovat majetek, na kterém proběhla poslední úprava, bez nutnosti otevírat detail záznamu.
Rozšíření centrálního vyhledávání o sériová čísla zařízení v požadavcích
Do centrálního vyhledávání jsme přidaly možnosti vyhledávání i o sériové číslo zařízení, které je k požadavku připojeno ze skladových karet prostřednictvím rozšíření Servis zařízení.
Vyhledávání podle sériového čísla je dostupné za následujících podmínek:
- v prostředí je aktivováno rozšíření Servis zařízení (typ požadavku)
- uživatel vyhledává cíleně v požadavcích pomocí zkratky cdr, za kterou následuje sériové číslo zařízení nebo jeho část.
Během psaní se v dropdown seznamu zobrazují výsledky pouze z otevřených požadavků, aby byly prioritně nabídnuty aktivní záznamy. Po potvrzení vyhledávání klávesou Enter je však možné rozšířit vyhledávání i na ukončené požadavky, a to zapnutím příslušného checkboxu.
Projekty
Vytvoření řešitelské skupiny projektového týmu na projektové zakázce
Do projektových požadavků přibyla možnost automaticky pracovat s projektovým týmem jako s řešitelskou skupinou. Cílem úpravy je zjednodušit přidělování řešitelů a zajistit, aby se všichni členové projektového týmu na projektové zakázce konzistentně nabízeli jako řešitelé pro související požadavky.
Mechanismus je dostupný pouze v případě, že je v Globálních nastaveních zapnutý projektový tým na projektových zakázkách.
- V šabloně požadavky přibyla v poli Upřednostnit řešitele nová možnost Projektový tým. Pokud se požadavek vytvoří ze šablony s touto volbou a je vázán na projektovou zakázku, jak řešitelská skupina se automaticky nastaví Projektový tým
- Pro každou projektovou zakázku, která má definovaný projektový tým (alespoň jednoho řešitele), se dynamicky vytvoří virtuální řešitelská skupina (s názvem Projektový tým + kód a název projektové zakázky)
- Funkcionalita se vztahuje na požadavky přímo vázané pod projektovou zakázku, i na podřazené požadavky pod touto zakázkou
Zobrazení hierarchie projektových zakázek v detailu požadavku
V poli Projektová zakázka v požadavku se nyní zobrazuje hierarchické uspořádání projektových zakázek.
Hierarchie se zobrazuje od nejbližšího (aktuálního) záznamu směrem nahoru, tedy zleva doprava až po nejvyšší (kořenový) záznam. Jednotlivé úrovně hierarchie jsou odděleny znakem „›“.
Dědění projektového manažera, priority a projektového týmu z nadřazené projektové zakázky
Do projektových zakázek jsme doplnili mechanismus dědění projektového manažera, priority a projektového týmu směrem na podřazené projektové zakázky. Cílem je sjednotit chování v hierarchii projektů a snížit potřebu manuálního nastavování stejných hodnot na více úrovních.
Přidání prioritizace projektových zakázek, včetně nového sloupce Priorita
Umožňujeme vytvářet a nastavovat žebříček priorit pro projektové zakázky. Jejich seznam s možností vytváření nových stupňů se nachází v Globálních nastaveních. Priority mohou být na prostředí nastaveny jako nepovinná hodnota, povinná hodnota, nebo mohou být vypnuty (výchozí stav).
Uživatelům nabízíme předem nastavený žebříček priorit, který mohou upravit, přidat či odebrat stupně, případně změnit jejich ikony a názvy.
Do seznamu projektových zakázek přibyl sloupec Priorita, podle kterého lze vyhledávat a filtrovat (hodnoty není/je)
Požadavky vytvořeno na projektové zakázce přebírají její termíny splnění od
Při vytváření nového požadavku s vazbou na projektovou zakázku jsme upravili předvyplnění termínů.
Od verze 3.2.10 platí, že pokud uživatel vytváří nový požadavek a v rámci vytváření jí přiřadí projektovou zakázku, pole Termín splnění od se automaticky nastaví na aktuální datum a čas. Cílem je zajistit konzistentní vyplnění plánování při projektových požadavcích a odstranit situace, kdy zůstával začátek termínu prázdný.
Tato úprava se uplatní pouze při vytváření nového požadavku s vazbou na projektovou zakázku. Nevztahuje se na případy, kdy se projektová zakázka doplňuje dodatečně na již existující požadavek.
Požadavky vytvořeno na projektové zakázce dědí její režim plánování
Doposud se při vytvoření nového požadavku automaticky nastavoval režim plánování Automaticky, bez ohledu na nastavení projektové zakázky. Nově se výchozí režim plánování dědí z projektové zakázky, ke které je požadavek přiřazen.
Díky této úpravě jsou požadavky od začátku harmonizovány s plánovací logikou projektu a není třeba režim plánování manuálně upravovat po vytvoření požadavku.
Schvalování
Doplnění výběru sloupců v seznamu schvalování
V seznamu schvalování jsme s verzí 3.2.10 přidali možnost vybírat sloupce.
Provádění indikátoru otevřených schvalování v hlavním menu
Do hlavního menu jsme doplnili rozšíření pro položku Schvalování, které přináší přehled o čekajících schváleních od uživatele.
Při názvu Schvalování se nově zobrazuje počet otevřených schvalování aktivního uživatele. Indikátor je zobrazen jedním číslem na žlutém podkladu, analogicky k počítadlu při požadavcích, avšak bez dalšího členění.
Přidání volného výběru schvalovatele v kroku předdefinovaného schvalování
V kroku pravidla schvalování přibyla možnost volného výběru schvalovatelů. Může jít o:
- Skupiny schvalovatelů
- Schvalovatele ze skupiny
- Schvalovatele (celkově)
Při vytváření šablon s takto předdefinovaným schvalováním lze vybrat za schvalovatele kohokoli z vybrané skupiny, nebo označit přímo celou skupinu, pokud byla do volného schvalování přidána jako skupina).
Notifikace
Přidání role do pravidel odesílání oznámení – Sledující, Přidání sledujícího, Odstranění sledujícího
Do pravidel odesílání notifikací pro požadavky jsme doplnili nové role, které rozšiřují možnosti adresování příjemců.
Nově jsou při každé notifikační události z požadavků dostupné role:
- Sledující
- Přidání sledujícího
- Odstranění sledujícího
Tyto role fungují stejně jako v notifikacích projektových zakázek a umožňují přesněji řídit, kdo a kdy obdrží oznámení v závislosti na změnách v seznamu sledujících.
Pro notifikace podle pravidel: Propojení SMS šablon na šablony požadavků a dynamické proměnné
Notifikace podle pravidel jsou zatím v beta režimu, ale používá ji už více klientů, proto jsme zařadili tento bod do novinek.
Pro uživatele se zapnutými notifikacemi podle pravidel, je možné SMS šablony vázat na konkrétní šablonu požadavku. Tímto se jednoznačně určuje použití pro daný typ požadavků. Tato vazba se zobrazuje přímo v detailu SMS šablony a slouží jako mechanismus kontroly konzistence mezi obsahem zprávy a daty, ze kterých vychází.
Při výběru SMS šablony v šabloně požadavky se tak uživateli nabízejí pouze SMS šablony propojené se šablonou požadavků, nebo SMS šablony bez vazeb.
V SMS šablonách je zároveň možné používat dynamické proměnné z uživatelských polí na šabloně požadavky. Proměnné se zobrazují přímo v detailu SMS šablony. Při použití těchto proměnných se SMS šablona automaticky uzamkne na příslušnou šablonu požadavku, aby byla zachována datová kompatibilita.
Při odesílání SMS notifikace se dynamické proměnné automaticky nahrazují konkrétními hodnotami z požadavku, tímto je zajištěn přesný a kontextově správný obsah zprávy.
Uživatelé a skupiny
Přidání sloupce Viditelné společnosti v seznamu uživatelů
Doplnili jsme nový informační sloupec – Viditelné společnosti, který rozšiřuje přehled nad stávajícím sloupcem Přiřazené společnosti.
V tomto sloupci se zobrazují všechny společnosti, které byly uživateli zviditelněny ručně, ale nejsou přímo přiřazeny. Sloupec tak slouží jako doplňková informace k přiřazení a pomáhá jednoznačně rozlišit, pro které společnosti je záznam viditelný nad rámec explicitního přiřazení.
Filtrování oprávnění – zobrazení všech povolených a zakázaných oprávnění
Do stromu oprávnění (pro skupiny i uživatele) doplňujeme nový filtr zobrazení, který umožní rychle filtrovat oprávnění podle typu nastavení a výsledného stavu.
Filtr bude dostupný jako dropdown vedle vyhledávacího pole (Vyhledávání) a bude mít tyto režimy:
- Všechny (aktuální chování, zůstává výchozí)
- Všechny explicitně povoleno (sytě zelené označení)
- Všechny explicitně zakázáno (sytě červené označení)
- Všechny zděděné (bledé označení)
- Všechny zděděné, povolené (bledě zelené označení)
- Všechny zděděné, zakázané (bledě červené označení)
Cílem je zjednodušit orientaci v rozsáhlých stromech oprávnění a umožnit rychlou kontrolu toho, která práva jsou nastavena přímo (explicitně) a která vyplývají z dědění, včetně rozlišení povolených a zakázaných oprávnění.
Kontektor integrácí s ERP
Podpora složených skladových karet (sad) v integraci s Money S4
Rozšiřujeme integraci CDESK s ekonomickým systémem Money S4 o podporu složených skladových karet (Sad). Tato úprava sjednocuje způsob práce se skladovými položkami mezi oběma systémy.
- CDESK nyní dokáže dotáhnout z Money S4 i složené skladové karty (Sady) a pracovat s nimi přímo v požadavcích.
- Při odesílání objednávky z CDESK do Money S4 se:
- o složené skladové karty neposílají jako jedna položka
- do objednávky se přenášejí pouze jednotlivé skladové karty, které tvoří danou sadu.
Integrace s CM
Automatické vkládání vzdáleného přístupu do požadavku na základě e-mailu zadavatele
Do požadavku se automaticky vloží blok se vzdáleným přístupem na počítač na základě shody e-mailu zadavatele s registračními údaji v C-Monitor. Vyhledávání je omezeno na společnost požadavky.
Obecné funkce
Centrální vyhledávání doplněno i o ukončené objekty za posledních 14 dnů
S verzí 3.2.10 zahrnuje centrální vyhledávání kromě otevřených objektů i ty, které byly ukončeny či uzavřeny za posledních 14 dní.
Jedná se o změnu pouze ve vyhledávacích podmínkách – bez dopadu na běžné filtry v seznamech a bez zbytečného zpomalování systému.