BPM Solution Implementation Guide

ibm.com/redbooks Redpaper
Front cover
BPM Solution
Implementation Guide
John Bergland
Luc Maquil
Kiet Nguyen
Chunmo Son
Practical approach to rapid BPM
solution delivery
Business-driven BPM solution
implementation
Complements existing
business partner and
customer solution
methodologies

International Technical Support Organization
BPM Solution Implementation Guide
October 2009
REDP-4543-00

© Copyright International Business Machines Corporation 2009. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
First Edition (October 2009)
This edition applies to WebSphere Business Modeler v. 6.1.2 and WebSphere Business Monitor, Version 6,
Release 2, Modification 0 (product number 5724M2400)
This document created or updated on January 13, 2010.
Note: Before using this information and the product it supports, read the information in “Notices” on
page ix.

iii
Contact an IBM Software Services Sales Specialist
Our highly skilled consultants make it easy for you to design, build, test and deploy solutions, helping
you build a smarter and more efficient business. Our worldwide network of services specialists wants you
to have it all! Implementation, migration, architecture and design services: IBM Software Services has
the right fit for you. We also deliver just-in-time, customized workshops and education tailored for your
business needs. You have the knowledge, now reach out to the experts who can help you extend and
realize the value.
For a WebSphere services solution that fits your needs, contact an IBM Software Services Sales Specialist:
ibm.com/developerworks/websphere/services/contacts.html
architectural knowledge, skills, research and development . . .
that's IBM Software Services for WebSphere.
Start SMALL, Start BIG, ... JUST START

iv BPM Solution Implementation Guide

© Copyright IBM Corp. 2009. All rights reserved. v
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
The team who wrote this paper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Chapter 1. Introduction to the BPM Prescriptive Guide to Solution Implementation. . 1
1.1 Scope and focus of this IBM Redpaper publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Introduction to Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 The BPM vision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Characteristics of BPM Success. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Introduction to the BPM Prescriptive Guide to Solution Implementation. . . . . . . . . . . . . 6
1.3.1 Understanding the goals, objectives, and intended audience of the
Prescriptive Guide to Solution Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Roles involved with the BPM Solution Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.1 Business roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.2 Technical roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5 Tools from IBM BPM Suite of products used in this solution. . . . . . . . . . . . . . . . . . . . . 13
1.5.1 Business Leader Widgets: WebSphere Business Publishing Server . . . . . . . . . . 14
1.5.2 WebSphere Business Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.3 WebSphere Business Monitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6 Introduction to the health care demo scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6.1 High level business goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6.2 Overview of the overall claims process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6.3 Interacting with the process through the business space . . . . . . . . . . . . . . . . . . . 18
1.6.4 Monitoring and managing the performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.6.5 Modifications to be made to the process to address business goals . . . . . . . . . . 21
1.7 Key assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Chapter 2. Discover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1 Overview of steps in the Discover phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.1 Activities within each task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.2 Tooling used for mapping strategic objectives, capabilities, and process
maps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2 Reviewing the business challenges, goals, and strategy for
the health care scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.1 Identifying business challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.2 Defining business goals and measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.3 Creating high-level capability maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.4 Creating high-level process maps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Chapter 3. Storyboarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1 Overview of steps in Storyboarding phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 Capture and refine the current state process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.1 Import high level process diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.2 Refine process model after import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

vi BPM Solution Implementation Guide
3.2.3 Add business item to process flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3 Add roles and cost to as-is process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.1 Adding roles to as-is process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.2 Add cost information to As-Is process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4 Examine alternate ROI scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4.1 Baseline Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.2 Issue 1: Efficiency of manual tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4.3 Issue 2: Efficiency of semi-automatic tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.4.4 Changes to cost table and second simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.4.5 Issue 3: Cost of service intake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.4.6 Issue 4: Cost of claim adjudication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.5 Define the future state scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.5.1 Implementation of human tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.5.2 Implementation of WebServices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.5.3 Implementation of business rules tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.5.4 Add additional Task “Notify Rejection to customer” . . . . . . . . . . . . . . . . . . . . . . . 68
3.5.5 Adapt control flow ratios to reflect insertion of business rules tasks. . . . . . . . . . . 69
3.5.6 Run final simulation for validation purposes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.5.7 Future improved business process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.6 Identify business rules content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.7 Generation and validation of mockup forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.8 Validation of mockup forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.9 Definition of control points to prepare experience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.9.1 The Balanced Scorecard approach to ensure strategical alignment. . . . . . . . . . . 78
3.9.2 The Input, Output, Process, Outcome Model to cover process life cycle . . . . . . . 79
3.10 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Chapter 4. Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1 Objective of the Experience phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.2 Overview of steps in the Experience process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.2.1 Activities within each task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.3 Reviewing the goals of Experience within the context of the health care scenario. . . . 84
4.4 Add operational characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4.1 Defining business rule tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4.2 Identifying business rule candidates from the scenario process. . . . . . . . . . . . . . 86
4.4.3 Steps to create a business rule (Provider Selection) . . . . . . . . . . . . . . . . . . . . . . 88
4.4.4 Defining human tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.5 Define Constructs for execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.5.1 Adding services to deployable applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.6 Elaboration on KPIs and SLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.6.1 Setting the context within the scenario for Health Care Insurance Co. ABC . . . 103
4.6.2 Steps to define the task duration KPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.6.3 Steps to Define the Total Claim KPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.7 Refine forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.7.1 Automatic generation of forms for human tasks . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.7.2 Customizing the appearance of the form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.8 Refine the process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.8.1 Interactive process design (IPD). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.8.2 Testing with the real life scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.9 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Chapter 5. Manage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.1 Goals of the Manage phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Contents vii
5.1.1 Identifying the overlap between the Experience phase and the Manage
phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.2 What to manage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.3 Introduction to the Business Space. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
5.4 Empowering the user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.4.1 Customizing the user experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.4.2 Assigning Access Rights: Why they are beneficial and how to assign them . . . 142
5.5 Monitoring the Health Insurance Claim Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
5.6 Manage in real-time using KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.6.1 Review of the KPIs to be monitored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.6.2 Setting up the KPI widget report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
5.6.3 Setting thresholds and spotting bottlenecks in KPI Reports . . . . . . . . . . . . . . . . 158
5.6.4 Using the KPI widget reports to identify bottlenecks. . . . . . . . . . . . . . . . . . . . . . 158
5.6.5 Reviewing the human task widget to analyze bottlenecks . . . . . . . . . . . . . . . . . 160
5.6.6 Dimension reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
5.6.7 KPI administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
5.7 Optimize workload assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
5.7.1 Objective of optimizing workload assignments . . . . . . . . . . . . . . . . . . . . . . . . . . 176
5.8 Govern changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
5.8.1 Governing change within the context of Health Insurance ABC. Co. . . . . . . . . . 184
5.9 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Chapter 6. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.1 Objectives of the steps of the deployment phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.2 Perform IT assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
6.2.1 Prepare export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
6.2.2 Exporting WebSphere Business Modeler artifacts . . . . . . . . . . . . . . . . . . . . . . . 192
6.2.3 Importing Project Interchange into WebSphere Integration Developer. . . . . . . . 196
6.2.4 Loading interface files into WebSphere Service Registry and Repository . . . . . 201
6.2.5 Mediation modules and business integration modules . . . . . . . . . . . . . . . . . . . . 205
6.2.6 Assembling a Web service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
6.2.7 Integrate with WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
6.2.8 Integrate with JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
6.2.9 Integrate with JCA adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
6.3 Generate and customize monitor models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
6.4 Assemble user experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
6.4.1 Automatic generation of forms for human tasks . . . . . . . . . . . . . . . . . . . . . . . . . 227
6.4.2 Customizing the appearance of the form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
6.4.3 Advanced Lotus forms editing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
6.5 Test applications in Universal Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
6.5.1 Using the integration test client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
6.5.2 Using component testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
6.6 Prepare production environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
6.7 Deploy applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
6.7.1 Generate applications in WebSphere Integration Developer . . . . . . . . . . . . . . . 237
6.7.2 Implementation of an automated build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
6.7.3 Deployment of applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
6.8 Monitor health of process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
6.8.1 Failed event manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
6.8.2 Service Integration Bus Browser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
6.8.3 Business Space health widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
6.8.4 Tivoli Performance Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

viii BPM Solution Implementation Guide
Appendix A. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
How to get Redbooks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

© Copyright IBM Corp. 2009. All rights reserved. ix
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs.

x BPM Solution Implementation Guide
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries, or both. These and other IBM trademarked terms are
marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US
registered or common law trademarks owned by IBM at the time this information was published. Such
trademarks may also be registered or common law trademarks in other countries. A current list of IBM
trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
CICS®
Domino®
FileNet®
IBM®
IMS™
Lotus Notes®
Lotus®
Notes®
Rational®
Redbooks®
Redpaper™
Redbooks (logo) ®
Tivoli®
WebSphere®
The following terms are trademarks of other companies:
FileNet, and the FileNet logo are registered trademarks of FileNet Corporation in the United States, other
countries or both.
Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation and/or
its affiliates.
Interchange, and the Shadowman logo are trademarks or registered trademarks of Red Hat, Inc. in the U.S.
and other countries.
SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other
countries.
Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other
countries, or both.
Microsoft, and the Windows logo are trademarks of Microsoft Corporation in the United States, other
countries, or both.
Other company, product, or service names may be trademarks or service marks of others.

© Copyright IBM Corp. 2009. All rights reserved. xi
Preface
This IBM® Redpaper™ publication provides a practical bridge toward achieving successful
BPM solution implementation within 60 days. It is based on an approach using phases and
specific activities outlined in the IBM Business Process Management Prescriptive Guide to
Solution Implementation. To provide a realistic context for the solution, we incorporate the
process, business model, and specific scenario from a health care provider. The context is
based on a live code demo that consists of a fictitious application based on a customer
scenario, using the approach in the IBM Business Process Management Prescriptive Guide
to Solution Implementation to assemble the solution. This paper discusses how to analyze,
model, and manage the processes within this realistic health care scenario.
The team who wrote this paper
This IBM Redpaper publication was produced by a team of specialists from around the world
working at the International Technical Support Organization, Poughkeepsie Center.
John Bergland is a project leader at the ITSO, Cambridge Center. He
manages projects that produce IBM Redbooks® publications that focus on
IBM WebSphere® and Lotus® software technology. Before joining the ITSO
in 2003, John worked as an IT Specialist with IBM Software Services for
Lotus, specializing in Lotus Notes® and Domino® messaging and
collaborative solutions. He holds a Master of Business Administration (MBA)
degree and a Master of Science (MS) degree in information technology from
Boston University.
Luc Maquil is a Technical Sales Specialist for WebSphere based in
Luxembourg and covering SouthWest Europe. Luc joined the Benelux team in
2007. Luc has extensive experience in Business Process Management
including methodology, architecture, performance, and implementation best
practices on IBM Business Process Management Solutions. Luc advises
customers from the telecommunications, public, and financial sectors. Luc
started working at IBM Research and Development in Böblingen, Germany in
2001, part of the Development team of Business Process technologies.
Between 2005 and 2007 Luc was a senior consultant within the lab services
team based in Böblingen, Germany and advising customers all across
Europe, bridging between deep lab experience and customer solutions.
Kiet Nguyen is an IT Solutions Architect and Software Engineer at the
WebSphere Business Monitor Lab in RTP, North Carolina, USA. He has
extensive application service development experience on multi-platform
backgrounds. He currently enables and advocates external and internal
customers worldwide in the adoption of the IBM BPM Monitor product suite to
manage and optimize their business processes. His areas of expertise are in
advanced deployment, development, and integration of SOA/BPM solutions.

xii BPM Solution Implementation Guide
Chunmo Son is a Senior IT Specialist in the United States, working with
customers in WebSphere BPM suites and also in WebSphere Infrastructure
solutions including App Server, Virtual Enterprise, and Cloudburst. He joined
IBM in 1999 and has spent most of his career in the WebSphere technical
sales field. He also worked at Silicon Valley Lab in San Jose, California. His
focus in BPM and WebSphere is helping customers to adopt, develop, and
implement a solution by conducting proof of concepts, workshops, and
technical assistance for major industries throughout the United States.
Thanks to the following people for their contributions to this project:
Akshay Sabhikhi
Program Director, BPM & Connectivity, IBM Software Group, Application and Integration
Middleware Software
IBM, Austin, TX
Michael A. Gilfix
Architect, WebSphere BPM & Connectivity "Black Belt" Team, IBM Software Group,
Application and Integration Middleware Software
IBM, Austin, TX
Jasmine Basrai
Sr. Product Manager, WebSphere Business Modeler and Monitor, IBM Software Group,
IBM, California
Genevieve Van Den Boer
Senior Managing Consultant - Software Services for WebSphere, IBM Software Group,
IBM, Canada
Richard Osowski
Software Engineer, IBM Software Group, Application and Integration Middleware Software,
IBM, Durham, NC
Special thanks to the following technical reviewers during this effort:
Keith Wright (IBM Lexington)
Andy (Anthony) Catts
Mahesh Sharma (IBM Burlingame)
Danae Chu
Tom Johnson (IBM Chicago)
Luisa Lopez de Silanes Ruiz
Become a published author
Join us for a two- to six-week residency program! Help write a book dealing with specific
products or solutions, while getting hands-on experience with leading-edge technologies. You
will have the opportunity to team with IBM technical professionals, Business Partners, and
Clients.
Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you
will develop a network of contacts in IBM development labs, and increase your productivity
and marketability.
Find out more about the residency program, browse the residency index, and apply online at:

Preface xiii
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our papers to be as helpful as possible. Send us your comments about this paper or
other IBM Redbooks publications in one of the following ways:
Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
Send your comments in an e-mail to:
redbooks@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400

xiv BPM Solution Implementation Guide

© Copyright IBM Corp. 2009. All rights reserved. 1
Chapter 1. Introduction to the BPM
Prescriptive Guide to Solution
Implementation
The goal of Business Process Management (BPM) is to improve your organization’s ability to
model, assemble, deploy, and manage your processes and improve your business. This IBM
Redpaper publication provides a practical bridge toward achieving successful BPM solution
implementation within 60 days. It is based on an approach using phases and specific
activities outlined in the IBM Business Process Management Prescriptive Guide to Solution
Implementation. To provide a realistic context for the solution, we incorporate the process,
business model and specific scenario from a health care provider. The context is based on a
live code demo which consists of a fictitious application based on a customer scenario, using
the approach in the IBM Business Process Management Prescriptive Guide to Solution
Implementation to assemble the solution. This paper discusses how to analyze, model, and
manage the processes within this realistic health care scenario.
This chapter establishes a foundation for implementing a BPM Solution by introducing the key
characteristics of a successful BPM initiative. It reviews the fundamental relationship between
BPM and a service-oriented architecture (SOA), while introducing the IBM BPM methodology,
the IBM Business Process Management (BPM) Enabled by SOA Method. It also introduces
the key phases and activities from the IBM Business Process Management Prescriptive
Guide to Solution Implementation, which is used to implement the health care scenario BPM
solution.
1

2 BPM Solution Implementation Guide
1.1 Scope and focus of this IBM Redpaper publication
The goal of the paper is to provide a definitive and practical guide to BPM Solution
Development. As a starting point, we structure our approach using the IBM asset IBM
Business Process Management Prescriptive Guide to Solution Implementation as a
framework and specific reference point. We proceed through the phases of building a BPM
solution using a live, working demo based on a fictitious health care insurance company to
provide specific and practical context to the approach. By doing this we intend to make the
IBM Business Process Management Prescriptive Guide to Solution Implementation more
consumable, less complex, and more practical. Accordingly, this paper is not exclusively
focused on only the detailed steps outlined in the IBM Business Process Management
Prescriptive Guide to Solution Implementation, nor is it limited to only serving as a
step-by-step guide on how to build the health care demo. It serves as a practical bridge,
illustrating how to begin with the approach provided in the Prescriptive Guide to Solution
Implementation, and apply this toward the practical solution demonstrated in the demo for the
health care insurance company. Figure 1-1 illustrates the scope and positioning of this paper
as a bridge from the Prescriptive Guide to Solution Implementation toward implementing the
solution shown in the working example for Health Insurance Company ABC.
Figure 1-1 Visual positioning of this paper
Objectives
The objectives within this paper are as follows:
Illustrate a Business Driven solution.
As we describe the approach for developing the solution in this paper, we emphasize how
your organizations’ underlying business needs and processes are identified, mapped,
analyzed and simulated. We discuss how IBM WebSphere BPM tools provide the
capability for modeling, simulating and ultimately monitoring and managing the efficiency
of your business solution, but it is the business need at the core of the strategic solution.
Provide a practical context which guides you from theoretical, prescribed approach
outlined in the IBM Business Process Management Prescriptive Guide to Solution
Implementation, and implementing this into a realistic solution. (See 1.3, “Introduction to
the BPM Prescriptive Guide to Solution Implementation” on page 6 for more details on the
focus and objectives of this prescriptive guide.)
This paper describes which tools from the IBM BPM Toolsuite are used, and gives you the
guidance as a business analyst on how you can use these tools to model and develop a
solution. This is all done using a realistic context from a fictitious health care company, and
it is all based on a working, live code demo.
Demo
(Live Code/
Working
Example)
Scope of Redpaper
To serve as a bridge and a
pragmatic guide on how to
approach/build a realistic
scenario using the
Health Insurance Company ABC
examples
BPM
Prescriptive
Guide
Presentation
(Framework for
approaching
Solution)

Chapter 1. Introduction to the BPM Prescriptive Guide to Solution Implementation 3
Illustrate the power and flexibility of the core tools used from the IBM BPM suite.
The IBM BPM tools we highlight in this paper demonstrate how you can discover, analyze,
modify, and manage your business process for continued improvement. We discuss
specific capabilities in individual tools with the emphasis being placed on how the tools are
well-integrated to drive you toward a comprehensive solution. This is not a single step
process, but one that allows for iterative improvements and adaptability as business needs
change in the future.
After the solution is modeled, you can simulate best case and worst case scenarios to
determine the best path to greater return on investment (ROI). As you model and simulate
different scenarios, you can refine the process and monitor the results, all before deploying
the solution into a live production environment. This allows for flexibility and a better
understanding of the impact of process improvements, without the cost and complexity of
making these changes in a production environment. Much of this initial simulation is
demonstrated in Chapter 3, “Storyboarding” on page 35.
1.2 Introduction to Business Process Management
BPM is most often associated with the life cycle of a business process. The process life cycle
spans identifying and improving processes that deliver business capability to deploying and
managing the process when it is operational. What is often forgotten about is managing
process performance after a process is operational. In a way, this is probably the most
important phase of the life cycle. After a business process is deployed, it must be managed.
To manage the business process, you must have visibility into process performance. When a
process is no longer meeting its performance goals, it is time to jump back in the life cycle to
assess the root cause of the performance problem and to look for improvement opportunities.
What is the role of IT in this scenario?
This paper discusses a business driven solution. That is, one designed and analyzed
primarily by a business analyst and key business stakeholders, representing the line of
business (LOB). The activities and steps demonstrated throughout this paper are
performed primarily through the business analyst perspective.
With this in mind, the reality is that IT is a critical partner in achieving a BPM solution. They
need to do the technical work of integrating the solution with the infrastructure. In many
cases, they are actually participants in the business-driven design that was done earlier in
the process. For example, an enterprise architect may be needed to work with a business
stakeholder and refine the process sufficiently for deployment.
IT has development responsibilities, while working closely with the business analysts to
realize the technical solution, based on the business needs. The IT team would be
responsible for installing and configuring the underlying IBM BPM Suite tools as a
foundation to begin working with the tools. In some specific tasks, such as the IPD phase
(direct deployment process) described in Chapter 4, “Experience” on page 81, or tasks
related to the larger scale roll-out of the solution in Chapter 6, “Deployment” on page 187,
we make it clear that this is primarily an IT responsibility.
This solution illustrates how the business is the primary driver, supported by IBM
technology.

1.2.1 The BPM vision
Dramatic increases in computing power are leading to new approaches and smarter
solutions, in which flexible, intelligent, and dynamic infrastructures can be applied to address
current and future opportunities. Businesses can instrument activities so that they can be
measured and improved, interconnect across silos, partners, and the broader value chain,
and intelligently derive insight from an interconnected world of devices, systems, and
businesses.
BPM manifests itself in numerous ways in business environments. Typical BPM solutions are
all around us:
Supply chain processes for inventory management
Self service portals for managing employee benefits
Financial processes for compliance
Call center management reports for service organizations
Whether your business needs to document existing processes, define flexible policy options
to handle a broad scope of business situations, facilitate human task flows, or gather
operational details about how well the business is running, BPM is there.
As the pace of change and competition accelerates in today's challenging economic climate,
enterprises are under tremendous pressure to improve the way they do business. Leaders
from around the world are focused more than ever on the economic, social, and
environmental changes driven by global integration, where free trade agreements, the
Internet, and globalization are simultaneously making the world smaller, flatter, and smarter.
These leaders have articulated the need to deliver products and services faster, raise the
quality of what they deliver, rein in costs, grow revenues, take advantage of market
opportunities, react to unforeseen events, and see long term trends. Businesses need to be
more agile, flexible, and responsive to market demands. Regardless of how well the
enterprise runs, it needs to adapt and improve, or it will be outdone by competitors.
What is the downside of inflexible business models and siloed solutions? Production and
service outages, backlogs and process bottlenecks, supply chain disruptions, stock outs,
missed service level agreements, ineffective use of staff, poor customer satisfaction,
operational reports that provide too little too late, and the list goes on. No one wants to be the
next case study on enterprise failure.
By working smart, business achieve the agility to succeed. Overcome the restrictions of the
past by moving to an agile business model, use Web 2.0 to build interactive ecosystems to
meet the situational needs of knowledge workers, build dynamic processes that use reusable,
service-based components, and embrace the Smart SOA approach that turns applications
into reusable services.

1.2.2 Characteristics of BPM Success
The following section highlights the key characteristics of a holistic BPM infrastructure.
Choice
Business dynamics change, regardless of how well plans are thought out. But how easy is
it to modify an IT solution without a massive IT effort? The choices made today should not
limit the choices that need to be made in the future.
Agility
There are many decisions to make as processes run. The right decision is often
influenced by various factors and cannot simply be expressed as a set of conditional
if-then-else statements. The business needs to express a dynamic business policy in
terms that IT infrastructure can harness, and that the business can manage on the fly as
that policy changes.
Flexibility
Invariably, disparate departments in an enterprise often develop and grow their missions
and capabilities isolated from other departments. As these departmental silos grow, so to
do their IT systems. At some point, you realize that there is valuable information that
should be shared across departments. Enabling departments to share information reveals
business efficiencies (for example, by eliminating the need to enter duplicate data) and
provides broader business insight across the organization. But can these disparate
systems work together without costly and risky rip-and-replace initiatives?
Speed
Business no longer has the luxury of taking years to develop solutions. IT departments
require the tools to assemble solutions based on reusable assets, minimal coding, robust
integrated test facilities, and a straightforward deploy capability. Heterogeneous
environments introduce the additional challenge of integrating various hardware and
software platforms, which dare not slow down solution development.
Skills
To improve business processes, an organization cannot, and should not, rely solely on IT
resources to design, collaborate, improve, build, deploy, and monitor those processes. The
line of business (LOB) brings subject matter expertise and domain knowledge into the
definition of what the business needs (requirements), why certain needs are prioritized
higher than others (business goals), and how those needs are reflected in process
definitions (models). LOB writes the specification for the business solution, whereas IT
ensures it is implemented, tested, and deployed on a robust and scalable infrastructure.
Striking the right balance across your organization to use strengths and experiences
across both IT and LOB departments facilitates the speed and agility that you need to
succeed. LOB needs to take an active role in both defining business processes and
seeing the business results in real-time so they can react swiftly with business insight.
LOB needs tools that can be easily tailored and used, tools that provide the necessary
handoffs and integration points with the IT organization.

1.3 Introduction to the BPM Prescriptive Guide to Solution
Implementation
The IBM Business Process Management Prescriptive Guide to Solution Implementation
provides a detailed, phased approach for implementing a BPM development solution. It is not
an actual methodology, but instead serves as an approach or framework giving step-by-step
guidance for a prescribed set of activities to deliver a BPM solution into production for smaller
scale, departmental class projects within 60 days. One of the core assumptions within the
guide is that it is business-driven. That means business leaders, analysts, and users are a
key part of the approach and play a continuous role. In fact, the business analysts do a lot of
the development in the human-centric cases. The approach in the IBM Business Process
Management Prescriptive Guide to Solution Implementation covers the core products within
the IBM WebSphere BPM suite of product (including Modeler, Publishing Server, Monitor,
WPS, WID, WSRR-ALE).
1.3.1 Understanding the goals, objectives, and intended audience of the
Prescriptive Guide to Solution Implementation
As mentioned in the objectives of this paper, the approach for solution implementation within
this paper is modeled on the IBM Business Process Management Prescriptive Guide to
Solution Implementation. Accordingly, it is important to understand the goals and objectives of
the guide, together with an understanding of the intended audience.
What is it?
It provides prescriptive guidance that is simple and usable on how to use BPM products to
deliver a solution into production within 60 days.
It is focused on departmental projects that are weighted towards interactive process
design and human-centric processing scenarios.
It covers the core products within the IBM WebSphere BPM suite (Modeler, Publishing
Server, Monitor, WPS, WID, WSRR-ALE).
Business leaders, analysts and users are a key part of the method and continuously play a
role. In fact the business analysts do a lot of the development in the human centric cases.
Who are the intended users?
IBM Tech Sales, Black belt in delivering customer departmental solutions
ISSW delivering a departmental BPM solution
Business Partners working on a BPM solution implementation
Customers implementing BPM solutions
Note: You can access the IBM Business Process Management Prescriptive Guide to
Solution Implementation in either of the following ways:
Internal IBM users can access the IBM Business Process Management Prescriptive Guide
to Solution Implementation through the following Web page:
https://w3.tap.ibm.com/com.ibm.ram/assetDetail/generalDetails.faces?guid={69933
8B4-3441-CF1A-B87C-5FE235A39E66}&v=1.0&submission=false
External IBM users should refer to Appendix A, “Additional material” on page 249 for
instructions on how to download the Prescriptive Guide.

Ownership: How is this document going to be maintained?
PLM and development own this document and will update with every release
What the guide is not
It is not intended to replace GBS, business partner, or ISSW methodologies, but to feed
into those methodologies as guidance on product usage. For example, it builds upon many
of the concepts in the formal BPM Enabled by SOA Methodology. For additional
information about this methodology, refer to the IBM Redpaper publication REDP-4495,
Business Process Management Enabled by SOA, available at the following Web page:
http://www.redbooks.ibm.com/abstracts/redp4495.html
It is not intended to replace product how to guides,which go into a more detail on specific
product usage.
At the core of IBM Business Process Management Prescriptive Guide to Solution
Implementation are five phases, ultimately spanning the life cycle of solution delivery. The
phases are as follows:
Discovery
Storyboarding
Experience
Manage
Deploy
Figure 1-2 illustrates an iterative view of the first four phases, with a view of which human task
roles are involved during each of the phases.
Figure 1-2 Overview of the phases within the IBM Business Process Management Prescriptive Guide to Solution
Implementation
BPM Methodology
Business Driven Activities
Discover your business intent;
Map intent to business capabilities
and process maps; Identify and
prioritize options
Storyboard the user
interaction by capturing
and defining as-is process
and to-do processes; Mock
up forms to validate and
visualize human interactions
Experience/visualize the
solution via elaboration of
business measures and KPI’’s;
Add operational characteristics
to future state processes;
Interactively validate elaborated
processes in IT sandbox
Manage real-time performance
by empowering business users
to customize their experience,
managing KPI’’s and alerts based
on changing business conditions
Collaborate, Iterate,
Refine & Validate
Business
Analyst
Business
Users
Business
Leader
Process
Owner
Business
Analyst
Business
Analyst
Process
Owner
Business
Users
Business
Leader

The high level objectives within each phase are as follows:
Discovery: Discover your business intent
– Capture business intent
– Map business capabilities
– Create high level process maps
– Identify options/prioritization
Storyboarding: Story board the user interaction
– Capture/refine current state process; Examine alternate ROI to determine approach
– Define future state process
– Define inputs and outputs and mock up forms for human interactions
– Validate and visualize human interactions
Experience: Experience/visualize the solution
– Elaboration of business measures and KPIs
– Add operational characteristics to future state process
– Refine forms
– Interactively validate elaborated process in IT sandbox
Management: Manage & Optimize performance
– Empower business users to customize user experience
– Assign access rights; Optimize work assignments; Govern change
– Manage real time business performance, KPIs, and alerts based on changing business
conditions
– Take corrective actions against process instances
Production: Put solution into production
– Set up IT environments
– Prepare and deploy production artifacts
– Unit test solution
– Monitor health of your solution to ensure process integrity
Throughout the subsequent chapters in this paper, we use the phases, goals, and steps
identified in the IBM Business Process Management Prescriptive Guide to Solution
Implementation to approach developing the health care demo scenario.
Note: The Prescriptive Guide is primarily aimed at an initial BPM solution rollout based on
a slightly smaller scale (for example, a departmental solution which can be achieved within
a 60-day time line). So, for the sake of this paper effort, both the functional and
non-functional requirements associated with a full scale enterprise deployment into a
production environment are not covered in detail. The goal is to highlight some of the key
steps and considerations associated with a production deployment in Chapter 6,
“Deployment” on page 187, but then refer the reader to a more detailed source of
information that is specifically focused on deployment steps and related activities.

1.4 Roles involved with the BPM Solution Implementation
Within the IBM Business Process Management Prescriptive Guide to Solution
Implementation, specific roles are identified for performing tasks in the different phases of the
solution implementation. The goal of this section is to better identify these roles and their
supporting skill sets.
The primary roles referred to within the IBM Business Process Management Prescriptive
Guide to Solution Implementation involve the following aspects:
Business roles
– Business analyst/Business leader
– Subject matter expert (SME)
– Business executive
IT roles
– IT solution developer
– IT administrator
– IT architect
The descriptions in 1.4.1, “Business roles” on page 9 and 1.4.2, “Technical roles” on page 11
help clarify the skills, goals, and tasks commonly associated with each of these roles.
1.4.1 Business roles
Business analyst
Skills/Education
– Business background with no technical background
– Extremely knowledgeable of the business; usually have been with the company for
many years and have a solid understanding of the business and its goals
– Mostly senior personnel (for example, been around business for okay)
– Skilled at Office suite (for example, PowerPoint, Visio)
Goals
– Build consensus from different stakeholders on as is and to be process model
– Accurately communicate process details
– Look for opportunities to improve current business
Tasks
– Conduct SME interviews (group or 1-on-1) for input into models (as is process) and
validating to be processes
– Define detailed business requirements, models business processes, gathers
simulation data (resource costs, and so forth), assess process execution in production
– Define and refine business metrics usually done outside of Modeler (for example,
captured in MS Word or Excel)
– Manage review and iteration of current model sharing and publishing models with
SMEs; generate PDF and JPEGs to distribute
– Review models produced either on WebSphere Publisher Server or using the Business
Leader Widgets available through the following Web page:
http://www-01.ibm.com/software/solutions/smartwork/bpmblueworks/

