Modelování podnikových procesů s nástrojem Signavio

Rozměr: px
Začít zobrazení ze stránky:

Download "Modelování podnikových procesů s nástrojem Signavio"

Transkript

1 Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod Modelování podnikových procesů s nástrojem Signavio Diplomová práce Autor: Bc. Martin Kohout Informační technologie a management Vedoucí práce: doc. Ing. Alena Buchalcevová, Ph.D. Praha Duben, 2015

2 Prohlášení Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Praze dne Martin Kohout

3 Poděkování Děkuji vedoucí diplomové práce doc. Ing. Aleně Buchalcevové, Ph.D. za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé diplomové práce.

4 Anotace Tématem diplomové práce je stručné seznámení s problematikou procesního modelování a vytvoření metodické příručky pro modelování podnikových procesů v nástroji Signavio Process Editor. Úvodní kapitola teoretické části seznamuje s podnikovým řízením, typy procesů a základními přístupy k modelování podnikových procesů. V kapitole Procesní modelování jsou probrány základy nejpoužívanějšího modelovacího jazyka. Praktická část je zaměřena na vytvoření metodické příručky pro vymodelování vlastního byznys procesu za pomoci tohoto nástroje. V závěru diplomové práce je modelovací nástroj Signavio Process Editor porovnán s dalšími obdobnými nástroji. Klíčová slova: procesní modelování, modelování podnikových procesů, nástroj Signavio Process Editor, byznys proces Annotation The topic of this thesis is a brief introduction to the issue of process modeling and the creation of a methodical guide for business process modeling in the Signavio Process Editor tool. The introductory chapter of the theoretical part introduces business management, process types and basic approaches to business process modeling. The chapter Process modeling discusses the basics of the most widely used modeling language. The practical part focuses on the creation of a methodical guide for modeling one s own business process with the help of this tool. In the conclusion, this thesis compares the Signavio Process Editor modeling tool with other similar tools. Key words: process modeling, business process modeling, Signavio Process Editor tool, business process

5 Obsah 1. Úvod Vymezení tématu Cíle práce Přínos práce Struktura práce Zvolené metody zpracování Úvod do byznys analýzy Vymezení pojmů Proces Procesní řízení Workflow Role Typy procesů Hlavní procesy Podpůrné procesy Řídící procesy Vedlejší procesy Business Process Management (BPM) BPM a jeho přístup k vývoji softwaru Implementace BPM Základní přístupy k modelování byznys procesů Funkční specifikace pomocí IDEF Specifikace procesu pomocí EPC Procesní modelování Jazyk BPML a notace BPMN Jazyk UML Základní stavební bloky Standardní profil jazyka UML pro podnikové procesy Rozšíření UML podle H. Erikssona Diagram aktivit Rozdíl mezi notací BPMN a diagramem aktivit v jazyce UML Jazyk uubml... 27

6 4. Signavio Process Editor Charakteristika nástroje Popis uživatelského rozhraní Explorer Editor Dictionary Portal Simulation Diagram comparison Kvalita modelů Kontrola syntaxe Kontrola dodržení osvědčených postupů při modelování podle notace BPMN Doporučení pro tvorbu modelů Komentáře a názvy diagramů Rozvržení Pojmenování Notace Struktura procesu Praktický příklad vymodelování podnik. procesu v nástroji Signavio Process Editor Zadání procesu Postup návrhu byznys procesu dle zadání Realizace procesu Modelování procesu Kontrola modelu Doplnění nalezených nedostatků Obdobné modelovací nástroje Historický vývoj modelovacích nástrojů Microsoft Visio ARIS Express Sparx Enterprise Architect Power Designer IBM Rational System Architect Adonis BPMN Web Modeler LucidChart... 69

7 7. Porovnání modelovacích nástrojů Metoda hodnocení výběru Určení vah a bodové hodnocení Stanovení vah ke skupinám kritérií a jednotlivým kritériím Porovnání nástrojů pro modelování podnikových procesů Signavio Process Editor Microsoft Visio ARIS Express Sparx Enterprise Architect Power Designer IBM Rational System Architect Adonis BPMN Web Modeler LucidChart Celkové vyhodnocení srovnání nástrojů pro modelování podnikových procesů Závěr Seznam použité literatury Seznam použitých zkratek Seznam použitých obrázků Seznam použitých grafů Seznam použitých tabulek Seznam použitých příloh... 86

8 1. Úvod Řada organizací je v dnešní době pod neustálým tlakem na zvyšování efektivity a jejich fungování. Organizace se zaměřují více na zákazníka a s tím úzce souvisí i procesní řízení. Mezi základní požadavky pro modelování procesů patří podpora nejrozšířenějších metodik pro popisování procesů. Podstatnou částí jsou možnosti zachycení datových elementů procesu, definování vstupů a výstupů každého kroku a specifikování uživatelských rozhraní pro lidské vykonavatele. Mezi významnou výhodu lze zařadit možnost definovat procesy nejen graficky, ale i tabulkově popisem pravidel. Pro řadu uživatelů je to přirozenější a snadnější Vymezení tématu Tato práce měla pro svůj vznik řadu důvodů. Jedním z hlavních důvodů je snaha stručně seznámit čtenáře s problematikou procesního modelování, která je velmi aktuálním tématem, a to zejména z důvodu reengineeringu (zásadního přehodnocení) společností, vylepšování současných procesů a implementací ERP systémů Cíle práce Cílem práce je poskytnutí přehledu přístupů k modelování podnikových procesů, popsání jazyků, metod a nástrojů pro modelování podnikových procesů, a na základě těchto znalostí vytvoření metodické příručky pro modelování podnikových procesů v nástroji Signavio Process Editor, která zároveň bude zahrnovat popis různých doporučení pro tvorbu modelů a popis kontroly kvality modelů Přínos práce Metodická příručka by měla být přínosem nejen pro uživatele, kteří se zajímají o problematiku modelování podnikových procesů, ale i pro pokročilejší uživatele či začínající 1

9 analytiky, kteří pro tvorbu svých modelů chtějí využít moderní modelovací nástroj Signavio Process Editor, ale neví, jak svůj první model vytvořit Struktura práce Úvodní kapitola teoretické části této práce má seznámit čtenáře s procesně řízenou společností, v které se na základě druhu tohoto řízení s úspěchem uplatňují podnikové procesy. Čtenář se tak dozví podrobněji o podnikovém řízení, typech procesů nebo základních přístupech k modelování podnikových procesů. Kapitola Procesní modelování je věnována již konkrétním jazykům a notacím používaných v případě, že modelujeme nějaký podnikový proces. V kapitole jsou probrány základy nejpoužívanějšího modelovacího jazyka a notace. Díky tomu kapitola slouží jako ideální úvod pro jejich praktické zvládnutí. Praktická část je zaměřena na popis uživatelského rozhraní a na popis možností aplikace Signavio Process Editor tak, aby čtenář následně zvládl pomocí této metodické příručky vymodelovat vlastní byznys proces právě za pomoci tohoto nástroje. Závěr práce slouží pro srovnání použitého modelovacího nástroje Signavio s dalšími obdobnými nástroji na základě zvolených konkrétních kritérií Zvolené metody zpracování Při tvorbě této práce bylo využito několika metod používaných pro zpracování textu. Metodou syntézy, tedy metodou spojování dvou nebo více částí různých zdrojů do jednoho celku, je vytvořena teoretická část této práce. S metodou analýzy a návrhu bylo pracováno v části praktické. Analýzy, tedy metody zkoumání, která rozkládá složitější skutečnosti na jednodušší, bylo využito při tvorbě praktického příkladu, kdy bylo třeba zdánlivě složitou úlohu rozložit na jednotlivé jednodušší části. Na základě této analýzy byl následně navržen a vymodelován podnikový proces. Metodou, která se zabývá hodnocením alternativ na základě několika zvolených kritérií, pod názvem multikriteriální analýza, byly porovnány obdobné modelovací nástroje. 2

10 2. Úvod do byznys analýzy V této kapitole jsou probrány základní pojmy (proces, procesní řízení atd.), typy procesů, základy procesního řízení nebo základní přístupy k byznys modelování Vymezení pojmů Smyslem byznys modelování je vytvořit takovou abstrakci 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. [1] V následujících podkapitolách jsou vysvětleny nejzákladnější pojmy Proces Pojem proces má mnoho definic a každá se liší jinou přesností a jiným náhledem na danou problematiku. V každém případě se poznání v oblasti procesů a procesního řízení neustále obohacuje o nové poznatky a díky tomu je nutné definice procesu také pravidelně aktualizovat. Definice procesu dle normy EN ISO 9000:2000 je následující: Proces je soubor vzájemně souvisejících nebo vzájemně působících činností, který přeměňuje vstupy na výstupy. [2] Na internetu i v literatuře lze najít spousty definic, podle Šmídy [3] jsou však tyto definice často neúplné, protože neberou v úvahu fakt, že kromě činností se proces může také skládat z několika subprocesů. Z tohoto důvodu autor uvádí vlastní definici: Proces je organizovaná skupina vzájemně souvisejících činností a/nebo subprocesů, které procházejí jedním nebo více organizačními útvary či jednou (podnikový proces) nebo více spolupracujícími organizacemi (mezipodnikový proces), které spotřebovávají materiální, lidské, finanční a informační vstupy a jejichž výstupem je produkt, který má hodnotu pro externího nebo interního zákazníka. [3] Uvedená definice je dle mého názoru velmi výstižná a pro naši oblast podnikových procesů přesná. Pro úplnost ještě uvádím definici byznys procesu, tak jak ho definoval prof. Ivo Vondrák: Byznys proces je po částech uspořádaná množina procedur a aktivit, které společně 3

11 realizují podnikatelský nebo strategický cíl, obvykle v kontextu organizační struktury definující funkce rolí a jejich vztahy. [1] Procesní řízení K definici slova proces se samozřejmě vážou i různé jiné důležité pojmy jako třeba pojem procesní řízení, které má více výkladů: Procesní řízení (Business Proces Management) je samo o sobě procesem, který zajišťuje neustále zlepšování výkonosti organizace. [4] Další z definic procesního řízení může být tato: Procesní řízení (Business Proces Management) je metoda, systém a standard, který umocňuje realizaci jakékoli existující teorie managementu a který podporuje pohotovější vytváření a osvojení nových teorií do podnikové reality. [5] Jako v případě pojmu proces, tak i v tomto případě přichází Šmída ve své publikaci s vlastní výstižnou definicí pojmu: Procesní řízení (management) představuje systémy, postupy, metody a nástroje trvalého zajištění maximální výkonnosti a neustálého zlepšování podnikových i mezipodnikových procesů, které vycházejí z jasně definované strategie organizace a jejichž cílem je naplnit strategické cíle. [3] Workflow Doslovným překladem pojmu workflow je tok prací. Tento pojem nemá v českém slovníku vhodnou náhradu a tak se používá toto slovo v anglické formě. Prof. Ivo Vondrák uvádí ve své publikaci následující definici: Workflow je automatizovaný byznys proces. Byznys proces a workflow jsou zaměnitelné pojmy, protože jejich význam je totožný. Jediným rozdílem je, že workflow spravuje a řídí k tomu určený software ERP 1 nebo WFM 2 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. [1] 1 Zkratka ERP (Enterprise Resource Planning) je informační systém, který se stará o plánování a řízení firemních zdrojů. 2 Zkratka WFM (Workflow Management) je informační systém sloužící k automatizaci a řízení workflow. 4

12 Role Pojem role je jedním z pojmů, který může mít několik významů. Když opomineme významy, které se nezabývají informatikou, lze pojem role definovat třeba tak, jak ho definuje prof. Vondrák ve své publikaci: Role je soubor vzájemně se doplňujících dovedností. Role jsou přiřazovány k jednotlivým aktivitám s cílem umožnit jejich plnění v rámci vykonání procesu. [1] S touto definicí souhlasím, ačkoliv se mi zdá pro nezasvěceného čtenáře poměrně složitá. Z tohoto důvodu uvádím svoji definici, která může být pro někoho lépe srozumitelná: Role je pojmenované omezení definující rozsah povolených činností, které uživatel smí vykonávat, např. v informačním systému nebo aplikaci. Rolí může být např. vývojář, protože osoba v této roli má omezený rozsah činností zaměřující se pouze na vývoj a zároveň s tím má v informačním systému přístup pouze k dokumentům pro tuto činnost potřebným Typy procesů Jak již bylo uvedeno při definici pojmů, pojem procesní řízení v podstatě znamená soubor procesů, metod a postupů s cílem naplnit strategické cíle společnosti. Výhodou procesního řízení je možnost jednotlivé procesy z tohoto souboru procesů oddělit a díky tomu je i následně popsat, resp. vytvořit a popsat procesní model. Výstupem těchto jednotlivých procesů může být nějaký produkt nebo služba. Každý proces se od toho druhého liší zejména svojí velikostí a rozsahem. Existují procesy, které se uplatňují například pouze v některé části firmy (organizační jednotce) a naopak také existují procesy, které procházejí napříč celou firmou a jsou tedy pro společnost strategicky důležité. Z pohledu rizik těchto procesů je pro společnost rozhodně několikanásobně rizikovější proces procházející celou firmou než proces malého rozsahu, a to zejména z důvodu možného ohrožení chodu firmy napříč několika organizačními jednotkami, které daný proces využívají. Naopak málo rozsáhlý proces, soustředěný pouze v jedné organizační jednotce, ohrozí většinou maximálně právě pouze tuto jednotku. Vzhledem k tomu, že každý proces má nějaký výstup, tak zároveň s tím má i své zákazníky. Tito zákazníci se dělí do svou skupin: na externí zákazníky, tedy zákazníky, kteří proces využívají mimo firmu, na interní zákazníky, tedy zákazníky využívající proces uvnitř firmy. 5

13 Procesy je možné rozdělit do několika skupin, na základě stanovených cílů a skupiny zákazníků, jak se také zmiňuje Pekárková ve své práci [6] Hlavní procesy Hlavní procesy jsou často nazývány jako tzv. core procesy. Tyto procesy vytváří přidanou hodnotu (vytvářejí produkty), za kterou platí externí zákazník. V důsledku toho podporují podnikatelskou činnost a naplňují tak strategické cíle podniku. Hlavní procesy lze ještě dělit na klíčové procesy. Klíčové procesy se odvíjejí od vize, zaměření a velikosti podniku, přičemž středně velký průmyslový podnik může mít například klíčových procesů Podpůrné procesy Podpůrné procesy, jak již mají ve svém názvu, podporují. Jsou to procesy, které poskytují služby pro hlavní procesy. Mezi tyto procesy se například často řadí proces kontroly jakosti, což lze vnímat jako přidanou hodnotu pro zákazníka, kterou sice nevidí, tudíž ji nevnímá, ale je nezbytná pro efektivní řízení podniku Řídící procesy Jedná se o průřezové procesy, které koordinují činnost ostatních procesů. Tyto procesy jsou často spojeny s naplněním strategických cílů podniku. Do řídích procesů patří například operativní plánování, alokace zdrojů či stanovení cílů Vedlejší procesy Vedlejší procesy jsou takové procesy, které nevytvářejí žádnou přidanou hodnotu pro podnik a nejsou pro něj natolik důležité jako procesy hlavní. Vzhledem k nižší důležitosti jsou často vedlejší procesy v podnicích řešeny outsourcingem [7]. Mohou být vykonávány zároveň s hlavními nebo sdílenými procesy a jejich výstupy jsou obvykle určeny pro externího zákazníka. Typickým příkladem takového procesu je například vlastní IT oddělení podniku. 6

14 2.3. Business Process Management (BPM) Business Process Management, v českém překladu procesní řízení, je důležité v každém procesně orientovaném podniku. Jak zmiňuje Šmída [3], základním a zásadním problémem organizací v dnešní době jsou neustálé změny. Organizace se musí naučit v tomto prostředí žít a rychle a efektivně na tyto změny reagovat při vynaložení co nejmenšího úsilí. S tím souvisí i nutnost vytvořit a otestovat velké množství procesů. Aby organizace, v tak vysoce konkurenčním prostředí jaké v dnešní době je, obstály, je nutné skvěle ovládat následující: postupy jak vytvářet nové procesy a znalost jak prakticky procesy vykonávat, znalost vlivů jednotlivých procesů a spolehlivější metody tvorby nových procesů, realizovatelné modely procesů propojené s podnikovou strategií a odrážející podnikatelské činnosti, řízené portfolio podnikových procesů, které reflektují přání zákazníků a které je možno okamžitě změnit, schopnost kombinovat jednotlivé procesy a přizpůsobovat je aktuálním potřebám zákazníků, testování realizace změn. V předchozích bodech musím se Šmídou souhlasit, protože se i v dnešní době, kdy je na trhu tak silná konkurence, je možné setkat s poměrně velkým množstvím podniků, které na procesní problematiku nekladou důraz. Fakt, že na trhu ovšem stále působí, je dle mého názoru dán především tím, že tyto podniky se buď pohybují v oboru, kde není tak silné konkurenční prostředí nebo spoléhají na svoji stabilní zákaznickou základnu. Je to ale jen otázka času, kdy se konkurence rozšíří a přijde s lepším a propracovaným Business Process Managementem. Poté se buď podniky přizpůsobí a zahájí změnu svého BPM nebo zaniknou. Digitální modely procesů mají mnoho společného, kromě informačních technologií, také s podnikáním. Na základě modelů podnikových procesů dochází k administrativním, exekutivním a kontrolním činnostem, které zajišťují, že procesy neustále vyhovují cílům podnikatele a splňují požadavky zákazníka. Pokud nastane případ, že tomu tak není, musí proces disponovat jednou nejdůležitější schopností - měnit se. [3] Tento přístup k vytvoření a implementaci procesů je nazýván tzv. 3. vlnou Business Process Managementu (BPM). Význam 3. vlny spočívá ve schopnosti vytvořit jedinou definici (standardní vyjádření) procesu, v níž mohou být poskytnuty různé úhly pohledu na ten samý 7

