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.

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.

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

“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.