xCP Pattern Library 3.3

xCP Pattern Library v3.3

EMC Corporation Corporate Headquarters:

Hopkinton, MA 01748–9103 1–508–435–1000

www.EMC.com

xCP Pattern Library 2

TABLE OF CONTENTS

1 EXECUTIVE SUMMARY ............................................................................................... 3

2 BASIC CONCEPTS ....................................................................................................... 5

3 INITIATE CASE ........................................................................................................... 11

4 MANAGE ..................................................................................................................... 18

5 REVIEW ...................................................................................................................... 30

6 COMMUNICATE .......................................................................................................... 39

7 CLOSE CASE ............................................................................................................. 50

8 CASE POLICIES ......................................................................................................... 54

9 DATA MODEL ............................................................................................................. 66

10 EXTERNAL INTERFACES ...................................................................................... 74

11 MONITORING .......................................................................................................... 83

Executive Summary


1 Executive Summary xCP is a case-based offering built on the Documentum platform. It accelerates solution development with pre-built, reusable components. These components are configured and assembled according to defined patterns. The Pattern Library documents these patterns so that they can be easily used by anyone.

Patterns have been used for object-oriented software design since the 1996 publication of the seminal book Design Patterns. We expand the notion of patterns to include requirements definition as well as design.

The xCP Pattern Library is a major contributing factor to the success of an xCP implementation. In addition to suggesting new ideas for solutions, the Pattern Library reduces the time and risk of an implementation by providing design alternatives and documenting best practices.

1.1 Audience This document is intended for EMC partners and consultants who are responsible for designing and building case-based applications. Specifically, it addresses the following roles:

• Solution Architects

• Business Managers

• Development Managers and Developers

• Project Managers

The Pattern Library may also be helpful to pre-sales for answering RFIs, and for creating demonstrations and proofs of concept that address customers’ business needs.

1.2 Approach The xCP Pattern Library is based on the observation that case-based applications are composed using a set of common patterns. The xCP Pattern Library provides a structured, scientific way to plan, design and implement case-based applications.

Business-level patterns are called solution patterns, while technical-level patterns are called design patterns. A solution pattern defines a functional requirement. A design pattern describes a method (or “recipe”) of implementation. Both pattern types are organized into logical categories that facilitate their use. Each solution pattern is mapped to a set of design patterns. This two-tiered approach makes it easier to define solution requirements and ensure traceability of implementation decisions to requirements.

1.3 Using the Pattern Library The Pattern Library, together with design patterns and mappings, is available on the EMC Developer Network (EDN). A full methodology describing how to use these patterns is

Executive Summary


important, but outside the scope of this document. The following are a few methodological suggestions.

Step 1: Working with the client, the business architect defines the business requirements for the case lifecycle. This can be accomplished using solution patterns to articulate potential requirements. For example, there are several alternative solution patterns for initiating a case. A requirements review with the client should then be held.

Step 2: The solution architect translates these requirements into an overall design for the system. This requires detailed definition of data modelling, case policies, external interfaces and monitoring. The design proceeds through a series of iterations. For example, a preliminary case data model is defined early in the project, but the data model cannot be completed until the data design is fleshed out. The solution architect identifies the appropriate design pattern for each solution pattern and documents the reasons for these design patterns. The solution architect then holds a design review.

Step 3: Implementation. The development manager assigns the selected design patterns to individual developers for implementation. Each developer must understand how the design patterns relate to the original business requirements, as reflected in the solution patterns. System testers verify that the implementation actually meets these business requirements.

1.4 Document Overview Chapter 2 explains the basic concepts underlying solution patterns and design patterns. Each subsequent chapter focuses on one category of solution patterns, presenting the context, business value, approach, method, and possible variations for each solution pattern. For example, Chapter 3 addresses Case Initiation, which includes four different solution patterns. The rest of the chapters address each of the remaining categories: Manage, Review, Communicate, Close Case, Data Model, External Interfaces, and Monitoring.

1.5 Benefits Benefits of the Pattern Library include:

• defining business requirements more quickly and precisely

• enabling business executives and stakeholders to understand, influence, and communicate what is being developed and why

• reducing time for application design

• reducing development and testing time

• improving the quality of the solution delivered to the customer

• reducing overall project risk

• providing a standardized approach to xCP case-based implementations

Basic Concepts


2 Basic Concepts

2.1 Case-Based Applications Businesses and governmental agencies often make decisions and take action in the context of a case. A case is a pattern of work with the following characteristics:

• an event that initiates the case

• a set of case information (structured and unstructured)

• processes for managing information flow, human decisions, and system interactions

• a case outcome, deliverable, or decision

One example of a case is an insurance claim. A case is triggered when a customer files a claim for damage to his car. The case information comprises the forms, photographs of the damaged car, and the body shop estimate. The case worker makes sure that all documents are in order and that work estimates are appropriate. The outcome is the payment for the damage.

2.2 The History of Patterns The idea of patterns was introduced for city planning by Christopher Alexander1

A typical pattern approach allows great flexibility and variations (for example, highways are planned with three-leaf and four-leaf interchanges).

. He believed that buildings and towns should reflect the daily life of the people who live and work there. His idea was to look for recurring patterns of use and then identify essential design elements that address those needs. For example, in highway design, a cloverleaf pattern is often used because it solves a common problem of getting on and off the road.

Patterns were introduced into software design by Gamma, Helm, Johnson, and Vlissedes in their book Design Patterns published in 1996. It showed that object-oriented software applications can be constructed by using recurring patterns such as the factory pattern, the facade pattern, and the observer pattern. As they say in the introduction, “Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context.”

The authors organized their design patterns into three major categories: creational patterns, structural patterns, and behavioural patterns. In their treatment, each of these patterns has four essential elements:

• Pattern Name

• Problem

1 See for example “A Timeless Way of Building” or “A Pattern Language” (1977)

Basic Concepts


• Solution

• Consequences

EMC has taken a similar approach in the xCP Pattern Library.

2.3 Structure of the Pattern Library The xCP Pattern Library is a collection of patterns that reduce a complex application to a series of smaller decisions. The underlying premise of the Pattern Library is that decisions need to be made at two levels:

• business requirements level (solution patterns)

• technical design level (design patterns)

Technical decisions must be driven by the decisions at the business level.

2.3.1 Approach

At a high level, the approach is as follows:

1. Divide the application into high-level functional modules (called solution pattern categories)

2. Reduce each of these categories to a set of solution patterns, which are patterns at the business level

3. Map each solution pattern to a set of one or more design patterns, which address the technical implementation

It is important to emphasize that design patterns are defined at the technical level while solution patterns are defined at the business level.

2.3.2 Solution pattern categories

Solution patterns are grouped into a series of categories. The categories are organized as follows:

1. Foundation categories. These are fundamental to the design of any case-based application and determine its global behavior. This includes two categories: Data Model and the Case Policies.

2. Lifecycle categories. These are visible in the active, ongoing case. This includes five categories: Initiate Case, Manage, Review, Communicate, and Close Case2

2 The lifecycle categories consist of functions, not processes. A single activity in a case can incorporate functions from the Manage, Review, and Communicate categories. Or a case can interleave activities from all three categories. There is no fixed activity order implied by these categories, except that Case Initiation comes at the beginning and Case Closure at the end.

.

Basic Concepts


3. Extension categories. These are optional but in practice can provide extreme value. This includes two categories: External Interfaces and Monitoring.

The complete set of categories is illustrated in the following figure.

Figure 2–1 Solution Pattern Categories

Each Solution Pattern Category is described in terms of:

• Category Overview

• Approach, including key questions to consider

• List of solution patterns in the category

2.3.3 Solution patterns Each Solution Pattern consists of a set of closely-related business functions. An example of a Solution Pattern is “Monitor Case Instances,” which occurs in the Monitoring category. This is shown in the following diagram:

Figure 2–2 Solution patterns in the Monitoring category

Review

Communicate

ManageInitiateCase

Close Case

Case Policies

External Interfaces

MonitoringData Model

Solution Pattern 1 Current Activity Monitoring

Solution Pattern 2 Historical Reports

Solution Pattern 3 Managing by Exception

Solution Pattern 4 PublishingMonitoring

Basic Concepts


Each Solution Pattern is described in the following way:

• Context: Short description of where and how the pattern is used

• Business Value: The value to the business that the Solution Pattern creates

• Approach: Brief overview of how the solution pattern works

• Method: Step-by-step instructions for defining the Solution Pattern in an actual project

• Variations: Suggested alternatives, enhancements, or extensions

2.4 Design patterns A solution pattern is implemented by a set of design patterns. An example of a design pattern is Process Initiation by DQL Query, which is linked to the solution pattern Initiate Process, which occurs in the Case Initiation category.

Each design pattern includes the following information:

• Context

• Description

• Prerequisites

• Solution

• Consequences

• Examples of use

• Related patterns

• Attachments

2.4.1 Design pattern categories

Just as solution patterns are grouped into categories based on business function, design patterns are grouped into categories based on technical implementation. The set of design pattern categories is shown in the following diagram:

Basic Concepts


Figure 2-3: Design pattern categories

This allows developers to investigate and learn about patterns from the bottom up. For example, a developer who is building user interfaces might go directly to the User Interaction category and review the user interface patterns. Design pattern categories allow developers to focus on their areas of expertise.

2.5 Mapping solution patterns to design patterns Each solution pattern can be mapped to one or more design patterns. This helps developers implement solution requirements. In the example is below, a solution pattern is linked to two design patterns:

Figure 2-4: Mapping a solution pattern to design patterns

Note that the design patterns can occur in multiple design pattern categories.

To be specific, map the solution pattern “Initiate Process” to the design pattern “Initiate process from document received via SMTP,” as follows.

User Interaction

Look & Feel

Process

Activity Integration

Invocation/Initiation

DataStructures

User-Oriented Process-Oriented Data-Oriented Operational

Administra-tion

SolutionPattern

DesignPattern

Solution Pattern Category

Design Pattern Category 2Design Pattern Category 1

DesignPattern

Basic Concepts


Figure 2-5: Mapping a solution pattern to a design pattern

The mapping means that this particular design pattern is used in the implementation of the requirement as defined by the solution pattern. This solution pattern is part of the solution pattern category “Initiate Case.” The design pattern is part of the design pattern category “Initiate/Invoke.”

Every design pattern falls into one of the design pattern categories. However, it is not necessary that every design pattern have a mapping from the solution patterns. Some Design patterns are generic and can apply across multiple solution patterns. For example, the same user interaction design pattern might recur in the Manage, Review, and Close Case categories.

Initiate Process

Initiate process from document received via SMTP

Initiate Case


3 Initiate Case

3.1 Overview The lifecycle of a case begins with initiation. In order for a case to become a case, it must execute a series of steps that ensure that it is valid and meets the prerequisite criteria. Upon passing that validation, another series of steps prepares the case for the next phase in its lifecycle: case work. Case work consists of three solution pattern categories: Manage, Review, and Communicate.

3.2 Approach A case is controlled by a process or series of processes. A process is invoked by a user performing an action or by an external event. (It is important to note that these process initiation patterns can be reused in other solution pattern categories). After invocation, the initiation request is validated against defined guidelines. If successful, the case is set up and enters the case work lifecycle phase.

When implementing a case initiation pattern, consider the following:

