The happy-path-only syndrome

Great article Ivo. One of the problems of being in the BPM business is that wherever you go in your daily life (Internet, restaurant, airport, hotel, shopping mall, etc) you see examples of bad and completely illogical processes. Glad to see that someone else has spotted them. I thought it was just me becoming a grumpy old man!

Rob

Ivo, you hit the bull's eye of BPM!

I am getting often angry when I am in the role of a customer in a (what I used to call) unstable process. That is, when the operator of a process has to leave the nice-weather path and need to handle an exception to still successfully finish the process. And that happens more often than we realize.

The other day I was standing in a fast food restaurant, which should - by its nature - fast in the order-to-delivery end-to-end process.

However, their processes seemed not to be meant to handle exceptions. “The fries are ready, but the burger needs a little longer” the clerk told me. “But please take a seat, I’ll serve the burger in a minute” I was told. So I paid and took my fries, the Coke and went to the table. A little later the same clerk brought a burger to complete my meal. But surprisingly it was different  from what I've ordered. I didn’t complain, because I wanted actually to be fast during my lunch. But what went wrong here? Can't the clerk remember what I've orded? Was it "too fast" for a fast food restaurant?

I am wondering how to keep standard processes stable in terms of handling exceptions. With resource and cost optimization in mind we tend to forget to make much use of a actually maintenance-free built-in process engine, our 200,000 years old brain. Seems to me turn it off in favor of well trained routines instead of let it control the execution of the process we are running.

So that raises the question how to build in common sense into a stable and reliable processes?

Cheers

Rune

Ivo, you make a good point. But isn't almost every model some version of a "happy path"? In today's dynamic business world, every complex real world process that involves humans will always lack detail about process branches that weren't forseen by the process model (or modelers).

As business orients more and more towards knowledge work, we'll being seeing more of these types of highly dynamic processes that really can't be competely and rigorously modeled. For anyone interested "Mastering the Unpredictable" is a good book on the topic.

Jacob Ukelson - CTO ActionBase

I agree with Ivo - its understanding the degrees of flexibility that is important. There has been talk for some time of dynamic processes that will be built on-the-fly, but when you look at some of the current issues in BPM: transparency, compliance, efficiency, customer satisfaction, etc., I don’t think dynamic processes address these. On the other hand traditional process design is seen as too time consuming and inflexible. What we need is to think much more about process reuse rather along the lines of car manufacturers. Most build your new car to order from the options you select, but even when there seems to be a vast range of options, they in fact have very carefully managed flexibility points that reuse key components. Its true we can’t account for every possible occurrence in the process, but we can understand which classes of options (or failures) are likely to occur and are important (effect customer, revenue, regulation etc) and make sure we account for them

I agree with Ivo - its understanding the degrees of flexibility that is important. There has been talk for some time of dynamic processes that will be built on-the-fly, but when you look at some of the current issues in BPM: transparency, compliance, efficiency, customer satisfaction, etc., I don’t think dynamic processes address these. On the other hand traditional process design is seen as too time consuming and inflexible. What we need is to think much more about process reuse rather along the lines of car manufacturers. Most build your new car to order from the options you select, but even when there seems to be a vast range of options, they in fact have very carefully managed flexibility points that reuse key components. Its true we can’t account for every possible occurrence in the process, but we can understand which classes of options (or failures) are most likely to occur and are important (effect customer, revenue, regulation etc) and make sure we account for them. Other options we must route to the human BPMS (i.e. Rune's brain!)

Thank you for your comment, Jacob. Putting semi-structured and unstructured processes aside, when analysis is on the structured ones, it's important to identify the patterns of behaviour with the degree of variation tolerance depending on the analysis objectives. In most cases we don't have information about all process instances for certain period. So, normalisation techniques can't be applied. Then we are left with our common sense and experience to identify those alternative that have significant probability. There is no universal norm of significant probability. For some businesses could be above 10%, for others even lower, say above 1%. And of course that's only when viewing  an alternative path as a normal, as a right path. Not talking about process variation representing error. There 1% is of course too high, especially if you ask SixSigma people.

I have a slightly different viewpoint. If i may suggest, the case here of Airlines, is not a example of 'Happy path' syndrome. It is ,as we say in Systems thinking, a example of not 'closing the loop'. When a loop is initiated, it has to be closed. When it hangs open like this, as is seen in the case, problems arise in plenty. So when the loop is not closed, the process will become 'unstable'. No prize to guess that !

Happy-path syndrome, i would like to suggest, is a 80:20 problem. We take care of 80% of the variety in a single process version and hope everything will go right. But as processes mature, as they often do, we have to create many process versions to satisfy the increasing variety such as to attract new customers, cater to niche demands of customer and so on. These 20% process versions then cause 80% of the process difficulties, so to say.  But in a way, we ourself fall in this pit, because we do not take care of 'closing the loop' of all these process versions. Any comments?

Sanjiv,

  I mostly agree. I think there are 2 versions of the 80-20 problem. For structured processes - 20% of the time the process doesn't cover the actual scenario (aka exceptions). Those exceptions cause 80% of the problems. I think that is what you meant.

  The other part of the 80-20 rule is that structured processes cover only about 20% of all real world processes in today's modern knowledge based economies... BPM systems are geared towards that structured 20%. We need systems and methodologies to help with the other 80% - something better than email and documents - the way most unstructured processes are handled today.

     Jacob Ukelson - CTO ActionBase

Dr Jacob,

You have given an interesting twist to my response. I did not categorise processes as structured or unstructured in my mind when i wrote the response. But your thought induces many unconnected threads. I propose to follow one of the intriguing thread.

I feel organisation has many structured and unstructured activities. ( I am not sure of their proportion!) Not all of them needs to be captured in a 'structured process'. Infact, the fewer we capture, the more freedom is experienced. Some of them do not even need a 'process' to 'capture'. For instance, with a coherent vision, many of the organisation unstructured activities automatically get channelised. ( Toyota is one such example) That vision itself reduces the variety to such an extent that processes become simpler and easy to implement. Does this idea gel with your experience?

Sanjiv,

Yes, exactly.

There is an interesting book on the subject by Thomas Davenport called "Thinking for a Living" where he talks about how knowledge workers do their jobs. He finds that for many types of knowledge work there is a need to give a goal describing what needs to get done, but not how to do it. If you try to describe how to do it in too much detail, they balk.

Adaptive case management is trying to address these issues - take a look at "Mastering the Unpredictable" (http://www.masteringtheunpredictable.com/) a new book on the subject.

Jacob Ukelson - CTO ActionBase

I might get some info on some online retailers to see if the product has a good review from users.