Požadované znalosti ke zkoušce

Role modelování ve vývoji informačního systému, modelování business procesů, modelování business objektů, konsistenční souvislosti modelu procesů a objektů, funkčnost informačního systému a jeho role v procesně řízené organizaci, podnikové architektuře a digitální transformaci alias zarovnání businessu s IT.

Téma této kapitoly

Role modelování ve vývoji informačního systému

Souhrn skript

Informační modelování organizací (4IT415)

Obsah

  1. Úvod do předmětu
  2. Globální procesní mapa
  3. Diagram tříd
  4. Diagram životního cyklu objektu
  5. Detailní diagram procesu
  6. Model funkcí informačního systému (DFD)
  7. Konzistence diagramů
  8. Specifika modelovacích jazyků
  9. Business Process Management System (BPMS)

1. Úvod do předmětu

Cíl kurzu

  • Osvojení si ucelené metodiky analýzy
    • Modelovací techniky: procesní a objektový model, funkční model
    • Modelovací standardy: BPMN, TOGAF/ArchiMate, UML, DFD
  • Vyzkoušet si práci s CASE nástrojem

Obsah přednášek

  • Užití modelů (procesů a jiných)
    • Řízení výkonnosti, Podniková architektura, vývoj SW
  • Představení komplexních přístupů k modelování reality (ARIS, TOGAF/ArchiMate, MMABP)
  • MMABP – minimální business architektura
    • Analytický postup
    • TOGAF event diagram
    • BPMN
    • UML: class, state machine
    • Strukturovaná analýza: data flow diagram
  • Přehled modelovacích jazyků: BPMN, UML, ArchiMate, EPC

Co je model?

Model je abstrakce reality založená na předpokladech.

Model musí být:

  • Formální
  • Úplný
  • Věrný
  • Jednoznačný
  • Jednoduchý na pochopení a užití

Důležité: Model není sám o sobě cílem, model není skutečnost a model se obvykle vytváří pro opakující se jevy.

Princip tří architektur

Realita → Model reality → Technologický model → Implementační model → Implementovaný systém

Potřeba rozlišovat:

  • Přirozené vlastnosti objektů/procesů
  • Vlastnosti objektů/procesů dané konkrétními podmínkami použité technologie a implementačního prostředí

Systém

Skupina interagujících, vzájemně propojených nebo vzájemně závislých prvků tvořících komplexní celek.

Využití business modelování

  • Analýza při zavádění/změně informačních technologií a procesů
  • CPM – Corporate Performance Management (ABC, TDABC, VBM, SixSigma, BSC)
  • Podniková architektura (EA)

Proč procesní řízení?

Procesní přístup se zaměřuje na:

  • Účinnost a účelnost
  • Chování za určitým účelem
  • Zpětnou vazbu

Faktory činnosti podniku:

  • Primární funkce → Podnikové procesy
  • Sekundární funkce → Informační systém
  • Terciární funkce → Informační technologie

MMABP - Methodology for Modeling and Analysis of Business Processes

Princip modelování

Objektivním základem implementace informačního systému musí být reálný svět: reálná fakta, existující mimo organizaci (a nezávisle na ní).

  • Model objektů jako souhrn atributů – kritických faktorů
  • Model procesů jako souhrn reakcí na změny kritických faktorů (události)

Princip abstrakce

Veškerá podstatná fakta jsou analyzována do detailu a detaily abstrahovány do celků s použitím hierarchických abstrakcí:

  • Celek - část (proces - subproces)
  • Typ – pod-typ (hierarchie tříd, dědičnost)

Dvě základní dimenze modelu reality

DimenzeProcesní pohledObjektový pohled
Záměr (Chování reálného světa)Modelování systému business procesů (Procesní mapa)Modelování struktury procesů (BPMN)
Kauzalita a Modalita (Ontologie reálného světa)Modelování konceptů (Diagram tříd)Modelování životních cyklů objektů (Stavový diagram)

2. Globální procesní mapa

Úvod

Globální procesní mapa je jedním ze 4 základních diagramů, se kterým se procesní analýza zpravidla začíná. Hlavním cílem procesní mapy je identifikace systému business procesů a tím vymezení, co má být předmětem analýzy.

Globální procesní mapa mapuje systém business procesů a zachycuje:

  • Business procesy, jaké události je spouští, jaký je jejich cílový výstup a do které business funkce podniku patří
  • Jak business procesy kooperují, jak se synchronizují - co který proces spouští a jakou zpětnou vazbu jednotlivé business procesy očekávají od ostatních procesů

