Metodika modelování a analýzy podnikových procesů

Metodika modelování a analýzy podnikových procesů, anglicky Methodology for Modelling and Analysis of Business Process (MMABP), je metodika, která vznikla na katedře informačních technologií patřící pod fakultu informatiky a statistiky Vysoké školy ekonomické v Praze, zejména zásluhou profesora Ing. Václava Řepy, CSc. Vznikat začala v druhé polovině devadesátých let dvacátého století a je dále neustále rozvíjena díky studentským pracím, výzkumné práci a prezentacím na konferencích.

• MMABP se využívá k analýze podnikových procesů a pro tvorbu celkového modelu. Tento model je možné využít k optimalizaci těchto procesů. Model by měl respektovat základní cíle, stav a charakteristiky organizace dále respektovat vnější vlivy, nezávislé na organizaci, které mohou ovlivnit organizaci v její činnosti. Model by měl být dále také „optimální“ a to ve smyslu ekonomickém, měl by být efektivní, a i ve smyslu věcném tzn. měl by být maximálně jednoduchý, a přitom si zachovat úplnou funkčnost. V neposlední řadě by měl model umožnit následnou optimalizaci, implementaci a zavedení systému procesů, které respektují výše uvedené charakteristiky.

• Technika analýzy událostí v této metodice: Cílem je identifikovat základní procesy v organizaci. Analyzovat události, které vedou k jednotlivým činnostem, zjišťuje se, které činnosti patří objektově dohromady a tvoří konceptuální proces.

• Základní východisko metodiky: Základním východiskem je, že činnost organizace je modelem cílů organizace a dalších skutečností, které ovlivňují splnění cílů a souvislostí mezi nimi. Z toho je patrné, že veškeré činnosti v organizaci musí sloužit k dosažení cílů organizace.

• Tři základní principy metodiky: Základními principy metodiky jsou:

1. Princip modelování
2. Princip různých architektur procesu
3. Princip abstrakce

Princip modelování bere za předpoklad, že objektivní základ k implementování podnikových procesů musí představovat reálné skutečnosti, které existují vně a nezávisle na organizaci. Princip různých architektur vyjadřuje potřebu oddělit od sebe charakteristiky procesu, které jsou dány objektivními a na organizaci nezávislými skutečnostmi od charakteristik, které jsou dány kontextem umístění procesu v dané organizaci. Princip abstrakce vyjadřuje, jakým způsobem jsou jednotlivé identifikované skutečnosti podrobněji analyzovány prostřednictvím hierarchických abstrakcí.

Model reality

Základem MMABP je představa, že model reality je založen na dvou vzájemně propojených modelech, modelu objektů a modelu věcných procesů. Oba modely zachycují totéž, jen se liší jejich úhel pohledu – pohled na statické vlastnosti reality a pohled na její dynamické chování.

• Model objektů: tento model sleduje základní stavební kameny reality – objekty a jejich vlastnosti (atributy). Popisuje, z čeho je realita složena a jaké jsou základní objekty, jejich vlastnosti a vztahy mezi nimi. K tomu je využíván Diagram tříd (Class Diagram). Kromě vztahů jednotlivých objektů a jejich vlastností, se sledují i tzv. životní cykly objektů. K tomu je použit Stavový diagram (State Chart). Ten zachycuje základní časové návaznosti mezi metodami objektů. Nesměřuje k žádnému cíli a plní tak svůj základní účel – modeluje strukturu reality a její základní vlastnosti.

• Model věcných procesů: jedná se o model dynamiky reality – popisuje následnost akcí, které vedou od počátečních stavů procesů až ke koncovým. K tomu se používá Procesní diagram, který zachycuje chování reality. Na rozdíl od stavového diagramu vždy směřuje k nějakému cíli. Druhý diagram používaný v tomto modelu je tzv. Eriksson-Penker Diagram. Ten zachycuje globální pohled na procesy, které jsou poté detailně zachyceny v již zmíněném procesním diagramu.

Každý z obou modelů popisuje realitu z hlediska své dimenze. V obou modelech jsou obsaženy procesy – buďto ve významu životního cyklu, nebo věcného. Životní cyklus je vymezení zákonitostí, které musí být respektovány jakýmkoliv chováním, zatímco věcný je popisem tohoto chování. Vzhledem k modelování podnikových procesů z tohoto rozdílu plyne, že nelze brát procesy pouze z technického hlediska. Jejich podstatu tvoří právě účelnost a cílenost.

I přesto, že se jedná o odlišné pohledy, mají modely mnoho společného. V obou modelech se pracuje jak s procesy, tak i s atributy, např. v procesním modelu je důležité sledovat atributy stavu procesu atd. Tímto společný průnikem obou dimenzí vyvstává nutnost sladit oba modely dohromady. Vzájemná konzistence je zde důležitá.

Metodický postup modelování procesů

Pro formulaci procesů v organizaci je zapotřebí identifikovat základní činnosti. Mít představu o základních událostech a předpokládaných reakcí na tyto události – zde se jedná o kontextovou představu organizace. A také představu o základních objektech zájmu a jejich životních cyklech, neboli objektová představa organizace.

