We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

What type of event leads to BPM vs. what type of event leads to ACM?

Vote 0 Votes
Last week we debated whether case management will take over BPM, but I heard from a few people wondering what type of event leads to what, so what type of event leads to BPM versus what type of event leads to ACM and is it possible to switch between them?

6 Replies

| Add a Reply
  • It is not the event, but the context, that determines whether BPM or ACM will be used.

    In my living room, if someone start having heart palpitations, it is going to be very much case management as we collectively put together a plan to take care of the situation without really getting the chance to sit down and make a nice plan. We just do it. However, in a hospital emergency room, they may have well defined (and somewhat routine) procedures on what to do about heart palpitations. The event is the same, but the context defines how common the event is.

    You can describe ACM and BPM as a spectrum, but that serves to hide an essential difference. With BPM, the plans (the process diagrams) are put together by one person and used by another, which with ACM the plans are put together as the work is being done, by the person doing the work. That is a difference that makes a difference. Theoretically with BPM it could be the same person, but in practice it never is, while with ACM it has to be the same person.

    We talk about surgeons drawing up BPMN diagrams, but that is not what happens. What happens in BPM that a process specialist works with a surgeon, observes the group, throws in some good ideas about how to improve things, and produces a process application. The tools do to this are geared toward this specialist and include many powerful features that they need.

    With ACM the plans must be drawn up by the surgeons themselves, and that strongly effects the power and capability of the tools. The surgeon has better things to do than to learn the intricacies of a process language (there are after all specialists to do that). Instead, the tools need to immediately support the case at hand. This is planning by doing, not just planning at nearly the same time as doing.

    This discussion usually devolves into whether vendor ABC offers tools for both BPM and ACM. I am sure that all vendors will eventually support both styles in an integrated environment, but that should not be taken to mean that the tools that are used to do the BPM are the same as those for ACM. The style of working, the pattern of behavior, the amount of specialization required, and the roles played are distinctly different and should not be confused.


  • May I offer a "tongue in cheek" answer: the event type that leads to ACM over BPM is the "process failed" event!

    (Although of course that is more accurately for dynamic business processes over the specialisation that is ACM...).

  • Maybe not so much "process failed" Paul, but rather, "Process too complicated to predefine"?

    Some would argue that any process can be modeled, but at what time and cost? To my thinking there are a number of fairly complex processes, often the ones that provide competitive differentiation through human judgment, that it simply isn't practical to try and capture in a process model as every instance is different.

  • Paul, you make a very good point here. Many people feel that dynamic nature is necessary because "the processes have not been developed yet" or "the process failed to handle the current situaion".

    There is a certain "Newtonian View" of the world that subscribes to the belief that all processes can ultimately be automated, given enough time to write them all down. This was the motivation behind "Office Automation": soon as we have had enough time, all the processes will be automated, and everything will become automatic. In the 1990's MIT sponsored the "Process Handbook" project which was an attempt to collect and publish all the variants of all processes, so we could just pick a process when needed.

    The Newtonian point of view in Physics was shattered by Quantum Mechanics that says that there is a limit to what can be predicted. There is chaos, the butterfly effect, and sensitive dependence on initial conditions. Now we know that the weather more than a week or so out is unpredictable, no matter how much we know about the status of the atmosphere today.

    In physics, our inability to predict the course of a physical system is not simply that we did not measure well enough to start with. Similarly, ACM should not be looked at as simple what is used when we failed to prepare with BPM. There is a space that will never be supportable with pre-defined process diagrams, no matter how hwo much time is invested in preparing them.

  • Mr. Swenson makes a good point about context but I still think we are making a relatively arbitrary distinction. The same event may trigger a highly structured BPM process or a more dynamic and iterative case management process.

    One of our customers, a large Italian auto maker, uses an enterprise resource planning (ERP), enterprise content management (ECM), and business process management (BPM) to manage the reconciliation and eventual payment of tens of thousands of supplier invoices each week. Most of these invoices are generated from highly structured procurement processes and the inbound invoice is easily matched to the purchase order. Business rules are automatically applied, discounts for prompt payment can be calculated, and the settlement is made. In most instances the entire process is automated except for a few approval steps required for very large invoices.

    But a number (roughly 10%) of the invoices come in without the needed information. These invoices are scanned, coded and stored in an enterprise content management system. This kicks off a case that references the invoice and any other supporting material. This case is then assigned to clerks who use search tools and organizational information to match the invoice to the plant or facility that placed the order. The case may pass through many hands, picking up information along the way. At some point the process will declare victory, complete the purchase order match, and the invoice will be settled using the payment portion of the process.

    Both scenarios are handled by the same process and the same technologies – BPM, ECM, and ERP. In this example, using process analysis of the cases that were not automatically handled, the customer is combining dynamic cases, discovering patterns, and using this information to expand the automated process to handle more and more exceptions.

    So is there really a difference?

  • I would side with Tom that it's too complicated to predefine. In the example that Mr. Swenson brings up of heart palpitations, clinicians have protocols that are guidelines, but the decisions or gateways aren't worth capturing in a predefined way. (Good luck getting a doctor to sit in a conference room for that long!) The primary goal of any up-front process design efforts is to ensure that you have the right resources available at the right time at the right place, in order to meet customer demand, right? A secondary goal is to ensure that all process performers know what to do in a particular situation. This is a case where data collection and post-process analysis and stratification of that data is of high value. This allows one to understand the variation in patient/customer profiles by time of day, day of week, week of month, month of year, and to build appropriate staffing models. Another possibility are tools that analyze thousands of possible flows and create one giant hierarchical flow with hundreds of gateways/decisions, but I doubt anyone would ever look at that monstrous flow. I'm a fan of using simulation in strategic cases where variation, complexity, and competition for resources are high...this is one of those cases in my opinion.

Add a Reply

Recently Commented On

Monthly Archives