What mechanisms are available to invoke a process to begin case initiation?

Examples of trigger mechanisms include:

• a person completes and submits a form

• a person sends an email

• an external system event updates a database field

What constitutes a valid submission?

Examples of validation rules include:

• the submitted form must contain all required fields

• all fields have values within defined ranges

• the request must be submitted within the specified dates of eligibility

Are there criteria that will cause case initiation to fail?

Examples of automatic disqualification criteria include:

• the contact information provided by the requestor is invalid

• this case is a duplicate of another case

• the external system that submitted the request is unauthorized

If validation succeeds, are there mandatory data that must exist before the case can move to the case work lifecycle phase?

Basic Concepts


Examples of system-generated supporting data include:

• case must be assigned a unique ID

• folder hierarchy must be created and assigned to the case

• document templates must be copied to the case

• checklists for the case worker must be generated to guide their work

Is a reply to the requestor needed to acknowledge receipt of the request?

Examples of acknowledgment include:

• sending an email to the person who submitted the request

• sending a message to the system that submitted the request, passing on the unique case ID

An Example from Grants Management:

An applicant for a grant submits a request form. A grants manager collects supporting documentation in preparation for a review.

• What mechanisms initiate the case?

The grant applicant submits the request by completing an application form and submitting it electronically via a variety of protocols.

• What constitutes a valid submission?

In addition to a completed submission form, the grant applicant must apply within the eligibility window of January 1st to April 31st.

• Are there any criteria that would automatically cause case initiation to fail?

If the grant applicant is from a country that is a state sponsor of terrorism, the request is rejected automatically and the case is not initiated.

• If validation succeeds, are there mandatory data which must exist before the case can enter the case work lifecycle state?

The case must be assigned a unique identifier, and a folder structure must be created and attached to the case to store supporting documentation and data for the case.

• Is a reply to the requestor needed to acknowledge receipt of the request?

The requestor must receive an email acknowledging their request.

3.3 Solution patterns in this category There are 4 solution patterns within this category:

1. Initiate Process

Basic Concepts


2. Validate Case

3. Set Up Case

4. Accept Case

The solution pattern “Validate Case” is automatic – it is performed by the system. “Accept Case” refers to human-level validation and acceptance of the case. Some setup might be required before Accept Case and can occur in Set Up Case. (For example, assigning user roles to the case is part of setup, but it would not make sense to assign user roles if the case were not accepted.)

3.4 Solution pattern 1: Initiate Process

3.4.1 Context

An external event (whether triggered by a human action, another system, or another process) provides the signal to initiate a case. This solution pattern generalizes slightly from “Initiate Case” to “Initiate Process,” since this general pattern recurs throughout the lifecycle of a case.

3.4.2 Business Value

The electronic capture of requests, supporting a variety of methods and protocols, gives businesses maximum flexibility to support their clients, customers, partners, and associates.

3.4.3 Approach

Identify the conditions, data, and mechanisms by which a person or system can establish a case.

3.4.4 Method 1. Determine if there are preconditions for initiation. For example, to submit an

automobile claims form, it is assumed that some damage to the car has occurred.

2. Identify the required case data for each type of initiation. What is the minimal information that the case worker needs to begin working on a case?

3. Identify the mechanisms or protocols used to submit the case data. Is this done by a human submitting a form? How should that form be submitted? Will an external system event generate the case data? Will it be a combination of both?

4. Process the incoming request and launch a Validate Case instance.

5. Define the different types of case initiation failure that can occur and how each is handled.

3.4.5 Variations

• Log all initiation attempts and identify those that were successful and unsuccessful.

Basic Concepts


• Some types of cases will be assigned case numbers at this point, while other types will be assigned case numbers only after validation and acceptance are complete

Basic Concepts


3.5 Solution pattern 2: Validate Case

3.5.1 Context

After process initiation completes successfully, the submission will often require validation before becoming an official case. This can sometimes be done automatically, by a system process. However, in many circumstances a manual review task will also be needed.


Case workers avoid wasting valuable time if the system can detect and reject extraneous, fraudulent, or mistaken case initiations.

3.5.3 Approach

Define the minimum qualified data and criteria for case initiation to complete successfully. Decide whether case validation is performed entirely by the system, or by a combination of system and human action.

3.5.4 Method 1. Assemble all required submission data.

2. Identify criteria for validating the case.

3. Apply these criteria to the incoming request.

4. Perform human tasks, if needed, to complete screening.

5. Take appropriate action if the validation fails.

3.5.5 Variations

• Consider a two-tier validation in which a preliminary step is performed by the system based on business rules, followed by a brief screening by a case worker.

• Send an email to the initiator if the validation fails. Provide some explanation for the reason it failed.

Basic Concepts


3.6 Solution pattern 3: Set Up Case

3.6.1 Context

A case request is submitted and validated. Before case work begins, however, certain basic setup activities must be completed.


Reduce the manual effort of case workers by automatically creating case data and acknowledging cases before they reach the case worker’s desk.

3.6.3 Approach

Assemble all data required to begin case work automatically by means of a system process. Assign an identifier to the case. Initiate communication to the person or system that requested the case.

3.6.4 Method 1. Identify the folder hierarchy needed to support case processing.

2. Assign a unique case identifier to the case. This identifier is needed to coordinate case-related activities across multiple users and processes.

3. Identify case data that can be created automatically, without human intervention.

4. Map any data received in the initiation to the case (for example, if the submitter fills out a web form).

5. Import all documents submitted to the case (for example, if the submitter files a document required to open the case).

6. Assign the case to an appropriate case manager (See the solution pattern category “Case Policies” for details on how this is done).

3.6.5 Variations

• Based on business rules, send an automatic notification to the manager of this case. For example, if a request is received from a government regulatory agency, notify the department manager.

Basic Concepts


3.7 Solution pattern 4: Accept Case

3.7.1 Context

In many business environments, a case must be reviewed by a human being to determine that it is complete and accurate.


This allows human judgment to be incorporated into the decision to move forward or reject a case. For example, in court case management, a court clerk needs to review the filing information to ensure it is complete and accurate. This decision cannot be automated.

3.7.3 Approach

Use a utility process to automatically assemble all data required to begin the case. Assign an identifier to the case. Initiate communication to the person or system that requested the case.

3.7.4 Method 1. Create an acceptance task and send it to the appropriate decision maker.

2. Ensure that all required information about the case request is available and easily accessible.

3. Enable the user to make a decision, typically by pressing a button.

4. If necessary, allow the user to add comments explaining the reason if the case is not accepted.

3.7.5 Variations

• Reject case. How will this be handled? One approach is to delete the case request and associated information. A better approach is often to archive case related information.

Manage


4 Manage

4.1 Category Overview The Case Initiation category brings information from the outside world into the case. This includes both structured data and unstructured content (documents, images, audio files, etc.) In the Manage category, the case worker must be able to view, create, or update the information. With this information, the case worker takes appropriate actions, such as requesting more information, sending the case for review, or making decisions on the case. Often these actions are then followed by Review or Communicate functions.

Figure 4-1 “Manage” in relation to other Solution Pattern Categories

The three solution patterns: Manage, Review, and Communicate constitute the “case work” functions. They can occur in any order and can be iterated as necessary.

4.2 Approach To manage a case, a case worker makes sure that it contains all required information, progresses properly, and accomplishes its goal. This involves producing and consuming case information, taking actions, and making decisions.

When implementing a case management pattern, consider the following:

Who manages the case? The case needs to be sent to a case worker to handle the details. For example, in a typical insurance claims case, a case worker will be assigned to the case based on a phone call from a claimant. In some cases, it might be necessary to assign multiple case workers, or refer it to a supervisor for additional decision making.

How does the case worker find case information? Case workers need to view information about the case. Ideally, the required case information is displayed on their

Manage

Review

Communicate

InitiateCase

Case Work

Manage


screen in a way that is clear and easy to navigate. Often they will need to search for documents related to the case or to examine related cases. For example, the claims worker might want to find and inspect previous automobile claims made by the claimant.

How does the case worker manage case data? Every case contains structured data describing the details of the case. For example, for an insurance claim, the case worker needs to have the name and policy details for the claimant and the description of the damage. As further information is received about the extent of the damage, the case worker may be required to enter or change this data.

How does the case worker manage documents associated with the case? A case may contain a variety of documents, images, or video files. For example, the case worker might receive a digital photograph of the damaged car that must be kept in the virtual case folder.

What actions can the case worker perform and when? Case workers can initiate actions, such as asking for more information or requesting a review. For example, the claims worker may decide to approve the automobile claim. The actions that a case worker can perform often depend on the state of the case: for example, the ability to import a certain type of document might be enabled in one phase of the case but not in another.

4.3 Solution patterns in this category

The Manage category includes the following solution patterns:

1. View Case

2. Manage Case Data

3. Manage Case Content

4. Find Case Information

5. Perform Case Actions

Manage


4.4 Solution pattern 1: View Case

4.4.1 Context

The case worker needs to view the case in order to review case status, data, documents, and actions. This view is especially important in the non-task-oriented cases, as work is done in a “case command center” that is independent of tasks.


The ability to view the case is the most fundamental capability of case management. A well-designed desktop can improve efficiency and help a case worker to resolve cases quickly.

4.4.3 Approach

A good example of a case view (a “folder view”) is shown below.

Figure 4-2 Case Command Center

Notice the following features:

1. User can browse through a set of folders related to the case.

2. User can access business logs and calendars, as well as documents.

Manage


3. User can enter and view other case metadata (shown on right).

4. The interface includes a set of action buttons, which depend on the case state. For example, if the case worker makes a telephone call, she can press the Record Call button to enter the details of the call.

4.4.4 Method 1. Display all relevant folders (for example in a tree structure, as shown in the left).

2. Provide relevant case metadata that can be entered, viewed, and changed.

3. Identify required actions for the case worker and implement them as action buttons.

4.4.5 Variations • Perform a validity check on data entered in a form.

• Make some fields mandatory and others optional.

• Create conditional fields, in which the fields that are displayed in a form depend on data entered (either in the same form or in other forms).

Manage


4.5 Solution Pattern 2: Manage Case Data

4.5.1 Context

This solution pattern addresses the creation and modification (and occasionally the deletion) of case data (that is, information about people, objects, or events in the case).


Case data describes and summarizes information about people, forms, business objects, and events that are important to the case. For example, in a loan application, case data might include the name of the person applying for the loan, the account number, the amount requested, and evidence of the ability to repay the loan. Decisions are ultimately based on case data, such as whether to approve or reject the loan application.

4.5.3 Approach

Case data is presented to the user via forms (organized collections of data fields). Data is automatically populated in the form and case performers can enter it manually. Performers can view the data and update it as needed.

Figure 4-3 Data fields in a form

4.5.4 Method 1. Identify data that is relevant for the case (see the Case Modeling category).

2. Decide on the presentation format for the data (for example, text field, drop down, check box).

3. Identify the case workers who need to work on the data and in which activities.

4. Group data fields together into forms if they are logically related.

5. Show or hide different data fields for each task and case worker (In some tasks, the data will be invisible, in other tasks it will be grayed out). Display only the relevant

Manage


information in each task: irrelevant data distracts from the work that must be done, and some data should not be shown for case policy reasons.