Metodický postup pro modelování podnikových procesů na základě metodiky MMAPB se skládá z přípravného nultého kroku a tří fází:

1. Krok 0 – Analýza událostí a vnějších reakcí
2. Fáze 1 – Analýza elementárních procesů
3. Fáze 2 – Specifikace klíčových procesů
4. Fáze 3 – Specifikace podpůrných procesů

0. Krok – Analýza událostí a vnějších reakcí

Cílem tohoto kroku je zjistit veškeré relevantní reálné události, které vedou k dosažení cíle a tyto události přiřadit k vnějším reakcím. Podstatné jsou ty reakce, které směřují mimo organizaci. To samé platí i pro události. Také zde platí, že se v tomto případě za události považují ty, které vznikají mimo organizaci.

Východiskem tohoto kroku je pak seznam událostí, který je strukturovaný podle: cílů, produktů, čí dalších aspektů. Události se dělí na dva základní typy:

Události věcné: Tyto události jsou provázány s produktem procesu. Odrážejí nějakou akci jakéhokoliv objektu v podnikovém schématu, (např. technologický čí informační systém) nebo také objektu okolí podniku (např. zákazníka, konkurenta).

Události časové: Zde se jedná o události dané časem. Časový údaj, či úsek v nichž je od procesu něco požadováno (např. konec měsíce, účetní období).

Tento krok také obsahuje nutné reakce na výše zmíněné události. Události jsou proto analyzovány ve vztahu k reakcím, a to z toho důvodu, že jedna z událostí se zároveň vyskytuje jako příčina různých reakcí a mezi událostmi, které jsou uspořádány k jedné reakci, je třeba vidět určité pořadí. Každé takovéto uspořádaní nám pak tvoří jeden elementární přirozený proces.

Přirozeným je proces proto, že bere v úvahu, co vede k reakcím organizace na existenci příslušných událostí. Přirozený proces se skládá ze dvou úkonů:

Přiřazení události k reakcím: Pro každou reakci se identifikují události, které k reakci vedou. Jedna událost se může vyskytovat ve více reakcích.

Uspořádání událostí v každé reakci: Události, které jsou přiřazeny k dané reakci se stanoví pořadí.

Výsledek nultého kroku je považován za nejdůležitější, a to z důvodu, že na jeho kvalitě je závislá kvalita celé analýzy.

1. Fáze – Analýza elementárních procesů

Tato fáze má za cíl poznání elementárních procesů v organizaci, a to za pomoci předchozího nultého kroku. Zjistit základní vazby a vnitřní strukturu analyzovaných událostí. Výsledkem je pak systém elementárních procesů, který je podkladem pro identifikaci klíčových procesů.

Fáze se skládá ze čtyř kroků:

Identifikace elementárních procesů: Základním východiskem pro tento krok je seznam událostí a reakcí. Dalším důležitým východiskem v tomto kroku je znalost činnosti organizace a mít základní, intuitivní představu o jejích základních procesech a činnostech. To zajistí vnímání širšího kontextu z hlediska cílů, vstupů a výstupů organizace.

Výstupem tohoto kroku je seznam identifikovaných elementárních procesů. Každý proces má jasné základní události, která jej ovlivňují a základní reakce, které proces produkuje.

Analýza a návrh elementárních procesů: V tomto kroku se zaměřujeme na přirozené souvislosti elementárních procesů. Výsledkem kroku je systém identifikovaných elementárních procesů.

Detailní analýza elementárních procesů: Jde o rozpracování globálního pohledu, který byl vytvořen v rámci předchozích dvou kroků, a to na požadovanou úroveň detailu. Úroveň detailu závisí na mnoha detailech a musí se volit vhodně na základě konkrétního případu.

Analýza a úprava konzistence elementárních procesů: Poslední čtvrtý krok se věnuje doladění systému procesů. A to do takového stavu, který si navzájem neodporuje. Výstupem kroku jsou úpravy systému identifikovaných elementárních procesů, který byl vytvořen v předcházejících krocích a zajištění, pokud možno úplně konzistence modelů. K zajištění konsistence je třeba věnovat pozornost znakům nekonzistentnosti jako například:

• Identifikované události nezahrnuté do žádné reakce
• Reakce na jedinou událost
• Existující výstupy systému nevázané na žádnou událost
• Detailní souvislosti událostí různých procesů, jimž neodpovídají vazby mezi těmito procesy
• Procesy bez výstupů, vstupů a aktérů

2. Fáze – Specifikace klíčových procesů

Cílem je identifikovat klíčové procesy v organizaci na základě objektové analýzy produktů dané organizace. Navazuje přímo na předchozí fázi. Fáze zahrnuje tři kroky:

Objektová analýza produktů: Zaměřuje se na životní cykly produktů. Jde o procesy, které pokrývají vznik a existenci produktů, které jsou pro organizaci klíčové. Výsledkem je objektový model produktů, který je východiskem pro následnou specifikaci procesů podpůrných.

