7 THE EVENT-DRIVEN PROCESS CHAIN (UDÁLOSTMI ŘÍZENÝ PROCESNÍ ŘETĚZEC)

87

7 THE EVENT-DRIVEN PROCESS CHAIN (UDÁLOSTMI ŘÍZENÝ PROCESNÍ ŘETĚZEC) RYCHLÝ NÁHLED DO PROBLEMATIKY KAPITOLY THE EVENT-DRIVEN PROCESS CHAIN (UDÁLOSTMI ŘÍZENÝ PROCESNÍ ŘETĚZEC) Rychlý náhled

CÍLE KAPITOLY THE EVENT-DRIVEN PROCESS CHAIN (UDÁLOSTMI ŘÍZENÝ PROCESNÍ ŘETĚZEC) Po úspěšném a aktivním absolvování této KAPITOLY Budete umět

Budete umět:

 Vypište cíle kapitoly. Postupujte jako v začátku celého modulu.  Metodiky je doporučováno, aby i zde bylo členění 'Budete umět …, Získáte …, Budete schopni …', tj. stejné jako v cílech celého modulu. Zvažte, pravděpodobně podle délky kapitoly. Získáte

Získáte:

 Instrukce k psaní uvedeny v cílích modulu Budete schopni

Budete schopni:

 ... ČAS POTŘEBNÝ KE STUDIU Celkový doporučený čas k prostudování KAPITOLY je minut.

KLÍČOVÁ SLOVA KAPITOLY THE EVENT-DRIVEN PROCESS CHAIN (UDÁLOSTMI ŘÍZENÝ PROCESNÍ ŘETĚZEC) Klíčová slova

V této kapitole se podíváme na Event-driven Process Chain, který tvoří jádro Aris metody. Máme zkoumat jak je postaveno používání událostí, funkcí, pravidel a jak na model rozhodování, paralelní cesty, smyčky a procesní toky.

7.1 Úvod Event-driven Process Chain (EPC) je hlavním ARIS modelem pro reprezentaci procesů. Jedná se

Lucie Ciencialová

Informační systémy II.

88 o dynamický model spojující statické zdroje podniku (systémy, organizace, data, atd. ) a organizující jim dodat posloupnost úkolů nebo činností (‘proces’), který přidává obchodní hodnotu. Existuje několik druhů EPC (řádek, sloupec, atd.), ale v této knize se budeme soustředit na základní informace a vztahy uvedené v EPC.

7.2 EPC Objekty V podstatě existují čtyři typy objektů používané v EPC:

 Události,  Funkce,  Pravidla,  Zdroje (data, organizace, systém atd. ). Obr. 7.1 ukazuje příklad EPC modelu procesního fragmentu čtyř typů objektů. V této kapitole se podíváme na první tři typy a ukážeme, jak jsou používány v modelu procesního toku. V kapitole 11 uvidíme přidávání zdrojových objektů, můžeme ukázat, jak tento proces interaguje se svýmprostředím. 7.2.1 Události ARIS události představují měnící se stav světa, jak proces probíhá:

 Vnější změny, spuštěny na začátku procesu (Např. “customer order received”/“Zákazníkova objednávka přijata”),

 Interní změny stavu pokračujícího procesu (Např. “product manufactured”/“Výrobek vyroben”),

 Konečný výsledek procesu, který má vnější efekt (Např. “order delivered to customer”/"Objednávka dodána zákazníkovi")

Lucie Ciencialová


89

7.1 Typický EPC procesní model

K zapůjčení termínu softwarového inženýrství: události představují „pre-podmínky“ a „postpodmínky“ pro každý krok v procesu. Pre-podmínky jsou ty věci, které musí být přítomny, nebo uvedeny před spuštěním činnosti. Post-podmínky představují to, co se změnilo v důsledku jednání aktivity. Události mohou nastat v důsledku lidské činnosti nebo jako důsledku IT systémové operace. Poslední událost v jednom procesu může být podnětem pro další proces, a tak můžeme spojovat části procesů k vytvoření větších „end-to-end“ procesů. Chcete-li popsat události, obvykle používáme konvence „podstatné jméno-sloveso“ nebo, více specificky v IT prostředí, „informační jednotka – akce“ (viz. Tabulka 7.1).

7.2.2 Funkce ARIS Funkce představují činnosti nebo úkoly prováděné jako součást obchodních procesů;

Lucie Ciencialová


90 v ideálním případě s každým přidáním nějaké hodnoty pro podnik. Funkce mohou být prováděny lidmi nebo IT systémy. Mají vstupy (informace nebo materiály), vytvářejí výstupy (různé informace nebo produkty) a mohou konzumovat zdroje. V kapitole 11 se podíváme podrobněji na přesnou povahu procesů, činností a funkcí. Uvidíme, že jsou ve skutečnosti „transformace“, ale pro moment můžeme jen myslet funkcí jako „dělání něčeho“. K popisu funkcí používáme konvenci „sloveso-podstatné jméno“ nebo více specificky, „akce-informační položka“ (viz tabulka 7.2).

