Imagine the folks at United Airlines and Continental Airlines last week as they announced the largest airline merger in history. Ask yourself a some simple questions:
- Did they use a BPMN diagram to describe the things that need to be done to accomplish the merger? If not why not?
- What is the chance that a process designer had drawn up a snippet ahead of time that they could bring in to use to accomplish the merger?
- Did the people who made the merger agreement see themselves as designing a process for the company?
We know that the two airlines attempted to merge before, but failed to come to terms. Almost everyone was surprised that they suddenly came to agreement and announced the merger. The executive will simply announce actions that are to be taken. Those announcement may drive something similar to planning — depending upon how much time there — but it would be misleading to say that the executives sit down and draw up a detailed plan at any level before shaking hands on the agreement.
- Did IBM make a BPMN process to describe the acquisition of Lombardi? Both companies have sufficient expertise in BPM. Why didn’t they execute a BPM process to accomplish the merger?
- Did Progress make a BPMN diagram of the acquisition of Savvion?
- Can we use BPM analytics to determine how efficient any of these acquisitions were?
Of course the people negotiating and coming to agreement did not sit down and write BPMN diagrams before communicating the merger to the public relations department. Those who believe that a BPMS can be used in unpredictable situations like this, will argue that the executives involved “planned” the merger of the company. Yes, they did plan it, but there is huge, fundamental difference between the way that an executive thinks up action items, and the way a process designer draws a process chart. The executive gave orders in a way that was internally consistent, but did not in any way externalize that process. Here is the reason: everything happens so quickly, you don’t have time to make a plan ahead of time.
No Time To Plan
There are two responses:
(1) It should have been done in a BPMS. Everything should be planned fully and explicitly. Everyone knows that things that are planned work out better than things that are not planned. The perfect world is one where everyone sits down and plans what they do before they do it. Take the activities that go into the BPM lifecycle, and speed it up to happen at run time.
(2) Not all situations require a BPMS. Planning as an intellectual activity is important, but making a external expression of those plans is work that often exceeds the benefit. There are situations where you need to simply get the work done. The overhead of a formal plan exceeds the benefit, and in fact because it is relatively fixed can actually get in the way of getting the work done.
Category 1 people tend to blame the lack of a plan on laziness, and often proposing ‘forcing them to make a plan for their own good’. If they are more generous, they blame the lack of usability of the planning tools, and call for advances in usability to make this work.
What is being ignored is the fundamental fuzziness of a plan. People are not like CPUs. A human organization can be very intelligent when executing fuzzy plans. Any good executive knows this. Instead of laying out a detailed plan of what everyone should do, an executive communicates the goals that are to be achieved, and lets the assignees work out the details.
“I’m sorry, Dave. I’m afraid I can’t do that.”
Show me the BPMN diagram that includes the ability to say that you can’t do something. A process definition can have a “go/no-go” decision branch, but that is still doing the process. BPMN diagrams can have failure events, but again, only pre-defined events can be handled. An executive that requests that task X be done; an assignee may find (possible for legal reasons) that that action is not possible, but can suggest an alternative. That may change the whole process, and you have to step outside of the process to do that. You can bet that as the merger of United and Continental goes forward, there will be many points like this that will be refined as they go along.
You really can not model this as an activity that says “Figure out what to do next” because when the initial directives are given out there is no way to know that there is a (legal) problem with a particular action. Of course, there is a way to know, but it takes time and you can’t afford to wait until all the details are worked out before taking action. In essence: you have to take action while being partially informed, and you have to expect that some of it will have to be changed.
Strategy and Tactics
It is like the difference between strategy and tactics. With strategy it is clear that elaborate plans make sense. But tactics is not just strategy done real fast. Tactics is different from strategy — that is why we have a different name for it. Strategy generally involves lots of possible routes depending upon specifics, but Tactics are made expressly for the situation, and are expected to change when more about the situation becomes known.
Usually when I talk to BPM experts, they say something like “Of course you wouldn’t use BPM for something like a major airline merger”. Most people understand that you would never use BPM to arrange a lunch with a colleague. There is broad understanding that there are things that BPM is simply overkill for, or too slow for.
The merger between United and Continental is a unique event. It has never been done before, and will never be done again in the same way. It has similarities with other mergers, but not to the level of detail that specific action plan (process definition) could be drawn up and re-used. This is a case where a pre-defined process will simply not be worth the benefit, or the cost in terms of delay.
I accept that there are things you just do (let’s have coffee today…) and that some things come about despite having no obvious plan or process (UK government, eventually) but dispute the premise that BPM should not be playing a part.
A problem with BPM is the assumption that the process cannot be changed in flight. It seems entirely reasonable to me that a process should be followed ; have a “I’m sorry, Dave. I’m afraid I can’t do that.” moment; and be changed at that point. Visualising the state in a BPMN diagram allows a view of what has been followed upto a state and what is expected to follow. The executable BPMN engines of today will struggle with a change to inflight process instances but there is still plenty of development milage to run there.
Pingback: Tweets that mention Where did I put that major airline merger process definition? « Thoughts on Collaborative Planning -- Topsy.com
Pingback: Process for the Enterprise » Blog Archive » Airline Mergers Don’t Use BPM?!?!
David, making a process change while it is running is not technologically difficult. My BPM products from Fujitsu have always allowed anyone (with the access rights) to change the process at any time: adding activities, removing activities, and re-routing the flow. This has worked for 15 years — but we find that few real people in organizations use it.
The difficulty with changing a process comes when the person who needs to make the change does not have the skill to understand the process editor and the implications of any given edit.
In the 1990’s we rather naively assumed that because the model was graphical, any user would be able to modify it. Since then we have come to understand that using a graphical editor for a BPMN process requires significant training. What is the change that 100% of the managers in an organization are trained in BPMN. And it has to be 100% because the need for change can come from anywhere. BPMN 2.0 increases the divide between skilled and unskilled by raising the bar for what you have to know.
This has led us to believe that to allow a process to be changed, there needs to be a very simple process paradigm — like a checklist — that can be easily modified by 100% of the managers. It is not a technical challenge, but instead a usability challenge.
So, a product with a checklist-style process model would be (in my estimation) modifiable by any manager, and it is unfair for me to exclude BPM from this category. But in general, BPM products are continually pushed to more complex modeling paradigms. The fact is that if a product does not have a BPMN modeler, the analyst refuse to consider it BPM. I am not making this up, but it is the BPM industry which states that a BPM product MUST have something very much like a BPMN modeler. So I am on relatively safe ground saying that a BPM product has a modeler that is too complex for the average corporate manager to use.
Pingback: Column 2 : links for 2010-05-25
Two things in Keith’s comments which are very important (to me):
“The difficulty with changing a process comes when the person who needs to make the change does not have the skill to understand the process editor and the implications of any given edit.” : this is a failing of many of the BPMS tools (and even worse, for the pre-BPM tooling out there – no one even tries to edit the process for an ERP system ; )
“This has led us to believe that to allow a process to be changed, there needs to be a very simple process paradigm — like a checklist — that can be easily modified by 100% of the managers. It is not a technical challenge, but instead a usability challenge.” – I think the basic point here is: software vendors need to invest in deeply understanding the needs of the users (managers) and invest in giving them control over complex changes with simple analogs (e.g. checklists, but I’m sure there are other approaches as well).
Pingback: Process for the Enterprise » Blog Archive » Keith Swenson Makes the Case