I was interested to see the “Great Case Management Debate” at Gartner’s BPM 2011 conference.  After all, it has been quite the topic, ever since Keith Swenson put his weight behind the ACM moniker more than a year ago.

But right off the bat, Toby Bell reset expectations- that this wouldn’t be a debate, it would be a “live research session” (whatever that means).  Toby Bell represented ECM (content management), Janelle Hill represented BPM, and Kimberly Harris-Ferrante represented insurance…?   It would have been more interesting to have someone really representing and advocating for case management, versus someone really advocating for “BPM” – instead we had a bit of an odd triangle.   For most of the session there was no debate at all, there wasn’t even nuanced disagreement. A definition of Case Management was given:

Case management is the optimization of long-lived collaborative processes that require secure coordination of knowledge, content, correspondence, and human resources and require adherence to corporate and regulatory policies and rules to achieve decisions about rights, entitlements, or settlements.

The path of execution cannot be completely pre-defined; human judgment and external events and interactions will alter the flow.

Even Toby poked fun at the very Gartner-ness of this definition.  They talked a bit about why Case Management hasn’t caught on better in the marketplace – and there was some consensus that part of the problem is the word “case” – what is it?  To many businesses, this is sort of a meaningless term.  Kimberly proposed that Case Management would get better traction by adopting industry-specific terminology for the “objects” that are cases.

Janelle gave an example of a collaborative, content-rich process:  university applications selection.  As she put it, they want to pick from a big applicant pool (lots of people applying), pick better students, and get a higher acceptance rate. ( Well, actually these last two goals are contradictory.  The better your students are, the more options they have, and the lower the implied acceptance rate.  However, what increases acceptance rate are things outside the selection process – reputation, communications, campus and facilities, faculty, cost, financial aid, etc.  Universities have been competing for top talent for a long time, since well before terms like case management and BPM were coined. )

The closest we got to a real debate was with respect to the marketplace.  Toby took a light-hearted shot at BPM vendors by pointing out that ECM vendors were adding case management and process management capabilities as obvious add-ons to their software packages.  Janelle’s retort was well-said:  that ECM vendors were pursuing BPM functionality out of necessity, looking for a way to grow when there are only 4 or 5 vendors left.  Whereas in BPM, there are 60-70 vendors, growing in the BPM space, adding ECM functionality as a rounding function, not out of a necessity to find new growth opportunities.  I think she has a point – for some of the ECM vendors it looks a bit desperate rather than aggressive.  It doesn’t mean they shouldn’t continue with the strategy but it does look like a strategy of necessity.

As Sandy Kemsley reviews it:

Looking at the issue of products, they showed a slide that looked at overlaps in product spaces, and puts BPM in the structured process/data quadrant, with case management far off in the opposite quadrant. As Hill points out, many of the BPM vendors are extending their capabilities to include case management functionality; Bell stated that this might fit better into the ECM space, but Hill countered (the first real bit of debate) that ECM vendors only think about how changes in content impact the case, which misses all of the rules and events that might impact the case and its outcome. She sees case management being added to ECM as just a way that the relatively small market (really just four or five key vendors) is trying to rejuvenate itself, whereas the case management advances from BPM vendors are much more about bringing the broad range of functionality within a BPMS – including rules and analytics – to unstructured processes.

Not everyone shared my disappointment at the lack of debate – I thought it was a missed opportunity to really dig into one of the few controversies in BPM.  The session was still good and well worth attending – it just wasn’t what I was expecting.

Keith Swenson has another post where he compares Case Management to BPM:

“The two approaches are very different:

• Sherlock Holmes will use a case management approach, not a BPM approach, when solving a case.
• Bank of America will use a BPM approach, not a case management approach, to support signing up people for new regular accounts.
• Admiral Thad Allen will use a case management approach, not a BPM approach, when responding to the oil disaster.
• Amazon will use a BPM approach, not a case management approach, to handling sales of common books.”

I’d propose another example:  I sure wish BP had been using a BPM approach on that oil rig, rather than a case management approach that allowed winging it with decisions like whether or not to use drilling mud.  I wish there had been a little more BPM going on in the mortgage business pre 2008 – not just signing up new accounts but making sure that customers actually met credit and income requirements.

I think there are more than just mundane examples of where a little more BPM would be a good thing.

Keith has another interesting comment:

To say that these approaches are the same, because they both help to get work done, ignores the very essence of BPM and case management. Yes, they are both techniques to help accomplish work, but they achieve this result through different means.

[...]

This has nothing to do with any vendor’s product. I am not making a sales pitch here. Those that say their favorite BPMS can do all of this are simply pointing out that these two management practices can be supported with similar technology – and many products will support both approaches. But remember, BPM, and Adaptive Case Management are not technology, not products. They are both approaches to managing work.