Jako nástroj pro zachycení procesní mapy používáme TOGAF Event Diagram v notaci odvozené od ArchiMate.

Elementy procesní mapy

SymbolPopis
Business funkceSeskupení business procesů podniku do logického celku, který poskytuje jednu ze schopností, které umožňují podniku naplňovat své cíle.
Business procesSérie činností businessu záměrně usilující o vytvoření cílového výstupu (produktu nebo služby), který je podstatný pro uspokojení konkrétních potřeb zákazníka procesu. Pokrývá celý cyklus vedoucí k řešení potřeby zákazníka - od jejího vyjádření až po uspokojení realizovanou službou či produktem (E2E).
Spouštěcí událostVýznamná změna přicházející z okolí business procesu v konkrétní moment, která je důvodem pro spuštění daného business procesu. Změny mohou být: ad-hoc změna business objektu nebo uplynutí času.
Cílový stav procesuBusiness objekt v takovém stavu svého životního cyklu, který značí uspokojení specifických potřeb zákazníka procesu.
Aktivační vazbaVazba business procesu na spouštěcí události nebo cílové stavy procesu.

Business proces a úrovně jeho abstrakce

MMABP specifikuje 4 úrovně abstrakce procesu:

  1. Business funkce (nejvyšší úroveň)
  2. Business proces
  3. Procesní krok
  4. Úloha (nejnižší úroveň)

Role procesů

MMABP rozlišuje dvě role business procesů:

  • Klíčový proces - svázán přímo se zákazníkem businessu a pokrývá celý business cyklus vedoucí k řešení zákazníkovy potřeby
  • Podpůrný proces - podporuje jiný business proces (klíčový nebo podpůrný) svým cílovým výstupem

Typy podpory (synchronizace procesů)

Procesní mapa umožňuje zachytit 3 typy kooperace mezi procesy:

  1. Přímá podpora na vyžádání
  2. Nepřímá podpora přes sdílené zdroje
  3. Kombinace obou typů

Pravidla pro tvorbu procesní mapy

  • Diagram obsahuje pouze definované prvky: business procesy, spouštěcí události, cílové stavy, business funkce a aktivační toky
  • Každý business proces má minimálně jednu spouštěcí událost a právě jeden cílový stav
  • Business procesy jsou pojmenovány jako činnost vedoucí k cílovému stavu procesu
  • Každý business proces je součástí maximálně jedné business funkce
  • Business funkce se obsahově nepřekrývají a ani neduplikují
  • V diagramu jsou zahrnuty i outsourcované business procesy
  • Každý klíčový proces má alespoň jeden podpůrný

Postup tvorby procesní mapy

  1. Identifikujte všechny relevantní zákazníky podniku
  2. Identifikujte klíčové procesy, které potřeby zákazníků uspokojují
  3. Identifikujte business funkce, které jsou přímo zodpovědné za uspokojování potřeb zákazníků
  4. Identifikujte podpůrné business funkce
  5. Identifikujte podpůrné procesy - hledejte kritické milníky, které představují významné body na cestě uspokojení potřeby zákazníka
  6. Identifikujte podpůrné procesy podpůrných procesů až na úroveň elementárních podpůrných procesů
  7. Identifikujte business procesy, které realizují identifikované podpůrné business funkce
  8. Opakujte pro všechny elementární podpůrné procesy

3. Diagram tříd

Úvod

Diagram tříd je druhým globálním modelem, který slouží k zachycení struktury reality. Vyjadřuje typy objektů (třídy) reálného světa a jejich základní vztahy.

Primárním cílem tvorby modelu tříd z hlediska business analýzy je pochopit realitu businessu a pojmy používané lidmi, kteří daný business tvoří.

Jako nástroj pro zachycení diagramu tříd používáme UML Class Diagram.

Elementy diagramu tříd

SymbolPopis
TřídaPojem, který představuje množinu objektů (možných instancí třídy), které mají stejný význam a sdílejí stejné vlastnosti (atributy a operace).
GeneralizaceVztah mezi obecnější a specifičtější třídou, základní klasifikace tříd objektů.
AsociaceMožnost obecného vztahu mezi objekty dvou různých tříd nebo stejné třídy.
Agregace a kompoziceZvláštní případ asociace, která znamená “skládá se z” a liší se silou vazby.

