! " ! # $ %& $ ' ( )
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
Frekvence změn
jednorázové nebo kontinuální změny
periodicky prováděné jednorázové změny
nové nebo existující procesy 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ů
simultánní realizace, napříč několika procesy úzký, uvnitř funkcí
každý proces samostatně
simultánní realizace, napříč mnoha procesy
široký, mezifunkční
všechny procesy v rámci hodnotového řetězce
Horizont
minulost a současnost
budoucnost
Riziko
mírné
vysoké
minulost, současnost i budoucnost nízké
Primární umožňující nástroj
statistická regulace
informační technologie
procesní technologie
Nástroje
off-line
žádné
on-line
Zapojení odborníci
odvětvoví specialisté
všestranní pracovníci v oblasti businessu
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
Typický rozsah působnosti
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
Nástroje reálně využívány procesními analytiky
Modelování procesů
Business model společnosti
Proprietární modelovací jazyky
Standardizované modelovací jazyky
Průběžné zlepšování procesů
Dynamické zvyšování výkonnosti
Vysoké počáteční náklady
Řešení možné i na bázi open source nebo jako služba
Dílčí produkty pro jednotlivé fáze životního cyklu procesu
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
Pegasystems Pegasystems SmartBPM Suite
Název 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
& $ Producent
IBM
Název
IBM BPM Suite
Verze Datum vydání Licencování
komerční
WWW odkaz
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
Obrázek 4 - Varianty IBM BPM Suite
& ' $ Producent
TIBCO Software
Název
TIBCO iProcess Suite
Verze Datum vydání Licencování
Komerční / free
WWW odkaz
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
Intalio
Název
IntalioWorks BPM
Verze Datum vydání Licencování
Free / komerční
WWW odkaz
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.
01 %234 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
Sybase
Název
PowerDesigner
Verze
15.0
Datum vydání
8/2008
Licencování
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/
5 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
'0 ' 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 Název Verze Datum vydání WWW odkaz
Bonitasoft Bonita Open Solution 5.0 10/2009 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 ./0% 1 + %**2- 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
. Producent
BizAgi
Název
BizAgi
Verze
9.1.2
Datum vydání
6/2009
Licence
120 Euro
WWW odkaz
http://www.bizagi.com
BizAgi je komerčním BPM systémem, který nabízí organizacím návrh, modelování, integraci, automatizaci a monitorování podnikových procesů skrze grafické prostředí bez nutnosti programovaní.
BizAgi je tvořen sadou tří nástrojů, které spravují kompletní životní cyklus procesu:
BizAgi Process Modeler – umožňuje modelování a dokumentaci navržených procesů,
BizAgi Studio – provádí automatizaci procesního modelu,
BizAgi BPM Server – vykonává a kontroluje procesy.
Na obrázku je znázorněn životní cyklus podnikového procesu v rámci BizAgi BMP systému.
Obrázek 19- Životní cyklus workflow v rámci systému BizAgi
44
BizAgi Process Modeler Jedná se o grafický nástroj, který umožňuje snadno modelovat podnikové procesy v notaci BPMN. Kromě samotného vytvoření diagramu v BPMN umožňuje nástroj rovněž export a import modelu do nejrůznějších formátů. Pro dokumentaci procesů je podporován export do formátu MS Word, PDF a PNG. Pro automatizaci a vykonání procesu je podporován import do formátu XPDL.
Obrázek 20 - Model procesu BizAgi
# ' Prostředí, jež automatizuje návrh zhotovený v modelovacím nástroji, se nazývá BizAgi Studio. Automatizace představuje transformaci navrženého modelu v notaci BPMN do technologické aplikace. BizAgi nabízí řadu nástrojů, jež umožňují generovat technologickou aplikaci související s podnikovým procesem (vývojový diagram, business pravidla, datový model, uživatelské rozhraní) pomocí grafického rozhraní a bez nutnosti programování. Tento model je uložen v databázi a je interpretován v rámci BizAgi BPM Server. Výsledkem automatizace modelu je webová aplikace, která je generována jen z grafického modelu bez nutnosti programování. Výhodou tohoto řešení je, že každá
45
změna provedená v rámci modelu je ihned zohledněna ve webové aplikaci. Uživatel přistupuje k webové aplikaci, která mu umožňuje spravovat jednotlivé aktivity v rámci procesu.
Obrázek 21 - Automatizované generování modelů BizAgi
# $ ' Jedná se o engine, který provádí a kontroluje automatizovaný proces. Základní komponentou je webová aplikace, která umožňuje účastníkům procesu zobrazit aktivity podle různých kritérií. Rovněž účastníkům procesu umožňuje vidět informace o stavu jednotlivých procesů v reálném čase. BizAgi podporuje technologii .NET a J2EE.
'$. Producent Název Verze Datum vydání Licence WWW odkaz
COSA GmbH COSA BPM 5.7 10/2008 cena podle kalkulace obchodníka http://www.bps-solutions.de/ 46
COSA je nástroj stejnojmenné firmy pro správu podnikových procesů, který kromě uživatelsky založeného workflow (nutná interakce s uživatelem systému) podporuje rovněž plně automatizované procesy bez nutnosti uživatelské interakce. Nástroj plně pokrývá životní cyklus BPM, jak je znázorněno na obrázku níže.
Obrázek 22 - Životní cyklus workflow v rámci systému COSA
Process Designer - na základě BPMN notace je uživateli poskytnut grafický nástroj pro modelování procesů. Návrháři je umožněno generovat dokumentaci procesu ve formátech RTF, PDF a HTML. Modelované procesy lze uložit ve standardu XPDL,
Process Viewer – procesy jsou zobrazovány se stejným vzhledem, s jakým byly modelovány,
Simulator - poskytuje simulaci procesů v čase běhu a verifikaci navržených procesů,
47
COSA Server - výkonné jádro systému založené na relační databázi. Kontroluje tok instancí procesů v závislosti na procesním modelu. Tedy řídí vykonání jednotlivých pracovních úkolů, spouští nové instance procesu. COSA Server umožňuje několika různým firmám využívat jeden společný server, přičemž každá z firem má definovány svá vlastní data a procesy. Kontrolu správného toku instancí jednotlivých procesů zajišťuje COSA Server podle definice procesu získané z Process Designeru,
Context Handler – představuje klientskou aplikaci, jenž prezentuje uživateli úkoly související s vykonáním procesu. Poskytuje uživateli seznam všech pracovních úkolů, data související s jednotlivými procesy či připojené dokumenty. Mezi data související s procesy mohou patřit lhůty, termíny nebo poznámky,
Control Station – monitorovací nástroj, který např. dokáže odhalit chyby, jež nastanou v rámci vykonávaného procesu.
Obrázek 23 - Architektura BPMS COSA
48
) ' Balanced scorecard (BSC) představuje strategický systém řízení organizace, který zpracovává a převádí poslání a vizi organizace do specifických cílů, co uceleného a srozumitelného souboru měřítek a ukazatelů finanční a nefinanční výkonnosti, které poskytují rámec pro posuzování úspěšnosti strategie a systému řízení. Balanced scorecard je stavebním kamenem integrovaného manažerského systému, který určuje priority a kritické faktory úspěšnosti. Dokáže mimo jiné také sledovat pokrok při dosahování strategických cílů, umožňuje monitorovat a průběžně upravovat zavádění strategie. BSC tedy zachovává měřítka, jež se sledují u většiny podniků a jsou obrazem minulých finančních transakcí, ale také doplňuje tato finanční měřítka o nová měřítka, která umožní zvýšit výkonnost. Můžeme k nim zařadit například nové distribuční kanály, pracovní postupy, dovednosti zaměstnanců, loajalita zákazníků, podnikový IS apod. Je třeba si uvědomit, že většina podniků pracuje jak s finančními, tak i nefinančními ukazateli. Nefinanční ukazatelé jsou ale používány pouze pro místní pokrok, nikoli pro strategické řízení. Není to z toho důvodu, že by si podniky neuvědomovaly důležitost takového ukazatele, jako je spokojenost zákazníka, rychlejší distribuční cesty apod. Naskýtá se problém v propojení finančních ukazatelů s nefinančními a zároveň ohodnocení zlepšení nefinančního ukazatele v peněžním vyjádření. Tento problém pomáhá vyřešit právě BSC. Tato metoda díky svým vazbám mezi jednotlivými ukazateli dokáže určit, jaké dopady budou mít na určitý finanční ukazatel změny, které jsou vyvolány různými nefinančními ukazateli. BSC tedy zjišťuje vazby mezi finančními a nefinančními ukazateli na základě vztahu příčina – důsledek. Jak již bylo zmíněno, metoda BSC je úzce spjata s pojmem strategie. Tento pojem se dá vysvětlit jako cesta ke splnění strategického cíle, který vychází a je v souladu s vizí podniku, tedy s tím, co podnik hodlá vytvořit a objasňuje důvod existence podniku. Úkolem strategie je najít a vytvořit konkurenční výhodu pro podnik tak, aby uspěl v současném konkurenčním prostředí. Pokud by konkurence neexistovala, podnik by žádnou strategii nepotřeboval a jeho existence by se opírala o předem jistý trh.
49
+ , Velikým problémem je fakt, že ve spoustě firem sice strategie existuje, nicméně je uložena pouze v hlavách manažerů a k řadovým zaměstnancům se dostává jen stěží. Dalším problémem je skutečnost, že i když se zaměstnanci o strategických plánech dozví, nevědí, jak se chovat, aby pomohli strategii naplnit. Tyto a další problémy napomáhá BSC řešit tím, že podnikovou strategii konkretizuje na jednotlivé perspektivy, dílčí cíle zobrazí ve strategické mapě a sleduje naplňování strategie pomocí určených měřítek. Strategické cíle podniku vychází z vize a strategie a rozhodují o celkovém úspěchu podniku. Pokud chceme v podniku plánovat a sledovat dosažení strategických cílů, je nutné k těmto cílům přiřadit odpovídající finanční a nefinanční měřítka a jejich cílové a skutečné hodnoty. Následně jsou pak přiřazeny jednotlivým cílům strategické akce, které zabezpečují, aby bylo strategického cíle dosaženo.
& & Dle výše uvedených informací můžeme říci, že BSC je nástrojem, který dokáže měnit podnikové procesy. Jde o princip – postup, dle kterého je možné upravovat a měnit podnikové procesy k dosažení vytyčených strategických cílů.
. Prvním krokem je vyhotovení tzv. SWOT analýzy. Jde o matici, kde jsou uvedeny veškeré silné a slabé stránky podniku, jeho ohrožení a příležitosti. Tímto krokem získáme komplexní pohled na podnik. Druhým krokem je analýza výstupu, který poskytla analýza SWOT. Nejprve je nutné oddělit strategické cíle podniku od strategických akcí a uspořádat je do přehledné tabulky perspektiv. Dále je třeba zajistit, aby byly pro jednotlivé perspektivy vybrány takové strategické cíle, které jsou z hlediska naplnění strategie podniku klíčové. Ne vždy se však jedná o zmíněné strategické cíle, je proto nezbytné rozlišovat mezi následujícími výstupy:
Strategický cíl – jeho naplnění zvýší konkurenceschopnost podniku a vede k naplnění vize podniku, 50
Obecný cíl – jeho splnění nezvýší konkurenční schopnost podniku,
Operativní cíl – slouží k udržení operativních procesů, není tedy součástí strategických cílů,
Strategické akce – nejde o cíl, jde o možnou cestu ke splnění strategického cíle.
Třetím krokem je určení a přiřazení měřítek k jednotlivým strategickým cílům dle jednotlivých perspektiv. Čtvrtým krokem je vytvoření mapy, která je tvořena ze strategických cílů. Pátým krokem je definování strategických akcí a jejich přiřazení jednotlivým strategickým cílům.
Autoři konceptu Balanced scorecard D. Norton a R. Kaplan (Kaplan, 1992) určili pět manažerských procesů, které jsou klíčové pro úspěšnou implementaci strategie:
Mobilizace – změny je nutné prosazovat ve všech částech organizace, prostřednictvím vrcholového vedení,
Převedení strategie – strategii je potřeba vyjádřit ve formě strategické mapy,
Vyladění organizace – důležité je sladit činnost organizace jako celku, jejích podnikatelských jednotek, podpůrných jednotek a externích orgánů tak, aby byly v souladu a jejich spolupráce vedla ke společnému cíli,
Motivace zaměstnanců – k naplnění vytyčené strategie je nutné, aby byli zaměstnanci motivování v souladu s danou strategií,
Způsob celkové správy – strategii je nutné zapojit do takových procesů v podniku, jako jsou plánování, výkaznictví, posuzování výkonnosti managementu a tvorba rozpočtů.
51
. - "- 6 './0 #
Silné stránky 3 3 3 3 3
Slabé stránky
Věrná zákaznická základna Spolehliví zaměstnanci Minimální fixní náklady Široké portfolio služeb Kvalitní služby
Malá úroveň sdílení informací uvnitř podniku 3 Absence celopodnikového IS 3 Nedostatečné vytížení pracovníků společnosti 3 Nedostatečné monitorování nákladů Hrozby 3
Příležitosti 3 3
Rozšířit služby na další části trhu Zavést kompletní objednávání přes internet
3 3 3 3 3 3
Nedostatek kvalifikovaných zaměstnanců Silná konkurence v oboru služeb Konkurence s lepší marketingovou strategií Růst mezd Úraz majitele firmy (nepostradatelný) Finanční krize
Tabulka 3 - SWOT analýza
1+ Nyní je potřeba oddělit strategické cíle od strategických akcí a uspořádat je do přehledné tabulky dle perspektiv. Perspektiva Finanční
Zákaznická
Procesní
Možný strategický cíl 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
Zlepšení hospodaření s variabilními náklady Zvýšení zisků Racionalizace nákladů Růst ziskovosti zakázek Růst obratu Absolutní orientace na ziskové zákazníky Udržení klíčových zákazníků a získávání nových Zvýšení zákaznické spokojenosti Tvorba strategických aliancí Zvýšení kvality služeb Zjištění optimálního portfolia služeb Poskytování nových služeb Zvýšení flexibility poskytování služeb Racionalizace činností podniku 52
15. 16. 17. 18. 19.
Učení se a růst
20. 21. 22. 23. 24. 25. 26. 27. 28.
Zajištění vysoké kvality služeb Zaměření se na činnosti core-businessu Zvyšování efektivnosti v procesu poskytování služeb Nákup komplexního IS podniku Zvyšování kvalifikace a rozvoj stávajících pracovníků Zajištění dostatečného počtu kvalifikovaných pracovníků Motivace a odměňování pracovníků Stabilizace schopných pracovníků Nadefinování pravidel podnikové kultury Zlepšení interní komunikace Rozvoj informačních a komunikačních technologií Automatizace rutinních činností Zavedení nového IS Zajištění školení pro uživatele IS
Tabulka 4 – Analýza cílů dle perspektiv
V následujícím kroku je nutné výše uvedené cíle analyzovat a rozhodnout o tom, zdali se jedná o cíl strategický, obecný nebo operativní, či se jedná o strategickou akci. Perspektiva Finanční
Zákaznická
Procesní Učení se a růstu
Strategický cíl 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Růst hodnoty podniku Růst obratu Růst ziskovosti zakázek Racionalizace nákladů podniku Udržení klíčových zákazníků a získávání nových Tvorba strategických aliancí Zjištění optimálního portfolia služeb Zajištění vysoké kvality služeb Zaměření se na činnosti core-businessu Zvyšování kvalifikace a rozvoj stávajících pracovníků Zajištění dostatečného počtu kvalifikovaných pracovníků Motivace a odměňování pracovníků Zlepšení interní dokumentace
Tabulka 5 – Analýza strategických cílů
' Ve strategické mapě lze spatřit souvislosti mezi jednotlivými strategickými cíli. Z obrázku 24 je vidět, že hlavním strategickým cílem je růst hodnoty podniku.
53
Růst obratu
Růst ziskovosti zakázek
Udržení klíčových zákazníků a získávání nových
Tvorba strategických aliancí
Procesní
Zákaznická
Finanční
Růst hodnoty firmy
Racionalizace nákladů podniku
Řízení rizik podnikání
Zajištění optimálního portfolia služeb
Zaměření se na činnosti corebusinessu
Zajištění vysoké kvality služeb
Podpora inovací (nápadů) ze strany zaměnstanců
Učení se a růstu
Růst produktivity práce
Zlepšení interní komunikace
Zvyšování kvalifikace a rozvoj stávajících zaměstnanců
Motivace a odměňování zaměstnanců
Obrázek 24 - Strategická mapa
$ 2 3 Strategický cíl
Měřítko
Růst hodnoty firmy
EVA
Růst obratu
Meziroční růst obratu
Racionalizace nákladů
Výnosnost nákladů
Růst produktivity práce
Přidaná hodnota práce a kapitálu
Řízení rizik
Volatilita ROE
Růst ziskovosti zakázek
Marže Tabulka 6 – Měřítka finanční perspektivy
Strategický cíl
Měřítko 54
Zajištění dostatečného počtu kvalifikovaných zaměstnanců
Udržení klíčových zákazníků a získávání nových
Počet nových klíčových zákazníku Podíl dlouhodobých klíčových zákazníku ke všem klíčovým zákazníkům
Tvorba strategických aliancí
Počet vytvořených strategických aliancí za rok
Zjištění optimálního portfolia
Podíl tržeb za vlastní služby k celkovým tržbám
služeb Tabulka 7 – Měřítka zákaznické perspektivy
Strategický cíl Zajištění vysoké kvality
Měřítko Podíl dobře vykonaných služeb ke všem vykonaným službám
služeb Zaměření se na činnosti core-
Rentabilita tržeb
businessu Tabulka 8 – Měřítka procesní perspektivy
Strategický cíl Zajištění dostatečného počtu
Měřítko Čisté zvýšení poctu pracovníku za rok
kvalifikovaných pracovníků Podpora inovací (nápadů) ze
Počet přijatých zlepšovacích návrhu od zaměstnanců
strany zaměstnanců Doba potřebná k vyhledání informace Zlepšení interní komunikace Přístup k informacím Zvyšování kvalifikace a rozvoj stávajících pracovníků
Průměrný počet hodin strávených zaměstnancem na školeních za rok
55
Strategický cíl Motivace a odměňování
Měřítko Průměrná mzda
pracovníků Tabulka 9 – Měřítka učení se a růstu
' Strategický cíl Růst hodnoty firmy
Růst obratu
Strategická akce ---
Růstu obratu by měl podnik dosáhnout prostřednictvím zaměření se na klíčové zákazníky
Racionalizace nákladů
Tohoto cíle firma dosáhne zejména racionalizací nejdůležitějších činností v podniku. Jde o to, aby se provedlo zmapování nejvýznamnějších procesu a prozkoumalo se, zda jsou prováděny efektivně a zda nejsou zbytečně složité. Složité procesy je třeba zjednodušit
Růst produktivity práce
Řízení rizik
---
Prostřednictvím zajištění dostatečného počtu kvalifikovaných zaměstnanců a zajištění optimálního portfolia služeb
Růst ziskovosti zakázek
Tohoto cíle dosáhne firma absolutní orientací na ziskové zákazníky a zkrácení průběžné doby realizace zakázek
Tabulka 10 – Akce z finanční perspektivy
56
Strategický cíl Udržení klíčových zákazníků a
Strategická akce Lze dosáhnout zkvalitněním poskytovaných služeb
získávání nových Tvorba strategických aliancí
---
Zjištění optimálního portfolia
---
služeb Tabulka 11 – Akce ze zákaznické perspektivy
Strategický cíl
Strategická akce
Zajištění vysoké kvality služeb
Důsledné dodržování směrnic managementu
Zaměření se na činnosti core-
Tohoto cíle bude dosaženo prostřednictvím rozšíření činností
businessu
oddělení outsourcingu, které bude efektivně řídit outsourcované aktivity, Tabulka 12 – Akce z procesní perspektivy
Strategický cíl
Strategická akce
Zajištění dostatečného počtu
Firma by se měla věnovat s dostatečnou péčí náboru nových
kvalifikovaných pracovníků
zaměstnanců
Podpora inovací (nápadů) ze
Zavedení vhodného systému motivace a odměňování pracovníků
strany zaměstnanců Zlepšení interní komunikace
K výraznému zlepšení interní komunikace dospěje firma pořízením vhodného IS
Zvyšování kvalifikace a rozvoj
Toho cíle dosáhne firma vytvořením propracovaného systému
stávajících pracovníků
školení pracovníků a důslednou realizací těchto školení
Motivace a odměňování
Vytvoření vhodného systému motivace a odměňování
pracovníků
zaměstnanců Tabulka 13 – Akce z perspektivy učení se a růstu
57
7 " $' Po provedení analýzy technikou Balanced scorecard jsme dostali hlavní důležitý výstup, který je tvořen ze strategických cílů. Na ně jsou navázány jak metriky, tak i akce, jak stanovených strategických cílů dosáhnout. Jak je z předchozích tabulek vidět, hlavním strategickým cílem firmy je růst její hodnoty. Tento jev není nikterak překvapivý, protože firmy tento cíl velice často zahrnují do své strategie. Tento cíl je však podporován řadou jiných pod-cílů, které jsou pro náš účel zajímavější. Nyní budou vybrány pouze některé z nich, kterých se bude týkat Business Process Engeneering. Z finanční perspektivy to jsou:
Racionalizace nákladů,
Růst ziskovosti zakázek.
Ze zákaznické perspektivy to jsou:
Udržení klíčových zákazníků a získávání zákazníků nových.
Z procesní perspektivy to je:
Zaměření na činnosti core-businessu.
Z perspektivy učení se a růstu to jsou:
Zlepšení interní komunikace,
Zvyšování kvalifikace a rozvoj stávajících pracovníků.
4 , '* Balanced scorecard není typickým nástrojem pro modelování podnikových procesů. Na rozdíl od nástrojů CASE nebo CABE není metoda BSC schopna modelovat procesy dle konkrétních standardů. 58
Tuto techniku bychom umístili před samotné využití modelovacích nástrojů, tzn., že nejprve dochází ke změnám ve firmě z hlediska procesů, poté až nastupují modelovací nástroje typu CASE/CABE, aby tyto změny zachytili a zobrazili je v praktické podobě. hlavním účelem BSC je poskytnout odpověď na otázku, JAK modelovat a navrhnout procesy v podniku tak, aby jejich výstupy podporovaly a byly v souladu s podnikovou strategií. Pokud aplikujeme metodu BSC v podniku správně, poskytne nám vodítko v podobě strategických cílů, které mnohdy mají formu výstupů z procesů. Tento cíl (výstup) je dále třeba vzít a přiřadit ho do nejbližšího procesu, jehož výstupem by mohl být. Pokud takový proces neexistuje lze vytvořit proces nový, který bude požadovaný cíl (výstup) poskytovat.
59
7!6 V práci jsme zvolili několik kategorií nástrojů, které provází podnikový proces v jeho hlavních fázích. Zaměřili jsme se na platformu nástrojů BPMS. Z dalších nástrojů jsme uvedli nástroje CABE a nástroje pro modelování pracovních toků, jež se podnikových procesů přímo týkají. Z pohledu „nesoftwarových“ nástrojů jsme zmínili přímou souvislost podnikových procesů a metody Balanced scorecard. Tuto metodu jsme aplikovali na příkladě fiktivní společnosti, a tak umocnili její význam na změny v procesech. Do práce jsme rovněž zařadili standardy BPEL a BPMN, jelikož s modelovacími nástroji přímo souvisí. Veškeré dnešní nástroje obsahují podporu notace BPMN či alespoň převod do této notace, proto jsme považovali za důležité tuto notaci analyzovat a porovnat ji s dalšími grafickými reprezentacemi. V rámci zmíněných typů nástrojů jsme prokázali jejich přímou souvislost s modelováním podnikových procesů. Co však chápeme jaký možný budoucí směr, je hledání souvislostí s dalšími nástroji. Business Process Management se neustále vyvíjí a tomu se přizpůsobuje i softwarová podpora a metodiky. Proto věříme, že lze, či bude možné, nalézt další spojitosti mezi modelovacími nástroji a dalšími metodami či nástroji, které snad na první pohled nejsou tradiční součástí procesního modelování.
60
7 / (Aalst, 2002) AALST, Wil. Patterns and XPDL: A Critical Evaluation of the XML Process Definition Language, 2002 [online]. Dostupný z WWW: <www.workflowpatterns.com/documentation/documents/ce-xpdl.pdf>. (BPM portál, 2008) BPM Portál, 2008 [online]. Dostupný z WWW: <www.procesy.cz>. (Fingar, 2003) SMITH, Howard; FINGAR Peter. BPM: The Third Wave, 2003. 312s. ISBN 0929652339. (Fischer, 2007) FISCHER L. BPM & Workflow Handbook , Future Strategies Inc., 2007. 1. vydání, ISBN- 0977752712. (Kalenda, 2008) Přednáška BPM 2. generace: Videozáznam přednášky, 2008 [online]. Václav Kalenda, přednášející. Fakulta informatiky MU Brno. Dostupný z WWW:
. (Kalina, 2009) KALINA, Jaroslav. Srovnání standardů pro procesní modelování, 2009 [online]. Dostupný z WWW:
. (Kaplan, 1992) KAPLAN, Robert; NORTON, David. The balanced scorecard: measures that drive performance. 1992, Harvard Business Review. (Knap, 2007) KNAP, Pavel. Orchestrace a choreografie služeb, 2007 [online]. Dostupný z WWW: . (Maršík, 2008) MARŠÍK, Vladimír; PRAGER Martin. Orchestrace geowebových služeb, 2008 [online]. Dostupný z WWW: . (OASIS, 2007) OASIS Standard. Web Services Business Process Execution Language Version 2.0, 2007 [online]. Dostupný z WWW: . (OMG, 2009) Business Process Modeling Notation (BPMN), Version 1.2, OMG Object management group, 2009 [online]. Dostupný z WWW: . (Raden, 2007) RADEN, Neil; TAYLOR, James. Smart (Enough) Systems, 2007. 404s. ISBN 0-13234796-2. (Řepa, 2007) ŘEPA, Václav. Podnikové procesy – Procesní řízení a modelování. 2. vyd. Praha: Grada Publishing a.s., 2007. 288 s. ISBN 978-80-247-2252-8.
61
(Šafář, 2007) ŠAFÁŘ, Pavel. Využití BPEL v servisně-orientovaných architekturách, 2007 [online]. Dostupný z WWW: . (Šmída, 2007) ŠMÍDA, Filip. Zavádění a rozvoj procesního řízení ve firmě. 1. vyd. Praha: Grada Publishing a.s., 2007. 300 s. ISBN 80-247-1679-8. (WPI, 2009) Workflow Patterns Initiative, 2009 [online]. Dostupný z WWW:.
62