Airline Mergers Don't Use BPM?!?!
- May 11, 2010
- 7 Comments
(As an aside, this article from Keith is a good read, but I disagree with his conclusions)
Keith Swenson on Airline Mergers not using BPM, making the case for ACM:
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.
Am I to believe that they used an ACM product for this?
Going into the weeds here, though I think that makes my basic point, here’s some of the background thinking:
Companies that engage in acquisitions a lot actually do have pre-defined processes for acquisitions – IBM, Cisco, Oracle. Are there parts of the acquisition that don’t fit neatly in a box? sure there are. That’s why it is called BPM, and not automation. Keith is giving us a false choice: all paths must be defined in BPMN in order to be BPM, on the one hand; on the other – nothing predefined in ACM and process nirvana is achieved. I’ll just assume that ACM would equal process nirvana in this case, and focus on the BPM choice to demonstrate my point.
With the right abstractions in your BPM models, you don’t model all possible choices, the choice is just data along the path to the next node, rather than having a separate path per choice. Nodes can be well-defined BPMN models, or they can be applications, or they can be “ACM” style processes like “Meet and make a Final Decision”, which may end up being 3 meetings or getting some additional emergent process defined.
Or they could map out the process they’d like to follow in Blueprint or ActionBase and go from there – much lower overhead for a one-off process- although THIS process has an effect measured in Billions so it might actually be worth it to spin up some cycles on defining the process even if it isn’t a running implementation of the process. Yes, requires a little bit of thinking ahead – but it doesn’t require BPMN – and it also allows for documenting any changes as you go. And yet, I’d still call it “BPM”. From a technology point of view, these folks may not be using a BPMS to do their acquisitions. But that doesn’t prove that they couldn’t. Whether a BPMS would be helpful or not largely depends on how well it supports this kind of use case, and that varies widely from one software package/vendor to another. Part of the problem: is “BPM” defined by what a BPMS can do for you? or is a BPMS defined by what you need to do “BPM”? Tough one. But you see this kind of problem all the time in software market definitions.
Do I think ACM could be a good fit for an airline merger? Sure, depending on the specific software and its features – this isn’t a run-of-the-mill situation. But if I use Keith’s logic, the fact that the airlines didn’t use ACM for this merger is proof that ACM doesn’t solve the problem. (tongue in cheek)
Generally in my experience if your modelers can’t model the process, you need to find new modelers. I might need to add a corollary though – your BPMS should be capable of handling abstractions well (like generic failure events, arbitrary data definitions, dynamic binding to service definitions or sub process definitions… ) It sounds like a lot of the folks writing about BPM and ACM still haven’t used a BPMS that supports these features.
(Incidentally, I agree with Keith that you wouldn’t use a BPMS to schedule lunch with a colleague. However, that’s because there are already good software solutions for scheduling lunch. If I was writing one of these solutions, like Tungle– I might very well use a BPMS to coordinate finding the right time on our schedule – because it is often done via electronic means and the back-and-forth is pretty inefficient. Tungle.me didn’t use a BPMS – but they sure could have. The point of BPM or ACM isn’t to do everything that they could do – it is to apply them when you don’t already have a good solution)