4.5.5 Variations

• Perform a validity check on data entered in a form.

• Make some fields mandatory and others optional.

• Create conditional fields, in which the fields displayed in one form depend on other forms or affects fields in the same form.

Manage


Solution pattern 3: Manage Case Content

4.5.6 Context

Case content refers to documents, video clips, photographs, scanned images and other unstructured information. Content can play a critical role in a case (for example, a signature in a legal document). Case workers must be able to create, access, and manage content.


Case content management allows case workers to create, view, modify, transform and delete content. Some cases are initiated when documents are received, such as an application form. In many cases, content is required to serve as evidence (for example, a photo ID). In other cases, the main purpose of the case is actually to create certain documents.

4.5.8 Approach

Each type of content can have data associated with it (metadata). For example, document metadata might include author, document type and date received. Often the management of the content depends on the metadata.

4.5.9 Method

As appropriate for the case under consideration, create tasks that enable case workers to:

1. Import documents and other content into the case. This can be done automatically by a utility process or manually by a case worker.

2. Organize content into folders. This is generally done automatically by a utility process.

Figure 4–6 Managing content by folders

On the left is a list of folders for content. The contents of the Case Participants folder are shown on the right, together with document metadata.

Manage


3. Display content (in this case an image) together with its associated metadata

Figure 4–7 Viewing content and its metadata

4. Enter or change document metadata (manually or automatically).

5. Create or edit content, if required (for example, write a document in MS Word).

6. Modify documents (for example, deleting pages, reordering pages).

7. Manage content versions.

8. Annotate documents.

4.5.10 Variations

• Number all documents in a case.

• If the content is received in paper format, scan it, index it, and import it into the case.

• Transform the format of the content (for example, render a MS Word document in PDF format).

• Import content from external sources (for example, SharePoint).

• Hold all content in a single folder and use a filter mechanism to restrict the view.

Manage


4.6 Solution pattern 4: Find Case Data

4.6.1 Context

As part of their research, case workers often need to locate individual cases, documents, person records, or other case information.


Case research helps discover facts needed to make the decisions in a case. For example, in the insurance claims industry, a case worker might want to find similar claims that have been submitted in the past that involve the same claimant. In general, case workers must be able to perform some level of research using case-based tools.

4.6.3 Approach There are three ways to find case data:

• explicit search

o Search for data, documents, cases

o Full-text search

• browse folders for documents

• select items from a pre-defined list

The following graphic shows an example of an explicit search in TaskSpace:

Figure 4–8 Search criteria

The following graphic shows an example of providing the user with the ability to select a case from a drop-down list.

Manage


Figure 4-9 Selecting a case from a drop-down list

After selecting the case, the user presses the Open button. This is clearly simpler than performing an explicit search.

Note: If this case had already been closed and the user selected it in the dropdown list, then she would not see a button labelled “Open.” Instead, the button would change to “Re-open.” This is a good example of case state-sensitive action buttons.

4.6.4 Method 1. Identify the type of item to find (for example, cases, documents).

2. Determine the technique to be used: explicit search, browsing, or select from list. If it is an explicit search, specify the search criteria (possibly including wildcards).

3. Decide how the system should respond when the user makes a choice (for example, how to display the hits, or what to do when the user selects an item from a list)

4.6.5 Variations

• Use full-text search for terms in a document or set of documents.

• Search a federated database.

• Select a case from a dropdown list on the Welcome screen.

Manage


4.7 Solution pattern 5: Perform Case Actions

4.7.1 Context

Case workers need to do more than view and enter case information. They need to be able to take action based on this information. Case workers perform actions to request more information, send the case to a reviewer, or approve the case.


Performing case actions enables the case worker to include human decision-making, based on knowledge and experience. Many cases are ultimately approved or rejected, but there are many intermediate actions and decisions that must be made. For example, a case worker might find a scanned document to be unclear and request a re-scan.

4.7.3 Approach

The basic tool for performing actions is the action button.

Figure 4–10 Action buttons

Each button is configured to perform an action. For some cases, like “Approve,” pressing the button is all that the case worker needs to do. For other actions, the button launches a form for the case worker to fill out with details associated with the action. For example, the “Send to Reviewers” button initiates a review activity. The case worker needs to select the reviewers and provide some instructions, as shown in the following form:

Figure 4-11 Action button launching a form

Notice that this form includes two action buttons.

Manage


Each action button has some result or consequence. In this example, the result is that the system creates tasks for the selected reviewers to perform.

4.7.4 Method 1. For each role in the case, determine which actions and decisions that role needs to

perform and under what conditions (depending on the state of the case).

2. Decide which actions are needed in each activity performed by that role.

3. If additional information must be entered, describe the required information.

4. Specify the consequences of the action. For example, if the decision is to accept the insurance claim, send an email to the claimant to that effect.

4.7.5 Variations

• Initiate an ad hoc task

• Initiate a task by supplying a URL instead of by pressing a button. (This might be used for a scanning task or any task in which the user needs to supply data).

• Initiate a process.

• Create a form instance.

• Cancel checkout.

• Print the form.

Review


5 Review

5.1 Category Overview The purpose of a review is to make sure that the outcome of the business process or case (be it a physical object, a document or a business decision) is correct and meets the desired quality criteria. The verification is captured by the outcome of the review. The review patterns have to be flexible enough to handle differences in the kinds of object being reviewed, the outcome of the review, and the review policies.

The review phase can include a combination of human and system activities. For example, a process may invoke a rules engine to determine eligibility, but also allow a human to override that decision. However, it is unlikely that a real case review would contain only system activities with no human activities.

Review patterns cannot be viewed in isolation, since they are dependent on solution patterns in other categories. For instance:

• A review is typically preceded by case work (as in the Manage or Communicate categories).

• A review can be followed by more case work.

• Case work and case review activities can be interleaved.

• Case review activities often depend on general case policies:

o The user who performs the review is determined by an assignment policy.

o A prioritization policy determines the order in which a reviewer performs multiple reviews.

o An escalation policy determines what happens when a reviewer does not perform the review on time.

5.2 Approach When implementing a review pattern, consider the following:

What is it that needs to be reviewed? What is the thing, object or information being subjected to a review? This can be an object within the system, a physical object outside of the system or both. Examples of objects that can be reviewed are:

• a document

• an image

• a collection of documents

• a decision to approve a case

Review


• an audit trail

• a customer call

• a Case Management methodology

What are the review criteria? Review criteria are the principles and methods by which the reviewer evaluates the object under review and produces review results. They can be defined in a checklist, a test procedure, a corporate policy, or codified in a legal document. The review criteria might exist outside of the system, as such, but govern how the review is performed, who performs it, and what the outcome is.

Who performs the review? The reviewer performs the actual evaluation and produces an outcome. How the reviewer is assigned is governed by an Assignment Policy Pattern. (See the section on Case Policies). Examples of reviewers are:

• the manager of the employee who produced the object being reviewed

• a subject-matter specialist

• a steering committee

• an automated system (for example, a business rules engine)

Under what circumstances is the review performed? This question captures two aspects of the review. First, it asks when the review is performed. In certain circumstances, a review is always performed at a certain point, while in others it depends on the context (for example, the funding amount requested in a grant application). In other circumstances, an external event triggers the need for the review (for example, a visit by a third-party auditor).

Second, this question asks whether the review is to be performed as part of normal case processing,

or is performed only if requested by the case worker.

What is the outcome of the review? The purpose of the review is to produce a result. Examples of common outcomes are:

• a decision or signoff (e.g. approved or not approved)

• a document

• a marked-up version of the document under review

• comments

• a new version of a document

• a digital signature

What effect does the review have on the case? Within the context of a case or a business process, the outcome of a review can influence the progress of the case or decide the future activities that will take place within the business process. This question also captures how the review interacts with case work, since the review might trigger additional case work until

Review


a sufficient level of quality has been reached. Examples of the effect a review can have on a case are:

• to move the case to a revision activity

• to effect a change in the state of the case (for example, a loan is approved)

• to produce nothing other than a review outcome

• to terminate the case

Example

Consider a grant application process in which a grants manager reviews a request for the purpose of approving or denying the grant, but he only needs to review it if the request is for an amount greater than $10,000. The solution team might answer the questions above as follows.

• Q: What needs to be reviewed? A: The grant application.

• Q: What are the review criteria? A: The grant application is judged on three criteria: originality, importance, and ability to execute. In an actual case this would be clarified by a more explicit series of questions that would need to be answered and judgments that would have to be made.

• Q: Who performs the review? A: The individual assigned to perform a peer review. How the reviewer is selected is determined by an Assignment Policy Pattern and might, for instance, depend on the type of grant sought or on reviewer availability.

• Q: When is the review performed? A: When the funding requested is greater than $10,000.

• Q: What is the outcome of the review? A: The outcome is a decision, either to approve or to deny the grant request. (In other types of cases, the outcome might only be a recommendation and the final decision would occur later, based on the recommendations of one or several reviewers).

• Q: What effect does the review have on the case? A: The outcome triggers a state change of the case. The applicant is informed of the decision and, depending on the decision, the case is closed.

5.3 Solution patterns in this category There are two solution patterns defined within the Review Pattern Category:

1. Sequential Review

2. Parallel Review

Review


5.4 Solution Pattern 1: Sequential Review

5.4.1 Context

This pattern occurs when case information (structured data or unstructured content) needs to be validated in a series of one or more reviews. The simplest example of a sequential review is the single review.

Multiple reviews can be formed by chaining together a series of single-step reviews. In many cases, the downstream reviews depend in some way on the results of the upstream reviews.


As with any review, the main business value is to ensure the correctness, quality and compliance of the work being performed. The sequential reviews generally build upon the previous reviews. For example, review 1 evaluates the content of a document and review 2 evaluates it in terms of style. The stylistic review requires the content to be corrected first.

5.4.3 Approach

The trivial sequential review involves only one review activity and is captured by the following flow:

Figure 5–1 Simple sequential review

The information or work product that is to be reviewed is produced and handed over to the reviewer. The reviewer evaluates the information or work product according to the review criteria produces an outcome. The outcome of the review can then be used in downstream activities in the case.

The sequential review becomes more complex as more steps are required. For example, here is a process fragment with two review steps:

Figure 5–2 Complex sequential review

5.4.4 Method 1. Identify the work product that needs to be reviewed. Is it the entire case, a subset, an

audit trail or an object external to the system?

WriteProposal

Department Head Review

Director Review

Review


2. Identify the criteria against which the review is to be performed. Provide instructions that explain the criteria to be used by the reviewer.

3. Identify the person or system responsible for performing the review. This could be a specific individual (“VP, Loan Operations”), it could depend on the values of data fields, it could be the performer of a previous task, or it might just be any individual from a group.

4. Identify the circumstances under which the review takes place. Does the review always take place, or only under certain conditions?

5. Identify the outcome of the review. Is the outcome a simple decision, a digital signature, a document, or a report?

6. Identify the effect that the outcome has on the case. Does it influence the process flow, or is simply a document stored within the case?

5.4.5 Variations

There are several important variations of the Sequential Review:

• Conditional Sequential Review

• Iterative Sequential Review

• Sequential Review with Delegation

It is not uncommon for these variations to be combined in the same process. For example, a case might include an Iterative Conditional Sequential Review or an Iterative Sequential Review with Delegation.