Identifikace, analýza a sestavení klíčových procesů: Jde o identifikaci klíčových procesů, které pro organizaci představují hlavní procesy z hlediska strategických cílů.  Výsledkem je systém klíčových procesů, které jsou rozděleny na hlavní a podpůrné.

Analýza a úprava konzistence klíčových procesů: Jedná se o podobnou úpravu jako v posledním kroku první fáze, avšak je zde mnohem více příležitostí k nekonzistencím, a to díky tomu, že vznikl další model (objektový model produktů). Znaky nekonzistentnosti jsou následující:

• Procesy, které nejsou klíčové a nejdou žádnému procesu podpůrné
• Procesně nepokryté produkty
• Procesně nepokryté části života produktů
• Strukturálně si neodpovídající život klíčového produktu s průběhem klíčového procesu
• Strukturálně si neodpovídající život klíčové produktu se způsobem návaznosti odpovídajících procesů
• Nedostatečná podpora klíčového procesu v jisté části

3. Fáze – Specifikace podpůrných procesů

Cílem této fáze je identifikovat podpůrné procesy organizace pomocí objektové analýzy. Výsledkem je systém konceptuálních procesů v organizaci. Fáze má tři navazující kroky:

Analýza objektů zájmu: Je vytvořen kompletní objektový model organizace, který pokrývá kromě produktů i jiné objekty, jako například: aktéry, organizační jednotky vstupy a výstupy. Také jsou v tomto kroku analyzovány i jejich vzájemné obecné vazby. Výstupem kroku je objektový model organizace.

Identifikace, analýza a návrh podpůrných procesů: V tomto kroku dochází ke konfrontaci představy klíčových procesů se zákonitostmi objektů a jejich vztahů. Výsledkem je komplexní poznání potřeby podpůrných procesů. Doplnění modelů a vytvoření finálního procesního modelu organizace.

Analýza a úprava konzistence systému procesů: Tento krok je uzavírá celý postup a jeho hlavním cílem je zajistit, pokud možno dokonalou konzistenci procesního modelu. Zde pracujeme s předpokladem, že nekonzistence pochází především ze změn, a to z toho důvodu, že modely již byli vytvořeny v obou krocích této fáze.

Modely využívané metodikou

Metodika používá pro modelování několika diagramů. Nejprve je na celou realitu nahlíženo z globálního pohledu (jak na model věcných procesů, tak na model objektů). Poté přichází na řadu modelování detailního pohledu. Hlavním důvodem je potřeba rozdělit zkoumanou oblast na zvládnutelné části - pochopit celý komplexní systém by totiž bylo nad lidské možnosti, proto dvě menší zvládnutelné části je nutností.

Globální pohled

Globální pohled je vždy nadčasový, zaměřený na existenci prvků a vztahů. Cílem globálního pohledu je především úplnost, do přílišných detailů jít nemusí.

Globální mapa procesů dle metodiky MMABP

Globálním modelem objektů je diagram tříd. Diagram tříd je jedním ze základních diagramů metodiky MMABP a celkově centrálním diagramem jazyka UML, kde slouží hlavně pro formální definici termínů a vztahů s cílem vyvinout počítačovou aplikaci.

Stavový diagram dle metodiky MMABP

Při informačním modelování organizace ovšem není cílem vyvinout aplikaci, ale poznat zkoumanou oblast reality. Diagram tříd v tomto odlišném významu má několik svých specifik. Např. u atributů není nutné uvádět jejich typ, stejně tak není nutné uvádět typ hodnoty ani parametry u operací - důležitý je hlavně název. Diagram tříd tedy obsahuje atributy (typové vlastnosti objektů dané třídy), operace (akce vázané k objektům třídy) a názvy jednotlivých vztahů mezi třídami. Ty jsou zachycovány v základních typech asociace, agregace, kompozice a generalizace, které by diagram měl také obsahovat.

Globálním modelem procesů je tzv. Eriksson-Penker diagram neboli tzv. globální procesní mapa. Notace Eriksson-Penker vznikla jako rozšíření jazyka UML, právě kvůli potřebě modelování systému procesů. Globální mapa procesů je jedním ze základních diagramů metodiky MMABP. Zachycuje všechny elementární procesy, jejichž analýza je druhou fází metodiky. Diagram začíná vždy vstupem (vstupy) do procesu a končí výstupem (výstupy). Jednotlivé procesy jsou zachyceny i s vzájemnou návazností na sebe a zároveň jsou odlišeny procesy klíčové a podpůrné.

Detailní pohled

Detailní pohled je na rozdíl od toho globálního již zaměřen časově. Je zaměřen na postup dění v systému.

Detailním modelem objektů jsou tzv. stavové diagramy. Diagramy doplňují diagram tříd, neboť popisují životní cykly vybraných důležitých tříd. Není samozřejmě nutné popsat cykly všech tříd, důležité jsou pouze konkrétně vybrané (klíčové) objekty, které se dále objeví i v procesních diagramech. V samotném diagramu je přechod mezi jednotlivými stavy objektu vždy okomentován a to formou důvod / akce. Akcí je v diagramu stavů vždy nějaká operace, která je uvedená u příslušné třídy v digramu tříd. . Dalšími objekty tohoto diagramu jsou: Stav objektu, Počáteční událost, koncový stav a již zmíněný přechod z jednoho stavu do druhého.^[4]