– Provide input to test cases and training materials; can also act as a tester and trainer
– Process analysis (for example, metrics, cost benefit analysis)
– Mock up application user interface
Tools
– Skilled at Office suite (for example, PowerPoint, Visio)
– Internet Explorer
– NetMeeting?
– MS Outlook or Lotus Notes
Business executive
Skills/Education
– Extensive business background, MBA or similar
– Has a good level of understanding of technology but will call the IT department right
away if there is a problem
– Extremely knowledgeable of the business; has a solid understanding of the business
and its goals
– Mostly senior personnel (for example, been around business for a while)
– Spends a large portion of the day away from the desktop
– Device for information delivery is important (for example, reports on a Blackberry
device)
– Needs to be provided information on timely basis (regular or ad hoc)
– Engages in light exploration and prefers to get details on demand
– Uses dashboards and scorecards for at-a-glance view
– Prefers any tool that understands patterns and can predict (and suggest) what the right
information might be ahead of time
Goals
– Get the right information right now. Has no time to sift through information to find what
is relevant. If it is more than one or two clicks away, it does not exist.
– Direct the business unit. Needs to detect trends, changes, and exceptions easily. Must
communicate how they map to corporate strategy.
– Keep context. Must be able to maintain information from various sources in one context
(one place).
– Improve over last quarter. Needs up-to-the minute, focused information to measure
how the organization is doing and understand how to increase performance going
forward.
– Keep up with the numbers. Insists on knowing what is going on around and them.
Keeps a close watch on key numbers and metrics.
– Monitor key customers. Needs to know what customers need and offer it to them.
Prefers to offer them something they want before they know they want it.
– Knowing what the team is doing. Has to keep track of what happens with information
and who is accountable for what to make sure the company is getting maximum value
for their investments.

Tasks
– Monitor company results against targets through reports and dashboards.
– Keep on top of what the company is doing relative to the competition.
– Communicate strategy on an ongoing basis.
– Attend regular meetings, prepared with a full set of information around a topic.
– Communicate with customers directly to understand and help them with their issues
Tools
– Microsoft® Office, especially Outlook and PowerPoint?
– Internet Explorer
– Blackberry e-mail
– Report viewing tools
Subject matter expert (SME)
SMEs are the experts who know and provide the content for a specific business area. They
understand the intricacies of a specific business area, know the terminology, and can help to
explain how a specific process should work according to the business need.
SMEs are responsible on how tasks, to include the order of performance steps, are to be
performed
SMEs are responsible for technical terminology and jargon.
SMEs are responsible for determining acceptable performance levels.
SMEs are responsible for providing the performance objectives.
1.4.2 Technical roles
IT administrator
Skills/Education
– Patience and courtesy
– Trouble ticket management
– Detailed understanding of the process authoring life cycle, including the tools, test
server, and deployment
– WPS Administration
Goals
– Support the LOB when they want to author a process, need a new role, need a new
service, or get confused
– Work with a test and production environment which empowers the business user and is
up 24/7
Tasks
– Install the Directly Deployed (D2D) test server environment
– Seed the Directly Deployed (D2D) organizational role model
– Create server config files, and distribute them to new process authors
– Teach new process authors about the Directly Deployed (D2D) life cycle and the tools

– Help new process authors connect to the test server environment, WSRR server, RAM
servers, and so forth.
– Provide first point of contact when process authors run into trouble, and handoff to the
relevant IT expert
– Manage the incoming requests for new roles and new services
– Meet with Archie, the IT Architect, on a regular basis to determine which services
should be implemented
– Notify the LOB when new services and roles become available
– Encourage centralization and sharing across the LOB
Tools
– Business Space, WebSphere Process Server
– E-mail
IT architect
Skills/Education
– Detailed understanding of overall technical goals of the business and the current
hardware and software inventory
– Detailed understanding of industry patterns and approaches related to the
infrastructure for the business
– Detailed understanding of solutions or technologies that map to company needs as
well as prerequisites and hardware/software requirements
– Detailed knowledge of the business and technology domains
– Basic understanding of company’s entire business and IT operations
– Expert understanding of one or more particular solutions
– Proficient communication
– Proficient creating and communicating the overall vision for the software application
– Proficient development activity leadership
– Basic understanding of many technologies (in other words, a generalist rather than a
specialist)
– Proficient broad technical decision making
Goals
– Support the business to achieve their goals
– Design and build the software function required while meeting performance, availability,
and scalability requirements
Tasks
– Analyze, digest, and prioritize the business and IT requirements for new software
function
– Design the high level architecture for the software function
– Write the Software Architecture Document that describes the application’s components
and their interfaces within and outside of the software system, including clear
specifications of functional and nonfunctional requirements for the solution
– Define expected behaviors of service in terms of performance, service levels, and so
on

