Our team of enthusiastic students from the University of Applied Sciences Koblenz has already taken a look at the input they’ve collected so far and they’ve given us a quick update presentation this morning. I’ll probably do a write-up of the 4 or 5 biggest surprises as a teaser later today but let me tell you there are lots more from what I’ve seen so far.

So keep on sending us more input so that we can stabilize the results!

And as I know that our american readers always love a challenge: Canadian participation is higher than US participation. Are you going to settle for that?

Stay tuned for the teaser results!

Get involved, let us know what your current situation and perspective on process quality is and take the survey: http://bit.ly/s3LaYO

Respondents will receive a free summary of results and can benchmark their answers against overall results.

Survey is conducted as a joint research project between the University of Applied Sciences Koblenz and the taraneon Process TestLab

Phase 1 of the survey saw us conduct in-depth interviews with representatives of various companies.

We have now started phase 2 in which we’re asking for your participation in our online survey. Please visit

www.q-in-bpm.org

and share your views and experiences. All registered participants will receive a detailed summary of the survey results, allowing them to benchmark themselves against the overall results.

DANGER: This process can seriously damage your wealth

I’ve always had this a vague picture in my mind of an analogy between wearing a seatbelt while driving and using process testing methods during projects. So I took a quick look at some stats and here’s what I found:

In Germany we have around 7.8 car accident fatalities per billion kilometres travelled. With an average driving distance of 10000 kilometres per year and driver, this translates into 100.000 drivers of whom 7.8 come to a sad ending. That’s 0.0078%. I’ve also recently read that without seatbelts alone (that’s discounting airbags and other safety measures) the fatality rate would have been 30 times higher, which would increase the rate to 0.234%. So, anything that helps us reduce the danger of injury (or worse) even in the highly unlikely case of an accident is generally accepted and we are fortunately seeing a continuous development of safety measures which will hopefully reduce the numbers even further.

The reason I mention this is that there are two important aspects to look at:

• Accident prevention and
• Reduction of the consequences of accidents

I’d think that nobody would dispute the sense in addressing both aspects.

Changing the subject completely (or so you’d think), we know that 82% of all process initiatives fail to reach their targets.

In many cases, the causes are located in design phase: Errors in process logic that prohibit implementation, workable but inefficient processes that lead to constant change requests long after the processes have been put into operations and the curious realisation that somehow reality always refuses to conform to project assumptions and process models.

This begs the question of what could be done. Well, most of us buckle up BEFORE we take to the road and not AFTER we’ve reached our destination. So why do we only test our processes only after we’ve implemented them and even then leave the final testing to our customers (always assuming you even get to that stage)?

This is of course what the Process TestLab is all about: Providing you with an independent assessment of the quality and risks associated with your process design. Will they work? How will they work? What happens if …?

Buckle up your processes!

Image by Juan de Dios Santander Vela

I, the customer, hereby promise that I will never change my mind once I have placed the burden of delivery on my supplier. So help me God.

Customer integration, Outside-In, consumer-orientation, social BPM … the list of terms describing the shift from process silo thinking to a more inclusive approach is as long as the list of companies proclaiming that their customers have always been the centre of their universe.

Slight hesitation. Does that mean that the whole company is turning around the axis called customer or do they just mean the place where they left the customer dead and buried?

Imagine a simple order handling process in which an incoming customer order is first checked and the required product or service is then created in a number of steps before the result is shipped to the customer. Nothing fancy and nothing special.

When our clients validate this sort of process in the Process TestLab they usually do so to check if the process will deliver the desired result and how a process model would translate into a live process.

If the validation run leads to the intended result and the process steps/tasks used are logical and more or less aligned there’s an immediate temptation to sign off on the process. It works, it performs, what more do we need to do? And as the process was initiated by a customer order and the customer gets what he ordered it must be a customer-centric process. QED?

This is where we’ve recently added a little something to the validation scenarios: An unexpected customer change request that comes in while the original order is being processed. In 8 times out of 10 we observe the following:

First it’s consternation: Can’t be done, this sort of customer behaviour has not been provided for in the process.

