Case Management and BPM

Most business functions combine some amount of structured processes with unstructured, ad hoc activities. This white paper examines how concepts of business process management (BPM) and adaptive case management (ACM) can effectively be applied together in order to manage a wide variety of business process types.

The Nature of Work: Exceptions are the New Norm

A key trend in business is the increased focus on knowledge worker productivity. In part because more routine work is becoming completely automated. Keith Swenson, in his book on adaptive case management, Mastering the Unpredictable, defines routine versus knowledge work: Routine work can be analyzed and a common pattern derived. This is not to say that routine work is done mechanically, exactly the same way every time, but rather that there is enough similarity in each instance of it that there is a benefit in identifying a specific, detailed pattern for the work. Because routine work is so repeatable, it can be automated by traditional process automation means. Knowledge work is not routine it does not have the level of repeatability found in routine work. The detailed differences from case to case overwhelm the similarity of different cases: it is not that similarities between cases do not exist, but rather that the differences are greater than the similarities. When it comes to work automation, any advantage gained from similarities is overwhelmed by the additional costs of having to accommodate the differences. Routine work, as his definition states, is about work that is performed the same way every time. You can analyze it ahead of time, work out the pattern or what we would call a process model in business process management (BPM) terms then execute it the same way every time. The key thing here is that executing routine work the same way every time is a good thing: we want it to be standardized and efficient, and theres not much room for creativity in these processes. This covers fully-automated straightthrough processing, but also transaction processing work that involved people in the steps, for example, keying transactions from instructions on a paper document. In 1

order to standardize and automate routine work, it takes some amount of analysis and implementation up front, but the high volume of repeatable processes makes that effort pay off. Knowledge work, on the other hand, doesnt have the same level of predictability as the routine work; instead, the knowledge worker needs to be able to decide what action to take next on a particular piece of work, and when to send it on to someone else. Since the processes dont happen the same way each time, its more difficult to manage them using standard structured BPM methods as with routine work. If you had to map out every possible path that could be taken in this sort of situation, it would take forever to get something implemented, and it would never be complete. In other words, it would be too expensive to even try to do that sort of modeling and implementation for a process that is truly knowledge work. Furthermore, not only is it not possible to remove all of the runtime variation in knowledge work, it may be that variation and the ability to manage it that brings value to the process. Deloitte Development, in a recent white paper entitled Social software for business performance, highlighted this shift from routine to knowledge work: Increasingly, employees encounter non-routine issues which break the standard processes. These exceptions impede operating processes and drag down business performance across all parts of the organization... The current technologies support standard business processes, but fail to support the dynamic informal communications needed for resolving exceptions. Their conclusion: exceptions are not exceptional they are the norm.

BPMS in a Dynamic Environment

Most modern BPM systems (BPMS) have their origins in the management of structured processes, and excel at modeling, automating, executing, measuring and optimizing business processes. Historically, the focus was on standardizing and automating highvolume, repeatable processes: the business equivalent of a factory assembly line. The only agility in these processes was not in the process topology, but in the rules that governed the flow through the a priori model.

An example of a high-volume, repeatable process is that of the data entry portion of processing an insurance application: an application form is received on paper from an external customer, and the information on the form must be keyed in from the form before further processing. There are several steps involved scanning the documents, verifying the quality of the scanned image, entering the data, validating the data entry and workers performing in the tasks in this process have little room for creativity: they are required to perform exactly those steps in exactly that order. The goal of the process is to complete the steps as efficiently and accurately as possible. For repeatable processes, a significant benefit comes from optimizing process performance, in part by modeling the process in advance in order to make it explicit to both business and IT: everyone sees the process model and understands what steps are going to be done in what order. That also provides a basis for monitoring the process, examining how many instances are in each step, or where a particular instance is relative to the process model at a point in time. The model defines everything: what you model is what you execute, but requires complete knowledge of every step in the process in order to implement. This method of BPM works when the number of repeatable process instances justifies the analysis and implementation efforts, such as automated processes or those governed by strict procedural rules. However, many processes dont fit well with a structured process model: there is too much variability, and workers must either use the defined process even though it is not optimal, or perform workarounds outside the BPMS. Traditional BPMS have been applied with excellent results to routine work, but it has been more challenging to adapt these systems to handle knowledge work, where there are dynamic processes, content and rules. This typically results in the requirement for an undefined hold step where the process participant puts the item on hold while they send email or make phone calls in order to resolve the issue at hand. In other words, they step out of the audited and controlled BPM environment in order to do what is necessary in order to achieve the goals of the process. Many BPMS tools are adapting to more effectively handle the unique challenges of knowledge work: more dynamic process definitions, better use of rules and external 3

events, and inclusion of process-related content. And since many processes include aspects of both structured and unstructured processes, many of the systems are allowing these to be combined in a single process, either where a structured process spawns a collaborative case for exception handling, or a dynamic case invokes structured process fragments for standard procedures. In our insurance application example discussed earlier, an application form that could not be processed due to missing information is forwarded to an exception task where a worker could decide what actions to take in order to complete the process, such as contacting the customer to request the missing information. The presence of a less structured task for exception handling doesnt turn the entire process into an unstructured or dynamic process: it just allows for a single point of unstructured work in the context of a structured process. The possible paths through the exception handling tasks are not modeled in advance, since they are relatively unpredictable.

Adaptive Case Management

