Workflow Handbook

Workflow Handbook

2005

Workflow Handbook 2005

_________________________________________________

Published in association with the

Edited by

Layna Fischer

Future Strategies Inc., Book Division Lighthouse Point, Florida

Workflow Handbook 2005 Copyright 2005 by Future Strategies Inc. ISBN 0-9703509-8-8 05 04 03 02 1 2 3 4 5 All brand names and product names mentioned in this book are trademarks or service marks of their respective companies. Any omission or misuse should not be regarded as intent to infringe on 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 and Workflow Management Coalition are service marks of the Workflow Management Coalition. http://www.wfmc.org. Neither the editor, Workflow Management Coalition, nor Future Strategies Inc., accept any responsibility or liability for loss or damage occasioned to any person or property through using the material, instructions, methods, or ideas contained herein, or acting or refraining from acting 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 no duty 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 #374 Lighthouse Point FL 33064 USA 954.782.3376 fax 954.782.6365 [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 by any meansgraphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systemswithout written permission of the publisher, except in the case of brief quotations embodied in critical articles and reviews. Publishers Cataloging-in-Publication Data Library of Congress Catalog Card No. 2005902352 Workflow Handbook 2005: /Layna Fischer (editor) p. cm. Includes bibliographical references, glossary, appendices and index. ISBN 0-9703509-8-8 1. Business Process Management. 2. Workflow Management. 3. Technological Innovation. 4. Information Technology. 5. Total Quality Management. 6. Organizational Change 7. Management Information Systems. 8. Office Practice_Automation. 9. Business Process Technology. 10. Electronic Commerce. 11. Process Analysis Fischer, Layna

TABLE OF CONTENTS

FOREWORD 7 Jon Pyke, Chair WfMC, United Kingdom

INTRODUCTION 9 Layna Fischer, General Manager Workflow Management Coalition, United States

SECTION 1THE WORLD OF WORKFLOW WORKFLOW IN THE WORLD OF BPM: ARE THEY THE SAME? 17

Charlie Plesums, WfMC Fellow, United States

BPMTOO MUCH BP, NOT ENOUGH OF THE M 23 Derek Miers, Enix Consulting, United Kingdom

INTEGRATED FUNCTION AND WORKFLOW 31 Chris Lawrence, Old Mutual, South Africa

BUSINESS ACTIVITY MONITORING AND SIMULATION 53 Joseph M. DeFee, CACI and Paul Harmon, Business Process Trends, United States

BUSINESS PROCESS IMPROVEMENT THROUGH OPTIMIZATION OF ITS STRUCTURAL PROPERTIES 75

Vladimr Modrk, Technical University of Koice, Slovakia

ENHANCING AND EXTENDING ERP PERFORMANCE WITH AN AUTOMATED WORKFLOW SYSTEM 91

Robert J. Kearney, Image Integration Systems, Inc., USA

NARROWING THE SEMANTIC GAP BETWEEN BUSINESS PROCESS ANALYSIS AND BUSINESS PROCESS EXECUTION 103

Dr. Setrag Khoshafian, Pegasystems Inc., USA

USING SOA AND WEB SERVICES TO IMPROVE BUSINESS PROCESS FLOW 113 Zachay B. Wheeler, Roberta Bortolotti, SDDM Technology, United States

WORKFLOW AND BUSINESS RULESA COMMON APPROACH 129 Heinz Lienhard and Urs-Martin Knzi,ivyTeam-SORECOGroup, Switzerland

STATE OF BPM ADOPTION IN ASIA 141 Ken Loke, Bizmann System (S) Pte Ltd., and Dr. Pallab Saha,, Institute of Systems Science, National University of Singapore

TABLE OF CONTENTS

SECTION 2WORKFLOW STANDARDS BUSINESS PROCESS METAMODELS AND SERVICES 159

Jean-Jacques Dubray, Attachmate, United States

WORKFLOW AND SERVICE-ORIENTED ARCHITECTURE (SOA) 179 Arnaud Bezancon, Advantys, France

A COMPARISON OF XML INTERCHANGE FORMATS FOR BUSINESS PROCESS MODELLING 185 Jan Mendling and Gustaf Neumann, Vienna University of Economics and Business Administration; and Markus Nttgens, Hamburg University of Economics and Politics

HOW TO MEASURE THE CONTROL-FLOW COMPLEXITY OF WEB PROCESSES AND WORKFLOWS 199

Jorge Cardoso, Department of Mathematics and Engineering, University of Madeira, Portugal

AN EXAMPLE OF USING BPMN TO MODEL A BPEL PROCESS 213 Dr. Stephen A. White, IBM Corp., United States

A SIMPLE AND EFFICIENT ALGORITHM FOR VERIFYING WORKFLOW GRAPHS 233 Sinnakkrishnan Perumal and Ambuj Mahanti, Indian Institute of Management Calcutta, India

ASAP/WF-XML 2.0 COOKBOOKUPDATED 257 Keith D Swenson, Fujitsu Software Corporation, United States

SECTION 3DIRECTORIES AND APPENDICES WfMC Structure and Membership Information 281

AppendixMembership Directory 283

Appendix-Officers and Fellows 289

AppendixAuthor Biographies 307

Index 317

Other Resources 320

1

Foreword

Jon Pyke, WfMC Chair, United Kingdom Thank you for supporting the work of the Workflow Management Coalition. It never ceases to amaze me just how much progress can be made in a 12-month period. My concerns during 2004 were that the ever-increasing numbers of stan-dards bodies in my industry were doing a great job in confusing the market place, holding back growth and putting us in danger of becoming just an-other over-hyped trendy sector. Well, things have certainly changed, and changed for the better. I am no longer concerned for the future of Workflow and Business Process Management technology. Over the past year the dis-cussions over which standard fits where has abated, and we now have a clear understanding of direction. The increase in the term BPM is however causing confusion in the minds of manydoes it mean Business Process Measurement? Business Process Modeling? or Business Process Measurement? It is clear that all of these terms are valid so the challenge now is to ensure that those responsible for the development of products, associated standards and the promotion of three-letter acronyms articulate the message crisply and clearly and ensure they say what they meanand thats part of the job of this publication. The development of standards is now moving at some considerable pace, and this is especially true with the XPDL standard also known by WfMC as Inter-face 2. Soon to see its second major version released, XPDL is recognized as a key component of the standards landscape. The working group responsible for the standard, led by Robert Shapiro, has made some significant advances especially in mapping the specification into the works of other standards groups such as the BPMI. The growing list of XPDL supporters and imple-mentations from both the vendor and user community can be found on our website. Led by Keith Swenson, WfMC TC Chair, several times during 2004 the WfMC assembled a live demonstration of products that implemented the Wf-XML 2.0 web commerce protocol. Wf-XML is a protocol for process engines that makes it easy to link engines together for interoperability. Wf-XML is built upon OASIS ASAP, so it was simultaneously a demonstration of ASAP inter-operability. The demonstration showed six different implementations of the new web ser-vices protocol and the exchange of data across the Internet. These demos were both in front of the live audience and online with observers around the world via a webcast, each time with sold-out capacity. A live demonstration led by Keith Swenson took place in Pisa, Italy in Octo-ber 2004 at which we hosted a local BPM Workshop open to the first 100 attendees, as well as another 600 on line. Participants who implemented the protocol included ADVANTYS, Fujitsu, HandySoft and TIBCO who demon-strated the scenarios of Customer, Retailer and Manufacturer. ASAP and Wf-XML are designed to be used by non-programmers. This is the key.

FOREWORD

2

More details on the demonstrations are available elsewhere in this book in the chapter: ASAP/Wf-XML 2.0 CookbookUpdated by Keith Swenson. Significant milestones for WfMC in 2004 have been the continuing adoption of our standards and specifications by government and big business world-wide. Notably, the United Kingdom e-Gov National Workflow project issued a workflow official standards guide assisted greatly by David Hollingsworth, TC Chair from the Workflow Management Coalition. More information on this workflow guide is available on their website, www.workflowNP.org.uk. The WfMC Standards Reference Model has proved its importance in other areas of technology, most notably the ISO Seven Layer reference model for computer communications. The members of the Workflow Management Coalition hope you enjoy our Workflow Handbook 2005 and find it useful as you explore workflow and business process management and their many diverse benefits. Our thanks go to everybody who contributed to this important body of work and to Layna Fischer, WfMC General Manager for her role as chief editor and publisher. Jon Pyke, Chair WfMC

