Case Management Is a Challenging BPMS Use Case

Most business process management suite (BPMS) products do not support a case management workload well and lack the requisite capabilities to coordinate this more-complex use case. Enterprises need to understand the interplay between case management representation and BPMS products.

• In collaborative environments, where knowledge workers work together on a process deliverable, the case management representation is the predominant process representation.
• Case management departs from the traditional view of structured and sequential predefined processes. Instead, workflows are nondeterministic, meaning they have one or more points where different continuations are possible. They are driven more by human decision making and content status than other factors.
• The case management representation cannot be supported by traditional workflow tools. Many BPMS tools only provide basic capabilities to support this case management representation.
• Many of the processes that we consider to be strictly sequential are a combination of structured processes and the case representation.

• When managing or supporting knowledge-worker processes, assess whether the case representation applies by looking at the composition of physical evidence, documents, images, handwritten notes and other process deliverables.
• Check on the case representation capabilities when selecting a BPMS system to automate or support parts of case-handling processes.
• If you want to deploy BPM on an enterprise level, then you need to look into these capabilities in BPMS systems, because you will definitely run into the case management representation.
• Organizations that understand the case management use case will be prepared to enter the next step in BPM — turning to more-complex, collaborative processes and the advanced case representation.

Case management work is collaborative and nondeterministic, meaning it has one or more points where different continuations are possible, and it departs from traditional structured, sequential predefined processes. Case management work depends more on human decision making and content than other processes do.

This tendency presents unique challenges for enterprises when case management is used as a "use case" – an assessment of a system's behavior as it responds to outside requests – for BPMS products. Most BPMS products are designed to manage the state of a single object. Case management, on the other hand, requires simultaneous, event-state change tracking of multiple objects. This research defines a "case" within process management and explains case handling for BPMS.

Scenario: A Process Improvement Initiative at a Tax and Financial Services Company

Consider, for example, a major tax and financial services company that wants to improve the processes surrounding income tax compliance, especially the delivery of tax returns, and provide a solid response to a set of business drivers (see Note 1). The company notes that during the preparation of tax returns, there are a lot of contacts with the client to gather information to prepare the tax package. The tax package includes the tax return, required documentation (depreciation tables, amortization tables, fiscal attestations and board decisions), client letters and such things as summaries, points of attention and tax filing instructions. If issues are to arise during this preparation, then the client will be contacted. Company procedures require the classification of all calls and outgoing e-mail. Furthermore, the company is in frequent contact with tax authorities, and these exchanges are also documented.

Case representation brings all these elements together into one "superstructure." Members of a small team decide how to proceed. After a review, a team leader – with the approval of a senior consultant – decides whether to shelf the unfinished case to gain some time or to move forward. After approval to proceed, the tax package is sent to the manager or senior manager for review. Sometimes, this manager requires the package to be reworked, but most of the time, this is not the case. If the package is accepted, then it travels to the partner responsible for final approval. Often, the tax package will be sent to the client first, simply because the partner is not available to sign the file (sometimes until months later). After the client files, the team assists in the follow-up of the tax return.

This sequence of events highlights how a large and variable amount of information is needed at different times, from different resources, under varying conditions and by different people. Moreover, these constituents have their own processes (predetermined or indeterminate) that need to be consolidated at the case level.

Other common use scenarios are customer support calls, claims, clinical trials, and work in engineering, research and other project environments that are often not thought of as case work, but could benefit from this BPM use case.

The Characteristics of Case Management Representation

Processes
Case management involves hierarchical levels of processes. The highest is the "case level," which describes the process of the case. This process usually has a limited number of statuses:

• Case creation
• Case preparation
• Case review
• Case approval
• Case closure
• Case archival

At a lower level, each case status has a list of deliverables that are predefined and ad hoc. Each deliverable follows its own processes, and the progression of these processes needs to be tracked. The case management team has to reconcile these subprocesses across the deliverables and consolidate them at the case level.

Activities
Activities at the case level or at a subprocess level can be invoked by an activity at a different level. This means that there is no fixed sequence between diverse activities or diverse deliverables. The connections between the activities are preconditions (that is, they are waiting on certain activities or deliverables that have reached a certain status) and post-conditions (deliverables that come close to a certain due date). Structured processes are merely guidelines, not fixed sequences. Often, milestones, such as due dates and percentages of completion, are fixed, but the activities between milestones are ad hoc.