15 proces a postaveny různé informační systémy. To prakticky znamená, že různí lidé s různými odbornostmi mohou vidět stejný proces různě a nakládat s ním tak, jak jim to vyhovuje. Všichni přitom pracují s jediným zdrojem. [3] Příkladem této definice BPM může být procesně řízený projekt v podniku. Každý manažer k řízení projektu přistoupí rozdílným způsobem, ačkoliv zadání mají všichni stejné. Dalším příkladem může být proces, na který také lze nahlížet rozdílně. Jeden pracovník nad procesem provádí výkonnostní výpočty a porovnávání, jiný si prohlíží procesní mapu BPM a jeho přístup k vývoji softwaru Význam slov a znaků neboli sémantika modelovacího jazyka Business Process Modeling Language (BPML) vychází z otevřeného standardu, který je dostupný jak lidem, tak i počítačovým systémům. Existují dva rozdílné přístupy [5], kterými obecně lze nahlížet na vývoj softwaru: přístup zaměřený na kód (code centric approach), přístup zaměřený na proces (proces centric approach). První zmíněný, přístup zaměřený na kód, znázorňuje životní cyklus vývoje a skládá se z těchto etap: 1. Modeluj (analytik) 2. Specifikuj (softwarový architekt) 3. Implementuj (vývojář softwaru) 4. Rozmísti (systémový administrátor) Obrázek 1: Životní cyklus vývoje software přístupem zaměřeným na kód, upraveno podle [5] 8

16 Druhý přístup, přístup zaměřený na proces, naopak zobrazuje zásadní průlom 3. vlny BPM a to tu skutečnost, že procesy jsou přímo a okamžitě vykonavatelné a není tedy potřeba vyvíjet žádný software. Tento přístup se právě proto skládá pouze z etap: 1. Modeluj (analytik a vývojář softwaru) 2. Rozmísti (systémový administrátor) 3. Řiď (analytik) Obrázek 2: Projektování procesu pomocí BPMS, upraveno podle [5] BPM tedy nezrychluje vývoj aplikací, ale snižuje jejich potřebu. Základní inovativností BPM je skutečnost, že data, procedury, workflow a distribuovanou komunikaci nyní chápeme jako tzv. jeden typ informací (abstraktní datový typ) podnikový proces. [3] Implementace BPM Zásadní vlastností BPM je snížení vlivu změn na současnou provozní činnost, zatímco staré je odstraňováno a nahrazováno lepším novým. Samotná implementace BPM je bezproblémová. Při implementaci BPM jsou všechny současné aplikace a procesy chráněny. V budoucnu se dají samozřejmě podle aktuálních potřeb změnit nebo nahradit jinými. [3] 2.6. Základní přístupy k modelování byznys procesů Byznys procesy jsou modelovány s cílem vytvořit určitou abstrakci reálného procesu. Během modelování je snaha identifikovat všechny probíhající aktivity v rámci procesu, vztahy mezi těmito aktivitami a také role a zařízení vstupující do procesu. K pochopení procesu nám pomáhají základní jednoduché otázky, které je vhodné si vždy při modelování byznys procesu položit: 9

17 1. Co? tato otázka nám pomůže zodpovědět, co modelovat. Jaké funkce má podnik plnit, proč tomu tak je a jaké jsou vstupy a výstupy těchto funkcí. 2. Jak? určuje, jak těchto funkcí dosáhnout pomocí aktivit a procesů 3. Kým a čím? pokud je již zřejmé, čeho má být dosaženo a jak na to, je nutné si položit otázku, čím těchto cílů dosáhnout a kdo a co zrealizuje jednotlivé aktivity. Na základě těchto znalostí je možné pomocí některého z modelovacích nástrojů proces vizualizovat. Podle prof. Vondráka [1] se k modelování byznys procesů používají tři základní přístupy: 1. Funkční přístup zaměřuje se zejména na funkce, jejich strukturování, vstupy a výstupy 2. Přístup specifikací chování přístup vycházející ze stanovení událostí a podmínek, za kterých mohou být prováděny jednotlivé aktivity 3. Strukturální přístup je zaměřen na entity a zdroje v procesu, jejich atributy, činnosti a vzájemné vazby Funkční specifikace pomocí IDEF Metody (standardy) IDEF (Integration DEFinition) vznikly na základě požadavku amerického vojenského letectva za účelem nalézt vhodný prostředek pro analýzu a komunikaci mezi lidmi, kteří se zaměřovali na zvyšování produktivity výroby. Tyto standardy v současné době pokrývají celou oblast modelování podnikové architektury. Výsledkem veškerého snažení jsou metody IDEF0 až IDEF14, přičemž základem byly následující metody: Metoda IDEF0 za účelem sestavení funkčního modelu, který strukturovaně popisuje funkce modelované doménové oblasti, metoda IDEF1 za účelem sestavení informačního modelu reprezentujícího strukturu a sémantiku informací, metoda IDEF2, resp. metoda IDEF3 za účelem popisu chování (dynamiky) systému. Kromě toho existují další metody jako například metoda IDEF1X sloužící pro modelování dat, IDEF4 pro objektově orientovaný návrh aplikací nebo IDEF5 pro popis ontologií. Tato diplomová práce se zabývá metodou IDEF0, jako typického reprezentanta systematického přístupu k analýze funkcí a metodou IDEF3, která je určena přímo pro modelování procesů. [1] [8] 10

18 Metoda IDEF0 vznikla z graficky orientovaného jazyka SADT (Structured Analysis and Design Technique) a poskytuje přesně definovaný modelovací jazyk, tedy jazyk s jasně danou syntaxí a sémantikou, který umožňuje vytvořit strukturovanou grafickou reprezentaci systému nebo organizace. Slouží pro modelování rozhodování, akcí a činností v podniku nebo informačním systému. Jedná se tedy o model, který se skládá z hierarchicky uspořádané sady diagramů a textů a z přesně definovaného systému vzájemných odkazů popisujícími funkce organizace či podniku. Mezi základní syntaktické prvky patří: Funkce, které popisují transformaci vstupu na požadovaný výstup, vstupy, tedy data nebo objekty, které jsou pomocí funkce transformovány na požadovaný výstup, výstupy, což jsou data nebo objekty, které jsou produkovány funkcí, řízení je definováno pomocí pravidel potřebnými k získání požadovaného výstupu, mechanismus, který definuje prostředky nutné k realizaci požadované funkce. Každá funkce vyžaduje tzv. ICOM, tedy vstup (input), výstup (output), řízení (control) a mechanismus (mechanism). Kromě toho má číselné označení (tzv. ID) a také označení diagramu, ve kterém je následně dále rozpracována do svých podfunkcí. Díky tomu je možné vytvořit hierarchii diagramů, při čemž jednotlivé funkce jsou skládány po diagonále od shora dolů. Diagram by měl být složen minimálně ze tří a maximálně ze šesti funkcí. [1] Obrázek 3: Základní stavební blok metody IDEF0, převzato z [9] Metoda IDEF3 byla vytvořena pro popis chování systému. Vzhledem k tomu, že zajišťuje sběr informací o procesech podniku, poskytuje i způsob, jak tyto informace reprezentovat a komunikovat. K tomuto účelu definuje grafický jazyk. 11

19 Základním elementem, z kterého metoda vychází je scénář. Scénář zachycuje opakující se situaci nebo množinu situací, z které vyplývá proces. Metoda dále rozlišuje dva rozdílné přístupy: přístup zaměřený na procesy přístup zaměřený na objekty V rámci přístupu zaměřeného na procesy metoda definuje jako základní stavební bloky modelovacího jazyka: UOB (Unit of Behavior), vazby a uzly. Jak takový diagram, zachycující proces procesně zaměřeným přístupem, může podle metody IDEF3 vypadat, ukazuje následující obrázek. Obrázek 4: IDEF3 Procesně zaměřený diagram, převzato z [10] V druhém případě, tedy přístupu zaměřeném na objekty, patří mezi základní stavební bloky modelovacího jazyka tyto části: objekty a jejich stavy, přeměny objektů, reference a podmínky. Diagram modelovaný přístupem zaměřeným na objekty metodou IDEF3 je ukázán na obrázku. Obrázek 5: IDEF3 Objektově zaměřený diagram, převzato z [10] 12

20 Specifikace procesu pomocí EPC Na rozdíl od metody IDEF, která specifikuje funkce, které by proces měl plnit, metoda EPC definuje, jak jsou tyto funkce realizovány pomocí aktivit, ale hlavně, jak jsou tyto aktivity z časového pohledu realizovány, zda jako posloupnost nebo paralelně. Mezi nejrozšířenější takovéto metody, jak uvádí i prof. Vondrák [1], patří právě metoda EPC (Event-driven Process Chain). Důvodů, proč je nejrozšířenější, je mnoho, ale ten nejdůležitější a nejvýznamnější je ten, že se stala součástí takových rozsáhlých a známých systémů jako je SAP nebo ARIS. Její hlavní podstatou je řetězení událostí a aktivit do posloupnosti, která realizuje požadovaný cíl. Každý proces je omezen dvěma událostmi, které definují jasně začátek a konec procesu. Proces má vstupní podmínku, tzv. precondition a výstupní podmínku, tzv. postcondition. Výstupní podmínka definuje ukončení aktivity a mohou na ní navazovat další aktivity. Primárním cílem autorů grafického jazyka, který je v EPC diagramech používán, bylo efektivně a srozumitelně popsat proces tak, aby mu byl schopen porozumět každý ze široké komunity zabývající se touto problematikou. K tomu EPC diagram využívá následující elementy [1]: Aktivity patří mezi základní stavební bloky a určují, co má být v procesu vykonáno. Události popisují situaci před a/nebo po vykonání aktivity. Událost může být výstupní podmínkou jedné aktivity a zároveň může být vstupní podmínkou události jiné. Logické spojky, které se v EPC diagramech užívají ke spojování různých aktivit a událostí. Využívány jsou tři typy těchto logických spojek a to: AND (a současně), OR (nebo), XOR (vzájemně vylučující se nebo). Pomocí těchto logických spojek je možné tok činností rozdělit, v tom případě má logická spojka jeden vstup a minimálně dva výstupy nebo je možné tok činností sloučit. Při sloučení má spojka minimálně dva vstupy a právě jeden výstup. Z toho lze odvodit několik závěrů, jak se používají v EPC diagramech tyto logické spojky. V případě potřeby vytvoření dvou souběžných toků činností se použije logická spojka AND-split. V opačném případě, tedy v případě, kdy je potřeba naopak synchronizovaně sloučit dva souběžné toky (tzn., že proces může pokračovat až v případě, kdy se oba toky dostanou do bodu sloučení), se použije spojka AND-join. 13

21 Pokud je potřeba tok rozpojit do jedné z možných cest, použije se XOR-split a XOR-join tyto dva vzájemně se vylučující toky zase spojí nazpět. Logická spojka OR-split a OR-join rozpojuje, resp. spojuje tok řízení v proměnlivém počtu. To znamená, že tedy může být vybraná jedna, druhá nebo taky obě cesty. Obrázek 6: Základní stavební bloky EPC diagramu 14

22 3. Procesní modelování Kapitola seznamuje čtenáře s notacemi a jazyky používanými v oblasti modelování byznys procesů, jako je notace BPMN či jazyky BPML nebo UML. U každé notace či jazyka jsou popsány jeho vlastnosti a základní stavební bloky. Notace BPMN slouží ke grafické specifikaci podnikových procesů, zatímco standardy EPC a IDEF, popsané v minulé kapitole, definují obecný popis sémantiky a strukturu procesu, tedy jak jsou data, procesní kroky, produkty řazeny a jaké jsou mezi nimi vztahy. Modelování byznys procesů se vyznačuje velkým počtem používaných notací. Použití konkrétní notace je dáno zejména oblastí a konvencemi byznysu, ve kterém je daný proces modelován, dále pak použitým nástrojem pro modelování, neboť každý nástroj podporuje rozdílné notace, a také samozřejmě dodavatelem daného softwaru. Notace v oblasti byznys modelování nejsou podrobeny tak přísné standardizaci jako například v oblasti programové (UML). Výhodou této skutečnosti je fakt, že při modelování notace příliš nesvazují konvencemi, což svádí k nestandardizovaným řešením, na druhou stranu je nutná striktní konvence, aby byla zachována použitelnost a smysl procesního modelování Jazyk BPML a notace BPMN Jazyk BPML (Business Process Modeling Language) je standardní součástí BPM a doplňkem pro BPMN (Business Process Modeling Notation). Vznikl v roce Jedná se o univerzální procesní jazyk, díky kterému mohou spolu po celém světě jakékoliv organizace komunikovat a spolupracovat. Je založený na XML schématu, a tak ve spolupráci se syntaxí 3 pro vyjádření a managementem podnikatelských procesů vytváří procesy požadovaný abstraktní model. Vlastnosti procesního modelovacího jazyka se dají shrnout do několika bodů: je otevřený, poskytuje slovník za účelem výměny definic procesů napříč systémy a modelovacími nástroji, 3 Syntaxe označuje pravidla pro zápis formálního jazyka. 15

23 proces je v BPML jednoznačně definován a stejně tak i realizován, definuje abstraktní model a základy pro vyjádření jakéhokoliv procesu, prostřednictvím XML schémat definuje procesní data. Vzhledem k tomu, že se jedná o otevřený jazyk, tak díky této vlastnosti umožňuje vznik nejrůznějším aplikacím pro procesní řízení. Jazyk BPML je natolik univerzální, že sám o sobě umožňuje integrovat rozhraní mezi procesy, které vzniknou díky existenci dalších různých procesních univerzálních jazyků. Pomocí BPML lze budovat jak systémy procesního managementu, tak modelovat podnikové procesy. BPML má i svou grafickou notaci, která je tvořena pomocí jednoduchých značek geometrických tvarů, které vytváří spojením procesní toky. [3] Notace BPMN (Business Process Modeling Notation) je otevřený a nejrozšířenější standard pro modelování byznys procesů, podporovaný většinou společností, zabývající se tvorbou modelovacích nástrojů. V podstatě lze notaci také chápat jako konkurenční řešení modelování byznys procesů v jazyce UML, v kterém se tvůrci s touto problematikou těžko vyrovnávali. Proces podle notace BPMN vždy začíná startovací událostí a modeluje se vždy zleva doprava. Po startovací události následuje různě dlouhá sekvence činností, která je ukončena koncovým stavem procesu. Notace BPMN rozlišuje: různé typy událostí a interních stavů (triggery), činnosti, brány, různé typy šipek pro rozlišení normálního a podmíněného toku nebo toku zprávy. [11] Události Jako událost je v BPMN chápáno vše, co se v procesu stane. Z toho vyplývá, že událostí může být začátek nebo konec činnosti, přijetí zprávy nebo například změna stavu objektu. Rozlišujeme tři základní typy událostí: počáteční, koncová, mezikrok. 16

24 Počáteční událostí začíná každý proces. Může jí být například zpráva, pravidlo nebo čas. BPML všechny tyto možné počáteční události umožnuje znázornit speciální grafickou značkou. Koncovou událostí je událost, kterou celý proces končí. Stejně tak, jako u počáteční události, tak i u koncové, notace BPMN rozlišuje více možností ukončení. Kromě klasického ukončení bez další akce, také zprávou nebo chybou. BPMN opět nabízí pro každou koncovou událost i vlastní grafickou značku. Mezikrok během procesu znázorňuje důležitou událost, kterou může být například časová prodleva nebo zpráva. Opět je možné znázornit samotnými grafickými symboly. [8] Obrázek 7: Druhy uzlů v BPMN Činnosti Činnost je samostatná aktivita vykonávaná v rámci procesu. Činnosti lze dělit na atomické či složené. Kromě toho BPMN rozeznává ještě další rozdělení na: procesy, subprocesy, úlohy. Procesem je složená činnost vykonávající nějakou práci. Jednotlivé procesy umožňují hierarchické uspořádání. To znamená, že proces se může skládat z jednotlivých subprocesů (podprocesů) a tyto subprocesy se mohou skládat z dalších subprocesů. Proces je v BPMN zobrazován vždy v samostatném bazénu. Subprocesem se rozumí složená činnost, která může být součástí nějakého procesu. Zároveň každý subproces se může skládat z dalších subprocesů. Subproces je graficky zobrazen jako samostatný symbol odkazující na nadřazený proces. Úlohou je myšlena samostatná činnost, z které se skládají jednotlivé procesy a subprocesy. V BPMN je úloha znázorněna značkou zaobleného obdélníku. [8] 17

25 Brány Bránou se rozumí místo v procesu, díky kterému dochází k rozvětvení nebo sloučení toku v procesu, případně volbě správné cesty toku. BPMN umožňuje použít několik primitivních logických bran, jako jsou: OR, XOR nebo AND. V případě potřeby netriviální podmínky lze použít tzv. komplexní bránu nebo kombinaci větvení primitivních logických bran. [8] Obrázek 8: Druhy bran v BPMN Toky Tak jako v notaci BPMN je rozlišováno několik typů událostí nebo bran, tak i u toků jsou rozlišovány následující typy: Obyčejný vztah následnosti zdrojového a cílového objektu znázorňuje obyčejný sekvenční tok. Potřebu splnění nějaké podmínky před pokračováním procesu znázorňuje podmínkový sekvenční tok. Pro specifikaci toku, který bude platit v případě nesplnění podmínky ani pro jeden vycházející objekt z brány XOR, lze použít defaultní sekvenční tok. Přenos zprávy mezi dvěma procesy, tzn. bazény, umožňuje tok zpráv, který je v BPMN znázorněn přerušovanou rovnou čarou se šipkou. V případě potřeby připojení nějaké informace či objektu k entitě procesu lze využít v grafickém znázornění notace tečkovanou čáru bez šipky nebo se šipkou. Tento typ propojení se nazývá asociace. [8] Obrázek 9: Druhy toků v BPMN 18

