POUŽITÍ CASE/CABE NÁSTROJŮ PRO ŘÍZENÍ WORKFLOW VE FIRMĚ

Transkript

1 POUŽITÍ CASE/CABE NÁSTROJŮ PRO ŘÍZENÍ WORKFLOW VE FIRMĚ Léto 2008 Martin Janů Ondřej Křižan Jana Tezzelová Barbora Tomášková

2 Obsah 1 ÚVOD WORKFLOW CO JE WORKFLOW? TYPY WORKFLOW Produkční workflow Administrativní workflow Kolaborativní Ad hoc PŘÍNOSY WORKFLOW VÝVOJ WORKFLOW HISTORICKÝ VÝVOJ GENERACE WORKFLOW SOUČASNOST REŠERŠE ČLÁNEK ČLÁNEK ČLÁNEK KRITÉRIA HODNOCENÍ NÁSTROJŮ OBECNÉ INFORMACE PODPORA KONCEPCE TÝMOVÁ SPOLUPRÁCE DOKUMENTACE PŘIZPŮSOBENÍ MODELOVÁNÍ A ANALÝZA IDS SCHEER ARIS OBECNÉ INFORMACE PODPORA KONCEPCE TÝMOVÁ SPOLUPRÁCE DOKUMENTACE PŘIZPŮSOBENÍ MODELOVÁNÍ A ANALÝZA ORACLE BPEL PROCESS MANAGER OBECNÉ INFORMACE PODPORA KONCEPCE TÝMOVÁ SPOLUPRÁCE DOKUMENTACE...21

3 7.6 PŘIZPŮSOBENÍ MODELOVÁNÍ A ANALÝZA MICROSOFT BIZTALK SERVER OBECNÉ INFORMACE PODPORA KONCEPCE TÝMOVÁ SPOLUPRÁCE DOKUMENTACE PŘIZPŮSOBENÍ MODELOVÁNÍ A ANALÝZA IBM WEBSPHERE BUSINESS MODELER OBECNÉ INFORMACE PODPORA KONCEPCE TÝMOVÁ SPOLUPRÁCE MODELOVÁNÍ A ANALÝZA ZÁVĚR...40 POUŽITÁ LITERATURA...41 SLOVNÍČEK POUŽITÝCH POJMŮ A ZKRATEK...42 SEZNAM OBRÁZKŮ, GRAFŮ A TABULEK...44

4 1 Úvod V této práci se zaměříme na popis nástrojů pro podporu řízení workflow. Pokusíme se zmapovat jejich vývoj od minulosti přes současnost až do budoucnosti. Kromě toho se budeme snažit identifikovat trendy v této oblasti. V úvodní části seznámíme čtenáře s pojmem workflow, vysvětlíme k čemu slouží a jaké druhy workflow rozlišujeme. Na tuto část navazuje kapitola o historickém vývoji workflow, ve které se zmíníme také o předpokládaném budoucím vývoji v daném oboru. Čtvrtá část práce shrnuje nejzajímavější poznatky o workflow a nástrojích, které podporují jejich provoz a modelování, získané z tisku. Poté už následuje nejdůležitější část celé práce, kterou je popis vlastností čtyř CASE nástrojů, jež podporují modelování a řízení workflow v organizacích. Všechny nástroje jsou hodnoceny podle jednotného schématu, které je stručně nastíněno v páté kapitole, a které čtenářům usnadňuje porovnání jednotlivých nástrojů. 1

5 2 Workflow Na počátku celé práce je vhodné se alespoň stručně seznámit s obecnými pojmy, které s workflow souvisí. Po krátkém úvodu a definici workflow uvedeme typy workflow, se kterými se můžeme setkat a jejich charakteristiky. 2.1 Co je workflow? Workflow Definice: Workflow je automatizace části nebo celého podnikového procesu, během kterého jsou dokumenty, informace nebo úlohy předávány podle sady procedurálních pravidel ke zpracování od jednoho účastníka k druhému. Činnost Dalším důležitým pojmem je činnost, která tvoří jeden logický krok procesu. Můžeme se setkat se dvěma druhy činností - manuálními a automatickými. Definice: Činností se rozumí část procesu, která tvoří jeden logický krok v rámci tohoto procesu. Instance Můžeme vytvářet instance jak procesů tak činností. Instance jsou tvořeny a řízeny systémem workflow pro každou jednotlivou invokaci procesu a činnosti. Definice: Instance je reprezentace jednoho konkrétního zpracování procesu nebo činnosti procesu včetně použitých dat. Každá instance představuje samostatně vykonávané vlákno procesu nebo činnosti, které může být řízeno nezávisle a má svůj interní stav a zvenčí viditelnou identitu. Ta může být použita k manipulaci, například k získání podrobných údajů o dané instanci. V případě, že proces zahrnuje paralelní činnosti, může jeho instance obsahovat více souběžně vykonávaných vláken. Proces Jedná se o reprezentaci podnikového procesu ve formě, která podporuje automatickou manipulaci jako je modelování nebo zpracování systémem řízení workflow. Definice procesu se skládá ze sítě činností, ze kterých je proces složen, a vztahů mezi nimi. Dále obsahuje kritéria zahájení a ukončení procesu a údaje o jednotlivých činnostech, o jejich účastnících, přiřazených IT aplikacích, datech atd. Definice: Definice procesu je popis procesu ve formě, která umožňuje jeho automatickou manipulaci, jakou je například modelování nebo řízení vykonávání prostřednictvím systému workflow. Systém řízení workflow Systém řízení workflow se skládá z komponent, které uchovávají a interpretují definice procesů, řídí vykonávání těchto procesů, zajišťuje komunikaci s uživateli a aplikacemi. Součástí systému jsou většinou také administrátorské nástroje a nástroje pro definování procesů. Definice: Systémem řízení workflow se rozumí systém, který definuje, vytváří a řídí vykonávání workflow s využitím softwarových prostředků běžících na jednom nebo více workflow strojích. Daný software je schopen interpretovat definice jednotlivých 2