Základní pojmy

  • Objekt - entita s jasně definovanými hranicemi a identitou, která si v sobě nese stav a potenciální dynamiku
  • Třída - koncept popisující množinu objektů se stejným významem a vlastnostmi
  • Atribut - vlastnost třídy představující podstatnou charakteristiku třídy
  • Operace - vlastnost třídy popisující potenciální dynamiku objektů třídy

Agregace vs. Kompozice

  • Agregace (slabá vazba) - seskupené objekty mohou existovat samostatně bez agregujícího objektu, jeden objekt může být v jednom okamžiku konstituentem více seskupení
  • Kompozice (silná vazba) - seskupené objekty mohou existovat pouze v dané kompozici, objekt komponenty může být v jakýkoliv okamžik součástí jen jedné kompozice

Generalizace

Vztah mezi obecnější a specifičtější třídou:

  • Ve směru od specifičtější třídy k obecnější = zobecnění
  • Ve směru od obecnější třídy ke specifičtější = specializace

Specializace mohou označovat i fáze vývoje (dynamická specializace).

Pravidlo: Všude tam, kde se nabízí použít atribut „typ …”, signalizuje specializaci.

Asociace

  • Oba konce asociace musí mít určenou mohutnost (kardinalitu)
  • Role jednotlivých tříd v asociaci dávají vztahům význam
  • Asociační třída se používá, když má asociace vlastní atributy, operace nebo vztahy

Pravidla pro tvorbu diagramu tříd

  • Všechny třídy jsou pojmenovány buďto jako zobecnění konkrétních objektů nebo zobecnění konkrétních tříd
  • Agregace/kompozice je použita pouze tam, kde k agregaci skutečně dochází
  • Rozdělení objektů na typy je řešeno přes specializace/role, nikoliv přes atribut „typ…”
  • Každá vazba má uvedenu správnou mohutnost na obou koncích
  • Žádná z vazeb není oboustranně povinná
  • Třída neobsahuje jako atributy žádné umělé identifikátory/klíče
  • Zachycení společné podstaty je řešeno generalizací, nikoliv duplicitou

Postup tvorby diagramu tříd

  1. Identifikujte objekty - z událostí, cílových stavů, business partnerů, zdrojů, stavů procesu, podmínek větvení
  2. Identifikujte třídy - na základě identifikovaných objektů
  3. Identifikujte generalizace - skupiny tříd se společnou podstatou
  4. Zkompletujte generalizace - zkontrolujte kompletnost specializací
  5. Identifikujte asociace - mezi třídami
  6. Určete mohutnost identifikovaných asociací
  7. Specifikujte agregace a kompozice
  8. Identifikujte třídy představující role
  9. Zkompletujte sady rolí
  10. Identifikujte role v asociacích
  11. Specifikujte atributy třídy
  12. Identifikujte strukturální operace třídy

4. Diagram životního cyklu objektu

Úvod

Diagram životního cyklu objektu je detailním diagramem objektového pohledu a slouží k popisu systému business pravidel zachycující podstatné stavy objektů pro daný business a důvody přechodů mezi nimi (kauzality business systému).

Na rozdíl od detailních diagramů business procesů se jedná o popis obecně platných pravidel platících pro jednotlivé třídy objektů, nikoliv o popis úmyslného chování směřujícího k nějakému cíli.

Životní cykly zachycujeme ve stavovém diagramu v podobě standardního UML State Machine Diagram.

Kdy modelovat životní cyklus

Modelují se ty životní cykly tříd objektů, které jsou pro modelovaný business systém podstatné:

  • Třídy objektů, jejichž stav ovlivňuje, které úlohy v procesu budou vykonány
  • Objekty spojené s událostmi a podmínkami větvení v modelech business procesů
  • Objekty, jejichž stavy jsou svázány s jednotlivými úlohami v procesu

Elementy diagramu životního cyklu

SymbolPopis
Startovací bodBod v čase, ve kterém nastala příčina vzniku objektu.
Stav objektuDosažení milníku v životě objektu, který je pro business podstatný. Objekt v daném stavu setrvává, dokud nenastane důvod pro přechod.
Přechod mezi stavyDefinuje důvod (událost nebo podmínka), který musí nastat pro vykonání operace a změnu stavu objektu.