Procesní diagram dle metodiky MMABP

Detailním modelem procesů je tzv. procesní diagram. Zde je autorem metodiky doporučována obecně uznávaná notace BPMN. Procesní diagram zachycuje vždy jeden proces. Je ale důležité myslet i na synchronizaci s dalšími procesy, což se děje prostřednictvím vstupů a výstupů (výstup jednoho procesu může být vstupem druhého). Kromě vstupů a výstupů diagram obsahuje samozřejmě jednotlivé aktivity, a také stavy důležitých objektů, které aktivity mění. Důležité body v procesním diagramu jsou i stavy, do kterých se proces dostane, a kde čeká na nějakou externí událost. Právě tyto momenty bývají příčinou zdržení v procesu a je dobré se na ně zaměřit při analýze. Dalším bodem, na který je třeba dát při modelování procesů pozor je správné rozlišení na klíčové a podpůrné procesy. Chybné rozdělení bude mít důsledky nejen v modelech, ale i v celém procesním řízení - k oběma typům procesů se totiž musí přistupovat jinak.

Class Diagram (Diagram tříd)

Standardní nástroj pro konceptuální modelování, který umožňuje propojení s detailními objektovými modely, je Diagram tříd z UML. Diagram tříd popisuje statickou strukturu systému ve formě tříd a vztahů mezi nimi. Je to základní diagram z celé škály UML diagramů. Více informací je možné dohledat na stránce Diagram tříd.

State Chart (Stavový diagram)

State Chart je nástroj pro popis možných (povolených) stavů objektu spolu s možnými přechody mezi nimi. Každý přechod je popsaný dvěma atributy:

• důvod pro přechod
• metoda realizace přechodu

MMABP považuje State Chart za nejvhodnější nástroj z jednotného modelovacího jazyka pro účely popisu životního cyklu objektu. Přesto nebyl State Chart původně zamýšlen jako nástroj pro popis životního cyklu. Jeho kořeny leží v teorii stavových strojů a je úzce spojen s konceptem takzvaného "real-time processing".

Konzistence modelů

Závěrečný krok metodiky. Cílem je zajistit, pokud možno dokonalou, konzistenci všech diagramů.

Kontrola konzistence modelů je klíčově důležitou součástí metodiky MMABP. Vzájemná sladěnost je totiž důležitým nástrojem analýzy - při důsledném sledování všech vzájemných vztahů nebude opomenuto důležitých částí modelů (jejich vynechání by se projevilo jako nesoulad v jednotlivých modelech).

V rámci správnosti a sladěnosti modelů je tak potřeba zajistit úplnost a správnost.

Kritéria úplnosti modelů

Úplnost diagramu tříd je dána hlavně tím, že mezi každými dvěma třídami v diagramu existuje alespoň jedna cesta prostřednictvím asociací. Další pravidla jsou spíše formální, např. předpoklad identity každého objektu, nutnost specifikovat atributy a operace, definovat typ a název vztahu atd. Úplnost životního cyklu třídy objektů znamená hlavně pokrytí celého života objektu a zahrnutí všech stavů, kterými objekt prochází.

Základní pravidla úplnosti modelu systému procesů jsou zejména existence a popis klíčových procesů pro každý typ výstupního produktu a zároveň mezi každými dvěma procesy modelu systému musí existovat alespoň jedna cesta jejich vzájemných vztahů.

Úplnost modelu business procesu znamená, že model pokrývá celý proces od začátku do konce, jsou specifikovány všechny události, které ovlivňují proces v běhu a také musí být specifikovány všechny nutné stavy procesu (při čekání na externí události).

• Úplnost konceptuálního modelu obecně vyplývá z teorie konceptuálního modelování, kde jsou definována základní pravidla pro toto kritérium. Například jedno z hlavních pravidel je: "Mezi jakýmikoli dvěma třídami v diagramu tříd musí existovat alespoň jeden spoj."
• Úplnost modelu podnikových procesů obecně vyplývá z teorie re-engineering a modelování podnikových procesů, kde je definován obsah tohoto konceptu v oblasti podnikových procesů. Například některá z hlavních pravidel jsou: "Pro každý specifikovaný produkt musí být popsán model podnikového procesu" nebo "Každá rozpoznaná událost musí být použita ve minimálně jednom modelu podnikového procesu jako důvod pro nějakou akci."
• Úplnost životního cyklu objektů je vyjádřena jednoduchým pravidlem, které říká, že "životní cyklus objektu musí zahrnovat celý život objektu". Jako realizaci tohoto pravidla metodologie definuje tři povinné typy objektových metod (stereotypy): konstruktor, destruktor a transformátor. Cílem je zajistit úplnost popisu celého životního cyklu objektu.