5.4.5.1 Conditional Sequential Review

A common variation is the Conditional Sequential Review. When a condition is added it changes the answer to the question “When is the review performed” from “always” to “when the condition is true.” In other words, in a conditional review the review isn’t always performed; instead, it depends on a condition of some kind. The conditional review is illustrated in the following process fragment.

Figure 5–3 Conditional sequential review

5.4.5.2 Iterative Sequential Review

Another common variation is the Iterative Sequential Review. In the iterative review, the outcome results in a decision, which may continue to trigger additional work until a sufficient level of quality has been achieved (that is, until a positive decision has been reached). The iterative review is illustrated in the following process fragment:

Review


Figure 5–4 Iterative sequential review

Sometimes the iterative review is restricted to a fixed number of iterations (or alternatively to a certain time duration), after which the process either continues or is terminated.

Typically the performer of the “Revise” step is the same as the one who created the initial work product, but this is a matter of case policy and is not invariably true.

Note that the decision point “Decision” can be a human decision, made by the same reviewer in each review cycle. However, it could also be assigned to a different person for each review. In some cases, it might even be an automatic activity.

5.4.5.3 Sequential Review with Delegation

Another common variation occurs when the reviewer is allowed to delegate the review. There are several aspects of delegation that can vary as well, such as:

• Successive delegation: Can the user to whom the review is delegated delegate it further? (that is, can delegations be nested?)

• Feedback, Is the review outcome sent back to the original reviewer, or is the outcome just forwarded to the next activity?

The essence of the sequential review with delegation is illustrated in the following process fragment.

Review


Figure 5–5 Sequential review with delegation

The issues concerning patterns of delegation are addressed in the Case Policy category.

Review


5.5 Solution Pattern 2: Parallel Review

5.5.1 Context

In some situations, it may be necessary for multiple people to perform reviews at the same time, either because a group decision is needed or because different people are reviewing independent aspects of the work product.


The purpose of this solution pattern is to improve efficiency by the strategy of “divide and conquer.” Different performers may have different skills and can work in parallel. This can save a significant amount of time over performing these review tasks sequentially. The Parallel Review solution pattern prevents the process from proceeding until all aspects of the work product or case have been approved by the person responsible for each aspect.

There are two fundamental differences between the parallel and the sequential review:

• Multiple reviews are performed in parallel

• Multiple outcomes are produced, and they must be combined in some way. This is a question of policy. It can be that all decisions must be positive, or perhaps multiple decisions will be merged into one by majority vote, or that multiple review reports will simply be added to the case.

5.5.3 Approach

The essence of the parallel review is illustrated by the following process fragment:

Figure 5–6 Parallel review

5.5.4 Method 1. Specify the information or work product that needs to be reviewed (for example, a

document, a set of information, a decision, or the entire case).

2. Identify the different aspects of the information or work product that need to be reviewed and ascertain if they can be reviewed independently.

Review


3. Specify the criteria against which the review is to be performed. Provide instructions on the criteria for the review for the reviewer (that is, by providing instructions for how the review is to be performed).

4. Identify the persons responsible for each review. This might be a specific individual (“VP, Loan Operations”) it might depend on case data, it could be the performer of a previous task, or it might just be any individual from a group and is governed by an assignment policy pattern.

5. Determine when the review takes place. Does the review always take place or only under certain conditions?

6. Describe the outcome of the review. Is the outcome a simple decision, a digital signature, a document, or a report?

7. Explain how multiple outcomes are to be combined. Is it a majority vote, or are multiple documents added to the case?

8. Determine the effect that the outcome has on the case. Does it influence the process flow, or is it a document stored within the case?

5.5.5 Variations

The variations of the parallel review are fundamentally the same as the variations for the sequential review.

5.5.5.1 Conditional Parallel Review

The conditional parallel review is similar to the conditional sequential review, except that the entire review, as well as certain aspects of the review, might be optional. For example, suppose the condition is “Does the document include images?” If the answer is yes, the images are reviewed in parallel with the content of the document. However, if the document has no images, then only the document content is reviewed.

5.5.5.2 Iterative Parallel Review

The iterative parallel review is similar to the iterative sequential review, except that if a positive decision is not reached, all reviewers might need to perform their review again. Or perhaps only the aspect that failed review will need to be reviewed again.

5.5.5.3 Parallel Review with Delegation

The parallel review with delegation is similar to the sequential review with delegation. Each reviewer may be allowed to delegate all the review work, or perhaps only certain aspects. For example, the manager might be required to review the content of the document, but the images in the document could be delegated to someone else.

Communicate


6 Communicate

6.1 Category Overview Most cases require some form of communication between persons within the case, or with external agents. Communication can occur at any phase of the case lifecycle. It can convey a question or an answer, a request for information, a formal notification of a decision, or it can be informal collaboration.

6.2 Approach Different types of communication are needed and each has its own characteristics. When implementing a communication pattern, consider the following:

1. Which parties are communicating? The communication can take place between parties working on the case (for example, between a grants manager and a peer reviewer), or the communication can be with an external party (for example, between the grants manager and the applicant).

2. Who initiates the communication? In the case of communication with an external party, the communication can be initiated by the external party or by a case worker. The former is referred to as “receive external communication” and the latter as “send external communication.”

3. What type of information is being communicated? This could be simple text, as in an email, but it could also include data fields or documents. For example, a grant applicant might send a project plan as a PDF document.

4. Is the communication formal or informal? External communication is generally formal, but internal collaboration can be formal or informal. An example of informal collaboration might be a collaborative discussion between a grants manager and grants reviewer.

5. Is a legal signature required? This is an important special case, in which an external party must sign and return a legal document. For example, if a party applies for a loan of $500,000, then a wet signature is required on the loan application.

6. What is the mechanism of communication? Communication can take place in a variety of ways, such as email, text message, a web form, a telephone call, or standard paper mail. If paper mail is used, then conversion from paper to digital format is generally required.

7. How can this communication be secured? For example, https can be used for transport layer encryption.

Communicate


6.2.1 Solution patterns in this category

The following solution patterns are defined within the Communicate category:

1. Send External Communication

2. Receive External Communication

3. Document Signature

4. Formal Internal Communications

5. Informal Internal Collaboration

Communicate


6.3 Solution Pattern 1: Send External Communication

6.3.1 Context

It is often necessary to send communications to the outside world. Some communications are one-way, such as notifications, approvals, or document delivery. Others follow a request-response model, as, for example, a request for tax forms. If the outgoing communication contains documents, the documents can be automatically generated, based upon case data, and personalized.


The aim is to integrate seamlessly all forms of communication within the case, so that the case worker is not distracted by switching to separate systems, each with its own user interface. For example, the xCP application interoperates with the organization’s email system so that the case worker receives and sends emails from within the case. This saves time, minimizes errors, and keeps the case worker focused on the task at hand.

6.3.3 Approach

Begin by identifying the touch points in the case where it is necessary to send notifications and receive responses. The designer can take advantage of pre-built activities and utility processes for implementing the different forms of communication. If necessary, create new interfaces for external communication. See the section of this document called “External Integration” for more on this subject.

6.3.4 Method

Following are typical techniques for sending external communications:

1. Send outgoing email. In the following example, the user is prompted to fill out a form. The process automatically transforms into an email.

Communicate


Figure 6–1 Outgoing email

Once the user presses the Send button, the system sends an email based on the form to the recipient.

2. In many cases, it is necessary to attach documents or images to the email. Custom documents can be automatically generated from case text and data. They can be personalized for the recipient as shown in the following example:

Communicate


Figure 6–3 Custom generated document

Communicate


6.3.5 Variations

• Send a reply to received external communications.

• Generate custom documents with barcodes.

• Send facsimiles.

6.4 Solution Pattern 2: Receive External Communication

6.4.1 Context

It is often necessary in a case to receive communication from the outside world. Examples are filing documents, email with attachments, and responses to requests for information. In some cases, the incoming communications will have to be correlated with previous outgoing communications (as in a response to a request).


As in the Send External Communication pattern, the aim is to integrate all communication within the case seamlessly, so that the case worker is not required to switch between different systems, each with its own interface.

6.4.3 Approach

The designer can take advantage of pre-built activities in business processes to receive the required types of communication. If necessary, create new mechanisms for external communication. See the External Integration section for details.

6.4.4 Method

Following is the typical method for responding to a request sent by email:

1. The case-based application listens for incoming email,

2. The application detects the case identifier

3. It saves the body of the message to the identified case

4. It saves the email attachments to the case

6.4.5 Variations

• Receive an incoming paper communications. The incoming document is commonly scanned and indexed.

Communicate


6.5 Solution Pattern 3: Document Signature

6.5.1 Context

This particular pattern is a variation of the simple external communication. It occurs when an organization requires a wet or electronic signature on a document.


This pattern is common in financial services and also within government. For example, a bank sends a new account application to the customer for signature. Once the bank receives the signed document, the document is added to the case.

6.5.3 Approach

The case sends an outgoing communication to the customer and waits for the response. The incoming (paper) document with the signature is scanned and added to the case.

6.5.4 Method 1. Identify documents that require a wet signature.

2. Generate and print the documents.

3. Send the printed documents to the customer for signature.

4. When the document is received from the customer, scan and digitize it.

5. Add the digitized document to the case

6.5.5 Variations

• Generate a barcode on the document.

• Ask the customer to attach additional paper documents (for example, a tax form).

• Configure a time-out on the incoming communication.

• Use a digital signature instead of a wet signature (for example, this can be done if the document is in PDF format and the customer has Adobe Acrobat Pro).

Communicate


6.6 Solution Pattern 4: Formal Internal Communication

6.6.1 Context

Case workers interact in a variety of ways. For example, managers assign tasks to case workers, and case workers sometimes delegate tasks to other persons. There needs to be some form of communication between these participants.


Formal case communication is used to provide clear instructions and feedback on tasks. These communications will also become a persistent and auditable part of the case.

6.6.3 Approach

Formal communication is generally handled in the actual tasks that workers perform. The tasks contain appropriate fields in which a worker provides input or response.

6.6.4 Method

Following are several techniques that are used in intra-case communications:

1. Instructions

Figure 6–5 Instructions

2. Feedback or response to a task

Figure 6–6 Reviewer response

This represents an official evaluation of the grant application.

Communicate


3. Notes

Figure 6–7 Case notes

Notes are comments entered by case workers and provide a running account of the case.

4. Action Log

Figure 6–8 Action log

The Action Log keeps track of all significant business events in the lifetime of the case. It provides a good communications vehicle for all case workers to understand the history of the case.

6.6.5 Variations

Respond to a task request and provide an explanation

Figure 6–9 Accepting a case

Communicate


6.7 Solution Pattern 5: Informal Collaboration

6.7.1 Context

Case Workers complete most tasks by themselves. However, some tasks require informal interaction with other case workers or internal experts.


Collaboration enriches the store of information available to the case, expands the breadth of alternatives to consider, provides new insights, and enables better decisions.

6.7.3 Approach

Collaborative activities can take place in different forms:

1. Joint activity: An activity in which two people work simultaneously together

2. Request/response: An activity done by person A, who requests assistance from person B

3. Discussion or chat: Person A sends comments to person B through the case in an informal band of communication

