Nastavení workflow

Top  Previous  Next

Workflow není nutné definovat pro každý typ hlášení jednotlivě, je možno využít toho, že se nastavení dědí z nadřazeného typu hlášení. Platí, že workflow je aplikací hledáno nejprve u typu hlášení, který uživatel zadal a pokud nebylo nalezeno, hledá se u rodiče a dále směrem ke kořeni stromu.

 

Správně nadefinované workflow by mělo obsahovat právě jeden počáteční a alespoň jeden koncový stav. Typ stavu se volí při zakládání stavu, kromě počátečního a koncového existují ještě další typy, které definují chování aplikace v tomto stavu a zároveň usnadňují tvorbu workflow. Typ stavu mimo jiné určuje komu a jaký email se pošle při přechodu do stavu, toto standardní chování je popsáno v následující tabulce. Toto chování je možné kompletně předefinovat při editaci stavu. Dále je u stavu možné určit dobu, po kterou je povoleno zůstat ve stavu (v hodinách) a akci, která se má provést při překročení této doby - je možné poslat výstražné emaily odpovědným osobám a/nebo nechat automaticky přesunout požadavek do definovaného stavu (např. pro stav, kdy je žádáno odsouhlasení zadavatelem a zadavatel tři dny nereaguje, je možné považovat požadavek za schválený, tj. je možné jej automaticky přesunout do stavu ukončeno).

 

Typy stavů používané při tvorbě workflow

přijato na helpdesk

Počáteční stav workflow, musí být definován právě jeden stav tohoto typu. V případě, že z něj vede pouze jedna výstupní hrana, je hlášení posunuto rovnou do dalšího stavu (toto chování je doporučené). V případě prvního přechodu do tohoto stavu je poslán email zadavateli o přijetí požadavku na HelpDesk, v případě, že není stav přeskočen, se pošle email řešiteli (klasicky operátor) s žádostí o řešení požadavku

řešeno

Stav tohoto typu nezahrnuje žádné speciální funkce, vždy je poslán email řešitelům s žádostí o posunutí řešení požadavku. Zahrnuje všechny stavy v průběhu řešení požadavku.

řešeno externě

Stav tohoto typu nezahrnuje žádné speciální funkce, vždy je poslán email řešitelům s žádostí o posunutí řešení požadavku. Je doporučeno takto nastavovat všechny stavy řešené externím řešitelem (tj. řešitelem mimo organizační strukturu organizace) v průběhu řešení požadavku.

schvalováno

Stav tohoto typu by měl být použit vždy při schvalovacím procesu. Je možné nastavit přeskočení stavu v případě, že je řešitel (jeden z řešitelů) zároveň žadatelem, tj. zadavatelem požadavku. K nastavení této funkce je třeba nadefinovat maximálně jednu souhlasnou odchozí hranu. Kromě této funkce je chování ve stavu stejné, jako ve stavu typu řešeno.

vyřešeno

Řešení požadavku skončilo, uživatel je žádán o schválení řešení. Je vždy zaslán email zadavateli s žádostí o schválení, pokud jsou nadefinováni řešitelé u stavu tohoto typu, je jim poslán email s oznámením ukončení řešení a čekání na vyjádření uživatele.

zákazník nesouhlasí s řešením

Stav tohoto typu nezahrnuje žádné speciální funkce, vždy je poslán email řešitelům s žádostí o posunutí řešení požadavku. Nedoporučujeme používat stav tohoto typu v běžných workflow, raději použijte přímo stav typu řešeno.

ukončeno

Koncový stav, zahrnuje jak ukončení s vyřešením požadavku, tak zamítnutí požadavku. V případě, že do tohoto stavu se požadavek dostane zásahem řešitele, je zadavatel upozorněn na ukončení řešení požadavku. Oznámení o ukončení řešení je také zasláno případným nedefinovaným řešitelům a primárnímu řešiteli požadavku. Přestože se jedná o stav konečný, je možné definovat přechody i ze stavů typu ukončeno.

 