Pravidla pro životní cyklus

  • Životní cyklus zachycuje celý život objektu - od vzniku až po zánik
  • Objekt může být v rámci jednoho životního cyklu jen v jednom elementárním stavu
  • Z každého stavu (kromě koncových) existují přechody alespoň do dvou jiných stavů
  • U každého stavu (kromě koncových) musí být zajištěno, že alespoň jeden z přechodů nastane (pozor na deadlock!)
  • Přechody se zachycují jako: důvod / operace()
  • Důvod může být událost nebo podmínka

Důležité poznámky

  • Nesprávná definice důvodu: Pokud by podmínka přechodu byla ihned splněna po dosažení stavu, stav by byl redundantní
  • Přechody neměnící stav: Některé operace mění pouze hodnoty atributů nebo vytváří vazby, ale stav objektu zůstává stejný
  • Reference mezi životními cykly: Vztahy mezi životními cykly různých objektů lze zachytit referencí v podmínce přechodu
  • Deadlock: Vždy zvažte časovanou podmínku přechodu

Postup tvorby (analýza existujícího businessu)

  1. Identifikujte podstatné třídy objektů - začněte s objekty z procesní mapy
  2. Určete, kdy objekty vznikají - co způsobuje vznik a jaký je výchozí stav
  3. Zmapujte reakce objektu na události nebo změnu podmínek - pro každý stav určete možné změny
  4. Iterativně aplikujte dokud neurčíte všechny stavy včetně koncových
  5. Zkompletujte přechody týkající se struktury objektu
  6. Revidujte při změně ostatních modelů

Pravidla konzistence

  • Každá vazba 1:N v diagramu tříd má odraz v iterativním cyklu v životním cyklu
  • Každá parciální vazba (0..1, 0..n) má odraz v alternativních přechodech
  • Operace v přechodech musí korespondovat s operacemi třídy
  • Atributy a vazby v podmínkách musí existovat v diagramu tříd

5. Detailní diagram procesu

Úvod

Detailní procesní diagramy představují detailní pohled na business procesy specifikované v procesní mapě. Zachycují na cíl orientované úmyslné chování a skládají se z dvou úrovní detailu:

  1. Úroveň procesních kroků - popis business procesu z pohledu synchronizace jeho běhu se svým okolím
  2. Úroveň úloh - popis řetězce konkrétních úloh pro dosažení cílového stavu

Pro zachycení detailu procesu používáme standard BPMN.

Elementy detailního procesního diagramu

SymbolPopis
Procesní krokŘetězec úloh business procesu, který je možné provést celý bez přerušení.
ÚlohaJasně vymezená činnost, jejíž provedení mění podstatný stav jednoho významného objektu.
Průběžný stav procesuMísto v procesu kde se čeká na událost, která rozhodne o dalším směru.
Koncový stav procesuMísto v procesu, ve kterém zpracování končí.
UdálostVýznamná změna přicházející z okolí business procesu (ad-hoc nebo časovaná).
Datový objektOdkaz na třídu objektů nebo stav objektu z jeho životního cyklu.
Logické brányUmožňují rozdělovat a spojovat toky zpracování (XOR, OR, AND).
Sekvenční tokSpojuje elementy a stanovuje pořadí zpracování.

Stavy procesu

Stav procesu je místo v procesu, kde:

  • Zpracování bylo dokončeno (vše co šlo)
  • Nyní se čeká na potřebný vstup z vnějšku business procesu

Stav procesu pojmenujeme podle stavu významného objektu, který nejlépe vystihuje situaci.

Vzor pro synchronizaci

Stavy procesu jsou specifickým návrhovým vzorem metody MMABP:

  1. Procesní krok vede ke stavu procesu
  2. Ve stavu procesu se čeká na události (včetně časové události jako pojistky proti deadlocku)
  3. Po události následuje další procesní krok nebo konec

Úloha

  • Jasně vymezená činnost měnící podstatný stav jednoho významného objektu
  • Jedna úloha = jeden cíl (mění stav pouze jednoho objektu)
  • Výjimka: alternativní konce/cíle úlohy
  • Pokud procesní krok obsahuje jen jednu úlohu, vloží se úloha rovnou do diagramu

Logické brány

Pravidla kombinací:

  • XOR dělící → XOR slučující
  • AND dělící → AND slučující
  • OR dělící → OR slučující

Nelze kombinovat např. XOR dělící s AND slučující!

Rozhodování - čtyři možné vstupy

  1. Stav objektu
  2. Hodnota atributu objektu
  3. Existence vazby mezi objekty
  4. Kombinace výše uvedených