– Incorporate existing components and services into the design
– Describe how the functionality of the system is distributed across physical nodes
– Construct and assess architectural proof-of-concepts
– Establish the structure in which the implementation will reside
– Guide the development team, review detailed designs, and generally nudge the
implementation towards the architectural vision
– Define architectural patterns, key mechanisms, and modeling conventions for software
development
Tools
– Microsoft Office
– WebSphere Integration Developer
– Rational® Software Architect
– Telelogic Software Architect
1.5 Tools from IBM BPM Suite of products used in this solution
The IBM BPM Suite contains a comprehensive set of role-based capabilities that enable
customers to model, simulate, run, rapidly change, monitor, and optimize core business
processes. Within this paper, we do not use or cover all of the products offered in the IBM
WebSphere Dynamic Process Edition 6.2. For more complete information about the complete
suite offered in IBM WebSphere Dynamic Process Edition 6.2, refer to the following Web
page:
http://www-01.ibm.com/software/integration/wdpe/
The goal of this paper is to highlight and focus on a subset of the BPM Toolsuite that aligns
closely to the phases and tasks outlined in the IBM Business Process Management
Prescriptive Guide to Solution Implementation. The specific IBM BPM tools we discuss in
detail include:
Business Leader Widgets available through IBM BPM Blueworks.
(http://www-01.ibm.com/software/solutions/smartwork/bpmblueworks/)
WebSphere Business Modeler Publishing Server V6.2
WebSphere Business Modeler V6.2
WebSphere Business Monitor V6.2

Figure 1-3 illustrates which IBM BPM products are used during specific phases of the BPM
Solution Implementation approach.
Figure 1-3 Mapping of WebSphere BPM Toolsuite products to phases within the Prescriptive Guide approach
1.5.1 Business Leader Widgets: WebSphere Business Publishing Server
The Business Leader Widgets, available as part of WebSphere Business Modeler Publishing
Server v. 6.2 (and also available through IBM BPM Blueworks), enable users to share
process models and BPM assets through a Web browser. They allow users to validate BPM
assets with SMEs to create best practice process models and optimize processes. They
enable users to publish an array of BPM assets including process models, WebSphere
Business Monitor dashboard designs, and user interface forms. Additionally, they provide
enhanced process-model visuals to display labels and the latest WebSphere Business
Modeler notation formats.
Within this paper, WebSphere Business Publishing Server, specifically the Business Leader
Widgets, are used to produce the high level strategy maps discussed and created in the
Discovery phase, in Chapter 2, “Discover” on page 25.
1.5.2 WebSphere Business Modeler
With WebSphere Business Modeler, a business analyst can fully visualize, understand,
document, test, and share business processes. You can simulate process runs to identify
bottlenecks and inefficiencies, and define key performance indicators and business metrics
for use in WebSphere Business Monitor. Then, you can use the real business results in
WebSphere Business Modeler simulations for continuous process improvement. In addition,
Refine & Validate
asd;lkjfsdjfa;jasjsj
dlsjfsjfla
aksdljasdljasdff
askflaskal
;skdflsjkdf
lsjdfsk
asdfsdfss
askflaskdfalskdfdfghj gh
alskdfjlaskdjf
alksdjfl;ka
adfdfgdfgsdgf
dfg
askflas kdfals kdfasj dfjksdhf
•• alsk dfjla skdjf
alks djfl;ka fdgdfsdf
•• a;lsdflsdka ;lssdf gds fg dhjrt r hfghs g
•• asdfsdfasdf
•• a;lskdjflkjsadfljk asdj flkasjdf alskd
•• asdlkjasd
•• asldkfjlaskdjf
•• aksdflkasjdflkajsdflja sdflkj
•• alskdflkjasld;kfjasldk fjlasdkfjlasdkfj lasdfjlasdjf
asdfsfsas
sdkf
asdfjal
askjdfasd
asdfjal
askjd
asd;lkjfsdjfa;jaaks
dljasdljasdffasdfas
dffjjhlhjkjhkl
asd;lkjfsdjfa;jasd;
wi
dfkjsldjjasdjasdjsj
asdfs
Business
Modeler
+
Business
Monitor
Business
Monitor
Business
Leader
Widgets
Business
Modeler
5. Deployment

WebSphere Business Modeler can generate IT implementation artifacts for WebSphere
Process Server and facilitate testing of human-centric processes in a process server
environment.
Within this paper, WebSphere Business Modeler is used to model, analyze, and simulate the
claim processing process for the Storyboarding phase (Chapter 3, “Storyboarding” on
page 35), and, to some extent for visualizing and refining elements of the process, during the
Experience phase (Chapter 4, “Experience” on page 81).
1.5.3 WebSphere Business Monitor
WebSphere Business Monitor is an integrated business activity monitoring (BAM)
environment that provides end-to-end visibility of business activity on WebSphere Process
Server, WebSphere MQ Workflow, FileNet® Business Process Manager, and other enterprise
applications. Web-based and portal-based dashboards provide near real-time information so
business leaders can make timely operational and strategic decisions. Fully configurable
dashboards show you only what you need to see, and deliver alerts to e-mail, pagers, or
PDAs. Monitoring results can be used in WebSphere Business Modeler simulations to
complete the BPM feedback cycle, and the WebSphere Business Monitor development toolkit
provides templates and a test environment to further accelerate time to value.
Within this paper, WebSphere Business Monitor provides the view of the Business space,
illustrating integrated BAM and a view into key performance indicator (KPI) values for the
health care claim scenario. In Chapter 5, “Manage” on page 135 we discuss these KPIs and
show how to better analyze and manage these for further optimization of business processes.
1.6 Introduction to the health care demo scenario
This paper builds upon the set of prescribed activities and phases outlined in the Prescriptive
Guide, while using a specific IBM demo as the practical context for the solution. Within IBM,
this demo has been built on information from a fictitious health insurance company. It walks
the audience through a health care claims processing scenario in a business
audience-oriented way. The demo focuses on all the business user touchpoints, from how the
process is captured, to an integrated user interface, and how business users can change and
interact with live processes through interactive process design. This is a comprehensive
demo that spans a wide range of our BPM capabilities in a truly integrated fashion.
1.6.1 High level business goals
The health care insurance company scenario is based on the high-level goals of reducing
costs and improving claims processing times through automation of manual tasks and
processes and integrating people with back-end systems. Additionally, they plan to improve
customer satisfaction by addressing denied claims and working with the customer earlier in
the cycle to correct an incorrectly submitted claim.
Note: The goal of this section is only to provide an introduction the scenario. Subsequent
chapters of the paper will provide in-depth details on specific process modelling, process
improvements and how KPIs were more efficiently monitored and managed.

1.6.2 Overview of the overall claims process
Figure 1-4 illustrates an overview of the complete claim process. After a claim is successfully
received and approved into the system, it is processed by a claims specialist who analyzes
the amount requested for the claim and determines the pending amount to be paid. With
pricing set, the claim proceeds to the adjudication sub-process, where it will be classified as
either a dental, medical, or mental health type of claim.
Figure 1-4 Overview of the complete claim handling process
Note: For a more detailed listing of the specific business goals and objectives, see 2.2,
“Reviewing the business challenges, goals, and strategy for the health care scenario” on
page 28.

Figure 1-5 illustrates one of the sub-processes for claim intake. One of the tasks, Select
Provider, is a human task and will be reviewed for ways in which automation can lower the
cost and improve the efficiency of the process.
Figure 1-5 Overview of the claim intake sub process

Figure 1-6 illustrates the adjudication sub-process. Currently, in the “as-is” state of the
process, there are three automated tasks to assign the claim:
Handle Medical
Handle Dental
Handle Mental
If a claim has been rejected, it bypasses this sub-process, remains in the denied state, and
the customer is notified through mail approximately 30–60 days later. As we discuss in
Chapter 3, “Storyboarding” on page 35, a modification to this process represents an
opportunity to improve customer satisfaction. For example, if we add an additional task in this
phase, which would “inform customer of denial”, and automatically notify a customer of a
potential claim rejection, this could provide a more a pro-active approach to correct the issue
earlier and boost customer satisfaction.
Figure 1-6 Overview of the claim adjudication sub-process
1.6.3 Interacting with the process through the business space
In this section, we introduce the Business Space. The Business Space represents a single
point of entry for users, as well as other key process stakeholders to view the process and
collaborate on process reviews and potential process improvements.
We now are seeing the process through the perspective of the customer service
representative who enters the claim information and begins the claim intake process.
Figure 1-7 on page 19 illustrates a form into which a customer service representative of the
system enters information.

Figure 1-7 Claim intake form
As specific information is entered about the claim, the claim analyst works through a role
specific form that supports custom views of data for different users of the system. The fields
on the form provide data validation as information is entered and the process proceeds.
(Figure 1-8)
Figure 1-8 Entering claim information: The form is specific to the role of the user of the system

Figure 1-9 illustrates an overview of the tasks in progress from within the Business Space.
This view represents a supervisor’s view into the system, allowing the supervisor to review
the progress of work allocated across the team. If necessary, the supervisor can re-allocate
tasks amongst resources to more evenly distribute the workload.
Figure 1-9 Overview of the Business Space: Manager perspective
1.6.4 Monitoring and managing the performance
Figure 1-10 on page 21 provides an in-depth view into the Business Space. The Business
Space allows users and managers to view what is happening in the process. It provides a
quick and simple overview of the following items:
Number of claims processed
Duration of the average claim processing time
Trends in claim processing over time
Using the Business Space, managers and analysts have an aggregate view of the business
data they really need in a way that makes sense. They can drill down to obtain more specific
details for processes as needed.
Note: Chapter 5, “Manage” on page 135 provides in-depth coverage of the Business
Space and its capabilities.
Note: Chapter 5, “Manage” on page 135 provides in-depth coverage of the Business
Space and its capabilities.

Figure 1-10 Using the Business Space to monitor and manage performance
1.6.5 Modifications to be made to the process to address business goals
In the following chapters, we provide details on how the fictitious company in our scenario has
modified their processes to improve their claim handling efficiency and reduce costs.
The modifications to the process we discuss in this paper include the following modifications:
Business rule modifications
Within the process, we illustrate how to make the following business rules that are aimed
at reducing the number of claim rejections, thereby reducing costs and increasing
customer satisfaction.
– Focusing on the claim intake subprocess (see Figure 1-11 on page 22), we perform an
analysis in the Storyboarding phase that illustrates the potential cost savings if the
number of claims handled automatically versus being routed to the manual task were
increased to 90% from the current level of 50%. See 3.4.5, “Issue 3: Cost of service
intake” on page 61 for more details on this analysis.

Figure 1-11 Modifying the percentages routed to the manual task of Select Provider
– Reduce the overall number of claim rejections by modifying claim eligibility and
encouraging a greater number of claims to be handled automatically. This is going to
be addressed by changing the efficiency of the tasks “Check Member Eligibility”, “Set
Provider” and “Clean Claim Edits” to different ratios. See 3.4.6, “Issue 4: Cost of claim
adjudication” on page 63.
Process modification
– To address customer complaints that are not informed of their rejected claims in a
timely manner, we propose adding a task within the adjudication process called “Notify
Rejection to Customer”. In the existing process, claim rejections are not pro-actively
handled and the customer must often wait up to 60 days simply to be informed of a
rejected claim. Figure 1-12 on page 23 illustrates where we add this task in the
process. This is discussed in 3.4.6, “Issue 4: Cost of claim adjudication” on page 63.
Modifying the
percentages

Figure 1-12 Adding a task to handle notification of rejections
To address overall efficiency within a Human Task - Select Provider, we add an operational
characteristic to the task that results in escalation if the duration of a task is in a pending
state beyond one hour. This escalation improves quality of service by reducing the number
of claims unnecessarily waiting in a pending state. It also reduces cost by maximizing the
efficiency of the human task. This is described in 4.4, “Add operational characteristics” on
page 85.
1.7 Key assumptions
Throughout the steps described in this paper toward implementing the BPM Solution for the
Health Care Services Provider, the effort is based on the following assumptions:
Positioning of the IBM Business Process Management Prescriptive Guide to Solution
Implementation is intended as a solution toward a smaller scale, initial deployment at, for
example, a departmental level.
The IBM Business Process Management Prescriptive Guide to Solution Implementation is
an approach based on a subset of tasks initially in accordance with the more formal IBM
BPM Enabled by SOA Method. The Prescriptive Guide is most suited for an initial smaller
scale implementation, because it does not formally address many of the non-functional
requirements for an enterprise scale, production deployment.
The testing approach used in this paper is based on the IPD (Interactive Process Design)
approach to deploying the model into a runtime environment. We do not cover a full scale
deployment using WebSphere Integration Developer, (WID), WebSphere Process Server
and other products which would typically be involved in a larger scale deployment.

Chapter 2. Discover
This chapter introduces the “Discover” phase within the approach outlined in the Prescriptive
Guide. This is the first phase in the approach, with the goal of capturing the business intent
through documenting and creating basic models for the business goals, objectives, and
strategy. Within the chapter, we review the steps of the Discover phase using the specific
context from the health care scenario introduced in 1.6, “Introduction to the health care demo
scenario” on page 15.
2

2.1 Overview of steps in the Discover phase
Discover is the first phase in the approach described in IBM Business Process Management
Prescriptive Guide to Solution Implementation. This is the phase in which the business goals,
objectives, and strategies are reviewed and agreed upon. From these goals, you can then use
high level strategic maps to visualize the goals and begin review and better understand the
process. Figure 2-1 illustrates the Discover phase as the initial phase.
Figure 2-1 Business activity phases
The steps to be accomplished in this phase include:
1. Identify business challenges
2. Strategize on solution
3. Define business/solution goals
4. Define business measures
5. Create business capability maps
6. Create high level processes for high priority business capabilities
7. Obtain executive sign-offs and approvals
Now that we have an understanding of the formal steps, we bring this together into a more
meaningful context and explain the rationale which binds these activities together.
For example, the business (Health Care Insurance Co. ABC.) defines a set of initiatives for the
year to meet its financial and transformation targets. From there, they need to define the
strategies, or the high level what they will do to accomplish those initiatives. After they have
defined those business measures, they then define measures to evaluate criteria for success
and operational performance. After we have defined the what, we then look to who in our
organization (people/asset/capability, and so forth) that will support the execution of the
strategy. From there we map those organizations into a high level process, which represents
the how of execution, that will realize and support those initiatives. Bringing all of these steps
together and defining the what, the how, and the who is what makes up the Discover process.
Figure 2-2 on page 27 illustrates an overview of these tasks from a visual model perspective.
Refine & Validate

Chapter 2. Discover 27
Figure 2-2 Visualization of the steps performed within the Discover phase
2.1.1 Activities within each task
This section provides more detail into the activities to be accomplished within each task. In
2.2.2, “Defining business goals and measurements” on page 29, we map these steps into the
specific context of challenges, goals, and strategy for Health Care Insurance Co. ABC.
1. Identify business challenges
– Work with business leaders to determine which business challenges might need to be
addressed.
– Prioritize and assess the challenges, and document them.
2. Strategize on the solution
– Create strategies related to business challenges to determine their relationships to
downstream goals and capabilities based on priorities.
3. Define business/solution goals
– Identify specific, measurable goals to ensure that the solution is meeting the business
needs.
4. Define business measures
– Based on the identified strategy and goals, define business measurements (such as
KPI’s, business SLA’s, and metrics) that can be tracked and monitored periodically to
ensure the solution is meeting the specific business goals identified.
5. Create business capability maps
Prioritize capabilities based on business challenges.
6. Create high level processes for high priority business capabilities
7. Obtain executive sign-offs and approvals
Ensure that executive level sign off is achieved to proceed to the next set of phases.
Define
Business
Goals
Define
Business
Measures
Create High
Level
Process
Maps
Obtain
Executive
Sign-off
Strategize on
Solution
Identify
Business
Challenges
Create
Process
Capability
Maps
Note: The first four steps define the what aspect of what the organization will do.
They understand the challenges and have identified a strategy containing goals and
specific measurements for gauging their ability to reach that goal.
Note: Steps 5 and 6. address the who and the how of the approach. Who is supported
by specific business roles.

2.1.2 Tooling used for mapping strategic objectives, capabilities, and process
maps
Within the Discover phase, strategic maps, capability maps, and high-level process maps can
be created using one of several tooling options. For the purposes of this IBM Redpaper
publication, we highlight the capabilities of the Business Leader Widgets that can be
accessed and used collaboratively within the cloud.
BPM Blueworks provides business users an easy on-ramp to BPM with cloud-based
process and strategy tools.
– Business leaders and business analysts can create, share, and collaborate using
pre-built BPM content and contributions from BPM experts and users around the world
to move quickly from strategy mapping to process execution.
– Users of BPM BlueWorks can perform the following tasks
• Capture and collaborate on BPM Business Designs in the cloud, including strategy
maps, capability maps, and process maps, starting from scratch, using prebuilt
templates, or using contributions from the community
• Discover and contribute industry-specific BPM content that covers a full spectrum of
BPM strategies, trends, capabilities, and best practices for making the smartest
business decisions around BPM
• Participate in the community by blogging, creating local meetups, and chatting with
BPM experts
2.2 Reviewing the business challenges, goals, and strategy for
the health care scenario
This section discusses the underlying business challenges, goals, and objectives identified
during the Discover phase.
2.2.1 Identifying business challenges
Using the fictitious scenario for Health Care Insurance Co. ABC, the primary business
challenge is how to compete effectively in an environment where the following circumstances
are true:
Costs are increasing dramatically.
Customers are becoming increasingly frustrated due to the complexity of the claim
submission process and amount of repetitive paperwork required to submit a claim.
Many of the manual tasks (for example, tasks involving humans processing paperwork
and manually entering information into a system) are slow, error prone, and costly in terms
of the number of steps required to complete the process.
To compete effectively and survive, Health Care Insurance Co. ABC must improve and
automate their claim handling process.
Note: Refer to the following Web page to learn more about the capabilities and
tooling provided with IBM BPM BlueWorks:
http://www-01.ibm.com/software/solutions/smartwork/bpmblueworks/
index.html

2.2.2 Defining business goals and measurements
After strategizing on how to best meet the business challenges presented above, the
business leaders and analysts have identified the following business objectives for Health
Care Insurance Co. ABC:
Streamline and automate manual processes where possible
Reduce claim processing turn around time
Reduce manual processing costs
Improve customer satisfaction
In terms of how they measure this success toward the goal, this is defined through the
following means:
Number of claims processed. Claims will also be segmented by type of claims, namely
medical, mental, and dental
Average processing time for claim
Figure 2-3 illustrates a high-level strategy map, illustrating objectives, and the measurements
for success. This map was created using tooling from the IBM BPM Blueworks and Business
Leader widgets. The creation of this map has also set the foundation for defining specific
business measures, such as service level agreements (SLAs) and KPIs.
Figure 2-3 High level strategy map with objectives and basic measures
Measurements for Success
Business Objectives

Establishing base KPIs
As the process is analyzed and refined, Health Care Insurance Co. ABC can define metrics
that can be tracked and monitored periodically to ensure the solution is meeting business
goals. Some of the base KPIs that will be used in the simulation model discussed in
Chapter 3, “Storyboarding” on page 35, include the following tasks:
Number of claims handled on a daily basis
Number of claims rejected
Percentage of claims routed to the manual, human task “Select Provider”.
Duration required for the human task “Select Provider”.
This is a manual process that is time consuming and expensive, so the goal is to bring the
duration of this task down.
Maintaining the percentage of claim rejections to below 25 percent of overall submitted
claims.
Accomplishing a reduction in rejected claims achieves two objectives:
– It increases customer satisfaction, a primary goal.
– It reduces cost associated with handling rejected claims.
2.2.3 Creating high-level capability maps
By creating a basic capability map, the goal is to make sure that the organizational
capabilities can and will align with the strategic objectives. This can help to identify gaps
between the organization’s existing capabilities and the strategic objective, prompting
modification to the capabilities, goals, or both.
Figure 2-4 on page 31 illustrates the basic capability map in terms of organizational
resources and IT resources, mapping these against the objective for claims processing and
handling. It is possible from the high-level capability map to drill down into more detailed
models within the organizational resources and the IT resources.
Note: See 3.9, “Definition of control points to prepare experience” on page 77 for
details on how these KPIs are used during the modeling simulation.
Refer to 5.6, “Manage in real-time using KPIs” on page 149 for details on monitoring
and managing these KPIs during the Manage phase.

Figure 2-4 Example of a capability map
2.2.4 Creating high-level process maps
The next step in the Discover phase is for Health Care Insurance Co. ABC to create high level
process maps for the high priority business capabilities. Figure 2-5 shows an initial, high-level
process map.
Figure 2-5 High level process map
Drill down into
IT Resources
Drill down into
Organizational
Resources

The top level processes and their immediate sub-processes consist of the following elements:
Claim Intake
– Determine member eligibility
– Choose provider
– Clean up claim data
– Approve or reject claim
Figure 2-6 illustrates the claim intake process.
Figure 2-6 Overview of the claim intake process
Adjust pricing
Determine payable amount based on plan membership eligibility.
Determine adjudicator
– Determine how to handle this claim,
– Route to appropriate department, depending upon if this is a medical, dental, or mental
health claim and perform claim adjudication
Figure 2-7 illustrates an overview of the claim adjudication sub-process.
Figure 2-7 Claim adjudication process
Overview of the Claim Intake Process
Overview of the Claim Adjudication Process

2.3 Summary
In this chapter, we have provided the basic business context for the scenario based on Health
Care Insurance Co. ABC. Using the steps outlined in the Discover phase in the IBM Business
Process Management Prescriptive Guide to Solution Implementation, we have analyzed and
mapped the strategic business goals and objectives in a strategy map. We have also
identified the base metrics and KPIs to monitor and manage our success toward reaching
these goals. These metrics are a foundation and will be refined and simulated throughout the
upcoming Storyboarding, Experience, and Manage phases of the effort. Finally, we created a
high-level capability map to confirm that the organization’s capabilities are in alignment with
the strategic objectives, while also beginning to map out the top level processes based on
capability prioritization.
Before proceeding to the Storyboarding phase, we should have executive level sign-off
approving the strategic objectives, goals, and maps produced during this phase.
Note: These process maps represent the initial, high-level process maps. In Chapter 3,
“Storyboarding” on page 35, we explain the process model in detail, beginning with a more
detailed model of the process, representative of what a customer might provide as their
understanding of the documented ‘as-is’ business process.

Chapter 3. Storyboarding
The goal of Storyboarding consists of assessing the current processes, process performance,
and process enablers (technology, organization, and knowledge) to develop the requirements
for future processes. The considered processes and measures, which have been selected
during the discovery phase, are first documented and assessed for potential issues and
improvements. Then they are explored for automatization, and specified with measures, or
control points.
This chapter provides documentation of the as-is situation, gap analysis, and definition of the
future state of the process model and measures. It explains how to perform the following
tasks:
1. Capture the as-is state of the selected business process. The as-is state of the selected
business process has been previously captured within the Business Leader Space of BPM
Blueworks.
2. Simulate the captured business process through the simulation capabilities of WebSphere
Business Modeler. Determination of the most expensive and the less efficient paths in the
process.
3. Assess and discuss improvements in the business process by taking into consideration
simulation results, but also strategy and goals of the company determined during the
discovery phase.
4. Define the new future state of the Business Process Flow and Measures (KPIs) based on
strategy and discussion outcome.
3
Tools used in this chapter:
WebSphere Business Modeler models the “as is” process, the “to be” process, and its
process measurement requirements. Refer to the following Web page for more information:
http://www-01.ibm.com/software/integration/wbimodeler/index.html

3.1 Overview of steps in Storyboarding phase
Storyboarding is the second phase in the approach described in IBM Business Process
Management Prescriptive Guide to Solution Implementation. This is the phase in which the
user interactions and the accompanying business processes are reviewed and modeled. The
goals are to capture and refine the current state/as-is process so that you can understand
how enhancements can be incorporated to arrive at an improved future state process. During
this phase you will validate the inputs and outputs and review and validate human interactions
with the system.
An overview of the tasks in this activity phase is as follows:
Capture/refine current state process
Examine alternate ROI to determine best approach
Define/refine future state process
Capture roles
Identify process steps as candidates for business rules
Define task inputs and outputs and mock up forms for human interactions
Validate and visualize human interactions.
Figure 3-1 illustrates the steps involved in the Storyboard phase.
Figure 3-1 Steps involved in the Storyboard phase
3.2 Capture and refine the current state process
The first step of storyboarding is named “Capture/Refine current state process” as seen in
Figure 3-2 on page 37.
Storyboarding Phase
Capture/
Refine
Current State
Process
Capture
Roles
Examine
Alternate
ROI
Scenarios
Create
Mock-up
Forms
Create
Business
Rules
Validate
Forms
Define/
Refine
Future State
Process
Note: Throughout this chapter, we use the Health Care Insurance Co. ABC scenario demo
for specific context. If you are not yet familiar with the Health Care Insurance Co. ABC
scenario, refer 1.6, “Introduction to the health care demo scenario” on page 15.

Chapter 3. Storyboarding 37
Figure 3-2 Capture and refine current state model
Capture of a business process means the translation of this business process into a meta
language named “BPMN2.0”. In reality, these business processes exist in one of the following
forms:
Paper form
High level diagram created within a software tool
Intellectual capital of the employees
Regardless of the form, assuming the knowledge about the processes has previously been
documented, the result of the first step of Storyboarding consists of standardizing the
knowledge about this process and translating it into a common meta-language using an IT
tool. This common meta language is BPMN.
Based on the fictitious scenario, Health Care Insurance Co. ABC claims process, we show
the business value of standardized and meta-language-based modelization based on a
real-life scenario.
The sub-sections of this chapter explain the value of and how to perform the following tasks:
Import high-level process diagrams
Refine imported process model
Add business item information
Storyboarding Phase
Capture/
Refine
Current State
Process
Capture
Roles
Examine
Alternate
ROI
Scenarios
Create
Mock-up
Forms
Create
Business
Rules
Validate
Forms
Define/
Refine
Future State
Process
Note: The value of standardizing business processes that existed previously in in paper
form allows for re-use, flexibility and ease of change going forward. Standardized
processes can be easily annotated with improvement suggestions, measure points, critical
points, roles, costs and other important process information. These annotations happen
within a collaboration space to enable easy exchange of information between business
leaders and business analysts. This brings a fast time to market and high adaptation
capabilities to change.

3.2.1 Import high level process diagrams
This IBM Redpaper publication assumes that high-level process diagrams have been created
within BPM Blueworks or using the Business Leader Widgets from IBM WebSphere
Publishing Server. We assume that three processes have been created based on the
high-level process diagrams, strategy maps, and capability maps explained in Chapter 2,
“Discover” on page 25:
Claim process
Claim intake
Claim adjudication
Figure 3-3 shows the repository of the three created processes. These processes can be
visualized within a Web Browser on either BPM Blueworks or using the Business Leader
Widgets.
Figure 3-3 Health Care Insurance Co. ABC repository showing three created processes
The Business Leader Widgets permit sharing of artifacts within the Web browser and enables
collaboration on these processes.
Figure 3-4 shows the high level process diagram of claim adjudication. Although that the
diagram is high level, it already contains a lot of information, including branch activity name,
branches, and condition information. In addition, the user can link activities to documents,
make comments, and collaborate on this model with his peers. Collaboration occurs through
the Web browser.
Figure 3-4 High level process diagram of claim adjudication

Figure 3-5 and Figure 3-6 show a high-level process diagram of process claim intake.
Branches have been named and we added so-called “go to” activities pointing to Reject
Claim. They permit the user to indicate that a particular task or activity is pointing to another
task or activity (in this case, claim rejection).
Figure 3-5 High-level process diagram of claim intake (Part 1)
Figure 3-6 High-level process diagram of claim intake (Part 2)
The following steps detail the export of the processes towards the WebSphere Business
Modeler.
1. Click Export in the toolbar and wait for the export functionality to appear. See Figure 3-7.
Figure 3-7 The Export button
2. Select the WebSphere Business Modeler icon from the toolbar, as shown in Figure 3-8.
Figure 3-8 Business Modeler icon in Export toolbar

3. Click OK to download the XML to your server. Repeat the steps with the three processes
including “Claim Intake”, “Claim Process” and “Claim Adjudication”
.
3.2.2 Refine process model after import
The following steps show the imported process model for Process Intake, Process
Adjudication and Claim Process. Some of the information in these flows is not needed. We
highlighted this information with red boxes. It is part of the capture process to standardize and
refine the processes to make the processes as logical as possible.
1. The merge activity is not needed. It can be deleted and Provider Selection can directly be
wired to the next activity (See Figure 3-9).
Figure 3-9 Claim intake (Part 1 of 3)
2. Another merge activity and duplicate Reject Claim activities are not needed. They can be
deleted and wired directly to the next activity (Refer to Figure 3-10.).
Note: Appendix A, “Additional material” on page 249, contains appendix material that
shows how to import a Business Process Flow from third-party tools. In this case we use
an existing Business Process Flow diagram designed in Microsoft Powerpoint. In several
cases business process diagrams already exist in a third-party tool, and you might want to
import these diagrams into the WebSphere Business Modeler.
Refer to Appendix A, “Additional material” on page 249 for information about how to
download this additional information.

3. Scroll to the end of the process. The Done activity is not needed. Remove this activity and
delete it from the process pane. (Refer to Figure 3-11.)
4. Switch to the Claim Adjudication process. The Done activity is not needed. Remove the
activity and rewire the process correctly. (Refer to Figure 3-12.)
Figure 3-12 Claim adjudication process
At this point the three processes shown in Figure 3-13 (Claim Intake, Claim Adjudication
and Claim Process) will be successfully imported and adjusted. None of the processes is
wired to its input node. Without having the input node correctly wired, it is not clear what
type of data is needed to start the process. Also simulation would not run correctly.
Figure 3-13 Claims process
5. Wire “Check Member Eligibility” to the input node of the process. Figure 3-15 on page 42
shows a wire between the process input (bullet on left side of figure) and the next task
named Check Member Eligibility.
Figure 3-14 Wire output node of process.

6. The last activity named “Reject Claim” needs to be wired to the process output.
Figure 3-14 on page 41 shows the link between Reject Claim and the Business Process
Output. This is necessary to specify the output information of the process.
Figure 3-15 Wire input node of process
7. Simulation requires that every process is finished with a terminate node. Figure 3-16
shows the Reject Claim activity linked to a terminate node.
Figure 3-16 Reject claim activity linked to a terminate node
8. Repeat step Figure 3-9 on page 40 through 7 for the Claim Adjudication process. Wire the
input node of the process to the first activity and wire the last activity to the output node, as
shown in Figure 3-17. Add a terminate node if none are present. At this stage, you should
have three processes:
– Claim Intake
– Claim Adjudication
– Claim Process
The processes should have linked inbound and outbound communication respectively an
end Bullet.
Figure 3-17 Completing wiring for the input and output nodes
Important: The End Node and Terminate Node look similar. Make sure you created a
Terminate Node and not an End Node.

3.2.3 Add business item to process flow
Business items are business documents, work products, or commodities that are transformed
in business operations. Examples of business items are manufacturing order, mother board,
power supply, and memory chip (in a PC assembly process), itinerary and customer
information record (in a trip reservation process), and passenger (in a transportation
process).
The business item used within the claim process for Health Care Insurance Co. ABC is
described in Table 3-1.
Table 3-1 Business item description
Field Name Type
FirstName Text
LastName Text
ClaimNumber Text
ClaimType Text
Amount Integer
Plan Text
BillingProvider Text
MemberNumber Text
ContactPhone Text
ContactAddress Text
ReasonCode Text
Cause Text
Date Date
UsedAmbulance Boolean
Note: Instead of using WebSphere Business Modeler to edit a business item, a business
item could also be defined in a third-party tool such as Excel and later imported into
WebSphere Business Modeler. Refer to the WebSphere Business Modeler Information
Center for more details:
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp

The following procedure describes how the business item-named claim has been imported
into WebSphere Business Modeler.
1. Right-click Claims-Model within the Project Tree view of WebSphere Business Modeler
and select Import from the context menu. Figure 3-18 displays a listing of formats to
import.
Figure 3-18 Listing of formats available for import

2. Click Next and select the folder containing the Business Item XSD file as shown in
Figure 3-19.
Figure 3-19 Folder containing the Business Item XSD file
3. Click Finish.
4. Switch to the “Advanced Mode” of WebSphere Business Modeler by selecting
Modeling Mode Advanced from the menu.
5. Drag the Claim” Business Item to every path in your Business Process Flow Model. This
needs to be done exactly on every link (path) within the Claim Adjudication, Claim Intake,
and Claim Process processes. See Figure 3-20.
Figure 3-20 Specify correct input and output task during drag and drop of business item
While performing this operation, you might be presented with the dialog box shown in
Figure 3-20. If this occurs, select the “Claim” option in that dialog box.

6. Change type of input and output from tasks, if needed. See Figure 3-21.
Figure 3-21 Change Input and Output type of tasks
3.3 Add roles and cost to as-is process
The next step of Storyboarding is called “Capture Roles, Create Human Tasks and add Roles
to Human Tasks” as seen in Figure 3-22 on page 47.
Important: Make sure WebSphere Business Modeler changes existing inputs and outputs
to “claim”. In some cases, WebSphere Business Modeler might want to generate additional
inputs and outputs instead of converting the existing inputs and outputs. If this happens,
you can remove the superfluous inputs and outputs or change the existing datatype to
“claim”. See Figure 3-21.

Figure 3-22 Capture roles, assign human tasks, and add cost
This section concentrates on adding roles and cost information to the BPM. The initial
Powerpoint describing the process flow does not give that information, making it difficult to
understand what is the most expensive path within the process and making it difficult to
optimize the process. Overall this is done through the following procedures:
Capturing all relevant human roles that perform steps in the process
Capturing all cost and duration information and association of this information to the steps
in the process
3.3.1 Adding roles to as-is process
Table 3-2 describes the roles that need to be defined for Health Care Insurance Co. ABC.
Table 3-2 Process roles
Storyboarding Phase
Capture/
Refine
Current State
Process
Capture
Roles
Examine
Alternate
ROI
Scenarios
Create
Mock-up
Forms
Create
Business
Rules
Validate
Forms
Define/
Refine
Future State
Process
Note: WebSphere Business Modeler gives possibilities to attribute roles to tasks. A role is
an additional characteristic to a resource. An employee resource could have the role of
customer service representative for example.
Role Name Description Attributed to
Claims Analyst The claims analyst is in charge
to claim requests to determine
an appropriate billing provider
Task “Select Provider”
Customer Service Rep The Customer Service
Representative processes
claim information, either over
the counter or through phone.
Not attributed.
Pricing Specialist The Pricing Specialist looks at
the claim information and
adjusts the claim amount based
on the nature of the claim
Task “Request Receive Pricing”

The following steps describe how you can create the roles for Health Care Insurance Co.
ABC:
1. Create roles as shown on Figure 3-23. Right-click Resources New Role. The
“Create a new role” dialog box displays. Name the new role “Pricing Specialist” and give a
meaningful description. For example: ”The Pricing Specialist looks at the claim information
and adjusts the claim amount based on the nature of the claim.” Create two more roles
named “Customer Service Rep” and “Claim Analyst”. Describe the roles as indicated in
Table 3-2 on page 47.
Figure 3-23 Create new role
2. Add “Pricing Specialist” and “Customer Service Representative” roles.
Note: After having attributed a role to a resource, the business analyst could switch to the
swimlane layout. The swimlane layout rearranges elements in the diagram according to
which organization unit, location, individual resource definition, or role requirement they
have. Using swimlane mode shows who is performing what in the process. Swimlane
layout based on roles is activated by navigating to View Switch to Swimlane Layout
Role.

3.3.2 Add cost information to As-Is process
Every activity task within the claim process costs money to Health Care Insurance Co. ABC.
To make our simulation as accurate as possible, we need to define costs as precisely as
possible prior to starting the simulation. The following type of costs can be modeled within
WebSphere Business Modeler:
One-time cost
A one-time cost for a role or resource applies every time that the role or resource is
associated with a task in the process.
Cost per time unit
A cost per time unit is a cost that increases with the amount of time the process uses the
resource. An example of a cost per day is the rental of a piece of equipment required for
the process.
Cost per quantity
A cost per quantity is a cost that increases with the amount of the resource that the
process requires. For example, hydro has a cost per kilowatt hour. You can associate costs
per quantity unit with bulk resources.
Cost per quantity and time unit
A cost per quantity and time unit is a cost that increases with both the amount of the
resource and the time for which it is required. You can associate costs per quantity and
time unit with bulk resources
The claims process from Health Care Insurance Co. ABC requires one-time costs, cost per
time units, and cost per quantity and time unit. The as-is process is paper-based and includes
the following types of cost:
1. Manual tasks
Manual tasks are tasks being executed solely on paper. A person receives the claim
through internal post, works on the claim, and transfers it to his peer using the internal
post. These pure manual tasks are time-intensive and executed solely by employees
without the intervention of an IT system.
2. External tasks
These tasks are executed by an external department. They are out of scope of the
process.
3. Semi-automatic tasks
These tasks are executed by an IT system. However, the data required to process this task
needs to be entered by an employee. The calculated cost is actually the time needed to
enter that data and afterwards print the result for further processing. Table 3-3 on page 50
highlights the cost information based on the resource role and type.
Note: The user can change the image of the various tasks of the process flow. WebSphere
Business Modeler has predefined images for tasks, making the model easier to read.
Right-click Task and navigate to Change Image Custom Image from the context menu.

Table 3-3 As-is process cost information
The following steps describe how to set the costs within the Processes of Health Care
Insurance Co. ABC.
1. Double-click Resources Claim Analyst within the project tree. The “Claims Analyst”
dialog box appears. Change to the “Costs” tab and click Add to add new costs to the
resource. See Figure 3-24.
Figure 3-24 Add cost information to role
Resource description Type of resource Cost information
Claims Analyst Role (Human Being) $20 per hour
Pricing Specialist Role (Human Being) $25 per hour
Determine Adjudicator Manual Task 1 hour by claims analyst
Handle Medical External Task $100 per claim
Handle Dental External Task $87 per claim
Handle Behavior External Task $111 per claim
Check Member Eligibility Manual Task 15 minutes by claims analyst
Provider Selection Manual Task 15 minutes by claims analyst
Select Provider Manual Task 1 hour by claims analyst
Set Provider Semi-Automatic Task 10 minutes by claims analyst
Clean Claim Edits Semi-Automatic Task 10 minutes by claims analyst
Reject Claim Semi-Automatic Task 10 minutes by claims analyst
Request Receive Pricing Manual Task 2 hours by Pricing Specialist

2. Select the Cost per time unit radio button, as shown in Figure 3-25. Insert $25 as a value
and 1 hour as cost details. This means that the resource price analyst is going to cost $25
per hour.
Figure 3-25 Specify type of cost
3. Select the “Handle Medical” task within the “Claim Adjudication” process. Select Cost and
Revenue and add a Specific amount of 111 USD to the task, as shown in Figure 3-26.
Add fixed cost information on the “Handle Dental” and “Handle Behavior” tasks.
Figure 3-26 Specify fix cost on task
.
Figure 3-27 Add cost tab to attributes panel
Note: If the menu does not give the possibility to select Cost and Revenue, click More
and add Cost and Revenue by selecting it as shown in Figure 3-27.

4. Add the following duration information to the Manual Tasks “Request Receive Pricing”,
“Check Member Eligibility”, “Provider Selection”, “Select Provider”, and “Request Receive
Pricing”. Duration information needs to be added to the Manual Tasks “Request Receive
Pricing” and “Select Provider”. Figure 3-28 shows where to add duration information.
Figure 3-28 Add duration information to tasks
Table 3-4 below summarizes all task durations.
Table 3-4 Duration information
3.4 Examine alternate ROI scenarios
This section uses case analysis to determine which usage scenarios/use cases best fit the
goals that were defined during discovery. The major goal determined in the discovery section
was cost reduction. Simulation and analysis in the present chapter will therefore target cost
reduction as a priority. Figure 3-29 on page 53 illustrates the current focus of this section
within the context of the overall Storyboarding phase.
Task Role Duration
Determine Adjudicator Claims Analyst 1 hour
Check Member Eligibility Claims Analyst 15 minutes
Provider Selection Claims Analyst 15 minutes
Select Provider Claims Analyst 1 hour
Set Provider Claims Analyst 10 minutes
Clean Claim Edits Claims Analyst 10 minutes
Reject Claim Claims Analyst 10 minutes
Request Receive Pricing Pricing Specialist 2 hours

Figure 3-29 Determine most effective paths in process
3.4.1 Baseline Simulation
1. Right click the Claim Process process and select Simulate from the context menu, as
shown in Figure 3-30. A simulation snapshot will be created. Wait until the creation
completes.
Figure 3-30 Select “Simulate” from the context menu
Storyboarding Phase
Capture/
Refine
Current State
Process
Capture
Roles
Examine
Alternate
ROI
Scenarios
Create
Mock-up
Forms
Create
Business
Rules
Validate
Forms
Define/
Refine
Future State
Process

2. Click the process background of the newly created simulation background. You will be able
to select the Attributes Tab and configure the Total Number of Tokens. Click Edit next to
the “Total Number of Tokens” field, which is set to 1 by default. This is a too small a number
to actually see relevant simulation data. Click edit to set the number of tokens to generate,
as shown in Figure 3-32.
Figure 3-31 Specify a number of tokens to generate
Figure 3-32 Setting the number of tokens for simulation
3. The “Edit Total Number of Tokens” dialog box will display. Select the Generate a specific
number of tokens in each simulation run radio box and set the number to 100 as shown
in Figure 3-32.
4. Select the “Simulation Control Panel” tab and click the white triangle next to the Play
button. The “Simulation Settings” dialog box displays. Clear the Display animation
during simulation button and make sure the speed is set to a higher rate. (Refer to
Figure 3-33 on page 55.)

Figure 3-33 Specify Simulation settings
5. Click Play next to the Settings button to start the simulation, as shown in Figure 3-34.
Figure 3-34 The “Play” Button

6. Wait for the simulation to complete. Individual Cost information will appear. This is shown
in Figure 3-35. The results are showing a case-by-case execution of the claims process
and highlighting the average cost of every case. It only shows this analysis at a Parent
Process Level, however, giving less insight on the actual expensive paths of the process.
The following sections provide more detail on this:
– 3.4.5, “Issue 3: Cost of service intake” on page 61
– 3.4.6, “Issue 4: Cost of claim adjudication” on page 63.
The 100 instances processed have an average cost of $184.367 USD.
Figure 3-35 Initial simulation results
3.4.2 Issue 1: Efficiency of manual tasks
Reducing paper and optimizing information flows have become key priorities. A traditional
manual task is processed as follows:
Every employee participating in a workflow has an inbound mail basket and an outbound mail
basket on his desk. Internal post would bring him new work, he would process this work, and
give it to his outbound mail basket. It would then be sent to another employee (for example, to
the manager for approval).
This way of working has several issues:
Quality of Service:
It is only difficult to monitor the time the employee passes on processing the claim he
needs to process. A claim can be lost or unattended for a long time, having a negative
impact on customer satisfaction and, indirectly, also on cost.
Limited workflow capabilities
Even though the workflow exists on paper, there is no guarantee that employees actually
follow the workflow. Unless there is severe control of every employee, the degree of
freedom is large and a bypass or change can be enacted without actually reflecting this as
a change to the paper-based process.
Escalation capabilities
It is difficult to act on lost claims. Because it is difficult to monitor a paper-based process, it
is also difficult to act directly (real-time) on lost claims. A possible reaction could be the
escalation to a manager.
A first possible action would be to implement manual tasks as automatized human tasks. In
this case, the automatized workflow handles the inbox and outbox of the employee. If a given
state in the process is reached, a work item would simply appear in the To Do list of the
employee. This To Do list is part of the corporate intranet site. Within the IBM BPM suite, the
Business Space would be the place where users could work on human tasks.

A second possible action would be to implement manual tasks as fully automatized business
rules. In this case, the execution would be fully automatized and no human interaction is
necessary. This would be convenient if the rules to be applied to the claim can be defined as
expressions in a business rule engine. This applies to rules based on decision tables, such as
the decision to ask for approval if the amount of claimed money is bigger than USD 5000.
Figure 3-36 illustrates the notion of converting manual tasks as automatized human tasks.
Figure 3-36 Manual task to human task
At this stage no changes should be done. The changes are indicated as comment boxes on
the process, and the cost changed so that the impact of a future change can be estimated.
Before the definition of a future state, we are still in the process of simulation and exploration
of changes. No changes should be applied at this moment.
Figure 3-37 Annotation to mark future changes to process
Candidates for automatization changes are as follows:
Request Receive Pricing: Change to Human Task
Check Member Eligibility: Change to Business Rule
Provider Selection: Change to Business Rule
Select Provider: Change to Human Task
Determine Adjudicator: Change to Business Rule
Note: Business Space powered by WebSphere enables business users to create an
integrated and customized user experience so that they can access contextualized
process information in a secure role-based environment. Using the single sign on, Web
2.0-based mashup environment, Business Space users can collaborate with colleagues
and SMEs by sharing process content and working together to review BPM assets.
Important: The action suggestions are assumptions which are tested during simulation. To
reflect these assumptions, we are going to change the cost table in Table 3-5 on page 59.

3.4.3 Issue 2: Efficiency of semi-automatic tasks
In this paper we named a semi-automatic task a moment in the process where the employee
accesses an IT system to work on a claim. The claim is still posted to the employee’s
paper-based inbox, but the action on the claim is performed in a backend system. This often
contains additional state information about the to-be-processed claim. In the case of Clean
Claim Edits, for example, the employee accesses the corporate ERP system and cleans claim
edits manually. This action requires the employee to connect to the ERP system, perform the
changes, and disconnect.
This approach creates the following issues:
The procedure is error-prone
The employee can make errors when copying information or simply clean the claim
changes on the wrong claim. Consequences of such a human error are having a huge
impact to the claim processing.
Quality of service
There is no real-time monitoring and guarantee that the employee actually performs these
changes. There are also limited capabilities in sending out an escalation event, if the
action does not occur within a defined amount of time.
The recommended action to address this issue consists of accessing the backend ERP
system automatically. Actually no manual login and data retrieval would be required. The
action (for example, Clean Claim Edits) in the ERP system is executed automatically. An
automatic access to a backend system is called “Internal WebService” and “External
WebService”. If internal, the Web service will be in the scope of the Business Process. If
external, the Web service is in charge on another department and implies cost.
The following semi-automatic tasks should be implemented as Internal WebServices:
Set Provider
Clean Claim Edits
Reject Claim
The following semi-automatic tasks should be implemented as External Web Services
Handle Medical
Handle Dental
Handle Behavior
Note: The paragraph above assumes that backend systems such as ERP systems are
accessible by the workflow. Ultimately, this is a responsibility for the IT department to
ensure that backend systems are accessible within the workflow. Please refer to Chapter 6,
“Deployment” on page 187 for details on how to expose these systems. To access backend
systems directly, the systems need to be accessible as Web services through for example
an Enterprise Service Bus.
Important: At this stage the changes are not actually implemented. They will be assumed
and reflected into the adapted cost table to be seen within Table 3-5 on page 59. Actual
changes will be performed in Chapter 4, “Experience” on page 81.

3.4.4 Changes to cost table and second simulation
At this point the cost table needs to be adapted to reflect changes given by sections 3.4.3,
“Issue 2: Efficiency of semi-automatic tasks” on page 58 and 3.4.2, “Issue 1: Efficiency of
manual tasks” on page 56. Internal Web services and business rules are going to be treated
automatically. This means that no cost will be involved. Table 3-5 shows the changes.
Table 3-5 Cost table based on process automatization assumptions
Before assessing improvements, a second simulation needs to be performed. We then
compare the outcome of this simulation with the baseline results and highlight improvements
made.
Execute a simulation by clicking Claims Process Simulate Make sure to run the
simulation with 100 tokens and to deactivate Animation in the simulation settings.
Check for the average cost to appear in the Processes tab of the simulation results, as shown
in Figure 3-38.
Figure 3-38 Second simulation results
Assessment is all about uncovering inefficiencies in existing processes. Identifying the
inefficiencies within the context of the initial goals of process improvement is important.
These goals have been identified in Chapter 2, “Discover” on page 25.
Resource description Type of resource Cost information
Claims Analyst Role (Human Being) $20 per hour
Pricing Specialist Role (Human Being) $25 per hour
Determine Adjudicator Business rule no cost involved
Handle Medical External WebService $100 per claim
Handle Dental External WebService $87 per claim
Handle Behavior External WebService $111 per claim
Check Member Eligibility Business rule no cost involved
Provider Selection Business rule no cost involved
Select Provider Human Task 1 hour by claims analyst
Set Provider Internal Web Service no cost involved
Clean Claim Edits Internal Web Service no cost involved
Reject Claim Internal Web Service no cost involved
Request Receive Pricing Human Task 2 hours by Pricing Specialist

Claim process is a cost-driven process. Healthcare Insurance ABC wants to reduce the cost
of this process and looks for improvements in the process. A secondary goal of the process
improvement at Health Care Insurance Co. ABC is customer satisfaction.
The following steps show how to generate a more meaningful analysis report from your
simulation.
1. Right-click your simulation result within the Project Tree. Select Dynamic Analysis
Processes Comparison Analysis Processes Cost Comparison and wait for the
report to generate.
2. Figure 3-39 shows the results and shows that from baseline up to now we could make an
improvement of about 6.27%. This only through automatization of the tasks. Additionally
customer satisfaction will be improved.
Figure 3-39 Second simulation cost comparison
At this point we would like to make a even deeper analysis and see if we can improve the
performance results of the current flow even more. It would be interesting to look at the
distribution of execution of the various activities in the business process. The following
procedure describes a deeper analysis of activity cost.
Figure 3-40 Aggregated analysis of activity cost
Right-click your Simulation result within the Project Tree. Select Dynamic Analysis
Aggregated Analysis Activity Cost and wait for the report to generate. The report shown
in Figure 3-39 will appear.

Note the cost of $111, $87, and $100, which occurred on “Handle Behavior”, “Handle Dental”
and “Handle Medical”. These services are outsourced from Health Care Insurance Co. ABC
and cannot bring more cost gain. A message could be forwarded to the business leaders
trying to negotiate a cost rebate or to look for another outsourced service provider. Another
idea would be to call these services when needed.
Note the cost of $20 which occurred on provider selection. This is basically the salary of the
claims analyst which worked for 1 hour on that case. This can be a potential process issue we
might want to improve. It makes the actual average cost of Service Intake relatively high.
Note the average cost of $152.93 we would like to reduce.
3.4.5 Issue 3: Cost of service intake
This section focuses on understanding why the cost of “Service Intake” is high and how it
could be potentially improved.
1. Execute a simulation snapshot on “Service Intake”. Make sure you generate 100 tokens
and that visual simulation is switched off. Refer to Figure 3-32 on page 54 Figure 3-33 on
page 55 on how to do that.
2. Dynamic analysis on Service Intake. Right-click the simulation result and select Dynamic
Analysis Process Instances Summary from the context menu. A new report will be
generated. You can do case-by-case analysis and spot the reason why certain cases are
taking $20 of cost and others not. The reason is that we have a human intervention
required within task named Provider Selection task. See Figure 3-41 for a case-to-case
analysis.
Figure 3-41 Dynamic Analysis: Process Instances Summary
When analyzing these results we see that 14% + 4% + 7% = 35% causes cost of USD20.
When looking at the business process, we see that we assume a 50% to 50% ratio between
Provider Selection and Select Provider. Remember that Provider Selection is planned to be a
business rules task and Select Provider is planned to be a human task. This assumption is a
bit too generous. We would at this point target the business rules task to be implemented in a
way that it permits to filter 90% of the cases and send only 10% of the cases to the human
task. Figure 3-42 on page 62 shows the 50% to 50% ratio on the split activity.
Note: When highlighting a case, WebSphere Business Modeler actually displays the
execution path of the process chosen in that case in blue.

Figure 3-42 50% to 50% ratio between Provider Selection and Select Provider
A further improvement in the process can be seen when trying to focus on the rejected cases.
The Dynamic Analysis on Process Instances gives this view. Actually, when doing a
case-by-case analysis we can determine that rejected cases are also sent to claim
adjudication. This is expensive, as these claims will be processed and increase cost. In
addition, it has a negative impact on customer satisfaction, as the customer is not notified if
his claim is rejected.
Figure 3-43 shows that even if the claim is rejected, we do not stop process execution and we
execute claim adjudication. This ultimately will result in unnecessary costs within the claim
adjudication process.
Figure 3-43 Process Flow if claim is rejected
A potential resolution to this issue would be to consider rejected cases, which according the
business analysts are high (overall a total of 86%). This number can be identified when
adding all the case rejection cases in the analysis table shown in Figure 3-41 on page 61.
Important: The action would be to increase efficiency of the business rules engine task
“Provider Selection” so that more claims can be processed automatically. Human Activity
performed under “Select Provider” shall be reduced to 10% of the cases. It is
recommended to indicate this requirement with an annotation. This is beneficial for
collaboration. The same way of thinking counts for the “Check Member Eligibility” task, The
target filtering of this business rules engine is also targeted to be 10% rejected cases and
90% accepted cases.

3.4.6 Issue 4: Cost of claim adjudication
This section focuses on reducing the cost of claim adjudication. Again a simulation of claim
adjudication shall be executed to see where the highest cost is occurring.
Figure 3-44 on page 64 shows that rejection cases are either sent to “Handle Medical”,
“Handle Dental”, or “Handle Behavior”. We would like to avoid claims being sent to an
outsourced department and cause unnecessary costs. This is a significant obstacle for
customer satisfaction. Claims are basically rejected without the customer being notified.
At this point, no further improvements can be found. The following sections apply the
recommended changes and run a simulation for validation purposes.
Important: Two decisions are forwarded to the business leaders:
Decision 1
A process improvement is suggested to actually reduce the amount of claim rejection.
The question is open: “Do we focus on the right customers”.
Decision 2
Another process improvement is suggested to treat automatically rejected cases. This
will be explained in section 3.4.6, “Issue 4: Cost of claim adjudication” on page 63.
Important: A cure to this issue is to introduce an additional automatic task named “Notify
rejection to customer”, which would treat the rejected claims.

Figure 3-44 Missing rejection notification
3.5 Define the future state scenario
The goal of this section is to define and refine future state business process models that
achieves the closest results to the most cost-effective alternative chosen from case analysis.
Figure 3-45 on page 65 illustrates the current focus of this section within the context of the
overall Storyboarding phase.
Note: In this stage, we execute future state scenarios to model the potential cost reduction
benefits. Later in the chapter, we also discuss the ability to import the actual monitor data
back into simulation.

Figure 3-45 Define and refine future state scenario
More concretely for Health Care Insurance Co. ABC, this means that in 3.4, “Examine
alternate ROI scenarios” on page 52 we identified four major issues and pinpointed actions to
address these issues.
In review, these are the actions to be taken to address the issues:
1. Implementation of Human tasks
2. Implementation of WebServices
3. Implementation of business rules
4. Add additional Task named “Notify rejection to customer”
5. Adapt control flow ratios to reflect simulation data.
3.5.1 Implementation of human tasks
Within a WebSphere Business Modeler Process Flow, by default, all tasks are generic and do
not give any information about if they are going to be executed automatically (by a machine)
or manually (by a human being). If a task is identified as a human task, it permits WebSphere
Modeler automatically to generate configurable IT artifacts, such as a todo list, authorizations,
escalations, and so forth. During simulation analysis within 3.4.2, “Issue 1: Efficiency of
manual tasks” on page 56, we found that it would be efficient for our processes to use human
tasks instead of pure manual paper-based tasks. Within the same section we did not
implement these tasks. We only simulated the effect of using them. In the present section we
are going to show how to implement these tasks as human tasks.
Storyboarding Phase
Capture/
Refine
Current State
Process
Capture
Roles
Examine
Alternate
ROI
Scenarios
Create
Mock-up
Forms
Create
Business
Rules
Validate
Forms
Define/
Refine
Future State
Process

The following are going to transform two tasks from the Health Care Insurance Co. ABC
processes into human tasks.
1. Right-click the human task and select Convert To Local Human Task Figure 3-46
below will appear.
Figure 3-46 Convert manual task to local human task
Figure 3-47 Add name to local human task
2. Click OK to complete the creation.
The icon of the task will change and a few options will be added in the attributes.
3.5.2 Implementation of WebServices
At this stage no particular implementations are required to convert Tasks into WebServices.
WebServices Tasks need to be completed with operational characteristics to make them
really executable. We discuss this in section 4.5.1, “Adding services to deployable
applications” on page 99. For the time being we use Annotations to indicate these required
changes during the “Experience phase”.

Figure 3-48 Annotation indicating that task has to be implemented by a WebService
3.5.3 Implementation of business rules tasks
The following tasks explained in Table 3-6 shall be implemented as business rule tasks.
Table 3-6 Tasks to be implemented as business rules tasks
Business rule Characteristics
Provider Selection Business rule engines makes assessment on amount and sets
provider to “billing provider” if the amount within claim is smaller
than amount specified in the business rules engine. This is a clear
example of request qualification what is perfectly executable by a
business rules task.
Determine Adjudicator Based on the claim type and patient details this business rules will
determine which department will handle the claim. This is another
example of request qualification.
Check Member Eligibility Business rule assesses the Claim and decides if Member is eligible
or not by setting the appropriate output field to “true” or “false”. This
is an example of a question in the process. We would like to
determine if the member is eligible or not. The answer is evaluated
based on input content and either “No” or “Yes”.

To convert existing Tasks into business rules tasks, right-click Determine Adjudicator and
select Convert To Local Business Rules Task from the context menu. See Figure 3-49
for more details. Repeat this operation for Check Member Eligibility, Determine
Adjudicator, and Provider Selection.
Figure 3-49 Convert existing task into Local business rules task
3.5.4 Add additional Task “Notify Rejection to customer”
Next, we add a task to the “Claim Adjudication” process. This new task which will be in charge
to notify customer of a rejected claim, as shown in Figure 3-50 on page 69.
After the changes are completed recreate a snapshot of “Claim Process”, rerun a simulation
and an Aggregated Process Activity Cost Analysis. The results obtained show a considerable
improvement.
Note: 3.6, “Identify business rules content” on page 73 gives details about the rules to be
included. Chapter 4, “Experience” on page 81 specifies these rules for the business rules
task.

Figure 3-50 Add additional task “Notify Rejection to Customer”
3.5.5 Adapt control flow ratios to reflect insertion of business rules tasks
3.5.3, “Implementation of business rules tasks” on page 67 describes the goals to place
business rules tasks into the process flow to automatize manual activity. A business rule is
often introduced to avoid human activity. However, human activity cannot always be avoided.
The human activity in the flow actually deals with exceptions that cannot be handled by the
business rules tasks. Figure 3-51 on page 70 shows a business rules task called “Provider
Selection”, which has the intention to filter requests and either continue normal execution if
filtering was successful, or go into human exception handling addressed by “Select Provider”
implemented as a human task.

Figure 3-51 Human tasks as exception handlers for business rules tasks
Change “Member Eligible?” ratios from 50% and 50% to 10% and 90%. Figure 3-52 shows
the ratio for “Member Eligible?”. Change this ratio to 10% non eligible and 90% eligible.
Figure 3-52 Change “Member Eligible” ratios
Change “Able to select provider?” ratios from originally 50%, 50% to now 10% and 90%.
Figure 3-53 shows the ratio for “Able to select provider?”. Change this ratio to 10% “No” and
and 90% “Yes”.
Figure 3-53 Change “Able to select provider” ratios
Note: The ratio of 50% to 50% for this kind of pattern is too generous. The business rules
tasks has to filter more than just 50% of the requests. We recommend a ratio of 10% to
90%. The same is true for “Check Member Eligibility” and “Determine Adjudicator”
business rules tasks. Eventually,a precise monitoring of these ratios as part of KPI’s will
determine the real settings. As this is a paper-based process, no such detail is available
and an assumption has to be made.
Note: This change will not influence actual execution of the business process. It has to be
seen as a target in execution based on either real-time experience or on assumptions.
KPI’s in the Manage phase will give the possibility to determine what the real value is.

Change “Adjudication for?” and adapt the ratio’s of the condition to 22.5%, 22.5%, 25% and
30% as shown in Figure 3-54. These ratios are based on estimations. Only execution will
show the reality.
Figure 3-54 Change “Adjudication for?” ratios
3.5.6 Run final simulation for validation purposes
The goal of this final simulation is to measure the overall impact the changes made to the
improved process. The last series of changes resulted in a simulation result with an average
cost of $120.07, as shown in Figure 3-55.
Figure 3-55 Results from the latest simulation
Next, rerun a Process Cost Comparison for the Claim Process. You will see a cost
improvement of 27.37%. See Figure 3-56 for results. This cost improvement is compared to
the last comparison done in 3.4.4, “Changes to cost table and second simulation” on page 59.
Figure 3-56 Simulation analysis

Figure 3-57 shows a second comparison done with the baseline simulation executed in 3.4.1,
“Baseline Simulation” on page 53. We can see an overall improvement of ABC.
Figure 3-57 Baseline comparison
3.5.7 Future improved business process
Figure 3-58 through Figure 3-62 on page 73 give an overview of the improved processes.
WebServices are still marked with annotations. WebServices will actually be completed with
operational characteristics in Chapter 4, “Experience” on page 81.
Figure 3-58 Claim process parent process (no improvements)
Figure 3-59 Claim adjudication process with improvements

Figure 3-60 Improved claim intake process
3.6 Identify business rules content
The goal of this section is to identify individual rules to be included into business rules tasks.
These implementation rules are summarized in annotations and then collaborated with the
team implementing the business rules within the Experience stage. This section does not
convert tasks into business rules tasks. It specifies the content of these business rules tasks.
overall Storyboarding phase.

Figure 3-63 Identify steps to be implemented as business rules
Often, human activity can be replaced by business rules. This is usually the case when the
outcome is easily computable based on rules. Usually business rules apply whenever a task
plays the role of a question in the process. Other examples are as follows:
Business calculations
Input validation
Request classification
Answers to questions are implementable as decision tables or decision trees.
Business rules candidates are as shown in Table 3-7. These rules will be implemented in
Chapter 4, “Experience” on page 81. As of now they are only marked as business rules within
3.5.3, “Implementation of business rules tasks” on page 67. There is no indication on the
content of these business rules tasks. The purpose of this section is to define the content of
business rules.
Table 3-7 Business rules content
Storyboarding Phase
Capture/
Refine
Current State
Process
Capture
Roles
Examine
Alternate
ROI
Scenarios
Create
Mock-up
Forms
Create
Business
Rules
Validate
Forms
Define/
Refine
Future State
Process
Activity Question Description
Check Member Eligibility Is the member eligible? This can be either implemented as
a decision table or as a decision
tree. The idea is to make a couple
of checks (such as the citizenship,
place of living, years of
membership) and give these
answers to the caller of the
business rule.
Claim Adjudication Which adjudicator is valid for
the claim?
This is typically a request
classification. It can be
implemented as a decision table.
Provider Selection Which provider is valid for this
claim?
This is typically a request
classification. It can be
implemented as a decision table.

3.7 Generation and validation of mockup forms
The goal of this section is to generate simple form mockups using forms designer, based on
the inputs and outputs for the tasks.
Figure 3-64 Generate mockup forms
If the human task has identical inputs and outputs, only one form will be generated and
associated with the task as both the input and output form.
If you have forms already created for the human tasks, you can associate forms with
human task and process inputs and outputs on the Forms tab in the Attributes view.
To generate a new mockup form for the “Select Provider” task, right-click Generate Form
(Figure 3-65) and wait for form generation to complete.
Figure 3-65 Generate mockup forms
Storyboarding Phase
Capture/
Refine
Current State
Process
Capture
Roles
Examine
Alternate
ROI
Scenarios
Create
Mock-up
Forms
Create
Business
Rules
Validate
Forms
Define/
Refine
Future State
Process
Important: When you associate a form with a human task, if the inputs or outputs of the
human task do not match the form data, the inputs and outputs of the human task will be
replaced with the form data.

3.8 Validation of mockup forms
Create storyboards using simulation to validate with process owners the flow and content of
the human steps within the process. Obtain sign off and approval to move to the experience
phase. See Figure 3-66.
Figure 3-66 Validate the forms
You can create storyboards to step through sequences of human tasks in a process (for
example, to demonstrate the flow of a new human-centric process and provide stakeholders
with a preview of the forms that are involved in the completion of each human task).
Storyboards allow you to view the forms associated with a human task side-by-side with the
process diagram, mimicking the task owner's interaction with the form. Figure 3-67 on
page 77 illustrates the form used for the human interaction at this specific step within the
overall process.
Storyboarding Phase
Capture/
Refine
Current State
Process
Capture
Roles
Examine
Alternate
ROI
Scenarios
Create
Mock-up
Forms
Create
Business
Rules
Validate
Forms
Define/
Refine
Future State
Process
Important: Storyboards in a simulation offer a powerful possibility to test the look and feel
and usability of forms to be used within a business process. Storyboards can be used to
get the signoff prior to going into the Experience and Production phases.

Figure 3-67 Storyboards of human task forms
Using a Storyboard provides an excellent opportunity to validate generated forms. After
defining the storyboard of each of the human tasks, the user can storyboard through the
human tasks and try out the forms. Tasks can be added or removed.
3.9 Definition of control points to prepare experience
Simulation is important and gives a deep understanding of the process behavior. However,
real-time data is much more valuable. At this stage, the business analyst would like to define
KPI’s that will later appear on a Dashboard and be visible to the business leaders.
We have selected the KPI’s inTable 3-8 for performance measurements and monitoring of
Health Care Insurance Co. ABC.
Table 3-8 Suggestions for KPI’s
Note: More details about Storyboards can be obtained on the following Web page:
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.i
bm.btools.modeler.advanced.help.doc/doc/tasks/simulating/creatingstoryboardsfor
humantaskswithforms.html
Activity Type of Activity Type of Measurement
Request Receive Pricing Human Task Key Performance Indicator on
Duration. Average duration
should remain < 3 hours.
Select Provider Human Task Key Performance Indicator on
Duration. Average duration
should remain < 1 hour.

KPI’s described in Table 3-8 on page 77 follow the “Input, Output, Process and Outcome
Model.”
Table 3-9 KPI’s for Health Care Insurance Co. ABC
Overall, the choice of performance measurement points has to follow both the strategy and
vision of Health Care Insurance Co. ABC, and it has to be aligned with the metrics of
processes.
3.9.1 The Balanced Scorecard approach to ensure strategical alignment
The Balanced Scorecard (BSC) is a performance management tool for measuring whether
the smaller-scale operational activities of a company are aligned with its larger-scale
objectives in terms of vision and strategy. Figure 3-68 on page 79 illustrates the different focal
points within the Balanced Scorecard approach and shows how they work together. In the
following paragraphs we explain each perspective in greater detail.
The financial perspective examines if the company’s implementation and execution of its
strategy are contributing to the bottom-line improvement of the company. It represents the
long-term strategic objectives of the organization and thus it incorporates the tangible
outcomes of the strategy in traditional financial terms.
The customer perspective defines the value proposition that the organization will apply to
satisfy customers and generate more sales to the most desired (for example, the most
profitable) customer groups. The measures that are selected for the customer perspective
should measure both the value that is delivered to the customer (value proposition), which
can involve time, quality, performance and service, and cost, and the outcomes that come as
a result of this value proposition (for example, customer satisfaction, market share). The value
proposition can be centered on one of the following three areas while maintaining threshold
levels at the other two:
Operational excellence
Handle Medical Automatic Task should remain around 22.5%.
Needs to be monitored
Handle Dental Automatic Task should remain around 22.5%.
Handle Behavior Automatic Task should remain around 30%.
Notify Rejection to Customer Automatic Task <25% (to guarantee
satisfaction)
Organization Input Output Process Outcome
Health Care
Insurance Co.
ABC Claims
Process
Total Processing
Time
(Total Amount of
time spent on
Process)
Amount of claims
arriving to Health
Care Insurance
Co. ABC
Number of
Handle Dental
Number of
Handle Medical
Number of
Handle Behavior
Average duration
of Request
Receive Pricing
Average duration
of Select Provider
Average duration
of Determine
Adjudicators
Number of
rejected claims
Number of
customers not
notified by the
Health Care
Insurance Co.
ABC after
rejection.
Activity Type of Activity Type of Measurement

Customer intimacy
Product leadership
The internal process perspective “Business Processes” is concerned with the processes that
create and deliver the customer value proposition. It focuses on all the activities and key
processes required for the company to excel at providing the value expected by the
customers both productively and efficiently. These can include both short-term and long-term
objectives as well as incorporating innovative process development to stimulate improvement.
The innovation and learning perspective “Organizational Learning” is the foundation of any
strategy and focuses on the intangible assets of an organization, mainly on the internal skills
and capabilities that are required to support the value-creating internal processes.
Figure 3-68 Balanced scorecard for Health Care Insurance Co. ABC
Vision and strategy are located at the core of the diagram shown in Figure 3-68, as these are
integral to determining the optimal performance measures of a company.
3.9.2 The Input, Output, Process, Outcome Model to cover process life cycle
The Input, Output, Process and Outcome Model is used to ensure measurement
completeness for processes. This model is common in quality management and logistics, as
it allows you to measure the impact of process changes within an organization and define
KPI’s which are meaningful. Using this model in conjunction with the strategical orientation of
an organization can be very beneficial.
Categories of the Input, Output, Process and Outcome Model are as follows:
Input KPIs measure assets and resources invested in or used to generate business
results.
Note: Business leader widgets can be used to define capability and strategical maps of
your organization. The recommendation is to use a framework, such as the Balanced
Scorecard, as an orientation when defining your strategical maps.
Better Healthcare Insurance ABC Co Balanced Scorecard
« How do we look to
our shareholders ? »
« Are we able to sustain
innovation, change, and
improvement ?»
« How do we look to
our customers »
«What business process
are the value drivers ?»
Financial Perspective
Business Processes
Organizationnal Learning
Customer Perspective
Vision
and
Strategy

Examples include "Dollars spent on research and development," "Funding for employee
training," "New hires' knowledge and skills," and "Quality of raw materials."
Output KPIs measure the financial and non-financial results of business activities.
Examples include "Revenues," "Number of new customers acquired," and "Percentage
increase in full-time employees."
Process KPIs measure the efficiency or productivity of a business process.
Examples include "Product-repair cycle time," "Days to deliver an order," "Number of rings
before a customer phone call is answered," "Number of employees graduating from
training programs," and "Weeks required to fill vacant positions."
Outcome KPI’s measure the customer value impact as the result of an activity (for
example, the number of incidents occurred).
They measure what the customer values as the result of the activity. Outcome KPI’s focus
on customer value.
3.10 Summary
In this chapter we captured the current state process imported from BPM Blueworks
high-level process diagrams. We enriched the imported information by specifying decisions.
Figure 3-69 is a summary overview of the major steps performed within the Storyboarding
phase. The imported business process was separated into domain-specific sub-processes
named Claim Intake and Claim Adjudication. We captured and described the roles.
Figure 3-69 End of Storyboarding
We concentrated on examining alternate ROI scenarios. Therefore, a detailed simulation was
necessary, which concentrated on finding all possibilities for improvement. Four issues were
discussed and remedies for these issues were applied. The business process was basically
automated by converting tasks into human tasks, business rules and Web services. An
analysis was made to determine the cost improvement between the various improvements.
We determined an overall improvement of about 56% after automatization and process
improvements.
We detailed business rules and created validated mockup forms. The effort of storyboarding
results into a fully improved and simulated future business process.
Storyboarding Phase
Capture/
Refine
Current State
Process
Capture
Roles
Examine
Alternate
ROI
Scenarios
Create
Mock-up
Forms
Create
Business
Rules
Validate
Forms
Define/
Refine
Future State
Process

Chapter 4. Experience
After you have modeled the basic flow of your process and verified that the flow and activities
in the flow work as expected in Chapter 3, “Storyboarding” on page 35, you are now ready to
refine your process to make it easier for people who will use the application to perform their
assigned tasks.
This chapter introduces the “Experience” phase outlined in the IBM Business Process
Management Prescriptive Guide to Solution Implementation. This is the third phase in the
approach. It has the goal of capturing the business intent through documenting and creating
basic models for the business goals, objectives, and strategy. Within the chapter, we review
the steps of the Experience phase using the specific context from the Health Care Scenario
demo introduced in 1.6, “Introduction to the health care demo scenario” on page 15.
4

4.1 Objective of the Experience phase
Experience is the third phase in the approach described in IBM Business Process
Management Prescriptive Guide to Solution Implementation. This is the phase in which the
business analysts can begin to experience the solution through visualization and true
hands-on iterative testing. The goal of this phase is to refine the solution. This is done while
still working with sets of realistic data, but before the solution has been deployed into a larger
scale production environment. As we discuss in this chapter, much of this is made possible
through the Interactive Process Design (IPD) capability within WebSphere Business Modeler.
(For example, in 4.8.2, “Testing with the real life scenario” on page 122). We illustrate how to
modify business rules and review the impact on the process.)
Based on the experience results during this iterative, hands on, refinement phase, you can be
confident that the final solution, when deployed in a larger scale environment, will be the
solution that most effectively meets your needs.
4.2 Overview of steps in the Experience process
The steps to be accomplished in this phase are as follows:
1. Add operational characteristics (attributes) to the future state process
2. Define Constructs for execution on future state process
3. Elaboration of performance measures, KPIs, and business SLAs
4. Refine Forms
5. Interactively validate elaborated process in IT sandbox
In the upcoming sections, we discuss how we performed these specific tasks within the
context of Health Care Scenario demo introduced in 1.6, “Introduction to the health care
demo scenario” on page 15.
Figure 4-1 illustrates an overview of these tasks from a visual model perspective.
Figure 4-1 Visualization of the steps performed within the Experience phase
Experience Phase
Interactively
Validate
Elaborated
Process in
Sandbox
Define
Constructs
for Execution
Elaboration
on KPIs and
SLAs
Refine
Forms
Add
Operational
Characteristics
to Future State
Process