26 Vzhledem k tomu, že je notace používána pro zobrazení toku dat a sladění toku procesu mezi jednotlivými účastníky procesu, využívá se s úspěchem přístup plaveckých drah. V BPMN se tento přístup využívá rozlišený na: bazén (pool) účastník procesu, dráha (lane) pro skupinu souvisejících činností. Notace BPMN je vhodná zejména pro modelování technických procesů a také procesů, u kterých se předpokládá vysoká míra automatizace. [11] 3.2. Jazyk UML Zkratka UML (Unified Modeling Language) v překladu znamená unifikovaný modelovací jazyk. UML je obecně univerzální jazyk pro vizuální modelování systémů. Další zjednodušenou definicí jazyka UML může být tato: Sjednocený modelovací jazyk (UML) je druh grafické notace podporovaný nezávislým meta-modelem, který umožňuje popisovat a navrhovat softwarové systémy, konkrétně systémy budované využitím objektově orientované metodiky. [12] Samozřejmě definic je mnohem více, protože každý si pod pojmem UML představí úplně něco jiného. K doplnění uvádím také vlastní definici jazyka UML: Jazyk UML je vizuální univerzální modelovací jazyk, využívaný pro návrh softwaru z pohledu statického i dynamického. Jazyk UML implementují všechny CASE nástroje, které se bez něj neobejdou. Všechny diagramy, které jsou vytvořeny v jazyce UML jsou pro lidi srozumitelné a snadno interpretovatelné právě CASE 4 nástroji [13]. Také je důležité zmínit, že UML není metodika, ale jazyk, a ani žádnou metodiku neposkytuje. Rozšířenou metodikou je například metodika UP neboli Unified Process, která nám říká, jaké pracovníky je potřeba mít, jaké činnosti se musí vykonat a jaké produkty vyrobit. [14] Jazyk UML se vyznačuje několika vlastnostmi: 1. UML poskytuje syntaxi pro modelování po celou dobu životního cyklu vývoje softwaru 2. Jazyk UML byl vytvořen jako vizuální jazyk pro modelování čehokoliv 4 Zkratka CASE (Computer Aided Software Engineering) v překladu v podstatě znamená vývoj software s využitím počítačové podpory. 19

27 3. Jazyk UML je nezávislý na programovacím jazyce a platformě 4. UML podporuje kromě nejrozšířenější metodiky UP a jeho variant i další metodiky podpory tvorby softwarového vybavení 5. Pro zajištění konzistence a vnitřní jednoty využívá malé množiny pojmů [14] Modely vytvořené ve vizuálním jazyce UML obsahují: statickou strukturu - tj. např. jaké typy objektů jsou pro modelování důležité a jak spolu tyto objekty souvisí, dynamické chování tj. životní cyklus objektů a způsob jejich vzájemné spolupráce. [14] Základní stavební bloky Jazyk UML je složen z následujících základních stavebních bloků: předmětů prvky modelu vztahů provázanost mezi předměty diagramů pohledy na modely UML, kolekce předmětů Předměty jsou děleny: na podstatná jména, která se používají jako označení tříd, rozhraní, případy užití a další, na slovesa, která popisují chování, na balíčky, které seskupují související prvky modelu, na anotace, které je možné připojit k modelu a které mají zachytit informaci Relace na modelu zobrazuje, jaký je vztah mezi dvěma předměty. Existuje několik typů relací: závislost asociace agregace kompozice ochranná nádoba zobecnění realizace 20

28 Diagramem je chápán pohled na model. Model tvoří předmět nebo jakákoliv relace přidána do nově vznikajícího modelu. Důležitou informací ovšem je, že diagram není model, neboť předměty a relace lze z diagramu odstranit, ale v modelu mohou stále existovat. [14] V UML existuje celkem čtrnáct různých typů diagramů. Diagramy můžeme rozdělit do dvou kategorií: statický model diagramy, které modelují statickou strukturu systému dynamický model digramy, které modelují dynamickou strukturu systému Statický model má za úkol zachycovat předměty a relace mezi nimi. Naopak dynamický model má za úkol zachycovat vzájemné chování předmětů, aby bylo dosaženo požadovaného chování softwarového systému. [14] Mezi diagramy statického modelu řadíme: diagram tříd diagram komponent diagram nasazení diagram vnitřní struktury objektový diagram diagram balíčků Mezi diagramy dynamického modelu řadíme: diagram aktivit diagram případu užití diagram stavového automatu diagram interakce Diagram interakce můžeme dále rozdělit na další diagramy: diagram posloupnosti (sekvenční diagram) diagram komunikace stručný diagram interakce diagram časování 21

29 Standardní profil jazyka UML pro podnikové procesy Jazyk UML se prezentuje jako univerzální modelovací jazyk. Z tohoto důvodu je možné jazyk využít pro modelování podnikových procesů a to díky rozšíření - profilu, v tomto případě standardnímu profilu, který mu byl dán již v době vzniku samotného jazyka. Tento profil zavádí nové významy pro následující diagramy: diagram případu užití (Use Case Diagram) diagram tříd (Class Diagram) Diagram případu užití, který je v jazyce UML definován jako diagram zachycující funkční požadavky a aktéry, kteří interagují se systémem, má v tomto profilu význam odlišný. Ve významu standardního profilu jazyka UML lze diagram případu užití definovat jako diagram popisující interakci mezi podnikovým procesem a aktérem. V diagramu s tímto významem je proces zobrazován jako ovál, který komunikuje s okolím (aktéry). Aktér může být představován jako účastník procesu nebo jako externí účastník, který s procesem nějakým způsobem pracuje. Diagram tříd, základní diagram UML, popisuje základní třídy objektů a vztahy mezi nimi. V tomto profilu je definován jako diagram popisující vnitřní strukturu organizace. Objekty v diagramu znázorňují jednotlivé entity organizace. Asociace, kromě obecného významu, rozlišuje své dva základní typy: obecnou komunikaci (stereotyp Communicate), upozorňování na specifické události (stereotyp Subscribe). Organizační struktura je popsána pomocí organizačních a pracovních jednotek jako stereotypy OrganizationUnit a WorkUnit. [8] Rozšíření UML podle H. Erikssona Rozšíření podle H. Erikssona patří k nejpoužívanějšímu profilu jazyka UML. Profil je určen pro modelování podnikových procesů a je založen na čtyřech základních pohledech: 1. Strategický pohled popisuje hlavní problémy, které mají být procesně řešeny 2. Procesní pohled popisuje vzájemné vztahy mezi procesy 3. Strukturní pohled zahrnuje zdroje organizace (organizační jednotky, produkty, dokumenty, ) 22

30 4. Chování organizace popisuje vnitřní chování a vztahy mezi zdroji a procesy Erikssonovo rozšíření slouží k plnohodnotnému modelování podnikových procesů. Rozšíření definuje celou sadu diagramů, mezi kterou patří i diagram procesů, který je rozšířením diagramu aktivit a tvoří tak jádro celé soustavy. Hlavním rozdílem mezi diagramem aktivit a diagramem procesů je pouze v záměně pojmu Činnost za pojem Proces a definici sady objektů, které přímo souvisí s procesem. Do této sady patří cíle, vstupy, výstupy, podpůrné a řídící objekty. [8] Pro krátké seznámení s rozšířením jazyka UML podle H. Erikssona by měly být předešlé informace dostačující. Vzhledem k tomu, že jazyk UML je používán pro modelování podnikových procesů, kromě diagramu případů a tříd, také diagramu aktivit, je probrán detailněji právě poslední zmíněný Diagram aktivit Diagram aktivit je jedním z diagramů, který je řazen mezi dynamické, protože popisuje vzájemné chování předmětů. S výhodou se využívá pro zobrazování pracovních postupů nebo nejrůznějších byznys procesů či procedurální logiky systému. V diagramu lze využívat nejrůznějších komponent jako počátečního či koncového uzlu, uzlu rozvětvení, uzlu sloučení, uzlu rozhodnutí nebo lze znázorňovat stavy objektů. Diagram lze kreslit v několika variantách a to v tzv. plaveckých drahách nebo zónách odpovědnosti. Počáteční a koncový uzel Začátek aktivity je definován pomocí počátečního uzlu. Aktivita může mít více počátečních uzlů, v tom případě je aktivita spuštěna paralelně ve všech počátečních uzlech, kde je dále paralelně zpracovávána. Počátečním uzlem, kterým je aktivita spuštěna, je přijetí události (např. časové) či parametr aktivity. Časová událost aktivitu spustí například v případě, že nastane předem definovaný konkrétní čas nebo dojde k vypršení definovaného časového limitu. Typickým příkladem v prvním případě může být spuštění automatické zálohy systému o půlnoci nebo prodleva mezi otevřením a zavřením dveří výtahu v druhém případě. Aktivita může mít kromě více počátečních uzlů také více koncových uzlů. V případě dosažení prvního koncového uzlu aktivity jsou ukončeny všechny cesty v rámci aktivity a tím pádem je také ukončena celá aktivita. V případě více cest je možné použít koncový uzel jedné cesty, kdy při jeho dosažení je ukončena pouze tato cesta a ostatní pokračují v běhu dál. [14] 23

31 Obrázek 10: Počáteční a koncový uzel diagramu v UML Uzel rozvětvení Pokud je potřeba využít souběžné cesty, tedy paralelního běhu aktivit, UML nám umožňuje využít uzel rozvětvení. V případě, že se token dotkne vstupní hrany, je okamžitě duplikován do všech paralelních cest. To znamená, že příchozí tok je rozdělen do několika souběžných výstupních toků. V každé takové cestě je možné využít například uzel rozhodnutí, který na základě podmínky umožní tokenu projít výstupní hranou pouze v případě splnění podmínky. [14] Obrázek 11: Uzel rozvětvení v UML Příkladem může být návrh obyčejného bankomatu. Po potvrzení transakce se běh programu, který obsluhuje bankomat, rozvětví a využije souběžných cest pro vydání hotovosti a zároveň pro tisk stvrzenky. Uzel sloučení Uzel sloučení je prostým opakem uzle rozvětvení. Uzel má několik vstupních hran, ale jen jednu hranu výstupní. Při dosažení výstupní hrany tokeny je proveden logický součin a tím i synchronizace tokenu opět pouze do jediného toku. 24

32 Obrázek 12: Uzel sloučení v UML Jako příklad je uvedeno využití bankomatu. Po vydání hotovosti a výtisku stvrzenky, kdy tyto činnosti proběhnou současně, dojde k opětovnému sloučení toku a bankomat se s námi textovou zprávou rozloučí a běh programu se ukončí. [14] Uzel rozhodnutí Uzel rozhodnutí je v podstatě podmínkový uzel. Má několik výstupních hran a jednu hranu vstupní, stejně jako uzel rozvětvení. Rozdíl mezi těmito obdobnými uzly je takový, že uzel rozhodnutí má všechny výstupní hrany chráněny podmínkami. Token, který se dostane na vstupní hranu, může v daný okamžik splňovat maximálně jednu podmínku. Z toho vyplývá, že jednotlivé podmínky se musí vzájemně vylučovat. Nevýlučnost podmínek UML 2 zakazuje a definuje chování uzlu jako formálně nedefinované. Situaci, kdy nebude splněna ani jedna podmínka, lze ošetřit klíčovým slovem jinak. To znamená, že pokud podmínka rozhodovacího uzlu není splněna, tedy není pravdivá, token využije právě této alternativní cesty. [14] Obrázek 13: Uzel rozhodnutí v UML Jako příklad rozhodovacího uzlu je možné na příkladu bankomatu uvést situaci, kdy je uživatel postaven před volbu, zda si z bankomatu vybere hotovost nebo si chce zobrazit zůstatek na 25

33 účtu. V tomto případě jsou uplatněny dvě podmínky, které se vzájemně vylučují. Na otázku: Chcete si vybrat z bankomatu?, odpovídají, buď Ano, nebo Ne. Stavy objektů Každý objektový uzel může být v diagramu aktivit zobrazen v nějakém stavu. Pokud je v diagramu aktivit pracováno s nějakým objektem, je možné zobrazit také jeho stav v dané situaci. Tento stav se může samozřejmě po vykonání určité činnosti změnit. Pokud je ovšem potřeba pouze zachytit stav objektu, doporučuji raději využít diagram k tomu přímo určený, stavový diagram. [14] Obrázek 14:Stavy objektů v UML 3.3. Rozdíl mezi notací BPMN a diagramem aktivit v jazyce UML U diagramu notace BPMN a diagramu aktivit vytvořeného pomocí jazyka UML je dosti pravděpodobné, že v obou diagramech je jistá podobnost v grafickém znázornění. Kromě této lze nalézt ještě další podobnosti. Jak u notace BPMN, tak u jazyka UML se jedná o otevřené standardy, které jsou udržovány skupinou OMG. V obou případech se také jedná o standardizované grafické zápisy, kdy notace BPMN je primárně určena pro modelování diagramů znázorňující byznys procesy a jazyk UML definuje 14 typů diagramů, kde pro modelování byznys procesů je vhodný Diagram aktivit. Jedním z hlavních rozdílů je ale fakt, že jazyk UML je jazyk objektově orientovaný, zatímco BPMN preferuje procesně orientovaný přístup, který je pro modelování byznys procesů vhodnější. Kromě těchto obecných podobností lze také porovnat podobnosti notace BPMN a diagramu aktivit jazyka UML. Přehled základních rozdílů najdete v tabulce. [15] 26

34 Rozdíl UML (diagram aktivit) BPMN (byznys proces) Zahájení procesu Název začátku a konce procesu Akční prvek Prvek definující činnost Rozhodnutí, sloučení Značka pro rozhodnutí směru toku na základě podmínky, sloučení a rozdělení toku Paralelní běh Rozdělení toku na více paralelních nebo sloučení více paralelních toků do jednoho Počáteční uzel (Initial Node) Akce (Action): atomická, volání chování, operace, zaslání signálu, atd. Stejná značka pro vše - Rozhodnutí (Decision) Uzel rozvětvení/sloučení (fork/join) Zahájení události (Start Event) Aktivita (Activity) se dělí na: o subproces složená aktivita dělící se dále na různé BPMN elementy o úkol (task) atomická, dále nedělitelná aktivita (např. podepsání smlouvy) Brána (Gateway) - AND, OR, XOR, atd. Brána (Gateway) Tabulka 1: Základní rozdíly modelování procesů v UML a BPMN 3.4. Jazyk uubml Jazyk uubml (Unicorn Unified Business Modelling Language) je modelovací jazyk vyvinutý společností Unicorn, který ve své podstatě vychází převážně z modelovacího jazyka UML. Jazyk je navržen tak, aby schéma vytvořené pomocí něj, dokázal pochopit každý. Schémata se pomocí tohoto jazyka vytvářejí v současné době pouze pomocí nástroje Microsoft Visio. 27

35 uubml se vyznačuje několika myšlenkami [16]: Unicorn Unified Business Modeling Language (UUBML) je nástroj pro vizuální modelování a komunikaci, pomocí jazyka uubml lze popsat různé objekty, situace, jejich vztahy a souvislosti, uubml je nástroj vhodný pro komunikaci v různých odvětvích (nejen v IT), jazyk je jednoduchý a atraktivní z několika důvodů: o nakreslená schémata jsou intuitivní, o pro kreslení nejsou potřebné žádné specifické znalosti, o díky grafickým ikonám schémata dobře vypadají, schémata lze v případě potřeby standardizovat. Po doplnění data konání školení a odeslání formuláře dojde k automatickému nadelegování aktivity držiteli kontraktu osoby hlásící se na školení. Executives 1.2 Přihlásit ke školení Nominační požadavek Schválit účast HR Specialist Client Representative BUC Přihlásit ke školení provádí přiřazení nominace ke konkrétnímu termínu školení. Změna stavu požadavku se promítne i do přehledů na vigxxx portálu, HR portálu a v evidenci požadavků. Date of training Nominační požadavek Při přihlášení je nutné doplnit datum konání školení. Volitelně je možné doplnit odkaz na přihlášku Povinně je nutné doplnit sponzora Po odeslání formuláře je účastník přesunut z DTT nominací do DTT přihlášených účastníků. Nominační požadavek Požadavek je přesunut do historie zrušených nominací. Obrázek 15: Ukázka procesu vymodelovaného v jazyce uubml 28