Kritéria správnosti modelů

Pro správnost modelu tříd platí zejména:

• Každá třída představuje typově reálně existující objekt této třídy
• Každá asociace představuje reálně existující vztah
• Specifikované atributy třídy musí být vlastnostmi jen objektu této třídy a všech jeho instancí
• Všechny specifikované operace třídy musí patřit do životního cyklu jen této třídy a jejích instancí

Správnost životního cyklu třídy objektů je dána zejména popisem pravdivých kombinací akcí a jejich výsledků, a zároveň je cyklus platný i pro všechny instance tohoto objektu.

Kritéria korektnosti a kompletnosti v diagramech

Správnost modelu systému procesů je zajištěna zejména tím, že každý proces poskytuje výstupy buď nutné pro naplnění základní funkce organizace, nebo k uskutečnění jiného procesu.

Správnost modelu business procesu definuje hlavně platnost popsaných činností procesu pro všechny instance procesu a každá činnost v procesu musí být elementární (tzn. že neobsahuje další proces).

• Správnost konceptuálního modelu je definována následovně: "Každá třída objektu musí odpovídat reálným a existujícím objektům. Jakýkoli vztah k jiné třídě(objektu) musí modelovat existující možný vztah. Popsané třídy objektů a jejich vztahy musí platit pro všechny možné instance každé třídy objektu."
• Správnost modelu podnikových procesů je definována následovně: "Podnikový proces musí splňovat hlavní cíl procesu. Popsané akce procesu, jejich následnost, vstupy, výstupy a další atributy musí platit pro všechny možné instance procesu."
• Správnost životních cyklů objektů je definována následovně: "Životní cyklus objektu musí odpovídat skutečným a objektivním akcím a jejich následnostem v životě objektu. Životní cyklus objektu musí být platný pro všechny možné instance třídy objektu."

Úplnost a správnost

Správnost (úplnost) vztahů mezi stavovým diagramem (State Chart) a diagramem tříd se zvažuje z hlediska vztahů mezi oběma diagramy a je definována následovně: "Každá asociace příslušející třídě v diagramu tříd musí odpovídat nějaké metodě specifikované v životním cyklu objektu (stavovém diagramu) této třídy jako atribut přechodu mezi stavy a naopak."

Správnost (úplnost) objektových rolí zvažuje vztahy mezi třídním diagramem a diagramem podnikových procesů a je definována následovně: "Každá třída objektu musí být přítomna v nějakém podnikovém procesu jako vstupní nebo výstupní sada, aktér nebo jakýkoli jiný externí faktor a naopak."

Správnost (úplnost) akcí zvažuje vztahy mezi diagramem podnikových procesů a stavovým diagramem a je definována následovně: "Každá akce v každém podnikovém procesu musí odpovídat alespoň jednomu přechodu mezi stavy v alespoň jednom životním cyklu objektu a naopak."

Správnost (úplnost) důvodů zvažuje vztahy mezi všemi třemi diagramy a je definována následovně: "Každá událost použitá v každém životním cyklu objektu jako důvod pro přechod mezi stavy by měla odpovídat stejné události použité v alespoň jednom podnikovém procesu jako důvod pro činnost procesu a naopak."

Strukturální soudržnost

Struktura souboru a programu

Podle autora byla základní myšlenkou JSP následující úvaha: struktura programu by měla být diktována strukturou jeho vstupních a výstupních datových toků. Pokud se jeden ze sekvenčních souborů zpracovávaných programem skládal ze skupin zákazníků, přičemž každá skupina se skládala ze záznamu o zákazníkovi, za nímž následuje určitý počet záznamů o objednávkách, z nichž každá je buď jednoduchá objednávka nebo urgentní objednávka, pak by program měl mít stejnou strukturu: měl by mít část programu, která zpracovává soubor s podčástí, která zpracovává každou skupinu zákazníků; a tato dílčí část by měla mít jednu dílčí část, která zpracovává záznam zákazníka, a tak dále.

Propojení procesů a objektů

Procesní model a class diagram musí být vzájemně propojeny. Toto propojení představuje logické vztahy při dvou pohledech na reálný systém:

• Pohled na reálný svět jako na strukturu objektů a jejich vztahů, které jsou relativně stabilní
• Pohled na reálný svět jako na strukturu částečně spojených akcí, které produkují vstupy a výstupy, při stejném procesním cíli

Protože tyto dva pohledy jsou jen různými pohledy na stejný skutečný svět, musí spolu odpovídat – být vzájemně konzistentní. To znamená, že byznys objekty, které jsou modelovány v modelu tříd, musí být přítomny v modelu procesů v různých formách jako aktéři, vstupy/výstupy, organizační jednotky a jiné vnější aspekty.

Smyslem tohoto dvojitého pohledu na skutečný svět je skutečnost, že tyto dva pohledy jsou odlišné. Dva odlišné pohledy na stejný systém umožňují prostorový efekt – nové informace jako synergický efekt.