Interestingly, because they are both approaches to managing work, the same people are likely to be involved in both approaches.  One can argue about which approach “wraps” the other approach, but as BPM is an amalgamation of techniques and approaches, the question (to me) is whether case management is just another one of those, or whether it is a whole “methodology” unto itself.  A relevant example:  Six Sigma and Lean are examples of different approaches to process improvement that, today, most people lump together because they both represent useful sets of tools for the same set of people engaged in process improvement.

Steve Wood, in the comments, captures my thoughts well:

“So, for example, when I look at how an agent supports a customer through an issue. At the high level, it’s very BPM-like, at the implementation level it’s very hybrid. I can optimize some tactical processes to improve performance and also optimize tactical experiences to improve case management.”

And of course, Max J Pucher has a well-worded  comment also:

“Analytic knowledge provides conversation pieces but no practical how-to knowledge and is thus quite useless.

The ‘war of who owns ‘adaptive cases’ is thus quite senseless. I do agree that I am chasing windmills in asking for a common sense approach, but at that is also the reason why the question whether BPM, ECM, E20 or ACM will bring adaptiveness won’t be agreed upon.”

Its an interesting read in the discussion / comments and the wealth of different perspectives – even from people who co-authored “Mastering the Unpredictable”.  Unfortunately, as with most of these discussions, there is a little too much focus on the arbitrary limitations of software tools (the specific experiences of the authors with either specific ACM or BPM tools), rather than sticking to Keith’s original premise that we’re talking about two different kinds of work, but it is a small blemish on a good discussion.

Redux Online’s guest blogger Ashish Bhagwat reposted styles of process, distinguished by their attributes… including: Case Management.  Was it posted by Gartner sometime in the last couple months, given all the debate on Case Management?  Nope.  It was posted in 2005.

Recently, we have had few on Case Management and unstructured processes. Those may have been triggered by an acquisition or two, or certain technological developments that made case management easier to achieve ‘technologically’ than earlier. But, most of us know it is not new in terms of problem space, in terms of definition and also in terms of implementation. I have been looking for something to confirm this – Case Management flavor of process management has existed almost all along.

And I stumbled across this picture that described the “styles” of processes in June 2005. I thought I’d share it and remind all of us that problem space has not changed by much!

I find myself in violent agreement.

Frank Michael Kraft has a good writeup of ACM questions and answers, that speaks well to people familiar with BPM :

Q: What is a specific example of the kind of knowledge work that might be supported?
A specific example is described in my chapter “Improving Knowledge Work” in the book “Mastering the Unpredictable”. There is Leona who works for a telecommunications company as an engineer and she needs to do phone support. The work she does in the support area is described with examples, as customer complaints need to be solved. Some tests need to be executed and some countermeasures need to be taken. The work is unpredictable, because the tests and the countermeasures depend on the situation. However the work can still be supported with Adaptive Case Management.

What I like best about his writeup is that he doesn’t set out to bash BPM before making his case in favor of ACM by first describing the problem, then describing the solution (ACM). He has a series of posts on the subject, all worth reading.

However, if I may be so bold, let’s look at the last statement.  “… However, the work an still be supported with [software package or knowledge work management approach]“  The part in brackets, Frank has filled in with the words “Adaptive Case Management.”  But the important thing isn’t the three letter acronym (or three word phrase) that describes the space.  If you are actually implementing your knowledge work emergent processes, the important thing is what the capabilities of that software (or management approach) are – and how well it supports your work.

Max J Pucher in a comment on Keith Swenson’s blog said that he didn’t care what label was applied to Papyrus by the industry or analysts – it solved problems and created real value for clients.  I guess I feel the same way.  If software that supports the use cases that Keith Swenson and Frank Kraft are describing ends up being called ACM, I guess I shouldn’t worry about it too much.  But I think some of the negative things said about BPM software packages reflect specific experience with specific software packages.  Another package that carries the same name (BPM) may have quite different capabilities (though quite a bit of overlap as well).

Pega, IBM, Oracle, and others are going to position hard that they handle Case Management (and ACM) – and if the vendors and thought leaders pushing the ACM label want to keep it differentiated they’ll have to get into the technical details as well as the philosophical (panned versus unplanned, is a philosophical distinction more than a technical one), to illustrate why customers should choose one product over another for the particular challenges they’re facing.

Theo Priestly on BPM Redux wrote about ArisAlign and its lack of “buzz”.  I’ve had similar feelings about Aris’ user experience, and the feeling that some of the enthusiasm espoused is a little forced – sort of trying to hard with the “I (heart) ArisBPM” pins, etc.