6 procesů, komunikovat s uživateli a kde je to zapotřebí, také spustit ICT nástroje a aplikace. Účastník workflow Pojem účastník workflow se obvykle používá v souvislosti s lidskými zdroji, ale konceptuálně může zahrnovat i zdroje mechanizované. Definice: Účastník workflow je zdroj, který vykonává práci reprezentovanou instancí činnosti. Tato práce se obvykle vyskytuje v podobě jedné nebo více pracovních položek, které jsou účastníkovi přiřazeny prostřednictvím pracovního seznamu. 2.2 Typy workflow Rozlišujeme čtyři základní typy workflow: a) produkční, b) administrativní, c) kolaborativní, d) ad hoc Produkční workflow Produkční workflow podporuje hlavní podnikové procesy. To jsou procesy, které vytvářejí přidanou hodnotu k finálnímu produktu a na kterých závisí spokojenost zákazníka (např. vyřízení žádosti o poskytnutí půjčky, likvidace pojistné události ap.) Procesy jsou dobře strukturovatelné, vyskytuje se mnoho případů použití procesů a práce s aktivitami procesu zabírá uživateli většinu pracovní doby. Důležitá je integrace s ostatními firemními aplikacemi. Čím kratší je doba mezi jednotlivými kroky procesu, tím je systém efektivnější. Pružnost změn definice procesu není důležitá, protože změny procesu nejsou každodenní záležitostí, ale souvisí většinou s rozsáhlejšími změnami v celé organizaci Administrativní workflow Administrativní Workflow je určeno k vyřizování každodenní agendy (např. vystavení objednávky, sledování výdajů, vyřízení reklamace, povolení pracovní cesty apod.) Tyto procesy jsou dobře strukturovatelné, často se opakují, bývají jednoduché (poskytují malý počet alternativních možností), obvykle jsou vázány na standardizované formuláře a dokumenty. Dobré řešení musí respektovat, že téměř každý zaměstnanec organizace je jejich potencionálním účastníkem, proto je důležitá dostupnost systému pro každého, a že účastnící administrativního workflow jsou příležitostní, tzn. workflow není jejich hlavní pracovní náplní Kolaborativní Kolaborativní workflow je zaměřeno na podporu skupinové spolupráce. Typická je existence dokumentu, jehož prostřednictvím si účastníci vyměňují své poznatky, a který se stane výsledkem jejich společné práce (např. zpracování kupní smlouvy, tvorba propagačního materiálu, návrh nové služby apod.) Očekáván je dokument, na němž spolupracuje několik uživatelů, a který prochází několika schvalovacími cykly. U kolaborativního workflow je klíčový proces a dokument, spolupracují s ním 3

7 většinou tvůrčí pracovníci, musí tedy podporovat kreativitu pracovníků a musí být pružné, neboť tvůrčí pracovníci často využívají nové, nepředdefinované postupy Ad hoc Ad hoc workflow je založeno na náhodnosti vzniku workflow procesu. Procesy jsou většinou jedinečné, je možné je definovat až v okamžiku jejich vzniku (např. odpověď na dotaz zákazníka, vypracování výroční zprávy...) Tyto procesy vyžadují od uživatelů vysokou míru samostatnosti. Proto je zde důležitá široká přístupnost workflow produktu a snadná definice workflow procesu. 2.3 Přínosy workflow Workflow systém přispívá zejména ke: 1) Změně podnikových procesů, čímž zlepšuje organizaci a kvalitu práce. 2) Zavedení standardních postupů a tím zvyšuje efektivitu práce. 3) Uchovávání pracovních postupů v systému, namísto v hlavách pracovníků, kteří mohou společnost opustit. 4) Urychlení vyřizování jednotlivých business případůí. 5) Usnadnění monitorování a ověření stavu konkrétního případu v každém okamžiku. 6) Autorizaci a uchovávání jednotlivých verzí. 4

8 3 Vývoj workflow 3.1 Historický vývoj Vznik workflow úzce souvisí s vývojem technologické architektury informačních systémů, které se také staly důvodem k jejich zavedení. První zmínka o aplikaci workflow v informačních systémech pochází již z konce osmdesátých let, kdy organizace z oblasti bankovnictví a pojišťovnictví v USA zaváděly technologii Imaging na zobrazování základních podnikových procesů. Hlavním důvodem bylo, že tyto organizace byly zavaleny velkým množstvím dokumentů v papírové podobě - žádostmi od zákazníků, fakturami a smlouvami, a od technologie grafického zobrazování procesů očekávali snížení úsilí vynaloženého na ověřování, distribuci a řízení těchto hmotných dokumentů. Cíl zavedení technologie Imaging spočíval v průběžném zlepšování základních podnikových procesů. Organizace FileNet, která představila workflow systém založený na skriptovacím jazyku, a Sigma Imaging System, která je autorem systému s uživatelským rozhraním, patří mezi průkopníky nabízející první workflow systémy. 1 Největší rozmach a rozvoj workflow systémů se objevuje v devadesátých letech, kdy došlo k vytlačení business logiky mimo podnikové aplikace. Prvotním cílem workflow nástrojů bylo automatizovat vykonávání procesů tím, že se úkoly (činnosti procesu) předávají dalším zaměstnancům podle předem stanovených pravidel bez jakéhokoliv zbytečného prodlení. S přechodem na procesní řízení se kromě samotné automatizace procesu začaly objevovat snahy o změny procesů (BPR). Současné workflow nástroje nabízejí funkcionalitu zajišťující zpětnou vazbu, umožňují sledování, vyhodnocování a simulaci průběhu procesů. Očekávané přínosy workflow nástrojů se od devadesátých let značně změnily. V devadesátých letech byly pracovní úkoly předávány mezi zaměstnanci. Hlavním přínosem bylo, že pokud je úkol doručen k pracovníkovi, předpokládá se, že na něm může začít pracovat, protože workflow systém by nedoručil úkol, který není kompletní a určený pro další zpracování. Doručování se tak automatizovalo. 2 Na počátku 21. století jde o celý proces, jenž se automatizuje. V jednotlivých aktivitách procesu se soubor dat a úkolů vytváří, předává, zpracovává a mění tak, aby se co nejlépe dosáhlo podnikových cílů. Většina workflow systémů dokáže zpracovat i velmi komplexní procesy. 2 Workflow běžně obsahuje počet logických kroků, z nich každý je určitou činností. Činnost může zahrnovat spolupůsobení s uživatelem nebo účastníkem workflow, nebo tato činnost může být zpracována pomocí strojových zdrojů. Doručování práce 1 [7] Morderchai Beizer, Interesting times for workflow technology, 2004, 2 [8] Rob Allen, Workflow: An Introduction,Open Image Systems Inc., United Kingdom, WfMC External Relations Committee,

