Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

download Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

of 321

Transcript of Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    1/321

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    2/321

    2007 BPMand

    WorkflowHandbook

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    3/321

    Future Strategies Inc.

    This book is published in digital format. The content of this book is fully copyrighted and maynot be distributed or data extracted therefrom without written permission by the publisher.

    You are licensed to print one copy for your own use.

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    4/321

    2007 BPM and

    Workflow HandbookMethods, Concepts, Case Studies and Standardsin Business Process Management and Workflow

    Published in association with theWorkflow Management Coalition

    Edited by

    Layna Fischer

    Future Strategies Inc., Book Division

    Lighthouse Point, Florida

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    5/321

    2007 BPM and Workflow Handbook

    Copyright 2007 by Future Strategies Inc.

    ISBN-13: 978-0-9777527-1-3

    ISBN-10: 0-9777527-1-2

    09 08 07 7 8 9

    All brand names and product names mentioned in this book are trademarks or service marks oftheir respective companies. Any omission or misuse should not be regarded as intent to infringeon the property of others. The Publisher recognizes and respects all marks used by companies,manufacturers and developers as a means to distinguish their products. The WfMC logo andWorkflow Management Coalition are service marks of the Workflow Management Coalition,www.wfmc.org.

    Neither the editor, Workflow Management Coalition, nor Future Strategies Inc., accept anyresponsibility or liability for loss or damage occasioned to any person or property through usingthe material, instructions, methods, or ideas contained herein, or acting or refraining fromacting as a result of such use. The authors and the publisher expressly disclaim all implied

    warrantees, including merchantability or fitness for any particular purpose. There will be noduty on the authors or Publisher to correct any errors or defects in the software.

    Published by Future Strategies Inc., Book Division

    2436 North Federal Highway #374Lighthouse Point FL 33064 USA954.782.3376 fax 954.782.6365www.futstrat.com; [email protected]

    Cover design by Pearl & Associates

    All rights reserved. Manufactured in the United States of America. No part of this

    work covered by the copyright hereon may be reproduced or used in any form or byany meansgraphic, electronic, or mechanical, including photocopying, recording,taping, or information storage and retrieval systemswithout written permission ofthe publisher, except in the case of brief quotations embodied in critical articles andreviews.

    Publishers Cataloging-in-Publication Data

    Library of Congress Catalog Card No. 2007901191

    2007 BPM and Workflow Handbook:/Layna Fischer (editor)

    p. cm.

    Includes bibliographical references, appendices and index.

    ISBN 978-0-9777527-1-3

    1. Business Process Management. 2. Workflow Management.3. Technological Innovation. 4. Information Technology. 5. Total QualityManagement. 6. Organizational Change 7. Management Information Systems. 8.Office Practice Automation. 9. Business Process Technology. 10. ElectronicCommerce. 11. Process Analysis

    Fischer, Layna

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    6/321

    TABLE OF CONTENTS

    FOREWORD 7Jon Pyke, Chair WfMC, United Kingdom

    INTRODUCTION:WORKFLOW AND BPMIN 2007:BUSINESS PROCESS STANDARDS SEE A NEW

    GLOBAL IMPERATIVE 9Nathaniel Palmer, Executive Director, Workflow Management Coalition,United States

    SECTION1-THEBUSINESSVALUEOFWORKFLOWANDBPM

    THEBUSINESS VALUE OFWORKFLOW AND BPM 17Keith D Swenson, Fujitsu Computer Systems, United States

    KNOWLEDGE INTENSIVE BPM 27Jon Pyke, The Process Factory Ltd., United Kingdom

    BPMAND SERVICE-ORIENTEDARCHITECTURE TEAMED TOGETHER:APATHWAY TOSUCCESS FORANAGILE GOVERNMENT 33

    Linus Chow and Charles Medley, BEA Systems; Clay Richardson, ProjectPerformance Corp., USA

    ANALYZING AND IMPROVING CORE TELECOM BUSINESS PROCESSES:CASE STUDY 55Lee, Kyeong Eon; KTF Co., Ltd., Seoul, Korea

    WORKFLOW AND PERFORMANCE MANAGEMENT 67Arnaud Bezancon, Advantys, France

    BPMCENTER OF EXCELLENCE MANIFESTO 73

    Dr. Setrag Khoshafian, Pegasystems Inc., USA

    EVOLUTION:AN INNOVATION PROCESS 85Gabriel Franciosi and Federico Silva, Pectra Inc., USA

    WHYENGAGEMENTWILL REDEFINE THE NEXT EVOLUTION IN WORKFLOW AND BPM 97Steve Rotter, Adobe Systems Incorporated, USA

    APPLYING MDACONCEPTS TO BUSINESS PROCESS MANAGEMENT 103Alexander Petzmann, Michael Puncochar, BOC Group, Austria; ChristianKuplich, BOC Group, Germany; David Orensanz, BOC Group, Spain

    FROM FUNCTIONAL SILOS TO A PROCESS VISION 117Salvatore Latronico and Francesco Battista, openwork, Italy

    SPOTLIGHTONBPMINHEALTHCARE

    THECHESTER COUNTY HOSPITAL:CASESTUDY 133Ray Hess, The Chester County Hospital, USA

    BUSINESS PROCESS MANAGEMENT INPHARMACEUTICAL R&D 147Dr. Kai A. Simon ALTANA Pharma AGa Nycomed company, Germany

    WORKFLOW OPPORTUNITIES AND CHALLENGES IN HEALTHCARE 157

    Jonathan Emanuele and Laura Koetter, Siemens Medical Solutions USA,Inc., USA

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    7/321

    TABLE OF CONTENTS

    AUTHENTICATED DOCUMENT/DATA EXCHANGE IN HEALTHCARE 167Dr. Mohammed Shaikh, Image X Inc., USA

    SECTION2STANDARDSANDTECHNOLOGY

    QUALITY METRICS FOR BUSINESS PROCESS MODELS 179Irene Vanderfeesten,Hajo A. Reijers, Wil van der Aalst, TechnischeUniversiteit Eindhoven, The Netherlands; Jorge Cardoso, University ofMadeira, Portugal; Jan Mendling, Vienna University of Economics andBusiness, Austria.

    ENTERPRISEARCHITECTURE AS A META-PROCESS 191Heinz Lienhard, ivyTeam-SORECOGroup, Switzerland

    OVERCOMING NEGATIVE TENDENCIES INAUTOMATED BUSINESS PROCESSES 203Juan J. Moreno, Lithium Software / Universidad Catlica, Uruguay; Luis

    Joyanes, Universidad Pontificia de Salamanca, SpainDEFINING EASYBUSINESS RULES FORACCOMPLISHING THE BASEL IIRISK HANDLINGINBANKS 211

    Dr. Juan J. Trilles, AuraPortal BPMS, Spain

    MSCWV:CYCLIC WORKFLOW VERIFICATIONALGORITHM FOR WORKFLOW GRAPHS 223Sinnakkrishnan Perumal and Ambuj Mahanti, Indian Institute ofManagement Calcutta, India

    BUSINESS PROCESSARCHITECTURE AND THE WORKFLOW REFERENCE MODEL 243Chris Lawrence, Old Mutual, South Africa

    SECTION3DIRECTORIESANDAPPENDICES

    Membership Structure 283

    Officers and Fellows 287

    Membership Directory 291

    Author Biographies 301

    Additional Resources 313

    Index 315

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    8/321

    7

    Foreword

    Jon Pyke, WfMC Chair, United Kingdom

    Thank you for continuing to support the work of the Workflow ManagementCoalition. It never ceases to amaze me just how much can change and theprogress that can be made in a 12-month period.

    2006 was a year of momentous change for Workflow Management Coalition.Layna Fischer, WfMC General Manager and Executive Director for many

    years, announced her semi-retirement in order to re-focus on the publishingaspect of her business. Part of that process meant that, after many years ofservice and support, Layna would step down from her role as General Man-ager. On behalf on the entire Coalition, I would like to thank Layna for allher efforts and hard work and we wish her well. Layna is not disappearing

    completely though, she will continue to support us in many ways includingthe editing and publishing of the annual Handbook and other publications,as well as continue to manage the annual Global Excellence Awards.

    Laynas decision did mean that we had to find another, equally enthusiastic,individual to manage our affairs. I am very pleased that another lifelongsupporter of the Coalition, Nathaniel Palmer, stepped up to the plate to takeover. Many of us in the WfMC worked with Nathaniel during his time withthe Delphi Group where he was lead analyst in this sector. Id like to takethis opportunity to welcome Nathaniel to the fold. He has many excitingideas and we look forward to working with him. Be sure to read his introduc-tory chapter on Workflow and BPM in 2007.

    I think it is also appropriate to mention the untimely death this past year ofDave Shorter. Dave was the driving force behind the Coalition as the found-ing Chair. His determination and sheer hard work brought the group intoexistence and made the Coalition what it is. He will be sorely missed.

    But what of the Coalition in 2006?

    We have made significant progress during the past year, which was filledwith great events, lots of changes and exciting new developments. XPDL hasbeen a great success and has really bought the message home on the impor-tance of this particular standard. During the year we ran technical andbusiness seminars throughout the world including Japan, USA and the UK.

    WfMC members spent many hours over 2006 helping to drive awareness,understanding and adoption of XPDL. As a result, it has been cited as themost deployed BPM standard by a number of industry analysts, and contin-ues to receive a growing amount of media attention. More seminars and we-binars are planned for 2007, so keep an eye on www.wfmc.org for furtherannouncements.

    The relevance of the WfMC in 2007 and beyond:

    We have seen a shift in thinking throughout the industry during 2006,which has resulted in much less confusion as to what Business ProcessManagement (BPM) really is and the job its there to do. Many of us involvedin the field of Workflow Automation and BPM have argued long and hardabout where these two technologies overlap, where they are different, which

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    9/321

    FOREWORD

    8

    mathematical models to use, which standards are applicable to which part ofthe technology stack and all that associated puff.

    Well, these arguments and discussions are over; the demarcation lines havebeen drawn; the road ahead is clear.

    The fact that Business Process Management has its roots in Workflow tech-nology is well knownmany of todays leading products are, in fact, evolu-tions of the original forms-processing packages. So there is no longer a needto debate what is now a moot point.

    The notion that BPM technology is only about SOA and web services hasshown itself to be flawed thinking. People are still a significant part of theoverall way businesses execute their processes. This means that much of thework conducted by the coalition over the years is more applicable now thanits ever been. If you get the chance, look again at Dave Hollingsworths semi-nal paper The Workflow Reference Model 10 years On1.

    The paper puts forward the notion of a BPM Reference Model and con-cludes that, In looking at the various components that make up a BPM ref-erence system, much of the previous work of the original workflow referencemodel lives on... the original architecture is now expressed in XML and asinterfaces to web services. One significant change presented in the paper isin the area of process fragments and the choreography of interactions be-tween such fragments. Hollingsworth goes on, Although the reference modeldid introduce the idea of distributed processes (and defined several types ofinteraction model) it never really tackled the problem of defining a notationfor expressing their interactionthe province of the emerging choreographystandards.

    The correct approach is to recognize what standards are needed where in thearchitecture, and for what purpose. Then they can be populated through thevarious industry and de jure standards bodies. Product vendors will adoptthem if they add valueand this stems from having a thought-through un-derlying architecture that clearly identifies the value and purpose of eachstandard.

    Perhaps this is the core legacy of the Reference Model. At the very least ithas provided a common framework for people to think about Workflow andBPM architecture and many years of fascinating discussions!

    Long may it continue

    Jon Pyke, Chair WfMCand Founder The Process Factory Ltd

    1Workflow Handbook 2004 ed. Fischer, L. Published by Future Strategies Inc., also available as a download from www.wfmc.org

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    10/321

    9

    Workflow and BPM in 2007:

    Business Process Standards See a

    New Global Imperative

    Nathaniel Palmer, Workflow ManagementCoalition, United States

    INTRODUCTION

    Until fairly recently, most of the discussion surrounding business process stan-dards had been largely limited to a technical context. Specifically, focus on stan-dard has been seen largely as the province of software developers and engineers.

    However, with the maturation of interoperability standards around process defini-tion (notably BPMN1and XPDL2), as well as a growing understanding of the roleof open standards in enterprise risk management, the role of BPM standards hasevolved from technical nuance to a business imperative, and is a topic likely todrive many BPM and workflow discussions in 2007.

    THECASEFOR OPENNESS:OPEN STANDARDS AS A RISK MANAGEMENT STRATEGY

    For decades open standards and open source have been natural compadres, yetthe two disciplines are neither equal nor interchangeable. A very visible exampleof this is found in the issues surroundingOASIS Open Document Format for OfficeApplications or commonly just ODF. After smoldering for some time, ODF ex-ploded into quite a wildfire last year when the Commonwealth of Massachusetts

    switched policy to favor it over proprietary office suite document formats.The Commonwealths Secretary of Administration and FinanceEric Kriss, who atthe time oversaw the office of CIO, made history as the first policy-maker to pub-licly favor open formats. His heard-around-the-world shot was fired at the Janu-ary 15, 2005 meeting of the Massachusetts Software Council, stating that it is anoverriding imperative of the American democratic system to prevent public docu-ments from being locked up in a proprietary format, subject to a proprietary li-cense.

    Detractors criticized the direction introduced by Kriss as anti-business and arbi-trarily favoring open source; however, Kriss and current Massachusetts GovernorMitt Romney are unlikely suspects to be anti-business, having co-founded a suc-cessful capital investment firm and, together, have built and led several othersuccessful firms (none of which I am aware of that have ever derived significantrevenue from federal or state governments.) Rather, these two maverick capitalistsrealized the inherent risk to democracy and capitalism presented by having ac-cess to the intellectual property stored in closed format, owned and controlled bya single private gatekeeper.

    1BPMN: Business Process Modeling Notation was developed by Business ProcessManagement Initiative (BPMI), and is now being maintained by the Object Management

    Group (OMG)2XPDL: XML Process Definition Language is a format standardized by the WorkflowManagement Coalition (WfMC) to interchange Business Process definitions between differentworkflow products like modeling tools and workflow engines.

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    11/321

    WORKFLOW AND BPMIN 2007

    10

    ODF is an open format but is not open source. Nor does it need to be. An openformat (to quote Wikipedia) is a published specification for storing digital data,usually maintained by a non-proprietary standards organization, and free of legalrestrictions on use.This also means that it must able to be implemented by both

    proprietary and open source software, using the standard or appropriate licensesused by each. To be clear, offering a clunky, unidirectional translator (the strategychosen by some software vendors) does not count as an open format.

    Ultimately the reason open formats exist is to guarantee long-term access to dataand information without being beholden to specific to legal rights or technicalspecifications. Yet similar to open source licensing, a secondary benefit of openstandards and open formats is the creation of a technology meritocracy. It offers aplatform for competing products to deliver innovative ways for addressing themarkets collective and individual requirements and desires. Indeed, there is arich market of products and online services that support ODF, far more than oth-erwise proprietary formats. Both issues have motivated governments and other

    large software consumers to increasingly favor open formats.The Open Document debate illuminates why we value transparency in data for-mats. Even if every software vendor supporting ODF simultaneously ceased toexist, the availability of an open format ensures the ability to build a new systemcapable of reading the document. Similarly, it provides a platform for new innova-tions to be marketed around a standard implementation, rather than requiringeach vendor to carry this burden alone.

    As we have seen with current and past movements in the role of technology inbusiness, including open source software (OSS), e-mail, the personal computeritself, and countless other examples, the innovative use of standard specificationsoffers far greater marketability than trying to reinvent the wheel on your own.

    What has now been sufficiently demonstrated through the same examples is thatno vertically-integrated, proprietary specification is defensible in the face of acompetitive network built on open standards.

    THEVALUE OF PROCESS TRANSPARENCY:LEVERAGING OPEN PROCESS DEFINITIONS

    Now apply the same notion of openness and portability to the application itself.What if, rather than simply addressing documents, in addition, all of the proprie-tary configurations defining how software applications work (i.e., the businesslogic) were similarly based on an open format. Imagine that all of the millions ofdollars and thousands of man-hours spent configuring business applicationswere not locked within intractable custom code, but were in a standard and port-

    able format. This is, in simple terms, the goal of a number of business processdefinition standards, notably XPDL(XML Process Definition Language).

    XPDL allows for processes to defined using any number of compliant modelingenvironments (both closed and open source options), and interpreted by XPDL-savvy applications. To be clear, it is not an executable language (such as BPEL3,which is discussed in greater detail later in this chapter), but rather a processdescription language which contains not only the business logic which definebusiness processes, but the metadata concerning how to read and recreate proc-essesdown to vector coordinates defining the graphic process model (expressedas a contemporary standard called BPMN(BPM Notation).

    3BPEL: Business Process Execution Language is a business process modeling languagedeveloped by OASIS.

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    12/321

    WORKFLOW AND BPMIN 2007

    11

    These capabilities distinguish XPDL from BPEL, though the two are often placedin close proximity. Yet, as observed by Bruce Silver, one of the industrys mosttenured analyzers of business process software, From day one BPM has soughtto make process design directly accessible to business analysts, but todays BPEL

    process models are, for the most part, undecipherable to non-programmers.Specifically that the content and context of a BPEL model (the equivalent of thewords and prose inside of an ODF document) can only be read by a BPEL engine,not a business analyst.

    Just as ODF provides a capsule for the preservation of intellectual property cre-ated in documents and spreadsheets, XPDL and BPMN provide a platform formanaging a library of business processes as reusable and accessible assets.

    These standards, already available today, also execute and update the same proc-esses in the same format, rather than having static models which are translatedinto code, they offer a single standard format for actionable and transparentbusiness process definitions.

    THEBPMSTANDARDS VALUECHAIN

    It has been suggested in both serious and sarcastic contexts that the great thingabout standards is there are so many to choose from! Used in jest, it pokes funat the fact that competing interests rarely agree on a single standard, despite theinherent notion of standards and standardization implying a singularity of sorts.In the case of business process management and workflow standards, however,there is an upside to that non sequitur.

    In addition to the potentially helpful proposed and emerging standards (notablyBPDM4and BPRI5), the spectrum of specifications in use today present more syn-ergy than redundancy. These include some of the standards previously discussed,

    BPMN, XPDL, and BPEL, as well as others such as eBP/BPSS6

    and the industrysbest kept secretWf-XML7.

    In many ways, this group begins with BPMN (Business Process Modeling Nota-tion), because the logical starting point for modeling is most frequently drawing aBPMN diagram or graphical process model. Then what do you do? The next stepsspotlight the rationale for multiple (yet complementary) standards. BPMN pro-vides a graphic model (i.e., it is a Modeling Notation standard) which can be savedas XPDL during development, and either executed by XPDL-compliant solutionsor ultimately pieces can also be translated to BPEL (i.e., the parts of the processfocuses on data exchange versus human interaction.)

    This presents what has been observed by some as a value chain connecting

    BPMN, XDPL and BPEL. BPMN depicts the end-to-end flow of steps and activitieswithin a business process, modeling the sequence of activities within a process aswell as the data or messages that flow between different process participantswithin a related set of activities. For this reason, BPMN is designed not simply to

    4BPDM, the Business Process Definition Metamodel, is a proposal being developed by theObject Management Group (OMG).

    5BPRI: Business Process Runtime Interfaces being developed by the Object ManagementGroup (OMG).

    6 ebXML BPSS:ebXML Business Process Specification Schema, defines a business processfoundation that promotes the automation and predictable exchange of business collaboration

    definitions using XML. Developed by OASIS.7Wf-XMLWorkflow eXtensible Markup Language.Version 2.0 was produced by the WorkflowManagement Coalition (WfMC), and extends the ASAP model to include BPM and workflow in-terchange capabilities.

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    13/321

    WORKFLOW AND BPMIN 2007

    12

    model applications, but the processes in which applications would be used. Forthis reason, the output of BPMN needs to be expressed in something other thanprogramming language. This was initially expected to be BPML, a since-abandoned standard developed by BPMI.org.

    WHY XPDLIS HERE TO STAYWhat BPMN would have provided vis-a-vis BPML is the direct translation of agraphical model intelligible by people (i.e., business analysts, process owners) intoa machine-readable formatto enable the interchange of process definitions be-tween different tools and from different vendors. In the absence of BPML, wheredo you go with a BPMN model? The answer(s) today are most compelling in theprocess of translating BPMN into XDPL and/or BPEL.

    One of the common misconceptions regarding these standards is that BPEL andXPDL are direct competitors or otherwise mutually exclusive. This is simply notthe case. BPEL and XPDL are entirely different yet complementary standards,designed for different purposes. BPEL is an execution languagedesigned to pro-vide a definition of web services orchestrationthe underlying sequence of inter-actions, the flow of data from point to point, defined start/stop and entrance/exitpoints. XPDL, on the other hand, is designed to capture both programmatic in-formation and the people work expressed within a process diagramto enableone tool to model the diagram, and another to read the diagram, and so on.

    BPMN can be used to model an executable process by constraining diagram ob-jects and their properties to that which can be mapped directly to BPEL elements.This enables, albeit with the limitations, the use of a BPMN diagram to provide abusiness-oriented graphical process model that can also generate executable codethrough BPEL. This present a real advantage because BPEL has not have an as-

    sociated graphical notation nor required concepts to support the visual diagramof a process model.

    Similarly to BPEL the original version of XPDL, by design, lacked specific graphi-cal representationi.e., it was built to be agnostic to modeling methods and nota-tions. With the release of XPDL 2.0 and subsequent versions, however, it was ex-panded to include the specific mechanisms allowing round-trip development fromBPMN to XPDL and back to BPMN. Rather than an executable programming lan-guage, XPDL is a process design format, which literally represents the "drawing"of the process definition. It has XY coordinates and node size, as well as a conceptof lines, and points along the line that give it a particular path.

    The XPDL file can provide this design interchange because it offers a one-to-one

    representation of the original BPMN process diagram. It can be written, and re-read to recover the original diagram. BPEL, on the other hand is a non-trivialmapping which is widely recognized as being one-directional (i.e., not round-trip).As previously stated, it is possible to take a BPMN diagram and produce BPEL,but it is difficult or impossible to recover the original BPMN diagram from theBPEL. But that is okayBPEL was not designed for process design interchange,whereas XPDL was designed precisely for this purpose.

    WHATABOUT SUBPROCESSES?

    Anyone spending time attempting to model the processes of an organizationprobably quickly realizes that operations cannot be easily fit on a single white-

    board. Rather, there are lots of activities and circumstances that happen some-where elsein different systems, different companies, different geographies. Ap-plied for a loan recently? If so, you no doubt participated in a subprocessas the

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    14/321

    WORKFLOW AND BPMIN 2007

    13

    loan application process likely separated the credit check function from the rest ofthe process. Today credit check is a very standard process where analysis of apredefined set of information returns a consistent result.

    Credit checks are a great example of BPEL-appropriate subprocess: it is predict-

    able, well-structured, dataflows are well-defined and dont change, and it istightly-coupled to the process. It is designed to run cheaply and most of timequickly; the rest of the process cannot and should not proceed without the result-ing credit score (what lender wants to waste time on a dead-beat?). There aremany other examples, however, where a subprocess is less time-constrained andlonger-running, operating in parallel with the parent or super-process. For ex-ample, a more complicated loan application today may involve the coordination oftwo separate BPM environments, where both need to talk but not necessarily beintegrated in a tightly-coupled manner. Unlike the credit check example, this isnot a job for BPEL. To leverage BPEL in this situation requires a very fine-grainunderstanding of the syntax of the other system.

    Luckily, there is another standard designed specifically for this. Extending fromOASIS, the standard ASAP (Asynchronous Service Access Protocol) usingSOAP(Simple Object Access Protocol)and Wf-XML allows two BPM systems using stan-dard messaging, analogous to sending an email to the system requesting it start aprocess, then coordinate activities or check in from time-to-time until the de-sired result is reached. Although it would be possible to achieve the same resultusing a combination of a number of web services interfaces, leveraging the singlestandard of Wf-XML allows multiple-compliant BPM systems to interoperatewithout requiring the traditional custom programming or fine-grain integration.Effectively it allows each to examine the process models and activity definitions ofothers, enabling BPM engines to collaborate in a way more closely following hu-

    man interaction than application integration.Who cares about the ability to interchange process models anyway? Process in-terchange offers a key leverage point for firms investing into process models, andis for those who want these investments to be actionable without being lockedinto a single vendor. In all of our research, as well as that we have seen done byothers, we have found it is common for individuals engaged in the early stage ofprocess discovery and validation to use general purpose graphics desktop tools todevelop process models, then to hand these results to process architects for fur-ther validation and the development of actual process definitions. Through vari-ous third-party extensions and templates, the most common desktop design toolscan be made to support BPMN which means it also supports XPDL. In fact, XPDL

    has been used specifically for the interchange of models between XPDL and simu-lation engines. XPDL and BPMN provide a platform for managing a library ofbusiness processes as reusable and accessible business assets.

    The importance of process design interchange continues to increase as the BPMmarket matures. The lack of interoperability and design exchange necessitates avertically-integrated model where a single vendor must supply all of the tools in-volved in BPM. This may have been acceptable in the early stage of the marketwhere early adopters were placing bets on individual vendors, but for the marketto grow and mature into the next stage there needs to be ecosystem, not an oli-garchy.

    BPMSTANDARDS DRIVE GLOBAL INNOVATION

    This ecosystem is visible and growing today, and despite relatively aggressivemergers and acquisitions within the BPM sector, the leverage of standards (nota-

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    15/321

    WORKFLOW AND BPMIN 2007

    14

    bly BPMN, XPDL and BPEL) has provided a platform for a host of individual spe-cialized and niche players, as well as the opportunity for larger BPMS vendors tooffer a standards-based, round-trip framework.

    These standards have also flattened the BPM playing field in a global context,

    with a number of firms within emerging markets now not only offering compliantsoftware, but directly contributing to the working groups defining and developingthe specifications. Where dominant U.S. and Western European firms have notalways demonstrated a willingness to play nice on standards development,emerging-market firms are showing great innovation when it comes to both thedevelopment and application of standards.

    An important attribute for enabling innovation within this ecosystem is the exten-sibility mechanism of XPDL. Specialized tools may present unique requirementsusing extended attributes, and while other tools will not understand these exten-sions, they will carry the extensions along the round-trip. For example, a tool spe-cialized to clean up the layout might manipulate the graphical aspects of the

    model, and return a cleaned-up model, including all the extensions, back to theoriginal source without losing any information. A number of open source toolshave demonstrated the ability to read XPDL files generated from commercial ven-dors, allowing process definitions to be modified and returned without any loss ofvendor specific extensions.

    Several BPM engines are able to run XDPL natively, which allows run-time modi-fication and process migration to be readily supported. Where these processesfocus on broader-scope collaboration among people, they can remain withinXPDL/BPMN. Where pieces are decomposed into system-to-system interactions,these can be translated to BPEL for transmission to an EAI-oriented BPM engine.

    These are three very different and very compatible roles. But that is the nature of

    the value chain; BPEL and XPDL are entirely different things for entirely differentpurposes

    No longer limited to an audience of software developers and engineers, processdefinition and interoperability standards such as BPMN and XPDL have becomemainstream issues for BPM and workflow consideration and competitive differen-tiation. This attraction will, no doubt, only increase as more individuals in linemanagement and business process ownership understand the strategic role ofopen standards in matters such as enterprise risk management and regulatorycompliance, as well as the opportunity to leverage investments made in businessprocess documentation and business logic design, rather than locking these awayinside closed systems and proprietary specifications.

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    16/321

    Section 1

    The Business

    Value ofWorkflowand

    BPM

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    17/321

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    18/321

    17

    The Business Value of

    Workflow and BPM

    Keith D. Swenson, Fujitsu Computer Systems,United States

    ABSTRACT

    Human-Oriented Business Process Management, also called Workflow, is a criti-cal component that allows applications to meet the agility demands of business.Service-Oriented Architecture (SOA) is an important design goal to meet the agilitydemands of Information Technology (IT).

    IT and business users are different audiences, with very different demands, and

    failure to recognize this can lead to missed opportunities and unsatisfactory solu-tions. This paper will show how workflow can be brought together with SOA tech-nology to form a powerful combination to meet both demands. IT can design ser-vices that are safe for non-technical people to compose into high level applica-tions, giving them the unprecedented ability to respond to external events. Exam-ples include a corporation that changed business process in 2 hours in order tobe in a new line of business the next day.

    INTRODUCTION

    In 2006, Forrester ran a poll of 146 IT Executives and asked the following ques-tion: Considering your existing enterprise applications, how important are the

    following business problems? The results of the poll are reflected in this chart:

    The question does not specifically mention business process, nor was the audi-ence selected for interest in business processes. Eighty one percent of the respon-

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    19/321

    THE BUSINESS VALUE OF WORKFLOW AND BPM

    18

    dents felt that inadequate support for cross-functional processes was an impor-tant business problem. Note that several other highly rated responses point to theneed for business process support.

    Please contact Forrester Research directly for the full details of the study and the

    results. This excerpt is used here to highlight that IT professionals understandthat there is a divide between the business side, with its business requirements,and the support that is being provided. Those IT professionals are looking forways to close this gap.

    DEFINITION OF TERMS

    Workflow is an excellent way to meet this need. Workflow allows for a betteralignment of IT with business because it allows the enterprise applications to beexpressed in a way that makes sense to business users. We will also see that ithelps businesses be more agile by allowing business people control of the busi-ness aspects of applications, while IT people retain control of the applicationsmore technical aspects. Before discussing the details of how this comes about, weshould start first with a definition of a few basic terms to make sure that we aretalking about the same things.

    The term Business Processis used a lot today, but often loosely to mean severaldifferent things. The origin of the term is generally attributed to Michael Hammerand his seminal work in the area of Business Process Reengineering. When Mi-chael Hammer talks about a Business Process he uses the term to distinguish aBusiness Process from a Manufacturing Process or a Chemical Process. Thedistinguishing characteristic of a Business Process is that it involves people doingoffice work. The point of his work was to get people to stop thinking about officework as being organized along functional lines, and to start thinking about the

    chain of different functions that must be strung together to accomplish a busi-ness goal. He was very successful in getting people to think along these lines, andtoday no serious business analyst would approach an attempt to improve the wayan office works without starting by drawing out the process. Oddly, some peopleuse the term business process for things that dont involve people or office work. Iprefer the WfMC definition which has been stable for ten years now:

    Business ProcessA set of one or more linked procedures or activitieswhich collectively realize a business objective or policy goal, normally withinthe context of an organizational structure defining functional roles and rela-tionships.

    WorkflowThe automation of a business process, in whole or part, duringwhich documents, information or tasks are passed from one participant toanother for action, according to a set of procedural rules.

    Process DefinitionThe representation of a business process in a formwhich supports automated manipulation, such as modeling, or enactment bya workflow management system. The process definition consists of a net-

    work of activities and their relationships, criteria to indicate the start and ter-mination of the process, and information about the individual activities, suchas participants, associated IT applications and data, etc.

    The WfMC Glossary does not include a definition for Business Process Manage-

    ment but recent discussions within the Coalition have centered on the followingproposal which highlights management aspect of the term:

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    20/321

    THE BUSINESS VALUE OF WORKFLOW AND BPM

    19

    Business Process ManagementThe practice of developing, running,performance measuring, and simulating Business Processes to effect the con-tinued improvement of those processes. Business Process Management isconcerned with the lifecycle of the Process Definition.

    As office work has been traditionally supported through the use of paper docu-ments and folders passed from function to function, many of the early workflowproducts focused on routing documents through a group of people. More recentsystems are quite a bit more sophisticated, offering not only documents, butstructured information handling, complex event processing, programmatic ma-nipulation of information, and the ability to exchange information with web ser-vices and other external information sources. These newer capabilities allow theworkflow systems to integrate into the modern IT infrastructure. At the sametime, the workflow systems have not forgotten the human aspect, which giveworkflow a unique capability to bridge the gap between the business world andthe IT world.

    TWODIFFERENTAUDIENCES

    We talk about the gap between business and IT, but what do we mean? Busi-nesses run on their information systems, but there are two distinct audiences.

    The first audience we call business users.These are the people in the organizationwho are doing the work that directly accomplishes the goals of the organization.In most ways, these people are users of the information systems. The businessside also includes management, who is interested in how well their organization isrunning, and might be interested in optimizing the way that people work. TheCEO, CFO, and Line of Business manager are roles that are well known. We nowtalk more about the Business Analyst role. People in this role specialize in the or-

    ganization of tasks into processes. The Business Analyst is not normally techni-cal, but instead someone who understands the business and the goals of thebusiness, as well as how to accomplish those goals with a team of people.

    The second audience we call Information Technology(IT) professionals. This side ofthe business is responsible for providing the information systems. Sometimes thismeans developing custom applications for the enterprise, and in other cases itincludes only installation and management of package applications.

    The reason for considering these as two distinct groups is because they often lookat the same problem with different goals and desires. The business side is con-cerned with business goals which are both manual and automatable, while the IT

    side is concerned with only those goals that can be translated into tested, reliable,and secure systems. While the IT side is organized around system structure andvalues 7x24 operation and scalability issues, the business side is organizedaround social structures with the complexities of working hours, vacation sched-ules, skills training, and changing positions.

    Both business and IT users need agility, the ability to respond to change. But therate and scope of change are different between the two groups. Not countingemergencies such as production server outages, there are usually weeks ormonths needed to plan the addition of a server or a new application to the sys-tem. The business user, on the other hand, needs to be responsive to competitors,the market, and personnel changes, on a week or even daily basis. If a competitor

    comes out with a challenging new product, you need to respond immediately. Thetypical average turnover across all US businesses is 20 percent. This means thatif you are running a 1000-person organization, you will have on the average one

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    21/321

    THE BUSINESS VALUE OF WORKFLOW AND BPM

    20

    person leaving and joining every day. Your personnel change internally is muchgreater than that, because you have people learning new skills, moving into newpositions, as well as taking and returning from vacations. Running a business isa matter of accommodating change on a daily basis.

    Process support for humans is also very different than process support for IT sys-tems, and this difference can be categorized as a difference in the handling oftime. Making a process which routes information through a set of servers is amatter of identifying the servers and transforming the data as required by each,along with any conditional logic to determine what happens next. The servers aregenerally available 7 x 24, so when you have a job for a server to do, it can typi-cally be given the task immediately. There are details for scalability and robust-ness being glossed over here, like retries for those rare cases that the server isdown, or queues for the cases where a server is given multiple tasks at the sameinstant, but it is fair to generalize by saying that servers spend most of their timesitting and waiting to be given a task, and when given a task they take those

    tasks in the order given. They generally complete the task almost instantly.People, on the other hand, work in a very different manner. A human process sys-tem (workflow) will offer tasks to people. Those people are not generally sittingaround with nothing else to do, and do not take up the task immediately uponbeing assigned. Generally a person has a worklist with a variety of things in pro-gress which can be sorted and completed in a more efficient manner. Tasks as-signed during off hours will wait until opening hours to be considered. The as-signment of a task to a systemis very concrete; if a system is set up to handle atask by the installation of software, it is immediately able to handle all such tasks.Assigning tasks topeopleon the other hand is a much more complicated thing.People will have varying levels of particular skills, and are often specialized in cer-

    tain ways. Two salespeople may have equivalent skill to close deals, but one ofthem may be more suitable for a particular job because of having more experiencewith, say, defense contractors. It may not be possible to express the criteria, sosuch systems need the ability to manually reassign tasks. Human process sys-tems generally offer an ability to send reminders or escalate the task when it hasnot been completed within a certain time. Whereas, there is no point in sending areminder to a server that has for any reason failed to complete an activity.

    When IT professionals talk about process support (even business process sup-port) they often are referring to this system to system process support whichforms an important part of meeting their needs to create robust, scalable system.But when business users discuss process support, they usually refer to human

    process support, or workflow, which includes these human features, but at thesame time can provide connectivity to the backend information systems. It is thisunique ability for workflow systems to bridge between the human and systemrealm that makes them key in providing business value to the organization.

    PURPOSE OF WORKFLOW

    I have pointed out how workflow offers unique features that allow for the coordi-nation of human work during the running of a process, but there is another key

    aspect of workflow which is critical to bridging the business IT gap.The businessprocesses themselves must be able to be designed and modified by business peo-ple. Here are some comments that reflect this:

    The ultimate goal of workflow is to place in the hands of business profes-sionals the ability to modify their processes, with no involvement from theIT organization.Michael Melenovsky, Gartner BPM Summit, 2006

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    22/321

    THE BUSINESS VALUE OF WORKFLOW AND BPM

    21

    ... process changes are made by business professionals who need only limitedknowledge of IT systems. In a growing number of cases, changes such as

    work item routing, business rule overrides, and parametric changes to ap-proval levels, are made in real time to executing process.Janelle Hill, Gart-

    ner BPM Summit, 2006These ideas are very uncomfortable for most IT professionals. That is becausethey know that with traditional programming practices, if you let an untrainedperson modify the code it is far more likely to break the application than to im-prove it. I think most people would agree that, for a non-programmer, opening up

    Java, C++, or Visual Basic code would be dangerous. To complete an application,a programmer must apply many rules and practices in a correct manner to resultin a reliable and safe application.

    What these industry experts are saying is not that we want business people play-ing with the guts of the application developed along the lines of traditional pro-gramming, but rather that applications must be structured in a specific way thatisolates the business process from the programming logic. The more technicalaspects of the application need to be wrapped up into reusable chunks. Thosechunks need to be robust and not sensitive to erroneous input. They need to bemore like plugging a power adapter into your cell phone, and less like soldering aprinted circuit board.

    Business side retains control of:

    Assignment of responsibility because this depends strongly on who is in

    the organization.

    Groups, Roles, and Skills because these change on a monthly, weekly, or

    even daily basis.

    Deadlines, Alerts, Reminders, and Escalations because they depend onthe culture of the organizational unit

    Order of tasks and addition of new manual tasks because this is critical

    for agility to be able to respond to market and legislative changes.

    User Interface because this is effected by the level of training or experience

    of a particular organization

    IT retains control of:

    Computational logic and data representations because there is little or no

    dependency upon the culture of the organizations

    Scalability and performance because this requires significant specialized

    expertise in the working of information systems.

    Interoperability because this requires extensive knowledge of the operat-ing infrastructure

    Master data management because this is constrained by highly special-

    ized requirements

    The business processes need to be abstracted out of the application, and repre-sented as a structure separate from the more technical aspects. The businessprocess is simply used to sequence the chunks into an integrated whole in a waythat is safe for a non-programmer to edit.

    By 2009, 20 percent of business processes in the Global 2000 will be sup-ported on BPMS[*]. These processes will be predominantly those that in-

    volve a lot of human work, that differentiate the company from its competi-tors and that are poorly supported by existing IT systems (0.7 probability). --Janelle Hill, Gartner BPM Summit 2006

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    23/321

    THE BUSINESS VALUE OF WORKFLOW AND BPM

    22

    Gartner defines a BPMS as a suite that handles both human and system proc-esses, which is equivalent to the definition of workflow given above. This trend isclear.

    AN EXAMPLE:HUMAN-BPMAPPLICATION

    To illuminate how the application might be structured to allow for the differentresponsibilities to be split across different groups of people, consider in detail anexample application for processing bank loans. It is common for the applicationdevelopment to start with drawing a high level human-oriented process diagram.A business analyst might start by deciding what important business activitiesneed to take place to accomplish the goal. Imagine that people come to the bankand fill out an application which is subsequently scanned and converted to textdata, and that this is the event that starts the process. In this case the businessanalyst determines that two people need to be involved. First, a person needs toreview the input data for completeness and as a check of the character recogni-tion. Once that has been done, a bank manager needs to make a decision on

    whether to grant the loan or not.

    This example is simplified so it can be discussed in this article, but it is importantto note that the business analyst is dealing only with jobs that must be performedby humans within the organization. There is an implicit assumption that therewill be a bunch of data processing associated with the process, but that is not aconcern at this level. For example, a bank will clearly want to perform a back-ground check on the applicant, but that is not a human activity. Since that canbe completely automated, there is no reason to have a person in your office whoperforms background checks. Instead, it is assumed that somewhere between thefirst and second human activity, a call will be made to retrieve information aboutthe background of the applicant, and the bank manager has the results of thatavailable in order to make the decision of whether to loan the money or not. Atthis point, the business analyst is concerned only with the activities that will bedone by office workers.

    Reviewenter

    infoReview

    enter

    info

    The diagram above is a conglomerate of notations. The circles, rounded rectan-gles, and arrows between them depict the process using a standard called Busi-ness Process Modeling Notation (BPMN). The rounded rectangles are the standardway that you represent an activity, while the circles represent the start and endevents. The trapezoid shapes are not part of the BPMN standard, but instead areused here simply to represent that there will be a user interface (UI) of some sortassociated with the activity. The business analyst may lay out some sort of form

    which specifies particular information values that must be made available to theuser. This specification might be abstract in only specifying the quantities thatneed to be present, or it might be a concrete layout of precisely where such values

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    24/321

    THE BUSINESS VALUE OF WORKFLOW AND BPM

    23

    should appear on a screen. The people then use the UI in order to perform theirrespective tasks.

    This level of the process might be designed on a graphical design tool intendedspecifically for business process design. It might be drawn up using a generic

    graphic tool, or it might simply be documented in a non-graphical way. Someworkflow systems will allow a drawing at this level to be executed directly withoutany further technical work. Others offer powerful design capabilities, but the im-plementation of the automated system is left as a task for a traditional develop-ment team. In some cases if suitable web services with public interfaces exist, it ispossible that a business user might be able to incorporate calls to back end sys-tem without programming. But in most cases, integration to the back end infor-mation systems must be done by a development team.

    The human process design is provided to the programmer who will add integra-tion to the back end system. In this example, immediately after the first activity ofreviewing the information for correctness (which must be done by a human) the

    system then should automatically call a service that can perform a backgroundcheck of the applicant. The bank may have rules that it will not accept certaincategories of applicants, and there is no reason to force the bank manager tocheck this manually. Business rules can be employed to classify applicants. Inthis example, an Enterprise Service Bus (ESB) is used to integrate the call to thebackground check service, and the call to the conformance rules into a single webservice which is easy to connect to the workflow. This is not meant to imply thatan ESB must be used; most workflow systems will allow for multiple calls to dif-ferent services. This is offered here only as an example of how IT professionalsmight wish to structure the back end systems to give them flexibility.

    After the bank manager reviews the application and approves the loan, an addi-

    tional call is used to integrate with the account management application and tocause the new account to be created.

    Enterprise Application A

    Account Management

    Backgrou

    nd

    Rules

    list

    Accts

    new

    Acct

    update

    Acct

    delete

    Acct

    call 1 Review

    ESB / BPEL

    enter

    info

    Enterprise Application A

    Account Management

    Backgrou

    nd

    Rules

    list

    Accts

    new

    Acct

    update

    Acct

    delete

    Acct

    call 1 Review

    ESB / BPEL

    enter

    info

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    25/321

    THE BUSINESS VALUE OF WORKFLOW AND BPM

    24

    The boxes in the lower half of the diagram represent automated services of vari-ous forms. The smaller square boxes represent web service interfaces to thesecapabilities. The intent is not to imply that it is necessary to use web services, butthat is currently a popular approach to allow for flexibility.

    Why didnt the diagram change when adding the new integration? An IT profes-sional might want to draw a more detailed diagram, one that includes activityboxes for the background check, and the rules. This would be helpful to IT, butan important principle of support for human processes is to not clutter the dia-gram with details that are not relevant to the human users. The human processdiagram is used for things like training people within the organization. It is impor-tant in a training scenario to show the steps that people have to do. The detail ofwhere calls are made to back end systems is not important when helping peopleto understand what it is that they need to do, and how it relates to what otherpeople do. The business users are best served by a diagram that shows what thebusiness users are doing. This may seem obvious, but you will find a large num-

    ber of IT people who find this concept surprising.AGILITY IN THE FACE OF CHANGE

    In the previous section we saw how an application might be constructed, but thatis not the end of the story. Applications must evolve and change over time. Thepoint of structuring the application in this way is to enable rapid change of someaspects of the application without breaking it.

    Consider what the bank will have to do to respond to this scenario: One day, it isreported that a small bank in one part of the country is successfully sued and hasto pay a huge fine for having given a loan to a terrorist. This is a purely hypotheti-cal example, but the point is that legal precedence is set by court cases which can

    happen relatively suddenly without warning. If this was to happen, the prece-dence would be set, and it might be possible then for many other banks to besued if they do the same thing. The bank has a huge risk, and can not afford towait for a new terrorist identification solution to be developed by IT in order tocheck if the applicant is a terrorist. The bank must begin, the very next day, tobehave under the new rule of not giving a loan to a terrorist.

    The first thing to happen is that a manual check must be added to the process. Ateam will be identified, and every bank loan must be reviewed by that team, toassure that the current loan is not going to a terrorist. The bank will also set inmotion a project to automate this, but that will take weeks or months. The bankcan not afford to stop giving out loans for that time. The manual review will be

    expensive, but less expensive than being sued if they make a mistake.The manual step can be immediately incorporated into the human process as anew step between the review and the approval. The huge advantage in being ableto put this step directly into the process is that, at the end of the day, you are as-sured that everybank loan has been checked. Workflow systems keep a record ofevery activity that is completed, and it is easy to prove that every loan has beenappropriately checked. The bank is able to prove compliance to the new rule (law)the very next day on every loan made, which greatly reduces risk of the bank.

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    26/321

    THE BUSINESS VALUE OF WORKFLOW AND BPM

    25

    Enterprise Application A

    Account Management

    Background

    Rules

    list

    Accts

    new

    Acct

    update

    Acct

    delete

    Acct

    call 1 Review

    ESB / BPEL

    enter

    info

    legal

    check

    Enterprise Application A

    Account Management

    Background

    Rules

    list

    Accts

    new

    Acct

    update

    Acct

    delete

    Acct

    call 1 Review

    ESB / BPEL

    enter

    info

    legal

    check

    legal

    check

    The manual step is temporary. A couple of months, or possibly weeks, later therewill be an automated service that will be able to reliably categorize an applicant asa terrorist or not. This can be added as another automated call between the firstand final steps of the process. When this is in place, and when the bank is confi-dent that it works correctly, the manual step can be removed from the process,and the bank can return to having two human steps in the loan process.

    CONCLUSION AND SUMMARY

    Agility is about responsiveness to the market. Applications that are designed us-ing traditional programming principles cannot be modified quickly due to thetechnical expertise that is required. But if an application is structured from thebeginning to separate the human process from the technical manipulation of the

    data, then it is possible for business users to be able to modify the process part ofthe application in a safe way.

    When done right, successful BPM initiatives (herein referring to projects in-volving both business process analysis and the implementation of businessprocess management software) change the entire notion of applications, byallowing core systems to respond to process context, rather than drivingprocesses around the limits of technology.Nathanial Palmer, LauraMooney, 2006

    The fundamental benefit is business level agility, where applications are no longermonolithic blocks constructed out of third-generation languages. Instead, the

    user interface is separated from the back end logic. In this case, user interfacemeans not only the visual display to the user, but the time-orientedaspects of of-fering a task to a user, and reminding that user if the task is not completed in

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    27/321

    THE BUSINESS VALUE OF WORKFLOW AND BPM

    26

    time. The solution is built from applications slicessequenced by workflow process.The workflow determines the right person for the right task at the right time.

    The key difference is that the business analyst is in control of the human side ofthe application. The business analyst can rearrange slices, and add in manual

    steps quickly, without having to do any programming. This yields a form of agilitythat is rapidly becoming a competitive differentiator in the industry.

    This is the business value of workflow and human-oriented BPM.

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    28/321

    27

    Knowledge Intensive BPM

    Jon Pyke, The Process Factory Ltd., UK

    Many of us involved in the field of Workflow Automation and Business ProcessManagement (BPM) have argued long and hard about where these two technolo-gies overlap, where they are different, which mathematical models to use, whichstandards are applicable to which part of the technology stack and all that asso-ciated puff.

    Well, these arguments and discussions are over; the demarcation lines have beendrawnthe road ahead is clear.

    The fact that Business Process Management has its roots in Workflow technologyis well knownmany of todays leading products are, in fact, evolutions of theoriginal forms processing packages. So there is no longer a need to debate what isnow a moot point.

    But what has happened is that BPM has also changed. Rather than being an ex-tension of workflow concepts BPM is now seen as systems-to-systems technologyexclusively used in the deployment of SOA solutions. Im over simplifying things Iknow, but it does seem that BPM is becoming an IT Technology solution as op-posed to the business process solution it was meant to be. Somewhere along theway, one of the key elements in a business processa persondropped off theagenda. The fact that the majority of business processes (some 85 percent accord-ing to the analyst company Forrester) involve carbon-based resources1was over-lookedthink BPEL for a momentdoesnt the development of that particular

    standard tell you something about the general direction of BPM? But be warned,many vendors will tell you that their BPM products support human interaction,but what they are talking about will be simple work item handling and form fill-ingthis is a long way from the collaboration and interaction management we willtalk about below.

    The problem stems from the fact that most workflow products were flawed and asa result, the problem in the gene pool has rippled through to the new BPM spe-cies. So what was wrong with workflow? Its quite simple when you think about it;most workflow products assumed that work moved from one resource to another.One user entered the loan details, another approved it. But business doesnt worklike that.

    This flawed thinking is probably the main reason why workflow was never quitethe success most pundits thought it would be; the solutions were just not flexibleenough, since the majority of processes are unsuited to this way of working.Paradoxically, it is the exact reason why BPM is so suited to the world of SOA andsystems to systems processes. A rigid approach to systems processes is essential,where people are concerned; the name of the game is flexibility.

    WHY DO WE NEED THE FLEXIBILITY?

    As mentioned earlier, we have to deal with the unexpected. This is not just aboutusing a set of tools to deal with every anticipated business outcome or rule; weare talking about the management of true interaction that takes place between

    individuals and groups which cannot be predicted or encapsulated beforehand.

    1Human beings, people

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    29/321

    KNOWLEDGE INTENSIVE BPM

    28

    This is because Business Processes exist at two levelsthe predictable (the sys-tems) and the unpredictable (the people).

    The predictable aspects of the process are easily and well-catered for by BPMSsolutionswhich is why the term Business Process Management is a misnomer

    since the perceived technology addresses only the integration aspectswith theclose coupling with Service-Oriented Architecture (SOA) (SOA needs BPM, theconverse is not true) there is an argument for renaming BPM to Services ProcessManagement (SPM).

    The advent of BPEL4People isnt going to fix the problem either, all that will hap-pen is the shortcomings of workflow will be replicated and it will be as difficultand expensive to implements as it ever wasand anyone who has tried to puttogether a business case for buying SOA/BPM will know the entire propositionwill be a non-starter.

    Understanding that the business processes exist at two levels (the Silicon and theCarbon) takes us a long way towards understanding how we solve this problem.

    The key point is to recognize that the unpredictable actions of the carbon compo-nents are not ad-hocprocesses, nor are they exception handling (ask anyone witha Six Sigma background about exceptions and youll understand very quicklywhat I mean). This is all about the unstructured interactions between peopleinparticular knowledge workers. These unstructured and unpredictable interac-tions can, and do, take place all the timeand its only going to get worse! Theadvent of Web 2.0, social computing, SaaS etc., are already having, and will con-tinue to have, a profound effect on the way we manage and do business.

    Process-based technology that understands the needs of people and supports theinherent spontaneity of the human mind is the next logical step, and we mightbe tempted to name this potential paradigm shift Knowledge-Intensive BusinessProcesses.

    This is somewhat different from workflow or BPM as we know it because the focusis on the work, not the process. Of course the underlying objective of the processis still of vital importance indeed, it provides the underlying bedrock of gettingtasks completedbut these processes are much more complex, ad-hoc, enduringand important to the business. They are contracted processes as opposed to co-ordinated or controlled processes as provided by workflow and BPM solutions.

    Lets take a simple analogy so that the concept is more easily understood.

    Supposing you were playing golf; using the BPM approach would be like hitting ahole in one every time you tee off. Impressive18 shots, and a round finished in

    25 minutes.But as we all know, the reality is somewhat different (well, mygolf is different)theres a lot that happens between teeing off and finishing a hole. Normally aboutfour steps (or shots)but you have to deal with the unexpected; sand traps, waterhazards, lost balls, free drops, collaboration with fellow players, unexpected con-sultation with the refereeand so it goes on. Then there are 17 more holes todothe result: an intricate and complex process with 18 targets but about 72operations.

    KIBPM falls into two main types, which will probably merge over time, and thevendor that recognizes that potential will steal a march on the others.

    The first, and in use today, is Case Management (AKA Case Handling).Case is a very different proposition and represents a very different opportunityspace for BPM vendors. As mentioned above, todays BPM solutions are still very

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    30/321

    KNOWLEDGE INTENSIVE BPM

    29

    production centricwhat Analysts used to call Production Class Workflow. Weknow that most organizations dont work this way, at least not at the humanlevel.

    The key differentiating2factor of a case handling environment is the ability to run

    multiple procedures against a given case of workthe primacy is with the caserather than the process that is used to support a work item, which means thatthe key concept of this approach is the body of work, the Case, not the typicallymodeled process of moving of work from one resource to another (where resourceis a system, a work tray or step in a process).

    Case Handling might be thought of as any sort of business problem where, with-out technology support, a manila folder would have been used to store relateddocuments and information about things of interest and tasks then associatedwith the contentsan intelligent to do list if you will. Case Handling systemsleverage the capability to associate virtually any number of objects within the con-text of a case. Processes tend to unfold rather than rely on a priori design time

    decisions (but within the context of an overall framework). Clearly, the activitiesare related and cases follow typical patterns but the process becomes the recipefor handling cases of a given type.3

    The following diagram illustrates what a typical solution might look like:

    Case management is effectively a sub-process within a much larger context andinherently more flexible.

    The next logical step from case management is to focus still further on the human

    aspects and introduce the concepts of Human Interaction Management (HIM).HIM has been developed to provide a mechanism that translates top-level strate-gies into executable collaborations and to provide an approach to negotiatingpublic processes.

    Worldwide, more and more routine work is gradually being automated and/orcommoditized. So the skilled human work left over is more important than everboth to individuals, who are competing for a smaller and smaller number of inter-esting jobs, and to organizations, for whom skilled human work is becoming theonly competitive differentiator left.

    2Meirs, Derek, Enix Consulting one of his many white papers

    3Van Der Aaalst, Wil Beyond Workflow Management: Product Driven Case Handling

    Case Case Case

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    31/321

    KNOWLEDGE INTENSIVE BPM

    30

    This type of work depends fundamentally on collaboration. Few highly skilled in-dividuals work in isolation. Yet the new software tools for Internet-based commu-nication are actually making collaboration less and less efficient, by flooding eachof us with more and more email, chat, text messages, video conferences, telecon-

    ferences, documents. Furthermore organizations have lost the ability to managetheir workforce. So we all need to collaborate better. This means adopting a sim-ple, general approach to collaborationone that meets both individual and organ-izational needs.

    Meeting this need is a framework for human process collaboration, based on thetheory of Human Interaction Management. HIM solves a problem of direct busi-ness relevance by constructing work processes based on those carried out in theirorganization. In this way, the processes are far easier to build and deploy; integra-tion demands are reduced; there is no need to get it right on first deployment.

    A typical human collaborative work process is agileit changes as it goes along,since much of the work is about jointly deciding what to do next. Hence, a proc-

    ess template intended for use as a starting point alone is enough to deliver signifi-cant personal productivity improvements to users, and significant efficiency bene-fits to organizational management.

    HIM is designed to support human work processes, which depend on interactionand are dynamically shaped by the participants. This is achieved by five mainfeatures of the technology:

    1. Connection visibility

    2. Structured messaging

    3. Support for knowledge work

    4. Supportive rather than prescriptive activity management

    5. Processes change processes.

    It effectively turns strategy into action and provides a mechanism for ensuringusers have control over the strategic objectives and that executives remain in con-trol of the overall deploymentwith the ramifications that will have over corporatecompliance. Furthermore it provides strong management control by enabling par-ticipation in the process execution including on going redefinition of the processitself, thereby ensuring maximum agility and responsiveness.

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    32/321

    KNOWLEDGE INTENSIVE BPM

    31

    The above diagram encapsulates HIM in action.

    Weve learnt that BPM has evolved from simple routing engines and forms pack-ages that were designed to manage the flow of work, and handle controlled proc-esses, through to Process Management tools that act upon explicit interactionsand effectively coordinate known processes to the Knowledge intensive BPM sce-nario that handles tacit interactions, case management and contracted processes.

    The true process-enabled enterprise will use the technology (BPM) to address allaspects of the value supply chain; the very DNA of the organization. This includesthe People: customers, employees and stake holders; the applications both inter-nal and external and processes up and down the full supply chain.

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    33/321

    KNOWLEDGE INTENSIVE BPM

    32

    CONCLUSION

    In conclusion the move towards sophisticated human interaction will have a ma-jor impact on the BPM market in the very near future. BPM vendors with theright insight into the market will seize this opportunity and steal a significantmarch on their competitorsand it is fair to say that some of those vendors willbe unable to respond to this growing need.

    I doubt there are many BPM products on the market today which will be able tomeet this seismic shift in requirementscertainly those that rely on BPEL andSOA wont and any that have been in the market for longer than five years willneed radical surgery to meet the coming challenge.

    KIBPM

    BPM

    WfM

    Source EDS BPM a systemic Perspective

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    34/321

    33

    BPM and Service-Oriented

    Architecture Teamed Together:

    A Pathway to Success for anAgile Government

    Linus Chow and Charles Medley, BEA Systems;Clay Richardson, Project Performance Corp., USA

    EXECUTIVE SUMMARY

    Business Process Management (BPM) and Service-Oriented Architecture (SOA)

    have evolved almost independently over the last six years to become key technolo-gies leveraged by government agencies in their struggle to become more agile andinnovative. Inherently team players, the converging maturity of these disciplinesand technologies promise to produce an ROI multiplier1effect for organizationsworldwide. This paper showcases the real challenges faced and benefits derived bygovernment agencies seeking to use BPM and SOA to meet constituent demandsfor increased agility and responsiveness. An example-driven analysis of these highimpact solutions and what they mean to government entities such as the US De-partment of Defense, US Intelligence Agency, and Government of Bermuda are pro-vided in this chapter.

    THREE KEYCHALLENGES WILL FACEGOVERNMENT OVER THE NEXT TENYEARS

    Through each budget cycle, government agencies are constantly challenged to ac-complish more far-reaching goals with less working capital. This trend is expectedto continue as government tightens its belt to accommodate social and military de-mands. Government executives, CIOs, and technology managers have become ac-customed to the mantra: Do More with Less. While technology has been a majordriver in addressing the need to Do More with Less in the last three to four years,the challenges have increased and are pushing technology to the limits of its capa-bilities.

    The first of the great challenges facing government is the retirement tsunami thatwill take place over the next five to ten years. As reported in the Washington Post,

    60 percent of the governments 1.6 million white-collar employees will be eligible forretirement in the next 10 years2. With such a large portion of the baby-boomer gen-eration retiring from government, the impact undoubtedly will be widespread. Thisissue will not only impact the federal government; it is also anticipated that largenumbers of retiring baby-boomers will step away from state and local government

    jobs in the coming years. Over 30 percent of Californias workforce will retire in thenext three years, points out Anthony L. Souza, a former CIO with the State of Cali-fornia3. This represents a looming crisis that the State is currently planning for,states Souza.

    The immediate challenge arising from this retirement tsunami will be filling thehigh number of job vacancies that will be created. However, the greater challenge

    lies in addressing the great loss of institutional knowledge that will literally walk outof the door when boomers retire. In many cases, this knowledge that has been builtup over decades of service to the government will be difficult, if not impossible, to

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    35/321

    BPMAND SERVICE-ORIENTEDARCHITECTURE TEAMED TOGETHER

    34

    capture or reconstitute. To address the strains created by projected mass-retirements, government will lean more heavily on information technology to driveefficiency, productivity, and self-service using a smaller, leaner workforce. Technol-ogy will need to capture the institutional knowledge of retiring government workers

    in order to ensure continued enforcement of informal and undocumented policiesand procedures.

    The second major challenge facing government is the need to support longer tech-nology refresh rates. Many agencies are now faced with technology refresh rates ofthree to four years. Looking out into the future, these refresh rates are likely to re-turn to those seen during the 1970s and 1980s.

    Given the trend toward lower information technology budgets for governmentagencies, systems will need to remain in commission longer than what we sawin the late 1990s and early 2000s, points out John Kim, who supports infra-structure planning activities for the United States Patent and Trademark Of-fice4. Looking to the future, Kim envisions technology refresh cycles of five to 10

    years, where systems will need to remain in commission and evolve to meetthe needs of internal and external constituents. This means systems will needto be able to incorporate rapid changes that result from new legislation and rulechanges, says Kim.

    The third great challenge facing government is the continued trend toward out-sourced information technology services. In most agencies today, the bulk of infor-mation technology services are outsourced to technology consulting firms. This of-ten means that agencies are orchestrating development projects across various in-tegrators that usually compete with one another in the federal marketplace. How-ever, agencies require these firms to work closely together to deliver mission-criticalsystems that cut across various departments.

    In the future it will become even more important that federal contractors and con-sulting firms play nice together to support the agencys mission. Technology andinteroperability standards will need to facilitate collaboration and communicationacross various systems, platforms, programming languages, and methodologies.Without standards and the appropriate tools, it becomes impossible for governmentto connect the various development activities of integrators to the larger picture ofthe agencys mission.

    BPMAND SOAARECONVERGING TOANSWER THESEGREAT CHALLENGES

    Over the last six years, Business Process Management (BPM) and Service-OrientedArchitecture (SOA) have evolved as key components in the technology landscape. In

    addition, these two technologies represent the greatest promise for answering thekey challenges that will be faced by government in the coming years.

    While these two technologies represent the greatest promise, they also represent themost over-hyped and maligned technologies today. Most government CIOs and in-formation technology managers view SOA and BPM more as industry buzzwordsthan technologies that have substance and can deliver measurable results. Much ofthis misunderstanding comes from the constant barrage of mixed messages ex-plaining BPM and SOA and their promised benefits.

    At Wikipedia.com, a search on Service-Oriented Architecture turns up over 10pages of content that define this technology. Even within the Wikipedia.com defini-tion, there is some debate as to exactly what SOA is and isnt. In addition, a quickpoll of most information technology managers also turns up that SOA is one of themost disdained terms in the technology lexicon. However, to understand SOA it is

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    36/321

    BPMAND SERVICE-ORIENTEDARCHITECTURE TEAMED TOGETHER

    35

    helpful to take a trip back to the mid-1990s when Object Oriented Programmingwas the hottest phrase in the world of technology. Object Oriented Programming(OOP) was introduced as a paradigm that allowed application code to closely mirrorthe objects and functions provided by a particular business activity. For example,

    an accounting program might contain a general ledger object along with functionsfor credit, debit, and reconcile.

    In theory, OOP made it easier for programmers to design and develop systems thatlooked like the business. The promise of OOP allowed technologists to remain in thedrivers seat from requirements through development to deployment of governmentsystems. Of course, government business units also thought OOP was great, as itpromised to give them a little more visibility into the black box of technology.

    Throughout the modern history of information technology, government businessunits have demanded greater control over what their systems look like and theirability to shape these systems. Of course, government business units want theirsystems to look and operate exactly as their businesses look and operate. SOA and

    BPM represent the continuation of this trend toward technology mirroring thebusiness.

    In fact, from a business perspective, the idea of service orientation is not a newconcept. In government, the concept of service design has been around for dec-ades. Service design in this context deals with the physical services that are pro-vided to internal and external constituents and how these services are designed.For example, at some point, someone within the Internal Revenue Service had todefine what services the organization would provide and how those services wouldbe carried out. In very much the same way, Service-Oriented Architecture is con-cerned with designing and constructing the technical services that are provided tointernal and external constituents. In many cases, these technical services are be-

    ing designed to mirror and support the physical services that are provided by thegovernmental agency.

    In the U.K., government is focused on designing better services, which oftenleads to better use of technology, reports Nick Jones, Assistant Director of theTransformation and Delivery Group within the United Kingdom Government5.Our goal is to first design a better service before we try to apply technology; ul-timately we believe this allows us to create a technical architecture that sup-ports the actual services delivered by government.

    The basic idea behind SOA is to provide a set of services that can be consumed byanyone at any time. In essence, SOA represents the latest in good systems designthat promotes the idea of delivering a black box that can be used in perpetuity byother systems and applications. In theory, any changes that need to be made insideof the black box do not impact any of the systems that are currently using it. Thisapproach supports the trend toward longer technology refresh rates within govern-ment. The black box can remain in commission as long as it is needed withoutnecessarily having to update the underlying technology. Technology updates andrefreshes can be decoupled from relying on a particular hardware, operating sys-tem, or database platform.

    Service-Oriented Architectures promise of delivering these black boxes also sup-ports governments continued trend toward outsourced technology services. As in-tegrators develop new applications, using SOA standards and frameworks, govern-

    ment can connect these systems to other applications being developed by other in-tegrators throughout the agency.

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    37/321

  • 8/13/2019 Layna Fischer Documento Integral 2007 Bpm Workflow Handbook

    38/321

    BPMAND SERVICE-ORIENTEDARCHITECTURE TEAMED TOGETHER

    37

    The IT transformation includes multi-year sequencing of improvements to IT Operations, ITInfrastructure, Information Assurance, and End User Services and achievement of the objec-tives shown in the diagram. The Troux Metix Enterprise Architecture tool is being used tosupport all phases of the agency transformation, including identification of AS IS components,definition of TO BE components, and the detailed multi-year sequencing required to achieve

    the target transformation environment. The enterprise architecture embodies the prioritizedbusiness process improvements identified through the agency Business Process Manage-ment Program (BMMP). The initial agency process selected from the enterprise architectureand BMMP for the BPM/SOA Pilot is agency contracting, which is a multi-billion dollar a yearoperation that involves interfacing with 34 different Federal, DoD, and Agency e-businesssystems.The agency Enterprise Portal uses the BEA AquaLogic User Interaction (ALUI) COTS soft-ware and it is the central interface for all agency applications. The BEA AquaLogic BusinessProcess Management (ALBPM) BPMS COTS software was selected because of its deep in-tegration with ALUI and its ability to support the transformation of agency processes throughprocess automation and integration of internal and external data, processes, and systems.The initial step in the Contracting BPMS was to conduct interviews with over 30 stakeholder

    organizations. A major part of the effort was to conduct a series of workshops to define an en-terprise level contracting process for the agency. This target process is the key enabler forprocess automation with the ALBPM modeling and design tools. A Requirements Specifica-tion was developed as well as an Interface Definition Document for the 34 Federal, DoD, andAgency e-business systems that will be integrated into the environment. The BPM modelingtool allows the agency to define all levels of the agency contracting process and identify proc-ess increments that will be implemented in phases.The target system concept is shown at the bottom of the diagram. The system will support allcontrac