BPM_01 Modelování podnikových procesů doc. Ing František Huňka, CSc. 155
Obsah kurzu • I. část: podnikový proces: – definování, účel použití, techniky modelování (grafické zobrazení), metodologie podnikových procesů – DEMO (Design Engineering Methodology for Organizations) 7 přednášek
• II. část: hodnotové modelování podnikových procesů – hodnotově orientovaný přístup REA (resource – event – agent), 4 přednášky
• III. část: praktické uplatnění a zasazení podnikových procesů. 2 přednášky 2
Obsah přednášky • Pojem podnikového procesu a jeho využití • Pojem modelování • Tradiční techniky modelování podnikových procesů (diagramy) • Zhodnocení jednotlivých hlavních metodik modelování podnikových procesů.
3
Model, modelování • Model je abstrakce popisující problémovou doménu a/nebo řešení problémové domény. • Tradičně jsou modely vytvářeny formou diagramů plus jejích odpovídající popis (dokumentace) – ne diagramy formou výsledků pohovorů (interview) a např. kolekce CRC diagramů (class responsibility collaborators).
4
Podnikový proces (Business Process)
• Podnikový proces je kolekce činností mezi rolemi aktérů, kterou iniciátor procesu získává nějakou hodnotu (nemusí jít o hodnotu bezprostředně vyjádřenou finančně). • Proces definuje kroky, které mají být podniknuty (provedeny), role aktérů (lidí), které tyto kroky provedou a artefakty, které jsou použity ke splnění účelu (důvodu), který poskytuje hodnotu někomu nebo nějaké organizaci. • Artefakt – dokument, model, soubor, diagram nebo položka vytvořená, modifikovaná nebo použitá během vývoje, operace nebo podpory systému.
5
Aktér, agent, role aktéra • Aktér představuje v modelu lidskou bytost, lidský subjekt. • Agent – počítačová entita reprezentující lidskou bytost v programovém systému. • Pro modelování je výhodné zavést role, např. role studenta, role pacienta, role učitele, role děkana. • Každá lidská bytost vystupuje v souběžně několika rolích. • Výměna fyzických osob v rolích – jmenování nového ředitele, děkana, role se nemění, mění se jen osoba. 6
Podnikový proces a jeho modelování • Procesní modely nám umožňují popsat často komplikovaný tok logiky uvnitř systému. • Procesní model je sociální systém, protože se v něm vyskytují lidské bytosti ve formě aktérů – správně ve formě rolí aktérů. • Zpravidla je iniciátor procesu a vykonavatel (exekutor, performer) procesu.
7
Podnikový proces a jeho modelování • Procesní modely také ukazují jak jsou informace systémem zpracovány a k podpoře těchto interakcí, popisují aktivity procesu a toky informaci mezi aktivitami. • Kromě aktivit podnikové procesy také popisují podniková pravidla (business rules). • Podniková pravidla: (constraints, derivation rules) – omezující podmínky: věk, max počet členů, max délka pobytu – odvozující pravidla: rok narození – věk, spotřeba na km, počet km – spotřeba celkem. 8
Podnikový proces a jeho modelování • Příklad podnikových procesů: – Zápis studenta ke studiu (výběr kurzů pro daný semestr, vstupní podmínky, výstupní podmínky), – Získání členství v tenisovém klubu, – Výpůjčka auta, – Zpracování cestovního příkazu.
9
Místo podnikového procesu ve vývoji programové aplikace • Vývoj programového vybavení: 1. Požadavky na systém – requirement analysis – forma: diagramy případů užití (use case modeling) (strategie číšníka – waiter strategy)
2. Uživatelské rozhraní jeho vývoj 3. Dodatečné požadavky (supplementary requirements) – podniková pravidla, omezující podmínky, komentáře – specifikace použitých pojmů
10
Místo podnikového procesu ve vývoji programové aplikace 4. Konceptové modelování – samotné požadavky jsou nedostačující, třeba techniku k doplnění detailů a chybějících artefaktů – vytvořit požadovanou strukturu 5. Modelování podnikových procesů – dynamická část řešení 6. Návrh architektury (most mezi požadavky a návrhem) 7. Dynamické modelování (sekvenční diagramy) 8. Modelování návrhu struktury (diagramy tříd) 9. Implementace, testování 10. Návrh a vývoj databáze 11
Podnikový proces • Prostřednictvím podnikových procesů (business procesů) můžeme snadněji pochopit informační systém specifikované domény. • Podnikový proces jako základ pro definici požadavků na SW – zpětně ovlivňuje požadavky na programové řešení.
12
Pojem podnikový proces další definice
• Podnikový (byznys) proces je po částech uspořádaná množina procedur a aktivit, které společně realizují podnikatelský nebo strategický cíl, obvykle v kontextu organizační struktury definující funkce rolí a jejich vztahy.
13
Pojem podnikový proces • Pojmem procedura rozumíme podproces obsažený v daném procesu. • Pojmem po částech uspořádaná množina pak vyjadřujeme fakt, že ne všechny aktivity a procedury lze seřadit do jediné posloupnosti.
14
Pojem podnikový proces • Model podnikového procesu je abstraktní reprezentace podnikového procesu obvykle umožňující jeho další zpracování automatizovaným způsobem. • Podnikový proces, jehož provádění je částečně, nebo dokonce úplně počítačově automatizováno se nazývá workflow (tok prací). • Workflow je automatizovaný podnikový proces. • Workflow systém je informační systém, který vykonává dohled na správnou sekvencí aktivit . 15
Workflow - definice • Automatizace celého nebo části podnikového procesu, během kterého jsou dokumenty, informace nebo úkoly předávány od jednoho účastníka procesu k druhému podle sady procedurálních pravidel tak, aby se dosáhlo nebo přispělo k plnění celkových/globálních podnikových cílů.
16
Workflow • Podnikový proces a workflow bývají zaměňovány, protože jejich význam je blízký, ne však totožný (z pohledu podnikové ontologie). • Jediným rozdílem je, že workflow spravuje a řídí k tomu určený software – ERP (Enterprise Resource Plamming) nebo WFM (Workflow Management) systém. • Je však důležité si uvědomit, že právě workflow, díky svému počítačovému zpracování, klade vysoké nároky na specifikaci procesu, na jeho přesnost a jednoznačnost. • Workflow - tok prací. 17
Kategorizace metod a nástrojů 1. ERP (Enterprise Resource Planning) systémy jako SAP, BAAN, Oracle apod. umožňující automatizovat výrobní procesy, finanční toky a řídit lidské zdroje, právě na základě explicitně popsaných procesů. Modelování podnikových procesů se tak stává počáteční fází softwarového procesu, na jehož konci je v podniku či organizaci implementovaný informační systém. 2. WFM (Workflow Management) systémy reprezentující generické softwarové nástroje pro definici, správu, realizaci a vlastní řízení podnikových procesů.
18
Postup návrhu podnikového procesu • Účelem modelování je vytvoření takové abstrakce procesu, která umožňuje pochopení všech jeho aktivit, souvislostí mezi těmito aktivitami a rolemi reprezentovaných schopnostmi lidí a zařízení zapojených do daného procesu. • V současné době lze nalézt celou řadu metod (technik) postavených na různých technologiích, které jsou používány k sestavování modelů podnikových procesů.
19
Obecný postup návrhu podnikového procesu • V podstatě tedy existují tři klasické základní přístupy, které se využívají k modelování procesů, a které vychází ze tří základních typů použité abstrakce: 1. Funkční přístup zaměřený především na funkce, jejich strukturování, vstupy a výstupy. 2. Přístup specifikací chování je zaměřen na řídící aspekt vykonávání procesu cestou stanovení událostí a podmínek, za kterých mohou být jednotlivé aktivity prováděny. 3. Strukturální přístup je zaměřen na statický aspekt procesu. Cílem je postihnout entity a zdroje vystupující v procesu včetně jejich atributů, činností (služeb) a vzájemných vazeb. 20
Využití konkrétních diagramů pro modelování podnikových procesů • Analýza požadavků – používá diagramy případů užití. – scénář je konkrétní instance případu užití, případ užití je zobecnění.
21
1. Diagramy užití (Use Case Diagrams) • Funkční specifikace je v jazyce UML řešena prostřednictvím diagramů případu užítí (Use Case Diagram). • Případ užití specifikuje jeden případ použití vytvářeného informačního systému. • Případ (scénář) užití je pojem, který je v rámci byznys modelování definován následujícím způsobem: • Případ užití je posloupnost akcí, které podnik či organizace realizuje v interakci se specifickými aktéry s cílem vytvořit výsledek požadované hodnoty. • V podstatě je tedy případ užití synonymem pro podnikový proces. 22
Obecný diagram případů užití název systému Restaurace příjem objednávky číšník
objedníní jídla
servírování
potvrzení objednávky
objednání
komunikační relace
hranice systému
servírování jídla usnadnění placení
příprava jídla kuchař
klient placení
účastník / aktor
příjem peněz vrchní
konzumace jídla
placení za jídlo
případ užití (use case)
Diagramy užití • Aktér reprezentuje lidskou bytost, někoho nebo organizaci, co stojí mimo podnikový proces specifikovaný daným případem užití (směr k workflow). • Primárním účelem diagramů případů užití je tak dokumentovat interakce mezi službami, které jsou podnikem či organizací poskytovány a těmi, kterými jsou tyto služby požadovány. • Takto vytvořený model identifikuje, co je vlastně účelem podnikání dané organizace a jaké služby nabízí svému okolí. 24
Diagramy užití (Use Case Diagrams) • Výhodu případů užití: – snadná srozumitelnost, – pokud jsou správně identifikovány případy užití, vývoj jde hladce kupředu.
• Slabá místa případů užití: – správná identifikace případů užití.
• Nároky na případy užití: – správná granularita a tedy úroveň detailu popisu, – kompletnost všech případů užití (strategie číšníka). 25
Diagramy užití • Diagram případů užití používá následujících elementů ke svému sestavení: 1. Případy užití (Use Cases), které identifikují funkce realizované byznys procesy. 2. Aktéry (Actors) popisující externí objekty vstupující do interakce se specifikovanými procesy (klasický přístup).
26
Diagramy případů užití - zhodnocení • Diagramy obsahují aktéry, mezi kterými probíhá podnikový proces. • Mají ohraničenou oblast použití. • RUP navrhuje využívat business use case models. • Jsou výhodné pro zjišťování použití navrhovaného systému, ale nejsou dobré pro zjišťování (posouzení) podnikových procesů, protože vůbec nepopisují informační toky.
27
Diagram toků – Flowchart Vývojový diagram
• Diagramy toků – modelovací technika zavedena v 1940/50 a popularizovaná pro strukturální vývoj programů v 1970 (Pascal) a pro modelování podnikových procesů.
28
Diagram toků – Flow Chart Diagram • Možnosti znázornění
29
Klasický příklad k řešení • Mějme dánu firmu, která po obdržení objednávky nejprve prostřednictvím svého obchodního oddělení rozhodne o tom, zda-li je schopna obdržené zboží dodat. • Pokud ne, proces je ukončen zamítnutím objednávky. • V opačném případě pokračuje proces ověřením, zda-li je zboží k dispozici ve skladu, či je nutné je vyrobit. • K účelu vyrobení je nutné zakoupit materiál, připravit výrobu a nakonec požadované zboží zhotovit ve výrobním úseku firmy. • Následně je expedicí zboží odesláno objednateli, vystavena a zaslána faktura účetním oddělením, které také kontroluje její zaplacení . 30
Realizace zakázky diagram toků (Flow Chart Diagram)
31
Realizace zakázky 2/2 • Semiformální popis zadání Flow chart – diagram toků – vývojový diagram
32
Deklarace uživatelských požadavků • User stories – popis provedený uživatelem. • Záleží na provedení. • Je-li proveden precizně má velkou vypovídací hodnotu a umožňuje efektivní postup. • Příklad user stories:
33
Uživatelské požadavky – user stories • Člověk se může stát členem tenisového klubu Volley zasláním dopisu poštou tenisovému klubu. V dopisu žadatel musí uvést příjmení, jméno, datum narození, pohlaví, telefonní číslo a poštovní adresu (ulice, číslo domu, poštovní kód a místo pobytu). • Karel, tajemník tenisového klubu, vybírá denně poštovní schránku a kontroluje, zda jsou zadané informace o členství kompletní. • Pokud ne, telefonuje odesílateli, aby zkompletoval požadovaná data. 34
Uživatelské požadavky – user stories • Je-li dopis kompletní, Karel přidá příchozímu dopisu číslo a datum, zaznamená dopis do knihy příchozí pošty a archivuje dopis. • Každou středu večer, zanese Karel obdržené dopisy Mirandě na sekretariát tenisového klubu. Karel také sebou bere registr členů.
35
Uživatelské požadavky – user stories • Pokud Miranda rozhodne, že se žadatel stane členem tenisového klubu, orazítkuje dopis žadatele s razítkem „nový člen“ a zapíše datum pod razítko. Toto datum je počátečním datem členství. Miranda poté předá dopis Karlovi, aby přidal nového člena do registru členů. • Registrem je kniha s číslovanými řádky. Každý nový člen je vložen na nový řádek. Číslo řádku je číslem člena, podle kterého je nový člen identifikován v administrativě klubu. 36
Uživatelské požadavky – user stories • Dále Miranda spočítá členský poplatek, který musí nový člen zaplatit pro zbývající část kalendářního roku. • Miranda vyhledá doplatnou částku za členství podle rozhodnutí valné hromady, které má na papíře v zásuvce svého stolu. • Potom požádá Karla, aby zapsal částku do registru členů. • Jestliže Miranda nedovolí, aby se žadatel stal členem klubu (např. protože je žadatel příliš mladý, nebo jestliže byl dosažen maximální počet členů klubu) 37
Uživatelské požadavky – user stories • Karel odešle dopis ve kterém vysvětlí, proč se žadatel nemůže stát členem tenisového klubu. • Pokud jsou zpracovány všechny žádosti, Karel vezme dopisy a registr členů domů a připraví fakturu pro každého nového člena pro platbu prvního členského poplatku.
38
Uživatelské požadavky – user stories • Karel odešle tyto faktury poštou. Poplatky musí být provedeny bankovním převodem. • Jakmile přijde platba, Karel vytiskne členskou kartu na které je uvedeno členské číslo, datum začátku členství, jméno, datum narození a poštovní adresa. • Karta je zaslaná novému členu poštou.
39
Diagram toků – tenisový klub
40
Diagram toků – tenisový klub
41
Diagram toků – tenisový klub
42
2. Flowchart - zhodnocení • Jednoduchý s výraznými schopnostmi zachytit požadavky na budovaný/opravovaný systém. • Relativně přehledný. • Nemá v sobě žádné možnosti pro zavedení abstrakcí, tedy popisuje detailně požadavky uživatele. • Chybí doplnění rolí aktérů – nutno provést explicitně. • Může sloužit jako výchozí bod pro vývoj aplikace.
43
3. Diagramy aktivit – activity diagram • Diagramy aktivit se typicky používají pro popis podnikových procesů. • Jsou schopny jednoznačně oddělit role aktérů – plavební dráhy, swim lines. • Zavádí možnost popisu paralelních činností. • Zachytí logiku případů užití, ale také detailní logiku podnikových pravidel (business rules).
44
Diagramy aktivit • Počáteční uzel – plný kruh, je počátečním bodem diagramu. Není nutný, diagram se ale lépe čte. • Konečný uzel – plný uzel s vnějším kroužkem. Diagram aktivit může mít jeden nebo více konečných uzlů. • Činnost /aktivita – obdélník s oblými vrcholy, který představuje činnosti, které nastanou. Aktivita může být jak fyzická – Inspekce formuláře, tak elektronická – Vytvoření obrazovky pro studenta.
45
Diagramy aktivit • Tok/hrana – šipka v diagramu. • Fork (vidlička rozdělení) – černá tlustá čára s jedník tokem do vidličky a několika toky z vidličky. Označení pro začátek paralelní činnosti. • Join (spojení) – černá tlustá čára s několika vstupujícími toky a jedním vystupujícím tokem. Označení pro konec paralelního zpracování. • Podmínka (strážní -guarded) – text např. [Nesprávný formulář], který definuje kontrolu – podmínku, která musí být true, aby se pokračovalo ve směru uzlu. 46
Diagramy aktivit • Rozhodnutí – kosočtverec, s jedním vstupním tokem a několika výstupními toky. Výstupní tok zahrnuje podmínku. • Merge (spojení) – kosočtverec s několika toky, které vstupují a jedním tokem, který vystupuje. Význam spojení je v tom, že všechny vstupní toky musí vstoupit do kosočtverce, než se vytvoří výstupní tok – synchronizace. • Plavební dráhy, oddíly – rozdělení pro jednotlivé role aktérů. 47
Diagram aktivit • Indikátor podčinnosti (subactivity) – kolečko s křížkem uvnitř označující, že daná činnost je blíže specifikovaná v dalším diagramu.
48
• Diagram aktivit – jednoduchý příklad
počáteční uzel Příjem objednávky
fork/vidlička
Zaslání faktury
Vyplnění objednávky
aktivita
rozhodnutí [prioritní objednávka] strážní podmínka Doručení běhen nici
Obdržení platby
Standardní doručení
merge/spojeni join/spojení
Uzavření objednávky
konečný uzel
49
Diagram aktivit realizace zakázky
50
Diagramy aktivit pro zápis studenta na univerzitu Žadatel
Registrátor
Vyplnění formuláře
Kontrola formuláře
Systém
[správně]
Zobraz obrazovku Vytvoř studenta
[chybný formulář] Vstup informací žadatele
Zápis na univerzitu
[není v seznamu]
Kontrola seznamu žadatelů [je v sesnamu]
Hledání žadatele
[žádný žadatel]
[žadatel není v seznamu] Výběr žadatele ze seznamu
[potenciální žadatelé]
Zobrazení výsledků hledání
Vytvoření stusdenta
Zápis do semináře
51
Zhodnocení standardních přístupů k modelování podnikových procesů • Klasické přístupy nerozlišující mezi konstrukčním a funkčním modelem – problémy při re-designu nebo reengineeringu. • Neberou aktora jako součástí podnikového procesu, protože se soustřeďuje pouze na workflow – automatizované podnikové procesy. • Modelují podnikový proces pouze jako sekvenční činnosti (následují za sebou) – spíše se podobá stromové struktuře. • Problém nalezení správné granularity a kompletnosti případů užití – strategie číšníka to nevyřeší. • Problém přílišné složitosti. 52
Postup návrhu podnikového procesu • Stávající metodologie vycházejí z tzv. „best practice“, pracují pouze s funkčními požadavky a chybí jim teorie a propracovanější metodologie.
53
Závěr • Pojem podnikový procesu a jeho klasické modely. • Flowchart, diagramy aktivit. • Nedostatky klasických metod.
54