9

Introduction

Layna Fischer, General Manager Workflow Management Coalition

Welcome to the Workflow Handbook 2005. This edition offers you:: SECTION 1: The World of Workflow covers a wide spectrum of

viewpoints and discussions by experts in their respective fields. Papers range from an examination of the workflow in the world of BPM to Web Services workflow architectures and Business Process Management Technology and Business Rules.

SECTION 2: Process Standards deals with a comparative analysis of XML standards, with a visionary look into the future of the service-oriented architecture. Several examples detail important step-by-step instructions of generating processes, such as using the BPMN specification to model a BPEL process. The ASAP/Wf-XML 2.0 Cookbook has been updated following several successful live demonstrations of the protocol.

SECTION 3: Directory and Appendicesan explanation of the structure of the Workflow Management Coalition and references comprise the last section including a membership directory.

Section 1The World of Workflow WORKFLOW IN THE WORLD OF BPM: ARE THEY THE SAME? 17 Charlie Plesums, WfMC Fellow, United States This introductory chapter describes how workflow management systems are no longer just a simple inventory of work to be processed, or a simple rout-ing system, but have become sophisticated process management tools. Sys-tem tools have emerged to help analyze and design complex new business processes. Other tools, the invocation engines, run the process as defined. Specifically these engines invoke transactions on systems both internally and across many organizationssuppliers, partners, and customers. Busi-ness Process ManagementBPMis born.

BPMTOO MUCH BP, NOT ENOUGH OF THE M 23 Derek Miers, Enix Consulting, United Kingdom The problem with many BPM deployments is that they often overlook the reason why this technology is needed in the first placeto support the achievement of business objectives. The re-emergence of business processes as a core discipline in modern business management is fairly clear. But in order to really derive the maximum benefit from BPM initiatives, firms need to manage the people interface more carefully.

INTEGRATED FUNCTION AND WORKFLOW 31 Chris Lawrence, Old Mutual, South Africa Mr. Lawrence discusses designing and building computer systems based on the process modeling methodology called integrated function and workflow (IFW) systems. A key claim of the approach presented in this chapter is that

INTRODUCTION

10

it keeps the business model and the solution model aligned because they are one and the same model. The subprocess concept and construct is an impor-tant factor in that alignmentwhich is effectively the alignment between what and how.

BUSINESS ACTIVITY MONITORING AND SIMULATION 53 Joseph M. DeFee, CACI and Paul Harmon, Business Process Trends, United States Gartner suggests that BAM will become a major corporate concern in the next few years. Most large organizations will at least explore the possibility of improving business process management by creating systems that provide a broad overview of a process that can provide near-real-time information and advice to process managers. A variety of techniques will be used. The au-thors believe that simulation-based BAM will prove to be the most powerful and flexible approach to BAM and will increasingly be relied on by those with the more complex processes.

BUSINESS PROCESS IMPROVEMENT THROUGH OPTIMIZATION OF ITS STRUCTURAL PROPERTIES 75 Vladimr Modrk, Technical University of Koice, Slovakia With the growing requirements for the improvement of business activities within organizations, aspects of changes and new concepts of process struc-tures are becoming a topical problem. These aspects are evenly important from standpoint objectives of the first out of two phases of workflow man-agement (WfM). The processes of change have been addressed mostly at the level of administrative business processes (BP). Apart from main intention to present a practicable approach to the measurement of the structural com-plexity of business processes, the chapter also outlines some conceptual as-pects of the effectiveness of the creation of practical tools for business proc-esses redesign consisting of modeling and subsequent analyzing of processes structural attributes.

ENHANCING AND EXTENDING ERP PERFORMANCE WITH AN AUTOMATED WORKFLOW SYSTEM 91 Robert J. Kearney, Image Integration Systems, Inc., USA ERP systems are most commonly and correctly perceived and utilized as transaction processing machines. In that role they excel. Workflow systems, integrated with the ERP system, can function as the data delivery mecha-nism for ERP transactional processing. Conversely, ERP transactional proc-essing is but one of the many activities in the workflow. Mr. Kearney de-scribes how the integrated result provides capabilities that have been miss-ing with ERP alone: standardization and automation of entire business proc-esses, effective involvement and interaction with the business experts, and, the creation and capture of all relevant business process information. The improved business processes enable the promised economies of scale from centralized ERP processing.

NARROWING THE SEMANTIC GAP BETWEEN BUSINESS PROCESS ANALYSIS AND BUSINESS PROCESS EXECUTION 103 Dr. Setrag Khoshafian, Pegasystems Inc., USA The business process management (BPM) industry is growing rapidly, sur-passing the expectations of even its most ardent supporters. Like most new technologies, BPM is enduring its own growing pains thanks to convergence, consolidation, and accelerated adoption. One of the critical areas of conver-

INTRODUCTION

11

gence that has not received sufficient attention is the semantic gap and in-teroperability challenges between business process analysis (BPA) tools and intelligent BPM engines. This interoperability challenge is further aggravated by the lack of robust business rules modeling tools. Business rules are now regarded as essential components of a next generation BPM (intelligent or smart BPM). Even though there are various BPM standardization efforts, the semantic gaps between BPA and run-time intelligent BPM engines are con-siderable. This paper addresses these semantic gaps and identifies solutions for continuous and iterative development of complex intelligent BPM applica-tions.

USING SOA AND WEB SERVICES TO IMPROVE BUSINESS PROCESS FLOW 113 Zachay B. Wheeler, Roberta Bortolotti, SDDM Technology, United States Case Study: District of Columbia's Oracle Database, Presentation Layer, SOAP/XML. Tasked with the analysis of improving and automating the cur-rent business process of license issuance for the Department of Consumer and Regulatory Affairs (DCRA) of the District Columbia, the SDDM Technol-ogy team developed Business Logic and Data Access Tiers. The solution to the District of Columbia business license problem was provided by using Service-Oriented Architecture and Web Services, taking advantage of a wide variety of available technologies. WS SOA allows business people in the DC government to consider using an existing application in a new way or offer-ing it to a partner in a new way, thus potentially increasing the transactions between agencies.

WORKFLOW AND BUSINESS RULESA COMMON APPROACH 129 Heinz Lienhard and Urs-Martin Knzi,ivyTeam-SORECOGroup, Switzerland The authors propose a BPM approach for addressing processes, Web Services and the use of business rules by the processes, starting from graphical models. Transparent, easy to manage and mathematically sound solutions are obtained in a coherent way. The authors show that practical experience with Business Rule Management within BPM will have a beneficial influence on the further development of BPM technology. What is already possible to do now will become very easy to do in the future, e.g. totally integrated calls to rule management from process elements (like event starts, process triggers, decisions (gateways in BPMN) etc). As well, rule inference may become a natural part of these systems.

STATE OF BPM ADOPTION IN ASIA 141 Ken Loke, Bizmann System (S) Pte Ltd., and Dr. Pallab Saha,, Institute of Systems Science, National University of Singapore There will be an exponential growth in the adoption of BPM technologies within ASEAN companies, say the authors. The way businesses and the marketplace are evolving will fuel this adoption. Acadamicians, consultants and solutions vendors are working together to bridge viable deliverables in various forms for ASEAN companies to adopt BPM. Companies have recog-nized the need to equip their workforce on process excellence. The intense competition and time to market factors further put pressure for companies optimize their current processes. The authors show how observing corporate governance in different degrees is something that most enterprises are taking seriously.

INTRODUCTION

12

