Another topic came up during the Tweetjam – what are standard use cases for ACM? There were a lot of examples – but twitter being twitter, none were described beyond a few words. I thought this would be a good time to flesh out a pretty popular use case – tracking executive management decisions, especially at the board of directors level. I like this example since it clearly differentiates ACM from BPM – I don’t think even the most diehard BPM evangelists would attempt to use a BPMS to create a board of directors decision management tool.

For example, let’s take a process initiated as a result of a decision taken during a board of directors meeting. In this example the meeting takes place, decisions are made and processes are initiated – but the actual processes executed is different every time, dependent on the context of the board meeting. For example, a bank’s board may be worried about the risk profile of the bank, especially their loans. So they initiate a process regarding the risk management of loans to European real estate and construction projects. In this case, the bank made large loans for the construction of commercial real estate projects in a number of European countries, and those projects have reached a point where they will be asking for additional funding to enable the project’s completion. In the period since the original loans were granted, both the macro and micro economic environment has changed, causing the bank to revisit the original assumptions underlying the loans. These loans now represent large, relatively risky loans and have the possibility of external scrutiny of the handling of those deals – so the board decided to take a closer look. The board requested that the international banking division and the real estate division jointly look into the viability and risk of the projects, taking into account various deal parameters such as the current legal situation of the country involved, the macro economic outlook, the expected amount of financing that will be requested, the financing sources for the projects, the capital structure of the projects, the current viability of the developers. Of course such a deep dive process will generate a lot of activity involving numerous people throughout different divisions in the bank, and experts from outside the bank, the specific participants and information assembled are dependent on the specifics of the loans being examined.

As I stressed in previous posts, for ACM to work – there needs to be a process owner, someone with the responsibility of ensuring the needed work gets done, and the process is driven to completion. In this example, there is a senior executive that owns each part of the process, but it is the corporate secretary’s role to provide oversight, make sure that process is completed in a timely fashion, and the board is briefed on the results. Today, such a process would probably be executed via emails and documents (e.g. spreadsheets) – without any management visibility, and without any IT support for managing the process. Missed handoffs, lost follow-ups and old versions of documents can all conspire to cause the process to fail. An adaptive case management system can ensure that the corporate secretary can provide an appropriate level of oversight and insight into the process – without the need to completely dictate the execution of the process and the work being done. The ability to have the process owners (and the corporate secretary) monitor, track and report on the process without providing so much management as to strangle it, lowers the process risk and increases corporate compliance and governance.

That is main driver behind this use case – risk management. The key to managing risk for unstructured processes is managing the handoffs between participants, managing the documents involved and providing real-time and historical visibility into actual process execution. That is what ACM provides.

Our book, Mastering the Unpredictable has many more real world ACM use cases.

We are currently renovating a house we bought. It is a pretty extensive renovation – adding a second story to the house.  Because it is such an extensive renovation we have an architect, engineer and project manager involved. Here is how I see this ongoing process as a microcosm of the Adaptive Case Management vs. Business Process Management debate:

Step 1 – Getting the plans together and approved by our local council. Essentially this entails plans going back and forth between architect, engineer and finally the local council with lots of conversation and negotiation. This process finally ended with a set of approved plans for the renovation. There is no way this could have been modeled – for example our council is very picky about the type of roof you build, and of course, our original roof plans weren’t appropriate (this isn’t a written rule, just implicit knowledge – since most standard roofs have no issues – we had a specific design problem that required a non-standard roof solution). There is no way anyone involved in the original creation of the plan could have foreseen this, and it caused everything to go off in a new direction – with lots of negotiation and collaboration. So clearly this is an ACM (with the plan as central document, and the architect as the process owner), not BPM process.

Step 2 – planning the actual renovation work.  My project manger put together a pretty comprehensive plan (e.g. model) about how the work should proceed. It was modeled to the best of his ability using the architecture and engineering plans, along with his knowledge of building. I was hoping for BPM like smooth sailing – we would proceed according to the model and everything would fall into place as planned. Boy, was I wrong. The problem was that once the work started, it became clear that the existing structure didn’t exactly fit the existing plans – and there was no way to know until we actually got to work on the house. After about the first 24 hours the original model was almost useless – the facts in the field changed everything. We are now into a mode where we do some work according to plan, find a problem, negotiate and collaborate to find a solution, update the model (aka plan) and continue. Not exactly BPM like. My project manager explained that if we would have razed the existing house, it would have been much smoother sailing and the work would have adhered to the plan – or as I would say it would be more BPM-like.  It would have also been much more expensive.  I think this holds for the process world in general since most BPM process work isn’t about completely new processes, but rather about enhancements and automation of existing processes. So if you have an existing process that lends itself to modeling – then make sure that you start from scratch in defining the new replacement process. If you try and retrofit an existing process you will end up with an exceptional process – in the sense everything is an exception :) – not a BPM process that follows a model.

The ACM Tweetjam was amazing. It was the first Tweetjam I have attended, and it is really an intense experience. Kudos to Keith Swenson (the driving force behind our Mastering the Unpredictable book and my fellow authors for a really thought provoking two hours. My only gripe was that it was a very technical discussion – we need to get more non-technical folks involved – or I worry that we may go down the same path as BPM – starting out as a tool for business people, but ending up as a tool for IT.

I thought I’d pull out the tweets that were related to defining ACM:
chuckwebster: Could someone please define adaptive case management? … in 132 characters (140 – ” #acmjam”) or less #bpm
I think this is a fair question. I  think before we can get to a technical definition (or a list of relevant technologies) we need a high level definition. I believe that there will multiple technical approaches to the problem – especially since it spans such a wide spectrum of use cases. Here my synopsis of partial answers  to this question from the tweetjam:

ActionBase: ACM is a way provide enough structure to knowledge work to make it manageable, but not so much as to strangle it #acmjam
JoshuaWaldman: @ActionBase I like your point. It’s like poetry. Structure upon which to hang the decision which people make. #acmjam
mishodikov: RT @cmooreforrester: nice RT @JoshuaWaldman: @piewords so it’s a people first approach to processes. I dig it. #acmjam
swensonkeith: @cmooreforrester old case mgmt mainly workflow and a case folder: New, ADAPTIVE CM includes better process and BI #acmjam
neilwd: A thought experiment re: tools reqts etc for #acm – how & where different from project management? #acmjam
juliebhunt: RT @cmooreforrester: #forrester thinks 3 kinds of ACM use cases will emerge: investigations, incident mgmt & service requests #acmjam #bpm #emc
ActionBase: @passion4process ACM is the way to manage the intelligent anarchy that is knowledge work #acmjam
frankkraft: RT @passion4process: We moved from top-down BPR, to collaborative BPM, to controlled anarchy ACM… #acmjam .. controlled anarchy!!
cmooreforrester: I think it’s about organizing chaos & letting smart people add value RT @charoy: #acmjam is it about organising chaos or controling chaos?
maxjpucher: @passion4process ACM is not anarchy – iit is EMPOWERMENT! Authority, Gaols and Means! Social is not empowerment! #acmjam
SingularityBPM: managing the unpredictable! http://bit.ly/abtnmD RT @cmooreforrester: it’s abt organizing chaos, letting smart ppl add value #acmjam @charoy
SingularityBPM: ACM is for knowledge workers what process automation was for task workers RT @cmooreforrester: … case benefits r hard to quantify #acmjam

This turned out longer list than I expected. As you can see it was a very dynamic interchange. One overarching theme that didn’t come out from these direct tweets is that ACM is for managing knowledge work. I’ll address that in another post.

I read an interesting article in the McKinsey Quarterly (free registration is required) on “Five ways CFOs can make cost cuts stick“. From my perspective most interesting part is the graph that shows that while cost of goods sold (COGS) has gone down 2.7% over the last decade, sales, general and administrative (SG&A) costs haven’t budged.

A lot of things go into SG&A (like travel and offices), but for most companies the bulk of SG&A is in compensation, or people costs. I think that explains the lack of progress in the area – most SG&A type work is knowledge work (or call it it office work if you like) and there have been very few effective widespread productivity enhancers for this type of work in the last decade.

I believe that to bring real, widespread productivity gains to this type of work – we will need a combined process+collaboration perspective focused on knowledge worker productivity. The key will be to bring transparency to knowledge work – and just enough control to manage the process, but no such much as to strangle it. The article alludes to the need for transparency in the article and Jim McGee has an excellent post on the need for transparency - “Managing the visibility of knowledge work“. Solving the problem also needs collaboration within the process context as John Tropea discusses in his latest blog on “Have we been doing Enterprise 2.0 in reverse : Socialising processes and Adaptive Case Management“ . 

I am hoping that Adaptive Case Management will be the begining a real focus on this issue. Maybe this can be the decade that we really start lowering SG&A cost by enhancing knowledge worker productivity.

A reminder – we will be having a tweetjam on Adaptive Case Management on July 15 at 12pm EDT, to find out more click here.

I often get asked how ActionBase relates to Business Process Management Suites (BPMS). From my perspective the simplest answer is that we focus on unstructured, unpredictable, ad-hoc human processes that knowledge workers do, while BPM suites focus on structured, predictable processes – and the two approaches are complementary. Adaptive Case Management (ACM) has been very useful in helping people understand that structured processes and unpredictable processes really do need to be thought (and handled) about differently.

Usually once we get past that hurdle the next question is what is unique about our approach to managing knowledge worker processes.  After having tried various explanations here is what I have come up with:

Familiar- email and documents are the way most ACM processes are handled today by most people. Most other approaches (e.g. wiki based approaches) want people to trade in their familiar tools (i.e. Outlook and Office) for new tools tailored more to this usage. I think the “rip and replace” approach to managing these processes just won’t work, since managing these processes make up the bulk of what knowledge workers do. Using a new tool (instead of Outlook and Office, or their equivalents) for executing these processes is almost equivalent to replacing email in general – and that just isn’t going to happen any time soon. If we really want to put this ability in the hands of the business people, we should leverage technical metaphors they already use and are comfortable with.

Collaborative -unstructured, unpredictable, ad-hoc, human processes need a lot of collaboration (i.e. negotiation, discussion) between the participants in the process. Today most tools take either process centric, or collaboration centric - knowledge work needs both equally. We leverage and enhance email to enable it to be a collaborative environment for knowledge process execution and management.

Managed – to manage these processes the trick is to apply enough structure to make the process manageable, but no so much as to strangle it. Our approach to management is that we don’t dictate the flow (though we can suggest a best practice), but rather focus on visibility. By providing the process owner and process participants visibility into the process as it unfolds – we provide them with the information they need to manage the process. By storing all ofthe information about these processes in an “system-of-record” we allow the organization gain understanding and insight into these emergent processes.

There have been a growing number of conversations on the web around the differences between business process management (BPM) and adaptive case management(ACM) – for example here.  A lot of those conversations end up discussing the definition of BPM, and whether BPM Suites (the BPM tools, not the discipline) can actually handle ad-hoc, unpredictable human processes or not.

I don’t think we’ll ever find a definition of BPM (the discipline, not the tool) that everyone will agree upon. Just for argument’s sake I’d like to use the definition – “BPM is discipline of making work processes simpler”.  I know it isn’t a perfect definition – but using it does have interesting implications. 

• What is a work process? Well, I think that is intuitively simple – those are the processes used to generate the work products required by the business. A more rigorous definition could be nice, but at least for me – that is good enough.
• What make a process simple? Well first off, it has to be correct (i.e if the process doesn’t generate the required work product, then it may be simple – but the “null” case of simple doesn’t matter). So beyond correctness – what makes a process simple? I think that is a very hard question – but I found a nice set of ten “Laws of Simplicity” that I think are interesting to think about in this context (see John Maeda’s Laws of Simplicity).

1. The simplest way to achieve simplicity is through thoughtful reduction.
2. Organization makes a system of many appear fewer.
3. Savings in time feel like simplicity.
4. Knowledge makes everything simpler.
5. Simplicity and complexity need each other.
6. What lies in the periphery of simplicity is definitely not peripheral.
7. More emotions are better than less.
8. In simplicity we trust.
9. Some things can never be made simple.
10. Simplicity is about subtracting the obvious, and adding the meaningful.

I think the first four laws sum up a lot of how BPM makes a process simpler and what the modelling stage of BPM is about. As complex as models are, they are simplifying metaphor used by BPM practitioners. The model is BPM’s expression of law 4, the model is the knowledge about the process, and that knowledge is what enables the process to be made simpler.

I see  lot of the arguments between BPM and ACM around Laws 5,6 and 9 – about whether it is even possible to apply the BPM simplicity metaphors to certain processes. Applying laws 5,6 and 9 is a lot of where the line between BPM and BPMS blur. Models can mean lots of things – it can be as rigorous as a BPMN model or as loose as guidelines and checklists – almost every BPMS leans towards rigorous BPMN models. ACM proponents believe that there are a whole set of processes that can not be simplified using the basic BPM simplification tool, the rigorous model.

Law 7 is why I think Google Wave is an interesting paradigm for BPM – it focuses on discussions and conversations, things that get people involved and participating. The Social BPM movement is a step in this direction – but only for a very specific process, the process of creating a model.  These is nothing special about modelling – there are many other processes like it that would benefit from the appropriate tools. Also, BPMS would be better off if they started to account for Law 7 (though it sort of is “anti-techie”) and focusing as much effort on the end user experience as the process models. People use tools that they like and  that empower them – that is true both in a consumer and business settings.

As BPM has evolved a technical platform to support more and more process types – the tools have already become quite complex – and now vendors are adding rules and events. I think ACM is partly a backlash to that complexity - trying address Law 8 by limiting the scope of BPMS (though sometimes I think that Law 8 is just not appropriate for technical tools – technical people love complexity and features when it comes to their tools, the problem is when they think everyone feels that way too).

Finally Law 10 – This is an interesting law from a BPM perspective – isn’t BPM about exposing and codifying the routine (which is version of the obvious)? So maybe BPM’s job is to lay the groundwork so we can get to Law 10 in business processes, and something else will need to come along enabling the next step towards Law 10.

(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”.