U jednotlivých stavů je třeba nadefinovat také přechody, klikněte na ikonku detail u stavu. U každé hrany je možné určit název, který se poté zobrazí řešiteli v seznamu možných posunů požadavku. Pokud není název hrany definován, zobrazí se název cílového stavu hrany. Ze stavu typu "vyřešeno" je nutné navíc u každé výstupní hrany nadefinovat, zda je souhlasná nebo nesouhlasná. Uživatelé se při schvalování požadavku nejprve rozhodnou, zda s řešením požadavku souhlasí nebo nesouhlasí. Poté už vybírají pouze z množiny stavů, do kterých vede (ne)souhlasná hrana dle jejich první volby. Pokud chcete uživatelům schvalování požadavku co nejvíce zjednodušit, nadefinujte z každého stavu typu „vyřešeno“ jednu souhlasnou a jednu nesouhlasnou hranu, po prvním kroku bude následný stav vybrán automaticky. V případě stavu typu "schvalováno" je také možné definovat, zda se jedná o hranu souhlasnou nebo nesouhlasnou. V případě, že je definována pouze jedna výstupní souhlasná hrana, bude tento stav přeskočen v případě, že zadavatel je jedním z řešitelů, tj. vedoucí si sám sobě schvaluje požadavek. Přechod hranou je možné podmínit předchozím stavem workflow. Pokud při editaci hrany ze stavu "vyjádření" do stavu "řešeno OIT" zadáte jako předchozí stav "řešeno OIT", půjde tato hranu použít pouze pokud je požadavek ve stavu "vyjádření" a předchozí stav byl "řešeno OIT". Pomocí této možnosti je možné definovat workflow "s odbočkou", kdy v každém stavu workflow je možné se obrátit na jakéhosi experta, který ovšem musí po vyjádření vrátit požadavek do původního stavu.

 

K přechodům lze také definovat řešitelské parametry. Ty je, pokud jsou definovány nutné nebo možné vyplnit před provedením změny stavu (přechod po hraně workflow). Řešitelské parametry lze nadefinovat stejně jako parametry uživatelské pro přizpůsobení formuláře při definici typu hlášení. Parametry je možné pojmenovat, definovat jejich povinnost, pořadí zobrazení a typ (viz 6.1.2 Přizpůsobení formuláře). Dále je nutné nadefinovat tzv. „určení“ parametru, kterým se udává, kdy je daný parametr třeba vyplnit a kde se zobrazí ve výpise:

 

Význam volby „určení“ parametrů

pro uživatele

definice vstupního formuláře požadavku, viz. 6.1.2 Přizpůsobení formuláře – vyplňuje se při zadávání požadavku

pro řešitele

řešitelský parametr, který se vyplňuje při každé změně stavu řešitelem, jeho hodnota se zobrazí u akce přesunutí (historie požadavku), tj. je možné zadat právě jednu hodnotu parametru pro každou jednu akci přesunu

pro určenou akci, výpis k akci přesunu

řešitelský parametr, který se vyplňuje při definované změně stavu řešitelem, jeho hodnota se zobrazí u akce přesunutí (historie požadavku), tj. existuje maximálně jedna hodnota parametru pro akci přesunu

pro určenou akci, výpis do hlavního přehledu

řešitelský parametr, který se vyplňuje při definované změně stavu řešitelem, jeho hodnota se zobrazí mezi údaji, které zadal zadavatel požadavku – existuje pouze jedna hodnota parametru pro jeden požadavek, pokud je parametr vyplňován u více akcí, dojde při druhé akci ke změně původní hodnoty parametru, ne k nadefinování nové hodnoty

automaticky vyplňovaný

zápis hodnoty přes externí aplikace

pro typ hlášení

definice konstantní hodnoty parametru. zadavatel ani řešitel jej nemůže změnit, definice se dědí z nadřízeného stavu a na konkrétním typu stavu se zadá jeho konkrétní hodnota, použití pro konstantní parametry předávané externí aplikaci

 

V případě, že parametr je definován „pro určenou akci“, je nutné provést definici, které přechody jsou těmi určenými akcemi. Toto je možné zadat při definici přechodů, kdy pro parametr k editovanému typu hlášení a jemu nadřízeným typům hlášení s příslušným „určením“ se zobrazí zaškrtávací pole s názvem parametru u každého přechodu.