9 uživatelů zvyšuje efektivnost. Automatizace samotné práce poskytuje obrovské zvýšení efektivnosti a dále poskytuje manažerům vytvořit virtuální organizaci Generace workflow Aplikace podporující workflow prošly během svého vývoje čtyřmi generacemi, což podrobnějí ukazuje následující tabulka. Čtvrtá generace byla stanovena jako budoucí a ukazuje se, že předpoklady byly správné. Generace Charakteristika workflow První Druhá Třetí Čtvrtá Součást aplikace: 1) Workflow bylo nedílnou součástí (např. správa dokumentů) 2) Pevná definice procesu 3) Uzavřené, schované, nemodelovatelné Samostatná aplikace 1) Workflow jako samostatná aplikace 2) Definici procesu lze upravovat skriptovacím jazykem Upravitelná služba 1) Služby workflow přístupné dalším aplikacím přes API 2) Otevřená architektura, založená na standardech 3) Možnosti úprav pres grafické rozhraní 4) Proprietální workflow rozhraní a formáty výměny zpráv Vnořená funkcionalita 1) Workflow služby plně integrovány s middleware službami ( , správce pracovní plochy, adresář) 2) Standardizovaná rozhraní a formáty výměny zpráv 3) Všudypřítomné, ale neviditelné Tab. 1 - Vývojové generace workflow 3 Důležitým milníkem ve vývoji byl přechod od implementace workflow v aplikacích založených na proprietárním (vlastním) komunikačním rozhraní k technologii middleware, která fyzicky přebírá úlohu zprostředkovatele komunikace. Workflow definované v rámci jedné aplikace, popřípadě ve více aplikacích komunikujících proprietárním rozhraním, se oddělilo na samostatný workflow systém (WMS), jehož aktivity procesu procházejí více aplikacemi. Zájem o integraci souvisí s technologickým rozvojem síťové infrastruktury a internetu. Podniky procházely nejprve vlnou vnitřní integrace procesů, a až později, s rozvojem internetu, rostl zájem o integraci procesů mezi podniky. Vyšší složitost podnikových procesů, zapojení více informačních systémů do procesu a zároveň potřeba rychlého přizpůsobení procesů změnám v podnikatelském prostředí, vytváří nové požadavky na workflow nástroje. Procesy je potřeba přehledně sledovat (což umí 3 [9] R. Kenneth, Experiences with Workflow Management: Issues for the next generation,

10 workflow nástroje od začátku), pravidelně vyhodnocovat (Business Activity Monitoring), optimalizovat a aplikovat změny, které se rychle projeví. Workflow by nemělo být napevno implementováno do aplikace, ale tvořit samostatnou vrstvu architektury, která běží nad více aplikacemi. Změna workflow by neměla vyvolávat zásahy do aplikací na úrovni změny zdroj. Tyto přínosy jsou dosažitelné na middlewarových technologiích založených na messagingu. 3.3 Současnost Současný stav v zásadě odpovídá čtvrté vývojové generaci podle Kennetha. Na základě analýzy vybraných nástrojů pro podporu workflow jsme odhalili některé další vývojové tendence. Cíl automatizace procesů předáváním úkolů podle předem stanovených pravidel se posunul na zájem o celkovou optimalizaci procesů. Workflow dříve kladlo důraz na automatizaci procesů tím, že se stanovila pravidla pro předávání úkolů v souladu s procesem. V současnosti roste zájem o sledování a měření průběhu vykonávání automatizovaného procesu přes různé dimenze (oblasti), a na různou úroveň podrobnosti (od dob trvání celého procesu až na doby jednotlivých činností). Dochází k velmi těsnému prolínání workflow a Business Intelligence. Optimalizaci procesů odpovídá i další nabízená funkcionalita. Nástroje podporují různé způsoby simulace procesů (tzv. what-if analýzy) a predikci budoucích hodnot. What-if analýza odpovídá na otázku, co se stane, když změníme některou činnost v procesu (např. změnou finančního limitu, od kterého se objednávka schvaluje složitějším postupem), nebo když změníme vstupy (např. vyřazení výrobku z prodeje). Pouhou změnou v modelu lze simulovat výsledky po opakovaném spouštění procesu. Efektivní řízení podniku se neobejde bez znalosti, které procesy slouží kterým podnikovým cílům. Nástroje více orientované na business problematiku (např. ARIS) umožňují sledovat i tyto vazby. 7

11 4 Rešerše 4.1 Článek 1 Nancy Feig (2007, July). BPM: Beyond Workflow Banks are using business process management to improve the customer experience. Bank Systems & Technology, 44(7), 32. Retrieved June 1, 2008, from ABI/INFORM Global database. (Document ID: ). Tento článek se zabývá změnou pohledu bankovních ústavů na roli BPM (Business Process Management) a workflow. Dříve byly metody BPM ponejvíce považovány a využívány jako nástroj zlepšení efektivity procesů. Novým trendem v bankovnictví je orientace na klienta - ať už vnějšího nebo vnitřního. A BPM je způsob, jak vyjít vstříc zákazníkovi: usnadnit a zpříjemnit mu praxi ve formě procesů, kterými musí projít. Tento cíl vede banky k automatizaci jejich procesů. Při výběru řešení by měl dostat přednost dodavatel se zkušenostmi a produktem orientovaným na finanční služby, aby nebylo nutné definovat všechny procesy od začátku. Oříškem pak může být implementace technologických aspektů BPM. Existují jednoduchá řešení pro definici a nasazení obchodních pravidel, optimalizaci a analýzu procesů atd., ovšem integrace jednotlivých částí řešení není jednoduchá. Také proto se očekává růst trhu v oblasti balíčků BPM aplikací a také větší uplatnění IT technologů v rozhodovacím procesu banky, když se řeší problémy. Takové změny v kultuře organizací se však prosazují v delším časovém horizontu: banka musí být schopna definovat a řídit svá obchodní pravidla, pochopit je a dále definovat procesy - to vše předat IT. Dalším významným trendem je podle autorky článku využití servisně orientované architektury - ta tvoří spolu s BPM dvě strany jedné mince. Při automatizaci procesů a workflow totiž hraje významnou roli jejich integrace. Tím pádem mohou banky nabízet nové produkty. 4.2 Článek 2 Symantec Corporation: Symantec Releases New Altiris Workflow Solution; Symantec acquires IT process management technology to reduce IT costs through orchestrated task automation. (13 March). M2 Presswire. Retrieved June 1, 2008, from ProQuest Computing database. (Document ID: ). Tato tisková zpráva hovoří o novém produktu společnosti Symantec pro firmy v oboru IT a ilustruje trendy v oblasti BPM a automatizace workflow. Organizace mohou využít nové řešení (Altiris Workflow Solution) pro vytvoření vlastních workflow procesů anebo využít předpřipravených procesů od společnosti Symantec - ty by měly být rovnou použitelné pro obvyklé služby IT jako je například zaopatření nových zaměstnanců, požadavky na hardware a software, nastavování hesel a další. IT organizace mají často správné lidi, nástroje a nejlepší postupy, ale postrádají schopnost je spojit tak, aby přinášely obchodní hodnotu. Nové řešení workflow může zvýšit důvěru v činnosti IT modernizací procesů a zaměřením na kritické potřeby. Toto řešení dále integruje prvky bezpečnosti a řízení na základě nejlepších postupů podle ITIL, využívá informace poskytované datovými úložišti a databázemi konfiguračního managementu (CMDB) a dále pomáhá zákazníkům implementovat IT procesy, automatizovat rutinní úlohy, snižovat náklady 8

