Making the Case for Case

The Merger of BPM and Case Management

Hans de Visser is chief strategy officer for Cordys, a BPM company that is now part of OpenText. I think it's interesting when a company has a title like that on the org chart. It shows a maturity of thought, and a planning imperative that recognizes two things: business process management demands planning; case management requires strategy. Hans is skilled at both. I had the pleasure to meet him around Thanksgiving. But he is based in The Netherlands, and waited till way in the afternoon to talk to me. So I appreciated his time. "Don't worry," Hans said. "I've been dealing with people in the US a lot lately. I'm getting used to it."

My opening gambit was to get the terminology out of the way. Here's the thing: there are overlaps between BPM and case management, and we (KMWorld) bundled them into a white paper topic, but in my mind they are fundamentally opposite. BPM refers to a hard-wired, replicable series of steps that carry out various daily transactions in a predictable way.

Case management, in contrast, is some magic way to automate the unpredictable nature of business relationships. It somehow refers to the control and rules governing the complete chaos of non-transactional business relations—contract negotiations, legal matters, customer relationships, even health matters that "House" would have trouble negotiating. There is nothing "automatable" about those things... is there? That's what Hans and I talked about that day.

"You're right," started Hans. "BPM is more about pre-designed, pre-defined processes. Case is much more dynamic, you might say ad hoc. It is intended to support knowledge workers and drive their personal productivity. And ensure certain outcomes of the tasks they've been assigned."

So much for a simple definition, I thought. That could describe just about anything. And it only got murkier.

"There is a gray area where BPM and case overlap. On one extreme is totally dynamic case management, where you design a case on the spot and organize your work accordingly. And BPM is strictly pre-designed. What we're finding is there is a middle place, where you add ‘guardrails'—predefined case models or templates. This is where you take a request through certain predetermined stages, based on experiences that have come beforehand. But at the same time the knowledge worker has some freedom while executing the case to define his or her own tasks, ad hoc. You might include other people, internal experts or even external stakeholders to get to the best possible outcome," said Hans. "So there's a whole spectrum that starts with straight-through processing on one end, and totally dynamic case management on the other."

With that gray area somewhere in the middle. The key to case management seems to be the repurposing of prior "good art" and apply it to the current task at hand. Because even though each case has its own unique challenges and nuances, there are also great portions of a task that are similar-enough to experiences you or someone in your organization has already accomplished that can be applied to avoid the "recreating the wheel" syndrome that stymies productivity.

But I still struggle with the idea that dynamic, ad hoc processes can be automated. "Oh, you can even create variations that could possibly be applied to a process beforehand," said Hans. "For example, we have a customer that is a huge emergency-response center. There are certain rules and procedures the call agent follows if they get a call from someone stuck on the road. Sometimes those are driven by policies; for example, the insurance policy does not cover an overnight stay. But sometimes the agents need to act on their judgment, and overrule the policy. Maybe they learn the stranded family has a young baby on board. That type of flexibility needs to be there. Being able to break the rules is sometimes the best way to get to the best possible outcome for the customer," said Hans. But it will always depend on the organization's tolerance; some will build that flexibility into the model; some will opt to limit the amount of flexibility.

The Benefit of Experience

A best practice, therefore, is to monitor what knowledge workers do over time to solve problems. Take the best and most successful of those decisions, and turn them into part of the process model. When you think about it, it is something we do from infancy: Watch and learn.

But in complex organizations, it's a little less intuitive. "In many examples, we are using process mining techniques that look for patterns of behavior, and every touchpoint of the interaction is recorded and analyzed," explained Hans. "Over time these patterns give you guidelines, and all those flavors will be at your disposal."

I told Hans that the whole thing seems simultaneously simple and also mind-blowing. "Yes, both are true," he laughed. "In the end, it's just a matter of mining the data and looking for the footprints knowledge workers leave behind." He was quick to point out that there are privacy and governance regulations, and they vary from country to country. "But basically, if you see that a certain marketing project is always executed in the same (or similar) steps, that these people are typically involved, determine who dispatches work and receives work, and follow the sequence of activities, that information will give you a recommendation on how to approach a new similar project."

It gets hairier. "That emergency organization I referred to earlier is taking it one step further. They are using their data-mined patterns to predetermine what steps might be necessary next... where the nearest salvage operation is; which hotel is the closest for the family...and providing that information when necessary to the call handler."