V první části tohoto článku jsme se zabývali postupnou změnou vnímání firemních procesů a tomu odpovídající úloze vytvářených procesních modelů v období několika posledních desítek let. Uvedli jsme, že nyní jsme svědky období, kdy se procesy vrací plně do rukou organizací, které je mohou uchopit jako klíčové objekty svého podnikání. Požadavky na podobu procesních modelů v tomto období diktuje zejména následná automatizace modelovaných procesů pomocí workflow nebo systémů BPM.



Workflow systémy aktivně podporují business procesy pomocí řízení toku práce, jeho směrováním společně s odpovídajícími informacemi od pracovníka k pracovníkovi. Pro tyto účely musí procesní model popisovat cestu toku pracovních položek mezi rolemi v organizaci včetně alternativních cest, ošetření výjimečných stavů, eskalací apod. Jinými slovy potřebujeme model vypovídající o rolích, aktivitách, stavech, rozhodováních a o řízení toku aktivit mezi rolemi – souhrnně o vzájemné interakci.
V poslední době se setkáváme se zcela jiným typem produktů – business process management systems (BPMS’s) – které spouští instance procesů na základě jejich definice zapsané ve formálním jazyce. Stejně tak jako „normální“ počítač spustí softwarový program, BPM systémy spouští sady procesů. Na první pohled je zde velká podobnost s workflow systémy, podstatný rozdíl spočívá v tom, že procesy se zde stávají primárními objekty, které mohou být řízeny, modifikovány a spouštěny. Procesy tak vystupují do popředí a stávají se viditelnými aktivy organizací.
Jednou z metod modelování procesů, která toto respektuje, je RIVA. Od řady dalších metod se odlišuje mimo jiné svým specifickým přístupem k odvození procesní hierarchie organizace a tvorbou modelů použitelných v dalších fázích pro automatizaci procesů. V tomto článku se budeme věnovat představení pouze klíčových principů této metody.

RIVA

RIVA je metoda pro identifikaci, modelování, analýzu a návrh procesů organizace. Kořeny této metody sahají do roku 1986, kdy si autoři Clive Roberts a Martyn A.Ould předsevzali vytvořit jazyk, který by umožňoval popsat proces a zároveň umožňoval proces popsaný v tomto jazyce na počítačovém systému „oživit“. RIVA používá dva základní typy diagramů:

• process architecture diagram (PAD) – používá se pro zachycení procesní architektury organizace,
• role activity diagram (RAD) – používaný pro detailní popis konkrétních procesů.

Celkový model organizace potom obvykle mívá jeden diagram PAD a jeden či více diagramů RAD.
Metoda RIVA obsahuje techniky pro:

• stanovení, jaké procesy musí organizace mít, aby mohla fungovat ve svém oboru,
• identifikaci a modelování existujících procesů nebo návrh zamýšlených procesů,
• kvalitativní analýzu procesů,
• použití procesních modelů pro identifikaci požadavků na informační systémy, workflow systémy či vytvoření procesních modelů pro vývoj systémů BPM.

Zaměříme-li se na organizaci pohledem metody RIVA, vidíme za chodu se vyvíjející síť paralelních, spolupracujících instancí procesů. Jedna instance procesu může aktivovat instanci jiného procesu, dvě či více instancí mohou spolupracovat prostřednictvím interakcí, které jsou chápány jako synchronizace stavů instancí procesů. Specifický pohled má metoda RIVA na zapouzdření procesů, v běžné praxi procesního modelování reprezentované v podobě dekompozice. RIVA doporučuje uvědomit si, že se jedná pouze o modelovací konvenci, která velmi pravděpodobně nemá v reálném světě adekvátní obraz. Pokud tedy k dekompozici přistoupíme, měli bychom pochopit celkovou procesní architekturu a použít stavy znázorňující, jak si odpovídá začátek a konec dekomponovaného procesu s procesem na vyšší úrovni.


Obr.1: Typy procesů
RIVA rozlišuje tři základní typy procesů:

• Case process (CP) – reprezentuje instance jednotek práce (UOW – units of work), typicky pojmenované jako „provést…“, „připravit…“ apod.
• Case management process (CMP) – řídící case procesy, zahrnují aktivity plánování, vykazování, sledování, prioritizaci, vyjednávání, obsazování zdroji. V principu existuje ke každé UOW case management proces, který řídí tok UOW. Tyto procesy existují pouze v jedné instanci. V případě potřeby aktivují příslušné case procesy nebo s nimi interagují.
• Case strategy process (CSP) – poskytují dlouhodobé interní či externí pohledy, nakládají s CP a CMP procesy a ovlivňují jejich podobu v souladu se strategií organizace.

Uspořádání uvedené trojice typů procesů ilustruje obrázek 1.

Procesní architektura organizace

Principiálním pohled metody RIVA na procesy probíhající v organizaci spočívá v uvědomění si složité sítě současně probíhajících instancí procesů, které spolu navzájem interagují. RIVA nepracuje s tradičními diagramy hierarchie procesů ani s žádnou obdobou diagramů tvorby procesních řetězců (tvorby přidané hodnoty). Procesní architekturu, která musí zachytit tuto síť probíhajících procesů, RIVA odvozuje jedině z pochopení oblasti podnikání organizace. A jak přitom postupovat?

Identifikace základních business entit

