Petr Vašíček, IBA CZ
V minulém díle jsme si popsali proces založení objednávky, který budeme v rámci seriálu modelovat a implementovat. Ještě před tím si však představíme notaci BPMN, ve které bude modelování probíhat. Tento článek můžete brát jako takový jemný úvod do této notace. Komplexnější pohled na BPMN a detailnější návod pro modelování v něm by vystačil na samostatný seriál, proto si v dnešním díle uvedeme alespoň jeho základy. Závěrem uvedeme několik odkazů na dokumenty, ze kterých je možno získat podrobnější znalosti.
Pár slov o BPMN
Business Process Modeling Notation (BPMN) je grafická notace (soubor grafických objektů a pravidel, podle nichž mohou být mezi sebou spojovány), která slouží k modelování procesů. Za jejím vznikem stojí iniciativa BPMI (Business Process Management Initiative), jejímž primárním cílem bylo v tomto případě vytvořit notaci, která bude čitelná všemi účastníky životního cyklu procesu (business analytici, techničtí vývojáři, analytici monitorující procesy atd.). Díky BPMN se úspěšně podařilo zmenšit komunikační mezeru mezi návrhem a implementací procesu a díky desítkám nástrojů, které jej používají, se stalo de facto standardem pro modelování procesů.
Dalším cílem BPMI bylo představit notaci, jež bude na jednu stranu jednoduchá na pochopení a používání, na druhé straně ale nabídne možnost modelovat i komplexní business procesy. Důležité bylo rovněž definovat převod mezi návrhem procesu v BPMN a jeho implementací v BPEL, BPML, či jiném jazyce pro spouštění procesů. BPMN definuje, jak převádět jednotlivé elementy a sekvence těchto elementů do jazyka BPEL. Je tedy možné (manuálně) model procesu do jeho spustitelné podoby převést. Díky poměrné volnosti modelování v BPMN není možné vygenerovat BPEL automaticky, některé BPMS nástroje však tuto funkci nabízejí, a to za cenu určitých omezení při samotném modelování procesu.
V současné chvíli je BPMN ve verzi 1.1, jež byla formálně přijata v lednu 2008. Daleko používanější ovšem zůstává verze 1.0 (únor 2006), která se od novější verze liší pouze v několika kosmetických změnách. Verze 2.0, která by měla přinést zásadnější změny, je očekávána koncem roku 2008 či spíše během roku 2009.
BPMN definuje jediný diagram, tzv. Business Process Diagram (BPD). Ten je tvořen sítí grafických objektů, zejména aktivitami a zobrazením toku informací mezi nimi. Jednotlivé grafické objekty jsou od sebe dobře odlišené, což přispívá k přehlednosti diagramu. Jasně dány jsou tvary těchto objektů, které je třeba dodržovat, je ovšem možné volit pro ně vlastní barvy, například z odlišovacích účelů. V určitých případech 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, pouze jej upřesňovat, či poskytovat nějaké dodatečné informace.
Grafické elementy
Business Process Diagram obsahuje čtyři základní druhy grafických elementů, jež se ještě dále dělí na další podtypy. Nejastěji používané druhy ilustruje následující obrázek:
Následuje výpis základních informací o jednotlivých typech grafických objektů:
Flow Objects (Tokové objekty)
Objekty, které souvisí s tokem informací v procesu.
Event (Událost)
Activity (Aktivita)
Gateway (Brána)
Connecting Objects (Spojovací objekty)
Objekty, které slouží k spojení tokových objektů navzájem či s artefakty.
Sequence Flow (Sekvenční tok)
Message Flow (Tok zpráv)
Association (Asociace)
Artifacts (Artefakty)
Značí nějaké upřesňující informace pro proces, nemají vliv na jeho tok.
Data Object (Datový objekt)
Group (Seskupení)
Annotation (Poznámka)
Swimlanes (Plavecké dráhy)
Slouží k zobrazení účastníků procesu či uspořádání činnosti v procesu např. podle rolí.
Pool
Lane (Dráha)
Příklad Business process diagramu
Uveďme příklad procesu jednoduchého aukčního systému. Tok informací v tomto procesu je následující. Nejprve proběhne registrace položky do aukce. Pokud je položka v aukci, může být koupena buďto s okamžitou platností kdykoliv během trvání aukce (tzv. „Buy It Now“), nebo může aukce skončit po určené době. V tom případě je vydražena, pokud byl učiněn alespoň jeden příhoz. V případě, že položka byla vydražena (buďto „Buy It Now“ nebo přihazováním), čeká systém na přijetí platby. Pokud platba přijde do sedmi dní, nechá systém zaslat koupené zboží a proces je ukončen. Pokud položka nebyla vydražena či výherce do sedmi dní nezaplatil, je buď znovu registrována do aukce, nebo je proces ukončen (podle nastavení aukční položky).
Na obrázku můžete vidět, jak by zadaný proces mohl vypadat. Není to samozřejmě jediný možný model tohoto procesu, BPMN poskytuje poměrně velkou volnost při modelování, takže existuje více možností, jak navrhnout stejný proces pomocí této notace.
Nyní si popíšeme tok v procesu tak, jak jej vidíte na uvedeném obrázku. Začátek procesu je zaznačen zeleným kroužkem. Odtud míří tok procesu do aktivity, jež značí registraci položky do aukce. Poté, co je položka registrována začne běžet aukce. Během ní mohou proběhnout dvě události – buďto někdo koupí položku hned (příjem zprávy „Koupeno hned“), nebo dříve dojde ke skončení aukce vypršením stanovené doby (časová událost typu „Timer“). Je tedy použito rozhodnutí na základě události a proces bude pokračovat větví, ve které nastane událost jako první. Pokud jako první nastane konec aukce, je třeba rozlišit, zda existují na položku nějaké příhozy. Jestli ano, míří tok procesu k čekání na přijetí platby stejně jako v případě, že někdo koupil položku již před skončením aukce díky možnosti „Buy It Now“. K aktivitě „Přijmout platbu“ je připojena událost „Timer“ s popisem „7 dní“. Tím je řečeno, že pokud proces setrvá v této aktivitě sedm dní, bude jeho tok směřovat větví, jež vybíhá z této události. Pokud je do sedmi dní platba přijata, je zboží zasláno výherci aukce – aktivita „Zaslat zboží“ - a proces končí. Pokud položka nebyla koupena nebo platba nedorazila, tok procesu bude ústit do grafického objektu znázorňujícího rozhodnutí na základě informace (tedy jestli má být zboží nasazeno znovu do aukce). Pokud má být položka znovu registrována, míří tok procesu na začátek do první aktivity, v opačném případě proces spěje do ukončovací události (červený kroužek) a je zastaven.
Závěrem
Účelem tohoto dílu bylo poskytnout jemný úvod do grafické notace Business Process Modeling Notation, kterou budeme používat pro modelování procesu v příštím díle. Uvedli jsme základní informace o této notaci a krátce představili její nejčastěji používané grafické elementy. Na závěr jsme si ukázali jednoduchý proces, na kterém můžeme vidět v praxi některé z grafických objektů. K hlubšímu pochopení, jak tyto objekty používat, a vůbec k lepšímu pochopení konceptu modelování v BPMN můžeme doporučit následující dokumenty:
3. část: Úvod do BPMN
Téma: BPM prakticky (seriál), BPMS, Modely
Subscribe to:
Komentáře k příspěvku (Atom)
21 Comments:
Děkuji za návodný příklad BPMN. Ještě jsem si ho sama nenamalovala, ale notace vypadá opravdu jednoduše.
Všem, kdo už BPMN trochu znají, doporučuji následující test - nečtěte si slovní popis vzorového procesu, ale prohlédněte si diagram a pokuste se ho interpretovat. Schválně - nakolik bude shodný?!
Mr. Korbel, dobrý test! Podle něj vůbec namalovaný proces textu neodpovídá nebo jen na hódně přehledové úrovni. Navrhuji autorovi reparát!
Co se Vám, Jíro, na diagramu nelíbí? Co na něm není a v textu je? Buďte konkrétní, ať se my hloupí poučíme.
Tak jen na ukázku - v jednom tasku "Registrovat do aukce" jsou semlety nejméně 3 zcela odlišné aktivity - vlastní registrace (provádí vlastník zboží), koupení zboží ihned a přihození (provádí kupec). Mělo by tedy buď jít o subproces nebo - a to pro demonstraci notace BPD by bylo vhodnější, task na tyto aktivity rozdělit - nejlépe do samostatných swimlines, které by reprezentovaly jiného nositele. A hned je celý model jinak.
Já totiž z tohoto modelu bez komentáře opravdu např. nevyčtu, že se dá přihazovat...
Jinak mám mj. i připomínku ke zvolenému způsobu pojmenování aktivit/subprocesů. Všude v literatuře jsem se dočetl, že je jediné správné pojmenování aktivity ve tvaru "Registrování do aukce", "Přijetí platby", Zaslání zboží"...
Myslím, že jen dokazujete v textu výše uvedenou větu: "Není to samozřejmě jediný možný model tohoto procesu, BPMN poskytuje poměrně velkou volnost při modelování, takže existuje více možností, jak navrhnout stejný proces pomocí této notace."
Navíc v BPMN není problém udělat z jakékoliv aktivity později subproces.
Uvedený proces je zamýšlen jako proces u prodávajícího, tedy registrací se provádí registrování položky do aukce. Přihazování není řešeno v tomto procesu (to může být např. spolu s potvrzením příhozu apod. součástí procesu nějaké aukční služby, kterou prodejce využívá, do které právě položku registruje), po registraci probíhá aukce a u prodejce je zachycena až událost "Koupeno hned" nebo "Konec aukce".
Jistě by bylo možné podobný proces namodelovat i jiným způsobem, ukázat například ostatní účastníky a interakci s nimi, účelem bylo ale zejména demonstrovat použití několika základních grafických elementů na praktickém příkladě.
Pokud jde o názvy aktivit, musím říct, že v literatuře dostupné mě, a to včetně specifikace BPMN, jsou uvedeny aktivity jako slovesa, tedy např. "Send Invoice", "Collect votes", "Reserve Hotel" apod. Pokud můžete uvést odkazy na literaturu o BPMN, ve které se udává opak, budu samozřejmě rád.
Je úplně jedno, jak byl proces "zamýšlen". Kritizoval jsem to, že něco jiného je napsáno v textovém popisu procesu a něco jiného lze vyčíst z diagramu.
K pojemnování aktivit - doufám, že pro Vás bude dostatečnou autoritou Bruce Silver - viz BPMN and the Business Process Expert, Part 3:
The Art of Process Modeling:
Pravidlo 4. Use tasks to represent work. Label them VERB-NOUN.
A jste si jist, že ste si to pravidlo spávně vyložil, příklady přeložil? :)
Ať koukám na Bruceův weblog či 3. část zmíněného článku je tam: Validate order čož rozhodně není v Ověření příkazu, ale Ověřit příkaz/Ověr příkaz.
Dle výše uvedeného je to tedy v článku pojmenováno správně.
Verb-noun je v češtině podstatné jméno slovesné. A to může být buď dokonavé - ověření, nebo nedokonavé - ověřování. Snadno se také pak tvoří názvy eventů - např. příkaz ověřen (čili datový objekt plus jeho stav způsobený aktivitou).
Nechci se přít, ale stejná pravidla byla využívána již v UML a pokud se nemýlím, stejný způsob pojmenování se užívá i v arisovském epc.
My máme také v konvencích modelování už několik let, že se používá pro tasky podstatné jméno slovesné a ani nevím, kde se to vzalo. Je to občas dost nešikovné - u běžných sloves to nevadí, ale jsou případy, kdy urputné používání právě tohoto tvaru vypadá hloupě nebo násilně a pak použijeme přímo substantivum (místo zkontrolování jen kontrola). Používat imperativy nechceme, protože se to pak plete s jednorázovými akcemi resp. cíli. Takhle odlišíme na první pohled, zda jde o procensí aktivitu nebo projektový task.
Co se tu ještě neřešilo, je otázka vidu. Videm se totiž dá velmi jednoduše odlišit, zda jde o proces nebo projekt. A na použitém tvaru nezáleží, jde to použít jak u substantivu, tak u imperativu (tam je to jednodušší).
Příklad pro proces:
Ověřování nebo Ověřovat
Příklad pro jednorázovou aktivitu:
Ověření nebo Ověřit
Řekl bych, že vid je důležitější než tvar.
S tím videm je to taky trochu sporné. Má být určen podle toho, co se děje přímo v procesu nebo obecně - když jde o proces, tak použít nedokonavý vid?
Při druhé způsobu použití to může být pěkně matoucí - když mám aktivitu Ověřovat a ve skutečnosti v rámci procesní instance provedu jen jedno ověření, jako v tomto případě.
Podle mě by vid měl být volen tak, aby vyjadřoval skutečnou činnost,která probíhá v rámci aktivity. Tedy pokud proběhne jedno jediné ověření dokonavý vid Ověřit, pokud probíhá opakovaná činnost v rámci jedné instance nedokonavý vid Ověřovat.
Jde přece o to, aby model byl srozumitelný, ne gramaticky jednotný.
Souhlasím s Alicí. Svého času jsme se snažili o rigidní pojmenování různých typů objektů a dopadlo to hodně křečovitě.
Jinak i aktivita v rámci projektu může probíhat opakovaně:)
Myslím, že je to velmi užitečná diskuze:)
Rád bych se ještě vrátil k tomu verb-noun. Nejsem si úplně jistý, že tím autor myslí podstatné jméno slovesné, ale spíše možná dvojici "sloveso - podstatné jméno".
Podle oxfordského slovníku: "a noun formed as an inflection of a verb and partly sharing its constructions, such as 'smoking' in 'smoking is forbidden'."
To znamená, že pokud by autor myslel podstatné jméno slovesné (verbal noun), musel by aktivity označovat jako "Reviewing Budget Documentation" či "Validating order". Protože ale používá tvar "Validate order", vede mě to spíše k přesvědčení, že pod VERB-NOUN myslí dvojici sloveso - podstatné jméno, tedy "validate" - "order".
Nechci se přít, ale stejná pravidla byla využívána již v UML a pokud se nemýlím...
Takze v UML 2.1, potažmo activity diagramu (který je založený na Petriho sítích), který se dá použít pro modelování business procesu, je použítí následující: Napsat dopis, Poslat dopis atd. Tzn vid dokonavý.
Ještě uvedu zdroj, např. Jim Arlow, UML2 a unifikovaný proces vývoje aplikací, Grada 2007, ISBN 978-80-251-1502-9.
Musím říci, že tohle byla jedna z nejzajímavějších diskusí, jaké jsem tu četl.
V naší firmě o konvence pojmenování vedeme válku již řadu let - a to nikoliv o to, zda je správně infinitiv nebo gerundium nebo čisté substantivum verbale (ó jak je ta angličtina jasná), ale o to, aby jednou stanovený tvar se používal trvale a všude. Tj. bylo na první pohled vidět, co tím autor míní a dalo se podle toho hlavně vyhledávat. A jmenovalo se to vždycky a všude stejně.
Na tohle bychom potřebovali recept. Kdysi jsme začali i se slovníkem pojmů, ale to je neudržitelné,má to smysl jen u nejdůležitějších business entit. Nemáte někdo nějaký dobrý návod?
Do doby,než se dočkáme sémantického webu (a to si v češtině počkáme:),nezbývá než držet nějakou formu podnikového slovníku, což se v řadě businessmodelerů dá - třeba v arisu je na to zvláštní model pojmů.
U nás máme seznam povolených sloves,která se mohou pro pojmenování aktivit používat. Datové objekty jsou jasné - jak jsou jednou zavedeny, musí se používat. U událostí používáme stejnou zásadu, jako zde psal jíra - datový objekt plus verbum z předchozí nebo budoucí aktivity v příslušném čase.
Příklad:
povolené sloveso - Ověřit
datový objekt - Objednávka
aktivita - Ověření objednávky
událost před - Objednávku ověřit
událost po - Objednávka ověřena
Proto je v češtině lepší pro aktivity používat slovesné podstatné jméno, aby se to nepletlo s událostí před.
Pokud by se užíval infinitiv, je třeba doplnit událost před o pomocné sloveso, např.
- Objednávku je nutné ověřit
Ale-jak pravil vznešený Seneca - není důležité, jaká gramatika se zvolí, ale jak se zvolená gramatika bude dodržovat.
Závěr - bez slovníku pojmů to nejde!!
Rozběhly se tu 2 debaty, které jsou odlišné. První - jak co správně namalovat v BPMN, což se (obávám) z jednoho článku v seriálu, který má navíc jiný účel, asi sotva naučíme.
Druhá je obecnější - jaké názvosloví v modelech používat obecně (a pokud lze - bez ohledu na použitou notaci). Což je opět, podle mého názoru, mimo zaměření seriálu, byť je to zajímavé.
Mslím, že bychom se měli držet tématu - jak zprovoznit miniBPMS. Bude asi dost složité samo o sobě.
ad Dušák: Nevím, proč by mělo být na škodu vyjasnění, jak přistupovat k pojmenování objektů - to je natolik obecný a trvalý problém, že se hodí pro jakékoliv modelování. Navíc tento díl o modelování byl.
Velmi se mi líbí přístup Věry - zdá se, že je opřen o řádnou praxi. Použití infinitivů je bezesporu jednodušší a nenutí vytvářet v češtině někdy násilné slovesné útvary typu "kontrolování". Není nutné ani doplňovat u událostí pomocná slovesa - to, že jde o event se pozná ze slovosledu: nejdříve datový objekt a pak sloveso (Objednávku ověřit), u aktivit naopak (Ověřit objednávku). Navíc eventy před činnostmi se moc nepoužívají, důležité jsou hlavně eventy za rozhodovacími operátory a tam už může být minulý (existující) stav datového objektu.
K uvedenému modelu v BPD - také jej nepovažuji za nejlepší. Sice chápu, že má jen demostrovat použití notace, ale zrovna tento příklad volá po využití poolu.
Post a Comment