(Adaptive) Case Management and how it relates to BPM (and ECM) seems to be getting a lot of attention lately (from Scott Francis, Adam Deane, Lee Dallas, David Mitchell). All worth a read if the topic interests you. Some serious, some funny  – they show that something new is stirring in the process management community.

One important part of the puzzle that everyone seems to be ignoring  are the sidebar  human conversations that go on with respect to a process or a case. For me linking those sidebar conversations to the process (or case) is a key aspect of how Social BPM and Adaptive Case Management are different from traditional BPM and Case Management. 

• Traditional BPM – structured processes usually should not generate a lot of sidebar conversations (if they aren’t being used to handle an exception). The process has been modeled and tasks assigned – so what is there to talk about?  So most traditional BPM systems tend to ignore sidebar conversations, and for most instances of a process, that is OK.
• Traditional Case Management – here too sidebar conversations are ignored.  Mostly for the same reasons they are ignored by traditional BPM -  since the case flow is predefined and rigid, and any important information should be included in case folder – so these sidebar conversations aren’t relevant to result. I think this is a bigger issue here than for traditional BPM – since case management is a human activity, and human activities by their very nature generate conversations. A lot of learning is wasted by having participants use external mechanisms for these sidebar conversations.
• Social BPM – Here the BPM community noticed (at least for the process of understanding and modeling a process) that sidebar conversations are an important part of the process (and may be the main part of the process), and need to be supported as part of the tooling.
• Adaptive Case Management – Since these are unpredictable, ad-hoc, human processes – conversational human-to-human sidebars around the process being handled are VERY important and need to be considered part of the process. They play a large role in  defining how the process will flow. I believe these are what enable unpredictable  processes to actually work and a generate successful outcomes. Not making them part of the ACM tool – will cause the tool to fail.

So I guess what I am saying is that lets not forget the need to include human-to-human sidebar conversations (and enabling them to be done efficiently and effectively) is a key component of Adaptive Case Management (and Social BPM)

I was reading a Gartner report on on “wicked problems” in business transformation (or as it is actually called “Introducing Hybrid Thinking for Transformation, Innovation and Strategy”). They define wicked problems as “those that defy conventional approaches to understanding, planning, design, implementation and execution because:

• The stakeholder interests are so diverse and divisive.
• Interdependencies are so complex and so little understood.
• Behaviors are so dynamic and chaotic (unpredictable).

Leaders who do recognize wicked problems typically don’t speak in terms of “solving the problem,” because wicked problems involve such fundamental trade-offs that they don’t have a “solution.” Instead, they speak of “taking on” a wicked problem to produce a “successful outcome,” which merely means that the outcome of the effort leaves the organization sufficiently better off that it was worth the effort.”

I think a lot of the issues faced by today’s knowledge worker fall into that category (though not necessarily on the same scale). Knowledge workers deal with wicked problems ”in the small” everyday. These aren’t the kind of problems that a standard BPMS is designed for (though it seems like the modeling part of a BPMS implementation is itself a “wicked problem”).

I believe that adaptive case management (ACM) could become the “process” toolset  for supporting the management of the processes used to bring wicked problems to a successful outcome. Some maybe we should call it wicked BPM?

I remember from my days at IBM Research that Tony Temple was driving home the mantra that “Simple is Good” for IBM’s software and hardware – i.e. the simpler it is to use  technology, the better it is for eveyone.  If that was true (simple is really better for everyone) – then IBM wouldn’t have needed a VP going around and telling people that – they would would have known it themselves. Then it hit me – simple isn’t good for everyone. For some people (especially IT technologists) powerful beats simple. They want powerful tools, tools that let them the job done. They tend to like gadgets and features so for them simplicity takes at most second place (or maybe isn’t thought of at all as valuable). When you build tools for technologists powerful and complex beats simple every time.

For me that is what is happening right now in the BPMS world. For the technologists – BPMS need more power and complexity inorder to make it easier for technical people to handle the complexities of real world processes (e.g.BPMN 2.0 (and counting),  rules,  CEP). If BPM folks even think about simplicity, it is in the context of the end-user application that is the result of their use of a BPMS (though to be honest, I don’t think many BPMS powered applications would win any usability prizes).