Protože oba tyto pohledy jsou různé pohledy na stejný skutečný svět, je nutné vědět, jaký je jejich společný význam – jak prvky jednoho pohledu odpovídají prvkům druhého. Zohlednění úrovně rozdílu mezi těmito dvěma pohledy ukazuje, že taková korespondence není jednoduchá. Jeden objekt z diagramu tříd se typicky objevuje v řadě procesů a jeden proces typicky kombinuje řadu objektů v řadě rolí. Navíc jeden objekt může být dokonce nalezen ve stejném procesu v několika různých rolích (jako aktér a informační vstup ve stejném čase, například).

Z výše popsaných skutečností vyplývá následující sada pravidel:

• Každá třída objektů v modelu tříd musí být přítomna v modelu procesů alespoň v jednom z jeho vstupů, výstupů a/nebo jako aktér nebo jiný vnější prvek.
• Každý vstup, výstup, aktér nebo jiný vnější prvek procesu musí být přítomen v modelu tříd jako třída, nebo jako asociace, nebo jako kombinace obou.

Výše popsaná pravidla jsou relevantní pouze pro jednu stranu reality – aspekty existence. Tato strana reality se skládá z objektů a artefaktů a jejich obecných (podstatných, statických) vztahů. Avšak druhá strana reality je také přítomna v obou modelech. Tato strana se skládá z akcí, stavů a jejich (časových) vztahů. Zatímco v procesním pohledu je tento "behaviorální" aspekt skutečného světa přítomen přirozeně, v objektovém pohledu na něj není tak jednoduché ho vnímat. Toto je přesně důvod pro popis životního cyklu objektu.

Následující sada pravidel doplňuje dříve uvedená pravidla o aspektech popisu životního cyklu objektu a jejich projevu ve vztazích mezi procesním a objektovým modelem:

1. pro každou třídu objektů z modelu tříd musí být specifikovány alespoň tři metody
   1. konstruktor (vytvoří instanci třídy)
   2. destruktor (odstraní instanci třídy)
   3. transformátor (mění atributy třídy)
2. pro každý atribut třídy objektů musí být specifikována metoda, která inicializuje hodnotu tohoto atributu, stejně jako metoda, která mění hodnotu tohoto atributu
3. pro každou asociaci tříd objektů musí být specifikována odpovídající metoda, která realizuje tuto asociaci
4. pro každou neprimitivní třídu objektů z modelu tříd musí být vytvořen stavový diagram popisující životní cyklus objektů této třídy
5. ve stavovém diagramu popisujícím životní cyklus by měly být popsány všechny možné (povolené) přechody mezi všemi stavy. Každý přechod musí specifikovat příčinnou událost a metodu použitou pro realizaci přechodu
6. stavový diagram popisující životní cyklus objektů určité třídy musí používat všechny metody této třídy v popisech přechodů. Popis přechodu nepoužívá metodu, která není specifikována v diagramu tříd
7. každá událost použitá v popisu přechodu musí odpovídat události specifikované v popisu některého obchodního procesu (procesů)

Procesně založená organizace

Během 20 let existence tohoto přístupu se uvažování v oblasti podnikových procesů stalo běžnou součástí řízení organizací. Nicméně, Business Process Re-engineering a Process Based Management znamenají mnohem více než je obvyklé v běžné manažerské praxi. Především jde o skutečnou paradigmatickou změnu v teorii managementu. Komplexnost této změny paradigmatu znesnadňuje její uplatňování; navíc není snadné pochopit základní myšlenku tohoto přístupu. Vzhledem k výše uvedeným skutečnostem je plné uplatňování myšlenek řízení řízených procesů velmi vzácné. Většina příběhů o používání myšlení založeného na procesech zdůrazňuje pouze okrajové aspekty tohoto přístupu, jako je částečné zlepšení důkazů, snižování času, nákladů, automatizace programů atd., bez skutečného zásadního změny v podnikovém výkonu, což je skutečná podstata této myšlenky. Na druhé straně neexistuje žádná oblast podnikání, kde by implementace Process Based Managementu nemohla přinést dramatické zlepšení.

Michael Hammer a James Champy vysvětlují nutnost "Business Process Re-engineering" v historickém kontextu. Ukazuje tradiční posloupnost historických milníků v evoluci socioekonomického systému od dělby práce přes band-organizovanou výrobu a dělení řízení až po "Rostoucí ekonomiku" 40. až 80. let a charakterizuje současnou situaci jako "konec ekonomického růstu". Konec ekonomického růstu byl způsoben saturací trhu, což mění tradiční role zákazníka, spolupracovníka a konkurenta. V takové situaci již nejsou běžné problémy, jako je hypertrofické střední vedení, oddělení řízení od zákazníka, obtíže s jasným stanovením cílů, tvrdohlavé řízení, problémy s koordinací globálních a lokálních cílů a další. Tyto problémy musí být nekompromisně a okamžitě řešeny pro budoucí rozvoj organizace. V nenasyceném trhu nebyly tyto typické problémy rostoucí organizace kritické, protože bylo možné je překonat prostřednictvím rozšíření trhu. Nicméně díky tvrdým limitům na saturovaném trhu spolu s následně rostoucím tlakem konkurence se tyto problémy staly kritickými. Autoři charakterizují tuto turbulentní situaci jako "3C" (zákazníci, konkurence a změna) a argumentují pro nutnost změny ve všech relevantních smyslech. Mluví o trvalé změně na trzích, v konkurenci, v povaze podnikání a dokonce i o samotné změně - změna již není jednorázovou individuální záležitostí, ale trvalým atributem organizace.