36 4. Signavio Process Editor Kapitola seznamuje s nástrojem Signavio Process Editor, který je používán v následujících částech diplomové práce. Jsou zde popsány jeho základní vlastnosti, funkce a uživatelské rozhraní nástroje. Vzhledem k tomu, že v rámci studentské licence je zdarma poskytována pouze webová verze nástroje, je v následujících kapitolách popisována pouze tato verze Charakteristika nástroje Signavio Process Editor [17] je moderní profesionální nástroj pro modelování podnikových procesů. Jeho vznik se datuje k roku 2009, kdy v Německu byla založena společnost vyvíjející tento produkt. Později, v roce 2012, byla tato společnost zapsána i v USA. Před samotným nástrojem Signavio jeho zakladatelé vyvinuli světově první webový modelář pro Business Process Modeling Notation (BPMN). Nástroj byl šířen pod volně šiřitelnou licencí a byl v podstatě podkladovým materiálem pro pozdější vznik nástroje s názvem Signavio Process Editor. Po samotném vzniku Signavia byl vývoj předchozího nástroje zastaven, protože se jednalo o již zastaralý produkt. Nástroj je dostupný ve dvou formách provozu cloud [18] a on-premise [19]. Uživatel si může určit, zda chce nástroj využívat pomocí webového rozhraní nebo zda zvolí lokální instalaci na serveru, kde ji může spravovat např. firemní IT oddělení. Instalace na lokální počítače uživatelů není v tomto případě nutná. Signavio Process Editor se oproti dalším nástrojů, které jsou v tomto textu popisovány, zaměřuje především na modelování podnikových procesů. Proto se v této oblasti řadí mezi to nejlepší, co lze z webových modelářů použít. Díky webovému řešení uživatel nemusí řešit problémy s uložením dokumentů, protože dokumenty jsou automaticky ukládány přímo na vlastní servery poskytovatele nástroje. Další nespornou výhodou je dostupnost dokumentů a nástroje kdykoliv, kdekoliv a na libovolném zařízení s jakoukoliv platformou, ať už se jedná o Windows, Linux nebo Mac, což je vlastnost výhodná zejména například pro manažery, kteří často cestují a díky tomuto řešení mají vždy přístup k poslední verzi dokumentu. Jediné, co je potřeba, je funkční připojení k internetu a webový prohlížeč. 29

37 Mezi jeho klíčové vlastnosti lze zařadit: modelování procesů pomocí grafického editoru a možnost editace pomocí tabulkově orientovaného rozhraní, simulaci procesů pro vyhodnocení kritických částí procesů, správu verzí nebo možnost opětovného využití objektů, sdílení digramů, publikování procesní dokumentace. V oblasti modelování podnikových procesů nástroj poskytuje plnou podporu a dodržování poslední verze BPMN a to ve verzi 2.0. Kromě toho poskytuje například export modelů do XML, podrobný reporting nebo export dokumentace do formátů PDF, tak i do formátu textového procesoru Microsoft Word. Proces validace modelů zajišťuje, že každý diagram je vytvořen přesně v souladu s definovanými normami bez ohledu na to, kdo daný model vytvoří. Odborníky může zaujmout možnost otestování a porovnání jednotlivých modelů pro optimalizaci návrhu workflow. Za zajímavou funkci lze považovat možnost simulace námi namodelovaného podnikového procesu. Výsledkem takovéto simulace je soubor grafů, který zachycuje simulaci podle uložených dat v jednotlivých elementech procesu. Jednotlivé grafy jsou seskupeny do dokumentu. Produkt byl několikrát oceněn, jedním z ocenění bylo v roce 2011 ocenění od německého spolkového ministerstva hospodářství a technologií v kategorii ICT 5 startupu roku. Tentýž rok Signavio bylo vybráno jako jeden z prvních účastníků programu "German Silicon Valley Accelerator". Signavio udržuje silné vazby s akademickou BPM komunitou a kvůli tomu také sponzoruje řadu akademických konferencí. Spolu s partnery společnost Signavio na konci roku 2009 spustila činnost BPM Academic Initiative, přičemž tato iniciativa má za úkol podporovat akademické výzkumy v oblasti BPM. Na základě této iniciativy Signavio poskytuje nástroj Signavio Process Editor v akademické komunitní edici, kdy je tento webový nástroj zdarma dostupný pro výukové účely jak studentům, tak učitelům. 5 Zkratka ICT označuje informační a komunikační technologie. 30

38 4.2. Popis uživatelského rozhraní Signavio Process Editor je nástroj s moderními grafickými a webovými prvky. Nástroj disponuje klasickým, většinou dvousloupcovým, případně třísloupcovým designem. Myslím si, že pro modelovací nástroj je to vůbec nejvhodnější a nejpraktičtější rozložení ovládacích prvků, které zajišťuje dostatečně velký pracovní prostor. Nástroj se skládá z několika částí (nástrojů a komponent), které zajišťují komplexnost celého nástroje. Mezi základní dvě patří: 1. Explorer jednoduchý správce souborů uložených v cloudovém prostředí nástroje, kde lze nalézt všechny vytvořené a sdílené soubory vytvořené tímto souborem (tzv. Shared documents) 2. Editor hlavní část nástroje určená pro modelování byznys procesů a digramů obecně Kromě těchto základních částí nástroj obsahuje ještě další části: 3. Dictionary slovník, který spravuje veškeré pojmy používané v diagramech a zároveň s tím obsahuje jejich popisy 4. Portal portál spolupráce umožňující zobrazit základní informace o digramu a jednotlivých použitých prvcích, jeho náhled a případně diagram komentovat vhodné např. z pohledu zákazníka. 5. Simulation umožňuje vizualizovat proces a simulovat jeho chování 6. Diagram comparison část umožňující porovnání změn dvou diagramů v různých revizích nebo porovnání různých diagramů V této práci popisuji zejména dvě základní částí - Explorer a Editor, protože ostatní vnímám jako části určené zejména pro pokročilé a náročné uživatele. Registrace a přihlášení účastníka Po registraci do aplikace a následném přihlášení pomocí přihlašovacího dialogu se po krátkém čekání nástroj spustí a přesměruje nás na úvodní obrazovku, kterou je vždy část nástroje zvaná Explorer. Znamená to tedy, že po každém spuštění nás nástroj přesměruje do interního správce souborů. 31

39 Explorer Uživatelské rozhraní části Explorer je tvořeno dvousloupcovým designem s hlavičkou a skrývající se patičkou. Obrázek 16: Popis uživatelského rozhraní části Explorer Levý sloupec dvousloupcového designu nástroje, části Explorer, je věnován k zobrazení stromové struktury souborů našich projektů a diagramů. Nechybí ani koš pro odstraněné soubory nebo část aplikace nazvaná Dictionary (Slovník), který spravuje veškeré pojmy používané v diagramech a k tomu jejich popisy. Skrývající se patička tohoto designu zobrazuje po vybrání konkrétního souboru náhled (Preview) a přehled revizí souborů, resp. historii úprav (Feed) ve formě přehledného grafu. Hlavička uživatelského rozhraní nástroje obsahuje kromě loga a názvu nástroje, aktuálně přihlášeného uživatele, tlačítko pro odhlášení, vyhledávací pole, tlačítko pro vyvolání nápovědy (Help) nebo obnovení stránky (Refresh) a sadu ikon. Tuto sadu ikon tvoří dvě části uživatelské ikony a ikony pro práci se soubory. Uživatelské ikony v pravé části hlavičky umožňují úpravu profilu, správu práv a uživatelů nebo definování notací či jazyků. Mnohem rozsáhlejší je nabídka pro práci se soubory. 32

40 Obrázek 17: Hlavička s menu části Explorer Vyhledávání Vyhledávací pole slouží pro jmenné vyhledávání v uložených a sdílených souborech. Vedle vyhledávacího pole je ikona pokročilého vyhledávání (Advanced Search). Po jejím stisknutí se v levém sloupci zobrazí roleta s možnostmi pro vyhledávání, zároveň s polem pro zadání vyhledávaného výrazu. Pokročilé vyhledávání umožňuje uživateli hledat např. na základě jména elementu, popisu, posledního autora, data změny nebo publikace, popřípadě na základě komentáře revize. Hlavička uživatelského rozhraní obsahuje několik rozbalovacích nabídek. Jsou zde nabídky New, Edit, Import/Export, Reporting a Share. Vytvoření nového souboru První jmenovaná nabídka menu, New, umožňuje vytvořit novou složku pro lepší třídění uložených souborů v Exploreru. Po stisknutí New -> Folder, zadání jména složky do dialogu a stisknutí tlačítka OK se požadovaná složka vytvoří. Vedle složek lze také zakládat nejrůznější diagramy (Business Process Diagram, Conversation Diagram, UML Class Diagram, Petri net, Organization Chart a další) podle různých notací a schémat, jako např. BPMN 1.2, BPMN 2.0, DMN 1.0 nebo jpdl 4. Zvolený diagram se vytvoří stisknutím tlačítka New a vybráním požadovaného diagramu (např. New -> Business Process Diagram). Po vybrání se spustí editor, v kterém je možné zvolený diagram vytvořit. Další možností nabídky je možnost založit QuickModel, což je v podstatě jednoduchý průvodce, pomocí kterého je možné vytvořit diagram procesu. Tento průvodce je založen na několika formulářích a tabulkách, do kterých se vyplní základní informace o procesu a definují se jednotlivé aktivity, aktéři, vstupní a výstupní dokumenty. Nástroj takto získané informace vyhodnotí a na jejich základě v reálném čase automaticky sám vytváří diagram. 33

41 Editace stávajícího souboru nebo složky Nabídka Edit je dostupná vždy po vybrání souboru nebo složky, i když v případě složky, jsou dostupné funkce oproti možnostem u souborů velmi omezené. U složky jsou k dispozici pouze funkce: Move (Přesuň), Delete (Smaž), Change name (Přejmenuj). U souborů jsou možnosti editace mnohem rozsáhlejší. Kromě základních operací pro manipulaci, stejných jako u složek, nástroj nabízí i pokročilé možnosti editace: Edit Quickmodel editace popisem diagramu pomocí tabulek a formulářů Edit diagram ruční editace diagramu Simulate diagram simulace chování diagramu Compare revisions/diagrams porovnání dvou různých diagramů nebo stejných diagramů na základě revize Show comments spravování komentářů a spolupráce nad diagramem (pomocí části Collaboration Portal) Zajímavou možností je volba Migrate BPMN 1.2 to BPMN 2.0. Volba je dostupná pouze u diagramů vytvořených ve verzi notace BPMN 1.2 a umožňuje zmigrovat vytvořený diagram do novější verze notace BPMN 2.0. Editace souboru se provede jeho vybráním, stiskem tlačítka Edit a vybráním možnosti editace (např. Edit -> Edit diagram). U všech výše uvedených možností dojde k otevření diagramu v části Editor. Import a export Import/Export je další nabídkou menu. Nástroj Signavio Process Editor nám poskytuje široké možnosti exportu výsledných diagramů nebo importu diagramů z jiných nástrojů. Diagramy lze importovat ve formátu BPMN 2.0 XML a také lze importovat schémata jpdl 4.0 či XPDL 2.1. Ve všech případech se jedná o XML soubory. Za praktickou a užitečnou možnost importu hodnotím možnost importovat diagram z konkurenčního modelovacího nástroje Astah. Import se provede stisknutím tlačítka Import/export a vybráním požadovaného formátu pro import (např. Import/export -> Import Astah), v zobrazeném dialogovém okně se vybere požadovaný soubor a stiskne tlačítko Import. Diagramy lze také exportovat do stejných formátů souborů, jako v případě importu (tedy XML, BPMN XML 2.0, do XML schémat jpdl 4.0, XPDL 2.1 nebo formátu Astah) a kromě 34

42 toho nástroj Signavio přidává podporu exportu do grafických formátů PNG a SVG a do jednoho z nejrozšířenějších formátu PDF. Export se provede stisknutím tlačítka Import/export a vybráním požadovaného formátu pro export (např. Import/export -> Export PDF). V případně zobrazeném dialogovém okně se provede nastavení parametrů pro export a volba se potvrdí tlačítkem. Při exportu do grafických formátů se export provede okamžitě po vybrání formátu souboru (nezobrazuje se dialogové okno). Reportování Další nabídkou v pořadí je nabídka pro generování nejrůznějších reportů nazvaná Reporting. Tato nabídka skrývá opravdu velké množství nejrůznějších reportů, kde i náročný uživatel či manager jistě nalezne svůj požadovaný report. Mimo klasickou procesní dokumentaci ve formátech Word či PDF je nástroj schopný vygenerovat procesní analýzu nákladů, analýzu spotřeby zdrojů, matice předání odpovědnosti, analýzu rizik, atd. a to vše ve formátu XLS, který je možný naimportovat a otevřít v jakémkoliv tabulkovém procesoru. Konkrétní nabídka reportů je následující: Process documentation (PDF) procesní dokumentace ve formátu PDF obsahující základní informace, digramy, jejich popis a elementy Process documentation (Word) procesní dokumentace ve formátu Word obsahující základní informace, digramy, jejich popis a elementy Process cost analysis (XLS) procesní analýza nákladů v tabulkovém formátu XLS Resource consumption analysis (XLS) analýza vytíženosti zdrojů v tabulkovém formátu XLS Modeling convetions (XLSX) tabulka porušení konvencí při tvorbě diagramu z pohledu architektury, notace, pojmenování, struktury a rozvržení v tabulkovém formátu XLSX Responsibility assignment matrix / RACI (XLS) matice přiřazení odpovědnosti v tabulkovém formátu XLS Responsibility handovers matrix (XLS) matice předání odpovědnosti v tabulkovém formátu XLS Documents usage matrix (XLS) matice využití dokumentu v tabulkovém formátu XLS 35

43 IT system usage matrix (by diagrams) (XLS) matice přiřazení aktivit podle diagramů v tabulkovém formátu XLS IT system usage matrix (by roles) (XLS) matice přiřazení aktivit podle rolí v tabulkovém formátu XLS Process characteristics with element details (XLS) procesní charakteristiky s detaily jednotlivých elementů diagramu v tabulkovém formátu XLS Process model metrics (XLS) metriky procesního modelu (z kolika prvků se skládá diagram, počet hran, atd.) v tabulkovém formátu XLS Risks & controls report (XLS) přehled rizik a jejich řízení v tabulkovém formátu XLS Vytvoření reportu lze provést stiskem tlačítka Reporting a stiskem na příslušný report (např. Reporting -> Process documentation (PDF)). V následném dialogovém okně se zvolí diagram, z kterého je report požadován, případně se doplní základní informace a volby potvrdí. Sdílení Poslední nabídkou menu je nabídka Share (Sdílení). Tvůrce diagramu má možnost přizvat k práci nad daným diagramem či diagramy další osoby pomocí zadání jejich ové adresy. Nástroj nabízí několik možností pozvánek: Invite anyone for feedback pozvání kohokoliv k podání zpětné vazby, Invite modeler to edit pozvání modeláře k editaci, Invite to fill out Quickmodel pozvání k editaci pomocí Quickmodelu. V případě přizvání účastníka je třeba stisknout tlačítko Share a vybrat jednu z výše uvedených typů pozvánek (např. Share -> Invite anyone for feedback). Otevře se dialogové okno s textem zprávy, která je dané osobě zaslána, a pole pro zadání ové adresy účastníka. Po zaslání pozvánky dané osobě přijde s informací o pozvání a odkazy na diagramy, které byly s osobou sdíleny. Po kliknutí na odkaz z u se spustí část Comments (resp. Collaboration Portal), kde už uživatel může komentovat jakýkoliv element diagramu. Po odeslání některé z pozvánek je nutné dané přístupy spravovat. K tomu slouží v nabídce Share -> Manage feedback invitations. Po zvolení této možnosti se zobrazí jednoduché dialogové okno se seznamem všech uživatelů, s kterými byl již nějaký diagram sdílen. Daného uživatele lze kdykoliv vymazat pomocí volby Remove. 36

44 Jednotlivé diagramy je možno sdílet pomocí kódu HTML nebo odkazu a umístit je díky tomu, např. na své webové stránky. K tomuto typu sdílení slouží volba Share -> Embed diagram. Následné dialogové okno umožňuje vygenerovat HTML kód pro webové stránky, MediaWiki nebo odkaz na soubor ve formátu PNG. Pak už stačí vygenerovaný kód z pole zkopírovat a vložit na požadované místo. Poslední možností sdílení je zobrazení náhledu na portálu spolupráce, volba Share -> Preview in Collaboration Portal, kde lze zobrazit základní informace o diagramu a jednotlivých použitých prvcích, případně jednotlivé části diagramu okomentovat. Řešení ve formě portálu je vhodné třeba v případě, pokud je potřeba diagram připomínkovat, např. zákazníkem Editor Rozložení uživatelského rozhraní části Editor je velmi podobné jako v případě části Explorer. V tomto případě je však rozložení uživatelského rozhraní trojsloupcové s hlavičkou, kdy jeden sloupec je možnost skrýt. Díky tomuto řešení má uživatel dostatek volné pracovní plochy, což je při modelování velmi podstatné. Patička je zobrazena jen při některých funkcích. Obrázek 18: Popis uživatelského rozhraní části Editor Rozhraní obsahuje několik základních a důležitých částí, které jsou zobrazeny na obrázku 18 výše: 37