Chapter 4. Experience 83
4.2.1 Activities within each task
This section detail s the activities to be accomplished within each task.
1. Add operational characteristics to future state process.
Refine and fill in high level process steps, process logic, error handling, and data flow to
support process execution.
2. Define Constructs for execution on future state process.
– All process control flow (for example, gateways) should be refined to reflect decision
logic based on process data.
– Define Business Object Model look for reuse opportunities.
– Business roles for human tasks should be mapped to the organizational directory.
– Technical attributes should be added to the process model to prepare for runtime
deployment.
– Publish models to repository.
3. Elaboration of performance measures, KPIs, and business SLAs.
– Introduce additional measures of process performance against the expanded
operational process. This includes adding measures for activities, process branches,
and other aggregated measures introduced during process refinement.
– Task escalations should be added in accordance to business SLAs.
4. Refine forms.
– Working with user interface development, the form mockups are built out as a fully
functional user experience.
– Forms are typically exported separate from the process for the hand-off. The end result
is a collection of fully functional forms that can be handed in a single web-ready (WAR)
package to IT.
– Publish forms to repository.
5. Interactively validate elaborated process in IT sandbox.
– After adding operational characteristics for the first time or for subsequent iterations,
the process model can be deployed directly to a test environment for user interaction
and validation.
– A mockup of an appropriate business space can be created for interacting with the
process, which can provide guidance for IT.
Note: Process data should reflect the fields & content needed to support the process
from storyboarding

4.3 Reviewing the goals of Experience within the context of the
health care scenario
In the introductory sections, we defined the overall steps and activities within the Experience
phase. Now, we illustrate how to perform several of these specific tasks and activities using
the context of the Health Care scenario. Specifically, we discuss the following topics:
Within the activity of adding operational characteristics (attributes) to the future state
process, we show where and how to define specific tasks as either of the following tasks:
– Business rule task
– Human task
– An option for incorporating a service task (Web service) potentially to replace a human
task
Within the activity of elaborating on KPI’s and SLA’s, we discuss the following procedures:
– How to define the task duration KPI, using the example of the request/ receive pricing
human task. After this KPI is defined, it gives the analyst a specific metric for
measuring and comparing the duration of this task.
– Define a KPI which measures total claim by claim type. With the creation of this KPI,
the business analyst can have a much better understanding of where the majority of
claims exists.
Within the activity for refining forms, we give an illustrative example of how a refined form
could look using Lotus Forms Designer, after you have created a basic form which maps
the inputs required for claim.
W discuss how to deploy the model using the IPD to have a view of the working model
within the context of the business space. We introduce the business space and show how
an analyst can review the process flow iterations and where appropriate, adjust specific
KPI values to better monitor results.
Now that we have set the stage with the steps from the IBM Business Process Management
Prescriptive Guide to Solution Implementation, we begin by adding operational attributes in
the process and defining business rules, human tasks, and potential service tasks.
Note: Discussing the step-by step approach of using Lotus Forms Designer and
working with a user interface/graphics specialist is beyond the scope of this IBM
Redpaper publication, but we do provide an overview of the process and illustrate how
a completed form will look.

4.4 Add operational characteristics
In the Storyboarding phase, we defined the future state process. (See 3.5, “Define the future
state scenario” on page 64) This process will not yet deploy through the IPD until we add
specific operational characteristics to future state process. Figure 4-2 illustrates the current
focus of this section within the context of the overall Experience phase.
In this section, we review the process and determine for each task what kind of task this
should be:
Business rule task
Human task
Service call (Web service) based task
Refine and fill in high level process steps, process logic, error handling, and data flow to
support process execution.
Process data should reflect the fields and content needed to support the process from
storyboarding
4.4.1 Defining business rule tasks
A business rule task is a specialized type of task that helps you, as a business analyst, define
business policies. You can expose your business policies as business rules in your process
and if the rules are based on rule templates with parameters, the parameter values are
configurable in your process at runtime. While you are testing your application, you can view
the associated business rules and update rule parameter values to test the effect of different
values on the execution path. This rule is viewable and configurable by Business Space users
after the application is deployed.
Experience Phase
Interactively
Validate
Elaborated
Process in
Sandbox
Define
Constructs
for Execution
Elaboration
on KPIs and
SLAs
Refine
Forms
Add
Operational
Characteristics
to Future State
Process

The following list details key concepts for business rules:
Rule
A rule is a condition that must evaluate as true to perform a specific action. For example, if
the claim type is “Medical” and the claim amount is less than $1000, set the billing provider
to “Internal Billing”.
Rule template
A rule template is a parameterized template that simplifies the definition of many rules and
can enforce the structure if there are several rules that have the same structure. For
example, the previous rule example can be turned into a template using the Claim Amount
parameter instead of the actual amount value $1000.
Rule set
A rule set is a group of rules (and an associated template), with which you can manage
related rules together. A rule set typically covers all eventualities so that you are certain
that one rule will run, regardless of the input value. For example, Gold, Silver, and Bronze
rules with the rule template constitute a rule set.
Business rules task
A business rules task is a task that can contain multiple rule sets and allows multiple rule
sets to run concurrently.
Rule presentation
A rules presentation is the text representation for your business rule. When you create a
business rule, a default rule presentation is generated for you. Because the rule
presentation that you set up in WebSphere Business Modeler is the same string that is
presented to users for configuration in the Business Space interface, it is important to
customize the text into a clear and readable format so that the Business Space user can
understand the rule logic and identify which parameters to modify.
Although this business logic can be represented with a multi-branch decision and parallel task
flows, business rules provide a consolidated way to encapsulate the policy.
4.4.2 Identifying business rule candidates from the scenario process
Figure 4-3 on page 87 illustrates which specific tasks in the process are candidates as
business rule tasks:
Check Member Eligibility
Provider Selection
Determine Adjudicator

Figure 4-3 Activities for business rule from storyboard
In our Claim Intake sub-process where a claim is matched with a provider, we decided that we
want to use a business rule for provider selection. Figure 4-4 illustrates the step within the
Claim Intake process which can be defined as a business rule
Figure 4-4 Step within the Claim Intake Process which can become a business rule

In this business rule scenario, we provide a filter for determining which claim amounts need to
be routed to the Select Provider human task. We can decide whether we automatically select
the internal billing provider based on a predefined claim amount or send to a human task to
select another billing provider. Also, because we are using a business rule template, we can
dynamically change this predefined claim amount during runtime in business space to adapt
to changing business environments. This will reduce the claim processing cost by reducing
the select provider human task activity.
4.4.3 Steps to create a business rule (Provider Selection)
In this section, we discuss the steps to create the Provider Selection business rule that we are
going to use to decide either of the following tasks:
Assign the internal billing provider
Send the selection task to the claims analyst for the human task
We are going to replace the current provider selection activity with the new rule task on the
process editor for Claim Intake process. Figure 4-5 illustrates this step in the process flow.
Figure 4-5 Current provider selection activity
To create this business rule, perform the following steps:
1. Drag a business rules task from the palette to the process editor. See Figure 4-6 on
page 89.
The business value of converting a manual task to a business rule: This business rule
acts as a filter for the human task so that only high amount claim goes to the human task
for selecting billing provider and the business rule (this filter) assigns the billing provider if
the claim amount is low. Automating the manual task of provider selection as a business
rule reduces human error and labor cost.

Figure 4-6 Business rule task
2. Change the name of this new rule task to Use Internal Billing and replace the Provider
Selection Activity by moving the input and output wiring from the Provider Selection
Activity to Use Internal Billing Activity.
3. Delete the Provider Selection Activity.
4. Click the Attributes - Attributes- XXXX Tab for the business rule task and then select the
Business Rules tab. (Figure 4-7)
Figure 4-7 Business Rules tab
5. In the Business Rules tab of the task, click Add to create a new business rule.
Figure 4-8 Add new business rule

6. Define the business rule. In the new “Define Business Rule” window, define:
– Rule parameter (Claim Amount)
– Rule template (Internal Template)
With the parameter (Claim Amount), we can dynamically change the value in the business
space during the runtime at a later time.
a. Enter Use Internal Billing for the Name field, as shown in Figure 4-9.
Figure 4-9 Define Business Rule window
b. Click Add Template and click Add in the Rule parameters section.
A new row will appear for you to create a new parameter.
c. Enter Claim Amount for Parameter Name and select Decimal (double- precision) for
Type. (Figure 4-10)
Figure 4-10 New parameter

7. Create a template that compares the Claim Amount parameter we defined with Amount in
the input field of this business rule task. If the Amount is less than ‘Claim Amount’
(Condition), then it will set the Assign Provider field in output to False and also assign the
Billing Provider field in the output to Internal Billing’(Rule Action).
a. Change the Template Name to Internal Template and click Rule condition to create
a condition template, as shown Figure 4-11.
Figure 4-11 New rule template
The “New Expression Builder” window displays.
b. Click Add to define a new condition.
c. Using the Expression Composer, create a new condition as shown in Figure 4-12. Click
Apply, then click OK.
Figure 4-12 New rule condition

8. Create a new Rule Action that will be executed if the new Rule Condition is true.
a. Click Rule Action as in Figure 4-13.
Figure 4-13 Rule Action button
b. Create a new Rule Action that assigns Internal Billing to the Billing Provider field in
output. Set the Provider output field to False, as shown in Figure 4-14. Click OK.
Figure 4-14 Rule action
9. In order for Business Space users to configure parameter values in runtime, you must
include the configurable parameters in the rule presentation. You can customize the text
that shows up in Business space during runtime for dynamic change of the parameter.
(Figure 4-15 on page 93)

Figure 4-15 Rule presentation
10.Click the If-then rules tab and we create three rules (Figure 4-16):
– Rule for Initialization (copying input to output)
– Default Rule (setting ‘Assign Provider’ field in output to True)
– Rule for using the Internal Template we just created
Figure 4-16 If-Then Rules tab
a. Click Add Rule to add Rule for Initialization
b. Enter Initialize for the rule name and click Rule Condition.
c. In the “Expression Builder” window, create a condition that will be always true, as
shown in Figure 4-17.
Figure 4-17 true condition

d. Click Rule Action and the “Specify Rule Action” window displays.
e. Highlight the output and click Expression, and then click Edit as shown in Figure 4-18.
Figure 4-18 Initialization action rule
f. In the “Expression Builder” window, select Input as shown in Figure 4-19, and click
Apply, and then click OK.
Figure 4-19 Initialization action rule Composer

11.The Initialization Rule is created. We will now create the second rule (Default Path) that
sets Assign Provider field in output to True.
a. Click Add Rule, change the rule name to Default Path, and click Rule Condition.
b. Make the condition True.
c. Click Rule Action and in the “Specify Rule Action” window, set the Assign Provider
output field to True, as shown in Figure 4-20. Click OK to save.
Figure 4-20 Default path rule composer
12.Create the third that uses the Internal Template we created before.
a. Click Add Rule and change the rule name to Internal Billing.
b. Click the template name and select the Internal Template. This populates the rule
condition and action field with the templates.
c. Highlight the Internal Billing rule as shown in Figure 4-21.
Figure 4-21 Complete If-Then rules

d. The internal billing rule includes the parameter (Claim Amount) that can be changed in
runtime.
e. Set the initial parameter value to the value of 1000, as in Figure 4-22.
Figure 4-22 Claim Amount value
13.Set this new rule (Use Internal Billing) as the default business rule in the scheduling
section of the Business Rules tab (Figure 4-23).
Figure 4-23 Default business rule
We implemented rest of the business rules for resource type Business Rule in Figure 4-3 on
page 87 following the same approach outlined in the above steps.
4.4.4 Defining human tasks
In the previous section, we added a set of operational characteristics by defining which steps
in the overall process could be defined and implemented as business rules. The next step is
to define which steps in the process can be defined and implemented as human tasks. The
two candidate steps for this are as follows:
Select provider task
Request/receive pricing task
For this scenario we focus on the Request/receive pricing task and illustrate how we can
assign escalation attributes to create alerts if the duration of this task is taking too long.
Figure 4-24 on page 97 shows a list of resources within the process and highlights the ones
which will be assigned as a human task.

