Airline Mergers Don't Use BPM?!?!

Scott Francis
Next Post
Previous Post
(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)
  • I stressed the BPMN in an attempt to make BPM concrete in the mind of the reader. However, you are right in saying that all BPM does not need to use BPMN.

    The difference between a BPM style process, and an ACM style process, is that “Adaptible” means that the processes are designed to be modified before use.

    That is the key: “the processes are designed to be modified before use.”

    With BPM, the processes are designed to complete and to run without modification, because the very meaning of BPM is to “manage” the processes in a cycle of continual improvement. This is rooted in the fundamental idea that a process can exist in abstract from the instance, and that you can evaluate that processes on a scale of good to bad, in abstract from a particular instance.

    ACM, however, represents an entirely different approach, which is that there every instance is different enough that there is no way to prepare an optimized process in advance. Yes, you do prepare templates, but they are “designed to be modified before use”. In fact there is no guarantee that an ACM template will run out-of-the-box without modification.

    I noticed also your statement “if your modelers can’t model the process, you need to find new modelers.” Who are modelers? The point about ACM is that the process is modified by the case manager. There are no separate modelers, and I think that is one of the big sticking points it trying to explain ACM. One of the requirements of ACM is that there is no need for specialists to do modeling.

    But, you argue: I can use my BPM system to make process definitions, and then any user can customize the process definition for the particular case without any constraints. AND, your BPM tool is designed to be used by anyone without specialized training i.e. it does not use BPMN. AND it allows for explicit representation of goals as well as activities. OK, I would agree that that specific BPM tool has the most important elements of ACM. I would agree you have something useful to knowledge workers.

    Use ACM for unpredictable knowledge work, use BPM for routine predictable processes. There will be products that support both, but don't fall into the trap of thinking that the user interface for a programmer to use BPMN is going to be the same user interface for an executive (assistant) to insert action items into an ACM case.

    All we are trying to do is to help people see that this is really quite different from the traditional understanding of how BPM is implemented and used.

  • I'll sum my points here:
    1. acquisitions, are, in fact, a repeatable process for some firms. (And that was the scenario in which modeling enters the picture, not for a pure one-off process execution).

    2. I understand your argument for using BPMN in place of BPM to make it more concrete. It makes sense to constrain the counter-arguments to make your proposition stronger :)

    3. I would argue, if my “BPM System” is designed for anyone to use without specialized training (except, perhaps, we might expect them to be experts in airline mergers in your example ;) , then you don't get to see whether there is any BPMN magick behind the scenes, or whether there is java code, or C++, or something in the cloud. All of those technology decisions are made behind the black box walls. What you do get to guarantee is that the users of the process can make the modifications they need for their process without touching technical details like BPMN (or java or sql queries).

    I would say, that when a major airline uses ACM software to execute a merger, then we have something to talk about regarding what a good fit ACM is for this type of one-off process. Til then, it is pretty much conjecture, rather than a proof of the benefits vis-a-vis BPM. Had you just focused on how ACM might address this use case, hypothetically, well and good. But you also used the straw man that because BPM was not used, it proves ACM is the right approach – whether or not your conclusion is right, the logic of the argument isn't sound in my opinion.

  • “you also used the straw man that because BPM was not used, it proves ACM is the right approach”

    No, that is not the argument at all. I was arguing that it should be self-evidence that based on fundamental principles of BPM, it would not be a good fit for this case. Similarly, based on the fundamental principles of ACM, it might be a good fit. This is a thought exercise, not a demonstration.

  • Pingback: Case Management & Social BPM Quotes of the week « Adam Deane()

  • Missed this previously. Similarly, if this company engaged in many mergers, most BPM advocates would not find it odd at all that they would apply BPM to acquisitions.

  • Pingback: Process for the Enterprise » Blog Archive » About that Merger…()

  • Pingback: Lest you think that Mergers are the Stuff of ACM… » Process for the Enterprise()