"In the Middle Ages, monks sat at tables carefully copying the scriptures. The father superior would make the assignments, perhaps giving the illuminated first page of a section to the most skilled artist, perhaps assigning the proofreading tasks to the elderly scholar with trembling hands.
Little has changed in centuries – the 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.
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 somebody's in-box – no 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 content – the document – that 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 (people) who could handle the work, to support interruptions in the work (I'll finish it in the morning), and to handle reassignment (I'm 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 attachments – pure process, without content. For example, renewing 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,
Thus workflow management systems are no longer just a simple inventory of work to be processed, or a simple routing system, but have become sophisticated 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 has become more complex in recent years. Many processes extend outside the organization – even outside the enterprise. Some of the steps that traditionally were handled internally are now being "outsourced" to "business partner" companies or individual contractors. Suppliers of products and services can be more economical and predictable when they are integrated 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 internally and across many organizations – suppliers, partners, and customers. Business Process Management – BPM – is 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 rigorous – some 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.
Both Business Process Management and Workflow allow a process to be defined, tested, and used. BPM originally focused on computer transactions - the large number of rapid business processes most often handled entirely by machine. Workflow originally focused on content that required human judgment 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 enterprises. However, each transaction is normally quick – the request to get a credit report may need to be queued until morning, but when run, the response is immediate. There may be only one system that performs a particular 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 components of uncertainty and delay such as those associated with people. We 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 total 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 priority – be assigned first. The workflow is often modified as the person seeks additional information (such as a lab analysis or a legal opinion) for this particular case. Quality needs to be checked – not just is the system operating reliably, but are the people making mistakes. (Beginners may have 100% of their work checked, but an expert may only have a few percent 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 products manage a business process, so in that sense they are the same. These products may be very different internally – and thus the strengths and weaknesses of those products in a particular application can be very different.
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 functionality – just 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 embedded within a specific application.
One person rarely works with a single application all day, every day – some of their time may be spent substituting for a supervisor, or quality checking other people's 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 sources – while working on email, they will likely respond to all the email, even if more important work is waiting in the workflow system or inbox. This leads to an argument for a separate enterprise (or desktop) workflow systems, that balance the work between multiple business functions and systems.
The Workflow Management Coalition reference model, below, defines five components of workflow – the five interfaces to the workflow enactment services (what BPM calls the invocation engine). Understanding the five components, represented by arrows in the diagram, helps distinguish between 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 process – some products use third party tools, if any, for analysis 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 application – the 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 that require less human interaction, and may have a stronger programming interface. Some BPM products have no human interface at all – any 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 processing 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 process – start the right program for the user, even if the data all needed to be entered manually. Eventually most workflow tools evolved, and can invoke local and remote processes, but that interface must often be customized – it is an "add on" to many systems. On the other hand, BPM is built to automatically invoke existing systems, using consistent, modern interfaces. BPM products generally excel here, except when dealing with archaic legacy systems that don't 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 vendor's 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 don't 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, including 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.
One organization decided that their systems needed to be modernized across the entire enterprise, using new technology to link the home office and regional offices to their vendors and customers. The 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 product didn't naturally link to documents, but that could be added. Their BPM product didn't 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 didn't have the ability to suspend work, allow a supervisor to override 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 solution 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 interaction, 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.
There is no simple answer. This certainly doesn't mean that Workflow is better 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.
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.
This document appears as a chapter in the book, "The Workflow Handbook 2005", starting at page 17, edited by Layna Fischer. For more information on this or other editions of the book, or to order a copy, go to Future Strategies - futstrat.com.
The annual "Workflow Handbook 2001," through "Workflow Handbook 2004," each with entirely different content, are still available as books or in CD form. They are published by Future Strategies Inc., Lighthouse Point, Florida, USA.
Back to the home page at www.plesums.com
Back to the Work Management index at www.plesums.com
Go to the Introduction to Workflow by Charlie Plesums, from the "Workflow Handbook 2002", pages 19-38.
Go to the Getting Started in Workflow by Charlie Plesums, from the "Workflow Handbook 2003", pages 257-262.
Send e-mail comments to Charlie@Plesums.com
©2005 by Charles A. Plesums, 5702 Puccoon Cove, Austin, Texas 78759 USA. ALL RIGHTS RESERVED.