45 přepínač módů, ovládací nástroje, modelovací nástroje, pracovní plocha, atributy. Editor se spustí vždy po založení nebo otevření zvoleného diagramu v části Explorer. Uživatelské rozhraní tvoří tyto části: Přepínač módů Přepínač módů je umístěn na pravé straně v hlavičce uživatelského rozhraní. Je řešen pomocí rozbalovací rolety, která uživateli umožňuje přepínat mezi následujícími módy: Graphical Editor grafický editor umožňující pomocí grafického rozhraní metodou drag & drop modelovat diagramy, QuickModel jednoduchý editor, který za pomoci vyplněných informací do tabulek a formulářů automaticky vytvoří diagram, Diagram comparison část umožňující porovnání dvou stejných diagramů v různých revizích nebo dvou různých digramů, Simulation část umožňující vizualizaci vytvořeného diagramu (resp. procesu) a simulaci jeho chování. Po vybrání požadované možnosti se diagram, na kterém se aktuálně pracuje, automaticky otevře v novém módu. Ovládací nástroje Sada ikon ovládacích nástrojů je umístěna v hlavičce uživatelského rozhraní nástroje, jak je vidět na obrázku 18. Jedná se především o uživatelské a manipulační funkce, které jsou dostupné ve všech běžných editorech. Mezi základní funkce, které tato sada ikon nabízí, patří funkce Save (uložení), Print (tisk), Cuts the selection into the clipboard (vyjmutí výběru), Copies the selection into the clipboard (kopie výběru), Pastes the clipboard to the canvas (vložení objektů ze schránky do pracovní plochy), Deletes all selected shapes (smazání všech vybraných objektů), Undo the last action (vrať poslední akci), Redo the last undone action (opakuj poslední vrácenou akci), Alignment (zarovnání), Text (nástroj pro práci s textem) nebo sada funkcí Zoom (přiblížení, oddálení 38

46 objektu, atd.). Práci s těmito nástroji záměrně nepopisuji, neboť předpokládám, že s nástrojem Signavio přijdou do styku zejména pokročilejší uživatelé, kteří již s nějakým editorem někdy pracovali. Obrázek 19: Ovládací nástroje produktu Signavio Process Editor Nástroj disponuje několika ovládacími funkcemi, které stojí za zmínku a nejsou v některých editorech tak běžné. Jednou z nich je funkce Create or remove free space by clicking and dragging, což je funkce, která po jejím zapnutí umožňuje vytvořit nebo odebrat volný prostor kdekoliv na pracovní ploše pouhým kliknutím do prostoru a tažením za držení stisknutého tlačítka myši. Tímto způsobem je možné například vytvořit větší rozestup mezi dvěma elementy diagramu, aniž by bylo potřeba předtím složitě všechny elementy vybírat a opatrně posouvat, neboť při této manipulaci se často stává, že dojde k rozbití jiné části diagramu. Další velmi užitečnou funkcí je funkce Restructure the process with BPStruct. BPStruct je nástroj pro transformaci špatně strukturovaných diagramů na dobře strukturované. Model je správně strukturován, pokud je pro každý uzel s více výstupními toky odpovídající uzel s více příchozími toky a naopak, tzn., že výstupy z uzlu a vstupy do uzlu jsou sloučeny do jednoho toku. Obrázek 20: Model před a po transformaci nástrojem BPStruct Nástroj disponuje funkcemi Show all comments of the current diagram (zobrazení všech komentářů daného diagramu), Show risks and controls on process elements (zobrazení rizik 39

47 a jejich řízení) a funkcemi kontroly Check syntax (kontrola syntaxe), Check simulation capability (kontrola, zda je možné simulovat chování modelu), Cost and resource analysis check (kontrola potřebných informací pro analýzu nákladů a zdrojů), Check Signavio Best Practices for BPMN 2.0 (kontrola dodržení osvědčených postupů při modelování podle notace BPMN 2.0). Z hlediska uživatelské podpory jsou v nabídce zakotveny dvě možnosti: kontaktovat technickou podporu nástroje Signavio s otázkou na nástroj Signavio nebo možností reportovat chybu ve funkčnosti nástroje pro vyřešení problému otevřít uživatelskou příručku nástroje Signavio Process Editor Modelovací nástroje Menu je umístěno v levém sloupci uživatelského rozhraní nástroje a je rozčleněno do několika skupin, které lze z důvodu lepšího zobrazení skrýt, tzn., že je možné mít vždy rozbalenu jenom tu část menu, kterou ke své současné práci uživatel potřebuje. Jedná se v podstatě o repozitář elementů notace BPMN 2.0, který logicky slučuje do skupin podobné elementy, např. všechny počáteční události jsou setříděny do jedné skupiny atd. Obsah menu je závislý na typu diagramu a notaci, které podléhá, tzn., že jiný obsah menu bude v případě, když je tvořen UML Class Diagram a jiný v případě tvorby Business Process Modelu. Pracovní plocha Při modelování jsou jednotlivé elementy z tohoto menu přetaženy pomocí myši na pracovní plochu. Po dvojitém kliknutí tlačítkem myši na daný element se zobrazí textové pole a možnost daný element pojmenovat. Při pouhém označení elementu kurzorem myši se okolo elementu zobrazí lokální menu s několika volbami, viz. obrázek 21. Obrázek 21: Element s lokálním menu Při postupu od pravého horního rohu jsou pod sebou dvě ikony, které se po najetí kurzorem myši rozbalí na širší nabídku. Z té je možné vybrat další z elementů dané notace a tento nový 40

48 element zobrazit na pracovní ploše, včetně propojení s elementem, z kterého tento nový element vznikl. Díky této funkci lze rychle vytvářet, např. procesní diagramy. Ikona šipek, resp. toků zprostředkovává propojení elementu s jiným elementem. Použití této funkce je jednoduché a funguje obdobně jako při práci s ostatními funkcemi. Na danou ikonu stačí kliknout tlačítkem myši, držet a kurzorem najet nad element, s kterým se daný element propojuje. Typ toku je volen automaticky. Systém umí vyhodnotit, které elementy se propojují, a dle toho sám zvolí správný typ toku. V lokálním menu pod obrazcem zleva je ikona slovníku, která vyvolá dialogové okno přidání nové položky do části Dictionary. Napravo od této volby je tlačítko Transform shape, které element přetransformuje dle nabídky na jiný. Atributy Nastavení atributů umístěné v pravém krajním sloupci uživatelského rozhraní Editoru lze v případě potřeby skrýt. Pomocí něj je možné k libovolnému elementu diagramu (např. aktivitě, toku, atd.) přidat dodatečné informace atributy, které jsou následně použity při generování nejrůznějších dokumentací a reportů. Nabídka atributů se vždy mění v závislosti na vybraném elementu diagramu. Ke každému elementu se zobrazují pouze relevantní atributy. Obecně lze pomocí atributu měnit např. barvu jednotlivých elementů, jejich pojmenování, doplnit podrobný popis elementu (např. v případě aktivity, kde lze popsat podrobně danou aktivitu), ohodnotit riziko, které daný element představuje, atd. Nastavení atributů je u každého elementu poměrně bohaté. Obrázek 22: Ukázka nastavení atributů elementu typu Task 41

49 Dictionary Dictionary (Slovník) je část nástroje, která slouží jako základní úložiště všech objektů využitých v diagramech. Objekty lze popsat a používat je v jednom nebo více diagramech. Tímto řešením je zaručená konzistence objektů mezi všemi diagramy. Uživatelské rozhraní této části je obdobné jako u jiných částí s tím rozdílem, že rozložení je pouze dvousloupcové s hlavičkou. V hlavičce najdeme standardně menu, v levém sloupci jednotlivé kategorie, do kterých lze objekty roztřídit. Pravý sloupec slouží jako prostor pro zobrazení jednotlivých položek slovníku. Obrázek 23: Popis uživatelského rozhraní části Dictionary Menu nabízí přidání nové položky (New Entry) do slovníku pomocí dialogového okna, kde je nutné vyplnit pojmenování objektu, kategorii, do které se má objekt zařadit a samotný objekt případně popsat. K objektu lze přidat odkaz na související dokument. Mezi další funkce patří funkce Merge Dictionary Entrie, která dokáže sloučit dva objekty. Funkce Export to Spreadsheet umožňuje exportovat buď celý slovník, nebo jenom jeho vybranou kategorii do tabulkového procesoru. Nástroj samozřejmě zvládá i opačný postup a to import z tabulkového procesoru. K tomu slouží funkce Import from Spreadsheet a pro import vyžaduje soubor ve formátu.xls nebo.xlsx. Nástroj je schopný vyhledávat objekty ve slovníku dle abecedy nebo pomocí vyhledávacího pole umístěného v hlavičce uživatelského rozhraní. 42

50 Portal Portal je jeden z nejmocnějších částí nástroje Signavio Process Editor. Slouží pro prohlížení a diskutování nad jednotlivými diagramy spolu s kolegy nebo zákazníky, přičemž umožňuje definovat, kdo a k jakým diagramům má mít přístup. Rozložení uživatelského rozhraní je trojsloupcové a je podobné uživatelskému rozhraní z části Editor jen s jediným rozdílem, že třetí krajní sloupec v tomto případě není možné skrýt. Levý sloupec slouží k zobrazení stromové struktury souborů našich projektů a diagramů, prostřední jako pracovní plocha pro zobrazení diagramu. Pravý krajní sloupec má tři možnosti zobrazení: Info zobrazí veškeré dostupné informace o diagramu, použitých slovníkových objektech, atd. Legend zobrazí stručný popis všech použitých elementů v diagramu Comments zobrazí diskusi nad diagramem Obrázek 24: Popis uživatelského rozhraní části Portal 43

51 Simulation Uživatelské rozhraní této části je uzpůsobeno její hlavní funkci a z tohoto důvodu je pro co největší přehlednost řešeno jednoduše. Je tvořeno pouze pracovní plochou a částí pro scénáře. Pracovní plocha slouží k zobrazení simulovaného procesu a ovládacích tlačítek pro ovládání této simulace. Část pro scénáře kromě zobrazení nejrůznějších statistik nabízí tlačítko pro vytvoření nového scénáře. Obrázek 25: Popis uživatelského rozhraní části Simulation 44

52 Diagram comparison Rozhraní nejrůznějších nástrojů pro jakékoliv porovnávání je obvykle dosti podobné, protože za dobu, po kterou tyto nástroje existují, se nejvíce osvědčilo dvousloupcové rozložení, které poskytuje potřebný přehled o změnách mezi dvěma soubory, diagramy apod. Stejné řešení je i v nástroji Signavio Process Editor. V hlavičce nástroje je vidět počet změn, přehled verzí a název porovnávaného diagramu. Pod hlavičkou lze v každém sloupci vybrat pomocí rozbalovací nabídky příslušné revize diagramů k porovnání. Na pracovní ploše jsou porovnávané diagramy a přehledně zvýrazněné případné změny (přidané, smazané nebo upravené elementy atd.). Patička slouží k zobrazení statistiky počtu elementů přidaných, smazaných, upravených atd. Obrázek 26: Popis uživatelského rozhraní části Diagram comparison 4.3. Kvalita modelů V organizacích a podnicích je do návrhu a modelování procesů zapojeno obvykle více osob. Následně vzniká velké množství nekonzistentních modelů, u kterých je třeba dodržovat stejnou kvalitu a úroveň bez ohledu na to, kdo daný proces modeloval. Pro zachování 45

53 konzistence má nástroj Signavio Process Editor integrovánu kontrolu modelů, která probíhá automaticky při ukládání modelu nebo na základě vyvolání kontroly tlačítkem v části nástroje Editor. Nástroj umožňuje provádět několik typů kontroly kvality modelů: 1. Kontrolu syntaxe (Check syntax) 2. Kontrolu simulace chování modelu (Check simulation capability) 3. Kontrolu potřebných informací pro analýzu nákladů a zdrojů (Cost and resource analysis check) 4. Kontrolu dodržení osvědčených postupů při modelování podle notace BPMN 2.0 (Check Signavio Best Practices for BPMN 2.0) Každá z těchto kontrol vyžaduje jinou úroveň informací v modelu. Kontrola potřebných informací pro analýzu nákladů a zdrojů vyžaduje jiný detail informací (mnohem více vyplněných atributů elementů) než například kontrola dodržení osvědčených postupů, z jejíž úrovně detailu je nástroj schopen bez problému vygenerovat např. procesní dokumentaci. Pro samotné modelování procesů je důležitá a potřebná kontrola syntaxe a kontrola dodržení osvědčených postupů při modelování podle notace BPMN Kontrola syntaxe Tento typ kontroly provádí kontrolu modelu dle základních pravidel (syntaxe) definovaných přímo notací BPMN 2.0. Jedná se o kontrolu konstrukčních pravidel jednotlivých elementů, např. kontrola připojení toků k elementům, kontrola počtu vstupních a výstupních sekvenčních toků elementu atd. Syntaktické nedostatky jsou vždy hodnoceny jako chyby, protože způsobují nefunkčnost celého procesu Kontrola dodržení osvědčených postupů při modelování podle notace BPMN Na rozdíl od kontroly syntaxe je tento typ kontroly komplexnější, neboť kromě syntaxe provádí kontrolu zavedených konvencí a praktik při modelování byznys procesů pomocí notace BPMN 2.0. Po provedení kontroly jsou nálezy rozčleněny podle povahy chyb do několika kategorií (viz kapitola 4.3) a dle závažnosti nálezu do kategorií na: 46

54 chyby, varování, rady. V případě nalezených chyb nás nástroj na tuto skutečnost striktně upozorní při ukládání modelu. Pokud model neobsahuje chyby ani varování, ale pouze nesplňuje notační rady, neovlivňuje tato skutečnost chování modelu procesu. Při vygenerování dokumentace či reportu mohou chybět některé podkladové informace. Jednotlivé rady a doporučení nástroje Signavio pro notaci BPMN 2.0 jsou podrobně popsány v následující kapitole Doporučení pro tvorbu modelů Jedním z typů kontroly kvality modelu je kontrola na základě doporučení sestavených výrobcem nástroje Signavio Process Editor, která z velké většiny vychází z konvencí neboli ustálených pravidel, definovaných na základě zkušeností jednotlivých tvůrců modelů. Kontrola doporučení nástroje Signavio Process Editor probíhá v pěti následujících níže uvedených oblastech. Při nedodržení některého z pravidel nás na tuto skutečnost nástroj upozorní výčtem a vážností chyb. Zdrojem pro uvedená doporučení je webová příručka výrobce nástroje. [20] Komentáře a názvy diagramů Uvedená doporučení této části lze považovat za obecná, neboť se přímo netýkají konkrétní problematické oblasti, jako tomu je v dalších oblastech doporučení. Doporučení uvádějí práci s komentáři a názvy diagramů. Začlenění veřejných komentářů Veřejné komentáře mohou obsahovat užitečné informace k procesu, je důležité je vzít v úvahu. Přidané komentáře pomocí připomínkovací funkce nástroje může následně autor modelu: akceptovat v případě, že komentář souvisí s procesem a je užitečný, ignorovat nebo smazat v případě, že komentář nesouvisí s procesem. V případě, že nástroj nalezne u modelu přidané a zároveň neohodnocené komentáře jedním z těchto stavů, vyhodnotí pravidlo jako porušené. 47

55 Unikátní názvy diagramů Každý diagram by měl být jedinečně pojmenován a tento název by neměl být duplikován. Pojmenování každého diagramu by mělo korespondovat s obsahem daného procesu. Při větším množství procesů a subprocesů je vhodné, pro lepší rozlišení a přehlednost, před název diagramu přidat číselné označení, např. proces pojmenovat jako 1.2 Zpracování faktury a subproces tohoto procesu pojmenovat jako Tisk faktury Rozvržení Následující uvedená pravidla definují doporučení, jak správně při modelování rozmístit jednotlivé elementy, aby nedocházelo např. k jejich překrytí nebo křížení, a jak modelovat jednotlivé propojovací toky. Překryv toků (hran) Překrytí toků narušuje čitelnost diagramu a porozumění procesu a může tak dojít ke špatné interpretaci významu těchto toků. Toky by vždy měly mít mezi sebou mezeru. Průnik a křížení jednotlivých elementů Průnik (např. překryv nebo překřížení) elementů snižuje přehlednost a čitelnost diagramu. Toky (hrany) by se neměly křížit s jinými ani procházet skrz jiné elementy a naopak elementy by se neměly ani částí překrývat. Jednotlivé elementy by vždy měly mít mezi sebou mezeru. Dodržení maximální velikosti diagramu Maximální velikostí diagramu v nástroji Signavio Process Editor je diagram formátu A3. Rozsáhlé diagramy jsou nepřehledné, je obtížné je číst a mají tendenci obsahovat více chyb. Z tohoto důvodu je vhodné rozsáhlé procesy rozdělit do subprocesů, které jsou v samostatných souborech. Konzistentní modelování asociace Asociace by měla být v diagramech modelována jako přímá, nikoliv jako lomená. Konzistentní modelování toku zprávy Tok zpráv by měl být v diagramech modelován svisle k bazénu bez lomení. 48

56 Konzistentní modelování sekvenčního toku Sekvenční tok by měl být modelován jako přímý. V nezbytném případě je možné tok zalomit a to pouze v úhlu 90. Konzistentní modelování vstupních a výstupních toků zpráv Při modelování výměny zpráv mezi dvěma bazény by měla být dodržena konzistence mezi vstupním a výstupním tokem (tj. oba toky by měly být vymodelovány stejným způsobem) za dodržení podmínky svislého přímého vymodelování. Konzistentní modelování vstupních a výstupních sekvenčních toků Sekvenční toky by měly být modelovány konzistentně, tj. výstupní tok může vycházet shora, zespodu nebo zprava elementu a vstupovat zleva, zespodu nebo shora. V každém případě by neměl vystupovat ze stejné strany elementu, jako do které vstupuje (např. výstupní tok ze spodní strany elementu by neměl vstupovat do dalšího elementu také zespodu). V případě potřeby je možné sekvenční tok vymodelovat jako lomený. Definice správného směru modelování Před samotným modelováním by měl být určen jeho směr. Ten může být změněn přímo v nástroji Signavio Process Editor, v kterém lze vybrat mezi horizontálním nebo vertikálním směrem modelování. Vybraný směr je pak nutné striktně dodržet. Dostatečná vzdálenost mezi prvky Mezi jednotlivými prvky by měla být použita dostatečná vzdálenost. Nástroj Signavio hlídá vzdálenost mezi propojenými prvky, přičemž tuto vzdálenost je schopen automaticky nastavit. Definice směru toku dat Tok dat by měl být modelován svisle k aktivitám. Definice směru sekvenčního toku Sekvenční tok by měl být modelován pouze v jednom směru, např. zleva doprava. 49

