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.

Realization

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.