What is in a name? work+flow=workflow

More than 10 years ago Rhonda and I both worked on software platforms designed to coordinate activities within companies. Such systems have gone by many names such as "workflow," "process management," and "routing management."

I have yet to see a single marketing campaign capture the essence of the products or benefits. The focus all to often is on the technology; the work queues, reporting, control logic, rules engine, etc. This is akin to selling a car by focusing on the metallurgy of the piston heads.

The problem is that companies have three primary ways of communicating: verbal, email, and database records. With verbal communications the number of possible outcomes is infinite, limited only by the creativity of the people involved. Given a conversation about any piece of work the needs to move forward, the conversation could result in that piece of work going to literally any single person in the company. Where that is powerful on one hand, that power should only be wielded in a rare few occasions when warranted. A second problem with verbal communications is that there is no preserved historical record of the decision.

Email presents the same infinite possible outcomes as verbal conversations, though it does have the advantage of leaving a historical record for some amount of time. Often that record is limited by legal document retention guidelines which cause old email to be deleted after 6 months or 1 year.

Infinite outcomes works against what people want most companies to accomplish: consistent and repeatable outcomes. Reliability and efficiency are characteristics we look for in the companies we choose to trust with our business. We want to trust that the company will get the work done without us calling multiple times. We also want to trust the company will get the work done in a predicable amount of time.

To reign in this infinite flow of work, database systems are used for holding work requests and tracking what state the work is in. These systems often also track the history of state changes for the work. An order for a car might go through prospect, sales presentation, order received, awaiting delivery, and delivered states. The software in these systems restricts how a request changes from one state to another. These are referred to as business rules.

Companies frequently undergo strikingly similar learning curves as they mature. They first learn they are too big to operate exclusively in verbal and email communications. Work gets "lost" and customers complain. So the companies add a database to track customer requests and add states for the requests as each situation is uncovered. Next some customer issue arises that they cannot explain what happened, and the company realises the need for a change history on the customer requests. This audit trail will help them understand the history of a future request when a problem arises.

This is the point which many company systems plateau. Why try to improve from here?
First consider that to understand the progress of the company, this database can be a great asset. Reports can be created to demonstrate the amount of work the company or each department are achieving over time.

Second consider that the databases now implemented look very similar across a multitude of companies. Yes, the specific order details, materials, etc. are specific to the companies needs. The similarities exist in the request tracking and reporting. In short, there are work requests, work states, and work transitions. There is a work transition history, and reporting. This accounts for a lot of custom design and code that could be generic and cheaper.

Third consider that the business logic that controls the transition of work from one state to another is sometimes written in source code, and sometimes is a completely manual process. These both are difficult for managers to review and improve upon. In order to improve the company, we must be able to understand how the company works. We must be able to answer the question, "How does work flow through our company?"

To address this we need a system that allows us to describe the business logic that controls the transition of work from one state to another. This description would be in a format that is close to what managers are familiar with while at the same time can be interpreted by the software. This results in their only being a finite number of ways work can flow through a company.
Why has workflow management software not become a part of the standard suite of business software?

First the companies that need it don't realize the need until the are several years into the development of their own custom software. They are heavily invested down the path of implementing and using proprietary database software. Change is a daunting prospect.
Second, the companies offering workflow solutions do not promote and demonstrate solutions that can augment existing database solutions. The products are often sold as all or nothing packages.

An easier to adopt workflow system would include web service calls to denote actions on work items. The services would simply track work items, states, and transitions as arbitrary entries relating back to the customer's database. The existing database reports would still show the static state of the work, while the workflow system would offer reports to show rates of progress. Over time, business rules can be added to the service as well as small bit of user interface implemented as HTML/AJAX code snippets.

In essence, the workflow management, reporting, business rules, and workflow specific user interface components can be offered as a light weight web service based product that is easy to try out, buy, and use increasingly over time.