Pravidla pro tvorbu detailního diagramu

  • Detail obsahuje jen cílené, záměrné činnosti modelovaného business systému
  • Každá úloha má asociovaný právě jeden stav objektu (výstup)
  • Synchronizace je zachycena jako stav procesu, kde se čeká na události
  • Subprocesy nemají smysl - procesy se synchronizují přes stavy
  • Jsou dodržena pravidla logických bran
  • Hrozící deadlock je ošetřen časovou událostí
  • U každého rozhodnutí jsou uvedeny podmínky pro každou cestu

Kontext v procesním diagramu

Méně je více! Kontext (role, org. jednotky, vstupy/výstupy) nijak neovlivňuje průběh procesu.

  • Role/organizační jednotky - lepší jako atribut úlohy než plavecké dráhy
  • Vstupy/výstupy - systematická analýza musí proběhnout na úrovni operací, ne úloh

Postup tvorby (design nového businessu)

  1. Určete hranice business procesů - spouštěcí události a cílový stav z procesní mapy
  2. Identifikujte všechny koncové stavy procesu
  3. Mapujte aktivity krok za krokem - procesní krok = série úloh bez přerušení
  4. Doplňte alternativní události u každého stavu procesu
  5. Rozdělte tok dle reakcí na identifikované události
  6. Postupně zachyťte celý diagram až ke všem koncovým stavům

6. Model funkcí informačního systému (DFD)

Úvod

Model business systému pracuje na úrovni úloh, zatímco objektový model pracuje na úrovni operací. Vstupy a výstupy jedné úlohy jsou vstupy a výstupy operací prováděných v rámci úlohy.

Pro systematickou analýzu vstupů a výstupů je třeba pracovat na úrovni operací. K tomu slouží Data Flow Diagram (DFD).

Cíle informační analýzy

Popsat funkčnost informačního systému jako celku, bez ohledu na to, co pak bude skutečně podpořeno ICT. Zahrnuje všechny informační toky - digitální, papírové i slovní.

DFD jako nástroj

  • Identifikace operací prováděných v rámci úlohy
  • Identifikace vstupů a výstupů operací
  • Rozlišení informačních a materiálních operací
  • Identifikace a kompletizace operací a atributů opomenutých v modelu business systému

Symboly DFD

SymbolPopis
FunkceAkce informačního systému manipulující s daty nebo je transformující.
TerminátorHraniční prvek mimo modelovaný systém (další IS, uživatelé, fyzické činnosti).
Datový tokTok dat s definovanou strukturou. Představuje přímé předání dat.
Data StoreUložiště dat, ze kterého funkce mohou načítat a zapisovat data.

Základní vzor

Událost → [Datový tok od Terminátoru/Funkce] → Funkce → [Datový tok] → Data Store/Terminátor

Důležité: Datový tok z Data Store nemůže spustit funkci - ta musí být spuštěna přímým tokem od terminátoru nebo funkce.

Pravidla pro DFD

  • Terminátory nepřistupují přímo k Data Storům
  • Funkce nemohou existovat bez vstupů a výstupů
  • Hierarchická konzistence - vstupy/výstupy agregovaných funkcí = vstupy/výstupy nadřazené funkce

Fyzické vs. informační operace

  • DFD zachycuje informační operace jako funkce
  • Fyzické operace jsou promítnuty jako terminátory - komunikují s IS, ale jsou mimo něj
  • Fyzické operace vyžadují informační vstupy a generují informace k zaznamenání

Postup tvorby DFD (Event Partitioning Approach)

  1. Identifikujte události, na které musí IS reagovat
  2. Pro každou událost přidejte funkci, která na ni reaguje
  3. Agregujte funkce do funkcí vyšší úrovně přístupem INFORMATION HIDING (skrývání lokálních Data Storů)

7. Konzistence diagramů

Úvod

Pravidla konzistence jsou nástrojem pro:

  • Odladění chyb v diagramech
  • Odstranění vzájemných rozporů mezi diagramy
  • Dosažení kvality modelu (správnost a úplnost)

Dva přístupy ke kontrole konzistence

  1. Kontrola vůči realitě - porovnání modelu s reálnou předlohou
  2. Kontrola vzájemné konzistence diagramů - model “alespoň na papíře” dává smysl

Kritéria kontroly vůči realitě

