For several years now, business process theorists have been concerned with describing the difference between processes that are more-or-less procedural in nature and slow to change and those processes that either change frequently, are very complex and difficult to describe, or both.
A good example of a procedural process that is slow to change is a production line situation where each assembly worker's job is precisely defined.
A good example of a complex, dynamic process is a process that generates proposals for major engineering undertakings. The process begins when the engineering firm receives a request for a bid. Someone at the firm analyzes the request to determine if the firm is even interested in bidding. Assuming the request is something the firm is interested in, a team is assembled to analyze the problem, design a solution and generate a bid. In the course of the project members of the team may send emails to colleagues around the world to find out about problems with similar jobs, to learn more about the needs of the company making the request, and to gather information about technologies that might be used. Similarly, there may be many meetings in which issues are argued out, solutions are discussed or the language of the final proposal is discussed. The proposal, when it is finally prepared and submitted may have characteristics in common with other proposals the engineering firm has submitted in the past, but it is also a unique response to a unique proposal. In other words, the response to the request was treated as a unique case. The approach and activities undertaken were adapted to the unique needs of the client and the skills of the team assembled to generate the proposal. And the entire effort was managed, at least in part, according to unique criteria associated with the specific request.
Historically, consulting firms have always used an approach more-or-less like the one just described. As other organizations offer more options and tailor to customer demands, they have also begun to introduce more flexibility into their processes. Similarly, as organizations rely more on knowledge workers who add value to services by refining them as they interact with customers, process analysts have been challenged to figure out how best to describe and specify improvements for complex, dynamic, knowledge-based processes. A variety of names have been proposed to describe these processes. Case Management has its roots in hospitals and insurance companies where the term reflects the idea that each patient's case needs to be considered as a unique case and that each insurance claim, is, so some extent, a unique case that needs to be carefully examined to determine which rules apply.
Theorists like Keith Harrison-Broninski have been discussing complex, dynamic processes for several years. The Object Management Group (OMG) began to discuss this type of process modeling problem in 2009 and has been using the term Case Management to describe the approach they are trying to define and standardize. I would prefer that they use something a little more descriptive, like "dynamic, complex processes," but can certainly use Case Management if that's what the community settles on.
Adaptive Case Management (ACM) describes an approach for capturing and automating the work that knowledge workers do. In essence, the authors propose a systematic approach for the description and capture of processes undertaken by knowledge workers - processes I would suggest range from a few hundred to a thousand rules.
Mastering the Unpredictable is a book of readings and the contributors include many people who have been involved in the OMG effort. As with any book of this type, some chapters are better than others. Chapters 5, 6 and 7 form the heart of the book and should be read by anyone interested in the future of BPMS and process automation.
The authors often contrast what they are recommending with BPM, which they say begins with and focuses on processes (procedural sequences) In essence, they are contrasting BPMS tools based on Enterprise Application Integration and older workflow approaches and their approach which depends on dynamic planning, "Tasks" ("templates") and rules.
Let's begin with the idea of tasks or templates, as these terms are used by the authors. A "case" is something that you want to accomplish. As the authors are using these terms, a process is a sequence. Each subprocess gets done in a specific order. A "task" is one or more activities that need to be accomplished to complete a case, but its use or its order can't be determined until we know the specific case. Thus, instead of a flow plan, the knowledge worker about to undertake the specific case considers a list of tasks and decides which he or she will use for this specific case, and in what order the tasks will be attempted. In other words, one of the first tasks in the case involved planning the tasks and tentative sequence for the specific case. Note that his places a limitation on automation - ACM applications are designed to support knowledge workers, not replace them. For any given case, only a subset of the tasks may be employed. The structure of the tasks themselves are largely based on the use of rules. The rules used, however, are mostly derived from knowledge workers, however, and not from organization policies.
Stepping back a bit, we are seeing an effort to reestablish some of the concepts used with expert systems development in the 80s. Instead of structuring the approach around a flow (procedural) we are going to structure the approach around knowledge concepts (data structures) and rules - a declarative approach. Our concern, in almost all the examples provided in the book, is not with accomplishing a task, but in reaching a decision or defining a solution. One might suggest that BPMS vendors began with procedural techniques, then begin to add rule-based techniques. Adaptive Case Management suggests how the rule-based techniques might take over and provide developers with tools that make it easier to model and automate knowledge structures and knowledge-based tasks.
This is an important book. It does not provide the kinds of concrete examples one might like, with detailed discussions of how a specific set of cases might be processed, but hopefully that will come in a subsequent volume. What this book does is define the fundamentals that might be used to develop what I think of as rule-based or agile workflow systems.
This is a significant step beyond the more or less independent business rule approaches that have been popular in the last decade and represents a return to knowledge-based techniques that predominated in the Eighties. It is a direct result of some very serious thought about how rule or knowledge-based techniques can be used to help model and automate complex, dynamic processes.
The contrast several authors set up between BPMS and their ACM approach is dramatic, but probably not as significant as they think. Lots of good enterprise work can be done with high-level processes that will be completely compatible with the use of ACM techniques at more detailed levels. ACM is not an alternative, but a set of tools that can be used on one set of problems that process analysts face.
I do not believe the techniques described in this book can be scaled to deal with really complex problems - for the same reason that expert systems failed - because the rule maintenance problems would be too expensive. I do believe, however, that the time is right to apply these techniques to extending BPMS tools for use with processes that include tasks that depend on knowledge. Moreover, as these applications illustrate, the tools only work if there are knowledge workers to plan each case and adjust the tasks and choose among the options offered by the ACM tools. In other words, we are always talking about a Decision Support tool here rather than a fully automated solution. Being stimulated to think about how this integrates with today's popular BPMS applications is worth the price of this book.
I recommend caution, however. This book will help you with cases that involve modest amounts of knowledge. It will not, however, prepare you to tackle the really hard or complex problems that would require thousands of rules. Those problems are still beyond what we can handle in a cost effective manner. You are better to hire a good CEO or a good enterprise architect than to focus on trying to define the processes he or she will use. But for many more modest knowledge-based jobs and processes, the approach recommended by ACM will probably work fine.
I strongly recommend this book. Others will come out with different ways of dealing with knowledge-based processes, but this is a very good start and suggests an approach that will certainly be rapidly developed in the year ahead. This book will not prepare you to build an Adaptive Case Management system, but it will certainly give you lots to think about.
