Obsah...2 Úvod...4 Business Process Management...5 Podnikové procesy...5 Typy podnikových procesů...5 Procesně orientované řízení...6 Historický přehled v přístupech k podnikovým procesům...6 Postupné zlepšování procesů...6 Business Process Reengineering...6 Business Process Management...7 Potřeba modelování podnikových procesů...8 BPMS...9 Procesní engine...12 Business Rules Engine...13 Business Activity Monitoring...14 Vybrané nástroje BPMS...15 Oracle Business Process Management Suite 11g...15 Pegasystems SmartBPM Suite...16 IBM BPM Suite...18 TIBCO iprocess Suite...19 Intalio BPM...20 Standardy BPM - BPEL, BPMN...22 BPEL...22 BPEL proces...25 BPMN...25
Srovnání BPMN s ostatními notacemi...27 CABE nástroje...29 Hlavní přínosy CABE...29 Vybrané nástroje CABE...30 PowerDesigner 15.0...30 System Architect...32 Visio...33 Aris Business Architect...34 Casewise Corporate Modeler...35 Open ModelSphere...36 Nástroje modelování pracovních toků...38 Modelovácí nástroje...40 Bonita...40 BizAgi...44 COSA...46 Balanced scorecard a BPE...49 Seznámení s Balanced scorecard...49 Proč používat Balanced scorecard?...50 Balanced scorecard jako nástroj...50 Aplikace metody Balanced scorecard...50 Aplikace metody balanced scorecard na fiktivní firmě...52 Zhodnocení aplikace techniky BSC...58 Zhodnocení využití aplikace techniky BSC...58 Závěr...60 Zdroje...61
Tato práce se zabývá nástroji modelování a řízení podnikových procesů z několika hledisek: kromě klasických modelovacích nástrojů jsme do práce zařadili rovněž nástroje, které lze využít před samotným procesním modelováním, jako možné vstupy. Takovým nástrojem je například metoda Balanced scorecard. Dále jsme do práce zařadili nástroje podporující celý procesní cyklus v podnikání, tzv. platformu nástrojů Business Process Management Suite (BPMS). Celá práce je strukturována do tří tematických bloků. V prvním bloku autoři definují oblast Business Process Managementu (BPM), která je mateřskou základnou pro podnikové procesy. Tato část vystihuje podstatu procesního modelování proč se vůbec podnikovými procesy zabývat, modelovat je. Druhá a zároveň stěžejní část práce je zaměřena na nástroje sloužící k modelování podnikových procesů. V rámci týmu jsme se rozhodli nezaměřovat práci na jeden určitý typ nástrojů užívaný při procesním modelování, ale vybrali jsme všechny, podle nás, zásadní softwarové i další prostředky související s podnikovými procesy. Konkrétně se jedná o nástroje typu CABE/CASE, Workflow, již zmíněnou metodu Balanced Scorecard, jež není typickým nástrojem chápaným jakožto softwarová aplikace, a platformu nástrojů BPMS. Každá kategorie nástrojů je popsána z hlediska teorie a rovněž jsme pro ni zařadili a uvedli několik produktů. Třetí oblastí, je podpora standardů v procesním modelování grafická notace BPMN a jazyk BPEL. Tyto standardy jsme popsali v teoretické rovině a hledali jejich místo na poli nástrojů BPM.
Tradiční způsob podnikání je založení společnosti, náboru nových zaměstnanců a jejich rozdělení do jednotlivých oddělení (zejména v případě větších společností). Každý zaměstnanec má v rámci svého oddělení přidělené pravomoci a odpovědnosti. Každý se zároveň soustředí zejména sám na sebe na náplň své vlastní práce. V důsledku to znamená, že nikdo příliš nesleduje ucelenost práce jednotlivých zaměstnanců. To logicky může vést k otázkám typu Nedělá se něco zbytečně? Nevykonávají se některé činnosti duplicitně? Nechybí nějaká klíčová akce, kterou nikdo nevykonává? Vzhledem k tomu, že se každý zaměstnanec orientuje na svou část práce, neexistuje jednotný přehled o činnostech různých zaměstnanců, které by měly tvořit určitý proces. V našem případě pod pojmem proces budeme rozumět vždy podnikový proces (z anglického originálu business process). Co to je podnikový proces? Podnikový proces je souhrnem činností, transformujících souhrn vstupů do souhrnu výstupů (zboží nebo služeb) pro jiné lidi nebo procesy, používajíce k tomu lidi a nástroje. (Řepa, 2007) Pokud bychom měli uvést vlastní definici podnikového procesu, mohla by být například takováto - jedná se o ucelený řetězec navazujících činností, jež vedou ke konkrétnímu cíli (v případě podniku uspokojení zákazníka), a během nichž jsou spotřebovávány zdroje (vstupy), které jsou transformovány na výstupy. Na tomto místě bychom rádi upozornili, že ačkoli užití výrazu uspokojení zákazníka může evokovat představu o zákazníkovi společnosti, není tomu vždy tak. Zákazníkem se myslí obecný zákazník daného procesu vždy to závisí na povaze podnikového procesu. Zákazníkem tudíž může být skutečný zákazník společnosti v případě objednávkového procesu, ale rovněž například zaměstnanec v případě procesu čerpání dovolené. Podnikové procesy lze dle prof. Řepy (Řepa, 2007) dělit na klíčové a podpůrné. Rozdíl mezi nimi je ten, že klíčové procesy jsou jakousi hnací silou daného podniku jsou základem daného byznysu a jsou tím, co přináší zisk. Jsou to takové procesy, které samy o sobě generují přidanou 5
hodnotu pro koncového zákazníka (tedy skutečného zákazníka společnosti). Naproti tomu podpůrné procesy nejsou pro koncového zákazníka nikterak významné, avšak své opodstatnění mají. Důvodem jejich existence je podpora klíčových procesů. Jsou to zdroje nutné pro fungování klíčových procesů. Příkladem podpůrného procesu je například čerpání dovolené, zatímco klíčový proces je například proces zpracování objednávky. Pokud by podpůrný proces čerpání dovolené neexistoval, těžko by se nějaký pracovník, jemuž je odpíráno vzít si dovolenou, staral o obchodní případy. Tento případ je poměrně extrémní, nicméně názorný. V posledních letech se stále více rozmáhá nový směr způsobu řízení podniku Business Process Management (v českém jazyce se užívá nejvíce pojem procesní řízení, případně procesně orientované řízení). Toto pojetí řízení se snaží oprostit od klasických struktur se zavedenými organizačními útvary a namísto toho staví jako svůj primární nástroj a cíl podnikové procesy. Business Process Management je manažerská disciplína a zároveň technologie, která říká, že podnikové procesy jsou alfou a omegou každé organizace. Procesy jsou tím, co firmu živí, a proto je třeba je dokonale ovládnout. V klasické literatuře (Šmída, 2007; Řepa, 2007) se často lze setkat s dělením BPM do tří etap. První etapa má počátek ve dvacátých letech minulého století a je spojována s Frederickem Taylorem. V této fázi jsou podnikové procesy ve firmě nastaveny pevně, nejsou za běhu nijak měřeny a na základě toho optimalizovány. Nicméně již v této době jsou procesy zdokumentovány a popsány pro využití při práci a čas od času dochází k jejich vylepšování. Druhá etapa se nazývá Business Process Reengineering (BPR). S reengineeringem jsou spojováni Michael Hammer a James Champy, tento přístup má kořeny v polovině devadesátých let. 6
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. (Řepa, 2007) Tato definice nám říká, že není třeba se ohlížet na minulost je možné, a reengineering to přímo vyžaduje, stávající proces ignorovat a namodelovat (nadefinovat) proces zcela nově. Díky tomu můžeme proces navrhnout tak, aby reflektoval skutečné požadavky kladené ze strany svého zákazníka. Třetí etapu zformulovali Howard Smith a Peter Fingar, kteří v roce 2003 publikovali knihu BPM: The Third Wave (Fingar, 2003). Podle těchto průkopníků BPM není ani reengineering podnikových procesů, ani trvalé konzervování podoby podnikových procesů. Neklade si za cíl zcela změnit veškeré procesy a ignorovat jejich stávající podobu. Naopak, bere je v potaz, vychází z nich a snaží se je průběžně vylepšovat na základě zvolených metrik. BPM není reengineering podnikových procesů, integrace dílčích podnikových aplikací, řízení workflow nebo další aplikace jde o sjednocení a prolnutí těchto technologií a metod do jednoho komplexního celku. Cílem BPM je optimalizace podnikových procesů s důrazem na jejich další rozvoj, nikoli na jednorázovou akci jako v případě reengineeringu. Význam 3. vlny spočívá ve schopnosti vytvořit jedinou definici (standardní vyjádření) procesu, v níž mohou být poskytnuty různé úhly pohledu na ten samý proces a postaveny různé informační systémy. To prakticky znamená, že různí lidé s různými odbornostmi mohou vidět stejný proces různě a nakládat s ním tak, jak jim to vyhovuje. Všichni přitom pracují s jediným zdrojem Například manažer může pracovat s výkonností procesu a porovnávat ji s KPI (Key Performance Indicators, klíčovými měřítky výkonnosti). Analytik si může zobrazit podrobnou procesní mapu, pro výkonné pracovníky je k dispozici procesní portál, výstupem pro programátora může být jazyk procesu, kompatibilní s programovacím jazykem atd. Právě schopnost vytvářet tyto různé pohledy z jednoho zdroje odlišuje 3. Vlnu BPM od předcházejících inovací. (Šmída, 2007) Zásadní odlišnosti těchto tří etap vystihuje tabulka 1. Faktor Zlepšování procesů (Kaizen) Inovace procesů (reengineering) 3. vlna BPM Úroveň změny inkrementální radikální týká se celého životního cyklu 7
Interpretace as is, to be současný proces, nová vylepšená verze starý proces, zcela nový procesdiskontinuita žádná způsobilost BPM, způsobilost BPM Výchozí bod existující procesy čistý list papíru nové nebo existující procesy Frekvence změn jednorázové nebo kontinuální změny periodicky prováděné jednorázové změny jednorázové, pravidelné, pokračující i evoluční Potřebný čas krátkodobý horizont dlouhodobý horizont v reálném čase Participace zdola nahoru shora dolů zdola nahoru i shora dolů Počet dotčených procesů Typický rozsah působnosti simultánní realizace, napříč několika procesy každý proces samostatně simultánní realizace, napříč mnoha procesy úzký, uvnitř funkcí široký, mezifunkční všechny procesy v rámci hodnotového řetězce Horizont minulost a současnost budoucnost minulost, současnost i budoucnost Riziko mírné vysoké nízké Primární umožňující nástroj statistická regulace informační technologie Nástroje off-line žádné on-line Zapojení odborníci odvětvoví specialisté všestranní pracovníci v oblasti businessu procesní technologie procesní inženýři a všichni zaměstnanci Práce praxe, zkušenost procesní procesní praxe, zkušenost Cesta k realizaci kulturní změna kulturní i strukturní změna matematický základ, procesní tech. standardy Tabulka 1 - Porovnání neustálého zlepšování procesů, reengineeringu a 3. vlny BPM. Upraveno podle (Šmída, 2007) Abychom mohli s podnikovými procesy pracovat, je třeba je poznat. Klasická poučka managementu říká, že co chceme řídit, musíme nejprve umět měřit. Jak jinak lze dosáhnout porovnání výkonnosti, pokud nemáme nastavené meze? 8
Jedním z východisek zkoumání reality je model. Model je svým způsobem zjednodušením reality abstrahuje od nepodstatných prvků (pro danou problémovou doménu). Zároveň model slouží jako vhodný komunikační prostředek, neboť běžná řeč je často příliš zavádějící, až vágní. Model nám nabízí prostředek, jakým můžeme nahlížet na danou problematiku obdobným pohledem. Nad stejným modelem (pokud je vhodně zvolen) mohou diskutovat lidé z oblasti byznysu i IT, což v případě mluveného slova neplatí vždy. Užitím modelu jako prostředku komunikace se snažíme eliminovat případné nejasnosti. Podnikové procesy nelze jen tak z hlavy vymyslet a doufat, že si všichni budou pamatovat, co kdy mají dělat. Naopak - pokud chceme práci řídit, musíme vědět, jak má být správně prováděna. Jestliže práce znamená procesy, pak vědět, jak práci dělat, znamená mít procesy zdokumentované. Touto dokumentací je procesní model společnosti, kde jsou zachyceny veškeré klíčové procesy a procesy podpůrné. Procesní mapa nám má ukázat souvislosti mezi klíčovými procesy generujícími přidanou hodnotu pro zákazníka a procesy podpůrnými. Modelování procesů však nesouvisí pouze s organizací práce. V dnešní době je pádným argumentem pro modelování procesů jejich další softwarová podpora, například pomocí nástrojů workflow. Automatizací procesů lze alespoň částečně omezit vznik chybových stavů a průběh jednotlivých procesů zrychlit, což obojí vede k vyšší spokojenost zaměstnanců i koncových zákazníků. Bez kvalitní dokumentace v podobě procesních modelů nelze podnikové procesy nikdy zcela poznat a ovládnout. A tím se vracíme zpět na rozpor mezi řízením a měřením pokud chceme procesy řídit, musíme je umět měřit. Pokud je chceme měřit, musíme zvolit nejen odpovídající metriky, ale hlavně vědět, co máme ve skutečnosti řídit. A právě zde se nalézá pravá podstata procesního modelování. Nástroje BPM prošly podle Ing. Kalendy (Kalenda, 2008) od devadesátých let minulého století dvěma etapami. V první etapě BPM byly nástroje neintegrované, nastavení nešla snadno překlopit do IS. Bylo třeba procesy namodelovat, v jiném nástroji je spustit, upravit IS, atd. V první generaci procesního řízení od počátku devadesátých let minulého století, šlo především o nástroje pro modelování podnikových struktur a jejich analýzu a také pro dokumentaci podnikové architektury. (BPM Portál, 2008) 9
Tento problém podle Ing. Kalendy řeší druhá generace nástrojů BPM - rozdíl v modelování je nově ve využití business modelu. Business model je konzistentní a vzájemně provázaný popis strategických cílů, měřitelných ukazatelů výkonnosti, procesů, pravidel podnikání, znalostí, organizačních struktur, rizik a IT služeb. (Kalenda, 2008) Tato změna chápání nástrojů BPM a nové technologie spadají pod koncept BPM 2.0 BPM druhé generace. O té lze podle Ing. Kalendy hovořit od roku 2005. Zásadní rozdíl oproti první etapě nástrojů BPM v sobě skrývá zkratka BPMS Business Process Management Suite. BPMS je platforma či soubor nástrojů, které dokážou podporovat uceleně celý životní cyklus podnikání. Jejich využívání je označování jako BPM 2. generace. (BPM Portál, 2008) Pod tím si lze představit fáze počínající od analýzy a designu procesu, přes implementaci a nasazení až po monitoring a následný koloběh tohoto cyklu. Tyto nástroje dnes podle Ing. Kalendy umožňují v reálném čase poskytovat data o jednotlivých průbězích procesu. To, co stojí za BPMS je servisně orientovaná architektura. V následující tabulce je stručně zpracován přehled základních rozdílů mezi nástroji BPM první a druhé generace. Nástroje BPM 1.0 Nástroje BPM 2.0 Funkcionalita prodávána business analytikům Modelování procesů Proprietární modelovací jazyky Průběžné zlepšování procesů Vysoké počáteční náklady Dílčí produkty pro jednotlivé fáze životního cyklu procesu Nástroje reálně využívány procesními analytiky Business model společnosti Standardizované modelovací jazyky Dynamické zvyšování výkonnosti Řešení možné i na bázi open source nebo jako služba Podpora celého životního cyklu business modelu společnosti integrovaně Tabulka 2 - Porovnání nástrojů první a druhé generace BPM. Upraveno podle (BPM portál, 2008) Odlišnosti nalezneme ať již v používání standardizované notace Business Process Management Notation (BPMN) a exekutivního jazyka Business Process Execution Language (BPEL) při samotném modelování podnikových procesů s vazbou na business model společnosti, či nově ucelenou podporou celého životního cyklu podnikání. 10
Ing. Kalenda shrnuje přínosy a jistou převratnost BPM 2.0 následovně: Analýza a design procesů, pravidel, dat, rolí a jiných zdrojů včetně výjimek je přímo propojeno na jednotnou repository - srdce BPMS, které oživuje řízení workflow, pravidel a chování volaných služeb. Navržené změny se tak přes integrační rozhraní přímo promítají do nastavení a chování celého IS. (Kalenda, 2008) Odpadá potřeba využívání duplicitních modelů a dat, BPMS pracuje s jednotnou repository. Hlavní moduly BPMS jsou: Procesní engine prostředí interpretující chování procesů popsaných v jazyce BPEL, Business Rules Engine (BRE) pro uložená pravidla dodává rozhodovací data nebo znalosti např. ze systému Business Intelligence, výsledky poskytuje jak pro řízení procesů, tak pro služby, které je vyžadují, Workflow zajištění interakce lidí v rámci procesů. Této části BPMS je věnována kapitola Nástroje modelování pracovních toků, Business Activity Monitoring (BAM) sledování výkonnosti procesů v reálném čase. Platformu nástrojů BPMS a vazby mezi jednotlivými prvky systému BPM v návaznosti na podnikové informační systémy znázorňuje obrázek 1. Podrobnější popis hlavních modulů BPMS následuje pod obrázkem 1. 11
Obrázek 1 - Platforma BPMS. Upraveno podle (BPM Portál, 2008) Jednou z hlavních komponent BPMS je na obrázku 1 znázorněný procesní engine. Vzhledem k tomu, že dnes je jazyk BPEL, kterému je věnována kapitola Standardy BPM BPEL, BPMN, chápán jako standard pro popis procesů v orchestraci webových služeb, lze pojmy procesní engine a BPEL engine zaměňovat dle potřeby. Jazyk BPEL pracuje se dvěma typy procesů dle úrovně abstrakce: Abstraktní proces - pouze zčásti specifikovaný proces, u kterého se nepředpokládá, že bude někdy spuštěn. Specifikuje pouze režim výměny zpráv, nikoli samotný procesní tok, Exekutivní proces do detailů specifikovaný a spustitelný proces v běhovém prostředí, tzv. engine. V našem případě se tím rozumí BPEL engine, jelikož BPEL je jazykem navrženým pro potřeby orchestrace. Proces popsaný v jazyce BPEL je vlastně XML dokument, který je vygenerován z modelu zhotoveném v příslušném modelovacím nástroji. S tímto dokumentem pak pracuje BPEL engine buďto jako rozhraní webové služby, případně pomocí podmínek nastavených uvnitř daného procesu. Procesní engine spouští daný proces a poskytuje ho svým uživatelům. 12
Možná podoba BPEL engine je webová služba, často s vlastním klientským prostředím. BPEL proces lze vytvořit v jakémkoliv textovém editoru, ale z praktických důvodů je tento postup značně neefektivní a vyžaduje hlubší znalosti XML. V současné době je dostupná spousta různých grafických editorů. Jedná se jak o komerční, tak i o volně dostupné a open-source produkty. Když zanedbáme jejich uživatelská prostředí, složitost, stabilitu ap., tak se většinou od sebe liší úrovní implementace BPEL a rozšiřitelností. Každá společnost většinou k danému editoru má i svůj vlastní stroj, na kterém lze daný proces spouštět. Vzhledem k trochu odlišné implementaci jazyka BPEL různými společnostmi a jeho možností rozšiřitelnosti o vlastní funkce dochází zde k nekompatibilitě těchto editorů a strojů. V případě nutnosti spouštět daný proces na jiném stroji než pro který byl určen, budeme v lepším případě potřebovat dobrou znalost obou produktů a jazyka BPEL. V horším případě to vůbec nebude možné. (Maršík, 2008) Do češtiny lze Business Rules přeložit jako pravidla podnikání. Pravidla podnikání jsou rozhodovací kritéria dodávaná pro jednotlivé procesy či služby. Příkladem může být proces přijetí objednávky pokud je objednávka vystavena na větší finanční hodnotu než 50 000 Kč, musí ji schválit finanční ředitel. Kritérium hodnoty objednávky vytváří v tomto případě pravidlo pokud je částka větší než určitá mez, udělej toto. Odlišný příklad může být situace, kdy pro všechny zákazníky, kteří nakoupí za 1000 a více Kč, bude udělena sleva ve výši 10% z celkové ceny. Opět se jedná o pravidlo podnikání. Pravidla podnikání je třeba důsledně evidovat, klasifikovat, hledat mezi nimi vztahy a řídit je. Ve vazbě na podnikové procesy platí, že ty zůstávají relativně neměnné, avšak pravidla, která jsou součástmi procesů, se mění velmi dynamicky. Proto je snaha pravidla podnikání od procesů oddělit, zpracovat je do samostatné komponenty. Podle (Raden, 2007) je Business Rules Engine samostatná softwarová komponenta, která pravidla podnikání vykonává. Tato pravidla nejsou přímou součástí aplikačního kódu, a tudíž je lze velmi rychle měnit bez nutnosti zasahovat do zdrojového kódu jednotlivých aplikací. Typicky jsou uložena v databázi, XML souborech, excelovské tabulce, či v různých skriptech. 13
Existuje několik druhů procesních strojů, v závislosti na tom, jak uložená pravidla vykonávají. Nejtypičtější jsou stroje, jež s pravidly pracují na bázi booleovského konstruktu IF-THEN. Tedy například jestliže je zákazník starší 18 let, smí si koupit výhodné balení alkoholu na e-shopu. Dalším typem stroje je reakční engine. Ten detekuje a reaguje na vzniklé situace například může upozornit skladníka, že na skladu je malá zásoba konkrétního typu zboží. Rozdíl mezi těmito dvěma typy strojů je ten, že první typ reaguje na konkrétní interakci s uživatelem, ten druhý vykonává pravidla automaticky. Většina dnešních Business Rules Engines umí zastávat obě zmíněné role. Výše zmíněný druh vykonávání pravidel postupuje směrem dopředu. Existují však i stroje jdoucí směrem dozadu tedy zjišťují co je potřeba, aby byl naplněn určitý cíl. Poslední kategorií Business Ruless Engine je deterministický engine. Ten může pracovat jak směrem dopředu, tak plánovat a zajišťovat potřebné akce na základě vytyčeného cíle, tedy zpětně. Jedná se o použití software, které sleduje průběh jednotlivých činností a procesu jako celku v čase. Vychází z agregace, analýzy a prezentace informací v reálném čase. Účelem aplikace tohoto typu je poskytovat data (analýzu) vlastníkům procesů a operačnímu managementu obecně. Umožňuje rychle nalézt problém a zavést potřebná protiopatření. BAM využívá obdobně jako systémy Business Intelligence tzv. dashboard k zobrazování dat. Na rozdíl od BI však pracuje s daty poskytovanými v reálném čase (on-line, případně near on-line daty), zatímco BI komunikuje s OLAP databází pomocí dotazů na data historická. Jinak si však BAM a BI dashboards mohou být vizuálně velmi podobné. Některé BAM systémy přímo poskytují možnost reagovat na vzniklé problémy, například formou zaslání zprávy (e-mail, text, hlasová zpráva) odpovědným lidem. Tento modul BPMS je sice klíčový, jedná se však o čistě komerční softwarové produkty. Pro předchozí uvedené komponenty existují různé open source varianty, které s vyvinutím úsilí lze vzájemně kombinovat a de facto si BPMS prostředí integrovat z volně dostupných nástrojů. BAM v současné době volně dostupný či jako open source neexistuje, lze ho do jisté míry simulovat pomocí nástrojů pro reporting. 14
V této podkapitole uvádíme několik konkrétních BPMS od různých dodavatelů. Vybrali jsme zástupce z kategorie komerčních BPMS od velkých softwarových firem a vedoucích hráčů na trhu s těmito produkty. Při volbě konkrétních platforem BPMS jsme vycházeli z výsledků analýzy provedené společností Gartner. Zvolili jsme řešení ze všech kvadrantů kromě třetího, ve kterém jsou nejméně konkurenčně výhodné produkty pro danou oblast. Obrázek 2 - Magic Quadrant BPMS dle Garner Producent Oracle Název Oracle Business Process Management Suite Verze 11g Datum vydání 07/2009 Licencování komerční WWW odkaz http://www.oracle.com/technologies/bpm/bpm-suite.html 15
Oracle Business Process Management Suite je dobrým příkladem komplexního BPMS. Ten je vystavěný nad databázovým systémem Oracle 11g, tedy nejnovější verzí. Mezi konkrétní moduly patří všechny hlavní zmíněné prvky. Jmenovitě Oracle BPM Suite nabízí následující komponenty: Oracle BPM kompletní IDE pro vývoj a optimalizaci business procesů, Oracle Business Rules Business Rules Engine, Oracle BPEL Process Manager procesní engine sloužící k vykonávání procesů popsané exekutivním jazykem BPEL, Oracle Business Activity Monitoring Business Activity Monitoring, Oracle WebCenter Suite portálová platforma. Producent Název Pegasystems Pegasystems SmartBPM Suite Verze 5.5 Datum vydání 07/2009 Licencování komerční WWW odkaz http://www.pega.com/products/ Společnost Pegasystems nabízí svá řešení BPM na trhu již 26 let. Za tu dobu se firma dostala do pozice lídra trhu díky svému rules-driven BPM. SmartBMP Suite se skládá z těchto komponent: PegaRULES Process Commander mozek a srdce SmartBPM řešení, Business Rules Engine je skrytý pod prvním názvem - PegaRULES. Process Commander je vývojové, exekutivní i monitorovací (pomocí dashboard) prostředí pro procesy, realizováné jako tenký klient pro spolupráci byznysu a IT, Process Analyzer využívá datové sklady, na nichž pomocí on-line nástrojů provádí analýzu (obdoba Business Activity Monitoring), 16
Process Simulator simulace nových podnikových procesů, předtím než jsou spuštěny v ostrém provozu. To umožňuje analytikům měřit a porovnávat výkonnostní charakteristiky a proces následně odladit před ostrým provozem, Enterprise Integration SmartBPM je vystaveno na SOA architektuře. Tato část se stará o integraci podnikových nástavců a konektorů, Case Management case-management aplikace, Content Management Integration integrace obrazových a dokumentových repository včetně DMS za účelem řízení veškerých procesů souvisejících s Records Managementem, Portal Integration integrace na úrovni webovských portálů pro spolupráci na bázi B2B. Jak je vidět, tento BPMS není pouhé BRE, BAM, workflow a procesní engine. SmartBPM jde dál a snaží se postihnout integraci řízení všech komponent, kterými podnikové procesy procházejí. Architekturu, ve které je SmartBPM vystavěno, znázorňuje obrázek 3. 17 Obrázek 3 - Architektura SmartBPM
Obrázek 4 - Varianty IBM BPM Suite Producent Název Verze Datum vydání Licencování WWW odkaz IBM IBM BPM Suite komerční http://www-01.ibm.com/software/info/bpm/offerings.html Řešení od IBM pokrývá celý životní cyklus podnikání, tedy od návrhu, po implementaci procesu, vykonávání a monitorování a následné změny. Zajímavostí je, že IBM nemá pouze jeden produkt, ale nabízí dvě možné varianty BPMS IBM WebSphere Dynamic Process Edition a IBM FileNet Active Content Edition. První ze zmíněných je vystavěno na platformě WebSphere, zatímco druhé řešení je založeno na nástroji workflow FileNet, jež IBM sama pokládá za lepší řešení pro firmy s BPM teprve začínajícími. IBM navíc nabízí jakési rozšíření obsahující pokročilé analytické nástroje, BPM repository, akcelerátory, nástroje pro spolupráci. Rozdíly mezi popsanými variantami znázorňuje obrázek níže. 18
Producent Název Verze Datum vydání Licencování WWW odkaz TIBCO Software TIBCO iprocess Suite Komerční / free http://www.tibco.com/software/business-processmanagement/iprocess-suite/default.jsp TIBCO Software je obdobně jako IBM jedním z lídrů na trhu BPMS. iprocess Suite poskytuje kompletní end-to-end řešení procesního řízení, po světě má více než 1000 zákazníků. Konkrétní komponenty, ze kterých se řešení skládá, jsou tyto: TIBCO Business Studio volně dostupný nástroj pro modelování a vykonávání podnikových procesů, TIBCO iprocess Decisions prostředí pro business analytiky k definování a řízení pravidel podnikání užívaných v procesních tocích, TIBCO iprocess Engine procesní engine, TIBCO iprocess Workspace rozhraní poskytující byznys uživatelům interakci s procesními instancemi. Toto rozhraní lze velmi snadno integrovat do portálových nástrojů či klientských aplikací, TIBCO iprocess Spotfire nástroj pro měření výkonnosti procesů a jejich analýzu (BAM), 19
TIBCO iprocess Conductor nástroj, jež se využívá pro procesy, které je obtížné modelovat strukturovaně, jelikož jsou příliš komplexní a dynamické. Tyto procesy jsou vykonávány za pomoci individuálních pomocných procesů. Producent Název Verze Datum vydání Licencování WWW odkaz Intalio IntalioWorks BPM Free / komerční http://www.intalio.com/products/bpm/ IntalioWorks BPM má dvě možnosti řešení. První volbou je IntalioWorks BPM Community Edition, která je zcela zdarma a 80% kódu je realizováno jako open source. Toto řešení se hodí spíše na menší BPM projekty. Pro velké společnosti zavádějící BPM je k dispozici čistě komerční IntalioWorks BPM Enterprise Edition, realizované jako open code. Obě řešení mají nástroje pro modelování procesů a jejich vykonávání spolu s návazností na workflow, nicméně nástroje typu BAM a BRE, které jsou dnes poměrně klíčové, jsou pouze ve zpoplatněné verzi. Enterprise Edition navíc nabízí portálové řešení, ESB, ECM. Architektura Enterprise Edition je ilustrována na obrázku. Řešení je vystaveno jako plugin pro vývojové prostředí Eclipse, kde lze procesy modelovat, a na BPEL engine Apache ODE, které je rovněž open source produktem. 20
Obrázek 5 - Architektura Intalio 21
V této kapitole blíže nahlédneme do kuchyně standardů BPM, konkrétně BPEL a BPMN. První část zmiňuje historický vývoj jazyka BPEL, jeho strukturu, vlastnosti a možnosti. Druhá část, věnovaná BPMN, se po stručném popisu notace věnuje porovnání této notace s ostatními, a predikci dalšího vývoje standardů vůbec. Standardizovaný jazyk Business Process Execution Language (BPEL) vznikl na základě spolupráce firem IBM, EA Systems a Microsoft. Nyní je pod vývojem Organizace pro pokrok ve standardizaci strukturovaných informací (OASIS). BPEL je exekutivním jazykem založeným na jazyce XML. Uplatňuje se při spolupráci a koordinaci mezi obchodními partnery, zejména v oblasti e-business a poskytování webových služeb. BPEL není pouze prostředkem pro modelování podnikových procesů umožňuje vytvářet spustitelné procesy, z nichž se volají jednotlivé webové služby. Jazyk BPEL je tak v jistém ohledu spíše programovacím jazykem. Vytváření spustitelných procesů v současné době představuje jeden z hlavních směrů vývoje a využití procesního modelování proto byl jazyk BPEL do této práce zahrnut. BPEL je založen na čtyřech standardech, bez kterých by nemohl fungovat. První z nich, zřejmě nejdůležitější, je XML - značkovací jazyk popisující strukturu a věcný obsah. Pro formální definici struktury dokumentu jazyka BPEL se využívá XML schémat, která striktně určují, co může a co nesmí být obsahem dokumentu. Pro orientaci ve vytvořeném dokumentu slouží jiný ze standardů s XML spjatých XPath. Posledním standardem je jazyk WSDL, využívaný pro popis rozhraní webových služeb. Kombinace výše zmíněných standardů nám poskytuje nutné minimum pro vytváření procesů v jazyce BPEL. Vytvořený proces v jazyce BPEL je ovšem pouze dokumentem ve formátu XML. Jako takový spustitelný není, k tomu je potřeba běhové prostředí. Běhová prostředí různých společností přistupují k exekuci BPEL procesu odlišně; buďto rovnou interpretují XML dokument nebo ho transformují do jiné podoby, kterou pak zkompilují a až poté proces lze spustit. Přehled vývoje jazyka BPEL: 2002 - BPEL4WS 1.0 - IBM, Microsoft, BEA 2003 - BPEL4WS 1.1 OASIS 22
2004 - WS-CDL - W3C (Kandidát) 2007 - WSBPEL 2.0 OASIS BPEL je výrazně podobný tradičním programovacím jazykům, obsahuje smyčky, větvení, proměnné, přiřazení atd. Tyto konstrukty nám dovolují namodelovat prakticky libovolný proces. Ovšem nejdůležitější vlastnosti jsou spojené s voláním webových služeb. Ty můžeme volat dvojím způsobem, synchronně a asynchronně. Můžeme spouštět operace jak sekvenčně, tak paralelně. Po asynchronním volání máme možnost čekat na tzv. callback (zpětné volání). BPEL také disponuje bohatou výbavou v oblasti obsluhy chyb, což je velmi důležité při vytváření robustních byznys procesů, a poskytuje podporu pro dlouho trvající procesy. Pomocí BPEL tedy můžeme: popisovat business procesy pomocí skládání služeb, skládat větší procesy ze služeb a již vytvořených procesů, pracovat se synchronními a asynchronními operacemi a přijímat tzv. callbacks, spouštět služby sekvenčně či paralelně, kompenzovat služby v případě chyby, přesměrovat příchozí zprávu patřičnému procesu, pracovat s událostmi, spouštět aktivity v určitém pořadí či za určitý čas, strukturovat business procesy." (Šafář, 2007) Jednotlivé služby mohou být skládány dvojím způsobem: centrální proces (může se jednat o další webovou službu) přebírá kontrolu nad službami, které jsou do procesu zapojeny, a koordinuje spouštění jednotlivých operací. Zúčastněné služby nevědí, a ani nemusí vědět, že jsou účastníky nějakého vyššího procesu. nevyužívá centrálního koordinátora. Každá zúčastněná služba přesně ví, kdy se má spustit a s kým má komunikovat. Všichni účastníci 23
Z hlediska skládání webových služeb, je orchestrace flexibilnější přístup než choreografie a jazyk BPEL je právě orchestračním jazykem. Instrumentace nabízí podle Šafáře (Šafář, 2007) tyto výhody: přesně víme, kdo je zodpovědný za celý business proces, můžeme spojovat služby, aniž by věděly, že jsou součástí procesu, v případě chyb můžeme vybrat jiný scénář procesu. BPEL rozlišuje procesy na spustitelné a abstraktní. Spustitelný business proces specifikuje veškeré detaily o procesu a může být spouštěn pomocí běhového prostředí BPEL. Abstraktní business proces není specifikován tak detailně a proto není spustitelný. Obrázek 6 Příklad schematického znázornění BPEL procesu. Upraveno dle (Šafář, 2007) Jazyk BPEL rozlišuje základní a složené aktivity. Základní aktivitou může být např. spuštění jiné webové služby, čekání na zprávu, generování odpovědi atp. Složené aktivity, podobně jako v BPML, řídí tok procesu. Komunikace probíhá tak, že BPEL proces obdrží požadavek, následně spustí patřičné webové služby a nakonec odešle odpověď zpět původnímu volajícímu. (Šafář, 2007) Webové služby mohou být spouštěny sekvenčně nebo paralelně, synchronně (čeká se na odpověď) a asynchronně (na odpověď se nečeká, pokračuje se v provádění procesu). 24
Spojení (links, též partner links) představují spojení ke všem účastníkům, s nimiž proces komunikuje. Rozlišujeme: spojení na webovou službu (invoked partner link), která je spouštěna, spojení ke klientovi (client partner link), který může spustit BPEL proces. Každý BPEL proces musí mít alespoň jeden client partner link, protože zde musí být nějaký klient, který spustí daný BPEL proces. Obvykle každý BPEL proces bude mít alespoň jeden invoked partner link, protože ve většině případů bude spouštět nějakou webovou službu. (Šafář, 2007) Jak uvádí samotná specifikace jazyka WS-BPEL (OASIS, 2007) BPEL proces specifikuje řád, ve kterém jsou služby sekvenčně či paralelně spouštěny. Umožňuje specifikovat podmínky, cykly, deklarovat proměnné, přiřazovat těmto proměnným hodnoty, ošetřovat výjimky a další. Doporučováno je grafické vyjádření BPEL procesu, tj. BPEL proces vhodným způsobem vizualizovat. Obvykle se tak děje buď v notaci UML či podobným způsobem v rámci komplexního řešení CASE nástrojů v portfoliu produktů společností tímto se zabývajících. S BPEL se lze setkat skutečně v řadě nástrojů, pro příklad uveďme Oracle BPEL Process Manager, Microsoft BizTalk, IBM WebSphere Business Integration Server, BEA WebLogic a další. Tento standard pro modelování podnikových procesů byl vyvinut konsorciem BPMI (Business Process Management Initiative), nyní za jeho vývoj zodpovídá skupina OMG. Modely BPMN využívají různých prvků, které jsou pro přehlednost rozděleny do čtyř kategorií a v rámci každé kategorie ještě do několika typů: 1) Objekty toku (flow objects): událost (event), aktivita/činnost (activity), brána (gateway). 2) Spojovací objekty (connecting objects): 25
sekvenční tok (sequence flow), tok zpráv (message flow), asociace (association). 3) Plavecké dráhy (swimlanes): bazén (pool), dráha (lane). 4) Rozšiřující objekty (artifacts): datový objekt (data object), skupina (group), poznámka (annotation). Z hlediska byznys perspektivy postrádá tento standard adekvátní prostředky pro modelování podstatné části náležitostí, jež hrají z hlediska modelování podnikových procesů organizace významnou roli. Již samotná filosofie tohoto standardu je čistě zaměřená na konkrétní technologickou realizaci modelovaných procesů. Jednotlivé atributy modelových elementů jsou čistě spojené se svým následným zpracováním v rámci integračního SW. Z těchto důvodů míra obecnosti standardu a jednoduchost standardu příliš nevyhovují. To samé lze tvrdit o možnostech modelování dimenzí jako je návaznost na organizační strukturu nebo spojitost s cíli organizace. Ačkoliv je BPMN silně specializovaným jazykem, má v nezanedbatelné míře podstatné průsečíky s obecnými nároky na standardy pro modelování podnikových procesů, pro potřeby vývoje SW, nebo jejich automatizace specializovaným SW. Svým konkrétním předjímáním provedení jednotlivých procesů standard přímo navádí své uživatele na jistý způsob uvažování o problémech. Z hlediska metodické podpory tohoto standardu lze konstatovat, že sama specifikace tohoto standardu se těmito otázkami nezabývá. Jedná se pouze o holý popis elementů a jejich atributů. Naopak, jelikož je BPMN do jisté míry relativně velmi rozšířeným standardem, je jeho vlastní podpora napříč nástroji velmi vysoká, a to i oproti faktu, že není zcela standardizované vlastní mapování na formát pro výměnu dat. Zároveň je specifikace tohoto standardu velmi konkrétní z hlediska popisu pravidel vlastní syntaxe což je žádoucí pro potenciální validování modelů. 26
Obrázek 7 - Porovnání BPMN s jinými notacemi. Upraveno dle (Kalina, 2009) Ačkoliv jsou všechny tyto standardy svým vznikem vztažené k oblasti informačních technologií, je vidět, že jak IDEF3, tak BPMN jsou v této perspektivě zhruba na stejné úrovni, a oproti EPC zaostávají přibližně o 20%. To je relativně zajímavé, neboť svým způsobem, jsou BPMN a IDEF3 víceméně antagonisticky pojaté standardy. BPMN je ryze specializovaný modelovací standard pro využití v oblasti tvorby procesů pro zpracování integračním SW, kdežto IDEF3 se zabývá obecným popisem sémantiky podnikového procesu, jako metoda pro konceptuální analýzu ve vztahu k budování IS/ICT. Možná interpretace by mohla být, že EPC poskytuje ideální rovnováhu mezi mírou konceptuality a využitelností výstupů modelování v dalších fázích vývoje SW. Je nicméně nutné připomenout, že je zde nutné brát ohled na možné zkreslení, které je dané konstrukcí variant jednotlivých charakteristik. Z vlastních hodnotících tabulek je patrné, že u IDEF3 je převažující jednoduchost a obecnost modelování, kdežto Scheer-EPC obětuje část těchto charakteristik a přidává robustnější popisné schopnosti. Z hlediska počtu charakteristik početně převažují ty spojené se samotnou vyjadřovací schopností standardu. To je jeden z důvodů vychýlení tohoto poměru na stranu EPC. Z hlediska BPMN je možné částečně prohlásit to samé jako o IDEF3, nicméně s tím, že BPMN se k Scheer-EPC přibližuje z opačné strany spektra a výsledky tohoto standardu jsou poznamenány jeho vlastní přespecializovaností. Druhým zjevným faktem je výrazný propad BPMN v rámci byznys perspektivy, kde dosahuje velmi nízkého výsledku. Tento výsledek se dá interpretovat jako zjevná nevhodnost používat tento standard k činnostem, jež jsou touto perspektivou zastupovány. Svým prvořadým zaměřením BPMN přehlíží mnoho dimenzí, které jsou pro modelování podnikových procesů v rámci organizace stěžejní (cíle, organizační struktura, apod.). Standard obsahuje také velké 27
množství elementů, které mají místy nepříliš intuitivní význam a pro uživatele mohou být následně obtížně interpretovatelné. Tyto vlastnosti jednotlivých elementů jsou samozřejmě dány tím, aby bylo možné v rámci BPMN modelovat klíčové rysy, které jsou třeba pro generování předpisu pro zpracování vhodným integračním nástrojem. Zajímavá je míra podobnosti mezi výsledky v rámci byznys perspektivy a ohodnocením vlivu standardů na zralost podnikového procesu dle modelu PEMM. Ačkoliv jsou jednotlivé standardy mezi sebou dost odlišné, jsou všechny postaveny na tzv. flow chart, navíc z pohledu PEMM nejsou kladeny přílišné nároky na deskriptivní schopnosti jednotlivých standardů. V oblasti procesního modelování existují (prozatím neúspěšné) snahy o jistou globální standardizaci, která by především měla usnadnit sdílení modelů mezi různými organizacemi. Nepředpokládáme přílišný úspěch těchto snah. Procesní modely nacházejí stále nová, navzájem odlišná, využití. To s sebou nese i nutnost jejich značné diverzifikace. Ve svých počátcích se procesní modely využívaly téměř výhradně k analýze a optimalizaci podnikových procesů (ať již ve smyslu postupného zlepšování či Business Process Reengineeringu) a snaha o jejich globální standardizaci jistě měla svá opodstatnění. V současné době se procesní modely vedle svého původního účelu používají i v oblastech celopodnikové komunikace, mezipodnikové spolupráce podnikových informačních systémů a webových služeb. V takto odlišných oblastech jsou na ně kladeny rozličné požadavky. Zatímco pro celopodnikové použití potřebujeme model srozumitelný a přehledný, v oblasti webových služeb je klíčová spustitelnost modelu. V některých zmíněných oblastech se zároveň odehrává velmi rychlý vývoj, a je tedy nutno, aby se modelovací nástroje vyvíjely spolu s modelovanou skutečností (to se týká zejména oblasti webových služeb). Proto předpokládáme, že budou i nadále vznikat mnohé nové standardy a metodiky a ty stávající se budou dále vyvíjet. 28
Zkratka CABE je akronym pro Computer Aided Business Engineering. Představuje skupinu nástrojů, které slouží ke komplexnímu modelování architektury podniku. Největší přínos znamenají v procesně řízených firmách, kde dokážou popsat strukturu všech procesů, vztahů mezi nimi a hierarchického uspořádání. Věcně správný popis procesů, klíčových i podpůrných, informačních a datových toků lze využít k efektivnímu dosahování podnikových cílů. Identifikace těchto cílů může sloužit k přesnější definici podnikové strategie. Nástroje CABE slouží k modelování podniku, jeho procesů, organizační struktury, datových toků, informační infrastruktury a cílů. S těmito nástroji se lze setkat i v dalších oblastech např. při plánování a budování worklow. (Řepa, 2007) Výstupy CABE nástrojů se využívají při návrhu nových podnikových informačních systémů a k optimalizaci či reengeneeringu struktury podniku a procesů. V současné době rozvoje servisně orientované architektury, jež přináší nový koncept pojetí a budování podnikových informačních systémů, jsou přínosy CABE nástrojů k optimalizaci podnikové struktury ještě významnější. Rovněž s využitím modelu Software as a Service lze výstupy CABE nástrojů podpořit přesnější formulaci požadavků na odebírané služby a jejich strukturu. CABE nástroje mohou sloužit v rámci podniku při vytváření katalogu a architektury ICT služeb. Hlavním přínosem CABE nástrojů je podpora podnikového řízení investic v oblasti ICT. Na základě analýzy výstupních dat CABE nástrojů lze formulovat informace využitelné při rozhodování v investiční oblasti. Lepší znalost organizační struktury, podnikových procesů, podnikové strategie vede k zefektivnění fungování celého podniku, jak na procesní úrovni, tak na technologické. Pomocí CABE nástrojů lze také odhalit potřebu modifikace, nebo nové implementace ICT infrastruktury. Přínosy využívání CABE nástrojů lze shrnout jako podporu při: Řízení investic v oblasti ICT, Identifikaci podnikových cílů a následné přesnější formulace podnikové strategie, Optimalizaci podnikové struktury a podnikových procesů, 29
Zvyšování efektivity podnikových procesů (reengineeringu), Optimalizaci ICT infrastruktury, Zavádění SOA, Rozhodování o outsourcingu. V přehledu vybraných nástrojů CABE jsme vyšli z materiálů předchozích zpracování tohoto tématu a doplnili je o aktuální informace. Jiný přístup ke CABE nástrojům jsme nezvolili z toho důvodu, že trh tvůrců a jejich produktů v této oblasti se příliš nemění. Vyvíjejí se pouze jednotlivé produkty, škála funkcionality a jejich prostředí jako reakce na požadavky zákazníků. Nástroje, jež jsme vybrali k popisu a srovnání: PowerDesigner, System Architect, Visio, ARIS Business Architect, Casewise Corporate Modeler, Open ModelSphere. PowerDesigner vyvíjí společnost Sybase a od roku 2008 je k dispozici ve verzi 15.0. Tento nástroj má přesah do oblasti CASE, jedná se o robustní modelovací nástroj. Slouží k vytváření objektových modelů, datových modelů, modelů business procesů, XML a DTD schémat. Lze jej využít pro návrh databáze od konceptuální úrovně, až po fyzickou úroveň datové základny. Umí u datových modelů generovat testovací data pro testování integrity databázového schématu. 30
Z objektových modelů podporuje PowerDesigner tvorbu modelu tříd, use case diagramu, diagramu sekvencí, komponent a aktivit. Umožňuje využití celé řady standardů a metodik. Podporuje UML 2.0, XML, DTD, BPEL4WS, BPMN a další. Podporuje velmi komplexní tvorbu dokumentace. Podporuje celou řadu vývojových prostředí (Java, C#, VB.NET, Hibernate, EJB3, NHibernate, JSF, WinForm (.NET and.net CF)) Vzhledem k poměrně velkému rozšíření představuje jakýsi etalon v praktičnosti a uživatelské přívětivosti designu pracovního prostředí, které je intuitivní a snadno ovladatelné. Obrázek 8 - Ukázka rozhraní v PowerDesigneru Producent Název Sybase Verze 15.0 Datum vydání 8/2008 Licencování PowerDesigner DataArchitect (datové modelování), Developer (objektové modelování), Studio (datové + objektové + modelování business procesů), Enterprise (+repository), Standalone (pevná licence na 1 PC) x Floating (plovoucí 31
licence) WWW odkaz www.sybase.com Za vývojem programu System Architect stojí nyní společnost IBM, která odkoupila Telelogic v roce 2008. Jedná se opět o robustní modelovací nástroj a je jedním z lídrů na trhu CABE nástrojů. Těžiště jeho využití leží v propracovaném modelování podnikových procesů. Podporuje vytváření procesních modelů, datových modelů, technologických modelů, metodu balanced scorecard, modelů servisně orientovaných architektur, aplikačních modelů. Podporuje standardy jako BPMN, UML, BPEL4WS, IDEF, TOGAF a další. Umožňuje přehledně propojit modely různých kategorií a skládat je jako komponenty jednoho celku. Podporuje analýzu míry podpory podnikových cílů. Podporuje přímé sledování nákladů v modelech pro jednotlivé ICT služby. Uživatelské prostředí není natolik intuitivní a přehledné jako například v případě PowerDesigneru. Obrázek 9 - Ukázka rozhraní System Architect Producent IBM Název Rational System Architect Verze 11.3 32
Datum vydání 10/2009 Licencování User License USD $3,700.00 WWW odkaz http://www-01.ibm.com/software/awdtools/systemarchitect/ Program Visio původně vyvíjela Visio Corporation a nyní, díky akvizici, spadá její vývoj pod křídla společnosti Microsoft. Visio je nabízeno jako součást určitých verzí kancelářského balíku Microsoft Office, nebo také jako samostatná aplikaci. V současnosti je ve verzi 12.0. Co do funkcionality a podpory podnikových procesů se nejedná o tolik robustní program, jako PowerDesigner nebo System Architect. Primárně slouží k vizualizaci schémat. Obsahuje mnoho šablon pro různé diagramy a schémata. Podporuje metodiku UML a proprietární Microsoft SmartShapes. Vytvořená schémata lze snadno exportovat do všech programů kancelářského balíku Office. Obrázek 10 - Ukázka rozhraní Visio Producent Microsoft Název Microsoft Visio Verze 2007 (12.0.6425.1000) 33
Datum vydání 4/ 2009 Licencování Retail price $559/$349 for Professional WWW odkaz http://office.microsoft.com Aris Business Architect vyvíjí německá společnost IDS Scheer. Jde o robustní nástroj pro komplexní řízení podnikových procesů a podnikové architektury. Funguje v moderním webovém prostředí. Disponuje intuitivním ovládáním a uživatelsky přívětivým prostředím. Podporuje standardy a metodiky BPMN, BPEL, ARIS, UML a další. Umožňuje detailní modelování, analýzu a optimalizaci podnikových procesů. Dále obsahuje celou řadu analytických funkcí, které mohou být využity při řízení podnikových procesů společnosti. Usnadňuje vytváření servisně orientované architektury, podporuje celou řadu metrik pro hodnocení výkonnosti jednotlivých procesů. Umožňuje správu rolí, práv a odpovědností. Obrázek 11 - Ukázka rozhraní Aris Business Architect Producent IDS Scheer Název ARIS Business Architect 34
Verze RSC-3 Datum vydání 2/2009 Licencování komerční WWW odkaz http://www.idsscheer.cz/cz/aris/aris_platform/aris_business_architect/34725.html Corporate Modeler od firmy Casewise je nástroj, jenž slouží ke komplexnímu modelování podnikových procesů. Umožňuje přehledné zobrazení celé podnikové struktury, která zahrnuje i zaměstnance, včetně všech podnikových procesů a vztahů mezi nimi. Pracuje s dynamickými objekty, které propojují IT architekturu s daty a procesy. Uživatelé mohou simulovat průběh jednotlivých procesů a testovat výsledky. Obrázek 12 - Ukázka rozhraní Casewise Corporate Modeler Producent Casewise Ltd Název Corporate Modeler Verze 2009.2 35
Datum vydání 11/2009 Licencování komerční WWW odkaz http://www.casewise.com/products/corporatemodelersuite/corporatemodele r Open ModelSphere od firmy Grandite je freewarový software určený k modelování podnikových procesů, databází a UML diagramů. Jde u multiplatformní nástroj, který je vytvořen v Javě. Původně komerční produkt je nyní nabízen jako freeware. 36
Obrázek 13 - Ukázka rozhraní Open ModelSphere Producent Grandite Název Open ModelSphere Verze 3.1 Datum vydání 11/2008 Licencování GNU General Public License WWW odkaz http://www.modelsphere.org/open_modelsphere.html 37
Ve spojitosti s podnikovými procesy se často objevuje termín workflow (do češtiny se obvykle překládá jako pracovní tok). Zjednodušeně lze říci, že workflow specifikuje, jak probíhá určitá práce od začátku do konce. Pracovní tok tvoří logika procesů a řídící pravidla. Logika procesů definuje sekvenci úkolů, jež mají být provedeny, řídící pravidla pak definují v jakých závislostech a limitech mohou být úkoly vykonány. Definice seskupení WfMC (Workflow Management Coalition), která je platná již 10 let, říká o workflow a podnikových procesech následující: Business proces je množinou procedur či aktivit, které dohromady realizují obchodní cíle v rámci organizační struktury, jenž definuje funkční role a vztahy. (Aalst, 2002) Workflow je automatizace podnikových procesů jako celku či jen jeho části, během níž dokumenty, úkoly a informace přecházejí mezi účastníky procesu na základě definované množiny pravidel. Skládá se z aktivit a jejich vztahů, identifikuje počátek a konec procesu, účastníky, aplikace a data. Workflow lze typicky hledat uvnitř velkých organizací, jako jsou banky, pojišťovny či státní správa. Velkým problémem dosavadního workflow je, že bylo vyvinuto mnoho standardů pro podporu workflow systémů, ale žádný z nich se nestal globálně uznávaným standardem, jaký představuje např. UML (Unified Modeling Language) v kategorii informačních systémů. Nejblíže k tomu dnes má jazyk WPDL (Workflow Process Definition Language). Nejprve se vyvinuly dokumentově orientované workflow systémy, jelikož kancelářská práce byla často spojena s velkým množstvím papírových dokumentů lišících se svojí funkčností. Množství dřívějších workflow systémů bylo zaměřeno na tok dokumentů mezi lidmi, kteří se workflow procesu zúčastňovali zejména tak, že k dokumentům přistupovali a měnili je podle toho, jaká role jim v rámci procesu byla udělena. Novější systémy jsou již obecnější. Nenabízejí pouze dokumenty, ale jakékoliv strukturované informace, komplexní zpracování událostí, programovatelnou manipulaci s informacemi a možnost rozšířit informace o webové služby a další externí zdroje informací. Vedle byznys požadavků na workflow systémy stojí rovněž požadavky vývojářů, kteří tlačili na standardizovaný přístup k návrhu workflow systémů. Během vývoje se objevila celá řada modelovacích jazyků či jiných formálních modelů, jež sloužily pro specifikaci vznikajícího 38
workflow systému. Velmi oblíbenými se staly Petriho síťe. Ty jsou stále velmi oblíbené mezi vývojáři workflow systémů, avšak vyžadují jistou dávku pochopení, která nemusí být vždy vlastní manažerům zadávajících komerční požadavky. Tudíž se stále hledají další modely, které by byly blízké oběma skupinám zúčastněným v rámci workflow systému. V dnešní době získávají na velké oblibě zejména standardy BPM, které se zabývají životním cyklem definice procesů. Vývojáři je mohou efektivně využít a podnikoví analytici jim rozumějí. V roce 1999 začala skupina na Eindhovenské technické univerzitě s výzkumem takzvaných Workflow Patterns (workflow šablon). Cílem je poskytnout koncepční základ pro modelování a návrh procesů. Jejich výzkum je rozdělen do několika kategorií (řízení, data, zdroje a správa přerušení procesů), které je třeba podporovat v rámci jazyka pro definování firemních procesů. Podle (WPI, 2009) jsou workflow šablony ustálená řešení typických situací při modelování firemních procesů s využitím diagramů BPD. Popisují jak modelovat určitou specifickou návaznost aktivit, např.: modelování paralelních procesů, modelování cyklů, modelování přerušení procesů. Workflow patterns jsou děleny do 4 základních kategorií: Control-flow patterns (vzory pro tok řízení) představují vzory struktur pro řízení toku, Data patterns (datové vzory) představují vzory, ve kterých jsou data reprezentována a využívána v rámci workflow, Resource patterns (zdrojové vzory) představují vzory, ve kterých jsou zdroje dat reprezentovány a využívány v rámci workflow, Exception patterns (vzory přerušení) popisují zpracování přerušení procesu. Důležitou institucí pro standartizaci v oblasti workflow je také WfMC (Workflow Management Coalition) fungující od roku 1993, která standratizovala jazyk XPDL, což je XML obdoba jazyka WPDL (Workflow Process Definition Language), z něhož byl odvozen a v němž se názvy a význam XML elementů a atributů používaných pro popis workflow entit shodují s klíčovými slovy jazyka WPDL. 39
Producent Bonitasoft Název Bonita Open Solution Verze 5.0 Datum vydání 10/2009 WWW odkaz http://www.bonitasoft.com/ Bonita Open Solution 5.0 je open source projektem umožňujícím definovat procesy v rámci organizace. Bonita vyhovuje standardu XPDL Systémové řešení Bonita je založeno na Process Virtual Machine (PVM). Obrázek 14 - Architektura BPM Bonita Bonita umožňuje snadné modelování workflow s pomocí grafického nástroje Proed (Process Editor). Proed je nástroj v jazyce Java, jenž umožňuje vytvoření, editaci a vizualizaci workflow procesů s využitím BPMN notace. Po vytvoření v modelovacím nástroji je proces uložen pomocí standardu XPDL. Proces je v prostředí Bonita definován jako množina aktivit. Každá aktivita může být vykonána automaticky nebo manuálně. Ke každému procesu lze definovat účastníky procesu, workflow data (definice dat, jenž budou vstupovat do procesu), přechody v rámci procesu, akce, aktivity a způsob spuštění aktivit (manuální, 40
automatický). Pokud má proces definovány workflow data, umožňuje Bonita generovat automatické formuláře pro zadání těchto dat během vykonání procesu. Proces uložený pomocí standardu XPDL lze nahrát pomocí workflow konzole do virtuálního stroje PVM, kde lze vytvářet jednotlivé instance procesu. Workflow konzole je vytvořena jako Web 2.0 aplikace, která umožňuje uživatelům spravovat procesy a jejich instance. Bonita rozlišuje mezi uživatelem a účastníkem procesu: Uživatel používá workflow systém bez ohledu na to, zda je účastníkem nějakého procesu, Účastník procesu v rámci definované role se účastní procesu. Bonita je plně založena na platformě J2EE. Poskytuje několik API, pomocí nichž lze graficky vytvářet modely procesů (Project API) či spouštět, zastavovat a sledovat procesy nebo dynamicky měnit procesy (User API). Obrázek 15 - Bonita API 41
User Registration Session Bean - Umožňuje vytváření a správu uživatelů, Project Session Bean - Umožňuje vytvářet procesy, User Session Bean - Provádí vykonání aktivit, spravuje TODO list, Engine Bean- Implementuje stavový stroj a kontrolu vykonávání procesů, Message Driven Bean - Zasílá uživateli upozornění např. pomocí e-mailového serveru, Bonita Hook - Pomocí Bonita Hook lze přistupovat k různým systémům za pomoci např. webových služeb. Na příkladu workflow pro schválení požadavku lze ukázat využití Bonita systému v praxi. V rámci aktivity Approval osoba rozhoduje o přijmutí (Acceptance) či zamítnutí (Rejection) požadavku (Request). Obrázek 16 - Grafický návrh procesu Bonita Takto navržený model je posléze s využitím XPDL notace nahrán do virtuálního stroje PVM, kde je skrze webové rozhraní přístupný uživatelům. Následující obrázky ukazují některé prvky webového rozhraní, které umožňují interakci s běžícím procesem. 42
Obrázek 17 - Správa procesů Bonita Obrázek 18 - Seznam TODO aktivit Bonita 43