12 na řízení IT, vylepšit úroveň služeb a spokojenost koncových zákazníků a nakonec také usnadnit vyhovění regulačním předpisům. Automatizace (nejen) IT procesů skrývá potenciál v segmentu středních i malých firem, které chtějí snížit náklady na provoz IT, stejně jako u velkých firem, cílících na plné zdokonalení procesů podle ITIL nebo jiných metodologií. Automatizace je jedním z hlavních trendů budoucnosti. 4.3 Článek 3 Major players propose human workflow extensions to business processes spec. (2007, August). Manufacturing Business Technology, 25(8), 38. Retrieved June 1, 2008, from ABI/INFORM Global database. (Document ID: ). Největší firmy na trhu podnikových systémů, jmenovitě IBM, BEA, Oracle, SAP a Adobe předkládají nový návrh na rozšíření BPEL, jazyka pro orchestraci obchodních procesů implementovaných jako webové služby, aby obsahoval také rozhraní pro lidské vstupy jako jeden z kroků workflow (procesu). Tato specifikace se nazývá BPEL4People. Orchestrace služeb je způsob dynamického zřetězení několika služeb dohromady jako část většího procesu. Do teď BPEL podporoval pouze vykonávání automatizovaných kroků. Ovšem při vytváření rozsáhlých procesů, či skládání menších procesů do vyšších celků, se často vyskytuje potřeba zapojit do procesu také lidský faktor - například v případech rozhodování, která nelze z různých důvodů automatizovat. Cílem zmíněných firem je standardizace takového rozhraní. Přesto mnoho hráčů v oblasti BPM nejeví o specifikaci zájem - vytýkají jí například, že neadresuje organizační hierarchii a řešení nechává na implementátorovi. BPEL také neřeší rozdělení rolí (povinností), které jsou vyžadovány v každém procesu, který má odpovídat regulačním, legislativním předpisům (například v USA). Specifikace byla předložena k posouzení OASIS na podzim

13 5 Kritéria hodnocení nástrojů Rozhodli jsme se, že při popisu vlastností jednotlivých nástrojů budeme dodržovat jednotnou strukturu. To nám následně výrazně zjednoduší práci při srovnávání produktů. Kritéria, jež jsme stanovili pro hodnocení, a která spolu souvisejí, jsme pro lepší přehlednost shrnuli do větších celků. To by mělo mimo jiné usnadnit orientaci čtenářům. 5.1 Obecné informace V úvodu popisu každého jednotlivého nástroje se zaměříme na shrnutí jeho nejobecnějších vlastností, mezi které jsme zařadili název produktu, jeho cenu a licenční politiku (nabízené edice, dostupnost trial verze ap.) a dále hardwarové a softwarové požadavky pro instalaci produktu. 1) Název 2) Cena 3) Hardwarové požadavky 4) Softwarové požadavky 5.2 Podpora Další kritéria se zaměřují na sledování nástrojů z hlediska podpory výrobcem a usnadnění a zefektivnění jejich využívání v organizacích. Z tohoto hlediska je velmi významná lokalizace produktu pro konkrétní prostředí, resp. zemi, v níž bude distribuován a nasazován. V tomto ohledu nejde jen o lokalizaci jazykovou, ale hlavně také o zavedení odpovídajících měrných jednotek (např. peněžních Kč, $,, ) a dalších podobných charakteristik. Následující zkoumanou vlastností je existence a možnosti užití klávesových zkratek zda je možné je používat, jsou předdefinované, lze je individuálně měnit a přizpůsobovat, definovat nové apod. Dalším krokem ke stanovení úrovně podpory je zhodnocení kvality dokumentace, především její podrobnosti a použitelnosti (jednoduchost, přehlednost, podrobnost...) Z hlediska podpory ze strany výrobce hodnotíme zařazení nejrůznější školení, e-learningových kurzů, helpdesk, diskusní skupiny, ové konference ap. Posledním popisovaným kritériem v tomto oddíle je popis nápovědy v aplikaci. 1) Lokalizace 2) Klávesové zkratky 3) Dokumentace a školení 4) Nápověda 5.3 Koncepce V této části se budeme zabývat především popisem struktury a aplikační architektury nástrojů. S tím velmi úzce souvisí další popisovaná oblast, a to kvalita, jednoduchost, přehlednost a přívětivost uživatelského rozhraní. Jsme si vědomi, že hodnocení uživatelského rozhranní je subjektivní záležitostí, nicméně pokusíme se být v tomto 10

14 směru co nejvíce objektivní a ukázat jakýsi nadhled. S uživatelským rozhraním souvisí také problematika použitelnosti celého systému, do níž můžeme zahrnout například snadnou a rychlou dostupnost důležitých a často používaných funkcí, složitost nastavení a ovládání atd. Poslední kategorií, kterou jsme zařadili do oblasti koncepce nástrojů je seznam standardů, které jednotlivé nástroje podporují. 1) Architektura 2) Uživatelské rozhraní 3) Použitelnost 4) Standardy 5.4 Týmová spolupráce Hlavní charakteristiky, které zkoumáme v rámci podpory týmové spolupráce jsou přidělování práv zda nástroj umožňuje přidělovat a měnit přístupová práva jednotlivým uživatelům, případně definovat role a ošetření (ne)možnosti souběžné práce více osob na jednom modelu. 1) Přidělování práv 2) Souběžná práce 5.5 Dokumentace Mezi kritéria pro hodnocení dokumentace nástrojů jsme zahrnuli náročnost, resp. jednoduchost a intuitivnost, jejího ovládání, složitost vyhledávání informací a vytváření reportů. Snažili jsme se mimo jiné zjistit, jaké druhy dokumentace jednotlivé nástroje nabízejí a podporují - XML, DOC, wiki, diskusní fóra, knowledge base... S dokumentací částečně souvisí i možnosti používání předdefinovaných, či definování vlastních nových, šablon, které lze využít jako prototyp pro určitý specifický probíhající business proces v organizaci, např. vyřízení objednávky. 1) Náročnost ovládání 2) Typy dokumentace 3) Šablony 5.6 Přizpůsobení Pod pojmem přizpůsobení CASE nástroje si můžete představit shrnutí možností nástrojů pro adaptaci na prostředí konkrétní organizace. To může být zajištěno například možností vytvářet a doplňovat nové objekty (přiřadit tvar, barvu, nastavit default hodnoty aj.), které by přesně odrážely potřeby podniku a metodiky v něm používané. S tím souvisí zároveň i rozsah možností modifikace standardních objektů, které nástroj obsahuje. 1) Doplnění objektů 2) Modifikace dostupných objektů 11

15 5.7 Modelování a analýza V části o modelování a analýze stručně shrneme typy modelů, které nástroj uživatelům nabízí a metodiky, které podporuje. Naší snahou bylo také ověřit, zda nástroj umožňuje simulovat průběh procesů, a pokud ano, pak jakým způsobem. 1) Procesní modely 2) Simulace 3) Metodiky BPM 12