Expert tip – je docela běžné používat termíny jako „prodej“ či „Marketing“ k reprezentaci vysoké úrovně obchodních operací. Nicméně, je velmi snadné splést tyto jména se jmény obchodního oddělení. Je lepší použít „sloveso-podstatné jméno“ přístup k popisu toho co je ve skutečnosti provedeno (např.: „Prodáváme produkt“). Je důležité nepoužívat nejasné či rozvláčné popisy funkcí. V podrobnějším procesním modelování funkcí budou zastupovat konkrétní, srozumitelné činnosti (např.: „Vstupní objednávka“). Nicméně, při modelování na vysoké úrovni operací to může lákat k delším popisům (Např.: „Přijmout pořadí, ověřování, procesy a informovat zákazníka“). Je lepší mít jeden stručnější název nebo rozdělení funkce do několika samotných funkcí.

7.3 The Event-driven Process Chain Funkce jsou spuštěny jednou nebo více událostmi. V ARIS terminologii událost „aktivuje“ funkci a funkce bude vždy „vytvářet“ jednu nebo více nových událostí. Takže události spouští funkce, a funkce vytvářejí nové události což spouští další funkce, a tak dále, k vytváření řetězce funkcí a událostí – Event-driven process chain (obr. 7.2). Ve skutečnosti Event-driven process chain by měl být skutečně jen Event-driven function chain. Tip – v předchozích kapitolách jsme předvedli EPC fragmenty přesně tak, jak jsou uvedeny v Designer Modulu. My se podíváme na mnoho příkladů EPC v této kapitole. Tak aby byly čitelnější na tištěné stránce, vypneme barvy pozadí objektů a vytvoříme spojovací linie tučnější. Ve skutečnosti procesy nejsou jednoduché řetězce událostí a funkcí a potřebujeme zavést pojem procesu flow. Procesní toky jsou postaveny kolem rozhodování a paralelních drach. Rozhodnutí: změna pracovního procesu jsou vždy přijaté funkce, ale k reprezentování možných logických výsledků potřebujeme zavést „Pravidla“. Krátce jsme toto představili v kapitole 5, ale my se na to podíváme podrobněji v oddíle 7.4. Lidé, kteří jsou zvyklí na jiné modelování a nástroje, které nemají pojem Event-driven process chain, často přemýšlí o hodnotě zavedení události. Jsou spíše více zvyklí právě na závádění funkcí společně jednu po druhé. Ukážeme si v oddílu 7.3.2, že přidáním událostí do procesního modelu, představuje míru přísnosti, která vytváří ARIS modely přesnější reprezentaci „Skutečného světa“ a tím zvyšuje jejich hodnotu. Důležitá pravidla, které jsou třeba mít na paměti při použití Eventdriven Process Chain jsou:

Lucie Ciencialová


91

 Každý model musí začínat a končit událostí  Funkce a události se vždy střídají Funkce by se normálně neměli připojovat k jiné funkci a události by se nikdy neměly připojovat k jiným událostem. S jednoduchými modely je snadné zajistit střídavost „zelené“ a „fialové“ barvy, ale ve větších modelech, s mnoha pravidly, může být trošku těžší toto pravidlo dodržet. Nejjednodušším způsobem jak toho dosáhnout, je sledovat každý krok, ignorovat pravidla a kontrolovat zda se funkce a události střídají.

7.2 Event-driven process chain

Expert Tip – vytvoření vhodného Metodního Filtru může být použito k prosazení modelování úmluv, jako například nedovolují funkce pro připojení k jiným funkcím. 7.3.1 Pojmenování Událostí v EPC Pojmenovávání událostí v EPC vyžaduje určité dodatečné vysvětlení. Způsob, jakým se díváme na události, závisí do značné míry na tom, zda jsou na začátku procesu, na konci procesu, nebo uprostřed (obr. 7.3).

Lucie Ciencialová


92

7.3 Pojmenování událostí

