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