Figure 4-24 Activities for human task from storyboard
Business considerations for a human task
Complex process flows are often a combination of automated tasks and human tasks. In our
solution, users can assign a human role or specific individual to a task. In addition, they can
use a first-class process element called a human task, which enables an interaction between
a person and a business process or service.
To ensure that human tasks do not delay a running process, you can define the escalation
logic that takes effect after a specified interval.
Escalation
In a human task, we can assign the task to a specific group of people based on their role and
create escalation if the task is not performed or claimed for a specified duration.
For the sake of illustration in our scenario, we implement escalation within the
Request/Receive Pricing human task activity in the Claim Process to meet our SLAs for
customer satisfaction. Figure 4-25 is the icon used in the overall process to indicate that
Request / Receive pricing is a Human Task activity.
Figure 4-25 Request/receive pricing human task
Important: Business roles for human tasks should be mapped to the organizational
directory and task escalations should be added in accordance to business SLAs.

Implementing escalation attributes to the human task
Perform the following steps to implement escalation attributes to the human task.
Click the Attributes - Request/Receive Pricing tab of the Request/Receive Pricing human
task, and then click the Escalation tab. Click Add.
Figure 4-26 Add escalations
It will populate with default escalation settings and we modify some of the settings so that if
the task is not claimed by users within two minutes after it is ready, the user with ID “admin”
will be notified by posting the escalation work item on the work list for the admin user. The
changes are shown in Figure 4-27.
Figure 4-27 New escalation

4.5 Define Constructs for execution
The next step within the Experience phase is to define constructs and prepare the process
model for runtime deployment. For the sake of illustration in our scenario, we review the
process and consider how existing Web services already defined by the organization could be
used to make steps in the process more efficient.
The goal for defining constructs for execution on future state process are as follows:
All process control flow (for example, gateways) should be refined to reflect decision logic
based on process data.
Define Business Object Model look for reuse opportunities
Business roles for human tasks should be mapped to the organizational directory.
Technical attributes should be added to the process model to prepare for runtime
deployment
Publish models to repository
Figure 4-28 illustrates the current focus of this section within the context of the overall
Experience phase.
4.5.1 Adding services to deployable applications
Services are external processes outside the organization that can be used within the
organization's processes. Services either provide input to the organization or receive output
from the organization. Services have well-defined inputs and outputs, but their internal
processes are unknown to the organization and cannot be changed.
As we review the claim handling process, the steps that could be ultimately implemented as a
service are as follows:
Handle Medical
Handle Dental
Set Provider
Clean Claim Edits
Reject Claim
Experience Phase
Interactively
Validate
Elaborated
Process in
Sandbox
Define
Constructs
for Execution
Elaboration
on KPIs and
SLAs
Refine
Forms
Add
Operational
Characteristics
to Future State
Process

As you are modeling your deployable business process, you might identify certain activities
that can be automated. Figure 4-29 identifies some resources that can be implemented as
automated services.
Figure 4-29 Activities for services from storyboard
Although services are outside the control of the organization, they are essential to modeling
the realities of business-to-business integration. For example, in our scenario, Health
Insurance Co. ABC can use the services of a Set Provider as part of a claim application
process. You can represent the Set Provider task as a service when modeling that process.
Figure 4-30 illustrates how you can right-click a task and begin the process of converting this
to a service.
Figure 4-30 Service activity
Note: For the sake of this scenario, we are assuming that Web services containing the
functionality required either already exist, or have already been created by the IT
organization for Health Care Insurance Co. ABC.
The goal is to illustrate why and how Web services could be used here.

Considerations for activities modelled as a service
These activities can be modeled in your process as services or business services, depending
on whether or not they have already been implemented as a service and exist on your
WebSphere Service Registry and Repository server.
If the business service already exists on your WebSphere Service Registry and Repository
server, you can import the business service and related business service objects for inclusion
within your process model. For example, if there is already an implemented service that
selects a billing provider for a claim in our scenario, you could replace the select provider
human task in your process model with this service.
If your service has not yet been implemented, you can model the type of service that you
would like to have implemented, including the types of input and output data and a description
of the operations performed by the service, and pass the service specification to your IT
developer to implement the service. The supported implementation types for tasks and global
tasks in deployable processes are 'none' or "Import - Web Service binding". See Figure 4-31.
Figure 4-31 Implementation type for services

After the developer has implemented the service and published the endpoint to the
WebSphere Service Registry and Repository server, you should be able to test your service
within your deployable process. IT should make the default WSRR connection from your test
server through WebSphere Administrative Console, as shown in Figure 4-32.
Figure 4-32 WSRR settings in IT sandbox
4.6 Elaboration on KPIs and SLAs
With KPIs, you can analyze data to gain business insight into what might not be known or
realized. As the business environment changes, KPI thresholds often need to change too. In
the Business Space, you can modify KPI thresholds so that you can move your success
targets and evaluate various scenarios without asking IT to update and redeploy the model.
Note: You can still include services in your deployable process even if you are not using a
WebSphere Service Registry and Repository server. If the WSDL you imported into
WebSphere Business Modeler is a single WSDL that includes the PortType as well as the
endpoint information, a WebServices Import will be generated that is bound to the
mediation component as the default port. This means that if no WebSphere Service
Registry and Repository server is configured, the WebServices Import will be triggered,
using the endpoint that is defined in the original WSDL object.
Optional: You can improve the efficiency of how your service is located at runtime by using
a classification system that is defined for services in your WebSphere Service Registry and
Repository server. Such a classification system might include, for example, values that
distinguish services used by one geographic region from another. For example, there can
be one claim service that is specific to California and one for rest of the states. When
modeling the claim process, you might want to ensure that the service for California is
invoked and therefore tag the service invocation in your process model with the
appropriate classifier.

Figure 4-33 illustrates the current focus of this section within the Experience phase.
4.6.1 Setting the context within the scenario for Health Care Insurance Co.
ABC
To bring this into the context of our scenario, the business analysts, working together with the
management team of Health Insurance Co. ABC deem that the claim rejection totals
threshold for the Medical claim type is too high. The analyst lowers the threshold value for
determining a rejection and assesses how well the business might perform given the same
incoming claims. If this real-time simulation shows that the threshold has been exceeded, the
management team can then ask the business analysts to determine how the process can be
improved given this new goal.
As you assess the state of the business using the dashboard, you might realize that a new,
yet-to-be-defined KPI might be helpful and one that correlates data in a new way. In the
Business Space, you can dynamically create a new KPI without modifying the original
process. Additionally, in the Business Space, you can use one or more KPIs and modify the
display mode (Table view, Gauge view, and so forth.) and the visual characteristics (color
range spectrums, sizes, layout format, and so on). Then you can save this personal
configuration so that it is applied to the most current deployed model. (See 5.6.2, “Setting up
the KPI widget report” on page 151)
4.6.2 Steps to define the task duration KPI
As part of our overall cost reduction effort, we would like to measure the duration of human
tasks (request/receive pricing and select provider tasks). In the following sections, we
describe how to do this.
Before you start creating this KPI, you need to enable monitored values for this task’s
processing time.
Note: In addition to this section, in which we introduce KPIs and illustrate how to define a
specific KPI, refer to Chapter 5, “Manage” on page 135 for more information about
creating, monitoring, and managing KPI performance.
Experience Phase
Interactively
Validate
Elaborated
Process in
Sandbox
Define
Constructs
for Execution
Elaboration
on KPIs and
SLAs
Refine
Forms
Add
Operational
Characteristics
to Future State
Process

Enabling the monitored values
Perform the following steps to enable the monitored values.
1. In the process editor, click the Request/Receive Pricing human task in the Claim
Process and then click the Business Measures tab. See Figure 4-34
Figure 4-34 Request/Receiving Pricing activity
2. Click the Monitored Values tab in Business Measures and select Average
Request/Receive Pricing Processing time as shown Figure 4-35.
Figure 4-35 Average Request/Receive Pricing Processing Time
3. If you go to Business Performance Indicators tab, you will see a new instance metric
and an aggregate metric that you can use to create a new KPI. (Figure 4-36)
Figure 4-36 New metrics

Creating the KPI for Avg Duration of Request/Receive Pricing
Perform the following steps to create the KPI for Avg Duration of Request/Receive Pricing.
1. Click Add to create the KPI that measures the task duration.
Figure 4-37 Add KPI
2. Enter the name, Avg Duration of Request/Receive Pricing, and select the KPI radio
button as type, as shown in Figure 4-38.
Figure 4-38 KPI as Type
3. Specify target type (Duration) and Target Value (2 hours) as shown in Figure 4-39.
Figure 4-39 Target Type and Value

4. Specify three ranges (Low, Medium, and High) using a percentage of target value, as
Figure 4-40 Target Ranges
5. Specify how it should calculate the KPI by selecting the instance metric (Request/Receive
Pricing Processing Time) and Average for Aggregation function
Figure 4-41 KPI calculation
6. Click OK to save.
To create additional KPIs (namely for task average duration KPI for Select Provider human
task Activity in the Claim Intake process), repeat the same steps in this section.
4.6.3 Steps to Define the Total Claim KPI
In our claim process, we would like to see how many claims are processed by claim type (for
example, Medical, Dental, Behavioral) for the current month to measure the cost as part of
our overall effort to reduce claim processing cost.

This KPI will automatically show up in the Business Space dashboard after we deploy the
process. You can design this KPI using the Business Measures editor in the modeler. The
process for defining the Total Claim KPI is described in this section.
1. Select the process (Claim Process) where you monitor this KPI and click the Business
Measures tab (Figure 4-42).
Figure 4-42 Business measures
2. To define this KPI, create a metric (Aggregate, Instance, or unspecified).
a. Create the Claim Number instance metric by clicking Add. Enter Claim Number for
Name and select the Instance metric radio button for Type. See Figure 4-43.
Figure 4-43 Claim Number instance metric
b. Select text for default type. See Figure 4-44
Figure 4-44 Defeat type

c. Specify how to calculate this instance metric by selecting Template (Business Item
Input), Process element (Claim Process) and Attribute (Claim Number). See
Figure 4-45.
Figure 4-45 Instance Metric Calculation
d. Click OK to save.
3. Repeat the steps above for another Instance Metric Claim type. See Figure 4-46.
Figure 4-46 Claim Type Instance Metric
4. Create a KPI using these metrics.
We create a KPI, Total Claims, with a Medical claim type for current month.
To create the metric, perform the following steps:
a. Click Add on the Business Measures tab.

b. Enter a name for this KPI and select KPI for type. In Figure 4-47, we are calling this
Total Claims Medical - Current Month.
Figure 4-47 KPI Type
c. Specify target type and value. In our example, we are targeting 500 claims in total claim
numbers, as shown in Figure 4-48.
Figure 4-48 Target Type Number
d. Specify ranges of your KPI for low, average and above average ranges using
percentages of the target value as in Figure 4-49.
Figure 4-49 KPI Ranges
e. Specify how to calculate the KPI. For example, Figure 4-50 on page 110 shows that we
are going to aggregate the claim number (the instance metric you just created in the
beginning of this section) using the count function to get claim totals.

Figure 4-50 KPI calculation
f. Specify the time period that you will measure this KPI. In Figure 4-51, we measure
during the current month and repeat every month.
Figure 4-51 KPI Time Period
g. Specify a KPI data filter so that we only calculate claims that include claim type
Medical, as shown in Figure 4-52.
Figure 4-52 KPI Data Filter
h. Click OK to save.
This KPI is ready. When you deploy the process to the server, it will show up automatically on
the dashboard of your business space panel.

Repeat these steps to create another KPIs. For example, Total Claims for Claim Type Dental
type during current month. You will change KPI Data Filter to ‘Claim type is equal to Dental’.
4.7 Refine forms
Just as human tasks help you define the manual aspects of a process, forms help you (the
business analyst) define how business users interact with in-flight process information. In fact,
forms in our solution can be associated with human tasks only. The relationship between
forms, business items, and human tasks is natural.
Forms define the user interface.
Business items define the data being acted on throughout the process.
Human tasks bring data and the user interface together.
One of the ways that you can make your application easier to use is to create custom forms
for your human tasks. If you already have forms created using Lotus Forms Designer, you can
import these forms into your workspace and associate them with a human task. You can also
customize forms that you create in WebSphere Business Modeler and update these forms in
your process model. A custom form designed in Lotus Forms Designer can provide a more
user-friendly and attractive interface for reviewing and entering the data associated with a
human task.
Experience phase.
Note: While we have discussed how to define and configure a few example KPIs,
Chapter 5, “Manage” on page 135 provides much greater detail on how to use the
Business Space to monitor and view KPI performance.
Note: When you associate a form with a human task, if the inputs or outputs of the human
task do not match the form data, the inputs and outputs of the human task will be replaced
with the form data.
Experience Phase
Interactively
Validate
Elaborated
Process in
Sandbox
Define
Constructs
for Execution
Elaboration
on KPIs and
SLAs
Refine
Forms
Add
Operational
Characteristics
to Future State
Process

4.7.1 Automatic generation of forms for human tasks
This section discusses how to generate a basic form for a human task. You can generate
input or output forms for a human task just by clicking the menu, as shown in Figure 4-54.
If you have forms already created for the human tasks, you can associate forms with human
task and process inputs and outputs on the Forms tab in the Attributes view.
Figure 4-54 Generate Form

4.7.2 Customizing the appearance of the form
A plain input or output form using the input or output business item for the activity will be
generated. Using the Claim Intake process for our example, if we use the default form
generated from the claim business item for the human task, the user will enter data in a form
that contains the following inputs shown in Figure 4-55.
Figure 4-55 Plain form from automatic generation

Figure 4-55 on page 113 illustrates only the generic, generated form. You can proceed to
customize the form using palette in the Lotus Forms Editor (Figure 4-56) by changing colors,
rearranging the fields and inserting graphics into the form.
Figure 4-56 Lotus Form Editor Palette
If we customize a form based on the claim business item, we can present users with a better
form layout and format, allowing users at each step of the process to find the fields in the form
that are relevant to the current task. This will save users time in data entry.
Figure 4-57 on page 115 illustrates an example of our custom form after it is modified using
the editor.
Note: Detailed information about how to customize a form using Lotus Forms Designer is
beyond the scope of this paper. Instead, we illustrate a more customized form to give the
readers a sense of what is possible when the business analyst works with members of the
graphics/design team using Forms Designer.

Figure 4-57 Customized new form
4.8 Refine the process
After you have modeled your business process for deployment, you can test it iteratively on a
managed deployment environment server set up for you by the IT department. This will allow
you to further experience the process and continue to make refinements to the process where
needed before a larger scale deployment. If you include business measures in your process,
monitoring dashboards are automatically generated that you can also test. The testing
function is enabled when your business process is free of errors.
Important: After a form is associated with a human task or process, you or your form
designer can move fields to improve the form layout, add headings and graphics, format
fonts, and make other visual enhancements to the form. However, it is recommended that
you do not add, delete, or re-create form data in the form editor (Lotus Forms Designer). To
add or change form data fields, update the attributes of the relevant business items.
Note: Ensure that your business process shows no errors in the WebSphere Process
Server mode from within Business Modeller. You can test a business process if warnings
are still displayed in the Errors view. However, any business measures with warnings that
they require further editing to be monitored will not be deployed to the test server.

Experience phase.
4.8.1 Interactive process design (IPD)
In this next section, we discuss how to put the solution into action using the Interactive
Process Design (IPD) feature in WebSphere Business Modeler 6.2. Taking advantage of this
feature allows you to accelerate your time to value by creating business process applications
on your timeline to exactly match your line of business (LOB) requirements.
Steps to deploy the model through IPD.
Perform the following steps to deploy a model through IPD.
1. After you have completed the previous steps in this chapter, (Adding operational
characteristics, defining constructs for execution, elaborating on KPIs & SLAs, and refining
forms, and so forth) you are ready to deploy the model directly to the test server
environment that IT has prepared for you.
2. IT will create a XML file that points to the test server for your testing. Example 4-1 is an
example of this XML file.
Example 4-1 Test server configuration XML file example
<?xml version="1.0" encoding="UTF-8"?>
<rest:serverConfiguration xmlns:rest="http://rest.dtd.btools.ibm.com"
name="Test Server with Monitor" test="true" secured="true"
memberMapping="Claims-Model.rmf">
<description>
Test MDE with WPS with Monitor
</description>
<serverComponent
name="WebSphere Process Server"
Experience Phase
Interactively
Validate
Elaborated
Process in
Sandbox
Define
Constructs
for Execution
Elaboration
on KPIs and
SLAs
Refine
Forms
Add
Operational
Characteristics
to Future State
Process
Note: The section below describes the process for deploying the model through the IPD
process, a step which is primarily handled by IT.
Important: IT level activities happen in parallel with business activities in this stage.

configuration="https://bpmsol04.itso.ibm.com:9444/rest/serverComponent/componentCo
nfiguration">
</serverComponent>
<serverComponent
name="WebSphere Monitor Server"
configuration="https://bpmsol04.itso.ibm.com:9444/monitorServerComponent/component
Configuration">
</serverComponent>
<serverComponent
name="WebSphere Business Space"
configuration="https://bpmsol04.itso.ibm.com:9444/BusinessSpace/services/request/d
eployConfig">
</serverComponent>
</rest:serverConfiguration>
3. IT also needs to create a mapping file that maps roles in your model to runtime
WebSphere group definitions. This file is referred as Claims-Model.rmf and is shown in
Example 4-1 on page 116.
Example 4-2 illustrates the content of Claims-Model.rmf that describes user role mapping.
Example 4-2 Test Server Configuration xml file example containing mapping
<?xml version="1.0" encoding="UTF-8"?>
<logicalMapping:LogicalEntityRoot
xmlns:logicalMapping="http:///www.ibm.com/logicalMapping"
peopleDirectory="bpe/staff/samplevmmconfiguration">
<role name="Resources/Claims Analyst" uniqueName="cn=Claims
Analyst,o=defaultWIMFileBasedRealm" uid="BLM-d4d0c3677dc3828d70797439a9019443"
description="" groupName="Claims Analyst"/>
<role name="Resources/Pricing Specialist" uniqueName="cn=Pricing
Specialist,o=defaultWIMFileBasedRealm" uid="BLM-70808a7cdd51d9e1ac6209284295c3d4"
description="" groupName="Pricing Specialist"/>
</logicalMapping:LogicalEntityRoot>
In this XML file (Example 4-2), role name and uid are from your process model and
uniqueName and groupName are from your test server environment that IT sets up for
you.
Now you are ready to run your model on the server. Make sure you are in the WebSphere
Process Server Mode (Figure 4-59).
Figure 4-59 WebSphere Process Server Mode in Modeler

4. Click your process and select Test On Server (Figure 4-60).
Figure 4-60 Test on server
You will be prompted for the server configuration file (Figure 4-61) and user ID and
password for the test server login, which you should get from IT.
Figure 4-61 Select server configuration file

5. Click OK to deploy your model to the server (Figure 4-62). This can take several minutes.
Figure 4-62 IPD in progress
Introduction to the Business Space
1. After the model deploys successfully, it will display the login window of Business Space
(Figure 4-63).
Figure 4-63 Business Space login
2. Log in to Business Space with the user ID and password you received from IT. This puts
you in the Business Space where you can run and test your process you designed.

3. Change the theme of your space to the corporate theme that IT designed. Click Manage
Business Spaces on the upper right corner of your page, as shown in Figure 4-64.
Figure 4-64 Manage Business Space
4. Click Change in the Theme box of the manage space page (Figure 4-65 on page 121)
and then click Save.

Figure 4-65 Change the theme in Business Space
The customized theme for ABC Health co. ABC is displayed (Figure 4-66).
Figure 4-66 Customized theme

4.8.2 Testing with the real life scenario
The first step in testing your process should be to test the overall flow of your process, to
make sure that your activities execute in the correct order, and that your gateways and
connections work as expected. You should also make sure that the correct data is passed
from node to node as your process executes.
After the process has completed its execution, you can perform the following tasks:
See the path of the process execution in the Process Execution area. The execution path
is highlighted in the diagram.
See the list of activities that were completed during the process execution in the Process
Execution Trace widget.
View the data associated with each executed activity in the execution path by selecting an
activity in the Process Execution Trace and Data Values widget, and examining the
associated output data.
Return to the Start Process Instance widget and start another process instance for testing,
potentially modifying the process inputs or the values of configurable business rules to
verify that the process runs as expected
We can now test the claim process that we created in the modeler with the Business Space
without receiving any help from IT.
1. Select the process you want to run. In our example, Claim Process, and click Create.
Figure 4-67 Create a new Instance
Note: If you encounter errors in the process testing environment at any point during your
testing, click Request Help From IT button in the Process Execution Trace and Data
Values widget. When this button is clicked, the log files from your testing session are
packaged up for you to pass off to your IT developer for problem determination

2. TNext, the claim form will appear to be filled in to start the claim process. Enter the data as
you want to test and click Submit. (Figure 4-68)
Figure 4-68 Claim data

3. The Process Execution widget displays the process diagram that you are testing. After you
create a process instance for testing, the execution path through the process is highlighted
in the diagram.
As each activity is completed, it is added to the Process Execution Trace and Data Values
widget. The name of the completed activity and the output data from the activity is
displayed in this widget.
You can view the data associated with different points in the execution path by selecting an
activity from the list of completed activities in the Process Execution Trace and Data
Values widget. When you select an activity from the list, the output data for the selected
activity is displayed. Figure 4-69 shows the output data of Use Internal Billing activity in
the execution path list.
Figure 4-69 Execution Trace and Data

4. After you submit the claim, you can see the process is moving through the activities in your
process execution diagram and stops where it is waiting for human task. In our example,
because we entered a claim amount of $2000, our provider selection business rule will
send this claim to the human task where a billing provider is selected by a claim analyst.
See Figure 4-70.
Figure 4-70 Claim process execution
5. In the available task section (Figure 4-71), the select provider task is waiting to be claimed.
Accept the task.
Figure 4-71 Accept a Task

After you claim this task, the “Billing Provider Selection” form (Figure 4-72) will appear.
Enter a billing provider as below and click Submit.
Figure 4-72 Select Billing Provider
After you submit the form with a billing provider, the process will move again and stop at
the next human task for checking the pricing (Figure 4-73).
Figure 4-73 Claim Process Execution

6. In available task section (Figure 4-74), this pricing task is waiting to be claimed. Accept
this task.
Figure 4-74 Accept a Task
7. The “Verify Claim Pricing” form displays (Figure 4-75). Examine the claim and click
Submit.
Figure 4-75 Verify Claim Pricing form

After you submit the form, you can now see that all the activities in your process have
successfully finished in your process execution diagram and that the process has reached
an endpoint. See Figure 4-76.
Figure 4-76 Completed claim process
Reviewing initial KPIs from the scenario test
Next, we turn our attention to the KPIs that we created to monitor the process.
1. You can see the total number of claims for Medical type and Average Duration time for
Request/Receive Pricing human task in Figure 4-77.
Figure 4-77 Predefined KPIs
2. You can also see this in the Instances view as shown in Figure 4-78 on page 129,
displaying both the total number of claims of type Medical, and the average duration for
Request / Receive Pricing processing time.
Note: While this section provides an introduction to monitoring the KPIs, also refer to 5.6,
“Manage in real-time using KPIs” on page 149.

Figure 4-78 Process Instance view
Example of modifying the business rule parameter
We can run a different scenario by changing the value of the parameter in the business rule.
In our example, we modify the claim amount value, which is currently set to $1000. (For a
review of how we set up the initial business rule to a value of $1000, refer to 4.4.2, “Identifying
business rule candidates from the scenario process” on page 86.)
By increasing the value from $1000 (as it was initially set) to $2000, we can change the
behavior of our process. Now claims over $1000 and below $2000 will also be automatically
assigned to internal billing provider.
To modify the business rule parameter through the Business Space, perform the following
steps:
1. Click Add widgets and drag the Business Rules widget.
Figure 4-79 Business Rules widget

2. Within the “Business Rules” window, you will see the name of the business rule and the
value initially set. You can edit this value, then click Save (Figure 4-80).
Figure 4-80 Business rule change in runtime
3. Rerun the claim process with the modified business rule and observe the change by
submitting a claim amount between $1000 and $2000.
4. Click Claim Process and click Create to start a new instance of the process
(Figure 4-81).
Figure 4-81 Start a new Instance

5. Enter the same claim information, except increase the claim amount to a level between
$1000 and $2000. In our example, (Figure 4-82), we use $1800.
Figure 4-82 Claim data

6. Click Submit and watch the process execution path for the process flow.
In Figure 4-83, we can see that this time the process didn’t go to the Select Provider
human task due to our changed business rule. Instead, because the claim amount is less
than $2000, the claim is automatically assigned to internal billing to a billing provider
without first invoking the Select Provider human task.
Figure 4-83 Different process execution path
7. Finish your scenario test by completing the remaining tasks (for example,
Request/Receive Pricing) available on the task list.
4.9 Summary
This chapter has provided specific context to the Experience phase outlined in the IBM
Business Process Management Prescriptive Guide to Solution Implementation. This is the
third phase in the approach with the goal of capturing the business intent through
documenting and creating basic models for the business goals, objectives, and strategy.
Within the chapter, we reviewed the steps of the Experience phase using the specific context
from the Health Care Scenario demo introduced in 1.6, “Introduction to the health care demo

Specifically, we have discussed and illustrated how to accomplish the following steps within
the experience phase:
We have discussed which tasks could be best defined as a business rule to improve
process efficiency. See 4.4.1, “Defining business rule tasks” on page 85.
Building upon our rationale of which task step to implement as a business rule, we show
the reader how to create the business rule. See 4.4.3, “Steps to create a business rule
(Provider Selection)” on page 88.
We review the process to determine which process steps are defined as human tasks and
discuss the advantages of this. See 4.4.4, “Defining human tasks” on page 96.
We discuss which steps in the process would be good candidates to be implemented as a
service. Although the do not actually go into detail on how to implement these tasks as
services, we discuss the advantages of having these function as a service. See “Adding
services to deployable applications” on page 99.
Within the context of refining forms for input into the system, we illustrate how to create a
basic form from the business object in the claim process. We then also discuss how the
forms can be customized using Lotus Forms Designer. See 4.7.2, “Customizing the
appearance of the form” on page 113.
Moving forward, we discuss how you can use the feature within WebSphere Business
Modeler to deploy the process in a test environment and further experience testing with
the process. See 4.8.1, “Interactive process design (IPD)” on page 116.
Finally, we introduce the Business Space and discuss how to perform some basic
scenario testing for further refining the process. See 4.8.2, “Testing with the real life

Chapter 5. Manage
This chapter discusses activities you perform after the completion of the Experience phase of
your model process. This phase is referred to as the Manage phase. The emphasis in this
phase is the management of your business model process and its optimization. When
satisfied that your model process has met all your IPD cycle requirements, proceed to deploy
it into your Q/A or pre-production and then production environment. It is in this environment
that you can observe and record its production-like behaviors due to the availability of
real-time data. Based on the results of the analysis using real-time data, you can also make
improvements to optimize your business process.
In this chapter, we first review the objectives and goals of the Manage phase as outlined in
the IBM Business Process Management Prescriptive Guide to Solution Implementation. Next,
we introduce the Business Space and show you how to build and use a monitoring dashboard
to view, analyze, and act upon the real-time data results.
5

5.1 Goals of the Manage phase
As we discuss in this chapter, the objective of this phase is to now pro-actively empower
users to monitor and manage real-time business performance using key performance
indicators (KPIs) and alerts based on changing business conditions. You can then take
corrective actions against process instances where the process is not executing as efficiently
as needed.
During this phase, you can empower business users and system administrators by providing
customized, role-based access to their own Business Space.
Following the approach outlined in IBM Business Process Management Prescriptive Guide to
Solution Implementation, the high level tasks and activities within this phase are as follows:
(Optional) Empower business users to customize user experience by providing their own
Business Space
Assign access rights for system capability
Optimize work assignments
Govern change
Manage real-time business performance
Manage KPIs and alerts based on changing business conditions
Take corrective action against process instances
Figure 5-1 illustrates a visual representation of the tasks, highlighting that many of these
tasks are done in parallel, while the ability to take corrective action based on the results of
real-time data is an ongoing, iterative process.
Figure 5-1 Representation of the steps in the manage phase
Note: This step is optional and not appropriate for business environments where the
user environment is locked down and strictly regulated.
Manage Phase
Empower
Business
Users
Assign
Access
Rights
Manage
Real Time
Business
Performance
Optimize
Work
Assignments
Govern
Change
Take corrective action
using real time data

Chapter 5. Manage 137
5.1.1 Identifying the overlap between the Experience phase and the Manage
phase
As you proceed from the Experience phase into the Manage phase, and eventually into your
enterprise deployment, it is common to question where one phase ends and the other begins.
Figure 5-2 depicts the overlapping of the Manage and Deployment phases, because it is fairly
frequent and realistic that the two phases coexist. This reflects that the Manage phase
includes iterative improvements being conducted during the Deployment phase. Also, there
are no hard rules about when the Experience phase stops and when a Manage phase begins
in this iterative approach of continuous refinement.
Figure 5-2 Manage and Production
In this chapter we describe the detailed activities of the Manage phase and how you can use
the results of your analysis to enhance your business process. As a starting point, we review
what you want to manage.
5.2 What to manage
In the introduction sections of this chapter, we discussed the objectives of the Manage phase,
namely to pro-actively empower users to monitor and manage real-time business
performance. This is the goal. We now address the question of what measurement criteria
you can use to determine your efficiency. You can do this using status overviews of human
task processes, KPIs, and alerts based on changing business conditions.
A typical performance management dashboard will have a set of KPIs that measure process
performance against business targets, durations for key activities (for example, human steps)
in the process, and dimensional analysis that allows for analysis by different business
attributes of the process (such as channels, customer type, and so forth).
Dashboards also typically incorporates some drill down, enabling users to locate business
transactions of interest. Drill down can start from high level views or data analysis, to
visualizing a process flow, to locating individual human tasks in the process and taking action
to reallocate work.
Note: We will continuously refer back to this diagram throughout the chapter, using it as a
road map to highlight which specific objective and task we are addressing, based on the
activities outlined in the IBM Business Process Management Prescriptive Guide to
Solution Implementation.
Discover
Story board
Experience
Manage
Production

You will want to have a baseline measurement with basic KPI expectations set and some
basic measures abstracted. Assuming you have been following the approach outlined in the
IBM Business Process Management Prescriptive Guide to Solution Implementation, and
modelled in this IBM Redpaper publication, you should have identified the base KPIs and
reports initially during the Storyboarding phase, and then have refined these in the
Experience phase. (See Chapter 3, “Storyboarding” on page 35, and Chapter 4, “Experience”
on page 81.)
As we discuss in this chapter, (5.6, “Manage in real-time using KPIs” on page 149) you begin
to optimize the process by making incremental changes, reviewing and tuning your KPIs, and
eventually, acquiring additional measures for your analysis.
For the purpose of this scenario, we assume that the monitoring model, based off of the live
working demo from the fictitious Health Care Insurance Co, (See 1.6, “Introduction to the
health care demo scenario” on page 15) provides this data and that you have used this
information to set up an initiating process improvements space and to configure the widgets
within it. We also assume that you have made each member of your team a viewer of the
space.
5.3 Introduction to the Business Space
The core piece used to enable real-time management of your business efficiency is the
WebSphere Business Monitor component. The tool itself is a framework that acquires
measures and metrics based on data that your business process model carries called events
and renders them into various graphic displays and reports in a Web-based browser called
the Business Space dashboard.
Using the new Web 2.0 Business Space interface, users can create a personal business
space that combines business data from multiple sources. Each business space consists of
custom pages that display content in one or more views on each page. The views on a page
are enabled by widgets that are tailored for different types of dynamic and static content, such
as business process information, human task activities, process diagrams, KPIs, dimensional
views, and documents (such as spreadsheets and presentations). The content sources can
be local or remote. Each user can create multiple business spaces. The reports within the
Business Space are highly customizable to suit your needs.
Figure 5-3 on page 139 illustrates an sample dashboard with human task overviews, KPIs,
and other metrics. We will be discussing how to build this specific dashboard in subsequent
sections of this chapter.

Figure 5-3 Preview of the dashboard used for monitoring and managing
Note: If you have been following the chapters of this paper in sequence, then you have
already seen an introduction to the Business Space from the Experience phase and the
Interactive Process Design (IPD) step in which you first deployed your process model. (See
4.8.1, “Interactive process design (IPD)” on page 116).
The environment provided through the IPD step gives you a good idea of what the
Business Space is. It is especially beneficial in that it allows you to deploy your process
model, largely independent on IT involvement. This allows you to experience the Business
Space and refine your monitoring goals and metrics, while still being outside of the true
production environment. This keeps costs for changes and initial Business Space/KPI
tuning to a minimum, because it will require only minimal IT involvement and is handled
primarily by the line of business users. More importantly, your initial work in the IPD
environment ensures that after you eventually deploy the model into a production
environment, it should have a strong foundation for measuring KPIs accurately.
Keep in mind however that IPD is a limited environment. Therefore, you might not have all
the real-time data that you acquire through the production environment.
All KPIs
for claims
processed
by type
Avg.
Adjudication
by Claim %
Duration
KPI
Status of
Human
Tasks
Human task
workload:
actionable
functions
Duration
KPI with
target set
to trigger
alerts
Dimension
report for all
total claim
by type

Now that we have introduced the Business Space, we next activate and set the runtime
functions that you perform to configure your business space to monitor the specifics applied
to model process.
5.4 Empowering the user
An essential component of Business Process Management (BPM) is to enable the line of
business (LOB) to play an active role in defining how the business processes should be
managed. The scope of this role includes the ability to define the high-level business metrics
(with WebSphere Business Modeler), view operational and strategic business activity using
dashboards, be alerted to key situations, and use real-time data to improve business process
definitions (also working with WebSphere Business Modeler).
WebSphere Business Monitor raises the bar of empowerment so that business users can
customize the monitoring solution and dashboard to react to these changes rapidly, without
requiring IT to re-implement, test, and re-deploy the monitoring solution, as defined by a
monitor model. Business users can modify what is displayed, add new KPIs, or change the
thresholds on existing ones, and define alert situations and determine which alerts business
users want to be alerted to, without discussing changes with a developer or portal
administrator. This customization not only provides flexibility to the business, but it relaxes the
need for IT to define all KPIs and alerts up front, enabling businesses to react quickly to
changing conditions. At the same time, the routine workload on IT is reduced, enabling them
to focus on more strategic projects.
In the following two sections, we discuss how to customize the user LOB experience, and
assign specific roles and perspectives into the Business Space.
5.4.1 Customizing the user experience
In this section we transition into using the context scenario for Health Care Insurance Co.
ABC, and show you how to begin building a custom Business Space.
Figure 5-4 on page 141 illustrates where we are in the overall flow of tasks within the Manage
phase.
Note: For additional information about Business Activity Monitoring (BAM) using
WebSphere Business Monitor, refer to the IBM Business Process Management Reviewer's
Guide, REDP-4433.
Note: For all subsequent sections in this chapter, we are following the outlined activities
and tasks from IBM Business Process Management Prescriptive Guide to Solution
Implementation, but using the specific data and context from the model of the fictitious
company Health Care Insurance Provider, ABC. See 1.6, “Introduction to the health care
demo scenario” on page 15 for details on the scenario.

Figure 5-4 This section is focusing on these tasks
WebSphere Business Monitor Business Space framework is a highly extensible framework for
monitoring your business performance.
The Business Space dashboard is easy to use and graphics-rich to augment the user
experience.
You can easily perform custom branding to match your corporate identity. Not only can you
customize its look and feel to make it tailored for a specific group of users based on
access level and their perspective of the business, but you can easily brand and customize
the business space with graphics matching your corporate identity.
In the upcoming example, we brand the space for the fictitious scenario, “Health Care
Insurance Company ABC”. We have branded the log on panel and top frame banner, but
other options for customization exist.
Business space widgets from other components can be integrated to provide an
end-to-end monitoring solution across the enterprise. You can bring in data company-wide
from sources outside of Monitor and still be able to present it on the Business Space as
one place to look at.
There are predefined templates and themes to use and reuse so you do not have to make
up your own.
Easily collaborate between departments within enterprise and possibly outside.
A complete typical graphical business space configuration as shown in Figure 5-5 on
page 142 takes less than five minutes.
Manage Phase
Empower
Business
Users
Assign
Access
Rights
Manage
Real Time
Business
Performance
Optimize
Work
Assignments
Govern
Change

Figure 5-5 illustrates an example of a customized Business Space, using the data from the
scenario used throughout this paper, Health Care Insurance Co. ABC.
Figure 5-5 This business space report with all widgets for a at-a-glance look take a few minutes to configure
5.4.2 Assigning Access Rights: Why they are beneficial and how to assign
them
For collaborative business environments, you can configure role-based access in Business
Space to enable business users to create, modify, improve, or personalize their BPM
experience as business needs evolve. Customer-specific templates can replace
out-of-the-box templates in Business Space to simplify the creation of new spaces by users.
Note: Assigning access rights is an optional step in the process and is not appropriate for
business environments where the user environment is locked down and strictly regulated.
In these environment a collaboration with the IT infrastructure security resource
administrator is needed to get the access rights implemented.

Assigning access rights to the hosting environment
This section provides specific guidance on how to assign access rights for the Business
Space within the runtime environment.
1. Ensure that your user ID has the role and authority to administer and manage your
models. This can be quickly activated by the WebSphere Monitor Security administrator. It
is a business role as opposed to an IT role.
This function can be performed by a Monitor administrator through the WebSphere
Application administrative console under the Monitor Security function. Select the models
you want to allow a role to administer and below it, you assign that role to the User ID.
2. Go to the WebSphere Admin console and select Monitor Data Security Administration.
3. Select Claims_Processing_HL, and Claims Processing_LL, as shown in Figure 5-6.
Figure 5-6 Model to administer
4. Select the role you want this user ID to have.
5. Click Users, then Search, as shown in Figure 5-7.
Figure 5-7 Select role

6. In the search result list, add all applicable users to the window on the right
Figure 5-8 shows the different user IDs that are assigned to different roles for them to
administer the models for Health Care Insurance Co. ABC. This takes care of the
infrastructure security. It is allowing a user ID to access what model running on an
application server infrastructure.
Figure 5-8 Assigning role to user IDs
Assigning access rights for system capability
You now have access rights to the production environment infrastructure where the Health
Care Insurance Co. ABC process model is executing. As the administrator of the modeling
process for this workflow, you can decide with whom on your team you wish to share access
to your business space so that they can view your reports.
1. Configure role-based access control to process and system function and data according
to the business organization structure. This configuration should reflect the separation of
concerns in the business. That is, who needs access to what data and what actions those
users can take on the data. Access rights should be fine-tuned along the following
high-level areas:
– Process configuration and decision making, such as business rules and calendars
– Visibility into data about the process, such as monitor models & process administration
– Interactions with the process managed by the BPM system, such as human task roles
2. Define the realm of possibility for what process users are allowed to do by sharing your
business space.
– After user IDs are assigned to role groups above you can share your business space
reports with them. This sharing can eliminate the need to set up separate business
space report groups for each class of users or groups.
– In the Manage Business Space window, you can share your business space with other
users. You can let them view or edit the configuration settings of your business space if
desired.
3. To share your business space, go into the Business Space and click Manage Business
Spaces (Figure 5-9 on page 145).

Figure 5-9 Manage Business Spaces
4. Select the Share this Business Space check box to share it with User IDs you enter as
the viewers or editors, as shown in Figure 5-10.
Figure 5-10 Sharing business spaces

5. A search window facilitates the adding of user IDs if you do not have the exact ID. See
Figure 5-11.
Figure 5-11 Search for User IDs if you do not know the exact ID
6. In our example, we share the Business Space with John James. Figure 5-12 shows a
shared business space owned by User ID ‘admin’ sharing to User ID ‘jjames’.
Figure 5-12 Allowed user ID can either edit or view your Business Space
7. Figure 5-13 on page 147 shows a shared business space owned by User ID ‘admin’,
sharing to User ID ‘jjames’. Because that User ID is only allowed to view a shared
business space, it cannot modify any of modifiable features the configuration. Notice how
there is no Change button next to the Claims Processing Theme, when compared to the
image shown in Figure 5-13 on page 147.

Figure 5-13 View mode of sharing
8. If your User ID is allowed to edit a shared business space’s configuration, its context
sensitive controls will be exposed, as shown in Figure 5-14.
Figure 5-14 Edit mode of sharing
In the next section, we set up the all the necessary widget views in to monitor the human task
activities for the Health Care Insurance Co. ABC process model.

5.5 Monitoring the Health Insurance Claim Process
The objective of monitoring a business process is to acquire insight into its current
performance and, if applicable, look at possible improvements for any or all the activities in
the process. The goal is to validate the efficiency of the process, identify potential bottlenecks,
and where possible, fine-tune the process to reach higher efficiency.
In a real-time monitoring environment, your Business Space provides a single inclusive
dashboard that lets you see everything that is going on in your process through the service of
its reporting widgets. You use the widget reports on the Business Space to alert you of any
impending situation that you need to be aware of and might possibly need to act upon.
The progression of activities that we are following throughout this chapter is as follows:
1. Monitor the overall process and sub-processes.
2. Identify process bottlenecks and diagnose the cause of inefficiencies.
3. Remedy and fix.
4. Implement permanent changes.
Figure 5-15 illustrates a configured Monitor business space, based on the fictitious scenario
for Health Care Insurance Co. ABC. This shows all the KPIs to make anomalies stand out
within the Business Space.
In the following sections, we show you how to add widgets to your Business space and create
a dashboard similar to the one shown here for the scenario based on Health Insurance Co.
ABC.
Figure 5-15 A typically configured business space dashboard shows all important KPIs views at a glance

5.6 Manage in real-time using KPIs
Based on our work in the Storyboarding phase (Chapter 3, “Storyboarding” on page 35), and
further refined in the Experience phase (Chapter 4, “Experience” on page 81), we have a
solid understanding of KPI guidelines to help anchor a baseline monitoring scenario for
Health Care Insurance Co. ABC. In this section, we discuss how you can monitor these KPIs
and determine how your initially simulated data results are comparing to your real-time data
results. The objective is to analyze and monitor these KPIs in real-time with production
volume to get a feel of whether the targets from results of your simulation are in-line with the
real picture.
Figure 5-16 illustrates the focus of this section within the overall steps of the Manage phase.
Figure 5-16 Managing real-time business performance
5.6.1 Review of the KPIs to be monitored
To better understand a breakdown of the effort among the various claim types, we are looking
at the percentage of claims processing by type. We also wish to monitor the duration of some
human task processing. being the two primary goals of improvements.
You will setup the KPIs widget report to view the real-time results of the KPIs shown in
Table 5-1 on page 150.
Manage Phase
Empower
Business
Users
Assign
Access
Rights
Manage
Real Time
Business
Performance
Optimize
Work
Assignments
Govern
Change
Note: The KPIs shown here correspond with the KPIs introduced and analyzed in 3.9,
“Definition of control points to prepare experience” on page 77.

Table 5-1 KPI measurements for reporting
The KPIs in Table 5-1 are predefined in the model for Health Care Insurance Co. ABC claim
process. These are baseline KPIs. If, after the course of monitoring these, you have found
that they are inadequate to harness an improvement plan, you can add more KPIs or change
the target values at runtime.
Claim Type Activity Type Measurements
Handle Medical Automatic KPI < 22.5%
Handle Dental Automatic KPI < 22.5%
Handle Behavioral Automatic KPI < 30%
Notify Rejection Automatic KPI < 25%
Request/Receive Human task duration < 3 hours
Select Provider Human task duration < 1 hour

5.6.2 Setting up the KPI widget report
For this example, we set it up as a KPI to measure the duration of how long our Request for
Pricing human task would take on the average.
The following steps describe how to set up the widget report:
1. From within your Business Space, add a KPI widget from the Add Widgets icon. This is
found in the upper right corner of the Business Space panel (Figure 5-17). Select KPIs
then drag this on to the Business Space.
Figure 5-17 Drag to add a KPI widget
When dragged onto the Business Space, this creates a KPI widget window. The base
widget still needs configuration (Figure 5-18 on page 152).

Figure 5-18 KPI widget window
2. Select Configure (Figure 5-19).
Figure 5-19 Configure the widget window

3. This opens and displays your available deployed claim process model with its defined
KPIs (Figure 5-20). Expand and select the Duration KPI for your model.
Figure 5-20 Select and add predefined KPI from model to your Business Space
Note: The Mortgage Lending Showcase comes out-of-the-box as a sample for
experiencing with Monitor. You can use it KPI examples for reference as needed.

4. After selecting the KPI, click the Layout tab at the top of the window (Figure 5-21) to
define the layout. By default, the layout of a KPI widget is in table form. You can choose a
different layout if so desired.
Figure 5-21 Default KPI layout display is table form
5. After you click OK, the KPI widget will display within your Business Space (Figure 5-22).
Figure 5-22 Initial display of the Duration KPI
With a different layout, the same KPI widget can be graphically displayed differently.
Figure 5-23 is an example of how the Duration KPI would appear if displayed as a Half
Gauge layout.
Figure 5-23 Half gauge layout of duration KPI for Health Care Insurance Co. ABC claim process

You can also use the quick layout change icons to change layouts for KPIs (Figure 5-24).
Figure 5-24 Quick access to change KPI layout
6. Click the KPI range color band to get a range definition quickview (Figure 5-25). The range
shows the duration target set for this KPI in the claim process model.
Figure 5-25 Click color range to view KPI range value
7. To edit the KPI properties, click KPI Properties Action (Figure 5-26) to edit the properties
for this KPI.
Figure 5-26 Click Edit Properties to change KPI properties

a. A window displays, letting you change different properties for the KPI at runtime. There
are five tabs: Name, Definition, Range, Other, and Preview.
b. Figure 5-27 lists the things you can change in the Name tab. A modeled KPI name
marked with an asterisk (*) cannot be changed at runtime.
Figure 5-27 Things you can change in Name tab
c. The most common changes made to KPIs are under the Range tab. You can change
target, range values, and color properties (Figure 5-28).
Figure 5-28 Changing range value and colors for KPI
8. Add additional KPI widgets for Medical, Dental, Behavioral, and Rejection by following the
same procedure outlined above. You can add these by either adding new KPI widgets, or
modifying the widget configuration (Figure 5-29 on page 157).

Figure 5-29 Modifying widget configuration
9. After adding and positioning the KPI widgets within the Business Space near each other,
you can arrange to have a report view like Figure 5-30.
Figure 5-30 Changing color for individual half gauges

With some focus on how and where you place the widget reports within the Business
Space page, you can fit several widgets to gain an overview of KPIs and process status for
Health Care Insurance Co. ABC Claim Process, similar to the Business Space example
shown in Figure 5-31. In this example, we have added the following widgets:
– KPIs - including Duration, Total Claims Behavior (Current Month), Total Claims Dental
(Current Month), Total Claims Medical (Current Month)
Figure 5-31 Combining different KPI widgets for a total overview of Health Care Insurance Co. ABC process
In a later section, we configure additional advanced widgets for your reports (such as
dimension for further analysis). But now, we return to the basic KPIs report that you have just
set up and learn to use it to look at situations.
5.6.3 Setting thresholds and spotting bottlenecks in KPI Reports
Keep in mind that the objective of monitoring your KPI data is to identify inefficiencies and
bottlenecks in the process, so that if needed, you can take corrective action to remedy the
situation. After you have decided on a set measurement for a threshold, you can use this
baseline as the standard threshold to use the different alert modes of the Monitor framework
to notify you when a situation requires attention.
5.6.4 Using the KPI widget reports to identify bottlenecks
The most common widget report to use for spotting bottlenecks is the KPI widget view. We
illustrate this using the sample data and process from the fictitious scenario based on Health
Care Insurance Co. ABC claim process. Figure 5-32 on page 159 illustrates the report you
configured according to the KPI target table (Table 5-1 on page 150) at the beginning of this
chapter.
Note: The definition of a process bottleneck is as follows:a
An activity within an organization which has a lower capacity than preceding or
subsequent activities, thereby limiting throughput. Bottlenecks are often the cause of a
build-up of work in progress and of idle time.
A limiting factor on the rate of an operation.
a. http://dictionary.bnet.com/definition/bottleneck.html

Looking at the KPI reportyou just configured on the Business Space (Figure 5-32) , you can
see that the first duration KPI for the human task has spiked up into the red zone.
Figure 5-32 KPI Duration Report from Business Space
The meter has indicated that the target has been exceeded (Figure 5-33). Looking closer you
see that the human task average duration is too long per our measurement standards. The
target range is 30 seconds, and the actual value captured is 36 seconds, exceeding the target
range.
Figure 5-33 Duration KPI reporting target exceeded
Note: For illustration purpose we arbitrarily set the duration target for these KPIs to be in
minutes. This is to show that your target threshold has been reached and that there might
be a situation that need your focus in handling performance of some human tasks.

5.6.5 Reviewing the human task widget to analyze bottlenecks
Following on from the KPI report widget, the next report widget you want to look at is the
human tasks widgets to identify a delay in processing of human tasks. As we illustrate in the
screenshots, we are assuming that you have a completely configured business space that
includes both KPI widget reports and human task widget reports. Figure 5-34 illustrates a
listing of the human tasks and their status
Figure 5-34 The human task report from the Business Space
In the human task widget report, pay special attention to the tasks with a status of
unassigned. Normally, the reason for an increase in the duration of human tasks is that
they are backed up.
Based on the information listed in this widget report, you can count the tasks with a status
of unassigned, or tasks in the pending state. Figure 5-35 on page 161 illustrates a listing
of these unassigned tasks.

Figure 5-35 Human task widget
Figure 5-36 indicates how you can select a specific unassigned task and the take action on
this task.
Figure 5-36 Spotting unassigned human tasks
After you have acquired enough information about the root cause of a delay or excessive
duration in the processing of human tasks you can take action accordingly.
By clicking the Actions button, you are presented with several choices that you can
perform on these human tasks, with the most logical one being to re-assign it another
resource to work on. Or, you can contact the owners of those human tasks and have them
claimed.
For specific approaches on how better to manage human tasks based on the results from
the human tasks reporting, see 5.7, “Optimize workload assignments” on page 175. We
discuss how to how to administer and manage human tasks and ultimately reach the goal
of optimizing workload.

5.6.6 Dimension reports
Dimension reports are powerful tools for business intelligence work. Dimension reports
provide ways to divide your data and summarize it in a structured way, based on the specific
dimensions you select. This allows you to look at measures by more than one grouping
(dimension) at a time. For example, a dimension report could report the average of profit -
measured both by business unit, and by country in a single report. In our upcoming example,
we illustrate a simple example of measuring duration, reported in terms of claim type
(Medical, Dental, or Behavioral.)
Dimension reports can be added as a widget report to your Business Space, giving you the
capability to look at your data in different levels of granularity and analyze them according to
your specifications. You can also choose from a full library of chart templates to support your
reporting requirements. This capability is made possible through Alphablox, which is the
component and data repository underneath all the business dimension functionalities.
Steps to add a Dimension report
To add a Dimension report to your business space page, perform the following steps:
1. From within your Business Space, add a Dimension widget from the Add Widgets icon,
found in the upper right corner of Business Space. (For reference, refer to Step 1 on
page 151, and Figure 5-17 on page 151).
2. Select Dimension (Figure 5-37), then drag this widget out onto the Business Space page.
Figure 5-37 Select Dimension Report widget
3. Click Configure to start configuring the report. See Figure 5-38 on page 163 for visual
reference on configuring the parameters.
a. For Monitoring Model, select the Claim Process model name. After this is selected,
the available monitoring context and measures available will become visible.
b. Select the Monitoring Context. In this case, we wish to drill down within the context of
Claim Type.
c. Select the Dimensions and Measures on which you want to report.
Note:
The instance count measure is selected by default, you can configure to use it if
desired.
Be sure to adjust the Frequency to monthly if you want your data range to be
beyond a daily cycle.

Figure 5-38 Add model name and measures for Dimension report

4. Click Apply and Save.
Your default base report will appear. An example base report is shown in Figure 5-39.
Figure 5-39 Default base dimension report
To make your report more meaningful, you might need to set the chart type and data color.
The common things to change would be the chart type and color of the graph elements.
For example, in the example for Health Care Insurance Co. ABC, we want to have this data
displayed in the form of a pie chart.
5. To change chart type, click Chart from the menu (Figure 5-40), and select the chart type
from the drop-down menu.
Figure 5-40 Changing chart type
After changing the chart type to pie, the chart updates the report, as shown in Figure 5-41
on page 165.

Figure 5-41 Pie chart for Health Care Insurance Co. ABC claim intake by type
What does this Dimension report tell us?
In the example above, we can see that the Claims by Type % are different and exceeding the
range of our set baseline KPI parameters. For example, in Table 5-1 on page 150, we have
set the target percentage of total intake for medical claim types for Health Care Insurance Co.
ABC to a target level of < 22.5%. According to this report however, the actual value is
currently above 42%.
Assuming that the report was configured using multiple-dimensions (for example, we would
configure the report such that row dimensions are set for one parameter, column dimensions
are set for another, and finally, page dimensions are set for a different parameter,) then you
could click specific quadrants within the chart to see the values of the other dimension.
5.6.7 KPI administration
As the real-time monitor results give you a better sense of the accuracy of your existing KPI
baselines, you will most likely need to make fine-tuning adjustments to parameters going
forward. WebSphere Monitor Business Space allows for you to make these modifications,
adding and adjusting KPIs at runtime. The necessary changes can be across the end-to-end
solution or can be simple adjustments to the runtime business space setting. The most
common changes are changes to the range or target of the KPI to tune it.
Note: Dimension reporting offers many features and options. Most of the configuration
work can easily be done at runtime and can be modified as the line of business uses the
report and further refines their requirements. In this section we have just shown you the
most common widget features to configure your business space so you can be up and
running quickly and using your report productively.

In the upcoming section, we discuss the following two topics in detail:
Adding a KPI at runtime directly from within the Business Space
Setting KPI alerts
Adding KPI at runtime
A handy feature in WebSphere Business Monitor business space is the ability to add more
KPIs directly at runtime through the Business Space. This is much more flexible than
requiring you to re-deploy the model for each additional KPI you wish to track. One important
assumption however, is that you have already defined the metrics within your model to base
the KPI aggregation on. In other words, think of these as predefined columns in the table,
which you might want to use and display in certain situations.
Why is the feature beneficial?
The flexibility gives you the ability to mix and match all the metrics at runtime and see which
combinations work best and which ones you do not need before you decide on a permanent
model-based implementation. This feature is used frequently in first or second stage of
production deployment, as some metrics, when revealed within production context, cannot
need to be measured as a KPI as frequently as originally predicted.
This feature is helpful for temporary situations in production. For example, if your organization
wanted to monitor seasonal inventory (for example, snowboards in the winter) and get alerts
on these, then remove it for the rest of the year.
Adding a new KPI at runtime through the Business Space
To add a new KPI, decide on the metric and function that the KPI will be using, then perform
the following steps:
1. From the Add widget icon, pull down the widgets menu and invoke the KPI Manager
widget
2. Drag the selected widget into an open space on the Business Space page (Figure 5-42).
Figure 5-42 Configuring KPI at runtime-

3. From the Model dropdown list, select your model name to expose its KPIs (Figure 5-43).
Figure 5-43 Select the model to add your KPI
4. The window shows all the KPIs currently associated with your Health Care Insurance Co.
ABC model. (Figure 5-44)
Figure 5-44 KPIs for a model listed
5. Click Action to select the type of KPI you are going to add.
6. Enter the KPI name and the process that contains the metrics that you want the KPI to be
based on (Figure 5-45).
Figure 5-45 Adding a KPI at runtime

7. Click the Definition tab and enter the operator and the metrics for the KPI. (Figure 5-46)
Figure 5-46 Definition of KPI
8. Select the Range tab to enter the target, range values and color properties for the duration
KPI (Figure 5-47 on page 169).

Figure 5-47 Adding KPI duration
9. Add the range definition values and color as shown in Figure 5-48.
Figure 5-48 Adding KPI target, range values and colors for the Claim Processing model
After you have completed the previous steps, you will see the new KPI added in the KPI
Manager panel for the Claim Intake process (Figure 5-49).
Figure 5-49 New KPI added at runtime for Health Care Insurance Co. ABC Claim Process

After adding the new KPI at runtime and incorporating it into the KPI widget of the monitoring
business space for Health Care Insurance Co. ABC, you come up with something like
Figure 5-50.
Figure 5-50 Business space with new KPI duration added at runtime
KPI modifications in runtime versus manipulating in the business model
The question remains about when to make KPI adjustments in the runtime environment
through the Business Space versus when to go back and make the changes in the original
model, then re-deploy the model. The following section highlights some guidelines for when
and where to best make these changes.
When to use modeled KPIs versus dashboard KPIs
You can define KPIs either in the Monitor Model editor or on the WebSphere Business
Monitor dashboards. If you model the KPIs in the Monitor Model editor, there are some
restrictions on the changes you can make in the dashboards.
You create KPIs in the model for any of the following reasons:
KPIs created in the model (modeled KPIs) represent the intent of the organization that
authored the model. These KPIs can come from WebSphere Business Modeler and can
carry the intent of the business owner. The KPIs that are created in the dashboards,
although they can be used for the same purpose, can also be defined as needed for
personal or temporary what-if analysis.
Modeled KPIs are portable, making it simpler to deploy models with KPIs across
environments.
Modeled KPIs reduce the amount of configuration that is required after deploying a
monitor model.
The Monitor Model editor provides access to a KPI library of typically used KPIs,
categorized according to the type of process to which they apply. Selecting a KPI from the
library creates a KPI with that name in the monitor model. The KPI library is based on
APQC's Process Classification Framework (PCF). APQC is a member-based nonprofit
organization that provides benchmarking and best practices for approximately 500

organizations worldwide in all industries. PCF organizes operating and management
processes into twelve enterprise-level categories and more than 1,500 processes and
associated activities. PCF provides organizations with a shared language for
communicating with each other.
KPIs that you model in the Monitor Model editor can be personalized in the dashboards but
are restricted: The number of ranges and the IDs of those ranges cannot be changed
because the trigger conditions of triggers in the model might refer to them. However, the
ranges are still configurable at run time. The target and range values are treated as initial
values so that they can be changed to reflect changes in business conditions.
A target cannot be set to null at run time, again because the trigger conditions of triggers in
the model might refer to it.
KPI alerts
There are situations where you might want to set an alert based on a KPI threshold for when
there is claims processing backlog.
Within WebSphere Business Monitor, you can set dynamic alerts based on the KPIs you have
configured for a process, such as the example shown for the Health Care Insurance Co. ABC
claim process. You can have alerts sent to different recipients’ e-mail, pagers, cell phones, or
sent as a visual cue right on their dashboards. The PDA, pager, and cell phone options
empower the users with the flexibility to monitor business processes and address situations
without requiring direct access to a computer.
In the next section, we illustrate how to set up an alert report within the Business Space.
Steps to set an alert on a KPI
To set alerts on a KPI, follow these steps:
1. Click Alert Manager in the KPI widget as shown in Figure 5-51.
Figure 5-51 Alert Manager button to configure alerts

2. After clicking Action, the Alert configuration panel displays. (Figure 5-52) Click New Alert.
Figure 5-52 Adding KPI alert
3. Enter the condition for the alert to be sent and other properties. You can choose to define
your own content or use the default template. See Figure 5-53.
Figure 5-53 Add content for Alert
4. Select the recipient of the alert and the medium for delivery. In this scenario, we send the
alert as a dashboard alert, to appear directly in the Business Space (Figure 5-54).
Figure 5-54 Define recipient and medium for alert

Upon completion, you get the confirmation that the alert was created (Figure 5-55).
Figure 5-55 KPI Alert creation confirmation

5. Add an Alert widget view onto your business space, following the same procedure for
adding a report, such as the KPI Reports in 5.6.2, “Setting up the KPI widget report” on
page 151.
6. After the Alert widget is added, you will see the alert view showing your alert. This
happens on the business space because we chose to receive dashboard (business
space) alerts, and the condition for the alert has already happened because the KPI target
has been exceeded. This is shown in Figure 5-56.
Figure 5-56 Alert view showing alert triggered by KPI target being exceeded condition. Click the alert to view the content
For each alert, the user can click the alert to see details about why the alert was triggered, as
Figure 5-57 Click alert to view content

As shown in Figure 5-58, when you click an alert, the content of the alert displays the results
of the duration, illustrating details of the situation that we have set up to notify us when the
average duration for a human task in the Health Care Insurance Co. ABC claim processing
has exceeded the target threshold.
Figure 5-58 Alert content displayed
There are many more features of the WebSphere Business Monitor framework that can be
used to optimize and manage the Health Care Insurance Co. ABC claim process activities
workload. We have discussed the common way of using KPIs for monitoring, alerts triggering,
and usage of business human task administration to spot and resolve bottlenecks, and
streamline your day-to-day workflows.
5.7 Optimize workload assignments
In the remaining sections of this chapter, we discuss how you can use the information from
your analysis to both optimize workload assignments, and govern changes in monitoring and
optimizing your business process.
Note: Refer to“Related publications” on page 251 for additional resources on using
WebSphere Business Monitor to manage your business processes.
Key Point: This is a key value add from WebSphere Business Monitor. You can have a
better understanding of the data and efficiency of your process, so that your organization
can act accordingly to improve it.