4. Common knowledge base: An activity in which one or more people contribute information to a topic in a common knowledge base, which can then be accessed by case workers.

6.7.4 Method 1. Joint Activity. Assign two workers to perform a single activity. They can interact on

this task in different ways: on the phone, in the same office, or by web-based communication.

Figure 6–10 Joint activity

2. Discussion: This technique enables informal channels of communication, so that case workers can send (out of band) messages to one another.

Figure 6–11 Informal interaction

Communicate


This is incorporated into the Grants Management application as a threaded discussion, as shown below:

Figure 6–1 Entering an informal comment

3. Common knowledge base. This is modeled as a standalone activity assigned to a group of workers. They create information that can be accessed by the case. For example, a group of healthcare researchers might be contributing information that is needed to make decisions for an individual patient.

Figure 6–2 Interaction using a common knowledge base

6.7.5 Variations • Post communications to a wiki.

• Post communications to a collaboration space in CenterStage.

Close Case


7 Close Case

7.1 Overview After a case is finished it needs to be closed. In order to end a case, the system performs a series of automated or manual activities. These activities update case status for reporting, move case data to offline storage, and ensure the case meets compliance and audit requirements.

7.2 Approach During the lifecycle of a case, a set of case data, documents, and folders typically transition from state to state. Once the case is complete, it is usually necessary to separate and archive this information. In addition, most reports need to distinguish between active cases and closed cases.

When implementing a case closing pattern, consider the following:

1. What case actions trigger case closure? A user may decide to initiate case closure based on external events or predefined criteria might be set for automatic case closure.

2. Does a final disposition document representing the case need to be generated? For historical or audit purposes, there may be a requirement to generate a read-only disposition document that contains a combination of different case documents and data.

3. Do the case folders, documents, and data need to be moved? In many situations, it is useful to store active case data in a separate physical location from the data of closed cases. The data might be moved to a cheaper storage medium since data access will be less frequent.

4. Will the case ever need to be reopened? If a case can be reopened after it has been closed, then you might need to store the active state of the case, such as the security applied to data or transient data such as the case actors.

5. Do external systems need to be updated with the results of the case? Case management systems frequently interact with other systems to retrieve case data, to make this data persistent, or to carry out case management functions.

6. Does the case information need to be published to a website? Once a case is closed, there may be a requirement to publish the results to a broader audience. For example, most modern judicial systems allow the public to view the case verdict after it has been issued.

Depending on what decisions were taken to complete the case, the system might need to execute specific business logic or perform updates to other systems in order to close the case. It might also need to generate documents that represent the official verdict, outcome, or summary of actions that lead to the conclusion of the case.

Close Case


7.3 Solution patterns in this category The following solution patterns are defined within the Close category.

• Case Data Archival

• Case Disposition

Close Case


7.4 Solution Pattern 1: Case Data Archival

7.4.1 Context

All cases contain persistent data, documents, and folders that need to be maintained long after the case is complete. Live case data is usually stored in different logical and physical locations from completed case data. In order to bring proper closure, the system needs to move this information to the proper locations.


Logically separating live cases from completed cases allows for easier maintenance of the system. Usually, live case data is accessed frequently and should utilize more expensive and responsive storage media. Archived case data is usually accessed less frequently and can be moved to less expensive storage. Archiving and securing the data ensures adherence to retention, regulatory, and audit requirements.

7.4.3 Approach

Identify the data and documents associated with the case and determine the requirements regarding auditing, retention, accessibility, security, and retrieval performance. The system designer can take advantage of pre-built activities that assist in applying these requirements, while others might require some degree of customization, depending on complexity.

7.4.4 Method 1. Identify the retention policy for case data. For example, you may be required to keep

all documents and data for a minimum period of 7 years from the time the case completes but discard the case folder structure if it is not needed.

2. Identify a base location for archived data. For example, you might create a separate cabinet that represents the year in which a case completed such that the retention disposition for all data in the cabinet is the same.

3. Identify the format of the case archive. For example, you might place all documents in an immutable virtual document, or you might render all documents to a single PDF file.

7.4.5 Variations • Allow for unexpected case termination.

Close Case


7.5 Solution Pattern 2: Case Disposition

7.5.1 Context

When a case is closed, there is a result based upon the decisions taken during the review state of a case lifecycle. The system must capture that result for reporting purposes, and take actions based upon the final case judgment.


Case management allows organizations to evaluate the merits of a case and make business decisions based upon the outcome of the case. Disposing of the case involves implementing the results, updating systems, and enabling reporting. In this way, case disposition enriches the collective intelligence of the organization.

7.5.3 Approach

Identify the different case actions and outcomes that must be taken in order to officially close the case. Ensure the reporting system knows the case disposition. Execute these actions as necessary by updating internal or external systems. Communicate the disposition to the interested parties.

For example, the defendant in a court trial has been found not guilty. Case closure requires the following actions: updating the district attorney’s performance statistics, clearing the defendant’s record, releasing the defendant from custody, and informing the public of the verdict.

7.5.4 Method 1. The case enters disposition after the final decision has been taken and the case data

has been archived.

2. Update the external systems that store the data related to the case.

3. Update the systems that gather and report the outcomes of cases.

4. Update the internal status of the case to “closed.”

5. Close all internal artifacts associated with the case.

7.5.5 Variations • Manual or physical actions may be required as part of disposition (for example,

releasing the defendant)

Case Policies


8 Case Policies

8.1 Overview Many solution patterns depend on establishing policies first. For example, the review delegation patterns assume that policies for task delegation are defined.

Case Policies refers to decisions that govern the behavior of the case across all phases of its lifecycle. In general, case policies are established at design time and enforced at run time. Each type of case has its own policies, as appropriate. For example, policies important for law enforcement are probably not relevant to opening a new account. In addition, policies of the same type might be applicable in different parts of the same case. For example, a case might use one assignment policy for document authoring, but a different assignment policy for document reviewing.

8.2 Approach When implementing case policy patterns, consider a series of questions about who, how, when, and what. For example:

Who:

• Who has access to case information?

• Who is allowed to work on a case?

• Who performs a specific task?

How:

• How are case workers assigned to cases?

• How can case workers seek assistance or delegate tasks to other workers?

• How (under what circumstances) can a case be escalated?

• How do we track incremental versions of case documents?

When:

• When are alerts raised?

• When does a case require escalation?

• When does a case milestone occur, or a case progress to a new phase?

• When should cases be removed from archival records? (In general, are there other policies pertaining to archiving?)

What:

• What cases (if any) require special handling?

• What actions, events or decisions are logged?

Case Policies


• What quality metrics are tracked for case management?

These questions affect the design and implementation of Case Initiation, Case Work (Manage, Review, and Communicate), and Case Closure. Effective system designers consider these questions early in the planning, well before the other Solution Pattern Categories are finalized.

8.3 Solution patterns in this category There are five solution patterns included in the Case Policies category, as listed below:

1. Case Access Control

2. Performer Assignment

3. Information Access Control

4. Task Delegation & Reassignment

5. Business Logging

This is not a comprehensive list. With more experience, additional solution patterns in this category might be identified.

Case Policies


8.4 Solution Pattern 1: Case Access Control

8.4.1 Context

Some cases are linear and task oriented: one discrete task is performed after another. However, other cases are more ad hoc. A case worker might do work as the need arises. Or a group of people might share responsibility for working on the case. It is important to determine which type of case is called for in the xCP application.


If the case control policy is rigorously task oriented, then each user performs their work within the context of tasks. If the case control policy is not task oriented, then it is necessary to provide a “command center” that allows a case worker (or group of workers) to perform work without the overhead of a task. This entails anticipating the functions they perform. Some cases involve a blend of task-oriented and non-task-oriented work.

8.4.3 Approach

Consider the following questions:

Who can work on the case? Specify whether it is a single case worker or a group.

What information must be provided? This might include case data, access to folders containing documents, an action log showing what has already happened in the case, and a case comments tool in which to add descriptive notes.

What actions can the performer take? An example would be sending a message to the case originator or importing documents into the case. Many of these functions can be exposed as action buttons.

8.4.4 Method 1. Decide which type of case control is necessary by asking questions about the

sequence of tasks that must be done. If the answer is “well, it all depends…it varies and is unpredictable,” then it is likely that the approach is not task oriented.

2. Describe the notion of a “command center” or “control panel” that provides the user a workspace.

3. Determine which data and document management functions need to be performed in the command center.

4. Identify the actions that users may need to take in the case.

5. Determine if the case is a group responsibility, where everyone in the group can see everyone else’s work If so, then decide who will has access and with what rights..

8.4.5 Variations

• If a task is defined as a group responsibility and a user in that group claims the task, then make sure that this task is removed from the inbox of all other workers in that group.

Case Policies


8.5 Solution pattern 2: Performer Assignment

8.5.1 Context

Throughout the life of a case, there can be several users performing different tasks in the case. The assignment policy defines which performer is assigned to each task.


The assignment of tasks to workers depends on a balance of several criteria:

• completing the tasks as efficiently as possible

• making sure that the person who is most appropriate to handle a task is assigned to it

• distributing tasks fairly, so that no one is overworked

• minimizing the number of resources

• maintaining the required level of quality

Different organizations prioritize these criteria in different ways, depending on criteria such as type of case, the nature of the work required, and the skills of their people. The goal of case policies is to ensure that each organization achieves optimal assignments according to their own criteria.

8.5.3 Approach

While trying to identify and define the different assignment policies, consider the following questions:

Is the performer named? Certain tasks must be performed by a specific user, such as the system owner, case owner, or a manager approving the work of a subordinate, while other tasks can be performed by any user within a group.

Is the performer static or dynamic? Static performers are performers who never change. It might be that a particular type of task is always done by one person, or a task is automated (performed by a system). Dynamic performers are those that are determined by a rule. For example, it might specify that a task should be performed by:

• the owner of a case

• the manager of a specific user

• any member of the underwriting group

Is there a backup defined? When defining an assignment policy with a named user (either static or dynamic) consider what happens if that user is not available. This typically involves specifying a backup performer.

Sample assignment policies

There are different types of assignment policies; for example, a task can be assigned to:

Case Policies


• the case owner

• the manager of the case owner

• the system owner

• the support case queue

• the resident expert on insurance fraud

Try to limit the number of policies to a small and consistent set that still covers your needs. If you have dynamic policies, make sure that any data necessary for the business rules are available, either within the process or through integration with a directory service.

8.5.4 Method

Decide how work is assigned to performers. Options include the following:

1. The manager (or some other designated individual) assigns performers by name.

2. The performer of a task assigns the performer of the next task.

3. A work queue automatically assigns the next performer.

4. A business rule determines the next performer.

o Define the business rule that determines the performer. This could be the manager of the performer of the previous activity, the manager for the current account, or some calculation made by the business rule.

o Make sure that all the data needed for the calculation are available in the process.

5. Determine if the performer assignment should be static or dynamic.

8.5.5 Variations

• Select the performer by invoking a rule in a business rules engine.

Case Policies


8.6 Solution pattern 3: Information Access Control

8.6.1 Context

Information Access Control specifies the persons who can access a case and its contents, the level of permissions associated with this access and the actions they can perform in the case. Access control is generally based on the security group of the user and the state of the case at the point in question.