Hammer a Champy uvádějí dvě hlavní charakteristiky, které by měly být považovány za podstatu myšlenky procesně orientovaného řízení.

• Hlavním důvodem pro tento přístup je potřeba, aby organizace byla dostatečně flexibilní, aby mohla změnit své vnitřní chování v souladu se změnami v prostředí. Tyto změny zahrnují nejen změny preferencí a požadavků zákazníků, ale také změny v možnostech, jak je uspokojit, které jsou typicky způsobeny vývojem technologií.
• Hlavní důsledek výše zmíněného důvodu spočívá ve změně konceptu podnikové organizace od přísně hierarchického k kolektivnímu.

Jakmile je tento důvod splněn a organizace se přesune z původně hierarchického na kolektivní styl chování, lze organizaci považovat za řízenou v procesně orientovaném způsobu. Nicméně tato změna vyžaduje mnoho částečných změn ve všech oblastech života organizace, přičemž každá z nich může být považována za kritickou. Navíc vzájemné vztahy mezi těmito oblastmi generují další související problémy, které je třeba řešit.

Informační systém v procesně řízené organizaci

Hlavním důvodem pro řízení organizace a jejího vývoje pomocí procesů je potřeba flexibility vůči se vyvíjející technologii a zároveň udržení kontroly nad vývojem organizace. Musíme být schopni operativně řídit vztahy mezi jednotlivými úkoly v organizaci definovanými jako byznys procesy namísto jejich "vázání" ve struktuře organizace. Toto osvobození byznys procesů od struktury organizace umožňuje udržet vývoj procesu pod kontrolou, flexibilně měnit jeho strukturu směrem k novým možnostem daným vývojem technologií. Chování organizace je pak flexibilní. Abychom dosáhli potřebné flexibility informačního systému, musíme ovládat "chování" informačního systému samostatnou komponentou, která umožňuje kontrolovat vztahy mezi jednotlivými funkcemi informačního systému pomocí definic procesů.

Informační systém v procesně řízené organizaci

Chování informačního systému v procesně řízené organizaci ovládá jeho klíčová komponenta: takzvaný systém řízení pracovních toků (Workflow Management System). Tato komponenta obsahuje model procesů a volá jednotlivé funkční komponenty informačního systému podle definic procesů. Stejným způsobem tato komponenta také využívá databázi, která kromě základních dat zpracovávaných funkčními komponentami obsahuje data o procesech a jejich podpoře (přesněji řečeno pro podporu jejich kontroly). Ve srovnání s tradiční koncepcí podnikového informačního systému, kde jsou vztahy mezi jednotlivými komponentami těsně vázány v struktuře systému, tato koncepce umožňuje operativně měnit chování systému přesně podle aktuální potřeby běžícího procesu.

Na obrázku vpravo je viditelná obecná struktura systému řízení pracovních toků (Workflow Management System), tak jak je definována standardy Workflow Management Coalition a lze ji popsat následovně. Centrální komponentou takového systému je takzvaný Workflow Engine. Ten řídí chování systému tím, že volá komponenty systému (klientské a volané aplikace na obrázku) podle definic aktuálně běžících procesů. Také umožňuje pracovat s definicemi procesů, vytvářet a operativně měnit definice a následně přizpůsobovat chování systému aktuální poptávce. Dalšími funkcemi systému řízení pracovních toků jsou správa a sledování průběhu procesu a také umožnění možné spolupráce s dalšími workflow enginy, pokud je to potřeba. Potřeba výše uvedených funkcí systému řízení pracovních toků vyvolává silný vztah k existujícím standardům, které umožňují stavbu informačního systému jako otevřeného systému, který je stále připravený na různá a v současné době ještě neznámá zlepšení, která by mohl přinést budoucí vývoj technologie.

Funkcionality informačních systémů a diagram toku dat (Data Flow Diagram)

Pro specifikaci obsahu informačního systému je nutné doplnit modely obchodních objektů a obchodních procesů o funkční model informačního systému ve formě diagramu toku dat.

Funkčnost informačního systému představuje podstatu jeho práce - to znamená, které obchodní aktivity informační systém podporuje a jak (jaké data / informace poskytuje). Z hlediska principů modelování je funkčnost informačního systému také odrazem reálného systému, odrazem skutečných procesů, které se provádějí s cílem zajišťovat vůli k vytváření, eliminaci nebo podpoře reálných objektů a jejich základních vztahů. V tomto smyslu by funkční model informačního systému měl být odvozen z modelu skutečných procesů a modelu objektů.