You monitor and optimize workload assignments to reach maximum efficiency in your process
and to meet Service Level Agreements with the stakeholders and customers.
Figure 5-59 illustrates the focus of this section within the overall Manage phase.
Figure 5-59 We are in Optimize Work Assignments section of chapter
5.7.1 Objective of optimizing workload assignments
Let us clarify what we mean by optimizing workload assignments as it pertains to the IBM
Prescriptive Guide for Business Process Management. Optimizing workload assignments
consists of the following tasks:
An ongoing process of looking across the allocation of human tasks among organizational
team members to shuffle work around and respond to changing business conditions.
Insight into work allocation can be achieved through a combination of team-based task
views and monitor visualizations that can optimization decisions.
Efforts to optimize work can be performed by a business user playing a supervisory role or
as part of a empowered peer organizational structure.
Optimizing workload within the context of Health Insurance Co. ABC
During the Storyboarding phase (See Chapter 3, “Storyboarding” on page 35), you performed
initial simulations that provided insight into the benefits of improving the as-is business
process. During the Experience phase (See Chapter 4, “Experience” on page 81), and the
Manage phase, you analyze the KPI results to determine the bottlenecks within the human
tasks and determine how to best re-allocate the work.
For optimizing workload, we focus primarily on monitoring the human task activities. We are
working with the KPIs defined in Table 5-1 on page 150. To monitor all the human task
activities for the Health Care Insurance Co. ABC claims process, you start by setting up a
human task widget report on your new page of the Business Space.
Manage Phase
Empower
Business
Users
Assign
Access
Rights
Manage
Real Time
Business
Performance
Optimize
Work
Assignments
Govern
Change

Adding the human task report widget
Perform the following steps to add the human task widget:
1. In your new page, click the Add Widgets icon (Figure 5-60).
Figure 5-60 Adding a widget to the page
2. The widget icon will be positioned in the open space. Select the human task icon
(Figure 5-61).
Figure 5-61 Human task widget added: To be configured

3. Click Configure on the top right corner as shown in Figure 5-62, to configure your human
task report.
Figure 5-62 Click Configure button
4. The human task widget will display a window with all the variables available for you to
select for your report. You can use the Add All, Add One, Remove All, Remove One and
Sort fields. Click OK when done (Figure 5-63).
Figure 5-63 Select and add variables to your human task report
5. After configuring the human task widget, you should see an overview of the activities,
similar to that shown in Figure 5-64 on page 179. Note that you have a clear indication of
which tasks have been completed, and any which might still be in a pending state.

Figure 5-64 Human Task activities at a glance: all instances
Note: This is where you look to spot bottlenecks in the human task activities for the Health
Care Insurance Co. ABC process. Any activity that is incomplete (has a status still of
pending) and does not have an owner assigned should be verified and that it is in pending
state for a valid reason.

As shown in Figure 5-65, the final task is not yet completed, nor does it have an assigned
owner.
Figure 5-65 Unassigned human tasks should have a valid reason
6. From this list you can take action on the task yourself by claiming it and working on it, or
you can choose to transfer it to someone else (Figure 5-66).
Figure 5-66 Claim a task to work on it

7. Figure 5-67 illustrates the other actions you can perform on a specific task:
– Assign the task to a User ID
– Claim the task,
– Release the task,
– Transfer the task
Additionally, you can change the status to Active, Complete, or On Hold.
Figure 5-67 Available actions for administering human tasks
8. After a task is claimed it will move to the next state.
Note: In working with a business model processes, a flow diagram can be helpful to
visually help tell you where you are in the process and which activity is in a pending
state for you to monitor.

9. To add a flow diagram, follow the procedure mentioned in earlier steps to add a widget
onto a page view. In this case, you are adding a Diagram widget depicting the Health Care
Insurance Co. ABC claims processing flow. When set up, you will see the flow diagram
(Figure 5-68).
Figure 5-68 Flow diagram for Health Care Insurance Co. ABC claim process
10.From within the flow diagram, you can further drill down on a process activity (Figure 5-69
on page 183). If there is a sub-process diagram, you can see what state an activity is in
under the main process.

Figure 5-69 Drilling down on subprocess
In conclusion, optimizing workload is based on inspecting the queues and monitoring the
counts of the tasks being backed up and remaining in a pending state. You can decide when
and what to reassign or how best and to whom to redistribute the workload. The unassigned
tasks and the pending state tasks are what you want to pay attention to.
5.8 Govern changes
As you manage your business process using the data, the analytical tools, and the KPI
adjustment capabilities from WebSphere Business Monitor, you will eventually need to
manage change in the business process. While change is inevitable going forward, your
ability to manage and control the change in an organized way will be critical to success.
Change might be the result of the following circumstances:
Improvements which your organization implements to become more efficient
Changes required to adapt to varying market and competitive conditions.
As you adapt and make changes to the process, you need to maintain traceability for changes
in the process. According IBM Prescriptive Guide for Business Process Management, the key
factors for governing change are as follows:
Artifacts should be stored and managed in a common repository in order preserve
traceability across tools and changes being made.
Key stakeholders should be identified and a review process put in place to govern change.

Figure 5-70 illustrates the focus on governing change within the greater context of the
Manage phase.
5.8.1 Governing change within the context of Health Insurance ABC. Co.
You have implemented your first stage of monitoring capabilities. The KPIs you have defined
will need periodic refinements as the dynamics of your line of business change.
The exporting functionality of Monitor business space can be used to unload the real
measurements acquired during the course of your monitoring periods. This data can be
fed back into the front-end modeling process for re-simulation.
This continuous cycle can help hardening your optimization of the Health Care Insurance
Co. ABC process.
This data can also be warehoused for future business intelligence purposes. Going
forward, you can conduct, periodic, regular analyses of running process results to institute
additional measures or even more monitor models to the greater enterprise.
Exporting monitoring data
You can export monitoring data to capture a specific point in time for the process, then archive
this information to use it for future reference or comparison.
To export monitoring data to an XML file that can be used in WebSphere Business Modeler,
use the Export Values page widget. Add the widget to an empty space on the Business
Space page as has been described in earlier sections of this chapter.
Manage Phase
Empower
Business
Users
Assign
Access
Rights
Manage
Real Time
Business
Performance
Optimize
Work
Assignments
Govern
Change

To export monitoring data to an XML file, perform the following steps:
1. Select the model you want to export.
2. Choose either All versions of the selected model or Only the selected model. (See
Figure 5-71)
a. (Optional) To view the data, click Preview Data.
3. To export the XML file, click Export.
Figure 5-71 Export Values widget of Monitor business space
5.9 Chapter summary
In this chapter, we have first defined what is covered in the Manage Phase and discussed the
value provided by giving you the ability to monitor and adjust your KPIs, set alerts, and
manage real time business performance.
This chapter provides specific examples on how to configure the Business Space specific to
your monitoring needs, using the context and business process from Health Care Insurance
Co. ABC for specific examples.
Note that business processes will not remain static, but will need to continually be adjusted
and improved to continuously adapt to market conditions. Accordingly, this will be an iterative
process of analyzing the data, then taking corrective action using real-time data.
Key value point: During the Manage phase, you pro-actively empower users to monitor
and manage real time business performance using KPIs and alerts based on changing
business conditions. You can then take corrective actions against process instances where
the process is not executing as efficiently as needed.

Figure 5-72 shows all of the tasks involved in the Manage phase, with the ultimate goal to be
taking corrective action based on the actual data from process execution.
For further details on the manage aspect of BPM refer to the references listed in “Related
publications” on page 251.
Manage Phase
Empower
Business
Users
Assign
Access
Rights
Manage
Real Time
Business
Performance
Optimize
Work
Assignments
Govern
Change

Chapter 6. Deployment
The previous chapters in this IBM Redpaper publication focused on the business phases of
business process management (BPM), targeting a fundamental re-thinking of companies’
processes to achieve both efficiency and most effectively realize their business goals. The
work in the earlier phases, namely, Discovery, Storyboarding, Experience and Manage,
allows the business leaders and business analysts to review, re-engineer, and streamline
their business goals within BPM. Their focus is as follows:
Concentrate on the processes that really matter to the organization’s business goals.
Be customer oriented, by putting both external customers and internal peers into the
center of all change considerations.
Re-examine and possibly change the old way of working.
Change existing structures to match the new processes.
With this chapter, we focus on working with the IT team to implement the BPM solution. To
make BPM a success, it is fundamental and highly important to involve IT. The full strength of
BPM is only realized if and when the documented and simulated model finally is also
executed, monitored, and then delivers real data to be improved. A BPM approach must use
all possible and efficient information technologies to ensure a successful implementation of
the new core business processes.
This leads to the fifth point of the BPM prescriptive guide approach, Deployment. Deployment
requires IT to offer all possibilities to make the business processes executable and
automatized across the company.
We begin with discussing an approach to thinking about Deployment, namely what needs to
be done where and by whom. We begin with the foundation of service-oriented architecture
(SOA) and how this fits with BPM. We then proceed to outline the specific deployment steps
necessary to arrive at a complete solution in a production environment.
6

6.1 Objectives of the steps of the deployment phase
The objective of the Deployment phase is to put the solution into production. More specifically,
it focuses on the following tasks:
Design BPM solution architecture
Set up IT environments
Prepare and deploy production artifacts
Unit test solution
Monitor health of your solution to ensure process integrity
IT focuses on Deployment. The objective of Deployment is to transform the outcome of the
Interactive Process Design (IPD) into a production ready executable application. Concretely,
this means that a responsible IT team will have the following responsibilities:
A capability to assemble and deploy business processes. This relates to the
transformation, packaging, distribution, and installation of the models created during the
modeling activity in the Discovery, Storyboarding, Experience and Manage phases. The
transformation involves applying a model-driven architecture (MDA) approach to transform
platform-independent models to technology-specific implementations. The packaging and
distribution is driven by the logical system topology for the running of the models.
An infrastructure to be used to run a process and provide possibilities to monitor the
processes.
Business processes are accompanying the whole development of a product and going
horizontally through the company. They easily spawn different IT systems from different
departments using different protocols. Nobody can afford a “Big Bang” approach. It is
important to rely on existing IT systems and departments. This presents an IT department
with a huge amount of technical integration challenges, as shown on Figure 6-1.
.
Figure 6-1 Common integration challenges
HTML
APIs
CICS
CGI
DOS
EJBs
GIFs
JNDI
JCA
IMS
J2EE
JMS
VM
MDBs
MVS
Network
Queues
iSeries3270
RMI
JSPs
RPCs
Servlets
SOAP
Web Services
SQL
Linux
URLs
JPGs
XML
IIOP
DB2
C
DASD Java
EIS
ERP
CORBA
COBOL
WSIF
HTTP
WSDL
JDBC

Chapter 6. Deployment 189
It is not recommended to integrate all possible protocols from scratch. Rather, we recommend
using a strong integration tooling and infrastructure such as WebSphere Integration
Developer.
We selected the following approach during the Deployment chapter. It is oriented on the
approach of the IBM Business Process Management Prescriptive Guide to Solution
Implementation. Figure 6-2 illustrates these tasks from a visual model perspective.
Figure 6-2 Visualization of the steps performed in the Deployment phase
The steps outlined within this chapter are as follows:
Perform IT assembly
Instrument process for monitoring and generate monitoring models
Assemble user experience
Test in universal test environment
Prepare production environment
Deploy artifacts
Monitor health of processes
Throughout this chapter, we use WebSphere Integration Developer to assemble the solution.
In addition to steps above, we recommend spending time on choosing your reference
architecture and creating your target architecture. A well-chosen approach for an integration
architecture is crucial for BPM to be deployable in all its strength. This paper, however, does
not cover architecture topics.
Note: More details on WebSphere Integration Developer, can be obtained in the IBM BPM
Information Center, at the following Web page:
bm.websphere.wps.620.doc/welcome_wps_dev.html
Deployment Phase
Perform
IT Assembly
Assemble
End User
Experience
Instrument Process
and Generate
Monitoring Models
Test in
Universal
Testing
Environment
Prepare
Production
Environment
Monitor
Health of
Process
Deploy
Artifacts

6.2 Perform IT assembly
Deployment phase.
Figure 6-3 Perform IT assembly
6.2.1 Prepare export
To use the maximum generation capabilities of WebSphere Business Modeler, the following
steps must be performed on every automatic Web service invocation. If the steps are not
performed, adaptations to namespace and porttype might be necessary in further steps.
Figure 6-4 illustrates defining the interface for the WSDL in prepararation for the export by
defining the namespace and porttype information.
Figure 6-4 Add namespace and porttype information
Figure 6-5 on page 191 illustrates adding the component type and selecting the binding type.
Deployment Phase
Perform
IT Assembly
Assemble
End User
Experience
Instrument Process
and Generate
Monitoring Models
Test in
Universal
Testing
Environment
Prepare
Production
Environment
Monitor
Health of
Process
Deploy
Artifacts

Figure 6-5 Add component information and select binding type
Note: Currently, only the “Web Service binding”implementation type is supported.

6.2.2 Exporting WebSphere Business Modeler artifacts
The next steps perform an export of artifacts from WebSphere Business Modeler. A Project
Interchange, also known as PI, is an archive file that can be easily exchanged between
WebSphere Integration Developer environments. A PI can also be used as input for manual
commandline build named “ServiceDeploy”.
1. Click File Export (Figure 6-6). A dialog box will display.
Figure 6-6 Select Export from the Menu

2. Select “WebSphere Integration Developer” as the format or product to which you want to
export. This is depicted in Figure 6-7.
Figure 6-7 WebSphere Integration Developer as Export format
3. Type a directory to which to export (Figure 6-8). Click Next to continue.
4. Select the “Export entire project and related projects” radio button (Figure 6-8). Click Next
to continue.
Figure 6-8 Type directory

Figure 6-9 WebSphere Integration Developer export details
5. Leave defaults and click Next to continue (Figure 6-10).
6. Select the Export business measures as a monitor model or models check box
(Figure 6-10). Click Next to continue, as shown in Figure 6-11 on page 195.
Figure 6-10 WebSphere Integration Developer business measures export

Figure 6-11 Click Finish to end export
Figure 6-12 shows the exported PI files.
Figure 6-12 Exported project interchange files
Note: More information about exporting from WebSphere Business Modeler Advanced to
WebSphere Integration Developer can be obtained at the following Web page:
bm.btools.modeler.advanced.help.doc/doc/tasks/transforming/exportingtowid.html

6.2.3 Importing Project Interchange into WebSphere Integration Developer
Perform the following steps to edit the generated business process model and monitor model
in WebSphere Integration Developer and WebSphere Business Monitor toolkit.
The following steps are going to lead through an import of a PI into WebSphere Integration
Developer:
1. After having started WebSphere Integration Developer using a new Workspace, select
File Import from the main menu (Figure 6-13).
Figure 6-13 Select Import from the menu

2. Import Claims-Model Project Interchange (Figure 6-14).
Figure 6-14 Import Claims-Model Project Interchange

3. Make sure to select the correct content in the PI file. In this case the whole content is
necessary. Refer to Figure 6-15 for details. Click Finish to end the import process.
Figure 6-15 Project Interchange Contents
Figure 6-16 illustrates the hierarchy tree which becomes visible inside of WebSphere
Business Modeler once the import is complete.
Figure 6-16 Explore imported artifacts

The following three artifacts have been imported:
Claims-Model
This artifact contains the exported BPMN flow translated to BPEL. The flow can be
opened within WebSphere Integration Developer and customized.
Claims-Model_impl
This artifact contains a series of mediation modules (dynamic service gateways), which
are guaranteeing the connectivity between the BPEL process module and underlying
services. Figure 6-17 shows the assembly diagram of the module in question.
Figure 6-17 Mediation modules (service gateways) mediating between business process and
underlying services
Claim-Model_lib
This artifact contains all interfaces and xsd’s from the business process layer. It also
contains interfaces of outbound Web services.
Note: Each of these mediation modules contains a mediation flow with a Dynamic
Endpoint Lookup Primitive. Using this technology, the real endpoint can be determined
through a lookup into the WebSphere Service Registry and Repository.

To make the further steps easier and more meaningful, and to permit execution at an early
stage, we implemented these services as stub services. These stub services simulate real
services. Stub services are depicted on Figure 6-18.
Figure 6-18 Implemented dummy Web services
Each of the service interfaces referenced by the initial WebSphere Business Modeler
Project has been implemented by a dummy Web service.
We explicitly generated exports with Web services bindings.
When generating a Web service binding automatically an endpoint and port will be
generated. When deployed, each of the components below are accessible as Web
services.
Note: The service interfaces need to be implemented to enable the connectivity of the
BPEL process to underlying services. Typically, these services can be implemented as
mediations negotiating between the generated mediations (Claims-Model_impl) and the
corporate service layer. These services are included in a module named “Claims Services.”

The next steps explained within section below are going to show how these Web services can
be published in the WSRR with goal that they are found out of the Mediation Modules
generated during the export to WebSphere Integration Developer.
6.2.4 Loading interface files into WebSphere Service Registry and Repository
The following steps show how to load interface files into WebSphere Service Registry and
Repository. The generated WSDL files, including their service endpoint information, needs to
be exported to the file system. It is advised to export these WSDL’s directly using the Archive
Wizard within the export menu. The next steps show how to export WSDL files to a zip
archive and import these files into WSRR.
1. Right-click “Claims-Model_lib” to obtain the context menu. Select Export from the menu.
This is depicted on Figure 6-19.
Figure 6-19 Select Export from the context menu
Note: The following article explains in detail how to implement service gateways with
endpoints in WSRR:
http://www.ibm.com/developerworks/websphere/library/techarticles/0906_jackson2/
0906_jackson2.html

2. Select General Archive File (Figure 6-20).
Figure 6-20 Select archive file
3. In the Export dialog box, clear all files other than WSDL or XSD (Figure 6-21). Only these
files are to be imported into the WebSphere Registry and Repository. Click Finish to
complete.
Figure 6-21 Select WSDL and XSD files and click finish

4. Open a Web browser and access the following URL:
http://localhost:<your_port>/ServiceRegistry
5. Log on to the page and select Service Documents WSDL Documents (Figure 6-22).
Figure 6-22 Selecting the path and proper document type

6. Browse to the ZIP file (In this case WSDL.zip), select ZIP/JAR as a document type and
click OK to continue.
7. Click Finish and wait until documents successfully uploaded (Figure 6-23).
Figure 6-23 Review service documents to import (WSDL’s)
If required, the endpoint can now be changed within the WebSphere Service Registry and
Repository console. Figure 6-24 on page 205 depicts this. It can be obtained after navigating
to WSDL Documents ClaimServices_HandleBehaviorExport1.wsdl
HandleBehaviorExport1_HandleBehaviorHttpService
HandleBehaviorExport1_HandleBehaviorHttpPort
HandleBehaviorExport1_HandleBehaviorHttpPort_SOAPAddress Edit
Relationships.
Note: The information center for WebSphere Service Registry and Repository Information
Center is an ideal place to explore usage of the tool:
http://publib.boulder.ibm.com/infocenter/sr/v6r2/index.jsp?topic=/com.ibm.help_
swg.ic.doc/wsrr_homepage.htm
Note: WebService Endpoints can be changed using the WebSphere Service Registry and
Repository console. This makes dynamic change easy, and guarantees services remain
loosely coupled.

Figure 6-24 Change Web service endpoint
6.2.5 Mediation modules and business integration modules
A module is a unit of deployment that determines which artifacts are packaged together in an
enterprise archive (EAR) file. Components within a module are collocated for performance,
and can pass their data by reference. A module can be seen as a scoping mechanism, that is,
it sets an organizational boundary for artifacts.
A module is a composite of service components, imports, and exports. The service
components, imports, and exports reside in the same project and root folder, which also
contains the wiring that links the components and the bindings needed for the imports and
exports. A module can also contain the implementations and interfaces referenced by its
components, imports, and exports, or these can be placed in other projects, such as a library
project.

There are two types of modules:
Business integration modules
Business integration modules contain a choice of many component types, often used to
support a business process.
Mediation modules
Mediation modules contain up to one component, one or more mediation flow
components, plus zero or more Java™ components that augment the mediation flow
component.
Before entering into details we would recommend exploring the various components we
obtain after exporting the WebSphere Business Modeler workspace into WebSphere
Integration Developer. A good practice consists of generating an integration solution out of the
imported artifacts which gives a good overview of all the artifacts from the Workspace. The
following steps show how to create a new integration solution.
1. Click New in the upper-right corner of the Business Solutions Project view (Figure 6-25).
Figure 6-25 Create new Integration Solution
2. The “New Integration Solution” dialog box (Figure 6-26) displays. Enter a name such as
Better Healthcare. Click Next to continue.
Figure 6-26 Type Integration solution name

3. Select artifacts to be included in the integration solution (Figure 6-27),and click Next to
continue.
Figure 6-27 Select modules to be included in an integration solution
Note: The existing artifacts include a project named Claims Services, which is basically a
dummy service, of which creation is beyond the scope of this paper. More on the dummy
services can be found in 6.2.3, “Importing Project Interchange into WebSphere Integration
Developer” on page 196.

4. Open the integration solution and review content. The integration solution is depicted in
Figure 6-28.
Figure 6-28 Review Better Healthcare Integration Solution
(1) shows a module named Claims-Model. It includes the generated BPEL business
process, generated forms, and maps associated to the BPEL process.
(2) shows a module named Claims-Model_impl. It includes the generated mediation
modules which guarantee dynamic lookup to the services (which are dummy services for
the moment and will really be implemented in the following section of this paper).
(3) shows a module named Claims Services. It includes the dummy Java services
implemented as Web services with SOAP/HTTP bindings.
Note: As of version 6.2.0.1 only Web services bindings are supported in IPD. Future
versions will also implement other bindings such as JMS or SCA.

Why are there two module types?
A business integration module is primarily designed for business processes.
A mediation module is like a gateway to existing external services, which is common in
enterprise service bus architectures.
Mediation modules included mediation flows and are responsible to intercept and modify
messages that are passed between existing services (providers) and customers (requesters)
that want to use those services. They are most commonly used for transforming data and
accessing header information, such as JMS, MQ or SOAP headers. Mediation modules can
be deployed on the WebSphere Enterprise Service Bus or the WebSphere Process Server.
Introducing mediation flows between services enables you to process the messages that are
being passed between these services. A message is a communication sent from one
application or service to another application or service. Mediation flows provide the logic that
processes the messages. For example, mediation flows can be used to find services with
specific characteristics that a requester is seeking and to resolve interface differences
between requesters and providers. For complex interactions, mediation primitives can be
linked sequentially. Typical mediations include the following processes:
Transforming a message from one format to another so that the receiving service can
accept the message
Conditionally routing a message to one or more target services based on the contents of
the message
Augmenting a message by adding data from a data source
Business integration modules include service components that can be implemented
according to a variety of service implementation types:
Java
An implementation of a component in Java is referred to as a Java object.
BPEL4WS
A BPEL process component implements a business process.
Selector
Integrated applications contain many ways to interact. A selector is used to route an
operation from a customer application to one of several possible components for
implementation.
Human task
A human task component implements a task done by a person. It represents the
involvement of a person in a business process.
State machine
state machine is an alternative way of creating a business process. A state machine is
suited for processes related to changing states rather than a flow of control. A state
defines what an artifact can do at a point in time. A state machine is an implementation of
this set of states. A state machine is implemented as BPEL.
Note: More details on mediations can be obtained in the IBM Information Center at the
following Web page:
bm.wbit.620.help.sib.mediation.ui.doc/topics/cmediations.html

Interface map
An interface map resolves differences between the interfaces of interacting components.
Human task
A human task component implements a task done by a person. It represents the
involvement of a person in a business process.
Business rule
Business rules complement business processes and state machines. If there is condition
with a variable, for example, a business rule can change the value in that variable at run
time. Created by a visual programming language, a business rule makes a decision based
on context. The decision can be simple or complex. Business rules are nonprocedural and
the rules can be changed independently of an application.
Standalone reference
Stand-alone references are references to applications that are not defined as Service
Component Architecture components (for example, JavaServer Pages or servlets).
Stand-alone references permit these applications to interact with Service Component
Architecture components.
6.2.6 Assembling a Web service
The goal of this section consists to replace an existing Dummy Service named “Select
Provider Impl” by a call to an existing WebService. As depicted in Figure 6-29 on page 211
the situation after export from Modeler to WID is as described in (1). IPD generates a process
and a gateway permitting to call underlying process services. These process services
however are usually decoupled from the underlying corporate service layer, meaning that a
gateway and maps respectively logic needs to be written to permit the communication to
occur successfully. This is shown under (2).
Note: More details about the Service Component Architecture, included in WebSphere
Process Server and WebSphere Enterprise Service Bus can be found in the IBM
Information Center at the following Web page:
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.wbit.620
.help.prodovr.doc/topics/csrvcomparch.html
Note: This section shows how to couple IPD generated processes to the underlying
corporate Web services, without creating dependencies between the process services
datamodel and the corporate datamodel. The process services datamodel needs to be
capable to evolve freely and regenerated without that underlying maps have to be
changed. The same counts for the corporate services datamodel which needs to be
capable to evolve freely without that the process is impacted.

Figure 6-29 Situation after export
Figure 6-30 shows Java components exposed as Web services. These Java components
need to be individually linked to Web service exports.
Figure 6-30 Java components exported as Web services
Claims
Process
Gateway
to Process
Services
Gateway
to Corporate
Services
Corporate
WebService
WebSphere Service Registry
and Repository
1. 2.

6.2.7 Integrate with WebSphere MQ
IBM WebSphere MQ is a popular middleware set of products that provide a well-known set of
messaging communications between applications, which can be on many dissimilar systems.
Integration with WebSphere MQ is important whenever data needed in the business process
needs to be called from services invocable through MQ. The Web page in the note below
describes how a WMQ message maps to service component architecture (SCA) artifacts.
That is, how a message maps to a business object and how input and output from a
WebSphere MQ client maps to an interface's operations. Data bindings and an important
function called the function selector as applied to WebSphere MQ are discussed. You are
then led through the generation of an MQ import and export binding.
A detailed description on how to use imports and exports with MQ bindings are beyond the
scope of this paper.
6.2.8 Integrate with JMS
JMS is a standard API for sending and receiving messages. It allows components based on
the Java 2 Platform, Enterprise Edition (J2EE) to create, send, receive, and read messages.
Integration with JMS is important when a service (for example, a Message Driven Bean) is
only callable through JMS queues. The Web page in the note below shows how a JMS
message maps to SCA artifacts. That is, how a message maps to a business object and how
input and output from a JMS client maps to an interface's operations. Data bindings and the
function selector are discussed. You are then led through the generation of a JMS import and
export binding and presented with some standard applications that make use of the JMS
binding.
Note: More information about integrating services with Web Services Bindings can be
obtained in the IBM WebSphere Enterprise Service Bus Information Center at the following
Web page:
.help.basics.doc/topics/cgenwsbnd.html
Note: More information about MQ Bindings can be obtained in the WebSphere Enterprise
Service Bus Information center. at the following Web page:
bm.wbit.620.help.messaging.doc/topics/tgenmqbnd.html
Note: More information about JMS bindings can be found in the WebSphere Enterprise
Service Bus Information Center. at the following Web page:
.help.messaging.doc/topics/cjms.html

6.2.9 Integrate with JCA adapters
IBM adapters allow you to integrate enterprise applications, and data storage facilities, in a
service-oriented way. Adapters expose low-level EIS functions, or events, in the form of a
service.
Adapters are sometimes referred to as resource adapters, and provide a standard interface to
proprietary systems. Using standard interfaces avoids the maintenance issues associated
with nonstandard solutions.
Some adapters come with WebSphere Integration Developer and are licensed for production
use, others are only for development purposes. That is, they can be used to develop and test
an application. Generally, after you deploy your application to WebSphere ESB, or
WebSphere Process Server, you will need a licensed runtime resource adapter.
There are two types of IBM adapters:
WebSphere adapters, also referred to as JCA adapters.
WebSphere Business Integration adapters.
Both types of adapter can be split into two classes:
Technology adapters
Technology adapters let you integrate files, FTP, databases, and e-mail. These adapters
come with WebSphere Integration Developer and are licensed for production use with
WebSphere ESB and WebSphere Process Server.
Application adapters
Application adapters let you integrate enterprise application suites, such as SAP
Exchange Infrastructure (XI).
WebSphere Process Server and WebSphere Integration Developer supports a variety of
Adapters:
IBM CICS® ECI Resource Adapter version 7.1.0.2
IBM IMS™ TM Resource Adapter version 9.1.0.2
IBM WebSphere Adapter for E-mail version 6.2.0
IBM WebSphere Adapter for FTP version 6.2.0
IBM WebSphere Adapter for Flat Files version 6.2.0
IBM WebSphere Adapter for IBM i version 6.2.0
IBM WebSphere Adapter for JDBC version 6.2.0
IBM WebSphere Adapter for JD Edwards EnterpriseOne version 6.2.0
IBM WebSphere Adapter for Oracle E-Business Suite version 6.2.0
IBM WebSphere Adapter for PeopleSoft Enterprise version 6.2.0
IBM WebSphere Adapter for SAP Software version 6.2.0
IBM WebSphere Adapter for Siebel Business Applications Version 6.2.0
Note: WebSphere Adapters are based on Java 2 Platform, Enterprise Edition (J2EE)
Connector architecture (JCA), and are the recommended adapters to use with WebSphere
ESB and WebSphere Process Server.
Note: WebSphere Business Integration adapters reside outside of WebSphere ESB or
WebSphere Process Server. The run time communicates with this type of adapter through
a Java Message Service (JMS) transport layer.

6.3 Generate and customize monitor models
The next step in the Prescriptive Guide Approach is to generate and customize monitor
models. It includes the following processes:
Export of a monitor model to WebSphere Integration Developer
Customization of the monitor model
Generation of Monitor EJB projects
Deployment to the runtime for testing purposes
Deployment phase.
Figure 6-31 Instrument process and generate monitoring models
Note: More information about working with adapters can be obtained in the IBM
WebSphere Enterprise Service Bus Information Center at the following Web page:
.help.adapter.emd.ui.doc/topics/timpexpapps.html
Important: Adapter patterns provide a quick and easy way of creating a service with an
adapter. The adapter patterns wizard can save you time in creating a service. In a few
pages containing a few fields, you can generate a service. In many cases, a service
generated from an adapter pattern meets the requirements for the service you want to
create.
The adapter patterns wizard can be used with the following adapters:
WebSphere Adapter for E-mail
WebSphere Adapter for FTP
WebSphere Adapter for Flat Files.
Deployment Phase
Perform
IT Assembly
Assemble
End User
Experience
Instrument Process
and Generate
Monitoring Models
Test in
Universal
Testing
Environment
Prepare
Production
Environment
Monitor
Health of
Process
Deploy
Artifacts