Section 2Workflow Standards BUSINESS PROCESS METAMODELS AND SERVICES 159 Jean-Jacques Dubray, Attachmate, United States The software industry has long searched for a computing model where busi-ness or work processes would be explicit and where customers could change the business processes without significant coding projects. Programming languages like WS-BPEL, Service orientation and web service technologies represent a major architectural advance to create a new generation of busi-ness process engines that can integrate with a wide variety of business func-tions and across business boundaries going far beyond the original concepts of business process orchestration that were defined in the late ninetiesi and have hardly evolved since then. Mr. Dubray contends that this new genera-tion of process engines is expected to manage end-to-end business processes while being far more flexible, far more business savvy and far more inte-grated with all aspects of IT as was laid out the business vision in the past 20 years. These concepts are poised to revolutionize software engineering and the way we build business applications.

WORKFLOW AND SERVICE-ORIENTED ARCHITECTURE (SOA) 179 Arnaud Bezancon, Advantys, France Service-Oriented Architecture is clearly the solution for organising information systems, responding on various levels to new development and communication challenges in applications. The work involved in system migration and choosing the appropriate moment to effect this migration are the main obstacles to rapid implementation in companies. Bezancon maintains that workflow, BPM and SOA are therefore not competitors but the proliferation of marketing and techniques surrounding automation of processes are such that solutions are particularly difficult to understand from the client companys point of view. He predicts that in this particular context, those solutions presenting tools which are easiest to implement and use will almost certainly have the highest rate of success.

A COMPARISON OF XML INTERCHANGE FORMATS FOR BUSINESS PROCESS MODELLING 185 Jan Mendling and Gustaf Neumann, Vienna University of Economics and Business Administration; and Markus Nttgens, Hamburg University of Economics and Politics This paper addresses heterogeneity of business process metamodels and re-lated interchange formats. It presents different approaches towards inter-change format design and effects of interchange format specification first. The authors derive the superset of metamodel concepts from 15 currently available XML-based specifications for business process modeling. These concepts are used as a framework for comparing the 15 specifications. The authors aim to contribute to a better comparison of heterogeneous ap-proaches towards BPM, with the hope that this may finally result in a BPM reference metamodel and a related general interchange format for BPM.

HOW TO MEASURE THE CONTROL-FLOW COMPLEXITY OF WEB PROCESSES & WORKFLOWS 199 Jorge Cardoso, Department of Mathematics and Engineering, University of Madeira, Portugal The major goal of this chapter is to describe a measurement to analyze the control-flow complexity of Web processes and workflows. The measurement is to be used at design-time to evaluate the complexity of a process design

INTRODUCTION

13

before implementation. In a competitive e-commerce and e-business market, organizations want Web processes and workflows to be simple, modular, easy to understand, easy to maintain and easy to re-engineer. To achieve these objectives, one can calculate the complexity of processes. The complex-ity of processes is intuitively connected to effects such as readability, under-standability, effort, testability, reliability and maintainability. While these characteristics are fundamental in the context of processes, Prof. Cardoso illustrates that no methods currently exist that quantitatively evaluate the complexity of processes.

AN EXAMPLE OF USING BPMN TO MODEL A BPEL PROCESS 213 Dr. Stephen A. White, IBM Corp., United States The Business Process Modeling Notation (BPMN) has been developed to en-able business user to develop readily understandable graphical representa-tions of business processes. BPMN is also supported with appropriate graphical object properties that will enable the generation of executable BPEL. Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation. This paper presents a simple, yet instructive example of how a BPMN diagram can be used to gen-erate a BPEL process.

A SIMPLE AND EFFICIENT ALGORITHM FOR VERIFYING WORKFLOW GRAPHS 233 Sinnakkrishnan Perumal and Ambuj Mahanti, Indian Institute of Management Calcutta, India The main contribution of this chapter is that a new workflow verification al-gorithm has been proposed to verify structural conflict errors in workflow graphs. This algorithm is presented along with visual step-by-step trace of the algorithm, correctness and completeness proofs and complexity proofs. Workflow verification issues have been solved in a simple and elegant man-ner by the proposed algorithm. The authors show how this algorithm is much easier to understand, as it uses search based techniques like Depth-First Search and has significant advantages in terms of time complexity when compared to other workflow verification algorithms available in the lit-erature.

ASAP/WF-XML 2.0 COOKBOOKUPDATED 257 Keith D Swenson, Fujitsu Software Corporation, United States Wf-XML is a protocol for process engines that makes it easy to link engines together for interoperability. Wf-XML 2.0 is an updated version of this proto-col, built on top of the Asynchronous Service Access Protocol (ASAP), which is in turn built on Simple Object Access Protocol (SOAP). This chapter is for those who have a process engine of some sort, and wish to implement a Wf-XML interface. At first, this may seem like a daunting task because the specifications are thick and formal. But, as you will see, the basic capability can be implemented quickly and easily. This article will take you through the basics of what you need to know in order to quickly set up a foundation and demonstrate the most essential functions. The rest of the functionality can rest on this foundation. The approach is to do a small part of the implemen-tation in order to understand how your particular process engine will fit with the protocol.

INTRODUCTION

14

Section 3Directory and Appendices The Authors Appendix provides the contact details and biographies of

the valuable contributors to this book. Each is a recognized expert in his or her respective field. You may contact them if you wish to pursue a discussion on their particular topics.

The chapters on the WfMC Structure and Membership describe the Coalitions background, achievements and membership structure and sets out the contractual rights and obligations between members and the Coalition

WfMC Membership Directory: WfMC members in good standing as of February 2005 are listed here. Full Members have the membership benefit of optionally including details on their products or services.

The WfMC invites you to delve into the information presented in whatever manner suits your reading or research style and knowledge level. Our thanks and acknowledgements extend to not only the authors whose works are published in this Handbook, but also to the many more that could not be published due to lack of space. Layna Fischer, Editor and Publisher General Manager, WfMC

Section 1 The World of Workflow

17

Workflow in the World of BPM Are They the Same?

Charlie Plesums, WfMC Fellow, United States

WORKFLOW In the Middle Ages, monks sat at tables carefully copying the scriptures. The father superior would make the assignments, perhaps giving the illumi-nated first page of a section to the most skilled artist, perhaps assigning the proofreading tasks to the elderly scholar with trembling hands.1

Little has changed in centuriesthe process is established, work is assigned and tracked, performance is checked, and results delivered. Often it is done by manual effort of supervisors (even today). But automated tools have emerged to assist.

WORKFLOW MANAGEMENT Document imaging emerged as a practical technology in the mid-1980s. When the images were stored in a computer system, there no longer was any paper to drop in somebodys in-boxno natural way to assign and track the work. The initial simple workflow management tools routed the work to the person (or sequence of people) that needed to process the documents. The early workflow management systems were intimately associated with the contentthe documentthat was being moved or routed.

The workflow management tools evolved to assign priorities to different types of work, to balance the distribution of work among multiple resources (peo-ple) who could handle the work, to support interruptions in the work (Ill fin-ish it in the morning), and to handle reassignment (Im sick and am leaving now).

Not all work was associated with a document, so most workflow management systems were adapted (if necessary) to process work that had no documents, images, or attachmentspure process, without content. For example, renew-ing an insurance policy or changing a credit limit.

Not all processing steps required a person. Therefore most current workflow management systems support straight through processing or robotics. For example,

As part of a larger process, one person may enter data from an order or application. When the entry is done and necessary data is avail-able, the workflow system may automatically requests a credit report from a system in another company. When the report is received, the manual or automated process continues.

The entire process may be automated. An address change may be de-tected (perhaps on the payment stub), so is automatically sent to an OCR process. If the address recognized from the form is a valid ad-dress in the postal database, the change is made, and a confirmation

1 Introduction to Workflow, Workflow Handbook 2002, page 19

WORKFLOW IN THE WORLD OF BUSINESS PROCESS MANAGEMENT

18

letter is sent to the customer. A person is only involved in an errorif the data cannot automatically be verified.

Thus workflow management systems are no longer just a simple inventory of work to be processed, or a simple routing system, but have become sophisti-cated process management tools. They originally assigned documents to people for processing, so most products have special strength assigning longer tasks to people, with one or many attached documents, but the viable workflow management systems have gone far beyond their historical origins.

BUSINESS PROCESS MANAGEMENT Business has become more complex in recent years. Many processes extend outside the organizationeven outside the enterprise. Some of the steps that traditionally were handled internally are now being outsourced to busi-ness partner companies or individual contractors. Suppliers of products and services can be more economical and predictable when they are inte-grated into the larger process.