In many government and business applications, cases contain sensitive information. Controlling access to information is needed to comply with legal requirements, and to protect the privacy of clients.

8.6.3 Approach

Consider the following issues when defining access control policies:

What types of information require access control? Access control operates at different levels:

• case

• application views within a case

• dashboards

• documents

• data

For example, a case worker might not be allowed to view dashboards that show performance metrics for other case workers.

What are the relevant security groups? Users are commonly assigned to security groups for the purpose of defining access control. Examples of security groups include case worker, clerk, reviewer, manager, and auditor. The access control capabilities for the auditor group would likely be different than for the clerk group.

What is the granularity of the access policy? Access control can apply to a group of cases, to an entire case, to selected objects within the case, or to individual data fields within a case object. For example, in an insurance claim handling system, medical records are viewed only by medical personnel while claim documents are viewed by all claim handlers.

What level of permission is allowed? Some individuals have the right to view information but not to change it. Other individuals have the right to delete documents from a case. It is important to specify the level of permissions for each user or group of users. For example, a clerk may be able to change certain data fields but might be limited in terms of what data to view, while the auditor would have wide scope in viewing data but could not change it.

Is the access static or dynamic? Static access does not change with time or circumstance. Dynamic access changes over time: for example, once a decision is made in a case, a case

Case Policies


worker is no longer permitted to change certain data fields. Static access is easy to define, maintain, and audit, but it might not always meet business needs.

When is access granted? This is closely related to the granularity and whether access is static or dynamic. Access might be assigned to a case or an object within the case at design time or at runtime. The latter can further depend on when the object is created, added to the case, when a case worker is assigned to work on a case, or when an internal or external event occurs.

How are exceptions handled? Sometimes access needs to be granted or restricted on an individual basis. For instance, if a relative of a grants manager applies for a grant, then access to that case might need to be restricted to prevent the grant manager from accessing the case and influencing the decision. One should always strive to minimize the number of exceptions, and it must be easy to audit any exceptions that arise.

Examples of access control policies

Below are common examples of access control policies:

• Case Based Access, in which all objects in the case have the same level of access control.

• Security Classification Based Access, in which access to an individual object is controlled by the security classification of that object (for example, “public” or “confidential”).

• Confidential data fields, in which certain data fields in an object can be viewed only by certain security roles.

8.6.4 Method 1. Define the security roles for the case (or group of cases).

2. Identify any sensitive case information, such as application views, dashboards, documents, and data.

3. Using a table, map the sensitive information to the security roles and specify the appropriate permission levels for each.

4. Specify when and how access is granted.

5. Identify documents that are hidden from certain users (in some cases the users must not be able to look inside these documents; in other cases the users must not even be aware of the existence of these documents).

6. Ensure that all information access is auditable

Case Policies


Following is a simple example of the table suggested in item 5:

Information Resource Sensitivity Security Role Access Permission

Health Claim Name of provider, diagnosis, and treatment

Claims worker Read or Edit

Customer Account Details

Personal information of value for identify theft

Claims worker, Claims manager

Read only

Customer Medical Records

Controlled by HIPAA regulations

Medical expert Read only

Claims worker, Claims manager

No access

Performance Dashboard

Information about case workers

Case executive Read only

8.6.5 Variations

• Define procedures for auditing

• Define procedures for exception handling

Case Policies


8.7 Solution pattern 4: Task Delegation & Reassignment

8.7.1 Context

In some cases, a performer needs the assistance of other resources to complete a task. In other cases, a manager might decide to reassign a task to a different performer.


Delegation is an important tool for a manager. It allows the manager to increase the productivity of an organization by transferring work from one resource to another; for example, when the original case worker lacks the necessary skills or is not available at the required time. It also allows a case worker to ask an expert for help handling a particular aspect of the work. For example, a complex insurance claim may need the judgment of an underwriter.

8.7.3 Approach

When implementing task delegation, consider the following:

Who is allowed to delegate work? The delegation policy must determine if no one is allowed to delegate work, if only certain roles can delegate, or if anyone can delegate.

To whom can a task be delegated? This question is closely coupled to the case assignment policy. Delegation involves a transfer of responsibility, but the person doing the delegation might be restricted in terms of to whom they can delegate a task. A manager might be allowed to delegate work only to her subordinates, while an individual contributor might only be able to delegate to his peers or to a designated group of people.

Is feedback required? Since delegation is a transfer of responsibility to another person, a key consideration is who decides if that responsibility has been properly fulfilled or not. Is it the person delegating or the person being delegated to? If the former case, the delegate must report back, while in the latter case the person completes the task and the case continues. The most common policy is delegation with feedback, which gives the responsibility to the person doing the delegation (that is, the one who was originally assigned the task). This policy difference is illustrated in the following two process patterns.

Case Policies


Figure 8–1 Delegation without feedback

Figure 8–2 Delegation with feedback

Does the same delegation policy apply to all tasks? Within case management solutions there are often multiple delegation policies, because certain tasks cannot be delegated (for example, a decision) and the restrictions on further delegation and feedback might also vary depending on the nature of the task.

8.7.4 Method 1. Decide whether to allow task delegation.

2. Decide which tasks, if any, can be delegated.

3. Decide to whom the tasks can be delegated.

4. Specify which tasks can be delegated with feedback, and which tasks can be delegated without feedback.

8.7.5 Variations

• Can a task be successively delegated? This might occur if the task was delegated to a performer who was unable to complete it properly, and therefore needed to delegate to a different performer.

• Can the task be delegated further? For instance, a manager might delegate the review of a document to his employee and that employee might want to delegate the review of the graphics to a graphic designer. The mandate given to the employee by the manager might or might not allow this type of nested delegation.

• Address the situation in which a task is delegated but is never performed. This is most relevant to the delegation without feedback pattern.

Case Policies


8.8 Solution pattern 5: Business Logging

8.8.1 Context

A business log is similar to an audit trail, but it is focused on information of business interest, such as case actions, events and decisions. The business log should be easily accessible by authorized business users. Most business logs are created manually by users entering comments; some business logs are generated automatically by the system, based on specific events. Other business logs will contain a combination of system-generated and human-entered information.


For many types of cases, having a record of significant events and actions is useful. It might also be a legal requirement. For example, court case management has a requirement for a document called a “docket” that records every important action in the case, such as a motion filed, a hearing scheduled, or a judge’s decision on a motion. The information in the business log must be recorded in a way that allows all authorized users to access it easily.

In investigative case management, an electronic notebook may be used to collect the comments of various police officers as the case progresses (for example, “the victim was visibly distressed”).

8.8.3 Approach

When defining a business log policy for a case management solution, consider the following.

What events should be logged? For example, it might be important to log all incoming information, all phone calls, and all decisions in the case.

What information should be logged? This refers to the attributes associated with events. For example:

• event identifier

• date the event occurred

• description of the event

• case worker who was proximate to the event

A business log can be as complex as business requirements dictate.

How are events created? Ideally, events are logged automatically as part of normal case processing. If the events occur outside of the case process, this might not be possible. For instance, if a client calls in to a call center, a case worker might have to enter notes in the corresponding case, recording the key facts about the phone call. However, if the same client submits a web form, the system might automatically add that event to the case.

Can users create entries into the log? As mentioned above, some business logs are designed to capture comments from system users while others simply capture events automatically.

Case Policies


What is the access policy of the business log? One issue of policy is which business users should have access to the business log. Another important aspect of the business log is whether or not it is editable. For example, can an error detected in the log be corrected? It generally is not permissible to delete events from the business log, but that is also a matter of policy.

8.8.4 Method 1. Define the event types in the case that need to be logged.

2. Decide if users will enter comments into the log, the system will record events automatically, or both.

3. Specify the set of attributes that is associated with each event.

4. Specify each activity that automatically triggers event logging

5. Define the access policy for the business log

8.8.5 Variations

• Enable authorized business users to add comments to the business log, but not edit the automatic entries.

Data Model


9 Data Model

9.1 Category Overview Case management solutions require facts, observations, statistics, measurements, and items of information that allow users or systems to draw conclusions about a case throughout its lifecycle. Without this information, a case cannot be defined, much less executed.

Data can be structured, such as XML files or database tables, or unstructured, such as images or video files. The definition of how, where, and for what duration this data is stored will have consequences throughout the solution. Moreover, changes to the data model made in later stages of a project will generally may require rework of those components that depend on the data definition. It is important to understand how data are produced and consumed by a case and to define the data model as fully as possible early in the project lifecycle.

9.2 Approach The data model is a holistic representation of all information needed to originate, execute, and maintain a historically accurate representation of a case once it is completed.

When designing a data model, consider the following:

What content is required for case workers and reviewers to make appropriate decisions? Case management systems require content to enable case work, review, and completion. Examples of content include:

• Office Documents

• Audio/Video

• Images

• Emails

What metadata is needed to describe content? Metadata is structured data that describes content. It enables searching, reporting, and system-to-system interaction. For example, the following metadata could be used to describe a contract:

• Contract ID

• Client ID

• Contract Start Date

• Contract End Date

Are there other entities needed by the process? Metadata can also describe entities that contain no content. Examples of these entities include:

• Person

Data Model


• Place

• Application

What data is needed for systems to make appropriate decisions? Some data are not consumed by end-users, but instead enable systems to make decisions as the case executes. Examples include:

• threshold levels that trigger alerts

• data values that are used in making routing decisions

What is the origin of case data? Data and content can originate from various sources, and influence design decisions, determine the system of record, and affect security requirements. Examples include:

• information ingested from external sources, such as incoming email

• data entered by a case worker

• static variables set on a case

• application-specific or environment-specific variables

How will users, applications, and other systems interact with case data? This helps drive requirements for other aspects of the application, particularly its interfaces with external systems. Examples include:

• a case worker needs to create a MS Word document from a template

• a case reviewer needs to annotate a document in a web browser

• an external system needs to ingest certain data fields from an approved application

When is information needed? This will help define security, audit, retention, and persistence requirements. Examples include:

• a case worker needs access to all case documents until the case completes

• compliance requirements call for case documents to be stored for 7 years after the case completes

• data published to an external system must be discarded upon case completion

Where should information be stored? Based on the nature of the data, there can be several storage and format options. This decision might be constrained based on how that data must be produced or consumed. Examples include:

• External database tables

• File storage

• Regulations concerning information privacy

Data Model


Example:

Consider a grant application process in which a formal review is required whenever the funding amount requested is greater than $10,000.

• Q: What content is required for case workers and reviewers?

A: The grant application document

• Q: What metadata is needed to describe content?

A: The funding amount; that is, the amount requested in the grant application

• Q: What data is needed for systems to make appropriate decisions?

The threshold amount ($10,000)

• Q: What is the origin of the case data?

A: The grant application documents are submitted externally by applicants. Business requirements dictate the threshold amount.

• Q: How will users, applications, and other systems interact with case data?

A: Grant managers must be able to view the application electronically in a web browser and annotate the document. The case management system needs to retrieve the threshold amount.

• Q: When is information needed?

A: The grant application is needed during case review and is archived for compliance reasons. Upon completion of the case, the threshold amount is no longer needed and is discarded.

• Q: Where is information stored?

A: The grant application is stored in a case folder and written to disk, with its metadata stored in a database. The threshold amount is stored in a database.

• Q: What relationships exist between the case and the data?