Generate the J2EE EARs necessary for all of the business measures. It is possible to test in
the iterative development environment prior to this step, but deployment requires that these
artifacts be generated. This allows for the KPIs and other data to be collected, and for the
business space widgets to be configured properly. After you have a satisfactory baseline
model from the IPD environment you can export the model from Modeler into the WebSphere
Integration Developer Toolkit to generate the J2EE monitoring model EAR.
The model you have from the Experience phase is all that is necessary for you to deploy into
the production environment. There are cases where you might want to augment the model
created from Modeler with some more features and metrics beyond what the Directly
Deployed (D2D) environment gives you. You can do so easily in the WebSphere Integration
Developer Toolkit.
We describe how you can import the model from modeler into WebSphere Integration
Developer Toolkit, select the events you want emitted for monitoring and how to generate a
J2EE monitoring EAR to ll of the Business Measures. It is also possible to test in the
WebSphere Integration Developer Toolkit environment prior to deployment as well. The
WebSphere Integration Developer Toolkit environment is a full-fledge development and test
environment.
To generate an EAR from the modeler ZIP file you receive as a project interchange format,
you first import it into your WebSphere Integration Developer Toolkit, activate the events for
monitoring, and generate a J2EE artifacts from the project to be deployed to production.
These are the steps:
1. Import the project interchange artifact from modeler. It must be exported in WebSphere
Business Monitor Development Toolkit format (Figure 6-32).
Figure 6-32 Export model in toolkit format to generate monitor model

2. Open your WebSphere Integration Developer Toolkit workspace and import the project
interchange (Figure 6-33).
Figure 6-33 Import the PI into your WebSphere Integration Developer Toolkit workspace
3. Select the project to import as shown in Figure 6-34 on page 217.

Figure 6-34 Import all modules of project
4. After the build your project will be displayed in the workspace in the business integration
perspective, as shown in Figure 6-35.
Figure 6-35 Default business integration layout

5. Verify that there is no errors from the import. Warnings are permissible.
Though the model you instrumented in modeler Directly Deployed (D2D) has all events
turned on to support the metrics and KPIs defined, it is a good practice to verify them after
the model project is being imported into the WebSphere Integration Developer Toolkit
environment.
You can refine and implement additional events for monitoring if you chose too beyond
what you have specified in the Directly Deployed (D2D). If you did so however make sure
that you remember to propagate the additional changes back to your model in modeler.
Figure 6-36 Verify there is no errors after import
6. For every process and every activity within a model that you want monitored, you must
ensure that their event emission setting is turned on (Figure 6-37).
In this sample that we use throughout this paper, the three processes are as follows:
– ClaimAdjudication
– ClaimIntake
– ClaimProcess
7. Select the process (green) in Figure 6-37 or activity (orange) in Figure 6-38 on page 219
from the business integration canvas editor that you want to set to emit events for
monitoring.
a. Select the process or activity.
b. Expose its properties through the Properties tab.
c. Select Event Monitor.
d. Select All for all event type and click Save.
e. Notice the Flag icon indicating that the activity or process is being wired to emit events
for monitoring.
f. Save the settings.
Figure 6-37 Decide on which process to monitor

Figure 6-38 Decide which activity in a process to monitor
Figure 6-39 illustrates how the monitoring focus will be on the Claim Adjudication, setting the
properties to all for Invoke - Handle Medical claims.
Figure 6-39 Activate process or activity to emit events for monitoring
A
B
C
D

8. Now that you have wired your business process model for monitoring, generate J2EE
artifacts so that it can be deployed into the production environment. To do so, perform the
following steps:
a. Select your monitor model project.
b. Right-click for the drop-down options.
c. Select Monitor Tools.
d. Select Generate Monitor Model.
9. When the generate functions starts, enter the monitor project and model module name. If
the names already exist, you must specify new names (Figure 6-40).
Figure 6-40 Enter project and model name to generate
10.Follow through by clicking Next. Keep all default options and include all reference projects
(Figure 6-41 on page 221).

Figure 6-41 Verify project name
11.The next panel lets you select what event you wanted to monitor. Do so by selecting the
default metrics from the template or by specific event selection for more granularity
(Figure 6-42).
Figure 6-42 Select the metrics to monitor from default template

You can also further refine by the exact event type you want to select (Figure 6-43).
Figure 6-43 Refine selection by exact event type
12.If you wanted to monitor the value of variables’ changes, you must also select them
(Figure 6-44).
Figure 6-44 Select variable values for monitoring as applicable
13.You can also choose the quick option of just select what was turned on in the application
as shown in step 12 (Figure 6-45).
Figure 6-45 Select default events turned on in application

14.When satisfied with your selection, click Next to proceed to generate the monitor model.
15.You will receive two more summary windows. The first summary window shows your
selection of what event types you turned on for monitoring (Figure 6-46). The second
summary window previews (Figure 6-47) what would transpire in your monitor model in
terms of metrics and KPIs.
Figure 6-46 Review panel for events selected
Figure 6-47 Model metrics and KPIs preview
16.Click Finish to generate the monitor model.

17.After the monitor model gets generated, it is displayed in the monitor model editor
perspective. Verify that there are no errors in the model (Figure 6-48). Warnings are
permissible.
Figure 6-48 Verify monitor model after generation
After your monitor model is deemed production ready, you can export it in the format of a
J2EE artifact to be deployed.
Note: The WebSphere Integration Developer Toolkit environment is a full extension of the
Modeler IPD environment that you are already familiar within your Experience phase. If you
choose to, the WebSphere Integration Developer Toolkit can be used to augment your
monitor model with additional monitoring rich features that the IPD environment doesn’t
offer.
You can also do iteration testing of your model here in this environment.

To do this, perform the following steps:
1. Select your monitor model project, right click and click Export.
2. Select Option to export EAR file (Figure 6-49).
Figure 6-49 Select to export project as a J2EE EAR
3. Enter the external name for the EAR file and specify folder location (Figure 6-50).
Figure 6-50 Export EAR file
You can now hand off your Monitor model EAR file to be deployed to production.

6.4 Assemble user experience
The next step in the Prescriptive Guide Approach is “Assemble user experience”. It includes
the following tasks:
Automatic generation of lotus forms
Customization of lotus forms
Recommendations for advanced forms creation customization
Deployment phase.
Figure 6-51 Assemble user experience
Forms allow you (the business analyst) to define how business users interact with real-time
process information. Forms in our solution can be associated with human tasks only. The
relationship between forms, business items, and human tasks is natural:
Forms define the user interface.
Business items define the data being acted on throughout the process.
Human tasks bring data and the user interface together.
One of the ways that you can make your application easier to use is to create custom forms
for your human tasks. If you already have forms created using Lotus Forms Designer, you can
import these forms into your workspace and associate them with a human task. You can also
customize forms that you create in WebSphere Business Modeler and update these forms in
Note: The process of exporting your emitting BPEL application as an EAR file for
deployment is exactly the same as the process for exporting a monitor EAR file because
they follow one standard specification.
Deployment Phase
Perform
IT Assembly
Assemble
End User
Experience
Instrument Process
and Generate
Monitoring Models
Test in
Universal
Testing
Environment
Prepare
Production
Environment
Monitor
Health of
Process
Deploy
Artifacts

your process model. A custom form designed in Lotus Forms Designer can provide a
user-friendly and attractive interface for reviewing and entering the data associated with a
human task.
6.4.1 Automatic generation of forms for human tasks
This section discusses how to generate a basic form for a human task. You can generate
input or output forms for human task by clicking the menu, as shown in Figure 6-52
If you have forms already created for the human tasks, you can associate forms with human
task and process inputs and outputs on the Forms tab in the Attributes view.
Figure 6-52 Generate Form
Note: When you associate a form with a human task, if the inputs or outputs of the human
task do not match the form data, then the inputs and outputs of the human task will be
replaced with the form data.

6.4.2 Customizing the appearance of the form
A plain input or output form using the input or output business item for the activity will be
generated. Using the claim intake process for our example, if we use the default form
generated from the claim business item for the human task, the user will enter data in a form
that contains the inputs shown in Figure 6-53.
Figure 6-53 Plain form from automatic generation
Figure 6-53 illustrates only the generic, generated form. You can customize the form by
changing colors, rearranging the fields, and inserting graphics into the form using the palette
in the Lotus Forms Editor (Figure 6-54 on page 229).

Figure 6-54 Lotus Form Editor Palette
If we customize a form based on the claim business item, then we can present users with a
better form layout and format, allowing users to find the fields in the form that are relevant to
the current task.This will save users time in data entry.
Note: Detailed information about how to customize a form using Lotus Forms Designer is
beyond the scope of this paper. Instead, we illustrate a more customized form to give the
readers a sense of what is possible when the business analyst works with members of the
graphics/design team using Forms Designer.

Figure 6-55 is an example of our custom form after it is modified using the editor.
Figure 6-55 Customized new form
6.4.3 Advanced Lotus forms editing
In this paper, our objective is to convey the importance and flexibility of creating and
designing forms as the user interaction with the system. Fortunately, other resources exist
that go into more depth on how to use Lotus Forms and Lotus Forms Designer for advanced
editing of Lotus Forms. For more information about using Lotus Forms for advanced design of
Forms, consult the following resources:
IBM Workplace Forms 2.6: Guide to Building and Integrating a Sample Workplace Forms
Application
http://www.redbooks.ibm.com/abstracts/sg247388.html?Open
The library for Lotus Forms documentation
http://www-01.ibm.com/software/lotus/forms/library.html
6.5 Test applications in Universal Test Environment
This section is the next phase of Deployment within the Prescriptive Guide Approach. It
focuses mainly on testing the application prior to deploying it to the production environment.
Two different types of testing are possible:
Unit testing using the Integration Test Client.
Automated and batch processed testing using the component testing capabilities
Important: After a form is associated with a human task or process, you or your form
designer can move fields to improve the form layout, add headings and graphics, format
fonts, and make other visual enhancements to the form. However, it is recommended that
you do not add, delete, or re-create form data in the form editor (Lotus Forms Designer). To
add or change form data fields, update the attributes of the relevant business items.

The following sections explain these capabilities in more detail and provides examples on
how to go through it. The intention is to give the reader a good overview of the capabilities
and, where appropriate, to allow the reader to become educated on specific topics by
following links that cover specific topics in greater detail.
Deployment phase.
Figure 6-56 Test in Universal Test Environment
The amount and kind of testing performed depends on whether the effort can be completed
using the IPD capability. If not, then one can use the component testing capability in the
WebSphere Integration Developer environment
6.5.1 Using the integration test client
In WebSphere Integration Developer, the integration test client is the designated tool for
testing modules and components. The test client features a sophisticated user interface that
enables you to manage and precisely control your tests.
Deployment Phase
Perform
IT Assembly
Assemble
End User
Experience
Instrument Process
and Generate
Monitoring Models
Test in
Universal
Testing
Environment
Prepare
Production
Environment
Monitor
Health of
Process
Deploy
Artifacts

The following steps give an overview on how to use the integration test client based on a unit
test on the freshly implemented Mediation “Select Provider”.
1. Select Test Component from the context menu (Figure 6-57). This triggers a full
end-to-end test. Testing the component in isolation permits testing the component without
actually calling towards outgoing services.
Figure 6-57 Select Test Component from the context menu
2. The integration test client will appear (Figure 6-58 on page 233).
In Figure 6-58 on page 233,(1) permits to start a new unit test, and (2) permits to select
values to be send to the service.

Figure 6-58 Integration test client for Select Provider
The integration test client is rich in functionality. It supports the following features:
Events page of the integration test client
In the Events page of the integration test client, you can perform numerous test activities
that enable you to interact with your module during testing, such as selecting an operation
to test, specifying values for the operation, and invoking the operation.
Value and data pool editors
In the Events page of the integration test client, a value editor is provided that enables you
to specify, view, edit, and pass values for operations, manual emulations, and event
definitions. The value editor also enables you to save values to a data pool, where you can
view and edit the values using the data pool editor and later reuse them in the value editor.
Configurations page of the integration test client
In the Configurations page of the integration test client, you can edit the default test
configuration or you can create and edit new test configurations. This enables you to add
modules to your test configurations, or add emulators and monitors to your test
configuration modules, to more precisely control your tests.
Icons and symbols for the integration test client
In the integration test client and other WebSphere Integration Developer tools, icons are
images that are used to invoke actions. Symbols, by comparison, are images that simply
represent workbench elements and they are not used to invoke actions.
Keyboard shortcuts for the integration test client
In the integration test client, you can perform many of the available test actions by using
keyboard shortcuts.

6.5.2 Using component testing
In component testing, you use the new test suite editor and associated wizards to create and
define test cases that are comprised of one or more operations. This enables you to
sequentially test multiple operations as a group in the integration test client. You can also
perform batch component testing on either a test environment server or a stand-alone server
by using test scripts or the user interface of the Web-based Component Test Explorer.
The test suite editor is fully integrated into the workbench, which enables you to navigate
through the Business Integration view and other views while using the editor. It is also closely
integrated with the assembly editor. You can open the assembly editor from the test suite
editor. The primary launch point for the test suite editor is the Business Integration view. You
can open multiple instances of the test suite editor and use them to define your test suites
and test cases.
6.6 Prepare production environment
Create a staging environment for testing on the full topology. This environment will be created
with a production topology as close as possible to the actual topology. The same topologies,
database configurations, messaging resources, and repositories should be used as for
production.
The product stack to install includes the following items:
WebSphere Process Server
WebSphere Business Monitor
WebSphere Services Registry and Repository
After testing is complete, perform any installation needed on the production topology.
overall Deployment phase.
Note: More information about the Integration test client can be found within the
WebSphere Process Server Information Center at the following Web page:
.help.comptest.ui.doc/topics/rtestui.html
Note: More information about component testing can be obtained within the WebSphere
Process Server Information Center at the following Web page:
.help.comptest.ui.doc/topics/ccomptestovw.html

Figure 6-59 Prepare production environment
In general, a variety of topologies are possible and a decision on the best solution depends
on the appropriate customer needs. In this paper, a topology has been chosen that has an
average complexity and is suitable for showing the various configuration steps.
The selected topology for BPM is named BPM Golden Topology (Figure 6-60 on page 236). It
includes the following features:
Application Deployment Cluster
This cluster contains the business process applications (For example, BPEL Processes).
Web Tools Cluster
This cluster contains the Web based administration tools, such as the Business Space.
Messaging Cluster and Support Cluster
This cluster contains internal BPM components, such as the Registry, messaging engines,
as well as the Business Rules Engine.
Deployment Phase
Perform
IT Assembly
Assemble
End User
Experience
Instrument Process
and Generate
Monitoring Models
Test in
Universal
Testing
Environment
Prepare
Production
Environment
Monitor
Health of
Process
Deploy
Artifacts

Figure 6-60 Example production topology
The clustered environment is installed on two dedicated logical or physical machines.
For scalability reasons and for further high availability specific requirements, it might be
necessary to add additional LPARs such as for duplication of the database, but also
duplication of the HTTP server and duplication of identity servers (LDAP).
A detailed click-by-click installation of such an environment is out of scope of this paper.
However, the link in the following note gives detailed information about how to set up a BPM
topology within a clustered environment.
6.7 Deploy applications
Deploying applications is the next step in the Deployment Phase part of the Prescriptive
Guide Approach. The following sections give a high-level overview of the following
capabilities:
Manually generate applications within WebSphere Integration Developer
Automatically generate applications using command line tools and ANT support.
Manually deploy applications to the server environment
Automatically deploy applications to the server environment
Note: The two nodes should have at least five gigabytes of available memory each, and be
running on a modern CPU architecture.
Note: The IBM Redbooks publication “WebSphere Business Process Management V6.2
Production Topologies” can be found at the following Web page:
http://www.redbooks.ibm.com/abstracts/sg247732.html
It gives in-depth explanations on how to set up a production environment for a business
process management environment.
Database Identity
Support Cluster
Messaging Cluster
Web Tools Cluster
Application Deployment Cluster
Dmgr Proxy Server
Node 1 Node 2

Deployment phase
Figure 6-61 Generate and deploy applications to server
6.7.1 Generate applications in WebSphere Integration Developer
This section shows how to generate applications within WebSphere Integration Developer.
The section shows in an overview how the modules created in the previous steps can be
packaged as EAR files and saved to the disk.
Deployment Phase
Perform
IT Assembly
Assemble
End User
Experience
Instrument Process
and Generate
Monitoring Models
Test in
Universal
Testing
Environment
Prepare
Production
Environment
Monitor
Health of
Process
Deploy
Artifacts

The following steps illustrate how to perform these actions.
1. Select File Export from the menu (Figure 6-62).
Figure 6-62 Export Module as an EAR file

2. The “Integration Module Export” dialog box in Figure 6-63 displays. Select EAR files for
server deployment and select which EARs to deploy.
Figure 6-63 Integration Module Export - Select export usage
Important: The modules will have versioning enabled, in which case you can only export
these as a Command Line service deployment. The user will have to use the service
deployment command line tool to generate the EAR file to deploy to the server. More
details can be found within WebSphere Process Server Information Center at the following
Web page:
bm.websphere.wps.620.doc/doc/tadm_installversionedsca.html

3. Select a directory (Figure 6-64) and click Finish to continue.
Figure 6-64 Select target directory
Exporting the modules as Service Deploy archives occurs in a similar manner. Instead of
selecting EAR files for server deployment, the user selects command-line service
deployment.
6.7.2 Implementation of an automated build
WebSphere Process Server does not offer out-of-the-box scripts to build and deploy
application modules. However, the artifacts and script languages to write such a script do
exist. We recommend Apache ANT to write the build script. WebSphere Process Server
offers ANT tasks for the following purposes:
ServiceDeploy Build of Module using ServiceDeploy
EJB Deploy Generation of EJB deployment code
For application deployment to the server we recommend the usage of Jython or JACL. This is
documented as example scripts within the various Information Centers. See the note box on
the next page for links to relevant resources.
Note: More details on deploying modules can be found within the WebSphere Process
Server Information Center at the following Web page:
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.webspher
e.wps.620.doc/doc/tdep_depprodserver.html

6.7.3 Deployment of applications
After the EAR files are produced, they can be deployed to the WebSphere Process Server
and WebSphere Business Monitor environments. Detailed deployment is out of scope of this
paper.
Additionally, deployment can also be executed through the use of Jython or JACL, executed
using the wsadmin tool. The wsadmin tool is a command-line version of the administrative
console and can be used to script any activity executed in the administrative console. More
information about this topic as well as the WebSphere Process Server and WebSphere
Business Monitor Information Center at the following Web page:
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.websphere.w
ps.620.doc/doc/tdep_depprodserver.html
6.8 Monitor health of process
After the application is deployed, a user might want to monitor the health of the processes
contained in these applications. Monitoring the health of the process is the next step in the
Deployment phase.
The tools and components that are part of the WebSphere BPM suite allow a variety of
possibilities. In this section we selected four major capabilities and explain the capabilities
briefly in the sections that follow. Note that detailed descriptions of these capabilities are not
in the scope of this paper. We indicate links and references we think are useful to give more
details.
Note: Information about creating a deployable application module using the ServiceDeploy
command line tool can be found at the following Web page:
bm.websphere.wps.z.620.doc/doc/rdev_servicedeploy.html
Information about the ServiceDeploy command line tool also available as a specific
Apache Ant task. Refer to the following Web page:
bm.websphere.wps.620.doc/doc/tdep_usingant.html

Deployment phase.
Figure 6-65 Monitor health of the process
If you look for throughput and performance problems, or if you look to adjust your system to
provide scalability and reliability, the following four capabilities within WebSphere Process
Server permit to monitor health and debug your system.
Failed Event Manager
Failed Event Manager is used to monitor errors in asychronous communication. If, for
example, a message could not be delivered to a target component, the user can use the
Failed Event Manager to resubmit this message after either correcting message payload
or after correcting the error.
Service Integration Bus Browser
Service Integration Bus Browser is used to monitor and administer the Service Integration
Bus topology underneath WebSphere Process Server. It delivers details about messaging
engines, publishing points and also queue depth. Additionally, it can be used to manage
messages in a queue including to browse the content of messages.
Business Space Health Monitor
The Business Space Health Monitor is part of the Business Space. It gives an aggregated
and high level view on application and component health which are part of WebSphere
Process Server.
Tivoli® Performance Viewer
Tivoli Performance Viewer can be used to do performance tuning of a business process
Management Production Environment.
Deployment Phase
Perform
IT Assembly
Assemble
End User
Experience
Instrument Process
and Generate
Monitoring Models
Test in
Universal
Testing
Environment
Prepare
Production
Environment
Monitor
Health of
Process
Deploy
Artifacts

First-failure data capture support (FFDC), logs, and trace can be used to track down issues:
FFDC persists records of failures and significant software incidents that occur during runtime
in WebSphere Process Server or WebSphere Enterprise Service Bus. Additionally
WebSphere provides logs and trace settings which can be used to debug and trace a problem
to the deepest level.
6.8.1 Failed event manager
The failed event manager is a Web-based client for working with and resubmitting the failed
invocations. It is an integration application and is available in the administrative console. It
displays the number of failed events and provides a number of search capabilities.
You can query for failed events using a variety of criteria such as date, last successful or failed
event, by exception text, or a combination of these.
Figure 6-66 provides a high-level illustration of WebSphere Process Server exception
processing and its relationship to the failed event manager. Explanations of the numbered
steps follow the illustration.
Figure 6-66 Failed event manager
1. Component A calls component B in an asynchronous manner.
2. Component B encounters a runtime exception and a failed event record is generated.
3. The failure recovery service captures this failure and stores it in the failed event database.
4. The system administrator opens the failed event manager to investigate the problem.
Note: Refer to WebSphere Application Server 6.1 Information Center for more detailed
information about how to troubleshoot WebSphere, at the following Web page:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.n
d.multiplatform.doc/info/ae/ae/ttrb_diagfix.html
runtime exception!
1 2
3
4
Failed Event Manager
Failed
Event
Database
Failed
Event
Failed Event
Generated
Component A Component B
Asynchronous
Request

6.8.2 Service Integration Bus Browser
The Service Integration Bus Browser provides a single location for browsing and performing
day-to-day operational tasks on service integration buses. The Service Integration Bus
Browser is noted for debugging asynchronous communication. Application errors can cause
messages not to be picked up. Using the SIB Explorer, the user can check where his
messages remain.
Examples of day-to-day operations include browsing service integration buses, viewing
runtime properties for messaging engines, or managing messages on message points. The
browser is not intended as a bus configuration tool. Figure 6-67 shows the Service Integration
Bus Browser which is embedded in the Administrative Console.
Figure 6-67 Service Integration Bus Browser within the administrative console
Note: The WebSphere Process Server Information Center gives more details on the Failed
Event Manager. Consult the following Web page for more information:
bm.websphere.wps.620.doc/doc/ctroub_howto_submitt_failed_events.html
Additionally the following Web page gives a detailed explanation based on a use case on
recovery from an error situation using the failed event handler:
bm.websphere.wps.620.doc/doc/ctroub_howto_submitt_failed_events.html

1. From within the Administrative Console the SIB Browser can be accessed by navigating to
Service Integration Service Integration Bus Browser.
2. A panel shows the Bus topology including messaging engines, queue points, publication
points, and mediation points.
3. A panel shows actual content of Queue Points. In this case we selected the queue points
from the SCA System Bus.
6.8.3 Business Space health widgets
The Business Space health widgets, also known as the Health Monitor (Figure 6-68), are
used to view a snapshot of the overall system health of your business solution. These widgets
provide a single place from which you can quickly assess the status of application servers,
nodes, clusters, deployment environments, messaging engines and their queues, databases,
system applications, and failed events.
Figure 6-68 Health Monitor
Note: The Service Integration Bus Browser gives you the ability to monitor queue content
and browse messages on the queue. It is a useful tool for debugging. More information
about the Service Integration Bus Browser can be found within the IBM WebSphere BPM
bm.websphere.wps.620.doc/doc/cadm_sibbrowser.html

In Health Monitor, you can perform the following actions:
Customize the widget to provide status on a desired subset of system components. Click
Configure from the widget menu to access the list of item types available in Health
Monitor. By default, all item types are selected. Clear any that you do not want to monitor.
You can update this configuration at any time to change the types of system components
you are currently monitoring. In addition, you can use the text boxes under certain system
components (clusters, servers, deployment environments, applications, and system
databases) to further filter the monitoring results. Enter the full text or use partial text with
a wild card character. The text fields support two types of wild cards:
– Question mark (?) is a single-character wild card
– Asterisk (*) is a multi-character wild card.
You can enter multiple values delimited by a comma (,) or a carriage return.
Specify the rate at which the widget refreshes the information. You can specify any
positive value in the Refresh every numberOfSeconds field. Set it to 0 (zero) to prevent
Health Monitor from refreshing.
Specify the number of rows to show per page. For each system component you are
monitoring, Health Monitor displays only the number of rows you specify. All other rows are
placed into tabbed pages. Use the forward arrow (>) and back arrow (<) to navigate
through the data. When you have configured Health Monitor to display a large number of
system component types, use a smaller value for the Rows per page field to prevent the
need for excessive scrolling.
Specify the maximin number of query results sent from the server to the client. You can
specify any positive value in the Maximum query result field.
6.8.4 Tivoli Performance Viewer
The Tivoli Performance Viewer (TPV) is a powerful application that allows you view a variety
of details of about the performance of your server. The performance viewer enables
administrators and programmers to monitor the current health of WebSphere Process Server.
Because the collection and viewing of data occurs on the process server, performance is
affected. To minimize performance impacts, monitor only those servers whose activity you
want to monitor.
Note: More details about the Health Monitor can be obtained from the WebSphere
Process Server Information Center at the following Web page:
bm.bspace.620.help.widgets.doc/doc/help_healthwidget/help_healthmonitor.html
A more concrete scenario is shown at the following Web page:
bm.bspace.620.help.framework.doc/scenarios/solution_management/solutionmanageme
ntscenario2.html

The following steps show how to use the Tivoli Performance Viewer:
1. Activate the Performance Monitoring Infrastructure (PMI) on the server, as depicted in
Figure 6-69.
Figure 6-69 Activate Performance Monitoring Infrastructure
2. Select Monitoring and Tuning Performance Viewer Current Activity from the
menu.
3. Figure 6-70 shows the Tivoli Performance Viewer details.
(1) shall be used to select a Performance Module (such as a JDBC Datasource).
(2) permits to actually display the content in the right pane
(3) view can be toggled between a graphical overview and a table overview. In this case it
is a table overview.
Figure 6-70 Tivoli Performance Viewer

Note: The WebSphere Process Server 6.2 Information Center provides more details about
using Tivoli Performance Viewer within WebSphere BPM products. Refer to the following
Web page:
bm.websphere.wps.620.doc/doc/tmon_viewing_pmi.html
Additional information can be obtained within the WebSphere Application Server V6.1
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.
websphere.nd.multiplatform.doc/info/ae/ae/tprf_tpvmonitor.html
Note: For performance monitoring going beyond the usage of Tivoli Performance Viewer,
including for example alerts, notification or a more advanced Dashboard, we strongly
recommend the usage of Tivoli Composite Manager for SOA. More info on ITCAM for SOA
can be obtained at the following Web page:
http://www-01.ibm.com/software/tivoli/products/composite-application-mgr-soa/

Appendix A. Additional material
This paper refers to additional material that can be downloaded from the Internet as
described below.
Locating the Web material
The Web material associated with this paper is available in softcopy on the Internet from the
IBM Redbooks Web server. Point your Web browser at:
ftp://www.redbooks.ibm.com/redbooks/REDP4543
Alternatively, you can go to the IBM Redbooks Web site at:
ibm.com/redbooks
Select the Additional materials and open the directory that corresponds with the IBM
Redpaper form number, REDP4543.
Using the Web material
The additional Web material that accompanies this paper includes the files shown in
Table A-1 on page 250.
A

Table A-1 Materials available for download
How to use the Web material
Create a subdirectory (folder) on your workstation, and unzip the contents of the Web
material zip file into this folder.
Filename Description
IBM Business Process Management
Prescriptive Guide to Solution Implementation
Prescriptive guidance that is simple and usable
on how to use BPM products to deliver a solution
into production within 60 days.
ArchitectureGuide.pdf Appendix - Architecture Guide: Includes
material on selecting and implementing a
BPM SOA Architecture
ImplementWebServices.pdf ImplementWebServices: Includes additional
material on how to link existing webservices to
the Business Processes
Claims-Model_2009-05-27T16.31.59.zip Contain WID Projects used as an example in this
IBM Redpaper publication
ClaimsServices.zip Contain WID Projects used as an example in this
paper
Claims-Model_Final.mar Contains the modeler Projects

Related publications
The publications listed in this section are considered particularly suitable for a more detailed
discussion of the topics covered in this paper.
IBM Redbooks
For information about ordering these publications, see “How to get Redbooks” on page 251.
Note that some of the documents referenced here might be available in softcopy only.
Business Process Management Enabled by SOA
http://www.redbooks.ibm.com/abstracts/redp4495.html
Online resources
These Web sites are also relevant as further information sources:
IBM BPM — Business Process Management Site
http://www-01.ibm.com/software/info/bpm/
BPM Blueworks
https://apps.lotuslive.com/bpmblueworks/
How to get Redbooks
You can search for, view, or download Redbooks, Redpapers, Technotes, draft publications
and Additional materials, as well as order hardcopy Redbooks publications, at this Web site:
ibm.com/redbooks
Help from IBM
IBM Support and downloads
ibm.com/support
IBM Global Services
ibm.com/services

®
REDP-4543-00
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed
by the IBM International
Technical Support
Organization. Experts from
IBM, Customers and Partners
from around the world create
timely technical information
based on realistic scenarios.
Specific recommendations
are provided to help you
implement IT solutions more
effectively in your
environment.
For more information:
ibm.com/redbooks
Redpaper™
BPM Solution
Implementation Guide
Practical approach to
rapid BPM solution
delivery
Business-driven BPM
solution
implementation
Complements
existing business
partner and customer
solution
methodologies
This IBM Redpaper publication provides a practical bridge toward
achieving successful BPM solution implementation within 60 days. It is
based on an approach using phases and specific activities outlined in
the IBM Business Process Management Prescriptive Guide to Solution
Implementation.
To provide a realistic context for the solution, we incorporate the
process, business model, and specific scenario from a health care
provider. The context is based on a live code demo that consists of a
fictitious application based on a customer scenario, using the
approach in the IBM Business Process Management Prescriptive Guide
to Solution Implementation to assemble the solution.
This Redpaper discusses how to analyze, model, and manage the
processes within this realistic health care scenario.
Back cover

BPM Solution Implementation Guide

More Related Content

What's hot (17)

Viewers also liked (12)

Similar to BPM Solution Implementation Guide (20)

BPM Solution Implementation Guide