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 is the relationship between a 'case' and a 'process?'

Vote 0 Votes
From a feature article on ebizQ where Lynn Haber debunks the myth that a "case" is just another word for a "process," what do you think is the relationship between a "case" and a "process?"

16 Replies

| Add a Reply
  • Overall Lynn's done a good job of surfacing some distinctions, but the comparison should have been between BPMS/BPMN and Case Managment, not BPM the methodology.

    Also, the lines are blurring from both directions. Case doesn't necessarily require BPMS/BPMN. There are Dynamic/Adaptive Case Management vendors, ourselves included, that can generate an emergent process based on Case context and rules. Processes can be built up step-by-step, which allows system flexibility and user adaptation.

    • Hi Dave, I agree, Lynn's article is very good. Albeit I somewhat disagree with your initial statement about the methodology approach. There has to be rules or system of methods, principles for regulating case management as it relates to improving work. These same rules, methods, principals are used in developing the BPMS and in using BPMN. Its even more appropriate for BPM,since ACM/DCM aligns closely with BPM.

      BTW...interesting threads in Linkedin ACM group.

  • I agree with Dave that Lynn did a good job regarding the distinctions between BPMS and dynamic case management. However, I get the sense that she is suggesting an "either ... or" situation when thinking about BPMS and DCM.

    A good example of the relationship between BPMS and DCM as well as the need for better integration of the two approaches is loan origination. There is an overall loan origination business process that most organizations find necessary. In addition, each loan origination case may be slightly different.

    From a governance perspective, you want organizations and their knowledge workers to follow the process. Also, you want those organizations to have rules that guide decision making relative to each case. Appropriate integration between BPMS and DCM software could assist in the workflow and rules area such that loan origination, both the process and the cases, is governed better.

  • I agree with Dave: Lynn has done a good job of clarifying many of the distinctions.

    Lynn should have started with a definition of BPM. BPM in many eyes is a style of application development sold to IT with the promise that "business people" can be involved in the design/development at some point. Like all programmable systems, one might be able to make a case management system out of this, but saying that it is the same thing as Case Management is like saying my PlayStation III is case management because I could program something there as well.

    The other meaning for BPM is a management approach where managers are analyzing their own (actual) processes and seeking ways to improve them, either by training people better, or many other ways. Here "case" and "process instance" are conceptually very similar since we have no need for a concrete implementation of the process.

    The best way to understand the distinction is how case management focuses on goals, while BPM focuses on methods. Consider a patient who shows up at the emergency room with a broken leg and tetanus. With a BPM approach you need two processes: one to cure the broken leg, and one to cure the tetanus. This is because a BPM application focuses on a distinct procedure for a particular affliction. With Case Management, however, you need only one case: the patient and the goal of getting them well. This will be broken into subgoals in this case, but all the information for all those goals can be placed in one case folder.

    Thinking of case management as a superset of BPM is not helpful either. The case manager will use a host of tools: word processors, spreadsheets, and BPM. BPM should be seen as a separate tool which is used when the particular procedure is clear and predictable. And just like you have many word processor documents in a case, you might have many BPM processes associated as well. If a particular procedure approach fails, you will kill that process, and start a NEW BPM process with a different procedure. But you will never close the case and reopen a new case, even when the goals completely change.

    These are very distinct concepts, but when the technologists get involved, they see that a process instance needs a collection of information, a case folder needs a collection of information, and ECM folder is a collection of information. Hmmm, all collections of information -- I can use the same Java class for all! So they are the same thing. But only at a level that carries no significance to the actual user.

  • I'll probably get in trouble here - but on the other hand it may start an interesting discussion

    Adaptive Case Management - a tool for knowledge workers to get their main task done - in other words a tool to help manage knowledge work. It supports them in effectively executing the kind of goal driven, unstructured, unpredictable processes they face every day. It should become the main business tool for knowledge workers everywhere.

    Business Process Management Suite - a tool for anyone (including knowledge workers) to get routine, structured work done. For knowledge workers a BPMS won't help them with their main task (knowledge work), but may help make specific, peripheral, highly structured processes more efficient. For many knowledge workers - these are the processes that get in the way of what they consider their real work.

  • Why always so tool oriented?

    Do you really think my customer cares whether I deliver his product (a case?) in case management style or so called BPM?

    Ofcourse not. He wants his product/service as we agreed.

    And if you like it or not, these products/services are created by a process.

    So, in my opinion, the discussion “bpm vs casemanagement” is useless.

    I think it must be about process and the flexibility it needs and the way you manage it.

    What most people seem to call bpm is what I call straight through processing. Not much flexibility, tightly managed. With results that won't differ much from each other.

    But some processes don’t have that clear results and cannot be steered based on those good old workflow principles. Depending on the customer some steps might be skipped, done in another order. Maybe some steps will be added ad hoc.
    It's still a process, but not predefined. Probably people like to call this case management.

    In the end it is all about managing a process (BPM?), but in some cases more flexible, less predefined.

    I think vendors want to make Case management important, so they can tell how special their case management tool is.

    But, who cares? I don't.

    Excel, some post-its and an agenda is all I need to serve my customers.

  • It is not about tools, for this I agree with Emiel. Some tools handle 'cases' better than other, but to all tool vendors, theirs is the best hammer.

    To answer the original question "What is the relationship between a 'case' and a 'process?'"... I'll answer this using 'case management' as the hammer: a case is the context of all information, processes, states and events that are going on to achieve any number of related goals.

    Or in more than one line, a case:

    * Is a container for the information about a set of things that needs to be done, or goals achieved.

    * Encapsulates many different ways these things can be done, including processes and ad-hoc actions performed by individuals.

    * Probably has multiple processes running simultaneously and independently.

    * It may have multiple goals.

    * It represents a context that is set based on the alignment of many states or events.

    * It often holds the data representing an entity such as a customer at a point in time, to be shared across all the processes where it makes sense to do so.

    A process, as we mentioned is just one of the things that can go on to help achieve the goals of the case, although it can be the only way that a case is 'processed'. Since for those with a 'process management' hammer, almost all of the above can be made true for processes by swapping some words around and changing the context of what is being said. The tool looks different, the end result is hopefully the same.


  • I can sum up Emiel's post succinctly as: "so what?" in other words, one describes ACM, and he feels like the customer doesn't care about this - excel/notes/etc. do the job... so so what?

    So if the question is, what software can I buy to help with ACM? or more accurately, what do I need to buy? (or where the value proposition is so good as to cause me to buy and find value)... If it is just a method, and no special tooling required, that's fine. But then "so what" is a valid response for those in the business of software and business process consulting (or development) :)

    (regarding the idea that you can "implement case management in BPM" - the point of that train of thought is simply counterpoint to the idea that BPM is antithetical to ACM or somehow unable to support ACM style work... as keith implies, as long as your system is turing complete, this is a silly argument ;)

    it seems obvious to me that a case is (most generally) a collection of information, and a process is a collection of transformations with a goal. I don't know anyone who thinks those terms are "the same thing". The question is whether case management is, itself, a process. Not whether case = process but whether case management = process :)

    Unfortunately the strawman set up in the linked post isn't very compelling. I can sum it up as "Case Management isn't BPM because I said so." It isn't proven, it is just stated as fact in several different ways. Not very convincing work. Example: "Myth: Case management is the same thing as business process management (BPM). Reality: Case management does provide solution features similar to those in BPM, such as task management and workflow processing. But it's actually more of a superset to BPM in that it addresses collaboration and unique content management capabilities." um... ok. It's an opinion but it hardly constitutes data to support the conclusions.

  • Good article.

    A process is the larger picture of how work is facilitated, whereas case is the drill down on a process so to speak – the rules, constraints and procedures, etc.; knowledge management of a process that can branch in many directions with variant levels of detail. Every process has a case.

  • Lynn's post provides no clarification on myths or otherwise. I consider them loosely defined opinions.

    First there ought to be a clear distinction between BPM and a BPMS for system, software or suite. ACM always refers to a system implementation because an adaptive approach relates to social empowerment and can't be implemented as a methodology only. That has an influence on what a case or process can be considered to be.

    Lynn also didn't define case or process. They were a few distinctions and I don't agree with them. I propose that 'unstructured process' is already an oxymoron. A process by definition has a start, steps and an end. Goals are only looked at during design and then one assumes that perfect execution will always produce best results. (A)CM onyl focuses on goals and the 'A' means that there is am embedded learning or knowledge gathering capability that changes future execution. BPMS always focus on nailing down the process using flows and improve them by bureaucracy only. Ad-hoc and dynamic features are not CM.

    When I use process I only do it because it is common use. In reality there is no such thing. Process is something that HAS HAPPENED or SHOULD HAPPEN, but never AS-IS. Even if performers hit all the process steps as checkpoints, they will do different things each time and usually not report or handle it through the BPMS. It is an abstraction and simplification. So in reality there are ONLY CASES.

    I will cover the subject more in detail on my blog.

  • Ad hoc work and knowledge work cannot always be standardized, but it can by systematized, meaning that this type of work would have a start point, a defined end point, periodic evaluation or check points, and goals, as well as implicit or embedded workflows. These underlying workflows are processes, and from this standpoint as Lynn and other contributors noted, the case then sits as an umbrella over existing processes and captures experience and data for future consideration.
    It might make better sense to break down process, system and case more clearly where:
    Process = A defined set of actions designed to consistently produce a specific intermediate product or outcome, example: How to print a customer invoice
    System = An integrated series of processes designed to achieve a tactical, functional or organizational objective, example: an invoicing system that enables bills to be approved by clients within 24 hours of sale
    Case = A unique business challenge, opportunity or set of circumstances requiring examination, investigation and resolution, example, resolving complex contract disputes would be a case for several functions within an organization.
    The tools employed for process, system or case management would not be of critical importance to the end-customer of the process or the client of the organization unless the client or end-user had concerns about the organization potentially passing along its inefficiencies into its pricing or service. In that instance, an business or organization that could point out its process controls, system or case management tools, that might allay concerns.

  • To explain the difference (at least what I think it is) I always try to use examples. One of these examples is a stay in a hotel.

    The complete stay (from check in till check out) is what I call a case. Being the hotel owner you want to manage this case as good as possible. That is how you earn your money.

    But it is not a process because you don’t know what will happen during the stay of your customer.
    Several processes might happen during the case. Ofcourse checking in will be executed. Maybe Serving a dinner or sometimes repairing a door lock.

    So within a case several processes might happen. Some of these processes might be straight through others might be more flexible. Within the case the amount of processes might be flexible to.

    To be able to make this case a success you can imagine good process execution is critical. You also need good information management (about the customer) to know what has happened for this case.

    Another example I sometime use is one in healthcare. A patient with a problem is the case. The case is ready when the patient is cured.

    During this case many things might happen you won’t know exactly upfront. And again information is very important here.

    As you can see (luckily) casemanagement is also about helping customers. Not by executing one process, but maybe more.

    • Emiel -

      Great response. I think I can add to your example (I've looked at similar examples on our blog).

      Take the hotel.
      Case = one person's "stay" at the hotel.
      Several processes occur (check-in, check-out, Room Service order, etc.)
      But also, at a high level, the hotel will have a macro view of this. The process for managing checkins and checkouts. (not managing one, but managing the aggregate outcome). the processes for running the kitchen (aggregate of many food orders, only some of which are room service).

      This is why I find it pointless for people to think "case owns processes" or "processes own cases" - what contains what depends entirely upon your goals, objectives, and scope.

      Take the doctor example. Patient = Case. Fine. Some processes may be involved, or more specific cases, within this overall "treat patient" case. But to the hospital, they have aggregate processes to understand and manage. Process inbound and outbound patients. The doctor's schedule of rounds, the schedule for checking in on all patients during the day. The validation of all radiography with a secondary specialist. Etc. These are processes independent of the specific cases - and yet they interact.

      Containment is inadequate to describe the relationships between case (what is) and process (transformations applied in context).

  • (pushed the button too fast....)

    You can also tell the difference from the words themselves.

    A Case is something that "is". For example A customer who wants to stay 3 nights in an hotel, a patient who wants to be cured.

    A process is something that "happens" for example Checking in, repairing a lock or making an MRI scan

  • Hi, all:

    I'm the site editor for ebizQ. I assigned and edited the article that prompted this question, and I wanted to clarify a few points here.

    Lynn's piece is a journalistic *article,* rather than a blog post, report, technical brief, white paper, etc. So it's researched, written and edited as a relatively short feature story that's one of many we're running on various aspects of case management right now. No individual story is, or is intended to be, comprehensive.

    On a related note, as you may have noticed, ebizQ's editorial content now focuses much more sharply on BPM, case management and several related topics. We don't provide definitions for these terms in every article because a) it would get redundant fast and b) we assume, based on our reader research, that most readers don't need definitions for most of these topics.

    Also, what is or isn't included in an article like this is, ultimately, a management decision. That is: my call, not Lynn's.

    That said, Pete's question wasn't intended to start a discussion about the specific merits of Lynn's article, but instead to provide a jumping-off point for a discussion about the difference between "case" and "process." So I'm hoping we can keep the discussion going, focusing in on Pete's question rather than the article that prompted it. Make sense?

    And, as always, if you've got questions or concerns about any editorial content that you see on ebizQ, I invite you--I encourage you--to contact me directly. If you've got ideas for coverage or just want to say hello, please contact me as well.

Add a Reply

Recently Commented On

Monthly Archives