 |
|
You are here: Foswiki>Mango Web>CibsHowToStartBmp (04 Sep 2019, UnknownUser)Edit Attach
Příklady implementace a použití v praxi
Potřebná práva pro základní práci s procesy:
| MAINTENANCE_JOBS_CHANGE_SUBSTATE | Změna stavu procesu |
| MAINTENANCE.MAINTENANCE_LIST.ACTION.INSERT | Ovlivňuje pouze zobrazení tlačítka akce na vložení nového procesu v tomto případě v modulu Procesy v tabulce se seznamem procesů |
| MAINTENANCE_LIST.INSERT | Právo na provedení akce založení nového procesu |
| MAINTENANCE_LIST.ACTION_EDIT | Ovlivňuje pouze zobrazení tlačítka akce na editaci procesu v tomto případě v modulu Procesy v tabulce se seznamem procesů |
| MAINTENANCE_LIST.EDIT | Právo na provedení akce editace procesu |
| MAINTENANCE_LIST.CREATE_BY_OPERATOR | PROCESY / Procesy / Seznam procesů / Vložení nového procesu (zobrazování typů procesů): Typ procesu se nezobrazuje, pokud není nastaveno MAINTENANCE_LIST.CREATE_BY_OPERATOR na shodný typ procesu jako je u nastaveného práva MAINTENANCE_LIST.INSERT (slouží pro případy, kde proces vzniká dle automatizace a uživatel by neměl mít možnost založit proces ručně). Typ procesu se zobrazuje, ale systém oznámí chybu, pokud je nastaveno MAINTENANCE_LIST.CREATE_BY_OPERATOR na typ procesu, který není nastaven u práva MAINTENANCE_LIST.INSERT (chybná konfigurace práv). |
| MAINTENANCE_LIST.VIEW | Umožňuje zobrazení procesu, jak v tabulkách, tak otevření samotné karty procesu |
| MAINTENANCE_SUBSTATE | Definuje právo na daný stav procesu |
| MENU_ITEM | Pro zobrazení položky ŘÍZENÍ v menu nastavte hodnotu SERVIS |
| MENU_ITEM | Pro zobrazení položky PROCESY v menu ŘÍZENÍ nastavte hodnotu SERVIS.SERVISNÍ ZÁSAHY |
| MODULE | Pro zobrazení modulu PROCESY nastavte hodnotu MAINTENANCE |
| MODULE_VIEW | Pro zobrazení záložky Dashboard v modulu PROCESY nastavte hodnotu |
Typ procesu, stavy a diagram přechodů
Pro správu přijatých zakázek opravy spotřebičů bude vytvořen jeden typ procesu, pojmenovaný jako “Oprava”. Zároveň, jelikož se nebude v tomto příkladu pracovat s evidencí zákazníka, je nutné jí v typu procesu explicitně vypnout.V modulu Nastavení procesů, záložka Typy vybrat akci “Vložení nového typu procesu”.
, záložka Stavy a parametry, vybrat akci "Vytvoření nového stavu".
Jelikož se vkládá první stav, bude označen jako počáteční a budou jím začínat všechny nově vytvořené procesy. Zároveň jelikož tato implementace nepoužívá úkoly (není tedy striktně definováno, jací uživatelé mají proces kdy zpracovávat), je nutné odškrtnout při vytvoření každého stavu políčko “Vyžadován úkol”., záložka Stavy a parametry vybrat v tabulce "Parametry" akci "Vložení definice parametru".
Takto je vložen první parametr sloužící k uchování telefonního čísla, interně pojmenovaný jako “PHONE_NUMBER”, zobrazovaný jako “Telefonní číslo” typu řetězec. Nemá žádné podmínky závislostí, je vždy viditelný a editovatelný, není nikdy povinný. Podobným způsobem je možné přidat další parametry pro jméno zákazníka (typ řetězec), popis závady (typ text) a popis řešení (typ text).
Konfigurace dashboard pro pracovníka
) pro pracovníka, resp. jeho účet v Mango Control. K tomu je nutné, aby se pracovník (nebo systémový integrátor na jeho účet) přihlásil a přepnul se do modulu “Procesy”, záložka “Dashboard”. Ve výchozím stavu bude obsahovat pouze tabulku “Moje procesy”, kde nebude nyní žádný proces zobrazen. Jak bylo zmíněno na začátku, tento příklad je zjednodušený a nepoužívá úkoly pro přiřazování odpovědných zdrojů (v tomto případě pracovníků) k procesům. Tabulku “Moje procesy” je možné v tuto chvíli skrýt a místo ní zobrazovat procesy pouze na základě jejich stavu. Pomocí tlačítka “Přidat další objekt” přidat tabulku s procesy a nastavit jí výchozí pohledy dle následujících pravidel: (detaily ohledně konfigurace Dashboard lze nalézt v sekci Dashboard této dokumentace)- První pohled bude obsahovat seznam zakázek, které jsou teprve přijaty a pracovník bude řešit opravu spotřebiče. Bude filtrována dle stavu procesu “Nahlášeno” a seřazena dle data přijetí od nejstaršího.
- Druhý pohled bude obsahovat seznam zakázek, které jsou již opravené, ale zákazníkovi se stále nepodařilo dovolat a domluvit s ním převzetí spotřebiče zpět.
- Poslední, třetí pohled bude obsahovat seznam zakázek, které jsou již opraveny a zákazník byl i informován o možnosti jejich vyzvednutí.
Práce se systémem, přijetí nové zakázky
Pracovníka na prodejně navštíví zákazník s porouchaným vysavačem a prosbou o jeho opravu. Pracovník zaeviduje novou zakázku (proces) do Mango Control. V Modulu Procesy na záložce “Dashboard” vybrat v libovolné tabulce akci “Vložení nového procesu”. V dialogu vyplnit pole (parametry) s informacemi od zákazníka a uložit. Tím je zakázka zaevidována a čeká na opravu.
Poté přijde druhý a třetí zákazník opět s požadavkem na opravu jejich spotřebiče, pracovník stejným způsobem pro jejich opravy vytvoří procesy. Nakonec budou evidovány 3 požadavky k opravě.
Jelikož nyní již žádný zákazník nepřichází, může se pracovník začít věnovat první opravě. Opraví první přijatý požadavek vadného vysavače, následně zatelefonuje zákazníkovi a informuje jej, že si může přijít jej vyzvednout. Proces přesune do stavu "K vyzvednutí"
Následně se může začít věnovat druhé zakázce, opraví vadný toastovač a opět zatelefonuje zákazníkovi. Ten ale jeho telefonát nepřijímá, pracovník tak přesouvá proces do stavu "Zatelefonovat".
Tím pracovní den končí a pracovník odchází domů.
Druhý den přijde do práce, přihlásí se do Mango Control a vidí stav svých zakázek - Měl by opravit lampu
- Měl by zavolat panu Rybářovi, že se může stavit pro toastovač
- Očekávat pana Fuksu, přijde si pro vysavač
Pracovník zkusí zavolat panu Rybářovi, tentokrát se dovolá a domluví si převzetí jeho spotřebiče. Proces posune do stavu "Čeká na vyzvednutí"
Po nějaké době se pan Rybář dostaví na prodejnu a toastovač si vyzvedne. Proces bude přesunut do posledního (koncového) stavu "Vyzvednuto" čímž se ukončí a z dashboard zmizí.
Příklad 2, úkoly a automatizace, tisk dokladu
Úvod
Příklad druhý si klade za cíl ukázat rozšíření toho předchozího o rozřazování práce na projektu mezi více zaměstnanců (zdrojů). Součástí ukázky bude i demonstrace možností přípravy a tisku vlastních dokumentů.Popis situace z praxe
Servis elektroniky z prvního příkladu začal prosperovat, zákazníci byli vždy spokojení a tak se jejich počet časem zvýšil natolik, že jeden pracovník již nebyl schopen stíhat všechny požadavky vyřídit. Majitel se proto rozhodl přijmout nového zaměstnance, asistentku, která bude přijímat nové zakázky od zákazníků, bude jim telefonicky oznamovat možnost vyzvednutí opraveného spotřebiče a zároveň je i vydávat. Současný pracovník se bude nadále už věnovat pouze opravám v zázemí servisu, v následujícím textu už bude nazýván jen jako servisní technik. Oba zaměstnanci spolu nebudou muset být celý den v kontaktu, ale přesto budou muset pracovat na společných procesech a jejich koordinaci bude zajišťovat Mango Control. Současně s touto změnou bylo rozhodnuto, že ruční vypisování protokolů o opravě je zdlouhavé a neefektivní, dokument bude sestaven přímo v Mango Control a asistentkou pouze vytištěn.Implementace
Pro implementaci budou využity úkoly, které představují mnohem mocnější nástroj rozdělování práce než samotné řízení prostřednictvím stavu procesu. Pomocí automatizace bude zajištěno, že má-li daný zdroj (technik nebo asistentka) na procesu v dané fázi pracovat, má zároveň i pro tento úkon naplánován úkol. Jakmile práci dokončí, posune proces do dalšího stavu, čímž se stávající úkol dokončí a zároveň vytvoří nový (pokud se nejednalo o přesun do stavu “K vyzvednutí”, kde iniciativu přebírá zákazník a zaměstnanci na procesu nepracují).Vytvoření nového účtu pro asistentku
Vytvoření nového účtu pro asistentku lze provést shodným způsobem jako pro pracovníka servisu v předchozím příkladu.Úprava dashboard servisního technika
Zobrazení procesů na dashboard se už nebude řídit stavem procesu, ale využijí se mnohem mocnější úkoly. Díky tomu je možné začít používat tabulku Moje Procesy na Dashboardu, současně s tím servisní technik už nebude potřebovat žádné další seznamy procesů, proto je možné je odstranit. Tabulka moje procesy bude řazena dle data nahlášení, technik tedy bude pracovat na opravách ve stejném pořadí, v jakém zákazníci přišli do provozovny.
Úprava dashboard asistentka
Kromě samotného zakládání procesů bude asistentka pracovat i na probíhajících procesech, a to formou obvolávání zákazníků a předávání výzvy, aby se pro opravený spotřebič dostavili. I ona bude používat na Dashboard tabulku moje procesy. Tabulka bude opět řazena dle data nahlášení, nicméně se předpokládá, že asistentka bude zkoušet v nějakém časovém intervalu obvolat vždy všechny zákazníky s dokončenou opravou, kdy na pořadí nijak záležet nebude. Jakmile přesune procesy do stavu "K vyzvednutí", bude čekat na zákazníka až si pro opravený spotřebič příjde. Vzhledem k tomu, že v tomto stavu není na asistentku iniciativa, nebudeme jí standardně tyto procesy zobrazovat.
Staví-li se zákazník pro opravený spotřebič, bude v této tabulce dohledávat daný proces pomocí druhého pohledu "K vyzvednutí".
Změna diagramu stavů a přechodů
Změnou organizace práce dojde i k mírné změně diagramu stavů a přechodů. Nově nebude technik nikdy okamžitě telefonovat zákazníkovi o dokončené opravě, ale vždy pouze předá proces asistentce a ta hovor obstará. Diagram se tak mírně zjednoduší:
Nastavení automatizace
V modulu , záložce Stavy a parametry provedeme editaci stavu "Nahlášeno", kde nastavíme akci "Nový úkol". Úkol s popiskem "Opravit" bude vytvořen pro zdroj (náš servisní technik Petr Kučera) a bude muset být dokončen dříve, než provedeme přechod do stavu "Zatelefonovat". Editace stavu vypadá takto:
.
| MAINTENANCE_SOURCE | Zdroj (technik), kterého chcete použít pro nastavení automatizace musí mít přiřazeno toto právo. |
| MAINTENANCE_JOBS_JOB_LIST.INSERT | Vložení nového úkolu. |
| MAINTENANCE_JOBS_EDIT.SCHEDULE | Naplánování termínu úkolu, přiřazení zdroje. |
- První automatizace nebude pro stav, ale přechod "Nahlášeno"->"Zatelefonovat". Akce bude opět "Nový úkol", zdroj nastavíme asistentku, nově vytvořený úkol pojmenujeme např. "Zavolej zákazníkovi" a zaškrtneme koncový stav "K vyzvednutí". Úkol tedy bude muset být dokončen dříve, než asistentka předá proces do stavu "K vyzvednutí".
- Druhá automatizace bude pro stav "K vyzvednutí". Akce bude "Nový úkol", zdroj nastavíme asistentku, nově vytvořený úkol pojmenujeme např. "Předej zboží zákazníkovi" a zaškrtneme koncový stav "Vyzvednuto". Úkol tedy bude muset být dokončen dříve, než asistentka proces ukončí přechodem do stavu "Vyzvednuto".
Vytvoření šablony protokolu o opravě
Pro tisk protokolu o opravě bude použit obecný tisk procesu využívající uživatelsky definovanou šablonu s proměnnými. Šablony dokumentů je možné vytvářet a spravovat v modulu , Pro potřeby protokolu opravy bude vytvořena nová šablona typu “Servisní proces”, její podoba pak může vypadat například takto:
Práce se systémem
Po úpravách systému a zaškolení personálu přijde na pobočku první nový zákazník s porouchaným mixérem. Asistentka ho přijme do opravy a založí nový proces.
Současně se založením procesu se naplánoval úkol na servisního technika pro opravu, díky tomu se mu objeví v seznamu “Moje procesy”. Servisní technik svůj seznam pravidelně kontroluje, když se mu nový proces zobrazí, dojde pro spotřebič,
přečte si popis závady a začne jí opravovat.
Asistentka poté přijme další spotřebič do opravy, zákazník přinesl vrtačku s poškozeným přívodním kabelem. Opět byl založen proces a vytvořen úkol na servisního technika.
Servisní technik tak má v tabulce “Moje procesy” dva procesy, seřazené jsou dle data vytvoření tak, aby nejstarší proces byl zobrazen jako první a technik na něm začal pracovat jako první.
Technik opraví první spotřebič, mixér. Otevře proces, napíše popis opravy a posune jej do dalšího stavu “Zatelefonovat”.
Posunutím procesu do dalšího stavu došlo k dokončení úkolu technika a zároveň k automatickému naplánování úkolu pro asistentku. Té se nyní proces objeví v tabulce “Moje procesy” a bude tak vědět, že je třeba zavolat zákazníkovi
a informovat jej o možnosti vyzvednutí.
Asistentka zavolá zákazníkovi, ten ale hovor nepřijímá. V tomto případě se nebude s procesem provádět žádná změna, systém nebude nijak evidovat neúspěšné pokusy o kontaktování zákazníka.
Jakmile se asistentka dovolá a informuje zákazníka o možnosti vyzvednout spotřebič, posune proces do stavu “K vyzvednutí”
Přesunem do stavu “K vyzvednutí” se vytvoří další úkol pro asistentku, aby předala opravený spotřebič zákazníkovi. Asistentka tedy proces stále vidí v tabulce "Moje procesy".
Když se zákazník dostaví, bude třeba mu nejprve vytisknout protokol o opravě. Asistentka vyhledá daný proces v tabulce “Moje procesy” a spustí akci “Tisk Procesu”. Vybrána bude jediná existující šablona protokolu o opravě:
Akce tisk procesu je dostupná pouze s právem MAINTENANCE_LIST.PRINT.
Asistentka předá zákazníkovi protokol a spotřebič, proces přesunem do posledního stavu dokončí.
Příklad 3, podmíněné přechody
Úvod
Třetí příklad už nebude navazovat na příklady předchozí. Cílem je si pouze ukázat použití podmíněných přechodů.Popis situace z praxe
Přechody mohou být podmíněny na základě nastavení parametru, stavu procesu, vlastností zákazníka nebo provozovny. Následující příklad využívá nastavení parametru. Představte si auto-moto servis nejlépe z velkého města, kde denně zajistí opravy mnoha automobilů a motocyklů a tudíž má smysl zavést procesní řízení. Pro opravy je často potřeba objednávat náhradní díly. Postup objednávky se pro automobily a motocykly liší. Pro naše účely si vytvoříme jednoduchý diagram skládající se ze stavu příjmu opravy, diagnostiky a následného objednání náhradního dílu. Budeme vždy uvažovat, že se příjme stroj do opravy, zjistí se problém a provede objednání dílu. Situace nereálná, ale pro naše účely postačující. Objednání dílů se v případě automobilu liší od motocyklu, budeme tedy na začátku procesu, v okamžiku příjmu stroje nastavovat o jaký stroj se jedná. K tomu použijeme jednoduchý parametr. Jakmile mechanik provede diagnostiku a požádá o objednávku dílu kolegu, systém automaticky nastaví objednávkový formulář vztahující se ke konkrétnimu stroji a to na základě toho jaký stroj nám zadavatel procesu nastavil. Vyřešíme tím situaci, kdy by se díl objednal chybně.Implementace
Diagram stavů a přechodů
Pro proces vytvoříme parametr "Typ opravy" s hodnotami automobil/motocykl, který bude vždy viditelný.
Pro přechod mezi stavy "Diagnostika" -> "Objednání dílů automobil" nastavíme závislost na parametru "Typ opravy" tak, že tento přechod se bude zobrazovat pouze pokud bude parametr nastavený na hodnotu automobil.
Stejným způsobem nastavíme závislost pro přechod "Diagnostika" -> "Objednání dílů motorka", který se bude zobrazovat pouze pokud bude parametr nastavený na hodnotu motorka.
Osoba na příjmu při vytváření procesu nastaví typ opravy, zapíše info s problémem od zákazníka (parametr pro zapsání informací od zákazníka není na obrázcích znázorněn) a předá mechanikovi k diagnostice.
Mechanik po provedení diagnostiky zapíše co je potřeba objednat (parametr pro zapsání informací není na obrázcích znázorněn) a předá kolegovi, který má na starosti objednávání.
Předání kolegovi proběhne přechodem, který už bude automaticky nastaven podle toho jaký stroj se diagnostikuje.
Standardně by proces pokračoval dále objednávkovým formulářem. To už není v příkladu řešeno. Nabízené přechody se neaktualizují okamžitě po změně parametru, ale při uložení procesu. V našem příkladu
jsme parametr nastavili na začátku procesu (ve stavu "Nahlášení"), než jsme se dostali do stavu "Diagnostiky" ve kterém se již musí projevit podmíněné přechody, byl proveden přechod a tím došlo k uložení procesu.
Příklad 4, Nastavení eskalací-SLA
Úvod
Nenavazuje na předchozí příklady. Cílem je si ukázat různá použití upozorňování pomocí SLA.Popis situace z praxe
Představte si obchodní oddělení nějaké firmy, která pro své zákazníky tvoří nabídky na základě jejich poptávky. Na začátku pošle zákazník emailem poptávku. Uvažujme, že poptávky budou zasílány pouze emailem, nebudou nahlašovány jiným kanálem. Obchodník se na ni podívá a vytvoří nabídku, případně si se zákazníkem upřesní detaily. Opět budeme uvažovat, že pouze emailem. Vytvořenou nabídku zašle zpět zákazníkovi a tím proces končí. Proces velmi jednoduchý, ale pro naše účely dostačující. Na takhle jednoduchém scénáři si ukážeme několik způsobů použití SLA.
Implementace 1
Obchodník bude potřebovat od zákazníka upřesnit zaslanou poptávku. Zákazníkovi pošle email s dotazem a dokud zákazník neodpoví, předá proces do stavu "Čekám na upřesnění". Pro tento stav si nastavíme upozornění, že pokud zákazník do 4 dnů nezareaguje tak chceme, aby nám u tohoto procesu svítil alert s porušeným SLA což bude pro obchodníka impulz, že s procesem není něco v pořádku. Dala by se samořejmě nastavit i akce třeba na založení úkolu pro obchodníka atd.. V našem příkladu se bez akcí obejdeme, postačí nám zobrazení ikony varování nebo alertu v seznamu procesů.
Jakmile obchodník přesune proces do stavu "Čekám na upřesnění", systém začne počítat čas, jak dlouho je proces v tomto stavu, od vstupu do tohoto stavu. Jakmile to budou 3dny, nastaví se u procesu varování, jakmile dosáhne 4 dnů, nastaví se porušení.
Varování a porušení procesu lze spatřit v tabulce se seznamem procesů.
Implementace 2
Celý proces chceme mít dokončen za maximálně 7 pracovních dní, soboty, neděle a svátky nejsou započítány. Jako kontrolovaný stav tedy nastavíme "Konec" a tentokrát budeme hlídat dobu za kterou by měl proces dosáhnout kontrolovaného stavu. Měřit budeme od nahlášení procesu, nikoli od vstupu do stavu jako v prvním příkladu. Pokud proces nebude dokončen do 6 dnů, u procesu se zobrazí varování, při nedokončení do 7 dnů pak porušení.
Zpět na:
Edit | Attach | Print version | History: r10 < r9 < r8 < r7 | Backlinks | View wiki text | Edit wiki text | More topic actions
Topic revision: r10 - 04 Sep 2019, UnknownUser
Main
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding Foswiki? Send feedback