Start a Discussion
BPM
user-pic

What is the Difference Between Case Management and BPM?

Vote 0 Votes
Another topic that will be covered in-depth at the BPM in Action Virtual Conference: What is the difference between case management and BPM?

And if you want to keep up with all that's going on with BPM, make sure to attend ebizQ's BPM in Action Virtual Conference coming Wednesday, June 23rd.  Attend individual sessions, or stay all day.  Sign up right here.

13 Replies

| Add a Reply
  • Just the amount of effort it takes to build certain categories of business solution!

    I think the question could be extended to "what is the difference between Case Management and BPM or ECM". I would still give the same answer, since most of our component technologies are intended to do the same thing, just in different ways: improve the operations of the business.

    Phil Ayres
    http://blog.consected.com

  • This question hinges on a clear definition of BPM for which there is no general agreement. As you read responses to this question, keep in mind that many people confuse BPM (which is a management practice) with BPM Suite (which is a technological product to support the practice). Many BPM Suites support not only the practice of BPM, but many other management practices as well, and this confuses the entire discussion. For discussion, we should use the wikipedia definition of BPM.

    BPM is a management practice that views the "process" as the most important organizing theme. It can be used only when processes are repeatable. A practitioner of BPM talks about "optimizing a process". In order to optimize a process, there must be a concrete representation of a given process; it must be useful for many individual instances of the process; you must be able to measure how good this process is in abstract from a given case. BPM is a practice of perfecting that process is for the purpose of supporting of future cases. This only works if you have confidence that future cases will be like the cases of the past that you are measuring the process against. In short, the process must be predictable. BPM is based on mass production principles: the up front investment that you make in perfecting the process, is paid back in a increase in efficiency over many instances of the process.

    Case Management is a technique that is useful when processes are not repeatable. A case represents a situation without necessarily requiring a process. Case management can be used for one-off situations for which the process can not be predicted in advance. A practitioner of case management needs a different kind of support: instead of tools to aid in the elaborate design and optimization of a process up front, a case manager need a way to communicate goals and intent. There is no point in investing a lot of up front effort in designing an optimized process -- because it is unlikely to fit the situation, and unlikely to pay back the up front investment -- so instead the investment is in information tools and capabilities that can be used directly by the case manager on demand: such as information collecting tools, and communications resources.

    The two approaches are very different: Sherlock Holmes will use a case management approach, not a BPM approach, when solving a case. Admiral Thad Allen will use a case management approach, not a BPM approach, when responding to the oil disaster. To say that these approaches are the same, because they both help to get work done, ignores the very essence of BPM and case management. Yes, they are both techniques to help accomplish work, but they are different approaches.

    Some will say that since ultimately a sequence of activities is performed, that this is a "process", even for case management. You can retrospectively view that as a process, but not one that can be "improved or optimized" in the way that the practice of BPM needs. Yes, it is true that the case manager gets better over time, because they learn. But to argue that all learning is actually BPM stretches the definition of BPM too far to be useful. BPM remains important as a distinct practice of defining, measuring, and optimizing a process in abstract from a given case. BPM should not mean simply all means of making an organization perform better.

    This has nothing to do with any vendor's product. I am not making a sales pitch here. Those that say their favorite BPMS can do all of this are simply pointing out that these two management practices can be supported with similar technology - and many products will support both approaches. But remember, BPM, and Adaptive Case Management are not technology, not products. They are both approaches to managing work.

    Those interested in this topic should look at the 350 pages that 12 different experts wrote on this subject:

    http://MasteringTheUnpredictable.com/

    Also, look for the Tweet Jam on July 15 where we hope to discuss this publicly.

    -Keith

    http://kswenson.wordpress.com/tag/adaptive-case-management/

  • As Keith points out, the biggest single difference between BPM and Case Management is the repeatability or predictability of the way in which work happens. BPM implementations presume a level of repeatability in the steps taken to accomplish a goal and to complete work. This tends to lead to the "one true process" view of the world where there is a best practice approach to how work is done. On the other hand, Case Management doesn't presume that there is always an order and structure to work. This is consistent with the way many knowledge workers approach their jobs; tasks are completed in different orders based on how and when events happen. This is not to imply that there is no goal or structure, just that there is an acceptance of the variability of the work environment and circumstances.

    Another difference between BPM and Case Management can be found in the approach to implementation. BPMS implementations, by nature of requiring a predefined process model, tend towards an approach where choices and order are predefined to the greatest extent possible. By taking a template based approach where end-users are empowered to make changes at run-time to support their needs, Case Management solutions tend more toward a rolling thunder style of implementation. Requirements and behaviors don't need to be set in stone when the solution is deployed because users are able to add tasks,documents, etc., as the process unfolds, incorporating the best of those into the template over time and based on experiences determined by analytics.

    I presented on this latter concept back in April, the slidecast can be found embedded in a post here: http://www.tomshepherd.net/?p=132

    I'd also second Keith's recommendation to visit the Mastering the Unpredictable site, although I'm biased as I did contribute to the effort.

  • The most general case, I am starting with, is an activity, in which a team of people is treating a problem to solve it.

    Clearly, if the problem has been solved, looking back, we can always determine some solution process, in terms of sufficiently coarse-grained steps. For example, we could file the order, in which team-members were playing their respective roles.

    Refering to this (solution) process, we can distinguish two main issues:

    -  How the team-members are cooperating to achieve the solution, and

    -  How the problem is solved, step by step, in the sense that an unsatisfactory initial
       state of some item is undergoing transitions, until it reaches some satisfactory final    state.

    Obviously, we may distinguish numerous different kinds of processes, each one characterized by a certain style of cooperation-management, and a certain kind of problem, defined by a triple (item, initial state, final state).

    In restricting attention to the problem-side, I am going to distinguish just three cases, in terms of the item: an integral human individual, as distinct from a single living human's body & mind, and any non-living object (leaving aside animals and plants).

    Irrespective of workflow-organization style, we are facing three characteristically different difficulties, when treating these three items to improve their state:

    In case of the human individual,
    treatment is bi-directional, interactive: There is, basically, no difference between the treated and the treating person. Accordingly the state-transition, resulting from a treatment by anyone of the roles involved, is not predictable. We cannot even predict precisely, how the treatment by each role will look like.
    Conclusion: The solution process, including the sequence of roles, is un-predictable.

    In case of a person,
    whose body-&-mind are in an unsatisfactory state, needing (medical) assistance, the treatment is uni-directional, interactive, though there is some more difference between the treated and the treating person. The state-transition, resulting from each team-member's treatment in this case, can be predicted but statistically, not individually.
    Conclusion: At best, a process with the highest probability to be successful can be predicted - and may be chosen.

    In case of a non-living object
    to be brought about in a satisfactory state ('manufactured'), treatment is uni-directional, non-interactive. The state-transition resulting from each role's kind of treatment is fairly predictable (though exceptions are always occuring).
    Conclusion: In this case, we may be lucky to predict, thus, pre-determine (manufacturing) processes, where 'lucky' means, the problem is well-structured in the sense, that consecutive states are related by clear-cut functions/mappings.

    Needless to say, that Case Management pertains to the first case, while what people call BPM, is a particular part of the third case.

    I cannot withstand to add, that the Solution Framework provided by Workstate-Management (www.mastering-it.com), can cover all three cases.

    Thanks


  • I agree with Keith and Tom, that the unpredictability of the process is a key indicator of whether the work should handled via a case management approach, or via process management approach.

    This inherent unpredictability has interesting implications of how the two different approaches need to work in the real world:
    1. In a case management approach participants control the process, and change it on a case-by-case basis. They (and not a process owner) have complete control over the case. They are expected to manage
    o Flow changes
    o Participant changes
    o Activity changes
    to meet the needs of the case. Process management will allow some level of participant control, but that on a limited basis. The process owner has a lot of control, even when they don't play a direct participatory role in a specific process instance.
    2. Since the work can't be rigorously defined ahead of time, each case instance must have a goal, deadline and a defined work product. In process management these can be replaced by a model of the process.
    3. Every case instance needs an owner for that instance. In a process management approach there doesn't need to be an owner for every instance, but there needs to be one for the process and its model.
    4. Since a case consists mainly of interactions between human participants, managing collaboration and negotiation are key parts of a case management approach. This isn't true for for process management - many would argue that eliminating these "time wasters" are one of the goals of a process management approach.
    5. In a case management approach, content is an integral part of the work, it is both consumed and produced as part of the process. Content is important for a process approach, but not as central.

    So these approaches are a very different way to get work done, and the tools need to reflect these very difffernt patterns of work. Each works better for a specific type of work. Yes, you can do case like things with BPM, or process like things with a case management system - but that is like saying screws and screwdrivers aren't important - since we can just use a hammer and nails for everything.
    Jacob Ukelson - CTO ActionBase

  • There is quite a big difference, and yet both are very similar when you try to look at things from an Agile perspective.

    The big difference is process, or as it has been said by other comments here, repeatability. BPM typically means you have a process that work flows down. With case management you dont have a process as such, rather you have a single "step" in a process and with it you have a number of tasks that need to be completed....This does mean that the way work is takled can be different based on the user and other variables, this isnt the case with BPM...

    Case Management isnt BPM as it doesnt have the capabilities to introduce real process and real flow of work, however it is far more flexible than many BPM offerings out there (unless of course you opt for a highly adaptive and agile BPM engine...) I often see case management as the poor relation to BPM, however in reality both have their place and both can be equally valuable to an organisation.

    I have posted about this very question a couple of times and have had some lively conversation around this .... http://andrewonedegree.wordpress.com/2009/09/09/case-management-isnt-bpm/ At the end of the day, I see the future as a mergence of many silos, already at my own company we have merged Case Management and BPM, so from our software point of view there is no difference, but from a "practice" point of view, the differences are plain to see....

  • after reading some other posts I would like to say that a good BPM platform will provide all the tools that are spoken about for Case Management. Content and collaboration can be at the heart of a BPM process just as much as it can with Case Management...

    My concern is that many people talk about case management and try to make it sound like it is unique in what it does, that it has a unique bunch of tools that BPM cannot provide, that simply isnt true...

    Granted typicall BPM can be more restrictive, however, this isnt the BPM practice that is restrictive, rather the platform you use. Good BPM platforms are highly agile and adaptive and they can cater for anything that you require from a case management solution...Adaptive BPM is where we should be moving too, http://andrewonedegree.wordpress.com/2010/03/24/adaptive-bpm-no-mapping-tools/ and moving away from strict process maps that are too restrictive....

    My point is that, BPM can deliver case management as a practice, but case management cannot be considered or start to deliver BPM...

  • Andrew,

    You are getting "BPMS products" confused with the management practice of BPM. BPM does not in any situation "deliver" case management, and case management similarly does not deliver BPM. These are simply two different approached to solving business problems.

    What you are trying to say, is that a "good" BPMS product can support both a BPM approach and Case Management approach. OK, that is fair enough. But most BPMS products are not "good" but this definition, and most BPM products can NOT support case management.

    You say people "try to make [case management] sound like it is unique in what it does, that it has a unique bunch of tools that BPM cannot provide"

    Again, you are confusing a BPMS product with the management practice of BPM. Case management is distinct from BPM, and it does require significantly different features and functionality. See Jacob's post above.

    Anyone who believes that the management practice of BPM is the same as the practice of case management, probably does not understand one or the other of these. There is a lot of disinformation out there.

    But most often, people are claiming that their favorite "BPMS product" can support both. That is possible, but it does not mean that BPM and case management are the same thing.

    Think for a moment what case management requires

    The case manager is a person from any profession: a salesman, a doctor, a lawyer, a CEO, a fireman. Many BPM products require you to use a BPMN process designer that assumes a knowledge of programming (i.e. throwing exceptions, writing expressions, allocating variables, calling web services, etc). Take that process modeler down to your local 7-11 convenience store, and ask the manager to use that to manage a "case" without any training. Most BPM products assume a person known as a "process analyst" to draw process diagrams. But in case management, you simply can not require a process analyst, and even less a programmer. A case manager has to be able to do everything unaided by anyone else.

    Sure, it true, a BPMS product could have a tool that the 7-11 manager can use without training, but the fact remains that most of them DON'T. They don't have them because the process designer was simply never intended for use by a 7-11 manager -- which eliminates it from consideration as system that can support case management. Note that it is not a technical capability, but a usability constraint the eliminates most BPMS system.

    A lot of people, even industry analysts, simply do not "get" that a product for supporting case management needs to be designed so that ANY person in the organization can use it WITHOUT any IT involvement. Like email can be used by anyone.

    The reason we draw a sharp distinction is to get people to think about what it means to have a case manager responsible for every aspect of a case. It is important to be able to talk clearly about the needs of people who are knowledge workers, and NOT to bury it as simply another thing that a BPMS could support.

    In the end, you are right: a "good" BPMS product could support a case management approach. A "good" ECM product could support case management as well. But in truth, very few of BPM Suites have been designed to be run by untrained non-IT professionals.

  • It seems, I have to make some definitional statement, to clarify my above answer to Peter's question, as I understood it. For me, as for virtually all people 'out there', Case Management is what you find, if you google on 'Case Management'. If you are thinking and speaking of something else, please, forget my contribution. Sorry for my lack of understanding your 'deviant' usage of the term.

  • Keith

    I think you have hit the problem that I am getting at. You immediately think of BPM product or BPM as a practice, as having to have a BPM designer, one that someone in IT or at least a BA uses to define rigid processes. This is my point, this is an old way of looking at things, we need to move forward and evolve...If you have a BPM platform that is highly adaptive, then users themeseleves (no need for IT or BAs) can define and redefine processes. This way 100% of busines processes can gradually become apart of the BPM solution. The old fashion way of using a design and creating rigid processes up front does mean you need IT or someone, and with these types of solutions, you are right, they cannot deliver case management....

    My point is though, adaptive BPM platforms and adaptive BPM as a practice can easily deliver Case Management. However, a case management platform cannot deliver BPM...This is where Case Management and BPM effectively merge, and shouldnt be seen as something very different, we should be moving towards this and getting rid of the barriers and strict distinctions between the two....This is something we have been working on here and are achieving, I also no that Papyrus already deliver highly adaptive BPM that merges what you may term as Case Managemetn and BPM....

    There are many differences between traditional Case Management and traditional BPM, however, we should be moving to a place where these "merge", and that is what we aim to deliver...Adaptive BPM as a practice and as a solution can and will deliver case management

  • Andrew,
    I think both Keith and I are talking about the "next generation" of case management tools - some call it "adaptive case management", some "dynamic case management", some "advanced case management" etc.

    Sorry to get uber-techy, but it seems like your argument is equivalent to "Assembler can do everything Java can do, but Java can't do everything Assembler can do - therefor Assembler is better for everything..."

    My point is that the tooling available drives the way people think of a problem, and how they approach a solution - "if all you have is a hammer eveything looks like a nail".

    For me - a BPM approach wants centralized control of the way a process is done - that isn't a bad thing - it depends on the process. I believe the "next-generation" of case management is about providing the necessary support to process participants (and their management) to manage the process. It is a subtle difference - but an important one in the real world, and I believe it requires a different set of tools and approaches(not that they couldn't be brought together under a "suite" notion).

    There was an article in Communications of the ACM a long while back titled "AFFORDANCES, MOTIVATION, and the DESIGN of USER INTERFACES" where we describe how these subtle distinctions make all the difference when building (or selecting) a tool. I think the ideas are relevant here too.

    Jacob Ukelson - CTO ActionBase

  • In my contribution above (June 17th), I tried to illuminate the relationship between Case Management and properly utilized Business-Process Management. But what about the relationship between Case Management and Business-Process Management, as used today, following the respective hype of IT-vendors.

    These systems are not restricted to the handling of non-living objects, but are implementing inter-departmental BPM-systems, targeted (among others) at treating people interaction. They, therefore, don't belong to the third case of the typology I am using. Nor do they pertain to the second case. As a matter of fact, they are representing the first case, thus, Case Management.

    This is a strange finding, in that Case Management is 'treating' people who are down with their philosophy of life.

    Formally,
    this reasoning would imply that people working with such inter-departmental BPM systems, are 'down'.

    Translated into practice,
    this would mean, those people should behave as if down and dependent on being guided in their life-activity.

    What do we observe?
    Could it be that (some) people, working under the regime of EAI-based BPM-systems are, in fact, becoming candidates for Case Management? Just in this case, Business-Process Management and Case Management would be essentially the same.

  • I would like to talk about the commonality between BPM and CM. I think, they are important parts of the continuum of “techniques? to help the business to get the job done. I already wrote about this in http://improving-bpm-systems.blogspot.com/2010/04/let-us-architect-use-of-existing.html.

    Keith is correct that we should not mix BPM as a discipline and BPM as software products (or BPMS). And Andrew actually added the third concept – the use of BPM, i.e. how the BPM discipline and some BPMS are applied within an enterprise.

    I use the following definition of the BPM discipline -- better management of an enterprise via modelling, automating, execution, controlling, measuring and optimising the flow of business activities that span the enterprise’s systems, employees, customers and partners within and beyond the enterprise boundaries.

    The meaning of the word “model? has to be clarified. It means to make known, to describe or to communicate a plan (or plan of work or process template) of how to carry out future actions to obtain a desired outcome. The word “automate? means to instrument the proposed plan of work by some existing or new tools. The word “execute? means coordinate different activities to obtain a desired outcome. This coordination may be strong (a BPMN diagram) or weak (the outcome only). Thanks to stronger coordination, the measurement can provide some evaluation of expected outcome thus helping us to be more proactive in the optimisation.

    In the use of BPM, some of those 6 BPM functions (model, automate, execute, control, measure, and optimise) can be:
    • present or not,
    • implicit (make a plan in your mind) or explicit (express it as a BPMN or Gantt diagram) ,
    • applied iteratively and continuously,
    • applied for process templates or process instances.
    The last item from this list is important. Those 6 BPM functions can be used at different granularity – for example, after each completed activity one can model, automate, etc. the rest of the job to be done (although this is not yet very efficient with current BPM tools).

    Based on this schema I try to describe a few examples of BPM and CM.
    1. “Classic? quality management system
    modelling – explicit with the maximum planning horizon
    automating – out of the scope
    execution – out of the scope
    some control, measurement -- sometimes completely absent
    optimization – reactive (applied for templates).

    2. Sherlock Holmes
    modelling – implicit with the planning horizon for a few next steps
    automating – implicit (except some dialogs with Dr Watson)
    execution – mainly via weak coordination (it is a specific of his work)
    control and measurement – implicit
    optimization – reactive (building the knowledge).

    3. “Typical? BPM done ideally (everything is explicit)
    execution – strong coordination
    optimization – can be proactive (if it is anticipated in modelling) in some extend.

    4. Case Management (please feel free to correct)
    modelling – absent (no planning horizon?) or implicit (in the head of a case manager)
    automating – done in advance
    execution – weak coordination
    control -- ??
    measurement – can be explicit (via the support from decision management)
    optimization – active (applied for instances).

    5. Project management
    modelling – explicit (but very coarse-grained) with the maximum planning horizon
    automating -- ??
    execution – weak coordination
    control -- all variations
    measurement – all variations
    optimization – active (applied for instances) and reactive (mainly as lessons learnt).

    Ideally, the people who are responsible for getting some job done should be able to change when they want: a) the depth of planning horizon (even to have a few scenarios to be better prepared for the unpredicted) and b) the level (strong or weak) of coordination. So, the both of them can be considered as continuous (not “binary?) characteristics.

    Thus, BPM and CM are clusters at the same continuum of “techniques? to help the business to get the job done. By considering them together we can give more consistent message to the business (see the forest but not the trees) and to the software industry (please develop the missing functionality which can interoperate instead of duplicating it in many products).

    Thanks,
    AS

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT