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.