With all the new technologies, how does one get started with process management or workflow? And which should one use - Automated Workflow Management or the new tools of Business Process Management?
Work management has been going on for centuries. Automated work management became popular with document image systems. With the paper records gone, it was no longer possible to assign work by putting a stack of paper in someone's in-box. It was no longer possible to look at the stack of work on the table or in the various in-boxes and determine the backlog. And with the paper gone, the work management had to take responsibility for the routing, or workflow. So automated workflow management has been around for 20 years. And in many people's minds has become an old fashioned component of an image system.
The techniques of distributed computing, especially web-based applications, have allowed business processes to be defined as a series of smaller component processes executed independently. Checking the credit rating of a buyer moved from a small component embedded in a monster mainframe order processing program to a separate application that is invoked by the primary business process - perhaps on a different computer system, or even at a different enterprise. Business Process Management is the relatively new technology to organize, manage, and reuse the steps of the business process - to take advantage of the flexibility offered by the smaller reusable components of the business process, and to control how those applications will be processed.
Two of the "old timers" in these new technologies recently had a debate. The "Business Process Management" advocate described the management of a business process. The process would be formally defined in a business process modeling language such as BPML. It would be displayed or plotted with a Business Process Management Notation such as BPMN. It would be managed and run by a business process management system, an invocation engine driven by a business process execution language such as BPEL. Communications with external processes - interoperability - would be through a facility such as WSCI (Web Services Choreography Interface). And if we needed to manage people as part of the work process, the BPMS would invoke whatever old-fashioned workflow engine was required, at the appropriate point in the process.
The "Workflow Management" advocate simply replied, "yup, that's workflow." Because the workflow technology has evolved from simply moving documents between people, to invoking processes using resources, where the process may be a person or a program, and the resource may be a computer rather than just someone in a job function. The process might be defined using XPDL, the new XML based Process Definition Language published by the Workflow Management Coalition. It might be managed and run by your favorite workflow engine (there are many products on the marketplace, beyond the simple workflow components embedded in many business application programs). Interoperability between systems (in another department or enterprise) can be handled through Wf-XML - the distributed process execution facility defined by the WfMC. Workflow still queues and prioritizes work when the resources are limited (a person is out sick or has a backlog of work) in addition to managing the "immediate" processes. Most workflow systems now incorporate totally automated processes that don't require people - sometimes called robotics or "straight through." Just like a Business Process Management tool.
If you have a completely new process, there is little question, you need to define and test the process. Be sure it is complete. Verify that all the special cases are handled. Determine what resources are required to perform the tasks. Configure to handle the workload. In other words, model it. There are a number of modeling and simulation tools available. And some of the emerging standards and techniques have been implemented in commercial products.
Some of the modeling tools can export the resulting model and "load" the process into a workflow engine or a business process execution engine to be performed. Many of the tools use XML as the language to communicate between the modeling tool and the execution system, which is very helpful. But use of XML doesn't mean that every execution tool can perform any process suggested by the modeling tool. (No more than I can do everything you ask me to do just because we both speak English.) So if we want to automatically move the model to the execution tool we need more than a common language - we need to use compatible techniques. Are there nested processes and sub processes? Is looping allowed? Can we have concurrent tasks? How do separate parts of the process rejoin to complete the process? Does any part of the process depend on what has happened before (e.g. back to the person who made the original decision - or to a different person for a second opinion)? Connecting a modeling tool to an invocation engine is far more difficult than it seems. Sometimes only a portion of the model can be automatically transferred.
Part of the reason for a model may be to simulate the process. For example, you might estimate that the computer will take 5 seconds to perform a particular function, or the person will take 10 minutes to do their job. But what if it is 10 seconds rather than 5 to get a response from the computer, and what if the person takes 8 minutes rather than 10, but makes a mistake that takes an average of 5 minutes to correct, 10% of the time? The initial guess is an interesting starting point to a simulation, but the real benefit comes from feedback - taking actual experience from the logs created by the workflow or business process invocation engine, and enhancing the simulation. Unfortunately very few tools provide this feedback in a useful, automated way.
If you are working with an existing process, it is rare that there is a formal definition of the process that accurately matches what is being performed. The cynic would even say it is rare that processes are documented at all. So the first step of planning a workflow is to examine the "As Is" flow - to record all the steps currently performed, what is done, how long it takes, the volumes involved, and so forth. Since the existing process presumably works, we can use that as the initial definition. For a typical process to be automated, an expert, working with the people currently doing the job typically can document the "As Is" model in a few weeks. This "As Is" model is then examined. If the workflow is going to be automated, then it is no longer necessary to manually log when the work is received, or when it is completed and passed to the next step. The task of "search for missing documents" should become rare. The "respond to customer inquiry about the work" should become trivial. Multiple concurrent tasks becomes practical. The "To Be" model is starting to emerge.
At this point, the "To Be" model can be entered into a modeling and simulation tool, just like new processes. Or it can be loaded into a workflow engine and tried in real life. For people-intensive processes, built on existing workflows, moving directly to a workflow implementation works well. For new processes, primarily between systems rather than people (the typical new web-based application), modeling is the only way to go.
Any work management, whether manual or automated, is subject to change. Volumes change, types of work change, processes change, environments change (whether it is the computer platform or the supervisor of the workers). Therefore any automated workflow management system must allow change. Some systems require a programmer for every change; better systems allow the supervisors to adjust their workflow "on the fly."
Within weeks of implementing a new workflow system, changes will be needed. Users will see a better way of doing things that they never considered while planning. As proficiency is gained, some processes will become much faster. Issues will be exposed that may require different approaches. But the need to change seems to be the same whether the "To Be" workflow was implemented immediately, or whether a year was spent tuning the model before trying it. So it is often better to "just do it," get the immediate benefits, save the cost of simulation, and let the managers refine the workflow while they use it.
Automated workflow management has been evolving over the last 20 years or more. There are numerous mature commercially-available products. They have withstood the test of time, and can handle the special cases that sometimes confound a newer product. They have emerged from the world with human workers, so most workflow products handle queues, half-done work, absences, and other issues that come from human workers. Most products can also handle the totally-automated robotic or straight-through processes. The workflow standards came after the products, and are built on the experience of the product developers. However, the standards can be cruel to the parents from which they were built - not every product has been changed to conform to the exact way the standards were published. The proven techniques that have been incorporated into the workflow standard are used in far more products than the number of products that may boast that they comply with the published standards.
Business Process Management technology has started with the specification, from which new products are emerging. Since the standard came before the product, there is an elegance to the design and implementation. The newer technology is often mathematically rigorous. Many of the products comply with the emerging standards, and use the latest technology. But the products are new, and if something is not in the standard, it is not in the product - some of the techniques that were important in workflow have not been incorporated... yet.
If you are a vendor or are building your own system, take advantage of the standards. They have been built on the knowledge and experience of some of the best industry experts from throughout the world.
If you are a user, it is nice if a product you like conforms to one or several standards, but there are lots of great products that do not conform, even though they may use many of the techniques incorporated in the standards. If you only consider products that meet published standards, you will exclude some great opportunities.
The reference model established by the Workflow Management Coalition many years ago has withstood the test of time, and is still a useful framework for identifying the components of a system. Although it is not perfect, it may help define the role of some of the many emerging languages and standards.
Disclaimer: All of these tools and products are evolving. Technicians who work with them full time have difficulty defining the role of each and the relation between them. Hopefully this list will still be helpful, and the one sentence definitions of each will not offend those who have spend years and hundreds of pages to do the real definition.
Interface 1 of the WfMC Reference Model represents the process definition and how the process can be transferred to a workflow engine.
XPDL is an XML based process definition language from the WfMC released in mid-2002. It provides a rigorous task definition including the data schema, properties, and interfaces.
BPML is an XML based process definition language from BPMI.org. It has a different structure than XPDL. BPMI and the WfMC are working together to see if these standards can be consolidated.
BPMN is the graphical Business Process Modeling Notation suggested by BPMI.org.
WPDL is the Work Process Definition Language from the WfMC that can be used between modeling tools and workflow runtime engines.
WSFL, Web Services Flow Language from IBM, is closely related to the IBM MQ series product. IBM has joined with others to endorse BPEL4WS, so this language (WSFL) is no longer viable.
XLang, from Microsoft, closely related to BizTalk and an extension of Web Services Definition Language. Like WSFL, this effort has been incorporated into the BPEL4WS specification, so XLANG is no longer viable.
BPEL4WS is the proposal from IBM, Microsoft, and BEA to the W3C as a process definition language - Business Process Execution Language for Web Services. Since it is closely related to commercial products, many fear that there will eventually be royalties for those who adopt it.
Interface 2 of the WfMC reference model allows other applications to call upon the workflow product at run time - embedding workflow in those applications. Interface 3 of the WfMC reference model allows the workflow engine to invoke business processing applications while it is running.
The workflow management coalition has consolidated these two portions of the specification as WAPI - workflow APIs.
WSCI - Web Services Choreography Interface is a public interface for processes that run across the web. If the interface is between the separate processes themselves, it would be considered interface 4. If the interface is between applications and the workflow invocation engine, it would be considered interface 2 or 3. An example of the challenge of making new ideas fit an existing picture.
Interface 4 of the WfMC reference model allows two different workflow engines to talk to each other - to coordinate processes. The process may be asynchronous (request that something be done, assume it will be done, and go on) or synchronous (monitor the progress, potentially alter the process such as provide additional data or cancel the process, and continue the primary process based on the results of the external process).
The initial WfMC interoperability standard was based on a MIME binding (e-mail communications technology) between the systems.
Wf-XML is the new XML based distributed process interoperability specification from the WfMC.
WSDL is the emerging XML-based Web Services Description Language from W3C. Version 1.0 is limited, but version 2 should be very interesting.
SOAP is the encoding of messages, normally in XML, for transport over HTTP (Internet protocol). It is widely used, but is a messaging tool, not a process management or workflow tool
UDDI is a tool, like the yellow pages, for publishing the services publicly available, and how to interface to them. For example, if a transportation company wanted "anyone" to be able to order shipping through them as part of their own process, they would publish the availability of their service, and the information required to invoke an automated interface to use it, in this Universal Description, Discovery, and Integration database.
BPSS from ebXML provided the semantics for inter-company communications with XML
Interface 5 in the WfMC reference model is to the Administration and Monitoring tools. Every tool must have a way of running the system, and most have pretty extensive logging and reporting, but there are few standards.
BPQL is the BPMI definition of the Business Process Query Language, for reporting on the process performed.
Business Process Management is a new technology that will help bring the components of a distributed business process together. Workflow Management is an established technology that can also bring the components of a distributed process together, but has evolved from the issues of prioritizing and managing people and other limited resources.
If the process is only between machines, either technology should work but the products that are categorized as Business Process Management tools may be simpler and more appropriate. If people are involved, either technology should work (since the BPM technology will invoke a workflow product) but a native Automated Workflow Management product may offer advantages.
But whatever is true today will be obsolete by tomorrow. So get started. It is common for automated processing (workflow management) to provide a 30 percent cost savings, while improving service and quality, so you shouldn't wait! Today's tools are great, even if tomorrow's tools will be better.
 |
This document appears as a chapter in the book, "The Workflow Handbook 2003", starting at page 257, edited by Layna Fischer. For more information on this or other editions of the book, or to order a copy (now at a greatly discounted price), go to the bookstore at Future Strategies, Inc.. |
 |
"Workflow Handbook" is part of an annual series from 2001 to present, each with entirely different content. Most are still relevant and continue to be 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 from the "Workflow Handbook 2002". |
 |
Send e-mail comments to Charlie@Plesums.com
©2003 by Charles A. Plesums, Austin, Texas USA. ALL RIGHTS RESERVED.