System tools have emerged to help analyze and design these complex new business processes. Other tools, the invocation engines, run the process as defined. Specifically these engines invoke transactions on systems both in-ternally and across many organizationssuppliers, partners, and customers. Business Process ManagementBPMis born.

The new BPM tools have been defined top down rather than simply evolving (like most workflow management tools). The techniques used to define the process are more rigoroussome people take pride in being able to describe the mathematical foundation behind the various techniques. Graphical maps, modeling, and simulation are common tools to define the process. In production, the invocation engines will use the latest technology (including the Internet) to pass data and invoke processes on local and remote systems within an organization, between different organizations within an enterprise, and between enterprises.

ARE BPM AND WORKFLOW THE SAME? Both Business Process Management and Workflow allow a process to be de-fined, tested, and used. BPM originally focused on computer transactionsthe large number of rapid business processes most often handled entirely by machine. Workflow originally focused on content that required human judg-ment or processing, often distributed among large numbers of people, with each process taking a relatively long time, thus being subject to interruption. Both BPM and Workflow can handle the entire range of business processes. The question is how well each product works in each situation.

BPM is focused on defining the overall business process, and managing and tracking that process wherever it goes, often through multiple organizations, different computer systems, multiple locations, and even different enter-prises. However, each transaction is normally quickthe request to get a credit report may need to be queued until morning, but when run, the re-sponse is immediate. There may be only one system that performs a particu-lar transaction, and when it is run, it is rarely interrupted. Since processing is fast, most can be processed on a first-in, first-out basis. BPM is optimized for processes that are automatic, not involving human interaction.

Workflow is focused on managing the process also, but often has compo-nents of uncertainty and delay such as those associated with people. We


19

may have to send the "work" to someone for approval, but that person may be interrupted (suspending the work while they take a phone call, go to a meeting, or even return from vacation). There may be many (even hundreds) of different processors (people or systems) that could handle that particular piece of work, and any one processor may be able to process many different types of work (but not the same combination as the next processor). The to-tal work must be equitably distributed among the many processors. Some of the processing may take many minutes or hours, so more important work (the bigger deal or the better customer or the older work) may be given higher prioritybe assigned first. The workflow is often modified as the per-son seeks additional information (such as a lab analysis or a legal opinion) for this particular case. Quality needs to be checkednot just is the system operating reliably, but are the people making mistakes. (Beginners may have 100 percent of their work checked, but an expert may only have a few per-cent checked.) Most workflow products can invoke programs automatically (without human intervention) like the BPM engines, but are optimized for the multiple processors and delays in the process. But many of the workflow products on the market today aren't (yet) as focused on the cross-enterprise or inter-enterprise processes as the BPM tools.

We could conclude that both workflow management products and BPM prod-ucts manage a business process, so in that sense they are the same. These products may be very different internallyand thus the strengths and weaknesses of those products in a particular application can be very differ-ent.

Many workflow vendors have integrated BPM products into their workflow packages, but the degree of integration is sometimes lim-itedthe product still is primarily a workflow tool.

Many BPM vendors have discovered the special needs of workflow, and have either integrated a workflow product into their BPM pack-ages, or have built-in rudimentary workflow functions.

EMBEDDED WORKFLOW Many computer systems, such as those that process orders or administer insurance policies, have recognized the value of workflow. Therefore many of these systems have embedded workflow among the functions provided by their system. The good news is that this is a fast and convenient way to get started in workflow. The bad news is that it may only have a minimal set of workflow functionalityjust enough to perform that specific application in an unsophisticated way. The workflow functions of a dedicated enterprise workflow system are likely to be much more robust than those that are em-bedded within a specific application.

One person rarely works with a single application all day, every daysome of their time may be spent substituting for a supervisor, or quality checking other peoples work. Some companies mix assignments between back office mail processing and front office call center work. Some time will be spent in training or even developing new work management procedures. Work may arrive from the telephone, internal or external email, from the paper inbox, or from the workflow system. People do not do well balancing the work from multiple sourceswhile working on email, they will likely respond to all the email, even if more important work is waiting in the workflow system or in-box. This leads to an argument for a separate enterprise (or desktop) work-


20

flow systems, that balance the work between multiple business functions and systems.

STANDARDS The Workflow Management Coalition reference model, below, defines five components of workflowthe five interfaces to the workflow enactment ser-vices (what BPM calls the invocation engine). The standards associated with these interfaces are listed in the standards section on the WfMC website at www.wfmc.org. Understanding the five components helps distinguish be-tween BPM and Workflow systems.

WfMC Interface 1 is the process definition. This is the starting point for BPM and the particular BPM component that has received a lot of analysis and development. Workflow products vary in the techniques and tools used to define the processsome products use third party tools, if any, for analy-sis of the process, or use custom programs or simply manually generated tables to define the business process for the processing engine.

WfMC Interface 2 is the client applicationthe program that invokes the workflow process. Workflow tools have a strong history of human interface, so may be stronger in this aspect; BPM is traditionally focused on processes

Workflow Enactment Services

Process Definition

Tool

Workflow Client

Application Invoked

Applications

Workflow Engine(s) Vendor A

A2

A1

2 3

Other Work-flow Enact-ment Ser-

vices

C B Admini-

stration &

Monitoring

1

45

WfMC Reference Model


21

that require less human interaction, and may have a stronger programming interface. Some BPM products have no human interface at allany human interaction must be custom programmed.

WfMC Interface 3 is the interface to the programs invoked by the business process. The first workflow systems presented documents to people for proc-essing in their traditional way (none of the processes to be performed by the people were automatically invoked). Workflow vendors quickly learned that they needed at least a minimal interface to expedite the processstart the right program for the user, even if the data all needed to be entered manu-ally. Eventually most workflow tools evolved, and can invoke local and re-mote processes, but that interface must often be customizedit is an add on to many systems. On the other hand, BPM is built to automatically in-voke existing systems, using consistent, modern interfaces. BPM products generally excel here, except when dealing with archaic legacy systems that dont support the modern interfaces and tools.

WfMC Interface 4 allows one workflow system to talk to another workflow system to initiate work on another system (perhaps a different vendors system in a different enterprise), to track the status (progress) of that work, to cancel the work if necessary, and to inquire or be notified when the work is complete. BPM invocation engines generally dont talk to other engines, but would invoke a transaction at another enterprise, and that transaction might, in turn, initiate a local process. Either approach gets the job done.

WfMC Interface 5 is for administration and monitoring of the system, in-cluding logging, monitoring the performance and backlogs, and adjusting the resources. Both BPM and Workflow have these functions. But this is an area that deserves attention.

CAUTION One organization decided that their systems needed to be modernized across the entire enterprise, using new technology to link the home office and re-gional offices to their vendors and customers. They selected a BPM product, installed all the system components, and trained all the staff.

The first application dealt with processing documents, from the customer through several regional offices, to home office specialists. Their BPM prod-uct didnt naturally link to documents, but that could be added. Their BPM product didnt have a user interface for the regional and home office staff to query the status of their work queues, but that could be built. Their BPM product didnt have the ability to suspend work, allow a supervisor to over-ride the assignment of work, or to automatically prioritize work (some work was more urgent than others).

All of these requirements could be added to the platform provided by the BPM product. But this process could have easily been implemented by many traditional workflow systems, with little or no customization. The BPM solu-tion may have been the best overall solution for the company, but workflow tools would have been much better to solve this first application.

In another environment the problem might have had minimal human inter-action, electronic data rather than documents, and processes that involve a more complex organizational structure. A workflow tool may accomplish the job, but BPM products might be easier to implement and perform better for this process.


22

There is no simple answer. This certainly doesnt mean that Workflow is bet-ter than BPM, although it probably would have been for the one business process in the first case. Not does it mean that BPM is better than workflow, even though it might have been so in the second case. It does mean that the business requirements need to be honestly identified, and both BPM and Workflow products need to be considered.

