EVROPSKÁ UNIE Evropské strukturální a investiční fondy Operační program Výzkum, vývoj a vzdělávání M I N I S T E R S T V O Š K O L S T V Í , M L A D E 2 E A TĚLOVÝCHOVY Název projektu Rozvoj vzdělávání na Slezské univerzitě v Opavě Registrační číslo projektu CZ.02.2.69/0.0./0.0/16_015/0002400 Techniky a nástroje v oblasti řízení podnikových procesů Distanční studijní text Roman Sperka, Michal Halaška, Dalibor Simek Karviná 2018 SLEZSKA U N I V E R Z I T A OBCHODNĚ PODNIKATELSKÁ FAKULTA V KARVINÉ Obor: Klíčová slova: Anotace: Podniková informatika, aplikovaná informatika, podniková ekonomika, management. Podnikový proces, management, BPM, řízení, process mining, zlepšování, simulace, Bizagi, Disco, ProM. Hlavním cílem výukového textuje představit využití základních technik, metod a nástrojů z oblasti řízení procesů se zaměřením na procesy probíhající v podnicích (nebo alternativně ve firmách, společnostech a organizacích). Tento text je vhodný jako distanční opora ve výuce předmětů na vysokých školách s důrazem na řízení podnikových procesů (BPM Business Process Management), zejména v oblasti průběhu podnikových procesů, jejich simulací a analýzy reálných podnikových dat. Technickou náročností je určena zejména aplikovaným informatickým oborům studia. Předmětem zájmu výukového textuje analýza podnikových procesů, která je základem pro pochopení konkrétní podnikové domény s cílem nalézt slabé místa v procesech a na-vrhnout jejich zlepšení. V prvních kapitolách autoři představují teoretické východiska pro pojmy, jako jsou podnikový proces, řízení a životní cyklus podnikových procesů. Následně bude prezentována notace BPMN, jednotlivé fáze životního cyklu BPM a detailní popis process miningu. Závěr opory tvoří popis softwarových nástrojů (Bizagi, Disco a ProM) a případové studie z oblasti B P M a process miningu. Celý text je proložen množstvím praktických pří­ kladů. Autoři: Doc. RNDr. Ing. Roman Sperka, Ph.D. Ing. et Ing. Michal Halaška v Ing. Dalibor Simek Recenzenti: Prof. Ing. Miroslav Hučka, CSc. Doc. Mgr. Petr Suchánek, Ph.D. ISBN 978-80-7510-312-3 @ 0 @ Toto dílo podléhá licenci: Creative Commons Uveďte původ-Zachovejte licenci 4.0 Znění licence dostupné na: http://creativecommons.Org/licenses/by-sa/4.0 Roman Šperka, Michal Halaška, Dalibor Šimek - Techniky a nástroje v oblasti řízení podnikových procesu Obsah ÚVODEM 6 RYCHLÝ NÁHLED STUDIJNÍ OPORY 7 1 ZÁKLADNÍ POJMY Z OBLASTI PROCESNÍHO ŘÍZENÍ 8 1.1 Podnikový proces 11 1.2 Typy podnikových procesů 18 1.3 Workflow 21 1.3.1 Automatické provedení podnikového procesu 21 1.3.2 Typy Workflow systémů 23 1.4 Metody pro modelování podnikových procesů 25 2 MODELOVÁNÍ A SIMULACE 30 2.1 Systém 30 2.2 Model 32 2.3 Modelování 34 2.4 Klasifikace modelů 35 2.5 Simulace 36 3 BUSINESS PROCESS MODELING NOTATION (BPMN) 41 3.1 Business Process Diagram (BPD) 42 3.1.1 Symboly používané v BPMN 43 3.2 Využití BPMN 48 4 ŘÍZENÍ PODNIKOVÝCH PROCESŮ (BPM) 51 4.1 Příklady podnikových procesů 51 4.2 Životní cyklus B P M 52 4.3 Identifikace procesů 57 4.3.1 Označovací etapa 57 4.3.2 Vyhodnocovací etapa 58 4.3.3 Procesní architektura 59 4.4 Objevování procesů 61 4.4.1 Obj evování založené na důkazech 62 4.4.2 Objevování založené na rozhovorech 62 4.4.3 Obj evování založené na workshopech 63 3 Roman Šperka, Michal Halaška, Dalibor Šimek - Techniky a nástroje v oblasti řízení podnikových procesií 4.5 Analýza procesů 63 4.5.1 Kvalitativní analýza procesů 63 4.5.2 Kvantitativní analýza procesů 65 4.6 Redesign procesů 66 4.7 Implementace a monitorování procesů 67 5 PŘÍPADOVÁ STUDIE BIZAGI 71 5.1 Představení Bizagi Suite 72 5.1.1 Bizagi a j eho zastoupení v životním cyklu B P M 74 5.2 Identifikace procesů 75 5.2.1 Situační analýza ukázkové firmy z pohledu procesní vyspělosti 76 5.2.2 Tvorba procesní architektury v ukázkové firmě 77 5.2.3 Prioritizace procesů 79 5.3 Obj evování procesů v ukázkové firmě 81 5.3.1 Analýza dokumentů 82 5.3.2 Pozorování procesních účastníků 83 5.3.3 Rozhovory s doménovými experty 84 5.3.4 Popis a model procesu zpracování závazků 84 5.4 Analýza procesu zpracování závazků 85 5.4.1 Kvalitativní analýza ukázkového procesu 86 5.4.2 Kvantitativní analýza ukázkového procesu 89 5.5 Implementace procesu zpracování závazků 94 5.5.1 Data model 95 5.5.2 Tvorba formulářů 96 5.5.3 Obchodní pravidla 96 5.5.4 Uživatelé 97 5.5.5 Integrace 98 5.5.6 Exekuce procesu a pracovní portál 99 5.6 Monitorování a kontrola ukázkového procesu 99 6 PROCESS MINING 105 6.1 Podstata a základní pojmy process miningu 106 6.2 Data potřebná pro process mining 110 6.2.1 Záznamy 112 6.3 Procesní modely 117 4 Roman Šperka, Michal Halaška, Dalibor Šimek - Techniky a nástroje v oblasti řízení podnikových procesu 6.3.1 Přechodový systém 117 6.3.2 Petrihosítč 118 6.4 Obj evování podnikových procesů 121 6.4.1 Alfa-algoritmus 124 6.4.2 Pokročí1é metody obj evování 131 6.5 Zjišťování shodnosti modelů procesů 132 6.6 Další perspektivy process miningu 141 6.6.1 Organizační perspektiva 141 6.6.2 Časová a pravděpodobnostní perspektiva 142 7 PŘÍPADOVÁ STUDIE DISCO 144 7.1 XES 144 7.2 Instalace softwarového produktu Disco 146 7.3 Analýza procesů v Disco 148 8 PŘÍPADOVÁ STUDIE PROM 162 8.1 Instalace softwaru ProM 163 8.2 Analýza procesů v ProM 165 LITERATURA 183 SHRNUTÍ STUDIJNÍ OPORY 186 PŘEHLED DOSTUPNÝCH IKON 187 5 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu ÚVODEM Studijní opora „Techniky a nástroje v oblasti řízení podnikových procesu" je určena studentům, kteří se zajímají o problematiku řízení podnikových procesů (angl. BPM, Business Process Management). Technickou náročností je zaměřena na aplikované informatické obory studia na vysokých školách. Student nemusí mít žádné speciální znalosti z předchozího studia, ale orientace v základech modelování, simulací, logice a technologii informačních systémů je vítaná. Student studiem opory získá následující dovednosti - bude umět přemýšlet procesně ve smyslu podnikové struktury; identifikovat, objevovat, analyzovat a navrhovat zlepšení podnikových procesů; provádět detailní analýzy podnikových dat s důrazem na identifikaci slabých míst podnikových procesů. Text je strukturován do 8 kapitol. Každá kapitola začíná stručným seznámením s jejím obsahem v rychlém náhledu kapitoly, dále obsahuje stručné cíle a klíčová slova. V samotném textu se vyskytují distanční prvky, které Vás upozorní na důležité definice, na texty pro zájemce, k zapamatování a případové studie. Distanční prvky samostatný úkol a úkol k zamyšlení budou řešeny v rámci prezenční výuky, takže si jejich řešení připravte dopředu. Každá kapitola končí kontrolními otázkami, krátkým shrnutím a odpověďmi na otázky. 6 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu RYCHLÝ NÁHLED STUDIJNÍ OPORY Studijní opora „Techniky a nástroje v oblasti řízení podnikových procesu" obsahuje komplexní a hloubkové představení problematiky identifikace, objevování, analýzy, redesignu a implementace podnikových procesu v podnicích, ve kterých je kladen důraz na procesní řízení, nebo které o procesním řízení uvažují. Opora začíná představením základních teoretických pojmů z oblasti procesního řízení, modelování a simulací podnikových procesů, objasněním použití notace BPMN (Business Process Modeling Notation) a životním cyklem řízení podnikových procesů. V druhé části textu je kladen důraz na představení softwarových nástrojů, které se v této oblasti využívají a na detailní a praktické případové studie, které nabízejí studentům si proces řízení podnikových procesů vyzkoušet. 7 ZÁKLADNÍ POJMY Z OBLASTI PROCESNÍHO ŘÍZENÍ 1 ZÁKLADNÍ POJMY Z OBLASTI PROCESNÍHO ŘÍZENÍ RYCHLÝ NÁHLED KAPITOLY V této kapitole se seznámíte se základní definici podnikového procesu, představíme si jeho strukturu a charakterizujeme pohled na funkční a procesní řízení podniku. Na metamodelu podnikového procesuj sou znázorněny základní prvky a účastníci podnikového procesu. Na objasnění praktického náhledu na provedení podnikového procesu použijeme model procesu objednávky pomocí notace BPMN. Následně si vysvětlíme rozdíl mezi modelem a jeho instancí procesu a definujeme pojem workflow. Neopomeneme ani základní členění podnikových procesů a objasníme podstatu hodnotového řetězce podle Portera. Kapitola v závěru představuje základní metody popisu podnikových procesů a grafických notací, které se používají při modelování podnikových procesů. CÍLE KAPITOLY Po prostudování této kapitoly budete umět: • Vysvětlit rozdíl mezi funkčním a procesním řízení podniku. • Definovat podnikový proces, vyjmenovat a charakterizovat základní členění podnikových procesů v souladu s podnikovými aktivitami. • Objasnit rozdíl mezi modelem procesu a instancí procesu. • Definovat pojem workflow podnikového procesu a jeho základní druhy. • Popsat metody popisu a grafické notace procesních modelů. KLÍČOVÁ SLOVA KAPITOLY Procesní a funkční řízení, podnikový proces, rozhodovací procesy, podpůrné procesy, instance, model, modelování, workflow, notace podnikových procesů. Současné koncepce managementu zdůrazňují několik významných charakteristik, které mají podstatní vliv na fungování dnešních podniků a organizací - (1) využívaní informačních technologií (IT) a podnikových informačních systémů, (2) významná úloha lidského faktoru, vedení lidí (leadership), učící se organizace a týmová práce, (3) zdůraznění nutnosti procesní orientace podniků. Procesní přístup se v posledním období stal standardem 8 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu v podnikovém managementu. Můžeme ho rozčlenit do více etap, v kterých byly identifikovány především výrobní procesy jako nezbytný předpoklad finální kvality výrobků a proto byla hlavní pozornost podniků věnována právě jim. Na druhé straně administrativní procesy byly charakteristické funkčním přístupem, který se datuje do prvních desetiletí minulého století. V tom čase Henry Ford aplikoval principy dělby práce, které definoval dříve Adam Smith na výrobní proces automobilů a rozdělil pracovní činnosti na menší části, které umožňovaly pracovníkům se specializovat na určité činnosti a tím dosáhnout lepší produktivity. Tím na druhé straně narůstaly požadavky na vedení lidí a jejich koordinaci. Tento problém vyřešil A. Sloan, který aplikoval princip dělby práce na management podobným způsobem jako na výrobní procesy. Tím se manažeři středního řízení firmy začali specializovat na určité funkce podniku (např. výroba, prodej, logistika, apod.) a top manažeři řídili firmu na základě finančních ukazatelů hospodaření podniku. Takovýto funkční přístup byl typický pro období hromadné výroby hlavně v poválečném období, ale posléze došlo k výrazným ekonomickým změnám, které začaly funkční přístup odsouvat na vedlejší kolej. Těmito důvody byli především boje výrobců o zákazníka na globalizovaném trhu a role zákazníků v ekonomice, kteří se stali určujícími činiteli, co mají firmy vyrábět na základě jejich preferencí. Za prvního autora procesního přístupu k řízení organizací se dá označit Michael Porter, který ve své práci o analýze konkurenceschopnosti podniků navrhnul hodnotový řetězec (více kapitola 1.2). Základním principem jeho přístupu byl fakt, že nezobrazoval podnik jako pyramidovou strukturu řízení, ale jako řetězec, ve kterém firma generuje marži a přispívá ke kladnému finančnímu výsledku celé firmy. V 80. letech minulého století zaznamenali víceré americké firmy jako např. IBM, Xerox nebo Ford prudkého zlepšení produktivity a to na základě radikálních změn svých procesů především s využitím IT a stali se příkladem pro zbytek světa. Postupně se začala uplatňovat myšlenka, že je lepší, když se procesy mění postupně, ne skokově a to především s ohledem na setrvačnost myšlení a chování lidí. Významným faktorem, který ovlivňuje konkurenceschopnost podniků v současném turbulentním prostředí, které je charakteristické konkurencí na globálních trzích a využívaním informací v rozhodovacím procesu, je hlavně schopnost řízení změn napříč celým podnikem (firmou). Tyto změny, které jsou způsobeny dynamikou a proměnami podnikatelského prostředí, jsou iniciovány požadavky na inovace a zaváděním nových služeb a produktů na globální trh. Významnou úlohu hraje taky radikální reengineering nebo automatizace stávajících procesů, aktivit a pracovních postupů v podniku, firmě nebo organizaci. Pro zajištění kontinuální správy těchto změn a samotné řízení podniků je nutné radikálně změnit úhel pohledu na vnímání podniku jako celku. Výsledkem je procesní pohled, který každou firmu, nebo podnik vnímá jako soubor obchodních, výrobních, administrativních nebo sumárně podnikových procesů. Podnikové procesy překračují jednotlivá oddělení ve firmě a dodávají své výstupy zákazníkovi - jak externímu (koncovému), tak internímu. 9 ZÁKLADNÍ POJMY Z OBLASTI PROCESNÍHO ŘÍZENÍ K ZAPAMATOVÁNÍ Reengineering znamená zásadní přehodnocení a radikální redesign (rekonstrukci) podnikových procesů tak, aby mohlo být dosaženo dramatického zdokonalení z hlediska kritických měřítek výkonnosti, jako jsou náklady, kvalita, služby a rychlost. Jedná se tedy o zavádění radikálních, především organizačních změn v podniku. Přechod firem z klasického funkčního (úkolového) řízení a pohledu na základě organizační struktury k procesnímu pohledu, kde jsou jednotlivé podnikové procesy spjaté se strategickými cíli organizací a plně vyhodnocované a sledované na základě stanovených metrik, vyžaduje odborníky s procesním pohledem a kvalifikací, které umožňuje tento přechod provést.1 DEFINICE Podle Evropské komise2 se podnikem rozumí každý subjekt vykonávající hospodářskou činnost, bez ohledu na jeho právní formu. K těmto subjektům patří zejména osoby samostatně výdělečně činné a rodinné podniky vykonávající řemeslné či jiné činnosti a obchodní společnosti nebo sdružení, která běžně vykonávají hospodářskou činnost. Obchodní zákoník3 (§5) ho definuje jako soubor hmotných, jakož i osobních a nehmotných složek podnikání. K podniku náleží věci, práva a jiné majetkové hodnoty, které patří podnikateli a slouží k provozování podniku nebo vzhledem ke své povaze mají tomuto účelu sloužit. Podnik je podle Kislingerové (1999) tedy funkčním celkem - entitou, která je nadána schopností přinášet určitý užitek, generovat určitý výnos v současnosti i budoucnosti. 1 PEKÁRKOVÁ, Lucie. Techniky modelování a optimalizace podnikových procesů. Brno, 2007. Diplomová práce. Masarykova univerzita, Fakulta informatiky. 2 NAŘÍZENÍ KOMISE (ES) č. 800/2008 ze dne 6. srpna 2008. Lex.europa.eu [online]. Evropská komise, 2008 [cit. 2017-09-30]. Dostupné z: http://eur-lex.europa.eu/LexUriServ/LexUri- Serv.do?uri=OJ:L:2008:214:0003:0047:cs:PDF 3 Zákoně. 513/1991 Sb., obchodní zákoník [online]. Businesscenter.cz, 2017 [cit. 2017-09-30]. Dostupné z: https://business.center.cz/business/pravo/zakony/obchzak/castl.aspx 10 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu 1.1 Podnikový proces Pro uskutečnění aktivit, které mají za cíl pochopit procesní náhled na podnik, firmu nebo organizaci je nutné vytvořit abstrakci procesu tak, aby umožňovala znázornit všechny aktivity, které v podnikovém procesu probíhají. Pozornost je věnována také vztahům mezi různými aktivitami, lidem v rozličných rolích a zařízením, které do podnikového procesu nějakým způsobem zasahují. Níže si zmíněné pojmy vysvětlíme podrobněji. Klíčový pojem v moderní teorii managementu (řízení) podniku představuje podnikový proces {business proces). V literatuře nalezneme různé definice. Každá z nich zdůrazňuje jiné aspekty podnikového procesu, přesto je však možné vysledovat některé společné vlast­ nosti. DEFINICE Podle Řepy (2006) je podnikový proces chápán jako souhrn činností přeměňující za pomoci lidí a dalších nástrojů vstupy na určité výstupy, které mají hodnotu pro zákazníky nebo jiné procesy. Podnikový proces Vlastnosti procesu Každý proces má tedy několik základních atributů. Z výše uvedené definice vyplývá, že proces využívá zdroje, transformuje vstupy na výstupy a skládá se z uspořádaných činností (kroků). Taktéž je možné jej dekomponovat na aktivity a subprocesy. Dále můžeme proces specifikovat jeho jednoznačným začátkem a koncem, včetně návazností na jiné procesy a opakovatelností. Navíc bychom mohli odvodit, že proces je spouštěn určitým signálem. Každý proces má své parametry, které můžeme měřit (např. kvalita, včasnost, průběžná doba, časová délka, náklady, apod.). Funkčnost procesů závisí na posloupnosti jednotlivých kroků (procedurách) a zdrojích. Každý proces má interní nebo externí vstupy či dodavatele a zároveň zákazníky a také má svého vlastníka. Vlastníkem procesu je pro každý proces právě jedna osoba. Táto osoba je odpovědná za způsob provádění procesu (jeho nastavení), tzn. za jednotlivé jeho aktivity a za dodržování stanovených postupů. Vstupem procesu se rozumí objekt, resp. jeho stav před působením předmětného procesu. Ten se stává předmětem působení procesu. Může to být např. příkaz či plán, poptávka, přijatá faktura nebo polotovar, atd. Výstupem procesuje objekt, resp. jeho stav po působení tohoto procesu. Může to být např. hotový výrobek, uhrazená faktura, vrácená faktura, vyškolený pracovník nebo vyskladnený materiál, apod.). Definice procesu je jeho reprezentace ve formě, která umožňuje jeho automatizované zpracování. Automatizovaným zpracováním je například jeho spuštění pomocí Workflow Management Systému (WfMS), nebo vytvoření modelu a jeho simulace (více o workflow naleznete v kapitole 1.3). Definice procesu obsahuje hlavně informace o kritériích zahájení procesu, přerušení a ukončení činnosti, sítí činností a jejich vztahů, aplikacích a datech 11 ZÁKLADNÍ POJMY Z OBLASTI PROCESNÍHO ŘÍZENÍ nebo o údajích o účastnících. Definice procesu pro účely WfMS obvykle tvoří souhrnný popis různých objektů (entit): Proces (popis celého procesu) Činnost (definice činností, z nichž se proces skládá) Účastník (seznam/deklarace účastníků procesu) Přechod (definice přechodů mezi činnostmi) Data (deklarace dat procesu) Aplikace (deklarace aplikací používaných procesem) Vzájemné vztahy entit znázorňuje tzv. metamodel procesu (obr. 1-1). | V I K ZAPAMATOVÁNÍ Workflow Management System je softwarový systém pro nastavení, spouštění a monitorování definované sekvence úkolů, které označujeme jako workflow. Prote^ i s : Data \ skládá-srz -| uživá |- U7iva vykonávaná Účastník Činnost vol.i Aplikace ~~J «=F _ l ± .1 to Přechod TTf Obrázek 1-1: Metamodel procesu. Zdroj: http://is.muni.cz/th/60555/fi_m/DP-pekarkova.pdf Podnikový proces se provádí za účelem splnění určitého podnikového cíle (business goal). Jeho provedení je časově ohraničeno, přičemž pro jeho zahájení platí vstupní podmínky. Ukončení procesuje charakterizováno dosažením určitých koncových podmínek. Jednotlivé činnosti (aktivity), které probíhají v rámci procesu, jsou vzájemně provázány. 12 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesii Aalst (2004, s. 33) ve své práci uvádí, že proces popisuje úlohy, které musí být uskutečněny a také specifikuje pořadí, v jakém mají být provedeny. Aktivity, které realizují příslušné úlohy, nemohou být řazeny libovolně. Jsou vždy uspořádány do určité posloupnosti tak, aby bylo dosaženo požadovaného podnikového cíle. K ZAPAMATOVÁNÍ Aktivita tvoří jeden logický atomický krok v procesu, kterého část popisuje. Aktivita může být manuální, tedy taková, která nevyžaduje počítačovou podporu, nebo automatizovaná (workflow). Workflow aktivita vyžaduje lidské a/nebo technické zdroje k pokračování vykonávání procesu (nejčastěji IT). Automatizovaná aktivita v průběhu podnikového procesu, kterého je součástí, je schopna být automaticky uskutečňována pomoci WfMS Manuální aktivitu naopak není možno automatizovat, proto pod WfMS nespadá. Každá aktivita se začne vykonávat pouze tehdy, pokud j sou splněna všechna omezení pro její provádění (execution constraints). Libovolná operace, která se v rámci podniku provádí, může být popsána jako proces. Podnikový proces představuje např. vyřízení objednávky od zákazníka, zajištění aktualizace aplikace u klientů, ale také například vývoj samotného produktu. Podnikové procesy interagují s jiným procesy. Jejich vzájemný kontakt přitom není omezen pouze na procesy v rámci firmy, která je ustanovuje, ale velmi často dochází také k interakci mezi procesy různých podniků {business-to-business proces- ses). K ZAPAMATOVÁNÍ Soubor vzájemně se doplňujících dovedností je role. Role jsou přiřazovány k jednotlivým aktivitám. Cílem rolí je umožnit jejich plnění v rámci vykonávání procesu. Role reprezentuje skupinu zdrojů. Zdroj je prostředek nebo jejich skupina, které jsou nutné k vykonání aktivity. Zdroje mohou být lidské (pracovníci) anebo technické (zařízení, stroje, systémy, apod.). Zdrojem mohou být například výrobní prostředek, informace, vykonavatel aktivity, další vykonavatel nebo jiný proces. Vykonavatel procesu je ten, kdo provádí aktivity spojené s procesem. Vykonavatel musí být při analýze a popisu procesu jednoznačně identifikován na různých hladinách konkrétnosti a pro různé účely. Role tedy definují zodpovědnost, kompetenci a chování jednotlivých osob nebo skupiny osob, které spolupracují. Jednotlivé lidské zdroje jsou mapovány na požadované role podle toho, jak jsou požadované kompetence slučitelné se schopnostmi těchto osob. 13 ZÁKLADNÍ POJMY Z OBLASTI PROCESNÍHO ŘÍZENÍ Nyní si představíme jednoduchý příklad procesu, který zachycuje proces přijetí objednávky ve firmě. Podnikový proces je složený z následujících činností: Přijetí objednávky od zákazníka, analýza objednávky, poslání zprávy o zamítnutí objednávky, odeslání zprávy o přijmutí objednávky, odeslání objednávky do oddělení objednávek, uzavření procesu přijetí objednávky. Výše uvedený textový popis podnikového procesu pomocí aktivit, které je nutné provést, není úplný. Podle definice podnikového procesu výše musí být stanoveno také pořadí, v jakém budou jednotlivé aktivity uskutečněny. K zachycení vazeb mezi aktivitami se v modelování používá grafické notace4 . Podnikový proces přijetí objednávky je znázorněn na obr. 1-2. Proces začíná obdržením e-mailové zprávy s konkrétní objednávkou zboží. Není nezbytně nutné přesně specifikovat formu zprávy, resp. samotné objednávky. Forma může být slovní, nebo písemná ve formě firemního formuláře, který používá firma pro objednávky svých zákazníků. V ideálním 0 Příklad při případě to muže být datový obj ekt, například datového typu XML, který j e výstupem účet- yeřl- objeď ního systému zákazníka a podnikový informační systém (např. MS Dynamics) je schopen n á v t y ho přijmout a poslat ke zpracování. V dalším kroku musí proběhnout ověření objednávky a pracovník firmy musí posoudit, jestli došlá objednávka splňuje všechny požadavky ke zpracování, nebo zdali je zboží k dispozici, apod. Dále mohou nastat dvě situace - (1) objednávka z nějakého konkrétního důvodu není pracovníkem firmy přijata a zákazníkovi je poslána zpráva, která popisující zdůvodnění odmítnutí jeho objednávky, nebo (2) objednávka splňuje podmínky pro vyřízení a firma zašle zákazníkovi potvrzení přijetí objednávky a taky odešle tuto objednávku do oddělení objednávek k dalšímu zpracování. Objednávka se odešle formou zprávy „Message" a příslušného datového objektu „Objednávka číslo". Objednávkový proces je nakonec uzavřen přijetím objednávky. Grafická notace, která byla použita pro návrh modelu objednávkového procesu, se nazývá Business Process Modeling Notation (zkratka BPMN). Obdélníky v procesních modelech této notace znázorňují jednotlivé aktivity. Orientované šipky pak označují vzájemné vztahy aktivit. Aktivita, u které šipka začíná, musí předcházet aktivitě, do které šipka směřuje. Speciální symbol ve tvaru diamantu se využívá pro znázornění větvení procesu a následného spojení jednotlivých větví. Diamant obsahuje písemný znak, který indikuje, jakým způsobem se proces rozdělí. Ve vzorovém procesu jsme potřebovali vyjádřit alternativu - má se provést pouze jedna vybraná větev znamenající (1) přijetí, nebo (2) nepřijetí 4 Pojem notace označuje formální prostředky pro zápis skutečnosti, nejčastěji ve formě grafické. 14 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu objednávky. Pro tento účel se používá diamant se znakem X. Bez ohledu na výsledek je nutné nakonec provést aktivitu uzavření objednávkového procesu. Proto se v grafickém zápisu procesu obě větve opět spojí pomocí symbolu diamantu se znakem X. Ten vyjadřuje ukončení větvení. Podrobněji se notaci BPMN budeme věnovat v kapitole 4. Objednávka zboží e-mailem Proces přijetí objednávky Přijetí <- Analýza objednávky objednávky Zpráva o zamítnutí objednávky Zpráva o přijetí objednávky Odesl odděl objed 0 U zavřen í procesu přijetí objednávky > > U zavřen í procesu přijetí objednávky slaní ěleni L J návek ávka číslo Procesní model a in­ stance Obrázek 1-2: Objednávkový proces. Zdroj: vlastní zpracování Další typický podnikový proces, který se realizuje v každé firmě, která prodává zboží je reklamační proces. Metoda, znázorněná na obr. 1-2 a popsaná v textu výše se dá úspěšně použít pro popis toho, jakým způsobem se má provádět libovolná reklamace, kterou musí nějaká firma uspokojit. Tato metoda představuje tzv. šablonu, která popisuje průběh práce v procesu vyřizování reklamace, nebo objednávek, atd. Tato šablona se nazývá model procesu nebo procesní model. Konkrétní případ reklamace uskutečněný podle procesního modelu potom nazýváme instanci procesu. Podobným způsobem můžeme uvažovat o jednotlivé aktivitě, která je prováděná v rámci libovolného procesu. Na úrovni procesního modelu je aktivita popsána modelem aktivity a její konkrétní provedení potom představuje instanci této aktivity. Podnikové procesy představují důležitý koncept, který pomáhá vedení podniku pochopit, jakým způsobem jejich podnik funguje. Definice procesů navíc nepředepisuje, jaké implementační strategie nebo platformy budou použity (Weske, 2007, s. 10). Aktivity jsou popisovány abstraktně. Díky tomuto přistupuje možné docílit lepší integrace informačních systémů (IS), které podnik používá k provedení činností v rámci podnikového procesu. Zaměřme se nyní na základní stavební prvky každého procesu, na aktivity. Aktivita představuje logickou jednotku práce, kterou můžeme popsatjako atomický proces. Aktivita je tedy buď provedena celá, anebo není provedena vůbec. Výrok o nedělitelnosti aktivity je však relativní. Pokud budeme vytvářet např. model výroby určitého produktu, můžeme ho definovat pomocí jediné aktivity „výroba produktu". Tato aktivita ale bude ve skutečnosti tvořena poměrně komplexním subprocesem, který obsahuje řadu dalších aktivit. Záleží tedy na zvolené míře abstrakce procesního modelu s ohledem na jeho velikost a srozumitelnost. Weske (2007) uvádí ještě další pojmy, které jsou spojené s aktivitou. Jedná se o úkol (task) a pracovní položku iwork item). Jejich vzájemný znázorňuje obr. 1-3. 15 ZÁKLADNÍ POJMY Z OBLASTI PROCESNÍHO ŘÍZENÍ Obrázek 1-3: Úkol, pracovní položka, aktivita a případ. Zdroj: vlastní zpracování Úkol odpovídá dříve definovanému pojmu model aktivity. Pracovní položka představuje úkol, který je specifikovaný pro určitý případ, tzn., jedná se o instanci aktivity. Samotná aktivita je podle Weskeho (2007) realizace pracovní položky vybraným zdrojem. V tomto textu se však budeme zabývat jenom modelováním procesů, a proto budeme používat pouze pojmy model aktivity a instance aktivity tak, jak byly vysvětleny výše. Aktivity v rámci procesu můžeme podle klasifikovat do tří skupin: 1. manuální aktivity, 2. systémové aktivity, 3. aktivity uživatelských interakcí. initialize enable begin terminate Aktivity skip Obrázek 1-4: Stavový diagram instance aktivity. Zdroj: Weske (2007, s. 86) Manuální aktivity mohou být vykonány pouze lidmi. S použitím IS se nepočítá. Zástupcem této skupiny aktivit je např. fyzické zaslání nové objednávky v rámci objednávkového procesu. Aktivity uživatelských interakcí realizují lidské zdroje. Pro jejich úspěšné dokončení je ovšem potřebná podpora IS. Jako příklad lze uvést uzavření objednávkového procesu, kdy pracovník firmy vloží do registru objednávek data, které popisují právě řešený 16 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu případ. Systémové aktivity obsahují aktivity, jejichž provedení je zajištěno pouze prostřednictvím IS. Příkladem takové aktivity by mohlo být automatické odeslání zprávy, která oznamuje přijetí nebo nepřijetí objednávky firmou. Nyní se budeme podrobněji věnovat modelování aktivity. Podle Weskeho (2007, s. 86) lze instanci aktivity popsat pomocí stavů, ve kterých se její uskutečnění nachází a příslušných přechodů mezi těmito stavy. Jednoduchý stavový diagram instance aktivity prezentuje obrázek 1-4. V momentě vyvolání aktivity (přechod „initialize") se její instance nachází ve stavu vyvolání („init"). Aby mohla být aktivita připravena k realizaci (stav „ready"), musí být nejdříve povolena přechodem „enable". V tomto stavuje aktivita stále považována za nezahájenou („not started"). Pokud v kontextu provádění procesu nepotřebujeme aktivitu uskutečnit, dojde k jejímu vynechání přechodem „skip" do stavu „vynechána" („skipped"). V opačném případě je aktivita započata přechodem „begin" a po dobu provádění setrvává ve stavu běhu („running"). Ukončení aktivity zajistí přechod „terminate" a aktivita přejde do ukončeného stavu („terminated"). Tento stav společně se stavem „přeskočeno" vyjadřuje, že aktivita je uzavřena („closed"). Obrázek 1-5: Událostní diagram provedené aktivity. Zdroj: Weske (2007, s. 86) Průchod aktivity j ednotlivými stavy je možné modelovat pomocí událostí. Událost vyjadřuje skutečnost, že došlo k přechodu z jednoho stavu instance aktivity do jiného. Uspořádáním událostí v čase potom můžeme zachytit průběh libovolné aktivity. Událost reprezentuje pojmenovaný okamžik. Tento okamžik je důležitý z pohledu vykonávání aktivity. Délka jeho trvání je nulová. Doba, během níž se aktivita nachází v určitém stavu, je definovaná časovým intervalem mezi uskutečněním dvou po sobě jdoucích událostí. Pořadí událostí vyjadřuje diagram událostí. Obr. 1-5 znázorňuje vztah diagramu událostí ke stavovému diagramu aktivity popsanému výše. Pro větší přehlednost j sou odděleny dva možné průběhy aktivity - úplně provedená aktivita (obr. 1-5) a vynechaná aktivita (obr. 1-6). 17 ZÁKLADNÍ POJMY Z OBLASTI PROCESNÍHO ŘÍZENÍ initialize skip Obrázek 1-6: Událostní diagram vynechané aktivity. Zdroj: Weske (2007, s. 86) V prvním případě můžeme průběh aktivity popsat pomocí čtyř událostí - vyvolání („initialize"), povolení („enable"), zahájení („begin") a ukončení („terminate"). Jakmile nastane událost vyvolání, aktivita přejde do stavu „init". V tomto stavu setrvává, dokud nedojde k události „povolení". Od tohoto momentu je aktivita připravena a k jejímu spuštění dochází s příchodem události „zahájení". Ukončení aktivity je potom vyjádřeno výskytem události „ukončení". Druhý případ je ještě jednodušší. Vyvolání je opět spojeno s událostí „vyvolání". Potom ovšem dojde k události „vynechání" („skip") a aktivita není provedena, což je reprezentováno příslušným stavem. 1.2 Typy podnikových procesů Procesní řízení se zaměřuje na opakované činnosti, které je možno separovat a následně popsat, tz. vytvořit a popsat pomocí procesního modelu. Pokud tedy nalezneme v podnikoProcesní vém procesu opakované řetězce činností (aktivit), mohli bychom vzbudit dojem, že se jedná n z e r " o primitivní řetězce aktivit, které j sou vykonávány rutinně, příp. naprogramovanými vykonavateli. To je ale falešný obraz, neboť hledání významných procesů v organizacích je vždy velmi obtížný úkol. Přestože máme řadu metodik a postupů, jedná se vždy o sofistikované řešení. Jak již bylo popsáno, proces je sled kroků navržených za účelem vytváření výrobků nebo služby. Některé procesy mohou být plně vykonávány v jediné organizační jednotce firmy, ale většina procesů prochází napříč celou strukturou firmy. Podnikové procesy obvykle procházejí napříč funkčními jednotkami podniku, což ale nezajišťuje jejich optimální řízení. Optimální řízení procesu znamená, že celý proces je řízen, monitorován a vykazován vlastníkem procesu. Ten řídí proces s cílem naplnění požadavků zákazníka. Podnikové procesy mají ze své definice vždy zákazníky. Zákazníky můžeme rozdělit do dvou skupin: Externí zákazník - využívá výstupy podnikového procesů vně podniku, Interní zákazník - využívá výstupy podnikového procesů uvnitř podniku a je interním subjektem firmy. 18 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu Podobně můžeme rozlišovat podnikové procesy podle jejich vztahu k subjektům, které do nich vstupují, nebo jimi jsou ovlivněny. Z tohoto hlediska je možné procesy dělit na (Gala a Pour, 2009, s. 27): Interní procesy - probíhající v rámci jednoho podniku, případně pouze v jeho or- T ypyr>r °ganizačních jednotkách (divizích, pobočkách, závodech, apod.). Pro tyto procesy je charakteristické, že činnosti firmy jsou vztažené pouze k dané firmě nebo útvaru. Tedy zejména k vlastním pracovníkům firmy. Příkladem interního procesuje výrobní zakázka a její řízení. Mezipodnikové, externí procesy - zahrnující vztahy podniku k externím subjektům (obchodním partnerům, státní správě a samosprávě, apod.), překračující hranice firmy. Jsou realizovány částečně u dodavatelů, u spolupracujících firem nebo u konečného zákazníka. Hlavní črtou těchto podnikových procesuje, že jejich jednotlivé činnosti se dělí mezi několik subjektů, které si v rámci průběhu procesu vzájemně předávají vstupní a výstupní informace, případně materiál, polotovary, produkty, atd. Příkladem takových procesuje například řízení obchodních zakázek. Na základě kategorie zákazníků a stanovených cílů podnikových procesů lze procesy v podniku dělit na (Gala a Pour, 2009, s. 27): Řídící procesy - zahrnují v sobě činnosti spojené s definováním strategických cílů podniku a zajištěním realizace těchto cílů v rámci celého podniku. Mezi tyto procesy tedy řadíme krátkodobé (operativní) plánování, stanovení cílů, odměňování a alokaci zdrojů, zpětnou kontrolu, apod. Základní procesy - vytvářejí produkt (výrobky nebo služby), který má hodnotu pro externího zákazníka. Jejich výsledkem je produkování výstupů, které požaduje externí zákazník. Základní procesy podporují hlavní podnikatelskou činnost firmy, která představuje naplnění poslání firmy, strategických cílů, atd. Na základě konkrétních vizí a poslání firmy lze podle jejich významu hlavní procesy dále členit na klíčové procesy (core processes). Vedlejší procesy - jsou podobné hlavním podnikovým procesům, ale nejsou z hlediska vize a poslání firmy důležité natolik, aby se výrazným způsobem podílely na hlavní podnikatelské činnosti firmy. Vedlejší procesy mohou být uskutečňovány paralelně s hlavními procesy nebo sdílenými procesy. Jejich výstupy jsou určeny převážně pro externího zákazníka. Jako takové jsou hlavními kandidáty na vyloučení z vlastní činnosti podniku formou outsourcingu5 . Jako příklad můžeme uvést proces provozu školy pečení v rámci pekárny. 5 Outsourcing (angl. „out", vně, a „source", zdroj) představuje, že podnik vyčlení různé podpůrné a vedlejší činnosti a svěří je smluvně jiné firmě jako sub-kontraktorovi, který je specializovaný na příslušnou činnost. Cílem je snížit náklady na vlastní provoz. 19 ZÁKLADNÍ POJMY Z OBLASTI PROCESNÍHO ŘÍZENÍ Podpůrné procesy - j ej ich výstupem j e vytvoření vhodných podmínek, které podporuj í funkcionality hlavních procesů. Jejich charakteristickým znakem je vytvoření přidané hodnoty pro externího zákazníka ve formě produktu, který externí zákazník sice nevidí, ale který je nezbytný pro efektivní řízení podniku. Příkladem je kontrola kvality. Sdílené procesy (nebo služby) - vytvářejí podmínky, které umožňují funkci všech podnikových procesů. Vytvářejí hodnotu pro interního zákazníka. Příkladem je proces přijetí objednávek. Hodnotový p r o c e s můžeme nahlížet také jako na hodnototvorný nebo hodnotový řetězec. Každý krok procesu (aktivita, činnost) by měl přidat jistou hodnotu výrobku nebo poskytované službě oproti kroku předchozímu. Podle úrovně řízení můžeme podnikové procesy dále členit na procesy operativního, taktického a strategického řízení. Podle oblasti řízení např. na procesy obchodního, finančního, marketingového nebo logistického řízení. PRO ZÁJEMCE Hodnotový řetězec (value chain) rozčleňuje firmu na její strategicky významné aktivity. Důvodem je porozumění vývoji nákladů a rozeznat existující potenciální zdroje odlišností. Firma získá konkurenční výhodu tím, že bude tyto strategicky důležité aktivity dělat levněji a lépe než její konkurenti. Michael Porter vytvořil hodnotový řetězec jako primární nástroj, který slouží k nalezení možností, jak vytvořit větší hodnotu pro zákazníka. Firmy obhospodařují soubor činností, jejichž hlavním cílem je designovat, produkovat, distribuovat a podporovat své výrobky nebo služby. Hodnotový řetězec podniku a způsob jakým podnik provádí jednotlivé aktivity, j sou odrazem jeho historického vývoje, strategie, postoji k realizaci této strategie a vnitřní ekonomiky těchto aktivit samotných. Rozdíly mezi jednotlivými hodnotovými řetězci u konkurence jsou hlavním zdrojem konkurenční výhody. Hodnotový řetězec znázorňuje jeho celkovou hodnotu a skládá se z hodnototvorných aktivit a marže. Hodnototvorné aktivity jsou technologicky a fyzicky odlišné činnosti, které podnik provozuje. Jsou to stavební kameny, jimiž firma vytváří produkt, který má pro jeho koncového zákazníka určitou hodnotu. Marže je rozdíl mezi koncovou cenou a souhrnnými náklady na uskutečnění potřebných hodnototvorných aktivit. Robert S. Kaplan a David P. Norton kladou značný důraz na hodnotový řetězec ve svém modelu Balanced Scorecard (používaná zkratka BSC). Hlavním faktorem, který ovlivňuje hodnotu produktu pro zákazníka, je zákaznická perspektiva a pro vlastníky to je finanční perspektiva. Hodnotový řetězec popisuje každý podnik a jeho procesy jako probíhající řadu dílčích aktivit, které společně ovlivňují pozici podniku ve vztahu ke konkurenci a k zákazníkům. Tyto aktivity se podílejí na vytváření hodnoty, proto se také využívají k hodnocení vlivu 20 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu jednotlivých dílčích aktivit na celkovou hodnotu podniku a mohou být následně zdokona­ lovány. BSC je metoda v managementu a představuje systém vyvážených ukazatelů výkonnosti podniku. Vytváří vazbu mezi operativními činnostmi a strategií se zaměřením na měření výkonu. Metoda BSC vznikla v roce 1992 jako reakce na fakt, že řada strategických záměrů podniků nebyla přetavena do reality. Mnoho podniků má problém s reálným propojením operativních činností se strategií tak, aby byla strategie implementovaná do všech podnikových oblastí a tím bylo možné ověřit dosažení strategických cílů. Jedním z důvodů je, že východiskem operativních plánů jsou většinou jenom finanční ukazatele, které nejsou schopné v dostatečné míře charakterizovat celý podnik. Je nutné proto sledovat a vzájemně skombinovat všechny ukazatele (metriky) - kromě finančních také ukazatele zaměřené na zaměstnance, firemní procesy a v neposlední radě taky na zákazníky. Hodnotovými výhodami zákazníka jsou ty vlastnosti produktů, které přinášejí podniku spokojenost a loajalitu zákazníků v cílových tržních segmentech. V jednotlivých segmentech se tyto výhody liší, aleje možné je rozčlenit do tří skupin, které platí pravděpodobně v každém ze segmentů. Patří mezi ně: Vztahy se zákazníky, vlastnosti výrobku nebo služby, pověst a image podniku. 1.3 Workflow Workflow systém 1.3.1 AUTOMATICKÉ PROVEDENÍ PODNIKOVÉHO PROCESU Významným přínosem zavedení procesního řízení v podniku je mimo jiné také možnost automatizace řízení a koordinace probíhajících aktivit. Podnikový proces, jehož provádění je částečně, nebo úplně počítačově automatizováno se nazývá workflow. Tohoto progresu v řízení je možné dosáhnout pomocí explicitní znalosti definice podnikového procesu. Zatímco tradičně řízení podniku spočívá na vedoucích pracovnících, kteří kontrolují korektní provádění aktivit manuálně na základě stanovených podnikových postupů a svých zkušeností, při existenci exaktního popisu podnikového procesu může být dohled nad správou pořadí vykonávaných činností přenechán informačnímu systému - workflow systému. Workflow systém na základě existujícího procesního modelu zajišťuje realizaci předepsaných činností. Tyto činnosti jsou přidělovány automaticky přiděleným pracovníkům. Řešitelem může být nejenom člověk, ale také další IS. Proto obecně diskutujeme o tzv. přidělování zdrojů. 21 ZÁKLADNÍ POJMY Z OBLASTI PROCESNÍHO ŘÍZENÍ Workflow systémy kromě samotné koordinace a řízení procesu zajišťují také další prospěšné funkce, mezi které patří podpora modelování procesu, jeho administrace, simulace nebo monitoring jeho průběhu. Pro kompletní informaci o názvosloví workflow systémy bývají podle jiné terminologie také nazývány systémy pro řízení podnikových procesů (angl. „Business Process Management Systems" - BPMS). Df DEFINICE Workflow je automatizace části nebo celého podnikového procesu. V průběhu procesu jsou předávány informace, dokumenty a/nebo úkoly od jednoho účastníka procesu k dalšímu podle stanovených procedurálních pravidel. Workflow umožňuje existující podnikové procesy zprůhlednit a pomáhá zajistit zvýšení efektivnosti, zjednodušení a zkrácení průběhu celého podnikového procesu. Na druhé straně ale klade vysoké nároky na jednoznačnost specifikace a přesnost procesu kvůli automatizaci. Základní rozdíl mezi workflow a podnikovým procesem je v tom, že workflow je řízeno k tomu určeným softwarem (WfMS nebo ERP6 ). WfMS definuje, tvoří a řídí průběh podnikového procesu. Workflow umožňuje interpretovat definici procesu, komunikovat s jeho účastníky a v případě nutnosti spouštět jiné aplikace. Z technického hlediska je samotný WfMS také zajímavý, neboť propojuje technologie, metodiky7 a principy různorodých oblastí řízení a ICT, jako např. elektronická pošta, řízení úkolů, znalostí, dokumentů technologie klient/server, databázové zpracování, modelování a monitoring procesů ajiné. Počítačové modely podnikových procesů upřesňují všechny nutné atributy a parametry pro vykonání složitých procesů. Parametry jsou jak jednotlivé kroky (například dotaz v databázi, vložení záznamu zákazníka, atd.), tak určení podmínek a pořadí, za nichž mohou být tyto kroky vykonány. Podmínkou může být např. určení odpovědnosti za krok procesu nebo datový tok mezi jednotlivými kroky procesu. Jednou z nej náročnějších částí implementace a realizace podpůrného počítačového systému jsou složité soustavy transakcí nebo 6 ERP (Enterprise Resource Planning) je informační systém, který integruje a automatizuje velké množství podnikových procesů, které souvisejí s odpovídajícími činnostmi firmy nebo podniku. Typicky se jedná o prodej, distribuci, logistiku, výrobu, fakturaci a účetnictví nebo správu majetku, apod. 7 Metodika je teoreticko-praktické schéma, které specifikuje postup provádění odborné činnosti. Vychází z vědeckého poznání a empirie. Také přesně vymezuje konkrétní postupy pro výkon zvolené činnosti. 22 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu operací, které je nutné koordinovat a organizovat na cílených výsledcích či případných selháních a také v závislosti na jejich pořadí. Workflow zatím nemá česky ekvivalent, proto je i v dalším textu opory používána anglická varianta. Do češtiny by tento výraz mohl být přeložen j ako „tok prací". Infrastruktura podniku je tvořena kombinací všech jeho procesu. Tedy i těch, které zdokumentované nejsou, neboť jsou vytvořené a uložené v hlavách pracovníků nebo v různých směrnicích, případně mohou být vyžadovány v rámci zvyků, neformálních pravidel, atd. Některé postupy jsou tedy předávány mezi pracovníky pouze ústně. Jak vidíme, toto je ten nejméně vhodný způsob, jak s infrastrukturou nakládat. Jakýkoli pokus rozšíření nebo o zlepšení této infrastruktury vyžaduje dokumentaci. Jedině tak můžeme o ni mluvit, poznat ji, aktualizovat a revidovat ji. Důležitá je také rychlost provádění podnikových procesů. Současné řídící postupy kladou na první místo rychlostj ednotlivých procesů, kterými j sou především vývoj a výroba produktu, případně logistika. Jde o rozhodující podnikové procesy v konkurenčním boji, které ovlivňují rozvoj a udržitelnost podnikání. Vždy bychom měli myslet na to, že konkurence již může mít řadu workflow procesů implementovánu. Tím před námi získává výhodu nejen v rychlosti implementace, ale také v kvalitě. Od implementace WfMS je možné očekávat snížení nákladů a zvýšení efektivity práce, které vyplývají ze zavedení standardních postupů, zlepšení kvality a organizace práce, zjednodušení podnikových procesů, dokumentace dosud jen v hlavách uložených postupů (což při odchodu pracovníka výrazně zjednoduší vyškolení jeho následovníka). Na základě vyhodnocení dokumentace postupuje také jednodušší navrhovat změny. V každé chvíli je možné jednoduše zkontrolovat stav jednotlivých případů, jejichž vybavení se pomocí WfMS značně zrychluje. V oblasti dokumentů má implementace WfMS také své výhody - veškeré změny v datech nebo dokumentech jsou autorizovány a průběh každého případu je zaznamenán v historii, kterou není možné dodatečně měnit. WfMS přirozeně podporuje i řízení kvality, které je důležitou složkou na konkurenčním trhu. 1.3.2 TYPY WORKFLOW SYSTÉMŮ Členění systémů do skupin se společnou charakteristikou je běžné, pokud potřebujeme získat lepší pohled na široké spektrum systémů. WfMS jsou taktéž členěny podle různých hledisek do skupin a typů. Základní členění WfMS je z hlediska charakteru podporovaných podnikových procesů. Z tohoto pohledu můžeme WfMS rozčlenit do čtyř základních skupin - administrativní, kolaborativní, produkční a ad hoc systémy. • Administrativní workflow slouží k vyřizování běžné agendy. Tento typ WfMS zajišťuje rutinní administrativní činnosti. Příkladem jsou registrace vozidla, vyřízení objednávky, vystavení faktury, ve školství např. žádost o mimořádný termín zkoušky apod. V každém podniku bychom našli množství podnikových procesů tohoto typu. Bývají dobře strukturovatelné, nejsou složité, často se opakují, nemají moc alternativních možností a bežnejšou spojené se standardizovanými formuláři. Pro administrativní workflow je typické, že téměř každý pracovník 23 ZÁKLADNÍ POJMY Z OBLASTI PROCESNÍHO ŘÍZENÍ v podniku je jeho potencionálním účastníkem, z čehož plyne důležitost dostupnosti systému pro každého. Také by se mělo myslet na to, že účastníci administrativního workflow jsou jen příležitostní, že toto není jejich hlavní pracovní náplní. Proto je nutné administrativní workflow co nejvíce simplifikovat. Z charakteru administrativního workflow vyplývá, že se značné liší v jednotlivých organizacích a také, že podléhá časovým změnám. Příkladem administrativního workflow je například zpracování žádosti o dovolenku. Ačkoli jde o podnikový proces, který je snadno strukturovatelný, jeho implementace je v různých firmách odlišná. Kolaborativní workflow podporuje spolupráci v týmu. Charakteristická je v tomto případě existence nějakého dokumentu, pomocí něhož si pracovníci vyměňují své poznatky a který je vlastně výsledkem jejich společné práce. Kolaborativní procesy většinou obsahují nějaký opakovaný cyklus několika iterací téhož kroku, dokud se všichni nesjednotí na výsledku. Taktéž může dojít i k návratu do předchozí iterace. Příkladů kolaborativních workflow procesů najdeme v každé organizaci několik - může jít o tvorbu propagačních materiálů, dokumentace, návrh nové služby, změnu designu produktu apod. Jedno mají tyto podnikové procesy společné - vždy je jako výstup dodán dokument, na kterém spolupracuje několik pracovníků a který prochází různými schvalovacími kolečky. Další typickou vlastností kolaborativních workflow procesů je jejich výrazná dynamičnost. Některé kroky jsou definovány až na základě průběhu předchozích aktivit. Pro kolaborativní workflow je charakteristické, že účastníci podnikového procesu pracují společně, podnikové procesy jsou tak méně rigidní a je pro ně typická dynamická změna jejich definice. Pro dobré řešení je vhodné, aby nebylo vtíravé a umožňovalo kreativitu účastníků podnikového procesu. Také musí být flexibilní, protože kreativní pracovníci často využívají předem nedefinované postupy. Průchodnost těchto systémů nebývá obvykle důležitá. Příkladem kolaborativního workflow by mohlo být představení marketingového konceptu pro uvedení nového výrobku na trh. Základní črty takového marketingového konceptu dle postupů firmy poskytuje pro tento případ určená šablona workflow. Marketingový manažer na základě dostupných zdrojů, svých znalostí a omezení zpracuje plán do detailů. Poté mají manažeři z poboček s lepšími informacemi o daném trhu možnost připomínkovat plán a navrhovat úpravy dle vlastních představ. V daném časovém horizontu se pak implementuje globální plán, jehož stav musí být průběžně k dispozici všem participujícím pracovníkům. Produkční workflow podporuje hlavní (klíčové) podnikové procesy, které vytvářejí přidanou hodnotu k finálnímu produktu a na kterých je závislá spokojenost zákazníků. Tyto podnikové procesy jsou také dobře strukturovatelné, i když jejich struktura může být někdy složitá. Výskyt takových podnikových procesů je častý, pracovníci jim věnují většinu své pracovní doby. Alternativní průběhy hlavních procesů jsou předem definovány a jejich výskyt je relativně omezený. Tyto procesy jsou vlastně jistou variací výroby v továrně. Dělníci vykonávají 24 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu řadu činností, ale jenom jediná je hlavní. Tato činnost určuj e jejich profesi, zařazení a identifikuje jejich rutinní úkoly. Na základě toho vznikl i název pro tento typ workflow. Produkční workflow je typické tím, že flexibilita změn definice podnikového procesu není důležitá, neboť jejich výskyt není častý. Navíc změna definice podnikového procesu není starostí koncových uživatelů, ale specialistů. Z toho vyplývá, že změna definice podnikového procesu většinou souvisí s podstatnějšími změnami v celém podniku. Produkční workflow vyžaduje integraci s jinými podnikovými systémy. Je celkem zřejmé, že čím je kratší prodleva mezi jednotlivými kroky podnikového procesu, tím je celý systém více produktivní. Typickým produkčního workflow může být zpracování žádosti o úvěr v bankách. V tomto případě se jedná o opakované zpracování poskytnutí standardního produktu. Ad hoc workflow je poslední skupinou WfMS z pohledu charakteru procesů. Tato skupina WfMS je založena na náhodnosti vzniku workflow procesu. Jedná se o podnikové procesy, kterých průběh není popsán předem. Nejsou proto standardizované a jsou většinou jedinečné. K jejich definici musí dojít v okamžiku jejich vzniku. Jistým způsobem jsou podobné administrativním workflow. Rozdílem je, že postup definice podnikového procesu má trend ke zpracování výjimek, odchylek a ojedinělých situací. Z toho vyplývá podstatný rys této skupiny procesů - zatímco celý podnikový proces je jedinečný, jeho účastník se běžně podílí na mnoha opakovatelných a podobných subprocesů. Ad hoc WfMS vyžadují od pracovníků vysokou míru samostatnosti. Proto je nutná široká dostupnost workflow produktu a jednoduchá definice workflow procesu. Příkladem ad hoc workflow je požadavek zákazníka na dodání velkého množství produktu s vlastním návrhem balení, které je specifické a vymyká se běžným postupům a možnostem podniku. Dalším možným příkladem je odpověď na zadání odběratele, zpracování závěrečného reportu projektu nebo selhání logistické přepravy, která byla smluvně garantovaná. 1.4 Metody pro modelování podnikových procesů Pro modelování procesů se používají různé metody. Mezi základní patří BPEL (Business Process Execution Language) (Basi, 2012, s. 115). Z obecného hlediska je možné pro modelování podnikových procesů použít např. univerzální modelovací jazyk UML (Unified Modelling Language), případně v upravené podobě podle H. Ericssona se čtyřmi základními pohledy na podnik (Řepa, 2006): Procesní pohled - zahrnuje podnikové procesy, aktivity a hodnoty v podniku, které tyto činnosti vytvářejí. Charakterizuje vzájemnou spolupráci podnikových 25 ZÁKLADNÍ POJMY Z OBLASTI PROCESNÍHO ŘÍZENÍ procesu a využívání zdrojů za účelem dosažení strategických cílů, které jsou definované ve vizi8 podniku. Chování organizace - zahrnuj e vnitřní „chování" a interakci j ednotlivých prvků podniku (procesy a zdroje). Cílem analýzy těchto interakcí je přidělení odpovědnosti za jednotlivé zdroje. Strategický pohled - zahrnuje klíčové pojmy jako např. strategické cíle a hodnoty podniku. Soustředí se na úmysly a hlavní problémy, které mají být procesní změnou vyřešeny. Strukturní pohled - zahrnuje zdroje organizace, jako jsou znalosti, dokumenty, organizační jednotky, informace, produkty apod. Obrázek 1-7: Metamodel podnikového procesu. Zdroj: upraveno podle Řepy (2006) K analýze podnikových procesů slouží soustava technik, mezi které patří také diagram procesů. Jak ilustruje obr. 1-7, jsou znázorněny základní objekty, které s procesem souvi­ sejí: Řídicí objekty - objekty, které řídí průběh podnikového procesu. Cíle - jichž má být prostřednictvím podnikového procesu dosaženo. Takovým cílem může být například spokojený zákazník nebo kvalitní produkt. Vstupy - objekty, které jsou podnikovým procesem přetvářeny nebo spotřebovávány. Jsou jimi suroviny, informace nebo lidská práce. Výstupy - obj ekty, které j sou produktem nebo výsledkem podnikového procesu. Diagram procesů 8 Vize sumarizuje to, čím chce podnik, společnost nebo organizace být, popisuje budoucnost, která je významně odlišná od současnosti tím, že vytyčuje směr dlouhodobých změn v společnosti a e zdrojem inspirace. Poskytuje důležitá rozhodovací kritéria pro tvorbu základních strategických cílů a směrů, v kterých je společnost chce dosáhnout. 26 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu Standardy Podpůrné objekty - suroviny nebo informace, kteréj sou podnikovým procesem využívány, ale nejsou přetvářeny ani spotřebovávány. Pro modelování podnikových procesů jsou využívány různé modelovací standardy a normy. Modelovací normy určují prvky modelu podnikového procesu a jejich význam. Příklad standardů (Basi, 2012, s. 116), které jsou běžně podporovány různými nástroji pro modelování podnikových procesů, jsou následující: • BPEL - Business Process Execution Language (BPEL) je technická norma, která se využívá při popisu spustitelných procesních modelů, které jsou určeny k provádění, automatizaci a integraci. Provádění je zabezpečeno webovými službami {web services9 ). • BPMN - Business Process Modeling Notation (BPMN ve verzi 2.0) je technicky specifikována norma pro vytváření procesních modelů. Více se o BPMN dočtete v další kapitole. UML - Unified Modeling Language (UML) j e univerzální modelovací j azyk pro analýzu a návrh funkcionalit softwarových produktů, ale používá se i v doméně modelování podnikových procesů. Primárně pomáhá zmazat mezeru mezi návrhem softwaru, který je pochopitelný pro lidi mimo ICT a detailním návrhem softwarových systémů. EPC - Event-driven Process Chain (EPC) je významný standard pro modelování podnikových procesů. Notace, která je zaměřená netechnicky, dovoluje rychle a jednoduše uživatelům mimo ICT optimalizovat a dokumentovat jejich workflow. Při modelování podnikových procesů se používají tři základní metody popisu: Neformální metody popisu - popis podnikových procesů prostřednictvím při- Z a k l a d m metody rozeného jazyka. Nemá danou syntaxi ani sémantiku. Vyskytuje se v podobě ne- popisu strukturovaného volného textu jako například „Michal přijme cenovou nabídku od dodavatele, zašleji Mirkovi a ten zjistí, jestli nabízená cena není mimo rozsah běžné ceny u tohoto typu služby.". Výhody této metody jsou například v tom, že pro kompletaci popisu není potřebné specifické vzdělání, ani zvláštní nástroje. Porozumění popisu je poměrně snadné. Nevýhodou je zavádění změn a složitá správa, nevhodnost pro prezentaci, nepřehlednost, nemožnost automatického zpracování a analýzy. Dále pak skutečnost, že každý má jiný styl psaní a rozumí jiným detailům. Problémy často vznikají při popisu souběžnosti a alternativy. 9 Webová služba je softwarový systém umožňující interakci dvou strojů na síti. Je popsána ve strojově zpracovatelném formátu, konkrétně WSDL. S webovou službou ostatní stroje komunikují způsobem, který je předepsaný v popisu služby, pomocí protokolu SOAP přepravené pomocí jiných, již zavedených protokolů, tzv. tunelování firewallu. 27 ZÁKLADNÍ POJMY Z OBLASTI PROCESNÍHO ŘÍZENÍ Semiformální metody popisu - popis podnikových procesu pomoci grafických notací. Pro tyto metody je typická volná sémantika a přesná syntaxe. Existuje poměrně velké množství dostupných notací. Příkladem je BPMN (další kapitola), UML, EPC, IDEF, RAD (Rapid Application Development), NPC a další. Grafický zápis je mnohem přehlednější než volný text. Výhody jsou v jednodušší správě a zavádění změn, možnost automatického zpracování a analýzy. Při dodržení několika omezení je možné semiformální popis převést do formálního tvaru. Nevýhodami jsou potřeba zvláštních nástrojů, potřeba základní znalosti notací i při čtení, složitější tvorba, často docházzí k rozdílným výkladům obsahu. Každá z použitých notací má v podstatě své výhody a nevýhody, ale použití více druhů vede k chaosu. Semiformální notace mají přesně danou syntaxi, ale nediktují použití precizní a úplné sémantiky. Formální metody popisu - umožňují jednoznačně definovat podnikový proces pomocí precizně dané syntaxi a sémantice použité metody. Jinak řečeno, jde nám o takové procesní modely, které je možné navrhovat v počítači, ukládat je tam, analyzovat a popřípadě dále využívat ve WfMS nebo ERP systémech. V momentě, kdy taková notace získává rysy precizní syntaxe i sémantiky, stává se z ní formalizmus, nebo formální specifikace. Formální specifikace je jinými slovy technika, která umožňuje jednoznačně popsat modelovaný systém. OTÁZKY 1. Vysvětlete procesní pohled na podnik a rozdíly oproti funkčnímu pohledu. 2. Popište obecně co je podnikový proces. 3. Jaké členění je typické pro podnikové procesy? 4. Jaký je rozdíl mezi workflow a podnikovým procesem? 5. Jaký je rozdíl mezi modelem podniku a jeho instancí? 6. Jaké typy workflow se v současnosti používají v praxi? 7. Jaké metody popisu podnikových procesů poznáte? Vysvětlete rozdíly. SHRNUTÍ KAPITOLY V této kapitole jsme se seznámili se základními pojmy z oblasti modelování podnikových procesů. Vysvětlili jsme si podstatu a složení procesu, typy podnikových procesů a procesní náhled na podnik, workflow a jeho typy. Závěrem kapitoly jsme nahlédli na základní notace modelování podnikových procesů. 28 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu ODPOVĚDI 1. Kapitola 1, str. 9. 2. Podkapitola 1.1, str. 11. 3. Podkapitola 1.2, od str. 18. 4. Podkapitola 1.3.1, str. 22. 5. Podkapitola 1.3. 6. Podkapitola 1.3.2. str. 23 a 24. 7. Podkapitola 1.4, str. 27 a 28. 29 MODELOVÁNÍ A SIMULACE 2 MODELOVÁNÍ A SIMULACE RYCHLÝ NÁHLED KAPITOLY Tato kapitola se věnuje představení základních pojmů v oblasti modelování - co je systém a jaké druhy systémů poznáme, z čeho se skládá a jiné. Dále se budeme věnovat událostem, transakcím, aktivitám a atributům systému. Část textu představuje také modelování, existující modely a klasifikaci modelů. Druhá polovina kapitoly prezentuje základní principy vědecké disciplíny - simulace. Vysvětlíme si definici simulace, simulačního experimentu a představíme základní členění simulací - spojitou a diskrétní simulaci. CILE KAPITOLY Po prostudování této kapitoly budete umět: • Definovat co je systém, model, modelování a simulace. • Vyjmenovat a objasnit základní typy modelů, simulací a základních simulačních konstruktů. ^ I KLICOVA SLOVA KAPITOLY Systém, modelování, model, simulace, program, běh, experiment, spojitá a diskrétní si­ mulace. Když chceme například podle Kindlera (2001) definovat modelování, je nutné před tím objasnit hned několik důležitých pojmů jako například systém, model a další. Množství termínů, které budeme v této kapitole používat, j sou cizí slova, nejčastěji adaptované z anglického jazyka. Každý počítačový specialista je nucen ve své odborné činnosti číst anglickou literaturu. Zároveň je však potřebné říct, že množství cizích slov, které se v oblasti modelování používají, mají jiný význam jako v běžném životě. 2.1 Systém Termín systém se v dnešní době vyskytuje v mnoha oblastech a v různých významech. systém V teorii modelování se studuj e něj aká věc, nebo j ej í možné varianty. Věc j e něj aký obj ekt, který se vyskytuje v reálném světě, který skutečně existuje (např. člověk, úřad, firma apod.), nebo o kterém předpokládáme, že by existovat mohl (počítač, škola, výrobní linka 30 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu nebo továrna, který by měla být postavena ajiné.). Věc, jak ji chápou filozofové, se uvažuje v její úplné složitosti nebo spolu se všemi nejasnostmi její existence. Stejně však chápou, že není v lidských možnostech celou věc rozumně pochopit a zvládnout. Podobně to chápou i různé technické obory, a proto se uvažují na zkoumaných věcech abstrakce oprošťující od přílišných detailů. Abstrakce usnadňují zainteresovaným osobám o věcech rozumně přemýšlet a komunikovat. Tyto oprošťující detaily nebo aspekty nejsou pro fungování řešené věci kritické. Taková abstrakce se v teorii modelování nazývá systémem. Podle druhu profese, která systém na věci „sleduje", „provádí", „definuje" bude tento systém dostávat přívlastek (např. politický systém, elektronický systém, mechanický systém a jiné.). Co se týče času, ten v abstrakci může nebo nemusí být zanedbán. Například firma Google, která pořizuje fotodokumentaci do své mapové cloudové aplikace se nemusí zajímat o to, jak vypadala krajina před nebo po datu focení, nebo kolik domů je právě ro­ zestavěno. DEFINICE Statickým systém nebere do úvahy význam času. V dynamickém systému se naopak čas nezanedbává. Množina okamžiků, v kterých dynamický systém existuje, se nazývá existence dynamického systému. Každý dynamický systém je v každém okamžiku své existence v nějakém stavu. Událost je změnou stavu dynamického systému. Systém je složen z prvků. Taky se může stát, že systém je tvořen jenom jedním prvkem, ale taková situace je poměrně ojedinělá. Běžně se systém skládá z více prvků, které mají svoje typické chování. Když poznáme chování jednotlivých prvků, je možné z toho odvodit chování celého systému. Prvky systému, tedy prvky abstrakce na nějaké věci, mohou odpovídat elementům, které na věci fyzicky (vztahové složky, prostorové), nebo logicky (provázanost dané věci, nebo jejich částí, schopnosti) rozeznáváme. Počet prvků v dynamickém systému se může během jeho existence měnit, např. biologický systém se může smršťovat a růst. V ekonomických a technických systémech jde nejčastěji o to, že prvky mohou do systému „vstupovat" a ze systému „vystupovat". Tyto prvky se nazývají transakce (temporary elements, transactions). Ve skutečnosti takové prvky nevznikají, ale přicházejí do systému z jeho „okolí", a nezanikají, nýbrž systém opouštějí. Vzhledem k tomu, že samotný systém je abstrakce, která našemu myšlení nahrazuje zkoumanou věc, abstrahujeme i od okolí, které reálně pro danou věc existuje, ale pro systém nikoliv. Jinak řečeno, když je nějaká složka reality přítomna v části prostředí, od kterého abstrahujeme, tak v naší abstrakci je to stejné, jako kdyby neexistovala. Příkladem transakcí j sou např. zakázky směrující do podniku, pacienti nastupující do nemocnice, zákazníci přihlašující se do e-shopu nebo vozidla, které vstupují do dopravního systému, 31 MODELOVÁNÍ A SIMULACE který je - jakožto systém - abstrahován tak, že je vyčleněn ze svého okolí, z něhož do něj vozidla přijíždějí a kam jej vozidla opouštějí. DEFINICE Permanentními prvky neboli aktivitami {activities, permanent elements) se nazývají prvky, které jsou v dynamickém systému během celé jeho existence,. Vysvětlili jsme si, že když o systému přemýšlíme, zanedbáváme vše, co do něho nechceme zahrnout. Z toho vyplývá, že když transakce dynamický systém jednou opustí, je „ztracena" z našich úvah a nemá smysl zabývat se jejím návratem. Jinak řečeno, pokud by bylo možné, že transakce systém skutečně opustila a pak se do něj vrátila, nemělo by být možno určit, že jde o tu samou transakci. Pokud se identita transakce naopak určit má, pak tato transakce nemůže systém opustit, nýbrž v něm zůstává, může být něj ak skryta a vyskytuje se bez důležitosti na to, co se v systému děje, ale nemůže systém opustit a musí být po celou dobu uvažování do abstrakce začleněna. Prvky systému mají své vlastnosti, které se nazývají atributy. Příkladem může být teplota vody v chladícím systému tepláren (jedná se o tzv. reálný nebo aritmetický atribut, protože ten nabývá aritmetických hodnot, reálných čísel), dále to může být funkčnost čidla v produkčním systému (jedná se o tzv. booleovský atribut, protože nabývá booleovských hodnot „ano" a „ne", konkrétněji značeno „měří" a „neměří"), nebo jméno dodavatele firmy (jedná se o tzv. textový atribut, který nabývá textových hodnot). Atributy tedy přiřazují prvkům určité hodnoty a ty se u prvků dynamického sytému mohou v čase měnit. 2.2 Model Jak se náš praktický život stává složitějším, tím více modelování jako vědecká metoda nabývá důležitosti v téměř každé lidské činnosti. Stává se z něj jedna ze základních metod poznání. Teorie modelování se zabývá všemi oblastmi poznání - od zkoumání mikrosveta po objekty velkých rozměrů, např. zemětřesení, atmosférické proudy anebo tvoření hvězdných mlhovin. Modelování se prosazuje taky v oblasti zkoumání sociálních jevů, nevyjímaje jevů poznáni lidské psychiky. Termín „model" se používá na označení materiální i nemateriálni napodobeniny objektu, přičemž nezávisí na tom, za jakým účelem se dělá. Samotná napodobenina se může vytvořit v souvislosti s různými praktickými úlohami, např. může plnit určité funkce při vyučování (jako např. makety, schémata, tabulky a jiné, které se používají jako názorné výukové pomůcky) anebo se používá za badatelským účelem. K vytvoření nebo návrhu modelů se běžně přistupuje v těch případech, kdy je obtížné anebo vůbec nemožné zkoumatjev nebo objekt v jeho přirozené formě. V mnoha případech 32 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu je zkoumaný jev natolik složitý (důležitý), že když ho pozorujeme v jeho bezprostřední formě, dochází k vzniku rizika schematizaci anebo zjednodušení reálného obrazu procesů, které v něm probíhají. Podobné nebezpečí může vzniknout při zkoumání jevů, které se vyvíjejí velice rychle anebo velice pomalu. Mnohem složitější je situace v případech, kdy se zabýváme jevy, které patří do minulosti nebo do budoucnosti. Současná praxe a věda se neustále zabývá řešením takových typů úloh. Jednou ze základních otázek, které se objevují při startu řešení každého nějaké úlohy praktické, teoretické, pragmaticky-praktické apod.) je, jestli máme k dispozici předběžné vědomosti o předmětných jevech a procesech. K ZAPAMATOVÁNÍ Apriorní informace je předběžná vědomost se o objektu a může se chápat jako počáteční. Někdy je taková informace tak komplexní a detailní, že vytýčenou úlohu je možné řešit bez dodatečného zkoumání objektu. Takové situaci poté odpovídá také nutnost vytvořit, resp. navrhnout modely. Existují i případy, kde je apriorní informace pro řešení úlohy nedostačující. V tomto případě je potřebné výzkum prodloužit, aby bylo možné získat další informace o objektu Apriorní zkoumání. Ačkoliv to vždy není možné. Snadno mohou nastat i takové situace, kdy apriorní informace informace vůbec není k dispozici. I v tomto případě je jedním z rozhodujících prostředků pro tvoření konkrétního systému poznatků proces modelování. Ve všech takových situacích práce výzkumníků probíhá specifickým způsobem: Místo zkoumání objektu přímo v jeho přirozené formě se přistupuje k tvorbě anebo využití dostupné náhrady objektu zkoumání a celý výzkumný proces se v tomto případě přenáší na objekt nový, dokud se znalosti, které jsou získané při jeho zkoumaní, týkají reálného objektu. V teorii modelování se v souvislosti s výše uvedeným používají tyto termíny - (1) originál se používá pro přirozený objekt a pro identifikaci objektu, který je předmětem bádaní, taktéž kváziobjekt, náhrada, (2) analogie - pro označování objektu nového, vytvořeného nebo používaného na výzkum ori­ ginálu. Každá náhrada reálného objektu musí vyhovět několika požadavkům. Hlavně se určitý jev zkoumá jako model tehdy, pokud je zdrojem nového poznání objektu našeho zájmu, nějaké vhodné informace a ověření. Aby splnil svou úlohu, musí se model nacházet v nějakém vztahu vůči objektu, musí mu být podobný. Ve většině případů objektivní vztah originálu a modelu tkví v tom, že model odráží reálný objekt. Současně každý model reprezentuje vybraný objekt v zjednodušené formě. V případě, že model modeluje svůj objekt v celé jeho mnohostrannosti a složitosti, 33 MODELOVÁNÍ A SIMULACE není potřeba jeho tvorby. Modely se tvoří, abychom získali nové vědomosti o zkoumaném objektu. Obvykle mnohem jednodušeji se dá vytvořit model než originál. Slovo „model" se používalo v běžné řeči nejprve pro předlohu Kindler (2001). V odborném jazyku z minulosti zůstal z praxe termín „funkční model" jako první exemplář nového výrobku. Jeho funkce imitují nový výrobek, ačkoliv jiné vlastnosti nového výrobku (např. estetické) tento exemplář ještě nemá. Z této praxe vznikla i interpretace slova model pro něco nezvyklého, zvláštního nebo nákladného. V modelování a simulaci se termín model používá pro vyjádření analogie mezi dvěma systémy. Jednoduché příklady nabízí socha (model zvířete nebo osoby apod. v neživém materiálu), dětský vláček (model skutečného vlaku ve zmenšeném měřítku) nebo zeměpisná mapa (model části země na papíře). RO ZÁJEMCE Vztah dvou systémů - modelovaného a modelujícího je dán tím, že každému prvku P modelovaného systému je přiřazen prvek Q modelujícího systému. Dále pak každému atributu g prvku P je přiřazen atribut h prvku Q a pro hodnoty atributů g a h je daná určitá relace. Charakter relace není nějak obecně omezen, ale v případě, že g i h jsou aritmetické atributy, bývá takovou relací tolerance (mapa zobrazuje jen přibližně), úměrnost, kombinace tolerance a úměrnosti (např. rozměry složek a částí dětského vláčku jsou přibližně úměrné odpovídajícím rozměrům skutečného vlaku) apod. Když jsou modelovaný i modelující systém statické, říkáme, že daný model je statický model. 2.3 Modelování V oblasti výpočtové techniky, informačních a komunikačních technologií dominuje anglicky psaná literatura, které je potřebné se přizpůsobit a uvědomit si, že modelovat (to model) a modelování (modelling nebo modeling) může mít téměř neomezeně mnoho vý­ znamů. DEFINICE Podstatou modelování ve smyslu výzkumné techniky je náhrada zkoumaného systému jeho modelem (přesněji systémem, který jej modeluje), jejímž cílem je získat pomocí pokusů (nebo experimentů) s modelem informaci o původním zkoumaném systému. Platí tedy, že vytvoříme model, ve kterém modelovaným systémem je zkoumaný systém. Přičemž my budeme experimentovat s modelujícím systémem. Cílem bude zjistit něco 34 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu o modelovaném systému. Kdyby bylo cílem nahrazení modelovaného systému modelujícím systémem v reálném světě, šlo by o modelování ve stylu vytváření protézy. Pokud by cílem experimentování bylo dozvědět se něco o modelujícím systému bez vztahu k sytému modelovanému, šlo by vlastně jen o přímě experimentování s modelujícím systémem. Modelující systém může být abstraktní matematická struktura (např. vzorec), která je měněna lidskou myslí a interpretovaná třeba na tabuli., může to být fyzikální analogie Je zřejmé, že v dnešní době se z mnoha důvodů stále více uplatňuje ve funkci modelujícího systému výpočet na počítači. 2.4 Klasifikace modelů Ve vědeckém světě i v praxi se většinou vytváří myšlené konstrukce, které hrají úlohu modelů. Ačkoliv možné jsou taky takové případy, kdy se jako modely použijí reálně existující objekty. Tyto mohou být podobné, nebo se pokládají za podobné zkoumanému objektu. V této souvislosti mohou být modely přirozené, případně uměle vytvořené objekty. Při návrhu a realizaci nových systémů nebo při výrobě určitých výrobků se často vytvářejí prototypy. Prototypy reprezentují důležité vlastnosti objektu, kterým se zabýváme. Když se při zkoumání těchto prototypů získá nová informace, pak se zkoumají jako modely. Často se vytvářejí také tzv. pokusné provizoria, které znamenají kvantitativní model pro plánovaný technologický komplex. Když pokusné provizorium dodává negativní výsledky, tak se mění původní projekt nebo plán. Metoda modelování nachází specifické využití při zkoumání jevů, j ako j e např. chování určité sociální skupiny, veřejné mínění, spotřebitelská poptávka apod. V takovýchto případech se používá teorie reprezentativního výzkumu. Podle této teorie se vybírá určitá skupina osob, které se zkoumají z hlediska vytýčeného cíle, například se zkoumá jejich reakce na jejich chování v dané situaci, jisté události atd. Když postupujeme správně, můžeme získat zdroj hodnotné informace. Tato informace se může postupně rozšířit na celou populaci, nebo na všechny členy předmětné sociální skupiny. Mluvíme konkrétně o svérázném pokusném provizoriu, které má sice charakter modelu, ale je nutné respektovat formulovanou teorii statistiky a dodržovat určitá pravidla. Znační rozvoj praktické a vědecké činnosti si vynutil a umožnil tzv. matematické modelování, které do značné míry odstraňuje nedostatky jiných forem sociálního modelování. Matematický model je vlastně jakýsi popis struktury a chování objektů v systému pomocí matematických prostředků. Matematické modely jsou různé. Je možné, aby vyjadřovaly základní charakteristiky systému, např. rovnice, které popisují pohyb systému, resp. stavy, dále pak tabulky a grafy pro popis přechodu systému z jednoho stavu do dalšího atd. Když se matematický aparát aplikuje v oblastech, které jsou na to vhodné, je nenahraditelným a silným prostředkem na překo- 35 MODELOVÁNÍ A SIMULACE nání subjektivizmu v teorii a praxi. V dnešní době se matematické modelování používá s využitím ICT, což do teorie a praxe modelování přináší zásadní nové momenty. Využití výpočtové techniky je jedním z nejjistějších prostředků realizace vědeckého postupu v řízení, přičemž se metoda modelování dostává na kvalitativně vyšší úroveň. V současnosti se stávají důležitějšími úlohy tzv. funkčních a strukturních modelů. Možnosti vytváření těchto modelů jsou ovlivněny skutečností, že každý objekt má svou funkční stránku, tzn. určité chování a současně se odlišuje vnitřním strukturním obsahem. Díky tomu je možné modelovat chování i strukturu daného systému. Strukturní a funkční modelování nachází široké uplatnění v teorii řízení, hlavně při projektování a budování systémů řízení. Jedním ze základních požadavků při budování řídicího systému je naprojektovat takovou strukturu, která by ideálně realizovala funkce řízení. V souvislosti s úrovní organizace objektu rozeznáváme modely sublokální, lokální, superlokální a superglobální. Zajímavé jsou modely, které se rozlišují podle počtu modelovaných objektů. Modely, označované jako singulární se vztahuji najeden objekt určitého rozměru (např. na konkurenceschopnost jedné skupiny firem během sledovaného období), binární modely (zahrnují dva objekty stejného rozsahu - např. vztah mezi dvěma firmami), multipletní modely (zahrnují víc než dva objekty). Pozornost si zasluhuje i klasifikace modelů, která je spjatá s charakterem procesu jejich vytváření. Do čistě diskrétních modelů spadají „modelující" (adaptivní) modely, které např. dovolují, aby se řídicí systém stále adekvátněji přizpůsoboval měnícím se podmínkám. Modely se mohou členit podle množství metod, které se používají při jejich návrhu. V tomto smyslu existují tzv. simplexní modely (při využívaní jedné metody), duplexní modely (při využití dvou metod), komplexní modely apod. 2.5 Simulace DEFINICE Podle Kindlera (2001) a Kolektivu autorů (1986) je simulace výzkumná technika, jejíž podstatou je náhrada zkoumaného dynamického systému jeho simulátorem, přičemž se simulátorem se experimentuje se záměrem získat informace o originálu - původním zkoumaném dynamickém systému. Obecně (Kindler, 2001) slovo simulace znamená předstírání bezvědomí, nemoci, duševní poruchy apod. Odborně vzato, tento význam slova simulace by měl patřit do sociální psychologie. Pojem simulace, jak s ním pracuje informatika ajak ho chápou i ostatní obory, 36 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu Simulátor když aplikují ICT, má však zcela jiný obsah. Jednoduše řečeno, v této oblasti je simulace chápána jako modelování ve smyslu výzkumné metody, při němž použitý model je simu­ lační. V tomto smyslu budeme termín simulace dále chápat i my. Platí zde vše, co bylo zmíněno výše o modelování jakožto výzkumné technice. Především cílem simulace je získat informace o simulovaném systému. Jeho pouhá náhrada simulátorem není dostatečná. Taková náhrada se někdy nazývá emulací. Například simulátor jednoho počítače P l , který realizovaný na počítači jiného typu je jakousi protézou, která nahrazuje P l , který např. není pro nás dostupný, ale máme pro něj programy. Dále platí, že simulátor nemusí být realizován na počítači, ale dnes je takto implementován stále častěji. Číslicový počítač má své výhody především v tom, že je možné k němu přistupovat vzdáleně a dá se použít i k jiným účelům (to se dá využít, když ho zrovna nepotřebujeme použít k simulaci). Taky je obecně známo, že nespotřebovává mnoho energie a nekazí životní prostředí, i když se s tím dá polemizovat. Nezanedbatelná výhoda využití ICT je i v tom, že výpočty na počítačích (a tedy i pokusy se simulátorem) je možné reprodukovat. Zdůrazněme, že aby šlo o simulaci, musí být cílem pokusů se simulátorem snaha dozvědět se něco o simulovaném systému. Když je simulátor realizován jako výpočet na počítači, může se složkou simulace stát i experimentování se simulátorem, jehož cílem je získat modelu informaci o něm samotném a ne o simulovaném systému. Nastává to například tehdy, když ověřujeme, zda v příslušném programu není programátorská chyba nebo zda v něm není použita nevhodná numerická metoda. Tento proces se nazývá ověření správnosti modelu nebo jinak verifikace modelu. Sloveso simulovat {to simulate) budeme ve shodě s anglicky psanou odbornou literaturou chápat jako provádět simulaci. Odborník, který provádí simulaci, je v angličtině nazýván simulationist, odpovídající český termín neexistuje. V minulosti byl simulátor realizován na speciálních zařízeních a podle nich dostávala Jypysimupříslušná simulace označení - např. galvanická, hydrodynamická, elektromechanická, odporová, mechanická, analogová (pomocí analogových počítačů) a hybridní (pomocí hybridních analogově-číslicových počítačů). Dnes byly všechny tyto druhy nahrazeny simulací, při níž je simulátor realizován na číslicovém počítači, tedy simulace číslicová (digital simulation). V dalším textu budeme přívlastek číslicová vynechávat, protože žádnou jinou simulaci řešit nebudeme. Když je však zřejmé, že jde o simulaci číslicovou, spojuje se možnost vyjádřit něco přívlastkem s charakterem simulovaného systému. Když j e charakter systému spojitý, tzn., hodnoty jeho atributů se mění v čase jen spojitě, mluví se o spojité simulaci (continuous simulation - simulace spojitých systémů). Když je simulovaný systém diskrétní, tzn., nenastávají v něm spojité změny v čase, mluví se o diskrétní simulaci (discrete event simulation - simulace diskrétních událostí). Když je simulovaný systém kombinovaný, tzn. má-li jak vlastnosti typické pro spojité systémy tak vlastnosti typické pro diskrétní systémy, mluví se o kombinované diskrétně-spojité simulaci nebo častěji jenom o kombinované simulaci (combined simulation). 37 MODELOVÁNÍ A SIMULACE Významy právě představených tří základních typů simulace jsou v různých situacích a různými autory více či méně modifikovány nebo i kombinovány. Připomínáme, že systém je definován na věci. Na jedné a téže věci může být definován jak spojitý, tak diskrétní (nebo i kombinovaný) systém. A tak se klidně může stát, že je někdy jedna věc zkoumána pomocí spojité, diskrétní a případně i kombinované simulace. Například odborník v oboru mechatroniky „vidí" na počítači spojitý systém, a může tedy např. zkoumat procesor pomocí spojité simulace; avšak odborník v oboru počítačových věd vidí na počítači diskrétní systém a může aplikovat na studium téhož procesoru diskrétní simulaci. Dále je zřejmé, že i když simulujeme spojitý systém na počítači, který je číslicový, je zajímavé, že „uvnitř počítače" existuje jakýsi diskrétní dynamický systém. Tento disktrétní systém vzniká aplikací numerické metody a „diskretizací modelovaného spojitého systému". I v tomto případě však jde o spojitou simulaci, protože (viz text výše) použitý přívlastek odráží to, jak definujeme simulovaný systém my, a není v tomto případě důležité, co se děje v simulátoru. Simulační Program, který řídí výpočet při simulaci, se nazývá simulačním programem. Neexis- program tuje jednotné vysvětlení, zda se pod tímto označením rozumí program ve strojovém kódu, který skutečně výpočet řídí, nebo zdrojový kód programu, napsaný v programovacím jazyku. Je zřejmé, že důvod této nejednotnosti spočívá v tom, že v praxi kvůli ní nedochází k žádným fatálním nedorozuměním nebo selháním. I v tomto textu budeme používat označení simulační program jak pro zdrojový kód, který napíše autor simulačního modelu v programovacím jazyku, tak pro strojový kód, který z něho vznikne kompilací nebo interpretací, čili automatickým převodem do strojového kódu. simulační Pokus se simulačním modelem se nazývá simulační pokus (simulation experiment). V české literatuře se často vyskytuje termín simulační běh, ale ten nemá žádnou analogii v literatuře ve světových jazycích. Slovo run (tedy běh) je navíc vhodné jako protiklad ke slovu překlad (nebo kompilace). Například „chyba zjištěná při kompilaci" vs. „chyba při běhu") s poznámkou, že při běhu neběží jen simulační pokusy (experimenty). Když na počítači běží simulační pokus, je nutné evidovat při něm i čas, který by dané fázi výpočtu odpovídal v simulovaném systému. Mezinárodní autority v oboru simulace doporučily, aby se hodnoty času nazývaly simulárním časem (simular time), avšak odborná veřejnost používá ne zcela přesný, ale všeobecně rozšířený termín simulovaný čas (simulated time). simulační Posloupnost simulačních experimentů, které mají stejný účel se nazývá simulační stu- studie die (simulation study). V současnosti je obvykle prováděna jako jeden výpočet (task). Před každým experimentem se simulovaný čas vrátí na výchozí hodnotu a rovněž se změní sledované hodnoty způsobem, který je vrátí k výchozímu stavu. Navázání jednoho simulačního experimentu na další lze tedy nejlépe chápat jako přirovnání k tomu, že simulovaný systém se nahradí systémem zcela novým, který z historie původního systému nic „nedědí". Jeden „běh" odpovídá tedy jedné simulační studii, tedy sekvenci několika simulačních ex­ perimentů. simulační y odborné literatuře se zavádí ještě termín simulační krok (simulation step). Simulační krok je časový úsek výpočtu, během něhož se nemění hodnota simulovaného času. Simulační studie se tedy skládá ze simulačních pokusů nebo experimentů a ty se dále skládají ze 38 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu simulačních kroků. Dále platí, že na začátku každého pokusu se simulovaný čas vráti na svou výchozí hodnotu (obvykle na nulu) a s výjimkou prvního simulačního kroku každého simulačního pokusu se hodnota simulovaného času zvětší o nějaký nezáporný přírůstek. Když je tento přírůstek pro celý simulační pokus stejně velký, mluví se o ekvidistantním simulovaném čase, v ostatních případech se mluví o neekvidistantním simulovaném čase. OTÁZKY 1. K čemu se využívá abstrakce při vytváření modelů? 2. Jaké systémy rozlišujeme v souvislosti s časem, který je ovlivňuje? 3. Co znamená pojem apriorní informace? 4. Vysvětlete rozdíl mezi modelovaným a modelujícím systémem. 5. Jaké jsou to singulární modely? 6. Co je simulace a jaký je rozdíl mezi spojitou a diskrétní simulací? 7. Popište pojem simulární čas. SHRNUTÍ KAPITOL Y V úvodu této kapitoly jsme prezentovali základní pojmy z oblasti systémů, modelů a vědecké disciplíny, která se modely zabývá - modelování. Seznámili jsme se se základními typy systémů a modelů. Druhá část kapitoly se zabývala základními principy další vědecké disciplíny - simulací. Obeznámili jsme se se základními typy simulací - diskrétní, spojitou a kombinovanou. Představili j sme pojmy jako simulační program, pokus, běh a simulární čas. ODPOVĚDI 1. Podkapitola 2.1, str. 30 a 31. 2. Podkapitola 2.1, str. 31. 3. Podkapitola 2.2, str. 33. 4. Podkapitola 2.2, str. 33 a 34. 5. Podkapitola 2.4, str. 36. 6. Podkapitola 2.5. 7. Podkapitola 2.5, str. 39. 39 MODELOVÁNÍ A SIMULACE 40 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu 3 BUSINESS PROCESS MODELING NOTATION (BPMN) RYCHL Ý NÁHLED KAPITOL Y <@> \ Tato kapitola stručně představuje jednu z nej používanej šich modelovacích notací v oblasti analýzy podnikových procesu - Business Process Modeling Notation (BPMN). Tato notace je standardem v předmětné oblasti a využívá se při práci s řízením podnikových procesu i při jejich realizaci v podobě workflow. Obeznámíme se se základními skupinami grafických prvků BPMN a na konkrétních příkladech si vysvětlíme použití grafických symbolů v procesních modelech. Ukážeme si také příklady diagramů podnikových procesů. CÍLE KAPITOLY Po prostudování této kapitoly budete umět: • Charakterizovat notaci BPMN. • Vyjmenovat a objasnit využití skupin symbolů BPMN. KLÍČOVÁ SLOVA KAPITOLY BPMN, tokové objekty, BPD, aktivity, brány, artefakty, události, plavecké dráhy. Business Process Modeling Notation (BPMN) je grafickou notací. Konkrétněji je to soubor grafických objektů a pravidel, podle kterých mohou být objekty v podnikových procesech mezi sebou spojovány. Smyslem této notace je zachycení toku práce v rámci probíhajících podnikových procesů. Za vznikem této notace stojí iniciativa BPMI (Business Process Management Initiative), jejímž hlavním cílem bylo vytvořit komunikační prostředek, který bude srozumitelný pro všechny účastníky procesního řízení v organizaci, podniku nebo firmě. Konkrétně tedy pro účastníky procesu, technické vývojáře, business analytiky, analytiky, kteří monitorující procesy apod. Pomocí BPMN se zmenšila komunikační mezera mezi návrhem a implementací procesu a pro mnohé implementační nástroje se stala de facto standardem pro modelování podnikového procesu. Notace BPMN je jednoduchá na pochopení a používaní a zároveň nabízí možnost modelovat i komplexní podnikové pro­ cesy. 41 BUSINESS PROCESS MODELING NOTATION (BPMN) Df DEFINICE Business Process Modeling Notation je soubor principů a pravidel, který slouží pro grafické znázorňování podnikových procesů pomocí procesních diagramů. Jinak řečeno jde o standard pro modelování podnikových procesů. Do této domény také spadá převod mezi návrhem podnikových procesů a jejích implementací v jazyce pro spouštění procesů. Jedná se o ryze technickou problematiku, které se v tomto textu detailněji věnovat nebudeme. BPMN procesní modely určují logiku průběhu procesů, které se pak prostřednictví jednotlivých elementů převádějí do jazyka BPEL. To umožňuje manuální transformaci procesního modelu do spustitelné podoby v podobě workflow. Díky volnosti modelování v BPMN není možné udělat tento převod automaticky. Když některé nástroje tuto funkci nabízejí, je to za cenu určitých omezení při samotném modelování procesů. V současnosti je BPMN ve verzi 2.01 0 (vydaná v roku 2011). 3.1 Business Process Diagram (BPD) BPMN standard definuje jediný typ diagramu - Business Process Diagram (BPD). BPD diagram je tvořen sítí grafických objektů, které jsou tvořeny zejména aktivitami a diagram zobrazuje tok práce, resp. informací mezi nimi. Jednotlivé grafické objekty jsou od sebe odlišeny, což přispívá k přehlednosti diagramu. Tvary těchto objektů jsou jednoznačně dány a je nutné je dodržovat. Můžeme ovšem volit pro ně vlastní barvy, například z odlišovacích účelů u skupiny objektů stejného typu. V některých situacích lze použít v diagramu i vlastní grafický objekt, ten se však nesmí překrývat s žádným již existujícím a rovněž by neměl ovlivňovat samotný tok procesu. Měl by jej pouze upřesňovat, či poskytovat nějaké dodatečné informace. BPD diagramy jsou tvořené z jednoduchých elementů, které umožňují snadnou tvorbu procesních modelů. Tyto modely by pak měly být intuitivně pochopitelné většinou podnikových analytiků. Tvary elementů byly navrženy s ohledem na již používané nástroje v procesním modelování. Například aktivity se znázorňují pomocí čtyřúhelníku a rozhodnutí jsou značené diamantem. Při vývoji B P M N byl kladen důraz na to, aby pomocí něj bylo možné zachytit i komplexní podnikové procesy, které probíhají různými odděleními napříč podniky. Pro lepší zvládnutí těchto požadavků bylo navrženo několik kategorií elementů, které napomáhají snadnější orientaci v jejich základních druzích. V rámci každé ze základ- 1 0 Documents Associated With Business Process Model And Notation™ (BPMN™) Version 2.0 Release Date: January 2011. Object Management Group [online]. 2017 [cit. 2017-10-21]. Dostupne z: http://www.omg.Org/spec/BPMN/2.0/ 42 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu nich kategorií je možné upřesňovat definované elementy prostřednictvím rozšiřujících informací. Rozšíření nesmí narušit základní charakteristiky elementů, tím by snižovala jejich srozumitelnost. 3.1.1 SYMBOLY POUŽÍVANÉ V BPMN V BPMN existují čtyři základní kategorie grafických prvků: tokové objekty (Flow Objects), • spojovací objekty (Connecting Objects), • plavecké dráhy (Swimlanes), artefakty (Artefacts). Tokové objekty Do kategorie tokových objektů patří tři základní elementy. Jsou to (1) událost (event), (2) aktivita (activity) a (3) brána (gateway). Stručný popis těchto elementů a symboly jejich zapisuje zachycen v tabulce 3-1. Tabulka 3-1: Tokové objekty. U d á l o s t U d á l o s t j e z n á z o r n ě n á k r u h e m a r e p r e z e n t u j e n ě c o , c o s e d ě j e b ě h e m p o d n i k o v é h o p r o c e s u . E x i s t u j í t ř i t y p y u d á l o s t í - s t a r t , p ř e c h o d a k o n e c . o o o A k t i v i t a A k t i v i t a j e r e p r e z e n t o v a n á o b d é l n í k e m s e z a o b l e n ý m i r o h y a r e p r e z e n t u j e č i n n o s t , k t e r á j e v y k o n á v a n á p o d n i k e m . A k t i v i t a m ů ž e b ý t j e d n o d u c h á , n e b o s l o ž e n á . M ů ž e b ý t d v o u t y p ů - ú l o h a n e b o p o d p r o c e s . P o d p r o c e s j e n ě k d y o z n a č e n ý z n a m é n k e m p l u s v e s t ř e d u s p o d n í č a s t i o b d é l n í k u . Úloha j ( : í Podproces > B r á n a B r á n a j e z n á z o r ň o v a n á j a k o d i a m a n t a p o u ž í v á s e n a r e a l i z a c i v ě t v e n í p o d n i k o v é h o p r o c e s u a s p o j o v á n í s e k v e n č n í c h t o k ů . o Zdroj: vlastní zpracování Události ovlivňují tok procesu a běžně obsahují spouštěč (příčinu) anebo důsledek (výsledek). Definované j sou tři typy událostí. Na začátku procesního toku se umísťuje startovací událost (start), v průběhu procesu používáme mezilehlé (intermediate) události a procesní tok ukončujeme koncovými událostmi (end). Pro každou událost můžeme do kruhu 43 BUSINESS PROCESS MODELING NOTATION (BPMN) Události umístit symbol, který upřesňuje spouštěč nebo výsledek. V BPMN je definováno více podtypů událostí. Ne všechny podtypy se mohou používat s každým typem události. Na obrázku 3-1 jsou zobrazeny všechny podtypy událostí. Mezilehlými událostmi můžeme navázat na aktivity, čímž specifikujeme jejich alternativní ukončení. - např. výskyt chyby v průběhu procesu nebo vypršení času na průběh aktivity a jiné podle uvedeného seznamu. Podtypy událostí se liší pro startovací, přechodové a koncové události (zelená, oranžová a červená barva). Jedná se např. o tyto podtypy: Pravidlo (conditional evenť) - splnění uvedeného pravidla (např. kladný zůstatek peněz na účtu). Zpráva (message evenť) - přijetí zprávy od účastníka podnikového procesu. Různý (multiple evenť) - ke vzniku události dochází různými způsoby. Paralelně různý (parallel multiple evenť) - ke vzniku události dochází různými způsoby, navíc paralelně. Signál (signál evenť) - ke vzniku události dochází po obdržení signálu. Časovač (timer evenť) - načasování spuštění procesu po uplynutí určitého časového intervalu. O None Compensation event (D Conditional evert Error event Escalation event © Message event @ Multiple event © Parallel multiple event © Signal event ® Timer event O None •Cancel event ® Compensation event Conditional event None •Error event • Cancel event Escalation event © Compensation event © Link event •Error event Message event • Escalation event © Multiple event ft Message event Parallel multiple event ® Multiple event Signal event • Signal event Timer event ft Terminate event Aktivity Obrázek 3-1: Seznam podtypů událostí. Zdroj: vlastní zpracování Aktivita je označení pro činnost, která probíhá v podniku. Aktivita může být atomická anebo se může skládat z více úloh. Rozdělení a sloučení sekvenčního toku činností se v diagramu zabezpečuje bránou. Brána j e znázorněna jako diamant, v jehož středu jsou zobrazené zpřesňující symboly. Ty specifikují, o jaký typ větvení toku se jedná. Na výběr máme 44 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu rozhodovací a paralelní dělení, které je založené na vstupních datech anebo na vyskytnuté události (obr. 3-2). K těmto dělením jsou definovány odpovídající sloučení. BPMN standard definuje element brána jako datový XOR, událostně řízený XOR, OR, AND nebo jako komplexní bránu. Odpovídající symboly jednotlivých typů uvádí obrázek 3-2. Brána typu XOR se použije v situaci, kdy proces může pokračovat dvěma a více větvemi, z nichž ale pouze jedna bude při provádění procesu iniciována. BPMN rozlišuje dva typy XOR brány. Datová XOR brána provádí směrování toku procesu na základě B r á n y jeho dat. Výběr větve je proveden na základě vyhodnocení podmínky, která je spojena s elementem brány. Standard dovoluje také označit výchozí (defaultní) cestu, která se provede, pokud žádná jiná větev nesplňuje stanovenou podmínku. Událostně řízená XOR brána má odlišnou sémantiku, protože všechny potenciálně možné následující aktivity jsou povoleny a očekávají přijetí zprávy. Také v tomto případě je vybrána pouze jedna větev tím, že nakonec dorazí odpovídající zpráva. Brána typu OR dovoluje na základě dat procesu zvolit jednu nebo více větví, které se provedou. Brána typu AND vyjadřuje paralelní provedení aktivit všech přípustných větví a nakonec komplexní brána je využita pro složitější větvení popsané v připojeném výrazu v diagramu. O Gateway Complex gateway Event-based gateway Exclusive gateway Inclusive gateway Instantiating event-based gateway • Instantiating parallel event-based gateway Parallel gateway Obrázek 3-2: Typy rozhodnutí pro brány. Zdroj: vlastní zpracování Spojovací objekty Spojovací objekty (connecting objects) se v BPD asociují se záměrem vytvořit základní kostru struktury podnikového procesu. Existují tří spojovací objekty, které toto zajišťují. Jejich přehled a popis nabízí tabulka 3-2. Spojovací objekty usnadňují propojení a taktéž umožňují připojení tzv. artefaktů (viz text níže). Tabulka 3-2: Spojovací objekty. Sekvenční tok Sekvenční tok (sequence flow) je znázorněný plnou čárou, která je ukončena plnou šipkou. Zobrazuje pořadí, v jakém se v procesu vykonávají aktivity. Sekvenční tok Sekvenční tok (sequence flow) je znázorněný plnou čárou, která je ukončena plnou šipkou. Zobrazuje pořadí, v jakém se v procesu vykonávají aktivity. 45 BUSINESS PROCESS MODELING NOTATION (BPMN) Tok zpráv Tok zpráv (message flow) se označuje přerušovanou čárou, která je ukončena prázdnou šipkou. Používá se na zobrazení toku zpráv mezi dvěma různými účastníky procesu, kteří posílají a přijímají tyto zprávy. Účastníky mohou být např. dva různé bloky ipools). C [> Asociace Asociace {association) je znázorněna tečkovanou čárou, která je ukončena šipkou a používá se na spojení dat, textu a jiných artefaktů s neukotvenými objekty. Asociace zobrazují vstupy a výstupy aktivit. i i i i i i i i • i i i i i • i • Zdroj: vlastní zpracování Plavecké dráhy Plavecké dráhy (swimlanes) j sou použité i v dalších metodologiích modelovaní procesů (např. U M L diagramy aktivit) jako pomůcka na organizování aktivit do vizuálně oddělených celků s cílem ilustrovat různou funkci těchto celků (např. různé oddělení v podniku). Notace BPMN podporuje dva typy smerodajných čar. Tabulka 3-3: Plavecké dráhy. Blok Blok (pool) reprezentuje účastníka v podnikovém procesu. Je taktéž grafickým kontejnerem pro rozklad skupiny aktivit z j iných bloků, např. v kontextu B 2 B 1 1 (Business-to-Business) situace. Dráha Dráha (lane) je častí bloku, která se táhne po jeho celé délce horizontálně nebo vertikálně. Používá se na organizování a třídění aktivit. Zdroj: vlastní zpracování Pool ohraničuje podnikový proces a graficky vymezuje jeho hranice. V rámci jednoho poolu se vyskytuje jenom jeden podnikový proces. Interakce mezi pooly je zajišťována pomocí zasílání zpráv. Pooly se v BPD využívají k dokumentaci dvou nebo více oddělených podnikových entit anebo účastníků procesů. Aktivity každého účastníka jsou uzavřené v jeho vlastním poolu, čím je specifikováno jeho jasné ohraničení. Předmětný pod- 1 1 Business-to-business (B2B) je označení pro obchodní vztahy mezi obchodními společnostmi. Významnou vlastnosti modelu B2B je větší důraz na logistiku a zajištění samotného obchodu, oproti důrazu na získání zákazníka, jako je tomu v případě konceptu B2C. Paradigma B2B je nejstarší složkou elektronického podnikání (e-business). 46 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu nikový proces nemůže spolupracovat s okolními procesy pomocí sekvenčních toků. K spolupráci mezi dvěma pooly se používá mechanizmus zasílání zpráv. Zprávy naopak není možné použit v rámci jednoho poolu. Na obrázku 3-3 dráha rozděluje pool na menší části po celé jeho délce. Slouží na smysluplné uspořádání aktivit. Může znázorňovat oddělení, role nebo funkce podniku. Komunikace mezi jednotlivými dráhami může probíhat pomocí sekvenčních toků. Toky zpráv se však nesmí používat na komunikaci mezi tokovými objekty v dráhách jednoho poolu, jak bylo uvedeno výše. Artefakty Notace BPMN byla navržena tak, aby měli odborní pracovníci - modeláři a také různé modelovací nástroje volnou ruku v rozšiřování prvků základní notace a při zachycení dalších souvislostí, které mohou být potřebné ve specifické situaci. Proto může být do diagramů doplněné libovolné množství tzv. artefaktů, které jsou vhodné v kontextu modelovaných podnikových procesů. Současná verze notace BPMN má předdefinované tři typy artefaktů (tab. 3-4). Kromě toho je možné navrhnou a používat vlastní typy artefaktů, které upřesňují průběh podnikového procesu. Tabulka 3-4: Artefakty. Datový objekt Datové objekty {data objects) znázorňují, jaká data jsou požadovaná a produkovaná aktivitami. K aktivitám se připojují pomocí asociací. Name [State] Skupina Skupina (group) je znázorněna obdélníkem se zaoblenými rohy zachycena tečko-čárkovanou čárou. Používá se na analytické nebo dokumentační účely. Nemá vliv na sekvenční tok. r i 1 i J Anotace Anotace (annotation) poskytují účastníkům diagramu doplňující textové informace. Text Annotation Allows a Motteler to provide additional Information Zdroj: vlastní zpracování Datový objekt slouží na znázornění toku dat v podnikovém procesu. Pomocí něho modelujeme, jaká data jsou požadována v průběhu procesu a jaká data systém produkuje na výstupu. Datový objekt j e k aktivitám připojený pomocí tzv. asociace. Graficky je reprezentovaný obdélníkem s ohnutým rohem. Skupina je znázorňovaná přerušovaným obdélníkem a používá se na analytické a dokumentační účely. Business analytik ji může použít na zpřehlednění diagramů, vytvořením skupin, které slučující související podnikové procesy. Vytvořené skupiny neovlivňují tok podnikového procesu. Anotace může tvůrce diagramu využít na zachycení dodatečné textové informace. Anotace zvyšuje názornost procesního modelu a poskytuje vysvětlující textovou informaci o 47 BUSINESS PROCESS MODELING NOTATION (BPMN) elementech, které se vyskytují v diagramech. Anotace je k objektu připojená pomocí aso­ ciace. Objednávka z baz 0 objednávam si zboží Příjem fa litiny J faktura U hrazení faktury Příjem z boč í faktura uhrazena ; zboží odesláno Příjem objednávky l ) Vysta vení faktury Overení platby T T -L L. HEM *Kontrola účtu Obrázek 3-3: Příklad využití bloku a dráhy. Zdroj: vlastní zpracování 3.2 Využití BPMN Pomoci BPMN je možné modelovat podnikové procesy na různých úrovních. Přesněji, od detailního popisu jednotlivých dílčích podnikových procesů až ke globální orchestraci procesů, které se můžou jevit jako černá skřínka1 2 (blackbox). Notace BPMN tím může oslovit různorodé publikum, kterému podává širší spektrum informací na různých úrovních detailů. Podle míry záběru modelovaných podnikových procesů se BPD člení do dvou základních skupin: Interní podnikové procesy - jsou znázorněné v hierarchii diagramů (více kapitola 4.3). Nejvyšší úroveň obsahuje hlavní podnikový proces v podniku (někdy se označuje jako klíčový), který je prostřednictvím podprocesů podrobně specifikovaný. Nej nižší úroveň podrobně modeluje všechny aktivity, které v procesu probíhají. Příkladem procesu vysoké úrovně je obrázek 3-4. Diagram se skládá z podprocesů, které reprezentují nižší úrovně. Rozbalením některého z podprocesů je možno získat podrobný diagram jeho průběhu. Kooperativní mezipodnikové procesy - kooperativní typ diagramu znázorňuje mezipodnikové procesy (Business to Business - B2B). Jeho hlavním cílem je 1 2 V programování jsou černé skříňky objekty, které mají pevně definované rozhraní, a jejich vnitřek je uk­ ryt. 48 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu zachycení vztahů mezi dvěma a více podnikovými procesy. Důraz je kladen na modelování vzájemné komunikace. Proces přijetí objednávky -> Přijetí objednávky — Analýza objednávky | Obja + Vystavení Ověření faktury úhrady -i Odešlá ní zboži Obrázek 3-4: Interní podnikový proces vysoké úrovně. Zdroj: vlastní zpracování Modelování podnikových procesů je disciplínou, která se používá hlavně v BPR (Business Process Reengineering). BPRje procesní přístup, kterého cílem je optimalizovat podnikové procesy tak, aby přinášely maximální efekt při minimální spotřebě podnikových zdrojů. Výsledkem BPR aktivit je řada podstatných změn v podnikových procesech, které jsou doprovázeny i změnami v organizační a kvalifikační struktuře podniku, a také ve způsobech organizace práce a řízení. Další z přístupů, se kterými se potkáváme v této oblasti je BPI (Business Process Improvemenť). BPI je systematický přístup, kterého snahou je pomoci podniku najít a optimalizovat její klíčové procesy tak, aby byly ve výsledku efektivnější. Notace BPMN se v obou přístupech používá jako základní technika analýzy a popisu aktivit v rámci podnikového procesu. Dále se využívá k reakci na události a tím vlastně ke komplexnímu ovlivnění chování podniku. Díky vytvořeným procesním modelům je posléze jednoduší provádět optimalizace. Informace na okraj - na popisu podnikových procesuje založena například certifikace ISO 9001. Z pohledu více informatického je nej důležitějším důvodem modelování podnikových procesů situace, kdy chce podnik zavést informační systém (IS). Procesní modely v tomto případě slouží k pochopení, jaké funkcionality má IS pokrývat pro podporu dotčených podnikových procesů. Funkce nového IS přímo vyplývají z toho, jak firma vlastně funguje, jaký business provozuje, v jakém prostředí, s jakými událostmi se potýká, s jakými daty se pracuje, jaké firemní pravidla tam platí a jaké podnikové procesy realizuje. Na druhé straně se modely podnikových procesů používají např. u softwarových dodavatelů k pochopení zadání, a slouží jako podklad pro různé investiční záměry - hlavně v oblasti podpory a automatizace procesů a jsou důležitou součástí dokumentace IS. IS je pouze nástrojem, který by měl podporovat podnikové procesy. Cílem je správně fungující a prosperující podnik. OTÁZKY 1. K čemu se notace BPMN využívá a jaký základní diagram používá? 2. Jaké základní kategorie prvků obsahuje notace BPMN? 49 BUSINESS PROCESS MODELING NOTATION (BPMN) 3. Vyj menujte tokové obj ekty v notaci BPMN. 4. Jaké jsou důvody modelování podnikových procesů z podnikového a informatického pohledu? SHRNUTÍ KAPITOLY Tato kapitola se stručně věnovala představení notace pro modelování podnikových procesů - BPMN. Objasnili jsme základní BPD (Business Process Diagram) notace, dále pak základní kategorie grafických prvků v BPMN a symboly, které notace používá. Na příkladech jsme dokumentovali tokové a spojovací objekty, plavecké dráhy a artefakty. V závěru kapitoly jsme popsali důvody pro modelování podnikových procesů a vysvětlili jeho přínos pro návrh funkcionalit informačních systémů v podnicích. ODPOVĚDI 1. Kapitola 3 a podkapitola 3.1, str. 39 a 40. 2. Podkapitola 3.1.1. 3. Podkapitola 3.1.1, str. 42. 4. Podkapitola 3.2, str. 47 a 48. 50 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu 4 ŘÍZENÍ PODNIKOVÝCH PROCESŮ (BPM) RÝCHLYNAHLED KAPITOLY Tato kapitola představuje v úvodu příklady podnikových procesu jako např. objednávka-hotovost, nabídka-objednávka a žádost-schválení. Jádrem kapitoly je popis životního cyklu řízení podnikových procesu (BPM) a jeho jednotlivých fází - identifikace, objevování, analýza, redesign, implementace a monitorování podnikových procesu. Při popisu typů procesů, simulace a automatizace podnikových procesů bude čtenář odkázán na předešlé kapitoly této opory. Závěrem získáte ucelený pohled na životní cyklus podnikového procesu s podporou ICT v podobě automatizovaného procesu. CÍLE KAPITOLY Po prostudování této kapitoly budete umět: • Uvést příklady podnikových procesů. • Popsat životní cyklus řízení podnikových procesů a jeho jednotlivé fáze. KLICOVA SLOVA KAPITOLY Řízení, podnikový proces, BPM, discovery, implementace, automatizace, BPMS. 4.1 Příklady podnikových procesů Každý podnik bez ohledu na jeho typ nebo formu musí řídit celou řadu procesů. Mezi typické podnikové procesy, které se vyskytují ve většině podniků, bezesporu patří napří­ klad: • Objednávka-hotovost (order-to-cash process) - tento typ podnikového procesu začíná u dodavatele zboží nebo služeb. Je realizovaný tehdy, když zákazník potvrdí nákup a je ukončený tehdy, když zákazník objednané zboží nebo službu dostane a za dodávku zaplatí. Tento podnikový proces souvisí s aktivitami, které pokrývají ověření nákupní objednávky (purchase order), odeslání zásilky, dodání zásilky, fakturace, platba za zásilku, a nakonec ověření platby. 51 ŘÍZENÍ PODNIKOVÝCH PROCESŮ (BPM) • Nabídka-objednávka (quote-to-order process) - tento typ podnikového procesu běžně předchází procesu order-to-cash. Podnikový proces začíná v okamžiku, když dodavatel dostane od zákazníka tzv. požadavek na nabídku (RFQ, Request for Quote) a končí tehdy, když zákazník potvrdí objednávku, která je založená na přijaté nabídce. Na tento proces navazuje order-to-cash a společně vytvářejí kombinovaný podnikový proces nabídka-hotovost (quote-to-cash). • Žádost-schválení (application-to-approval) - tento typ procesu začíná v případě, že někdo v podniku žádá např. o udělení mimořádné odměny za práci nad rámec běžných pracovních povinností, o povolení k zahraniční pracovní cestě nebo o vyplacení benefitu apod. Je to poměrně běžný proces ve vládních a veřejných institucích. Mezi další příklady patří např. žádost o dotaci, proplacení nákladů za poplatky, nebo přijímací řízení na vysoké škole apod. Mezi další typické podnikové procesy patří např. nákup-platba (procure-to-pay) nebo problém-řešení (issue-to-resolution). Způsob, jakým jsou podnikové procesy navrženy a následně prováděny v podnicích, ovlivňuje kvalita služeb, kterou vnímá koncový zákazník a efektivnost, s kterou jsou služby dodávaný. V případě, že podnik dokáže tyto podnikové procesy zabezpečovat efektivněji než konkurence, může je realizovat i komerčně, jako službu nabízenou dalším firmám. Každý podnikový proces obsahuje kromě dříve zmiňovaných událostí, aktivit, úloh a rozhodovacích bodů i aktéry, kterými jsou pracovníci, podniky, informační systémy, hmotné (prototypy, materiál, zboží, polotovary atd.) a nehmotné objekty (elektronické záznamy). Provedení podnikového procesu by mělo vést k jednomu nebo více výstupům a v ideálním případě by měl taktéž přinést přidanou hodnotu všem jeho aktérům. V takovém případě označujeme výstup podnikového procesu jako pozitivní. V případě, že podnikový proces nepřináší žádnou přidanou hodnotu aktérům, označujeme jeho výstup za negativní. Mezi všemi aktéry podnikových procesuje nej důležitější zákazník, kterým může být zaměstnanec daného podniku (interní zákazník) nebo to může být externí zákazník mimo daný podnik. 4.2 Životní cyklus BPM Řízení podnikových procesů (BPM, Business Process Management) je vědeckou disciplínou, která se zabývá způsoby, jakými je v podnicích vykonávaná práce pro zajištění konzistentních výstupů. B P M se zaměřuje na výhody, které přinášejí příležitosti pro zlepšení postupů, jakými jsou práce, a hlavně podnikové procesy prováděny. V tomto kontextu může mít slovo „zlepšení" různý význam podle toho, co je cílem podniku. Typickým příkladem zlepšování jsou například redukce chybných výrobků a výsledků, snižování nákladů na výrobu a provoz nebo optimalizace pracovního času. Tyto snahy o zlepšení mohou být jednorázového charakteru nebo mohou v podnicích probíhat kontinuálně. 52 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu B P M není jenom o způsobu, jakým jsou aktivity nebo činnosti vykonávány, ale hlavně o řízení celého komplexu činností, rozhodnutí a událostí, které se označují jako podnikové procesy (viz kapitola 1). Každá společnost, organizace, nebo podnik má podnikové procesy, které musí řídit, jak j sme uvedli na začátku této kapitoly. Porozumění těmto procesům a jejich řízení je klíčovým faktorem pro zajištění konkurenceschopnosti a efektivnosti podniků. Pomocí orientace na procesy (procesní řízení) podniky řídí ty aktiva, které jsou nej důležitější, aby měly pozitivní dopad na zákazníka. B P M je kolekcí metod, principů a nástrojů pro analýzu, návrh, exekuci a monitorování těchto podnikových procesů. Jako základ pro řízení podnikových procesů se používají procesní modely a metriky procesního výkonu. Hlavní myšlenky a přístupy, které jsou použity v této kapitole, jsou založené na referenční publikaci Dumase et al. (2013). První otázku, kterou by si měl každý podnik na začátku jakékoliv B P M aktivity položit je, jaké podnikové procesy chce zlepšit. Před samotným započetím o úvahách nad startem BPM aktivity pravděpodobně v podniku existovali nějaké problémy v operativě a účastnící by měli mít představu, jakých podnikových procesů se to týká. Jestli např. manažer logistiky ve firmě vidí, že se mu hromadí dodávky na skladě a přepravce je nestíhá distribuovat, je zřejmé, že se problémy týkají externího dodavatele a v první řadě by se mělo určit, kde daný podnikový proces začíná a kde končí, jestli se jedná o stejného dodavatele logistických služeb, nebo konkrétního zboží apod. Tyto otázky souvisejí se zkušenostmi podniku s procesním řízením v minulosti. Kdyby se jimi podnik již zabýval, je pravděpodobné, že by měl vytvořený seznam podnikových procesů a alespoň částečně definován jejich rozsah. V podnicích, které se B P M aktivitami doposud nezabývali, musí B P M tým v první řadě identifikovat problematické podnikové procesy, určitjejich rozsah a vztahy mezi nimi. Táto počáteční fáze B P M činnosti se nazývá identifikace procesů (process identification). Tato fáze vede k vytvoření tzv. procesní architektury {process architecture), která je obvykle reprezentovaná kolekci podnikových procesů různého druhu a vztahy mezi nimi. Obecným pravidlem B P M činnosti je, aby analyzované podnikové procesy vedly ke konzistentním pozitivním výstupům a aby přinášeli přidanou hodnotu podniku nebo organizaci především ve vztahu k zákazníkům. Měření této hodnoty je klíčovým prvkem B P M aktivity. Není možné něco řídit nebo kontrolovat, když to neumíme měřit. Před detailní analýzou podnikových procesuje nutné stanovit si metriky procesního výkonu {process performance metrics). Tyto procesní metriky budou určovat stav procesu. Konkrétní typy metrik mohou souviset s náklady např. režijní náklady, mzdy, externí služby, poplatky apod. Další typy metrik mohou být vázané na čas, např. průměrný čas, který uplyne při vyřizování reklamace. Tato metrika se obecně označuje jako cyklický čas (cycle time). Třetí typ metrik se týká kvality, např. chybovost (error rate). Chybovost je percentuálně podíl neúspěšně ukončených instancí procesu z celkového počtu instancí. Může to být například celkový podíl nedoručených zásilek z důvodu nesprávně vyplněné adresy zákazníka. Je zřejmé, že podnik by se měl snažit takové chybovosti vyvarovat a minimalizovat ji. Identifikace metrik procesního výkonu a výkonnostních cílů je obecně součástí identifikační fáze B P M činnosti i když je možněji v některých případech posunout do fází pozdějších. 53 ŘÍZENÍ PODNIKOVÝCH PROCESŮ (BPM) Objevo- p 0 identifikaci předmětných podnikových procesů a určení metrik procesního výkonu vání pro- o o cesó je další fází B P M aktivity pochopení detailu podnikových procesu. Tato fáze se označuje objevování procesů (process discovery). Hlavním výstupem této fáze je jeden nebo více procesních modelů, které zachycují současný skutečný stav procesů, jedná se o tzv. as-is procesní modely. As-is procesní modely znázorňují myšlení lidí v podniku o tom, jakým způsobem je vykonávaná jejich rutinní pracovní náplň. Tyto procesní modely by měli být jednoduše pochopitelné a měli by se využívat při komunikaci mezi členy B P M týmu. Podnikové procesy je možné modelovat např. pomocí přirozeného jazyka ve formě psaného textu. Jenomže takovýto charakter popisu často vede k mylné interpretaci, a proto se při modelování běžně používají diagramy. Diagramy umožňují jednoduchým způsobem zachytit průběh podnikových procesů. V případě, že se při tvorbě diagramů bude využívat nějaká konkrétní notace modelování podnikových procesů (např. BPMN v kapitole 3), která je snadno pochopitelná pro všechny členy procesního týmu, tak prostor pro nedorozumění je minimální. Také v tomto případě se může použít forma textového popisu. Dokonce kombinace diagramů a textu se jeví jako nejvhodnější. Po detailním pochopení as-is podnikových procesuje další fází B P M činnosti identifikace a analýza problémů v těchto procesech. Jedním z potenciálních problémů procesu vyskladnení zásilek může být příliš vysoký cyklický čas. Toto může způsobovat různá zpoždění v úlohách, které se musí splnit při dodávkách zboží zákazníkům. Pro analýzu takového problému potřebuje analytik dostat informace o časech, které konkrétní pracovník strávil přímo svou prací na jednotlivých rutinních úkolech a časech, kdy čekal na výsledky práce někoho jiného (idle time). Tento čas se nazývá čekací čas (waiting time). Analytik potřebuje také informace ohledně množství opakované práce (rework) v podnikovém procesu. Opakovaná práce znamená, že se jedna nebo více úloh opakuje, protože se v podnikovém procesu něco nepovedlo. Procesní analytik by v podobných případech potřeboval vědět, v kolika (procentuálně) případech k tomuto dochází. Jestliže analytik tuto informaci má, může využít různé B P M techniky pro identifikaci příčin vysokého cyklického času a při určení změn, které se musí v podnikovém procesu realizovat pro jeho snížení. Analýza Další problémy, s kterými by měl být procesní analytik obeznámen, se týkají případů, procesů kdy instance procesů končí negativním výstupem. To znamená, že se v podnikovém procesu něco nepovede, např. faktura se nevystaví, objednávka nebude vybavená apod. Při analýze takového typu problému musí procesní analytik identifikovat, jak často k těmto negativním výstupům dochází, ale hlavně proč k nim dochází. Častým důvodem bývá nedorozumění v komunikaci mezi účastníky podnikového procesu, chybami, které jsou způsobené daty (nesprávné podkladové materiály apod.). Identifikaci, klasifikaci a detailním pochopením příčin negativních výstupů může procesní analytik naleznout řešení problému v podnikovém procesu. Identifikace a diagnostika problémů a příležitostí na zlepšení podnikových procesů se označuje jako analýza procesu (process anály sis). Po analýze a případné kvantifikaci problémů v podnikových procesech začíná další fáze životního cyklu B P M - identifikace a analýza potenciálních změn problémů. Procesní analytik v této fázi přemýšlí nad možnostmi jak problémy, které byli identifikovány, vyřešit. 54 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu Redesign procesů Musí myslet na to, že jakékoliv změny, které by vyřešili jeden problém, mohou vést ke vzniku dalších problémů. Například při řešení problému s plným skladem by mohlo dojít k záměně balíčků a nesprávnému doručení koncovému zákazníkovi. To by mohlo ve svém důsledku vést k vyšší míře negativních výstupů vyskladňování. Změna podnikového procesu není nikdy j ednoduchá. Lidi j sou navyklí pracovat určitým způsobem a každou změnu vnímají negativně. Často se změny v podnikových procesech týkají taky změn v IS podniku, který se používá při vykonávání příslušného podnikového procesu. Taková změna bývá často finančně náročná a může se krom předmětného podniku nebo organizaci týkat taky např. dodavatelů nebo odběratelů. Analytik, který má informace o jednom nebo více problémech v podnikovém procesu může navrhnout jeho redesign (znovu navržení) - jeho novou verzi, která řeší identifikované problémy v as-is procesním modelu. Vzniká nová verze podnikového procesu, která se označuje jako to-be procesní model, tj. vylepšená verze skutečnosti. To-be podnikový proces je hlavním výstupem další fáze životního cyklu BPM. Důležitou charakteristikou této fáze je, že redesign a analýza bývají přepojené, protože analytik musí mít k dispozici dostatek analytických informací při výběru nejlepší redesignové možnosti. Po znovu navržení podnikového procesu a vytvoření to-be procesního modeluje nutné |m P/ e m e n navržené změny práce a změny v IS i realizovat. Tato fáze se nazývá implementace pro- Cesů cesu (process implementation). Obecně se implementace procesů skládá ze dvou vzájemně se doplňujících oblastí - organizační change management (organizational change management) a automatizace procesů {process automation). Organizační change management se týká všech činností, které j sou potřebné pro změnu způsobu práce všech účastníků podnikového procesu. Tyto činnosti zahrnují: Vytvoření plánu change managementu, který bude všechny zúčastněné strany informovat, kdy a jaké změny nastanou a jaká přechodná opatření nastanou, aby bylo možné se vyhnout problémům při přechodu na to-be procesy. Vysvětlení přínosů zaváděných změn pro podnik nebo organizaci. Skolení uživatelů na nový způsob práce a monitorování změn pro zajištění hladkého přechodu na to-be procesy. Automatizace podnikových procesů sestává z nastavení nebo implementace ITC systému pro podporu to-be procesů. Tento systém by měl sloužit pro podporu vykonávání jednotlivých kroků podnikového procesu jeho účastníky. Účastníkům procesu jsou přiřazeny úlohy; jsou jim poskytovány informace, které potřebují při plnění úloh; jejím poskytována pomoc při stanovení priorit při výkonu práce; mají k dispozici automatizovanou kontrolu práce a výstupů s cílem implementovat co nejvíce automatizovaných úloh. Po realizaci to-be podnikových procesů nastává fáze, kdy je potřebné vyhodnotit jejich Monitoring a kontrola fungování a implementovat změny těch částí procesů, které nesplňují očekávání. Proto by procesů měl být podnikový proces průběžně monitorován a monitorovací data by měli být průběžně 55 ŘÍZENÍ PODNIKOVÝCH PROCESŮ (BPM) analyzována pro identifikaci nedostatků a pro lepší průběh podnikových procesů. Tyto činnosti zajišťuje monitoring a kontrola procesu {process monitoring and controlling) jako další fáze B P M životního cyklu. Řízení podnikového procesu vyžaduje neustálou kontrolu, protože jeho nedostatek způsobuje pokles jeho výkonu, případně až degradaci. Podnikový proces se musí neustále přizpůsobovat technologiím, konkurenci a především požadavkům zákazníků. To je důvod, proč jsou všechny fáze životního cyklu B P M realizovány v kruhu (obr. 4-1). Monitoring a kontrola procesů se vrací zpět na začátek životního cyklu B P M k objevování a analýze podnikového procesu. Kontrola shody a výkonnost procesu Identifikace procesů Procesní architektura Objevování procesů -is model Monitorování a kontrola procesů Analýza procesů II Spustitelný procesní model Implementace procesů Redesign procesů Slabé stránky procesu To-be model Obrázek 4-1: Interní podnikový proces vysoké úrovně. Zdroj: upravené podle Dumase et al. (2013). Životní cyklus B P M pomáhá pochopit význam technologií v procesním řízení. Klíčovou technologií procesního řízení je ICT. Systémoví inženýři, kteří zastupují ICT v B P M činnosti podniku nebo organizace jsou součástí většího celku. Jestli chceme z B P M využít maximum musí být členy B P M týmu kromě systémových analytiků také procesní analytici, kteří chápou příslušnou business doménu a dokážou využít synergický efekt znalostí z obou světů. BPM projekt má interdisciplinární charakter a spolupracují na něm manažeři různých organizačních úrovní podniku nebo organizace, dále běžní a administrativní pracovníci, analytici (systémoví, procesní, business) a celé ICT týmy. 56 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu 4.3 Identifikace procesů DEFINICE Identifikace procesů začíná s výskytem business problému/ů. Podnikové procesy, které se spojují s daným problémem, jsou identifikovány, je určen jejich rozsah a vztahy mezi nimi. Výstupem této fáze B P M je revidovaná nebo nová procesní architektura, která znázorňuje celkový pohled na všechny participující podnikové procesy a jejich vzájemné vztahy v podniku nebo v organizaci. Paralelně se někdy s těmito činnostmi identifikují také procesní metriky výkonnosti. Procesní architektura slouží jako framework pro definici rozsahu a priorit procesního modelování a celého B P M projektu. V této podkapitole jsou stručně popsané metody, které se využívají při identifikaci podnikových procesů ve dvou etapách - označovací {designation) a vyhodnocovací {evaluation). Označovací etapa se zabývá definici počátečního seznamu podnikových procesů. Vyhodnocovací etapa má za úkol najít vhodná kritéria po definici priorit těchto procesů. Výstupy obou etap jsou následné využity u tvorby procesní architektury. 4.3.1 OZNAČOVACÍ ETAPA Jestli je podnik jenom na začátku přechodu na procesně orientovaný, první jejich aktivitou je správné označení všech probíhajících podnikových procesů. Základním problémem je hierarchicky charakter podnikových procesů a určení toho, co tvoří jeden nezávislý podnikový proces a které jeho části jsou považované za součástí jiného podnikového procesu. Rozdělení podnikových procesů jsme se věnovali v kapitole 1.2 tohoto textu. Myšlenkou procesního řízení j e aktivně řídit podnikové procesy v organizaci a tím uspokoj ovat potřeby zákazníků. Když označíme procesy, které jsou příliš rozsáhlé, tak bude velice obtížné je řídit ve smyslu rychlosti akce a jejich rozsahu. Některé procesy mohou být příliš komplexní ajejich odstavení by mohlo způsobit ochromení činnosti podniku nebo organizace. Proto by měl být počet a rozsah označených procesů pro B P M aktivity kompromisem mezi dopadem a schopností tyto podnikové procesy řídit. V případě velkých diverzifikovaných podniků je obvyklé identifikovat stovky podnikových procesů. V případě menších podniků jsou to desítky procesů. V této fázi B P M činnosti nejde zúčastněným stranám o přesnou specifikaci procesů a jejich vzájemných vztahů, ale v první řadě o jejich pochopení a seznámení se se situací ohledně jejich rozsahu, propojení a výkonnosti. V této aktivitě jsou přínosné referenční procesní modely. 57 ŘÍZENÍ PODNIKOVÝCH PROCESŮ (BPM) 4.3.2 VYHODNOCOVACÍ ETAPA Pro vyjádření důležitosti podnikových procesů se používají různá kritéria. Mezi nejpoužívanější patří: • Důležitost (Importance) - posuzuje se strategický přínos každého podnikového procesu. B P M aktivita by se měla soustředit na ty podnikové procesy, které mají největší vliv na dosahování strategických cílů podniku nebo organizace. • Disfunkce (Dysfunction) - posuzuje se kondice každého podnikového procesu. Procesy s největšími problémy by měli mít největší přínos z hlediska přínosů BPM aktivity. • Proveditelnost (Feasibility) - posuzuj e se do j aké míry j e každý podnikový proces citlivý na aktivity procesního řízení. Obecné platí, že jestli se předmětné podnikové procesy týkají politických nebo kulturních aspektů, tak se stávají překážkou procesního řízení. Procesní řízení by se mělo soustředit především na takové procesy, od kterých je možné očekávat přínosy. Maturity pfj posuzování těchto kritérií se předpokládá, že máme k tomu dostatek informací. Podnik nebo organizace musí mít jasno, jaké je jejich strategické směřování a to alespoň na abstraktní úrovni. Více podniků považuje za strategické např. schopnost změnit sortiment nabízeného zboží v situaci, kdy zákazníci změní preference. Při posuzování disfunkcí podnikových procesuje důležité, aby podnik byl schopen kvantitativně vyhodnotit výkonnost jednotlivých podnikových procesů. U kvalitativního posouzení podnikových procesuje to snadnější. Další informace o disfunkci podnikových procesů můžeme získat od zákazníků např. pomocí dotazníků. V oblasti proveditelnosti je už celkem běžnou praxí, že podniky procházejí různými programy na zlepšení výkonnosti v různých dimenzích (např. telekomunikace, ICT, technologie obecně, apod.). Když se změny realizují příliš často, stává se, že management společnosti, ale i běžní zaměstnanci reagují negativně na časté programy zlepšování. U procesního řízení je důležitý pozitivní postoj vrcholného managementu podniku. Sofistikovanější přístup k vyhodnocovací fázi je založený na vyspělosti (maturity) podniku. PRO ZÁJEMCE Nej známějším frameworkom na vyhodnocení vyspělosti procesního řízení je Capability Maturity Model Integrated (CMMI). Rozsah procesních oblastí a stupeň jejich podpory určuje vyspělost podniku na pěti CMMI úrovních (obr. 4-2): • Úroveň 1 (Initial) - procesy v podniku běží náhodně a bez jasné definice. Neexistuje jejich kontrola. • Úroveň 2 (Managed) - v podniku probíhá plánování, monitorování a kontrola projektů. Jsou nasazeny analýza a metriky. 58 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu • Úroveň 3 (Defined) - procesy j sou definovány a společnost nabízí školení účastníkům procesů, aby byli schopní se podílet na analýze a dokumentování podnikových procesů. • Úroveň 4 (Quantitatively managed) - výkonnost procesů v podniku je sledována. Využívají se kvantitativní techniky. • Úroveň 5 (Optimizing) - funguje management výkonnosti procesů s analýzou příčin a následků (causal analysis and resolution). Obrázek 4-2: CMMI. Zdroj: vlastní zpracování 4.3.3 PROCESNÍ ARCHITEKTURA Procesní architektura je konceptuálni model, který znázorňuje procesy v podnikua explicitně stanovuje vztahy mezi nimi. Tyto vztahy jsou definované v obou směrech. Procesy mohou být ve vztahu konzument-producent - jeden proces produkuje výstup, který je zároveň vstupem do druhého procesu. Procesní architektura definuje různé úrovně detailů (obr. 4-3). 59 ŘÍZENÍ PODNIKOVÝCH PROCESŮ (BPM) Obrázek 4-3: Procesní architektura. Zdroj: upravené podle Dumase et al. (2013). Část procesní architektury, která reprezentuje úroveň 1, se nazývá procesní mapa (process landscape model). Znázorňuje hlavní podnikové procesy na velice abstraktní úrovni. Každá z částí procesní mapy odkazuje na konkrétní podnikový proces na úrovni 2 procesní architektury. Tato úroveň znázorňuje procesy najemnější úrovni granularity, ale pořád abstraktním způsobem. Každá část abstraktních procesních modelů na úrovni 2 odkazuje na detailní procesní modely úrovně 3. Detailní procesní modely obsahují všechny detaily procesů jako je předávání aktivity (control flow), účastníky podnikových procesů, datové vstupy a výstupy. Pro definici procesní architektury se využívají různé přístupy, jako např. přes typy případů {čase types) a business funkce (business functions). Případy představují běžné situace, se kterými podnik pracuje. Je to produkt nebo služba, kterou podnik nabízí zákazníkům a klasifikuje ho na základě mnohých parametrů, např. typ (spotřební zboží, stroj, software, apod.) nebo komunikační kanál (např. Internet, telefon, e-mail, apod.). Funkce je jednoduše řečeno to, co podnik dělá např. prodej, výroba, distribuce, apod. Pro vytvoření procesní architektury se doporučuje postupovat systematicky: 1. Identifikovat typy případů (typ produktu, typ služby, kanál a typ zákazníka). 2. Identifikovat funkce pro typy případů (např. pomocí řízených rozhovorů se zaměstnanci se zaměřením na funkce jednotlivých oddělení). 3. Navrhnout případově-funkční matici (různé funkce podniku pro různé typy zá­ kazníků). 4. Identifikovat procesy. 60 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu 4.4 Objevování procesů DEFINICE Objevování procesů neboli as-is procesní modelování dokumentuje současný stav všech relevantních podnikových procesů. Výstupem této fáze B P M činnosti je jeden nebo několik as-is procesních modelů. Důležitou částí této aktivity je sběr dostatečného množství informací o skutečném stavu procesů. Vyhledávání informací o podnikových procesech je časově náročnou aktivitou a vyžaduje nastavení způsobů, jakým budeme informace efektivně sbírat. Pro vyřešení těchto problémů popíšeme nyní čtyři kroky objevování podnikových procesů: 1. Definovat nastavení - výběr a sestavení týmu, který bude pracovat na podnikovém procesu. 2. Sběr informací - pochopení podnikového procesu s využitím různých exploračních metod pro sběr informací o podnikovém procesu. 3. Modelování - organizace aktivit, potřebných pro vytvoření modelu s využitím mapování procesu systémovým způsobem. 4. Zajištění kvality procesního modelu - výsledný procesní model musí plnit nastavené kritéria kvality pro dosažení důvěry v procesní model. Za analýzu a modelování podnikového procesu běžně odpovídá procesní analytik, který často není obeznámen se všemi detaily procesu. Pro získání dostatečných informací o podnikovém procesu se využívají doménoví experti, kteří zastřešují informace z různých perspektiv podnikových procesů. Nejčastěji se doménovým expertem stává přímo účastník procesu, ale může to být i manažer nebo vlastník procesu, případně dodavatel nebo zákazník. Vzhledem k tomu, že doménovými experty jsou různé osoby, objevování procesů musí čelit výzvám především v oblastech jako fragmentové procesní znalosti, myšlení v případech a nezkušenost s procesními modelovacími jazyky. První výzva souvisí s faktem, že účastníci podnikového procesu mají detailní znalosti ze svoji částí procesu, ale jejich celkový pohled na proces je obecný. Druhá výzva odráží zkušenost, že experti nemají problém nad úvahami o konkrétních případech a aktivitách v procesu, ale zobecnit průběh podnikového procesu je pro ně problém. Třetí výzva se týká problému, že doménoví experti neumí číst procesní modely, které vytvořil někdo jiný. Při objevování podnikových procesů se používají různé techniky. Mezi nej důležitější patří: 61 ŘÍZENÍ PODNIKOVÝCH PROCESŮ (BPM) • Objevování založené na důkazech (evidence-based discovery) • Objevování založené na rozhovorech (interview-based discovery) • Objevování založené na workshopech (workshop-based discovery) 4.4.1 OBJEVOVÁNÍ ZALOŽENÉ NA DŮKAZECH Objevování založené na důkazech používá různé druhy důkazů pro analýzu existujících podnikových procesů. Mezi tři základní metody patři analýza dokumentů, pozorování a automatické objevování procesů. Analýza dokumentů vychází z předpokladu, že v podniku nebo v organizaci je běžně dostupná dokumentace existujících podnikových procesů. Tato dokumentace nezřídka vykazuje více problémů. Často se stává, že dokumentace se nevyskytuje v procesně orientované podobě, např. v podobě organizačních diagramů. Dalším problémem bývá granularita dokumentů nebo důvěryhodnost dokumentů. Při pozorování přímo sledujeme průběh jednotlivých případů a snažíme se pochopit, j akým způsobem proces probíhá. Procesní analytik se může přímo stát zákazníkem a podnikový proces spouštět, nebo ho může pozorovat pasivně. Problémem je, že zaměstnanci nejsou zvyklí, aby je někdo při práci pozoroval, a může se stát, že nebudou práci vykonávat běžným způsobem. Automatické objevování procesů využívá enormní vývoj ICT v podobě operativní podpory podnikových procesů pomocí IS. Informační systémy zaznamenávají všechny operace, které v podnicích probíhají prostřednictvím tzv. logovacích souborů o událostech. Data o událostech mohou být ukládány takovým způsobem, který umožňuje jejich rekonstrukci v podobě procesních modelů pomocí tzv. process miningových metod (dolování procesů). Více se této problematice věnujeme na konci opory. Výhodou automatického objevování procesuje, že logovací soubory zachycují realizaci podnikového procesu velmi přesně včetně času. Nevýhodou je, že struktura některých dat neumožňuje jejich zpracování nebojsou generované procesní modely nepřehledné a komplexní. Vtákových případech se používají techniky filtrování a clusteringu. 4.4.2 OBJEVOVÁNÍ ZALOŽENÉ NA ROZHOVORECH Objevování založené na rozhovorech je metoda, která je založena na rozhovorech s doménovými experty. Procesní analytik si pro rozhovory vybírá ty doménové experty, kteří mají specifické znalosti k určité části podnikového procesu. Používají se dvé techniky vedení rozhovorů. První technikou je začít rozhovor od konce podnikového procesu (downstream) - od produktu a postupně se dostat až na začátek procesu. Druhou technikou je postupně odhalovat tok procesu (upstream). Obě techniky mají své výhody a umožňují postupně odhalovat jaké vstupy nebo výstupy jsou potřebné pro realizaci dalších podnikových procesů a jaké jsou mezi nimi vztahy. Procesní analytik následně vytváří prvotní procesní model - draft procesní model, který se následně iterativně vylepšuje. Doporučuje se 62 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu forma volného rozhovoru, ne strukturovaného interview. Takovýto postup je časové velmi náročný vzhledem k iteracím, které v něm probíhají. 4.4.3 OBJEVOVÁNÍ ZALOŽENÉ NA WORKSHOPECH Objevování založené na workshopech patří taky mezi příležitosti, jak získat hodnotné informace o podnikových procesech. Podněty z diskuse mohou být přímo přidané do procesního modelu. Kromě běžných účastníků workshopu se ho účastní facilitátor, který vystupuje jako moderátor, aby nedošlo k tomu, že diskuse bude odbíhat od tématu a operátor, který vkládá detaily do procesního modelu. Dále by měl být účastný procesní analytik a vlastník procesu. Zajištění účasti a hladký průběh workshopu si vyžaduje důslednou přípravu a plánování. Workshopy se opakují tři až pět krát za sebou. Diskuse probíhá nad aktivitami v podnikovém procesu, a když dojde ke shodě nad první aktivitou procesu, pokračuje se další až na konec procesu. Třetí fází objevování podnikových procesuje modelování. Modelování podnikových M o d e l 1 vání a procesů j sme se podrobněji věnovali v kapitolách 2 a 3 této opory. Výsledkem modelování nta je vytvořený procesní model, který musí mít určitou kvalitu (čtvrtá fáze objevování procesů). Rozeznáváme syntaktickou, sémantickou a pragmatickou kvalitu modelů. Pro zajištění syntaktické kvality se používá verifikace. Validace se používá pro zajištění sémantické kvality a certifikace pro pragmatickou kvalitu. 4.5 Analýza procesů DEFINICE Pří analýze procesů jako další fázi B P M činnosti, identifikujeme problémy, které vyplývají z as-is procesních modelů. Snažíme se tyto problémy kvantifikovat pomocí metrik procesního výkonu. Výsledkem této fáze je strukturovaný seznam problémů, který je seřazený podle jejich dopadu na celkový průběh podnikových procesů nebo podle výkonu, který musíme vynaložit na jejich řešení. 4.5.1 KVALITATIVNÍ ANALÝZA PROCESŮ Kvalitativní analýza se soustředí v první řadě na štíhlost (Jean) podnikových procesů identifikací nadbytečných částí procesů s cílem je odstranit. Analyzuje slabé částí podnikových procesů. Tyto částí způsobují problémy a negativně ovlivňují výkonnost procesů. S využitím kvalitativní analýzy analyzujeme dopady problémů v podnikovém procesu s úmyslem použít získané informace v další fázi B P M aktivity - při redesignu podnikových procesů. 63 ŘÍZENÍ PODNIKOVÝCH PROCESŮ (BPM) Klasifikace hodnoty Root cause ana­ lýza Value-added analýza, neboli analýza přidané hodnoty se skládá ze dvou kroků - klasifikace hodnoty a eliminace nadbytku. Analýza přidané hodnoty se snaží nalézt nepotřebné kroky v podnikovém procesu a eliminovat je. Krok v tomto případě značí úlohu v podnikovém procesu, nebo její část, případně přecházení toku procesu mezi dvěma úlohami. Platí přitom, že všechny kroky, které přinášejí hodnotu zákazníkovi, jsou value-adding (VA). Některé kroky hodnotu nepřinášejí, ale jsou důležité pro business samotný. Příkladem může být kontrola údajů o zákazníkovi, která jemu samotnému nic nepřináší, ale pro podnik to znamená správné údaje při doručování zásilek a menší podíl negativních výstupů procesu doručování. Takové kroky v podnikovém procesu označujeme jako business value-adding (BVA). Zákazník za ně není ochoten platit, ale pro podnik, který podnikový proces realizuje, přinášejí užitek. Třetím typem kroku, který nepřináší hodnotu zákazníkovi, se nazývá non-value-adding (NVA). Po identifikaci a klasifikaci kroků v podnikovém procesu můžeme pokračovat odstraněním nadbytečných úloh (eliminating waste). Obecným pravidlem je, že by jsme měli eliminovat, resp. minimalizovat N V A kroky v procesu. Některé N V A kroky mohou být eliminovány automatizací podnikových procesů a souvisí taky s odstraňováním účastníků procesů. Při analýze podnikových procesů platí, že i relativně dobrý podnikový proces může být lepší. V každém procesu se mohou vyskytovat odchylky, chyby, nedorozumění, nepotřebné kroky a jiné formy nadbytku při rutinním běhu podnikového procesu. Úkolem procesního analytika je identifikovat a dokumentovat tyto problémy rozhovory a pozorováním přímo na místě a bude přicházet do interakce s mnoha účastníky procesu, přičemž každý z nich může mít jiný názor na výkonnost celého podnikového procesu. Root cause analýza je skupinou technik, které se soustředí na identifikaci a porozumění příčinám problémů nebo nečekaných událostí. Mezi nejvíce používané techniky root cause analýzy patří tzv. diagramy příčin a následků (cause-ejfect diagrams, obr. 4-4) a proč diagramy (why-why diagrams, obr. 4-5). Příčina Následek Problém Obrázek 4-4: Diagram příčin a následků. 64 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu Zdroj: https://cs.wikipedia.org/wiki/Dia- gram_p%C5%99%C3%AD%C4%8Din_a_n%C3%Alsledk%C5%AF#/media/File:Is- hikawa_Fishbone_Diagram_cz.svg M E G R P I X L Download from megapixl.com.'19344687 Obrázek 4-5: Why-why diagram. Zdroj: https://images.megapixl.com/1934/19344687.jpg 4.5.2 KVANTITATIVNÍ ANALÝZA PROCESŮ Kvantitativní analýza procesu nabízí hodnotné pohledy dovnitř podnikových procesu, přičemž se zaměřuje na výkonnostní metriky procesů, jako např. cyklický a čekací čas, odchylky, apod. Mezi nej důležitější techniky kvantitativní analýzy patří analýza toků (flow analysis), analýza front (queueing analysis) a simulace. Každý podnik by chtěl mít podnikové procesy levnější, lepší a rychlejší. Z toho plynou základní výkonnostní dimenze, kterými jsou čas, náklady a kvalita. Někdy se k nim přidává i reakce na změny - flexibilita. Každá ze jmenovaných dimenzí může být rozdělená na procesní výkonnostní metriky, které též nazýváme key performance indicators (KPIs). Procesní výkonnostní metriky jsou kvantifikovatelné. Poznáme např. více druhů nákladů výrobní náklady, režijní náklady, fixní a variabilní náklady, operativní náklady, apod. Každý z těchto typů nákladů můžeme blíže specifikovat pomocí agregační funkce, např. průměr, rozptyl, minimum, maximum, apod. Čas je nejčastěji analyzovanou dimenzi. Cyklický čas je čas průběhu jednoho podnikového procesu (neboli případu) od začátku do konce. Redukce cyklického času (maximálního nebo průměrného) bývá cílem další fáze životního cyklu B P M - redesignu procesů. Další typy časů, které se používají při analýze podnikových procesů, jsou: (1) čekací čas (waiting time), kdy podnikový proces, resp. jeho aktivita čeká na volný zdroj, a (2) čas zpracování (processing time), po který zdroj (např. účastník procesu) pracuje na případě. Flexibilita je schopností reagovat na změny. Výkonnostní di­ menze 65 ŘÍZENÍ PODNIKOVÝCH PROCESŮ (BPM) Může jít o schopnost managementu podniku změnit strukturu, pravidla a zodpovědnosti v podnikovém procesu jako reakci na potřeby trhů a obchodních partnerů, nebo o schopnost samotného podnikového procesu zpracovat různé případy a změnu obsahu pracovní náplně. Další metody, které se používají při identifikaci a definici procesních výkonnostních metrik jsou referenční modely, průmyslné benchmarky, nebo např. balanced scorecard. Simulace procesů je jednou z nej rozšířenějších a nej oblíbenějších technik na kvantitativní analýzu procesů. Simulaci se věnujeme v kapitole 2.5 této opory a její praktické nasazení při aplikaci na podnikové procesy budeme demonstrovat v další kapitole. Mezi nejznámější nástroje pro modelování a simulaci podnikových procesů patří bezesporu ARIS Business Simulator, Bizagi Process Modeler, BIMP nebo Signavio. 4.6 Redesign procesů DEFINICE Cílem redesignu procesů jako další fáze životního cyklu B P M je nalézt změny v podnikových procesech, které by pomohly vyřešit problémy, identifikované v minulé fázi B P M aktivity. Jedná se o zlepšování podnikových procesů. V tomto okamžiku si může podnik nastavit výkonnostní cíle. Změny mohou být analyzované a srovnané s nastavenými výkonnostními metrikami. Tato fáze se kombinuje s různými analytickými technikami a navrhovanými změnami, co vede k novému redesignu (návrhu) podnikového procesu, resp. k jednomu nebo vícerým to-be procesním modelem, které sestávají vstupem do další fáze BPM aktivity. Důkladná analýzy podnikových procesů vede k různým nápadům a směrům, jak by se mohly předmětné podnikové procesy změnit, aby lépe fungovali s ohledem na stanovené výkonnostní metriky. Tady vzniká prostor pro redesign procesů, neboli jejich znovunávrh. Komplikací je, že redesign nebývá řízený systematickým způsobem, nýbrž spíš je založený na kreativní činnosti. Stává se proto, že víceré redesignové možnosti, které mohou být přínosem, bývají ve svém důsledku opomenuty. Při redesignu se využívají dvě základní metody: (1) heuristický procesní redesign (heuristicprocess redesign) a (2) produktově orientovaný design (product-based design). Podnikový proces vytváří a dodává nějaký produkt nebo službu pro své zákazníky. Kdyby někdo chtěl zlepšit kvalitu tohoto produktu nebo služby, tak nej lepším způsobem, jak toho dosáhnout je zlepšit příslušný podnikový proces. Všechny podnikové procesy se časem vyvíjejí a výsledkem může být mnohem komplexnější proces, než jaký byl zamýšlený na začátku jeho návrhu. Jeho komplexnost může být důvodem pro jeho výkonnostní problémy, které ve svém důsledku budou mít negativní vliv na zákazníka. Při redesignu podnikového procesu musíme vzít v potaz tyto skutečnosti: 66 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu • Interní a externí zákazníci podnikového procesu. • Operativní pohled na podnikový proces - implementační detaily procesu, počtu a druhu jeho aktivit. • Informace, které podnikový proces vytváří a využívá. • Technologie, kterou podnikový proces využívá. • Organizace a účastníci podnikového procesu - rozlišujeme dvě úrovně: (1) pracovníci jako účastníci podnikových procesů, kteří jsou alokováni k jednotlivým aktivitám včetně vztahů mezi nimi a (2) organizační struktura jako role, oddělení, projektové skupiny, uživatele, apod. • Chování podnikového procesu - jakým způsobem je podnikový proces realizovaný, jaké je pořadí jednotlivých aktivit a jejich plánování. Existuje velké množství informačních zdrojů, které se týkají procesního redesignu, různých metodologií, případových studií, apod. Všechny přestupy můžeme rozdělit do tří skupin - metodologie, techniky a nástroje. Metodologie je souhrnem metod, postupů, principů, které se používají k řešení problému. Technika je přesně specifikovaný postup, který vede k řešení daného problému. Při procesním redesignu se používá např. brainstorming, out-of-box-thinking, Paretova analýza, kognitivní mapování, apod. Z technického pohledu se v procesním redesignu používají různé techniky a notace jako např. BPMN, IDEF, simulace, apod. To samé platí pro nástroje, které podporují simulaci výše uvedených technik a notací. Při procesním redesignu se nejčastěji začíná s exilujícím podnikovým procesem, který se analyzuje a navrhují se jeho změny (heuristický procesní redesign). Ve výjimečných případech se nebere do úvahy existující podnikový proces, ale postupuje se radikálně projektem na „zelené louce". V tomto případě je výsledek nejistý (produktově orientovaný design). 4.7 Implementace a monitorování procesů IS, které využívají znalosti o tom, jak spolu různé aktivity, které probíhají v podnikových procesech, souvisí, se nazývají procesně orientované IS (process-aware). Hlavní kategorii procesně orientovaných IS se nazývá Workflow Management systémy (WfMS), nebo v současnosti častěji Business Process Management systémy (BPMS). Speciálním znakem BPMS je, že pro spouštění podnikového procesu využívají jeho explicitní (nebo formální) popis ve formě procesního modelu. Účelem BPMS je koordinovat automatizovaný podnikový proces takovým způsobem, že aktivita v procesu je načas provedena správným účastníkem procesu. 67 ŘÍZENÍ PODNIKOVÝCH PROCESŮ (BPM) Df DEFINICE Ve fázi implementace procesů j sou připravené změny pro přechod od as-is k to-be procesním modelům implementované nejčastěji v podobě WfMS (podrobněji kapitola 1.3) nebo BPMS. Implementace procesů se skládá ze dvou rovin - organizační change management a automatizace procesů. Automatizace představuj e vývoj a nasazení ICT technologií a IS, které podporují a spouštějí to-be precesní modely. BPMS je standardním typem softwarového systému, který se nabízí na trhu s různými funkcionalitami, které pokrývají celý životní cyklus BPM, resp. podnikového procesu. Od jednoduchých systémů, které pomáhají při návrhu a automatizaci podnikových procesů, až po komplexní řešení, které pokrývají i monitorování a process mining pro zajištění kvality implementovaných procesů. BPMS ve své složitější podobě, např. v bankách umožňují i napojení na systémy třetích stran a na sociální sítě. Nutným předpokladem automatizace podnikových procesuje podpora formátu, ve kterém se nachází procesní model. BPMS následně tento procesní model načte a umožní jeho nastavení a exekuci včetně různých podmínek a časových omezení pro nasazení v běžné podnikové praxi. Takový procesní model, resp. jeho explicitní popis je nutné aktualizovat pro zajištění jeho aktuálního obsahu. BPMS proto existují jako komplexní produkty nebo se specializují jenom na určitou část životního cyklu BPM, např. jako analytické, modelovací nebo simulační nástroje. Typická BPMS architektura je znázorněna na obr. 4-6. Řízení exekuce V Ovládání pracovních položek Nástroje pro modelování procesů Nástroje pro administraci a monitorování 68 Obrázek 4-6: Architektura BPMS. Zdroj: vlastní zpracování Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu DEFINICE Když redesignované procesy běží, tz. jsou spuštěné, tak dochází ke sběru a ukládání dat o těchto procesech. Tyto data jsou analyzována a je možné rekurentně zjistit, jaká je aktuální výkonnost podnikových procesů od realizované změny. Ve fázi monitorování a kontroly procesů jsou identifikované a případně opravené odchylky od požadovaného stavu (deviations), úzké hrdla (bottlenecks) a opakující se chyby v procesech. Může dojít ke vzniku nových problémů a celá B P M aktivita startuje od začátku. OTÁZKY 1. Popište podnikový proces obj ednávka-hotovost. 2. Jaké etapy identifikace procesů předcházejí vytvoření procesní architektury? 3. Jaké typy objevování procesů poznáme a na čem j sou založeny? 4. Jaký je rozdíl mezi kvalitativní a kvantitativní analýzou procesů? 5. K čemu slouží BPMS? SHRNUTÍ KAPITOL Y V této kapitole jsme představili příklady podnikových procesů a vysvětlili j sme si podstatu životního cyklu řízení podnikových procesů (BPM, Business Process Management). Stručně jsme si popsali jednotlivé fáze životního cyklu - identifikace procesů, objevování procesů, analýza procesů, redesign procesů, monitorování a kontrolu procesů. Závěrem jsme přiblížili fungování softwarových systémů na podporu návrhu, implementace a exekuce podnikových procesů. ODPOVĚDI 1. Podkapitola 4.1, str. 51 a 52. 2. Podkapitola 4.3, str. 56 a 57. 3. Podkapitola 4.4. 4. Podkapitola 4.5. 5. Podkapitola 4.7, str. 67. 69 ŘÍZENÍ PODNIKOVÝCH PROCESŮ (BPM) 70 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu 5 PŘÍPADOVÁ STUDIE BIZAGI RÝCHLY NÁHLED KAPITOLY Hlavním obsahem této kapitoly bude názorná ukázka využití životního cyklu B P M v podnikové praxi. Za pomoci softwarového nástroje Bizagi bude procházeno všemi fázemi včetně jejich zastoupení právě v prostředí Bizagi. Kapitola tedy bude kopírovat životní cyklus B P M teoreticky popisován v předchozí kapitole, proto se nedoporučuje postoupit k této kapitole bez prostudování předchozí. Součástí této kapitoly je obsáhlá případová studie ve strojírenském podniku. Případová studie se zabývá adopcí procesního řízení jako nástroje na zvyšování procesní vyspělos-ti a zefektivňování firemní procesů. Bude se postupovat od úvodního nastavení procesní architektury a rozdělením procesů podle jejich podstaty. Následovat bude identifikace procesů vedoucí k tvorbě as-is procesního modelu. Důležitým aspektem je také analýza procesů, kde za použití simulace procesů v Bizagi Modeler se budou testovat a vybírat ty nejlepší to-be procesní modely, které následně postoupí do implementační a optimalizační fáze. Tím se životní cyklus uzavírá. Jako další součást kapitoly budou dílčí úkoly podporující praktickou demonstraci principů procesního řízení prakticky používaného v podnicích napříč odvětvími. CÍLE KAPITOLY Po prostudování této kapitoly budete umět: • Využít software Bizagi jako podporu na řízení podnikových procesů, • Testovat výkonnost různých procesních modelů v simulačním rozhraní, • Metody sloužící pro úspěšnou implementaci B P M do podniku, • Holistický přístup k praktickému řízení procesů. KLÍČOVÁ SLOVA KAPITOLY Bizagi, BPM, Simulace procesů, procesní model, redesign procesů, implementace, životní cyklus, zpracování závazků. 71 PŘÍPADOVÁ STUDIE BIZAGI 5.1 Představení Bizagi Suite Bizagi je akronymem pro Business agility v překladu - podniková obratnost. Tento pojem vychází z historického vývoje disciplíny BPM, která prošla rozličnými etapami od radikálního přístupu k implementaci procesních technik (BPR) až po více agilní přístup vycházející z principů agilního způsobu projektového řízení. Proto se slovo agility - hbitost, obratnost hojně využívá nejen ve vědeckých publikacích, ale také u dodavatelů IT systémů podporující procesní řízení, jakým je také Bizagi. Samotná společnost stojící za Bizagi vznikla v roce 1989, kdy byla B P M disciplína v počátcích. Původní záměr společnosti bylo doručovat platformu na podporu postupného vylepšování podnikových procesů. Tato platforma se postupem času stala globální a má stovky zákazníků, mezi kterými jsou firmy jako GE, Adidas, a další. Velká výhoda také spočívá v možnosti synchronizace s vysoce rozšířenými softwary jako např. IBM, SAP nebo Oracle a prostřednictví API také s ostatními IT systémy v podniku. Samotné Bizagi se prezentuje jako platforma sloužící pro zažehnutí digitální transformace ve firmách. Výhody platformy Bizagi: • Velice jednoduchá ovladatelnost zaměřená na uživatelskou přívětivost. Široká nabídka školících kurzů a online materiálu pro samostudium. Podpora plyne také ze strany Bizagi komunity, která se shlukuje na fóru na Bizagi webových stránkách. To vše pomáhá při získávání důležitých informací pro firmy najejich B P M cestě. • Celistvé řešení Bizagi má pozitivní ohlasy od zákazníků i směrem k poměru nákladů a přínosů při implementaci do podniku v porovnání s ostatními dodavateli obdobných řešení. • Společnost Bizagi se odlišuje také nastavením svého obchodního modelu. Dva ze tří softwarů nabízí zdarma. Na prvních dvou modulech - Bizagi Modeler a Bizagi Studio lze finálně adoptovat a pilotně otestovat fungování v podniku až do rozsahu 20 uživatelů a také na neomezeném množství procesních modelů. Až v situaci, kdy je podnik připraven na zavedení, se poptá řešení, které bývá nejčastěji individuálně naceněno. Nevýhody platformy Bizagi: • Jednoduchá implementace nabádá uživatele k rozhodnutí, že adopce ve vlastní režii bude nejvýhodnější. To může být častokrát kritická chyba, neboť mohou 72 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu chybět kompetence v oblasti procesního řízení a vůbec základních principů, které budou obsahem této kapitoly, a to může vyplynout až v nepovedený start a v nej horším případě celý B P M projekt může zaniknout. • Přestože Bizagi umožňuje řídit jak strukturované, tak nestrukturované procesy, nedostatečně se ovšem věnuje komplexnímu case managementu (řízení pří­ padů). • Vzhledem k velikosti firmy a rychlosti změn v oblasti B P M společnost Bizagi pomalu přestává hbitě reagovat na změny a disrupce v oboru řízení a především automatizace podnikových procesů, kam vstupují firmy využívající například umělou inteligenci anebo tzv. robotickou procesní automatizaci. Bizagi se skládá ze tří komponentů: B a l í k s Bizagi • Bizagi modeler - tato část softwarového Bizagi balíku slouží pro tvorbu procesních modelů respektující BPM notaci. Vše probíhá v jednoduchém rozhraní, kde se dá vytvořit téměř jakýkoli procesní model za pomoci jednoduchého a intuitivního sytému „drag and dropííU . Součástí Bizagi Modeler je také simulační prostředí. Do toho prostředí vstupuje nastavený procesní model a zde se již jednoduchými 4-mi kroky nastaví veškeré proměnné vstupující do procesní simulace. V Bizagi Modeler tedy začíná B P M cesta a také zastupuje první fáze v životním cyklu BPM. Po dokončení tvorby procesních modelů lze tyto modely vyexportovat a dokumentovat v různých formátech, jakými je např. Word, PDF, a další. Bizagi obecně podporuje kolaboraci týmů, a proto i v Bizagi Modeler se nachází rozšíření pro spolupráci, kdy lze k procesním modelům přizvat další spolupracovníky, a dokonce s nimi komunikovat prostřednictvím vbudovaného chatu. • Bizagi Studio - na modelech a dalších výstupech z Bizagi Modeler následně buduje Bizagi Studio, které slouží pro tvorbu procesních aplikací. Bizagi často zdůrazňuje, že se jedná o budování aplikací bez použití kódu - programování. To se dá brát jako výhoda, ale může to působit také kontraproduktivně v případě nutných větších zásahů do aplikací, popř. při řešení chyb v nastavení. Uživatelské rozhraní, na kterém se pracuje, se zde dělí na dvě. Jednou je prostředí, kde se nastavují a budují procesní aplikace. Celý tento proces je rozdělen do několika kroků, kterými se postupně prochází. Nastavuje se zde - datový model vázaný na procesní mapu, definování formulářů (rozhraní pro exekuci procesů), obchodní pravidla, uživatelé, integrace s ostatními softwary zapojenými do procesů a finálně exekuce procesů, kde se pilotně testuje, jestli je vše správně nastaveno. Po vybudování této procesní aplikace určené pro exekuci jednotlivých procesů se již vše odehrává v dalším uživatelském rozhraní, kam již přistupují konkrétní 1 3 V překladu táhni a pusť. Nejběžněji se využívá v prostředí Windows, kdy uchopíme virtuální objekt a přetáhneme jej na požadované místo. 73 PŘÍPADOVÁ STUDIE BIZAGI uživatelé, ať již z pozice procesních účastníků nebo majitelů procesů a finální proces operativně vykonávají. Bizagi Studio se bude využívat ve fázi implementace procesů v rámci životního cyklu BPM. • Bizagi Engine - poslední součást Bizagi balíku je Bizagi Engine. Za jeho pomoci lze distribuovat procesní aplikace napříč celým podnikem do všech zařízení. Bizagi je responzivním softwarem a nabízí jak rozhraní pro PC, tak i pro mobily nebo tablety. Lze také používat software přímo v prostředí webového prohlížeče nebo si stáhnout program a využívat jej přímo ze zařízení. Zde již veškerá práce probíhá v uživatelském rozhraní Bizagi pracovního portálu. Zaměstnancům jsou přiděleny konkrétní procesy, kterých se účastní a oni pak veškerou práci provádí právě přes toto rozhraní. Vseje tedy pod jednou střechou, z čehož je možné čerpat spoustu informací a dat skrze analytický nástroj přímo zabudovaný do programu. Data se týkají efektivity a výkonu prováděných procesů. Ty se poté používají pro další rozhodování při redesignu procesů popř. dalších strategických rozhodnutích. Bizagi Modeler a studio jsou nabízeny zadarmo ke stažení včetně obsáhlé dokumentace vhodné pro implementaci. Za Bizagi Engine se již platí na bázi licencí za jednotlivé uživatele. Cena se rozděluje pro případ nasazení Bizagi Engine v cloudové formě nebo lokálně ve firmě. Zde se také účtuje ročně částka za údržbu. I V I K ZAP AZAPAMATOVANÍ Bizagi Modeler je program na tvorbu procesních modelů a jejich testování skrze simulace, Bizagi Studio slouží pro tvorbu procesních aplikací nad procesní modely, které slouží jako rozhraní pro exekuci těchto procesů a Bizagi Engine následně distribuuje tyto aplikace do potřebných zařízení napříč podnikem a také poskytuje analytický nástroj pro vyhodnocování a analýzu vykonávaných procesů. 5.1.1 BIZAGI A JEHO ZASTOUPENÍ V ŽIVOTNÍM CYKLU BPM Na obrázku 5-1 je zaznačen kompletní životní cyklus B P M jako v předchozí kapitole, ale navíc je do něj doplněno zastoupení jednotlivých komponentů z balíku Bizagi pro zpřehlednění. Vidíme, že největší zastoupení v životním cyklu B P M má program Bizagi Modeler, který se využívá od objevování procesů přes analýzu až po redesign procesů. Implementace procesuje časově i technicky nej náročnější fáze a v případové studii bude prováděna v Bizagi Studio. Poslední fáze monitorování a kontrola procesů j e zastoupena v Bizagi Engine, kde se skrze analytický nástroj bude vyhodnocovat výkonnost procesů. 74 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu b i z o g i Kontrola shody a výkonnost procesu Monitorovania kontrola procesů Spustitelný procesní model í Identifikace procesů Procesní J L architektura W Objevování procesů As-is model ) | Analýza procesů J Implementace procesů Redesign procesů Slabé stránky procesu blZQQI To-be model blZQQI Mnrlolor Obrázek 5-1: Zastoupení Bizagi v životním cyklu B P M . Zdroj: vlastní zpracování 5.2 Identifikace procesů Fáze identifikace procesů jako jediná nevstupuje přímo do uzavřeného životní cyklu BPM a také není podporována žádným z programů Bizagi. To však nemění fakt, že se jedná o klíčovou aktivitu, která následně ovlivní všechny další fáze. Tato podkapitola se bude soustředit na procesní architekturu v podniku a na zodpovězení dvou hlavních otázek, které umožní vstoupit do další fáze: • Jaké procesy v podniku probíhají? • Na jaký proces by měl vstoupit do životního cyklu B P M na základě prioritizace dle zvolených kritérií? 75 PŘÍPADOVÁ STUDIE BIZAGI SAMOSTATNÝ UKOL Představte si štandartní autobazar. Jaké procesy budou řídící, klíčové a podpůrné v takové firmě? Uveďte alespoň 3 příklady ke každému z nich. 5.2.1 SITUAČNÍ ANALÝZA UKÁZKOVÉ FIRMY Z POHLEDU PROCESNÍ VYSPĚLOSTI Pro správné zvolení procesu a celkového implementačního přistupuje nutné si nejdříve udělat zhodnocení podnikové vyspělosti (viz. podkapitola 4.3.2) z pohledu řízení podnikových procesů. To, v jaké fázi vyspělosti se firma nachází, determinuje její vztah k procesnímu řízení a také úroveň celkové procesní orientace. Podniková y s o u c a s n é době se firma nachází v situaci maximálního využití výrobních kapacit, což procesní vyspělost je dáno celkovou situací na trhu i v ekonomice obecně. Nezaměstnanost je na velmi nízké úrovni a firmy v tomto odvětví musí častokrát i odmítat zakázky. To je pro jakékoli rozvojové nebo změnové programy nepříliš vhodné prostředí, protože jednoduše vedení tvrdí, že na tyto věci není čas a všichni se musí zabývat provozem a operativou. V minulosti již ve firmě probíhaly určité snahy o zavedení principů BPM, které ovšem skončily právě kvůli nadměrné vytíženosti. V rámci tohoto projektu se zaměřili na několik procesů v administrativě, kde vytvořili as-is procesní modely a ihned bez předchozího analyzování a optimalizace se pustili do automatizace těchto procesů. Povědomí u většiny pracovníků v ekonomickém a obchodním oddělení o procesním řízení již existuje, to platí i pro vedení firmy, které celý tento pilotní projekt iniciovalo. Tím, že zaměstnanci byli do těchto projektů zapojeni a jejich odezva byla spíše kladná, lze odhadem usoudit, že potenciál ve firemní kultuře pro iniciaci dalšího B P M projektuje značný. Z pohledu napojení na firemní manažerské nástroje (rozpočty, organizační struktury atd.) a na firemní IT infrastrukturu, je situace ve firmě v rámci B P M technik nulová, tzn., neexistuje žádný takový nástroj a předchozí projekt se touto oblastí nezabýval. Z analýzy současné situace lze tedy usoudit, že podnik se stále nachází na první úrovni B P M vyspělosti, kterou je fáze ,Jnitial" - počáteční. Tuto skutečnost je důležité mít na paměti v průběhu dalšího postupu, např. při zapojování zaměstnanců do B P M aktivit, výběr pilotního procesu, vzdělávání zaměstnanců apod. Rozdělte následující firemní procesy v rámci procesní architektury mezi řídící procesy, klíčové procesy a podpůrné procesy a popište vztah mezi procesní architekturou a organizační strukturou. Všechny procesy pochází z firmy z případové studie, která má následující organizační strukturu. 76 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu Vedeni společnosti Valná hromada Obchodní oddělení T Technologie T Logistika 1 Marketing «IT správa • Export ŕľli 1 Nákup •Výzkum a vývoj *— Expedice HR oddělení _ Ku/voj zaměstnanců ™ Personalistiku T Výroba Plánovaní Kvalita Vedoucí středisek ' 1 ^ Ekonomické oddělení •Účetnictví ^Controling Obrázek 5-2: Organizační struktura sledovaného podniku. Zdroj: vlastní zpracování Vybrané firemní procesy: • Nábor zaměstnanců, • zpracování dokladů, • prototypování nového produktu, • tvorba plánu výroby, • vytvoření požadavku na nákup, hodnocení kvartální výkonnosti společnosti. 5.2.2 TVORBA PROCESNÍ ARCHITEKTURY V UKÁZKOVÉ FIRMĚ Na obrázku 5-3 je zobrazena procesní architektura v případové firmě. Procesy jsou uvedeny na značně abstraktní úrovni, aby bylo možné obsáhnout všechny oblasti podnikových procesů. Jedná se tedy o první úroveň detailnosti tzv. procesní mapa. Tato architektura tedy znázorňuje veškeré firemní procesy na základní úrovni a dekompozicí jednotlivých prvků v ní se lze postupně dostat přes procesní modely až na velice konkrétní úroveň sub-procesů. Procesní architektura (viz. podkapitola 4.3.3) byla vybudována na základě rozhovorů s důležitými osobami v rámci více zájmových skupin uvnitř podniku. Rozhovor se týkal 77 PŘÍPADOVÁ STUDIE BIZAGI procesů a aktivit probíhajících jak na operativní, tak na strategické úrovni a jejich vzájemného vztahu a provázanosti. Také byla analyzována organizační struktura (uvedena v řešené úloze výše), která také posloužila pro vytvoření celistvého obrazu o hlavních skupinách procesů v podniku. Obrázek 5-3: Procesní architektura ukázkového podniku. Zdroj: vlastní zpracování První části a pomyslnou střechu celé architektury tvoří řídící procesy. Nadřazeným procesem je strategické řízení, které určuje celkové směřování firmy a využívání dostupných zdrojů do oblastí dle priorit stanovených ve firemní strategii. Ostatní řídící procesy již fungují samostatně a ze své podstaty zasahují a ovlivňují další procesy napříč podnikem. Další část firemní procesů poté tvoří klíčové procesy, prostřednictvím kterých se generuje hodnota pro zákazníka od počátečního vývoje přes výrobu, marketing, prodej, distribuci až po zákaznický servis. Rozložení v této části procesní architektury odpovídá hodnotovému řetězci. Naznačuje tedy posloupnost klíčových procesů přispívajících k budování hodnoty pro zákazníka v pořadí znázorněném šipkami. Poslední částí v procesní architektuře j sou podpůrné procesy, které umožňují, podporují a zefektivňují exekuci klíčových procesů. V případovém podniku existují tři základní procesní skupiny - řízení lidských zdroj (HR), správa informačních systémů a technologií a účetnictví. Tyto procesy sami o sobě nepřináší hodnotu zákazníkovi, což ale neubírá na jejich důležitosti v kontextu celkového firemního řízení procesů. 78 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu 5.2.3 PRIORITIZACE PROCESŮ Po procesní architektuře přichází na řadu hlubší rozklíčování hlavních abstraktních procesů na sub-procesy druhé úrovně, z kterých již lze vybudovat procesní modely a jasně stanovit účastníky a majitele procesu. Tato aktivita je v této případové studii spíše kvalitativního charakteru, kdy se vede rozhovor s vedoucími jednotlivých oddělení, a otázky jsou směřovány na základní dekompozici procesů první úrovně stanovených v procesní architektuře. Vedoucí oddělení mají v dané oblasti nej větší přehled o procesech a u spousty z nich jsou jejich majiteli, což z nich tvoří ideální osoby právě pro hlubší identifikaci. Vysoká Nízká •Prototypování •Požadavek na nákup •Nábor • zaměstnanců Zpracování dokladů Slabé Zdraví Dobré Obrázek 5-4: Prioritizace procesů. Zdroj: vlastní zpracování Ukázky rozklíčovaných procesů jsou zaznamenány v samostatném úkolu výše v této podkapitole. Také v této fázi ještě není potřeba procesy dále mapovat nebo s nimi jiným způsobem pracovat, jde pouze o jejich nalezení a zaznamenání. Vybrané procesy byly ilustrativně zaznamenány do matice na obrázku 5-4. Pro vyšší přehlednost nebyly zaznamenány všechny. Matice zobrazuje na jedné ose důležitost daného procesu v rámci celkového firemního kontextu a na horizontální oseje zdraví procesu, které se získá prostřednictvím pozorováním, stínováním nebo rozhovory s procesními majiteli a účastníky. Následně se zanáší jednotlivé procesy do matice a jejich pozice se určuje podle vzájemného vztahu právě těchto dvou proměnných. Jedná se o pomůcku, která v této případové studii je hodně o subjektivním pohledu účastníků a majitelů procesu, protože ve firmě neexistuje žádný nástroj na měření efektivity a kvantifikaci prováděných procesů. Jedinou možnou kvantifikaci procesuje možné realizovat skrze logovací soubory využívaného ERP softwaru a jeho 79 PŘÍPADOVÁ STUDIE BIZAGI následné zpracování prostřednictvím Process miningu, jak bude ukázáno v další případové studii v poslední kapitole těchto skript. I přes jistou subjektivitu se lze od takto roztříděných procesů odrazit. Proces prototypování je součástí klíčového procesu vývoj, tím pádem je, co se týče důležitosti, na vysoké pozici. Rozhovor s vedoucím oddělení technologie odhalil, že proces zde není jasně strukturovaný, protože přehnaná strukturovanost by mohla omezit kreativní myšlení, tak důležité pro tvorbu inovací. Jinak proces prototypování nevyjadřuje žádné známky špatného procesní kondice. Kombinace nevhodnosti (neproveditelnosti) zapojení technik procesního řízení s dobrou úrovní procesního zdraví, směřuje k faktu, že tento proces není vhodný pro úvodní B P M projekt. Proces náboru zaměstnanců je součástí HR oddělení a zabezpečuje průchod zaměstnance od fáze zájemce až do fáze zaškolený pracovník. S představitelem tohoto oddělení byl opět veden rozhovor týkající se současného stavu a existujících problémů při vykonávání tohoto procesu. Až na menší problémy týkající se efektivní práce s náborovými dokumenty, jejich správa a archivace, nebyly v procesu identifikovány žádné další problémy, a i z pohledu výkonu proces funguje dle stanovených indikátorů. Proto je procesní zdraví spíše na dobré úrovni a výsledný efekt po zapojení do B P M programu by nebyl dostatečný. To by mohlo způsobit špatnou návratnost investice z vložených zdrojů a zastavení dalších B P M projektů do budoucna. V této fázi vyspělosti nelze vybrat klíčový proces (rozdělení procesů kapitola 1.2), možná by úspěch prospěl při obhajobě u vedení, ale neúspěch by zabil veškeré další snahy do budoucna o postoupení v modelu procesní vyspělosti. Také kapacitní vytíženost firmy je vysoká. Rozum by velel vybrat si jeden z klíčových procesů (např. požadavek na nákup nebo prototypování) a snažit se s ním dosáhnout stanoveného cíle ve formě efektivity nebo zvýšení kvality výstupů. To může platit v případě, že již firma dosáhla určité fáze procesní orientace a její procesní vyspělost je na vyšší úrovni. Avšak v této počáteční fázi je nesmírně důležité začít od malých projektů nezaměřujících se na klíčové procesy, jejichž možné ohrožení v průběhu implementace by mohlo následně ohrozit chod celé firmě na nej důležitějším hodnotovém řetězci směrem k zákazníkům. Proto volba úvodního procesu, kterému se dále tato případová studie bude věnovat, padla na proces zpracování dokladů (závazků), který je součástí podpůrného procesu účetnictví. Jeho jasná strukturovanost, pravidelnost a také podpůrný charakter j sou důležitými faktory pro jeho výběr. Po rozhovoru s hlavní firemní účetní byly naznačeny určité nedostatky v tomto procesu, které spočívají především v dlouhé době zpracování a oběhu dokladu. Na základě informací tedy bylo zdraví procesu stanoveno na spíše horší úrovni. Důležité je zde také zmínit vysokou míru proveditelnost, která značí potenciál úspěchu při využití B P M nástrojů a technik, což vychází z faktu, že velká část procesu probíhá v elektronické podobě a jediný externí program vstupující do exekuce procesu je účetní ERP software. 80 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu 5.3 Objevování procesů v ukázkové firmě Úlohy objevování procesu ve firmách má nejčastěji na starosti procesní analytik, který zodpovídá za projekty týkající se analyzování a vylepšování procesu. To platí za předpokladu, že firma má již určitou zkušenost s projekty zaměřenými na procesní řízení. To však v ukázkové firmě neplatí. Tuto úlohu tedy mohl plnit externí konzultant, nově rekrutovaný zaměstnanec s potřebnými kompetencemi nebo současný zaměstnanec povolaný pro novou pracovní pozici. Firma vyhodnotila, že nejvýhodnej ší bude najmout externího konzultanta, který tuto roli bude zastávat. Bude mít k dispozici tzv. doménové experty. Ti mají důkladnou znalost, jak proces probíhá, protože se ho buď přímo účastní, nebo ho vlastní (vlastník procesu). Aby fungovala fáze objevování procesů, musí fungovat také kooperace mezi procesním analytikem a doménovým expertem, protože výsledek v podobě platného procesního modelu, závisí na znalosti od obou zúčastněných rolí. Doménoví experti v případě vybraného procesu v ukázkové firmě mají znalost o průběhu procesu z každodenní operativy, avšak nemají znalost modelovacích jazyků. Tu má externí procesní analytik, který ale zas nemá znalost samotného procesu zpracování závazků v podniku. K ZAPAMATOVÁNÍ Doménový expert je osoba, která má důkladnou znalost o průběhu analyzovaného procesu. Nejčastěji je to konkrétní pracovník, který proces vykonává nebo osoba zodpovědná za proces (procesní vlastník) Procesní analytik oproti tomu má vysokou znalost o řízení a analýze procesů, včetně znalosti modelovacích jazyků a aktivně se této oblasti věnuje. Avšak jeho znalost konkrétní procesuje nižší. Před samotnou realizací této fáze životního cyklu B P M je důležité identifikovat výzvy, před kterými osoby zodpovídající za úspěch této iniciativy stojí: • Již zmiňovaná kapacitní vytíženost projevující se i v ekonomickém oddělení a z toho plynoucí neochota doménových expertů spolupracovat • Jakákoli neznalost doménových expertů základních modelovacích principů • Roztříštěnost znalostí o procesu mezi několik pracovních pozic (procesních účastníků) • Neschopnost doménových expertů zobecňovat procesy. Tím pádem se drží na úrovni konkrétních aktivit 81 PŘÍPADOVÁ STUDIE BIZAGI UKOL K ZAMYŠLENI Představte si, že z pozice procesního analytika vstupujete do studijního oddělení naší fakulty. Máte za úkol vymodelovat administrativní proces změny typu studia z prezenční na kombinovanou. Jaké by byl postup? Do jakých dokumentů byste náhlídli? Jaké konkrétní otázky byste zvolil při rozhovoru? Postup Strategie organizovaného sběru informací je založena na několika krocích logicky na sebe navazujících a má vyplynout ve vybudování procesního modelu. Prvotní snahy budou směřovány do analýzy dokumentů, které nenarušují pracovníky a nevyžadují jejich zapojení, což v případě plného vytížení firemních kapacit, je na místě. Další taktika méně zasahující je pozorování účastníků procesu při vykonávání daného procesu. Poslední taktika budou rozhovory s doménovými experty, kde se bude postupně pracovat na vylepšování draftu procesního modelu. V případě, že i po tomto kroku budou nejasnosti ohledně vymodelovaného procesu, musí přijít na řadu workshop pod vedením facilitátora se zástupci účastníků procesu, aby se přímo na tomto workshopu dosáhlo konsensu o finální podobě procesního modelu. Avšak tato aktivita je časově více náročná, proto se využije pouze v krajním případě. 5.3.1 ANALÝZA DOKUMENTŮ V prvním kroku se budou analyzovat dostupné dokumenty tak, aby procesní analytik získal informace o procesu a mohl si utvořit alespoň základní představu předtím, než přejde ke kroku, který již počítá s účastí doménových expertů. Před získání dokumentů byl proveden krátký rozhovor s vedoucím ekonomického oddělení, který směřoval k odhalení všech pracovních pozic, jenž se procesu zpracování závazků účastní. Představení si cesty jednotlivých faktur skrz ekonomické oddělení není pro vedoucího obtížný úkol, proto ihned identifikoval 4 pozice, které přímo vstupují do procesu: • Finanční asistent • Recepční • Administrativní manažer • Účetní Je možné, že se počet zúčastněných ještě změní, ale jako základ tato informace stačí. Následuje analýza popisu pracovních pozic, právě u těchto 4 pozic. Tyto dokumenty j sou jedny z mála dokumentů, které má každá firma zejména i kvůli legislativě. Tím, že popis pracovní pozice musí být ze zákona přiložen k pracovní smlouvě, jedná se spíše o dokument vznikající z nutnosti nežli popis činnosti, z kterého se dá vycházet. Lze z něj vyčíst 82 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu hrubé obrysy jednotlivých aktivit, z toho některé očividně přímo souvisí s procesem zpracování závazků, jako např. zavedení faktur a dokladů do ERP softwaru, tvorba platebních příkazů nebo také kontrola přijatých dokladů. Po průzkumu dokumentů se zanáší aktivity a sub-procesy v různých úrovních abstraktnosti nebo konkrétnosti do pracovního souboru a z něj se bude v další fázi vycházet při formování těchto aktivit do posloupnosti a značení spojitostí mezi nimi. U jedné pozice - finanční asistent byl z důvodu vysoké fluktuace na této pozici sepsán podrobný dokument usnadňující zapojení nového pracovníka do operativních činností. Tento dokument poskytuje již příliš mnoho detailů a konkrétních pracovních úkonů včetně tzv. workflow (viz. kapitola 1.3). Ten není vymodelován, ale spíše popsán slovně i graficky. Dohromady tvoří dokumenty pouze základ pro další objevování a pouze s jejich znalostí nelze validně vybudovat procesní model. Procesní analytikje ale pomocí těchto dokumentů uveden do kontextu procesu zpracování závazků a v dalších fázích znalosti nabité zde využije. Dalším plánovaným krokem je tedy pozorování procesních účastníků při výkonu ukázkového procesu. 5.3.2 POZOROVÁNÍ PROCESNÍCH ÚČASTNÍKŮ V další úrovni objevování procesů se procesní analytik s majitelem procesu domluvil na pasivním pozorování, které bude vykonávané v průběhu pracovní doby, kdy všichni účastníci procesu jsou zapojeni v procesu a nejlépe proces aktivně vykonávají. Procesní analytik zvolil nejdříve taktiku sledování cesty jednoho konkrétního závazku (faktury) napříč všemi aktivita od přijetí přes zpracování, nejlépe až po zaplacení. Následně bude sledovat konkrétní účastníky při jejich práci po dobu nezbytně nutnou pro sběr dostatečného množství vstupů zabezpečující kvalitu informací. Tím, že proces zpracování závazků je dobře strukturovaný a objevuje se v něm málo výjimek a jiných problémů, nebude tato fáze náročná jako u více nahodilých a méně strukturovaných procesů, kde se může jednat o komplexní a náročnou aktivitu. Po výstupech z pasivního pozorování si procesní analytik udělal jasno v procesní posloupnosti a propojení procesů. To mu umožnilo navrhnout první procesní model tzv. draft, který se bude následně iterativně vylepšovat skrz rozhovory s doménovými experty. 83 PŘÍPADOVÁ STUDIE BIZAGI SAMOSTATNÝ UKOL Jak by podle vás vypadal draft procesního modelu zpracování e-shopové objednávky u vašeho oblíbeného e-shopu. Nemusíte se nutně držet B P M notace, jde spíše o prvotní draft určený pro další validaci. 5.3.3 ROZHOVORY S DOMÉNOVÝMI EXPERTY Při rozhovorech s doménovými experty bývá největší překážkou jejich skeptický přístup. Myšlení je nutné přetransformovat z pohledu, že vidí výjimky a odlišnost každé situace do pozice, kdy pochopí smysl modelování procesů a dokáží do určité míry generalizovat aktivity v procesu na úroveň pro procesní modelování potřebnou. Při rozhovorech procesní analytik dodržuje stejnou posloupnost jako u pozorování - dopředný postup, kdy se začíná u přijetí faktury u pozice recepční. Rozhovor také nemá žádnou předem definovanou strukturu, j sou pouze stanoveny informace, ke kterým se procesní analytik snaží dopátrat. Požadavky na informace vychází z předcházejících fází, zejména pak z fáze pozorování. U některých pracovních pozicí jde skutečně o rychlý rozhovor, protože např. úloha recepčního v procesu je pouze předat nebo přeposlat fakturu dále. U některých dalších pozicí jako finanční asistent je situace komplikovanější, protože do procesu vstupuje několikrát a stará se o velkou část aktivit spojených s procesem zpracování závazků. Další věc u otevřeného rozhovoru je povzbudit otevřenost doménových expertů, kteří se formální strukturou nebudou cítit tak svázáni a otevřenost přispěje k získání transparentních informací. 5.3.4 POPIS A MODEL PROCESU ZPRACOVÁNÍ ZÁVAZKŮ Po několika rozhovorech se ucelily výstupní informace, daly se dohromady s informacemi získanými z analýzy dokumentů a z pozorování a výsledkem je tento finální procesní popis: Celý proces zpracování závazků začíná na pozici recepčního, kde se doklad přijímá, a to ve dvou možných formách - elektronicky (např. prostřednictvím emailové zprávy) nebo fyzicky (společně s dodávkou). Je zde také spárován s příslušnou objednávkou, která každému závazku předchází. Poté probíhá porovnání přijaté faktury s údaji uvedenými na objednávce. Když informace na faktuře (produkty, datum splatnosti, částky) korespondují s objednávkou, faktura je schválena. Když ne, faktura je odmítnuta, okomentována a vrácena dodavateli. Sub-proces navrácení dodavateli se v této případové studii neřeší. V případech, kdy závazek nemá žádnou objednávku, která předcházela, musí být do faktury zaneseny další dodatečné informace (označení produktu, údaje o dodavateli). Další brána ur- 84 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu čuje, jestli je potřeba dalšího schvalování od osoby, která je majitelem procesu tvorby objednávky (administrativní manažer). Pokud schválení není potřeba, proces se přesouvá k aktualizaci ERP systému, kterou má v režii firemní účetní. Když schválení od administrativního manažera neprojde, je faktura opět vrácena dodavateli. Po aktualizaci ERP systému probíhá kontrola splatnosti faktury opět u finančního asistenta, který po zvážení faktorů, jakými jsou blížící se splatnost na dokladu a likvidita podniku, určí, jestli je faktura připravena na uhrazení. Jestli ne, proces zde končí. V opačném případě finanční asistent vytvoří platební příkaz, který přepošle účetnímu a ten příkaz zkontroluje a provede platbu skrze internetové bankovnictví. 5.4 Analýza procesu zpracování závazků U analýzy procesu a následné tvorby to-be procesního modelu se jedná o nejvíce kreativní fázi ze všech, která je hodně otevřená ve smyslu používání striktních postupů a metod. Samozřejmě, že jako u každé fáze i zde je obrovské množství technik, a proto je potřeba určit, které se pro danou situaci nejvíce hodí. Z kapitoly 4.5 vyplývá, že máme dvě obecné skupiny analýzy, a to kvalitativní a kvantitativní. Námi využívaný program Bizagi používá logicky kvantitativní analýzu prostřednictví simulací a what-if analýzy. Té ale nejlépe musí předcházet kvalitativní analýza, protože obecně platí, že až kombinace obou druhů analýzy přináší nej efektivnější výstupy. ~> PostupRecepce Revize dokladu Schvalování dokladu Úhrada dokladu Přijetí dokladu Potřeha Doklad schválení Ověření dokladu koresponduje oroduktu^služ s objednávkou A r r Vrácení dokladu dodá Ne Scvhálení produktu/sl užby (>rodukt/služb| Ano a byla schválena Aktualizace v ERP systému 9 ir.it —, Neplatit Kontrola splatnosti ' • dokladu Rozhodnutí o provedení platby Vytvoření platebního príkazu Kontrola a provedení platby Obrázek 5-5: As-is procesní model procesu zpracování závazků. Zdroj: vlastní zpracování Postup analýzy procesu zpracování závazků v ukázkové firmě tedy bude následující. Nejdříve se začne analýzou přidané hodnoty, která je kvalitativního charakteru a měla by roztřídit procesy na ty, které přináší hodnotu zákazníkovi nebo podniku a ty, nepřinášející hodnotu. Tato analýza pomůže v hledání podnětu pro inovaci a redesign ukázkového pro- 85 PŘÍPADOVÁ STUDIE BIZAGI cesu, který by měl vyvrcholit ve vybudování to-be procesního modelu. Správnost a účinnost předpokladu, který předcházel vymodelování to-be procesu, bude otestována v programu Bizagi Modeler, konkrétně v jeho simulačním prostředí. Tím se dokáže vyčíslit možný přínos chystaného redesignu a potvrdí se nebo vyvrátí předpoklad vycházející z kvalitativní analýzy. 5.4.1 KVALITATIVNÍ ANALÝZA UKÁZKOVÉHO PROCESU Analýza hlavní technika kvalitativní analýzy byla zvolena analýza přidané hodnoty, neboť přidané hodnoty její využití je velice široké a může být přínosná téměř v každém případě analýzy procesů. Obvykle se v první etapě rozkládá proces na jednotlivé kroky a sub-procesy tak, aby se na úrovni pracovního postupu eliminovali zbytečné aktivity. V této případové studii tato úvodní činnost není na místě, protože se operuje na úrovni procesního modelu znázorněného v předchozí podkapitole a další zabředávání a specifikace na konkrétní aktivity by mohla i vzhledem k nízké procesní vyspělosti firmy působit zbytečně složitě a časově náročně. Navíc nejsou žádné další podklady ani procesní popisy či seznamy, proto by se vše muselo tvořit od začátku, a to bude předmět spíše dalších B P M projektů v ukázkové firmě. Nyní musí následovat určení, o jaký proces se v kontextu analýzy přidané hodnoty jedná. Proces zpracování závazků je podpůrným procesem (vychází z procesní architektury) a hodnotu zákazníkovi ze své podstaty nepřináší, jedná se ale o tzv. business valueadding proces, který nepřináší hodnotu zákazníkovi, ale firmě umožňuje efektivně pracovat a nakládat s daty dodavatelů nebo zákazníků. Pomyslným zákazníkem procesu je dodavatel, který poslal do firmy fakturu (vznikl závazek) a očekává její uhrazení. Pro firmu jsou na druhou stranu důležitá data, která se musí zanést do ERP systému a společně s celkovými daty o závazcích slouží jako základ pro manažerské rozhodování. Následuje samotný rozklad všech aktivit v procesu a zmapování, které z nich přidávají hodnotu přímo zákazníkovi, které přidávají hodnotu podniku, a které nejsou pro podnik ani zákazníka vůbec přínosné. ŘEŠENÁ ÚLOHA Uvažujme nad procesem požadavek na nákup vybavení z jedné výrobní haly u velkého kovozpracujícího podniku. Proces zde bude rozložen do vysoké specifičnosti jednotlivých kroků: Když předák výroby na základě sledovaných hodnot u vybavení, kterým j sou např. pracovní rukavice, špunty do uší a další vybavení spíše spotřebního charakteru (nejedná se o materiál), spatří nedostatek u tohoto typů vybavení, sepíše oficiální požadavek na nákup a přidělení chybícího vybavení. Následně tento požadavek pošle skrze email na ekonomické oddělení pro další zpracování. Pracovník na ekonomickém oddělení si tento email otevře, 86 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu přečte, následně skrze elektronické rozhraní vybere chybící vybavení, zkontroluje jeho dostupnost nejčastěji telefonátem. Na základě těchto kroků vytvoří požadavek na nákup, který přepošle v emailové podobě vedoucímu výroby na schválení. Ten jej otevře a prozkoumá žádost, v případě potřeby vykomunikuje nejasnosti a přepošle požadavek zpátky pracovníkovi ekonomického oddělení. Ten vytvoří objednávku na vybavení a pošle jej dodavateli vybavení. Na základě tohoto popisu identifikujte procesní kroky a rozčleňte (popis rozdělení naleznete v kapitole 4.5.1) je mezi: • Value-adding (VA) • Business value-adding (BVA) • Non-value-adding (NVA) Proces zpracování závazků se ve sledované firmě skládá z těchto aktivit. Níže je k nim přidán komentář, o jaký typ přidané hodnoty se jedná: • Přijetí dokladu - bez přijetí dokladu by žádné další kroky nebyly možné. Ovšem je zde potřeba jít trochu hlouběji a zaměřit se, jestli je přijetí na recepci, která pouze přepošle fakturu dále, nutné a jestli by fakturu nemohl přímo přijímat finanční asistent. I tak se avšak jedná o aktivitu přidávající hodnotu zákazníkovi procesu. • Ověření dokladu - ověřování a kontrolní kroky obecně se často řadí mezi Business-value-adding aktivity. Avšak analytik by si měl položit otázku, kolik ověřovacích a kontrolních krokuje potřeba, a jestli jsou skutečně přínosné pro podnik. U této aktivity lze říci, že je přínosná pro podnik, protože toto ověření je klíčové kvůli dalšímu zpracování a správnosti faktury. Bez tohoto kroku by dále mohly vzniknout chyby. • Schválení produktu/služby - další schválení následuje, ale nyní již v režii administrativního manažera. Aktivita je nastavena pouze pro vybrané produkty nebo služby, jenž schválením musí projít. Zde je již na zvážení, jaké schválení, jakého produktu je pro podnik přínosné (BVA) a co nepřidává hodnotu. Tento poznatek může sloužit dále při analýze procesu, kdy se tento schvalovací krok podrobí hlubší inspekci a pokusí se najít opatření pro zefektivnění procesu. • Aktualizace v ERP systému - zde se určitějedná o aktivitu přidávající hodnotu zákazníkovi procesu (VA), neboť ERP je důležitým komponentem, který i následně generuje platební příkaz a určuje, kdy by měl být závazek uhrazen. Takže bez tohoto kroku by nebylo možné splnění cíle procesu. 87 PŘÍPADOVÁ STUDIE BIZAGI • Kontrola splatnosti dokladu - časově nejméně náročná aktivita bude také přidávající hodnotu, bez tohoto mezikroku nebude možné pokračovat k vytvoření platebního příkazu. Celý proces po této aktivitě také může skončit kvůli nevyhovujícím podmínkám (splatnost a dostatek volných finančních prostředků) vyplývajících z ERP. • Vytvoření platebního příkazu - na základě platební příkazu se uskutečňuj e platba závazku dodavateli. Proto se jednoznačně jedná o aktivitu přidávající hodnotu (VA). • Kontrola a provedení platby - proces skládající se ze dvou kroků, kdy jeden je spíše přínosný pro podnik (BVA) a tím je kontrole příkazu a druhý krok je již přidávající hodnotu pro zákazníka procesu, protože úhradou závazku se dosahuje cíle celého procesu. U kroku kontroly platebního přikazuje zapotřebí se podívat, jak a proč tato kontrola probíhá a jestli je skutečně potřebná. Tyto pochybné místa budou součástí dalšího zkoumání. Bramstor- p 0 a n a i ý z e přidané hodnoty bude následovat kreativní část kvalitativní analýzy pro- ming workshop cesu, kdy se pomocí metody brainstorming, bude s majitelem procesu a vybranými procesními účastníky vyhodnocovat rozporuplné místa v procesu, jenž byly výstupem analýzy přidané hodnoty. Brainstorming je kreativní technika, která j e založena na skupinové kreativitě. Účastníci brainstormingu j sou vyzváni, aby generovali nápady směřující k cíli nebo vyřešení zadaného problému. Musí se přitom dbát na základní pravidla. Brainstorming je o kvantitě, a ne o kvalitě nápadů. V průběhu brainstormingu se nápady nehodnotí, aby se předešlo soudu a až po nasbírání dostatečného množství nápadů se na závěr hodnotí reálnost a proveditelnost vygenerovaných idejí. Největší otazníky přineslo nadměrné kontrolování a schvalování v procesu, proto tyto místa byly obsahem kreativní porady, jejímž cílem bylo vytvořit to-be procesní model. Nejdříve se rozklíčovaly schvalovací aktivity na jednotlivé kroky a spustila se debata, které z kroků jsou přínosné a které naopak ne (podrobnější analýza přidané hodnoty). Procesní analytik celou tuto schůzku facilitoval (moderoval). Z porady vyplynulo, že nejvíce zbytečný a zatěžující je proces schvalování platebních příkazů, který je dán zejména velkou pracovní zátěží u účetního, jenž si stěžuje na vysoké množství pracovních úkonů, které musí v průběhu dne vykonávat, a hlavně na nadměrné přecházení mezi aktivitami, což přerušuje plynulý tok práce a celková efektivita tak klesá. Oblast pro brainstorming je tedy vydefinovaná a kreativní část pod vedení procesního analytika začala. Výstupem 88 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu byl předpoklad na vylepšení stávajícího procesu předelegováním části procesu od účetního na finančního asistenta. Tento procesní redesign spočívá v přidělení kompetence úhrady závazků pod 10 tisíc korun finančnímu asistentovi, který při splnění této podmínky, vytvoří platební příkaz a rovnou závazek také uhradí. To podpoří plynulost toku práce a mělo by ulehčit účetní. V případě, že závazek bude nad 10 tisíc korun, vše probíhá tak, jako v as-is procesním modelu. To-bepm- Na obrázku 5-6 je znázorněn to-be procesní model, který je až poslední fáze úhrada cesnimo- dokladu stejný jako as-is procesní model. Jediná změna proběhla, jak bylo popsáno výše, po bráně rozhodnutí zaplatit, kdy nyní vytvoření příkazu k úhradě a zaplacení dokladu může provést finanční asistent. Nyní je potřeba přistoupit ke kvantitativní části analýzy procesu, kdy se pomocí procesní simulace v Bizagi Modeler, bude zjišťovat, jak by tento procesní redesign mohl zvýšit efektivitu vykonávaného procesu zpracování závazků. 5.4.2 KVANTITATIVNÍ ANALÝZA UKÁZKOVÉHO PROCESU Ve stejném programu (Bizagi Modeler), ve kterém byly as-is i to-be procesní modely vybudovány, lze testovat vykonávání procesu v tzv. Simulation view rozhraní. Velice rychle a jednoduše se dá potvrdit nebo vyvrátit procesní předpoklad. To je tedy další logický krok v případové studii. R e c e p c e Přijetí dokladu Reuize dokladu Schvalování dokladu Úhrada dokladu Potreba schválení Ově ření dokladu koresponduje D roduktu/služ s objednávkou a Vracení dokladu doda Ne Scvhálení produktu/sl užby Produkt/služb a byla Aktualizace v ERP systému Kontrola V splatnosti dokladu > Nastavení procesní simulace Rozhodnutí neplatit Rozhodnutí o provedení Do 10 tis, Zaplacení dokladu Vytvorení platebního pfík JZU Kontrola a provedení platby Obrázek 5-6: To-be procesní model procesu zpracování závazků. Zdroj: vlastní zpracování Samotné nastavení procesní simulace probíhá ve 4 krocích. V prvním se procesní model validuje (Process validation) v tomto kroku se stanovuje pouze počet příchozích tokenů a přerozdělení v branách. Validace je důležitá na otestování, jestli je proces správně vybudován. V dalším kroku - časová analýza (Time anály sis) se měří časy zpracování u jednotlivých aktivit v procesu. U každé aktivity lze stanovit tzv. statistická distribuci, která zpřesňuj e simulační výsledky. Počítá se zde s neomezeným množstvím zdrojů. Předposledním 89 PŘÍPADOVÁ STUDIE BIZAGI krokem je analýza zdrojů (Resource anály sis). Zdroj zde nabývá podoby lidského nebo hmotného (vybavení, zařízení). Takže se aktivitám přidělují procesní účastníci a popř. i vybavení (v případě, že jeho využívání něco stojí). Cena zdrojů může být fixní nebo variabilní - cena za hodinu nebo za vykonání procesu. Přidělení zdrojů omezuje vykonavatelnost procesů, protože se v procesu začíná projevovat čekací doba (waiting time), kterou token (doklad) musí čekat na zpracování. Poslední krok je analýza kalendářů (Calendar analysis), v které se pro j ednotlivé zdroje přiřazují pracovní kalendáře. Formují další omezení pro zdroj, protože se zde počítá s pracovní dobou zaměstnanců a mohou se zde projevovat i různé pracovní volna, pauzy, a další prostoje. PRO ZÁJEMCE V simulační prostředí Bizagi Modeler fungují různé typy distribucí pro lepší vyobrazení reality v procesních simulacích. Aktivity v procesu častokrát nemají fixní dobu zpracování, tzn., každý případ se liší. Např. schválení faktury trvá někdy 3 a někdy 5 minut. Proto nám slouží distribuce, aby bylo možné se vypořádat s takovými rozdílnostmi. V případové studii jsou použity dva druhy distribucí. Poissonova distribuce, která se používá při zcela náhodném zpracování, které nemá žádné závislé proměnné. Tzn., události se nezávisle na sobě vyskytují pouze s fixní průměrnou mírou. Další typ je triangulární distribuce, kdy se stanovuje minimální a maximální hodnota pro dobu zpracování a také pravděpodobná hodnota, která je v mezích minima a maxima a výsledky se poté pohybují v tomto rozmezí. Z výsledků z rozhovorů a pozorování, které proběhly ve fázi objevování procesů, jsou známy tyto údaje, které slouží jako vstupy do nastavení procesní simulace: • Aktivita přijetí dokladu i s jeho distribucí finančnímu asistentovi zabere většinu času okolo 2 minut, ať už doklad dorazí v elektronické nebo fyzické podobě. Je zde nastavená doba zpracování na fixní dobu 2 minut. • U ověření dokladu již nelze přesně stanovit kolik aktivita zabere času, protože záleží podobě dokladu a např. množství položek v něm. Proto se nastavuje Poissonova distribuce s průměrem 1,5 minuty. • Z 85 % doklad koresponduje s objednávkou, což lze vyčíst zERP softwaru. V 15 % případů se doklad posílá zpět dodavateli. Sub-proces navrácení dokladu zpět dodavateli se ani v rámci simulací procesů neřeší. • Potřeba dalšího schválení od administrativního manažera vzniká ve 34 % případů. Tzn., že 66 % putuje rovnou do aktivity aktualizace ERP. 90 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu • Časová náročnost aktivity schválení produktu/služby se liší v závislosti na typu produktu nebo služby, která má být schválena. Inspekce produktu nebo verifikace služby se zpracovává v rozmezí od 3 minut do 10 minut, ale u většiny produktu to bývá minut 5. Proto se zde zvolila triangulární distribuce s minimem 3 minuty maximem 10 minut a nej pravděpodobnějším časem zpracování 5 mi­ nut. • Z výstupů z ERP softwaru 85 % produktů/služeb bývá v předcházející aktivitě schváleno. 15 % tedy putuje zpět dodavateli. • Aktualizace ERP softwaru se s předchozí schvalovací aktivitou řadí mezi nej náročnější z pohledu času. Opět zde záleží na množství položek v dokladu, ale průměrně se doba zpracování pohybuje kolem 4 minut najeden zpracovaný doklad. Opět tedy byla zvolena Poissonova distribuce s průměrem 4 minuty. • Kontrola splatnosti dokladu je otázka 0,5 minuty, protože finanční asistent pouze rozklikne zvolený doklad a zkontroluje datum splatnosti. Z týdenních reportů již má přehled, jak je na tom firemní cash flow a podle toho fakturu posouvá k zaplacení nebo zde proces končí. • U rozhodnutí o provedení platby to zde vychází zhruba půl na půl. Tzn., že u 50 % doklad splňuje podmínku pro zaplacení, u ostatních tato podmínka naplněna není hlavně kvůli vzdálené době splatnosti. • To-be procesní model zde má další bránu, která vyjadřuje objem dokladů, které jsou nad 10 tisíc korun. Nad tuto hranici se dostává pouze 25 % z celkového počtu dokladů. A u to-be procesního modelu tedy nově vydefinovanou cestou putuje 75 % dokladů. • Vytvoření platebního příkazu velmi usnadňuj e ERP software, a proto dobra zpracování u této aktivity je pouze 1,5 minuty. Zde nezáleží na složitosti faktury, protože ERP systém příkaz generuje automaticky. • Kontrola a provedení platby přes internetové bankovnictví zabere účetní 2,5 mi­ nuty. • U to-be procesního modelu aktivita zaplacení dokladu, která obsahuje nejen vytvoření příkazu k úhradě, ale také úhradu samotnou zabere 3 minuty. Této úspory je dosaženo vynecháním kontroly platebního, která jinak probíhala u účetního. Sledovaným obdobím byl pracovní týden, a z ERP bylo vysledováno, že průměrné množství zpracovaných závazků za toto období je 215. Takže úvodní počet vstupujících značek do simulace je nastaven rovněž na 215. 91 PŘÍPADOVÁ STUDIE BIZAGI Velice rychle ajednoduše nastavená procesní simulace bude sloužit především jako podklad, zdali a jak se procesní redesign vyplatí. Také majitel procesu a další zájmové skupiny se budou lépe přesvědčovat pro vstup do implementační fáze, s jasnými čísli a benefity pro ně plynoucími. Pro vyhodnocení výsledků byla použita tzv. what-if analýza, která je součástí Bizagi Modeler, v které se porovnávají výsledky z dvou scénářů (as-is a to-be procesní model). Výstupy z what-if analýzy se vyexportují do excelovské tabulky, kde jsou oba scénáře a jejich výsledky přehledně znázorněny. DEFINICE Cílem What-if analýzy je prozkoumat chování komplexních systémů, jako třeba korporátní společnosti nebo její části, při stanovených hypotézách, které se nazývají scénáře. V podstatě what-if analýza měří, jak změny v množině nezávislých proměnných ovlivňují množinu závislých proměnných s odkazem na specifický simulační model. (Golfarelli, et al, 2006) 1 600 Kč 1 400 Kč 1 200 Kč 1 000 Kč 800 Kč 600 Kč 400 Kč 200 Kč 0 Kč To-be Drocesní model As-is Drocesní model Obrázek 5-7: Náklady na finančního asistenta. Zdroj: vlastní zpracování První sešit ve vyexportovaných excelových výsledcích procesních simulací se zabývá využitelností zdrojů a náklady u těchto skupin zdrojů. Z výsledků analýzy tedy logicky vyplývá, že zátěž u finančních asistentů v to-be oproti as-is procesnímu modelu stoupla. Přesně z využitelnosti 1,96 % na 2,42 %. Tyto výsledky samozřejmě nejsou brány v kontextu ostatních procesů běžící na ekonomickém oddělení, a jehož jsou součástí procesní 92 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu účastníci ze sledovaného procesu. Proto procentuální vyjádření využitelnosti zdrojů odpovídá realitě, kdy mají na starosti i spoustu dalších aktivit. Jak lze logicky vyvodit u účetní využitelnost v to-be procesním modelu poklesla z 3,17 % na 2,4 %. Důležité je ovšem se na tyto rozdíly ve využitelnosti podívat z pohledu financí. Finanční asistent má sazbu 130,CZK na hodinu a účetní 160,- CZK. Z toho vyplývá, že úspora času u účetního bude více nákladově efektivní než úspora času u finančního asistenta. U finančního asistenta náklady u to-be procesního modelu vzrostly o 289,- CZK, avšak vlivem delegace jedné z aktivit od účetní k finančnímu asistentovi poklesly náklady na účetního o 593,- CZK, což v celkovém součtu dává úsporu 304,- C Z K u to-be procesního modelu. Pro hlubší analyzuje potřeba se podívat na simulační výsledky jednotlivých aktivit a podívat se i na další aspekt a tou je doba zpracování závazků. 250 200 50 0 • To-be procesní model • As-is procesní model Max. doba (min) Prům. doba (min) Obrázek 5-8: Doby zpracování u celkového procesu zpracování závazků. Zdroj: vlastní zpracování Výsledky jasně ukazují, jaká varianta j e z pohledu času více výhodnější. U as-is procesního modelu se maximální doba, za kterou se ve sledované firmě zpracuje závazek, pohybuje na úrovni 209 minut. Průměrná doba, jež trvá dokladu od přijetí až po jeho potencionální zaplacení nebo dovršení jiného konce procesuje 71 minut. U to-be procesního modelu jsou výsledky o poznání lepší. Maximální doba zde činí 77 minut a průměrná doba 26 minut, což je vylepšení výkonu procesu o neskutečných 273 %. Po další analýze simulačních dat procesní analytik došel k závěru, že za takto rozdílnými výsledky skutečně stojí vysoká míra přetížení účetní, která má na starosti jeden z nej náročnějších aktivit aktualizace ERP softwaru a do toho v poslední fázi procesu se stará o kontrolu platebních příkazů a následnou úhradu faktur, proto se častokrát stávalo, že se jedna z těchto aktivit zastavila a tím rostla doba zpracování celého sledovaného procesu. Tím pádem se jednalo o úzké místo, což se potvrdilo na datech. 93 PŘÍPADOVÁ STUDIE BIZAGI Na posledním obrázku 5.9 lze vidět, jak se úzké místo vytrácí i když se přímo do této aktivity v to-be procesním modelu nezasáhlo. 75 % dokladuje pod částku 10 tis. CZK a tím pádem jej v to-be procesním modelu může uhradit finanční asistent, který nepodléhá tak velké míře vytížení jako účetní. To uvolnilo více času pro účetní na aktivitu aktualizace ERP, a tak se již nestává, že by se právě u tohoto úzkého místa proces zpomalil nebo úplně zastavil. To opět dokládají výsledky, kdy se maximální doba zpracování dokladu snížila ze 116 na 29 minut a průměrná doba ze 48 na 10 minut. 140 120 • To-be procesní model • As-is procesní model Max. doba (min) Prům. doba (min) Obrázek 5-9: Doby zpracování u aktivity aktualizace v ERP systému. Zdroj: vlastní zpracování Na datech z procesní simulace se tedy potvrdilo, že to-be procesní model je daleko efektívnej ší, jak z pohledu času, tak i z pohledu nákladů, a proto se zvolil jako vstup do další fáze životního cyklu BPM, kterou je implementace procesů. 5.5 Implementace procesu zpracování závazků Implementace bývá nej náročnější fází v rámci životního cyklu BPM, a proto je potřeba, aby všechny předešlé fáze předcházely, jinak by mohla nastat situace, kterájiž ve sledované firmě dříve nastala, a to je implementace nepřipraveného a nezanalyzovaného procesu. Ve firmě se přeskočila jakákoli fáze analýzy procesu a ihned se postoupilo k implementaci a automatizaci as-is procesu. To samozřejmě není správný postup, protože celková efektivita tohoto procesu je nízká a tím pádem bude efektivita nižší i po implementaci či automatizaci tohoto procesu. Implementace procesů již probíhá v rozhraní druhého programu z balíku Bizagi a tím je Bizagi Studio. Jak bylo řečeno, tato fáze bývá náročná, a to hlavně z IT pohledu. I když 94 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu prostředí Bizagi Studio je velice přívětivé. Smyslem této části případové studie není vysvětlovat technické detaily implementace ukázkového procesu v Bizagi Studio, ale spíše nastínit postup, jakým tato implementace probíhá, j aké j sou její výstupy a celkový význam pro podnik. Celá implementace je přímo navázána na procesní model z Bizagi Modeler, který se automaticky exportuje do Bizagi Studio a zde samotná implementace začíná. Je rozdělena do několika na sebe navazujících kroků, které budou v této části postupně představeny včetně obecné ukázky implementace procesu zpracování závazků. 5.5.1 DATA MODEL Prvním krokem je vytvoření tzv. Data modelu. Ten obsahuje všechny informace, s kterými bude ukázkový proces dále pracovat a také zobrazovat v pracovním portále a při samotné exekuci procesu od koncových uživatelů. Hlavní entita v ukázkovém procesuje doklad (faktura). Hlavními atributy dokladu jsou např.: produkty, celková částka, daně, číslo dokladu, informace o dodavateli, datum vystavení, splatnosti a zdanitelného plnění, informace o způsobu platby atd. Doklad je provázán s objednávkou a produkty, viz obrázek 5-10. Purchase Order ®' _ A linbuies E R P =-":-as« O O C - V J :i = . : - ; ; ; : - : - • í l ž t ":•! ľ:sft -.-•5" z. V : ; t.M r.oces Cca; 1_ Relators II : - : : : Í — r.šľ •:-i \:: : : .it il - Í 1-1 - í "í"' ' _l Attnbi/tes •tC >»*•>•« **C S-c© f *•»-**• « c w •bc M I H - Relations ua< tí - -j« Invoiced Product _ Attributes . • 3.SV-. , • =-:s A - ľ. s::. „ř =-:Í •bc Ksc-rr-y Obrázek 5-10: Data model. Zdroj: upravené podle https://www.bizagi.com/processcentral/Documents/a492d863- 2d50-4170-a4d9-3e28e062ffl6/docs/Accounts%20Payable%20-%20Const.pdf 95 PŘÍPADOVÁ STUDIE BIZAGI Další možnost v tomto kroku spočívá ve vytvoření parametrových tabulek. Na obrázku 5-10 jsou v zeleném provedení a slouží k používání často se opakujících informací. V případě ukázkového procesu to je např. informace o dodavateli. Kdyby se parametrové tabulky nepoužívaly, musely by se informace o dodavateli vkládat pokaždé manuálně. Takhle se manuálně vytvoří pouze jednou a později se již pouze zvolí dodavatel a ostatní informace o něm se vyplní automaticky. 5.5.2 TVORBA FORMULÁŘŮ Jakmile je data model připraven postoupí se k tvorbě formulářů spojených s každou jednotlivou aktivitou v procesu vyžadující lidskou interakci. Formuláře utváří rozhraní, které slouží pro zobrazování a vkládání požadovaných informací vyplývajících z data modelu, aby koncový uživatel (účastník procesu) mohl proces vykonávat. Designování formulářů používá pole zadána v data modelu a jednoduchým způsobem si lze přizpůsobovat vzhled formulářů dle vlastní potřeby V ukázkovém procesu zpracování závazků lze tvorbu formulářů ukázat na příkladu, kdy u druhé aktivity v procesu - ověření dokladu, probíhá porovnání, jestli doklad sedí s objednávkou. Na obrázku 5-11 je zobrazeno navržené rozhraní, pro vyhledávání přijatých dokladů podle předem stanovených kritérií. Order number: Order dal« rJdMMfty» Supplier: Total Cost: Obrázek 5-11: Data model. Zdroj: upravené podle https://www.bizagi.com/processcentral/Documents/a492d863- 2d50-4170-a4d9-3e28e062ffl6/docs/Accounts%20Payable%20-%20Const.pdf 5.5.3 OBCHODNÍ PRAVIDLA Další krok v implementaci procesu je definice obchodních pravidel, která kontrolují směřování procesu, vznikající u každých bran. První a pro tento proces nej důležitější jsou pravidla přechodová. Určují, za jakých podmínek proces bude směřovat jakou cestou. Souvisí s branami v procesním modelu a mají hodnoty pravda nebo nepravda. V ukázkovém procesu jsou pouze exkluzivní brány (XOR-split brány), proto se zde nastavování podmínek řídí stejnými principy. Na obrázku 5-12 je zobrazeno nastavování 96 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu pravidla pro druhou bránu v procesu, která určuje, jestli je potřeba schválení produktu/služby od administrativního manažera. Lze tedy vidět dvě podmínky jednou z nich je potřeba inspekce pro schválení, kde výsledek je buď pravda, nebo nepravda a druhá podmínka značí, že pokud doklad nesouvisí s žádnou objednávkou, aktivita schvalování produktu/služby není k dispozici. Dále je v tomto kroku možné nastavovat tzv. Activity actions (činnosti), které opět slouží pro automatizaci některých mezikroků a pro ulehčení výkonu procesů uživatelům. Tvoří se zde pravidla pro automatické vyplnění požadovaných polí u opakujících se dat. V ukázkovém procesu to např. znamená, že při spárování objednávky s dokladem se některé informace z objednávky automaticky nahrají do faktury a naopak. Obrázek 5-12: Tvorba obchodní pravidel. Zdroj: upravené podle https://www.bizagi.com/processcentral/Documents/a492d863- 2d50-4170-a4d9-3e28e062ffl6/docs/Accounts%20Payable%20-%20Const.pdf 5.5.4 UŽIVATELÉ Přidělování zdrojů je velice důležitá část v implementaci procesu. Zodpovědní vykonavatelé procesu dostávají v tomto kroku přidělené aktivity. Také zde probíhá identifikace vztahů existující mezi různými zaměstnanci, což vychází z charakteristických proměnných, které rozlišují jednotlivé zdroje. Díky této funkcionalitě Bizagi inteligentně alokuje aktivity různým zaměstnancům v podniku. Takže nejdříve je důležité určit, jak by se měly vhodně přidělovat aktivity. 97 PŘÍPADOVÁ STUDIE BIZAGI V ukázkovém procesuje situace jednodušší, protože na každé pozici existuje právě jeden zdroj (zaměstnanec). Takže úvodní přidělování probíhá podle rolí, znázorněných v procesním modelu. Žádné další podmínky ani proměnné zde nastavovat není potřeba, protože jednotlivé aktivity bude mít k dispozici pro jejich exekuci právě jeden konkrétní zdroj. tm Performers Preconditions O X Assignation method: By load T 0 And 0 Or 0 Cond^tor Sä A ways Role = = Financial Assistant e Ok Cancel Obrázek 5-13: Přidělování zdrojů. Zdroj: upravené podle https://www.bizagi.com/processcentral/Documents/a492d863- 2d50-4170-a4d9-3e28e062ffl6/docs/Accounts%20Payable%20-%20Const.pdf 5.5.5 INTEGRACE Praktický výkon procesu zpracování závazků by mohl probíhat i bez kroku integrace, ale znamenalo by to nutnost v ukázkovém procesu v průběhu vystoupit z prostředí Bizagi a vykonat aktivitu aktualizace ERP systému právě ve firemním ERP systému, což se nejeví jako efektivní. Bizagi nabízí možnost integrovat jej s dalšími firemními systémy, ať již formou předefinovaných konektorů, které jsou zdarma k stažení na webovém portále Bizagi. com, tak také prostřednictvím tzv. API, kde je již propojení daleko složitější, avšak může uspokojit individuální potřeby procesních účastníků. PRO ZÁJEMCE API (Application Programming Interface) obecně se jedná o soubor přesně definovaných metod, pomocí kterých komunikují různé softwarové komponenty. Uvedeno na příkladu, komunikace mezi dvěma softwary: Budovaná aplikace (může být i Bizagi) najde současný stav měnového kurzu tím, že pošle strukturovanou zprávu do API webu kurzy.cz (pokud má API) a tato API následně odpoví obdobně strukturovanou zprávou naší aplikaci, která přijatou informaci již může využít dle předem definovaného postupu. Jak tedy bylo řečeno jediná integrace v ukázkovém procesuje s ERP softwarem, kam se zanáší informace z dokladu. Konkrétně je potřeba, aby informace zanesené do Bizagi formuláře se automaticky a správně přenesly do ERP systému. Ve sledované firmě se o toto propojení postaral pracovník z IT oddělení a další podrobnosti zde nebudou rozebrány. 98 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu 5.5.6 EXEKUCE PROCESU A PRACOVNÍ PORTÁL Posledním krokem je nastavení pracovního portálu a testování a validace implementovaného procesu pro ostré nasazení. Testovací exekuce procesu a rozhraní pro procesní účastníky je znázorněno na obrázku 5-14. Pracovní portál tedy slouží pro všechny osoby zúčastněné na procesu a lze jej individuálně přizpůsobovat a definovat dle potřeby jednotlivců. Toto rozhraní ještě neslouží pro finální výkon procesů, to bude probíhat až v rozhraní programu Bizagi Engine. • All Processes ílu Users ' T licenses > P Entitles s? Cases Q M a m s > cryption Obrázek 5-14: Pracovní portál Bizagi Studio. Zdroj: upravené podle https://www.bizagi.com/processcentral/Documents/a492d863- 2d50-4170-a4d9-3e28e062ffl6/docs/Accounts%20Payable%20-%20Const.pdf V tomto kroku se taktéž vytváří účty pro jednotlivé zaměstnance a procesní účastníky, pod kterými se do pracovního portálu budou přihlašovat. Testování probíhá tak, že se vytvoří nový případ (case), který značí přijetí dokladu do firmy. Celý proces se tak se všemi procesními účastníky proj de ve všech možných scénářích a hledají se možné chyby a špatné či neefektivní nastavení. Pro celkový hladký průběh je v ukázkové firmě zapotřebí zorganizovat školení, které bude představovat způsob práce v pracovním portále Bizagi. Nejedná se o složitý systém a v kombinaci se znalostí ukázkového procesu procesními účastníky se adopce nového systému rychle uchytí. Tím, že zatím žádné další procesy se v rozhraní Bizagi nerealizují, efektivita není zatím na tak vysoké úrovni, avšak s přibývajícím množstvím procesů, se bude zlepšovat. 5.6 Monitorování a kontrola ukázkového procesu Poslední fáze životního cyklu BPM je zastoupena v posledním programu z balíčku Bizagi a tím je Bizagi Engine. Jak bylo zmíněno na začátku této kapitoly, jedná se o jediný program z balíku, který je placený. Nacenění probíhá individuálně, takže veřejně není 99 PŘÍPADOVÁ STUDIE BIZAGI k dispozici žádný ani orientační ceník. Výhoda takto zvolené metody placení pro firmy spočívá v tom, že až pokud skrze použití Bizagi Modeler a Bizagi Studio, vidí přínosy pro podnik a procesní řízení v něm, pustí se do ostrého provozu a zavádění funkčních redesignovaných procesů a teprve v této fázi platí za využití služeb Bizagi. Důležité je zmínit, že v této případové studii se již nebude pracovat s reálnými daty ze sledovaného podniku, protože finální implementace a ostrý provoz, se v době tvorby případové studie teprve připravoval - fáze implementace. Avšak v rámci udržení celistvosti případové studie je zapotřebí si ukázat i možnosti a prvky v Bizagi Engine, které se budou v budoucnu v případovém podniku používat. Procesní aplikace V rámci ukázkového procesu se po kompletní implementaci v Bizagi Studio přesuneme v doručení těchto funkčních procesní aplikací (rozhraní Bizagi) k jednotlivým zaměstnancům, kteří vykonávají roli procesního účastník nebo procesního majitele u procesu zpracování závazků. Bizagi Engine umožňuje, aby tito zaměstnanci proces vykonávali, jak ze svých obvyklých pracovišť (PC) tak i z tabletu či mobilů, a to nejen v jejich stabilním pracovním místě. To proto podporuje mobilitu zaměstnanců včetně možnosti zavádět, v těchto dobách oblíbené, práce z domu nebo to v budoucnu využijí zaměstnanci, často cestující mimo prostory firmy, např. obchodní zástupci. bizagi Q All Cases 7 • Access Management 0 Access Management 2 » Purchase New Case * ( \ Queries * Reports ' {o)> Admin ' * 'žo Q * *ío Q, * %> a * •k Q. * la O. * to Q Process Access Management Accounts Payable Purchase Request Travel Request Travel Request Purchase Request Access Management Activity • Enter Permission Request • Receive Invoice • Create Purchase Request • Approve Travel Request • Register Travel Request • Create Purchase Request • Enter Permission Request Case creation date 4/14/2016 4.08 pm 4/14/20164:12 pm 4/14/20164:12 pm 4/21/201612:12am 4/21/2016 12:14am 4/21/2016 12:14am 4/21/2016 12:19am Activity due date 4/15/2016 11:08 am 4/15/20164:12 pm 4/14/20165:12pm 4/21/2016 1200 pm 4/21/201612:00 pm 4/21/2016 W)0 am 4/21/20163:00 pm © Case due date 4/14/20164:08 pm 4/18/20164:12 pm 4/22/20164:12 pm 4/25/2016 6:00 pm 4/25/2016 6:00 pm 4/28/2016 6:00 pm 4/21/2016 12:19am bizagi Obrázek 5-15: Pracovní portál Bizagi engine. Zdroj: upravené podle https://www.bizagi.com/processcentral/Documents/a492d863- 2d50-4170-a4d9-3e28e062ffl6/docs/Accounts%20Payable%20-%20Const.pdf Na obrázku 5-15 je zobrazen pracovní portál aplikace Bizagi Engine, ve kterém, po finálním zavedení, všichni pracovníci operují. Je složen z několika částí a nabízí různé funkce velmi dobře použitelné a ulehčující práci. Na horní liště (hlavní menu) je např. zá- 100 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu lôžka Inbox (přímo zobrazená na obrázku 5-15). V ní se zobrazují aktivity čekající na zpracování, schválení nebo další akci od procesního účastníka přihlášeného do portálu. Lze je seřadit i dle priorít a ty se značí barvou. V levém sloupci (prípady) lze vidět, do jakých firemních procesuje zaměstnanec zapojen. Jsou seřazeny do záložek např. podle typu nebo jiných kritérií. Samotná exekuce procesuje zde znázorněná v záložce nové případy (New Case). Tzn., že každé jedno zpracování dokladu v procesu zpracování závazků bude bráno jako samostatný případ. Hlavním účelem z pohledu monitorování a kontroly procesuje určitě schopnost tvořit reporty a vyhodnocovat kompletní průběh sledovaných procesů podle velkého množství předefinovaných ukazatelů. V poli reportuje tedy možné monitorovat tyto výkonové uka­ zatele: • Čas cyklu - souhrn počtu uzavřených (hotových) případů včetně výčtu dat za celý proces, jakými jsou např. průměrná doba zpracování, standardní odchylka atd. • Histogram - zobrazuje, za jakou dobu se podařilo ve firmě sledovaný proces zpracovat. Vertikální přerušovaná linka (obrázek 5-16) odděluje včasné případy od zpožděných. • Procesní aktivita - tento report pracuje s celkovými čísly. Takže kolik bylo otevřených případů celkem, kolik z nich se dokončilo, kolik bylo přerušeno a také zde lze zobrazit dlouhodobý trend v celkovém množství vykonaných procesů (případů). • Analýza frekventovaných cest - další zajímavá data ukazují (na procesním modelu) jaké jsou nej častější cesty, kterými se jednotlivé případy ubírají. To samozřejmě ukazuje, jako jsou nejběžnější cesty u většiny procesů a poskytuje to tak důležité informace k dalšímu rozhodování. • Analýza aktivit - pro skutečně cenné vhledy je zapotřebí jít do vyšší úrovně podrobnosti procesu, a to na úroveň aktivit. Zde se tedy zobrazují data z výkonu jednotlivých úkonů a těmi jsou průměrná doba trvání, očekávaná doba trvání, počet úkonů provedených včas apod. • Analýza případů - poslední reportingový výstup jde opět do hloubky procesu a je v něm možné vybrat konkrétní případ a podívat se blíže na jeho průběh z pohledu doby trvání jak celkového případu, tak i konkrétní aktivity v něm. Slouží pro analýzu odchylek a výjimek v procesu. Veškeré reporty lze vyexportovat do excel formátu a dále s nimi pracovat. Po dokončení první iterace v životním cyklu BPM, by se v podniku měla podrobit celá iniciativa zpětnému vyhodnocení a také by se měl nastartovat další cyklus, který již bude budovat na vzniklé procesní architektuře a zkušenostech z předcházejícího cyklu. Postup zůstane 101 PŘÍPADOVÁ STUDIE BIZAGI stejný, jenom se firma může rozhodnout, že do dalšího projektu zapojí více procesů. Síla B P M systému Bizagi spočívá v tom, že pokud se všechny operativní procesy podrobí podobnému postupu, jaký byl předveden v této případové studii, může celá firma fungovat na balíku Bizagi softwaru a stát se tak procesně orientovanou firmou s vyšší šancí na dosažení maximální provozní efektivity a úspěšné splnění dalších vytyčených cílů. bizogi 5 Inbo« New Case " CX_ Queries • ITtTI Reports ' Admin T Q. Cycle Trne Duration Histogram Process Activity ACQvation Ranking Frequents Paths U M HÍIWD VI7.'ZD10 Vacation Laave Request - 1 0 ' ^ ? Ada Dimension 3W2C13 5/17,? Q16 I I " * ] [ 1gm 3m 1 | 5fl id ^ Save Report 700 657 j mo , at 400 — 100 4 I 1 • • 7 I < ! M I Ö 1 2 3 4 5 & 7 8 9 1Ü 11 12 13 NentDays • Duration Duration Histogram This dial A M how many days closed cases have taken to complete The vertical dashed line separates on 1 me cases horn overdue cases Obrázek 5-16: Report histogramu trvání. Zdroj: upravené podle https://www.bizagi.com/processcentral/Documents/a492d863- 2d50-4170-a4d9-3e28e062ffl6/docs/Accounts%20Payable%20-%20Const.pdf ŘEŠENÁ ÚLOHA Řešení úlohy z podkapitoly 5.2.1: Vybrané firemní procesy: • Nábor zaměstnanců - podpůrný proces • zpracování dokladů - podpůrný proces • prototypování nového produktu - klíčový proces • tvorba plánu výroby - řídící proces • vytvoření požadavku na nákup - podpůrný proces 102 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu • hodnocení kvartální výkonnosti podniku - řídící proces I když by se mohlo zdát, z pohledu vzájemného vztahu, organizační struktura nijak nesouvisí s procesní architekturou. Procesní architektura se buduje za předem jasných pravidel a podle specifické metodiky, oproti tomu organizační struktura může nabývat různých podob v závislosti na zvoleném manažerském přístupu vedení podniku. Organizační struktura slouží jako vhodný materiál vstupující do procesu budování procesní architektury, avšak vzájemný vztah zde nefunguje - tzn. nelze z organizační struktury odvodit procesní architekturu a obráceně. ŘEŠENÁ ÚLOHA Řešení úlohy z podkapitoly 5.4.1: • Vyplnění požadavku (předák výroby) - aktivita přidávající hodnotu • Poslání požadavku na ekonomické oddělení (předák výroby) - aktivita nepřidávající hodnotu • Otevření a přečtení požadavku (administrativní pracovník) - aktivita nepřidávající hodnotu • Výběr chybějícího vybavení (administrativní pracovník) - aktivita přidávající hodnotu • Kontrola dostupnosti vybavení (administrativní pracovník) - aktivita přidávající hodnotu • Tvorba požadavků na nákup (administrativní pracovník) - aktivita přidávající hodnotu • Zaslání požadavku vedoucímu výroby (administrativní pracovník) - aktivita nepřidávající hodnotu • Komunikace nejasností (vedoucí výroby) - aktivita přidávající hodnotu firmě • Přeposlání požadavku zpět administrativnímu pracovníkovi (vedoucí výroby) aktivita nepřidávající hodnotu • Tvorba objednávky (administrativní pracovník) - aktivita přidávající hodnotu firmě 103 PŘÍPADOVÁ STUDIE BIZAGI • Zaslání objednávky dodavateli (administrativní pracovník) - aktivita přidávající hodnotu OTÁZKY 1. Z jakých částí se skládá balík Bizagi a k čemu se používá? 2. Jakým způsobem se přistupuje k budování as-is procesního modelu? 3. K čemu se v praxi využívají simulace podnikových procesů? 4. Jak probíhá implementace procesu v Bizagil 5. Jaké jsou hlavní ukazatele, které je vhodné sledovat při analýze výkonnosti procesů? SHRNUTÍ KAPITOLY V této kapitole bylo představeno praktické využití životního cyklu B P M prostřednictvím případové studie a za pomocí softwaru Bizagi. Každá fáze životního cyklu BPM je zde zastoupena včetně technik a nástrojů používající se v procesním řízení v praxi. ODPOVĚDI 1. Podkapitola 5.1. 2. Podkapitola 5.2. 3. Podkapitola 5.4, str. 84. 4. Podkapitola 5.4.2. 104 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu 6 PROCESS MINING RÝCHLYNAHLED KAPITOLY V posledních letech si podniky uvědomily, kolik užitečných informací se skrývá ve velkých objemech dat, které buďto samy produkují, anebo ke kterým mají přístup. Z tohoto důvodu se podniky uchýlily k zařazení datových věd do svého arzenálu nástrojů, kterými se snaží zajistit prosperitu sobě i svému okolí, zvýšit svou konkurenceschopnost a efektivitu, snížit své náklady, zabránit plýtvání zdroji apod. To vše nás přivádí k pojmu process mining. Process mining je disciplína sjednocující B P M a datové vědy. Tvoří tak jakýsi most mezi procesní a datovou vědou. Jednoduše řečeno, process mining se snaží získat informace o podnikových procesech ukryté v podnikových datech. Tato data neboli tzv. události jsou zaznamenávány podnikovými informačními systémy, které jsou stále více a více propojeny s operačními procesy podniků. Process mining tak poskytuje celou řadu nových metod, které lze využít pro modelování či redesign podnikových procesů, a je schopen odstranit některé nedostatky metod z předchozích kapitol. V této kapitole se tak seznámíme se základními pojmy vážícími se na process mining. CILE KAPITOLY Po prostudování této kapitoly budete umět: • Objasnit podstatu process miningu. • Popsat data potřebná pro process mining a určit zdroje těchto dat. • Objasnit základní typy process miningu a využít Petriho sítě pro reprezentaci modelů. • Vysvětlit podstatu vybraných process miningových metod. 0 Process mining, objevování procesů, zjišťování shodnosti, Petriho sítě, záznamy, stopy, události. 105 PROCESS MINING V následující podkapitole si představíme základní pojmy proces miningu. Tyto základní pojmy si uvedeme v kontextu B P M životního cyklu (více kapitola 4). Představíme si základní typy proces miningu - objevování, zjišťování shodnosti a zlepšování podnikových procesů. Vzhledem k účelu tohoto textu se budeme do detailu věnovat pouze prvním dvěma typům, a sice objevování a zjišťování shodnosti. Zlepšování podnikových procesů zmíníme jen okrajově. 6.1 Podstata a základní pojmy process miningu Process mining je relativně mladá disciplína, jejíž počátky sahají do konce devadesátých let minulého století. Účelem process miningu bylo vyplnit pomyslnou díru mezi přístupy machine learningu a data miningu na jedné straně a procesního modelování a analýzy na straně druhé. Jelikož zatímco machine learning a data mining nebraly v potaz podnikové procesy, procesní modelování a analýza nepracovaly s dostupnými daty. Process mining tak spojuje procesní a datový přístup v jeden. Tento přístup nabyl na významu zejména v posledních letech v důsledku nových technologií (především ICT) a jejich penetrace napříč podnikatelskými jednotkami. Tyto podnikatelské jednotky generují velké objemy dat, u kterých roste potřeba jejich zpracování. Data potřebná pro process mining jsou generována skupinou informačních systémů zvanou Process-Aware Information Systems (PAIS). DEFINICE PAIS zahrnují takové informační systémy, které podporují celý proces namísto pouze izolovaných aktivit. Příklady takových informačních systémů mohou býti ERP (Enterprise Resource Planning) systémy jako notoricky známý SAP, C R M (Customer Relationship Management) systémy, W F M systémy a další. PAIS systémy produkují potřebná data přímo, zatímco u ostatních typů informačních systémů může být zapotřebí je předzpracovat do vhodné podoby. PRO ZÁJEMCE Pro zájemce, kteří by se chtěli o PAIS dozvědět více, odkazujeme na práci Dumas, Aalst a Hofstede (2005). 106 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu Za průkopnické v oblasti process miningu můžeme označit práce Cooka a Wolfa (1996) a také Agrawala, Gunopulose a Leymanna (1999). Cook a Wolf se věnovali objevování softwarových procesů z na událostech založených dat, a právě oni přišli s technikou objevování procesů. Ve svém článku srovnávali jimi vyvinutou statisticko-algoritmickou techniku zvanou Markovova metoda, kterou porovnávali se dvěma dalšími metodami přebranými z dalších dvou domén, které byly upraveny pro potřeby objevování procesů. Dalšími dvěma metodami byla tak zvaná KTail metoda a RNet metoda. Zatímco KTail metoda byla čistě algoritmická, RNet metoda byla čistě statistická. Autoři dospěli k názoru, že KTail metoda a Markovova metoda jsou slibným začátkem, zatímco RNet metoda založená na neuronových sítích, ještě není zralá pro praktickou aplikaci. Autoři také předpověděli, že největší potenciál vidí v algoritmickém přístupu. Tuto jejich domněnku můžeme s odstupem času potvrdit, jelikož naprostá většina doposud vyvinutých metod je založena na algoritmickém přístupu nebo je jeho kombinací. Agrawal, Gunopulos a Leymann (1999) představili ve své práci algoritmus, který byl schopen modelovat podnikový proces v podobě grafu na základě existujících logů. Autory výše můžeme označit za průkopníky, kteří stáli u zrodu této disciplíny. Nicméně nej vlivnější postavou v oblasti process miningu byl a stále je profesor Aalst, a to zejména kvůli komplexnímu přístupu k tomuto tématu, a to nejen jeho přístup, ale i přístup skupiny, kterou v této oblasti vede na Technické univerzitě vEindhovenu. Pojem process miningu poprvé představili ve své práci Weijters a Aalst (2001). DEFINICE Process mining, je výpočetní proces zaměřený na identifikaci skrytých vzorů a trendů vyskytujících se v datech, umožňující modelování a analýzu podnikových procesů na základě dat ve formě záznamů. Process mining se zaměřuje na zvyšování efektivity a porozumění podnikových procesů. Záznam, Ještě než si představíme tři základní typy process miningu, pojďme si přiblížit, na čem připadá j sou vlastně process miningové analýzy zpracovávány. Abychom byli schopni provést pro- s í o p a cess miningovou analýzu, potřebujeme, aby se data vyskytovala v potřebném formátu. Taková data jsou v rámci process miningu označována jako záznamy. Předpokládejme, že je možné sekvenčně zachytit události tak, že každá událost odpovídá jedné aktivitě a je spojena s právě jedním případem neboli instancí procesu. Skupině událostí jedné instance procesu poté říkáme stopa. Uvědomme si, že tatáž stopa může reprezentovat několik případů. Množinu případů reprezentovaných jednotlivými vykonanými aktivitami poté označujeme jako záznam. 107 PROCESS MINING PŘÍPADOVÁ STUDIE Uvažujme jednoduchý proces výběru hotovosti z bankomatu a následující množinu čtyř aktivit, které nám tento bankomat umožňuje provádět {Přihlášení,Výběr hotovosti,Kontrola zůstatku, Odhlášení}. Příkladem stopy poté může býti ox = (Přihlášení, Výběr hotovosti, Odhlášení) nebo Informační systém Specifikace Konfigurace a Implementace Analýz Objevování Zjišťování shodnosti Zlepšování Záznamy Záznam Obrázek 6-1: Pozice tří základních typů process miningu: objevování, zjišťování shodnosti a zlepšování podnikových procesů Zdroj: upraveno podle Aalsta (2016) Třetím typem process miningu je zlepšování. Podstatou tohoto přistupuje rozšíření či z l e P s o v a r " vylepšení existujícího procesu s využitím informací o tomto modelu vyskytujících se v záznamu o tomto procesu. V rámci zlepšování podnikových procesů jsou tedy využívány i výsledky předchozích dvou typů process miningu. V následující kapitole si ukážeme, že záznamy, kromě dat nutných pro process mining mohou obsahovat také záznamy jako časová značka, zdroj a podobně. Tato dodatečná data umožňují zkoumat další perspektivy jako časová, organizační či případová, které lze využít při zlepšování podnikových procesů. Tyto perspektivy lze samozřejmě využít i u předchozích dvou typů process miningu. Některým perspektivám, jako například analýze sociálních sítí, se budeme v pozdějších kapi­ tolách. Existuj ej eště čtvrtý typ process miningu zvaný operační podpora, který začíná nabývat ° P e r a č n í podpora na významnosti zejména v posledních letech. V předchozích typech se pracuje s daty již ukončených procesů, tedy s daty z minulosti. Zatímco v operační podpoře se pracuje s daty z právě probíhajících procesů. Tato data bývají často doplněna také o data z minulosti, jelikož je často vhodné v rámci operační podpory pracovat také s informacemi získanými z předchozích tří typů. Nicméně operační podpoře se v tomto skriptu již více věnovat nebudeme. Jak můžete vidět z dosavadního povídání, process mining dnes zdaleka není pouze 109 PROCESS MINING o objevování procesů, nýbrž process mining je schopen nabídnout vhodné nástroje v prakticky všech fázích životního cyklu BPM. Operační podpoře se však hlouběji věnovat nebudeme, jelikož je nad rámec tohoto textu. | V I K ZAPAMATOVÁNÍ V rámci process miningu je velmi důležité odlišovat mezi modelem procesu a realitou zachycenou ve formě záznamu, proto rozlišujeme tři základní pojmy, které nemají v českém jazyce obdobu, a proto je pro naše potřeby přebereme z angličtiny. Prvním z pojmů je Play-Out, který referuje klasické použití modelů procesů. Budemeli uvažovat například Petriho síť, potom je možnost vygenerovat chování. Například budeme-li mít Petriho síť Nt z kapitoly 6.3 přehráváním značek bychom byly schopni získat záznam Lx. Play-Out se tak využívá pro analýzu a ustanovení správných podnikových procesů. Například jde s využitím vhodného softwaru, jako je Disco či ProM, simulovat chování daného modelu. Model bude opakovaně exekuovaný a v rámci simulace budou zachycovány různé statistiky. Druhým pojmem je Play-In. V tomto případě máme k dispozici data například v podobě záznamu a cílem je zkonstruovat model. Play-In je tedy opakem Play-Out. pod pojmem Play-In si tak můžeme představit různé přístupy k objevování podnikových procesů, jako například Alfa-algoritmus. Pojem Replay je svým způsobem kombinací předchozích dvou pojmů, jelikož v tomto případě je k dispozici nejen záznam, ale i daný model. Daný záznam je přehráván na daném modelu. Replay je používán zejména v případě zjišťování shodnosti, konstruování prediktivních modelů či v případě operační podpory. PRO ZÁJEMCE V anglické literatuře jsou pojmy používané v tomto skriptu označovány následovně: záznamy jsou označovány slovy log nebo event log, události jsou označovány jako event, aktivity jako activity, případy neboli instance procesu jako case a stopa jako trace. 6.2 Data potřebná pro process mining V předchozí kapitole jsme si přiblížili vznik process miningu a představili jsme si základní pojmy z této oblasti. Ještě než se pustíme do samotných metod, řekneme si něco více k datům potřebným pro process mining, co reprezentují, jakých formátů mohou nabývat, 110 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu co musí a nemusí obsahovat a další potřebné náležitosti. Je potřeba si uvědomit, že jelikož má process mining své kořeny v datových vědách, kvalitní data jsou základním pilířem process miningu. Kvalita dat tak značně ovlivní kvalitu dosažených výsledků. Budete-li tedy praktikovat process mining, musíte mít na paměti, že přípravě a práci s daty budete muset věnovat značnou část Vašeho časového fondu v rámci process miningových analýz. Různé zdroje dat Extrakce, Transformace a nahrávání (ETL'i iExtrakce Nefiltrované záznamy XES, M X M L , Process mining Objevování Ziistovani ľ , . Zlepšovaní shodnosti ť =1 Filtrované záznamynamy l Odpovědi Obrázek 6-2: Workflow od heterogenních dat k process miningovým výsledkům Zdroj: upraveno podle Aalsta (2016) Počátečním bodem pro process miningovou analyzuje extrakce často nestrukturovaných dat ukrytých ve všech možných datových zdrojích. Zdroji dat mohou být prosté databázové soubory, excelovské tabulky nebo relační databáze. Tyto datové zdroje se však mohou nacházet napříč několika odděleními či dokonce napříč několika firmami. Nestruk- 111 PROCESS MINING turovaná data mohou pocházet z například z webových stránek, emailů atd., ale i strukturovaná data z podnikových informačních systémů mohou být často oříškem vzhledem ke komplexnosti těchto systémů. Obrázek výše popisuje workflow spojené se získáváním process miningových výsledků z heterogenních dat. ETL (neboli Extraction, Transformation andLoading) popisuje v oblasti zvané Business Intelligence (BI) proces složený ze tří fází: (1) extrakce dat z vnějších zdrojů, (2) transformace dat do podoby potřebné pro další zpracování a (3) nahrání dat do cíleného systému (jako je například datový sklad). Datové sklady umožňují uskladnit operační a transakční data. Je potřeba si uvědomit, že tyto datové zdroje častokrát budou obsahovat i data nevztahující se k analyzovanému procesu, určení správného rozsahu dat, které z těchto zdrojů využijeme při tvorbě záznamů, je proto velmi důležité. Záznamy extrahované z různých datových zdrojů musejí být často podrobeny předzpracování v podobě různých filtrů a dalších metod ještě před samotnou process miningovou analýzou v důsledku jejich nestrukturovanosti. Některé filtry a další metody využívané pro předzpracování záznamů si představíme až v kapitolách věnovaných process miningovým softwarům Disco a ProM. Filtry jsou používány zejména v souvislosti s tzv. špagetovými procesy. Kromě špagetových procesů existují také lasagna procesy. Oba případy si představíme v podkapitole věnované softwaru Disco. 6.2.1 ZÁZNAMY Tabulka níže reprezentuje typické informace obsažené v záznamu pro potřeby process miningové analýzy. Obecně je předpokládáno, že jeden záznam obsahuje data týkající se jednoho procesu. Toto souvisí s výše debatovaným rozsahem použitých dat. V tabulce níže jsou obsažená data generovaná v rámci reklamačního procesu. Každá událost, v našem případě každý řádek, musí připadat právě jednomu případu neboli instanci procesu (v tabulce níže každé je každá událost (ID události) přiřazena právě jednomu případu (ID případu). Dále předpokládáme, že každá událost může býti reprezentována vykonanou aktivitou. Reprezentace událostí aktivitami je v rámci process miningu vcelku přirozená. Dalším nutným předpokladem je, že události jsou v rámci jednotlivých případů seřazeny, nejčastěji s využitím časových značek. Bez seřazení událostí samozřejmě není možné určit příčinné nebo kauzální závislost a tím model daného procesu. Tabulka 6-1: Část záznamu reklamačního procesu - každý řádek reprezentuje jednu událost ID případu ID události Časová značka Aktivita Zdroj 138521 15-10-2016:11.33 138522 16-10-2016:10.55 138523 16-10-2016:14.15 138524 16-10-2016:14.40 138525 17-10-2016:08.30 138531 15-10-2016:12.15 138532 15-10-2016:12.45 Registrace požadavku Důkladné prověření Kontrola účtenky Vydání rozhodnutí Oznámení o zamít­ nutí Registrace požadavku Kontrola účtenky Petr Monika Marcel Sára Petr Marcel Marcel 112 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu 138533 15- 10 -2016:13 05 Zběžné prověření Monika 138534 15- 10 -2016:13 35 Vydání rozhodnutí Sára 138535 16- 10 -2016:09 45 Vyplacení hotovosti Agáta 138625 25- 10 -2016:14 32 Registrace požadavku Petr 138626 25- 10 -2016:15 06 Zběžné prověření Monika 138627 25- 10 -2016:16 34 Kontrola účtenky Marcel 138628 28- 10 -2016:09 18 Vydání rozhodnutí Sára 138629 28- 10 -2016:12 18 Oznámení o zamít­ nutí Petr 138630 28- 10 -2016:13 06 Znovuotevření poža­ davku Sára 138631 29- 10 -2016:11 35 Důkladné prověření Monika 138632 29- 10 -2016:12 26 Kontrola účtenky Marcel 138633 30- 10 -2016:12 23 Vydání rozhodnutí Sára 138634 30- 10 -2016:12 45 Vyplacení hotovosti Agáta 138675 28- 10 -2016:15 02 Registrace požadavku Petr 138676 29- 10 -2016:12 06 Důkladné prověření Jozef 138677 29- 10 -2016:14 44 Kontrola účtenky Franti­ šek 138678 29- 10 -2016:15 44 Vydání rozhodnutí Sára 138679 30- 10 -2016:09 02 Oznámení o zamít- Petr Zdroj: upraveno podle Aalsta (2016) Tabulka 6-1 tedy reprezentuje typickou strukturu záznamu. Mimo to lze z tabulky výše vyvodit základní předpoklady očekávané u každého záznamu: • Každý proces j e tvořen z případů, • případy j sou tvořeny událostmi a to tak, že každá událost (ID události) se vyskytuje pouze v rámci jednoho případu (ID případu), • události v rámci případů jsou seřazeny, • události mohou mít atributy, jako například aktivita, časová značka, zdroj či cena. Minimální informace, kterou musí záznamy obsahovat, jsou tedy jednotlivé případy a v rámci nich seřazené události. Nicméně události mohou mít i další vlastnosti a tyto vlastnosti jsou nazývány atributy. Atributy mohou poskytnout další zajímavé perspektivy na zkoumaný proces. Například časové značky nám umožňují náhled do výkonnostní složky procesu, zatímco informace o zdrojích jednotlivých událostí nám umožňují náhled do organizační perspektivy. Ne všechny události musejí mít stejnou množinu atributů, ale typicky události vážící se k jedné a té samé aktivitě mívají stejnou množinu atributů. 113 PROCESS MINING DEFINICE Nechť £ je množina všech možných událostí. Události mohou býti charakterizovány atributy (např. událost může mít časovou značku, korespondovat s jistou aktivitou, být vykonána nějakou osobou atd.) Nechť AN je množina jmen atributů. Potom pro jakoukoliv událost e E £ a jméno n E AN je #n (e) hodnota atributu n události e. Jestliže událost e nemá atribut n, potom #n (e) =1 (nulová hodnota). Použijeme-li záznam v tabulce výše, pak $Aktivita (138521) = Registrace požadavku, #Zdroj (138521) = Petr, atd. Události jsou často referovány názvy příslušných aktivit, které reprezentují. Proto je nutné rozlišovat jednotlivé instance těchto aktivit, protože jak si za chvíli řekneme, každá událost se může v záznamu vyskytovat pouze jednou. Dále je třeba míti na paměti, že aktivity často, nějaký čas trvají a proto jedna aktivita může býti reprezentována několika událostmi. Ještě než si řekneme formální definici záznamu, povíme si něco blíže k posloupnostem. Posloupnosti jsou vhodným nástrojem pro reprezentaci stop v záznamech. Pro danou množinu A, je A* množina všech možných konečných posloupností nad množinou A. Konečná posloupnost nad množinou A délky n je funkce a E { 1 , 2 , n } -> A. Taková posloupnost může býti reprezentována řetězcem, např.: a = (alt a2,..., an), kde at = n: hdk (o) = a. Množina pre f (a) = {hdk (a)\0 •••>a n) j e posloupnost posledních k prvků posloupnosti a. Pro k = 0 je tlk (a) prázdná posloupnost a pro k > n: tlk (o) = a. Pro jakoukoliv posloupnost a = (av ) nad množinou A, dmnoiina konvertuje posloupnost v množinu, např.: dmnolina((a,a,b,b,a,b,b,b)) ={a,b}, a dmultimnolina konvertuje posloupnost v multimnožinu, např.: dmultimnolina((a,a,b,b,a,b,b,b)) = [a3 ,bs ]. Nyní, když víme co je to posloupnost a víme jak s nimi pracovat, pojďme si formálně nadefinovat případ, stopu a záznam. Nechť C je množina všech možných případů. Případy podobně jako události mohou mít různé atributy. Pro jakýkoliv případ c G (ľ a jméno n G AN platí, že #n (c) je hodnota 114 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu atributu n prípadu c (#n (c) =1, jestliže případ c nemá atribut n). Každý případ má speciální povinný atribut zvaný stopa #stopa (c ) e £*• c =#stopa (c)1 4 označuje ve zkratce stopu. Stopu tedy definujeme jako konečnou posloupnost událostí o G £*, ve které se každá událost objeví pouze jednou, tzn. pro 1 < i < j < \a\: , tedy že každá stopa v záznamu obsahuje alespoň jednu událost. 115 PROCESS MINING účely této teoretické kapitoly je tato definice až příliš detailní a proto si definujeme také tak zvaný zjednodušený záznam. DEFINICE Nechť je JI množina jmen aktivit, potom zjednodušená stopa uje posloupnost aktivit, tzn. a G JI*. Zjednodušený záznam L poté definujeme jako multimnožinu stop nad množinou JI, tzn. L G M(Jl*), kde M(Jl*) je zobrazení JI* -> N, například mějme multimnožinu X G K(D) pak je-li X = [ a 2 , ^ 1 ] potom X(Ď) = 3. Jak je možné vidět z definice výše, u zjednodušeného záznamu nepracujeme s atributy událostí, a události referujeme názvy odpovídajících aktivit. V následujícím textu budeme ve chvílích, kdy bude z kontextu jasné, že mluvíme o zjednodušeném záznamu, označovat jen jako záznam. Po zbytek kapitoly 6.1 budeme pracovat téměř výhradně se zjednodušeným záznamem. ŘEŠENÁ ÚLOHA Naším úkolem je transformovat záznam z tabulky 1 na zjednodušený záznam. Jak jsme si řekli v definici zjednodušeného záznamu, referujeme jednotlivé události názvy aktivit, které reprezentují. V prvé řadě si tedy sestavíme množinu aktivit následovně (pro zjednodušení budeme aktivity označovat zkratkami tvořenými z prvních písmen slov, tedy zběžné prověření bude značeno jako ZP, zatímco znovuotevření požadavku ZnP, atd.): [RP, DP, KÚ, VR, OZ, ZP, VH, ZnP}. Máme-li sestavenu množinu aktivit, sestavíme si jednotlivé stopy dle množiny případů. Dle případu 1 (ID případu) dostaneme ox = (RP,DP,KÚ,VR,OZ), dále dle případu 2 dostaneme o2 = (RP,KÚ,ZP,VR,VH), o3 = (RP, ZP, KÚ, VR, OZ, ZnP, DP, Kli, VR, VH) aa4 = aí = (RP, DP, Kli, VR, OZ). Dle definice tedy zjednodušený záznam vypadá následovně: L = [(RP, DP, Kli, VR, OZ)2 , (RP, Kli, ZP, VR, VH), (RP, ZP, Kli, VR, OZ, ZnP, DP, Kli, VR, VH)] Pozn.: Pro definici zjednodušeného záznamu nemusejí být vždy použity pouze jména aktivit, ale je možné použít také například jména zdrojů, vtom případě by ox = (Petr, Monika, Marcel, Sára, Petr). K datům se ještě znova vrátíme v kapitolách 7 a 8 věnovaným softwarům Disco a ProM, kde se na data zaměříme spíše z praktického hlediska a kde si ukážeme reálné záznamy. Nicméně pro pokračování v našem teoretickém úvodu k process miningu nám výše definované záznamy zcela postačí. 116 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu 6.3 Procesní modely Ať již procesní modely tvoříme anebo objevujeme, je potřeba je nějakým způsobem reprezentovat či zobrazit. V tomto textu jste se již ve 3. kapitole seznámili s BPMN notací. Kromě notace BPMN existují ještě také kauzální sítě, procesní stromy, EPC notaci, přechodové systémy či Petriho sítě. My se blíže seznámíme s pojmy přechodový systém a Petriho sítě. DEFINICE Přechodový systém je trojice TS = (S,A, T), kde 5 je množina stavů, A £ Ji je množina aktivit a T e S X c / Z x S j e množina přechodů. szacatek £ s je množina počátečních stavů a Skonec £ S je množina konečných stavů. Množina stavů S může býti nekonečná, nicméně u praktických aplikací je množina stavů konečná. V takovém případě je přechodový systém označován také jako Finite-State Machine (FSM) nebo finite-state automaton. 6.3.1 PŘECHODOVÝ SYSTÉM Přechodový systém je jednou z nejzákladnějších modelovacích notací. Přechodové systémy sestávají ze stavů a přechodů. Ukázku přechodového systému lze vidět na obrázku níže. Stavy jsou reprezentovány uzly s počátečním stavem sx a koncovým stavem s2 , zatímco přechody jsou reprezentovány hranami. Obrázek 6-3: Přechodový systém Zdroj: upraveno podle Aalsta (2016) 117 PROCESS MINING SAMOSTATNÝ UKOL Sestavte množiny S, A, T, TS, szacatek , skonec pro přechodový systém na obrázku 6-3. Výhodou přechodových systémů j e, že j sou velmi j ednoduché a lze j e velmi j ednoduše transformovat do vyšších jazyků, které mají definovánu spustitelnou sémantiku, jako jsou Petriho sítě či BPMN. Nicméně přechodové systémy mají problémy vyjádřit konkurenční chování a to kvůli pojmu, zvanému state explosion. Proto byly představeny Petriho sítě, které modelování konkurenčního chování značně zjednoduší. Ovšem je potřeba si pamatovat, že ani Petriho sítě nejsou dokonalé. V podstatě každý modelovací jazyk má nějaký svůj ^representational bias" neboli nějaké limitace, avšak toto už je nad rámec tohoto textu. 6.3.2 PETRIHO SÍTĚ Petriho sítě sice patří ke starším nástrojům umožňujícím modelování paralelního chování, nicméně stále patří mezi jedny z nejlepších. Přestože je jejich grafická notace velmi intuitivní a dobře čitelná, mají Petriho sítě také spustitelnou sémantiku, což umožňuje mnoho způsobů jak je analyzovat. Podobně jako tomu bylo u přechodového systému, i zde se jedná jen o úvod do základů Petriho sítí. Jelikož Petriho sítě mají dlouholetou tradici a jedná se o samostatnou vědní disciplínu se stovkami teorémů. Za vznikem Petriho sítí stál Carl Adam Petři, už je asi jasné, proč je nazýváme Petriho sítě. Obrázek 6-4: Značená Petriho síť Zdroj: upraveno podle Aalsta (2016) Petriho síť jak ji můžeme vidět na obrázku 6-4, sestává z míst a přechodů, kde místa by se dala přirovnat ke stavům u přechodového systému a přechody k aktivitám přechodo- 118 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu vého systému. Struktura sítě nebo jinak samotný graf je síce statická, nicméně síť lze přehrát s využitím značek a přechodového pravidla (v anglické literatuře se můžete setkat s pojmy token afiring rule). Stav Petriho seje určen značením Petriho sítě, takové Petriho sítě nazýváme značené Petriho sítě. Na obrázku 6-4 se tedy nachází značená Petriho síť se značkou v místě začátek. DEFINICE Petriho síť je trojice JV = (P, T, F), kde P je konečná množina míst (v angličtině plačeš), T je konečná množina přechodů (v angličtině transitions) takových, že P n T = 0 a F je konečná množina orientovaných hran mezi místy a přechody F = (P X T) U (T X P) popisujících toky v síti. Značená Petriho síť je potom dvojice (JV, M), kde JV = (P, T, F) je Petriho síť a M c M(P) je multimnožina nad množinou P tzv. značení sítě. JV označujeme jako množinu všech značených sítí. S využitím značek a přechodového pravidla jsme tedy do jinak statických sítí schopni vnést jistou úroveň dynamiky. Přechod je umožněn, jestliže se v každém vstupním místě nachází alespoň jedna značka. Na obrázku 6-4 je tedy umožněn přechod a, chtěli-li bychom umožnit přechod e, museli bychom dostat značky do míst m3,m4 (mějme na paměti, že v jednotlivých místech se může vyskytovat i více nezjedná značka). Ve chvíli, kdy je přechod umožněn, může být přechod proveden. V tomto případě, by byla spotřebována značka z místa začátek a vyprodukovány značky v místech m 1 , m 2 , tímto by došlo k umožnění přechodů b, c, d, ale přechod a by již umožněn nebyl. Při provedení přechodu tedy dojde ke spotřebování značek ve všech vstupních místech daného přechodu a vyprodukování značek ve všech výstupních místech daného přechodu. Abychom byly schopni formalizovat přechodové pravidlo, potřebujeme definovat vstupní a výstupní místa, respektive přechody. Mějme tedy síť JV = (P, T, F) a množinu uzlů P U T. Uzel x je vstupním uzlem uzlu y jen a pouze tehdy, je-li mezi těmito uzly orientovaná hrana z x do y. Obdobně platí, že uzel x je výstupním uzlem uzlu y pouze tehdy, je-li mezi těmito uzly orientovaná hrana y do x. Pro uzel x E P U T je množina vstupních a výstupních uzlů následující • x = {y\(y, x) G F} a x •= {y|(x,y) e F}. DEFINICE Nechť (JV, M) je značená Petriho síť, kde JV = (P, T, F) a M c HJ(P). Přechod t E T je umožněn, značíme (JV, M)[t), jen a pouze tehdy platí-li • t < M. Přechodové pravidlo _[_)_ £ JV* x T x JV je nejmenší možná relace uspokojující pro jakoukoliv síť (JV, M) a jakýkoliv přechod t G T, (N,M)[t) => (JV, (M \ - t)[±)t •)• 119 PROCESS MINING Podíváme-li se opět na obrázek 6-4 pak provedení umožněného přechodu a u značené sítě (JV, [začátek]) vyústí ve značenou síť (JV, [začátek])[a)(N, [m1,m2]). Samozřejmě že toto můžeme napsat i pro celou posloupnost postupně prováděných přechodů, např. vrátíme-li se opět k síti na obrázku 6-4 (JV, [začátek])[a,b)(N, [m2,m3]), či (JV, [začátek])[a, b, d, e,g)(N, [konec]). Při modelování podnikových procesů je často využívána podtřída Petriho sítí, zvaná WF-sítě (WorkFlow nets). Pro WF-sítě je typické, že se mají jasně určené vstupní a výstupní místo a všechny uzly v síti jsou na cestě vedoucí těmito dvěma místy. DEFINICE Označená Petriho síť je pětice JV = (P, T, F, A, l), kde JV = (P, T,F) je Petriho síť tak, jak ji máme definovánu výše, A £ j{ j e množina názvů aktivit a l G T -> ^4 je funkce přiřazující přechodu t název dané aktivity. WF-síť poté můžeme definovat následovně. Mějme síť JV = (P,T,F,A,l) a t Ě P U 7\ JV je WF-síť jen a pouze tehdy platí-li": • P obsahuje vstupní místo i takové, že • i = 0 • P obsahuje výstupní místo o takové, že o •= 0 • a síť JV = (P, T U {f}, F U {(o,ř),(M)},^ U {T}, l U {(t,T)}) je silně souvislá, což znamená, že je v síti cesta mezi každými dvěma uzly (a to jak z x do y tak z y do x). Obrázek 6-5: Definice WF-sítě Zdroj: vlastní zpracování 120 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu Petriho síť na obrázku 6-4 je WF-síť, což lze jednoduše vidět z obrázku 6-5. Jelikož po přidání přechodu f mezi místa začátek (vstupní místo) a konec (výstupní místo) dostaneme silně souvislou síť ve smyslu silně souvislého orientovaného grafu. Spolehlivá Petriho sítě a stejně tak i WF-sítě mohou korespondovat velkou spoustou vlastností, s/ť které tu nebudeme rozebírat, ani si je nebudeme uvádět. Nicméně uvedeme si alespoň jednu, kterou využijeme v kapitole 6.4, a sice spolehlivost sítě či spolehlivá síť. Uvažujme tedy opět WF-síť JV = (P,T,F,A,l) se vstupním místem i a výstupním místem o. O síti JV = (P, T, F, A, V) můžeme říci, že je spolehlivá jen v případě, splňuje následující pod­ mínky: • Bezpečnost - (JV, [i]) musí být bezpečná, tzn., že každé místo může v danou chvíli obsahovat nanejvýš jednu značku. • Řádné dokončení - pro jakékoliv značení M G [JV, [i]), o E M implikuje M = H • Možnost dokončit - pro jakékoliv značení M G [JV, [í]), o G [N, M). • Absence mrtvých částí - (JV, [i]) neobsahuje žádné mrtvé přechody, tzn., že pro každý přechod t existuje posloupnost přechodů umožňující přechod t. Množina [JV, M0 ) je množina dosažitelných značení značené sítě (JV, M0 ). Značení M je dosažitelné z původního značení jen a pouze tehdy, existuje-li posloupnost umožněných značení, jejichž provedené vede ze značení M 0 ke značení M. Dále si všimněte, že vlastnost možnost dokončit implikuje vlastnost řádného dokončení. 6.4 Objevování podnikových procesů Objevování podnikových procesů je velmi vyzývajícím úkolem. Cílem objevování podnikových procesuje na základě záznamu zkonstruovat model procesu, který bude zachycovat chování pozorované vdaném záznamu. Objevování podnikových procesů si představíme na jednom z prvních process miningových algoritmů zvaném alfa-algoritmus. Alfa-algoritmus ilustruje obecné myšlenky využívané při objevování procesů. Mimo to je prvním krokem v diskuzi o výzvách, kterým objevování procesů musí čelit. Nicméně je nutné zmínit, že jelikož se jedná o jeden z prvních algoritmů, má alfa-algoritmus relativně hodně nedostatků. Než se pustíme dále, možná bude vhodné připomenout si, co je to vlastně algoritmus. 121 PROCESS MINING Df DEFINICE Neformálně je algoritmus definován jako soubor detailních instrukcí definujících výpočetní proces, který plně determinuje výstup na základě vstupu.15 Pro naše potřeby však Aalst (2016) definuje algoritmus jako funkci y, která zobrazí záznam L G IB(c/Z*) na značenou Petriho síť y(L) = (JV, M). V ideálním případě je síť JV spolehlivá WF-síť a všechny stopy obsažné v záznamu korespondují s posloupnostmi provedených přechodů značené Petriho sítě (JV, M). Obrázek 6-6: WF-síť N i Zdroj: upraveno podle Aalsta (2016) Podíváme-li se na Nx na obrázku 6-3 a vezmeme-li v úvahu záznam Lt = [(a, b, c, d, )3 , (a, c, b, d)2 , (a, e, d)], pak je možné, aby algoritmus y objevil síť Nx na obrázku 3. Není problém ověřit, že každá stopa obsažená v záznamu je možná posloupnost provedených přechodů sítě Nx. 1 5 Definition of algorithm. Encyclopedia of Mathematics [online]. 2017 [cit. 2017-5-11]. Dostupne z: https://www.encyclopediaofmath.org/index.php/Algorithm 122 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu SAMOSTATNÝ ÚKOL Určete z kolika případů a z kolika různých stop sestává záznam Lt = [(a, b, c, d, )3 , (a, c, b, d)2 , (a, e, d)] a ověřte, že je záznam L x vskutku přehratelný na síti Nj_. To samé poté proveďte pro záznam L2 a síť JV2 niže. Nyní uvažujme záznam: (a, b, c, d)3 , (a, c, b, d)4 , (a, b, c, e, f, b, c, d)2 , (a, b, c, e, f, c, b, d), (a,c,b,e,f,b,c,d)2 ,(a,c,b,e,f,b,c,e, f, c, b, d) Na základě záznamu L2 mohl nějaký algoritmus objevit model reprezentovaný WF-sítí JV2 na obrázku níže. Síť JV2 je podobně jako v předchozím případě opět schopna přehrát záznam L2. Nicméně mezi oběma sítěmi je jeden zásadní rozdíl. A sice zatímco u sítě N-^ obsahuje záznam Lt všechny možné posloupnosti provedených přechodů, které síť umožňuje, síť JV2 umožňuje provedení posloupnosti přechodů (a,c,b,e,f,c,b,d), tato stopa ovšem není přítomna v záznamu L2. Ve skutečnosti kvůli existenci smyčky v daném modelu existuje nekonečně mnoho takových stop. Obrázek 6-7: WF-síť N2 Zdroj: upraveno podle Aalsta (2016) 123 PROCESS MINING Modely procesu hodnotíme na základě čtyř kritérií. Obecně vzato žádný reálný model nebude perfektně uspokojovat všechny čtyři kritéria, ale některá kritéria budou uspokojena na úkor jiných. Čtyři kritéria týkající se kvality modelů procesů jsou následující: • Shodnost - j e kritérium hodnotící, do j aké míry obj evený model zachycuj e chování vyskytující se v záznamu, neboli jeli možno na daném modelu přehrát celý záznam. • Přesnost - objevený model by neměl povolit chování radikálně odlišné od toho, které se vyskytuje v záznamu. Přesnost úzce souvisí s pojmem nedoučení modelu (v anglické literatuře underfitting), ve chvíli kdy model vykazuje nízkou přesnost, říkáme, že je nedoučený, jelikož je příliš obecný a umožňuje chování neregistrované v záznamu. • Generalizace - na druhou stranu v rámci kritéria generalizace je vyžadováno jisté zobecnění daného logu, a tedy možnosti přehrát na daném modelu i chování v záznamu se nevyskytující. Generalizace úzce souvisí s pojmem přeučení modelu (v anglické literatuře overfitting), ve chvíli, kdy model vykazuje nízký stupeň generalizace, říkáme, že je přeučený, jelikož je příliš specifický a umožňuje přehrát pouze případy vyskytující se v záznamu. • Jednoduchost - toto kritérium souvisí s principem známé Occamovy břitvy, podstatou tohoto kritéria je fakt, že objevený model by měl být co možná nejjed- nodušší. miPRO ZÁJEMCE Princip Occamovy břitvy krásně shrnuje citát Alberta Einsteina: „Everything should be made as simple as possible, but not simpler'. Volně přeloženo to znamená, že vše by mělo být tak jednoduché, jak jen to jde, ale ani o kousek jednodušší. V anglické literatuře jsou jednotlivá kritéria označována následovně: shodnost -fitness, přesnost - precision, generalizace - generalization a jednoduchost - simplicity. 6.4.1 ALFA-ALGORITMUS Alfa-algoritmus je příkladem výše zmíněné funkce y. Vstupem alfa-algoritmu je zjednodušený záznam a jeho výstupem je Petriho síť umožňující přehrání záznamu. Alfa-algoritmus byl jedním z prvních, který si dokázal jistým způsobem poradit s konkurenčním chováním. Konkurenční chování můžeme vidět například u sítě JV2 výše, konkrétně se jedná 124 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu o přechody bac. Přestože je alfa-algoritmus pro objasnění základních principů objevování procesů, v praxi je dnes již zastíněn daleko sofistikovanějšími přístupy. Toje dáno zejména problémy, se kterými si alfa-algoritmus nedokáže poradit jako hluk, neúplnost či komplexní chování (všem těmto problematickým částem se budeme věnovat později). ÚKOL K ZAMYŠLENÍ Uvažujte síť Nľ a zdůvodněte, proč nejsou přechody (b, e) ani (c, e) vzájemně konkurenčními přechody, zatímco (b, c) konkurenční chování vykazují, i když by se při prvním pohledu na daný model mohlo zdát, že ano. Mějme tedy zjednodušený záznam L E M(Jl*) a jednotlivé elementy množiny Ji označujme jako aktivity. Tyto aktivity korespondují s přechody v objevené Petriho síti. Dále označujme množiny aktivit velkými písmeny, A, B £ Ji, a jednotlivé aktivity malými písmeny, a, b E Ji. Výstupem alfa-algoritmu je značená WF-síť, a(L) = (JV,M). Principem alfa-algoritmu je hledání jistých vzorců chování v záznamu (například je-li aktivity a vždy následována aktivitou b, ale nikdy ne opačně, pak se dá předpokládat kauzální závislost mezi oběma aktivitami. Rozlišujeme čtyři vztahy, které vyjadřují relevantní vzorce nacházející se v záznamu. DEFINICE Nechť L je záznam nad množinou aktivit JI, tedy L E M(Jl*) a mějme dvě aktivity a, b E Ji, potom definujeme následující čtyři vztahy mezi aktivitami v daném záznamu (Aalst, 2011): • a >L b jen a pouze existuje-li stopa a = (tv t2, —,tn) a i E {1, ...,n — 1} takové, že a E L a tt = a a ti+1 = b (tzv. přímá následnost), • a ->L b jen a pouze tehdy, platí-li a >L b a b >L a, • a #L b jen a pouze tehdy, platí-li a >L b a b >L a, • a \\L b jen a pouze tehdy, platí-li a >L b a b >L a. Vezmeme-li v úvahu znovu záznam L x = [(a, b, c, d)3 , (a, c, b, d)2 , (a, e, d)], pak se dopátráme toho, že obsahuje následující vztahy: • > L x = {(a, b), (a, č), (a, é), {Jo, č), (c, b), (Jo, d), (c, d), (e, ď)} 125 PROCESS MINING • ->L i = {(a, b), (a, c), (a, e), (b, d), (c, d), (e, d)} {(a, a), (a, d), (Ď, Ď), (Ď, e), (c, c), (c, e), (d, a), (d, d), (e, b), (e, c), (e, e)} • \\L = {(b, c), (c, b)} Vztah >L i je tedy množina obsahující všechny páry aktivit, které jsou ve vztahu přímé následnosti. Vezmeme-li v úvahu stopu (a, b, c, d), pak vidíme, že aktivita b přímo následuje aktivitu a. Navíc, jelikož aktivita a není v žádné ze tří různých stop záznamu Lt ve vztahu přímé následnosti s aktivitou b, je mezi aktivitami (a, b) také vztah ->L i . Tabulka 6-2: Vztahová matice záznamu L i a b c d " X 0 c d e Zdroj: upraveno podle Aalsta (2016) Budeme-li nyní uvažovat stopu (a,c,b,d) a v ní vyskytující se aktivity (c, b), vidíme, že je mezi nimi vztah >L i , avšak jelikož ve stopě (a,b,c,d) aktivita c přímo následuje aktivitu b, a proto mezi nimi není vztah ->L Nicméně jelikož mezi aktivitami bac platí vztahy b >Li c a c >Li b, pak mezi nimi platí vztah ||L i . #L i vztah je množina obsahující všechny páry aktivit pro které platí a >L b a b >L a. Vztahy mezi jednotlivými aktivitami lze také zobrazit pomocí tzv. matice vztahů, viz obrázek výše. SAMOSTATNÝ ÚKOL Sestrojte vztahovou matici pro záznam L2 = [(a, b, c, d)3 , (a, c, b, d)4 , (a, b, c, e, f, b, c, d)2 , (a, b, c, e, f, c, b, d), (a, c, b, e, f, b, c, d)2 , (a, c, b, e, f, b, c, e, f, c, b,d)]. Nyní si tedy konečně představíme samotný alfa-algoritmus. Nejste-li si jisti některými definicemi uvedenými v kapitole 6.3, doporučujeme, ještě než se vrhnete na studování následující definice věnující se alfa-algoritmu, abyste si dřívější definice znova prošli. Zejména je potřeba vědět co je to záznam, výše uvedené čtyři vztahy mezi událostmi, co je to WF-síť a čím je charakteristická, mít jasno mezi místy a přechody. Dále je potřeba jistý 126 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu matematický aparát z teorie množin a výrokové logiky, které v tomto textu neprocházíme, musíme vědět co je to množina, co je to podmnožina, ale to již necháme na Vás, jelikož jste jistě poctivě navštěvovali všechny povinné kurzy matematiky, které naše fakulta na­ bízí. DEFINICE Nechť L je záznam nad množinou T ^ JI, poté je kde A označuj e množinu vstupních přechodů (• P(A,B) = A) a množina B je množina výstupních přechodů (P(A,B) , = místa P(A,B)V rámci čtvrtého kroku jsou identifikována jednotlivá potenciální místa objevované WF-sítě. Myšlenku stojící za objevením jednotlivých míst u alfa-algoritmu je vidět na obrázku výše. To znamená, že všechny prvky množiny A by měly mít kauzální závislost na všech prvcích množiny B, neboli má platit pro všechny (a,b) G A X B: a ->L b. Mimo to 127 PROCESS MINING je požadováno, aby prvky v rámci množiny A nebyly vzájemně ve vztahu přímé následnosti, tedy pro všechny a1,a2 E A: ax #L a2. Podobně pro množinu je požadováno, aby pro všechny prvky množiny B platilo blt b2 £ B: bx #L b2.Y pátém kroku dojde k vyloučení menších než maximální párů, jelikož v opačném případě by bylo v objevené síti příliš mnoho míst, a dojde tak ke vzniku množiny YL. V šestém kroku jsou určeny jednotlivá místa korespondující prvkům (A, B) G YL, a také vstupní a výstupní místo typické pro WFsítě. V sedmém kroku jsou vygenerovány hrany WF-sítě mezi všemi místy P(A,B) a vstupními přechody množiny A a výstupními přechody množiny B, a mezi vstupním a výstupním místem a příslušnými přechody příslušných množin Tj aT0. Obrázek 6-8: Základní myšlenka stojící za místy u čtvrtého kroku alfa-algoritmu Zdroj: upraveno podle Aalsta (2016) ŘEŠENÁ ÚLOHA Nyní aplikujeme alfa-algoritmus v praxi, uvažujme záznam L3 = [(a, b, e, f)3 , (a, b, e, c, d, b, f)s , {a, b, c, e, d, b, f)2 , {a, b, c, d, e, b, f)2 , {a, e, b, c, d, b, f)3 ] Potom jednotlivé kroky alfa algoritmu j sou následující: 1. TÍ 3 = {a,b,c,d,e,f} V prvním kroku byly nejprve identifikovány všechny aktivity vyskytující v záznamu L3 reprezentující události s podobnými vlastnostmi, což dalo vznik množině TLz. 2. ľ; = {a} 128 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu Ve druhém kroku jsou identifikovány všechny aktivity, které se vyskytují na první pozici napříč všemi stopami v záznamu, což není v našem případě problém, jelikož v případě záznamu L3 se jedná pouze o aktivitu a. 3. T0={f} Ve třetím kroku byly identifikovány všechny aktivity, které se vyskytují na poslední pozici napříč všemi stopami záznamu L 3 , což opět není problém, jelikož se jedná pouze o aktivitu / . 4 X = í ( { a } ' ™ ' ( { a } ' { e } ) ' m ' { C } ) ' m ' ™ ' ( { C } ' 4 ' Al * { ({d},{b}),({el{ni({a,dl{b}),({b},{c,f}) i Ve čtvrtém kroku dojde k identifikaci potencionálních míst WF-sítě prostřednictvím vztahů ->L a #L. V praxi, kde budeme pracovat s desetitisíci řádky v záznamu, to za nás udělá technika, ale u takto jednoduchých záznamů lze využít matici vztahů k odhalení množ i n y ^ . Tabulka 6-3: Matice vztahů L3 a b c d e 0 c d f K K K K K H,a H,a K Zdroj: upraveno podle Aalsta (2016) 5. YĹ3 = {({a}, {e}), ({c}, {d}), ({e}, {f}), ({a, d}, {b}), ({b}, {c, f})} V pátém kroku odebereme v z množiny XL3 všechny nemaximální prvky a dáme vzniknout množině YL. Jak lze vidět, budeme-li uvažovat prvky ({a}, {b}), ({d}, {b}) a ({a, d}, {b}) vzniklo by v síti zbytečně mnoho míst, zatímco, ponecháme-li jen maximálni prvek ({a, d}, {b}) dostaneme stejné chovaní s využitím pouze jednoho místa. Podobně je tomu s prvky ({b}, {c}), ({*>},{/}) a ({b}, {c, f}). 6- PL3 = {P({a},{e}> P({c},{d}> P({e},{/})> P({a,d},W> P({6},{c,/}>L L 3 , 0LS} V šestém kroku tedy dojde k formální definici míst a tedy vzniku množiny míst P Ĺ 3 . 129 PROCESS MINING Í (ÍL, a), (a, P({a},{e}))» («» P({a,d},{b}))> (P({a},{e}> e), (p({a,d},{b})>b )> (e > ?({«},{/]))' (b > Vm.{c,m)> (P«bUcf}> c )> (c > Pttclíd})), (P({c},{d}>d )> (d, P({a,d},íb}))> (P(íe},íf}> / ) ' (PQLbUcfí)' f)> (f> °L) V sedmém kroku doplníme množinu hran WF-sítě. V tomto bodě jsme připraveni na osmý krok, ve kterém již jsme schopni definovat objevenou WF-síť. 8- 191 o2 177 0 3 144 o 4 133 PROCESS MINING 111 o5 82 o6 56 o7 47 o8 38 Og 33 010 14 On 11 Ol2 9 Ol3 8 014 5 Oi5 3 Oi6 2 Oi7 2 018 1 019 1 O20 1 021 Zdroj: upraveno podle Aalsta (2016) K problému kvantitativní charakterizace kritéria shodnosti v rámci zjišťování shodnosti, lze poměrně naivně přistupovat například způsobem, že kritérium shodnosti vyjádříme jako podíl přehratelných stop v rámci celého záznamu. Uvažovali-li bychom záznam L4 a sítě N41 a JV42 , pak bychom mohli určit shodnost sítě N41 následovně S = 1391/1391 = 1 a shodnost sítě JV4 2 by byla S = 948/1391 = 0,6815. Sami si vyzkoušejte, že síť JV4 1 je vskutku schopna přehrát celý záznam, zatímco N42 není schopna přehrát celý záznam (pozn. již na první pohled je vidět, že jelikož v síti JV4 2 chybějí přechody b.f.g, nebude možno přehrát stopy, v nichž se vyskytují aktivity {b,f,g} c TLA). Nicméně tato naivní metrika není zdaleka vhodná pro více realistické procesy. Například došlo-li by ke spojení míst m 1 a m 2 v síti N41 v jedno, nebylo by možno přehrát žádnou ze stop v záznamu L4 a tedy ani jeden případ z 1391 případů a kritérium shodnosti by bylo S = 0/1391 = 0, což se ale zdá býti příliš svazující vzhledem k tomu, že zbylé chování by taková síť vystihovala vcelku dobře. 134 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu m 2 n i 4 Obrázek 6-10: Sítě N4.1 (horní) a N4.2 (dolní) Zdroj: upraveno podle Aalsta (2016) Z tohoto důvodu je kritérium shodnosti spíše řešeno na úrovni událostí a schopnosti přehrát jednotlivé události, než na úrovni stop. Budeme-li se držet úrovně událostí, stačí jen trochu modifikovat předchozí případ, a sice v případě, že nějaká událost nebude přehratelná, neskončíme a neklasifikuje stopu jako nepřehratelnou, ale budeme pokračovat a tyto nejasnosti zaznamenávat. V takovém případě nás budou zajímat následující charakteristiky: vyprodukované značky (p), spotřebované značky (c), chybějící značky (m) a přebývající značky (r). Uvažujme síť N41 a stopu ox = (a, c, d, e, h) záznamu L4. Na počátku je p = c = 0 a žádné místo neobsahuje značku. Následně prostředí vyprodukuje značku v místě Začátek a v důsledku toho p = 1, viz obrázek níže. 135 PROCESS MINING Obrázek 6-11: Síť N4.1 - značka v začátku Zdroj: upraveno podle Aalsta (2016) V následujícím krokuje proveden přechod a a tím dojde ke spotřebování jedné značky a vyprodukování dvou nových značek, dostaneme tedy značenou síť na obrázku níže. Obrázek 6-12: Síť N4.1 - značka v mi a im Zdroj: upraveno podle Aalsta (2016) Dle stopy ox = (a,c,d,e,h) následuje po provedení přechodu a přechod c. Obrázek níže zobrazuje provedení zbylých aktivit c až h dle stopy ox s příslušnými charakteristikami p, c, m, r. 136 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu 137 PROCESS MINING Obrázek 6-13: Síť N4.1 - značky im, ni3 až niKonec Zdroj: upraveno podle Aalsta (2016) V tomto případě můžeme definovat shodnost následovně: 1 / m\ 1 / r\ shodnost(a,N) = - ( 1 ) + (1) 2 v c / 2 \ p/ Jelikož j sme byli schopni přehrát v síti JV4 x bez problémů celou stopu ox a neměli j sme chybějící ani přebývající značky, je shodnost^, N41) = 1, což je stejný výsledek j ako u naší naivní definice shodnosti. ŘEŠENÁ ÚLOHA Uvažujme nyní síť JV4 2 a stopu a2 = (a,b,d,e, g) a vypočítejme kritérium shodnosti shodnost(a3, N4 2). Celý postup shrnuje obrázek níže. Opět začínáme s neznačenou sítí a tedy p = c = 0. 138 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu PROCESS MINING m = 2 r = 2 Obrázek 6-14: Síť N4.2 - značky mzačátek až mKonec Zdroj: upraveno podle Aalsta (2016) Zde nám nastává problém, jelikož nám se neshodují aktivity v síti a stopě. V tomto případě abstrahujeme od chybějících událostí a přehrajeme o2 = (a, d, e). Při přehrání aktivity a dojde ke spotřebě značky v místě Začátek a vyprodukování značek v místech m x a m2 . Poté je dle stopy o'2 = (a, d, e) provedena aktivita d spotřebou značky v místě m2 a vyprodukováním značky v místě m4 . Problém nastane, ve chvíli, kdy se snažíme provést aktivitu e, jelikož nám v místě m 3 chybí značka a provedení aktivity e tak není umožněno. Místo m 3 tedy označíme značkou m, a přehrajeme aktivitu e. Po přehrání o2 = (a, d, e) je značení [pi, Ps], jenomže prostředí potřebuje spotřebovat značku z místa Konec, a tedy i místo Konec je označeno značkou m. Jelikož nám po spotřebování značky v místě Konec stále přebývají značky v místech [pi,p5 ], označíme je jako r. A po dosazení je tedy shodnost^, Ní2) = i ( l - =) + i ( l - 0 = f ( l - f) + i ( l - fj = 0.6 Shodnost dle vzorce (1) výše ovšem řeší pouze jeden případ respektive stopu, abychom zjistili shodnost pro celý záznam je potřeba vzorec (1) následovně modifikovat: shodnost(a, N) ~2\ I XES s t a n d a r d v e r s i o n : 1 DpenXES l i b r a r y v e r s i o n • OpenXEE i s a v a i l a b l e f r I xes . v e r s i o r . = " l . 0 " x e s . f odLr.g="DTF-8r ?> w i c h che OpenXEE l i b r a r y the XES s t a n d a r d f o r l o g : I t conforms — : ;orage and —> :rsj-cir="l.DRC7" jgiilr.s="ht-tp: //www.: '. Kes-stana*?.?;1 iľiľ:i-1 i f e^v^le , xesext"/> j c e s - s t a n d a r d . ijrij/crij , xesext1 1 /> o r g / t i m e .jcesext" /> ľi ľŤ'ľ: r XfrgfrX r '' / • l="JittiJ : / /www. xi?ŕ-ŕ~ :\;-.: :1 n •' ŕ^r.-f-.: i : : : x ^ ŕ ^ x ~ " .-" 1 . 0 R C 7 — > r.~ ~ : . : --rr.y.-ri. : r:' — t t r e s = " n e s t e d - a t t r i b u t e s " oper.xes extension. r.ame=" L i f e a y a l e " p~ef Lx=" l i f e c y c l e " c ~ i = " h t t p : / / ' extension. r.ame="Organizational" prefi.x="org" u.ri="http: / / w e x t e n s i o n r_ame="T ime" pi-=-fix="t ime" '.LI I = .-" .-ww xes -s la y .1 e x t e n s i o n r_ame=" Concept" p r e f Lx=" concept" c ~ i = " n " r : /www xes^st a:'i;:lard • org/1 extension. r.ame="£eiE.anti c" prefLx=" semanti g l o b a l 3cope="trace"> < s t r i : i g Jfey="concept: name" v a l t e = " INVALID "/> / g l o b a l ? g l o b a l s c o p e s event" > < s t r i : i g Jfey=" con cep t: name" v a l t e = " INVALID "/> < s t r i n g key="l i f e a y a l e : t r a n s i t i on" valce="complete"/> / g l o b a l ; * ="MXML Legacy C l a s s i f i er" }rev-s=" con cept: name l i f e a y a l e : t r a n s i t ="Event Name" keys="concept:name"/> ="Resonrce" keys="org:resource"/> ="Event THame AND Resource" keys="concept:name o r g : resource"/::• roe" value="CPN T o o l s s i n m l a t i o n " / > s t a n d a r d . o r g / " > •;lsss^f^er ~. c l a s s i f i e r n. s t r i n g k"ey=": s t r i n g key="concept: name" v a l t e = " r e p a i rExample . mxml"/> s t r i n g Jiey="l i f e c y c l e : model" v a l t e = " standard"/> s t r i n g J r e y ^ ' d e s c r i p t i o n " valt.e="Simnlated p r o c e s s " / ? < s t r i n g Jiey="concept: name" v a l t e = " l"/> < s t r i n g key=" o r g : r e s o u r c e " value="System"/> < s t r i n g key=" l i f e c y c l e : t r a n s i t i on" valce="complete "/> < s t r i n g Jiey="org: r e s o u r c e " valt.e="Tester3"/> < s t r i n g key=" con cep t: name" v a l u e ™ " A n a l y z e Def ect"/> < s t r i n g Jiey=" l i f e c y c l e : t r a n s i t i on" v a l u e = " s t a r t " / > extensible Markup Languagefile Ln:1 Col:1 Sel: 0 | 0 Obrázek 7-2: Záznam v XES Zdroj: Vlastní zpracování Kromě XES a M X M L souborů si Disco poradí také s CSV (Comma Separated Values), TXT (Textfiles), XLS/XLSX (Microsoft Excel) či FBT sobory. 7.2 Instalace softwarového produktu Disco Disco1 8 je produktem Nizozemské společnosti Fluxicon. Tuto společnost založili bývalí studenti ve skupině profesora Aalsta na Technické univerzitě v Eindhovenu, Anne Rozinat a Christian W. Günther. Oba mají zázemí v oblasti softwarového inženýrství a process miningu. Ještě než se popíšeme prostředí produktu Disco, rychle si projdeme proces instalace. Disco je k dispozici ke stažení online (viz poznámka pod čarou číslo 16). Disco je k dispozici jak pro uživatele systému Windows tak Mac OS. Stáhněte si příslušnou verzi .exe souboru a dvojklikem na soubor Disco-Setup.exe spusťte instalaci. Poté klikněte na tlačítko „Nexť (obrázek 7-3 vlevo) a následně „Instair (obrázek 7-3 vpravo). 1 8 Disco. Fluxicon: process mining for professionals [online]. 2017 [cit. 2017-11-10]. Dostupne z: https://fluxicon.com/disco/ 146 Roman Sperka, Michal Halaška, Dalibor Simek -Techniky a nástroje v oblasti řízení podnikových procesů Welcome to Disco Setup Setup will guide you through the installation of Disco. It is recommended that you dose all other applications before starting Setup. This will make it possible to update relevant system files without having to reboot your computer. Click Next to continue, 0 Disco Setup • n o o s e Install Location Choose the folder in which to install Disco. 0 Setup will install Disco in the following folder. To install in a different folder, dick Browse and select another folder, Click Install to start the installation. Destination Folder Space required: 34.0 MB Space available: 381.4GB Nullsoft Install System v3.02 Obrázek 7-3: Instalace Disco Zdroj: Vlastní zpracování Ve chvíli, kdy Disco spustíte poprvé, budete dotázáni pro souhlas s licenčními podmínkami, zakřížkujte pole ..I have read and understood this license" a potvrďte stisknutím „/ accept these terms". Register Disco. Before you can use this software, you have to register with Fluxicon. Enteryour email address and you will be registered in just a minute (internet connection required). Thanks for entering your registration information. You can now proceed to finish the registration. Activate Disco. We have sent you an email with* your registration hey Enter this regi strabort key below to activate your in stallatio n ol Disco. If you cannot find the email we sent you. please also check your spam and |unh mail roiaers. Enler you r registration key here. Registration key: SBGlCF Your E m a i l : x x x x x x x @ o p f . s l u . c z A Communication with c • Is SECU rEd by Ind usüy-sta n dard S3L. Login (7) Subscribe (o our newsletter (no spam, promisel, A ConvruniearnA wan awr ttrvtrt« SMUIW ty nau stry-swnaa« M L . Baflt j [ Complete registration | Obrázek 7-4: Registrace Disco Zdroj: vlastní zpracování Po vyjádření souhlasu s licenčními podmínkami je potřeba kopii Disco registrovat. Na OPF je pořízena licence pro software Disco, a registrace probíhá prostřednictvím školního emailu ve formátu xxxxxxx@opf.slu.cz, namísto xxxxxxx použijte své uživatelské jméno pro přihlášení (viz obrázek 7-4 vlevo). Na email Vám poté bude zaslán email s registračním klíčem, který vyplníte do pole ..Registration key" a kliknete na políčko ..Complete registration" (viz obrázek 7-4 vpravo). V případě problémů odkazujeme studenty na vyučující ať již osobně či prostřednictvím emailu, případně na uživatelskou příručku1 9 . 1 9 Disco. Disco User's Guide [online]. 2017 [cit. 2017-11-10]. Dostupné z: https://fluxicon.com/disco/fi- les/Disco-User-Guide.pdf 147 PŘÍPADOVÁ STUDIE DISCO 7.3 Analýza procesů v Disco Vše máme připraveno a můžeme analyzovat. V rámci této kapitoly budeme analyzovat vybraný proces a zároveň si i představíme prostředí Disco. Po provedení registrace se nám objeví úvodní obrazovka, kterou můžete vidět na obrázku 7-5 níže. O Disco - New pr 2 JQ p SŠÚ. Disco Project: New projed 3 a * 3 Time to get started! Your project Is currently empty, so there Is nothing to see here yet. If you want to get to know Disco first, you can play around with our sandbox project. You can also get started right sway by loading your own event log. Play in the sandbox Losfl your own data Obrázek 7-5: Disco úvodní obrazovka Zdroj: vlastní zpracování 1. Při kliknutí na políčko „Sandbox" se vytvoří úvodní proj ekt pro nové uživatele s předem nahranými daty a nápovědou pro vyzkoušení si softwaru Disco. 2. V případě, že máme svá vlastní data, můžeme je importovat buď stisknutím tlačítka „OpenfUe" anebo kliknutím na ikonu v levém horním rohu na obrázku 7-5. 3. Kliknutím na ikonu číslo 3 na obrázku 7-5 si můžeme zobrazit nápovědu. 4. Kliknutím na ikonu číslo 4 na obrázku 7-5 lze nahlásit problém se softwarem. 5. Kliknutím na ikonu číslo 5 na obrázku 7-5 lze změnit uživatele. 6. Kliknutím na ikonu číslo 6 na obrázku 7-5 lze vytvořit nový projekt. 7. Kliknutím na ikonu číslo 7 na obrázku 7-5 lze uložit stávající projekt. 148 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu (Sŕ DÍSÍO - New proj SIX 4 5 6 - O X jrSí \ ťBBHíffS ~\'. ^ j-, j-. %0 V halaska@opt.slu.cz L / l o C U Case ID Q column is u ^_2_ •}_ # Case ID 339 3 3 9 Q Activity Create Purchase Req ^nal/ie Furchase Re: Amend Purchase Req KIT a I.'i c Purchase Re: JO StartTime Q EndTime sifion 5011/02/16 14:31:00.000 2011/02/16 15:23:00.000 Jisition 2011/02/1709:34:00.000 2011/02/17 09:40:00.000 isltlon 2011/02/1721:29:00.000 2011/02/1721:5200.000 Jisition 2011/02/18 17:24:00.000 2011/02/18 17:30:00.000 Dtation Requester Manager 2011'_| 2 18 17 ' S^nn noo 2011/02/18 1738 00 000 |t Resource •Jico Ojenbeer Vlaris Freeman Elvira Lores Heine 'Jutschmidt 0 Role Requester Requester Manager Requester Requester Manager r S 9 •10 12 339 339 3 3 9 940 940 940 940 -.nal/ie RequestforQ inend Requestfor Qi_ ^nal.ze Request forQ Create Purchase Req Create Request for Qu ^.nal/ie Request forQ 3e-iiv Re;uestfcT Cue Otation 2011/02/22 09:34:00.000 2011/02/22 09:58:00.000 otation Requester 2011/02/22 10:50:00.000 2011/02/2211:03:00.000 otation 2011/02/28 08:10:00.000 2011/02/28 08:34:00.000 sition 2011/05/17 06:31:00.000 2011/05/17 07:08:00.000 Dtation Requester 2011/05/1709:58:00.000 2011/05/1710:06:00.000 Otation 2011/95/1819:30:00.000 2011/05/1819:56:00.000 ation to Supplier 2011/05/18 23:46:00.000 2011/05/18 23:59:00.000 Magdalena Predutta ^enn Osterwalder ; rancois de Perrier mmanuel Karagianni Es "nana Liubiata Francois de Perrier Vlagdalena Predutta Furchaslng Agent Requester Manager Purchasing Agent Requester Requester Purchasing Agent Purchasing Agent 13 15 16 19 23 940 940 940 940 940 940 940 940 Create Quotation com -.nal/ie Quotation cc' Choose Gest option Settle conditions with Create Purchase Crce Confirm Purchase Deliver Goods Sei.ice Release Furchase Cr arisonMap 2011/05/19 03:44:00.000 2011/05/1908:31:00.000 parlscn Map 2011/05/19 15:38:00.000 2011/05/19 15:5200.000 2011/05/19 15:52:00.000 2011/05/19 15:52:00.000 upplier 2011/05/20 23:31:00.000 2011/05/21 09:22:00.000 2011/05/21 18:48:00.000 2011/05/21 18:59:00.000 sr 2011/05/2211:33:00.000 2011/05/2211:44:00.000 2011/05/23 05:32:00.000 2011/05/2413:46:00.000 er 2011/05/2420:59:00.000 2011/05/2421:00:00.000 r rancois de Perrier kl 'l Fassa Anna Kaufman n 'vlagdalena Predutta Francois de Perrier Esmeralda Clay Esmeralda Clay Kim Pass a Purchasing Agent Requester Requesler Purchasing Agent Purchasing Agent Requester I J22 23 24 25 26 27 _ 23 2? 30 940 940 940 940 1417 1417 1417 1417 1417 159 approve Purchase 2.p: Authorize Suppliers In Pay invoice Create Purchase Re:: Create RecmestfofCiL inal.ce Request forQ : ."ieiio Requestfor Qi_ -.nal/ie Request toi0 Create Purchase Req srforpayment 2011/05/26 07:41:00.000 2011/05/26 07:42:00.000 2011/05/28 01:11:00.000 2011/05/28 01:11:00.000 olee payment 2011/05/28 15:28:00.000 2011/05/28 15:28:00.000 2011/05/28 16:11:00.000 2011/05/28 16:19:00.000 sition 2011/07/2312:53:00.000 2011/07/2313:31:00.000 Dtation Requester 2011/07/2317:51:00.000 2011/07/2317:59:00.000 otation 2011/08/02 07:02:00.000 2011/08/02 07:24:00.000 otation Requester 2011/08/02 08:17:00.000 2011/08/02 08:27:00.000 otation 2011/08/08 04:03:00.000 2011/08/08 04:23:00.000 sition 2011/01/21 15:02:00.000 2011/01/21 15:42:00.000 Karel de Groot Kiu Kan Pedro Alvares -varalca IJimwada Christian Francois mmanuel Karagianni Systém a zabezpečení -> Systém kolonka „typ systému". My tedy zvolíme verzi ProM 6.7 with 64-bit JRE7 a stáhneme instalační .exe soubor, který dvojklikem otevřeme. 2 1 ProM. ProM documentation [online]. 2017 [cit. 2017-11-22]. Dostupné z: http://www.promto- ols.org/doku.php 163 PŘÍPADOVÁ STUDIE PROM Setup - ProM 6.7 Welcome to the ProM 6.7 Setup Wizard. Created with an evaluation version of BitRodc InstallBuilder Cancel Obrázek 8-2: Instalace ProM 6.7 Zdroj: vlastní zpracování Objeví se klasické instalační okno, u kterého kliknete na políčko „Nexŕ, poté znova „Nexŕ - případně můžete změnit adresář, kde má být ProM nainstalován, a poté ještě jednou „Nexŕ. V tuto chvíli započne instalace ProM. Ve chvíli, kdy instalace skončí, objeví se okno podobné tomu na obrázku 8-2 a však místo „Nexŕ klikneme na „Finish". £j£ ProM UITopia Package Manager External Packages Required Authorls); Maintained by: License: Dependencies F. Mannhardt F. Mannhardt L-GPL GraphViz DataAwareReplayer DataPetnNets XESLrte Widgets Murata Succesfully installed Murata-6 7 70 Downloading Widgets-6.7.224 Installing; Widgets-6.7.224 Succesfully installed Widgets-6 7 224 Downloading LogEnhancement-6 7 354 Obrázek 8-3: Prvotní instalace pluginů Zdroj: vlastní zpracování 164 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu Ve chvíli, kdy ProM poprvé otevřeme, objeví se nám obrazovka jako na obrázku 8-3. To se do ProM začaly automaticky stahovat různé pluginy jako alfa-algoritmus, inductive miner, fuzzy miner a další, jistě si na ně z 6. kapitoly vzpomínáte. Vyčkejme tedy až se tento proces ukončí, v závislosti na výkonu Vašeho počítače a rychlosti internetu to může trvat i několik minut. 8.2 Analýza procesů v ProM ProM máme naistalován, poj ďme se tedy podívat, j ak s j eho pomocí můžeme analyzovat procesy. Úvodní pracovní plochu v ProM můžeme vidět na obrázku 8-4 niže. Obrázek 8-4: Pracovní plocha ProM Zdroj: vlastní zpracování Na obrázku 8-4 popisek 1 je označena pracovní plocha. Pracovní plocha zobrazuje všechny zdroje, které: • byly do ProM importovány, popisek 4, • nebo jsou výsledky prováděných akcí na jiných zdrojích. Dále můžeme na obrazovce vidět čtyři různá zobrazení zdrojů označená „A//", „Favourites", ^Imported" a ^Selection". V našem případě máme zvoleno zobrazení ^Favourites", nicméně jelikož jsme ještě žádná data neimportovali ani neprováděli žádné akce, je naše zobrazení zdrojů prázdné (obrázek 8-4 popisek 5). Zobrazení „A//" zobrazí všechny zdroje, zobrazení ^Favourites" zobrazí nej používanější, zobrazení ^Imported" zobrazí importované zdroje. Zobrazení ^Selection" umožňuje zobrazit vybrané zdroje. Dále lze zdroje v da- 165 PŘÍPADOVÁ STUDIE PROM ném zobrazení členit s pomocí tří tlačítek, viz popisek 6. Tlačítko vlevo člení zdroje v závislosti na době vzniku, prostřední tlačítko dle toho, kdy byly naposledy užity a pravé tlačítko seřadí zdroje dle abecedy. | £ ProM UITopii Obrázek 8-5: Akční plocha ProM Zdroj: vlastní zpracování Klikneme-li na tlačítko na obrázku 8-4 popisek 2, zobrazí se nám akční plocha, viz obrázek 8-5. Akční plocha zobrazí všechny akce („Actions"), které mohou být provedeny na zvolených vstupech („Inpuŕ), a které vyústí v jisté výstupy („Output") v závislosti na zvolených kritériích. Klikneme-li na tlačítko na obrázku 8-4 popisek 3, zobrazí se nám plocha zobrazení, viz obrázek 8-6. Na ploše zobrazení se zobrazí zdroje, či zdroje po provedení vybraných akcí atp. Jestli je Vám ProM stále cizí, nevadí, všechno si ukážeme na skutečných datech. Proces, kterému se budeme věnovat, je proces opravy telefonů ve firmě, která se zabývá jejich prodejem a servisem. Firma opravuje tři typy telefonů (TI, T2 a T3). Proces začíná registrací opravovaného zařízení zaslaného firmě zákazníkem. Po registraci je telefon k opravě zařazen do jedné z 10 kategorií dle závady na oddělení detekce problémů (DP). Poté je odeslán na oddělení oprav (R) a zákazníkovi je poslán email s informacemi o závadě. Oddělení oprav má dva týmy. První tým se stará o opravu jednodušších vad a druhý tým se stará o opravu komplexních vad. Nicméně některé kategorie mohou být opraveny oběma týmy. Jakmile jsou na oddělení oprav hotovi, je telefon odeslán na oddělení kvality (QA), kde je telefon analyzován, zdali byl telefon opravdu opraven. V případě, že zaměstnanec zjistí, že telefon nebyl řádně opraven, je opět zaslán na oddělení oprav (R). V případě, že je telefon opraven, záznam je archivován a opravený přístroj je zaslán zákazníkovi. Firma má zásadu, že v důsledku časové úspory, je každý telefon opravován jen do určitého 166 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu počtu pokusu. V případě, že se telefon opravit nepovede, je zákazníkovi zaslán zcela nový telefon. * 0 • 1 <•> ^T'fluxicon Views Obrázek 8-6: Plocha zobrazení ProM Zdroj: vlastní zpracování Workspace ^ import... K-I Favorites nana ig Select an import plugin. Available Import Pluglns lor file repairExample.xi ProM log tiles (XESLite - MapDB (slow random a ProM log files (XESLite - MapDB (slow random access)) Import Conforming Log from IEEE XES Log File ProM log files (XESLite - MapDB (no cache)) ProM log files (XESLite - Sequential XIDs) ProM log files (XESLite - In-Memory (slow random access ProM log files (XESLite - MapDB) Import Lenient Log from IEEE XES Log File Import Stnciiy Conforming Log from IEEE Xt S Log I ile Obrázek 8-7: Import dat Zdroj: vlastní zpracování 167 PŘÍPADOVÁ STUDIE PROM Klikneme tedy na políčko „Import" na pracovní ploše (obrázek 8-4 popisek 4) a najdeme zdroj našich dat, v našem případě se jedná o soubor typu .xes a zmáčkneme políčko „Open". V seznamu (viz obrázek 8-7) vybereme hned první možnost pro volbu příslušného pluginu a volbu potvrdíme stisknutím políčka „Ok". Workspace f=2i repairExampleSainple2.mxml repairExaiiiple.mxinl GHEX repairExample.mxml XLog rj 29 minuies ago imported i Obrázek 8-8: Pracovní plocha s importovanými daty Zdroj: vlastní zpracování Do ProM jsme importovali soubory s názvy „repairExample" a „repairExampleSample2". Stisknutím políčka s popiskem 1 na obrázku 8-8 přidáme zdroj mezi oblíbené. Stisknutím políčka s popiskem 2 se dostaneme na akční plochu podobně jako na obrázku 8-4. Stisknutím políčka s popiskem 3 na obrázku 8-8 se dostaneme na plochu zobrazení opět podobně jako na obrázku 8-4. Stisknutím políčka s popiskem 4 lze daný datovou soubor odstranit. Kliknutím na „Rename resource" lze změnit název souboru a kliknutím na „Export to disk" je možno data exportovat na disk, například po jejich úpravě (viz obrázek 8-8 popisek 5). Po stisknutí políčka s popiskem 3 ať už se jedná o obrázek 8-4 nebo 8-8 si můžeme zobrazit statistiku o použitých datech. Jak můžeme vidět na obrázku 8-9, záznam „repairExample" obsahuje 1 proces („Process"), 1104 případů („Cases") a 11855 událostí („Events"). Těchto 11855 událostí je reprezentováno 12 různými třídami („Event classses"). Toto úzce souvisí s pojmem klasifikátor, kdy jednotlivé instance událostí mohou být klasifikovány jako natolik podobné, že je v tomto směru můžeme označit za stejné. Například v našem záznamu jsou jednotlivé události reprezentovány příslušnými aktivitami, kterých je v tomto případě 12. To, že jednotlivé aktivity se vyskytují v různých časech či mají různé zdroje napříč jednotlivými případy, nás bude zajímat až u časové a organizační perspektivy, nicméně pro samotnou tvorbu modelu, ať už se jedná o Petriho síť či procesní mapu, je tato klasifikace událostí užitečná, kdy vlastně upouštíme od zdrojů a 168 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu časových značek. Dále můžeme vidět, že v záznamu máme dva typy událostí a sice „starť a„complete" neboli začátek a ukončení události (viz obrázek 8-10). Toto úzce souvisí s dalším pojmem, který jsme v kapitole 6 nepředstavili, a sice životní cyklus transakce (Transactional Life-Cycle). Představme si, že jednotlivé události jako aktivity. V takovém případě často nejsou události reprezentovány jediným bodem v čase, nýbrž časovým intervalem, jelikož vykonání dané aktivity může nějaký čas trvat a u dané aktivity tak registrujeme dvě události, a sice její začátek a konec (viz obrázek 8-10). Select visualisation... V () * # • m Obrázek 8-9: Zobrazení statistiky dat Zdroj: vlastní zpracování mm* • i <•> repairExample.mxml ^ ^ ^ ^ ^ ^ ^ ^ Class Occurrences (absolute) Occurrenc es (relative) Test Repair+complete 1508 12.72% Test Repalr+start 1508 12,72% Register+complete 1104 9.313% Analyze Defect+complete 1104 9,313% Analyze Defect+start 1104 9,313% Inform User+comp-ete 1102 9.296% Archive Repair+complefe 1000 8,435% Repair (Simple)+complete 785 6,622% Repair (Simple}+start 785 6,622% Repair (Complex)+start 725 6.116% Repair (ComplexJ-Komplete 724 6.107% Restart Repair+complete 406 3,425% Obrázek 8-10: Typy událostí „start" a „complete' 169 PŘÍPADOVÁ STUDIE PROM Zdroj: vlastní zpracování Dále můžeme na obrázku 8-9 můžeme vidět další statistiky jako minimální počet událostí na případ, což je rovno 4 („Event per case"), průměrný počet událostí na případ, což je 11 a maximální počet událostí na případ, což je 24. Pod diagramem počet událostí na případ vidíme diagram počtu tříd událostí na případ („Event classes per case"), kde minimum je 4, maximum je 12 a průměr je 9. Na základě obou průměrů a maxim můžeme v modelu očekávat smyčku. ÚKOL K ZAMYŠLENÍ Objasněte, proč nám průměry události na případ a třída událostí na případ mohou naznačovat vyskytující se smyčku v modelu. (Nápověda: soustřeďte se nato, jak vypadá stopa v modelu se smyčkou a podstatu toho, proč se oba průměry liší.) Vysvětlete, proč nemůže být hodnota maximální počet tříd událostí na případ v tomto případě vyšší než 12. repairExample.mxml 1000 1001 1002 1003 1004 1005 1006 1007 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 102 1020 1021 1022 1023 1024 •1 complete ©System 04.01.1970 02:28:00.000 Analyze Defect «2 start ©Tester* 04.01.1970 02:28:00.000 Analyze Defect •3 complete ©Tester! 04.01.1970 02:36:00.000 Repair (Complex) « start ©soiwrci 04.01.1970 02:52:00.000 Repair (Complex) « complete @5o1verC1 04.01.1970 03:09:00.000 Test Repair ** start ©Testert 04.01.1970 03:09:00.000 Test Repair W complete I M r l 04.01.1970 03:18:00.000 Inform User « complete ©System Attributes for case 100 LITERAL TYPED concept name: 100 description: Simulated process instanc Obrázek 8-11: Plocha zobrazení položka „Inspector" Zdroj: vlastní zpracování Přejdeme-li z položky „Dashboard" na položku „Inspector" na ploše zobrazení, můžeme si detailně a přehledně zobrazitjednotlivé případy vyskytující se v záznamu prostřednictvím políčka „Browser" (viz obrázek 8-11). Klikneme-li na vedlejší políčko „Explorer", zobrazí se nám jednotlivé případy graficky. Klikneme-li na další políčko „Log atributes", 170 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu zobrazí se nám obdoba obrázku 7-1, tedy jakási struktura dat respektive záznamu (viz obrázek 8-12). •- Wt Extensions - B lifecyde (Lifecycle) - B org (Organizational) - ft time crime) - B concept (Concept) L- B semantic (Semantic) t- • Global Trace Attributes L- 1 conceptname m Global Event Attributes k 1 conceptname ft litecyde transition - HI Classifiers ! H MXML Legacy Classifier [- B concept:name ft lifecyclelransition Ml Event Name ftj concept:name M Resource L- ft org:resource • Event Name AND Resource h- B concept:name L- B org:resource - f c Attributes - B conceptname - B description Obrázek 8-12: Struktura dat respektive záznamu Zdroj: vlastní zpracování Poslední položka na ploše zobrazení je „Summary", kde můžeme najít souhrnné informace o záznamu, jako například události vyskytující se na prvním či posledním místě ve stopách napříč záznamem, pravděpodobnost jejich výskytu atp. (viz obrázek 8-13). «mm! i., flu nicon repairExample.mxml ( Select visualisation... * ( > » » • • • • Class Occurrences (absolute) Occurrences (relative) System 1104 100.0% Class Occurrences (absolute) Occurrences (relative) System 1027 93.025% Tester3 20 1.812% Testen 14 1.268% Testere 12 1.087% Tester2 12 1,087% Tester4 10 0.906% Testers 7 0.634% SolverC3 1 0.091% Solvere 1 1 0.091% Obrázek 8-13: Shrnující informace o záznamu Zdroj: vlastní zpracování 171 PŘÍPADOVÁ STUDIE PROM Podobně si můžeme předem analyzovat i záznam „repairExampleSamplel" či jiná data, která jsme si do ProM importovali. Nicméně nyní už pojďme k samotné analýze. Zobrazíme si tedy akční plochu (viz obrázek 8-4 nebo 8-8 popisek 2). Nacházíme-li se v akční ploše, klikneme na položku „Click to add input objecť v levém sloupci „Input" a zvolíme soubor „repairExample". V případě, že bychom zvolili postup z obrázku 8-8, již bychom nemuseli znovu volit data, jelikož zvolený datový soubor se nám automaticky vloží do sloupce „Input". ProM UTTopia — m m m r n S w Plugin action info (B Alpha Miner Trie Alpha Miner Plugin implements a collealon of algorithms, all oeloning lo the 'Alpha Family All algonthms lake an ev nt log as an input and result in a I I Author S.J, van Zetst. B.F van Porigen. L M A Tonnaer S Categories: Discovery Petri net with an initial marking The algonthms are Based on me following papers: - Alpha (Classic): "Worwiow Mining: Discovery Process Models from Event Logs": Aalst, W M P van der. Weijters, AJ M M and. Maruster. L -Alpha*: "Process Mining (or U&iquilous Mobile Systems: An Overview and a Concrete Algorithm". Medeiros.AK A. de. Dongen, B.F van, Aalst WM P van der. and. Weijters. A J.MM - Alpha** "Mining Process Models with Non-Free-Chotce Constructs": Wen. L, Aalst W MP van der, Wang. J . and. Sun. J J Obrázek 8-14: Alfa miner v ProM Zdroj: vlastní zpracování Ať již zvolíme postup dle obrázku 8-4 nebo 8-8, dostaneme se k akční ploše na obrázku 8-14 v podstatě stejně. Ve chvíli kdy jsme vybrali data („Input"), zvolíme na akční ploše v prostředním sloupci „Actions", buď prostřednictvím vyhledávacího proužku („Search") anebo posunem myši, najdeme plugin „Alpha miner". Klikneme-li na „Alpha miner" zobrazí se nám ve spodní liště informace o daném pluginu („Plugin action info"). V pravém sloupci vidíme výstup („Output"), který dostaneme po aplikaci dané akce. V našem případě Petriho síť („Petrinet") a značení („Marking"). V seznamu akcí, jsou zeleně podbarveny akce, které můžeme s daným vstupem provádět, žlutě j sou akce ke kterým nám chybí vstupní data. V případě, že se objevíme na akční ploše tak jako tomu bylo na obrázku 8-5, kdy ještě nemáme zvoleny vstupní data a nejsme si jisti, jaká data budeme pro danou akci potřebovat, stačí ji najít v prostředním sloupci. Poté co klikneme na příslušný plugin se v levém sloupci „Input" vypíší data, kterou pro tuto akci potřebujeme, a zbytek zůstane stejný, ve spodní liště se objeví informace o daném pluginu a v pravém sloupci se objeví výstup dané akce. Toto můžeme vidět na obrázku 8-15, kde pro akci „Align log to Model" j e potřebný záznam a Petriho síť j ako vstup, a výstupem j e záznam, který j e na dané Petriho síti přehratelný. 172 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu Obrázek 8-15: Zjištění požadavků na vstupní data pro jednotlivé akce Zdroj: vlastní zpracování Jistě jste si po obou stranách vyhledávacího proužku všimli celkem sedmi ikon, pěti vlevo a dvou vpravo (viz obrázek 8-16 červené obdélníky). Nejprve se zaměříme na skupinku dvou ikon: zleva je filtr tzv. interaktivních akcí, což jsou akce, u nichž je potřeba jistého nastavení uživatelem, zatímco vpravo je filtr neinteraktivních akcí, u kterých již nemusí uživatel nic nastavovat. U druhé skupinky, tedy u skupinky pěti ikon se budeme věnovat jen prvním třem zleva: první ikonka je filtr objevovacích technik, druhá ikonka je filtr technik pro zjišťování shodnosti a třetí ikonka je filtr technik sloužících pro zlepšování procesů. 173 PRÍPADOVÁ STUDIE PROM Obrázek 8-16: Filtry pro hledání vhodných akcí na akční ploše Zdroj: vlastní zpracování Nyní tedy již pojďme aplikovat „Alpha miner' na náš „reparExample" záznam. Vrátíme se tedy na obrazovku 8-14 a klikneme na políčko „Start". Na další obrazovce ponecháme „Event classifier" na hodnotě „MXML legacy classifier", a u políčka „Version" zvolíme hodnotu „Alpha++" a klikneme na políčko „Finish". flu xicon Petrinet ( Obrázek 8-17: Aplikace Alpha++ algoritmu v pluginu Alpha miner Zdroj: vlastní zpracování 174 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu Alpha++ algoritmus objevil z dat, která j sou obsažena v souboru „repairExample" model v podobě Petriho sítě, který lze vidět na obrázku 8-17 výše. Červenou šipkou je označena hrana smyčky, kterou jsme předpověděli na základě statistik z obrázku 8-9. Můžeme vidět, že objevený proces je dobře strukturovaný a potýkáme se tedy s lasagna procesem. SAMOSTATNÝ ÚKOL Jistě si z kapitoly 6.3.2 vzpomínáte na definici spolehlivé sítě. Ověřte, zdali je Petriho síť na obrázku 8-17 spolehlivá či nikoliv. (Nápověda: ověřte, že síť splňuje uvedené čtyři podmínky či nikoliv). Své zjištění si můžete ověřit s pomocí akce „Analýze with Woflan" (V případě, že uvidíte zprávu psanou červeně „The net is not a sound workflow neť nejedná se o spolehlivou síť. Zbylý text řeší diagnostiku respektive otázku proč, ten už nás ale v tuto chvíli nemusí zajímat.) Ve třetí kapitole jsme se věnovali BPMN notaci. Pojďme si tedy s pomocí ProM převést objevenou Petriho síť na B P M N diagram. Což se provede jednoduše. Přejdeme na akční plochu a ve sloupci „Actions" vyhledáme akci „Convert Petři net to B P M N diagram". Jako vstup přidáme před chvílí vygenerovanou Petriho síť a stiskneme políčko „Starť. Výsledek konverze můžete vidět na obrázku 8-18. Export Obrázek 8-18: Převedení Petriho sítě z obrázku 8-17 na BPMN diagram Zdroj: vlastní zpracování Přestože jsme se v 6. kapitole intenzivně věnovali pouze alfa algoritmu, pojďme využít toho, že ProM nám nabízí široké možnosti a vyzkoušejme si i další objevovací techniky jako například heuristic miner či inductive miner. Opět se tedy přesuneme na akční plochu 175 PRÍPADOVÁ STUDIE PROM a na náš soubor „repairExample" aplikujeme heuristic miner, tedy konkrétně vyhledáme „Minefor a Heuristic Net using Heuristic miner", v mezikroku opět ponecháme přednastavené hodnoty. Dostaneme „heuristic neť, která připomíná procesní mapu v Discu s příslušnými frekvencemi a klikneme-li na jednotlivé aktivity, můžeme si zobrazit statistiku o vstupních a výstupních aktivitách dané aktivity (na obrázku 8-19 máme zobrazenu statistiku pro aktivitu „Analýze defecť). Select visualisation... Fitness: 0.9673 Obrázek 8-19: Heuristic net vygenerovaná prostřednictvím heuristic miner Zdroj: vlastní zpracování Už na první pohled je vidět, že model objevený prostřednictvím heuristic mineru se liší od toho produkovaného alpha minerem. Zájemci si mohou heuristic net konvertovat na Petriho síť a přesvědčit se sami prostřednictvím akce „Convert Heuristics net into Petri neť. Opět se tedy přesuňme na akční plochu a na náš soubor „repairExample" aplikujeme ještě třetí techniku inductive miner, respektive vyhledáme „Mine process tree with inductive miner" a v mezikroku opět ponechejme přednastavené hodnoty a obdobně i pro následující model. 176 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu ProM UITopia Select visLI.IM ... O • • • i Variables Varia tileProperu'es Expressions ExrjressioiiProperties Originators OriginatorPropertie: •Control-F lov/ Perspectiví bt>26f255-a66 on: Move cti (+) rToggle Blocking riuu PciwHiiue Senuenne nattern manifestatinn in renairFxamnle mxml 1 ^ fluxicon v mu Legend Element Statistics j Global Statistics Obrázek 8-23: Analýza výkonnostní složky modelu Zdroj: vlastní zpracování Na konci 6. kapitole jsme si kromě časové perspektivy říkali také o perspektivě organizační, a konkrétně jsme si říkali o analýze sociálních sítí prostřednictvím atributu. Sociální síť můžeme vidět na obrázku 8-24. Tuto je možno zobrazit prostřednictvím akce „Mine far handover-of-work sociál network", jejímž vstupem je analyzovaný záznam „repairExample". ProM nabízí čtyři akce spojené s analýzou sociálních sítí, a jednou z nich výše zmíněné akce předávání práce {„handover-of-work"), což znamená, že sledujeme předávání práce. Předávání práce je ve smyslu, měli-li bychom stopu (a, b, c) a věděli-li bychom, že aktivitu a vykonal Petr, aktivitu b Tomáš a aktivitu c Adam, pak by měli sociální síť se třemi uzly Petr, Tomáš, Adam orientovaná hrana by vedla od Petra k Tomášovi a od Tomáše k Adamovi. 179 PRÍPADOVÁ STUDIE PROM $g ProM UITopia Social Network (HoW) 33 TRANSFORMING • Edges removed forcl... View options Q shape by degree U size by ranking • stretch by degree ratio v] show vertex names • show edge weight values 0 show edge G stroke highlight on selection O Group Clusters ._) Hyperbolic View ^P^fluxkon I Select visualisation... Obrázek 8-24: Analýza sociálních sítí doplněná o statistiku zdrojů vyskytujících se v záznamu „repairExample" Zdroj: vlastní zpracování Z obrázku 8-24 je vidět, že práci si předávají vzájemně všichni pracovníci mezi sebou a nenachází se zde žádný, na kterém by celý proces závisel, respektive tedy samozřejmě celý proces závisí na informačním systému, který se stará o třetinu (30 %) všech aktivit, a který daný proces podporuje. Ale co se opravářů týče, tak skupinka „SolverCl", „SolverC2" a „SolverC3" starající se o opravy komplexních vad je v daném procesu zainteresovaná v přibližně stejném počtu událostí, jako skupinka „SolverSl", „SolverS2" a „SolverS3" starající se o nekomplexní vady. Nicméně co je zajímavé, je, že podíváme-li se na obrázek 8-23, tak jedna z podezřelých aktivit je právě „Repair complex" tedy oprava komplexních vad, což 180 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu dává smysl, jelikož opravy komplexních vad budou trvat daleko déle než vad méně kom­ plexních. ™ I D <•> Dotted Chart O ě 0 • • 3X Axis Attribute VAnis Attribute rrace Sorting Sort trace as they C: Event Name were in the original fie, Color Attribute Attribute Statistics O Connect events y-axis updated in 23 ms, Inspector 65 [£ Obrázek 8-25: Zobrazení událostí na ose x a příslušných zdrojů na ose y s využitím akce „Dotted chart" Zdroj: vlastní zpracování Komplexních vad je dokonce tolik, že „SolverCl", „SolverC2" a „So/verC5", přestože by mohli se k opravám nekomplexních vad ani nedostanou. Z tohoto pohledu by tedy mohlo stát za zvážení přeškolení jednoho či dvou ze skupinky „SolverSl", „SolverS2" a „SolverS3" do skupinky opravářů komplexních vad. Ale to už záleží na zvážení managementu firmy, jestli je toto úzké místo natolik vážné, aby stálo za to investovat prostředky do zaškolování pracovníků. Tímto uzavřeme případovou studii, týkající se představení softwarového produktu ProM. Zájemce samozřejmě opět nabádáme, pro bližší zkoumání ProMu. OTÁZKY 1. Jaký je rozdíl mezi špagetovým a lasagna procesem? 2. Jaké znáte další objevovací techniky kromě alfa-algoritmu? 3. S čím souvisí pojem životní cyklus transakce? 181 PŘÍPADOVÁ STUDIE PROM S SHRNUTÍ KAPITOLY V této kapitole jsme navázali na předcházející kapitoly, kdy jsme si ukázaly další možnosti aplikace process miningových technik a jejich aplikaci tentokráte ale v daleko mocnějším nástroji zvaném ProM, který nabízí daleko více přístupů, avšak na úkor příjemného grafického rozhraní a uživatelského komfortu. Tentokráte j sme se věnovali reklamačnímu procesu firmy na rozdíl od nákupního procesu v kapitole 7. V rámci této studie jsme si také blíže představili prostředí ProM. Nicméně jsme opět nebyly schopni projít všechny možnosti, které ProM nabízí. Záj emce opět nabádáme k detailnej Šímu prozkoumání tohoto soft­ waru. 0 ODPOVĚDI 1 Podkapitola 8.2, str. 177. 2 Podkapitola 8.2, od str. 178. Podkapitola 8.2, str. 171.3 182 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu LITERATURA [I] AALST, Will M.P. van der. Process mining: Discovery, Conformance and Enhancement of Business Processes. Heidelberg: Springer, 2011. ISBN 978- 3642434952. [2] AALST, Will M.P. van der. Process mining: Data science in action. Heidelberg: Springer, 2016. ISBN 978-3662498507. [3] AALST, Willy M.P. van der, Ana K.A. de MEDEIROS a Ton A.J.M.M WEIJTERS. Genetic Process Mining. Applications and Theory of Petri Nets 2005, Lecture Notes in Computer Science, 2005, Berlin: Springer, 48-69. [4] AALST, Willy M.P. van der, V. RUBIN, Eric H.M.W. VERBEEK, Boudewijn F. van DONGEN, E. KINDLER a C.W. GUNTHER. Process mining: a two-step approach to balance between underfitting and overfitting. Journal of Software and Systems Modeling, 2008, 9(1), 87-111 [5] AALST, Will M.P. van der, Ton A.J.M.M WEIJTERS a Laura MARUSTER. Workflow mining: discovering process models from event logs. IEEE Transactions on Knowledge and Data Engineering. 2004, 16, 1128-1142. [6] AALST, Wil van der a Kees van HEE. Workflow management: models, methods and systems. Paperback ed. Cambridge: MIT Press, 2004. ISBN 978-0262720465. [7] B ASL, Josef a Roman BLAZICEK. Podnikové informační systémy: podnik v informační společnosti. 3., aktualiz. a dopi. vyd. Praha: Grada, 2012. Management v informační společnosti. ISBN 978-80-247-4307-3. [8] BERGENTHUM, R., J. DESEL, R LORENZ a R. MAUSER. Process Mining Based on Regions of Languages. Business Process Management, Lecture Notes in Computer Science, 2007, Berlin: Springer, 375-383. [9] DUMAS, Marlon. Fundamentals of business process management. Berlin: Springer, 2013. ISBN 978-364-2331-435. [10] GALA, Libor, Jan POUR a Zuzana ŠEDIVÁ. Podniková informatika. 2., přeprac. a aktualiz. vyd. Praha: Grada, 2009. Expert (Grada). ISBN 978-80-247-2615-1. [II] GOLFARELLI, M., J. LECHTENBÔRGER, S. RIZZI a G. VOSSEN. Schema Versioning in Data Warehouses: Enabling Cross-Version Querying via Schema Augmentation. Data and Knowledge Engineering, 59(2), 435-459. [12] KINDLER, Evžen a Ivan KŘIVÝ. Simulace a modelování: učební text. Ostrava: Ostravská univerzita v Ostravě, 2001. Dostupné z: http://vendulka.zcu.cz/Download/Free/SkriptaKindlerMS .pdf 183 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesů [13] KISLINGEROVÁ, Eva. Oceňování podniku. Praha: C.H. Beck, 1999. C.H. Beck pro praxi. ISBN 80-717-9227-6. [14] Kolektiv autorů. Dohoda o chápání pojmu simulace systémů. Automatizace, 1986, 29(12), 299-300. [15] LEEMANS, S.J.J., D. FAHLAND a Willy M.P. van der AALST. Discovering Block-Structured Process Models from Event Logs - A Constructive Approach. Application and Theory of Petri Nets and Concurrency, Lecture Notes in Computer Science, 2013, Berlin: Springer, 311-329. [16] LEEMANS, S.J.J., D. FAHLAND a Willy M.P. van der AALST. Discovering Block-Structured Process Models from Event Logs Containing Infrequent Behaviour. Business Process Management Workshops, Lecture Notes in Business Information Processing, 2013, Berlin: Springer, 66-78. [17] LEEMANS, S.J.J., D. FAHLAND a Willy M.P. van der AALST. Discovering Block-Structured Process Models from Incomplete Event Logs. Application and Theory of Petri Nets and Concurrency, Lecture Notes in Computer Science, 2014, Berlin: Springer, 91-110. [18] MEDEIROS, Ana K.A. de, Willy M.P. van der AALST a Ton A.J.M.M. WEIJTERS. Workflow Mining: Current Status and Future Directions. On The Move to Meaningful Internet Systems 2003: CoopIS, DOA, and ODBASE, Lecture Notes in Computer Science, 2003, Berlin: Springer, 389-406. [19] MEDEIROS, Ana K.A. de, Boudewijn F. van DONGEN, Willy M.P. van der AALST a Ton A.J.M.M. WEUTERS. Process Mining: Extending the a-algorithm to Mine Short Loops. 2005. [20] MEDEIROS, Ana K.A. de, Boudewijn F. van DONGEN, Willy M.P. van der AALST a Ton A.J.M.M. WEUTERS. Process Mining for Ubiquitous Mobile Systems: An Overview and a Concrete Algorithm. Proceedings of the Second CAiSE Conference on Ubiquitous Mobile Information and Collaboration Systems, 2004, Berlin: Springer, 151-165. [21] MEDEIROS, Ana K.A. de, Ton A.J.M.M WEUTERS a Willy M.P. van der AALST. Genetic Process Mining: A Basic Approach and Its Challenges. Business Process Management Workshops, Lecture Notes in Computer Science, 2005, Berlin: Springer, 203-215. [22] REPA, Václav. Podnikové procesy: procesní řízení a modelování. Praha: Grada, 2006. Management v informační společnosti. ISBN 80-247-1281-4. [23] WEUTERS, Ton A.J.M.M., a Joel T.S. RIBEIRO. Flexible Heuristics Miner (FHM). 2011 IEEE Symposium on Computational Intelligence and Data Mining (CIDM), 2011,310-317. 184 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu [24] WEJJTERS, Ton A J . M . M a Willy M.P. van der AALST. Rediscovering Workflow Models from Event-Based Data using Little Thumb. Integrated ComputerAided Engineering, 2003, 10(2), 151-162. [25] WESKE, Mathias. Business process management: concepts, languages, architectures. New York: Springer, c2007. ISBN 978-3540735212. 185 Roman Sperka, Michal Halaška, Dalibor Simek - Techniky a nástroje v oblasti řízení podnikových procesu SHRNUTÍ STUDIJNÍ OPORY Studijní opora „Techniky a nástroje v oblasti řízení podnikových procesu" se vás pokusila seznámit se základními pojmy, metodami a přístupy k zlepšování podnikových procesů. Výchozím pojmem je nepochybně procesní model, který se používá na zachycení aktuálního stavu podnikového procesu - as-is procesní model a na návrh redesignu procesu - tobě procesní model. Smyslem řízení podnikových procesů je pomoci procesnímu řízení v podnicích, firmách nebo organizacích a důsledným sledováním životního cyklu B P M je možné podnikové procesy zlepšit, zjednodušit, případně automatizovat. Implementace B P M do řízení podniku je v současnosti nespornou konkurenční výhodou. Studijní opora se pokusila přiblížit čtenáři techniky, nástroje a praktické postupy ke splnění výše uvedeného cíle. 186 PŘEHLED DOSTUPNÝCH IKON E Čas potřebný ke studiu Klíčová slova Průvodce studiem I Rychlý náhled 7 7 Tutoriály K zapamatování Řešená úloha Kontrolní otázka |y] Odpovědi Samostatný úkol Pro zájemce jfej Cíle kapitoly Nezapomeňte na odpočinek 1 Průvodce textem V I Shrnutí D f l Definice mi E Případová studie Věta Korespondenční úkol Otázky Další zdroje Úkol k zamyšlení Název: Autor: Vydavatel: Určeno: Počet stran Recenzenti Tiskárna: Náklad: ISBN Techniky a nástroje v oblasti řízení podnikových procesů doc. RNDr. Ing. Roman Šperka, Ph.D. Ing. et Ing. Michal Halaška Ing. Dalibor Šimek Slezská univerzita v Opavě Obchodně podnikatelská fakulta v Karviné studentům SU OPF Karviná 188 prof. Ing. Miroslav Hučka, CSc. doc. Mgr. Petr Suchánek, Ph.D. X-MEDIA servis s.r.o. 50 ks 978-80-7510-312-3 Tato publikace neprošla jazykovou úpravou.