But something has started to shift. As Sandy Kelmsley puts it “the blurring of the boundary between designing and participating in processes” is a trend happening now. I see that as one of the key drivers adaptive of case management (ACM). That means the ability to create and change processes is moving into the hands of everyday process owners (and users), no longer can it remain in the hands of technologists (the tradtional users of BPMS).  This is a radical shift, and I think people are underestimating how hard it will be (both from a cultural perspective and technical perspective) for BPM vendors to make this shift with their tools. As a technologist that has worked in usability for a long time I can tell you making things simple is much harder than making things complex, and that is the technologists collorary to the “Simple is Good” message – for a techologist “Simple is Hard”.

“Mastering the Unpredictable” is finally out in its official edition – available in hardcopy and Kindle.Kudos to Keith Swenson who did an amazing job in getting the book out in record time.

Since I spend a lot of my time explaining to people what unstructured, unpredictable ad-hoc process are used for, I give a couple of simple everday examples trying to explain the importance (and ubiquity) of these processes:

1. Complex Project Management – there are many excellent tools out there to help plan projects and keep them on track, but in most cases for project execution, tracking and management everyone falls back on the tried and true methods of email and documents. This is true for every type of project – but especially those done by IT professionals. There is a project owner who defines specific project related goals and checklists, but that is it – everything else is managed on the fly by the participants themsleves and guided by the project owner.  Adaptive Case Management can help manage that part of the project management processes (and BTW this is a standard ActionBase usage scenario).

I think this is reason the BPM community is so “hot” on Social BPM – they’ve discovered the hard way that there a class of processes (in their case business process modeling) that is an inherently unstructured, unpredictable and hard to manage project.  What they don’t seem to understand yet is that there is nothing special about BPM implementation processes (modeling or otherwise) - the same issues hold for any project, but I won’t belabor this here since I have posted on it in the past.

2. Executive Management Decision Tracking – For example at a Board of Directors meeting any number of decisions are made that require a follow-on process. From the executive level it can seem like a simple request (”get us the information on XXX” – e.g. the state of our audit processes), but that request quite often turns into a full-fledged, ad-hoc process that can involve quite a few people and needs to be managed. Again the tools of preference for executing these processes are email and documents. No one would even consider modeling the process, especially since it probably isn’t completely understood until it starts executing (making it true “Design by Doing”). The best one can hope for is an owner, goal and maybe a dynamic checklist (and of course an owner). 

Many high-level, complex project management  scenarios are similar to unpredictable, ad-hoc process and would benefit from using adaptive case mangement. I wonder – Is this the generic use case for Adaptive Case Management which is then tailored to specific domain?

I read a really interesting article by William Gladwell on “How David Beats Goliath” which got me thinking about what would happen to business if we could actually accelerate the decision processes done by knowledge workers. Most analysts now agree that knowledge worker processes make up the bulk of processes for most businesses, and for the most part the only tools IT provides for them in their tasks email and documents (and maybe wikis and IM). What would happen if we could magically increase the speed in which this type of work could be done? What would be the ramifications for business? What would be the benefits that could be reaped over competition?

I think everyone would agree that a company that could speed up these critical knowledge workers decision processes would have an “unfair” advantage over its competitors. So what is needed to make this a reality?

A simpler version of this problem can be found in performance problem resolution for complex distributed computer systems. The problem arises because today’s computer systems are so distributed, with so many components that interact in unanticipated ways and with so many transactions flowing through them – performance problems are a bear to solve.

Finding the root cause of distributed application performance problems is a very, very hard problem – and that is for systems much less complex (and less dynamic) in their interactions than human processes.  Not surprisingly, it turns out that the first step in solving such performance problem is having the right data about the actual transaction flow. The premise is that if you collect all the information of how a transaction progresses along its path (both as it happens and a historical view) – then solving a performance problem becomes much, much  easier. The intuition behind this is simple – the best way to fix a performance problem is to understand its root cause, and the best way to find a root cause is to see the problem while it is happening. If you don’t see it “in-vivo” while it is happening – then it becomes a detective task – you only get to see the symptoms of the original problem, and need to derive from those the root cause. Like the TV show CSI – a show that derives all of its interest from how smart people unravel a mystery from its symptoms (or after effects) without the benefit of an eyewitness. It is so interesting because deriving a root cause from symptoms is hard (and the source of many a TV show – e.g. House MD, Law and Order, Fringe). The reason the problem is so hard (and the show so interesting) is that they are studying the after effect of an event, and trying to ascertain the root cause. This blood splatter meant that, this rip was caused by the other. Contrast that to an eyewitness report – I saw X pick up the knife and stab Y. Would make for a really effective investigation (and a really boring show).  Same is true for performance problem resolution in computer systems. If you have the right “eye-witness” data, then in many cases analyzing and fixing the problem is a piece of cake, without the right data – it is a bear.

Performance problem technology went through some interesting phases – first came the sophisticated analysis techniques to help solve the problem (the CSI approach) and now we are seeing new technology and approaches that are focused on collecting better, more effective data (the eye-witness approach) – since examining only symptoms causes root cause analysis to be very expensive, while an eye-witness approach is much more effective (and cheaper).

 The same holds true for knowledge processes. If we want to improve knowledge worker process – the first thing we need to do is collect the right data – not after the fact symptomatic, biased data – but true “in-vivo” data of how the process is actually performed. Only then can we be effective at resolving the problems and speeding up the process. If we could view knowledge worker decision processes as they are executed – then most of the difficulty involved with speeding up such a process (or fixing a broken one) would go away… It would be simple to see where any given decision process stands at any given time, and to understand whether it is healthy or not.

I have been doing an experiment lately. Whenever I talk to a group of people about Adaptive Case Management (or Human Process Management) with knowedge workers that are familiar with BPM  – I ask “How many people present use BPM or a system built on BPM for their everyday work?”. Everyone at these meetings is a knowledge worker and (some of them even develop BPM tools and systems) . Never has more than one person raised their hand. Then I ask who uses email and documents every day, and of course everyone raises their hand. If you ask them how many of them do structured, repeatable, routine work eveyday – then the usual answer is that is always a part of their job, but not what they are paid for.

I know this is kind of a stupid experiment, but it does point out (at least for me) the current state of tooling for most knowledge workers. They consider their work (at least the important part of it) as “Design by Doing” as Jim Sinur so nicely worded it in his blog. BPM as they understand it (and I’m sure that everyone understands it a bit differently – but I’ll guess the ability to model a process, most probably in BPMN, is part of what they think is involved in BPM) has nothing to do with their everday jobs.

Sure we could try and extend BPMS (the tool) to include the kind of work they do, perhaps even extend it enough to have it include email and document management systems (or is it that document management systems include BPMS, I get confused). But why should we? Most BPM systems have hooks that let the system invoke email (and so do document management systems) – but I would doubt most people would consider email as part of BPM. BPM and email are two separate systems which are sometime used in unison to solve a business problem – there is no need to pull them both under the same umbrella. I think the same is true of Wikis and other social technologies – they are useful tools – and there is no benefit pulling them under the BPM umbrella. So in the on going debate on ACM as part of BPM – I’m going to have to side with Keith and Max.

BPMS (the tool, not the approach) is for routine, predictable, structured work where people and documents may play a part – but are not central. ACM is for unpredictable, unstructured, ad-hoc work – where people and documents are central. The two are complementary, but not equivalent. To prove my point, I’ll go back to my old post - no one is building social BPMS tools using BPMS - not even the BPMS vendors.

My presentation from our chapter in the book “Mastering the Unpredictable”

Yeah, I know – it was the process.gov conference, but my real interest was the Adaptive Case Management day (and the launching of the “Mastering the Unpredictable” book). Many thanks to Nataniel Palmer and Keith Swenson for setting it up.