Začátek Události Událost v horní části procesu představuje změnu ve vnějším světě, která způsobí, že celý proces bude zahájen. To spouští první funkci v procesu a pojmenováním je obvykle vybráno něco smysluplného a významného pro proces jako celek, spíše než jen něco relevantního pro první funkci. Tedy můžeme nazvat událost „Customer Order Received“ spíše než „Envelope in Post Tray“. Konec Události Událost na konci procesu představuje dokončení celého procesu (nebo jeho část je popsána v modelu). Na konci události může být často spoušť pro další postup v jiném modelu, takže je moudré zvolit jméno, které je významné při pohledu na konci modelu, nebo na začátku druhého. Jeho jméno tedy není nutně související s funkcí, která ji vytvořila, které mohou mít malý význam. V příkladu na obr. 7.2, poslední událost byla Cost Calculated. Ve skutečnosti, pravděpodobně další funkce a události po tomto kroku, ale pokud opravdu byla na konci procesu, pravděpodobně bychom měli dát významnější jméno jako „Order Entry Complete“. Vnitřní Události Události uprostřed procesu, pokud jde o spojení posloupnosti funkcí dohromady, jsou obě spouštěcí události pro následující funkce a výsledek akce pro předchozí funkci. To nám dává problém, máme je označit, aby odrážely to, co se právě stalo nebo co se asi stane? Běžná konvence je název, aby odrážely výsledek předchozí funkce. Jak uvidíme níže, toto nám pomáhá zjistit, že jsme správně popsali, co funkce dělá a jak proces probíhá. V procesech, kde je dlouhý sled funkcí a událostí bez jakékoli změny toku řízení, jména uplynulých událostí budou bezvýznamné a

Lucie Ciencialová


93 nepřidají velkou hodnotu. Někteří lidé jsou v pokušení nechat si ujít tyto události ven, ale to může být nebezpečné, jak uvidíme později. Nicméně, občas, událost může naznačovat, že bylo v procesu dosaženo významné etapy. V tomto případě je zcela přijatelné, aby událost měla významnější jméno, právě jako jsme udělali s „koncovou událostí“. Taková pojmenování by měla být šetrně používána k vytvoření většího efektu. 7.3.2 Proč užívat události? Noví ARIS lidé, zejména ti, kteří používají jiné diagramy nebo modelovací nástroje, často uvažují o hodnotě přidávaných událostí mezi každou funkci. Proč právě nepřipojovat funkce přímo spolu můžeme vidět na obrázku 7.4a. V ARISU je možné připojovat funkce dohromady, pokud je to povoleno v metodě Filter. Nicméně, existují dobré důvody proč to udělat, jelikož přidávání a pojmenování událostí je:

 Dobrou kontrolou správné definice funkce.  Dobrou kontrolou správného procesního toku. První důvod pro nepřímé spojování funkcí dohromady je kázeň vypracování. To, že událost následuje funkci je velmi dobrá kontrola, že funkce byla správně popsána:

 Má se funkce skutečně projevit jako důsledek této události?  Má událost vždy aktivační funkce, nebo jsou tam jiné podmínky, které musí být splněny? Také pohled na událost následující funkce:

 Má popsat, co se změnilo v důsledku výkonu funkce?  Je to výsledek, nebo je tam více alternativ? Pokud nemůžeme přijít na to, co se změnilo, je pravděpodobné, že definice funkce není správná. Pokud se spíše zdá, že se hodně změnilo, stala se celá tato změna jako důsledek v této jedné činnosti? Je možné, že co funkci představuje, není opravdu jen jednou činností, ale počtem činností (paralelní nebo sekvenční) shrnutými dohromady, že by bylo lepší je uvést samostatně. Zkontrolujte, zda granularita a význam této funkce je podobný jako v ostatních modelech.

Lucie Ciencialová


94

7.4 Benefit akcí

Druhým důvodem pro používání událostí je pečlivé zvážení události následující funkce, bude jasné to, kde rozhodnutí ovlivňuje procesní tok. Podívejme se znovu na tento proces užívání funkcí na obrázku 7.4a. Proces vypadá jako jednoduchý řetězec činností: Enter Order (zadání objednávky), Check Order (kontrola objednávky) a Manufacture product (výroba produktu). Ale teď pohled na proces v obr. 7.4b, kde události byly přidány mezi funkcemi. Zejména pohled na událost následující funkce Check Order (kontrola objednávky). Jak by měla být tato skutečnost nazývána? Je lákavé označit za „Order checked“ (objednávka skontrolována). Na první pohled to vypadá v pořádku, ale koukněte se znovu; dává to smysl? Co se změnilo v důsledku kontroly objednávky? Je mnohem zjednodušující říct, objednávka byla zkontrolována. Proč byla objednávka zkontrolována? Krok nepřidává hodnotu, pokud existuje důvod pro kontrolu objednávky a tudíž je možný více než jeden výsledek. Lidé se často dopouštějí této chyby, když začínají používat Aris. Je-li otázka: „Proč by měla být objednávka zkontrolována?“ Modeláři téměř vždy vědí proč (např.: zda je příkaz platný nebo je-li nad určitou peněžní hodnotu) ještě nemají zohledněny tyto poznatky v modelu. Jako důsledek postrádají zřejmé skutečnosti, které jsou více než jeden výsledek z výkonu funkce. Funkce nejen provádí kontrolu, ale také dělá rozhodnutí o tom, co by mělo následovat. Jestliže se nyní podíváme na správný postup procesního modelu na Obr. 7.4c můžeme vidět, že je pravidlo za funkcí, které je následováno dvěma událostmi. Tyto události nyní představují dva možné výsledky rozhodnutí přijaté Check Order funkce. Pravidlo představuje logiku výsledku