16 6 IDS Scheer ARIS 6.1 Obecné informace Název: ARIS Software Cena: od Kč Hardwarové požadavky: Pentium II, 450 MHz, 512 MB RAM, 2GB volného místa na disku Softwarové požadavky: Windows XP, 2000, Podpora Existuje on-line zákaznické centrum, které slouží k podpoře při zavádění a využívání jejich IS. Větším firmám jsou poskytovány i doplňky softwaru na zakázku. Jazyková lokalizace: Čeština pro všechny části. Klávesové zkratky: Ano - klávesové zkratky jsou většinou standardní. Školení: Dvojího typu: 1) Produktová školení vás naučí pracovat se všemi produkty z řady ARIS ARIS Easy Design - ATS1 ARIS Toolset - ATS2 ARIS Easy Design a ARIS Toolset - ATS ARIS Business Designer - ABD ARIS Business Architect - ABA ARIS sestavy základ (ARIS Toolset) - RSC-1 ARIS sestavy pro pokročilé (ARIS Toolset) - RSC-2 ARIS sestavy základ (ARIS Business Architect) - RSC-3 ARIS sestavy pro pokročilé (ARIS Business Architect) - RSC-4 2) Metodická zaměření na získání dovedností týkajících se procesního řízení Efektivní zavádění a využití procesního řízení - EPR Trénink procesních specialistů - TPS Nápověda: Kontextová, možnost vyhledávání, seznam pojmů. 6.3 Koncepce Architektura: Na následujících obrázcích je názorně vidět rozsáhlost platformy ARIS a zároveň také části modulů, z kterých je složena. Nejzajímavější pro tuto práci je Design platform, která je zaměřena především na návrh, analýzu a optimalizace podnikových procesů pomocí webového rozhraní, dynamickou publikaci procesních portálů, celopodnikové řízení IT architektury a podporuje i osvědčenou metodiku pro různé oblasti použití. Pod všemi těmito moduly je samozřejmě jednotná repository. 13

17 Obr. 1 - ARIS Platformy ARIS BSC Scout ARIS BSC Solution ARIS Business Optimizer ARIS Smart Input for Business Optimizer Obr. 2 - ARIS Strategy Platform ARIS for SAP NetWeaver ARIS Business Architect for SAPNetWeaver ARIS Business Designer for SAP NetWeaver ARIS Easy Design for SAP NetWeaver ARIS Toolset for SAP NetWeaver ARIS P2A ARIS Redocumentation Scout ARIS Scout Factory ARIS Software Engineering Scout ARIS UML Designer Obr. 3 - ARIS Implementation Platform 14

18 ARIS Business Architect ARIS Business Designer ARIS Easy Design ARIS Toolset ARIS Business Publisher ARIS Defense Solution ARIS Healthcare Solution ARIS Quality Management Scout ARIS Simulation ARIS Web Publisher Obr. 4 - ARIS Design Platform ARIS Audit Manager ARIS Business Analyzer ARIS Online Monitoring ARIS OrgAnalyzer ARIS Performance Cockpit ARIS Process Performance Manager ARIS Process Mining ARIS Process Risk Scout Obr. 5 - ARIS Controlling Platform Uživatelské rozhraní a použitelnost: Uživatelské rozhraní je tvořeno hlavní plochou, v níž se zobrazuji jednotlivé modely, modeluje se zde, případně při vyhledávání se zobrazují atributy. V levé části je umístěn panel, který uživateli dovoluje přepínat mezi průzkumníkem, designérem či třeba administrátorem. Modely se otevírají formou záložek. Je vidět posun od 6. verze ARIS, ve kterém se modely klasicky otevíraly nad sebou, díky čemu nebylo vidět kolik, a jaké modely jsou aktuálně otevřené. V horní části je klasicky umístěn panel s ovládacími funkcemi. 15

19 Hierarchizace je v modelech dělaná formou umístěného malého obrázku rozvětvení v pravém dolním roku objektu. Při poklepání se nám zobrazí model, do kterého je daný objekt hierarchizován. Standardní funkce jako zvětšování, zmenšování či přichycení k mřížce jsou samozřejmostí. Také tvorba vlastních panelů nástrojů není výjimkou. ARIS podporuje více než 150 notací pro modelování procesů, přičemž lze každý objekt customizovat pro podnikové podmínky. Obr. 6 - ARIS - Uživatelské rozhraní I Obr. 7 - ARIS - Uživatelské rozhraní II 16

20 6.4 Týmová spolupráce Přidělování práv: Přidělovaná práva mohou být trojího typu právo pro čtení, editaci a mazání. Jednotlivá práva mohou být vzájemně libovolně kombinována. Souběžná práce: Omezení souběžné práce je na jednom modelu, přičemž když někdo jiný má otevřený daný model tak druhému uživateli se zobrazí hlášení, kde je uvedeno kdo tento model právě upravuje. 6.5 Dokumentace Vytváření dokumentace je velice snadné. Pouze proklikáním pár oken je možné vytvořit kvalitní dokumentaci i v mnoha různých sestavách. Samozřejmostí jsou také předpřipravené šablony, které pomohou uživatelům především v začátcích jejich práce s nástrojem. V pokročilejších fázích si sami uživatelé mohou nadefinovat, jak a co se má vygenerovat. Dokumenty lze generovat do formátů XML, MS Office, MS excel, PDF a třeba i HTTP. 6.6 Přizpůsobení Velikost tohoto nástroje zaručuje i vysokou míru modularity. Jak již bylo zmíněno výše, objekty se dají libovolně upravovat a měnit. Dá se například nastavit dědění vlastností objektů nebo celých modelů. Lze nastavit libovolnou rozteč mřížky či zda název objektu v modelu má být striktně uveden v objektu nebo ho může přesahovat aj. 6.7 Modelování a analýza Při modelování v tomto nástroji je využívána především metodika ARIS. Nejvíce jsou využívány organigramy, funkční stromy, EPC a business diagramy. Každý z těchto diagramů zastává důležitou funkci v metodice ARIS. Lze použít filtry, díky nimž omezíme množství objektů, na ty, které nejčastěji využíváme a není tedy nutné se vždy přebírat obrovským množstvím neznámých objektů. Procesní modely: V rámci ARISu lze navrhovat procesy především graficky, k čemuž je tento nástroj primárně předurčen. Důležitá je i možnost propojení se softwarem firmy SAP a následná synchronizaci mezi nimi. Tato možnost velice usnadňuje práci. Bohužel to platí pouze pro software firmy SAP. Ovšem vzhledem k rozsáhlosti tohoto nástroje není divu, že se spojil právě s takovým gigantem. Simulace a měření procesů: Pro simulaci průběhu procesů je z nabídky ARIS určen modul Simulator. Umožňuje analyzovat a zlepšovat stávající i nové procesy. Na základě zdokumentovaných podnikových procesů doplněných o dynamické parametry poskytuje Simulator důležité informace o úzkých místech procesů z hlediska času, nákladů a kapacit. Výsledek je zobrazován formou statistik i diagramů. Přínosy, které organizace díky produktu získávají, jsou nejčastěji podpora strategického rozhodování, snížení doby průběhu procesů a souběžné zlepšení využití zdrojů a detailní srovnání různých alternativ procesů s možností následné identifikace nejlepšího postupu. Modelovací standardy: Bussines process modely poskytují abstraktní pohled na komplexní strukturu. Soustředí se na specifické části struktury a zde zdůrazňují klíčové vztahy a ignorují méně důležité aspekty. Modely se používají k dokumentaci, analýze a ke konfrontaci s realitou. Základním požadavkem je, aby různí 17

21 pozorovatelé vždy interpretovali obsah stejně, i přes různé stupně pohledu. Z tohoto důvodu definují modelovací standardy jednotlivé modelové elementy a jejich význam. EPC (Řetězec procesů řízený událostmi) Typicky je využíván na nižších úrovních hierarchie procesů. Firmy pomocí EPC znázorňují své pracovní postupy. EPC popisují IT systémy, organizační strukturu, jaká jsou tam data a jaké jsou vztahy mezi těmito objekty. BPMN (Business Process Modeling Notation) Tento standard umožňuje vytvořit vazby mezi jednotlivými typy procesů, jako jsou Privátní podnikový proces, Abstraktní proces, Kolaborační proces UML (Unified Modeling Language) V UML jsou definována schémata i grafické symboly a navíc formát výměny dat XMI. Pomocí formátu XMI si mohou jednotlivé modelovací nástroje a vývojová prostředí vyměňovat informace. Podporovaná verze UML je 1.4. Vzhledem k tomu, že modelování v UML je plně integrováno s nástroji ARIS UML Designer a ARIS SOA Architect, dají se prvky modelu UML používat i v podnikových modelech. BPEL (Business Process Execution Language) Standard se používá k popisu automatizovaných procesů. Grafické modely je možno exportovat do oficiálního formátu BPEL XML. ARIS nabízí možnost transformace typu EPC-to-BPEL, díky níž se modely podnikových procesů automaticky transformují do proveditelných procesů. WSDL (Web Services Description Language) Jazyk WSDL se používá k definování klíčových prvků webové služby, např. názvu, adresy a rozhraní. Standard WSDL definuje formát XML, ale nedefinuje žádný grafický standard pro modelování a také popisuje technické detaily ne však funkcionalitu webových služeb. 18

22 7 Oracle BPEL Process Manager 7.1 Obecné informace Název: Oracle BPEL Process Manager Cena: $ za CPU (zahrnuje aplikační server) $ - jako nadstavba Trial verze zdarma Hardwarové požadavky: Paměť: Minimálně 512 MB RAM(doporučeno 1 GB) Volné místo na disku: Oracle BPEL Process Manager for Developers: 600 MB Oracle BPEL Process Manager for OracleAS Middle Tier: 200 MB Swap space 1535 MB Podporované databáze: Oracle Database Lite (pouze pro windows) Oracle Database 10g - doporučeno Oracle9i Database nebo starší Softwarové požadavky: Windows, Linux, Solaris 7.2 Podpora Lokalizace: Grafický nástroj na modelování procesů BPEL Designer nepodporuje češtinu. Klávesové zkratky: Nástroj používá standardní klávesové zkratky pro běžně používané činnosti, v některých případech podporuje i kombinaci tří nebo čtyř kláves. Školení: K produktům od Oracle existují názorné výukové tutoriály. Další možností je navštívit školení na Oracle univerzity a popřípadě získat certifikát. Nápověda: Existuje více druhů nápovědy - kontextová (podle témat), možnost vyhledávání, seznam pojmů, oblíbené (nejprve musí uživatel definovat obsah oblíbené složky.) 7.3 Koncepce Architektura: BPEL Designer nabízí grafické rozhraní pro tvorbu BPEL procesů. Používá BPEL jako nativní formát, proto jsou vytvořené modely přenositelné do jiných nástrojů. 19

23 BPEL engine představuje robustní implementaci BPEL serveru. Představuje výkonné jádro, na kterém se spouští procesy namodelované v jazyce BPEL. Nabízí funkci dehydratace, při které je stav dlouho trvajících asynchronních procesů automaticky uložen do databáze, zatímco čekají na výsledek volané asynchronní činnosti. BPEL Server podporuje spolupráci s některými J2EE aplikačními servery (BEA WebLogic, Oracle AS, JBoss, IBM WebSphere). Zabudované integrační služby poskytují vývojářům napojení BPEL procesů na ostatní systémy a transformace BPEL procesů. Lze vytvářet XSLT a XQuery transformace nebo napojení na informační systémy přes JCA adaptéry a nativní protokoly. Integrační služby umožňují propojení manuálně vykonávaných úkolů do BPEL procesu, čímž vytvářejí workflow. WSDL binding framework poskytuje napojení na ostatní aplikace i přes jiné protokoly a jiné formáty zpráv než SOAP. Tím lze skombinovat volnou architekturu orientovanou na služby s nativním propojením aplikací, které zpravidla nabízí vyšší výkon. BPEL Console nabízí rozhraní pro řízení, správu a ladění procesů nasazených na BPEL serveru. Jedná se o reportovaní nástroj, který zpřístupňuje historická dat o dobách průběhu probíhajících procesů. Obr. 8 - Architektura Oracle BPEL Process Manager 4 Uživatelské rozhraní a použitelnost: Uživatelské rozhraní tvoří hlavní plocha pro modelování procesů a několik pomocných panelů. Je založeno na přesouvání objektů ze záložky s možností editace zdrojového kódu. Zajímavou funkcionalitou je záložka, která zobrazuje historie změn. Ke každé historii změn se zobrazí dva sloupce se zdrojovými kódy v XML, ve kterých jsou změny zvýrazněné. XML kód lze jednoduše opravit vyškrtnutím provedených změn. Aktivity v procesech lze zobrazovat na různé úrovni detailu a rozklikávat přes úseky až na jednotlivé činnosti. Rozsáhlý model lze zobrazit na celou obrazovku, 4 [5] Oracle BPEL Process Manager x Quick start tutorial 20

24 samozřejmostí je možnost zvětšování a zmenšování. Model má jediné omezení, že činnosti jsou umístěny automaticky pod sebou ve sloupci, čímž model roste do výšky při stabilní šířce. Obr. 9 - Oracle BPEL Process Manager - Uživatelské rozhraní Standardy: BPEL, XML, XQuery, XPath, WS, SOAP, WSDL, JCA, JMS, SMTP, HTTP Exporty: Model v notaci BPEL lze exportovat do XML a je tak přenositelný do jiných nástrojů. Osobně oceňuji možnost přímého vytvoření obrázku v JPEG formátu. 7.4 Týmová spolupráce Přidělování práv: Je omezeno na přidělování práv v rámci CVS vytvořením uživatelského jména a hesla. Souběžná práce: Vytvořené soubory, které popisují namodelovaný proces, se ukládají přímo na disk. Pro spolupráci více uživatelů se nabízí využití CVS (systému na ukládání souborů a správu verzí, do kterého přistupuje více uživatelů.) Oracle JDeveloper přímo podporuje použití CVS. V nabídce je složka s příkazy používanými při práci s CVS. Historická data o průběhu procesů se ukládají do společné databáze a jsou přístupné přes BPEL konzoli. 7.5 Dokumentace Dokumentace BPEL Process Manageru je psána stejným stylem jako u ostatních Oracle produktů. Náročnost na ovládání: Dokumentace Oracle nástrojů je rozdělená podle oblastí (Business Inteligence, E-Business, aplikační server...), každá oblast má většinou více komponent. Proto vyhledání příslušné dokumentace není problém, popřípadě lze 21

