« How to abuse your software investments | Main | How not to be outsourced (and keep your job) »

What?  The Chair of the Workflow Management Coalition, and former CTO (and designer) of Staffware, saying workflow sucks?  Yes, it's true.  Check out the home page of The Process Factory, of which Jon is President.

Jon is not exactly noted for reluctance to rock boats.  But this statement seems particularly challenging.  I'll look more closely at Jon's message, and the content of the white paper he recently published, in a moment.  But first, we need to step back a bit.

Consider my post last week, How to abuse your software investments, in which I asserted that the deluge of new Internet tools known as Web 2.0 is actually a disadvantage to most organizations.  People are spending more and more time using these sexy new programs and devices without having any way of measuring the contribution to business goals made by such use.  As a result, most organizations are wasting more staff time than ever before.  Hardly the spirit of "extreme competition" needed in the new and challenging 21st century business environment!

To take just one example of such time wasting, here is a quote from the BBC, to which Jon himself drew my attention:

It’s not unusual for office workers to spend as much as two hours a day, every day, sorting and reading all the mail which pours into their in-boxes, let alone the time they have to spend responding to it.

How much is this contributing to personal or organizational goals?  I've written about the problems of corporate email before.  But email is just one example of how human work is actually being hijacked by new workplace technology.  Blogs, wikis, mailing lists, forums, intranets, chat, Web search, .... how are you measuring the operational (dis)advantages resulting from use of such tools in the workplace?

Here is a picture of where most organizations are now:

The underlying problem (and here we are getting closer to Jon's message) is that traditional work management tools - such as workflow - are of no help at all here.  You might think of workflow et al as "Work 1.0" and current knowledge-focused, collaboration-intensive, and innovation-driven work practices as "Work 2.0".  Here is a picture of where organizations need to go:

The key element of this picture is the blob in the middle, Human Interaction Management System, or HIMS.  What is an HIMS?  And why do we need one in order to implement what Jon's white paper calls Knowledge-Intensive BPM, or KIBPM - to control fundamentally important business activities such as Project Management and Case Management?

Let's start with the definition of an HIMS.  Here it is, from "Human Interactions: The Heart and Soul of Business Process Management" (2005), the seminal source book on Human Interaction Management (HIM):

A process modeling and enactment system that provides native support for the six Role Activity Theory object types (Role, Entity, Activity, User, State and Interaction), uses a state-based approach to Activity enablement and validation, permits Interactions to be composed of multiple asynchronous channels, and supports management of process change by allowing any process component to be created and configured as a natural part of process execution—not just objects of the six fundamental types, but also the user interfaces by which they are presented (screens, for example) and the means by which they interact with other systems (Web service calls, for example).

This is a complex definition, of course - almost what you would expect to see in a software specification document.  This is deliberate and necessary.  A HIMS must be a very specific sort of beast, in order to support the 5 basic principles of HIM:

1. Connection visibility - to work with people, you need to know who they are, what they can do, and what their responsibilities are as opposed to yours.
   You need Role and User objects, both instances and types, each with its own properties and responsibilities.
   
2. Structured messaging - if people are to manage their interactions with others better, their communications must be structured and goal-directed.
   You need Interaction objects in which there are multiple asynchronous channels, each for a different purpose.
   
3. Support for mental work - organizations must learn to manage the time and mental effort their staff invest in researching, comparing, considering, deciding, and generally turning information into knowledge and ideas.
   You need Entity objects that can be created, versioned and shared within a process.
   
4. Supportive rather than prescriptive activity management - humans do not sequence their activities in the manner of a procedural computer program.  There is always structure to human work, sometimes less and sometime more, but it is not the same kind of structure that you get in a flowchart.
   You need State objects that can both enable and validate Activity objects, along with the Roles that contain them.
   
5. Processes change processes - human activities are concerned often with solving problems, or making something happen. Such activities routinely start in the same fashion - by establishing a way of proceeding. Before you can design your new widget, or develop your marketing plan, you need to work out how you are going to do so - which methodology to use, which tools are required, which people should be consulted, and so on. In other words, process definition is an intrinsic part of the process itself.  Further, this is not a one-time thing - it happens continually throughout the life of the process.
   You must be able to manipulate not only objects but also user interfaces and integration mechanisms via the process that contains them.

How could a conventional "task allocation and notification" system possibly provide all these vital features?  Just to take one example, I have never seen a workflow/BPM system in which it is practical for users to try and make significant change to a process from within the process itself.  This is why Jon Pyke says, of course with tongue in cheek, that workflow sucks.  We need a new form of software tool, in order to support the business practices that are at the heart of organizational efficiency in the 21st century.

TAKE AWAY

 If you want to compete in the 21st century, you need to leverage your human resources efficiently.  If you want to leverage your human resources efficiently, you need an HIMS - not a workflow/BPM system rebadged as an HIMS.

So ask any software vendor trying to sell you a "Human Interaction Management System" how their offering conforms to the definition above.

Don't let them sell you a pig in a poke.

Posted by keithhb in Business Process Management • Internet • Knowledge Management • Management • Office Applications |Digg This|Add to del.icio.us

Posted by: Brian Leapman at November 15, 2006 12:59 PM

Posted by: Keith Harrison-Broninski at November 15, 2006 01:41 PM

Posted by: Roeland Loggen at December 18, 2006 05:31 PM