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

Should ACM and BPM be kept separate?

Vote 0 Votes
Awhile ago I asked the forum, What type of event leads to BPM vs. what type of event leads to ACM? which made me think, Do you think it make sense to keep adaptive case management and BPM separate?

10 Replies

| Add a Reply
  • The difference between ACM and BPM is a distintion without a difference. That said, if you do talk about these 2 kinds of things in your shop, they are more likely different use cases of the same thing. If the business processes differ in some radical fashion, then keep them apart.

    Bill Roth

    • Bill, typical BPM products are not capable to perform unstructured processes. Therefore it is not the same thing. But as I said in my response, I see ACM as a kind of BPM. It would be a use-case that can't be handled by the existing BPM solutions and that is the reason that a different terminology was chosen.

  • The simple answer is NO. Why? Any structured process can at any time turn into an unstructured one through any unexpected event. Further, why should one department use two different tools for processes/cases.

    I see ACM as an expansion of BPM principles into unstructured and social interaction. That is not widely accepted.

    On the other hand, the analyst community has refused to accept the ACM termnology (NIH syndrome) and use DCM for dynamic, even though that only deals with Ad-Hoc processes and does not cover the user creation/adaptation of process templates. Therefore the incumbent BPM vendors with Social and dynamic capabilities are now also the 'leading' DCM vendors. Therefore the reality is that adaptive/dynamic capability is now part of BPM even if most vendors have no capability for enduser creation of process without a flowchart editor.

  • What a daft question - of course not. As traditionally interpreted, they represent different ends of the same spectrum.

    And Max is right, in the sense that processes tend to flip flop from one end of the spectrum to the other.

    Otoh, he's wrong on DCM/ACM - god knows where you got the idea that DCM only deals with ad hoc processes. If an incumbent vendor can deal with the unfolding/adaptive/dynamic aspects of the world, dynamically combining processes, allowing folks to move to unstructured as they need to ... then what's the problem (apart from it not describing his product).

    I have answered to this distinction elsewhere more than once.

  • Normally this is where I chime in and say "what he said" :)
    Max and Derek have neatly covered it, I think...

  • Yes, in the sense that they will both be part of a business process practioner's toolbox. Just like in a toolbox the connection will be as a suite of tools, not as a single monolithic tool that solves both ends of the process spectrum.
    The reason that they can't be a single monolithic tool is because ACM and BPM approach the world of process differently - BPM brings rigorous control to business processes (and the focus is on the model and leveraging that model), while ACM tries to facilitate, monitor and track emergent unpredictable processes (without a model -only artifacts like frameworks, templates and checklists). These different approaches require different tools (just like a hammer vs. a screwdriver - you need both).
    It will be easy to recognize when it happens - a BPM\ACM suite will be successful when the use of it surpasses the use of email and excel\word for real world business processes.

    Jacob Ukelson - CTO ActionBase

  • No, I see BPM and ACM potentially enabled by one solution platform. Or in other words, ACM is a use case for a BPM Suite with some extra capabilities.

  • Although it is true that most BPMS on the market today do not do ACM well, in the future these two disciplines will absolutely have to merge. Most business process involve a combination of both. For example, you might have a principle ACM process, but many of the activities that get executed in the ACM framework will be better managed using BPM constructs. I have written extensively about the BPM vs. ACM discussion in this blog article - http://bit.ly/kBF0z1

    Brian Reale

  • Absolutely not. The argument that systems cannot handle both type of processes is wrong because if they can, what happens?

    Are we going diving to the abyss of the siloed process type? People are striving to get rid of silos for years and we are promoting systems and siloed process types, just for the fact that they are different?

    I posted some time ago a solution to blend ACM and BPM - the Decorator:


  • user-pic

    Yes it makes sense to keep them separate.

    For me it comes down to Timing and Predictability. Using the simple example of account opening, I will try to explain my thoughts:

    Timing - Whether I am opening an account, complaining about service or closing it, the relationship between the two entities (my account and me!) remains the same. Timing is irrelevant and the relationship must be maintained even if the activity or process is complete

    Predictability - When I want to open that account, I MUST go through certain steps - fill in the form, confirm credit rating, get approval etc. No matter what, those are the steps, they are predictable and set in stone (almost)

    ACM is better for the first situation, BPM is better for the second. There's a world of grey inbetween but that's how I arrange it in my mind.

    Mike Marin, a Distinguished Engineer in the ACM space at IBM, delivered an excellent paper on this at IMPACT2011 which I am paraphrasing, possibly too simplistically, but that's how I see it

Add a Reply

Recently Commented On

Monthly Archives