But the post reminded me of a theme that has been on my mind a lot over the last year: Design Matters in BPM. As if there was any doubt, I see more and more evidence that in the Second Decade of BPM, design will matter.  Not just a little bit.  I believe design will dictate whether BPM achieves ubiquity in the business. Design will dictate which tools will benefit from that ubiquity.

Apple serves as a good example of how much design matters in an industry that appeared to be commoditized (personal computing, cell phones).  Some might argue that BPM software isn’t commoditized yet, and therefore the focus might be on features/functions rather than “design”.  But I think the key elements of BPMS are, by enterprise software standards, fairly commoditized:  there are many players in the space, customers have a difficult time discerning the differences from a feature/function point of view, and ASP (Average Selling Price) is likely declining for most BPM vendors.  There are also a couple of open-source BPM software offerings on the make.

Combine the above with a trend toward putting BPM suites “in the cloud” and offering them in a SaaS model, and it really starts to look more like a utility.  But what takes it to the next level?  Here are some areas of BPM and my thoughts about how well they’ll differentiate vendors…

• Execution.  I think everyone agrees execution is nearly commoditized.  There are *real* differences at the execution level, but the market doesn’t recognize these differences in a way that channels dollars to the best execution engines.
  
• Simulation. Many of the vendors offer this.
• More modeling constructs? Already, vendors barely provide a fraction of the BPMN modeling capabilities defined in BPMN 2.0 (or even 1.0).  So, there’s an opportunity here, but fast-following will be pretty easy.
• Process Discovery? This holds some promise for differentiation in the short-to-medium term, in my view (there are only a few vendors who even claim this ability).
• Optimization? This has potential, but the current solutions simply don’t achieve it.  They work really well on small data sets and don’t (yet) let you efficiently do “optimization” on enterprise production data.  There’s a significant software investment to make here, and opportunity for differentiation.  Pair optimization with process discovery and you’ve got something really interesting…
  
• Modeling tools?  This is heading toward commodity rapidly.  Absent the advent of SaaS software I would have predicted an open source modeling tool would gain pre-eminence and get embedded in a lot of commercial products.
  
• SaaS / Cloud offering? There are already numerous choices and prices are heading toward standard increments.
  
• Community / Collaboration?  Outside of BPM, these are already fairly commoditized from a feature/function point of view.  Wikis, chats, Instant Messaging, Videochats, Communities – these features will not provide differentiation on their own.  In fact, vendors may rely on Wave or similar technologies to incorporate collaboration without making some of the IT investments that early adopters have had to make.
  
• “Dynamic” BPM or “Case Management”.  Call me crazy, but I remember CASE tools being all the rage in the mid-90′s.  I think unstructured, dynamic, and case management style processes are important, but I don’t think the technology required will offer differentiation to vendors for long from a feature/function point of view.  What they offer is a “better fit” to these use cases, but they’re not solving a problem that couldn’t be solved before.  (Note: Better fit matters, its why you should use BPM tooling to solve process problems rather than just slinging some Java or PHP code or hoisting a SOA stack into place)  To the extent that these “case management” tools are better, its a result of better design to suit the problem, not a case of out-featuring the other guys…
  

The opportunity for BPM vendors will be to produce differentiation based on the design of their products and offerings, by producing designs that engage the users, that elicit effective and efficient usage.  Collaboration, Unstructured BPM, Process Discovery, and Optimization all offer the biggest opportunities for differentiation by product design, in my opinion.

In closing, I should clarify that product design is not just skin deep.  Some make this mistake when they look at Apple Products and see only the outer shell.  Good product design goes much deeper than the UI, than the outer shell of the product.

Lately there’s been a bit of a buzz about CRM.  Not sure what caused it, but here are three thoughtful articles on the subject:

1. Derek Miers’ post on Case Management revival
2. Bruce Silver’s commentary regarding a new OMG spec RFP for Case Management.
3. Paul Vincent’s blog for Tibco, where he mentions PRR and DMN… and Case Management yet again…

I’m still waiting to see a really good case being made that Case Management requires or lends itself to different technical solutions than, say, BPM.  Having said that, I’m also sensitive to the fact that as BPM was picking up steam, many in the SOA stack community wondered why BPM wasn’t just a “feature” of SOA.  The fact that I don’t yet have the information to prove to myself that Case Management has technical requirements not addressed by BPM, does not mean that such information won’t be forthcoming.

Update: Bruce Silver has another update – apparently there was a bit of controversy about the case management proposal at OMG recently, and a little bit of blogosphere dust-up resulted.