POUŽITÍ CASE/CABE PRO ŘÍZENÍ WORKFLOW VE FIRMĚ (VAZBA

VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE FAKULTA INFORMATIKY A STATISTIKY POUŽITÍ CASE/CABE PRO ŘÍZENÍ WORKFLOW VE FIRMĚ (VAZBA NA NÁSTROJE WORKFLOW, TRENDY A MOŽNOSTI) 4IT450 | CASE ‐ Computer Aided Systems Engineering semestrální práce Martin Hájek, [email protected] Jiří Jakeš, [email protected] Martin Jindřich, [email protected] Nikos Margaris, [email protected] Miroslav Přívratský, [email protected] Prosinec 2009 Abstrakt Turbulentní tržní prostředí klade značné nároky na efektivní řízení podniku. Jedním ze způsobů, jak mohou společnosti čelit tomuto tlaku, je zavedení workflow. Ve své podstatě představuje workflow především koncept, ale tento pojem bývá užíván i pro technologie pro automatizaci podnikových procesů a s nimi souvisejícími aktivitami (např. předávání dokumentů, řízení podnikových zdrojů apod.). Kromě toho systémy workflow umožňují také sledování, hodnocení, řízení nebo optimalizaci podnikových procesů. Kromě vymezení teoretické problematiky workflow a souvisejících pojmů, se tato studie dále zaměřuje právě na systémy řízení workflow, resp. CASE/CABE nástroje zaměřené na informační podporu pro workflow. Jedná se o nástroje Documentum, Nintex a OpenText BPM Desinger. Klíčová slova Workflow, WF, systémy řízení workflow, WfMS, počítačem podporovaný vývoj softwaru, CASE, počítačem podporovaný business, CABE, Documentum, Nintext, OpenText BPM Designer Abstract Turbulent economic environment places considerable requirements on company and effective company management. Workflow represents one way how accept this new challenge. Nowadays workflow is well established both concept and often also information technology for modeling, monitoring a managing processes, which are running inside the organization. However workflow is more like concept, how to do process automation and CASE/CABE represent implementation of this concept into information technology. A side from theoretic background about workflow, this thesis also provides characteristics of few CASE/CABE tools such as Documentum, Nintex and OpenText BPM Designer. Key words Workflow, WF, workflow management systems, computer aided software engineering, CASE, computer aided business engineering, CABE, Documentum, Nintext, OpenText BPM Designer Obsah 1 Úvod ........................................................................................................................................ 4 2 Cíle a metodika práce .............................................................................................................. 5 3 Teoretické zázemí .................................................................................................................... 6 3.1 CASE ......................................................................................................................................... 6 3.1.1 Přínosy využití nástrojů CASE ...................................................................................... 7 3.1.2 Možné nástrahy nástrojů CASE ................................................................................... 8 3.1.3 Druhy nástrojů CASE ................................................................................................... 9 3.2 Související standardy ................................................................................................................ 9 3.3 Workflow ............................................................................................................................... 12 3.3.1 Co je to workflow? .................................................................................................... 12 3.3.2 Klasifikace systémů workflow ................................................................................... 12 3.3.3 Základní koncepty workflow ..................................................................................... 14 3.3.4 Referenční model workflow ...................................................................................... 16 3.3.5 Přínosy workflow....................................................................................................... 20 4 Nástroje pro řízení workflow ve firmě .................................................................................... 21 4.1 Nintex Workflow 2007 ........................................................................................................... 21 4.1.1 Šablony a Snippets .................................................................................................... 24 4.1.2 Sledování Workflow .................................................................................................. 24 4.2 Open Text – BPM Server ........................................................................................................ 26 4.2.1 Process Designer ....................................................................................................... 27 4.2.2 BPM Web Process Manager ...................................................................................... 29 4.2.3 Process Service .......................................................................................................... 31 4.3 EMC Documentum Process Suite ........................................................................................... 33 4.3.1 EMC Documentum Process Analyzer ........................................................................ 34 4.3.2 EMC Documentum Process Simulator ...................................................................... 35 4.3.3 EMC Documentum Process Navigator ...................................................................... 36 4.3.4 EMC Documentum Process Builder .......................................................................... 36 4.3.5 EMC Documentum Forms Builder ............................................................................. 37 4.3.6 EMC Documentum Process Engine ........................................................................... 37 4.3.7 EMC Documentum Process Integrator ..................................................................... 38 4.3.8 EMC Documentum TaskSpace .................................................................................. 38 4.3.9 EMC Documentum Business Activity Monitor .......................................................... 39 4.3.10 Documentum Process Suite a platforma Documentum ........................................... 40 5 Závěr ..................................................................................................................................... 41 6 Zdroje .................................................................................................................................... 42 3 1 Úvod Jedním z příznaků moderní doby je komplexní, dynamické a rychle se měnící ekonomické prostředí. Podnik, jehož cílem je zajistit si stabilní pozici a odpovídající tržní podíl, tak čelí celé řadě rychle se vyvíjejících činitelů, od požadavků současných i potenciálních zákazníků, přes konkurenci, vliv partnerských firem až po legislativu a současný ekonomický stav. V tomto turbulentním prostředí se tradiční způsoby řízení, založené na funkčním přístupu a hierarchické organizační struktuře, stávají neefektivními. V rámci hierarchicky postavených organizací jsou klíčové procesy často roztříštěné, značně rigidní a příliš složité, než aby bylo možné je efektivně spravovat. Tato situace je způsobena rozložením pravomocí a odpovědností napříč organizační strukturou společnosti. Pracovníci jsou v rámci takovýchto organizací specializováni pouze ne určité činnosti, často nemají a ani nepotřebují mít přehled o celém produkčním cyklu nebo další znalosti. Problém společnosti přichází v případě, kdy zákaznici nechtějí standardizovaný produkt, je potřeba distribuovat a předávat práci mezi jednotlivými útvary apod. V konečném souhrnu se řízení společnosti stává natolik komplikovaným, že je možné jej realizovat převážně pomocí sledování finančních ukazatelů. Snaha o zefektivnění řízení procesu a především zvýšení orientace na zákazníka vedla řadu společností k přechodu na procesní řízení. Základním cílem společnosti se stává uspokojení zákaznické potřeby konečným produktem. Celý koncept procesního řízení je tedy postaven na 3 pilířích: identifikace zákaznické potřeby, produktu, který ji uspokojuje a procesu, jehož výstupem je daný produkt. Na výrobní cyklus je tedy pohlíženo jako na komplexní, kompozitní objekt, který je možno rozložit na dílčí činnosti a jehož hlavním výstupem je produkt přinášející přidanou hodnotu pro zákazníka. Hlavním cílem procesního řízení je zefektivnit všechny podnikové procesy, dále eliminovat, nebo alespoň redukovat, veškeré procesy a činnosti, které nepřináší přidanou hodnotu. S přechodem na procesní řízení dochází k eskalaci potřeby na vytvoření jednotné platformy pro správu a řízení podnikových procesů. Nedá se ovšem tvrdit, že by samotné procesní řízení stálo za zrodem workflow, tj. automatizaci podnikových procesů. První systémy zaměřené na automatizaci pracovního toku, byly postaveny na principech funkčního řízení. Základním stavební jednotkou těchto systémů byly dovednosti a specializace pracovníků, příp. jejich organizační umístění. Práce, resp. pracovní proces probíhal sekvenčně, po dokončení určitého pracovního bloku, byla předána dalšímu zaměstnanci, často spadající do jiné funkční jednotky. Základním problémem, na který se tyto systémy zaměřovaly, byla koordinace a distribuce práce. S příchodem procesního pojetí organizace se automatizace podnikových činností zaměřuje na procesy, jejich modelování, definici a řízení. 4 2 Cíle a metodika práce Cílem této práce je sumarizovat informace a znalosti uvedené v předešlých pracích, případně je doplnit a rozšířit v oblastech, kde to bude vhodné. Dále se studie zaměřuje na revizi již uvedených CASE/CABE nástrojů a rozšíření seznamu již uvedených nástrojů. Teoretická část této studie pokrývá znalosti spojené s principy workflow, souvisejícími technologiemi a standardy. Tato problematika je zpracována na základě studia informačních pramenů. Informace budou čerpány jak z primárních pramenů, tak samozřejmě i sekundární literatury, která sestává z prací již vypracovaných na podobné téma v průběhu minulých semestrů. Cílem praktické části je přiblížit čtenářům některé CASE, resp. CABE nástroje, které podporují workflow a workflow management. V této oblasti si práce klade za cíl zaměřit se na nástroje, které ještě nebyly identifikovány a popsány předcházejícími týmy. Zabývat se bude produkty Nintex Workflow 2007, Documentum a Opentext BPM Designer. 5 3 Teoretické zázemí 3.1 CASE1 CASE, neboli Computer‐Aided Software Engineering, je, jak napovídá samotný název, označení pro aplikace nacházející uplatnění při vývoji informačních systémů a ostatního software. Jsou to nástroje, které usnadňují vývoj počítačových systémů prostřednictvím modelování relevantních aspektů firemního prostředí, typicky procesů, datových bází, infrastruktury, ale např. i cílů firmy, organizačních struktur, okolí podniku a příslušných vazeb apod. Aplikace CASE se začaly rozvíjet přibližně před 25 lety ruku v ruce s významnějším rozvojem počítačů pro podnikové využití. Nástroje CASE mohou rovněž pomáhat řídit vývoj konkrétního systému jako projekt, a je tak kladený důraz na včasné dodání, dodržení rozpočtu, řízení a alokace zdrojů apod. Prohloubení a zefektivnění spolupráce všech lidí, kteří se na vývoji podílejí, patří k největším přínosům CASE nástrojů. Významným rysem těchto nástrojů je také podpora vývojových standardů. Dalším rysem je implementace společných tzv. projektových repository, které fungují jako sklady výstupů týmové i individuální práce. Pokud člen týmu vytvoří model nebo kus kódu, uloží ho do společného úložiště a tím umožní všem ostatním členům týmu přístup a sdílení těchto výstupů. Výhodou je kromě sdílení přístupu i jednodušší zálohování všech důležitých souborů, jejich rychlá dostupnost, a snadná aktualizovatelnost. Znakem, společným pro všechny CASE nástroje, je i snaha zajistit znovupoužitelnost již jednou vytvořeného programového kódu. Jak uvnitř jedné aplikace, tak mezi různými aplikacemi. Je to jeden z hlavních způsobů jak ušetřit náklady při vývoji aplikací. Vlastností umožňující zredukovat náklady použitím CASE nástrojů jsou i prostředky pro usnadnění údržby vytvořené aplikace. Na trhu se vyskytuje značné množství CASE nástrojů nejrůznějšího funkčního záběru i určení. Valná většina nejznámějších aplikací byla rozebrána v předchozích seminárních pracích, a vzhledem k tomu, že téma této práce je navíc pouze specifičtěji vymezená kategorie nástrojů CASE, nebylo by ani účelné, ani věcné, snažit se tyto nástroje opět klasifikovat a rozepisovat (v předchozích pracích jsou kromě základního popisu funkcionality a náhledů obrazovek k dispozici také informace o možnostech jejich pořízení, či poskytované podpoře výrobců a distributorů, anebo různé srovnávací tabulky). Pro získání uceleného obrázku je připojené stručné zařazení vybraných nástrojů do skupin podle cílové skupiny uživatelů [2]: • Velké podniky: IDS Scheer Aris, IBM Rational Rose Modeler, Oracle Designer, Select Architect, Power Designer • Malé podniky: Magic Draw UML, JUDE Professional • Jednotlivci: Umbrello UML Modeller, Dia, Toad Data Modeler • Všechny skupiny: Sparx Enterprise Architect, Altova UModel, Visio 1
Pro zpracování úvodní teoretické kapitoly byla provedena rešerše předchozích prací [1], [2] zpracovaných v rámci kurzu CASE, jejich vzájemné uvedení do kontextu, a tematické rozšíření. 6 Hlavní přínosy a potenciální nebezpečí nástrojů CASE jsou shrnuty v následujícím schématu a blíže rozepsány v navazujícím textu níže: +
–
Vyšší produktivita vývojových týmů
Nevhodný výběr nástroje či jejich nevhodná kombinace
Snížení nákladů na vývoj
Nevhodná kombinace CASE nástrojů
Nižší riziko chybovosti vyvíjeného systému
Vysoké pořizovací náklady
Snadnější údržba a další vývoj výsledného produktu
Vysoké nároky na kvalifikaci uživatelů
Kvalitnejší dokumentace
Zjednodušení administrativy vývojového projektu
Zjednodušení administrativy vývojového projektu
3‐1: Přínosy a rizika CASE nástrojů 3.1.1 Přínosy využití nástrojů CASE Využití nástrojů CASE s sebou samozřejmě přináší celou řadu výhod. V této podkapitole jsou shrnuty ty nejpodstatnější [1]. Vyšší produktivita vývojových týmů Dochází ke značnému zrychlení spolupráce jednotlivých členů vývojových týmů. Díky automatizaci práce, kterou s sebou využití CASE přináší, dochází k urychlení zpracování a tím zvýšení produktivity práce (dle odhadu až zdvojnásobení). Samozřejmě obrovským přínosem je též podpora práce několika vývojářů, respektive návrhářů, na projektu současně. Snížení nákladů na vývoj Souvisí mj. se snížením doby potřebné pro vývoj daného produktu. Nižší riziko chybovosti vyvíjeného systému Využití nástrojů CASE s sebou přináší možnost průběžné kontroly, které vedou k lepšímu a rychlejšímu odstraňování chyb. Netřeba dodávat, že čím dříve jsou chyby detekovány a odstraněny, tím nižší jsou náklady s tím spojené. Čím vetší a robustnější informační systém, tím je identifikace chyb obtížnější a jejich odstraňování problematičtější a nákladnější [1]. Snadnější údržba a další vývoj výsledného produktu Výsledkem kvalitnějšího návrhu, dokonalejší analýzy, automatického generování aplikačního kódu, automatizovaného testování a včasného odstranění chyb je vyšší kvalita celého 7 systému. Díky generované dokumentaci (viz níže) je též snadnější a levnější údržba celého systému během jeho životního cyklu. Kvalitnější dokumentace Jednodušší tvorba a správa dokumentace projektu je dalším znakem nástrojů CASE. Jsou poskytovány mj. nástroje pro automatické generování dokumentace. Zjednodušení administrativy vývojového projektu Je dosaženo díky implementaci některých funkcionalit potřebných pro efektivní projektové řízení. Vetší angažovanost uživatelů na vývoji produktu Možnosti flexibilního vedení projektu umožňují zapojení většího počtu účastníků. 3.1.2 Možné nástrahy nástrojů CASE Využití CASE nástroje umožňuje (převážně díky srozumitelným diagramům) lepší možnost participace uživatelů na vývoji produktu, což vede ke zkrácení doby nutné k zaučení uživatelů v práci s novým systém. Ačkoliv s sebou využití CASE nástrojů bezesporu přináší mnoho výhod, je potřeba zmínit též úskalí, na která lze při používání CASE nástroje narazit [1]: Nevhodný výběr nástroje či jejich nevhodná kombinace Aby společnost díky využití CASE nástroje skutečně dosáhla úspor nákladů a dalších prezentovaných výhod, je nutné dbát zvýšené pozornosti na správný výběr tohoto nástroje, např. s ohledem na integraci nástrojů CASE a integraci dat přes všechny platformy. V této věci mohou poskytnout cenné informace předchozí seminární práce věnované úzce aplikacím CASE. Nevhodná kombinace CASE nástrojů Vhodným výběrem konkrétního nástroje ještě nemá firma vyhráno, zejména pokud takových nástrojů využívá, anebo plánuje využívat více. Pozornost vyžaduje také případný přechod z jednoho nástroje CASE na jiný. Vysoké pořizovací náklady Mezi CASE nástroji sice najdeme i freeware produkty, ale obecněji lze říci, že tyto nástroje nejsou levné. Při kalkulaci nákladů na jejich pořízení nesmí být opomenuto zahrnutí nákladů na potřebný hardware, software, školení zaměstnanců a v neposlední řadě také náklady na podporu a údržbu systému. Teprve tyto celkové náklady je žádoucí porovnávat s úsporami, které se od zavedení nástroje očekávají. 8 Vysoké nároky na kvalifikaci uživatelů Při zavádění CASE nástrojů je na místě počítat se zvýšenými nároky na kvalitu a znalosti uživatelů. Pro správné používání je nutné si osvojit celou řadu technik a postupů, které jsou závislé na konkrétním typu nástroje. 3.1.3 Druhy nástrojů CASE Tato sekce přehledně rekapituluje jedno z možných rozdělení nástrojů CASE [1]: Interaktivita
•CASE nástroje, které jsou interaktivní ze své podstaty (např. nástr. podporující metodu návrhu)
•CASE nástroje, které nejsou interaktivní (tzv. vývojové nástroje ‐ napr. kompilery)
Fáze projektu •front‐end CASE (využívány v drívejších fázích projektu – napr. nástroje na podporu návrhu)
•back‐end CASE (využívány v pozdejších fázích projektu – napr. nástroje podporující testování)
Stupeň integrace
•CASE tools (automatizovaná podpora libovolné úlohy životního cyklu SW (dále jen SDLC))
•CASE toolkits (soubor integrovaných nástroju, poskytujících podporu v rámci 1 fáze SDLC)
•CASE workbenches (integrované CASE tools /toolkits, poskytující podporu v min.2 fázích SDLC)
•I – CASE (nejvyšší stupeň integrace; propojení CASE tools, CASE toolkits a CASE workbenches)
Využití během životního cyklu SW
•vertikální CASE (nástroje podporující jen dílcí krok životního cyklu software ci dílcí oblast)
•horizontální CASE (nástroje podporující nekolik kroku životního cyklu software ci více oblastí)
Fáze životního cyklu IS
•Pre CASE (podporuje činnosti předcházející vývoji IS – globální strategie)
•Upper CASE (podporuje tvorbu informační strategie a analýzu)
•Middle CASE (podporuje tvorbu globálního a detailního návrhu IS)
•Lower CASE (podporuje fázi implementace)
•Post CASE (podporuje fázi uvedení IS do provozu, provoz, údržbu, reengineering)
3‐2: Rozdělení CASE nástrojů 3.2 Související standardy S tématem využívání nástrojů CASE úzce souvisí využívání nejrůznějších standardů a technologií. Koneckonců je to i jedním z nemalých přínosů CASE nástrojů, že jsou s obecně platnými standardy kompatibilní a prosazují tak jejich aplikaci v praxi, což vývoj a údržbu systémů bezpochyby usnadňuje. Zároveň tím, že celý tým používá stejný CASE nástroj, je zajištění dodržení vývojových standardů všemi členy týmu jednodušší. Tato kapitola se zaměří na některé klíčové standardy, jejichž alespoň základní povědomí je pro porozumění kontextu CASE nástrojů (zejména se zaměřením na řízení workflow) výhodou, ne‐li nutností. Mnohé standardy byly již zpracovány v předchozích pracích, a proto zmíněny budou jen standardy dosud nezpracované, anebo revidované či doplněné. BPMN Standard BPMN (Business Process Modeling Notation), byl vyvinut, aby umožnil tvořit srozumitelné grafické znázornění business procesu. Tento standard byl vytvořen (verze 1.0 publikována v květnu 2004) skupinou BPMI (Business Process Management Initiative) a v roce 2006 standardizován konsorciem OMG (Object Management Group). 9 Stěžejním úkolem bylo poskytnout notaci, která by byla citelná pro všechny uživatele – od analytiků přes programátory až po takové uživatele, kteří budou procesy monitorovat a řídit. BPMN je také možné, díky jeho XML povaze, také využít pro generování dalších formátu (XPDL, BPEL, BPEL4WS). Díky tomu BPMN vytváří most mezi business orientovanou analýzou a designem procesů a jejich implementací [1]. BPMN 2.0 Business Process Model and Notation je zatím jen pracovní jméno budoucího standardu BPMN 2.0 [17]. Cílem BPMN 2.0 je sjednocení do jediné specifikace pro Business Process Model and Notation která definuje notaci, metamodel a výměnné formáty pod známým a osvědčeným názvem "BPMN". Mezi navržené vlastnosti patří [1]: • Spojení BPMN s business process definition meta modelem BPDM do jednoho konzistentního jazyka. • Umožnit převod modelu mezi modelovacími nástroji. • Umožnit uživateli rozdílný pohled na model podle jeho aktuální potřeby. • Serializovat BPMN a poskytnout XML schéma pro transformaci modelů a rozšířit BPMN směrem k procesnímu modelování a podpoře businessu. Přestože mělo být BPMN 2.0 dle původních záměrů již uvedeno do praxe, zatím je stále v procesu schvalování. Klíčovým momentem bylo finální návrh podaný 22. Června 2009, který získal 4 rozhodující hlasy a je připraven stát se OMG (Object Management Group) „alfa“ specifikací na podzim 2009 [3]. Wf‐XML Standard jazyka Wf‐XML je rozšířený interface, který umožňuje komunikovat mezi WfMS (Workflow Management Systems) a externími službami. Rozhraní vytváří procesy a jejich instance pracující s asynchronními (požadavek/odpověď) protokoly. Dnešním trendem je XML‐driven workflow, tedy takový systém, který si o zpracovávaných datech dokáže zjistit potřebné informace sám (automatizované), anebo mu jsou tyto informace přiřazeny pro zadávání (manuální) – podle nich pak automaticky probíhá vlastní zpracování tiskových dat [1]. Wf‐XML 2.0 Wf‐XML 2.0 od WfMC propojuje možnosti BPM a modelování workflow. Business proces engine je speciální typ asynchronní služby. Průběh takové služby je znázorněn takto: spuštěna, ke službě jsou přirazeni lidé, služba je dokončena v určitý čas. Některé BPMS mají integrovány různé konektory, ať již obecné, nebo vytvořené pro konkrétní software. Rozhraní na vyšší úrovni představuje integrace na úrovni samotných BPMS. Pod tím si lze představit schopnost jednoho BPMS zavolat v rámci svého procesu subproces jiného BPMS. Standardy definující komunikační jazyk pro tato volání jsou zejména Wf‐XML, AWSP, WSDL. Wf‐XML 2.0 je definovaný prostřednictvím WSDL (Web Services Description Language), a proto je obecně akceptovaný jako webová služba. Je důležité také zmínit, že služby 10 vyvinuté pomocí Wf‐XML 2.0 nejsou zpětně kompatibilní se službami využívajících Wf‐XML 1.1, jelikož předchozí protokol nebyl založený na SOAP (Simple Object Access Protocol) zprávách [4]. XPDL Standard XML Process Definition Language (XPDL) je podle jeho tvůrce Workflow Management Coalition (WfMC) široce používaným jazykem pro definici procesu. Jedná se o BPM standard, který je podporován širokým spektrem aplikací – ERP systémy, call centra, CRM systémy, Business Intelligence, Business Activity Monitoring (BAM), ECM, nástroje pro procesní modelování a simulaci procesu atd. První verze tohoto jazyka byla nazývána Workflow Process Definition Language (WPDL). Tato verze byla poprvé představena v roce 1998. Tento procesní metamodel obsahoval všechny klíčové části nutné pro automatizaci workflow. Ve stejném roce se objevily i první standardy založené na jazyce XML. Pracovní skupina 1 tento standard přepracovala a představila ho již pod jménem XPDL (verze 1.0). XPDL 1.0 byla WfMC uznána v roce 2002, následně byl tento standard implementován do mnoha nástrojů, jako svůj výměnný formát [1]. XPDL 2.0 V roce 2004 se WfMC začala hlásit k BPMN. XPDL bylo rozšířeno tak, aby pomocí XML dokázalo popsat BPMN diagramy. Tato verze byla pak v říjnu 2005 standardizována jako XPDL 2.0. Tato verze je zpětně kompatibilní s původní verzí 1.0. XPDL se pro svůj původ v XML používá různými nástroji především jako výměnný formát. Jak již bylo řečeno, je implementován do mnoha nástrojů pro návrh a správu procesu. Existují však nástroje, které primárně používají právě formát XPDL [5]. Na rozdíl od BPEL, programovacího jazyku, jehož cílem je poskytnout definice webových služeb s důrazem na tok dat, cílem XPDL je poskytovat procesní diagram pro zápis a čtení různými nástroji [6]. Další standardy Mezi další standardy a přístupy, které mohou s problematikou vývoje a řízení workflow nástrojů úzce souviset patří i Zachman Enterprise Architecture, anebo ITIL, jež se zaměřují mj. na popis a definici podnikového prostředí v kontextu informačního managementu. Za zmínku stojí i jazyk UML, který je hojně využíván při dokumentaci a návrhu informačních systémů mnoha různých zaměření. Podrobnější zpracování těchto standardů by však obsahově přesahovalo zamýšlený rozsah úvodu do práce se zaměřením na CASE pro řízení workflow. 11 3.3 Workflow 3.3.1 Co je to workflow? Jak již bylo zmíněno v úvodu práce, je na podniky dnes často pohlíženo jako na množinu vzájemně propojených procesů, které mají různou strukturu, využívají odlišné zdroje, a pro podnik samotný mají často i odlišný význam. Koncept workflow lze zjednodušeně charakterizovat jako podnikovou informační platformu, nebo přinejmenším její součást, která se přímo podílí na efektivní správě procesů, které probíhají uvnitř podniku. Blíže si tento pojem můžeme přiblížit jako skupinu nástrojů, pomocí kterých lze modelovat jednotlivé procesů v takové míře detailu, která umožňuje sledovat alokaci zdrojů, výměny a distribuce dokumentů, přiřazení účastníků apod. Dále tyto nástroje zahrnují prostředky pro monitorování, řízení procesů a množinu klientských aplikací, které umožňují vykonávání jednotlivých úkolů nebo činností v rámci procesu. Často se také setkáme s výkladem pojmu workflow jako určité kompozice logiky vykonávaného procesu a množiny řídících, resp. procedurálních pravidel. Logika procesu definuje pořadí a návaznosti jednotlivých dílčích činností, tak jak mají být v rámci konkrétního způsobu vykonány. Zatímco procedurální pravidla hovoří o závislostech, omezeních a vazbách jednotlivých úkolů. Je zřejmě, že výkladů pojmu workflow existuje celá řada. V rámci snah o sjednocení pohledu na tuto poměrně komplexní problematiku vydala Workflow Management Coalition (WMC) následující definici: "Workflow znamená automatizaci celého nebo části podnikového procesu, během kterého jsou dokumenty, informace nebo úkoly předávány od jednoho účastníka procesu k druhému podle sady procedurálních pravidel tak, aby se dosáhlo nebo přispělo k plnění celkových/globálních podnikových cílů" [7]. WMC se také snaží vytvořit jasnou hranici mezi konceptem workflow a jeho vlastní implementací za pomoci informačních technologií. Systém řízení workflow (WfMS) je schopen na základě definice vytvořit a řídit průběh proces, zajišťovat interakci s jeho účastníky a v případě potřeby zajistit spolupráci s dalšími informatickými nástroji nebo aplikacemi. [9] 3.3.2 Klasifikace systémů workflow Pro klasifikaci workflow systémů lze využít celou řadu přístupů i kritérií. Asi nejčastěji se můžeme setkat s dělením aplikací dle podnikové hodnoty (významu procesu) a struktury procesu. Dle charakteru procesů lze rozlišit následující typy workflow systémů dle [7]: • Administrativní • Ad‐hoc • Kolaborativní • Produkční Administrativní systémy jsou svoji povahou přizpůsobeny zejména často opakovaným, dobře strukturovaným a popsaným procesů. Často se uvádí, že jsou zaměřeny především na 12 zvládání každodenních úloh spojených s hlavní činností firmy, jako např. fakturace, obesílání zákazníků apod. Ad‐hoc workflow je navrženo pro spatně strukturované procesy, které mají v organizaci relativně nízkou četnost a vznikají pouze za určitých okolností. Kolaborativní aplikace nabízejí podporu a řízení spolupráce. Produkční systémy jsou orientovány na hlavní podnikové procesy. Zpravidla tedy řeší dobře popsané, strukturované a značně formalizované procesy, u kterých je ošetřena i majoritní většina výjimek. Cíle produkčního workflow je zajistit maximální efektivitu vykonávání hlavní činnosti podniku, často proto vyžadují integraci do další podnikových aplikací. Produkční Administrativní
Kolaborativní
Ad‐hoc • Procesy jsou podrobně strukturovány • Procesy jsou formalizovány • Většina odchylek je předem ošetřena • Procesy bývají složité • Je vyžadována rychlá doba odezvy, vysoká průchodnost • Vyžadují integraci s dalšími aplikacemi • Cílem je vysoká produktivita • Konkrétní procesy často využívá vymezený okruh uživatelů • Procesy jsou dobře strukturované, předem definované • Není požadována taková průchodnost jako u produkčních systémů • Nahodile jsou tyto procesy využívány většinou uživatelů • Procesy jsou obvykle spojeny s formuláři či jinými dokumenty • Procesy nejsou příliš strukturovány • Důraz je kladen na zajištění řízené spolupráce účastníků procesu • Důležitá je snadná dynamická možnost změny procesu • Průchodnost procesu není rozhodující • Důležitá je snadná a rychlá definice procesu v okamžiku potřeby • Procesy definují koncoví uživatelé • Existuje možnost dynamických modifikací procesů • Požadavky na průchodnost jsou nízké • Cílem jsou nulové náklady a žádná správa 3‐3: Srovnání workflow systémů [7] Existují samozřejmě i jiné možnosti dělení, další možné charakteristiky jsou např. technologická infrastruktura a orientace procesů. Dle infrastruktury, na které je systém workflow realizován, tedy rozlišujeme produkty založené na [7]: • elektronické poště, • dokumentech, • procesech, • internetových technologiích. Z hlediska orientace procesů pak rozlišujeme [7]: • procesy zaměřené na lidi, • procesy zaměřené na sebe. Výše popsaná dělení jsou pouze jedním z možných způsobů, jak rozlišit workflow aplikace. Při nasazení v reálném prostředí se systémy svou funkcionalitou často překrývají, a často jsou založeny na celé řadě technologií. 13 3.3.3 Základní koncepty workflow Modelování, návrh a definice procesu Nástroje pro modelování, definici a přesný popis procesu jsou základním stavebním kamenem celého konceptu workflow. Vytvoření definice procesu představuje abstrakci skutečných činností, zdrojů a pracovníků do podoby, která je vhodná pro automatizované řízení procesu. Každý proces se v rámci definice stává kompozitním objektem, který zahrnuje celou řadu činností, účastníků, rolí zdrojů, které jsou vzájemně provázány pomocí různých asociačních nebo procedurálních pravidel. Často hovoříme o tzv. mapě procesu, proces je v konečné fázi návrhu reprezentován orientovaným necyklickým grafem. Základní vztahy mezi modelovanými prvky jsou reprezentovány v meta‐modelu definice procesu. má
Definice workflow
sestává z
Role
může se
vztahovat
Činnost
používá
Věcná data
worfklow
používá
může
mít
Vyvolaná
aplikace
Přechodové
podmínky
může se
vztahovat
3‐4: Meta‐model definice procesu [7] Definice workflow představuje jednoznačnou identifikace modelovaného procesu. Kromě názvu by měla nést informace o podmínkách zahájení nebo ukončení procesu a další řídící či jiná data s procesem související. Libovolný mapovaný proces tedy sestává z činností. Pod tímto pojmem si můžeme představit elementární úkon provádění manuálně nebo s podporou informačního systému. Činnosti mohou být spojeny 4 typy vazeb [7]: • sekvenční směrování, • větvení, • paralelní směrování, • opakování činnosti. Přechod mezi činnostmi je vždy realizován na základě splnění určitých předpokladů. V zásadě existují 4 základní typy přechodových podmínek [7]: 14 • lhůta, • vstupní podmínka, • výstupní podmínka, • přechodová podmínka. Účastníci workflow mají přiřazeny role, které definují, jakou pozici zastávají v rámci procesu, za které činnosti jsou zodpovědné apod. Metamodel definice procesu dále hovoří i o stavech procesů, jednotlivých činnostech a dalších oblastech souvisejících s problematikou modelování a definice procesu. Některé z těchto oblastí jsou řešeny dále v rámci části zaměřené na referenční model. Cílem této práce je poskytnou čtenáři náhled do celé problematiky, proto nyní téma definice opustíme a přesuneme se k dalším principům workflow. Monitoring Možnost sledování průběhu jednotlivých procesů, vytížení zdrojů představuje velice cenný interní informační zdroj podniku, který je zpravidla využíván zejména managementem. Monitorovací nástroje by měli poskytovat především možnost sledovat stav podnikových procesů, vytížení zdrojů, seznam úkolů. Toto hodnocení by mělo být možné nejen z pohledu aktuálního stavu, ale také s určitým historickým rámcem, který by např. umožnil manažerům sledovat průměrné vytížení jednotlivých pracovníků a vhodně reorganizovat své zdroje tak, aby bylo dosaženo maximální výkonnosti podniku. V rámci monitoringu by měli i ostatní uživatelé workflow systému mít možnost sledovat seznam svých úkolů a jejich stav. Notifikace a eskalace V okamžiku vzniku určité instance procesu se dá předpokládat, že proces ke svému ukončení bude vyžadovat vykonání určité činnosti od účastníka workflow. Notifikace představuje přenesení odpovídajícího úkolu přímo na konkrétního účastníka, resp. informování účastníka o zadaném úkolu. Způsob realizace může být různý. Rozlišujeme mezi aktivními a pasivními systémy, základní myšlenkou je přenos úkolu na účastníka. Zatímco v aktivních systémech je účastníkovi workflow přidělen úkol a zasláno oznámení. Pasivní systémy realizují tuto činnost prostřednictvím seznamu úkolů, ze kterého si uživatel sám volí činnosti, které provede. U notifikačních principů, můžeme hovořit ještě o problematice eskalace. Eskalace představuje reakci systému na specifické události. Zpravidla se jedná o situaci, když účastník workflow nepotvrdí přijetí či splnění úkolu v zadané lhůtě nebo dle určitých vnořených pravidel. V takovém případě reaguje workflow systém předem definovaným způsobem, chybovým hlášením, informační zprávou pro řídící pracovníky nebo delegováním úlohy jinému zaměstnanci. 15 3.3.4 Referenční model workflow Význam referenčního modelu Automatizace podnikových procesů je poměrně komplexní činností, která vyžaduje porozumění jak na straně managementu, zaměstnanců podniku, tak i na straně informatiků provádějící implementaci systému řízení workflow a mapování podnikových procesů. Zavádění workflow může dále komplikovat i skutečnost, že každá organizace může využít poněkud odlišnou terminologii pro popis svých procesů, dílčích činností, podnikových zdrojů apod. Klíčové procesy daného podniku jsou často unikátní, liší se svou strukturou, významem, využívanými zdroji či skladbou jednotlivých aktivit nebo procedurálními pravidly řízení. Další problémovou oblastí je komponentová architektura workflow systémů a snaha o zajištění vzájemné spolupráce odlišných systémů. Referenční model a terminologický slovník jsou snahou Workflow Management Coalition o sjednocení názvosloví workflow a vytvoření prostoru pro standardizaci. Cílem je zajištění vzájemného porozumění, odstranění problému komunikace mezi všemi stranami v rámci implementace WfMS. Referenční model by měl dále nabízet výchozí bod pro návrh WfMS, který by zajistil kompatibilitu a umožnil integraci různých workflow aplikací. V rámci této části studie budou vymezeny základní pojmy a jejich vzájemné souvislosti a charakteristika referenčního modelu, tak jak je uvádí Workflow Management Coalition. Terminologie a vztahy Podnikový proces (Business process) lze vymezit jako množinu vzájemně provázaných činností, které jsou vázány na realizaci obchodních cílů, a jejichž podoba je často ovlivněna organizační strukturou [7]. Z pohledu workflow proces zachycuje způsob realizace transformace vstupů na výstupy, které slouží k uspokojení poptávky vyvolané současnými i potenciálními zákazníky daného podniku. Na úrovni workflow aplikací jsou procesy reprezentovány specifickým popisem, vytvořeným prostřednictvím dostupných modelovacích nástrojů. Definice (Process definition) přestavuje reprezentaci podnikového procesu v podobě, která je vhodná pro využití automatizovaného zpracování (modelování, provádění systémem řízení workflow). Definice procesů sestává ze sítě vzájemně propojených činností, indikátorů zahájení a ukončení procesu, dále také informací o dílčích činnostech, jako jsou účastníci, aplikace, data atd. [9] Jednotlivé definice sestávají z celé řady provázaných elementárních prvků, které označujeme jako činnosti. Činností (Activities) rozumíme jeden logický krok v rámci celého procesu. Činnosti můžeme rozdělit na manuální a automatizované, jinými slovy jedná se o aktivitu vyžadující pro vykonání alokování lidského resp. informačního zdroje [9]. Definice nezachycuje reálně běžící proces, představuje pouze jeho model, který je využíván při realizaci daného procesu. Konkrétní výskyt procesu nebo aktivity označujeme jako 16 instanci (Process/activity instance) [9]. To v praxi znamená, že v rámci jedné definice procesu může v libovolný okamžik probíhat souběžně několik procesů a k nim příslušných aktivit. Již víme, že proces se skládá z elementárních činností. Z podstaty jednotlivých aktivit je zřejmé, že ke své realizaci vyžadují určité zdroje. V této souvislosti hovoříme o účastníkovi workflow. Účastníkem (Workflow participant) rozumíme zpravidla pracovníka (lidský zdroj), aplikaci nebo určitou funkcionalitu informačního systému (počítačový zdroj), které mají přiřazenu určitou činnost, resp. její instanci. Práci vykonávanou zdrojem můžeme definovat jako úkol zpracovávaný účastníkem a přiřazený přes seznam úkolů [9]. Úkol, resp. pracovní položka (Work Item) je reprezentací úlohy zpracovávané jedním z účastníků workflow ve vazbě na konkrétní činnost a instanci procesu [9]. Seznam úkolů (Worklist) je pak soupisem pracovních položek přidělených jednomu účastníkovi. 3‐5: Vazby v rámci terminologie workflow [9]
Vztah mezi procesem, jeho instancí a úkoly Jak již víme, definice představuje abstrakci procesu vhodnou pro automatizované zpracování. Při řešení konkrétního obchodního případu je na základě definice vytvořena instance procesu, z toho vyplývá, že v určitém okamžiku může v organizaci probíhat celá řada instancí jednoho procesu. Úkoly v zásadě reprezentují jednotlivé atomické činnosti, ze kterých je proces složen. Při řešení byznys případů, tak v organizaci vzniká celá řada souběžně 17 zpracovávaných úkolů, které jsou prostřednictvím seznamu pracovních položek přidělovány jednotlivým zaměstnancům. 3‐6: Vztah mezi definicí procesu, jeho instancí a úkoly [9] Referenční model a rozhraní Řídící služby workflow (Workflow Enactment Service, WES) můžeme v podstatě charakterizovat jako běhové prostředí pro worfklow. Dle WMC sestává z jednoho nebo více výkonných jader, skrze které vytváří a koordinuje jednotlivé instance workflow [8]. Součástí, nebo spíše nástavbou WES je programové rozhraní (Workflow application programming interface, WAPI), které zprostředkovává komunikaci mezi řídící službou a ostatními aplikacemi. Výkonné jádro workflow (Workflow Engine) představuje komponentu zodpovědnou za kontrolu a řízení běhové prostředí. "Výkonné jádro zajišťuje zpracování výskytů procesu na základě definice procesu. Dokáže interpretovat definici procesu, řídí a zpracování výskytů procesu včetně jejich spuštění, zastavení, přerušení atp." [7] Mezi výkonným jádrem a dalšími aplikacemi tedy existuje WAPI, které vytváří jednotný komunikační kanál s cílem zajistit standardizaci a vzájemnou interoperabilitu nesourodých komponent. WAPI existuje v podobě 5 rozhraní, z nichž každé zajišťuje přístup ke specifické funkcionalitě. Rozhraní 1 (Interface 1) propojuje WES s nástroji pro definici a modelování procesu. Dle [7] je vlastně linií, která jednoznačně separuje oblast návrhu od vlastního průběhu procesu. Hlavním přínosem tohoto rozhraní je nezávislost workflow nástroje na použitém 18 modelovacím nástroji. Díky standardizaci v této oblasti je tak možné přenášet definici procesu mezi různými workflow systémy nebo jejich komponentami, bez nutnosti provádění dílčích úprav. Rozhraní 2 (Interface 2) napojuje do architektury workflow systému klientské aplikace. Klíčovou oblastí, kterou toto rozhraní řeší, je zajištění komunikace mezi workflow a účastníky procesu, díky tomu musí podporovat celou komunikačních standardů od emailové komunikace, přes vzdálená volání až po sdílení souborů. Spolupráce mezi workflow a vyvolanými aplikacemi je předmětem rozhraní 3 (interface 3). Externích aplikací vázaných na systémy workflow je celá řada. Míra standardizace, která by zajistila přímou spustitelnost aplikace prostřednictvím WAPI, je zřejmě nereálná. Aplikace lze aplikace rozlišit do dvou skupin [8]: • aplikace přímo spolupracující s WfMS, • aplikace spustitelné prostřednictvím aplikačního agenta. Aplikační agent v tomto případě reprezentuje službu, transformační místo, které zajišťuje průběh komunikace mezi aplikací a workflow. Rozhraní 4 (Interface 4) vytváří komunikační kanál mezi řídícími službami workflow v případech, kdy je nutné zajistit jejich vzájemnou spolupráci. Rozhraní 5 (Interface 5) zajišťuje komunikaci mezi administrativními nástroji a řídící službou. Jedná se o komponenty odpovědné za správu uživatelů, rolí, řízení zdrojů, sledování apod. 3‐7: Referenční model workflow [8] 19 3.3.5 Přínosy workflow Automatizace podnikových procesů má celou řadu pozitivních přínosů, např. zrychlení vykonávání činností pomocí systému oběhu dokumentů, zavedení standardních postupů a zvýšení efektivity práce nebo uchování určitých znalostí o procesech v systému. Nicméně správně implementované workflow by měl umožňovat více než ponechat provádění určitých činností na informačním systému nebo rychlé a efektivní sdílení dokumentů. Měl by umožnit manažerům prostřednictvím analytických nástrojů průběžně sledovat a vyhodnocovat aktuální stav podniku. Tím by měl výrazně přispět ke schopnosti řídících pracovníků reagovat na změny v ekonomickém prostředí, ve které společnosti pohybují. Zavedení konceptu řízení pracovních toků může přinášet podniku celou řadu benefitů, nicméně je nutno si uvědomit, že přínosy nelze očekávat bezprostředně po přijetí konceptu workflow, ale až po implementaci příslušných nástrojů. Propojením workflow a CASE nástrojů může podnik realizovat celou řadu přínosů: •
Formalizace průběhu procesů, sjednocení procesů napříč organizační strukturou •
Automatizace procesů umožňuje vyšší efektivitu provádění, snížení nároků na podnikové zdroje, snížení nároků na administrativní a řídící činnost, zajišťuje potenciál pro růst objemu vykonané práce se stávajícími zdroji •
Uvolnění podnikových kapacit pro další činnosti •
Eliminace problémů souvisejících s oběhem dokumentů, snížení množství dokumentů předávaných v tištěné formě •
Jednoznačné rozlišení odpovědností, pravomocí, zrychlení a zprůhlednění rozhodovacích činností •
Kontrola a sledování stavu procesů jako celku, i v rámci řešení jednotlivých business případů, sledování výkonnosti a pracovního vytížení jednotlivých zaměstnanců Celkově lze říci, že adopce workflow a informačních nástrojů jeho podpory, spolu se zajištěním jejich těsné vazby na podnik, přináší podniku možnost efektivního provádění hlavních podnikových činností. Workflow ovšem není všelék pro podniky nacházející se v krizi z důvodu neefektivního řízení. Koncept workflow se orientuje spíše na problematiku jak účelně vykonávat činnosti v rámci jednotlivých procesů a jak zamezit chybám nebo eliminovat časové ztráty, např. z důvodu čekání na odpovídající dokumenty. 20 4 Nástroje pro řízení workflow ve firmě Hlavním východiskem pro výběr popisovaných produktů je studie společnosti Gartner z roku 2008 (viz obr. 4‐1), která identifikuje klíčové hráče na trhu ECM (Enterprise Content Management). V případě, že se společnost nachází v pravém horním kvadrantu, znamená to, že ve svém portfoliu má i komplexní řízení workflow. Při analýze historických prací jsme identifikovali několik produktů z tohoto kvadrantu, které již byly podrobně popsány. Avšak společnosti Microsoft se svým produktem Nintex, ECM a Open Text ještě nebyly zmiňovány. 4‐1: Gartner Magic Qadrant for ECM 2008 [22] 4.1 Nintex Workflow 2007 Nintex Workflow 2007 je výborný a velmi user‐friendly nástroj pro modelování workflow. Tento software není samostatný aplikační balík. Je to add on pro velmi často používaný Microsoft Sharepoint. Ačkoliv sám Sharepoint nabízí nástroj pro vytváření jednoduchých workflow (Sharepoint Designer), chybí mu mnoho užitečných funkcí. Ve verzi Sharepoint 2010 došlo, ke značnému zlepšení, ale stále nedosahuje kvalit NW 2007. Sharepoint také může využít Visual Studia, to je však zase příliš robustní řešní a není příliš vhodné. Nintex Workflow se pohybuje někde mezi těmito řešeními. Dává koncovým uživatelům možnosti Visual Studia, ale stále zachovává user‐friendly prostředí. 21 NW umožňuje organizacím vytvářet komplexní workflow procesy rychle a jednoduše. Není potřeba instalovat další klienty, vše se dá jednoduše vytvořit pomocí webového prohlížeče. Rozhraní trochu připomíná např. webovou verzi známého Outlooku [10]. NW umožňuje běžným zaměstnancům: • automatizovat business procesy, • sledovat průběh workflow v reálném čase, • vytvářet workflow v řádech hodin, • automatizovat administrativní úkony pro Sharepoint, • generovat různé reporty, • Workflow kreslit, ne programovat. Vývojářům NW umožňuje: • připojení k externím datům pomocí SQL, Web Services, LDAP, XML, • využívat Web Service API, • BizTalk integraci, • využívaní Active Directory. 4‐2: Nintex Framework [11] 22 4‐3: Nintex Workflow UI [10] Nintex podporuje drag‐and‐drop mezi menu a plochou designeru a umožňuje nastavit akce workflow pomocí dialogových boxů. 4‐4: Ukázka složitějšího workflow [10] 23 4.1.1 Šablony a Snippets Další často využívanou funkcionalitou je možnost tvořit šablony z existujících workflow. To velmi šetří čas, pokud vytváříte stále podobná workflow. Další možností pro znovu použití workflow jsou tzv. snippets. Snippet je zjednodušeně soubor workflow akcí, které jsou uloženy jako akce jediná. Například vytvoříte snippet, který upozorní vlastníka dokumentu, že v něm došlo ke změnám. Kdykoliv pak chcete tuto akci použít v jiném workflow, jednoduše přetáhnete snippet na plochu workflow designeru a nemusíte ji znovu vytvářet. 4.1.2 Sledování Workflow Pokud Sharepoint Designeru něco opravdu chybí, je to možnost sledovat a dokumentovat co se děje v probíhajícím workflow [10]. NW má velmi pěknou informační stránku. Na této stránce máte visuálně zobrazené workflow, kde je výborně vidět, které akce se právě vykonávají. Dále zobrazuje informace o délce trvání, schvalování akcí a další užitečné informace. 4‐5: Informační stránka NW 2007 [10] 24 4‐6: Workflow statistiky [10] V NW můžeme rozdělit workflow do dvou skupin. Na sekvenční workflow (krok za krokem) a tzv. state machine workflow. Sekvenční workflow je vlastně sekvence předdefinovaných kroků, kde můžeme využít podmínky na větvení workflow tasku, ale zjednodušeně to je pořád workflow z A do B. Sharepoint Designer zvládne pouze toto sekvenční workflow. State machine workflow je trochu složitější, ale zjednodušeně si ho můžeme představit jako soubor sekvenčních workflow. Každý stav v state m. workflow je pak oddělené sekvenční workflow. Tyto stavy pak můžou fungovat jako triggery (spouště pro další workflow). Na rozdíl od sekvenčního workflow, který musí jednou skončit, state machine workflow může teoreticky běžet pořád dokola. State machine workflow tak je nejlepší model pro workflow, které jakýmkoliv způsobem spolupracuje s lidmi [11]. 25 4‐7: State machine workflow [10] 4.2 Open Text – BPM Server Společnost Open Text, jakožto jeden z leaderů v oblasti poskytování ECM(Enterprise Content Managent) technologií, disponuje CASE nástroji na podporu workflow a správu podnikových procesů, používaných právě ve svých řešeních. Pro tyto účely slouží aplikační balík tzv. BPM Server, který s pomocí svých nativních komponent poskytuje požadovanou funkcionalitu od fáze analýzy, návrhu, implementace, administrace, automatizace, optimalizace či sledování procesů napříč společností, a tím zabezpečuje efektivní řízení podnikových procesů. BPM Server je systém na správu procesů. Tím pádem zjednodušuje, optimalizuje a urychluje pracovní procesy společnosti. Tyto benefity plynoucí z funkcionality BPM Serveru napomáhají tomu, že automatizace procesů pomocí IT se stává jednou z největších výzev současnosti. Zároveň tyto benefity způsobují zvýšení produktivity práce, zlepšení kvality procesů a poskytuje nebývalé možnosti snižování nákladů [16]. BPM Server dokáže totiž pracovat s milióny vstupních transakcí, s velkým objemem uživatelů a integrovat data z již existujících systémů společnosti (může se například jednat o ERP, CRM systémy nebo jiné tzv. legacy applications). V neposlední řade BPM Server respektuje standardy jakou je XML nebo WfMC (Workflow Management Coalition Interface), které mimo jiné zajišťují ochranu historických systémů a jejich kompatibilitu. Další z podstatných rysů BPM serveru je schopnost pružně reagovat na různé požadavky okolí a být s nimi v souladu (ať už se jedná o interní směrnice či externí nařízení obligatorního charakteru). 26 Součásti BPM Serveru: • Process Designer • BPM Web Process Manager • Process Service Jednotlivé části BPM Serveru jsou prezentována jako kompaktní řešení pro oblast workflow a BPM. Avšak pro různé potřeby konkrétních implementací mohou být, a také jsou, nasazeny pouze požadované komponenty. Například komponenta Process Service je součástí mnoha řešení Open Textu v širokém spektru ECM. Čistě pro potřeby DMS (Document Management System) existuje komponenta Extended Workflow, která pokrývá podobné spektrum potřeb jako BPM Server. Bývá ale spjata s méně komplexními řešeními, proto jí v této části práce nebude věnována taková pozornost. 4.2.1 Process Designer [17] Smyslem Process Designeru je schopnost rychle a efektivně implementovat procesy pomocí technologie. (Typické příklady procesů v pojetí Open Textu mohou být např.: zpracování příchozích faktur, schvalování žádostí, objednávky zboží atp.) V tomto nástroji, pomocí grafických elementů, uživatel definuje jednotlivé kroky tvorby procesu, přiřazuje k procesu relevantní data a určuje, v jakých informačních systémech společnosti se bude samotná transakce uskutečňovat. Na obrázku 4‐8 je možné vidět grafickou podobu procesu objednávky zboží. Je využito klasických „plaveckých drah“ pro definování aktérů daného procesu. Jsou zde také využity rozcestníky, místa notifikací, konce procesu a další logické spojky a schémata. 4‐8: Příklad zobrazení procesu v Process Designeru [17] 27 Avšak nejenom toto je nutné v Process Designeru stanovit. Je také nutné definovat data, která budou přenášena, jako jméno a e‐mail uživatelů, jména objednávaného zboží a jeho množství, atd. Data mohou být vyplněna ručně nebo, v lepším případě importována z jiných systémů společnosti. Dalším aspektem je uživatelské rozhraní formuláře, které představuje prostředí pro schvalování anebo odmítání požadavků. V neposlední řadě je to také prostředí, pod kterým proces je k nahlédnutí, tj. browser pro Internet (viz obrázek 4‐9). 4‐9: UI rozhraní pro Internet [17]
Uživatelské rozhraní Process Designeru Process Designer je poměrně přívětivá aplikace co do uživatelského rozhraní. Na obrázku 4‐
10 je ukázka obrazovky Designeru s jednotlivými klíčovými oblastmi. 1. Menu a různé nástrojové lišty, k rychlým a často používaným funkcím. 2. Workspace, pro znázornění organizační struktury společnosti ve stromové podobě a orientaci v projektu samotném. 3. Okno procesu, ve kterém uživatel graficky proces modeluje. 4. Globální pohled na proces pro lepší orientaci a rychlé přesuny z místa na místo. 5. Katalogy obsahující již nadefinované kroky prosesu (v různých grafických stylech). Tato oblast může významně urychlit pro zkušené uživatele samotné modelování. 6. Okno vlastností objeku, ve kterém se dají tyto atributy rychle editovat. 7. Okno zpráv, kde je prováděna jak sytaktická kontrola správnosti, tak i zobrazení všech upozornění , informací a chyb v definici procesu. 8. Statusová lišta, obsahující online/offline režim, nastavení procesní URL, informace o položce, na kterou ukáže kurzor myši a jiné doplňující informace. 28 4‐10: GUI Process Designeru [17] 4.2.2 BPM Web Process Manager [18] Tento modul je uživatelským klientem pro BPM Server Solution a mezi jeho hlavní funkce a přínosy především patří možnost měnit, editovat proces, prezentace formulářů ke koncovým uživatelům, možnost přidávání komentářů a příloh k procesům, změny v průběhu procesu co se týče konkrétních uživatelů (prohlížení cizích inboxů, přebírání rolí v rámci procesu, spojování uživatelů do pracovních skupin,…) a třeba i vytváření ad‐hoc procesů. Práce na konkrétním procesu může být zahájena několika možnými způsoby: 1. Iniciovat nový proces ze seznamu, který nabízí Web Process Manager. 2. Výběr a práce na procesu, který se nachází v inboxu konkrétního uživatele. 3. Příchodem notifikace, generované systémem nebo uživatelem vyšší úrovně, ve které je uživateli přidělen proces. Poté může začít samotná práce na tvorbě / editaci procesu pomocí následujících nástrojů: Seznamy procesů: slouží k řízení / editaci / tvorbě procesů pomocí následujících složek: • Inbox – zde je možné pro informaci vidět, které procesy byly nasměrovány na uživatele, od koho, jakou má proces prioritu a kdy je termín vyhotovení procesu. • Start Process – v této složce budou všechny třídy procesu, ke kterým má uživatel povolení spouštět proces. Je zde také detailní popis procesu. 29 • Draft – je možno práci na procesu pozastavit a rozdělaná práce se přesuje do této složky. Po odeslání draftu je složka automaticky vyprázdněna • Sent – seznam všech procesů odeslaných k dalšímu zpracování • Started – zobrazí výčet uživatelem vytvořených entit od začátku tvorby na procesu • Postponed – nastavení časového zpoždění pro práci na procesu, po vypršení časového limitu se proces automaticky převádí do složky inbox • Reports – seznam tříd, používaných jako reportovacího nástroje Formulář: Existence a funkcionalita formuláře přímo závisí na definici procesu. Rozdílné procesy zahrnují rozdílné formuláře, které se také liší v individuálních procesních krocích. Následující výčet funkcí je k dispozici na funkční liště a umožňuje práci s formulářem. Jedná se o funkce Forward, Save, Delete, Print, Group Assignment (pro případy, kdy je proces určen více uživatelům), Ad Hoc Workflow, Escalation (časová eskalace, tedy změna uživatele). Přílohy: Jsou to dokumenty, které jsou propojeny s procesem, takže následní uživatelé procesu mohou k dokumentům přistupovat. Jsou rozšířeny o metadata, která usnadňují orientaci a vyhledávání v nich. Je samozřejmě možno přílohy přidávat, mazat nebo modifikovat. Komentáře: Rozšiřují předávané množství informací ve workflow o komentáře, výhrady, připomínky, tipy a jiné informace, pro které neexistuje standardizované pole. Kontrola cesty procesu: V grafickém prostředí náhledu procesu je možné získat shrnutí sekvencí procesu, pomocí ikon a šipek. Následným krokem může být modifikace cesty procesu. Dále je možnost sledovat časový rozpis procesu a jeho dodržování, pracovat ve skupinách nebo zobrazit report (viz obr. 4‐11). Ten slouží ke zjištění, které procesy splňují předem zadaná filtrační kritéria. 4‐11: Report z Web Process Manageru – Web Report Builder [18] 30 V rámci managementu složek je možné také manuálně přesouvat procesy z vlastního inboxu do inboxu cizího nebo týmového. Toto je podporováno i u složek „Postponed“. 4.2.3 Process Service [19] Process Service je workflow engine, který kompletně zahrnuje vše od workflow spolupráce až po BPM (Business Process Management). Jelikož workflow potřebují velice často customizaci, měla by zde být možnost rozšířit již dané workflow scénáře o automatizované úkony. Program či modul, který umožňuje takovéto chování se nazývá, v terminologii Open Textu, „agent“. Právě Process Service nabízí framework, který umožňuje rychlou a lehkou možnost takovéto agenty vyvinout a nasadit. Pro snadnou integraci Agentů do již stávajících workflow či procesů je využíván výše popsaný Process Designer, kde je také možnost nastavení Agenta a jeho vlastností modifikovat. Když se proces dostane do fáze agenta, implementace vyvolá engine Agenta, aby agenta vykonal. V této chvíli se engine Agenta stará o celou transakci, její směrování, chybových hlášeních na všech položkách agenta (viz obr 4‐12, kde je načrtnuta část vykonání implementace Agenta a vypořádání se s chybovými hláškami). 4‐12: Spuštění agenta a příklady chybové hlášky [19] 31 Typy agentů: Synchronní vs. asynchronní – v případě asynchronních agentů je vždy agent spuštěn ze svého frameworku a proces muší čekat, než se činnost agenta provede. U synchronních agentů jsou tyto úkony v souběhu. Druhy agentů: • Script agents – zde existuje předdefinovaná implementace agenta, implementace může být použita k vykonání JavaScriptu v příkazu agenta. • EJB agents – interakci s enginem vykonává také předdefinovaný agent. EJB agent umožňuje volat metodu Stteless Session Bean v aplikačním serveru (viz dokumentace J2EE) • POJO (Plain Old Java Object) agents – je tou nejflexibilnější cestou k implementaci agenta. Žádné předdefinované implementace pro tohoto agenta neexistují. POJO agent musí splňovat IAgentMps rozhraní. (viz. balík ‘com.opentext.ecm.bpm.agent’) WQL (Workflow Query Language) Je jazyk vybudovaný na bázi XML pro Process Service. Jeho strukturu ji možné vidět na obr. 4‐13. WQL může být použito k definici příjemce nebo skupin příjemců konkrétních kroků procesu. 4‐13: Struktura WQL [20] PMQL (Process Management Query Language) Jazyk, podobně jako WQL, vybudovaný na základech XML. Je primárně určen k přístupu k datům Process Service. Je používán k reportování generací, sestavování customizovaných sofistikovaných pohledů na inboxy pro specifické aplikace. Umožňuje komplexní dotazovací operace, které jsou potřeba provádět přímo nad datovými úložišti. Obr.4‐14 4‐14: Struktura PMQL [21] 32 4.3 EMC Documentum Process Suite [12], [13], [14], [15] Aplikační balík společnosti EMC, Documentum Process Suite, je komplexní produkt zaměřený na správu podnikových procesů (Business Process Management – BPM). Svou funkcionalitou pokrývá celý životní cyklus podnikového procesu, jenž je tvořen několika fázemi (viz 4‐15): •
•
•
•
analýzou, modelováním a simulací procesu; implementací procesu; provozem (prováděním) procesu; monitorováním a vyhodnocováním procesu. 4‐15: Životní cyklus podnikového procesu [12] Každá z dílčích fází životního cyklu podnikového procesu představuje řadu odlišných činností prováděných různými pracovníky. Jednotlivé fáze jsou podporovány různými aplikačními komponentami, které se specializují právě na činnosti v dané oblasti [13]: Analýza • EMC Documentum Process Analyzer • EMC Documentum Process Simulator • EMC Documentum Process Navigator Implementace • EMC Documentum Process Builder • EMC Documentum Forms Builder Provoz • EMC Documentum Process Engine • EMC Documentum Process Integrator • EMC Documentum TaskSpace 33 Monitorování • EMC Documentum Business Activity Monitor 4.3.1 EMC Documentum Process Analyzer Process Analyzer je aplikační nástroj pro analýzu a modelování podnikových procesů. Jeho grafické prostředí je navrženo takovým způsobem, aby umožňovalo práci netechnicky orientovaným pracovníkům (tj. business pracovníkům) – procesy jsou jednoduše „namalovány“ (metodou drag‐and‐drop) s využitím předdefinovaných grafických objektů (příklad diagramu zobrazeného s využitím tzv. „plaveckých drah“ viz 4‐16). Procesní diagramy jsou však uchovávány nikoliv jako grafické symboly, ale jako data v relační databázi, což umožňuje mnohem sofistikovanější způsoby zpracování. Podporovány jsou jazyky BPEL a XPDL. 4‐16: Příklad zobrazení procesního diagramu [13] 4‐17: Příklad reportu z nástroje Process Analyzer [13] 34 V případě změny některé komponenty uvnitř procesu se dynamicky přepisují všechny touto změnou dotčené části. Nástroj rovněž umožňuje uchovávat daný proces zároveň v mnoha různých verzích, definovat hierarchické struktury mezi jednotlivými procesy a tímto způsobem je propojovat a dávat do vzájemných vazeb. Analytik může u každého procesu nadefinovat klíčové atributy, které budou u procesu sledovány, nebo na základě jakých bude proces analyzován (např. náklady, čas nezbytný k provedení, míra automatizace, atd.). Analytická část této aplikace dává prostor pro tvorbu různých reportů na základě informací, které jsou o daném procesu k dispozici. Definované procesy je možné porovnávat na základě jejich atributů (náklady, čas, vztahy mezi aktéry procesu, atd.) – příklad vygenerovaného reportu (podíl aktérů v jednotlivých činnostech procesu) je možné vidět na obr. 4‐17. Další možností je generování procesních map nebo nahlížení na procesy z různých úhlů pohledu (multidimenzionální přístup). Process Analyzer je primárně určen k použití spolu s dalšími aplikacemi z rodiny Documentum, avšak je možné ho využívat i jako samostatný modelovací nástroj. 4.3.2 EMC Documentum Process Simulator Process Simulator je aplikací přímo napojenou na Process Analyzer. Jejím účelem je simulace různých scénářů na daném procesu za účelem prozkoumání jeho chování při různých úrovních zatížení a identifikace úzkých míst a případných omezení (tj. otestování procesu z hlediska kvantitativního). Tento nástroj nám i umožňuje porovnávat výsledky simulací různých verzí téhož procesu, což v praxi znamená např. otestování navrhované optimalizace procesu před jejím uvedením do produkčního prostředí. 4‐18: Ukázka simulace procesu [13] 35 4.3.3 EMC Documentum Process Navigator Process Navigator je aplikační rozhraní k nástroji Process Analyzer, které poskytuje přístup k modelovaným procesům prostřednictvím webového prohlížeče v režimu read‐only. Účelem je poskytnout informace o modelovaných procesech také osobám, které jsou v těchto procesech zainteresováni, respektive dotčeni případnými změnami (tzv. stakeholders), a především poskytnout těmto osobám možnost podat zpětnou vazbu již v této fázi, tj. před zavedením změn do produkčního prostředí. 4.3.4 EMC Documentum Process Builder Process Builder je vývojová platforma, na které se procesy namodelované na úrovni businessu v Process Analyzeru doplňují o technické podrobnosti (např. mapují se datové zdroje) a implementují do produkčního prostředí. Nástroj disponuje propracovaným grafickým prostředím (viz obr. 4‐19) a širokou základnou různých šablon pro dílčí předem definované činnosti. Šablony je možné upravovat nebo vytvářet vlastní tak, aby bylo do maximální míry zajištěno využití principu znovupoužitelnosti. V ideálním případě se proces implementace obejde bez programování – vše se pouze „nakliká“. Smyslem tak robustního nástroje je snaha o co možná největší zjednodušení a tedy i zrychlení implementační fáze. 4‐19: Ukázka GUI nástroje Process Builder [13] 36 4.3.5 EMC Documentum Forms Builder Forms Builder je nástroj úzce napojený na Process Builder určený k tvorbě uživatelského rozhraní. S jeho pomocí lze navrhovat elektronické formuláře (např. přístupné skrze webový prohlížeč) nebo celé grafické rozhraní do aplikace TaskSpace (viz dále). Podobně jako u Process Builderu se jedná o „naklikávací“ aplikaci disponující databází šablon za účelem dosažení co nejkratšího času vývoje a co největší znuvupoužitelnosti (vizír. 4‐20). Forms Builder je kompatibilní se standardem W3C XForms a využívá technologie AJAX. 4‐20: Ukázka GUI nástroje Forms Builder [13] 4.3.6 EMC Documentum Process Engine Právě aplikace Process Engine je jádrem celého BPM systému společnosti EMC. Vykonává, koordinuje a řídí instance nadefinovaných podnikových procesů, vyhodnocuje k nim přiřazená business pravidla a přiděluje požadavky příslušným jiným systémům, skupinám pracovníků nebo konkrétním osobám. Účelem je zajistit, aby každý požadavek na provedení dané činnosti byl přiřazen ve správný čas správné entitě (jiné aplikaci nebo člověku). Process Engine se rovněž stará, aby byly u jednotlivých požadavků dodrženy potřebné termíny, případně provádí nadefinované notifikace a eskalace. 37 Process Engine také slouží jako spojovací most mezi podnikovými procesy a daty (Documentum Process Engine je těsně integrován s aplikacemi obstarávající správu podnikových dat – např. Documentum Content Server) a právě přes něj přistupují uživatelé vykonávající daný workflow k příslušným datům. Aplikace rovněž zaznamenává údaje o prováděných procesech, které předává k vyhodnocení Business Activity Monitoru (viz dále). 4.3.7 EMC Documentum Process Integrator Process Integrator tvoří integrační vrstvu mezi Documentum Process Engine, respektive aplikacemi z rodiny Documentum, a mezi ostatními systémy, datovými zdroji, lidmi. Tato aplikace využívá servisně orientované architektury (SOA) a podporuje celou řadu komunikačních protokolů s externími entitami (např. HTTP/S, XML/SOAP, SMTP, atd.) – tedy včetně možnosti e‐mailové komunikace s uživateli vně organizace (viz obr. 4‐21). 4‐21: Process Integrator [13] 4.3.8 EMC Documentum TaskSpace TaskSpace je aplikace sloužící jako uživatelské rozhraní pro nástroje Documentum BPM. Její specialitou je možnost velké customizace uživatelského rozhraní (např. skrze návrhy z aplikace Forms Builder) – umožňuje specifikovat rozdílné uživatelské rozhraní v závislosti na momentálně prováděné činnosti nebo roli daného uživatele. Rovněž je možné zároveň zobrazovat informace z různých datových zdrojů (viz obr 4‐22). Tento nástroj je určen zejména na použití v rámci workflow, tj. pro uživatele, kteří musí zvládnout velké množství podobných opakujících se činností anebo pracují s velkým množstvím dokumentů ve velkých úložištích (repository). 38 4‐22: Ukázka použití TaskSpace [13] 4.3.9 EMC Documentum Business Activity Monitor Business Activity Monitor je nástroj, který slouží ke sledování a analyzování procesů na operační úrovni. Zdrojem dat je aplikace Process Engine, ze které jsou potřebné informace extrahovány v intervalech řádově jednotek až desítek vteřin. Informace jsou prezentovány v grafickém prostředí formou „kokpitu“ (viz obr. 4‐23), které je možné customizovat na základě sledovaných klíčových atributů daných procesů (definovaných v Process Analyzeru). V případě detekce nežádoucího stavu aplikace vyhodnocuje alerty, které se jednak promítají v GUI a jednak může být zároveň rozeslána notifikace např. prostřednictvím e‐mailu. Data za delší období z Business Activity Monitoru mohou být zároveň podkladem pro simulace a analýzy v Process Analyzeru. 39 4‐23: BAM „kokpit“ [13] 4.3.10 Documentum Process Suite a platforma Documentum Aplikační balík Documentum Process Suite tvoří pouze malou část komplexního řešení pro správu podnikového obsahu (Enterprise Content Management – ECM) Documentum od společnosti EMC, které v sobě zahrnuje nástroje a aplikace pro zajištění repository funkcí, včetně zabezpečení, archivace a mnoho dalších (viz obrázek 5‐24). 4‐24: ECM Documentum [13] 40 5 Závěr V první části práce bylo popsáno základní vymezení problematiky CASE nástrojů pro workflow, workflow jako samotné a významné standardy, které tuto oblast postihují či jsou jejím východiskem. Úvodní část, jako teoretický základ je pro potřeby naší práce dostatečný. V druhé, praktické části naší práce, jsme se zaměřily na dosud nepopsané nástroje. Produkt Nintex je velice úzce spjat s technologií Microsoftu, ale při trendu expanze této společnosti do oblasti workflow a s tím souvisejících technologií, jeho význam poroste. Dále jsme popsali dva významné konkurenty v oblasti komplexních ECM řešení, kde jak společnost ECM, tak Open Text představují celosvětové leadery. Velmi zajímavé je porovnání těchto produktů, jelikož se příliš neliší ve svých funkcích, pouze v rozdílné interpretaci a technologickém pojetí. Tato část práce představuje přidanou hodnotu oproti pracím minulým. 41 6 Zdroje [1] Dokumenty z minulých etap: Použití CASE/CABE pro řízení workflow ve firmě [online]. URL: http://www.panrepa.org/CASE/ [2] Dokumenty z minulých etap: Přehled nástrojů CASE na tuzemském trhu [online]. URL: http://www.panrepa.org/CASE/ [3] Oracle: BPMN 2.0 Hits a Major Milestone [online]. URL: http://blogs.oracle.com/bpm/2009/07/bpmn_20_hits_a_major_milestone_1.html [4] Workflow Management Coalition: ASAP / Wf‐XML: Workflow Runtime Integration [online]. URL: http://www.xpdl.org/nugen/p/wf‐xml/public.htm [5] Cover Pages: XML‐Based Workflow and Process Management Standards: XPDL, Wf‐XML [online]. URL: http://xml.coverpages.org/wf‐xml.html [6] Swenson K.D.: The BPMN‐XPDL‐BPEL value chain [online]. URL: http://kswenson.wordpress.com/2006/05/26/bpmn‐xpdl‐and‐bpel/ [7] Carda, A., Kunstová, R.: Workflow: Řízení firemních procesů, Praha, 2004, Grada Publishing, ISBN 80‐247‐0200‐2 [8] Hollingswort, D.: Workflow Management Coalition: Workflow ref. model, Winchester: WMC, 1995 [9] Workflow Management Coalition: Terminology & Glossary, Winchester: WMC, 1999 [10] Furuknap, Bjørn Christoffer Thorsmæhlum. Sharepoint magazine. http://sharepointmagazine.net/products/review‐workflows‐with‐nintex‐workflow‐2007. [11] Understanding sharepoint journal. http://www.understandingsharepoint.com/ [12] EMC Documentum Process Suite: Data Sheet [online]. URL: http://czech.emc.com/products/detail/software/process‐suite.htm [13] EMC Documentum Process Suite: A Detailed Review (2008) [online]. URL: http://czech.emc.com/products/detail/software/process‐suite.htm [14] The BPMS Report: EMC Documentum Process Suite 6.0 (2008, Bruce Silver – BPMS Watch) [online]. URL: http://info.emc.com/mk/get/15633_LAND_RL [15] The Forrester WaveTM: Business Process Management For Document Processes, Q3 2007 [online]. URL: http://czech.emc.com/products/detail/software/process‐suite.htm [16] Produktové informace z webu OpenText [online], cit. 10. 12. 2009, URL: http://www.opentext.com/2/global/sol‐products/sol‐pro‐business‐process‐management/pro‐ll‐bpm‐
server.htm [17] Open Text Process Designer 10.0.1, DMS spol. OpenText, nedostupné online bez platné registrace, 2009, URL: https://knowledge.opentext.com/knowledge/llisapi.dll/fetch/2001/3551166/14399616/15271672/1
5252881/Open_Text_Process_Designer_10.0.1_Customizing_Guide.pdf?nodeid=15640526&vernum
=‐2 42 [18] Open Text BPM Web Process Manager 10.0.1, DMS spol. OpenText, nedostupné online bez platné registrace, 2009, URL: https://knowledge.opentext.com/knowledge/llisapi.dll/fetch/2001/3551166/14399616/15271672/1
5252881/Open_Text_BPM_Web_Process_Manager_10.0.1_User_Guide.pdf?nodeid=15640742&ver
num=‐2 [19] Open Text Process Service 10.0.1 Agent Framework, DMS spol. OpenText, nedostupné online bez platné registrace, 2009, URL: https://knowledge.opentext.com/knowledge/llisapi.dll/fetch/2001/3551166/14399616/15271672/1
5252881/Open_Text_Process_Service_10.0.1_Agent_Framework.pdf?nodeid=15649872&vernum=‐2 [20] Open Text Enterprise Process Services 10.0.1 WQL , DMS spol. OpenText, nedostupné online bez platné registrace, 2009, URL: https://knowledge.opentext.com/knowledge/llisapi.dll/fetch/2001/3551166/14399616/15271672/1
5252881/Open_Text_Enterprise_Process_Services_10.0.1_WQL_‐
_Workflow_Query_Language.pdf?nodeid=15649871&vernum=‐2 [21] Open Text Enterprise Process Services 10.0.1 PMQL , DMS spol. OpenText, nedostupné online bez platné registrace, 2009, URL: https://knowledge.opentext.com/knowledge/llisapi.dll/fetch/2001/3551166/14399616/15271672/1
5252881/Open_Text_Enterprise_Process_Services_10.0.1_PMQL_‐
_Process_Management_Query_Language.pdf?nodeid=15649331&vernum=‐2 [22] Gartner Magic Quadrant for ECM 2008. [online], cit. 26. 11. 2009, URL: ftp://ftp.software.ibm.com/software/uk/itsolutions/information‐management/information‐
foundation/enterprise‐content‐management/magic‐quadrant‐for‐ecm_gartner‐2008.pdf 43