Nicméně, v samotném informačním systému - jako součásti reálného systému - se procedurální a strukturální prvky reality projevují specifickým způsobem: jako data nebo informace o skutečných vzájemně propojených událostech, jejichž znalost je zabudována do vlastností informačního systému. Informační systém přijímá informace o skutečné události ve formě svého vstupu a kombinuje je s dalšími známými událostmi, aby z jejich vztahu odvodil informace. Kombinování informací o různých časově nezávislých (asynchronních), ale fakticky souvisejících jevech vyžaduje ukládání informací (tj. zapamatování si události a čekání na další budoucí, fakticky související události). K tomu musí informační systém "znát" realitu. Přesněji řečeno, systém musí být schopen předpokládat primární (podstatnou) kontinuitu základních (podstatných) reálných událostí, tyto očekávané vztahy musí být "zakódovány" v jeho struktuře.

Data Flow Diagram

Data Flow Diagram (DFD) specifikuje funkční model informačního systému jako soubor funkcí a jejich vztahů. Funkce určuje, jaké procesy se provádějí v informačním systému, aby byl věrným modelem podporované reality. Procesy informačního systému ve skutečnosti odrážejí skutečné obchodní aktivity a procesy. Přesto není funkční algoritmický model (i když popisuje procesy). DFD popisuje funkce, které v systému existují, a podstatné spojení mezi nimi prostřednictvím datových toků. Jedná o statický popis. Popisované procesy jsou z informačního systému. Statický popis funkcí (neprocedurální) je potřeba během analýzy, aby bylo jisté, že všechny důležité behaviorální aspekty reality jsou informačním systémem plně modelovány. Procedurální aspekty chování informačního systému nejsou předmětem analýzy podnikové reality. Algoritmický popis konkrétních procesů informačního systému je proveden ve fázi návrhu systému (viz Deployment Diagram z UML). Funkční model systému tak představuje základní analytické zadání a výchozí bod návrhu systému.

DFD se vyvinul z takzvaných diagramů aktivit používaných v metodologii SADT. SADT (Structured Analysis and Design Technique) je metodologie, která se používá od poloviny sedmdesátých let.

DFD diagram

DFD má následující základní prvky: Funkce, Datový tok, Datové úložiště a Terminator.

Funkce je základním prvkem diagramu. Představuje proces zpracování dat. Podle principu modelování je funkce prvkem modelu chování reálného světa. Přesto nemůže být považována za obchodní proces, jak se často, ale chybně, předpokládá. Funkce je proces, který probíhá v informačním systému, a ten sám je specifickým modelem skutečných (byznys) systémů (včetně byznys procesů). Funkce tedy představuje jednotku chování informačního systému. Funkce IS se tedy nikdy nepřiřazuje k "fyzickým" prvkům chování reálného systému - byznys procesům 1:1, ale spíše M:N, jelikož typicky mnoho byznys procesů potřebuje splnit stejnou funkci IS, aby využilo jen část svých potřeb. Fyzicky funkce představuje transformaci dat, která vede k výstupu (transformace ze vstupu na výstup).

Datový tok představuje abstrakci jakékoliv formy přenosu dat v systému. Datové toky obsahují data, která jsou zpracována a uložena v systému. Symbolizuje ho čára s šipkou.

DataStore je abstrakce jakékoliv formy ukládání dat v informačních systémech. DataStore je úložiště dat (data uložená pro pozdější použití). Je znázorněn dvěma rovnoběžnými čarami. V technické symbolice tento symbol představuje přerušení, které poukazuje na to, že ukládání dat znamená přerušení toku dat v čase. DataStore jako "místo pro dočasné ukládání dat" se používá všude tam, kde je zpožděný (asynchronní) přenos dat mezi procesy. Vyjadřuje pouze skutečnost, že data jsou uchovávána (tj. tok je v čase přerušen) a neříká nic o konkrétní formě ukládání (což je otázka implementace IS). DataStore je sekundární (pasivní) prvek na diagramu - datové toky do něj a z něj musí vždy provádět funkce.

Terminátor je objekt, který nepatří do popisovaného systému. Terminátor (začátek nebo konec datového toku, zdroj dat, umístění a účel spotřeby dat) ukazuje externí zdroj nebo cíl dat (někdy také nazývaný externí entitou - objektem). Odráží tedy okolní (reálný svět) systém, se kterým informační systém komunikuje.

Konzistence diagramů DFD a jiných informačních modelů

Pravidla konzistence MMABP také potvrzují význam funkčního modelu jako integrované součásti modelů informačního systému, stejně jako projevují silnou potřebu nástrojů jako je UML, pokud plní své závazky v oblasti analýzy (a nejen splnění "uživatelských požadavků", jak je oblíbené v současných přístupech k vývoji aplikací).

Související články

• Softwarové inženýrství
• Metodika vývoje softwaru
• Vědecké modelování

Externí odkazy

• Obrázky, zvuky či videa k tématu Metodika modelování a analýzy podnikových procesů MMABP na Wikimedia Commons
• Information Modelling of Organizations