57 Pojmenování Při tvorbě diagramů je nutné dbát na správné pojmenování. Nástroj Signavio Process Editor dbá na správné a logické pojmenování jednotlivých částí diagramů, aby nedošlo k nechtěné záměně elementů a špatnému pochopení procesu. Konzistentní pojmenování subprocesů Samotný subproces by měl mít stejný název jako aktivita v nadřazeném procesu. To znamená, že subproces se jmenuje stejně jako aktivita v nadřazeném procesu odkazující na subproces. Pojmenování datových objektů Každý datový objekt by měl být pojmenován. Pojmenování by mělo být výstižné a lze ho provést dvojím kliknutím na daný objekt. Pojmenování událostí Každá událost by měla být pojmenována. Název prvku lze zadat dvojím kliknutím na prvek. Pojmenování události by mělo odrážet stav, v kterém se proces nachází. Pojmenování rolí Každá role musí mít jméno. Název role by měl korespondovat s tím, kdo je odpovědný za proces. Značení aktivit Aktivita musí být pojmenována tak, aby indikovala, která aktivita má být provedena. Pojmenování aktivit Každá aktivita vyžaduje jméno. Konzistentní pojmenování brány XOR Všechny brány XOR by měly být pojmenovány stejným způsobem podle příslušného nastavení modelovacích konvencí. Brána může být pojmenována dotazem, na který je odpovězeno výběrem příslušného výstupního sekvenčního toku nebo může obsahovat pouze uvedené možnosti u výstupních toků. 50

58 Notace Následující doporučení uvádějí způsob, jak zaznamenat jednotlivé objekty diagramu, aby při pozdějších úpravách nedocházelo k nekonzistenci mezi jednotlivými diagramy, a jak předcházet nesprávnému pochopení aktivit v procesu. Uložení datového objektu, IT systému nebo role ve slovníku Jednotlivé objekty (datové objekty, IT systémy nebo role) by měly být uloženy ve slovníku. Slovník zajistí centrální správu všech objektů. V případě úpravy objektu, stačí objekt upravit pouze na jednom místě bez ohledu na to, v kolika diagramech se vyskytuje. Pokud objekt ve slovníku neexistuje, je možné ho přidat. Popis aktivit Každá aktivita by měla být podrobně popsána, aby byla správně pochopena, protože může být interpretována různými způsoby Struktura procesu Dodržení následujících uvedených doporučení zajistí správnou strukturu procesu včetně správného použití jednotlivých jeho elementů. Správná struktura procesu je důležitá pro zajištění správného chování celého procesu a předejití nechtěným stavům procesu jako např. jeho uváznutí. Uváznutí procesu Při nesprávném použití bran dochází k uváznutí (zablokování) procesu. Při rozhodnutí, kudy proces má pokračovat, je využita XOR brána a následně by měly být větve z této brány sloučeny pomocí brány AND. V tomto případě slučovací brána AND čeká na doběhnutí procesu v obou větvích, ačkoliv proces pokračuje pouze v jedné větvi. Tímto způsobem dochází k zablokování procesu. Je nutné tomuto stavu předcházet použitím správné brány (v tomto případě brány XOR). Pokud je v procesu použito více bran, je doporučena důkladnější kontrola procesu. Multi sloučení Jedná se o opak uváznutí. Špatná kombinace bran může způsobit několikanásobné spuštění následujícího toku aktivit. K tomuto jevu může dojít v případě paralelního běhu procesu 51

59 a následnému sloučení pomocí brány XOR nebo v případě více sekvenčních toků, vedoucí z jedné aktivity do jiné. Místa v procesu, kde jsou instalovány brány, je nutné kontrolovat. Využití bran pro rozdělení toku V případě potřeby rozdělení toku se výslovně doporučuje využít bran. Rozdělení toku by nemělo být řešeno za pomoci aktivit, protože každá aktivita má mít pouze jeden výstupní sekvenční tok. Využití bran pro rozdělení toku po mezikrokové události Je doporučeno, aby mezikroková událost měla pouze jeden výstupní sekvenční tok. Následné rozdělení toku by mělo být provedeno za prvkem mezikroku pomocí brány. Řešení zvýší přehlednost procesu a sníží riziko chyb a problémů, např. s uváznutím nebo multi sloučením. Využití bran pro rozdělení toku po začátku události Počáteční událost by měla mít pouze jeden výstupní sekvenční tok a neměla by zajišťovat jeho rozdělení. Rozdělení by mělo být realizováno až po počáteční události pomocí brány. Sloučení toku pomocí bran Aktivita by měla mít pouze jeden výstupní sekvenční tok. Při sloučení rozděleného toku je doporučeno k tomuto účelu využít brány, kterou proces pokračuje, místo použití aktivity. Toto řešení zvýší přehlednost a sníží počet chyb. Prvky vykonávající funkci rozdělení a sloučení zároveň Je důležité dodržovat striktní rozdělení bran, které tok rozdělují (rozvětvují) a bran, které tok naopak slučují. Není možné, aby brána vykonávala zároveň funkci rozdělení a sloučení. Pokud v procesu tato kombinace funkcí brány existuje, je nutné vymodelovat novou bránu pro oddělení funkcí. Absence cyklů vytvořených subprocesy Vztah mezi procesem a subprocesem musí být čistě hierarchický, nikoliv cyklický. V případě modelování procesu a subprocesu je nutné dbát zvýšené opatrnosti, aby nedošlo k vytvoření cyklu. K zacyklení může snadno dojít v případě, že aktivita procesu odkazuje na subproces, jehož aktivita řeší proces, na který se odkazuje. 52

60 Využívání bazénů při modelování procesu a subprocesu Pro zachování konzistence je nutné, aby bazén procesu a subprocesu byl pojmenován stejně. Používání počátečních a koncových událostí procesu Každý proces musí mít alespoň jednu zahajovací a ukončovací událost, aby byl jasně specifikován začátek a konec procesu. Není možné, aby proces měl buď jen počáteční, nebo jen ukončovací událost. Připojení hraničních událostí k aktivitě Pro správné zobrazení a pochopení procesu je nutné správné připojení hraniční události k aktivitě. Přidání hraniční události v nástroji Signavio Process Editor je snadné. Za držení tlačítka myší přesuneme hraniční událost až k okraji aktivity, dokud se její okraj nezmění na zelenou barvu. Použití podmíněných a výchozích toků Za objektem může být použit pouze jeden výchozí tok a jeden nebo více podmíněných toků. Podmíněný tok je takový, který obsahuje podmínku, která má být splněna, aby tok pokračoval dále. V případě nesplnění ani jedné podmínky se provede výchozí tok. Výměna zpráv mezi bazény V případě procesu s více bazény by každý bazén měl být propojen minimálně jedním tokem s jiným bazénem a s hlavním procesem, v opačném případě se nepropojený bazén nezúčastňuje procesu. Použití omezeného počtu bazénů Pro zachování přehlednosti modelovaného procesu by mělo být omezeno použití bazénů v diagramu na minimum. Bazény, které přímo nesouvisí s aktuálním procesem, by měly být ukončeny. Použití syntaxe Při návrhu procesu musí být dodržen logický postup a všechny prvky procesu musí být vzájemně propojeny. V případě modelování subprocesu musí být posloupnost aktivit ohraničena jako subproces a případné toky musí být s tímto ohraničením subprocesu propojeny. 53

61 Při výměně zpráv mezi dvěma bazény a dvěma částmi procesu je nutné mít na paměti, že komunikace s jiným bazénem nezajistí propojení částí procesu. Pro propojení částí procesu je nutné využít tok mezi prvky. Použití bran Brána slouží k rozdělení, sloučení nebo spojení procesů. Každá brána by měla mít jeden příchozí tok a více odchozích, nebo naopak více příchozích toků a jeden odchozí. Aktivity a toky zpráv Tok zpráv by měl být využíván jen s určenými prvky. Odesílací aktivity by měly být modelovány s odchozím tokem zpráv, příjímací aktivity naopak s příchozím tokem zpráv. Počáteční událost v procesu nebo subprocesu Každý proces nebo subproces musí mít přesně definovaný začátek a pouze jednu počáteční událost. Více počátečních událostí může způsobit špatnou interpretaci procesu, resp. subprocesu. 54

62 5. Praktický příklad vymodelování podnikového procesu v nástroji Signavio Process Editor Praktickou část tvoří jednoduchý příklad metodického postupu modelování na základě zadání. Příklad je řešen od samého začátku, tedy od počáteční analýzy problému až po samotné modelování procesu v nástroji Signavio Process Editor a následnou kontrolu modelu včetně názorného odstranění nedostatků modelu procesu Zadání procesu Zadáním procesu je objednávka jídla z restaurace. Zákazník si na webových stránkách své oblíbené restaurace vybere dle aktuálního menu jídlo. Na základě tohoto výběru provede objednávku. Restaurace ji po přijetí zákazníkovi potvrdí a sdělí předpokládaný čas doručení. Ten by neměl přesáhnout 60 minut od přijetí objednávky. Objednávka je doručena na adresu zákazníka, tzv. poslíčkem. V případě nedoručení objednávky do 60 minut, zákazník kontaktuje restauraci s dotazem na svoji objednávku. Příjemce reklamací zákazníka v tomto případě uklidní s informací o brzkém doručení. Připravená objednávka je doručena zákazníkovi na uvedenou adresu poslíčkem. Poslíček zákazníkovi předá účet a objednávku a zákazník mu na základě účtu zaplatí Postup návrhu byznys procesu dle zadání Začátek procesu modelování. K dispozici je zadání od zákazníka, na základě zadání je provedena analýza. Při nedostatku informací od zákazníka je nutné chybějící informace specifikovat a doplnit. V této fázi je nejlepším řešením postupovat položením si jednoduchých otázek, které jsou uvedeny v kapitole 2.6 této diplomové práce. 1. Co? Tato otázka pomůže odhalit, co se modeluje, co je vstupem a co výstupem procesu a jaké funkce má podnik plnit. 55

63 Naším zadáním je realizovat objednávku jídla. Vstupem tohoto procesu je chuť zákazníka na jídlo, resp. tedy jeho objednávka. Výstupem procesu je spokojený zákazník, který obdržel svoji objednávku a na jídlo nečekal déle, než byla určena doba doručení. V případě, že se tomu tak nestalo, zákazník obdržel od personálu včas informace, situaci pochopil a se zpožděním dodávky počítal. Funkcí restaurace je objednávku zpracovat, jídlo uvařit a včas ho zákazníkovi doručit. 2. Jak? Dále je třeba stanovit, jak těchto aktivit dosáhneme pomocí aktivit a procesů. Zákazník uspokojí svoji chuť na jídlo tím, že vyhledá oblíbenou restauraci, vybere si jídlo z aktuálního menu a provede objednávku. Následně vyčká na doručení objednaného jídla, které převezme a zaplatí za něj. Restaurace přijme objednávku od zákazníka, zpracuje ji a připraví objednané jídlo. Objednávku zákazníkovi doručí do 60 minut a nechá si za ni zaplatit. V případě komplikací jako je např. nedodržení doby doručení, restaurace kontaktuje zákazníka, o těchto skutečnostech ho informuje, popřípadě uklidní. Na základě tohoto rozboru lze tedy definovat následující aktivity: vybrat jídlo, objednat jídlo, zeptat se na jídlo, převzít jídlo, zaplatit jídlo, sníst jídlo, přijmout objednávku, uklidnit zákazníka, připravit jídlo, doručit jídlo, převzít platbu. Pomocí těchto kroků je dosaženo doručení objednaného jídla a uspokojení potřeby zákazníka. 3. Kým a čím? Nyní je znám cíl a jeho dosažení. V řešení zůstává otázka, čím se dosáhne cíle, kdo a co z výše uvedených aktivit realizuje. Cíle lze dosáhnout např. pomocí informačního systému, který dokáže provádět sběr objednávek a jejich zpracování. V předchozím bodě je definováno šest aktivit: vybrat jídlo, objednat jídlo, zeptat se na jídlo, zaplatit jídlo, převzít jídlo a sníst jídlo. To vše souvisí s realizací samotné objednávky a uspokojením zákazníka. Tyto aktivity tedy bude realizovat zákazník. Zbývají nám tedy aktivity přijmout a zpracovat objednávku, uklidnit zákazníka, připravit jídlo, doručit jídlo a převzít platbu. Z těchto aktivit je zřejmé, že jsou v případě objednávky jídla realizovány subjektem restaurace. Při bližším určení je nutné však blíže specifikovat, 56

64 které role jaké aktivity vykonají. Pokud by je prováděla restaurace, nebylo by to přesné už jen z důvodu, že nelze rozdělit kompetence za jednotlivé aktivity a navíc by nebylo ani jasné, kdo restauraci zastupuje. Bylo by těžko uvěřitelné, že by všechny tyto aktivity mohla zvládat jedna osoba a měla k tomu navíc všechny kompetence. Přijmout a zpracovat objednávku od zákazníka musí v restauraci osoba k tomu speciálně určená, protože pokud je restaurace většího charakteru, oblíbená a v oblasti s velkým počtem administrativních budov nebo výrobních podniků, je zřejmé, že rezervací má mnoho. Tato osoba je nazývána příjemcem objednávek. Pokud není objednávka doručena včas, jsou případné dotazy směrovány na pracovníka příjemce reklamací. Přípravu jídla má v restauraci na starosti kuchař. Připravenou objednávku i s účtem přebírá poslíček restaurace. Jídlo doručí zákazníkovi a převezme platbu. Je tedy definováno, kdo jaké aktivity realizuje: Zákazník vybrat jídlo, objednat jídlo, zeptat se na jídlo, zaplatit jídlo, převzít jídlo, sníst jídlo Příjemce objednávek přijmout objednávku Příjemce reklamací uklidnit zákazníka Kuchař připravit jídlo Poslíček doručit jídlo, převzít platbu 5.3. Realizace procesu Po podrobné analýze zadání jsou k dispozici veškeré důležité informace pro vymodelování samotného procesu. V následujícím textu je popsáno samotné vymodelování v nátroji Signavio Process Editor. 57

65 Modelování procesu Předpokladem pro začátek modelování je, že uživatel je již ve službě Signavio Process Editor zaregistrován a do služby přihlášen. Výchozím bodem následujícího postupu je část Explorer, do které se uživatel dostane již po přihlášení. Další postup při realizaci modelu procesu je následující: 1. Založit nový soubor pro diagram kliknutím v menu na New -> Business Process Diagram (BPMN 2.0). 2. Pro našich pět aktérů vytvořit bazény procesu. Do jednoho z nich vytvořit čtyři plavecké dráhy. Z menu modelovacích nástrojů, resp. repozitáře elementů na pracovní plochu přetáhnout ze skupiny Swimlanes tři elementy Pool/Lane. Tím jsou vytvořeny dva základní bazény jeden pro zákazníka a jeden pro restauraci. Do bazénu restaurace se následně stejným způsobem přetáhnou ještě další tři bazény, resp. dráhy. Tyto elementy je nutné táhnout ke kraji původního bazénu, kde nástroj sám znázorní, že tažení lze ukončit. Nástroj vytvoří v bazénu dráhu, v tomto případě tedy další tři dráhy. Uživatel může dvojitým klikem myši jednotlivé bazény a dráhy pojmenovat. 3. Nyní je nutné přistoupit k samotnému vymodelování procesu dle zadání a následné analýzy. Do jednotlivých plaveckých drah je nutné umístit stejným způsobem, jako v případě bazénů tažením, počáteční a koncovou událost. Počáteční událost se umístí na začátek plavecké dráhy zákazníka a je pojmenována jako Chuť k jídlu. Koncová událost se umístí na konec této plavecké dráhy s pojmenováním Chuť uspokojena. Další koncová událost se umístí na konec dráhy role poslíčka, protože po převzetí platby a předání objednávky končí proces i pro něj. 4. Jednotlivé elementy činnosti se pojmenují dle aktivit výše popsaných. Tyto činnosti jsou seřazeny dle logického pořadí jednotlivých aktivit u každé role. 5. Následně jsou kompletovány jednotlivé procesní větve v jednotlivých plaveckých drahách, pomocí toků a případných rozhodovacích elementů nebo událostí. Začíná se u zákazníka. Od počátku procesu, kdy zákazník měl chuť k jídlu, až po aktivitu provedení objednávky je možné elementy spojit sekvenčním tokem. Mezi objednávkou a převzetím jídla ovšem nastává několik událostí. V případě, že vše probíhá tak jak má, zákazník do 60 minut obdrží zprávu o doručení jídla a půjde si 58

66 jej převzít. Při nedodržení času doručení, kontaktuje restauraci s dotazem, kdy mu jídlo doručí. Z následujícího popisu je zřejmé, že zde musí figurovat brána řízená událostí, v případě které proces pokračuje, až když nastane jedna ze dvou uvedených událostí, tj. do 60 minut přijde zpráva o doručení nebo doba čekání překročí 60 minut a zákazník kontaktuje restauraci. Mezi aktivity objednávky jídla a převzetí jídla je nutné vložit již zmíněnou bránu řízenou událostmi, dále zde musí být událost pro příjem zprávy o doručení objednávky a mezikroková událost s časovačem, která v druhé větvi procesu hlídá dobu doručení. Všechny události jsou pojmenovány. Nakonec se do procesu umístí i brána pro sloučení rozděleného toku. Pokud nastane situace, že zákazníkovi není jídlo doručeno včas, po vypršení stanovené doby kontaktuje restauraci a dále čeká na svoji objednávku. To znamená, že brána pro sloučení musí být ihned za aktivitou objednávky jídla. Nyní může být provedeno propojení jednotlivých elementů sekvenčními toky. Níže uvedený obrázek je v plné velikosti dostupný v příloze č. 1. Obrázek 27: 1. fáze modelovaného procesu "Objednávka jídla" 6. V další fázi se pokračuje dále podle toku procesu. Po objednávce zákazníka obdrží objednávku restaurace, resp. příjemce objednávek a na základě této události dojde k jejímu zpracování. Je tedy nutné vložit počáteční událost přijmutí zprávy. Následně je objednávka po jejím zpracování předána kuchaři. Zodpovězení dotazu zákazníka na opožděné dodání objednávky provede příjemce reklamací. V případě dotazu zákazníka na dobu doručení objednávky je do plavecké dráhy příjemce reklamací vložena mezikroková příjmová událost zprávy. Za touto událostí následuje uklidnění zákazníka a poté pracovník reklamací objednávek opět čeká na další urgenci. Dle tohoto popisu lze doplnit sekvenční toky. Níže uvedený obrázek je v plné velikosti dostupný v příloze č

