Case Management Modeling: Creating Systems of Engagement

The past couple of years have seen a fairly dramatic shift away from process-first BPM approaches toward more dynamic case management solutions. Why the shift? Why is the market turning?

One reason is flexibility. Organizations require systems that can accommodate the variability of real-world business scenarios that are collaborative, information-intensive, subjected to incremental changes, driven by outside events, and responsive to progressive requests from knowledge workers. While BPM is excellent at codifying processes, it is not an optimal tool for accommodating variability and incremental change in real time.

A second reason is time-to-market and system adoption. Today's business landscape changes quickly and as such, organizations must be able to rapidly develop and deploy applications—and once deployed, those systems need to be fully adopted in order to be effective. Process modeling can actually be a barrier to this. Forrester Research's Clay Richardson recently opined: "In the next three to five years, expect to see traditional BPM methods and practices to decrease in adoption, with new ‘experience-first' approaches emerging to play a greater role in driving business process improvement and business transformation."

In order to connect with users so that they can have this "experience-first" experience, we must first adopt a language that opens the conversation to all stakeholders and allows everyone to contribute to the system design and evaluation process. That language is not "process," it is "data."

Let's start with a bit of context. We require three basic elements to efficiently oversee all of our business operations:

• Information
• Policies
• Procedures

And if we are going to build a system, it's pretty obvious that it must be able to accommodate and manage these elements for us. 

• Information may be any combination of structured data (information in a database, forms, etc.) and unstructured data (documents, audio files, video, images, etc.);
• Policies may be standards-based (HIPAA, NIST, etc.) or may be domain-based (industry or business specific); and
• Procedures may be structured (rigid processes) or unstructured (state to state).

Data-First and Case Management

"Data-first" is a simple concept. While BPM would start at the bottom of this list by mapping out procedures (rigid processes) and work its way up the stack, data-first simply expresses the fact that in modeling a case management system that you start with the information (data) model and work your way down. Policy modeling comes second. Process modeling, if required, comes last (in some cases there is no process modeling).

At its core, a case is information-an aggregation of structured and unstructured data that knowledge workers will guide, collaborate and rule-on with a goal of delivering an effective and appropriate outcome. If the information isn't correct or comprehensive it won't be possible to effectively manage the case irrespective of how good a process may be. It therefore follows that in the world of case management, information is king-we therefore begin with data modeling, building the system around the information we are going to manage.

How Data Modeling Promotes User Engagement

One of the really nice things about a data-first approach is that it is very easy to engage system stakeholders in the requirements—gathering and system—design process-and to ultimately drive system adoption.

In contrast to BPM's process-first approach, which calls for people conversant in process modeling (which most users aren't), a data-first approach makes it easy to engage stakeholders throughout the organization. The average worker can tell you the information that they will need in order to manage their case work—for example, they can show you the forms they use to capture data today. Supervisors can readily share the level of real-time insights and controls that will be necessary. Managers generally have a very good fix on the reports they require. And IT can easily describe their capabilities, constraints and level of governance they will want. All of these are data points—not process points.

Additionally, if we abandon the process-first notion of having to define the entire case flow upfront, we can simply concentrate on the "states" that a case must transit. This is good because states too are really just data-points and, in general, users can readily identify the states that a case will move through. For example, most cases will have an initiation state, an information-gathering state, a review state and a resolution state. The states generally remain consistent but the order in which they occur will vary based on information that is captured and events that occur as the case moves from initiation to resolution.

By engaging users in discussions regarding the data points, the information that they will need in order to accomplish their work, we make it easier for them to contribute to the design and build of the system. If we go a step further and model the system for them in real time, based on the information they are feeding us, it makes it even easier for users to contribute to the system's evolution when they see how the system will look-this is experience-first design and it's powerful because:

• When users are able to see the system they can better identify gaps and information needs;
• Visualization helps spur new ideas;
• It is easier to bring end users into the design process—they don't need special training; and
• The states, milestones and goals that a case must transit become naturally apparent (and in this manner, process modeling becomes organic).

Additionally, this approach of system modeling promotes system use and adoption as users:

• Come to understand that a dynamic case management system can evolve on the fly;
• Focus less on the "as-is" state and are more comfortable to move forward with deployments; and
• Feel more included and are therefore more committed to the system's success.

Policy modeling. Once we have our case's data and state model completed, we might want to employ some policies to govern how the case will be managed. Policies can be standards-based, domain-based, or may be unique to a particular organization. For example, an organization may have a policy that everyone must be at work by 9 a.m. With this policy in place we can set up listeners for violations of the policy. These listeners can in turn trigger other actions. In this scenario the case would be the employee's file, if that employee arrives late the system might fire off an email to the supervisor alerting him to the fact that the employee is late.

This is also a point where case management design diverges substantially from BPM. We can actually stop with our system modeling once we have added policies—we don't necessarily need process.

In the above example the employee's case may reside in an "employee in good standing" state and the supervisor has been alerted to the "status" of the case (the employee's tardiness). The subsequent actions by the supervisor can be left entirely to that knowledge worker. There may be no official process for how to handle tardiness-the system can be flexible and absent of associated process.