CONCLUSION The key issue is the business process, and how that process works for the business users, partners, suppliers, and customers. BPM and Workflow are both technologies that manage the definition, implementation, and operation of the business processes. One is not good and the other bad, but they come from a different origin, and thus have different strengths. The key is to look beyond the product name, and find the functions that will best serve the business.

23

BPMToo Much BP, Not Enough of the M

Derek Miers, Enix Consulting, United Kingdom

INTRODUCTION In the 1990s, I used to say, The problem with workflow is that you dont want it (work) to flowyou want it to get done. The point was that, rather than having cases of work ping-ponging all over your business, the emphasis should be on getting work done.

Generally, the reason companies were deploying workflow technology was to drive operational efficiencyto save cost while improving consistency and quality. Workflow also promised a way of dealing with the cultural malaise that had infected organizations over a certain size. But the reality of deploy-ment in many large financial services businesses was that they just got into a bigger mess faster. Sure, many tasks were automated and streamlined to remove delays from the process. But the culture of the organization was sel-dom fundamentally changed. The body politic of the firm just absorbed the technological change and carried on as before.

What firms were often missing was a methodology for dealing with the day-to-day grind of managementproduction and how to get the most out of the available resources. Even now, most firms still have only a superficial appre-ciation of how much work their employees are capable of handling.

With a workflow implementation, the problem shifted. The visible backlogs of bulging in-trays were now hidden within the shared queues on the system. Individuals were driven (handed work) by the system but were seldom meas-ured or managed in terms of what they could realistically achieve.

Deployments took little account of the skill levels of the individuals. Some could achieve work at a tremendous rate, while others struggled to achieve the norm. At the team level, there was no sense of driving performance or the achievement of goals or business targets. Out-of-the-box, management in-formation was simply unavailable in workflow products. While the system logged the history of all work (audit trail), it was left to the customer to write suitable programs that provided managers with effective informationi.e., while management information was often promised, it was seldom delivered.

BPM TODAY And it is not much different today. All that has really changed are the terms. Now its called Business Process Management (BPM) rather than workflow. But in the same way that workflow implementation often missed the point, so do many BPM deploymentstoo much emphasis on the BP and not enough on the M.

The problem with many BPM deployments is that they often overlook the reason why this technology is needed in the first placeto support the achievement of business objectives. They set out to deliver the ability to en-sure that work is doneconsistently, on time, and correctly. Yet they miss

BPMTOO MUCH BP, NOT ENOUGH OF THE M

24

one of the key ingredients to corporate successthe day-to-day management of the people involved. This is not about the life-cycle management of the process itself, which is still important. It is about the management of the people who work within the processwhat their collective efforts can achieve, where they are struggling, how much work is coming down the pipe, and what they have to get out the door today, tomorrow, this week, or by the end of the month. The capability to steer the detailed operations of the busi-ness by driving its business processes (through BPM) is one thing, but de-veloping an effective production management discipline is another.

Technological support for this aspect is usually left to manual spread-sheetsan afterthought, developed by the managers themselves. While this may be good enough for a couple of small teams, it just doesnt scale to 300 teams of 20 people. Indeed, most white-collar businesses have no accurate idea of what sort of work throughput is possible with the resources they al-ready have. Executives continually hear the cry for more staff, yet they dont really know how much work the current employees can deliver. Our research in major financial services firms has shown that as much as 30-40 percent additional productivity is possible when a disciplined production manage-ment approach is employed (over and above the benefits possible from the core workflow/BPM implementation). This research was based on a series of detailed interviews with key executives within the core business and IT man-agement functions of major financial services firms in the UK and Europe. Firms ranged in size from 120 to several thousand employees.

The primary focus of the analysis was to understand the critical success fac-tors associated with major BPM deploymentshow these affected productiv-ity and the goals of executive management. In all cases, the businesses con-cerned had already deployed business process support environments. We really wanted to understand the issues that affected how one firms BPM im-plementation was more successful than that of another. What did they do different? What best practices were developed? How was it driven and man-aged?

We found that senior managers often bought into the idea of a BPM deploy-ment based on not only increased productivity and better consistency, but also on the Holy Grailbetter Management Information. They really wanted the ability to look into the end-to-end profitability of a product or service, drilling down to assess, compare, and contrast the impact of one channel over another, or how individual departments were performing against Service Level Agreements (SLAs). They wanted the ability to track and monitor their business, identifying teams that were failing or quickly spotting bottlenecks that were impacting performance. They also wanted the ability to ensure adequate adherence to new regulatory requirements.

A CASE STUDY Halifax plc (now merged with the Bank of Scotland to create HBOS) is an in-ternationally famous financial services brand. Responding to the challenges of the modern high street, their re-organization involved taking the back of-fice functions out of their many branches and creating centralized admini-stration centers. To support this exercise, process support systems were im-plemented to drive work from the front office operations in the high street directly into the back office.


25

The initial emphasis was on the BPM technology implementation, its features and usability at the front end. Significant benefits derived from the initial consolidation project with around a 15 percent reduction in costs. While some new management information was made available as a result, there was little change in the way that first line managers operated across the business.

However, through a subsequent project, focused on the introduction of pro-duction management disciplines, the company transformed the whole cul-ture of management. Rather than looking at team performance from a his-torical point of view (as was the norm), managers now predict what work is possible with the resources at their disposal. Previously, managers looked at what level of achievement they had delivered and then justified why they couldnt handle any more. To support this new project, the core BPM system was extended with an innovative Management Information application that also took over the allocation and distribution of work, marrying the needs of the case and business priorities back to the skills of the employees in the individual teams.

First line managers are now driven to understand how much work they have in the system and what is likely to arrive. In turn, this has allowed them to think more deeply about the performance of the individual team members, assessing their skills and personal development in a more holistic way. Indi-viduals are assigned work within their capabilities and monitored against performancein terms of task completion but also qualitatively.

Managers are held accountable against weekly plans and asked to predict productivity over the ensuing 12 weeks. A league table is maintained, and individual team leaders are now incentivised to (over)achieve realistic per-formance targets through the staff under their control. The end result is a further 20 percent productivity improvement over the previous year alone. Week on week output is still rising and the costs of doing business are being driven ever lower. With over 2000 fulltime staff in the back office alone, that 20 percent improvement equates to 400 man-yearsa big impact on the bot-tom line of the business. Moreover, the company has achieved a real trans-formation in management culture, building a virtuous circle of corporate performance, team working, and personal development.

But none of this would have been possible without an alignment of incen-tives with the enhanced technology support environment. The product used to extend the BPM environment, Work Manager from eg Solutions in the UK (www.eguk.co.uk), provided a further layer of sophistication over and above the core capabilities of the BPM Engine. It allowed the business to develop a single view of work in the business, integrating the core BPM environment with other workflow systems and applications.1

1 We have since discovered that this same application is relatively widely used in the UK financial services market, working alongside leading BPM products such as Staffware, FileNet, AWD, and eiStream (now Global 360). In some im-plementations, Work Manager is integrated with two or three different BPM en-vironments, providing a single view of all work in the business and allowing management to track work across processes rather than just functional silos.


26

In the words of the Head of Retail Processing for the bank (talking about the BPM deployment), You end up with brilliant processes, but the people in-volved cant necessarily handle them. The organizational culture is left a mile behind, and the people side suffers. We had the systems and process part working well, but the behavior and people side slipped. The real issue was developing a new set of management behaviors.

DONT FORGET THE PEOPLE There is an important lesson here. In a great many BPM projects, there is plenty of emphasis on the Business Process, but the wider holistic aspects of people, culture, and production management are often overlooked, yet they are just as important. As far as functionality goes, it is not a huge difference, but the lack of a manage & control and understand & improve culture makes a big difference to performance and bottom line profitability. BPM cannot be considered complete without it.

All of the over-performing companies we surveyed sought to create a culture of continuous improvement. At the core of that objective were two common strategies:

The application of production management techniques, and The extraction of quality management information.

From the executive point of view, the overall objective was generally sublime operational efficiencyreducing the level of resources required to deliver value. They also wanted more meaningful information to support decision-making and better adherence/compliance with corporate policies and proce-dures.