67 Obrázek 28: 2. fáze modelovaného procesu "Objednávka jídla" 7. V následujícím kroku je zkompletován zbytek procesu. Kuchař, na základě přijaté objednávky, připraví jídlo a následně ho předá poslíčkovi k doručení. Ten jídlo doručí zákazníkovi, předá účtenku a převezme platbu. Níže uvedený obrázek je v plné velikosti dostupný v příloze č. 3. Obrázek 29: 3. fáze modelovaného procesu "Objednávka jídla" 8. Na závěr jsou doplněny a popsány veškeré datové toky mezi elementy. První datový tok znázorňující provedení objednávky jde od elementu přijetí objednávky k události čekající na příjem zprávy v plavecké dráze příjemce objednávek. Další datové toky znázorňují zpětnou komunikaci mezi zákazníkem a příjemcem reklamací, v případě neobdržení objednávky do stanovené doby. Příchozí tok od zákazníka spouští na straně příjemce reklamací aktivitu uklidnění zákazníka, přičemž na základě toho zákazník obdrží zpět informaci o brzkém dodání. Po doručení objednávky poslíček informuje zákazníka zprávou o doručení. Po převzetí objednávky poslíček předá zákazníkovi účet a převezme platbu za objednávku. Tímto proces pro restauraci končí. Zákazník si doručené jídlo sní a proces je ukončen i z jeho strany. Níže uvedený obrázek je v plné velikosti dostupný v příloze č

68 Obrázek 30: Pohled na celý modelovaný proces "Objednávka jídla" Kontrola modelu Po samotném vymodelování procesu je nutné provést kontrolu modelu. Na výběr je několik možností kontroly, viz. bod 4.3. V našem případě je zvolena kontrola syntaxe modelu včetně dodržení veškerých konvencí a doporučení Check Signavio Best Practices for BPMN 2.0. Po spuštění kontroly jsou získány výsledky s popisem příslušných chyb, varování a také rady, díky kterým je možné model upravit a doplnit o informace potřebné např. při generování dokumentace. U všech dotčených elementů jsou zobrazeny ikony závažnosti chyb. Po umístění kurzoru na ikonu s konkrétní chybou je nedostatek elementu specifikován. Kontrola modelu se u většiny případů provádí průběžně i při samotném modelování procesu. Tím se předejde nepříjemným zjištěním až po vymodelování celého procesu. Při této průběžné kontrole se minimálně používá alespoň kontrola syntaxe, aby byla provedena kontrola konstrukčního řešení modelu, komplexnější kontrola, např. Check Signavio Best Practices for BPMN 2.0. je lepší. 61

69 Při tvorbě modelu nebyly záměrně vyplněny všechny informace z důvodu, aby byla demonstrována samotná kontrola. Obrázek 31: Ukázka výstupu kontroly modelu po kontrole Signavio Best Practices for BPMN Doplnění nalezených nedostatků Na výstupu z kontroly modelu (obr. 31) je vidět, že aktivitám chybí podrobnější dokumentační popis a aktéři procesu nejsou evidováni ve slovníku. Chyby nebo varování model neobsahuje. Pro dosažení úplné procesní dokumentace při následném exportu je nutné tyto informace doplnit. Evidence jednotlivých aktérů (bazénů, včetně plaveckých drah) ve slovníku je provedena pomocí lokálního menu každého elementu, kde je zobrazena příslušná ikona této části. Následně je otevřeno dialogové okno, kde je proveden stručný popis jednotlivých aktérů. Doplnění popisu jednotlivých aktivit lze provést v editoru pomocí panelu atributů. V sekci Main Atrributes se nalézá parametr Documentation, ke kterému je potřeba vždy doplnit podrobnější popis aktivity. Po doplnění těchto nedostatků a opětovné kontrole modelu nástroj již žádné nedostatky nehlásí. Znamená to tedy, že model procesu je dokončen a připraven, např. pro export procesní dokumentace. 62

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování.

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování. 3 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Business modelling, základní nástroje a metody business modelování.

Více

Modelování procesů s využitím MS Visio.

Modelování procesů s využitím MS Visio. Modelování procesů s využitím MS Visio jan.matula@autocont.cz Co je to modelování procesů? Kreslení unifikovaných či standardizovaných symbolů, tvarů a grafů, které graficky znázorňují hlavní, řídící nebo

Více

Objektově orientované technologie Business proces Diagram aktivit. Daniela Szturcová

Objektově orientované technologie Business proces Diagram aktivit. Daniela Szturcová Objektově orientované technologie Business proces Diagram aktivit Daniela Szturcová Osnova Bysnys proces pojmy metody, specifikace pomocí diagramů Modelování pomocí aktivitního diagramu prvky diagramu

Více

Business Process Modeling Notation

Business Process Modeling Notation Business Process Modeling Notation Stephen A. White, IBM Corporation Procesní řízení 1 Co to je BPMN? Standard Business Process Modeling Notation (BPMN) byl vyvinutý skupinou Business Process Management

Více

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika

Informační systémy 2008/2009. Radim Farana. Obsah. UML - charakteristika 2 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Jazyk UML, základní modely, diagramy aktivit, diagramy entit.

Více

Základní informace. Modelování. Notace

Základní informace. Modelování. Notace Základní informace BPMS = business process management systems - systémy pro modelování a optimalizace business procesů uvnitř organizace BPMN = business process modeling notation - součást BPMS, notace

Více

Modelování podnikových procesů

Modelování podnikových procesů Modelování podnikových procesů Co je to podnikový proces? Činnost za účelem splnění určitého podnikového cíle (business goal) Provádění časově ohraničeno Vstupní podmínky Při realizaci probíhají vzájemně

Více

Modelování procesů (1) Procesní řízení 1

Modelování procesů (1) Procesní řízení 1 Modelování procesů (1) Procesní řízení 1 Vizualizace procesů Znázornění procesu ve formě diagramatického modelu, vede k jeho zpřehlednění a snadnějšímu pochopení. Označuje se jako: procesní mapa, procesní

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

Obsah. Zpracoval:

Obsah. Zpracoval: Zpracoval: houzvjir@fel.cvut.cz 03. Modelem řízený vývoj. Doménový (business), konceptuální (analytický) a logický (návrhový) model. Vize projektu. (A7B36SIN) Obsah Modelem řízený vývoj... 2 Cíl MDD, proč

Více

OBSAH 1. ÚVOD STRUKTURA A ÚROVNĚ PROCESNÍHO MODELU KONVENCE PRO MODELOVÁNÍ PROCESŮ KONVENCE PRO MODELOVÁNÍ ORGANIZAČNÍCH STRUK

OBSAH 1. ÚVOD STRUKTURA A ÚROVNĚ PROCESNÍHO MODELU KONVENCE PRO MODELOVÁNÍ PROCESŮ KONVENCE PRO MODELOVÁNÍ ORGANIZAČNÍCH STRUK Konvence procesního modelování v CENIA výtah z metodiky příloha č. 3 soutěžní dokumentace pro výběrové řízení na Integrovaný systém plnění ohlašovacích povinností OBSAH 1. ÚVOD... 4 2. STRUKTURA A ÚROVNĚ

Více

Principy UML. Clear View Training 2005 v2.2 1

Principy UML. Clear View Training 2005 v2.2 1 Principy UML Clear View Training 2005 v2.2 1 1.2 Co je touml? Unified Modelling Language (UML) je univerzálníjazyk pro vizuální modelování systémů Podporuje všechny životní cykly Mohou jej implementovat

Více

UML. Unified Modeling Language. Součásti UML

UML. Unified Modeling Language. Součásti UML UML Unified Modeling Language 1995 počátek 1997 verze 1.0 leden dnes verze 2.0 (vývoj stále nedokončen) Standardní notace OMG podpora velkých firem (Microsoft, IBM, Oracle, HP ) popisuje struktury popisuje

Více

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W UML - opakování I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Co je to UML Evoluce UML Diagram komponent Diagram odbavení Diagram tříd Aktivity diagram Stavový diagram Sekvenční diagram Diagram

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 22. Otázka : Úvodní fáze rozpracování softwarového projektu. Postupy při specifikaci byznys modelů. Specifikace požadavků a jejich rozpracování pomocí

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 24. Otázka : Implementační fáze. Postupy při specifikaci organizace softwarových komponent pomocí UML. Mapování modelů na struktury programovacího

Více

Modelování procesů (2) 23.3.2009 Procesní řízení 1

Modelování procesů (2) 23.3.2009 Procesní řízení 1 Modelování procesů (2) 23.3.2009 Procesní řízení 1 Seznam notací Síťové diagramy Notace WfMC Notace Workflow Together Editor Aktivity diagram (UML) FirsStep Designer Procesní mapa Select Prespective (procesní

Více

4 ARCHITEKTURA PODNIKOVÝCH PROCESŮ S ARISEM

4 ARCHITEKTURA PODNIKOVÝCH PROCESŮ S ARISEM 41 4 ARCHITEKTURA PODNIKOVÝCH PROCESŮ S ARISEM V této kapitole vysvětlíme potřebu strukturované architektury podnikových procesů, a seznámíme se s běžnými typy modelů, používaných v ARISu k reprezentaci

Více

7.6 Další diagramy UML

7.6 Další diagramy UML 7.6 Další diagramy UML 7.6.1 Moduly (balíčky - package) a kolaborace (collaboration) Jak rozložit rozsáhlý systém na menší? - seskupování tříd (prvků modelu) do jednotek vyšší úrovně (package v UML). UI

Více

Vývojové diagramy 1/7

Vývojové diagramy 1/7 Vývojové diagramy 1/7 2 Vývojové diagramy Vývojový diagram je symbolický algoritmický jazyk, který se používá pro názorné zobrazení algoritmu zpracování informací a případnou stručnou publikaci programů.

Více

7.6 Další diagramy UML

7.6 Další diagramy UML 7.6 Další diagramy UML 7.6.1 Moduly (balíčky - package) a kolaborace (collaboration) Jak rozložit rozsáhlý systém na menší? - seskupování tříd (prvků modelu) do jednotek vyšší úrovně (package v UML). UI

Více

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování 1. Teoretické základy modelování na počítačích 1.1 Lambda-kalkul 1.1.1 Formální zápis, beta-redukce, alfa-konverze 1.1.2 Lambda-výraz jako data 1.1.3 Příklad alfa-konverze 1.1.4 Eta-redukce 1.2 Základy

Více

Architektura informačních systémů. - dílčí architektury - strategické řízení taktické řízení. operativní řízení a provozu. Globální architektura

Architektura informačních systémů. - dílčí architektury - strategické řízení taktické řízení. operativní řízení a provozu. Globální architektura Dílčí architektury Informační systémy - dílčí architektury - EIS MIS TPS strategické řízení taktické řízení operativní řízení a provozu 1 Globální Funkční Procesní Datová SW Technologická HW Aplikační

Více

TÉMATICKÝ OKRUH Teorie zpracování dat, Databázové a informační systémy a Teorie informačních systémů

TÉMATICKÝ OKRUH Teorie zpracování dat, Databázové a informační systémy a Teorie informačních systémů TÉMATICKÝ OKRUH Teorie zpracování dat, Databázové a informační systémy a Teorie informačních systémů Číslo otázky : 16. Otázka : Funkční a dynamická analýza informačního systému. Obsah : 1. Úvod 2. Funkční

Více

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken Jazyk UML - přehled Unified Modeling Language jazyk pro popis objektově orientované analýzy a návrhu aplikací slouží k vzájemné komunikaci mezi zadavatelem a návrhářem systému má několik částí, není nutné

Více

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language) 7 Jazyk UML (Unified Modeling Language) 7.1 Základní charakteristika jazyka Motivace - vznik řady OO metod a metodologií (konec 80. let a první polovina 90.let) podobné notace vyjadřující totéž, komplikující

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 03.220.01; 35.240.60 materiálem o normě. Inteligentní dopravní systémy Požadavky na ITS centrální datové

Více

Návrh IS - UML. Jaroslav Žáček

Návrh IS - UML. Jaroslav Žáček Návrh IS - UML Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Trochu historie neuškodí Do roku 1994 chaos ve světě objektově orientovaných metod (několik jazyků pro vizuální modelování,

Více

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language) 7 Jazyk UML (Unified Modeling Language) 7.1 Základní charakteristika jazyka Motivace - vznik řady OO metod a metodologií (konec 80. let a první polovina 90.let) podobné notace vyjadřující totéž, komplikující

Více

U Úvod do modelování a simulace systémů

U Úvod do modelování a simulace systémů U Úvod do modelování a simulace systémů Vyšetřování rozsáhlých soustav mnohdy nelze provádět analytickým výpočtem.často je nutné zkoumat chování zařízení v mezních situacích, do kterých se skutečné zařízení

Více

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz UML a jeho použití v procesu vývoje Jaroslav Žáček jaroslav.zacek@osu.cz Různé pohledy na modelování Různé pohledy na modelování Unified Modeling Language UML není metodikou ani programovacím jazykem,

Více

Návrh IS - UML. Jaroslav Žáček

Návrh IS - UML. Jaroslav Žáček Návrh IS - UML Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ UML UML není metodikou ani programovacím jazykem, je to pouze vizuální modelovací nastroj pro objektově orientované systémy.

Více

Problémové domény a jejich charakteristiky

Problémové domény a jejich charakteristiky Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 02 1/16 Problémové domény a jejich charakteristiky Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta

Více

Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová

Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová Objektově orientované technologie Diagram komponent Implementační náhled (Diagram rozmístění) Pavel Děrgel, Daniela Szturcová Osnova K čemu slouží diagram komponent obsah komponent závislosti rozhraní

Více

CASE. Jaroslav Žáček

CASE. Jaroslav Žáček CASE Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Co znamená CASE? Definice dle SEI A CASE tool is a computer-based product aimed at supporting one or more software engineering activities

Více

Optimalizace podnikových procesů fakultní nemocnice

Optimalizace podnikových procesů fakultní nemocnice Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií Optimalizace podnikových procesů fakultní nemocnice diplomová práce Autor: David Lísal BIVŠ ITMK Informační

Více

Návrh softwarových systémů - architektura softwarových systémů

Návrh softwarových systémů - architektura softwarových systémů Návrh softwarových systémů - architektura softwarových systémů Martin Tomášek, Jiří Šebek Návrh softwarových systémů (B6B36NSS) Převzato z přednášky X36AAS M. Molhanec Co je to architektura Využívá se

Více

CASE nástroje. Jaroslav Žáček

CASE nástroje. Jaroslav Žáček CASE nástroje Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Co znamená CASE? A CASE tool is a computer-based product aimed at supporting one or more software engineering activities within

Více

Objektově orientované technologie Dynamický náhled Sekvenční diagram (Realizace UC) Daniela Szturcová

Objektově orientované technologie Dynamický náhled Sekvenční diagram (Realizace UC) Daniela Szturcová Objektově orientované technologie Dynamický náhled Sekvenční diagram (Realizace UC) Daniela Szturcová Osnova Modelování interakcí mezi objekty modelování zpráv (mapování zpráv na operace), vytváření a

Více

Modelování informačních systémů s využitím jazyka UML. Jaroslav Šmarda

Modelování informačních systémů s využitím jazyka UML. Jaroslav Šmarda Modelování informačních systémů s využitím jazyka UML Jaroslav Šmarda Využití jazyka UML při vývoji IS na příkladu jednoduché aplikace pro evidenci knih Model IS Modelování případů užití Diagram případů

Více

Communist Party of Nepal (Unified Marxist-Leninist) Unified Modeling Language University of Massachusetts Lowell User-mode Linux.

Communist Party of Nepal (Unified Marxist-Leninist) Unified Modeling Language University of Massachusetts Lowell User-mode Linux. Jan Smolík UML UML Communist Party of Nepal (Unified Marxist-Leninist) Unified Modeling Language University of Massachusetts Lowell User-mode Linux Zdroj: Wikipedia Unified modelling language Neproprietární

Více

Využití SysML pro tvorbu modelů v systémovém inženýrství

Využití SysML pro tvorbu modelů v systémovém inženýrství Využití SysML pro tvorbu modelů v systémovém inženýrství Antonín Srna, Ústav informatiky, Provozně ekonomická fakulta, Mendelova univerzita v Brně, xsrna2@mendelu.cz Abstrakt Článek se zaobírá univerzálním

Více

Softwarová podpora v procesním řízení

Softwarová podpora v procesním řízení Softwarová podpora v procesním řízení Zkušenosti z praxe využití software ATTIS Ostrava, 7. října 2010 www.attis.cz ATTN Consulting s.r.o. 1 Obsah Koncepce řízení výkonnosti Koncepce řízení výkonnosti

Více

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Procesy, procesní řízení organizace Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Co nového přináší ISO 9001:2008? Vnímání jednotlivých procesů organizace jako prostředku a nástroje

Více

Vývoj informačních systémů. Přehled témat a úkolů

Vývoj informačních systémů. Přehled témat a úkolů Vývoj informačních systémů Přehled témat a úkolů Organizace výuky doc. Mgr. Miloš Kudělka, Ph.D. EA 439, +420 597 325 877 homel.vsb.cz/~kud007 milos.kudelka@vsb.cz Přednáška Teorie Praxe Cvičení Diskuze

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

PV207. Business Process Management

PV207. Business Process Management PV207 Business Process Management Úvod do BPMN 12. 3. 2009 Petr Vašíček 2007 2009 IBA Group FI MU Obsah přednášky Opakování BPMS Úvod do BPMN Přehled grafických elementů Flow objects Connecting objects