A: A case can include only one grant application. The persistent amount of the grant must be compared to the transient threshold amount.

In this example, the data model could be represented as follows.

Figure 9–1 Data model example

Data Model


9.3 Solution patterns in this category There are three solution patterns within the Data Modelling category:

1. Model Persistent Process Data

2. Model Transient Process Data

3. Model Data Relationships

Data Model


9.4 Solution pattern 1: Model Persistent Process Data

9.4.1 Context

Business entities, such as customer, order, invoice, and product, are modelled as persistent data. This persistent data is consumed by business processes. This data is ingested, created, generated and transformed by the business processes. Its output is preserved after a case is completed.


Structured data, as well as unstructured content (such as documents, images, multimedia files) is a critical element in case processing. It depends upon the core information model with which organizations conduct their operations, even after the case is complete. This is the “persistent data model.” An example is the folder taxonomy in which that content is organized for case execution. This hierarchy is valuable and needs to be preserved upon case completion.

9.4.3 Approach

The basic approach is to identify the content, metadata, and case information that is consumed (and created) during the case lifecycle and which, upon completion of the case, is retained for future use.

9.4.4 Method 1. Define and model persistent entities. These data entities should accurately mirror

real business entities (contract, order, invoice, etc.).

2. For each entity, specify its attributes and their types.

3. Define and model the case folder structure, its metadata, and logical storage locations.

4. Identify documents and other unstructured data that are necessary for case workers to perform their tasks.

a. Specify the necessary metadata for each piece of unstructured content.

b. Model the content in Documentum as custom object types.

c. Consolidate and normalize the data model as appropriate.

9.5 Solution pattern 2: Model Transient Process Data

9.5.1 Context

Some data that are important in the case lifecycle are not needed once the case is complete. These data elements are “transient process data.” They are kept in temporary storage and discarded after the case completes. An example of transient process data is a counter, a data structure that keeps track of the number of items in a list, such as a list of items received from another system. Transitory data, even though it is not maintained in persistent

Data Model


storage, is monitored by the Business Activity Monitor. See the chapter in this document on Monitoring.


There are several reasons for distinguishing between persistent and transitory data. First of all, separating data used only during process execution from persistent data allows for streamlined maintenance of the underlying storage structures. Second, it eliminates the storage of data that comes from external systems of record and might become outdated. Finally, there are performance implications associated with the way in which data is stored.

9.5.3 Approach

The basic approach is to look for data elements that are needed temporarily, during process execution. Do not expect to identify all transitory data elements in the requirements phase. This task will be completed during the design phase, when these elements will be mapped into “Process Variables.”

9.5.4 Method

For each case:

1. Specify the data elements that are used for:

a) transition decisions

b) inter-process communication

c) inbound correlation events

d) environment-specific variables (i.e. is a the document generation system is enabled)

e) communication with external systems

f) counters

g) variables that an Administrator can manually update mid-process (See Managing Process Parameters in the Process Builder User Guide Release 6.6, page 61)

2. Map the elements into the appropriate process variables

3. Consolidate and normalize the data model as appropriate

4. Assign the process variables to the appropriate process templates

Data Model


9.6 Solution pattern 3: Model Data Relationships

9.6.1 Context

Data entities will often be related to other data entities. It is important to understand these relationships when building solutions.

Example 1: Composition Relationships

Figure 9–2 Data relationships

In this example, the cardinality of the relationship is 1-1. One customer has a unique address. However, we may want to allow a customer to have multiple addresses (for example, to include a summer home). In that case, the relationship would be 1-n. If the household can contain several customers, then the cardinality would be modelled as n-n. In general, the modelling is based on certain assumptions about the domain.

Example 2: Inheritance Relations

A Case-Based Application is a kind of Business Application (that is, “Case-Based Application” inherits from “Business Application”).

Example 3: “Uses“ Relationship

An employee uses a Case-Based Application.


Reusing and repurposing data allows organizations to maintain the integrity of their data sources, while minimizing the cost of maintaining that data.

9.6.3 Approach

Identify and model the semantics of the entities and other data.

• Direct relationships – Entity Person of type Lawyer is assigned to a case

• Indirect relationships – Entity document of type docket is located in the case folder

Data Model


9.6.4 Method

Given the data model:

1. Identify a relationship. Then determine

a. Cardinality

i. 1-1 (customer to address)

ii. 1-many (customer to order)

iii. many-many (order to product)

b. Hierarchy and Direction

i. Are the related entities describing a master object (master to detail)?

ii. Is the relationship hierarchical (parent to child)?

c. Recursion: Can an object relate to itself?

d. Ordering: Is the order of objects related to a master object important in a master-detail relationship

2. Create an entity relationship diagram (ERD)

3. Evaluate the design criteria and adjust as necessary

a. Performance: ability to construct efficient queries

b. Space consumption

c. Deployment and referential integrity: when moving from one system to another, are the relationships maintained?

4. Determine the implementation approach for each relationship

9.6.5 Variations

• Use a UML model to show data entities and relationships.

External Interfaces


10 External Interfaces

10.1 Overview Cases rarely exist in isolation from other systems and data in the enterprise (or beyond the enterprise). There are often several points in the life of a case where interaction with external systems occurs. For example:

• The case is initiated by an external user. An external client might submit a form from a website, send an email to a case mailbox, or mail a paper form that is scanned and ingested.

• The case is initiated by an automated system by invoking a web service.

• During the life of a case, validation rules require access to an external database.

• When a task is assigned to a case worker, an assignment policy requires the name of the user’s manager from the corporate directory for subsequent approval tasks.

• During case closure the case updates back office systems. For example, the case sends account opening details to a CRM system.

Note that there is considerable overlap between External Integration and other solution pattern categories; for example, sending an email is a communications function as well as a form of external integration.

10.2 Approach When designing integration points for a case management solution, consider the following:

What is the direction of the contact? There are four possibilities:

• incoming, unsolicited (i.e., not a response)

• incoming, response

• outgoing, response

• outgoing, unsolicited (i.e., not a response)

What is the nature of the interaction? Consider three types of interaction:

• Exchange of structured data

• Exchange of unstructured data (that is, content such as images and text documents).

• Service request or invocation, to perform some form of action

These types are not mutually exclusive. For example, a request might involve acting on content, such as a request to render a MS Word document into PDF format.

What is the timing of the interaction? Consider three types of interaction protocols:

External Interfaces


• On demand. On-demand integration means “invoked when needed.” The interaction can be synchronous (that is, the process waits for a response) or asynchronous (that is, the process continues without waiting for a response). Typical examples of on-demand interaction protocols are web service calls and external database queries.

• Scheduled. A scheduled integration pushes or pulls data periodically, at a regular interval. A typical example is synchronizing a group from a directory service.

• Publish/Subscribe. In this mode of interaction, a case subscribes to messages published by an external data feed. For example, the external data feed might post significant stock market changes, to which the case could react.

10.3 Solution patterns in this category There are four solution patterns in this category.

• Data Integration

• Content Integration

• Outbound Service Requests

• Inbound Service Requests

External Interfaces


10.4 Solution pattern 1: Content Integration

10.4.1 Context

Sometimes it is necessary to import content produced outside of the case. At other times, it is necessary to publish content that exists within a case to an external system.


Case-based applications operate in a business environment in which content can be created inside the case or outside the case. It is critical that the case-based application can exchange documents, images, and other types of content with its environment.

10.4.3 Approach

Consider the following questions when trying to identify and define content integration needs:

What is the direction (incoming/outgoing) of the communication? Content can either be sent out from the case (system) or received by the case (system).

What is the communication mechanism or protocol? There are many ways of exchanging content between systems. For example:

• web-based submissions (HTTP)

• file exchanges (FTP)

• the local file system

• email

• facsimile

• web services

• physical posting of a paper document (requiring a scanning or printing solution)

What is the content being communicated? It can be a single document or multiple documents.

What is the format of the content? A case document written in MS Word might need to be transformed into PDF format before being sent to the external destination.

How is content be correlated to the case? Incoming documents are either used to start a new case or else they need to be correlated to an existing case. This means that the incoming document must be marked with a case ID or similar identifier to indicate the case with which it is associated.

Who is the recipient of the content? The recipient of the content can be a system, a specific user, or a set of users (as in an email or a post).

When is the content communicated? In some situations, content is received on demand, as in a filing to institute a civil lawsuit. In other situations, legal restrictions require that

External Interfaces


content be sent out by a certain date. The solution must reflect the time constraints of the interaction.

10.4.4 Method 1. Determine the direction of the communication.

2. Define the communication protocol.

3. Specify the content to be communicated and its format.

4. If necessary, define the case identifier for the content.

5. If necessary, define the recipient of the content.

6. Specify when the content is to be sent or received.

External Interfaces


10.5 Solution pattern 2: Data Integration

10.5.1 Context

Sometimes it is necessary to retrieve from external systems data used in the processing of a case. At other times, it is necessary to update an external system with data produced by the case. Both involve data integration.


In many enterprises, certain systems and databases are designed as systems of record. They contain the official data and are generally outside the scope of the case. That is, the case may read, consume, modify and transform this data, but its ultimate destination is with these external systems. A good example of this is an enterprise’s organization data, which often resides in an enterprise directory system.

10.5.3 Approach

Consider the following questions when trying to identify and define the data integration for your solution:

What is the nature of the data? The data could be of various types: customer data, product data, data from industry databases, or data stored in systems of record.

What is the direction (incoming/outgoing) of the integration? As with content integration, data can flow into or out of the case. A common pattern is for data to flow into the case, be consumed and transformed by the case, and then flow from the case to the external system.

When is the data communicated? The data might be sent or received based on an explicit request by a case manager, or it might be received automatically (at any time).

What is the mechanism or protocol of communication? Data can be sent and received using a variety of mechanisms. For example:

• database read or write

• web forms (HTTP), in which a user submits data from a form on a website

• web services, an automated application-to-application mechanism

10.5.4 Method 1. Determine the direction of the communication.

2. Define the communication protocol.

3. Define the nature of the data.

4. Specify the content to be communicated and its format.

External Interfaces


10.6 Solution pattern 3: Outbound Service Requests

10.6.1 Context

In the outbound pattern, the case requests external services. For example, it might request that SAP perform a calculation and return the results. or it might request currency conversion from Kronor to Euros.


Outbound service requests enable the case to utilize services provided by systems inside or outside of the enterprise. They also enable a case to take advantage of a Service Oriented Architecture, which offers the benefits of loose coupling and flexibility.

10.6.3 Approach

Consider the following questions when identifying outbound service requests applicable to your solution:

What is the mechanism or protocol of communication? The service can be invoked using:

• web services

• HTTP

• a low-level API call

• an external program

What is the interface of the service? The interface of the service is defined by the service name (or URL), parameter list, and the result produced. For example, consider a method, openNewAccount, which is exposed by a back office system. This method might take a complex parameter structure specifying the individual to open the account and the type of account. It would then return the account ID of the newly constructed account.

When is the service invoked? The service might be invoked on demand when a case worker seeks to change an account type. Alternatively, the case might send periodic updates to another system about the progress of the case. The service might be invoked only when an event happens in the case (for example, when the case enters the case closing phase).

