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

Will case management soon take over BPM?

Vote 0 Votes
While this post asks if case management will replace BPM? do you think ACM will soon take over BPM? Has it already?

21 Replies

| Add a Reply
  • BPM has been applied to all types of workflows. I would ask if BPM will just subsume case management.

  • This is less a question of BPM vs ACM but rather what a business wants to achieve. Traditionally, BPM centers around control, simplification, elimination of variation, cutting costs, and reduction of complexity.
    Rightly understood, complexity cannot be reduced as these two concepts contradict each other, the cost cutting remains doubtful if you keep in mind the cost of the governance overhead, and the rest fits only for a small proportion of modern jobs and workplaces.
    The reality is that most processes are as unpredictable as their participants because they involve human interaction and can therefore be best defined by the process owners themselves. The key word is empowerment, and yes, business users need that information and data as described in the related post but they also need the authority and the means to make decisions accordingly based on their experience and judgment and in line with their goals and transparently defined targets and strategic business objectives to achieve an outcome that's right for the customers. Getting the knowledge about successful outcomes back into the business and its processes is a key to innovation, no matter how you call it.

  • ACM take over from BPM. No, why? Because ACM doesnt solve the problem in the same fashion as BPM, it doesnt work as well as BPM for highly structured processes, so it cant take over.

    Its popularity may well grow and we may see implementations that were once traditional BPM areas being thrown open to ACM, but this doesnt mean replacement.

    I believe APG is the evolution of BPM, encorporating BPM capabilities for highly structured processes (with adaptive capabilities), and ACM thinking for dealing with highly unstructured processes.

    At the end of the day though, everything is still tackling the same business problem, that of managing processes...

  • Not a hope! And neither will BPM take over Case Management.

    For the best solutions to business problems we can take pieces from each, but one is over-stretching if it thinks it can do the job of the other.

    There is too much information management and content in Case Management for BPM to do a good job, and too much finicky process design and measurement in BPM for Case Management. Even the big software companies with both seem to have failed to bring the two together in a convincing way, as have the practitioners who are experts in the methodologies of BPM or case management.

    Some business processes need the strengths and technology of BPM. Others just don't, and will do fine being managed with a Case Management solution. Where requirements are general and cross the functionality of both product types, either could do the job. Its the many exceptions that show us that there is a need for both.

    Phil Ayres

  • It is completely irrelevant if how a business implements processes is called by someone BPM, ACM, APG or 'KMA'.

    BPM in general doesn't have any strength that Case Management in generla lacks. There are differences in priducts, that all. BPM governance is too costly and too rigid and possibly that will be replaced by enhancements in the area of 'social' to the point that it will be difficult to distinguish between BPM and ACM. But then people who apply BPM methodologies are more control-oriented and people who use case management are more empowerment oriented.

    People make sll sorts of assumption what ACM or BPM entails and they are all wrong. Products and definition change day by day and neither acronym is well enough defined to make such as statement.

    Let's focus on solving business needs!

  • Ha! Only in the ACM blogosphere would such a question even be asked. Case management is a style of BPM in which processes are more event-driven and unstructured than "traditional" workflow. BPMN is not a great fit for case management, and case requires specially tailored UI for the case folder, but the fact that dedicated case management software exists is an artifact of its "newness" (the technology, not the problem). When the mainstream providers offer both structured BPM and case on the same platform, does anyone believe the case guys have a chance?

    • "When the mainstream providers offer both structured BPM and case on the same platform, does anyone believe the case guys have a chance?" Denial isn't just a river in Egypt.

  • There is no red line separating cases from processes - these two overlap, compliment and mutate. Hence my bet is ACM-enabled BPM.

  • The way I see it, most of the time, it’s not an either/or scenario. A Culture that promotes Process management still needs Case Management, and vice-versa. It just depends on how you look at it, and how you “intend? to handle “things? that may eventually take the form of a case or a process. Agreed, there are situations that demand one approach againstother, but it's because the demands of the business are such due to the way they want it to execute. It's the culture they want to promote in the area.

    I posted this some time back, I still hold the same pov -

  • I'm with Anatoly and Ashish on this: it's a spectrum of capabilities, not either or. At one of the spectrum are highly-structured processes, such as regulatory and compliance processes; at the other end is completely ad hoc, such as innovation management. In between, however, you find all flavors of the rainbow: ad hoc with some structured process snippets (e.g., insurance claims processes, where some of the functions that a work may select to include on a case are actually predefined subprocesses that have to be executed in a specific way for regulatory reasons), and structured with ad hoc pieces for exception management (e.g., financial services transaction processing). Although a lot of my work has been in the more structured side because I work with financial services back offices, it's never purely structured, and sometimes is quite far along the spectrum towards the dynamic, ad hoc end.

  • I'm not going to copy paste the article written in the past : ACM under the BPM umbrella regarding a previous discussion started here in ebizQ http://ultrabpm.wordpress.com/2011/02/01/acm-is-under-bpm-umbrella/ but I have definitively the idea that ACM is a way, a method to manage unstructured processes, like six sigma is to reduce structured process variability.

  • I agree with Sandy - there is a spectrum of process "structuredness" that flows from the very structured (which is handled very well by a BPMS) to completely unstructured (which is usually handled by documents and email) which BPMS doesn't handle very well and my opinion isn't really the appropriate tool).

    The way I see it, traditional case management (and no Bruce it isn't very new - case management tools have been a staple of the legal and medical domains for a long time - well before BPMS) is somewhere towards the unstructured end of the spectrum. Adaptive Case Management (as least my view) is at the very unstructured end, trying to support the same type of unstructured use cases covered by email.

    I think the questions are: Will BPM and case management converge? Will ECM and case management converge? - or will there be a new category of Case Management - Adaptive Case Management which covers what used to be specialized Case Management tools - but extends it to become a platform for more general use cases and as a general purpose tool for knowledge work.

    jacob Ukelson - CTO ActionBase

  • I agree with everyone who has said "no". I don't believe that anything will "take over" anything. BPM is for repeatable, defined, "structured", processes. Case management is for knowledge workers who figure out what they are going to do when they do it, and for whom the effort of developing a predefined process would never pay off. I think Sandy says it best, but fine posts by many others in the list.

    To express this in terms of current events: the team struggling with the Fukushima power plant are doing "case management" right now, NOT BPM. To suggest that what they are doing is BPM, is to completely miss the point about what BPM is. Those people are leveraging every scrap of knowledge, every bit of skill, and every resource they can, to handle the details of the current situation. They are NOT drawing BPMN diagrams, they are not perfecting business processes, and they are NOT as Bruce suggests drawing BPMN diagrams that respond to external events.

    Even stranger is the OMG stance that case management is simply a style of drawing diagrams that respond to external events. This is not handling unpredictability. If you can predict that an event might occur, and if you can draw up a description of what you want to do (in any language) in response to that event, then this situation is entirely predictable. This all assumes that the "event" in question is an electronic message, not a hydrogen explosion.

    I think it was Heisenberg who said that if you don't find quantum mechanics deeply disturbing, then you probably don't understand it. Similarly, those who believe that BPM and ACM are ultimately the same thing, probably don't understand one of them.

  • Yes, as Keith says, BPM and ACM are separate - and there's more.

    Rarely in organizational life are processes "completely ad hoc", even (or especially) strategic, critical processes such as "innovation management". Rather, there are processes that cannot be dealt with either as structured workflows (BPM) or as incidents requiring handling (ACM).

    For example, R&D, project management, M&A, and organizational change generally fall outside both BPM and ACM - yet the treatment of this high-value work in process terms is a vital enabler of organizational success.

    For such work you need Human Interaction Management (HIM), which provides the right combination of structure and flexibility, as well as allowing work to cross boundaries of any kind in the same way as email (i.e., without need for everyone involved to use the same server).

  • I tend to agree with Jacob, that convergence is the more likely outcome. And the reason I believe this is due to Sandy and others' points that work (not cases or processes) exists along a spectrum, from totally unstructured, to totally unstructured, and that any work that is examined with any level of scrutiny will prove to combine work from all along that spectrum.

    Because this is a spectrum, and not a binary question of structured or unstructured work, is exactly why an either/or approach just doesn't work, and likewise why general purpose case management tools will not fit the bill. Such an approach is hardly better than the email trails that currently "manage" the work--it just creates another work silo.

    Cases and processes separate, but tightly linked concepts (see post here: http://www.pega.com/community/pega-blog/the-distinction-between-case-and-process ) A case is the work to be done, and the process is the path it takes as it is completed. In the example of highly unstructured work, that path is being defined as the person or people complete it. And at the other end is work that has a well-defined process. But again, cases (i.e. work) are typically made up of a number of different pieces of work that fall all along this spectrum.

    The last reason why I think it is a mistake to think of this in terms of either/or is that most organizations and people want to move their unstructured work further down the spectrum towards greater structure. This is because after you do something once you have identified some best practices for how to handle that type of event in the future, whether that is content generated, a process here or there, what the overall breakdown of the work is, who is best equipped to handle what, etc.. Taking a binary view of case and process doesn't allow you to migrate work from one end of the spectrum to the other, just as it doesn't allow you to handle work from across the spetrum.

    Certainly the workers at the Fukushima power plant are performing in an awful, ad hoc scenario, but they are also doubtless applying many tried-and-true processes and policies, and identifying new ones through their heroic actions.

  • Both are neither the same nor will take over each other (except maybe from the marketiing/buzzword point of view), but are special cases of a broader concept, indeed.

    A sound unifying concept including a corresponding modelling language is UBPML (Unified Business Process Modelling Language).

    The key elements of UBPML and the various approaches (BPM, (A)CM...) are compared at this page:


    Please note: this is a wiki and if you like to leave comments there or propose different views, feel free to do so.


  • I think its like Sport.
    There is a structured process to achieve your victory but on the field you must improvise to achieve victory without deviating too much from the structure.

    In a nutshell, both are needed. Depending on the business scenario and its environment and users, you may adopt either or both.

    Do we have to compare everything? Both the Apple and the Orange have their place. Let your recipe determine your ingredient. Not vice versa.

  • It really boils down to the problem people are trying to solve. As many have said before me, the ACM vs. BPM discussion is really more of a vendor discussion than a user discussion. Vendors who are stronger on one side of the fence than the other will tend to defend the longevity of their solution. In reality, the business are seeking better ways to get today's work done. The construct of that work may take on different forms of structured and unstructured work; I would venture to say that most types of work do not fall explicitly into one bucket or another. Therefore, as Ashish says and ACM and BPM, "it not an either/or scenario" for users (or the vendors that serve them for that matter).

  • More likely: the definition for "BPM" will eventually be corrected to allow for all types of business processes, including case / ad-hoc / dynamic processes, event-driven processes, etc etc.

    I really think the "BPM = some orchestration of process tasks" definition is one of the dumbest around; surely this is now an albatross around the BPM industry's neck!

  • Paul,
    I think you and I are saying the same thing. Instead of albatross, try "straw man." No leading BPMS provider is going to neglect the case/dynamic/event-driven process style... no matter how much the ACM boosters insist they will. If BPMN doesn't fit for that style, so be it. BPM (and BPMS) is more than orchestration of simple task flows.

  • Something inbetween albatross and straw man.

    While the BPMN ad-hoc process concept hints into the right direction, there is more to do than just cut control flow arrows to become as flexible as it might be apt.

    On the other hand, I don't see that the alternative approach of socially coupled documents will do it either.

    Anyway, the relationship between traditional BPM and (A)CM is really easy to see, once you take notice of the unified model (UBPML) underlying both.

Add a Reply

Recently Commented On

Monthly Archives