25 použít fulltextové vyhledávání. Po obsahové stránce se klade důraz na úplnost, k lepší přehlednosti dokumentace pomáhá členitost na kapitoly a podkapitoly. Speciální featurou je vytváření logů během instalace a konfigurace komponent, do kterých se ukládají zadané konfigurační údaje (nezahrnují hesla, ale ostatní parametry ano). Po dokončení instalace se v prohlížeči spustí dokumentace, kde produkt spustit a jak ho nakonfigurovat, což urychlí práci při hledání v manuálech. Typy dokumentace: Dokumentace bývá rozdělena podle způsobu využití nástroje instalační, uživatelská, administrátorská, vývojářská. Pro popis komponenty existuje více zdrojů podle různé úrovně detailu. K dispozici je stručný popis komponenty a/nebo podrobný popis API komponenty. Kromě klasické dokumentace v HTML nebo v PDF souboru existují další zdroje informací o produktech. Na Oracle Technology Network (OTN) se objevují články ohledně využití nových featur produktů. Seznam článků na Knowledge Base popisuje řešení některých problémů. 7.6 Přizpůsobení Modelování procesů je striktně založeno na standardu BPEL, proto není možné vytvářet nové typy objektů nebo měnit zásadním způsobem stávající objekty. Přizpůsobit lze pouze grafické atributy barvu a velikost objektů. Volnost v definování BPEL procesu je zajištěna tím, že lze zavolat libovolnou webovou službu, čímž se v maximální míře využívá znuvupoužitelnosti kódu. Proces nezahrnuje pouze systémové úlohy, ale může obsahovat i úkol, pro který je potřeba lidský zásah. 7.7 Modelování a analýza Modelování procesů v BPEL designeru je striktně založeno na BPEL notaci, která sama o sobě zahrnuje pouze systémové úlohy a pro realizaci workflow nestačí. Cílem standardu BPEL je propojit existující webové služby podle podnikového procesu, který se tím také stává webovou službou lze ji vyhledat, spustit s příslušnými parametry a obdržet výsledek. Hlavní výhodou propojení aplikací na bázi SOA (Service Oriented Architecture), konkrétně webových služeb, je vytvoření interface pro komunikaci mezi aplikacemi, tj. BPEL procesy, přes které se volají webové služby na základě jejich rozhraní, aniž by uživatelé museli znát implementační detaily. Architektura je značně flexibilní vůči změnám v podnikových procesech. Podrobněji pojednává o BPEL jedna z předchozích prací. 5 Standard BPEL je koncipován pouze pro systémové úlohy a sám o sobě neumožňuje zahrnout do procesu lidskou činnost. Tento nedostatek odstraňují některé firmy. Active Endpoints, Adobe, BEA, IBM, Oracle a SAP rozšiřují standard WS-BPEL na BPEL4PEOPLE. Oracle rozšiřuje aplikaci standardu BPEL pomocí Workflow services. Workflow services umožňují připojit úkoly, pro které je potřeba lidského zásahu, k BPEL procesu tím, že se do procesu přidají další druhy aktivit. Workflow services je 5 [6] Použití CASE/CABE nástrojů pro řízení workflow ve firmě 22

26 napojena na BPEL proces přes WSDL z pohledu BPEL procesu je workflow service pouze jedna z mnoha volaných služeb, avšak liší se tím, že pro její vykonání je potřeba lidského zásahu. Typickým příkladem je situace, kdy v procesu schvalování objednávky za vysokou částku je potřeba souhlas osoby. Do BPEL procesu se mohou přidat následující činnosti - úkol, pro který je potřeba lidského zásahu, poslat , poslat hlasový záznam nebo poslat sms. Obr. 10 Oracle BPEL Process Manager - architektura workflow services 6 WorkFlow services umožnují: 1) Přidělení úkolu a směrování zahrnuje vytvoření úkolu v určitém bodě business procesu a přidělení uživateli nebo uživatelské roli. Přidělení úkolu a směrování zahrnuje: Možnost vypršení časové lhůty úkolu a automatické opakování úkolu. Úkol lze delegovat na někoho jiného. Ukládají se historické informace o průběhu úkolu, které slouží pro kontrolu průběhu dílčích činností úkolu. 2) Různé workflow šablony zahrnuje standardní šablony jako jednoduché schválení, schválení, pro které je potřeba postupného souhlasu více osob, současné schvalování více osobami, apod. Existují šablony pro přeposílání úkolu managerům nebo předání podřízeným zaměstnancům. Základní šablony lze kombinovat do složitějších. 3) Služba ověření identity- může být napojena na systém, který získává všechny informace o uživateli přes Java AuthoriZatioN (JAZN) a LDAP. Služba poskytuje řízení přístupu jednotlivých rolí do systému. Přiděluje seznam úkolů k uživatelům, rolím nebo skupinám. Spravuje informace o uživateli jméno, adresa, telefon, . Vytváří organizační strukturu. 4) Notification service oznamuje uživateli přidělení nového úkolu nebo změnu již přiděleného přes různé kanály , hlasová služba, fax, pager nebo SMS. 6 [4]Workflow services 23

27 5) Aplikace se seznamem přidělených úkolů umožňuje uživateli zobrazit seznam úkolů, a akce, které s nimi může provádět např. komu je může přeposlat, s kým na úkolu spolupracuje nebo komu může úkol nasdílet aj. Procesní modely: BPEL procesy se vytváří v komponentě Oracle JDeveloper, kterou lze spustit samostatně za přítomnosti JRE nebo jako plug-in ve vývojovém prostředí Eclipse. Aktivity procesu se modelují v jedné řadě pod sebe. V tomto kontextu se aktivitou rozumí více činností, může tvořit určitý úsek procesu, který lze rozbalovat na nižší úroveň detailu. Příkladem nižší úrovně detailu rozhodovacího stromu může být obsah větve za rozhodovacím stromem až do okamžiku, kdy se obě větve spojí. Schovávání detailů umožní pohodlnou čitelnost procesu od shora dolů. Při nejvyšší úrovni detailu je proces snadno čitelný, avšak je příliš obecný. Na nižší úrovni detailu se sice zpravidla ani jednoduchý proces nevejde na jednu obrazovku (při standardní velikosti), avšak je již kompletní. Důvodem může být snaha o přehlednost napojení aktivit na služby. V levé části je proces napojen na služby, které jej volají, a v pravé části na služby, které využívá. Asi jediným drobným omezením je to, že dlouhý proces rozbalený do detailu je příliš dlouhý a málo široký, což může být nepříjemné při tisku. Rozmístění aktivit nelze vizuálně upravovat, protože jsou na pracovní ploše umístěné napevno v daných vzdálenostech. Tyto parametry lze měnit v nastavení. Dále existují různá barevná schémata pro používané objekty a chybové hlášky. Celkově hodnotím přehlednost při modelování procesů kladně. Každý proces se chová jako jedna webová služba. Jestliže jeden podnikový proces využívá jiný proces, v BPEL notaci v kontextu webových služeb se namodeluje podproces, který se chová jako webová služba, a jako služba se rovněž volá. Každý proces je vlastně různou granularitou služeb. Při vytváření BPEL procesu se volí šablona procesu, která určí, zda bude proces, a tím i služba, synchronní nebo asynchronní. Synchronní volání služeb se používá, když se očekává odezva v krátkém čase, zatímco asynchronní volání služeb se používá pro dlouhotrvající transakce. Oracle JDeveloper má mnoho podobného s klasickým vývojovým prostředím. Model se kontroluje automaticky a systém zobrazuje nevalidní části. Od každé nesrovnalosti vede odkaz na nápovědu. Existuje možnost ladění (debugging) modelu, při kterém se transparentně prochází jednotlivé kroky procesu. V hlavním menu je možnost napojení modelu na CVS. Monitorování průběhu procesů: Oracle nabízí nástroje na sledování průběhu procesů. Oracle BPEL Process Analytics poskytuje dashboard, který vyhodnocuje doby průběhu procesů podle předem stanovených metrik a jasně zobrazuje odchylky od plánu. Business analytik může definovat KPI na procesy definované v BPEL Process Manageru, které implementují jeden podnikový proces a následně může sledovat skutečnou výkonnost KPI. Nástroj poskytuje možnost upozornění manažerů, když se skutečnost odchýlí od stanoveného KPI. Zpětná vazba o průběhu procesů umožní lepší provázanost mezi transakčními procesy a strategickým řízením. Příkladem KPI může být průměrná doba potřebná pro poskytnutí půjčky zákazníkovi, která zahrnuje proces ověřování bonity klienta. V nástroji lze vytvořit dimenze, přes které se má KPI sledovat. Definování dimenzí není povinné, pouze rozšiřuje analytické možnosti. Nástroj nabízí přehledné grafické zobrazení sledovaných metrik 24

