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 .................................................................
Executive Summary
xCP Pattern Library 3
1 Executive Summary
xCP is a case-based offering built on the Documentum platform....
Executive Summary
xCP Pattern Library 4
important, but outside the scope of this document. The following are a few methodo...
Basic Concepts
xCP Pattern Library 5
2 Basic Concepts
2.1 Case-Based Applications
Businesses and governmental agencies oft...
Basic Concepts
xCP Pattern Library 6
• Solution
• Consequences
EMC has taken a similar approach in the xCP Pattern Library...
Basic Concepts
xCP Pattern Library 7
3. Extension categories. These are optional but in practice can provide extreme value...
Basic Concepts
xCP Pattern Library 8
Each Solution Pattern is described in the following way:
• Context: Short description...
Basic Concepts
xCP Pattern Library 9
Figure 2-3: Design pattern categories
This allows developers to investigate and learn...
Basic Concepts
xCP Pattern Library 10
Figure 2-5: Mapping a solution pattern to a design pattern
The mapping means that th...
Initiate Case
xCP Pattern Library 11
3 Initiate Case
3.1 Overview
The lifecycle of a case begins with initiation. In order...
Basic Concepts
xCP Pattern Library 12
Examples of system-generated supporting data include:
• case must be assigned a uniq...
Basic Concepts
xCP Pattern Library 13
2. Validate Case
3. Set Up Case
4. Accept Case
The solution pattern “Validate Case” ...
Basic Concepts
xCP Pattern Library 14
• Some types of cases will be assigned case numbers at this point, while other types...
Basic Concepts
xCP Pattern Library 15
3.5 Solution pattern 2: Validate Case
3.5.1 Context
After process initiation complet...
Basic Concepts
xCP Pattern Library 16
3.6 Solution pattern 3: Set Up Case
3.6.1 Context
A case request is submitted and va...
Basic Concepts
xCP Pattern Library 17
3.7 Solution pattern 4: Accept Case
3.7.1 Context
In many business environments, a c...
Manage
xCP Pattern Library 18
4 Manage
4.1 Category Overview
The Case Initiation category brings information from the outs...
Manage
xCP Pattern Library 19
screen in a way that is clear and easy to navigate. Often they will need to search for
docum...
Manage
xCP Pattern Library 20
4.4 Solution pattern 1: View Case
4.4.1 Context
The case worker needs to view the case in or...
Manage
xCP Pattern Library 21
3. User can enter and view other case metadata (shown on right).
4. The interface includes a...
Manage
xCP Pattern Library 22
4.5 Solution Pattern 2: Manage Case Data
4.5.1 Context
This solution pattern addresses the c...
Manage
xCP Pattern Library 23
information in each task: irrelevant data distracts from the work that must be done,
and som...
Manage
xCP Pattern Library 24
Solution pattern 3: Manage Case Content
4.5.6 Context
Case content refers to documents, vide...
Manage
xCP Pattern Library 25
3. Display content (in this case an image) together with its associated metadata
Figure 4–7 ...
Manage
xCP Pattern Library 26
4.6 Solution pattern 4: Find Case Data
4.6.1 Context
As part of their research, case workers...
Manage
xCP Pattern Library 27
Figure 4-9 Selecting a case from a drop-down list
After selecting the case, the user presses...
Manage
xCP Pattern Library 28
4.7 Solution pattern 5: Perform Case Actions
4.7.1 Context
Case workers need to do more than...
Manage
xCP Pattern Library 29
Each action button has some result or consequence. In this example, the result is that the
s...
Review
xCP Pattern Library 30
5 Review
5.1 Category Overview
The purpose of a review is to make sure that the outcome of t...
Review
xCP Pattern Library 31
• an audit trail
• a customer call
• a Case Management methodology
What are the review crite...
Review
xCP Pattern Library 32
a sufficient level of quality has been reached. Examples of the effect a review can have on ...
Review
xCP Pattern Library 33
5.4 Solution Pattern 1: Sequential Review
5.4.1 Context
This pattern occurs when case inform...
Review
xCP Pattern Library 34
2. Identify the criteria against which the review is to be performed. Provide instructions
t...
Review
xCP Pattern Library 35
Figure 5–4 Iterative sequential review
Sometimes the iterative review is restricted to a fix...
Review
xCP Pattern Library 36
Figure 5–5 Sequential review with delegation
The issues concerning patterns of delegation ar...
Review
xCP Pattern Library 37
5.5 Solution Pattern 2: Parallel Review
5.5.1 Context
In some situations, it may be necessar...
Review
xCP Pattern Library 38
3. Specify the criteria against which the review is to be performed. Provide instructions
on...
Communicate
xCP Pattern Library 39
6 Communicate
6.1 Category Overview
Most cases require some form of communication betwe...
Communicate
xCP Pattern Library 40
6.2.1 Solution patterns in this category
The following solution patterns are defined wi...
Communicate
xCP Pattern Library 41
6.3 Solution Pattern 1: Send External Communication
6.3.1 Context
It is often necessary...
Communicate
xCP Pattern Library 42
Figure 6–1 Outgoing email
Once the user presses the Send button, the system sends an em...
Communicate
xCP Pattern Library 43
Figure 6–3 Custom generated document
Communicate
xCP Pattern Library 44
6.3.5 Variations
• Send a reply to received external communications.
• Generate custom ...
Communicate
xCP Pattern Library 45
6.5 Solution Pattern 3: Document Signature
6.5.1 Context
This particular pattern is a v...
Communicate
xCP Pattern Library 46
6.6 Solution Pattern 4: Formal Internal Communication
6.6.1 Context
Case workers intera...
Communicate
xCP Pattern Library 47
3. Notes
Figure 6–7 Case notes
Notes are comments entered by case workers and provide a...
Communicate
xCP Pattern Library 48
6.7 Solution Pattern 5: Informal Collaboration
6.7.1 Context
Case Workers complete most...
Communicate
xCP Pattern Library 49
This is incorporated into the Grants Management application as a threaded
discussion, a...
Close Case
xCP Pattern Library
50
7 Close Case
7.1 Overview
After a case is finished it needs to be closed. In order to en...
Close Case
xCP Pattern Library 51
7.3 Solution patterns in this category
The following solution patterns are defined withi...
Close Case
xCP Pattern Library 52
7.4 Solution Pattern 1: Case Data Archival
7.4.1 Context
All cases contain persistent da...
Close Case
xCP Pattern Library 53
7.5 Solution Pattern 2: Case Disposition
7.5.1 Context
When a case is closed, there is a...
Case Policies
xCP Pattern Library 54
8 Case Policies
8.1 Overview
Many solution patterns depend on establishing policies f...
Case Policies
xCP Pattern Library 55
• What quality metrics are tracked for case management?
These questions affect the de...
Case Policies
xCP Pattern Library 56
8.4 Solution Pattern 1: Case Access Control
8.4.1 Context
Some cases are linear and t...
Case Policies
xCP Pattern Library 57
8.5 Solution pattern 2: Performer Assignment
8.5.1 Context
Throughout the life of a c...
Case Policies
xCP Pattern Library 58
• the case owner
• the manager of the case owner
• the system owner
• the support cas...
Case Policies
xCP Pattern Library 59
8.6 Solution pattern 3: Information Access Control
8.6.1 Context
Information Access C...
Case Policies
xCP Pattern Library 60
worker is no longer permitted to change certain data fields. Static access is easy to...
Case Policies
xCP Pattern Library 61
Following is a simple example of the table suggested in item 5:
Information Resource ...
Case Policies
xCP Pattern Library 62
8.7 Solution pattern 4: Task Delegation & Reassignment
8.7.1 Context
In some cases, a...
Case Policies
xCP Pattern Library 63
Figure 8–1 Delegation without feedback Figure 8–2 Delegation with feedback
Does the s...
Case Policies
xCP Pattern Library 64
8.8 Solution pattern 5: Business Logging
8.8.1 Context
A business log is similar to a...
Case Policies
xCP Pattern Library 65
What is the access policy of the business log? One issue of policy is which business
...
Data Model
xCP Pattern Library 66
9 Data Model
9.1 Category Overview
Case management solutions require facts, observations...
Data Model
xCP Pattern Library 67
• Place
• Application
What data is needed for systems to make appropriate decisions? Som...
Data Model
xCP Pattern Library 68
Example:
Consider a grant application process in which a formal review is required whene...
Data Model
xCP Pattern Library 69
9.3 Solution patterns in this category
There are three solution patterns within the Data...
Data Model
xCP Pattern Library 70
9.4 Solution pattern 1: Model Persistent Process Data
9.4.1 Context
Business entities, s...
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
xCP Pattern Library 3.3
Upcoming SlideShare
Loading in …5
×