The deficiencies of conventional BPMS in managing dynamic and unstructured processes led to the rise of a new class of systems, called adaptive case management (ACM) or dynamic BPM. Focused on supporting knowledge workers rather than automation and efficiency, ACM includes a variety of functionality for problem solving rather than transaction processing: The work is centered on a specific situation, or case, and a desired outcome for that case. A case folder provides a persistent container for all tasks, rules, content artifacts and history related to the case resolution. There may be little or no predefined process flow, with the worker defining the flow as the case progresses. The worker may add new tasks at any time during case, either previouslydefined (including structured process snippets) or completely ad hoc. Business rules may constrain the selection of specific tasks, or trigger other tasks and processes based on the user selection of tasks within a case. External events may impact the course of a case, either through automated processing of the events, or user reaction to the events.

Human-focused and content-rich, the goal of ACM is to assist, not replace, human work. There are many business situations where we just dont know the exact steps that need to be taken in order to complete an assignment: we need to get started, then use information that comes up during the process in order to determine which steps to take next. Peter Drucker, the well-known management consultant, coined the term management by objectives to describe how these processes and the people who participate in them need to work: you set the goals, and let the person figure out the best way to do things in order to achieve that goal based on their skills and experience. Case management systems must combine aspects of BPMS, enterprise content management (ECM), business rules and collaboration in order to effectively support knowledge workers, and maintain a solid history of the case in order to allow for auditing and also to provide a reference for workers added partway through the case timeline. For an example of case management, consider an insurance claims process. Unlike the insurance application process discussed earlier, which has a fairly structured process with a few points of unstructured exception handling, claims processing is primarily a dynamic process where the claims worker decides what tasks to perform, and in what order. The claims worker may request information from the customer or other involved parties based on their assessment of the claim, then wait for that information to arrive in order to build up a complete, auditable claim file that supports their final decision. The goal of the process is to resolve the claim, not to perform specific tasks. However, even this dynamic, unstructured case management scenario makes use of structured process fragments in order to complete some tasks: the original claim form and other supporting documents, if they arrive via paper or fax, will go through a structured data entry process before being seen by the claims worker, as will other structured tasks such as processing payments once the claim is resolved. However, the claims worker is unlikely to be performing those structured tasks, but works purely within the adaptive case management environment. Proponents of ACM compare their offerings with a specific definition of BPM that focuses on structured processes, although this is a somewhat unfair comparison: they

are actually comparing conventional BPMS tools based on older workflow and application integration approaches with a dynamic planning approach. There is nothing inherent in the definition of BPM either as a management practice or the tools used to assist it that prevents BPMS tools from including ACM functionality. Ultimately, both BPM and ACM are about managing business processes.

A Spectrum of Capabilities
Routine work and knowledge work are very different in terms of the degree of structure and a priori knowledge, as well as the skills and level of responsibility of the people who actually do the work. In reality, however, few business processes are purely structured or purely dynamic: instead, we see a spectrum of functional requirements between these two endpoints, and a spectrum of capabilities required to assist users in managing these activities. On the structured end of the spectrum are repeatable processes that are mandated by regulations, part of a strict compliance process, or mostly automated. At the adaptive end are processes that are unpredictable, or for which there is so much variation that there is no benefit in modeling all possible permutations; instead, the knowledge worker must select operations based on external events and case content. The goal and focus at either end of the spectrum are different, too: structured processes are typically focused on transactions with the goal of maximizing efficiency, whereas adaptive processes are focused on knowledge with the goal of problem/case resolution. The structured processes are clearly the target of conventional BPM systems, whereas the adaptive processes are better handled by the emerging class of ACM systems. However, the reality of business is rarely that simple: between these two extremes, we see scenarios such as structured processes that require case management for exception handling, and ad hoc processes that require some structured process segments if the knowledge worker includes a task that is governed by specific rules. The earlier examples, of insurance applications and insurance claims handling, showed how a seemingly structured process actually has unstructured steps, and a seemingly dynamic case management situation may include structured subprocesses.

Structured
e.g., regulatory process

Structured with ad hoc exceptions

e.g., financial backoffice transactions

Adaptive with structured snippets

e.g., insurance claims

Adaptive
e.g., investigations

Through the course of their lifecycles, most cases will be handled by a variety of different kinds of workers, some of whose work is very structured, and others whose work is more unstructured, even ad hoc. In order to achieve efficient, consistent case management, organizations need to support the entire gamut of caseworkers whether they are called that or not and the various kinds of work they do to process and resolve a case. And they need to do this in a way that doesnt involve awkward hand-offs that risk losing key pieces of context and case information in the transition. Process may also migrate along this spectrum over time, once some analysis can be performed on running instances of the processes. Applying process discovery and analysis to ad hoc processes may detect patterns that allow some portions of the process to be standardized into structured processes. Alternatively, moving from more to less structured, the analysis of a structured process may show such a high degree of exceptions and workarounds that portions of the process are converted to a more dynamic style.

Summary
Recent discussions that position BPM and ACM as competitive approaches or technologies dont account for the complexity of real-life processes, where many processes include aspects of both routine and knowledge work. Its critical to position 7

an organizations business processes along that spectrum to gain an understanding of what degree of structure and flexibility are required, and thereby be able to select the best approaches for managing those processes.

Biography
Sandy Kemsley is an independent analyst, application architect and blogger, specializing in business process management and Enterprise 2.0. During her career of more than 20 years, she has started and run successful product and service companies, including a desktop workflow and document management product company and a 40-person services firm implementing BPM and e-commerce solutions, and held the position of BPM evangelist for a major BPM vendor. Currently, she practices as a BPM industry analyst and architect, performing engagements for end-user organizations and BPM vendors. She writes the popular Column 2 BPM blog at www.column2.com, is a contributing author on other business and social media-related blogs, and is a featured speaker on BPM and its impact on business.