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's the Difference Between Case Management and BPM?

Vote 0 Votes
There has been some discussion lately about companies thinking they're running BPM when in fact they have a Case Management Solution.  So what's the difference, and what type of metrics should a company use when deciding on a solution?

11 Replies

| Add a Reply
  • Case management is an instance of a specific business process focused on managing a long running asynchronous business process, typically around the gathering of disparate, non-related materials and then generating a decision or outcome based on those materials.

  • In my opinion Case Management deals with processes which can change unpredictably. These business processes have a model to follow but usually they need to flow some documents and records through them in addition to several real-time decisions. Generally, these decisions cannot be foreseen, so Case Management demands deep flexibility for "in-the-flight" process changing.
    On the other hand we have the commom BPM, focused on business process Modeling, Simulation, Publishing, Automation, Monitoring, Analyzing and Optimization. I see BPM as a foundation for human-centric business processes, integration-centric business processes, document-centric business processes, and obviously Case Management (business processes).

  • JP Morgenthal's description is quite good; I'd add this, from a more "business-intelligence/decision-management" focused perspective:

    Case management is a repeatable, rules-based set of transactions, which takes into account specific sets of information-inputs, applies pre-defined decision guidelines, and then produces a "justified" decision, based on selected norms or rules which apply to that particular instance or transactional event.

    In a broader sense, "case management" is the overall historical collection of inputs/guidelines/decisions/outcomes which have been acted-upon or produced, along with the resulting "institutional memory" which describes the means by which either similar events or newly-encountered situational events are intended to be managed.

    Ideally, this "institutional memory" establishes a baseline for future cases, and serves to build a "case history" based on past experience, along with the audit-trail-tracking of business rules applied and the changes that are made to those rules over time. The case management history, if effective, must be able to explaing WHAT information was available at the time to describe the situation, WHY a given decision was reached, WHICH RULES applied at the time, and in context, WHY or WHY NOT to apply those same constraints and judegements to a new case when it arises.

  • I am in violent agreement with the responses above, but thought I'd add my two cents anyway. For me, BPM (whether implemented in software or not) requires the definition of a process model. If you use a BPM suite, this process model is what drives the rest of the software development.

    For case management the process is driven by the specifics of the case (its content, the actors involved) and less by some predefined model (there may be some best practice or guidelines) but in general things are handled on a case-by-case basis.

    For me, case management is an example of a class of human-centric, ad-hoc, unstructured processes that need to be managed. Being unstructured processes, most organizations use documents and email for their case management.

  • Anonymous posted:
    "Case management is a repeatable, rules-based set of transactions, which takes into account specific sets of information-inputs, applies pre-defined decision guidelines, and then produces a "justified" decision, based on selected norms or rules which apply to that particular instance or transactional event."

    This is spot on. My suggestion is that there is NOT just one Case Management process instance centered on the Case itself, but rather many parallel process instances centered on the documents (transactions) that contribute to the Case outcome in addition to the Case centered process.

    None of these parallel process instances can exist without a Case process instance and they have a lifecycle of their own. They will likely depend on the current state of the Case and can potentially affect the starting/stoping of the Case process instance as well as influence the next state of the Case itself.

    Adopting such a parallel process view of Case processing reduces the need to change the Case process instance on-the-fly to fit the events and situations that may or may not occur for each individual Case. Once a parallel process is triggered by the receipt of a document or timed event it is managed seperately and business rules can be applied upon its completion contribute to the state/history (memory) of the Case.

  • There are several dimensions that characterize “Case Management.? Here are few of them. First, in CM the focus is on the case. Multiple active policies and processes could be processing a case at any given time. A case has meta-data and content (e.g. documents). Second, cases typically have case “subjects? – these could be customers, employees, citizens, or other. The subjects and the processes in cases will have many-to-many relationships with one another. Third, Case Management supports ad-hoc as well as dynamic processes (vs. structured process template- process instance capabilities). Some processes for subjects will be structured but most will be ad-hoc. Fourth, cases generate and respond to case events. Fifth, cases have states such as Open, Waiting, Closed, etc. You should have flexibility in transitions between case states. These requirements are not exhaustive, but do capture some of the more important capabilities that companies should look for in a CM solution.

    Now how do these relate to BPM? Well, one approach is to leverage a BPM suite that supports the aforementioned CM requirements as core BPM capabilities. This is perhaps the best option: where companies can choose to leverage the CM specific features in the BPM platform to build their CM applications, while benefiting from the model driven development and support for change/agility that are the salient features of BPMSs. There are other options: including building Case Management solutions on top of a BPM suite, as an application; or leveraging CM platforms or point solutions with CM focused capabilities.

  • Case Management is a very unique instance of BPM which, as many of the comments above point out, involves a much more unpredictable, ad hoc progression/flow. The "extreme" ad hoc focus of case management brings with it a unique set of challenges and a customer with case management needs should ask the following questions:
    1) How does the case management tool draw a visual of the process? Remember, in case management the picture comes after not before the process as is the case with most BPM diagrams
    2) How is time to be measured especially with respect to alerts and triggers (t- vs. t+) ?
    3) What should the case history look like? This can be extremely important especially if this is going to be used in police/legal environments.

  • The majority of BPM products enable users to model and execute very structured, prescriptive standard processes that are rules based. These tools automate the interaction with human participants and systems involved in a pre-defined way.

    However, the majority of people don’t work that way. Few people follow a strict sequence of operations when completing their daily tasks. In fact, one of the main reasons that a task cannot (or will not) be completely automated seems to be that it requires humans to use their intimate knowledge of the process, to adjust the contents of a task to fit the requirements of a particular instance. BPM just doesn’t help. So we need an alternative approach, but an alternative that is inextricably linked to the overall process. Case management is a subset of process management in that the case handling is what takes place at one or more nodes (or steps) in the process.

    This means that we define case management as follows:

    A case, is usually a component of a larger business process (but not always), that involves a collection of activities or tasks. However, unlike BPM, the process from initiation to completion of the case is not easily constrained to a process diagram. This is because the interactions are unpredictable and the focus is on the work to be done, not the process to support it. So which activities need to be performed in order to complete the case depends on the details of each instance.
    Furthermore, users can add new tasks, data objects, documents - even new processes - to the case while it is processing. Case management inherently carries with it fluidity of structure in an ad-hoc manner.

  • Case Management is really about the flexibility to adapt to an uncertain or unpredictable business process. It is fascinating to see where on the spectrum of flexibility companies end up. Some choose to go the route of a structured process to control the flow of the case(as Jon points out above). Others end up with no structured process at all and simply rely on ad-hoc tasks and case status for controlling and monitoring the process.

    A robust process engine accessible from the CM solution adds substantial value through automation of repetitive tasks, especially when linked to predefined task "templates". With that said, the case is generally the central or coordinating object and doesn't require the engine in every scenario.

    Ad-hoc capabilities are critical. Users need to be empowered to decide on the fly what needs to be done, have the ability to assign tasks and deadlines, and be able to deal with the events that happen around the case as they happen(a customer calls, a document is received, a deadline is passed). That also implies that many people may be working on the same case concurrently, which is generally not something a BPMS allows.

    Analytics, reporting and monitoring are equally important. Providing the user with the ability to do their job in a means that makes sense to them and allows them to exercise their experience and judgement does not imply a lack of accountability. Not only do we need to ensure deadlines and SLAs are met but we need to be able to learn from our experience, therefore tracking is a necessity.

    Given the information-rich nature of CM processes, support for both structured (data) and unstructured (documents) content is a must have. A link to a folder where groups of documents about a case isn't sufficient. Instead a true CM solution should have an intimate understanding of the content associated with the case, including the idea that documents don't live just in the case but can exist on their own as well.

    Case Management provides people with solutions to "real world" processes, where everything isn't neat and tidy and you can't distill the process down to a picture. Ultimately, it's about adapting the tool to the way people apply their judgement and experience rather than forcing people to adapt to the tool.

  • Whether or not BPM software should be used to implement case management - I think it is important for Case Management to be put in the context of an overall process.

    At some level, all this case management should, at some point, exit and enter larger process-oriented views of the world - ie, we should have finished managing the case and have moved it into a "resolved" state.

    By plugging Case Mgmt into the larger process context, we can collect metrics and correlations about the cases to help us understand our business better: which types of cases are taking the longest to process, which types of cases are associated with bad customer service scores or a failure to renew business. Once we find these problematic case types, we can investigate whether a more managed process is necessary for a subset of cases.

    Key thing: put those case management black boxes into process context. Leverage process tools within the black box when you can. Without process context, Case Management can too easily become "data management" and lose all sense of the business process being serviced.

  • Great comments from everybody - thanks so much.

    Key themes I'm picking up on are: 1) CM is typically more ad-hoc / dynamic / long lived, its more People Centric than System Centric, it relies more on processing unstructured data; and finally - BPMS systems today don't handle CM very well!

    I manage the Process and Service Effetiveness practice for Booz and Company - and I'm really glad this topic has come up (at last). I was ex BPM head for large Bank so certainly agree that BPMS just isnt there yet with respect to the true needs of CM. Vendors are catching on and enhancing their offerings ... but my view is that most of the major BPM vendor offerings today have more DNA in common with old world EAI than a real need to address CM.

    When you think about CM, its origins (from a conceptual perspective anyway) are from areas such as law/justice, health, and service industries in general ... (I have worked in these areas) ... this is where lots of fragmented data sources need to be collated and managed in the interests of progressing a service request from clients/customers. Cases are retained as records typically for purposes of audit and a future need to 'open' and ammend a case based on new service requests. This typically all used to be paper based. Now that we have more digitized content its really about marshalling the sources of electrons to support the same notion of a case - and basically progressing a case in the interest of satisying a client/customer request within agreed SLA/customer expectations (where they exist).

    I think the vendors have fragmented their tech offerings so much that business has lost sight of what fundamentally case management is (was) all about - and the IT departments that serve the business often struggle to architect the right solutions due to confused offerings in the market (let me think CRM, BI, BPMS incl rules engines, legacy, custom built, package apps, collaboration software/tools, portals, middleware/EAI/SOA, etc etc ) ....little wonder case management is struggling - yet I'd argue that case management is really what constitutes the operational core of most service organisations today (esp as we more more toward service industries rather than industrials that were typically transactional focussed) ... the business need to regain control and define their service ops needs, and work more closely with IT to define the right combination of technologies to better serve end-to-end process situations where the customers (and their requests), the workers, and performance goals, are centric (ie. not the tech).

    I also liked the suggestion of putting CM in the context of business processes - whilst CM does need to support dynamic actions - they also need to adhere a degree of consistecy in execution (think about why lean six sigma is hot right now) - perhaps its more about hitting performance milestones in the execution of the process to ensure its progressing at the right pace/quality (otherwise open collaboration could make a long lived process VERY long).

    I could go on for hrs .....

Add a Reply

Recently Commented On

Monthly Archives