Správnost (model odpovídá realitě):

  • Každá třída koresponduje s reálně existujícím objektem
  • Vazby zachycují v realitě možné vazby
  • Business proces směřuje k naplnění hlavního cíle
  • Životní cyklus koresponduje s reálnou posloupností změn

Kompletnost (nic nebylo opomenuto):

  • Existuje alespoň jedna cesta mezi kterýmikoliv dvěma třídami
  • Pro každý výstupní produkt existuje business proces
  • Každá událost je uvedena jako iniciátor nějaké činnosti
  • Životní cyklus pokrývá celý život objektu

Kontrola konzistence diagramů

Dva typy kontroly:

  1. Kontrola struktury - elementy z různých diagramů si odpovídají dle metamodelu
  2. Kontrola souslednosti - temporální diagramy nejsou v rozporu

Pravidla konzistence struktury

Globální analýza (procesní mapa + diagram tříd):

  • Objekty v názvech událostí, cílových stavů a business partnerů korespondují s třídami v diagramu tříd

Detailní procesní diagram:

  • Spouštěcí události jsou identické s procesní mapou
  • Cílový stav z procesní mapy je uveden jako stav objektu v detailním diagramu
  • Podpůrné procesy jsou zachyceny jako synchronizace

Diagram životního cyklu:

  • Více životních cyklů jedné třídy = objekt vystupuje ve více rolích
  • Vazba 1:N = iterativní cyklus v životním cyklu
  • Parciální vazba = alternativní přechody
  • Operace v přechodech = operace třídy

Kontrola souslednosti

Kontroluje se, že souslednost stavů objektů v detailních diagramech procesů není v rozporu se sousledností v životních cyklech.

Konzistenční tabulka:

Č.Událost/Podmínka (proces)Akce (proces)Akce (STD)Stav (proces)Stav (STD)

Konzistence s DFD

  • Každý elementární Data Store = třída v diagramu tříd
  • Každý informační tok = atributy třídy
  • Každá funkce IS = operace třídy

8. Specifika modelovacích jazyků

Procesní modelovací jazyky

Event-driven Process Chain (EPC) - 1994

  • Vyvinut v 90. letech v IWi Saarbrücken ve spolupráci se SAP
  • Cíl: definovat modelovací jazyk pro dokumentaci procesů SAP R/3
  • Základem je Petri Net
  • Rozšíření: eEPC (extended EPC) v rámci ARIS

ARIS (Architecture of Integrated Information Systems)

  • Komplexní metodika od Software AG
  • ARIS House - architektura integrovaných informačních systémů:
    • Organization view
    • Data view
    • Function view
    • Control view (integrující pohled)
  • Používá Value Chain, eEPC a další diagramy

UML Activity Diagram (1997)

  • Součást UML standardu
  • Primárně pro modelování softwarových systémů, ale použitelný i pro business procesy
  • Rozšíření: Accept Time Event, Sending/Receiving Signals, Exception Flow

BPMN - Business Process Model and Notation (2004)

Primární cíl: Notace srozumitelná všem business uživatelům - od business analytiků přes vývojáře až po manažery.

Sekundární cíl: Zajistit vizualizaci XML jazyků pro exekuci procesů (WSBPEL).

Klíčové vlastnosti:

  • Focus na executability (BPEL)
  • Detailní události
  • Service Oriented Architecture (SOA)
  • Task Types, Gateway Types, Event Types
  • Collaboration diagrams

DMN - Decision Model and Notation

  • Standard pro modelování a exekuci rozhodnutí řízených business pravidly
  • Rozhodovací tabulky
  • FEEL (Friendly Enough Expression Language) pro podmínky
  • Decision Requirements Diagrams pro komplexní rozhodnutí

Flowchart

  • Standardizován 1960, revize 1985
  • Základní symboly: Process, Decision, Data, Terminator

Metamodel

Metamodel = “nad-model”, model modelu

  • Popisuje, z jakých prvků se model může skládat
  • Definuje, jaké vztahy jsou mezi prvky přípustné
  • Pro zachycení se používá UML diagram tříd

UML diagramy (přehled)

  • Use Case Diagram
  • Activity Diagram
  • Sequence Diagram
  • Class Diagram
  • State Machine Diagram
  • Component Diagram
  • Information Flow Diagram

TOGAF / ArchiMate

TOGAF (The Open Group Architecture Framework):

  • Enterprise Architecture framework
  • ADM (Architecture Development Method)
  • Různé typy diagramů pro různé vrstvy

ArchiMate:

  • Modelovací jazyk pro enterprise architekturu
  • Tři hlavní vrstvy:
    • Business Layer - business actors, roles, processes, functions, services
    • Application Layer - application components, services, interfaces
    • Technology Layer - nodes, devices, system software, networks

9. Business Process Management System (BPMS)

Definice

Business Process Management System (BPMS) je systém, který podporuje:

  • Návrh
  • Analýzu
  • Provádění
  • Monitorování

business procesů na základě explicitních procesních modelů.

Analogie: Jako DBMS je standardizované ukládání/přístup k datům, BPMS je standardizované ukládání/přístup k funkcím.

Historie

BPMS pocházejí ze staršího typu PAIS (Process Aware Information Systems) známých jako Workflow Management System (WfMS), který byl zaměřen na modelování a exekuci.

BPM vs BPMS

  • BPM = metodika, metoda, technika nebo projevy v realitě
  • BPMS = soubor technologií pro automatizaci procesů

Spektrum BPMS systémů

  1. Groupware systems

    • Sdílení dokumentů a informací
    • Přímá komunikace mezi uživateli
    • Přímo nepodporují business procesy (např. IBM Notes)

  2. Ad hoc workflow systems

    • Definice procesů lze vytvořit a upravit za běhu
    • Práce může začít od prázdné definice
    • Vyžaduje sofistikované uživatele (např. ActiveMatrix BusinessWorks)

  3. Case management systems

    • Podpora procesů, které nejsou pevně specifikovány
    • Implicitní procesní modely s možností odchylky
    • CMMN (Case Management Model and Notation)
    • Příklady: i-Sight, PEGA Case Management, ISIS Papyrus

  4. Production workflow systems

    • Nejvýznamnější typ
    • Práce směrována striktně dle explicitních procesních modelů
    • Příklady: IBM Business Process Manager, Camunda
    • Podtypy: Administrativní BPMS, Transakční BPMS

Komponenty BPMS

  1. Execution Engine

    • Centrální součást
    • Vytváření instancí procesu
    • Distribuce práce účastníkům
    • Automatické získávání a ukládání dat
    • Generování úloh
    • Koordinace činností

  2. Process modeling tool

    • Vytváření a úprava procesních modelů
    • Anotace (vstup/výstup, účastníci, pravidla)
    • Ukládání do repository

  3. Worklist handler

    • Nabízí pracovní úkoly účastníkům
    • Podobný doručené poště
    • Check-out (zahájení úkolu) / Check-in (dokončení)
    • Elektronické formuláře

  4. Externí služby

    • Integrace s externími aplikacemi
    • Servisní rozhraní
    • Komunikace mezi BPMS různých organizací

  5. Nástroje pro správu a monitorování

    • Provozní záležitosti
    • Řešení výjimečných situací
    • Sledování výkonu procesů
    • Dashboardy a reporty
    • Execution logs

BPMS vs iBPMS

iBPMS (intelligent BPMS) přidává:

  • Validace (simulace, “co kdyby”)
  • Ověřování (logická shoda)
  • Optimalizace
  • Integrace se sociálními médii
  • Mobilní procesní úkoly
  • Analytika streamování
  • Správa rozhodnutí v reálném čase

Výhody zavedení BPMS

  • Workload Reduction - správná distribuce práce
  • Flexible System Integration - oddělení koordinace a zpracování dat, SOA
  • Execution Transparency - přehled o stavu procesů
  • Rule Enforcement - vynucování pravidel

Příklady BPMS

  • IBM Business Process Manager
  • Camunda BPM
  • jBPM
  • Bizagi
  • Bonita

Literatura

  • Řepa, V., Svatoš, O. (2021). Adaptive and Resilient Business Architecture for the Digital Age. Springer.
  • The Open Group. (2018). TOGAF Version 9.2. Van Haren.
  • The Open Group. (2016). ArchiMate 3.0 Specification. Van Haren.
  • Object Management Group. (2017). Unified Modeling Language (UML) specification v2.5.1.
  • Object Management Group. (2014). Business Process Model and Notation (BPMN) Specification version 2.0.2.
  • Yourdon, E. (1989). Modern structured analysis. Yourdon Press.
  • Weske, M. Business Process Management.
  • Dumas, M., La Rosa, M., Mendling, J., Reijers, H.A. (2018). Fundamentals of Business Process Management.
  • Scheer, A.W. (1998). ARIS - Business Process Frameworks. Springer.