Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií Použítí CASE/CABE pro řízení workflow ve firmě (vazba na nástroje workflow, trendy, možnosti) Autoři: Dominik Matoušek Dominik Šimůnek Jan Veselý Iveta Havelková Filip Worsch Jan Rubáš Datum: 2011
86
Embed
Vysoká škola ekonomická v Praze · tools, business modeling software, enterprise modeling tools, business process management tools aj. Důvodem, proč je vhodné tyto nástroje
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Vysoká škola ekonomická v PrazeFakulta informatiky a statistiky
Katedra informačních technologií
Použítí CASE/CABE pro řízení workflow ve firmě (vazba na nástroje workflow, trendy, možnosti)
CASE nástroje poskytují celou řadu funkcí určených ke zvýšení produktivity práce. Dle IBM [IBM,
2008] jde zejména o:
● automatizaci přechodu mezi různými úrovněmi abstrakce:
○ „forward engineering” (generování kódu, případně modelů nižší úrovně),
○ „reverse engineering“ (vizualizace existujícího kódu, generování modelů vyšší
úrovně),
● automatické ověřování nebo přímé zajišťování konzistence různých modelů nebo jejich
prvků,
● zobrazování modelů z různých úhlů pohledů,
● generování dokumentace, přehledů aj.
Je však třeba vzít v úvahu i rizika a náklady, které se pojí s CASE nástroji (pomineme-li samotnou
cenu nástroje):
● čas a náklady na úvodní osvojení nástroje,
● náklady spojené s údržbou modelů v průběhu času (používání CASE nástroje může vést k
nutkání neustále udržovat modely aktuální, ačkoliv to v dané chvíli již nemusí být
optimální),
● čas ztracený nadužíváním nástroje (snaha dělat modely krásné, snaha zakomponovat do
modelu maximum informací – i těch, které nejsou při pohledu na model vidět, které lze
zobrazit pouze v daném nástroji),
● náklady na převod modelů mezi různými nástroji.
V každém případě je nutné vždy pečlivě zvážit, zda je CASE výhodné využít, či nikoliv, a to jak z
hlediska věcného přínosu při řešení daného problému, tak z hlediska nákladů.
2.1.3 Způsoby dělení CASE
Case nástroje se dělí podle několika různých hledisek.
a) Podle životního cyklu projektu:
Dělení CASE nástrojů podle životního cyklu projektu je nejčastějším dělením. Vychází z životního
cyklu projektu neboli fáze vývoje informačního systému či programové aplikace.
Pre CASE Podporuje činnosti předcházející vývoji IS (globální strategie).
Upper CASE Podporuje tvorbu analýzy a informační strategie.
Middle CASE Podporuje tvorbu globálního a detailního návrhu IS.
Lower CASE Podporuje fázi implementace.
Post CASE Podporuje uvedení IS do provozu, provoz, údržbu či reengineering.Tab. 1 – Rozdělení CASE nástrojů podle životního cyklu vývoje softwaru.
Pokrytí jednotlivých typů CASE nástrojů v různých fázích životního cyklu vývoje softwaru je
přehledně zobrazen na obrázku 4.
Obr. 4 - Pokrytí fází životního cyklu vývoje informačního systému různými druhy CASE [Chlapek, Řepa, 1997].
Rozdělení popsané výše se občas zjednodušuje na pouhé dvě kategorie:
• Upper CASE – tyto nástroje jsou pro tvorbu diagramu, generování reportu, formulářů apod.
Jedná se o podporu fáze analýzy a návrhu.
• Lower CASE – tyto nástroje jsou podporou pro fázi implementace, testování a řízení
konfigurací.
b) Podle interaktivity
Mezi CASE nástroje, které jsou interaktivní, patří nástroje podporující metodu návrhu.
Mezi CASE nástroje, které nejsou interaktivní, patří vývojové nástroje (překladače).
c) Podle fáze projektu vývoje software, v níž jsou využívány
• Front-end CASE nástroje - využívány v předchozích fází projektu (na podporu návrhu).
• Back-end CASE nástroje - využívány v následujících fázích projektu (nástroje podporující
testování).
d) Podle toho, zda jsou využívány během celého životního cyklu software
• Vertikální CASE nástroje – podpora dílčích kroků životního cyklu software (kódování,
zjišťování uživatelských požadavků).
• Horizontální CASE nástroje – podpora několika kroků životního cyklu software (řízení
konfigurace, tvorba dokumentace).
e) Podle stupně integrace
• CASE tools – zabezpečení automatizované podpory jakékoli úlohy životního cyklu
software.
• CASE toolkits - soubor integrovaných softwarových nástrojů, který poskytuje částečnou či
komplexní podporu v rámci jedné fáze životního cyklu software.
• CASE workbenches - množina integrovaných CASE tools nebo CASE toolkits, která
poskytuje částečnou či komplexní podporu v nejméně dvou fázích životního cyklu software.
• I – CASE - představuje nejvyšší stupeň integrace a propojení několika CASE tools, CASE
toolkits a CASE workbenches
2.1.4 Vývoj CASE nástrojů
Co se pod pojmem CASE skrývá, již bylo popsáno v předchozích kapitolách. Kde se však tento
termín vzal? Vznik CASE nástrojů lze datovat shodně s nástupem softwarového inženýrství. To se
začalo formovat na konci 60. let, kdy začala tzv. softwarová krize, kdy výkon hardware předčil
vývoj software. Charakteristickými znaky této krize bylo neúnosné prodlužování a prodražování
projektů, nízká kvalita programů, nesnadnost či nemožnost údržby a inovace, špatná produktivita
práce programátorů, neefektivita vývoje a řada dalších.
Příčin této krize bylo hned několik:
● Špatná komunikace mezi vývojáři a zákazníkem.
● Malé kompetence zákazníka - většinou byl na dodavateli závislý a byl nucen tolerovat
nedostatky.
● Nesprávné odhady času, nákladů i rozsahu.
● Nízká produktivita práce.
Zlomem lze označit konferenci NATO v roce 1968 ve středisku Garmisch Partenkirchen v
Německu, kterou lze označit za místo narození softwarového inženýrství. Do té doby se počítače
využívaly převážně pro vědecko-technické výpočty, kde záleželo spíše na preciznosti řešení, než
na efektivitě vývoje. Jednalo se o průkopnickou etapu, kdy programátoři vytvářeli programy šité na
míru danému počítači či architektuře. Vytvářené programy jsou většinou neudržované a neměnné
a často vypáleny na trvalé paměti.
V 70. letech dochází k formulaci základních principů tohoto oboru, tvorba programů začíná být
častějším jevem, hardware se stává dostupnější. Začínají se vytvářet první aplikace umožňující
interakci s uživatelem. Z tohoto období pochází také značná část dodnes používaných technik -
specifikace, návrh, architektura, testování, zajištění kvality, modely životního cyklu atd. V dalších
letech jsou vyvíjeny metodiky pro analýzu. Vzniká také první verze generace nástrojů pro podporu
této disciplíny, což jsou právě CASE nástroje. Původní myšlenka CASE nástrojů byla ta, že už
nebude potřeba programátorů, tedy, že CASE nástroj vygeneruje již samotný kód, který bude
připraven k použití bez jakýchkoliv úprav a zásahů.
80. léta jsou pro CASE boomem, zásluhu na tom má příchod GUI (grafické uživatelské rozhraní).
V tomto období nastupují objektově orientované přístupy, objektově orientovaná analýza a
objektově orientovaný návrh. Hlavní výhodou byla možnost udržovat program na návrhové úrovni
bez potřeby znalosti zdrojového kódu. Ani nyní se však naděje, že CASE nástroje budou generovat
kód, nevyplnila. Stále přetrvával problém s udržováním aktuálních verzí modelů a kódů. Po každé
úpravě návrhu se musel změnit kód a naopak. Tento nedostatek se postupně podařilo odstranit -
nástroje začaly zajišťovat provázanost jednotlivých modelů a dále začaly poskytovat možnost
zpětného vytvoření modelu ze zdrojového kódu.
Dnes CASE nástroje představují podporu ve všech fázích procesu vývoje softwaru, nepomáhají již
pouze vývojářům, ale také např. v procesu řízení formy, kdy se zanalyzují stávající firemní procesy
a pomocí CASE nástrojů se postupně optimalizují.
2.2 Workflow
V dnešním světě firmy velmi často požadují vytvoření jakési platformy, která umožní spravovat
nesčetný počet business procesů probíhajících napříč odděleními, lidskými zdroji a firemními
systémy. Taková platforma by měla zajistit definování procesů (zpravidla grafický nástroj), klientský
nástroj pro provádění úkolů lidmi, monitorovací nástroje pro zjištění (ne)efektivity jednotlivých
procesů a také nástroj pro řízení jednotlivých procesů, neboli tzv. workflow engine.
Než se tedy pustíme do porovnání jednotlivých CASE/CABE nástrojů pro řízení workflow ve firmě,
je nutné se zastavit a vysvětlit obsah, který se pod slovem workflow skrývá. Workflow se často
používá v mnoha významech, někdy znamená business proces, jindy software, který zajišťuje jeho
automatizaci. Pro standardizaci pojmů v oblasti workflow se rozhodla instituce Workflow
Management Coalition2 (WfMC) vydat terminologický slovník [WfMC, 1999], ve kterém termín
workflow definuje jako:
“The automation of a business process, in whole or part, during which documents,
information or tasks are passed from one participant to another for action, according
to a set of procedural rules.”
Což můžeme přeložit takto:
“Automatizace celého nebo části podnikového procesu, během kterého jsou dokumenty, informace
nebo úkoly předávány od jednoho účastníka k druhému podle sady procedurálních pravidel.”
Podobně pojem workflow definuje i ředitel společnosti Kaktus Software David Kalous [Kalous,
2010]:
“Workflow je v pojetí IT v podstatě implementací byznys procesu v podobě technologického
nástroje, který pomáhá tyto postupy automatizovat.”
Jenže, jak zmiňuje Bruce Silver - nezávislý analytik a konzultant specializující se na oblast BPM
[Carda, Kunstová, 2003]:
“Workflow je dnes zprofanovaný termín, který může znamenat mnoho různých věcí.”
Pokusíme-li se přeložit pojem workflow, získáme výraz jako “pracovní tok”. Pracovní tok však
nemusí nutně znamenat svoji automatizaci, ta může být součástí podpory pracovního toku pomocí
informačních a komunikačních technologií, avšak samotný pracovní tok nemusí být nutně
automatizován. Autoři tohoto dokumentu se tedy spíše přiklánějí k definici pojmu workflow, jak ji
nadefinoval například Davenport [Davenport, 1996]:
“Workflow je strukturovaná a měřitelná sada činností sestavená tak, aby vytvářela specifikovaný
2 Založena 1993 pro zajištění standardizace a interoperability workflow management systémů (www.wfmc.org)
výstup pro určitého zákazníka nebo trh. Její součástí je značný důraz na to, jak se daná práce v
určité organizaci provádí.”
Případně, jak je nadefinována v dokumentu ISO 12052:2006:
“Workflow se skládá z posloupnosti propojených kroků. Je to zobrazení posloupnosti operací,
je prohlášen za dílo osoby, skupiny osob, práci organizace zaměstnanců, nebo stroje.”
Chceme-li pracovní tok, neboli workflow, automatizovat, využijeme pro to nepochybně
počítačových systémů. Počítačové systémy, které zajišťují fungující automatizaci podnikového
procesu nebo jeho části, se označují pojmem systémy řízení workflow. Systém řízení workflow je
tedy dle Workflow Management Coalition systém, který [WfMC, 1999]: “definuje, vytváří a řídí
průběh procesu. Je schopen interpretovat definici procesu, komunikovat s účastníky workflow a v
případě potřeby spustit další aplikace.”
Workflow systémy z pravidla podporují tyto fáze [Carda, Kunstová, 2003]:
1. Přípravnou fázi - neboli fázi definice procesu, jenž bude automatizovaně řízen
2. Realizační fázi - tedy řízení průběhu procesu
3. Sledovací a vyhodnocovací fázi - neboli tzv. monitoring a vyhodnocení reálného průběhu
procesu
Vidíme, že rozsah možností workflow systémů je dnes již široký a dalo by se říci, že zajišťují celý
životní cyklus procesu od jeho definice, přes realizaci až po jeho monitoring a na něj navazující
případnou optimalizaci procesu.
V definicích workflow systémů se neustále mluví o procesu či procesech. Proces můžeme
definovat jako [Řepa, 2006]: “souhrn činností, transformující souhrn vstupů do souhrnu výstupů
(zboží nebo služeb) pro jiné lidi nebo procesy, používajíce k tomu lidi a nástroje.”
V každé firmě probíhá minimálně několik procesů, jako příklad si můžeme uvést - sepsání
smlouvy, přijetí nového zaměstnance a zpravidla výrobní procesy atd. Workflow systémy v rámci
automatizace procesů mohou například posouvat určitý dokument k potřebným osobám, změnit
automaticky stav dokumentu na základě nějaké události atd. V reálu potom workflow systém
umožňuje například dle Kalouse [Kalous, 2010]: “vizualizaci procesů vyřizování objednávky, kdy je
v systému vidět, kdy objednávka vznikla, zda ji již někdo řeší, či zda je už vyřízena. Dále je třeba
možné v systémech sledovat stav montáže nového vozidla a podobně.“
Abychom sjednotili často používané pojmy v oblasti workflow a jejich významy, použijeme zde
obrázek vytvořený Workflow Management Coalition v rámci její snahy sjednotit pojmosloví v této
oblasti, jejímž cílem je usnadnění komunikace a porozumění v průběhu implementace systému
workflow ve firmě.
Obr. 5 - Vztahy mezi pojmy souvisejícími s workflow [WfMC, 1999] (přeložená a mírně upravená verze původního modelu WfMC převzata z [Novotný, 2009])
Z obrázku vyplývá, že proces je množinou několika činností / aktivit, které jsou vzájemně
propojeny. Tyto aktivity mohou být manuální, což znamená, že nejsou řízeny workflow systémem,
nebo automatizované. Každý proces je definován svojí definicí procesu, v níž se vyjadřuje vše, co
má proběhnout. Podnikový proces je řízen workflow management systémem, který řídí
automatizované části procesů či celé automatizované procesy. V rámci konkrétní instance procesu
se postupně zpracovávají dílčí instance aktivit procesu (odpovídají jednotlivým automatizovaným
aktivitám), které mohou obsahovat například spuštění určité aplikace, která aktivitu vykoná, nebo
přidělení úkolu účastníkovi workflow, jenž bude upozorněn na jemu přidělený pracovní úkol, který
musí vykonat (v rámci určitých pravidel - časových atd.).
2.2.1 Rozdíl mezi workflow a BPR
Blízko procesům má také jedna zkratka - BPR, pod níž se skrývá pojem Business Process
Reengineering. Aby nedošlo k omylům, považujeme za vhodné zde stručně vysvětlit, jaký je rozdíl
mezi těmito pojmy.
Kunstová vysvětluje BPR takto [Kunstová, 1999]: “Reengineering je aktem analýzy podnikových
procesů a jejich změny s cílem jejich zlepšení. Zahrnuje kombinaci odbornosti, dovednosti,
diplomatické zkušenosti, pohotovosti, taktnosti a manažerského citu.”. Důležité je především
použité slovo “zlepšení”. Řepa [Řepa, 2006] zmiňuje, že „BPR je kulturně zcela jiným přístupem,
než průběžné zlepšování procesů. Ve své extrémní podobě BPR předpokládá, že stávající
podnikový proces (procesy) je zcela nevyhovující – nefunguje, je špatný, je třeba jej z podstaty
změnit, od počátku.“ Workflow je však pouze softwarová technologie, která poskytuje prostředky
pro automatizaci podnikových procesů [Kunstová, 1999]. Zatímco tedy BPR se věnuje optimalizaci
a tedy i obsahovému zlepšení procesu a jeho změně, tak automatizace procesu zpravidla nemusí
vést k jeho obsahové změně a optimalizaci. Z toho můžeme usoudit, že firma může automatizovat
procesy bez jejich reengineeringu, nebo obráceně, tedy že výsledkem BPR aktivit nemusí být vždy
implementace workflow [Kunstová, 1999], neboť ne každý proces je vhodné či možné
automatizovat pomocí workflow. Návaznost BPR a Workflow ilustruje Kunstová [Kunstová, 1999]
následovně: „Využití nástrojů BPR pro popis životního cyklu pracovního toku začíná analýzou
existujícíh procovních toků. Potom se použijí nástroje BPR ke grafickému znázornění a zmapování
procesu včetně přiřazení úkolů a zdrojů. Simulační nástroje umožňují vyladění procesu. Po
ukončení optimalizace návrhu je definice procesu předána workflow systému, který zajistí jeho
automatizaci, bude řídit jeho zpracování, sledovat a evidovat průběh procesu a tyto statistické
údaje poskytovat BPR nástroji pro případnou další analýzu, eliminaci úzkých míst, simulaci a
optimalizaci.“
Tento vztah si můžeme ilustrovat na obrázku 6, který zobrazuje jeden z modelů metodiky MMDIS3.
Jedná se o model řízení podniku založený na procesním řízení a skládá se z 6-ti úrovní. V tomto
modelu bychom mohli BPR zařadit do druhé úrovně Vývoj produktů/služeb – definice a
optimalizace procesů a souvisejících metrik, kde se definují procesy, pomocí kterých chce podnik
realizovat svůj byznys model a své cíle. Workflow naopak spadá do úrovně páté Realizace
procesů, ale nepochybně i do úrovně čtvrté Monitoring procesů, neboť workflow řídí zpracování,
sleduje a eviduje průběh procesu. Výsledky monitoringu poté předává BPR pro případnou další
analýzu a optimalizaci, což naznačuje šipka ze čtvrté do druhé úrovně Změna definice procesu.
Obr. 6 – Model řízení podniku založený na procesním řízení [Voříšek, 2010].
3 Multidimensional Management and Development of Information Systems
Václav Řepa ilustruje rozdíl a vzájemné vztahy mezi BPR a Workflow následovně [Řepa, 2007]:
Obr. 7 - Konceptuální model business procesů a vazby BPR na Workflow.
2.2.2 Typy workflow systémů
Workflow management systémy můžeme rozdělit do kategorií podle několika hledisek. Carda a
Kunstová [Carda, Kunstová, 2003] klasifikují systémy workflow podle charakterů procesů,
technologické infrastuktury a orientace procesů. Podle charakteru procesů dělíme workflow
systémy na:
● Administrativní workflow
● Ad hoc workflow
● Produkční workflow
● Kolaborativní workflow
Administrativní workflow slouží k vyřizování běžné každodenní agendy, neboli automatizuje
opakované a podpůrné procesy jako například vystavení objednávky, vyřízení reklamace,
registrace vozidla, vyřízení žádosti o služební cestu a mnoho dalších. Ad hoc workflow se odlišuje
tím, že je založeno na náhodnosti procesu. Tím, že je proces náhodný, je možné jej nadefinovat až
v okamžiku jeho vzniku. Produkční workflow systémy, jak již název napovídá, podporují hlavní
podnikové procesy, které vytvářejí přidanou hodnotu k vyráběnému produktu nebo službě.
Především na kvalitním průběhu těchto procesů závisí spokojenost zákazníka. Poslední kategorií
je kolaborativní workflow podporující především týmovou spolupráci, kdy typicky členové týmu
společně pracují na určitém dokumentu, jenž je zpravidla výsledkem jejich společného úsilí (např.
návrh designu výrobku, zpracování kupní smlouvy atd.).
Rozdělení můžeme ilustrovat na obrázku 8:
Obr. 8 - Kategorie workflow systémů [Kunstová, 1999].
A pro podrobnější pochopení základních typů workflow systémů i na tabulce 2 [Carda, Kunstová,
2003]:
Produkční Administrativní Kolaborativní Ad-hoc
• Procesy jsou
podrobně
strukturovány,
• procesy jsou
formalizovány,
• většina
odchylek je
předem
ošetřena,
• procesy bývají
složité,
• je vyžadována
rychlá doba
odezvy, vysoká
průchodnost,
• vyžadují
integraci s
dalšími
aplikacemi,
• cílem je vysoká
• Procesy jsou
dobře
strukturované,
předem
definované,
• není
požadována
taková
průchodnost
jako u
produkčních
systémů,
• nahodile (v
nepravidelných
intervalech)
jsou tyto
procesy
využívány
většinou
uživatelů,
• procesy jsou
• Procesy nejsou
příliš
strukturovány,
• důraz je kladen
na zajištění
řízené
spolupráce
účastníků
procesu,
• důležítá je
snadná
dynamická
možnost změny
procesu,
• průchodnost
procesu není
rozhodující.
• Důležitá je
snadná a rychlá
definice procesu
v okamžiku
potřeby,
• procesy definují
koncoví
uživatelé,
• existuje možnost
dynamických
modifikací
procesů,
• požadavky na
průchodnost jsou
nízké,
• cílem jsou
nulové náklady a
žádná správa.
produktivita,
• konkrétní
procesy často
využívá
vymezený okruh
uživatelů.
obvykle spojeny
s formuláři či
jinými
dokumenty.
Tab. 2 - Porovnání základních typů workflow [Carda, Kunstová, 2003].
Workflow systémy můžeme dále dělit podle technologické infrastuktury. Zpravidla se jedná o
produkty založené na elektronické poště (mail-based), jenž využívají emailové servery a protokoly
SMTP4/POP35. Jejich použití je smysluplné především u kolaborativních a ad hoc workflow
systémů. Produkty založené na dokumentech (dokument-based) jsou obvykle rozšířením produktů
DMS6 a jsou založeny na představě směřování dokumentů (často za hranice firmy - komunikace s
externími aplikacemi). Třetí kategorií jsou produkty založené na procesech (process-based), jenž
jsou speciálně navrženy pro analýzu, automatizaci a řízení podnikových procesů. Zpravidla sem
patří produkční workflow systémy. A konečně poslední kategorií workflow systémů podle
technologické infrastruktury jsou produkty založené na webu (web-based), které využívají
jednotného prostředí intranetových či internetových aplikací dostupných prostřednictví webového
prohlížeče.
Poslední hledisko dělení workflow systémů, které zde ve stručnosti zmíníme je hledisko orientace
procesů. Procesy mohou být orientováné na lidi (people-centric) či na sebe (process-centric). U
systémů people-centric spoléhají účastníci především sami na sebe a průběh procesu je závislý na
těchto jednotlivcích, kteří se na něm podílejí. Příkladem takového procesu mohou být prezentace
nové služby, zákaznický servis atd. Naopak process-centric systémy jsou zaměřeny na klíčové
procesy, které jsou předpověditelné a mají především pevná pravidla řešení a zpracování (např.
pojistné události).
2.2.3 Architektura workflow systémů
Abychom mohli v praktické části práce rozebrat jednotlivé CASE a CABE nástroje pro podporu
workflow ve firmě, musíme pochopit základní stavební kameny systémů workflow. Těmito
stavebními kameny jsou zpravidla jednotlivé programové komponenty a vazby mezi nimi, jež
bývají, přestože na trhu figuruje velké množství workflow produktů, poměrně standardizovány.
4 Simple Mail Transfer Protocol5 Post Office Protocol version 36 Document Management System
Obr. 9 - Obecný model workflow systému [WfMC, 1995] (český překlad převzat z [Kunstová, 1999]).
Obrázek 9 ukazuje architekturu workflow systémů, kde tučným obdélníkem jsou zobrazeny
jednotlivé programové komponenty a nezvýrazněným obdélníkem tzv. datové komponenty.
Nejdůležitější komponentou systému workflow je nepochybně Výkonné jádro workflow, které řídí
průběh samotného procesu a udržuje statistiky o průběhu workflow. Předtím, než nějaký proces
budeme automatizovat, je nutné ho nadefinovat, nejlépe pomocí nějakého CASE nástroje, který
nám umožní bez znalostí jakéhokoli programovacího jazyka nadefinovat pomocí grafických objektů
proces. Tuto komponentu obsahuje dnes většina systému workflow a na obrázku obecného
modelu workflow systému je tato část pojmenována jako Nástroj pro definici procesů. Programové
komponenty Správce úloh a Uživatelské rozhraní umožňují komunikace uživatele s jádrem
workflow systému. Tyto dvě komponenty mohou tvořit jednolitý celek.
2.2.4 Referenční model workflow
WfMC (Workflow Management Coalition) vytvořila tzv. referenční model workflow, který
představuje architektonickou reprezentaci systémů workflow a identifikuje nejdůležitější rozhraní
(interfaces).
Obr. 10 - Referenční model workflow [WfMC, 2011].
Uprostřed obrázku 10 se nachází Výkonné jádro workflow (Workflow engines), které zajišťuje
zpracování výskytů procesů [WfMC, 1995]. To je “obaleno” Řídící službou workflow (Workflow
enactment service), která vytváří, řídí a spouští instance (výskyty) procesů. Může obsahovat i více
výkonných jader. Ostatní aplikace mohou s komunikovat s touto službou pomocí rozhraní
nazvaného workflow application programming interface (WAPI) dle [WfMC, 1995].
Mezi službou workflow a ostatními programovými komponentami či dalšími službami jsou
definována aplikační programová rozhraní (API). Referenční model workflow dle WfMC jich
definuje pět a v této části si je stručně rozebereme.
Interface 1 – Process Definition Tools x Workflow Enactment ServiceRozhraní mezi Řídící službou workflow a Nástrojem pro definici procesu zajišťuje jejich propojení a
zároveň umožňuje oddělit fázi návrhu procesu a fázi průběhu procesu. Můžeme tedy modelovat
proces v určitém nástroji s použitím určitého standardu. To umožňuje poté opakované použití
definice procesu ve více produktech workflow.
Interface 2 – Client Apps x Workflow Enactment ServiceRozhraní 2 je rozhraním mezi Řídící službou workflow a klientskými aplikacemi. Rozhraní musí
zajistit různé alternativy komunikace klientské workflow aplikace se službou. Pomocí této
komunikace může uživatel vyhledávat jednotlivé výskyty procesů, jednotlivé úkoly, zahajovat nový
proces, či ho přerušit, může zjistit informace o přiděleném úkolu atd. Klientská aplikace je tedy
přístupovým místem uživatele workflow systému, která mu obvykle nabídne přívětivé grafické
rozhraní.
Interface 3 – Tool Agent x Workflow Enactment ServiceTřetí rozhraní je rozhraním mezi Řídící službou workflow a externími aplikacemi (jak obrázek
napovídá, jedná se zpravidla o webové služby viz. kapitola o Web Services). Přístup k externím
aplikacím je většinou přes Aplikačního agenta, jelikož externí aplikace zpravidla dosahují vysoké
různorodosti a Aplikační agent tedy plní úlohu převodu standardizovaného API do specifického API
externí aplikace. Rozhraní musí umožňovat spuštění externí aplikace či její zastavení, oznámení o
dokončení činnosti a také předávání dat mezi službou a externí aplikací.
Interface 4 – Other Workflow Enactment Service x Workflow Enactment ServiceJednotlivé workflow systémy spolu mohou spolupracovat a mohou si zpracování na určitém
procesu rozdělovat či spolu jinak spolupracovat. Dokonce se na zpracování jednoho procesu může
podílet i více než dvě Řídící služby workflow, což vyžaduje jejich úzkou spolupráci a pokud možno
co největší interoperabilitu. Právě čtvrté rozhraní by mělo zajistit interoperabilitu mezi více Řídícími
službami workflow. Přes toto rozhraní si jednotlivé služby workflow předávají informace o výskytu
určité události (např. dokončení činnosti přidělené dané službě workflow, změna stavu činnosti či
třeba hlášení chyby).
Interface 5 – Administration & Monitoring Tools x Workflow Enactment ServiceSpráva a monitorování je umožněno díky pátému rozhraní. Páté rozhraní umožňuje klasickou
administraci - správu přístupových práv uživatelů či rolí a přířazení uživatelů k rolím, ale také třeba
operace řízení zdrojů, operace dohledu či funkce stavu procesu.
2.3 Standardy
Pro výběr vhodného CASE nástroje pro podporu modelování procesů a workflow je nutné nejdříve
zjistit, jaké podporuje modelovací standardy a jaké standardy chceme při práci využívat. V
následující části jsou uvedeny nejpoužívanější obecně uznávané standardy, které jsou často
využívány CASE nástroji. Jedná se o standardy BPMN, XPDL, Wf-XML, EPC, IDEF3 a BPEL.
Srovnáním standardů pro procesní modelování se věnoval ve své práci například Mareš [Mareš,
2010] a podle jeho analýzy, kdy měřil, jaké všechny požadavky rozdělené do jednotlivých dimenzí
splňují jednotlivé standardy pro procesní modelování. Porovnávány byly BPMN 1.1, IDEF3, EPC a
BPMN 2.0.
Obr. 11 – Srovnání standardů pro procesní modelování [Mareš, 2010].
Z obrázku je patrné, že si nejlépe vedl standard BPMN 2.0.
2.3.1 BPMN
Business Process Modeling Notation7 je celosvětově uznávaný standard společnosti OMG8 pro
modelování podnikových procesů, který určuje, jak má vypadat definice procesu zobrazeného
graficky na obrazovce či vytištěného na papíře. Zachycení procesu v grafické formě je důležité při
analýze a změnách procesů. Grafická forma procesu je srozumitelná nejenom IT odborníkům, ale i
uživatelům, se kterými je třeba průběh procesu konzultovat. Model procesu ve standardu BPMN je
možné převést na spustitelný program prostřednictvím jazyka XPDL.
Standard BPMN (Business Process Modeling Notation), byl vyvinut, aby umožnil tvořit
srozumitelné grafické znázornění business procesu. Grafická notace obsahuje soubor pravidel,
podle kterých je možné objekty spojovat. Dalším cílem BPMN bylo, vytvoření snadno pochopitelné
a použitelné notace. Tato jednoduchost ovšem neznamená, že by v ní nebylo možné vytvářet
složité business procesy. Tento standard byl vytvořen (verze 1.0 publikovaná v květnu 2004)
skupinou BPMI (Business Process Management Initiative) a v roce 2006 standardizován
konsorciem OMG (Object Management Group). Stěžejním úkolem bylo poskytnout notaci, která by
byla čitelná pro všechny uživatele – od analytiků přes programátory až po takové uživatele, kteří
budou procesy monitorovat a řídit. BPMN je také možné, díky jeho XML povaze, také využít pro
generování dalších formátů (XPDL, BPEL, BPEL4WS). Díky tomu BPMN vytváří most mezi
business orientovanou analýzou a designem procesů a jejich implementací.
7 Více viz. http://bpmn.org8 Object Management Group - http://en.wikipedia.org/wiki/Object_Management_Group
Na již zmíněných stránkách (http :// bpmn . org / ) je uvedena specifikace BPMN 2.0 z 3. ledna 2011.
Cílem BPMN 2.0 je sjednocení do jediné specifikace pro Business Process Model and Notation,
která definuje notaci, metamodel a vyměnné formáty pod známým a osvědčeným názvem
"BPMN". Mezi navržené vlastnosti patří:
● Spojeni BPMN s business process definition meta modelem BPDM do jednoho
konzistentního jazyka.
● Umožnit převod modelu mezi modelovacími nástroji.
● Umožnit uživateli rozdílný pohled na model podle jeho aktuální potřeby.
● Serializovat BPMN a poskytnout XML schéma pro transformaci modelů a rozšířit BPMN
směrem k procesnímu modelováni a podpoře businessu.
Zde následuje přehled grafických prvků BPM notace:
Event (Událost)
● značí se kroužkem
● přímo ovlivňují tok procesu
● události, kterými proces začíná, končí, či které nastanou v jeho průběhu
Obr. 12 – BPMN – Události [Wikipedie – BPMN, 2011].
Activity (Aktivita)
● obdélník s kulatými rohy
● znázorňuje činnost či práci
● může být buďto atomická (tzv. Task) nebo v sobě může obsahovat samostatný proces, pak
se tato aktivita nazývá subprocesem
Obr. 13 – BPMN – Aktivity [Wikipedie – BPMN, 2011].
Gateway (Brána)
● značí se čtvercem či kosočtvercem, stojícím na špici
● označuje rozbíhání či souběh toků procesu, např. rozhodování či paralelní zpracování
počáteční zavádění a konfiguraci (bootstrapping). Jednotlivé standardy jsou zobrazeny na obrázku
22.
Obr. 22 - Součásti WSIT [Mareš, 2008]
Počáteční zavádění a konfigurace spočívá ve využití URL adresy pro získání WSDL souboru a
jeho následné využití pro tvorbu klienta, který dokáže komunikovat a využívat služeb webové
služby, viz obrázek 23.
Obr. 23 - Komunikace s využitím WSIT [Mareš, 2008]
URL služby je možné získat například prostřednictvím UDDI. Klient využije nástroje wsimport pro
odeslání dotazu MetadataExchangeRequest webové službě a získá odpověď ve formě WSDL.
Součástí WSDL je i WS-Policy popisující bezpečnostní možnosti a požadavky služby.
Technologie na optimalizaci zpráv slouží k optimálnímu přenosu rozdílných dat jako text, obrázky či
video. Pomocí klasického SOAP se velikost přenášených dat v jiné než textové podobě zvětší a
zatíží se tím zbytečně síť. Optimalizace zpráv tedy zajišťuje optimalizaci XML, kdy doporučení
firmy Sun zmiňuje největší přenášený XML dokument 1KB.
Spolehlivé doručování je Quality of Service (QoS) technologie pro tvorbu spolehlivých webových
služeb. Spolehlivost měříme jako schopnost systému doručit zprávu z bodu A do bodu B bez
chyby. Technologie spolehlivého doručování zaručuje, že odeslané sekvence zpráv se ke svému
adresátovi alespoň jednou dostane a volitelně i ve správném pořadí. Pokud se zpráva ze sekvence
ztratí tak tato technologie umožňuje systému se z této ztráty vzpamatovat. Pokud se zpráva ztratí
během přepravy, tak ji klient znovu vysílá, dokud mu nedojde potvrzení o doručení, nebo pokud
zprávy dojdou ve špatném pořadí, dokáže systém správně uspořádat pořadí došlých zpráv.
Bezpečnost je ve WSIT zajištěna hlavně pomocí WS-Security44, který umožňuje bezpečnější
přenos zpráv a zajišťuje integritu obsahu i při průchodu zprávy mimo podnikovou síť. WS-Security
ve WSIT je možné využít společně se zabezpečením transportní vrstvy třeba pomocí Secure
Sockets Layer (SSL). Dalšími součástmi WSIT jsou Web Services Security Policy, která umožňuje
webovým službám definovat preference na zabezpečení konečných uzlů, a Web Services Trust47
pro odesílání SOAP zpráv se žádostí o bezpečnostní token, který je následně použit při tvorbě
důvěryhodné komunikace mezi klientem a webovou službou.
2.4.3 SOA
V souvislosti s webovými službami se nabízí otázka, zda nebudovat systémy tak, aby odpovídaly
standardům právě webových služeb. Koncept, který se zabývá principy a postupy, jak toho
dosáhnout, se označuje jako architektura orientovaná na služby (Sevice-Oriented Architecture,
SOA). K základním cílům podle [Gála, Pour, Toman, 2006] patří:
• adoptovat průmyslové standardy zahrnující webové služby a specifikace XML
• v co největší míře využít komerčních hotových softwarů, které poskytují adaptéry webových
služeb
• zapouzdřit stávající aplikace tak, aby byly dostupné prostřednictvím webových služeb
• použít nezávislé (integrační) vrstvy, která komunikuje prostřednictvím webových služeb
Definice podle [Erl, 2004]: “SOA je forma technologické architektury, která je založena na principu
služeb. Protože je realizovaná na technologické platformě webových služeb, vytváří SOA
potenciál, jak podporovat a rozšiřovat tyto principy v business procesech a nejrůznějších
podnikových oblastech.“
Podle Randyho Heffnera ze společnosti Forrester Research Inc. [Gála, Pour, Toman, 2006] lze
architekturu orientovanou na služby definovat takto: „Vzor pro návrh, vývoj a řízení (a) aplikací a
(b) softwarové infrastruktury a architektur v nichž:
• jsou aplikace organizovány v „business pracovních jednotkách“ (službách), které jsou
(typicky) dostupné na síti
• definice rozhraní služeb jsou prvotřídní vývojové produkty
• charakteristiky kvality služby (bezpečnost, transakce, výkon atd.) jsou explicitně definovány
v době návrhu služby
• softwarová infrastruktura přebírá aktivní zodpovědnost za řízení kvality služeb a vykonává
politiku přístupu ke službám a jejich realizace
• služby a jejich metadata jsou uloženy v repository
• protokoly a struktury v rámci infrastruktury jsou volitelně založeny na standardech (tj. např.
SOAP)“.
SOA je specifickým přístupem budování aplikací, který využívá principů webových služeb, a jako
část podnikové architektury:
• umožňuje pružně reagovat na potřeby organizace
• snižuje náklady na vývoj, protože umožňuje využívat hotových aplikačních balíků
• snižuje náklady na zajištění provozu a údržby
• minimalizuje náklady spojené se zajištěním integrace aplikací, neboť využívá standardů
• umožňuje i malým organizacím, aby se zapojily do elektronické výměny dat
2.4.4 YAWL
YAWL (Yet Another Workflow Language) je technologie, která má za cíl poskytovat podporu
systémového prostředí k definování, analýze a spouštění obchodních procesů a má vést ke
zjednodušení specifikace proveditelnosti obchodních procesů bez rozptylování „zbytečných“
technických úvah.
YAWL poskytuje komplexní řešení pro celý podnik a zároveň slouží pro uskladnění využití modelů
do budoucna. Podnikové scénáře mohou být komplexní a modelovací jazyk by měl být schopný se
potýkat s touto komplexitou. Podnikový analytik by neměl potřebovat opakovaně hledat dočasná
řešení k určení složitých aspektů podnikových scénářů, které se v praxi přirozeně vyskytují,
protože to může vést k procesním modelům, které nejsou jednoduché na pochopení a udržování.
YAWL momentálně čerpá z volně dostupných zdrojů a GUI editace, psané v Javě a vydáváno pod
LGPL. YAWL využívá XML Schema, Xpath, xquery a xforms přirozeně a je kompatiblní se SOAP a
WSDL. Vývoj je uskutečněn za pomoci Eindhoven Univerzity technologií v Nizozemí.
YAWL poskytuje silný, flexibilní koncept BPM platformy, která je celopodnikově integrovaná. Tato
platforma, využívaná manažery a analytiky, může pomoci, zlepšit efektivnosti v business aktivitách,
a zvýšit kvalitu služeb pro zákazníky. Dále také poskytuje silné příležitosti pro monitorování
procesů, integraci se vzdálenými procesy, korporační kontrolu a přizpůsobivost s nejlepší praxí.
3 Konkrétní produkty
V této části se nejdříve podíváme na trh CASE /CABE nástrojů pro řízení workflow firmy a
jednotlivé kategorie nástrojů, které umožňují modelování business procesů a workflow. V další
části si některé vybrané nástroje blíže představíme. Představení bude čistě ilustrativní a nebude
snahou jednotlivé nástroje mezi sebou konkrétněji porovnávat, neboť není možné provést
objektivní porovnání několika nástrojů vzhledem k subjektivním požadavkům každého jednotlivého
uživatele. Představení nástrojů tedy může sloužit jako úvod a souhrn základních informací o
nástrojích pro člověka přemýšlejícího nad výběrem nástroje pro oblast modelování workflow a
business procesů. Přínosem této kapitoly tak může být vytvoření představy o kategoriích produktů
umožňujících modelování business procesů a workflow a získání základní představy o hlavních
nástrojích.
3.1 Trh CASE / CABE nástrojů pro řízení workflow firmy
Produktů, které bychom mohli nazvat jako CASE / CABE nástroje pro řízení workflow firmy, je celá
řada. Zpravidla se nejedná o specializované nástroje pouze pro tento účel, ale o nástroje, jejichž
funkcionalita je mnohem širší a často se prolíná s jinými oblastmi. Na úvod představíme jednotlivé
kategorie produktů tak, jak je člení poradenská společnost Gartner14.
3.1.1 Produkty Business Process Analysis (BPA)
Podle Gartneru leží trh nástrojů BPA mezi trhy s produkty Enterprise Architecture a s produkty
BPMS [Gartner - BPA, 2010]. Nástroje BPA tedy mají společné prvky s nástroji na modelování
enterprise architektury15 (EA) a s nástroji na modelování a redesign business procesů. Nástroje
BPA tedy využují především:
● business architekti, kteří potřebují nástroj pro modelování enterprise architektury (EA)
● business process architekti, kteří modelují business procesy na konceptuální úrovni
● business process analytici, kteří modelují business procesy na detailní úrovni, často k
14 http://www.gartner.com/technology/home.jsp15 EA je „přístup, koncept, prostředek a nástroj, kterým vyjadřujeme fundamentální upořádání vztahu mezi byznysem a
jeho informačním systémem, které vede k naplnění mise organizace, přičemž respektuje okolní prostředí a konzistentně dodržuje formulované principy návrhu a rozvoje systému“ [Gála a Buchalcevová, 2008].
použití v BPMS.
Nástroje BPA jsou také spojovány se schopností vytvořit určitý most mezi IT profesionály a lidmi z
businessu, neboli propojení či navázání IT cílů a činností na business cíle tak, aby IT efektivně
podporovalo samotný business podniku - v tomto ohledu se mnohdy používá pojmu Business-IT
alignment16.
Firmy představující výrobce svých BPA produktů jsou zařazeny do kvadrantu podle úrovně
hodnocení ve dvou kritériích [Gartner - BPA, 2010]:
● completness of vision, což bychom mohli chápat jako potenciál dané firmy, strategickou
vyspělost a jasnou strategickou vizi.
● ability to execute - vyjadřuje schopnost výrobce prodávat a podpořit svůj ECM produkt a
služby.
Firmy, které dosáhnou nejlepšího hodnocení v obou kritériích se umístí v kvadrantu leaders, neboli
lídrů.
Obr. 24 - Magic Guadrant pro BPA (Business Process Analysis) [Gartner – BPA, 2010].
Podle Gartneru se v oblasti lídrů umístily následující firmy (viz. obr. 24):
● IDS Scheer - se svou sadou produktů ARIS. Nabízí i zdarma odlehčenou verzi ARIS
Express.
16 Stav, kdy podnik je schopen efektivně využívat informační technologie k dosažení business cílů. [http://en.wikipedia.org/wiki/Business/IT_alignment]
● IBM - s produktem System Architect a pro modelování procesů specializovaným
WebSphere Business Modeler.
● Metastorm - s produktem Metastorm ProVision BPA. Společnost Metastorm je však od
února roku 2011 součástí společnosti OpenText, která ji koupila za 182 milionů dolarů17.
● Mega - s produkty Mega Modeling Suite umožňujícími modelovat business procesy i IT
architekturu a mnohé další.
● iGrafx - se sadou produktů iGrafx Enterprise BPA tools. Nabízí různé úrovně produktu od
nejjednoduššího iGrafx FlowCharter vhodného pro začátečníky, přes iGrafx Process
určeného pro business process analytiky až po iGrafx Enterprise Modeler určeného pro
V této části naší práce bychom chtěli provést představení nejvýznamnějších produktů pro
modelování business procesů a workflow. Jak již bylo řečeno, nechceme se pouštět do srovnávání
nástrojů, neboť to je nutně subjektivní. Existují různá porovnání nástrojů, podle definovaných
kritérií, zda je daný nástroj splňuje, avšak ani maximální splnění všech kritérií nemusí být pro
každého výhodné, neboť pro jeho práci by mohl stačit například mnohem agilnější nástroj, které
umí především to, co sám uživatel potřebuje a požaduje, nehledě na to, že spousta kritérií se
nedají měřit jinak, než subjektivním hodnocením (uživatelské rozhraní atd.). Pokud na veškeré
snahy o porovnání jednotlivých nástrojů koukáme tímto pohledem, mohou být pro nás některé
studie srovnání přínosné, jelikož nám představují souhrn všech vlastností daných nástrojů, podle
kterých si již může uživatel vybrat daný produkt. V tomto smyslu poměrně zdařilé porovnání
nástrojů na modelování business procesů je k nalezení v práci Jana Mareše [Mareš, 2010], ve
které autor porovnává 8 nástrojů pro modelování business procesů podle 7 dimenzí různých
požadavků. Na obrázku 28 je vidět, že autorem definované požadavky nejlépe splňuje ARIS
Business Architect, ale stále to nemusí znamenat, že zrovna pro naši konkrétní potřebu musí být
vždy nejlepší a rozhodování musí probíhat vždy individuálně pro konkrétní použití a pro konkrétní
požadavky.
Obr. 28 - Srovnání nástrojů se stejnou váhou každé dimenze [Mareš, 2010].
V naší práci jsme se rozhodli vytvořit ucelený popis produktů, jež se umístily v kvadrantu lídrů v
Magic Guadrant pro Business Process Analysis od Gartneru. Jedná se o produkty ARIS Design
Platform, IBM WebSphere Business Modeler, Metastorm ProVision BPA, Mega Modeling Suite,
iGrafx Process a Microsoft Visio 2010.
Po představení těchto produktů z řady leadrů dle Gartneru jsme se rozhodli pro porovnání a pro
úplnost představit i vybrané open source nástroje z oblasti modelování business procesů a
workflow. Z velké řady open source produktů jsme vybrali dva rozdílné produkty – první je BizAgi
Process Modeler a druhý je Gliffy, který je možné využívat přímo v internetovém prohlížeči jako
Saas (Software-as-a-Service).
3.2.1 Struktura popisu
Pro usnadnění orientace v textu bude pro popis jednotlivých nástrojů použita jednotná struktura.
Sjednocením struktury popisu navíc dosáhneme i větší přehlednosti a usnadnění hodnocení a
srovnávání jednotlivých produktů. Pokud nástroj výrazně nevyniká v některé z dalších oblastí bude
použita následující struktura:
Obecné informaceZačínáme klasicky obecnými informacemi čili představením produktu a jeho stručným popisem,
abychom čtenáři představili, s jakým produktem má tu čest. Po krátkém představení nástroje a
společnosti, jež ho vyvíjí, se zaměříme na další základní informace jako jsou podporované
standardy a platformy. Část obecných informací uzavřeme hardwarovými a softwarovými
požadavky, jež jsou potřeba k instalaci a především používání jednotlivých produktů.
FunkcionalitaPo obecných informacích následuje asi nejdůležitější část a tou je funkcionalita, tedy informace o
tom, co konkrétní nástroj dokáže. Například popis modelů, které nástroj uživatelům nabízí a
metodiky, které podporuje. Pokud se nástroj skládá z více modulů a je tato informace relevantní
bude čtenář seznámen se strukturou a aplikační architekturou tohoto nástroje a funkcionalitou
jednotlivých částí.
Uživatelské rozhraníUživatelské rozhraní je oblast, jenž je většinou vnímána velice subjektivně. My se ho pokusíme
zhodnotit z pohledu přehlednosti, jednoduchosti, intuitivnosti ovládání a celkové přívětivosti pro
uživatele.
Podpora ze strany výrobceV části nazvané Podpora ze strany výrobce se podíváme, jaké portfolium služeb společnost
vyvíjející daný produkt nabízí. Ať už se jedná o českou lokalizaci, trial/demoverze pro vyzkoušení
projektu školení, dokumentaci nebo technickou podporu spojenou s diagnostikou a řešením
případných problémů.
● lokalizace, školení, dokumentace, technická podpora, demo verze
Licence a cena
Poslední část, jak již název napovídá, je zaměřená na finanční stránku věci. Pokud jsou tyto
informace k dispozici, bude čtenář seznámen s cenou nástroje a licenční politikou.
3.2.2 ARIS Design Platform
ARIS Design Platform je skupina produktů z rozsáhlého balíku integrovaných produktů ARIS
Platform, které vyvíjí společnost IDS Sheer. Společnost IDS Sheer společně se společností
Software AG, se kterou se v roce 2010 spojila, představuje globálního lídra na trhu BPM produků i
konzultačních služeb v oblasti procesního řízení. Svými produkty zcela pokrývá životní cyklus
řízení podnikových procesů – od analýzy a návrhu až po imlementaci, simulaci, optimalizaci a
monitoring [BPTrends, 2007].
3.2.2.1 Obecné informace
Název ARIS Design Platform (skupina produktů z rodiny produktů ARIS Platform)
Výrobce IDS Sheer (resp. Software AG, se kterou se společnost IDS Sheer v roce 2010 spojila) http :// www . softwareag . com /
Distributor pro ČR IDS Sheer ČR http :// www . ids - scheer . com / cz /
Verze 7.2
Podporované standardy
EPC, BPMN, BPEL, UML, IT City Planning, Zachman, TOGAF, TEAF, FEAF, DoDAF (dříve C4ISR), NAF, ArchiMate, SCOR, ITIL, eTOM, ISO9000:2000, TMF, APQC. ARIS dále zahrnuje proprietární procesně orientovaný architektonický rámec známý jako ARIS House. ARIS podporuje přes 150 notací. Uživatelé si navíc mohou vytvořit své vlastní.
Podporované platformy
Klientská aplikační platforma- MS Windows 2000/XP/Vista/7 Serverové, relačně databázové platformy- Microsoft Windows NT, Microsoft Windows 2000, Server Standard SP3/4, Microsoft Windows 2003 Server Standard SP1, HP-UX 11.11, Solaris 9/10
HW požadavky Přesné HW požadavky závisí na konkrétních požadovaných produktech a v případě serveru také na počtu uživatelů. Dle instalační příručky k ARIS Platform ([ARIS2, 2011]) jsou však
požadavky zhruba následující: Klient (minimální požadavky)- Intel Core2, 2,33GHz- 2 až 4GB RAM (4GB v případě instalace lokálního databázového systému)- alespoň 128KBit/s připojení- 2 GB volného místa na HDD ARIS Business Server (minimální požadavky)- Intel Xeon 5500 processor series, Quad-Core Intel Xeon- 64-bit systém- 16 GB RAM
SW požadavky Klientské stanice musí být vybavené prohlížečem MS Internet Explorer verze 6 a vyšší nebo Firefox verze 3 a vyšší. Dále je vyžadován Java Runtime Environment.
Tab. 2 – Obecné informace k produktu ARIS Design Platform.
ARIS Platform sestává z více než 20 nástrojů a komponent, které jsou orientované na různé
uživatele a na různé scénáře. Všechny produkty jsou však dobře integrované, a to nejen datově,
technologicky a graficky, ale i metodicky [BPTrends, 2007]. V souladu s doporučovaným přístupem
IDS Scheer k projektům zavádění procesního řízení jsou softwarové nástroje ARIS Platform
členěny do čtyř specializovaných skupin) [ARIS3, 2011], [DAVIS, 2007]:
• ARIS Strategy Platform – pro nastavení podnikové strategie, její procesní nasazení a
průběžné monitorování.
• ARIS Design Platform – pro distribuované modelování, simulaci, optimalizaci a publikaci
podnikových procesů a řízení IT architektur.
• ARIS Implementation Platform – pro přenesení podnikových procesů do prostředí SAP
NetWeaver, pro vývoj architektur orientovaných na služby a pro řízení podnikových
HW požadavky Nepodařilo se zjistitTab. 4 – Obecné informace o produktu Metastorm ProVision BPA.
3.2.4.2 Funkcionalita
Nástroj Metastorm ProVision BPA umožňuje dle [Metastorm, 2011] především:
● Procesní modelování - analýzu a design procesů s využitím notace BPMN či UML
● Podporu strategie - analýza toho, jak procesy podporují business cíle a business strategii
● Podporu standardů - nástroj podporuje oblíbené modelovací jazyky a standardy jako
BPMN, IDEF, UML
● Simulace - analýza výkonu procesů a pomocí metodu Monte Carlo a discrete event
simulátorů, umožňuje jak “as-is”, tak i “to-be” analýzy.
● Podporu spouštění procesů - umožňuje vygenerovat a testovat vytvořené modely pomocí
technologie BPEL, nebo exportovat procesní model do specifických BPM řešení jako je
Metastorm BPM.
● Podporu SOA - umožňuje importovat a exportovat WSDL popisy webových služeb.
● Integrace s řešeními EA a BPM - umožňuje případnou integraci s Metastorm ProVision EA
a Metastorm BPM.
● Integraci s dalšími nástroji - jako jsou Visio, MS Project, Excel, Word a různá řešení ERP,
workflow či BPM.
Vztah mezi produkty Metastorm ProVision EA, Metastorm ProVision BPA a Metastorm BPM je
vidět na obrázku 36.
Obr. 36 - Vztah mezi EA, BPA a BPM u produktů firmy Metastorm [Metastorm, 2011].
3.2.4.3 Uživatelské rozhraní
Nástroj nabízí běžné uživatelské rozhraní s rozmístěním jednotlivých základních prvků po
obrazovce tak, jak jsou uživatelé zvyklý i z jiných nástrojů.
Levá vertikální část obsahuje několik záložek - explorer, repository, inventory, model palette,
gallery, property. Tato část tradičumožňuje zobrazení struktury projektu a jednotlivých modelů,
jejich zobrazení či uzavření. Obsahuje také důležitou paletu modelovacích prvků.
Hlavní část obrazovky zobrazuje modelovaný proces a pouhým přetažením z palety modelovacích
prvků umožňuje jednoduše tvořit business proces.
Ukázka uživatelského rozhraní je na obrázku 37.
Obr. 37 - Ukázka grafického rozhraní [Metastorm, 2011].
3.2.4.4 Podpora ze strany výrobce
ŠkoleníSpolečnost Metastorm nabízí vzdělávací kurzy pro zájemce o různé problematiky týkající se
zaměření společnosti. Kurzy Business process analysis using Metastorm ProVision 6 jsou určeny
pro enterprise architekty i pro business analytiky. Tento kurz trvá 4 dny a není třeba žádná
předchozí znalost produktů Metastorm. Za tento kurz se účtuje 2600 USD a konají se minimálně
jednou za měsíc. Existují i pokročilejší a specializovanější kurzy vždy aktuálně vypsané na
stránkách Metastorm ProVision Training21.
LokalizaceProdukt není k dispozici v češtině. Je možné ho mít v následujících jazycích: angličtina,
francouzština, němčina, italština, španělština a japonština.
DokumentaceNa stránkách společnosti Metastorm není k dispozici podrobný návor na použití produktu, ale je 21 http://www.metastorm.com/services/provision_training.asp
možné vznést jakýkoli dotaz v Metastorm Community Central22.
Demo-trial verzeSpolečnost Metastorm umožňuje stažení trial verze na 30 dní. K použití trial verze je nutná
registrace a vyplnění následně zaslaného dotazníku, ve kterém je třeba specifikovat, k čemu
chcete program využívat a další doplňkové informace.
3.2.4.5 Licence a cena
Na internetových stránkách nejsou žádné informace o ceně produktů. Ani ze sekundárních zdrojů
se nepodařilo zjistit orientační cenu nástroje ProVision BPA.
3.2.5 iGrafx Process
iGrafx založený v roce 1987 pod názvem Micrografx, je od roku 2001 nezávislou obchodní
jednotkou společnosti Corel Corporation. iGrafx má v Evropě své pobočky v Německu a ve Velké
Británii. IGrafx je předním poskytovatelem Business Process Analysis (BPA), řešení pro flexibilní
navrhování, optimalizaci a implementaci procesů, za účelem zvýšení produktivity v celém podniku.
iGrafx účinně propojuje tři hlavní procesy: IT, Business analýza procesů a Iniciativy pro měřitelné
zlepšení produktivity.
Následuje výčet nabízených produktů:
• iGrafx FlowCharter
• iGrafx Process
• iGrafx Process for Six Sigma
• iGrafx Process for Enterprise Modeling
• iGrafx Proces for SAP
• iGrafx Process Central
• iGrafx Enterprise Central
• iGrafx Enterprise Modeler
• iGrafx Enterprise Modeler for SAP
• iGrafx IDEF0
3.2.5.1 Obecný popis
Název iGrafx
Výrobce iGrafx je divize společnosti Corel, Inc
Verze iGrafx 2011
Podporované standardy
BPEL, XPDL, XML, WSDL
22 http://communitycentral.metastorm.com/
Podporované platformy
Windows XP SP3, Windows Vista SP1, SP2; Windows 7
SW požadavky 32-bitové - Sun ® Java ™ Runtime Environment verze 1.3 nebo novější 64-bitové - Sun® Java™ Runtime Environment version 1.6 updateInternet Explorer 6 a vyšší nebo Mozilla Firefox 2.0 nebo vyšší (Internet Explorer 7 a vyšší nebo Firefox 3.0 nebo vyšší doporučeno)Pro export/import MS Office 2000, Acrobat Reader verze 7 nebo novější
HW požadavky Procesor Pentium ® II 350 MHz nebo vyššíPaměť 256 MB RAM, Hard Disk 106 MB
Tab. 5 – Obecné informace o produktu iGrafx Process.
3.2.5.2 Funkcionalita
iGrafx je rozdělen do několika verzí, které se odlišují funkcionalitou. „Lepší“ verze je vždy doplněna
o další funkcionalitu nad verzi „horší“. Přehled verzí je uveden v následující tabulce.
Obr. 38 – Přehled verzí iGrafx a jejich funkcionality (http://www.igrafx.com/products).
Obr. 41 - Ukázka uživatelského rozhraní [Mega, 2011].
Na výše uvedeném obrázku 41 můžeme spatřit uživatelské rozhraní nástroje, MEGA Process.
Vidíme, že obrazovka je rozdělena do dvou základních oken, kolem kterých je hned několik panelů
s nástroji. Nemohu zcela posoudit, jakým způsobem je zpracováno uživatelské rozhraní, jelikož se
mi nepodařilo tento nástroj získat. Z výše uvedeného obrázku usuzuji, že je nástroj velmi
komplexní a relativně přehledný.
3.2.6.4 Podpora ze strany výrobce
ŠkoleníNa stránkách výrobce je uveřejněno, že je k dispozici verze pro studijní účely pod názvem MEGA
Suite Education Version. Osobně se mi však tuto verzi nepovedlo získat. Dále na těchto stránkách
můžeme nalézt několik videí, které nám mohou pomoci se dozvědět základní informace o
uživatelském rozhraní. Mega také pořádá výukový seminář, který poskytuje zákazníkům informace
o nejlepším využití nástroje MEGA Suite.
LokalizaceNástroj MEGA 2009 SP5 je lokalizován v základních 4 jazycích. V angličtině, němčině,
francouzštině a italštině.
DokumentaceSpolečnost na svých stránkách dokumentaci poskytuje. Nicméně je třeba se nejprve zaregistrovat
a následně požádat o požadovaný dokument mailem.
Demo-trial verzeSpolečnost Mega sice na svých stránkách uvádí, že poskytuje trial verzi, nicméně jsem se k této
trial verzi nedostal.
3.2.6.5 Licence a cena
Licence je vázána na určitého uživatele a jeho počítač.
3.2.7 Visio 2010
V polovině července 2009 vydal Microsoft Technical Preview aplikace MS Visio ve verzi 2010.
Technical Preview je není jako finální produkt, ale spíše jako zkušební verzi.
Ke zjednodušení složitých konceptů pomáhají pokročilé nástroje pro tvorbu diagramů ve Visio
2010 a díky nim dochází k dynamickým, daty řízeným vizuálním prvkům a novým způsobům
sdílení na webu v reálném čase.
Aplikace Visio 2010 je jedním z nejvýkonnějších nástrojů pro zobrazování a výklad důležitých
informací. Hlavním důvodem je jednoduchost, obrazce přizpůsobující se datům a možnost sdílení
na webu.
3.2.7.1 Obecný popis
Název Microsoft Visio 2010
Výrobce Microsoft
Verze 2010 Technical Preview
Podporované standardy
BPMN, XPS, UML
Podporované platformy
Windows XP (nutně s aktualizací SP3) (32 bitů)Windows 7, Windows Vista s aktualizací Service Pack (SP) 1Windows Server 2003 s aktualizací SP2 a se službou MSXML 6.0 (pouze 32bitový systém Office)Windows Server 2008 nebo novější 32bitový či 64bitový operační systém
SW požadavky Microsoft Internet Explorer 6.0 nebo novější, pouze 32bitový prohlížeč. Pro využití funkcí Internetu je vyžadováno připojení k Internetu.
HW požadavky Paměť: 256 MB RAM (pro některé rozšířené funkce je doporučena paměť o velikosti 512 MB),
volná paměť: 2 GB volného místa na disku, procesor: 500 MHz nebo rychlejší
Tab. 7 – Obecné informace o produktu Visio 2010.
Dle výrobce (Microsoft) slouží Visio 2010: „pro vizualizaci a tvorbu diagramů, a to buď statických,
nebo dynamických, které se automaticky mění v závislosti na datech a v reálném čase. Visio
slouží k tvorbě organizačních a síťových diagramů, modelování obchodních procesů nebo
schémat podlaží, výrobních linek, ISO procesů a schémat architektury IT. Schémata lze sdílet
pomocí webového rozhraní nebo publikovat na server SharePoint.“.
Hlavní výhody Visio 2010:
• Předdefinované šablony – obsahuje velké množství předdefinovaných šablon pro
nejdůležitější procesy nebo diagramy;
• Rychlé kreslení – automaticky napovídá další logistické tvary, které můžeme nakreslit.
Rychlost je pomocí velké knihovny ikon a intuitivní uživatelské rozhraní;
CABE Computer-aided business engineering - kategorie nástrojů pro modelování podnikových procesů nebo jiných aspektů podnikání (podnikových cílů, organizační struktury, vztahů podniku s okolím atd.)
CASE Computer-aided software engineering - komplex počítačových nástrojů pro podporu zejména analýzy, návrhu a implementace IS/ICT.
CVS Concurrent Version System - systém sloužící ke správě verzí projektu.
DMS Document management system - systém pro správu dokumentů.
FDL Flowmark Definition Language - jazyk pro textovou interpretaci modelů.
FTP File Transfer Protocol - protokol pro přenos souborů v internetu.
GUI Graphical User Interface - grafické uživatelské rozhraní.
HTTP Hyper Text Transfer Protocol - protokol pro přenos souborů v internetu.
OASIS Organization for the Advancement of Structured Information Standards - organizace řídící standardy webových služeb a e-businessu
SCA Service Component Architecture - soubor specifikací popisujících model pro budování aplikací a systémů v servisně orientované architektuře.
SVG Scalable Vector Graphics - značkovací jazyk a formát souboru, který popisuje dvojrozměrnou vektorovou grafiku pomocí XML.
SOA Software Oriented Architecture - architektura IS/ICT orientovaná na služby
SMTP Simple Mail Transfer Protocol - internetový protokol určený pro přenos zpráv elektronické pošty.
UDDI Universal Discription, Discovery and Integration - standardizovaný přístup k implementaci registru webových služeb.
VB.NET Visual Basic .NET - moderní objektově orientovaný programovací jazyk založený na platformě .NET Framework.
VDX Virtual Document eXchange - meziknihovnový výpujční systém.
Workflow Řízení pracovních toků.
WS Web Service - volně spojené, znovupoužitelné SW komponenty, přístupné pře standardní internetové protokoly.
WSBM WebSphere Business Modeler - nástroj od společnosti IBM.
WSIT Web Services Interoperability Technology - produkt firmy Sun Microsystems, jehož účelem je zlepšení kompatibility mezi klienty a servery napsanými v jazyce Java a těmi napsanými pomocí .NET 3.0.
WSDL Web Services Definition Language - XML dokument popisující rozhraní webové služby.
WWW World Wide Web - služba Internetu, která prostřednictvím WWW prohlížeče zpřístupňuje uživateli informace spravované službou.
XAML eXtensible Application Maruk Language - deklativní jazyk vyvíjený Microsoftem a založený na XML
XMI XML Metedata Interchange - standard pro výměnu metada.
XML eXtensible Markup Language - značkovací jazyk uvádějící způsob zápisu struktury dokumentu, mechanismus vytváření logických struktur v dokumentu, pravidla deklarace elementů a vlastností apod.
XSD XML Schema Definitions - schéma popisující XML strukturu.