Then the discussion leads to two possible solutions: Either cancel the original order and ask the customer to create a new one, or go ahead with the original order and tell the customer that he should have made up his mind before starting the process.

It’s at this stage that experience takes over: A clever employee will bypass the process to accommondate the customer. The result? A happy customer, a happy employee AND a lot of undocumented activities, no audit trail, possibly a failure to follow governance and compliance rules. To put it bluntly: You’ve worked outside the rules of your company. Do it once, it may be regarded as a heroic one-off exception and be tolerated, but do it more often (and successfully) you have in fact created an unmanaged, uncontrolled and unauthorized set of shadow processes.

The bottom line is that technically and logically in this example these change requests could be fulfilled. It is only the process design that limits the agility and flexibility that is essentially available.  In other words, the process is incomplete as it doesn’t take the dynamic behaviour of the customer into account. The customer – more often than not – is something we see stuck at the beginning and at the end of a process, totally ignoring the fact that not only we as vendors or suppliers have processes but that customers do as well.

So, when you check your processes, don’t only look at the business logic and process objectives but also ask yourselves if your static process models allow for dynamic behaviour. If you’re planning to provide quality processes, never forget that quality customers are usually alive.

The 10 revised full papers presented together with one invited keynote paper and three panel statements were carefully reviewed and selected from initially 17 submissions. The papers present innovative cross-disciplinary ideas, concepts, methods, tools and results in foundational and applied research as well as studies on the realization of such innovations in the real world – all based on the promising new paradigm of subject-oriented business process management.”

And now comes the really good bit:

In a blogpost at the time I mentioned that I had given a – in the eyes of the gathered research community – somewhat controversial presentation (never a good idea to tell your audience they got it wrong). The publishers have now made the most of this and have given Albert Fleischmann – the inventor of S-BPM – and Dr. Singer and Dr. Zinser from the University of Applied Sciences in Graz, Austria room for a reply to my thesis that “…research has failed the BPM community”. The two papers are included in the proceedings and together with my paper I believe they cover the whole spectrum of current BPM discussions quite well. Of course, my presentation was intentionally provocative but I believe it was well worth it as forced some excellent replies to appear.

Hopefully we will be able to update our discussions at the next S-BPM One conference at the end of this month in Ingolstadt.

Links:

taraneon Blog: Why BPM research has got it wrong

S-BPM One 2011 conference website

Here’s an extract of what I found:

1. Do something, (or at least pretend to).
Well observed. Might make it to the top of my BPM definitions
2. Method of doing something, (or at least pretending to).
There’s a method to pretending to do something? Consultants??
3. To change the structural integrity of an object so as to render it incapable of containing mass. This is usually accomplished by a sudden, violent force, such as an explosion, or having the object struck by a hollow-point bullet travelling at extremely high velocities.
Three ideas come to mind:
a) the result of a process is the destruction of content,
b) BPMS buyers will in future have to provide an end-user certificate to receive the product and the accompanying ammunition,
c) Heavyweights like Software AG and SAP will likely ship their products with customized RPGs.
4. Process is the word used to describe screwing Lions.
While I hope that this (probably) concerns american football, I firmly refuse to even have an opinion on this one.

Note to self: Explain what you really mean when you’re talking about espresso, processes or screwing lions – though the latter has until now never come up in any conversation I’ve witnessed.

“We can’t spend time and effort on trying to avoid process errors as all our resources are tied up with correcting the mistakes we made in the past.”

It’s been nearly a week since that statement was made by the process owner of a very large company. I’ve finally decided that I must have heard him correctly. Now I’m just wondering if he’s aware of the difference between movement and progress.

So listen in to find out

• why the main causes of process failure can be traced back to the process design phase
• why having a process that works isn’t the same as having a good process
• why process awareness plays an important – and often overlooked – part in quality management
• why frequent change of process managers can be counterproductive to continuous process improvement

Image by Colleen, sound of paper rustling in the background courtesy of Thomas fumbling through a stack of prepared but sadly illegible notes.