Caseworkers
Participants in casework can be categorized as knowledge workers. They are able to pick a given set of activities to work on, depending on certain conditions and their case assessment. A huge difference in this process flow, as opposed to other use cases, is caseworkers are not consulting a work in-box, where activities are listed in a fixed order. Instead, they have a different interface – a content-driven case in-box. This case in-box shows an overview of pending cases, the status of a case, its different constituents (data, documents and activities), the status of these constituents, people in different roles contributing to the case, the timing constraints on these constituents and, in some instances, predictive analysis. Depending on the needed flexibility, caseworkers can neglect or overrule some of the conditions to start working on a certain case constituent. In some complex case representations, interdependencies between cases and content that is shared among several cases have to be provided in the caseworker interface.

Architectural Consequences
Most BPMS products only factor roles and process instances into the development of a user interface (see Figure 1), and they index databases based on these variables. If an enterprise wants to build a case in-box and people have to go through the entire dataset to find where the case and its constituents are used in and over process instances, then the impact on building the user interface at runtime will be huge. What's needed is a case structure (for example, in a content system) where a company can store the case hierarchy and keep track of the process instances for each of the constituents and the interrelationships. If a BPMS product doesn't have these capabilities out of the box, then the appropriate tables have to be built and maintained by the client organization.

Example of a Caseworker Interface

Source: Singularity

Requirements of the Case Management Representation on BPMS Systems

Many BPMS implementations try to standardize processes so that they can be automated. However, this kind of automation is only relevant in certain, restricted process environments where the heavily structured process does not interact extensively with other processes, and primarily steers and keeps track of the status points of a well-defined single object. In this scenario, objects that clearly show case patterns are erroneously forced into a more deterministic process flow (such as the invoice, the claim, the complaint and other inappropriate areas). Although this kind of automation increases the flexibility of the applications supporting the processes, it decreases the flexibility of the persons engaged in the processes. Their creativity in handling claims and complaints is limited by the supporting workflowlike implementation.

To be able to support the case management use case, a BPMS system should have specific capabilities and traits:

• Support for repeating aspects of the process with capabilities to handle all possible kinds of exceptions related to a case
• Ad hoc documents and document metadata
• Case notes and case metadata
• Agenda management for planning meetings around content
• Ad hoc collaboration among caseworkers
• Capability to dynamically assemble process fragments in real time (late-binding principles) to support the case instead of following predefined process definitions

In addition to support for nondeterminism, case management workload tracks one-to-many and many-to-one states among people and cases and deliverables. This is different from the one-to-one interaction patterns organizations tend to focus on in other process use cases. Also, case management assesses capabilities that combine, on a case level, lots of documents, correspondence, notes, structured and unstructured data, rules, and resources. These require a case identifier on each of these constituents and persistence of the hierarchical structure (see Note 2). As noted, this is a layered process modeling approach where activities on a case level, and probably one level deeper, can be modeled in the traditional way, but where activities per deliverable and per case constituent are modeled in a matrix way (for example, adapted Gantt chart – see Resultmaker, a small Danish BPMS vendor) with due dates per deliverable, and with calendar support for scheduling ad hoc events.

Status of the BPMS Market

Most BPMS vendors are extending their case management capabilities to cope with the basics (content integration, support for indeterminate processes and ad hoc collaboration), but they still have limited functionality to support the full case representation. A couple of them have been offering real case-handling support for years because of their unstructured content-handling roots or because they have experience with this process use case, which was investigated in the 1990s in certain European countries (see Note 3).

Pallas Athena, Singularity, Global 360, Appian and other companies whose BPMS products have their roots in enterprise content management (FileNet and EMC) are examples of companies that have supported the case management process use case for three or more years. Some of the newest BPMS vendors started from a master data management perspective, which provides another excellent way of handling the case management representation. These include Polymita and AuraPortal, which immediately marketed this process use case as one of their strongholds.

If your enterprise matures to the point at which you start managing end-to-end processes, and you want to deploy BPMS products on an enterprise level, then you will run into case management (see Note 4) issues. Assess the BPMS vendors' support for this use case.