CABE PRO ŘÍZENÍ WORKFLOW VE FIRMĚ (VAZBA NA NÁSTROJE WORKFLOW, TRENDY A MOŽNOSTI)

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