With a title like that, how could I miss this session? Toby Bell (ECM), Kimberly Harris-Ferrante (insurance vertical) and Janelle Hill (BPM) took the stage for what was really a live research session rather than a debate. Is it a process pattern covered by BPM? Is it functionality within ECM? Is it an industry-specific vertical application? Gartner is still evolving their definition of case management (as are many people), and currently publish the following definition:
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/rules to achieve decisions about rights, entitlements or settlements.
The path of execution cannot completely be predefined; human judgment and external events and interactions will alter the flow.
Harris-Ferrante said that we need to first create industry-specific definitions or examples of what a case is, then this definition can be presented in that context in order to make sense.
Bell made the distinction between content-triggered automation (e.g., paper invoice scanning and processing), collaborative content-rich processes (e.g., specific projects such as construction), and case management: there’s a bit of a spectrum here, based on a variety factors including cost, complexity, people involved and time to completion. Case management is distinguished from the others by (human) decisions supported by information: Hill felt that this decision-support nature of case management is a defining feature. Harris-Ferrante talked about the cost and risk factors: case management is used in situations where you have compliance requirements where you need to be able to show how and why you made a particular decision. She also pointed out that rules-based automated decision is really standard BPM, whereas rules-supported human decisioning falls into case management.
They showed a slide that talked about a continuum of business process styles, ranging from unstructured to structured; looks vaguely familiar. Okay, they use “continuum” rather than “spectrum”, have five instead of four categories, and put structured on the right instead of the left, but I am a bit flattered. Their continuum includes unstructured, content collaboration, event driven, decision intensive, and structured activities; they went on to discuss how case management is the most common example of an unstructured process style. I found that wording interesting, and aligned with my ideas: case management is a process style, not something completely different from process. Business process management, in its most generic form, doesn’t mean structured process management, although that’s how some people choose to define 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.
Hill stated that Gartner doesn’t have an MQ for case management because there are so many different styles of case management: content-heavy, decision-heavy, and industry-specific packaged solutions. Besides, that way they could sell three reports instead of one. Not that they would think that way. Harris-Ferrante discussed the challenges to case management as an industry application, including the lack of shared definitions of both cases and case management, and Bell stated that buyers just don’t understand what case management is, and vendors are rejigging the definition to suit the customer context, so aren’t really helping in this regard.
In spite of stating that they don’t have a case management MQ, they did finish up with a slide showing the critical capabilities that customers are asking for in case management. such as a balance of content, collaboration and process services; and high-configurable case-based user interface. They lay these out against four styles of case management – collaborative forms-based case management, knowledge workers collaborating on internal content, regulated customer-facing file folders and data, and costly processes initiated by customers – and indicate how important each of the factors is for each style. I definitely see the beginnings of an MQ (or four) here. They did state that they would be issuing a research report on the great case management debate; I’ll likely be giving my take on this topic later this year as the industry track chair at the academic BPM 2011 conference.
It’s clear that the definition of case management needs to firm up a bit. As I asked in a tweet during the session: case management: is it a floor wax or a dessert topping? As any old Saturday Night Live fan knows, it’s both, and that could be part of the problem.
Sandy,
Hi, thanks for the writeup, it is invaluable to us that couldn’t make it to the conference.
I actually think that it was “the vendors” (which I guess ActionBase is one of) that generated the debate about Case Management, because we saw a need in the marketplace that wasn’t fulfilled by BPM. I remember attending a Gartner BPM conference about 3 years ago, talking to analysts about unstructured, ad-hoc prcoesses and getting blank stares.
I agree that most customers don’t know what Case management is – but I see that just as much the fault of Analysts as the vendors. The only analyst report about case management is the Forrester Dynamic Case Management report – but it put an over riding emphasis on structured process, which I think minimized its value. We don’t need another way of handling content intensive structured processes, what is needed is tools for the management of unstructured, adaptive, human processes.
Finally I don’t think you can just “glom on” case management to a standard BPMS, unstructured process management is very different than structured proess management – and the tools need to reflect that difference and its subtleties.
I am not sure I understand the continuum notion especially the order – for example meetings tend to be very unstructured, but they can also be very decision intensive – and the “content” comes later in the process (think of a Board of Directors meeting where decision are made which kick off proceses which need to be tracked and monitored, along with the related content.)
Jacob Ukelson – CTO ActionBase
Thanks for the report. Very interesting indeed. As always we find the analysts taking information from the market and not giving reference to who they took it from.
While I do agree on the classification of process types I see it as a fallacy to propose them as different functionalities needed. It is creating an arbitrary order where there is none! It’s like having to go to three different restaurants for starters, main dish and dessert. Possible, but neither enjoyable nor efiicient. Businesses need only ONE PROCESS ENVIRONMENT. And it has to support all process types because within a business capability or even a single case all process styles – unstructured, content collaboration, event driven, decision intensive, and structured activities – will take place. BTW, the processes are unstructred because much of the content collaboration is event driven and therefore decision intensive. So the whole list is to me a tautology – meaning the same thing – a customer focused process.
I defined in 2009 that based on a Business Architecture Adaptive Process technology must expose structured (business data) and unstructured (content) information to the members of structured (business) and unstructured (social) organizations to securely execute – with knowledge INTERACTIVELY gathered in previous processes – structured (process) and unstructured (case) work in a transparent and auditable manner.
Jacob and Max, thanks for the comments.
I agree that the continuum as presented for Gartner didn’t really make sense: more discrete points than a continuum. When I discussed the spectrum in my previous blog post on this, I was talking about only one dimension, namely unstructured to structured. We really need a multi-dimensional space to represent this properly.
Max, I completely agree that having organizations buy several different systems all for similar types of process-related work is not the best way to go. Gartner has been pushing the “multiple BPMS” for a while (see https://www.column2.com/2010/03/but-customers-dont-want-three-bpmss/) and it just doesn’t fly for me or many of my customers, who want something more comprehensive from a single solution.
Sandy,
I think IT would like a single tool for both ends of the spectrum (assuming they have actually thought about unstructured processes – most IT departments haven’t) – and they would like to believe (hope?) that unstructured processes are just a special case of structured processes . I don’t believe that to be true, and I don’t think the business cares – they just don’t want have to pay for another tool…
Since the ends of the spectrum (structured to unstructured) are so different I think the answer is more a “suite” solution (an integrated set of discrete tools) than a single tool that spans the spectrum from structured to unstructured. They could all be from one vendor, or not.
Jacob Ukelson – CTO ActionBase
Every time I see this title I get worked up and wonder what the vendors will be telling us next. I keep hearing about the solutions now support unstructured and structured processes and how completely adhoc tasks can be supported outside the stipulated process path.
My issue with these definitions of case and specifically dynamic case is that in the last fifteen years of consulting to clients across a range of industries not one of them has come to me with requirements to support these so called ad hoc processes. And allow process participants to define ad redefine processes on the fly. Why, probably because it would cause chaos and there would be a real risk of reputation and regulatory penalties. One client expressly refused to allow their staff to change parameters within a process let alone define completely new processes.
The closest requirement I have seen is at a recent client where we defined a high level process of five steps to manage a claims case. At each stage the knowledge worked had a list of pre-defined optional tasks that could be taken depending on the circumstances. Just because we can allow process participants to create these ad hoc tasks I can see many reasons why we wouldn’t. How do you ensure that the new activities and processes are compliant with corporate rules and policy, for instance? I can see the audit department insisting on introducing an authorisation process to have the change verified and approved, which would most likely eliminate any time to market advantages gained by allowing the knowledge worker to adapt the process in the first place. Am I going mad or is it just me?
Nicholas, I certainly agree for a lot of use cases. I work primarily with financial services and insurance companies on their back-office processes, and you can be sure that none of them allow their line-of-business processes to be modified on the fly for exactly the reasons that you state: regulatory compliance. There are use cases for more dynamic processes, and I’m sure that Jacob can point to many that they are seeing, but that doesn’t mean that everything should be considered as potentially dynamic/ad hoc. Rather, the “processes” that are currently being done via email and other completely unconstrained means can be considered for dynamic process management, or ACM, since the alternative is not managing them at all.
Jacob, I don’t think that everyone in BPM thinks that unstructured processes are just structured processes waiting to be analyzed properly, although there is some amount of that. The bigger issue is processes that are a blend of structured and unstructured, depending on where they are in their execution: some structured back-office processes have front-office customer-facing portions that need to be dynamic to allow someone to solve a customer’s problem. Unless we want to look at bridging systems — which is the common solution now — I really think that we need tools that can handle the full range of structured to unstructured.