Lucie Ciencialová


95 (Např.: s XOR pouze jeden z nich může dojít v kterémkoli okamžiku.) Na pravidla se podrobně podíváme v oddílu 7.4. V jednoduchém příkladu výše jsme předpokládali to, že byl jen jeden výsledek (výstup) z Enter Order (Příjem objednávky), ale dva výstupy z Check Order(kontrola objednávky). Samozřejmě je taky možné že může být více než jeden výstup z Enter Order. Například, příjem objednávky může selhat a alternativní akce může být potřebná. Je to věcí názorů, jak mnoho detailů potřebuji v modelu. Pamatuj: „Don´t model the universe!“ (Nemodeluj vesmír!) „Know when you have done enough.“ (Víš, když jsi udělal dost.) „Define standards and stick to them.“ (Definuj všechny standardy a drž se jich.) Tak, zdaleka zbytečné úsilí, přidávání událostí mezi funkce přidává míru přísnosti k modelování procesů. To pomáhá zajistit: Modely jsou přesnější odraz toho, co se skutečně děje. Nevýhodou je: Modely jsou stále větší, což vytváří stručnou prezentaci více obtížnou. Pokud opravdu musíte, můžete odstranit „triviální“ události mezi řetězci funkcí, zejména v highúrovni modelů. Avšak, důrazně doporučujeme zpočátku stavět své modely se všemi událostmi v místě. Jen jednou jste přesvědčený, model je správný, měl byste odstranit triviální události.

7.4 Pravidla a procesní tok Jak jsme řekli výše, reálné procesy nejsou jen skládány z postupných kroků. Potřeba vyrovnat se s paralelními dráhami, rozhodnutími a složitými toky je důvod, proč použít modelovací nástroje k prezentování procesů. K modelu procesního toku přidáme „Pravidla“ k funkcím a událostem dle dřívějšího popisu. V předešlé části jsme viděli příklad (Obr. 7.4c), kde byly dva možné výstupy rozhodnutí, z nichž pouze jeden může být pravdivý v kterémkoli okamžiku. 7.4.1 Pravidla Existují tři základní typy pravidel, jak je uvedeno v tabulce 7.3 a mají mírně odlišná použití v závislosti na tom, zda následují nebo předcházejí funkce. Porozumění toku procesních modelů je nezbytné pochopit, jak pravidla kombinovat s funkcemi a událostmi, k zastoupení rozhodnutí a paralelních cest. Rozhodnutí (viz sekce 7.5) užívá OR a XOR pravidla, zatímco paralelní cesty (viz sekce 7.6) užívají AND pravidla. Některé kombinace nejsou validní za žádných okolností, zatímco jiné jsou platné, ale jsou matoucí, takže je nebudeme ukazovat. Jestliže použijete pravidla jaká jsou definovány výše, a na příkladech, které následují, budete moci správně modelovat většinu situací procesu flow.

Lucie Ciencialová


96

Poznámka 1: Je nezbytně nutné zvážit časové období, během něhož všechny události musí nastat, aby spouštěcí operátor AND byl validní. Expertní tip – ke změně pravidla z jednoho různého typu (Např.: OR na XOR), vybereme operátor, Pravý Click>Properties(Vlastnosti) [Format / Object Appearance] a vybereme nový operátor ze Symbol – navigačního boxu. Poté zvolte Attributes Tab (Atributy tabulky) na Properties Bar (Vlastnosti) a změňte Name (jméno) atributu operátoru.

7.5 Rozhodnutí V ARIS EPC modelování metodou rozhodnutí jsou tvořeny funkce; jméno funkce popisující přijímání rozhodnutí. 7.5.1 Modelování rozhodnutí Funkce tvoří rozhodnutí a připojí se pravidlo, které určuje logika z možných výsledků (Např.: OR nebo XOR). Toto pravidlo má jediný vstup a dva nebo více výstupů. Výstupy vedou k událostem, které uvedou, jaký konkrétní výsledek rozhodnutí vyvolalo cestu z procesu (viz Obr.: 7.5b). Měli byste se vyhnout OR nebo XOR pravidlům po události, protože není žádná funkce, aby se rozhodlo o následující cestě. Můžeme to někdy vidět v top-úrovni modelů. Například v Obr. 7.5a, událost Order Received (objednávka přijata) se připojuje k OR, který se připojuje na paralelní cesty tak, že každý proces je jiného typu pořadí. Předpoklad je, že když je objednávka obdržena, je směrována vhodnou cestou z Order-handling (objednávka-zacházení) procesu.

