Case Management Work Patterns

My last post on process, rules and content has me thinking about the style of application where they all come together: case management. Not about when or whether to use the Case Management Model and Notation (CMMN) versus the Business Process Model and Notation (BPMN) versus the Decision Model and Notation (DMN), which I covered in a post on this “triple crown” of modeling standards, but the business requirements for different styles of processes including case management.

For business analysts, the distinction between work patterns is important, since different patterns lend themselves to different types of user interfaces, use cases, systems and levels of automation. And yes, they need to be modeled differently, possibly using different modeling notations, but first it’s necessary to identify the work patterns in order to classify them. There are some types of work that are so unpredictable that it’s difficult to model them at all, but let’s stick with the broad array of work that can be modeled in some way: we know a bit about the goals of the work, or the steps required to achieve the goals, or the information that is being used, or the rules that must be followed along the way.

At one end of the spectrum is transactional workflow, where most of the process is known: the order of the steps, the rules that dictate when things move from one step to another, and the step that defines when the process has been completed. These processes are often codified in BPM systems or line-of-business systems, and are partially or even fully automated.

At the other end of the spectrum is case management: a work style for goal-oriented scenarios that don’t have a predefined method of resolution. This is commonly used for problem resolution, but is also for work that doesn’t have a defined order of steps, such as claims management or legal cases. A case may be initiated directly by someone – a customer, or an internal worker – as a standalone piece of work, or a case may be triggered by a transactional workflow to handle an exception or resolve a problem before returning to the predefined process.

As more and more routine tasks within transactional processes become fully automated, more workers are engaged in doing knowledge work within case management. The goals and metrics for this type of work are very different from transactional processes: since cases are often related to resolving problems, case management metrics such as customer satisfaction can be a key competitive differentiator. Case management workers need a much richer informational context in order to do their job, and very different tools than workers engaged in routine tasks within transaction processes.

In my practice, I often help organizations to understand the different work patterns within their operational areas. They may not even recognize some of these as definable work patterns, just “the way that we do it.” Let’s look at identifying case management work patterns:

• Case management doesn’t have a predefined order of steps or endpoint, but is considered completed when the central issue has been resolved. The set of all possible steps may be known, but it’s unknown the order in which they will be executed, or even if some of them will be executed at all. Each case will follow a different path, since the worker decides what must be accomplished to complete the case, and they may not decide on what the next step is until information has been gathered by the current step.
• Case management is centered around a case file/folder that is used to collect all related content. This case folder is persistent, since it holds a record of decisions and the documentation required to make those decisions. This is the crossover with content management, and why case management systems often are built on the foundation of a content management system.
• Case management relies on knowledge workers to gather information from a variety of sources and guide the work towards a resolution. This includes assigning tasks to other participants and making decisions that cannot be automated. There can also be automated processes and triggers that gather information into the case folder, make decisions and assign tasks, but case management scenarios almost always involve some level of human decision-making.

I use the following diagram to visualize all the components that may involved in case management:

What do the three characteristics of case management that I list above mean for the business architects and analysts involved in defining and implementing these processes?

First of all, these are goal-oriented processes, and the metrics need to reflect that. For example, the success of a case isn’t tied to how fast it is completed, or how few resources were consumed, although those may be secondary metrics: it’s primarily about whether the issue was resolved satisfactorily. That might be a customer satisfaction measurement, or a legal or regulatory measure, depending on the goal of the case. Business analysts need to identify the goals for each type of case, and ensure that those are the metrics that are being captured. If more traditional process metrics are used, you could end up with cases being resolved very quickly but a lot of unhappy customers or lost sales.

Second, these are content-rich processes, and there must be robust content management as well as the type of content governance that I discussed in my previous post. Since many different types of people may participate in completing a case, you need to be sure that people are seeing all of the content that they need to do their work, but not parts of the case folder that they should not have access to.

Lastly, these are knowledge processes that require people to look at information and make decisions. That means that they need a rich informational context in order to make the right decisions: the right content from the case folder at the right time, but also information from other systems, organized in a fashion that requires a minimum amount of searching. Currently, a lot of case management work is performed with an ad hoc assortment of methods and applications – including spreadsheets, email and external applications – often without support from IT-supported systems; this makes it difficult for the case workers to be sure that they are looking at the right information to support the decision that they’re making.

Once you’ve identified work that looks like case management based on these characteristics – even if it has some predefined processes tucked into part of it – you’re ready to start into the detailed analysis. This is where you will likely use CMMN (and possibly BPMN and DMN) to model how the cases will work, but don’t lose sight of the human side of case management: making decisions in a content-rich environment to reach a specified goal.

Follow Sandy on her personal blog Column 2.