Is there an Elephant in your (Process Design) Room?

Imagine landing a jet liner by blindly following a long list of actions, without any consideration of your altitude, position, fuel status, airspeed or the weather, and what about wind direction and ground traffic.  Such a scenario is clearly absurd and doomed.

But this is exactly what we're doing when we model business processes by simply sequencing tasks or actions. We're creating an action-packed sequence of work that tells us what to do, but we remain blind to the very thing we're working on—the business process case data itself.

Yet this is exactly how most organisations model and conduct their operations today.

Business process data is the proverbial elephant in the room and its omission leaves a gaping holes in our design, that lead to expensive project and operational failures.

Based on my 20+ years of business process design and automation in financial services and government, I’ll offer my considered views on why this blind spot exists, the serious problems it causes and a simple fix.

In short, I believe that overlooking business data during process design is simply an old business habit that refuses to die, although it’s getting ever harder to ignore.

Some decades back in manufacturing the world was different. Labour was an expensive and scare resource that needed tight management and the state of the materials being processed was generally obvious.  Was the state of this sheet of metal say, pressed or pressed and painted?

A sequential flow chart was generally adequate to explain this style of business operation.

This is no longer the case in a modern services economy where customers and staff interact to co-create the service “product” and the thing being processed is not tangible, like sheet metal.  Services only process data.

And, data (or information) is an elusive thing that can be located anywhere, is easily modified, duplicated or deleted and can exist in numerous forms ranging from analog, unstructured data like voice, to well structured digital databases.

Service sector processes are by definition many times more complex than those found in manufacturing and, in my opinion, they deserve a completely different, purpose-built approach to design.

Service operations are best designed around the lifecycle of the data they process, as well as the various interrupting events demanded by customers, suppliers and regulators.  This is similar to an airline pilot who wisely bases their next action on the current state of the aircraft and its context.

Trying to model all the possibilities of aircraft behaviour in advance is clearly impossible and trying to over simplify the navigational options could well be fatal.  These are the exact same failure patterns we see during process design.

A designer attempts to account for all possible processing pathways, which is generally impossible, or they simply narrow the scope to a so called "happy day scenario”, in which only the most common or most expensive pathways are considered.  All else is an exception.

The UK Institute of Customer Service consistently finds that around 20% of the productive capacity of all customer facing staff is wasted in process failures and non value-adding rework.  This is a large unnecessary cost (about £11 billion pounds per month) in the UK alone.

Designing processes without a proper regard for data leads to compliance failures and audit findings, exposing a company to heightened operational risks along with expensive fines and sanctions.

I, for one, don’t believe it’s good enough to account for these failures as “business as usual costs” and simply pass them onto the consumer.

Time’s up.  We need to confront the elephant.

There does exist a well accepted international standard for the visual design of business processes called the business process modelling notation (BPMN).  It's popular and widely adopted, but its heritage in manufacturing pays little attention to business process data.  Just 10 pages out of more than 530.

The standard openly explains (p201) that data is outside the scope of this International Standard and becomes the responsibility of the tool vendor.

So process data was overlooked some years ago and we simply continue to ignore it today.  Worse still, when we do stop to consider the business data there is no generally agreed and business friendly way to define data or its compliant behaviour.

We have come to understand that there exist two models to be understood and defined for every business process, the task-work model and the data-event model, distinct but also co-dependent.  We have always known there was an elephant in the room but until now we lacked an elegant way to present process data in a business-friendly way.

At this point let me make a full disclosure. I was actively involved in developing the original BPMN standard so I carry some responsibility for its shortcomings, and hopefully for some of its popularity.

We now propose to fix this overdue and unsatisfactory state of affairs, by introducing a business friendly approach to data design including a concise way to describe the often complex lifecycle of business process data, and without dismantling BPMN.  An approach that has proven invaluable to us during real-world customer projects.

Using natural business language and a simple guided graphical interface these business modelling enhancements simplify any process design project, enabling anyone to be a brilliant process designer.

Let me know what you think of properly integrating data into process design and how you envisage the evolution of our ageing process design methods.