28 Cílem analýzy je odhalit příčiny, které nejvíce ovlivňují hodnotu KPI. Featura analýza příčin a efektů zobrazuje, které KPI (příčiny) nejvíce ovlivňují sledované KPI (efekt) pro vybraný časový úsek. Jako příklad uvedu vztah mezi celkovou výší poskytnutých úvěrů a průměrnou částkou poskytovaného úvěru. Obr. 11 Oracle BPEL Process Manager - Business Activity Monitoring 7 Simulace: Nástroj umí vytvářet predikci KPI podle statistických metod na základě naměřených hodnot a označit odchylky předikovaných KPI od plánu. 7 [5] Oracle BPEL Process Manager x Quick start tutorial 25

29 8 Microsoft BizTalk Server 2006 BizTalk Server 2006 je server společnosti Microsoft pro vývoj řešení pro obchodní procesy a integraci. BizTalk Server 2006, čtvrtá verze tohoto produktu, je založen na inovacích a úspěšných funkcích předchozích třech verzí BizTalk Server 2000, 2002 a Jde především o nástroj určený k integraci skupiny aplikací v jeden funkční celek. BizTalk umožňuje jednoduše a rychle vyvinout vrstvu, pomocí níž se propojí různé systémy dohromady tak, aby informace mezi nimi mohly proudit co nejrychleji, a aby se snížilo riziko zavlečení chyb, přičemž celý návrh je vizuální. 8.1 Obecné informace Název: Microsoft BizTalk Server 2006 Verze: 2006, nová verze každé 2 roky od r Cena a licence: Enterprise edition $, za CPU Standard edition $ Developer edition 500 $ (za uživatele) 120-denní trial verze zdarma Minimální hardwarové požadavky: Procesor - kompatibilní s Intel Pentium, který má 1 GHz, pokud má jeden procesor 900 MHz, pokud je dvouprocesorový 700 MHz, pokud je čtyřprocesorový Podporovány jsou i dvoujádrové procesory. Operační paměť: 1GB RAM Hard disk: 15 GB volného místa pro kompletní instalaci (včetně operačního systému, všeho nezbytného software a jazykových balíčků; nezahrnuje prostor pro uložení dat) Minimální softwarové požadavky: Windows Server 2003 (včetně SP1 nebo SP2), Windows Server 2003 R2. Podporovány jsou také 64-bitové edice Windows Server Microsoft Internet Information Services (IIS) 6.0 Microsoft Office Excel 2003 a Microsoft Office InfoPath 2003 (včetně SP2). Podporovýny jsou i Microsoft Office Excel 2007 a Microsoft Office InfoPath Microsoft Visual Studio 2005 with Visual C#.NET. SQL Server 2005 (SP2) nebo SQL Server 2000 (SP4). 26

30 SQL Server 2005 Analysis Services (SP2) nebo SQL Server 2000 Analysis Services (SP4). SQL Server 2005 Notification Services (SP2) nebo SQL Server 2000 Notification Services 2.0 (SP1). Microsoft Windows SharePoint Services 2.0 (SP2). Jeden z produktů - Windows SharePoint Services 2.0 (SP2), Windows SharePoint Services 3.0, Microsoft Office SharePoint Server 2007 (MOSS). 8.2 Podpora Lokalizace: Microsoft BizTalk Server 2006 je lokalizován do devíti světových jazyků (angličtina, němčina, francouzština, španělština, italština, korejština, zjednodušená čínština a tradiční čínština), čeština mezi ně však zatím nepatří. Klávesové zkratky: Většina součástí BizTalk Serveru 2006 je plně ovladatelná klávesnicí. Nástroj nabízí velké množství předdefinovaných klávesových zkratek. Použitelné jsou vždy právě jen ty, které mají v daném okamžiku smysl, případně se jejich význam liší v závislosti na použitém kontextu. Možnost definování nových klávesových zkratek uživatelem, respektive přemapování předdefinovaných zkratek, se nám nepodařilo potvrdit ani vyvrátit. Nicméně si myslíme, že tuto možnost BizTalk Server 2006 nepodporuje. Dokumentace: Microsoft BizTalk Server nabízí mnoho druhů dokumentace, které mohou uživateli usnadnit práci. Protože však produkt není lokalizován do češtiny, musí se uživatelé smířit s tím, že většina zdrojů je v angličtině. Často zmiňovaným problémem může být, že dokumentace je velmi stručná, strohá a omezuje se pouze na základní popis funkcionality produktu. Kromě klasické dokumentace a přímého supportu dodavatelem BizTalk Serveru 2006 lze nalézt mnoho dalších zdrojů, jako např. tutoriály, vzorové scénáře business řešení, blogy, newsgroups, diskusní fóra apod. Školení: Společnost Microsoft nabízí možnost spolupráce s BizTalk výukovým centrem, jehož prostřednictvím lze získat výukové materiály či plány k certifikačním zkouškám nebo se přímo zúčastnit e-learningových kurzů. Další možností je účast na školeních, které zahrnují různé kurzy, workshopy, virtuální laboratoře a mnoho dalších možností podpory a pomoci uživatelům při implementaci a zavádění řešení BizTalk Server. Nápověda: Nápověda je podobně jako u většiny produktů kontextová. K dispozici je obsah, jmenný rejstřík a v neposlední řadě samozřejmě vyhledávání podle klíčového slova. 8.3 Koncepce Architektura: Architektura BizTalk Server 2006 zahrnuje mnoho nástrojů, služeb a technologií pro efektivní vytváření EAI (Enterpise Application Integration), B2B (Business To Business) a BPM (Business Process Management) řešení. 27