Lucie Ciencialová


97

7.5 Modelování rozhodnutí

Ačkoli tato zkratka přístupu zachovává model jednoduchý, může dát falešný dojem z toho, co se skutečně děje. Pokud je objednávka skutečně směrována k různým procesům, je lepší modelovat funkci, která představuje směrování rozhodnutí, i když je automatická (Obr.: 7.5b). Pokud, na druhou stranu, objednávky nejsou vedeny ke konkrétnímu procesu, ale zákazník odešle objednávku na jinou adresu v závislosti na produktu, pak jsou ve skutečnosti zcela oddělené procesy a to je chyba modelu, jako by se jednalo o jeden. Nesprávné modelování rozhodnutí je jednou z nejčastějších chyb lidí používající Aris. Obvykle lidé nemodelují co se skutečně děje, ale jen nějakou idealizovanou verzi. To vede pouze k pozdějším problémům během implementace, analýzy nebo re-designu. 7.5.2 Rozhodovací pravidla Existují dvě pravidla, která můžeme použít k zastupování rozhodnutí:

 OR – Kombinace cest,  XOR - Jedna cesta nebo druhá, ale ne obojí. Je velmi lákavé modelovat vše pomocí OR operátoru, neboť se jedná o pojem používaný v běžném jazyce. Avšak, v praxi většina rozhodnutí může mít pouze jeden z možných výsledků, a proto by měla být modelována pomocí operátoru XOR. Výjimky jsou situace podobné příkladu Order-processing (Objednávka-zpracování), zmiňovaném výše. Představte si například obchod s různými postupy pro poskytování, kde se každý roz-

Lucie Ciencialová


98 dílný výrobek prodává. Když objednávka dorazí, to může být právě pro jeden produkt, nebo to může být pro kombinaci produktů. K modelu této situace byste měli po funkci použít OR operátor, aby bylo možné zahájit libovolnou kombinaci procesních toků. Nicméně, měli byste si uvědomit, že později v procesu musí být krok, který dbá na správnou kombinaci produktů sestavených před konečnou dodávkou (viz Obr. 7.6). Tyto situace nejsou tak časté, takže můžeme sestavit obecné pravidlo:

 Model rozhodnutí vždy s operátorem XOR, pokud jste si jisti, více kombinací může opravdu nastat. 7.5.3 Spojování rozhodovacích cest Výsledkem rozhodnutí je vyslat proces jednou nebo více alternativními cestami. Někdy jedna z těchto cest může být dead-end, kde se proces zastaví, ale normálně se cesty spojí zpět dohromady na nějakém místě k dokončení procesu. Připojení by mělo vždy být provedeno s použitím stejného pravidla, použitého při jejich rozdělení, po rozhodnutí, jak je ukázáno na Obr. 7.6.

Lucie Ciencialová


99

7.6 Spojování rozhodovacích cest

Lucie Ciencialová


100

7.7 a) Multiple joins b) Alternativa

Lucie Ciencialová


101

Vyvstává otázka: Mělo by se spojovat v alternativní cestu po událostech nebo po funkcích? Pokud máte zajištění funkcí a událostí správně nahrazeno, nezáleží na tom. Obvykle je lepší připojovat po událostech (obr. 7.6a), takže událost na konci každé cesty značení dokončení cesty. „Spojovací“ pravidlo je poté následováno funkcí. Pokud potřebujete vytvořit spojení na samotném konci procesu, často neexistují žádné funkce po a před připojením finálové události. V tomto případě budete muset položit pravidlo před finálovou událost a cesty musí končit ve funkcích (Obr. 7.6b). Často cesty rozdělené z několika různých rozhodnutí se připojí na stejném místě. V takovém případě, i když můžeme přinést všechny spojující cesty dohromady ve stejné pravidlo, je dobrou praxí používat jednotlivá pravidla a tyto pravidla připojit jako v Obr. 7.7a. To je zásadní v případě, že pravidla jsou různých typů (např. OR a XOR). Obr. 7.7b ukazuje alternativní přístup. OR pravidlo spojuje cestu z Product B Require, tok je oddělen událostí Product A Ready z XOR pravidla, které kombinuje cesty z toku Product A Required. To je možné, protože Variant A a Variant B cesty v toku Product A Required byly modelovány, končí ve funkcích. Přestože jsme říkali, že obecně lepší zakončení cest je v událostech, tato reprezentace zřejmě vede k jasnějšímu modelu. To jen dokazuje, že neexistuje jediná správná cesta k modelu procesu. Pokud chápete střídání událost-funkce řetězce, můžete zvolit reprezentaci, která se zdá mít co největší smysl z hlediska procesu, který modelujete. 7.5.4 Rozhodnutí nic nedělajících cest Myslíte si, že cesty vyplývající z rozhodnutí, kde se následně nic nestane, budou zbytečné, ale ve skutečnosti k nim dochází poměrně často. Podívejte se na příklad v obrázku 7.8a. Pokud je nátěr stále mokrý, budeme muset počkat na to, až uschne, před použitím druhého nátěru. Pokud je nátěr již suchý, můžeme provést přímo uplatnění druhého nátěru, takže není potřebný pro úkol a tudíž funkci v „paint dry“ cestě. Obr. 7.8b ukazuje alternativní způsob jak to reprezentovat. Tentokrát tam není událost nebo funkce v „paint dry“ cestě, ale právě jen spojující linka. Příklad levé-strany má tu výhodu, že události následují po pravidlu, aby bylo zřejmé co je výsledkem rozhodnutí. Na druhou stranu, příklad pravé strany vypadá čistší a je to velmi zřejmé, že se nic neděje v „paint dry“ cestě. Nicméně, to není tak jasné, který výsledek vyvolal „nic nedělací“ cestu, aby to bylo jasné, museli jsme se uchýlit k uvedení štítku na cestu. Opět budeme muset vybrat nejvhodnější metodu pro proces, který modelujete. Upozornění – Pokud byste měli potřebu mít dvě události se stejným názvem, je důležité si vytvořit dvě oddělené události. V žádném případě byste neměli kopírovat událostní objekt. V každém případě je dobrá praxe, aby byla jména podobných událostí mírně odlišná. Pokud bychom nepotřebovali druhý nátěr a Paint Dry byl konec procesu, nebudeme mít jinou možnost, než použít reprezentaci pravé strany, protože potřebujeme konec procesu v Události.