PRODUCTION MANAGEMENT & REGULATORY COMPLIANCE Production Management is really all about seven things: Measure; Plan; Communicate; Allocate; Monitor; Analyze, and Improve. While all this just sounds like plain, old-fashioned common sense to the seasoned manager, it has almost been lost in the hullabaloo created around the Business Process end of BPM. Having understood what their people are capable of and planned accordingly, team leaders need to track and monitor how well they do against targets.

People need to know where they fit. When they understand this, they are far more motivated, especially if they can clearly grasp the basis for their indi-vidual targets and see that their achievements are fairly reflected. One mort-gage firm we spoke with had achieved a particularly dramatic rise in produc-tivity. With a new set of work practices and service level targets in place for six months, throughput rose by an average 221 percent per day (in the number of applications processed), and the number of actual completions carried out increased by a massive 429 percent. These changes have trans-lated into a more profitable company with lending increasing from 220 mil-lion in the whole of 2001, to 620 million of completions in the last nine months of 2002 alone.

In the words of another senior manager (from one of the worlds leading mul-tinational insurance groups): Our people now understand that a service level agreement is not a target that we aspire to, but a benchmark below which we will not fall. Introducing SLAs is an opportunity to make rapid and


27

lasting cultural changes within an organization, whilst bringing people with you. Everyone knows what he or she has to achieve. They now understand what good looks like.

Of course, there is more to it than saying managers need to monitor their employees. What came out in our interviews again and again was the need to align the people to the work in hand and then monitor them individually. This implies assessing an individuals skills and competencies against that required by the task. However, understanding peoples expertise and profi-ciencies is almost an art in itself. While this is relatively easy with a small team, when you consider the scale required for several thousand customer service staff and their associated back office support, a technological founda-tion is a must. On the other hand, the cost of getting this alignment wrong is usually not considered until it is too late.

In the UK mortgage market during the late 90s, many firms oversold en-dowment related insurance policies that paid off the mortgage at term. Across the industry, the costs associated with handling related complaints have now run into hundreds of millions of pounds.

If firms had delivered that work to suitably qualified personnel in the first place, they could well have avoided the current cost repercussions that are having a serious impact on business and product profitability.

Sure, some of the issues I am highlighting with this example are related to initial product design and a responsible sales process, but the whole finan-cial services industry is now governed by a much stricter regulatory regime. Firms have to meet stringent new targets on handling customer complaints within a given deadlinei.e. managers need to know when they are unlikely to achieve this. But more importantly, organizations must now ensure that the individuals handling sensitive parts of the sales and administrative proc-esses are qualified to undertake the work.

Stricter regulatory regimes are not limited to just the financial services in-dustry. With the introduction of the Sarbanes Oxley legislation in the US, most large firms need to ensure compliance in all sorts of ways. Firms are also struggling with the new focus on transparency and compliance. The widely held perception is that greater control of the process will ensure regu-latory compliance. While the underlying BPM technology provides an effec-tive audit trail (logging the history of all work items), seemingly small errors in the way a case is handled can have a massive impact on the brand.

But the reality is that routing a work item through the business, using rules to get it to the right role (job title), is just the first step. Modern financial markets demand transparency and accountabilityon what we do, how we act, and the decisions we makethrough every level of the business. With this transparency comes increased risk to the public trust in the brand. But transparency is only about finding out afterwardsmanagement via the rear view mirror. What is needed is a more proactive approach. A methodology that ensures employees have the right capabilities and training to undertake the work in hand. And to realistically achieve this goal, a more holistic view of the business is required.


28

MANAGEMENT INFORMATION As the use of procedural rules to route work moves all firms towards com-moditization, differentiation will increasingly be based on how the processes are managed. Managing the life cycle of the process itself is certainly impor-tant, but we found that managing the groups of people interacting with those BPM systems is of equal importance. And managing people in such an envi-ronment requires that decisions are based upon good information.

Virtually every BPM solution one looks at promotes the idea that, by using their technology, customers will get better management information. The audit trail provides all the information youll needa complete history of the work item including who handled it when, what information was changed, etc. But because these products are focused on the needs of the business process life cycle, businesses are left to reflect on their own special needs for Management Information.

With the right information gathering and reporting regime, the business can more easily sense important changes in the market and customer behavior, changing the process if necessary. But all that process flexibility will not do you much good unless you optimize the resources at your disposal. Based on a better understanding of operational capacity, managers can make more informed decisions, adjusting resource levels in different departments; effec-tively load balancing the business in line with peaks and troughs of demand. While this sounds a little like a return to the days of Bigger People Reduc-tions (BPR), during our interviews we found that, with more accurate Man-agement Information, a greater sense of reality prevailed. In some instances, this led to redeploying or recruiting extra staff to manage the work within the desired service and quality levels. Employees are now focused on targets set against several factors including effectiveness, quality, and product knowl-edge. With the core BPM environment, all that was really monitored was throughput.

Firms seeking this sort of sophistication have three alternative optionsbuild your own (i.e., write suitable programs on top of the BPM package), deploy a package with the core Production Management and Management Information components, or plug in a high-end Business Intelligence appli-cation such as Hyperion or Comshare. While many BPM vendors claim to provide the requisite Management Information, most leave it to the customer to write suitable programs to reflect their own special reporting needs. Some BPM tools do provide their own built-in analytics capabilities capturing av-erage cycle times of processes and activities, or how long work items wait before moving on to the next activity. This information is useful for finding process bottlenecks, but often does little for the day-to-day grind of extract-ing management information to support production or supervision at the team and individual level.

When it comes to building your own management information, the problem is that you first of all have to understand all the key business issues and problems. Moreover, a deep appreciation is needed of the relationship be-tween day-to-day operations and effective reporting. You also need to be aware of the technological implementation issues and then develop your own methodology for deployment amongst the workforce. Indeed, developing an


29

appropriate implementation methodology that embeds the cultural change is a major part of the battle.

With BI solutions, the emphasis is largely on financial reporting. Products tend to focus on the provision of an executive dashboard with a 360-degree view of all metrics. This information is largely underpinned by operational metrics, but its purpose is primarily overall financial performance. Again, support for the day-to-day needs of production management is largely lack-ing. When considering packaged implementation, we found only one product that seemed to cover the whole spectrum. Work Manager from eg Solutions provided a pretty comprehensive approach. Their customer references pointed to the products superior work allocation features, providing inte-grated management information with features for monitoring work through-put at the individual and team levels. This has left managers with more time to address process bottlenecks rather than simply detecting them. Managers were also more able to focus on value-added functions, so time saved on rou-tine tasks such as work allocation was channeled into addressing customer needs.

CONCLUSION The re-emergence of business processes as a core discipline in modern busi-ness management is fairly clear. But in order to really derive the maximum benefit from BPM initiatives, firms need to manage the people interface more carefully. Through a focus on this area, successful firms have derived as much as 40 percent additional productivity improvement over and above that achieved by initial process automation using a BPM engine. In order to achieve these sorts of benefits, firms need to adopt a wider, holistic set of principles surrounding the BPM initiative. They need to institutionalize this as a way of thinking. Thinking that delivers real, tangible results and long-term benefits.

31

Integrated Function and Workflow1

Chris Lawrence, Old Mutual, South Africa I want to talk about designing and building computer systems based on the process modelling methodology previously outlined in this book. I shall call them integrated function and workflow (IFW) systems. The significance of each of the words in this description should become clear as the rest of this book unfolds, so I wont try to steal my own thunder by attempting a sum-mary explanation now. It is possible to design computer systems in which the concepts of process, subprocess, task, and so on are themselves the basic building blocks. The immediate advantage of this is that the eventual system design matches the business design. This simple correspondence brings enormous benefits, with implications on a number of levels. Some of the implications can be quite profound. But before explaining how to design a computer system from a business process model, I need to introduce a specialised piece of software which makes it possible. This is the workflow engine or process engine. But be-fore I do that, I must talk a bit about current workflow systems. I am not claiming that any component calling itself a workflow engine will do the job. But nor am I claiming that the kind of workflow engine the ap-proach needs is radically different from any workflow engine currently avail-able. Most if not all of the features which an IFW system needs in its work-flow engine would be found somewhere in todays workflow technology. I will not be describing workflow engines, or any particular workflow engine, at the technical level. But I will cover the essential business functionality of the kind of workflow engine an IFW system needs. I want to do this in enough depth to make it quite clear what architectural component is re-sponsible for what feature of any eventual solution.