Prvním krokem stavby procesní architektury je charakteristika oblasti podnikání organizace. Provádí se pomocí identifikace tzv. essential business entities (EBE’s) – základních business entit – věcí neoddělitelně spjatých s podnikáním organizace, bez kterých by toto podnikání nebylo možné. EBE může být něco zcela konkrétního (např. výrobek), nebo něco poněkud abstraktnějšího (test výrobku – probíhá, ale nemůžeme si na něj sáhnout), nebo něco zcela abstraktního (požadavek na změnu výrobku). EBE’s tak představují základ podnikání organizace – její podstatu. Při hledání seznamu kandidátů na EBE’s lze použít cílené otázky typu „Co vyrábíme?“, „Co prodáváme?“, „Jaké služby nabízíme?“, „Bez čeho se prostě neobejdeme?“, „Kdo jsou naši zákazníci?“ atd.

Výběr EBE’s představujících jednotky práce

Ne všechny identifikované EBE’s ale představují pro organizaci skutečnou práci. V dalších krocích se provádí filtrování identifikovaných EBE’s s cílem najít ty, které mají svůj životní cyklus, v jehož průběhu je nutné se o ně starat. Například výrobek má svůj životní cyklus, musí být navržen, vyroben, otestován atd. Proto patří mezi EBE’s, které představují tzv. essentials units of work – základní jednotky práce.

Zmapování vazeb mezi UOW

Mezi jednotkami práce existují vztahy vyvolané potřebou jiných UOW, například výrobek potřebuje sérii testů, aby mohl být dokončen. Pro následné kroky je třeba zjistit jejich typ a kardinalitu (1:1, 1:N).

Vytvoření procesní architektury organizace

První verzi procesní architektury organizace lze získat téměř mechanicky pomocí nalezených UOW a dvou základních idejí:

• Pro každou UOW existují potenciálně tři procesy – CP, CMP a CSP (např. pro UOW Objednávka existují procesy Zpracování objednávky – CP, Řízení objednávek – CMP a Strategické pohledy na objednávky – CSP).
• Každá vazba mezi UOW typu „generuje“ může být transformována na vazby mezi odpovídajícími procesy pomocí dvou typů standardních transformací „task force“ a „service function“, které se od sebe liší existencí CMP procesu nebo jeho zakomponováním do volajícího UOW.

Transformace vazby typu „service function“ mezi UOW A a B potom vypadá dle obrázku 2.


Obr.2: Vazba typu „service function“
Transformace typu „task force“ se liší tím, že neobsahuje nezávislý řídící proces A CMP, který je zakomponován v procesu A CP.
Procesní architektura vytvořená v předchozím kroku na základě UOW v praxi často zachytí více, než ve skutečnosti existuje. Dále se proto redukuje sestavená první verze procesní architektury pomocí několika technik, jejichž podrobný výklad nelze z důvodu rozsahu tohoto článku plně vysvětlit. Jejich společným smyslem je zjednodušení a zpřehlednění procesní architektury, které ovšem není provedeno na vrub věcného významu.
Následující obrázky ilustrují postup odvození velmi jednoduché procesní architektury pro softwarovou společnost. Předpokládejme, že tato společnost nabízí řadu softwarových produktů. Během života těchto produktů dochází k požadavkům na změny. Požadavky na změny jsou posuzovány, některé z nich zamítnuty, jiné zapracovány do nových releasů produktů.
Pomocí brainstormingu byly identifikovány tyto EBE’s: produkt, požadavek na změnu, release, obchodník a zákazník. Která z těchto EBE’s představuje skutečné UOW, či jinými slovy, která žije svým vlastním životním cyklem, který musíme zajistit? Předpokládejme pro tuto chvíli, že se nezabýváme prodejem ani marketingem, ale pouze výrobou produktů k prodeji. Seznam UOW vypadá takto: produkt, požadavek na změnu a release.


Obr.3: UOW diagram
Předpokládejme dále, že náměty na nové produkty přichází odněkud zvenčí (pravděpodobně z marketingu) a požadavky na změny přichází opět zvenčí vývojové skupiny – od zákazníků.
UOW diagram vypadá podle obrázku 3. Transformací a následnou redukcí docházíme k návrhu procesní architektury podle obrázku 4.


Obr.4: Procesní architektura
Procesy zachycené na modelu procesní hierarchie (PAD) jsou v dalších krocích detailně namodelovány pomocí diagramů RAD. Vysvětlení jejich notace je ovšem nad rámec rozsahu tohoto článku, pro ilustraci uveďme alespoň část diagramu RAD pro proces Realizace release na obrázku 5.


Obr.5: Diagram RAD

Přínosy

Přínos metody RIVA spočívá především:

• v dostatečném množství technik pro identifikaci, modelování a analýzu procesů,
• ve způsobu odvození procesní architektury organizace,
• ve tvorbě procesních modelů snadno použitelných pro následnou automatizaci procesů pomocí workflow či systémů BPM.

Metoda RIVA, kterou jsme se snažili velmi stručně představit v tomto článku, patří mezi přístupy k procesnímu modelování, které jsou díky své filozofii a produkovaným modelům schopny dostát požadavkům na kvalitní procesní modely a naplnit tak výzvy poslední doby. V tomto ohledu je možné očekávat, že se s metodou samotnou a jejími principy budeme setkávat stále častěji.

Autor působí ve společnosti LBMS.