Lucie Ciencialová


102

7.8 Cesty, které nic nedělají

7.6 Paralelní cesty Paralelní cesty používají pravidlo AND, které odděluje proces do dvou nebo více cest. Cesty se obvykle připojují dalším užitím pravidla AND dále v procesu. Když se připojují, tak daný proces nemůže pokračovat, dokud nejsou všechny cesty spojeny pravidlem AND. V příkladu 7.9 musíme dát dohromady oba diagramy toků: ,,Výroba výrobků A“ a ,,Výroba produktů B“ pro každou objednávku. Pravidlo AND rozděluje, je používáno po událostech a nejlepší postup je spojení po poslední události v paralelních cestách. Nutno podotknout, že to není tvrdé a rychlé pravidlo. Můžete spojovat cesty po funkcích a dát jednu funkci po AND pravidlu, které reprezentuje, že všechny cesty byly dokončeny.

Lucie Ciencialová


103

První je lepší pro dlouhé komplexní procesní cesty, a další pro jednoduché paralelní úlohy. Rozdělení procesů do paralelních drah, znamená, že mohou být proveden ve stejnou dobu, protože nejsou na sobě závislé. Samozřejmě, jen proto, že je to modelováno touto cestou, to neznamená, že budou procesy provedeny ve stejnou dobu. Nemůže tam žádná procesní závislost, ale pokud stejná osoba dělá stejné úkony, pak dovede dělat pouze v jeden v aktuálním čase (pokud to ovšem není žena, ta má zabudovaný multitasking=) Dokonce však, i pokud se liší lidé, kteří dělají na úkolech, pořád není záruka, že budou pracovat plně paralelně, mohou tam být značné rozdíly mezi dokončením jedné větve a té druhé. Setříděním skutečného procesu budeme schopni zjistit, jestli je tento proces prováděn tak, jak jsme zamýšleli. Simulace v programu ARIS nám umožní zkontrolovat, zda alokovanými zdroji lze dosáhnout toho, co jsme zamýšleli.

7.9 Paralelní cesty

7.7 Spuštění 7.7.1 Základní spuštění Většina z příkladů má jediné spuštění, a to na začátku procesu. Tato akce představuje změnu stavu ve vnějším prostředí, a vyžaduje proces začít. Při definování spouštěcí události je důležité se ujistit, že událost sama o sobě nepostačí k nastartování procesu. Například, aby zvednutí telefonu je zřejmé spoušť. Zazvoní telefon, někdo odpoví, a m. Podobně, obdržení faxu se rovněž zdá být spoušť. Kdybyste modelovali prodejní proces na vysoké úrovni byste určitě akce ukaž telefon a FAX jako alternativní spouštěcí mechanismy. Nicméně, na podrobnější úrovni, nemohou být ekvivalentní. Neexistuje žádná záruka, že když

Lucie Ciencialová


