Struktura textu 1. Popis základních prvků notace BPMN. Vychází ze specifikace BPMN verze 1.212 . Jde pouze o lehký úvod, který je určen pro základní orientaci v notaci. Proto doporučuji následně pročíst příslušné pasáže specifikace. V popisu notace se na specifikaci také na mnoha místech odkazuji. 2. Antivzory, aneb jak to nedělat3 . Popis a zobrazení nejčastějších chyb, které se při modelování v BPMN dělají. 3. Návrhové vzory, aneb jak to dělat4 . Popis a zobrazení často se vyskytujících fragmentů diagramů. Úvod a motivace Níže uvedený text slouží k proniknutí do základů notace Business Process Model and Notation (BPMN). Obsahuje základní (minimálně nutné) znalosti k tomu, aby bylo možné vytvořit model středně složitého procesu tak, aby odpovídal notaci. Hned na úvod je nutné připomenout, že BPMN není jednoznačná notace, tzn. nezaručuje vytvoření 100% správného (formálně) modelu. Některé jiné možnosti zobrazení procesů (např. Petriho sítě) 100% (formální) správnost zaručují, ale nejsou příliš vhodné pro manažery. Jelikož text slouží pouze jako základní a přehledový zdroj, je vhodné studovat i z dalších metariálů. Další informace lze najít především na internetu. Oficiálním zdrojem informací jsou webové stránky Business Process Management Initiative: http://www.bpmn.org/. Další zdroje jsou již méně oficiální, ale v lecčems hodnotné. Rozcestník, který pokrývá i část zdrojů použitých v těchto výukových materiálech, lze najít na adrese: http://it.toolbox.com/blogs/the-soa-blog/bpm-designguide-24981. Dalším zajímavým materiálem o BPMN je blog ruského konzultanta: http://mainthing.ru/tag/pattern/. 1 Poznámka k českým překladům. Vzhledem k tomu, že většina pojmů z BPMN nemá oficiální české protějšky, jsou anglické pojmy obvykle přeloženy doslova. 2 Více viz http://www.omg.org/spec/BPMN/1.2/PDF/. 3 Antivzory přebrány z http://www.slideshare.net/tomirozman/eurospi2007trozman 4 Podrobnější materiál i s komentářem ke vzorům, které jdou nad očekávaný rámec nutných znalostí: http://wwwis.win.tue.nl/~wvdaalst/BPMcenter/reports/2005/BPM-05-26.pdf Činnosti Činnost je jakákoli práce (úkon, aktivita), která je vykonána v rámci procesu. Činnost může být buď atomická nebo složená. Činnosti mohou mít několik následujících podob: Obrázek slouží jako přehled možných druhů činností. Informace o jednotlivých činnostech lze najít Ilustrace 1: Zdroj: http://www.bpmn.org/Samples/Elements/Activities.htm ve specifikaci na straně 52 a dále. Události Prvek událost představuje událost, která nastane v průběhu procesu. Události ovlivňují tok procesu a obvykle mají příčinu nebo dopad. Může jít o počátek činnosti (např. Zpracování objednávky zahájeno), konec události (např. Zpracování objednávky ukončeno), změnu stavu dokumentu (např. Stavební povolení potvrzeno), příchod zprávy (např. Faktura od dodavatele obdržena) atd. V BPMN události zahrnují pouze takové druhy událostí, které mají efekt na posloupnost činností nebo na čas jejich začátku. V BPMN existují tři typy událostí: počáteční, mezilehlé a koncové. Počáteční a většina mezilehlých událostí je nějak spuštěna. Různé možnosti, jak události spustit jsou popsány na straně 38 a 45 specifikace. Koncové události mohou mít výsledky, které jsou definovány na straně 41 specifikace. Události mohou být více typů, jež jsou graficky rozlišeny piktogramem uvnitř (více viz http://www.bpmn.org/Samples/Elements/Events.htm, nebo specifikace). Ilustrace 2: Události.png Brány Brány se využívají k zobrazení rozdělování a spojování sekvenčních toků. V některých procesech je nutné kontrolovat jejich tok pomocí podmínek a rozhodovacích bodů, k čemuž brány slouží. Význam prvku brána spočívá v tom, že tento prvek procesu buď umožní, anebo neumožní pokračovat v toku procesu příslušným sekvenčním tokem. Jak je naznačeno na obrázku, existuje několik typů bran. Jejich podrobný popis je uveden ve specifikaci na straně 73-86. Brány se od sebe (až na komplexní bránu) liší logickými funkcemi, které jsou pro každou bránu charakteristické. Níže uvedená tabulka vyjadřuje charakter brány na základě vstupních (slučovací brána) nebo výstupních (rozdělovací brána) sekvenčních tocích. Logické funkce (1 = proces „projde“ větví, 0 = proces „neprojde“ větví): XOR AND OR 1 1 0 1 1 1 0 1 0 1 0 1 1 0 1 0 0 0 0 0 Komplexní brány slouží k řešení situací, které nelze jednoduše nebo vůbec vyřešit pomocí ostatní bran. Pro bránu se tak musí nadefinovat pravidlo, podle kterého se tok procesu rozděluje, respektive slučuje. Spojování objektů Objekty mohou být v BPMN spojeny pomocí tří způsobů: sekvenčním tokem, komunikačním tokem a asociací. Sekvenční tok se používá pro seřazení aktivit prováděných v rámci procesu. Sekvenční tok musí mít právě jeden začátek a jeden konec. Pomocí sekvenčního toku lze spojit pouze události, činnosti a brány. Komunikační tok se využívá pro zobrazení toků zpráv mezi dvěma entitami, které v BPMN představují bazény. Z tohoto důvodu musí být komunikační tok připojen buď k různým bazénům, anebo k prvkům z různých bazénů. Asociace se používá pro připojení informací a některých prvků (typicky datový objekt nebo poznámku) modelu k ostatním objektům. Více k asociacím na straně 129. Bazény a plavecké dráhy Bazény a plavecké dráhy se používají kvůli přiřazení zodpovědnosti za činnosti, což umožňuje organizovat a roztřídit činnosti do celků (útvarů) podle toho, kdo za ně nese zodpovědnost, respektive kdo je vykonává. Bazén představuje účastníka procesu, kterým může být buď konkrétní obchodní jednotka (podnik) nebo může jít o obecnější roli (např. zákazník, dodavatel, výrobce). Pokud je v diagramu pouze jeden bazén, nemusí být explicitně zobrazován. Bazén může být zobrazen buď jako „černá skříňka“ (black box) nebo jako „bílá skříňka“ (white box). V případě bazénu zobrazeného jako „černá skříňka“ jde o takový bazén, u nějž nás nezajímají detaily, a tudíž neobsahuje žádné činnosti (prvky). To znamená, že v případě „černé skříňky“ neobsahuje bazén ani jeden sekvenční tok. Může však obsahovat, respektive na něj mohou být navázány, komunikační toky. Plavecká dráha (nebo jen dráha) je podmnožina bazénu. Používá se zejména pro vyznačení interních rolí (vedoucí útvaru nebo oddělení), systémů (ERP systém), útvarů (výzkumné oddělení). Podle specifikace mohou být dráhy děleny na další dráhy, avšak ve skutečnosti obvykle záleží na možnostech modelovacího nástroje. Ostatní objekty Notace poskytuje možnost využít při modelování i další objekty než výše zmiňované. Jde o datové objekty, poznámky a skupiny. V diagramech se používají pro poskytnutí dodatečných informací, které výše popsané prvky neobsahují. Datový objekt obvykle znamená elektronický dokument, který reprezentuje buď elektronický anebo fyzický objekt. Poznámky slouží k poskytnutí dodatečných informací o celém procesu, nebo o objektech v diagramu, ke kterým jsou navázány pomocí asociace. Skupiny umožňují vizuálně seskupit činnosti, které jsou nějakým způsobem podobné, anebo mají mezi sebou souvislost, kterou nelze zachytit sekvenčním nebo komunikačním tokem. Skupiny mohou také přesahovat hranice jednoho bazénu. Konkrétním příkladem může být například v procesu Vyřízení zákaznické objednávky označení činností, které se věnují výrobě chybějícího zboží na skladě prvkem skupina pojmenovaným jako Výroba, a např. označení činností, které se věnují komunikaci se zákazníkem, objektem skupina pojmenovaným jako Komunikace. Antivzory aneb jak to nedělat Antivzor č. 1: Aktivity v jednom bazénu nejsou spojeny sekvenčním tokem Špatně Správně: Komentář: Vzhledem k tomu, že sekvenční tok je zásadní při určení logické návaznosti jednotlivých činností, musí mít každá činnost vstupní i výstupní sekvenční tok. Jinak se buď nikdy nevykoná, anebo v ní proces uvázne. Antivzor č. 2: V diagramu není počáteční událost. Špatně: Správně: Komentář: Každý proces musí nějak začínat. Z tohoto důvodu musí být v jednom bazénu právě jedna počáteční událost. Antivzor č. 3: Činnost nemá výstupní sekvenční tok. Špatně: Správně: Komentář: Každá činnost představuje část procesu. Jednotlivé prvky procesu na sebe nějakým způsobem navazují. Tuto návaznost vyjadřuje sekvenční tok. Po každé činnosti musí následovat buď událost, činnost nebo rozhodovací brána. V případě že proces činností končí, musí za činností být koncová událost. Antivzor č. 4: Prvek není umístěn v bazénu. Špatně: Správně: Komentář: Za každý prvek (např. činnost) musí být „zodpovědné“ nějaké oddělení. Jinak řečeno, každý prvek musí být součástí některého bazénu. Správné řešení může být dvojí. Buď patří prvek do bazénu, z kterého k němu vede sekvenční tok, nebo patří do jiného bazénu. V tom případě však k němu musí vést komunikační tok. Antivzor č. 5: Komunikační toky nahrazují sekvenční toky a komunikační toky vyjadřují jinou skutečnost než sekvenční toky. Špatně: Správně: Komentář: Sekvenční toky vyjadřují logickou a časovou následnost činností. Komunikační toky představují výměnu (směr toku) informace mezi dvěma bazény. Vzhledem k tomu, že sekvenční toky určují pořadí průchodu prvky diagramu, a o době průchodu rozhodují aktéři procesu, nelze tok procesu řídit pomocí komunikačních toků. Průběh procesu v jednotlivých bazénech je na sobě víceméně nezávislý a proto nemůže např. zákazník ovlivňovat pořadí prvků v bazénu podniku a naopak. Tyto nesourodé entity si mezi sebou mohou vyměňovat pouze zprávy. Proto nelze mezi sebou oba toky zaměňovat. Synchronizace komunikace mezi dvěma bazény se korektně zobrazuje jinak (viz Návrhový vzor č. 1). V tomto případě jde jen o základní obecnou ilustraci. Antivzor č. 6: Z jiného prvku než činnosti vede komunikační tok a datový objekt a do jiného prvku než činnosti (události) vede komunikační tok a datový objekt. Špatně: Správně: Komentář: Komunikační toky slouží k výměně informací mezi bazény. Původcem komunikace jsou vždy aktéři procesu a tudíž činnosti, které tito aktéři provádí. Součástí komunikace mohou být i datové objekty (např. dokumenty). Příjemcem komunikace jsou také aktéři procesu a tudíž nic jiného než činnosti nemohou být příjemcem komunikačního toku (s výjimkou událostí) a datového objektu. Antivzor č. 7: Činnost ani událost nemá vstupní sekvenční tok. Špatně: Správně: Komentář: Sekvenční toky slouží k zobrazení logické a časové návaznosti prvků procesu. Pokud tedy nemá např. činnost vstupní sekvenční tok, nikdy na ni v běhu procesu „nepřijde řada“. Každý prvek modelu musí být zařazen do sekvenční posloupnosti pomocí sekvenčního toku. Antivzor č. 8: Bazén obsahuje víc počátečních událostí Špatně: Správně: Komentář: Každý bazén musí obsahovat právě jednu počáteční událost. To znamená, že instance procesu v každém bazénu vzniká právě jednou událostí, respektive v právě jednom bodě. Pokud by měl proces více jak jednu počáteční událost, byl by proces nedeterministický, protože by se její jedna instance mohla nacházet ve více stavech. Z tohoto důvodu dochází hned po začátku procesu (vzniku instance) k rozhodnutí, který případ (událost) začátek procesu charakterizuje. Antivzor č. 9: Komunikační událost zobrazuje datový objekt. Špatně: Správně: Komentář: Komunikační událost zobrazuje stav procesu, v kterém dojde k příjmu zprávy. Zpráva (respektive dokument), který si předávají dvě činnosti navzájem, musí být reprezentován datovým objektem. Antivzor č. 10: Komunikační událost generuje komunikační tok a datový objekt. Špatně: Správně: Komentář: Viz Antivzor č. 6. Vybrané návrhové vzory aneb jak to dělat Vzhledem k tomu, že většina způsobů, jak (ne)modelovat základní skutečnosti procesů, byla zmíněna v předchozí části, je tato část věnovaná návrhovým vzorům podstatně kratší. Vzor č. 1: Komunikace Komentář: Na obrázku je znázorněno standardní schéma komunikace. Pokud spolu dva bazény (aktéři procesu) komunikují, děje se to na základě činnosti, v rámci které se zpráva odešle, instance procesu v druhém bazénu „čeká“, dokud nenastane událost přijetí zprávy, po ní následuje např. zpracování zprávy a obvykle odeslání odpovědi, na kterou „čeká“ instance procesu aktéra, který zprávu poslal. Procesy pak individuálně pokračují. Komentář: Pokud neznáme, anebo nás nezajímá, procesní logika v některém bazénu, lze ho zobrazit jako „černou skříňku“ (black-box). V takovém případě vychází a vchází komunikační toky přímo do bazénu a ne do jednotlivých činností. Vzor č. 2: Větvení a sdružování Komentář: Pokud dochází v procesu k větvení, je nutné použít brány. Každá brána představuje logickou funkci, podle níž se následně řídí tok procesu. Na schématu je pouze brána založená na logické funkci XOR, ale schéma je natolik obecné, že lze použít pro jakoukoli bránu. Pro přehlednost diagramu je zásadní, aby pokud je použita rozdělovací brána, byla ideálně vždy použita i příslušná slučovací brána. Ačkoli z povahu notace není tento přístup povinný, zamezí se tím nepřehlednosti a nejasnosti ohledně toku procesu. Vzor č. 3: Začátek komunikací Komentář: Pokud začíná proces v bazénu na základě komunikace (typicky, pokud chce něco zákazník), lze pro danou situaci využít výše uvedené schéma.