the case for cm

Emily Burns, Pegasystems

Creating a “Case” Layer:Using Dynamic Case Management to Foster Agility and Improve End-user Effectiveness

February 24th, 2011

2© 2011 Pegasystems Inc.

Agenda

• What is a Case?• The imperative for a “Case Layer”• Creating the Case Layer

• Cases and Processes• Subcases vs. Process Components

• Benefits of the Case Layer• Demo• Summary


Case Definition

A case is the coordination of multiple tasks–planned or

unplanned – and associated content, towards a concrete

objective or goal.Cases are dynamic, and respond to and generate

events.


Without a Case Layer…

Individual, “atomic,” pieces of work are managed separately, without

context

Case: Vehicle Damage

Claim (for 3rd party)

Case: Vehicle Damage Claim (insured)

Case: Bodily Injury

Claim (insured)


A Case Layer Allows you to Manage All of the work for a given case in a holistic manner

Case: Policy holder submits

claim in at-fault accident

Obtain police report

Site visit for verification

Interview parties

Interview Insured

Interview witnesses

Subcase 1: Bodily injury to

insured

Request submission of hospital bills

Obtain physician statement

Subcase 2: Vehicle

Damage Claim for 3rd party

Subcase 3: Vehicle

Damage Claim

Site visit for initial

assessment of damage

Obtain damage estimate from repair shop

A case layer allows you to easily bring together

related work to improve case handling and

outcomes

• All work, including ad hoc work• All work, regardless of who or what

is performing it

Manage the All of the Case

• Aware of all other work associated with the case

• Able to manage all work for a case—structured and unstructured–from the same system

Allows “Case workers” to work more effectively

• Case types can be re-used in other case types

• Case types can be specialized to quickly extend the application

Fosters re-use and agility


Capturing Relationships: The Key to Delivering Successful Case Apps

• Enabling technology: Case Management• Required for holistic case management• Provides foundation for including ad hoc work

Hierarchical Relationships

• Enabling Technology: BPM• Defines the progression of work

Temporal Relationships

• Enabling Technology: Business Rules Engine• Allows you to set conditions for how the work is

accomplished, from process flow, to UI to access

Conditional Relationships

Case Applications must allow designers to easily, and explicitly define these three key types of relationships. Anything less will be incomplete and inflexible.


Creating The Case Layer

Cases

Processes

ServicesRules

Rules

Rules Rules

Rules

Rules

Rules

Rules

RulesConsume

Consume


Cases and ProcessesA “case” is the work,

“Process” is the path it takes to be completed

Process

Process

Process


Cases and ProcessesCase A

Case B

Case C

Case D

P1

P4

P5

P7 P3

P3

P6

P3P2

Cases exist distinct from processes

•represented by the process diagram on the case folder)

All cases have a process, even if the process is very simple

Any case may have multiple subcases

•other than the primary process, these will typically be process components

Any case can have multiple processes run on it simultaneously

•ad hoc•automatically (procedurally or declaratively)

Subcases and processes for a given case may be invoked…


Subcase or Process, That is the QuestionSubcases… Process (components)…

Are discrete pieces of work and could reasonably be performed without the top-level case

Would never occur if the case withwhich they are associated was not created. (e.g. you wouldn’t refund money to someone if they hadn’t created a “return” case).

May not have a known process, other than being opened and staying open until someone resolves them. May spin off other subcases to handle exceptions

Are typically invoked once it is clear that they are needed, and proceed down a clear path, rarely if ever invoking exceptions

Are often collaborative, and need multiple people or systems to be working on them in concert

Do not allow for multiple people to work on them in parallel

Provide better visibility to the work as a distinct object

Allow you to do a lot on a given piece of work without “cluttering” with an excess of subcases.


Subcase or Process, Examples

Subcase Example Process Component

Subcase: Devilled eggs Devilled egg fillingParent case: “First course” Associated with case: Devilled eggsWhy a subcase? I could reasonably make devilled eggs by themselves

Why it’s a process component? I would never make devilled egg filling if I weren’t making deviled eggs

Subcase Example Process ComponentSubcase: Item return Process: Process refundParent case: Purchase Item Associated with case: item returnWhy a subcase? I might reasonably handle returns without tying them to the original purchase.

Why it’s a process component? I would never process a refund if an item weren’t being returned

Nota Bene: These are guidelines, there are no restrictions that force you to use one or the other. You have flexibility.


Key Supporting Functionality

• Ability to define for every case, and all its subcases and tasks all of the necessary elements (content, instantiation, roles, etc.) and the relationships between them.

Design-Time: Explicit support for creating the Case layer

• Allows users (with permissions) to view a case and all its nested subcases and tasks, as well as the associated content, users, roles and subjects.

• Users can add pre-defined ad hoc work, or can add new ad hoc work to cases.• UI allows for case-type specific definition of UI—at any level

Run-Time: Out-of-the-Box UI for viewing and working on cases

• Ad hoc work added to cases can be saved back to the case type, as an update to the case, a new version of that case, or as an entirely new case type.

• Allows for capture of ad hoc work into the process in a passive, iterative manner. • Limited-use, role-based privilege (i.e. no running amok)

Run-Time to Design-Time: “Design by Doing”


Benefits of a Case Layer: Innovation Comes Standard

• Working with the full context of the work being performed on the case

Your users are more effective

• Rapidly specialize or enhance applications to maintain an innovative market stance

• Built-in re-use to foster agility and ease management

A Case layer is a differentiation layer

• “Design by Doing” allows users to capture innovation in real-time

Built-in tools to capture innovation


Demo


Getting to the Case Designer


Creating the Case Layer in the Case Designer


Adding New or Re-using Existing Case Types


Other Things to do from the Case Designer


Linking Case and Process


One of the Processes (Autoclaim 2) for “FNOL;”


User’s Caseload View


Case Details View: Vehicle Damage Subcase


Summary

• A case is the work that needs to be done• A process is the path it takes during completion

Cases exist independent of processes

• Easy to create and visualize case relationships• Easy to re-use case types• Use processes as components to be called and re-used as needed

A case layer provides a powerful tool for agility

• Depends on how tightly coupled the work is to its “parent” case

When to user subcases, when to use process components

• Case designer• OOTB portal for viewing and managing cases• Design-by-doing for constant innovation

Key supporting functionality in Pega Case Management for creating a case layer


Join the Conversation!

Dynamic Case Management Forum

http://www.pega.com/forums/dynamic-case-management

25 © 2011 Pegasystems Inc.

• Additional resources on the PDN• New CM articles now posted• View an archive of this presentation (+1 day)

• Questions or ideas? Email us.• Future session topics: [email protected]• Product questions: [email protected]

• Please take the webinar exit survey.

mailto:[email protected]�

mailto:[email protected]�

the case for cm

Documents