• Don’t try to structure every process. Most of the world’s business processes are currently unstructured and executed using email and documents. Many of these just can’t be structured. Even though more and more processes will get structured over time, an even greater number of unstructured processes will be continue to be created.

Recognizing a greater power that can give strength;

• The reason that there are so many unstructured processes is because in the world of knowledge work, that is how people get things done. Don’t try to structure processes that are inherently unstructured – you’ll fail. Here are some basic questions to help ascertain whether your process can be structured or not:
  • Does the process have a lot of ad-hoc, unpredictable activity associated with it (i.e does it change each time it is executed)?
  • Are there a lot of exceptions associated with process?
  • Is the process a people process that is heavily dependent on the skill and knowledge of the participants –do they need to be in charge of the flow? Is negotiation and discussion between participants a major part of the process?
  • Does the process require investigation and research?
  • Is the process generating and gathering (for the most part) unstructured data and content (i.e. documents)?
  • Does the process flow change based on the accumulated documents and content?

Examining past errors with the help of a sponsor (experienced member);  

• Get an adaptive case management (ACM) mentor (come join us at the ACM mentor camp on Sept 17) and learn to ask some basic questions about your processes and their structure.

Making amends for these errors;

• Take a look at your processes from a new angle – maybe they should remain unstructured, and you need to provide just enough of a framework to make them manageable, but not so much as to strangle them. Maybe there is a reason people stick to email and documents for certain processes.

Learning to live a new life with a new code of behavior;

• Don’t think every process should be modeled.  Maybe your process can’t be rigorously modeled. Maybe the structure will emerge over time, or maybe never. Maybe tracking and monitoring can take place of control and rigorous modeling. Maybe “trust but verify” works better than “lock it down”. Maybe a BPMS and BPMN just aren’t the right tools. Think about the social and human aspects of your process and process participants (and the process experience).

Helping others that suffer from the same addictions or compulsions

• Help spread the word in the process community. There are structured processes – which is where BPMS excel. Unstructured, unpredictable human processes – they exist, and aren’t just “processes that haven’t yet been structured” – that is where ACM can help.

This aspect of ACM  vs. BPM isn’t mentioned much. Maybe because most of the people in the discussion are from a techical background. From my experience, when people collaborate – they negotiate, which is natural part of the give and take of getting the job done. Negotiation and discussion may be the most important part of the whole process – and certainly key to understanding why the flow of a specific instance of unpredictable process emerged as it did. Emergent processes emerge just as much by EQ as by IQ.

A key aspect of ACM is managing and supporting negotiation. How does ACM link the negotiations and discussions back to the goals of case? Negotiation and discussion are a first class part of any knowledge process, and need to be supported, managed and integrated into the process flow. 

ACM needs to support EQ just as much as IQ .

I think that if Google would have built Wave into an enterprise extension of Gmail, and provided the features needed by the enterprise – they would have had a winning combination. I have written about this in the past in my blog (http://blog.actionbase.com/does-google-wave-docverse-adaptive-case-management-by-google, http://blog.actionbase.com/can-google-wave-become-a-disruptive-good-enough-bpms) and in articles http://www.information-management.com/newsletters/enterprise_collaboration_tool_technology_email-10016792-1.html. Of course they would have also needed to move away from an advertising based model, to a more standard fee based enterprise software pricing model. So all those taken together (especially the enterprise business model part) is my guess why Wave was pulled from the market.

As the Adaptive Case Management (ACM) discussion is maturing, and the community is starting to define what is needed by an ACM system – I still think that Google Wave, Google Docs and Docverse could have been pulled together in such a way that it would have made a real impact on the business process management (BPM) market.  Those Google tools, integrated into Gmail – along with a robust reporting and analytics would have been a real game changer in the ACM market – especially for mid-size enterprises. Google had all the pieces, they just needed to pull them together – and the will to really enter the enterprise market.

I am sorry to see Google Wave depart, especially since they didn’t even try to enter the enterprise market.  It could have turned the business process management market on its head.

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

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)

• 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?

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