Workflow systems Software systems configured as workflow engines have been around for a while, and there are many workflow systems on the market. There is an entire industry dedicated to designing and perfecting workflow systems, and to deriving and maintaining standards in workflow technology. The standards include protocols allowing workflow systems and workflow-enabled applications to talk to each other. To an extent however this indus-try has a particular kind of workflow system in mind. This is primarily a separate application operating alongside (and therefore external to) other business applications, and not necessarily communicating with them. This isnt to say it rules out the type of workflow which is fully integrated into the business application, but that the paradigm case is of functional separation.

1 Excerpted with permission from the forthcoming book Make work make sense: An in-troduction to business process architecture by Chris Lawrence

INTEGRATED FUNCTION AND WORKFLOW

32

There are a number of reasons for this, some good, some not so good. One good reason is that a business or organization may have a number of system applications, for example a core administration system, an accounting pack-age, and, say, a human resources/payroll system. They may then have a single external workflow system which manages work done on (ie user inter-actions with) all these systems. If an entire business process spans a num-ber of systems, the advantage of a functionally separate workflow system is that the entire process can be implemented in the one workflow implementa-tion. This brings consistency and comprehensiveness. A less good reason is historical. Workflow is a relatively new technologynewer than a lot of the mainframe systems which dominate many of our banks, insurance companies and government departments. So there was obviously a ready market for workflow systems designed to operate in paral-lel with, or on top of, and therefore external to, those legacy systems. Turning now to what these packaged workflow applications do, I think it is fair to say that their principal functionality focuses on the routing of links to electronic (scanned or text) documents and the management of work related to those documents. As a result there are now many reasonably sophisticated administration op-erations which see themselves as functioning as paperless offices. But their business processes are actually implemented in a mixture of procedure manuals, independent electronic models, peoples heads, and these work-flow packages. Their business processes are only partially implemented in the routing of links to electronic documents. This is because sometimes the two are the same and sometimes they are not:

There is another type of workflow which is a lot more internal. Many application systems have a workflow component which may be of greater or lesser sophistication. This workflow component often consists of little more than control over the status (or status code) of a particular mas-ter record, for example an insurance policy master record. This will exercise a degree of workflow control over (say) new business administration, but the same control may not be extended to other areasclaims, investment in-structions and so on. This second type of workflow is often called embedded workflowfor fairly obvious reasons. This book is principally concerned with a third type of workflow. I shall call this intrinsic rather than embedded or external workflow. Architecturally, both embedded and external workflow are afterthoughts. Embedded work-


33

flow is an afterthought built into the data and functional design of an ad-ministration system which is normally functionally complete and coherent without it. External workflow is even more of an afterthought, one that is literally layered onto a pre-existing applicationregardless of how much in-tegration is then done to make the two layers communicate with each other. Perhaps the best way to characterise intrinsic workflow is to turn the IT clock back, and try to imagine what might have happened if workflow sys-tems had appeared first, and record-keeping systems only afterwards. Sys-tems might then have been designed with their primary objective being to model, support, control, direct and record the work passing through the business, and only their secondary objective being to carry out the data processing, record keeping and document generation which was the work itself. Although the intrinsic workflow design pattern did not apply in the past, it will be increasingly important in the future. Even where external workflow makes sense as a unifying layer over disparate legacy systems, intrinsic workflow can serve as a model to which de facto enterprise (compromise?) architectures will aspire. Specification and interoperability standards will be as necessary in this world as in the current world. Where appropriate in this book I will employ the standards and terminology of the Workflow Management Coalition (WfMC), which is where the words process, subprocess and task originate. (WfMC uses task as an alternate to activity.) Having said that I am using subprocess in a slightly specialised sense. The reason for this I hope I shall make plain later on, when we get onto incre-mental automation. Further comparisons between external and intrinsic workflow are drawn in a later section entitled IFW and classic workflow compared.

Workflow engine The WfMC literature includes a detailed survey of features displayed by a workflow engine or, more broadly, a workflow enactment service. I do not want to replicate these descriptions here. Instead I want to discuss in gen-eral business terms the features which a workflow engine would need in or-der to animate and articulate the kind of systems this book is about. It is unlikely that anything here will contradict a standard like that of the WfMC. These features are summarised below.

Data The workflow engine will need its own database to support a number of spe-cific data structures. I will go through these in turn.

Process model These will be primarily the concepts already introduced, plus some support-ing entities:

Process (instance) Process type

Eg order handling; insurance claim. Subprocess (instance) Subprocess type


34

Eg take order; check order. Task (instance) Task type

Eg manual take order; automatic check order; automatic follow up.

Task class Eg manual; automatic etc (others may be needed later).

The data model diagram below shows the relationships between these enti-ties.

The individual instances of the subject entity will be the individual caseseg order 123 going through the order handling process. There will also need to be rules, attributes, and possibly additional entities, to allow processes of different types to be assembled from the appropriate subprocesses and tasks, in the right sequences, and with the correct rout-ing.

Users and access There will be more to say about tasks later on, including the features of manual versus automatic tasks. For now we shall just say that the main functionality of the systems discussed here will be at task level. So this will be where information about different users access rights will need to be ap-plied. Different users will have access to different task types. The data model therefore needs to be extended:


35

(In practice access may also need to operate at levels lower than task type. An example is where user A may be able to authorise requests captured by user B, and user B may be able to authorise requests captured by user A; but neither user A nor user B can authorise requests they themselves cap-tured.)

Workflow information Workflow information here means information about where all the current process instances are at any time, and historic information about what task in what subprocess was performed when for what subject entity. In the case of manual tasks, the historic information would also include what user was involved at what point. So current state information would be for example that subject entity 123 is in process ABC and has a current workflow status of awaiting X, where X is the subprocess (or task within the subprocess) which that process instance has reached.


36

Historic information would be for example:

Process instance

Process Sub process

Task User Date/ time started

Date/time finished

Task result*

Order 123 Order Take order

Manual take order

Fred 10-1-2001; 09:00:00

10-1-2001; 09:30:00

Next Subprocess

Order 123 Order Check order

Auto check order

N/A 10-1-2001; 09:31:00

10-1-2001; 09:31:02

Next Task


Manual correct errors

Fred 10-1-2001; 10:00:00

10-1-2001; 10:15:00

Next Task


Auto check order

N/A 10-1-2001; 10:16:00

10-1-2001; 10:16:02

Next Subprocess

Order 123 Order Check credit rating

Auto credit check

N/A 10-1-2001; 10:20:00

10-1-2001; 10:20:02

Next Subprocess

etc

Task result If, as a result of what has taken place in the task, the next move is to the next subprocess, then we shall say the task result is next subprocess. If instead the result is that the next move is to another task in the same sub-process, we shall say the result is next task. In practice the result next task may need to be supplemented with an indi-cation of which next task to route to, as there could be more than one choice, but well keep it simple for now. There may also be other possible task results later, but for the moment we shall only consider these two. So for example the only possible task result for Manual take order is next subprocess, as there is nowhere else for the or-der to go. Then if the order passes all the validation rules in Automatic check, the task result is again next subprocess. But if as a result of errors the order has to be routed to the Manual correct errors task, then the task result is next task.

System information We said above that in an actual IFW system the functionality itself is all con-tained at task level. In fact even that wasnt strictly true. Just as a process is effectively a container for one or more subprocesses, and a subprocess is a container for one or more tasks, so a task is a container for one or more pro-gramsand it is those programs which are the real functionality level. To prevent any misconceptions, the expression one or more programs is only so as not to make assumptions about the implementation environment. Each task would normally be implemented by one logical program, even if this consists of a number of different components, subroutines and so on.


37

The same logical program could however easily implement more than one task. The data model is therefore further extended:

Functionality The workflow engine will also need to do a number of things, as well as un-derstand its database.

