Does work actually flow?

Chuffed with the acuity of our analysis, we might be inclined to take a logical leap. Namely, given enough effort, we can identify definite patterns in the way work flows. We can then capture these patterns in a form that computer systems can execute. Doing so will allow us to automate those pesky workflows for the greater good of the organization.

Hmmmm. I'm not so sure. Douglas Adam's posited the existence of a planet where all ballpoint pens go to when they are lost[2]. Another Douglas (coincidence?) - Douglas Hofstadter - posited the existence of a country he called Tumbolia[3] where software goes to rest while the hardware it is running on is down.

I posit that somewhere in the rolling green hills of Tumbolia there is a valley chock-full of machine readable workflows that have been abandoned by the organizations that created them. In fact, there are so many abandoned workflows there, that Tumbolia residents want their government to ship them off to a separate planet dumping ground.

In my experience, workflows - even very complex ones - can be gross over-simplifications of the real world. In mechanizing a workflow, architects typically use concepts of task, role and transition. Simply put, a workflow is a combination of tasks. Tasks are 'resting places' in a workflow. To move a workflow from one resting place to another, somebody playing the right role must move the work along by doing something. The 'something' that they do must be a valid something per the workflow. It must result in an approved transition from one resting place to another. If you don't have the right role or if you are doing the wrong thing or trying an unapproved transition, the computer will stop you. It will beep or start sulking or turn various options of gray on you.

This is the point at which one-way tickets to Tumbolia are purchased. In the real world, workflows are not always simple combinations of states and if-then-else rules. There generally is no immovable set of roles. No inviolate set of transitions. Heck, it may not even be clear if anyone in the organization understands how the workflow actually works. Double-heck, it may not even be clear that the rules (such as they are) sit still long enough to capture them on a diagram -- never mind in a computer program.

Here in the real world, things change. Things change all the time. People play multiple roles - sometimes at the same instant -- in order to get things done. Anything can happen pretty much any time -- regardless of what the computer might think. People in the real world have to deal with it. They need to think on their feet. They adapt in order to succeed. Computerized workflow? A nice idea but get out of the way please, I have work to do...

Is this being too harsh on the idea of computerized workflows? Probably. There are times when they work wonderfully. The problem -- a recurring one in the IT business -- is to extrapolate from the simple case to the complex case in an unwarranted way.

Workflow is one area where such extrapolations can bite you real hard. I'm not convinced that the term 'workflow' does justice to the complexity of the concept it seeks to describe. Does your work actually flow? How many times does the simple case that you can articulate as the general workflow actually apply? How much of your time is spent dealing with the exceptions rather than the general rule? If the general rule rarely applies it is pretty anemic as a general rule and perhaps not a good candidate for automation.

In my experience, workflows can be a lot more complex than the simple sounding word would indicate and when in comes to automating them, it pays to assume that there are levels of unseen complexity in even the simplest workflows.

[1] http://en.wikipedia.org/wiki/Workflow
[2] http://www.funtrivia.com/en/Literature/Adams-Douglas-8815.html
[3] http://en.wikipedia.org/wiki/Tumbolia