Více

Objektová tvorba SW, Analýza požadavků 2006 UOMO 53

Objektová tvorba SW, Analýza požadavků 2006 UOMO 53 Objektová tvorba SW, Analýza požadavků 2006 UOMO 53 Osnova Základní principy tvorby SW Fáze tvorby SW v předmětu UOMO Analýza požadavků Modelování typových úloh 2006 UOMO 54 Tvorba SW Dříve umění vyvolených

Více

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů.

Modely datové. Další úrovní je logická úroveň Databázové modely Relační, Síťový, Hierarchický. Na fyzické úrovni se jedná o množinu souborů. Modely datové Existují různé úrovně pohledu na data. Nejvyšší úroveň je úroveň, která zachycuje pouze vztahy a struktury dat samotných. Konceptuální model - E-R model. Další úrovní je logická úroveň Databázové

Více

Analýza a modelování dat. Helena Palovská

Analýza a modelování dat. Helena Palovská Analýza a modelování dat Helena Palovská Analýza a modelování pro SW projekt Strukturovaný přístup Dynamická část (procesy, aktivity, funkce) Statická část (data) Objektově orientovaný přístup use case

Více

Komputerizace problémových domén

Komputerizace problémových domén Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 03 1/19 Komputerizace problémových domén Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta informačních

Více

Obsah. ÚVOD 1 Poděkování 3

Obsah. ÚVOD 1 Poděkování 3 ÚVOD 1 Poděkování 3 Kapitola 1 CO JE TO PROCES? 5 Co všechno musíme vědět o procesním řízení, abychom ho mohli zavést 6 Různá důležitost procesů 13 Strategické plánování 16 Provedení strategické analýzy

Více

1. Dědičnost a polymorfismus

1. Dědičnost a polymorfismus 1. Dědičnost a polymorfismus Cíl látky Cílem této kapitoly je představit klíčové pojmy dědičnosti a polymorfismu. Předtím však je nutné se seznámit se základními pojmy zobecnění neboli generalizace. Komentář

Více

Česká zemědělská univerzita v Praze. Provozně ekonomická fakulta. Katedra informačních technologií

Česká zemědělská univerzita v Praze. Provozně ekonomická fakulta. Katedra informačních technologií Česká zemědělská univerzita v Praze Provozně ekonomická fakulta Katedra informačních technologií Teze diplomové práce Analýza a návrh informačního systému Miloš Rajdl 2012 ČZU v Praze 1 Souhrn Diplomová

Více

3 druhy UML diagramů

3 druhy UML diagramů UML grafický jazyk se pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů zjednodušuje komunikaci mezi zadavatelem a řešitelem projektu UML podporuje objektově orientovaný přístup

Více

Pokročilé typové úlohy a scénáře 2006 UOMO 71

Pokročilé typové úlohy a scénáře 2006 UOMO 71 Pokročilé typové úlohy a scénáře 2006 UOMO 71 Osnova Interní model typové úlohy Vazby include a extend Provázanost typových úloh na firemní procesy a objekty Nejčastější chyby 2006 UOMO 72 Interní model

Více

Návrh softwarových systémů - architektura softwarových systémů

Návrh softwarových systémů - architektura softwarových systémů Návrh softwarových systémů - architektura softwarových systémů Jiří Šebek Návrh softwarových systémů (B6B36NSS) Převzato z přednášky X36AAS M. Molhanec Co je to architektura 2 Využívá se v různách oborech

Více

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce WORKFLOW Procesní přístup Základ perspektivního úspěšného podnikového řízení Funkčnířízení založené na dělbě práce Procesní řízení princip integrace činností do ucelených procesů 1 Funkční řízení Dělba

Více

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

X36SIN: Softwarové inženýrství. Životní cyklus a plánování X36SIN: Softwarové inženýrství Životní cyklus a plánování 1 Kontext Minule jsme si řekli, co to je deklarace záměru, odborný článek, katalog požadavků, seznam aktérů a seznam událostí. Seznam aktérů a

Více

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda 1. Lze vždy z tzv. instanční třídy vytvořit objekt? 2. Co je nejčastější příčinou vzniku chyb? A. Specifikace B. Testování C. Návrh D. Analýza E. Kódování 3. Je defenzivní programování technikou skrývání

Více

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Osnova přednášky Co to je softwarové inženýrství Softwarový proces Metodika a metoda Evoluce softwarových

Více

ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ PODLE ÚROVNĚ ŘÍZENÍ

ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ PODLE ÚROVNĚ ŘÍZENÍ ARCHITEKTURA INFORMAČNÍCH SYSTÉMŮ PODLE ÚROVNĚ ŘÍZENÍ Podle toho, zda informační systém funguje na operativní, taktické nebo strategické řídicí úrovni, můžeme systémy rozdělit do skupin. Tuto pyramidu

Více

Vývoj informačních systémů. Přehled témat a úkolů

Vývoj informačních systémů. Přehled témat a úkolů Vývoj informačních systémů Přehled témat a úkolů Organizace výuky doc. Mgr. Miloš Kudělka, Ph.D. EA 439, +420 597 325 877 homel.vsb.cz/~kud007 milos.kudelka@vsb.cz Přednáška Znalosti Schopnosti Cvičení

Více

komplexní podpora zvyšování výkonnosti strana 1 Využití Referenčního modelu integrovaného systému řízení veřejnoprávní korporace Město Hořovice

komplexní podpora zvyšování výkonnosti strana 1 Využití Referenčního modelu integrovaného systému řízení veřejnoprávní korporace Město Hořovice strana 1 Využití Referenčního modelu integrovaného systému řízení veřejnoprávní korporace Město Hořovice 19.3.2018 Zpracoval: Roman Fišer, strana 2 1. ÚVOD... 3 2. POPIS REFERENČNÍHO MODELU INTEGROVANÉHO

Více

Informační systémy 2008/2009. Radim Farana. Obsah. Obsah předmětu. Požadavky kreditového systému. Relační datový model, Architektury databází

Informační systémy 2008/2009. Radim Farana. Obsah. Obsah předmětu. Požadavky kreditového systému. Relační datový model, Architektury databází 1 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Požadavky kreditového systému. Relační datový model, relace, atributy,

Více

OOT Objektově orientované technologie

OOT Objektově orientované technologie OOT Objektově orientované technologie Požadavky a případy užití Daniela Szturcová Institut geoinformatiky, HGF Osnova Systém Uživatelé Případy užití Vazby (asociace, generalizace, include a extend) Shrnutí

Více

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

SOFTWAROVÁ PODPORA TVORBY PROJEKTŮ

SOFTWAROVÁ PODPORA TVORBY PROJEKTŮ Slezská univerzita v Opavě Obchodně podnikatelská fakulta v Karviné SOFTWAROVÁ PODPORA TVORBY PROJEKTŮ Distanční studijní opora Karel Skokan František Huňka Karviná 2012 Projekt OP VK 2.2 (CZ.1.07/2.2.00/15.0176)

Více

UML úvod. Zdroje: Kanisová Hana, Müller Miroslav: UML srozumitelně, Computer Press 2007

UML úvod. Zdroje: Kanisová Hana, Müller Miroslav: UML srozumitelně, Computer Press 2007 UML úvod Kapitola má seznámit se základy modelovacího jazyka UML. Klíčové pojmy: UML, CASE nástroje, procesní modelování, případy užití, role, diagram tříd, diagram objektů, sekvenční diagramy, digram

Více

Objekty, třídy, vazby 2006 UOMO 30

Objekty, třídy, vazby 2006 UOMO 30 Objekty, třídy, vazby 2006 UOMO 30 Osnova Vymezení pojmu objekt Objekt a základní objektové koncepty Třídy, třída vs. objekt Vztahy mezi objekty, vazby mezi třídami Polymorfismus 2006 UOMO 31 Vymezení

Více

Globální strategie, IT strategie, podnikové procesy. Jaroslav Žáček

Globální strategie, IT strategie, podnikové procesy. Jaroslav Žáček Globální strategie, IT strategie, podnikové procesy Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Globální podniková strategie Co budeme dělat? Jak to budeme dělat? Jak využijeme IT systémy?

Více

METODY BYZNYS MODELOVÁNÍ

METODY BYZNYS MODELOVÁNÍ Vysoká škola báňská - Technická univerzita Ostrava Fakulta elektrotechniky a informatiky METODY BYZNYS MODELOVÁNÍ pro kombinované a distanční studium Prof. Ing. Ivo Vondrák, CSc. Ostrava 2004 Ivo Vondrák,

Více

OOT Objektově orientované technologie

OOT Objektově orientované technologie OOT Objektově orientované technologie Požadavky a případy užití Daniela Szturcová, Pavel Děrgel Institut geoinformatiky, HGF Osnova Systém Uživatelé Případy užití Vazby (asociace, generalizace, include

Více

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz RUP - Disciplíny Jaroslav Žáček jaroslav.zacek@osu.cz Disciplíny Množství disciplíny v dané iteraci Disciplíny podle RUP Šest základních: Business modeling - pro pochopení problémové domény Requirements

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

Teorie systémů TES 5. Znalostní systémy KMS

Teorie systémů TES 5. Znalostní systémy KMS Evropský sociální fond. Praha & EU: Investujeme do vaší budoucnosti. Teorie systémů TES 5. Znalostní systémy KMS ZS 2011/2012 prof. Ing. Petr Moos, CSc. Ústav informatiky a telekomunikací Fakulta dopravní

Více

Kapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů

Kapitola 1: Úvod. Systém pro správu databáze (Database Management Systém DBMS) Účel databázových systémů - 1.1 - Kapitola 1: Úvod Účel databázových systémů Pohled na data Modely dat Jazyk pro definici dat (Data Definition Language; DDL) Jazyk pro manipulaci s daty (Data Manipulation Language; DML) Správa

Více

Jak správně psát scénáře k případům užití?

Jak správně psát scénáře k případům užití? Jak správně psát scénáře k případům užití? Autor RNDr. Ilja Kraval 2007 http://www.objects.cz K napsání tohoto článku mne inspiroval tento mail: Dobrý den pane Kravale, chci Vás poprosit o radu, která

Více

1. Integrační koncept

1. Integrační koncept Příloha č. 2: Technický popis integrace 1. Integrační koncept Z hlediska koncepčního budování Smart Administration na Magistrátu města Mostu je možno hovořit o potřebě integrace tří úrovní systémové architektury

Více

ČESKÉ VYSOKÉ UČENÍ TECHNIKÉ Fakulta elektrotechnická. Microsoft Sharepoint 2007 Workflows Průmyslové informační systémy

ČESKÉ VYSOKÉ UČENÍ TECHNIKÉ Fakulta elektrotechnická. Microsoft Sharepoint 2007 Workflows Průmyslové informační systémy ČESKÉ VYSOKÉ UČENÍ TECHNIKÉ Fakulta elektrotechnická Microsoft Sharepoint 2007 Workflows Průmyslové informační systémy Bc. Petr Pokorný Letní semestr 2009/2010 1 Obsah 1 Úvod... 3 2 Workflow... 3 3 Workflow

Více

OOT Objektově orientované technologie

OOT Objektově orientované technologie OOT Objektově orientované technologie Logická struktura systému (Diagram tříd) Daniela Szturcová Institut geoinformatiky, HGF Osnova Třídy Statický pohled na systém Atributy a operace, řízení přístupu

Více

UML: Unified Modeling Language

UML: Unified Modeling Language UML 1 UML: Unified Modeling Language Systém kombinace softwaru, hardwaru, dat a uživatelů, která umožňuje řešení konkrétního problému Vývoj systémů vytváření systémů pro klienta Vývoj probíhá na základě

Více

GIS Libereckého kraje

GIS Libereckého kraje Funkční rámec Zpracoval: Odbor informatiky květen 2004 Obsah 1. ÚVOD...3 1.1. Vztah GIS a IS... 3 2. ANALÝZA SOUČASNÉHO STAVU...3 2.1. Technické zázemí... 3 2.2. Personální zázemí... 3 2.3. Datová základna...

Více

Modelování webových služeb v UML

Modelování webových služeb v UML Modelování webových služeb v UML Jaromír Šveřepa LBMS, s.r.o. Abstrakt: Tento příspěvek se zaměřuje na praktický postup pro identifikaci potřeby webové služby, modelování způsobu jejího použití, popřípadě

Více

6 Objektově-orientovaný vývoj programového vybavení

6 Objektově-orientovaný vývoj programového vybavení 6 Objektově-orientovaný vývoj programového vybavení 6.1 Co značí objektově-orientovaný - organizace SW jako kolekce diskrétních objektů, které zahrnují jak data tak chování objekt: OMG: Objekt je věc (thing).

Více

Řízení projektů. Centrální podpora projektového řízení projektů realizovaných MVČR (CEPR) Praha,

Řízení projektů. Centrální podpora projektového řízení projektů realizovaných MVČR (CEPR) Praha, Řízení projektů Centrální podpora projektového řízení projektů realizovaných MVČR (CEPR) Praha, 6. 12. 2012 Představení Zpracovatel: SOFO Group a.s. Ovocný trh 572/11 Praha 1 Projektový tým zpracovatele:

Více

1. Webové služby. K čemu slouží? 2. RPC Web Service. 3. SOA Web Service. 4. RESTful Web services

1. Webové služby. K čemu slouží? 2. RPC Web Service. 3. SOA Web Service. 4. RESTful Web services 13. Webové služby. K čemu slouží? Popis a vyhledávání služeb. Co je a k čemu slouží orchestrace a choreografie služeb. Technologie pro implementaci služeb 1. Webové služby. K čemu slouží? Definice WS -

Více

PROCESNÍ ANALÝZA Fáze III. Metodická příručka pro řízení procesů

PROCESNÍ ANALÝZA Fáze III. Metodická příručka pro řízení procesů PROCESNÍ ANALÝZA Fáze III. Metodická příručka pro řízení procesů Zadavatel: Město Tišnov Datum vytvoření: 13. 12. 2010 Zpra Projekt Nastavení systému projektového a procesního řízení na MěÚ Tišnov r. č.

Více

Procesní dokumentace Process Management. Pavel Čejka

Procesní dokumentace Process Management. Pavel Čejka Procesní dokumentace Process Management Pavel Čejka SAP Solution Manager 7.2 SAP Solution Manager 7.2 nabízí dramatické zlepšení možností dokumentace Solution dokumentace Jednotné webové prostředí Integrovaný

Více

Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a přiřazení datových modelů

Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a přiřazení datových modelů Pracovní celky 3.2, 3.3 a 3.4 Sémantická harmonizace - Srovnání a datových modelů Obsah Seznam tabulek... 1 Seznam obrázků... 1 1 Úvod... 2 2 Metody sémantické harmonizace... 2 3 Dvojjazyčné katalogy objektů

Více

MOŢNOSTI VYUŢITÍ ROLÍ, AKTORŮ A AGENTŮ PŘI DESIGNU BYZNYS PROCESŮ

MOŢNOSTI VYUŢITÍ ROLÍ, AKTORŮ A AGENTŮ PŘI DESIGNU BYZNYS PROCESŮ MOŢNOSTI VYUŢITÍ ROLÍ, AKTORŮ A AGENTŮ PŘI DESIGNU BYZNYS PROCESŮ Ing. Jan Smolík Vysoká škola finanční a správní PROČ JINÝ ZPŮSOB MODELOVÁNÍ PROCESŮ Základní žurnalistické otázky Co, kdo, kdy, kde, jak,

Více

Úloha 1. Úloha 2. Úloha 3. Text úlohy. Text úlohy. Text úlohy

Úloha 1. Úloha 2. Úloha 3. Text úlohy. Text úlohy. Text úlohy Úloha 1 Zkratka ERP jako celopodniková transakční aplikace znamená: a. Enterprise Route Planning b. Enterprise Resource Planning c. Enterprise Re-implementation Planning d. Enterprise Resource Processing

Více

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ

MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ MATURITNÍ OTÁZKY ELEKTROTECHNIKA - POČÍTAČOVÉ SYSTÉMY 2003/2004 PROGRAMOVÉ VYBAVENÍ POČÍTAČŮ 1) PROGRAM, ZDROJOVÝ KÓD, PŘEKLAD PROGRAMU 3 2) HISTORIE TVORBY PROGRAMŮ 3 3) SYNTAXE A SÉMANTIKA 3 4) SPECIFIKACE

Více

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/

Architektury Informačních systémů. Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Architektury Informačních systémů Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Nutné pojmy Co je to informační systém? Jaké oblasti zahrnuje? Jaká je vazba IS na podnikovou strategii?

Více

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu

VÝUKOVÝ MATERIÁL. Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632 Číslo projektu VÝUKOVÝ MATERIÁL Identifikační údaje školy Vyšší odborná škola a Střední škola, Varnsdorf, příspěvková organizace Bratislavská 2166, 407 47 Varnsdorf, IČO: 18383874 www.vosassvdf.cz, tel. +420412372632

Více

Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky

Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky Univerzita Pardubice Fakulta ekonomicko-správní Ústav systémového inženýrství a informatiky Datová podpora na úrovni kontaktního pracoviště Úřadu práce pro státní sociální podporu Josef Hájek Bakalářská

Více

Vývoj IS - strukturované paradigma II

Vývoj IS - strukturované paradigma II Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 05 1/18 Vývoj IS - strukturované paradigma II Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta informačních

Více

Metodika analýzy. Příloha č. 1

Metodika analýzy. Příloha č. 1 Metodika analýzy Příloha č. 1 Příloha č. 1 1 Účel dokumentu Dokument popisuje závaznou metodiku systémové analýzy, je upraven na míru pro prostředí Podniku. Dokument je provázán s Podnikovou analýzou,

Více