Is the result of the invocation synchronous or asynchronous? Regardless of the direction of the method invocation, the invocation can be either synchronous (a response is produced immediately) or asynchronous (the response is delayed and either pushed back later or polled for).

10.6.4 Method 1. Specify the mechanism of communication.

2. Define the interface of the service the solution exposes.

3. Specify when the service can be invoked.

External Interfaces


4. Specify the synchronicity of the service and, if it is asynchronous, specify how the results are fetched/received.

External Interfaces


10.7 Solution pattern 4: Inbound Service Requests

10.7.1 Context

External systems sometimes need to control certain aspects of a case (for example, starting a new case automatically when a web form is submitted). Inbound service requests specify how external systems or external clients can direct and control case processing.


Some customers will prefer to keep their familiar existing systems and user interfaces but use xCP for case-related services. Inbound service requests enable this pattern of use. They ensure that the case management system presents its functionality as a set of services, which fits well with an enterprise-wide Service Oriented Architecture.

10.7.3 Approach

Consider the following questions when identifying inbound service requests that are applicable to your solution:

What is the mechanism or protocol of communication? The service can be invoked using:

• web services

• HTTP

• a low-level API call

• an external program

• email sent to a functional mail box

What is the interface of the service? The interface of the service is defined by the method name (or URL), parameter list, and the result produced. For instance, a service “startCaseWithDocument” exposed by a case management solution might take a single parameter (the document) and return the case ID of the newly constructed case.

When is the method invoked? One possibility is that the service can be invoked on demand at any time by another system. Alternatively, an existing case process might have to wait in a suspended mode until a service is invoked. The service might only be available at certain times.

Is the result of the invocation synchronous or asynchronous? Regardless of the direction of the service invocation, the invocation can be either synchronous (a response is produced immediately) or asynchronous (the response is delayed and either pushed back later or polled for).

10.7.4 Method 1. Specify the mechanism of communication.

2. Define the interface of the service that the solution exposes.

External Interfaces


3. Specify when the service can be invoked.

4. Specify the synchronicity of the service; if it is asynchronous, specify how the results are fetched/received.

Monitoring


11 Monitoring

11.1 Category Overview Case Monitoring gives workers, managers and executives visibility into cases, allows them to see patterns and assess trends, and to take corrective actions. The benefits of business activity monitoring (BAM) include faster response time to problems, better decision making, and improved service to customers and partners.

11.2 Approach When defining how the solution will be monitored, consider the following:

What real-time information about executing processes is needed? Typically, this includes activities that have completed, the activity that is currently executing, the durations of activities, the names of performers, and so forth.

Who needs this information? This could be an operational manager or a group of operational managers, a case worker, or a business executive. Their responsibility is to ensure that the processes are running smoothly and achieving the expected business outcomes.

What types of historical reports are needed? Since the number of completed individual processes can be very large, it is common to provide summary reports that aggregate this information. For example, a summary report might show the number of new insurance claims grouped by month, geographical location, or type.

How will this information be presented? Normally, summary reports are organized into related groups and presented in dashboards. Some dashboards will be targeted at operational managers, some at process owners, and others at line-of-business executives. Individual reports can also be embedded in the workspaces of case workers.

What should happen if Service Level Agreements or Key Performance Indicators are not met? The monitoring subsystem provides the ability to generate alerts based on various conditions. For example, if an automobile claim takes more than five days to adjudicate, an alert is raised and sent to the responsible claims supervisor.

Monitoring collects real-time information from executing business processes. This includes information about the:

• activities in the process (for example, when each activity start and ends)

• performers of activities (for example, who performs the activities – both users and queues)

• business data managed by activities (for example, order number, date of order, items ordered)

11.3 Solution patterns in this category There are four solution patterns defined within the Monitoring Pattern Category:

1. Current Activity Monitoring

Monitoring


2. Historical Reporting

3. Management by Exception

4. Publishing

Monitoring


11.4 Solution pattern 1: Current Activity Monitoring

11.4.1 Context

Assume that a process instance is in progress. Some activities may have completed while others have yet to occur. Instance Monitoring allows you to:

1. see where the process instance is at this moment (which activity is executing)

2. understand the progression (path) of the process up to this point


Instance Monitoring enables an operational manager to determine the current status of a specific ongoing case or process instance. For example, it allows the manager to answer the question: “What is the status of Customer X’s Order of January 22?” It also allows her to estimate when the order will be completed. If the order has been delayed, it helps to diagnose the problem.

11.4.3 Approach

A dashboard displays a list of in-flight processes. When the user selects a specific instance, the process diagram shows the current state of the instance, with the current activity indicated.

11.4.4 Method 1. Create a dashboard called “Instance Monitoring” (or something equivalent but more

meaningful for the business, like “Current Loans”).

2. Add a Process Instance list and a Process Diagram report to the dashboard.

3. Create a drilldown relationship between the Process Instance list and the Process Diagram (meaning that the Process Diagram you see depends on the Process Instance the user selects).

4. Decide if users want to filter the report results to their own department or region.

5. If you are monitoring a case that contains many processes, it might not be convenient or helpful to monitor each and every case. In this situation, you need to create a special BAM Control Flow to represent the progress of the case. This single process collects significant events from the other processes, thereby allowing the user to see them displayed in a single process diagram.

11.4.5 Variations

• Include a gauge report in the dashboard that shows the time elapsed (for the specific case or process instance). You could also add a dial-gauge that shows the average duration (for example, over a day, week, or month).

• For the current activity, provide a report detailing the performer, start time, duration, and possibly the business data.

Monitoring


• Provide a report that shows the same information for all completed activities.

Figure 11–1 Process instance dashboard

Monitoring


11.5 Solution pattern 2: Historical Reporting

11.5.1 Context

When process instances finish, it is useful to summarize performance in the form of analytical reports. These reports are displayed in dashboards.


Summary Reports provide insight into operational results and performance. There are four main types:

1. Classification Reports – for example, how many orders were received from gold, silver, and bronze customers (pie chart), how many orders were received from each state (bar chart), or what was the average time for order fulfillment for each sales region (bar chart)?

2. Detail Reports – for example, for each order received this week, show the date of the order, the name of the customer, the customer’s state, the products ordered, the branch office responsible, and the total amount of the order.

3. Performer Reports – for example, how many cases is each performer working on, what is the average case duration for that performer, and what is the total dollar value of all orders for that performer (for example, over the last week)?

4. Trend Reports – for example, how many loan applications have been received each week for the preceding month, and what is the average duration of the loan process each month for the last year?

With this information, managers can accurately measure the efficiency of people and processes, correct operational problems, and help performers succeed. Executives can analyze costs, determine when to increase or decrease the workforce, and decide when to restructure the underlying processes.

11.5.3 Approach

Plan the dashboards, based on the needs of the operational managers and other dashboard users. Create the required reports and insert them in the appropriate dashboards.

11.5.4 Method

Proceed as follows:

1. Identify a set of potential dashboard users. This might include executives, line of business managers, IT professionals, operational managers, and business analysts.

2. Interview the users to understand their reporting needs. Describe the four types of summary report (described above) and ask what information they need.

3. Determine the time filter for each report (for example, data grouped by day, week, or month).

Monitoring


4. Based on feedback from interviews, create prototype dashboards and hold another review. For each report, discuss why this information is important and how it will be used.

5. Periodically reconvene the users and assess the effectiveness of the dashboards. Make any necessary changes, adding new reports, deleting reports, or changing the content of reports.

Be careful about the number of reports per page. Do not include too many reports in a dashboard, as usability may suffer.

11.5.5 Variations

• Reports can include the ability to click and drill down for more details. For example, the user can click a segment in a pie chart and display a bar chart that provides the next level of detail.

• Analytical reports can be inserted in the worker portal of individual task performers. The information in these singleton reports is relevant to the tasks of the worker and throws light on the task at hand. For example, the report might show the number of orders that a customer has made over the last year, together with the date and amount of each order. This provides context for the task performer.

• Reporting with data in external systems

Monitoring


11.6 Solution pattern 3: Management by Exception

11.6.1 Context

Management by exception involves the following functions:

1. Noticing that something exceptional has occurred, generally a weakness or operational problem. For example, a certain process is not meeting its Service Level Agreement.

2. Identifying the root cause of the problem, which could be a resource problem, a data problem, a process problem, or a performer problem.

3. Taking appropriate corrective action, for example, to add more resources or change the process.


Managers want to be informed when a problem occurs, and the earlier the better. Problems that are caught early cost less to correct. Even better is to be informed before the problem has occurred, based upon the past performance of a process.

11.6.3 Approach 1. Notice an exceptional situation. You might be able to detect a problem from a

summary report. For example, one branch office might have a much longer cycle time than the others. You can also define alerts that indicate in real time a problem or exceptional situation. These alerts are displayed in a dashboard.

2. Identify the root cause. This is generally done by reviewing a report to understand the details. You might have to look at multiple reports to understand the full picture.

3. Take corrective action. When an alert occurs, an email is sent out to the responsible parties. Alternatively, the alert can trigger a remediation process.

Note: Alerts can be based on a variety of parameters, including:

• process duration (for example, if the duration of the ongoing process takes more than 8 hours, generate an alert)

• activity duration

• average process duration

• business data, such as the number of instances completed in a unit of time, or calculated values, such as the dollar value of an order (for example, if an order amount > $1M, generate an alert).

11.6.4 Method 1. Define SLAs: these are the thresholds set by business for alerts.

2. Based on the SLAs, define each alert and set its severity level.

Monitoring


3. For each alert, decide which users (by name) who should be alerted.

4. Define the alert resolution process. What must they do in order to close the alerts?

5. Create one or more alert reports and insert them into the appropriate dashboards.

11.6.5 Variations

• Add an Alert List Report to the Instance Monitoring dashboard

• An alert can automatically trigger a remediation business process. This process would typically define the steps needed to investigate and resolve the alert condition.

Monitoring


11.7 Solution pattern 4: Publishing

11.7.1 Context

Publishing is the means by which BAM reports are conveyed to the consumers of these reports.


Reports on current activities or historical metrics must be communicated in an appropriate way to case workers, supervisors, and managers. This allows these individuals to understand the state of the business, make better decisions, and take corrective actions when needed.

11.7.3 Approach

Publishing is based on the needs of the audience. Understand the audience for monitoring reports and design a communication mechanism that best meets their needs. Different types of user will have different needs. For example:

• An executive might only be interested in historical business metrics.

• A case supervisor might want to know the status of the work queues in her group.

• An operational manager might need to know what is happening at the moment.

• A heads-down case worker might need only a report that shows how many of his cases are new, how many have been screened, and how many need screening.

11.7.4 Method

Proceed as follows:

1. Identify the users who require monitoring reports.

2. Interview the users to determine what type of monitoring reports they need.

3. Decide if it is most appropriate to use dashboards as the means of communication. Which dashboards will each individual need? What should each dashboard be called?

4. Determine the reports that each dashboard will contain. Create mockups of the dashboard. Review with the target users.

5. Decide if individual reports embedded in a user workspace are more appropriate for a different group of target users. Which reports do these users need and in what context? For example, the case worker may need to see a report on order history for the customer they are servicing.

11.7.5 Variations

• Create a batch job that generates a set of reports and send them to users via email.

• Embed selected BAM reports in a custom web application.

Software

xCP Pattern Library 3.3