1. My first take away is that adaptive case management covers a pretty wide swath of  approaches. Looking back at Keith Swenson’s chart on “Four Process Trends and 1 Gap” – the gap between human workflow and email is quite large – and some look at ACM as closer to the human workflow side of the spectrum, and we look it at as closer to email. That is OK, and will make for a rich set of tools, each with it own focus – but can cause people to think that we aren’t all talking about the same thing. I believe that all of ACMers are addressing the same business issue (the need for managing ad-hoc, unstructured, unpredictable human processes) – we just are going at the problem from different angles. I think all of the authors agree on that.

2. People have no problem with the notion of ad-hoc, unpredictable processes - almost everyone  intuitively gets it right away.

3. The BPM folks sometimes have a difficult time with the notion that anything that has to do with processes may be outside the scope of BPM. I think everyone continually confuses business process management with what can be done with a BPMS. Since ACM handles business processes of a certain type, ACM is arguably part of business process management, but it  is clear that it is different than BPMS, and needs a different set of technologies and approaches. If you are interested in why – read the book “Mastering the Unpredictable”

4. The type of processes that lend themselves to ACM tend to be a lot like projects.

5. We need to find a wider audience to participate in the ACM community – and I am hoping that we can find business users that would like to become part of this community.

There is a lot of buzz around what is coming in business process management (BPM), a lot of it seems to stem from the social technologies that are starting to gain a foothold in business, and the desire to understand how they will effect BPM. I actually think that issues with the current state of the art in BPM go deeper – it is just that the emergence of social technologies is bringing them to the forefront, and giving people a common understanding to discuss these changes. I think the real problem is that BPM is becoming too complex and is on its way to becoming even more complex – people are even asking whether BPM is becoming the next programming paradigm, or whether it will be used as a basis to replace all applications in the enterprise.

The are reasons for the complexity, mainly as an attempt to make BPM applicable to more types of business processes. Examples of the increasing complexity are that BPMN has become more complex as a modeling language, vendors are adding rules, complex event processing and process simulators (just take a look at Jim Sinur’s list of the Top Ten BPM Technologies - all valuable stuff, but adding complexity). It seems to me that BPM as a technologyhas moved away from the  business side, and is going deeper into the technology side. I think that this growing complexity is what will eventually stop BPM from growing (Clay Shirky has a great post on why complexity destroys - The Collapse of Complex Business Models) – though I wouldn’t go so far as to claim the complexity will cause BPM to implode, it will just stop its growth.

That is why I am happy that the WfMC positioned Adaptive Case Management (ACM) as separate from BPM - trying to extend the BPMS umbrella to handle unstructured, unpredictabel human processes is a mistake. The two process types are very different, though complementary. They require a different understanding of the world, different tools and a different focus. Just like in Clay’s article the AT&T folks just couldn’t understand the messy world of web hosting, I think many BPMS vendors will find themselves unable to reconcile themselves with the messy world of ACM.

An interesting blog post by Keith Swenson on unpredictable processes got me thinking about the use of a model in BPM. People use the term “to map the process” as a way to describe what is done during process discovery, and as the result of the discovery process. After having thought about it, using the term “map” is misleading, since the result is usually a set of codified directions – not a map.

A map is used to show the lay of the land, and existing obstacles. It doesn’t give direction (or focus on a particular path) – just shows what is out there (for better or worse), at various level of detail. For any specific navigation task, most of what is shown on the map isn’t relevant and it is up the person using the map to find the appropriate path. The more structured the terrain (e.g. an urban area, versus out in the wild) the easier it is to use automation to find a path. But in many circumstances the map doesn’t contain all the relevant details – especially about movable obstacles (e.g. where construction is happening right now, where there is an accident, where the lions are located at this very minute) – so you can’t always rely on the directions. As the terrain becomes less structured – the less detailed the directions that can be given, and navigating the trail relies more on the knowledge and skill of the participant.

Most BPMN models provide something closer to directions (since they don’t map all the terrain, but rather the process as it should be executed), not maps – which is why they work for routine processes, but are inappropriate for unstructured, unpredictable human processes. For unstructured, unpredictable, human work the best you can do is a very high level description (Guidelines, Best Practices, Checklist) – not a detailed model.