Making the Case for Case

There's been a nearly invisible shift in the business process business, but it is having an enormous impact. Business process management (BPM) is a deeply ingrained support mechanism behind almost every transaction in every organization. This loan application goes from A to B to C, and gets approved or turned down based on rules and policies. It's automated, it's fast and it's accurate. A lot of organizations depend on it in one form or another, and in one department or another.

It works. But there's a more subtle itch emerging in organizations that BPM simply can't scratch. The trending term is "case management," and I needed to get to the bottom of it. So I reached out to Bob Ragsdale. Bob is VP marketing at MicroPact, a Herndon, VA-based case- and business process management solution provider. Based where they are, you could guess they have a large footprint with the feds, and you'd be right. More on that later.

Being a neophyte to the area, I started by asking Bob to define terms. Such as, what's the difference between BPM and case management? Little did I know the size of THAT can of worms.

"Many people cast case management as a subset of business process management," says Bob right off. "I don't see it that way. I see case management as being at one end of a continuous spectrum—BPM is at one end of the spectrum, with its very rigid processes and rigid data, and at the opposite extreme there's case management, which deals with unstructured information (such as documents, audio transcripts from a deposition) and less structured processes. You can't predict what the flow might be for an investigation, for example."

BPM would not work there. It has its place, says Bob, but the two are at opposite ends of the process.

"Where I see people making a mistake is characterizing case management by its ability to manage unstructured data alone. It does that, but that's just a characteristic—it's not the whole definition," adds Bob. "The benefit of BPM is the coalescing and optimization of processes across an enterprise. And, of course, we use technologies to help us do that."

Bob continues—dude knows his stuff. "The goal of case management is to create an optimal outcome to whatever case might exist. Case management is very information intensive, and it's about serving up the right information to the right person at the right time." Sounds like the perfect definition of knowledge management. We'll get to that in a minute, too.

I try out an analogy on Bob. "BPM is like target shooting; case management is like hunting." "Yeah, that's pretty good." I think I hear him writing it down.

Two Sides of the Coin

Case management, we'll say it again, exists to handle the unpredictable. "Life is never black and white. Unless you're in one of the political parties," he laughs. "Every system falls somewhere between the two ends of that spectrum I talked about. Some are more BPM-like, some are more case-like."

I get the impression that case management and document management are kissing cousins. "If you're going to be handling case management, you need that ability to manage unstructured data. If it's not baked into your case management solution, at the very least your solution will have to work with a document management solution of some kind," he says.

Where does case management escape and rise above document management? "Document management is not so focused on generating an outcome. You might get an outcome on that particular document; you collaborate and edit and change and you finally arrive at an outcome for that single document. Case management is about the outcome of several documents, plus more. Think of it as a manila folder of many things, with a lot of tabs in it. Or another analogy is walking from desk to desk collecting information," Bob says.

"A great example of case management would be loan applications," explains Bob. You gather information from a number of sources, and deliver it to a loan officer. But there might be a company policy that says ‘above $417,000, this is a jumbo loan.' It now has to flow down a different path. The difference is whether that rule is an automated one, or is up the knowledge worker."

It takes me a while, but eventually it sinks in. Case management is flexible with the rules... like me. For example, you may have a policy about arriving at work at 9. Bill shows up at 9:15. In a case example, the supervisor could cut him some slack; his kid was sick and he was taking care of things. It's up to the manager; in this case; he/she may do nothing. No action taken. But the BPM version of that would be very rigid—Bill is late and the system automatically docks his pay. No room for improvisation. Rules is rules.

Case management is exploratory. "In case management, we tend to think of things in terms of states. You identify all the information, then you determine which states that information might transition through. You might have an initiation state; then a review state; then an information-gathering state; then maybe a ruling state. And you can go from any state to any state. To model that within a BPM process would be impossible," Bob says.

A lot of people still think of case management as the domain and in context of a legal environment, or government or healthcare. "Human services...great example," says Bob. "You associate that with ‘case workers.' They gather information, review it to see if the person is eligible for a certain program, and then determine a course of action."

This is the "traditional" view of case management... but it's changing. Applying case management to general business across the board and outside of the traditional contexts is a relatively new thing, and old habits die hard. Only within the last two or three years have people recognized the shortcomings of BPM, and customers decided they need something that was broader reaching. As Bob puts it: "They'd squeezed everything they could from BPM, and needed to move beyond."

I call case management BPM's smarter brother. "I like that!" Bob says enthusiastically. "Case management is designed to handle an incredible amount of variability. We have worked very hard as a society to try to codify and script as much we humanly can. That's great, and BPM does a really good job of codifying and scripting those things that can be. What it doesn't do a great job at is allow you to add-to and empower those things that have variability. That's the strength of case management

"But keep in mind; everything is a flexible process, even within BPM. If something isn't working the way a knowledge worker wants it to, they'll find a workaround. So it becomes a flexible process whether you want it to or not!" claims Bob.

"BPM is awesome for when you want to drone the variability right out of something. Make sure there's almost no possibility of doing anything outside of the process rule set. Case management is about helping smart people be smarter."

Is it KM or What?

To what degree does Bob consider himself in the KM business? Because gathering information, delivering it to the right people at the right time so they can make better decisions sounds like a dandy definition of knowledge management to me.

"That's a good one. I think to a large degree we are in KM," admits Bob. It almost sounds like a confession. "It depends on what lens you look through. In fact, I despair at the fact that so much of the world looks at case management through a BPM lens."

The context of case emerged first from BPM system activity, and then it's taken a step further. "What we do is much more akin to ECM and knowledge management than BPM, because we're moving information among people and helping them do the optimal job of managing it," says Bob.

"The market recognition is moving, and I think very soon we'll start to change the conversation toward terms like knowledge management and collaborative decision making."

Entering the mainstream has not been the easiest thing to do. "The hardest part was finding a common language, and that scared me a little. Because people would look at us through that process-modeling lens, and I'd have to say, ‘Yeah, we're like that except 180º different.'

"They'll usually have a concept of what they'd like to have, and then when they see a prototype, they'll say ‘Oh yeah. That's what I was thinking of.'" It's great to be able to anticipate the customer requirements without anybody-the customer included-really expecting what those will be. "It's practically organic. It's just part of dealing with information capture," says Bob.

"The nice thing about it is you don't have to adjust your work. The system is built to accommodate your work. And most people get that; they're working with a paper process or they've had three systems trying to pull them together, so they're looking to simplify, and automate as much as possible. They may not know how they want to do that, or how to go about it, but they know they're deficient in some way and they're looking forward to making their lives easier."

And isn't that what we all want?