Guidelines for Selecting Processes for Workflow Automation

One of the big uncertainties for an organization considering the use of or evaluating a workflow automation tool is the tractability of the chosen process to automation; this affects the success of the automation effort and the favorable evaluation of the tool. This short white paper is intended to give you some very general guidelines as to the types of business processes which would make good candidates for a pilot project, and how to go about selecting a process and how to automate it successfully. The field is new and literature is scarce; the references provided will be useful if you decide to delve deeper into the subject.

Business Process Reengineering versus Business Process Improvement

Business Process Reengineering (BPR) represents a much more radical philosophy than Business Process Improvement (BPI). For people on the outside, there is a lot of confusion between the two, and they are often used interchangeably. However Business Process Reengineering is highly politicized. Some quotes by Michael Hammer, one of the firebrands of BPR sound like rehashed Lenin, Mao, etc., complete with violent rhetoric. (The Hocus Pocus of Reengineering, Paul A. Strassman, June 1994.), whereas BPI seems more common in Japanese companies and large organizations with long-term goals. BPR can evolve into BPI.

What are your goals?

Reduction in expenses isn't the only place to look for improvements. Cycle times, throughput, customer/job satisfaction, and quality improvement can also be important goals. (Business Reengineering at CIGNA Corporation, J. Raymond Caron, Sirkka L. Jauvenpaa, Donna B. Stoddard; Management Information Systems Quarterly , Sept. 1994.)

What kinds of processes are tractable to workflow automation?

Take account of informal and formal communications channels when designing workflows; when informal adjustment/accomodation is in fact how work gets done, then the emphasis should probably be on improving archiving and information exchange rather than on defining complex workflow routes. Perhaps surprisingly, direct charismatic supervision (contrasted to a bureaucracy) has a high level of informal communication: complex workflows work best for processes which have a well-established process or bureaucracy.

Route-Oriented versus State-Oriented

Route versus task -oriented analysis can produce a very different-looking picture. Workflows are generally analyzed (and tools are usually tailored similarly) into either a route-oriented  or a document state  paradigm.

Route-Oriented

Route-oriented analysis focuses on the steps in the process, and the decision that is made at each step. In practice, route-oriented systems often bear a strong resemblance to e-mail systems. They often have a GUI-based route editor which shows the actors and the decisions.

State-Oriented

State-oriented analysis focuses on the valid states for documents, and (typically) visibility attributes for those states. The workflow, as a process, is not the focus of the analysis. State-oriented workflows can be implemented in any SQL database by the judicious use of views which select based on various critieria in addition to the database login name.

Combining workflow with document management is not coincidental

"..the fact that all researched [for this paper] systems have ... a combination of a workflow system and a document information system is not coincidently [sic, probably artifact of the translation to English]" (Workflow Automation in Four Administrative Organizations, Gaston J.A. Aussems, Nov. 1994; University of Twente, Netherlands. PostScript available at http://www_is.cs.utwente.nl:8080/~joosten/workflow.html) and the implication is that often a solution was first sought for the archiving problem; furthermore workflow automation and document archiving are synergistic. The particular methodology used to do the analysis of the process being automated is much less important than that the analysis is being done; bottom-up and top-down approaches can both succeed. The visibility into the automated process can defuse the inherent "big brother" aspect if used wisely.

Designing a useful workflow

Focus on workflow steps (event/actor) as a responsibility, not only a process; for instance this allows more than one person to participate in a workflow step, as long as there is a single point of responsibility. A workflow step (object of activity) may not be contained within the document passed through the workflow; that may be nothing but instructions or supporting documentation. A workflow step may involve phone calls, a meeting, writing a letter (to someone outside the workflow) as well; again, this is best captured if a workflow step is viewed as the responsibility for completing the step.

"An event is carried by an object" (Aussems, op cit.), the object being what is passed from step to step in the workflow instance, the event being the symbolic encapsulation of the entirety of the purpose of the workflow process. Workflows are triggered by causes: for instance the submission of a damage claim or the admission of a patient to a hospital. Obviously only some of the resulting activities can be encapsulated in a piece of software, hence the need to focus on a workflow step as the responsibility for the completion of that step. "Workflow tools do not add functionality to applications, but focus on the coordination of work between those applications." (Aussems, ibid.)

It is suggested that one way to determine what constitutes a workflow step (normalizes it) is that completing the activity results in considering what to do next; this implies that except for extremely simple routes (ad hoc workflows), routes encapsulate some major process decisions, but perhaps not minor ones; in fact, ad hoc workflows may then be the result of just such consideration on a case by case basis.

The importance of "Intelligent Documents"

As previously mentioned, workflow automation software is about process in a pure sense -- not information, which is actually what software applications have been traditionally written to address. In your typical mainframe environment, knowledge of routing or process is embedded in the application or module used at each step of the process: the application knows to get its input from here and send its output to there. Workflow automation software takes that knowledge of process and makes it visible and manageable.

But it doesn't replace the other functions of such software, including what are referred to in information processing argot as edit checks. You may design your workflow to be used in such a manner that the information processing functions which it addresses are carried on externally, which is to say that just as a step may involve making a phone call it may also involve using an existing mainframe application, or a word processor or spreadsheet. But if you actually perform information processing in an object passed along the workflow, you may want to consider whether you want to embed some of those edit checking "smarts" in that object, or what new kinds of objects might enhance the automated workflow.

You may want to consider using a Microsoft Word 6 form, or an Excel spreadsheet with locked cells, or a Clarisworks document of some sort, or even a Filemaker Pro database. Done correctly, you can have a semi-automated final step in the workflow which extracts the information from such a form and adds it to a database; technology today supports macros in all of those applications which could be used to extract the useful information "at the click of a button", and the trend is to make operating system environments fully scriptable via such means as Applescript and OLE. Such smart documents can also be used to query a database or log onto a system at one or more points in the workflow.

Are there any ways to tell in advance if this project will succeed?

Effectively using new tools/software/methods often requires changes to business processes.

Deploying workflow software as a sophisticated e-mail system or world wide web analogue is a way to familiarize users with the product, but does not make effective use of it; this is backed up by experiences with groupware at other organizations and is widely documented in the literature. Effective use occurs when groupware tools are focused on improving or reengineering a business process.

Important guideposts:

1. Being clear on the process to be reengineered.
2. Everyone should understand the fundamental case for change; ownership should exist at all levels.
3. Visible commitment from management/leadership and frequent review.
4. Historical evidence of the success of leadership methods chosen.
5. Pick the right key people to work on the process, not necessarily the "usual suspects".

("Should You Take the Reengineering Risk?", Andrea Ovans, Datamation ?, Sept. 15, 1995? http://www.datamation.com/PlugIn/issues/sept15/09bmg100.html)