Handle tasks A fundamental thing the workflow engine will have to do is handle task in-stances: both manual and automatic tasks. Both classes have slightly differ-ent requirements depending on whether or not they are the first in the proc-ess. To explain how the workflow engine handles various categories of tasks will involve explaining the generic features of the tasks themselves. This makes up a big part of the design of an IFW system.

Manual task at the start of a process A manual task at the start of a process would normally be the way the rele-vant process beginsfor example entering an order or an insurance claim. In fact most manual tasks in IFW systems, and in particular manual tasks which start processes, are like traditional on-line data entry programs whose job is to capture data and create and/or update records in a production da-tabase. And just as traditional data entry programs need to be made available to cer-tain users and not others depending on the users access rights, so manual tasks which start processes will normally be accessible from some sort of


38

menu customised in accordance with the logged-in users access rights. In an IFW system this is typically a function of the workflow engine itself. So the workflow engine would be able to present each logged-in user with the list of processes that user is allowed to start: a process menu. Then, by the time the relevant manual task has completed, and as a result has captured enough data to start the process, the workflow engine would have created an instance of the correct process in its database. It would then follow the routing rules for the process of that type to deter-mine what the next task should be. Following the order process example, since the subprocess take order only has that one manual task, the routing will be to the next subprocess, in which the first task is the automatic check task. Having said all this, it is also possible for a manual task at the start of a process to behave like one after the start of a process (see below) and not be started from the process menu. There will be an example of this in the case study.

Automatic task at the start of a process This would normally be where a process is not only triggered by another process, it also uses data captured by that other process. The first task of the triggered process can therefore be an automatic task which operates on the data captured by the process which triggered it. There is an example of this in one of the main processes in the case study.

Automatic task after the start of a process The automatic check order task is an example of an automatic task after the start of a process. The initial manual task will have completed, and the workflow status of the relevant subject entity will have been set to awaiting check order. The workflow engine makes the next task available, which is Automatic check. Make available means effectively place on the job queue. The workflow engine therefore needs scheduler logic to decide what task in-stance gets processed next. This will use data including priority or frequency parameters held at the task type and/or task instance level. A fairly simple type of logic is that the workflow engine processes task in-stances in strict order of effective date/time. Thus each task instance gets created with an effective date/time, and the scheduler processes any task whose effective date/time is less than or equal to the current date/time, in strict order of effective date/time. Task instances can be created to run at a particular time in the future by setting their effective date/time in the future. One common way of doing this for automatic follow-up functionality is by setting a time constraint. The rule would typically operate at task (type) leveleg to set the effective date/time of all instances of that task type to a week following the current date/time. The constraint itself (the future effective date/time) would be at task instance level. So for example a task type of auto follow up might have a time constraint of seven days. An instance of task: Auto follow-up created at (say) 10:00:00 am on 3 March 2003 would have its effective date/time set to 10:00:00 am on 10 March 2003. The workflow engine would run the task at (or as soon as pos-sible after) 10:00:00 am on 10 March 2003.


39

The more normal task types which are not post-dated in this way would therefore have a default time constraint of zero. It is possible to implement other types of constraints, for example conditional constraints (only action if such and such is true). It is also possible to implement more complicated priority algorithms into the workflow engine if required. An automatic task is like a batch program processing a file of data with only one logical record in the file. In outline, the responsibilities of the workflow engine in this context are as follows:

Decide when it is the turn of this automatic task instance to run. When its turn comes, call the appropriate (logical) program and cause

it to be supplied with the appropriate data. The appropriate data will be identified from the subject entity.

When the program has processed that instance, act on the task resultif next subprocess, then route to the next subprocess; if next task, then route to the appropriate next task in the same subprocess. (In practice route to means creating a record on the appropriate workflow table identifying the next task instanceeither the first task of the next subprocess or the relevant next task in the same subprocessand therefore placing the next task instance on the job queue.)

Manual task after the start of a process Take the example of the Manual correct errors task in the Check order sub-process. The Automatic check task has run and found errors in the captured data. It returns a result of next task. The only possible next task is Manual correct errors. Just as in the case of an Automatic task after the start of a process a task instance record will need to be put on the appropriate workflow table. This will identify the subject entity instance (either directly or via identification of subprocess and process), the task type, and the task class. In this case the task class is manual. Therefore a user has to action it. Which user? Any user with the appropriate access rightscontrolled by the task access table. How will these users access the task instance, and how do they know it is there to be actioned? This brings us to another important workflow feature, that of the in tray. This is another familiar way in which workflow systems interact with users (and vice versa). Whereas the process menu enables users to start proc-esses (of types they are allowed to start), the in tray presents users with in-stances of (manual) tasks from processes which have already been started. The instances will be of task types the users are allowed to perform. They may well be from processes someone else (or something else) has started. An example of a Manual task after the start of a process is manual under-writing. Someone else (eg a new business clerk) may have started a new business process for application number 123. When application number 123 reaches the underwriting subprocess the business rules decide it needs to be underwritten manually, by an underwriter of level 2. The routing within the


40

process will then ensure that a task instance for application number 123 will appear in the in tray of one or more underwriters of level 2. Different workflow systems distribute work in different ways, and they may be flexible in how they do this. In one paradigm the task instance for appli-cation number 123 will appear in the in tray of all level 2 underwriters. As soon as one of them picks application number 123 off his in tray it will no longer be available for any others. In another paradigm there could be a work distribution algorithm which allocates work across users in accordance with skill levels, current workloads etc. Another variant of the distribution algorithm paradigm is where there is no in tray as such. The workflow engine not only allocates manual task in-stances between individuals, it also controls the order the individuals proc-ess the tasks. In this paradigm the user is only given one task instance at a time. See also Distribute work below. It is worth mentioning that there are two overall logical categories of manual tasks which are waiting to be performed. One is of tasks which can be done immediatelyfor example the manual underwriting case. The other category is of manual tasks which can only be performed when a particular external event occurs. An example is of a manual task which can only be performed when a reply is received from a customer. Manual task instances also sometimes need to be post-datedie created so they appear on users work queues (in trays) not immediately but at some time in the future. As with automatic tasks, this is done by applying a time constraint at the task type level.

Distribute work Work allocation algorithms have already been mentioned (Manual task after the start of a process above). Workflow systems will often have functionality to allow managers and super-visors to manipulate in trays, reallocate work and alter task access rights to ease bottlenecks and generally spread work appropriately across the avail-able resources.

Record data Another important job the workflow engine has is to record information about tasks as they happen. Information about subprocesses and processes can normally be derived from task-level data. Example data items are:

Task type Eg manual underwriting; automatic check order

Task class Manual or automatic

Date + time started Date + time completed User

(Or, more generically, resource) Task result

Next task; next subprocess;


41

Display data It may not necessarily be the responsibility of the workflow engine itself to display data. But it will need to make the data available for query and dis-play. This will cover both historic data (work which has happened) and data about work still to be done. This data will need to be accessed for a number of reasons, including both work management (how much work is there in the system; what has been allocated to whom) and also customer service (contact management; history of work done for particular customers; and so on).

Incremental automation We can now draw a number of threads together to introduce another power-ful feature of the architectural approach. The example will be the order process discussed earlier. We need to imagine a context where the system has been implemented initially with a relatively low level of automation, but with an intention to enhance the system incre-mentally thereafter. This minimal principle can apply to all processes in the system, and all subprocesses and tasks in each process. But to illustrate what I mean I shall focus on one particular subprocess, that of check credit rating. For conven-ience the relevant process diagram is repeated below.

Match againststock

+

Authoriseorder

+

Despatchorder

+

Check credit rating

Automaticcredit check

Manual creditcheck

Automaticfollow up

Manualrecord

documents

meets criteriaof 3, 4 or 5approved

(rule 3)

pass1 or 2

written to customer(rule 4 or 5)

Checkorder

+

Take order

+

I now want to consider how the Check credit rating subprocess may be de-veloped incrementally, by going through a number of iterations. For reasons of illustration, the example will be fairly extreme.


42

There were some fairly intricate business rules involved in the check credit rating subprocess. Incremental automation will to a large extent mean pro-gressive implementation of those rules.

Iteration 1 In the first iteration the subprocess would consist of just two tasks, both of which would have minimal function

Documents

Workflow Handbook