What Is Case Management?

I view case management as a particular style of BPM, i.e., a class of business processes, that is not handled particularly well by conventional BPM tools.  I am working on a white paper that goes into more detail.  Below is an excerpt from the draft version:

What Is Case Management?

Over the past several years, Business Process Management Suites (BPMS) have matured into powerful platforms for process automation and performance optimization, many configurable by business-friendly process modeling tools.  The benefits of BPMS over a wide range of processes – improvements in cycle time, throughput, resource utilization, standardization and compliance, business integration, and end-to-end performance visibility – are well established.  However, an important class of business processes has been unable to enjoy them because of the limitations of conventional BPM Suites: case management.  This report describes the differences between case management and conventional BPM and shows you what to look for in a true case management BPM solution.

One problem with case management is that no single definition for it exists.  It has been variously described as a segment or style of document management, knowledge management, or customer relationship management.  Certainly, document content, collaborative decision-making, and customer interactions are important elements of case management, but they are important in conventional BPM as well.

The essential distinguishing characteristic of case management is the “unstructured” progression of a case from initiation to its final state.  In conventional BPM, by definition, a process instance progresses through a sequence of steps you can describe explicitly as paths in a diagram, leading from a single start point to one or more end points.  The path logic for any particular instance might be determined by human judgment, external events, and business rules, but the steps, branching logic, and exception paths are all definable in advance. 

In case management, by contrast, the flow logic cannot be expressed in such a diagram defined in advance. In case management, human judgment, external events, and business rules don’t just determine paths through a predefined diagram.  Instead those factors determine at runtime which activities need to be performed and whether additional steps are required, either picked from a predefined menu or conceived on the fly.  While this flexibility is an essential ingredient of many types of real-world processes, conventional BPM Suites demand a process model – however complex – that can be completely defined in advance.

Moreover, a case is rarely a single process in the conventional BPM sense.  It is a collection of processes and isolated tasks, the number and identity of which cannot be fixed by a predefined template or rules.  While case templates provide a convenient starting point for cases of a particular type, the actual steps and information required to complete each case are determined by a combination of human judgment, rules, and events occurring at runtime.  While conventional BPM can sometimes manage individually the various processes involved in a case, it has difficulty managing progress of the case as a whole.

Despite its semi-structured nature, case processes suffer from the same problems as conventional structured processes.  They take too long to complete.  Resources are not used efficiently.  Information is misplaced or not retained.  No standardization across the organization.  Difficulty of enforcing compliance with policies, regulations, and best practices.  Lack of visibility into key performance indicators, either at the individual case level in real time or historical trends in the aggregate.  BPM Suites bring relief for all of these issues with conventional processes.  Case management processes need the same capabilities… but this requires a different type of BPM platform.

Who Uses Case Management?

Case management processes are a common occurrence in many industry segments, including government, insurance, banking and credit, legal, and healthcare. 

Dispute Resolution

A good example of dispute resolution concerns billing and credit card disputes.  Processing payments is a conventional structured process, but when a customer disputes a charge or demands a refund, case management is usually required. 

Even if the credit card issuer provides a standard form for initiating the case, the activities required to resolve each case depend on a myriad of factors.  What is the reason for the dispute?  Were the goods delivered or services provided?  Were they defective?  Was the defect the fault of the manufacturer, the shipper, the customer, or some other party?  Does the dispute concern the amount of the charge?  And so forth. 

Resolution of the dispute could depend on any or all of these factors, each of which typically involves production and review of documents. The credit card company may require information from the customer; the manufacturer, retailer, or service provider; the shipper; possibly legal counsel, attorneys, or even law enforcement. The rules involved could depend on the customer’s location. As the facts unfold, new tasks and documents may be added to the case. 

In the end, there is no way to define in advance the credit card company’s dispute resolution “process” as an explicit flow from case initiation to resolution.  But many of the same factors that motivate conventional BPM – timely resolution, efficient utilization of resources, compliance, and end-to-end performance visibility – are still important.

Other examples of dispute resolution case management include healthcare claims and grievance procedures, HR termination, and civil litigation and mediation.

Benefits Administration

Case management is well established in many segments of benefits administration, particularly in the public sector.  Examples include disability, veterans’ benefits, welfare assistance, student financial aid, and grants programs.  Within a single case there are issues of eligibility, disbursement of funds or services, changing circumstances of the beneficiary, reporting and compliance.

Underwriting

In various segments of financial services, including commercial lending, life and disability insurance, and securities, the underwriting process is really case management.  The activities and documents required depend on the circumstances of each case.  While the components of “standard” cases may be predictable, there are many exceptions, requiring additional input from lawyers, accountants, regulators, and investigators.

Project Management

An application area that could benefit from case management BPM, but has received little attention to date, falls under the heading of project management.  Examples include launch of a new product or service, a major IT system upgrade, or mergers and acquisitions.  There may be relatively few instances of a particular type of case, but each may represent high value and high risk. As with the other examples, the significant attribute is the fact that unanticipated tasks and processes may be added once the project is underway. Project management software typically provides just planning and tracking; case management adds the BPM dimensions of automated workflow, enforcement of business rules, and application integration.