104 přijede FAX, někdo si toho všimne, že bude proces objednávky. Proto může být nezbytné navrhnout postup, kde pravidelně, někdo kontroluje FAX. Procesy se často nedaří, protože úkoly, které jsou 'tak zřejmé nejsou modelovány, předpokládá se, že někdo jiný to udělá. Dobrým příkladem jsou internetové webové stránky, které chtějí e-mailovou adresu pro vytvoření kontaktu na zákazníka, ale když jím ji odešlete, tak nikdo neodpoví Vždy kontrolovat vaše akce a používejte následující testy:

 Má případě představují externí 'změna stavu'?  Má změna stavu sama o sobě přímo spustit proces na rozdíl od pouhého vlivu na něj?  Je události postačující k spuštění procesu? Nebo jsou tam i jiné podmínky, které musí býtsplněny? 7.7.2 Hromadné spuštění Často může být proces spuštěn několika různými událostmi. Obr. 7.10 ukazuje tři příklady modelovaných s odlišnými pravidly. Jak jsme viděli s rozhodnutími, využívání XOR je běžnější než OR. Je však velmi důležité, aby byla vypracována správná logika pro spuštění procesu. V prvním příkladu, Obr. 7.10a, vidíme začátek procesu, aby byl vstup vyvolaný zákazníkem telefonování nebo posílání faxu. Na první pohled se to zdá docela jednoduché a je modelován s XOR. Ale to, co se stane, když zákazník telefonuje na místo na objednávku, ale také posílá faxové potvrzení? V tomto případě jedna nebo obě události spustí proces.

7.10 Hromadné spouštění

Chceme-li zvládnout tuto situaci, mohli bychom být v pokušení nahradit XOR s OR, ale je to správné? Telefonní hovor bude vždy spouštět proces, ale pokud je to společné pro zákazníky také poslat potvrzení faxem, pak když jsme obdrželi fax, by bylo nutné zapojit FAX s předchozím telefonem, aby se zajistilo, zda byl zaslán pouze jednou. To znamená, že proces manipulace obdržení faxu se poněkud liší od obdržení telefonního hovoru a je třeba modelovat odlišně. Můžeme nyní vidět, že modelování se spouští pomocí OR a může být trochu nepříjemné. Pokud použijete OR, měli byste si velmi pečlivě zjistit o tom, co to znamená. V Obr. 7.10b je podmínka Zvonek u dveří zvoní OR zaklepání na dveře. To znamená, že jakékoli kombinaci těchto událostí může vyvolat proces. Buď událost spustí proces sám, a to je docela zřejmé anebo návštěvník může zaklepat na dveře a zazvonit ve stejnou dobu a fotografií spouští otevřít dveře stejným způsobem. No, možná byste mohli odpovědět, že by to mohlo být rychlejší, ale stále jen otevíráte jen jednou.

Lucie Ciencialová


105 Chcete-li použití OR, musíte si být jisti, jestli obě události se stanou zároveň a mají přesně stejný účinek jako spuštění jedné. Pokud se rozhodneme, že nikdy nenastanou současně pak, za předpokladu, že oba mají stejný spouštěcí efekt, můžeme používat XOR jestliže potřebujeme více komplexní logiku. Rozdílné scénáře jsou shrnuty v tabulce 7.4

Tabulka 7.4: Logika spouštění událostí Třetí příklad na Obr. 7.10c, spouští ukazuje, kombinaci s AND. Obě události musí nastat dříve, než je funkce spuštěna. V tomto příkladu jsme trvali na tom, ť zákazník potvrdí telefonicky objednávku faxem, než ji můžeme zpracovat. Setkáváme se však s problémem času. Pokud zákazník telefonicky objedná, ale nikdy nedostaneme FAX, proces bude bez pokračování. V praxi bychom raději, aby zákazník zavolal, pokud jsme neobdrželi FAX do druhého dne. Proto musíme vzít v úvahu během jakého časového období je události spojená AND musí dorazit k postupu, který bude spuštěn, a pokud ne, pak co uděláme místo toho? Výše uvedené příklady jsou spíše vymyšlené, ale přispívají k názoru, že musíte pečlivě přemýšlet o tom, jak více událostí spojit a spustit dohromady. Použitím jediného pravidla může nalézt správou cestu, jak popsat nepříjemné scénáře, ale to může způsobit, že zakryjete zásadní detail, který by měl být založen na podrobnějším rozboru.

7.8 Smyčky Chcete-li zvládnout složitější procesní toky a rozhodnutí, musíte zavést pojem smyček. Smyčka se vrací procesu dříve, aby znova spustila část procesu znovu. Obr. 7,11 ukazuje poněkud složitější verzi našeho zájmu- procesu manipulace. Tento proces vyžaduje potvrzení faxem, které mají být přijaty. Původní telefonické objednávky mohou být zpracovány. Protože tam může být zpoždění Před tím, než je telefax doručen tj. proces kontroly, zda objednávka stále platí, tj. cena je stále ještě správné. Pokud je objednávka v pořádku, bude objednávka aktuální události odkazovat na zbytek objednávky- odbavovacím procesu. Pokud je objednávka již neplatná, je zákazník požádán, zda chtějí, aby se upravily ceny. Pokud tak učiní, proces smyčky skočí zpět na začátek procesu, projde po řádku a potvrdí činnost znovu. Chcete-li připojit smyčku do procesu a máte rozdělené spojení mezi prvním případem a funkce vkládají XOR operátor, aby se připojila smyčka. Můžete si všimnout, že je XOR a ne OR proto = logicky, počáteční poušť a spuštění smyčky by nikdy nemohlo dojít dohromady.

