Peter Schoof asked this question on his EBizQ forum this morning, and I thought I would copy my response here:
This question hinges on a clear understanding of traditional flow-chart oriented BPM for which there is some widespread confusion. As you read responses to this question, keep in mind that many people confuse BPM (which is a management practice) with BPM Suite (which is a technological product to support the practice). Many BPM Suites support not only the practice of BPM, but many other management practices as well, and this confuses the entire discussion. For discussion, we should use the updated, One Common Definition for BPM.
Traditional BPM is a management practice that views the “process” as the most important organizing theme. A practitioner of traditional BPM talks about “optimizing a process”. In order to optimize a process, there must be a concrete representation of a given process; it must be useful for many individual instances of the process; you must be able to measure how good this process is in abstract from a given case. Traditional BPM is a practice of perfecting that process is for the purpose of supporting of future cases. This only works if you have confidence that future cases will be like the cases of the past that you are measuring the process against. In short, the process must be predictable. Traditional BPM is based on mass production principles: the up front investment that you make in perfecting the process, is paid back in a increase in efficiency over many instances of the process.
Case Management is a technique that is useful when processes are not repeatable. A case represents a situation without necessarily requiring a process. Case management can be used for one-off situations for which the process can not be predicted in advance. A practitioner of case management needs a different kind of support: instead of tools to aid in the elaborate design and optimization of a process up front, a case manager need a way to communicate goals and intent. There is no point in investing a lot of up front effort in designing an optimized process — because it is unlikely to fit the situation, and unlikely to pay back the up front investment — so instead the investment is in information tools and capabilities that can be used directly by the case manager on demand: such as information collecting tools, and communications resources. In short, case management is useful when the process is unpredictable, or at least not repeatable enough to warrant the up front investment in perfecting the process.
The two approaches are very different:
- Sherlock Holmes will use a case management approach, not a traditional BPM approach, when solving a case.
- Bank of America will use a traditional 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 traditional BPM approach, when responding to the oil disaster.
- Amazon will use a traditional BPM approach, not a case management approach, to handling sales of common books.
To say that these approaches are the same, because they both help to get work done, ignores the very essence of traditional BPM and case management. Yes, they are both techniques to help accomplish work, but they achieve this result through different means.
Some will say that even in case management since ultimately a sequence of activities is performed, that this is a “process”. Yes, you can view that retrospectively as a process, but not one that has been or can be “improved or optimized” in any way similar to the practice of traditional BPM. Yes, it is true that the case manager gets better over time, because they learn their job. But to argue that all learning is actually “traditional, flow-chart oriented BPM” stretches the definition of a flowchart too far to be useful. Traditional, flow-chart oriented BPM remains important as a distinct practice of defining, measuring, and optimizing a process in abstract from a given case, for use in future cases.
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, traditional, flow-chart oriented BPM, and Adaptive Case Management are not technology, not products. They are both approaches to managing work.
Those interested in this topic should look at the 350 pages that 12 different experts collaborated on to attempt to describe this subject:
http://MasteringTheUnpredictable.com/
Also, look for the Tweet Jam on July 15 where we hope to discuss this publicly.
Update:
This terminology in this post was updated to make it consistent with the One Common Definition for BPM proposed in January 2014.
Thinking Matters 
Pingback: links for 2010-06-16 « steinarcarlsen
That’s an excellent explanation. I’ve not heard one so succinctly put.
I have a question through: where does Social BPM fit in?
The reason I ask is that I believe (and the definition I’m running to) is that Social BPM is trying to solve both problems – it’s a shared methodology between traditional BPM and case management. So, from a “tools” perspective (which is my interest area to support the concepts), it means that the tools can accommodate both. I think it also limits the scale at which BPM can be applied by combining them (but that’s a beer conversation).
Another way to think about it might be to say that we need to stop thinking about them as different methodologies. Case management implementations (and the tools that drive them) are too flexible and BPM is too inflexible (tooling mainly – but also concept too rigorously applied). There’s got to be a middle ground.
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.
Just some thoughts. I’ve not written a 350 page book on the subject – but I will read it with interest!
Thanks for the supportive comments!
Social BPM appears to be, as you have concluded, split into to usages, so it is another term I like to avoid.
One usage is simply the application of collaborative support to the traditional BPM cycle. I call this direction “Process Wiki” because of the focus on collaborative design of more or less traditional business solutions.
The other usage is more worthy of the title, and that is looking at using social software in a business setting, and then figuring out what kinds of process support is needed. For example, I could use my FaceBook friends as a way to assign activities to the approriate people. This example works for both pre-defined formal BPM processes, as well as on-the-fly case management tasks.
See my discussion in: https://kswenson.wordpress.com/2010/05/12/who-is-socializing-in-social-bpm-2/
I don’t think there is any benefit in unifying BPM and ACM — there is no need for a one-size-fits-all management approach. There are routine processes that call for a no-compromises BPM approach. Other emergent situations call for an uncompromising ACM approach. As you point out, these often co-exist at different levels. Keep watching this site, because in the next 6 months I will be exploring some exciting new directions similar to this slide cast:
http://www.slideshare.net/kswenson/200906-largescale-federated-bpm-workflow
Keith, we now face the discussion whether BPM or ECM should be the carrier of case management, adaptive or not. Also BPM has tried to be adaptive for a long time and ad-hoc BPM solutions and certainly now the social add-ons present their claims and try to stake out their territory expansions. It is like the Wild, Wild West with wagons racing to be there first.
How could we stop this silly market fragmentation discussion and focus on what businesses actually need and how we get that solution to them? Yes, businesses need ECM, BPM, CRM, ACM, BRM, BAM, and E20 functionality to deal with knowledge work but certainly not as products to be integrated …
Pingback: Tweets that mention https://kswenson.wordpress.com/2010/06/16/what-is-the-difference-between-case-management-and-bpm/#more-984?utm_source=pingback -- Topsy.com
Pingback: Tweets that mention What is the Difference Between Case Management and BPM? « Thoughts on Collaborative Planning -- Topsy.com
People have a natural tendency to try to find “the one true answer to everything” born out of the idea that there must be a simple solution to everything. I think we are getting over the hurdle of thinking that ACM is just BPM.
“The ocean is a desert with its life underground and the perfect disguise above.”
Perhaps we need a framework that helps people to organize all the different kinds of approaches (not tools) fit in relation to each other.
Keith, I don’t see the problem with ‘one true answer’. I rather believe that people have the natural need to stereotype (is a kind of) to be able to think in abstract terms. 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.
Keith,
I agree that unpredictability is a key attribute of case management, but I think many people underestimate how that “small” change – from predictable routine processes to unpredictable processes – changes just about everything you expect from your tools. Here is a partial list of how the approaches (and the tools that support them) differ:
1. In a case management approach participants control the process, and change it on a case-by-case basis. They (and not a process owner) have complete control over the case. They are expected to manage
o Flow changes
o Participant changes
o Activity changes
to meet the needs of the case. Process management will allow some level of participant control, but that on a limited basis. The process owner has a lot of control, even when they don’t play a direct participatory role in a specific process instance.
2. Since the work can’t be rigorously defined ahead of time, each case instance must have a goal, deadline and a defined work product. In process management these can be replaced by a model of the process.
3. Every case instance needs an owner for that instance. In a process management approach there doesn’t need to be an owner for every instance, but there needs to be one for the process and its model.
4. Since a case consists mainly of interactions between human participants, managing collaboration and negotiation are key parts of a case management approach. This isn’t true for for process management – many would argue that eliminating these “time wasters” are one of the goals of a process management approach.
5. In a case management approach, content is an integral part of the work, it is both consumed and produced as part of the process. Content is important for a process approach, but not as central.
Jacob Ukelson – CTO ActionBase
Very good point. Many people mistakenly think that an unpredictable process is handled like BPM with a new type of process called “ad-hoc”. It is so important that people realize that this not just a new kind of process, it is a completely different approach (as you have explained). Thanks for the comment!
Jacob,
I wholeheartedly agree with your statement that the addition of that small “un-” in front of predictable makes a world of difference. We go from a world where order rules and everything lines up neatly to a world where the opposite is true.
Your point about content is valuable as well, it is indeed important (both incoming and outgoing) but as you say, it’s not everything. My belief is that content, data, and (gasp!) process are all first-class citizens in the case management space. Meaning that any one of those should be treated as equal and not always subservient to the other (as content often is in BPMS implementations). The practical implications are that we can bring structure and repeatability (process) to a case where appropriate, and that cases and documents can stand on their own as they often have their own lifecycle outside the business process.
Good conversations, glad to see others joining in as well!
Fantastic Explanation Steve and some great conversations.
The problem is that flow-, participant-, and activity-changes in a flowcharted process are handled by dynamic, social, and ad-hoc BPM. So that won’t be enough distinction.
In our book ‘Mastering the Unpredictable’ I stated in my chapter ‘Elements of ACM’, that there are actually FIVE of those: 1) data, 2) content (received&sent), activities (tasks, can be subprocesses), rules (also goals), actors (roles&participants). All those must be adaptive, meaning that they can be added, changed or deleted by properly authorized participants. One can also build a rigid process with the above. In BPM a business user CANNOT assemble a process or case from the above elements on the fly.
Let’s not forget that CONTENT means to manage for outbound a library of standard texts, layouts, rules to assemble documents, security and privacy rules (i.e. HIPPA), while for inbound content it needsscanning, text and image classification, OCR, data capture and extraction, data validation rules and backend data validation and automatic case assignment. That is the reason that ACM is in principle closer to ECM than to BPM, which is utterly ignorant to such functionality.
One could declare that the difference between case management and BPM is that each case instance must have a specific owner, while in BPM a process has one owner for all instances. I see that as an arbritrary choice. Not wrong, but not a key distinction.
The key difference to CM and BPM is that in ACM, adaptive means that knowledge from the execution is fed back into the template and that there is no upfront analysis phase to create a process. As execution is not rigid there are no exceptions and variants necessary. Creating the process/case becomes much easier.
Smoe more observations:
A case does not have to define a work product. Often, the kind of work to be performed to fulfil a goal has to be identified during the case. A case can include negotiation or not. If for each task a single expert performer is assigned by another participant there is no need for negotiation.
The problem is much broader than discussing differences to the fuzzy definitions of BPM and CM. Thanks for the discussion.
Pingback: Library clips :: Have we been doing Enterprise 2.0 in reverse : Socialising processes and Adaptive Case Management :: July :: 2010
Pingback: Process for the Enterprise » Blog Archive » BPM vs. Case Management Yet Again
Keith ,
a good and precise explaination on BPM and Case management . However , I have a question : how different is case management from business event management wherein unexpected events trigger off processes ?
I believe that case management is very different from what you call “business event management”. Some call this complex event processing.
Defining a process to be programmed in order to respond to a number of specific events is still a predefined process. A BPM process can be designed to be able to respond to any number of incoming events. Your event handling can be arbitrarily complex in order to have a response for any possible incoming event trigger.
This is not quite what you said. You said “unexpected event”. If it is unexpected, how can it trigger things? If it “triggers” something automatically, then it is, at some level, expected.
If instead you said that unexpected events arrive, a person looks at them, and then decides to run a process, then that looks a lot like case management. But I would not describe the event as “triggering” the process. Instead, the case manager started the process.
Does that help make it clear?
Keith ,
thanks for the clarification .
Keith,
I never understood the difference between case management and BPM until I read “Mastering the Unpredictable”.
Civerex built a ‘case management’ in 1992 that had a strong focus on guiding the processing of patients according to “best practice” protocols.
We took this direction this because our company received a grant from a hospital association to build healthcare software where the entire focus was on instances (i.e. patients), and where no two instances are handled in exactly the same way. We had ‘cases’ from the start and we called these Electronic Medical Records.
We never had issues with unstructured work – our users could process patients using protocols, process not using protocols, or both. Basically, they have always done what they like, when they like, how they like.
I found by reading “Mastering the Unpredictable” that what we have been doing for the past 15 years is called ACM.
We realized something was different about our BPM system. We found it difficult to engage many consultants in conversations about our software – they would typically look at us as if we were from another planet (always a possibility).
So we renamed our approach at one stage to BPMx. And then, about a month ago, to ACM/BPM.
I don’t understand or agree with everything in the book but our ability to communicate with management consultants has improved dramatically.
I tell anyone who will listen that “Mastering the Unpredictable” is a must-read.
Congratulations to all who contributed.
K Walter Keirstead,
Managing Director,
Civerex Systems Inc.
http://www.civerex.com
Pingback: Are BPM suites another 4GL (fourth generation programming language) « Jacob Ukelson's Blog
Pingback: Business Process and Adaptive Case Management News and Information » Are BPM suites another 4GL (fourth generation programming …