xCP Pattern Library 3.3

1,088 views

Published on

Published in: Software, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,088
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
64
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

xCP Pattern Library 3.3

  1. 1. xCP Pattern Library v3.3 EMC Corporation Corporate Headquarters: Hopkinton, MA 01748–9103 1–508–435–1000 www.EMC.com
  2. 2. 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
  3. 3. Executive Summary xCP Pattern Library 3 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
  4. 4. Executive Summary xCP Pattern Library 4 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
  5. 5. Basic Concepts xCP Pattern Library 5 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)
  6. 6. Basic Concepts xCP Pattern Library 6 • 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. .
  7. 7. Basic Concepts xCP Pattern Library 7 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 Manage Initiate Case Close Case Case Policies External Interfaces Monitoring Data Model SolutionPattern 1 CurrentActivity Monitoring Solution Pattern 2 Historical Reports Solution Pattern 3 ManagingbyException Solution Pattern 4 PublishingMonitoring
  8. 8. Basic Concepts xCP Pattern Library 8 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:
  9. 9. Basic Concepts xCP Pattern Library 9 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 Data Structures User-Oriented Process-Oriented Data-Oriented Operational Administra- tion Solution Pattern Design Pattern Solution Pattern Category Design Pattern Category 2Design Pattern Category 1 Design Pattern
  10. 10. Basic Concepts xCP Pattern Library 10 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. InitiateProcess Initiate process from document received via SMTP
  11. 11. Initiate Case xCP Pattern Library 11 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?
  12. 12. Basic Concepts xCP Pattern Library 12 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
  13. 13. Basic Concepts xCP Pattern Library 13 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.
  14. 14. Basic Concepts xCP Pattern Library 14 • 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
  15. 15. Basic Concepts xCP Pattern Library 15 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. 3.5.2 Business Value 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.
  16. 16. Basic Concepts xCP Pattern Library 16 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. 3.6.2 Business Value 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.
  17. 17. Basic Concepts xCP Pattern Library 17 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. 3.7.2 Business Value 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.
  18. 18. Manage xCP Pattern Library 18 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 Initiate Case Case Work
  19. 19. Manage xCP Pattern Library 19 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
  20. 20. Manage xCP Pattern Library 20 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. 4.4.2 Business Value 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.
  21. 21. Manage xCP Pattern Library 21 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).
  22. 22. Manage xCP Pattern Library 22 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). 4.5.2 Business Value 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
  23. 23. Manage xCP Pattern Library 23 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.
  24. 24. Manage xCP Pattern Library 24 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. 4.5.7 Business Value 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.
  25. 25. Manage xCP Pattern Library 25 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.
  26. 26. Manage xCP Pattern Library 26 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. 4.6.2 Business Value 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.
  27. 27. Manage xCP Pattern Library 27 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.
  28. 28. Manage xCP Pattern Library 28 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. 4.7.2 Business Value 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.
  29. 29. Manage xCP Pattern Library 29 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.
  30. 30. Review xCP Pattern Library 30 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
  31. 31. Review xCP Pattern Library 31 • 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
  32. 32. Review xCP Pattern Library 32 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
  33. 33. Review xCP Pattern Library 33 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. 5.4.2 Business Value 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? Write Proposal Department Head Review Director Review
  34. 34. Review xCP Pattern Library 34 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:
  35. 35. Review xCP Pattern Library 35 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.
  36. 36. Review xCP Pattern Library 36 Figure 5–5 Sequential review with delegation The issues concerning patterns of delegation are addressed in the Case Policy category.
  37. 37. Review xCP Pattern Library 37 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. 5.5.2 Business Value 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.
  38. 38. Review xCP Pattern Library 38 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.
  39. 39. Communicate xCP Pattern Library 39 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.
  40. 40. Communicate xCP Pattern Library 40 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
  41. 41. Communicate xCP Pattern Library 41 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. 6.3.2 Business Value 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.
  42. 42. Communicate xCP Pattern Library 42 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:
  43. 43. Communicate xCP Pattern Library 43 Figure 6–3 Custom generated document
  44. 44. Communicate xCP Pattern Library 44 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). 6.4.2 Business Value 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.
  45. 45. Communicate xCP Pattern Library 45 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. 6.5.2 Business Value 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).
  46. 46. Communicate xCP Pattern Library 46 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. 6.6.2 Business Value 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.
  47. 47. Communicate xCP Pattern Library 47 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
  48. 48. Communicate xCP Pattern Library 48 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. 6.7.2 Business Value 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
  49. 49. Communicate xCP Pattern Library 49 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.
  50. 50. Close Case xCP Pattern Library 50 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.
  51. 51. Close Case xCP Pattern Library 51 7.3 Solution patterns in this category The following solution patterns are defined within the Close category. • Case Data Archival • Case Disposition
  52. 52. Close Case xCP Pattern Library 52 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. 7.4.2 Business Value 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.
  53. 53. Close Case xCP Pattern Library 53 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. 7.5.2 Business Value 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)
  54. 54. Case Policies xCP Pattern Library 54 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?
  55. 55. Case Policies xCP Pattern Library 55 • 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.
  56. 56. Case Policies xCP Pattern Library 56 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. 8.4.2 Business Value 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.
  57. 57. Case Policies xCP Pattern Library 57 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. 8.5.2 Business Value 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:
  58. 58. Case Policies xCP Pattern Library 58 • 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.
  59. 59. Case Policies xCP Pattern Library 59 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. 8.6.2 Business Value 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
  60. 60. Case Policies xCP Pattern Library 60 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
  61. 61. Case Policies xCP Pattern Library 61 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
  62. 62. Case Policies xCP Pattern Library 62 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. 8.7.2 Business Value 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.
  63. 63. Case Policies xCP Pattern Library 63 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.
  64. 64. Case Policies xCP Pattern Library 64 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. 8.8.2 Business Value 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.
  65. 65. Case Policies xCP Pattern Library 65 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.
  66. 66. Data Model xCP Pattern Library 66 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
  67. 67. Data Model xCP Pattern Library 67 • 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
  68. 68. Data Model xCP Pattern Library 68 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
  69. 69. Data Model xCP Pattern Library 69 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
  70. 70. Data Model xCP Pattern Library 70 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. 9.4.2 Business Value 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

×