Lucie Ciencialová


106 Zároveň ale bude muset počkat svůj tah. Proces pokračuje přesně, jako předtím se zákazníkem ještě potřebují potvrdit faxem. Samozřejmě, pokud zákazník opět zpozdí odesílání faxu, může pořadí dat jít znovu, tak bychom šli kolem smyčky jindy. Jestliže je tomu tak i nadále, mohli bychom jít smyčkou navždy, to je problém se smyčkami. Takže v praxi bychom potřebovali unikavou trasu. Možná, že kdyby pořadí upravili, tak by to šlo. Potřebujeme jistotu při odesílání, že se proces vrací do dřívějšího bodu, neboli že se stejný postup opakuje stejným způsobem. Často vykazuje výjimky nebo chyby i proces smyčky - zpět na předchozí bod. V našem příkladě (obr. 7.11), jsme ukázali přehrávání detailů objednávky, kroky se opakovaly. Nicméně, v praxi by to nemělo být nutné. Nechcete-li znovu zadat celou zakázku znovu, ale jen k aktualizaci cen. Typicky, existují některé speciální procesy ve smyčce, které pak spojují hlavní proces později, než bylo prvně myšleno. Je to věcí názoru, zda má být upozorněno na detailní rozdíly, které nastaly po smyčku zpět.

Lucie Ciencialová


107

7.11 Funkce, události a kombinační pravidla

Třetí příklad na Obr. 7.10c, spouští ukazuje, kombinaci s AND.

7.9 Spojení všeho dohromady

Lucie Ciencialová


108

Možná si myslíte, že Událostně-řízený procesní řetězec je opravdu poměrně složitý. Avšak, všechno jsme dělali kombinací tří základních typů objektů (funkce, události, pravidla) dohromady představují různé scénáře procesního toku. Je možné kombinovat tyto objekty dohromady mnoha různými způsoby. Některé z nich jsou platné a některé z nich platné nejsou, jsou shrnuty v Obr. 7.11. Obr. 7.12 ukazuje úplnější verzi našeho zájmu-vyřizování procesu zahrnující mnoho scénářů uvedených v této kapitole. Ale nezapomeňte, ne vše může být reprezentováno jako proces. Komplexní plánování projektu, úkoly s více možnostmi a data řízené systémy nezvládají model stejně jako procesy, buď proto, že mohou být lépe zastoupeny v dalších způsobech, nebo protože využívají vysoký stupeň lidské inteligence, design a plánování při jejich provádění. 7.9.1 Pravidla pro modelování v EPC Na základě zásad, které jsme zavedli v této kapitole, můžeme shrnout následujícími základními pravidly užívání Event-driven process chain k pokrytí modelování procesních toků:

 Každý model musí mít alespoň jednu startovní událost a jednu koncovou,  Funkce a události se vždy střídají,  Funkce a události mají pouze jediné příchozí a odchozí spojení,  Procesní cesty vždy rozdělit a spojit pomocí pravidel,  Více událostí spouští funkce v kombinaci s užitím pravidel,  Pravidla nemohou sledovat jednu událost,  Rozhodnutí jsou přijímána funkcemi,  Funkce, které přijímají rozhodnutí, jsou vždy sledovány pravidly,  Pravidla ukazují platnou kombinaci cesty, na které následuje rozhodnutí,  Události následující pravidla ukazují aktuální výsledky rozhodnutí,  Pravidla nemohou mít více vstupů a výstupů. Tato pravidla následují ARIS metodu, ale v některých případech jsou přísnější než ty, které se mohou setkat v průběhu školení ARIS, nebo v ARIS nápovědě. To je, aby se odstranily některé nejasnosti, které se objevují, když lidé používají pravidla v nejednoznačných způsobech.

Lucie Ciencialová


109

7.12 Spojení všeho dohromady

Lucie Ciencialová


110

SHRNUTÍ KAPITOLY THE EVENT-DRIVEN PROCESS CHAIN (UDÁLOSTMI ŘÍZENÝ PROCESNÍ ŘETĚZEC) Shrnutí kapitoly

Lucie Ciencialová


7 THE EVENT-DRIVEN PROCESS CHAIN (UDÁLOSTMI ŘÍZENÝ PROCESNÍ ŘETĚZEC)

Recommend Documents