TEAM thinks about it !!

What Is Workflow?

"Workflow" is one of those terms someone coined based on the idea that work "flows" through an organization. The visual image suggested by the term is supposed to be a boat (the work) flowing down a stream or river with the current carrying it smoothly towards some ultimate destination.

In the military when people talk about workflow they are often referring exclusively to staff work. While staff work is a workflow process, it is not the only one. Any activity that can be explicitly defined and modeled, from ordering a chair to submitting a performance report, can be automated with the right system.

The people clamoring loudest for relief at the moment, however, are mostly involved in staff work - and with good reason. Unlike that boat on the river, our staff work frequently looks a lot more like a salmon trying to swim up a waterfall.

Defining Workflow

Workflow is, first and foremost, about defining processes. Workflow process models normally have two levels of representation. The first level defines the process of the flow of work through the system. The second level represents the state of execution of a particular process, usually described as an "enactment."

For the purposes of workflow modeling, we'll assume a process consists of a name and a sequence of activities needed to execute the process.

At the next level in the process, an activity consists of a name, a set of roles and actions associated with that activity and usually a completion condition.

One thing to bear in mind at this point is some activities contain enough complexity to qualify as complete processes in and of themselves. These key activities are encapsulated within the larger process and are often the critical components whose performance will make or break the entire system. It's quite possible to model the larger process correctly but then have a workflow system fail because of a lack of sufficient detail at the activity level.

My personal preference when modeling activities is to bound them within single roles. A role is what an actor plays in the execution of an activity. An actor can be a person, a group of people, a computer program or an organization that provides the functionality for the system by executing activities.

If we define our actors' roles clearly for each activity, we'll have a better chance of defining and meeting the specific requirements of those activities. Each activity should consist of the actions executed contiguously by a single role. When the role changes, we've entered a new activity. We should be able to reduce just about any process to manageable chunks for implementation with this method. We'll talk more about roles later.

An action is a description of something to be done. "After coordinating, forward this to the next reviewer," "send an e-mail to acknowledge receipt," and "apply digital signature" are all examples of specific actions that may be executed by a person or software agent.

The tedious part of building a workflow system is ensuring that every action executed by every actor in every role for every activity in the process is accounted for somewhere in the workflow system. Each action should also satisfy an argument ("if this, then this; if that, then that") that generates further action based on a perceived (either by human or machine) value.

That's the process level. At the execution level, each iteration of a workflow process is considered an "enactment." This consists of a unique enactment ID number, a reference to the process being enacted, a reference to current activity within that process, binding actors and roles to activities and matching arguments to values.

In plain English, every time we send work through the system we should know the following at any given point in the process:

• Something that uniquely identifies each work package (ID number).
• What action are we performing? (Ordering, coordinating, modifying, etc.)
• Where are we in the process? (How many activities have we completed?)
• Who or what is currently involved in the action?
• How is the work proceeding? (Are the actors responding appropriately?)
• When is the work complete? (At any level: action, activity or enactment.)

Here's the scary part: as complicated as it appears, the description above greatly understates the difficulty of actually modeling a process with the intent of building workflow around it. In addition to explicitly defining every action in the process, particularly the ones to be automated completely, we must also define the networks of activities that specify parallel, iterative and conditional interactions between actions, actors and activities.

One thing that helps is that workflow enactments are case-based. Every piece of work we do, for example, is executed for a specific business case and almost always for a specific customer. The goal of workflow management is to handle the enactment of those cases as efficiently and effectively as possible.

So, we design workflow processes to handle similar types of cases, with workflow management being what we do to try and shepherd our work through our organizations. With that basic understanding, we will now move on to workflow management systems.