Differences from Conventional BPM

These examples share a number of common factors.  Some of them are absent entirely in conventional BPM, while others simply play a different role in case management.

Case Information Managed as Documents

A large fraction of case-related information is received and managed in the form of business documents rather than structured data.  Where conventional BPM applies automated logic to data, case logic more often applies human judgment to information contained in documents. Thus a case management platform must include a complete document management system, a comprehensive facility for creating, capturing, indexing, storing, finding, viewing, sharing, editing, versioning, and retaining a wide variety of document types.  Simple document attachments and a viewer, as provided by conventional BPM, are not enough. Case-oriented BPM should be able to apply rules to document events – check-in of a new version, for example – for automation and case status tracking.  Just as you cannot predefine all the tasks needed to complete the case, you cannot specify in advance all of the documents required.  While common ones can be required by the case template; others may be added ad-hoc at runtime.

Case Activities Added at Runtime

Some tasks and processes needed to complete the case may be defined in advance through the case template, but ad hoc tasks – whether selected from a predefined menu or defined from scratch – are a critical distinguishing element of case management.  Often, those tasks are related to creating, obtaining, reviewing, and approving documents.  Some of those tasks could represent conventional processes involving multiple participants.  Managing a case as a single unit composed of independent tasks and processes – some added at runtime – is simply beyond the scope of conventional BPMS.

Case Advancement through Events

In BPM, an event means “something that happened.” Conventional BPM often initiates processes based on some event, such as receipt of a document, but from there the instance progresses like a train moving down a track.  Subsequent events might switch the train to another track at specified points in the flow, but for the most part the process advances by itself.  Completion of one task is what triggers the next one down the line.

Case management does not normally work by routing the case folder to the next task sequentially down the line.  Instead it advances through events, both external and internal:

• External events include receipt of a phone call, letter, fax, or email related to the case.  The contents of that message are added to the case folder, and new tasks or processes may be created. 
• Internal events include assignments and business rules. Case workers assign tasks and initiate processes as they deem necessary as they work on the case. Business rules within the case may automatically create and assign tasks – or perform fully automated actions – based on either external events, completion of other case tasks, or expiration of task deadlines.

Thus, instead of a train moving down a track from task to task, the conceptual model of a case is a collection of independent parallel tasks interacting via events.  Those tasks define the case context and are visible, along with case documents, from the shared case folder.  The state of the case as a whole is determined by the combined state of all its tasks and documents.

Case Context through Shared Case Folder

Human judgment about advancement or resolution of the case frequently depends on not a single document in isolation, but the document collection as a whole.  Thus, all case information – subject to specific security and access control rules – is typically available to users working on the case in the form of a shared case folder.  The assumption that case workers know where to look for the case information they require represents the knowledge dimension of case management.  In addition to case data and documents, the case folder provides shared access to case tasks and deadlines.  

Why Case Management Is Hard for Conventional BPMS

As awareness of the case management gap in BPM has increased, BPMS vendors are beginning to add one or two features to their standard offering and declare it suitable for case management.  But even with these isolated enhancements, conventional BPMS has a hard time addressing case management for several reasons:

1.       The process engine.  The key feature of a BPMS is its central orchestration engine, which automates the flow of a process instance according to a predefined process model.  Some BPMSs have added the ability to insert ad-hoc tasks from another task in the model.  But such tasks are not independent, running in parallel, with their own rules or possibility of spawning other steps from within them.  They are simply grafted into the sequential flow for that instance.  The fallacy here is that a case is not a single process.  It is a collection of tasks and processes interlinked by events, rules, and business judgment.  Conventional BPMS cannot manage such a collection as a single complex “thing.”

2.       Content-awareness.  Most BPMSs are designed to operate with data, not business documents.  They treat documents as attachments, available for viewing, but they rarely support creating, editing, versioning, organizing, or finding the specific document types required by the case, or storing documents in large volume, or responding to content events, or retaining documents for years after the case is complete.  Good content management systems can do those things, but they need to be deeply integrated with the BPM component to meet the needs of case.  BPM Suites from content management vendors do this part reasonably well, but they tend to fall down on the next requirement.

3.      The Case Folder.  As the central feature of a case management system, one would think that an out-of-the-box case folder would be part of any purported case management feature in a BPMS.  Not so.  BPMS vendors are far more likely to propose that the tools used to configure the conventional process portal environment can be used create something like a case folder.  Outside of the hassle involved, particularly in integrating the tasks, documents, rules, and events involved in the case, this approach misses the core idea of case management: a case is not just a collection of isolated things, like processes and documents, but a single thing that is progressing toward completion.  That is what the case folder represents.  If you cannot understand the status of the case as a whole through simple inspection of the case folder, you can’t really do case management very well.

Tags: case handling, case management