In spite that the risk is well known, it seems we quite often encounter the happy-path-only syndrome. My recent one was with easyJet airlines.
The online check-in is not to be missed, although in that particular case it is not the most pleasant web experience, it's worth a few extra clicks. And really it's such a simple win-win scenario. Apart from the obvious direct and indirect benefits for the airlines, online check-in saves a lot of time both to those who do it and those who don't (especially when the first group is a majority).
So I did it. But this time I had an extra bag. That's not something extraordinary. I fell into the category of "bag-droppers". But that's in the virtual part of the process only. In the check-in hall, only the sequence for online checkiners with hand baggage existed. There were three check-in counters - one for speedy boarding and two for regular. Bag-droppers can't go to speedy boarding unless they paid for that service leaving them with no other option but to go to the regular queue. That of course was the main thing they wanted to avoid by doing online check-in...
Isn't it strange that the happy-path-only problem, which has been in the BPM classic mistake charts for years, is still among the top? Rob Davis in his excellent "Before you start modelling" online course lists "modelling only success" among the common modelling pitfalls together with incorrectly modelling decisions, false assumptions, mixing viewpoints, not modelling inputs and outputs, and forgetting measures.
But it's not just in modelling where it happens. Yes, alternative paths are often missed during analysis, but sometimes they are caught during analysis, and then somehow forgotten during implementation. In the easyJet case, it was implemented but only in the automated part of the process. And that is how this story brings up another thing of equal importance. I looked and asked around and it's not just me seeing a trend of contemporary business process management to be actually a disguised application process management. The BPM today 1) goes away from Enterprise Architecture loosing its integration capability and 2) the non-automated part of the processes are being neglected, thus loosing the power of end-to-end process improvement. In the context of the story, a missed alternative path in a (to-be) automated process, especially when it's a matter of just going "off-road", could be easily identified and exception handling added. That's not the case when the process continues with little or no IT support as most processes do. In the end, it's a matter of awareness -> informed decision -> implemented decision.
So call me old-fashioned but I believe that a process should be adequately modelled to enter and be processed by an old and sometimes neglected execution engine - the human brain.
But OK, let's talk about automation. As I mentioned in the beginning, the online check-in was not itself the most pleasant IT experience. Again, it's not only me that noticed that. Gary Comerford in his post "The Tao of online processes" compares the Amazon order process with guess what - online purchasing of a cut-price airline ticket. You can imagine the result; if not or in any case read the post. Here I definitely agree with Gary that "many companies have designed their processes around an existing bricks-and-mortar method of dealing with customers and have then transferred that directly to the web". This brings us again to the need to process things through the same old and sometimes neglected execution engine - the human brain.
ARIS model
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
Mon, 07/26/2010 - 11:40
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
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 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!)
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
